(57)【要約】【課題】対話式認証なしのデバイス上のコンテンツに関するデジタル権利管理（ＤＲＭ）暗号化および保護方法を提供する。【解決手段】デバイス６２が媒体６１からテーブル６４を獲得し、デバイス６２のデバイス鍵（ＤＫ）と、その（ＤＫ）のインデックス値を獲得し、獲得されたインデックス値に基づいてテーブルのエントリを指し示し、指し示されたエントリから暗号化された秘密を選択し、獲得されたデバイス鍵（ＤＫ）を選択された暗号化された秘密に適用してその秘密を露見させ、露見された秘密を適用してコンテンツをレンダリングすることによって媒体上のコンテンツをレンダリングする。【選択図】　　　　図１３
2004040772.tif 000002
【特許請求の範囲】
【請求項１】
ホストコンピュータ、および事前選択されたインデックス値を有するデバイス鍵（ＤＫ）を有するデバイスとの組合せで行われる方法であって、前記デバイスが、記憶媒体を受け入れるか、または前記記憶媒体を有するようになっており、前記記憶媒体は、秘密に従って保護されたデジタルコンテンツ、および複数のエントリを中に有するテーブルを記憶しており、各エントリが、複数のデバイスの１つの前記デバイス鍵（ＤＫ）、およびインデックス値によって暗号解読可能な鍵に従って暗号化された前記秘密を含んでおり、前記デバイスについて前記記憶媒体上の前記コンテンツをレンダリングする前記方法は、
前記記憶媒体上の前記コンテンツをレンダリングする要求を受け取るステップと、
前記記憶媒体から前記テーブルを獲得するステップと、
前記デバイスの前記デバイス鍵（ＤＫ）、および、その（ＤＫ）の前記インデックス値を獲得するステップと、
前記獲得されたインデックス値に基づいて前記テーブルのエントリを指し示すステップと、
前記指し示されたエントリから前記暗号化された秘密を選択するステップと、前記獲得されたデバイス鍵（ＤＫ）を前記選択された暗号化された秘密に適用して前記秘密を露見させるステップと、
前記露見された秘密を適用して対応する前記コンテンツをレンダリングするステップと
を含むことを特徴とする方法。
【請求項２】
前記秘密は、対称鍵、前記コンテンツに関するコンテンツ鍵、およびパスワードの一つを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記デバイスは、事前選択されたインデックス値をそれぞれが有する複数のデバイス鍵（ＤＫ）を有しており、
前記デバイスの前記デバイス鍵（ＤＫ）、および、そのデバイス鍵（ＤＫ）の前記インデックス値を獲得するステップと、
それぞれの獲得されたデバイス鍵（ＤＫ）に関して、
前記対応する獲得されたインデックス値に基づいて前記テーブルのエン
トリを指し示すこと、
前記指し示されたエントリから前記暗号化された秘密を選択すること、
および、
前記獲得されたデバイス鍵（ＤＫ）を前記選択された暗号化された秘密
に適用して前記秘密を露見させること
を実際に前記秘密が露見されるまで行うステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記記憶媒体は、前記記憶媒体のＩＤを前記記憶媒体上に含み、前記秘密と前記ＩＤの組合せから導出された最終の秘密に従って保護された前記デジタルコンテンツを前記記憶媒体上に記憶しており、前記コンテンツが、前記ＩＤによって前記記憶媒体に結び付けられている方法であって、
前記獲得されたデバイス鍵（ＤＫ）を前記選択された暗号化された秘密に適用して前記秘密を露見させるステップと、
前記記憶媒体の前記ＩＤを前記記憶媒体から獲得するステップと、
前記露見された秘密、および前記獲得されたＩＤを所定の関数に適用して最終の秘密を生成するステップと、
前記生成された最終の秘密を適用して対応する前記コンテンツをレンダリングするステップと
を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記露見された秘密、および前記獲得されたＩＤを一方向ハッシュ関数に適用して前記最終の秘密を生成することを含むことを特徴とする請求項４に記載の方法。
【請求項６】
前記記憶媒体は、前記記憶媒体のＩＤを前記記憶媒体上に含み、前記テーブルは、前記テーブルに記憶された前記記憶媒体の前記ＩＤを含み、前記テーブルが前記ＩＤによって前記記憶媒体に結び付けられた方法であって、
前記記憶媒体の前記ＩＤを前記記憶媒体から獲得するステップと、
前記テーブルに記憶された前記記憶媒体の前記ＩＤを獲得するステップと、
前記獲得されたＩＤを比較して、前記ＩＤが互いに一致する場合にだけ先に進むステップと
をさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記テーブルは前記テーブルに記憶された前記記憶媒体の前記ＩＤに少なくともある程度基づく署名を含んでおり、
前記署名を確認して前記ＩＤを検証するステップをさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記テーブルは露見された前記秘密に従って暗号化された前記記憶媒体の前記ＩＤを含んでおり、
前記秘密を前記暗号化されたＩＤに適用することで前記ＩＤを獲得して、一致することを明らかにすることを含むことを特徴とする請求項６に記載の方法。
【請求項９】
前記記憶媒体上の前記テーブルは新しい秘密を有するように定期的に更新され、かつ前の秘密のデイジーチェーンを有しており、前記デイジーチェーンの中のそれぞれの前の秘密は直後の秘密に従って暗号化されて一続きのリンクを形成し、前記テーブルの各エントリは、前記新しい秘密、または複数のデバイスの１つの前記デバイス鍵（ＤＫ）に従って暗号化された前記前の秘密、インデックス値、および前記エントリの前記暗号化された秘密に関するバージョン番号のうち１つを含んでおり、レンダリングされるべき前記コンテンツが、そのコンテンツを保護する前記デイジーチェーンの中の前記秘密に対応するバージョン番号を有する方法であって、
前記コンテンツのバージョン番号を判定するステップと、
前記指し示されたエントリから前記暗号化された秘密を選択するステップと、
前記選択された暗号化された秘密のバージョン番号を判定するステップと、
前記獲得されたデバイス鍵（ＤＫ）を前記選択された暗号化された秘密に適用して前記選択された暗号化された秘密を露見させるステップと、
前記選択された暗号化された秘密の前記バージョン番号に基づいて前記デイジーチェーンに入るエントリポイントを決定するステップと、
前記デイジーチェーンの前記エントリポイントから遡って前記コンテンツを保護している前記秘密を露見させるステップと、
前記露見された秘密を適用して対応する前記コンテンツをレンダリングするステップを含み、
デバイスは、前記デイジーチェーンを前記エントリポイントから遡って、より早期の秘密を獲得できるが、より後の秘密は獲得できない
ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記選択された暗号化された秘密、および前記コンテンツの前記バージョン番号に基づき、前記秘密を使用して前記コンテンツをレンダリングすることができるかどうかを判定するステップと、
前記選択された暗号化された秘密の前記バージョン番号が前記コンテンツの前記バージョン番号より低くなく、したがって、前記コンテンツをレンダリングするのに使用することができる場合にだけ先に進むステップと
をさらに含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記デバイス鍵（ＤＫ）は対称鍵であることを特徴とする請求項１に記載の方法。
【請求項１２】
ホストコンピュータ、および事前選択されたインデックス値を有するデバイス鍵（ＤＫ）をそれぞれが有する複数のデバイスとの組合せで行われる方法であって、各デバイスが、記憶媒体を受け入れるか、または前記記憶媒体を有するようになっており、前記記憶媒体は、前記記憶媒体のＩＤを前記記憶媒体上に含むとともに秘密に従って保護されたデジタルコンテンツ、および複数のエントリを中に有するテーブルを前記記憶媒体上に記憶しており、各エントリが、複数のデバイスの１つの前記デバイス鍵（ＤＫ），およびインデックス値によって暗号解読可能な鍵に従って暗号化された秘密を含んでおり、前記ホストコンピュータについて前記記憶媒体を前記テーブルとともに提供する前記方法は、
キャッシュから前記テーブルを獲得するステップと、
前記記憶媒体の前記ＩＤを前記記憶媒体から獲得するステップと、
前記記憶媒体の前記獲得されたＩＤを前記獲得されたテーブルに付加するステップと、
デバイス鍵（ＤＫ）および前記デバイス鍵（ＤＫ）の前記インデックス値を使用して、前記獲得されたテーブルの前記対応するエントリを見出して、かつ、そのテーブルの秘密を露見させるステップと、
前記記憶媒体の前記ＩＤと前記露見された秘密により、前記テーブルを前記記憶媒体に結び付けるステップと、
前記結び付けられたテーブルを前記記憶媒体にコピーするステップと
を含むことを特徴とする方法。
【請求項１３】
前記テーブルを前記記憶媒体に結び付けるステップは、前記記憶媒体の前記ＩＤ、および前記露見された秘密に少なくともある程度基づいて前記テーブルに署名を付加することを含むことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記記憶媒体の前記ＩＤにより前記テーブルを前記記憶媒体に結び付けるステップは、前記露見された秘密に従って前記ＩＤを暗号化すること、および、前記暗号化されたＩＤを前記テーブルに付加することを含むことを特徴とする請求項１２に記載の方法。
【請求項１５】
相異なる秘密にそれぞれが基づく複数のテーブルを有するキャッシュから前記テーブルを獲得するステップを含むことを特徴とする請求項１２に記載の方法。
【請求項１６】
前記テーブルにバージョン番号を割り当てるステップをさらに含むことを特徴とする請求項１２に記載の方法。
【請求項１７】
前記提供されたテーブルは第Ｎ番のテーブルであって、前記ホストコンピュータにより、第（Ｎ＋１）番の更新されたテーブルを前記記憶媒体に提供して、前記記憶媒体上の前記提供された第Ｎ番のテーブルと置き換える方法であって、かつ、
第（Ｎ＋１）番の秘密を有する第（Ｎ＋１）番のテーブルを前記キャッシュから獲得するステップと、
前記記憶媒体の前記ＩＤを前記記憶媒体から獲得するステップと、
前記記憶媒体の前記獲得されたＩＤを前記（Ｎ＋１）番のテーブルに付加するステップと、
前記第（Ｎ＋１）番のテーブルから第（Ｎ＋１）番の秘密を獲得するステップと、
前記記憶媒体上の前記第Ｎ番のテーブルから第Ｎ番の秘密を獲得し、そして、存在するならば、前記第Ｎ番のテーブルの前の秘密のデイジーチェーンを獲得するステップであって、前記デイジーチェーンの中のそれぞれの前の秘密が、直後の秘密に従って暗号化されて一続きのリンクを形成しているステップと、
前記獲得されたデイジーチェーンを拡張するとともに、前記第（Ｎ＋１）番の秘密に従って暗号化された第Ｎ番の秘密を、前記デイジーチェーンの中の別のリンクとして前記デイジーチェーンに追加するステップと、
前記拡張されたデイジーチェーンを前記（Ｎ＋１）番のテーブルに付加するステップと、
前記第（Ｎ＋１）番のテーブルを調整して無効にされたデバイス鍵（ＤＫ）に関する古い秘密を含ませるとともに、バージョン番号を各エントリに割り当てるステップと、
前記記憶媒体の前記ＩＤおよび前記獲得された第（Ｎ＋１）番の秘密により、前記（Ｎ＋１）番のテーブルを前記記憶媒体に結び付けるステップと、
前記調整された第（Ｎ＋１）番のテーブルを前記記憶媒体にコピーして前記記憶媒体上の前記第Ｎ番のテーブルと置き換えるステップと
を含むことを特徴とする請求項１２に記載の方法。
【請求項１８】
前記第（Ｎ＋１）番のテーブルを前記記憶媒体に結び付けるステップは、前記記憶媒体の前記ＩＤ、および前記露見された秘密に少なくともある程度、基づく署名を前記第（Ｎ＋１）番のテーブルに付加することを含むことを特徴とする請求項１７に記載の方法。
【請求項１９】
前記（Ｎ＋１）番のテーブルを前記記憶媒体の前記ＩＤにより前記記憶媒体に結び付けるステップは、前記獲得された第（Ｎ＋１）番の秘密に従って前記ＩＤを暗号化することと、前記暗号化されたＩＤを前記第（Ｎ＋１）番のテーブルに付加することを含むことを特徴とする請求項１７に記載の方法。
【請求項２０】
前記第Ｎ番のテーブルにおける各エントリは、対応する前記暗号化された秘密のバージョン番号をさらに含んでおり、さらに、無効にされたデバイス鍵（ＤＫ）に関する古い秘密を含むように前記第（Ｎ＋１）番のテーブルを調整することと、バージョン番号を各エントリに割り当てることを含む方法であって、
前記第（Ｎ＋１）番のテーブルから、前記テーブルにおいてどのデバイス鍵（ＤＫ）が無効にされたかを判定するステップと、
それぞれの無効にされた（ＤＫ）に関して、前記第Ｎ番のテーブルの中の対応するエントリ、ならびにその対応するエントリの前記バージョン番号でその第（Ｎ＋１）番のテーブルの中のエントリを埋めるステップと、
前記第（Ｎ＋１）番のテーブルの前記バージョン番号を、前記第Ｎ番のテーブルからの入力が行われておらず、したがってまだ有効な前記第（Ｎ＋１）番のテーブルの中のすべてのエントリに割り当てるステップであって、これにより、有効なデバイス鍵（ＤＫ）を有する有効なデバイスが前記第（Ｎ＋１）番のテーブルの最新の（第（Ｎ＋１）番）の秘密にアクセスすることができ、かつ、無効にされたデバイス鍵（ＤＫ）を有する無効にされたデバイスが前記第（Ｎ＋１）番の秘密より早期の前記第（Ｎ＋１）番のテーブルの中の対応する秘密にアクセスすることができ、さらに、これにより、前記アクセスされた秘密を使用して、前記デバイスは、拡張により、前記デイジーチェーンの中のすべてのより早期の秘密にアクセスできるが、より後の秘密には全くアクセスできないステップと
を含むことを特徴とする請求項１７に記載の方法。
【請求項２１】
前記デバイス鍵（ＤＫ）は対称鍵であることを特徴とする請求項１２に記載の方法。
【請求項２２】
ホストコンピュータと、記憶媒体上に前記記憶媒体のＩＤを含んでおり、前記記憶媒体上に複数のエントリを中に有するテーブルを有する前記記憶媒体との組合せで行われる方法であって、各エントリは、複数のデバイスの１つの前記デバイス鍵（ＤＫ）、およびインデックス値によって暗号解読可能な鍵に従って暗号化された前記秘密を含んでおり、前記テーブルの現行の秘密の少なくとも１つに従って前記記憶媒体上にデジタルコンテンツを記憶する前記方法は、
前記記憶媒体から前記ＩＤを獲得するステップと、
前記テーブルから現行の秘密を獲得するステップと、
前記獲得された現行の秘密と前記獲得されたＩＤを所定の関数に適用して最終の秘密を生成するステップと、
前記最終の秘密に従って前記記憶媒体上に記憶されるべき前記コンテンツを保護し、これにより、前記コンテンツを前記記憶媒体に前記記憶媒体の前記ＩＤにより結び付けるステップと、
前記保護されたコンテンツを前記記憶媒体にコピーするステップと
を含むことを特徴とする方法。
【請求項２３】
前記獲得された現行の秘密と前記獲得されたＩＤを一方向ハッシュ関数に適用して前記最終の秘密を生成することを含むことを特徴とする請求項２２に記載の方法。
【請求項２４】
前記テーブルは、前記記憶媒体の前記ＩＤ、および前記記憶媒体の前記ＩＤに基づく署名を内部に含んでおり、
前記署名を検査して、前記テーブルの中の前記記憶媒体の前記ＩＤが前記記憶媒体から獲得された前記ＩＤと一致することを確認するステップをさらに含むことを特徴とする請求項２２に記載の方法。
【請求項２５】
前記デバイス鍵（ＤＫ）は対称鍵であることを特徴とする請求項２２に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、デジタルコンテンツにおける権利を行使するためのアーキテクチャに関する。より詳細には、本発明は、デジタルコンテンツのユーザによって獲得されたライセンス権利によって指定されたパラメータに従ってのみ暗号化されたデジタルコンテンツへのアクセスを許すそのような行使アーキテクチャに関する。さらにより詳細には、本発明は、限られた暗号解読能力および通信能力を有する比較的小さく、および／または単純なデバイスのためのアーキテクチャに関する。
【０００２】
本出願は、１９９９年４月１２日に出願した「ＥＮＦＯＲＣＥＭＥＮＴ　ＡＲＣＨＩＴＥＣＴＵＲＥ　ＡＮＤＭＥＴＨＯＤ　ＦＯＲ　ＤＩＧＩＴＡＬ　ＲＩＧＨＴＳ　ＭＡＮＡＧＥＭＥＮＴ」という名称の米国特許出願番号０９／２９０，３６３、および１９９９年３月２７日に出願した「ＥＮＦＯＲＣＥＭＥＮＴ　ＡＲＣＨＩＴＥＣＴＵＲＥ　ＡＮＤ　ＭＥＴＨＯＤ　ＦＯＲ　ＤＩＧＩＴＡＬ　ＲＩＧＨＴＳ　ＭＡＮＡＧＥＭＥＮＴ」という名称の米国特許仮出願番号６０／１２６，６１４に関連する。
【０００３】
【従来の技術】
デジタル権利の管理および行使は、デジタルコンテンツがユーザに配布されるデジタルオーディオ、デジタルビデオ、デジタルテキスト、デジタルデータ、デジタルマルチメディアなどのデジタルコンテンツに関連して極めて望ましい。配布の通常の様式には、磁気（フロッピー（登録商標））ディスク、磁気テープ、光（コンパクト）ディスク（ＣＤ）などの有形のデバイス、ならびに電子掲示板、電子ネットワーク、インターネットなどの無形の媒体が含まれる。ユーザが受け取ると、ユーザは、パーソナルコンピュータ上のメディアプレーヤなどの適切なレンダリングデバイスの助けを借りてデジタルコンテンツをレンダリングする、つまり「再生」する。
【０００４】
通常、作成者、発行者、放送業者などのコンテンツ所有者または権利所有者（以降、「コンテンツ所有者」）は、ライセンス料または何らかの他の対価と引換えにユーザまたは受け手にデジタルコンテンツを配布することを望む。コンテンツ所有者は、選択が与えられるのであれば、ユーザが、配布されたデジタルコンテンツに対して何を行うことができるかを制限することを望む可能性が高い。例えば、コンテンツ所有者は、ユーザが、少なくとも第２のユーザからのライセンス料をコンテンツ所有者に与えないような仕方でコンテンツをコピーして第２のユーザに再配布することを禁止することを望む。
【０００５】
さらに、コンテンツ所有者は、ユーザに実際に購入されたあらゆるタイプのライセンスの条項を守らせながら、異なるライセンス料で異なるタイプの使用ラインセンスを購入する柔軟性をユーザに提供することを望む可能性がある。例えば、コンテンツ所有者は、配布されたデジタルコンテンツが、限られた回数だけ、ある合計時間だけ、あるタイプのマシン上でだけ、あるタイプのメディアプレーヤ上でだけ、あるタイプのユーザによってだけ再生されるのを許すことを望む可能性がある。
【０００６】
しかし、配布が行われた後、コンテンツ所有者は、デジタルコンテンツに対してほとんど規制を有さない。このことは、実質的にすべての新しいパーソナルコンピュータまたは最新のパーソナルコンピュータが、デジタルコンテンツの正確なデジタルコピーを作成し、正確なデジタルコピーを書込み可能な磁気ディスクまたは光ディスクにダウンロードする、または正確なデジタルコピーをインターネットなどのネットワークを介して任意の宛先に送信するのに必要なソフトウェアおよびハードウェアを含むことに鑑みて特に問題である。
【０００７】
もちろん、ライセンス料が得られた正当な取引の一環として、コンテンツ所有者は、デジタルコンテンツのユーザが、デジタルコンテンツを再配布しないことを約束することを要求することができる。しかし、そのような約束は、簡単に結ばれて簡単に破られる。コンテンツ所有者は、通常、暗号化および暗号解読が関わるいくつかの周知のセキュリティデバイスの任意のものを介してそのような再配布を防止しようと試みることができる。しかし、ある程度、決心したユーザが、暗号化されたデジタルコンテンツを解読し、デジタルコンテンツを暗号化されていない形態で保存した後、そのコンテンツを再配布することを防止するものはほとんど存在しない。
【０００８】
したがって、規制が柔軟であり、デジタルコンテンツのコンテンツ所有者によって定義可能である、任意の形態のデジタルコンテンツの規制されたレンダリングまたは再生を可能にする行使アーキテクチャおよび行使方法を提供する必要性が存在する。また、レンダリング環境が行使アーキテクチャの少なくとも一部分を含む、パーソナルコンピュータなどのコンピューティングデバイス上で規制されたレンダリング環境を提供する必要性も存在する。レンダリング環境は、デジタルコンテンツが、コンテンツ所有者の規制下にないコンピューティングデバイス上でレンダリングされるにしても、コンテンツ所有者によって指定された通りにしかレンダリングされることを許さない。
【０００９】
さらに、信頼される構成要素が、コンテンツ所有者によって許可されていない仕方でデジタルコンテンツにアクセスしようとするコンピューティングデバイスのユーザによる試みにさえ抗して、あるデジタルコンテンツに関連してコンピューティングデバイス上でコンテンツ所有者の権利を行使する、コンピューティングデバイス上で実行される信頼される構成要素の必要性が存在する。単に一例として、信頼されるソフトウェア構成要素は、コンピューティングデバイスのユーザが、デジタルコンテンツのコンテンツ所有者によって許可されている形を除き、デジタルコンテンツのコピーを作成するのを防止する。
【００１０】
最後に、デジタル権利管理アーキテクチャを比較的小さく、および／または単純なデバイスにも適用することを可能にする方法およびメカニズムの必要性が存在する。より詳細には、比較的小さいデバイス上のコンテンツに関して、コンテンツがレンダリングされるデバイスが比較的小さく、および／または単純であり、非対称鍵暗号解読を行うことやネットワーク接続を介して遠隔のエンティティと通信することなどの比較的複雑な機能を有していなくても、暗号化およびデータ保護を可能にするバージョンのデジタル権利管理アーキテクチャの必要性が存在する。より詳細には、非対称鍵暗号解読を行う必要がなく、Ｗｅｂ接続またはネットワーク接続を要さない、ＤＲＭアーキテクチャを比較的小さく、および／または単純なデバイスにも適用するメカニズムおよび方法の必要性が存在する。
【００１１】
【特許文献１】
米国特許出願公開第２００２／００１３７７２号明細書
【特許文献２】
特開２００３−１０１５２６号公報
【００１２】
【発明が解決しようとする課題】
本発明の目的は、上記の必要性を充足することのできる方法を提供することである。
【００１３】
【課題を解決するための手段】
前述した必要性は、アーキテクチャおよび方法が、インターネット、光ディスクなどの媒体上で利用可能な保護された（セキュアな）デジタルコンテンツにおける権利を行使する、デジタル権利管理のための行使アーキテクチャおよび行使方法によって少なくともある程度、満たされる。コンテンツを供与するため、このアーキテクチャは、インターネットなどを介して暗号化された形態でデジタルコンテンツがアクセス可能であるコンテンツサーバを含む。また、コンテンツサーバは、光ディスク等の上に記録するために暗号化されたデジタルコンテンツを供給することも可能であり、暗号化されたデジタルコンテンツを光ディスク自体の上で配布することができる。コンテンツサーバにおいて、デジタルコンテンツは、暗号化鍵を使用して暗号化され、デジタルコンテンツをユーザのコンピューティングデバイスまたはクライアントマシンにおいてデジタルライセンスと結び付ける（ｂｉｎｄ）のに公開鍵／秘密鍵技術が使用される。
【００１４】
ユーザが、コンピューティングデバイス上でデジタルコンテンツをレンダリングしようと試みたとき、レンダリングアプリケーションが、ユーザのコンピューティングデバイス上でデジタル権利管理（ＤＲＭ）システムを起動する。ユーザが、初めてそのデジタルコンテンツをレンダリングしようと試みている場合、ＤＲＭシステムは、求めている仕方でデジタルコンテンツをレンダリングするライセンスを獲得するようライセンスサーバにユーザを導くか、またはユーザ側でアクションを全く必要とすることなくライセンスサーバからライセンスをトランスペアレントに獲得する。ライセンスは、以下のものを含む。
【００１５】
−暗号化されたデジタルコンテンツを解読する暗号解読鍵（ＫＤ）、
−記述がデジタル可読形態である場合、ライセンスによって与えられる権利（再生、コピー等）、および関連する条件（開始日、失効日、再生の回数等）の記述、および
−ライセンスの完全性を保証するデジタル署名。
【００１６】
ユーザが、ライセンスサーバからそのようなライセンスを獲得することなしに暗号化されたデジタルコンテンツを解読してレンダリングすることができてはならない。獲得されたライセンスはユーザのコンピューティングデバイス内のライセンスストアに格納される。
【００１７】
重要なことには、ライセンスサーバは、「信頼される（ｔｒｕｓｔｅｄ）」（すなわち、自らを認証することができる）ＤＲＭシステムだけにライセンスを発行する。「信頼」を実装するため、ＤＲＭシステムは、ＤＲＭシステムのために暗号解読機能および暗号化機能を行う「ブラックボックス」を備えている。ブラックボックスは、公開鍵／秘密鍵ペア、バージョン番号、および固有署名を含み、以上すべてが、承認された認証機関によって提供されるものである。公開鍵は、発行されるライセンスの部分を暗号化し、これにより、ライセンスをブラックボックスに結び付ける（ｂｉｎｄ）目的でライセンスサーバに供与される。秘密鍵は、対応する公開鍵を使用して暗号化された情報を解読する目的で、ブラックボックスにだけ利用可能であり、ユーザまたは他の何人にも利用可能ではない。ＤＲＭシステムは、最初、公開鍵／秘密鍵ペアを有するブラックボックスを備え、ユーザは、ライセンスを最初に要求したとき、ブラックボックスサーバから更新されたセキュアなブラックボックスをダウンロードするように促される。ブラックボックスサーバは、固有の公開鍵／秘密鍵ペアとともに更新されたブラックボックスを提供する。更新されたブラックボックスは、ユーザのコンピューティングデバイス上でだけ実行される固有の実行可能コードで書かれ、定期的に再更新される。
【００１８】
ユーザが、ライセンスを要求したとき、クライアントマシンは、ブラックボックスの公開鍵、バージョン番号、および署名をライセンスサーバに送り、ライセンスサーバは、バージョン番号が最新であり、署名が有効である場合にだけ、ライセンスを発行する。また、ライセンス要求は、行われたライセンスの要求が関係するデジタルコンテンツの識別、および要求されたデジタルコンテンツに関連する暗号解読鍵を特定する鍵ＩＤも含む。ライセンスサーバは、ブラックボックス公開鍵を使用して暗号解読鍵を暗号化し、暗号解読鍵を使用してライセンス条項を暗号化した後、暗号化された暗号解読鍵および暗号化されたライセンス条項をライセンス署名とともにユーザのコンピューティングデバイスにダウンロードする。
【００１９】
ダウンロードされたライセンスが、ＤＲＭシステムライセンスストアの中に記憶されると、ユーザは、ライセンスによって与えられ、ライセンス条項によって指定された権利に従ってデジタルコンテンツをレンダリングすることができる。デジタルコンテンツをレンダリングする要求が行われたとき、ブラックボックスが、暗号解読鍵およびライセンス条項を解読するようにさせられ、またＤＲＭシステムライセンスイバリュエータ（ｅｖａｌｕａｔｏｒ）が、ライセンス条項を評価する。ブラックボックスは、ライセンス評価により、要求者が、コンテンツを再生することが許されているという判定がもたらされる場合にだけ暗号化されたデジタルコンテンツを解読する。解読されたコンテンツが、レンダリングのためにレンダリングアプリケーションに提供される。
【００２０】
本発明の一実施形態では、複数のデバイスのそれぞれが、事前選択されたインデックス値を有するデバイス鍵（ＤＫ）を有する。各デバイスは、記憶媒体を受け取るようになっているか、または記憶媒体を有する。記憶媒体には、秘密に従って保護されたデジタルコンテンツ、および複数のエントリを有するテーブルが記憶されている。各エントリは、複数のデバイスの１つのデバイス鍵（ＤＫ）、およびインデックス値で暗号解読可能な鍵に従って暗号化された秘密を含む。
【００２１】
デバイスが媒体上のコンテンツをレンダリングするには、デバイスは、その媒体からテーブルを獲得し、デバイスのデバイス鍵（ＤＫ）、およびそのデバイス鍵（ＤＫ）のインデックス値を獲得し、獲得されたインデックス値に基づいてテーブルのエントリを指し示し（ｉｎｄｅｘ　ｉｎｔｏ）、指し示されたエントリから暗号化された秘密を選択し、獲得されたデバイス鍵（ＤＫ）を選択された暗号化された秘密に適用してその秘密を露見させ、露見された秘密を適用してコンテンツをレンダリングする。
【００２２】
記憶媒体は、自らのＩＤを含む。ホストコンピュータが媒体にテーブルを提供するには、ホストコンピュータは、キャッシュからテーブルを獲得し、媒体から媒体のＩＤを獲得し、媒体の獲得されたＩＤを獲得されたテーブルに付加し、デバイス鍵（ＤＫ）、およびデバイス鍵のインデックス値を使用して獲得されたテーブルにおいて対応するエントリを見出して、テーブルの秘密を露見させ、媒体のＩＤ、および露見された秘密でテーブルを媒体に結び付け（ｔｉｅ）、結び付けられたテーブルを媒体にコピーする。
【００２３】
提供されたテーブルは、第Ｎ番のテーブルである。ホストコンピュータが、媒体上の提供された第Ｎ番のテーブルと置き換わる第（Ｎ＋１）番の更新されたテーブルを媒体に提供するには、ホストコンピュータは、第（Ｎ＋１）番の秘密を有する第（Ｎ＋１）番のテーブル６４をキャッシュから獲得し、媒体から媒体のＩＤを獲得し、媒体の獲得されたＩＤを第（Ｎ＋１）番のテーブルに付加し、第（Ｎ＋１）番のテーブルから第（Ｎ＋１）番の秘密を獲得し、媒体上の第Ｎ番のテーブルから第Ｎ番の秘密を、また存在する場合、第Ｎ番のテーブルにおいて前の秘密のデイジーチェーン（ｄａｉｓｙ　ｃｈａｉｎ）を獲得する。デイジーチェーンの中のそれぞれの前の秘密は、直後の秘密に従って暗号化されて一続きのリンクを形成している。次に、ホストコンピュータは、獲得されたデイジーチェーンを拡張して、第（Ｎ＋１）番の秘密に従って暗号化された第Ｎ番の秘密をデイジーチェーンの中の別のリンクとして追加し、拡張されたデイジーチェーンを第（Ｎ＋１）番のテーブルに付加し、無効にされたデバイス鍵（ＤＫ）に関する古い秘密を含むように第（Ｎ＋１）番のテーブルを調整し、各エントリにバージョン番号を割り当て、媒体のＩＤ、および獲得された第（Ｎ＋１）番の秘密で第（Ｎ＋１）番のテーブルを媒体に結び付け、媒体上の第Ｎ番のテーブルに置き換わるように調整された第（Ｎ＋１）番のテーブルを媒体にコピーする。
【００２４】
ホストコンピュータが、媒体上のテーブルの現行の秘密に従って媒体上にデジタルコンテンツを記憶するには、ホストコンピュータは、媒体からＩＤを獲得し、テーブルから現行の秘密を獲得し、獲得された現行の秘密、および獲得されたＩＤを所定の関数に適用して最終の秘密を生成し、媒体上に記憶されるべきコンテンツを最終の秘密に従って保護し、これにより、媒体のＩＤでコンテンツを媒体に結び付け、保護されたコンテンツを媒体にコピーする。
【００２５】
以上の概要、および本発明の実施形態の以下の詳細な説明は、添付の図面と併せて読まれるとき、よりよく理解される。本発明を例示するため、図面には、現在、好ましいとされる実施形態を示している。ただし、理解されるべきこととして、本発明は、図示した構成および手段（ｉｎｓｔｒｕｍｅｎｔａｌｉｔｉｅｓ）には限定されない。
【００２６】
【発明の実施の形態】
同様の符号が、すべての図面にわたって同様の要素を指すように使用される図面を詳細に参照すると、図１に、本発明の一実施形態による行使アーキテクチャ１０が示されている。全体として、行使アーキテクチャ１０により、デジタルコンテンツ１２の所有者が、デジタルコンテンツ１２がユーザのコンピューティングデバイス１４上でレンダリングされることが許されるには、まず満たされなければならないライセンス規則を指定することが可能になる。ライセンス規則は、ユーザ／ユーザのコンピューティングデバイス１４（以降、状況により別段、必要とされない限り、これらの用語は区別しない）が、コンテンツ所有者、またはコンテンツ所有者の代理業者から獲得しなければならないデジタルライセンス１６の中で実現される。デジタルコンテンツ１２は、暗号化された形態で配布され、無料で広汎に配布されることが可能である。好ましくは、デジタルコンテンツ１２を解読するための暗号解読鍵（ＫＤ）が、ライセンス１６に含められる。
【００２７】
コンピュータ環境
図１２、および以下の考察は、本発明および／または本発明の部分を実施することができる適切なコンピューティング環境の簡単な一般的説明を提供するものとする。必須ではないが、本発明は、サーバ上のクライアントワークステーションなどのコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈（ｃｏｎｔｅｘｔ）で説明する。一般に、プログラムモジュールには、特定のタスクを行う、または特定の抽象データタイプを実装するルーチン、プログラム、オブジェクト、構成要素、データ構造等が含まれる。さらに、本発明、および／または本発明の部分は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースの家庭用電化製品またはプログラマブル家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ等を含め、他のコンピュータシステム構成で実施してもよいことを理解されたい。また、本発明は、タスクが、通信網を介してリンクされた遠隔処理デバイスによって行われる分散コンピューティング環境において実施してもよい。分散コンピューティング環境では、プログラムモジュールが、ローカルのメモリ記憶デバイスと遠隔の記憶デバイスの両方の中に配置されることが可能である。
【００２８】
図１２に示す通り、例としての汎用コンピューティングシステムには、処理ユニット１２１、システムメモリ１２２、およびシステムメモリから処理ユニット１２１までを含む様々なシステム構成要素を結合するシステムバス１２３を含む、従来のパーソナルコンピュータ１２０等が含まれる。システムバス１２３は、様々なバスアーキテクチャの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造の任意のものであることが可能である。システムメモリは、読取り専用メモリ（ＲＯＭ）１２４、およびランダムアクセスメモリ（ＲＡＭ）１２５を含む。始動中などに、パーソナルコンピュータ１２０内部の要素間で情報を転送するのを助ける基本ルーチンを含む基本入力／出力システム１２６（ＢＩＯＳ）が、ＲＯＭ１２４の中に記憶される。
【００２９】
パーソナルコンピュータ１２０は、ハードディスク（図示せず）に対して読取りおよび書込みを行うためのハードディスクドライブ１２７、取外し可能な磁気ディスク１２９に対して読取りおよび書込みを行うための磁気ディスクドライブ１２８、およびＣＤ−ＲＯＭ、または他の光媒体などの取外し可能な光ディスク１３１に対して読取りおよび書込みを行うための光ディスクドライブ１３０をさらに含むことが可能である。ハードディスクドライブ１２７、磁気ディスクドライブ１２８、および光ディスクドライブ１３０は、それぞれ、ハードディスクドライブインターフェース１３２、磁気ディスクドライブインターフェース１３３、および光ドライブインターフェース１３４でシステムバス１２３に接続される。以上のドライブ、および関連するコンピュータ可読媒体により、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの不揮発性ストレージがパーソナルコンピュータ２０に提供される。
【００３０】
本明細書で説明する例としての実施形態は、ハードディスク、取外し可能な磁気ディスク１２９、および取外し可能な光ディスク１３１を使用するが、コンピュータがアクセスすることが可能なデータを記憶することができる他のタイプのコンピュータ可読媒体も、例としての動作環境において使用できることを理解されたい。そのような他のタイプの媒体には、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）等が含まれる。
【００３１】
オペレーティングシステム１３５、１つまたは複数のアプリケーションプログラム１３６、その他のプログラムモジュール１３７、およびプログラムデータ１３８を含め、いくつかのプログラムモジュールをハードディスク、磁気ディスク１２９、光ディスク１３１、ＲＯＭ１２４、またはＲＡＭ１２５に記憶することができる。ユーザは、キーボード１４０やポインティングデバイス１４２などの入力デバイスを介してパーソナルコンピュータ１２０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ等が含まれることが可能である。以上の入力デバイス、およびその他の入力デバイスは、しばしば、システムバスに結合されたシリアルポートインターフェース１４６を介して処理ユニット１２１に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ｕｎｉｖｅｒｓａｌ　ｓｅｒｉａｌ　ｂｕｓ）（ＵＳＢ）などの他のインターフェースで接続してもよい。また、モニタ１４７、または他のタイプの表示デバイスも、ビデオアダプタ１４８などのインターフェースを介してシステムバス１２３に接続される。モニタ１４７に加えて、パーソナルコンピュータは、通常、スピーカやプリンタなどの他の周辺出力デバイス（図示せず）も含む。また、図１２の例としてのシステムは、ホストアダプタ１５５、スモールコンピュータシステムインターフェース（Ｓｍａｌｌ　Ｃｏｍｐｕｔｅｒ　Ｓｙｓｔｅｍ　Ｉｎｔｅｒｆａｃｅ）（ＳＣＳＩ）バス１５６、およびＳＣＳＩバス１５６に接続された外部記憶デバイス１６２も含む。
【００３２】
パーソナルコンピュータ１２０は、遠隔コンピュータ１４９のような１つまたは複数の遠隔コンピュータに対する論理接続を使用するネットワーク化された環境において動作することが可能である。遠隔コンピュータ１４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードであることが可能であり、通常、パーソナルコンピュータ１２０に関連して前述した要素の多く、またはすべてを含むが、図１２では、メモリ記憶デバイス１５０だけを示している。図１２に描いた論理接続は、ローカルエリアネットワーク（ＬＡＮ）１５１、およびワイドエリアネットワーク（ＷＡＮ）１５２を含む。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータ網、イントラネット、およびインターネットで一般的である。
【００３３】
ＬＡＮネットワーキング環境で使用されるとき、パーソナルコンピュータ１２０は、ネットワークインターフェース、またはネットワークアダプタ１５３を介してＬＡＮ１５１に接続される。ＷＡＮネットワーキング環境で使用されるとき、パーソナルコンピュータ１２０は、通常、インターネットなどのワイドエリアネットワーク１５２を介して通信を確立するためのモデム１５４、または他の手段を含む。内部にあることも、外部にあることも可能なモデム１５４は、シリアルポートインターフェース１４６を介してシステムバス１２３に接続される。ネットワーク化された環境では、パーソナルコンピュータ１２０に関連して描いたプログラムモジュール、またはプログラムモジュールの部分が、遠隔メモリ記憶デバイスの中に記憶されることが可能である。図示したネットワーク接続は、例としてのものであり、コンピュータ間で通信リンクを確立する他の手段も使用できることが理解されよう。
【００３４】
アーキテクチャ
図１を再び参照すると、本発明の一実施形態では、アーキテクチャ１０が、オーサリングツール（ａｕｔｈｏｒｉｎｇ　ｔｏｏｌ）１８、コンテンツ−鍵データベース２０、コンテンツサーバ２２、ライセンスサーバ２４、およびブラックボックスサーバ２６、ならびに前述したユーザのコンピューティングデバイス１４を含む。
【００３５】
アーキテクチャ−オーサリングツール１８
オーサリングツール１８は、デジタルコンテンツ１２をパッケージ化して、本発明のアーキテクチャ１０に関連して使用するのに適した形態にするためにコンテンツ所有者によって使用される。詳細には、コンテンツ所有者が、デジタルコンテンツ１２、デジタルコンテンツ１２に付随すべき命令および／または規則、およびデジタルコンテンツ１２がどのようにパッケージ化されるべきかに関する命令および／または規則をオーサリングツール１８に提供する。次に、オーサリングツール１８が、暗号化／暗号解読鍵、およびデジタルコンテンツ１２に付随する命令および／または規則に従ってデジタルコンテンツ１２が暗号化されたデジタルコンテンツパッケージ１２ｐを生成する。
【００３６】
本発明の一実施形態では、オーサリングツール１８は、異なる暗号化／暗号解読鍵に従って暗号化された同一のデジタルコンテンツ１２をそれぞれが有するいくつかの異なるデジタルコンテンツ１２パッケージ１２ｐを連続的に生成するように命令される。理解されるべきこととして、同一のデジタルコンテンツ１２を有するいくつかの異なるパッケージ１２ｐを有することは、パッケージ１２ｐ／コンテンツ１２（以降、別段、必要とされない限り、単に「デジタルコンテンツ１２」）の配布を追跡するのに役立つ可能性がある。そのような配布追跡は、通常、必要ないが、デジタルコンテンツ１２が違法に販売された、または放送された場合、調査機関によって使用されることが可能である。
【００３７】
本発明の一実施形態では、デジタルコンテンツ１２を暗号化する暗号化／暗号解読鍵は、暗号化鍵が暗号解読鍵（ＫＤ）でもあることで、対称鍵である。以下により詳細に述べる通り、暗号解読鍵（ＫＤ）は、デジタルコンテンツ１２に関するライセンス１６の一部として隠された形態でユーザのコンピューティングデバイス１４に送られる。好ましくは、各デジタルコンテンツ１２は、コンテンツＩＤを備え（または各パッケージ１２ｐが、パッケージＩＤを備え）、各暗号解読鍵（ＫＤ）が、鍵ＩＤを有し、またオーサリングツール１８により、各デジタルコンテンツ１２（または各パッケージ１２ｐ）に関する暗号解読鍵（ＫＤ）、鍵ＩＤ、およびコンテンツＩＤ（またはパッケージＩＤ）が、コンテンツ−鍵データベース２０の中に記憶させられる。さらに、デジタルコンテンツ１２に関して発行されるライセンス１６のタイプに関するライセンスデータ、および各タイプのライセンス１６に関する条項および条件が、コンテンツ−鍵データベース２０、あるいは別のデータベース（図示せず）の中に記憶されることが可能である。好ましくは、ライセンスデータは、状況、および市場の条件によって必要となるに応じて、コンテンツ所有者によって変更されることが可能である。
【００３８】
使用時に、オーサリングツール１８には、とりわけ、以下を含む情報が供給される。
【００３９】
−パッケージ化されるべきデジタルコンテンツ１２、
−透かし入れ（ｗａｔｅｒｍａｒｋｉｎｇ）、および／または指紋入れ（ｆｉｎｇｅｒｐｒｉｎｔｉｎｇ）が使用される場合、透かし入れ、および／または指紋入れのタイプおよびパラメータ、
−データ圧縮が使用される場合、データ圧縮のタイプおよびパラメータ、
−使用される暗号化のタイプおよびパラメータ、
−シリアル化（ｓｅｒｉａｌｉｚａｔｉｏｎ）が使用される場合、シリアル化のタイプおよびパラメータ、および
−デジタルコンテンツ１２に付随すべき命令および／または規則。
【００４０】
周知の通り、透かしは、識別子としてデジタルコンテンツ１２に追加される、隠されたコンピュータ可読の信号である。指紋は、各インスタンスに関して異なる透かしである。理解されるべきこととして、インスタンスは、固有であるデジタルコンテンツ１２のバージョンである。任意のインスタンスの複数のコピーを作成することができ、またあらゆるコピーは、特定のインスタンスのものである。デジタルコンテンツの特定のインスタンスが違法に販売された、または放送されたとき、調査機関が、場合により、デジタルコンテンツ１２に追加された透かし／指紋に従って容疑者を特定することが可能である。
【００４１】
データ圧縮は、本発明の趣旨および範囲を逸脱することなく、任意の適切な圧縮アルゴリズムに従って行われることが可能である。例えば、．ｍｐ３圧縮アルゴリズム、または．ｗａｖ圧縮アルゴリズムを使用することができる。もちろん、デジタルコンテンツ１２が、既に圧縮された状態にあることも可能であり、その場合、さらなる圧縮は必要ない。
【００４２】
デジタルコンテンツ１２に付随すべき命令および／または規則には、本発明の趣旨および範囲を逸脱することなく、実質的にあらゆる適切な命令、規則、または他の情報が含まれることが可能である。以下に述べる通り、付随する命令／規則／情報は、主に、デジタルコンテンツ１２をレンダリングするライセンス１６を獲得するためにユーザ、およびユーザのコンピューティングデバイス１４によって使用される。したがって、付随する命令／規則／情報には、以下により詳細に説明する通り、適切にフォーマットされたライセンス獲得スクリプト等が含まれることが可能である。追加として、または別法として、付随する命令／規則／情報には、ユーザにデジタルコンテンツ１２のプレビューを提供するように設計された「プレビュー」情報が含まれることが可能である。
【００４３】
供給された情報を使用して、オーサリングツール１８は、デジタルコンテンツ１２に対応する１つまたは複数のパッケージ１２ｐを生成する。次に、各パッケージ１２ｐを世界に配布するためにコンテンツサーバ２２上に記憶することができる。
【００４４】
本発明の一実施形態では、図２を参照すると、オーサリングツール１８は、指定し、操作することが可能な入力パラメータを受け取る動的オーサリングツール１８である。したがって、オーサリングツール１８は、複数のデジタルコンテンツ１２に関して複数の変種のパッケージ１２ｐを迅速に生成することができる。好ましくは、入力パラメータは、図示する通り、情報２８の形態で実現され、辞書２８は、以下のようなパラメータを含む。
【００４５】
−デジタルコンテンツ１２を有する入力ファイル２９ａの名前、
−行われるべき符号化のタイプ、
−使用されるべき暗号化／暗号解読鍵（ＫＤ）、
−デジタルコンテンツ１２とともにパッケージ１２ｐの中にパッケージ化されるべき付随する命令／規則／情報（「ヘッダ情報」）、
−行われるべき多重化（ｍｕｘｉｎｇ）のタイプ、および
−デジタルコンテンツ１２に基づいてパッケージ１２ｐが書き込まれるべき出力ファイル２９ｂの名前。
【００４６】
理解されるべきこととして、辞書２８は、オーサリングツール１８のオペレータ（人間またはマシン）によって容易かつ迅速に変更可能であり、したがって、オーサリングツール１８によって行われるオーサリングのタイプも同様に、動的な仕方で容易かつ迅速に変更可能である。本発明の一実施形態では、オーサリングツール１８は、人間のオペレータに対してコンピュータスクリーン上で表示可能なオペレータインターフェース（図示せず）を含む。したがって、オペレータは、そのインターフェースを使用して辞書２８を変更することができ、またさらに、そのインターフェースを使用して辞書２８を変更する際に適切な支援および／または制限を受けることが可能である。
【００４７】
オーサリングツール１８内部で、図２に見られる通り、ソースフィルタ１８ａが、デジタルコンテンツ１２を有する入力ファイル２９ａを辞書２８から受け取り、その入力ファイルからデジタルコンテンツ１２を取得して、デジタルコンテンツ１２をＲＡＭなどのメモリ２９ｃの中に入れる。次に、符号化フィルタ１８ｂが、メモリ２９ｃの中のデジタルコンテンツ１２に対して符号化を行い、辞書２８の中で指定される符号化のタイプに従ってファイルを入力形式から出力形式に（すなわち、．ｗａｖから．ａｓｐに、．ｍｐ３から．ａｓｐになど）転換し、符号化されたデジタルコンテンツ１２をメモリ２９ｃの中に入れる。図示する通り、パッケージ化されるべきデジタルコンテンツ（例えば、音楽）が、．ｗａｖ形式または．ｍｐ３形式などの圧縮された形式で受け取られ、．ａｓｐ（アクティブストリーミングプロトコル（ａｃｔｉｖｅ　ｓｔｒｅａｍｉｎｇ　ｐｒｏｔｏｃｏｌ））形式などの形式に変換される。もちろん、本発明の趣旨および範囲を逸脱することなく、他の入力形式および出力形式を使用することができる。
【００４８】
その後、暗号化フィルタ１８ｃが、辞書２８の中で指定された暗号化／暗号解読鍵（ＫＤ）に従ってメモリ２９ｃの中の符号化されたデジタルコンテンツ１２を暗号化し、暗号化されたデジタルコンテンツ１２をメモリ２９ｃの中に入れる。次に、ヘッダフィルタ１８ｄが、辞書２８の中で指定されたヘッダ情報をメモリ２９ｃの中の暗号化されたデジタルコンテンツ１２に追加する。
【００４９】
理解されるべきこととして、状況に応じて、パッケージ１２ｐは、複数のストリームが多重化された（すなわち、「ｍｕｘ処理」された）時間的に揃えられたデジタルコンテンツ１２の複数のストリーム（図２では、１つのストリームを示している）を含むことが可能である。したがって、多重化フィルタ（ｍｕｘ　ｆｉｌｔｅｒ）１８ｅが、辞書２８の中で指定された多重化のタイプに従ってメモリ２９ｃの中のヘッダ情報および暗号化されたデジタルコンテンツ１２に対して多重化を行い、その結果をメモリ２９ｃの中に入れる。次に、ファイルライタフィルタ（ｆｉｌｅ　ｗｒｉｔｅｒ　ｆｉｌｔｅｒ）１８ｆが、その結果をメモリ２９ｃから取得し、辞書２８の中で指定された出力ファイル２９ｂにその結果をパッケージ１２ｐとして書き込む。
【００５０】
ある状況では、行われるべき符号化のタイプは、通常、変化しないことに留意されたい。多重化のタイプは、通常、符号化のタイプに基づくので、同様に、多重化のタイプも、変化しないことが通例である。実際に変化しない場合、辞書２８は、符号化のタイプおよび／または多重化のタイプに関するパラメータを含む必要がない。実際、符号化のタイプが、符号化フィルタの中に「配線によって組まれ（ｈａｒｄｗｉｒｅｄ）」、かつ／または多重化のタイプが、多重化フィルタの中に「配線によって組まれる」だけでよい。もちろん、本発明の趣旨および範囲を逸脱することなく、状況によって必要とされるのに応じて、オーサリングツール１８は、前述したフィルタのすべてを含むこと、または他のフィルタを含むことが可能であり、またあらゆる含まれるフィルタが、配線によって組まれる、または辞書２８の中で指定されたパラメータに従って機能を行うことが可能である。
【００５１】
好ましくは、オーサリングツール１８は、適切なソフトウェアを使用して適切なコンピュータ上、プロセッサ上、または他のコンピューティングマシン上に実装される。そのようなマシン、およびそのようなソフトウェアの構造および動作は、本明細書の開示に基づいて明白であるはずであり、したがって、本開示において詳述することは必要ない。
【００５２】
アーキテクチャ−コンテンツサーバ２２
図１を再び参照すると、本発明の一実施形態では、コンテンツサーバ２２が、オーサリングツール１８によって生成されたパッケージ１２ｐを配信するか、または別の形で取得のために供与する。パッケージ１２ｐは、本発明の趣旨および範囲を逸脱することなく、コンテンツサーバ２２が要求するのに応じて任意の適切な配信チャネルを使用して配信されることが可能である。例えば、配信チャネルは、インターネットまたは別のネットワーク、電子掲示板、電子メール等であることが可能である。コンテンツサーバ２２を使用してパッケージ１２ｐを磁気ディスク、または光ディスク、あるいはその他の記憶デバイスにコピーすることができ、次に、記憶デバイスを配布することができる。
【００５３】
コンテンツサーバ２２は、信頼問題またはセキュリティ問題を顧慮せずにパッケージ１２ｐを配信することが認められよう。以下で述べる通り、そのような問題は、ライセンスサーバ２４、およびライセンスサーバ２４とユーザの記憶デバイス１４の間の関係に関連して対処される。本発明の一実施形態では、コンテンツサーバ２２は、デジタルコンテンツ１２を要求するあらゆる配信先（ｄｉｓｔｒｉｂｕｔｅｅ）にデジタルコンテンツ１２を有するパケット１２ｐを自由にリリースし、配信する。ただし、コンテンツサーバ２２は、配信に先立って所定の配信料の支払いをまず要求する、あるいは配信先が自らを認証することを要求する、あるいは実際に、配信先の識別に基づいて配信が行われるべきかどうかを決定することが可能である。
【００５４】
さらに、予期されるデマンドを満たすように事前にいくつかの異なるパッケージ１２ｐを生成するようにオーサリングツール１８を制御することにより、コンテンツサーバ２２を使用してインベントリ（ｉｎｖｅｎｔｏｒｙ）管理を行うことができる。例えば、サーバは、同一のデジタルコンテンツ１２に基づいて１００のパッケージを生成し、各パッケージ１２ｐを１０回、提供することが可能である。例えば、パッケージ１２ｐの供給が、２０まで減少すると、コンテンツサーバ２２は、やはり例として、８０のさらなるパッケージ１２ｐを生成するようにオーサリングツール１８を導くことができる。
【００５５】
好ましくは、アーキテクチャ１０におけるコンテンツサーバ２２は、以下により詳細に説明する通り、ライセンス１６を評価し、対応するデジタルコンテンツ１２を解読するための暗号解読鍵（ＫＤ）を獲得するプロセスの一環として使用される固有の公開鍵／秘密鍵ペア（ＰＵ−ＣＳ、ＰＲ−ＣＳ）を有する。周知の通り、公開鍵／秘密鍵ペアは、鍵ペアの鍵の１つで暗号化されたものが、鍵ペアの鍵の他方によってだけ解読することができることで、非対称鍵である。公開鍵／秘密鍵ペア暗号化システムでは、公開鍵は、世界に知らせてもよいが、秘密鍵は、秘密鍵の所有者によって常に秘密に保たれなければならない。したがって、コンテンツサーバ２２は、秘密鍵（ＰＲ−ＣＳ）を使用してデータを暗号化した場合、暗号解読の目的で、公開鍵（ＰＵ−ＣＳ）とともにその暗号化されたデータを世界に送り出すことができる。したがって、外部デバイスが、コンテンツサーバ２２だけがデータを解読することができるようにデータをコンテンツサーバ２２に送ることを望む場合、外部デバイスは、まず、そのコンテンツサーバ２２の公開鍵（ＰＵ−ＣＳ）を獲得し、次に、その公開鍵を使用してデータを暗号化しなければならない。したがって、次に、コンテンツサーバ２２が（また、コンテンツサーバ２２だけが）、その秘密鍵（ＰＲ−ＣＳ）を使用して暗号化されたデータを解読することができる。
【００５６】
オーサリングツール１８と同様に、コンテンツサーバ２２も、適切なソフトウェアを使用して適切なコンピュータ上、プロセッサ上、またはその他のコンピューティングマシン上で実装される。そのようなマシンおよびそのようなソフトウェアの構造および動作は、本明細書の開示に基づいて明白であるはずであり、したがって、本開示で詳述することは必要ない。本発明の一実施形態では、オーサリングツール１８、およびコンテンツサーバ２２が、それぞれ別個の作業スペース内で、単一のコンピュータ上、単一のプロセッサ上、または単一の他のコンピューティングマシン上に常駐することが可能である。さらに、コンテンツサーバ２２は、ある状況では、前述した通り、オーサリングツール１８を含むことが可能であり、かつ／またはオーサリングツール１８の機能を行うことが可能であることを認識されたい。
【００５７】
デジタルコンテンツパッケージ１２ｐの構造
次に、図３を参照すると、本発明の一実施形態では、コンテンツサーバ２２によって配信されるデジタルコンテンツパッケージ１２ｐが、以下のものを含む。
【００５８】
−前述した通り、暗号化／暗号解読鍵（ＫＤ）を使用して暗号化されたデジタルコンテンツ１２（すなわち、（ＫＤ（ＣＯＮＴＥＮＴ）））、
−デジタルコンテンツ１２（またはパッケージ１２ｐ）のコンテンツＩＤ（またはパッケージＩＤ）、
−暗号解読鍵（ＫＤ）の鍵ＩＤ、
−好ましくは、暗号化されていない形態のライセンス獲得情報、および
−コンテンツサーバ２２秘密鍵（ＰＲ−ＣＳ）で署名されたコンテンツサーバ２２公開鍵（ＰＵ−ＣＳ）を暗号化する鍵ＫＤ（すなわち、（ＫＤ（ＰＵ−ＣＳ）Ｓ（ＰＲ−ＣＳ）））。
【００５９】
（ＫＤ（ＰＵ−ＣＳ）Ｓ（ＰＲ−ＣＳ））に関して、このアイテムは、以下に説明する通り、デジタルコンテンツ１２および／またはパッケージ１２ｐを検証することに関連して使用されることを理解されたい。デジタル署名（以下を参照）を有する証明書とは異なり、（ＫＤ（ＰＵ−ＣＳ））を得るのに鍵（ＰＵ−ＣＳ）は必要ない。代わりに、鍵（ＰＵ−ＣＳ）は、単に暗号解読鍵を適用することによって獲得される。獲得されると、その鍵（ＰＣ−ＣＳ）を使用して署名（Ｓ（ＰＲ−ＣＳ））の有効性を試験することができる。
【００６０】
また、パッケージ１２ｐがオーサリングツール１８によって構成されるには、オーサリングツール１８が、想定では、辞書２８によって供給されるヘッダ情報として、ライセンス獲得情報、および（ＫＤ（ＰＵ−ＣＳ）Ｓ（ＰＲ−ＣＳ））を既に所有していなければならない。さらに、オーサリングツール１８とコンテンツサーバ２２が、想定では、（ＫＤ（ＰＵ−ＣＳ）Ｓ（ＰＲ−ＣＳ））を構成するように対話しなければならない。この対話は、例えば、以下のステップを含むことが可能である。
【００６１】
−（ＰＵ−ＣＳ）をオーサリングツール１８に送るコンテンツサーバ２２、
−（ＫＤ）を使用して（ＰＵ−ＣＳ）を暗号化して（ＫＤ（ＰＵ−ＣＳ））を生成するオーサリングツール１８、
−（ＫＤ（ＰＵ−ＣＳ））をコンテンツサーバ２２に送るオーサリングツール１８、
−（ＰＲ−ＣＳ）を使用して（ＫＤ（ＰＵ−ＣＳ））に署名して（ＫＤ（ＰＵ−ＣＳ）Ｓ（ＰＲ−ＣＳ））を生成するコンテンツサーバ２２、および
−（ＫＤ（ＰＵ−ＣＳ）Ｓ（ＰＲ−ＣＳ））をオーサリングツール１８に送るコンテンツサーバ２２。
【００６２】
アーキテクチャ−ライセンスサーバ２４
図１を再び参照すると、本発明の一実施形態では、ライセンスサーバ２４が、デジタルコンテンツ１２に関連してユーザのコンピューティングデバイス１４からライセンス１６の要求を受け取る機能、ユーザのコンピューティングデバイス１４が、発行されたライセンス１６を遵守するものとして信頼できるかどうかを判定する機能、ライセンス１６を交渉する機能、ライセンス１６を構成する機能、およびライセンス１６をユーザのコンピューティングデバイス１４に伝送する機能を行う。好ましくは、伝送されるライセンス１６は、デジタルコンテンツ１２を解読するための暗号解読鍵（ＫＤ）を含む。このライセンスサーバ２４、および以上の機能を以下により詳細に説明する。好ましくは、コンテンツサーバ２２と同様に、アーキテクチャ１０におけるライセンスサーバ２４は、以下により詳細に説明する通り、ライセンス１６を評価し、対応するデジタルコンテンツ１２を解読するための暗号解読鍵（ＫＤ）を獲得するプロセスの一環として使用される固有の公開鍵／秘密鍵ペア（ＰＵ−ＬＳ、ＰＲ−ＬＳ）を有する。
【００６３】
オーサリングツール１８およびコンテンツサーバ２２と同様に、ライセンスサーバ２４は、適切なソフトウェアを使用して適切なコンピュータ上、プロセッサ上、または他のコンピューティングマシン上に実装される。そのようなマシンおよびそのようなソフトウェアの構造および動作は、本明細書の開示に基づいて明白であるはずであり、したがって、本開示において詳述するまでもないない。さらに、本発明の一実施形態では、オーサリングツール１８および／またはコンテンツサーバ２２が、ライセンスサーバ２４とともに、それぞれ別個の作業スペース内で、単一のコンピュータ上、単一のプロセッサ上、または単一の他のコンピューティングマシン上に常駐することが可能である。
【００６４】
本発明の一実施形態では、ライセンス１６の発行に先立って、ライセンスサーバ２４とコンテンツサーバ２２は、ライセンスサーバ２４が、実際に、コンテンツサーバ２２によって配信されるデジタルコンテンツ１２の少なくとも一部分に関してライセンス機関（ｌｉｃｅｎｓｉｎｇ　ａｕｔｈｏｒｉｔｙ）となることに合意する代理契約（ａｇｅｎｃｙ　ａｇｒｅｅｍｅｎｔ）等を結ぶ。理解されるべきこととして、本発明の趣旨および範囲を逸脱することなく、１つのコンテンツサーバ２２が、いくつかのライセンスサーバ２４と代理契約等を結ぶことができ、かつ／または１つのライセンスサーバ２４が、いくつかのコンテンツサーバ２２と代理契約等を結ぶことができる。
【００６５】
好ましくは、ライセンスサーバ２４は、実際に、自らが、コンテンツサーバ２２によって配信されるデジタルコンテンツ１２に関するライセンス１６を発行する権限を有することを世界に示すことができる。これを行うため、ライセンスサーバ２４が、コンテンツサーバ２２にライセンスサーバ２４公開鍵（ＰＵ−ＬＳ）を送り、また次に、コンテンツサーバ２２が、ライセンスサーバ２４に、コンテンツサーバ２２秘密鍵で署名されたコンテンツ（ＣＥＲＴ（ＰＵ−ＬＳ）Ｓ（ＰＲ−ＣＳ））としてＰＵ−ＬＳを含むデジタル証明書を送ることが好ましい。理解されるべきこととして、証明書の中のコンテンツ（ＰＵ−ＬＳ）には、コンテンツサーバ２２公開鍵（ＰＵ−ＣＳ）を使用してだけアクセスすることが可能である。やはり理解されるべきこととして、一般に、基底のデータのデジタル署名は、そのデータの暗号化された形態であり、そのデータが改ざんされている場合、または別の仕方で変更されている場合、そのデータにマッチしない。
【００６６】
デジタルコンテンツ１２に関連するライセンス機関として、またライセンス機能の一環として、ライセンスサーバ２４は、デジタルコンテンツ１２に関する暗号解読鍵（ＫＤ）へのアクセスを有さなければならない。したがって、ライセンスサーバ２４が、デジタルコンテンツ１２（またはパッケージ１２ｐ）に関する暗号解読鍵（ＫＤ）、鍵ＩＤ、およびコンテンツＩＤ（またはパッケージＩＤ）を有するコンテンツ鍵データベース２０にアクセスを有することが好ましい。
【００６７】
アーキテクチャ−ブラックボックスサーバ２６
やはり図１を参照すると、本発明の一実施形態では、ブラックボックスサーバ２６が、ユーザのコンピューティングデバイス１４における新しいブラックボックス３０をインストールする機能、および／またはアップグレードする機能を行う。以下により詳細に説明する通り、ブラックボックス３０は、ユーザのコンピューティングデバイス１４のために暗号化機能、および暗号解読機能を行う。やはり、以下により詳細に説明する通り、ブラックボックス３０は、攻撃に対してセキュアであり、保護されているものとされる。このセキュリティおよび保護は、以下により詳細に説明する通り、少なくともある程度、ブラックボックスサーバ２６を使用して、必要に応じて、ブラックボックス３０を新しいバージョンにアップグレードすることによって提供される。
【００６８】
オーサリングツール１８と同様に、コンテンツサーバ２２、ライセンスサーバ２４、およびブラックボックスサーバ２６は、適切なソフトウェアを使用して適切なコンピュータ上、プロセッサ上、または他のコンピューティングマシン上に実装される。そのようなマシンおよびそのようなソフトウェアの構造および動作は、本明細書の開示に基づいて明白であるはずであり、したがって、本開示において詳述することは必要ない。さらに、本発明の一実施形態では、ライセンスサーバ２４、オーサリングツール１８、および／またはコンテンツサーバ２２が、それぞれ別個の作業スペース内で、ブラックボックスサーバ２６とともに、単一のコンピュータ上、単一のプロセッサ上、または単一の他のコンピューティングマシン上に常駐することが可能である。ただし、セキュリティ上の目的で、ブラックボックスサーバ２６を別個のマシン上に有することが賢明である可能性があることに留意されたい。
【００６９】
次に、図４を参照すると、本発明の一実施形態では、ユーザのコンピューティングデバイス１４は、キーボード、マウス、スクリーン、プロセッサ、ＲＡＭ、ＲＯＭ、ハードドライブ、フロッピー（登録商標）ドライブ、ＣＤプレーヤ、および／または以上に類するものを含む要素を有するパーソナルコンピュータ等である。ただし、ユーザのコンピューティングデバイス１４は、本発明の趣旨および範囲を逸脱することなく、とりわけ、テレビジョンまたはモニタなどの専用ビューイング（ｖｉｅｗｉｎｇ）デバイス、ステレオプレーヤ、またはその他の音楽プレーヤなどの専用オーディオデバイス、専用プリンタ等であることも可能である。
【００７０】
デジタルコンテンツ１２のコンテンツ所有者は、ユーザのコンピューティングデバイス１４が、コンテンツ所有者自身が指定した規則を遵守すること、すなわち、求める仕方でレンダリングを可能にするライセンス１６をユーザが獲得しない限り、デジタルコンテンツ１２がレンダリングされないことを信頼しなければならない。したがって、好ましくは、ユーザのコンピューティングデバイス１４は、デジタルコンテンツ１２に関連し、ユーザによって獲得されるライセンス１６で実現されるライセンス規則に従ってでなければ、デジタルコンテンツ１２をレンダリングしないことをコンテンツ所有者に確信させることができる信頼される構成要素、または信頼されるメカニズム３２を提供しなければならない。
【００７１】
この場合、信頼されるメカニズム３２は、デジタルコンテンツ１２がレンダリングされることをユーザが要求したときにイネーブルにされ、求める仕方でデジタルコンテンツ１２をレンダリングするライセンス１６をユーザが有するかどうかを判定し、必要な場合、そのライセンス１６を獲得することを実行し、ユーザが、デジタルコンテンツ１２を再生する権利を有するかどうかをライセンス１６に従って判定し、また、ライセンス１６に従ってユーザがそのような権利を実際に有する場合、レンダリング目的でデジタルコンテンツ１２を解読するデジタル権利管理（ＤＲＭ）システム３２である。ユーザのコンピューティングデバイス１４上の、アーキテクチャ１０に関連するＤＲＭシステム３２の内容および機能を以下に説明する。
【００７２】
ＤＲＭシステム３２
ＤＲＭシステム３２は、本明細書に開示するアーキテクチャ１０を使用して以下の４つの主な機能を行う。すなわち、（１）コンテンツ獲得、（２）ライセンス獲得、（３）コンテンツレンダリング、および（４）ブラックボックス３０インストール／更新である。好ましくは、以上の機能の任意のものが、任意の時点で行われることが可能である。ただし、機能のいくつかは、デジタルコンテンツ１２が獲得されることを既に必要とすることが認められる。
【００７３】
ＤＲＭシステム３２−コンテンツ獲得
ユーザおよび／またはユーザのコンピューティングデバイス１４によるデジタルコンテンツ１２の獲得は、通常、比較的簡単なことであり、一般に、暗号化されたデジタルコンテンツ１２を有するファイルをユーザのコンピューティングデバイス１４上に置くことに関わる。もちろん、本明細書で開示するアーキテクチャ１０、およびＤＲＭシステム３２で機能するには、暗号化されたデジタルコンテンツ１２が、以下に説明する通り、デジタルパケット１２ｐなどの、アーキテクチャ１０およびＤＲＭシステム３２に適する形態になっていることが必要である。
【００７４】
理解されるべきこととして、デジタルコンテンツ１２は、本発明の趣旨および範囲を逸脱することなく、直接に、または間接的に、コンテンツサーバ２２から任意の仕方で獲得することが可能である。例えば、デジタルコンテンツ１２は、インターネットなどのネットワークからダウンロードされること、獲得された光ディスクまたは磁気ディスク等の上に存在すること、電子メール等の一部として受信されること、または電子掲示板等からダウンロードされることが可能である。
【００７５】
デジタルコンテンツ１２は、獲得されると、好ましくは、コンピューティングデバイス１４上で実行されるレンダリングアプリケーション３４（以下に説明する）によって、またはＤＲＭシステム３２によってアクセス可能であるように記憶される。例えば、デジタルコンテンツ１２は、ユーザのコンピューティングデバイス１４のハードドライブ（図示せず）上、またはコンピューティングデバイス１４がアクセス可能なネットワークサーバ（図示せず）上のファイルとして配置することが可能である。デジタルコンテンツ１２が、光ディスク上または磁気ディスク上などで獲得される場合、そのディスクが、ユーザのコンピューティングデバイス１４に結合された適切なドライブ（図示せず）の中に存在するだけでよい可能性がある。
【００７６】
本発明では、直接の配布ソースとしてのコンテンツサーバ２２からも、間接の配布ソースとしての何らかの仲介役からも、デジタルコンテンツ１２を獲得するのに特別なツールが必要であることを全く想定していない。つまり、デジタルコンテンツ１２が、他のあらゆるデータファイルと同様に容易に獲得されることが好ましい。ただし、ＤＲＭシステム３２および／またはレンダリングアプリケーション３４は、ユーザがデジタルコンテンツ１２を獲得するのを支援するように設計されたインターフェース（図示せず）を含むことが可能である。例えば、このインターフェースは、デジタルコンテンツ１２を探索すること、デジタルコンテンツ１２のソースであることが分かっている事前定義されたインターネットＷｅｂサイトにリンクすること等を行うように特に設計されたＷｅｂブラウザを含むことが可能である。
【００７７】
ＤＲＭシステム３２−コンテンツレンダリング、第１部
次に、図５Ａを参照すると、本発明の一実施形態では、暗号化されたデジタルコンテンツ１２が、ユーザに配布されて受け取られ、ユーザによって記憶されたファイルの形態でコンピューティングデバイス１４上に置かれたものと想定して、ユーザが、レンダリングコマンドの何らかの変種を実行することにより、デジタルコンテンツ１２をレンダリングしようと試みる（ステップ５０１）。例えば、そのようなレンダリングコマンドは、デジタルコンテンツ１２を「再生する」要求、または「開く」要求として実現することができる。例えば、ワシントン州レッドモンドのマイクロソフトコーポレーションによって販売される「ＭＩＣＲＯＳＯＦＴ　ＷＩＮＤＯＷＳ（登録商標）」オペレーティングシステムなどの一部のコンピューティング環境では、この再生コマンド、または開くコマンドは、単にデジタルコンテンツ１２を表すアイコン上で「クリックする」程度の簡単なものであることが可能である。もちろん、本発明の趣旨および範囲を逸脱することなく、レンダリングコマンドの他の実施形態も使用することができる。一般に、レンダリングコマンドは、ユーザが、デジタルコンテンツ１２を有するファイルが開かれ、遂行され、実行され、かつ／または以上に類することが行われるように指示したときにはいつでも、実行されるものと見なすことができる。
【００７８】
重要なことには、さらに、レンダリングコマンドは、デジタルコンテンツ１２を、印刷された形態、ビジュアル形態、オーディオ形などの別の形態にコピーする要求として実現することができる。理解されるべきこととして、同一のデジタルコンテンツ１２を、コンピュータスクリーン上などのある形態でレンダリングし、次に、印刷されたドキュメントなどの別の形態でレンダリングすることが可能である。本発明では、各タイプのレンダリングは、以下に説明する通り、ユーザがレンダリングを行う権利を有する場合にだけ行われる。
【００７９】
本発明の一実施形態では、デジタルコンテンツ１２は、拡張子で終わるファイル名を有するデジタルファイルの形態になっており、コンピューティングデバイス１４が、その拡張子に基づいて特定の種類のレンダリングアプリケーション３４を開始することを決めることができる。例えば、ファイル名＊＊＊が、デジタルコンテンツ１２がテキストファイルであることを示す場合、レンダリングアプリケーション３４は、ワシントン州レッドモンドのマイクロソフトコーポレーションによって販売される「ＭＩＣＲＯＳＯＦＴ　ＷＯＲＤ」などの何らかの形態のワードプロセッサである。同様に、ファイル名＊＊＊が、デジタルコンテンツ１２がオーディオファイル、ビデオファイル、および／またはマルチメディアファイルであることを示す場合、レンダリングアプリケーション３４は、やはり、ワシントン州レッドモンドのマイクロソフトコーポレーションによって販売される「ＭＩＣＲＯＳＯＦＴ　ＭＥＤＩＡ　ＰＬＡＹＥＲ」などの何らかの形態のマルチメディアプレーヤである。
【００８０】
もちろん、本発明の趣旨および範囲を逸脱することなく、レンダリングアプリケーションを決める他の方法を使用することも可能である。単に一例として、デジタルコンテンツ１２は、そのデジタルコンテンツ１２をレンダリングするのに必要なレンダリングアプリケーション３４のタイプに関する情報を含むメタデータを暗号化されていない形態（すなわち、前述したヘッダ情報の形態）で含むことが可能である。
【００８１】
好ましくは、レンダリングアプリケーション３４は、ファイル名に関連するデジタルコンテンツ１２を検査し、そのデジタルコンテンツ１２が、権利の保護された形態で暗号化されているかどうかを判定する（ステップ５０３、５０５）。保護されていない場合、デジタルコンテンツ１２は、無造作にレンダリングすることができる（ステップ５０７）。保護されている場合、レンダリングアプリケーション３４は、暗号化されたデジタルコンテンツ１２から、そのデジタルコンテンツ１２を再生するのにＤＲＭシステム３２が必要であると判定する。したがって、レンダリングアプリケーション３４は、ユーザのコンピューティングデバイス１４が、そのデバイス１４上のＤＲＭシステム３２を実行するように導く（ステップ５０９）。次に、レンダリングアプリケーション３４は、ＤＲＭシステム３２を呼び出してデジタルコンテンツ１２を解読する（ステップ５１１）。以下により詳述する通り、ＤＲＭシステム３２は、ユーザが、デジタルコンテンツ１２に関して有効なライセンス１６を有し、その有効なライセンス１６におけるライセンス規則に従ってデジタルコンテンツ１２を再生する権利を有する場合にだけ、実際にそのデジタルコンテンツ１２を解読する。好ましくは、ＤＲＭシステム３２は、レンダリングアプリケーション３４によって呼び出された後、少なくとも、ユーザがデジタルコンテンツ１２を再生する権利を有するかどうかを判定する目的で、レンダリングアプリケーション３４から制御を引き継ぐ（ステップ５１３）。
【００８２】
本発明の一実施形態では、図４を再び参照すると、ＤＲＭシステム３２が、ライセンスイバリュエータ３６、ブラックボックス３０、ライセンスストア３８、および状態ストア４０を含む。
【００８３】
ＤＲＭシステム３２構成要素−ライセンスイバリュエータ３６
ライセンスイバリュエータ３６は、とりわけ、要求されたデジタルコンテンツ１２に対応する１つまたは複数のライセンス１６を探し出し、そのライセンス１６が有効であるかどうかを判定し、有効なライセンス１６におけるライセンス規則を検討し、検討したライセンス規則に基づき、要求側のユーザが、求める仕方で要求のデジタルコンテンツ１２をレンダリングする権利を有するかどうかを判定する。理解されるべきこととして、ライセンスイバリュエータ３６は、ＤＲＭシステム３２における信頼される構成要素である。本開示では、「信頼される」ということは、ライセンスサーバ２４（または任意の他の信頼する側の要素）が、信頼される要素が、ライセンス１６における権利記述に従ってデジタルコンテンツ１２の所有者の願いを実行すること、およびユーザが、不正な、または別の何らかの目的で信頼される要素を容易に変更できないことを確信させられることを意味する。
【００８４】
ライセンスイバリュエータ３６は、実際にライセンス１６を適切に評価することを確実にするため、またライセンス１６の実際の評価を回避する目的で、ユーザによって不正改造されている、または別の仕方で変更されていることがないことを確実にするため、信頼されなければならない。したがって、ライセンスイバリュエータ３６は、保護された環境、または覆われた環境において実行して、ライセンスイバリュエータ３６に対するユーザのアクセスが拒否されるようにする。本発明の趣旨および範囲を逸脱することなく、ライセンスイバリュエータ３６に関連して他の保護手段も使用することができる。
【００８５】
ＤＲＭシステム３２構成要素−ブラックボックス３０
主に、前述した通り、ブラックボックス３０は、ＤＲＭシステム３２において暗号化機能および暗号解読機能を行う。詳細には、ブラックボックス３０は、ライセンスイバリュエータ３６と連携して動作して、ある情報をライセンスイバリュエータ機能の一環として解読すること、および暗号化することを行う。さらに、ライセンスイバリュエータ３６が、ユーザが、求める仕方で要求のデジタルコンテンツ１２をレンダリングする権利を実際に有すると判定すると、ブラックボックス３０は、デジタルコンテンツ１２に関する暗号解読鍵（ＫＤ）の提供を受け、暗号解読鍵（ＫＤ）に基づいてデジタルコンテンツ１２の暗号解読の機能を行う。
【００８６】
ブラックボックス３０は、ＤＲＭシステム３２の信頼される構成要素でもある。詳細には、ライセンスサーバ２４が、ブラックボックス３０が、ライセンス１６におけるライセンス規則に従ってだけ暗号解読機能を行うことを信頼し、またブラックボックス３０が、ライセンス１６の実際の評価を回避するという不正な目的で、ユーザによって不正改造された、または別の仕方で変更された場合、動作しないことを信頼しなければならない。したがって、ブラックボックス３０も、保護された環境、または覆われた環境において実行して、ブラックボックス３０に対するユーザのアクセスが拒否されるようにする。この場合も、本発明の趣旨および範囲を逸脱することなく、ブラックボックス３０に関連して他の保護手段も使用することができる。好ましくは、コンテンツサーバ２２およびライセンスサーバ２４と同様に、ＤＲＭシステム３２におけるブラックボックス３０は、以下により詳細に説明する通り、ライセンス１６を評価し、デジタルコンテンツ１２を解読するための暗号解読鍵（ＫＤ）を獲得するプロセスの一環として使用される固有の公開鍵／秘密鍵ペア（ＰＵ−ＢＢ、ＰＲ−ＢＢ）を有する。
【００８７】
ＤＲＭシステム３２構成要素−ライセンスストア３８
ライセンスストア３８は、対応するデジタルコンテンツ１２に関してＤＲＭシステム３２によって受け取られたライセンス１６を記憶する。ライセンスストア３８自体は、信頼される必要はない。というのは、ライセンスストア３８は、以下に説明する通り、信頼構成要素がそれぞれ、内部に既に組み込まれていなければならないライセンス１６を単に記憶するだけだからである。本発明の一実施形態では、ライセンスストア３８は、ハードディスクドライブまたはネットワークドライブなどのドライブのサブディレクトリに過ぎない。ただし、ライセンスストア３８は、ＤＲＭシステム３２にとって比較的便利な場所にライセンス１６を記憶する機能を行う限り、本発明の趣旨および範囲を逸脱することなく、任意の他の形態で実現することができる。
【００８８】
ＤＲＭシステム３２構成要素−状態ストア４０
状態ストア４０は、現在、ライセンスストア３８の中にある、または以前にライセンスストア３８の中にあったライセンス１６に対応する状態情報を保持する機能を行う。状態情報は、ＤＲＭシステム３２によって生成され、必要に応じて状態ストア４０の中に記憶される。例えば、特定のライセンス１６により、対応するデジタルコンテンツ１２の所定回数のレンダリングだけが許される場合、状態ストア４０は、ライセンス１６に関連して何回のレンダリングが実際に行われたかに関する状態情報を保持する。状態ストア４０は、ライセンスストア３８の中にもはや存在しないライセンス１６に関する状態情報を保持しつづけて、そうでなければ、ライセンスストア３８からライセンスを削除した後、状態ストア４０から対応する状態情報を削除しようとして同一のライセンス１６を獲得することが有利である状況を回避する。
【００８９】
状態ストア４０も、内部に記憶されている情報が、ユーザにより都合の良い状態にリセットされないことを確実にするために信頼されなければならない。したがって、状態ストア４０も同様に、保護された環境、または覆われた環境において実行して、状態ストア４０に対するユーザのアクセスが拒否されるようにする。この場合も、本発明の趣旨および範囲を逸脱することなく、もちろん、他の保護手段も使用することができる。例えば、状態ストア４０は、ＤＲＭシステム３２によってコンピューティングデバイス１４上に暗号化された形態で記憶されることが可能である。
【００９０】
ＤＲＭシステム３２−コンテンツレンダリング、第２部
図５Ａを再び参照し、本発明の一実施形態におけるコンテンツレンダリングについて再び述べると、ＤＲＭシステム３２は、呼出し側のレンダリングアプリケーション３４から制御を引き継いだ後、ユーザが、求める仕方で要求のデジタルコンテンツ１２をレンダリングする権利を有するかどうかを判定するプロセスを開始する。詳細には、ＤＲＭシステム３２は、ライセンスストアの中で有効な、使用を可能にするライセンス１６を探し出すか（ステップ５１５、５１７）、またはライセンスサーバ２４から、有効な、使用を可能にするライセンス１６を獲得しようと試みる（すなわち、以下に述べ、図７に示すライセンス獲得機能を行う）。
【００９１】
第１のステップとして、図６を参照すると、ＤＲＭシステム３２のライセンスイバリュエータ３６が、デジタルコンテンツ１２に対応する１つまたは複数の受け取られたライセンス１６の存在に関してライセンスストア３８を検査する（ステップ６０１）。通常、ライセンス１６は、以下に述べる通り、デジタルファイルの形態になっている。ただし、ライセンス１６は、本発明の趣旨および範囲を逸脱することなく、他の形態になっていることも可能であることが認められよう。通常、ユーザは、ライセンス１６なしにデジタルコンテンツ１２を受け取る。ただし、デジタルコンテンツ１２は、本発明の趣旨および範囲を逸脱することなく、対応するライセンス１６とともに受け取られることが可能であることも同様に認められよう。
【００９２】
図３に関連して前述した通り、各デジタルコンテンツ１２は、デジタルコンテンツ１２（またはパッケージ１２ｐ）を識別するコンテンツＩＤ（またはパッケージＩＤ）、および暗号化されたデジタルコンテンツ１２を解読する暗号解読鍵（ＫＤ）を識別する鍵ＩＤを備えたパッケージ１２ｐの中にある。好ましくは、コンテンツＩＤ（またはパッケージＩＤ）、および鍵ＩＤは、解読されていない形態になっている。したがって、特に、デジタルコンテンツ１２のコンテンツＩＤに基づき、ライセンスイバリュエータ３６は、そのコンテンツＩＤに該当する識別子を含むライセンス１６をライセンスストア３８の中で探す。特に、デジタルコンテンツ１２の所有者が、デジタルコンテンツ１２に関して複数の異なる種類のライセンス１６を指定しており、ユーザが、そのライセンス１６のなかの複数のライセンスを獲得している場合、複数のそのようなライセンスが見出される可能性があることに留意されたい。実際、ライセンスイバリュエータ３６が、要求のデジタルコンテンツ１２に対応するライセンス１６をライセンスストア３８の中で全く見出さなかった場合、ＤＲＭシステム３２は、以下に説明するライセンス獲得の機能（図５Ｂのステップ５１９）を行うことが可能である。
【００９３】
次に、ＤＲＭシステム３２に、デジタルコンテンツ１２をレンダリングする要求が行われており、またデジタルコンテンツ１２に対応する１つまたは複数のライセンス１６が、ライセンスストア３８の中に存在するものと想定する。本発明の一実施形態では、ＤＲＭシステム３２のライセンスイバリュエータ３６は、各ライセンス１６に関して、そのライセンス１６自体が有効であるかどうかを判定することに取りかかる（図６のステップ６０３および６０５）。好ましくは、詳細には、各ライセンス１６が、そのライセンス１６のコンテンツ２８に基づくデジタル署名を含む。理解されるべきこととして、デジタル署名２６は、コンテンツ２８が改ざんされているか、または別の仕方で変更されている場合、ライセンス１６にマッチしない。したがって、ライセンスイバリュエータ３６は、デジタル署名２６に基づき、コンテンツ２８が、ライセンスサーバ２４から受け取られた形態をしている（すなわち、有効である）かどうかを判定することができる。有効なライセンス１６がライセンスストア３８の中で見出されなかった場合、ＤＲＭシステム３２は、以下に説明するライセンス獲得機能を行って有効なライセンス１６を獲得することができる。
【００９４】
１つまたは複数の有効なライセンス１６が見出されたと想定すると、それぞれの有効なライセンス１６に関して、ＤＲＭシステム３２のライセンスイバリュエータ３６が、次に、その有効なライセンス１６が、所望の仕方で対応するデジタルコンテンツ１２をレンダリングする権利をユーザに与える（すなわち、使用を可能にするものである）かどうか判定する（ステップ６０７および６０９）。詳細には、ライセンスイバリュエータ３６は、各ライセンス１６における権利記述に基づき、またユーザが、デジタルコンテンツ１２に何をしようとしているかに基づき、要求側のユーザが、要求のデジタルコンテンツ１２を再生する権利を有するかどうかを判定する。例えば、この権利記述により、ユーザが、デジタルコンテンツ１２をサウンドにレンダリングすることが許されるが、解読されたデジタルコピーにレンダリングすることは許されない。
【００９５】
理解されるべきこととして、各ライセンス１６における権利記述は、ユーザが誰であるか、ユーザがどこに所在するか、ユーザがどのようなタイプのコンピューティングデバイス１４を使用しているか、どのようなレンダリングアプリケーション３４がＤＲＭシステム３２を呼び出しているか、日付、時刻等を含め、いくつかのファクタの任意のものに基づき、ユーザがデジタルコンテンツ１２を再生する権利を有するかどうかを指定する。さらに、権利記述は、例えば、所定の回数の再生に、または所定の再生時間にライセンスを制限することが可能である。そのような場合、ＤＲＭシステム３２は、ライセンス１６に関してあらゆる状態情報（すなわち、何回、デジタルコンテンツ１２がレンダリングされたか、デジタルコンテンツ１２がレンダリングされた合計時間等）を参照しなければならず、この状態情報は、ユーザのコンピューティングデバイス１４上のＤＲＭシステム３２の状態ストア４０の中に記憶されている。
【００９６】
したがって、ＤＲＭシステム３２のライセンスイバリュエータ３６が、それぞれ有効なライセンス１６の権利記述を検討して、その有効なライセンス１６により、求めている権利がユーザに与えられるかどうかを判定する。これを行う際、ライセンスイバリュエータ３６は、ユーザのコンピューティングデバイス１４にローカルな他のデータを参照して、ユーザが、求めている権利を有するかどうかの判定を行う。図４に見られる通り、このデータは、ユーザのコンピューティングデバイス（マシン）１４の識別４２およびデバイス１４の特定の態様、ユーザの識別４４およびユーザの特定の態様、レンダリングアプリケーション３４の識別およびアプリケーション３４の特定の態様、システムクロック４６等を含むことが可能である。求める仕方でデジタルコンテンツ１２をレンダリングする権利をユーザに提供する有効なライセンス１６が見出されない場合、ＤＲＭシステム３２は、以下に説明するライセンス獲得機能を行い、そのようなライセンス１６が実際に獲得可能である場合、そのライセンス１６を獲得する。
【００９７】
もちろん、一部の場合、ユーザは、要求する仕方でデジタルコンテンツ１２をレンダリングする権利を獲得することができない。というのは、デジタルコンテンツ１２のコンテンツ所有者が、そのような権利が許可されるべきでないことを実際に指示しているからである。例えば、デジタルコンテンツ１２のコンテンツ所有者が、ユーザがテキストドキュメントを印刷すること、または暗号化されていない形態でマルチメディアプレゼンテーションをコピーすることを許すライセンス１６が交付されるべきでないことを指示していることが可能である。本発明の一実施形態では、デジタルコンテンツ１２は、ライセンス１６の購入時にどのような権利が入手可能かに関するデータ、および入手可能なライセンス１６のタイプに関するデータを含む。ただし、デジタルコンテンツ１２のコンテンツ所有者は、デジタルコンテンツ１２に関して入手可能なライセンス１６を変更することにより、デジタルコンテンツに関して現行で入手可能な権利を任意の時点で変更できることが認められよう。
【００９８】
ＤＲＭシステム３２−ライセンス獲得
次に、図７を参照すると、ライセンスイバリュエータ３６が、実際に、要求されたデジタルコンテンツ１２に対応する有効な、使用を可能にするライセンス１６をライセンスストア３８の中で見出さなかった場合、ＤＲＭシステム３２が、ライセンス獲得の機能を行うことが可能である。図３に示す通り、各デジタルコンテンツ１２は、そのデジタルコンテンツ１２をレンダリングするためのライセンス１６をどのように獲得するかに関する暗号化されていない形態の情報（すなわち、ライセンス獲得情報）とともにパッケージ化される。
【００９９】
本発明の一実施形態では、ライセンス獲得情報は、とりわけ、入手可能なライセンス１６のタイプを含み、また各ライセンスサーバ２４が、実際に、デジタルコンテンツ１２に対応するライセンス１６を発行することができる場合、１つまたは複数の適切なライセンスサーバ２４にアクセスすることが可能な１つまたは複数のインターネットＷｅｂサイト、または他のサイト情報を含むことが可能である。もちろん、ライセンス１６は、本発明の趣旨および範囲を逸脱することなく、他の仕方で獲得することも可能である。例えば、ライセンス１６は、電子掲示板において、あるいは磁気ディスクまたは光ディスク等の上のファイルの形態で直接に、または通常の郵便を介してでも獲得することが可能である。
【０１００】
ライセンス１６を獲得するための場所が、実際に、ネットワーク上のライセンスサーバ２４であると想定すると、ライセンスイバリュエータ３６が、Ｗｅｂサイト情報、または他のサイト情報に基づき、ライセンスサーバ２４に対するネットワーク接続を確立し、次に、接続されたライセンスサーバ２４にライセンス１６の要求を送信する（ステップ７０１、７０３）。詳細には、ＤＲＭシステム３２は、ライセンスサーバ２４にコンタクトすると、適切なライセンス要求情報３６をそのライセンスサーバ２４に伝送する。本発明の一実施形態では、ライセンス１６は、以下のものを含むことが可能な情報３６を要求する。すなわち、とりわけ、
−ＤＲＭシステム３２のブラックボックス３０の公開鍵（ＰＵ−ＢＢ）、
−ＤＲＭシステム３２のブラックボックス３０のバージョン番号、
−ブラックボックス３０を認証する認証機関からのデジタル署名を伴う証明書（ただし、証明書は、ブラックボックス３０の前述した公開鍵およびバージョン番号を実際に含む）、
−デジタルコンテンツ１２（またはパッケージ１２ｐ）を識別するコンテンツＩＤ（またはパッケージＩＤ）、
−デジタルコンテンツ１２を解読するための暗号解読鍵（ＫＤ）を識別する鍵ＩＤ、
−要求されたライセンス１６のタイプ（実際に、複数のタイプが入手可能な場合）、
−デジタルコンテンツ１２のレンダリングを要求したレンダリングアプリケーション３４のタイプ、
および／または以上に類するもの。もちろん、本発明の趣旨および範囲を逸脱することなく、より多量の、またはより少量のライセンス１６要求情報３６が、ＤＲＭシステム３２によってライセンスサーバ２４に伝送されることが可能である。例えば、レンダリングアプリケーション３４のタイプに関する情報が必要でない可能性がある一方で、ユーザおよび／またはユーザのコンピューティングデバイス１４に関する追加の情報が必要である可能性がある。
【０１０１】
ライセンスサーバ２４は、ＤＲＭシステム３２からライセンス１６要求情報３６を受け取ると、信頼／認証に関して、またその他の目的でいくつかの検査を行うことができる。本発明の一実施形態では、ライセンスサーバ２４は、認証機関のデジタル署名に関して証明書を検査して、署名が改ざんされているかどうか、または別の仕方で変更されているかどうかを判定する（ステップ７０５、７０７）。改ざん、または変更されている場合、ライセンスサーバ２４は、要求情報３６に基づいてライセンス１６を交付するのを拒否する。また、ライセンスサーバ２４は、既知の「不良な」ユーザおよび／またはユーザのコンピューティングデバイス１４のリストも保持することができ、リスト上のいずれかの不良なユーザおよび／または不良なユーザのコンピューティングデバイス１４からの要求に基づいてライセンス１６を交付するのを拒否することができる。本発明の趣旨および範囲を逸脱することなく、そのような「不良」リストを任意の適切な仕方で編成することが可能である。
【０１０２】
受け取られた要求、およびその要求に関連する情報に基づき、また詳細には、ライセンス要求情報の中のコンテンツＩＤ（またはパッケージＩＤ）に基づき、ライセンスサーバ２４は、コンテンツ−鍵データベース２０（図１）に問い合わせ、要求の根拠であるデジタルコンテンツ１２（またはパッケージ１２ｐ）に対応するレコードを探し出すことができる。前述した通り、このレコードは、そのデジタルコンテンツ１２に関する暗号解読鍵（ＫＤ）、鍵ＩＤ、およびコンテンツＩＤを含む。さらに、このレコードは、デジタルコンテンツ１２に関して発行されるべきライセンス１６のタイプに関するライセンスデータ、および各タイプのライセンス１６に関する条項および条件を含むことが可能である。あるいは、このレコードは、そのような追加の情報を有する場所に対するポインタ、リンク、またはリファレンスを含むことが可能である。
【０１０３】
前述した通り、複数のタイプのライセンス１６を入手可能とすることができる。例えば、比較的小額のライセンス料で、限られた回数のレンダリングを許すライセンス１６を入手可能とすることができる。より高額のライセンス料で、失効日まで無制限のレンダリングを許すライセンス１６を、入手可能とすることができる。さらに高額のライセンス料で、失効日なしの無制限のレンダリングを許すライセンス１６が入手可能とすることができる。本発明の趣旨および範囲を逸脱することなく、任意の種類のライセンス条項を有する実質的にあらゆるタイプのライセンス１６を考案することが可能であり、またライセンスサーバ２４によって発行することが可能である。
【０１０４】
本発明の一実施形態では、ライセンス１６の要求は、ライセンスサーバ２４からユーザのコンピューティングデバイス１４に伝送されるＷｅｂページ等の助けを借りて達せられる。好ましくは、このＷｅｂページは、ライセンス１６要求の根拠であるデジタルコンテンツ１２に関してライセンスサーバ２４から入手可能なすべてのタイプのライセンス１６に関する情報を含む。
【０１０５】
本発明の一実施形態では、ライセンス１６を発行することに先立ち、ライセンスサーバ２４は、ブラックボックス３０のバージョン番号を検査して、ブラックボックス３０が比較的新しいかどうかを判定する（ステップ７０９、７１１）。理解すべきこととして、ブラックボックス３０は、不正な（すなわち、ライセンス１６なしにデジタルコンテンツ１２を不適切にレンダリングする、または対応するライセンス１６の条項を外れてレンダリングする）目的を有するユーザからの攻撃に対してセキュアであり、保護されているものとする。ただし、そのような攻撃に対して完全にセキュアなシステムおよびソフトウェアデバイスは存在しないことを認識されたい。
【０１０６】
また、理解されるべきこととして、ブラックボックス３０が比較的新しい場合、すなわち、比較的最近に獲得されるか、または更新されている場合、ブラックボックス３０が、不正なユーザによって成功裏に攻撃されている可能性がより低い。好ましくは、信頼に関わることとして、ライセンスサーバ２４は、比較的新しくはないブラックボックス３０バージョン番号を含む要求情報３６を伴うライセンス要求を受け取った場合、以下に説明する通り、対応するブラックボックス３０が現行のバージョンに更新されるまで、要求されたライセンス１６を発行するのを拒否する。簡単に言えば、ライセンスサーバ２４は、ブラックボックス３０が比較的新しくない限り、ブラックボックス３０を信頼しない。
【０１０７】
本発明のブラックボックス３０のコンテキストでは、「現行の」または「比較的新しい」という用語は、本発明の趣旨および範囲を逸脱することなく、ブラックボックス３０の経時（ａｇｅ）、または使用法に基づいてブラックボックス３０を信頼する機能と整合する任意の適切な意味を有することが可能である。例えば、「現行」は、経時に従って（すなわち、１カ月以内の経時）定義することができる。代替の例として、「現行」は、ブラックボックス３０がデジタルコンテンツ１２を解読した回数（すなわち、２００回以内の暗号解読）に基づいて定義することができる。さらに、「現行」は、ライセンスサーバ２４ごとに「現行」に違った定義が行われ、ライセンスサーバ２４が、さらに、とりわけ、ライセンス１６が要求されたデジタルコンテンツ１２に依存して、または要求されたライセンス１６のタイプに依存して「現行」に違った定義を行う、各ライセンスサーバ２４によって設定されたポリシーに基づくことが可能である。
【０１０８】
ブラックボックス３０のバージョン番号、またはブラックボックス３０の他の指示から、ブラックボックス３０が現行のものであるとライセンスサーバ２４が確信させられたと想定して、ライセンスサーバ２４が、ライセンス１６に関する条項および条件をユーザと交渉することに取りかかる（ステップ７１３）。あるいは、ライセンスサーバ２４は、ユーザとライセンス１６を交渉し、次に、ブラックボックス３０のバージョン番号から、ブラックボックス３０が現行のものであるという確信を得る（すなわち、ステップ７１３を行い、次にステップ７１１を行う）。もちろん、交渉の量は、発行されるべきライセンス１６のタイプ、およびその他のファクタに応じて様々である。例えば、ライセンスサーバ２４が、単に支払済みの無制限の使用ライセンス１６を発行する場合、ほとんど交渉を行う必要がない。他方、ライセンス１６が、変化する値、スライディングスケール（ｓｌｉｄｉｎｇ　ｓｃａｌｅ）、ブレークポイント（ｂｒｅａｋ　ｐｏｉｎｔ）、およびその他の詳細などの項目に基づく場合、そのような項目および詳細をライセンスサーバ２４とユーザの間で調整してからでないと、ライセンス１６を発行することができない可能性がある。
【０１０９】
理解されるべきこととして、状況に応じて、ライセンス交渉は、ユーザが、ライセンスサーバ２４にさらなる情報（例えば、ユーザ、ユーザのコンピューティングデバイス１４等に関する情報）を提供することを必要とする可能性がある。重要なことには、ライセンス交渉は、ユーザおよびライセンスサーバ２４が、とりわけ、互いに受入れ可能な支払い手段（クレジット口座、デビット（ｄｅｂｉｔ）口座、郵送される小切手等）、および／または支払い方法（即時の支払い、ある期間にわたる支払い等）を決めることも要求することが可能である。
【０１１０】
ライセンス１６のすべての条項が交渉され、ライセンスサーバ２４とユーザの両方によって合意されると（ステップ７１５）、ライセンスサーバ２４によってデジタルライセンス１６が生成され（ステップ７１９）、この生成されたライセンス１６は、少なくともある程度、ライセンス要求、ブラックボックス３０公開鍵（ＰＵ−ＢＢ）、およびコンテンツ−鍵データベース２０から獲得される要求の根拠であるデジタルコンテンツ１２に関する暗号解読鍵（ＫＤ）に基づいている。本発明の一実施形態では、図８で見られる通り、生成されたライセンス１６は、以下のものを含む。すなわち、
−ライセンス１６が適用されるデジタルコンテンツ１２のコンテンツＩＤ、
−暗号解読鍵（ＫＤ）で、場合により、暗号化されたデジタル権利ライセンス（ＤＲＬ）４８（すなわち、ライセンスイバリュエータ３６が問い合わせることができる所定の形式で書かれたライセンス１６の権利記述、または実際の条項および条件）（すなわち、ＫＤ（ＤＲＬ））、
−ライセンス要求の中で受け取られたブラックボックス３０公開鍵（ＰＵ−ＢＢ）で暗号化されたデジタルコンテンツに関する暗号解読鍵（すなわち、（ＰＵ−ＢＢ（ＫＤ））、
−（ＫＤ（ＤＲＬ））および（ＰＵ−ＢＢ（ＫＤ））に基づき、ライセンスサーバ２４秘密鍵で暗号化されたライセンスサーバ２４からのデジタル署名（付加された証明書なしの）（すなわち、（Ｓ（ＰＲ−ＬＳ）））、および
−ライセンスサーバ２４が、コンテンツサーバ２２から以前に獲得した、ライセンスサーバ２４が、ライセンス１６を発行するコンテンツサーバ２２からの許可を有することを示す証明書（すなわち、（ＣＥＲＴ（ＰＵ−ＬＳ）Ｓ（ＰＲ−ＣＳ）））である。
【０１１１】
理解されるべきこととして、前述した要素、および、場合により、その他の要素は、デジタルファイル、または何らかの他の適切な形態にパッケージ化される。やはり、理解されるべきこととして、ライセンス１６の中のＤＲＬ４８、または（ＰＵ−ＢＢ（ＫＤ））が改ざんされた、または別の仕方で変更された場合、ライセンス１６の中のデジタル署名（Ｓ（ＰＲ−ＬＳ））は、ライセンス１６にマッチせず、したがって、ライセンス１６を有効にしない。この理由で、ＤＲＬ４８は、必ずしも暗号化された形態（すなわち、前述した（ＫＤ（ＤＲＬ）））でなくてもよい。ただし、暗号化された形態は、一部の場合、望ましく、したがって、本発明の趣旨および範囲を逸脱することなく使用することができる。
【０１１２】
デジタルライセンス１６が準備されると、このライセンス１６は、要求側（すなわち、ユーザのコンピューティングデバイス１４上のＤＲＭシステム３２）に対して発行される（図７のステップ７１９）。好ましくは、ライセンス１６は、ライセンス１６の要求が行われたのと同じパス（すなわち、インターネット、または別のネットワーク）を介して伝送される。ただし、本発明の趣旨および範囲を逸脱することなく、別のパスを使用することもできる。受領時に、要求側のＤＲＭシステム３２は、好ましくは、受領したデジタルライセンス１６をライセンスストア３８の中に配置する（ステップ７２１）。
【０１１３】
ユーザのコンピューティングデバイス１４には、ときとして動作不良が生じる可能性があり、そのユーザのコンピューティングデバイス１４上のＤＲＭシステム３２のライセンスストア３８の中に記憶されたライセンス１６が、回復不能な仕方で失われる可能性があることを理解されたい。したがって、ライセンスサーバ２４が、発行されたライセンス１６のデータベース５０を維持し（図１）、またライセンスサーバ２４が、発行済みライセンス１６のコピーまたは再発行（以降、「再発行」）をユーザに提供することを、そのユーザが、実際に、再発行を受ける資格がある場合、行うことが好ましい。ライセンス１６が回復不能な仕方で失われる前述したケースでは、状態ストア４０の中に記憶され、ライセンス１６に対応する状態情報も失われていることになっている可能性が高い。この失われた状態情報が、ライセンス１６を再発行する際、考慮に入れられなければならない。例えば、固定回数のレンダリングライセンス１６は、比較的短い期間の後、応分に割振り計算した形で正当に再発行することが可能であるが、比較的長い期間の後、再発行することは可能でない。
【０１１４】
ＤＲＭシステム３２−ブラックボックス３０のインストール／アップグレード前述した通り、ライセンス１６を獲得する機能の一環として、ライセンスサーバ２４は、ユーザのコンピューティングデバイス１４が、比較的新しくはない、すなわち、比較的古いバージョン番号を有するブラックボックス３０を備えたＤＲＭシステム３２を有する場合、ユーザからのライセンス１６の要求を拒否する可能性がある。その場合、そのＤＲＭシステム３２のブラックボックス３０をアップグレードして、その後にライセンス獲得機能を開始できるようにすることが好ましい。もちろん、ブラックボックス３０は、本発明の趣旨および範囲を逸脱することなく、任意の時点でアップグレードすることができる。
【０１１５】
好ましくは、ユーザのコンピューティングデバイス１４上のＤＲＭシステム３２をインストールするプロセスの一環として、ブラックボックス３０の固有でない「ライト（ｌｉｔｅ）」バージョンが提供される。次に、この「ライト」ブラックボックス３０を、デジタルコンテンツ１２をレンダリングするのに先立って固有の通常のバージョンにアップグレードする。理解されるべきこととして、各ＤＲＭシステム３２の中のブラックボックス３０は固有であり、１つのブラックボックス３０のセキュリティを破って侵入することにより、何らかの他のブラックボックス３０で容易に侵入を繰り返すことはできない。
【０１１６】
次に、図９を参照すると、ＤＲＭシステム３２が、ブラックボックスサーバ２６等（前述し、図１に示した）から固有のブラックボックス３０を要求することにより、ブラックボックス３０を獲得する（ステップ９０１）。通常、この要求は、インターネットを使用して行われるが、本発明の趣旨および範囲を逸脱することなく、他のアクセス手段を使用することもできる。例えば、ブラックボックスサーバ２６に対する接続は、ローカル式または遠隔式の直接接続であることが可能である。ある固有のライトでないブラックボックス３０から別の固有のライトでないブラックボックス３０へのアップグレードも、例えば、前述した通り、ライセンスサーバ２４が、ブラックボックス３０が現行のものでないと見なした時点などの任意の時点で、ＤＲＭシステム３２によって要求されることが可能である。
【０１１７】
その後、ブラックボックスサーバ２６が、新しい固有のブラックボックス３０を生成する（ステップ９０３）。図３に見られる通り、それぞれの新しいブラックボックス３０は、バージョン番号、および認証機関からのデジタル署名を有する証明書を備えている。ライセンス獲得機能に関連して前述した通り、ブラックボックス３０のバージョン番号は、ブラックボックス３０の相対的な経時および／または使用法を示す。やはりライセンス獲得機能に関連して前述した、認証機関からのデジタル署名を備えた証明書は、ライセンスサーバ２４がブラックボックス３０を信頼すべきことの認証機関からの申し出（ｐｒｏｆｆｅｒ）メカニズム、または保証（ｖｏｕｃｈｉｎｇ）メカニズムである。もちろん、ライセンスサーバ２４は、認証機関が、実際に信頼に値するブラックボックス３０に関して証明書を発行するものと信頼しなければならない。実際には、ライセンスサーバ２４が、特定の認証機関を信用せず、その認証機関によって発行されたあらゆる証明書を尊重することを拒否する可能性がある。例えば、特定の認証機関が、証明書を不適切に発行することを繰り返し行っていることが分かった場合、信頼がなされない可能性がある。
【０１１８】
好ましくは、前述した通り、ブラックボックスサーバ２６は、新しい固有の公開鍵／秘密鍵ペア（ＰＵ−ＢＢ、ＰＲ−ＢＢ）を新たに生成された固有のブラックボックス３０に含める（図９のステップ９０３）。好ましくは、そのブラックボックス３０に関する秘密鍵（ＰＲ−ＢＢ）には、そのブラックボックス３０だけがアクセス可能であり、そのブラックボックス３０を有するＤＲＭシステム３２を有するコンピューティングデバイス１４、およびコンピューティングデバイス１４のユーザを含め、それ以外の世界には隠されており、アクセス不可能である。
【０１１９】
世界から秘密鍵（ＰＲ−ＢＢ）を隠す機能を実際に行う限り、本発明の趣旨および範囲を逸脱することなく、ほとんどの任意の隠蔽スキームを使用することができる。単に一例として、秘密鍵（ＰＲ−ＢＢ）は、いくつかの下位構成要素に分割することができ、各下位構成要素を固有に暗号化して、異なる場所に記憶することができる。そのような状況では、下位構成要素が決して完全に組み立てられて秘密鍵全体（ＰＲ−ＢＢ）をもたらすことがないことが好ましい。
【０１２０】
本発明の一実施形態では、秘密鍵（ＰＲ−ＢＢ）は、コードベースの暗号技術に従って暗号化される。詳細には、この実施形態では、ブラックボックス３０の実際のソフトウェアコード（または他のソフトウェアコード）が、暗号化鍵として使用される。したがって、ブラックボックス３０のコード（または他のソフトウェアコード）が、例えば、不正な目的を有するユーザによって改ざんされた、または別の仕方で変更された場合、その秘密鍵（ＰＲ−ＢＢ）を解読することができない。
【０１２１】
それぞれの新しいブラックボックス３０は、新しい公開鍵／秘密鍵ペア（ＰＵ−ＢＢ、ＰＲ−ＢＢ）とともに配信されるが、新しいブラックボックス３０には、好ましくは、ユーザのコンピューティングデバイス１４上のＤＲＭシステム３２に以前に配信された古いブラックボックス３０からの古い公開鍵／秘密鍵ペアに対するアクセスも与えられる（ステップ９０５）。したがって、アップグレードされたブラックボックス３０は、それでも、以下により詳細に述べる通り、古い鍵ペアを使用して、その古い鍵ペアに従って生成されたより古いデジタルコンテンツ１２、およびより古い対応するライセンス１６にアクセスすることができる。
【０１２２】
好ましくは、ブラックボックスサーバ２６によって配信されたアップグレードされたブラックボックス３０は、ユーザのコンピューティングデバイス１４に緊密に結び付く、または緊密に関連する。したがって、アップグレードされたブラックボックス３０は、不正な目的、またはその他の目的で、複数のコンピューティングデバイス１４間で動作上、転送することができない。本発明の一実施形態では、ブラックボックス３０の要求（９０１）の一環として、ＤＲＭシステム３２が、そのＤＲＭシステム３２に固有であり、かつ／またはユーザのコンピューティングデバイス１４に固有であるハードウェア情報をブラックボックスサーバ２６に提供し、ブラックボックスサーバ２６は、その提供されたハードウェア情報にある程度、基づき、そのＤＲＭシステム３２用のブラックボックス３０を生成する。次に、この生成されたアップグレード済みのブラックボックス３０が、ユーザのコンピューティングデバイス１４上のＤＲＭシステム３２に配信されて、インストールされる（ステップ９０７、９０９）。その後、アップグレードされたブラックボックス３０が、何らかの仕方で別のコンピューティングデバイス１４に転送された場合、転送されたブラックボックス３０は、その別のコンピューティングデバイス１４を宛先としていないことを認識し、要求されたレンダリングが、その別のコンピューティングデバイス１４上で進められることを全く許さない。
【０１２３】
新しいブラックボックス３０がＤＲＭシステム３２にインストールされると、ＤＲＭシステム３２は、ライセンス獲得機能、または任意の他の機能を開始することができる。
【０１２４】
ＤＲＭシステム３２−コンテンツレンダリング、第３部
次に、図５Ｂを参照すると、ライセンスイバリュエータ３６が、少なくとも１つの有効なライセンス１６を見出し、また有効なライセンス１６の少なくとも１つが、求める仕方で対応するデジタルコンテンツ１２をレンダリングするのに必要な権利をユーザに提供する（すなわち、使用を可能にするものである）ものと想定すると、ライセンスイバリュエータ３６が、そのライセンス１６の１つをさらなる使用のために選択する（ステップ５１９）。詳細には、要求されたデジタルコンテンツ１２をレンダリングするため、ライセンスイバリュエータ３６とブラックボックス３０が一緒に、ライセンス１６から暗号解読鍵（ＫＤ）を獲得し、ブラックボックス３０が、その暗号解読鍵（ＫＤ）を使用してデジタルコンテンツ１２を解読する。本発明の一実施形態では、前述した通り、ライセンス１６から獲得された暗号解読鍵（ＫＤ）が、ブラックボックス３０公開鍵で暗号化され（ＰＵ−ＢＢ（ＫＤ））、ブラックボックス３０が、その暗号化された暗号解読鍵を自らの秘密鍵（ＰＲ−ＢＢ）を使用して解読して、暗号解読鍵（ＫＤ）をもたらす（ステップ５２１、５２３）。ただし、本発明の趣旨および範囲を逸脱することなく、デジタルコンテンツ１２に関する暗号解読鍵（ＫＤ）を獲得する他の方法も使用することができる。
【０１２５】
ブラックボックス３０が、デジタルコンテンツ１２に関する暗号解読鍵（ＫＤ）、およびそのデジタルコンテンツ１２をレンダリングするライセンスイバリュエータ３６からの許可を入手すると、制御が、レンダリングアプリケーション３４に戻ることが可能である（ステップ５２５、５２７）。本発明の一実施形態では、次に、レンダリングアプリケーション３４が、ＤＲＭシステム３２／ブラックボックス３０を呼び出し、暗号化されたデジタルコンテンツ１２の少なくとも一部分を暗号解読鍵（ＫＤ）に従って暗号解読のためにブラックボックス３０に向かわせる（ステップ５２９）。ブラックボックス３０は、デジタルコンテンツ１２に関する暗号解読鍵（ＫＤ）に基づいてデジタルコンテンツ１２を解読し、次に、解読したデジタルコンテンツ１２を実際のレンダリングのためにレンダリングアプリケーション３４に戻す（ステップ５３３、５３５）。レンダリングアプリケーション３４は、本発明の趣旨および範囲を逸脱することなく、デジタルコンテンツ１２に関する暗号解読鍵（ＫＤ）に基づき、暗号解読のために暗号化されたデジタルコンテンツ１２の一部分、またはデジタルコンテンツ１２全体をブラックボックス３０に送ることができる。
【０１２６】
好ましくは、レンダリングアプリケーション３４が、暗号解読のためにデジタルコンテンツ１２をブラックボックス３０に送ったとき、ブラックボックス３０および／またはＤＲＭシステム３２が、そのレンダリングアプリケーション３４を認証して、そのレンダリングアプリケーション３４が、ＤＲＭシステム３２に動作するように最初に要求を行ったのと同じレンダリングアプリケーション３４であることを確実にする（ステップ５３１）。そうでなければ、あるタイプのレンダリングアプリケーション３４上のレンダリング要求に基づくことにより、レンダリング許可が不適切に獲得され、実際には、別のタイプのレンダリングアプリケーション３４を使用してレンダリングが行われる可能性が存在する。認証が成功し、デジタルコンテンツ１２が、ブラックボックス３０によって解読されたものと想定すると、次に、レンダリングアプリケーション３４が、解読されたデジタルコンテンツ１２をレンダリングすることができる（ステップ５３３、５３５）。
【０１２７】
鍵トランザクションのシーケンス
次に、図１０を参照すると、本発明の一実施形態では、鍵トランザクションのシーケンスが、暗号解読鍵（ＫＤ）を獲得し、要求されたデジタルコンテンツ１２に関するライセンス１６を評価するように（すなわち、図５Ａおよび５Ｂのステップ５１５〜５２３を行うように）行われる。主に、このシーケンスでは、ＤＲＭシステム３２が、ライセンス１６から暗号解読鍵（ＫＤ）を獲得し、ライセンス１６およびデジタルコンテンツ１２から獲得された情報を使用して、ライセンス１６とデジタルコンテンツ１２の両方の有効性を認証し、または確実にし、次に、ライセンス１６が、求められる仕方でデジタルコンテンツ１２をレンダリングする権利を実際に提供するかどうかを判定する。提供する場合、デジタルコンテンツ１２をレンダリングすることができる。
【０１２８】
図８に見られる通り、デジタルコンテンツ１２に関する各ライセンス１６が、
−ライセンス１６が適用されるデジタルコンテンツ１２のコンテンツＩＤ、
−暗号解読鍵（ＫＤ）で、場合により、暗号化されたデジタル権利ライセンス（ＤＲＬ）４８（すなわち、ＫＤ（ＤＲＬ））、
−ブラックボックス３０公開鍵（ＰＵ−ＢＢ）で暗号化されたデジタルコンテンツ１２に関する暗号解読鍵（ＫＤ）（すなわち、（ＰＵ−ＢＢ（ＫＤ）））、−（ＫＤ（ＤＲＬ））および（ＰＵ−ＢＢ（ＫＤ））に基づき、ライセンスサーバ２４秘密鍵で暗号化されたライセンスサーバ２４からのデジタル署名（すなわち、（Ｓ（ＰＲ−ＬＳ）））、および
ライセンスサーバ２４が、コンテンツサーバ２２から以前に獲得した証明書（すなわち、（ＣＥＲＴ（ＰＵ−ＬＳ）Ｓ（ＰＲ−ＣＳ）））を含むことを念頭に置き、また、図３に見られる通り、デジタルコンテンツ１２を有するパッケージ１２ｐが、
−デジタルコンテンツ１２のコンテンツＩＤ、
−ＫＤで暗号化されたデジタルコンテンツ１２（すなわち、（ＫＤ（ＣＯＮＴＥＮＴ）））、
−暗号化されていないライセンス獲得スクリプト、および
−コンテンツサーバ２２秘密鍵（ＰＲ−ＣＳ）で署名されたコンテンツサーバ２２公開鍵（ＰＵ−ＣＳ）を暗号化する鍵ＫＤ（すなわち、（ＫＤ（ＰＵ−ＣＳ）Ｓ（ＰＲ−ＣＳ）））を含むことも念頭に置いて、本発明の一実施形態では、デジタルコンテンツ１２に関するライセンス１６の特定の１つに関する鍵トランザクションの特定のシーケンスが、以下の通りである。
【０１２９】
１．ライセンス１６からの（ＰＵ−ＢＢ（ＫＤ））に基づき、ユーザのコンピューティングデバイス１４上のＤＲＭシステム３２のブラックボックス３０が、自らの秘密鍵（ＰＲ−ＢＢ）を適用して（ＫＤ）を獲得する（ステップ１００１）。（ＰＲ−ＢＢ（ＰＵ−ＢＢ（ＫＤ））＝（ＫＤ））。重要なこととして、次に、ブラックボックス３０は、ＫＤを使用して無造作にデジタルコンテンツ１２を解読することを開始できることに留意されたい。ただし、やはり重要なこととして、ライセンスサーバ２４は、ブラックボックス３０がそうしないものと信頼する。この信頼は、ライセンスサーバ２４が、ブラックボックス３０が信頼に値することを保証する認証機関からの証明書に基づいてライセンス１６を発行した時点で確立されている。したがって、ブラックボックス３０が、最終ステップではなく、初期ステップとして暗号解読鍵（ＫＤ）を獲得するにも関わらず、ＤＲＭシステム３２は、以下に説明する通り、すべてのライセンス１６検証機能および評価機能を行いつづける。
【０１３０】
２．デジタルコンテンツ１２からの（ＫＤ（ＰＵ−ＣＳ）Ｓ（ＰＲ−ＣＳ））に基づき、ブラックボックス３０は、新たに獲得された暗号解読鍵（ＫＤ）を適用して（ＰＵ−ＣＳ）を獲得する（ステップ１００３）。（ＫＤ（ＫＤ（ＰＵ−ＣＳ））＝（ＰＵ−ＣＳ））。さらに、ブラックボックス３０は、（ＰＵ−ＣＳ）を署名（Ｓ（ＰＲ−ＣＳ））に照らして適用して、署名およびデジタルコンテンツ１２／パッケージ１２ｐが有効であることの確信を得ることができる（ステップ１００５）。有効でない場合、プロセスは停止され、デジタルコンテンツ１２へのアクセスが拒否される。
【０１３１】
３．ライセンス１６からの（ＣＥＲＴ（ＰＵ−ＬＳ）Ｓ（ＰＲ−ＣＳ））に基づき、ブラックボックス３０は、新たに獲得されたコンテンツサーバ２２公開鍵（ＰＵ−ＣＳ）を適用して、証明書が有効であることの確信を得る（ステップ１００７）。有効であることは、ライセンス１６を発行したライセンスサーバ２４が、そうすることの許可をコンテンツサーバ２２から得ていることを意味する。次に、ブラックボックス３０は、証明書コンテンツを検査して（ＰＵ−ＬＳ）を獲得する（ステップ１００９）。有効でなかった場合、プロセスは停止され、ライセンス１６に基づくデジタルコンテンツ１２へのアクセスは拒否される。
【０１３２】
４．ライセンス１６からの（Ｓ（ＰＲ−ＬＳ））に基づき、ブラックボックス３０は、新たに獲得されたライセンスサーバ２４公開鍵（ＰＵ−ＬＳ）を適用して、ライセンス１６が有効であることの確信を得る（ステップ１０１１）。有効でなかった場合、プロセスは停止され、ライセンス１６に基づくデジタルコンテンツ１２へのアクセスは拒否される。
【０１３３】
５．すべての検証ステップが成功し、ライセンス１６の中のＤＲＬ４８が、暗号解読鍵（ＫＤ）で実際に暗号化されたものと想定すると、次に、ライセンスイバリュエータ３６が、既に獲得済みの暗号解読鍵（ＫＤ）をライセンス１６から獲得された（ＫＤ（ＤＲＬ））に適用して、ライセンス１６からライセンス条項（すなわち、ＤＲＬ４８）を獲得する（ステップ１０１３）。もちろん、ライセンス１６の中のＤＲＬ４８が、実際に暗号解読鍵（ＫＤ）で暗号化されていない場合、ステップ１０１３は、省略することができる。次に、ライセンスイバリュエータ３６が、ＤＲＬ４８の評価／問合せを行い、ライセンス１６の中のＤＲＬ４８に基づき、ユーザのコンピューティングデバイス１４が、求める仕方で対応するデジタルコンテンツ１２をレンダリングする権利を有するかどうか（すなわち、ＤＲＬ４８が使用を可能にするものであるかどうか）を判定する（ステップ１０１５）。ライセンスイバリュエータ３６が、その権利が存在しないと判定した場合、プロセスは停止され、ライセンス１６に基づくデジタルコンテンツ１２へのアクセスは拒否される。
【０１３４】
６．最後に、ライセンス１６の評価により、ＤＲＬ４８条項に基づいてユーザのコンピューティングデバイス１４が、求める仕方で対応するデジタルコンテンツ１２をレンダリングする権利を有するという肯定的な判定がもたらされたものと想定すると、ライセンスイバリュエータ３６は、ブラックボックス３０が、暗号解読鍵（ＫＤ）に従って対応するデジタルコンテンツ１２をレンダリングすることができることをブラックボックス３０に知らせる。その後、ブラックボックス３０は、暗号解読鍵（ＫＤ）を適用して、パッケージ１２ｐからデジタルコンテンツ１２を解読する（すなわち、（ＫＤ（ＫＤ（ＣＯＮＴＥＮＴ））＝（ＣＯＮＴＥＮＴ）））（ステップ１０１７）。
【０１３５】
以上に指定した一連のステップは、ライセンス１６とデジタルコンテンツ１２の間の交替、または「ピンポン（ｐｉｎｇ−ｐｏｎｇｉｎｇ）」を表すことに留意することが重要である。このピンポンにより、検証プロセスおよび評価プロセスが、デジタルコンテンツ１２とライセンス１６がともに適切に発行された有効な形態で存在する場合にだけ行われることが可能であるということで、デジタルコンテンツ１２が、ライセンス１６に緊密に結合されることが確実になる。さらに、ライセンス１６からコンテンツサーバ２２公開鍵（ＰＵ−ＣＳ）を獲得するのと、パッケージ１２ｐからデジタルコンテンツ１２を解読された形態で（また、場合により、ライセンス１６からライセンス条項（ＤＲＬ４８）を解読された形態で）獲得するのとに同一の暗号解読鍵（ＫＤ）が必要とされるため、以上のアイテムも緊密に結合される。また、署名検証により、デジタルコンテンツ１２およびライセンス１６が、コンテンツサーバ２２およびライセンスサーバ２４からそれぞれ発行されたのと同じ形態であることが確実になる。したがって、ライセンスサーバ２４を迂回することによってデジタルコンテンツ１２を解読することは、不可能でないにしても困難であり、また、デジタルコンテンツ１２またはライセンス１６を改変した後、解読することも、不可能でないにしても困難である。
【０１３６】
本発明の一実施形態では、署名確認、特にライセンス１６の署名確認が、以下の通り交替で行われる。図８に見られるように、ライセンスサーバ２４の秘密鍵（ＰＲ−ＬＳ）で署名が暗号化されるのではなく、各ライセンス１６の署名が、秘密ルート鍵（ｐｒｉｖａｔｅ　ｒｏｏｔ　ｋｅｙ）（ＰＲ−Ｒ）（図示せず）で暗号化され、各ＤＲＭシステム３２のブラックボックス３０が、その秘密ルート鍵（ＰＲ−Ｒ）に対応する公開ルート鍵（ｐｕｂｌｉｃ　ｒｏｏｔ　ｋｅｙ）（ＰＵ−Ｒ）（やはり図示せず）を含んでいる。秘密ルート鍵（ＰＲ−Ｒ）は、ルートエンティティにだけ知られ、ライセンスサーバ２４は、ライセンス１６を発行することをルートエンティティと取り決めた場合にだけ、ライセンス１６を発行することができる。
【０１３７】
詳細には、この実施形態では、
１．ライセンスサーバ２４が、自らの公開鍵（ＰＵ−ＬＳ）をルートエンティティに提供し、
２．ルートエンティティが、秘密ルート鍵（ＰＲ−Ｒ）で暗号化されたライセンスサーバ公開鍵（ＰＵ−ＬＳ）（すなわち、（ＣＥＲＴ（ＰＵ−ＬＳ）Ｓ（ＰＲ−Ｒ）））をライセンスサーバ２４に戻し、また
３．次に、ライセンスサーバ２４が、ライセンスサーバ秘密鍵（Ｓ（ＰＲ−ＬＳ））で暗号化された署名を有するライセンス１６を発行し、またルートエンティティからの証明書（ＣＥＲＴ（ＰＵ−ＬＳ）Ｓ（ＰＲ−Ｒ））をライセンスに付加する。
【０１３８】
ＤＲＭシステム１８が発行されたライセンス１６を検証するには、ＤＲＭシステム１８は、
１．公開ルート鍵（ＰＵ−Ｒ）を付加された証明書（ＣＥＲＴ（ＰＵ−ＬＳ）Ｓ（ＰＲ−Ｒ））に適用してライセンスサーバ公開鍵（ＰＵ−ＬＳ）を獲得し、また
２．獲得されたライセンスサーバ公開鍵（ＰＵ−ＬＳ）をライセンス１６の署名（Ｓ（ＰＲ−ＬＳ））に適用する。
【０１３９】
重要なことには、ルートエンティティが、ライセンスサーバ２４に対して証明書（ＣＥＲＴ（ＰＵ−ＬＳ）Ｓ（ＰＲ−Ｒ））を提供することによってライセンス１６を発行する許可を与えると、ライセンスサーバ２４は、同様の証明書を第２のライセンスサーバ２４に提供することができ（すなわち、（ＣＥＲＴ（ＰＵ−ＬＳ２）Ｓ（ＰＲ−ＬＳ１）））、これにより、第２のライセンスサーバもライセンス１６を発行することができるようになることを認識されたい。既に明白である通り、第２のライセンスサーバによって発行されるライセンス１６は、第１の証明書（ＣＥＲＴ（ＰＵ−ＬＳ１）Ｓ（ＰＲ−Ｒ））、および第２の証明書（ＣＥＲＴ（ＰＵ−ＬＳ２）Ｓ（ＰＲ−ＬＳ１））を含む。同様に、このライセンス１６は、第１の証明書から第２の証明書までの連鎖を辿ることによって検証される。もちろん、その連鎖にさらなるリンクを追加してトラバース（ｔｒａｖｅｒｓｅ）することも可能である。
【０１４０】
前述した署名確認プロセスの１つの利点は、ルートエンティティが、定期的に秘密ルート鍵（ＰＲ−Ｒ）を変更し、これにより、各ライセンスサーバ２４が新しい証明書（ＣＥＲＴ（ＰＵ−ＬＳ）Ｓ（ＰＲ−Ｒ））を獲得することを同様に要求することが可能なことである。重要なことには、その新しい証明書を獲得する要件として、各ライセンスサーバが、自らをアップグレードすることが必要とされる可能性がある。ブラックボックス３０の場合と同様に、ライセンスサーバ２４が、比較的新しい場合、すなわち、比較的最近、アップグレードされている場合、ライセンスサーバ２４が、成功裏に攻撃を受けている可能性がより低い。したがって、信頼に関わることとして、各ライセンスサーバ２４は、好ましくは、署名確認プロセスなどの適切なアップグレードトリガメカニズムを介して、定期的にアップグレードされることが必要とされる。もちろん、本発明の趣旨および範囲を逸脱することなく、他のアップグレードメカニズムも使用することができる。
【０１４１】
もちろん、秘密ルート鍵（ＰＲ−Ｒ）が変更された場合、各ＤＲＭシステム１８における公開ルート鍵（ＰＵ−Ｒ）も変更されなければならない。この変更は、例えば、通常のブラックボックス３０アップグレード中に行われることが可能であり、あるいは、実際に、ブラックボックス３０アップグレードが行われることを要する可能性がある。変更された公開ルート鍵（ＰＵ−Ｒ）は、より古い秘密ルート鍵（ＰＲ−Ｒ）に基づいて発行されたより古いライセンス１６に関する署名検証の障害になる可能性があるが、この障害は、アップグレードされたブラックボックス３０が、すべての古い公開ルート鍵（ＰＵ−Ｒ）を憶えておくことを要求することによって最小限に抑えることができる。あるいは、ライセンス１６に関する証明書確認を１回だけ、例えば、ライセンス１６が、ＤＲＭシステム１８のライセンスイバリュエータ３６によって最初に評価されるときにだけ要求することにより、その障害を最小限に抑えることができる。その場合、署名確認が行われたかどうかに関する状態情報がまとめられなければならず、またその状態情報は、ＤＲＭシステム１８の状態ストア４０の中に記憶されなければならない。
【０１４２】
デジタル権利ライセンス４８
本発明の一実施形態では、ライセンスイバリュエータ３６が、ライセンス１６の権利記述または権利条項としてデジタル権利ライセンス（ＤＲＬ）４８を評価して、ＤＲＬ４８により、求める仕方で対応するデジタルコンテンツ１２をレンダリングすることが許されるかどうかが判定される。本発明の一実施形態では、ＤＲＬ４８は、任意のＤＲＬ言語でライセンサ（ｌｉｃｅｎｓｏｒ）（すなわち、コンテンツ所有者）が書くことが可能である。
【０１４３】
理解されるべきこととして、ＤＲＬ４８を指定する多数のやり方が存在する。したがって、あらゆるＤＲＬ言語において高い度合いの柔軟性が見込まれなければならない。ただし、特定のライセンス言語におけるＤＲＬ４８のすべての態様を指定することは実際的ではなく、その言語の作成者が、特定のデジタルライセンサが所望する可能性があるすべての可能なライセンシングの態様を理解できる可能性は、極めて低い。さらに、極めて高度なライセンス言語は、不必要であり、比較的簡単なＤＲＬ４８を提供するライセンサには障害とさえなる可能性がある。それでも、ライセンサは、どのようにＤＲＬ４８を指定すべきかを不必要に制限してはならない。同時に、ライセンスイバリュエータ３６は、いくつかの特定のライセンス問題に関して常にＤＲＬ４８から回答を得ることができなければならない。
【０１４４】
本発明では、図１１を参照すると、ＤＲＬ４８は、任意のライセンス言語で指定することができるが、言語識別子、または言語タグ５４を含む。ライセンス１６を評価するライセンスイバリュエータ３６が、言語タグ５４を検討して言語を識別する予備ステップを行い、次に、その識別された言語でライセンス１６にアクセスするのに適切なライセンス言語エンジン５２を選択する。理解されるべきこととして、ライセンス言語エンジン５２は、存在し、ライセンスイバリュエータ３６がアクセスできなければならない。存在しない場合、言語タグ５４および／またはＤＲＬ４８は、好ましくは、言語エンジン５２を獲得するための場所５６（通常、Ｗｅｂサイト）を含む。
【０１４５】
通常、言語エンジン５２は、ハードドライブなどのユーザのコンピューティングデバイス１４のメモリの中に常駐する実行可能ファイル、または１組のファイルの形態をしている。言語エンジン５２は、ライセンスイバリュエータ３６を助けて、ＤＲＬ４８に直接に問合せを行い、ライセンスイバリュエータ３６は、仲介役をする言語エンジン５２等を介してＤＲＬ４８に間接的に問合せを行う。実行されたとき、言語エンジン５２は、ＲＡＭなどの、ユーザのコンピューティングデバイス１４のメモリ内部の作業空間において実行される。ただし、本発明の趣旨および範囲を逸脱することなく、任意の他の形態の言語エンジン５２も使用することができる。
【０１４６】
好ましくは、任意の言語エンジン５２、および任意のＤＲＬ言語が、以下に述べる通り、あらゆるＤＲＬ４８によって応えられることをライセンスイバリュエータ３６が予期する少なくともいくつかの特定のライセンス問題をサポートする。したがって、ライセンスイバリュエータ３６は、何らかの特定のＤＲＬ言語には結び付いておらず、ＤＲＬ４８は、任意の適切なＤＲＬ言語で書くことができ、また、新しいライセンス言語で指定されたＤＲＬ４８が既存のライセンスイバリュエータ３６によって使用されることが、対応する新しい言語エンジン５２をライセンスイバリュエータ３６に獲得させることによって可能になる。
【０１４７】
ＤＲＬ言語
それぞれＤＲＬ４８で実現されたＤＲＬ言語の２つの例を以下に提示する。第１の「簡単な」ＤＲＬ４８は、ライセンス属性を指定するＤＲＬ言語で書かれ、一方、第２の「スクリプト」ＤＲＬ４８は、ＤＲＬ４８の中で指定されたスクリプトに従って機能を行うことができるＤＲＬ言語で書かれる。ＤＲＬ言語で書かれているが、コードの各行の意味は、各行の言語（ｌｉｎｇｕｉｓｔｉｃｓ）、および／または以下の属性記述チャートに基づいて明白なはずである。
【０１４８】
Ｓｉｍｐｌｅ　ＤＲＬ　４８：
＜ＬＩＣＥＮＳＥ＞
＜ＤＡＴＡ＞
＜ＮＡＭＥ＞Ｂｅａｓｔｉｅ　Ｂｏｙ’ｓ　Ｐｌａｙ＜／ＮＡＭＥ＞
＜ＩＤ＞３９３８４＜／ＩＤ＞
＜ＤＥＳＣＲＩＰＴＩＯＮ＞Ｐｌａｙ　ｔｈｅ　ｓｏｎｇ　３　ｔｉｍｅｓ＜／ＤＥＳＣＲＩＰＴＩＯＮ＞　＜ＴＥＲＭＳ＞＜／ＴＥＲＭＳ＞
＜ＶＡＬＩＤＩＴＹ＞
＜ＮＯＴＢＥＦＯＲＥ＞１９９８０１０２　２３：２０：１４Ｚ＜／ＮＯＴＢＥＦＯＲＥ＞＜ＮＯＴＡＦＴＥＲ＞１９９８０１０２　２３：２０：１４Ｚ＜／ＮＯＴＡＦＴＥＲ＞
＜／ＶＡＬＩＤＩＴＹ＞
＜ＩＳＳＵＥＤＤＡＴＥ＞１９９８０１０２　２３：２０：１４Ｚ＜／ＩＳＳＵＥＤＤＡＴＥ＞　＜ＬＩＣＥＮＳＯＲＳＩＴＥ＞ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ＜／ＬＩＣＥＮＳＯＲＳＩＴＥ＞
＜ＣＯＮＴＥＮＴ＞
＜ＮＡＭＥ＞Ｂｅａｓｔｉｅ　Ｂｏｙ’ｓ＜／ＮＡＭＥ＞
＜ＩＤ＞３９２＜／ｌＤ＞
＜ＫＥＹＩＤ＞３９２９２＜／ＫＥＹＩＤ＞
＜ＴＹＰＥ＞ＭＳ　Ｅｎｃｒｙｐｔｅｄ　ＡＳＦ　２．０＜／ＴＴＹＰＥ＞
＜／ＣＯＮＴＥＮＴ＞
＜ＯＷＮＥＲ＞
＜ＩＤ＞９３９ＫＤＫＤ３９３ＫＤ＜／ｌＤ＞
＜ＮＡＭＥ＞Ｕｎｉｖｅｒｓａｌ＜／ＮＡＭＥ＞
＜ＰＵＢＬＩＣＫＥＹ＞＜／ＰＵＢＬＩＣＫＥＹ＞
＜／ＯＷＮＥＲ＞
＜ＬＩＣＥＮＳＥＥ＞
＜ＮＡＭＥ＞Ａｒｎｏｌｄ＜／ＮＡＭＥ＞
＜ＩＤ＞９３９ＫＤＫＤ３９３ＫＤ＜／ｌＤ＞
＜ＰＵＢＬＩＣＫＥＹ＞＜／ＰＵＢＬＩＣＫＥＹ＞
＜／ＬＩＣＥＮＳＥＥ＞
＜ＰＲＩＮＣＩＰＡＬ　ＴＹＰＥ＝＝ＡＮＤ＝＞
＜ＰＲＩＮＣＩＰＡＬ　ＴＹＰＥ＝＝ＯＲ＝＞
＜ＰＲＩＮＣＩＰＡＬ＞
＜ＴＹＰＥ＞ｘ８６Ｃｏｍｐｕｔｅｒ＜／ＴＹＰＥ＞
＜ＩＤ＞３９３９２９２９３９ｄ９ｅ９３９＜／ＩＤ＞
＜ＮＡＭＥ＞Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ＜／ＮＡＭＥ＞
＜ＡＵＴＨＴＹＰＥ＞Ｉｎｔｅｌ　Ａｕｔｈｅｎｔｉｃａｔｅｄ　Ｂｏｏｔ　ＰＣ　ＳＨＡ−１　ＤＳＡ５Ｉ２／ＡＵＴＨＴＹＰＥ＞　＜ＡＵＴＨＤＡＴＡ＞２９２９３９３９＜／ＡＵＴＨＤＡＴＡ＞
＜／ＰＲＩＮＣＩＰＡＬ＞
＜ＰＲＩＮＣＩＰＡＬ＞
＜ＴＹＰＥ＞Ａｐｐｌｉｃａｔｉｏｎ＜／ＴＹＰＥ＞
＜ＩＤ＞２９３９４９５９３９２９２＜／ＩＤ＞
＜ＮＡＭＥ＞Ｗｉｎｄｏｗ＝ｓ　Ｍｅｄｉａ　Ｐｌａｙｅｒ＜／ＮＡＭＥ＞＜ＡＵＴＨＴＹＰＥ＞Ａｕｔｈｅｎｔｉｃｏｄｅ　ＳＨＡ−１＜／ＡＵＴＨＴＹＰＥ＞
＜ＡＵＴＨＤＡＴＡ＞９３９３９＜／ＡＵＴＨＤＡＴＡ＞
＜／ＰＲＩＮＣＩＰＡＬ＞
＜／ＰＲＩＮＣＩＰＡＬ＞
＜ＰＲＩＮＣＩＰＡＬ＞
＜ＴＹＰＥ＞Ｐｅｒｓｏｎ＜／ＴＹＰＥ＞
＜ＩＤ＞３９２９９４８２０１０＜／ＩＤ＞
＜ＮＡＭＥ＞Ａｒｎｏｌｄ　Ｂｌｉｎｎ＜／ＮＡＭＥ＞
＜ＡＵＴＨＴＹＰＥ＞Ａｕｔｈｅｎｔｉｃａｔｅ　ｕｓｅｒ＜／ＡＵＴＨＴＹＰＥ＞＜ＡＵＴＨＤＡＴＡ＞￥￥ｒｅｄｍｏｎｄ￥ａｒｎｏｌｄｂ＜／ＡＵＴＨＤＡＴＡ＞
＜／ＰＲＩＮＣＩＰＡＬ＞
＜／ＰＲＩＮＣＩＰＡＬ＞
＜ＤＲＬＴＹＰＥ＞ＳｉｍｐＩｅ＜／ＤＲＬＴＹＰＥ＞［ｔｈｅ　ｌａｎｇｕａｇｅ　ｔａｇ　５４］
＜ＤＲＬＤＡＴＡ＞
＜ＳＴＡＲＴ＞１９９８０１０２　２３：２０：１４Ｚ＜／ＳＴＡＲＴ＞
＜ＥＮＤ＞１９９８０１０２　２３：２０：１４Ｚ＜／ＥＮＤ＞
＜ＣＯＵＮＴ＞３＜／ＣＯＵＮＴ＞
＜ＡＣＴＩＯＮ＞ＰＬＡＹ＜／ＡＣＴＩＯＮ＞
＜／ＤＲＬＤＡＴＡ＞
＜ＥＮＡＢＬＩＮＧＢＩＴＳ＞ａａａａｂｂｂｂｃｃｃｃｄｄｄｄ＜／ＥＮＡＢＬＩＮＧＢＩＴＳ＞
＜／ＤＡＴＡ＞
＜ＳＩＧＮＡＴＵＲＥ＞
＜ＳＩＧＮＥＲＮＡＭＥ＞Ｕｎｉｖｅｒｓａｌ＜／ＳＩＧＮＥＲＮＡＭＥ＞＜ＳＩＧＮＥＲＩＤ＞９３８２ＡＢＫ３９３９ＤＫＤ＜／ＳＩＧＮＥＲＩＤ＞　＜ＨＡＳＨＡＬＧＯＲＩＴＨＭＩＤ＞ＭＤ５＜／ＨＡＳＨＡＬＧＯＲＩＴＨＭＩＤ＞　＜ＳＩＧＮＡＬＧＯＲＩＴＨＭＩＤ＞ＲＳＡ　１２８＜／ＳＩＧＮＡＬＧＯＲＩＴＨＭＩＤ＞　＜ＳＩＧＮＡＴＵＲＥ＞ｘｘｘｙｙｙｘｘｘｙｙｙｘｘｘｙｙｙ＜／ＳＩＧＮＡＴＵＲＥ＞　＜ＳＩＧＮＥＲＰＵＢＬＩＣＫＥＹ＞＜／ＳＩＧＮＥＲＰＵＢＬＩＣＫＥＹ＞　＜ＣＯＮＴＥＮＴＳＩＧＮＥＤＳＩＧＮＥＲＰＵＢＬＩＣＫＥＹ＞＜／ＣＯＮＴＥＮＴＳＩＧＮＥＤＳＩＧＮＥＲＰＵＢＬＩＣＫＥＹ＞
＜／ＳＩＧＮＡＴＵＲＥ＞
＜／ＬｌＣＥＮＳＥ＞
Ｓｃｒｉｐｔ　ＤＲＬ　４８：
＜ＬＩＣＥＮＳＥ＞
＜ＤＡＴＡ＞
＜ＮＡＭＥ＞Ｂｅａｓｔｉｅ　Ｂｏｙ’ｓ　Ｐｌａｙ＜／ＮＡＭＥ＞
＜ＩＤ＞３９３８４＜／ＩＤ＞
＜ＤＥＳＣＲＩＰＴＩＯＮ＞Ｐｌａｙ　ｔｈｅ　ｓｏｎｇ　ｕｎｌｉｍｉｔｅｄ＜／ＤＥＳＣＲＩＰＴＩＯＮ＞
＜ＴＥＲＭＳ＞＜／ＴＥＲＭＳ＞
＜ＶＡＬＩＤＩＴＹ＞
＜ＮＯＴＢＥＦＯＲＥ＞１９９８０１０２　２３：２０：１４Ｚ＜／ＮＯＴＢＥＦＯＲＥ＞＜ＮＯＴＡＦＴＥＲ＞１９９８０１０２　２３：２０：１４Ｚ＜／ＮＯＴＡＦＴＥＲ＞
＜／ＶＡＬＩＤＩＴＹ＞
＜ＩＳＳＵＥＤＤＡＴＥ＞１９９８０１０２　２３：２０：１４Ｚ＜／ＩＳＳＵＥＤＤＡＴＥ＞　＜ＬＩＣＥＮＳＯＲＳＩＴＥ＞ｈｔｔｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ＜／ＬＩＣＥＮＳＯＲＳＩＴＥ＞
＜ＣＯＮＴＥＮＴ＞
＜ＮＡＭＥ＞Ｂｅａｓｔｉｅ　Ｂｏｙ’ｓ＜／ＮＡＭＥ
＜ＩＤ＞３９２＜／ＩＤ＞
＜ＫＥＹＩＤ＞３９２９２＜／ＫＥＹＩＤ＞
＜ＴＹＰＥ＞ＭＳ　Ｅｎｃｒｙｐｔｅｄ　ＡＳＦ　２．０＜／ＴＴＹＰＥ＞＜／ＣＯＮＴＥＮＴ＞
＜ＯＷＮＥＲ＞
＜ＩＤ＞９３９ＫＤＫＤ３９３ＫＤ＜／ＩＤ＞
＜ＮＡＭＥ＞Ｕｎｉｖｅｒｓａｌ＜／ＮＡＭＥ＞
＜ＰＵＢＬＩＣＫＥＹ＞＜／ＰＵＢＬＩＣＫＥＹ＞
＜／ＯＷＮＥＲ＞
＜ＬＩＣＥＮＳＥＥ＞
＜ＮＡＭＥ＞Ａｒｎｏｌｄ＜／ＮＡＭＥ＞
＜ＩＤ＞９３９ＫＤＫＤ３９３ＫＤ＜／ＩＤ＞
＜ＰＵＢＬＩＣＫＥＹ＞＜／ＰＵＢＬＩＣＫＥＹ＞
＜／ＬＩＣＥＮＳＥＥ＞
＜ＤＲＬＴＹＰＥ＞Ｓｃｒｉｐｔ＜／ＤＲＬＴＹＰＥ＞　　［ｔｈｅ　ｌａｎｇｕａｇｅ　ｔａｇ　５４］
＜ＤＲＬＤＡＴＡ＞
ｆｕｎｃｔｉｏｎ　ｏｎ＿ｅｎａｂｌｅ（ａｃｔｉｏｎ，　ａｒｇｓ）　ａｓ　Ｂｏｏｌｅａｎ
ｒｅｓｕｌｔ　＝　Ｆａｌｓｅ
ｉｆ　ａｃｔｉｏｎ　＝　”ＰＬＡＹ”　ｔｈｅｎ
ｒｅｓｕｌｔ　＝　Ｔｒｕｅ
ｅｎｄ　ｉｆ
ｏｎ＿ａｃｔｉｏｎ　＝　Ｆａｌｓｅ
ｅｎｄ　ｆｕｎｃｔｉｏｎ
．　．　．
＜ＤＲＬＤＡＴＡ＞
＜／ＤＡＴＡ＞
＜ＳＩＧＮＡＴＵＲＥ＞
＜ＳＩＧＮＥＲＮＡＭＥ＞Ｕｎｉｖｅｒｓａｌ＜／ＳＩＧＮＥＲＮＡＭＥ＞　＜ＳＩＧＮＥＲＩＤ＞９３８２＜／ＳＩＧＮＥＲＩＤ＞　＜ＳＩＧＮＥＲＰＵＢＬＩＣＫＥＹ＞＜／ＳＩＧＮＥＲＰＵＢＬＩＣＫＥＹ＞　＜ＨＡＳＨＩＤ＞ＭＤ５＜／ＨＡＳＨＩＤ＞
＜ＳＩＧＮＩＤ＞ＲＳＡ　１２８＜／ＳＩＧＮＩＤ＞
＜ＳＩＧＮＡＴＵＲＥ＞ｘｘｘｙｙｙｘｘｘｙｙｙｘｘｘｙｙｙ＜／ＳＩＧＮＡＴＵＲＥ＞＜ＣＯＮＴＥＮＴＳＩＧＮＥＤＳＩＧＮＥＲＰＵＢＬＩＣＫＥＹ＞＜／ＣＯＮＴＥＮＴＳＩＧＮＥＤＳＩＧＮＥＲＰＵＢＬＩＣＫＥＹ＞＜／ＳＩＧＮＡＴＵＲＥ＞
＜／ＬＩＣＥＮＳＥ＞
以上に指定した２つのＤＲＬ４８では、リストされた属性が、以下の表の記述およびデータタイプを有する。
【０１４９】
【表１】
2004040772.tif 000003
【０１５０】
【表２】
2004040772.tif 000004
【０１５１】
【表３】
2004040772.tif 000005
【０１５２】
メソッド
前述した通り、任意の言語エンジン５２および任意のＤＲＬ言語が、デジタルライセンスイバリュエータ３６が、あらゆるＤＲＬ４８によって応えられるものと予期する少なくともいくつかの特定のライセンス問題をサポートすることが好ましい。サポートされる問題を認識することには、本発明の趣旨および範囲を逸脱することなく、前述した２つのＤＲＬ４８の例で使用した用語法と整合するあらゆる問題が含まれる可能性があり、本発明の一実施形態では、サポートされる問題、つまり「メソッド」には、以下の通り、「アクセスメソッド」、「ＤＲＬメソッド」、および「イネーブル使用（ｅｎａｂｌｉｎｇ　ｕｓｅ）メソッド」が含まれる。
【０１５３】
アクセスメソッド
アクセスメソッドは、最上位レベルの属性に関してＤＲＬ４８にクエリを行うのに使用される。
【０１５４】
ＶＡＲＩＡＮＴ　ＱｕｅｒｙＡｔｔｒｉｂｕｔｅ（ＢＳＴＲ　ｋｅｙ）
有効な鍵は、ＢＳＲＴ　Ｖａｒｉａｎｔをそれぞれが戻すＬｉｃｅｎｓｅ．Ｎａｍｅ、Ｌｉｃｅｎｓｅ．Ｉｄ、Ｃｏｎｔｅｎｔ．Ｎａｍｅ、Ｃｏｎｔｅｎｔ．Ｉｄ、Ｃｏｎｔｅｎｔ．Ｔｙｐｅ、Ｏｗｎｅｒ．Ｎａｍｅ、Ｏｗｎｅｒ．Ｉｄ、Ｏｗｎｅｒ．ＰｕｂｌｉｃＫｅｙ、Ｌｉｃｅｎｓｅｅ．Ｎａｍｅ、Ｌｉｃｅｎｓｅｅ．Ｉｄ、Ｌｉｃｅｎｓｅｅ．ＰｕｂｌｉｃＫｅｙ、Ｄｅｓｃｒｉｐｔｉｏｎ、およびＴｅｒｍｓ、ならびにＤａｔｅ　Ｖａｒｉａｎｔをそれぞれが戻すＩｓｓｕｅｄ、Ｖａｌｉｄｔｙ．Ｓｔａｒｔ、およびＶａｌｉｄｙ．Ｅｎｄを含む。
【０１５５】
ＤＲＬメソッド
以下のＤＲＬメソッドの実装は、ＤＲＬ４８ごとに異なる。ＤＲＬメソッドの多くは、より高度な情報をＤＲＬ４８に伝えることを目的とする「データ」というラベルが付けられた変種のパラメータを含む。これは、現在、主に将来的な拡張性のためのものである。
【０１５６】
Ｂｏｏｌｅａｎ　ＩｓＡｃｔｉｖａｔｅｄ（Ｖａｒｉａｎｔ　ｄａｔａ）
このメソッドは、ＤＲＬ４８／ライセンス１６がアクチベートされているかどうかを示すブーリアン（Ｂｏｏｌｅａｎ）を戻す。アクチベートされたライセンス１６の例は、初回の再生時に４８時間だけアクティブである制限された動作のライセンス１６である。
【０１５７】
Ａｃｔｉｖａｔｅ（Ｖａｒｉａｎｔ　ｄａｔａ）
このメソッドは、ライセンス１６をアクチベートするのに使用される。ライセンス１６は、アクチベートされると、非アクチベートとすることができない。
【０１５８】
Ｖａｒｉａｎｔ　ＱｕｅｒｙＤＲＬ（Ｖａｒｉａｎｔ　ｄａｔａ）
このメソッドは、より高度なＤＲＬ４８と通信するのに使用される。これは、主に、ＤＲＬ４８機能セットの将来的な拡張性に関するものである。
【０１５９】
Ｖａｒｉａｎｔ　ＧｅｔＥｘｐｉｒｅｓ（ＢＳＴＲ　ａｃｔｉｏｎ，Ｖａｒｉａｎｔ　ｄａｔａ）
このメソッドは、提出済みアクション（ｐａｓｓｅｄ−ｉｎ　ａｃｔｉｏｎ）に関するライセンス１６の失効日を戻す。戻り値がＮＵＬＬである場合、ライセンス１６は、決して失効しないか、またはアクチベートされていない等のために、まだ失効日を有さないものと考えられる。
【０１６０】
Ｖａｒｉａｎｔ　ＧｅｔＣｏｕｎｔ（ＢＳＴＲ　ａｃｔｉｏｎ，Ｖａｒｉａｎｔ　ｄａｔａ）
このメソッドは、残っている提出済みアクションの動作の回数を戻す。ＮＵＬＬが戻された場合、その動作は、無制限の回数、行うことができる。
【０１６１】
Ｂｏｏｌｅａｎ　ＩｓＥｎａｂｌｅｄ（ＢＳＴＲ　ａｃｔｉｏｎ，Ｖａｒｉａｎｔ　ｄａｔａ）
このメソッドは、ライセンス１６が、現時点で要求されたアクションをサポートするかどうかを示す。
【０１６２】
Ｂｏｏｌｅａｎ　ＩｓＳｕｎｋ（ＢＳＴＲ　ａｃｔｉｏｎ，Ｖａｒｉａｎｔ　ｄａｔａ）
このメソッドは、ライセンス１６の代金が支払われているかどうかを示す。前払いで代金が支払われているライセンス１６は、ＴＲＵＥを戻し、一方、使用されるにつれて代金を徴収するライセンス１６などの、前払いで代金が支払われていないライセンス１６は、ＦＡＬＳＥを戻す。
【０１６３】
イネーブル使用メソッド
このメソッドは、コンテンツを解読する際に使用するためにライセンス１６をイネーブルにするのに使用される。
【０１６４】
Ｂｏｏｌｅａｎ　Ｖａｌｉｄａｔｅ（ＢＳＴＲ　ｋｅｙ）
このメソッドは、ライセンス１６を検証するのに使用される。提出済みの鍵は、ライセンス１６の署名の検証で使用するための対応するデジタルコンテンツ１２に関する暗号解読鍵（ＫＤ）で暗号化されたブラックボックス３０公開鍵（ＰＵ−ＢＢ）（すなわち、（ＫＤ（ＰＵ−ＢＢ）））である。ＴＲＵＥの戻り値は、ライセンス１６が有効であることを示す。ＦＡＬＳＥの戻り値は、無効を示す。
【０１６５】
ｉｎｔ　ＯｐｅｎＬｉｃｅｎｓｅ　１６（ＢＳＴＲ　ａｃｔｉｏｎ，ＢＳＴＲ　ｋｅｙ，Ｖａｒｉａｎｔ　ｄａｔａ）
このメソッドは、解読されたイネーブルビット（ｅｎａｂｌｉｎｇ　ｂｉｔ）にアクセスする準備をするのに使用される。提出済みの鍵は、前述した通り、（ＫＤ（ＰＵ−ＢＢ））である。０の戻り値が、成功を示す。その他の戻り値は、定義することができる。
【０１６６】
ＢＳＴＲ　ＧｅｔＤｅｃｒｙｐｔｅｄＥｎａｂｌｉｎｇＢｉｔｓ（ＢＳＴＲ　ａｃｔｉｏｎ，Ｖａｒｉｎａｔ　ｄａｔａ）
Ｖａｒｉａｎｔ　ＧｅｔＤｅｃｒｙｐｔｅｄＥｎａｂｌｉｎｇＢｉｔｓＡｓＢｉｎａｒｙ（ＢＳＴＲ　ａｃｔｉｏｎ，Ｖａｒｉａｎｔ　Ｄａｔａ）
このメソッドは、解読された形態のイネーブルビットにアクセスするのに使用される。いくつかの理由のどれかのためにそれが成功しなかった場合、空のストリング、または空のバリアント（ｖａｒｉａｎｔ）が戻される。
【０１６７】
ｖｏｉｄ　ＣｌｏｓｅＬｉｃｅｎｓｅ（ＢＳＴＲ　ａｃｔｉｏｎ，Ｖａｒｉａｎｔ　ｄａｔａ）
このメソッドは、提出済みアクションを行うためにイネーブルビットへのアクセスをロック解除するのに使用される。いくつかの理由のどれかのためにこれが成功しなかった場合、空のストリングが戻される。
【０１６８】
ヒューリスティック
前述した通り、同一のデジタルコンテンツ１２に関して複数のライセンス１６が存在する場合、ライセンス１６の１つが、さらなる使用のために選択されなければならない。前述したメソッドを使用して、この選択を行うために以下のヒューリスティックを実施することが可能である。詳細には、デジタルコンテンツ１２に対してアクション（例えば、「再生」）を行うため、以下のステップを行うことが可能である。
【０１６９】
１．特定のデジタルコンテンツ１２に適用されるすべてのライセンス１６を獲得する。
２．アクションを可能にしない各ライセンス１６を、そのライセンス１６に対してＩｓＥｎａｂｌｅｄファンクションを呼び出すことによって除去する。
３．アクティブでない各ライセンス１６を、そのライセンス１６に対してＩｓＡｃｔｉｖａｔｅｄを呼び出すことによって除去する。
４．前払いで代金が支払われていない各ライセンス１６を、そのライセンス１６に対してＩｓＳｕｎｋを呼び出すことによって除去する。
５．何らかのライセンス１６が残っている場合、そのライセンス１６を使用する。特に、無制限回数の再生のライセンス１６が失効日を有する場合、無制限回数の再生のライセンス１６を使用してから、制限された回数の再生のライセンス１６を使用する。あらゆる時点で、ユーザは、既に獲得された特定のライセンス１６を選択することが、その選択の費用対効果が大きくない場合でも、許されていなければならない。したがって、ユーザは、ＤＲＭシステム３２には、場合により、明白でない基準に基づいてライセンス１６を選択することができる。
６．ライセンス１６が全く残っていない場合、そのことを示すステータスを戻す。次に、ユーザに、以下のオプションが与えられる。すなわち、
前払いで代金が支払われていないライセンス１６が利用可能である場合、そのライセンス１６を使用すること、
あるライセンス１６が利用可能である場合、そのライセンス１６をアクチベートすること、かつ／または
ライセンスサーバ２４からのライセンス獲得を行うこと。
【０１７０】
比較的単純なデバイスのための単純化された暗号解読
理解されるべきこととして、以上に述べたＤＲＭアーキテクチャ１０は、とりわけ、ユーザのコンピューティングデバイス１４が、コンテンツ１２をレンダリングするライセンス１６を受け取るのに先立って、アーキテクチャの中の正当なＤＲＭ構成要素として自らを認証するようにさせることによってデジタルコンテンツ１２を保護する技術である。この認証は、署名された証明書、交渉、非対称鍵および対称鍵の交換等を含む対話式プロセスを含み、対話式プロセスは、コンピューティングデバイス１４と、ライセンスサーバ２４などの遠隔のエンティティの間でネットワーク接続等を介して達せられる。
【０１７１】
ただし、一部の場合では、コンテンツ１２がレンダリングされるデバイスは比較的小さく、および／または単純であり、前述した対話式プロセスにおいて非対称鍵暗号解読を行うことや、ネットワーク接続等を介して遠隔のエンティティと通信することなどの比較的複雑な機能を有さないことを理解されたい。代わりに、比較的小さく、および／または単純なデバイスは、通常、記憶媒体上でコンテンツ１２等を受け取るか、またはホストコンピュータから内部メモリの中にコンテンツ１２等をダウンロードすることができる。したがって、デバイスが非対称鍵暗号解読を行う必要がなく、Ｗｅｂ接続またはネットワーク接続を要さない、ＤＲＭアーキテクチャ１０を比較的小さく、および／または単純なデバイスにも適用するメカニズムおよび方法の必要性が存在する。
【０１７２】
簡単に述べると、本発明では、デバイスは、デバイス鍵（ＤＫ）、および何らかの形態のＤＲＭシステムを与えられることによって事前許可（ｐｒｅ−ａｕｔｈｏｒｉｚｅ）を受け、許可は、テーブルを介して確認され、ＤＲＭシステムは、（ＤＫ）を使用して、パスワードまたはさらなる暗号解読鍵などの秘密を解明する。テーブルは、磁気データディスク、または光データディスク、あるいはデータカードなどの事前記録された媒体上で、またはデバイスのメモリに対する直接のコンテンツのブロードキャスト、またはその他の大量配布（ｍａｓｓ　ｐｕｂｌｉｃａｔｉｏｎ）においてコンテンツ１２に付随することが可能である。デバイスは、テーブル内部へのアクセスを可能にする（ＤＫ）およびＤＲＭシステムを有することにより、コンテンツ１２を使用することが許可される。
【０１７３】
次に、図１３を参照すると、デジタルコンテンツ１２を獲得し、レンダリングする１つの様式において、デジタルコンテンツ１２がソース６０からダウンロードされ、記憶媒体６１上に置かれるのが見られ、記憶媒体６１は、比較的小さく、および／または単純なデバイス６２に装てんされるか、あるいはデバイス６２内部にある。ソース６０は、ソース６０と記憶媒体６１の間で適切な接続が存在しなければならないことに留意して、本発明の趣旨および範囲を逸脱することなく、任意の適切なソースであることが可能である。同様に、記憶媒体６１も、本発明の趣旨および範囲を逸脱することなく、任意の適切な媒体であることが可能である。
【０１７４】
例えば、ソース６０は、コンテンツ１２が提供される場所である、またはコンテンツ１２の提供が媒介されるホストコンピュータ、遠隔のサーバロケーション、またはホストコンピュータとサーバロケーションの組合せであることが可能である。同様に、記憶媒体６１は、光ディスク、磁気ディスク、メディアカードなどのようにポータブルであることが可能であり、あるいはデバイス６２の内部メモリであることが可能である。前者の場合、例えば、コンテンツ１２、および関連するデータは、キオスク、場合によっては小売店にあるソース６０からダウンロードされることが可能である。内部メモリである場合、例えば、デバイス６２が、例えば、ホストコンピュータなどのソース６０に結合され、コンテンツ１２および関連するデータが、デバイス６２に直接にダウンロードされることが可能である。
【０１７５】
本発明の一実施形態では、コンテンツ１２が媒体６１にダウンロードされる際、対応するデジタルライセンス１６も獲得され、ダウンロードされるか、または別の仕方で媒体６１上に置かれる。ライセンス１６は、媒体６１のために獲得されるライセンスであることが可能であり、あるいは例えば、ホストコンピュータなどの別のコンピューティングデバイス１４のために獲得されたライセンス１６から導出されたサブライセンス１６ｓであることが可能である。ライセンス１６からサブライセンス１６ｓを導出するための方法は、２００１年６月２７日に出願した文献に記載している（例えば、特許文献１または２参照）。あるいは、獲得されたコンテンツ１２が、内部に獲得されたライセンス１６を含むことが可能である。
【０１７６】
通常、デバイス６２は、コンテンツを解読すること、コンテンツをレンダリングすることなどのプレーヤ動作のために比較的少量のメモリを保留している。比較的少量のメモリでは、デバイス６２は、非対称（すなわち、公開鍵−秘密鍵）暗号解読を行うことができない可能性が高い。したがって、本発明の一実施形態では、デバイス６２は、デバイス６２上のメモリの中でインスタンス化されるポータブルＤＲＭシステム３２ｐ（図１３）だけを使用して対称暗号解読を行う。
【０１７７】
本発明の一実施形態では、前述した文献（例えば、特許文献１または２参照）に開示した題材の場合と同様に、媒体６１に関してデジタルコンテンツ１２、および対応するデジタルライセンス１６またはサブライセンス１６を獲得することはすべて、例えば、自宅のパーソナルコンピュータ、または小売店におけるキオスクにあるコンピュータなどのホストコンピュータ等を使用して行われる。詳細には、ホストコンピュータは、対応するデジタルコンテンツ１６に関するライセンス１６を獲得し、次に（必要な場合）、デバイス６２上でデジタルコンテンツ１２をレンダリングするためにサブライセンス１６ｓを媒体６１に発行する。サブライセンス１６ｓは、本発明の趣旨および範囲を逸脱することなく、ソース６０から媒体６１にデジタルコンテンツをダウンロードしている最中に発行されること、またはソース６０から媒体６１にデジタルコンテンツ１２をダウンロードする前、またはダウンロードした後のある時点で発行されることが可能である。
【０１７８】
理解することができるように、サブライセンス１６ｓが発行される場合、発行されたサブライセンス１６ｓは、デバイス６２において媒体６１上で対応するコンテンツ１２をレンダリングするのに満たされなければならない制限が存在する場合、その制限を指定することができる。もちろん、サブライセンス１６ｓは、適切なライセンスサーバ２４から獲得された対応するライセンス１６の条項に従って許可される場合にだけ、発行することができる。サブライセンス１６ｓを発行する際、サブライセンス１６ｓの少なくとも一部分が、デバイス６２により適した形態に書き換えられる。詳細には、コンピュータ６０が、コンテンツ１２を解読するためのコンテンツ鍵（ＫＤ）を、デバイス６２による暗号解読により適した形態に暗号化しなおす。この場合、本発明の一実施形態では、コンテンツ鍵は、媒体６１上のテーブル６４の中に記憶された対称鍵に従って暗号化しなおされ、対称鍵は、デバイス６２のデバイス鍵（ＤＫ）に従って暗号化されている。
【０１７９】
詳細には、コンピュータ６０上のライセンス１６の中のコンテンツ鍵（ＫＤ）が、前述した仕方でホストコンピュータのブラックボックス公開鍵（ＰＵ−ＢＢ−ＨＣ）などの非対称鍵に従って暗号化されているものと想定すると、ホストコンピュータは、前述した仕方でホストコンピュータのブラックボックス秘密鍵（ＰＲ−ＢＢ−ＨＣ）のブラックボックス秘密鍵を適用することによってコンテンツ鍵（ＫＤ）を獲得し、少なくともデバイス６２の対称鍵（ＤＫ）に従ってコンテンツ鍵（ＫＤ）を暗号化しなおす。したがって、理解されるべきこととして、コンテンツ鍵（ＫＤ）は、（ＤＫ）およびサブライセンス１６ｓの適用によって適切な時点で、デバイス６２による獲得が可能である。理解されるべきこととして、コンテンツ鍵（ＫＤ）を暗号化しなおすことなしには、（ＰＲ−ＢＢ−ＨＣ）を知らないデバイス６２は、（ＰＵ−ＢＢ−ＨＣ（ＫＤ））を解読して（ＫＤ）を獲得することができない。
【０１８０】
サブライセンス１６ｓを作成するための手続きは、前述した文献（例えば、特許文献１または２参照）により詳細に記載されており、したがって、本明細書で詳述するまでもないない。本発明に鑑みて必要なこの手続きのあらゆる変形形態は、文献（例えば、特許文献１または２参照）に基づいて当分野の技術者一般には明白であろう。
【０１８１】
やはり図１３を参照すると、デジタルコンテンツ１２、および対応するライセンス１６またはサブライセンス１６ｓを媒体６１にダウンロードするため、媒体６１は、本発明の趣旨および範囲を逸脱することなく、任意の適切な接続であることが可能な接続６３を介してソース６０に結合しなければならない。理解することができるように、媒体６１が何らかの形態のポータブルの書込み可能なストレージである場合、接続６３は、媒体６１が装てんされる適切なドライブである。同様に、媒体６１が、デバイス６２内部にある場合、接続６３は、適切なケーブル、ＲＦリンクまたはＩＲリンクなどの無線リンク等であることが可能である。接続６３、および接続６３をサポートするハードウェアおよび／またはソフトウェアは、周知であるか、または当分野の技術者一般には明白なはずであり、したがって、本明細書でより詳細に説明するまでもないない。
【０１８２】
注目すべきこととして、デバイス６２は、その単純さに基づき、特に信頼に値するものと考えることができる。つまり、単純なデバイス６２は、限られた機能およびアクセス可能性を有することが可能であり、したがって、コンテンツ泥棒、または他の不正な個人による攻撃に対して特に強い。したがって、そのような状況では、サブライセンス１６ｓは、絶対に必要ではない。代わりに、コンテンツ１２は、テーブル６４を介してデバイス６２に利用可能な対称鍵に従って暗号化された媒体６１上に配置することが可能であり、デバイス６２は、テーブル６４の対称鍵を使用してその暗号化されたコンテンツ１２を自在にレンダリングすることができる。もちろん、これを行うためには、ホストコンピュータ６０によって獲得されたコンテンツ１２を、前述したのと同様の仕方で対称鍵に従って解読し、次に暗号化しなおさなければならない可能性が高い。これを行うための詳細および方法は、本開示に基づいて当分野の技術者一般には明白であろう。
【０１８３】
あるいは、コンテンツ１２は、暗号化されていない形態で媒体６１上に置かれるが、テーブル６４を介してパスワード等がデバイス６２に利用可能な場合にだけそのデバイスがアクセスできることが可能であり、デバイス６２は、テーブル６４の中のパスワードを使用して暗号化されたコンテンツ１２を自在にレンダリングすることができる。この場合も、ホストコンピュータ６０によって獲得されたコンテンツ１２を解読し、次に、パスワード保護しなければならない可能性が高い。これを行うための詳細および方法は、当分野の技術者一般には明白であろう。
【０１８４】
前述した通り、媒体６１上のコンテンツ１２にアクセスするためのコンテンツ鍵（ＫＤ）、コンテンツ１２に関するパスワード等（以降、「秘密」）は、少なくともデバイス６２のデバイス鍵（ＤＫ）に従って暗号化される。デバイス６２は、本発明では、本発明の趣旨および範囲を逸脱することなく、実際には、その機能が存在することが可能であるが、デバイス鍵（ＤＫ）を媒体６１、またはホストコンピュータ６０に伝えることができないものと想定されている。したがって、コンテンツ１２に関するコンテンツ鍵（ＫＤ）の暗号化を行うエンティティは、デバイス鍵（ＤＫ）を既に所有していなければならない。注目すべきこととして、数百万、あるいはそれより多くのデバイス６２が存在する可能性があり、各デバイス６２が、独自の固有であるものとされるデバイス鍵（ＤＫ）を有する可能性がある。しかし、前述した暗号化を行うエンティティが、すべてのデバイス６２に関する固有のデバイス鍵（ＤＫ）を知っていることは期待できない可能性が高い。
【０１８５】
したがって、本発明の一実施形態では、各デバイス６２が、固有でないデバイス鍵（ＤＫ）を有し、これにより、前述したエンティティが所有していなければならないデバイス鍵（ＤＫ）の数が、扱いやすいレベルに保たれる。それでも、各デバイス６２は、本発明の趣旨および範囲を逸脱することなく、独自の固有のデバイス鍵（ＤＫ）を有することも可能である。ただし、各デバイス６２が固有でないデバイス鍵（ＤＫ）を有するものと想定すると、固有でないデバイス鍵（ＤＫ）をデバイス６２に配布することを、本発明の趣旨および範囲を逸脱することなく、任意の適切なやり方で行うことができる。例えば、デバイス６２の各製造業者に特定のデバイス鍵（ＤＫ）を割り当てることが可能であり、これにより、その製造業者によって製造されたすべてのデバイス６２が、その製造業者特有の（ＤＫ）を備える。同様に、デバイス６２の各モデル６２に特定の（ＤＫ）を割り当てることが可能である。同様に、デバイス６２の各製造業者、または各モデルに、デバイス６２の特定のものにランダムに、または意図的に提供されたいくつかのデバイス鍵（ＤＫ）を割り当てることが可能である。
【０１８６】
媒体６１に保護されたコンテンツ１２（暗号化されているか、またはパスワード保護されている）をダウンロードするホストコンピュータ６０は、媒体６１がどのデバイス６２に装てんされるか、またはどのデバイス６２の内部にあるかを必ずしも知らない。したがって、図１３に見られる通り、本発明の一実施形態では、ホストコンピュータ６０は、テーブル６４もダウンロードし、テーブル６４は、既知のいくつかのデバイス鍵（ＤＫ）のそれぞれに従って暗号化されたコンテンツ１２の秘密を中に有している。見られる通り、それぞれの暗号化された秘密は、その秘密を暗号化したデバイス鍵（ＤＫ）の識別子を指定する対応するインデックス値を有する。
【０１８７】
本発明の一実施形態では、テーブル６４は、対応するコンテンツ１２をレンダリングするのに使用されるデバイス６２のデバイス鍵（ＤＫ）に従って暗号化された秘密を中に含む。テーブル６４は、本発明の趣旨および範囲を逸脱することなく、ホストコンピュータ６０に既知であるすべてのデバイス鍵（ＤＫ）に従って、またはそのデバイス鍵（ＤＫ）のサブセットに従って暗号化された秘密を有することが可能であることに留意されたい。例えば、ダウンロードを実行するユーザが、デバイス６２がある特定の製造業者によって製造されていることを指定することができ、したがって、テーブル６４は、その製造業者のすべてのデバイス鍵（ＤＫ）に従って暗号化された秘密を含む。同様に、ユーザは、デバイス６２がいくつかの特定のデバイス６２のどれかである可能性があることを指定することができ、したがって、テーブル６４は、そのいくつかの特定のデバイス６２のすべてのデバイス鍵（ＤＫ）に従って暗号化された秘密を含む。
【０１８８】
次に、媒体６１上のコンテンツ１２をレンダリングするため、デバイス６２は、そのコンテンツ１２に対応する媒体６１上のテーブル６４を参照し、デバイス６２のデバイス鍵（ＤＫ）に従って暗号化された秘密を指し示す。詳細には、図１４を参照すると、デバイス６２は、コンテンツ１２をレンダリングするように指示されると（ステップ１４０１）、デバイス６２自らに対応するテーブル６４を獲得し（ステップ１４０３）、デバイス６２自らのデバイス鍵（ＤＫ）、および（ＤＫ）のインデックス値を獲得し（ステップ１４０５）、獲得されたインデックス値に基づいてテーブル６４の中を指し示し（ステップ１４０７）、対応する暗号化された秘密を選択する（ステップ１４０９）。次に、デバイス６２は、獲得されたデバイス鍵（ＤＫ）を暗号化された秘密に適用してその秘密を露見させ（ステップ１４１１）、露見された秘密を適用して対応するコンテンツ１２をレンダリングする（ステップ１４１３）。例えば、秘密を使用してコンテンツ１２を解読することができる場合、または秘密をライセンス１６またはサブライセンス１６ｓに適用してコンテンツ１２のレンダリングを可能にすることができる場合、秘密により、コンテンツ１２のレンダリングが直接に可能になることに留意されたい。
【０１８９】
本発明の一実施形態では、媒体６１上のテーブル６４は、媒体６１上の複数のコンテンツ１２に対応する共通のテーブル６４であり、複数のコンテンツ１２のそれぞれが、単一の共通の秘密によって保護されている。したがって、媒体６１上の複数のコンテンツ１２のどれをレンダリングするのにも、デバイスは、共通のテーブル６４を参照して共通の秘密を獲得するだけでよい。したがって、図１４に示したのと実質的に同じ方法を使用することができる。
【０１９０】
前述した通り、ホストコンピュータ６０によって生成されたテーブル６４は、ホストコンピュータ６０に既知のすべてのデバイス鍵（ＤＫ）に従って、またはそのデバイス鍵（ＤＫ）のサブセットに従って暗号化された秘密を有することが可能である。サブセットに従って暗号化された秘密を有する場合、テーブル６４の中のサブセットからデバイス鍵（ＤＫ）を排除することにより、対応するデバイス６２が、対応するコンテンツ１２をレンダリングすることが防止される。すべてのデバイス鍵（ＤＫ）に従って暗号化された秘密を有する場合、対応する暗号化された秘密に関してテーブル６４の中のフィールドを空白のままにすることにより、対応するデバイス６２がコンテンツ１２をレンダリングすることが、同様に防止される。あるいは、そのフィールドを、わけのわからない話または無意味なデータなどの何らかの代わりのデータで埋めることができる。
【０１９１】
本発明の一実施形態では、各デバイス６２が、単一ではないより多くのデバイス鍵（ＤＫ）を備える。したがって、デバイス６２は、コンテンツ１２をレンダリングするのに必要な秘密を露見させるものが見出されるまで、テーブル６４に対して各（ＤＫ）を使用することを試みる。この実施形態では、デバイス６２を（例えば、信頼に値しないものとして）無効にすることが必要であると判明した場合、ホストコンピュータは、そのデバイス６２のデバイス鍵（ＤＫ）のすべてに対応するエントリをテーブル６４から除外しなければならない。そのような状況では、デバイス鍵Ａ、Ｂ、Ｃ、およびＤを有する無効にされたデバイス６２により、テーブル６４からのデバイス鍵Ａ、Ｂ、Ｃ、およびＤの「取消し」がもたらされる。そのような状況では、デバイス鍵Ｂ、Ｃ、Ｄ、およびＥを有するデバイス６２は、それでも、デバイス鍵Ｅも取り消されているのではないものと想定すると、テーブル６４で、デバイス鍵Ｅをインデックスとする秘密にアクセスすることができるが、鍵Ｂ、Ｃ、またはＤをインデックスとする秘密にはアクセスすることができない。
【０１９２】
本発明の一実施形態では、ホストコンピュータ６０は、媒体６１にダウンロードされるテーブル６４を作成する際、および媒体にダウンロードされるコンテンツ１２を保護する際、テーブル６４およびコンテンツ１２を媒体６１に結び付ける。したがって、テーブル６４およびコンテンツ１２は、他の媒体６１に自由に移すことができない。この場合、コンテンツ１２を結び付けることは、テーブル６４から露見された秘密と、媒体６１を識別するＩＤの組合せである最終の秘密を使用してコンテンツ１２を露見させることによって行われる。媒体６１のＩＤは、本発明の趣旨および範囲を逸脱することなく、任意の適切なＩＤであることが可能である。例えば、ＩＤは、媒体６１に永久的に関連付けられた通し番号であることが可能である。最終の秘密は、例えば、ＳＨＡアルゴリズムまたはＨＭＡＣアルゴリズムに基づいて獲得されることが可能な秘密およびＩＤの一方向ハッシュであることが可能である。したがって、最終の秘密を分解して秘密にすることは容易に行うことができない。
【０１９３】
本発明の一実施形態では、テーブル６４は、媒体６１のＩＤを秘密裏に組み込むことによって媒体６１に結び付けられる。ＩＤは、テーブル６４に付けられる署名のための少なくとも１つの基準として使用することによってテーブルに秘密裏に組み込むことができる。あるいは、ＩＤをテーブル６４の秘密によって暗号化する、または署名することができる。
【０１９４】
理解されるべきこととして、媒体６１のＩＤは、テーブル６４を構成し、媒体６１に対してコンテンツ１２を準備するのに先立ってホストコンピュータ６０から収集され、テーブル６４およびコンテンツ１２は、実際、媒体６１に結び付けられるようにホストコンピュータ６０によって構成され／準備される。次に、テーブル６４が媒体６１に関連付けられていることを確認するため、図１５を次に参照すると、デバイス６２が、媒体６１からのＩＤにアクセスし（ステップ１５０１）、テーブル６４からのＩＤにアクセスし（ステップ１５０３）、その２つのＩＤを比較してそれらが一致するかどうかを判定する（ステップ１５０５）。一致する場合、レンダリングに取りかかることが許可される（ステップ１５０７）。ステップ１５０３でテーブル６４からのＩＤにアクセスすることには、テーブル６４の署名を確認して、アクセスされたＩＤが不正変更されていないことを確かめること（ステップ１５０３ａ）、または露見された秘密を暗号化されたＩＤに適用して（図１４のステップ１４１１）ＩＤを明らかにすること（ステップ１５０３ｂ）が関わる可能性がある。
【０１９５】
コンテンツ１２が媒体６１に関連付けられていることを確認するため、デバイス６２は、露見された秘密および確認されたＩＤをハッシュに適用して最終の秘密を生成する（ステップ１５０９）。もちろん、最終の秘密が、コンテンツ１２のレンダリングをうまく可能にするかどうかの確認が行われる（ステップ１５１１）。デバイス６２は、媒体からのＩＤにアクセスし（ステップ１５０１）、露見された秘密およびアクセスされたＩＤをハッシュに適用して最終の秘密を生成する（ステップ１５０９）ことだけにより、ＩＤの確認を単純化できることに留意されたい。生成された最終の秘密により、コンテンツ１２をレンダリングすることに失敗した場合、デバイス６２は、その失敗を説明する目的でテーブル６４を確認することができる。
【０１９６】
前述した通り、媒体６１のＩＤに基づくテーブル６４の第１の署名を使用して、テーブル６４に関連付けられたＩＤを確認することができる。同様に、テーブル全体、またはテーブルの一部分が、許可を与えるエージェントによって提供された第２の署名の基準であることが可能である。第２の署名は、コンテンツ１２をレンダリングするのにデバイス６４によって必要とされていないが、新しいコンテンツ１２を既存のテーブル６４とともに媒体６１に追加するデバイスまたはアプリケーションのためのセキュリティ上の予防策として使用することができる。詳細には、第２の署名は、既存のテーブル６４が、不正なエンティティによってではなく、許可を与えるエージェントによって作成されたことを確認する。また、第２の署名は、テーブル６４のバージョン番号（以下を参照）を検証するのに役立ち、したがって、テーブル６４の「新しさ（ｆｒｅｓｈｎｅｓｓ）」を検証するのに役立つ。
【０１９７】
媒体６１上のテーブル６４内の詳細は、ときどき更新される、または変更される必要がある可能性があることを認識されたい。例えば、デバイス６２が無効にされ、デバイス６２に関するデバイス鍵（ＤＫ）に関するテーブルエントリを除去する必要があり、および／または新しいエントリを追加する必要があり、および／またはテーブル６４の秘密を変更する必要がある可能性がある。特に、媒体６１が更新される可能性があるが、同時に古いコンテンツ１２および古い機能を保持しなければならないとき、困難が生じる。ホストコンピュータ６０が、新しい（保護された）コンテンツ１２を媒体６１に書き込み、古い（保護された）コンテンツが媒体６１上に既に存在するとき、特にテーブル６４が比較的古い場合、これが当てはまる。この場合、本発明の一実施形態では、古い秘密を有する媒体６１上の古いテーブル６４が、新しい秘密を有する新しい更新されたテーブル６４で置き換えられる。新しい秘密を有する新しいテーブル６４は、もちろん、その新しい秘密で保護された媒体６１上の新しいコンテンツ１２をサポートする。重要なこととして、新しいテーブル６４は、古い秘密によって保護される媒体６１上の古いコンテンツ１２もサポートしなければならない。無効にされたデバイス６２を含むすべてのデバイス６２が、古いコンテンツ１２に対するアクセスを保持しなければならない。
【０１９８】
これは、テーブル６４自体、およびテーブル６４の中の各エントリに、アドミニストレータによって保持されるマスタテーブル６８との関係で減少しないバージョン値が与えられる図１６に示したようなテーブルによって達せられる。アドミニストレータは、本発明の趣旨および範囲を逸脱することなく、任意の適切なエンティティであることが可能であり、マスタテーブル６８の中で、任意のテーブル６４の中に入れられる可能性があるすべての対称デバイス鍵（ＤＫ）を保持することを主に担う。
【０１９９】
各デバイス鍵（ＤＫ）に加えて、アドミニストレータは、例えば、各デバイス鍵（ＤＫ）に関するインデックス値や有効フラグなどの情報をマスタテーブル６８の中で保持することもできる。理解することができるように、アドミニストレータは、デバイス鍵（ＤＫ）がもはや信頼に値しなくなり、したがって、無効にされるときを決定するか、または別のエンティティからその決定を受け取り、それに応じて、そのデバイス鍵（ＤＫ）に関する有効フラグにマークを付ける。もちろん、マスタテーブル６８は、本発明の趣旨および範囲を逸脱することなく、その他の情報を有することが可能である。重要なこととして、マスタテーブル６８は、バージョン値も含み、アドミニストレータがマスタテーブル６８を変更するたびに毎回、マスタテーブル６８のバージョン値がインクリメントされる。このバージョン値は、バージョン番号、日付、またはその他の増加する値であることが可能である。
【０２００】
秘密（Ｎ）を有する媒体６１上のテーブル（Ｎ）が新しい秘密（Ｎ＋１）を有する新しいテーブル（Ｎ＋１）６４で置き換えられるたびに毎回、その後に媒体６１上に置かれた新しいコンテンツ１２が、新しい秘密（Ｎ＋１）にリンクされる。同時に、あらゆる新しいテーブル６４の中で、各秘密（Ｎ）が、前の秘密（Ｎ−１）を暗号化して保護して、媒体６１にそれまで関連付けられたすべての秘密、および媒体６１上のコンテンツ１２が、秘密の「デイジーチェーン」からアクセス可能であるようにする。これにより、デイジーチェーン内の特定の秘密にアクセスすることができるデバイス６２が、拡張により、デイジーチェーン内のすべてのより早期の秘密にアクセスすることが可能になるが、より後の秘密のどれにもアクセスすることができない。もちろん、デバイス６２は、無効にされているのでない限り、媒体６１の最新の秘密にアクセスすることができなければならない。
【０２０１】
以上のことに基づき、媒体６１上のコンテンツ１２およびテーブル６４を簡便にし、実現し、サポートするための方法について以下に述べる。
【０２０２】
次に、図１７を参照すると、媒体６１上に全くテーブル６４がない状態で媒体６１に新しい秘密のテーブル６４を書き込むのに、ホストコンピュータ６０は、まず、キャッシュ６６（図１３）からテーブル６４を獲得する（ステップ１７０１）。キャッシュ６６は、少なくとも１つの秘密テーブル６４を含み、各テーブル６４は、テーブルサーバ等（図示せず）を使用してマスタテーブル６８、およびマスタテーブル６８のアドミニストレータから獲得された相異なる秘密に基づいている。キャッシュ６６に配信されるテーブルサーバによる、またはテーブルサーバのためのテーブル６４の生成は、本発明の趣旨および範囲を逸脱することなく、任意の適切な方法によって行われることが可能である。
【０２０３】
例えば、テーブル６４を生成するのに、テーブルサーバまたは別のデバイスは、マスタリストおよび乱数発生器にアクセスを有することが可能であり、乱数発生器を使用して秘密の値を生成することができる。次に、マスタリストの中のそれぞれ有効なデバイス鍵（ＤＫ）に関して、そのデバイス鍵（ＤＫ）を使用して、生成された秘密を暗号化し、暗号化された秘密が、生成中のテーブル６４の中に適切に入れられる。ただし、マスタテーブル６８の中のそれぞれの無効なデバイス鍵（ＤＫ）に関しては、秘密は、その鍵（ＤＫ）によって暗号化されず、生成中のテーブル６４の中には入れられないことに留意されたい。代わりに、（ＤＫ−Ｘ（ＳＥＣＲＥＴ））のためのスペースは、単に空白のままにされるか、または０などの何らかの所定の値で埋められる。さらに、マスタリストのバージョン番号が、生成中のテーブル６４のバージョン番号として採用され、適切な場所でテーブル６４の中に入れられ、テーブル６４のバージョン番号を含むテーブル６４が、アドミニストレータ、または別のエンティティ（すなわち、前述した許可を与えるエージェント）の秘密鍵によって署名される。
【０２０４】
この場合、理解されるべきこととして、デマンド等に基づき、適切な時点で１つまたは複数のテーブル６４がキャッシュ６６の中に入れられる。あるいは、新しいテーブル６４が、キャッシュ６６として動作しているテーブルサーバから直接にオンデマンドで獲得されることが可能である。ホストコンピュータ６４は、本発明の趣旨および範囲を逸脱することなく、キャッシュ６６からのテーブル６４を１回、または複数回、使用できることに留意されたい。
【０２０５】
デバイス６２と同様に、ホストコンピュータ６０は、任意のテーブル６４の中を指し示すデバイス鍵（ＤＫ）を有する。したがって、ホストコンピュータ６０は、デバイス鍵（ＤＫ）、およびデバイス鍵（ＤＫ）のインデックス値を使用して、獲得されたテーブル６４の中で対応するエントリを見出し、そのテーブル６４の秘密を明らかにする（ステップ１７０３）。ホストコンピュータ６０は、いくつかのデバイス鍵（ＤＫ）を有することが可能であることに留意されたい。獲得されたテーブル６４の中の鍵エントリのどれも、最新のテーブルバージョンに一致しない場合、ホストコンピュータのデバイス鍵（ＤＫ）は陳腐化しているか、または取り消されており、更新してからでないと、媒体６１に全くコンテンツ１２を書き込むことができない。
【０２０６】
獲得されたテーブル６４の秘密が明らかにされると、ホストコンピュータは、媒体６１のＩＤ番号を獲得し（ステップ１７０５）、そのＩＤ番号を獲得されたテーブル６４に付加する（ステップ１７０７）。このテーブル６４は、媒体６１上に置かれる最初のものであるので、ホストコンピュータ６０は、０または１などのバージョン番号をテーブルに割り当てるか、またはテーブル６４が、バージョン番号を既に含んでいる。次に、ホストコンピュータ６０は、媒体６１のＩＤ番号が実際に使用されると想定すると、秘密で暗号化または署名を行って、そのＩＤ番号を使用してテーブル６４を媒体６１に結び付け（ｂｉｎｄ）る（ステップ１７０９）。その後、ホストコンピュータ６０は、テーブル６４を媒体６１にコピーする（ステップ１７１１）。
【０２０７】
次に、媒体６１が、自らの上にテーブル６４を既に有しており、新しいコンテンツ１２を受け取るものと想定して、図１８を参照すると、ホストコンピュータが、媒体６１上のテーブル６４を検査して、テーブルの中の署名が検証されるかどうかを調べる（ステップ１８０１）。検証されない場合、媒体６１は、不良である可能性が高く、再フォーマットされなければならない。さらに、ホストコンピュータ６０は、媒体６１上でテーブルのバージョン番号、および／またはその他の情報を獲得し（ステップ１８０１）、そのバージョン番号および／またはその他の情報に基づいてテーブル６４が陳腐化しているかどうかを判定する（ステップ１８０３）。例えば、ホストコンピュータ６０は、獲得されたバージョン番号、および／またはその他の情報に基づき、テーブル６４が比較的古いこと、またはテーブル６４が、ある無効にされたデバイス６２を反映していないことを判定することができる。加えて、または別法として、新しいコンテンツ１２に対応するライセンス１６の中の条項により、テーブル６４がより新しいバージョン番号に更新されることが必要とされることが可能である。例えば、媒体６１上のテーブル６４のバージョン番号が４０であり、および条項により、そのバージョン番号が少なくとも６０であることが要求される場合、テーブル６４を更新しなければならない。
【０２０８】
媒体６１上のテーブル６４が実際に更新されなければならない場合、ホストコンピュータは、既に媒体６１上にある第Ｎ番のテーブル６４と置き換わる新しい第（Ｎ＋１）番のテーブル６４を生成して（ステップ１８０５）、その第（Ｎ＋１）番のテーブル６４を媒体６１の上に置く（ステップ１８０７）。詳細には、図１８Ａを参照すると、ホストコンピュータは、第（Ｎ＋１）番の秘密を有する第（Ｎ＋１）番のテーブル６４をキャッシュ６６から獲得し（ステップ１８０５ａ）、図１７の通り、第（Ｎ＋１）番の秘密を獲得し（ステップ１８０５ｂ）、図１７の通り、第（Ｎ＋１）番のテーブル６４を媒体６１に結び付け（ｂｉｎｄ）る（ステップ１８０５ｃ）。キャッシュ６６を使用してテーブルサーバから獲得された第（Ｎ＋１）番のテーブル６４は、適切な場所により新しいバージョン番号を既に有していることに留意されたい。また、ホストコンピュータ６０は、媒体６１上の第Ｎ番のテーブル６４から第Ｎ番の秘密を獲得し、また、存在する場合、第Ｎ番のテーブル６４の中で前の秘密のデイジーチェーンを獲得する（ステップ１８０５ｄ）。次に、ホストコンピュータは、獲得されたデイジーチェーンを１つだけ拡張して、第（Ｎ＋１）番の秘密に従って暗号化された第Ｎ番の秘密を秘密のデイジーチェーンの中の次のリンクとしてそのデイジーチェーンに追加し（ステップ１８０５ｅ）、拡張されたデイジーチェーンを第（Ｎ＋１）番のテーブル６４に付加する（ステップ１８０５ｆ）。
【０２０９】
また、ホストコンピュータ６０は、無効にされたデバイス鍵（ＤＫ）に関する古い秘密を含むように第（Ｎ＋１）番のテーブルを調整することも行い、各エントリにバージョン番号を割り当てる。詳細には、ホストコンピュータ６０は、第（Ｎ＋１）番のテーブル６４から、どのデバイス鍵（ＤＫ）が無効にされているかを判定し（ステップ１８０５ｇ）、それぞれの無効にされた（ＤＫ）に関して、第Ｎ番のテーブル６４の中の対応するエントリ、ならびにその対応するエントリのバージョン番号で第（Ｎ＋１）番のテーブル６４の中のエントリを埋める（ステップ１８０５ｈ）。ホストコンピュータ６０は、例えば、第（Ｎ＋１）番のテーブルの中のどのエントリが空であるか、または０などの何らかの所定の値で埋められているかを判定することにより、第（Ｎ＋１）番のテーブル６４か、どのデバイス鍵（ＤＫ）が無効にされているかを判定することができることに留意されたい。
【０２１０】
次に、ホストコンピュータ６０は、第（Ｎ＋１）番のテーブル６４のバージョン番号を、第（Ｎ＋１）番のテーブル６４の中の変更されていない、したがって、依然として有効であるすべてのデバイス鍵エントリに割り当てる。あるいは、第（Ｎ＋１）番のテーブル６４を生成したテーブルサーバが、この割当てを既に行っている。したがって、有効なデバイス鍵（ＤＫ）を有する有効なデバイス６２は、第（Ｎ＋１）番のテーブル６４の最新の（第（Ｎ＋１）番）の秘密にアクセスすることができる。これに相応して、無効にされたデバイス鍵（ＤＫ）を有する無効にされたデバイス６２は、第（Ｎ＋１）番のテーブル６４の中の対応する秘密にアクセスすることができるが、秘密は、媒体６１に関する前のテーブル６４のものであり、第（Ｎ＋１）番のテーブル６４からのものではない。以上に述べた通り、このアクセスされた秘密を使用して、デバイス６２は、拡張により、デイジーチェーンの中のより早期のすべての秘密にアクセスすることができるが、より後の秘密のどれにもアクセスすることはできない。
【０２１１】
第（Ｎ＋１）番のテーブルの中のエントリが適切に調整されると、ホストコンピュータ６０は、図１７の通り、第（Ｎ＋１）番の秘密で第（Ｎ＋１）番のテーブル６４に暗号化または署名を行って、媒体６１のＩＤ番号を使用して第（Ｎ＋１）番のテーブル６４を媒体６１に結び付け（ｂｉｎｄ）る（ステップ１８０５ｉ）。最後に、ステップ１８０７で、第（Ｎ＋１）番のテーブル６４が媒体６１にコピーされて、媒体６１上の第Ｎ番のテーブル６４が置き換えられる。
【０２１２】
次に、媒体６１が自らの上に、現行の秘密マスタテーブル６８に相対するバージョン番号、ＩＤ番号、ならびに、拡張により、その秘密およびＩＤ番号から導出可能な最終の秘密を有する現行のテーブル６４を有するものと想定して、ホストコンピュータ６０が、コンテンツ１２を媒体６１に書き込むことができる。これを行うため、図１９を参照すると、ホストコンピュータ６０は、媒体６１からＩＤ番号を獲得し（ステップ１９０１）、媒体６１上のテーブル６４から秘密を獲得し（ステップ１９０３）、そのテーブル６４の署名を確認し（ステップ１９０５）、そのテーブル６４の中のＩＤ番号が、媒体６１のＩＤ番号に一致することを確認する（ステップ１９０７）。確認が肯定的であったものと想定すると、次に、ホストコンピュータ６０は、獲得された秘密とそのＩＤ番号を組み合わせて、前述した通り所定の関数に従って最終の秘密を決定し（ステップ１９０９）、媒体６１に書き込まれるべきコンテンツ１２をその最終の秘密に従って暗号化し（ステップ１９１１）、これにより、そのコンテンツ１２を媒体６１に結び付け（ｂｉｎｄ）、暗号化されたコンテンツ１２を媒体６１にコピーする（ステップ１９１３）。その後、ホストコンピュータ６０は、必要に応じて適宜、あらゆる適切なコピー後アクションを行うことができる。例えば、コンテンツ１２が、金銭上の取引の一環として供給された場合、ホストコンピュータは、その取引に完了したものとしてマークを付けること、口座に課金すること、カウント値をインクリメントまたはデクリメントすること等を行うことができる。
【０２１３】
図１９に関連して行われるステップは、媒体６１が装てんされる、または内部にあるデバイス６２が、有効であるかどうか、したがって、有効なデバイス鍵（ＤＫ）を有するかどうかを考慮に入れないことに留意されたい。実際、ホストコンピュータ６０は、媒体６１にコンテンツ１２を書き込むのに先立ってこの問題を確認する手立てを有していない可能性が高い。コンテンツ１２が、無効にされたデバイスによって媒体６１上のテーブル６４においてアクセス可能な何らかの秘密より後の秘密に従って暗号化されており、無効にされているデバイス６２が、実際に、媒体６１上でコンテンツ１２をレンダリングしようと試みた場合、その試みは失敗する。
【０２１４】
コンテンツ１２が、媒体６１にコピーされると、そのコンテンツ１２は、適合するソフトウェアを有し、および媒体６１を読み取ることができ、および媒体６１を受け入れることができる（媒体６１が、デバイス６２とは別個である場合）任意のデバイス６２によってレンダリングされることが可能である。もちろん、デバイス６２は、適切なＤＲＭシステム３２ｓ、および媒体６１上のテーブル６４の中を指し示す対称デバイス鍵（ＤＫ）を有していなければならない。さらに、デバイス６２は、テーブル６４において取り消されているか、無効にされており、テーブル６４において、コンテンツ１２をレンダリングするのに必要な秘密にアクセスすることができないわけにはいかない。
【０２１５】
媒体６１上のコンテンツ１２をデバイス６２がレンダリングするのに、図２０を参照すると、デバイス６２は、媒体６１、および媒体６１上のテーブル６４からＩＤ番号を獲得し（ステップ２００１）、媒体６１のＩＤ番号を媒体６１上のテーブル６４の中のＩＤ番号と比較して、そのテーブル６４がその媒体６１に属することを確認する（ステップ２００３）。比較が成功したものと想定すると、デバイス６２は、次に、レンダリングされるコンテンツ１２に関連するバージョン番号を獲得する（ステップ２００５）。コンテンツ１２のバージョン番号は、本発明の趣旨および範囲を逸脱することなく、任意の適切な場所にあることが可能であり、コンテンツ１２を保護するのに秘密が使用されたテーブル６４のバージョン番号に一致する。例えば、バージョン番号は、コンテンツ１２を媒体６１にダウンロードするのに先立ってホストコンピュータ６０によってコンテンツ１２の中に入れられる、またはコンテンツ１２に付加されることが可能であり、あるいはホストコンピュータによってコンテンツ１２に付随するライセンス１６またはサブライセンス１６ｓの中に入れられることが可能である。
【０２１６】
次に、デバイス６２は、デバイス６２自らのデバイス鍵のインデックス値を使用して、対応する暗号化された秘密、およびその秘密のバージョン番号をテーブル６４から獲得する（ステップ２００７）。理解することができるとおり、次に、デバイス６２は、獲得された暗号化された秘密の最高のバージョン番号が、コンテンツ１２のバージョン番号より低いかどうかを判定する。低い場合、そのコンテンツ１２をデバイスがレンダリングすることはできない（ステップ２００９）。低くない場合、コンテンツ１２のバージョン番号に等しいか、それより大きいバージョン番号を有する暗号化された秘密の１つが選択される（ステップ２０１１）。選択された暗号化された秘密は、コンテンツ１２のバージョン番号を有し、デイジーチェーンを辿ることが全く必要ないようになっているか、またはコンテンツ１２のバージョン番号に最も近く、デイジーチェーンを辿ることが可能な限り短いようになっていなければならない。
【０２１７】
次に、デバイス６２は、選択された暗号化された秘密に対応するデバイス６２自らのデバイス鍵（ＤＫ）を獲得し（ステップ２０１３）、そのデバイス鍵（ＤＫ）を適用してその秘密を明らかにする（ステップ２０１５）。必要な場合、次に、明らかにされた秘密を使用して、コンテンツ１２を保護するのに使用された秘密に戻るまでテーブル６４の中のデイジーチェーンを辿り、これにより、コンテンツ１２の秘密が明らかにされる（ステップ２０１７）。理解されるべきこととして、選択された暗号化された秘密のバージョン番号を使用して、どこでデイジーチェーンに入るかが決められ、デバイス６２は、コンテンツ１２の秘密を明らかにする適切なバージョン番号に戻るまでデイジーチェーンの中を辿る。
【０２１８】
コンテンツ１２の秘密が明らかにされると、その秘密、および媒体６１のＩＤ番号を適用して最終の秘密を決定し（ステップ２０１９）、次に、コンテンツ１２に対応する何らかの対応するライセンス１６またはサブライセンス１６ｓが満たされていると想定すると、その最終の秘密を使用してコンテンツ１２をレンダリングすることができる。
【０２１９】
媒体上に既に存在する第Ｎ番のテーブル６４と置き換わる第（Ｎ＋１）番のテーブル６４を媒体に提供する最中に、第（Ｎ＋１）番のテーブル６４のバージョン番号が、第Ｎ番のテーブル６４の次のバージョン番号ではない可能性があることに留意されたい。代わりに、図１６にあるように、第Ｎ番のテーブル６４が、マスタテーブル６８のバージョン番号１９から生成されており、したがって、１９というバージョン番号を有し、また第（Ｎ＋１）番のテーブル６４が、マスタテーブル６８のバージョン番号２５から生成されており、したがって、２５というバージョン番号を有することが可能である。媒体６１にダウンロードされたすべてのコンテンツ１２は、現行のテーブル６４の秘密に従って保護されており、また媒体６１上のテーブル６４は、秘密１９を有するバージョン番号１９から、秘密２５を有するバージョン番号２５に変更されているので、テーブル６４がバージョン番号１９に変更された後にダウンロードされたコンテンツ１２が、秘密１９または秘密２５以外の何らかの秘密によって保護されていることが可能であることはあり得そうにない。
【０２２０】
前述した通り、テーブルサーバ等によって生成されたテーブル６４は、アドミニストレータ、または別の適切なエンティティの秘密鍵によって署名される。ただし、図１８のステップ１８０５ｈで、ホストコンピュータ６０が、第Ｎ番のテーブル６４の中の対応するエントリ、ならびにその対応するエントリのバージョン番号で、それぞれの無効にされた（ＤＫ）に関する第（Ｎ＋１）番のテーブル６４の中のエントリを埋める。したがって、ホストコンピュータ６０が、図１９のステップ１９０５でテーブルサーバ署名を確認するとき、その確認は、ホストコンピュータ６０が、まず、テーブルサーバ署名の時点で、それぞれの埋められるエントリが、それの状態を反映するように整えられない限り失敗する。この調整は、当分野の技術者一般には明白なはずであり、本明細書で詳述するまでもないない。
【０２２１】
図面に関連して説明した通り、テーブル６４から獲得された秘密、または最終の秘密により、コンテンツ１２自体が解読されるか、またはコンテンツ１２へのアクセスが提供される。同等に、コンテンツ鍵がコンテンツ１２の中、コンテンツ１２に関するライセンス１６またはサブライセンス１６ｓの中、または別の場所にある場合、テーブル６４から獲得された秘密、または最終の秘密により、コンテンツ１２に関するコンテンツ鍵が解読されるか、またはコンテンツ鍵に対するアクセスが提供されることが可能である。理解することができるとおり、秘密、または最終の秘密に従ってコンテンツ鍵を保護することは、コンテンツ１２を何らかの特定の媒体に特有のやり方で保護する必要がないことを意味する。それでも、コンテンツ１２は、コンテンツ鍵によってだけアクセス可能であることにより、媒体６１に結び付けられており、コンテンツ鍵は、媒体６１上のテーブル６４の秘密、または最終の秘密によって保護されていることにより、媒体６１に結び付けられている。
【０２２２】
やはり、図面に関連して説明した通り、バージョン番号は、マスタテーブル６８とともに進む。ただし、代わりに、バージョン番号は、本発明の趣旨および範囲を逸脱することなく、例えば、媒体６１とともに進むことも可能である。バージョン番号が、媒体６１とともに進む場合、ホストコンピュータ６０は、とりわけ、第Ｎ番のテーブル６４のバージョン番号を判定し、媒体６１のための第（Ｎ＋１）番のテーブル６４を生成する際にバージョン番号をインクリメントすることを担うことに留意されたい。
【０２２３】
マスタテーブル６８のバージョン番号が増加するにつれ、あらゆるテーブル６４の中で有効なデバイス鍵エントリが、ますます少なくなる。したがって、マスタテーブル６８およびテーブル６４を拡張して新しいエントリを追加することが望ましい可能性がある。例えば、マスタテーブル６８が、１０のエントリ、１〜１０を有するものと想定する。時間の経過とともに、エントリの基礎であるデバイス鍵（ＤＫ）が漏洩し、マスタテーブル６８の中で無効にされる。マスタテーブル６８の中で単一の有効なエントリ（例えば、３）が残された時点で、エントリ１１〜２０を追加することによってマスタテーブル６８を拡張することが決定される。したがって、すべての新しいテーブル６４は、エントリ１、２、および４〜１０が無効であり、エントリ３、および１１〜２０が有効である拡張されたマスタテーブル６８に基づく。次に、エントリ３、および１１〜２０に対応するデバイス鍵（ＤＫ）を、新しいコンテンツ１２を読み取るために次世代のデバイス６２に配布することができる。
【０２２４】
極めて重要なこととして、無効にされる最後のデバイス鍵（例えば、ＤＫ−９）も、次世代のデバイス６２に配布される。つまり、すべての新しいデバイス６２が、エントリ９に対応するデバイス鍵（ＤＫ−９）を含んでいなければならない。（ＤＫ−９）は既に危うくなっているが、さらなる配布により、その侵入（ｐｅｎｅｔｒａｔｉｏｎ）が弱まることはない。ただし、すべての「第１世代」のコンテンツ１２は、（ＤＫ−９）を有効であると見なしているので、（ＤＫ−９）は、第１世代のコンテンツ１２へのアクセスを提供するように第１世代のコンテンツ１２によって使用されることが可能である。
【０２２５】
以上のようにして、最後に無効にされたデバイス鍵（ＤＫ）は、特別の価値を有する。このデバイス鍵（ＤＫ）は漏洩しているので、広く配布することができる。このデバイス鍵（ＤＫ）は、「第２世代」の拡張されたテーブル６４の発行まで、取り消されていないので、すべての第１世代のコンテンツ１２へのアクセスを提供する。したがって、最後の無効にされたデバイス鍵（ＤＫ）は、２つの世代を橋渡しする作用をし、また新しいテーブル６４を拡張するための極めて重要な要素として作用する。この例では、（ＤＫ−３）も、すべての古いコンテンツ１２へのアクセスを提供するため、橋渡しの作用をすることが可能であるが、まだ漏洩していないので、あまり広汎に配布することがためらわれることに留意されたい。
【０２２６】
本発明は、対称暗号化および対称暗号解読だけを行うことができる単純なデバイス６２を特に対象としているが、本発明は、非対称暗号化および非対称暗号解読を行う単純なデバイス６２、または任意の他のデバイスによっても使用されることが可能である。もちろん、これを行うのに、テーブル６４の中の特定のエントリが、秘密鍵に従ってテーブル６４の秘密を暗号化し、デバイスが、対応する公開鍵を有することになる。非対称暗号化および非対称暗号解読に対応するのに必要な他の変更は、当分野の技術者一般には明白なはずであり、したがって、本明細書で詳述する必要がない。
【０２２７】
結論
本発明は、前述したような限られた機能を有する比較的小さく、および／または単純なデバイス６２に関連して特に有用であるが、本発明は、本発明の趣旨および範囲を逸脱することなく、例えば、パーソナルコンピュータ、サーバ、インテリジェント機器など、比較的単純であるか、比較的複雑であるかに関わらず、任意の適切なデバイスに関連して実施することができる。より詳細には、本発明を使用して、例えば、ＣＤプレーヤが、保護された音楽を有するＣＤを再生することができるようにすること、セットトップボックスが、有料テレビジョン放送にアクセスを有することを可能にすること等が可能である。したがって、「単純なデバイス」は、デバイス鍵（ＤＫ）を有し、およびコンテンツ１２、および付随する秘密のテーブル６４を受け取り、受け取られたコンテンツ１２をレンダリングする秘密を（ＤＫ）に基づいてテーブルから獲得する任意のデバイス６２等を包含するものと解釈されたい。
【０２２８】
本発明に関連して行われるプロセスを実施するのに必要なプログラミングは、比較的簡単であり、該当のプログラミング分野の技術者一般（ｒｅｌｅｖａｎｔｐｒｏｇｒａｍｍｉｎｇ　ｐｕｂｌｉｃ）には明白であるはずである。したがって、そのプログラミングは、本明細書には添付しない。したがって、本発明の趣旨および範囲を逸脱することなく、任意の特定のプログラミングを使用して本発明を実施することができる。
【０２２９】
以上の説明では、本発明が、デジタル権利管理アーキテクチャ１０を比較的小さく、および／または単純なデバイス６２にも適用することを可能にする新しく、有用な方法およびメカニズムを含むことを見て取ることができる。このアーキテクチャ１０により、コンテンツ１２をレンダリングするデバイス６２が比較的小さく、および／または単純であり、また非対称鍵暗号解読を行うことや、ネットワーク接続等を介して遠隔のエンティティと通信することなどの比較的複雑な機能を有していなくても、その比較的小さいデバイス６２上でコンテンツ１２に関する暗号化、およびデータ保護が可能になる。本発明の概念を逸脱することなく、前述した実施形態に変更を加えることができることを理解されたい。したがって、本発明は、開示した特定の実施形態には限定されず、頭記の特許請求の範囲によって定義される本発明の趣旨および範囲に含まれる変更形態を範囲に含むものとする。
【図面の簡単な説明】
【図１】本発明の一実施形態による行使アーキテクチャを示すブロック図である。
【図２】本発明の一実施形態による図１のアーキテクチャのオーサリングツールを示すブロック図である。
【図３】本発明の一実施形態による図１のアーキテクチャに関連して使用するためのデジタルコンテンツを有するデジタルコンテンツパッケージを示すブロック図である。
【図４】本発明の一実施形態による図１のユーザのコンピューティングデバイスを示すブロック図である。
【図５Ａ】本発明の一実施形態によるコンテンツをレンダリングする図４のコンピューティングデバイスのデジタル権利管理（ＤＲＭ）システムに関連して行われるステップを示す流れ図である。
【図５Ｂ】本発明の一実施形態によるコンテンツをレンダリングする図４のコンピューティングデバイスのデジタル権利管理（ＤＲＭ）システムに関連して行われるステップを示す流れ図である。
【図６】本発明の一実施形態による何らかの有効な、使用を可能にする（ｅｎａｂｌｉｎｇ）ライセンスが存在するかどうかを判定する図４のＤＲＭシステムに関連して行われるステップを示す流れ図である。
【図７】本発明の一実施形態によるライセンスを獲得する図４のＤＲＭシステムに関連して行われるステップを示す流れ図である。
【図８】本発明の一実施形態による図１のアーキテクチャに関連して使用されるデジタルライセンスを示すブロック図である。
【図９】本発明の一実施形態による新しいブラックボックスを獲得する図４のＤＲＭシステムに関連して行われるステップを示す流れ図である。
【図１０】本発明の一実施形態によるライセンスおよびデジタルコンテンツを検証し、そのコンテンツをレンダリングする図４のＤＲＭシステムに関連して行われる主要なトランザクションステップを示す流れ図である。
【図１１】本発明の一実施形態による図４のライセンスイバリュエータをライセンスのデジタル権利ライセンス（ＤＲＬ）およびＤＲＬを解釈するための言語エンジンとともに示すブロック図である。
【図１２】本発明の態様、および／または態様の部分を組み込むことができる汎用コンピュータシステムを示すブロック図である。
【図１３】本発明の一実施形態による単純なデバイス、ホストコンピュータ、ならびにホストコンピュータによって書き込まれ、デバイスによって読み取られる秘密テーブルおよび暗号化されたコンテンツを有する記憶媒体を示すブロック図である。
【図１４】コンテンツをレンダリングする際に図１３のデバイスによって行われる主要なステップを示す流れ図である。
【図１５】コンテンツをレンダリングする際に図１３のデバイスによって行われる主要なステップを示す流れ図である。
【図１６】図１３のホストコンピュータによって第Ｎ番のテーブルから導出された第（Ｎ＋１）番のテーブルを示すブロック図である。
【図１７】媒体に対して新しいテーブルを獲得する際に図１３のホストコンピュータによって行われる主要なステップを示す流れ図である。
【図１８】媒体上のテーブルを置き換える際に図１３のホストコンピュータによって行われる主要なステップを示す流れ図である。
【図１８Ａ】媒体上のテーブルを置き換える際に図１３のホストコンピュータによって行われる主要なステップを示す流れ図である。
【図１９】媒体上にコンテンツを書き込む際に図１３のホストコンピュータによって行われる主要なステップを示す流れ図である。
【図２０】コンテンツをレンダリングする際に図１３のデバイスによって行われるさらなる主要なステップを示す流れ図である。
【符号の説明】
１０　アーキテクチャ
１２　デジタルコンテンツ
１２ｐ　デジタルコンテンツパッケージ
１６　デジタルライセンス
１８　オーサリングツール
１８ａ　ソースフィルタ
１８ｂ　符号化フィルタ
１８ｃ　暗号化フィルタ
１８ｄ　ヘッダフィルタ
１８ｅ　多重化フィルタ
１８ｆ　ファイルライタフィルタ
２０　コンテンツ−鍵データベース
２２　コンテンツサーバ
２４　ライセンスサーバ
２６　ブラックボックスサーバ
２８　辞書
２９ｃ　メモリ
３０　ブラックボックス
３２，３２ｐ　ＤＲＭシステム
３４　レンダリングアプリケーション
３６　ライセンスイバリュエータ
３８　ライセンスストア
４０　状態ストア
４２　マシン情報
４４　ユーザ情報
４６　システムクロック
５０　発行済みライセンスデータベース
６０　ソース／ホストコンピュータ
６１　記憶媒体
６２　デバイス
６３　接続
６４　テーブル
６８　マスタテーブル
７６　キャッシュ
１２０　コンピュータ
１２１　処理ユニット
１２２　システムメモリ
１２３　システムバス
１２７　ハードドライブ
１２８　フロッピー（登録商標）ドライブ
１２９，１３１　ストレージ
１３０　光ドライブ
１３３　磁気ディスクドライブＩ／Ｆ
１３４　光ドライブＩ／Ｆ
１３６　アプリケーションプログラム
１３７　他のプログラム
１３８　プログラムデータ
１４０　キーボード
１４２　マウス
１４６　シリアルポートＩ／Ｆ
１４７　モニタ
１４８　ビデオアダプタ
１４９　遠隔コンピュータ
１５０　メモリ
１５３　ネットワークＩ／Ｆ
１５４　モデム
１５５　ホストアダプタ
１５６　ＳＣＳＩバス
１６２　記憶デバイス
【図１】
2004040772.tif 000006
【図２】
2004040772.tif 000007
【図３】
2004040772.tif 000008
【図４】
2004040772.tif 000009
【図５Ａ】
2004040772.tif 000010
【図５Ｂ】
2004040772.tif 000011
【図６】
2004040772.tif 000012
【図７】
2004040772.tif 000013
【図８】
2004040772.tif 000014
【図９】
2004040772.tif 000015
【図１０】
2004040772.tif 000016
【図１１】
2004040772.tif 000017
【図１２】
2004040772.tif 000018
【図１３】
2004040772.tif 000019
【図１４】
2004040772.tif 000020
【図１５】
2004040772.tif 000021
【図１６】
2004040772.tif 000022
【図１７】
2004040772.tif 000023
【図１８】
2004040772.tif 000024
【図１８Ａ】
2004040772.tif 000025
【図１９】
2004040772.tif 000026
【図２０】
2004040772.tif 000027
【外国語明細書】
2004040772.tif 000028
2004040772.tif 000029
2004040772.tif 000030
2004040772.tif 000031
2004040772.tif 000032
2004040772.tif 000033
2004040772.tif 000034
2004040772.tif 000035
2004040772.tif 000036
2004040772.tif 000037
2004040772.tif 000038
2004040772.tif 000039
2004040772.tif 000040
2004040772.tif 000041
2004040772.tif 000042
2004040772.tif 000043
2004040772.tif 000044
2004040772.tif 000045
2004040772.tif 000046
2004040772.tif 000047
2004040772.tif 000048
2004040772.tif 000049
2004040772.tif 000050
2004040772.tif 000051
2004040772.tif 000052
2004040772.tif 000053
2004040772.tif 000054
2004040772.tif 000055
2004040772.tif 000056
2004040772.tif 000057
2004040772.tif 000058
2004040772.tif 000059
2004040772.tif 000060
2004040772.tif 000061
2004040772.tif 000062
2004040772.tif 000063
2004040772.tif 000064
2004040772.tif 000065
2004040772.tif 000066
2004040772.tif 000067
2004040772.tif 000068
2004040772.tif 000069
2004040772.tif 000070
2004040772.tif 000071
2004040772.tif 000072
2004040772.tif 000073
2004040772.tif 000074
2004040772.tif 000075
2004040772.tif 000076
2004040772.tif 000077
2004040772.tif 000078
2004040772.tif 000079
2004040772.tif 000080
2004040772.tif 000081
2004040772.tif 000082
2004040772.tif 000083
2004040772.tif 000084
2004040772.tif 000085
2004040772.tif 000086
2004040772.tif 000087
2004040772.tif 000088
2004040772.tif 000089
2004040772.tif 000090
2004040772.tif 000091
2004040772.tif 000092
2004040772.tif 000093
2004040772.tif 000094
2004040772.tif 000095
2004040772.tif 000096
2004040772.tif 000097
2004040772.tif 000098
2004040772.tif 000099
2004040772.tif 000100
2004040772.tif 000101
2004040772.tif 000102
2004040772.tif 000103
2004040772.tif 000104
2004040772.tif 000105
2004040772.tif 000106
2004040772.tif 000107
2004040772.tif 000108
2004040772.tif 000109
2004040772.tif 000110
2004040772.tif 000111
2004040772.tif 000112
2004040772.tif 000113
2004040772.tif 000114
2004040772.tif 000115
2004040772.tif 000116
2004040772.tif 000117
2004040772.tif 000118
2004040772.tif 000119
2004040772.tif 000120
2004040772.tif 000121
2004040772.tif 000122
2004040772.tif 000123
2004040772.tif 000124
2004040772.tif 000125
2004040772.tif 000126
2004040772.tif 000127
2004040772.tif 000128
2004040772.tif 000129
2004040772.tif 000130
2004040772.tif 000131
2004040772.tif 000132
2004040772.tif 000133
2004040772.tif 000134
2004040772.tif 000135
2004040772.tif 000136
2004040772.tif 000137
2004040772.tif 000138