KR101513026B1 - Method and device for managing authorization of right object in digital rights management - Google Patents

Abstract

The present invention relates to a method and apparatus for managing the issuing rights of a domain RO in devices (entities) of a digital rights management (DRM) system. In a DRM system, a DA / DEA The RDP Drop Domain Protocol is newly defined between the RI and the RI, and the rights to generate and issue the RO of the RI domain RO to the specific user domain are suspended to effectively manage the rights in the DRM system.

DRM, DEA, DA, usage rights, RO, domain, rights management

Description

[0001] METHOD AND APPARATUS FOR MANAGING AUTHORIZATION OF RIGHT OBJECT IN DIGITAL RIGHTS MANAGEMENT [

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to digital rights management (hereinafter referred to as DRM), and more particularly, to a method and apparatus for managing rights of issuing a domain RO between devices (entities) of a DRM system.

DRM is a system technology for safely protecting and systematically managing the rights to digital contents. It is a system technology to prevent illegal copying of contents, to acquire the right to use contents, to provide a series of protection and management system for the production and distribution and use of contents do.

FIG. 1 is a block diagram illustrating a digital rights management system in which the digital rights management system controls the content provider to use only the content provided to the user by the user. At this time, the content provider is an entity corresponding to a content issuer (CI) and / or a rights issuer (RI).

Wherein the content issuer (CI) issues protected content using a specific encryption key so as to protect the content from a user who does not have access rights, and the rights issuer (RI) (RO).

The DRM agent is installed in the device (or terminal), receives the protected content and the usage right, interprets a license included in the usage right, and stores the protected content in a form To control the use of the content.

DA / DEA (Domain Authority / Domain Enforce Agent) is an entity that manages and supervises user domains. That is, the DA defines a domain policy for the user domain, and the DEA is an entity that performs the domain policy set by the DA, and can be in the network or in a device in the domain.

2 is a diagram of a user domain system in DRM. FIG. 2 shows a framework for sharing-key management among user domain key management methods.

Unlike the conventional domain concept of the OMA DRM technology, the user domain only performs the role of issuing the domain rights object (RI) and the domain member is managed by the DA / DEA. The user domain members (i.e., devices subscribed to the user domain) can share the rights object (RO) issued from different service providers with each other through copying and moving.

Referring to FIG. 2, when a device (or a DRM agent) requests a subscription to a corresponding user domain through a Join Domain Request, the DA / DEA verifies the DRM agent, Domain Key) to the terminal securely. At this time, the DA / DEA encrypts the MDK with the device's public key. All devices subscribed to a specific user domain will share the same MDK.

DA / DEA securely issues a DDK (Diversified Domain Key) derived from MDK to RI. The DDK is used to encrypt the Rights Object Encryption Key (REK) of the domain RO. In addition, DA / DEA issues an additional validation token (aka V-Token) to check whether the member of the user domain receives the RO and is a reliable RI. Since the V-Token includes information such as the period or conditions under which the DA / DEA is contracted with the RI, the device (e.g., DEV1 in FIG. 2) Can be verified.

The device can derive the DDK by deriving the MDK issued by the DA / DEA and can also use the RO (ie, domain RO) issued by RI using this DDK. At this time, the device will verify via the V-Token whether the RO is usable before using the RO. Meanwhile, if the terminal (e.g., DEV1) wants to share the RO with another terminal (e.g., DEV2) that is a member of the user domain, the terminal (i.e., DEV1) transmits a DCF (DRM Contents Format) It is possible to transfer the V-Token to another device (that is, DEV2).

3 is a block diagram illustrating a process in which a RI creates a domain RO in a user domain.

Referring to FIG. 3, when the device 1 (or the DRM Agent 1) requests an RO from the RI (S1), the RI determines whether the corresponding user domain (for example, the device 1 is the device 1 and the domain to which the device is subscribed in FIG. (In FIG. 3, Use Domain Request) (S2), and then requests domain information, V-Token (or User Domain Token) and key (DDK or DDK-set) with DEA. The RI receives a response to the request (i.e., Use Domain Response in FIG. 3) from the DEA (S3). After generating the user domain RO based on the received information, i.e., the DDK and the V-Token, in response to the process (S3), the RI issues the generated RO to the device 1 (RO response in FIG. 3) S4).

The object of the present invention is to define the detailed parameters of the RDP Use Domain protocol and to define the RDP Drop Domain protocol. The RDP Use Domain protocol allows DEA to send RI a key material (aka Key Material, eg DDK or DDK-set) required for RI to create an RO, corresponding authority, Domain information, and Domain RO A note is a protocol between DEA and RI. The RDP Drop Domain Protocol is a protocol between DEA and RI that restricts the RO creation rights already granted to RI so that DEA can no longer create a domain RO.

According to an aspect of the present invention, there is provided a rights management method in digital rights management,

(A) the first entity sends a trigger message including first information for stopping the issuing authority of the domain RO to the specific domain to the second entity;

(B) receiving, from the second entity, a message requesting the issuing authority suspension of the domain RO including the second information regarding the suspension of the issuing authority of the domain RO;

(C) sending, to the second entity, a response message to the request message, the third entity including third information regarding suspension of the issuing rights of the domain RO.

Preferably, the second entity receives a message requesting issuance of the domain RO from the terminal;

And the second entity sends a response message to the terminal in response to the issuance request of the domain RO.

Preferably, the second entity updates the issuing authority of the domain RO using the third information.

Preferably, the first information includes a resID parameter indicating an ID of the first entity, a reqURL parameter indicating an address of the first entity, a domID indicating an ID of the corresponding user domain in which the issuing authority of the domain RO is suspended, And a parameter.

Preferably, the second information includes at least one of a reqID parameter indicating an ID of the second entity, a resID parameter indicating an ID of the first entity, user domain information regarding issuing authority suspension of the domain RO, and an <unauthorized> element And &lt; RTI ID = 0.0 &gt; reqInfo &lt; / RTI &gt;

Preferably, the third information includes at least one of a reqID parameter indicating an ID of the second entity, a resID parameter indicating an ID of the first entity, user domain information related to suspension of issuing rights of the domain RO, And a resInfo parameter including a user domain token indicating information on the presence or absence of the authority.

Preferably, the step (B)

Confirming that the second entity is authorized to issue the domain RO to the domain;

If the second entity is not authorized to issue the domain RO, informing the first entity of the second information through the < unauthorized > element that there is no authority to issue a domain RO to the domain in the request message And a control unit.

Advantageously, the step (B) comprises: confirming whether the second entity is authorized to issue the domain RO to the domain; If the second entity is authorized to issue the domain RO, the second entity deletes information about the domain; And sending the request message including the second information to the first entity using an address indicated by the reqURL parameter included in the trigger message.

Preferably, the third information is a Status element set to 'Success' or 'Fail'.

Preferably, the second entity checks the value of the Status element included in the drop domain response message;

If the value of the Status element is 'Success', the second entity is a user including at least one of User Domain Info, Key Material, and User Domain Tokens, And deleting the domain context (User Domain Context).

Preferably, in the step (C), the first entity successfully receives the Drop Domain Request message, or after the first entity receives the drop domain request message, the second entity When the status information of the user domain RO creation and issuance function of the user domain RO is successfully confirmed or updated,

The first entity may include a 'Status' element set to 'Success' in the response message.

Preferably, in the step (C), the first entity fails to receive the drop domain request message, or the state information on the function of generating and issuing a user domain RO of the second entity is confirmed or updated If it fails,

The first entity may include a 'Status' element set to 'fail' in the response message.

According to another aspect of the present invention, there is provided a rights management method in a digital rights management system,

The first entity sending a drop domain request message to the second entity, the drop domain request message including information about an issuing rights of the domain RO;

Receiving, by the first entity, a response message from the second entity, the response message including a Status element related to an issuing authority of the domain RO;

The first entity checks the value of the Status element and verifies whether the issuing authority of the domain RO is updated according to the value of the Status element.

Preferably, the first entity sends a trigger message for performing a protocol to suspend the issuing authority of the domain RO

And receiving from the second entity.

According to another aspect of the present invention, there is provided an apparatus for managing rights in digital rights management,

An apparatus for granting an issuing authority of a domain RO to a DRM entity for a specific domain,

And a module for performing a protocol for suspending the issuing authority of the domain RO,

The module sending a trigger message to the entity requesting initiation of the protocol; Receiving a message from the entity requesting suspension of the issuing authority of the domain RO; Searching whether the entity information includes information indicating whether or not the entity RO has an issuance authority in the received request message; And sends a response message including information instructing the entity to update the issuing authority of the domain RO according to the retrieved result.

The present invention can suspend the creation and issuance rights of the domain RO for a specific domain in the digital rights management by performing the RDP Drop domain protocol between the newly defined RI and the DA / DEA. Therefore, the present invention can efficiently manage the creation and issuing rights of the domain RO for the user domain in the digital rights management.

And is applied to the digital rights management (DRM) system of the present invention. However, the present invention is not limited thereto, and can be applied to all communication systems and methods to which the technical idea of the present invention can be applied.

The basic concept of the present invention is to newly define the RDP Drop Domain protocol between the DA / DEA and the RI in the DRM system, to stop the authority to generate and issue the RO of the RI to the specific user domain, .

Hereinafter, technical terms used in the present invention will be described. The technical terms described below are only for the explanation of the present invention, and do not limit the technical meaning of the terms.

A terminal (or device) according to the present invention refers to any device capable of carrying out the technical features of the present invention. That is, the terminal according to the present invention performs a function of setting up a network and an IP tunnel, and is capable of transmitting / receiving data to / from a network node through the set IP tunnel (for example, a UE (User Equipment) Mobile phones, mobile phones, DMB phones, game phones, camera phones, smart phones, etc.) and other notebooks, desktop computers, personal digital assistants (PDAs), and white goods.

The DRM agent according to the present invention may be configured as a module of a terminal as a module (for example, a device composed of software and hardware) that performs functions related to digital content management. In the description of the present invention, the DRM agent and the terminal are described in a mixed manner.

A User Domain Token is a so-called Validation Token (V-Token) that allows a DA / DEA to assign certain roles (for example, RI, LRM, etc.) (Such as issuing a license to devices) to perform certain tasks (such as authorization) or authorization information (User Domain Token is used by the DA / DEA to authorize certain tasks to perform certain tasks in relation to the User Domain. A User Domain Token consists of the identity of the entity, the authorized roles of the entity, the expire date and the digital signature. The user domain token additionally includes information of the ID of the entity (i.e., identification information of the entity), authorized roles of the entity, and expiration date.

The key material is the key information necessary to generate the user domain RO, for example, DDK or DDK-set.

DDK (Diversified Domain Key) is a value obtained by hashing MDK (Master Domain Key) shared by DA / DEA and device (or DRM agent). RI receiving DDK can not derive MDK.

In the DDK-set, when the user domain upgrade is performed, both the MDK and the DDK for the user domain are changed. In this case, devices that are members of the user domain can only issue the most recent generation MDK if the hash chain is supported, and derive the previous MDK through the hash chain. On the other hand, because the hash chain is not applied to the DDK, it must forward all the DDKs of the previous domain generation. When domain RO of various domain generation is created, DDK-set is transmitted.

A signature provides a digital signature for the entire message, integrity and authenticity of the message.

In the RDP Drop Domain Protocol, the RDP Trigger {Drop Domain} message is a trigger message of the RDP Drop Domain Protocol. The Drop Domain Request message is a request message for returning or aborting the creation and issuing rights of the RO, which is sent from the RI to the DA / DEA (the DropDomainRequest message is sent from a RI to a DA / DEA). In addition, the Drop Domain Request message is the first message of the 2-pass RDP Drop Domain Protocol and is a message requesting that the RI no longer generates an RO (i.e., a RO for the user domain) -pass DropDomain protocol for disabling a certain RI to create Ro's for the User Domain).

The Drop Domain Response message is a response message to the Drop Domain Request message, and includes information on the creation and issuing rights of the RO.

Hereinafter, embodiments according to the present invention will be described in detail with reference to the accompanying drawings.

4 and 5 are signal flow diagrams illustrating the RDP Drop domain protocol. However, FIG. 4 illustrates a case where the RI 200 normally has rights to create and issue a user domain RO, according to a first embodiment of the present invention. 5 is a diagram illustrating a second embodiment of the present invention. In the case where the RI 200 does not normally have the authority to create and issue a user domain RO (for example, Unless you have permission to create it).

Hereinafter, an embodiment of the present invention will be described with reference to FIG.

The DA / DEA 300 desires to deprive the RI 200 of the right to create the RO of the user domain it manages. At this time, the DA / DEA 300 transmits a trigger message, that is, an RDP Trigger {Drop Domain} to the RI 200 to request the RI 200 to return the generation right of the user domain RO (S41). The trigger message (RDP Trigger {Drop Domain}) includes information (parameter, element, or attribute) for performing RDP Drop Domain Protocol: type, version, proxy, resID, resAlias, reqURL, nonce , domID, domAlias, RI-ID, signature, and encKey. Among these information, the important information is as follows: 'resID' is a parameter indicating the ID of DA / DEA (when DA / DEA is one entity) or DEA ID (when DA / DEA is separated) Element or attribute); 'ReqURL' is a parameter (element or attribute) that points to the DA / DEA URL (if DA / DEA is an entity) or DEA URL (if DA / DEA is separate); 'DomID' includes information on the user domain ID managed by the DEA and information for notifying the user domain RO to return the authority to generate and issue the user domain RO.

After the RI 200 receives the RDP Trigger {Drop Domain}, the RI 200 verifies its own user domain RO creation and issuance rights. 4 and FIG. 5) to the DEA 300 (S42-1 in FIG. 4 and S42-2 in FIG. 5). Here, it is a case that the RI 200 normally has authority to create and issue a user domain RO.

Accordingly, after the RI 200 deletes the information (domain information and key material) of the corresponding user domain, the RI 200 deletes the reqURL (i.e., information indicating the address of the DA / DEA) included in the RDP Trigger {Drop Domain} And transmits a drop domain request message (Drop Domain Request) to the address indicated (S42-1). The drop domain request message includes the ID information of the user domain required for the RI 200 to expire the creation and issuance rights of the RO: reqID, resID, nonce, time, certificateChain, reqInfo, signature. 'ReqID' is a parameter (element or attribute) indicating the ID of the RI to which the creation and issuance authority of the domain RO is to be returned, 'resID' is the ID of the DA / DEA DEA is a parameter (element or attribute) indicating a DEA ID (when the DA / DEA is separated), and 'reqInfo' is a parameter indicating that the DA / DEA is a parameter (Element or attribute) that contains the information of the user domain. That is, the reqInfo parameter basically includes the user domain ID (which is a sub-element of reqInfo), and may additionally include a user domain alias.

The DA / DEA 300 sends a Drop Domain Response message to the RI 200 after receiving the Drop Domain Request message (S43-1 in FIG. 4 and S43- 2). The drop domain response message includes information (parameter, element, or attribute) for performing the RDP Drop domain protocol: status, reqID, resID, nonce, resInfo, signature. Among the above information, important information will be described as follows: 'reqID' element (parameter) is information indicating the ID of the RI to return the authority to create and issue domain RO; The 'resID' element is information indicating the ID of the DA / DEA (if the DA / DEA is an entity) or the DEA ID (if the DA / DEA is separated); The 'resInfo' element includes user domain information and a user domain token. Here, the user domain information includes' user domain ID ',' expiration time of a domain context 'and' (User Domain alias) '.

After receiving the Drop Domain Request message, the DA / DEA 300 checks whether or not the < unauthorized > element is included as a sub-element in the <reqInfo> element of the message. If the < unauthorized > element is not included as a subelement in the < reqInfo > element, the RI 200 deletes the authority to create and issue the user domain RO owned by the DA / DEA 300 for the corresponding user domain . Accordingly, the DA / DEA 300 updates the current state information on the creation and issuance rights of the corresponding user domain RO. For example, update from an 'RO issuable' state (aka 'Enable' state) to an 'RO issuable' state (aka, Disable state).

The DA / DEA 300 transmits information to the RI 200 through the user domain token (i.e., V-Token) to expire the creation right of the user domain RO through a drop domain response message, The requesting unit 200 requests the RO to update the authority regarding the RO (S43-1). In step S43-1, the drop domain response message is characterized in that the RI 200 includes the user domain token and the domain ID.

In addition, the DA / DEA 300 may receive the drop domain request message (Drop Domain Request), or after receiving the drop domain request message, the state of the user domain RO creation and issuance function of the RI 200 (Or parameters) set to 'Success' in the Drop Domain Response message when the information is successfully confirmed or updated. If the DA / DEA 300 fails to receive the drop domain request message or fails to confirm or update the status information on the user domain RO creation and issuance function of the RI 200, the DA / DEA 300 transmits a drop domain response message (Or parameter) set to 'fail' in the Drop Domain Response.

The RI 200 receives the drop domain response message and confirms the value of the 'Status' element included in the drop domain response message (Success or fail). If the value of the 'Status' element is 'Success', the RI 200 includes 'User Domain Info', 'Key material', and 'User Domain Tokens' , The RI 200 can not issue the RO of the user domain. In this case, the RI 200 can not issue the RO of the user domain. As described above, the RI 200 receives the drop domain response message and deletes (updates) its own rights on the RO based on the received information (for example, the Status element) in the message (S44) .

After the RDP Drop domain protocol is performed as in the above steps S41 to S44,

The terminal 100, which is a member of the user domain, requests the RO creation and issuance to the RI 200 returning the creation and issuance rights of the user domain RO (RO Request message in FIG. 4) (S45) . The RI 200 informs the RO creation and issuance through RO Response message (S46). At this time, the value of the 'status' element included in the RO Response message is set to 'fail'.

The second embodiment of Fig. 5 will be described below. However, the description of the parts overlapping with those of the first embodiment of FIG. 4 will be omitted, and only the differences from the embodiment of FIG. 4, namely, S42-2 and S43-2 will be described. Therefore, the same reference numerals in Figs. 5 and 4 denote the same operations and functions. 5, if the RI 200 does not normally have the creation and issuance rights of the user domain RO (for example, it has already returned the generation right of the user domain RO or the generation right of the user domain RO ).

That is, if the RI 200 has already returned the generation right of the user domain RO or expires the generation right of the user domain RO (for example, the use time or the expiration of the use condition) in the trigger message of the step S41, There may be cases where you do not have it anymore because of reasons such as. In this case, if the DA / DEA 300 sends the RDP Trigger {Drop Domain} to the RI 200, the RI 200 informs the user that the RDP 200 has already returned or expired the creation authority of the user domain RO, (Ie, Drop Domain Request). That is, the RI 200 transmits a Drop Domain Request message (Drop Domain Request) to the address indicated by the reqURL (that is, the information indicating the address of the DA / DEA) included in the RDP Trigger {Drop Domain} 2). The drop domain request message includes the ID information of the user domain required for the RI 200 to expire the creation and issuance rights of the RO: reqID, resID, nonce, time, certificateChain, reqInfo, signature. The function of these parameters is already described above. However, the <reqInfo> element (or parameter) includes a user domain ID and an <unauthorized> element as sub-elements. The <unauthorized> element is passed through the "unauthorized" extension of the <reqInfo> element. In addition, the &lt; unauthorized &gt; element indicates that the DA / DEA 300 transmits an RDP Trigger (RDP) message to the RI 200 in a state where the RI 200 has already been authorized to generate and issue the user domain RO, In case of sending {Drop Domain}, the RI 200 transmits to the DA / DEA 300 that it is not authorized to create and issue a user domain RO, and does not have the right to create and issue an RO for the corresponding domain .

Hereinafter, the process (S43-2) will be described.

When the DA / DEA 300 confirms that the <unauthorized> sub-element is included in the received <reqInfo> element in the Drop Domain Request message, the DA / And confirms or updates the RI 200 without authorization to create and issue the corresponding user domain RO. Optionally, the DA / DEA 300 includes a user domain token, which is updated with information indicating that the RI's RO creation and issuance rights have expired, into a &lt; resInfo &gt; element, Response to the RI 200 (S43-2).

As another embodiment, the DA / DEA 300 may generate and issue a user domain RO of the RI 200 after successfully receiving the drop domain request message or after receiving the drop domain request message Status' element (or parameter) set to 'Success' in the drop domain response message when the status information of the function is successfully confirmed or updated. However, if the DA / DEA 300 fails to receive the drop domain request message or if the confirmation or update of the status information for the user domain RO creation and issuance function of the RI 200 fails, the DA / The 'Status' element (or parameter) set to 'fail' in the response message (Drop Domain Response).

6 is a block diagram illustrating the RDP Drop Domain protocol. 6 schematically illustrates the signaling of the RDP Drop domain protocol of FIGS. 4 and 5. FIG. In FIG. 6, DA and DEA are shown as independent entities, but DA and DEA may be separate entities or combined entities. The operation of the signaling corresponding to each reference numeral in Fig. 6 is the same as the operation of the corresponding signaling in Fig. 4 and Fig.

The configuration and function of the DA / DEA according to the present invention will be described below.

The DA / DEA according to the present invention includes a module for performing the operations and functions described with reference to FIGS. Such modules are implemented through software or hardware including the software. In addition, the module is not limited to the name, and may be referred to as a control unit or a processing unit as a configuration unit that performs the operations and functions described with reference to Figs.

The module configured in the DA / DEA according to the present invention performs the newly defined RDP Drop Domain protocol. That is, the module sends a trigger message (RDP trigger {Drop Domain}) requesting initiation of the protocol to a specific entity (for example, the RI that is authorized to issue the domain RO); Receiving a Drop Domain Request message requesting suspension of the issuing authority of the domain RO from the entity (RI); (Analyzes) whether or not the received request message includes information indicating whether or not the entity is authorized to issue the domain RO (i.e., an < unauthorized > element in the reqInfo parameter); (I.e., a user domain token) instructing the entity (RI) to update the issuing authority of the domain RO (i.e., suspend the issuing authority) according to the retrieved result.

In addition to the module, the DA / DEA includes all communication components required to perform the RI and RDP Drop domain protocols: a transceiver, an output (e.g., a display, a speaker, etc.) And an input unit. These components are obvious to those skilled in the art, and a detailed description thereof will be omitted.

The configuration and function of the RI according to the present invention will be described below. The RI may be a device corresponding to a server in the network.

The RI according to the present invention includes a module that performs the operations and functions described with reference to Figs. Such modules are implemented through software or hardware including the software. In addition, the module is not limited to the name, and may be referred to as a control unit or a processing unit as a configuration unit that performs the operations and functions described with reference to Figs.

The module configured in the RI according to the present invention performs the newly defined RDP Drop Domain protocol. That is, the module receives a trigger message (RDP trigger {Drop Domain}) requesting the specific entity (for example, DEA / DA) to start the protocol; Sending a drop domain request message (DEA / DA) including information indicating the existence of an issuing authority of the domain RO; A response message to the request is received from the entity DEA / DA, and whether or not the response message contains information indicating whether or not the issuing authority of the domain RO exists (i.e., the Status element in the reqInfo parameter) Analysis); And updates the issuing authority of the domain RO (for example, suspends the issue of the issuing authority) in accordance with the retrieved result.

The module (or processing unit) of the RI receives the Drop Domain Response message and confirms the value of the 'Status' element included in the drop domain response message (Success or fail). At this time, if the value of the 'Status' element is 'Success', the module of the RI may include 'User Domain Info', 'Key material', 'User Domain Tokens' And deletes the User Domain Context including at least one of the User Domain Contexts.

In addition to the module, the RI includes all communication components required to perform the DEA / DA and RDP Drop domain protocols: a transceiver, an output (e.g., a display, a speaker, etc.) An input unit, and the like. These components are obvious to those skilled in the art, and a detailed description thereof will be omitted.

The method according to the present invention described so far can be implemented in software, hardware, or a combination thereof. For example, a method in accordance with the present invention may be stored in a storage medium (e.g., mobile terminal internal memory, flash memory, hard disk, etc.) &Lt; / RTI &gt; in a software program that can be executed by a computer.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. I will understand. Accordingly, the true scope of the present invention should be determined by the technical idea of the appended claims.

1 is a block diagram showing a digital rights management system.

2 is a diagram of a user domain system in DRM.

3 is a block diagram illustrating a process in which a RI creates a domain RO in a user domain.

4 is a signal flow diagram illustrating an RDP Drop domain protocol as a first embodiment of the present invention.

5 is a signal flow diagram illustrating an RDP Drop domain protocol as a second embodiment of the present invention.

6 is a block diagram illustrating the RDP Drop Domain protocol.

Claims (33)

delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete A method for managing authorization of digital rights, the method being performed by a first server, The first server sends a drop domain authorization trigger message for initiating a protocol for stopping the generation of the domain RO for the domain having the authority to issue the rights object (RO) Receiving from a server, the drop domain authorization trigger message including information about the domain, and the information about the domain being an identity (ID) of the domain; Wherein the domain is managed by the second server and the authority is obtained by the first server from the second server, Checking the status of the authority; A drop domain permission request (ID) including a domain ID, a parameter indicating a ID of the first server, a reqID indicating a ID of the second server, authorization request message to a second server; And Receiving a drop domain authorization response message including a status element indicating a result of processing for the drop domain authorization request message from the second server, The drop domain permission request message includes a not-authorized element indicating that the first server does not have the right for the domain if the right is already checked to be dropped. A method for managing rights of digital copyright. 23. The method of claim 22, Further comprising: checking the value of the status element included in the drop domain rights response message. The method of claim 22, wherein if the value of the status element indicates success, the second server has successfully received the drop domain authorization request message or the second server receives the drop domain authorization request message And subsequently indicating that the state information on the function for creating and issuing the domain RO of the second server has been successfully checked or updated. &Lt; Desc / Clms Page number 19 &gt; The method of claim 22, wherein if the value of the status element indicates failure, the second server fails to receive the drop domain authorization request message or the second server receives the drop domain authorization request message And subsequently indicating that it has failed to check or update the status information on the function for creating and issuing the domain RO of the second server. &Lt; Desc / Clms Page number 19 &gt; 23. The method of claim 22, wherein the first server is a rights issuer (RI), and the second server is a DA / DEA (Domain Authority / Domain Enforce Agent). Lt; / RTI &gt; 23. The method of claim 22, Wherein the privilege is already disabled due to a previous drop domain privilege trigger message or expiration of the privilege period. 24. The method of claim 23, further comprising deleting a domain context for the domain if the value of the status element indicates success. 24. The method of claim 23, further comprising enabling the rights if the value of the status element indicates failure. 23. The method of claim 22, Receiving an RO request message from a terminal; Checking whether the privilege is already disabled; And And sending a response message, Wherein the response message includes a value indicating failure if the privilege is disabled, Wherein the response message includes an RO if the rights are not disabled. &Lt; RTI ID = 0.0 &gt; 11. &lt; / RTI &gt; 23. The method of claim 22, wherein the drop domain rights trigger message comprises: A parameter (resID) indicating an ID of the second server, and a parameter (reqURL) indicating an address of the second server. Way. 23. The method of claim 22, wherein the drop domain rights response message comprises: A parameter (reqID) indicating the ID of the first server, A parameter (resID) indicating the ID of the second server, and And a parameter (resInfo) including information on the domain. &Lt; Desc / Clms Page number 20 &gt; An apparatus configured to manage authorization of digital rights, the apparatus comprising: The apparatus includes a processor, wherein the processor The apparatus receives a drop domain authorization trigger message for starting the protocol for stopping the generation of the domain RO for the domain having the authority to issue the rights object (RO) Wherein the drop domain permission trigger message includes information about the domain and the information about the domain is an identity of the domain; The domain being managed by the server and the rights being obtained by the device from the server, Checking the status of the authority; A drop domain authorization request including a signature (ID) of the domain, a parameter (reqID) indicating an ID of the device, a parameter indicating a ID of the server (resID), and a signature, Sending a message to the server; A drop domain authorization response message including a status element indicating a result of processing for the drop domain authorization request message from the server, Wherein the drop domain permission request message includes a not-authorized element indicating that the device does not have the right for the domain if the right is already checked to be dropped. , A device configured to manage the rights of digital copyright.

Images