System and method for on-demand data distribution in a P2P system

PRIORITY REFERENCE TO PRIOR APPLICATIONS

[0001] This application claims benefit of and incorporates by reference provisional patent application Ser. No. 60/217,788, entitled “System and Method for On-Demand Data Distribution,” filed on Jul. 11, 2000, by inventor Brian Yen.

TECHNICAL FIELD

[0002] This invention relates generally to peer-to-peer (“P2P”) data distribution, and more particularly, but not exclusively, provides techniques for encrypted on-demand P2P data distribution and payment.

BACKGROUND

[0003] Conventionally, P2P systems, such as Napster, enable a user to store and share data files, such as MP3 files, on his or her computer. The user may also download data files from other users' computers to his or her computer. The downloaded files may then also be shared with other users. To enable sharing, the user first logs on to a central server, which keeps a registry of all logged-on users and their files available for sharing. The central server notes the address of the user and his/her files that are available and adds the filenames to the registry. If the user wants to download a file, the user enters the filename (i.e., a song's title in the case of Napster) and the central server returns a list of computers storing the file. The user can then download the song from one of the computers.

[0004] However, there are disadvantages to conventional P2P systems. One disadvantage may include the lack of a payment technique for downloading files. Another possible disadvantage of conventional P2P systems is that they may enable theft of intellectual property via unauthorized duplication of copyrighted data files.

SUMMARY

[0005] The present invention provides a system for distributing data via a P2P network topography. The system comprises a server communicatively coupled to a network, such as the Internet. A plurality of consumer boxes, which may include mobile devices, computers, or any other network-enabled device (which may also be generically referred to as peers), may also be coupled to the network. The central server includes a distribution engine, which keeps a database of files available over the network at consumer boxes, as well as consumer boxes' addresses. The database also keeps consumer box owner data, which may include name, address, and payment information, as well as other data. Upon receiving a request for a data file from a consumer box, the distribution engine locates a consumer box closest to the requesting consumer box that has the requested data file. The distribution engine then sends information to the requesting consumer box necessary to download the data file from the closest consumer box. This information may include the address of the closest consumer box, encryption data to decrypt the request data file, and other data. The distribution engine may also request payment information from the requesting consumer box and process payment.

[0006] The present invention further provides a method for P2P data distribution. The method comprises the steps of receiving a request from a consumer box for a data file, the request including payment information; locating a consumer box closest to the requesting consumer box having the requested file; sending encryption data to decrypt the request data file to the requesting consumer box; sending the address of the closest consumer box to the requesting consumer box; and processing payment for the requested file.

[0007] Therefore, the system and method may advantageously prevent theft of intellectual property in P2P systems by enabling encryption and payment for authorized duplication of intellectual property.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.

[0009]FIG. 1 is a diagram of a network topography suitable for employing an embodiment of the invention;

[0010]FIG. 2 is a block diagram of central server of FIG. 1;

[0011]FIG. 3 is a block diagram showing the memory of the central server;

[0012]FIG. 4 is a block diagram of consumer box <b>2</b> of FIG. 1;

[0013]FIG. 5 is a block diagram showing the memory of the consumer box <b>2</b>;

[0014]FIG. 6 is a flowchart diagram of a method for a central server communicatively coupled to multiple consumer boxes to distribute data on a P2P system;

[0015]FIG. 7 is a flowchart diagram of a method for a consumer box communicatively coupled to the central to distribute data on a P2P system; and

[0016]FIG. 8 is a diagram of a network topography suitable for employing an alternative embodiment of the invention.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

[0017] The following description is provided to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles, features and teachings disclosed herein.

[0018]FIG. 1 is a diagram of a network topography suitable for employing an embodiment of the invention. In one embodiment, central server <b>110</b>, consumer box 1 (<b>130</b>), consumer box 2 (<b>140</b>) and numerous other consumer boxes are communicatively coupled to the Internet <b>120</b> via DSL connections <b>125</b>. In an alternative embodiment, Internet <b>120</b> can be any other network suitable for transferring data and DSL connections <b>125</b> may be other suitable types of connections to a network such as dial up, cable modem connections, wireless connections or a LAN. Also note that central server <b>110</b> can alternatively comprise multiple servers accessible via one net IP address. The multiple servers may in turn be coupled to database servers that are coupled to a single storage array holding an index and other required data for implementing the invention. The storage array may also be mirrored at different locations across the world.

[0019]FIG. 2 is a block diagram of central server <b>110</b> (FIG. 1). Central server <b>110</b> comprises Input/Output (“I/O”) interface <b>210</b>; display <b>220</b>; input device <b>230</b>; memory <b>240</b>; and CPU <b>250</b>, all coupled together via system bus <b>205</b>. I/O <b>210</b> couples central server <b>110</b> to Internet <b>120</b>. Input device <b>230</b> can comprise a keyboard, mouse, trackball, or other devices or any combination thereof. Memory <b>240</b> may comprise a single read and write capable memory device, or it may comprise multiple memory devices including a Hard Drive, RAM, ROM and/or any other memory devices. CPU <b>250</b> can be an Intel Pentium® processor or any other processor capable of executing instructions stored in memory <b>240</b>. In addition, central server <b>110</b> may comprise other peripheral devices (not shown).

[0020]FIG. 3 is a block diagram showing the memory <b>240</b> (FIG. 2), which includes tracking engine <b>310</b>; tracking database <b>320</b>; advertising engine <b>330</b>; ad database <b>340</b>; distribution engine <b>350</b>; data file index <b>360</b>; user database <b>370</b>; operating system (“O/S”) <b>380</b>; optional web server <b>390</b>; and optional interface <b>395</b>. Tracking engine <b>310</b> tracks how widely songs are distributed and/or requested and which demographics groups are listening to which songs and then stores this data in tracking database <b>320</b>. Advertising engine <b>330</b> tracks the distribution of ads stored in ad database <b>340</b> and in consumer boxes. Distribution engine <b>350</b> handles distribution of songs and payment for distribution of songs and will be discussed in further detail in conjunction with FIG. 6. Data file index <b>360</b> is an index of available data files (typically MP3 files), their locations (i.e., IP addresses or other address type and ID <b>530</b> (FIG. 5) of consumer boxes holding the data file) and the decryption key, if any, for each data file. Identical data files on different consumer boxes may have different decryption keys or identical decryption keys. Note that while in the embodiment discussed herein the data file may include MP3-encoded songs, other embodiments may include any other type of data file such as audio/visual, text, etc. Data file index <b>360</b> may also hold the IP addresses or other address-types of ads.

[0021] User database <b>370</b> includes names of all registered owners of consumer boxes, the IDs of their associated consumer boxes, payment information for the purchase of data files (i.e., debit or credit card information or any other suitable technique for making payment for the purchase of media), and relevant demographic data for use in targeting ads. In one embodiment, O/S <b>380</b> is Linux. However, O/S <b>380</b> can be any operating system capable of operating with software residing in memory <b>240</b>. Optionally, memory <b>240</b> can also include web server <b>390</b> for serving web pages and sending interface <b>395</b> to consumer boxes for ordering media.

[0022]FIG. 4 is a block diagram of consumer box 2 (<b>140</b>), which may be substantially similar to consumer box 1 (<b>130</b>) and any other consumer boxes or peers communicatively coupled to Internet <b>120</b>. Consumer box 2 (<b>140</b>) may be an instant-on device (i.e., boot-up time is minimal). Consumer box 2 (<b>140</b>) comprises I/O <b>410</b>; audio output <b>420</b>; display <b>430</b>; CPU <b>450</b>; memory <b>460</b>; input device(s) <b>470</b>; optional Universal Serial Bus (“USB”) port <b>440</b> and optional removable memory <b>480</b>, all coupled together via system bus <b>405</b>. I/O interface <b>410</b> connects consumer box 2 (<b>140</b>) to the Internet <b>120</b> so that consumer box 2 (<b>140</b>) can exchange data with other consumer boxes communicatively coupled to the Internet <b>120</b> as well as with central server <b>110</b>.

[0023] Audio output <b>420</b> may include speakers for outputting songs and ads that are downloaded from other consumer boxes or central server <b>110</b>. Alternatively, audio output <b>420</b> may include headphones or any other device for outputting sound. CPU <b>450</b> may include an Intel Pentium® processor or any other processor capable of executing instructions stored in memory <b>460</b>. Input device <b>470</b> may include a keyboard, mouse, or any other device or combination thereof for inputting information. Optional USB port <b>440</b> is for communicatively coupling devices, such as an MP3 player, to download songs from memory <b>460</b>. Note that in another embodiment USB port <b>440</b> may alternatively be any type of port for connecting devices. Similarly, songs may be stored in removable memory <b>480</b> for listening to in portable devices. Note that only authorized songs stored in memory <b>460</b> can be downloaded via USB port <b>440</b> or to removable memory <b>480</b>. Songs may be authorized for downloading by paying additional fees. In addition, songs may be authorized for downloading if the songs are authorized by the copyright owner to be distributed for free (or if the songs are in the public domain).

[0024]FIG. 5 is a block diagram of memory <b>460</b>, which comprises consumer engine <b>510</b>; encrypted songs <b>520</b>; ID <b>530</b>; O/S <b>540</b>; and optional non-encrypted songs <b>550</b>. Note that memory <b>460</b> may also optionally store (or store in place of and perform the operations of consumer engine <b>510</b>) a client browser, such as Internet Explorer, for surfing Internet <b>120</b> and interacting with optional interface <b>395</b> (FIG. 3). Consumer engine <b>510</b> interacts with the central server <b>110</b> to download songs from other consumer boxes. In addition, consumer engine <b>510</b> sends songs from songs (encrypted) <b>520</b> to other consumer boxes upon receipt of a request for the specified song. Operation of consumer engine <b>510</b> will be discussed in further detail in conjunction with FIG. 7.

[0025] Songs (encrypted) <b>520</b> holds encrypted songs downloaded from other consumer boxes (peers). These songs are typically in MP3 format but can be any format that can be outputted via audio output <b>420</b>. Further, songs stored in songs (encrypted) <b>520</b> can be downloaded to a device, such as an MP3 player, or to removable memory <b>480</b>, if the songs are authorized for downloading (i.e., by payment of a fee, if they are public domain, or authorized for free distribution, etc.). In an alternative embodiment, songs stored in songs (encrypted) <b>520</b> may be downloaded via USB port <b>440</b> or to removable memory <b>480</b> but are degraded with each duplicate made in order to discourage illegal distribution. Songs (encrypted) <b>520</b> may also hold ads in encrypted form (to prevent tampering) for distribution to other consumer boxes.

[0026] ID <b>530</b> is a unique ID established for each consumer box and relates to the owner of the consumer box. Upon purchasing a consumer box, the purchaser registers the box and may submit relevant demographic information, which can be used for targeting advertisements. Alternatively, submission of demographic information may be optional or not even requested during the registration process. Upon registration, the purchaser establishes an account with central server <b>110</b> so that the purchaser may download songs and have his/her credit or debit card (or other payment means) automatically charged for the purchase. The account is identified by ID <b>530</b>, which is sent to central server <b>110</b> whenever a purchaser downloads a song. In an alternative embodiment, consumer box 2 (<b>140</b>) may be a personal computer employing a client browser, such as Internet Explorer. In this case, ID <b>530</b> would be a unique ID stored in a cookie in memory <b>460</b> by the client upon registering for On-Demand Radio over the Internet.

[0027] O/S <b>540</b> is an operating system capable of operating with consumer application <b>510</b>. In one embodiment, O/S <b>540</b> may include Linux. However, in an alternative embodiment O/S <b>540</b> may be any operating system such as Windows 2000® Palm OS®, etc. Optional songs (non-encrypted) <b>550</b> may include songs (or other data files), typically in MP3 format, that are authorized for distribution without payment. As such, the songs need not be encrypted.

[0028]FIG. 6 is a flowchart diagram of a method for distributing data on a P2P system. In one embodiment, distribution engine <b>350</b> of central server <b>110</b> can execute the method of FIG. 6. The method of FIG. 6 may run continuously or at representative intervals. Further, multiple instances of the FIG. 6 method may run simultaneously. Note that in an alternative embodiment, the method of FIG. 6 can be preceded by the sending of interface <b>395</b> to a requesting consumer box. First, a search request for songs is received (<b>605</b>) from, in one embodiment, a requesting consumer box or peer, such as consumer box 2 (<b>140</b>), over Internet <b>120</b> or other network. Next, an index or database is searched (<b>610</b>), such as index <b>360</b>, for songs matching search criteria in the search request and results are sent, in one embodiment, to consumer box 2 (<b>140</b>). Next, a request for a specific song from consumer box 2 (<b>140</b>) is received (<b>615</b>). The request may include a song identifier, such as a song title, and a machine identifier, such as ID <b>530</b>. The request may also include information specifying the type of purchase such as download for a single play, download for a limited number of plays or unlimited play, download to removable memory, etc. Further, the request may include a password or other security data to verify that the user of consumer box 2 (<b>140</b>) is in fact authorized to make this purchase.

[0029] Next, it is determined if an ad should be sent (<b>620</b>). The determination can be based on user preferences, song selected, type of purchase made (i.e., purchase may be subsidized or free for listening to an advertisement), etc. In one embodiment of the invention, advertising engine <b>330</b> (FIG. 3) performs the determination. If an ad is to be sent to, for example, consumer box 2 (<b>140</b>), then an appropriate ad may be determined (<b>625</b>) based on the song identifier (i.e., ads for entry-level cars may be appropriate for Madonna songs while ads for high-end cars may be more appropriate for classical songs) and/or demographic data associated with the ID <b>530</b> (for example, feminine hygiene products would be more appropriate for female consumers than for male consumers) by, in one embodiment, advertising engine <b>330</b>. Alternatively, an ad may be randomly selected or a default ad may be selected that is not based on demographic data or the song identifier.

[0030] Once it is determined which ad to send, then it is determined (<b>630</b>), by, in one embodiment, advertising engine <b>330</b>, which consumer box holding the determined ad is closest to the requesting consumer box. Determination of the closest consumer box storing the ad can be determined via comparing geographical addresses of consumer boxes holding the ad with the requesting consumer box. Alternatively, consumer boxes may be “pinged” to determine the closest consumer box via the Internet <b>120</b>. In one embodiment, the determined ad may reside in ad database <b>340</b> of central server <b>110</b>. Further, the ad may be encrypted in order to prevent tampering with the ad.

[0031] The identifier information of the determined ad and the address of the closest consumer box are sent (<b>635</b>). If the ad is encrypted, then a decryption key may also sent. In an alternative embodiment of the invention, the encryption technique of FIG. 8, as described below, may be used to encrypt and decrypt the ad. If a receipt of ad confirmation signal is received from a requesting box, then an owner of the consumer box requesting the song is charged (<b>650</b>) for the song, as will be discussed further below. If a negative confirmation signal is received (<b>640</b>) or after a pre-specified amount of time has passed without receipt (<b>640</b>) of a signal, then the address of the next closest consumer box that contains the ad is sent (<b>645</b>). If a confirmation signal is not received (<b>640</b>), then the address of the third closest consumer containing the song is sent (<b>645</b>). This process may be repeated until a confirmation signal is received. Alternatively, this process may be repeated a finite number of times or may be repeated for a pre-specified amount of time.

[0032] Once a confirmation signal is received (<b>640</b>) or if no ad is to be displayed, the purchaser is charged (<b>650</b>) for the song. Note that if the song is free (public domain, subsidized by ads, etc.) then the purchaser need not be charged. In an alternative embodiment, the purchaser may be charged after receiving (<b>665</b>) a confirmation signal confirming receipt of the song. In one embodiment, distribution engine <b>350</b> charges the purchaser for the song by charging a credit card or debit card. Alternatively, distribution engine <b>350</b> can debit a prepaid account or debit a checking account or use any other suitable techniques for accepting payment. In an alternative embodiment, distribution engine <b>350</b> can bill the purchaser through his or her ISP bill, similarly to the conventional method of billing for purchased services or items to a telephone bill. In one embodiment, payment information for each registered purchaser may be stored in user database <b>370</b> and indexed by ID <b>530</b> of the consumer box.

[0033] Next, the closest consumer box holding the song is computed (<b>655</b>) by either comparing geographical addresses of consumer boxes with the requesting consumer box (as stored in user database <b>370</b> in one embodiment), by pinging consumer boxes, or via other techniques. Next, a decryption key for the song requested by the requesting box and the address of the closest consumer box that contains the song is sent (<b>660</b>). In an alternative embodiment of the invention, the encryption technique of FIG. 8, as described below, may be used to encrypt and decrypt the song. If a receipt of song confirmation signal is received (<b>665</b>) then the method ends (<b>675</b>). If a negative confirmation signal is received (<b>665</b>) or after a pre-specified amount of time has passed with no receipt (<b>665</b>) of a signal, then the address of the next closest consumer box that contains the song is sent to the requesting consumer box. Sending (<b>660</b>) addresses and awaiting receipt (<b>665</b>) of confirmation may be repeated until a confirmation signal is received. Repetition may be limited to a pre-specified amount of times in order. Once confirmation is received, the method ends (<b>675</b>).

[0034]FIG. 7 is a flowchart diagram of a method for distributing data on a P2P system. In one embodiment, consumer engine <b>510</b> of a consumer box can execute the method of FIG. 7. The method of FIG. 7 may run continuously or at representative intervals. Further, multiple instances of the FIG. 7 method may run simultaneously. Note that in one embodiment, the method of FIG. 7 can be preceded by receiving interface <b>395</b>, in which case, an optional client, such as Internet Explorer, will perform the method of FIG. 7 instead of consumer engine <b>510</b>.

[0035] First, a search request is sent (<b>705</b>) to a central server, such as central server <b>110</b>. Next, the results of the search from the central server are received and then displayed (<b>710</b>). In one embodiment of the invention, consumer engine <b>510</b> may display the results on display <b>430</b>. Alternatively, the results could be voice synthesized and output via speakers, such as audio output <b>420</b>. Next, a request that includes a song identifier and ID, such as ID <b>530</b>, is sent (<b>715</b>) to the central server. In addition, a password or other security data to verify that a user is in fact authorized to make this purchase may be sent to the central server. The request may also include information specifying the type of purchase such as download for a single play, download for a limited number of plays or unlimited play, etc.

[0036] If notification is received (<b>720</b>) that no ad is to be played, then a decryption key and address of the closest box having the song is received (<b>770</b>), as will be discussed further below. However, if an ad is to be played, then the address of the nearest box with the ad and an ad identifier is received (<b>725</b>). In one embodiment, the ad may be located in ad database <b>340</b> of central server <b>110</b>, in which case the received address would be that of central server <b>110</b>. In addition, if the ad is encrypted, a decryption key will also be received. Note that in an alternative embodiment of the invention, the encryption technique of FIG. 8, as described below, may be used to encrypt and decrypt the ad. Next, a request for the ad is sent to the nearest box (or the central server <b>110</b> as discussed above). The ad is then received (<b>735</b>).

[0037] If the ad is not completely received (<b>740</b>) or if there is another problem receiving the ad (<b>740</b>), then an incomplete signal is sent to central server <b>110</b> (<b>745</b>). Then, the address of the next nearest box with the ad is received (<b>750</b>). A request to the address of the next nearest box that was identified in then sent (<b>755</b>). The ad is then received (<b>735</b>). The above process for receiving an ad may be repeated until an ad is received in its entirety. In another embodiment of the invention, the process may be limited to a finite amount of time or number of attempts.

[0038] Once the ad is received, a completion signal is sent (<b>760</b>) to central server <b>100</b> and then the ad is played (<b>765</b>). Next, a decryption key (if the song is encrypted) and the address of the nearest box containing the song are received (<b>770</b>). Next, a request for the song is sent (<b>775</b>) to the identified box. The request includes the song identifier. The song is then received (<b>780</b>) from the nearest box that contains the song. If the song is not completely received (<b>782</b>) due to some network communication failure or because the nearest box drops offline or some other reason, then an incomplete signal is sent (<b>785</b>) to central server <b>110</b>. An address of the next nearest box that holds the song is then received (<b>787</b>). A request to the next nearest box (<b>787</b>) is then sent (<b>790</b>). The above process for requesting a song can be repeated until the song is successfully received. In another embodiment of the invention, the process may be limited to a finite amount of attempts or to a finite amount of time.

[0039] Once the song is completely received, a completion signal is sent (<b>792</b>) to central server <b>110</b>. The song is then decrypted with the decryption key and played (<b>795</b>). In another embodiment of the invention, the downloaded song can also be encrypted and stored in songs (encrypted) <b>520</b>, and inform central server <b>110</b> accordingly. In turn, central server <b>110</b> will update index <b>360</b> to show that the requesting box holds a copy of this song, thereby causing the requesting box to become a server for this song. Note that in an alternative embodiment of the invention, the encryption technique of FIG. 8, as described below, may be used to encrypt and decrypt the song.

[0040]FIG. 8 is a diagram of a network topography suitable for employing an alternative embodiment of the invention. The network topography includes a central server <b>800</b>, a tracking server <b>810</b>, and consumer boxes <b>820</b>, <b>830</b>, and <b>840</b>, which are all communicatively coupled together via a network, such as the Internet. In an embodiment of the invention, the network topography of FIG. 8 implements an encryption technique that may be used in conjunction with the methods disclosed in FIG. 6 and FIG. 7.

[0041] The central server <b>800</b>, tracking server <b>810</b>, and consumer boxes <b>820</b>, <b>830</b>, and <b>840</b> use a public key (asymmetric) encryption technique in order to securely store data files on consumer boxes and to transmit data files between consumer boxes. The public key system utilizes a pair of keys generated with a single algorithm called RSA after the inventors Rivest, Shamir and Adleman, which is described in U.S. Pat. No. 4,405,829, which is hereby incorporated by reference. This algorithm relies on the fact that factorizing very large numbers into two primes is a very hard problem and should take a computer a long time. The basis of the public key system is the two keys, one is kept secret and stored on a consumer box and the other key may be public and is stored on the tracking server <b>810</b>. Only the private key can decrypt information that is encrypted by a corresponding public key. Therefore, to transmit data, an encryption engine uses the public key stored on the tracking server <b>810</b> to encrypt data. Then, only the consumer box having the corresponding private may decipher the data to use it. Further, to protect data for integrity, the data may be checksummed using the private key stored in the consumer box.

[0042] Central server <b>800</b> may be substantially similar to server <b>110</b> (FIG. 1) and includes a data index <b>805</b>, which may be substantially similar to data file index <b>360</b> (FIG. 3). Tracking server <b>810</b> may track transactions and also performs encryption using encryption engine <b>815</b>, as will be discussed further below. In one embodiment of the invention, the features of tracking server <b>810</b> may be combined with central server <b>800</b>, thereby eliminating the need for two servers. Tracking server <b>810</b> also stores public keys K_pub(A), K_pub(B), and K_pub(C) for consumer boxes A <b>820</b>, B <b>830</b> and C <b>840</b>, respectively. In one embodiment, consumer boxes A <b>820</b>, B <b>830</b> and C <b>840</b> do not know their respective public keys. Further, for a transaction T, encryption engine <b>815</b> may generate public key K_pub(T) and private key K_pvt(T).

[0043] Consumer boxes <b>820</b>, <b>830</b>, and <b>840</b> may be substantially similar to consumer box 1 (<b>130</b>) (FIG. 1). Consumer box A <b>820</b> includes an encrypted data file D. The data file D is encrypted with K_pub(A) (referred to herein as K_pub(A)[D]) and may be decrypted with K_pvt(A), which is stored in memory of consumer box A <b>820</b>. In one embodiment of the invention, K_pvt(A) is hardwired into consumer box A <b>820</b> such that it is undiscoverable by a user of consumer box A <b>820</b>. Consumer box A <b>820</b> also includes an encryption engine A <b>825</b> to encrypt K_pub(A)[D] using public keys received from tracking server <b>810</b>, as will be discussed further below. Further, consumer box A <b>820</b> may also include a consumer engine A <b>827</b> for transmitting data between consumer boxes and servers, as will be discussed further below. In one embodiment, consumer engine A <b>827</b> may be substantially similar to consumer engine <b>510</b> (FIG. 5).

[0044] Consumer box B <b>830</b> includes an encryption engine B <b>835</b> and K_pvt(B), which may be hardwired into consumer box B <b>830</b> such that it is undiscoverable by a user of box B <b>830</b>. K_pvt(B) is a private key that can decrypt data encrypted with K_pub(B). Further, consumer box B <b>830</b> may also include a consumer engine B <b>837</b> for transmitting data between consumer boxes and servers, as will be discussed further below. In one embodiment, consumer engine B <b>837</b> may be substantially similar to consumer engine <b>510</b> (FIG. 5).

[0045] Consumer box C <b>840</b> includes an encryption engine C <b>845</b> and K_pvt(C), which may be hardwired into consumer box C <b>840</b> such that it is undiscoverable by a user of box C <b>840</b>. K_pvt(C) is a private key that can decrypt data encrypted with K_pub(C). Further, consumer box C <b>840</b> may also includes a consumer engine C <b>847</b> for transmitting data between consumer boxes and servers, as will be discussed further below. In one embodiment, consumer engine C <b>847</b> may be substantially similar to consumer engine <b>510</b> (FIG. 5).

[0046] In an example operation of the topology of FIG. 8, box B <b>830</b> requests a data file D from central server <b>800</b>. A distribution engine (not shown), similar to distribution engine <b>350</b> (FIG. 3), then searches data index <b>805</b> for consumer boxes holding the data file D and returns a list of boxes having D. The list may be in order of closest location, fastest location, or other orders. Note that in the example of FIG. 8, only box A <b>820</b> has D. A user of consumer box B <b>830</b> then selects a box having D or a consumer engine <b>837</b> may automatically select a box based on closest location, expected download time or other criteria. The engine <b>837</b> then transmits a data request for D to box A <b>820</b>. Consumer engine <b>827</b> of box A <b>820</b> receives the request and may reject it for various reasons including no longer having D, at which point engine <b>837</b> must select another box having D, assuming one is available.

[0047] Assuming that engine <b>827</b> of box A <b>820</b> accepts the request, engine A <b>827</b> then notifies tracking server <b>810</b> of the request. If central server <b>800</b> performs the functions of tracking server <b>810</b>, then the request may go to central server <b>800</b> instead. The request may include an address of consumer box A <b>820</b> and an ID of the consumer box requesting the data D. In turn, encryption engine <b>815</b> of tracking server <b>810</b> generates K_pub(T) and K_pvt(T) using techniques described in U.S. Pat. No. 4,405,829. In addition, encryption engine encrypts K_pub(B) and K_pub(T) using K_pub(A) yielding K_pub(A)[K_pub(B)] and K_pub(A)[K_pub(T)] and sends them to consumer box A <b>820</b>.

[0048] Encryption engine A <b>825</b> then decrypts the encrypted keys K_pub(A)[K_pub(B)] &amp; K_pub(A)[K_pub(T)] using K_pvt(A) to get K_pub(B) and K_pub(T). Encryption engine A <b>825</b> then decrypts K_pub(A)[D] using K_pvt(A) to get unencrypted D. Encryption engine A <b>825</b> then encrypts D with K_pub(B) and K_pub(T) to yield K_pub(T)[K_pub(B)[D]] or K_pub(B)[K_pub(T)[D]] depending on the order of encryption. Consumer engine A <b>827</b> then transmits K_pub(T)[K_pub(B)[D]] (or K_pub(B)[K_pub(T)[D]]) to consumer box B <b>830</b>.

[0049] Upon receipt of K_pub(T)[K_pub(B)[D]] at consumer box B <b>830</b>, consumer engine B <b>837</b> notifies tracking server <b>810</b> of receipt of the encrypted data D. Encryption engine <b>815</b> of tracking server <b>810</b> then encrypts K_pvt(T) with K_pub(B) to yield K_pub(B)[K_pvt(T)], which encryption engine <b>815</b> then sends to consumer box B <b>830</b>. Encryption engine <b>835</b> then decrypts K_pub(B)[K_pvt(T)] using K_pvt(B) to yield private key K_pvt(T). Encryption engine <b>835</b> then decrypts the encrypted D-K_pub(T)[K_pub(B)[D]] using K_pvt(T) and K_pvt(B) to yield unencrypted D, which can then be played on consumer box <b>830</b>. Further, K_pub(B)[D] may be stored in consumer box <b>830</b>. After decryption, consumer engine B <b>837</b> notifies central server <b>800</b> that the transaction is completed and can then charge the registered owner of box B <b>830</b> per the method of FIG. 6. In an alternative embodiment, central server <b>800</b> may charge the register owner of box B <b>830</b> at initiation of the transaction or at another point. In addition, consumer engine B <b>837</b> may notify central server <b>800</b> to update data index <b>805</b> to include that box B <b>830</b> now stores D.

[0050] The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.

[0051] These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.