HK1147863B

HK1147863B - Interoperable keychest

Info

Publication number: HK1147863B
Application number: HK11101793.4A
Authority: HK
Inventors: 阿尔诺‧罗伯特; 斯科特‧F‧沃森
Original assignee: 迪斯尼实业公司
Priority date: 2009-07-10
Filing date: 2011-02-23
Publication date: 2015-02-13

Abstract

There is provided a system and method for an interoperable keychest. There is provided a method for use by a central key repository (CKR) or keychest to provide content access authorizations to distributors, comprising receiving a key information file including a first encrypted second key for decrypting with a first key and a content identification, decrypting the first encrypted second key using a first key to retrieve the second key, receiving, from a distributor, a key request including the content identification, encrypting the second key using a third key to generate a second encrypted second key, and transmitting the second encrypted second key to the distributor in response to the receiving of the key request. In this manner, key management for protected distributors using different DRM schemas or systems may be simplified and made interoperable.

Description

Interoperable key locker

Background

Technical Field

The present invention relates generally to digital media. More particularly, the present invention relates to digital rights management for digital media.

Technical Field

Although digital media distribution has grown in popularity and become a viable alternative to many consumers purchasing retail physical media, there are still considerable obstacles to the consumer before they can fully accept digital media without reservation. Many of these reservations revolve around limited interoperability between different playback devices or service providers, and the possibility that media files may become inoperable in the future due to new formats or protection schemes. For example, perfecting a digital media distribution channel may use incompatible media formats and proprietary DRM systems, and the closing or termination of video offerings due to financial difficulties or changes in corporate ownership may leave the consumer with media files that can no longer be consumed.

Accordingly, there is a need for interoperable protected content that can withstand the changes of the distribution market and provide continuous services to consumers, regardless of the original distribution channel and the original media file format used. In this manner, consumers can easily switch service providers, use protected media in a variety of playback devices, and maintain confidence that protected content is guaranteed for future playback. Similarly, content producers can maintain confidence in relying on digital distribution of protected media as a viable and sustainable business model. However, to ensure such interoperability in the most straightforward approach by simply specifying a single DRM method, many existing DRM systems and distribution channels may need to fundamentally modify established and proven operational procedures — a proposal that may find little aggressiveness in the marketplace. In addition, this would result in a single point of vulnerability.

Accordingly, there is a need to overcome the deficiencies and inadequacies in the art by providing a way to interoperate digital media in different service providers and media devices that requires minimal disruptive changes to existing digital rights management paradigms, distribution patterns, and consumption patterns, particularly with respect to key management.

Summary of The Invention

A system and method for an interoperable keylocker substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.

According to one aspect of the present invention, there is provided a method for online registration of a digital receipt associated with content, comprising: executing a service for acquiring content from the first distributor; receiving a digital receipt associated with the content from the first dispenser, wherein the digital receipt includes information about the transaction; and sending the digital receipt to a Central Key Repository (CKR) for online registration of the digital receipt associated with the content.

Preferably, the digital receipt comprises data about the consumer, data about the first dispenser, data about the transaction comprising the type of transaction and the date of the transaction, metadata about the content or data about the CKR.

Preferably, the method further comprises receiving a return value from the CKR indicating success or failure of the online registration process.

Preferably, the portion of the digital receipt is further encrypted prior to receipt of the digital receipt or is further digitally signed prior to receipt of the digital receipt.

Preferably, the encrypted portion of the digital receipt is encrypted using the public key of the CKR.

Preferably, sending the digital receipt to the CKR is through a first dispenser.

Preferably, the method further comprises obtaining a first Digital Rights Management (DRM) license from the first distributor for playback of the content.

Preferably, the method further comprises: sending a digital receipt to the second dispenser; and receiving a second DRM license from the second distributor to play back the content, the second DRM license granted in response to the second distributor validating the sent digital receipt using CKR.

Preferably, the CKR also applies one or more business rules to information included in the digital receipt to verify the validity of the transmitted digital receipt.

Preferably, the sending step further sends a user credential, and wherein the second distributor further authenticates the user credential to verify the validity of the sent digital receipt.

Preferably, the sending step further sends a user credential, and wherein the CKR further authenticates the user credential to verify the validity of the sent digital receipt.

Preferably, the user credentials are usable for authentication using a plurality of dispensers including the first dispenser and the second dispenser, and wherein the CKR further verifies the validity of the transmitted digital receipt by verifying the user credentials against a third party authentication server.

Preferably, the second distributor further queries CKR for a further online registration of a digital receipt authenticated using the same digital voucher, and wherein a further DRM license is received from the second distributor further comprising a content ownership key usable with said second distributor to derive said further online registration.

Preferably, the method further comprises performing a further service to obtain the second DRM license from the second distributor before receiving the second DRM license.

Preferably, the method further comprises: resending the digital receipt to the CKR for evidence of providing the service; obtaining an ownership key from the CKR in response to the CKR verifying the validity of the resent digital receipt using the online registration, thereby confirming evidence of the transaction; and initiating playback of the content using the ownership key derived from the CKR.

Preferably, the method further comprises: resending the digital receipt to the CKR for evidence of providing the service; selecting a third dispenser from a plurality of dispensers provided by the CKR, wherein the plurality of dispensers are verified by the CKR to have distribution privileges for content associated with the digital receipt; and receiving a third DRM license from the third distributor to playback the content, the third DRM license being granted in response to the CKR's validity to forward the resent digital receipt to the third distributor using the online registry, thereby confirming the proof of the transaction.

Preferably, the resending step further sends user credentials, and wherein the CKR further authenticates the user credentials to verify the validity of the resent digital receipt.

Preferably, the re-sending step further sends a user credential, and wherein the third distributor further authenticates the user credential to verify the validity of the re-sent digital receipt.

According to another aspect of the present invention, there is provided a method for use by a first distributor to enable clients to playback content encrypted using an ownership key, comprising: receiving a digital receipt associated with the content from the client, wherein the digital receipt includes information relating to a transaction performed by the client with the second distributor for enabling playback of the content; interrogating a Central Key Repository (CKR) to verify the validity of the received digital receipt using a corresponding online registration of digital receipts; generating a DRM license usable by the client to obtain the ownership key through the first distributor; sending the DRM license to the client; and providing the ownership key to the client in response to the client using the DRM license.

Preferably, the method further comprises transmitting the content encrypted using the ownership key to the client.

Preferably, the method further comprises: interrogating the CKR for additional online registrations of digital receipts authenticated using the same user credentials as the received digital receipts; generating a further DRM license usable by the client to derive an ownership key for content associated with the further online registration; and sending the further DRM license to the client.

According to yet another aspect of the present invention, there is provided a method of distributing media content to a distributor, comprising: acquiring a first key, a second key and content; encrypting the second key using the first key to generate an encrypted second key; encrypting the content using the second key to generate encrypted content; generating a key information file including the encrypted second key; generating a universal file comprising the encrypted content and a first network address of a Central Key Repository (CKR); providing a key information file for a memory in the CKR; and providing the common file to the distributor.

Preferably, at least two distributors receiving the universal file use different Digital Rights Management (DRM) schemes for distributing the content to the consumers.

Preferably, obtaining the first key comprises receiving the first key from a certificate authority trusted by the CKR.

Preferably, obtaining the second key comprises generating the second key.

Preferably, the method further includes acquiring content information related to the content, wherein the key information file is generated by including the content information in the key information file.

Preferably, generating the universal file includes encoding the content prior to encryption of the content.

Preferably, generating the common file includes formatting the encrypted content, the first network address, and the content information using an MPEG-4 container format.

Preferably, the content information includes a Universally Unique Identifier (UUID), an international standard audiovisual material number (ISAN), and a content owner identification.

Preferably, the method further includes obtaining content information related to the content, wherein the common file is generated by including the content information in the common file.

Preferably, the contents information includes a Universally Unique Identifier (UUID) and an international standard audiovisual material number (ISAN).

Preferably, providing the key information file to the memory in the CKR also uses the CKR to transcrypt the key information file such that the distributor can decrypt the encrypted second key using a third key related to the first key and retrieve the second key.

Preferably, the first key is a public key of the distributor and wherein the third key is a private key of the distributor.

Preferably, the first key is a symmetric key, and wherein the third key is a symmetric key available to the distributor.

According to yet another aspect of the present invention, there is provided a universal file packager for distributing media content to a distributor, comprising a processor configured to: acquiring a first key, a second key and content; encrypting the second key using the first key to generate an encrypted second key; encrypting the content using the second key to generate encrypted content; generating a key information file including the encrypted second key; generating a universal file comprising the encrypted content and a first network address of a Central Key Repository (CKR); providing a key information file for a memory in the CKR; and providing the common file to the distributor.

Preferably, at least two distributors receiving the universal file use a Digital Rights Management (DRM) scheme different from other schemes used for retrieving content from the universal file.

Preferably, the processor obtains the first key by receiving the first key from a certificate authority trusted by the CKR.

Preferably, the processor obtains the second key by generating the second key.

Preferably, the processor is further arranged to obtain content information associated with said key, wherein the processor is further arranged to generate the key information file by including the content information in the key information file.

Preferably, the processor is arranged to encode the content before generating the generic file.

Preferably, the processor is arranged to generate the universal file by formatting the encrypted content, the first network address and the content information using an MPEG-4 container format.

Preferably, the content information includes a Universally Unique Identifier (UUID), an international standard audiovisual material number (ISAN) and a content owner identification.

Preferably, the processor is further arranged to obtain content information relating to the content and to generate the common file by including the content information in the common file.

Preferably, the processor is arranged to provide a key information file to the memory in the CKR such that the CKR transcribes the key information file so that the distributor can decrypt the encrypted second key using a third key related to the first key and retrieve the second key.

According to another aspect of the present invention, there is provided a method for use by a distributor in obtaining content access authorization from a Central Key Repository (CKR), comprising: receiving a user request from a user device for accessing encrypted content, the user request including a content identification; sending a key request to the CKR in response to receipt of the user request, the key request including the content identification; receiving an encrypted first key from the CKR in response to the sending of the key request; decrypting the encrypted first key using the second key to retrieve the first key; and providing, in response to receipt of the user request and for use by the user device to decrypt the encrypted content using the first key, a DRM license for the encrypted content to the user device using the first key.

Preferably, the method further comprises: receiving a universal content file including the encrypted content file from the media content packager; and transmitting the encrypted content file to the user device.

Preferably, the universal content file further comprises a first network address of a Central Key Repository (CKR).

Preferably, the method further comprises re-acquiring the first network address before sending the key request to the CKR, and wherein said sending sends the key request to the first network address.

Preferably, the first network address is a Uniform Resource Locator (URL) for access over the internet.

Preferably, the method further comprises: generating a second key; and sending the second key to the CKR before sending the key request to the CKR.

Preferably, the method further comprises: receiving a second key from the CKR before receiving the encrypted first key from the CKR; and storing the second key.

Preferably, the key request further comprises user information and a service type.

Preferably, the method further comprises: code associated with a medium storing content identified in relation to the content is received from a user device, wherein the key request includes the code.

Preferably, receiving the encrypted first key from the CKR comprises receiving a key information file comprising the encrypted first key, a Universally Unique Identifier (UUID), and an international standard audio-visual data number (ISAN).

Preferably, the key information file further comprises access rights or usage rules associated with the key request.

Preferably, the DRM license further includes access rights or usage rules received from the key information file.

According to another aspect of the present invention there is provided a distributor for obtaining content access authorization from a Central Key Repository (CKR), comprising a processor arranged to: receiving a user request from a user device for accessing encrypted content, the user request including a content identification; sending a key request to the CKR in response to receiving a user request, the key request including a content identification; receiving an encrypted first key from the CKR in response to sending a key request; decrypting the encrypted first key using the second key to retrieve the first key; and in response to receiving the user request and for use by the user device to decrypt the encrypted content using the first key, providing the DRM license for the encrypted content to the user device using the first key.

Preferably, the processor is further configured to: receiving a universal content file including the encrypted content file from the media content packager; and transmitting the encrypted content file to the user device.

Preferably, the processor is further arranged to retrieve the first network address and send the key request to the first network address before sending the key request to the CKR.

Preferably, the processor is further configured to: generating a second key; and sending a second key to the CKR before sending the key request to the CKR.

Preferably, the processor is further configured to: receiving a second key from the CKR before receiving the encrypted first key from the CKR; and storing the second key.

Preferably, the processor is further configured to: code associated with a medium storing content identified in relation to the content is received from a user device, wherein the key request includes the code.

Preferably, receiving the encrypted first key from the CKR comprises receiving a key information file comprising the encrypted first key, a Universally Unique Identifier (UUID), and an international standard audiovisual data number (ISAN).

Brief description of the drawings

The features and advantages of the present invention will become more readily apparent to those of ordinary skill in the art after reviewing the following detailed description and accompanying drawings, wherein:

FIG. 1 illustrates a system for generating files for use with an interoperable keylocker, in accordance with an embodiment of the present invention;

FIG. 2 illustrates a system for providing a digital receipt to a client for use with an interoperable keylocker, according to one embodiment of the invention;

FIG. 3 illustrates a system for obtaining protected Digital Rights Management (DRM) licenses for interoperability between different DRM systems through an interoperable key locker, according to one embodiment of the invention;

FIG. 4a illustrates a system for playback of protected media using an interoperable keylocker independent of the original distribution media distributor, in accordance with one embodiment of the present invention;

FIG. 4b illustrates a system for recovering indirect protected media using an interoperable keylocker, in accordance with an embodiment of the present invention;

FIG. 5 shows a flowchart describing steps by which online registration of digital receipts associated with content can be used with a Central Key Repository (CKR) to enable interoperable playback of content independent of the original distributor, in accordance with one embodiment of the present invention;

FIG. 6 shows a flowchart describing steps by which media content may be distributed to a media distributor, in accordance with one embodiment of the present invention;

FIG. 7 shows a flowchart depicting steps by which a Central Key Repository (CKR) may provide content access authorization to a media distributor, in accordance with one embodiment of the present invention; and

fig. 8 shows a flow chart describing steps by which a media distributor may obtain content access authorization from a Central Key Repository (CKR), in accordance with one embodiment of the present invention.

Detailed description of the invention

The present invention is directed to a system and method for a universal file packager (packager) for use with an interoperable keylocker. The following description contains specific information pertaining to the implementation of the present invention. Those skilled in the art will recognize that the present invention may be implemented in a manner different from that specifically discussed in the present application. In addition, some of the specific details of the invention are not discussed in order not to obscure the invention. Specific details not described in the present application are within the knowledge of a person of ordinary skill in the art. The drawings in the present application and their accompanying detailed description are directed to merely exemplary embodiments of the invention. In the interest of brevity, other embodiments of the invention that use the principles of the present invention are not specifically described in the present application and are not specifically illustrated by the present drawings.

FIG. 1 illustrates a system for generating files for use with an interoperable keylocker, according to one embodiment of the invention. The environment 100 of fig. 1 includes an owner (title owner) 110, an owner ID (identifier) 111, an ownership ID116, a certificate authority 120, a modulator 130, a key locker 160, and a media distributor 170. The ownership owner 110 includes a title 115 and ownership metadata 118. Certificate authority 120 includes certificate 121. Certificate 121 includes a key locker public key 122. The modulation machine 130 includes a key generator 131, an ownership key 132, a general file packager 135, a general file 140, and a key information file 150. The universal file 140 includes an ownership ID116, metadata 117, cryptographic ownership 145, and a keylocker URL (uniform resource locator) 146. The key information file 150 includes an ownership owner ID111, an ownership ID116, encrypted data 153, and an encrypted ownership key 152. The key locker 160 comprises a processor 158 and a memory 159. Memory 159 includes a preparer API (application programming interface) 161, a key information database 162, a customer database 163, a business database 164, a key locker private key 165, a distributor public key database 166, a distributor database 167, and a provider API 157. Media distributor 170 includes a transcribed key information file 151, a distributor private key 175, and a local DRM (digital rights management) system 172.

The ownership owner 110 may include a manufacturer, broadcaster, copyright owner, author, or assignee of ownership 115, such as an individual artist or creator, a media group, a movie production studio, an animation studio, a television studio, or a movie distributor. The ownership rights 115 may then include creative media work or schemes such as music writings or albums, radio programs, video clips, full-length movies or animations, drama or television series episodes, interactive video games, or any other type of audiovisual work or content. The ownership metadata 118 may then be provided in more detail to describe the ownership rights 115, such as to provide human readable ownership names, specific media categories, content genres, media formats, ratings, and other information useful for classifying and identifying ownership rights to the ownership rights 115. Although the ownership metadata 118 is shown in fig. 1 as being provided by the ownership owner 110, alternative embodiments may instead use the modulation machine 130 or another third party to generate the ownership metadata 118.

In addition, the ownership owner 110 and the ownership 115 are each uniquely identified by the ownership owner ID111 and the ownership ID116, respectively. These identifiers may also be included in the ownership metadata 118. The ownership ID116 may be particularly suited for a combination of an international standard audiovisual material number (ISAN) (if available) and a Universally Unique Identifier (UUID) based cryptographic function, such as secure hash algorithm 1 (SHA-1), although any suitable algorithm for selecting a unique identifier may be employed. In this way, different ownership owners that do not communicate with each other can still generate ownership IDs that strongly ensure uniqueness. Alternatively, a centralized authority may distribute unique identifiers to requestors, ensuring uniqueness by maintaining a database of all identifiers.

Once the above identifiers, metadata and ownership files are arranged in order, the ownership owner 110 may transmit them to the general file packager 135 of the preparer 130 for incorporation into a distribution channel serving the general public. This transmission to the modulation machine 130 may be accomplished by any suitable communication means, preferably in a safe manner that mitigates the risk of third party leakage. For example, various protected internet protocols may be used, such as FTP (file transfer protocol), Secure Sockets Layer (SSL), Secure Shell (SSH), or another protocol. Alternatively, the data may be written onto physical media for transmission by mail or in person to the modulation machine 130.

The ownership owner 110 and the modulation machine 130 are shown in fig. 1 as separate entities, as the process of preparing ownership for encoding and distribution may be outsourced to third party equipment for efficiency or other reasons. However, alternative embodiments may allow the ownership owner 110 to also assume the functions of the modulator 130, which may be more convenient for smaller media unit operations. In this case, the ownership owner 110 and the modulation machine 130 are owned by the same upper layer and their functions may be incorporated into a single server or cluster of computers.

The key generator 131 provides encryption keys to the universal file packager 135 to support protection of content through encryption. Without applying some protection to the ownership rights 115, enforcing the license terms and preventing unauthorized copying becomes difficult because the consumer has direct access to the unprotected media files. Thus, as shown in fig. 1, the key generator 131 generates a symmetric encryption key-ownership key 132 to encrypt and decrypt the ownership 115. By limiting access to the ownership key 132 to the range of authorized media applications having appropriate DRM licenses, consumers can still enjoy viewing or listening to the ownership 115 without directly accessing the ownership 115 in an unprotected form.

Although longer key lengths and stronger encryption algorithms for the ownership key 132 may provide greater security against spoofing techniques, decoding complexity may also lead to significant contradictory concerns. This concern is particularly acute for mobile devices that have limited battery life, memory, and processing resources. Thus, to encrypt the ownership key 132, a balanced compromise such as Advanced Encryption Standard (AES) may be selected to provide reasonably strong security with fast decode time.

To securely transfer the ownership key 132 from the modulation machine 130 for access by the key locker 160, an asymmetric cryptographic key pair generated by the certificate authority 120 is used, as shown in fig. 1. The key pair may also be generated by the key locker 160 and the certificate issued by the certificate authority 120. For example, a public key and private key pair may use a 2048 bit RSA key, e.g., in accordance with public key cryptography standard #1 (PKCS # 1). The public key of the key pair is included in the digital certificate 121. By retrieving the key locker public key 122 from the certificate 121, the universal file wrapper 135 may encrypt the ownership key 132 using the key locker public key 122, resulting in an encrypted ownership key 152, such that only the owner of the key locker 160-corresponding key locker private key 165 may decrypt the encrypted ownership key 152. The certificate authority 120 acts as a trusted third party in fig. 1, ensuring that the key locker public key 122 provided in certificate 121 is properly bound to an entity called a key locker 160.

Certificate authority 120 may, for example, comply with release 3 x.509 certificate standards. To verify the identity of the certificate authority 120, the modulation machine 130 may also have a pre-loaded set of certificates that guarantee the identity of a trusted third party, such as the certificate authority 120. Mutual authentication may also be implemented such that certificate authority 120 is responsive only to authorized modulators, media distributors, or service providers and other interested parties. Although only a single certificate authority is shown in FIG. 1, alternative embodiments may use a hierarchical system of certificate authorities other than X.509 or alternative trust systems such as peer-regulated trust networks.

In this manner, the keylocker 160 acts as a Central Keystore (CKR) that retains ownership keys in an encrypted form in a key information file. Through the modulator API161, a content modulator, such as modulator 130, may submit an encrypted ownership key in a key information file container, such as key information file 150. These key information files containing encrypted ownership keys, e.g., encrypted ownership key 152, encrypted data or metadata, e.g., encrypted data 153, and associated content information, e.g., ownership owner ID111 and ownership ID116, may be stored in a database, e.g., key information database 162. For the modulator 130 to access the modulator API161, standard web services may be exposed for key exchange by the key locker 160 using Simple Object Access Protocol (SOAP) and by the secure hypertext transfer protocol (HTTPS) using the secure Transport Layer (TLS) with Diffie-Hellman compliant PKXD # 3. This same secure communication means or variation using different parameters may also be used for the other communication paths shown in fig. 1 and the following figures. In addition, security measures such as limiting the incoming Internet Protocol (IP) address range or Media Access Control (MAC) address range to well-known values may also be implemented to further protect against unauthorized access.

As previously discussed, the encrypted ownership key 152 is encrypted using the key locker public key 122. Because the key locker 160 is the owner of the corresponding private key, the key locker private key 165, it is free to encrypt and access all ownership keys submitted to the key information database 162 in the manner discussed above. Using the processor 158 to interpret requests received through the preparer API161 and the provider API157 in memory 159, the key locker 160 can provide robust key storage and distribution services for authorized preparers and media distributors, also referred to as service providers or content providers. In the other direction, authorized distributors such as media distributor 170 can use their own asymmetric key pairs to request these ownership keys in encrypted form through provider API157 to securely generate DRM licenses for delivery to consumer media applications and devices. Thus, the original key information file from the key information database 162 is decrypted and encrypted or transcribed using an encryption key applicable to each particular media distributor to produce a transcribed key information file, such as transcribed key information file 151.

In fig. 1, this key file transcription may be accomplished by having key locker 160 aggregate the public keys of all media distributors, e.g., each distributor 170, in a distributor public key database 166, each media distributor possessing its own corresponding private key, e.g., distributor private key 175. The media distributor may generate its own key pair using standard Public Key Infrastructure (PKI) methods. However, alternative embodiments may use alternative encryption arrangements, for example, where the key locker 160 generates a public/private key pair and provides the private key to each media distributor using a secure communication channel. As before, using the key locker public key 122, a certificate authority 120 or another trusted third party may be used to provide a trusted certificate that ensures a legitimate binding between the public key and its associated mentioned identity.

As shown in the key locker 160, several additional databases are available, including a customer database 163, a business database 164, a distributor database 167, an offer database 168, and a modulator database 169. These databases can be used to implement various business rules from the side of the keylocker, to register media transcriptions and related rights performed by consumers, to register consumer authentication data, and to ensure that only authorized providers and media distributors can interact with the keylocker according to different business agreements. For example, after each successful online transaction, a record may be stored in the transaction database 164 indicating the date and time of sale, price paid, type of purchase, whether leased, permanent purchase, redeemed or reserved, whether the redeem code provided was used multiple times, associated identifiers such as customer, client, device ID, and other details. Thus, the keylocker 160 may be able to enforce rental time periods, rental count limits, and other business rules as needed. Distributor database 167 can track which media distributors have privilege to access which key information files because key locker 160 can support several different associated or non-associated media distributors using different content licensing protocols. The consumer database 163 may act as a rights library that allows consumers to access and unlock protected media files without being restricted to a particular media distributor, as discussed further below in FIG. 2, and also include authentication information to allow consumers to authenticate among multiple distributors using a single or multiple authentication schemes, such as an ownership authentication scheme from a unique distributor or a more open solution such as OpenID. Additionally or alternatively, the key locker 160 may include a device database, not shown in fig. 1, that lists media devices that may be associated with a particular consumer, allowing modes based on binding to the particular device rather than the particular consumer or allowing modes based on binding to the device and the consumer. In general, the device database works similarly to and may be associated with the consumer database 163. The offer database 168 may associate ownership with particular usage rules to support multiple business models, such as rental, reservation, and purchase. The modulator database 169 may ensure that only authorized media modulators may upload key information files to the key locker 160.

The focus is transferred from the key information file 150 to the universal file 140, the universal file 140 also being generated by the universal file packager 135 for distribution to the media distributor and ultimately to the consumer. The name "universal file" describes such a property: even if the media distributors use different DRM systems, the same files are distributed to the consumers and may be interoperable in different media distributors with the help of CKR-key locker 160. As shown in fig. 1, the ownership 115 is encrypted with the ownership key 132 to create an encrypted ownership 145 accompanied by identification data including the ownership ID116, metadata 117, and a keylocker URL 146. The metadata 117 may include, for example, components of ownership metadata 118. The keylocker URL146 acts as a pointer or network address to indicate where to find the keylocker storing the associated key information file 150 so that the encrypted file 145 can be decoded using the ownership key stored in the key information file 150. In the case of FIG. 1, the keylocker URL146 will point to the keylocker 160. It should be noted that the keylocker URL may simply point to a redirect server using RUL redirection to flexibly redirect keylocker traffic. In addition, the URL form is chosen to use SOAP to connect with a web service accessible over the Internet, but alternative web addressing protocols may also be used. The components of the universal file 140 may be embedded in a standard container format such as an MPEG-4Part14 or MP4 container file. Alternatively, if the ownership rights 115 are provided in an uncompressed format, the modulation machine 130 may use video or audio compression before encrypting the ownership rights 115 using, for example, MPEG-4Part10 or h.264. After the generic file 140 is generated, it may be provided to the media distributor 170.

Once the media distributor 170 receives the universal file 140, it may immediately request the relevant key information file from the key locker URL146, or may delay the request until the consumer or client actually requests the universal file 140. In either case, the media distributor 170 queries the key locker 160 using, for example, SOAP over HTTPS as discussed previously, to request the information contained in the associated key information file associated with the ownership ID 116. The keylocker 160 may then search the key information database 162 to find the key information file 150 stored there with the same ownership ID116, apply all relevant business logic rules to determine whether permission to distribute the file should be granted, and provide the transcribed key information file 151 if such determination is positive. The transcribed key information file 151 may look similar to the key information file 150, except that the encrypted ownership key 152 is encrypted using the public key of the media distributor 170 instead of the public key of the key locker 160, the key locker public key 122. As previously discussed, the transcription step may be supported by a key locker 160 that collects all media distributor's public keys in advance into a distributor public key database 166.

To avoid continually retrieving the most recently transcribed key information file from the keylocker, the media distributor may store a local cache of transcribed key information files to avoid unnecessarily burdening the keylocker resources. To keep the cached key information file updated, requests for changes that have occurred since a previous key information access may be requested from the key locker periodically or on demand. Alternatively, the key locker may actively send updates to the media distributor.

Once media distributor 170 transcribes key information file 151 and universal file 140, it can use them in conjunction with distributor private key 175 and local DRM system 172 to provide the media file to the client in a protected manner with minor modifications (if any) to any existing DRM system infrastructure that may have replaced media distributor 170. The media distributor 170 may use its own private key, the distributor private key 175, to access the ownership key 132 from the transcribed key information file 151 and feed such ownership key 132 to the local DRM system 172. The local DRM system 172 may then generate an appropriate DRM license that contains usage rules and an ownership key 132 encrypted using its own security protocols. Once the consumer receives the universal file 140 and the local DRM license, he can consume the media contained in the universal file 140, as permitted by the usage rules.

In this way, the barriers to input using the universal file format and interoperable keylockers are minimized to participating media distributors, encouraging the adoption of a wider distribution channel and all the benefits of providing enhanced interoperability to consumers. By helping to address interoperability and usability concerns with respect to digital distribution media and by providing digital receipts within the consumer's control as described below in fig. 2, the consumer may feel authorized rather than limited by the digital distribution, which may in turn translate into higher sales and greater consumer satisfaction.

Although in fig. 1 the ownership owner 110, ownership 115, certificate authority 120, modulation machine 130, key locker 160, and media distributor 170 are shown as single instances, alternative embodiments may include several instances of each entity. For example, the universal file 140 may encompass several different ownership rights as editors, as part of an album, or as alternative tracks. Similarly, the key information file 150 may store several associated ownership keys. The keylockers may also be scaled to suit particular organizational needs. For example, a large studio with many movie units and subdivisions may decide to dedicate a different keylocker for each studio department, or may prefer to have all departments served by one large consolidated keylocker. Alternatively, several different studios or companies may share a single keylocker, or outsource keylocker operation and maintenance to third party entities, especially for smaller studios. Another possibility is a large centralized keylocker operated by a third party to which the studio submits the key information file. As mentioned above, URL redirection may also be used for flexible keylocker redirection, enabling service load balancing, fast migration, and other features. The keylockers may also share information with other keylockers if appropriate protocols and security procedures are appropriate. That is, the keylockers may be centralized or decentralized as needed, but a centralized keylocker with access to a large database of key information may provide more efficient services to clients that have trades with multiple media distributors.

FIG. 2 illustrates a system for providing a digital receipt to a client for use with an interoperable keylocker, according to one embodiment of the invention. Environment 200 of fig. 2 includes key locker 260, media distributor 270, distributor ID271, client 280, client ID281, common client ID286, display 288, and backup storage 289. Keylocker 260 includes key information database 262, consumer database 263, business database 264, keylocker private key 265, distributor public key database 266, distributor database 267, quote database 268, client API256, and provider API 257. Because there is no interaction with the modulator in fig. 2, the corresponding modulator API161 and modulator database 169 in fig. 1 are omitted from fig. 2 for simplicity, but may still be present in the key locker 260. Media distributor 270 includes universal file 240, transcribed key information file 251, local DRM server 272, DRM license 273, distributor private key 275, and processor 276. The universal file 240 includes an ownership ID216, metadata 217, encrypted ownership 245, and a keylocker URL 246. The transcribed key information file 251 includes an ownership owner ID211, an ownership ID216, and an encrypted ownership key 252. The DRM license 273 includes an ownership ID216, an encrypted ownership key 274, a client ID281, and usage rules 277. Client 280 includes native DRM client 282, client media application 283, protected media path decoding engine 299, and digital receipt 285. Digital receipt 285 includes ownership ID216, distributor ID271, client ID281, common client ID286, consumer ID284, and business information 287. With respect to fig. 2, it should be noted that the keylocker 260 corresponds to the keylocker 160 in fig. 1 and the media distributor 270 corresponds to the media distributor 170 in fig. 1. Although the keylockers 260 of fig. 2 do not depict processors or memory as in the keylockers 160 of fig. 1, it may be assumed that they exist to support the operation of APIs and other logical operations of the keylockers 260.

Fig. 2 transfers focus from the owner of ownership and the modulation machine in fig. 1 to the media distributor and the client in fig. 2. More specifically, fig. 2 shows how a consumer or client can actually use the generic file, key information file, and CKR or keylocker concepts introduced in fig. 1 to access media files for final playback on the display 288. In addition, FIG. 2 introduces the concept of a digital receipt, shown as digital receipt 285, which can serve as proof of purchase or proof of business for reactivating protected media content even if, for example, the client loses the originally retrieved protected media file or even if the client switches media distributors.

The contents of the common file 240 and the transcribed key information file 261 have been described in some detail by the corresponding common file 140 and transcribed key information file 151 in FIG. 1. The transcribed key information file 251 may be provided to the media distributor 271 by an entity having a distribution agreement with the media distributor 271, e.g., an entity similar to the owner of ownership 110 of fig. 1, along with the key locker 260 for the transcription step. The processor 276 of the media distributor 270 may use with the distributor private key 275 to decrypt the encrypted ownership key 252 for use at the local DRM server 272. Local DRM server 272 executing on processor 276 may then generate DRM license 273 for distribution to the authorized client requesting universal file 240 using all of the inputs indicated in fig. 2. The encrypted ownership key 274 may be protected using the protection system provided by the local DRM server 272, effectively changing the encryption partner of the media distributor 270 from the key locker 260 to the client 280. This step may be viewed as a further transcription step similar to the key locker 260 providing a key information file transcribed for a particular media distributor, but the media distributor 270 instead provides a DRM license with an ownership key transcribed for a particular client.

Examining the DRM license 273, an encrypted ownership key 274 corresponding to the ownership key that may be used to encrypt the universal file 240 may be included. The DRM license 273 also includes identification information, including the client or client ID281 to which the DRM license applies, and the associated media ownership or universal file or ownership ID 216. Additional information may also be embedded with the DRM license 273, such as the distributor ID271, common client ID286, consumer ID284, usage rules 277 and business information 284 indicated in fig. 1.

Turning to client 280, client 280 may include a personal computer, media player, set-top box, video game console, mobile phone, portable media player, or any other device that interacts with media distributor 270. The client 280 may also include a client media application 283 for browsing, purchasing, playback, and other services with digital media provided by the media distributor 270. After the consumer decides to purchase, lease or otherwise obtain universal file 240 for playback on client 280 through the digital service, media distributor 270 may process the service through interaction with the financial institution to charge the amount of the commitment or internally subtract a pre-paid point commitment amount or other currency, generate DRM license 273 as described above, and provide universal file 240 and DRM license 273 to client 280 through local DRM server 272. Additionally, records of digital services can be deposited into the services database 264 through the provider API257 of the key locker 260.

After client 280 receives universal file 240 and DRM license 273, client 280 may use DRM license 273 in conjunction with native DRM client 282 to decrypt encrypted ownership 245 in universal file 240 for consumption by playback using protected media path decoding engine 299 output to display 288, which display 288 may also include speakers for audio content. Accordingly, the consumer may view the requested media on the display 280.

While there is a universal file 240 and DRM license 273 that allows client 280 to playback encrypted ownership 245 while local DRM client 282 is able to interact with DRM server 272, there may be instances where one or more of the above elements are missing to client 280, where the user needs to use an entirely different client, or where the user needs to use a different media distributor. To ensure these possibilities, media distributor 270 may also provide client 280 with a secure digital receipt 285. If the consumer needs to deal with the above listed conditions, the digital receipt 285 can be retrieved and provided to the optional media distributor or keylocker 260 as proof of purchase, to retrieve the universal file again, to retrieve a new DRM license, or even both, as the conditions may require.

As shown in fig. 2, client 280 actively secures data receipt 285 by copying to backup memory 289, which may comprise a Universal Serial Bus (USB) storage device, and registering with an associated CKR or keylocker 260 via client API256 for deposit of the digital receipt into consumer database 263. For example, a web interface may be provided to allow data receipts to be uploaded directly to the keylocker 260 through a client API256, the client API256 being similar to the SOAP web service where the provider API257 exposes HTTPS protection. A third party may provide and maintain backup storage 289, for example, by providing an online backup service or a network-accessible email server. In particular, if a digital receipt is provided to the user via a registered email address, the user's email account may effectively be replaced with a backup repository of digital receipts.

Alternatively, after the user completes the digital service, the client media application 283 may prompt the user to automatically register a digital receipt online with the key locker 260. The key locker 260 may then provide a return value to the client 280 indicating the success or failure of the digital receipt registration process.

Digital receipt 285 contains several fields related to the identity of the user, resulting in the creation of a digital receipt. Client ID281 identifies the consumer or device associated with the particular DRM system implemented by local DRM client 282 and local DRM server 272. Consumer ID284 and distributor ID271 indicate the particular consumer associated with a particular media distributor, while common client ID286, an optional section, may globally identify a user in a general sense. The common client ID286 may be connected to an external user authentication system, such as OpenID, which may be used for authentication in several media distributors rather than in just a single media distributor. Because not all users handle such a common client ID, it may be omitted for such users, or an alternative identifier may be created and provided to the user. However, if a common client ID286 is provided, the keylocker 260 may be able to identify all receipts in the consumer database 263 that are considered consumer attributes, regardless of the media distributor, which may prove useful to users with large collections of media among several different media distributors.

Digital receipt 285 also contains several fields related to the business that created the digital receipt. The ownership ID216 indicates a specific general file referred to by the digital receipt, and the service information 287 may contain specific information about a service such as a service date, a service type, or a quote ID, and metadata about the content referred to by the ownership ID 216. The date of the service may include a particular date and time that the service occurred, while the type of service may indicate, for example, whether the service was part of a full purchase, lease, subscription plan, or another type of service included. The metadata may include information similar to metadata 117 of FIG. 1, such as ownership, genre, rating, and other data. Digital receipt 285 may also optionally contain information about keylocker 260, such as a keylocker URL or optionally information about a server used to register digital receipt 285 in the form of a URL or similar reference data. While most of the data stored in digital receipt 285 may be protected using encryption, the ownership metadata portion of business information 287 may be presented in simple text form unencrypted, allowing the digital receipt to be readily recognized by the user. As shown in FIG. 2, portions of digital receipt 285 are encrypted with the public key of keylocker 260, where keylocker 260 may decrypt the encrypted portions using keylocker private key 265, although other protection methods that may be used by keylocker 260 may also be used. In addition, portions of digital receipt 285 may also be digitally signed by the issuing media distributor 270 so that key locker 260 can confirm that digital receipt 285 is timely distributed by an authorized media distributor.

Once digital receipt 285 is securely stored in backup storage 289 and consumer database 263 of keylocker 260, the user of client 280 is protected from loss of universal file 240, loss of DRM license 273, and loss or alteration of client 280 and/or media distributor 270. The user need only retrieve data receipt 285 from backup storage 289 and resubmit it to keylocker 260, media distributor 270, or another media distributor having an established relationship with keylocker 260. Once digital receipt 285 is submitted or forwarded directly to keylocker 260, keylocker 260 may verify the receipt using keylocker private key 265, as appropriate, to decrypt the encrypted portion of digital receipt 285 and/or the public key of media distributor 270, to verify the signature described above, and to process any relevant business rules to grant or deny the challenge or request. If the challenge or request is granted, the media distributor may retrieve the corresponding key information file to authorize resending the universal file 240 and/or generate a new DRM license that includes the user's ownership key.

While it may be desirable from a user's perspective for all media distributors to provide any required key information file for any submitted digital receipt, a limited distribution agreement between different media distributors and ownership owners may limit the scope of key information files that may be transferred by any single media distributor. In particular, distributor database 267 can specify access privileges for particular key information files in accordance with the identity of the interrogating media distributor. In the case of media distributor 270, this would correspond to distributor ID271, and may be provided as part of the HTTPS or TLS handshake procedure prior to establishing secure communications with keylocker 260 through provider API 257.

In addition, while the user may prefer that all media dispensers provide for the download of the universal file 240 or the generation of new DRM licenses for free, the media dispensers must also account for fees such as server and network maintenance, consumer service, and release contracts. Thus, while some media dispensers may provide free reactivation with digital receipts to encourage their use of particular online services, other media dispensers may charge fees for the redemption of digital receipts to pay for bandwidth, server maintenance, customer support, and the acquisition and recovery of dispenser rights and content licenses. These considerations may be included within business rules implemented by the keylocker 260 or by a separate media distributor, flexibly independent of the core key storage and distribution functions of the CKR-keylocker 260.

FIG. 3 illustrates a system for obtaining protected Data Rights Management (DRM) licenses for interoperability between different DRM systems through an interoperable key locker, according to one embodiment of the invention. The environment 300 of FIG. 3 includes a key locker 360, media distributors 370a-370b, clients 380a-380b, a common client ID386, and a common client ID authentication server 390. Key locker 360 includes key information database 362, customer database 363, business database 364, distributor public key database 366, distributor database 367, quote database 368, preparer database 369, and provider API 357. Media distributor 370a includes a local DRM server 372 a. Media distributor 370b includes a local DRM server 372 b. Client 380a includes universal file 340, DRM license 373a, and local DRM client 382 a. The universal file 340 includes an ownership ID316, metadata 317, encrypted ownership 345, and a keylocker URL 346. The DRM license 373a includes an ownership ID316, an encrypted ownership key 374a, and a client ID 381. Client 380b includes universal file 340, DRM certificate 373b, and local DRM client 382 b. The DRM certificate 373b includes the ownership ID316, the encrypted ownership key 374b, and the client ID 381. With respect to FIG. 3, it should be noted that keylocker 360 corresponds to keylocker 260 of FIG. 2, media distributors 370a-370b correspond to media distributor 270, and clients 380a-380b correspond to client 380.

Although the concept of using digital receipts for interoperability between different media distributors is explained in some detail in fig. 2 above, fig. 3 shows an alternative method of interoperability between different media distributors, where universal files are only copied between different clients and used to obtain new DRM licenses applicable to the new clients, even if different media distributors use different DRM systems or schemes.

For example, assume that a user of client 380a has purchased universal file 340, which also results in obtaining an associated DRM license 373 a. Additionally, a record of the purchase is recorded in business database 364, including the identification of the purchaser, common client ID 386. As previously discussed, the common client ID386 may use an identification scheme such as OpenID. Using the DRM system or scheme supported by native DRM client 382a and native DRM server 372a, the user of client 380a can now easily consume and enjoy and playback and encrypted ownership 345 on client 380 a. However, the user of client 380a may have several different clients or devices for media consumption, some clients being more suited to certain situations than others. For example, client 380a could represent a user's personal computer, while client 380b could represent a user's video game console. For example, if a video game console happens to connect to a high-end home theater system in the living room, and a personal computer happens to move to a book room with a small computer speaker and a small LCD screen, the user may wish to view the universal file 340 on client 380b instead of client 380 a. Alternatively, client 380 may represent a user's portable media device, where the user wishes to view generic file 340 while in flight on a business trip.

Traditionally, it has been difficult or impossible to transfer files between different devices using different DRM systems, as privately closed system DRM formats tend to introduce incompatibilities, preventing full interoperability. In addition to DRM interoperability challenges, media container formats and compression algorithms may even result in unprotected content not being played on different platforms.

However, the introduction of a generic file concept as shown in fig. 3 may help to largely address this concern among digital media consumers. As shown in fig. 3, after purchasing the universal file 340 from the client 380a, it may be directly copied to the client 380b as is, as evidenced by the identity between the two instances of the universal file 340 in the client 380a and the client 380. Alternatively, generic file 340 may first be copied to an intermediate storage location, such as a USB storage device, before being copied to client 380 b. Because DRM license 373a works only with the DRM systems supported by local DRM client 382a and local DRM server 372a, DRM license 373a is useless for client 380 b. However, with the help of the key locker 360, the client 380b can obtain the DRM license 373b from the media distributor 370b even if the client 380b and the media distributor 370b use different DRM systems supported by the local DRM server 372 and the DRM client 382 b.

After receiving universal file 340, client 380b may query media distributor 370b for a DRM license 373 b. Client 380b may also provide identification credentials, such as a username and password, associated with common client ID 386. Media distributor 370b may then verify the identity of the user by relaying the identification credential to common client ID verification server 390.

Once the identity of client 380b is confirmed, media distributor 370b may query keylocker 360 through provider API357 to confirm whether the user identified by common client ID386 has rights associated with generic file 340. Thus, the key locker 360 can check the service database 364 to confirm the existence of a previous service with the media distributor 370a involving the purchase of the universal file 340 by the same user identified using the common client ID 386. If the transaction database 364 instead reports no match results associated with the common client ID386 and the generic file 340 or the transaction type is rental rather than purchase, the keylocker 360 may stop processing and return a negative grant. The distributor database 367 may also be consulted to determine whether the media distributor 370b has a protocol to replace the issuance of the relevant key information file associated with the generic file 340 from the key information database 362. Additionally, as previously discussed, different business rules may be enforced by the keylocker 360. For example, to prevent abuse of universal document distribution, a global limit of 5 different clients can be supported for any single purchase connected to an identifiable user, the user needs more than 5 simultaneously valid DRM licenses that are processed by the consumer service on a case-by-case basis. Similarly, global restrictions of 5 different identities may be supported to identify the same consumer.

Assuming the key locker 360 confirms that the qualified services in the services database 364 and any and all other business rules are satisfied, the key locker 360 may retrieve the relevant key information file from the key locker information database 362 and provide the media distributor 370b with the transcribed key information file using the public key of the media distributor 370b, as previously described. Media distributor 370b may then use the transcribed key information file to generate a DRM license 373b using local DRM server 372b and provide DRM license 373b to local DRM client 382b in client 380 b. Thus, the user of client 380b is able to consume universal file 340 by re-acquiring DRM license 373b, which includes a much smaller download size than would be necessary to download universal file 340 again, providing nearly instant playback and allowing the user to enjoy universal file 340 on a high-end home theater system or on a portable media device.

Alternatively, rather than routing the digital receipt through the intermediary media distributor, the client 380b may resend the digital receipt directly to the keylocker 360 if the keylocker 360 provides a direct client interface for requesting the registered media. A separate keylocker is free to decide to provide this function. As previously discussed, the digital receipt serves as evidence of the transaction and thus can be resent back to the keylocker 360 to gain access to the original media or license that was recognized by the original transaction. If key locker 360 does support such a direct request from client 380b, and if key locker 360 determines that client 380b has privilege to access the requested registered media as detailed above, key locker 360 may direct client 380b to the appropriate media distributor capable of serving the requested registered media.

For example, the key locker 360 may first determine a list of privileged media distributors using the distributor database 367, find all third party media distributors that have publishing rights or publishing privileges to the requested registered media, such as the universal file 340. The user of client 380b may then be prompted to select from the provider's list to be redirected to a particular third party media distributor. After the user of client 380b is redirected to a particular third party media distributor, such as media distributor 370b, keylocker 360 may then forward to media distributor 370b a verification that the user of client 380b is authorized to retrieve the requested universal file 340 and/or any associated DRM licenses. As before, this validation may involve validating the submitted digital receipt against the registered digital receipts in consumer database 363 and applying any applicable business rules. After this, the process continues normally as if the user submitted a digital receipt to the media dispenser instead of the CKR. Accordingly, distributor 370b may thus provide client 380b with DRM license 373b for consumption of universal file 340.

In addition, this process of sharing common files and obtaining different DRM licenses can be used to provide recommended media files to friends and colleagues without requiring them to re-download the related common files. For example, a user of client 380a may provide a copy of generic file 340 to a user of client 380b via a USB storage device. However, because client 380b does not know the personal login details of the user of client 380a, client 380b cannot provide login credentials for common client ID386, allowing media distributor 370b to determine that the user of client 380b is not the same as the user of client 380a, the original purchaser of copied universal file 340. Instead, media distributor 370 may display an attempt to execute a new service to obtain the DRM license for universal file 340, unlocking it for immediate playback. In addition, although two separate media distributors are shown in fig. 3, this process may also be applied to clients using the same media distributor.

As shown in fig. 3, each media distributor may provide exactly the same universal file for a particular media ownership, even if a different DRM system or scheme is used. Since the keylocker 360 functions as a central rights exchange and the common client ID authentication server 390 authenticates the identity of the unique user in the provider, the media distributor can provide an interoperable solution and re-establishment of existing DRM systems with minimal additional effort. This allows the user to easily transfer the universal file between different devices and the media distributor, requiring only a quick re-acquisition of a new DRM license to play back the copied universal file.

Figure 4a illustrates a system for playback of protected media using an interoperable keylocker independent of the original distribution media distributor, in accordance with one embodiment of the present invention. The environment 400 of FIG. 4a includes a key locker 460, a media distributor 470, a client 480, a backup storage 489, and a common client ID authentication server 490. The media distributor 470 includes a universal file 440 and a DRM license 473. Client 480 includes a client media application 483. Backup storage 489 includes digital receipt 485. With respect to fig. 4a, it should be noted that keylocker 460 corresponds to keylocker 260 of fig. 2, media distributor 470 corresponds to media distributor 270, client 480 corresponds to client 280, and backup storage 489 corresponds to backup storage 489.

As previously discussed, there may be instances where a user may voluntarily or involuntarily lose access to purchased universal files and associated DRM licenses. The loss of willingness may include changing the client device or the media distributor. Involuntary loss may include catastrophic hardware failure, such as a failed hard drive, or user error, such as accidental deletion of files. As shown in fig. 2, because each digital service is accompanied by a delegated digital receipt under user control, the user has a complete discretion to plan for such unforeseen events independently of the original media distributor. For example, if a user diligently registers digital receipts online using an associated key locker and maintains a secure backup, the user need only resubmit the digital receipt to restore access to the associated universal file and DRM license.

For example, assume that a user of client 480 suffers a catastrophic hard drive failure. The user replaces the hard drive of client 480 and reinstalls client media application 483 to interact again with media distributor 470. Since the hard disk drive stores the user media library of the universal file and DRM license, the user of client 480 attempts to restore access to his old media library. It is appreciated that the user maintains a copy of the digital receipt in backup storage 489, which may include a USB storage device or an online email provider, as previously discussed. Additionally, as shown in FIG. 4a, the user registers digital receipt 485 online with key locker 460 so that digital receipt 85 can be stored in the user authentication database of key locker 460.

Thus, the user of client 480 only provides the digital receipt 485 dispatcher retrieved from backup storage 489 to media dispatcher 470 along with user credentials for authentication with media dispatcher 470 or, alternatively, common user credentials for authentication with common client ID authentication server 490. The media distributor 470, after consulting the key locker 460, may then provide the universal file 440 and the DRM license 473 to the client 480. In addition, media distributor 470 may also provide bulk transfer of any other generic files and DRM licenses, with the appropriately registered digital receipts within key locker 460 matching the user credentials provided by client 480 and verified by media distributor 470 or common client ID verification server 490 on a time-to-time basis. This bulk transfer can save the user a lot of time and effort if several digital receipts are submitted, which may be the case after a catastrophic hard disk failure. Several business rules may begin to work in this mode to handle possible abuse, ensure proper functioning of the system, or provide additional services to the consumer.

Additionally, this same mechanism may provide a user with a measure of protection against failure or recombination with their favorite media dispenser. For example, if a media dispenser that the client 480 normally subsidizes suddenly stops working, the user can easily transfer to another media dispenser, such as media dispenser 470 of FIG. 4a, as long as the user of the client 480 saves a copy of the digital receipt and registers the digital receipt using key locker 460. In this manner, many of the long-standing user concerns regarding the persistence of DRM-protected digital media may be effectively addressed.

FIG. 4b illustrates a system for recovering indirect protected media using an interoperable keylocker, in accordance with one embodiment of the present invention. The environment 400 of FIG. 4b includes the key locker 460, media distributor 470, clients 480a-480b, displays 488a-488b, media disk 491 and media box code 492. The media distributor 470 includes a universal file 440b and DRM licenses 473a-473 b. Client 480a includes a client media application 483 a. The media disk 491 includes a universal file 440 a. With respect to FIG. 4b, it should be noted that keylocker 460 corresponds to keylocker 260 of FIG. 2, media distributor 470 corresponds to media distributor 270, clients 480a-480b correspond to client 280, and displays 488a-488b correspond to display 288.

While the discussion of the universal document is generally limited to online digital distribution in this regard, the universal document may also have applications that also use physical retail media. For example, the media disk 491 may comprise a blu-ray disc purchased through retail outlets. In addition to storing standard blu-ray movie data, corresponding general files may be included for use on personal computers or for portable media devices. The media box code 492 may then comprise a unique numeric or alphanumeric sequence printed within the liner or under the hidden scratch pad that may be used to restore the universal file 440a for playback by retrieving the applicable DRM license. In this sense, the media box code may act as an anonymous user identifier because the key locker 460 may limit the amount of recovery for any single media code using business rules.

Thus, the user of the client 480a, a notebook PC, may insert the media disk 491 into the Blu-ray drive, wherein the user is prompted as to whether he wishes to restore the universal file 440 a. If the user answers yes, he may be prompted to enter media box code 492, which is sent to the media distributor 470 with any identifying metadata contained in the generic file 440 a. The media distributor 470 may then consult the key locker 460 to determine whether the media box code 492 is valid and/or has reached a maximum recovery number. For example, business rules on the keylocker 460 may force that each valid media box code may only provide up to three (3) recoveries, again preventing potential abuse of any common file sharing. If the key locker 460 answers positively, the media distributor 470 may provide a DRM license 473a so that the user of the client 480a can view the movie at full resolution on the display 488a of the notebook PC.

In addition, an eye-catching point of sale of the media disk 491 may include the ability to copy movies from the media disk 491 to various portable devices. Thus, the client 480a may additionally request a Standard Definition (SD) 720x480 version of the movie for playback on a portable device with a standard definition display. Using the same media box code 492 and the same metadata from the universal file 440a, the media distributor 470 can again query the key locker 460 for the portable device's special standard version key file, which is returned on time and used to generate the universal file 440b and the DRM license 473b, which can then be transmitted to the client 480b for playback on the display 488 b. In addition, the recovery of the box code may be associated with the client or consumer ID and recorded in an associated database in the key locker 460, as previously done using an online service. Alternatively, various universal files that have been formatted for popular media devices may be embedded on the media disk 491 so that only the corresponding DRM license needs to be retrieved, reducing download time.

FIG. 5 shows a flowchart describing steps by which online registration of digital receipts associated with content can be used with a Central Key Repository (CKR) to enable interoperable playback of content independent of the original distributor, in accordance with one embodiment of the present invention. Certain details and features have been left out of flowchart 500 that are apparent to a person of ordinary skill in the art. For example, a step may include one or more substeps or may involve specialized equipment or materials, as known in the art. While steps 510 through 570 shown in flowchart 500 are sufficient to describe one embodiment of the present invention, other embodiments of the present invention may use different steps than those shown in flowchart 500.

Referring to step 510 of the flowchart 500 in fig. 5 and the environment 200 of fig. 2, step 510 of the flowchart 500 includes the client 280 performing a transaction to obtain the universal file 240 from the media distributor 270, the universal file 240 including the encrypted ownership 245 encrypted by an ownership key corresponding to the encrypted ownership key 274 or the unencrypted version of the ownership key 132 of fig. 1, and a DRM license 273 usable with the media distributor 270 to access the unencrypted version of the encrypted ownership key 274. This process has been discussed in some detail, but briefly, the client 280 uses the client-side media application 283 to browse the digital storefront and select the universal file 240 to begin the business. In response, media distributor 270 provides universal file 240 and associated DRM license 273 to client 280 through interaction with key locker 260, native DRM server 272, and native DRM client 282.

Referring to step 520 of flowchart 500 in fig. 5 and environment 200 of fig. 2, step 520 of flowchart 500 comprises client 280 receiving digital receipt 285 associated with encrypted ownership 245, wherein digital receipt 285 comprises information related to the service of step 510. As shown in fig. 2, this information includes client ID281, distributor ID271, common client ID286, consumer ID284, ownership ID216, and business information 287, although alternative embodiments may use other arrangements of data. Additionally, as shown in FIG. 2, a portion of digital receipt 285 is provided that is encrypted by the public key of key locker 260.

Referring to step 530 of flowchart 500 in FIG. 5 and environment 200 of FIG. 2, step 530 of flowchart 500 comprises client 280 sending data receipt 285 received from step 520 to keylocker 260 for online registration of digital receipt 285 in consumer database 263. As shown in fig. 2, client 280 sends digital receipt 285 using client API256 of keylocker 260, client API256 may expose a web service accessible through SOAP over HTTPS.

Referring to step 540 of flowchart 500 in FIG. 5 and environment 400 of FIG. 4a, step 540 of flowchart 500 includes client 280 losing access to DRM license 473 corresponding to DRM license 273 retrieved from step 510. As discussed previously, this may be through a loss of resources by the media distributor or client, or through an involuntary loss of hardware failure, for example, resulting in data loss. In either case, client 480 is no longer able to directly access DRM license 473 after step 540. However, in contrast to the access state shown in FIG. 4a, client 480 may still maintain access to generic file 440 corresponding to generic file 240 retrieved from step 510.

Referring to step 550 of flowchart 500 in FIG. 5 and environment 400 of FIG. 4a, step 550 of flowchart 500 includes client 480 sending digital receipt 485 to media distributor 470, where digital receipt 485 corresponds to digital receipt 285 retrieved from step 520, and where media distributor 470 is completely different from media distributor 270 accessed during steps 510 and 520. After step 550, media distributor 470 can scrutinize the validity of digital receipt 485 by querying key locker 460 for existing proof of online registration of the same digital receipt 485. Key locker 460 may also use different business rules before providing the relevant key information file for use in generating a new DRM license.

Referring to step 560 of flowchart 500 in fig. 5 and environment 400 of fig. 4a, step 560 of flowchart 500 includes client 480 receiving from media distributor 470 a DRM license 473 that is usable with media distributor 470 to access an ownership key for decoding universal file 440 that is the same as the ownership key used in step 510 for encrypted ownership 245. As previously discussed, after step 550, key locker 460 may also verify the identity of client 480, the authorization of media distributor 470, and any applicable business rules before providing the relevant key information file to allow step 560 to proceed.

Referring to step 570 of flowchart 500 in fig. 5 and environment 400 of fig. 4a, step 570 of flowchart 500 includes client media application 483 of client 480 initiating playback of universal file 440 using media distributor 470 on display 488 encrypted using an ownership key that was obtained using DRM license 473 received from step 560. Because the client 480 has access to the universal file 440 and the DRM license 473 at the end of step 560, the client need only access the ownership key embedded in the DRM license 473 using the native DRM solution implemented by the client media application 483 and the media distributor 470 for decoding the encrypted ownership rights in the universal file 440, which can then be consumed or output to the display 488 for viewing by the user of the client 480.

FIG. 6 is a flow chart illustrating steps by which media content may be distributed to a media distributor according to one embodiment of the present invention. Certain details and features have been left out of flowchart 600 that are apparent to a person of ordinary skill in the art. For example, a step may include one or more substeps or may involve specialized equipment or materials, as known in the art. While steps 610 through 670 shown in flowchart 600 are sufficient to describe one embodiment of the present invention, other embodiments of the present invention may use steps different from those shown in flowchart 600.

Referring to step 610 of flowchart 600 in fig. 6 and environment 100 of fig. 1, step 610 of flowchart 600 comprises general file packager 135 of modulator 130 obtaining a first key, a key locker public key 122, a second key, an ownership key 132, and ownership 115. As shown in fig. 1, the key locker public key 122 is retrieved from a trusted third party, certificate authority 120, where the certificate 121 is used to validate the binding between the key locker public key 122 and the key locker 160. However, alternative methods with or without PKI may also be used. The modulation machine 130 itself may generate the ownership key 132 using the key generator 131. The ownership 115 is re-acquired from the ownership owner 110 and the ownership 115 can be securely acquired through digital or physical means. The ownership owner 110 may also be owned by the same entity as the modulator 130, as previously described.

Referring to step 620 of flowchart 600 in fig. 6 and environment 100 of fig. 1, step 620 of flowchart 600 includes general file packager 135 of modulation machine 130 encrypting ownership key 132 using keylocker public key 122 to generate encrypted ownership key 152, both keylocker public key 122 and ownership key 132 obtained from step 610. Because the encrypted ownership key 152 may only be encrypted using the key locker private key 165, the key locker 160 may only access the ownership key 132 from the encrypted ownership key 152 as long as the key locker 160 protects the privacy of the key locker private key 165. As previously discussed, a 2048 bit RSA key that conforms to public key cryptography standard #1 (PKCS) may be used for the asymmetric key encryption of step 620.

Reference is made to step 630 of flowchart 600 in fig. 6 and environment 100 of fig. 1. A step 630 of flowchart 600 includes the universal file packager 135 of the modulation machine 130 encrypting the ownership 115 using the ownership key 132 to generate the encrypted ownership 145, both the ownership 115 and the ownership key 132 obtained from step 610. As discussed previously, a balanced compromise such as Advanced Encryption Standard (AES) may be used for the symmetric key encryption of step 630 to provide fast decode time for reasonably strong security.

Referring to step 640 of flowchart 600 in fig. 6 and environment 100 of fig. 1, step 640 of flowchart 600 comprises general file packager 135 of modulator 130 generating key information file 150 comprising encrypted ownership key 152 generated from step 620. As shown in fig. 1, the key information file 150 may also include various metadata and identification information, such as the ownership owner ID111 and the ownership ID116, to assist in indexing and re-acquiring the key information file 150 in the key information database 162.

Referring to step 650 of flowchart 600 in fig. 6 and environment 100 of fig. 1, step 650 of flowchart 600 comprises general file packager 135 of preparer 130 generating general file 140 comprising encrypted ownership 145 generated from step 630 and key locker URL146 of Central Key Repository (CKR) -key locker 160. The keylocker URL146 represents a network address that points to the keylocker 160, and the redirect server may also serve as an intermediary as discussed previously. Although fig. 1 uses URLs as network addresses for interacting with SOAP-over-HTTPS based networks, alternative embodiments may use other protocols to reach network addresses in a secure manner. As shown in the universal file 140, additional metadata and identification information, such as the ownership ID116 and metadata 117, may also be included in the universal file 140 to facilitate identification and classification of the universal file 140.

Referring to step 660 of flowchart 600 in fig. 6 and environment 100 of fig. 1, step 660 of flowchart 600 comprises general file wrapper 135 of modulation machine 130 providing key information file 150 for storage in key information database 162 of key locker 160. As shown in fig. 1, this may be through the use of SOAP web services exposed over HTTPS by the modulation machine API161 of the key locker 160. After the key locker 160 authenticates the modulator 130 as an authorized modulator and accepts the key information file 150, it may be archived in the key information database 162 for future re-acquisition by the media distributor, the key information file prepared in a transcribed form by using the public keys from the distributor public key database 166 corresponding to the re-acquired media distributor. In this case, each media distributor generates its own private/public key pair and distributes the public key to the key locker 160, but as discussed previously, the key locker 160 may also generate private/public key pairs and distribute the public key to the media distributors.

Referring to step 670 of flowchart 600 in fig. 6 and environment 100 of fig. 1, step 670 of flowchart 600 includes general file packager 135 of modulator 130 providing general file 140 to media distributor 170. Prior to step 670, there should be an appropriate distribution arrangement between the parties. More specifically, the media distributor 170 should have an agreement to issue the ownership 115 from the ownership owner 110, and the distributor database 167 of the key locker 160 should grant the media distributor 170 access to the corresponding key information file 150 from the key locker 160. Although only a single media distributor is shown in fig. 1, in an alternative embodiment, the owner of ownership 110 may have an agreement with several different media distributors to send the common file generated by the modulator to each of the different media distributors. As with the ownership owner 110 providing ownership 115 to the modulator 130, the universal file 140 may be provided to the media distributor 170 physically or digitally using any suitable secure communication method. Once the universal file 140 is published to an authorized media distributor, such as media distributor 170, the universal file 140 can be used to request a client or user through a digital storefront or other display method.

Fig. 7 shows a flowchart describing steps by which a Central Key Repository (CKR) may provide content access authorization to a media distributor, in accordance with one embodiment of the present invention. Certain details and features have been left out of flowchart 700 that are apparent to a person of ordinary skill in the art. For example, a step may include one or more substeps or may involve specialized equipment or materials, as known in the art. While steps 710 through 750 shown in flowchart 700 are sufficient to describe one embodiment of the present invention, other embodiments of the present invention may use steps different from those shown in flowchart 700.

Referring to step 710 of the flowchart 700 in fig. 7 and the environment 100 of fig. 1, step 710 of the flowchart 700 includes the keylocker 160 receiving the key information file 150 including the encrypted ownership key 152, the ownership ID116, and the ownership owner ID 111. As shown in fig. 1, step 710 may be implemented by exposing the SOAP web service by HTTPS through modulator API161 for use by modulator 130. Once the key locker 160 receives the key information file 150, it may sort it into a key information database 162 for future retrieval by the media distributor.

Referring to step 720 of the flowchart 700 in fig. 7 and the environment 100 of fig. 1, step 720 of the flowchart 700 includes the key locker 160 decrypting the encrypted ownership file 152 in the key information file 150 received from step 710 using the key locker private key 165 to reacquire the ownership key 132. Because the encrypted ownership key 152 is encrypted using the key locker public key 122, the key locker 160 need only use the key locker private key 165 already in memory 159 for decryption.

Referring to step 730 of flowchart 700 in fig. 7 and environment 100 of fig. 1, step 730 of flowchart 700 comprises keylocker 160 receiving a key request from media distributor 170 comprising ownership ID 116. For example, the media distributor 170 may receive a request from a client to service the universal file 140. However, in order to achieve playback of the general file 140, the key information file 150 is also required for decryption. Because the universal file 140 includes the ownership ID116, the media distributor 170 can request a key information file that matches the ownership ID116 from the keylocker 160 to satisfy the request from the client.

Referring to step 740 of flowchart 700 in fig. 7, environment 100 of fig. 1, and environment 200 of fig. 2, step 740 of flowchart 700 includes key locker 160 encrypting ownership key 132 decrypted from step 720 using a provider public key stored in distributor public key database 166 to generate encrypted ownership key 252 of transcribed key information file 251, where the provider public key corresponds to the public portion of the private/public asymmetric key pair comprising distributor private key 175. The provider public key may be provided to the key locker 160 in advance by a trusted third party, such as the certificate authority 120. Step 740 "transcribes" the key information file 150 into a transcribed key information file 151 corresponding to the transcribed key information file 251 in fig. 2. The term "transcribe" is used herein in the sense that the ownership key 132 transitions from being encrypted by the key locker public key 122 to the encrypted ownership key 152 to being encrypted by the provider public key to the encrypted ownership key 252, such that only the associated media distributor 270 having the distributor private key 275 has access to the original ownership key 132 from the transcribed key information file 251.

Referring to step 750 of flowchart 700 in FIG. 7 and environment 100 of FIG. 1, step 750 of flowchart 700 includes keylocker 160 sending encrypted ownership key 252 generated from step 740 corresponding to the encrypted ownership key contained in the transcribed key information file 151 to media distributor 170 in response to step 730-the receipt of a key request. After step 750, the media distributor 170 may access the original ownership key 132 using the distributor private key 175 for incorporation within the local DRM system 172 to enable access and playback of the universal file 140.

Fig. 8 shows a flow chart describing steps by which a media distributor may obtain content access authorization from a Central Key Repository (CKR), in accordance with one embodiment of the present invention. Certain details and features have been left out of flowchart 800 that are apparent to a person of ordinary skill in the art. For example, a step may include one or more substeps or may involve specialized equipment or materials, as known in the art. While steps 810 through 850 shown in flowchart 800 are sufficient to describe one embodiment of the present invention, other embodiments of the invention may use steps different from those shown in flowchart 800.

Referring to step 810 of flowchart 800 in fig. 8 and environment 200 of fig. 2, step 810 of flowchart 800 comprises media distributor 270 receiving a user request distributor from client 280 for access to encrypted ownership 245 in universal file 140, the request comprising ownership ID 216. For example, the client media application 283 may communicate with the media distributor 270 to display an e-commerce storefront to the user of the client 280. A user of the client 280 can browse an e-commerce storefront and begin a protocol for purchasing a license for viewing digital media identified by the ownership ID216 or the encrypted ownership 245 in the universal file 240. This protocol may then be sent as a user request to be communicated to media distributor 270.

Referring to step 820 of flowchart 800 in FIG. 8 and environment 200 of FIG. 2, step 820 of flowchart 800 comprises media distributor 270 sending a key request to keylocker 260 in response to step 810, the key request comprising ownership ID 216. Using the provider API257, the media distributor 270 may send a key request to the keylocker 260 for the key information file corresponding to the ownership ID 216. As with the client API256, the provider API257 may be exposed externally by the web service through SOAP over HTTPS.

Referring to step 830 of flowchart 800 in fig. 8 and environment 200 of fig. 2, step 830 of flowchart 800 comprises media distributor 270 receiving the transcribed key information file 251 comprising the encrypted ownership file 252 in response to step 820. The transcribed key information file 251 may be received using the same secure connection established in step 820. Because the encrypted ownership key 252 in the transcribed key information file 251 is encrypted using the public key of the media distributor 270, the distributor private key 275 can be readily used to decrypt the encrypted ownership key 252.

Referring to step 840 of the flowchart 800 in fig. 8 and the environment 200 of fig. 2, step 840 of the flowchart 800 includes the media distributor 270 decrypting the encrypted ownership key 252 of the transcribed key information file 251 received from step 830 to reacquire an ownership key corresponding to the ownership key 132 of fig. 1. This ownership key may ultimately be used to decrypt the encrypted ownership 245 associated with the ownership ID216 in the universal file 240.

Referring to step 850 of flowchart 800 in fig. 8 and environment 200 of fig. 2, step 850 of flowchart 800 comprises media distributor 270 providing client 280 with DRM license 273 of encrypted ownership 245 of universal file 240, DRM license 273 using the ownership key from step 840 as encrypted ownership key 274 protected by local DRM server 272. Step 850 is initiated and used by the client 280 to decrypt the encrypted ownership 245 using the ownership key from step 840 that can be re-acquired from the DRM license 273 using the native DRM client 282. After the client 280 receives the DRM license 273, it may use the local DRM client 282 to remove the protection from the encrypted ownership key 274, accessing the ownership key from step 840 to decrypt the encrypted ownership 245 in the universal file 240. After decryption, for example, client 280 may direct the decrypted content for playback on display 288 on protected media path decoding engine 299 so that a user of client 280 may enjoy the content requested from step 810.

It will be apparent from the above description of the invention that various techniques can be used to implement the concepts of the invention without departing from its scope. In addition, although the present invention has been described with specific reference to certain embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention. The described embodiments are, therefore, to be considered in all respects as illustrative and not restrictive. It should also be understood that the invention is not limited to the particular embodiments described herein, but is capable of many rearrangements, modifications, and substitutions without departing from the scope of the invention.

Claims

1. A method for use by a central key repository CKR for providing access authorization to content, the method comprising:

receiving a key information file comprising an ownership ID and a first encrypted ownership key encrypted using a CKR public key, the first encrypted ownership key for decryption using a CKR private key;

decrypting the first encrypted ownership key using the CKR private key to reacquire the ownership key;

receiving a key request including the ownership ID from a distributor, wherein the distributor receives the content from a modulator and not from the CKR;

encrypting the ownership key using a distributor public key to generate a second encrypted ownership key; and

sending the second encrypted ownership key to the distributor in response to receipt of the key request.

2. The method of claim 1, wherein encrypting the ownership key using the distributor public key is in response to receipt of the key request.

3. The method of claim 1, further comprising:

generating the distributor public key;

storing the distributor public key in a distributor key database; and

sending the distributor public key to the distributor before sending the second encrypted ownership key to the distributor.

4. The method of claim 1, further comprising:

receiving the distributor public key from the distributor prior to encrypting the ownership key using the distributor public key; and

storing the distributor public key in a distributor key database.

5. The method of claim 1, further comprising:

receiving the distributor public key from a third party prior to encrypting the ownership key using the distributor public key; and

storing the distributor public key in a distributor key database.

6. The method of claim 5, wherein the third party includes a certificate authority.

7. The method of claim 1, wherein the key information file further comprises a Universally Unique Identifier (UUID) and an international standard audiovisual material number (ISAN).

8. The method of claim 1, wherein the CKR further comprises a distributor database, and wherein in response to receipt of the key request, the method further comprises determining whether the distributor is authorized to receive the ownership key.

9. The method of claim 1, wherein the key request further comprises at least one of customer information, service type, and device information.

10. The method of claim 9, wherein the CKR further comprises a consumer database, and wherein in response to receipt of the key request, the method further comprises determining whether a consumer associated with the consumer information is authorized to consume the content associated with the ownership ID.

11. The method of claim 9, wherein the CKR further comprises a traffic database, and wherein in response to receipt of the key request, the method further comprises determining whether the traffic type authorizes a consumer to consume the content associated with the ownership ID.

12. The method of claim 9, wherein the CKR further comprises a device database, and wherein in response to receipt of the key request, the method further comprises determining whether the device associated with the request is authorized to consume the content associated with the ownership ID.

13. The method of claim 1, wherein the key request further comprises a code associated with the content associated with the ownership ID.

14. The method of claim 1, wherein transmitting the second encrypted ownership key comprises a key information file having the second encrypted ownership key and information about the content referred to by the ownership ID.

15. A central key repository, CKR, system for providing access authorization to content, the CKR system comprising:

means for receiving a key information file comprising an ownership ID and a first encrypted ownership key encrypted using a CKR public key, the first encrypted ownership key for decryption using a CKR private key;

means for decrypting the first encrypted ownership key using the CKR private key to reacquire the ownership key;

means for receiving a key request including the ownership ID from a distributor, wherein the distributor receives the content from a modulator and not from the CKR;

means for encrypting the ownership key using a distributor public key to generate a second encrypted ownership key; and

means for sending the second encrypted ownership key to the distributor in response to receipt of the key request.

16. The CKR system of claim 15, wherein the means for encrypting encrypts the ownership key using the distributor public key in response to receiving the key request.

17. The CKR system of claim 15, further comprising:

means for generating the distributor public key;

means for storing the distributor public key in a distributor key database; and

means for sending the distributor public key to the distributor before sending the second encrypted ownership key to the distributor.

18. The CKR system of claim 15, further comprising:

means for receiving the distributor public key from the distributor prior to encrypting the ownership key using the distributor public key; and

means for storing the distributor public key in a distributor key database.

19. The CKR system of claim 15, further comprising:

means for receiving the distributor public key from a third party prior to encrypting the ownership key using the distributor public key; and

means for storing the distributor public key in a distributor key database.

20. The CKR system of claim 19, wherein the third party comprises a certificate authority.

21. The CKR system of claim 15, wherein the key information file further comprises a Universally Unique Identifier (UUID) and an international standard audiovisual data number (ISAN).

22. The CKR system of claim 15, further comprising:

a dispenser database, and

means for determining whether the distributor is authorized to receive the ownership key in response to receiving the key request.

23. The CKR system of claim 15, wherein the key request further comprises at least one of customer information, service type, and device information.

24. The CKR system of claim 23, further comprising:

a consumer database, and

means for determining whether a consumer associated with the consumer information is authorized to consume the content associated with the ownership ID in response to receiving the key request.

25. The CKR system of claim 23, further comprising:

a service database, and

means for determining whether the traffic type authorizes a consumer to consume the content associated with the ownership ID in response to receiving the key request.

26. The CKR system of claim 23, further comprising:

a device database, and

means for determining, in response to receiving the key request, whether a device associated with the request is authorized to consume the content associated with the ownership ID.

27. The CKR system of claim 15, wherein the key request further comprises a code associated with the content associated with the ownership ID.

28. The CKR system of claim 15, wherein the means for sending the second encrypted ownership key sends the second encrypted ownership key by including a key information file having the second encrypted ownership key and information about the content referenced by the ownership ID.