WO2010003328A1 - 许可的处理方法及装置 - Google Patents

许可的处理方法及装置 Download PDF

Info

Publication number
WO2010003328A1
WO2010003328A1 PCT/CN2009/071174 CN2009071174W WO2010003328A1 WO 2010003328 A1 WO2010003328 A1 WO 2010003328A1 CN 2009071174 W CN2009071174 W CN 2009071174W WO 2010003328 A1 WO2010003328 A1 WO 2010003328A1
Authority
WO
WIPO (PCT)
Prior art keywords
license
srm
agent
drm agent
updated
Prior art date
Application number
PCT/CN2009/071174
Other languages
English (en)
French (fr)
Inventor
张仁宙
黄晨
袁卫忠
周志鹏
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP09793803A priority Critical patent/EP2299378A4/en
Publication of WO2010003328A1 publication Critical patent/WO2010003328A1/zh
Priority to US12/980,050 priority patent/US8336109B2/en
Priority to US13/540,212 priority patent/US8353055B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/107—License processing; Key processing
    • G06F21/1075—Editing

Definitions

  • Embodiments of the present invention relate to the field of Digital Rights Management (DRM), and in particular, to a method and an apparatus for processing a license. Background technique
  • DRM Digital Rights Management
  • Digital rights management protects the legitimate rights and interests of content owners by controlling the use of digital content through rights restrictions and content protection schemes.
  • the content content Content Issuer, hereinafter referred to as CI
  • the user downloads the encrypted digital content data package to the terminal device;
  • the Rights Issuer (hereinafter referred to as RI) is responsible for distributing the license corresponding to the digital content ( Rights Object, referred to as RO), which includes the content decryption key and corresponding permissions.
  • the device can only use the purchased digital content if it has both a digital content package (which contains the information necessary to decrypt the digital content) and a license.
  • the DRM Agent decrypts the license key using the private key of the device, and then obtains the content key in the license to decrypt the digital content, and controls the specific use of the digital content by the user according to the permission information in the license.
  • the license contains information such as rights, restrictions, keys, digital signatures, and so on. For the same content, you can create multiple different licenses with different permissions. For example, for a certain document file, some licenses have the right to browse, print, and transfer permissions. Some licenses only set Browse rights.
  • Licensed devices can independently consume licenses and use corresponding digital content, and unlicensed devices can also consume licenses in SRM by interacting with a Secure Removable Media (SRM).
  • SRM Secure Removable Media
  • the SRM can be a secure memory card or smart card that can be stored on the SRM so that it can be easily consumed on multiple devices via SRM.
  • the licenses stored on the device there is still a need to transfer the licenses stored on the SRM, for example: Users can transfer the license of some old content on the SRM to their friends, make room for purchase. License for new content.
  • the device transfers the license stored by itself to the SRM, and there are cases where the device transfers the license stored in the SRM to itself.
  • the inventors have found that at least the following defects exist in the prior art: During the transfer process, the device must check the license. Does it indicate "the license is transferable", that is, whether the license has the transfer authority, and whether the license allows the license to be transferred in advance.
  • the terminal cannot transfer the license from the SRM. If the user does not fully consider whether the license needs to be transferred in the future and how many transfers need to be made in the future when purchasing the license, it may result in the inability to transfer the license, which limits the license.
  • An embodiment of the present invention provides a method and an apparatus for processing a license, which are used to implement an application that transfers a license that does not have a transfer right on an SRM from an SRM, and expands a license that does not have a transfer right.
  • a method of updating licenses including:
  • the DRM agent obtains license related information of the license to be updated from the SRM agent;
  • the DRM agent provides the license related information to the RI and obtains a new license from the RI; the DRM agent interacts with the SRM agent, and updates the new license with the new license
  • the license to be updated on the SRM.
  • Another method of updating licenses including: Related information;
  • the RI updates the license to be updated on the SRM with the generated new license.
  • a method of deleting a license including:
  • the DRM agent receives the trigger message sent by the RI, where the trigger message includes an identifier of the license to be deleted on the SRM;
  • the DRM agent interacts with an SRM agent on the SRM to delete the to-be-deleted permission.
  • a method of transferring licenses including:
  • the RI acquires the license-related information of the license to be transferred on the SRM;
  • the RI triggers the DRM agent to delete the to-be-transfer permission on the SRM, and
  • the DRM agent provides the REK of the license to be transferred.
  • Another method of transferring licenses includes:
  • the DRM agent interacts with the SRM agent to obtain license related information of the license to be transferred on the SRM;
  • the DRM agent interacts with the RI, provides the license related information to the RI, and obtains the transfer right to be transferred from the RI;
  • the DRM agent transfers the to-be-transferred license to the device where the DRM agent is located according to the transfer permission.
  • An authorization center that includes:
  • a new license generation module configured to generate a new license according to license-related information of the license to be updated on the SRM obtained through the DRM agent and the SRM agent;
  • a new license providing module for providing the new license to the DRM agent.
  • a digital rights management agent including:
  • a license-related information obtaining module configured to obtain license-related information of the license to be updated on the SRM from the SRM agent, and provide the license-related information to the RI;
  • a first license update module configured to update, by the SRM agent, the to-be-updated license on the SRM by using the new license generated by the RI according to the license related information.
  • Another type of authorization center including:
  • a new license generation module configured to generate a new license according to license-related information of the license to be updated on the SRM obtained through the DRM agent and the SRM agent;
  • a second license update module configured to update, by the DRM agent and the SRM agent, the license to be updated on the SRM by using the new license.
  • Another digital rights management agent including:
  • a license-related information obtaining module configured to obtain license-related information of the license to be updated on the SRM from the SRM agent, and provide the license-related information to the RI;
  • a new license acquisition module for obtaining a new license generated from the license-related information from the RI.
  • Another digital rights management agent including:
  • a receiving module configured to receive a trigger message sent by the RI, where the trigger message includes an SRM The identifier of the license to be deleted;
  • a deleting module configured to notify the SRM agent to delete the to-be-deleted license.
  • And another authorization center including: the license-related information, triggering the DRM agent to delete the to-be-transferred license on the SRM by using the SRM agent;
  • the REK providing module is configured to provide the DRM agent with the REK of the to-be-transferred license.
  • Another digital rights management agent including:
  • a license-related information obtaining module configured to obtain license-related information of the license to be updated on the SRM from the SRM agent, and provide the license-related information to the RI;
  • a REK obtaining module configured to receive the REK of the to-be-transfer permission provided by the RI.
  • a 4 authorized center including:
  • a transfer authority generating module configured to generate, according to the license-related information of the license to be transferred on the SRM by the DRM agent and the SRM agent, the transfer permission of the to-be-transferred license;
  • a transfer permission providing module configured to provide the DRM agent with the transfer right of the transfer permission.
  • digital rights management agent including:
  • a license-related information obtaining module configured to obtain license-related information of the license to be updated on the SRM from the SRM agent, and provide the license-related information to the RI;
  • a license transfer module configured to receive the transfer permission of the to-be-transfer permission provided by the RI, where the agent is located.
  • the embodiment of the present invention interacts with the RI by using the information related to the license that does not have the transfer authority stored on the SRM obtained by the DRM agent, and transfers the license from the SRM, so that the transfer can be performed without the transfer. Permissions for permissions are transferred from SRM, extending the use of licensed applications that do not have transfer permissions.
  • DRAWINGS The drawings used in the examples or the description of the prior art are briefly introduced. It is obvious that the drawings in the following description are only some embodiments of the present invention, and are not creative to those skilled in the art. Other drawings can also be obtained from these drawings on the premise of labor.
  • FIG. 1 is a schematic flowchart of a first embodiment of a method for updating a license according to an embodiment of the present invention
  • FIG. 2 is a schematic flowchart of a second embodiment of a method for updating a license according to an embodiment of the present invention
  • a flow chart of an embodiment of an interaction protocol in a second embodiment of a method for updating a license
  • FIG. 4 is a schematic flowchart of a first embodiment of a method for updating a license according to an embodiment of the present invention
  • FIG. 5 is a schematic flowchart of a second embodiment of a method for updating a license according to an embodiment of the present invention
  • EMBODIMENT OF THE INVENTION A flow chart after the implementation of the interaction protocol in the second embodiment of the method for updating the license;
  • FIG. 7 is a schematic flowchart diagram of an embodiment of a method for deleting a license according to an embodiment of the present invention.
  • FIG. 8 is a schematic flowchart of a first embodiment of a method for transferring a license according to an embodiment of the present invention
  • FIG. 9 is a schematic flowchart of a second embodiment of a method for transferring a license according to an embodiment of the present invention
  • FIG. 11 is a schematic flowchart of a first embodiment of a method for transferring a license according to an embodiment of the present invention
  • FIG. 12 is a schematic flowchart of a second embodiment of a method for transferring a license according to an embodiment of the present invention
  • a schematic diagram of a process after the interaction protocol is embodied
  • FIG. 14 is a schematic structural diagram of an embodiment of an authorization center according to an embodiment of the present invention.
  • FIG. 15 is a schematic structural diagram of an embodiment of a digital rights management agent according to an embodiment of the present invention
  • FIG. 16 is a schematic structural diagram of another embodiment of an authorization center according to an embodiment of the present invention
  • FIG. 17 is a schematic structural diagram of another embodiment of a digital rights management agent according to an embodiment of the present invention
  • FIG. 18 is a schematic structural diagram of another embodiment of a digital rights management agent according to an embodiment of the present invention. Schematic diagram of the structure of the authorization center embodiment;
  • FIG. 20 is a schematic structural diagram of another embodiment of a digital rights management agent according to an embodiment of the present invention
  • FIG. 21 is a schematic structural diagram of an embodiment of an authorization center according to an embodiment of the present invention
  • FIG. 22 is a schematic structural diagram of an embodiment of a digital rights management agent according to an embodiment of the present invention
  • FIG. FIG. 23 is a schematic structural diagram of an embodiment of a secure removable media proxy according to an embodiment of the present invention
  • FIG. 24 is a schematic structural diagram of another embodiment of a secure removable media proxy according to an embodiment of the present invention.
  • the RI acquires the license-related information of the license to be updated on the above SRM, and replaces the license to be updated on the above SRM with the generated new license.
  • the license to be updated may be a license that lacks transfer authority, and accordingly, the new license may be a license with transfer authority.
  • the embodiment of the present invention may further pass the above
  • the SRM agent interacts with the DRM agent or another DRM agent to transfer the new license with the transfer authority to the device where the DRM agent is located or the device of the other DRM agent.
  • FIG. 1 is a schematic flowchart of a first embodiment of a method for updating a license according to an embodiment of the present invention. As shown in FIG. 1 , the embodiment may include the following steps: performing interaction to obtain related information of a license to be updated on an SRM;
  • Step 102 The DRM agent interacts with the RI by using the related information of the license to be updated, and obtains a new license generated according to the related information from the RI.
  • Step 103 The DRM agent interacts with the SRM agent, and updates the to-be-updated license on the SRM by using the new license.
  • Step 201 The RI sends a license update trigger message to the DRM agent to trigger the DRM agent to update the license in the SRM.
  • the trigger message may include an identifier of the license to be updated, so that the DRM agent knows which license to update when receiving the trigger message.
  • the terminal user Before the RI sends the trigger message, the terminal user needs to access the RI website by means of the device or other device where the DRM agent is located, submits his own request for updating the license in the SRM, and the related information of the new license that needs to be supplemented, and the RI performs some calculations. After the fee-related operation, the trigger message can be sent to the DRM agent.
  • This step is an optional step, and this embodiment can also start directly from step 202.
  • the trigger message may further include an indication information for indicating whether the RI saves a Rights Encryption Key (REK) corresponding to the previously issued license, and the REK is used to encrypt the content encryption key (Content Encryption Key (CEK), which forms an encrypted CEK placement license;
  • REK Rights Encryption Key
  • CEK Content Encryption Key
  • Step 202 The DRM agent interacts with the SRM agent to prepare to update a certain license on the SRM.
  • the foregoing preparation may at least include: the DRM agent instructs the SRM agent to set the pending update permission to be unavailable, so that the pending update cannot be any
  • the device is used to consume the corresponding content.
  • the DRM agent may obtain from the SRM agent a certificate of existence of "there is a license to be updated on the SRM", the certificate containing part or all of the information of the license to be updated and the digital signature of some or all of the information of the license by the SRM agent .
  • the partial information of the license mentioned here may be the REK or the license identifier of the license.
  • the DRM agent may send the certificate to the RI, and the RI verifies the digital signature of the part or all of the information that the SRM contains in the license. If the digital signature is verified correctly, it is determined that the license to be updated exists in the SRM.
  • the digitally signed data of the SRM in the certificate may further include a timestamp to prevent the DRM agent from repeatedly using the same presence certificate to "cheat" the license from the RI.
  • the SRM agent should also encrypt the REK with the public key of the RI, together with the presence certificate. Issued to the DRM agent;
  • Step 203 The DRM agent interacts with the RI to obtain a new license for replacing the license to be updated on the SRM, where the new license includes the transfer authority.
  • the DRM agent can update the license to be updated, RI
  • the digital signature of the original license and the status information of the license to be updated are sent to R1.
  • the DRM agent may also send the above proof of presence provided by the SRM agent to the RI to prove to the RI that the license to be updated does exist on the SRM.
  • the RI verifies that the existence certificate passes and determines that there is indeed a license to be updated on the SRM
  • a new license is generated and sent to the DRM agent, wherein the newly licensed REK is encrypted by the way that the DRM agent cannot be finally decrypted, such as the SRM public.
  • the key is encrypted and then further encrypted with the public key of the DRM agent.
  • the DRM agent should also send the REK encrypted by the SRM agent with the public key of the RI to the RI. In order for the RI to verify the presence certificate provided by the SRM agent without exposing the REK to the DRM agent.
  • the DRM agent can also send the end user information about the new license, such as: what kind of transfer authority is required, to the RI, so that the RI can generate a new license that meets the requirements of the end user;
  • Step 204 The DRM agent interacts with the SRM agent to replace the pending license on the SRM with the new license.
  • the DRM agent may pre-process the new license sent by the RI, for example: verifying the digital signature of the new license by the RI, and then requesting the SRM agent to request the new license obtained from the RI to replace the license to be updated on the SRM. During the replacement process, SRM needs to decrypt and save the encrypted REK with its own private key;
  • Step 205 The DRM agent interacts with the RI, and confirms to the RI that the license has been replaced. This step is an optional step, and the embodiment may also directly jump to step 206 to execute;
  • Step 206 The DRM agent interacts with the SRM agent to transfer the new license from the SRM to the device where the DRM agent is located or to other devices.
  • FIG. 3 is a schematic flowchart of the implementation of the interaction protocol in the second embodiment of the method for updating the license according to the embodiment of the present invention. It is assumed that the RI does not cache the previously published REK. As shown in FIG. 3, the specific process may include the following steps. :
  • Step 301 The DRM agent sends a license information query request ( RightslnfoQueryRequest ) message to the SRM agent.
  • Step 302 After receiving the license information query request message, the SRM agent returns a license information query response ( RightsInfoQueryResponse) message to the DRM agent.
  • the DRM agent obtains all information about the license RO to be updated except the REK from the SRM, including: ⁇ rights> element, digital signature of the RI pair ⁇ 1 ⁇ 5> element, licensed Meta Data, and corresponding State Information (if the license is stateful).
  • the field included in the license information query request message sent by the DRM agent in step 301 can be as shown in Table 1:
  • Handle A unique identifier that is licensed on the SRM.
  • the field information contained in the license information query response message returned by the SRM agent in step 302 can be as shown in Table 2:
  • the SRM agent processes the results of the license information query request message. If an error occurs, only this field appears in the license information inquiry response message.
  • Metadata for Permission Metadata (License Meta Data), including the following information:
  • the Rights Object contains a container for the ⁇ rights> element and the ⁇ signature> element.
  • State Information The remaining status information of the license, such as how many playback rights remain. This field does not appear if the license is stateless.
  • Step 303 After receiving the license information query response message, the DRM agent can learn that the license RO does not have the transfer right according to the ⁇ 1 ⁇ > element and the state information of the license (State Information).
  • the DRM agent can find that the license RO does not have the transfer authority by analyzing the ⁇ rights> element and the status information of the license.
  • the device can prompt the user to update the RO by popping up the dialog box.
  • Step 304 The user logs in to the website provided by the RI through the device or other device of the DRM agent, and submits a request for updating the RO on the SRM through the page provided by the website.
  • the user can specify the identity of the license to be updated through the web page, what permissions need to be supplemented, and the like.
  • Step 305 After performing operations such as charging, the RI pushes an SRM license update trigger (SRMROUpgradeTrigger) message to the DRM agent, and the trigger message may be used to trigger the DRM agent to update the license R0 on the SRM.
  • SRM license update trigger SRMROUpgradeTrigger
  • the fields included in the SRM license update trigger message can be as shown in Table 3:
  • Step 306 After receiving the SRM license update trigger message, the DRM agent sends a license update preparation request (RightsUpgradeSetupRequest) message to the SRM agent.
  • the DRM agent can send a license update preparation request message to the SRM agent in two ways: Manner 1: According to the upgradelnfo field in the SRM license update trigger message, the user is displayed with the permission information that he has specified that needs to be supplemented, and is sent by the user after confirmation;
  • Method 2 Send directly without confirmation by the user.
  • the fields included in the license update preparation request message can be as shown in Table 4:
  • Step 307 After receiving the license update preparation request message, the SRM agent overwrites the existing Handle field by using a New Handle field.
  • the SRM agent can further set R0 to an unavailable state. Because the permission is set to the unavailable state, the Handle and other fields are not allowed to be queried, further ensuring that R0 is not accessed by other devices.
  • the DRM agent Since the SRM license update trigger message sent by the RI includes the REKNeeded field, the DRM agent also includes it in the license update preparation request message to indicate to the SRM agent that the RI does not cache the previously issued REK, and the SRM agent proceeds in the next step. In the middle, you need to send a REK. If the RI is able to cache all published REKs, the REKNeeded field will not need to be transmitted;
  • Step 308 The SRM agent sends a license update preparation response ( RightsUpgradeSetupResponse ) message to the DRM agent.
  • the fields included in the license update preparation response message can be as shown in Table 5:
  • Status indicates whether the SRM agent successfully processed the license update preparation request message. If an error occurs, the response message will only contain the field, and subsequent fields will not be included.
  • Encrypted REK EncryptedREK
  • the ExistProof field is used to prove that the license to be updated on the SRM is an optional field;
  • the certificate includes all the information of the license to be updated and the digital signature of all the information of the SRM to be updated, or part of the information of the license to be updated and the SRM
  • the digital signature of the information of the updated license part may be the REK of the license to be updated, the identifier of the license to be updated, or the combination of the REK of the license to be updated and the identifier of the license to be updated.
  • Step 309 After receiving the license update preparation response message, the DRM agent sends an SRM license update request (SRMROUpgradeRequest) message to the RI.
  • SRMROUpgradeRequest SRM license update request
  • the fields included in the SRM license update request message can be as shown in Table 6:
  • the EncryptedREK field can be used by the RI to verify whether the end user's device (the DRM agent is located on the device or SRM, but who does not know who it is) really has the license to be updated, because the RI only needs to decrypt the encryptedCEK in the ⁇ rights> element. Successful decryption indicates end user The device has the license to be updated, and vice versa. It can also be used by the RI to verify the ExistProof field. When the RI does not back up the REK of the license to be updated that it has released, the RI needs to decrypt the original text of the REK from the EncryptedREK to verify the ExistProof.
  • the value of the upgradelnfo field in the foregoing SRM license update request message may be in two cases: When the DRM agent performs the RO update operation triggered by the SRM license update trigger message, the value of the upgradelnfo field is taken from the SRM license update trigger message. The value of the same-named field in the field; when the DRM agent does not perform the RO update operation triggered by the SRM license update trigger message, the device needs to display a friendly user interface for the user to specify the update requirement for the license RO, and the value of the upgradelnfo field will be taken From the above user interface.
  • Step 310 After receiving the SRM license update request message, the RI verifies the digital signature of the ⁇ rights> element and the presence certificate.
  • Step 311 After the foregoing verification is passed, the RI constructs a new RO according to the upgradelnfo field, and sends the message to the DRM agent through an SRM License Update Response (SRMROUpgradeResponse) message.
  • SRMROUpgradeResponse SRM License Update Response
  • the REK in the new R0 is not the same as the REK in the original R0 to be updated.
  • the fields included in the SRM license update response message can be as shown in Table 7:
  • the REK in the new license should be different from the REK of the license to be updated.
  • the encryption algorithm is as follows:
  • ⁇ KDF(I20SP(Z X , mLen SRM ), NULL, kekLen)
  • mLen SRM is the modulus of the SRM certificate
  • the kekLen and KDF() functions can refer to the OMA DRM standard document OMA-TS-DRM_DRM-V2_1-20070919-C.doc;
  • C x1 l20SP (RSA.ENCRYPT (PubKey SRM , Z x ), mLen SRM );
  • the I20SP() function, RSA.ENCRYPT() function can refer to the above DRM standard document;
  • EncREK C x1
  • KEK KDF (I20SP (Z, mLen Surround Agent ), NULL, kekLen);
  • ⁇ 11_613 ⁇ 4 ⁇ is the modulus of the DRM proxy certificate, and the kekLen and KDF() functions can refer to the above DRM standard document;
  • K KMAC I EncREK
  • d l20SP (RSA.ENCRYPT (PubKey DRM Agent, Z), mLen DRMAgent ); and C- Ci I ⁇ 2.
  • Rl carries C in the new license and sends it to the DRM agent. After receiving the C, the DRM agent can use its own private key to finally get the EncREK and pass it to the SRM agent. The SRM agent can then use its own private key to get the REK.
  • Step 312 After receiving the new RO that meets the user requirement, the DRM agent performs pre-processing on the new RO.
  • the foregoing pre-processing includes the following steps:
  • the EncryptedREK field is the result of the RI encrypting the REK using the public key of the SRM agent; If the security requirements are appropriately lowered, the above newly licensed REKs can also be encrypted without further public key use of the SRM agent.
  • Step 313 After completing the foregoing pre-processing, the DRM agent sends a license replacement request ( RightsReplaceRequest) message to the SRM agent.
  • a license replacement request RightsReplaceRequest
  • the fields included in the license replacement request message can be as shown in Table 8:
  • Step 314 After receiving the license replacement request message, the SRM agent replaces the original license to be updated with the new license.
  • Method 1 According to the size field, create a new storage slot for storing the new license, corresponding to the handle field as a temporary handle, then store the new license in the new storage slot, and then store the existing original storage.
  • the slot (that is, the storage slot corresponding to the value of the handle field in the license replacement request message) is deleted, and then the temporary handle is overwritten by the value corresponding to the handle field in the license replacement request message;
  • Method 2 First delete the existing original storage slot (that is, the storage slot corresponding to the value of the handle field in the license replacement request message), and then create a new storage slot according to the size field, and the value of the corresponding handle is in the above license replacement request message. The value of the handle field, and then store the new license in a new slot.
  • the new license is stored in the new storage slot process. If the REK in the previous SRM license update response is further encrypted with the public key of the SRM agent, the difference from the OMA SRM 1.0 standard is Before the SRM agent stores the REK, it needs to decrypt the EncryptedREK field with its own private key, and then store the decrypted result to In the storage slot; otherwise the SRM agent stores the REK directly without a decryption process.
  • Step 315 The SRM agent returns a license replacement response ( RightsReplaceResponse ) message to the DRM agent.
  • the fields included in the license replacement response message can be as shown in Table 9:
  • the ReplaceProof field is used to prove that the new license has replaced the existing license to be updated on the SRM, and is an optional field;
  • the certificate includes the following combination of information and the digital signature of the SRM: ⁇
  • the old licensed REK (the REK of the license to be updated) and/or the identifier of the old license (ie the identifier of the license to be updated)
  • Step 316 After receiving the license replacement response message, the DRM agent sends an SRM license update confirmation request (SRMROUpgradeConfirmRequest) message to the RI to confirm to the RI that the new license has successfully replaced the original license on the SRM.
  • SRMROUpgradeConfirmRequest SRM license update confirmation request
  • the fields included in the SRM License Update Confirmation Request message can be as shown in Table 10:
  • the ReplaceProof field is used to prove that the new license has been replaced on the SRM that has been updated.
  • the license is an optional field; see step 315 for the form of the proof.
  • Steps 314-316 are to replace the old and new licenses by a pair of messages.
  • the inventor believes that the two pairs of messages can also be implemented, that is, the DRM agent sends a message to the SRM agent, and the SRM agent is required to delete the generation update license; After deletion, the DRM agent resends the message to the SRM agent, transmits the new license to the SRM agent, and the new license is installed into the SRM by the SRM agent.
  • the DRM agent obtains the deletion certificate of the license to be updated and the installation certificate of the new license from the SRM agent.
  • the removal certificate contains the following combination of information and the digital signature of the SRM:
  • the REK of the license is deleted; (ie the REK of the license to be updated)
  • the identifier of the deleted license (ie the identifier of the license to be updated)
  • the installation certificate contains the following combination of information and the digital signature of the SRM:
  • the identifier of the license being installed (ie the identifier of the new license)
  • Step 317 After receiving the SRM license update confirmation request message, the RI verifies the replacement certificate or the deletion certificate and the installation certificate provided by the SRM agent.
  • Step 318 After the above verification is passed, the RI returns a SRM License Upgrade Confirmation Response (SRMROUpgradeConfirmResponse) message to the DRM Agent.
  • SRMROUpgradeConfirmResponse SRM License Upgrade Confirmation Response
  • the fields included in the SRM License Update Confirmation Response message can be as shown in Table 11:
  • Step 319 After receiving the SRM license update confirmation response message, the DRM agent may transfer the updated new license to the DRM agent by using the UM SRM1.0 Push Move protocol immediately or at some future time. On the device where it is located.
  • the user can insert the SRM onto another device and then perform a Pull Move operation.
  • the above DRM agent obtains a new RO from the RI, and may also implement the method of adding a new message, that is, an SRM license update request message and an SRM license update response message, to the existing OMA SRM1.0 standard in steps 309 and 310. Instead, modify the message in the existing ROAP-RO Upgrade Protocol, and use the Extension field in the message to pass the field or data to be delivered, which can achieve the same effect;
  • the above DRM agent replaces the original license on the SRM with a new license, and may also use the method of adding a new message, that is, a license replacement request message and a license replacement response message, to the existing OMA SRM1.0 standard in steps 313 and 315.
  • a new message that is, a license replacement request message and a license replacement response message
  • Implementation, but using two pairs of messages to achieve that is, first install the new license that is the license installation request ( RightslnstallRequest) message and the license installation response ( RightslnstallResponse ) message, and then delete the existing original license that is the permission removal request ( Rights Removal Request) Message and permission delete response (Rig htsRemoval Response) message.
  • the SRM agent needs to decrypt the EncryptedREK field using the private key of the SRM agent, and the DRM agent in the OMA SRM1.0 standard is passed to the SRM.
  • the agent can store the REK directly instead of the REK encrypted with the SRM proxy public key.
  • FIG. 4 is a schematic flowchart of another embodiment of a method for updating a license according to an embodiment of the present invention. As shown in FIG. 4, this embodiment may include the following steps:
  • Step 401 The DRM agent interacts with the SRM agent to obtain license related information of the license to be updated on the SRM.
  • Step 402 The RI triggers the DRM agent to interact with the SRM agent to delete the to-be-updated license on the SRM.
  • Step 403 The RI triggers that the DRM agent obtains, from the RI, the new license generated according to the related information to be installed on the SRM.
  • This embodiment expands the licensed application by deleting the license on the SRM and replacing it with the new license, so that it can have some new operation authority, and the license can be updated.
  • FIG. 5 is a schematic flowchart of a second embodiment of a method for updating a license according to an embodiment of the present invention.
  • this embodiment may include the following steps:
  • Step 501 The RI sends a permission deletion trigger message to the DRM agent to trigger the DRM agent to delete the license on the SRM.
  • the trigger message may include an identifier of the original license to be deleted, so that the DRM agent knows which license to delete when receiving the trigger message.
  • the end user needs to access the RI website by means of the DRM agent's device or other device, submit a request for transferring the license in SRM to himself, and information about the new license that needs to be supplemented, RI After some operations such as billing, the trigger message can be sent to the DRM agent.
  • This step is an optional step, and the embodiment may also start directly from step 502;
  • Step 502 The DRM agent interacts with the SRM agent to delete the license on the SRM.
  • the DRM agent can obtain a deletion certificate of "The license has been deleted for the SRM agent" from the SRM agent.
  • For the form of the certificate refer to the description in step 316.
  • Step 503 The DRM agent interacts with the RI, and reports to the RI that the license to be updated is deleted. Preferably, for security reasons, the DRM agent should provide the RI with the proof of deletion described above in step 502. After verifying that the certificate is passed, the RI can determine that the license to be updated has been deleted from the SRM and send a new license to the DRM agent; Step 504: R1 installs a new license including the authority already in the license to be updated, and the transfer permission required by the user to the SRM through the DRM agent.
  • Step 505 The DRM agent interacts with the SRM agent to transfer the new license from the SRM to the device where the DRM agent is located, or another DRM agent interacts with the SRM agent to transfer the new license from the SRM to another DRM agent. On the device.
  • This embodiment is similar to the embodiment of the method for updating the permission permission of the present invention, and also by updating the license in the SRM that does not have the transfer permission, so that the transfer permission is sufficient, and then the license is transferred, and the update is implemented.
  • the separation of the transfer after the license is updated to have the transfer authority, the license is transferred to the device where the DRM agent is located, and the license that does not have the transfer permission can be transferred from the SRM, thereby expanding the application of the license without the transfer permission.
  • the update method in this embodiment is different, that is, the RI triggers the DRM agent to delete the license on the SRM, and then the RI over the DRM agent installs the new license to the SRM.
  • FIG. 6 is a schematic flowchart of a specific implementation of an interaction protocol in a second embodiment of a method for updating a license according to an embodiment of the present invention. As shown in FIG. 6, the specific process may include the following steps:
  • Step 601 The DRM agent sends a license information query request message to the SRM agent, where the license information query request message includes a Handle field.
  • Step 602 After receiving the license information query request message, the SRM agent returns a license information query response message to the DRM agent, where the license information query response message includes a permission metadata (Permission Meta Data) field, and a rights object container. Field, status information field.
  • Permission Meta Data Permission Meta Data
  • the DRM agent obtains all information about the license R0 to be deleted except the REK from the SRM, including: ⁇ rights> element, signature of the RI pair ⁇ 1 ⁇ 5> element, licensed element Statistics (Rights Meta Data), and corresponding State Information (if the license is stateful);
  • Step 603 After receiving the license information query response message, the DRM agent can know that the license R0 does not have the transfer right according to the ⁇ ! ⁇ > element and the state information of the license (State Information).
  • the DRM agent can find that the license R0 does not have the transfer right by analyzing the ⁇ rights> element and the status information of the license.
  • Device can be popped up In the way of the dialog box, the user is prompted to update the RO.
  • Step 604 The user logs in to the website provided by the RI through the device or other device of the DRM agent, and submits a request for updating the RO on the SRM through the page provided by the website.
  • the user can specify the identifier of the license to be updated through the webpage, what kind of authority needs to be supplemented, and the like;
  • Step 605 After performing operations such as charging, the RI pushes an SRM license deletion trigger (SRMRORemovalTrigger) message to the DRM agent, and the trigger message may be used to trigger the DRM agent to delete the license RO on the SRM.
  • the SRM license deletion trigger message includes a ROID field and a REKNeeded field;
  • the trigger message may further include a hyperlink indicating the reason for deleting the license or pointing to the reason, so that after the DRM agent receives the trigger message, the DRM agent device may display the reason for the deletion to the terminal user. For example, the user has previously submitted a request for updating the license through the web page.
  • Step 606 After receiving the SRM permission deletion trigger message, the DRM agent sends a permission deletion request ( RightsRemovalRequest) message to the SRM agent, where the permission deletion request message includes a Handle field and a ProofNeeded field;
  • a permission deletion request RightsRemovalRequest
  • Step 607 The SRM agent sends a permission deletion response ( RightsRemovalResponse) message to the DRM agent, where the permission deletion response message includes a Status field and a Proof of Removal field;
  • Step 608 After receiving the permission deletion response message, the DRM agent sends an SRM permission deletion request (SRMRORemovalReportRequest) message to the RI, where the SRM permission deletion report request message includes a ROID field, a ⁇ rights> element, a ⁇ signature> element, and a Proof of Removal.
  • SRM permission deletion request SRMRORemovalReportRequest
  • Step 609 After receiving the SRM permission deletion report request message, the RI returns an SRM license deletion report response (SRMRORemovalReportResponse) message to the DRM agent.
  • SRM license deletion report response SRMRORemovalReportResponse
  • Step 610 The RI sends a license acquisition trigger (ROAquisitionTrigger) message to the DRM agent, where the license acquisition trigger message includes a ROID field;
  • ROAquisitionTrigger license acquisition trigger
  • Step 611 The DRM agent sends a permission request (RORequest) message to the RI to obtain a new permission to be transferred, and the permission request message includes a ROID field;
  • Step 612 After receiving the permission request message, R1 returns a license response (ROResponse) message to the DRM agent to provide a new license bound to the SRM agent to the SRM through the DRM agent;
  • ROResponse license response
  • Step 613 After receiving the new RO, the DRM agent performs pre-processing on the new RO, and the foregoing pre-processing includes steps of verifying the integrity of the license;
  • Step 614 After completing the foregoing pre-processing, the DRM agent sends an installation preparation request (Install SetupRequeset) message to the SRM agent, where the installation preparation request message includes a Handle field and a Size field;
  • Step 615 After receiving the installation preparation request message, the SRM agent returns an installation preparation response (Install SetupResponse) message to the DRM agent, where the installation preparation response message includes a Status field;
  • Step 616 After receiving the installation preparation response message, the DRM agent sends a license installation request ( RightslnstallationSetupRequeset) message to the SRM agent, where the license installation request message includes a Handle field, a Rights Information field, and a REK bound to SRM Agent field.
  • a license installation request ( RightslnstallationSetupRequeset) message
  • the license installation request message includes a Handle field, a Rights Information field, and a REK bound to SRM Agent field.
  • Step 617 After receiving the license installation request message, the SRM agent returns a license installation response ( RightslnstallationSetupResponse) message to the DRM agent, where the license installation response message includes a Status field;
  • Step 618 The DRM agent interacts with the SRM agent to transfer the new license from the SRM. After receiving the license installation response message, the DRM agent can transfer the updated new license to the device where the DRM agent is located, either immediately or at some time in the future.
  • FIG. 7 is a schematic flowchart of a method for deleting a license according to an embodiment of the present invention. As shown in FIG. 7, the embodiment may include the following steps:
  • Step 701 The DRM agent on the terminal device receives the trigger message sent by the RI, where the trigger message includes an identifier of the license to be deleted on the SRM.
  • Step 702 The DRM agent interacts with the SRM agent on the SRM, and deletes the to-be-deleted license.
  • the DRM agent interacts with the SRM agent on the SRM according to the identifier of the to-be-removed license on the SRM included in the received trigger message, and deletes the to-be-deleted license, so that the license on the SRM can be deleted.
  • a new license is installed, thereby expanding the licensed application.
  • FIG. 8 is a schematic flowchart of a first embodiment of a method for transferring a license according to an embodiment of the present invention. As shown in FIG. 8, the embodiment may include the following steps:
  • Step 801 Obtain, by using a DRM agent on the terminal device and an SRM agent on the SRM, the RI obtains license-related information about the to-be-transferred license on the SRM.
  • Step 802 The RI triggers the DRM agent to delete the to-be-transferred license on the SRM, and provides the REK agent with the REK to be transferred.
  • the DRM agent is triggered to delete the license to be transferred, and the REK agent is provided with the REK to be transferred, so that the DRM agent can be new according to the related information and the REK.
  • the license is installed on SRM, which enables the transfer of licenses that do not have transfer rights from SRM, thus extending the license application.
  • FIG. 9 is a schematic flowchart of a second embodiment of a method for transferring a license according to an embodiment of the present invention. It is assumed that an RI cache has a previously issued REK, and a license (RO) issued by the RI and having no transfer permission exists on the SRM. The user of the Device wants to transfer the RO to the device. As shown in FIG. 9, the embodiment may include the following steps:
  • Step 901 The RI sends a trigger message to the DRM agent to trigger the DRM agent to obtain the REK corresponding to the license from the RI.
  • the trigger message may include an identifier of the license, so that the DRM agent knows which license corresponding REK will be acquired when receiving the trigger message.
  • the terminal user Before the RI sends the trigger message, the terminal user needs to access the RI website by means of the device or other device where the DRM agent is located, and submits a request for transferring the license in the SRM to the user. After the RI performs some operations such as charging, the terminal can perform the operation. Send the trigger message to the DRM agent.
  • This step is an optional step, and the embodiment may also start directly from step 902;
  • Step 902 The DRM agent interacts with the SRM agent to delete the license on the SRM.
  • the DRM agent may obtain, from the SRM agent, a certificate that "the above license exists on the SRM and the license has been deleted for the SRM agent", and the certificate may be in the form of an SRM generation.
  • the certificate may further include a time stamp to prevent the DRM agent from repeatedly using the certificate and then "frauding" the license from the RI, etc., that is, the signature range of the SRM agent may include a time stamp;
  • Step 903 The DRM agent interacts with the RI to obtain a REK corresponding to the license.
  • the DRM agent should provide the RI with proof that "there is a corresponding license on the SRM and the license has been deleted by the SRM agent".
  • the RI sends a REK (that is, a REK encrypted with the DRM agent's public key) bound to the DRM agent to the DRM agent.
  • This REK should be the same as the REK previously stored in the SRM.
  • Step 904 The DRM agent installs the license according to the related information of the license and the REK of the license.
  • the DRM agent obtains the relevant information of the license from the SRM agent, that is, the information other than the REK, deletes the license on the SRM, and then obtains the REK from the RI, and then installs according to the information about the obtained license and the REK. Licensing also extends the ability to transfer licenses that do not have transfer rights from the SRM to the device where the DRM agent is located, thereby extending the licenses that do not have permission to transfer.
  • FIG. 10 is a schematic flowchart of a specific implementation of an interaction protocol in a second embodiment of a method for transferring a license according to an embodiment of the present invention. As shown in FIG. 10, the specific process may include the following steps:
  • Step 1001 The DRM agent sends a license information query request message to the SRM agent.
  • the DRM agent obtains all information about the license RO to be deleted except the REK from the SRM, including: ⁇ rights> element, signature of the RI on the ⁇ 1 ⁇ > element, and the permitted element Data (Meta Data), and corresponding State Information (if the license is stateful).
  • the field included in the license information query request message sent by the DRM agent in step 1001 may be as shown in Table 12:
  • Handle A unique identifier that is licensed on the SRM.
  • the field information contained in the license information query response message returned by the SRM agent in step 1002 may be as shown in Table 13:
  • Metadata for Permission Metadata (License Meta Data), including the following information:
  • the Rights Object contains a container for the ⁇ rights> element and the ⁇ signature> element.
  • State Information The remaining status information of the license, such as how many playback rights remain. This field does not appear if the license is stateless.
  • Step 1003 After receiving the license information query response message, the DRM agent can learn that the license RO does not have the transfer permission according to the ⁇ rights> element and the status information of the license (State Information).
  • the DRM agent After receiving the license information inquiry response message, the DRM agent can find that the license RO does not have the transfer authority by analyzing the ⁇ rights> element and the status information of the license.
  • the device can prompt the user to delete the RO by popping up the dialog box.
  • Step 1004 The user logs in to the website provided by the RI through the device or other device where the DRM agent is located, and submits a request for transferring the R0 on the SRM through the page provided by the website.
  • the user can specify the identity of the license to be transferred, etc. through a web page.
  • Step 1005 After performing operations such as charging, the RI pushes a REK touch to the DRM agent.
  • the REKTrigger message may be used to trigger the DRM agent to obtain the REK corresponding to the license from the RI.
  • the fields contained in the REK trigger message can be as shown in Table 14:
  • Step 1006 After receiving the REK trigger message, the DRM agent sends a Rig htsRemoval Request message to the SRM agent.
  • the fields contained in the license deletion request message can be as shown in Table 15:
  • Step 1007 After receiving the license deletion request message, the SRM agent returns a permission deletion response ( RightsRemovalResponse) message to the DRM agent.
  • a permission deletion response RightsRemovalResponse
  • the fields contained in the license deletion response message can be as shown in Table 16:
  • the RemovalProof field above is used to prove that the license has been removed from the SRM, and the certificate contains the signature of the SRM for the following combination of information:
  • Step 1008 After receiving the permission deletion response message, the DRM agent sends a REK request message to the RI.
  • the fields contained in the REK request message can be as shown in Table 17:
  • Step 1009 After receiving the REK request message, the RI returns a REK response to the DRM agent.
  • the fields contained in the REK response message can be as shown in Table 18:
  • the above EncryptedREK field is a REK encrypted using a DRM proxy public key, and the REK is used to decrypt the EncryptedCEK in the ⁇ > element in the REK request message;
  • Step 1010 The DRM agent installs the license according to the license related information and the licensed REK.
  • FIG. 11 is a schematic flowchart of a first embodiment of a method for transferring a license according to an embodiment of the present invention. As shown in FIG. 11, the embodiment may include the following steps:
  • Step 1101 The DRM agent on the terminal device interacts with the SRM agent on the SRM, and obtains license-related information about the license to be transferred on the SRM.
  • Step 1102 The DRM agent interacts with the RI, provides the license related information to the RI, and obtains a transfer right from the RI indicating that the RI allows the DRM agent to transfer the to-be-transferred permission;
  • Step 1103 The DRM agent transfers the to-be-transferred license to the device where the DRM agent is located according to the transfer permission.
  • the DRM agent applies to the RI according to the obtained license related information of the license to be transferred. Please transfer the license. After obtaining the approval of the RI, the license is forcibly transferred from the SRM to the device where the DRM agent is located. This realizes that the license without the transfer authority can be transferred from the SRM, thereby expanding the license. application.
  • FIG. 12 is a schematic flowchart of a second embodiment of a method for transferring a license according to an embodiment of the present invention. As shown in FIG. 12, the embodiment may include the following steps:
  • Step 1201 The RI sends a trigger message to the DRM agent to trigger the DRM agent to obtain an approval for the RI to transfer the license that does not have the transfer right on the SRM.
  • the trigger message may include an identifier of the license to be transferred, so that the DRM agent knows which license to obtain approval for when the trigger message is received.
  • the terminal user Before the RI sends the trigger message, the terminal user needs to access the RI website by means of the device or other device where the DRM agent is located, and submits a request for transferring the license in the SRM to the user. After the RI performs some operations such as charging, the terminal can perform the operation. Send the trigger message to the DRM agent.
  • This step is an optional step, and the embodiment may also start directly from step 1202.
  • Step 1202 The DRM agent interacts with the SRM agent to prepare to transfer the license on the SRM.
  • the foregoing preparation includes at least: the DRM agent instructs the SRM agent to set the to-be-transfer permission to an unavailable state.
  • the DRM agent may obtain, from the SRM agent, a certificate of "there is a license to be transferred on the SRM", which may be in the form of a signature of the SRM agent to the REK corresponding to the license.
  • the certificate may further include a time stamp to prevent the DRM agent from repeatedly using the certificate and then "frauding" the license from the RI, etc., that is, the signature range of the SRM agent may include a time stamp.
  • This step is an optional step, and the embodiment may also start directly from step 1203.
  • Step 1203 The DRM agent interacts with the RI to obtain an approval for transferring the license to be transferred on the SRM.
  • the DRM agent may present to the RI a certificate of "the above-mentioned license to be transferred on the SRM" (i.e., the signature of the SRM agent to the REK).
  • the RI After verifying that the above-mentioned license is to be transferred on the SRM, the RI sends the approval information to the DRM agent through a message. Once the DRM agent receives the approval information, it can save the approval.
  • the RI may sign the above approval information
  • Step 1204 The DRM agent interacts with the SRM agent to transfer the license from the SRM to the device.
  • the DRM agent finds that the license does not have the transfer authority, it applies to the RI to transfer the license, and after obtaining the approval of the RI, the license is forcibly transferred from the SRM to the device where the DRM agent is located.
  • the license itself indicates that it does not have transfer rights, the DRM agent can still transfer the license from the SRM to the device under the approval instructions obtained by the DRM agent. This requires appropriate tampering based on the WIPO SRM 1.0 disclosure of the Rights Removal Agreement.
  • FIG. 13 is a schematic flowchart of the interaction protocol in the second embodiment of the method for transferring a license according to another embodiment of the present invention.
  • the specific process may include the following steps: Step 1301: DRM agent to SRM The proxy sends a license information query request message, and the message includes a Handle field;
  • Step 1302 After receiving the license information query request message, the SRM agent returns a license information query response message to the DRM agent, where the message includes a Rights field, a MetaData field, a Rights Object Container field, and a State Information field.
  • the DRM agent obtains, from the SRM, all information about the license RO to be transferred except the REK, including: ⁇ rights> element, signature of the RI pair ⁇ 1 ⁇ > element, licensed element Data (Meta Data), and corresponding State Information (if the license is stateful);
  • Step 1303 After receiving the license information query response message, the DRM agent can learn that the license RO does not have the transfer permission according to the ⁇ rights> element and the status information of the license (State Information).
  • the DRM agent After receiving the license information inquiry response message, the DRM agent can find that the license RO does not have the transfer authority by analyzing the ⁇ rights> element and the status information of the license.
  • the device can prompt the user to delete the RO by popping up the dialog box.
  • Step 1304 The user logs in to the website provided by the RI through the device or other device where the DRM agent is located, and submits a request for obtaining the transfer permission of the RO on the SRM through the page provided by the website.
  • the user can specify the identity of the RO to be transferred, etc. through a web page.
  • Step 1305 After performing operations such as billing, the RI pushes a transfer approval to the DRM agent.
  • a trigger (MovePermissionTrigger) message the trigger message may be used to trigger a transfer permission of the DRM agent to obtain a license to the RI, the message includes a ROID field, a transfer requirement information (MoveRequirementInfo) field, and a REKNeeded field; wherein the transfer requirement information is used to indicate a user-specified Specific transfer requirements, such as: What licenses need to be transferred, what is the number of transfers, etc. Users can specify these requirements through the web pages provided by RI.
  • a trigger (MovePermissionTrigger) message the trigger message may be used to trigger a transfer permission of the DRM agent to obtain a license to the RI, the message includes a ROID field, a transfer requirement information (MoveRequirementInfo) field, and a REKNeeded field; wherein the transfer requirement information is used to indicate a user-specified
  • Step 1306 After receiving the transfer approval trigger message, the DRM agent sends a Move Preparation Request ( MoveSetupRequest) message to the SRM agent, where the message includes a Handle field, a New Handle field, and a REKNeeded field.
  • MovePreparation Request MoveSetupRequest
  • Step 1307 After receiving the transfer preparation request message, the SRM agent returns a Transfer Preparation Response ( MoveSetupResponse) message to the DRM agent, where the message includes an ExistProof field and an Encrypted REK field.
  • Transfer Preparation Response MoveSetupResponse
  • Step 1308 After receiving the transfer preparation response message, the DRM agent sends a MovePermission Request message to the RI, where the message includes a ROID field, a ⁇ rights> field, a ⁇ signature> field, a State Information field, an SRMSignOverREK field, and an EncryptedREK field. , MoveRequirementInfo field; these fields can refer to the foregoing embodiment.
  • Step 1309 After receiving the transfer approval request message, the RI returns a TransferPermissionResponse message to the DRM agent, where the transfer approval response message includes a MovePermission field.
  • the MovePermission field contains the signature of the following information: an identifier indicating the transfer action;
  • the RI can sign the MovePermission field and send it to the DRM agent along with the MovePermission field.
  • Step 1310 The DRM agent transfers the license from the SRM to the device according to the Transfer Permission field of the RI.
  • the DRM agent can perform the transfer operation according to the MovePermission field immediately after receiving the transfer approval response, or save the MovePermission field and perform the transfer operation in the subsequent time, depending on the needs of the user.
  • FIG. 14 is a schematic structural diagram of an embodiment of a 4 authorized center according to an embodiment of the present invention.
  • the embodiment may include: a new license generation module 1401, configured to generate a new license according to the license-related information of the license to be updated on the SRM obtained through the DRM agent and the SRM agent;
  • a new license providing module 1402 is provided for providing the above new license to the above DRM agent.
  • FIG. 15 is a schematic structural diagram of a digital rights management agent according to an embodiment of the present invention. As shown in FIG. 15, the embodiment may include:
  • the license-related information obtaining module 1501 is configured to obtain license-related information of the license to be updated on the SRM from the SRM agent, and provide the license-related information to the RI;
  • the first license update module 1502 is configured to update the to-be-updated license on the SRM by using the new license generated by the SRM agent according to the license-related information by using the foregoing RI.
  • the embodiment of the present invention can be used in the first embodiment and the second embodiment of the method for updating the license according to the embodiment of the present invention.
  • FIG. 16 is a schematic structural diagram of another embodiment of an authorization center according to an embodiment of the present invention. As shown in FIG. 16, the embodiment may include:
  • a new license generation module 1601 configured to generate a new license according to the license-related information of the license to be updated on the SRM obtained through the DRM agent and the SRM agent;
  • the second license update module 1602 is configured to update the to-be-updated license on the SRM by using the above-mentioned DRM agent and the above-mentioned SRM agent.
  • FIG. 17 is a schematic structural diagram of another embodiment of a digital rights management agent according to an embodiment of the present invention. As shown in FIG. 17, the embodiment may include:
  • the license-related information obtaining module 1701 is configured to obtain license-related information of the license to be updated on the SRM from the SRM agent, and provide the license-related information to the RI;
  • the new license acquisition module 1702 is configured to obtain a new license generated from the above RI based on the above license related information.
  • FIG. 18 is a schematic structural diagram of another embodiment of a digital rights management agent according to an embodiment of the present invention. As shown in FIG. 18, this embodiment may include:
  • the receiving module 1801 is configured to receive a trigger message sent by the RI, where the trigger message includes The identifier of the license to be deleted on the SRM;
  • the deleting module 1802 is configured to notify the foregoing SRM agent to delete the above-mentioned to-be-deleted license.
  • FIG. 19 is a schematic structural diagram of another 4 authorized center according to an embodiment of the present invention. As shown in FIG. 19, the embodiment may include: after the license related information of the license is moved, triggering the DRM agent to delete the SRM by using the SRM proxy. The above-mentioned license to be transferred;
  • the REK providing module 1902 is configured to provide the foregoing DRM agent with the above-mentioned transfer permission
  • FIG. 20 is a schematic structural diagram of another embodiment of a digital rights management agent according to an embodiment of the present invention. As shown in FIG. 20, this embodiment may include:
  • the license-related information obtaining module 2001 is configured to obtain license-related information of the license to be updated on the SRM from the SRM agent, and provide the license-related information to the RI;
  • the REK obtaining module 2002 is configured to receive the REK of the above-mentioned to-be-transfer permission provided by the foregoing RI.
  • the foregoing embodiment of the present invention and another digital rights management agent embodiment can be used in the processes of the first embodiment and the second embodiment of the method for transferring a license according to an embodiment of the present invention.
  • FIG. 21 is a schematic structural diagram of an embodiment of an authorization center according to an embodiment of the present invention. As shown in FIG. 21, this embodiment may include:
  • the transfer authority generating module 2101 is configured to generate the transfer right of the to-be-transferred license according to the license-related information of the license to be transferred on the SRM obtained by the DRM agent and the SRM agent;
  • the transfer permission providing module 2102 is configured to provide the transfer permission of the above-mentioned transfer permission to the DRM agent.
  • FIG. 22 is a schematic structural diagram of a digital rights management agent according to an embodiment of the present invention. As shown in FIG. 22, this embodiment may include:
  • the license-related information obtaining module 2201 is configured to obtain license-related information of the license to be updated on the SRM from the SRM agent, and provide the license-related information to the RI;
  • the license transfer module 2202 is configured to receive the transfer permission of the to-be-transfer permission provided by the RI, and transfer the to-be-transferred license to the device where the DRM agent is located by using the SRM agent according to the transfer authority.
  • the embodiment of the present invention further provides a process for the first embodiment and the second embodiment of the method for transferring a license according to another embodiment of the present invention.
  • FIG. 23 is a schematic structural diagram of an embodiment of a secure removable media proxy according to an embodiment of the present invention. As shown in FIG. 23, this embodiment may include:
  • the license-related information providing module 2301 is configured to provide the DRM agent with the license-related information of the license to be updated;
  • the license update module 2302 is configured to receive a new license generated by the DRM agent according to the license related information of the license to be updated, and update the license to be updated.
  • FIG. 24 is a schematic structural diagram of another embodiment of a secure removable media proxy according to an embodiment of the present invention. As shown in FIG. 24, this embodiment may include:
  • the message receiving module 2401 is configured to receive a permission deletion request message sent by the DRM agent, and the deleting module 2402 is configured to delete the permission to be deleted according to the received permission deletion request message and return a deletion certificate to the DRM agent.
  • the information related to the license interacts with the RI, obtains a new license or transfer authority from the RI, and transfers the license from the SRM, thereby realizing that the license without the transfer authority can be transferred from the SRM, thereby expanding the non-transfer authority.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

许可的处理方法及装置 技术领域
本发明实施例涉及数字版权管理 （Digital Rights Management, 简称 DRM )领域， 特别是一种许可的处理方法及装置。 背景技术
数字版权管理主要通过权利限制和内容保护方案控制数字内容的使用， 保护内容所有者的合法权益。 内容中心 （Content Issuer, 以下简称 CI )将 数字内容加密后， 用户将加密的数字内容数据包下载到终端设备上； 授权中 心 ( Rights Issuer, 以下简称 RI )负责分发与数字内容相对应的许可（ Rights Object, 简称 RO ), 其中包括内容解密密钥及对应的权限。 设备只有同时拥 有数字内容数据包（其中包含解密数字内容所必须的信息）和许可， 才能正 常使用所购买的数字内容。 DRM代理（DRM Agent )利用设备的私钥解密得 到许可密钥， 进而得到许可中的内容密钥解密数字内容， 并根据许可中的权 限信息控制用户对数字内容的具体使用。 许可中包含有权利、 限制、 密钥、 数字签名等信息。 对同一个内容， 可以制作包含不同权限的多个不同的许可， 如对于某一文档文件， 有的许可中设置有浏览、 打印权利及本许可的转移 ( Move )权限， 有的许可中只设置浏览权利。
拥有许可的设备可以独立消费许可并使用对应的数字内容， 没有许可的 设备也可以通过与一个安全可移动媒体 ( Secure Removable Media, 简称 SRM )进行交互以消费 SRM中的许可。 SRM可以是一种安全存储卡或智能 卡， 在 SRM上可以存储许可， 从而通过 SRM可以方便地在多个设备上消费 许可。 与存储在设备上的许可一样， 对于存储在 SRM 上的许可， 仍然也有 将其转移出来的需求， 例如： 用户可以将 SRM 上的一些老内容的许可转让 给自己的朋友， 腾出空间后购买新内容的许可。
现有技术中， 既存在设备将自身存储的许可转移给 SRM 的情况， 也存 在设备将 SRM 中存储的许可转移到自身的情况。 在实现本发明过程中， 发 明人发现现有技术中至少存在以下缺陷： 在转移过程中， 设备必须检查许可 本身是否注明 "该许可是可转移的"， 即检查许可是否有转移权限， RI 是否预 先允许对该许可进行转移。 当 SRM 中存储的许可没有转移权限， 或者转移 权限已经被消费完毕， 终端则无法将许可从 SRM 中转移出来。 若用户在购 买许可时如果没有充分考虑好将来是否需要对该许可进行转移、 以及需要对 该许可进行多少次转移的问题， 则有可能会导致无法对许可进行转移的情况 发生， 限制了该许可的应用。 发明内容
本发明实施例提供一种许可的处理方法及装置， 用以实现将 SRM上所 存储的不具备转移权限的许可从 SRM 上转移出来， 扩展不具备转移权限的 许可的应用。
一种更新许可的方法， 包括：
DRM代理从 SRM代理获得待更新许可的许可相关信息；
所述 DRM代理向 RI提供所述许可相关信息， 并从所述 RI获得新许可； 所述 DRM代理与所述 SRM代理进行交互， 利用所述新许可更新所述
SRM上的所述待更新许可。
另一种更新许可的方法， 包括： 相关信息；
所述 RI用所生成的新许可更新所述 SRM上的待更新许可。
一种删除许可的方法， 包括：
DRM代理接收 RI所发送的触发消息， 所述触发消息中包含 SRM上待 删除许可的标识；
所述 DRM代理与所述 SRM上的 SRM代理进行交互， 将所述待删除许 可删除。
一种转移许可的方法， 包括：
通过 DRM代理以及 SRM代理， RI获取所述 SRM上的待转移许可的许 可相关信息；
所述 RI触发所述 DRM代理删除所述 SRM上的所述待转移许可， 并向 所述 DRM代理提供所述待转移许可的 REK。
另一种转移许可的方法， 包括：
DRM代理与 SRM代理进行交互， 获得所述 SRM上的待转移许可的许 可相关信息；
所述 DRM代理与 RI进行交互， 向所述 RI提供所述许可相关信息， 并 从所述 RI获得所述待转移许的转移权限；
所述 DRM代理根据所述转移权限，将所述待转移许可转移到所述 DRM 代理所在设备上。
一种授权中心， 包括：
新许可生成模块， 用于根据通过 DRM代理以及 SRM代理获得的 SRM 上的待更新许可的许可相关信息生成新许可；
新许可提供模块， 用于向所述 DRM代理提供所述新许可。
一种数字版权管理代理， 包括：
许可相关信息获取模块，用于从 SRM代理获得 SRM上的待更新许可的 许可相关信息， 并向 RI提供所述许可相关信息；
第一许可更新模块， 用于通过所述 SRM代理用所述 RI根据所述许可相 关信息生成的新许可更新所述 SRM上的所述待更新许可。
另一种授权中心， 包括：
新许可生成模块， 用于根据通过 DRM代理以及 SRM代理获得的 SRM 上的待更新许可的许可相关信息生成新许可；
第二许可更新模块，用于通过所述 DRM代理以及所述 SRM代理用所述 新许可更新所述 SRM上的待更新许可。
另一种数字版权管理代理， 包括：
许可相关信息获取模块，用于从 SRM代理获得 SRM上的待更新许可的 许可相关信息， 并向 RI提供所述许可相关信息；
新许可获取模块，用于从所述 RI获得根据所述许可相关信息生成的新许 可。
又一种数字版权管理代理， 包括：
接收模块， 用于接收 RI所发送的触发消息， 所述触发消息中包含 SRM 上待删除许可的标识；
删除模块， 用于通知所述 SRM代理将所述待删除许可删除。
再一种授权中心， 包括： 可的许可相关信息后，触发所述 DRM代理通过所述 SRM代理删除所述 SRM 上的所述待转移许可；
REK提供模块， 用于向所述 DRM代理提供所述待转移许可的 REK。 再一种数字版权管理代理， 包括：
许可相关信息获取模块，用于从 SRM代理获得 SRM上的待更新许可的 许可相关信息， 并向 RI提供所述许可相关信息；
REK获取模块， 用于接收所述 RI所提供的所述待转移许可的 REK。 还一种 4受权中心， 包括：
转移权限生成模块， 用于根据通过 DRM代理以及 SRM代理获取 SRM 上的待转移许可的许可相关信息生成所述待转移许可的转移权限；
转移权限提供模块， 用于向所述 DRM代理提供所述待转移许可的转移 权限。
还一种数字版权管理代理， 包括：
许可相关信息获取模块，用于从 SRM代理获得 SRM上的待更新许可的 许可相关信息， 并向 RI提供所述许可相关信息；
许可转移模块， 用于接收所述 RI所提供的所述待转移许可的转移权限， 代理所在设备上。
由上述技术方案可知，本发明实施例利用 DRM代理所获取的 SRM上所 存储的不具备转移权限的许可的相关信息与 RI进行交互， 将许可从 SRM上 转移出来， 实现了可以将不具备转移权限的许可从 SRM 上转移出来， 从而 扩展了不具备转移权限的许可的应用。 附图说明 施例或现有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面 描述中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性的前提下， 还可以根据这些附图获得其他的附图。
图 1为本发明实施例一种更新许可的方法的第一实施例的流程示意图； 图 2为本发明实施例一种更新许可的方法的第二实施例的流程示意图； 图 3为本发明实施例一种更新许可的方法的第二实施例中交互协议具体化 后的流程示意图；
图 4为本发明实施例另一种更新许可的方法的第一实施例的流程示意图； 图 5为本发明实施例另一种更新许可的方法的第二实施例的流程示意图； 图 6为本发明实施例另一种更新许可的方法的第二实施例中交互协议具体 化后的流程示意图；
图 7为本发明实施例删除许可的方法实施例的流程示意图；
图 8为本发明实施例一种转移许可的方法的第一实施例的流程示意图； 图 9为本发明实施例一种转移许可的方法的第二实施例的流程示意图； 图 10 为本发明实施例一种转移许可的方法的第二实施例中交互协议具体 化后的流程示意图；
图 11为本发明实施例另一种转移许可的方法的第一实施例的流程示意图； 图 12为本发明实施例另一种转移许可的方法的第二实施例的流程示意图； 图 13 为本发明实施例另一种转移许可的方法的第二实施例中交互协议具 体化后的流程示意图；
图 14为本发明实施例一种授权中心实施例的结构示意图；
图 15为本发明实施例一种数字版权管理代理实施例的结构示意图； 图 16为本发明实施例另一种授权中心实施例的结构示意图；
图 17为本发明实施例另一种数字版权管理代理实施例的结构示意图； 图 18为本发明实施例又一种数字版权管理代理实施例的结构示意图； 图 19为本发明实施例再一种授权中心实施例的结构示意图；
图 20为本发明实施例再一种数字版权管理代理实施例的结构示意图； 图 21为本发明实施例还一种授权中心实施例的结构示意图；
图 22为本发明实施例还一种数字版权管理代理实施例的结构示意图； 图 23为本发明实施例一种安全可移动媒体代理实施例的结构示意图； 图 24为本发明实施例另一种安全可移动媒体代理实施例的结构示意图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例中的技术方案进行 清楚、 完整地描述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而 不是全部的实施例。 基于本发明中的实施例， 本领域普通技术人员在没有做 出创造性劳动前提下所获得的所有其他实施例， 都属于本发明保护的范围。 RI获取上述 SRM上的待更新许可的许可相关信息， 并用所生成的新许可替 换上述 SRM上的待更新许可。
其中的待更新许可可以为一个缺乏转移权限的许可， 相应地， 新许可则 可以为一个具备了转移权限的许可。 本发明实施例进一步还可以通过上述
SRM代理与上述 DRM代理或者另外一个 DRM代理进行交互， 将上述具备 了转移权限的新许可转移到上述 DRM代理所在设备或者上述另外一个 DRM 代理所在设备。
图 1为本发明实施例一种更新许可的方法的第一实施例的流程示意图， 如图 1所示， 本实施例可以包括以下步骤： 进行交互， 获取 SRM上待更新许可的相关信息；
步骤 102、 上述 DRM代理利用上述待更新许可的相关信息与 RI进行交 互， 并从上述 RI获得根据上述相关信息生成的新许可；
步骤 103、 上述 DRM代理与上述 SRM代理进行交互， 利用上述新许可 更新上述 SRM上的待更新许可。
本实施例通过对 SRM 上的许可的替换， 使其能够具备某种新的操作权 限， 实现了可以对许可进行更新， 从而扩展了许可的应用。
图 2为本发明实施例一种更新许可的方法的第二实施例的流程示意图， SRM上存在一个由 RI发布的、不具备转移权限的许可（ RO ),设备（ Device ) 的用户希望将 RO转移出来。 如图 2所示， 本实施例可以包括以下步骤： 步骤 201、 RI向 DRM代理发送许可更新触发消息， 以触发 DRM代理 更新 SRM中的许可。
较佳地， 上述触发消息中可以包含待更新许可的标识， 这样 DRM 代理 接收到该触发消息时知道将更新哪一个许可。 在 RI发送该触发消息之前， 终 端用户需要借助 DRM代理所在设备或者其他设备访问 RI的网站， 提交自己 关于更新 SRM中许可的请求， 以及所需要补充的新许可的相关信息， RI进 行一些诸如计费相关的操作后， 便可以发送该触发消息给 DRM代理。
本步骤为可选步骤， 本实施例也可以直接从步骤 202开始。
进一步地， 上述触发消息中还可以包含一个指示信息， 用于表明 RI是否 会保存曾经发布的许可对应的权限加密密钥 （Rights Encryption Key, 简称 REK ), REK用于加密内容加密密钥（Content Encryption Key, 简称 CEK ), 形成加密的 CEK置入许可中；
步骤 202、 DRM代理与 SRM代理进行交互， 准备更新 SRM上的某个 许可， 上述准备工作至少可以包括： DRM代理指示 SRM代理将待更新许可 置为不可用状态， 以使待更新许可不能被任何设备用于消费相应内容。
较佳地， DRM代理可以从 SRM代理获得 "该 SRM上的确存在待更新 的许可"的存在证明，该证明包含待更新许可的部分或者全部信息和 SRM代 理对许可的部分或全部信息的数字签名。 这里说的许可的部分信息可以是许 可对应的 REK或者许可的标识。 在后面的步骤中， DRM代理可以将该证明 发送给 RI , RI验证其中包含的 SRM对许可部分或者全部信息的数字签名， 如果数字签名验证正确， 则判定 SRM中的确存在该待更新的许可。
较佳地， 该证明中 SRM 所进行数字签名的数据中还可以进一步包含一 个时间戳， 以防止 DRM代理反复使用同一个存在证明从 RI处 "骗取" 许可 等。
进一步地， 如果在上述步骤 201的触发消息中包含有指示信息， 该指示 信息表明 RI不保存曾经发布许可对应的 REK, 则 SRM代理还应该将 REK 用 RI的公钥进行加密， 连同存在证明一起发给 DRM代理；
步骤 203、 DRM代理与 RI进行交互，获取用于替换 SRM上待更新许可 的新许可， 该新许可包含有转移权限。 DRM 代理可以将待更新许可、 RI 曾 经对该原许可的数字签名以及待更新许可的状态信息发送给 Rl。
较佳地， DRM代理还可以将 SRM代理提供的上述存在证明发送给 RI , 以便向 RI证明 SRM上的确存在该待更新许可。 RI验证该存在证明通过并判 定 SRM上的确存在待更新许可后， 则生成新许可发送给 DRM代理， 其中新 许可的 REK釆用 DRM代理无法最终解密获得的方式加密， 如先釆用 SRM 的公钥加密， 然后再釆用 DRM代理的公钥进一步加密。
进一步地， 如果在上述步骤 201的触发消息中包含有指示信息， 该指示 信息表明 RI不保存曾经发布许可对应的 REK,则 DRM代理还应该将由 SRM 代理用 RI的公钥加密的 REK发送给 RI ,以便 RI验证 SRM代理提供的存在 证明， 且又不将 REK暴露给 DRM代理。
较佳地， DRM代理还可以将终端用户关于新许可的要求， 例如： 需要什 么样的转移权限等信息， 发送给 RI , 以便 RI生成满足终端用户要求的新许 可；
步骤 204、 DRM代理与 SRM代理进行交互， 将新许可替代 SRM上的 待更新许可。
DRM代理可以先将 RI发送来的新许可进行预处理， 例如： 验证 RI对新 许可的数字签名， 然后向 SRM代理请求将从 RI处获取的新许可替代 SRM 上待更新许可。 在替换过程中， SRM需要将加密的 REK使用自己的私钥进 行解密并保存；
步骤 205、 DRM代理与 RI进行交互， 向 RI确认许可已经替换完毕。 本步骤为可选步骤， 本实施例也可以直接跳到步骤 206执行；
步骤 206、 DRM代理与 SRM代理进行交互， 将新许可从 SRM上转移 到该 DRM代理所在设备上或其他设备上。
本实施例中， 通过先更新 SRM 中的不具备转移权限的许可， 使之具备 足够的转移权限， 然后对该许可进行转移， 实现了更新与转移的分离， 许可 更新成具备转移权限后， 用户可以决定将许可转移到哪个设备上， 实现了可 以将不具备转移权限的许可从 SRM 上转移出来， 从而扩展了不具备转移权 限的许可的应用。如果用户想将其转移到一个无连接设备即不能与 RI直接通 信的设备上， 本实施例尤其适合。 图 3为本发明实施例一种更新许可的方法的第二实施例中交互协议具体 化后的流程示意图， 假设 RI没有緩存曾经发布的 REK, 如图 3所示， 具体 的流程可以包括以下步骤：
步骤 301 、 DRM 代理向 SRM 代理发送许可信息查询请求 ( RightslnfoQueryRequest ) 消息；
步骤 302、 SRM代理接收到许可信息查询请求消息后， 向 DRM代理返 回许可信息查询响应 ( RightslnfoQueryResponse ) 消息。
通过步骤 301和步骤 302, DRM代理从 SRM上获得了关于待更新的许 可 RO除了 REK之外的所有信息， 包括： <rights>元素、 RI对<1^^5>元素 的数字签名、 许可的元数据 （Meta Data ), 以及对应的状态信息 （State Information ) (如果该许可是有状态许可的话）。
其中， 步骤 301 中 DRM代理所发送的许可信息查询请求消息所包含的 字段可以如表 1所示：
表 1 许可信息查询请求消息中的字段 ( Fields of RightslnfoQueryRequest ) 字段 ( Fields ) 描述 ( Description )
句柄 ( Handle ) 许可在 SRM上的唯一标识。
其中， 步骤 302中 SRM代理返回的许可信息查询响应消息所包含的字 段可以如表 2所示：
表 2许可信息查询响应消息中的字段 ( Fields of RightslnfoQueryResponse ) 字段 ( Fields ) 描述 ( Description )
状态 （Status ) SRM 代理处理许可信息查询请求消息的结果。 如果有错误发 生， 在许可信息查询响应消息中只有这个字段出现。
权限元数据 ( Rights Meta Data ) 许可的元数据， 包括如下信息：
Rights Object Version (许可版本 );
RO Alias (许可别名 );
Rights Issuer Identifier ( RI的标识 );
Rights Issuer URL ( RI的 URL );
Rights Issuer Alias ( RI的别名 );
Rights Issuer Time Stamp ( RI发行许可的时间戳）。 字段 ( Fields ) 描述 ( Description )
权限对象容器 （ Rights Object 包含了 <rights>元素和 <signature>元素的容器。
Gontsinsr )
状态信息（ State Information ) 许可的剩余状态信息， 如还剩下多少次播放权限等。 如果许可 是无状态的， 则该字段不出现。
步骤 303、 DRM代理接收到许可信息查询响应消息后， 根据 <1^^^>元 素和该许可的状态信息（ State Information )可以获知该许可 RO不具备转移 权限。
接收许可信息查询响应消息后， DRM代理通过分析 <rights>元素以及该 许可的状态信息， 即可发现许可 RO不具备转移权限。 设备可以通过弹出对 话框的方式， 提示用户对 RO进行更新。
步骤 304、 用户通过 DRM代理所在设备或者其他设备登录到 RI提供的 网站， 通过网站提供的页面， 提交关于希望将 SRM上的 RO进行更新的请 求。 较佳地， 用户可以通过网页指定需要更新的许可的标识， 需要补充什么 样的权限等。
步骤 305、 RI进行诸如计费等操作后， 向 DRM代理推送一个 SRM许可 更新触发（SRMROUpgradeTrigger ) 消息， 该触发消息可以用于触发 DRM 代理更新 SRM上的许可 R0。 SRM许可更新触发消息所包含的字段可以如 表 3所示：
表 3 SRM许可更新触发消息中的字段 ( Fields of SRMROUpgradeTrigger )
Figure imgf000012_0001
步骤 306、 DRM代理接收到该 SRM许可更新触发消息后， 向 SRM代 理发送许可更新准备请求（RightsUpgradeSetupRequest )消息。 DRM代理 可以以两种方式发送许可更新准备请求消息给 SRM代理： 方式一： 根据 SRM许可更新触发消息中的 upgradelnfo字段， 向用户显 示其曾经指定的需要补充的权限信息， 得到用户确认后发送；
方式二： 不经用户确认， 直接自动发送。
许可更新准备请求消息所包含的字段可以如表 4所示：
表 4许可更新准备请求消息中的字段 ( Fields of RightsUpgradeSetupRequest )
Figure imgf000013_0001
步骤 307、 SRM代理接收到许可更新准备请求消息后，使用 New Handle 字段覆盖已有的 Handle字段。
在本步骤之前还需要验证字段 New Handle的唯一性，即确保在 SRM上 不存在相同的 Handle字段。这样，许可 RO在 SRM上的唯一标识仅该 DRM 代理知道， 而其他 DRM代理因不知道对应的 Handle字段而无法访问该许可 R0。
较佳地， SRM代理可以进一步将 R0置为不可用状态， 因为置为不可用 状态的许可，其 Handle等字段是不允许查询的，进一步确保了 R0不被其他 设备所访问。
由于 RI所发送的 SRM许可更新触发消息中包含有 REKNeeded字段， 因此 DRM代理也将其包含在许可更新准备请求消息中，以向 SRM代理表明 RI没有緩存曾经发布的 REK, 则 SRM代理在后续步骤中， 需要发送 REK。 若 RI能够緩存所有发布的 REK, 则 REKNeeded字段将不需要传送；
步骤 308 、 SRM 代理向 DRM 代理发送许可更新准备响应 ( RightsUpgradeSetupResponse ) 消息。
许可更新准备响应消息所包含的字段可以如表 5所示：
表 5许可更新准备响应消息中的字段 ( Fields of RightsUpgradeSetupResponse ) 字段 ( Fields ) 描述 ( Description ) 字段 ( Fields ) 描述 ( Description )
状态 （Status ) 表明 SRM代理是否成功处理许可更新准备请求消息。 如果发生错 误， 则该响应消息将只包含该字段， 后续字段将不包含。
存在证明 ( ExistProof ) 表明许可在 SRM上存在的存在证明。
加密的 REK ( EncryptedREK ) 使用 RI的公钥加密的 REK, 即绑定到 RI的 REK。
其中， ExistProof字段用于证明 SRM上的确存在待更新许可， 为可选字 段； 该证明包含待更新许可的全部信息以及 SRM 对待更新许可全部信息的 数字签名， 或者包含待更新许可的部分信息以及 SRM 对待更新许可部分信 息的数字签名， 这个部分信息可以为待更新许可的 REK, 也可以为待更新许 可的标识， 还可以为待更新许可的 REK与待更新许可的标识的组合。
如果上述许可更新准备请求消息中的 REKNeeded字段不存在， 则许可 更新准备响应消息中的 EncryptedREK字段也将不需要；
步骤 309、 DRM代理接收到许可更新准备响应消息后， 向 RI发送 SRM 许可更新请求（ SRMROUpgradeRequest ) 消息。
SRM许可更新请求消息所包含的字段可以如表 6所示：
表 6 SRM许可更新请求消息中的字段 ( Fields of SRMROUpgradeRequest )
Figure imgf000014_0001
明的形式参见步骤 308。
EncryptedREK字段既可被 RI用于验证终端用户的设备 ( DRM代理所 在设备或 SRM, 但不知道究竟是谁）是否真的拥有待更新许可， 因为 RI只 要拿 REK解密 <rights>元素中 encryptedCEK, 若解密成功则说明终端用户 的设备拥有待更新许可，反之不拥有，也可以被 RI用于验证 ExistProof字段， 当 RI 不备份自己曾经发布的待更新许可的 REK 的时候， RI 需要从 EncryptedREK解密得到 REK原文， 从而验证 ExistProof。
其中，上述 SRM许可更新请求消息中的 upgradelnfo字段的取值可以有 两种情况： 当 DRM代理在 SRM许可更新触发消息的触发下进行 RO更新操 作时， upgradelnfo字段的值取自 SRM许可更新触发消息中的同名字段的值； 当 DRM代理不在 SRM许可更新触发消息的触发下进行 RO更新操作时，设 备则需要显示友好的用户界面， 供用户指定对许可 RO 的更新需求， upgradelnfo字段的值将取自上述用户界面。
步骤 310、 RI接收到 SRM许可更新请求消息后， 对自己对 <rights>元素 的数字签名、 以及存在证明进行验证；
步骤 311、 上述验证通过后， RI根据 upgradelnfo字段构造一个新 RO, 通过 SRM许可更新响应（ SRMROUpgradeResponse )消息发送给 DRM代 理。
较佳地，为了安全起见，新 R0中的 REK要与待更新的原 R0中的 REK 不相同。
SRM许可更新响应消息所包含的字段可以如表 7所示：
表 7 SRM许可更新响应消息中的字段 ( Fields of SRMROUpgradeResponse )
Figure imgf000015_0001
其中新许可中的 REK应该与待更新许可的 REK不同，其加密算法如下:
RI随机生成好 REK后， 为将其在 DRM代理无法获知的情况下传递给 SRM, 则需要执行如下步骤：
生成一个随机数 Zx, 得到：
ΚΕΚχ = KDF(I20SP(ZX, mLenSRM), NULL, kekLen) 其中， mLenSRM是 SRM证书的模长， kekLen和 KDF()函数可参考 OMA DRM标准文稿 OMA-TS-DRM_DRM-V2_1-20070919-C.doc;
得到：
Cx2=AES-WRAP(KEKx,REK); 和
Cx1 =l20SP(RSA.ENCRYPT(PubKeySRM,Zx),mLenSRM);
其中 I20SP()函数， RSA.ENCRYPT()函数可参考上述 DRM标准文稿； 再得到：
EncREK = Cx1 | Cx2;
再生成一个随机数 Z和一个 KMAC (根据上述 DRM标准， 其用于 DRM 代理险证消息的完整性）得到：
KEK = KDF(I20SP(Z, mLen圍 Agent), NULL, kekLen);
其中 ^11_61¾ ^^是 DRM代理证书的模长， kekLen和 KDF()函数可参 考上述 DRM标准文稿；
再由前面得到的 EncREK和 KMAC得到：
K = KMAC I EncREK;
C2 = AES-WRAP(KEK, K);
d = l20SP(RSA.ENCRYPT(PubKeyDRMAgent, Z), mLenDRMAgent); 以及 C― C-i I〇2。
Rl将 C携带在新许可中发送给 DRM代理。 DRM代理收到 C后， 利用 自己的私钥， 可以最终得到 EncREK, 将其传给 SRM代理， SRM代理再利 用自己的私钥， 可以最终得到 REK。
步骤 312、 DRM代理接收到满足用户需求的新 RO后， 对新 RO进行预 处理， 上述预处理包括以下步骤：
验证 RI对 SRM许可更新响应消息的数字签名；
验证 RI对<1^^^>元素的数字签名；
从 SRM许可更新响应消息中提取出 OMA SRM1.0标准所定义的 Rights Meta Data, <rights>元素、 <signature>元素即 Rl †<rights>iL素的数字签名； 从 SRM许可更新响应消息中提取出 EncryptedREK字段即 RI使用 SRM 代理的公钥对 REK的加密结果； 如果适当降低安全要求，以上新许可的 REK也可以不用进一步使用 SRM 代理的公钥加密。
步骤 313、 完成上述预处理后， DRM代理向 SRM代理发送许可替换请 求 ( RightsReplaceRequest ) 消息。
许可替换请求消息所包含的字段可以如表 8所示：
表 8许可替换请求消息中的字段 ( Fields of RightsReplaceRequest )
Figure imgf000017_0001
步骤 314、 SRM代理收到许可替换请求消息后， 使用新许可替换待更新 的原许可。
S RM代理进行新许的替换可以釆用以下两种方式：
方式一： 根据 size字段，新创建一个用于存储新许可的新存储槽（slot ), 对应 handle字段为一个临时 handle, 然后将新许可存储到该新存储槽中， 再将已有的原存储槽（即上述许可替换请求消息中 handle字段的值对应的存 储槽）给删除， 然后用上述许可替换请求消息中 handle字段对应的值覆盖上 述临时 handle;
方式二： 先删除已有的原存储槽 (即上述许可替换请求消息中 handle字 段的值对应的存储槽）， 然后根据 size字段创建新的存储槽， 对应 handle的 值为上述许可替换请求消息中的 handle字段的值，再将新许可存储到新的存 储槽中。
在上述两种方式中， 将新许可存储到新的存储槽过程中， 如果在前面的 SRM许可更新响应中的 REK进一步釆用 SRM代理的公钥加密的话， 则与 OMA SRM 1.0 标准不同的是， SRM 代理在存储 REK 前， 需要对 EncryptedREK 字段釆用自己的私钥进行解密， 然后将解密后的结果存储到 存储槽中； 否则 SRM代理直接存储 REK, 而不需要一个解密的过程。
步骤 315 、 SRM 代理向 DRM 代理返回许可替换响应 ( RightsReplaceResponse ) 消息。
许可替换响应消息所包含的字段可以如表 9所示：
表 9许可替换响应消息中的字段 ( Fields of RightsReplaceResponse )
Figure imgf000018_0001
其中， ReplaceProof字段用于证明新许可已经替换 SRM上已有待更新 许可， 为可选字段； 该证明包含如下信息组合以及 SRM对其的数字签名： {
促使 SRM代理进行更新操作的 DRM代理的标识；
更新的时间；
表示替换操作的标识；
新许可的 REK和 /或新许可的标识；
旧许可的 REK (即待更新许可的 REK )和 /或旧许可的标识（即待更新 许可的标识）
}
步骤 316、 DRM代理接收到许可替换响应消息后， 向 RI发送 SRM许可 更新确认请求（SRMROUpgradeConfirmRequest ) 消息， 以向 RI确认新许 可已经成功替换 SRM上的原许可。
SRM许可更新确认请求消息所包含的字段可以如表 10所示：
表 10 SRM许可更新确认请求消息中的字段
( Fields of SRMROUpgradeConfirmRequest )
Figure imgf000018_0002
其中， ReplaceProof字段用于证明新许可已经替换 SRM上已有待更新 许可， 为可选字段； 该证明的形式参见步骤 315。
步骤 314~316是通过一对消息实现新旧许可的替换，发明人认为也可以 通过两对消息实现， 即， DRM代理发送消息给 SRM代理， 要求 SRM代理 删除代更新许可； 确认待更新许可已经被删除之后， DRM代理再发送消息给 SRM代理， 将新许可传送给上述 SRM代理， 由 SRM代理将新许可安装到 SRM 中。 但这样， DRM代理要从 SRM代理先后获得待更新许可的删除证 明和新许可的安装证明。 删除证明包含如下信息组合以及 SRM 对其的数字 签名：
{
促使 SRM代理进行删除操作的 DRM代理的标识；
删除的时间；
表示删除操作的标识；
被删除许可的 REK; (即待更新许可的 REK )
被删除许可的标识； (即待更新许可的标识 )
}
而安装证明包含如下信息组合以及 SRM对其的数字签名：
{
促使 SRM代理进行安装操作的 DRM代理的标识；
安装的时间；
表示安装操作的标识；
被安装许可的 REK; (即新许可的 REK )
被安装许可的标识； (即新许可的标识 )
}
步骤 317、 RI接收到 SRM许可更新确认请求消息后，对 SRM代理提供 的替换证明或者删除证明与安装证明进行验证；
步骤 318、上述验证通过后， RI向 DRM代理返回 SRM许可更新确认响 应 ( SRMROUpgradeConfirmResponse ) 消息。
SRM许可更新确认响应消息所包含的字段可以如表 11所示：
表 11 SRM许可更新确认响应消息中的字段 ( Fields of SRMROUpgradeConfirmResponse )
Figure imgf000020_0001
执行过本步骤之后， SRM上原先不具备转移权限的许可（RO ), 现在已 经替换成具备转移权限的许可 ( RO );
步骤 319、 DRM代理接收到 SRM许可更新确认响应消息后， 可以立即 或者在将来的某个时刻， 釆用 OMA SRM1.0的推式转移 （Pull Move )协议 将更新后的新许可转移到 DRM代理所在的设备上。
如果用户不愿意将许可转移到该设备上， 而是希望将其转移到另外一个 设备上，则用户可以将 SRM插入到另外一个设备上，然后进行拉式转移（ Pull Move )操作。
可替换地， 本实施例中的步骤除了上面公开的实现方法外， 还存在一些 替代方法， 例如：
上述 DRM代理从 RI获得新 RO, 也可以不釆用如步骤 309和步骤 310 中在现有 OMA SRM1.0标准上增加新消息即 SRM许可更新请求消息和 SRM 许可更新响应消息的方法来实现， 而是修改现有许可更新协议 ( ROAP-RO Upgrade Protocol ) 中的消息， 利用消息中的 Extension字段传 递需要传递的字段或数据， 可以达到同样效果；
上述 DRM代理使用新许可替换 SRM上的原许可，也可以不釆用如步骤 313和步骤 315中在现有 OMA SRM1.0标准上增加新消息即许可替换请求消 息和许可替换响应消息的方法来实现， 而是釆用两对消息来实现， 即先安装 新许可即许可安装请求 （ RightslnstallRequest ) 消息和许可安装响应 ( RightslnstallResponse ) 消息， 然后删除已有的原许可即许可删除请求 ( Rights Removal Request ) 消 息 和 许 可 删 除 响 应 ( Rig htsRemoval Response ) 消息。 不过注意， 安装新许可与现有 OMA SRM1.0标准中的安装方法有点不同，即 SRM代理需要将 EncryptedREK字 段使用 SRM代理的私钥解密后保存， 而 OMA SRM1.0标准中 DRM代理传 送给 SRM代理可直接存储的 REK,而不是使用 SRM代理公钥加密的 REK。
图 4 为本发明实施例另一种更新许可的方法的第一实施例的流程示意 图， 如图 4所示， 本实施例可以包括以下步骤：
步骤 401、 上述 DRM代理与上述 SRM代理进行交互， 获得 SRM上的 待更新许可的许可相关信息；
步骤 402、 上述 RI触发上述 DRM代理与上述 SRM代理进行交互删除 上述 SRM上的上述待更新许可；
步骤 403、上述 RI触发上述 DRM代理从上述 RI获得根据上述相关信息 生成的新许可安装到上述 SRM上。
本实施例通过删除 SRM 上的许可， 替换为新许可， 使其能够具备某种 新的操作权限， 实现了可以对许可进行更新， 从而扩展了许可的应用。
图 5 为本发明实施例另一种更新许可的方法的第二实施例的流程示意 图， SRM 上存在一个由 RI 发布的、 不具备转移权限的许可 （RO ), 设备 ( Device ) 的用户希望将 RO转移到该设备上。 如图 5所示， 本实施例可以 包括以下步骤：
步骤 501、 RI向 DRM代理发送许可删除触发消息， 以触发 DRM代理 删除 SRM上的许可。
较佳地， 上述触发消息中可以包含待删除的原许可的标识， 这样 DRM 代理接收到该触发消息时知道将删除哪一个许可。 在 RI 发送该触发消息之 前， 终端用户需要借助 DRM代理所在设备或者其他设备访问 RI的网站， 提 交关于希望将 SRM 中许可转移给自己的请求， 以及所需要补充的新许可的 相关信息， RI 进行一些诸如计费相关的操作后， 便可以发送该触发消息给 DRM代理。
本步骤为可选步骤， 本实施例也可以直接从步骤 502开始；
步骤 502、 DRM代理与 SRM代理进行交互， 将 SRM上的许可删除。 较佳地， DRM代理可以从 SRM代理获得"该许可已经为 SRM代理所删 除"的删除证明， 该证明的形式参见步骤 316中的说明。
步骤 503、 DRM代理与 RI进行交互， 向 RI报告待更新许可删除完毕。 较佳地， 为了安全起见， DRM代理应该向 RI提供步骤 502上述的删除 证明。 RI在验证该证明通过后， 即可判定待更新许可已经从 SRM删除， 并 向 DRM代理发送新许可； 步骤 504、 Rl通过 DRM代理， 将一个包含了待更新许可中已有的权限， 外加用户所需要的转移权限的新许可安装到 SRM上。
步骤 505、 DRM代理与 SRM代理进行交互， 将新许可从 SRM上转移 到该 DRM代理所在设备上，或者另外一个 DRM代理与 SRM代理进行交互， 将新许可从 SRM上转移到另外一个 DRM代理所在的设备上。
本实施例与本发明一种许可权限的更新方法实施例相似， 也是通过先更 新 SRM 中的不具备转移权限的许可， 使之具备足够的转移权限， 然后对该 许可进行转移， 实现了更新与转移的分离， 许可更新成具备转移权限后， 将 许可转移到 DRM 代理所在设备上， 实现了可以将不具备转移权限的许可从 SRM上转移出来， 从而扩展了不具备转移权限的许可的应用。 但本实施例中 的更新方法不同， 即先由 RI触发 DRM代理删除 SRM上的许可， 再由 RI 过 DRM代理将新许可安装到 SRM上。
图 6为本发明实施例另一种更新许可的方法的第二实施例中交互协议具 体化后的流程示意图， 如图 6所示， 具体的流程可以包括以下步骤：
步骤 601、 DRM代理向 SRM代理发送许可信息查询请求消息， 该许可 信息查询请求消息包含 Handle字段；
步骤 602、 SRM代理接收到许可信息查询请求消息后， 向 DRM代理返 回许可信息查询响应消息， 该许可信息查询响应消息包含许可的元数据 ( Rights Meta Data )字段、 权限对象容器 ( Rights Object Container )字段、 状态信息字段。
通过步骤 601和步骤 602, DRM代理从 SRM上获得了关于待删除的许 可 R0除了 REK之外的所有信息， 包括： <rights>元素、 RI对<1^^5>元素 的签名、 许可的元数据（Rights Meta Data )、 以及对应的状态信息 （State Information ) (如果该许可是有状态许可的话）；
步骤 603、 DRM代理接收到许可信息查询响应消息后， 根据 <!^^^>元 素和该许可的状态信息（ State Information )可以获知该许可 R0不具备转移 权限。
接收许可信息查询响应消息后， DRM代理通过分析 <rights>元素以及该 许可的状态信息， 即可发现许可 R0不具备转移权限。 设备可以通过弹出对 话框的方式， 提示用户对 RO进行更新。
步骤 604、 用户通过 DRM代理所在设备或者其他设备登录到 RI提供的 网站， 通过网站提供的页面， 提交关于对 SRM上的 RO进行更新的请求。 较佳地， 用户可以通过网页指定需要更新的许可的标识， 需要补充什么样的 权限等；
步骤 605、 RI进行诸如计费等操作后， 向 DRM代理推送一个 SRM许可 删除触发（SRMRORemovalTrigger )消息， 该触发消息可以用于触发 DRM 代理删除 SRM上的许可 RO。 该 SRM许可删除触发消息包含 ROID字段、 REKNeeded字段；
较佳地， 该触发消息中还可以包含一个用于指明删除许可的原因或者指 向该原因的超级链接， 这样当 DRM代理收到该触发消息后， DRM代理所在 设备可以向终端用户显示删除的原因， 例如此前用户自己通过网页提交了更 新许可的要求等。
步骤 606、 DRM代理接收到 SRM许可删除触发消息后， 向 SRM代理 发送许可删除请求（ RightsRemovalRequest )消息， 该许可删除请求消息包 含 Handle字段、 ProofNeeded字段；
步骤 607 、 SRM 代理向 DRM 代理发送许可删 除响应 ( RightsRemovalResponse ) 消息， 该许可删除响应消息包含 Status字段、 Proof of Removal字段；
步骤 608、 DRM代理接收到许可删除响应消息后， 向 RI发送 SRM许可 删除 告请求（SRMRORemovalReportRequest ) 消息， 该 SRM许可删除 报告请求消息包含 ROID 字段、 <rights>元素、 <signature>元素、 Proof of Removal字段；
步骤 609、 RI接收到 SRM许可删除报告请求消息后， 向 DRM代理返回 SRM许可删除报告响应 （SRMRORemovalReportResponse ) 消息；
步骤 610、 RI向 DRM代理发送许可获取触发（ ROAquisitionTrigger ) 消息， 该许可获取触发消息包含 ROID字段；
步骤 611、 DRM代理向 RI发送许可请求（RORequest ) 消息， 以获具 备转移权限的新取许可， 该许可请求消息包含 ROID字段； 步骤 612、 Rl接收到许可请求消息后， 通过向 DRM代理返回许可响应 ( ROResponse ) 消息来通过 DRM代理向 SRM提供一个绑定于 SRM代理 的新许可；
步骤 613、 DRM代理接收到新 RO后， 对新 RO进行前期处理， 上述前 期处理包括验证许可的完整性等步骤；
步骤 614、 完成上述前期处理后， DRM代理向 SRM代理发送安装准备 请求（ InstallationSetupRequeset ) 消息， 该安装准备请求消息包含 Handle 字段、 Size字段；
步骤 615、 SRM代理接收到安装准备请求消息后， 向 DRM代理返回安 装准备响应 （ InstallationSetupResponse ) 消息， 该安装准备响应消息包含 Status字段；
步骤 616、 DRM代理接收到安装准备响应消息后， 向 SRM代理发送许 可安装请求（ RightslnstallationSetupRequeset )消息， 该许可安装请求消息 包含 Handle字段、 Rights Information字段、 REK bound to SRM Agent字 段；
步骤 617、 SRM代理接收到许可安装请求消息后， 向 DRM代理返回许 可安装响应（ RightslnstallationSetupResponse )消息， 该许可安装响应消息 包含 Status字段；
至此， SRM上原先不具备转移权限的许可就变成了一个具备转移权限的 许可；
步骤 618、 DRM代理与 SRM代理进行交互， 将新许可从 SRM上转移 出来。 DRM代理接收到许可安装响应消息后， 可以立即或者在将来的某个时 刻， 将更新后的新许可转移到 DRM代理所在的设备上。
图 7为本发明实施例删除许可的方法实施例的流程示意图，如图 7所示， 本实施例可以包括以下步骤：
步骤 701、 终端设备上的 DRM代理接收 RI所发送的触发消息， 上述触 发消息中包含 SRM上待删除许可的标识；
步骤 702、 上述 DRM代理与上述 SRM上的 SRM代理进行交互， 将上 述待删除许可删除。 本实施例 DRM代理根据接收到的触发消息中包含的 SRM上待删除许可 的标识， 与上述 SRM上的 SRM代理进行交互， 将上述待删除许可删除， 实 现了可以将 SRM上的许可删除， 以供获取 RI提供的许可的 REK后， 安装 新许可， 从而扩展了许可的应用。
图 8为本发明实施例一种转移许可的方法的第一实施例的流程示意图， 如图 8所示， 本实施例可以包括以下步骤：
步骤 801、 通过终端设备上的 DRM代理以及 SRM上的 SRM代理， RI 获取上述 SRM上的待转移许可的许可相关信息；
步骤 802、 上述 RI触发上述 DRM代理删除上述 SRM上的上述待转移 许可， 并向上述 DRM代理提供上述待转移许可的 REK。
本实施例中 RI 获取 SRM 上的待待转移许可的许可相关信息后， 触发 DRM代理删除上述待转移许可， 并向 DRM代理提供待转移许可的 REK, 以 供 DRM代理根据相关信息和 REK将新许可安装到 SRM上， 实现了可以将 不具备转移权限的许可从 SRM上转移出来， 从而扩展了许可的应用。
图 9为本发明实施例一种转移许可的方法的第二实施例的流程示意图， 假设 RI緩存有曾经发布的 REK, SRM上存在一个由 RI发布的、 不具备转 移权限的许可（RO ), 设备 ( Device ) 的用户希望将 RO转移到该设备上。 如图 9所示， 本实施例可以包括以下步骤：
步骤 901、 RI向 DRM代理发送触发消息， 以触发 DRM代理向 RI获取 许可对应的 REK。
较佳地， 上述触发消息中可以包含许可的标识， 这样 DRM代理接收到 该触发消息时知道将获取哪个许可对应的 REK。 在 RI发送该触发消息之前， 终端用户需要借助 DRM代理所在设备或者其他设备访问 RI的网站， 提交关 于希望将 SRM中许可转移给自己的请求， RI进行一些诸如计费相关的操作 后， 便可以发送该触发消息给 DRM代理。
本步骤为可选步骤， 本实施例也可以直接从步骤 902开始；
步骤 902、 DRM代理与 SRM代理进行交互， 将 SRM上的许可删除。 较佳地， DRM代理可以从 SRM代理获得"该 SRM上的确存在上述许可 以及该许可已经为 SRM代理所删除"的证明， 该证明的形式可以是 SRM代 理对许可对应的 REK的签名以及对 DRM代理发送的删除许可的请求消息的 签名。
较佳地， 该证明中还可以包含一个时间戳， 以防止 DRM代理反复使用 这个证明然后从 RI处"骗取"许可等， 即 SRM代理的签名范围可以包括一个 时间戳；
步骤 903、 DRM代理与 RI进行交互， 获取许可对应的 REK。
较佳地， 为了安全起见， DRM代理应该向 RI提供" SRM上的确存在相 应许可以及该许可已经被 SRM 代理删除"的证明。 RI 在验证该证明后， 向 DRM 代理发送绑定于 DRM 代理的 REK (即用 DRM 代理的公钥加密的 REK ), 这个 REK应该与先前存储在 SRM中的 REK相同。
步骤 904、 DRM代理根据许可的相关信息和许可的 REK, 安装许可。 本实施例中， DRM代理从 SRM代理获取到许可的相关信息即除了 REK 之外的信息后， 删除 SRM上的许可， 然后从 RI获取 REK, 再根据获取到的 许可的相关信息和 REK, 安装许可， 同样实现了可以将不具备转移权限的许 可从 SRM上转移到 DRM代理所在的设备上，从而扩展了不具备转移权限的 许可的应用。
图 10 为本发明实施例一种转移许可的方法的第二实施例中交互协议具 体化后的流程示意图， 如图 10所示， 具体的流程可以包括以下步骤：
步骤 1001、 DRM代理向 SRM代理发送许可信息查询请求消息； 步骤 1002、 SRM代理接收到许可信息查询请求消息后， 向 DRM代理 返回许可信息查询响应消息。
通过步骤 1001和步骤 1002, DRM代理从 SRM上获得了关于待删除的 许可 RO除了 REK之外的所有信息， 包括： <rights>元素、 RI对<1^^^>元 素的签名、 许可的元数据 （ Meta Data )、 以及对应的状态信息 （ State Information ) (如果该许可是有状态许可的话）。
其中，步骤 1001中 DRM代理所发送的许可信息查询请求消息所包含的 字段可以如表 12所示：
表 12许可信息查询请求消息中的字段 ( Fields of RightslnfoQueryRequest ) 字段 ( Fields ) 描述 ( Description ) 字段 ( Fields ) 描述 ( Description )
句柄 ( Handle ) 许可在 SRM上的唯一标识。
其中，步骤 1002中 SRM代理返回的许可信息查询响应消息所包含的字 段可以如表 13所示：
表 13许可信息查询响应消息中的字段 ( Fields of RightslnfoQueryResponse ) 字段 ( Fields ) 描述 ( Description )
状态 （Status ) SRM代理处理许可信息查询请求消息的结果。如果有错误发生， 在许可信息查询响应消息中将只有这个字段出现。
权限元数据 ( Rights Meta Data ) 许可的元数据， 包括如下信息：
Rights Object Version (许可版本 );
RO Alias (许可别名 );
Rights Issuer Identifier ( RI的标识 );
Rights Issuer URL ( RI ^ URL );
Rights Issuer Alias ( RI的别名 );
Rights Issuer Time Stamp ( RI发行许可的时间戳）。
权限对象容器 （ Rights Object 包含了 <rights>元素和 <signature>元素的容器。
Gontsinsr )
状态信息（ State Information ) 许可的剩余状态信息， 如还剩下多少次播放权限等。 如果许可是 无状态的， 则该字段不出现。
步骤 1003、 DRM 代理接收到许可信息查询响应消息后， 根据 <rights> 元素和该许可的状态信息（ State Information )可以获知该许可 RO不具备转 移权限。
接收许可信息查询响应消息后， DRM代理通过分析 <rights>元素以及该 许可的状态信息， 即可发现许可 RO不具备转移权限。 设备可以通过弹出对 话框的方式， 提示用户对 RO进行删除。
步骤 1004、 用户通过 DRM代理所在设备或者其他设备登录到 RI提供 的网站， 通过网站提供的页面， 提交关于转移 SRM上的 R0的请求。 较佳 地， 用户可以通过网页指定需要转移的许可的标识等。
步骤 1005、 RI进行诸如计费等操作后， 向 DRM代理推送一个 REK触 发（ REKTrigger )消息， 该触发消息可以用于触发 DRM代理向 RI获取许可 对应的 REK。 REK触发消息所包含的字段可以如表 14所示：
表 14 REK触发消息中的字段 ( Fields of REKTrigger )
Figure imgf000028_0001
步骤 1006、 DRM代理接收到 REK触发消息后， 向 SRM代理发送许可 删除请求 ( Rig htsRemoval Request ) 消息。
许可删除请求消息所包含的字段可以如表 15所示：
表 15许可删除请求消息中的字段 ( Fields of RightsRemovalRequest )
Figure imgf000028_0002
步骤 1007、 SRM代理接收到许可删除请求消息后， 向 DRM代理返回 许可删除响应 ( RightsRemovalResponse ) 消息。
许可删除响应消息所包含的字段可以如表 16所示：
表 16许可删除响应消息中的字段 ( Fields of RightsRemovalResponse )
Figure imgf000028_0003
上述的 RemovalProof字段用于证明许可已经从 SRM上删除，该证明包 含 SRM对如下信息组合的签名：
{
促使 SRM代理进行删除操作的 DRM代理的标识;
删除的时间；
表示删除操作的标识；
被删除许可的 REK;
被删除许可的标识；
}； 步骤 1008、 DRM代理接收到许可删除响应消息后， 向 RI发送 REK请 求消息。
REK请求消息所包含的字段可以如表 17所示：
表 17 REK请求消息中的字段（ Fields of REKRequest )
Figure imgf000029_0001
步骤 1009、 RI接收到 REK请求消息后， 向 DRM代理返回 REK响应
( REKResponse ) 消息。
REK响应消息所包含的字段可以如表 18所示：
表 18 REK响应消息中的字段（ Fields of Response )
Figure imgf000029_0002
上述的 EncryptedREK字段是使用 DRM代理公钥加密的 REK,该 REK 用于解密 REK请求消息中 <^^^>元素内的 EncryptedCEK;
步骤 1010、 DRM代理根据许可的相关信息和许可的 REK, 安装许可。 图 11 为本发明实施例另一种转移许可的方法的第一实施例的流程示意 图， 如图 11所示， 本实施例可以包括以下步骤：
步骤 1101、 终端设备上的 DRM代理与 SRM上的 SRM代理进行交互， 获得上述 SRM上的待转移许可的许可相关信息；
步骤 1102、 上述 DRM代理与 RI进行交互， 向上述 RI提供上述许可相 关信息， 并从上述 RI获得表明上述 RI允许上述 DRM代理对上述待转移许 可进行转移的转移权限；
步骤 1103、 上述 DRM代理根据上述转移权限， 将上述待转移许可转移 到上述 DRM代理所在设备上。
本实施例中， DRM代理根据获取的待转移许可的许可相关信息向 RI申 请对该许可进行转移，在得到 RI的批准后，将许可从 SRM上强行转移到 DRM 代理所在的设备上， 实现了可以将不具备转移权限的许可从 SRM 上转移出 来， 从而扩展了许可的应用。
图 12 为本发明实施例另一种转移许可的方法的第二实施例的流程示意 图， 如图 12所示， 本实施例可以包括以下步骤：
步骤 1201、 RI向 DRM代理发送触发消息， 以触发 DRM代理向 RI获 取允许将 SRM上不具备转移权限的许可转移出来的批准。
较佳地， 上述触发消息中可以包含待转移的许可的标识， 这样 DRM 代 理接收到该触发消息时知道将为哪一个许可获取批准。在 RI发送该触发消息 之前， 终端用户需要借助 DRM代理所在设备或者其他设备访问 RI的网站， 提交关于希望将 SRM中许可转移给自己的请求， RI进行一些诸如计费相关 的操作后， 便可以发送该触发消息给 DRM代理。
本步骤为可选步骤， 本实施例也可以直接从步骤 1202开始；
步骤 1202、 DRM代理与 SRM代理进行交互，准备转移 SRM上的许可， 上述准备工作至少包括： DRM代理指示 SRM代理将待转移许可置为不可用 状态。
较佳地， DRM代理可以从 SRM代理获得 "该 SRM上的确存在待转移 的许可"的证明，该证明的形式可以是 SRM代理对许可对应的 REK的签名。
较佳地， 该证明中还可以包含一个时间戳， 以防止 DRM代理反复使用 这个证明然后从 RI处 "骗取" 许可等， 即 SRM代理的签名范围可以包括一 个时间戳。
本步骤为可选步骤， 本实施例也可以直接从步骤 1203开始；
步骤 1203、 DRM代理与 RI进行交互， 获取关于将 SRM上的待转移的 许可转移出来的批准。
较佳地， DRM代理可以向 RI出示" SRM上的确存在上述待转移的许可" 的证明 （即 SRM代理对 REK的签名）。 RI在验证 SRM上的确存在上述待 转移的许可后， 将批准信息通过消息发送给 DRM代理。 DRM代理接收到该 批准信息后， 可以将该批准保存下来。
较佳地， 为安全起见， RI可以对上述批准信息进行签名； 步骤 1204、 DRM代理与 SRM代理进行交互， 将许可从 SRM上转移到 设备上。
本实施例中， DRM代理发现许可不具备转移权限后， 向 RI申请对该许 可进行转移， 在得到 RI的批准后， 将许可从 SRM上强行转移到 DRM代理 所在的设备上。 虽然许可自身表明它不具备转移权限， 但是在 DRM代理获 得的批准指示下， DRM代理仍然可以将许可从 SRM上转移到设备上。 这需 要在 OMA SRM1.0所公开的许可删除（ Rights Removal )协议基础上进行适 当的爹改。
图 13 为本发明实施例另一种转移许可的方法的第二实施例中交互协议 具体化后的流程示意图， 如图 13所示， 具体的流程可以包括以下步骤： 步骤 1301、 DRM代理向 SRM代理发送许可信息查询请求消息， 该消 息包含 Handle字段；
步骤 1302、 SRM代理接收到许可信息查询请求消息后， 向 DRM代理 返回许可信息查询响应消息，该消息包含 Rights字段、 MetaData字段、 Rights Object Container字段、 State Information字段。
通过步骤 1301和步骤 1302, DRM代理从 SRM上获得了关于待转移的 许可 RO除了 REK之外的所有信息， 包括： <rights>元素、 RI对<1^ ^^>元 素的签名、 许可的元数据 （ Meta Data )、 以及对应的状态信息 （ State Information ) (如果该许可是有状态许可的话）；
步骤 1303、 DRM 代理接收到许可信息查询响应消息后， 根据 <rights> 元素和该许可的状态信息（ State Information )可以获知该许可 RO不具备转 移权限。
接收许可信息查询响应消息后， DRM代理通过分析 <rights>元素以及该 许可的状态信息， 即可发现许可 RO不具备转移权限。 设备可以通过弹出对 话框的方式， 提示用户对 RO进行删除；
步骤 1304、 用户通过 DRM代理所在设备或者其他设备登录到 RI提供 的网站， 通过网站提供的页面， 提交关于获取 SRM上的 RO的转移权限的 请求。 较佳地， 用户可以通过网页指定需要转移的 RO的标识等。
步骤 1305、 RI进行诸如计费等操作后， 向 DRM代理推送一个转移批准 触发（ MovePermissionTrigger ) 消息， 该触发消息可以用于触发 DRM代理 向 RI 获取许可的转移权限， 该消息包含 ROID 字段、 转移需求信息 ( MoveRequirementlnfo )字段、 REKNeeded字段； 其中转移需求信息用于 表示用户指定的具体转移要求， 如： 需要对什么许可进行转移， 可转移次数 是多少等。 用户可以通过 RI提供的网页中指定这些要求。
步骤 1306、 DRM代理接收到转移批准触发消息后， 向 SRM代理发送 转移准备请求（ MoveSetupRequest )消息， 该消息包含 Handle字段、 New Handle字段、 REKNeeded字段；
步骤 1307、 SRM代理接收到转移准备请求消息后， 向 DRM代理返回 转移准备响应 （ MoveSetupResponse ) 消息， 该消息包含 ExistProof字段、 EncryptedREK字段；
步骤 1308、 DRM代理接收到转移准备响应消息后， 向 RI发送转移批准 请求 ( MovePermission Request ) 消息， 该消息包含 ROID 字段、 <rights> 字段、 <signature>字段、 State Information字段、 SRMSignOverREK字段、 EncryptedREK字段、 MoveRequirementlnfo字段； 这些字段可以参考前述 实施例。
步骤 1309、 RI接收到转移批准请求消息后， 向 DRM代理返回转移批准 响应 （ MovePermissionResponse ) 消息， 该转移批准响应消息包含转移批 准 ( MovePermission )字段。 MovePermission字段包含如下信息的签名： 表示转移动作的标识；
待转移的许可的标识；
为安全起见， RI 可以对 MovePermission 字段进行签名 ， 随 MovePermission字段一起发送给 DRM代理。
步骤 1310、 DRM代理根据 RI的转移批准 ( MovePermission )字段， 将许可从 SRM上转移到设备上。 DRM代理可以在收到转移批准响应后立即 根据其中的 MovePermission字段执行转移操作，也可以将 MovePermission 字段保存下来， 在后续时间里进行转移操作， 具体视用户的需要而定。
图 14为本发明实施例一种 4受权中心实施例的结构示意图，如图 14所示， 本实施例可以包括： 新许可生成模块 1401 , 用于根据通过 DRM代理以及 SRM代理获得的 SRM上的待更新许可的许可相关信息生成新许可；
新许可提供模块 1402 , 用于向上述 DRM代理提供上述新许可。
图 15为本发明实施例一种数字版权管理代理实施例的结构示意图，如图 15所示， 本实施例可以包括：
许可相关信息获取模块 1501 , 用于从 SRM代理获得 SRM上的待更新 许可的许可相关信息， 并向 RI提供上述许可相关信息；
第一许可更新模块 1502,用于通过上述 SRM代理用上述 RI根据上述许 可相关信息生成的新许可更新上述 SRM上的上述待更新许可。
本发明实施例上述一种 4受权中心和一种数字版权管理代理实施例可以用 于本发明实施例一种更新许可的方法的第一实施例和第二实施例中的流程。
图 16为本发明实施例另一种授权中心实施例的结构示意图， 如图 16所 示， 本实施例可以包括：
新许可生成模块 1601 , 用于根据通过 DRM代理以及 SRM代理获得的 SRM上的待更新许可的许可相关信息生成新许可；
第二许可更新模块 1602, 用于通过上述 DRM代理以及上述 SRM代理 用上述新许可更新上述 SRM上的待更新许可。
图 17为本发明实施例另一种数字版权管理代理实施例的结构示意图，如 图 17所示， 本实施例可以包括：
许可相关信息获取模块 1701 , 用于从 SRM代理获得 SRM上的待更新 许可的许可相关信息， 并向 RI提供上述许可相关信息；
新许可获取模块 1702, 用于从上述 RI获得根据上述许可相关信息生成 的新许可。
本发明实施例上述另一种授权中心和另一种数字版权管理代理实施例可 以用于本发明实施例另一种更新许可的方法的第一实施例和第二实施例中的 流程。
图 18为本发明实施例又一种数字版权管理代理实施例的结构示意图，如 图 18所示， 本实施例可以包括：
接收模块 1801 , 用于接收 RI所发送的触发消息， 上述触发消息中包含 SRM上待删除许可的标识；
删除模块 1802, 用于通知上述 SRM代理将上述待删除许可删除。 例一种删除许可的方法实施例中的流程。
图 19为本发明实施例再一种 4受权中心的结构示意图， 如图 19所示， 本 实施例可以包括： 移许可的许可相关信息后，触发上述 DRM代理通过上述 SRM代理删除上述 SRM上的上述待转移许可；
REK提供模块 1902 , 用于向上述 DRM 代理提供上述待转移许可的
REK。
图 20为本发明实施例再一种数字版权管理代理实施例的结构示意图，如 图 20所示， 本实施例可以包括：
许可相关信息获取模块 2001 , 用于从 SRM代理获得 SRM上的待更新 许可的许可相关信息， 并向 RI提供上述许可相关信息；
REK获取模块 2002,用于接收上述 RI所提供的上述待转移许可的 REK。 本发明实施例上述再一种授权中心和再一种数字版权管理代理实施例可 以用于本发明实施例一种转移许可的方法的第一实施例和第二实施例中的流 程。
图 21为本发明实施例还一种授权中心实施例的结构示意图， 如图 21所 示， 本实施例可以包括：
转移权限生成模块 2101 , 用于根据通过 DRM代理以及 SRM代理获取 SRM上的待转移许可的许可相关信息生成上述待转移许可的转移权限；
转移权限提供模块 2102, 用于向上述 DRM代理提供上述待转移许可的 转移权限。
图 22为本发明实施例还一种数字版权管理代理实施例的结构示意图，如 图 22所示， 本实施例可以包括：
许可相关信息获取模块 2201 , 用于从 SRM代理获得 SRM上的待更新 许可的许可相关信息， 并向 RI提供上述许可相关信息； 许可转移模块 2202, 用于接收上述 RI所提供的上述待转移许可的转移 权限， 并根据上述转移权限通过上述 SRM 代理将上述待转移许可转移到上 述 DRM代理所在设备上。
本发明实施例上述还一种 4受权中心和还一种数字版权管理代理实施例可 以用于本发明实施例另一种转移许可的方法的第一实施例和第二实施例中的 流程。
图 23为本发明实施例一种安全可移动媒体代理实施例的结构示意图，如 图 23所示， 本实施例可以包括：
许可相关信息提供模块 2301， 用于向 DRM代理提供待更新许可的许可 相关信息；
许可更新模块 2302, 用于接收 DRM代理发送的、 根据待更新许可的许 可相关信息生成的新许可， 并更新上述待更新许可。
图 24为本发明实施例另一种安全可移动媒体代理实施例的结构示意图， 如图 24所示， 本实施例可以包括：
消息接收模块 2401， 用于接收 DRM代理发送的许可删除请求消息； 删除模块 2402,用于根据收到的许可删除请求消息将待删除许可删除并 向上述 DRM代理返回删除证明。 的许可的相关信息与 RI进行交互， 从 RI获取新许可或转移权限， 将许可从 SRM上转移出来，实现了可以将不具备转移权限的许可从 SRM上转移出来， 从而扩展了不具备转移权限的许可的应用。
本领域普通技术人员可以理解： 实现上述方法实施例的全部或部分步骤 可以通过程序指令相关的硬件来完成， 前述的程序可以存储于一计算机可读 取存储介质中， 该程序在执行时， 执行包括上述方法实施例的步骤； 而前述 的存储介质包括： ROM、 RAM, 磁碟或者光盘等各种可以存储程序代码的介 质。
最后应说明的是： 以上实施例仅用以说明本发明的技术方案， 而非对其 限制； 尽管参照前述实施例对本发明进行了详细的说明， 本领域的普通技术 人员应当理解： 其依然可以对前述各实施例所记载的技术方案进行修改， 或 者对其中部分技术特征进行等同替换； 而这些修改或者替换， 并不使相应技 术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims

权 利 要求
1、 一种更新许可的方法， 其特征在于， 包括：
DRM代理从 SRM代理获得待更新许可的许可相关信息；
所述 DRM代理向 RI提供所述许可相关信息， 并从所述 RI获得新许可； 所述 DRM代理与所述 SRM代理进行交互， 利用所述新许可更新所述
SRM上的所述待更新许可。
2、 根据权利要求 1 所述的方法， 其特征在于， 所述 DRM代理从所述 RI获得新许可之前还包括： 所述待更新许可的存在证明， 并向所述 RI传送所述存在证明；
在所述 RI验证所述存在证明通过后， 所述新许可被发送给所述 DRM代 理。
3、 根据权利要求 2 所述的方法， 其特征在于， 所述存在证明包含所述 SRM代理对第一信息的签名，所述第一信息至少包含所述待更新许可的权限 加密密钥 REK和 /或所述待更新许可的标识。
4、 根据权利要求 1所述的方法， 其特征在于， 所述从所述 RI获得新许 可之前还包括： 通过所述 SRM代理将所述待更新许可置为不可用状态。
5、 根据权利要求 1所述的方法， 其特征在于， 所述从所述 RI获得新许 可之前还包括： 向所述 RI传送许可更新需求信息。
6、 根据权利要求 5所述的方法， 其特征在于， 所述新许可是由所述 RI 根据所述待更新许可的许可相关信息与所述许可更新需求信息生成的。
7、 根据权利要求 1 所述的方法， 其特征在于， 所述 DRM代理与所述 体包括：
所述 DRM 代理从所述新许可中得到所述新许可的许可相关信息和所述 新许可的 REK, 所述新许可的 REK是由所述 RI釆用所述 SRM代理能够解 密、 而所述 DRM代理无法解密的方式加密的；
所述 DRM代理向所述 SRM代理发送所述新许可的许可相关信息以及所 述新许可的 REK,由所述 SRM代理解密所述新许可的 REK得到 REK明文， 并将所述新许可的许可相关信息和所述 REK明文存储到所述 SRM上。
8、 根据权利要求 1所述的方法， 其特征在于， 所述利用所述新许可更新 所述 SRM上的所述待更新许可具体为：
所述 DRM代理将所述新许可传送给所述 SRM代理， 由所述 SRM代理 用所述新许可替换所述待更新许可； 或
所述 DRM代理通过所述 SRM代理删除所述待更新许可后，将所述新许 可传送给所述 SRM代理， 由所述 SRM代理将所述新许可安装到所述 SRM 上。
9、 根据权利要求 1所述的方法， 其特征在于， 所述利用所述新许可更新 所述 SRM上的所述待更新许可之后或同时还包括：所述 DRM代理通知所述
RI所述新许可替换所述待更新许可完毕。
10、 根据权利要求 9所述的方法， 其特征在于， 所述利用所述新许可更 新所述 SRM上的所述待更新许可之后还包括： 述新许可所替换的替换证明；
所述 DRM代理向所述 RI传送所述替换证明， 以表明所述新许可替换所 述待更新许可完毕。
11、根据权利要求 10所述的方法， 其特征在于， 所述替换证明包含所述 SRM代理对第二信息的签名，所述第二信息至少包含如下信息中的一项或任 意组合： 所述新许可对应的 REK; 所述新许可的标识； 所述 DRM代理的标 识； 表示替换动作的标识； 所述待更新许可为所述新许可替换的时间； 所述 待更新许可的 REK; 所述待更新许可的标识。
12、 根据权利要求 8所述的方法， 其特征在于， 代理获取用于表明所述待更新许可已经从所述 SRM上删除的删除证明； 在所述 SRM代理安装所述新许可后， 所述 DRM代理从所述 SRM代理 获取用于表明所述新许可已经安装到所述 SRM的安装证明；
所述 DRM代理向所述 RI传送所述删除证明和安装证明， 以表明所述新 许可替换所述待更新许可完毕。
13、 根据权利要求 12 所述的方法， 其特征在于， 所述删除证明包含所 述 SRM 对第三信息的签名， 所述第三信息至少包含如下信息中的一项或任 意组合： 所述待更新许可的 REK; 所述待更新许可的标识； 所述 DRM代理 的标识； 表示删除动作的标识； 所述待更新许可被删除的时间；
所述安装证明包含所述 SRM 对第四信息的签名， 所述第四信息至少包 含如下信息中的一项或任意组合： 所述新许可的 REK; 所述新许可的标识； 所述 DRM代理的标识； 表示安装动作的标识； 表明新许可被安装的时间。
14、 一种更新许可的方法， 其特征在于， 包括： 相关信息；
所述 RI用所生成的新许可更新所述 SRM上的待更新许可。
15、 根据权利要求 14所述的方法， 其特征在于， 所述 RI用所生成的新 许可更新所述 SRM上的待更新许可具体包括：
所述 RI在确认所述待更新许可从所述 SRM删除后， 触发所述 DRM代 理从所述 RI获得所述新许可， 通过 DRM代理将许可安装到所述 SRM上。
16、 根据权利要求 15 所述的方法， 其特征在于， 所述待更新许可从所 述 SRM删除包括：
由 RI触发所述 DRM代理与所述 SRM代理进行交互删除所述 SRM上 的所述待更新许可。
17、 根据权利要求 15所述的方法， 其特征在于， 所述 DRM代理从所述
RI获得所述新许可之前还包括： 所述 DRM代理获得所述 SRM代理釆用所 述 RI能够解密而所述 DRM代理无法解密的方式加密了的所述待更新许可的 REK, 所述 DRM代理向所述 RI传送所述加密了的 REK, 所述 RI解密所述 加密了的 REK得到 REK明文， 以供验证所述待更新许可。
18、 根据权利要求 15所述的方法， 其特征在于， 所述 RI在确认所述待 更新许可从所述 SRM删除具体为： 所述 RI通过验证删除证明来确认所述待 更新许可从所述 SRM删除， 所述删除证明由所述 SRM代理提供、 经由所述 DRM代理传送给所述 Rl。
19、 根据权利要求 14 所述的方法， 其特征在于， 所述待更新许可为一 个缺乏转移权限的许可， 所述新许可为一个具备了转移权限的许可。
20、 一种删除许可的方法， 其特征在于， 包括：
DRM代理接收 RI所发送的触发消息， 所述触发消息中包含 SRM上待 删除许可的标识；
所述 DRM代理与所述 SRM上的 SRM代理进行交互， 将所述待删除许 可删除。
21、 根据权利要求 20 所述的方法， 其特征在于， 所述将所述待删除许 可删除之后还包括： 通知所述 RI所述待删除许可删除完毕。
22、 根据权利要求 21所述的方法， 其特征在于， 所述通知所述 RI所述 待删除许可删除完毕具体包括： 已经从所述 SRM删除的删除证明；
所述 DRM将所述删除证明发送给所述 RI ,以向所述 RI表明所述待删除 许可已删除完毕。
23、 一种转移许可的方法， 其特征在于， 包括：
通过 DRM代理以及 SRM代理， RI获取所述 SRM上的待转移许可的许 可相关信息；
所述 RI触发所述 DRM代理删除所述 SRM上的所述待转移许可， 并向 所述 DRM代理提供所述待转移许可的 REK。
24、根据权利要求 23所述的方法， 其特征在于， 所述 RI触发所述 DRM 代理删除所述 SRM上的所述待转移许可，并向所述 DRM代理提供所述待转 移许可的 REK具体包括：
所述 RI向所述 DRM代理发送触发消息， 所述触发消息中包含所述待转 移许可的标识；
所述 DRM代理根据所述触发消息与所述 SRM代理进行交互，通过所述
SRM代理删除所述待转移许可；
所述 DRM代理与所述 RI进行交互， 从所述 RI获取所述待转移许可的 REK。
25、 根据权利要求 24所述的方法， 其特征在于， 所述通过所述 SRM代理删除所述待转移许可具体包括：所述 DRM代理 与所述 SRM代理进行交互， 删除所述 SRM上的所述待更新许可， 并从所述 SRM代理获取用于表明所述待转移许可已经被所述 SRM代理删除的删除证 明；
所述从所述 RI获取所述待转移许可的 REK具体包括： 所述 DRM代理 将所述删除证明发送给所述 RI , 所述 RI在验证所述删除证明成功后向所述 DRM代理发送所述待转移许可的 REK。
26、 一种转移许可的方法， 其特征在于， 包括：
DRM代理与 SRM代理进行交互， 获得所述 SRM上的待转移许可的许 可相关信息；
所述 DRM代理与 RI进行交互， 向所述 RI提供所述许可相关信息， 并 从所述 RI获得所述待转移许可的转移权限；
所述 DRM代理根据所述转移权限， 将所述待转移许可转移到所述 DRM 代理所在设备上。
27、 根据权利要求 26所述的方法， 其特征在于， 所述从所述 RI获得所 述待转移许可的转移权限之前还包括： 通过所述 SRM 代理将所述待转移许 可置为不可用状态。
28、 根据权利要求 27所述的方法， 其特征在于， 所述从所述 RI获得所 述待转移许可的转移权限之前还包括： 所述待转移许可的存在证明；
所述 DRM代理向所述 RI传送所述存在证明；
所述 RI验证所述存在证明通过后向所述 DRM代理发送所述转移权限。
29、 根据权利要求 27所述的方法， 其特征在于， 所述从所述 RI获得所 述待转移许可的转移权限之前还包括：
所述 DRM代理从所述 SRM代理获取 SRM提供的釆用所述 RI能够解 密而所述 DRM代理无法解密的方式加密的所述待转移许可的 REK;
所述 DRM代理将所述加密了的 REK传送给所述 RI;
所述 RI解密所述加密了的 REK, 以供验证所述待转移许可。
30、 根据权利要求 27所述的方法， 其特征在于， 所述从所述 RI获得所 述待转移许可的转移权限之前还包括： 从所述 RI收到触发消息， 所述触发消 息中包含所述待转移许可的标识、 转移需求信息中的一项或任意组合。
31、 根据权利要求 27所述的方法， 其特征在于， 所述从所述 RI获得所 述待转移许可的转移权限之前还包括： 向所述 RI发送转移需求信息。
32、 一种 4受权中心， 其特征在于， 包括：
新许可生成模块， 用于根据通过 DRM代理以及 SRM代理获得的 SRM 上的待更新许可的许可相关信息生成新许可；
新许可提供模块， 用于向所述 DRM代理提供所述新许可。
33、 一种数字版权管理代理， 其特征在于， 包括：
许可相关信息获取模块，用于从 SRM代理获得 SRM上的待更新许可的 许可相关信息， 并向 RI提供所述许可相关信息；
第一许可更新模块， 用于通过所述 SRM代理用所述 RI根据所述许可相 关信息生成的新许可更新所述 SRM上的所述待更新许可。
34、 一种授权中心， 其特征在于， 包括：
新许可生成模块， 用于根据通过 DRM代理以及 SRM代理获得的 SRM 上的待更新许可的许可相关信息生成新许可；
第二许可更新模块，用于通过所述 DRM代理以及所述 SRM代理用所述 新许可更新所述 SRM上的待更新许可。
35、 一种数字版权管理代理， 其特征在于， 包括：
许可相关信息获取模块，用于从 SRM代理获得 SRM上的待更新许可的 许可相关信息， 并向 RI提供所述许可相关信息；
新许可获取模块，用于从所述 RI获得根据所述许可相关信息生成的新许 可。
36、 一种数字版权管理代理， 其特征在于， 包括：
接收模块， 用于接收 RI所发送的触发消息， 所述触发消息中包含 SRM 上待删除许可的标识；
删除模块， 用于通知所述 SRM代理将所述待删除许可删除。
37、 一种 4受权中心， 其特征在于， 包括： 可的许可相关信息后，触发所述 DRM代理通过所述 SRM代理删除所述 SRM 上的所述待转移许可；
REK提供模块， 用于向所述 DRM代理提供所述待转移许可的 REK。
38、 一种数字版权管理代理， 其特征在于， 包括：
许可相关信息获取模块，用于从 SRM代理获得 SRM上的待更新许可的 许可相关信息， 并向 RI提供所述许可相关信息；
REK获取模块， 用于接收所述 RI所提供的所述待转移许可的 REK。
39、 一种 4受权中心， 其特征在于， 包括：
转移权限生成模块， 用于根据通过 DRM代理以及 SRM代理获取 SRM 上的待转移许可的许可相关信息生成所述待转移许可的转移权限；
转移权限提供模块， 用于向所述 DRM 代理提供所述待转移许可的转移 权限。
40、 一种数字版权管理代理， 其特征在于， 包括：
许可相关信息获取模块，用于从 SRM代理获得 SRM上的待更新许可的 许可相关信息， 并向 RI提供所述许可相关信息；
许可转移模块， 用于接收所述 RI所提供的所述待转移许可的转移权限， 代理所在设备上。
PCT/CN2009/071174 2008-07-07 2009-04-07 许可的处理方法及装置 WO2010003328A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP09793803A EP2299378A4 (en) 2008-07-07 2009-04-07 PROCESSING METHOD AND DEVICE FOR A RIGHT OBJECT
US12/980,050 US8336109B2 (en) 2008-07-07 2010-12-28 Method and apparatus for processing rights object
US13/540,212 US8353055B2 (en) 2008-07-07 2012-07-02 Method and apparatus for processing rights object

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810130556.7A CN101626371B (zh) 2008-07-07 2008-07-07 许可的处理方法及装置
CN200810130556.7 2008-07-07

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/980,050 Continuation US8336109B2 (en) 2008-07-07 2010-12-28 Method and apparatus for processing rights object

Publications (1)

Publication Number Publication Date
WO2010003328A1 true WO2010003328A1 (zh) 2010-01-14

Family

ID=41506679

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/071174 WO2010003328A1 (zh) 2008-07-07 2009-04-07 许可的处理方法及装置

Country Status (4)

Country Link
US (2) US8336109B2 (zh)
EP (1) EP2299378A4 (zh)
CN (1) CN101626371B (zh)
WO (1) WO2010003328A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011099903A1 (en) 2010-02-11 2011-08-18 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses and methods for enabling a user to consume protected contents of a content provider
US8336109B2 (en) 2008-07-07 2012-12-18 Huawei Technologies Co., Ltd. Method and apparatus for processing rights object

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100925731B1 (ko) * 2006-04-05 2009-11-10 엘지전자 주식회사 디지털 저작권 관리에서의 사용권리 전달 방법 및 장치
KR101649528B1 (ko) * 2009-06-17 2016-08-19 엘지전자 주식회사 메모리 카드에 저장되어 있는 권리를 업그레이드하는 방법 및 장치
US20120303974A1 (en) * 2011-05-25 2012-11-29 Condel International Technologies Inc. Secure Removable Media and Method for Managing the Same
CN102945532A (zh) * 2012-11-20 2013-02-27 南京邮电大学 一种支持版权转让的数字版权实现方法
TWI524718B (zh) * 2012-12-06 2016-03-01 財團法人資訊工業策進會 進行委任金鑰管理之主要管理裝置、代理管理裝置、電子裝置及其金鑰管理方法
US20150312697A1 (en) * 2014-04-28 2015-10-29 Intel IP Corporation Dynamic declaration of conformity and certification for radio application distribution
US9430619B2 (en) * 2014-09-10 2016-08-30 Microsoft Technology Licensing, Llc Media decoding control with hardware-protected digital rights management
US10068098B2 (en) * 2015-04-17 2018-09-04 Cicer One Technologies Inc. Data storage and access platform with jurisdictional control
US9841999B2 (en) 2015-07-31 2017-12-12 Futurewei Technologies, Inc. Apparatus and method for allocating resources to threads to perform a service
CN106649395B (zh) * 2015-11-03 2021-05-25 腾讯科技（深圳）有限公司 网页更新方法和装置
US10013558B1 (en) * 2015-12-17 2018-07-03 Lockheed Martin Corporation Method and computer readable medium for secure software installation mechanism
US10806334B2 (en) 2017-02-28 2020-10-20 Verily Life Sciences Llc System and method for multiclass classification of images using a programmable light source
US11645384B2 (en) 2021-03-03 2023-05-09 Bank Of America Corporation System for electronic data obfuscation and protection using independent destructible data objects

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004077911A2 (en) * 2003-03-03 2004-09-16 Sony Ericsson Mobile Communications Ab Rights request method
CN1728039A (zh) * 2004-07-29 2006-02-01 Lg电子株式会社 用于处理数字权利管理系统中的权利对象的方法和系统
CN1851608A (zh) * 2005-09-28 2006-10-25 华为技术有限公司 Drm系统内撤销ro的方法及系统
CN101038610A (zh) * 2006-03-16 2007-09-19 华为技术有限公司 一种具有版权属性对象更新的方法及装置
CN101089865A (zh) * 2006-06-12 2007-12-19 华为技术有限公司 一种域许可转移的方法、装置及系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020019814A1 (en) * 2001-03-01 2002-02-14 Krishnamurthy Ganesan Specifying rights in a digital rights license according to events
JP5084515B2 (ja) * 2005-01-13 2012-11-28 サムスン エレクトロニクス カンパニー リミテッド ホスト装置、携帯用保存装置、及び携帯用保存装置に保存された権利オブジェクトのメタ情報を更新する方法。
KR20070050712A (ko) * 2005-11-11 2007-05-16 엘지전자 주식회사 Srm의 디지털 저작권 관리 방법 및 장치
WO2007108619A1 (en) * 2006-03-17 2007-09-27 Lg Electronics Inc. Method for moving and sharing digital contents and rights object and device thereof
EP2034420A4 (en) * 2006-06-26 2009-10-21 Huawei Tech Co Ltd METHOD AND DEVICE OF OPERATING RIGHTS
CN101626371B (zh) 2008-07-07 2014-04-30 华为技术有限公司 许可的处理方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004077911A2 (en) * 2003-03-03 2004-09-16 Sony Ericsson Mobile Communications Ab Rights request method
CN1728039A (zh) * 2004-07-29 2006-02-01 Lg电子株式会社 用于处理数字权利管理系统中的权利对象的方法和系统
CN1851608A (zh) * 2005-09-28 2006-10-25 华为技术有限公司 Drm系统内撤销ro的方法及系统
CN101038610A (zh) * 2006-03-16 2007-09-19 华为技术有限公司 一种具有版权属性对象更新的方法及装置
CN101089865A (zh) * 2006-06-12 2007-12-19 华为技术有限公司 一种域许可转移的方法、装置及系统

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8336109B2 (en) 2008-07-07 2012-12-18 Huawei Technologies Co., Ltd. Method and apparatus for processing rights object
US8353055B2 (en) 2008-07-07 2013-01-08 Huawei Technologies Co., Ltd. Method and apparatus for processing rights object
WO2011099903A1 (en) 2010-02-11 2011-08-18 Telefonaktiebolaget Lm Ericsson (Publ) Apparatuses and methods for enabling a user to consume protected contents of a content provider
EP2534603A4 (en) * 2010-02-11 2017-06-28 Telefonaktiebolaget LM Ericsson (publ) Apparatuses and methods for enabling a user to consume protected contents of a content provider

Also Published As

Publication number Publication date
US20110091041A1 (en) 2011-04-21
EP2299378A1 (en) 2011-03-23
EP2299378A4 (en) 2012-02-29
US8336109B2 (en) 2012-12-18
US20120272334A1 (en) 2012-10-25
US8353055B2 (en) 2013-01-08
CN101626371A (zh) 2010-01-13
CN101626371B (zh) 2014-04-30

Similar Documents

Publication Publication Date Title
WO2010003328A1 (zh) 许可的处理方法及装置
JP4790021B2 (ja) Ｓｒｍのデジタル著作権管理方法及び装置
JP4913871B2 (ja) セキュアコンテンツおよびアプリケーションのコピーを防ぐセキュリティメカニズムを有するメモリカードのアップグレード
JP4976492B2 (ja) ライセンスをバックアップおよび復元するための方法とシステム
JP4664352B2 (ja) デバイスと携帯用保存装置との間に権利客体を移動またはコピーする方法及び装置
EP1509024B1 (en) Method for sharing rights objects between users
US20040039932A1 (en) Apparatus, system and method for securing digital documents in a digital appliance
US8782419B2 (en) Device and method for a backup of rights objects
KR101944800B1 (ko) Ｄｒｍ 모듈 다운로드 방법 및 장치
US8079089B2 (en) Information usage control system and information usage control device
US20110119494A1 (en) Method and apparatus for sharing licenses between secure removable media
EP1754167A1 (en) Method and apparatus for transmitting rights object information between device and portable storage
JP2004046790A (ja) デジタルコンテンツの保護及び管理のためのシステム
KR20080035940A (ko) Ｄｒｍ 제공 장치, 시스템 및 그 방법
WO2006110213A2 (en) Apparatus, system, and method for securing digital documents in a digital appliance
US20130047264A1 (en) Method and Device for Communicating Digital Content
WO2007086015A2 (en) Secure transfer of content ownership
WO2008148356A1 (fr) Procédé, dispositif et système destinés à transférer une autorisation
WO2013075673A1 (zh) 数字版权管理的方法、系统和服务器
KR100917312B1 (ko) 재구매를 위한 디지털 저작권 컨텐츠의 정보 갱신 시스템및 그 방법과 그 기능의 컴퓨터 프로그램이 기록된기록매체
JP2008271564A (ja) ライセンスのオフライン環境下における送信流通システム及び送信流通方法
KR100814064B1 (ko) Ｄｒｍ 컨텐츠 패키징 방법 및 시스템
KR20080082875A (ko) 저작권보호 시스템에서의 효율적인 디지털콘텐츠 라이센스관리 및 운영방법
KR100864949B1 (ko) 한 단말에서 다른 단말로의 디지털 콘텐츠 권리 관리사용자 데이터 전송
JP5975097B2 (ja) 情報処理装置、情報処理システム、および情報処理方法、並びにプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09793803

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2009793803

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE