METHOD TO REGISTER ISSUING OF RIGHTS AND AUTHORITY OF
DOMAINS IN ADMINISTRATION OF DIGITAL RIGHTS AND METHOD
TO IMPLEMENT FUNCTIONS OF EXCHANGE OF SAFE CONTENT
USING THE SAME DESCRIPTION OF THE INVENTION The present invention relates to Digital Rights Management, and more specifically to a method for registering a Domain Authority and a Rights Issuer in Digital Rights Management and a method for implementing Secure Content Exchange functions. using the same. With the increase of devices capable of distributing multimedia content to a user, a user can possess, operate or maintain control or responsibility over various devices, such as a centralized domestic media entertainment system connected in a network and portable devices with various degrees of network connectivity. Portable devices may include a mobile phone and a portable music player. Network connectivity may include, for example, wireless connectivity through a mobile telephone or a wired broadband Internet connection through a personal computer. The user can buy and download content, such as multimedia content, or programs for operation on a device over the network connection.
However, the user may also wish to operate the content or programs on other devices owned by the user. Therefore, in accordance with the Secure Content Exchange Requirements (SCE) of Digital Rights Management (DRM) of the Open Mobile Alliance (OMA) (after this, referred to as "OMA SCE Requirements"), suggested by the OMA Mobile application software standardization organization, which is incorporated herein by reference, and which established the concept of a "user domain", the user can establish a user domain. A user domain may include other devices owned, operated, controlled or under the responsibility of the user. The user can add devices to the user's domain, and can use a device in the user's domain to obtain content that can be used in the user's domain. In addition, the user can share content between devices in the user domain through network connectivity or through appropriate storage memory to transfer content between devices, such as a Secure Removable Media (SRM). Alternatively, such as where content is propagated over a network connection, the user may share authorization to propagate the content with other devices in the user's domain. This can be achieved by sharing, for example, user tabs associated with the
authorization . In this way, the user domain refers to the group of users that can share the DRM content. A device can include any device that can share DRM content within the user domain. The administration of user domains can include administration tasks such as adding devices to and removing devices from the user domain and the application of the domain policy. In this way, a content provider can allow the replication and use of content between devices in the user's user domain. In addition, the content provider may limit and / or prohibit the distribution and use of such content to devices outside the user's domain. A user domain can be created by a user through the operation of a device in the user domain with network connectivity. For example, a user can create a user domain by operating a device to observe a list of possible domain policies. Several domain policies can be developed, and one of them can be selected by a user as the most appropriate for that user. An SCE enabler can support only a simple domain policy for a user domain. Domain policies for user domains, issued by a Domain Authority (DA), can
include such restrictions as the maximum number of devices in the user's domain, temporary restrictions on the use of content, or frequency of content use. The DA can provide the selected domain policy and a Domain Key (DK) to a Domain Execution Agent (DEA) stored on the user device. The device can create and manage the user's user domain through the DEA. The user can then add other devices to the user domain. For example, a user can connect a mobile phone, portable music player, and a Home Media Center to the device and add these devices to the user's domain. The domain policy issued by the DEA can limit the number of devices that can be added to the user's domain, and the DEA can prevent the number of devices added to the user's domain from exceeding this limit. When a user acquires content with a User Domain Rights Object (RO), the user may wish to share the content with the devices in the user's domain or with devices outside the user's domain. The user can then connect the connected device to other devices in the user domain to transfer copies of the content and its corresponding RO to
other devices in the user domain. An SCE enabler can enable a rights issuer (RI), which can exchange a Content Encryption Key (CEK) with a content issuer, to specify usage permissions for the consumption of rights over and transfer rights between devices that are in the user's domain. Use permissions can include permissions to reproduce, copy and / or move content between devices in the user's domain. An SCE enabler can also allow an RI to specify usage permissions for rights between devices outside the user domain. Use permissions can include permissions to copy and move content to devices outside the user's domain. Alternatively, usage permissions may prohibit devices in the user domain from copying or moving content to devices outside the user's domain. The SCE enabler can allow the AED to execute the domain policy and perform the user domain administration according to the domain policy specified by the DA. Managing user domains can include administration tasks such as adding and removing devices from the user domain, and applying the domain policy. In this way, the SMA Requirements of OMA
introduced the concept of "user domain" in such a way that a user can directly administer user domains instead of administering user domains through an RI. Therefore, the OMA SCE Requirements also introduced the concept of DA and DEA in such a way that it defines and describes a domain policy that can be performed by the DA and the execution of the domain policy can be done by the DA. The DA and the DEA can be separate entities or can be integrated into a single entity. A DA can define and describe the domain policy and can distribute such domain policy to the DEA. The DEA can receive the domain policy of the DA, and can define and manage the user domain based on the domain policy received. That is, the user domain generated by the DEA is also handled by the DEA. If the DA and the DEA are integrated as a single entity, the DA can define the user domain and can perform the administration of domains without interconnecting with a separate DEA. FIGURE 1 shows a schematic diagram of the SMA Requirements of OMA. Unlike the traditional OMA V2.0 DRM standard (after this referred to as "OMA V2.0 DRM"), which is also incorporated for reference and that
precedes the OMA SCE Requirements, OMA SCE Requirements include: (1) Import Function by a Local Rights Administrator (LRM); (2) User Domain function by the DA and the
DEA; and (3) move function to move RO from one device to another. After this, the Import function and the User Domain function will be described in more detail. The OMA SCE Requirements provide an Import function that can be performed by LRM. The Import function refers to converting non-OMA DRM data into OMA DRM data. For example, an OMA DRM-compatible device may attempt to play data without OMA DRM. In this case, the OMA-DRM-free data must be converted or imported into the OMA DRM data by an LRM in accordance with the OMA SCE Requirements. In this way, the LRM imports the DRM-free data from OMA into the DRM Content Format (DCF) and imports an RO for the DRM from OMA, in which it is called "Imported DCF" and "RO Imported", respectively. Imported DCF and Imported RO, which support OMA DRM, can be used by the DRM agent on a device
compatible with OMA DRM according to the OMA SCE Requirements. As described in the above, the user domain allows a user to perform the administration of user domains for a number of devices included in the user's domain instead of performing the administration of user domains for each device through a user's domain. rights issuer (RI), as established in the traditional OMA V2.0 DRM standard. Other characteristics of the traditional standard of
OMA V2.0 DRM, however, are compatible with the OMA SCE Requirements. For example, OMA V2.0 DRM includes 4-step registration protocol. FIGURE 2 illustrates a 4-step registration protocol used by the device and a Rights Issuer (RI) in accordance with OMA V2.0 DRM. OMA V2.0 DRM uses the 4-step registration protocol so that a device registers with an RI to acquire an RO. The 4-step registration protocol is used for the device and the IR to exchange information between them and register with each other. If the protocol is successful, the device may have the RI context, which contains RI information, and the RI may possess device information. According to the 4-step registration protocol,
the device first transfers a Device Greeting message that includes device information to the RI. The Device Greeting message may contain protocol version, device ID, and encryption algorithms supported for the device. The IR transfers an IR Greeting message that includes RI information to the device in the second phase. The RI Greeting message contains the result of transfer, session ID, protocol version, RI ID, supported algorithm, and other verification and server information. The device then transfers a RegistrationRequest message to the RI to register the device with the RI in the third phase. The RegistrationRequest message contains verification data, such as session ID, message transfer time, certificate and signature, and present time. The IR finally transfers a message from RegistrationResponse to the device in the fourth phase. This RegistrationResponse message contains verification data, such as the result of device registration, session ID, RI certificate / digital signature, and Online Certificate Status Protocol (OCSP) Response, which can be sent from RI in response to the OCSP request message that can be sent from the RI to a
OCSP answering machine with certain contingencies that will not be described in additional detail. However, the OMA SCE Requirements do not include a method to register a DA and an RI or the implementation of SCE using the registration method. This invention provides a method for registering a DA and an RI. The present invention also provides a method for supporting SCE functions using a method for registering a DA and an RI. Additional features of the invention will be set forth in the description that follows, and in part will be apparent from the description, or may be learned by the practice of the invention. The present invention describes a method for registering a Domain Authority (DA) and a Rights Issuer (RI) for Digital Rights Management, which includes exchanging information between the DA and the RI. The present invention also discloses a method for implementing Secure Content Exchange (SCE) functions for Digital Rights Management (DRM), which includes registering a DRM agent with a Domain Authority (DA) to join a user domain, register the DRM agent with a Rights issuer (RI), exchange information between the DA and the IR to register the DA and the IR,
register a Rights Object (RO) for the user domain from the RI, exchange information between the RI and the DA to acquire information about the user domain, and transfer the RO for the user domain to the DRM agent. The present invention also describes a method for implementing Secure Content Exchange (SCE) functions for Digital Rights Management (DRM), which includes exchanging information between a Domain Authority (DA) and a Rights Issuer (RI) to register the DA and the RI, register an SCE RM Agent with the DA to join a user domain, acquire a Rights Object (RO) for the user domain from the RI, transfer the RO for the user domain and a DRM content format (DCF) to a DRM 2.0 agent, and register the DRM 2.0 agent to the DA through the RI. The present invention also describes a method for implementing Secure Content Exchange (SCE) functions for Digital Rights Management (DRM), which includes registering a Local Rights Manager (LRM) with a Domain Authority (DA) to join a user domain, create an Imported Rights Object (RO) for the user domain, exchange information between the DA and a Rights Issuer (RI) to register the DA and the RI, transfer the RO for the user domain and a Format
DRM content (DCF) to a DRM 2.0 agent and register the 2.0 DRM agent to the DA through the RI. It will be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide additional explanation of the invention as claimed. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated into and constitute a part of this specification, illustrate exemplary embodiments of the invention, and together with the description serve to explain the aspects of the invention. FIGURE 1 shows a schematic diagram of the SMA Requirements of OMA. FIGURE 2 illustrates a 4-step registration protocol used by a device and Rights Issuer (RI) in accordance with OMA V2.0 DRM. FIGURE 3 illustrates a method for registering a domain authority and a rights issuer according to a first exemplary embodiment of the present invention. FIGURE 4 illustrates a method for acquiring a rights object for the user domain by an SCE DRM agent using the registration method according to the first exemplary embodiment of the present invention.
FIGURE 5 illustrates a method for using a rights object for user domain by a DRM 2.0 agent using the registration method according to a second exemplary embodiment of the present invention. FIGURE 6 illustrates a method for using a user domain rights object imported by a DRM 2.0 agent using the registration method according to a third exemplary embodiment of the present invention. The invention is described more fully thereafter with reference to the accompanying drawings, in which exemplary embodiments of the invention are shown. This invention, however, may be represented in many different forms and should not be construed as limited to the exemplary embodiments set forth herein. In fact, these exemplary embodiments are provided in such a way that this description is complete, and will bring the scope of the invention fully to those skilled in the art. In the drawings, the size and relative sizes of the layers and regions can be exaggerated for clarity. Similar reference numbers in the drawings denote similar elements. In order to effectively support multiple functions in accordance with the OMA SCE Requirements, the RI 40 must receive information about a Domain Authority 20 (DA), and information about the RI 40 must be received by
DA 20. However, no mechanism is defined in the SMA Requirements of AOM to establish the exchange of information between DA 20 and RI 40. A registration function between DA and RI may allow DA and RI to exchange information to implement protocols or functions between them. Additionally, the registration function must precede any other protocol or function between DA and RI. In addition, the registration function should allow the DA information to be notified in advance to the RI, so that the registration function can be used even if the RI can not access the DA. Accordingly, the present exemplary embodiment describes a registration mechanism between the DA 20 and the RI 40 (after which also referred to as 'DA-RI') which can be incorporated into (1) the way in which a DRM agent acquires an RO for the user domain, (2) the way in which a DRM 2.0 agent uses the user domain RO, and (3) the way in which the DRM 2.0 agent uses an imported RO for the user domain. FIGURE 3 illustrates a method for recording a DA and an RI according to a first exemplary embodiment of the present invention. In the first phase, the RI 40 transfers to the DA 20 an activation message of the Acquisition Protocol of
Rights Object (ROAP), which can be referred to as a RegistrationRequest message, to activate the registration of the DA 20 with the RI 40 in operation S100. However, the ROAP activation message is not necessarily required for the registration of the DA 20. Even if the ROAP activation message is not sent, the DA 20 may transfer a DA Greeting message to the RI 40 to initiate the registration procedure. In the second phase, the DA 20 transfers the Da Greeting message to the RI 40 to provide the DA 20 with the basic information in the operation S102. The DA Greeting message may contain protocol version, DA ID, supported encryption algorithms. If the DA 20 does not receive the ROAP activation message from the RI 40, the DA-RI registration procedure is initiated when transferring the DA Greeting message to the RI 40. In the third phase, the RI 40 transfers a message from greeting from RI to DA 20 in operation S104. The RI Greeting message contains the result of transfer of the Da greeting message, session ID, protocol version, RI ID, supported algorithm, and other verification and server information. In the fourth phase, the DA 20 transfers a RegistrationRequest message to the RI 40 in such a way that the DA 20 can be registered in the RI 40 in operation S108. The message
of RegistrationRequest contains verification data, such as session ID, message transfer time, certificate / digital signature, and present time. The RegistrationRequest message can be implemented similarly to the DRM RegistrationRequest message from O TO V2.0, as described above. In the fifth phase, the RI 40 transfers to the DA 20 the RegistrationResponse message containing the registration result and the information to register the RI 40 with the DA 20 in operation S110. The RegistrationResponse message contains verification information, such as DA registration result, session ID, Rl certificate / digital signature, and OCSP Response. The RegistrationResponse message can be implemented similarly to the OMA V2.0 DRM RegistrationResponse message, as described above. After completing the DA-RI registration procedure, the DA 20 has the RI context that has the RI information, and the RI 40 records the DA information therein. The DA-RI registration procedure can be performed only once, at the time of the first DA-RI information exchange. However, if the validity term for the RI context has expired, the DA 20 may resume or repeat the registration procedure. In another exemplary embodiment, the RI 40 may first
request the registration of the DA 20. In other words, the RI 40 can first request the registration of the DA 20 when transferring the Greeting message from RI to the DA 20. Then, the DA 20 can respond to the RI 40 when transferring the DA Greeting message to the RI 40. Then, the RI 40 transfers to the DA 20 the RegistrationRequest message for the registration, and the DA 20 transfers the RegistrationResponse message to the RI 40. In this case, the details of the messages must be modified to suit their corresponding context. The messages can be substantially similar in both exemplary embodiments described in the foregoing. Although the DA and RI respectively exist in private and public networks, the DA-RI registration mechanism can initially be executed to allow the RI to access the DA. Any other DA-RI protocol / function can be supported by the aforementioned DA-RI registration function. Accordingly, the DA-RI registration function can be performed before any other DA-RI protocol / function. FIGURE 4, FIGURE 5, and FIGURE 6 illustrate methods for implementing SCE functions using the aforementioned DA-RI registration method. FIGURE 4 illustrates a method for acquiring a rights object for the user domain by an agent
SCE DRM using the registration method according to a first exemplary embodiment of the present invention. The present exemplary embodiment describes a method for acquiring the RO for user domain of the RI 40 by an SCE DRM agent 50. That is, the present exemplary embodiment describes how the DA-RI registration method is performed and in which the phase the DA-RI registration method is executed. The present exemplary embodiment assumes that the user domain is handled by the DA 20 and the DEA 30, which are combined with each other. If the DA 20 and the DEA 30 are separated from each other, the user domain is handled by the DEA 30. In the first phase, the SCE DRM agent 50 is registered by the DA 20 to join the user domain in the S200 operation. This phase can be implemented similarly to the procedure for registering DRM agent with the domain according to DRM of OMA V2.0, which may require multiple procedures for message transfer and data exchange. Once this phase is successfully completed, the SCE DRM agent 50 is a member of the user domain and can use the user domain RO. In the second phase, the SCE agent 50 DRM is registered with the RI 40 in the S202 operation by a mechanism similar to the 4-step registration protocol of the DRM RI 40 of OMA V2.0. This phase includes a verification
mutual / exchange of keys, and mutual exchange / confirmation of multiple parameters for post-registration communications. The registration procedure can be performed once when the DRM agent first tries to acquire the RO of the RI 40. However, if the DRM agent 50 is no longer allowed to access the RI 40 due to the expiration of the validity term, it is phase can be done again. In the third phase, the DA 20 is registered with the RI 40 through the DA-RI registration mechanism in the S204 operation. This phase is previously performed since the RI 40 inquires into the domain information of the user of the DA 20 to issue the user domain RO to the SCE DRM agent 50 in the sixth phase. In this way, the third phase can be carried out at any time before the sixth phase. In the fourth phase, the RI 40 transfers to the SCE DRM agent 50 a ROAP trigger message for a RORequest message in the S206 operation. The SCE DRM agent 50 performs a ROAP upon accessing the RI 40 to transfer a RORequest message. In this case, the ROAP trigger message activates the SCE DRM agent 50 to acquire the RO of the RI 40. The ROAP trigger message may not be required. Even if the ROAP trigger message is not sent, the SCE DRM agent 50 can initiate the ROAP by transferring the RORequest message to the RI 40.
In the fifth phase, the SCE DRM agent 50 transfers the RORequest message to the RI 40 to acquire the user domain RO of the RI 40 in the S208 operation. The RORequest message may be similar to the RORequest message of a 2-step ROAP protocol according to an OMA DRM of V2.0. In this case, the CSE DRM agent 50 transfers to the RI 40 the information for the RO request and the user verification, such as the device ID, domain ID, RI ID, request time, RO information , and digital certificate / signature. The domain ID may be the user domain ID, acquired through the DA 20. In this case, the SCE DRM agent 50 has information about the DA 20 that manages the user domain information to acquire the RO of user domain and transfers the information on the DA 20 to the RI 40. In the sixth phase, the RI 40 exchanges information with the DA 20 to acquire user domain information in operations S210 and S212. Since the RI 40 issues the user domain RO to the SCE DRM agent 50, the RI 40 checks with the DA 20 whether the SCE DRM agent 50 belongs to the user domain. In addition, the RI 40 receives a User Domain Key (DK) from the DA 20. In this case, when the RI 40 transfers the UserDomainRequest message to the DA 20, the DA 20 responds to the RI 40 when transferring the message from
UserDomainResponse that contains the appropriate information. In this phase, the RI 40 and the DA 20 exchange the DK and other information for the RI 40 to create the user domain RO. In the seventh phase, the RI 40 transfers the RORresponse message to the SCE DRM agent 50 in operation S214. In this phase, the RI 40 transfers the user domain RO to the SCE DRM agent 50. The ROResponse message may be substantially similar to the ROResponse message of the OMA V2.0 DRM 2-step ROAP protocol. In this case, the RI 40 transfers to the SCE DRM agent 50 the information for RO transfer and user verification, such as process result, device ID, RI ID, created RO information, and certificate / digital signature. In the present exemplary embodiment, the RI 40 acquires authorization procedure with respect to the user domain and the information acquisition procedure for issuing the user domain RO to the SCE DRM agent 50. Accordingly, the aforementioned DA-RI registration mechanism allows the RI 40 to acquire information in advance with respect to the DA 20. FIGURE 5 illustrates a method for using a rights object for user domain by a DRM 2.0 agent which uses the registration method according to a second exemplary embodiment of the present invention.
The second exemplary embodiment describes how the DA-RI registration method is implemented and in which phase the DA-RI registration method is executed. The second exemplary mode assumes that the user domain is managed by the DA 20 and the DEA 30, which are combined with each other. If the DA 20 and the DEA 30 are separated from each other, the user domain is managed by the DEA 30. In the first phase, the DA 20 is registered in the RI 40 through the registration mechanism of DA-RI in the S300 operation. This phase is carried out in advance since the RI 40 carries out the user domain registration with the DA 20 on behalf of the DRM 2.0 agent 60 in the seventh phase in such a way that the DRM 2.0 agent 60 can use the RO of user domain. The first phase can be done at any time before the seventh phase. If the DA-RI registration procedure has already been done, no additional DA-RI registration procedure may be necessary. In the second phase, the SCE DRM agent 50 registers with the DA 20 to join the user domain in the S302 operation. That phase can be implemented similarly to the procedure for registering the DRM agent to the DRM domain of OMA V2.0. Once this phase is successy completed, the SCE DRM agent 50 is a member of the user domain and can use the user domain RO.
In the third phase, the SCE DRM agent 50 acquires the user domain RO of the RI 40 in operation S304. This phase follows the method described above according to the first embodiment shown in FIGURE 4. In the fourth phase, the SCE DRM agent 50 transfers the acquired user domain RO and the DRM Content Format (DCF) to a DRM 2.0 agent 60 in operation S306. The transfer method can be any method for transferring content associated with DRM from one device to another device. The DRM 2.0 agent 60 can register with the DA 20 and join the user domain to use the user domain RO. However, the DRM 2.0 agent 60 may not make a direct application for admission to the DA 20, and may make an indirect application for admission to the DA 20 through the RI 40. After registration of the DRM agent 60 2.0 with the user domain, the DRM 2.0 agent 60 receives a DK and uses the user domain RO. After this, the fifth, sixth, seventh and eighth phases will be described. In the fifth phase, the DRM 2.0 agent 60 registers with the RI 40 using the OMA DRM 4-step registration protocol V2.0 in operation S308. If any information is required to use the user domain RO, the information can be transferred additionally
using an extension or other message field. In the sixth stage, the DRM 2.0 agent 60 transfers a JoinDomainRequest message to acquire a DK and use the user domain RO in operation S310. Since the DRM 2.0 agent 60 may not directly access the DA 20 to acquire the DK, the DRM 2.0 agent 60 may acquire the DK indirectly through the RI 40. Accordingly, the JoinDomainRequest message may be similarly written in the DRM JoinDomainRequest message V2.0. In the seventh phase, the RI 40 performs the user domain registration in the DA 20 on behalf of the DRM 2.0 agent 60 in operation S312. In this case, a JoinDomainRequest message, which is transferred by the DRM 2.0 agent 60 in the sixth phase, may contain a tag that explicitly requests user domain registration. Alternatively, a domain ID field of the JoinDomainRequest message corresponds to a user domain ID area, and if a corresponding user domain ID is entered, access to the DA 20 is allowed. In the previous scenario, the RI 40 has a small amount of overhead to implement the process, while in the latter scenario, the antecedent compatibility of the DRM 2.0 agent can be supported. When the seventh phase is complete, the RI 40
wants the DK on behalf of the DRM 2.0 agent 60 in such a way that the user domain RO can be used. In the eighth phase, the DK acquired in the seventh phase is transferred to the DRM 2.0 agent in operation S316. In this case, the JoinDomainResponse message can be written similarly to the JoinDomainResponse message of DRM V2.0. Accordingly, in the present exemplary embodiment, the DA-RI registration mechanism is performed in such a way that the RI 40 acquires the information about the DA 20 in advance. If the DA-RI registration procedure is already carried out in the third phase and the validity term has not expired, the DA-RI registration procedure may not be required. FIGURE 6 illustrates a method for using a user domain rights object imported by a DRM 2.0 agent using the registration method according to a third exemplary embodiment of the present invention. More specifically, the third exemplary embodiment describes a method for using the user domain RO, imported by a Local Rights Administrator (LRM) by the DRM 2.0 agent 60. The present exemplary embodiment describes how the DA-RI registration method is included and in which phase the DA-RI registration method is executed. The present exemplary embodiment assumes that the user domain
it is managed by the Domain Authority 20 (DA) and the Agent 30 of Execution of Domain (DEA), which are combined among themselves. If the DA 20 and the DEA 30 are separated from each other, the user domain is managed by the DEA 30. In the first phase, the LRM 10 is registered with the AD
, allocates the domains, and receives import procedures to convert OMA DRM-free RO into OMA DMR RO for user domain in the S400 operation. This phase may include multiple procedures for message transfer and data exchange. If this phase is successful, the LRM 10 creates the imported user domain RO and the imported DCF, which can be used by the DRM 2.0 agent 60. Different methods for importing DRM data by an LRM 10 are described and claimed in the application that has the attorney's file number P2199US00, which was assigned to the same assignee of the present application. In the second phase, the DA 20 is registered in the RI 40 through the registration mechanism of DA-RI in operation S402. This phase is carried out in advance since the RI 40 supports the DRM 2.0 agent 60 in the user domain in the sixth phase in such a way that the DRM 2.0 agent 60 can use the imported user domain RO. In this way, the second phase can be carried out at any time before the sixth phase. If the second phase was already carried out and the
validity period has not expired, the second phase may not be performed. In the third phase, the user domain RO and DCF are transferred from the LRM 10 to the DRM 2.0 agent in operation S404. The transfer method can be any method for transferring content associated with DRM from one device to another device. The DRM 2.0 agent 60, which receives the RO of the user domain imported, may not directly carry out the registration with the DA 20. Accordingly, the RI 40 performs the registration in the DA 20 on behalf of the agent 60 of DRM 2.0. After registration in the DA 20, the DRM 2.0 agent 60 receives a DK and uses the user domain RO. After this, the fourth, fifth, sixth and seventh phases will be described, which are similar to the fifth, sixth, seventh and eighth phases in the second exemplary embodiment described in the foregoing. Accordingly, in the present embodiment, the DA-RI registration mechanism is included in such a way that the RI 40 acquires the information about the DA 20 in advance. If the DA-RI registration procedure is already carried out and the validity term has not expired, the DA-RI registration procedure may not be required. As it is apparent from the previous description, it is possible to effectively implement the functions
of SCE through a DA-RI registration mechanism in accordance with exemplary embodiments of the present invention, including: (1) a method for acquiring the user domain RO by the DRM agent 50; (2) a method for using the user domain RO by the DRM 2.0 agent 60; and (3) a method for using the user domain RO imported by the DRM 2.0 agent 60. In addition, since the Da-RI registration function is used to notify the RI of the DA information in advance, in the DA-RI registration function it can be used even if the RI does not have direct access to the DA. In addition, the DA-RI registration function can provide information in advance to implement any new protocol / function between the DA and RI. Accordingly, the DA-RI registration function can precede any new protocol / function between the DA and RI. It will be apparent to those skilled in the art that various modifications and variations may be made in the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention with the proviso that they fall within the scope of the appended claims and their equivalents.