Source: https://patents.google.com/patent/US20110010298A1/en
Timestamp: 2019-04-24 21:35:31
Document Index: 243522662

Matched Legal Cases: ['art 14', 'art 10', 'art 500', 'art 500', 'art 500', 'art 500', 'art 700', 'art 700']

US20110010298A1 - Interoperable keychest - Google Patents
US20110010298A1
US20110010298A1 US12/460,003 US46000309A US2011010298A1 US 20110010298 A1 US20110010298 A1 US 20110010298A1 US 46000309 A US46000309 A US 46000309A US 2011010298 A1 US2011010298 A1 US 2011010298A1
US12/460,003
2009-07-10 Application filed by Disney Enterprises Inc filed Critical Disney Enterprises Inc
2009-07-10 Priority to US12/460,003 priority Critical patent/US20110010298A1/en
2009-07-29 Assigned to DISNEY ENTERPRISES, INC. reassignment DISNEY ENTERPRISES, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WATSON, SCOTT F., ROBERT, ARNAUD
2010-07-07 Priority claimed from EP10007016A external-priority patent/EP2273409A3/en
2011-01-13 Publication of US20110010298A1 publication Critical patent/US20110010298A1/en
Accordingly, there is a need to overcome the drawbacks and deficiencies in the art by providing a way for digital media to interoperate across different service providers and media devices in a manner that requires minimal disruptive changes to existing digital rights management paradigms, distribution models and consumption models, particularly with respect to key management.
There are provided systems and methods for an interoperable keychest, substantially as shown in and/or described in connection with at least one of the figures, as set forth more completely in the claims.
The present application is directed to a system and method for a universal file packager for use with an interoperable keychest. The following description contains specific information pertaining to the implementation of the present invention. One 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. Moreover, some of the specific details of the invention are not discussed in order not to obscure the invention. The 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. To maintain brevity, other embodiments of the invention, which use the principles of the present invention, are not specifically described in the present application and are not specifically illustrated by the present drawings.
Switching focus from KeyInfo file 150 to universal file 140, universal file 140 is also generated by universal file packager 135 for distribution to media distributors and eventually to consumers. The name “universal file” describes the property that even if media distributors use different DRM systems, the same file is distributed to consumers and is interoperable across different media distributors with the help of the CKR, keychest 160. As shown in FIG. 1, title 115 is encrypted with title key 132 to create encrypted title 145, which is accompanied with identifying data including title ID 116, metadata 117, and keychest URL 146. Metadata 117 may contain, for example, components of title metadata 118. Keychest URL 146 acts as a pointer or network address to direct where to find the keychest storing the associated KeyInfo file 150 so that encrypted title 145 can be decoded using a title key stored in KeyInfo file 150. In the case of FIG. 1, keychest URL 146 would point to keychest 160. It should be noted that the keychest URL might simply point to a redirection server using URL redirection to flexibly redirect keychest communications. Additionally, the URL form is chosen to tie with web services accessible over the Internet using SOAP, but alternative network addressing protocols could also be used as well. The components of universal file 140 may be embedded in a standard container format such as a MPEG-4 Part 14 or MP4 container file. Additionally, if title 115 is provided in an uncompressed format, preparer 130 may apply video and audio compression before encrypting title 115, using for example MPEG-4 part 10 or H.264. After universal file 140 is generated, it may be provided to media distributor 170.
However, the introduction of the universal file concept as shown in FIG. 3 may help to largely address this concern among digital media consumers. As shown in FIG. 3, after the purchase of universal file 340 from client 380 a, it is copied directly as-is to client 380 b, as evidenced by the identical contents between the two instances of universal file 340 within client 380 a and client 380 b. Alternatively, universal file 340 might be first copied to an intermediary storage location, such as a USB storage device, before being copied to client 380 b. Since DRM license 373 a only works with the DRM system supported by native DRM client 382 a and native DRM server 372 a, DRM license 373 a is of no use to client 380 b. However, with the assistance of keychest 360, client 380 b can obtain DRM license 373 b from media distributor 370 b, even though client 380 b and media distributor 370 b utilize a different DRM system supported by native DRM server 372 b and DRM client 382 b.
After receiving universal file 340, client 380 b may query media distributor 370 b for DRM license 373 b. Client 380 b may also provide identifying credentials associated with shared client ID 386, such as a username and password. Media distributor 370 b may then verify the identity of the user by relaying the identifying credentials to shared client ID verification server 390.
Additionally, a compelling sales point for media disc 491 might include the ability to copy the movie from media disc 491 to various portable devices. Thus, client 480 a might additionally request for a standard definition (SD) 720×480 version of the movie for playback on portable devices with standard definition displays. Using the same media box code 492 and the same metadata from universal file 440 a, media distributor 470 might again query keychest 460 for a special standard definition version KeyFile for portable devices, which is duly returned and used to generate universal file 440 b and DRM license 473 b, which can then be transferred to client 480 b for playback on display 488 b. Moreover, the redemption of box codes can be associated with a client or consumer ID and recorded within relevant databases in keychest 460, as previously done with online transactions. Alternatively, various universal files already formatted for popular media devices might be embedded on media disc 491 such that only a corresponding DRM license needs to be retrieved, reducing download time.
Referring to step 540 of flowchart 500 in FIG. 5 and environment 400 of FIG. 4 a, step 540 of flowchart 500 comprises client 480 forfeiting access to DRM license 473 corresponding to DRM license 273 retrieved from step 510. As previously discussed, this might be a voluntary forfeiture by changing media distributors or clients, or involuntarily by, for example, hardware failures resulting in data loss. In either case, client 480 will no longer have direct access to DRM license 473 after step 540. However, client 480 may still retain direct access to universal file 440 corresponding to universal file 240 retrieved from step 510, contrary to the access state shown in FIG. 4 a.
Referring to step 550 of flowchart 500 in FIG. 5 and environment 400 of FIG. 4 a, step 550 of flowchart 500 comprises client 480 transmitting digital receipt 485 to media distributor 470, where digital receipt 485 corresponds to digital receipt 285 retrieved from step 520, and wherein media distributor 470 is a different entity from media distributor 270 accessed during steps 510-520. After step 550, media distributor 470 may scrutinize digital receipt 485 for validity by querying keychest 460 for prior evidence of online registration of the same digital receipt 485. Keychest 460 may also apply various business rules before providing a relevant KeyInfo file for generating a new DRM license.
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 comprises keychest 160 encrypting title key 132 decrypted from step 720 using a provider public key stored in distributor public key database 166 to generate encrypted title key 252 of transcribed KeyInfo file 251, wherein the provider public key corresponds to a public portion of a private/public asymmetric key pair including distributor private key 175. This provider public key may have been provided to keychest 160 in advance through a trusted third party such as certificate authority 120. Step 740 “transcribes” KeyInfo file 150 to transcribed KeyInfo file 151, corresponding to transcribed KeyInfo file 251 in FIG. 2. The term “transcribe” is used here in the sense that title key 132 transitions from being encrypted by keychest public key 122 as encrypted title key 152 to being encrypted by the provider public key as encrypted title key 252, so that only the associated media distributor 270 having distributor private key 275 can access the original title key 132 from transcribed KeyInfo file 251.
1. A method for use by a central key repository (CKR) to provide content access authorizations to distributors, the method 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.
3. The method of claim 1 further comprising: generating the third key;
storing the third key in a distributor key database; and
transmitting the third key to the distributor prior to the transmitting of the second encrypted second key to the distributor.
receiving the third key from the distributor prior to the encrypting of the second key using the third key; and
storing the third key in a distributor key database.
receiving the third key from a third party prior to the encrypting of the second key using the third key; and
15. A central key repository (CKR) for providing content access authorizations to distributors, the central key repository comprising:
a memory having a first key;
receive a key information file including a first encrypted second key for decrypting with the first key and a content identification and store the key information file in the memory;
decrypt the first encrypted second key using the first key retrieved from the memory to retrieve the second key;
receive, from a distributor, a key request including the content identification;
encrypt the second key using a third key to generate a second encrypted second key; and
transmit the second encrypted second key to the distributor in response to receiving the key request.
17. The central key repository of claim 15, wherein the processor is further configured to:
generate the third key;
store the third key in a distributor key database in the memory; and
transmit the third key to the distributor prior to transmitting the second encrypted second key to the distributor.
18. The central key repository of claim 15, wherein the processor is further configured to:
receive the third key from the distributor prior to encrypting the second key using the third key; and
store the third key in a distributor key database in the memory.
19. The central key repository of claim 15, wherein the processor is further configured to:
receive the third key from a third party prior to the encrypting of the second key using the third key; and
US12/460,003 2009-07-10 2009-07-10 Interoperable keychest Pending US20110010298A1 (en)
US12/460,003 US20110010298A1 (en) 2009-07-10 2009-07-10 Interoperable keychest
EP10007016A EP2273409A3 (en) 2009-07-10 2010-07-07 Interoperable keychest
KR1020100065729A KR101387635B1 (en) 2009-07-10 2010-07-08 Interoperable Keychest
JP2010157194A JP5319620B2 (en) 2009-07-10 2010-07-09 Interoperability key storage box
CN 201010225461 CN101951360B (en) 2009-07-10 2010-07-09 Interoperable keychest
CN201410309535.7A CN104077501B (en) 2009-07-10 2010-07-09 Interoperable keychest
HK11101793.4A HK1147863A1 (en) 2009-07-10 2011-02-23 Interoperable keychest
KR1020110141963A KR101276348B1 (en) 2009-07-10 2011-12-26 A method for online registration of a digital receipt associated with a content
JP2013032536A JP5552176B2 (en) 2009-07-10 2013-02-21 Interoperability key storage box
JP2014087720A JP6294745B2 (en) 2009-07-10 2014-04-21 Interoperability key storage box
JP2014087728A JP6328986B2 (en) 2009-07-10 2014-04-21 Interoperability key storage box
US16/020,758 US20180308017A1 (en) 2009-07-10 2018-06-27 Interoperable Keychest
US16/020,758 Continuation US20180308017A1 (en) 2009-07-10 2018-06-27 Interoperable Keychest
US20110010298A1 true US20110010298A1 (en) 2011-01-13
ID=43428236
US12/460,003 Pending US20110010298A1 (en) 2009-07-10 2009-07-10 Interoperable keychest
US16/020,758 Pending US20180308017A1 (en) 2009-07-10 2018-06-27 Interoperable Keychest
US (2) US20110010298A1 (en)
US20150262190A1 (en) * 2014-03-14 2015-09-17 Disney Enterprises, Inc. Methods and Systems for Determining Consumer Entitlements for Playback Interoperability
2009-07-10 US US12/460,003 patent/US20110010298A1/en active Pending
2018-06-27 US US16/020,758 patent/US20180308017A1/en active Pending
US20180308017A1 (en) 2018-10-25
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ROBERT, ARNAUD;WATSON, SCOTT F.;SIGNING DATES FROM 20090709 TO 20090710;REEL/FRAME:023024/0459