JP2004246902A - 組織などの限定された領域内におけるデジタル著作権管理（ｄｒｍ）システムによるデジタルコンテンツのパブリッシュ - Google Patents

Abstract

【課題】 組織などの限定された領域内においてデジタル著作権管理（ＤＲＭ）システムによるデジタルコンテンツのパブリッシュを提供すること。
【解決手段】 ライセンサが要求者から要求を受け取り、この要求はコンテンツに関連付けられた権利データを含み、この権利データは少なくとも１つの識別子と該識別子に関連付けられた権利のセットをリストする。ライセンサは、識別子と該識別子に関連付けられる権利のセットを選択し、この権利は対応するデジタルライセンス中に設定されるものであり、また識別子に基づき代替の権利セットも選択する。代替の権利セットは、権利データ中の権利セットの代わりに使用され、その代替の権利セットを用いて要求者にライセンスを発行し、そうすることで発行したライセンス中の代替の権利セットにより、要求者が対応するコンテンツのレンダリングと関連して守らなければならない諸規定および諸条件を設定する。
【選択図】 図１４

Description

本発明は、デジタル著作権管理（ＤＲＭ）システムに関する。より詳細には、本発明は、組織、オフィス、会社内などの範囲が限定された領域内で、対応する使用またはライセンスの条件に従って、その領域内でのコンテンツのレンダリングおよび使用を制限できるように、ＤＲＭシステムを用いてデジタルコンテンツをパブリッシュすることに関する。

デジタル著作権の管理および施行は、デジタルオーディオ、デジタルビデオ、デジタルテキスト、デジタルデータ、デジタルマルチメディアなどのデジタルコンテンツを１人または複数のユーザに配布する場合に、そのようなコンテンツと関連して非常に望まれている。デジタルコンテンツは、例えばテキスト文書など静的な場合もあるし、またはライブイベントのストリーミングされるオーディオ／ビデオなどストリーミングされる場合もある。典型的な配布形態には、磁気（フロッピー（登録商標））ディスク、磁気テープ、光（コンパクト）ディスク（ＣＤ）などの有形のデバイスと、電子掲示板や電子ネットワーク、インターネットなどの無形の媒体が含まれる。ユーザは、デジタルコンテンツを受け取ると、パーソナルコンピュータ上のメディアプレーヤなどの適切なレンダリングデバイスを用いてデジタルコンテンツをレンダリングすなわち「再生」する。

１つのシナリオでは、作成者、出版社、放送事業者などのコンテンツ所有者または著作権者は、ライセンス料やその他の対価と引き換えに多数のユーザまたは受領者各々にこのようなデジタルコンテンツを配布することを望んでいる。そのようなシナリオでは、コンテンツは歌曲、歌曲のアルバム、映画などであり、配布の目的はライセンス料を生み出すことである。そのようなコンテンツ所有者は、選択肢があれば、配布されたデジタルコンテンツにユーザが行える事を制限したいとおそらく考えるであろう。例えば、コンテンツ所有者は、少なくともコンテンツ所有者が第２のユーザからライセンス料を得られないような形で、ユーザがコンテンツをコピーし、第２のユーザに再配布することを制限したいと考えるであろう。

また、コンテンツ所有者は、異なるタイプのライセンスを異なるライセンス料で購入する柔軟性をユーザに提供すると同時に、実際に購入したライセンスがどのようなタイプであれ、その条件をユーザに守らせることを望む場合がある。例えば、コンテンツ所有者は、配布されたデジタルコンテンツの再生を制限された回数のみ、一定の合計時間のみ、特定タイプのマシンのみ、特定タイプのメディアプレーヤのみ、特定タイプのユーザにのみ許可したいと考える場合がある。

別のシナリオでは、組織の従業員やメンバなどのコンテンツ開発者が、その組織の１人または複数の他の従業員またはメンバ、あるいは組織外の他の者にそうしたデジタルコンテンツを配布したいが、他人がそのコンテンツをレンダリングできないようにしたい場合がある。この場合のコンテンツの配布は、ライセンス料や何らかの他の対価と引き換えに行われる広域にわたる配布とは反対に、内々で、あるいは制限付きの形態で行われる組織内のコンテンツ共有により近いものとなる。

そのようなシナリオでは、コンテンツは、オフィス環境内で交換されるような文書プレゼンテーション、表計算、データベース、電子メールなどであり、コンテンツの開発者は、コンテンツが組織内あるいはオフィスの環境内に留まり、例えば競争相手や敵対者などの認可されていない者によってレンダリングされないようにしたいと思う場合がある。この場合も、そのようなコンテンツ開発者は、配布されるデジタルコンテンツに受領者が行える事を制限したいと望む。例えば、コンテンツ所有者は、少なくともコンテンツのレンダリングが許可されるべき者の範囲外にコンテンツが公開されるような形態でユーザがコンテンツをコピーし、第２のユーザに再配布することを制限したいと考えるであろう。

また、コンテンツ開発者は、様々な受信者に異なるレベルのレンダリング権を与えたい場合がある。例えば、コンテンツ開発者は、あるクラスの者には保護されたデジタルコンテンツを閲覧できるが印刷できないようにし、別のクラスの者には閲覧も、印刷もできるようにしたいと思う場合がある。

しかしどのシナリオでも、配布が行われた後は、そのようなコンテンツ所有者／開発者は、デジタルコンテンツに対するコントロールを持つにしてもごくわずかしか持っていない。これは特に、そのようなデジタルコンテンツの正確なデジタルコピーを作成し、その正確なデジタルコピーを書き込み可能な磁気ディスクまたは光ディスクにダウンロードするか、インターネットなどのネットワークを通じてその正確なデジタルコピーを任意の宛先に送信するために必要なソフトウェアおよびハードウェアをほぼすべてのパーソナルコンピュータが含んでいることを考えると問題である。

言うまでもなく、コンテンツが配布されるトランザクションの一部として、コンテンツ所有者／開発者は、デジタルコンテンツのユーザ／受領者に、そのようなデジタルコンテンツを歓迎されない形態で再配布しないことを約束させることができる。しかし、そのような約束は容易に行われ、容易に破られるものである。コンテンツ所有者／開発者は、通例は暗号化および解読を伴ういくつかの周知のセキュリティ機構のいずれかを通じてそのような再配布の防止を試みることができる。しかし、約束の遵守をさほど真剣に考えていないユーザが暗号化されたデジタルコンテンツを解読し、それを暗号化されていない形式で保存し、再配布するのを防止できる見込みは非常に少ない。

したがって、デジタル著作権管理（ＤＲＭ）および施行のアーキテクチャと、任意の形式のデジタルコンテンツのコントロールされたレンダリングまたは再生を可能にする方法を提供する必要性があり、この場合、そのようなコントロールは、柔軟性があり、そのデジタルコンテンツのコンテンツ所有者／開発者によって定義可能であることが必要とされる。より具体的には、特に限定された個人のグループまたは個人のクラスの間で文書を共有することになるオフィスや組織環境などで、そのようなコントロールされたレンダリングを可能にし、容易にするアーキテクチャが必要とされている。

上述の必要性は、ライセンサ（ｌｉｃｅｎｓｏｒ）が要求者にデジタルライセンスを発行して、要求者が対応するデジタルコンテンツをレンダリングすることを許可する本発明により少なくとも部分的に満たされる。

本発明では、ライセンサが要求者から要求を受け取り、この要求はコンテンツに関連付けられた権利データを含み、権利データは、少なくとも１つの識別子とその識別子に関連付けられた権利のセットをリストする。ライセンサは、識別子とその識別子に関連付けられた権利のセットを選択し、このような権利は発行されるライセンス中に指示されることになり、また識別子に基づき代替の権利セットも選択する。代替の権利セットは、権利データの権利セットの代わりに使用され、その代替の権利セットを用いて要求者にライセンスが発行され、それにより発行されたライセンス中の代替の権利セットが、対応するコンテンツのレンダリングと関連して要求者が守らなければならない諸規定（ｔｅｒｍｓ）および諸条件を指定する。

（コンピュータ環境）
図１および以下の説明は、本発明を実施することが可能な適切なコンピューティング環境の簡潔で一般的な説明を提供するものである。ただし、本発明と関連して使用するために、あらゆる種類のハンドヘルド型、可搬型、および他のコンピューティングデバイスが企図されることを理解されたい。以下では汎用コンピュータについて記載するが、これは一例に過ぎず、本発明では、ネットワークサーバとの相互運用性とインタラクションを有するシンクライアント（ｔｈｉｎ ｃｌｉｅｎｔ）で十分である。したがって、本発明は、例えばクライアントデバイスが単にブラウザすなわちワールドワイドウェブとのインタフェースとして機能するネットワーク化された環境など、非常に小さいかあるいは最小限のクライアントリソースが関係する、ネットワーク化されたホストサービスの環境で実施することもできる。

必須ではないが、本発明は、開発者による使用のために、アプリケーションプログラムインタフェース（ＡＰＩ）を介して実施することができ、そして／または、ネットワークブラウジングソフトウェア中に含めることができる。これについては、クライアントワークステーション、サーバ、または他のデバイスなどの１つまたは複数のコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令との一般的な関連で説明する。一般に、プログラムモジュールには、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。通例、プログラムモジュールの機能は、各種の実施形態での必要に応じて組み合わされても、分散されてもよい。さらに、当業者には、本発明が他のコンピュータシステム構成でも実施できることが認識されよう。本発明と共に使用するのに適する可能性がある他の周知のコンピューティングシステム、環境、および／または構成には、これらに限定されないが、パーソナルコンピュータ（ＰＣ）、自動現金預け払い機、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能な民生電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどがある。本発明は、通信ネットワークまたは他のデータ伝送媒体を通じてリンクされた遠隔の処理装置によってタスクが行われる分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含むローカルおよびリモート両方のコンピュータ記憶媒体に配置されることがある。

図１に、本発明を実施することが可能な適切なコンピューティングシステム環境１００の一例を示すが、上記で明らかにしたように、コンピューティングシステム環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲について何らの制限を示唆するものではない。コンピューティング環境１００は、例示的動作環境１００に示した構成要素の任意の１つまたは組合せに関連するいかなる依存関係または要件を有するものとして解釈されるべきではない。

図１を参照すると、本発明を実施するための例示的システムは、コンピュータ１１０の形態の汎用コンピューティングデバイスを含んでいる。コンピュータ１１０の構成要素には、これらに限定されないが、処理装置１２０、システムメモリ１３０、およびシステムメモリを含む各種のシステム構成要素を処理装置１２０に結合するシステムバス１２１が含まれる。システムバス１２１は、メモリバスもしくはメモリコントローラ、ペリフェラルバス、および各種のバスアーキテクチャの任意のものを使用したローカルバスを含む任意の数タイプのバス構造とすることができる。限定ではなく、例として、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バス（メザニンバスとも称される）が含まれる。

コンピュータ１１０は、通例、各種のコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０がアクセスすることができる任意の利用可能な媒体とすることができ、揮発性および不揮発性の両媒体、取り外し可能および取り外し不可の両媒体が含まれる。限定ではなく、例として、コンピュータ可読媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術に実装された揮発性および不揮発性の両媒体、取り外し可能および取り外し不可の両媒体を含む。コンピュータ記憶媒体には、これらに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または所望の情報の記憶に用いることができ、コンピュータ１１０によるアクセスが可能な他の任意の媒体が含まれる。通信媒体は、通例、搬送波または他のトランスポート機構などの変調データ信号にコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを具現し、任意の情報伝達媒体を含む。用語「変調データ信号」とは、信号中に情報を符号化する様態でその信号の特性の１つまたは複数を設定または変化させた信号を意味する。限定ではなく、例として、通信媒体は、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体とを含む。上記の媒体のいずれの組合せもコンピュータ可読媒体の範囲に含まれるべきである。

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

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

上記で説明し、図１に示したドライブとそれらに関連付けられたコンピュータ記憶媒体は、コンピュータ１１０のコンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの記憶を提供する。例えば、図１では、ハードディスクドライブ１４１はオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納しているものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じものでも、異なるものでもよいことに留意されたい。ここではオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、それらが少なくとも異なるコピーであることを表すために異なる参照番号をつけている。ユーザは、キーボード１６２および一般にはマウスと称されるポインティングデバイス１６１、トラックボールまたはタッチパッドなどの入力装置を通じてコンピュータ１１０にコマンドおよび情報を入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどがある。これらおよび他の入力装置は、システムバス１２１に結合されたユーザ入力インタフェース１６０を通じて処理装置１２０に接続されることが多いが、パラレルポート、ゲームポート、あるいはユニバーサルシリアルバス（ＵＳＢ）など他のインタフェースおよびバス構造によって接続されることもある。

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

コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の共通ネットワークノードでよく、図１にはメモリ記憶装置１８１しか示していないが、通例はコンピュータ１１０と関連して上記で挙げた要素の多くまたはすべてを含む。図１に示した論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークを含んでもよい。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットに一般的に見られる。

ＬＡＮネットワーキング環境で使用する場合、コンピュータ１１０はネットワークインタフェースまたはアダプタ１７０を通じてＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する場合、コンピュータ１１０は通例、インターネットなどのＷＡＮ１７３を通じて通信を確立するためのモデム１７２またはその他の手段を含む。モデム１７２は、内蔵型でも外付け型でもよく、ユーザ入力インタフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０との関連で図示したプログラムモジュール、またはその一部は、遠隔のメモリ記憶装置に格納することができる。限定ではなく、例として、図１ではリモートアプリケーションプログラム１８５がメモリ装置１８１にあるものとして示している。図のネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立する他の手段を使用できることは理解されよう。

当業者には、コンピュータ１１０または他のクライアントデバイスは、コンピュータネットワークの一部として配備できることを理解されよう。これに関して、本発明は、任意数のメモリまたは記憶装置と、任意数の記憶装置またはボリュームにわたって実行される任意数のアプリケーションおよびプロセスとを有するコンピュータシステムに関する。本発明は、リモートまたはローカルの記憶装置を有するネットワーク環境内に配備されたサーバコンピュータとクライアントコンピュータを含む環境に適用することができる。本発明は、プログラミング言語の機能、変換処理および実行の機能を有するスタンドアロンのコンピューティングデバイスにも適用することができる。

分散コンピューティングは、コンピューティングデバイスおよびシステム間での直接交換によりコンピュータリソースおよびサービスの共有を容易にする。このリソースおよびサービスには、情報の交換、キャッシュストレージ、およびファイルのディスクストレージが含まれる。分散コンピューティングはネットワークの接続性を活用して、クライアントが集合的な力を利用して企業全体を利することができるようにする。これに関して、信頼のおけるグラフィックパイプラインのために本発明による認証技術に協働して係わることのできるアプリケーション、オブジェクト、またはリソースを各種のデバイスが有している可能性がある。

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

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

分散コンピューティング環境に対応する各種のシステム、コンポーネント、およびネットワーク構成がある。例えば、コンピューティングシステムは、ローカルネットワークまたは広域分散ネットワークで、配線または無線システムにより共に接続することができる。現在、ネットワークの多くはインターネットに接続されている。インターネットは、広域分散コンピューティングのためのインフラストラクチャを提供し、多くの様々なネットワークを包含している。

家庭のネットワーク環境では、電力線、データ（無線および有線）、音声（例えば電話）、および娯楽媒体など、それぞれが固有のプロトコルをサポートすることができる少なくとも４つの異種のネットワークトランスポート媒体がある。照明のスイッチや電気製品などの家庭用の制御装置の大半は、接続に電力線を用いることができる。データサービスは、広帯域（例えばＤＳＬやケーブルモデム）として家庭に入り、家庭内では無線（例えば、ＨｏｍｅＲＦや８０２．１１ｂ）または有線（例えば、ＨｏｍｅＰＮＡ、Ｃａｔ５、あるいは電力線）の接続性を用いてアクセス可能である。音声トラフィックは、有線（例えばＣａｔ３）または無線（例えば携帯電話）として家庭に入り、家庭内ではＣａｔ３の配線を使用して分配することができる。娯楽媒体は、衛星またはケーブルを通じて家庭内に入り、家庭内では通例は同軸ケーブルを使用して分配される。また、ＩＥＥＥ１３９４およびＤＶＩが、メディアデバイスのクラスタのためのデジタル相互接続として台頭しつつある。これらのネットワーク環境とプロトコル標準として台頭する可能性があるその他の環境をすべて相互接続して、インターネットにより外の世界に接続できるイントラネットを形成することができる。すなわち、データの格納と送信には各種の異種のソースが存在し、その結果、コンピューティングデバイスは、今後、データ処理パイプラインのあらゆる部分でコンテンツを保護する方策を必要とするようになるであろう。

「インターネット」は、コンピュータネットワーキングの分野ではよく知られているＴＣＰ／ＩＰのプロトコルスイートを利用するネットワークおよびゲートウェイの集合を一般に指す。ＴＣＰ／ＩＰは、「Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（伝送制御プロトコル／インターネットプロトコル）」の頭字語である。インターネットは、ユーザがネットワークを通じて相互に通信し、情報を共有することを可能にするネットワーキングプロトコルを実行するコンピュータによって相互接続された地理的に分散したリモートコンピュータネットワークからなるシステムと表現することができる。そのような広範囲にわたる情報共有により、インターネットなどのリモートネットワークは、開発者が基本的に制約を受けずに特化した操作またはサービスを行うためのソフトウェアアプリケーションを設計することができるオープンシステムへとこれまで一般に発展してきた。

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

通例、サーバは、インターネットなどのリモートネットワークを通じてアクセス可能なリモートコンピュータシステムである。クライアントプロセスは第１のコンピュータシステムでアクティブであり、サーバプロセスは第２のコンピュータシステムでアクティブであることができ、通信媒体を介して相互に通信し、それゆえ分散した機能を提供し、複数のクライアントがサーバの情報集約機能を利用できるようにしている。

クライアントとサーバは、プロトコル層によって提供される機能を利用して相互と通信する。例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、ワールドワイドウェブ（ＷＷＷ）と関連して使用される共通のプロトコルである。通例は、ユニバーサルリソースロケータ（ＵＲＬ）またはインターネットプロトコル（ＩＰ）アドレスなどのコンピュータネットワークアドレスを使用して、サーバまたはクライアントコンピュータを相互に識別する。ネットワークアドレスは、ユニバーサルリソースロケータアドレスと称することができる。例えば、通信は通信媒体を通じて提供することができる。具体的には、クライアントとサーバは、大容量通信のＴＣＰ／ＩＰ接続を通じて相互に結合することができる。

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

例えば、通信ネットワーク／バス１４がインターネットであるネットワーク環境では、サーバ１０は、クライアント１１０ａ、１１０ｂ、１１０ｃ、１１０ｄ、１１０ｅ等がＨＴＴＰなどの数種の周知のプロトコルのいずれかを介して通信するウェブサーバとすることができる。分散コンピューティング環境の特徴であるように、サーバ１０はクライアント１１０としても機能することができる。通信は、適切な場合には有線でも無線でもよい。クライアントデバイス１１０は、通信ネットワーク／バス１４を介して通信することもあり、しないこともあり、自身と関連する独立した通信を有することもできる。例えば、ＴＶまたはＶＣＲの場合は、その制御にネットワーク化された面があることもあり、ないこともある。各クライアントコンピュータ１１０およびサーバコンピュータ１０は、各種のアプリケーションプログラムモジュールまたはオブジェクト１３５を備え、また各種のストレージ要素またはオブジェクトへの接続またはアクセスを備えることができ、そのストレージ要素やオブジェクトにファイルを格納するか、ファイルの一部をダウンロードまたは移動することができる。このように、本発明は、コンピュータネットワーク／バス１４にアクセスし、相互作用することが可能なクライアントコンピュータ１１０ａ、１１０ｂ等と、クライアントコンピュータ１１０ａ、１１０ｂ等、ならびに他のデバイス１１１およびデータベース２０と相互作用することが可能なサーバコンピュータ１０ａ、１０ｂ等とを有するコンピュータネットワーク環境で利用することができる。

（デジタル著作権管理（ＤＲＭ）の概要）
次いで図１１を参照すると、知られているように、デジタル著作権管理（ＤＲＭ）および施行は、デジタルオーディオ、デジタルビデオ、デジタルテキスト、デジタルデータ、デジタルマルチメディアなどのデジタルコンテンツ１２をユーザに配布する場合に、そのようなコンテンツとの関連で非常に望まれている。ユーザにより受け取られると、ユーザは、パーソナルコンピュータ１５のメディアプレーヤなどの適切なレンダリングデバイスを用いてデジタルコンテンツをレンダリングすなわち「再生」する。

通例、そのようなデジタルコンテンツ１２を配布するコンテンツ所有者または開発者（以下「所有者」）は、配布されたデジタルコンテンツ１２にユーザが行える事を制限したいと望む。例えば、コンテンツ所有者は、ユーザがコンテンツ１２をコピーし、第２のユーザに再配布することを制限したいと望むか、あるいは配布したデジタルコンテンツ１２の再生を制限された回数のみ、一定の合計時間のみ、特定タイプのマシンのみ、特定タイプのメディアプレーヤのみ、特定タイプのユーザのみに許可することを望むことがある。

しかし、配布が行われてしまうと、コンテンツ所有者は、デジタルコンテンツ１２に対するコントロールを持つにしてもごくわずかしか持たない。そこで、ＤＲＭシステム１０は、任意形態のデジタルコンテンツ１２のコントロールされたレンダリングまたは再生を可能にし、この場合、そのようなコントロールは、柔軟性があり、そのデジタルコンテンツのコンテンツ所有者によって定義可能である。通例、コンテンツ１２は、パッケージ１３の形態で任意の適切な配布チャンネルによりユーザに配布される。配布されるデジタルコンテンツパッケージ１３は、対称的な暗号／解読鍵（ＫＤ）で暗号化されたデジタルコンテンツ１２（すなわち（ＫＤ（ＣＯＮＴＥＮＴ）））と、コンテンツを識別する他の情報、そのコンテンツのライセンスの取得法などを含むことができる。

信頼に基づくＤＲＭシステム１０では、デジタルコンテンツ１２の所有者は、デジタルコンテンツ１２をユーザのコンピューティングデバイス１５でレンダリングすることを許可する前に満たさなければならないライセンス規則を指定することができる。このライセンス規則は、上述の時間に関する要件を含むことができ、ユーザ／ユーザのコンピューティングデバイス１５（以下、状況により別段必要がない限りこれらの用語は同義で用いる）がコンテンツ所有者またはその代理人から得なければならないデジタルライセンスまたは使用文書（以下「ライセンス」）内に具体化することができる。このライセンス１６は、ユーザのコンピューティングデバイスで解読できる鍵に従って恐らく暗号化されたデジタルコンテンツを解読するための解読鍵（ＫＤ）も含む。

デジタルコンテンツ１２のコンテンツ所有者は、コンテンツ所有者がライセンス１６中に指定した規則および要件をユーザのコンピューティングデバイス１５が守るであろうこと、すなわち、ライセンス１６中のその規則および要件を満たさない限りデジタルコンテンツ１２がレンダリングされないであろうということを信頼しなければならない。そのため、デジタルコンテンツ１２と関連付けられ、ユーザが入手したライセンス１６に具体化されたライセンス規則による以外は、デジタルコンテンツ１２をレンダリングしないであろうという信頼のおけるコンポーネントまたは機構１８を、ユーザのコンピューティングデバイス１５が備えることが好ましい。

信頼のおけるコンポーネント１８は、通例ライセンスエバリュエータ２４を有し、これは、例えば、ライセンス１６が有効であるかどうかを判定し、有効なライセンス１６中のライセンス規則および要件を点検し、点検したライセンス規則および要件に基づいて、要求元のユーザが、要求したデジタルコンテンツ１２を求められた様態でレンダリングする権利を有するかどうかを判定する。理解されるように、ライセンスエバリュエータ２４は、ＤＲＭシステム１０で信頼を受けて、ライセンス１６の規則および要件に従ってデジタルコンテンツ１２の所有者の要望を実行し、どのような不正な目的あるいは別の目的でもユーザがこのような信頼のおける要素を容易に変更することができてはならない。

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

この規則および要件は、任意の適切な言語および構文に従ってライセンス１６中に指定することができる。例えば、言語により、満たされなければならない属性および値（ＤＡＴＥはＸより大きくなければならないなど）を単に指定してもよいし、指定されるスクリプトに従って機能の実行（例えば、ＤＡＴＥがＸより大きい場合は、次に．．．をする等）を要求してもよい。

ライセンスエバリュエータ２４により、ライセンス１６が有効であり、ユーザがその中の規則および要件を満たすと判定されると、それでデジタルコンテンツ１２をレンダリングすることができる。詳細には、コンテンツ１２をレンダリングするには、ライセンス１２から解読鍵（ＫＤ）を取得し、コンテンツパッケージ１３の（ＫＤ（ＣＯＮＴＥＮＴ））に適用して実際のコンテンツ１２を得、そしてそのコンテンツ１２が実際にレンダリングされる。

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

本発明の一実施形態では、特に３つのエンティティを用いてセキュアなデジタルコンテンツをパブリッシュすることができる：それは、クライアント３００で実行され、パブリッシュするコンテンツを作成するコンテンツ作成アプリケーション３０２、同じくクライアントデバイス３００に常駐するデジタル著作権管理（ＤＲＭ）アプリケーションプログラムインタフェース（ＡＰＩ）３０６、および通信ネットワーク３３０を通じてクライアント３００に通信可能に結合されたＤＲＭサーバ３２０である。本発明の一実施形態では、通信ネットワーク３３０はインターネットを含むが、通信ネットワーク３３０は、例えば私設のイントラネットなど任意のローカルまたはワイドエリアネットワークでもよいことを理解されたい。

コンテンツ作成アプリケーション３０２は、デジタルコンテンツを生成する任意のアプリケーションでよい。例えば、アプリケーション３０２は、ワードプロセッサや、デジタル形式のテキストファイル、デジタル形式の音楽、ビデオ、あるいは他の同様コンテンツを生成する他のパブリッシャとすることができる。コンテンツには、例えばライブイベントまたは記録されたイベントのストリーミングされるオーディオ／ビデオなどのストリーミングコンテンツも含まれる。本発明によれば、コンテンツ作成アプリケーションはユーザを促して、ユーザが提供する鍵を使用してコンテンツを暗号化する。アプリケーション３０２は、その鍵を使用してデジタルコンテンツを暗号化することにより、暗号化されたデジタルコンテンツファイル３０４を形成する。このクライアントアプリケーションはまた、ユーザを促して、デジタルコンテンツファイル３０４の権利データを提供する。この権利データには、そのデジタルコンテンツに権利を有する各エンティティのそれぞれのアイデンティティが含まれる。

このエンティティは、例えば個人、あるクラスの個人、あるいはデバイスとすることができる。そのようなエンティティごとに、権利データは、そのエンティティがコンテンツに有する権利のリスト、およびその権利のいずれかあるいはすべてに課されうる任意の条件も含む。この権利には、デジタルコンテンツを読み出す、編集する、コピーする、印刷する等の権利が含まれる。さらに、権利は包含的であっても排他的であってもよい。包含的な権利は、指定されたユーザがコンテンツに対して指定された権利（例えばユーザがデジタルコンテンツを編集できるなど）を有することを指す。排他的な権利とは、指定されたユーザがコンテンツに対して指定された権利以外のすべての権利（例えば、ユーザがコピー以外はデジタルコンテンツにどのような操作を行ってもよいなど）を有することを指す。

本発明の一実施形態によれば、クライアントＡＰＩ３０６は、暗号化されたデジタルコンテンツと権利データをＤＲＭサーバ３２０に渡すことができる。ＤＲＭサーバ３２０は、下記で詳細に説明するプロセスを用いて、ユーザが割り当てた権利を施行できるかどうかを判定し、施行できる場合は、ＤＲＭサーバ３２０は権利データに署名して署名済み権利ラベル（ＳＲＬ）３０８を形成する。ただし、一般には、信頼のおけるエンティティであれば、好ましくはＤＲＭサーバ３２０によって信頼のおける鍵を用いて、権利データに署名することができる。例えば、クライアントは、ＤＲＭサーバ３２０から提供される鍵を用いて権利データに署名することができる。

権利ラベル３０８は、権利記述を表すデータ、暗号化されたコンテンツ鍵、および権利記述と暗号化されたコンテンツ鍵に対するデジタル署名を含むことができる。ＤＲＭサーバが権利ラベルに署名する場合は、署名済み権利ラベル３０８をクライアントＡＰＩ３０６を通じてクライアントに戻し、ＡＰＩ３０６は、署名済み権利ラベル３０８をクライアントデバイス３００上に格納する。次いで、コンテンツ作成アプリケーション３０２は、署名済み権利ラベル３０８を暗号化されたデジタルコンテンツファイル３０４と関連付ける。例えば、ＳＲＬ３０８を暗号化されたデジタルコンテンツファイルと連結して、権利管理されたコンテンツファイル３１０を形成することができる。

しかし、一般には、権利データをデジタルコンテンツと組み合わせる必要はない。例えば、権利データを既知の場所に格納し、格納された権利データへの参照を暗号化されたデジタルコンテンツと組み合わせてもよい。この参照は、権利データが格納された場所（例えば権利データを保持するデータストア）を示す識別子、およびその特定の格納場所にあるその特定の権利データに対応する（例えば当該特定権利データの入っているファイルを識別する）識別子を含むことができる。そして、権利管理されたコンテンツ３１０を任意の場所および対象に配信することができ、そのコンテンツを消費する権利を有するエンティティだけが、そのエンティティに割り当てられた権利に従ってのみ、そのコンテンツを消費することができる。

図４は、権利管理されたデジタルコンテンツをパブリッシュするための本発明による例示的方法４００の流れ図であり、ここではＤＲＭサーバが権利ラベルに署名する。ただし、この実施形態は例示的なものに過ぎず、権利ラベルは一般には信頼のおける任意のエンティティによって署名されうることを理解されたい。一般に、デジタルコンテンツをパブリッシュするための本発明による方法は、次を含むことができる。すなわち、コンテンツ鍵（ＣＫ）を用いてデジタルコンテンツを暗号化すること、デジタルコンテンツに関連付けられた権利記述を生成すること、ＤＲＭサーバの公開鍵（ＰＵ−ＤＲＭ）に従ってコンテンツ鍵（ＣＫ）を暗号化して（ＰＵ−ＤＲＭ（ＣＫ））を得ること、および権利記述と（ＰＵ−ＤＲＭ（ＣＫ））の組合せに対して、（ＰＵ−ＤＲＭ）に対応する秘密鍵（ＰＲ−ＤＲＭ）に基づくデジタル署名を生成することである。

ステップ４０２で、アプリケーション３０２は、デジタルコンテンツを暗号化するのに使用するコンテンツ鍵（ＣＫ）を生成する。このコンテンツ鍵（ＣＫ）は、対称鍵であることが好ましいが、一般にはどのような鍵を使用してもデジタルコンテンツを暗号化することができる。対称鍵アルゴリズムは、時に「秘密鍵」アルゴリズムとも呼ばれ、メッセージの解読にそのメッセージを暗号化するのと同じ鍵を用いる。その理由から、（ＣＫ）を秘密にすることが好ましい。送信者と受信者での（ＣＫ）の共有は、その（ＣＫ）が不正に傍受されるのを防ぐために非常に慎重に行わなければならない。（ＣＫ）を暗号化側と解読側で共有するので、（ＣＫ）は、暗号化したメッセージを送信する前に通信することが好ましい。

当技術分野ではいくつかの対称鍵生成アルゴリズムが知られている。一実施形態では、ＤＥＳ（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）を用いるが、任意の対称鍵アルゴリズムを使用できることを理解されたい。そのような対称鍵アルゴリズムの例には、これらに限定されないが、ＡＥＳ、Ｔｒｉｐｌｅ−ＤＥＳ、ＩＤＥＡ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ａｒｇｏｒｉｔｈｍ）、Ｃａｓｔ、Ｃａｓｔ−１２８、ＲＣ４、ＲＣ５、およびＳｋｉｐＪａｃｋがある。

ステップ４０４で、アプリケーション３０２は、対称コンテンツ鍵（ＣＫ）でデジタルコンテンツを暗号化して暗号化デジタルコンテンツ３０４を形成するが、これを（ＣＫ（ＣＯＮＴＥＮＴ））という表記を用いて表すことができる。アプリケーション３０２を使用する作成者は、デジタルコンテンツに関連付けられた権利データを生成することもできる。この権利データは、コンテンツを消費する資格を与えることになるエンティティのリスト、各エンティティがそのコンテンツに関して所有する特定の権利、ならびにそれらの権利に課されることのある任意の条件を含むことができる。このような権利には、例えば、コンテンツの閲覧、コンテンツの印刷などを含むことができる。アプリケーション３０２は、権利データをＡＰＩ３０６に提供する。ＸＭＬ／ＸｒＭＬフォーマットの権利データの一例を付録１として本明細書に添付する。

ステップ４０６で、ＡＰＩ３０６は、コンテンツ鍵（ＣＫ）の暗号化に使用する第２の暗号鍵（ＤＥＳ１）を生成する。（ＤＥＳ１）も対称鍵であることが好ましい。ステップ４０８で、ＡＰＩ３０６は、（ＤＥＳ１）で（ＣＫ）を暗号化して（ＤＥＳ１（ＣＫ））を得る。ステップ４１０で、ＡＰＩ３０６は（ＣＫ）を破棄し、その結果（ＣＫ）は（ＤＥＳ１（ＣＫ））を解読することでしか得ることができなくなる。（ＣＫ（ＣＯＮＴＥＮＴ））が中央のＤＲＭサーバ３２０に対して保護され、そのコンテンツについてのすべての「ライセンス要求」が権利データに従って中央で行われるように、ＡＰＩ３０６はステップ４１２で、提供されたＤＲＭサーバ３２０に連絡を取り、その公開鍵（ＰＵ−ＤＲＭ）を取り出す。ステップ４１４で、ＡＰＩ３０６は、（ＰＵ−ＤＲＭ）で（ＤＥＳ１）を暗号化して（ＰＵ−ＤＲＭ（ＤＥＳ１））を得る。このように、（ＣＫ）は（ＰＵ−ＤＲＭ）に対して保護され、ＤＲＭサーバ３２０が（ＣＫ（ＣＯＮＴＥＮＴ））を解読するのに必要とされる（ＣＫ）へのアクセスを得られるであろう唯一のエンティティであることが裏付けられる。ステップ４１６で、ＡＰＩ３０６は、（ＤＥＳ１）で権利データ（許可されたエンティティのリストと、リストの許可された各エンティティと関連付けられたそれぞれの権利および条件）を暗号化して（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を得る。

代替の実施形態では、（ＣＫ）を使用して権利データを直接暗号化して（ＣＫ（ｒｉｇｈｔｓｄａｔａ））を得、（ＰＵ−ＤＲＭ）を使用して（ＣＫ）を直接暗号化して（ＰＵ−ＤＲＭ（ＣＫ））を得、それにより（ＤＥＳ１）を全く使用せずに済ませることができる。しかし、（ＤＥＳ１）を用いて権利データと（ＣＫ）を暗号化することで、そのような（ＤＥＳ１）を、ＤＲＭサーバに適合性（ａｍｅｎａｂｌｅ）のある任意の特定のアルゴリズムに準拠させることができるようになり、一方、（ＣＫ）は、ＤＲＭサーバから独立したエンティティによって指定することができ、ＤＲＭサーバに適合性のないものとすることができる。

ステップ４１８で、コンテンツ作成アプリケーション３０２は、（ＰＵ−ＤＲＭ（ＤＥＳ１））および（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を署名のために権利ラベルとしてＤＲＭサーバ３２０に提出することができる。あるいは、クライアント自身が権利データに署名してもよい。権利データを署名のためにサーバに提出する場合は、ステップ４２０で、ＤＲＭサーバ３２０が権利データにアクセスし、提出された権利ラベル中の権利と条件を施行できることを検証する。権利データを施行できることを検証するために、ＤＲＭサーバ３２０は、（ＰＲ−ＤＲＭ）を（ＰＵ−ＤＲＭ（ＤＥＳ１））に適用して（ＤＥＳ１）を得、（ＤＥＳ１）を（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））に適用して平文の権利データを得る。次いでサーバ３２０は、任意のポリシー確認を行って、権利データで指定されるユーザ、権利、および条件がサーバ３２０によって施行されるポリシーの範囲内にあることを検証することができる。サーバ３２０は、（ＰＵ−ＤＲＭ（ＤＥＳ１））および（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を含む最初に提出された権利ラベルに署名して、署名済み権利ラベル（ＳＲＬ）３０８を得る。この場合、この署名は、ＤＲＭサーバ３２０の秘密鍵（ＰＲ−ＤＲＭ）に基づき、ＳＲＬ３０８をＡＰＩ３０６に返し、ＡＰＩ３０６は、返されたＳＲＬ３０８をクライアントアプリケーション３０２に提示する。

ＳＲＬ３０８は、デジタル的に署名された文書であり、そのため改ざんに対する耐性を持つ。また、ＳＲＬ３０８は、コンテンツの暗号化に使用する実際の鍵のタイプとアルゴリズムに依存しないが、それが保護するコンテンツと１対１の強い関係を保持する。次いで図４Ａを参照すると、本発明の一実施形態では、ＳＲＬ３０８は、恐らくはコンテンツのＩＤを含むＳＲＬ３０８の基礎となるコンテンツについての情報、（ＰＵ−ＤＲＭ（ＤＥＳ１））とネットワーク上でＤＲＭサーバを見つけるためのＵＲＬのような参照情報、そしてそのＵＲＬが機能しなかった場合の予備情報を含むＳＲＬ３０８に署名するＤＲＭサーバについての情報、（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））、（ＤＥＳ１（ＣＫ））、およびＳ（ＰＲ−ＤＲＭ）などのＳＲＬ３０８自体を記述する情報など、を含む。ＳＲＬ３０８のＸＭＬ／ＸｒＭＬのサンプルを付録２として本明細書に添付する。

信頼のおけるエンティティが権利データに署名して署名済み権利ラベル３０８を作成するようにすることにより、ＤＲＭサーバは、権利ラベル３０８の権利データに記載されたとおりパブリッシャによって設定された条件に従ってコンテンツのライセンスを発行することになることを表明（ａｓｓｅｒｔ）する。理解されるように、特にライセンスがコンテンツ鍵（ＣＫ）を含む限りは、ユーザは、コンテンツをレンダリングするためにライセンスを得ることを要求される。暗号化されたコンテンツのライセンスを得たいとき、ユーザは、そのコンテンツのＳＲＬ３０８を含むライセンス要求と、ＤＲＭサーバ３２０または他のライセンス発行エンティティに対する自身のクレデンシャル（ｃｒｅｄｅｎｔｉａｌ）を証明する証明書とを提示することができる。ライセンス発行エンティティは、（ＰＵ−ＤＲＭ（ＤＥＳ１））および（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を解読して権利データを生成し、作成者によってそのライセンス要求エンティティに付与される権利を（ある場合には）すべてリストし、それらの特定の権利だけを用いてライセンスを構築する。

好ましくは、アプリケーション３０２がＳＲＬ３０８を受け取ると、そのアプリケーション３０８は、署名済み権利ラベル３０８を対応する（ＣＫ（ＣＯＮＴＥＮＴ））３０４と連結して、権利管理されたデジタルコンテンツを形成する。あるいは、暗号化されたデジタルコンテンツが提供される場所への参照とともに、権利データを既知の場所に格納することができる。このように、ＤＲＭに対応可能なレンダリングアプリケーションは、そのアプリケーションがレンダリングしようとするコンテンツを介して、署名済み権利ラベル３０８を発見することができる。この発見がトリガとなって、レンダリングアプリケーションがＤＲＭライセンシングサーバ３２０に対するライセンス要求を開始する。パブリッシュアプリケーション３０２は、例えばＤＲＭライセンシングサーバ３２０へのＵＲＬを格納することができ、あるいは、ＤＲＭライセンシングサーバ３２０が権利ラベルにデジタル署名する前に自身のＵＲＬをメタデータとして権利ラベル中に埋め込み、それによりレンダリングアプリケーションによってコールされたＤＲＭクライアントのＡＰＩ３０６が、正しいＤＲＭライセンシングサーバ３２０を識別することができる。グローバル一意識別子（ＧＵＩＤ）などの一意の識別子を、例えば、権利ラベルに署名する前に、権利ラベルに入れることが好ましい。

本発明の一実施形態では、コンテンツ作成アプリケーション３０２またはレンダリングアプリケーションとＤＲＭサーバ３２０との間の通信にＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）を使用することができる。また、ＡＰＩ３０６などのＡＰＩライブラリを提供し、アプリケーション３０２などのアプリケーションがクライアント側のＤＲＭプロトコルを実装する必要なく、単にローカルのＡＰＩコールを行うだけで済むようにすることができる。ＸＭＬ言語の一種であるＸｒＭＬを使用して、デジタルコンテンツの権利記述、ライセンス、および権利ラベルを記述することが好ましいが、権利記述および他のデータには任意の適当なフォーマットを使用できることを理解されたい。

（パブリッシュされたコンテンツのライセンス取得）
図５は、本発明による権利管理されたデジタルコンテンツをライセンスするためのシステムおよび方法の一実施形態の機能ブロック図である。本明細書で使用する「ライセンスする」という用語は、アプリケーションまたはサービスが、ライセンス中に指名されたエンティティがライセンスに指定された条件に従ってそのコンテンツを消費することができるようにするライセンスを要求し、受け取るために従うプロセスを指す。このライセンシングプロセスへの入力は、ライセンスが要求されているコンテンツと関連付けられた署名済み権利ラベル（ＳＲＬ）３０８と、ライセンスが要求されているエンティティの公開鍵の証明書とを含むことができる。ライセンスを要求しているエンティティは、必ずしもそのライセンスが要求されている対象のエンティティでなくともよいことに留意されたい。通例、ライセンスは、ＳＲＬ３０８からの権利記述、暗号化されたコンテンツを解読できる暗号化された鍵、および権利記述と暗号化された鍵に対するデジタル署名を含む。デジタル署名は、指定されたエンティティと権利が正当なものであることを表明（ａｓｓｅｒｔ）する。

アプリケーション３０２が権利管理されたコンテンツ３１０を消費する１つの方法は、クライアントＡＰＩ３０６が、権利管理されたコンテンツ３１０の署名済み権利ラベル３０８を通信ネットワーク３３０経由でＤＲＭサーバ３２０に転送することである。ＤＲＭサーバ３２０の場所は、例えばＳＲＬ３０８の参照情報で見つけることができる。そのような実施形態では、ＤＲＭライセンシングサーバ３２０は、下記で詳細に述べるプロセスを通じて、権利ラベル中の権利記述を使用してライセンスの発行が可能かどうかを判定し、可能な場合は、権利記述を導き出してライセンスに含める。

上述のように、権利ラベル３０８は、ＤＲＭサーバ３２０の公開鍵（ＰＵ−ＤＲＭ）により暗号化されたコンテンツ鍵（ＣＫ）（すなわち（ＰＵ−ＤＲＭ（ＣＫ）））を収容する。ライセンスを発行するプロセスで、ＤＲＭサーバ３２０は、この値をセキュアに解読して（ＣＫ）を得る。そして、ライセンス要求中で渡される公開鍵の証明書中の公開鍵（ＰＵ−ＥＮＴＩＴＹ）を使用して（ＣＫ）を再度暗号化する（すなわち（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））となる）。新たに暗号化された（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））が、サーバ３２０がライセンスに入れるものである。このように、（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））から（ＣＫ）を復元できるのは関連付けられた秘密鍵（ＰＲ−ＥＮＴＩＴＹ）の保有者だけなので、（ＣＫ）を露出する危険なくライセンスを呼び出し元に戻すことができる。クライアントＡＰＩ３０６は、次いで、（ＣＫ）を使用して暗号化されたコンテンツを解読して、解読したデジタルコンテンツ３１２を形成する。それで、クライアントアプリケーション３０２は、ライセンス中に提供される権利に従って解読されたデジタルコンテンツ３１２を使用することができる。

あるいはまた、例えばパブリッシングクライアントなどのクライアントが、コンテンツを消費するために自身のライセンスを発行することもできる。そのような実施形態では、適当な状況下でデジタルコンテンツを解読するのに必要な鍵をクライアントに提供するセキュアなプロセスをクライアントコンピュータで実行する。

図６Ａおよび６Ｂに、権利管理されたデジタルコンテンツをライセンスするための本発明による方法の一実施形態の流れ図を示す。本発明によれば、要求元のエンティティは、１つまたは複数の潜在的なライセンシ（ｌｉｃｅｎｓｅｅ）の代わりにライセンスリクエストを提出することができる。要求元のエンティティは、潜在的ライセンシの１つであっても、そうでなくともよい。潜在的ライセンシは、個人、グループ、デバイス、あるいはコンテンツを任意の様態で消費することができる他の任意のエンティティである。ＤＲＭサーバがライセンス要求を処理する一実施形態を参照してこの方法を次に説明するが、ライセンス要求の処理はクライアントで実行してもよく、またクライアントが直接発行したライセンスであってもよいことを理解されたい。

ステップ６０２で、例えばＤＲＭサーバなどのライセンス発行エンティティが、ライセンス要求を受け取る。ライセンス要求は、１つまたは複数の要求したライセンシそれぞれの公開鍵証明書またはアイデンティティを含むことが好ましい。

ステップ６０４で、要求元のエンティティ（ライセンス要求を行っているエンティティ）を認証する。本発明の一実施形態によれば、ライセンス発行エンティティは、プロトコル認証（例えばチャレンジ−レスポンス認証）を使用して要求元のエンティティのアイデンティティを判定するように構成することができ、または要求元のエンティティの認証を要求しない（「匿名認証を許可する」とも言う）ように構成することもできる。認証が要求される場合、任意のタイプの認証方式を使用することができる（例えば、上記のチャレンジ−レスポンス方式、ＭＩＣＲＯＳＯＦＴ．ＮＥＴ、ＰＡＳＳＰＯＲＴ、ＷＩＮＤＯＷＳ（登録商標）認証、ｘ５０９などのユーザＩＤとパスワードによる方式など）。匿名認証を許可し、同時に統合情報システムがサポートする任意のプロトコル認証方式もサポートすることが好ましい。認証ステップの結果、例えば「匿名の」アイデンティティなどのアイデンティティ（匿名認証の場合）か、または個人アカウントのアイデンティティが得られることになる。何らかの理由でライセンス要求を認証できない場合は、エラーが戻され、ライセンスは付与されない。

ステップ６０６で、認証されたエンティティを認可する。すなわち、ステップ６０４で認証されたエンティティが（自身のため、または別のエンティティの代わりに）ライセンスを要求するのを許可するかどうかを判定する。ライセンス発行エンティティは、ライセンスを要求するのを許可する（または許可しない）エンティティのリストを格納していることが好ましい。一実施形態では、このアイデンティティリスト中のアイデンティティは、ライセンスが要求されている対象のエンティティのアイデンティティではなく、要求を行っているエンティティのアイデンティティであるが、どちらであってもよい。例えば、個人アカウントのアイデンティティにはライセンス要求を直接行うことを許可せず、信頼のおけるサーバプロセスがそのようなエンティティの代わりにライセンス要求を行うようにすることができる。

本発明によれば、ライセンス要求は、各潜在的ライセンシの公開鍵証明書またはアイデンティティを含むことができる。ライセンスが１つのライセンシだけのために要求される場合は、１つの証明書またはアイデンティティのみが指定される。複数のライセンシのためにライセンスが要求される場合は、潜在的ライセンシごとに証明書またはアイデンティティを指定することができる。

ライセンス発行エンティティは、有効なライセンシそれぞれの公開鍵証明書を有することが好ましい。しかし、アプリケーション３０２が所定のユーザにライセンスを生成したいが、そのユーザの公開鍵証明書にアクセスできない場合がある。そのような状況では、アプリケーション３０２は、ライセンス要求の中でユーザのアイデンティティを指定することができ、結果として、ライセンス発行エンティティが、ディレクトリサービスで検索し、該当するユーザの公開鍵証明書を戻す登録証明書プラグインモジュールを呼び出すことができる。

ステップ６０８で、発行エンティティがライセンス要求に公開鍵証明書が含まれていないと判定した場合、発行エンティティは、指定されたアイデンティティを使用して該当する公開鍵証明書を求めてディレクトリサービスまたはデータベースの検索を行う。ステップ６１０でディレクトリに証明書があると発行エンティティが判定した場合は、ステップ６１２で証明書を取り出す。一実施形態では、証明書プラグインを使用してディレクトリアクセスプロトコルによりディレクトリサービスから公開鍵証明書を取り出す。所定の潜在ライセンシの証明書が要求中にもディレクトリにも見つけることができない場合、ライセンスサーバは、その潜在的ライセンシにはライセンスを生成せず、ステップ６１４で要求元エンティティにエラーを返す。

ライセンス発行エンティティが少なくとも１つの潜在的ライセンシの公開鍵証明書を有すると想定すると、ステップ６１６で発行エンティティはそのライセンシの証明書の信頼性を検証する。発行エンティティは、信頼のおける証明書発行者の証明書のセットを備えるように構成し、ライセンシの証明書の発行者が信頼のおける発行者のリストにあるかどうかを判定することが好ましい。ステップ６１６で発行エンティティがそのライセンシ証明書の発行者が信頼のおける発行者リストにないと判定した場合は、そのライセンシの要求は失敗となり、ステップ６１４でエラーを生成する。このように、証明書が信頼のおける発行者によって発行されていないいかなる潜在的ライセンシも、ライセンスを受け取らないであろう。

また、発行エンティティは、信頼のおける発行者の証明書から個々のライセンシの公開鍵証明書に至る証明書チェーンに含まれるすべてのエンティティに対してデジタル署名の検証を行うことが好ましい。チェーン中でデジタル署名を検証するプロセスは、周知のアルゴリズムである。所定の潜在的ライセンシの公開鍵証明書が有効と認められない場合、またはチェーン中の証明書の１つが有効と認められない場合は、その潜在ライセンシは信頼されず、したがってその潜在ライセンシにはライセンスが発行されない。そうでない場合は、ステップ６１８でライセンスを発行することができる。このプロセスは、ライセンスが要求されたすべてのエンティティを処理するまでステップ６２０で繰り返す。

図６Ｂに示すように、ライセンス発行エンティティは、ライセンス要求で受け取った署名済み権利ラベル３０８の検証に進む。一実施形態では、発行エンティティは、権利ラベルのプラグインと、発行エンティティによって署名されたすべての権利ラベルのマスターコピーをサーバ上に格納するバックエンドデータベースとを使用することができる。権利ラベルは、パブリッシュ時にその中に配置されたＧＵＩＤによって識別される。ライセンス時（ステップ６２２）に、発行エンティティは、ライセンス要求中の権利ラベルの入力を解析（ｐａｒｓｅ）し、権利ラベルのＧＵＩＤを取り出す。次いでそのＧＵＩＤを権利ラベルプラグインに渡し、プラグインは、データベースに対してクエリを発行してマスター権利ラベルのコピーを取り出す。マスター権利ラベルは、ライセンス要求で送信された権利ラベルのコピーよりも新しい可能性があり、これが、以下のステップの要求中で使用される権利ラベルとなる。ＧＵＩＤに基づいてデータベースに権利ラベルが見つからない場合、発行エンティティはステップ６２４でそのポリシーを確認して、要求中の権利ラベルに基づいてライセンスを発行することがまだ許可されるかどうかを判定する。ポリシーが許可しない場合、ライセンス要求はステップ６２６で失敗し、ステップ６２８でＡＰＩ３０６にエラーを戻すことになる。

ステップ６３０で、ライセンス発行エンティティは権利ラベル３０８を検証する。権利ラベルのデジタル署名を検証し、ライセンス発行エンティティがその権利ラベルの発行者（それに署名したエンティティ）でない場合、ライセンス発行エンティティは、権利ラベルの発行者が別の信頼のおけるエンティティ（例えば、そのライセンス発行エンティティが主要な資料を共有することを可能にしているエンティティ）であるかどうかを判定する。権利ラベルが有効と認められない場合、または信頼のおけるエンティティによって発行されていない場合、ライセンス要求はステップ６２６で失敗し、ステップ６２８でＡＰＩ３０６にエラーを戻すことになる。

すべての検証を行うと、ライセンス発行エンティティは、権利ラベル３０８を承認されたライセンシそれぞれのライセンスに変換する。ステップ６３２で、ライセンス発行エンティティは、各ライセンシに発行することになるライセンスのそれぞれの権利記述を生成する。発行エンティティは、ライセンシごとに、権利ラベル中の権利記述に指定されたアイデンティティに照らして、そのライセンシの公開鍵証明書に指定されたアイデンティティを評価する。権利記述は、ライセンス中のあらゆる権利または権利のセットに、その権利または権利のセットを実行することのできるアイデンティティのセットを割り当てる。このライセンシのアイデンティティが関連付けられたあらゆる権利または権利のセットについて、その権利または権利のセットをライセンスの新たなデータ構造中にコピーする。この結果得られるデータ構造が、その特定のライセンシのライセンスにおける権利記述となる。このプロセスの一部として、ライセンス発行エンティティは、権利ラベルの権利記述にある任意の権利または権利のセットと関連付けられる可能性のある任意の前提条件を評価する。例えば、権利には、ライセンス発行エンティティがある指定の時間の後にライセンスを発行することを制限する、その権利と関連付けられた時間の前提条件がある場合がある。この場合、発行エンティティは、現在の時間を確認する必要があり、前提条件で指定された時間を過ぎている場合は、この発行エンティティはそのライセンシのアイデンティティがその権利と関連付けられていたとしてもそのライセンシにその権利を発行することはできないであろう。

ステップ６３６で、発行エンティティは、権利ラベル３０８から（ＰＵ−ＤＲＭ（ＤＥＳ１））および（ＤＥＳ１（ＣＫ））を取り出し、（ＰＲ−ＤＲＭ）を適用して（ＣＫ）を得る。発行エンティティは、次いでライセンシの公開鍵証明書の（ＰＵ−ＥＮＴＩＴＹ）を使用して（ＣＫ）を再度暗号化して（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））を得る。ステップ６３８で、発行エンティティは、生成した権利記述を（ＰＵ−ＥＮＴＩＴＹ（ＣＫ））と連結し、その結果得られるデータ構造に（ＰＲ−ＤＲＭ）を用いてデジタル的に署名する。この署名したデータ構造が、その特定のライセンシのライセンスとなる。

ステップ６４０で、その特定の要求に対して生成すべきライセンスがそれ以上ないと判断したとき、発行エンティティは、ゼロまたは１つ以上のライセンスを発行したことになる。生成されたライセンスは、ステップ６４２で、それらのライセンスと関連付けられた証明書チェーン（例えば、サーバ自身の公開鍵証明書と、証明書を発行した証明書など）とともに要求元エンティティに返される。

本発明によるシステムの一実施形態では、複数のライセンサ鍵を使用することができる。そのような実施形態では、暗号化された状態で権利ラベル３０８を通じてライセンス中に移動するコンテンツ鍵（ＣＫ）は、実際には任意のデータとすることができる。特に有用な変形形態の１つは、権利記述中の異なる権利または異なる権利者（ｐｒｉｎｃｉｐａｌ）とそれぞれ関連付けられた、複数の暗号化された個別のコンテンツ鍵（ＣＫ）を使用することである。例えば、アルバムの歌曲のデジタルバージョンをすべて異なる鍵（ＣＫ）で暗号化することができる。それらの鍵（ＣＫ）を同じ権利ラベルに含めるが、ある権利者はそれらの歌曲の１つを再生する権利を有し（例えば、自分のライセンス中にその１つの鍵を得る権利を有するだけの場合）、他方、第２の権利者は、すべての歌曲を再生する権利を持つことができる（自分のライセンス中にすべての鍵を得る権利を持つ場合）。

本発明によるシステムでは、パブリッシングアプリケーション／ユーザが、権利ラベル３０８中にライセンシのグループまたはクラスを指定できるようにすることが好ましい。そのような実施形態では、ライセンス発行エンティティは、権利ラベル中に指定されたグループ／クラスを評価して、現在のライセンシのアイデンティティが、そのグループ／クラスのメンバであるかどうかを判定することになる。指定されたグループ／クラスのメンバであることが分かると、発行エンティティは、そのグループ／クラスと関連付けられた権利または権利のセットを、ライセンスに使用する権利記述のデータ構造に加えることができるであろう。

本発明の一実施形態では、ＤＲＭサーバ中のパブリッシュおよびライセンスのプロトコルインタフェースが、呼び出し元アプリケーションまたはユーザの認証および認可をサポートし、管理者がＤＲＭサーバの管理コンソールによりライセンシングおよびパブリッシング両方のインタフェースへのアクセス制御リストを生成することができるようにする。これにより、サーバの顧客は、どのユーザ／アプリケーションがパブリッシュもしくはライセンス、またはその両方が許可されるかについてのポリシーを適用することができるようになる。

（署名済み権利ラベル３０８の変更または再パブリッシュ）
本発明の一実施形態では、コンテンツのユーザがそのようにするための十分な許可を与えられた場合には、ＳＲＬ３０８を「再パブリッシュ」することができる。すなわち、許可された場合、ユーザは、ＳＲＬ３０８中の権利データを変更することができる。注意すべきは、このような権利データを変更する許可は慎重かつ控えめに付与されなければならない。というのは、権利データを変更する許可を持つユーザは、基本的に、関連するコンテンツに関して広範な権利を自身に付与することができるからである。考えうることとして、そのようなユーザは、コンテンツを公開し、世界に転送する権利を自身に付与しかねない。

ここで、変更の許可は、特定のユーザまたは特定のクラスのユーザが権利データおよび権利ラベル３０８を実際に変更または「再パブリッシュ」することができる旨の指示を、ＳＲＬ３０８の権利データ内に含めることによって示す。ＤＲＭサーバ３２０は、ライセンスの要求と関連してそのような許可を含むＳＲＬ３０８を受け取ると、そのユーザ向けの要求ライセンス内に、ユーザの公開鍵（ＰＵ−ＥＮＴＩＴＹ）に従って暗号化され（ＰＵ−ＥＮＴＩＴＹ（ＤＥＳ１））となる対称鍵（ＤＥＳ１）を含める。

このように、ＳＲＬ３０８内の権利データを編集するには、次いで図７に移り、ユーザはライセンスから（ＰＵ−ＥＮＴＩＴＹ（ＤＥＳ１））を取り出し（ステップ７０１）、（ＰＲ−ＥＮＴＩＴＹ）をそれに適用して（ＤＥＳ１）を得（ステップ７０３）、ＳＲＬ３０８から（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を取り出し（ステップ７０５）、そしてそれに（ＤＥＳ１）を適用して権利データを得る（ステップ７０７）。その後、ユーザは希望に応じて権利データを変更し（ステップ７０９）、変更した権利データを図４と関連して説明した様態でＤＲＭサーバ３２０に提出して、署名済み権利ラベル３０８を得る（ステップ７１１）。言うまでもなく、ここで、署名済み権利ラベル３０８は、実際には再パブリッシュされたＳＲＬ３０８であり、したがって、ＳＲＬ３０８を受け取る（ステップ７１３）と、ユーザは、関連付けられたコンテンツに連結された元のＳＲＬ３０８を除去し（ステップ７１５）、そして再パブリッシュされたＳＲＬ３０８をそのコンテンツに連結する（ステップ７１７）。

このように、理解されうるとおり、ＳＲＬ３０８を再パブリッシュすることにより、ユーザは、関連付けられたコンテンツを変更する必要なく、権利、条件、およびユーザを含むＳＲＬ３０８の権利データを更新することができるようにする。特に、再パブリッシュするのに、関連付けられたコンテンツを新しい（ＣＫ）で再暗号化する必要はない。また、再パブリッシュするのに、新しいＳＲＬを最初から生成する必要もない。というのは、元のＳＲＬ３０８には、新しいＳＲＬ３０８にコピーできる多くの項目がその中に含まれているからである。

（署名済み権利ラベル３０８の自己パブリッシュ）
本発明の一実施形態では、ＳＲＬ３０８は、要求元のユーザ自身によって署名することができる。そのため、ユーザは、関連付けられたコンテンツのＳＲＬ３０８を得るのにＤＲＭサーバ３２０に連絡を取る必要がない。結果として、自己パブリッシュは、オフラインパブリッシュとも呼ぶことができる。そのような実施形態では、ＤＲＭサーバ３２０に連絡を取って、そのような自己パブリッシュされたＳＲＬ３０８に基づくライセンスを要求することをユーザに求めることもできる。また、パブリッシュを行うエンティティが自身のライセンスを発行できるようにしてもよいことも理解されたい。

具体的には、次いで図８を参照すると、この実施形態では、ユーザはまず、公開鍵（ＰＵ−ＣＥＲＴ）と、ユーザの公開鍵（ＰＵ−ＥＮＴＩＴＹ）に従って暗号化され（ＰＵ−ＥＮＴＩＴＹ（ＰＲ−ＣＥＲＴ））となる対応する秘密鍵（ＰＲ−ＣＥＲＴ）とを含むＤＲＭ証明書８１０をＤＲＭサーバ３２０から受信することにより、自己パブリッシュするための準備（ｐｒｏｖｉｓｉｏｎ）がなされる。この証明書は、ＤＲＭサーバ３２０が検証できるようにＤＲＭサーバ３２０の秘密鍵（ＰＲ−ＤＲＭ）で署名されるべきである。これについては下記でより詳細に説明する。理解されうるように、ＤＲＭ証明書８１０が自己パブリッシュするユーザを認可する。同じく理解されうるように、鍵のペア（ＰＵ−ＣＥＲＴ、ＰＲ−ＣＥＲＴ）は、（ＰＵ−ＥＮＴＩＴＹ、ＰＲ−ＥＮＴＩＴＹ）とは別個であり、特に自己パブリッシュのために用いられる。鍵のペア（ＰＵ−ＣＥＲＴ、ＰＲ−ＣＥＲＴ）は用いずに済ましてもよく、その場合ＤＲＭ証明書８１０はユーザの公開鍵（ＰＵ−ＥＮＴＩＴＹ）だけを含み、ＤＲＭサーバ３２０が検証できるようにＤＲＭサーバ３２０の秘密鍵（ＰＲ−ＤＲＭ）で署名されることに留意されたい。

自己パブリッシュは、図４に示すパブリッシュと異なり、ＤＲＭサーバ３２０が行うステップに関して、ユーザが基本的にＤＲＭサーバ３２０の代わりとなっている。重要な点として、ユーザは、ＤＲＭ証明書８１０から得られる（ＰＲ−ＣＥＲＴ）と共に（ＰＵ−ＤＲＭ（ＤＥＳ１））および（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を含む提出された権利ラベルに署名して（すなわちＳ（ＰＲ−ＣＥＲＴ））、署名済み権利ラベル（ＳＲＬ）３０８を得る。理解されるように、ユーザは、ＤＲＭ証明書８１０から（ＰＵ−ＥＮＴＩＴＹ（ＰＲ−ＣＥＲＴ））を取得し、それに（ＰＲ−ＥＮＴＩＴＹ）を適用することにより、ＤＲＭ証明書８１０から（ＰＲ−ＣＥＲＴ）を得る。しかし、特にユーザが（ＰＵ−ＤＲＭ（ＤＥＳ１））に適用する（ＰＲ−ＤＲＭ）を持っていないので、ＤＲＭサーバ３２０が提出された権利ラベル中の権利を施行できることをユーザは検証することができないことに留意されたい。したがって、ＤＲＭサーバ３２０はそれ自身で、自己パブリッシュされたＳＲＬ３０８に基づいてライセンスが要求された時点で検証を行わなければならない。

ユーザがＳＲＬ３０８を自己パブリッシュすると、ユーザは、その自己パブリッシュしたＳＲＬ３０８と、そのＳＲＬ３０８を生成するのに使用したＤＲＭ証明書８１０をコンテンツに連結し、ＳＲＬ３０８およびＤＲＭ証明書８１０を含むそのコンテンツを別のユーザに配布する。その後、相手のユーザは、図６Ａおよび６Ｂに示すのと実質的に同じ様態でＤＲＭサーバ３２０にコンテンツのライセンスを要求し、取得する。ただし、ここで、ライセンスを要求するユーザは、コンテンツに連結された自己パブリッシュしたＳＲＬ３０８とＤＲＭ証明書８１０の両方をＤＲＭサーバ３２０に提出する。するとＤＲＭサーバ３２０は、対応する（ＰＵ−ＤＲＭ）に基づいてＤＲＭ証明書８１０のＳ（ＰＲ−ＤＲＭ）を検証し、ＤＲＭ証明書８１０から（ＰＵ−ＣＥＲＴ）を得る。ＤＲＭサーバ３２０は次いで、取得した（ＰＵ−ＣＥＲＴ）に基づいてＳＲＬ３０８中のＳ（ＰＲ−ＣＥＲＴ）を検証し、上述のように続ける。ただし、ユーザはＤＲＭサーバ３２０がＳＲＬ３０８中の権利を施行できることを検証できないので、上述した通り、ＤＲＭサーバ３２０自身がこの時点で検証を行なうべきであることに留意されたい。

（権利テンプレート）
上述のように、ユーザには、ユーザまたはユーザのクラスを定義し、定義したユーザまたはユーザクラスそれぞれに権利を定義し、そして任意の使用条件を定義することにより、権利ラベル中にほとんどあらゆる種類の権利データを作成する自由が与えられている。しかし、重要な点として、特に異なるコンテンツに対して同じユーザまたはユーザクラス、権利、および条件を繰り返し定義する場合には、複数の権利ラベルに対して繰り返し権利データを定義するのは煩瑣であり、反復的である場合がある。そのような状況は、例えば、企業またはオフィスの環境で生じる場合があり、そこではユーザが、ある特定の既定のユーザチームと共有することになる様々なコンテンツを繰り返しパブリッシュしている。そのような状況では、本発明の一実施形態では、ユーザが権利ラベルの作成と関連して繰り返し用いることができる権利テンプレートを作成し、この権利テンプレートには、事前に定義されたユーザまたはユーザクラスのセット、定義されたユーザまたはユーザクラスそれぞれについて事前に定義された権利、および事前に定義された使用条件が既に含まれている。

本発明の一実施形態では、次いで図９に移ると、権利テンプレート９００は、権利ラベルにあるであろうものと実質的に同じ権利データを有する。ただし、（ＤＥＳ１）はコンテンツがパブリッシュされるまで分からないので、権利ラベルの場合のように、（ＤＥＳ１）に従って権利データを暗号化することはできない。本発明の一実施形態では、暗号化されていない権利データを含む権利テンプレート９００は、図４のステップ４１６で権利データを（ＤＥＳ１）で暗号化して（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を生成する間に提出される。言うまでもなく、権利データは、そのように暗号化される前に、提出された権利テンプレート９００から取り出す。

権利テンプレートが構築される時点でＤＲＭサーバ３２０とその公開鍵（ＰＵ−ＤＲＭ）が分かっている場合もあれば、そうでない場合もある。さらに、分かっている場合でも、ＤＲＭサーバ３２０が複数あり、それぞれが自身の（ＰＵ−ＤＲＭ）を有している場合もあり、そうでない場合もある。それでも、権利テンプレートが構築される時にＤＲＭサーバ３２０とその公開鍵（ＰＵ−ＤＲＭ）が分かっている場合と、１つのみのＤＲＭサーバ３２０を用いるか、または権利テンプレート９００と関連して１つのみのＤＲＭサーバ３２０を用いることになる場合には、権利テンプレート９００は、その権利テンプレートから得られる権利ラベルに署名することになるＤＲＭサーバについての情報をその中に含むこともでき、この情報にはＤＲＭサーバの公開鍵（ＰＵ−ＤＲＭ）が含まれる。そのような（ＰＵ−ＤＲＭ）は、（ＤＥＳ１）を暗号化して（ＰＵ−ＤＲＭ（ＤＥＳ１））を得るものとしてＳＲＬ３０８に含まれるが、（ＤＥＳ１）はコンテンツがパブリッシュされるまで分からず、それゆえ権利テンプレート９００中の（ＰＵ−ＤＲＭ）は、権利ラベルの場合のようにそのような（ＤＥＳ１）を暗号化することができないことを再度理解されたい。本発明の一実施形態では、次いで、暗号化されていない（ＰＵ−ＤＲＭ）を含む権利テンプレート９００を、図４のステップ４１４にて（ＰＵ−ＤＲＭ）で（ＤＥＳ１）を暗号化して（ＰＵ−ＤＲＭ（ＤＥＳ１））を生成する間に提出する。言うまでもなく、（ＰＵ−ＤＲＭ）は、提出された権利テンプレート９００から使用する前に取り出す。

上述の場合と同様に、権利テンプレートに含めることができるＤＲＭサーバについての他の情報には、ネットワーク上でＤＲＭサーバを見つけるためのＵＲＬ、およびＵＲＬが機能しなかった場合の予備情報などの参照情報を含めることもできる。いずれの場合も、権利テンプレートは、数ある中でも、権利テンプレート９００自体を記述する情報を含むこともできる。権利テンプレート９００は、コンテンツおよび／または暗号鍵（ＣＫ）や（ＤＥＳ１）に関連する権利ラベルに含まれる情報など、パブリッシュされることになるコンテンツに関連する情報のためのスペースを提供することもできるが、権利テンプレートのインスタンス化が実際には権利ラベル中に転換されない場合にはそのようなスペースは必要ないことに留意されたい。

ここまで開示した権利テンプレート９００は、主としてユーザの利便を目的とするが、状況によっては、ユーザは、権利ラベルの権利データを定義するのに制約のない自由を持つべきでなく、作成できる権利ラベルの範囲またはタイプを制限するために権利テンプレート９００を使用することができることも理解されたい。例えば、特に企業やオフィスの環境の場合、ある特定のユーザはいつも特定のクラスのユーザにのみコンテンツをパブリッシュする、あるいはある特定クラスのユーザにはコンテンツをパブリッシュすべきでないことをポリシーとして事前に定義することができる。いずれの場合も、本発明の一実施形態では、そのようなポリシーは事前に定義された権利データとして１つまたは複数のテンプレート９００中に具体化し、コンテンツをパブリッシュする際に権利ラベルを作成するのにその権利テンプレートをユーザに用いるように制限することができる。注意すべきこととして、あるユーザについてのパブリッシングポリシーを指定するためにそのユーザが利用できる権利テンプレート９００または権利テンプレート９００のグループは、本発明の精神および範囲から逸脱せずに任意の特定のタイプのパブリッシングポリシーを指定することができる。

制限付きユーザなどに権利テンプレート９００を指定するには、次いで図１０に移り、管理者などが、事前に定義した権利データを定義し（ステップ１００１）、ある特定のＤＲＭサーバ３２０に関連する情報など、必要であり、適切である他の任意のデータを定義する（ステップ１００３）ことにより、権利テンプレート９００を実際に構築する。重要な点として、制限付きユーザなどによる使用のために権利テンプレートを実施するには、権利テンプレート９００が公式になされなければならない。すなわち、権利テンプレート９００は、制限付きユーザなどが用いることのできる権利テンプレートとして認識されうるようにしなくてはならない。そのため、本発明の一実施形態では、管理者などによって構築された権利テンプレートを署名のためにＤＲＭサーバ３２０に提出し、サーバ３２０による署名により権利テンプレートを公式にする（ステップ１００５）。

署名を行うＤＲＭサーバ３２０は、権利テンプレート９００中に実際にそのような情報がある場合、権利テンプレート９００中に自信の情報があるＤＲＭサーバ３２０であることに留意されたい。また、ＤＲＭサーバ３２０は、必要な確認を行った後にのみ権利テンプレート９００に署名することも、確認は一切行わずに署名することもできることに留意されたい。そして、ＤＲＭサーバ３２０からのテンプレートの署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）（Ｔは、署名がＯＲＴ９００に対するものであることを表す）は、少なくとも権利テンプレート９００中の事前に定義された権利データに基づくべきであるが、本発明の精神および範囲から逸脱せずに他の情報に基づくことも可能であることに留意されたい。下記で述べるように、署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）は権利ラベルに組み込まれ、権利ラベルと関連して検証され、したがって、署名が何に基づくものであれすべて権利ラベル中に変更されていない形態で組み込まれるべきである。

ＤＲＭサーバ３２０が権利テンプレート９００に署名し、それを管理者などに戻すと、管理者は、署名済みの今では公式になったＳ（ＰＲ−ＤＲＭ−Ｔ）を含む権利テンプレート９００を受け取り（ステップ１００７）、その公式権利テンプレート（ＯＲＴ）９００を１人または複数のユーザに使用のために転送する（ステップ１００９）。したがって、ユーザがＯＲＴ９００に基づいてコンテンツをパブリッシュするには、ユーザは、ＯＲＴ９００を取り出し（ステップ１０１１）、そしてコンテンツについての情報、適切な鍵情報、（ＤＥＳ１）によって暗号化され（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））を得るＯＲＴ９００の権利データ、およびＯＲＴ９００の任意の他の情報などの必要な情報を提供することによりＯＲＴ９００に基づいて権利ラベルを構築する（ステップ１０１３）。重要な点として、ユーザは、権利ラベルに、ＯＲＴ９００の署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）も含める。

その後、先と同様に、ユーザは署名のために権利ラベルをＤＲＭサーバ３２０に提出する（ステップ１０１５）。ただし、ここで、ＤＲＭサーバ３２０は、権利ラベル中のＳ（ＰＲ−ＤＲＭ−Ｔ）が検証されない限り、提出された権利ラベルに署名しないであろう。すなわち、ＤＲＭサーバ３２０は、提出された権利ラベルがＯＲＴ９００の署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）を含まない場合は提出された権利ラベルに署名するのを拒否することにより、ユーザに提出された権利ラベルがＯＲＴ９００に基づくことを強制する。具体的には、ＤＲＭサーバ３２０は、このようなＳ（ＰＲ−ＤＲＭ−Ｔ）とその署名が基づく情報を提出された権利ラベルから取り出し、（ＰＵ−ＤＲＭ）に基づいてその署名を検証する。提出された権利ラベル中の権利データは、（ＤＥＳ１）に従って暗号化されていることに留意されたい（すなわち（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））。したがって、図７との関連で上述したように、ＤＲＭサーバ３２０は、まず（ＤＥＳ１）を取得し、それを用いて（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ）を解読しなければ、提出された権利ラベル中の権利データに基づいて署名を検証することができない。

検証されると、先と同様に、ＤＲＭサーバ３２０は、提出された権利ラベルにＳ（ＰＲ−ＤＲＭ−Ｌ）で署名してＳＲＬ３０８を生成する（−Ｌは、その署名がＳＲＬ３０８に対するものであることを意味する）。ここで、Ｓ（ＰＲ−ＤＲＭ−Ｌ）は、Ｓ（ＰＲ−ＤＲＭ−Ｔ）に取って代わってもよいし、Ｓ（ＰＲ−ＤＲＭ−Ｔ）に追加してもよい。追加する場合、Ｓ（ＰＲ−ＤＲＭ−Ｌ）は、部分的にＳ（ＰＲ−ＤＲＭ−Ｔ）に基づくことができる。（ＰＲ−ＤＲＭ）を用いてＳ（ＰＲ−ＤＲＭ−Ｔ）およびＳ（ＰＲ−ＤＲＭ−Ｌ）の両方を生成しても、あるいは、Ｓ（ＰＲ−ＤＲＭ−Ｔ）とＳ（ＰＲ−ＤＲＭ−Ｌ）それぞれに異なる（ＰＲ−ＤＲＭ）を用いてもよいことに留意されたい。ＤＲＭサーバ３２０が権利ラベルに署名し、ＳＲＬ３０８をユーザに戻すと、ユーザはＳ（ＰＲ−ＤＲＭ−Ｌ）を含むＳＲＬ３０８を受け取り（ステップ１０１７）、次いで先と同様にそれをパブリッシュするコンテンツに連結する。

ＯＲＴ９００の署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）が少なくとも部分的にＯＲＴ９００中の事前に定義された権利データに基づく場合は、（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））のＳＲＬ３０８に見られるその権利データは、修正または変更することはできない。そうでなければ、Ｓ（ＰＲ−ＤＲＭ−Ｔ）が検証されないことになる。しかし、本発明の一実施形態では、ＯＲＴ９００中の権利データは、同じくＯＲＴ９００に含まれる規定された規則の範囲内で変えることができる。例えば、この規則は、２セットの権利データのうち１つをＳＲＬ３０８に含めるように指定することもできるし、あるいは代替１セットの中から選択を可能にすることもできる。理解されうるように、この規則は、本発明の精神および範囲から逸脱せずに、任意の適切な構文で指示される任意の特定の規則とすることができる。ここで、この規則は、権利ラベルが作成された時点でユーザの適当な規則インタープリタによって解釈される。権利データは変えることができるが、規則が同じように変わることはなく、したがってＯＲＴ９００のテンプレート署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）は少なくとも部分的に規則に基づき、権利データ自体には基づかない。結果として、ＯＲＴ９００に含まれる規則は、ＳＲＬ３０８にも含めなくてはならない。

本発明の一実施形態では、上述のように、ＯＲＴ９００中の事前に定義された権利データは、部分的には固定され、不変であり、部分的には可変で規則の影響を受ける。ここで、ＯＲＴ９００のテンプレート署名Ｓ（ＰＲ−ＤＲＭ−Ｔ）は、少なくとも部分的には規則の固定部分と、権利データの可変部分についての規則とに基づく。

理解されうるように、ユーザによって所有されるＯＲＴ９００は古くなることがある。すなわち、ＯＲＴ９００は、その中の権利データを通じて、期限切れになったポリシー、不適当になったポリシー、あるいは単にもはや適用可能でなくなったポリシーを反映することがある。例えば、ＯＲＴ９００の権利データで指定される１人または複数のユーザまたはユーザのクラスが、もはやそのポリシー環境内に存在しない、あるいはＯＲＴ９００の権利データで指定された特定のユーザまたはユーザクラスがそのポリシー環境でもはや同じ権利を持たない場合がある。このような場合、管理者が改訂したＯＲＴ９００を発行しているもののユーザがなお以前の古いバージョンのＯＲＴ９００を使用している等の可能性がある。

そのような状況では、本発明の一実施形態では、ＤＲＭサーバ３２０は、提出された権利テンプレート９００に署名してＯＲＴ９００を作成すると、ＯＲＴ９００のコピーを保持し、各ＯＲＴ９００は一意の識別印（ｉｎｄｉｃｉａ）を有し、ＯＲＴ９００に基づいて構築された権利ラベルそれぞれはそのようなＯＲＴ９００の識別印をその中に含む。したがって、図１０との関連などで提出された権利ラベルを受け取ると、ＤＲＭサーバ３２０は、権利ラベル中にＯＲＴ９００の識別印を見つけ、見つけた印に基づいてそのＯＲＴ９００の最も新しいコピーを取り出し、提出された権利ラベルから権利データを除去し、取り出したＯＲＴ９００の権利データを挿入し、少なくとも部分的には挿入した権利データに基づいて権利ラベルに署名する。言うまでもなく、ＤＲＭサーバは、（ＤＥＳ１（ｒｉｇｈｔｓｄａｔａ））の解読および再暗号化を含めて、上述のようにこのプロセスで必要となり、行う義務のある暗号化および解読のステップも行う。提出された権利ラベル中の権利データを取り替えるようにＤＲＭサーバがなされている場合は、権利ラベルと、その権利ラベルを構築する元となるＯＲＴ９００は、必ずしも権利データを含む必要はないことに留意されたい。代わりに、権利データはＤＲＭサーバ３２０にあればよい。ただし、権利ラベルと、その権利ラベルを構築する元となるＯＲＴ９００とに権利データを含めると、ユーザにとって有用である場合があり、したがって状況によっては有用である可能性がある。

（ディレクトリによるライセンシング）
保護されたコンテンツのライセンスを発行する際、ライセンス発行エンティティ（以下「ライセンサ」）は、コンテンツ中の送信されたＳＲＬ３０８を調べて、権利を与えるべきユーザ／グループ／クラスタ／部門／プラットフォーム／など（以下「エンティティ」）を判定し、送信された証明書を調べてライセンスの要求者を識別する。それに基づき、ライセンサは、ＳＲＬ３０８にリストされた権利のどれを要求者に発行すべきかを判断する。概念的には、ライセンサは、ＳＲＬ３０８にリストされたエンティティを調べ、そのエンティティを要求者と比較する。このように、特定のグループがライセンスを受け取るべきであり、要求者がそのグループのメンバであるとＳＲＬ３０８に指定される場合、要求者には、そのグループについてＳＲＬ３０８に指定される権利を含むライセンスが与えられる。同様に、特定のユーザがライセンスを受け取るべきであり、要求者がそのユーザであるとＳＲＬ３０８に指定される場合、要求者には、そのユーザについてＳＲＬ３０８に指定された権利を含むライセンスが与えられる。理解されうるように、ある特定のＳＲＬ３０８は、いくつかのエンティティとその権利をリストすることができ、ある特定の要求者には１つまたは複数のエンティティのメンバであることに基づいてライセンスを与えることができる。

本発明の一実施形態では、図１２に示すように、要求者は、送信された証明書１２０２において識別子１２０４により識別され、この識別子１２０４は、例えば組織ディレクトリ１２０６において要求者が識別されるエイリアスとすることができる。それに対応して、ＳＲＬ３０８は、そのような識別子１２０４に従って権利を得る資格がある各エンティティをリストする。このように、ライセンス１２０８の要求を処理する一部として、ライセンサ１２１０は、証明書１２０２から要求者の識別子１２０４を取得し、取得した識別子１２０４を送信されたＳＲＬ３０８にリストされたすべての識別子１２０４と比較する。一致するものが見つかった場合、ライセンサ１２１０は、その要求者の識別子１２０４のＳＲＬ３０８に指定された権利と共にライセンス１２０８を要求者に発行する。

さらに、ディレクトリ１２０６が利用できることにより、他のエンティティそれぞれにおいて要求者のメンバーシップステータスを反映するであろう適切な相互参照情報がディレクトリ１２０６に入っていることを前提として、ライセンサ１２１０は、要求者がＳＲＬ３０８にリストされた他のエンティティのメンバであるかどうかを判定することもできる。通例、ディレクトリ１２０６は、各要求者について、その識別子１２０４だけでなく、要求者がそのメンバである各グループ／クラスタ／部門／プラットフォーム／他のエンティティ／などの識別子１２０４もリストする。ディレクトリ１２０６は、メールアドレス、代替のメールアドレス、ＩＤ、代替ＩＤ、グループのメンバーシップ、履歴的な識別子などの識別子１２０４を含むこともできることに留意されたい。

次いで図１３を参照すると、要求者から受け取った識別子１２０４を含む証明書１２０２と、要求者から受け取ったＳＲＬ３０８の権利データを用いて、ライセンサ１２１０は、以下の様態で要求者にライセンス１２０８を発行する。準備として、ライセンサ１２１０は、受け取った証明書１２０２から要求者の識別子１２０４を取得し（ステップ１３０１）、取得した識別子１２０４をディレクトリ１２０６で見つける（ステップ１３０３）。その後、ライセンサ１２１０は、ディレクトリ１２０６で見つけた識別子１２０４に基づき、要求者の識別子１２０４がメンバである各エンティティの識別子１２０４を見つける（ステップ１３０５）。このように、見つけた要求者の識別子１２０４と見つけたすべてのエンティティの識別子１２０４それぞれについて、ライセンサ１２１０は、その識別子１２０４と、送信されたＳＲＬ３０８にリストされたすべての識別子１２０４とを比較する（ステップ１３０７）。ここでも、一致するものが見つかると、ライセンサ１２１０は、一致した識別子１２０４のＳＲＬ３０８で指定された権利を含むライセンス１２０８を要求者に発行する（ステップ１３０９Ａ）。

複数の識別子１２０４をＳＲＬ３０８と比較するので、一致する識別子１２０４がＳＲＬ３０８に複数見つかる場合もあることに留意されたい。その場合、ライセンサ１２１０は、ＳＲＬ３０８中で一致した複数の識別子１２０４のうち適切な１つを選択し、その選択した一致識別子１２０４のＳＲＬ３０８で指定される権利を含むライセンス１２０８を要求者に発行する（ステップ１３０９Ｂ）。例えば、ライセンサは、要求者に最も多くの権利を譲渡する一致識別子１２０４を選択することができる（ステップ１３０９Ｂ−１）。ライセンサは、どの一致識別子１２０４が最も多くの権利を譲渡するかを判定することができる場合も、あるいはＳＲＬ３０８中の何らかの種類の優先度の印１２１２に依拠しなければならない場合もあることに留意されたい。後者の場合は、ＳＲＬ３０８の一致識別子（ユーザ）１２０４それぞれが対応する優先度印１２１２を有し、例えば印１２１２が高いほど付与される権利の範囲が大きくなることを意味する。このように、ライセンサ１２１０がＳＲＬ３０８中で一致する識別子１２０４を複数見つけた場合、ライセンサ１２１０は、最も高い優先度印１２１２を有する一致識別子１２０４を選択する（ステップ１３０９Ｂ−２）。

ディレクトリ１２０６を参照して要求者に関連する追加的な識別子１２０４を生成する際、ライセンサ１２１０は、例えばＳＲＬ３０８が作成されてから要求者のメールアドレスまたはＩＤが変わっている状況であっても一致が見つかるであろう見込みが高まることに留意されたい。一般には、ディレクトリ１２０６は、要求者の１つの識別子１２０４からその要求者の他の可能な識別子１２０４へのマッピングを提供し、それによって、ＳＲＬ３０８の識別子１２０４との一致を見つけようとする際にすべての識別子１２０４を用いることができる。

（グループに対するライセンシング）
本発明の一実施形態では、要求者によって提出された送信された証明書１２０２は、グループやクラスタ、あるいは何らかの他の個人の集合（以下「グループ」）を表すことができ、そのようなグループはディレクトリ１２０６内で適切に表される。そのようなグループには、配布リストまたはメールエイリアスなどのメールが可能なグループ、あるいはネットワークオペレーティングシステムなどと関連して定義されうるようなセキュリティグループが含まれることができる。したがって、ライセンサ１２１０は、送信された「グループ」の証明書１２０２を受け取ると実質的に先と同様に進行する。ただし、送信された証明書１２０２は特定のグループを表すので、ライセンサ１２１０から発行されたライセンス１２０８は、証明書１２０２で識別されるグループに対するものであり、特に要求者に対するものではないことに留意されたい。あるいは、ライセンサ１２１０は、要求者が証明書１２０２で識別されるグループの一部であることをディレクトリ１２０６から判断することができ、その場合は発行されたライセンス１２１０は要求者に対するものである。

前者の場合、発行されたライセンス１２０８は、そのグループの公開鍵に従って暗号化されたコンテンツ鍵を含むことができ、したがって要求者はそのグループの対応する秘密鍵を得る必要がある。したがって、要求者は、グループのメンバーシップの証明書をそのような秘密鍵と共に有することができ、それは恐らくは要求者の公開鍵に従って暗号化され、対応する要求者の秘密鍵に従って解読することができる。

後者の場合、要求者の公開鍵に従って暗号化されたコンテンツ鍵を発行されたライセンス１２０８に含めるために、ライセンサ１２１０は、さらに要求者から公開鍵を含む証明書を受け取ることができる。あるいは、ライセンサ１２１０は、そのような証明書をファイルに有することができ（例えば図６Ａおよび６Ｂのステップ６０８〜６１２参照）、要求者が送信されたグループ証明書１２０２で識別されるグループの一部であることをディレクトリ１２０６から判定すると、証明書中の公開鍵を使用することができる。

注目すべきこととして、グループに従ってＳＲＬ３０８に権利を指定し、ライセンス１２０８を発行することにより、企業または組織の環境でデジタル著作権管理を実施する。例えば、所定の部門のすべてのメンバが文書または電子メールを読む権利を持つように文書や電子メールをＤＲＭで保護することができるであろう。よくあるケースとして、そのような部門についてあるグループ（例えば電子メールエイリアス）が組織のディレクトリ１２０６に存在すると想定すると、文書または電子メールの作成者は、個人ではなくグループに基づいて権利を付与するであろう。理解されうるように、そのようなグループ単位の権利付与の利点としては、権利を有する個人のクラスを指定する際に作成者にとって使用が容易であることが挙げられる。また、グループに応じて権利を指定することにより、新しい者がグループに入り、古い者がグループを抜けても、指定された権利が「古く」ならない。代わりに、グループの現在のメンバすべては、そのグループのメンバーシップが組織ディレクトリ１２０６で最新の状態に保たれている限り権利を行使することができる。

（ライセンシング中のポリシーの挿入）
本発明の一実施形態では、図９のＯＲＴ９００との関連で触れたように、ＤＲＭサーバ／ライセンサ１２１０は、ＳＲＬ３０８に基づいてライセンス１２０８を発行する際に、提出されたＳＲＬ３０８の権利データを変更または入れ替えるように適合させることができる。具体的には、提出されたＳＲＬ３０８の権利データを明示的に無視し、ＳＲＬ３０８に基づいてライセンス１２０８を作成する際にライセンサ１２１０が代替のポリシーを代わりに入れる、あるいは「挿入」するいくつかの状況が発生する。ライセンサ１２１０がライセンス１２０８にポリシーを挿入するいくつかの特定の状況をここで開示するが、ライセンサ１２１０は、本発明の精神および範囲から逸脱せずに任意の他のタイプの状況でもライセンス１２０８にポリシーを挿入することができることに留意されたい。

第１の状況では、次いで図１４を参照すると、ライセンサ１２０８は、特別な権利が与えられる特別なエンティティ（ユーザ、グループなど）のリスト１２１４（図１２）を保持している。例えば、特別なエンティティは、数ある中で、組織内のより高い地位にある特定の個人、監督する地位にある個人、すべてのコンテンツをレンダリングできるべき特定の個人、およびそのような個人のグループを含むことができる。リスト１２１４は、実際には、特別なエンティティそれぞれのディレクトリリストの中で情報を識別するものとして組織ディレクトリ１２０６内に具体化するか、あるいはより単純にそのような特別なエンティティの１つまたは複数のグループを作成することにより具体化することができる。このように、特別なエンティティは、そのエンティティのＳＲＬ３０８がその他の点ではレンダリングを禁止する場合でもコンテンツをレンダリングすることができる。

エンティティがライセンス１２０８の要求の一部としてＳＲＬ３０８を提出すると、次いで図１４を参照すると、ライセンサ１２１０は、適当な様態でディレクトリ１２０６を調べて、提出元のエンティティが特別なエンティティとして特徴付けられているかどうかを判定し（ステップ１４０１）、そうである場合、ライセンサ１２１０は、提出されたＳＲＬ３０８にある権利データとは異なる特別な権利を用いてその特別なエンティティのためのライセンス１２０８を作成する（ステップ１４０３）。特別な権利は、本発明の精神および範囲から逸脱しない範囲で任意の権利であってよいことに留意されたい。例えば、特別な権利は、すべての特別なエンティティは対応するコンテンツに完全にアクセスし、レンダリングすることができる、特定グループのすべての特別エンティティはコンテンツに完全にアクセスし、レンダリングすることができる、特定の特別なエンティティはライセンス１２０８の有効期限が切れる前により多くの再生回数、あるいはより長い期間の強化された権利を受ける、等とすることができる。特別な権利がある個人またはグループに特定のものである場合、その権利は、ディレクトリ１２０６中のその個人またはグループのディレクトリエントリに指定することができ、そのようなディレクトリエントリは、特別な権利がある場所への適当な参照を有することができ、ライセンサ１２１０は、個人またはグループの識別子１２０４に基づいてデータベースから特別な権利を見つけられることに留意されたい。

第２の状況では、次いで図１４を参照すると、ライセンサ１２０８は、権利が制約または拒否されることになる制限付きエンティティ（ユーザ、グループなど）のリスト１２１６（図１２）を保持している。例えば、制限付きエンティティは、数ある中で、組織から抜けた個人、保守管理や建物の関係者など通常ではどのコンテンツへの権利も持つべきでない組織内の個人、契約者や臨時従業員など組織内で限定された身分しか持たない個人、およびそのような個人のグループなどである。上述の「特別な」リスト１２１４と同様に、制限付きリスト１２１６も、制限付きエンティティそれぞれについてのディレクトリリストの中で情報を識別するものとして組織ディレクトリ１２０６内に具体化することができ、あるいはより単純にそのような制限付きエンティティの１つまたは複数のグループを作成することにより具体化することができる。このように、制限付きエンティティは、そのＳＲＬ３０８がその他の点ではレンダリングを許可する場合であっても、コンテンツのレンダリングを制約される。

あるエンティティがライセンス１２０８の要求の一部としてＳＲＬ３０８を提出すると、引き続き図１４を参照して、ライセンサ１２１０は、適当な様態でディレクトリ１２０６を調べて、その提出元のエンティティが制限付きエンティティとして特徴付けることができるかどうかを判定し（ステップ１４０５）、そうである場合、ライセンサ１２１０は、提出されたＳＲＬ３０８にある権利データと異なる制限付き権利を用いてその制限付きエンティティのライセンス１２０８を作成する（ステップ１４０７）。制限付き権利は、本発明の精神および範囲から逸脱せずに任意の権利とすることができることに留意されたい。例えば、制限付き権利は、制限付きエンティティはすべてどのような形態でも対応するコンテンツにアクセスし、レンダリングすることができない、特定グループの制限付きエンティティはすべて短命の間だけコンテンツにアクセスし、レンダリングすることができる、制限付き特定のエンティティはコンテンツのコピーを１つだけ印刷できる等である。また、制限付き権利は、制限付きエンティティにはどのようなライセンスも付与すべきでないとしてもよい。特別な権利の場合と同様に、制限付き権利がある個人またはグループに特定のものである場合、その権利はディレクトリ１２０６のその個人またはグループのディレクトリエントリに指定することができ、そのディレクトリエントリは、制限付き権利が位置する場所への適当な参照を有することができ、ライセンサ１２１０は、その個人またはグループの識別子１２０４に基づいてデータベースで制限付き権利を見つけることができるなどである。

第３の状況では、ライセンサ１２０８は、ライセンス１２０８にポリシーを挿入して、対応するコンテンツをレンダリングするコンピューティングデバイス１５（図１１）で必要な最低限のシステム要件を指定することができる（ステップ１４０９）。最低限のシステム要件は通例、コンピューティングデバイス１５の信頼性と安全性に関連するものであるが、本発明の精神および範囲を逸脱せずに任意の他の事項に関連するものであってもよい。

ライセンサ１２１０にとって重要である信頼性および安全性の主要な例は、コンピューティングデバイス１５の信頼のおけるコンポーネント１８またはそのセキュリティ部分が現在のものであるかどうかである。理解されうるように、そのような新しさは、バージョン番号、ビルドされた日付などによって表すことができ、信頼のおけるコンポーネント１８またはその一部の古さを反映する。同じく理解されうるように、信頼のおけるコンポーネント１８またはその一部は、それが古くなるに従って、悪意のあるエンティティによるセキュリティ攻撃に弱くなる。したがって、ライセンサ１２１０は、一定の古さを超えている信頼のおけるコンポーネント１８またはその一部は信頼すべきでないと判断し、対応するコンテンツのレンダリングを許可する前に信頼性のない信頼のおけるコンポーネント１８またはその一部を更新することを求めるポリシーを自身が発行するライセンス１２０８に挿入することができる。

ライセンサ１２１０にとって重要である信頼性および安全性の別の例は、コンテンツをレンダリングすることになるアプリケーションを本当に信頼すべきであるかどうかである。理解されうるように、例えば保護されない形態でコンテンツを保存することを許可しないことによりあるアプリケーションを信頼してライセンス１２０８の範囲内でコンテンツをレンダリングさせ、一方で別のアプリケーションは同様には信頼できない場合が考えられる。したがって、ライセンサ１２１０は、特定のアプリケーションだけを用いて対応コンテンツをレンダリングすると決定し、そのアプリケーションだけを用いてコンテンツをレンダリングすることを要求するポリシーを自身が発行するライセンス１２０８に挿入することができる。

言うまでもなく、ポリシーを挿入する状況はこの他にも数多くある。一般には、ポリシーの挿入は、恐らくは要求者に基づいてＳＲＬ３０８中の権利データにさらに権利を追加する、または権利を削除するために行うことができ（ステップ１４１１）、同様に、同じく要求者に基づいて権利データに条件を追加する、あるいは条件を削除するために行うことができる（ステップ１４１３）。

（まとめ）
本発明と関連して行われるプロセスを実施するのに必要なプログラミングは、比較的単純であり、関連するプログラミング業界の者には明白であろう。したがって、そのようなプログラミングは本明細書には添付しない。任意の特定のプログラミングを用いて、本発明の精神および範囲から逸脱せずに本発明を実施することができる。

本発明の概念から逸脱せずに、上記の実施形態に変更を加えられることは理解されよう。特に、本発明について組織など限定された領域の点から説明したが、本発明は、本発明の精神および範囲から一切逸脱せずに、組織のサブセット、または複数の組織を包括する限定された領域内でも用いることができる。したがって、本発明はここに開示した特定の実施形態に限定されず、添付の特許請求の範囲に規定した本発明の精神および範囲内の変更を包含するものとする。

（付録１）
権利データのサンプル

（付録２）
署名済み権利ラベル（ＳＲ）３０８のサンプル

本発明を実施することができる例示的な非限定のコンピューティング環境を表すブロック図である。 本発明を実施することができる、各種のコンピューティングデバイスを有する例示的なネットワーク環境を表すブロック図である。 本発明によるデジタルコンテンツをパブリッシュするためのシステムおよび方法の一実施形態の機能ブロック図である。 本発明による権利が管理されたデジタルコンテンツをパブリッシュするための方法の一実施形態の流れ図である。 図４の方法によって生成された署名済み権利ラベルの構造を示すブロック図である。 本発明による権利が管理されたデジタルコンテンツをライセンスするためのシステムおよび方法の一実施形態のブロック図である。 本発明による権利が管理されたデジタルコンテンツをライセンスするための方法の一実施形態の流れ図である。 本発明による権利が管理されたデジタルコンテンツをライセンスするための方法の一実施形態の流れ図である。 本発明の一実施形態に従って権利ラベルを再パブリッシュする際に行われる主要ステップを示す流れ図である。 本発明の一実施形態に従ってユーザがオフラインパブリッシュを行えるようにするためにＤＲＭサーバからユーザに発行される証明書を示すブロック図である。 本発明の一実施形態に従って権利ラベルに組み込まれる情報を指定する権利テンプレートを示すブロック図である。 本発明の一実施形態に従って図９の権利テンプレートを作成し、権利テンプレートに基づいて図４Ａの署名済み権利ラベルを作成する際に行われる主要ステップを示す流れ図である。 信頼に基づくシステムの一例の施行アーキテクチャを示すブロック図である。 本発明の一実施形態に従ってライセンスの要求を処理するライセンサを示すブロック図である。 ライセンスを発行するときにディレクトリと関係して図１２のライセンサによって行われるステップを示す流れ図である。 発行されることになるライセンスにポリシーを挿入するときに図１２のライセンサによって行われるステップを示す流れ図である。

符号の説明

１０ａ、１０ｂ、１１０ａ、１１０ｂ、１１０ｃ コンピューティングオブジェクト／デバイス
１２ デジタルコンテンツ
１３ コンテンツパッケージ
１４ 通信ネットワーク／バス
１５ ユーザのコンピューティングデバイス
１６ ライセンス
１８ 信頼のおけるコンポーネント
２０ データベース
２４ ライセンスエバリュエータ
１００ 動作環境
１１０ コンピュータ
１２０ 処理装置
１２１ システムバス
１３０ システムメモリ
１３１ ＲＯＭ
１３２ ＲＡＭ
１３３ ＢＩＯＳ
１３４、１４４ オペレーティングシステム
１３５、１４５ アプリケーションプログラム
１３６、１４６ プログラムモジュール
１３７、１４７ プログラムデータ
１４１ ハードディスクドライブ
１５０ インタフェース
１５１ 磁気ディスクドライブ
１５２ 磁気ディスク
１５５ 光ディスクドライブ
１５６ 光ディスク
１６０ ユーザ入力インタフェース
１６１ ポインティングデバイス
１６２ キーボード
１７０ ネットワークインタフェース
１７１ ＬＡＮ
１７２ モデム
１７３ ＷＡＮ
１８０ リモートコンピュータ
１８１ メモリ記憶装置
１８２ グラフィックインタフェース
１８４ ＧＰＵ
１８５ リモートアプリケーションプログラム
１８６ ビデオメモリ
１９０ ビデオインタフェース
１９１ モニタ
１９５ 出力周辺インタフェース
１９６ プリンタ
１９７ スピーカ
３００ クライアント
３０２ コンテンツ作成アプリケーション
３０４ 暗号化されたデジタルコンテンツ
３０６ ＤＲＭクライアントＡＰＩ
３０８ 署名済み権利ラベル（ＳＲＬ）
３１０ 権利管理されたコンテンツ
３１２ 解読されたデジタルコンテンツ
３２０ ＤＲＭサーバ
３３０ 通信ネットワーク
８１０ ＤＲＭ証明書
９００ 権利テンプレート
１２０２ 証明書
１２０４ 識別子
１２０６ ディレクトリ
１２０８ ライセンス
１２１０ ライセンサ
１２１２ 優先度印
１２１４ 特別なエンティティのリスト
１２１６ 制限付きエンティティのリスト

Claims (18)

1. ライセンサが要求者にデジタルライセンスを発行して前記要求者が対応するデジタルコンテンツをレンダリングすることができるようにするための方法であって、該方法は、
   前記要求者から、前記コンテンツと関連付けられた権利データを含む要求を受け取ることであって、前記権利データは、少なくとも１つの識別子と該識別子と関連付けられた権利のセットとをリストすることと、
   前記識別子と該識別子と関連付けられた前記権利のセットを選択することであって、当該権利は前記発行されたライセンスに設定されるものであることと、
   前記識別子に基づき、代替の権利のセットを選択することと、
   前記権利データの前記権利のセットに代えて前記代替の権利セットを使用することと、
   前記代替の権利セットを用いて前記要求者に前記ライセンスを発行し、そうすることで、前記発行されたライセンス中の前記代替の権利セットにより、前記要求者が前記対応するコンテンツのレンダリングと関連して守らなければならない規定および条件を設定することと
   を備えることを特徴とする方法。
2. 前記ライセンサは、前記識別子についてのリストを含むディレクトリへのアクセスを有し、前記リストは、前記代替の権利データのセットを参照し、前記代替の権利データのセットを選択することは、前記ディレクトリ中で前記識別子を見つけることと、前記ディレクトリ中の前記識別子についてのリストにおいて前記代替の権利セットへの参照に基づいて前記代替の権利のセットを見つけることとを備えることを特徴とする請求項１に記載の方法。
3. 前記識別子に基づいて前記要求者が特別な要求者であることを判定することと、そのことに基づき前記権利データの前記権利のセットよりも大きな権利を提供する代替の権利セットを選択することを備えることを特徴とする請求項１に記載の方法。
4. 前記特別な要求者が前記対応するコンテンツに完全にアクセスし、レンダリングすることを許可する代替の権利セットを選択することを備えることを特徴とする請求項３に記載の方法。
5. 前記識別子に基づいて前記要求者が制限付きの要求者であることを判定することと、そのことに基づき前記権利データの前記権利セットよりも少ない権利を提供する代替の権利セットを選択することを備えることを特徴とする請求項１に記載の方法。
6. 前記制限付きの要求者が前記対応するコンテンツにアクセスし、レンダリングすることを許可しない代替の権利セットを選択することを備えることを特徴とする請求項５に記載の方法。
7. 前記対応するコンテンツがレンダリングされることになるコンピューティングデバイスに関して最小限のシステム要件を課す代替の権利セットを前記識別子に基づいて選択することを備えることを特徴とする請求項１に記載の方法。
8. 前記識別子に基づき前記権利データの前記権利のセットに権利を追加する代替の権利セットを選択することを備えることを特徴とする請求項１に記載の方法。
9. 前記識別子に基づき前記権利データの前記権利セットから権利を減らす代替の権利セットを選択することを含むことを特徴とする請求項１に記載の方法。
10. ライセンサが要求者にデジタルライセンスを発行して前記要求者が対応するデジタルコンテンツをレンダリングすることができるようにするための方法を実行するコンピュータ実行可能命令が格納されたコンピュータ可読媒体であって、前記方法は、
    前記要求者から、前記コンテンツと関連付けられた権利データを含む要求を受け取ることであって、前記権利データは、少なくとも１つの識別子と該識別子と関連付けられた権利のセットとをリストすることと、
    前記識別子と該識別子と関連付けられた前記権利のセットを選択することであって、当該権利が前記発行されたライセンス中に設定されるものであることと、
    前記識別子に基づき、代替の権利のセットを選択することと、
    前記権利データの前記権利のセットに代えて前記代替の権利セットを使用することと、
    前記代替の権利セットを用いて前記要求者に前記ライセンスを発行し、そうすることで、前記発行されたライセンス中の前記代替の権利セットにより、前記要求者が前記対応するコンテンツのレンダリングと関連して守らなければならない規定および条件を設定することと
    を備えたことを特徴とするコンピュータ可読媒体。
11. 前記ライセンサは、前記識別子についてのリストを含むディレクトリへのアクセスを有し、前記リストは、前記代替の権利データのセットを参照し、前記代替の権利データのセットを選択することは、前記ディレクトリ中で前記識別子を見つけることと、前記ディレクトリ中の前記識別子についてのリスト中の前記代替の権利セットへの参照に基づいて前記代替の権利のセットを見つけることとを備えたことを特徴とする請求項１０に記載のコンピュータ可読媒体。
12. 前記方法は、前記識別子に基づいて前記要求者が特別な要求者であることを判定することと、そのことに基づき前記権利データの前記権利のセットよりも大きな権利を提供する代替の権利セットを選択することを備えたことを特徴とする請求項１０に記載のコンピュータ可読媒体。
13. 前記方法は、前記特別な要求者が前記対応するコンテンツに完全にアクセスし、レンダリングすることを許可する代替の権利セットを選択することを備えたことを特徴とする請求項１２に記載のコンピュータ可読媒体。
14. 前記方法は、前記識別子に基づいて前記要求者が制限付きの要求者であることを判定することと、そのことに基づき前記権利データの前記権利セットよりも少ない権利を提供する代替の権利セットを選択することを備えたことを特徴とする請求項１０に記載のコンピュータ可読媒体。
15. 前記方法は、前記制限付きの要求者が前記対応するコンテンツにアクセスし、レンダリングすることを許可しない代替の権利セットを選択することを備えたことを特徴とする請求項１４に記載の媒体。
16. 前記方法は、前記対応するコンテンツがレンダリングされることになるコンピューティングデバイスに関して最小限のシステム要件を課す代替の権利セットを前記識別子に基づいて選択することを備えたことを特徴とする請求項１０に記載のコンピュータ可読媒体。
17. 前記方法は、前記識別子に基づき前記権利データの前記権利のセットに権利を追加する代替の権利セットを選択することを備えたことを特徴とする請求項１０に記載のコンピュータ可読媒体。
18. 前記方法は、前記識別子に基づき前記権利データの前記権利セットから権利を減らす代替の権利セットを選択することを備えたことを特徴とする請求項１０に記載のコンピュータ可読媒体。
    

Images