JP4724360B2 - ディジタル権利管理システムにおいて権利テンプレートを使用してディジタルコンテンツのための署名権利ラベル（ｓｒｌ）を取得する方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ディジタル権利管理（ＤＲＭ）システムに関する。より詳細には、本発明は、このようなＤＲＭシステムにおいて１つのディジタルコンテンツのためにライセンスサーバから署名権利ラベル（ＳＲＬ）を取得するために権利テンプレートを使用する際に実行されるステップに関する。
【０００２】
【従来の技術】
ディジタルオーディオ、ディジタルビデオ、ディジタルテキスト、ディジタルデータ、ディジタルマルチメディアなどのディジタルコンテンツとの関連において、ディジタル権利管理および実施が非常に望ましく、このようなディジタルコンテンツは、１つまたは複数のユーザに配布される。ディジタルコンテンツは、たとえばテキストドキュメントなどの静的なものでもよく、またはライブイベントのストリーム化されたオーディオ／ビデオなどのストリーム化されたものでもよい。代表的な配布の形態には、磁気（フロッピー（登録商標））ディスク、磁気テープ、光学（コンパクト）ディスク（ＣＤ）などの有形のデバイス、および電子掲示板、電子ネットワーク、インターネットなどの無形の媒体が含まれる。ユーザは、受信すると、パーソナルコンピュータなどの上のメディアプレーヤなどの適切なレンダリングデバイスの助けをかりて、ディジタルコンテンツをレンダリングまたは「再生」する。
【０００３】
あるシナリオでは、著者、パブリッシャ、放送者などのコンテンツ所有者または権利所有者が、ライセンス料または他の何らかの報酬と引き換えに、このようなディジタルコンテンツを多くのユーザまたは受信者のそれぞれに配布したいと望む。次いで、このシナリオでは、コンテンツは、歌、歌のアルバム、映画などである可能性があり、配布の目的はライセンス料を発生させることである。このようなコンテンツ所有者は、もし選択肢があれば、おそらくユーザがこのような配布されたディジタルコンテンツを用いてできることを制限したいと望む。たとえば、コンテンツ所有者は、ユーザがこのようなコンテンツをコピーし第２のユーザに再配布することを、少なくともコンテンツ所有者がこの第２のユーザからライセンス料を拒む方式で制限したいであろう。
【０００４】
さらに、コンテンツ所有者は、異なるライセンス料で異なるタイプの使用ライセンスを購入するための柔軟性をユーザに提供し、また同時にどのようなタイプのライセンスであれ実際に購入したものの条件にユーザを拘束したいと望むことがある。たとえば、コンテンツ所有者は、限られた回数のみ、ある合計時間のみ、あるタイプのマシン上でのみ、あるタイプのメディアプレーヤでのみ、あるタイプのユーザによってのみなどで、配布されたディジタルコンテンツを再生できるようにしたいと望むことがある。
【０００５】
別のシナリオでは、組織内の従業員などのコンテンツ開発者が、このようなディジタルコンテンツを組織内の１人または複数の他の従業員あるいは組織外の他の個人に配布したいと望むが、他の人々にそのコンテンツをレンダリングさせないようにしたい場合がある。ここで、コンテンツの配布は、ライセンス料または他のいくつかの報酬と引き換えの広域ベースの配布と比べて、秘密のまたは制限された方式での組織ベースのコンテンツ共用により類似している。次いで、このようなシナリオでは、コンテンツは、オフィス環境内で交換されるものなどの、ドキュメント表示、スプレッドシート、データベース、電子メールなどである可能性があり、コンテンツ開発者は、コンテンツがオフィス環境内に留まり、たとえば競争業者や利害の対立する人々などの許可されていない個人によってレンダリングされないことを確実にしたいと望むことがある。繰り返すが、このようなコンテンツ開発者は、受信者がこのような配布されたディジタルコンテンツを用いてできることを制限したいと望む。たとえば、コンテンツ所有者は、ユーザが、少なくともコンテンツをレンダリングできる個人の境界外にコンテンツを公開する方式で、このようなコンテンツをコピーし第２のユーザに再配布することを制限したい場合がある。
【０００６】
さらに、コンテンツ開発者は、さまざまな受信者に異なるレベルのレンダリング権利を提供したいと望むことがある。たとえば、コンテンツ開発者は、保護されているディジタルコンテンツを、あるクラスの個人に対しては表示可能だが印刷可能でないようにし、別のクラスの個人に対しては表示可能かつ印刷可能にしたいと望むことがある。
【０００７】
【発明が解決しようとする課題】
しかし、またいずれのシナリオにおいても、配布が起きた後には、このようなコンテンツ所有者／開発者は、ディジタルコンテンツに対して、たとえできたとしても、ほとんど制御ができない。このことは、実際にあらゆるパーソナルコンピュータが、このようなディジタルコンテンツの正確なディジタルコピーを作成し、このような正確なディジタルコピーを書込可能磁気ディスクまたは光学ディスクにダウンロードするか、またはこのような正確なディジタルコピーをインターネットなどのネットワークを介して任意の宛先に送信するために必要なソフトウェアおよびハードウェアを含むという事実から見て、特に問題である。
【０００８】
もちろん、コンテンツが配布されるトランザクションの一部として、コンテンツ所有者／開発者は、ディジタルコンテンツのユーザ／受信者に、このようなディジタルコンテンツを好ましくない方式で再配布しないことを約束させる必要があるであろう。しかし、このような約束は容易になされ容易に破られる。コンテンツ所有者／開発者が、通常暗号化および復号化を必要とする、いくつかの周知のセキュリティデバイスのいずれかを通じてこのような再配布を防止しようと試みることができる。しかし、断固とした決意を持つわけでもないユーザが、暗号化されたディジタルコンテンツを復号化し、このようなディジタルコンテンツを暗号化されていない形式でセーブし、次いでそれを再配布することを防止できる可能性はほとんどない。
【０００９】
したがって、任意の形式のディジタルコンテンツの制御されたレンダリングまたは再生を可能にするディジタル権利管理および実施アーキテクチャおよび方法を提供することが求められており、この場合、このような制御は柔軟であり、このようなディジタルコンテンツのコンテンツ所有者／開発者によって定義可能である。より詳細には、特に定義済みグループの個人間またはクラスの個人間でドキュメントが共用されるオフィスまたは組織環境などで、このような制御されたレンダリングを可能にし、容易にするアーキテクチャが求められている。
【００１０】
【課題を解決するための手段】
本発明は、署名権利ラベルを介してディジタルコンテンツおよびサービスのための使用ライセンスを発行するためのシステムおよび方法を提供することにより、上述した当該技術分野における必要を満足させる。
【００１１】
本発明によれば、ディジタル権利管理（「ＤＲＭ」）ライセンス発行コンポーネントが、別のソフトウェアアプリケーションまたはコンポーネントがディジタルコンテンツまたはサービスを、ライセンスによって定められた条件に従って消費できるようにするライセンスを発行する。ライセンスを発行するために、ライセンス発行コンポーネントは、単一の特定のライセンスを発行することが可能な１組の条件を指定する権利ラベルを使用する。ライセンス条件は、コンテンツまたはサービスを使用するための権利、条件、原理を指定する。本明細書で使用する用語、「権利」とは、消費コンポーネントによって理解される特定のアクションを言う（たとえば、ディジタルメディアプレーヤについては「再生」、またはドキュメント管理システムについては「編集」）。本明細書で使用する用語、「条件」とは、消費コンポーネントにより消費が起きることができるようになる前に満足されなければならない特定の基準（たとえば、「１２月１日までに」）を言う。さらに、ライセンスはまた、ライセンスが付与されている保護されているコンテンツまたはサーバをアンロックするために使用される暗号鍵材料も含むことができる。本発明による権利ラベルには、その権利ラベルが関連するコンテンツまたはサービスについて差し支えなく発行できるすべてのライセンスの境界を区切る定義が含まれる。したがって、一般に、ライセンスには、権利ラベル内で指定された１サブセットの権利および条件が含まれる。
【００１２】
本発明は、１つのコンテンツのための権利記述および関連する保護されている暗号鍵材料を受信するステップと、権利ラベルを作成するためにこのデータを介してディジタル署名の妥当性を確認し作成するステップと、アプリケーションが１つのコンテンツのためのライセンスを要求できるようにするステップと、ＤＲＭライセンスサーバが上述の要求に許可チェックを実行できるようにするステップと、ＤＲＭライセンシングサーバがその要求に基づいて要求者にライセンスを発行できるようにするステップと、その要求をしているアプリケーションまたはユーザに対するコンテンツの暗号材料を保護するステップとを含む機能を実行するための、プロトコルおよび／またはアプリケーションプログラムおよび／またはアプリケーションプログラムインターフェース（ＡＰＩ）として具体化できる。
【００１３】
本発明による一実施形態においては、ライセンスサーバが、コンテンツをレンダリングすることを望む１つまたは複数のユーザにコンテンツに対応するディジタルライセンスを発行できるようにするために、ディジタルコンテンツがパブリッシュされる。コンテンツは、コンテンツ鍵（ＣＫ）に従って暗号化され、（ＣＫ（ｃｏｎｔｅｎｔ））が生じ、（ＣＫ）は、ライセンスサーバのための公開鍵（ＰＵ−ＤＲＭ）に従って保護される。権利テンプレートが検索され、その権利テンプレートからコンテンツに関連する権利データが取り出され、取り出された権利データが（ＰＵ−ＤＲＭ）に従って保護される。
【００１４】
保護されている権利データおよび保護されている（ＣＫ））は、それによって署名するためのライセンスサーバへの権利ラベルとして提出される。ライセンスサーバは、権利ラベルの妥当性を確認し、妥当であれば、（ＰＵ−ＤＲＭ）に対応する秘密鍵（ＰＲ−ＤＲＭ）に基づいてかつ少なくとも一部は保護されている権利データに基づいてディジタル署名を作成し、署名権利ラベル（ＳＲＬ）が生じ、ＳＲＬを返す。返されたＳＲＬは受信され、（ＣＫ（ｃｏｎｔｅｎｔ））と連結してコンテンツパッケージを形式し、コンテンツパッケージは１つまたは複数のユーザに配布される。
【００１５】
コンテンツをレンダリングすることを望むユーザが、コンテンツパッケージからＳＲＬを取り出し、コンテンツに対応するライセンスのための要求の一部はとして、取り出されたＳＲＬをライセンスサーバに提出する。ライセンスサーバは、（ＰＵ−ＤＲＭ）に基づいてかつ少なくとも一部は保護されている権利データに基づいてＳＲＬの署名を検証し、ＳＲＬ内の保護されている権利データにアクセスし、それを見直してユーザがライセンスの資格があるかどうかを判断し、資格があればライセンスをユーザに発行する。ライセンスは、ユーザからアクセス可能な保護されている形式で（ＣＫ）を含む。
【００１６】
本発明による一実施形態では、権利ラベルは、公用権利テンプレート（ＯＲＴ）から取り出され（ＰＵ−ＤＲＭ）に従って保護された権利データを含み、またＯＲＴからのディジタル署名も含み、その署名は、（ＰＵ−ＤＲＭ）に対応する秘密鍵（ＰＲ−ＤＲＭ）に基づきかつ少なくとも一部はＯＲＴ内の権利データ（Ｓ（ＰＲ−ＤＲＭ−Ｔ））に基づく。ライセンスサーバは、少なくとも一部は権利ラベル内の保護されている権利データに基づいてＳ（ＰＲ−ＤＲＭ−Ｔ）を検証し、Ｓ（ＰＲ−ＤＲＭ−Ｔ）が検証された場合にのみ権利ラベルに署名する。
【００１７】
本発明の他の特徴は、添付図面と関連する本発明による実施形態についての以下の詳細な説明からさらに自明となる。
【００１８】
【発明の実施の形態】
例示的コンピューティングデバイス
図１および以下の説明の目的は、本発明が実施できる適切なコンピューティング環境の一般的な記述を簡単に提供することである。しかし、すべての種類のハンドヘルドデバイス、ポータブルデバイス、他のコンピューティングデバイスが、本発明に関連して使用されることが想定されることを理解されたい。汎用コンピュータを以下に記述するが、これは一例に過ぎず、本発明は、ネットワークサーバのインタオペラビリティおよびインタラクションを備えた１つのシンクライアントのみを必要とするだけである。したがって、本発明は、最小のクライアントリソースしか関与しないかまたはほとんど関与しないネットワーク化された穂スティングされたサービスの環境、たとえば、クライアントデバイスが単にブラウザまたはワールドワイドウェブへのインターフェースとしてしか役立たないネットワーク化された環境内で実施できる。
【００１９】
必要ではないが、本発明は、開発者によって使用されかつ／またはクライアントワークステーション、サーバ、または他のデバイスなどの１つまたは複数のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な状況下で記述するネットワークブラウジングソフトウェア内に含まれる、アプリケーションプログラミングインターフェース（ＡＰＩ）を介して実施できる。一般に、プログラムモジュールには、特定のタスクを実行するかまたは特定の抽象データタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。通常、プログラムモジュールの機能は、さまざまな実施形態内で所望通りに組み合わされるかまたは分散できる。さらに、本発明が他のコンピュータシステム構成とともに実行できることは、当業者なら理解されるであろう。本発明とともに使用するのに適切な他の周知のコンピューティングシステム、環境、および／または構成には、パーソナルコンピュータ（ＰＣ）、現金自動預け払い機、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラマブル大衆消費電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなど含まれるが、それらに限定されるものではない。本発明はまた、タスクが通信ネットワークまたは他のデータ送信媒体を通じてリンクされたリモート処理デバイスによって実行される分散型コンピューティング環境内でも実行できる。分散型コンピューティング環境においては、プログラムモジュールを、記憶装置デバイスを含むローカルおよびリモートのコンピュータ記憶媒体の両方内に置くことができる。
【００２０】
したがって、図１は、本発明が実施できる適切なコンピューティングシステム環境１００の一例を示す図であるが、上記で明らかなように、コンピューティングシステム環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の使用範囲または機能を限定することを示唆するものではない。コンピューティング環境１００は、オペレーティング環境１００の例で例示したコンポーネントのいずれにもまたはそれらの組合せに対しても依存性または要件を有するものと解釈してはならない。
【００２１】
図１を参照すると、本発明を実施するためのシステムの例に、コンピュータ１１０の形式で汎用コンピューティングデバイスが含まれている。コンピュータ１１０のコンポーネントには、処理ユニット１２０、システムメモリ１３０、システムメモリを含むさまざまなシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１を含むことができるが、それらに限定されるものではない。システムバス１２１は、さまざまなバスアーキテクチャのいずれをも使用するメモリバスまたはメモリコントローラ、周辺バス、ローカルバスを含むいくつかのタイプのバス構造のいずれでもよい。例示として、このようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子装置規格化協会（ＶＥＳＡ）ローカルバス、周辺装置相互接続（ＰＣＩ）バス（メザニンバスとしても周知である）が含まれるが、それらに限定されるものではない。
【００２２】
コンピュータ１１０には、一般にさまざまなコンピュータ読取り可能媒体が含まれる。コンピュータ読取り可能媒体は、コンピュータ１１０からアクセスでき、揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体の両方を含むどのような使用可能媒体でも良い。例示として、コンピュータ読取り可能媒体には、コンピュータ記憶媒体および通信媒体が備えられることがあるが、それらに限定されるものではない。コンピュータ記憶媒体には、コンピュータ読取り可能命令、データ構造、プログラムモジュールまたは他のデータなどの情報を格納するためのどのような方法または技術においても実施される、揮発性および不揮発性、取り外し可能および取り外し不可能媒体の両方が含まれる。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）または他の光学ディス記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置デバイス、または所望の情報を格納するために使用できコンピュータ１１０からアクセスできる他の媒体を備えるが、それらに限定されるものではない。通信媒体が、一般に、搬送波や他の移送メカニズムなどの被変調データ信号内でコンピュータ読取り可能命令、データ構造、プログラムモジュールまたは他のデータを包含し、どのような情報配信媒体をも含む。用語「被変調データ信号」とは、信号内に情報を符号化する方式で設定または変更された特性の１つまたは複数を有する信号である。例として、通信媒体には、有線ネットワークや直接有線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体とが含まれるが、それらに限定されるものではない。上記のいずれの組合せも、コンピュータ読取り可能媒体の範囲内に含まれるものとする。
【００２３】
システムメモリ１３０は、読取専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形式でコンピュータ記憶媒体を含む。基本入出力システム１３３（ＢＩＯＳ）が、スタートアップ中などにコンピュータ１１０内の要素間で情報を転送する助けとなる基本ルーチンを含み、一般にＲＯＭ１３１内に格納される。ＲＡＭ１３２は、一般に、ただちに処理ユニット１２０からアクセス可能でありかつ／または現在それによって動作しているデータおよび／またはプログラムモジュールを含む。例示として、図１にはオペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、プログラムデータ１３７が示されているが、それらに限定されるものではない。
【００２４】
コンピュータ１１０はまた、他の取り外し可能／取り外し不可能、揮発性／不揮発性コンピュータ記憶媒体も含むことができる。単に例示として、図１には、取り外し不可能、不揮発性磁気媒体から読取りまたはそれに書き込むハードディスクドライブ１４１、取り外し可能、不揮発性磁気ディスク１５２から読取りまたはそれに書き込む磁気ディスクドライブ１５１、ＣＤ ＲＯＭや他の光学媒体などの、取り外し可能、不揮発性光学ディスク１５６から読取りまたはそれに書き込む光学ディスクドライブ１５５が示されている。オペレーティング環境の例で使用できる他の取り外し可能／取り外し不可能、揮発性／不揮発性コンピュータ記憶媒体には、磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどが含まれるが、それらに限定されるものではない。ハードディスクドライブ１４１は、一般に、インターフェース１４０などの取り外し不可能メモリインターフェースを通じてシステムバス１２１に接続され、磁気ディスクドライブ１５１および光学ディスクドライブ１５５は、一般に、インターフェース１５０などの取り外し可能メモリインターフェースによってシステムバス１２１に接続される。
【００２５】
上述し図１に例示したそれらのドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ１１０のためのコンピュータ読取り可能命令、データ構造、プログラムモジュールおよび他のデータの記憶装置を提供する。図１に、たとえば、ハードディスクドライブ１４１が、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７を格納して例示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、プログラムデータ１３７と同じものでもまたは異なるものでも良いことに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、プログラムデータ１４７には異なる番号が付与されているが、これは、少なくともこれらが異なるものであることを例示するためである。ユーザが、キーボード１６２や一般にマウス、トラックボールまたはタッチパッドと呼ぶポインティングデバイス１６１などの入力デバイスを通じてコンピュータ１１０にコマンドおよび情報を入力できる。他の入力デバイス（図示せず）が、マイクロホン、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、スキャナなどを含むことができる。これらのおよび他の入力デバイスは、しばしば、システムバス１２１に結合されているユーザ入力インターフェース１６０を通じて処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によっても接続できる。
【００２６】
モニタ１９１または他のタイプのディスプレイデバイスもまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。ノースブリッジ（Ｎｏｒｔｈｂｒｉｄｇｅ）などのグラフィックスインターフェース１８２も、システムバス１２１に接続できる。ノースブリッジは、ＣＰＵまたはホスト処理ユニット１２０と通信し、アクセラレィテッドグラフィックスポート（ＡＧＰ）通信を担当するチップセットである。１つまたは複数のグラフィックス処理ユニット（ＧＰＵ）１８４が、グラフィックスインターフェース１８２と通信できる。この点において、ＧＰＵ１８４は、一般に、レジスタ記憶装置などのオンチップ記憶装置を含み、ＧＰＵ１８４は、ビデオメモリ１８６と通信する。しかし、ＧＰＵ１８４はコプロセッサの一例に過ぎず、従って、コンピュータ１１０内にはさまざまなコプロセッシングデバイスを含むことができる。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続され、インターフェースは、ビデオメモリ１８６と通信できる。モニタ１９１に加えて、コンピュータはまた、出力周辺インターフェース１９５を通じて接続できる、スピーカ１９７やプリンタ１９６などの他の周辺出力デバイスも含むことができる。
【００２７】
コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境内で動作できる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたは他の共通ネットワークノードとすることができ、一般に、コンピュータ１１０について上述した要素の多くまたはすべてを含むが、図１には記憶装置デバイス１８１のみが例示されている。図１に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含むことができる。このようなネットワーキング環境は、オフィス、全社的コンピュータネットワーク、イントラネット、インターネットで一般的なものである。
【００２８】
ＬＡＮネットワーキング環境内で使用された場合は、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を通じてＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境内で使用された場合は、コンピュータ１１０は、一般に、インターネットなどの、ＷＡＮ１７３を介して通信を確立するためのモデム１７２または他の手段を備える。モデム１７２は、内蔵でも外付けでもよいが、ユーザ入力インターフェース１６０または他の適切なメカニズムを介してシステムバス１２１に接続できる。ネットワーク化された環境においては、コンピュータ１１０について示したプログラムモジュール、またはその一部分を、リモート記憶装置内に格納できる。例示として、図１にはメモリデバイス１８１上に常駐するリモートアプリケーションプログラム１８５が例示されているが、それに限定されるものではない。図示されているネットワーク接続は例であり、コンピュータ間で通信リンクを確立する他の手段も使用できることを理解されたい。
【００２９】
コンピュータ１１０または他のクライアントデバイスをコンピュータネットワークの一部として配置できることは、当業者なら理解できるであろう。この点において、本発明は、任意の数のメモリまたは記憶ユニットおよび、任意の数の記憶ユニットまたは記憶ボリュームにわたって生じる任意の数のアプリケーションおよびプロセスを含むどのようなコンピュータシステムにも関係する。本発明は、リモートまたはローカル記憶装置を有するネットワーク環境内に配置されたサーバコンピュータおよびクライアントコンピュータを備えた環境に適用できる。本発明はまた、プログラミング言語機能、解釈、実行機能を有するスタンドアロンコンピューティングデバイスにも適用できる。
【００３０】
分散型コンピューティングは、コンピューティングデバイスとシステムの間の直接交換によるコンピュータリソースおよびサービスの共用を容易にする。これらのリソースおよびサービスには、情報の交換、キャッシュ記憶装置、ファイルのためのディスク記憶装置が含まれる。分散型コンピューティングは、ネットワーク接続性を利用して、クライアントが企業全体を利するための集合力を高めることができるようにする。この点において、さまざまなデバイスが、１つまたは複数のトラステッド・グラフィックスパイプラインのための本発明の認証技術に関与するよう対話できるアプリケーション、オブジェクト、またはリソースを有することができる。
【００３１】
図２は、ネットワーク化されたまたは分散型コンピューティング環境の例を示す概略図である。分散型コンピューティング環境は、コンピューティングオブジェクト１０ａ、１０ｂなどおよびコンピューティングオブジェクトまたはデバイス１１０ａ、１１０ｂ、１１０ｃなどを含む。これらのオブジェクトは、プログラム、方法、データ記憶装置、プログラマブル論理などを含むことができる。オブジェクトは、ＰＤＡ、テレビジョン、ＭＰ３プレーヤ、テレビジョン、パーソナルコンピュータなどと同じまたは異なるデバイスの一部分を含むことができる。それぞれのオブジェクトが、通信ネットワーク１４経由で他のオブジェクトと通信できる。このネットワークは、それ自体、図２のシステムにサービスを提供する他のコンピューティングオブジェクトおよびコンピューティングデバイスを含むことができる。本発明の一態様によれば、それぞれのオブジェクト１０または１１０が、１つまたは複数のトラステッド・グラフィックスパイプラインのために本発明の認証技術を要求する可能性のあるアプリケーションを含むことができる。
【００３２】
１１０ｃなどのオブジェクトを、別のコンピューティングデバイス１０または１１０上にホストできることも理解されたい。したがって、示されている物理環境はコンピュータなどの接続されたデバイスを示しているが、これは、単に例示であって、ＰＤＡ、テレビジョン、ＭＰ３プレーヤなどのさまざまなディジタルデバイスと、インターフェースなどのソフトウェアオブジェクトと、ＣＯＭオブジェクトなどとを備えた物理環境を示すかまたは記述することもできる。
【００３３】
分散型コンピューティング環境をサポートするさまざまなシステム、コンポーネント、ネットワーク構成がある。たとえば、ワイヤラインまたは無線システムにより、ローカルネットワークまたは広範囲に分散されたネットワークにより、コンピューティングシステムをともに接続できる。現在、ネットワークの多くがインターネットに結合され、これが広範囲に分散されたコンピューティングのためのインフラストラクチャを提供し、多くの異なるネットワークを包含する。
【００３４】
ホームネットワーキング環境においては、それぞれが、電力線、データ（無線および有線の両方）、音声（たとえば、電話）、エンターテイメントメディアなどの一意のプロトコルをサポートできる、少なくとも４つの異種類のネットワーク移送媒体がある。電灯のスイッチや電気製品などのほとんどの家庭用制御デバイスが、接続のために電力線を使用できる。データサービスは、ブロードバンド（たとえば、ＤＳＬやケーブルモデム）として家庭に入ることができ、無線（たとえば、ＨｏｍｅＲＦまたは８０２．１１ｂ）または有線（たとえば、ＨｏｍｅＰＮＡ、Ｃａｔ５、さらには電力線）の接続のいずれかを使用して家庭内にアクセス可能である。音声トラフィックが、有線（たとえば、Ｃａｔ３）または無線（たとえば、携帯電話）のいずれかとして家庭に入ることができ、Ｃａｔ３ワイヤリングを使用して家庭内で配布できる。エンターテイメントメディアは、衛星またはケーブルのいずれかを通じて家庭内に入ることができ、一般に、同軸ケーブルを使用して家庭内に配布される。ＩＥＥＥ１３９４およびＤＶＩもまた、１群のメディアデバイスのためのディジタル相互接続として現れてきている。これらのネットワーク環境およびプロトコル標準として現れてくる他のネットワーク環境のすべてが相互接続されて、インターネット経由で外界に接続できるイントラネットを形成できる。要するに、データの格納および送信のためにさまざまな異種類のソースが存在し、その結果ますます発展して、コンピューティングデバイスには、データ処理パイプラインのすべての部分でコンテンツを保護する方式が必要となる。
【００３５】
インターネットとは、一般に、コンピュータネットワーキングの分野で周知のプロトコルのＴＣＰ／ＩＰの組を利用するネットワークおよびゲートウェイの集合を言う。ＴＣＰ／ＩＰとは、「伝送制御プロトコル／インターフェースプログラム（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｆａｃｅ Ｐｒｏｇｒａｍ）」の頭字語である。インターネットは、ユーザがネットワークを介して情報と対話しそれを共用できるようにするネットワーキングプロトコルを実行するコンピュータによって相互接続された、地理的に分散されたリモートコンピュータネットワークのシステムとして記述できる。このような広範囲に拡がった情報共用により、インターネットなどのリモートネットワークは、開発者が専用オペレーションまたはサービスを実行するためのソフトウェアアプリケーションを基本的に無制限に設計できるオープンシステムへと広く発展するに至った。
【００３６】
したがって、ネットワークインフラストラクチャが、クライアント／サーバ、ピアツーピア、またはハイブリッドアーキテクチャなどの多くのネットワーク トポロジを可能にする。「クライアント」とは、関係しない別のクラスまたはグループのサービスを使用する、あるクラスまたはグループのメンバである。したがって、コンピューティングにおいては、クライアントとは、プロセス、すなわち大雑把に言って別のプログラムによって提供されるサービスを要求する１組の命令またはタスクである。クライアントプロセスは、他のプログラムまたはサービス自体に関する動作している詳細を「知る」必要なしに、要求されたサービスを利用する。クライアント／サーバアーキテクチャ、特にネットワーク化されたシステムにおいては、クライアントとは、通常、別のコンピュータ、たとえばサーバによって提供される共用ネットワークリソースにアクセスするコンピュータである。図２の例では、コンピュータ１１０ａ、１１０ｂなどがクライアントであり、コンピュータ１０ａ、１０ｂなどがサーバであると考えることができ、ここで、サーバ１０ａ、１０ｂなどがデータを維持し、次いでデータがクライアントコンピュータ１１０ａ、１１０ｂなど内で複製される。
【００３７】
サーバとは、一般にインターネットなどのリモートネットワークを介してアクセス可能なリモートコンピュータシステムである。クライアントプロセスは第１のコンピュータシステム内でアクティブにすることができ、サーバプロセスは第２のコンピュータシステム内でアクティブにすることができ、通信媒体を介して互いに通信し、従って、分散機能が提供され、複数のクライアントがサーバの情報収集機能を利用することが可能となる。
【００３８】
クライアントとサーバは、プロトコルレイヤによって提供される機能を利用して互いに通信する。たとえば、ハイパテキスト転送プロトコル（ＨＴＴＰ）が、ワールドワイドウェブ（ＷＷＷ）とともに使用される共通プロトコルである。一般に、ユニバーサルリソースロケータ（ＵＲＬ）またはインターネットプロトコル（ＩＰ）アドレスなどのコンピュータネットワークアドレスが、サーバまたはクライアントコンピュータを互いに識別するために使用される。ネットワークアドレスは、ユニバーサルリソースロケータアドレスとも呼ぶことができる。たとえば、通信は通信媒体を介して提供できる。具体的には、クライアントおよびサーバは高容量通信用のＴＣＰ／ＩＰ接続を介して互いに結合できる。
【００３９】
したがって、図２は、本発明を用いることのできる、ネットワーク／バスを介してクライアントコンピュータと通信するサーバを有する、ネットワーク化されたまたは分散された環境の例を示す図である。より詳細には、いくつかのサーバ１０ａ、１０ｂなどが、本発明に従って、ポータブルコンピュータ、ハンドヘルドコンピュータ、シンクライアント、ネットワーク化されたアプライアンス、またはＶＣＲ、テレビ、オーブン、照明、ヒータなどの他のデバイスなどの、いくつかのクライアントまたはリモートコンピューティングデバイス１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどを備えた、ＬＡＮ、ＷＡＮ、イントラネット、インターネットなどとすることができる通信ネットワーク／バス１４を介して相互接続される。したがって、本発明は、トラステッド・ソースから安全なコンテンツを処理し格納しまたはレンダリングすることが望ましい状況において、どのようなコンピューティングデバイスにも適用できると想定される。
【００４０】
通信ネットワーク／バス１４がインターネットであるネットワーク環境においては、たとえばサーバ１０は、ＨＴＴＰなどのいくつかの周知のプロトコルのいずれかを介してクライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅなどがそれと通信するウェブサーバである場合がある。サーバ１０はまた、クライアント１１０としても機能することができ、これは分散型コンピューティング環境の特性でもあり得る。通信は、適宜有線でも無線でも良い。クライアントデバイス１１０が、通信ネットワーク／バス１４を介して通信する場合もしない場合もあり、それに関連する独立した通信を有することができる。たとえば、テレビまたはＶＣＲの場合は、それの制御についてネットワーク化された態様である場合もそうでない場合もある。それぞれのクライアントコンピュータ１１０およびサーバコンピュータ１０は、さまざまなアプリケーションプログラムモジュールまたはオブジェクト１３５を装備し、さまざまなタイプの記憶要素またはオブジェクトへの接続またはアクセスを有することができ、それを通じてファイルを格納でき、またはファイルの１つまたは複数の部分をダウンロードまたは移行できる。したがって本発明は、コンピュータネットワーク／バス１４にアクセスし、それと対話できるクライアントコンピュータ１１０ａ、１１０ｂなどと、クライアントコンピュータ１１０ａ、１１０ｂなどおよび他のデバイス１１１およびデータベース２０と対話できるサーバコンピュータ１０ａ、１０ｂなどとを備えたコンピュータネットワーク環境内で利用できる。
【００４１】
ディジタル権利管理（ＤＲＭ）の概要
周知であるが、次に図１１を参照すると、ディジタル権利管理（ＤＲＭ）および実施が、ディジタルオーディオ、ディジタルビデオ、ディジタルテキスト、ディジタルデータ、ディジタルマルチメディアなどのディジタルコンテンツ１２について非常に望ましく、このようなディジタルコンテンツ１２がユーザに配布されている。ユーザによって受信されると、このようなユーザはパーソナルコンピュータ１４上のメディアプレーヤなどの適切なレンダリングデバイスの助けをかりてディジタルコンテンツをレンダリングまたは「再生」する。
【００４２】
一般に、このようなディジタルコンテンツ１２を配布しているコンテンツ所有者または開発者（以下、「所有者」と呼ぶ）が、ユーザがこのような配布されたディジタルコンテンツ１２を用いてできることを制限したいと望む。たとえば、コンテンツ所有者は、ユーザがこのようなコンテンツ１２をコピーし第２のユーザに再配布することを制限したいと望むか、または限られた回数のみ、ある合計時間のみ、あるタイプのマシン上でのみ、あるタイプのメディアプレーヤでのみ、あるタイプのユーザによってのみなどで、配布されたディジタルコンテンツ１２を再生できるようにしたいと望むことがある。
【００４３】
しかし、配布が起きた後に、このようなコンテンツ所有者はディジタルコンテンツ１２に対して、たとえできたとしても、ほとんど制御ができない。次いで、ＤＲＭシステム１０により、任意の形式のディジタルコンテンツ１２の制御されたレンダリングまたは再生が可能となり、このような制御は柔軟でありこのようなディジタルコンテンツのコンテンツ所有者によって定義可能である。一般に、コンテンツ１２は、適切な配布チャネル経由でパッケージ１３の形式でユーザに配布される。ディジタルコンテンツパッケージ１３は、配布されて対称暗号化（ｓｙｍｍｅｔｒｉｃ ｅｎｃｒｙｐｔｉｏｎ）／復号化鍵（ＫＤ）で暗号化されたディジタルコンテンツ１２（すなわち、（ＫＤ（ＣＯＮＴＥＮＴ）））、ならびにこのようなコンテンツのためのライセンスをどのように取得するかなどの、コンテンツを識別する他の情報とを含むことができる。
【００４４】
トラステッド・ベースのＤＲＭシステム１０により、ディジタルコンテンツ１２の所有者が、このようなディジタルコンテンツ１２がユーザのコンピューティングデバイス１４上でレンダリングできるようになる前に、満足されなければならないライセンス規則を指定できる。このようなライセンス規則は上述した時間要件を含むことができ、ユーザ／ユーザのコンピューティングデバイス１４（以下、この２つの用語は、別段の必要な状況がない限り、交換可能である）がコンテンツ所有者またはそのエージェントから取得しなければならないディジタルライセンス１６内に包含できる。このようなライセンス１６はまた、ユーザのコンピューティングデバイスによって復号化可能な鍵に従って恐らく暗号化されているディジタルコンテンツを復号化するための復号化鍵（ＫＤ）も含む。
【００４５】
１つのディジタルコンテンツ１２のコンテンツ所有者は、ユーザのコンピューティングデバイス１４がライセンス１６内のこのようなコンテンツ所有者によって指定された規則および要件を遵守する、すなわち、ディジタルコンテンツ１２はライセンス１６内の規則および要件が満足されない限りレンダリングされることはないということを信頼しなければならない。好ましくは、次いで、ユーザのコンピューティングデバイス１４には、ディジタルコンテンツ１２に関連してライセンスｌ６内に包含され、ユーザによって取得されたライセンス規則に従うこと以外は、ディジタルコンテンツ１２をレンダリングしないトラステッド・コンポーネントまたはメカニズム１８が提供される。
【００４６】
トラステッド・コンポーネント１８は一般に、ライセンス１６が妥当かどうかを判断し、このような有効ライセンス１６内のライセンス規則および要件を再検討し、見直したライセンス規則および要件に基づいて要求しているユーザが要求したディジタルコンテンツ１２をとりわけ要求された方式でレンダリングする権利を有するかどうかを判断するライセンスエバリュエータ２０を備える。理解されるであろうが、ライセンスエバリュエータ２０は、ライセンス１６内の規則および要件に従ってディジタルコンテンツ１２の所有者の望みを実行するためのＤＲＭシステム１０内で信頼され、ユーザは、どのような目的であれ、または不法に、このようなトラステッド・エレメントを容易に改変することはできない。
【００４７】
理解されるであろうが、ライセンス１６内の規則および要件は、ユーザは誰であるか、ユーザはどこにいるか、ユーザはどのタイプのコンピューティングデバイスを使用しているか、どのレンダリングアプリケーションがＤＲＭシステムを呼び出しているか、日付、時間などを含むいくつかの要因のいずれかに基づいて、ユーザがディジタルコンテンツ１２をレンダリングする権利を有するかどうかを指定できる。さらに、ライセンス１６の規則および要件は、ライセンス１６を、たとえば所定の回数の再生または所定の再生時間に制限できる。
【００４８】
規則および要件は、適切な言語およびシンタックスに従ってライセンス１６内で指定できる。たとえば、言語は、単に、満足さなければならない属性および値を指定するだけであったり（たとえば、日付（ＤＡＴＥ）はＸより後でなければならない）、または指定されたスクリプト（Ｘより大きいＩＦ ＤＡＴＥ、ＴＨＥＮ ＤＯなど）による機能の性能を必要とすることがある。
【００４９】
ライセンスエバリュエータ２０が、ライセンス１６が妥当でありユーザがその規則および要件を満足すると判断すると、ディジタルコンテンツ１２をレンダリングできる。具体的には、コンテンツ１２をレンダリングするために、復号化鍵（ＫＤ）がライセンス１２から取得され、コンテンツパッケージ１３からの（ＫＤ（ＣＯＮＴＥＮＴ））に適用され、実際のコンテンツ１２が生じ、次いで実際のコンテンツ１２が実際にレンダリングされる。
【００５０】
ディジタルコンテンツのパブリッシング
図３は、ディジタルコンテンツをパブリッシュするための本発明によるシステムおよび方法の好ましい実施形態を示す機能ブロック図である。「パブリッシング」とは、本明細書で使用する場合、アプリケーションまたはサービスが、トラステッド・エンティティを用いて、そのエンティティがそのコンテンツのために発行できる１組の権利および条件を確立するために従いかつそれに対してそれらの権利および条件が発行できるプロセスを言う。本発明によれば、パブリッシングプロセスは、ディジタルコンテンツ暗号化するステップと、コンテンツの著者がコンテンツのすべての可能なユーザに対して意図した永続的に実施可能な（ｅｎｆｏｒｃｅａｂｌｅ）権利のリストを関連付けるステップとを含む。このプロセスは、コンテンツの著者によって意図された場合でない限り、権利またはコンテンツのいずれへのアクセスも禁止するための安全な方式で実行できる。
【００５１】
本発明の好ましい実施形態では、具体的には次の３つのエンティティを利用してセキュアデジタルコンテンツを発行する。そのエンティティとは、クライアント３００上で実行され、パブリッシングのためにコンテンツを準備するコンテンツ準備アプリケーション３０２、やはりクライアントデバイス３００上に常駐するディジタル権利管理（ＤＲＭ）アプリケーションプログラムインターフェース（ＡＰＩ）３０６、および通信ネットワーク３３０を介してクライアント３００に通信可能に結合されるＤＲＭサーバ３２０である。本発明による好ましい実施形態においては、通信ネットワーク３３０はインターネットを含むが、通信ネットワーク３３０は、たとえばプロプライエタリイントラネットなどのローカルまたはワイドエリアネットワークのどのようなものでもあり得ることを理解されたい。
【００５２】
コンテンツ準備アプリケーション３０２は、ディジタルコンテンツを製作するどのようなアプリケーションでも良い。たとえば、アプリケーション３０２は、ディジタルテキストファイル、ディジタル音楽、ビデオ、または他のこのようなコンテンツを製作するワードプロセッサまたは他のパブリッシャであり得る。コンテンツはまた、たとえば、ライブまたはテープにとったイベントのストリーム化されたオーディオ／ビデオなどの、ストリーム化されたコンテンツでもあり得る。本発明によれば、コンテンツ準備アプリケーションは、ユーザが提供する鍵を使用してコンテンツを暗号化するようそのユーザを勧誘する。アプリケーション３０２は、鍵を使用してディジタルコンテンツを暗号化し、従って、暗号化されたディジタルコンテンツファイル３０４を形式する。クライアントアプリケーションはまた、ディジタルコンテンツファイル３０４のための権利データを提供するようユーザを勧誘する。権利データは、ディジタルコンテンツ内に権利を有するそれぞれのエンティティのための各識別情報を含む。このようなエンティティは、たとえば、個人、あるクラスの個人、またはデバイスであり得る。それぞれのこのようなエンティティについて、権利データはまた、そのエンティティがコンテンツ内に有する権利のリストと、これらの権利のいずれにもまたはすべてに課すことのできる条件とを含む。このような権利は、ディジタルコンテンツを読み取り編集しコピーし印刷するなどのための権利を含むことができる。さらに、権利は、包括的でも排他的でもあり得る。包括的な権利は、指定されたユーザがコンテンツ内に指定された権利を有する（たとえば、ユーザはディジタルコンテンツを編集できる）ことを示す。排他的な権利は、その旨指定された場合以外は、指定されたユーザがコンテンツ内のすべての権利を有する（たとえば、ユーザはそれをコピーすることを除きディジタルコンテンツを用いてどのようなこともできる）ことを示す。
【００５３】
本発明の一実施形態によれば、クライアントＡＰＩ３０６は、暗号化されたディジタルコンテンツおよび権利データをＤＲＭサーバ３２０に渡すことができる。以下に詳細に記述するプロセスを使用して、ＤＲＭサーバ３２０は、ユーザが割り当てた権利を実施できるかどうか判断し、できる場合は、ＤＲＭサーバ３２０は権利データに署名して署名権利ラベル（ＳＲＬ）３０８を形成する。しかし、一般に、どのようなトラステッド・エンティティも、好ましくはＤＲＭサーバ３２０によって信頼された鍵を使用して、権利データに署名できる。たとえば、クライアントが、ＤＲＭサーバ３２０によってそれに提供された鍵を使用して権利データに署名できる。
【００５４】
権利ラベル３０８は、権利記述と、暗号化されたコンテンツ鍵と、権利記述および暗号化されたコンテンツ鍵に対するディジタル署名とを表すデータを含むことができる。ＤＲＭサーバが権利ラベルに署名している場合は、クライアントＡＰＩ３０６を通じて署名された権利ラベル３０８をクライアントに再び渡し、ここで、クライアントデバイス３００上に署名権利ラベル３０８を格納する。次いで、コンテンツ準備アプリケーション３０２は、署名権利ラベル３０８を暗号化されたディジタルコンテンツファイル３０４に関連付ける。たとえば、ＳＲＬ３０８は、暗号化されたディジタルコンテンツファイルと連結して、権利管理されたコンテンツファイル３１０を形成できる。しかし、一般に、権利データはディジタルコンテンツと組み合わせる必要はない。たとえば、権利データは周知の場所に格納でき、格納された権利データへの参照を暗号化されたディジタルコンテンツと組み合わせることができる。参照は、権利データがどこに格納されているか（たとえば、権利データを含むデータ記憶装置）を示す識別子と、その特定の記憶装置の場所のその特定の権利データに対応する（たとえば、特定の当該権利データを含むファイルを識別する）識別子とを含むことができる。次いで、権利管理されたコンテンツ３１０は、誰にでもどこへでも配信でき、そのコンテンツを消費する権利を有するエンティティのみが、それらが割り当てられた権利に従ってそのコンテンツを消費できる。
【００５５】
図４は、権利管理されたディジタルコンテンツをパブリッシュするための本発明による方法４００の例を示す流れ図であり、権利ラベルはＤＲＭサーバによって署名される。しかし、この実施形態は単に例示であり、権利ラベルは一般にどのようなトラステッド・エンティティによっても署名できることを理解されたい。一般に、ディジタルコンテンツをパブリッシュするための本発明による方法が、コンテンツ鍵（ＣＫ）を使用してディジタルコンテンツを暗号化するステップと、ディジタルコンテンツに関連付けられた権利記述を生成するステップと、ＤＲＭサーバのための公開鍵（ＰＵ−ＤＲＭ）に従ってコンテンツ鍵（ＣＫ）を暗号化し、（ＰＵ−ＤＲＭ（ＣＫ））を生じるステップと、権利記述と（ＰＵ−ＤＲＭ（ＣＫ））との組合せを介して（ＰＵ−ＤＲＭ）に対応する秘密鍵（ＰＲ−ＤＲＭ）に基づいてディジタル署名を作成するステップとを含むことができる。
【００５６】
ステップ４０２で、アプリケーション３０２は、ディジタルコンテンツを暗号化するために使用されるコンテンツ鍵（ＣＫ）を生成する。コンテンツ鍵（ＣＫ）が対称鍵であることが好ましいが、一般に、ディジタルコンテンツを暗号化するためのどのような鍵も使用できる。対称鍵アルゴリズムは、時に「秘密鍵」アルゴリズムと呼ばれるが、メッセージを復号化するのに、そのメッセージを暗号化するのと同じ鍵を使用する。そのため、（ＣＫ）を秘密にしておくことが好ましい。送信側と受信側との間の（ＣＫ）の共用は、非常に注意深く行い、このような（ＣＫ）の無許可の傍受を回避すべきである。（ＣＫ）が暗号側と復号化側の両方の間で共用されているために、暗号化されたメッセージが伝送される前に（ＣＫ）が通信されることが好ましい。
【００５７】
いくつかの対称鍵生成アルゴリズムが当技術分野で周知である。好ましい実施形態ではデータ暗号化標準（ＤＥＳ）が用いられるが、どのような対称アルゴリズムも使用できることを理解されたい。このような対称鍵アルゴリズムの例には、Ｔｒｉｐｌｅ−ＤＥＳ、ＩＤＥＡ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ａｌｇｏｒｉｔｈｍ）、Ｃａｓｔ、Ｃａｓｔ−１２８、ＲＣ４、ＲＣ５、スキップジャック（ＳｋｉｐＪａｃｋ）が含まれるが、これに限定されるものではない。
【００５８】
ステップ４０４で、アプリケーション３０２は、ディジタルコンテンツを対称コンテンツ鍵（ＣＫ）で暗号化し、暗号化されたディジタルコンテンツ３０４を形成する。これは、表記（ＣＫ（ｃｏｎｔｅｎｔ））を使用して書かれる場合がある。アプリケーション３０２を使用している著者はまた、ディジタルコンテンツに関連する権利データを生成できる。権利データは、コンテンツを消費する資格があるエンティティのリストと、コンテンツについてエンティティのそれぞれが所有する特定の権利とを、これらの権利に課される任意の条件とともに、含むことができる。このような権利は、たとえば、コンテンツを表示すること、コンテンツを印刷することなどを含むことができる。アプリケーション３０２は、権利データをＡＰＩ３０６に提供する。ＸＭＬ／ＸｒＭＬフォーマットの権利データの例が、付録１として本明細書に添付されている。
【００５９】
ステップ４０６で、ＡＰＩ３０６は、コンテンツ鍵（ＣＫ）を暗号化するために使用される第２の暗号化鍵（ＤＥＳ１）を生成する。好ましくは、（ＤＥＳ１）もまた対称鍵である。ステップ４０８で、ＡＰＩ３０６は（ＣＫ）を（ＤＥＳ１）で暗号化し、（ＤＥＳ１（ＣＫ））が生じる。ステップ４１０で、ＡＰＩ３０６は、（ＣＫ）を廃棄し、その結果（ＣＫ）は（ＤＥＳ１（ＣＫ））を復号化することによってのみ取得できる。（ＣＫ（ｃｏｎｔｅｎｔ））が中央ＤＲＭサーバ３２０に対して保護されており、コンテンツのためのすべての「ライセンス要求」が権利データに従って中央で行われることを確実にするために、ＡＰＩ３０６は、ステップ４１２で、提供されたＤＲＭサーバ３２０にコンタクトし、その公開鍵（ＰＵ−ＤＲＭ）を取り出す。ステップ４１４で、ＡＰＩ３０６は、（ＤＥＳ１）を（ＰＵ−ＤＲＭ）で暗号化し、（ＰＵ−ＤＲＭ（ＤＥＳ１））が生じる。したがって、（ＣＫ）は、（ＰＵ−ＤＲＭ））に対して保護されて、ＤＲＭサーバ３２０が、（ＣＫ（ｃｏｎｔｅｎｔ））を復号化するために必要な（ＣＫ）へのアクセスを得ることのできる唯一のエンティティであることを確実にできる。ステップ４１６で、ＡＰＩ３０６は、権利データ（すなわち、許可されたエンティティのリストとリスト内のそれぞれの許可されたエンティティに関連する各権利および条件）を（ＤＥＳ１）で暗号化し、（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））が生じる。
【００６０】
代替実施形態においては、（ＣＫ）を使用して権利データを直接暗号化でき、その結果（ＣＫ（ｒｉｇｈｔｓｄａｔａ））が生じ、それにより全く（ＤＥＳ１）を使用しなくて済む。しかし、（ＤＥＳ１）を使用して権利データを暗号化することにより、このような（ＤＥＳ１）は、ＤＲＭサーバに従う義務のある可能性のある特定のアルゴリズムに従うことができるようになるが、それに対して（ＣＫ）は、ＤＲＭサーバから独立したエンティティによって指定でき、それに従う義務がないことがある。
【００６１】
ステップ４１８で、コンテンツ保護アプリケーション３０２は、（ＰＵ−ＤＲＭ（ＤＥＳ１））および（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））をＤＲＭサーバ３２０に、署名するための権利ラベルとして提出できる。あるいは、クライアント自体が権利データに署名できる。権利データが署名するためにサーバに提出されている場合、ステップ４２０で、ＤＲＭサーバ３２０は、権利データにアクセスし、提出された権利ラベル内の権利および条件を実施できることを検証する。権利データを実施できることを検証するために、ＤＲＭサーバ３２０は（ＰＲ−ＤＲＭ）を（ＰＵ−ＤＲＭ（ＤＥＳ１））に適用し、（ＤＥＳ１）が生じ、次いで（ＤＥＳ１）を（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））に適用し、疑いのない権利データが生じる。次いで、サーバ３２０はポリシチェックをして、権利データ内で指定されたユーザ、権利、条件が、サーバ３２０によって実施されたポリシ内にあることを検証できる。サーバ３２０は（ＰＵ−ＤＲＭ（ＤＥＳ１））および（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を含む元々提出された権利ラベルに署名し、署名権利ラベル（ＳＲＬ）３０８を生じるが、ここで署名はＤＲＭサーバ３２０の秘密鍵（ＰＲ−ＤＲＭ）に基づく。次いでＳＲＬ３０８をＡＰＩ３０６に返し、次いで返されたＳＲＬ３０８をクライアントアプリケーション３０２に提示する。
【００６２】
ＳＲＬ３０８は、ディジタルに署名されたドキュメントであり、それにより不正変更に対して強くなる。さらに、ＳＲＬ３０８は、コンテンツを暗号化するために使用される実際の鍵タイプおよびアルゴリズムから独立しているが、それが保護しているコンテンツに対して強力な１対１の関係を維持する。次に図４Ａを参照すると、本発明による一実施形態において、ＳＲＬ３０８は、とりわけ、恐らくコンテンツのＩＤを含むＳＲＬ３０８の基礎であるコンテンツに関する情報と、（ＰＵ−ＤＲＭ（ＤＥＳ１））およびネットワーク上にＤＲＭサーバを位置決めするためのＵＲＬなどの紹介情報およびＵＲＬが失敗した場合のフォールバック情報を含むＳＲＬ３０８に署名するＤＲＭサーバに関する情報と、ＳＲＬ３０８自体を記述する情報と、（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））すなわち（ＤＥＳ１（ＣＫ））と、Ｓ（ＰＲ−ＤＲＭ）とを含むことができる。ＸＭＬ／ＸｒＭＬＳＲＬ３０８のサンプルが、本明細書に付録２として添付されている。
【００６３】
トラステッド・エンティティが権利データに署名して、署名権利ラベル３０８を作成することを確実にすることにより、ＤＲＭサーバは、権利ラベル３０８の権利データに記載されているように、パブリッシャによって記載された条件に従ってコンテンツのためのライセンスを発行することを表明する。理解されるであろうが、ユーザは、ライセンスがコンテンツ鍵（ＣＫ）を含む場合は特に、ライセンスを取得してコンテンツをレンダリングする必要がある。ユーザが暗号化されたコンテンツのためのライセンスを取得したいと思った場合は、ユーザは、コンテンツのためのＳＲＬ３０８を含むライセンス要求およびユーザの資格証明を検証する証明書を、ＤＲＭサーバ３２０または他のライセンス発行エンティティに提示できる。次いで、ライセンス発行エンティティは、（ＰＵ−ＤＲＭ（ＤＥＳ１））および（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を復号化して、権利データを製作し、著者によって付与されたすべての権利を（もしあれば）ライセンス要求エンティティにリストし、これらの特定の権利のみでライセンスを構築できる。
【００６４】
好ましくは、アプリケーション３０２がＳＲＬ３０８を受信すると、このアプリケーション３０２は、署名権利ラベル３０８を対応する（ＣＫ（ｃｏｎｔｅｎｔ））３０４に連結して、権利管理されたディジタルコンテンツを形成する。あるいは、権利データは、暗号化されたディジタルコンテンツが提供されたその場所を参照して、周知の場所内に格納できる。したがって、ＤＲＭイネーブルされているレンダリングアプリケーションが、そのレンダリングアプリケーションがレンダリングすることを試みている１つのコンテンツを介して署名権利ラベル３０８を発見することができる。この発見により、レンダリングアプリケーションが、ＤＲＭライセンスサーバ３２０に対してライセンス要求を開始する。パブリッシングアプリケーション３０２が、ＵＲＬをたとえばＤＲＭライセンシングサーバ３２０に格納でき、またはＤＲＭライセンシングサーバ３２０は、それをディジタルに署名する前に、それ自体のＵＲＬを１つのメタデータとして権利ラベル内に埋め込むことができ、その結果、レンダリングアプリケーションによって呼び出されたＤＲＭクライアントＡＰＩ３０６は、正しいＤＲＭライセンシングサーバ３２０を識別できるようになる。好ましくは、たとえばグローバル一意識別子（ＧＵＩＤ）などの一意の識別子が、それが署名される前に権利ラベル内に入れられる。
【００６５】
本発明による好ましい実施形態においては、単純なオブジェクトアクセスプロトコル（ＳＯＡＰ）が、コンテンツ保護アプリケーション３０２またはレンダリングアプリケーションとＤＲＭサーバ３２０の間の通信のために使用できる。さらに、ＡＰＩ３０６などのＡＰＩライブラリが提供でき、その結果、アプリケーション３０２などのアプリケーションは、ＤＲＭプロトコルのクライアント側を実施するために必要ではなく、むしろローカルＡＰＩ呼出しを行えるだけである。好ましくは、ＸＭＬ言語であるＸｒＭＬが、ディジタルコンテンツのための権利記述、ライセンス、権利ラベルを記述するために使用されるが、権利記述および他のデータについては、どのような適切なフォーマットも使用できることを理解されたい。
【００６６】
パブリッシュされたコンテンツのためのライセンスを取得すること
図５は、権利管理されたディジタルコンテンツにライセンスを付与するための本発明によるシステムおよび方法の好ましい実施形態を示す機能ブロック図である。本明細書で使用する用語、「ライセンスを付与する（Ｌｉｃｅｎｓｉｎｇ）」とは、アプリケーションまたはサービスが、ライセンス内で名付けられたエンティティがライセンス内で指定された条件に従ってコンテンツを消費できるようにするライセンスを要求し受信するために従うプロセスを言う。ライセンスを付与するプロセスへの入力が、ライセンスが要求されているコンテンツに関連する署名権利ラベル（ＳＲＬ）３０８と、ライセンスが要求されている１つまたは複数のエンティティの１つまたは複数の公開鍵証明書とを含むことができる。ライセンスを要求しているエンティティが、必ずしもライセンスが要求されているエンティティであるとは限らないことに留意されたい。一般に、ライセンスは、ＳＲＬ３０８からの権利記述と、暗号化されたコンテンツを復号化できる暗号化された鍵と、権利記述および暗号化された鍵に対するディジタル署名とを含む。ディジタル署名は、名付けられたエンティティおよび権利が適合していることを表明する。
【００６７】
アプリケーション３０２が権利管理されたコンテンツ３１０を消費するための１つの方式は、クライアントＡＰＩ３０６が、通信ネットワーク３３０を介して権利管理されたコンテンツ３１０の署名権利ラベル３０８をＤＲＭサーバ３２０に転送することである。ＤＲＭサーバ３２０の場所は、たとえば、ＳＲＬ３０８内の紹介情報内で見つけることができる。このような実施形態においては、ＤＲＭライセンシングサーバ３２０は、以下に詳細に記述するプロセスを介して、権利ラベル内の権利記述を使用して、それがライセンスを発行できるかどうかを判断することができ、発行できる場合は、権利記述を導出してライセンスとともに含む。上述したように、権利ラベル３０８は、ＤＲＭサーバ３２０の公開鍵（ＰＵ−ＤＲＭ）に従って暗号化されるコンテンツ鍵（ＣＫ）（すなわち、（ＰＵ−ＤＲＭ（ＣＫ）））を含む。ライセンスを発行するプロセスにおいては、ＤＲＭサーバ３２０は、この値を安全に復号化して、（ＣＫ）を取得する。次いで、ライセンス要求内でのがした公開鍵証明書内の公開鍵（ＰＵ−ＥＮＴＩＴＹ）を使用して、（ＣＫ）を再暗号化する（すなわち、（ＰＵ−ＥＮＴＩＴＹ（ＣＫ）））。新しく暗号化された（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））は、サーバ３２０がライセンス内に入れるものである。したがって、関連する秘密鍵（ＰＲ−ＥＮＴＩＴＹ）の保持者のみが（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））から（ＣＫ）を回復することができるので、ライセンスは、（ＣＫ）を公表するリスクをおかさずに呼出側に返すことができる。次いで、クライアントＡＰＩ３０６は、（ＣＫ）を使用して暗号化されたコンテンツを復号化し、復号化されたディジタルコンテンツ３１２を形成する。次いで、クライアントアプリケーション３０２は、ライセンス内で提供された権利に従って復号化されたディジタルコンテンツ３１２を使用できるようになる。
【００６８】
あるいは、たとえばパブリッシングクライアントなどのクライアントが、それ自体のライセンスを発行して、コンテンツを消費できる。このような実施形態においては、安全なプロセスが、適切な状況下でディジタルコンテンツを復号化するのに必要な１つまたは複数の鍵をクライアントに提供するクライアントコンピュータ上で実行できる。
【００６９】
図６Ａおよび６Ｂは、権利管理されたディジタルコンテンツにライセンスを付与するための本発明による方法６００の好ましい実施形態を示す流れ図である。本発明によれば、要求エンティティが、１つまたは複数の可能性のあるライセンス保有者に代ってライセンス要求を提出できる。要求エンティティは、可能性のあるライセンス保有者の１つである場合もそうでない場合もある。可能性のあるライセンス保有者は、どのような方式ででもコンテンツを消費できる、人、グループ、デバイス、または任意の他のエンティティであり得る。次に、方法６００を一実施形態を参照しながら記述するが、ここでＤＲＭサーバがライセンス要求を処理するが、ライセンス要求の処理はクライアント上でも実行でき、かつライセンスはクライアントによって直接発行できることを理解されたい。
【００７０】
ステップ６０２で、たとえばＤＲＭサーバなどのライセンス発行エンティティが、ライセンス要求を受信する。好ましくは、ライセンス要求が、１つまたは複数の要求されたライセンス保有者のそれぞれについて公開鍵証明書または識別情報のいずれかを含む。ライセンス要求の好ましい実施形態のためのＳＯＡＰプロトコルは、以下の通りである。
【００７１】
【表１】

【００７２】
ステップ６０４で、要求エンティティ（すなわち、ライセンス要求を行うエンティティ）が認証される。本発明による一実施形態によれば、ライセンス発行エンティティは、プロトコル（たとえば、チャレンジ−応答）認証を使用して、要求エンティティの識別情報を判断するよう構成でき、または要求エンティティの認証を必要としない（「匿名認証を可能にする」としても周知である）よう構成できる。認証が必要な場合は、どのようなタイプの認証スキームも使用できる（たとえば、上述したチャレンジ−応答スキーム、ＭＩＣＲＯＳＯＦＴ．ＮＥＴ、ＰＡＳＳＰＯＲＴ、ＷＩＮＤＯＷＳ（登録商標）許可、ｘ５０９などのユーザｉｄおよびパスワードスキーム）。好ましくは、匿名認証が可能であり、統合情報システムによってサポートされているどのようなプロトコル認証スキームをもサポートする。認証ステップの結果は、たとえば、（匿名認証のための）「匿名」識別情報または個人口座識別情報などの識別情報であろう。ライセンス要求が何らかの理由で認証できなかった場合は、エラーが返され、ライセンスは付与されない。
【００７３】
ステップ６０６で、認証されたエンティティが許可される、すなわち、ステップ６０８で認証されたエンティティが、（それ自体のためまたは別のエンティティに代って）ライセンスを要求することが可能であるかどうかが判断される。好ましくは、ライセンス発行エンティティは、ライセンスを要求することが可能である（または可能でない）エンティティのリストを格納する。好ましい実施形態においては、識別情報のこのリスト内の識別情報は、ライセンスが要求されているエンティティの識別情報ではなく、要求を行っているエンティティの識別情報であるが、そのいずれでもあり得る。たとえば、個人口座識別情報が、直接ライセンス要求を行うことはできないが、トラステッド・サーバプロセスがこのエンティティに代ってライセンス要求を行うことができる。
【００７４】
本発明によれば、ライセンス要求は、それぞれ可能性のあるライセンス保有者について、公開鍵証明書または識別情報のいずれかを含むことができる。ライセンスがただ１つのライセンス保有者のみについて要求された場合は、ただ１つの証明書または識別情報が名付けられる。ライセンスが複数のライセンス保有者について要求された場合は、それぞれ可能性のあるライセンス保有者について証明書または識別情報を名付けることができる。
【００７５】
好ましくは、ライセンス発行エンティティは、それぞれの妥当なライセンス保有者のための公開鍵証明書を有する。しかし、アプリケーション３０２が、所与のユーザのためのライセンスを生成したいと思うことがあるが、アプリケーション３０２は、そのユーザのための公開鍵証明書へのアクセスを有さないことがある。このような状況においては、アプリケーション３０２は、ライセンス要求内にユーザの識別情報を指定でき、その結果、ライセンス発行エンティティは、ディレクトリサービス内のルックアップを実行し適切なユーザの公開鍵証明書を返す登録された証明書プラグインモジュールを起動できる。
【００７６】
ステップ６０８で、発行エンティティが、公開鍵証明書がライセンス要求内に含まれていないと判断した場合は、発行エンティティは、指定された識別情報を使用して、適切な公開鍵証明書のためにディレクトリサービスまたはデータベース内でルックアップを実行する。ステップ６１０で、発行エンティティが、証明書がディレクトリ内にあると判断した場合は、ステップ６１２で、証明書が取り出される。好ましい実施形態においては、証明書プラグインを使用して、ディレクトリアクセスプロトコル経由でディレクトリサービスから公開鍵証明書を取り出す。要求内またはディレクトリ内のいずれかで、所与の可能性のあるライセンス保有者のための証明書が見つけられなかった場合は、ライセンスサーバは、その可能性のあるライセンス保有者のためのライセンスを生成せず、ステップ６１４で、エラーが要求エンティティに返される。
【００７７】
ライセンス発行エンティティが少なくとも１人の可能性のあるライセンス保有者のための公開鍵証明書を有しているとみなすと、ステップ６１６で、発行エンティティは、ライセンス保有者証明書の信頼の妥当性を確認する。好ましくは、発行エンティティは、１組のトラステッド証明書発行者証明書とともに構成され、ライセンス保有者証明書の発行者がトラステッド発行者のリスト内にあるかどうかを判断する。ステップ６１６で、発行エンティティは、ライセンス保有者証明書の発行者がトラステッド発行者のリスト内にないと判断した場合は、そのライセンス保有者のための要求は失敗し、エラーがステップ６１４で生成される。したがって、トラステッド発行者によって証明書が発行されていないどのような可能性のあるライセンス保有者も、ライセンスを受け取らない。
【００７８】
さらに、発行エンティティは、好ましくは、トラステッド発行者証明書から個々のライセンス保有者公開鍵証明書までの証明書の連鎖内のすべてのエンティティ上でディジタル署名妥当性検査を実行する。連鎖内のディジタル署名の妥当性を確認するプロセスは、周知のアルゴリズムである。所与の可能性のあるライセンス保有者のための公開鍵証明書の妥当性が確認されなかった場合、または連鎖内の証明書の妥当性が確認されなかった場合は、可能性のあるライセンス保有者は信頼できず、したがってその可能性のあるライセンス保有者に対してライセンスが発行されない。そうでない場合は、ステップ６１８で、ライセンスが発行できる。ライセンスが要求されているすべてのエンティティが処理されるまで、ステップ６２０でプロセスを繰り返す。
【００７９】
図６Ｂに示されるように、ライセンス発行エンティティは次に進んで、ライセンス要求内で受信される署名権利ラベル３０８の妥当性を確認する。好ましい実施形態においては、発行エンティティは、権利ラベルプラグインおよびバックエンドデータベースを使用して、サーバ上に発行エンティティによって署名されたあらゆる権利ラベルのマスタコピーを格納できる。権利ラベルは、パブリケーションでそれらに入れられたＧＵＩＤによって識別される。ライセンス時に（ステップ６２２で）、発行エンティティは、ライセンス要求内の権利ラベル入力を解析し、そのＧＵＩＤを取り出す。次いで、このＧＵＩＤを権利ラベルプラグインに渡し、これがデータベースに対してクエリを発行して、マスタ権利ラベルのコピーを取り出す。マスタ権利ラベルは、ライセンス要求内で送信された権利ラベルのコピーと比べてより最新のものであることができ、以下のステップの要求内で使用される権利ラベルとなる。権利ラベルがＧＵＩＤに基づくデータベース内で見つけられなかった場合は、発行エンティティは、ステップ６２４でそのポリシをチェックし、まだ要求内の権利ラベルに基づいてライセンスを発行することが可能かどうかを判断する。ポリシによりこれが可能でなかった場合は、ステップ６２６でライセンス要求は失敗し、ステップ６２８でエラーがＡＰＩ３０６に返される。
【００８０】
ステップ６３０で、ライセンス発行エンティティは、権利ラベル３０８の妥当性を確認する。権利ラベル上のディジタル署名の妥当性が確認され、ライセンス発行エンティティが権利ラベルの発行者（それを署名したエンティティ）でなかった場合は、ライセンス発行エンティティは、権利ラベルの発行者が別のトラステッド・エンティティ（たとえば、ライセンス発行エンティティが鍵材料を共用できるようにされているエンティティ）であるかどうかを判断する。権利ラベルの妥当性が確認されなかった場合、またはトラステッド・エンティティによって発行されていない場合は、ステップ６２６でライセンス要求は失敗し、ステップ６２８でエラーがＡＰＩ３０６に返される。
【００８１】
すべての妥当性検査が行われた後、ライセンス発行エンティティは、権利ラベル３０８を承認済みライセンス保有者のそれぞれのためのライセンスに翻訳する。ステップ６３２で、ライセンス発行エンティティは、それぞれのライセンス保有者に発行すべきライセンスのための各権利記述を生成する。それぞれのライセンス保有者について、発行エンティティは、権利ラベル内の権利記述内で名付けられたエンティティに対してそのライセンス保有者の公開鍵証明書内で名付けられて識別情報を評価する。権利記述は、あらゆる権利または組の権利に、ライセンス内でその権利または組の権利を行使できる１組の識別情報を割り当てる。このライセンス保有者の識別情報が関連付けられているあらゆる権利または組の権利については、その権利または組の権利が、ライセンスのために新しいデータ構造内にコピーされる。結果として得られるデータ構造は、特定のライセンス保有者のためのライセンス内の権利記述である。このプロセスの一部として、ライセンス発行エンティティは、権利ラベルの権利記述内の権利または組の権利のいずれにも関連付けられている可能性のあるどのような前提条件をも評価する。たとえば、権利が、ライセンス発行エンティティが指定時間後にライセンスを発行することを制限する、それに関連付けられている時間前提条件を有することがある。この場合、発行エンティティは現在の時間をチェックする必要があり、前提条件で指定された時間を過ぎていた場合は、発行エンティティは、たとえそのライセンス保有者の識別情報がその権利に関連付けられていたとしても、その権利をライセンス保有者に発行できなくなる。
【００８２】
ステップ６３６で、発行エンティティは、権利ラベル３０８から（ＰＵ−ＤＲＭ（ＤＥＳ１））および（ＤＥＳ１（ＣＫ））をとり、（ＰＲ−ＤＲＭ）を適用して（ＣＫ）を取得する。次いで、発行エンティティは、（ＰＵ−ＥＮＴＩＴＹ）ライセンス保有者の公開鍵証明書を使用して（ＣＫ）を再暗号化し、（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））が生じる。ステップ６３８で、発行エンティティは、生成された権利記述を（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））と連結し、（ＰＲ−ＤＲＭ）を使用して結果として得られたデータ構造にディジタルに署名する。この署名されたデータ構造は、この特定のライセンス保有者のためのライセンスである。
【００８３】
ステップ６４０で、発行エンティティがこれ以上特定の要求について生成すべきライセンスがないと判断した場合は、ゼロまたはそれ以上のライセンスを生成する。ステップ６４２で、生成されたライセンスは、これらのライセンスに関連付けられた一連の証明書（たとえば、サーバ自体の公開鍵証明書ならびにその証明書を発行した証明書など）とともに要求エンティティに返される。
【００８４】
ライセンス応答の好ましい実施形態のためのＳＯＡＰプロトコルは、以下の通りである。
【００８５】
【表２】

【００８６】
本発明によるシステムの好ましい実施形態においては、複数のライセンス許諾者鍵が使用できる。このような実施形態においては、暗号化されて権利ラベル３０８を通ってライセンスに進行するコンテンツ鍵（ＣＫ）は、実際にどのような任意のデータでも良い。１つの特に有用な変形形態は、権利記述内の、それぞれ、異なる権利または異なる原理に関連付けられた複数の別個の暗号化されたコンテンツ鍵（ＣＫ）を使用することである。たとえば、アルバムの歌のディジタルバージョンは、すべて異なる鍵（ＣＫ）を用いて暗号化できる。これらの鍵（ＣＫ）は、同じ権利ラベル内に含まれるが、１つの原理は、歌の１つを再生する権利を有し（たとえば、自分のライセンス内の１つの鍵を得る権利のみを有する場合）、第２の原理は、すべての歌を再生する権利を有する（自分のライセンス内のすべての鍵を得る権利を有する場合）ことがある。
【００８７】
好ましくは、本発明によるシステムにより、パブリッシングアプリケーション／ユーザが、権利ラベル３０８内のライセンス保有者のグループまたはクラスを名付けることができる。このような実施形態においては、ライセンス発行エンティティは、権利ラベル内で名付けられたグループ／クラスを評価して、現在のライセンス保有者識別情報がこれらのグループ／クラスのメンバであるかどうかを判断する。名付けられたグループ／クラス内のメンバシップが見つかった場合は、発行エンティティは、そのグループ／クラスに関連付けられた権利または組の権利をライセンスのために使用される権利記述データ構造に追加できる。
【００８８】
本発明による好ましい実施形態においては、ＤＲＭサーバ内のパブリッシュおよびライセンスプロトコルインターフェースは、呼び出しているアプリケーションまたはユーザの認証および許可をサポートし、ＤＲＭサーバのための管理コンソールにより、アドミニストレータがインターフェースにライセンスを付与しそれをパブリッシュするためのアクセス制御リストを生成できる。このことにより、サーバの顧客が、ユーザ／アプリケーションがパブリッシュするか、ライセンスを付与するか、あるいはそれらの両方を行うことが可能となるポリシを適用できる。
【００８９】
署名権利ラベル３０８を修正することまたは再パブリッシュすること
本発明による一実施形態においては、コンテンツのユーザにそうするための十分な許可が付与されていた場合は、ＳＲＬ３０８が「再パブリッシュ」できる。つまり、可能ならば、ユーザは、ＳＲＬ３０８内の権利データを改変することができる。とりわけ、権利データを改変するためのこのような許可は、控えめかつ適切な判断で付与すべきであり、権利データを改変する許可を有するユーザが、基本的に関連付けられているコンテンツについて広範囲な権利をそれ自体に付与できる場合は特にそうである。このようなユーザが、コンテンツを公開する権利をそれ自体に付与し、それを世界に向けて転送することができることが想定される。
【００９０】
ここで、改変するための許可は、ＳＲＬ３０８内の権利データ内に、特定のユーザまたはあるクラスのユーザが実際に権利データおよび権利ラベル３０８を改変または「再パブリッシュ」できるという指示を含むことによって表される。ＤＲＭサーバ３２０がライセンスのための要求に関連してこのような許可を有するこのようなＳＲＬ３０８を受信した場合は、ＤＲＭサーバ３２０は、そのユーザのために要求されたライセンス内に、ユーザの公開鍵（すなわち、ＰＵ−ＥＮＴＩＴＹ）に従って暗号化された対称鍵（ＤＥＳ１）を含み、（ＰＵ−ＥＮＴＩＴＹ（ＤＥＳ１））を生じる。
【００９１】
したがって、ＳＲＬ３０８内の権利データを編集するために、次に図７を参照すると、ユーザは、（ＰＵ−ＥＮＴＩＴＹ（ＤＥＳ１））をライセンスから取り出し（ステップ７０１）、その（ＰＲ−ＥＮＴＩＴＹ）を適用し、（ＤＥＳ１）が生じ（ステップ７０３）、（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））をＳＲＬ３０８から取り出し（ステップ７０５）、その（ＤＥＳ１）を適用し、権利データが生じる（ステップ７０７）。その後、ユーザは、権利データを所望通りに改変し（ステップ７０９）、改変された権利データをＤＲＭサーバ３２０に図４について記載された方式で提出して、署名権利ラベル３０８を取得する（ステップ７１１）。ここでもちろん、署名権利ラベル３０８は、実際に再パブリッシュされたＳＲＬ３０８であり、したがっていったんＳＲＬ３０８が受信される（ステップ７１３）と、ユーザは、関連付けられたコンテンツに連結された元のＳＲＬ３０８を取り除き（ステップ７１５）、次いで再パブリッシュされたＳＲＬ３０８をこのようなコンテンツに連結する（ステップ７１７）。
【００９２】
したがって、理解されるであろうが、ＳＲＬ３０８を再パブリッシュすることにより、ユーザが、関連付けられたコンテンツを改変する必要もなく、権利、条件、ユーザを含む、ＳＲＬ３０８内の権利データを更新できるようになる。具体的には、再パブリッシュすることには、新しい（ＣＫ）を用いて関連付けられたコンテンツを再暗号化することは必要ではない。また、再パブリッシュすることには、元のＳＲＬ３０８が新しいＳＲＬ３０８にコピーできる多くのアイテムをその中に有している場合は特に、最初から新しいＳＲＬを生成することも必要がない。
【００９３】
署名権利ラベル３０８のセルフパブリッシング
本発明による一実施形態においては、ＳＲＬ３０８は、要求しているユーザ自体によって署名できる。したがって、ユーザは、ＤＲＭサーバ３２０にコンタクトして、関連付けられている１つのコンテンツのためのＳＲＬ３０８を取得する必要がない。その結果、セルフパブリッシングを、オフラインパブリッシングと呼ぶこともできる。このような実施形態においては、ユーザが、ＤＲＭサーバ３２０にコンタクトして、このようなセルフパブリッシュされたＳＲＬ３０８に基づいてライセンスを要求する必要があることがある。パブリッシングエンティティがそれ自体のライセンスを発行できることがあることも理解されたい。
【００９４】
具体的には、次に図８を参照すると、その実施形態において、ユーザがまず第１にＤＲＭサーバ３２０から、公開鍵（ＰＵ−ＣＥＲＴ）およびユーザの公開鍵（ＰＵ−ＥＮＴＩＴＹ）に従って暗号化された対応する秘密鍵（ＰＲ−ＣＥＲＴ）を含むＤＲＭ証明書８１０を受信することにより、セルフパブリッシュするようにされ、（ＰＵ−ＥＮＴＩＴＹ（ＰＲ−ＣＥＲＴ））を生じる。証明書は、ＤＲＭサーバ３２０の秘密鍵（ＰＲ−ＤＲＭ）によって署名されるべきであり、その結果、以下にさらに詳細に記載するように、このようなＤＲＭサーバ３２０がそれを検証できる。理解されるであろうが、ＤＲＭ証明書８１０は、ユーザがセルフパブリッシュすることを許可する。またこれも理解されるであろうが、鍵の対（ＰＵ−ＣＥＲＴ、ＰＲ−ＣＥＲＴ）は（ＰＵ−ＥＮＴＩＴＹ、ＰＲ−ＥＮＴＩＴＹ）とは別であり、特にセルフパブリッシングのために用いられる。鍵の対（ＰＵ−ＣＥＲＴ、ＰＲ−ＣＥＲＴ）はなくても良いことに留意されたい。この場合、ＤＲＭ証明書８１０は、ユーザの公開鍵（ＰＵ−ＥＮＴＩＴＹ）のみを含み、ＤＲＭサーバ３２０の秘密鍵（ＰＲ−ＤＲＭ）によって署名され、その結果、このＤＲＭサーバ３２０はそれを検証できる。
【００９５】
セルフパブリッシングは、ユーザが、それによって実行されるステップに関して基本的にＤＲＭサーバ３２０に代るという点で、図４に示されるパブリッシングとは異なる。明らかに、ユーザは、ＤＲＭ証明書８１０（すなわち、Ｓ（ＰＲ−ＣＥＲＴ））から取得された（ＰＲ−ＣＥＲＴ）で（ＰＵ−ＤＲＭ（ＤＥＳ１））および（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を含む提出された権利ラベルに署名し、署名権利ラベル（ＳＲＬ）３０８が生じる。理解されるであろうが、ユーザは、このようなＤＲＭ証明書８１０から（ＰＵ−ＥＮＴＩＴＹ（ＰＲ−ＣＥＲＴ））を取得し、それに（ＰＲ−ＥＮＴＩＴＹ）を適用することにより、ＤＲＭ証明書８１０から（ＰＲ−ＣＥＲＴ）を取得する。しかし、ユーザは、ＤＲＭサーバ３２０が提出された権利ラベル内の権利を実施できることを検証できないことに留意されたい。ユーザが（ＰＵ−ＤＲＭ（ＤＥＳ１））に適用するための（ＰＲ−ＤＲＭ）を有していない場合は特にそうである。したがって、ＤＲＭサーバ３２０自体は、セルフパブリッシュされたＳＲＬ３０８に基づいてライセンスが要求された時に、検証を実行すべきである。
【００９６】
いったんユーザがＳＲＬ３０８をセルフパブリッシュすると、ユーザは、それを製作するために用いられるこのようなセルフパブリッシュされたＳＲＬ３０８およびＤＲＭ証明書８１０をコンテンツに連結し、ＳＲＬ３０８およびＤＲＭ証明書８１０を有するこのようなコンテンツが別のユーザに配布される。その後、他のユーザが、ＤＲＭサーバ３２０からコンテンツのためにライセンスを、図６Ａおよび６Ｂに示された方式と実質的に同じ方式で要求し取得する。しかしここで、ライセンスを要求しているユーザは、コンテンツに連結されてセルフパブリッシュされたＳＲＬ３０８とＤＲＭ証明書８１０の両方をＤＲＭサーバ３２０に提出する。次いで、ＤＲＭサーバ３２０は、対応する（ＰＵ−ＤＲＭ）に基づいてＤＲＭ証明書８１０内のＳ（ＰＲ−ＤＲＭ）を検証し、（ＰＵ−ＣＥＲＴ）をＤＲＭ証明書８１０から取得する。次いで、ＤＲＭサーバ３２０は、取得した（ＰＵ−ＣＥＲＴ）に基づいてＳＲＬ３０８内のＳ（ＰＲ−ＣＥＲＴ）を検証し、上記と同じことを続行する。しかし、ユーザがＤＲＭサーバ３２０がＳＲＬ３０８内の権利を実施できることを検証しなかったので、かつ上記に記載されているように、ＤＲＭサーバ３２０自体が、この時に検証を実行すべきである。
【００９７】
権利テンプレート
上記のように、ユーザに、ユーザまたはクラスのユーザを定義し、それぞれ定義されたユーザまたはクラスのユーザのための権利を定義し、次いでどのような使用条件をも定義することにより、権利ラベル内のほとんどどのような多様なまたは種類の権利データをも作成する自由が提供される。しかし、明らかに、複数の権利ラベルのための権利データを繰り返して定義することは面倒であり反復的であろう。同じユーザまたはクラスのユーザ、権利、条件を、異なるコンテンツのために繰り返して定義する場合は特にそうである。このような状況は、たとえば、ユーザが特定の定義済みのチームのユーザと共用すべき異なるコンテンツを繰り返してパブリッシュするような企業またはオフィス環境で起きる場合がある。次いで、このような状況において、かつ本発明による一実施形態においては、ユーザが権利ラベルを作成することに関連して繰り返して用いることのできる権利テンプレートが作成され、その権利テンプレートは、定義済みの組のユーザまたはクラスのユーザ、それぞれの定義済みユーザまたはクラスのユーザのための定義済みの権利、定義済みの使用条件を既にその中に含んでいる。
【００９８】
本発明による一実施形態においては、次に図９を参照すると、権利テンプレート９００が、権利ラベル内と実質的に同じ権利データを有する。しかし、コンテンツがパブリッシュされるまで（ＤＥＳ１）が周知でないので、権利データは、権利ラベルの場合と同様に、このような（ＤＥＳ１）に従って暗号化できない。次いで、本発明による一実施形態においては、暗号化されていない権利データを有する権利テンプレート９００は、図４のステップ４１６で（ＤＥＳ１）で権利データを暗号化する課程で提出され、（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を製作する。もちろん、権利データは、暗号化される前に提出された権利テンプレート９００から取り出される。
【００９９】
権利テンプレートが構築される時に、ＤＲＭサーバ３２０およびその公開鍵（ＰＵ−ＤＲＭ）が周知である場合もそうでない場合もある。さらに、たとえ周知の場合でも、複数のＤＲＭサーバ３２０があり、それぞれがそれ自体の（ＰＵ−ＤＲＭ）を有する場合もそうでない場合もある。しかしそれにもかかわらず、権利テンプレートが構築される時に、ＤＲＭサーバ３２０およびその公開鍵（ＰＵ−ＤＲＭ）が周知である場合、かつただ１つのＤＲＭサーバ３２０が用いられるか、または権利テンプレート９００に関連して、ただ１つのＤＲＭサーバ３２０が用いられる場合に、このような権利テンプレートはまた、その公開鍵（ＰＵ−ＤＲＭ）を含み、権利テンプレート９００からの結果として得られる権利ラベルに署名すべきＤＲＭサーバに関する情報をその中に含むこともできる。このような（ＰＵ−ＤＲＭ）が、（ＤＥＳ１）を暗号化する時にＳＲＬ３０８内に現れ、（ＰＵ−ＤＲＭ（ＤＥＳ１））が生じるが、コンテンツがパブリッシュされるまで（ＤＥＳ１）は周知でないことを、再び理解されたい。したがって、権利テンプレート９００内の（ＰＵ−ＤＲＭ）は、権利ラベルの場合と同様に、このような（ＤＥＳ１）を暗号化できない。本発明による一実施形態においては、次いで、暗号化されていない（ＰＵ−ＤＲＭ）を有する権利テンプレート９００が、図４のステップ４１４で（ＰＵ−ＤＲＭ）で（ＤＥＳ１）を暗号化する課程で提出され、（ＰＵ−ＤＲＭ（ＤＥＳ１））を製作する。もちろん、（ＰＵ−ＤＲＭ）は、それが用いられる前に、提出された権利テンプレート９００から取り出される。
【０１００】
また上述の場合においては、権利テンプレート内に含むことのできるＤＲＭサーバに関する他の情報がまた、ネットワーク上にＤＲＭサーバを位置決めするためのＵＲＬなどの紹介情報と、ＵＲＬが失敗した場合のフォールバック情報とを含むことができる。いずれの場合においても、権利テンプレートはまた、とりわけ、権利テンプレート９００自体を記述する情報も含むことができる。権利テンプレート９００はまた、コンテンツおよび／または暗号化鍵（ＣＫ）および（ＤＥＳ１）に関連する権利ラベル内に現れる情報などの、パブリッシュすべきコンテンツに関連する情報のための空間を提供できるが、権利テンプレートのインスタンス生成が実際に権利ラベルに変換されない場合は、このような空間は必ずしも必要ではない。
【０１０１】
これまでに開示してきた権利テンプレート９００は、主にユーザのためのものであるが、状況によっては、ユーザが権利ラベル内の権利データを定義するために無制限の自由を有すべきではなく、作成できる権利ラベルの範囲またはタイプを制限するために権利テンプレート９００を使用できる状況もあることも理解されたい。たとえば、特に企業またはオフィス環境の場合に、特定のユーザが常にコンテンツを特定のクラスのユーザのみにパブリッシュすべきである、またはユーザがコンテンツを特定のクラスのユーザにパブリッシュすべきではないことが、ポリシとして定義済みであることがある。いずれの場合においても、本発明による一実施形態においては、このようなポリシは、１つまたは複数の権利テンプレート９００内に定義済み権利データとして包含され、ユーザは、コンテンツをパブリッシュする場合に、権利ラベルを作成するためにこのような権利テンプレートを用いることを制限されることがある。とりわけ、本発明の趣旨および範囲から逸脱することなく、ユーザのためのパブリッシングポリシを指定するためにユーザに使用可能となった権利テンプレートまたは１グループの権利テンプレートが、どのような特定のタイプのパブリッシングポリシをも指定できる。
【０１０２】
制限されたユーザなどのための権利テンプレート９００を指定するために、次に図１０を参照すると、アドミニストレータなどが実際に、定義済み権利データを定義し（ステップ１００１）、特定のＤＲＭサーバ３２０に関連する情報などの、必要であり適切な可能性があるどのような他のデータをも定義する（ステップ１００３）ことにより権利テンプレート９００を構築する。明らかに、制限されたユーザなどによって使用される権利テンプレートを実行するためには、権利テンプレート９００は公用になっていなければならない。つまり、権利テンプレート９００は、制限されたユーザなどが用いることのできる権利テンプレートとして認識可能でなければならない。したがって、本発明による一実施形態においては、アドミニストレータなどによって構築された権利テンプレートは、それによって署名するためにＤＲＭサーバ３２０に提出され、このように署名することにより、権利テンプレートが公用となる（ステップ１００５）。
【０１０３】
署名しているＤＲＭサーバ３２０は、実際にこのような情報が権利テンプレート９００内に存在する場合は、その情報が権利テンプレート９００内にあるＤＲＭサーバ３２０であることに留意されたい。また、ＤＲＭサーバ３２０は、必要なチェックを行う時にのみ権利テンプレート９００に署名できるか、または全くチェックせずに署名できることにも留意されたい。最後に、ＤＲＭサーバからのテンプレート署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）（ここで、Ｔは、署名がＯＲＴ９００用であることを表す）は、少なくとも権利テンプレート９００内の定義済み権利データに基づくべきであるが、本発明の趣旨および範囲から逸脱することなく他の情報に基づくこともできる。以下に記載するように、署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）は、権利ラベル内に組み込まれ、それについて検証され、したがってどのような署名も改変されていない形式で権利ラベル内に組み込まれるべきである。
【０１０４】
ＤＲＭサーバ３２０が、権利テンプレート９００に署名し、それをアドミニストレータなどに返すと、アドミニストレータは、Ｓ（ＰＲ−ＤＲＭ−Ｔ）で署名され現在は公用の権利テンプレート９００を受信し（ステップ１００７）、公用権利テンプレート（ＯＲＴ）９００ をそれによって使用する１つまたは複数のユーザに転送する（ステップ１００９）。したがって、ユーザがＯＲＴ９００に基づいてコンテンツをパブリッシュするためには、ユーザは、ＯＲＴ９００を検索し（ステップ１０１１）、コンテンツに関する情報、適切な鍵情報、（ＤＥＳ１）によって暗号化されたＯＲＴ９００からの権利データの結果生じた（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））、およびＯＲＴ９００からの他の情報などの、必要などのような情報をも提供することにより、ＯＲＴ９００に基づいて権利ラベルを構築する（ステップ１０１３）。明らかに、ユーザはまた、権利ラベルとともに、ＯＲＴ９００からの署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）を有する。
【０１０５】
その後、かつ上記と同様に、ユーザは、権利ラベルを署名するためにＤＲＭサーバ３２０に提出する（ステップ１０１５）。しかしここで、その中のＳ（ＰＲ−ＤＲＭ−Ｔ）が検証されなければ、ＤＲＭサーバ３２０は提出された権利ラベルに署名しない。つまり、このような提出された権利ラベルがＯＲＴ９００からの署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）を含まない場合は、ＤＲＭサーバ３２０は、提出された権利ラベルに署名することを拒絶することにより、ユーザがＯＲＴ９００上の提出された権利ラベルを基礎としなければならないことを実施する。具体的には、ＤＲＭサーバ３２０は、提出された権利ラベルからこのようなＳ（ＰＲ−ＤＲＭ−Ｔ）およびこのような署名が基礎をおいているどのような情報をも取り出し、次いで、（ＰＵ−ＤＲＭ）に基づいてこのような署名を検証する。提出された権利ラベル内の権利データは、（ＤＥＳ１）に従って暗号化されていることに留意されたい（すなわち、（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））。したがって、ＤＲＭサーバ３２０は、図７について上に記載したように、まず第１に（ＤＥＳ１）を取得し、提出された権利ラベル内の権利データに基づいて署名を検証できるように、それを用いて（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を復号化しなければならない。
【０１０６】
いったん検証されると、ＤＲＭサーバ３２０は、以前と同様に、Ｓ（ＰＲ−ＤＲＭ−Ｌ）で提出された権利ラベルに署名してＳＲＬ３０８を製作する（ここで、Ｌは、署名がＳＲＬ３０８のためであることを表す）。ここで、Ｓ（ＰＲ−ＤＲＭ−Ｌ）は Ｓ（ＰＲ−ＤＲＭ−Ｔ）を置換するか、またはこのようなＳ（ＰＲ−ＤＲＭ−Ｔ）に追加されることがある。さらに、Ｓ（ＰＲ−ＤＲＭ−Ｌ）が一部Ｓ（ＰＲ−ＤＲＭ−Ｔ）に基づくことがある。（ＰＲ−ＤＲＭ）を用いて、Ｓ（ＰＲ−ＤＲＭ−Ｔ）とＳ（ＰＲ−ＤＲＭ−Ｌ）の両方を製作できるか、またはＳ（ＰＲ−ＤＲＭ−Ｔ）およびＳ（ＰＲ−ＤＲＭ−Ｌ）のそれぞれについて異なる（ＰＲ−ＤＲＭ）を用いることができることに留意されたい。ＤＲＭサーバ３２０が権利ラベルに署名し、ＳＲＬ３０８をユーザに返すと、ユーザは、以前と同様に、Ｓ（ＰＲ−ＤＲＭ−Ｌ）でＳＲＬ３０８を受信し（ステップ１０１７）、次に進んで、それをパブリッシュされているコンテンツに連結する。
【０１０７】
ＯＲＴ９００の署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）が少なくとも一部はＯＲＴ９００内の定義済み権利データに基づいていると、このような権利データが、（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ）内の）ＳＲＬ３０８内に現れる時に、修正または変更できない。そうでない場合は、Ｓ（ＰＲ−ＤＲＭ−Ｔ）は検証しない。しかしそれにもかかわらず、本発明による一実施形態においては、ＯＲＴ９００内の権利データは、これもＯＲＴ９００内に含まれている規定された規則内で変更できる。たとえば、規則は、ＳＲＬ３０８内に含まれるべき２つの組の権利データの１つを指定できるか、または１組の代替物からの選択が可能である。理解されるであろうが、規則は、本発明の趣旨および範囲から逸脱することなく、どのような適切なシンタックスで記載されたどのような特定の規則でも良い。ここで、規則は、権利ラベルが作成される時に、ユーザのための適切な規則インタプリタによって解釈される。権利データは変化できるが、規則は同様に変化しなく、したがってＯＲＴ９００のためのテンプレート署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）は、少なくとも一部は規則に基づき、権利データ自体には基づかない。その結果、ＯＲＴ９００とともに含まれる規則は、ＳＲＬ３０８とともにも含まれなければならない。
【０１０８】
本発明による一実施形態においては、ＯＲＴ９００内の定義済み権利データは、上記に記載したように、一部は固定かつ不変であり、一部は可変かつ規則ドリブンである。ここで、ＯＲＴ９００のためのテンプレート署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）は、少なくとも一部は規則の固定部分および権利データの可変部分のための規則に基づく。
【０１０９】
理解されるであろうが、ＯＲＴ９００は、ユーザによって所有されたときには、旧式にまたは古くなっていることがある。つまり、その中の権利データを通ったＯＲＴ９００は、旧式で無関係な、または単にもはや適用不可能なポリシを反映していることがある。たとえば、ＯＲＴ９００の権利データ内で指定された１つまたは複数のユーザまたはクラスのユーザが、もはやポリシ環境内に存在しないか、またはＯＲＴ９００の権利データ内で指定された特定のユーザまたはクラスのユーザが、もはやポリシ環境内で同じ権利を有していないことがある。このような場合において、アドミニストレータは改訂したＯＲＴ９００を発行したが、ユーザはまだ以前の古いバージョンのＯＲＴ９００を使用していることがある。
【０１１０】
次いで、このような状況において、かつ本発明による一実施形態においては、ＤＲＭサーバ３２０は、ＯＲＴ９００を作成するために、提出された権利テンプレート９００に署名すると、ＯＲＴ９００のコピーを保持し、それぞれのＯＲＴ９００が一意の識別印（ｉｄｅｎｔｉｆｙｉｎｇ ｉｎｄｉｃｉａ）を有し、かつＯＲＴ９００に基づいて構築されたそれぞれの権利ラベルがこのようなＯＲＴ９００の識別印をその中に含む。したがって、図１０についてなどの提出された権利ラベルを受信すると、ＤＲＭサーバ３２０は、権利ラベル内のＯＲＴ９００の識別印を見つけ、見つけられた識別印に基づいてこのようなＯＲＴ９００の最新のコピーを検索し、提出された権利ラベルから権利データを除去し、検索されたＯＲＴ９００からの権利データを挿入し、次いで、少なくとも一部は挿入された権利データに基づいて権利ラベルに署名する。もちろん、ＤＲＭサーバはまた、（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））の復号化および再暗号化を含む、記載したプロセスに必要であり義務である必要な暗号化および復号化ステップを実行する。ＤＲＭサーバが提出された権利ラベル内の権利データを置換するよう適応されている場合は、このような権利ラベルおよびこのような権利ラベルがそれから構築されるＯＲＴ９００は、必ずしもその中に権利データを含む必要はない。そうではなく、権利データは、ＤＲＭサーバ３２０に常駐している必要があるだけである。しかし、権利ラベルおよびこのような権利ラベルがそれから構築されるＯＲＴ９００とともに権利データを含むことは、ユーザにとって有用であり得、したがっていくつかの状況においても有用であり得る。
【０１１１】
結論
本発明について実行されるプロセスを実施するのに必要なプログラミングは、比較的明快であり、関連するプログラミング関係者一般には自明である。したがって、このようなプログラミングについては、本明細書に添付していない。次いで、その趣旨および範囲から逸脱することなく本発明を実施するために、どのような特定のプログラミングも用いることができる。
【０１１２】
したがって、署名権利ラベルを介してディジタルコンテンツおよびサービスのための使用ライセンスを発行するためのシステムおよび方法を記述してきた。本発明の好ましい実施形態に対して、数々の変更形態および修正形態を行うことができ、かつこのような変更形態および修正形態が本発明の趣旨から逸脱することなく行うことができることは、当業者なら理解されるであろう。したがって、頭記の請求の範囲は、本発明の真の趣旨および範囲内に含まれるすべてのこのような均等な変形形態を包含するものとする。
【０１１３】
付録１
権利データのサンプル
【０１１４】
【表３】

【０１１５】
【表４】

【０１１６】
付録２
署名権利ラベル（ＳＲＬ）３０８のサンプル
【０１１７】
【表５】

【０１１８】
【表６】

【０１１９】
【表７】

【図面の簡単な説明】
【図１】本発明が実施できる限定されないコンピューティング環境の例を示すブロック図である。
【図２】本発明が実施できるさまざまなコンピューティングデバイスを備えたネットワーク環境の例を示すブロック図である。
【図３】ディジタルコンテンツをパブリッシュするための本発明によるシステムおよび方法の好ましい実施形態を示す機能ブロック図である。
【図４】権利管理されたディジタルコンテンツをパブリッシュするための本発明による方法の好ましい実施形態を示す流れ図である。
【図４Ａ】図４の方法によって製作された署名権利ラベルの構造を示すブロック図である。
【図５】権利管理されたディジタルコンテンツにライセンスを付与するための本発明によるシステムおよび方法の好ましい実施形態を示す機能ブロック図である。
【図６Ａ】権利管理されたディジタルコンテンツにライセンスを付与するための本発明による方法の好ましい実施形態を示す流れ図である。
【図６Ｂ】権利管理されたディジタルコンテンツにライセンスを付与するための本発明による方法の好ましい実施形態を示す流れ図である。
【図７】本発明による一実施形態に従って権利ラベルを再パブリッシュする際に実行される重要なステップを示す流れ図である。
【図８】ユーザが本発明による一実施形態に従ってオフラインパブリッシングを実行できるようにするために、ＤＲＭサーバによってユーザに発行された証明書を示すブロック図である。
【図９】本発明による一実施形態に従って権利ラベル内に組み込むべき情報を指定する権利テンプレートを示すブロック図である。
【図１０】本発明による一実施形態に従って、図９の権利テンプレートを作成し、権利テンプレートに基づいて図４Ａの署名権利ラベルを作成する際に実行される重要なステップを示す流れ図である。
【図１１】トラステッド・ベースのシステムの一例の実施アーキテクチャを示すブロック図である。
【符号の説明】
１０ コンピューティングオブジェクト
１２ ディジタルコンテンツ
１３ ディジタルコンテンツパッケージ
１４ 通信ネットワーク
１６ ライセンス
１８ コンポーネント
２０ データベース
１００ コンピューティングシステム環境
１１０ コンピュータ、コンピューティングオブジェクトまたはデバイス
１１１ デバイス
１２０ 処理ユニット
１２１ システムバス
１３０ システムメモリ
１３１ 読取専用メモリ（ＲＯＭ）
１３２ ランダムアクセスメモリ（ＲＡＭ）
１３３ 基本入出力システム
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４０ インターフェース
１４１ ハードディスクドライブ
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ インターフェース
１５１ 磁気ディスクドライブ
１５２ 取り外し可能、不揮発性磁気ディスク
１５５ 光学ディスクドライブ
１５６ 取り外し可能、不揮発性光学ディスク
１６０ ユーザ入力インターフェース
１６１ ポインティングデバイス
１６２ キーボード
１７０ アダプタ
１７１ ローカルエリアネットワーク（ＬＡＮ）
１７２ モデム
１７３ ワイドエリアネットワーク（ＷＡＮ）
１８０ リモートコンピュータ
１８１ 記憶装置デバイス
１８２ グラフィックスインターフェース
１８４ グラフィックス処理ユニット（ＧＰＵ）
１８５ リモートアプリケーションプログラム
１８６ ビデオメモリ
１９０ ビデオインターフェース
１９１ モニタ
１９５ 出力周辺インターフェース
１９６ プリンタ
１９７ スピーカ
３００ クライアント
３０２ コンテンツ準備アプリケーション
３０４ 暗号化されたディジタルコンテンツファイル
３０６ ディジタル権利管理（ＤＲＭ）アプリケーションプログラムインターフェース（ＡＰＩ）
３０８ 署名権利ラベル（ＳＲＬ）
３１０ 権利管理されたコンテンツファイル
３１２ 復号化されたディジタルコンテンツ
３２０ ＤＲＭサーバ
３３０ 通信ネットワーク
４００ 権利管理されたディジタルコンテンツをパブリッシュするための本発明による方法
６００ 権利管理されたディジタルコンテンツにライセンスを付与するための本発明による方法
８１０ ＤＲＭ証明書
９００ 権利テンプレート

Claims (12)

1. ディジタルコンテンツをパブリッシュして、ライセンスサーバが、前記コンテンツに対応するディジタルライセンスを、前記コンテンツをレンダリングすることを望む１つまたは複数のユーザのクライアントに発行できるようにする方法であって、
   コンテンツ所有者のクライアントが、コンテンツ鍵（ＣＫ）に従って前記コンテンツを暗号化して（ＣＫ（ｃｏｎｔｅｎｔ））を生じるステップと、
   前記コンテンツ所有者のクライアントが、対称鍵（ＤＥＳ１）を生成するステップと、
   前記コンテンツ所有者のクライアントが、（ＤＥＳ１）に従って（ＣＫ）を暗号化して（ＤＥＳ１（ＣＫ））を生じるステップと、
   前記コンテンツ所有者のクライアントが、前記ライセンスサーバのための公開鍵（ＰＵ−ＤＲＭ）に従って（ＤＥＳ１）を暗号化して（ＰＵ−ＤＲＭ（ＤＥＳ１））を生じ、前記ライセンスサーバが（ＰＲ−ＤＲＭ）を（ＰＵ−ＤＲＭ（ＤＥＳ１））に適用してＤＥＳ１を生じることにより（ＣＫ）にアクセスできるようにするステップと
   前記コンテンツ所有者のクライアントが、権利テンプレートを検索し、前記権利テンプレートから前記コンテンツに関連付けられるべき権利データを取り出すステップと、
   前記コンテンツ所有者のクライアントが、（ＤＥＳ１）に従って前記権利データを暗号化して（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を生じるステップと、
   前記コンテンツ所有者のクライアントが、（ＤＥＳ１（ＣＫ））および（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を前記ライセンスサーバへ権利ラベルとして提出し、それによりそれにより前記ライセンスサーバが署名するステップであって、前記ライセンスサーバは前記権利ラベルの妥当性を確認し、妥当であった場合は、（ＰＵ−ＤＲＭ）に対応する秘密鍵（ＰＲ−ＤＲＭ）に基づいてかつ少なくとも一部は前記暗号化されている権利データに基づいてディジタル署名を作成して署名権利ラベル（ＳＲＬ）を生じ、前記ＳＲＬを返すステップと、
   前記コンテンツ所有者のクライアントが、前記返されたＳＲＬを受信し、このような受信されたＳＲＬを（ＣＫ（ｃｏｎｔｅｎｔ））に連結して、コンテンツパッケージを形成するステップと、
   前記コンテンツ所有者のクライアントが、前記コンテンツパッケージを前記１つまたは複数のユーザのクライアントに配布し、それにより、前記コンテンツをレンダリングすることを望む前記ユーザのクライアントは、前記ＳＲＬを前記コンテンツパッケージから取り出し、前記コンテンツに対応する前記ライセンスの要求の一部として前記取り出されたＳＲＬを前記ライセンスサーバに提出し、それにより、前記ライセンスサーバは、（ＰＵ−ＤＲＭ）に基づいてかつ少なくとも一部は前記暗号化されている権利データに基づいて前記ＳＲＬの前記署名を検証し、前記ＳＲＬ内の前記暗号化されている権利データにアクセスし再検討して、前記ユーザのクライアントが前記ライセンスの資格があるかどうかを判断し、資格があれば、前記ユーザのクライアントからアクセス可能な暗号化されている形式で（ＣＫ）を含む前記ライセンスを前記ユーザのクライアントに発行するステップとを備えることを特徴とする方法。
2. 前記コンテンツ所有者のクライアントが、（ＤＥＳ１）に従って（ＣＫ）を暗号化して（ＤＥＳ１（ＣＫ））を生じた後に（ＣＫ）を廃棄し、（ＤＥＳ１（ＣＫ））を復号化することによってのみ（ＣＫ）を取得できるようにするステップをさらに備えることを特徴とする請求項１に記載の方法。
3. 前記コンテンツ所有者のクライアントが、対称コンテンツ鍵（ＣＫ）に従って前記コンテンツを暗号化し、（ＣＫ（ｃｏｎｔｅｎｔ））を生じるステップを備えることを特徴とする請求項１に記載の方法。
4. 前記コンテンツ所有者のクライアントが、前記権利テンプレートから、前記コンテンツをレンダリングする資格があるそれぞれのエンティティと、それぞれのエンティティについて前記エンティティが前記コンテンツをレンダリングすることに関して所有するそれぞれの権利とを含む権利データを取り出すステップであって、それぞれのエンティティはユーザおよびクラスのユーザの一方を表すステップを備えることを特徴とする請求項１に記載の方法。
5. 前記コンテンツ所有者のクライアントが、前記権利テンプレートから、前記エンティティが前記コンテンツをレンダリングすることに関して所有する前記権利の少なくともいくつかのうちのそれぞれについて前記権利を行使するための前提条件を有する権利データを取り出すステップを備えることを特徴とする請求項４に記載の方法。
6. 前記コンテンツ所有者のクライアントが、前記暗号化されている権利データ、前記暗号化されているコンテンツ鍵（ＣＫ）、その識別子を有する前記コンテンツに関する情報を前記ライセンスサーバへ前記権利ラベルとして提出し、それにより前記ライセンスサーバが署名するステップを備えることを特徴とする請求項１に記載の方法。
7. 前記ライセンスサーバが、前記ライセンスサーバを位置決めするためのアドレス情報を含む前記ライセンスサーバに関する情報を前記権利ラベルに追加し、前記ライセンスサーバに関する情報を含む前記ＳＲＬを返し、前記方法は、前記コンテンツ所有者のクライアントが、前記ライセンスサーバに関する情報を含む前記返されたＳＲＬを受信するステップを備えることを特徴とする請求項１に記載の方法。
8. 前記コンテンツ所有者のクライアントが、前記権利テンプレートから（ＰＵ−ＤＲＭ）を取り出すステップをさらに備えることを特徴とする請求項１に記載の方法。
9. 前記権利データを有する前記権利テンプレートは、アドミニストレータからの公用権利テンプレート（ＯＲＴ）であり、（ＰＲ−ＤＲＭ）に基づいてかつ少なくとも一部は前記権利データに基づく前記ライセンスサーバからのディジタル署名（Ｓ（ＰＲ−ＤＲＭ−Ｔ））を有し、前記方法は、前記コンテンツ所有者のクライアントが、Ｓ（ＰＲ−ＤＲＭ−Ｔ）、前記暗号化されている権利データ、前記暗号化されているコンテンツ鍵（ＣＫ）を、前記ライセンスサーバへ前記権利ラベルとして提出し、それにより前記ライセンスサーバが署名するステップであって、前記ライセンスサーバは、Ｓ（ＰＲ−ＤＲＭ−Ｔ）を検証し、検証された場合は、前記権利ラベルの妥当性を確認し、妥当であった場合は、（ＰＵ−ＤＲＭ）に対応する秘密鍵（ＰＲ−ＤＲＭ）に基づいてかつ少なくとも一部は前記暗号化されている権利データに基づいてディジタル署名（Ｓ（ＰＲ−ＤＲＭ−Ｌ）を作成して署名権利ラベル（ＳＲＬ）を生じ、前記ＳＲＬを返すステップを備えることを特徴とする請求項１に記載の方法。
10. ライセンスサーバが署名権利ラベル（ＳＲＬ）をユーザに提供するための方法であって、前記ＳＲＬは、該ＳＲＬからディジタルライセンスを取得する前記ライセンスサーバに提出されて、対応するパブリッシュされたディジタルコンテンツのレンダリングを可能にし、前記コンテンツは、コンテンツ鍵（ＣＫ）に従って暗号化されて（ＣＫ（ｃｏｎｔｅｎｔ））を生じ、前記ライセンスサーバによって実行される前記方法は、
    コンテンツ所有者のクライアントから、対称鍵（ＤＥＳ１）に従って暗号化されている（ＣＫ）と、公用権利テンプレート（ＯＲＴ）から取り出され対称鍵（ＤＥＳ１）に従って暗号化されている権利データと、前記ＯＲＴからのディジタル署名とを含む権利ラベルを受信するステップであって、（ＤＥＳ１）は前記ライセンスサーバのための公開鍵（ＰＵ−ＤＲＭ）に従って暗号化され、前記署名（Ｓ（ＰＲ−ＤＲＭ−Ｔ））は、（ＰＵ−ＤＲＭ）に対応する秘密鍵（ＰＲ−ＤＲＭ）に基づきかつ少なくとも一部は前記ＯＲＴ内の前記権利データに基づいており、前記ライセンスサーバは、（ＰＲ−ＤＲＭ）を前記暗号化された（ＤＥＳ１）に適用して（ＤＥＳ１）を生じることにより（ＣＫ）にアクセスできるステップと、
    少なくとも一部は前記権利ラベル内の前記暗号化されている権利データに基づいてＳ（ＰＲ−ＤＲＭ−Ｔ）を検証するステップと、
    前記権利ラベルの妥当性を確認するステップと、
    Ｓ（ＰＲ−ＤＲＭ−Ｔ）が検証され、前記権利ラベルの妥当性が確認されると、
    （ＰＲ−ＤＲＭ）に基づいてかつ少なくとも一部は前記暗号化されている権利データに基づいてディジタル署名（Ｓ（ＰＲ−ＤＲＭ−Ｌ））を作成し、
    Ｓ（ＰＲ−ＤＲＭ−Ｌ）を前記受信された権利ラベルに付加し、前記署名権利ラベル（ＳＲＬ）を生じ、
    前記ＳＲＬを前記コンテンツ所有者のクライアントに返し、前記コンテンツ所有者のクライアントは、前記返されたＳＲＬを受信し、（ＣＫ（ｃｏｎｔｅｎｔ））でこのような受信されたＳＲＬを連結してコンテンツパッケージを作成し、前記コンテンツパッケージを前記１つまたは複数のユーザのクライアントに配布し、それにより、前記コンテンツをレンダリングすることを望むユーザのクライアントは、前記ＳＲＬを前記コンテンツパッケージから取り出し、前記コンテンツに対応する前記ライセンスの要求の一部として前記取り出されたＳＲＬを前記ライセンスサーバに提出し、それにより、前記ライセンスサーバは、（ＰＵ−ＤＲＭ）に基づいてかつ少なくとも一部は前記暗号化されている権利データに基づいてＳ（ＰＲ−ＤＲＭ−Ｌ）を検証し、前記ＳＲＬ内の前記暗号化されている権利データにアクセスし再検討して、前記ユーザのクライアントが前記ライセンスの資格があるかどうかを判断し、資格があれば、前記ライセンスを前記ユーザのクライアントに発行し、前記ライセンスは、前記ユーザのクライアントからアクセス可能な暗号化されている形式で（ＣＫ）を含むステップとを備えることを特徴とする方法。
11. 前記コンテンツ所有者のクライアントから、前記コンテンツをレンダリングする資格があるそれぞれのエンティティと、それぞれのエンティティについて前記エンティティが前記コンテンツをレンダリングすることに関して所有するそれぞれの権利とを含む権利データを有する権利ラベルを受信するステップであって、それぞれのエンティティはユーザおよびクラスのユーザの一方を表すステップを備えることを特徴とする請求項１０に記載の方法。
12. 前記コンテンツ所有者のクライアントから、前記エンティティが前記コンテンツをレンダリングすることに関して所有する前記権利の少なくともいくつかのうちのそれぞれについて、前記権利を行使するための前提条件を含む権利データを含む権利ラベルを受信するステップを備えることを特徴とする請求項１１に記載の方法。

Images