Patent Application
20050271205
The present invention relates to Digital Rights Management (DRM) or Intellectual Property Management and Protection (IPMP) for a generic digital content, especially relates to the protection and management of a digital content independent of any data format.
As various kinds of network are widely deployed, it will be demanded that digital content can be delivered and distributed to user via such network besides using CD, DVD. The corresponding issue is raised by content owner. Is it secure to sell their content in this way?
As hard disk or other storage embedded device become more and more, another issue is that how the content protection technique can ensure the entitled rights to be exercised correctly.
As many different digital formats exist to use for packaging content in digital form for easy transmitting over various network, question arises as how the protection technology can be cross-used among different digital formats.
At the same time users have more demands on the convenience with low cost for enjoying content, even sharing with their friends if they purchase such rights, to have rich user experience.
Conflict is always there since content owner cares for any illegal copy so that content providers are trying to protect content in their own proprietary ways due to lacking of the open protection techniques in the market at that time. This not only brings a big barrier for content owner to sell content, but also brings a heavy cost for CE (consumer electronics) manufacturers to produce different versions of the product just for matching with various protection techniques which content provider use.
MPEG-21 is trying to define a generic framework to enable transparent and augmented use of digital content across a wide range of networks and devices used by different communities. How to protect the contents when they are being used across network or devices, becomes a very important item in MPEG-21, which is the part 4 of MPEG-21, called MPEG-21 IPMP (Intellectual Property Management and Protection)
In the past, people working on MPEG-4/2 IPMP Extension were required to define a content protection scheme based on MPEG-4/2 system since the aim is to protect any content if they are packaged in MPEG-4/2 format.
In MPEG-21, a Digital Item (DI) is defined as a structured digital object for any digital content with a standard representation, identification and description, and it will be used as the fundamental unit of interchange, distribution and transaction within MPEG-21 framework.
The Digital Item is declared and expressed using XML by Digital Item Declaration (DID). Besides a digital content which is represented as media resources in MPEG-21, such as video, music, image, the DID provides the flexible structure to include various kinds of functional metadata. Such metadata is supposed to describe media resource format, to specify resource protection scheme, to give the resource an identification name, to provide User preference, etc.
Besides the core part of DID technology, some other key technologies have also been elaborately developed or are under development. Digital Item Identification (DII), Digital Item Adaptation (DIA), Intellectual Property Management and Protection (IPMP), REL (Rights Expression Language)/RDD (Rights Data Dictionary), as well as ER (Event Reporting) are all the important technologies for extensively exploiting the Digital Items' usage. All the functional metadata defined by these technologies can be placed into a DID document to aid the actual media resource consumption.
A content protection and management mechanism is highly requested to address most of the requirements raised by many different application domains, especially in the scope of MPEG-21 domain, to reflect the market needs.
The requirements on MPEG-21 IPMP are the problems to be targeted and solved here.
IPMP, especially MPEG-21 IPMP shall support the management and protection of intellectual property in descriptors and description schemes.
IPMP, especially MPEG-21 IPMP shall provide for interoperability so that content is able to be played anywhere.
IPMP, especially MPEG-21 IPMP should enable devices to dynamically discover, request, and obtain upgrades for supporting new media formats, IPMP tools and support.
IPMP, especially MPEG-21 IPMP shall provide mechanisms to reference Digital Item Descriptions as part of the language, make reference to external content descriptions.
IPMP, especially MPEG-21 IPMP shall provide mechanisms to associate Expressions with composite Digital Items.
IPMP, especially MPEG-21 IPMP shall provide mechanisms to reference Containers or other aggregations of Digital Items.
IPMP, especially MPEG-21 IPMP should flag that a particular Expression should be subject to protection. The protection itself (if any) is provided by an IPMP system controlling the Expression as a Digital Item.
IPMP, especially MPEG-21 IPMP shall provide mechanisms to reference authentication schemes.
IPMP, especially MPEG-21 IPMP shall provide mechanisms to ensure that the IPMP is independent of the format or delivery channel of Digital Items.
IPMP, especially MPEG-21 IPMP shall unambiguously articulate requirements relating to IPMP Tool and Features.
IPMP, especially MPEG-21 IPMP shall need to identify IPMP Tools and Features to build trusted IPMP implementations.
IPMP Tools and Features are components parts to build an IPMP-enabled Terminal or Peer. It should also possible for a Terminal or Peer to disclose its IPMP capability (IPMP Tools and Features). This makes it possible for a communicating Terminal or Peer to examine IPMP capability of another Terminal or Peer before deciding to engage with it.
Methods of Digital Content Protection with Digital Rights Expression, comprising the following steps of:
(Means of Solving the Problems)
On the content packaging side:
On the content production side as shown in
The content could be watermarked using certain watermarking tool to achieve certain functions, such as finger printing, persistent association, or copyright protection by embedding CID or other information.
The content can be encrypted by an IPMP tool with ToolIDXXX, where xxx is the number which is registered with RA (Registration Authority), to indicate which encryption algorithm is used. A default tool such as AES is defined for simple hardware to implement. The resulted Key information could be carried in IPMP Control Graph directly or by pointing to a location where the whole Key information data could be found. The encryption key can be further encrypted and finally a license could be generated and directly carried in either IPMP Control Graph, in REL data or other Rights Expression Data, or in DID itself, or in somewhere which can be indicated by KeyLocation indicator to be carried in IPMP Control Graph/REL/DID;
Rights can be expressed by an independent and existing technology standard such as REL defined in MPEG-21 or other Rights Expression methods, and such rights could be protected by digital signature for its integrity;
The license information can be obtained from License Manager which could be a temper resistant entity to prevent any disclosure of how a license is retrieved by a license manager.
Rights and content is un-protected by using the above key, key data, and protection tool. Rights is further parsed by Rights Parser to obtain the rights and conditions in clear form, so that the rights and conditions processing can be conducted.
Therefore the un-protected content can be played back, rendered, modified, deleted, or adapted if there is such rights entitled for the user;
As shown in
(Reference 1, 2)
The DID has defined a useful model (unit 1.1 in
Module 1.2 shown in
The further improvements over the Prior Art are:
Since DID is to address static relation among each elements and it can be treated as file format, rights and protection information can be directly associated to its protected content as IPMP_Control_Graph, shown in
On the other hand, key information can be carried from KeyData Holder in IPMP_Control_Graph directly or indirectly. It could also be segmented when the content is delivered via network.
Rights which might be encrypted is carried separately or together with protection information.
Another Prior Art is shown in
(Reference 3)
The Rights Expression Language (REL) Engine in module 2.1 is the component that determines REL authorizations, given an authorization request and a set of licenses and root grants. The REL Engine uses the License Manager to help resolve authorization queries.
The Digital Item Manager in module 2.2 parses Digital Item Declarations within Digital Items. The Digital Item Manager also provides access to where the Digital Items are, and creates Digital Item iNstances in module 2.3. The Digital Item Manager passes to the License Manager any Licenses that are embedded within Digital Item Declarations.
The Digital Item iNstance in module 2.3 represents a Digital Item within a Trusted Domain. The Digital Item iNstance contains local metadata about the Digital Item, such as storage location and possibly information about content encryption keys.
The License Manager in module 2.4 supports the REL Engine by managing the persistent state of Licenses and their authorization or revocation status. The License Manager is also responsible for verifying the integrity of Licenses.
The Condition Processor in module 2.5 selects, evaluates and fulfills Conditions, and initiates the execution of authorized Operations (via the DIP Processor, generating a Right Exercise) once conditions are satisfied.
The IPMP User Session Manager in module 2.6 orchestrates the invocation of Digital Item Operations (via the Condition Evaluator), first making sure that proper authorization is obtained (via the REL Engine) and that conditions are evaluated (via the Condition Evaluator).
A Right Exercise in module 2.7 is a record of having exercised a right, i.e., the invocation of a Digital Item Operation. It is maintained by the User Session Manager, and is used to associate the fulfillment of Conditions with the exercise of Rights.
The Digital Item Processing Engine in module 2.8 executes Digital Item Operations, including Digital Item Methods (DIMs), Digital Item Basic Operations (DIBOs) in module 2.9, and Digital Item eXtended Operations (DIXOs) in module 2.10. The DIMs are executed by a DIM Engine, the DIXOs by a DIXO Engine, and the DIBOs by a DIBO Library. The Digital Item Processing Engine updates the User Session State with process state information.
The big issue with
The second issue with
The third issue with
The better rights and protection is designed based on the two cases. The first case is where the existing REL is employed for expressing the corresponding rights and conditions and a protection control mechanism is defined to take care of content protection including encryption, watermarking, key management. The second case is where the existing REL is extended by adding protection function which could include encryption, watermarking, key management, etc.
Both cases are elaborated in the following sections.
(Content Packaging and Consumption with Separate Rights and Protection)
As in
When the content is needed to transmit via network, normally it will be segmented, encrypted and stored as Resource somewhere, and the corresponding time-variant key is stored as Key Information in KeyData Holder in IPMP Control Graph in module 3.9 directly or indirectly by pointing to a location.
For example when the protected content is transmitted over RTP, IPMP Control Graph can be carried in SDP (Section Description Protocol), while the key information can be carried in the RTP header or as special case for video and audio packet as long as there is synchronization among time-variant keys and the protected video or audio data.
Module 3.1 is to assign content ID, DII in MPEG-21 could be used here. If necessary sub content ID can be used and the protection can be associated with this sub content ID if the sub content need to be protected.
Module 3.2 is to place a flag in IPMP Control Graph to tell if the content is protected or free. Module 3.3 is to place a flag in IPMP Control Graph to indicate if there is watermarking embedded.
If there is watermarking embedded in the content, module 3.4 will assign watermarking (WM) ToolID for the WM tool used for this case, and ToolID is then recorded and placed in IPMP Control Graph. The module 3.5 will create WM Descriptions including watermarking Interface or API related information which is placed in IPMP Control Graph.
Module 3.6 is to determine if the content will be encrypted, and a flag for “Yes/No” will be placed in IPMP Control Graph in module 3.15.
Module 3.9 is to assign encryption ToolID for the encryption tool used for this case, and ToolID is then recorded and placed in IPMP Control Graph. The module 3.7 is to place Key information in KeyData Holder directly in IPMP Control Graph, or pointing by the Holder to other location.
The encryption key can be further encrypted in module 3.11, and 3.13, and the key as a license is eventually placed in IPMP Control Graph, REL, DID, or somewhere indicated by KeyLocation1.
Module 3.8 is to create and package rights with the corresponding conditions which conforms to the existing REL standard, and this part could be modified and edited by distribution agents in the content distribution value chain.
The module 3.10 is to protect the rights metadata by digitally signing the rights. Module 3.12 is to assign ToolID for the verification of the digital signature, and module 3.14 is to place the Entity_Key in IPMP Control Graph, or in DID, or in somewhere indicated by KeyLocation2.
The detail of module 3.15 is shown in
Module 4.1 is to parse DID and IPMP Control Graph information where DID parser is required only for the case IPMP Control Graph is carried in DID in MPEG-21 case.
In the case of content distribution over RTP network, IPMP Control Graph can be retrieved from SDP to obtain rights and protection description information except the key information if it is time-variant.
Module 4.2 is to detect if the content is protected or free. If it is free, it will be able to play back by module 4.18 for consumption. Otherwise there are three branches to go and check in module 4.3, 4.4, and 4.5, respectively.
Module 4.3 is to detect if the Rights is encrypted, module 4.4 is to detect if the content is encrypted, and module 4.5 is to detect if the content is watermarked.
If the rights is protected, module 4.6 is to invoke the protection tool with ToolID and module 4.7 is to check the integrity of the rights using the tool. If the integrity is successfully verified in module 4.8, the rights will be sent to module 4.9 for parsing the rights by REL Engine which conforms to the existing REL standard.
Module 4.11 is to process the rights and conditions attached to the content and store the entitled rights and conditions in a buffer. In module 4.19 those rights requested by the users are subjected to checking against the rights and conditions stored in the buffer.
If there is license carried in Rights, module 4.10 is to retrieve license from License Manager which may be temper resistant (TR) protected.
If the content is protected and encrypted, module 4.13 is to invoke the encryption tool indicated by ToolID carried in IPMP Control Graph, module 4.14 is to retrieve Key Information, and module 4.12 is to obtaining the key license from License Manager.
License Manager here could be protected by temper resistant technique if it is part of the terminal or somewhere in other places, since it will provide the actual license which the decryption engine will use to un-protect the content.
The encryption tool can be defined as default for most of the terminals to use in their implementation, while an IPMP ToolID is provided so that people can choose other than default encryption tool in their special domain. If the platform is allowed to download and use different encryption tool indicated by ToolID, it would achieve extensibility, flexibility and renewability at the same time we will achieve interoperability across different domains.
Key Information could be retrieved from different places in the case of content delivery via various networks. This will depend on where you place key information. If you place them in RTP header, you can get them there, while if you place them as other packets like video and audio data, you can get them by following the same rules applied to video and audio. The time-variant key information is required to obtain in the same time when you need to decrypt the video and audio content.
Module 4.15 is to decrypt the content with the invoked tool, KeyData, and License, then passed to module 4.17 for further processing.
If the content is detected as watermarked in module 4.5, the watermarking tool with ToolID and its description data including interface will be invoked and prepared in module 4.16 for action which is up to user's request.
Finally module 4.17 is to exercise the rights which user is requested based on the entitled rights & conditions, and act on the un-protected content which is the output of module 4.15.
In
As shown in
Decrypting, watermarking, etc. in module 8.12, could be conducted in module 8.8 if such method is defined in DIME, or in module 8.9 if it is defined as one function of DIBO, or in module 8.10 if it is an external function.
The line 8.14 is shown for the data flow from IPMP Control Graph processing module to REL Engine, and the line 8.15 is shown for the data flow from IPMP Control Graph processing module to NI iNstance.
The line 8.16 is shown for the data flow from License Manager to the un-protecting block in the module 8.12 for issuing a license.
Module 8.13 is for Event Reporting Engine which is placed in the same trusted domain compared to that in
TR means Temper Resistance module to be used to protect License Manager operation and Condition Processing Operation.
Other modules have the similar meaning as explained in
(Content Packaging and Consumption with Mixed Rights and Protection)
In this case, there is no clear boundary between rights and protection, and they are mixed. IPMP Control Graph can be considered as REL-IPMP Control Graph.
Based on the current MPEG-21 REL or other rights expression language, protection of content as well as indicating for how to protect the content is not defined. In this case the existing REL has to be extended to support such protection signaling.
As shown in
Other modules have the same functions as explained above.
As in
When the content is needed to transmit via network, normally it will be segmented, encrypted and stored as Resource somewhere, and the corresponding time-variant key is stored as Key Information in KeyData Holder in REL-IPMP Control Graph in module 5.9 directly or indirectly by pointing to a location.
For example when the protected content is transmitted over RTP, REL-IPMP Control Graph can be carried in SDP (Section Description Protocol), while the key information can be carried in the RTP header or as special case for video and audio packet as long as they are synchronized among time-variant keys and the protected video or audio data.
Module 5.1 is to assign content ID, DII in MPEG-21 could be used here. Module 5.2 is to place a flag in REL-IPMP Control Graph to tell if the content is protected or free. Module 5.3 is to place a flag in REL-IPMP Control Graph to indicate if there is watermarking embedded.
If there is watermarking embedded in the content, module 5.4 will assign watermarking (WM) ToolID for the WM tool used for this case, and ToolID is then recorded and placed in REL-IPMP Control Graph. The module 5.5 will create WM Descriptions including watermarking Interface or API related information which is placed in REL-IPMP Control Graph.
Module 5.6 is to determine if the content will be encrypted, and a flag for “Yes/No” will be placed in REL-IPMP Control Graph in module 5.15.
Module 5.9 is to assign encryption ToolID for the encryption tool used for this case, and ToolID is then recorded and placed in REL-IPMP Control Graph. The module 5.7 is to place Key information in KeyData Holder directly in REL-IPMP Control Graph, or pointing by the Holder to other location.
The encryption key can be further encrypted in module 5.11, and 5.13, and the key as a license is eventually placed in REL-IPMP Control Graph, REL, DID, or somewhere indicated by KeyLocation1.
Module 5.8 is to create and package rights with the corresponding conditions which conforms to the existing REL standard, and this part could be modified and edited by distribution agents in the content distribution value chain.
The module 5.10 is to protect the rights metadata by digitally signing the rights. Module 5.12 is to assign ToolID for the verification of the digital signature, and module 5.14 is to place the Entity_Key in REL-IPMP Control Graph, or in DID, or in somewhere indicated by KeyLocation2.
The detail of module 5.15 is shown in
It can be seen from the
As shown in
Other modules are the same functions as explained in the above.
In
Module 6.1 is to parse DID and REL-IPMP Control Graph information where DID parser is required only for the case REL-IPMP Control Graph is carried in DID in MPEG-21 case.
In the case of content distribution over RTP network, REL-IPMP Control Graph can be retrieved from SDP to obtain rights and protection description information except the key information if it is time-variant.
Module 6.2 is to detect if the content is protected or free. If it is free, it will be able to play back by module 6.18 for consumption. Otherwise there are three branches to go and check in module 6.3, 6.4, and 6.5, respectively.
Module 6.3 is to detect if the Rights is encrypted, module 6.4 is to detect if the content is encrypted, and module 6.5 is to detect if the content is watermarked.
If the rights is protected, module 6.6 is to invoke the protection tool with ToolID and module 6.7 is to check the integrity of the rights using the tool. If the integrity is successfully verified in module 6.8, the rights will be sent to module 6.9 for parsing the rights by REL Engine which conforms to the existing REL standard.
Module 6.11 is to process the rights and conditions attached to the content and store the entitled rights and conditions in a buffer. In module 6.19 those rights requested by the users are subjected to checking against the rights and conditions stored in the buffer.
If there is license carried in Rights, module 6.10 is to retrieve license from License Manager which may be temper resistant (TR) protected.
If the content is protected and encrypted, module 6.13 is to invoke the encryption tool indicated by ToolID carried in REL-IPMP Control Graph, module 6.14 is to retrieve Key Information, and module 6.12 is to obtaining the key license from License Manager.
License Manager here could be protected by temper resistant technique if it is part of the terminal or somewhere in other places, since it will provide the actual license which the decryption engine will use to un-protect the content.
The encryption tool can be defined as default for most of the terminals to use in their implementation, while an IPMP ToolID is provided so that people can choose other than default encryption tool in their special domain or case. If the platform is allowed to download and use different encryption tool indicated by ToolID, it would achieve extensibility, flexibility and renewability at the same time we will achieve interoperability across different domains.
Key Information could be retrieved from different places in the case of content delivery via various networks. This will depend on where you place key information. If you place them in RTP header, you can get them there, while if you place them as other packets like video and audio data, you can get them by following the same rules applied to video and audio. The time-variant key information is required to obtain in the same time when you need to decrypt the video and audio content.
Module 6.15 is to decrypting the content with the invoked tool, KeyData, and License, then passed to module 6.17 for further processing.
If the content is detected as watermarked in module 6.5, the watermarking tool with ToolID and its description data including interface will be invoked and prepared in module 6.16 for action which is up to user's request.
Finally module 6.17 is to exercise the rights which user is requested based on the entitled rights & conditions, and act on the un-protected content which is the output of module 6.15.
In
As shown in
Decrypting, watermarking, etc. in module 9.12, could be conducted in module 9.8 if such method is defined in DIME, or in module 9.9 if it is defined as one function of DIBO, or in module 9.10 if it is an external function.
The line 9.14 is shown for the data flow from REL-IPMP Control Graph processing module to REL Engine, and the line 9.15 is shown for the data flow from REL-IPMP Control Graph processing module to NI iNstance.
The line 9.16 is shown for the data flow from License Manager to the un-protecting block in the module 9.12 for issuing a license.
Module 9.13 is for Event Reporting Engine which is placed in the same trusted domain compared to that in
TR means Temper Resistance module to be used to protect License Manager operation and Condition Processing Operation.
Other modules have the similar meaning as explained in
In
The invention is very effective when content is required to be protected with rights and conditions, especially such content can be in any data form and could be transmitted via various network.
The invention is effective when such protection is required to associate with the protected content via content ID, especially such protection information is defined as a set of descriptions attached to the protected content using content ID, or DII in MPEG-21;
The invention is effective when each of the protection is indicated by ToolID so that both defined IPMP tool and external IPMP Tool can be used for flexibility, renewalbility and extensibility.
The present invention relates to Digital Rights Management (DRM) or Intellectual Property Management and Protection (IPMP) for a generic digital content, especially relates to the protection and management of a digital content independent of any data format. The invention is very effective when content is required to be protected with rights and conditions, especially such content can be in any data form and could be transmitted via various network.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/JP03/13120 | 10/14/2003 | WO | 1/27/2005 |
