JP2004259281A - ディジタル権利管理（ｄｒｍ）サーバのｄｒｍアーキテクチャへのエンロール／サブエンロール - Google Patents

Abstract

【課題】 ディジタルコンテンツのレンダリングまたはプレイを可能にし、コンテンツオーナー／デベロッパによって定義する方法を提供する。
【解決手段】 ディジタル権利管理（ＤＲＭ）機能性を実行する複数のＤＲＭサーバを有し、エンターするＤＲＭ−Ｅサーバが、ＤＲＭ−Ｒサーバによってシステムにエンロールされ、システム内で信頼されるようになる。ＤＲＭ−Ｅサーバは、識別子および公開キー（ＰＵ−Ｅ）を含むエンロールメント要求をＤＲＭ−Ｒサーバに送る。ＤＲＭ−Ｒサーバは、識別子を検証し、ＤＲＭ−ＥサーバをＤＲＭシステムにエンロールするために、ＤＲＭ−Ｅサーバに関する（ＰＵ−Ｅ）を用いてディジタルエンロールメント証明書を生成する。エンロールされたＤＲＭ−Ｅサーバは、これを使用して、ＤＲＭシステム内でＤＲＭドキュメントを発行する。
【選択図】 図１３

Description

本発明は、ディジタル権利管理（ｄｉｇｉｔａｌ ｒｉｇｈｔｓ ｍａｎａｇｅｍｅｎｔ、ＤＲＭ）システムに関する。具体的には、本発明は、オフィスまたは会社または類似物などの組織内のコンテンツのレンダリングおよび使用を、対応する使用条件またはライセンス条件に従って制約できるようにする、組織内のディジタルコンテンツのパブリッシュ（ｐｕｂｌｉｓｈ）へのＤＲＭシステムの使用に関する。さらに具体的には、本発明は、そのようなＤＲＭシステムを実現するＤＲＭサーバのネットワークおよびネットワークへのＤＲＭサーバのエンロールまたはサブエンロールの方法に関する。

ディジタル権利管理およびディジタル権利実施は、ディジタルオーディオ、ディジタルビデオ、ディジタルテキスト、ディジタルデータ、ディジタルマルチメディアなどのディジタルコンテンツに関連して、そのようなディジタルコンテンツが１つまたは複数のユーザに配布される場合に非常に望ましい。ディジタルコンテンツは、たとえばテキストドキュメントなどの静的なディジタルコンテンツ、または生イベントのストリーミングオーディオ／ビデオなどのストリーミングされるディジタルコンテンツとすることができる。配布の通常の態様には、磁気（フロッピー（登録商標））ディスク、磁気テープ、光学（コンパクト）ディスク（ＣＤ）などの有形のデバイス、および電子掲示板、電子ネットワーク、インターネットなどの無形メディアが含まれる。ユーザによる受信の際に、そのようなユーザは、パーソナルコンピュータ上のメディアプレイヤまたは類似物などの適当なレンダリングデバイスの助けを得てディジタルコンテンツをレンダリングまたは「プレイ」する。

１つのシナリオでは、著作者、出版社、放送会社などのコンテンツオーナーまたは権利オーナーが、ライセンス料またはなんらかの他の報酬と交換で多数のユーザまたは受取人のそれぞれにそのようなディジタルコンテンツを配布することを望む。そのようなシナリオでは、コンテンツが、曲、曲のアルバム、ムービーなどである可能性があり、配布の目的が、ライセンス料を生成するためである。そのようなコンテンツオーナーは、選択肢を与えられた場合に、そのような配布されるディジタルコンテンツに関してユーザが行うことができることを制限することを望みたがる。たとえば、コンテンツオーナーは、少なくともコンテンツオーナーが第２ユーザからのライセンス料を拒否する形で、ユーザが第２ユーザへのそのようなコンテンツのコピーおよび再配布を行うことを制限したがる。

さらに、コンテンツオーナーは、異なるライセンス料で異なるタイプの使用ライセンスを購入する柔軟性をユーザに提供すると同時に、実際にどのタイプのライセンスが購入されたかに関してユーザを拘束することを望む可能性がある。たとえば、コンテンツオーナーは、配布されるディジタルコンテンツを、限られた回数だけ、あるトータル時間だけ、あるタイプのマシンでのみ、あるタイプのメディアプレイヤでのみ、あるタイプのユーザによってのみ、などでプレイできるようにすることを望む可能性がある。

もう１つのシナリオでは、組織の従業員またはメンバなどのコンテンツデベロッパが、そのようなディジタルコンテンツを、組織内の１つまたは複数の他の従業員またはメンバ、あるいは組織外の他の個人に配布することを望むが、他者がそのコンテンツをレンダリングできなくすることを望む。この場合に、そのコンテンツの配布は、ライセンス料またはなんらかの他の報酬と交換のブロードベースの配布ではなく、秘密の形または制限された形での組織ベースのコンテンツ共有により類似する。

したがって、そのようなシナリオにおいて、コンテンツを、オフィスセッティング内で交換することができるドキュメントプレゼンテーション、スプレッドシート、データベース、電子メール、または類似物などのドキュメントプレゼンテーション、スプレッドシート、データベース、電子メール、または類似物とすることができ、コンテンツデベロッパは、コンテンツが、組織またはオフィスセッティング内に留まり、たとえば競争者または反対者など、許可されない個人によってレンダリングされないことを保証することを望む可能性がある。やはり、そのようなコンテンツデベロッパは、受取人がそのように配布されるディジタルコンテンツに関して行うことができることを制限することを望む。たとえば、コンテンツオーナーは、少なくともコンテンツをレンダリングすることを許可されなければならない個人の範囲の外にコンテンツが露出される形で、ユーザがそのようなコンテンツをコピーし、第２ユーザに再配布することを制限したがる。

さらに、コンテンツデベロッパは、さまざまな受取人に異なるレベルのレンダリング権利を与えることを望む可能性がある。たとえば、コンテンツデベロッパは、あるクラスの個人に関してプロテクトされたディジタルコンテンツを表示可能にするが、印刷可能にせず、別のクラスの個人に関して表示可能であり印刷可能にできるようにすることを望む可能性がある。

しかし、どちらのシナリオにおいても、配布が行われた後に、そのようなコンテンツのオーナー／デベロッパは、ディジタルコンテンツに対する制御を、あるとしてもごくわずかだけ有する。これは、実用上すべてのパーソナルコンピュータに、そのようなディジタルコンテンツの正確なディジタルコピーを行い、そのような正確なディジタルコピーを書き込み可能磁気ディスクまたは書き込み可能光学ディスクにダウンロードし、またはインターネットなどのネットワークを介して任意の宛先へそのような正確なディジタルコピーを送信するのに必要なソフトウェアおよびハードウェアが含まれるという事実に鑑みて、特に問題である。

もちろん、コンテンツが配布されるトランザクションの一部として、コンテンツのオーナー／デベロッパは、ディジタルコンテンツのユーザ／受取人が、歓迎されない形でそのようなディジタルコンテンツを再配布しないことを約束することを要求することができる。しかし、そのような約束は、簡単になされ、簡単に破られる。コンテンツのオーナー／デベロッパは、通常は暗号化および暗号化解除が用いられる、複数の既知のセキュリティデバイスのいずれかを介してそのような再配布を防ぐことを試みることができる。しかし、穏やかに決心したユーザが、暗号化されたディジタルコンテンツを暗号解除し、そのようなディジタルコンテンツを暗号化されない形態で保存し、その後、これを再配布することを防ぐことの可能性は非常に低い。

任意の形態のディジタルコンテンツの制御されたレンダリングまたはプレイを可能にし、そのような制御が、柔軟であり、そのようなディジタルコンテンツのコンテンツオーナー／デベロッパによって定義可能である、ディジタル権利管理（ＤＲＭ）およびディジタル権利実施アーキテクチャならびにディジタル権利管理（ＤＲＭ）およびディジタル権利実施方法の必要が存在する。具体的には、特にドキュメントが個人の定義されたグループまたは個人のクラスの間で共有されるオフィスまたは組織環境あるいは類似物での、そのような制御されたレンダリングを可能にし、促進するアーキテクチャの必要が存在する。さらに具体的には、承認を付与するサーバのアーキテクチャへのエンロールの方法の必要が存在する。

前述の必要は、ディジタル権利管理（ＤＲＭ）システムが、ＤＲＭ機能性を実行する複数のＤＲＭサーバを有し、エンターするＤＲＭ−Ｅサーバがシステム内で信頼されるように、エンターするＤＲＭ−ＥサーバがエンロールするＤＲＭ−Ｒサーバによってシステムにエンロールされる本発明によって少なくとも部分的に満足される。本発明では、ＤＲＭ−Ｅサーバが、ＤＲＭシステム内でそのようなＤＲＭ−Ｅサーバを識別する公開／秘密キー対（ＰＵ−Ｅ、ＰＲ−Ｅ）を獲得し、その提供する識別を獲得し、提供する識別および（ＰＵ−Ｅ）を含むエンロールメント要求をＤＲＭ−Ｒサーバに送る。

ＤＲＭ−Ｒサーバは、提供する識別を検証し、要求が尊重される場合に、そのようなＤＲＭ−ＥサーバをＤＲＭシステムにエンロールするために、ＤＲＭ−Ｅサーバのディジタルエンロールメント証明書を生成する。生成されるエンロールメント証明書は、少なくとも部分的に（ＰＵ−Ｅ）に基づく。ＤＲＭ−Ｒサーバは、要求するＤＲＭ−Ｅサーバに生成されたエンロールメント証明書を返し、現在、エンロールされているＤＲＭ−Ｅサーバは、返されたエンロールメント証明書を、将来の使用のために適当な位置に保管する。エンロールメント証明書を有するＤＲＭ−Ｅサーバは、これを使用してＤＲＭシステム内でＤＲＭドキュメントを発行することができる。

前述の要約ならびに以下の本発明の実施形態の詳細な説明は、添付図面と共に読まれる場合によりよく理解される。本発明の例示において、図面に、現在好ましい実施形態を示す。しかし、理解されるように、本発明は、図示の正確な配置および手段に限定されない。

コンピュータ環境
図１および以下の説明は、本発明を実施することができる適切なコンピューティング環境の短い全般的な説明を提供することを意図されている。しかし、ハンドヘルドコンピューティングデバイス、ポータブルコンピューティングデバイス、およびすべての種類の他のコンピューティングデバイスが、本発明と共に使用されることを企図されていることを理解されたい。汎用コンピュータを下で説明するが、これは、１つの例にすぎず、本発明は、ネットワークサーバインターオペラビリティおよびネットワークサーバインタアクションを有するシンクライアントだけを必要とする。したがって、本発明は、非常に少ないクライアントリソースまたは最小限のクライアントリソースが関係するネットワークホステッドサービスの環境、たとえば、クライアントデバイスがワールドワイドウェブへのブラウザまたはインターフェースとしてのみ働くネットワーク化された環境で、実施することができる。

必要ではないが、本発明を、デベロッパによる使用のためのアプリケーションプログラミングインターフェース（ＡＰＩ）を介して実施するか、クライアントワークステーション、サーバ、または他のデバイスなどの１つまたは複数のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の全般的な文脈で説明されるネットワークブラウジングソフトウェアに含めるか、その両方を行うことができる。一般に、プログラムモジュールには、特定のタスクを実行するか、特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、および類似物が含まれる。通常、プログラムモジュールの機能性は、さまざまな実施形態での望みに応じて、組み合わせるか分散することができる。さらに、当業者は、本発明を他のコンピュータシステム構成で実践することができることを諒解するであろう。本発明と共に使用するのに適する可能性がある他の周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成には、パーソナルコンピュータ（ＰＣ）、自動預金払戻機、サーバコンピュータ、ハンドヘルドデバイス、ラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、プログラマブル消費者電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、および類似物が含まれるが、これに限定はされない。本発明は、通信ネットワークまたは他のデータ伝送メディアを介してリンクされるリモートプロセッシングデバイスによってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含む、ローカルコンピュータストレージメディアおよびリモートコンピュータストレージメディアの両方に配置することができる。

したがって、図１に、本発明を実施することができる適切なコンピューティングシステム環境１００の例を示すが、上で明らかにしたように、コンピューティングシステム環境１００は、適切なコンピューティング環境の１つの例に過ぎず、本発明の使用の範囲または機能性に関する限定を提案することを意図されてはいない。コンピューティング環境１００を、例示的なオペレーティング環境１００に示されたコンポーネントのいずれかまたはその組合せに関する依存性または要件を有するものと解釈してもならない。

図１に関して、本発明を実施する例示的なシステムに、コンピュータ１１０の形態の汎用コンピューティングデバイスが含まれる。コンピュータ１１０のコンポーネントには、処理ユニット１２０、システムメモリ１３０、およびシステムバス１２１が含まれるがこれに限定はされず、システムバス１２１によって、システムメモリを含むさまざまなシステムコンポーネントが、処理ユニット１２０に結合される。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含む複数のタイプのバス構造のいずれかとすることができる。制限ではなく例として、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バス（メザニンバスとも称する）が含まれる。

コンピュータ１１０には、通常は、さまざまなコンピュータ可読メディアが含まれる。コンピュータ可読メディアは、コンピュータ１１０によってアクセスすることができるすべての使用可能なメディアとすることができ、コンピュータ可読メディアには、揮発性メディアおよび不揮発性メディアと、取り外し可能メディアおよび取り外し不能メディアの両方が含まれる。制限ではなく例として、コンピュータ可読メディアに、コンピュータストレージメディアおよび通信メディアを含めることができる。コンピュータストレージメディアには、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報のストレージに関する任意の方法またはテクノロジで実施される、揮発性および不揮発性の両方の、取り外し可能メディアおよび取り外し不能メディアが含まれる。コンピュータストレージメディアには、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージデバイス、あるいは所望の情報を保管するのに使用することができ、コンピュータ１１０によってアクセスすることができる他のあらゆるメディアが含まれるが、これに制限はされない。通信メディアによって、通常は、搬送波または他のトランスポートメカニズムなどの変調されたデータ信号でコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータが実施され、通信メディアには、すべての情報配信メディアが含まれる。用語「変調されたデータ信号」は、信号内で情報を符号化する形でその特性の１つまたは複数を設定または変更された信号を意味する。制限ではなく例として、通信メディアには、ワイヤードネットワークまたは直接配線接続などのワイヤードメディアと、音響、ＲＦ、赤外線、および他のワイヤレスメディアなどのワイヤレスメディアが含まれる。前記のいずれかの組合せも、コンピュータ可読メディアの範囲に含まれなければならない。

システムメモリ１３０には、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性のメモリの形態のコンピュータストレージメディアが含まれる。起動中などにコンピュータ１１０内のエレメントの間での情報の転送を助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）が、通常はＲＯＭ１３１に保管される。ＲＡＭ１３２には、通常は、即座にアクセス可能であるおよび／または処理ユニット１２０によって現在操作されているデータおよび／またはプログラムモジュールが含まれる。制限ではなく例として、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７が図示されている。

コンピュータ１１０には、他の取り外し可能／取り外し不能の揮発性／不揮発性コンピュータストレージメディアを含めることもできる。例としてのみ、図１に、取り外し不能不揮発性磁気メディアから読み取り、これに書き込むハードディスクドライブ１４１、取り外し可能不揮発性磁気ディスク１５２から読み取り、これに書き込む磁気ディスクドライブ１５１、およびＣＤ ＲＯＭまたは他の光学メディアなどの取り外し可能不揮発性光ディスク１５６から読み取り、これに書き込む光学ディスクドライブ１５５が図示されている。この例示的オペレーティング環境で使用することができる他の取り外し可能／取り外し不能の揮発性／不揮発性コンピュータストレージメディアには、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、および類似物が含まれるが、これに限定はされない。ハードディスクドライブ１４１は、通常は、インターフェース１４０などの取り外し不能メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光学ディスクドライブ１５５は、通常は、インターフェース１５０などの取り外し可能メモリインターフェースによってシステムバス１２１に接続される。

上で説明した、図１に図示されたドライブおよびそれに関連するコンピュータストレージメディアによって、コンピュータ１１０のコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージが提供される。図１では、たとえば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を保管する状態で図示されている。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一または異なるのいずれかとすることができる。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、最低限、これらが異なるコピーであることを示すために、本明細書では異なる符号を与えられている。ユーザは、キーボード１６２およびポインティングデバイス１６１（通常は、マウス、トラックボール、またはタッチパッドと称する）などの入力デバイスを介してコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星放送受信用パラボラアンテナ、スキャナ、または類似物を含めることができる。前記および他の入力デバイスは、しばしば、システムバス１２１に結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ（ＵＳＢ）などの、他のインターフェースおよびバス構造によって接続されることが可能である。

モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。ノースブリッジなどのグラフィックスインターフェース１８２も、システムバス１２１に接続することができる。ノースブリッジは、ＣＰＵまたはホスト処理ユニット１２０と通信するチップセットであり、ａｃｃｅｌｅｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｏｒｔ（ＡＧＰ）通信の責任を負う。１つまたは複数のグラフィックス処理ユニット（ＧＰＵ）１８４によって、グラフィックスインターフェース１８２と通信することができる。これに関して、ＧＰＵ１８４には、一般に、レジスタストレージなどのオンチップメモリストレージが含まれ、ＧＰＵ１８４によって、ビデオメモリ１８６との通信が行われる。しかし、ＧＰＵ１８４は、コプロセッサの１つの例にすぎず、したがって、さまざまなコプロセッシングデバイスを、コンピュータ１１０に含めることができる。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続され、このビデオインターフェース１９０によって、ビデオメモリ１８６と通信することができる。モニタ１９１の他に、コンピュータに、スピーカ１９７およびプリンタ１９６など、出力周辺インターフェース１９５を介して接続することができる他の周辺出力デバイスも含めることができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、リモートコンピュータ１８０には、通常は、コンピュータ１１０に関して上述したエレメントの多数またはすべてが含まれるが、図１にはメモリストレージデバイス１８１だけが図示されている。図１に示された論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークも含めることができる。そのようなネットワーキング環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれている。

ＬＡＮネットワーキング環境で使用される場合に、コンピュータ１１０は、ネットワークインターフェースまたはネットワークアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用される場合に、コンピュータ１１０には、通常は、インターネットなどのＷＡＮ１７３を介する通信を確立する、モデム１７２または他の手段が含まれる。モデム１７２は、内蔵または外付けとすることができるが、ユーザ入力インターフェース１６０または他の適当なメカニズムを介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示されたプログラムモジュールまたはその諸部分を、リモートメモリストレージデバイスに保管することができる。制限ではなく例として、図１に、メモリデバイス１８１に常駐するリモートアプリケーションプログラム１８５を図示する。図示のネットワーク接続が、例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用することができることを諒解されたい。

当業者は、コンピュータ１１０または他のクライアントデバイスを、コンピュータネットワークの一部として展開することができることを諒解することができる。これに関して、本発明は、任意の個数のメモリまたはストレージユニット、および任意の数のストレージユニットまたはボリュームにまたがって発生する任意の数のアプリケーションおよびプロセスを有するあらゆるコンピュータシステムに関係する。本発明は、リモートストレージまたはローカルストレージを有する、ネットワーク環境内で展開されたサーバコンピュータおよびクライアントコンピュータを伴う環境に適用することができる。本発明は、プログラミング言語機能性、解釈機能、および実行機能を有する独立型コンピューティングデバイスにも適用することができる。

分散コンピューティングによって、コンピューティングデバイスとシステムとの間の直接交換によるコンピュータリソースおよびサービスの共有が容易になる。これらのリソースおよびサービスには、情報の交換、キャッシュストレージ、およびファイル用のディスクストレージが含まれる。分散コンピューティングでは、ネットワーク接続性が利用され、クライアントが、集合的な威力を活用して企業全体に利益をもたらすことができるようになる。これに関して、さまざまなデバイスが、信頼されるグラフィックスパイプラインに関する本発明の認証テクニックを含めるために相互作用することができるアプリケーション、オブジェクト、またはリソースを有する。

図２に、例示的なネットワーク化されたコンピューティング環境または分散コンピューティング環境の概略図を示す。分散コンピューティング環境には、コンピューティングオブジェクト１０ａ、１０ｂなどおよびコンピューティングオブジェクトまたはコンピューティングデバイス１１０ａ、１１０ｂ、１１０ｃが含まれる。これらのオブジェクトに、プログラム、メソッド、データストア、プログラマブルロジックなどを含めることができる。オブジェクトに、ＰＤＡ、テレビジョン、ＭＰ３プレイヤ、テレビジョン、パーソナルコンピュータなどの同一のデバイスまたは異なるデバイスの一部を含めることができる。各オブジェクトは、通信ネットワーク１４によって別のオブジェクトと通信することができる。このネットワーク自体に、図２のシステムにサービスを提供する、他のコンピューティングオブジェクトおよびコンピューティングデバイスを含めることができる。本発明の態様によれば、各オブジェクト１０または１１０に、信頼されるグラフィックスパイプラインに関する本発明の認証テクニックを要求する可能性があるアプリケーションを含めることができる。

１１０ｃなどのオブジェクトを、別のコンピューティングデバイス１０または１１０上でホスティングすることができることも諒解することができる。したがって、図示の物理的環境では、接続されたデバイスがコンピュータとして図示されているが、そのような図示は、単に例示的であり、代わりに、ＰＤＡ、テレビジョン、ＭＰ３プレイヤなどのさまざまなディジタルデバイス、またはインターフェース、ＣＯＭオブジェクト、および類似物などのソフトウェアオブジェクトを含む物理的環境を図示するか説明することができる。

分散コンピューティング環境をサポートするさまざまなシステム、コンポーネント、およびネットワーク構成がある。たとえば、コンピューティングシステムを、ワイヤラインシステムまたはワイヤレスシステムによって、ローカルネットワークまたは広い範囲に分散したネットワークによって、一緒に接続することができる。現在、ネットワークの多くが、インターネットに結合され、このインターネットによって、広範囲に分散したコンピューティングネットワークのインフラストラクチャが提供され、このインターネットに、多数の異なるネットワークが含まれる。

ホームネットワーキング環境には、電力線、データ（ワイヤレスおよびワイヤードの両方）、音声（たとえば電話）、およびエンターテイメントメディアなどの独自のプロトコルをそれぞれがサポートすることができる少なくとも４つの異なるネットワークトランスポートメディアがある。照明スイッチおよび照明器具などのホームコントロールデバイスのほとんどによって、接続に電力線を使用することができる。データサービスは、ブロードバンド（たとえば、ＤＳＬモデムまたはケーブルモデムのいずれか）として家庭にエンターする（入る）ことができ、家庭内でワイヤレス接続性（たとえば、ＨｏｍｅＲＦまたは８０２．１１ｂ）またはワイヤード接続性（たとえば、Ｈｏｍｅ ＰＮＡ、Ｃａｔ ５、ｅｖｅｎ ｐｏｗｅｒ ｌｉｎｅ）のいずれかを使用してアクセス可能である。音声トラフィックは、ワイヤード（たとえば、Ｃａｔ ３）またはワイヤレス（たとえば、セル電話）のいずれかとして家庭にエンターすることができ、家庭内でＣａｔ ３配線を使用して配布することができる。エンターテイメントメディアは、衛星またはケーブルのいずれかを介して家庭にエンターすることができ、通常は、家庭内で同軸ケーブルを使用して配布される。ＩＥＥＥ １３９４およびＤＶＩも、メディアデバイスのクラスタのディジタル相互接続として現れつつある。これらのネットワーク環境およびプロトコル標準規格として現れる可能性がある他の環境のすべてを、インターネットによって外部の世界に接続することができるイントラネットを形成するように相互接続することができる。短く言うと、データのストレージおよび伝送のためのさまざまな異なるソースが存在し、その結果、前に進むと、コンピューティングデバイスは、そのデータ処理パイプラインのすべての部分で、コンテンツを保護する形を必要とするようになる。

「インターネット」は、一般に、コンピュータネットワーキングの技術で周知の、ＴＣＰ／ＩＰプロトコルスイートを使用するネットワークおよびゲートウェイの集合を指す。ＴＣＰ／ＩＰは、「Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｆａｃｅ Ｐｒｏｇｒａｍ（転送制御プロトコル／インターフェースプログラム）」の頭字語である。インターネットは、ユーザがネットワークを介して相互作用でき、情報を共有できるようにする、ネットワーキングプロトコルを実行するコンピュータによって相互接続された、地理的に分散したリモートコンピュータネットワークのシステムとして説明することができる。そのような広範囲に広がった情報共有のゆえに、インターネットなどのリモートネットワークは、これまで、全般的に、デベロッパが、本質的に制限なしで特殊化されたオペレーションまたはサービスを実行するソフトウェアアプリケーションを設計することができるオープンシステムに進化してきた。

したがって、ネットワークインフラストラクチャによって、クライアント／サーバアーキテクチャ、ピアツーピアアーキテクチャ、またはハイブリッドアーキテクチャなどのネットワークトポロジのホストが可能になる。「クライアント」は、それが関係しない別のクラスまたはグループのサービスを使用する、あるクラスまたはグループのメンバである。したがって、コンピューティングにおいて、クライアントは、別のプログラムによって提供されるサービスを要求するプロセスすなわち、おおまかには命令の組またはタスクである。クライアントプロセスによって、他のプログラムまたはサービス自体に関する機能の詳細を一切「知る」必要なしに、要求されたサービスが使用される。クライアント／サーバアーキテクチャ、特にネットワークシステムにおいて、クライアントは、通常は、たとえばサーバなどの別のコンピュータによって提供される共有ネットワークリソースにアクセスするコンピュータである。図２の例において、コンピュータ１１０ａ、１１０ｂなどを、クライアントと考えることができ、コンピュータ１０ａ、１０ｂなどを、サーバと考えることができ、ここで、サーバ１０ａ、１０ｂなどによって、クライアントコンピュータ１１０ａ、１１０ｂなどに複製されるデータが維持される。

サーバは、通常は、インターネットなどのリモートネットワークを介してアクセス可能なリモートコンピュータシステムである。クライアントプロセスは、第１コンピュータシステム内でアクティブとすることができ、サーバプロセスは、第２コンピュータシステム内でアクティブとすることができ、これらが通信メディアを介して互いに通信し、したがって、分散機能性がもたらされ、複数のクライアントがサーバの情報収集機能を利用できるようになる。

クライアントおよびサーバは、プロトコルレイヤによって提供される機能性を使用して互いに通信する。たとえば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ワールドワイドウェブ（ＷＷＷ）と共に使用される一般的なプロトコルである。通常、Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）またはインターネットプロトコル（ＩＰ）アドレスなどのコンピュータネットワークアドレスが、サーバコンピュータまたはクライアントコンピュータがお互いを識別するのに使用される。ネットワークアドレスを、Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒアドレスと呼ぶことができる。たとえば、通信を、通信メディアを介して提供することができる。具体的に言うと、クライアントおよびサーバを、大容量通信に関するＴＣＰ／ＩＰ接続を介して互いに結合することができる。

したがって、図２に、サーバがネットワーク／バスを介してクライアントコンピュータと通信する、本発明を実施することができる、例示的なネットワーク化された環境または分散環境が示されている。さらに詳細に言うと、本発明にしたがって、複数のサーバ１０ａ、１０ｂなどが、ＬＡＮ、ＷＡＮ、イントラネット、インターネットなどとすることができる通信ネットワーク／バス１４を介して、ポータブルコンピュータ、ハンドヘルドコンピュータ、シンクライアント、ネットワーク化された機器、またはＶＣＲ、ＴＶ、オーブン、照明、ヒータ、および類似物などの他のデバイスなどの複数のクライアントコンピューティングデバイスまたはリモートコンピューティングデバイス１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなど相互接続される。したがって、本発明を、それに関して信頼されるソースからのセキュアコンテンツを処理し、保管し、またはレンダリングすることが望ましいあらゆるコンピューティングデバイスに適用することができることが企図されている。

通信ネットワーク／バス１４がインターネットであるネットワーク化された環境では、たとえば、サーバ１０を、ウェブサーバとすることができ、このウェブサーバに、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどが、ＨＴＴＰなどの複数の既知のプロトコルのいずれかを介して通信する。サーバ１０は、クライアント１１０として働くこともでき、これは、分散コンピューティング環境の特性とすることができる。通信は、適当な場合に、ワイヤードまたはワイヤレスとすることができる。クライアントデバイス１１０は、通信ネットワーク／バス１４を介して通信してもしなくてもよく、独立の通信を関連付けられることができる。たとえば、ＴＶまたはＶＣＲの場合に、その制御に対するネットワーク化された態様がある場合もそうでない場合もある。各クライアントコンピュータ１１０およびサーバコンピュータ１０は、さまざまなアプリケーションプログラムモジュールまたはオブジェクト１３５を備えることができ、さまざまなタイプのストレージエレメントまたはオブジェクトへの接続またはアクセスを備えることができ、この接続またはアクセスを介して、ファイルを保管するか、ファイルの一部をダウンロードまたは移植することができる。したがって、本発明を、通信ネットワーク／バス１４にアクセスし、これと相互作用することができるクライアントコンピュータ１１０ａ、１１０ｂなどと、コンピュータ１１０ａ、１１０ｂなどおよび他のデバイス１１１およびデータベース２０と相互作用することができるサーバコンピュータ１０ａ、１０ｂとを有するコンピュータネットワーク環境で使用することができる。

ディジタル権利管理（ＤＲＭ）の概要
既知のように、図１１を参照すると、ディジタル権利管理（ＤＲＭ）およびディジタル権利実施は、ディジタルオーディオ、ディジタルビデオ、ディジタルテキスト、ディジタルデータ、ディジタルマルチメディアなどのディジタルコンテンツ１２に関して、そのようなディジタルコンテンツ１２がユーザに配布される場合に、非常に望ましい。ユーザによって受け取られる際に、そのようなユーザは、パーソナルコンピュータ１４のメディアプレイヤまたは類似物などの適当なレンダリングデバイスの助けを得てディジタルコンテンツをレンダリングまたは「プレイ」する。

通常、そのようなディジタルコンテンツ１２を配布するコンテンツオーナーまたはコンテンツデベロッパ（以下では「オーナー」と称する）は、ユーザがそのように配布されるディジタルコンテンツ１２に関して行うことができることを制限することを望む。たとえば、コンテンツオーナーは、ユーザが、そのようなコンテンツ１２をコピーし、第２のユーザに再配布することを制限することを望む可能性があり、あるいは、配布されたディジタルコンテンツ１２を、限られた回数だけ、あるトータル時間だけ、あるタイプのマシンでのみ、あるタイプのメディアプレイヤでのみ、あるタイプのユーザによってのみ、などでプレイできるようにすることを望む可能性がある。

しかし、配布が行われた後には、そのようなコンテンツオーナーは、ディジタルコンテンツ１２に対する制御を、あるとしてもごくわずかだけ有する。ＤＲＭシステム１０を用いると、ディジタルコンテンツ１２の任意の形での制御されたレンダリングまたはプレイが可能になり、そのような制御は、柔軟であり、そのようなディジタルコンテンツのコンテンツオーナーによって定義可能である。通常、コンテンツ１２は、適当な配布チャネルによってパッケージ１３の形でユーザに配布される。配布されるディジタルコンテンツパッケージ１３に、対称暗号化／暗号化解除（暗号解読）キー（ＫＤ）（すなわち（ＫＤ（ＣＯＮＴＥＮＴ）））を用いて暗号化されたディジタルコンテンツならびに、コンテンツを識別する情報、そのようなコンテンツのライセンスを獲得する方法などの他の情報を含めることができる。

信頼ベースのＤＲＭシステム１０を用いると、ディジタルコンテンツ１２のオーナーが、そのようなディジタルコンテンツ１２がユーザのコンピューティングデバイス１４でのレンダリングを許可される前に満足されなければならないライセンスルールを指定できるようになる。そのようなライセンスルールに、前述の時間的要件を含めることができ、そのようなライセンスルールは、ユーザ／ユーザのコンピューティングデバイス１４（以下、このような用語は、状況が他の形を必要としない限り、交換可能である）がコンテンツオーナーまたはそのエージェントから入手しなければならないディジタルライセンスまたは使用ドキュメント（以下では「ライセンス」と称する）１６内で実施することができる。そのようなライセンス１６に、おそらくはユーザのコンピューティングデバイスによって暗号化解除（暗号解読）可能なキーによって暗号化されたディジタルコンテンツを暗号化解除する暗号化解除キー（ＫＤ）も含まれる。

ディジタルコンテンツ１２の１つのコンテンツオーナーは、ユーザのコンピューティングデバイス１４が、そのようなコンテンツオーナーによってライセンス１６内で指定されたルールおよび要件を守ることすなわち、ディジタルコンテンツ１２が、ライセンス１６内のルールおよび要件が満足されない限りレンダリングされないことを信頼しなければならない。ユーザのコンピューティングデバイス１４が、ディジタルコンテンツ１２に関連し、ユーザによって入手されるライセンス１６で実施されるライセンスルールに従う場合を除いてディジタルコンテンツ１２がレンダリングされない、信頼されるコンポーネントまたは信頼されるメカニズム１８を備えることが好ましい。

信頼されるコンポーネント１８は、通常は、ライセンスエバリュエータ２０を有し、このライセンスエバリュエータ２０によって、とりわけ、ライセンス１６が有効であるかどうかが判定され、そのような有効なライセンス１６のライセンスルールおよびライセンス要件が再検討され、再検討されたライセンスルールおよびライセンス要件に基づいて、要求元のユーザが、要求されたディジタルコンテンツ１２を求められる形でレンダリングする権利を有するかどうかが判定される。理解されるように、ライセンスエバリュエータ２０は、ＤＲＭシステム１０内で信頼されて、ライセンス１６のルールおよび要件に従ってディジタルコンテンツ１２のオーナーの望みを実行し、ユーザは、極悪なまたは他の形のすべての目的のためにそのような信頼されるエレメントを簡単に変更することができてはならない。

理解されなければならないように、ライセンス１６のルールおよび要件によって、ユーザが、そのユーザが誰であるか、そのユーザがどこに位置するか、そのユーザが使用しているコンピューティングデバイスのタイプが何であるか、どのレンダリングアプリケーションによってＤＲＭシステムが呼び出されているか、日付、時刻などを含む複数の要因に基づいて、ディジタルコンテンツ１２をレンダリングする権利を有するかどうかを指定することができる。さらに、ライセンス１６のルールおよび要件によって、たとえば事前に決定されるプレイ回数または事前に決定されるプレイ時間にライセンス１６を制限することができる。

ルールおよび要件は、任意の適当な言語および構文に従ってライセンス１６内で指定することができる。たとえば、この言語によって、満足されなければならない属性および値を単純に指定することができ（たとえば、ＤＡＴＥ ｍｕｓｔ ｂｅ ｌａｔｅｒ ｔｈａｎ Ｘ）、あるいは、指定されたスクリプトによる関数の実行を要求することができる（たとえば、ＩＦ ＤＡＴＥ ｇｒｅａｔｅｒ ｔｈａｎ Ｘ，ＴＨＥＮ ＤＯ ．．．）。

ライセンスエバリュエータ２０が、ライセンス１６が有効であり、ユーザがそのライセンスのルールおよび要件を満足すると判定する際に、ディジタルコンテンツ１２をレンダリングすることができる。具体的に言うと、コンテンツ１２をレンダリングするために、暗号化解除キー（ＫＤ）が、ライセンス１２から入手され、コンテンツパッケージ１３からの（ＫＤ（ＣＯＮＴＥＮＴ））に適用されて、実際のコンテンツ１２がもたらされ、実際のコンテンツ１２が、実際にレンダリングされる。

ディジタルコンテンツのパブリッシュ
図３は、ディジタルコンテンツをパブリッシュするシステムおよび方法の機能ブロック図である。本明細書で使用される用語としての「パブリッシュ」は、アプリケーションまたはサービスが、信頼されるエンティティと共に、そのエンティティがそのコンテンツを発行できる権利および条件の組ならびにその権利および条件を発行できる相手を確立するために従うプロセスである。本発明によれば、パブリッシュプロセスに、ディジタルコンテンツを暗号化することと、コンテンツの作者がコンテンツのすべての可能なユーザについて企図した永続的で実施可能な権利のリストを関連付けることが含まれる。このプロセスをセキュアな形で実行して、コンテンツの作者によって意図されないすべての権利またはコンテンツへのアクセスを禁止することができる。

具体的には、３つのエンティティが、セキュアディジタルコンテンツのパブリッシュに使用される。すなわち、クライアント３００で実行され、パブリッシュのためにコンテンツを準備するコンテンツ準備アプリケーション３０２、やはりクライアントデバイス３００に常駐するディジタル権利管理（ＤＲＭ）アプリケーションプログラムインターフェース（ＡＰＩ）３０６、および、インターネット、ローカルエリアネットワーク、広域ネットワーク、またはこれらの組合せなどの通信ネットワーク３３０を介してクライアント３００に通信的に結合されるＤＲＭサーバ３２０である。

コンテンツ準備アプリケーション３０２は、ディジタルコンテンツを作る任意のアプリケーションとすることができる。たとえば、アプリケーション３０２は、ディジタルテキストファイル、ディジタルミュージック、ビデオ、または他のそのようなコンテンツを作る、ワードプロセッサまたは他のパブリッシャとすることができる。コンテンツに、ライブイベントまたはテープに記録されたイベントまたは例のストリーミングされたオーディオ／ビデオなどの、ストリーミングされたコンテンツを含めることもできる。アプリケーション３０２は、ディジタルコンテンツを暗号化し、したがって、暗号化されたディジタルコンテンツファイル３０４を形成する暗号キーを備え、ユーザは、ディジタルコンテンツファイル３０４の暗号化されたコンテンツに緊密に関連付けられる権利データを提供する。権利データには、ディジタルコンテンツの権利を有するエンティティごとの識別ならびに各識別されたエンティティの権利および条件の組が含まれる。

そのようなエンティティは、たとえば、個人、個人のクラス、またはデバイスとすることができる。そのような権利に、ディジタルコンテンツを読み取る権利、ディジタルコンテンツを編集する権利、ディジタルコンテンツをコピーする権利、ディジタルコンテンツを印刷する権利などを含めることができる。条件に、最小システム要件、日付制限、回数制限、プレイカウント、および類似物を含めることができる。

クライアントＡＰＩ３０６によって、暗号化されたディジタルコンテンツデータおよび権利データが、ＤＲＭサーバ３２０に渡される。下で詳細に説明するプロセスを使用して、ＤＲＭサーバ３２０によって、そのＤＲＭサーバ３２０によって権利データを実施できるかどうかが判定され、そうである場合には、ＤＲＭサーバ３２０によって、権利データに署名して、署名付き権利ラベル（ＳＲＬ）３０８が形成される。しかし、一般に、信頼されるエンティティであればどれであっても、好ましくはＤＲＭサーバ３２０によって信頼されるキーを使用して、権利データに署名することができる。たとえば、クライアントが、ＤＲＭサーバ３２０によってクライアントに供給されるキーを使用して権利データに署名することができる。

権利ラベル３０８に、権利記述、暗号化されたコンテンツキー、ならびに権利記述および暗号化されたコンテンツキーに対するディジタル署名を表すデータを含めることができる。ＤＲＭサーバ３２０によって権利ラベルに署名される場合には、ＤＲＭサーバ３２０によって、署名付き権利ラベル３０８が、クライアントＡＰＩ３０６を介してクライアントに渡され、このクライアントによって、署名付き権利ラベル３０８が、クライアントデバイス３００で保管される。コンテンツ準備アプリケーション３０２によって署名付き権利ラベル３０８が、たとえば権利管理されたコンテンツファイル３１０を形成するための連結によるなど、暗号化されたディジタルコンテンツファイル３０４に関連付けられる。しかし、コンテンツファイル３１０を形成するためにコンテンツファイル３０４に連結されたＳＲＬ３０８への参照を用いて、ＳＲＬ３０８を、コンテンツファイル３０４と別々に既知の位置に保管することができることに留意されたい。

図４を参照すると、権利管理されたディジタルコンテンツをパブリッシュする方法の１つが示されている。ステップ４０２で、アプリケーション３０２によって、ディジタルコンテンツを暗号化するのに使用されるコンテンツキー（ＣＫ）が生成される。コンテンツキー（ＣＫ）は、通常は、対称キーであるが、ディジタルコンテンツの暗号化に任意のキーを使用することができる。既知のように、対称キーは、対称キーアルゴリズムによって、暗号化および暗号化解除の両方に使用される。したがって、（ＣＫ）は、送信側と受信側の間で共有される場合に、きちんと隠蔽されなければならない。

ステップ４０４で、アプリケーション３０２によって、（ＣＫ）を用いてディジタルコンテンツを暗号化して、暗号化されたコンテンツファイル３０４（すなわち（ＣＫ（ｃｏｎｔｅｎｔ）））を形成する。さらに、（ＣＫ（ｃｏｎｔｅｎｔ））に対応する権利データが、コンテンツのパブリッシャまたは別のエンティティのいずれかによって生成される。そのような権利データを、カスタム権利データまたは、事前に定義されたテンプレートから入手される権利データとすることができることに留意されたい。上で説明したように、権利データに、コンテンツを消費する権利を与えられるエンティティのリスト、コンテンツに関してエンティティのそれぞれが所有する特定の権利、およびこれらの権利に押し付けることができるすべての条件を含めることができる。

ステップ４０６で、ＡＰＩ３０６によって、第２の暗号化キー（Ｋ２）が生成され、このキーはコンテンツキー（ＣＫ）を暗号化するのに使用される。（Ｋ２）も、対称鍵であることが好ましい。ステップ４０８で、ＡＰＩ３０６によって、（Ｋ２）を用いて（ＣＫ）を暗号化して、（Ｋ２（ＣＫ））をもたらす。ステップ４１０で、ＡＰＩ３０６によって、（ＣＫ）を破棄し、その結果、（ＣＫ）は、（Ｋ２（ＣＫ））を暗号化解除することによってのみ入手できるようになる。（ＣＫ（ｃｏｎｔｅｎｔ））が中央ＤＲＭサーバ３２０に保護されることと、コンテンツに関するすべての「ライセンス要求」が権利データに従って集中して行われることを保証するために、ステップ４１２で、ＡＰＩ３０６によって、提供されるＤＲＭサーバ３２０に連絡し、その公開キー（ＰＵ−ＤＲＭ）を検索する。ステップ４１４で、ＡＰＩ３０６によって、（ＰＵ−ＤＲＭ）を用いて（Ｋ２）を暗号化して、（ＰＵ−ＤＲＭ（Ｋ２））をもたらす。したがって、（ＣＫ）を（ＰＵ−ＤＲＭ））に保護して、ＤＲＭサーバ３２０が、（ＣＫ（ｃｏｎｔｅｎｔ））の暗号化解除に必要な（ＣＫ）へのアクセスを得ることができる唯一のエンティティであることを保証する。ステップ４１６で、ＡＰＩ３０６によって、（Ｋ２）を用いて権利データ（すなわち、許可されるエンティティのリストならびにリスト内の許可されるエンティティのそれぞれに関連するめいめいの権利および条件）を暗号化して、（Ｋ２（ｒｉｇｈｔｓｄａｔａ））をもたらす。

代替実施形態では、（ＣＫ）を使用して、権利データを直接に暗号化して、（ＣＫ（ｒｉｇｈｔｓｄａｔａ））をもたらすことができ、（ＰＵ−ＤＲＭ）を使用して、（ＣＫ）を直接に暗号化して、（ＰＵ−ＤＲＭ（ＣＫ））をもたらすことができ、これによって、（Ｋ２）の使用を完全になしで済ませることができる。しかし、（Ｋ２）を使用して権利データおよび（ＣＫ）を暗号化することによって、そのような（Ｋ２）を、ＤＲＭサーバに従うようにすることができる任意の特定のアルゴリズムに従わせることができ、（ＣＫ）を、ＤＲＭサーバから独立のエンティティによって指定することができ、ＤＲＭサーバに従う（ＣＫ）としなくてよい。

ステップ４１８で、コンテンツ保護アプリケーション３０２によって、署名用の権利ラベルとしてＤＲＭサーバ３２０に（ＰＵ−ＤＲＭ（Ｋ２））および（Ｋ２（ｒｉｇｈｔｓｄａｔａ））がサブミットされる。代わりに、クライアント自体が、下で示す形で権利データに署名することができる。権利データが、署名のためにサーバにサブミットされている場合には、ステップ４２０で、ＤＲＭサーバ３２０によって、権利データがアクセスされ、サブミットされた権利ラベルの権利および条件をＤＲＭサーバ３２０によって実施できることが検証される。ＤＲＭサーバ３２０によって権利を実施できることを検証するために、ＤＲＭサーバ３２０によって、（ＰＵ−ＤＲＭ）に対応する秘密キー（ＰＲ−ＤＲＭ）を（ＰＵ−ＤＲＭ（Ｋ２））に適用して、（Ｋ２）をもたらし、次に、（Ｋ２）を（Ｋ２（ｒｉｇｈｔｓｄａｔａ））に適用して、平文の権利データをもたらす。次に、サーバ３２０によって、ポリシ検査を実行して、権利データで指定されたユーザ、権利、および条件が、サーバ３２０によって実施されるすべてのポリシに含まれることを検証する。サーバ３２０によって、最初にサブミットされた、（ＰＵ−ＤＲＭ（Ｋ２））および（Ｋ２（ｒｉｇｈｔｓｄａｔａ））を含む権利ラベルに署名して、署名付き権利ラベル（ＳＲＬ）３０８をもたらし（この署名は、ＤＲＭサーバ３２０の秘密キー（ＰＲ−ＤＲＭ）に基づく）、ＳＲＬ３０８がＡＰＩ３０６に返され、ＡＰＩ３０６によって、返されたＳＲＬ３０８が、クライアントアプリケーション３０２に提示される。

ＳＲＬ３０８は、ディジタル署名されたドキュメントであり、このディジタル署名によって、ＳＲＬ３０８が耐タンパにされる。さらに、ＳＲＬ３０８は、コンテンツを暗号化するのに使用された実際のキーのタイプおよびアルゴリズムと独立であるが、それが保護するコンテンツに対する強い１対１関係が維持される。図４Ａを参照すると、本発明の一実施形態で、ＳＲＬ３０８に、とりわけ、おそらくはコンテンツのＩＤ；（ＰＵ−ＤＲＭ（Ｋ２））と、ネットワークでＤＲＭサーバを突き止めるためのＵＲＬおよびＵＲＬに障害が発生する場合のフォールバック情報などの参照情報とを含む、ＳＲＬ３０８に署名するＤＲＭサーバに関する情報；ＳＲＬ３０８自体を説明する情報；（Ｋ２（ｒｉｇｈｔｓｄａｔａ））；（Ｋ２（ＣＫ））；およびディジタル署名（Ｓ（ＰＲ−ＤＲＭ））を含むＳＲＬ３０８の基礎であるコンテンツに関する情報を含めることができる。

署名付き権利ラベル３０８を作るために、信頼されるエンティティが権利データに署名することを保証することによって、ＤＲＭサーバ３２０によって、権利ラベル３０８の権利データで説明されるパブリッシャによって示される条件に従ってコンテンツに関するライセンスが発行されることが、ＤＲＭサーバ３２０によって主張されつつある。諒解されなければならないように、ユーザは、特にライセンスにコンテンツキー（ＣＫ）が含まれる限り、コンテンツをレンダリングするためにライセンスを入手することを要求される。ユーザが、暗号化されたコンテンツに関するライセンスを入手することを求める場合には、ユーザは、コンテンツのＳＲＬ３０８およびＤＲＭサーバ３２０または他のライセンスを発行するエンティティへのユーザの信任証を検証する証明書を含むライセンス要求を提示することができる。ライセンスを発行するエンティティは、（ＰＵ−ＤＲＭ（Ｋ２））および（Ｋ２（ｒｉｇｈｔｓｄａｔａ））を暗号化解除して、権利データを作ることができ、ライセンスを要求するエンティティに対して作者（存在する場合に）によって許可されるすべての権利をリストすることができ、これらの特定の権利だけを有するライセンスを構築することができる。

上で示したように、アプリケーション３０２がＳＲＬ３０８を受け取る際に、そのようなアプリケーション３０２によって、署名付き権利ラベル３０８に、対応する（ＣＫ（ｃｏｎｔｅｎｔ））３０４が連結されて、権利管理されたディジタルコンテンツが形成される。代わりに、権利データが、既知の位置に保管され、その位置への参照が、暗号化されたディジタルコンテンツと共に提供される。したがって、ＤＲＭ対応であるレンダリングアプリケーションによって、そのレンダリングアプリケーションによってレンダリングが試みられつつあるコンテンツの部分を介して、署名付き権利ラベル３０８を発見することができる。このディスカバリによって、レンダリングアプリケーションによる、ＤＲＭライセンシングサーバ３２０に対するライセンス要求の開始がトリガされる。パブリッシュするアプリケーション３０２によって、たとえば、ＵＲＬをＤＲＭライセンシングサーバ３２０に保管することができ、あるいは、ＤＲＭライセンシングサーバ３２０によって、権利ラベルにディジタル署名する前に、それ自体のＵＲＬをメタデータの一部として権利ラベルに組み込むことができ、その結果、レンダリングアプリケーションによって呼び出されるＤＲＭクライアントＡＰＩ３０６によって、正しいＤＲＭライセンシングサーバ３２０を識別できるようになる。

パブリッシュされたコンテンツに関するライセンスの入手
図５を参照すると、権利管理されたディジタルコンテンツをライセンシングするシステムおよび方法が示されている。本明細書で使用される用語としての「ライセンシング」は、ライセンスで指定される条件に従って、ライセンスで名前を指定されるエンティティがコンテンツを消費できるようにするライセンスを要求し、受け取るためにアプリケーションまたはサービスが従うプロセスを指す。ライセンシングプロセスへの入力に、ライセンスが要求されているコンテンツに関連する署名付き権利ラベル３０８およびそれに対するライセンスが要求されているエンティティの公開キー証明書を含めることができる。ライセンスを要求するエンティティが、必ずしもそれに関するライセンスが要求されているエンティティでないことに留意されたい。通常、ライセンスには、ＳＲＬ３０８からの権利記述、暗号化されたコンテンツを暗号化解除することができる暗号化されたキー、ならびに、合法性を主張し、タンパリングを防ぐための、権利記述および暗号化されたキーに対するディジタル署名が含まれる。

予備的に、クライアントＡＰＩ３０６によって、権利管理されたコンテンツ３１０の署名付き権利ラベル３０８が、通信ネットワーク３３０を介してＤＲＭサーバ３２０に転送される。上述したように、権利ラベル３０８には、ＤＲＭサーバ３２０の公開キー（ＰＵ−ＤＲＭ）に従って暗号化されたコンテンツキー（ＣＫ）（すなわち（ＰＵ−ＤＲＭ（ＣＫ）））が含まれる。ライセンス発行のプロセスで、ＤＲＭサーバ３２０によって、（ＰＲ−ＤＲＭ）が（ＰＵ−ＤＲＭ（ＣＫ））に適用されて、（ＣＫ）が入手される。ＤＲＭサーバ３２０によって、ライセンス要求で渡される公開キー証明書の公開キー（ＰＵ−ＥＮＴＩＴＹ）が使用されて、（ＣＫ）が再暗号化される（すなわち（ＰＵ−ＥＮＴＩＴＹ（ＣＫ）））。新たに暗号化された（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））が、ライセンスに置かれる。したがって、ライセンスを、（ＣＫ）を露出する危険性なしに呼出し側に返すことができる。というのは、（ＰＵ−ＥＮＴＩＴＹ）に対応する秘密キー（ＰＲ−ＥＮＴＩＴＹ）の所有者だけが、（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））から（ＣＫ）を回復できるからである。クライアントＡＰＩ３０６によって、（ＣＫ）が使用されて、暗号化されたコンテンツが暗号化解除されて、暗号化解除されたディジタルコンテンツ３１２が形成される。クライアントアプリケーション３０２によって、ライセンス内で供給される権利に従って、暗号化解除されたディジタルコンテンツ３１２を使用することができる。

代わりに、下で詳細に示すように、パブリッシュするクライアントなどのクライアントによって、たとえば、コンテンツを消費するための使用ライセンスをそれ自体に発行することができる。

図６Ａおよび６Ｂに移ると、権利管理されたディジタルコンテンツをライセンシングする方法が示されている。ステップ６０２で、ＤＲＭサーバ３２０などのライセンスを発行するエンティティによって、公開キー証明書あるいは１つまたは複数の要求されるライセンシーのそれぞれの識別のいずれかを含むライセンス要求が受け取られる。おそらく、識別が指定される場合に、ＤＲＭサーバ３２０によって、ディレクトリ、データベース、または類似物から対応する公開キー証明書を獲得することができる。１つのライセンシーだけに関してライセンスが要求された場合には、１つの証明書だけまたは１つの識別だけが、名前を指定される。ライセンスが、複数のライセンシーについて要求された場合には、証明書または識別を、潜在的なライセンシーごとに名前を指定することができる。ステップ６０４で、望まれる場合に、要求するエンティティ（すなわち、ライセンス要求を行うエンティティ）が認証される。ステップ６０６で、やはり望まれる場合に、エンティティがライセンスを要求することを許可されるかどうかを判定する。

ステップ６０８で、発行するエンティティによって、公開キー証明書がライセンス要求に含まれていないかどうかが判定され、そうである場合に、発行するエンティティによって、指定された識別を使用して、適当な公開キー証明書についてディレクトリサービスまたはデータベースのルックアップが実行される。ステップ６１０で、発行するエンティティによって、証明書がディレクトリ内にあると判定される場合に、ステップ６１２で、その証明書を検索する。証明書を、要求内またはディレクトリ内のいずれでも所与の潜在的なライセンシーについて見つけることができない場合には、ライセンスサーバは、その潜在的なライセンシーに関するライセンスを生成せず、ステップ６１４で、要求元エンティティにエラーを返す。

ＤＲＭサーバ３２０が、少なくとも１つの潜在的なライセンシーの公開キー証明書を有すると仮定すると、ステップ６１６で、そのようなＤＲＭサーバ３２０によって、各ライセンシー証明書の信頼が検証される。検証されない場合に、ＤＲＭサーバ３２０によって、ライセンシー証明書の発行者が信頼される発行者のリストにないことが判定され、その後、要求がそのライセンシーについて失敗し、ステップ６１４でエラーが生成される。したがって、信頼される発行者によって発行された証明書を有しないすべての潜在的なライセンシーが、ライセンスを受け取らない。

さらに、ＤＲＭサーバ３２０によって、信頼される発行者証明書から個々のライセンシー公開キー証明書に進む証明書チェーン内のすべてのエンティティに関するディジタル証明書検証が実行されることが好ましい。チェーン内のディジタル証明書を検証するプロセスは、周知のアルゴリズムである。所与の潜在的なライセンシーの公開キー証明書が検証されない場合、またはチェーン内の証明書が検証されない場合に、その潜在的なライセンシーが信頼されず、したがって、ライセンスは、その潜在的なライセンシーに発行されない。そうでない場合には、ステップ６１８で、ライセンスを発行することができる。このプロセスは、それに関してライセンスが要求されたすべてのエンティティが処理されるまで、ステップ６２０で繰り返される。

図６Ｂからわかるように、ＤＲＭサーバ３２０は、ライセンス要求で受け取った署名付き権利ラベル３０８の検証に進む。一実施形態では、ＤＲＭサーバ３２０は、それによって署名されるすべての権利ラベルのマスタコピーを有する。ライセンスの際に（ステップ６２２で）、ＤＲＭサーバ３２０によって、マスタ権利ラベルのコピーを検索することができる。マスタ権利ラベルは、ライセンス要求で送られる権利ラベルのコピーより新しい可能性があり、したがって、要求されたライセンスを作るのに使用される権利ラベルになる。マスタ権利レベルが見つからない場合には、ＤＲＭサーバ３２０によって、ステップ６２４で、事前に定義されたポリシに従って、要求の権利ラベルに基づいてライセンスを発行するかどうかが判定される。ポリシによって許可されない場合には、ステップ６２６で、ライセンス要求が失敗し、ステップ６２８で、エラーがＡＰＩ３０６に返される。

ステップ６３０で、ＤＲＭサーバ３２０によって、ＳＲＬ３０８、特にそのディジタル署名が検証される。ＳＲＬ３０８が検証されない場合には、ステップ６２６でライセンス要求が失敗し、ステップ６２８でエラーがＡＰＩ３０６に返される。

すべての検証が行われた後に、ＤＲＭサーバによって、ＳＲＬ３０８に基づいて承認されたライセンスごとにライセンスが構築される。ステップ６３２で、ＤＲＭサーバ３２０によって、各ライセンシーに発行されるライセンスのめいめいの権利記述が生成される。ライセンシーごとに、ＤＲＭサーバ３２０によって、そのライセンシーの公開キー証明書で名前を指定された識別が、権利ラベルの権利記述で名前を指定された識別に対して評価される。ステップ６３６で、ＤＲＭサーバ３２０によって、ＳＲＬ３０８から（ＰＵ−ＤＲＭ（Ｋ２））および（Ｋ２（ＣＫ））が入手され、（ＰＲ−ＤＲＭ）が適用されて、（ＣＫ）が入手される。発行するエンティティによって、次に、ライセンシーの公開キー証明書からの（ＰＵ−ＥＮＴＩＴＹ）を使用して（ＣＫ）が再暗号化されて、（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））がもたらされる。ステップ６３８で、ＤＲＭサーバ３２０によって、生成された権利記述と（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））が連結され、結果のデータ構造が、（ＰＲ−ＤＲＭ）を使用してディジタル署名される（すなわち、Ｓ（ＰＲ−ＤＲＭ））。したがって、この署名されたデータ構造が、この特定のライセンシーのライセンスである。

ステップ６４０で、ＤＲＭサーバ３２０によって、特定の要求に関して生成されるライセンスがまだあるかどうかが判定される。生成されるラインセスは、その後、ステップ６４２で、ライセンスを信頼されるオーソリティに結び付ける適当な証明書チェーンと一緒に、要求元のエンティティに返される。

署名付き権利ラベル３０８のセルフパブリッシング
本発明の一実施形態では、ＳＲＬ３０８に、要求するユーザ自体／パブリッシングユーザ自体によって署名することができる。したがって、そのようなユーザは、関連するコンテンツのＳＲＬ３０８を入手するためにＤＲＭサーバ３２０に連絡する必要がない。その結果、セルフパブリッシングを、オフラインパブリッシングと呼ぶこともできる。そのような実施形態では、セルフパブリッシングされるコンテンツがＤＲＭ保護され、パブリッシングユーザが保護されたコンテンツをレンダリングできるようにするためにパブリッシャライセンスが必要である限り、パブリッシングユーザが、それ自体にパブリッシャライセンスを発行することもできなければならない。パブリッシングユーザが、他のユーザにライセンスを発行できるようにすることもできることも理解されたい。

具体的に言うと、図７に示されているように、この実施形態では、オフラインパブリッシングユーザが、まず、（ＰＵ−ＥＮＴＩＴＹ（ＰＲ−ＣＥＲＴ））をもたらすためにユーザの信頼されるコンポーネント１８（図１１）から直接にまたは間接的にアクセス可能な公開キー（ＰＵ−ＥＮＴＩＴＹ）に従って暗号化された公開キー（ＰＵ−ＯＬＰ）および対応する秘密キー（ＰＲ−ＯＬＰ）を含むオフラインパブリッシング（ＯＬＰ）証明書８１０をＤＲＭサーバ３２０から受け取ることによって、オフラインパブリッシュに供給される。（ＰＵ−ＥＮＴＩＴＹ）を、たとえば、信頼されるコンポーネント１８の公開キーとすることができ、あるいは、信頼されるコンポーネント１８の公開キーによってアクセス可能なユーザの公開キーとすることができることに留意されたい。下で詳細に説明するように、ＯＬＰ証明書８１０は、ＤＲＭサーバ３２０の秘密キー（ＰＲ−ＤＲＭ）によって署名されなければならず、その結果、そのＤＲＭサーバ３２０が、そのＯＬＰ証明書を検証できるようになる。

さらに、下で説明するように、ＯＬＰ証明書８１０には、信頼されるコンポーネント１８がそのＯＬＰ証明書８１０およびそのＯＬＰ証明書８１０に関連する他の証明書またはライセンスを検証できるようにするために、パブリッシングユーザまたは別のユーザの信頼されるコンポーネント１８によって信頼されるオーソリティまでの、（ＰＵ−ＤＲＭ）からの証明書チェーンが含まれなければならない。短く言うと、理解されなければならないように、証明書のチェーンは、信頼されるオーソリティの秘密キーによって署名され、チェーン内の次の証明書の公開キーを有するルート証明書から始まる。チェーン内の各中間の証明書は、チェーン内の前の証明書の公開キーに対応する秘密キーによって署名され、チェーン内の次の証明書の公開キーを有する。最後に、チェーンが付加される証明書またはライセンスは、チェーン内の最後の証明書の公開キーに対応する秘密キーによって署名される。

したがって、チェーンが付加される証明書またはライセンスを検証するために、信頼されるオーソリティの秘密キーに対応する公開キーの知識が、獲得され、信頼されるオーソリティのそのような公開キーが、チェーン内のルート証明書の署名の検証に使用される。ルート証明書署名が検証されると仮定すると、ルート証明書からの公開キーが、入手され、チェーン内の最初の中間証明書の署名の検証に使用される。このプロセスでは、チェーンのすべての署名が検証されるまでチェーンを通って順次繰り返され、その後、チェーン内の最後の中間証明書からの公開キーが、入手され、チェーンが付加された証明書またはライセンスの署名の検証に使用される。

諒解されなければならないように、ＯＬＰ証明書８１０によって、信頼のチェーン内で、オフラインでパブリッシュされるコンテンツ３０４と、そのコンテンツ３０４のライセンスを発行するＤＲＭサーバ３２０の間にリンクが作成される。ＯＬＰ証明書８１０は、ＸＭＬ／ＸｒＭＬ言語または他の適当な言語に基づいて作成することができる。

やはり諒解されなければならないように、ＯＬＰ証明書８１０および付加される証明書チェーンによって、セルフパブリッシュに対してパブリッシングユーザがオーソライズされる。さらに諒解できるように、キー対（ＰＵ−ＯＬＰ、ＰＲ−ＯＬＰ）は、（ＰＵ−ＥＮＴＩＴＹ、ＰＲ−ＥＮＴＩＴＹ）と別であり、特にセルフパブリッシングに使用される。キー対（ＰＵ−ＯＬＰ、ＰＲ−ＯＬＰ）を、なしで済ませることができ、その場合に、ＤＲＭ証明書８１０に、ユーザの公開キー（ＰＵ−ＥＮＴＩＴＹ）だけが含まれ、ＤＲＭ証明書８１０が、ＤＲＭサーバ３２０の秘密キー（ＰＲ−ＤＲＭ）によって署名され、その結果、そのＤＲＭサーバ３２０がこれを検証できるようになることに留意されたい。

セルフパブリッシングは、ユーザが、本質的に、ＤＲＭサーバ３２０によって実行されるステップに関して、ＤＲＭサーバ３２０に代わるという点で図４に示されたパブリッシングと異なる。重要なことに、ユーザは、（ＰＵ−ＤＲＭ（Ｋ２））および（Ｋ２（ｒｉｇｈｔｓｄａｔａ））を含むか、（ＰＵ−ＤＲＭ（ＣＫ））および（ＣＫ（ｒｉｇｈｔｓｄａｔａ））を含む（後者は図７および８に示されている）サブミットされた権利ラベルに、ＤＲＭ証明書８１０（すなわちＳ（ＰＲ−ＯＬＰ））から入手した（ＰＲ−ＯＬＰ）を用いて署名して、署名付き権利ラベル（ＳＲＬ）３０８をもたらす。ＯＬＰ証明書を使用する際の信頼されるコンポーネント１８クライアントは、通常は、付加された証明書チェーンに基づいてこれを検証する。諒解されなければならないように、ユーザの信頼されるコンポーネント１８は、ＯＬＰ証明書８１０から（ＰＵ−ＥＮＴＩＴＹ（ＰＲ−ＯＬＰ））を入手することと、それに（ＰＲ−ＥＮＴＩＴＹ）を適用することとによって、そのようなＯＬＰ証明書８１０から（ＰＲ−ＯＬＰ）を入手する。しかし、パブリッシングユーザは、ＤＲＭサーバ３２０がセルフパブリッシュされるＳＲＬ３０８内の権利を実施できることを検証することができないことに留意されたい。したがって、ＤＲＭサーバ３２０自体は、セルフパブリッシュされるＳＲＬ３０８に基づいてライセンスが要求される時に、検証を実行しなければならない。

パブリッシングユーザが、ＳＲＬ３０８をセルフパブリッシュしたならば、そのユーザは、そのセルフパブリッシュされたＳＲＬ３０８と、これを作成するのに使用されたＯＬＰ証明書８１０を、コンテンツ３０４に連結し、そのコンテンツ３０４を、ＳＲＬ３０８およびＤＲＭ証明書８１０と共に、権利管理されたコンテンツ３１０として別のユーザに配布する。その後、他のユーザは、図６Ａおよび６Ｂで示した形と実質的に同一の形で、コンテンツ３０４／３１０のライセンスをＤＲＭサーバ３２０に要求し、ＤＲＭサーバ３２０から入手する。しかし、ここで、ライセンスを要求するユーザは、コンテンツ３０４に連結された、セルフパブリッシュされたＳＲＬ３０８とＯＬＰ証明書８１０の両方を、ＤＲＭサーバ３２０にサブミットする。ＤＲＭサーバ３２０は、対応する（ＰＵ−ＤＲＭ）に基づいて、ＯＬＰ証明書８１０のＳ（ＰＲ−ＤＲＭ）を検証し、ＤＲＭ証明書８１０から（ＰＵ−ＯＬＰ）を入手する。ＤＲＭサーバ３２０は、入手した（ＰＵ−ＣＥＲＴ）に基づいてＳＲＬ３０８のＳ（ＰＲ−ＯＬＰ）を検証し、前と同様に継続する。しかし、パブリッシングユーザは、ＤＲＭサーバ３２０がＳＲＬ３０８の権利を実施できることを検証しなかったので、上で示したように、ＤＲＭサーバ３２０自体が、この時に検証を実行しなければならない。

また、ＤＲＭサーバ３２０が、おそらくはそれ自体を信頼するので、ＯＬＰ証明書８１０のＳ（ＰＲ−ＤＲＭ）だけを検証する必要があることに留意されたい。したがって、ＯＬＰ証明書８１０からの関連する証明書チェーンは、もちろんそのチェーンが他の形で必要（たとえば、チェーン自体が少なくとも部分的にＳ（ＰＲ−ＤＲＭ）の基礎であるなど）である場合を除いて、必ずしもそのようなＯＬＰ証明書８１０と共にＤＲＭサーバ３２０に送る必要はない。

しかし、重要なことに、パブリッシングユーザは、ライセンスに関してＤＲＭサーバ３２０に頼る必要なしに、現在、保護されているコンテンツ３０４／３１０をレンダリングできなければならない。言い換えると、ＯＬＰ証明書８１０に基づいてＤＲＭサーバ３２０に頼らずにコンテンツ３０４／３１０をオフラインパブリッシュするパブリッシングユーザは、ＤＲＭサーバ３２０に頼らずにオフラインの形でそれ自体にライセンスを発行することもできなければならず、その結果、そのユーザが、オフラインパブリッシュされたコンテンツ３０４／３１０をレンダリングできるようになる。したがって、パブリッシングユーザは、ＤＲＭサーバ３２０への接続性なしに、セルフパブリッシュされたコンテンツ３１０を扱い続けることができる。

本発明の一実施形態では、図８を参照すると、パブリッシングユーザは、オフラインパブリッシャライセンス８２０をそれ自体に発行するが、このオフラインパブリッシャライセンス８２０は、（ＰＲ−ＯＬＰ）によって署名され、セルフパブリッシュされたＳＲＬ３０８に基づき、このオフラインパブリッシャライセンス８２０に、ＯＬＰ証明書８１０およびその証明書チェーンが含まれる。おそらく、パブリッシャライセンス８２０によって、パブリッシングユーザに、セルフパブリッシュされたコンテンツ３１０へのフルアクセスが許可されるが、より少ない量のアクセスを許可することもできる。パブリッシャライセンス８２０は、他のＤＲＭライセンスと同様に、ＸＭＬ／ＸｒＭＬ言語または他の言語で記述することができる。諒解されなければならないように、パブリッシャライセンス８２０には、（ＰＵ−ＥＮＴＩＴＹ）に従って暗号化されたコンテンツキー（ＣＫ）が含まれて、（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））がもたらされ、この（ＰＵ−ＥＮＴＩＴＹ）は、ユーザのコンピューティングデバイス１４の信頼されるコンポーネント１８によって入手することができる。

したがって、パブリッシャライセンス８２０のチェーンは、そのようなライセンス８２０からＯＬＰ証明書８１０に進み、その後、おそらくは１つまたは複数の中間証明書によって、信頼されるオーソリティからのルート証明書に戻る。ユーザの信頼されるコンポーネント１８は、おそらく、ルート証明書に署名するのに使用された信頼されるオーソリティの秘密キーに対応する公開キーを得ることができるので、信頼されるコンポーネント１８自体は、その証明書チェーンによってパブリッシャライセンス８２０を検証でき、検証時に、それから（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））を入手でき、それに（ＰＲ−ＥＮＴＩＴＹ）を適用して（ＣＫ）を得ることができ、（ＣＫ）を（ＣＫ（ｃｏｎｔｅｎｔ））に適用して、コンテンツ３０４のレンダリングのためにコンテンツ３０４をもたらすことができる。その結果、パブリッシングユーザは、オフラインのままでありながら、これによってオフラインパブリッシュされたコンテンツ３１０を操作し続けることができる。

前記によれば、図９を参照すると、パブリッシングユーザは、コンテンツ３０４／３１０をオフラインパブリッシュし、それ自体に、そのようなコンテンツ３０４／３１０に関するオフラインパブリッシャライセンス８２０を、下記の形で発行する。

予備的に、諒解されなければならないように、コンテンツ３０４が、適当な形で開発され、コンテンツキー（ＣＫ）に従って暗号化され（ステップ９０１）、パブリッシングユーザが、適当な情報｛（ＰＵ−ＤＲＭ（ＣＫ））および（ＣＫ（ｒｉｇｈｔｓｄａｔａ））など｝を用いてコンテンツ３０４の権利ラベルを作成する（ステップ９０３）。その後、パブリッシングユーザは、おそらくは既にＤＲＭサーバ３２０からのＯＬＰ証明書８１０を所有しているが、そのようなＯＬＰ証明書８１０を入手し（ステップ９０５）、その署名および証明書のチェーン（ルートオーソリティにつながる）に基づいてこれを検証する（ステップ９０７）。諒解されなければならないように、そのような検証は、実際には、パブリッシングユーザのコンピューティングデバイス１４上の信頼されるコンポーネント１８によって実行される。検証が成功であると仮定すると、パブリッシングユーザ／信頼されるコンポーネント１８（以下では「パブリッシングユーザ」と称する）は、ＯＬＰ証明書８１０から（ＰＵ−ＥＮＴＩＴＹ（ＰＲ−ＯＬＰ））を検索し（ステップ９０９）、（ＰＲ−ＥＮＴＩＴＹ）を（ＰＵ−ＥＮＴＩＴＹ（ＰＲ−ＯＬＰ））に適用して（ＰＲ−ＯＬＰ）を入手し（ステップ９１１）その後、そのような（ＰＲ−ＯＬＰ）を用いて、作成された権利ラベルに署名して、ＳＲＬ３０８を作成する（ステップ９１３）。

その後、パブリッシングユーザは、そのようなＳＲＬ３０８およびそれを作るのに使用されたＯＬＰ証明書８１０を、コンテンツ３０４に連結して、セルフパブリッシュされたコンテンツ３１０を形成し（ステップ９１５）、そのような権利管理されたコンテンツ３１０は、したがって、別のユーザに配布することができる。しかし、パブリッシングユーザがコンテンツ３１０の使用またはレンダリングを継続するためには、そのようなパブリッシングユーザが、それ自体に、対応するオフラインパブリッシャライセンス８２０を発行しなければならない。

したがって、パブリッシングユーザは、それ自体のための適当な権利データを定義し、コンテンツキー（ＣＫ）に従ってこれを暗号化して、（ＣＫ（ｒｉｇｈｔｓｄａｔａ））をもたらすことによって、パブリッシャライセンス８２０を作成する（ステップ９１７）。ここで、そのような権利データを、コンテンツ３１０からのＳＲＬ３０８から入手でき、セルフパブリッシュされたコンテンツ３１０への部分的なアクセスまたはフルアクセスをパブリッシングユーザに許可する権利データのデフォルトの組とすることができ、あるいは、別のソースから導出することができることに留意されたい。さらに、パブリッシングユーザは、（ＰＵ−ＥＮＴＩＴＹ）に従ってコンテンツキー（ＣＫ）を暗号化して、（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））を形成する（ステップ９１９）。そのような（ＣＫ（ｒｉｇｈｔｓｄａｔａ））および（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））が、パブリッシャライセンス８２０にフォーマットされ（ステップ９２１）、ＯＬＰ証明書８１０およびその証明書のチェーンが、付加され（ステップ９２３）、そのようなパブリッシャライセンス８２０が、ステップ９１１で入手された（ＰＲ−ＯＬＰ）に基づいて署名される（ステップ９２５）。ここで、コンテンツ３０４（すなわち（ＣＫ（ｃｏｎｔｅｎｔ）））、パブリッシングライセンス８２０、およびＯＬＰ証明書が組み合わされて、信頼されるオーソリティに戻るディジタルアイテムのチェーン８３０が形成されることに留意されたい。

パブリッシングユーザがパブリッシュされたコンテンツ３１０をレンダリングするためには、図１０を参照すると、そのようなパブリッシングユーザは、ＤＲＭサーバ３２０に連絡する必要はなく、その代わりに、ルート証明書に署名するのに使用された信頼されるオーソリティの秘密キーに対応する公開キーを入手し（ステップ１００１）、ルート証明書を検証し（ステップ１００３）、たとえばチェーン内の中間証明書ごとに、前の証明書から公開キーを入手し、それを使用して証明書の署名を検証することによって、チェーン内の中間証明書のそれぞれを検証する（ステップ１００５）。その後、チェーン内の最後の証明書からの（ＰＵ−ＤＲＭ）を使用して、ＯＬＰ証明書８１０の署名（すなわちＳ（ＰＲ−ＤＲＭ））を検証し（ステップ１００７）、ＯＬＰ証明書８１０から（ＰＵ−ＯＬＰ）を入手し（ステップ１００９）、その（ＰＵ−ＯＬＰ）を使用して、パブリッシャライセンス８２０の署名（すなわちＳ（ＰＲ−ＯＬＰ））を検証する（ステップ１０１０）。

パブリッシャライセンス８２０が検証されたならば、それから（ＣＫ（ｒｉｇｈｔｓｄａｔａ））および（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））が検索され（ステップ１０１１）、（ＰＲ−ＥＮＴＩＴＹ）が（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））に適用されて（ＣＫ）がもたらされ（ステップ１０１３）、（ＣＫ）が（ＣＫ（ｒｉｇｈｔｓｄａｔａ））に適用されて権利データがもたらされる（ステップ１０１５）。ここで諒解されなければならないように、権利データが、パブリッシングユーザのコンピューティングデバイス１４の信頼されるコンポーネント１８によって再検討されて、その権利データによって、求められる形でのレンダリングが許可されることが判定され（ステップ１０１７）、したがって、その信頼されるコンポーネントによって、コンテンツ３１０からの（ＣＫ（ｃｏｎｔｅｎｔ））に（ＣＫ）が適用されてコンテンツがもたらされ（ステップ１０１９）、そのコンテンツが、実際のレンダリングのために適当なレンダリングアプリケーションに転送される（ステップ１０２１）。したがって、図１０のステップによって、要するに、信頼されるオーソリティからコンテンツ３０４まで、ディジタルアイテムのチェーン８３０がトラバースされる。

想像されるように、信頼されるコンポーネント１８によって、（ＣＫ）が（ＣＫ（ｃｏｎｔｅｎｔ））に適用されて、まず権利データを再検討することなく、どの権利データによって許可または拒否することができるかに無関係にコンテンツをもたらすことができるが、信頼されるコンポーネント１８は、信頼され、権利データを再検討し、その権利データによってそのコンテンツのレンダリングが許可されることをそれ自体で満足した後に限って、コンテンツを実際に作るように構成されている。やはり、パブリッシャライセンス８２０を有することの結果として、パブリッシングユーザは、オフラインパブリッシュされるコンテンツ３１０を操作し続けることができると同時に、ＤＲＭサーバ３２０に連絡する必要がない限り、オフラインのままであることができる。

ＤＲＭサーバのエンロールメントおよびサブエンロールメント
図３に示されたアーキテクチャには、単一のＤＲＭサーバ３２０だけが示されている。しかし、諒解できるように、そのアーキテクチャに、複数のＤＲＭサーバ３２０を含めることができ、実際に含まれる可能性が高い。具体的に言うと、本発明の一実施形態では、そのアーキテクチャに、ＤＲＭサーバ３２０の分散ネットワークが含まれる。本発明の趣旨および範囲から逸脱せずに、そのようなＤＲＭサーバ３２０のそれぞれが、特定の機能を有することができ、ＤＲＭサーバ３２０のすべてを、なんらかの適当な形で編成することができる。

たとえば、図１２に移ると、特定の組織が、ＳＲＬ３０８を作るための権利ラベルへの署名、ライセンス１６の発行、パブリッシングライセンス３２０の付与、ユーザへの証明書の発行、コンピューティングデバイス１４への証明書の発行、および類似物のために１つまたは複数のユーザレベルＤＲＭサーバ３２０を有する場合がある。各そのようなユーザレベルＤＲＭサーバ３２０を、地理的に割り当てることができ、あるいは、たとえば機能または負荷に基づいて割り当てることができる。同様に、複数のユーザレベルＤＲＭサーバ３２０を監督するために、組織が、１つまたは複数のマネジメントＤＲＭサーバ３２０を有する場合がある。そのような組織ベースのＤＲＭサーバ３２０は、望まれる場合に、組織ファイアウォールの背後に配置することができる。

組織ベースのＤＲＭサーバ３２０のほかに、組織間ＤＲＭ機能性を促進する、組織を超えたＤＲＭサーバもある場合がある。たとえば、そのような組織を超えたサーバ３２０によって、組織の対があるＤＲＭコンテンツ１２を共有できるようにすることができる。また、他のすべてのＤＲＭサーバ３２０をイネーブルする監督ＤＲＭサーバ３２０のネットワークがある場合がある。たとえば、そのような監督ＤＲＭサーバ３２０によって、他のすべてのＤＲＭサーバ３２０を監督し、保守し、前に示した証明書のチェーンの基礎であるルートオーソリティまたは信頼されるオーソリティへの他のすべてのＤＲＭサーバ３２０の適当なリンケージをもたらすことができる。そのような非組織ベースのＤＲＭサーバ３２０は、組織ファイアウォールの背後に配置されない可能性が高い。

重大なことに、図１２のアーキテクチャの各ＤＲＭサーバ３２０は、それが信頼されることを保証できなければならない。したがって、上の証明書のチェーン議論から諒解されなければならないように、各ＤＲＭサーバ３２０は、このアーキテクチャにエンターする際に、図１３に示されたエンロールメント証明書１３１０を与えられる。重要なことに、本発明の一実施形態では、エンロールメント証明書１３１０が、既にアーキテクチャ内にある別の「エンローリング」ＤＲＭサーバ３２０（以下では「ＤＲＭ−Ｒサーバ３２０」と称する）によって、エンターするＤＲＭサーバ３２０（以下では「ＤＲＭ−Ｅサーバ３２０」と称する）に与えられる。また、重要なことに、エンローリングＤＲＭ−Ｒサーバ３２０から与えられるエンロールメント証明書１３１０に付加されているのが、エンローリングＤＲＭサーバ３２０のエンロールメント証明書１３１０、エンローリングＤＲＭ−Ｒサーバ３２０にエンロールするＤＲＭサーバ３２０のエンロールメント証明書１３１０など、ルートＤＭＲサーバ３２０までの、証明書のチェーン１３２０である。そのようなルートＤＲＭサーバ３２０は、ルートオーソリティまたは信頼されるオーソリティを表すことができ、あるいは、証明書のチェーン１３２０を、ルートオーソリティまたは信頼されるオーソリティに達する以上に延長することができる。諒解されなければならないように、そのようなエンロールメント証明書１３１０および証明書のチェーン１３２０が、組み合わされて、図８に示されたパブリッシングユーザなどのパブリッシングユーザにエンロールされたＤＲＭ−Ｅサーバ３２０または入ったＤＲＭ−Ｅサーバ３２０によって供給されるＯＬＰ証明書８１０に付加される証明書のチェーンを形成する。

本発明の一実施形態では、ＤＲＭ−Ｒサーバ３２０によってＤＲＭ−Ｅサーバ３２０に供給されるエンロールメント証明書１３１０が、ＸｒＭＬ１．２ベースの証明書などの形態である。諒解できるように、そのようなタイプの証明書１３１０は、サードパーティによって独立に提供されず、したがって、そのようなタイプの証明書１３１０は、そのような証明書１３１０の保有者に関するサードパーティによるすべての種類の独立のバウチングを表さない。

本発明の一実施形態では、特定のＤＲＭ−Ｅサーバ３２０がアーキテクチャにエンターする方法が、エンローリングＤＲＭ−Ｒサーバ３２０がエンターするＤＲＭ−Ｅサーバ３２０を知るかそれを信頼する理由を有するかどうかに依存する。そうでない場合には、ＤＲＭ−Ｅサーバ３２０は、それが信頼に値し、ＤＲＭアーキテクチャを実施することをＤＲＭ−Ｒサーバ３２０に証明することを要求されなければならない。そうである場合には、ＤＲＭ−Ｅサーバ３２０は、少なくとも同一の度合でない度合まで、それが信頼に値することをＤＲＭ−Ｒサーバ３２０に証明することを要求されてはならない。したがって、信頼しない／知らないＤＲＭ−Ｒサーバ３２０は、ＤＲＭ−Ｅサーバ３２０を「エンロール」するが、知っている／信頼するＤＲＭ−Ｒサーバ３２０は、ＤＲＭ−Ｅサーバ３２０を「サブエンロール」する。

通常、ＤＲＭ−Ｒサーバ３２０は、ＤＲＭ−Ｒサーバ３２０およびＤＲＭ−Ｅサーバ３２０の両方が同一の組織によってまたはその組織のために運営される場合に、ＤＲＭ−Ｅサーバ３２０を知る／信頼するが、知識／信頼は、本発明の趣旨および範囲から逸脱せずに他の状況からも生じる可能性がある。したがって、特定のＤＲＭ−Ｅサーバ３２０をアーキテクチャにエンロールする方法は、通常は、エンロールするＤＲＭ−Ｒサーバ３２０が組織に基づくか非組織に基づくかに依存する。その結果、非組織に基づくＤＲＭ−Ｒサーバ３２０は、ＤＲＭ−Ｅサーバ３２０を「エンロール」するが、組織に基づくＤＲＭ−Ｒサーバ３２０は、ＤＲＭ−Ｅサーバ３２０を「サブエンロール」する。

エンロールメント
本発明の一実施形態では、図１４を参照すると、知らない／信頼しないＤＲＭ−Ｒサーバ３２０は、下記の形でＤＲＭ−Ｅサーバ３２０をエンロールする。

予備的に、知らない／信頼しないＤＲＭ−Ｒサーバ３２０によってエンロールされることを望むＤＲＭ−Ｅサーバ３２０が、そのようなＤＲＭ−Ｒサーバ３２０を知らない可能性が高いことを諒解されたい。したがって、本発明の一実施形態によれば、ＤＲＭ−Ｅサーバ３２０は、そのようなＤＲＭ−Ｅサーバ３２０をバウチすることを望むサードパーティからバウチング証明書１３３０を獲得しなければならない（ステップ１４０１）。通常、そのようなサードパーティは、そのようなバウチングを実行するためにＤＲＭ−Ｒサーバ３２０によって信頼される、たとえば米国カリフォルニア州マウンテンビューのＶＥＲＩＳＩＧＮ Ｃｏｒｐｏｒａｔｉｏｎ社などの独立の証明書発行エージェントである。そのようなバウチング証明書１３３０は、たとえば、Ｘ．５０９証明書などの形態とすることができる。ＤＲＭ−Ｅサーバ３２０のバウチングのために信頼されるサードパーティに頼るＤＲＭ−Ｒサーバ３２０において、そのようなＤＲＭ−Ｒサーバ３２０の、ＤＭＲ−Ｅサーバ３２０の悪い行いに関する責任が、軽減されることに留意されたい。

諒解されなければならないように、通常は、図１３にも示されているように、バウチング証明書１３３０には、その中に、公開キー（ＰＵ−Ｖ）および対応する秘密キー（ＰＲ−Ｖ）が組み込まれ、信頼されるサードパーティによって署名されており、検証のための既知のルートにつながる証明書のチェーンを添付することができる。通常そうであるように、バウチング証明書１３３０内の（ＰＲ−Ｖ）は、バウチング証明書１３３０の基礎である、そのためにバウチングされるＤＲＭ−Ｅサーバ３２０からアクセス可能な形で保護される。たとえば、図１３に示されているように、（ＰＲ−Ｖ）を、適当な公開キーに従って暗号化することができる。

ＤＲＭアーキテクチャ内で、エンターするＤＲＭ−Ｅサーバ３２０は、一意の識別を有しなければならない。ここで、ＤＲＭ識別が、（ＰＵ−Ｖ、ＰＲ−Ｖ）と別個である可能性が高いが、本発明の趣旨および範囲から逸脱せずに、ＤＲＭ識別が、そのような（ＰＵ−Ｖ、ＰＲ−Ｖ）と一致することもできることを理解されたい。したがって、そのような識別を確立するために、そのようなＤＲＭ−Ｅサーバ３２０は、新しい公開／秘密キー対（ＰＵ−Ｅ、ＰＲ−Ｅ）を生成するか入手する（ステップ１４０３）。また、ＤＲＭアーキテクチャ内で、エンロールするＤＲＭ−Ｅサーバ３２０が、どのエンティティが参加のオーソリティを取り消すことができるかを判断しなければならない。したがって、そのようなＤＲＭ−Ｅサーバ３２０は、そのような取り消すエンティティのそれぞれを、おそらくはその公開キーによって、リスト内で識別する（１４０５）。

ＤＲＭ−Ｅサーバ３２０は、そのＤＲＭ−Ｅサーバ３２０が、実際に、ステップ１４０１で入手されたバウチング証明書１３３０を所有することをエンロールするＤＲＭ−Ｒサーバ３２０に対して確立できなければならない。したがって、ＤＲＭ−Ｅサーバ３２０は、バウチング証明書１３３０からの（ＰＲ−Ｖ）を使用して（ＰＵ−Ｅ）を暗号化して、所有権のしるしとして（ＰＲ−Ｖ（ＰＵ−Ｅ））をもたらす、または（ＰＲ−Ｖ）を用いて（ＰＵ−Ｅ）に署名して、所有権のしるしとして（ＰＵ−Ｅ）Ｓ（ＰＲ−Ｖ）をもたらすのいずれかを行う（ステップ１４０７）。どちらの場合でも、（ＰＵ−Ｖ）を適用して（ＰＵ−Ｅ）を暗号化解除するか、署名を検証することによって、（ＰＲ−Ｖ）の所有が確立され、したがって、バウチング証明書１３３０の所有が確立される。

ここまでで、ＤＲＭ−Ｅサーバ３２０は、バウチング証明書１３３０、（ＰＵ−Ｅ）および（ＰＲ−Ｅ）、取り消しオーソリティリスト、ならびに所有権のしるしとして（ＰＲ−Ｖ（ＰＵ−Ｅ））または（ＰＵ−Ｅ）Ｓ（ＰＲ−Ｖ）を有する。エンロールメントを要求するために、そのようなＤＲＭ−Ｅサーバ３２０は、バウチング証明書１３３０、（ＰＵ−Ｅ）、取り消しオーソリティリスト、および（ＰＲ−Ｖ（ＰＵ−Ｅ））または（ＰＵ−Ｅ）Ｓ（ＰＲ−Ｖ）を、所有権のしるしとしてＤＲＭ−Ｒサーバ３２０に送り（ステップ１４０９）、ＤＲＭ−Ｒサーバ３２０は、そのような要求するＤＲＭ−Ｅサーバ３２０のエンロールに進む。要求またはその一部を、（ＰＲ−Ｅ）によって署名された証明書の形態とすることができることに留意されたい。

具体的に言うと、ＤＲＭ−Ｒサーバ３２０は、信頼されるサードパーティによるバウチング証明書１３３０の署名および既知のルートにつながる証明書のチェーンに基づいて、バウチング証明書１３３０を検証する（ステップ１４１１）。したがって、ＤＲＭ−Ｒサーバ３２０は、ＤＲＭ−Ｅサーバ３２０がバウチングされたことを確立する。また、ＤＲＭ−Ｒサーバ３２０は、要求からの（ＰＵ−Ｖ）を適用して、（ＰＵ−Ｅ）の暗号化解除または署名の検証のいずれかを行い、したがって、（ＰＲ−Ｖ）の所有を確立し、したがって、要求内のバウチング証明書１３３０の所有を確立することによって所有権のしるしを検証する（ステップ１４１０）。さらに、重要なことに、ＤＲＭ−Ｒサーバ３２０は、要求を尊重するかどうかを判断するのに必要なすべてのカスタムロジックを実行する（ステップ１４１３）。そのようなカスタムロジックは、本発明の趣旨および範囲から逸脱せずに任意の適当なロジックとすることができ、たとえば、ＤＭＲ−Ｅサーバ３２０および／またはそのオペレータに対するバックグラウンドチェック、ＤＲＭ−Ｅサーバ３２０が最新の信頼されるコンポーネント１８および／またはオペレーティングシステムあるいは類似物を有するかどうかの判定、ＤＲＭ−Ｅサーバ３２０が取り消しリストまたは他のウォッチリストにあるかどうかの判定、および類似物を含めることができる。

カスタムロジックによって、要求を尊重できると仮定すると、本発明の一実施形態では、ＤＲＭ−Ｒサーバ３２０が、ＤＲＭ−Ｅサーバ３２０のエンロールメント証明書１３１０を生成する（ステップ１４１５）。具体的に言うと、図１３からわかるように、ＤＲＭ−Ｒサーバ３２０は、エンロールメント証明書１３１０に下記を組み込む。

・ＤＲＭ−Ｒサーバ３２０の公開キー（ＰＵ−Ｒ）など、ＤＲＭ−Ｒサーバ３２０の識別子
・（ＰＵ−Ｅ）など、ＤＲＭ−Ｅサーバ３２０の識別子
・バウチング証明書１３３０を発行した信頼されるサードパーティ、バウチング証明書１３３０からの通し番号、およびバウチング証明書１３３０内で識別される発行者を含む、バウチング証明書１３３０からの識別のしるし
・たとえば日の範囲など、その間にエンロールメント証明書１３１０である範囲を指定する有効性範囲情報
・取り消しオーソリティリスト
・（ＰＵ−Ｒ）に対応するＤＲＭ−Ｒサーバ３２０の秘密キー（ＰＲ−Ｒ）に基づく署名
・他の適当な情報

そのような他の適当な情報には、証明書が発行された時刻；たとえばすべてのアクティビティ、アカウントアクティベーションのみ、権利ラベル署名のみ、コンテンツライセンス発行のみ、およびこれらの組合せなど、エンロールされるサーバが実行することを許可されるＤＲＭアクティビティの種類の表示；およびＤＲＭアクティビティの実行を許可される時間範囲を含めることができるが、これに制限はされない。証明書チェーン内のエンロールメント証明書１３１０を含む証明書を尊重するために、現在の時刻が有効性範囲内でなければならないという点で、許可される時間範囲が、有効性範囲と異なることに留意されたい。対照的に、子証明書の発行時刻は、ＤＲＭアクティビティを実行するために親証明書の許可される時間範囲内に含まれなければならない。

諒解されなければならないように、エンロールメント証明書１３１０を生成する際に、ＤＲＭ−Ｒサーバ３２０は、当初に、証明書情報を生成し、その後、カスタムロジックに追加情報を生成させるか、既存の情報を修正させることができる。そのようなカスタムロジックによって、たとえば、ＤＲＭ−Ｒサーバ３２０に適当な情報が含まれることを保証することができ、あるいは、事前定義のＤＲＭアーキテクチャポリシを実施することができる。もちろん、エンロールメント証明書１３１０の署名は、そのようなカスタムロジックが実行された後に作成される。また、諒解されなければならないように、ＤＲＭ−Ｒサーバ３２０は、信頼されるルートオーソリティにつながる証明書のチェーン１３２０を、生成されるエンロールメント証明書１３１０に付加し、その結果、生成されるエンロールメント証明書１３１０を、その証明書のチェーン１３２０に基づいて検証できるようにする。

特に、エンロールメント証明書１３１０に置かれるバウチング証明書１３３０からの識別のしるしが、かならずそのようなエンロールメント証明書１３１０と共に移動し、バウチング証明書１３３０へのブリッジとして働くことに留意されたい。したがって、やはり、そのような識別のしるしは、ＤＭＲ−Ｒサーバ３２０が、ＤＲＭ−Ｅサーバ３２０に関してバウチングするためのバウチング証明書１３３０の信頼されるサードパーティ発行者に頼ることを世界に示し、ＤＲＭ−Ｅサーバ３２０の悪い行いに関するそのようなＤＲＭ−Ｒサーバ３２０の責任が軽減される。

ＤＲＭ−Ｒサーバ３２０が、証明書のチェーン１３２０を付加されたエンロールメント証明書１３１０を成功裡に生成したならば、ＤＲＭー４サーバ３２０は、これをＤＲＭ−Ｅサーバ３２０に返し（ステップ１４１７）、現在、エンロールされているＤＲＭ−Ｅサーバ３２０が、将来の使用のためにこれを適当な位置に保管する（ステップ１４１９）。上述したように、エンロールメント証明書１３１０内の（ＰＵ−Ｅ）および対応する（ＰＲ−Ｅ）は、ＳＲＬ３０８を作るために権利ラベルに署名する場合、ＯＬＰ証明書８１０を発行する場合、およびＤＲＭアーキテクチャ内に他の形で参加する場合にＤＲＭ−Ｅサーバ３２０が（ＰＵ−ＤＲＭ）および（ＰＲ−ＤＲＭ）として使用する公開／秘密キー対である。したがって、そのようなエンロールメント証明書１３１０および証明書のチェーン１３２０が、組み合わされて、そのようなＯＬＰ証明書８１０および類似物に付加される証明書のチェーンを形成する。

サブエンロールメント
本発明の一実施形態では、図１５を参照すると、知っている／信頼するＤＲＭ−Ｒサーバ３２０は、下記の形でＤＲＭ−Ｅサーバ３２０をサブエンロールする。

予備的に、知っている／信頼するＤＲＭ−Ｒサーバ３２０によってサブエンロールされることを望むＤＲＭ−Ｅサーバ３２０が、それでも、そのような知識または信頼が完全でない可能性がある限り、そのようなＤＲＭ−Ｒサーバ３２０に対してそれ自体を識別することを要求されなければならないことを諒解されたい。しかし、そのような識別要件は、ＤＲＭ−Ｒサーバ３２０がＤＲＭ−Ｅサーバのある知識／信頼を有する限り、信頼されるサードパーティによる提供のレベルに達する必要はない。したがって、本発明の一実施形態では、ＤＲＭ−Ｅサーバ３２０が、ＤＲＭ−Ｒサーバ３２０によって認識可能であり、尊重されることが期待される、ＤＲＭ−Ｒサーバ３２０が満足するようにＤＲＭ−Ｅサーバ３２０を識別する、ある種の信任証１３４０（図１３）を入手するか、与えられる（ステップ１５０１）。

ＤＲＭ−Ｒサーバ３２０およびＤＲＭ−Ｅサーバ３２０の両方が、同一の組織内にある場合に、そのような信任証１３４０を、たとえば両方のサーバ３２０が共通のネットワーク上にある場合にネットワークＩＤ、両方のサーバ３２０が共通のドメインを共有する場合にドメイン、または類似物など、組織ベースの信任証とすることができる。ＤＲＭ−Ｒサーバ３２０およびＤＲＭ−Ｅサーバ３２０の両方が、同一の組織内にない場合には、そのような信任証１３４０を、両方のサーバ３２０が共通のネットワーク上にある場合にはネットワークＩＤ、両方のサーバ３２０が共通のドメインを共有する場合にはドメイン、または類似物とすることができ、あるいは、たとえばサードパーティによって発行され、ＤＲＭ−Ｒサーバ３２０によって認識される信任証などの他の信任証とすることができる。

この状況において、ＤＲＭ−Ｒサーバ３２０が、ＤＲＭ−Ｅサーバ３２０のバウチングのために信頼されるサードパーティに頼らず、したがって、ＤＲＭ−Ｅサーバ３２０の悪い行いに関するそのようなＤＲＭ−Ｒサーバ３２０の責任が軽減されないことに留意されたい。それでも、ＤＲＭ−Ｒサーバ３２０は、ＤＲＭ−Ｅサーバ３２０が実際にそのような悪い行いを実行しないことの知識またはそれへの信頼に基づいて、そのようなリスクを引き受ける。

前と同様に、ＤＲＭアーキテクチャ内で、エンターするＤＲＭ−Ｅサーバ３２０は、一意の識別を有しなければならない。ここで、ＤＲＭ識別が、信任証１３４０と別である可能性が高いが、本発明の趣旨から逸脱せずに、ＤＲＭ識別を信任証１３４０と同一にすることもできることを理解されたい。したがって、そのような識別を確立するために、そのようなＤＲＭ−Ｅサーバ３２０は、新しい公開／秘密キー対（ＰＵ−Ｅ、ＰＲ−Ｅ）を生成するか入手する（ステップ１５０３）。前と同様に、ＤＲＭアーキテクチャ内で、サブエンロールするＤＲＭ−Ｅサーバ３２０は、どのエンティティが参加のオーソリティを取り消すことができるかを判断しなければならない。したがって、そのようなＤＲＭ−Ｅサーバ３２０は、リスト内の各そのような取り消すエンティティを、おそらくはその公開キーによって識別する（ステップ１５０５）。

ここまでで、ＤＲＭ−Ｅサーバ３２０は、信任証１３４０、（ＰＵ−Ｅ）および（ＰＲ−Ｅ）、ならびに取り消しオーソリティリストを有する。サブエンロールメントを要求するために、そのようなＤＲＭ−Ｅサーバ３２０は、信任証１３４０、（ＰＵ−Ｅ）、および取り消しオーソリティリストをＤＲＭ−Ｒサーバ３２０に送り（ステップ１５０７）、ＤＲＭ−Ｒサーバ３２０は、そのような要求するＤＲＭ−Ｅサーバ３２０のサブエンロールに進行する。前と同様に、要求またはその一部を、（ＰＲ−Ｅ）によって署名された証明書の形態とすることができる。

具体的に言うと、ＤＲＭ−Ｒサーバ３２０は、どのロジックまたはリソースが検証に必要であり、使用可能であるかに基づいて信任証１３４０を検証する（ステップ１５０９）。したがって、ＤＲＭ−Ｒサーバ３２０は、検証された信任証１３４０に基づいて、ＤＲＭ−Ｅサーバ３２０がＤＲＭアーキテクチャを尊重し、従うために信頼されることを確立する。さらに、前と同様に、ＤＲＭ−Ｒサーバ３２０は、要求を尊重するかどうかを判断するのに必要なカスタムロジックを実行する（ステップ１５１１）。

カスタムロジックによって、要求を尊重できると仮定すると、本発明の一実施形態では、ＤＲＭ−Ｒサーバ３２０が、ＤＲＭ−Ｅサーバ３２０のサブエンロールメント証明書１３１０を生成する（ステップ１５１３）。具体的に言うと、図１３からわかるように、ＤＲＭ−Ｒサーバ３２０は、サブエンロールメント証明書１３１０に下記を組み込む。

・ＤＲＭ−Ｒサーバ３２０の公開キー（ＰＵ−Ｒ）など、ＤＲＭ−Ｒサーバ３２０の識別子
・（ＰＵ−Ｅ）など、ＤＲＭ−Ｅサーバ３２０の識別子
・信任証１３４０またはそれへの参照
・たとえば日の範囲など、そのサブ間にエンロールメント証明書１３１０である範囲を指定する有効性範囲情報
・取り消しオーソリティリスト
・（ＰＵ−Ｒ）に対応するＤＲＭ−Ｒサーバ３２０の秘密キー（ＰＲ−Ｒ）に基づく署名
・他の適当な情報

前と同様に、サブエンロールメント証明書１３１０を生成する際に、ＤＲＭ−Ｒサーバ３２０は、当初に、証明書情報を作成し、カスタムロジックに、追加情報を生成させるか、既存の情報を修正させる。やはり、サブエンロールメント証明書１３１０の署名が、カスタムロジックを実行した後に作成される。前と同様に、ＤＲＭ−Ｒサーバ３２０は、信頼されるルートオーソリティにつながる証明書のチェーン１３２０を、生成されたサブエンロールメント証明書１３１０に付加し、その結果、生成されたサブエンロールメント証明書１３１０を、その証明書のチェーン１３２０に基づいて検証できるようにする。

ここで、信任証１３４０またはそれへの参照が、本質的に必要とは考えられないが、それでも完全を期して含めることができることに留意されたい。バウチング証明書がこのサブエンロールメントシナリオで必要でない限り、サブエンロールメント証明書１３１０に、バウチング証明書１３３０からの識別のしるしが含まれないことにも留意されたい。

ＤＲＭ−Ｒサーバ３２０が、付加された証明書のチェーン１３２０によってサブエンロールメント証明書１３１０を成功裡に生成したならば、ＤＲＭ−Ｒサーバ３２０は、これをＤＲＭ−Ｅサーバ３２０に返し（ステップ１５１５）、現在はサブエンロールされたＤＲＭ−Ｅサーバ３２０は、将来の使用のためにこれを適当な位置に保管する（ステップ１５１７）。前と同様に、サブエンロールメント証明書１３１０の（ＰＵ−Ｅ）および対応する（ＰＲ−Ｅ）は、ＤＲＭ−Ｅサーバ３２０が、ＳＲＬ３０８を作るために権利ラベルに署名する場合、ＯＬＰ証明書８１０を発行する場合、およびＤＲＭアーキテクチャ内に他の形で参加する場合に（ＰＵ−ＤＲＭ）および（ＰＲ−ＤＲＭ）として使用する公開／秘密キー対である。したがって、そのようなサブエンロールメント証明書１３１０およびチェーン１３２０が、組み合わされて、そのようなＯＬＰ証明書８１０および類似物に付加される証明書のチェーンを形成する。

結論
本発明に関連して実行されるプロセスを実現するのに必要なプログラミングは、比較的単純であり、当業者に明白である。したがって、そのようなプログラミングは、本明細書に添付しない。任意の特定のプログラミングを使用して、本発明の趣旨および範囲から逸脱せずに本発明を実現することができる。

本発明では、ディジタル権利管理（ＤＲＭ）およびディジタル権利実施のアーキテクチャおよび方法によって、任意の形態のディジタルコンテンツの制御されたレンダリングまたは制御されたプレイが可能になり、そのような制御は、柔軟であり、そのようなディジタルコンテンツのコンテンツオーナー／デベロッパによって定義可能である。このアーキテクチャによって、そのような制御されたレンダリングが、特にオフィスまたは組織環境あるいは、ドキュメントが個人の異なるグループまたは個人のクラスの間で共有される場合に、可能になり、促進される。そのようなアーキテクチャには、承認を付与するＤＲＭサーバ３２０をアーキテクチャにエンロール／サブエンロールするメカニズムが含まれる。

本発明の概念から逸脱せずに、上述の実施形態に対して変更を行うことができることを諒解されたい。たとえば、ライセンスまたは権利ラベルが、その中の権利データに基づいて署名される場合に、そのような権利データは、必ずしも暗号化される必要がない。同様に、エンロールメント証明書またはサブエンロールメント証明書１３１０を要求し、構築する際に、取り消しオーソリティリストおよび他の類似する情報を、必ずしも使用する必要がない。したがって、本発明が開示された特定の実施形態に限定されるのではなく、請求項によって定義される本発明の趣旨および範囲に含まれる修正形態を含むことが意図されていることを理解されたい。

本発明を実施することができる例示的であり非制限的なコンピューティング環境を表すブロック図である。 本発明を実施することができるさまざまなコンピューティングデバイスを有する例示的なネットワーク環境を表すブロック図である。 ディジタルコンテンツをパブリッシュする、本発明によるシステムおよび方法の好ましい実施形態を示す機能ブロック図である。 権利管理されたディジタルコンテンツをパブリッシュする、本発明による方法の好ましい実施形態を示す流れ図である。 図４の方法によって作られる署名付き権利ラベルの構造を示すブロック図である。 権利管理されたディジタルコンテンツをライセンシングする、本発明によるシステムおよび方法の好ましい実施形態を示すブロック図である。 権利管理されたディジタルコンテンツをライセンシングする、本発明による方法の好ましい実施形態を示す流れ図である。 権利管理されたディジタルコンテンツをライセンシングする、本発明による方法の好ましい実施形態を示す流れ図である。 本発明の一実施形態による、ユーザがオフラインパブリッシングを実行できるようにするためにＤＲＭサーバによってユーザに発行される証明書を示すブロック図である。 本発明の一実施形態による、パブリッシングユーザによってオフラインでパブリッシュされたコンテンツをそのユーザがレンダリングできるようにするパブリッシャライセンスと共に図７の証明書を示すブロック図である。 本発明の一実施形態による、図８のパブリッシングライセンスを入手するために、パブリッシングユーザによって実行されるキーステップを示すフローチャートである。 本発明の一実施形態による、対応するコンテンツをレンダリングするために図９の入手されたパブリッシングライセンスを使用するためにパブリッシングユーザによって実行されるキーステップを示すフローチャートである。 信頼ベースシステムの例の実施アーキテクチャを示すブロック図である。 本発明のアーキテクチャに存在することができるＤＲＭサーバなどの複数のＤＲＭサーバを示すブロック図であり、各（エンターする）ＤＲＭサーバが、これにエンロールメント証明書を発行する別の（エンローリング）ＤＲＭサーバによってアーキテクチャにエンロールまたはサブエンロールされる。 少なくともいくつかの場合にエンターするＤＲＭサーバによってエンローリングＤＲＭサーバに提示されるバウチング証明書と共に図１２のエンロールメント証明書を示すブロック図である。 エンターするＤＲＭサーバをエンロール（図１４）またはサブエンロール（図１５）するために図１３および１４のエンローリングＤＲＭサーバおよびエンターするＤＲＭサーバによって実行されるキーステップを示すフローチャートである。 エンターするＤＲＭサーバをエンロール（図１４）またはサブエンロール（図１５）するために図１３および１４のエンローリングＤＲＭサーバおよびエンターするＤＲＭサーバによって実行されるキーステップを示すフローチャートである。

符号の説明

３００ クライアント
３０２ コンテンツ準備アプリケーション
３０４ 暗号化されたディジタルコンテンツファイル
３０６ ディジタル権利管理（ＤＲＭ）アプリケーションプログラムインターフェース（ＡＰＩ）
３０８ 署名付き権利ラベル（ＳＲＬ）
３１０ 権利管理されたコンテンツファイル
３２０ ＤＲＭサーバ
３３０ 通信ネットワーク

Claims (74)

1. ＤＲＭ機能性を実行する複数のＤＲＭサーバを有するディジタル権利管理（ＤＲＭ）システムと組み合わされ、エンターするＤＲＭ−Ｅサーバが前記システム内で信頼されるように、前記エンターするＤＲＭ−Ｅサーバを、エンロールするＤＲＭ−Ｒサーバによってシステムにエンロール方法であって、
   前記ＤＲＭ−Ｅサーバは、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステム内で識別する公開／秘密キー対（ＰＵ−Ｅ、ＰＲ−Ｅ）を獲得するステップと
   前記ＤＲＭ−Ｅサーバが、その提供する識別を獲得するステップと、
   前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｒサーバにエンロールメント要求を送るステップであって、そこでは、前記要求は、前記提供する識別および（ＰＵ−Ｅ）を含むと、
   前記ＤＲＭ−Ｒサーバが、前記提供する識別を検証するステップと、
   前記ＤＲＭ−Ｒサーバが、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするために、前記ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成するステップであって、そこでは、前記生成されるエンロールメント証明書が、少なくとも部分的に（ＰＵ−Ｅ）に基づくステップと、
   前記ＤＲＭ−Ｒサーバが、前記生成されたエンロールメント証明書を前記要求するＤＲＭ−Ｅサーバに返すステップと、
   現在、エンロールされたＤＲＭ−Ｅサーバは、将来の使用のために適当な位置に前記返されたエンロールメント証明書を保管するステップであって、そこでは、前記エンロールメント証明書を有する前記ＤＲＭ−Ｅサーバは、前記ＤＲＭシステム内でＤＲＭドキュメントを発行するためにこれを使用することができるステップと
   を含むことを特徴とする方法。
2. 前記ＤＲＭ−Ｒサーバは、前記ＤＲＭ−Ｅサーバを信頼する既存の基礎を有しておらず、
   前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｅサーバのバウチングをいとわない当事者からのバウチング証明書を含む提供する識別を獲得するステップであって、そこでは、前記バウチング証明書は、その中に公開キー（ＰＵ−Ｖ）および対応する秘密キー（ＰＲ−Ｖ）を組み込むステップと、
   前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｅサーバが前記バウチング証明書を所有することを示すための所有権のしるし（ｉｎｄｉｃｉａ）を定式化するために（ＰＵ−Ｅ）および（ＰＲ−Ｖ）を使用するステップと、
   前記ＤＲＭ−Ｅサーバは、前記ＤＲＭ−Ｒサーバにエンロールメント要求を送るステップであって、そこでは、前記要求は、前記バウチング証明書、（ＰＵ−Ｅ）、および前記所有権のしるしを含むステップと、
   前記ＤＲＭ−Ｒサーバが、前記バウチング証明書を検証するステップと、
   前記ＤＲＭ−Ｒサーバが、前記所有権のしるしを検証するステップと、
   前記ＤＲＭ−Ｒサーバが、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするために前記ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成するステップであって、そこでは、当該生成されるエンロールメント証明書が、前記バウチング証明書および（ＰＵ−Ｅ）に少なくとも部分的に基づくステップと
   を含むことを特徴とする請求項１に記載の方法。
3. 前記ＤＲＭ−Ｅサーバが、前記バウチングを実行するために前記ＤＲＭ−Ｒサーバによって信頼され、頼られる独立の証明書発行エージェントから前記バウチング証明書を獲得するステップを含むことを特徴とする請求項２に記載の方法。
4. 前記ＤＲＭ−Ｅサーバが、Ｘ．５０９バウチング証明書を獲得するステップを含むことを特徴とする請求項２に記載の方法。
5. 前記ＤＲＭ−Ｅサーバが、前記バウチングの当事者によって署名され、検証のために既知のルートにつながる証明書のチェーンが付随するバウチング証明書を獲得するステップと、
   前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバがバウチングされたことを確立するために、前記バウチングの当事者による前記バウチング証明書の署名および証明書の前記チェーンに基づいて前記バウチング証明書を検証するステップと
   を含むことを特徴とする請求項２に記載の方法。
6. 前記ＤＲＭ−Ｅサーバが、前記所有権のしるしとして（ＰＲ−Ｖ（ＰＵ−Ｅ））をもたらすために（ＰＵ−Ｅ）を暗号化するために（ＰＲ−Ｖ）を使用するか、または前記所有権のしるしとして（ＰＵ−Ｅ）Ｓ（ＰＲ−Ｖ）をもたらすために（ＰＲ−Ｖ）によって（ＰＵ−Ｅ）に署名するかを実行するステップと、
   前記ＤＲＭ−Ｒサーバが、（ＰＵ−Ｅ）を暗号化解除するため、または前記ＤＲＭ−Ｅサーバが（ＰＲ−Ｖ）を所有し、それ故、バウチング証明書を所有することを確立するために前記署名を検証するために、前記要求からの（ＰＵ−Ｖ）を適用することによって前記所有権のしるしを検査するステップと
   を含むことを特徴とする請求項２に記載の方法。
7. 前記ＤＲＭ−Ｒサーバは、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）、前記バウチング証明書を識別するための識別のしるし、および前記ＤＭＲ−Ｒサーバの秘密キーに基づく署名を含めるためのエンロールメント証明書を生成するステップであって、そこでは、これによって、前記エンロールメント証明書内の前記バウチング証明書に関する前記識別のしるしは、前記バウチング証明書へのブリッジとして働き、前記ＤＲＭ−Ｒサーバが前記ＤＲＭ−Ｅサーバに関してバウチングする前記バウチングの当事者を信頼しており頼っていることを示すステップを含むことを特徴とする請求項２に記載の方法。
8. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｒサーバの識別子として前記ＤＲＭ−Ｒサーバの公開キーをさらに含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項７に記載の方法。
9. 前記ＤＲＭ−Ｒサーバが、その間に前記エンロールメント証明書が有効である範囲を指定する有効性範囲情報をさらに含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項７に記載の方法。
10. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバを信頼する既存の基礎を有し、前記方法は、
    前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｒサーバによって認識可能であり、これよって尊重されることが期待される信任証を含む、前記ＤＲＭ−Ｅサーバの提供する識別を獲得するステップと、
    前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｒサーバにエンロールメント要求を送るステップであって、そこでは、前記要求は、前記信任証および（ＰＵ−Ｅ）を含むステップと、
    前記ＤＲＭ−Ｒサーバが、前記信任証を検証するステップと、
    前記ＤＲＭ−Ｒサーバが、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするための、ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成するステップであって、そこでは、前記生成されるエンロールメント証明書が、前記信任証および（ＰＵ−Ｅ）に少なくとも部分的に基づくステップと
    を含むことを特徴とする請求項１に記載の方法。
11. 前記ＤＲＭ−Ｅサーバが、ネットワークＩＤまたはドメインＩＤからなる群から選択された信任証およびサードパーティによって発行された信任証を獲得するステップを含むことを特徴とする請求項１０に記載の方法。
12. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）、前記信任証を識別するための識別のしるし、および前記ＤＲＭ−Ｒサーバの秘密キーに基づく署名を含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項１０に記載の方法。
13. 前記ＤＲＭ−Ｒサーバが、その識別子として前記ＤＲＭ−Ｒサーバの公開キーをさらに含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項１２に記載の方法。
14. 前記ＤＲＭ−Ｒサーバが、その間に前記エンロールメント証明書が有効である範囲を指定する有効性範囲情報をさらに含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項１２に記載の方法。
15. 前記ＤＲＭ−Ｒサーバが、前記要求を尊重するかどうかを判断するためにカスタムロジックを実行するステップを含むことを特徴とする請求項１に記載の方法。
16. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバおよび／またはそのオペレータに対するバックグラウンドチェックの実行、前記ＤＲＭ−Ｅサーバおよびまたはその一部は最新であるかどうかの判定、前記ＤＲＭ−Ｅサーバは取り消しリストまたはウォッチリストにあるかどうかの判定、およびこれらの組合せからなる群から選択されるカスタムロジックを実行するステップを含むことを特徴とする請求項１５に記載の方法。
17. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）および前記ＤＲＭ−Ｒサーバの秘密キーに基づく署名を含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項１に記載の方法。
18. 前記ＤＲＭ−Ｒサーバが、その識別子として前記ＤＲＭ−Ｒサーバの公開キーをさらに含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項１７に記載の方法。
19. 前記ＤＲＭ−Ｒサーバが、その間に前記エンロールメント証明書が有効である有効性範囲情報をさらに含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項１７に記載の方法。
20. 前記ＤＲＭ−Ｒサーバが、前記提供する識別を識別する識別のしるしをさらに含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項１７に記載の方法。
21. 前記ＤＲＭ−Ｒサーバが、前記エンロールメント証明書内の情報の少なくとも一部を生成するためにカスタムロジックを使用することによって前記エンロールメント証明書を生成するステップを含むことを特徴とする請求項１に記載の方法。
22. 前記ＤＲＭ−Ｒサーバが、前記生成されるエンロールメント証明書が信頼されるルートオーソリティにつながる証明書のチェーンに基づいて検証され得るようにするための、前記証明書のチェーンを生成される前記エンロールメント証明書に付加するステップを含むことを特徴とする請求項１に記載の方法。
23. 前記ＤＲＭ−Ｅサーバが、取り消しオーソリティリスト内でオーソリティを有する少なくとも１つのエントリを識別するステップであって、そこでは、該識別により前記ＤＲＭシステム内の前記ＤＲＭ−Ｅサーバのエンロールメントを取り消し、前記ＤＲＭ−Ｅサーバは、エンロールメント要求を前記ＤＲＭ−Ｒサーバに送るステップを含み、前記要求は、前記提供する識別、（ＰＵ−Ｅ）、および前記取り消しオーソリティリストを含み、前記ＤＲＭ−Ｒサーバは、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするためたの、ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成し、当該生成されるエンロールメント証明書が、（ＰＵ−Ｅ）および前記取り消しオーソリティリストに少なくとも部分的に基づくことを特徴とする請求項１に記載の方法。
24. 前記ＤＲＭ−Ｅサーバが、前記取り消しオーソリティリスト内の各エンティティを、その公開キーによって識別するステップを含むことを特徴とする請求項２３に記載の方法。
25. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）、前記要求からの前記取り消しオーソリティリスト、および前記ＤＲＭ−Ｒサーバの秘密キーに基づく署名を含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項２３に記載の方法。
26. 前記ＤＲＭ−Ｒサーバが、ＸｒＭＬエンロールメント証明書を生成するステップを含むことを特徴とする請求項１に記載の方法。
27. ＤＲＭ機能性を実行する複数のＤＲＭサーバを有するディジタル権利管理（ＤＲＭ）システムと組み合わされる方法であって、
    エンターするＤＲＭ−Ｅサーバが前記システム内で信頼されるように、エンロールするＤＲＭ−Ｒサーバによって、前記エンターするＤＲＭ−Ｅサーバを前記システムにエンロールし、
    前記ＤＲＭ−Ｅサーバが、前記ＤＲＭシステム内で前記ＤＲＭ−Ｅサーバを識別するために公開／秘密キー対（ＰＵ−Ｅ、ＰＲ−Ｅ）を獲得するステップと、
    前記ＤＲＭ−Ｅサーバが、その提供する識別を獲得するステップと、
    前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｒサーバにエンロールメント要求を送るステップであって、そこでは、前記要求は、前記提供する情報および（ＰＵ−Ｅ）を含み、前記ＤＲＭ−Ｒサーバは、前記提供する識別を検証し、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするために前記ＤＲＭ−Ｅサーバのディジタルエンロールメント証明書を生成し、当該生成されるエンロールメント証明書は、少なくとも部分的に（ＰＵ−Ｅ）に基づき、前記ＤＲＭ−Ｒサーバは、前記生成されるエンロールメント証明書を前記要求するＤＲＭ−Ｅサーバに返すステップと、
    前記現在、エンロールされたＤＲＭ−Ｅサーバが、将来の使用のために適当な位置に前記返されたエンロールメント証明書を保管するステップであって、前記エンロールメント証明書を有する前記ＤＲＭ−Ｅサーバが、前記ＤＲＭシステム内でＤＲＭドキュメントを発行するために前記エンロールメント証明書を使用することができるステップと
    を含むことを特徴とする方法。
28. 前記ＤＲＭ−Ｒサーバは、前記ＤＲＭ−Ｅサーバを信頼する既存の基礎を有しておらず、
    前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｅサーバに関するバウチングをいとわない当事者からのバウチング証明書を含む提供する識別を獲得するステップであって、前記バウチング証明書は、その中に、公開キー（ＰＵ−Ｖ）および対応する秘密キー（ＰＲ−Ｖ）を組み込むステップと、
    前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｅサーバは前記バウチング証明書を所有することを示すために所有権のしるしを定式化するために（ＰＵ−Ｅ）および（ＰＲ−Ｖ）を使用するステップと、
    前記ＤＲＭ−Ｅサーバが、エンロールメント要求を前記ＤＲＭ−Ｒサーバに送るステップであって、そこでは、前記要求は、前記バウチング証明書、（ＰＵ−Ｅ）、および前記所有権のしるしを含み、前記ＤＲＭ−Ｒサーバが、前記バウチング証明書を検証し、前記所有権のしるしを検査し、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするための、ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成し、前記ディジタルエンロールメント証明書は、少なくとも部分的に前記バウチング証明書および（ＰＵ−Ｅ）に基づくステップと
    を含むことを特徴とする請求項２７に記載の方法。
29. 前記ＤＲＭ−Ｅサーバが、前記バウチングを実行するために前記ＤＲＭ−Ｒサーバによって信頼され、頼られる独立の証明書発行エージェントから前記バウチング証明書を獲得するステップを含むことを特徴とする請求項２８に記載の方法。
30. 前記ＤＲＭ−Ｅサーバが、Ｘ．５０９バウチング証明書を獲得するステップを含むことを特徴とする請求項２８に記載の方法。
31. 前記ＤＲＭ−Ｅサーバが、前記バウチングの当事者によって署名され、検証のために既知のルートにつながる証明書のチェーンが付随するバウチング証明書を獲得するステップを含み、前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバがバウチングされたことを確立するために、前記バウチングの当事者による前記バウチング証明書の前記署名および証明書の前記チェーンに基づいて前記バウチング証明書を検証することを特徴とする請求項２８に記載の方法。
32. 前記ＤＲＭ−Ｅサーバが、前記所有権のしるしとして（ＰＲ−Ｖ（ＰＵ−Ｅ））をもたらすために（ＰＵ−Ｅ）を暗号化するのに（ＰＲ−Ｖ）を使用すること、または前記所有権のしるしとして（ＰＵ−Ｅ）Ｓ（ＰＲ−Ｖ）をもたらすために（ＰＲ−Ｖ）を用いて（ＰＵ−Ｅ）に署名することの１つを実行するステップであって、（ＰＵ−Ｅ）を暗号化解除するための要求か、または、前記ＤＲＭ−Ｒサーバが、（ＰＲ−Ｖ）それゆえに、前記バウチング証明書を所有することを確立するための署名を検査するための要求を適用することによって、前記ＤＲＭ−Ｒは前記所有権のしるしを検査するステップを含むことを特徴とする請求項２８に記載の方法。
33. 前記現在、エンロールされたＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）、前記バウチング証明書を識別する識別のしるし、および前記ＤＲＭ−Ｒサーバの秘密キーに基づく署名を含む前記返されたエンロールメント証明書を保管するステップであって、そこでは、これによって、前記エンロールメント証明書内のバウチング証明書の識別のしるしが、前記バウチング証明書へのブリッジとして働き、前記ＤＲＭ−Ｅサーバをバウチングするために前記ＤＲＭ−Ｒサーバが前記バウチングの当事者を信頼しており、頼っていることを示すステップを含むことを特徴とする請求項２８に記載の方法。
34. 前記現在、エンロールされたＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｒサーバの識別子として前記ＤＲＭ−Ｒサーバの公開キーをさらに含む、返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項３３に記載の方法。
35. 前記現在、エンロールされたＤＲＭ−Ｅサーバが、その間に前記エンロールメント証明書が有効である範囲を指定する有効性範囲情報をさらに含む前記返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項３３に記載の方法。
36. 前記ＤＲＭ−Ｒサーバは、前記ＤＲＭ−Ｅサーバを信頼する既存の基礎を有し、
    前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｒサーバによって認識可能であり、これによって尊重されることが期待される信任証を含む前記ＤＲＭ−Ｅサーバの提供する識別を獲得するステップと、
    前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｒサーバにエンロールメント要求を送るステップであって、そこでは、前記要求は、前記信任証および（ＰＵ−Ｅ）を含み、前記ＤＲＭ−Ｒサーバは、前記信任証を検証し、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするために前記ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成し、当該生成されるエンロールメント証明書が、前記信任証および（ＰＵ−Ｅ）に少なくとも部分的に基づくステップと
    を含むことを特徴とする請求項２７に記載の方法。
37. 前記ＤＲＭ−Ｅサーバが、ネットワークＩＤまたはドメインＩＤからなる群から選択された信任証およびサードパーティによって発行された信任証を獲得するステップを含むことを特徴とする請求項３６に記載の方法。
38. 前記現在、エンロールされたＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）、前記信任証を識別する識別のしるし、および前記ＤＲＭ−Ｒサーバの秘密キーに基づく署名を含む、返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項３６に記載の方法。
39. 前記現在、エンロールされたＤＲＭ−Ｅサーバが、その識別子として前記ＤＲＭ−Ｒサーバの公開キーをさらに含む、返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項３８に記載の方法。
40. 前記現在、エンロールされたＤＲＭ−Ｅサーバが、その間に前記エンロールメント証明書が有効である範囲を指定する有効性範囲情報をさらに含む、返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項３８に記載の方法。
41. 前記現在、エンロールされたＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）、および前記ＤＲＭ−Ｒサーバの秘密キーに基づく署名を含む前記返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項２７に記載の方法。
42. 前記現在、エンロールされたＤＲＭ−Ｅサーバは、その識別子として前記ＤＲＭ−Ｒサーバの公開キーをさらに含む、返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項４１に記載の方法。
43. 前記現在、エンロールされたＤＲＭ−Ｅサーバは、その間に前記エンロールメント証明書が有効である範囲を指定する有効性範囲情報をさらに含む、返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項４１に記載の方法。
44. 前記現在、エンロールされたＤＲＭ−Ｅサーバは、前記提供する識別を識別する識別のしるしをさらに含む、返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項４１に記載の方法。
45. 前記現在、エンロールされたＤＲＭ−Ｅサーバが、前記生成されるエンロールメント証明書を信頼されるルートオーソリティにつながる証明書のチェーンに基づいて検証できるようにするために、前記証明書のチェーンを含む前記返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項２７に記載の方法。
46. 前記ＤＲＭ−Ｅサーバが、前記ＤＲＭシステム内の前記ＤＲＭ−Ｅサーバのエンロールメントを取り消すオーソリティを有する少なくとも１つのエンティティを取り消しオーソリティリスト内で識別するステップをさらに含み、前記ＤＲＭ−Ｅサーバは、エンロールメント要求を前記ＤＲＭ−Ｒサーバに送るステップを含み、前記要求は、前記提供する識別、（ＰＵ−Ｅ）、および前記取り消しオーソリティリストを含み、前記ＤＲＭ−Ｒサーバは、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするために前記ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成し、前記生成されるエンロールメント証明書が、（ＰＵ−Ｅ）および前記取り消しオーソリティリストに少なくとも部分的に基づくことを特徴とする請求項２７に記載の方法。
47. 前記ＤＲＭ−Ｅサーバが、前記取り消しオーソリティリスト内の各エンティティを、その公開キーによって識別するステップを含むことを特徴とする請求項４６に記載の方法。
48. 前記現在、エンロールされたＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）、前記要求からの前記取り消しオーソリティリスト、および前記ＤＲＭ−Ｒサーバの秘密キーに基づく署名を含む前記返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項４６に記載の方法。
49. 前記現在、エンロールされたＤＲＭ−Ｅサーバが、ＸｒＭＬエンロールメント証明書を保管する前記返されたエンロールメント証明書を保管するステップを含むことを特徴とする請求項２７に記載の方法。
50. ＤＭＲ機能性を実行する複数のＤＲＭサーバを有するディジタル権利管理（ＤＲＭ）システムと組み合わされる方法であって、前記方法は、エンターするＤＲＭ−Ｅサーバが前記システム内で信頼されるように、前記エンターするＤＲＭサーバをエンロールするＤＲＭ−Ｍサーバによってシステムにエンロールし、
    前記ＤＲＭ−Ｒサーバが、前記ＤＲＭシステム内でＤＲＭ−Ｅサーバを識別する、提供する識別および前記ＤＲＭ−Ｅサーバの公開キー（ＰＵ−Ｅ）を含む前記ＤＲＭ−Ｅサーバからのエンロールメント要求を受け取るステップと、
    前記ＤＲＭ−Ｒサーバが、前記提供する識別を検証するステップと、
    前記ＤＲＭ−Ｒサーバが、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするために前記ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成するステップであって、前記生成されるエンロールメント証明書が、（ＰＵ−Ｅ）に少なくとも部分的に基づくステップと、
    前記ＤＲＭ−Ｒサーバが、前記要求するＤＲＭ−Ｅサーバに前記生成されるエンロールメント証明書を返すステップであって、そこでは、前記現在、エンロールされたＤＲＭ−Ｅサーバが、将来の使用のために適当な位置に前記返されたエンロールメント証明書を保管し、前記エンロールメント証明書を有する前記ＤＲＭ−Ｅサーバが、前記ＤＲＭシステム内でＤＲＭドキュメントを発行するのに前記エンロールメント証明書を使用するステップと
    を含むことを特徴とする方法。
51. 前記ＤＲＭ−Ｒサーバは、前記ＤＲＭ−Ｅサーバを信頼する既存の基礎を有しておらず 前記ＤＲＭ−Ｒサーバは、ＤＲＭ−Ｅサーバからのエンロール要求を受け取るステップであって、そこでは前記エンロール要求は（ＰＵ−Ｅ）および提供の識別を含み、該提供の識別は前記ＤＲＭ−Ｅサーバに関するバウチングをいとわない当事者からのバウチング証明書を含み、前記バウチング証明書は、その中に、公開キー（ＰＵ−ＶＵ）および対応する秘密キー（ＰＲ−Ｖ）を組み込み、前記ＤＲＭ−Ｅサーバが、前記ＤＲＭ−Ｅサーバが前記バウチング証明書を所有することを示すために所有権のしるしを定式化するのに（ＰＵ−Ｅ）および（ＰＲ−Ｖ）を使用済みであり、前記エンロールメント要求が、さらに、前記所有権のしるしを含むステップと、
    前記ＤＲＭ−Ｒサーバが、前記バウチング証明書を検証するステップと、
    前記ＤＲＭ−Ｒサーバが、前記所有権のしるしを検査するステップと、
    前記ＤＲＭ−Ｒサーバが、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするために前記ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成するステップであって、そこでは、当該生成されるエンロールメント証明書が、前記バウチング証明書および（ＰＵ−Ｅ）に少なくとも部分的に基づくステップと
    を含むことを特徴とする請求項５０に記載の方法。
52. 前記ＤＲＭ−Ｒサーバが、前記バウチングを実行するために前記ＤＲＭ−Ｒサーバによって信頼され、頼られる独立の証明書発行エージェントからのバウチング証明書を含む前記ＤＲＭ−Ｅサーバからのエンロールメント要求を受け取るステップを含むことを特徴とする請求項５１に記載の方法。
53. 前記ＤＲＭ−Ｒサーバが、Ｘ．５０９バウチング証明書を含む前記ＤＲＭ−Ｅサーバからのエンロールメント要求を受け取るステップを含むことを特徴とする請求項５１に記載の方法。
54. 前記ＤＲＭ−Ｒサーバが、バウチングの当事者によって署名され、検証のために既知のルートにつながる証明書のチェーンが付随する、バウチング証明書を含むＤＲＭ−Ｅサーバからのエンロールメント要求を受け取るステップと、
    前記ＤＲＭ−Ｒサーバは、前記ＤＲＭ−Ｅサーバがバウチングされたことを確立するために、前記バウチングの当事者による前記バウチング証明書の前記署名および前記証明書のチェーンに基づいて前記バウチング証明書を検証するステップと
    を含むことを特徴とする請求項５１に記載の方法。
55. 前記ＤＲＭ−Ｅサーバは、（ＰＵ−Ｅ）を暗号化して前記所有権のしるしとして（ＰＲ−Ｖ（ＰＵ−Ｅ））をもたらすか、または、（ＰＲ−Ｖ）を使用するか、またはＰＲ−Ｖ）によって（ＰＵ−Ｅ）に署名して前記所有権のしるしとして（ＰＵ−Ｅ）Ｓ（ＰＲ−Ｖ）をもたらすステップを含み、さらに、前記要求からの（ＰＵ−Ｖ）を適用することによって前記ＤＲＭ−Ｒサーバが所有権のしるしを検査するステップであって、（ＰＵ−Ｅ）を暗号化解除するか、または、前記ＤＲＭ−Ｅサーバが（ＰＲ−Ｖ）、それ故、バウチング署名書を所有することを確立するための署名を検証するステップを含むことを特徴とする請求項５１に記載の方法。
56. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）、前記バウチング証明書を識別するための識別のしるし、および前記ＤＭＲ−Ｒサーバの秘密キーに基づく署名を含めるために前記エンロールメント証明書を生成するステップであって、そこでは、これによって、前記エンロールメント証明書内の前記バウチング証明書に関する前記識別のしるしは、前記バウチング証明書へのブリッジとして働き、前記ＤＲＭ−Ｒサーバが前記ＤＲＭ−Ｅサーバに関してバウチングする前記バウチングの当事者を信頼しており頼っていることを示すステップを含むことを特徴とする請求項５１に記載の方法。
57. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｒサーバの識別子として前記ＤＲＭ−Ｒサーバの公開キーをさらに含めるために前記エンロールメント証明書を生成するステップを含むことを特徴とする請求項５６に記載の方法。
58. 前記ＤＲＭ−Ｒサーバが、その間に前記エンロールメント証明書が有効である範囲を指定する有効性範囲情報をさらに含めるために前記エンロールメント証明書を生成するステップを含むことを特徴とする請求項５６に記載の方法。
59. 前記ＤＲＭ−Ｒサーバは、前記ＤＲＭ−Ｅサーバを信頼する既存の基礎を有し、
    前記ＤＲＭ−Ｒサーバは、（ＰＵ−Ｅ）と、提供の識別を含む、前記ＤＲＭ−Ｅサーバからのエンロールメント要求を受け取るステップであって、そこでは、前記提供の識別は前記ＤＲＭ−Ｒサーバによって認識可能であり尊重されると期待される信任証を有するステップと、
    前記ＤＲＭ−Ｒサーバが、前記信任証を検証するステップと、
    前記ＤＲＭ−Ｒサーバが、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするために前記ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成するステップであって、前記生成されるエンロールメント証明書が、前記信任証および（ＰＵ−Ｅ）に少なくとも部分的に基づくステップと
    を含むことを特徴とする請求項５０に記載の方法。
60. 前記ＤＲＭ−Ｒサーバが、ネットワークＩＤまたはドメインＩＤからなる群から選択された信任証およびサードパーティによって発行された信任証を含む前記ＤＲＭ−Ｅサーバからのエンロールメント要求を受け取るステップを含むことを特徴とする請求項５９に記載の方法。
61. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）、前記信任証を識別するための識別のしるし、および前記ＤＲＭ−Ｒサーバの秘密キーに基づく署名を含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項５９に記載の方法。
62. 前記ＤＲＭ−Ｒサーバが、その識別子として前記ＤＲＭ−Ｒサーバの公開キーをさらに含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項６１に記載の方法。
63. 前記ＤＲＭ−Ｒサーバが、その間に前記エンロールメント証明書が有効である範囲を指定する有効性範囲情報をさらに含めるために前記エンロールメント証明書を生成するステップを含むことを特徴とする請求項６１に記載の方法。
64. 前記ＤＲＭ−Ｒサーバが、前記要求を尊重するかどうかを判断するためにカスタムロジックを実行するステップを含むことを特徴とする請求項５０に記載の方法。
65. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバおよび／またはそのオペレータに対するバックグラウンドチェックを実行すること、前記ＤＲＭ−Ｅサーバおよびまたはその一部は最新であるかどうかを判定すること、前記ＤＲＭ−Ｅサーバは取り消しリストまたはウォッチリストにあるかどうかを判定すること、およびこれらの組合せからなる群から選択されるカスタムロジックを実行するステップを含むことを特徴とする請求項６４に記載の方法。
66. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）および前記ＤＲＭ−Ｒサーバの秘密キーに基づく署名を含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項５０に記載の方法。
67. 前記ＤＲＭ−Ｒサーバが、その識別子として前記ＤＲＭ−Ｒサーバの公開キーをさらに含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項６６に記載の方法。
68. 前記ＤＲＭ−Ｒサーバが、その間に前記エンロールメント証明書が有効である有効性範囲情報をさらに含めるためのエンロールメント証明書を生成するステップを含むことを特徴とする請求項６６に記載の方法。
69. 前記ＤＲＭ−Ｒサーバが、前記提供する識別を識別する識別のしるしをさらに含めるために前記エンロールメント証明書を生成するステップを含むことを特徴とする請求項６６に記載の方法。
70. 前記ＤＲＭ−Ｒサーバは、前記エンロールメント証明書内の情報の少なくとも一部を生成するためのカスタムロジックを使用することによって前記エンロールメント証明書を生成するステップを含むことを特徴とする請求項５０に記載の方法。
71. 前記ＤＲＭ−Ｒサーバが、生成される前記エンロールメント証明書が信頼されるルートオーソリティにつながる証明書のチェーンに基づいて検証され得るようにするために、前記証明書のチェーンを前記生成されるエンロールメント証明書に付加するステップを含むことを特徴とする請求項５０に記載の方法。
72. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭシステム内での前記ＤＲＭ−Ｅサーバのエンロールメントを取り消すためにオーソリティを有する少なくとも１つのエンティティを識別する取り消しオーソリティリストをさらに含む前記ＤＲＭ−Ｅサーバからのエンロールメント要求を受け取るステップを含み、前記ＤＲＭ−Ｒサーバは、前記要求が尊重される場合に、前記ＤＲＭ−Ｅサーバを前記ＤＲＭシステムにエンロールするために、前記ＤＲＭ−Ｅサーバに関するディジタルエンロールメント証明書を生成するステップであって、前記生成されるエンロールメント証明書が、少なくとも部分的に前記取り消しリストに基づくステップを含むことを特徴とする請求項５０に記載の方法。
73. 前記ＤＲＭ−Ｒサーバが、前記ＤＲＭ−Ｅサーバの識別子としての（ＰＵ−Ｅ）、前記要求からの前記取り消しオーソリティリスト、および前記ＤＲＭ−Ｒサーバの秘密キーに基づく署名を含む前記エンロールメント証明書を生成するステップを含むことを特徴とする請求項７２に記載の方法。
74. 前記ＤＲＭ−Ｒサーバが、ＸｒＭＬエンロールメント証明書を生成するステップを含むことを特徴とする請求項５０に記載の方法。
    

Images