200820039 九、發明說明： 【參照之相關申請案】 本申請案主張2006年8月21日所申請之韓國專利申 凊案弟10-2006-0079066號，2006年1〇月9曰所申請之 韓國專利申請案第10-2006-0098167號，2006年10月18 曰_所申請之韓國專利申請案第10_20〇6_〇1〇1531號之優先 權’包含在此供參考。 【發明所屬之技術領域】 本發明係關於數位權利管理，具體而言，係關於輸入 數位權利管理資料，以將使帛者域中非公開摘聯盟的數 位權利管理資料轉換為公開行動聯盟的數位權利管理 料的方法。 、 【先前技術】 ❹ 隨著可遞送多媒體内容給使用者的裝置不斷增加，使 2者可擁奴操彳愤鍊置、麵触裝置轉控制或負 貝這些裝置包含可上網的家庭媒體中心系統及帶有某程 度網路連線能力的手持裝置。手縣置可包含手機及;]:攜 式音樂播放ϋ。瓣連線可包含修透過手機上網的無^ 連線或透過個人電腦上網的有線寬頻網際網路連線。使 ^者可透過網路連線’購買並下載比方多媒體内容的内 容、或運作裝置的程式。 200820039 然而，使用者亦會想在其所擁有的其他裝置上摔作此 内容或程式。因此，公開行動聯盟（0penMGbileAu=此 OMA)行域崎體鮮域雜薦的公開行動聯盟 /OMA)數位權利管理(DRM)安全内容交換(sce)規格㈣ ^稱為「OMASCE規格」），係包含在此作參考，其建立 「使用者域」的觀念，使得使用者可建立使用者域。使用 者域可包含許多使用者本身所擁有、操作、控制、或負責 的裝置。使用者可增加裝置到使用者域，並可使用使用者 域中的裝置，取得使用者域中可用的内容。再者，使用者 可透過網路連線，或適合在裝置間移轉内容的儲存記憶體 (好比安全可移除式媒體(SRM))，在裝置間分享内容。或 者，在内谷是透過網路連線串流的情況下，使用者可分享 權限，藉由例如分享與其權限相關聯之使用者憑證(user token)’而在使用者域的其他裝置間串流内容。 因此，使用者域係指可分享DRM内容的使用者群· 組。所謂的裝置係可包含可在使用者域内分享DRM内容 的任何裝置。使用者域管理可包含好比在使用者域增加裝 置與移除裝置，以及網域政策之應用等管理工作。 因此，内容供應商可允許使用者的使用者域中各裝置 間複製及使用内容。再者，内容供應商可限制及/或禁止在 使用者域外的裝置分佈及使用此内容。 6 200820039 使用者域可由使用者透過具有網路連線的使用者域 中其中一個裝置的操作建立之。舉例而言，使用者可透過 操作一裝置，而觀看可行的網域政策清單，進而建立使用 者域。許多網域政策可被開發，而其中之一可由使用者選 擇作為最適合其本身的網域政策。SCE啟動器得僅支持使 用者域中的單一網域政策。由網路職權(DA)所發佈的使用 者域之網域政策可包含使用者域中最大數量之裝置，内容 使用之暫時限制，或内容使用之頻率等限制。 DA可提供選出的網域政策與網域鑰匙(DK)給儲存於 使用者裝置中的網域執行代理器(DEA)。此裝置可透過 DEA建立使用者的使用者域。 使用者可接著加入其他的裝置到使用者域中。舉例而 言，使用者可連接手機、可攜式音樂播放器、以及家庭媒 體中心到此裝置，並將這些裝置加入使用者域中。DA所 發佈的網域政策可限制使用者域中可新增的裝置數量，而 DEA可避免使用者域中所新增的裝置量超過此限制。200820039 IX. Invention Description: [Related application] This application claims to apply for the Korean Patent Application No. 10-2006-0079066, which was filed on August 21, 2006. The priority of the Korean Patent Application No. 10_20, the entire disclosure of which is hereby incorporated by reference. TECHNICAL FIELD OF THE INVENTION The present invention relates to digital rights management, and more particularly to the input of digital rights management materials to convert digital rights management data of non-publicly extracted alliances in the field into digital values of public action alliances. The method of managing the rights. [Prior Art] ❹ With the increasing number of devices that can deliver multimedia content to users, the two can have slavery, anger chain, face device control or negative shell. These devices include Internet-enabled home media center systems. And a handheld device with a certain degree of network connectivity. Hand County can include mobile phones and;]: portable music player. The flap connection can include a wired broadband Internet connection that is connected via a mobile phone or connected via a personal computer. The user can purchase and download the content of the multimedia content or the program of the operating device through the Internet connection. 200820039 However, users will also want to drop this content or program on other devices they own. Therefore, the Open Action Alliance (0penMGbileAu=this OMA) is a public interest alliance (OMA) for digital domain rights management (DRM) security content exchange (sce) specification (4) ^ called "OMASCE specification") Included here for reference, it establishes the concept of a "user domain" so that the user can establish a user domain. The user domain can contain many devices that the user owns, operates, controls, or is responsible for. The user can add devices to the user domain and can use the devices in the user domain to obtain content available in the user domain. Furthermore, users can share content between devices via a network connection or storage memory suitable for transferring content between devices (such as Secure Removable Media (SRM)). Alternatively, in the case where the inner valley is streamed through the Internet connection, the user can share the rights and string between other devices in the user domain by, for example, sharing user tokens associated with their rights. Streaming content. Therefore, the user domain refers to the user group and group that can share the DRM content. A so-called device may include any device that can share DRM content within a user domain. User domain management can include administrative tasks such as adding devices and removing devices in the user domain, as well as applications for domain policies. Therefore, the content provider can allow content to be copied and used between devices in the user's user domain. Furthermore, the content provider may limit and/or prohibit distribution and use of the content outside of the user's domain. 6 200820039 The user domain can be established by the user through the operation of one of the devices in the user domain with the network connection. For example, a user can view a list of possible domain policies by operating a device to establish a user domain. Many domain policies can be developed, and one of them can be chosen by the user as the domain policy that best suits itself. The SCE Enabler only supports a single domain policy in the consumer domain. The domain policy of the user domain published by the network authority (DA) may include the maximum number of devices in the user domain, temporary restrictions on the use of content, or the frequency of content usage. The DA can provide the selected domain policy and domain key (DK) to the Domain Execution Agent (DEA) stored in the user device. This device can establish the user's user domain through DEA. The user can then join other devices to the user domain. For example, a user can connect a mobile phone, a portable music player, and a home media center to the device and add these devices to the user domain. The domain policy issued by DA limits the number of devices that can be added in the user domain, while DEA prevents the number of devices added to the user domain from exceeding this limit.
當使用者取得使用者域權利物件(R〇)及内容時，使用 者可能會想與使用者域巾的裝置或使用者域外的裝置分 享此内容。使用者可接著將相連的裝置連接職用者域中 的其他裝置，以移制容㈣本及其職RQ給 中的其他裝置。 A 7 200820039 SCE啟肺可啟動拥發佈雜j)，其可與内容發佈 者交換内容加密鑰匙(CEK)，以指定使用者域中各裝置間 權利消耗的允許使用量及權利移轉。允許使用量可包含在 使用者域各裝㈣作減、複製及/或移㈣容的允許。 SCE啟動益亦可啟動见，以指定使用者域外各褒置間的允 許使用量之權利。允許使用量可包含複製及移動内容至使 用者域外的裝置。或者，允許制量可禁止朗者域内的 裝置複製或移動内容到使用者域外的裝置。 因此，OMA SCE規格引進「使用者域」的觀念，使 才于使用者可直接操作使用者域管理，而無需透過见來運 作使用者域管理。因此，OMA SCE規格亦引進DA及DEA 的觀念’使传定義並描述網域政策可由DA運作，而DEA 可運作網域政策的執行。DA及DEA可為獨立個體或可為 整合在一起的單一個體。 DA可定義並描述網域政策，並可遞送此網域政策給 DEAaDEA可接收來自DA的網域政策，並可根據所收到 的網域政策，定義及管理使用者域。亦即，DEA所產生之 使用者域亦係由DEA管理。若DA及DEA整合為單一個 體，則DA可定義使用者域並運作網域管理，而無需一獨 立的DEA作為介面。 圖1顯示OMASCE規格的示意圖。 200820039 與習知OMA DRM V2.0標準(爾後稱為〇mA DRM V2.0)不同的是，OMASCE規格包含： (1) 本區權利管理器(LRM)的輸入(import)功能； (2) DA與DEA的使用者域功能；以及 (3) 將RO從一裝置移動到另一裝置的移動功能。 爾後，輸入功能及使用者域功能詳述如後。 OMA SCE規格^供可由LRM運作之輸入功能。輸入 功能係指將非OMA DRM資料轉換為〇MA DRM資料的 功能。 舉例而言’與OMA DRM相容的裝置可試圖播放非 OMADRM資料。在此情況下，非〇MADRM資料應根據 OMA SCE規格由LRM轉換或輸入為qma DRM資料。 因此，LRM將非OMA DRM資料輸入為DRM内容格式 (DCF) ’並輸入QMADRM的RO，分別稱為「輸入dcf」 或「輸入RO」。支援0MADRM的輸入DCF及輸入R〇， 係可根據OMA SCE規格由與OMA DRM相容的裝置中的 DRM代理器使用之。 如上述，使用者域允許使用者運作使用者域中許多裝 置的使用者域管理，而不用如習知OMA DRM V2 〇桿準， 透過權利發佈者(RI)針鱗個裝置進行使用者域管理、。 9 200820039 然而’習知OMA DRM V2.0標準的其他功能係與 OMA SCE規格相容。舉例而言，〇MA DRM V2 〇包含4 次傳送登記協定及2次傳送權利物件(RO)取得協定，供裝 置取得一個RO。 圖2顯示OMADRM V2.0之4次傳送登記協定。 4次傳送登記協定允許裝置與ri交換資訊並向彼此登 記其資訊。若協定成功，則此裝置可擁有RI情境(context)， 其包含關於RI的資訊，且RI可擁有其裝置的資訊。 根據4次傳送登記協定，首先裝置移轉包含裝置資訊 的裝置哈囉(Device Hello)信息給RI。Device Hello信息可 包含協定版本、裝置ID、及支援其裝置之加密演算法。 在第二階段，RI移轉包含RI資訊的RI哈囉(RIHello) -信息到裝置中。RI Hello信息包含移轉結果、對話ID、協 定版本、RUD、所支援的演算法、及其他確認及伺服器資 訊0 在第三階段，此裝置接著移轉RegistrationRequest信 息給RI，以向RI登記此裝置。RegistrationRequest信息包 含確認資料，好比對話ID、信息移轉時間、認證及簽章與 現時。 200820039 在第四階段，RI最後移轉Registrati〇nResp_信息 給裝置。Registrati〇nResponse信息包含確認資料好比裝 置，記結果、_ ID、R!認證，練簽章、錢線上認證 狀態協定(OCSP)回應，係送給rj以作為w根據某特定事 件送給OCSP回應者之〇CSP請求信息之回應。 圖3顯示OMADRMV2.0之2次傳送R〇取得協定。 2次傳送RO取得協定係在4次傳送登記協定之後運 作’以取得RO。根據運作4次傳送登記協定所取得之rj 情境’裝置藉由傳送RORequest信息到RI，並藉由接收來 自RI的ROResponse信息，以接收來自RI的r〇。再者， 0CSP回應可傳送給RI，以回應在某些特定事件中RI傳 送OCSP請求信息給OCSP回應者。 再者，此裝置可登記對應的使用者域。圖4顯示OMA DRMV2.0之2次傳送加入網域協定。 2次傳送加入網域協定係由支援OMA DRM V2.0的裝 置使用，以使用基於網域的R〇。在此情況下，此裝置可 再利用2次傳送加入網域協定加入對應網域之後，使用基 於網域的RO。2次傳送加入網域協定通常僅在發生4次 傳送登記協定之後才會運作。一旦作了加入，此裝置可透 過圖5所示的程序使用R〇。 200820039 圖5顯示根據OMA DRM V2.0由一裝置使用R〇的 方法。 丄在第一階段，裝置D卜D2及D3利用圖2所示之4 =傳送登記協定，以及圖4所示之2次傳送登加入網域協 疋加入網域。在第二階段，裝置D1透過圖3所示之2次 傳送RO取得協定，從KI取得R〇。在第三階段，所取得 Ο 的R0會從裝置D1移轉到裝置m及D3。由於裝置D2When the user obtains the user domain rights object (R〇) and the content, the user may want to share the content with the device of the user domain towel or the device outside the user domain. The user can then connect the connected device to other devices in the user's domain to move the other devices in the (4) home and RQ. A 7 200820039 SCE can initiate a release of j), which exchanges content encryption keys (CEK) with content publishers to specify the allowable usage and transfer of rights between devices in the user domain. The allowable usage can be included in the user domain (4) for the reduction, copying and/or shifting (4) tolerance. The SCE Startup Benefit can also be activated to specify the right to allow usage between the devices outside the user's domain. Allowable usage can include copying and moving content to devices outside the user's domain. Alternatively, the system is allowed to prohibit devices within the domain from copying or moving content to devices outside the user's domain. Therefore, the OMA SCE specification introduces the concept of a "user domain" so that the user can directly operate the user domain management without having to operate the user domain management. Therefore, the OMA SCE specification also introduces the concept of DA and DEA. The definition and description of the domain policy can be operated by the DA, and the DEA can operate the domain policy. DA and DEA can be independent individuals or can be a single entity that is integrated together. The DA can define and describe the domain policy and can deliver this domain policy to DEAaDEA to receive domain policies from the DA and to define and manage user domains based on the received domain policies. That is, the user domain generated by the DEA is also managed by the DEA. If DA and DEA are integrated into a single entity, the DA can define the user domain and operate the domain management without the need for a separate DEA as the interface. Figure 1 shows a schematic of the OMASCE specification. 200820039 Unlike the conventional OMA DRM V2.0 standard (hereinafter referred to as 〇mA DRM V2.0), the OMASCE specification includes: (1) the import function of the District Rights Manager (LRM); (2) The user domain function of the DA and DEA; and (3) the mobile function of moving the RO from one device to another. After that, the input function and user domain functions are detailed as follows. OMA SCE specification ^ for input functions that can be operated by LRM. Input function refers to the function of converting non-OMA DRM data into 〇MA DRM data. For example, a device compatible with OMA DRM may attempt to play non-OMA DRM material. In this case, non-〇MADRM data should be converted or entered as qma DRM data by LRM according to OMA SCE specifications. Therefore, LRM inputs non-OMA DRM data into DRM Content Format (DCF)' and inputs the RO of QMADRM, which is called "input dcf" or "input RO". The input DCF and input R〇 supporting 0MADRM can be used by the DRM agent in the OMA DRM compatible device according to the OMA SCE specification. As described above, the user domain allows the user to operate the user domain management of many devices in the user domain without using the rights issuer (RI) pin-scale device for user domain management, as is the case with the conventional OMA DRM V2 benchmark. ,. 9 200820039 However, other functions of the OMA DRM V2.0 standard are compatible with the OMA SCE specification. For example, 〇MA DRM V2 〇 contains 4 transfer registration agreements and 2 transfer rights object (RO) acquisition agreements for the device to obtain an RO. Figure 2 shows the four transfer registration agreements for OMADRM V2.0. The 4 transfer registration agreement allows the device to exchange information with ri and register their information with each other. If the agreement is successful, the device may have an RI context that contains information about the RI and the RI may have information about its device. According to the 4th transfer registration agreement, the device first transfers the device Hello information containing the device information to the RI. The Device Hello information can include the protocol version, the device ID, and the encryption algorithm that supports its device. In the second phase, the RI transfers the RI Hello (RIHello) containing the RI information to the device. The RI Hello message contains the transfer result, the session ID, the protocol version, the RUD, the supported algorithm, and other acknowledgments and server information. In the third phase, the device then transfers the RegistrationRequest message to the RI to register the RI with the RI. Device. The RegistrationRequest message contains confirmation information, such as the conversation ID, information transfer time, certification and signature, and current status. 200820039 In the fourth phase, the RI finally transferred the Registrati〇nResp_ message to the device. The Registrati〇nResponse information contains confirmation information such as device, record result, _ ID, R! certification, practice signature, and money online certification status agreement (OCSP) response, which is sent to rj as a w to give OCSP respondents according to a specific event. After that, the CSP requests the response. Figure 3 shows the 2nd transmission R〇 acquisition agreement for OMADRMV2.0. The second transfer RO acquisition agreement is operated after four transfer registration agreements to obtain the RO. The rj context device obtained by operating the four-transmission registration agreement transmits the RORequest information to the RI and receives the ROResponse information from the RI to receive the r〇 from the RI. Furthermore, the 0CSP response can be sent to the RI in response to the RI transmitting the OCSP request message to the OCSP responder in certain events. Furthermore, the device can register the corresponding user domain. Figure 4 shows that the 2 transmissions of OMA DRMV 2.0 join the domain agreement. The 2-pass join to the domain agreement is used by devices that support OMA DRM V2.0 to use domain-based R〇. In this case, the device can use the domain-based RO after the second transfer joins the domain agreement to join the corresponding domain. A 2-pass join to a domain agreement usually only works after 4 transfer registration agreements have occurred. Once added, the device can use R〇 through the procedure shown in Figure 5. 200820039 Figure 5 shows the method of using R〇 by a device according to OMA DRM V2.0. In the first stage, the devices D Bu D2 and D3 use the 4 = transfer registration protocol shown in Figure 2, and the 2 transfers shown in Figure 4 join the domain association to join the domain. In the second stage, the device D1 transmits the RO acquisition protocol through the secondary transfer shown in Fig. 3, and acquires R〇 from the KI. In the third stage, the obtained R0 of Ο is transferred from the device D1 to the devices m and D3. Due to device D2
及D3係加入與裝置D1相同的網域，因此裝置D1將RO 移轉給尚未加入與裝置D1相同的網域的裝置D4。由於裝 置D4尚未加入網域，因此在第五階段裝置D4係透過2 次傳送加入網域協定加入此網域，並使用來自裝置D1的 RO 〇 然而’ OMASCE規格並不描述由lrm輸入，並將非 ;, 〇MADRM資料改為OMADRM資料的方法，或允許屬於 使用者域之DRM代理器使用輸入oma DRM資料的方 法。 【發明内容】 本發明提供一種輸入DRM資料以將非〇MADRM資 料轉換為OMADRM資料的方法。 本發明亦提供一種藉由DRM代理器從DA或RI取得 200820039 輸入RO來使用輸入DRM資料的方法。 本發明之其他特徵將描述如下，熟此技藝者當可根據 其描述而知其特徵或由實施本發明而得知。 本發明揭露一種輸入數位權利管理(DRM)資料之方 法’其包含向網域職權(DA)登記本區權利管理器(LRM)， 交換使用者域資訊，以及根據使用者域資訊從非公開行動 聯盟(OMA) DRM資料，建立DRM内容格式(DCF)以及權 利物件(RO)，其中DCF及RO係符合OMADRM標準。 本發明亦揭露一種使用數位權利管理(D rm)資料的 方法，其包含向網域職權(DA)登記本區權利管理器 (LRM) ’交換使用者域資訊，以及根據使用者域資訊從非 公開行動聯盟(OMA) DRM資料，建立DRM内容格式 (DCF)以及權利物件(R〇)，其中dcf係符合OMADRM標 準’由權利發佈者(RI)建立使用者域的權利物件(R〇)，以 及將DCF從LRM移到一裝置的DRM代理器。 本發明亦揭露一種輸入數位權利管理(DRM)資料的 方法’其包含向網域職權(DA)登記權利發佈者(RI)給本區 權利管理器(LRM)，交換使用者域資訊，以及根據使用者 域資訊從非公開行動聯盟(OMA) DRM資料，建立DRM 内容格式(DCF)以及權利物件(R〇)，其中dCf以及R〇係 13 200820039 符合OMADRM標準。 ΟAnd D3 is added to the same domain as device D1, so device D1 transfers the RO to device D4 that has not yet joined the same domain as device D1. Since the device D4 has not yet joined the domain, in the fifth stage, the device D4 joins the domain by joining the domain agreement with 2 transmissions, and uses the RO from the device D1. However, the OMASCE specification does not describe the input by the lrm, and No;, the method of changing the MADRM data to OMADRM data, or the method of allowing the DRM agent belonging to the user domain to use the input oma DRM data. SUMMARY OF THE INVENTION The present invention provides a method of inputting DRM data to convert non-〇MADRM data into OMADRM data. The present invention also provides a method for inputting DRM data by using a DRM agent to obtain a 200820039 input RO from a DA or RI. Other features of the present invention will be described in the following, and those skilled in the art will be aware of the features of the present invention. The present invention discloses a method for inputting digital rights management (DRM) data, which includes registering a local rights manager (LRM) with a domain authority (DA), exchanging user domain information, and performing non-public actions based on user domain information. Alliance (OMA) DRM data, establishing DRM Content Format (DCF) and Rights Object (RO), where DCF and RO are compliant with OMADRM standards. The invention also discloses a method for using digital rights management (D rm) data, which comprises registering a local area rights manager (LRM) to exchange domain domain information, and according to user domain information. Open Action Alliance (OMA) DRM material, establishing DRM Content Format (DCF) and Rights Object (R〇), where dcf is OMADRM compliant 'Right Object (R〇) for Establishing User Domain by Rights Publisher (RI), And a DRM agent that moves the DCF from the LRM to a device. The present invention also discloses a method for inputting digital rights management (DRM) data, which includes registering a rights issuer (RI) with a domain authority (DA) to a local rights manager (LRM), exchanging user domain information, and User domain information from the Non-Public Action Alliance (OMA) DRM data, the establishment of DRM Content Format (DCF) and rights objects (R〇), where dCf and R〇13 200820039 comply with OMADRM standards. Ο
本發明亦揭露一種使用數位權利管理(DRM)資料的 方法，其包含登記權利發佈者(RI)給本區權利管理器 (LRM) ’父換使用者域資訊’以及根據使用者域資訊從非 公開行動聯盟(OMA) DRM資料，建立DRM内容格式 (DCF)以及權利物件(R0)，其中DCF係符合〇MADRM標 準’建立使用者域的權利物件(RO)，在網域職權(DA)及 RI間交換使用者域資訊，以及將DCF從LRM移到一震置 的DRM代理器。 需要知道的是，上述一般描述及以下詳述僅供範例及 說明之用，僅為了進一步描述本發明之說明。 【實施方式】 、本發明爾後將參照伴隨圖式作進一步之描述，其伴隨 ，式緣示本發明之示範實施例。然而，本發明可以不同型 恶實施’因此不得解釋為受限於在此所示之示範實施例。 =之’這些示範實施例僅係用以完整描述本揭露，且將完 f表達本發明之範疇給熟此技藝者。在圖式中，各層級與 ，圍的大小及相對大，】、可能會誇示作說明之用。圖中類似 參考數代表類似元件。 爾後’將描述本發明之示範實施例輸入DRM資料的 14 200820039 方法。本發明之實施例輸入DRM資料的方法所使用的協 定’係與上述OMADRMV2.0標準中所述之協定以類似 的方式運作。 圖ό繪示本發明之示範實施例將非〇MA DRM資料輸 入為使用者域中之OMADRM資料的方法。具體而言，圖 6繪示LRM 10將非OMADRM資料輸入使用者域中之 OMA DRM資料’使得屬於使用者域中之裝置的代 理器50得以使用OMADRM資料的方法。 在第一階段，於作業S100,在LRM 10及DA20間進 行登記程序。此登記可在當LRM 10開始進行使用者域之 輸入功能時運作。再者，若登記過時，則亦可進行此登記 作業。詳述之，登記階段進行共同認證/鑰匙交換，以及後 續登ό己溝通中許多參數的共同交換/確認。登記程序可利用 4次傳送登圮協定在LRM 10與DA·20間實施。亦即，登 (1 記階段可經過許多信息交換實施。 在第二階段，使用者域資訊係由在作業sl〇2進行交 換。使用者域資訊係由LRM 10進行交換，以將非〇Ma DRM資料轉換為與DA 20相關聯之使用者域的〇Ma DRM資料。 若需要現有使用者域中之〇madrm資料，則 15 200820039 會從DA 20接收有關使用者域之資訊。 除非有使用者域的存在，否則OMADRM資料的使用 者域係透過DA20作分配，而使用者域相關之資訊會移轉 、給LRM 10。使用者域資訊交換程序可透過數個信息交換 而實施。 f) 在第三階段，接收到可供輸入(import-ready)之資料以 在作業S104建立DRM内容格式(DCF)。可供輸入資料係 指欲轉換為OMADRM資料的非OMADRM資料。接收 及轉換資料的方法可為由LRM 10所運作之任何接收及轉 換與DRM相關聯之内容的方法。 若LRM 10沒有關於使用者域的足夠資料，當收到的 可供輸入資料將轉換為使用者域之DCF時，即可運作上 述使用者域資訊交換程序。 ϋ 在第四階段，使用者域的r〇係由作業Si〇6及作業 S108的DCF建立之。在作業sl〇6，LRM 1〇移轉 CreateRORequest 信息給 ri 40。在作業 sl〇8 中，w 4〇 將The present invention also discloses a method for using digital rights management (DRM) data, which includes a registration rights issuer (RI) to a local rights manager (LRM) 'parent user domain information' and a non-user domain information Open Action Alliance (OMA) DRM material, establishing DRM Content Format (DCF) and Rights Object (R0), where DCF is in compliance with the MADRM standard 'establishing user domain rights (RO), in domain authority (DA) and The user domain information is exchanged between the RIs, and the DCF is moved from the LRM to a shocked DRM agent. It is to be understood that the foregoing general description and claims [Embodiment] The present invention will be further described with reference to the accompanying drawings, which are accompanied by exemplary embodiments of the invention. However, the invention may be embodied in different forms and should not be construed as being limited to the exemplary embodiments shown. The exemplary embodiments are intended to be a complete description of the disclosure, and the scope of the invention will be apparent to those skilled in the art. In the drawings, the levels of each level and the size of the enclosure are relatively large, which may be exaggerated for illustrative purposes. Like reference numerals in the figures represent like elements. Hereinafter, a method of inputting DRM data of the exemplary embodiment of the present invention will be described. The protocol used in the method of inputting DRM data in the embodiment of the present invention operates in a similar manner to the protocol described in the above OMA DRMV 2.0 standard. The figure illustrates a method of inputting non-〇 MA DRM data into OMADRM data in a user domain in an exemplary embodiment of the present invention. Specifically, FIG. 6 illustrates a method in which the LRM 10 inputs non-OMA DRM data into the OMA DRM material in the user domain such that the agent 50 belonging to the device in the user domain can use the OMA DRM material. In the first stage, in the job S100, a registration procedure is performed between the LRM 10 and the DA 20. This registration can be operated when the LRM 10 starts the input function of the user domain. Furthermore, if the registration is out of date, this registration can also be performed. In detail, the registration phase performs a common authentication/key exchange, and a common exchange/confirmation of many parameters in the subsequent communication. The registration process can be implemented between LRM 10 and DA·20 using 4 transfer registration agreements. That is, Deng (1 phase can be implemented through many information exchanges. In the second phase, user domain information is exchanged in job sl2. User domain information is exchanged by LRM 10 to be non-〇Ma The DRM data is converted into the 〇Ma DRM data of the user domain associated with the DA 20. If the 〇madrm data in the existing user domain is required, then 15 200820039 will receive information about the user domain from the DA 20. Unless there is a user The domain exists, otherwise the user domain of the OMADRM data is distributed through the DA20, and the user domain related information is transferred to the LRM 10. The user domain information exchange program can be implemented through several information exchanges. In the third stage, information available for import-ready is received to establish a DRM Content Format (DCF) at job S104. The available data is the non-OMADRM data to be converted to OMADRM data. The method of receiving and converting data can be any method by which the LRM 10 operates to receive and convert content associated with the DRM. If the LRM 10 does not have sufficient information about the user domain, the user domain information exchange program can be operated when the received input data is converted into the DCF of the user domain. ϋ In the fourth stage, the user domain's r〇 is established by the job Si〇6 and the DCF of job S108. In job sl6, LRM 1〇 transfers the CreateRORequest message to ri 40. In the job sl〇8, w 4〇 will
CreateROResponse 信息移轉給 LRM 10。 在此等作業，RI40及LRM 10交換有關權利允許及 限制之資訊，以儲存於R〇中，並交換建立DCF所使用之 16 200820039 鑰匙及RO建立與安全通訊之資料。藉此，m 4〇建立使 用者域之RO，以在LRM 10發出請求時移轉給LRM 10。 然而，在建立RO之後，RI4 0可能不會移轉r〇給LRM 10。 由於RI40係使用使用者域資訊來建立R〇,因此使 用者域資訊係在第四階段於LRM 1〇與见4〇間作交換。 使用者域資訊包含建立R〇之鑰匙，以及相關資料交換的 資訊。 在第五階段’ LRM10在作業S110將所建立的DCF 移轉給DRM代理器50。 在第六階段，DRM代理器50在作業3112加入使用 者域以使用DCF。若DRM代理器50在第六階段前即已 加入使用者域’則本發明可不包含此階段。 在第七階段，進行R〇取得程序係於作業s丨14在DRM 代理器50端取得RO。R〇取得階段係透過如圖3所示之 數個信息交換實施。然而，若RQ係從LRM 1G所接收， 則可能不需要第七階段。再者，若DRM代理器5G在轉 使用者域的RO時尚未加人使用者域，财在使用R0前 先行運作第六階段。 圖7、、、曰示本务明之另一示範實施例將非⑽a〇腕資 200820039 料輸入為使用者域中之0MA DRM資料的方法。本發明之 示範實施例包含於作業S208及作業S21〇，在da2〇及 Ri4〇間交換元資料資訊，或使用者域資訊。 在苐h #又，於作業S200運作LRM 10與RI40間之 登記程序。可在LRM 1〇開始運作使用者域之輸入功能時 進行登記。再者’若登記過時，則可進行登記。詳述之， ζ) 登5己階段進行共同認證/鑰匙交換，以及後續登記溝通中許 多參數的共同交換/確認。登記程序可利用4次傳送登記協 疋在LRM 10與RI 40間實施。亦即，登記階段可經過許 多信息交換實施。 在第二階段，於作業S202，在LRM 10端收到可供輸 入資料以建立DCF。可供輸入資料係指欲轉換為〇ΜΑ DRM資料的非OMADRM資料。接收及轉換資料的方法 可為由LRM 10所運作之任何接收及轉換與DRM相關聯 之内容的方法。 在第三階段，於作業S204建立DCF。在第四階段， 於作業S206，LRM 10將CreateRORequest信息移轉給ri 40。在第五階段，於作業 S208，RI40 將 UserDomainRequest 信息移轉給DA 20，以請求從DA20移轉使用者域資訊。 在第六階段，於作業S210，DA 20將具有使用者域資訊之 UserDomainResponse 信息移轉到RI40。 18The CreateROResponse information is transferred to LRM 10. In these operations, RI40 and LRM 10 exchange information about the rights and restrictions of the rights to be stored in R〇 and exchange information on the establishment of the 2008 2008039 key and RO establishment and safety communication used by the DCF. Thereby, m 4 〇 establishes the RO of the user domain to be transferred to the LRM 10 when the LRM 10 issues a request. However, after the RO is established, RI40 may not transfer r〇 to LRM 10. Since the RI40 uses user domain information to establish R〇, the user domain information is exchanged between LRM 1 and see 4 in the fourth phase. The user domain information contains the key to establishing the R key and the information exchange. In the fifth stage, the LRM 10 transfers the established DCF to the DRM agent 50 at job S110. In the sixth phase, DRM agent 50 joins the user domain at job 3112 to use the DCF. The present invention may not include this stage if the DRM agent 50 has joined the user domain before the sixth phase. In the seventh stage, the R〇 acquisition procedure is performed in the operation s丨14 to obtain the RO at the DRM agent 50 side. The R〇 acquisition phase is implemented through several information exchanges as shown in FIG. However, if the RQ is received from the LRM 1G, the seventh phase may not be needed. Furthermore, if the DRM agent 5G has not added the user domain to the RO of the user domain, the sixth phase is operated before the R0 is used. FIG. 7 is a diagram showing a method of inputting non-(10)a wristband 200820039 into 0MA DRM data in a user domain. An exemplary embodiment of the present invention is included in job S208 and job S21, exchanging metadata information, or user domain information, between da2 and Ri4. In 苐h # again, the registration procedure between LRM 10 and RI 40 is operated at job S200. Registration can be performed when LRM 1 starts to operate the input function of the user domain. Furthermore, if the registration is out of date, registration can be made. In detail, ζ) the common certification/key exchange at the 5th stage and the common exchange/confirmation of many parameters in the subsequent registration communication. The registration process can be implemented between LRM 10 and RI 40 using 4 transfer registration agreements. That is, the registration phase can be implemented through a number of information exchanges. In the second phase, at job S202, an available input data is received at the LRM 10 side to establish a DCF. The information available for input refers to non-OMADRM data to be converted into 〇ΜΑ DRM data. The method of receiving and converting data can be any method by which the LRM 10 operates to receive and convert the content associated with the DRM. In the third stage, a DCF is established at job S204. In the fourth stage, in operation S206, the LRM 10 transfers the CreateRORequest information to the ri 40. In the fifth stage, at job S208, RI40 transfers the UserDomainRequest information to DA 20 to request that the user domain information be transferred from DA20. In the sixth stage, at job S210, the DA 20 transfers the UserDomainResponse information with the user domain information to the RI 40. 18
Ο 200820039 可在上述第五階段及第六階段前先行運作之登記RJ 40與DA20的枝，侧露並主張於律師登錄號為 P2197US00之申請案中，此申請案係與本申請案同 並與本申請案之受讓人相同。 ^在第七階段，於作業％12，RI40係根據使用者域資 訊建立R〇，並將Cre滅0Response信息移轉給LRM 1〇。 於作業S212，RI 4〇亦可將R0移轉給LRM 1〇。 在第八階段，於作業S214，LRM 10移轉DCF及R〇 給DRM代理器50。因此，與先前之示範實施例不同的是， DRM代理器50係從LRM 1〇而非ri 4〇收到R〇。 在第九階段，於作業S216，DRM代理器50傳送 JoinDomainRequest信息給DA2〇以加入使用者域，並使 用DCF。在第十階段，於作業S218，DA20傳送Ο 200820039 The registration of RJ 40 and DA20, which can be operated before the fifth and sixth phases mentioned above, is disclosed and advocated in the application of the lawyer registration number P2197US00. This application is the same as this application. The assignee of this application is the same. ^ In the seventh stage, in operation %12, RI40 establishes R〇 according to the user domain information, and transfers Cre out 0Response information to LRM 1〇. In operation S212, RI 4〇 may also transfer R0 to LRM 1〇. In the eighth stage, at job S214, the LRM 10 moves the DCF and R〇 to the DRM agent 50. Thus, unlike the previous exemplary embodiment, DRM agent 50 receives R〇 from LRM 1 instead of ri 4〇. In the ninth stage, at job S216, the DRM agent 50 transmits the JoinDomainRequest message to the DA2 to join the user domain and use the DCF. In the tenth stage, in job S218, DA20 transmits
JoinDomainResponse 信息給 DRM 代理器 50。若 DRM 代 理器50已加入使用者域，則本發明可不包含第九與第十 階段。 圖8繪示本發明之另一實施例中將非OMA DRM資料 輸入使域者域中之OMADRM資料的方法。第一階段、第 二階段、第三階段、第四階段、第五階段、第六階段、以 及第七階段實質上與圖7所示之各階段相同。 19 200820039 在第八階段’ DCF勤LRM1G移_ DRM代理器 5〇然* ’與被移轉之DCF相關聯之並沒有移制 DRM代理器50。因此，為了使用DCF，圖8顯示第十一 階段的RO取得⑽。RC)取得階段可與圖3所述之方法 實施。若DRM代理器50在取得R〇時尚未加入使用者 域’則可在使用RO前先行運作圖7所述之第九階 +階與。 上述輸入DRM資料的範實施例可作修改。 舉例而言，圖6的第二階段可在圖6的第三階段之 運作。 、再者，若目前裝置的DRM代理器50已加入使用者 域，則可省略圖6的第六階段以及圖7與8的第九盥十階 段。 · ’、 再者’若RO與DCF已在前一階段進行移轉，則可省 略圖6的第七階段與圖8的第十一階段。 再者，加入網域程序可運作於RO取得程序之後。 從以上描述可得知，支援OMA DRM標準的裝置可播 放非OMADRM資料。 20 200820039 再者’若非OMADRM資料被轉換為omadrm資 料，則DRM代理器不僅可以直接從LRM取得被轉換的 RO，其亦可從RI取得之。 ' 熟此技藝者當知，本發明當可作許多潤飾及變化而不 偏離本發明之精神與範"#。因此，本發明亦包含以下請求 向及其均等者之範疇内的所有潤飾及變化。 【圖式簡單說明】 本發明將以各實施例以範例方式參照伴隨圖式描述 其範例精神，其中，伴隨圖式係包含於此藉以提供本發明 進一步之說明’並作為本說明書之一部分·· 圖1繪示OMASCE規格之示意圖。 圖2繪示OMADRM V2.0之4次傳送登記協定。 . 圖3繪示OMADRMV2.0之2次傳送R0取得協定。 〇 圖4繪示0MA DRM V2.0之2次傳送加入網域協定。 圖5繪不OMADRMV2.0中裝置使用尺〇之方法。 圖6繪示本發明之示範實施例將非〇MADRM資料輸 入使用者域之OMADRM資料的方法。 圖7繪示本發明之另一示範實施例將非〇madrm資 料輸入使用者域之OMADRM資料的方法。 圖8繪示本發明之另一示範實施例將非〇MAdrm資 料輸入使用者域之OMADRM資料的方法。 21 200820039 【主要元件符號說明】 本區權利管理器 LRM 10 網域職權 DA20 網域執行代理器 DEA30 權利發佈者 RI40 數位權利管理代理器 50 Ο ΟJoinDomainResponse information to DRM Agent 50. If the DRM agent 50 has joined the user domain, the present invention may not include the ninth and tenth stages. FIG. 8 illustrates a method of inputting non-OMA DRM data into OMADRM data in a domain domain in another embodiment of the present invention. The first phase, the second phase, the third phase, the fourth phase, the fifth phase, the sixth phase, and the seventh phase are substantially the same as the phases shown in FIG. 19 200820039 In the eighth phase, the DCF agent LRM1G shift_DRM agent 5 **' is not associated with the transferred DCF and does not move the DRM agent 50. Therefore, in order to use the DCF, Figure 8 shows the RO acquisition (10) of the eleventh stage. The RC) acquisition phase can be implemented in the manner described in Figure 3. If the DRM agent 50 has not joined the user domain when R is obtained, the ninth order + order sum described in Fig. 7 can be operated before using the RO. The above exemplary embodiment of inputting DRM data can be modified. For example, the second phase of Figure 6 can operate in the third phase of Figure 6. Furthermore, if the DRM agent 50 of the current device has been added to the user domain, the sixth stage of Fig. 6 and the ninth stage of Figs. 7 and 8 may be omitted. · ', Again' If the RO and DCF have been transferred in the previous stage, the seventh stage of Figure 6 and the eleventh stage of Figure 8 can be omitted. Furthermore, joining the domain program can operate after the RO acquisition process. As can be seen from the above description, devices supporting the OMA DRM standard can play non-OMA DRM data. 20 200820039 Furthermore, if the non-OMADRM data is converted to omadrm data, the DRM agent can not only obtain the converted RO directly from the LRM, but also obtain it from the RI. As will be appreciated by those skilled in the art, the present invention can be modified and varied without departing from the spirit and scope of the present invention. Accordingly, the present invention also includes all modifications and variations within the scope of the following claims and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS The present invention will be described by way of example with reference to the accompanying drawings, in which the accompanying drawings FIG. 1 is a schematic diagram of an OMASCE specification. Figure 2 illustrates the four transfer registration agreements for OMADRM V2.0. Figure 3 illustrates the 2nd transmission R0 acquisition agreement for OMADRMV2.0. 〇 Figure 4 shows that the 2nd transmission of 0MA DRM V2.0 joins the domain agreement. Figure 5 depicts the method of using the ruler in the device of OMADRMV 2.0. 6 illustrates a method of inputting non-〇 MADRM data into OMADRM data of a user domain in accordance with an exemplary embodiment of the present invention. 7 illustrates a method of inputting non-〇 madrm data into OMADRM data of a user domain in accordance with another exemplary embodiment of the present invention. 8 illustrates a method of inputting non-〇 MAdrm data into OMADRM data of a user domain in accordance with another exemplary embodiment of the present invention. 21 200820039 [Explanation of main component symbols] Local rights manager LRM 10 Domain authority DA20 Domain execution agent DEA30 Rights issuer RI40 Digital rights management agent 50 Ο Ο