JP2008052736A - ユーザードメインのためにデジタル権限管理をインポートする方法 - Google Patents

Abstract

【課題】モバイル応用ソフトウェア標準化団体のＯＭＡに準じない非ＯＭＡデジタル権限管理データをＯＭＡデジタル権限管理データに変換する。
【解決手段】ＤＲＭデータをインポートする方法はＤＲＭソリューションを通じて非ＯＭＡのＤＲＭデータをユーザードメインのためのＯＭＡのＤＲＭデータに変換させる。ローカル権限管理者（ＬＲＭ）をドメイン権限附与者または権限発行者に登録する段階と、ユーザードメイン情報を交換する段階、ユーザードメイン情報に基づいて非ＯＭＡのＤＲＭデータからＯＭＡのＤＲＭ標準に符合するＤＲＭコンテンツフォーマット（ＤＣＦ）と権限明示個体（ＲＯ）を生成する段階を含む。ＤＲＭデータを使用する方法は、ＬＲＭを登録する段階と、非ＯＭＡのＤＲＭデータからＯＭＡのＤＲＭ標準に符合するＤＣＦを生成する段階と、ＲＯを生成する段階と、ＤＣＦとＲＯをディバイスのＤＲＭエージェントに伝送する段階を含む。
【選択図】図６

Description

本発明はデジタル権限管理（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ、ＤＲＭ）に関するもので、より詳細にはモバイル応用ソフトウェア標準化団体のＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）に準じない非ＯＭＡデジタル権限管理データをＯＭＡデジタル権限管理データに変換するために、デジタル権限管理データをインポートする方法に関するものである。

マルチメディアコンテンツをユーザーに伝達できるデバイスの増加によって、ユーザーはネットワークに連結した家庭用メディアセンターの娯楽システム及びネットワーク連結性の程度を変化させるハンドヘルドデバイスのような、多数のデバイスに亘って制御または責任を所有、操作または維持できる。ハンドヘルドデバイスは移動電話機及び携帯用音楽再生機を含むことができる。ネットワーク連結性は、例えば移動電話機を通じた無線連結または個人用コンピュータを通じた有線広域インターネット連結を含むことができる。ユーザーはネットワーク連結を通じて一つのデバイス上で運営するためのマルチメディアコンテンツのようなコンテンツまたはプログラムを購買してダウンロードできる。

しかし、ユーザーは所有している他のデバイス上でそのようなコンテンツまたはプログラムを運営することを希望することもできる。したがって、モバイル応用ソフトウェア標準化団体のＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）が提案し、本明細書で参照として併合した、「ユーザードメイン」の概念を確立する、ＯＭＡのデジタル権限管理（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ、ＤＲＭ）の保安コンテンツ交換（Ｓｅｃｕｒｅ Ｃｏｎｔｅｎｔ Ｅｘｃｈａｎｇｅ、ＳＣＥ）要件（以後「ＯＭＡのＳＣＥ要件」と略称する）によって、ユーザーはユーザードメインを確立できる。ユーザードメインはユーザーが所有、運営、制御したり、ユーザーの責任である他のデバイスを含むことができる。ユーザーはユーザードメインにデバイスを付加でき、ユーザードメイン内で使用することができるコンテンツを得るためにユーザードメイン内の一つのデバイスを使用することができる。さらに、ユーザーはネットワーク連結を通じて、または保安移動可能媒体（Ｓｅｃｕｒｅ Ｒｅｍｏｖａｂｌｅ Ｍｅｄｉａ、ＳＲＭ）のようなデバイス間でコンテンツを伝達するのに適合した格納メモリを通じて、ユーザードメイン内のデバイス間でコンテンツを共有できる。選択的に、コンテンツがネットワーク連結を通じてストリーミングされるように、ユーザーはユーザードメイン内の他のデバイスとコンテンツをストリーミングするための権限確認を共有できる。このようなものは、例えば権限確認に関連したユーザートークンを共有することによって達成できる。

したがって、ユーザードメインはＤＲＭコンテンツを共有できるユーザーグループを指す。デバイスはユーザードメイン内のＤＲＭコンテンツを共有できる任意のデバイスを含むことができる。ユーザードメイン管理はユーザードメインにデバイスを付加したり、デバイスを除去するというような管理任務、及びドメイン政策のアプリケーションを含むことができる。

したがって、コンテンツ供給者はそのユーザーのユーザードメイン内におけるデバイス間でコンテンツのコピー及び使用を許容することができる。さらに、コンテンツ供給者はそのようなコンテンツの使用及びユーザードメイン外のデバイスに対する配布を制限及び／または禁止することができる。

ネットワーク連結を有するユーザードメイン内の一つのデバイスの運営を通じて、ユーザーはユーザードメインを生成することができる。例えば、ユーザーは可能なドメイン政策の目録を見るためのデバイスを運営することによって、ユーザードメインを生成できる。多様なドメイン政策を開発することができ、これらのうちいずれかをユーザーのために最も適切なものとしてユーザーは選択することができる。ＳＣＥイネイブラーは一つのユーザードメインに対してただ一つのドメイン政策だけを支援できる。ドメイン権限附与者（Ｄｏｍａｉｎ Ａｕｔｈｏｒｉｔｙ、ＤＡ）により発行されたユーザードメインのためのドメイン政策は、ユーザードメイン内のデバイスの最大数、コンテンツ使用に対する一時的制限またはコンテンツ使用の頻度のような制限を含むことができる。

ＤＡは選択したドメイン政策とドメインキー（Ｄｏｍａｉｎ Ｋｅｙ、ＤＫ）をユーザーデバイスに格納したドメイン執行エージェント（Ｄｏｍａｉｎ Ｅｎｆｏｒｃｅｍｅｎｔ Ａｇｅｎｔ、ＤＥＡ）に提供できる。デバイスはＤＥＡを通じてユーザーのユーザードメインを生成及び管理できる。

ユーザーはその後、他のデバイスをユーザードメインに付加できる。例えば、ユーザーは移動電話、携帯用音楽プレーヤー、及び家庭用メディアセンターをデバイスに連結し、これらのデバイスをユーザードメインに付加できる。ＤＡから発行したドメイン政策はユーザードメインに付加できるデバイスの総数を制限でき、ＤＥＡはユーザードメインに付加したデバイスの総数がこのような制限を超過することを予防する。

ユーザーがユーザードメインの権限明示個体（Ｒｉｇｈｔｓ Ｏｂｊｅｃｔ、ＲＯ）を有するコンテンツを獲得する時、ユーザーはこのようなコンテンツをユーザードメイン内のデバイス、またはユーザードメイン外のデバイスと共有することを希望できる。したがって、ユーザーは連結したデバイスをユーザードメイン内の他のデバイスに連結し、コンテンツの複製物とこれに相応するＲＯをユーザードメイン内の他のデバイスに伝達できる。

ＳＣＥイネイブラーは、ユーザードメイン内にあるデバイス上で権限の消費及びデバイス間の権限の伝達のための使用許容を詳述するために、権限発行者（ＲＩ）をイネーブルさせることができ、このような権限発行者はコンテンツ暗号キー（Ｃｏｎｔｅｎｔ Ｅｎｃｒｙｐｔｉｏｎ Ｋｅｙ、ＣＥＫ）をコンテンツ発行者と交換できる。使用許容はユーザードメイン内のデバイス間にコンテンツの再生、コピー、及び／または移動するための許容を含むことができる。ＳＣＥイネイブラーはまた、ユーザードメイン外のデバイス間の権限のための使用許容を詳述するためにＲＩをイネーブルさせることができる。使用許容はコンテンツをコピーしてユーザードメイン外のデバイスに移動させるための許容を含むことができる。選択的に、使用許容はユーザードメイン内のデバイスがコンテンツをコピーしてユーザードメイン外のデバイスに移動させることを禁止することもできる。

ＳＣＥイネイブラーはＤＥＡに対して、ＤＡが前述したドメイン政策によってドメイン政策を執行してユーザードメイン管理を行うように許容する。ユーザードメイン管理はユーザードメインにデバイスを付加したり、除去するなどといった管理業務と、ドメイン政策のアプリケーションを含むことができる。

したがって、ＯＭＡのＳＣＥ要件は、ユーザーがＲＩを通じてユーザードメイン管理を行う代わりに、直接ユーザードメイン管理を行うことができるように、「ユーザードメイン」の概念を導入した。したがって、ＯＭＡのＳＣＥ要件はまた、ドメイン政策を定義して記述することをＤＡで行うことができ、ドメイン政策の執行をＤＥＡで行うことができるように、ＤＡ及びＤＥＡの概念を導入した。ＤＡ及びＤＥＡは実体を分離したり、単一実体に統合することができる。

ＤＡはドメイン政策を定義して詳述でき、このようなドメイン政策をＤＥＡに伝達できる。ＤＥＡはＤＡからドメイン政策を受信することができ、受信したドメイン政策に基づいてユーザードメインを定義及び管理できる。すなわち、ＤＥＡにより生成したユーザードメインはまた、ＤＥＡにより管理する。仮りにＤＡとＤＥＡが単一実体に統合されると、ＤＡはユーザードメインを定義することができ、別のＤＥＡとインターフェースしなくてもドメイン管理を行うことができる。

図１はＯＭＡのＳＣＥ要件を示す概略図である。

参照のためここに併合し、ＯＭＡのＳＣＥ要件より時期的に早かった、伝統的なＯＭＡのＤＲＭ Ｖ２．０標準（以後、「ＯＭＡのＤＲＭ Ｖ２．０」と称する）とは異なり、ＯＭＡのＳＣＥは次の要件を含む。

（１）ローカル権限管理者（Ｌｏｃａｌ Ｒｉｇｈｔ Ｍａｎａｇｅｒ）によるインポート（Ｉｍｐｏｒｔ）機能；
（２）ＤＡとＤＥＡによるユーザードメイン機能；及び
（３）ＲＯを一つのデバイスから他のデバイスに移動させるための移動機能。

以後、インポート機能とユーザードメイン機能について詳細に説明する。

ＯＭＡのＳＣＥ要件はＬＲＭにより行うことができるインポート機能を提供する。インポート機能は非ＯＭＡのＤＲＭデータをＯＭＡのＤＲＭデータに変換することを指す。

例えば、ＯＭＡのＤＲＭと互換できるデバイスは非ＯＭＡのＤＲＭデータの再生を試みることができる。この場合、非ＯＭＡのＤＲＭデータはＯＭＡのＳＣＥ要件に従ってＬＲＭによりＯＭＡのＤＲＭデータに変換またはインポートしなければならない。したがって、ＬＲＭは非ＯＭＡのＤＲＭデータをＤＲＭコンテンツフォーマット（ＤＣＦ）にインポートし、ＯＭＡのＤＲＭのためのＲＯをインポートする。これらは、それぞれ「変換済みＤＣＦ」及び「変換済みＲＯ」と称する。ＯＭＡのＤＲＭを支援する変換済みＤＣＦと変換済みＲＯはＯＭＡのＳＣＥ要件によってＯＭＡのＤＲＭと互換できるデバイス内でＤＲＭエージェントが使用することができる。

前述したように、ユーザードメインは、伝統的なＯＭＡのＤＲＭ Ｖ２．０標準で確立したように、ユーザーが権限発行者（ＲＩ）を通じて各デバイスに対してユーザードメイン管理を行う代わりに、ユーザードメイン内に含まれた多数のデバイスのためにユーザードメイン管理を行うことを許容する。

しかし、伝統的なＯＭＡのＤＲＭ Ｖ２．０標準の他の特徴はＯＭＡのＳＣＥ要件と互換できる。例えば、ＯＭＡのＤＲＭ Ｖ２．０はディバイスがＲＯを獲得するために、４−パス登録プロトコルと２−パス権限明示個体（ＲＯ）獲得プロトコルを含む。

図２はＯＭＡのＤＲＭ Ｖ２．０に伴う４−パス登録プロトコルを示す。

４−パス登録プロトコルはデバイスとＲＩが互いに情報を交換し、互いに対して登録するために使用する。プロトコルが成功的であれば、デバイスはＲＩの情報を含むＲＩコンテクストを所有できて、ＲＩはデバイスの情報を所有できる。

４−パス登録プロトコルによって、デバイスはまずデバイス情報を含むDeviceHelloメッセージをＲＩに伝送する。DeviceHelloメッセージはデバイスのためのプロトコルバージョン、デバイスＩＤ、及び支援された暗号アルゴリズムを含むことができる。

ＲＩはＲＩ情報を含むＲＩHelloメッセージを第２段階でデバイスに伝送する。ＲＩHelloメッセージは伝送結果、セッションＩＤ、プロトコルバージョン、ＲＩのＩＤ、支援されたアルゴリズム、及び他の確認及びサーバー情報を含む。

デバイスはその後、第３段階でデバイスをＲＩに登録するためにRegistrationRequestメッセージをＲＩに伝送する。このRegistrationRequestメッセージはセッションＩＤ、メッセージ伝送時間、認証及び署名、及び臨時データのような確認データを含む。

ＲＩは最終的に、第４段階でRegistrationResponseメッセージをデバイスに伝送する。RegistrationResponseメッセージはデバイス登録結果、セッションＩＤ、ＲＩ認証／デジタル署名、及びオンライン認証状態プロトコル（Ｏｎｌｉｎｅ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｆｒｏｔｏｃｏｌ、ＯＣＳＰ）応答のような確認データを含む。ＯＣＳＰ応答は、より詳細に記述しない特定の付随的な事件に対してＲＩからＯＣＳＰ応答者に送ることができるＯＣＳＰ要請メッセージに対する応答で、ＲＩに送ることもできる。

図３はＯＭＡのＤＲＭ Ｖ２．０に伴う２−パスＲＯ獲得プロトコルを示す。

２−パスＲＯ獲得プロトコルは４−パス登録プロトコルに沿ってＲＯを獲得するために行う。４−パス登録プロトコルを行って得たＲＩコンテクストに基づいて、ディバイスはＲＯRequestメッセージをＲＩに伝送し、ＲＩからＲＯResponseメッセージを受信することによって、ＲＩからＲＯを受信する。付加的に、ＯＣＳＰ応答は特定付随的な事件に対してＲＩからＯＣＳＰ応答者に伝送したOCSPRequestメッセージに応答してＲＩに伝送できる。

付加的に、ディバイスは対応するユーザードメインに登録できる。図４はＯＭＡのＤＲＭ Ｖ２．０に伴う２−パスドメイン加入（ｊｏｉｎ ｄｏｍａｉｎ）プロトコルを示す。

２−パスドメイン加入プロトコルはドメインに基づいたＲＯを使用するために、ＯＭＡのＤＲＭ Ｖ２．０を支援するディバイスで使用する。この場合、ディバイスは２−パスドメイン加入プロトコルを使用して対応するドメインに加入した後、ドメインに基づいたＲＯを使用することができる。２−パスドメイン加入プロトコルは一般的に４−パス登録プロトコルが発生した後にだけ運営される。一旦加入すれば、ディバイスは図５に示した過程を通じてＲＯを使用することができる。

図５はＯＭＡのＤＲＭ Ｖ２．０に伴うディバイスを通じてＲＯを使用する方法を示す。

第１段階において、ディバイスＤ１、Ｄ２及びＤ３は図２に示した４−パス登録プロトコルと、図４に示した２−パスドメイン加入プロトコルを使用してドメインに加入する。第２段階において、ディバイスＤ１は図３に示した２−パスＲＯ獲得プロトコルを通じてＲＩからＲＯを獲得する。第３段階で獲得したＲＯはディバイスＤ１からディバイスＤ２及びＤ３に伝送する。ディバイスＤ２及びＤ３がディバイスＤ１と同一なドメインに加入するために、ディバイスＤ２及びＤ３はディバイスＤ１から受信したＲＯを使用することができる。第４段階において、ディバイスＤ１はＲＯを、ディバイスＤ１と同一なドメインに加入しないディバイスＤ４に伝送する。ディバイスＤ４はドメインに加入しなかったため、４第５段階で２−パスドメイン加入プロトコルを通じてドメインに加入し、ディバイスＤ１から受信したＲＯを使用する。

しかし、ＯＭＡのＳＣＥ要件はＬＲＭによる非ＯＭＡのＤＲＭデータをＯＭＡのＤＲＭデータでにインポート及び変換する方法、またはユーザードメインに属したＤＲＭエージェントが変換済みＯＭＡのＤＲＭデータを使用する方法を含んでいない。

本発明は非ＯＭＡのＤＲＭデータをＯＭＡのＤＲＭデータに変換するためにＤＲＭデータをインポートする方法を提供する。

また、本発明はＤＡまたはＲＩからＤＲＭエージェントにより変換済みＤEＲＯを獲得することによって、変換済みＤEＤＲＭデータを使用する方法を提供する。

本発明の追加的な特徴は次の詳細な説明で明確になり、部分的には以下の説明から明白になるか、または本発明の実施形態を通じて理解できる。

前述の目的を達成するための本発明に係るデジタル権限管理（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ、ＤＲＭ）データをインポートする方法は、ローカル権限管理者（Ｌｏｃａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ、ＬＲＭ）をドメイン権限附与者（Ｄｏｍａｉｎ Ａｕｔｈｏｒｉｔｙ、ＤＡ）に登録する段階と、ユーザードメイン情報を交換する段階と、ユーザードメイン情報に基づいて、モバイル応用ソフトウェア標準化団体のＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）に準じない非ＯＭＡのＤＲＭデータから、ＯＭＡのＤＲＭ標準に符合するＤＲＭコンテンツフォーマット（ＤＲＭ Ｃｏｎｔｅｎｔ Ｆｏｒｍａｔ、ＤＣＦ）と権限明示個体（Ｒｉｇｈｔｓ Ｏｂｊｅｃｔ、ＲＯ）を生成する段階と、を含むことを特徴とする。

また、本発明に係るデジタル権限管理（ＤＲＭ）データを使用する方法は、ローカル権限管理者（ＬＲＭ）をドメイン権限附与者（ＤＡ）に登録する段階と、ユーザードメイン情報を交換する段階と、ユーザードメイン情報に基づいて、モバイル応用ソフトウェア標準化団体の（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）に準じない非ＯＭＡのＤＲＭデータから、ＯＭＡのＤＲＭ標準に符合するＤＲＭコンテンツフォーマット（ＤＣＦ）を生成する段階と、を含むことを特徴とする。

また、本発明に係るデジタル権限管理（ＤＲＭ）をインポートする方法は、ローカル権限管理者（ＬＲＭ）を権限発行者（ＲＩ）に登録する段階と、ユーザードメイン情報を交換する段階と、ユーザードメイン情報に基づいて、モバイル応用ソフトウェア標準化団体のＯＭＡに準じない非ＯＭＡのＤＲＭデータから、ＯＭＡのＤＲＭ標準に符合するＤＲＭコンテンツフォーマット（ＤＣＦ）と権限明示個体（ＲＯ）を生成する段階と、を含むことを特徴とする。

さらに、本発明に係るデジタル権限管理（ＤＲＭ）データを使用する方法は、ローカル権限管理者（ＬＲＭ）をドメイン権限発行者（ＲＩ）に登録する段階と、ユーザードメイン情報を交換する段階と、ユーザードメイン情報に基づいて、モバイル応用ソフトウェア標準化団体のＯＭＡに準じない非ＯＭＡのＤＲＭデータから、ＯＭＡのＤＲＭ標準に符合するＤＲＭコンテンツフォーマット（ＤＣＦ）を生成する段階と、ユーザードメインのための権限明示個体（ＲＯ）を生成する段階と、ドメイン権限附与者（ＤＡ）と前記ＲＩとの間で前記ユーザードメイン情報を交換する段階と、前記ＤＣＦを前記ＬＲＭからディバイスのＤＲＭエージェントに伝送する段階と、を含むことを特徴とする。

本発明の追加的な特徴は次の詳細な説明で明確になり、部分的には以下の説明から明白になるか、または本発明の実施形態を通じて理解できる。

本発明によれば、ＯＭＡのＤＲＭ標準を支援するディバイスを通じて非ＯＭＡのＤＲＭデータを再生することが可能である。

さらに、仮りに非ＯＭＡのＤＲＭデータがＯＭＡのＤＲＭデータに変換される場合、ＤＲＭエージェントはＬＲＭから直接だけでなく、ＲＩからも変換されたＲＯを獲得できる。

本発明の例示的な実施形態を示す添付図面を参照してさらに詳細に説明する。しかし、本発明は他の多くの形態に実行することができ、本明細書で説明する例示的な実施形態に制限されないと解釈しなければならない。むしろ、これらの例示的な実施形態は本明細書が徹底的に本発明の範疇を当業者に完全に伝達するように提供する。図面において、層及び領域の大きさ及び相対的な大きさは明確性のために誇張されることがある。図面で類似の番号は類似要素を示す。

以下、本発明の本例示的な実施形態に係るＯＭＡのＤＲＭデータをインポートする方法を説明する。本発明のこの例示的な実施形態に係るＯＭＡのＤＲＭデータをインポートする方法は、ＯＭＡのＤＲＭ Ｖ２．０標準で詳細に説明したプロトコルと同様の方式で運営するプロトコルを使用する。

図６は本発明の例示的な実施形態によって非ＯＭＡのＤＲＭデータをユーザードメインのためのＯＭＡのＤＲＭデータにインポートする方法を示す。より詳細に、図６はユーザードメインに属したディバイスのＤＲＭエージェント５０がＯＭＡのＤＲＭデータを使用することができるようにローカル権限管理者（Ｌｏｃａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ、ＬＲＭ）１０により非ＯＭＡのＤＲＭデータをユーザードメインのためのＯＭＡのＤＲＭデータにインポートする方法を示す。

第１段階において、運営ステップＳ１００でＬＲＭ１０とドメイン権限附与者（Ｄｏｍａｉｎ Ａｕｔｈｏｒｉｔｙ、ＤＡ）２０との間で登録手順を行う。登録はＬＲＭ１０がまずユーザードメインのためのインポート機能を行う時、処理できる。付加的に、登録が満了する場合、登録を行うことができる。より詳細に、登録段階は相互確認／キー交換、及び事後−登録通信のための多数のパラメーターの相互交換／確認を行う。登録手順はＬＲＭ１０とＤＡ２０との間で４−パス登録プロトコルを使用して実行できる。すなわち、登録段階は多数のメッセージ交換を通じて実行できる。

第２段階において、ユーザードメイン情報は運営ステップＳ１０２で交換する。ユーザードメイン情報はＬＲＭ１０により非ＯＭＡのＤＲＭデータをＤＡ２０に関連したユーザードメインのためのＯＭＡのＤＲＭデータに変換するために交換する。

仮りに既存ユーザードメインのためのＯＭＡのＤＲＭデータが必要であればＬＲＭ１０はＤＡ２０からユーザードメインに対する情報を受信する。

ユーザードメインが存在しない場合、ＯＭＡのＤＲＭデータのためのユーザードメインがＤＡ２０を通じて割り当てられ、ユーザードメインに関する情報はＬＲＭ１０に伝送される。ユーザードメイン情報の交換手順は多数のメッセージ交換を通じて実行できる。

第３段階において、運営ステップＳ１０４でＤＲＭコンテンツフォーマット（ＤＣＦ）を生成するためにインポート−準備データが受信される。インポート−準備データはＯＭＡのＤＲＭデータに変換される非ＯＭＡのＤＲＭデータを言う。データを受信して変換する方法はＬＲＭ１０によりＤＲＭに関連したコンテンツを受信して変換する任意の方法であることができる。

ユーザードメインのためのＤＣＦへの変換のためにインポート−準備データを受信する時、ＬＲＭ１０がユーザードメインに対する不充分な情報を有する場合、前述したユーザードメイン情報交換手順を行うことができる。

第４段階において、ユーザードメインのためのＲＯが運営ステップＳ１０６及び運営ステップＳ１０８でＤＣＦから生成される。ＬＲＭ１０は運営ステップＳ１０６でCreatRORequestメッセージを権限発行者（Ｒｉｇｈｔｓ Ｉｓｓｕｅｒ、ＲＩ）４０に伝送する。ＲＩ４０は運営ステップＳ１０８でCreatROResponseメッセージをＬＲＭ１０に伝送する。

これらの運営ステップ途中に、ＲＩ４０とＬＲＭ１０は権限承認に関する情報とＲＯに含まれる制限事項を交換し、ＤＣＦを生成する時使用したキーとＲＯ生成と安全な通信のためのデータを交換する。結果的に、ＲＩ４０はユーザードメインのためのＲＯを生成し、ＬＲＭ１０の要請時ＲＯをＬＲＭ１０に伝送できる。しかし、ＲＩ４０はＲＯが生成された以後にはＲＯをＬＲＭ１０に伝送しなくなる。

ＲＩ４０がＲＯを生成するためにユーザードメイン情報を使用するために、第４段階でユーザードメイン情報はＬＲＭ１０とＲＩ４０との間で交換する。ユーザードメイン情報はＲＯを生成するためのキーに関連したデータ交換のための情報を含む。

第５段階において、ＬＲＭ１０は運営ステップＳ１１０で生成したＤＣＦをＤＲＭエージェント５０に伝送する。

第６段階において、ＤＲＭエージェント５０は運営段階Ｓ１１２でＤＣＦを使用するためにユーザードメインに加入する。ＤＲＭエージェント５０が第６段階以前にユーザードメインに加入した場合は、この段階を含んでいない。

第７段階において、運営ステップＳ１１４でＲＯを獲得するためにＲＯ獲得手順を行う。ＲＯ獲得段階は図３に示すように多数のメッセージ交換を通じて実行できる。しかし、第７段階はＲＯがＬＲＭ１０から受信する場合は不要である。付加的に、仮りにＤＲＭエージェント５０がユーザードメインのためのＲＯを獲得する時、ユーザードメインに加入しなかった場合、第６段階はＲＯを使用する前に行うことができる。

図７は本発明の他の例示的な実施形態によって非ＯＭＡのＤＲＭデータをユーザードメインのためのＯＭＡのＤＲＭデータにインポートする方法を示す。この例示的な実施形態は運営ステップＳ２０８及び運営ステップＳ２１０でＤＡ２０とＲＩ４０との間でメタ情報またはユーザードメイン情報を交換する段階を含む。

第１段階において、ＬＲＭ１０とＲＩ４０との間の登録手順は運営ステップＳ２００で行う。登録はＬＲＭ１０がまずユーザードメインのためのインポート機能を行う時、処理できる。付加的に、登録が満了する場合、登録を行うことができる。より詳細に、登録段階は相互確認／キー交換、及び事後登録通信のために多数パラメーターの相互交換／確認を行う。登録手順はＬＲＭ１０とＲＩ４０との間で４−パス登録プロトコルを使用して実行できる。すなわち、登録段階は多数のメッセージ交換を通じて実行する。

第２段階において、インポート−準備データは運営ステップＳ２０２でＤＣＦを生成するためにＬＲＭ１０に受信される。インポート−準備データはＯＭＡのＤＲＭデータに変換される非ＯＭＡのＤＲＭデータを言う。データを受信して変換する方法はＬＲＭ１０によりＤＲＭに関連したコンテンツを受信して変換する任意の方法であることができる。

第３段階において、運営ステップＳ２０４でＤＣＦを生成する。第４段階でＬＲＭ１０は運営ステップＳ２０６でCreatRORequestメッセージをＲＩ４０に伝送する。第５段階において、ＲＩ４０は運営ステップＳ２０８でＤＡ２０からユーザードメイン情報の伝送を要請するためにUserDomainRequestメッセージをＤＡ２０に伝送する。第６段階において、ＤＡ２０は運営ステップＳ２１０でユーザードメイン情報を有するUserDomainResponseメッセージをＲＩ４０に伝送する。

前述したように、第５段階と第６段階に先に行うことができる、ＲＩ４０とＤＡ２０を登録する方法は代理人管理番号Ｐ２１９７ＵＳ００を有する特許出願で開示、及び請求しており、この出願は本出願と同時に出願して、本出願の譲受人に譲渡した。

第７段階において、ＲＩ４０はユーザードメイン情報によってＲＯを生成し、運営ステップＳ２１２でCreatROResponseメッセージをＬＲＭ１０に伝送する。ＲＩ４０はまた運営ステップＳ２１２でＲＯをＬＲＭ１０に伝送できる。

第８段階において、ＬＲＭ１０は運営ステップＳ２１４でＤＣＦとＲＯをＤＲＭエージェント５０に伝送する。したがって、以前の例示的な実施形態とは対照的に、ＤＲＭエージェント５０はＲＩ４０でなくＬＲＭ１０からＲＯを受信する。

第９段階において、ＤＲＭエージェント５０は運営ステップＳ２１６でユーザードメインに加入してＤＣＦを使用するためにJoinDomainRequestメッセージをＤＡ２０に伝送し、第１０段階において、ＤＡ２０は運営ステップＳ２１８でJoinDomainResponseメッセージをＤＲＭエージェント５０に伝送する。ＤＲＭエージェント５０が既にユーザードメインに加入した場合は、第９段階と第１０段階を含んでいないこともある。

図８は本発明のもう一つの例示的な実施形態によって非ＯＭＡのＤＲＭデータをユーザードメインのためのＯＭＡのＤＲＭデータにインポートする方法を示す。第１段階、第２段階、第３段階、第４段階、第５段階、第６段階及び第７段階は図７に対して前述した段階と同様であるか、ほとんど似ている。

第８段階において、ＤＣＦはＬＲＭ１０からＤＲＭエージェント５０に伝送される。しかし伝送したＤＣＦに関連したＲＯはＤＲＭエージェント５０に伝送されない。したがって、ＤＣＦを使用するために、第１１段階でＲＯ獲得手順が図８に示すように含まれる。ＲＯ獲得段階は図３に対して説明したように実行できる。仮りにＲＯが獲得される時、ＤＲＭエージェント５０がユーザードメインに加入しなかった場合は、図７に対して説明したように第９段階及び第１０段階がＲＯを使用する前に行うことができる。

前述したＤＲＭデータをインポートするための例示的な実施形態は多様な変更が可能である。

例えば、図６の第２段階は図６の第３段階以後に行うことができる。

さらに、図６の第６段階と図７と図８の第９段階及び第１０段階は、現ディバイスのＤＲＭエージェント５０が既にユーザードメインに加入した場合は、省略できる。

付加的に、図６の第７段階と図８の第１１段階は、ＲＯが初期段階でＤＣＦと共に伝送された場合は、省略できる。

さらに、ドメイン加入手順はＲＯ獲得手順以後に行うことができる。

本発明によれば、以上の説明から明白であるように、ＯＭＡのＤＲＭ標準を支援するディバイスを通じて非ＯＭＡのＤＲＭデータを再生することが可能である。

さらに、仮りに非ＯＭＡのＤＲＭデータがＯＭＡのＤＲＭデータに変換される場合、ＤＲＭエージェントはＬＲＭから直接だけでなく、ＲＩからも変換されたＲＯを獲得できる。従って、本発明の産業利用性はきわめて高いものといえる。

一方、本明細書内で本発明をいくつかの好ましい実施形態によって記述したが、当業者ならば、添付の特許請求範囲に開示した本発明の範疇及び思想から外れずに、多くの変形及び修正がなされ得ることがわかるはずである。

ＯＭＡのＳＣＥ要件を示す概略図である。 ＯＭＡのＤＲＭ Ｖ２．０に伴う４−パス登録プロトコルを示す図面である。 ＯＭＡのＤＲＭ Ｖ２．０に伴う２−パスＲＯ獲得プロトコルを示す図面である。 ＯＭＡのＤＲＭ Ｖ２．０に伴う２−パスドメイン加入プロトコルを示す図面である。 ＯＭＡのＤＲＭ Ｖ２．０に伴うディバイスによりＲＯを使用する方法を示す図面である。 本発明の例示的な実施形態によって非ＯＭＡのＤＲＭデータをユーザードメインのためのＯＭＡのＤＲＭデータにインポートする方法を示す図面である。 本発明の他の例示的な実施形態によって非ＯＭＡのＤＲＭデータをユーザードメインのためのＯＭＡのＤＲＭデータにインポートする方法を示す図面である。 本発明のもう一つの例示的な実施形態によって非ＯＭＡのＤＲＭデータをユーザードメインのためのＯＭＡのＤＲＭデータにインポートする方法を示す図面である。

符号の説明

１０ ローカル権限管理者（ＬＲＭ）
２０ ドメイン権限附与者（ＤＡ）
４０ 権限発行者（ＲＩ）
５０ ＤＲＭエージェント

Claims (19)

1. デジタル権限管理（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ、ＤＲＭ）データをインポートする方法であって、
   ローカル権限管理者（Ｌｏｃａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ、ＬＲＭ）をドメイン権限附与者（Ｄｏｍａｉｎ Ａｕｔｈｏｒｉｔｙ、ＤＡ）に登録する段階と、
   ユーザードメイン情報を交換する段階と、
   ユーザードメイン情報に基づいて、モバイル応用ソフトウェア標準化団体のＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）に準じない非ＯＭＡのＤＲＭデータから、ＯＭＡのＤＲＭ標準に符合するＤＲＭコンテンツフォーマット（ＤＲＭ Ｃｏｎｔｅｎｔ Ｆｏｒｍａｔ、ＤＣＦ）と権限明示個体（Ｒｉｇｈｔｓ Ｏｂｊｅｃｔ、ＲＯ）を生成する段階と、を含むことを特徴とするデジタル権限管理データをインポートする方法。
2. 前記ユーザードメイン情報を交換する段階は、非ＯＭＡのＤＲＭデータからユーザードメインのためのＤＲＭデータを獲得するためにメタ（ｍｅｔａ）情報を交換する段階を含むことを特徴とする請求項１に記載のデジタル権限管理データをインポートする方法。
3. 前記登録段階は、
   ＬＲＭ情報を前記ＤＡに伝送する段階と、
   ＤＡ情報を前記ＬＲＭに伝送する段階と、
   前記ＤＡ情報に基づいて登録情報を生成し、前記登録情報を前記ＤＡに伝送する段階と、
   前記登録情報に基づいてＬＲＭを登録し、登録結果を前記ＬＲＭに伝送する段階を含むことを特徴とする請求項１に記載のデジタル権限管理データをインポートする方法。
4. デジタル権限管理（ＤＲＭ）データを使用する方法であって、
   ローカル権限管理者（ＬＲＭ）をドメイン権限附与者（ＤＡ）に登録する段階と、
   ユーザードメイン情報を交換する段階と、
   ユーザードメイン情報に基づいて、モバイル応用ソフトウェア標準化団体の（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）に準じない非ＯＭＡのＤＲＭデータから、ＯＭＡのＤＲＭ標準に符合するＤＲＭコンテンツフォーマット（ＤＣＦ）を生成する段階と、を含むことを特徴とするデジタル権限管理データを使用する方法。
5. ＤＲＭエージェントを通じて前記ユーザードメインのためのＲＯを獲得する段階をさらに含むことを特徴とする請求項４に記載のデジタル権限管理データを使用する方法。
6. 前記ＲＯを権限発行者（Ｒｉｇｈｔｓ Ｉｓｓｕｅｒ、ＲＩ）から前記ＬＲＭに伝送する段階をさらに含むことを特徴とする請求項４に記載のデジタル権限管理データを使用する方法。
7. 前記ＤＲＭエージェントは、前記ＬＲＭまたは前記ＲＩから前記ＲＯを獲得することを特徴とする請求項５に記載のデジタル権限管理データを使用する方法。
8. 前記登録段階は、
   ＬＲＭ情報を前記ＤＡに伝送する段階と、
   ＤＡ情報を前記ＬＲＭに伝送する段階と、
   前記ＤＡ情報に基づいて登録情報を生成し、前記登録情報を前記ＤＡに伝送する段階と、
   前記登録情報に基づいてＬＲＭを登録し、登録結果を前記ＬＲＭに伝送する段階と、を含むことを特徴とする請求項４に記載のデジタル権限管理データを使用する方法。
9. 前記ＤＲＭエージェントを前記ユーザードメインに加入させるために、前記ＤＲＭエージェントからドメイン加入要請メッセージを伝送する段階をさらに含むことを特徴とする請求項４に記載のデジタル権限管理データを使用する方法。
10. デジタル権限管理（ＤＲＭ）をインポートする方法であって、
    ローカル権限管理者（ＬＲＭ）を権限発行者（ＲＩ）に登録する段階と、
    ユーザードメイン情報を交換する段階と、
    ユーザードメイン情報に基づいて、モバイル応用ソフトウェア標準化団体のＯＭＡに準じない非ＯＭＡのＤＲＭデータから、ＯＭＡのＤＲＭ標準に符合するＤＲＭコンテンツフォーマット（ＤＣＦ）と権限明示個体（ＲＯ）を生成する段階と、を含むことを特徴とするデジタル権限管理データをインポートする方法。
11. 前記ユーザードメイン情報を交換する段階は、非ＯＭＡのＤＲＭデータからユーザードメインのためのＤＲＭデータを獲得するためにメタ（meta）情報を交換する段階を含むことを特徴とする請求項１０に記載のデジタル権限管理データをインポートする方法。
12. 前記登録段階は、
    ＬＲＭ情報を前記ＲＩに伝送する段階と、
    ＲＩ情報を前記ＬＲＭに伝送する段階と、
    前記ＲＩ情報に基づいて登録情報を生成し、前記登録情報を前記ＲＩに伝送する段階と、
    前記登録情報に基づいてＬＲＭを登録し、登録結果を前記ＬＲＭに伝送する段階と、を含むことを特徴とする請求項１０に記載のデジタル権限管理データをインポートする方法。
13. デジタル権限管理（ＤＲＭ）データを使用する方法であって、
    ローカル権限管理者（ＬＲＭ）をドメイン権限発行者（ＲＩ）に登録する段階と、
    ユーザードメイン情報を交換する段階と、
    ユーザードメイン情報に基づいて、モバイル応用ソフトウェア標準化団体のＯＭＡに準じない非ＯＭＡのＤＲＭデータから、ＯＭＡのＤＲＭ標準に符合するＤＲＭコンテンツフォーマット（ＤＣＦ）を生成する段階と、
    ユーザードメインのための権限明示個体（ＲＯ）を生成する段階と、
    ドメイン権限附与者（ＤＡ）と前記ＲＩとの間で前記ユーザードメイン情報を交換する段階と、
    前記ＤＣＦを前記ＬＲＭからディバイスのＤＲＭエージェントに伝送する段階と、を含むことを特徴とするデジタル権限管理データを使用する方法。
14. 前記ＤＡと前記ＲＩとの間でユーザードメイン情報を交換する段階は、前記非ＯＭＡのＤＲＭデータからユーザードメインのためのＤＲＭデータを獲得するためにメタ情報を交換する段階を含むことを特徴とする請求項１３に記載のデジタル権限管理データを使用する方法。
15. ＤＲＭエージェントを通じて前記ユーザードメインのためのＲＯを獲得する段階をさらに含むことを特徴とする請求項１３に記載のデジタル権限管理データを使用する方法。
16. 前記ＤＲＭエージェントは前記ＲＩまたは前記ＬＲＭから前記ＲＯを獲得することを特徴とする請求項１５に記載のデジタル権限管理データを使用する方法。
17. 前記ＲＯを前記ＲＩから前記ＬＲＭに伝送する段階をさらに含むことを特徴とする請求項１３に記載のデジタル権限管理データを使用する方法。
18. 前記登録段階は、
    ＬＲＭ情報を前記ＲＩに伝送する段階と、
    ＲＩ情報を前記ＬＲＭに伝送する段階と、
    前記ＲＩ情報に基づいて登録情報を生成し、前記登録情報を前記ＲＩに伝送する段階と、
    前記登録情報に基づいてＬＲＭを登録し、登録結果を前記ＬＲＭに伝送する段階と、を含むことを特徴とする請求項１３に記載のデジタル権限管理データを使用する方法。
19. 前記ＤＲＭエージェントを前記ユーザードメインに加入させるために、前記ＤＲＭエージェントからドメイン加入要請メッセージを伝送する段階をさらに含むことを特徴とする請求項１３に記載のデジタル権限管理データを使用する方法。

Images