System and method for providing encrypted data to a device

TECHNICAL FIELD OF THE INVENTION

[0001] The present invention relates generally to the field of communications and, more particularly, to a system and method for providing encrypted data to a device.

BACKGROUND OF THE INVENTION

[0002] Consumers want the ability to obtain high quality digital audio and video content from the Internet on demand. Content providers, such as movie studios, music companies, artists and movie/music rental companies, also want to provide such content to consumers, but only if they are compensated and their content can be protected from unauthorized use and duplication.

[0003] Encryption and coding techniques have been used to protect content in digital video discs (“DVDs”) and other media. But those systems typically maintain the security of the content by keeping the decrypted digital content within the hardware and allowing the user to only have access to an analog output or acceptable digital output. Content security is at risk from hackers and unauthorized use when the encryption/decryption processing is performed via software within a computer. As a result, content providers have been slow to embrace the Internet as an on-demand distribution medium. Moreover, traditional methods of content encryption/decryption for transmission via the Internet have been to slow to provide customers with high quality reception that is competitive to DVD rental, digital cable or satellite television. This is largely due to the time required to encrypt the content on the server, transmit the encrypted content from the server to the client, decrypt the content on the client and “play” the content. Accordingly, there is a need for a system and method for providing encrypted data to a device that meets the demands of both the customer and the content provider.

SUMMARY OF THE INVENTION

[0004] The present invention provides a system and method for providing encrypted data to a device that meets the demands of both the customer and the content provider. More specifically, the present invention improves delivery of encrypted data via a network by encrypting the data with a symmetric key before it is requested and then storing the encrypted data and the symmetric key for later retrieval and transmission.

[0005] The present invention provides a method of providing encrypted data to a device. One or more public keys are received from the device and then validated. A request for the encrypted data is received from the device, and the encrypted data and a symmetric key used to encrypt the data is retrieved. The symmetric key is then encrypted using each of the one or more public keys, and the one or more encrypted symmetric keys and the encrypted data are sent to the device. This method can be implemented using a computer program with various code segments to implement the steps of the method.

[0006] The present invention also provides a system for providing encrypted data to a device. The system includes a processor, a data storage device communicably coupled to the processor and a communications interface communicably coupled to the processor. The processor receives one or more public keys from the device via the communications interface and validates the one or more public keys. The processor also receives a request for the encrypted data from the device via the communications interface, and retrieves the encrypted data and a symmetric key used to encrypt the data from the data storage device. Next, the processor encrypts the symmetric key using each of the one or more public keys, and sends the one or more encrypted symmetric keys and the encrypted data to the device via the communications interface.

[0007] Other features and advantages of the present invention shall be apparent to those of ordinary skill in the art upon reference to the following detailed description taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] For a better understanding of the invention, and to show by way of example how the same may be carried into effect, reference is now made to the detailed description of the invention along with the accompanying figures in which corresponding numerals in the different figures refer to corresponding parts and in which:

[0009]FIG. 1 is a block diagram of a content delivery system in accordance with one embodiment of the present invention;

[0010]FIG. 2 is a block diagram of an encrypted content provider (server) in accordance with one embodiment of the present invention;

[0011]FIG. 3 is a block diagram of a device (client) in accordance with one embodiment of the present invention;

[0012]FIG. 4A is a block diagram of a decryption path of a device (client) in accordance with one embodiment of the present invention;

[0013]FIG. 4B is a block diagram of an encryption path of a device (client) in accordance with one embodiment of the present invention;

[0014]FIG. 5 is a flowchart of a content delivery system in accordance with one embodiment of the present invention;

[0015]FIGS. 6A, 6B and <b>6</b>C are various file formats to deliver content in accordance with one embodiment of the present invention;

[0016]FIG. 7 is a block diagram of a peer-to-peer content delivery system in accordance with one embodiment of the present invention;

[0017]FIG. 8 is another block diagram of a peer-to-peer content delivery system in accordance with one embodiment of the present invention;

[0018]FIGS. 9A and 9B are flowcharts of a peer-to-peer content delivery system in accordance with one embodiment of the present invention;

[0019]FIG. 10A is a block diagram of a decryption path and decoding path of a peer device in accordance with one embodiment of the present invention;

[0020]FIG. 10B is a block diagram of an encryption and encoding path of a peer device in accordance with one embodiment of the present invention;

[0021]FIG. 11A is a block diagram of a decryption path and decoding path of a peer device in accordance with another embodiment of the present invention; and

[0022]FIG. 11B is a block diagram of an encryption path of a peer device in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0023] While the making and using of various embodiments of the present invention are discussed in detail below, it should be appreciated that the present invention provides many applicable inventive concepts, which can be embodied in a wide variety of specific contexts. For example, in addition to telecommunications systems, the present invention may be applicable to other forms of communications or general data processing. Other forms of communications may include communications between networks, communications via satellite, or any form of communications not yet known to man as of the date of the present invention. The specific embodiments discussed herein are merely illustrative of specific ways to make and use the invention and do not limit the scope of the invention.

[0024] The present invention provides a system and method for providing encrypted data to a device that meets the demands of both the customer and the content provider. More specifically, the present invention improves delivery of encrypted data via a network by encrypting the data with a symmetric key before it is requested and then storing the encrypted data and the symmetric key for later retrieval and transmission.

[0025] Referring to FIG. 1, a block diagram of a content delivery system <b>100</b> in accordance with one embodiment of the present invention is shown. The client delivery system <b>100</b> primarily includes one or more servers <b>102</b> that receive data or content from a content provider <b>104</b>. The one or more servers <b>102</b> then deliver the data or content in an encrypted format to a client <b>106</b> that requests the data or content via network <b>108</b>. The data or content can be concerts, broadcasts, games, multimedia, music, movies, television programs, audio/video transmissions (real time conferencing or recordings), and sound recordings.

[0026] The content providers <b>104</b> can be movie studios, music companies, artists, movie/music rental companies or anyone that wants to make audio and/or video content available to customer using a secure environment. The content provider <b>104</b> can specify the terms and conditions, and the level of security by which customers (client <b>106</b>) can access the data or content via the content distributor or service provider (server <b>102</b>). Typically, the content provider <b>104</b> will convert the content from an analog to a digital format (process <b>110</b>), if necessary, and compress the content (process <b>112</b>). The content provider <b>104</b> then provides the content to the server <b>102</b> in a compressed digital format. Some of the more commonly used digital compression standards are produced by the Moving Picture Experts Group (“MPEG”), such as MPEG-1 (VCD and MP3 products), MPEG-2 (digital television set top boxes and digital video discs (“DVD”), MPEG-4 (multimedia for the web and mobility), MPEG-7 (multimedia content description interface) and MPEG-21 (multimedia framework). The present invention is not restricted to these formats, and can, therefore, accept, store and distribute content provided in any format.

[0027] The server <b>102</b> can, however, receive the content in an analog and/or uncompressed format and, if necessary, convert the content from analog to digital format or compress the content as required. The server <b>102</b> encrypts the content (process <b>114</b>) and stores the encrypted content along with the encryption key in a data storage device <b>116</b> (process <b>118</b>). The present invention can use any desired standard or proprietary encryption process <b>114</b>, such as a triple Data Encryption Standard (“3DES”) algorithm, an Advanced Encryption Standard (“AES”) algorithm, or a linear feedback shift register (“LFSR”) sequence. The server <b>102</b> may encrypt and store several versions of the same content. For example, the same movie could be made available in MPEG-2 and MPEG-4 formats. Moreover, each of these formats could be made available in more than one encrypted format, such as 3DES and AES. The server <b>102</b> also authenticates the client <b>106</b> and provides the secure transmission link to the client <b>106</b> via network <b>108</b> (process <b>120</b>). Once a client is properly authenticated, the server <b>102</b> retrieves the requested content from the data storage device <b>116</b> for delivery to the client <b>106</b> (process <b>118</b>). The data storage device <b>116</b> can be a single device or numerous devices communicably coupled via a network. Moreover, the data storage device <b>116</b> can be located within or physically near the server <b>102</b> (local), physically remote to the server <b>102</b>, or any combination thereof.

[0028] The server <b>102</b> can be communicably coupled to the client <b>106</b> using any direct or network communication link. The Internet is a good example of network <b>108</b>. But, network <b>108</b> can be a telephone line, a wireless network, a satellite network or any combination thereof. Likewise, the client <b>106</b> can be any type of audio and/or video playback device, such as a computer, game console, personal data assistant, MP3 player, DVD player, CD player, television, television set top box or wireless network device. The client <b>106</b> decrypts the content (process <b>122</b>), decompresses the content (process <b>124</b>) and may convert the content from a digital format to an analog format (process <b>126</b>).

[0029] Now referring to FIG. 2, a block diagram of an encrypted content provider (server <b>102</b>) in accordance with one embodiment of the present invention is shown. The server <b>102</b> receives content from the content provider <b>104</b> via an input device <b>202</b>, which can be a communication link, a disk drive, optical disk reader, magnetic tape reader or any other means of reading or receiving data. The decrypted content <b>204</b> is encrypted using an encryption engine <b>206</b>, which can be hardware, software or a combination of both. The encryption engine <b>206</b> can use any desired standard or proprietary encryption process, such as a 3DES algorithm, an AES algorithm or a LFSR sequence. The decrypted content <b>204</b> can also be stored in a data storage device (not shown) for later encryption. As previously described, the server <b>102</b> can also convert the content from an analog to digital format and/or compress the content before it is encrypted using the encryption engine <b>206</b>. The encryption engine <b>206</b> stores the encrypted content along with the encryption key in a database or data storage device <b>116</b>. The encryption engine <b>206</b> may encrypt and store several versions of the same content (compression formats and encryption formats). The data storage device <b>116</b> and the encryption engine <b>206</b> are physically or virtually isolated from one another via barrier <b>208</b> to prevent any unauthorized access to the decrypted content <b>204</b>.

[0030] The delivery portion of the server <b>102</b> includes a processor <b>210</b> communicably coupled to the data storage device <b>116</b>, a user profile database <b>212</b>, a memory <b>214</b> and a communications interface <b>216</b>. The processor <b>210</b> uses the user profile database <b>212</b> to authenticate and validate the clients <b>106</b>. The user profile database <b>212</b> can also be used for maintaining and storing customer profiles, purchases or rentals, billing, quality of service options, client hardware and software configurations, and client download terms and restrictions. The memory <b>214</b> can be read only memory (“ROM”), random access memory (“RAM”) or any other type of memory required by the processor <b>210</b> to implement content delivery system. The communications interface <b>216</b> can be any number of different interfaces that allow the server <b>102</b> and the client <b>106</b> to communicate.

[0031] As will be described in more detail in reference to FIG. 5, the processor <b>210</b> receives one or more public keys from the client device <b>106</b> via the communications interface <b>216</b> and validates the one or more public keys using the user profile database <b>212</b>. The one or more public keys are each contained within a certificate signed by the manufacturer or provider of the client device <b>106</b>. Each certificate is validated by verifying its signature using the manufacturer or provider's certificate. The processor <b>210</b> also receives a request for the encrypted data from the client device <b>106</b> via the communications interface <b>216</b>, and retrieves the encrypted data and a symmetric key used to encrypt the data from the data storage device <b>116</b>. Next, the processor <b>210</b> encrypts the symmetric key using each of the one or more public keys, and sends the one or more encrypted symmetric keys and the encrypted data to the client device <b>106</b> via the communications interface <b>216</b>.

[0032] Now referring to FIG. 3, a block diagram of a device (client <b>106</b>) in accordance with one embodiment of the present invention is shown. As shown, only those elements of the client device <b>106</b> that handle the content are shown. The other elements of the client device <b>106</b> will vary depending on the specific client device <b>106</b> being used. The client device <b>106</b> receives and transmits data via a high-speed network connection <b>302</b>. The actual speed of the network connection <b>302</b> will vary according to the client device <b>106</b> and the content being received or transmitted. Network connection <b>302</b> can be a direct or network connection via a telephone line, a wireless network, a satellite network or any combination thereof The network connection <b>302</b> is communicably coupled to a software application <b>304</b> that controls the encrypted content flow between the network connection <b>302</b> and the encryption/decryption device <b>306</b>. The encryption/decryption device <b>306</b> is communicably coupled to a flash ROM key storage <b>308</b>, a decoder/graphics controller <b>310</b> and an input/encoder <b>312</b>. When the encryption/decryption device <b>306</b> receives encrypted content from the software application <b>304</b>, it decrypts the content and sends the decrypted content to the decoder/graphics controller <b>308</b>, which decompresses the decrypted content, if required, and performs a digital to analog conversion so that the decrypted and decompressed content can be displayed. Likewise, the input/encoder <b>312</b> receives analog or digital content, converts the content to a digital format (if required), compresses the content (if required) and delivers the content to the encryption/decryption device <b>306</b> for encryption and subsequent delivery to the software application <b>304</b>.

[0033] The encryption/decryption device <b>306</b> can be implemented as a single chip or as all or part of a card. Moreover, some applications may only require that the encryption/decryption device <b>306</b> perform one function, either encryption or decryption. The flash ROM key storage <b>308</b> can be part of the encryption/decryption device <b>306</b>. The key storage <b>308</b> is used to store a unique private key that has been given to each client device <b>106</b>. At the time of purchase, the customer is given a certificate for the device <b>106</b> that contains the corresponding public key. When the customer chooses to purchase some content, he presents this certificate to the server <b>102</b> (content distributor) (FIG. 1). The server <b>102</b> (FIG. 1) verifies that the certificate corresponds to a valid player (device <b>106</b>) and then encrypts the content using the device's public key and transmits the encrypted content to the device <b>106</b>. The certificate may be instead encoded on a removable smart card so that the content can “travel” with the owner of the smart card rather than the device itself.

[0034] Referring now to FIG. 4A, a block diagram of a decryption path of a device (client <b>106</b>) in accordance with one embodiment of the present invention. The encryption/decryption device <b>306</b> shown in FIG. 4A is a multimode device because it can process unencrypted content (clear channel path <b>402</b>), content encrypted using a first decryption algorithm (block decryption path <b>404</b>) and a second decryption algorithm (streaming decryption path <b>406</b>). Note that a multimode encryption/decryption device <b>306</b> is not required by the present invention. Also note that the present invention is not limited to a single algorithm for streaming encryption/decryption and a single algorithm for block encryption/decryption as both 3DES and AES algorithms could be implemented within a single embodiment of the present invention for block encryption/decryption. Nor is the present invention limited to a total of two encryption/decryption algorithms. For example, the present invention is capable of providing two or more types of block encryption/decryption and two or more types of streaming encryption/decryption within a single embodiment. The encryption/decryption device <b>306</b> includes a PCI interface <b>410</b> communicably coupled to a first buffer <b>412</b> (first in, first out) and a decryption controller <b>414</b>. Note that the PCI interface <b>410</b> can be any standard or high-speed digital interface, such as FireWire, USB-2, Fast Ethernet or AGP interfaces. The first buffer <b>412</b> is communicably coupled to the clear channel path <b>402</b>, the block decryption path <b>404</b> (first decryption algorithm) and the streaming decryption path <b>406</b> (second decryption algorithm). The clear channel path <b>402</b>, the block decryption path <b>404</b> (first decryption algorithm) and the streaming decryption path <b>406</b> (second decryption algorithm) are communicably coupled to a second buffer <b>418</b> (first in, first out). The decryption controller <b>414</b> is communicably coupled to the clear channel path <b>402</b>, the block decryption path <b>404</b> (first decryption algorithm), the streaming decryption path <b>406</b> (second decryption algorithm) and a key manager <b>416</b>. The key manager <b>416</b> is communicably coupled to the key storage <b>108</b>. The security keys are embedded within the hardware of the client device <b>106</b> so that they cannot be compromised by sharing data, such as electronic mail, newsgroup posts, file transfers, etc.

[0035] As shown, the encryption/decryption device <b>306</b> receives encrypted, compressed digital content (audio/video) <b>408</b> via the PCI interface <b>410</b> and places the encrypted, compressed digital content (audio/video) <b>408</b> in the first buffer <b>412</b>. The decryption controller <b>414</b> checks the encrypted compressed digital content (audio/video) <b>408</b> and determines which path <b>402</b>, <b>404</b> or <b>406</b> will process the content <b>408</b>. The decryption controller <b>414</b> also monitors and controls the clear channel path <b>402</b>, the block decryption path <b>404</b> (first decryption algorithm) and the streaming decryption path <b>406</b> (second decryption algorithm). The clear channel path <b>402</b> receives content from the first buffer <b>412</b> and may perform some processing on the content before it is placed in the second buffer <b>418</b> for output as unencrypted, compressed digital content (audio/video) <b>420</b>.

[0036] The block decryption path <b>404</b> (first decryption algorithm) receives content from the first buffer <b>412</b> and decrypts the content using a first decryption algorithm before it is placed in the second buffer <b>418</b> for output as unencrypted, compressed digital content (audio/video) <b>420</b>. The block decryption path <b>404</b> (first decryption algorithm) uses a low to medium speed, high security, standard or proprietary encryption process, such as a 3DES algorithm or an AES algorithm. The block decryption path <b>404</b> is typically used to decrypt content that is in a file format or other type of data block in a batch or off-line process. The decryption controller <b>414</b> requests the appropriate security key from the key manager <b>416</b> and provides the security key to the block decryption path <b>404</b> for use in decrypting the content.

[0037] The streaming decryption path <b>406</b> (second decryption algorithm) receives content from the first buffer <b>412</b> and decrypts the content using a second decryption algorithm before it is placed in the second buffer <b>418</b> for output as unencrypted, compressed digital content (audio/video) <b>420</b>. The streaming decryption path <b>406</b> (second decryption algorithm) uses a high speed, medium security, standard or proprietary encryption process, such as a LFSR sequence. The streaming decryption path <b>406</b> is typically used to decrypt content during a real time or near real time on line process. This provides low latency delays for interactive applications, such as gaming and video conferencing. This also reduces hardware complexity to allow the present invention to be easily integrated into portable client devices. The decryption controller <b>414</b> requests the appropriate security key from the key manager <b>416</b> and provides the security key to the streaming decryption path <b>406</b> for use in decrypting the content.

[0038] Now referring to FIG. 4B, a block diagram of an encryption path of a device (client <b>106</b>) in accordance with one embodiment of the present invention is shown. As previously described, the encryption/decryption device <b>306</b> shown in FIG. 4B is a multimode device because it can process unencrypted content (clear channel path <b>452</b>), content encrypted using a first encryption algorithm (block encryption path <b>454</b>) and a second encryption algorithm (streaming encryption path <b>456</b>). The encryption/decryption device <b>306</b> includes a first buffer <b>458</b> communicably coupled to the clear channel path <b>452</b>, the block encryption path <b>454</b> (first encryption algorithm) and the streaming encryption path <b>456</b> (second encryption algorithm). The clear channel path <b>452</b>, the block encryption path <b>454</b> (first encryption algorithm) and the streaming encryption path <b>456</b> (second encryption algorithm) are communicably coupled to a second buffer <b>460</b> (first in, first out) and an encryption controller <b>462</b>. The second buffer <b>460</b> is communicably coupled to a PCI interface <b>464</b>. The PCI interface <b>464</b> is also communicably coupled to the encryption controller <b>462</b>. Note that the PCI interface <b>464</b> can be any standard or high-speed digital interface, such as FireWire, USB-2, Fast Ethernet or AGP interfaces. The encryption controller <b>462</b> is communicably coupled to the clear channel path <b>452</b>, the block encryption path <b>454</b> (first encryption algorithm), the streaming encryption path <b>456</b> (second encryption algorithm) and the key manager <b>416</b>, which was previously described in reference to FIG. 4A.

[0039] As shown, the encryption/decryption device <b>306</b> receives unencrypted, compressed digital content (audio/video) <b>466</b> via first buffer <b>458</b>. The encryption controller <b>462</b> determines which path <b>452</b>, <b>454</b> or <b>456</b> will process the content <b>466</b>. The encryption controller <b>462</b> also monitors and controls the clear channel path <b>452</b>, the block encryption path <b>454</b> (first encryption algorithm) and the streaming encryption path <b>456</b> (second encryption algorithm). Once processed and placed in the second buffer <b>460</b>, the encrypted, compressed digital content (audio/video) <b>468</b> is sent out via the PCI interface <b>464</b>. The clear channel path <b>452</b> receives content from the first buffer <b>458</b> and may perform some processing on the content before it is placed in the second buffer <b>460</b>.

[0040] The block encryption path <b>454</b> (first encryption algorithm) receives content from the first buffer <b>458</b> and encrypts the content using a first encryption algorithm before it is placed in the second buffer <b>460</b>. The block encryption path <b>454</b> (first encryption algorithm) uses a low to medium speed, high security, standard or proprietary encryption process, such as a 3DES algorithm or an AES algorithm. The block encryption path <b>454</b> is typically used to encrypt content that is in a file format or other type of data block in a batch or off-line process. The encryption controller <b>462</b> requests the appropriate security key from the key manager <b>416</b> and provides the security key to the block encryption path <b>454</b> for use in encrypting the content.

[0041] The streaming encryption path <b>456</b> (second encryption algorithm) receives content from the first buffer <b>458</b> and encrypts the content using a second encryption algorithm before it is placed in the second buffer <b>460</b>. The streaming encryption path <b>456</b> (second encryption algorithm) uses a high speed, medium security, standard or proprietary encryption process, such as a LFSR sequence. The streaming encryption path <b>456</b> is typically used to encrypt content during a real time or near real time on line process. This provides low latency delays for interactive applications, such as gaming and video conferencing. This also reduces hardware complexity to allow the present invention to be easily integrated into portable client devices. The encryption controller <b>462</b> requests the appropriate security key from the key manager <b>416</b> and provides the security key to the streaming decryption path <b>456</b> for use in decrypting the content.

[0042] Referring now to FIGS. 1 and 5, FIG. 5 is a flowchart of a content delivery system in accordance with one embodiment of the present invention. The process starts in block <b>502</b>. The client <b>106</b> initiates a communication link with the server <b>102</b> via network <b>108</b> in block <b>504</b>. The client <b>106</b> then sends the client's public key to the server <b>102</b> in block <b>506</b>. If the client's public key is not authorized as determined by the server <b>102</b> in decision block <b>508</b>, the server <b>102</b> sends an error message to the client <b>106</b> in block <b>510</b>. The client <b>106</b> can then retry the authorization process or attempt to remedy the error. If, however, the client's public key is authorized as determined by the server <b>102</b> in decision block <b>508</b>, the client <b>106</b> then requests the content to be downloaded in block <b>512</b>. The server <b>102</b> determines whether the download should be approved in decision block <b>514</b>. The approval process may include a check of the client's account status, and device, connection and encryption compatibilities. If the download is not approved, as determined in decision block <b>514</b>, the server <b>102</b> sends a denial message to the client <b>106</b> in block <b>516</b>. If the client <b>106</b> decides not to retry or make another selection, as determined in decision block <b>518</b>, the process ends in block <b>520</b>. If, however, the client <b>106</b> decides to retry or make another selection, as determined in decision block <b>518</b>, the process loops back to block <b>512</b> where the client <b>106</b> requests another download.

[0043] If, however, the download is approved, as determined in decision block <b>514</b>, the server <b>102</b> retrieves the encrypted data, one or more terms of use and the symmetric key for the encrypted data from data storage device <b>116</b> in block <b>522</b>. The terms of use allow the content provider <b>104</b> or the server <b>102</b> to specify restrictions on the playback of the content. For example, the terms of use may include a view only once restriction, a limited time period to view the content, a reproduction restriction or any other restriction that the content provider <b>104</b> or server <b>102</b> wishes associate with the content. The server <b>102</b> then encrypts the symmetric key for the encrypted data using the client's private key in block <b>524</b> and sends the encrypted symmetric key, terms of use and encrypted data to the client <b>106</b> in block <b>526</b>. The encrypted symmetric key, terms of use and encrypted data can be sent as one file as will be described in reference to FIGS. 6A, 6B and <b>6</b>C. After receiving the data, the client <b>106</b> decrypts the symmetric key using the client's private key in block <b>528</b> and decrypts the encrypted data using the decrypted symmetric key in block <b>530</b>. The data is then provided to the user in accordance with the terms of use in block <b>532</b> and the process ends in block <b>520</b>.

[0044] Now referring to FIGS. 6A, 6B and <b>6</b>C, various file formats to deliver content in accordance with one embodiment of the present invention are shown. FIG. 6A depicts a file that is intended for delivery to a single client device. The file includes encrypted symmetric key <b>602</b>, which has been encrypted using the client's public key, and encrypted terms of use for the content <b>604</b> and the encrypted content <b>606</b>, both of which have been encrypted using the symmetric key. FIG. 6B depicts a file that is intended for delivery to a client device A with further distribution to client devices B and C. For example, a single customer has several playback devices and would like to be able to use his content in all of them, such as a video playback device in his or her living room, den and bedroom. Or, the customer wants to temporarily play the content on another customer's device, such as a video playback device at a friend's house. The file includes encrypted symmetric key <b>612</b>, which has been encrypted using the client device A's public key, encrypted symmetric key <b>614</b>, which has been encrypted using the client device B's public key, encrypted symmetric key <b>616</b>, which has been encrypted using the client device C's public key, and encrypted terms of use for the content <b>618</b> and the encrypted content <b>620</b>, both of which have been encrypted using the symmetric key. As a result, each device A, B and C decrypts the content using its own private key. FIG. 6C depicts a file that is intended for delivery to a single client device. The file includes encrypted symmetric key <b>622</b> and encrypted terms of use for the content <b>624</b>, both of which have been encrypted using the client's public key, and the encrypted content <b>626</b>, which has been encrypted using the symmetric key.

[0045] Referring now to FIG. 7, a block diagram of a peer-to-peer content delivery system <b>700</b> in accordance with one embodiment of the present invention is shown. The peer-to-peer content delivery system <b>100</b> primarily includes two or more systems, such as system A <b>702</b>, system B <b>704</b> and system C <b>706</b>, that transmit and receive encrypted data or content from one to another via network <b>708</b>. Although the content can be of any type, the system is particularly well suited for video conferencing. Systems A <b>702</b>, B <b>704</b> and C <b>706</b> can be communicably coupled to one another using any direct or network communication link. The Internet is a good example of network <b>708</b>. But, network <b>708</b> can be a telephone line, a wireless network, a satellite network or any combination thereof.

[0046] System A <b>702</b> includes multi-mode encryption and decryption processes <b>710</b>, compression and decompression processes <b>712</b>, digital to analog and analog to digital conversion processes <b>714</b> and authentication and secure transmission processes <b>716</b>. The multi-mode encryption and decryption processes <b>710</b> were previously described in reference to FIGS. 4A and 4B. Note that the encryption and decryption processes of System A <b>702</b> can be implemented as a single mode encryption and decryption process. The encryption and decryption processes of System A <b>702</b> can use any desired standard or proprietary encryption process, such as a 3DES algorithm, an AES algorithm, or a LFSR sequence. The LFSR is probably better suited for the video conferencing application. The compression and decompression processes <b>712</b> and the digital to analog and analog to digital conversion processes <b>714</b> can use any standard or proprietary technique known to those skilled in the art. The authentication and secure transmission processes <b>716</b> are used to setup, monitor and control the initiation and maintenance and tear down of the communication link between the systems <b>702</b>, <b>704</b> and <b>706</b>. Similarly, System B <b>704</b> includes multi-mode encryption and decryption processes <b>720</b>, compression and decompression processes <b>722</b>, digital to analog and analog to digital conversion processes <b>724</b> and authentication and secure transmission processes <b>726</b>, and System C <b>706</b> includes multi-mode encryption and decryption processes <b>730</b>, compression and decompression processes <b>732</b>, digital to analog and analog to digital conversion processes <b>734</b> and authentication and secure transmission processes <b>736</b>.

[0047] Now referring to FIG. 8, another block diagram of a peer-to-peer content delivery system <b>800</b> in accordance with one embodiment of the present invention is shown. Device <b>802</b> receives and transmits data via a high-speed network connection <b>804</b>. The actual speed of the network connection <b>804</b> will vary according to the device <b>802</b> and the content being received or transmitted. Network connection <b>804</b> can be a direct or network connection via a telephone line, a wireless network, a satellite network or any combination thereof. The network connection <b>804</b> is communicably coupled to a software application <b>806</b> that controls the encrypted content flow between the network connection <b>804</b> and the encryption/decryption device <b>808</b>. The encryption/decryption device <b>808</b> is communicably coupled to a flash ROM key storage <b>810</b>, a decoder/graphics controller <b>812</b> and an input/encoder <b>814</b>. When the encryption/decryption device <b>808</b> receives encrypted content from the software application <b>806</b>, it decrypts the content and sends the decrypted content to the decoder/graphics controller <b>810</b>, which decompresses the decrypted content and performs a digital to analog conversion so that the decrypted and decompressed content can be displayed. Likewise, the input/encoder <b>814</b> receives analog or digital content, converts the content to a digital format, compresses the content and delivers the content to the encryption/decryption device <b>808</b> for encryption and subsequent delivery to the software application <b>806</b>.

[0048] Similarly, device <b>822</b> receives and transmits data via a high-speed network connection <b>824</b>. The actual speed of the network connection <b>824</b> will vary according to the device <b>822</b> and the content being received or transmitted. Network connection <b>824</b> can be a direct or network connection via a telephone line, a wireless network, a satellite network or any combination thereof. The network connection <b>824</b> is communicably coupled to a software application <b>826</b> that controls the encrypted content flow between the network connection <b>824</b> and the encryption/decryption device <b>828</b>. The encryption/decryption device <b>828</b> is communicably coupled to a flash ROM key storage <b>830</b>, a decoder/graphics controller <b>832</b> and an input/encoder <b>834</b>. When the encryption/decryption device <b>828</b> receives encrypted content from the software application <b>826</b>, it decrypts the content and sends the decrypted content to the decoder/graphics controller <b>830</b>, which decompresses the decrypted content and performs a digital to analog conversion so that the decrypted and decompressed content can be displayed. Likewise, the input/encoder <b>834</b> receives analog or digital content, converts the content to a digital format, compresses the content and delivers the content to the encryption/decryption device <b>828</b> for encryption and subsequent delivery to the software application <b>826</b>.

[0049] The encryption/decryption devices <b>808</b> and <b>826</b> can be implemented as a single chip or as all or part of a card. The flash ROM key storages <b>810</b> and <b>830</b> can be part of the encryption/decryption devices <b>808</b> and <b>826</b> respectively. The key storages <b>810</b> and <b>830</b> are used to store a unique private key that has been given to each device <b>802</b> and <b>822</b>. At the time of purchase, the customer is given a certificate for the device <b>802</b> or <b>822</b> that contains the corresponding public key. When a video conference or other encrypted data transfer is desired, the devices exchange certificates and negotiate the proper encryption standard to be used. Thereafter, data transmission keys are created and exchanged so that content can be transmitted between the two devices <b>802</b> and <b>822</b>.

[0050] Referring now to FIGS. 9A and 9B, flowcharts of a peer-to-peer content delivery system in accordance with one embodiment of the present invention are shown. The process starts in block <b>902</b>. System A initiates a communication link for control messages with System B in block <b>904</b>. System A sends public key A to System B in block <b>906</b> and system B sends public key B to System A in block <b>908</b>. In other words, System A and B exchange their public security keys. System A and B then negotiate the security level for the communication link for the control messages in block <b>910</b>. The security level can be non-encrypted (“in the clear”) or a selected proprietary or standard encryption algorithm, such as a 3DES algorithm, an AES algorithm or a LFSR sequence. The selected security level will depend on the content being exchanged, the devices at either end, the communication link or the required data transfer rate.

[0051] If the selected security level for the control communication link is encrypted, as determined in decision block <b>912</b>, System A generates a control transmission key A using the selected control security level encryption algorithm in block <b>914</b>. System A then encrypts the control transmission key A using public key B in block <b>916</b> and sends the encrypted control transmission key A to System B in block <b>918</b> where System B decrypts the encrypted control transmission key A using private key B in block <b>920</b>. Similarly, System B generates a control transmission key B using the selected control security level encryption algorithm in block <b>922</b>. System B then encrypts the control transmission key B using public key A in block <b>924</b> and sends the encrypted control transmission key B to System A in block <b>926</b> where System A decrypts the encrypted control transmission key B using private key A in block <b>928</b>. System A and B then initiate a new control communication link using control transmission keys A and B in block <b>930</b>.

[0052] Once the new control communication link is initiated in block <b>930</b> or if the selected security level for the control communication link is unencrypted, as determined in decision block <b>912</b>, System A and B then negotiate the security level for the communication link for the data or content in block <b>932</b>. The security level can be non-encrypted (“in the clear”) or a selected proprietary or standard encryption algorithm, such as a 3DES algorithm, an AES algorithm or a LFSR sequence. The selected security level will depend on the content being exchanged, the devices at either end, the communication link or the required data transfer rate. If the selected security level for the data or content communication link is non-encrypted, as determined in decision block <b>934</b>, System A and B then initiate an open data communication link in block <b>936</b> and exchange the non-encrypted data in block <b>938</b>. Once the communications are complete, the process ends in block <b>940</b>. Note that the present invention allows either system to request and subsequent change the selected security level for the control communication link during ongoing communications.

[0053] If the selected security level for the data communication link is encrypted, as determined in decision block <b>934</b>, System A generates a data transmission key A using the selected data security level encryption algorithm in block <b>942</b>. System A then encrypts the data transmission key A using public key B in block <b>944</b> and sends the encrypted data transmission key A to System B in block <b>946</b> where System B decrypts the encrypted data transmission key A using private key B in block <b>948</b>. Similarly, System B generates a data transmission key B using the selected data security level encryption algorithm in block <b>950</b>. System B then encrypts the data transmission key B using public key A in block <b>952</b> and sends the encrypted data transmission key B to System A in block <b>954</b> where System A decrypts the encrypted data transmission key B using private key A in block <b>956</b>. System A and B then initiate a data communication link using data transmission keys A and B in block <b>958</b>. System A and B then exchange the encrypted data in block <b>960</b>. Once the communications are complete, the process ends in block <b>940</b>. Note that the present invention allows either system to request and subsequent change the selected security level for the data communication link during ongoing communications.

[0054] Now referring to FIG. 10A, a block diagram of a decryption path and decoding path of a peer device in accordance with one embodiment of the present invention is shown. The encryption/decryption device <b>1000</b> a multimode device because it can process unencrypted content (clear channel path <b>1002</b>), content encrypted using a first decryption algorithm (block decryption path <b>1004</b>) and a second decryption algorithm (streaming decryption path <b>1006</b>). Note that a multimode encryption/decryption device <b>1000</b> is not required by the present invention. Also note that the present invention is not limited to a single algorithm for streaming encryption/decryption and a single algorithm for block encryption/decryption as both 3DES and AES algorithms could be implemented within a single embodiment of the present invention for block encryption/decryption. Nor is the present invention limited to a total of two encryption/decryption algorithms. For example, the present invention is capable of providing two or more types of block encryption/decryption and two or more types of streaming encryption/decryption within a single embodiment. The encryption/decryption device <b>1000</b> includes a PCI interface <b>1010</b> communicably coupled to a first buffer <b>1012</b> (first in, first out) and a decryption controller <b>1014</b>. Note that the PCI interface <b>1010</b> can be any standard or high-speed digital interface, such as FireWire, USB-2, Fast Ethernet or AGP interfaces. The first buffer <b>1012</b> is communicably coupled to the clear channel path <b>1002</b>, the block decryption path <b>1004</b> (first decryption algorithm) and the streaming decryption path <b>1006</b> (second decryption algorithm). The clear channel path <b>1002</b>, the block decryption path <b>1004</b> (first decryption algorithm) and the streaming decryption path <b>1006</b> (second decryption algorithm) are communicably coupled to a second buffer <b>1018</b> (first in, first out), which is communicably coupled to an decoder <b>1020</b>, such as an MPEG decoder. The decryption controller <b>1014</b> is communicably coupled to the clear channel path <b>1002</b>, the block decryption path <b>1004</b> (first decryption algorithm), the streaming decryption path <b>1006</b> (second decryption algorithm) and a key manager <b>1016</b>. The key manager <b>1016</b> is communicably coupled to the key storage <b>1022</b>. The security keys are embedded within the hardware of the device <b>1000</b> so that they cannot be compromised by sharing data, such as electronic mail, newsgroup posts, file transfers, etc.

[0055] As shown, the encryption/decryption device <b>1000</b> receives encrypted, compressed digital content (audio/video) <b>1008</b> via the PCI interface <b>1010</b> and places the encrypted, compressed digital content (audio/video) <b>1008</b> in the first buffer <b>1012</b>. The decryption controller <b>1014</b> checks the encrypted compressed digital content (audio/video) <b>1008</b> and determines which path <b>1002</b>, <b>1004</b> or <b>1006</b> will process the content <b>1008</b>. The decryption controller <b>1014</b> also monitors and controls the clear channel path <b>1002</b>, the block decryption path <b>1004</b> (first decryption algorithm) and the streaming decryption path <b>1006</b> (second decryption algorithm). The clear channel path <b>1002</b> receives content from the first buffer <b>1012</b> and may perform some processing on the content before it is placed in the second buffer <b>1018</b>. The decoder <b>1020</b> then receives the content from the second buffer <b>1018</b> and decompresses it for output as unencrypted, decoded digital content (audio/video) <b>1024</b>.

[0056] The block decryption path <b>1004</b> (first decryption algorithm) receives content from the first buffer <b>1012</b> and decrypts the content using a first decryption algorithm before it is placed in the second buffer <b>1018</b> for processing by decoder <b>1020</b>. The block decryption path <b>1004</b> (first decryption algorithm) uses a low to medium speed, high security, standard or proprietary encryption process, such as a 3DES algorithm or an AES algorithm. The block decryption path <b>1004</b> is typically used to decrypt content that is in a file format or other type of data block in a batch or off-line process. The decryption controller <b>1014</b> requests the appropriate security key from the key manager <b>1016</b> and provides the security key to the block decryption path <b>1004</b> for use in decrypting the content.

[0057] The streaming decryption path <b>1006</b> (second decryption algorithm) receives content from the first buffer <b>1012</b> and decrypts the content using a second decryption algorithm before it is placed in the second buffer <b>1018</b> for processing by decoder <b>1020</b>. The streaming decryption path <b>1006</b> (second decryption algorithm) uses a high speed, medium security, standard or proprietary encryption process, such as a LFSR sequence. The streaming decryption path <b>1006</b> is typically used to decrypt content during a real time or near real time on line process. This provides low latency delays for interactive applications, such as gaming and video conferencing. This also reduces hardware complexity to allow the present invention to be easily integrated into portable client devices. The decryption controller <b>1014</b> requests the appropriate security key from the key manager <b>1016</b> and provides the security key to the streaming decryption path <b>1006</b> for use in decrypting the content.

[0058] Referring now to FIG. 10B, a block diagram of an encryption and encoding path of a peer device in accordance with one embodiment of the present invention is shown. As previously described, the encryption/decryption device <b>1000</b> is a multimode device because it can process unencrypted content (clear channel path <b>1052</b>), content encrypted using a first encryption algorithm (block encryption path <b>1054</b>) and a second encryption algorithm (streaming encryption path <b>1056</b>). The encryption/decryption device <b>1000</b> includes an encoder <b>1058</b>, such as a MPEG encoder, for compressing the unencrypted, uncompressed digital content (audio/video) <b>1060</b>. The encoder <b>1058</b> is communicably coupled to the first buffer <b>1062</b> (first in, first out). The first buffer <b>1062</b> communicably coupled to the clear channel path <b>1052</b>, the block encryption path <b>1054</b> (first encryption algorithm) and the streaming encryption path <b>1056</b> (second encryption algorithm). The clear channel path <b>1052</b>, the block decryption path <b>1054</b> (first encryption algorithm) and the streaming decryption path <b>1056</b> (second encryption algorithm) are communicably coupled to a second buffer <b>1064</b> (first in, first out) and an encryption controller <b>1066</b>. The second buffer <b>1064</b> is communicably coupled to a PCI interface <b>1068</b>. The PCI interface <b>1068</b> is also communicably coupled to the encryption controller <b>1066</b>. The encryption controller <b>1066</b> is communicably coupled to the clear channel path <b>1052</b>, the block encryption path <b>1054</b> (first encryption algorithm), the streaming encryption path <b>1056</b> (second encryption algorithm) and the key manager <b>1016</b>, which was previously described in reference to FIG. 10A.

[0059] As shown, the encryption/decryption device <b>1000</b> receives unencrypted, uncompressed digital content (audio/video) <b>1066</b> via encoder <b>1058</b>, which compresses the content and sends the unencrypted, compressed, digital content (audio/video) to the first buffer <b>1062</b>. The encryption controller <b>1066</b> determines which path <b>1052</b>, <b>1054</b> or <b>1056</b> will process the content. The encryption controller <b>1066</b> also monitors and controls the clear channel path <b>1052</b>, the block encryption path <b>1054</b> (first encryption algorithm) and the streaming encryption path <b>1056</b> (second encryption algorithm). Once processed and placed in the second buffer <b>1064</b>, the encrypted, compressed digital content (audio/video) <b>1070</b> is sent out via the PCI interface <b>1068</b>. Note that the PCI interface <b>1068</b> can be any standard or high-speed digital interface, such as FireWire, USB-2, Fast Ethernet or AGP interfaces. The clear channel path <b>1052</b> receives content from the first buffer <b>1062</b> and may perform some processing on the content before it is placed in the second buffer <b>1064</b>.

[0060] The block encryption path <b>1054</b> (first encryption algorithm) receives content from the first buffer <b>1058</b> and encrypts the content using a first encryption algorithm before it is placed in the second buffer <b>1064</b>. The block encryption path <b>1054</b> (first encryption algorithm) uses a low to medium speed, high security, standard or proprietary encryption process, such as a 3DES algorithm or an AES algorithm. The block encryption path <b>1054</b> is typically used to encrypt content that is in a file format or other type of data block in a batch or off-line process. The encryption controller <b>1066</b> requests the appropriate security key from the key manager <b>1016</b> and provides the security key to the block encryption path <b>1054</b> for use in encrypting the content.

[0061] The streaming encryption path <b>1056</b> (second encryption algorithm) receives content from the first buffer <b>1062</b> and encrypts the content using a second encryption algorithm before it is placed in the second buffer <b>1064</b>. The streaming encryption path <b>1056</b> (second encryption algorithm) uses a high speed, medium security, standard or proprietary encryption process, such as a LFSR sequence. The streaming encryption path <b>1056</b> is typically used to encrypt content during a real time or near real time on line process. This provides low latency delays for interactive applications, such as gaming and video conferencing. This also reduces hardware complexity to allow the present invention to be easily integrated into portable client devices. The encryption controller <b>1066</b> requests the appropriate security key from the key manager <b>1016</b> and provides the security key to the streaming decryption path <b>1056</b> for use in decrypting the content.

[0062] Now referring to FIG. 11A, a block diagram of a decryption path and decoding path of a peer device in accordance with another embodiment of the present invention is shown. The encryption/decryption device <b>1100</b> a multimode device because it can process unencrypted content (clear channel path <b>1102</b>), content encrypted using a first decryption algorithm (block decryption path <b>1104</b>) and a second decryption algorithm (streaming decryption path <b>1106</b>). Note that a multimode encryption/decryption device <b>1100</b> is not required by the present invention. Also note that the present invention is not limited to a single algorithm for streaming encryption/decryption and a single algorithm for block encryption/decryption as both 3DES and AES algorithms could be implemented within a single embodiment of the present invention for block encryption/decryption. Nor is the present invention limited to a total of two encryption/decryption algorithms. For example, the present invention is capable of providing two or more types of block encryption/decryption and two or more types of streaming encryption/decryption within a single embodiment. The encryption/decryption device <b>1100</b> includes a PCI interface <b>1110</b> communicably coupled to a first buffer <b>1112</b> (first in, first out) and a decryption controller <b>1114</b>. Note that the PCI interface <b>1110</b> can be any standard or high-speed digital interface, such as FireWire, USB-2, Fast Ethernet or AGP interfaces. The first buffer <b>1112</b> is communicably coupled to the clear channel path <b>1102</b>, the block decryption path <b>1104</b> (first decryption algorithm) and the streaming decryption path <b>1106</b> (second decryption algorithm). The clear channel path <b>1102</b>, the block decryption path <b>1104</b> (first decryption algorithm) and the streaming decryption path <b>1106</b> (second decryption algorithm) are communicably coupled to a second buffer <b>1118</b> (first in, first out), which is communicably coupled to an decoder <b>1120</b>, such as an MPEG decoder. The decoder <b>1120</b> is communicably coupled to a graphics controller <b>1122</b>, which is communicably coupled to an analog copy prevention device <b>1124</b>. The decryption controller <b>1114</b> is communicably coupled to the clear channel path <b>1102</b>, the block decryption path <b>1104</b> (first decryption algorithm), the streaming decryption path <b>1106</b> (second decryption algorithm) and a key manager <b>1116</b>. The key manager <b>1116</b> is communicably coupled to the key storage <b>1126</b>. The security keys are embedded within the hardware of the device <b>1100</b> so that they cannot be compromised by sharing data, such as electronic mail, newsgroup posts, file transfers, etc.

[0063] As shown, the encryption/decryption device <b>1100</b> receives encrypted, compressed digital content (audio/video) <b>1108</b> via the PCI interface <b>1110</b> and places the encrypted, compressed digital content (audio/video) <b>1108</b> in the first buffer <b>1112</b>. The decryption controller <b>1114</b> checks the encrypted compressed digital content (audio/video) <b>1108</b> and determines which path <b>1102</b>, <b>1104</b> or <b>1106</b> will process the content <b>1108</b>. The decryption controller <b>1114</b> also monitors and controls the clear channel path <b>1102</b>, the block decryption path <b>1104</b> (first decryption algorithm) and the streaming decryption path <b>1106</b> (second decryption algorithm). The clear channel path <b>1102</b> receives content from the first buffer <b>1112</b> and may perform some processing on the content before it is placed in the second buffer <b>1118</b>. The decoder <b>1120</b> then receives the content from the second buffer <b>1118</b> and decompresses the content. The graphics controller <b>1122</b> then converts the content from a digital format to an analog format. Next, the analog copy prevention device <b>1124</b> modifies the content so that the output is cannot be copied by standard recording devices. As a result, the encryption/decryption device <b>1100</b> produces a non-copiable analog content (audio/video) <b>1128</b>.

[0064] The block decryption path <b>1104</b> (first decryption algorithm) receives content from the first buffer <b>1112</b> and decrypts the content using a first decryption algorithm before it is placed in the second buffer <b>1118</b> for processing by decoder <b>1120</b>. The block decryption path <b>1104</b> (first decryption algorithm) uses a low to medium speed, high security, standard or proprietary encryption process, such as a 3DES algorithm or an AES algorithm. The block decryption path <b>1104</b> is typically used to decrypt content that is in a file format or other type of data block in a batch or off-line process. The decryption controller <b>1114</b> requests the appropriate security key from the key manager <b>1116</b> and provides the security key to the block decryption path <b>1104</b> for use in decrypting the content.

[0065] The streaming decryption path <b>1106</b> (second decryption algorithm) receives content from the first buffer <b>1112</b> and decrypts the content using a second decryption algorithm before it is placed in the second buffer <b>1118</b> for processing by decoder <b>1120</b>. The streaming decryption path <b>1106</b> (second decryption algorithm) uses a high speed, medium security, standard or proprietary encryption process, such as a LFSR sequence. The streaming decryption path <b>1106</b> is typically used to decrypt content during a real time or near real time on line process. This provides low latency delays for interactive applications, such as gaming and video conferencing. This also reduces hardware complexity to allow the present invention to be easily integrated into portable client devices. The decryption controller <b>1114</b> requests the appropriate security key from the key manager <b>1116</b> and provides the security key to the streaming decryption path <b>1106</b> for use in decrypting the content.

[0066] Referring now to FIG. 11B, a block diagram of an encryption path of a peer device in accordance with one embodiment of the present invention is shown. As previously described, the encryption/decryption device <b>1100</b> is a multimode device because it can process unencrypted content (clear channel path <b>1152</b>), content encrypted using a first encryption algorithm (block encryption path <b>1154</b>) and a second encryption algorithm (streaming encryption path <b>1156</b>). The encryption/decryption device <b>1100</b> includes an analog to digital converter <b>1060</b> for receiving unencrypted, uncompressed, analog content (audio/video) <b>1058</b>, an encoder <b>1158</b>, such as a MPEG encoder, for receiving unencrypted, uncompressed, digital content (audio/video) <b>1062</b>, and a first buffer <b>1068</b> (first in, first out) for receiving unencrypted, compressed, digital content (audio/video) <b>1066</b>. The analog to digital converter <b>1060</b> is communicably coupled to the encoder <b>1064</b>, which is communicably coupled to the first buffer <b>1068</b>. The first buffer <b>1168</b> communicably coupled to the clear channel path <b>1152</b>, the block encryption path <b>1154</b> (first encryption algorithm) and the streaming encryption path <b>1156</b> (second encryption algorithm). The clear channel path <b>1152</b>, the block encryption path <b>1154</b> (first encryption algorithm) and the streaming encryption path <b>1156</b> (second encryption algorithm) are communicably coupled to a second buffer <b>1170</b> (first in, first out) and an encryption controller <b>1172</b>. The second buffer <b>1170</b> is communicably coupled to a PCI interface <b>1174</b>. The PCI interface <b>1174</b> is also communicably coupled to the encryption controller <b>1172</b>. The encryption controller <b>1172</b> is communicably coupled to the clear channel path <b>1152</b>, the block encryption path <b>1154</b> (first encryption algorithm), the streaming encryption path <b>1156</b> (second encryption algorithm) and the key manager <b>1116</b>, which was previously described in reference to FIG. 11A.

[0067] As shown, the encryption/decryption device <b>1100</b> can receive unencrypted, uncompressed analog content (audio/video) <b>1158</b> via analog to digital converter <b>1160</b>, which converts the content to an unencrypted, uncompressed digital content. The encryption/decryption device <b>1100</b> can also receive unencrypted, uncompressed digital content (audio/video) <b>1162</b> via analog to digital converter <b>1160</b> or encoder <b>1164</b>, which converts the content to an unencrypted, compressed digital content. In addition, the encryption/decryption device <b>1100</b> can receive unencrypted, compressed digital content (audio/video) <b>1166</b> via encoder <b>1164</b> or first buffer <b>1168</b>. The encryption controller <b>1172</b> determines which path <b>1152</b>, <b>1154</b> or <b>1156</b> will process the content. The encryption controller <b>1172</b> also monitors and controls the clear channel path <b>1152</b>, the block encryption path <b>1154</b> (first encryption algorithm) and the streaming encryption path <b>1156</b> (second encryption algorithm). Once processed and placed in the second buffer <b>1170</b>, the encrypted, compressed digital content (audio/video) <b>1176</b> is sent out via the PCI interface <b>1174</b>. The clear channel path <b>1152</b> receives content from the first buffer <b>1168</b> and may perform some processing on the content before it is placed in the second buffer <b>1170</b>.

[0068] The block encryption path <b>1154</b> (first encryption algorithm) receives content from the first buffer <b>1168</b> and encrypts the content using a first encryption algorithm before it is placed in the second buffer <b>1170</b>. The block encryption path <b>1154</b> (first encryption algorithm) uses a low to medium speed, high security, standard or proprietary encryption process, such as a 3DES algorithm or an AES algorithm. The block encryption path <b>1154</b> is typically used to encrypt content that is in a file format or other type of data block in a batch or off-line process. The encryption controller <b>1172</b> requests the appropriate security key from the key manager <b>1116</b> and provides the security key to the block encryption path <b>1154</b> for use in encrypting the content.

[0069] The streaming encryption path <b>1156</b> (second encryption algorithm) receives content from the first buffer <b>1168</b> and encrypts the content using a second encryption algorithm before it is placed in the second buffer <b>1170</b>. The streaming encryption path <b>1156</b> (second encryption algorithm) uses a high speed, medium security, standard or proprietary encryption process, such as a LFSR sequence. The streaming encryption path <b>1156</b> is typically used to encrypt content during a real time or near real time on line process. This provides low latency delays for interactive applications, such as gaming and video conferencing. This also reduces hardware complexity to allow the present invention to be easily integrated into portable client devices. The encryption controller <b>1172</b> requests the appropriate security key from the key manager <b>1116</b> and provides the security key to the streaming decryption path <b>1156</b> for use in decrypting the content.

[0070] Those skilled in the art will appreciate that the embodiments and examples set forth herein are presented to best explain the present invention and its practical application and to thereby enable those skilled in the art to make and utilize the invention. However, those skilled in the art will recognize that the foregoing description and examples have been presented for the purpose of illustration and example only. The description as set forth is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching without departing from the spirit and scope of the following claims.