(57)【要約】  デジタル著作権管理を実行するためのシステムおよび方法を記載する。一実施形態において、リクエストされたコンテンツのアクセスまたは他の使用が認可されるか否かを決定するために、保護されたコンテンツに関連するライセンスを評価するデジタル著作権管理エンジンが提供される。一部の実施形態において、ライセンスは、デジタル著作権管理エンジンによって実行可能な制御プログラムを含む。【選択図】図２９
2009512096.tif 000002
【特許請求の範囲】
【請求項１】
ホストコンピュータシステム上の電子コンテンツへのアクセスを認可する方法であって、
前記ホストコンピュータシステムのユーザから前記電子コンテンツにアクセスするリクエストを受信し、
前記電子コンテンツに関連するライセンスを検索することであって、前記ライセンスは、制御オブジェクトと、コントローラオブジェクトと、プロテクタオブジェクトと、コンテンツ鍵オブジェクトとを含み、
前記制御オブジェクトから第１制御プログラムを検索し、
前記リクエストが認可され得るか否かを決定するために、前記ホストコンピュータシステム上で実行するデジタル著作権管理エンジンを使用して前記第１制御プログラムを実行し、前記制御プログラムを実行することは１つ以上のリンクオブジェクトを評価することを含み、前記各リンクオブジェクトは２つのエンティティの関係を表し、前記１つ以上のリンクオブジェクトの少なくとも１つは第２制御プログラムを含み、
前記１つ以上のリンクオブジェクトを評価することは、リンクが有効であるか否かを決定するために、前記デジタル著作権管理エンジンを使用して前記第２制御プログラムを実行することを含み、前記実行することは、前記制御プログラムによって表現される１つ以上の条件が満たされるか否かを決定することを含む、方法。
【請求項２】
前記コントローラオブジェクトが、前記制御オブジェクトを前記コンテンツ鍵オブジェクトに安全に結合するように操作可能である、請求項１に記載の方法。
【請求項３】
前記プロテクタオブジェクトが、前記コンテンツ鍵オブジェクトを前記電子コンテンツに安全に結合するように操作可能である、請求項１に記載の方法。
【請求項４】
前記１つ以上の条件のうちの少なくとも１つが、現在時刻が定義済みの時間の前であるという必要条件を含む、請求項１に記載の方法。
【請求項５】
前記１つ以上の条件のうちの少なくとも１つが、現在時刻が一定の時刻の後であるという必要条件を含む、請求項１に記載の方法。
【請求項６】
前記１つ以上の条件のうちの少なくとも１つが、前記第２制御プログラムが定義済みの回数よりも多く前もって実行していないという必要条件を含む、請求項１に記載の方法。
【請求項７】
前記１つ以上の条件のうちの少なくとも１つが、メモリに格納されたカウンタが定義済みの値を超過しないという必要条件を含む、請求項１に記載の方法。
【請求項８】
前記１つ以上の条件のうちの少なくとも１つが、定義済みのイベントが前もって生じていないという必要条件を含む、請求項１に記載の方法。
【請求項９】
前記１つ以上の条件のうちの少なくとも１つが、前記ホストコンピュータシステムが１つ以上の定義済みの特性を有しなければならないという必要条件を含む、請求項１に記載の方法。
【請求項１０】
前記１つ以上の条件のうちの少なくとも１つが、前記電子コンテンツをレンダリングするための前記ホストコンピュータシステム上で実行するソフトウェアが前記電子コンテンツを定義済みのインタフェースにエクスポートすることができないという必要条件を含む、請求項１に記載の方法。
【請求項１１】
電子コンテンツ上で所与のアクションが実行されることを認可する方法であって、
第１デジタル著作権管理エンジン上で実行する仮想マシンを使用して第１制御プログラムを実行し、前記第１制御プログラムは、前記所与のアクションが前記電子コンテンツ上で実行され得るか否かを決定するように操作可能であり、前記第１制御プログラムは、前記所与のアクションの実行が認可されるために満たされなければならない１つ以上の条件の第１セットを評価するように操作可能であり、前記１つ以上の条件の第１セットのうちの少なくとも１つは、１つ以上のリンクオブジェクトが前記デジタル著作権管理エンジンに利用可能であるという必要条件を含み、前記リンクオブジェクトは、第１エンティティを表す第１ノードを、第２エンティティを表す第２ノードに論理的にリンクし、
１つ以上のリンクオブジェクトを検索し、前記リンクオブジェクトの各々は２つのエンティティの関係を表現し、前記リンクオブジェクトの少なくとも１つは、第２制御プログラムを含み、前記第２制御プログラムは、前記少なくとも１つのリンクオブジェクトが有効であるとみなされるために満たされなければならない１つ以上の条件の第２セットを評価するように操作可能であり、
前記第２制御プログラムを実行するためにデジタル著作権管理エンジンを使用する、方法。
【請求項１２】
前記１つ以上の条件の第１セットが時間ベースの条件を含む、請求項１１に記載の方法。
【請求項１３】
前記１つ以上の条件の第２セットが時間ベースの条件を含む、請求項１１に記載の方法。
【請求項１４】
前記条件の第１セットまたは前記条件の第２セットのうちの少なくとも１つが、メモリに格納されたカウンタが定義済みの値を超過しないという必要条件を含む、請求項１１に記載の方法。
【請求項１５】
電子コンテンツへのアクセスまたは使用を管理するための方法であって、
電子コンテンツに関連する制御プログラムを検索し、前記制御プログラムは命令を含み、前記命令は、デジタル著作権管理エンジンによって実行されるときに第１条件を評価するように操作可能であり、前記第１条件が満たされたことを決定する際に前記電子コンテンツの第１使用を可能にし、
前記デジタル著作権管理エンジンの制御の下に状態情報をデータベースに格納し、前記状態情報は、前記電子コンテンツの前記第１使用に関し、
前記第１条件および前記第２条件を評価することによって、前記電子コンテンツの第２使用が認可されるか否かを決定するために、前記制御プログラムを２回目に実行し、前記第２条件の前記評価は少なくとも部分的に前記状態情報に依存し、
前記第２条件が満たされたことを決定する際に、前記状態情報をアップデートし、前記アップデートされた状態情報を前記データベースに格納する、方法。
【請求項１６】
前記データベースに格納された前記状態情報が、前記電子コンテンツがアクセスされた回数のカウントを含む、請求項１５に記載の方法。
【請求項１７】
前記データベースに格納された前記状態情報が、前記電子コンテンツの使用の所要時間の測定を含む、請求項１５に記載の方法。
【請求項１８】
前記制御プログラムがリンクオブジェクトから入手され、前記リンクオブジェクトが第１ノードから第２ノードまでの認可グラフの一部を形成する、請求項１５に記載の方法。
【請求項１９】
前記第１条件が、前記リンクオブジェクトが有効であるという必要条件を含む、請求項１８に記載の方法。
【請求項２０】
前記第１ノードがコンピューティング装置を表し、前記第２ノードが前記コンピューティング装置のユーザを表す、請求項１８に記載の方法。
【請求項２１】
前記第１ノードがコンピューティング装置を表し、前記第２ノードが購読サービスを表す、請求項１８に記載の方法。
【請求項２２】
前記第１ノードがコンピューティング装置を表し、前記第２ノードがホームネットワークドメインを表す、請求項１８に記載の方法。
【請求項２３】
電子コンテンツへのアクセスまたは使用を管理するためのシステムであって、
電子コンテンツに関連する制御プログラムを検索し、前記制御プログラムは命令を含み、前記命令は、デジタル著作権管理エンジンによって実行されるときに第１条件を評価するように操作可能であり、前記第１条件が満たされたことを決定する際に前記電子コンテンツの第１使用を可能にする手段と、
前記デジタル著作権管理エンジンの制御の下に状態情報をデータベースに格納し、前記状態情報は、前記電子コンテンツの前記第１使用に関する手段と、
前記第１条件および前記第２条件を評価することによって、前記電子コンテンツの第２使用が認可されるか否かを決定するために前記制御プログラムを２回目に実行し、前記第２条件の前記評価は、少なくとも部分的に前記状態情報に依存する手段と、
前記第２条件が満たされたと決定する際に、前記状態情報をアップデートし、前記アップデートされた状態情報を前記データベースに格納するための手段とを備える、システム。
【請求項２４】
前記データベースに格納された前記状態情報が、前記電子コンテンツがアクセスされた回数のカウントを含む、請求項２３に記載のシステム。
【請求項２５】
前記データベースに格納された前記状態情報が、前記電子コンテンツの使用の所要時間の測定を含む、請求項２３に記載のシステム。
【請求項２６】
前記制御プログラムがリンクオブジェクトから入手され、前記リンクオブジェクトが第１ノードから第２ノードまでの認可グラフの一部を形成する、請求項２５に記載のシステム。
【請求項２７】
前記第１条件が、前記リンクオブジェクトが有効であるという必要条件を含む、請求項２６に記載のシステム。
【請求項２８】
前記第１ノードがコンピューティング装置を表し、前記第２ノードが前記コンピューティング装置のユーザを表す、請求項２６に記載のシステム。
【請求項２９】
前記第１ノードがコンピューティング装置を表し、前記第２ノードが購読サービスを表す、請求項２６に記載のシステム。
【請求項３０】
前記第１ノードがコンピューティング装置を表し、前記第２ノードがホームネットワークドメインを表す、請求項２６に記載のシステム。
【請求項３１】
デジタル著作権管理ライセンスを保護する方法であって、前記デジタル著作権管理ライセンスは、
（ａ）制御プログラムを含み、前記制御プログラムは１つ以上の命令を含み、前記１つ以上の命令は、電子コンテンツの指定された使用に関連する１つ以上の条件を検証するように操作可能である、第１オブジェクトと、
（ｂ）第１暗号鍵を含み、前記第１暗号鍵は少なくとも部分的に暗号化され、前記電子コンテンツを解読するように操作可能である、第２オブジェクトと、
（ｃ）前記第１オブジェクトへの参照と前記第２オブジェクトへの参照とを含む第３オブジェクトと、
（ｄ）前記第２オブジェクトへの参照と前記電子コンテンツへの参照とを含む第４オブジェクトとを含み、
前記第１暗号鍵を使用して前記第３オブジェクトにデジタル署名する、方法。
【請求項３２】
前記第１オブジェクトのメッセージ認証コードを算出し、前記メッセージ認証コードが前記第１暗号鍵を使用する、請求項３１に記載の方法。
【請求項３３】
前記メッセージ認証コードの公開鍵署名を算出する、請求項３２に記載の方法。
【請求項３４】
前記第２オブジェクトの中に前記メッセージ認証コードと前記公開鍵署名とを含むことを更に含む、請求項３３に記載の方法。
【請求項３５】
前記第１オブジェクトが制御オブジェクトを含む、請求項３１に記載の方法。
【請求項３６】
前記第２オブジェクトがコンテンツ鍵オブジェクトを含む、請求項３１に記載の方法。
【請求項３７】
前記第３オブジェクトがコントローラオブジェクトを含む、請求項３１に記載の方法。
【請求項３８】
前記第４オブジェクトがプロテクタオブジェクトを含む、請求項３１に記載の方法。
【請求項３９】
デジタル著作権管理ライセンスの完全性を検証する方法であって、前記デジタル著作権管理ライセンスは、
（ａ）制御プログラムを含み、前記制御プログラムは１つ以上の命令を含み、前記１つ以上の命令は、電子コンテンツの指定された使用に関連する１つ以上の条件を検証するように操作可能である、第１オブジェクトと、
（ｂ）第１暗号鍵を含み、前記第１暗号鍵は少なくとも部分的に暗号化され、前記電子コンテンツを解読するように操作可能である、第２オブジェクトと、
（ｃ）前記第１オブジェクトへの参照と前記第２オブジェクトへの参照とを含む第３オブジェクトと、
（ｄ）前記第２オブジェクトへの参照と前記電子コンテンツへの参照とを含む第４オブジェクトとを含み、
前記第３オブジェクトのデジタル署名を検証するために前記第１暗号鍵を使用する、方法。
【請求項４０】
メッセージ認証コードを算出するために前記第１暗号鍵を使用し、前記メッセージ認証コードを前記第３オブジェクトに含まれる値と比較する、請求項３９に記載の方法。
【請求項４１】
前記メッセージ認証コードの署名を検証するために公開鍵／秘密鍵のペアの秘密鍵を使用することを更に含む、請求項４０に記載の方法。
【請求項４２】
前記第１オブジェクトが制御オブジェクトを含む、請求項３９に記載の方法。
【請求項４３】
前記第２オブジェクトがコンテンツ鍵オブジェクトを含む、請求項３９に記載の方法。
【請求項４４】
前記第３オブジェクトがコントローラオブジェクトを含む、請求項３９に記載の方法。
【請求項４５】
前記第４オブジェクトがプロテクタオブジェクトを含む、請求項３９に記載の方法。
【請求項４６】
デジタル著作権管理ライセンスの完全性を検証するシステムであって、前記デジタル著作権管理ライセンスは、
（ａ）制御プログラムを含み、前記制御プログラムは１つ以上の命令を含み、前記１つ以上の命令は、電子コンテンツの指定された使用に関連する１つ以上の条件を検証するように操作可能である、第１オブジェクトと、
（ｂ）第１暗号鍵を含み、前記第１暗号鍵は少なくとも部分的に暗号化され、前記電子コンテンツを解読するように操作可能である、第２オブジェクトと、
（ｃ）前記第１オブジェクトへの参照と前記第２オブジェクトへの参照とを含む第３オブジェクトと、
（ｄ）前記第２オブジェクトへの参照と前記電子コンテンツへの参照とを含む第４オブジェクトとを含み、
前記第３オブジェクトのデジタル署名を検証するために前記第１暗号鍵を使用するための手段を備える、システム。
【請求項４７】
第２エンティティの定義済みの近似の範囲内に第１エンティティがあるか否かを決定する方法であって、
前記第１エンティティにおいて乱数ペアのセットを生成し、
前記第２エンティティが乱数ペアのセットを導出し得る元となる暗号化された情報を、前記第１エンティティから前記第２エンティティに送信し、
前記暗号化された情報を前記第２エンティティにおいて解読し、
前記乱数ペアのセットを前記第２エンティティにおいて導出し、
受信通知を、前記第２エンティティから前記第１エンティティに送信し、
第１時間値を、前記第１エンティティにおいて測定し、
前記乱数ペアのセットからの第１数を、第１エンティティから第２エンティティに送信し、
前記第１数が前記乱数ペアのセットからのものであることを、前記第２エンティティにおいて検証し、
前記乱数ペアのセットからの対応する乱数を、第２エンティティから第１エンティティに送信し、
前記対応する乱数を、第１エンティティにおいて受信し、
第２時間値を、前記第１エンティティにおいて測定する、方法。
【請求項４８】
前記第１時間値と前記第２時間値との差分を算出し、前記差分を閾値と比較する、請求項４７に記載の方法。
【請求項４９】
前記差分が前記閾値より大きい場合、計算リソースへのアクセスを前記第２エンティティに対して拒絶する、請求項４８に記載の方法。
【請求項５０】
前記差分が前記閾値より小さい場合、計算リソースへのアクセスを前記第２エンティティに対して認可する、請求項４８に記載の方法。
【請求項５１】
第２エンティティに対する第１エンティティの近似を決定する方法であって、
第１秘密を前記第１エンティティから前記第２エンティティに送信し、
受信通知を前記第２エンティティから受信し、
第１時間値を前記第１エンティティにおいて測定し、
前記第１秘密の一部を前記第１エンティティから前記第２エンティティに送信し、
前記第１秘密の対応する部分を、前記第２エンティティから受信し、
第２時間値を前記第１エンティティにおいて測定し、
前記第１時間値と前記第２時間値との差分を算出する、方法。
【請求項５２】
前記差分を閾値と比較する、請求項５１に記載の方法。
【請求項５３】
前記差分が前記閾値より大きい場合、計算リソースへのアクセスを前記第２エンティティに対して拒絶する、請求項５２に記載の方法。
【請求項５４】
前記差分が前記閾値より小さい場合、計算リソースへのアクセスを前記第２エンティティに対して認可する、請求項５２に記載の方法。
【請求項５５】
仮想マシンを含むデジタル著作権管理エンジンを含むデジタル著作権管理システムにおいて電子コンテンツへのアクセスまたは他の使用を認可する方法であって、
電子コンテンツへのアクセスまたは他の使用のためのリクエストを受信し、
前記電子コンテンツに関連するライセンスを識別し、前記ライセンスは制御プログラムとコンテンツ鍵とを含み、
前記仮想マシンを使用して前記制御プログラムを実行し、
前記仮想マシンから出力を入手し、前記出力は、義務が満たされる限り前記電子コンテンツの前記リクエストされたアクセスまたは他の使用が認可されることを示し、
前記義務をホストアプリケーションが満たすことができることを決定し、
前記義務を満たして、前記電子コンテンツを解読するために前記コンテンツ鍵を使用し、前記電子コンテンツの前記リクエストされたアクセスまたは他の使用を行うことを許可する、方法。
【請求項５６】
前記義務が前記電子コンテンツを低品質フォーマットにレンダリングする、請求項５５に記載の方法。
【請求項５７】
前記義務が前記電子コンテンツへの前記アクセスまたは他の使用に関連する監査情報を記録し、前記監査情報を遠隔サイトに報告する、請求項５５に記載の方法。
【請求項５８】
前記義務が、前記デジタル著作権管理システムが実行するホスト環境の指定された機能が使用停止にされるという必要条件を含む、請求項５５に記載の方法。
【請求項５９】
前記電子コンテンツが広告を含み、前記指定された機能が前記電子コンテンツのレンダリング中の早送りまたは巻戻しの能力を含む、請求項５８に記載の方法。
【請求項６０】
前記指定された機能が前記電子コンテンツを一定の技術にエクスポートする能力を含む、請求項５８に記載の方法。
【請求項６１】
仮想マシンを含むデジタル著作権管理エンジンを含むホストシステムにおいて電子コンテンツへのアクセスまたは他の使用を認可する方法であって、
電子コンテンツへのアクセスまたは他の使用のためのリクエストを受信し、
前記電子コンテンツに関連するライセンスを識別し、前記ライセンスは制御プログラムとコンテンツ鍵とを含み、
前記仮想マシンを使用して前記制御プログラムを実行し、
義務が満たされる限り前記電子コンテンツの前記リクエストされたアクセスまたは他の使用が認可され得ることを決定し、
前記ホストシステムが前記義務を満たすことができないと決定し、前記リクエストされた前記電子コンテンツのアクセスまたは他の使用が行われることを拒絶する、方法。
【請求項６２】
電子コンテンツへのアクセスまたは使用を管理するための方法であって、
電子コンテンツに関連する制御プログラムを検索し、前記制御プログラムは命令を含み、前記命令は、デジタル著作権管理エンジンによって実行されるときに第１条件を評価するように操作可能であり、前記第１条件が満たされたことを決定する際に前記電子コンテンツの第１使用を可能にし、
遠隔システムからエージェントプログラムを受信し、前記エージェントプログラムは命令を含み、前記命令は、デジタル著作権管理エンジンによって実行されるときに前記デジタル著作権管理エンジンによって管理されるデータベースに状態情報を格納するように操作可能であり、
前記制御プログラムを実行し、前記実行は、前記第１条件が満たされたか否かについての決定を行い、前記決定は少なくとも部分的に前記状態情報に基づく、方法。
【請求項６３】
前記データベースに格納された前記状態情報が、前記電子コンテンツの前記第１使用が行われ得る回数のカウントの初期値を含む、請求項６２に記載の方法。
【請求項６４】
前記電子コンテンツの前記第１使用を可能にし、前記カウントの現在値を減らす、請求項６２に記載の方法。
【請求項６５】
前記制御プログラムがリンクオブジェクトから入手され、前記リンクオブジェクトが第１ノードから第２ノードまでの認可グラフの一部を形成する、請求項６２に記載の方法。
【請求項６６】
前記第１条件が、前記リンクオブジェクトが有効であるという必要条件を含む、請求項６５に記載の方法。
【請求項６７】
前記第１ノードがコンピューティング装置を表し、前記第２ノードが前記コンピューティング装置のユーザを表す、請求項６５に記載の方法。
【請求項６８】
前記第１ノードがコンピューティング装置を表し、前記第２ノードが購読サービスを表す、請求項６８に記載の方法。
【請求項６９】
前記エージェントプログラムが前記購読サービスのオペレータから受信される、請求項６８に記載の方法。
【請求項７０】
前記第１ノードがコンピューティング装置を表し、前記第２ノードがホームネットワークドメインを表す、請求項６５に記載の方法。
【請求項７１】
電子コンテンツへのアクセスまたは使用を管理するためのシステムであって、
電子コンテンツに関連する制御プログラムを検索し、前記制御プログラムは命令を含み、前記命令は、デジタル著作権管理エンジンによって実行されるときに第１条件を評価するように操作可能であり、前記第１条件が満たされたことを決定すると前記電子コンテンツの第１使用を可能にする手段と、
エージェントプログラムを遠隔システムから受信し、前記エージェントプログラムは命令を含み、前記命令は、デジタル著作権管理エンジンによって実行されるときに前記デジタル著作権管理エンジンによって管理されるデータベースに状態情報を格納するように操作可能である手段と、
前記制御プログラムを実行し、前記実行は、前記第１条件が満たされたか否かについての決定を行い、前記決定は少なくとも部分的に前記状態情報に基づく手段とを備える、システム。
【請求項７２】
前記データベースに格納された前記状態情報が、前記電子コンテンツの前記第１使用が行われ得る回数のカウントの初期値を含む、請求項７２に記載のシステム。
【請求項７３】
前記電子コンテンツの前記第１使用を可能にするための手段と、前記カウントの現在値を減らすための手段とを更に含む、請求項７１に記載の方法。
【請求項７４】
前記制御プログラムがリンクオブジェクトから入手され、前記リンクオブジェクトが第１ノードから第２ノードまでの認可グラフの一部を形成する、請求項７１に記載のシステム。
【請求項７５】
前記第１条件が、前記リンクオブジェクトが有効であるという必要条件を含む、請求項７４に記載のシステム。
【請求項７６】
前記第１ノードがコンピューティング装置を表し、前記第２ノードが前記コンピューティング装置のユーザを表す、請求項７４に記載のシステム。
【請求項７７】
前記第１ノードがコンピューティング装置を表し、前記第２ノードが購読サービスを表す、請求項７４に記載のシステム。
【請求項７８】
前記エージェントプログラムが前記購読サービスのオペレータから受信される、請求項７７に記載のシステム。
【請求項７９】
前記第１ノードがコンピューティング装置を表し、前記第２ノードがホームネットワークドメインを表す、請求項７９に記載のシステム。
【請求項８０】
企業文書を管理する方法であって、
第１ソフトウェアアプリケーションを使用している電子文書を作成し、
前記文書を暗号化し、かつライセンスを前記文書に関連づけるために、デジタル著作権管理プラグインを使用し、前記ライセンスは、前記文書へのアクセスを獲得するために、第１装置に関連するノードをユーザの第１グループに関連するノードに論理的に接続する１つ以上のリンクオブジェクトのセットを有する必要があり、前記ライセンスは、前記文書を解読するように操作可能な第１鍵の暗号化されたバージョンを更に含み、
前記文書を遠隔コンピュータシステムに送信し、
前記遠隔コンピュータシステムを前記ユーザのグループに関連する前記ノードに論理的に接続する１つ以上のリンクオブジェクトのセットを前記遠隔コンピュータシステムが有するということを決定し、前記１つ以上のリンクのうちの１つは、前記第１鍵を解読するように操作可能な第２鍵の暗号化されたバージョンを含み、
前記決定ステップの終了後に、前記遠隔コンピュータシステムに関連する鍵を使用して前記第２鍵を解読し、
前記第２鍵を使用して前記第１鍵を解読し、
前記第１鍵を使用して前記文書を解読する、方法。
【請求項８１】
前記デジタル著作権管理プラグインを使用するステップが、１つ以上のテンプレートのセットから第１テンプレートを選択し、前記１つ以上のテンプレートは、前記電子文書へのアクセスに課され得るポリシー条件を表現し、前記デジタル著作権管理プラグインは、前記テンプレートによって表現される前記ポリシー条件を前記デジタル著作権管理プラグインによって実行可能な制御プログラムに自動的に変換するように操作可能である、請求項８０に記載の方法。
【請求項８２】
前記デジタル著作権管理プラグインが、前記制御プログラムを前記第１鍵に安全に結合するコントローラオブジェクトを作成するように更に操作可能である、請求項８１に記載の方法。
【請求項８３】
前記コントローラオブジェクトがコンテンツ鍵オブジェクトのハッシュと制御オブジェクトのハッシュとを含み、前記コンテンツ鍵オブジェクトが前記第１鍵の前記暗号化されたバージョンを含み、前記制御オブジェクトが前記制御プログラムを含む、請求項８２に記載の方法。
【請求項８４】
前記コントローラオブジェクトが、前記第１鍵を使用してＨＭＡＣによって署名される、請求項８３に記載の方法。
【請求項８５】
前記コントローラオブジェクトが、前記電子文書の作成者の公開鍵署名によって署名される、請求項８４に記載の方法。
【請求項８６】
前記公開鍵署名が、前記第１鍵を使用してＨＭＡＣによって署名される、請求項８５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願の引用］
本出願は、２００５年１０月１８日に米国仮出願第６０／７２８，０８９号明細書、２００６年２月９日に出願の米国仮出願第６０／７７２，０２４号明細書、２００６年４月１０日に出願の米国仮出願第６０／７４４，５７４号明細書、２００６年４月１０日に出願の米国仮出願第６０／７９１，１７９号明細書、２００６年５月８日に出願の米国仮出願第６０／７４６，７１２号明細書、２００６年５月８日に出願の米国仮出願第６０／７９８，９２５号明細書、および２００６年８月１日に出願の米国仮出願第６０／８３５，０６１号明細書の利益を請求する。米国仮出願第６０／７２８，０８９号明細書、第６０／７７２，０２４号明細書、第６０／７４４，５７４号明細書、第６０／７９１，１７９号明細書、第６０／７４６，７１２号明細書、第６０／７９８，９２５号明細書、および第６０／８３５，０６１号明細書は、任意の目的のために参照によってその全体が本明細書に援用されている。
【０００２】
［著作権認可］
本特許書類の開示の一部は、著作権保護の対象となるマテリアルを含む。本著作権者は、本特許文書または本特許の開示事項が米国特許商標局の特許ファイルまたは記録に示されているので、本特許文書または本特許の開示事項を誰かがファクシミリで複写することに異議を申立てないが、その外のものについては全著作権を留保するものである。
【背景技術】
【０００３】
現代のコンピューティングシステムにおいて、電子コンテンツ、サービスおよび／または処理リソースに対するアクセスを限定すること、および／または一定のエンティティのみが一定の動作を実行できるようにすることが、望ましいことが多い。そのような制御を可能にするために、様々な技術が開発または提案されている。これらの技術は、デジタル著作権管理（ＤＲＭ）技術と呼ばれることが多い。なぜなら、一般に、これらの目的は、デジタルまたは他の電子コンテンツ、サービスまたはリソースの様々なエンティティの著作権を管理することにあるからである。多くの従来技術の問題は、過度に複雑で、限定的で、比較的に柔軟性がなく、一定の普通の種類の関係およびプロセスを有効にすることができないこと、および／または他のＤＲＭシステムとの相互運用性がないということである。
【０００４】
これらの問題の一部または全てを改善するために使用できる改善されたＤＲＭ技術に関するシステムおよび方法を、本明細書に記載する。ここに記載する進歩性のある一連の作業の実施形態は、プロセス、装置、システム、デバイス、方法、コンピュータ可読媒体として、および／またはそれらの組み合わせとして、数多くの方法で実現できることを理解すべきである。
【０００５】
コンテンツに対するアクセスを制御する既存のシステムは、電子コンテンツへのアクセスを認可することに関連して、ライセンスにアクセスする構成要素を含むことがある。しかしながら、そのような構成要素は、ライセンスに関連する著作権管理情報、リンクまたはノードの、連鎖またはグラフについて、柔軟性のない評価を一般に実行する。それらは、コンテンツへのアクセスを認可するにあたって、異種の認可スキームに適合することができない、および／または一定のＤＲＭシステムを用いて動作することができないことが多い。本発明の実施形態は、ライセンスに関連して、付加的なルーチンまたは制御プログラムを格納、利用および／または実行することによって、そのような欠点を解決するものであり、動的な認可機能を提供し、分散した認可リソースを有効にし、および／またはアクセス機能を合理化することができる。
【０００６】
更に、多くの既存のシステムは、単純な認可／状態関連データが維持される場合のみに向けられる。これらのシステムは、他のノードに関連するすでに導出したデータに基づいて条件を決定する等の、アクセス認可がデータの複数層への依存を必要とし得る状況には、対処することができない。本発明の実施形態は、ＤＲＭ制御プログラムに関連して状態データベースの実現を介してこれらの欠点を克服するものであり、確実な設定条件メモリ機能を提供し、呼出しから呼出しまでの持続的な状態情報を提供し、または状態読み書き機能を有効にする。状態読み書き機能は、制御プログラム実行を改善し、および／またはより効果的なアクセス認可を実行する。
【０００７】
更なる既存のシステムは、ライセンス構成要素を保護するにあたって、公開鍵の使用に関わる構成要素を含むＤＲＭライセンスまたはＤＲＭ構造を実現する場合がある。しかしながら、これらのシステムに関する欠点は、ハッカーが、アクセスまたはライセンスの実現に必要なデジタル署名を偽造したり、ＤＲＭライセンス構造に存在する関連の相互関係を利用したりできる、という可能性を含む。本発明の１つ以上の実施形態は、特定の保護された鍵の使用を含むライセンスオブジェクトの、デジタル署名および／またはインタロック署名の実現を介して、そのような欠点を解決する。これらの実施形態の利点は、公開鍵を介する認可されていないアクセスの防止、ならびにライセンス要素の相互関係に由来する関連機能を含む。
【０００８】
他の既存のシステムは、第１エンティティと第２エンティティとの間（例えば２つの著作権管理エンティティの間）の近似決定を行う構成要素を含むことがある。そのようなシステムは、例えば、扱いにくい近似照合手順を実現することによって、保護されたコンテンツが一定の環境外では複製できないことを示す規則を実施することがある。しかしながら、これらのシステムの欠点は、近似照合そのものの実行を不適当に妨げることなく、保護されたコンテンツにセキュリティを提供することもできないということである。
本発明の実施形態は、乱数および／または秘密シードの送信に関連する機能を介して保証される、簡潔な近似検出プロトコルを提供することによって、この欠点および他の欠点を解決する。１つ以上の実施形態の関連する利点は、たとえリクエストが傍受されても、攻撃者が正しい反応を決定することを不可能にする暗号を含む。
【０００９】
要約すれば、過度に複雑で、限定的で、および／または比較的に柔軟性がない技術に頼ることなく、電子コンテンツに対するアクセスを適切に認可できるシステム、一定の普通の種類の関係およびプロセスを有効にできるシステム、および／または他のＤＲＭシステムと相互運用性のあるシステムに対するニーズがある。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明と一貫性のあるシステム、方法および製品は、電子コンテンツに対するアクセスの認可、および電子コンテンツに関連するデータ処理に向けられる。
【課題を解決するための手段】
【００１１】
１つの例示的実施形態において、メモリに格納された電子コンテンツへのアクセスを認可する方法が提供される。この例示的実施形態の方法は、電子コンテンツにアクセスするリクエストを受信し、電子コンテンツに関連するライセンスを検索し、リクエストが認可されるか否かを決定するデジタル著作権管理エンジンを使用して第１制御プログラムを実行してもよい。他の例示的実施形態は、メモリに格納された１つ以上のリンクオブジェクトを評価し、リンクが有効であるか否か、および／または１つ以上の条件が満たされるか否かを決定する第２制御プログラムを実行してもよい。
【００１２】
上述の概説および以下の詳細な説明は、単に例示的かつ説明的なものであり、記載する本発明を限定するものではないことを理解すべきである。本明細書に記載する機能および／またはバリエーションに加えて、更なる機能および／またはバリエーションを提供してもよい。例えば、本発明は、開示される機能および／または組み合わせの様々な組み合わせおよび副次的な組み合わせ、および以下の詳細な説明において開示されるいくつかの更なる機能の副次的な組み合わせに向けられてもよい。
【発明を実施するための最良の形態】
【００１３】
進歩性のある一連の作業の詳細な説明を、下記に提供する。いくつかの実施形態を記載するが、進歩性のある一連の作業は、任意の一実施形態に限定されるものではなく、これに代わって数多くの代替案、変更および等価物を含むことを理解すべきである。また、進歩性のある一連の作業の完全な理解を提供するために、以下の説明に数多くの具体的な詳細を記載するが、一部の実施形態は、これらの詳細の一部または全部を用いることなく実施することができる。さらに、明快さのために、関連技術分野において公知の一定の技術的資料は、進歩性のある一連の作業を不必要に不明確にすることを回避するために詳述しない。
【００１４】
本発明の譲受人に譲渡された米国特許出願第１０／８６３，５５１号明細書（公開第２００５／００２７８７１  Ａ１号明細書）（以下「５５１出願」と呼ぶ）は、参照によって本明細書に援用されており、多くの以前のＤＲＭ実現を特徴づける弱点の一部を克服するデジタル著作権管理（ＤＲＭ）アーキテクチャおよび新規なＤＲＭエンジンの実施形態を記載している。本出願は、５５１出願に記載されるアーキテクチャおよびＤＲＭエンジンに対する増強、拡張および変更、ならびにその代替の実施形態、さらには新規な構成要素、アーキテクチャおよび実施形態を記載する。従って、本明細書に記載する資料は、５５１出願に記載されるようなアーキテクチャおよび／またはＤＲＭエンジンの状況ならびに他の状況において使用できるということが理解される。
【００１５】
１．例示的なＤＲＭシステム
図１は、電子コンテンツを管理するための例示的なシステム１００を示す。図１に示すように、電子コンテンツ１０３の著作権を保持するエンティティ１０２は、エンドユーザ１０８ａ〜ｅによる配信および消費のために、コンテンツをパッケージングする（エンドユーザ１０８ａ〜ｅは、集合的に「エンドユーザ１０８」と呼び、文脈から明らかなように、参照符号１０８は、エンドユーザ、またはコンピューティングシステムのエンドユーザを、互換可能に指す）。例えば、エンティティ１０２は、コンテンツ所有者、作成者、またはプロバイダ（例えば音楽家、映画スタジオ、出版社、ソフトウェア企業、著者、モバイルサービスプロバイダ、インターネットのコンテンツダウンロードまたは購読サービス、ケーブルテレビまたは衛星テレビのプロバイダ、会社の従業員等、またはそれらのために作動するエンティティ）を含んでもよい。コンテンツ１０３は、任意の電子コンテンツ（例えばデジタルビデオ、オーディオコンテンツまたはテキストコンテンツ、映画、曲、ビデオゲーム、１つのソフトウェア、電子メールメッセージ、テキストメッセージ、ワードプロセッシング文書、報告、または他の任意の娯楽コンテンツ、企業コンテンツ、または他のコンテンツ）を含んでもよい。
【００１６】
図１に示す例において、エンティティ１０２は、パッケージングエンジン１０９を使用することによって、ライセンス１０６を、パッケージングされたコンテンツ１０４と関連させる。ライセンス１０６は、ポリシー１０５またはエンティティ１０２の他の要望に基づいており、コンテンツの許可および／または禁止された使用を特定し、および／または１つ以上の条件を特定する。１つ以上の条件は、コンテンツを利用するために満たされなければならず、使用の条件または結果として満たされなければならない。コンテンツも同様に、暗号化またはデジタル署名技術などの１つ以上の暗号メカニズムによってセキュリティを施されてもよく、そのために、信用権限１１０は、適切な暗号鍵や証明書などを得るために使用されてもよい。
【００１７】
図１に示すように、パッケージングされたコンテンツ１０４およびライセンス１０６は、任意の適切な手段によって（例えば、インターネットなどのネットワーク１１２、ローカルエリアネットワーク１０３、ワイヤレスネットワーク、仮想専用ネットワーク１０７、広域ネットワークなどを介して、あるいはケーブル、衛星、またはセルラ方式通信１１４を介して、および／または記録可能媒体１１６（例えばコンパクトディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）、フラッシュメモリカード（例えばセキュアデジタル（ＳＤ）カード）など）を介して）、エンドユーザ１０８に提供することができる。パッケージングされたコンテンツ１０４は、同一または異なるソースから受信される、単一のパッケージまたは送信１１３において、または独立したパッケージまたは送信において、ライセンス１０６と共にユーザに配信することができる。
【００１８】
エンドユーザのシステム（例えば、パーソナルコンピュータ１０８ｅ、自動車電話１０８ａ、テレビジョンおよび／またはテレビセットトップボックス１０８ｃ、携帯オーディオプレーヤおよび／またはビデオプレーヤ、電子ブックリーダなど）は、アプリケーションソフトウェア１１６、ハードウェア、および／またはコンテンツを検索およびレンダリングするように操作可能な特殊目的論理を含む。ユーザのシステムは、本明細書においてデジタル著作権管理エンジン１１８と呼ぶソフトウェアおよび／またはハードウェアを更に含む。デジタル著作権管理エンジン１１８は、パッケージングされたコンテンツ１０４に関連するライセンス１０６を評価し、ライセンス１０６によって許可される場合にのみ、例えばコンテンツに対するユーザアクセスを選択的に認可することによって、その条件を実施する（および／またはアプリケーション１１６がそのような条件を実施することを可能にする）。デジタル著作権管理エンジン１１８は、構造的または機能的にアプリケーション１１６に統合してもよく、あるいはソフトウェアおよび／またはハードウェアの独立した部分を含んでもよい。それに代わって、またはそれに加えて、ユーザのシステム（例えばシステム１０８ｃ）は、システム１０８ｂなどの遠隔システム（例えば、サーバ、ユーザの装置ネットワークにおける別の装置（例えばパーソナルコンピュータまたはテレビセットトップボックス）など）と通信してもよい。遠隔システムは、ユーザによってすでに入手またはリクエストされたコンテンツに対するユーザアクセスを認可するべきかどうかに関して、デジタル著作権管理エンジンを使用して決定１２０を行う。
【００１９】
デジタル著作権管理エンジン、および／またはユーザのシステムまたはその遠隔通信における他のソフトウェアは、保護されたコンテンツに対するユーザのアクセスまたは他の使用に関して、情報を更に記録してもよい。一部の実施形態において、この情報の一部または全部は、遠隔団体（例えば、情報センタ１２２、コンテンツ作成者、コンテンツ所有者、プロバイダ１０２、ユーザの管理者、そのために作動するエンティティなど）に伝えられてもよい。その使用目的は、例えば、収入（例えば使用料、広告ベースの収入など）の割り当て、ユーザプリファレンスの決定、システムポリシーの強化（例えば機密情報が使用される場合および方法を監視すること）などを行うためである。図１は、例示的なＤＲＭアーキテクチャおよび例示的な関係の集合を示すものであり、本明細書に記載するシステムおよび方法は、任意の適切な状況において実施できることが理解され、従って、図１は、限定のためではなく、実例および説明のために提供するものであることが理解される。
【００２０】
図２は、進歩性のある一連の作業の実施形態を実施するために使用できるシステム２００のより詳細な例を示す。例えば、システム２００は、エンドユーザの装置１０８、コンテンツプロバイダの装置１０９などの実施形態を含んでもよい。例えば、システム２００は、汎用コンピューティング装置（例えばパーソナルコンピュータ１０８ｅまたはネットワークサーバ１０５）、または特殊化したコンピューティング装置（例えば携帯電話１０８ａ、携帯情報端末、携帯オーディオプレーヤまたはビデオプレーヤ、テレビセットトップボックス、キオスク、ゲームシステム等）を含んでもよい。システム２００は、プロセッサ２０２、メモリ２０４、ユーザインタフェース２０６、リムーバブルメモリ２０８を受け入れるためのポート２０７、ネットワークインターフェース２１０、および上述の要素を接続するための１つ以上のバス２１２を一般に含む。システム２００の操作は、メモリ２０４に格納されたプログラムの誘導の下で稼働するプロセッサ２０２によって、一般に制御される。メモリ２０４は、高速のランダムアクセスメモリ（ＲＡＭ）および不揮発性メモリ（例えば磁気ディスクおよび／またはフラッシュＥＥＰＲＯＭ）を一般に含む。メモリ２０４の一部分は、システム２００の他の構成要素による読み出しまたは書き込みができないように制限してもよい。ポート２０７は、コンピュータ可読媒体２０８（例えば、フレキシブルディスク、ＣＤ―ＲＯＭ、ＤＶＤ、メモリカード、ＳＤカード、他の磁気媒体または光学媒体など）を受け入れるためのディスクドライブまたはメモリスロットを備えてもよい。ネットワークインターフェース２１０は、ネットワーク２２０（例えばインターネットまたはイントラネット（例えばＬＡＮ、ＷＡＮ、ＶＰＮなど））を介して、システム２００と他のコンピューティング装置（および／またはコンピューティング装置のネットワーク）との接続を提供するように一般に操作可能であり、そのような接続（例えば無線、イーサネット（登録商標）など）を物理的に行うために、１つ以上の通信技術を使用してもよい。一部の実施形態において、システム２００は、システム２００または他のエンティティのユーザによる不正操作から保護される演算処理装置２０３を更に含んでもよい。そのような安全な処理装置は、デリケートな操作（例えば、デジタル著作権管理プロセスの、鍵管理、署名照合、および他の態様）のセキュリティを高めるのを補助することができる。
【００２１】
図２に示すように、コンピューティング装置２００のメモリ２０４は、コンピューティング装置２００の操作を制御するための様々なプログラムまたはモジュールを含んでもよい。例えば、メモリ２０４は、アプリケーションおよび周辺装置などの実行を管理するためのオペレーティングシステム２２０と、レンダリング保護された電子コンテンツのためのホストアプリケーション２３０と、本明細書に記載する著作権管理機能の一部または全部を実現するためのＤＲＭエンジン２３２とを一般に含む。本明細書の他の場所に記載するように、ＤＲＭエンジン２３２は、他の様々なモジュール（例えば、制御プログラムを実行するための仮想マシン２２２、仮想マシン２２２用に状態情報を格納するための状態データベース２２４、および／または１つ以上の暗号モジュール２２６）を含み、相互操作し、および／または制御してよい。暗号モジュール２２６は、コンテンツの暗号化および／または解読、ハッシュ関数およびメッセージ認証コードの計算、デジタル署名の評価などの暗号操作を実行する。メモリ２０４は、保護されたコンテンツ２２８、および関連するライセンス２２９、ならびに暗号鍵、証明書など（図示せず）を更に一般に含む。
【００２２】
図２に例示するものと類似または同一のコンピューティング装置、または実質的に他の任意の適切なコンピューティング装置（図２に示す構成要素の一部を有しないコンピューティング装置、および／または図示しない他の構成要素を有するコンピューティング装置含む）を用いて、本明細書に記載するシステムおよび方法を実施することができることを、当業者は理解する。従って、図２は、限定のためではなく、説明のために提供するものであることを、理解すべきである。
【００２３】
デジタル著作権管理エンジンおよび関連するシステムおよび方法を本明細書に記載する。それらを使用することによって、図１および図２に示すようなシステム、または他の種類のシステムの、著作権管理機能の一部または全部を提供することができる。また、様々な他のシステムおよび方法を以下に述べる。それらは、図１および図２に示すようなシステムの状況、ならびに他の状況（デジタル著作権管理とは無関係な状況を含む）において使用することができる。
【００２４】
２．ＤＲＭエンジンアーキテクチャ
一実施形態において、比較的に単純で、制限のない、柔軟なデジタル著作権管理（ＤＲＭ）エンジンを使用することによって、中心的なＤＲＭ機能を実現する。好ましい実施形態において、このＤＲＭエンジンは、５５１出願に記載されるようなウェブサービス環境、および実質的に任意のホスト環境またはソフトウエアアーキテクチャの中に、比較的に容易に統合するように設計される。好ましい実施形態において、ＤＲＭエンジンは、特定の媒体フォーマットおよび暗号プロトコルから独立しており、特定の場合による必要に応じて、設計者が標準化技術または著作権を主張できる技術を柔軟に使用することを可能にする。ＤＲＭエンジンの好ましい実施形態により用いられるガバナンスモデルは、単純であるが、高度な関係およびビジネスモデルを表すように使用することができる。
【００２５】
以下に記載するＤＲＭエンジンの例示的実施形態の一部は、「オクトパス」と呼ばれる実施例に関する。しかし、本発明は、オクトパスの実施例の具体的な詳細に限定されるものではなく、当該実施例は、限定ではなく説明のために提供するものであることが理解される。
【００２６】
１．１．概要
図３は、ＤＲＭを使用するシステム３０２において、例示的なＤＲＭエンジン３０３ａが機能し得る方法を示す。図３に示すように、一実施形態において、ＤＲＭエンジン３０３ａは、ホストアプリケーション３０４ａ（例えば、オーディオプレーヤおよび／またはビデオプレーヤなどのコンテンツレンダリングアプリケーション、テキストレンダリングアプリケーション（例えば電子メールプログラム、ワードプロセッサ、電子ブックリーダ、またはドキュメントリーダなど））の中に埋め込まれるかまたは統合され、あるいはそれらと通信する。一実施形態において、ＤＲＭエンジン３０３は、ＤＲＭ機能を実行し、サービス（例えば暗号化、解読、ファイル管理）のためにホストアプリケーション３０４ａ依存し、および／または、他の機能はホストによってより効果的に提供することができる。例えば、好ましい実施形態において、ＤＲＭエンジン３０３ａは、コンテンツ３０８を保護するライセンス３０６を含むＤＲＭオブジェクト３０５を操作するように操作可能である。一部の実施形態において、ＤＲＭエンジン３０３は、ホストアプリケーション３０４ａに対して鍵を更に配信してもよい。図３に示すように、ＤＲＭエンジン３０３ａおよびホストアプリケーション３０４ａの一方または両方は、処理および／またはそれぞれのタスクを完了するために必要な情報のために、ウェブサービス３０５ａおよび／またはホストサービス３０６ａを利用してもよい。５５１出願は、そのようなサービスの例を提供し、ＤＲＭエンジン３０３ａおよびホストアプリケーション３０４ａがそれと相互操作し得る態様を提供する。
【００２７】
図３に示す例において、ＤＲＭエンジン３０３、ホストアプリケーション３０４ａ、ホストサービス３０６ａ、およびウェブサービスインタフェース３０５ａは、装置３００ａ（例えばエンドユーザのパーソナルコンピュータ（ＰＣ））上にロードされる。装置３００ａは、サーバ３００ｂ（そこからコンテンツ３０８およびライセンス３０６を入手する）、ならびに携帯機器３００ｄ（それに対して装置３００ａがコンテンツ３０８および／またはライセンス３０６を転送し得る）と通信で接続される。これらの他の装置の各々は、ＤＲＭエンジン３００ａと類似または同一のＤＲＭエンジン３０３を含んでもよく、装置の特定のホストアプリケーションおよびホスト環境に統合することができる。例えば、サーバ３００ｂは、ホストアプリケーション３０４ｂを含んでもよい。ホストアプリケーション３０４ｂは、コンテンツおよび／またはライセンスのバルクパッケージングを実行し、ＤＲＭエンジン３００ａを使用することによってコンテンツに関連する制御を評価する。コンテンツは、任意の再配信制約に従うようにパッケージングされる。同様に、装置３００ｃは、コンテンツのレンダリングおよびパッケージングができるホストアプリケーション３０４ｃを含んでもよく、装置３００ａは、単にコンテンツをレンダリングできるホストアプリケーションを含んでもよい。ホスト環境の潜在的多様性のさらに別の例として、装置３００ｄは、ウェブサービスインタフェースを含まなくてもよいが、これに代わって装置３００ａとの通信に依存してもよく、ホストアプリケーション３０４ｄおよび／またはＤＲＭエンジン３０３ｄに対するウェブサービスインタフェース３０５ａは、任意のウェブサービスの使用を必要とする。図３は、ＤＲＭエンジンを使用できるシステムの単なる一例である。本明細書に記載するＤＲＭエンジンの実施形態は、多くの異なる方法でアプリケーションおよびシステムに実現および統合することができ、図３に示す説明例に限定されるものではないことが理解される。
【００２８】
１．２．オブジェクト
好ましい実施形態において、コンテンツの保護およびガバナンスのオブジェクトの使用目的は、システムにおけるエンティティを示し、コンテンツを保護し、使用規則をコンテンツに関連させ、リクエスト時にアクセスが認可されるか否かを決定することにある。
【００２９】
後で詳しく述べるように、一実施形態において、以下のオブジェクトを使用する。
【表１】
2009512096.tif 000003
【００３０】
１．２．１．ノードオブジェクト
ノードオブジェクトは、システムのエンティティを示すために使用する。実際には、ノードは通常、ユーザ、装置、またはグループを示す。ノードオブジェクトは、ノードに関連するエンティティの一定の特性を示す関連属性を、更に一般に有する。
【００３１】
例えば、図４は、２人のユーザ（キサン４００およびノックス４０２）、２つの装置（ＰＣ４０４および携帯装置４０６）、およびグループ（例えば、ケアリー家の家族４０８、公共図書館の家族４１０、特定の音楽サービスの加入者４１２、ＲＩＡＡ認可装置４１４、および特定の企業によって製造される装置４１６）を示すいくつかのエンティティを示し、それぞれは、関連するノードオブジェクトを有する。
【００３２】
一実施形態において、ノードオブジェクトは、ノードが示すものを規定する属性を含む。
属性の一例は、ノード種別である。ノード種別属性は、ユーザ、グループ、または装置を示す他に、他のエンティティを示すために使用することができる。一部の実施形態において、例えば、本明細書の他の場所に記載する鍵の導出および配信の技術の実施形態が使用される場合、ノードオブジェクトは、暗号鍵情報を更に含むことができる。
【００３３】
一部の実施形態において、ノードオブジェクトは、ノードオブジェクトの機密部分にアクセスするサブシステムに対して、機密情報を対象にするために使用する、機密性非対称鍵ペアを更に含む。このことは、ノードが示すエンティティ（例えば音楽サービス４１２）、またはノードの管理を担う一部のエンティティであり得る（例えば、エンドユーザ（例えばノックス４０２）は、自分の携帯機器４０６を管理する責任があり得る）。
【００３４】
１．２．２．リンクオブジェクト
好ましい実施形態において、リンクオブジェクトは、２つのノードの関係を示すために使用される署名されたオブジェクトである。例えば、図４において、ＰＣノード４０４からノックス４０２へのリンク４１８は、所有権を示す。ノックス４０２からケアリー家ノード４０８へのリンクは帰属関係を示し、ケアリー家ノード４０８から音楽サービス加入者ノード４１２へのリンクも帰属関係を示す。一実施形態において、リンクオブジェクトは２つのノードの関係を表すので、図４に示す関係は、１０のリンクを使用して示すことができる。
【００３５】
図４に示すように、グラフ４２０は、ノードの関係を表すために使用できる。ここで、リンクオブジェクトは、ノード間の誘導されたエッジである。例えば、図４において、ケアリー家ノード４０８と音楽サービスノード４１２との関係は、頂点がケアリー家ノード４０８および音楽サービスノード４１２であるグラフにおいて、誘導されたエッジ４２２が存在することを表明する。ノックス４０２およびキサン４００は、ケアリー家４０８の家族である。ケアリー家４０８が音楽サービス４１２にリンクされ、ノックス４０２がケアリー家４０８にリンクされるので、ノックス４０２と音楽サービス４１２との間に経路があると言うことができる。
あるノードから他のノードまでの経路がある場合、ＤＲＭエンジンは、別のノードから到達可能なノードを検討する。このことにより、制御を書き込むことが可能である。それにより、装置からノードに到達可能であるという条件に基づいて、保護されたコンテンツに対するアクセスの許可を可能にする。この装置においては、保護されたコンテンツに対するアクセスをリクエストするアプリケーションが実行中である。
【００３６】
後で詳しく述べるように、リンクオブジェクトは、コンテンツ鍵の導出を可能にする一部の暗号データを更に任意に含むことができる。リンクオブジェクトは、リンクが有効であると考え得る条件を規定する制御プログラムを、更に含んでもよい。そのような制御プログラムは、リンクの有効性を評価するために（例えば、認可グラフにおける所与のノードに達するためにリンクを使用できるか否かを決定するために）、ＤＲＭエンジンの仮想マシンによって実行または解釈する（これらの用語は本明細書において互換可能に使用される）ことができる。
【００３７】
一実施形態において、リンクは、署名される。任意の適切なデジタル署名メカニズムを使用することができる。一実施形態において、ＤＲＭエンジンは、リンクオブジェクトが署名される方法を規定せず、いかなる関連証明書も評価しない。これに代わって、ＤＲＭエンジンは、任意のそのような署名および／または証明書を検証するにあたって、ホストシステムに依存する。このことにより、システム設計者またはシステムアドミニストレータは、リンクオブジェクトの寿命の規定、無効化などができる（鍵または証明書の失効、取り消しなどを用いて）。従って、特定の保護されたコンテンツおよび／またはリンクの状況において、制御プログラムおよびＤＲＭオブジェクトのＤＲＭエンジンの評価によって提供されるポリシー管理およびセキュリティに加えて、更なるポリシー管理およびセキュリティが提供される（例えば、リンクオブジェクト自身に適切な制御プログラムを含めることによって、リンクの失効を代替的または付加的に実施することができ、これが実行されると、失効日または他の有効期間が実施される）。一実施形態において、ＤＲＭエンジンは、包括的なものであり、ホストアプリケーションおよび／または環境により用いられる、任意の適切な暗号化、デジタル署名、取り消し、および／または他のセキュリティスキームとともに作用する。従って、例えば、ＤＲＭエンジンが、特定のリンクが適切に署名されているか否かを決定する必要がある場合、単にホストアプリケーション（および／またはホストまたはシステムの暗号サービス）を呼び出すことによって、システム設計者によって選ばれた特定の署名スキームに従って署名を検証する。このＤＲＭエンジンそのものの詳細は不明でよい。他の実施態様において、ＤＲＭエンジンそのものは、実際の署名評価を実行し、使用する適切な署名アルゴリズムを単に示すにあたって、ホストに依存する。
【００３８】
１．２．３．コンテンツ保護およびガバナンス
再び図３を参照して、代表的なシナリオにおいて、コンテンツプロバイダ３００ｂは、パッケージングエンジンを含むアプリケーション３０４ｂを使用することによって、１つの電子コンテンツ３０８を暗号化または暗号によるセキュリティを施し、そのコンテンツのアクセスまたは他の使用を管理するライセンス３０６を作成する。一実施形態において、ライセンス３０８は、コンテンツ３０８の使用方法を特定するオブジェクトのセット３０５を含み、それを入手するために必要なコンテンツの暗号化キーおよび／または情報を更に含む。一実施形態において、コンテンツ３０８およびライセンス３０６は、論理的に独立しているが、共に内部参照によって束縛される（例えばオブジェクトＩＤ３１０を使用して）。多くの場合において、コンテンツおよびライセンスを共に格納および／または配信することは便利であり得るが、好ましい実施形態においては必要ではない。一実施形態において、１つのライセンスを複数のコンテンツ項目に適用することができ、複数のライセンスを任意の単一のコンテンツ項目に適用することができる。
【００３９】
図３に示すように、クライアント装置３００ａ上で実行するホストアプリケーション３０４ａは、コンテンツ３０８の特定の部分に対するアクションを実行したい場合、ＤＲＭエンジン３０３ａに、実行しようとするアクション（例えば「再生」）が許可されるか否かを照合するように求める。一実施形態において、ＤＲＭエンジン３０３ａは、コンテンツライセンス３０６を含むオブジェクト３０５に含まれる情報から、コンテンツ３０８に関連する制御プログラムをロードおよび実行する。アクション実行の許可は、制御プログラムによって戻される結果に基づいて、認可または拒絶される。許可は、一部の条件が満たされることを一般に必要とする。例えば、あるノードが、リクエストするエンティティ／装置３００ａを示すノードから到達可能であるという条件などである。
【００４０】
図５は、リクエストされるアクション（例えば１つのコンテンツの閲覧）が認可されるか否かを、ＤＲＭエンジンの実施形態が決定できる方法を例示するフローチャートである。
図５に示すように、所与のアクションに関するライセンスを評価するリクエストが受信される（５００）。例えば、指定のアクションを実行するリクエストをホストがユーザから受信した後で、このリクエストはホストアプリケーションから受信されてもよい。図５に示すように、ＤＲＭエンジンは、指定されたライセンスを評価し（５０２）、リクエストされたアクションが認可されるか否かを決定する（５０４）。例えば、ライセンスは、ＤＲＭエンジンが実行する制御プログラムを含んでもよく、その出力は、認可決定を行うために使用される。リクエストされたアクションをライセンスが認可する場合（すなわちブロック５０４から「ＹＥＳ」で出て行く場合）、ＤＲＭエンジンは、リクエストが認可されることをホストアプリケーションに示す（５０６）。それ以外の場合、ＤＲＭエンジンは、リクエストが拒絶されたことをホストアプリケーションに示す（５０８）。一部の実施形態において、ＤＲＭエンジンは、ホストアプリケーションに様々なメタデータ（例えば認可の授与に関連する条件）（例えば義務および／またはコールバック）を更に返してもよく、あるいは認可の拒否の原因に関する追加情報を提供してもよい。例えば、ＤＲＭエンジンは、リクエストされたアクションの実行に関する一定の情報をホストアプリケーションが記録する場合にのみ、あるいは、例えばライセンスを再評価する所定の時間間隔において、ホストアプリケーションがＤＲＭエンジンを呼び出す限り、リクエストされたアクションが許可されることを示してもよい。ＤＲＭエンジンによって返されるそのような義務、コールバック、および他のメタデータに関する追加情報を、以下に提供する。リクエストされたアクションが認可される場合、（例えばライセンスのＣｏｎｔｅｎｔＫｅｙオブジェクトから）コンテンツ鍵が検索され、リクエストされた使用についてコンテンツを公開するために使用される。
【００４１】
１．２．４．ライセンスＤＲＭオブジェクト
図６に示すように、好ましい実施形態において、ライセンス６００は、オブジェクトのセットである。図６に示す例において、ライセンス６００は、ＣｏｎｔｅｎｔＫｅｙオブジェクト６０２、プロテクタオブジェクト６０４、コントローラオブジェクト６０６、および制御オブジェクト６０８を含む。図６に示すように、ＣｏｎｔｅｎｔＫｅｙオブジェクト６０２は、暗号化された鍵データ６１０（例えば暗号化されたコンテンツ項目６１２を解読するために必要な鍵の暗号化されたバージョン）、および鍵データを暗号化するために使用する暗号システムに関する情報を含む。プロテクタオブジェクト６０４は、ＣｏｎｔｅｎｔＫｅｙオブジェクト６０２を１つ以上のコンテンツオブジェクト６１４に結合する。図６に示すように、制御オブジェクト６０８は、コンテンツオブジェクト６１４が管理される方法を特定する制御プログラム６１６を、含んで保護する。好ましい実施形態において、制御プログラム６１６は、ＤＲＭエンジンによって操作される仮想マシン上で実行する、１つの実行可能なバイトコードである。制御プログラムは、制御プログラムにおいて指定された条件の満足について照合することによって、コンテンツに対して一定のアクションを実行できるか否かを管理する。その条件とは、例えば、有効なリンクオブジェクトを使用して一定のノードに到達可能か否か、一定の状態オブジェクトが格納されているか否か、ホスト環境が一定の特徴を有するか否かなどである。再び図６を参照して、コントローラオブジェクト６０６は、１つ以上のＣｏｎｔｅｎｔＫｅｙオブジェクト６０２を制御オブジェクト６０８に結合するために使用される。
【００４２】
ライセンス６００は、付加的なオブジェクト（例えば、ライセンスによって必要とされるコンテンツアクセス条件の、機械可読記述または人間が読める記述を提供するメタデータ）を更に含んでもよい。それに代わって、またはそれに加えて、そのようなメタデータは、他のオブジェクト（例えば制御オブジェクト６０８）の１つのリソース拡張として含めることができる。図６に示す実施形態において、制御オブジェクト６０８およびコントローラオブジェクト６０６は両方とも署名されるので、システムは、コンテンツアクセス決定を行うために制御情報を使用する前に、制御情報が信頼されたソースからのものであることを検証できる。一実施形態において、制御オブジェクト６０８の有効性は、コントローラオブジェクト６０６で含まれる安全なハッシュの検証によって、更に照合することができる。コントローラオブジェクト６０６は、参照するＣｏｎｔｅｎｔＫｅｙオブジェクト６０２に含まれる鍵または他の鍵データの各々についてハッシュ値を更に含むことができる。それによって、鍵データとＣｏｎｔｅｎｔＫｅｙオブジェクトとの間の結合に攻撃者が不正操作することを比較的に困難にする。
【００４３】
図６に示すように、一実施形態において、コンテンツ６１２は、暗号化され、コンテンツオブジェクト６１４に含まれる。使用される復号キー６１０は、ＣｏｎｔｅｎｔＫｅｙオブジェクト６０２の中に含まれ（またはそれによって参照され）、２つの間の結合は、プロテクタオブジェクト６０４によって示される。図６に示すように、一意なＩＤは、コンテンツオブジェクト６１４とＣｏｎｔｅｎｔＫｅｙオブジェクト６０２との間の結合を容易にするために使用される。コンテンツ６１２を解読するための鍵６１０の使用を管理する規則は、制御オブジェクト６０８の中に含まれる。制御オブジェクト６０８とＣｏｎｔｅｎｔＫｅｙ６０２との間の結合は、ここでも一意なＩＤを使用して、コントローラオブジェクト６０６によって示される。
【００４４】
図６は、好ましい一実施形態においてライセンスを含むオブジェクトを示すが、本明細書に記載するＤＲＭのシステムおよび方法は、このライセンス構造の使用に限定されないことが理解される。例えば、限定するものではないが、ライセンスの使用にあたって、図６に示す様々なオブジェクトの機能は、より少ない数のオブジェクトにおいて組み合わせたり、または付加的なオブジェクトにわたって広げたり、または異なる態様においてオブジェクト間に分解したりすることができる。それに代わって、またはそれに加えて、本明細書に記載するシステムおよび方法の実施形態は、図６に示すライセンス構造によって有効にされる機能の一部が欠如したライセンス、および／または付加的な機能を提供するライセンスによって実施することができる。従って、本明細書に記載する原理に従って、ライセンスをコンテンツに関連させる任意の適切なメカニズムを使用できることが理解される。但し、好ましい実施形態においては、図６に示す有利な構造が使用される。
１．３．状態データベース
【００４５】
一実施形態において、ＤＲＭエンジンは、保護状態記憶メカニズムを提供するために使用できる安全で持続的なオブジェクト記憶を含むかまたはアクセスする。そのような機能は、呼出しから呼出しまで持続的な状態情報の読込みおよび書込みを行うことが可能な制御プログラムを有効にするのに役立つ。そのような状態データベースは、状態オブジェクト（例えば、再生回数、最初の使用日、集積されたレンダリング時間など）、ならびに帰属関係状態、および／または他の任意の適切なデータを格納するために使用することができる。
一部の実施形態において、第１システム上で実行するＤＲＭエンジンは、ローカル状態データベースに対するアクセスを有しなくてもよく、遠隔状態データベースにアクセスするように操作可能でもよい（例えばウェブおよび／またはホストサービスを使用して）。
一部の場合において、第１システム上で実行するＤＲＭエンジンは、遠隔システム上のデータベースに格納された状態情報にアクセスすることが必要な場合がある。例えば、第１システムは、状態データベースを含まなくてもよく、またはそれ自身の状態データベースにおいて必要とする情報を有しなくてもよい。一部の実施形態において、ＤＲＭエンジンがそのような場合に直面する場合、後で詳しく述べるように、サービスインタフェースを介して、および／またはエージェントプログラムを使用することにより、遠隔状態データベースにアクセスしてもよい。
【００４６】
１．４．制御プログラムについて
本明細書に記載するシステムおよび方法は、様々な状況において制御プログラムを利用する。例えば、制御オブジェクトに含まれる制御プログラムは、保護コンテンツの使用を管理する規則および条件を表すために使用することができる。また、リンクオブジェクトにおける制御プログラムは、所与の目的（例えばノード到達可能性分析）についてリンクが有効か否かを決定する規則および条件を表すために使用することができる。そのような制御プログラムは、本明細書においてリンク制約と呼ぶことがある。制御プログラムを使用できるさらに別の状況は、エージェントまたは委託オブジェクトにあり、制御コードは、（エージェント制御プログラムの場合は）別のエンティティに代わって、または（委託制御プログラムの場合は）別の制御に代わって、アクションを実行するために使用される。
【００４７】
一実施形態において、物理的なプロセッサによって直接に実行されることとは対照的に、制御プログラムは、ＤＲＭエンジンによってホストされる仮想マシンによって実行または解釈される。しかしながら、制御プログラムを実行するために、物理的なプロセッサまたは他のハードウェア論理を容易に構成できることが理解される。一実施形態において、制御プログラムはバイトコードフォーマットになっており、それはプラットホーム全体の相互接続性を容易にする。
【００４８】
好ましい実施形態において、制御プログラムは、アセンブラ言語で記述され、アセンブラプログラムによってバイトコードに変換される。他の実施態様において、テンプレートおよび／または高水準の著作権表現言語は、著作権、規則、および／または条件の初期表現を提供するために使用することができる。コンパイラは、高水準の表現を、本明細書に記載するＤＲＭエンジンの実施形態によって実行するバイトコードに変換するために使用することができる。例えば、著作権を主張できるＤＲＭフォーマットで書かれる著作権表現は、適切なコンパイラによって、本明細書に記載するＤＲＭエンジンの実施形態で実行する機能的に同等のバイトコード表現に変換または翻訳することができる。従って、保護されたコンテンツは、著作権を主張できるＤＲＭフォーマットを解釈するシステム、ならびに本明細書に記載するようなＤＲＭエンジンを含むシステム上で、コンテンツプロバイダによって特定される条件に従って使用できる。本明細書に記載するデジタル著作権管理エンジンのシステムおよび方法は、仮想マシンによって解釈されるバイトコード著作権表現の使用に限定されないことも理解すべきである。これに代わって、一部の実施形態において、著作権は、任意の適切な態様で表現することができる（例えば、高水準著作権表現言語（ＲＥＬ）、テンプレートなどを使用して）。本明細書に記載する認可グラフおよび／または他の技術は、そのような著作権表現を認識および評価するように設計されたアプリケーションプログラムを使用して実行することができる。
【００４９】
１．４．１．条件
前述のように、制御プログラムは、リクエストが認可されるコンテンツを使用すること、リンクが有効とみなされることなどのために、満たさなければならない１つ以上の条件を一般に表現する。コンテンツプロバイダまたはシステム設計者の必要条件に依存して、および／またはシステムによって提供される機能に依存して、任意の適切な条件を使用することができる。
【００５０】
好ましい実施形態において、ＤＲＭエンジンによって使用される仮想マシンは、例えば以下の一部または全ての条件を検証できる任意の複雑なプログラムをサポートする。
・時間ベースの条件：クライアント時間値を、制御プログラムにおいて指定される値と比較すること。
・特定ノードを対象にすること：一定のノードが別のノードから到達可能か否かを照合すること。このコンセプトは、ドメイン、購読、帰属関係などのモデルについてサポートを提供する。
・一定のノード属性が指定された値に一致するか否かを検証すること：例えばノードに関連する装置のレンダリング機能が忠実度必要条件を満たすか否かなど、ノードの属性のいずれかを照合すること。
・クライアントにおけるセキュリティ関連メタデータが最新であるか否かを検証すること：例えば、許容できるバージョンのクライアントソフトウェアおよび正確な時間測定をクライアントが有する否かを照合すること。一部の実施形態において、そのような照合は、例えば、データ証明サービスからの１つ以上の証明書のアサーションに依存してもよい。
・状態ベースの条件：状態データベースにおける情報を照合すること。
例えば、状態データベースは、制御プログラムの以前の実行の結果として生成される情報、および／または購読、帰属関係などの所有権を証明するトークンを含んでもよい。それによって、カウンタ（例えば再生の回数、エクスポートの回数、経過時間限度など）、および記録されたイベントおよび条件に関する他の情報を含む条件の評価を可能にする。
・環境特性：例えば、ホスト環境におけるハードウェアおよび／またはソフトウェアが一定の特徴（例えば義務の認識および実施をする能力）を有するか否かを照合すること、一定のソフトウェアまたはハードウェア構成要素（例えば安全な出力チャネル）の有無を照合すること、近似情報（例えば別の装置またはアプリケーションに対するリクエスト側装置の近似）を照合すること、ネットワークサービスおよび／またはエージェントを使用して遠隔システムの特徴および／または遠隔システムに格納されたデータを照合することなど。
【００５１】
これらの条件または他の任意の適切な条件を使用して、制御オブジェクトは、コンテンツをエクスポート、転送、レンダリングなどできる方法を管理する規則を表現することができる。上記の条件リストは、事実上、例示的なものであり、所望の条件を検証するためにシステムコールを実現することによって、任意の適切な条件を規定および使用できることが理解される。例えば、限定するものではないが、特定のサブネットワークに装置が配置されることを要求することが望ましい場合、システムコールを規定することができる（例えばＧｅｔＩＰＣｏｎｆｉｇ）。これはホスト装置のＩＰＣｏｎｆｉｇ情報（または、システムコールがエージェントを使用する遠隔装置上で稼働する場合は遠隔装置のＩＰＣｏｎｆｉｇ情報）を返すように操作可能である。これは、定められたサブネットワークに装置が配置されたか否かを検証するために制御プログラムによって使用できる。
【００５２】
１．４．２．エージェント
本明細書に記載するＤＲＭエンジン関連のシステムおよび方法の好ましい実施形態は、制御プログラムを運ぶ独立オブジェクトにサポートを提供する。そのような「エージェント」は、指定された機能（例えば遠隔ＤＲＭエンジンの安全な状態記憶への書き込み）を達成するために、遠隔システム上で稼働するＤＲＭエンジンに分散することができる。例えば、エージェントは、遠隔サービスとの接触、または遠隔制御プログラムの実行の結果として、送信することができる。エージェントは、コンテンツ移動操作の遂行、カウンタの初期化、ノードの登録取り消しなどのために使用することもできる。さらに別の例として、エージェントは、遠隔ノードから別のノードまでの到達可能性分析を実行するために使用できる。そのようなエージェントは、例えば、第１ユーザに登録された装置が第２ユーザに登録されることを禁止するポリシーを実施する際に有用であり得る。第２ユーザが登録をリクエストする場合、第２ユーザ、または第２ユーザの代わりに作動する登録サービスによって、エージェントが装置に送信されることによって、装置がすでに第１ユーザに登録されているか否かを決定する。装置がすでに第１ユーザに登録されている場合、第２ユーザの登録リクエストは拒絶される。
【００５３】
図７Ａおよび図７Ｂは、一実施形態におけるエージェントの使用方法を例示する。図７Ａに示すように、２つのエンティティ（システムＡ７００およびシステムＢ７０２）はコンピュータネットワーク７０３を通じて互いに通信することを望み、ＤＲＭシステムが使用されていると仮定されたい。ＤＲＭシステムは、一定の操作（例えば保護されたコンテンツにアクセスすること）に関する規則を記述および実施することができ、ＤＲＭオブジェクトを作成することができる。ＤＲＭオブジェクトは、帰属関係、登録状態などを示すために使用することができる。場合によっては、規則は、システムＡ７００の上で評価されるが、システムＢ７０２の状態に依存する情報を必要とする。その情報は、システムＡ７００上で規則を実施しているＤＲＭシステム７０４によって信頼される必要がある。
【００５４】
例えば、システムＡ７００上のＤＲＭシステム７０４は、システムＡ７００からシステムＢ７０２までのコンテンツの遠隔レンダリングを実行する規則を評価／実施してもよい。規則は、システムＢ７０２が一定の装置グループの一部である場合のみに、そのような操作が許可されることを示してもよい。そのグループにおける帰属関係は、システムＢ７０２上でアクセス可能な安全な状態データベース７１６における状態オブジェクト７１１の存在によって表明される。
【００５５】
そのような状況を処理するために、好ましい実施形態において使用される方法は、エージェントを利用する。例えば、システムＡ７００がシステムＢ７０２から情報を必要とする場合、システムＡ７００は、エージェント７０５を準備する。一実施形態において、エージェント７０５は、システムＡ７００からシステムＢ７０２に送信される制御プログラム（例えばＤＲＭエンジンによって実行できる一連の命令）である。一実施形態において、システムＡ７００は、認証された通信チャネル７２０を通じて、エージェントコード７０５をシステムＢ７０２に送信するので、システムＡ７００は、エージェント７０５が実行するシステムＢ７０２上に実際にあることを確信することができる。一部の実施形態において、システムＡ７００は、エージェントコード７０５とともに、１つ以上のパラメータを、システムＢ７０２に通信してもよい。１つ以上のパラメータは、エージェントコード７０５がその作業を遂行するために使用する。
【００５６】
図７Ｂに示すように、システムＢ７０２は、エージェント７０５および任意の関連するエージェントパラメータを受信し、エージェントコード７０５を実行する。エージェント７０５がシステムＢ７０２上で実行されると、好ましくは認証された通信チャネル７１０を通じて、エージェント７０５は、システムＢの状態データベース７１６にアクセスし、状態情報７１１を検索、および／または状態情報７１１を用いて１つ以上の計算を実行し、システムＡ７００に結果７１３を送信する。ここで、システムＡ７００は、その評価を継続するために必要な情報を有する。
【００５７】
１．４．３．リンク制約
一実施形態において、コンテンツ項目上の一定の操作（例えば「再生」）の実行を管理する規則を示すルーチンのセットは、「アクション制御」と呼ばれる。リンクオブジェクト上の有効性制約を示すルーチンのセットは、「リンク制約」を呼ばれる。アクション制御と同様に、好ましい実施形態において、リンク制約は、条件の任意の適切な組み合わせを表現することができる。更にアクション制御と同様に、リンク制約は、サービスインタフェースまたはエージェントを使用して、ローカルおよび／または遠隔で評価することができる。
【００５８】
１．４．４．義務およびコールバック
一実施形態において、一定のアクションは、認可される際に、ホストアプリケーションからの更なる関与を必要とする。義務は、リクエストするコンテンツ鍵の使用時または使用後に、ホストアプリケーションによって実行される必要のある操作を表す。コールバックは、リクエストするコンテンツ鍵の使用時または使用後に、ホストアプリケーションによって実行される必要のある制御プログラムのルーチンのうちの１つ以上に対する呼び出しを表す。義務の例は、限定するものではないが、コンテンツのレンダリング中に一定の出力および／または制御をオフにするという必要条件（例えば、保護されていない出力に対するコンテンツの書き込むことを防止したり、またはコンテンツの一定の重要なセグメントを早送りすることを防止したりするため）、コンテンツの使用に関する情報を、記録したり（例えば測定または審査情報）、および／または遠隔サイト（例えば情報センタ、サービスプロバイダなど）に送信するという必要条件、エージェントプログラムをローカルまたは遠隔で実行するという必要条件などを含む。コールバックの例は、限定するものではないが、コンテンツの使用が停止されたときに、一定の経過時間（例えばコンテンツ使用の経過時間）の後、一定のイベント（例えばトライアルコンテンツレンダリング期間の完了）の発生の後などに、ホストが、一定の絶対時間において制御プログラムをコールバックする、という必要条件を含む。例えば、一定の経過時間後のコールバックは、予算、再生回数などを増減させるために使用することができる（例えば、少なくとも一定時間にわたって１つのコンテンツを使用する場合、ユーザ予算から引き落とすのみ）。従って、ユーザが誤って再生ボタンを押し、即時に停止を押した場合、ユーザのアカウントから引き落としされることを防止する。
【００５９】
一実施形態において、異なる種類の義務およびコールバックがある。アプリケーションがサポートまたは理解しない任意の重要な義務またはコールバックに遭遇した場合（例えばアプリケーションを実行した後で義務の種類が規定されたため）、アプリケーションは、この義務パラメータまたはコールバックパラメータが返されたアクションの継続を拒絶する必要がある。
【００６０】
１．４．５．実施例
図８〜１２は、ＤＲＭエンジンの例示的実施形態が１つのコンテンツの使用を制御できる方法の実施例を示す。図８を参照して、ＤＲＭエンジンが、コンテンツ項目８０２および８０４のグループ８００を再生するリクエストを受信したと仮定されたい。例えば、コンテンツ項目８０２および８０４は、マルチメディアプレゼンテーション、異なるトラックのアルバム、購読サービスから入手する異なるコンテンツ、電子メール添付などの、異なる副次的な部分を含んでもよい。リクエストは、ＤＲＭエンジンによってホストアプリケーションから受信されてもよく、ホストアプリケーションは、その実行中にコンピューティング装置のユーザからリクエストを受信する。ホストアプリケーションからのリクエストは、リクエストされたアクション、アクションを取る対象のコンテンツ、およびコンテンツを管理するライセンスを一般に識別する。ＤＲＭエンジンは、リクエストが認可されるべきか否かを決定する際に、図５に例示するプロセスに従う。
【００６１】
図８および図９は、図５に示すプロセスのより詳細な非限定的な実施例を提供する。図９を参照して、ＤＲＭエンジンは、コンテンツ項目８０２および８０４にアクセスするリクエストを受信すると（ブロック９００）、リクエストまたはその所有権において識別されるライセンスを検討することによって、有効なライセンスが存在するか否かを知る。例えば、ＤＲＭエンジンは、コンテンツ項目８０２および８０４の一意の識別子を含む、プロテクタオブジェクト８０６および８０８を最初に識別し得る（すなわち、それぞれＮＳ：００７およびＮＳ：００８）（図９のブロック９０２）。次に、ＤＲＭエンジンは、プロテクタオブジェクト８０６および８０８において識別されるＣｏｎｔｅｎｔＫｅｙオブジェクト８１０および８１２を見つける（図９のブロック９０４）。このことは、次に、ＤＲＭエンジンが、ＣｏｎｔｅｎｔＫｅｙオブジェクト８１０および８１２を参照するコントローラ８１４を識別することを可能にする（図９のブロック９０６）。好ましい実施形態において、コントローラ８１４は、署名され、ＤＲＭエンジンは、その署名を検証する（またはホストサービスにそれを検証するように求める）。ＤＲＭエンジンは、コントローラ８１４を使用することによって、ＣｏｎｔｅｎｔＫｅｙオブジェクト８１０および８１２（従ってコンテンツ項目８０２および８０４）の使用を管理する制御オブジェクト８１６を識別する（図９のブロック９０８）。好ましい実施形態において、ＤＲＭエンジンは、制御オブジェクト８１６の完全性を検証する（例えば、制御オブジェクト８１６のダイジェストを算出し、コントローラ８１４に含まれるダイジェストとそれを比較することによって）。完全性検証が成功した場合、ＤＲＭエンジンは、制御オブジェクト８１６に含まれる制御コードを実行し（ブロック９１０）、ホストアプリケーションに結果を戻す（ブロック９１２）。ホストアプリケーションは、それを使用することによって、コンテンツにアクセスするユーザのリクエストを認可または拒絶する。制御コードの結果は、ホストアプリケーションが満たす必要のある１つ以上の義務またはコールバックを任意に特定してもよい。
【００６２】
図１０は、図９のブロック９１０および９１２において指定されるアクション（すなわち、制御プログラムを実行してその結果を戻すこと）をＤＲＭエンジンが実行し得る方法の、より詳細な実施例である。図１０に示すように、ＤＲＭエンジンは、関連する制御オブジェクトを識別すると、制御オブジェクトに含まれるバイトコードを、好ましくはＤＲＭエンジンによってホストされる仮想マシンの中にロードする（ブロック１０００）。ＤＲＭエンジンおよび／または仮想マシンは、仮想マシンの実行時環境を更に一般に初期化する（ブロック１００２）。例えば、仮想マシンは、制御プログラムの実行のために必要なメモリを割り当て、レジスタおよび他の環境変数を初期化し、および／または仮想マシンが稼働中のホスト環境に関する情報を入手してもよい（例えば、後述するように、Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔ呼び出しを行うことによって）。一部の実施形態において、ブロック１０００および１００２は、効果的に組み合わせたりインタリーブしたりすることができ、および／またはその順序を逆転できることが理解される。図１０に示すように、仮想マシンは、次に制御プログラムのバイトコードを実行する（ブロック１００４）。本明細書の他の場所に記載するように、このことは、他の仮想マシンコードに対して呼び出しを行うこと、保証格納域から状態情報を検索することなどを含み得る。制御プログラムは、実行を終了すると、例えば呼び出しアプリケーションによって使用され得る出力（例えば、好ましい実施形態において、ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋ）を提供する。アプリケーションは、リクエストが認可されたか否かを決定し、認可された場合は任意の義務またはコールバックがそれに関連するか否かを決定する。アプリケーションは、リクエストが拒絶されたか否かを決定し、拒絶された場合は拒絶の理由を決定する。あるいは、アプリケーションは、実行中に任意のエラーが生じたか否かを決定する（ブロック１００６）。
【００６３】
前述のように、制御オブジェクト８１６に含まれる制御コードは、コンテンツ項目８０２および８０４のリクエストされた使用を行うために満たさなければならない条件または他の必要条件を特定する。本明細書に記載するシステムおよび方法は、任意の複雑な条件のセットを指定することを可能にする。しかしながら、この実施例のために、制御プログラムは、コンテンツ項目８０２および８０４を再生するために、（ａ）コンテンツを再生するリクエストが行われた装置から、所与のユーザのノードに到達可能でなければならないこと、および（ｂ）現在の日付は指定日の後でなければならないこと、を必要とするように設計されていると仮定されたい。
【００６４】
図１１は、装置１１０２上で稼働するＤＲＭエンジン１１００の例示的実施形態が、上述した例示的制御プログラムを実行し得る方法を示す。図１２は、実行プロセスに関わるステップのフローチャートである。図１１に示すように、ＤＲＭエンジン１１００は、（例えばＳｙｓｔｅｍ．Ｈｏｓｔ．Ｓｐａｗｎ  Ｖｍを呼び出すことによって）仮想マシン実行状況１１０４を作成し、制御プログラムをロードする。仮想マシン１１０４は、ＤＲＭエンジン１１００によって特定されるエントリポイントにおいて制御プログラムの実行を開始する（例えばＣｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．Ｐｌａｙ．ｐｅｒｆｏｒｍルーチンの位置において）。この実施例において、制御プログラムは、ＤＲＭエンジン１１００が稼働している装置１１０２の個人ノードから、所与のノードに到達可能か否かを決定する必要がある。この決定を行うために、制御プログラムは、ＤＲＭエンジン１１００によって提供されるリンクマネージャサービス１１０６に対して、呼び出し１１０５を行い、リンクが必要とされるノードを特定する（図１２のブロック１２００）。リンクマネージャ１１０６は、あるノードが別のノードから到達可能であるか否かを決定するために、リンクオブジェクトを評価することを担う。このことを効率的に行うために、リンクマネージャ１１０６は、装置１１０２の個人ノード１１１０から、装置１１０２が所有する任意のリンクオブジェクトにおいて特定される様々なノード１１１４までの、経路が存在するか否かを事前算出してもよい。すなわち、リンクマネージャ１１０６は、アクセスするリンクの「ｔｏ」および「ｆｒｏｍ」フィールドを単に照合することによって、どのノードが、装置１１０２の個人ノード１１１０から潜在的に到達可能であるかを決定してもよい。リンクマネージャ１１０６は、仮想マシン１１０４から呼び出し１１０５受信すると、個人ノード１１１０から指定ノード１１１２までの経路が存在するか否かをまず決定することによって、指定ノード１１１２が到達可能か否かを決定する（例えば、理論的に到達可能であるとすでに決定したノードのリストにおけるノードＩＤを照合することによって）（図１２のブロック１２０２）。経路が存在する場合、リンクマネージャ１１０６は、リンクに含まれる任意の制御プログラムを評価することによって、リンクが有効か否かを知る（図１２のブロック１２０４〜１２１０）。リンクオブジェクトにおける制御プログラムを評価するために（図１２のブロック１２０６）、リンクマネージャ１１０６は、それ自身の仮想マシン１１０８を使用してもよく、リンクオブジェクトに含まれる制御プログラムを仮想マシン上で実行する、リンクマネージャ１１０６は、仮想マシン１１０４において実行する制御プログラムに対して、決定の結果（すなわち所与のノードが到達可能か否か）を戻す。決定の結果は、コンテンツを再生するリクエストが認可されるか否かの総合評価において使用される。仮想マシン１１０４上で実行する制御プログラムは、指定ノード１１１２が装置１１０２の個人ノード１１１０から到達可能であることを決定すると、指定された日付の制約が満たされるか否かを次に決定する（図１２のブロック１２１２）。日付の���約が満たされた場合（すなわち、ブロック１２１２から「ＹＥＳ」で出る場合）、制御プログラムは、指定された条件が満たされていることを示す結果を戻す（図１２のブロック１２１４）。そうでない場合、制御プログラムは、条件が満たされないことを示す結果を戻す（図１２のブロック１２１６）。
【００６５】
上述したような制御プログラムの例を、以下に示す。
【表２】
2009512096.tif 000004
【表３】
2009512096.tif 000005
【表４】
2009512096.tif 000006
【００６６】
制御プログラムの更なる例は、付録Ｅに含まれる。
【００６７】
３．コンテンツ消費およびパッケージングアプリケーション
以下は、ＤＲＭによって保護されたコンテンツを消費するアプリケーション（例えば、メディアプレーヤ、ワードプロセッサ、電子メールクライアントなど（例えば図３のアプリケーション３０３ａ、３０３ｃおよび３０３ｄ））、および消費アプリケーションを対象にするコンテンツをパッケージングするパッケージングアプリケーション（例えばアプリケーション３０３ｂ）の例示的実施形態のより詳細な説明である。
【００６８】
１．５．コンテンツを消費するアプリケーションアーキテクチャ
コンテンツを消費するアプリケーションは、保護されたコンテンツへのアクセスに一般に焦点をあてるものであるか、あるいは他の機能（例えばコンテンツのパッケージング）をも実行する汎用アプリケーションの一部であり得る。様々な実施形態において、コンテンツを消費するアプリケーションは、以下の一部または全部を実行してもよい。
・インタフェースを提供することによって、ユーザは、保護されたコンテンツオブジェクトに対するアクセスをリクエストすることができ、コンテンツに関する情報またはエラー情報を受信することができること。
・ファイルシステムとの対話処理を管理すること。
・保護されたコンテンツオブジェクトのフォーマットを認識すること。
・コンテンツにアクセスする許可が認可され得るか否かを知るために、ＤＲＭエンジンにコンテンツのライセンスを評価するようにリクエストすること。
・デジタル署名を検証し、ＤＲＭエンジンが実行する必要のある他の汎用暗号機能を処理すること。
・ＤＲＭエンジンに、保護されたコンテンツの解読に必要な鍵を提供するようにリクエストすること。
・保護されたコンテンツを解読し、媒体レンダリングサービスと対話することによって、コンテンツをレンダリングすること。
【００６９】
一実施形態において、ＤＲＭクライアントエンジンは、コンテンツに関連するライセンスを評価し、コンテンツを使用する許可を認可または拒絶し、コンテンツを消費するアプリケーションに解読鍵を提供する。ＤＲＭクライアントエンジンは、コンテンツを消費するアプリケーションに対して、１つ以上の義務および／またはコールバックを更に発行してもよく、コンテンツに対するアクセスを与える結果として、アプリケーションに一定のアクションを実行することを要求する。
【００７０】
図１３は、一実施形態においてコンテンツを消費するクライアントアプリケーション１３００を構成する要素を示す。図１３に示すように、ホストアプリケーション１３０２は、クライアントの論理的な中心点である。ホストアプリケーション１３０２は、他のモジュール間の対話処理パターン、ならびにユーザインタフェース１３０４を介するユーザとの対話処理を営むことを担う。ホストアプリケーション１３０２は、ホストサービスインタフェース１３０８を介して、ＤＲＭエンジン１３０６に対してサービスのセットを提供する。ホストサービスインタフェース１３０８は、ホストアプリケーション１３０２によって管理されるデータに対するアクセス、ならびにホストアプリケーション１３０２によって実行される一定のライブラリ関数に対するアクセスを、ＤＲＭエンジン１３０６が獲得することを可能にする。一実施形態において、ホストサービスインタフェース１３０８は、ＤＲＭエンジン１３０６にとって唯一のアウトバウンドインタフェースである。
【００７１】
一実施形態において、ＤＲＭエンジン１３０６は、ホストアプリケーション１３０２によって管理されるマルチメディアコンテンツと直接に対話しない。ホストアプリケーション１３０２は、マルチメディアコンテンツにアクセスするためのコンテンツサービス１３１０と論理的に対話し、エンジンによって処理されなければならないデータの部分のみをＤＲＭエンジン１３０６に渡す。コンテンツとの他の対話処理は、媒体レンダリングエンジン１３１２によって実行される。例えば、一実施形態において、コンテンツサービス１３１０は、メディアサーバからコンテンツを獲得し、コンテンツをクライアントの信頼性の高い記憶装置において格納および管理することを担う。その一方で、媒体レンダリングエンジン１３１２は、マルチメディアコンテンツにアクセスし、それをレンダリングすることを担うサブシステムである（例えばビデオ出力および／または音声出力上で）。一実施形態において、媒体レンダリングエンジン１３１２は、ＤＲＭエンジン１３０６から一部の情報（例えばコンテンツ解読鍵）を受信する。しかし、一実施形態において、ＤＲＭエンジン１３０６は、媒体レンダリングエンジン１３１２と直接に対話せず、ホストアプリケーション１３０２を介して対話する。
【００７２】
ＤＲＭエンジン１３０６によって必要とされる情報の一部は、マルチメディアコンテンツのバンド内で利用可能であり得、コンテンツサービス１３１０によって獲得および管理することができる。しかし、この情報の一部は、他のサービス（例えば個人化サービスまたは帰属関係サービス（図示せず））を介して入手する必要があり得る。
【００７３】
図１３に示す実施形態において、暗号操作（例えば、暗号化、署名照合など）は、暗号サービスブロック１３１４によって処理される。一実施形態において、ＤＲＭエンジン１３０６は、暗号サービスブロック１３１４と直接に対話せず、これに代わって（ホストサービスインタフェース１３０８を使用して）ホスト１３０２を介して間接的に対話し、ホスト１３０２がそのリクエストを転送する。暗号サービス１３１４は、コンテンツ解読を実行するために、例えば媒体レンダリングエンジン１３１２によって使用されてもよい。
【００７４】
図１３は、説明のために提供するものであり、他の実施形態において、図１３に示す様々な構成要素は、再編、合併、分離、除去することができ、および／または新しい構成要素を追加できることが理解される。例えば、限定するものではないが、図１３におけるＤＲＭエンジンとホストアプリケーションとの間の機能の論理的分割は、１つの可能な実施形態の単なる例示であり、実際の実施においては変化させることができる。例えば、ＤＲＭエンジンは、完全にまたは部分的にホストアプリケーションに統合することができる。従って、ホストアプリケーションとＤＲＭエンジンとの間で、機能の任意の適切な分割を使用できることが理解される。
【００７５】
１．６．パッケージャアーキテクチャ
以下は、電子コンテンツをパッケージングするホストアプリケーションのために、パッケージングエンジンが実行し得る機能の例を提供するものである。実際には、パッケージングアプリケーションは、具体的にパッケージングに焦点をあててもよく、あるいは、（例えば、ローカルに、あるいはネットワーク上などの他の場所でパッケージングされる）保護されたコンテンツにアクセスするユーザシステムにおいて稼働する、汎用アプリケーションの一部であり得る。
【００７６】
様々な実施形態において、パッケージングホストアプリケーションは、以下の一部または全部を実行してもよい。
・コンテンツおよびライセンス情報を特定できるユーザインタフェースを提供すること。
・コンテンツを暗号化すること。
・ライセンスを構成するＤＲＭオブジェクトを作成すること。
・コンテンツを含むかまたは参照するコンテンツオブジェクト、およびライセンスを含むかまたは参照するコンテンツオブジェクトを作成すること。
【００７７】
図１４は、一実施形態においてパッケージングアプリケーション１４００を構成する要素を示す。ＤＲＭパッケージングエンジン１４１６は、本明細書に記載するようなライセンス（例えば、制御、コントローラ、プロテクタなどのＤＲＭオブジェクトを含むライセンス）をパッケージングすることを担う。一部の実施形態において、ＤＲＭパッケージングエンジン１４１６は、メタデータをライセンスに関連づけることによって、ライセンスが行う内容を、人間が読み取れる形で説明する。
【００７８】
一実施形態において、ホストアプリケーション１４０２は、ユーザインタフェース１４０４を提供し、情報の入手を担う。この情報は、例えばユーザ（一般にコンテンツの所有者またはプロバイダ）が実行することを望むコンテンツ参照およびアクションである（例えば、誰にコンテンツを結合するか、ライセンスにどのようなコンテンツ使用条件を含めるかなど）。ユーザインタフェース１４０４は、パッケージングプロセスに関する情報を表示することもできる（例えば、発行されるライセンスのテキスト、故障が生じた場合には故障の理由）。一部の実施形態において、ホストアプリケーション１４０２によって必要とされる一部の情報は、他のサービス（例えば認証サービスまたは認可サービス）の使用、および／またはサービスアクセスポイント（ＳＡＰ）を通した帰属関係の使用を必要としてもよい。従って、一部の実施形態において、パッケージングアプリケーション１４００および／またはホストアプリケーション１４０２は、以下の一部または全部を実施することを必要としてもよい。
・媒体フォーマットサービス１４０６：一実施形態において、この要素は、媒体フォーマット操作（例えばトランスコーディングおよびパッケージング）の管理を担う。
この要素は、コンテンツ暗号化サービスモジュール１４０８を介して達成されるコンテンツ暗号化も担う。
・汎用暗号サービス１４１０：一実施形態において、この要素は、署名の発行／検証、ならびに一部のデータの暗号化／解読を担う。そのような操作のためのリクエストは、ホストサービスインタフェース１４１２を介して、サービスアクセスポイント１４１４、またはＤＲＭパッケージングエンジン１４１６によって発行することができる。
・コンテンツ暗号化サービス１４０８：一実施形態において、このモジュールは、アプリケーションを知らないので、汎用暗号サービス１４１０から論理的に切り離される。これは、ＤＲＭパッケージングエンジン１４１６によってすでに発行された鍵のセットを用いて、コンテンツパッケージング時において、媒体フォーマットサービスによって営まれる。
【００７９】
４．鍵導出
以下は、本明細書に記載するＤＲＭエンジンおよびシステムアーキテクチャの好ましい実施形態におのずと適合し、および／または他の状況において使用できる、鍵導出システムを説明するものである。以下のセクションにおける実施例の一部は、「スキューバ」として公知の、この鍵導出システムの好ましい実施形態の照合基準製品からとられるものである。更なる実施形態は、５５１出願に記載されている。
【００８０】
図１５に示すように、一部の実施形態において、リンクオブジェクト１５３０ａおよび１５３０ｂは、ノード１５００ａ、１５００ｂ、１５００ｃの関係を確立するという主な目的に加えて、鍵を分散するために使用される。上述のように、制御オブジェクトは、アクションを実行するリクエストを認可するべきか否かを決定するために使用できる制御プログラムを含むことができる。これを行うために、制御プログラムは、特定のノードがリンクのチェーンを介して到達可能か否かを照合してもよい。本明細書に記載する鍵導出技術は、リンクのこのチェーンの存在を利用することによって、鍵の配信を容易にするので、制御プログラムを実行するＤＲＭエンジンにとって鍵を利用可能にすることができる。
【００８１】
１つの例示的実施形態において、各ノードオブジェクト１５００ａ、１５００ｂ、１５００ｃは、任意の鍵配信システムを使用する所与の展開において、コンテンツ鍵および他のノードの鍵を暗号化するために使用する鍵のセットを有する。同じ展開において使用するために作成されるリンクオブジェクト１５３０ａおよび１５３０ｂは、ＤＲＭエンジンによってリンクのチェーンが処理されるときに鍵情報の導出を可能にするペイロードとして、一部の暗号データを含む。
【００８２】
この態様で鍵を運ぶノードおよびリンクを用いて、ノードＡ（１５００ａ）からノードＣ（１５００ｃ）までのリンク１５３０ａおよび１５３０ｂのチェーンを想定すると、ノードＡ（１５１５ａおよび１５２５ａ）の秘密共有鍵にアクセスするエンティティ（例えばクライアントホストアプリケーションのＤＲＭエンジン）は、ノードＣ（１５１５ｃおよび１５２５ｃ）の秘密共有鍵にもアクセスする。ノードＣの秘密共有鍵にアクセスすることによって、その鍵によって暗号化される任意のコンテンツ鍵に対するアクセスをエンティティに与える。
【００８３】
１．７．ノード、エンティティ、および鍵
１．７．１．エンティティ
ＤＲＭシステムの一実施形態において、ノードは、データオブジェクトであり、システムにおいて作動中の参加者ではない。作動中の参加者は、この状況において、エンティティと呼ばれる。エンティティの例は、メディアプレーヤ、装置、購読サービス、コンテンツパッケージャなどである。エンティティは、エンティティに関連するノードを一般に有する。コンテンツを消費するエンティティは、ＤＲＭエンジンを使用し、その個人を構成する少なくとも１つのノードオブジェクトを管理する。一実施形態において、エンティティは、管理するノードオブジェクトのすべてのデータ（オブジェクトのすべての個人情報を含む）にアクセスすると想定される。
【００８４】
１．７．２．ノード
鍵導出システムの例示的実施形態に関与するノードオブジェクトは、データの一部として鍵を含む。一実施形態において、ノードは、２つの一般的な種類の鍵、すなわち共有鍵および機密鍵を含んでもよい。以下のセクションは、様々な実施形態において使用できる異なる鍵の種類を記載する。しかしながら、特定の展開は、これらの鍵のサブセットのみを使用できることが理解される。例えば、システムは、鍵のペアを用いることによってのみ動作するように構成でき、秘密共通鍵の使用を除外する。または、共有鍵を使用することのみが必要である場合、システムは、機密鍵を用いて供給ノードなしで展開することができる。
【００８５】
１．７．２．１．共有鍵
共有鍵は、ノードＮおよびすべてのノードＰｘによって共有される公開／秘密の鍵のペアおよび／または共通鍵であり、それに対して、鍵導出拡張を含むＰｘからＮへのリンクが存在する。
【００８６】
共有公開鍵：Ｋｐｕｂ―ｓｈａｒｅ［Ｎ］。これは、公開鍵暗号のための公開／秘密の鍵のペアの公開部分である。この鍵は、一般に証明書を伴うので、それに機密情報を暗号によって結合することを望むエンティティによって、その証明を検証することができる。
【００８７】
共有秘密キー：Ｋｐｒｉｖ―ｓｈａｒｅ［Ｎ］。これは、公開／秘密の鍵のペアの秘密の部分である。ノードを管理するエンティティは、この秘密鍵が秘密に保たれるように保証することを担う。この理由のために、この秘密鍵は、一般に残りのノード情報とは別に格納および輸送される。この秘密鍵は、リンクの鍵導出拡張を通して他のノードによって共用されるダウンストリームであり得る。
【００８８】
共有共通鍵：Ｋｓ―ｓｈａｒｅ［Ｎ］。これは、共通暗号を用いて使用する鍵である。秘密鍵と同様に、この鍵は機密であり、ノードを管理するエンティティは、鍵を秘密に保つことを担う。この秘密鍵は、リンクの鍵導出拡張を通して他のノードによって共用されるダウンストリームであり得る。
【００８９】
１．７．２．２．機密鍵
機密鍵は、機密鍵が帰属するノードを管理するエンティティにのみ知られる鍵のペアおよび／または共通鍵である。これらの鍵と上述した共有鍵との相違点は、これらの鍵が、リンクにおける鍵導出拡張を通して他のノードによって共有されないということである。
【００９０】
機密公開鍵：Ｋｐｕｂ―ｃｏｎｆ［Ｎ］。これは、公開鍵暗号のための公開／秘密の鍵のペアの公開部分である。この鍵は、一般に証明書を伴うので、それに機密情報を暗号によって結合することを望むエンティティによって、その証明を検証することができる。
【００９１】
機密秘密鍵：Ｋｐｒｉｖ―ｃｏｎｆ［Ｎ］これは、公開／秘密の鍵のペアの秘密の部分である。ノードを管理するエンティティは、この秘密鍵が秘密に保たれるように保証することを担う。この理由のために、この秘密鍵は、一般に残りのノード情報とは別に格納および輸送される。
【００９２】
機密性共通鍵：Ｋｓ―ｃｏｎｆ［Ｎ］これは、共通暗号を用いて使用する鍵である。機密秘密鍵と同様に、この鍵は、秘密に保たれる。
【００９３】
１．８．暗号要素
本明細書に記載する鍵の導出および配信システムの好ましい実施形態は、様々な異なる暗号化アルゴリズムを使用して実現することができ、暗号化アルゴリズムの任意の特定の選択に限定されない。それでもやはり、プロファイルの所与の展開について、すべての関与するエンティティは、サポートされたアルゴリズムのセットに一致することを一般に必要とする（ここでプロファイルという用語は、特定のインプリメンテーション（例えば、鍵導出のためのＲＳＡ、コード化オブジェクトのためのＸＭＬ、ファイルフォーマットのためのＭＰ４など）において使用される実際の技術の集合の規格、および／またはオブジェクトが実際的な展開において規定されるときに存在する意味論的な状況の他の表現を一般に指す）。
【００９４】
一実施形態において、展開は、少なくとも１つの公開鍵暗号（例えばＲＳＡ）、および１つの共通鍵暗号（例えばＡＥＳ）のための、サポートを含む。
【００９５】
暗号機能を指すときに、以下の表記法が使用される。
・Ｅｐ（Ｋｐｕｂ［Ｎ］，（Ｍ））は、「メッセージＭは、公開鍵暗号を用いて、ノードＮの、公開鍵Ｋｐｕｂによって暗号化される」を意味する。
・Ｄｐ（Ｋｐｒｉｖ［Ｎ］，（Ｍ））は、「メッセージＭは、公開鍵暗号を用いて、ノードＮの、秘密鍵Ｋｐｒｉｖによって解読される」を意味する。
・Ｅｓ（Ｋｓ［Ｎ］，（Ｍ））は、「メッセージＭは、共通鍵暗号を用いて、ノードＮの、共通鍵Ｋｓによって暗号化される」を意味する。
・Ｄｓ（Ｋｓ［Ｎ］，（Ｍ））は、「メッセージＭは、共通鍵暗号を用いて、ノードＮの、共通鍵Ｋｓによって解読される」を意味する。
【００９６】
１．９．コンテンツ鍵のターゲティング
好ましい実施形態において、２つの種類の暗号ターゲティングが使用される。ターゲットノードの共有鍵に対してコンテンツ鍵をターゲットにすることは、そのターゲットノードの秘密共有鍵を共有するすべてのエンティティに対して、その鍵を利用可能にすることを意味する。ノードの機密鍵に対してコンテンツ鍵を対象にすることは、そのノードを管理するエンティティのみに対して、その鍵を利用可能にすることを意味する。コンテンツ鍵のターゲティングは、以下の方法の一方または両方を使用して、ＣｏｎｔｅｎｔＫｅｙオブジェクトによって運ばれるコンテンツ鍵（ＣＫ）を暗号化することによって行われる。
・公開結合：Ｅｐ（Ｋｐｕｂ［Ｎ］（ＣＫ））を含むＣｏｎｔｅｎｔＫｅｙオブジェクトを作成すること。
・共通結合：Ｅｓ（Ｋｓ［Ｎ］（ＣＫ））を含むＣｏｎｔｅｎｔＫｅｙオブジェクトを作成すること。
【００９７】
好ましい実施形態において、可能な場合には共通結合が使用される。なぜなら、共通結合は、よりコンピュータ集約的でないアルゴリズムに関わるからであり、従って受信エンティティにとっての煩わしさを低減する。しかしながら、ＣｏｎｔｅｎｔＫｅｙオブジェクトを作成するエンティティ（一般に、コンテンツパッケージャ）は、必ずしもＫｓ［Ｎ］にアクセスしなくてもよい。パッケージャがＫｓ［Ｎ］を有しない場合、公開結合を使用することができる。なぜなら、Ｋｐｕｂ［Ｎ］は、機密情報ではないので、公開結合を行う必要のあるエンティティに対して利用可能にできるからである。Ｋｐｕｂ［Ｎ］は通常、コンテンツ鍵を対象にする必要のあるエンティティに対して利用可能にされる。これは証明書を伴い、証明書は、一部の合意に基づくポリシーに従ってコンテンツ鍵を処理する際に、Ｋｐｕｂ［Ｎ］が実際に信頼できるノードの鍵であるか否かを決定するために、エンティティによって検査することができる（例えば、そのノードは、システムの機能的な操作上のセキュリティポリシーに従う、ＤＲＭエンジンおよびホストアプリケーションを実行するエンティティに対応する）。
【００９８】
１．１０．リンクを使用した鍵の導出
エンティティが個人ノードから到達可能なすべてのノードの共有鍵にアクセスすることを可能にするために、一実施形態において、リンクオブジェクトは、任意の鍵拡張ペイロードを含む。この鍵拡張ペイロードは、リンクの「ｆｒｏｍ」ノードの秘密鍵にアクセスするエンティティが、リンクの「ｔｏ」ノードの秘密共有鍵にもアクセスすることを可能にする。このようにして、エンティティは、その個人ノードから到達可能なノードに対して対象にされる、任意のコンテンツ鍵を解読することができる（ターゲットノードの共有鍵を使用してターゲティングが行われる場合）。
【００９９】
一実施形態において、ＤＲＭエンジンがリンクオブジェクトを処理する際に、ＤＲＭエンジンは、アクセスする鍵の内部チェーンをアップデートするために、各リンクの鍵拡張ペイロードを処理する。一実施形態において、ノードＦからノードＴへのリンクＬの鍵拡張ペイロードは、以下のいずれかを含む。
・公開導出情報：Ｅｐ（Ｋｐｕｂ―ｓｈａｒｅ［Ｆ］，｛Ｋｓ―ｓｈａｒｅ［Ｔ］，Ｋｐｒｉｖ―ｓｈａｒｅ［Ｔ］｝）、または
・共通導出情報：Ｅｓ（Ｋｓ―ｓｈａｒｅ［Ｆ］，｛Ｋｓ―ｓｈａｒｅ［Ｔ］，Ｋｐｒｉｖ―ｓｈａｒｅ［Ｔ］｝）。
【０１００】
ここで、｛Ｋｓ―ｓｈａｒｅ［Ｔ］，Ｋｐｒｉｖ―ｓｈａｒｅ［Ｔ］｝は、Ｋｓ―ｓｈａｒｅ［Ｔ］およびＫｐｒｉｖ―ｓｈａｒｅ［Ｔ］を含むデータ構造である。
【０１０１】
公開導出情報は、ノードＴ、Ｋｓ―ｓｈａｒｅ［Ｔ］およびＫｐｒｉｖ―ｓｈａｒｅ［Ｔ］の秘密共有鍵を、ノードＦ、Ｋｐｒｉｖ―ｓｈａｒｅ［Ｆ］の秘密共有鍵にアクセスする任意のエンティティに伝達するために使用される。
【０１０２】
共通導出情報は、ノードＴ、Ｋｓ―ｓｈａｒｅ［Ｔ］およびＫｐｒｉｖ―ｓｈａｒｅ［Ｔ］の秘密共有鍵を、ノードＦ、Ｋｓ―ｓｈａｒｅ［Ｆ］の共通共有鍵にアクセスする任意のエンティティに伝達するために使用される。
【０１０３】
ノードに対してコンテンツ鍵を対象にすることに関して、リンクに含む好ましいペイロードは、共通導出情報である。このことは、リンク作成者がＫｓ―ｓｈａｒｅ［Ｆ］にアクセスする場合に可能である。そうでない場合には、リンク作成者は、リンクのためのペイロードとして公開導出情報を含むことにフォールバックする。
【０１０４】
リンクを処理するＤＲＭエンジンが、その内部キーチェーンにおいて、Ｋｓ―ｓｈａｒｅ［Ｆ］およびＫｐｒｉｖ―ｓｈａｒｅ［Ｆ］をすでに有すると仮定するならば、リンク（Ｌ［Ｆ→Ｔ］）を処理した後に、ＤＲＭエンジンは、Ｋｓ―ｓｈａｒｅ［Ｔ］およびＫｐｒｉｖ―ｓｈａｒｅ［Ｔ］をも有する。
【０１０５】
一実施形態において、リンクは任意の順序で処理できるので、ＤＲＭエンジンは、所与のリンクＬが処理される時に、鍵導出計算を行えない場合がある。このことは、その時に、ＤＲＭエンジンのキーチェーンが、そのリンクの「ｆｒｏｍ」ノードの鍵をまだ含んでいないという事実に起因する場合がある。この場合、新しい情報がＤＲＭエンジンに利用可能になるときに（例えば新しいリンクＰを処理した後に）、リンクは記憶されており、再び処理される。リンクＰの「ｔｏ」ノードがリンクＬの「ｆｒｏｍ」ノードと同一であり、なおかつリンクＰの「ｆｒｏｍ」ノードが到達可能なノードである場合、リンクＬの「ｆｒｏｍ」ノードも到達可能であり、鍵導出ステップは、リンクＬの「ｆｒｏｍ」ノードの秘密共有鍵を、鍵チェーンに加える。
【０１０６】
５．実施例
本明細書に記載するシステムおよび方法の様々な実施形態を実際に応用する方法を説明するために、以下にいくつかの実施例を提供する。
本明細書に記載するシステムおよび方法は、広範囲にわたる著作権管理および他の機能を有効にすることができる。従って、ここに与えられる具体例は、網羅的であることを意図するものではなく、進歩性のある一連の作業の範囲を例示するものであることが理解される。
【０１０７】
１．１１．実施例：ユーザ、ＰＣ、および装置
コンテンツを再生する著作権を特定のユーザに結びつけるＤＲＭシステムを実現することが所望され、ユーザが所有するすべての再生装置上のコンテンツを再生することがユーザにとって容易になることが所望される、と仮定されたい。必要に応じて再生装置（例えばモバイルプレーヤ）を加えることを可能にするソフトウェアをユーザに提供することを決定すると仮定されたい。しかしながら、ユーザが配信機関としての役割を果たす能力を有しないように、ユーザがコンテンツを転送できる汎用装置の数を限定する何らかのポリシーを設定することが所望される、とさらに仮定されたい。
【０１０８】
これらのシステム要件に基づいて、作成するライセンスをユーザに結びつけ、ユーザとユーザが使用する装置との関係を確立することは、例えば、意味をなす場合がある。従って、この実施例において、必要とされる種類の関係を確立するために、どのような種類のノードが必要であるかを最初に決定してもよい。例えば、以下の種類のノードを規定してもよい。
・ユーザ（例えばコンテンツを使用する権利を有する個人）。
・ＰＣ（例えば、パーソナルコンピュータ上で実行し、コンテンツを再生することができ、付加的な再生装置を特定することができる、ソフトウェアアプリケーション）。
・装置（例えば携帯コンテンツレンダリング装置）。
【０１０９】
各ノードオブジェクトは、オブジェクトが、ユーザ、ＰＣ、または装置を表すか否かを示す型属性を含むことができる。
【０１１０】
例えば、特定の時間において任意の１人のユーザに接続できるＰＣノードオブジェクトの最大数を、４に限定することを決定するとする。ＰＣの数に制約を提供する限り、ユーザに接続される装置の数を限定する必要がないと決定する。このことに基づいて、ユーザノードとアクセスをリクエストするノードとの間に関係を確立できる場合、制御プログラムは、アクセスを可能にするように設定することができる。このノードは、ＰＣまたは装置であり得る。
【０１１１】
図１６は、上述の必要条件を満たすように設計されたシステムを示す。サーバ１６００は、ユーザノードオブジェクト１６０２ａおよび１６０２ｂを、各新規ユーザ１６０４ａおよび１６０４ｂに割り当て、保護されたコンテンツにアクセスするためのユーザ１６０４ａおよび１６０４ｂの能力を、装置１６０６および１６０８、ＰＣ１６１０および１６１２に関連づけるように管理する。ユーザ１６０４ａが、新しい装置１６０６を自分のユーザノード１６０２ａに関連させることを望む場合、サーバ１６００は、装置１６０６がすでに個人化情報１６１４を含むか否かを決定する（装置１６０６が製造時に個人化されている場合がそうである）。装置が個人化情報１６１４を含む場合、サーバ１６００は、その個人化情報１６１４を使用することによって、装置１６０６からユーザノード１６０２ａへのリンク１６１６を作成し、リンク１６１６をユーザの装置１６０６に送信する。ユーザ１６０４ａが、保護されたコンテンツ１６１８を（例えばサーバ１６００から、または何らかの他のコンテンツプロバイダから）入手する場合、コンテンツ１６１８は、ユーザのノード１６０２ａの対象にされる（例えばユーザのノード１６０２ａに関連する秘密共有鍵のうちの１つを有するコンテンツの解読鍵を暗号化することによって）。ライセンス１６１９は、それに関連づけられ、コンテンツにアクセスできる条件を特定する。ユーザ１６０４ａが、装置１６０６上のコンテンツ１６１８の再生を試みる場合、装置１６０６上で実行するＤＲＭエンジン１６２０は、ライセンス１６１９を評価する。この評価は、ユーザノード１６０２ａが到達可能である限り、コンテンツ１６１８が再生可能であることを示す。ＤＲＭエンジン１６２０は、リンク１６１６（ユーザノード１６０２ａが装置１６０６から到達可能であることを示す）を評価し、コンテンツ１６１８にアクセスするユーザ１６０４ａのリクエストを認可する（例えば、ライセンス１６１９の中に含まれるコンテンツ解読鍵の解読を認可することによって）。
【０１１２】
この実施例において、コンテンツ解読鍵は、ユーザのノード１６０２ａに関連する秘密鍵を使用して暗号化されているので、コンテンツ解読鍵を解読するためには、この秘密鍵を入手する必要がある。本明細書の他の場所に記載される任意の鍵導出技術が使用されている場合、装置１６０６の秘密鍵のうちの１つを使用して、リンク１６１６に含まれる鍵導出情報を単に解読することによって、ユーザノードの鍵を入手することができる。解読された鍵導出情報は、ライセンス１６１９（あるいはそこから導出または入手できる情報）に含まれるコンテンツ解読鍵を解読するために必要な鍵を含む。
【０１１３】
図１６を再び参照して、ユーザ１６０４ａが、新しいＰＣ１６１０を自分のユーザノード１６０２ａに関連させることを望むと仮定されたい。サーバ１６００は、ＰＣの最大数があらかじめユーザノード１６０２ａに関連づけられていないことを検証し、ＰＣ１６１０をユーザノード１６０２ａに関連づけることを認可する。しかしながら、関連を実行するためには、サーバ１６００は、ＰＣ１６１０から個人化情報（例えば、暗号鍵、一意の識別子など）を入手する必要がある。しかしながら、ＰＣ１６１０があらかじめ個人化されていない場合（ユーザがＰＣソフトウェアのコピーを単にダウンロードする場合がそうである）、サーバ１６００は、（例えば本明細書の他の場所に記載されるブートストラッププロトコルを使用してＰＣノードオブジェクトを作成することによって）個人化プロセスを実行するか、または個人化プロセスを実行できるサービスプロバイダにユーザを導く。個人化プロセスが完了すると、サーバ１６００は、ＰＣ１６１０からユーザノード１６０２ａへのリンク１６２４を作成し、リンクをＰＣ１６１０に送信することができる。ＰＣは、リンクが有効である限り、リンクを使用し続けることができる。
【０１１４】
ユーザは、後で付加的なＰＣを加えるようにリクエストすることができ、サーバは、ユーザごとのＰＣノードオブジェクトの数を４に限定するポリシーを実施し得る（一般に、必要に応じてユーザが有効リストからＰＣを削除する能力も提供される）。
【０１１５】
さらに別の実施例として、ここで、サービスプロバイダが、ユーザが所有する任意の装置上にユーザが所有する任意のコンテンツを、ユーザが再生できるべきであると決定したと仮定されたい。サービスプロバイダは、ユーザがサーバ１６００と接触するのではなく、ユーザのＰＣソフトウェアがユーザの装置の各々に対するリンクを作成することを可能にすることを更に望み得る。そのような実施形態において、ユーザが新しい装置上でコンテンツを再生することを望む場合、ユーザのＰＣソフトウェアは、新しい装置の機密の個人化情報にアクセスし、その情報を使用することによって、その装置のための新しいリンク（例えば新しい装置からユーザノード１６０２ａへのリンク）を作成し得る。装置が個人化されていない場合、ＰＣソフトウェアは、遠隔サービスにアクセスするか、または装置を遠隔サービスにアクセスさせるように導くことによって、個人化プロセスを実行してもよい。ＰＣソフトウェアは、リンクを新しい装置に送信し得る。この時点において、新しい装置は、有効である限りコンテンツを再生することが可能である。なぜなら、一実施形態において、リンクオブジェクトが存在するならば、リンクオブジェクトが失効または無効にされない限り、別のリンクオブジェクトを作成する必要がないからである。
【０１１６】
上記の実施例において、コンテンツは、ユーザを対象にする。このことを行うために、パッケージャアプリケーションは、コンテンツ用に新しいＩＤを選択するかまたは既存のＩＤを選び、暗号化キーおよび関連するＣｏｎｔｅｎｔＫｅｙオブジェクトを作成し、ならびにコンテンツオブジェクトをＣｏｎｔｅｎｔＫｅｙオブジェクトに結合するプロテクタオブジェクトを作成する。パッケージャは、制御プログラムを用いて制御オブジェクトを作成する（例えばＤＲＭエンジンの仮想マシンによって実行可能なバイトコードでコンパイルされるもの）。これにより、アクションをリクエストするＰＣまたは装置ノードからユーザノードに到達可能な場合に限り、「再生」アクションを行うことが可能になる。一般に、適切な場合、制御、コントローラ、プロテクタ、およびＣｏｎｔｅｎｔＫｅｙオブジェクトは、パッケージングされたコンテンツに埋め込まれる。その結果、ＰＣおよび装置は、それらを別に入手する必要がない。
【０１１７】
一実施形態において、装置またはＰＣがコンテンツの再生を望む場合、図９に関連して上述したようなプロセスに従う。すなわち、ＤＲＭエンジンは、コンテンツのコンテンツＩＤのためのプロテクタオブジェクト、次にそのプロテクタによって参照されるＣｏｎｔｅｎｔＫｅｙオブジェクト、次にそのＣｏｎｔｅｎｔＫｅｙオブジェクトを参照するコントローラオブジェクト、最後にそのコントローラによって参照される制御オブジェクトを見つける。ＤＲＭエンジンは、制御オブジェクトの制御プログラムを実行し、それはユーザノードが到達可能か否かを照合する。装置またはＰＣノードが、そのノードとユーザノードとの間に経路が存在することを検証するために必要なリンクオブジェクトを有する場合、条件は満たされ、制御プログラムは、ＣｏｎｔｅｎｔＫｅｙオブジェクトにおいて表される鍵の使用を可能にする。装置またはＰＣの媒体レンダリングエンジンは、コンテンツの解読および再生ができる。
【０１１８】
１．１２．実施例：一時的ログイン
図１７は、本明細書に記載するＤＲＭシステムおよび方法の可能な用途の別の実施例である。この実施例は、前述のセクションにおける実施例と同様であるが、ここで異なる点は、ユーザがすでに別のＰＣへの一時的ログインを有しない限り、ＰＣノードオブジェクトとユーザノードオブジェクトとの間のリンクオブジェクトの生成を管理するポリシーが、１２時間だけの一時的ログインを可能にするということである。この機能によって、ユーザ１７００は、自分のコンテンツ１７０２を友人のＰＣ１７０４に持って行き、ある期間にわたってそのＰＣ１７０４にログインし、友人のＰＣ１７０４上でコンテンツ１７０２を再生することができる。
【０１１９】
このことを達成するために、リンクオブジェクト１７１０は、限定された有効期間によって作成される。一実施形態において、このことは、以下のように行うことができる。
【０１２０】
説明の容易さのために、ＤＲＭで保護されたコンテンツ１７０２を再生するために必要な、ＤＲＭ対応の消費するソフトウェア１７１４は、友人のＰＣ１７０４上にすでに存在すると仮定されたい。コンテンツ１７０２およびライセンス１７０８を含むファイルは、友人のＰＣ１７０４へ転送される。ユーザがコンテンツ１７０２の再生を試みる場合、ソフトウェア１７１４は、コンテンツを所有するユーザのノードにローカルなＰＣノードを連結する有効なリンクオブジェクトがないことを認識する。ソフトウェア１７１４は、ユーザの証明１７１２についてユーザを促し（このことは、システムのポリシーの下で可能にされるユーザ名／パスワード、携帯電話認証プロトコル、スマートカード、または任意の認証システムを介して提供できる）、バックエンドシステム１７０６と通信する。バックエンドシステム１７０６は、リンクがリクエストされるユーザノードオブジェクトおよびＰＣノードオブジェクトの属性を照合し、まだ有効で作動中の一時的ログインリンクオブジェクトがないことを照合する。これらの条件が満たされる場合、バックエンドサービス１７０６は、友人のＰＣノードオブジェクトとユーザのノードとをリンクするリンクオブジェクト１７１０を作成し、有効期間をリクエストされたログイン所要時間に限定する（例えば、この実施例におけるポリシーに従うと１２時間未満）。リンクオブジェクト１７１０を有することによって、友人のＰＣ１７０４は、リンク１７１０が失効するまで、ユーザのコンテンツ１７０２を再生できる。
【０１２１】
１．１３．実施例：企業コンテンツ管理
図１８は、企業文書（例えば、電子メール、ワードプロセッシング文書、プレゼンテーションスライド、インスタントメッセージングテキストなど）を管理する例示的なシステム１８００の高水準アーキテクチャを示す。図１８に示す実施例において、文書編集アプリケーション（例えばワードプロセッサ）１８０２、電子メールクライアント１８０４、およびディレクトリサーバ（例えばアクティブディレクトリサーバ）１８０６は、デジタル著作権管理（ＤＲＭ）プラグイン１８０８、ネットワークサービス編成レイヤ１８１０、登録サービス１８１２、およびポリシーサービス１８１６を利用することによって、ポリシーによる文書、電子メールメッセージなどの管理を容易にする。好ましい実施形態において、ＤＲＭプラグイン１８０８、ネットワークサービス編成レイヤ１８１０、ポリシーサービス１８１６、および登録サービス１８１２は、本明細書の他の場所および５５１出願に記載されるＤＲＭエンジンおよびサービス編成技術を使用して実現される。例えば、一実施形態において、ＤＲＭプラグイン１８０８は、上述したＤＲＭエンジンの実施形態を含んでもよい。図１８に示す実施形態において、既存のアプリケーション（例えばワードプロセッサ１８０２および電子メールクライアント１８０４）は、アプリケーションが呼び出せるプラグインを介してＤＲＭエンジンに統合されるが、他の実施形態において、ＤＲＭエンジンは、アプリケーション自体の不可欠な部分として含まれる場合があることが理解される。図１８に示す例示的なシステムは、単一の企業の中で実現してもよく、または複数の企業にまたがってもよいことも理解される。
【０１２２】
図１８に示す図解において、ディレクトリサーバ１８０６は、例えば、ユーザプロファイルおよびグループ定義を含んでもよい。例えば、企業のシステムアドミニストレータが「特別プロジェクトチーム」と呼ぶグループを設定することによって、企業の特別プロジェクトチームの構成員を識別してもよい。
【０１２３】
一実施形態において、ディレクトリサーバ１８０６は、５５１出願に記載されるようなウェブサービスを実行するアクティブディレクトリサーバを含んでもよい（さらに、例えばＷｉｎｄｏｗｓ（登録商標）プラットホーム上の規格ＩＩＳベース技術を用いて実現されてもよい）。ディレクトリサーバは、アクセスされるコンテンツに基づいて、特別プロジェクトチームの人々に、ノード、リンクおよびライセンスを発行する。グループにおいて帰属関係が変化する場合、新しいトークンを発行してもよい。著作権の取り消しのために、ディレクトリサーバ１８０６は、５５１出願に記載されるような技術（本明細書において「ＮＥＭＯ」技術と呼ぶことがある）に基づいて、セキュリティメタデータサービスを実行することができる。一部の実施形態において、クライアントは、ＤＲＭライセンスを使用するために、現在までの時間値または時間概念（企業が規定するように選択するいかなるフレッシュネス値にも基づく（例えば１週、１日、１時間、５分ごとなど））を有することを必要とされる場合がある。例えば、セキュリティメタデータサービスが提供するトークンは、信頼された時間値および認証可能な時間値を含んでもよい。一部の実施形態において、クライアントは、セキュリティメタデータサービス対話処理におけるユーザノードＩＤを識別することができる。ユーザが依然として所与の帰属関係を有する場合、決定するライセンス制御の状況において、セキュリティメタデータを直接に評価することができる。セキュリティメタデータは、例えば特別プロジェクトチームの構成員であるという関係が有効であるか否かを決定できるエージェントを返すこともできる。従って、一部の実施形態において、明確に定義されたウェブサービスを多少追加するだけで、企業の既存の認可および認証インフラストラクチャ（例えば企業のアクティブディレクトリサーバ）に影響を及ぼすことが可能である。
【０１２４】
図１９は、図１８に示すようなシステムを使用することによって、文書に対するアクセスまたは文書の他の使用を管理する、方法の実施例を示す図である。この実施例において、特定の従業員（ジョン）は、高度に機密の戦略的プロジェクトに頻繁に取り組み、自分のアプリケーションのためにＤＲＭプラグイン１９０８（例えば、ワードプロセッシングプログラム１９０２、電子メールプログラム１９０４、カレンダープログラム、そのようなプログラムを統合するプログラムまたはプログラムセットなど）をすでにインストールしている場合がある。ジョンは、自分の文書を作成中のある時点において、自分のアプリケーションのツールバーに追加された「許可」プルダウンメニュー項目にアクセスする（アクション１９１３）。ここで現れる許可ダイアログボックスは、システム上に設定された個人およびグループのディレクトリについて、ジョンの会社のアクティブディレクトリサーバ１９０６と接触するものである。ジョンは、リストから「特別プロジェクトチーム」を選択し、チームの全員に、文書の閲覧、編集、印刷の許可を与えることを決める。
ＤＲＭプラグイン１９０８は、５５１出願に記載するＮＥＭＯサービス編成技術を使用して、ＮＥＭＯ対応ポリシーサービス拡張１９１６をアクティブディレクトリ１９０６に接触させ、特別プロジェクトチーム用のファイルを保護するために使用するポリシーのコピーをリクエストする（アクション１９１４）。ジョンが文書を保存すると、ＤＲＭプラグインは、ファイル１９１２を自動的に暗号化し、「特別プロジェクトチーム」１９１０として知られるグループに対してターゲティングおよび結合されたライセンスオブジェクトを作成する。ライセンス１９１０は、装置ノードから特別プロジェクトチームグループノードへのリンクの有効チェーンを生成することができる任意の装置が、ファイル１９１２にアクセス（例えば、編集、印刷、閲覧など）することを可能にする。
【０１２５】
ジョンは、文書１９１２にアクセスできる。なぜなら、ジョンの装置は、ジョンのユーザノードへのリンクを有し、ジョンのユーザノードから「特別プロジェクトチーム」グループノードへのリンクも有するからである。同様に、ジョンがこの文書を他者に転送する場合、他者が「特別プロジェクトチーム」グループノードへのリンクの有効チェーンを生成できる場合、他者は文書にアクセスすることのみができる（例えば、装置が特別プロジェクトチームノードに到達可能であることを要求することによって）。
【０１２６】
ジョンは、自分のコンピュータ上に（すでに保護された）ファイルを保存し、後でファイルを電子メールメッセージに添付してもよい（アクション１９２０）。例えば、ジョンは、自分の上司（ジョージ）に対する古い電子メールを開き、通常行うようにファイルを添付し、メッセージを送信してもよい。図２０に示すように、ジョージは、自分のコンピュータ２０１４上にインストールされるＤＲＭプラグイン２０００をも有する。ジョージが自分のコンピュータ２０１４にログインする際に、プラグイン２０００は、ジョージが追加されたグループのすべてを好機をねらって照合し（アクション２００６）、失効した任意のリンクについて、新しいリフレッシュされたリンクをダウンロードする（アクション２０１２）。ジョージが最後のログイン以来「特別プロジェクトチーム」に追加されている場合、ジョージのプラグイン２０００は、ジョージのユーザノードを「特別プロジェクトチーム」グループノードにリンクする、リンクオブジェクト２００８をダウンロードし得る。このリンク２００８は、ユーザノード「ジョージ」が、グループノード「特別プロジェクトチーム」の構成員であることを示す。この実施例において、リンクオブジェクト２００８は、それ以降は有効でなくなる失効日（例えば３日）を有すると仮定されたい。
【０１２７】
図２１に示すように、ジョージが文書を開こうとすると（アクション２１３０、２１３２）、ＤＲＭプラグイン２１０８は、埋め込まれた（または添付された）ライセンスを照合し、「特別プロジェクトチーム」ノードが到達可能でなければならないことを知る。ジョージのプラグイン２１０８は、ジョージのコンピュータの装置ノードからユーザノード「ジョージ」へのリンク２１２０、およびユーザノード「ジョージ」からグループノード「特別プロジェクトチーム」への２１２２の、チェーンを構成（および検証）する（アクション２１３４）。装置は、リンク２１２０および２１２２の有効チェーンを有するので、ジョージのプラグイン２１０８は、ファイルへのアクセスを許可する。
【０１２８】
本明細書の他の場所に記載するように、一部の実施形態において、リンクは、安全な鍵のチェーンを運ぶこともできる。従って、一部の実施形態において、特別プロジェクトチームノードへのリンクのチェーンを生成することによって、プラグインは、コンテンツへのアクセスが許可されることを証明できるのみならず、コンテンツの解読を可能にする鍵のチェーンを解読することもできる。
【０１２９】
例えば、別の従業員（「キャロル」）が、偶発的にジョンの電子メールを受信し、文書を開くことを試みる場合、キャロルのＤＲＭプラグインは、ファイルにバンドルされるライセンスを検索し、ライセンスの条件を評価する。キャロルのＰＣは、キャロルのユーザノード「キャロル」へのリンクを有するが、キャロルはチームの構成員ではないので、「キャロル」から「特別プロジェクトチーム」グループノードへのリンクがない。「特別プロジェクトチーム」が到達可能でないので、キャロルはファイルへのアクセスを許可されない。
【０１３０】
キャロルが最終的に「特別プロジェクトチーム」のグループに追加される場合、次回にキャロルのＤＲＭプラグインがキャロルの帰属関係をリフレッシュする際に、ＤＲＭプラグインは、この新しいグループを検出し、キャロルのユーザノードを特別プロジェクトチームノードにリンクするリンクオブジェクトをダウンロードする。キャロルのプラグインは、現在、キャロルの装置ノードから、キャロルのユーザノードへ、さらに特別プロジェクトチームノードへの、チェーンを構成するために必要なすべてのリンクを有する。特別プロジェクトチームノードは、現在「到達可能」であり、キャロルは、特別プロジェクトチームを対象にした任意の文書または電子メール（キャロルがチームに加わる以前に作成されたものさえ）を開くことができる。
【０１３１】
１ヵ月後に、ジョージは、新しい任務に異動し、アクティブディレクトリにおける特別プロジェクトチームから削除されると仮定されたい。次回にジョージがログインする際に、ジョージのプラグインは、ジョージのユーザノード「ジョージ」を「特別プロジェクトチーム」に関連づける新しいリフレッシュされたリンクオブジェクトを受信しない。数週後に、ジョージがジョンのファイルを開くことを試みる際に、ジョージのプラグインは、特別プロジェクトチームへのリンクのチェーンの構成を試みる。ジョージのＰＣは、依然としてユーザノード「ジョージ」へのリンクを有する（ジョージのＰＣは依然としてジョージに帰属する）が、「ジョージ」から「特別プロジェクトチーム」へのリンクは失効している。「特別プロジェクトチーム」が到達可能でないので、ジョージはファイルへのアクセスを許可されない。
【０１３２】
会社は、記録されるすべての機密情報へのアクセスを必要とするポリシーを有すると仮定されたい。そのような一実施形態において、特別プロジェクトチームのためのポリシーは、このグループのために作成されるすべてのライセンスもまた、例えばセントラルレポシトリに対して使用情報の収集およびレポーティングを要求する必要がある、ということを規定する。従って、この実施例において、プラグインは、ライセンスにおける制御プログラムを評価（例えば実行）する際に、アクセスを記録してそのように行うという必要条件を実行する。例えば、結果の活動は、本明細書に記載するようなローカルな保護された状態データベースに記録することができ、ネットワーク接続が再確立されると、関連コンテンツは、上述のサービスを経て報告することができる。
【０１３３】
図２２は、企業内で電子コンテンツを管理するための別の例示的システム２２００を示す。図２２に示す実施例において、ＬＤＡＰサーバ２２０６は、ユーザプロファイル、グループ定義、および任務割当てを管理するために使用され、「特別プロジェクトチーム」と呼ばれるグループ定義、および「弁護士」の任務定義を含む。
【０１３４】
ジョンは、弁護士であり、添付を有する電子メールを特別プロジェクトチームの他の構成員に送信することを望む、と仮定されたい。ジョンが自分のアプリケーションのためにＤＲＭプラグイン２２０８をインストールする際に、プラグインはジョンの電子メールツールバーにも項目をインストールする。ジョンは、電子メールメッセージを作成中のある時点において、自分のツールバーに追加されたプルダウンメニューから「許可の設定」にアクセスする。ＤＲＭプラグイン２２０８は、ポリシーサービス２２１６に接触し、選択元となる企業メッセージ送信ポリシーのリストを表示する。ジョンは、「特別プロジェクトＤＲＭテンプレート」を選択し、ＤＲＭプラグイン２２０８は、ＮＥＭＯプロトコルを使用することによって、受信するポリシーオブジェクトの確実性、完全性、および機密性を、リクエストおよび保証する。ポリシーは、このテンプレートを使用するライセンスを作成する方法（ライセンスを対象にして結合する方法を含む）を記述する。
【０１３５】
ジョンが「送信」を選択すると、ＤＲＭプラグイン２２０８は、メッセージおよび添付を暗号化し、関連するライセンスを生成する。電子メールまたは添付にアクセスするために、ライセンスにとっての必要条件として、特別プロジェクトチームグループノードまたは「弁護士」グループノードが到達可能でなければならない。
【０１３６】
ライセンスは、暗号化されたメッセージペイロードおよび暗号化された添付にバンドルされる。その後、メッセージは、標準電子メール機能を使用して、受信者のリストに送信される。ライセンスの規則および暗号化は、電子メールのアドレス方式には依存しないので、正しくない電子メール受信者が誤って含まれ得るという事実は、電子メールまたは添付のコンテンツをリスクにさらさない。
【０１３７】
そのような予想外の受信者は、ユーザノードを特別プロジェクトチームにリンクする有効なリンクオブジェクトを有しないので、仮に受信者がコンテンツへのアクセスを試みたとしても許可されない。更にまた、そのような受信者の装置は、必要なリンクのチェーン（およびそれらが含む鍵）を有しないので、装置はコンテンツを解読する機能さえ有しない。
【０１３８】
しかしながら、予想外の受信者が、次に、標準電子メール機能を使用して、同一の変更されていない電子メールを特別プロジェクトチームの構成員に転送する場合、その構成員は、自分のユーザノードを「特別プロジェクトチーム」グループノードにリンクするリンクオブジェクトを有するので、電子メールのコンテンツにアクセスできる。
【０１３９】
会社の別の弁護士（「ビル」）もまた、自分を「特別プロジェクトチーム」グループノードに関連づけるリンクオブジェクトを受信したと仮定されたい。ビルも、ファイルを閲覧することができる。ビルが、弁護士補助員（「トレント」）（弁護士でもなく特別プロジェクトチームとも関連していない）にそのメッセージを転送する場合、トレントは、自分を「特別プロジェクトチーム」グループノードに結びつけるリンクオブジェクトを有しないので、トレントは文書にアクセスできない。
【０１４０】
その後、トレントが、ＬＤＡＰディレクトリ２２０６における特別プロジェクトチームグループに追加された場合、トレントは、必要なリンクオブジェクトを与えられるので、すでに転送された電子メールにアクセスできるようになる。
【０１４１】
前述のように、この会社が、すべてのライセンスにレポーティング必要条件が含まれることを示すポリシーを有する場合、一実施形態において、これらのライセンスのうちの１つの中の制御プログラムが実行される（例えば誰かがファイルへのアクセスを試みる）ときは必ず、レポーティングイベントをトリガすることができる。レポーティングステップはさらに、アクセスが認可または拒絶されたか否かに関するインジケータを含むことができる。このことは、インプリメンテーションの選択の問題である。そのようなインジケータを使用する場合、特定の文書にアクセスを試みる回数、およびそれぞれに関する状態または他の情報（例えば成功、失敗など）について、ログを維持することができる。
【０１４２】
さらに別の実施例として、特別プロジェクトチームの構成員の１人（「スティーブン」）が、特別プロジェクトの仕事を遂行するために、別の会社に出張すると仮定されたい。
他の会社に向かって出発する前に、スティーブンの電子メールクライアントは、すべての電子メールのローカルコピーを受信箱にダウンロードする。これらの電子メールのうちの１通に添付される保護されたレポートもまた、埋め込まれた（または添付された）ライセンスを含む。このライセンスオブジェクトは、コンテンツにアクセスするための規則、ならびに暗号化されたコンテンツ鍵を含む。コンテンツにアクセスするために必要な唯一の「失われたリンク」は、「特別プロジェクトチーム」グループノードに到達するために必要なリンクオブジェクトである。
【０１４３】
この実施例において、会社のポリシーは、リンクオブジェクトが３日間にわたって有効であることを可能にするので、スティーブンのユーザノードを特別プロジェクトチームノードにリンクするリンクオブジェクトは、スティーブンが出張中に接続しない間も有効に保たれる。スティーブンが、オフラインの間にファイルへのアクセスを試みる場合、特別プロジェクトチームグループノードは依然として到達可能であるので、スティーブンはファイルへのアクセスを許可される。
【０１４４】
しかしながら、スティーブンが３日よりも長くオフラインのままである場合、スティーブンを特別プロジェクトチームにリンクするリンクオブジェクトは、失効する。特別プロジェクトチームグループノードは、もはや到達可能ではないので、スティーブンはファイルへのアクセスを許可されない。
【０１４５】
スティーブンが、最終的に（例えばＶＰＮを介して）会社のシステムに接続できる場所に出張する場合、スティーブンのＤＲＭプラグインは、スティーブンが帰属するグループの各々について、リンクオブジェクトのリフレッシュされたコピーをリクエストする。スティーブンは、依然として「特別プロジェクトチーム」グループの一員であるので、自分のユーザノードから特別プロジェクトチームグループノードへの新しいリンクオブジェクトを受信する。このリンクは、失効してもはや有効ではなくなった「古い」リンクと入れ替わる。
【０１４６】
この新しいリフレッシュされたリンクを使用することにより、「特別プロジェクトチーム」ノードは現在到達可能であるので、スティーブンは、保護されたレポートに再びアクセスすることができる。新しいリンクオブジェクトは、３日間にわたって有効であり、その後はやはり失効する。
【０１４７】
さらに別の実施例として、特別プロジェクトチームの構成員（「サリー」）は、インスタントメッセンジャを介して、別のチーム構成員と通信し、通信のコピーを保存し、チームの別の構成員に（例えば、電子メール添付、ディスケット、ドングル等を介して）コピーを与えることを望む、と仮定されたい。この実施例において、インスタントメッセンジャクライアント（および潜在的に会社が従業員に提供する他の任意のメッセージングまたは通信の成果物）は、上述の実施例のように、ＤＲＭプラグインにリンクされ、ＤＲＭプラグインは、ライセンスを対象にして結合する方法を規定するポリシー「特別プロジェクトＤＲＭテンプレート」にアクセスする。サリーが、自分のインスタントメッセージングの会話の保存（例えば「別名で保存する」を選択することによって）を試みる際に、プラグインは、暗号化キーを（例えばランダムに）選択し、会話のテキストをパッケージング（暗号化）する。ＤＲＭプラグインは、会社のポリシーごとに、特別プロジェクトチームグループノードを対象にして結合するライセンスオブジェクトを生成する。
【０１４８】
保護されたＩＭトランスクリプトを含むファイルは、トランスクリプトコンテンツにアクセスするためのライセンスにバンドルされる。上述の実施例のように、ライセンスは、コンテンツへのアクセスを管理する規則、ならびに  コンテンツ鍵の暗号化されたコピーを含む。サリーは、標準的な「ドラッグアンドドロップ」手順を使用して、このバンドルされたファイルを、電子メール、ＵＳＢドングル、ディスケットなどに転送し、それを他の誰かに送信することができる。受信者の装置が、特別プロジェクトグループノードへの有効なリンクを生成できると仮定するならば、コンテンツに対するアクセスは、許可され、可能である。
【０１４９】
サリーが、ジョン（これも特別プロジェクトチームの構成員）にファイルを与える、と仮定されたい。ジョンが、自分を特別プロジェクトチームの構成員として識別する最近リフレッシュされたリンクオブジェクトを有する場合、ジョンはファイルにアクセスできる。会社のポリシーごとに、このリンクオブジェクトは、３日で失効になる失効日を含む。従って、たとえジョンが接続しないままであっても、そのリンクが有効である限り、ジョンは依然としてアクセスを有する。
【０１５０】
後のいずれかの時点において、ジョンが、別の職務のために特別プロジェクトチームから離れ、自分のバッグの中にサリーからのＵＳＢドングルを発見し、自分のデスクトップコンピュータを使用してファイルを開くことを試みる場合、ジョンのユーザノードを特別プロジェクトチームに関連づけるリンクオブジェクトは、失効している。ジョンは、もはやチームの一員でないので、ジョンの装置上のＤＲＭプラグインは、新しいリフレッシュされたリンクを獲得することがもはやできない。「特別プロジェクトチーム」グループノードは、もはやジョンの装置によって到達可能ではないので、アクセスは許可されない。
【０１５１】
ジョンは、仕事が変わったとき以来、自分のラップトップがネットワークに接続していないと考え、その装置を用いてファイルを開くことを試みる。最大割り当て時間が過ぎてしまっているので、そのリンクももはや有効ではない。一部の実施形態において、ジョンがファイルへのアクセスを試みるたびに、レポートが生成され、セントラルレポシトリに送信するように待ち行列に入れられることができる。
【０１５２】
セントラルレポシトリは、ファイルのアクセスに失敗した試みについて、複数のレポートを受信し、電子メールを介してマネージャにフラグを立てる。マネージャは、機密資料へのアクセスがもはや許可されないことをジョンに気づかせ、すべてのファイルを抹消することを求める（アクセスが認可されなかったことをシステムが示す場合でも）。
【０１５３】
さらに別の実施例として、政府機関または社外監査役が、特別プロジェクトチームの機密情報の取り扱いを調査または監査することを望む、と仮定されたい。調査を支援するために、会社は、特別プロジェクトに関連する機密情報へのアクセスに関する追跡記録レコードを示すことを望む。
【０１５４】
このために、会社はまず、特別プロジェクトに関連する任意のメッセージについて、すべてのクリアテキストメッセージアーカイブをスキャンする。安心したことに、会社のポリシーに則って、適切なＤＲＭ保護なしに特別プロジェクトについて論ずるメッセージを送信した従業員はいないことがわかる（例えばシステムの外部で）。
【０１５５】
会社は、ＤＲＭアクセス記録を使用することによって、保護された情報へのアクセスがいつ誰に与えられたかを詳述する追跡記録を生成する。
【０１５６】
社内手順書につき、特別プロジェクトチームグループが確立された際に、特に指定しない限り主任コンプライアンス役員（ＣＣＯ）も含んだ。主任コンプライアンス役員のためのリンクオブジェクトが作成され、記録サーバに保存された。それにより、主任コンプライアンス役員は、将来必要に応じてすべてのメッセージのコンテンツを照合することができる。
【０１５７】
この実施例において、特別プロジェクトチームのために規定されるポリシーは、チームによって生成されるすべてのライセンスが、ファイルに対する任意の試行済みアクセス（日付、時間、ＵｓｅｒＮｏｄｅ、アクセスが認可されたか否かを含む）を報告する必要条件を含まなければならないということを示した。これらのレポートは、セントラルレポシトリ上のアクセスログに保存された。
【０１５８】
ＣＣＯは、疑われる任意の漏洩または他の反則が生じた日付に先立つ、特別プロジェクトチームに関連するすべてのアクセスについて、アクセスログを照合する。ＣＣＯはまた、その日付を含む以前のすべてのメッセージトラフィックおよびシステムファイルについて、電子メール、ＩＭ、およびネットワークバックアップアーカイブを検索する。各ファイルは、（コンテンツ鍵とともに）添付されたライセンスを有し、ＣＣＯは、ライセンスの必要条件を満たすために必要なリンクオブジェクトを有するので、ＣＣＯは、問題の時間の前にアクセスされたすべてのメッセージのコンテンツへのアクセスを許可される。
【０１５９】
アクセスログおよび解読されたメッセージコンテンツは、調査の一環として、機関／監査役に対して完全に利用可能にされる。
【０１６０】
一部の実施形態において、特別プロジェクトチームのためのポリシーは、特別プロジェクトに関連するすべてのライセンスについて失効日を設定するという必要条件をも含み得る。例えば、会社がこの性質の記録を１年の期間にわたって保管することを法令によってのみ求められる場合、ポリシーにおいて、ライセンスが発行日の１年後に失効することを示し得る。その場合、会社は、法的に必要とされるのと同じ期間にわたって記録を保管するだけでよい。ＣＣＯでさえ、その時刻以降はアクセスを有し得ない。
【０１６１】
上述の説明において、「ターゲティング」および「結合」が時折言及された。好ましい実施形態において、ターゲティングおよび結合は、２つの異なる密接に関連したプロセスを表す。好ましい実施形態において、「結合」は、主に暗号プロセスであり、コンテンツを暗号化するために使用された鍵を保護することに関する。ライセンスが、ノード（例えば「特別プロジェクトチーム」ノード）に「結合される」場合、例えば、コンテンツ鍵がそのノードに関連する公開鍵によって暗号化されることを意味し得る。従って、ノードの秘密鍵にアクセスする装置のみが、コンテンツを解読するために必要な鍵を有する（さらに、好ましい実施形態において、ノードの秘密鍵に対するアクセスを獲得する唯一の方法は、そのノードへのリンクのチェーンを解読することである）。しかしながら、単に正しい秘密鍵を有するということは、コンテンツを解読する機能を装置が有することを示すだけである（そうすることが許可される場合）。
【０１６２】
好ましい実施形態において、装置がコンテンツへのアクセスを許可されるか否かは、ライセンス内の制御プログラムによって決定され、具体的には「ターゲティング」の方法によって決定される。「ターゲティング」は、コンテンツの使用を実行するにあたって、特定の単一ノード（または複数ノード）が「到達可能である」ように指定するために、制御プログラムに必要条件を追加することを指す。上記の実施例において、制御プログラムは、消費する装置によって特定ノード「特別プロジェクトチーム」が到達可能であることを一般に指定する。
【０１６３】
場合によっては、複数のノードを対象にするライセンスを有することは、望ましいことがある（例えば、新しい最高機密の製品の構成要素に入札する複数の供給会社と協働する会社（「Ｃｏｍｐａｎｙ」）における新製品開発チーム）。プロジェクトの初期段階において、供給会社Ａおよび供給会社Ｂ（競合他社）は、いずれも「ＳｅｃｒｅｔＰｒｏｊｅｃｔＸ」へのリンクを有する、と仮定されたい。供給会社Ａは、自らのアイデアをＳｅｃｒｅｔＰｒｏｊｅｃｔＸのすべての構成員と共有することを望むが、そのアイデアを供給会社Ｂに不注意に漏洩することは望まない。供給会社Ａは、以下のように、これらのライセンスを対象にすることができる。すなわち、「ＳｅｃｒｅｔＰｒｏｊｅｃｔＸは到達可能である」なおかつ「供給会社Ａは到達可能である」または「Ｃｏｍｐａｎｙは到達可能である」。Ｃｏｍｐａｎｙが、不注意にこの情報を、秘密プロジェクトＸにおける全員（供給会社Ｂを含む）と共有する場合、供給会社Ｂの社員はそれを見ることを許可されず、任意の非開示リスクはＣｏｍｐａｎｙに限定され、供給会社Ａがトレードシークレットを失う可能性が排除される。
【０１６４】
１．１４．実施例：健康管理記録
図２３は、本明細書に記載するシステムおよび方法を健康管理記録の管理に応用できる方法を説明する。医療記録は、異なるレベルの機密性を有し、システムにおける異なるエンティティ（例えば患者、医師、保険会社など）に対して異なるアクセス権を認可することは望ましい、と仮定されたい。例えば、一部の記録が患者のみによって閲覧されることを許可すること、一部の記録が患者の医師のみによって閲覧されることを許可すること、一部の記録が患者によって閲覧可能であるが、患者の医師のみによって編集可能であることを許可すること、一部の記録がすべての医師によって閲覧可能であることを許可すること、一部の記録がすべての保険会社によって閲覧されることを許可すること、一部の記録が患者の保険会社のみによって閲覧可能であることを許可すること、などが望ましい場合がある。
【０１６５】
図２３に示すように、この健康管理エコシステム２３００は、本明細書の他の場所に記載するようなノードおよびリンクなどのＤＲＭオブジェクトを使用して、モデル化することができる。例えば、患者２３０２、患者の医師２３０４、患者の保険会社２３０６、患者の装置２３０８および２３１０、患者の医師の特定の一人２３１２、医師のコンピューティング装置２３１４および２３１６、すべての医師のグループ２３１８、一定の専門医のグループ２３２０、医療機関２３２２、保険会社２３２４、保険会社によって使用されるコンピューティング装置２３２６、すべての保険会社のグループ２３２８、などにノードを割り当てることができる。
【０１６６】
患者の医師は、患者に関する医療記録を作成するために自分のＰＣを使用する、と仮定されたい。例えば、医療記録は、ノート、診断、処方指示、患者用の指示などのための多くのフィールドを有する文書テンプレートを含んでもよい。テンプレートはまた、医師が文書および／またはその個々のフィールドを管理するためのセキュリティポリシーを選択すること可能にしてもよい。例えば、医師のアプリケーションは、標準的なセキュリティポリシー選択の集合を示し、医師の選択を入手すると、それらの選択に基づいてライセンスを自動的に生成し、医療記録の保護された（例えば暗号化された）コンテンツに関連づけてもよい。
【０１６７】
この実施例では、ライセンスは、患者、患者を治療するすべての健康管理提供者、および患者に保障範囲を提供するすべての保険会社に対して、閲覧アクセスを認可する、と仮定されたい。説明のために、ライセンスは、医療機関ｘにおける心臓専門医のみに編集権を認可する、と更に仮定されたい。
【０１６８】
パッケージングアプリケーションは、医師のポリシー指定入力を受け入れて（それは標準的なテンプレート上でパソコンのマウスをクリックすることを単に含んでもよい）、下記に示すような制御プログラムを含むライセンスを生成する。
【表５】
2009512096.tif 000007
【０１６９】
医療記録およびそれに関連するライセンスは、医療記録のセントラルデータベース（特定の医療財団などによって運営されるデータベース）に格納されてもよい。その後、患者Ｙが、別の健康管理提供者を訪問し、その健康管理提供者を、（例えば認可用紙に署名することによって）自分の承認済み健康管理提供者の１つとして認可する場合、その健康管理提供者は、患者Ｙ認可の健康管理提供者ノードへのリンクを入手し、その健康管理提供者はコンピュータシステムに記憶される。その健康管理提供者が、医師Ｘによって作成される医療記録を入手しようとする場合、その医療記録への閲覧アクセスを獲得できる。なぜなら、患者Ｙが承認した健康管理提供者ノードは、新しい健康管理提供者のコンピュータシステムから到達可能だからである。これに反して、承認されていない健康管理提供者が、（暗号化された）医療記録のコピーを入手しようとする場合、アクセスはできない。なぜなら、必要なノード（すなわち、患者Ｙのノード、患者Ｙの承認した全ての健康管理提供者のノード、および患者Ｙの承認したすべて保険会社のノード）のいずれも、コンピューティングシステムから到達可能ではないからである。
【０１７０】
しかしながら、上記の例示的な制御プログラムは、例えば、緊急時において健康管理提供者が保護された医療記録にアクセスする必要がある場合に呼び出せる優先機能を含むが、制御プログラムの条件を満たすことはできないことに留意されたい（なぜなら、例えば、医療記録への緊急時アクセスを試みる健康管理提供者は、あらかじめ患者Ｙの健康管理提供者として登録されていないからである）。しかしながら、緊急時アクセス例外の呼出しによって、呼出しおよび／または他の状況に関する情報が自動的に記録され、この実施例において、（例えば、患者の好ましい健康管理提供者、すなわち患者によって明示的に認可されるエンティティ、および／または患者自身に対して）通知が送信されることにも留意されたい。濫用の記録が存在し得るので、そのような義務を緊急時例外に関連づけることによって、例外の濫用を阻止してもよい。
【０１７１】
この例示的プログラムは、本明細書に記載されるシステムおよび方法の一定の実施形態の説明を容易にするために提供するものであることが理解される。例えば、システムが緊急時例外のためのサポートを含むか否かは、システム設計者の必要条件および要求に一般に依存する。従って、例えば、一部の実施形態は、緊急時例外をサポートしなくてもよく、他の実施形態は、緊急時例外をサポートしてもよい。しかし、そのような例外を呼び出すことができるエンティティのクラスは、「すべての医師」のクラスに限定される（例えば、ＥｍｅｒｇｅｎｃｙＥｘｃｅｐｔｉｏｎフラグを「真実の」に設定し、なおかつＡｌｌＤｏｃｔｏｒｓノードが到達可能であることを要求することによって）。他の実施形態は、やはり緊急時例外をサポートしてもよいが、強制的な義務をそれに関連づけない（なぜなら、好ましい実施形態において、義務に従えないことは、コンテンツをアクセス不可能にし得るからである）。これに代わって、非技術的、法的、または組織的な施行手段に依存する（例えば、例外を呼び出す能力を健康管理提供者が濫用しないと信頼することによって、および／または濫用を防止するために事業証明書および法律制度に依存することによって）。
【０１７２】
上述の実施例に対するさらに別のバリエーションとしては、医師または具体的に指名された医師が、実際に医療記録にアクセスするという、より強力な証明を要求することであり、記録にアクセスするために医師が使用するコンピュータに他の誰かが座るのとは対照的である（従って、コンピュータは、到達可能性分析を満たすのに必要なリンクを潜在的に含む）。そのようなより強力な形態の認証は、任意の適切な態様において実施することができる。このことは、例えば、パスワード、ドングル、バイオメトリック認証メカニズムなどを使用して、医療記録へのアクセスに使用される医師のコンピュータおよび／またはソフトウェアを保護することによって、アプリケーションまたはシステムのレベルにおいて、完全にまたは部分的に実施することができる。それに代わって、またはそれに加えて、一定の医療記録に関連する制御プログラムは、それ自身が義務または条件を含むことができる（例えば、ドングルの存在を照合するなどの、より強力な識別を要求したり、ホストがパスワードを獲得することを要求したりすることなどによって）。
【０１７３】
１．１５．実施例：購読
図２４は、本明細書に示すシステムおよび方法を電子購読サービスの状況に使用できる方法を示す。例えば、ユーザ（アリス）が、インターネットサービスプロバイダ（ＸＹＺ  ＩＳＰ）から、ジャズの音楽への購読を入手することを望むとする。インターネットサービスプロバイダは、無料のトライアル購読を含む様々な異なる購読オプションを提供してもよいが、失効する前に購読コンテンツを５回再生するために利用することしかできない（例えば、１つの曲を５回再生すること、５つの異なる曲を１回ずつ再生すること等によって）。トライアル購読はまた、わずかにグレードを下げた形態（例えば低減した忠実度または解像度）においてコンテンツを利用可能にするのみである。アリスは、自分のパーソナルコンピュータを使用して、サービスプロバイダのインターネットウェブサイトにアクセスし、トライアル購読を選択する。サービスプロバイダは、リンクオブジェクト２４００およびエージェント２４０１を発行し、それらをアリスのパーソナルコンピュータ２４０６に送信する。エージェント２４０１は、アリスの安全な状態データベースの状態を初期化するように操作可能であり、このデータベースは、アリスがトライアルコンテンツを使用した回数の記録をとるために使用されるリンク２４００は、アリスのＩＳＰアカウントノード（Ａｌｉｃｅ＠ＸＹＺ ＩＳＰ）２４０２から購読ノード２４０４へのリンクであり、制御プログラムを含む。制御プログラムは、アリスがコンテンツの再生をリクエストする際に、エージェント２４０１によって設定された状態変数の現在の値を照合することによって、更なる再生が可能か否かを調べる。
【０１７４】
アリスが、コンテンツを自分のＰＣにダウンロードし、コンテンツの再生を試みる際に、アリスのＰＣ上のＤＲＭエンジンは、コンテンツに関連するライセンスを評価する。ライセンスは、コンテンツを再生するためには、購読ノード２４０４が到達可能でなければならないことを示す。アリスは、すでに自分のＰＣをＩＳＰに登録した。その時にアリスは、自分のＰＣノード２４０６から自分のアカウントノード２４０２へのリンク２４０５を受信した。従って、ＤＲＭエンジンは、ＰＣノード２４０６を購読ノード２４０４に接続するリンクオブジェクト２４０５および２４００を含む。しかしながら、コンテンツを再生するアリスのリクエストを認可する前に、ＤＲＭエンジンはまず、リンクが含む任意の制御プログラムを実行することによって、リンクが有効か否かを決定する。リンク２４００における制御プログラムが実行されると、ＤＲＭエンジンは、状態データベースエントリを照合することによって、すでに５回の再生が行われた否かを決定する。そうでない場合には、コンテンツを再生するアリスのリクエストを認可するが、ホストアプリケーションに対して義務も発行する。義務は、レンダリングの前に、ホストがコンテンツのグレードを下げることを要求する。ホストアプリケーションは、この義務を満たすことが可能であると決定し、コンテンツのレンダリングを始める。５回の無料トライアル再生に対してコンテンツを数える前に、アリスがそのコンテンツをプレビューできるためには、制御プログラムがコールバックを含んでもよい。コールバックは、コンテンツを再生するリクエストが認可された後の、例えば２０秒を照合することによって、そのコンテンツが依然として再生されているか否かを調べる。コンテンツが依然として再生されている場合には、再生カウントは減らされるが、そうでない場合には減らされない。従って、アリスは、購読サービスによって提供されるコンテンツ項目のいずれかを選択し、アリスのトライアル購読が失効する前に、そのうちの５つを再生することができる。
【０１７５】
アリスのトライアル購読が失効すると、アリスは、正規の毎月購読を購入することを決めることにより、月額料金で望む限りの数のコンテンツ項目を再生することができる。アリスは、自分のＰＣを使用して購読の契約をすることにより、アリスのアカウントノード２４０２から購読ノード２４０４へのリンク２４１０を受信する。リンクは、リンクが１ヵ月間のみにわたって有効であることを示す制御プログラムを含む（例えば、制御プログラムは、状態データベースにおけるエントリを照合することにより、リンクが発行されてから１ヵ月が経過したか否かを調べる）。アリスのＰＣには、リンク２４１０と共に、エージェントプログラムが送信される。エージェントプログラムは、ＰＣのＤＲＭエンジンの状態データベースにおける適切なエントリを初期化するように操作可能であり、ＤＲＭエンジンは、リンクが発行された日付を示す。アリスが、購読サービスからコンテンツをダウンロードし、再生を試みる際に、アリスのＰＣのＤＲＭエンジンは、リンク２４０５および２４１０を含む購読ノードへの経路が存在することを決定する。ＤＲＭエンジンは、リンク２４０５および２４１０に含まれる任意の制御プログラムを実行することにより、リンクが有効であるか否かを決定する。リンク２４１０が発行された時から１ヵ月未満が経過した場合、リンク２４１０における制御プログラムは、リンク２４１０が依然として有効であることと、コンテンツを再生するアリスのリクエストとを示す結果を返す。アリスが、無料トライアル期間中にすでに入手したコンテンツの再生を試みる場合、アリスのＰＣ上のＤＲＭエンジンは、同じ分析を実行し、アリスのリクエストを認可する。トライアル期間中に入手したコンテンツに関連するライセンスは、安全なデータベースにＴｒｉａｌＳｔａｔｅ変数が設定されていない場合、購読ノードが到達可能でなければならないということが唯一の条件であるということを示す。購読ノードは、アリスのＰＣから再び到達可能であるので、アリスは、そのコンテンツに再びアクセスすることができるが、今回は、もはや有効でないリンク２４００でなく、リンク２４１０を介する。従って、アリスは、無料トライアルの提供中に入手したコピーに置き換わる、コンテンツ項目の第２のコピーを入手する必要がない。同様に、アリスが友人のボブ（同一サービスへの加入者）から購読コンテンツを入手する場合、この実施例において、アリスもそのコンテンツを再生することが可能である。なぜなら、コンテンツのライセンスは、購読ノードが到達可能であることを単に要求し、購読ノードがボブのＰＣまたはアカウントを介して到達可能であることを要求しないからである。
【０１７６】
上記の実施例は、本明細書に記載するシステムおよび方法によって有効にできる機能の一部の例示を単に意図するものであり、まさに上述したとおりの態様で購読が実現されなければならないという提案を意図するものではないことが理解される。例えば、他の実施例において、購読コンテンツに関連するライセンスは、購読ノードの代わりにユーザのノードに結合されてもよい。これによって、上記の実施例においてボブおよびアリスが可能なように２人の加入者がコンテンツを共有することを防止する。上記の実施例に対して多くの他のバリエーションを行うことができることが理解される。
【０１７７】
以下の表は、上記の実施例におけるエージェント、リンク、およびライセンス制御プログラムに関する、一部の例示的な擬似コードを提供するものである。
【表６】
2009512096.tif 000008
【表７】
2009512096.tif 000009
【０１７８】
図２４を再び参照して、アリスは、モバイルサービスプロバイダのアカウント２４２０をも有する。このアカウントは、アリスがネットワークに接続されている限り有効に保たれる。アリスは、購読のために特別な支払いを行う必要がなく、それと引き替えに、リンクがアリスに送信される。むしろ、アリスがネットワークに接続する際に、更新リンク２４２４がアリスの電話に自動的に送信される。これらのリンクによって、アリスは、モバイルサービスプロバイダによって提供されるコンテンツ項目またはサービスのいずれにもアクセスすることができる。これらが有するライセンスは、購読ノード２４２２が到達可能であることのみを要求する。アリスは、モバイルサービスプロバイダを変更した場合、自分のリンク２４２４が失効すると、すでに獲得したコンテンツにアクセスすることができなくなる。
【０１７９】
図２５は、サービスプロバイダがホームネットワークドメイン２５００と対話し得る方法の実施例を示す。この実施例において、装置は、最高５台の装置が常にドメインに帰属することを可能にするポリシーを実施する、ホームネットワークドメインに登録される。
スミス家のケーブルサービスプロバイダは、ホームネットワークドメイン２５００を設定するために使用するドメインマネージャソフトウェアを提供しなかった。しかし、ケーブルサービスプロバイダは、ホームネットワークドメインマネージャソフトウェアの認証済みプロバイダによってドメインマネージャが実現されていることを知っているので、ドメインマネージャソフトウェアが意図された通りに稼働することを信頼する。図２５に示すように、スミス家は、アリスの電話およびＰＣ、カールのＰＶＲ、およびジョーのＰＳＰを、ドメイン２５００に接続する。その結果、これらの装置の各々からドメインノード２５００へのリンクが発行される。新しいコンテンツが受信される場合（例えばＰＶＲにおいて）、５５１出願に記載されるような発見サービスは、ドメインにおける他の装置が、コンテンツおよび任意の必要なリンクを自動的に入手することを可能にする。ドメインノード２５００からサービスプロバイダアカウントノード２５０２へのリンクが発行される。ケーブルサービスプロバイダのコンテンツの一部は、早送りおよび巻戻しが無効にされなければならないという義務を有するライセンスを有するので、広告が閲覧される。カールのＰＶＲおよびＰＣアリスのＰＣは、この義務を実施できるので、コンテンツを再生できる。アリスの携帯電話は、この義務を実施できないので、コンテンツへのアクセスを拒絶する。
【０１８０】
１．１６．更なる実施例：コンテンツおよび著作権共有
前述の実施例が示すように、本明細書に示すシステムおよび方法の実施形態は、電子コンテンツが自然な方法で共有されることを可能にする。例えば、本明細書に記載するシステムおよび方法を使用することによって、消費者は、娯楽コンテンツを友人および家族と共有することができ、および／または家族の装置のすべてにおいて娯楽コンテンツを享受することができ、同時に、より広い無許可の配信が防止される。例えば、自動化されたピアツーピアの発見および通知サービスを使用することができる。その結果、１つの装置がコンテンツまたは関連する著作権を入手する際に、他の装置はそのコンテンツに自動的に気づくことができる。それによって、自動的にアップデート可能な仮想分散ライブラリが提供される。例えば、一実施形態において、１人のユーザがある場所において携帯機器上のコンテンツまたは著作権を入手してから帰宅する場合、ユーザの家族の装置は、これらの著作権を自動的に発見および利用することができる。反対に、ユーザが、自分のホームネットワーク上の装置において著作権を入手する場合、ユーザの携帯機器は、そのコンテンツを発見し、遠くへ運んで他の場所で使用することができる。本明細書に記載するシステムおよび方法の好ましい実施形態を使用することによって、例えば５５１出願に記載されるサービス発見および検査技術を用いて上記のシナリオを完全に自動化することを可能にするサービスおよび著作権オブジェクトを作成することができる。例えば、特定のドメインに登録される装置は、互いにサービスを提供してもよく（例えば著作権およびコンテンツの共有）、および／または遠隔サービスを呼び出すことによって、コンテンツのローカルな共有を容易にすることができる。記載するシステムおよび方法は、コピーの生成そのものの防止に焦点をあてないＤＲＭフレームワークの生成を可能にするが、ネットワーク技術と調和して作動することにより、コンテンツの共有を可能にするように設計されており、消費者がコンテンツの違法ディストリビュータになることを防止する。
【０１８１】
本明細書に記載するＤＲＭシステムおよび方法の好ましい実施形態はまた、一部の他のＤＲＭシステムの冗長な種類の著作権表現の特徴を有することなく、著作権の決定を可能にする。これに代わって、好ましい実施形態は、文脈上対話することができる巧みに作られた著作権オブジェクトのセットを使用する。これらのオブジェクトは、エンティティ（例えばユーザ、装置、コンテンツ、およびそれらのグループ）の間の関係および制御を記述する。例えば、そのような文脈的対話処理は、所与のコンテンツを再生できることを装置が決定することを可能にする。その理由は以下の通りである。（ａ）コンテンツは、ユーザが現在購読している合法的なコンテンツサービスから入手したものである。（ｂ）ユーザは、特定の家族グループの一員である。（ｃ）装置は、この特定の家族グループに関連している。この実施例に記載するような数多くの種類の関係があり、ユーザはそのことを直観的に理解する。本明細書に記載するシステムおよび方法の好ましい実施形態は、これらの種類の関係をおのずと理解するシステムの生成を可能にする。エンティティ間の関係は、時間の経過と共に、生成、抹消、および変化し得る。好ましい実施形態は、動的なネットワーク化された環境（消費者がおのずと理解できる環境）において著作権を決定する自然な方法を提供する。それにもかかわらず、コンテンツの展開者がより従来的な著作権表現方法を使用したい場合、好ましい実施形態はそれを受け入れることもできる。例えば、ツールを使用することによって従来の著作権表現を上述のようなオブジェクトのセットに変換することができ、および／またはそのような著作権表現を直接的に操作するＤＲＭエンジンを実現することができる。それに代わって、一部の実施形態において、装置は、そのような従来の著作権表現を理解する必要がなく、それらの限定によって制約されない。
【０１８２】
本明細書に記載するシステムおよび方法の好ましい実施形態はまた、媒体サービスの非常に一般的な概念を有する。媒体サービスの例は、放送サービス、およびインターネットのダウンロードサービスまたは購読サービスである。これらのサービスに関連する制約は、コンテンツの共有を困難にする場合がある。本明細書に記載するシステムおよび方法の好ましい実施形態によって、コンテンツは、放送、ブロードバンド、およびモバイルサービス上で入手することができ、携帯機器を含む家庭内のネットワーク化された装置のグループ上で共有することができる。それに代わって、またはそれに加えて、サービスは、無線接続を介してピアツーピア様式で個々の装置によって提供することができる。例えば、新世代のＷｉＦｉ対応携帯電話は、コンテンツカタログサービスを他の装置に提供することができる。そのようなサービスは、他の装置が、どのようなコンテンツが装置から共有するように利用可能であるかを「調べる」ことを可能にする。サービスは、著作権の決定のために使用できる情報を提供するので、任意の限定を受け入れたり容易に排除したりすることができる。
【０１８３】
本明細書に記載するシステムおよび方法の好ましい実施形態は、１つのサービスまたは１つのプラットホームに限定されない。前述したように、好ましい実施形態は、「個人」サービスを含む数多くのサービスとともに動作することができる。ホームネットワークおよび個人ネットワークがよりユビキタスになるにつれて、このことはますます重要になりつつある。例えば、デジタルカメラは、現在ＷｉＦｉ接続性を有して利用可能であり、ネットワーク上で写真を共有することが非常に便利になっている。写真の共有を自動化できることは素晴らしいが、カメラは、持ち運ばれる際に、多くの異なるネットワークに遭遇する。自動化された共有は便利であるが、個人的な写真はもちろん個人的なものである。本明細書に記載するシステムおよび方法の実施形態は、家族の装置において家族内で写真を共有することを容易にするが、ネットワーク上のカメラに偶然に遭遇する任意の装置とは共有しない。一般に、より多くの装置がネットワーク化されるにつれて、それらの装置上のすべてのコンテンツの著作権を管理することがますます重要になってくる。ネットワークの目的は、ネットワーク化された装置に関する情報の共有を可能にすることであるが、ネットワークは、互いに重なり合い、組み合わされる。ネットワークは、コンテンツが容易に共有されることを可能にするが、任意に共有されるべきではない。従って、コンテンツ、ユーザ、ネットワーク、および装置の特性によって提供される状況を利用することによって、コンテンツが共有されるか否か、およびコンテンツの共有方法を決定する、ネットワークを意識したＤＲＭシステムを有することは、望ましい。本明細書に記載するシステムおよび方法の好ましい実施形態は、そのような方法を可能にする。
【０１８４】
６．コンテンツ消費およびパッケージングのための参照アーキテクチャ
以下は、ＤＲＭで保護されたコンテンツを消費する消費アプリケーション（例えばメディアプレーヤ）、および消費アプリケーションを対象にしたコンテンツをパッケージングするパッケージングアプリケーション（例えばサーバに存在するアプリケーション）についての、参照アーキテクチャの説明である。
【０１８５】
１．１７．クライアントアーキテクチャ
以下は、コンテンツを消費するホストアプリケーションのためにＤＲＭエンジンの例示的実施形態が実行し得る機能の実施例を提供するものである。
【０１８６】
１．１７．１．ＤＲＭエンジンインタフェースに対するホストアプリケーション
好ましい実施形態においては、ＤＲＭエンジン用のＡＰＩは必要ないが、以下は、例示的なＤＲＭエンジン（「オクトパス」ＤＲＭエンジンと呼ばれる）によって、１つの例示的実施形態のホストアプリケーションに提供される、インタフェースの種類の高レベルの説明である。
【０１８７】
Ｏｃｔｏｐｕｓ：ＣｒｅａｔｅＳｅｓｓｉｏｎ（ｈｏｓｔＣｏｎｔｅｘｔＯｂｊｅｃｔ）→Ｓｅｓｓｉｏｎ。これは、ホストアプリケーションコンテキストを与えられるセッションを作成する。コンテキストオブジェクトは、アプリケーションの中にコールバックを行うために、オクトパスＤＲＭエンジンによって使用される。
【０１８８】
Ｓｅｓｓｉｏｎ：ＰｒｏｃｅｓｓＯｂｊｅｃｔ（ｄｒｍＯｂｊｅｃｔ）。この機能は、ＤＲＭサブシステムに帰属するものとして識別され得る媒体ファイルにおける一定の種類のオブジェクトに遭遇するときに、ホストアプリケーションによって呼び出されるべきものである。そのようなオブジェクトは、コンテンツ制御プログラム、帰属関係トークンなどを含む。これらのオブジェクトのシンタックスおよびセマンティクスは、ホストアプリケーションにとって不透明である。
【０１８９】
Ｓｅｓｓｉｏｎ：ＯｐｅｎＣｏｎｔｅｎｔ（ｃｏｎｔｅｎｔＲｅｆｅｒｅｎｃｅ）→Ｃｏｎｔｅｎｔ。ホストアプリケーションは、マルチメディアコンテンツファイルと対話する必要があるときに、この機能を呼び出す。ＤＲＭエンジンは、Ｃｏｎｔｅｎｔオブジェクトを返す。Ｃｏｎｔｅｎｔオブジェクトは、コンテンツに関するＤＲＭ情報を検索し、それと対話するために、後で使用することができる。
【０１９０】
Ｃｏｎｔｅｎｔ：ＧｅｔＤｒｍＩｎｆｏ（）。これは、ファイルのための標準的なメタデータにおいて利用可能でないコンテンツに関するＤＲＭメタデータを返す。
【０１９１】
Ｃｏｎｔｅｎｔ：ＣｒｅａｔｅＡｃｔｉｏｎ（ａｃｔｉｏｎＩｎｆｏ）→Ａｃｔｉｏｎ。ホストアプリケーションは、Ｃｏｎｔｅｎｔオブジェクトと対話することを望むときに、この機能を呼び出す。ａｃｔｉｏｎＩｎｆｏパラメータは、アプリケーションがどのような種類のアクションを実行する必要があるか（例えばＰｌａｙ）、ならびに必要に応じて任意の関連パラメータを指定する。この機能は、Ａｃｔｉｏｎオブジェクトを返す。Ａｃｔｉｏｎオブジェクトを使用することによって、アクションを実行し、コンテンツ鍵を検索することができる。
【０１９２】
Ａｃｔｉｏｎ：ＧｅｔＫｅｙＩｎｆｏ（）。これは、解読サブシステムがコンテンツを解読するために必要な情報を返す。
【０１９３】
Ａｃｔｉｏｎ：Ｃｈｅｃｋ（）。ＤＲＭサブシステムがこのアクションの実行を認可するか否か（例えばＡｃｔｉｏｎ：Ｐｅｒｆｏｒｍ（）が成功するか否か）を照合する。
【０１９４】
Ａｃｔｉｏｎ：：Ｐｅｒｆｏｒｍ（）。これは、このアクションを管理する規則による指定される通りに、アクションを実行し、（その副作用による）任意の結果を実行する。
【０１９５】
１．１７．２．ホストサービスインタフェースに対するＤＲＭエンジン
以下は、ホストアプリケーションの例示的実施形態から、ＤＲＭエンジンの例示的実施形態によって必要とされる、ホストサービスインタフェースの種類の実施例である。
【０１９６】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＧｅｔＦｉｌｅＳｙｓｔｅｍ（ｔｙｐｅ）→ＦｉｌｅＳｙｓｔｅｍ。これは、ＤＲＭサブシステムが排他的にアクセスする仮想ＦｉｌｅＳｙｓｔｅｍオブジェクトを返す。この仮想ＦｉｌｅＳｙｓｔｅｍは、ＤＲＭ状態情報を格納するために使用される。このＦｉｌｅＳｙｓｔｅｍの中のデータは、ＤＲＭサブシステムのみによって読み込みおよび書き込みが可能であるべきである。
【０１９７】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＧｅｔＣｕｒｒｅｎｔＴｉｍｅ（）。これは、ホストシステムによって保守されるような現在の日付／時間を返す。
【０１９８】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＧｅｔＩｄｅｎｔｉｔｙ（）。これは、このホストの一意なＩＤを返す。
【０１９９】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＰｒｏｃｅｓｓＯｂｊｅｃｔ（ｄａｔａＯｂｊｅｃｔ）。これは、データオブジェクトをホストサービスに返す。データオブジェクトは、ＤＲＭオブジェクトに埋め込まれている。しかし、ＤＲＭサブシステムは、データオブジェクトをホストによって管理されるもの（例えば証明書）として識別する。
【０２００】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＶｅｒｉｆｙＳｉｇｎａｔｕｒｅ（ｓｉｇｎａｔｕｒｅＩｎｆｏ）。これは、データオブジェクトを通じてデジタル署名の有効性を照合する。一実施形態において、ｓｉｇｎａｔｕｒｅＩｎｆｏオブジェクトは、ＸＭＬＳｉｇ要素に見いだされる情報と同等の情報を含む。ホストサービスは、署名を検証するために必要な鍵および鍵証明書の管理を担う。
【０２０１】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＣｒｅａｔｅＣｉｐｈｅｒ（ｃｉｐｈｅｒＴｙｐｅ，ｋｅｙＩｎｆｏ）→Ｃｉｐｈｅｒ。これは、ＤＲＭサブシステムがデータを暗号化および解読するために使用することができるＣｉｐｈｅｒオブジェクトを作成する。暗号化を実施するために必要な鍵情報を記述する各フォーマットについて、暗号種類の最小セットが規定される。
【０２０２】
Ｃｉｐｈｅｒ：：Ｅｎｃｒｙｐｔ（ｄａｔａ）
【０２０３】
Ｃｉｐｈｅｒ：：Ｄｅｃｒｙｐｔ（ｄａｔａ）
【０２０４】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＣｒｅａｔｅＤｉｇｅｓｔｅｒ（ｄｉｇｅｓｔｅｒＴｙｐｅ）→Ｄｉｇｅｓｔｅｒ。これは、ＤＲＭサブシステムが一部のデータを通して安全なハッシュを算出するために使用することができるＤｉｇｅｓｔｅｒオブジェクトを作成する。
一実施形態において、ダイジェストの最小セットを規定することができる。
【０２０５】
Ｄｉｇｅｓｔｅｒ：：Ｕｐｄａｔｅ（ｄａｔａ）
【０２０６】
Ｄｉｇｅｓｔｅｒ：：ＧｅｔＤｉｇｅｓｔ（）
【０２０７】
１．１７．３．ＵＭＬシーケンス図
図２６は、前述のセクションに記載される例示的なＡＰＩの使用方法、ならびに例示的実施形態においてホストアプリケーションとＤＲＭクライアントエンジンとの間で行われる対話処理を例示する。
【０２０８】
１．１８．パッケージャ参照アーキテクチャ
以下は、コンテンツをパッケージングするホストアプリケーションのために、パッケージングエンジンが実行し得る機能の例を提供するものである。実際には、パッケージングアプリケーションは、具体的にパッケージングに焦点をあててもよく、あるいは、（例えば、ローカルに、あるいはネットワーク上の他の場所でパッケージングされる）保護されたコンテンツにアクセスするユーザシステムにおいて稼働する、汎用アプリケーションの一部であり得る。
【０２０９】
１．１８．１．パッケージングエンジンインタフェースに対するホストアプリケーション
このセクションは、「オクトパス」と呼ばれる参照ＤＲＭエンジンに関連して使用されるホストアプリケーションとパッケージングエンジンとの間の例示的なＡＰＩの高レベルの説明を提供するものである。
【０２１０】
Ｏｃｔｏｐｕｓ：：ＣｒｅａｔｅＳｅｓｓｉｏｎ（ｈｏｓｔＣｏｎｔｅｘｔＯｂｊｅｃｔ）→Ｓｅｓｓｉｏｎ。これは、ホストアプリケーションコンテキストを与えられるセッションを作成する。この機能によって返されるコンテキストオブジェクトは、アプリケーションの中にコールバックを行うために、パッケージングエンジンによって使用される。
【０２１１】
Ｓｅｓｓｉｏｎ：：ＣｒｅａｔｅＣｏｎｔｅｎｔ（ｃｏｎｔｅｎｔＲｅｆｅｒｅｎｃｅｓ［］）→Ｃｏｎｔｅｎｔ。ホストアプリケーションは、この機能を呼び出すことによって、次のステップのライセンスオブジェクトに関連するコンテンツオブジェクトを作成する。ｃｏｎｔｅｎｔＲｅｆｅｒｅｎｃｅｓアレイにおいて複数のコンテンツ参照を有するということは、これらがバンドルにおいて共に結合され（例えば１つのオーディオトラックおよび１つのビデオトラック）、発行されたライセンスが１つの非可分グループとしてこれらの対象にされるべきであるということを意味する。
【０２１２】
Ｃｏｎｔｅｎｔ：：ＳｅｔＤｒｍＩｎｆｏ（ｄｒｍＩｎｆｏ）。ｄｒｍＩｎｆｏパラメータは、発行されるライセンスのメタデータを指定する。ｄｒｍＩｎｆｏは、ライセンスから仮想マシンのためのバイトコードに変換するために、ガイドラインとしての役割を果たす。
【０２１３】
Ｃｏｎｔｅｎｔ：：ＧｅｔＤＲＭＯｂｊｅｃｔｓ（ｆｏｒｍａｔ）→ｄｒｍＯｂｊｅｃｔｓ。この機能は、パッケージャエンジンが作成したｄｒｍＯｂｊｅｃｔｓをホストアプリケーションが獲得する準備ができたときに、呼び出される。フォーマットパラメータは、これらのオブジェクト（例えばＸＭＬまたはバイナリアトム）のについて予想されるフォーマットを示す。
【０２１４】
Ｃｏｎｔｅｎｔ：：ＧｅｔＫｅｙｓ（）→ｋｅｙｓ［］。この機能は、コンテンツを暗号化するために鍵を必要とするときに、ホストパッケージングアプリケーションによって呼び出される。一実施形態において、コンテンツ参照ごとに１つの鍵がある。
【０２１５】
１．１８．２．ホストサービスインタフェースに対するパッケージングエンジン
以下は、一実施形態において、例示的なパッケージングエンジンにとってホストアプリケーションが提供する必要のあるインタフェースの種類の実施例である。
【０２１６】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＧｅｔＦｉｌｅＳｙｓｔｅｍ（ｔｙｐｅ）→ＦｉｌｅＳｙｓｔｅｍ。これは、ＤＲＭサブシステムが排他的にアクセスする仮想ＦｉｌｅＳｙｓｔｅｍオブジェクトを返す。この仮想ＦｉｌｅＳｙｓｔｅｍは、ＤＲＭ状態情報を格納するために使用することができる。このＦｉｌｅＳｙｓｔｅｍの中のデータは、ＤＲＭサブシステムのみによって読み込みおよび書き込みが可能であるべきである。
【０２１７】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＧｅｔＣｕｒｒｅｎｔＴｉｍｅ（）→Ｔｉｍｅ。これは、ホストシステムによって保守されるような現在の日付／時間を返す。
【０２１８】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＧｅｔＩｄｅｎｔｉｔｙ（）→ＩＤ。これは、このホストの一意なＩＤを返す。
【０２１９】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＰｅｒｆｏｒｍＳｉｇｎａｔｕｒｅ（ｓｉｇｎａｔｕｒｅＩｎｆｏ，ｄａｔａ）。パッケージングエンジンによって作成された一部のＤＲＭオブジェクトは、信頼されなければならない。ホストによって提供されるこのサービスは、指定されたオブジェクトに署名するために使用される。
【０２２０】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＣｒｅａｔｅＣｉｐｈｅｒ（ｃｉｐｈｅｒＴｙｐｅ，ｋｅｙＩｎｆｏ）→Ｃｉｐｈｅｒ。これは、パッケージングエンジンがデータの暗号化および解読のために使用することができる暗号オブジェクト（データの暗号化および解読ができるオブジェクト）を作成する。一実施形態において、暗号オブジェクトは、ＣｏｎｔｅｎｔＫｅｙオブジェクトにおけるコンテンツ鍵データを暗号化するために使用される。
【０２２１】
Ｃｉｐｈｅｒ：：Ｅｎｃｒｙｐｔ（ｄａｔａ）。これは、データを暗号化する。
【０２２２】
Ｃｉｐｈｅｒ：：Ｄｅｃｒｙｐｔ（ｄａｔａ）。これは、データを解読する。
【０２２３】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＣｒｅａｔｅＤｉｇｅｓｔｅｒ（ｄｉｇｅｓｔｅｒＴｙｐｅ）→Ｄｉｇｅｓｔｅｒ。これは、パッケージングエンジンが一部のデータを通して安全なハッシュを算出するために使用することができるダイジェスタオブジェクトを作成する。
【０２２４】
Ｄｉｇｅｓｔｅｒ：：Ｕｐｄａｔｅ（ｄａｔａ）。これは、ダイジェスタオブジェクトにデータを送る。
【０２２５】
Ｄｉｇｅｓｔｅｒ：：ＧｅｔＤｉｇｅｓｔ（）。これは、ダイジェストを算出する。
【０２２６】
ＨｏｓｔＣｏｎｔｅｘｔ：：ＧｅｎｅｒａｔｅＲａｎｄｏｍＮｕｍｂｅｒ（）。これは、鍵を生成するために使用できる乱数を生成する。
【０２２７】
図２７は、上記の例示的なＡＰＩの使用方法、ならびに１つの例示的実施形態においてホストアプリケーションとパッケージングエンジンとの間で行われる対話処理の、実施例を示すＵＭＬ図である。
【０２２８】
７．オブジェクト
このセクションは、ＤＲＭエンジンの例示的なインプリメンテーションの基礎単位として役立つＤＲＭオブジェクトに関する詳細な情報を提供するものである。まず、コンテンツの保護およびガバナンスのためのＤＲＭエンジン使用法のオブジェクトの種類について、比較的に高レベルの概要を述べる。次に、これらのオブジェクトより詳細な説明、およびオブジェクトが伝える情報を、１つの例示的実施形態において使用される一部の例示的データ構造とともに提供する。
【０２２９】
１．１９．コンテンツ保護およびガバナンスＤＲＭオブジェクト
前述したように、図６と関連して、コンテンツガバナンスオブジェクト（ノードおよびリンクオブジェクトとともに集合的に「ＤＲＭオブジェクト」と呼ばれることがある）を使用することによって、使用規則および条件を、保護されたコンテンツに関連づける。
これらのオブジェクトは共にライセンスを形成する。
【０２３０】
図６に示すように、コンテンツオブジェクト６１４によって表されるデータは、鍵を使用して暗号化される。コンテンツを解読するために必要な鍵は、ＣｏｎｔｅｎｔＫｅｙオブジェクト６０２によって表される。それを暗号化するために使用するコンテンツと鍵との間の結合は、プロテクタオブジェクト６０４によって表される。解読鍵の使用を管理する規則は、制御オブジェクト６０８によって表される。ＣｏｎｔｅｎｔＫｅｙ６０２と制御オブジェクト６０８との間の結合は、コントローラオブジェクト６０６によって表される。一実施形態において、信頼されるシステムは、制御オブジェクト６０８におけるバイトコードによって表現される規則のガバナンスの下で、コンテンツ解読鍵を利用するのみである。図２８Ａは、図６に示すようなライセンスのより詳細な図解であり、一実施形態において使用される署名スキームを例示する。
【０２３１】
１．１９．１．共通要素
一実施形態において、オブジェクトは、共通の基本的特徴を共有し、それらの各々は、ＩＤ、属性のリスト、および拡張のリストを有することができる。
【０２３２】
１．１９．１．１．ＩＤ
他のオブジェクトによって参照されるオブジェクトは、一意なＩＤを有する。
一実施形態において、ＩＤは単にＵＲＩであり、規則としてそれらのＵＲＩはＵＲＮである。
【０２３３】
１．１９．１．２．属性
属性は、入力された値である。属性には、名称をつけたり削除したりすることができる。名前付き属性の名前は、単純なストリングまたはＵＲＩである。属性の値は、単純型（ストリング、整数、またはバイト列）、または複合型（リストおよびアレイ）である。種類「リスト」の属性は、名前付き属性の番号の付かないリストを含む。種類「アレイ」の属性は、無名の属性の順序配列を含む。
【０２３４】
オブジェクトの「属性」フィールドは、名前付き属性の（場合によっては空の）無秩序のセットである。
【０２３５】
１．１９．１．３．拡張
拡張は、任意または強制的な追加データを運ぶために、オブジェクトに追加することができる要素である。拡張は、入力され、一意なＩＤも有する。拡張は、内部拡張または外部拡張であり得る。
【０２３６】
１．１９．１．３．１．内部拡張
内部拡張は、拡張するオブジェクトの中に含まれる。内部拡張は、拡張のための特定の拡張データの種類が、オブジェクトを使用するインプリメンテーションにとって知られる必要があるか否かを示す、「重要」フラグを有する。一実施形態において、インプリメンテーションが、理解できないデータ型を有する重要な拡張を有するオブジェクトに遭遇する場合、オブジェクト全体を拒絶しなければならない。
【０２３７】
一実施形態において、内部拡張のＩＤは、ローカルに一意である必要がある。オブジェクトは、同一のＩＤを有する２つの拡張を含むことはできない。しかし、２つの異なるオブジェクトが各々、他のオブジェクトの拡張のＩＤと同じＩＤを有する拡張を含むことは可能である。
【０２３８】
オブジェクトの「拡張」フィールドは、内部拡張の（場合によっては空の）無秩序のセットである。
【０２３９】
１．１９．１．３．２．外部拡張
外部拡張は、拡張するオブジェクトの中には含まれない。外部拡張は、オブジェクトから独立して出現し、それらが拡張するオブジェクトのＩＤを含む「サブジェクト」フィールドを有する。一実施形態において、外部拡張のＩＤは、グローバルに一意である必要がある。
【０２４０】
１．１９．２．コンテンツ
一実施形態において、コンテンツオブジェクトは、「外部」オブジェクトである。そのフォーマットおよび記憶は、ＤＲＭエンジンの制御の下にはなく、ホストアプリケーションのコンテンツ管理サブシステムの下にある（例えば、コンテンツは、ＭＰ４ムービーファイル、ＭＰ３音楽トラックなどであり得る）。一実施形態において、コンテンツのためのフォーマットは、ＩＤをコンテンツペイロードデータに関連づけるためのサポートを提供する必要がある。コンテンツペイロードは、フォーマットに依存する態様（一般に共通暗号（例えばＡＥＳ）によって）において暗号化される。
【０２４１】
１．１９．３．ＣｏｎｔｅｎｔＫｅｙ
ＣｏｎｔｅｎｔＫｅｙオブジェクトは、一意な暗号化キーを表し、それをＩＤに関連づける。ＩＤの目的は、ＰｒｏｔｅｃｔｏｒオブジェクトおよびＣｏｎｔｒｏｌｌｅｒオブジェクトがＣｏｎｔｅｎｔＫｅｙオブジェクトを参照できるようにすることである。ＣｏｎｔｅｎｔＫｅｙオブジェクトにカプセル化される実際の鍵データは、それ自体が暗号化されるので、コンテンツを解読することを認可された受信者のみが読み取ることができる。ＣｏｎｔｅｎｔＫｅｙオブジェクトは、鍵データを暗号化するためにどの暗号システムが使用されたかを指定する。コンテンツ鍵データを保護するために使用される暗号システムは、鍵配信システム（Ｋｅｙ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｓｙｓｔｅｍ）と呼ばれる。異なる鍵配信システムを使用することができる。鍵配信システムの例は、上述したスキューバ鍵配信システムである。
【０２４２】
１．１９．４．プロテクタ
Ｐｒｏｔｅｃｔｏｒオブジェクトは、Ｃｏｎｔｅｎｔオブジェクトのデータを暗号化するためにどの鍵が使用されたかを見いだすことを可能にする情報を含む。Ｐｒｏｔｅｃｔｏｒオブジェクトはまた、そのデータを暗号化するためにどの暗号化アルゴリズムが使用されたかに関する情報を含む。一実施形態において、Ｐｒｏｔｅｃｔｏｒオブジェクトは、Ｃｏｎｔｅｎｔオブジェクトへの参照である１つ以上のＩＤと、データを暗号化するために使用された鍵を表すＣｏｎｔｅｎｔＫｅｙオブジェクトへの参照である正確に１つのＩＤとを含む。プロテクタが複数のＣｏｎｔｅｎｔオブジェクトを指し示す場合、これらのすべてのＣｏｎｔｅｎｔオブジェクトは、同一の暗号化アルゴリズムおよび同一の鍵を使用して暗号化されたデータを表す。一実施形態において、使用される暗号システムが、異なるデータ項目のために同一の鍵を使用する安全な方法を可能にしない限り、Ｐｒｏｔｅｃｔｏｒオブジェクトが複数のＣｏｎｔｅｎｔオブジェクトを指し示すことは推奨されない。
【０２４３】
１．１９．５．制御
制御オブジェクトは、ホストアプリケーションによってリクエストされるときに、コンテンツ上の一定のアクションが許可されるべきか否かに関する決定を、ＤＲＭエンジンが行うことを可能にする、情報を含む。一実施形態において、コンテンツ鍵の使用を管理する規則は、仮想マシンによって実行されるバイトコードとして、制御オブジェクトにおいてコード化される。制御オブジェクトはまた、一意なＩＤを有するので、コントローラオブジェクトによって参照されることができる。一実施形態において、制御オブジェクトは署名されるので、ＤＲＭエンジンは、制御バイトコードが有効で信用できることを、決定のためにそれを使用する前に、検証できる。制御オブジェクトの有効性もまた、コントローラオブジェクトに含まれる安全なハッシュの検証によって、任意に導出することができる。
【０２４４】
１．１９．６．コントローラ
コントローラオブジェクトは、ＣｏｎｔｅｎｔＫｅｙオブジェクトによって表される１つ以の鍵の使用をどの制御が管理するかについて、ＤＲＭエンジンが見いだすことを可能にする情報を含む。コントローラオブジェクトは、ＣｏｎｔｅｎｔＫｅｙオブジェクトおよびそれが参照する制御オブジェクトにそれを結合する情報を含む。一実施形態において、コントローラオブジェクトは署名される（例えば、コントローラオブジェクトに署名することを可能にする証明書を有するパッケージャアプリケーションによって）。その結果、ＣｏｎｔｅｎｔＫｅｙとそれを管理する制御オブジェクトとの間の結合の有効性および、ならびにＣｏｎｔｅｎｔＫｅｙ  ＩＤと実際の鍵データとの間の結合の有効性を、確立することができる。コントローラオブジェクトの署名は、公開鍵署名、または共通鍵署名、あるいは両方の組み合わせであり得る。更に、コントローラオブジェクトによって参照される制御オブジェクトのダイジェストがコントローラオブジェクトに含まれる場合、制御オブジェクトの署名を別に検証する必要なしに、制御オブジェクトの有効性を導出することができる。
【０２４５】
１．１９．６．１．共通鍵署名
一実施形態において、このことは、コントローラオブジェクトのための署名の好ましい種類であり、コントローラオブジェクトのメッセージ認証コード（ＭＡＣ）を算出することによって実現される。これに鍵をかけることは、対応するＣｏｎｔｅｎｔＫｅｙオブジェクトによって表される鍵と同一の鍵によって行われる。一実施形態において、このＭＡＣのための標準的な方法は、同一の展開において使用されるＰＫＩ署名アルゴリズムのために選択されるものと同一のハッシュアルゴリズムを有するＨＭＡＣを使用することである。
【０２４６】
１．１９．６．２．公開鍵署名
この種の署名は、コントローラオブジェクトの署名者の身元を知る必要があるときに、使用される。この種の署名は、公開鍵署名アルゴリズムによって実現される。この署名は、このオブジェクトの有効性を表明する主体の秘密鍵によって行われる。一実施形態において、この種の署名を使用する場合、共通鍵署名も存在し、コントローラオブジェクトならびに公開鍵署名の両方に署名する。その結果、その秘密鍵によって署名した主体もまた、ＣｏｎｔｅｎｔＫｅｙオブジェクトにおいて運ばれるコンテンツ鍵の実効値についての知識を有したことを保証することができる。
【０２４７】
１．２０．識別および鍵管理ＤＲＭオブジェクト
前述したように、ノードオブジェクトは、ＤＲＭプロファイルにおけるエンティティを表す。ノードオブジェクトが表すものを規定するために、暗黙的または明示的なセマンティクスは使用されない。システムの所与の展開（ＤＲＭプロファイル）は、どのような種類の主体が存在するか、および異なるノードオブジェクトがどのような役割および識別を表すかを規定する。その意味情報は、ノードオブジェクトの属性を使用して、一般に表現される。
【０２４８】
リンクオブジェクトは、ノード間の関係を表す。リンクオブジェクトはまた、コンテンツ鍵導出のために使用されるリンクを可能にする一部の暗号データを任意に含むことができる。まさしくノードに関して、一実施形態において、リンク関係が意味するものを規定するために、暗黙的または明示的なセマンティクスは使用されない。所与のＤＲＭプロファイルにおいてリンクのｆｒｏｍノードおよびｔｏノードが表すものに依存して、リンク関係の意味は、帰属関係、所有権、関連、および／または多くの他の種類の関係を表現することができる。代表的なＤＲＭプロファイルにおいて、一部のノードオブジェクトはユーザを表すことがあり、他のノードは装置を表すことがあり、他のノードはユーザグループまたは認可ドメイン（広告）を表すことがある。そのような状況において、装置とユーザとの間のリンクは所有権関係を表してもよく、ユーザとユーザグループまたは認可ドメインと間のリンクは帰属関係を表してもよい。図２８Ｂは、１つの例示的実施形態におけるノードとリンクとの間の構造および相互関係を例示する。
【０２４９】
１．２０．１．ノード
ノードオブジェクトは、システムのエンティティを表す。ノードオブジェクトの属性は、ノードオブジェクトが表すものの一定の態様を規定する（例えば、ＤＲＭプロファイルの状況におけるノードオブジェクトによって表される役割または識別）。ノードオブジェクトはまた、ノードオブジェクトの機密の部分（一般に、ノードによって表されるエンティティ、またはそのノードの管理を担う一部のエンティティ）にアクセスするサブシステムに対して、機密情報を対象にするために使用される機密非対称鍵のペアを有してもよい。ノードにおいて対象にされる機密情報は、そのノードの機密公開鍵によって暗号化することができる。ノードオブジェクトはまた、共有非対称鍵のペアを有してもよい。共有共通鍵は、システムがＣｏｎｔｅｎｔＫｅｙ配信のためにＣｏｎｔｅｎｔＫｅｙ導出システム（例えば本明細書の他の場所に記載するようなもの）を使用するときに、リンクオブジェクトと連動して使用することができる。好ましい実施形態において、リンクまたは制御オブジェクトによって参照される必要のあるエンティティ、または暗号によって対象にされる情報を受信する必要のあるエンティティのみが、対応するノードオブジェクトを有することを必要とする。
【０２５０】
１．２０．２．リンク
リンクオブジェクトは、頂点がノードオブジェクトであるグラフにおいて、誘導されたエッジが存在するということの、署名されたアサーションである。ノードおよびリンクの所与のセットについて、グラフにおいてノードＸ頂点とノードＹ頂点との間に有向路が存在する場合、ノードＸとノードＹとの間に経路があると言われる。ノードＸとノードＹとの間に経路がある場合、ノードＹはノードＸから到達可能であると言われる。リンクオブジェクトによって表されるアサーションは、どのノードが他のノードから到達可能であるかを表現するために使用される。コンテンツオブジェクトを管理する制御は、アクションの実行を可能にする前に、アクションを実行するエンティティに関連するノードから一定のノードに到達可能であることを照合できる。例えば、ノードＤが、コンテンツオブジェクト上で「再生」アクションを実行することを望む装置を表す場合、コンテンツオブジェクトを管理する制御は、一定のユーザを表す一定のノードＵが、ノードＤから到達可能であるか否かを検証することができる。ノードＵが到達可能であるか否かを決定するために、ＤＲＭエンジンは、ノードＤとノードＵとの間に経路を確立することができるリンクオブジェクトのセットがあるか否かを照合することができる。
【０２５１】
一実施形態において、ＤＲＭエンジンは、ノードグラフにおける経路の存在を決定するためにリンクオブジェクトを使用する前に、リンクオブジェクトを検証する。
リンクオブジェクトに署名するために使用される証明書システム（例えばｘ５０９ｖ３）の特定の機能に依存して、限定された存続期間をリンクオブジェクトに与えたり、リンクオブジェクトを無効にしたりなどできる。一実施形態において、どの鍵がリンクオブジェクトに署名できるか、どのリンクオブジェクトが作成され得るか、およびリンクオブジェクトの存続期間、を管理するポリシーは、ＤＲＭエンジンによって直接に処理されない。
これに代わって、これらのポリシーは、ノードの属性情報に影響を及ぼす。一実施形態において、一定のポリシーを実施するタスクを容易にするために、更なる制約照合によって標準証明書フォーマットを拡張する方法が提供される。これらの拡張は、リンクに署名する鍵のための証明書上の有効性制約を表現することを可能にする。その結果として、リンクが有効とみなされる前に、制約（例えば、リンクがどのようなタイプのノードに接続しているか、ならびに他の属性）を照合することができる。
【０２５２】
一実施形態において、リンクオブジェクトは、リンクの有効性を限定するために使用される制御オブジェクトを含むことができる。それに加えて、一実施形態において、リンクオブジェクトは、共有鍵を有するユーザに鍵配信を提供する暗号鍵導出データを含んでもよい。その暗号データは、メタデータに加えて、「ｔｏ」ノードの共有公開鍵および／または共有共通鍵によって暗号化する、「ｆｒｏｍ」ノードの秘密鍵および／または共通共有鍵を含む。
【０２５３】
１．２１．データ構造
以下の段落は、上述のオブジェクトのための例示的なオブジェクトモデルを更に詳細に説明するものであり、１つの例示的実施形態において各タイプのオブジェクトが有するフィールドを規定する。データ構造は、比較的に単純なオブジェクト記述シンタックスを使用して記述される。各オブジェクトタイプは、親クラス（すなわち「〜は…である」関係）を拡張できるクラスによって規定される。クラス記述は、単純な抽象型、すなわち「ストリング」（文字列）、「ｉｎｔ」（整数値）、「バイト」（８ビット値）、および「ブーリアン」（真または偽）に関するものであるが、それらのデータ型について、またはそれらの種類を含む複合構造について、任意の特定のコード化を規定するものではない。オブジェクトをコード化または表す方法は、エンジンのインプリメンテーションに依存して変化することがある。実際には、ＤＲＭエンジンの使用の所与のプロファイルは、フィールドがどのように表されるかを指定することができる（例えばＸＭＬスキーマを使用して）。
【０２５４】
１つの例示的実施形態において、以下の表記法が使用される。
【表８】
2009512096.tif 000010
【０２５５】
【表９】
2009512096.tif 000011
【０２５６】
１．２１．１．１．属性
一実施形態において、４種類の属性（ＩｎｔｅｇｅｒＡｔｔｒｉｂｕｔｅ、ＳｔｒｉｎｇＡｔｔｒｉｂｕｔｅ、ＢｙｔｅＡｒｒａｙＡｔｔｒｉｂｕｔｅ、およびＬｉｓｔＡｔｔｒｉｂｕｔｅ）があり、各々が名前およびタイプを有する。
【表１０】
2009512096.tif 000012
【０２５７】
１．２１．１．２．拡張
論ずる例示的実施形態において、２つのタイプの拡張、すなわち、Ｏｃｔｏｂｊｅｃｔの内部で運ばれる内部拡張、およびＯｃｔｏｂｊｅｃｔの外部で運ばれる外部拡張がある。
【表１１】
2009512096.tif 000013
【０２５８】
一部の実施形態において、たとえ特定のタイプのＥｘｔｅｎｓｉｏｎＤａｔａが所与のインプリメンテーションによって理解されない場合でさえも、オブジェクトの署名が検証可能であることが重要である。従って、一実施形態において、ｄａｔａＤｉｇｅｓｔフィールドを有するインダイレクションのレベルが追加される。ＥｘｔｅｎｓｉｏｎＤａｔａの指定によって、データが特定のオブジェクトの状況における署名の一部であることが要求される場合、ｄａｔａＤｉｇｅｓｔフィールドが存在する。このＥｘｔｅｎｓｉｏｎＤａｔａを理解し、従ってその正準表示を算出できるインプリメンテーションは、ダイジェストを検証することができる。そのような実施形態において、このＥｘｔｅｎｓｉｏｎＤａｔａの指定によって、データが署名の一部でないことが要求される場合、ｄａｔａＤｉｇｅｓｔフィールドは存在しない。
【表１２】
2009512096.tif 000014
【０２５９】
一実施形態において、各鍵は、一意なＩＤ、フォーマット、使用法（空白であり得る）、およびデータを有する。「使用法」フィールドは、空でない場合、鍵を使用できる目的を指定する。通常のコンテンツ鍵について、このフィールドは空である。上述したような鍵配信スキームが使用される実施形態において、このフィールドは、共有鍵または機密鍵のいずれであるかを指定してもよい。「フォーマット」フィールドは、「データ」フィールドのフォーマットを指定する（例えば、共通鍵のための「ＲＡＷ」、またはＲＳＡ秘密鍵のための「ＰＫＣＳ＃８」など）。「データ」フィールドは、「フォーマット」フィールドに従ってフォーマットされる実際の鍵データを含む。
【０２６０】
鍵のペア（例えばＲＳＡ鍵）の一部である鍵については、追加のフィールド「ｐａｉｒＩｄ」が、ペアのための一意の識別子を与える。その結果、ペアはその他のデータ構造から参照されることができる。
【０２６１】
一実施形態において、オブジェクトの実際の表現が、鍵の暗号化されたコピーを含む場合でさえも、鍵オブジェクトにおけるデータフィールドは、実際の鍵の平文値である（すなわち、ハッシュされる鍵の平文値である）。
【表１３】
2009512096.tif 000015
【０２６２】
８．仮想マシン
本明細書に記載するＤＲＭエンジンの好ましい実施形態は、仮想マシン（本明細書において「制御仮想マシン」、「制御ＶＭ」、または単に「ＶＭ」と呼ばれることがある）を使用することによって、コンテンツへのアクセスを管理する制御プログラムを実行する。そのような仮想マシンの例示的実施形態、ならびにこの例示的実施形態に対してなし得る様々な変更および設計考慮事項を以下に記載する。仮想マシン（「プランクトン」仮想マシンと呼ばれる）の例示的実施形態を、ＤＲＭエンジン（「オクトパス」と呼ばれる）の例示的実施形態に統合したものも記載する。しかしながら、本明細書に記載するデジタル著作権管理エンジン、アーキテクチャ、および他のシステムおよび方法の実施形態は、任意の適切な仮想マシンとともに使用することができ、または一部の実施形態においては、全く仮想マシンなしで使用することができることが理解されるべきである。従って、仮想マシンの例示的実施形態に関して下記に提供する詳細は、説明のためであって、限定のためではないことが理解される。
【０２６３】
好ましい実施形態において、制御ＶＭは、従来の仮想マシンであり、非常に小さいコードフットプリントを有する様々なプログラミング言語を使用して、容易に実現するように設計される。制御ＶＭは、最低限必要なものだけであるように設計された単純なスタック向き命令セットに基づいており、実行速度またはコード密度に対する過度の懸念がない。コンパクト符号が必要とされる状況において、データ圧縮技術は、仮想マシンのバイトコードを圧縮するために使用することができる。
【０２６４】
好ましい実施形態において、制御仮想マシンは、低水準または高水準プログラミング言語のためのターゲットとして適切に設計され、アセンブラ、Ｃ、およびＦＯＲＴＨをサポートする。さらに、コードを仮想マシンによって使用されるフォーマット（例えばバイトコード）にコンパイルするために、他の言語（例えばＪａｖａ（登録商標）またはカスタマイズした言語）のためのコンパイラを、比較的に簡単な様式で作成できることが理解される。一実施形態において、制御仮想マシンは、ホスト環境の中でホストされるように設計され、プロセッサ上またはシリコンにおいて直接に実行されない。好ましい実施形態において、仮想マシンのための自然なホスト環境は、ＤＲＭエンジンである。但し、それに代わって、またはそれに加えて、本明細書に記載する仮想マシンアーキテクチャが他の状況において使用されることが理解される。
【０２６５】
図２９は、仮想マシン２９０２の例示的な実現の操作環境を示す図である。図２９に示すように、一実施形態において、仮想マシン２９０２は、そのホスト環境２９０４の状況の中で実行する。ホスト環境２９０４は、プログラム２９０６を実行する際に、仮想マシンによって必要とされる機能の一部を実現する。一般に、制御ＶＭは、ホスト環境を実現するＤＲＭエンジン２９０８の中で実行する。図２９に示すように、好ましいデータベースにおいて、仮想マシン２９０２およびＤＲＭエンジン２９０８は、状態情報の持続的な記憶のための安全なデータベース２９１０にアクセスする。
【０２６６】
１．２２．アーキテクチャ
１．２２．１．実行モデル
好ましい実施形態において、ＶＭは、コードモジュールにおいてバイトコードで格納される命令を実行することによって、プログラムを実行する。これらの命令の一部は、システムコールを行うことによって、プログラム自体の外で実現される機能を呼び出すことができる。システムコールは、ＶＭ自体によって実現、またはホスト環境に委託することができる。
【０２６７】
一実施形態において、ＶＭは、コードモジュールに格納される命令を、メモリにロードされるバイトコードのストリームとして実行する。ＶＭは、プログラムカウンタ（ＰＣ）と呼ばれる仮想レジスタを保守する。プログラムカウンタは、命令が実行される際に増加させられる。ＶＭは、ＯＰ ＳＴＯＰ命令に遭遇するまで、空の呼出しスタックがＯＰ ＲＥＴ命令に遭遇するまで、または実行時例外が生じるまで、各命令を順番に実行する。ジャンプは、相対的なジャンプ（ＰＣの現在値からのバイトオフセットとして指定される）として、または絶対アドレスとして指定される。
【０２６８】
１．２２．２．メモリモデル
一実施形態において、ＶＭは、比較的に単純なメモリモデルを使用し、メモリは、データメモリおよびコードメモリに分けられる。例えば、データメモリは、アドレス０から始まる単一の平坦な隣接するメモリ空間として実現でき、さらにホストアプリケーションまたはホスト環境のヒープメモリの中で割り当てられるバイトのアレイとして実現できる。一実施形態において、割り当てられた空間外のメモリへのアクセスを試みると、実行時例外が生じ、プログラムの実行が終了する。
【０２６９】
データメモリは、仮想マシンによって同時にロードされるいくつかのコードモジュールによって潜在的に共有される。データメモリにおけるデータは、メモリアクセス命令によってアクセスすることができ、そのアクセスは、一実施形態において、３２ビットまたは８ビットのアクセスであり得る。３２ビットメモリアクセスは、ビッグエンディアンバイト順を使用して実行される。好ましい実施形態において、仮想マシンから見えるメモリとホストに管理されるメモリとの間のアラインメントに関して（すなわちホストＣＰＵの仮想メモリまたは物理メモリ）、前提条件は作られない。
【０２７０】
一実施形態において、コードメモリは、アドレス０から始まる平坦な隣接するメモリ空間であり、ホストアプリケーションまたはホスト環境のヒープメモリの中で割り当てられるバイトのアレイとして実現できる。
【０２７１】
ＶＭは、複数のコードモジュールをロードすることをサポートしてもよい。ＶＭが、いくつかのコードモジュールをロードする場合、一実施形態において、すべてのコードモジュールは同一のデータメモリを共有する（但し、各モジュールのデータは、好ましくは異なるアドレスにおいてロードされる）。しかし、各々はそれ自身のコードメモリを有するので、１つのコードモジュールにおけるジャンプ命令が別のコードモジュールにおけるコードへのジャンプを引き起こすことを防止する。
【０２７２】
１．２２．３．データスタック
一実施形態において、ＶＭは、データメモリに格納される３２ビットデータセルを表すデータスタックの概念を有する。ＶＭは、スタックポインタ（ＳＰ）と呼ばれる仮想レジスタを保守する。再設定の後、ＳＰは、データメモリの終わりを指し示し、スタックは、下方に増大する（データがデータスタック上にプッシュされると、ＳＰレジスタは減少させられる）。スタック上の３２ビットデータセルは、スタックデータを参照する命令に依存して、３２ビットアドレスまたは３２ビット整数として解釈される。アドレスは、符号のない整数である。一実施形態において、データスタック上の他の全ての３２ビット整数値は、特に明記しない限り、符号付き整数として解釈される。
【０２７３】
１．２２．４．コールスタック
一実施形態において、ＶＭは、サブルーチン呼出しを行うために使用される呼出しスタックを管理する。一実施形態において、このスタック上にプッシュされる値は、メモリアクセス命令によって直接に読み込まれたり書き込まれたりすることができない。このスタックは、ＯＰ ＪＳＲ命令、ＯＰ ＪＳＲＲ命令、およびＯＰ ＲＥＴ命令を実行するときに、ＶＭによって内部的に使用される。所与のＶＭインプリメンテーションについて、このリターンアドレススタックのサイズは、最大に固定することができる。このことは、一定回数のみの入れ子の呼び出しを可能にする。
【０２７４】
１．２２．５．擬似レジスタ
一実施形態において、ＶＭは、データメモリの始めにおいて小さいアドレス空間を確保することによって、擬似レジスタをマッピングする。一実施形態において、これらの擬似レジスタのアドレスは固定される。例えば、以下のレジスタを規定することができる。
【表１４】
2009512096.tif 000016
【０２７５】
１．２２．６．メモリマップ
以下は、例示的実施形態におけるデータメモリおよびコードメモリのレイアウトを示すものである。
【０２７６】
データメモリ
【表１５】
2009512096.tif 000017
【０２７７】
コードメモリ
【表１６】
2009512096.tif 000018
【０２７８】
１．２２．７．ルーチンの実行
一実施形態において、仮想マシンインプリメンテーションは、コードルーチンを実行する前に、データスタックポインタが初期化済データスタックの最上部を指し示すようにリセットする。初期化済データスタックは、ルーチンの入力データを含み、データメモリの終わりまで拡張する。初期化済データスタックは、ルーチンに入力引数を渡す方法として使用されてもよい。初期化済データスタックがない場合、データスタックポインタは、データメモリの終わりを指し示す。一実施形態において、初期呼出しスタックは、空であるか、またはＯＰ ＳＴＯＰ命令を指し示す単一のターミナルリターンアドレスを含む。このことは、ルーチンがＯＰ ＲＥＴ命令によって終わった場合に、ルーチンの実行をＯＰ ＳＴＯＰ命令上で強制終了させる。
【０２７９】
実行が停止する場合、空の呼出しスタックを有する最終的なＯＰ ＲＥＴ命令が実行されたか、または最終的なＯＰ ＳＴＯＰ命令が実行されたために、データスタックに残された任意のデータはルーチンの出力であるとみなされる。
【０２８０】
１．２２．８．実行時例外
一実施形態において、以下の条件のいずれかは、実行時例外であるとみなされ、実行を直ちに停止させる。
・カレントデータメモリアドレス空間の外のデータメモリに対するアクセスの試み。
・ＰＣがカレントコードメモリアドレス空間の外のコードアドレスに到達するように、ＰＣを設定する試み。
・未定義バイトコードを実行する試み。
・０に等しいスタック最上部オペランドを有するＯＰ ＤＩＶ命令を実行する試み。
・０に等しいスタック最上部オペランドを有するＯＰ ＭＯＤ命令を実行する試み。
・コールスタックのオーバーフローまたはアンダーフロー。
【０２８１】
１．２３．命令セット
一実施形態において、制御ＶＭは、比較的に単純な命令セットを使用する。限定されてはいるものの、命令の数は、任意の複雑さのあるプログラムを表現するのに十分である。命令およびそのオペランドは、バイトコードのストリームによって表される。一実施形態において、命令セットはスタックベースであり、ＯＰ ＰＵＳＨ命令を除いて、直接オペランドを有する命令はない。オペランドはデータスタックから読み出され、結果はデータスタック上にプッシュされる。一実施形態において、ＶＭは、３２ビットＶＭである。すべての命令は、３２ビットスタックオペランド上で動作し、メモリーアドレスまたは符号付き整数を表す。符号付き整数は、２ｓコンプリメント２進コード化によって表される。
制御ＶＭとともに用いる命令セットの例示的実施形態を、以下の表に示す。表において、２つのオペランドを有する命令のためのスタックオペランドは、「Ａ，Ｂ」として記載され、スタックの最上部のオペランドは、最後に記載される（すなわち「Ｂ」）。特に明記しない限り、１つの例示的実施形態の以下の記載において用いられる「プッシュ」という用語は、データスタックの最上部に３２ビット値をプッシュすることを指す。
【表１７】
2009512096.tif 000019
【表１８】
2009512096.tif 000020
【０２８２】
１．２４．コードモジュール
好ましい実施形態において、コードモジュールは、ＭＰＥＧ―４ファイルフォーマット用に使用されるものと類似または同一のアトムベースのフォーマットで格納される。アトムが含むものは、３２ビットサイズ（例えばビッグエンディアンバイト順の４バイトによって表される）、次に４バイトタイプ（例えばアルファベット文字のＡＳＣＩＩ値に対応するバイト）、次にペイロード（例えば８バイト）である。
【０２８３】
図３０は、例示的なコードモジュール３０００のフォーマットを示す。図３０を参照して、ｐｋＣＭアトム３００２は、トップレベルのコードモジュールアトムである。それは、一連のサブアトムを含む。一実施形態において、ｐｋＣＭアトム３００２は、１つのｐｋＤＳアトム３００４、１つのｐｋＣＳアトム３００６、１つのｐｋＥＸアトム３００８、および場合によっては１つのｐｋＲＱアトム３０１０を含む。一実施形態において、ｐｋＣＭアトム３００２はまた、無視されるいかなる数の他のアトム（存在する場合）を含んでもよい。一実施形態において、サブアトムの順序は指定されないので、インプリメンテーションは特定の順序を仮定するべきでない。
【０２８４】
１．２４．１．ｐｋＤＳアトム
図３０に示すように、ｐｋＤＳアトム３００４は、データメモリにロードできるデータセグメントのメモリイメージ３００５を含む。図３１Ａに示すように、一実施形態において、メモリイメージ３００５は、バイト列３１１２によって表され、１つのヘッダバイト３１１４と、それに続く０以上のデータバイト３１１６とからなる。ヘッダバイト３１１４は、３１１６に続くバイトのフォーマットを識別するバージョンナンバをコード化する。
【０２８５】
一実施形態において、１つのみのバージョンナンバが規定され（すなわち、ＤａｔａＳｅｇｍｅｎｔＦｏｒｍａｔＶｅｒｓｉｏｎ＝０）、このフォーマットにおいて、メモリイメージのデータバイトは、メモリにロードされる生画像を表す。仮想マシンローダは、メモリイメージ３１０５のデータバイト３１１６のみをロードする（ヘッダバイト３１１４を含まない）。一実施形態において、仮想マシンローダは、任意の他のフォーマットのイメージをロードすることを拒絶するように操作可能である。
【０２８６】
１．２４．２．ｐｋＣＳアトム
図３０に示すように、ｐｋＣＳアトム３００６は、コードメモリにロードできるコードセグメントのメモリイメージ３００７を含む。図３１Ｂに示すように、一実施形態において、メモリイメージ３００７は、バイト列３１２０によって表され、１つのヘッダバイト３１２２と、それに続く０以上のデータバイト３１２４とからなる。ヘッダバイト３１２２は、３１２４に続くバイトのフォーマットを識別するバージョンナンバをコード化する。
【０２８７】
一実施形態において、１つのみのバージョンナンバが規定され（すなわちＣｏｄｅＳｅｇｍｅｎｔＦｏｒｍａｔＶｅｒｓｉｏｎ＝０）、図３１Ｃに示すように、このバージョンにおいて、ヘッダバイト３１２２に続くバイトは、別のヘッダバイト３１３０を含み、ヘッダバイト３１３０は、次のバイト３１３２のバイトコードのコード化を識別するバージョンナンバを含む。図３１Ｃに示す実施例において、ヘッダバイト３１３０は、ＢｙｔｅＣｏｄｅＶｅｒｓｉｏｎ＝０を識別する。このことは、データバイト３１３２が上記の例示的命令セットで規定されるようなバイトコード値を有する生バイト列を含むということを指定する。好ましい実施形態において、仮想マシンローダは、２つのヘッダバイト３１２２および３１３０ではなく、データバイトのバイトコード部分３１３２のみをロードする。
【０２８８】
１．２４．３．ｐｋＥＸアトム
図３０を再び参照して、ｐｋＥＸアトム３００８は、エクスポートエントリのリストを含む。図３０において示す実施例において、ｐｋＥＸアトム３００８の最初の４つのバイト３００９は、次のエントリの数に等しいビッグエンディアンバイト順に、３２ビット符号のない整数をコード化する。図３１Ｄに示すように、次の各エクスポートエントリ３１６０は、名前（名前サイズＳを含む１つのバイト３１６２としてコード化される）と、それに続くＳバイト３１６４（名前のＡＳＣＩＩ文字を含む）（終了するゼロ３１６６を含む）と、それに続くビッグエンディアンバイト順の３２ビットの符号のない整数３１６８とからなり、それは名前付きエントリポイントのバイトオフセットを表し、３１ＣＳアトムに格納されるバイトコードデータの開始から測定される。図３１Ｅは、オフセット６４におけるエントリポイントＭＡＩＮのためのエクスポートテーブルエントリ３１７０の例を示す。ここで、第１バイト３１７２は、名前（すなわち「ＭＡＩＮ」）のサイズに終了するゼロを加えたものが、５バイトであることを示す。さらに、最後の４つのバイト３１７４は、バイトオフセットが６４であることを示す。
【０２８９】
１．２４．４．ｐｋＲＱアトム
図３０に示すように、ｐｋＲＱアトム３０１０は、コードモジュールにおけるコードを実行するために仮想マシンインプリメンテーションが満たす必要のある必要条件を含む。一実施形態において、このアトムは任意であり、これが存在しない場合、仮想マシンは、インプリメンテーションプロファイルによって規定されるような、デフォルトのインプリメンテーション設定を使用する。
【０２９０】
一実施形態において、ｐｋＲＱアトムは、３２ビットの符号のない整数値のアレイからなる（フィールドごとに１つ）。
【表１９】
2009512096.tif 000021
【０２９１】
１．２４．５．モジュールローダ
仮想マシンは、コードモジュールをロードすることを担う。コードモジュールがロードされるときに、ｐｋＤＳアトムにおいてコード化されたデータセグメントメモリイメージが、メモリーアドレスにおいてデータメモリにロードされる。そのアドレスは、ＶＭローダによって選択され、コードの実行時にＤＳ疑似レジスタに格納される。
【０２９２】
ｐｋＣＳアトムにおいてコード化されたコードセグメントメモリイメージは、メモリーアドレスにおいてコードメモリにロードされる。そのアドレスは、ＶＭローダによって選択され、コードの実行時に、ＣＳ疑似レジスタに格納される。
【０２９３】
コードモジュールがロードされるときに、「Ｇｌｏｂａｌ。ＯｎＬｏａｄ」という名前の特別ルーチンが、エクスポートテーブルのエントリに見いだされる場合には実行される。このルーチンは、スタック上の引数を受け取らず、成功を示すリターン０における整数状態、およびエラー条件を示すマイナスのエラーコードを戻す。
【０２９４】
コードモジュールがアンロードされるとき（または、モジュールをロードした仮想マシンが処理されるとき）に、「Ｇｌｏｂａｌ．ＯｎＵｎｌｏａｄ」という名前の特別ルーチンが、エクスポートテーブルに見いだされる場合には実行される。このルーチンは、スタック上の引数を受け取らず、成功を示すリターン０における整数状態、およびエラー条件を示すマイナスのエラーコードを戻す。
【０２９５】
１．２５．システムコール
仮想マシンのプログラムは、それらのコードモジュールのコードセグメントの外で実現される機能を呼び出すことができる。このことは、呼び出すシステムコール番号を指定する整数スタックオペランドを受け取る、ＯＰ ＣＡＬＬ命令を用いることによってなされる。システムコールを依存して、インプリメンテーションは、異なるコードモジュールにおけるバイトコードルーチン（例えば効用関数のライブラリ）であり得、それはＶＭのネイティブのインプリメンテーションフォーマットにおけるＶＭによって直接に実行されるか、または外部ソフトウェアモジュール（例えばＶＭのホスト環境）に委託される。
【０２９６】
一実施形態において、ＯＰ ＣＡＬＬ命令が任意のシステムコールに対応しない数を含むオペランドによって実行される場合、ＶＭは、あたかもＳＹＳ ＮＯＰシステムコールが呼び出されたかのように機能する。
【０２９７】
１．２５．１．システムコール番号アロケーション
論ずる例示的実施形態において、システムコール番号０〜１０２３は、固定されたシステムコール（これらのシステムコールはすべてのＶＭインプリメンテーション上で同数を有する）のために確保される。システムコール番号１０２４〜１６３８３は、ＶＭが動的に割り当てるように利用可能である（例えば、Ｓｙｓｔｅｍ．ＦｉｎｄＳｙｓｔｅｍＣａｌｌＢｙＮａｍｅによって返されるシステムコール番号は、ＶＭによって動的に割り当てられることができ、すべてのＶＭインプリメンテーション上で同数である必要はない）。
【０２９８】
１つの例示的実施形態において、以下の固定されたシステムコール番号が指定される。
【表２０】
2009512096.tif 000022
【０２９９】
１．２５．２．標準システムコール
一実施形態において、制御プログラムに書き込むために有用な多少の標準システムコールがサポートされる。これらの呼び出しは、上記の表に記載される固定数システムコール、ならびに動的に決定される数を有するシステムコールを含む（すなわち、それらのシステムコール番号は、引数として渡される名前を用いてＳｙｓｔｅｍ．ＦｉｎｄＳｙｓｔｅｍＣａｌｌＢｙＮａｍｅを呼び出すことによって検索される）。
【０３００】
一実施形態において、このセクションにおいて指定されるシステムコールは、マイナスのエラーコードを返すことができ、任意の負の数を有するエラーコードを返してもよい。
セクション８．４．４は、特定の例示的な値を規定する。一実施形態において、所定でないマイナスのエラーコード値が戻される場合、それらは、あたかも一般的なエラーコード値ＦＡＩＬＵＲＥであるかのように解釈される。
【０３０１】
Ｓｙｓｔｅｍ．ＮｏＯｐｅｒａｔｉｏｎ。この呼び出しは、入力を受け取らず、出力を返さず、何もせずに単に戻る。それは、主にＶＭを検証するために使用される。
【０３０２】
Ｓｙｓｔｅｍ．ＤｅｂｕｇＰｒｉｎｔ。この呼び出しは、ヌル終了文字列を含むメモリーロケーションのアドレスを、スタックの最上部から、その入力として受け取り、出力を返さない。この機能に対する呼び出しによって、テキストのストリングが、デバッグ出力に印刷させられる。このことは、デバッグにおいて有用であり得る。ＶＭインプリメンテーションが、デバッグテキストを出力する機能を含まない場合（例えば非開発環境の場合がそうである）、ＶＭは、呼び出しを無視し、あたかもＳｙｓｔｅｍ．ＮｏＯｐｅｒａｔｉｏｎが呼び出されたかのようにそれを処理してもよい。
【０３０３】
Ｓｙｓｔｅｍ．ＦｉｎｄＳｙｓｔｅｍＣａｌｌＢｙＮａｍｅ。この呼び出しは、名前を与えられるシステムコールの数を見いだす。この呼び出しは、探すシステムコールの名前を含むヌル終了ＡＳＣＩＩストリングのアドレスを、その入力として（スタックの最上部から）受け取り、システムコール数（指定名を有するシステムコールが実現される場合）、ＥＲＲＯＲ ＮＯ ＳＵＣＨ ＩＴＥＭ（システムコールが実現されない場合）、およびマイナスのエラーコード（エラーが生じる場合）を（スタックの最上部に）返す。
【０３０４】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＬｏｃａｌＴｉｍｅ。この呼び出しは、入力を受け取らず、一実施形態において、１９７０年１月１日００：００：００から経過した分数に等しい３２ビット符号付き整数として表現されるホストのローカルタイムの現在の値、またはマイナスのエラーコードを、スタックの最上部へ返す。
【０３０５】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＬｏｃａｌＴｉｍｅＯｆｆｓｅｔ。この呼び出しは、入力を受け取らず、ホストの現在の時間オフセット（ＵＴＣ時間からの）をスタックの最上部に返す。この時間オフセットは、一実施形態において、ローカルタイムとＵＴＣ時間（すなわちＬｏｃａｌＴｉｍｅ―ＵＴＣ）との間の差分の分数に等しい３２ビット符号付き整数として表現される。
【０３０６】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＴｒｕｓｔｅｄＴｉｍｅ。この呼び出しは、入力を受け取らず、信頼された時間および１つ以上のフラグの値をスタックの最上部に返す。一実施形態において、信頼された時間は、信頼されたタイムクロックの現在の値（システムがそのような信頼されたクロックを含む場合）、またはマイナスのエラーコード（信頼された時間が利用可能でない場合）である。一実施形態において、信頼された時間の値は、１９７０年１月１日００：００：００ＵＴＣから経過した分数に等しい３２ビット符号付き整数、またはマイナスのエラーコードとして表現される。一実施形態において、フラグは、信頼されたクロックの現在の状態を更に規定するフラグのビットセットである。一実施形態において、エラーが生じた場合（例えばＴｒｕｓｔｅｄＴｉｍｅの値がマイナスのエラーコードである場合）、フラグのために戻される値は、０である。
【０３０７】
一実施形態において、以下のフラグが規定される。
【表２１】
2009512096.tif 000023
【０３０８】
このシステムコールは、信頼された時間ソースと同期可能で、かつ単調なタイムカウンタを保守可能な、信頼されたクロックを実現するシステムに関連する。信頼された時間の値は、常に正確であることを保証されないが、一実施形態において、以下の特性が真実である必要がある。
・信頼された時間の値は、ＵＴＣ時間値として表現される（現在の場所を確実に決定することはできないので、信頼された時間は、ローカルタイムゾーンの中にはない）。
・信頼された時間は、決して逆行しない。
・信頼されたクロックは、リアルタイムより速く進むことはない。
【０３０９】
従って、この例示的実施形態において、ＴｒｕｓｔｅｄＴｉｍｅの値は、最後の同期時間（信頼された時間ソースによって同期させられる）の値と、現在のリアルタイムとの間にある。信頼された時間ソースによる最後の同期以来、信頼されたクロックが連続的に正常に間断なく動作および更新をしている、ということをシステムが決定できる場合、システムは、ＴｒｕｓｔｅｄＴｉｍｅの値が推定ではなく正確な値であるということを決定し、ＴＩＭＥ ＩＳ ＥＳＴＩＭＡＴＥフラグを０に設定することができる。
【０３１０】
一実施形態において、信頼されたクロックが、ハードウェアまたはソフトウェアの障害状態が生じたことを検出し、信頼された時間の推定を返すことさえできない場合、エラーコードが返され、返されたフラグの値は０に設定される。
【０３１１】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔ。このシステムコールは、仮想マシンのホストによって提供されるオブジェクトにプログラムがアクセスすることを可能にする、一般的なインタフェースである。Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔ呼び出しは、以下の入力を受け取る。すなわち、Ｐａｒｅｎｔ、Ｎａｍｅ、ＲｅｔｕｒｎＢｕｆｆｅｒ、およびＲｅｔｕｒｎＢｕｆｆｅｒＳｉｚｅである（スタックの最上部から下に向かって記述される）。「Ｐａｒｅｎｔ」は、親コンテナの３２ビットハンドルである。「Ｎａｍｅ」は、（親コンテナに対して）リクエストされるオブジェクトへの経路を含むヌル終了文字列のアドレスである。「ＲｅｔｕｒｎＢｕｆｆｅｒ」は、オブジェクトの値が格納されるメモリバッファのアドレスである。「ＲｅｔｕｒｎＢｕｆｆｅｒＳｉｚｅ」は、オブジェクトの値が格納されるメモリバッファのバイトのサイズを示す３２ビット整数である。
【０３１２】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔ呼び出しは、ＴｙｐｅＩＤおよびＳｉｚｅの出力を生成する（スタックの最上部から下に向かって記述される）。「ＴｙｐｅＩｄ」は、オブジェクトタイプＩＤ、または呼び出しができない場合はマイナスのエラーコードである。要求オブジェクトが存在しない場合、返されるエラーは、ＥＲＲＯＲ ＮＯ ＳＵＣＨ ＩＴＥＭである。リターン値に供給されるバッファがあまりに小さい場合、返されるエラーは、ＥＲＲＯＲ ＩＮＳ（登録商標）ＵＦＦＩＣＩＥＮＴ ＳＰＡＣＥである。アクセスされているオブジェクトツリーの部分がアクセスによって制御される場合、呼出しプログラムはオブジェクトにアクセスする許可を有せず、ＥＲＲＯＲ ＰＥＲＭＩＳＳＩＯＮ ＤＥＮＩＥＤが返される。他のエラーコードが返される場合もある。「Ｓｉｚｅ」は、呼出し元によって出力されるバッファにおいて返されるデータのバイトのサイズ、または呼出し元があまりに小さいバッファを提供した場合に必要なサイズを示す、３２ビット整数である。
【０３１３】
一実施形態において、４つのタイプのホストオブジェクト（ストリング、整数、バイト列、およびコンテナ）がある。
【表２２】
2009512096.tif 000024
【０３１４】
一実施形態において、バイト列オブジェクトの値は、８ビットバイトのアレイであり、ストリングオブジェクトの値は、ＵＴＦ−８においてコード化されるヌル終了文字列であり、整数オブジェクトの値は、３２ビット符号付き整数値である。コンテナは、タイプの任意の組み合わせのオブジェクトの一連の任意の数を含む、一般的なコンテナである。コンテナに含まれるオブジェクトは、そのコンテナの子と呼ばれる。コンテナの値は、所与のＶＭインスタンスの中で一意の３２ビットコンテナハンドルである。一実施形態において、ルートコンテナ「／」は、固定されたハンドル値０を有する。
【０３１５】
一実施形態において、ホストオブジェクトのための名前空間は階層的であり、コンテナの子オブジェクトの名前は、親コンテナの名前に子の名前を追加することによって構成され、これらは「／」キャラクタによって分けられる。ストリングおよび整数オブジェクトは、子を有しない。例えば、コンテナが「／Ｎｏｄｅ／Ａｔｔｒｉｂｕｔｅｓ」という名前であり、かつ「Ｔｙｐｅ」という名前のストリング子を有する場合、『／Ｎｏｄｅ／Ａｔｔｒｉｂｕｔｅｓ／Ｔｙｐｅ』は、子ストリングを指す。
【０３１６】
名前空間のルートは、「／」である。ＡＵ絶対名は、「／」で開始する。「／」で開始しない名前は、関係名である。関係名は、親コンテナに関連する。例えば、親「／Ｎｏｄｅ」に関連する名前「Ａｔｔｒｉｂｕｔｅｓ／Ｔｙｐｅ」は、絶対名「／Ｎｏｄｅ／Ａｔｔｒｉｂｕｔｅｓ／Ｔｙｐｅ」を有するオブジェクトである。
【０３１７】
一実施形態において、コンテナオブジェクトはまた、仮想名を使用することによってアクセスされる現実および仮想の子オブジェクトを有することができる。仮想名は、ホストオブジェクトに添付されない名前であるが、名前なし子オブジェクト、異なる名前を有する子オブジェクト、または仮想子オブジェクト（コンテナの現実の子ではなく、リクエストされるときに動的に作成される子オブジェクト）を識別する規則である。
【０３１８】
一実施形態において、オブジェクトのために、以下の仮想名が、仮想子オブジェクト名として規定される。
【表２３】
2009512096.tif 000025
【０３１９】
一実施形態において、コンテナのために、以下の仮想名が、仮想子オブジェクト名として規定される。
【表２４】
2009512096.tif 000026
【０３２０】
実施例
【０３２１】
以下の表は、ホストオブジェクトの階層の実施例を示す。
【表２５】
2009512096.tif 000027
【０３２２】
この実施例において、Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔ（親＝０、子＝「Ｎｏｄｅ）」）を呼び出すことによって、０のタイプＩＤ（すなわちコンテナ）が返され、１のハンドル値が、呼出し元によって出力されるバッファに書き込まれる。
値のサイズは、４バイトである。
【０３２３】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔ（親＝０、名前＝「Ｎｏｄｅ／Ａｔｔｒｉｂｕｔｅｓ／Ｄｏｍａｉｎ）」）を呼び出すことによって、２のタイプＩＤ（すなわちストリング）が返され、ストリング「ＴｏｐＬｅｖｅｌ」が、呼出し元によって出力されるバッファに書き込まれる。値のサイズは、９バイトである。
【０３２４】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔ（親＝１、名前＝「Ａｔｔｒｉｂｕｔｅｓ＠１」）を呼び出すことによって、１のタイプＩＤ（すなわち整数）が返され、整数７８が、呼出し元によって出力されるバッファに書き込まれる。値のサイズは、４バイトである。
【０３２５】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔ（親＝０、名前＝「ＤｏｅｓＮｏｔＥｘｉｓｔ）」）を呼び出すことによって、エラーコードＥＲＲＯＲ ＮＯ ＳＵＣＨ ＩＴＥＭが返される。
【０３２６】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔ。このシステムコールは、仮想マシンのホストによって提供されるオブジェクトを、プログラムが作成、書き込み、および抹消することを可能にする、一般的なインタフェースである。オブジェクト名およびタイプの記述は、上述したＳｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔ呼び出しと同一である。すべてのホストオブジェクトが、書き込みまたは抹消されることをサポートするわけではなく、すべてのコンテナが、子オブジェクトの作成をサポートするわけではない。ＳｅｔＯｂｊｅｃｔ呼び出しが、操作をサポートしないオブジェクトのために行われる場合、ＥＲＲＯＲ ＰＥＲＭＩＳＳＩＯＮ ＤＥＮＩＥＤが返される。
【０３２７】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔシステムコールは、以下のパラメータを入力として受け取る（スタックの最上部から下に向かって記述される）。
スタックの最上部：
【表２６】
2009512096.tif 000028
【０３２８】
Ｐａｒｅｎｔ：親コンテナの３２ビットハンドル。
【０３２９】
Ｎａｍｅ：（親コンテナに対して）オブジェクトへの経路を含むヌル終了文字列のアドレス。
【０３３０】
ＯｂｊｅｃｔＡｄｄｒｅｓｓ：オブジェクトの値が格納されるメモリバッファのアドレス。アドレスが０である場合、呼び出しは、オブジェクトを抹消するリクエストとして解釈される。アドレスにおけるデータは、オブジェクトのタイプに依存する。
【０３３１】
ＯｂｊｅｃｔＴｙｐｅ：オブジェクトのタイプＩＤ。
【０３３２】
ＯｂｊｅｃｔＳｉｚｅ：オブジェクトの値が格納されるメモリバッファのバイトのサイズを示す３２ビット整数。論ずる例示的実施形態において、サイズは、整数オブジェクトについては４に設定され、ストリングオブジェクトについては、ヌルターミネータを含むメモリバッファのサイズに設定される。バイト列オブジェクトについて、サイズは、アレイのバイト数である。
【０３３３】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔシステムコールは、出力として、ＲｅｓｕｌｔＣｏｄｅをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、呼び出しが成功した場合は０であり、呼び出しが失敗した場合はマイナスのエラーコードである。呼び出しがオブジェクトを抹消するリクエストであり、かつ要求オブジェクトが存在しない場合、あるいは呼び出しがオブジェクトを作成または書き込むリクエストであり、かつオブジェクトの親が存在しない場合、返されるエラーコードは、ＥＲＲＯＲ ＮＯ ＳＵＣＨ ＩＴＥＭである。アクセスされているオブジェクトツリーの部分がアクセスによって制御される場合、呼出しプログラムはオブジェクトにアクセスする許可を有せず、ＥＲＲＯＲ ＰＥＲＭＩＳＳＩＯＮ ＤＥＮＩＥＤが返される。他のエラーコードが返されてもよい。
【０３３４】
オブジェクトがコンテナを指し、かつＯｂｊｅｃｔＡｄｄｒｅｓｓが０でない、という特別な場合がある。この場合、ＯｂｊｅｃｔＳｉｚｅパラメータは０に設定され、ＯｂｊｅｃｔＡｄｄｒｅｓｓの値は無視される。コンテナがすでに存在する場合、何もなされず、ＳＵＣＣＥＳＳ  ＲｅｓｕｌｔＣｏｄｅが返される。コンテナが存在せず、かつコンテナの親が書き込み可能である場合、空のコンテナが作成される。
【０３３５】
Ｏｃｔｏｐｕｓ．Ｌｉｎｋｓ．ＩｓＮｏｄｅＲｅａｃｈａｂｌｅ。このシステムコールは、仮想マシンのこのインスタンスをホストするエンティティに関連するノードから所与のノードに到達可能か否かを照合するために、制御プログラムによって使用される。呼び出しは、その入力としてＮｏｄｅＩｄをスタックの最上部から受け取る。ＮｏｄｅＩｄは、到達可能性について検証されるターゲットノードのＩＤを含むヌル終了文字列である。出力として、呼び出しは、ＲｅｓｕｌｔＣｏｄｅおよびＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、ノードが到達可能である場合は０の整数値であり、そうではない場合はマイナスのエラーコードである。ＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒは、標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋのアドレスであり、状態ブロックが返されない場合は０である。
【０３３６】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＳｐａｗｎＶｍ。このシステムコールは、仮想マシンの新しいインスタンスを作成し、かつ新しいコードモジュールをロードする、ということをリクエストするために、制御プログラムによって使用される。一実施形態において、ホストオブジェクト「／Ｏｃｔｏｐｕｓ／Ｒｕｎｔｉｍｅ／Ｐａｒｅｎｔ／Ｉｄ」が呼出し元の識別に対して設定されることを除いて、新しく作成された仮想マシンのホストは、呼出し元にさらされたものと同じホストオブジェクトをさらす。一実施形態において、このホストオブジェクトは、コンテナである。このコンテナの子は、文字列型のオブジェクトであり、各々が名前を表す値を有する。一実施形態において、それらの名前のセマンティクスおよび具体的な詳細は、仮想マシンのホストの指定によって指定される。
【０３３７】
一実施形態において、呼出し元のためのコードを実行中の仮想マシンが終了する場合、Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＲｅｌｅａｓｅＶｍを呼び出すことによって明示的にリリースされなかった任意の生み出された仮想マシンは、あたかもＳｙｓｔｅｍ．Ｈｏｓｔ．ＲｅｌｅａｓｅＶｍが呼び出されたかのように、システムによって自動的にリリースされる。
【０３３８】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＳｐａｗｎＶｍ呼び出しは、その入力としてＭｏｄｕｌｅＩｄをスタックの最上部から受け取る。ＭｏｄｕｌｅＩｄは、新しい仮想マシンインスタンスにロードされるコードモジュールを識別する。一実施形態において、仮想マシンのホストの指定は、このモジュールＩＤに対応する実際のコードモジュールが位置づけられるメカニズムを記述する。
【０３３９】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＳｐａｗｎＶｍ呼び出しは、ＲｅｓｕｌｔＣｏｄｅおよびＶｍＨａｎｄｌｅをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、呼び出しが成功した場合は０の整数値であり、失敗した場合はマイナスのエラーコードである。ＶｍＨａｎｄｌｅは、作成された仮想マシンのインスタンスを識別する整数値である。呼び出しが失敗した場合、このハンドルは０に設定される。一実施形態において、このハンドルは、この呼び出しが行われる仮想マシンの範囲内で一意であることのみが保証される。
【０３４０】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＣａＩｌＶｍ。このシステムコールは、Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＳｐａｗｎＶｍシステムコールを使用して作成される仮想マシンインスタンスにロードされるコードモジュールにおいて実現されるルーチンを呼び出すために、制御プログラムによって使用される。このシステムコールは、スタックの最上部から以下の入力を受け取る。
スタックの最上部：
【表２７】
2009512096.tif 000029
【０３４１】
ＶｍＨａｎｄｌｅ：Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＳｐａｗｎＶｍを呼び出すことによって作成された仮想マシンのハンドルを表す整数値。
【０３４２】
ＥｎｔｒｙＰｏｉｎｔ：呼び出すエントリポイントの名前を指定するヌル終了文字列のアドレス。この名前は、ＶｍＨａｎｄｌｅパラメータに対応する仮想マシンインスタンスにロードされたコードモジュールのＥｘｐｏｒｔ  Ｔａｂｌｅのエントリポイントのうちの１つと一致する必要がある。
【０３４３】
ＰａｒａｍｅｔｅｒＢｌｏｃｋＡｄｄｒｅｓｓ：呼ばれる側に渡されるデータを含むメモリブロックのアドレス。呼ばれる側にパラメータが渡されない場合、このアドレスは０に設定される。
【０３４４】
ＰａｒａｍｅｔｅｒＢｌｏｃｋＳｉｚｅ：アドレスＰａｒａｍｅｔｅｒＢｌｏｃｋＡｄｄｒｅｓｓにおけるメモリブロックのバイトのサイズであり、ＰａｒａｍｅｔｅｒＢｌｏｃｋＡｄｄｒｅｓｓが０である場合は、これも０である。
【０３４５】
ＲｅｔｕｒｎＢｕｆｆｅｒＡｄｄｒｅｓｓ：呼出し元が呼ばれる側からデータを受信することができるメモリバッファのアドレス。呼出し元が呼ばれる側から任意のデータが戻されることを予想しない場合、このアドレスは０に設定される。
【０３４６】
ＲｅｔｕｒｎＢｕｆｆｅｒＳｉｚｅ：アドレスＲｅｔｕｒｎＢｕｆｆｅｒＡｄｄｒｅｓｓにおけるメモリバッファのバイトのサイズであり、ＲｅｔｕｒｎＢｕｆｆｅｒＡｄｄｒｅｓｓが０である場合は、これも０である。
【０３４７】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＣａＩｌＶｍ呼び出しは、以下の出力をスタックの最上部に返す。
スタックの最上部：
【表２８】
2009512096.tif 000030
【０３４８】
ＳｙｓｔｅｍＲｅｓｕｌｔＣｏｄｅ：呼び出しが成功した場合は０の整数値であり、失敗した場合はマイナスのエラーコードである。この値は、呼ばれる側によってではなく、システムによって決定される。成功は、システムが呼び出すルーチンを首尾よく見いだし、ルーチンを実行し、ルーチンからリターン値を獲得することができたことを示すのみである。ルーチン自体からのリターン値は、ＣａｌｌｅｅＲｅｓｕｌｔＣｏｄｅ値において返される。
【０３４９】
ＣａｌｌｅｅＲｅｓｕｌｔＣｏｄｅ：呼ばれる側によって返される整数値。
【０３５０】
ＲｅｔｕｒｎＢｌｏｃｋＳｉｚｅ：呼出し元によって出力されるバッファにおいて返されるデータのバイトのサイズ、または呼出し元があまりに小さいバッファを提供した場合に必要なサイズ。呼ばれる側によってデータが返されない場合、値は０である。
【０３５１】
論ずる例示的実施形態において、呼び出されるルーチンは、以下のインタフェース規則に従う。ルーチンが呼び出されるときに、スタックの最上部は、呼出し元によって出力される値ＰａｒａｍｅｔｅｒＢｌｏｃｋＳｉｚｅを含み、パラメータブロックのサイズを示し、その後にデータのＰａｒａｍｅｔｅｒＢｌｏｃｋＳｉｚｅバイトが続く。サイズが４の倍数でない場合、スタック上のデータをゼロによってパッドすることによって、スタックポインタが４の倍数であることが確実にされる。リターンの際に、呼び出されるルーチンは、以下のリターン値をスタック上に提供する。
スタックの最上部：
【表２９】
2009512096.tif 000031
【０３５２】
ＲｅｔｕｒｎＢｌｏｃｋＡｄｄｒｅｓｓ：呼出し元に返されるデータを含むメモリブロックのアドレス。データが返されない場合、このアドレスは０に設定される。
【０３５３】
ＲｅｔｕｒｎＢｌｏｃｋＳｉｚｅ：アドレスＲｅｔｕｒｎＢｌｏｃｋＡｄｄｒｅｓｓにおけるメモリブロックのバイトのサイズであり、ＲｅｔｕｒｎＢｌｏｃｋＡｄｄｒｅｓｓが０である場合は、これも０である。
【０３５４】
Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＲｅｌｅａｓｅＶｍ：このシステムコールは、Ｓｙｓｔｅｍ．Ｈｏｓｔ．Ｓｐａｗｎ  Ｖｍに対する以前の呼び出しによって生み出された仮想マシンをリリースするために、制御プログラムによって使用される。リリースされた仮想マシンによって生み出される任意の仮想マシンは、再帰的にリリースなどされる。Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＲｅｌｅａｓｅＶｍ呼び出しは、その入力としてＶｍＨａｎｄｌｅをスタックの最上部から受け取る。ＶｍＨａｎｄｌｅは、Ｓｙｓｔｅｍ．Ｈｏｓｔ．Ｓｐａｗｎ  Ｖｍを呼び出すことによって作成された仮想マシンのハンドルを表す。Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＲｅｌｅａｓｅＶｍ呼び出しは、出力として、ＲｅｓｕｌｔＣｏｄｅをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、呼び出しが成功した場合は０の整数値であり、失敗した場合はマイナスのエラーコードである。
【０３５５】
１．２５．３．標準データ構造
以下は、標準システムコールの一部によって使用される標準データ構造である。
【０３５６】
１．２５．３．１．標準パラメータ
ＰａｒａｍｅｔｅｒＢｌｏｃｋ：
【表３０】
2009512096.tif 000032
【０３５７】
Ｎａｍｅ：パラメータの名前。
【０３５８】
Ｖａｌｕｅ：パラメータの値。
【０３５９】
ＥｘｔｅｎｄｅｄＰａｒａｍｅｔｅｒＢｌｏｃｋ：
【表３１】
2009512096.tif 000033
【０３６０】
Ｆｌａｇｓ：ブーリアンフラグのベクトル。
【０３６１】
Ｐａｒａｍｅｔｅｒ名前および値を含パラメータブロック。
【０３６２】
ＮａｍｅＢｌｏｃｋ：
【表３２】
2009512096.tif 000034
【０３６３】
Ｓｉｚｅ：それに続く「キャラクタ」フィールドのバイトのサイズに等しい３２ビットの符号のない整数。この値が０である場合、キャラクタフィールドは、空のままにされる（すなわち何も続かない）。
【０３６４】
Ｃｈａｒａｃｔｅｒｓ：ヌル終了ＵＴＦ―８ストリング。
【０３６５】
ＶａｌｕｅＢｌｏｃｋ：
【表３３】
2009512096.tif 000035
【０３６６】
Ｔｙｐｅ：３２ビットタイプ識別子。一実施形態において、以下のタイプが規定される。
【表３４】
2009512096.tif 000036
【０３６７】
Ｓｉｚｅ：それに続く「データ」フィールドのバイトのサイズに等しい３２ビットの符号のない整数。この値が０である場合、データフィールドは、空のままにされる（すなわちＶａｌｕｅＢｌｏｃｋにおけるサイズフィールドの後には何も続かない）。
【０３６８】
Ｄａｔａ：値を表す８ビットバイトのアレイ。実際のバイトは、タイプフィールドによって指定されるデータのコード化に依存する。
【０３６９】
ＶａｌｕｅＬｉｓｔＢｌｏｃｋ：
【表３５】
2009512096.tif 000037
【０３７０】
ＶａｌｕｅＣｏｕｎｔ：それに続くＶａｌｕｅＢｌｏｃｋ構造の数に等しい３２ビットの符号のない整数。この値が０である場合、この後にＶａｌｕｅＢｌｏｃｋｓは続かない。
【０３７１】
Ｖａｌｕｅ０、Ｖａｌｕｅ１、…：０以上のＶａｌｕｅＢｌｏｃｋ構造のシーケンス。
【０３７２】
１．２５．３．２．標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓ
標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋは、呼び出しからルーチンまたはシステムコールへの戻りステータスとして拡張情報を伝達するために一般に使用されるデータ構造である。これは、フィールドのための異なる可能な値の範囲内で、様々な状況において使用できる一般的なデータ構造である。一実施形態において、ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋは、以下のように規定される。
【０３７３】
ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋ：
【表３６】
2009512096.tif 000038
【０３７４】
ＧｌｏｂａｌＦｌａｇｓ：カテゴリーフィールドに関係なくセマンティクスが同一であるブーリアンフラグ。フラグの位置および意味は、標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋデータ構造を使用するプロファイルによって規定される。
【０３７５】
Ｃａｔｅｇｏｒｙ：この状態が帰属するカテゴリの一意な整数識別子。カテゴリ識別子値は、標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋデータ構造を使用するプロファイルによって規定される。
【０３７６】
ＳｕｂＣａｔｅｇｏｒｙ：このブロックによって記述される状態のタイプを更に分類するサブカテゴリの整数識別子（カテゴリの範囲内で一意である）。
【０３７７】
ＬｏｃａｌＦｌａｇｓ：この状態ブロックのカテゴリおよびサブカテゴリに対してセマンティクスがローカルであるブーリアンフラグ。フラグの位置および意味は、カテゴリのセマンティクスを規定および使用するプロファイルによって規定される。
【０３７８】
ＣａｃｈｅＤｕｒａｔｉｏｎ：この状態をキャッシュに格納できる（すなわち有効な状態を維持する）持続時間を示す。持続時間の実効値が規定される方法については、下記のＣａｃｈｅＤｕｒａｔｉｏｎＢｌｏｃｋタイプの定義を参照されたい。
【０３７９】
Ｐａｒａｍｅｔｅｒｓ：０以上のＶａｌｕｅＢｌｏｃｋのリスト。各ＶａｌｕｅＢｌｏｃｋは、タイプＰａｒａｍｅｔｅｒまたはＥｘｔｅｎｄｅｄＰａｒａｍｅｔｅｒの値としてコード化されるパラメータを含む。各パラメータは、入力された値に名前を結合し、柔軟な可変データをコード化するために使用する。この可変データは、単なるカテゴリ、サブカテゴリ、キャッシュ持続時間、およびフラグよりも詳細に、状態ブロックを記述する。
【０３８０】
ＣａｃｈｅＤｕｒａｔｉｏｎＢｌｏｃｋ：
【表３７】
2009512096.tif 000039
【０３８１】
Ｔｙｐｅ：値のタイプのための整数識別子。一実施形態において、以下のタイプが規定される。
【表３８】
2009512096.tif 000040
【０３８２】
Ｖａｌｕｅ：３２ビット整数。その意味はＴｙｐｅフィールドに依存する。
【０３８３】
１．２５．４．標準結果コード
標準結果コードは、様々なＡＰＩにおいて使用される。
【表３９】
2009512096.tif 000041
【０３８４】
１．２６．アセンブラシンタックス
このセクションは、本明細書の他の場所に記載するバイトコードフォーマットにプログラムをコンパイルするために使用する例示的なシンタックスを記載する。これは１つの可能なシンタックスの一実施例であり、任意の適切なシンタックスを使用できることが理解されるべきである。前述のように、本明細書に示すバイトコードフォーマットは、単なる実施例であり、本明細書に記載するシステムおよび方法は、他の任意の適切なバイトコードフォーマットまたは他のコードフォーマットとともに使用できることも理解されるべきである。
【０３８５】
アセンブラは、コード、データ、および処理命令を含むソースファイルを読み取り、制御仮想マシンによってロード可能な２進コードモジュールを生成する。１つの例示的実施形態において、アセンブラは、ソースファイルを一行ごとに順次処理する。行は、０以上のキャラクタであり得、その後に改行が続く。各行は、空行（空白文字のみ）、セグメント指令、データ指令、アセンブラ指令、コード命令、ラベル、またはエクスポート指令のうちの１つであり得る。それに加えて、各行は、コメントで終了してもよい。コメントは、「；」キャラクタによって開始し、行の終わりまで続く。
【０３８６】
ソースファイルから読み取られるデータおよび命令は、暗黙のデスティネーションセグメントを有する（すなわちＶＭによってロードされるときに終了する場合）。構文解析プロセスの任意の点において、アセンブラは、データおよび命令のための暗黙のデスティネーションセグメントである「カレント」セグメントを有する。カレントセグメントは、セグメント指令を使用して変化し得る。
【０３８７】
１．２６．１．セグメント指令
セグメント指令は、パーサのカレントセグメントを変化させる。一実施形態において、サポートされるセグメント指令は、．ｃｏｄｅおよび．ｄａｔａである。．ｃｏｄｅセグメントは、バイトコード命令を保持する。．ｄａｔａセグメントは、グローバル変数を保持する。
【０３８８】
１．２６．２．データ指令
データ指令は、仮想マシンのデータセグメントにロードされるデータ（例えば整数およびストリング）を指定する。一実施形態において、サポートされるデータ指令は、以下の通りである。
・．ｓｔｒｉｎｇ＜ｓｏｍｅ  ｃｈａｒｓ＞；キャラクター列を指定する。一実施形態において、アセンブラは、ストリングの終わりに値０を有するオクテットを追加する。
・．ｂｙｔｅ＜ｖａｌｕｅ＞：８ビット値を指定する。＜ｖａｌｕｅ＞は、１０進数または１６進数として表現できる（０ｘを接頭辞として付ける）。
・．ｌｏｎｇ＜ｖａｌｕｅ＞：３２ビット値を指定する。＜ｖａｌｕｅ＞は、１０進数または１６進数として表現できる（０ｘを接頭辞として付ける）。
【０３８９】
１．２６．３．アセンブラ指令
一実施形態において、サポートされるアセンブラ指令は、．ｅｑｕ＜ｓｙｍｂｏｌ＞，＜ｖａｌｕｅ＞である。これは、シンボル＜ｓｙｍｂｏｌ＞を値＜ｖａｌｕｅ＞に等しくなるように設定する。シンボルは、オペランドまたはコード命令として一般に使用される。
【０３９０】
１．２６．４．ラベル
ラベルは、セグメントの中の場所を指し示すシンボルである。コードセグメントにおいて命令を指し示すラベルは、ジャンプ／分岐命令のために一般に使用される。データセグメントにおいてデータを指し示すラベルは、変数を指すために一般に使用される。一実施形態において、ラベルのためのシンタックスは、＜ＬＡＢＥＬ＞である。
【０３９１】
任意のコメントを除いて、「：」の後には何もないことに留意されたい。ラベルは、次のデータまたは命令の場所を指し示す。一実施形態において、同一のアドレスを指し示す複数のラベルを有してもよい。
【０３９２】
１．２６．５．エクスポート指令
エクスポート指令は、アセンブラによって生成されるコードモジュールの「エクスポート」セクションのエントリを作成するために使用される。エクスポートセクションにおける各エントリは、（名前およびアドレスの）ペアである。論ずる例示的実施形態において、コードセグメントの中のアドレスのみを、エクスポートセクションにおいて指定することができる。
【０３９３】
エクスポート指令のシンタックスは、．ｅｘｐｏｒｔ＜ｌａｂｅｌ＞である。これは、＜ｌａｂｅｌ＞によって指し示され＜ｌａｂｅｌ＞という名前を有するアドレスを、エクスポートする。
【０３９４】
１．２６．６．コード命令
コードセグメントに行くことになるデータをコンパイルするときに、アセンブラは、直接的または間接的にバイトコードにマッピングする命令を読み取る。上記の例示的な命令セットにおいて、大部分の仮想マシンバイトコードは、直接のオペランドを有せず、単一の行の上の単純なニーモニックによって表示される。アセンブラシンタックスを読みやすくするために、一部の命令は、擬似オペランド（あたかもバイトコードオペランドであるかのように見えるが本当はそうではない）を受け入れる。この場合、アセンブラは、１つ以上のバイトコード命令を生成することによって、あたかも命令が直接のオペランドを有するかのような効果と同じ効果を生み出す。例えば、分岐命令は、擬似オペランドを使用する。
【０３９５】
１．２６．６．１．分岐オペランド
分岐命令は、逐語的に指定することができ（任意オペランドなしで）、または任意オペランドを用いて指定することができる。任意オペランドは、アセンブラによって、対応するバイトコードシーケンスに変換される。任意オペランドは、整数定数またはシンボルである。オペランドがシンボルである場合、アセンブラは、正しい整数相対オフセットを算出するので、分岐はシンボルに対応するアドレスで終わる。
【０３９６】
１．２６．６．２．プッシュオペランド
一実施形態において、プッシュ命令は、１つのオペランドを常に受け取る。オペランドは、整数定数、シンボル、または接頭辞「＠」（その後にラベル名が直接続く）のうちの１つであり得る。オペランドがシンボルである場合、シンボルがラベルまたは．ｅｑｕシンボルのいずれであろうとも、プッシュされる値は、そのシンボルの直接的な値である（値は、セグメントオフセットによって増加させられない）。オペランドが、前に「＠」を付けられるラベル名である場合、プッシュされる値は、ラベルが指し示すものに依存する。スタック上にプッシュされる値は、ラベルによって表される絶対アドレスである（すなわち、セグメントオフセットに追加されるローカルなラベル値）。
【表４０】
2009512096.tif 000042
【０３９７】
１．２６．８．コマンド行構文
一実施形態において、アセンブラは、以下のシンタックスによって呼び出すことができるコマンド行ツールである。すなわち、「ＰｋｔＡｓｓｅｍｂｌｅｒ［ｏｐｔｉｏｎｓ］＜ｉｎｐｕｔ ｆｉｌｅ ｐａｔｈ＞＜ｏｕｔｐｕｔ ｆｉｌｅ ｐａｔｈ＞。ここで、［ｏｐｔｉｏｎｓ］は、−ｃｓ  ｉｎｔ、−ｄｓ  ｉｎｔ、−ｘｍｌ  ｉｄ、または−ｈであり得る。「−ｃｓ  ｉｎｔ」は、コードセグメントアドレス値（デフォルト＝８）である。「−ｄｓ  ｉｎｔ」は、データセグメントアドレス値（デフォルト＝４）である。「−ｘｍｌ  ｉｄ」は、指定のＩＤを有するＸＭＬファイルとして制御オブジェクトを出力するために使用される。「−ｈ」は、ヘルプ情報を表示するために使用される。
【０３９８】
９．制御
このセクションは、制御オブジェクトの例示的実施形態を記載する。制御オブジェクトは、それらが制御するＣｏｎｔｅｎｔＫｅｙオブジェクトの使用を認可または拒絶することによってコンテンツへのアクセスを管理する規則を表すために使用することができる。制御オブジェクトは、それらが埋め込まれるリンクオブジェクトの有効性に関する制約を表すために使用することもできる。制御オブジェクトは、別のエンティティ（例えばエージェントまたは委託）に代わって実行される独立型プログラムコンテナとして使用することもできる。一実施形態において、制御は、メタデータおよびバイトコードプログラムを含む。これらは、特定の対話処理プロトコルを実現する。制御プロトコルの目的は、ＤＲＭエンジンを通して、ＤＲＭエンジンと制御プログラムとの間、またはホストアプリケーションと制御プログラムとの間の対話処理を指定することである。このセクションはまた、アプリケーションがコンテンツ上で実行できる例示的なアクション（そのアクションパラメータは制御プログラムに出力されるべきである）、制御プログラムが戻りステータスをコード化する方法（リクエストされたアクションが実行できるか否かを示す）、ならびに戻りステータスをさらに記述できるパラメータを記載する。
【０３９９】
このセクションにおいて、以下の略語および頭字語が使用される。
・ＥＳＢ：拡張された状態ブロック（Ｅｘｔｅｎｄｅｄ  Ｓｔａｔｕｓ  Ｂｌｏｃｋ）
・ＬＳＢ：最下位ビット（Ｌｅａｓｔ  Ｓｉｇｎｉｆｉｃａｎｔ  Ｂｉｔ）
・バイト：８ビット値またはオクテット
・バイトコード：実行可能命令とそのオペランドとをコード化するバイトのストリーム
【０４００】
１．２７．制御プログラム
一実施形態において、制御オブジェクトは、制御プログラムを含む。制御プログラムは、仮想マシンによって実行可能なバイトコードを含むコードモジュール、および名前付きルーチンのリスト（例えばエクスポートテーブルにおけるエントリ）を含む。
【０４０１】
一実施形態において、コンテンツ項目上の一定の操作（例えば「再生」）の実行を管理する規則を示すルーチンのセットは、「アクション制御」と呼ばれる。リンクオブジェクト上の有効性制約を示すルーチンのセットは、「リンク制約」を呼ばれる。遠隔エンティティに代わって（例えば異なるホスト上で実行するＤＲＭエンジンを用いたプロトコルセッション中に）実行するように意図されたルーチンのセットは、「エージェント」と呼ばれる。
別の制御に代わって（例えば制御プログラムがＳｙｓｔｅｍ．Ｈｏｓｔ．ＣａｌｌＶｍシステムコールを使用するときに）実行するように意図されるルーチンのセットは、「委託」と呼ばれる。
【０４０２】
１．２７．１．制御プログラムに対するインタフェース
一実施形態において、制御プログラムは、ホスト環境で動作する仮想マシンによって実行される。ホスト環境は、任意の適切な態様において実現することができる。しかしながら、説明の容易さ、および例示する目的のために、以下の説明において、仮想マシンのホスト環境のインプリメンテーションを、２つの部分、すなわちホストアプリケーションおよびＤＲＭエンジンに論理的に分けることができると仮定する。しかしながら、他の実施形態は、異なる論理的機能分離を有してもよく、それは上述した論理構造と同等であり得ることが理解される。
【０４０３】
図２９に示すように、他の好ましい実施形態において、ＤＲＭエンジン２９０８は、ホストアプリケーション２９００と制御プログラム２９０６との間の論理インタフェースである。ホストアプリケーション２９００は、エンジン２９０８に対して論理的リクエストを行う（例えば一定の目的（例えばコンテンツストリームの再生またはレンダリング）のためにコンテンツ鍵へのアクセスをリクエストする）。一実施形態において、エンジン２９０８は、下記の対話処理プロトコルが正しく実現されることを確実にする（例えば、制御プログラムの初期化、呼び出しシーケンス、および他の対話処理の詳細に関する任意の保証が満たされることを確実にすることによって）。
【０４０４】
ホストアプリケーション２９００がコンテンツＩＤのセットのためのコンテンツ鍵の使用をリクエストする場合、ＤＲＭエンジン２９０８は、どのＣｏｎｔｒｏｌオブジェクトを使用するべきかを決定する。Ｐｒｏｔｅｃｔｏｒオブジェクトは、リクエストされたコンテンツＩＤのためにどのＣｏｎｔｅｎｔＫｅｙオブジェクトにアクセスする必要があるかについて、エンジンが決定することを可能にする。次に、エンジンは、これらのＣｏｎｔｅｎｔＫｅｙオブジェクトを参照するＣｏｎｔｒｏｌｌｅｒオブジェクトを見いだす。一実施形態において、Ｃｏｎｔｒｏｌｌｅｒオブジェクトは、複数のＣｏｎｔｅｎｔＫｅｙオブジェクトを参照することができる。これは、複数のＣｏｎｔｅｎｔＫｅｙオブジェクトが同一のＣｏｎｔｒｏｌオブジェクトによって管理されることを可能にする。ホストアプリケーションが、アクションを呼び出すことによってコンテンツ鍵へのアクセスをリクエストする場合、それらに対応するＣｏｎｔｅｎｔＫｅｙオブジェクトが同一のＣｏｎｔｒｏｌｌｅｒオブジェクトによって参照される程度に、ホストアプリケーションはコンテンツＩＤをグループとしてリクエストすることができる。一実施形態において、複数のコントローラオブジェクトによって参照される一群のコンテンツ鍵にアクセスするリクエストは、許可されない。
【０４０５】
一実施形態において、ＤＲＭエンジンは、アクションをルーチン名にマッピングする規則に従う。例えば、一実施形態において、下記のルーチンの各々について、コードモジュールにおけるＥｘｐｏｒｔ  Ｔａｂｌｅエントリに現れる名前は、下記のセクション９．１．４〜９．１．７に示すそれぞれのストリングである。
【０４０６】
１．２７．１．１．制御ローディング
一実施形態において、エンジンが制御ルーチンに呼び出しを行うことができる前に、エンジンは制御のコードモジュールを仮想マシンにロードする必要がある。一実施形態において、ＶＭごとに唯一のコードモジュールがロードされる。
【０４０７】
１．２７．１．２．最小単位
一実施形態において、エンジンは、ルーチンに対して利用可能にするリソース（例えばオブジェクト（または「状態」）データベース）に関して、制御プログラム内のルーチンへの呼び出しがアトミックであることを確実にする。従って、そのような実施形態において、エンジンは、呼び出すルーチンのいずれかの実行中に、これらのリソースが変更されないままであることを確実にする必要がある。このことは、ルーチン呼び出し中にこれらのリソースを効果的にロックすることによって、または複数のＶＭの同時実行を防止することによって行われてもよい。しかしながら、エンジンは、連続したルーチン呼出し全体にわたってこれらのリソースが変更されないことを保証する必要はない。
【０４０８】
１．２７．２．制御プロトコル
一実施形態において、ルーチン命名、入出力インタフェース、およびコードモジュールにおける各ルーチンのためのデータ構造は、共に制御プロトコル（Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）を構成する。コードモジュールによって実現されるプロトコルは、Ｃｏｎｔｒｏｌオブジェクトの「プロトコル」フィールドに表示される。下記の例示的な制御プロトコルは、標準制御プロトコル（Ｓｔａｎｄａｒｄ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）と呼ばれる。その識別子（「プロトコル」フィールドの値）は、「ｈｔｔｐ：／／ｗｗｗ．ｏｃｔｏｐｕｓ−ｄｒｍ．ｃｏｍ／ｓｐｅｃｓ／ｓｃｐ−１ ０」である。
【０４０９】
一実施形態において、ＤＲＭエンジンは、コードモジュールをロードし、かつ制御プログラムにおけるルーチンを呼び出す前に、制御プログラムによる対話処理が、プロトコルフィールドに表示される特定のプロトコルＩＤに関する指定と一貫していることを保証する必要がある。そのことは、実現する必要のある仮想マシンの機能に関する任意の保証、および制御プログラムに利用可能なアドレス空間の大きさに関する保証などを含む。
【０４１０】
制御プロトコル（例えば標準制御プロトコル）は、新しいプロトコル仕様を作成する必要なしに、時間とともに進化することが可能である。プロトコルに対して行われる変更が、仕様の以前の修正と一貫しており、ＤＲＭエンジンの既存のインプリメンテーション、ならびにそのプロトコルに従う既存の制御プログラムが、仕様に従って実行し続ける限り、変更は互換性があるとみなされる。そのような変化は、例えば、新しいアクションタイプを含んでもよい。
【０４１１】
１．２７．３．バイトコードタイプ
標準制御プロトコルに関わる上述の例示的実施形態において、バイトコードモジュールのタイプは、「プランクトン（Ｐｌａｎｋｔｏｎ）バイトコードモジュールバージョン１．０」である。この例示的実施形態において、制御オブジェクトの「タイプ」フィールドのための値は、「ｈｔｔｐ：／／ｗｗｗ．ｏｃｔｏｐｕｓ−ｄｒｍ．ｃｏｍ／ｓｐｅｃｓ／ｐｋｃｍ−１ ０」である。
【０４１２】
１．２７．４．汎用制御ルーチン
汎用ルーチンは、全体として制御に適用できるルーチンであり、所与のアクションまたはリンク制約に特定のものではない。１つの例示的実施形態において、以下の一般的な制御ルーチンが使用される。
【０４１３】
１．２７．４．１．ＣｏｎｔｒｏｌＩｎｉｔ
このルーチンは、任意である（すなわち、すべての制御において必要とされるわけではない）。このルーチンが使用される場合、他の任意の制御ルーチンを呼び出す前に、エンジンはこのルーチンを１回呼び出す。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、成功の場合は０であり、失敗の場合はマイナスのエラーコードである。一実施形態において、ＲｅｓｕｌｔＣｏｄｅが０でない場合、エンジンは、現在の制御操作を中止し、この制御のためのルーチンに対する更なる呼び出しを行わない。
【０４１４】
１．２７．４．２．Ｃｏｎｔｒｏｌ．Ｄｅｓｃｒｉｂｅ
このルーチンは、任意である。一般に制御プログラムによって表される規則の意味の記述をアプリケーションがリクエストするときに、このルーチンが呼び出される（すなわち特定のアクションのためではない）。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅおよびＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒを、スタックの最上部に返す。ここで、ＲｅｓｕｌｔＣｏｄｅは、整数値である（ルーチンが首尾よく完了した場合は０であり、そうでない場合はマイナスのエラーコードである）。ＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒは、標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋのアドレスである。ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋは、アプリケーションが解釈および使用できる情報を含むので、アプリケーションは、制御プログラムによって表される規則の意味に関する情報をユーザに提供する。
【０４１５】
１．２７．４．３．Ｃｏｎｔｒｏｌ．Ｒｅｌｅａｓｅ
このルーチンは、任意である。このルーチンが存在する場合、ＤＲＭエンジンは、他の任意のルーチンを呼び出す必要がなくなった後に、このルーチンを１回呼び出す。制御の新しい使用が開始されない限り、制御のために他のいかなるルーチンも呼び出されない（この場合、ＣｏｎｔｒｏｌＩｎｉｔルーチンが再び呼び出される）。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、成功の場合は０であり、失敗の場合はマイナスのエラーコードである。
【０４１６】
１．２７．５．アクションルーチン
それぞれの可能なアクションは、名前（例えば、再生、転送、エクスポートなど）を有する。１つの例示的実施形態において、所与のアクション＜Ａｃｔｉｏｎ＞について、以下のルーチン名が規定される（ここで「＜Ａｃｔｉｏｎ＞」は、アクション（例えば「再生」「転送」「エクスポート」など）の実際の名前を表す）。
【０４１７】
１．２７．５．１．Ｃｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．＜Ａｃｔｉｏｎ＞．Ｉｎｉｔ
このルーチンは、任意である。このルーチンが存在する場合、このアクションのために他の任意のルーチンを呼び出す前に、エンジンはこのルーチンを１回呼び出す。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、成功の場合は０であり、失敗の場合はマイナスのエラーコードである。一実施形態において、ＲｅｓｕｌｔＣｏｄｅが０でない場合、エンジンは、現在のアクションを中止し、この制御のためのルーチンに対する更なる呼び出しを行わない。
【０４１８】
１．２７．５．２．Ｃｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．＜Ａｃｔｉｏｎ＞．Ｃｈｅｃｋ
論ずる例示的実施形態において、所与のアクションのためにＰｅｒｆｏｒｍルーチンが呼び出される場合、戻りステータスが何であるかを照合するために、このアクションを実行することなく、このルーチンが必要とされて呼び出される。このルーチンが任意の副作用を有さないことは、重要である。Ｐｅｒｆｏｒｍルーチンも副作用を有しない場合、制御のＥｎｔｒｉｅｓ  ＴａｂｌｅにおけるＣｈｅｃｋエントリおよびＰｅｒｆｏｒｍエントリは、同一のルーチンを指し示すことができることに留意されたい。このルーチンは、下記のＰｅｒｆｏｒｍルーチンのように、同一の入力および出力を有する。
【０４１９】
１．２７．５．３．Ｃｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．＜Ａｃｔｉｏｎ＞．Ｐｅｒｆｏｒｍ
一実施形態において、アプリケーションがアクションを実行しようとするときに、このルーチンが必要とされて呼び出される。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅおよびＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒを、スタックの最上部に返す。ここで、ＲｅｓｕｌｔＣｏｄｅは、整数値である（ルーチンが首尾よく完了した場合は０であり、そうでない場合はマイナスのエラーコードである）。ＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒは、標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋのアドレスである。一実施形態において、成功のＲｅｓｕｌｔＣｏｄｅ（すなわち０）は、リクエストが認可されたことを意味しない。それは、ルーチンがエラーなしに実行可能であったことのみを意味する。それは、リクエストが認可または拒絶されたことを示すＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋである。しかしながら、ＲｅｓｕｌｔＣｏｄｅが失敗を示す場合、ホストアプリケーションは、あたかもリクエストが拒絶されたかのように進行する。例えば、一実施形態において、ＳｔａｔｕｓＢｌｏｃｋのカテゴリは、ＡＣＴＩＯＮ ＤＥＮＩＥＤであるべきであり、または返されたＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋは拒絶され、ホストアプリケーションはアクションを中止する。
【０４２０】
アクションが実行されるときに、Ｐｅｒｆｏｒｍルーチンのみが呼び出される必要がある。エンジンは、前もってＣｈｅｃｋルーチンを呼び出す必要はない。Ｐｅｒｆｏｒｍルーチンのインプリメンテーションは、Ｃｈｅｃｋルーチンを内部的に呼び出すことは、選択すれば可能であるが、システムが前もってＣｈｅｃｋルーチンを呼び出すことを仮定するべきでない。
【０４２１】
１．２７．５．４．Ｃｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．＜Ａｃｔｉｏｎ＞．Ｄｅｓｃｒｉｂｅ
このルーチンは、任意であり、アプリケーションが所与のアクションのための制御プログラムによって表される規則および条件の意味の記述をリクエストするときに、呼び出される。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅおよびＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒを、スタックの最上部に返す。ここで、ＲｅｓｕｌｔＣｏｄｅは、整数値である（ルーチンが首尾よく完了した場合は０であり、そうでない場合はマイナスのエラーコードである）。ＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒは、標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋのアドレスである。
【０４２２】
１．２７．５．５．Ｃｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．＜Ａｃｔｉｏｎ＞．Ｒｅｌｅａｓｅ
このルーチンは、任意である。このルーチンが存在する場合、ＤＲＭエンジンが所与のアクションのための他の任意のルーチンを呼び出す必要がなくなった後で、このルーチンが１回呼び出される。アクションの新しい使用が開始されない限り、所与のアクションのために他のいかなるルーチンも呼び出されない（この場合、Ｉｎｉｔルーチンが再び呼び出される）。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅをスタックの最上部に返す。
ＲｅｓｕｌｔＣｏｄｅは、成功の場合は０であり、失敗の場合はマイナスのエラーコードである。ＲｅｓｕｌｔＣｏｄｅが０でない場合、エンジンは、所与のアクションのためのルーチンに対する更なる呼び出しを行わない。
【０４２３】
１．２７．６．リンク制約ルーチン
一実施形態において、埋め込まれた制御をリンクオブジェクトが有する場合、ＤＲＭエンジンは、その制御におけるリンク制約ルーチンを呼び出すことによって、リンクオブジェクトの有効性を検証する。１つの例示的実施形態において、以下の一般的なリンク制約ルーチンが使用される。
【０４２４】
１．２７．６．１．Ｃｏｎｔｒｏｌ．Ｌｉｎｋ．Ｃｏｎｓｔｒａｉｎｔ．Ｉｎｉｔ
このルーチンは任意であり、このルーチンが存在する場合、所与のリンク制約のために他の任意のルーチンが呼び出される前に、このルーチンが正確に１回呼び出される。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、成功の場合は０であり、失敗の場合はマイナスのエラーコードである。ＲｅｓｕｌｔＣｏｄｅが０でない場合、エンジンは、リンクオブジェクトの有効性制約が満たされていないとみなし、リンク制御のためのルーチンに対する更なる呼び出しを行うことを回避する。
【０４２５】
１．２７．６．２．Ｃｏｎｔｒｏｌ．Ｌｉｎｋ．Ｃｏｎｓｔｒａｉｎｔ．Ｃｈｅｃｋ
論ずる例示的実施形態において、所与のリンクのための有効性制約が満たされるか否かを照合するために、このルーチンが必要とされて呼び出される。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅおよびＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒを、スタックの最上部に返す。ここで、ＲｅｓｕｌｔＣｏｄｅは、整数値である（ルーチンが首尾よく完了した場合は０であり、そうでない場合はマイナスのエラーコードである）。ＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒは、標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋのアドレスである。ＲｅｓｕｌｔＣｏｄｅが０でない場合、エンジンは、リンクオブジェクトの有効性制約が満たされていないとみなし、リンク制御のためのルーチンに対する更なる呼び出しを行うことを回避する。たとえＲｅｓｕｌｔＣｏｄｅが０（成功）である場合でも、制約が満たされたことを意味せず、ルーチンがエラーなしに実行可能であったことのみを意味する。ＳｔａｔｕｓＢｌｏｃｋは、制約が満たされるか否かを示す。
【０４２６】
１．２７．６．３．Ｃｏｎｔｒｏｌ．Ｌｉｎｋ．Ｃｏｎｓｔｒａｉｎｔ．Ｄｅｓｃｒｉｂｅ
このルーチンは、任意であり、アプリケーションが所与のリンクのための制御プログラムによって表される制約の意味の記述をリクエストするときに、呼び出される。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅおよびＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒを、スタックの最上部に返す。ここで、ＲｅｓｕｌｔＣｏｄｅは、整数値である（ルーチンが首尾よく完了した場合は０であり、そうでない場合はマイナスのエラーコードである）。ＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒは、標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋのアドレスである。
【０４２７】
１．２７．６．４．Ｃｏｎｔｒｏｌ．Ｌｉｎｋ．Ｃｏｎｓｔｒａｉｎｔ．Ｒｅｌｅａｓｅ
このルーチンは任意であり、このルーチンが存在する場合、エンジンが所与の制約のための他の任意のルーチンを呼び出す必要がなくなった後で、このルーチンが呼び出される。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、成功の場合は０であり、失敗の場合はマイナスのエラーコードである。論ずる実施形態において、このルーチンを呼び出した後に、新しいサイクルが開始されない限り、所与の制約のために他のいかなるルーチンも呼び出されない（この場合、Ｉｎｉｔルーチンが再び呼び出される）。同様に、ＲｅｓｕｌｔＣｏｄｅが０でない場合、エンジンは、所与のリンク制約のためのルーチンに対する更なる呼び出しを行わない。
【０４２８】
１．２７．７．エージェントルーチン
一実施形態において、エージェントは、エンティティに代わって実行するように設計される制御オブジェクトである。エージェントは、２つのエンドポイントの間のサービス対話処理の状況において一般に使用される。ここで、１つのエンドポイントは、第２のエンドポイントの状況の中で、一部の仮想マシンコードを実行する必要があり、場合によってはその実行の結果を入手する必要がある。一実施形態において、制御は複数のエージェントを含むことができ、各エージェントは実行可能な任意の数のルーチンを含むことができる。しかしながら、実際には、エージェントは、一般に単一のルーチンを有する。
【０４２９】
１つの例示的実施形態において、エージェントについて、以下のエントリポイントが規定される。ここで、＜Ａｇｅｎｔ＞は、エージェントの実際の名前を指す名前ストリングである。
【０４３０】
１．２７．７．１．Ｃｏｎｔｒｏｌ．Ａｇｅｎｔｓ．＜Ａｇｅｎｔ＞．Ｉｎｉｔ
このルーチンは任意であり、このルーチンが存在する場合、エンジンは、所与のエージェントのために他の任意のルーチンを呼び出す前に、このルーチンを１回呼び出す。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、成功の場合は０であり、失敗の場合はマイナスのエラーコードである。
【０４３１】
１．２７．７．２．Ｃｏｎｔｒｏｌ．Ａｇｅｎｔｓ．＜Ａｇｅｎｔ＞．Ｒｕｎ
論ずる例示的実施形態において、このルーチンは、必要とされ、エージェントのメインルーチンである。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅ、ＲｅｔｕｒｎＢｌｏｃｋＡｄｄｒｅｓ、およびＲｅｔｕｒｎＢｌｏｃｋＳｉｚｅを、スタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、整数値である（ルーチンが首尾よく完了した場合は０であり、そうでない場合はマイナスのエラーコードである）。ＲｅｔｕｒｎＢｌｏｃｋＡｄｄｒｅｓｓは、エージェントコードが呼出し元に返すと予想されるデータを含むメモリブロックのアドレスである（ルーチンが何も返す必要がない場合、アドレスは０である）。ＲｅｔｕｒｎＢｌｏｃｋＳｉｚｅは、ＲｅｔｕｒｎＢｌｏｃｋＡｄｄｒｅｓｓにおけるメモリブロックのバイトのサイズである。一実施形態において、ＲｅｔｕｒｎＢｌｏｃｋＡｄｄｒｅｓｓが０である場合、ＲｅｔｕｒｎＢｌｏｃｋＳｉｚｅの値も０である。
【０４３２】
１．２７．７．３．Ｃｏｎｔｒｏｌ．Ａｇｅｎｔｓ．＜Ａｇｅｎｔ＞．Ｄｅｓｃｒｉｂｅ
このルーチンは、任意であり、アプリケーションが所与のエージェントの記述をリクエストするときに呼び出される。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅおよびＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒを、スタックの最上部に返す。ここで、ＲｅｓｕｌｔＣｏｄｅは、整数値である（ルーチンが首尾よく完了した場合は０であり、そうでない場合はマイナスのエラーコードである）。ＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒは、標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋのアドレスである。
【０４３３】
１．２７．７．４．ＣｏｎｔｒｏＩ．Ａｇｅｎｔｓ．＜Ａｇｅｎｔ＞．Ｒｅｌｅａｓｅ
このルーチンは任意であり、このルーチンが存在する場合、エンジンは、このエージェントのための他の任意のルーチンを呼び出す必要がなくなった後で、このルーチンを１回呼び出す。新しいサイクルが開始されない限り、このエージェントのために他のいかなるルーチンも呼び出されない（この場合、Ｉｎｉｔルーチンが再び呼び出される）。ルーチンは、入力を有さず、出力として、ＲｅｓｕｌｔＣｏｄｅをスタックの最上部に返す。ＲｅｓｕｌｔＣｏｄｅは、成功の場合は０であり、失敗の場合はマイナスのエラーコードである。
【０４３４】
１．２８．拡張状態ブロック
以下の例の定義は、上述のルーチンのいくつかの例示的実施形態によって返されるＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋデータ構造に適用可能である。ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋデータ構造の実施例を、仮想マシンの記載と関連して記載する。
【０４３５】
一実施形態において、グローバルなＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋフラグはない。この実施形態において、制御プログラムは、ＥｘｔｅｎｄｅｄＳｔａｔｕＢｌｏｃｋのＧｌｏｂａｌＦｌａｇフィールドを、０に設定する。
【０４３６】
１．２８．１．カテゴリ
以下の段落は、一実施形態によるＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋｓのＣａｔｅｇｏｒｙフィールドのための値を規定する。一実施形態において、これらのカテゴリのいずれもサブカテゴリを有しないので、ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋｓのＳｕｂＣａｔｅｇｏｒｙフィールドの値は、０に設定される。
【０４３７】
一実施形態において、以下のカテゴリコードが規定される。
【０４３８】
１．２８．１．１．アクション照合および実行ルーチン
【表４１】
2009512096.tif 000043
一実施形態において、アクションルーチンによって返されるＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋパラメータのコンテキストにおいて、制約とは、真実であることを必要とする条件、または、ルーチンの結果がカテゴリＡＣＴＩＯＮ ＧＲＡＮＴＥＤとともにＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋを返すために、満たされる必要のある基準を意味する。
【０４３９】
一実施形態において、上述の両方のカテゴリに共通するＬｏｃａｌＦｌａｇｓフィールドのための値は、以下を含む。
【表４２】
2009512096.tif 000044
【０４４０】
上記の表において、参照されるパラメータリストは、ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋデータ構造の「Ｐａｒａｍｅｔｅｒ」フィールドである。
【０４４１】
１．２８．１．２．Ｄｅｓｃｒｉｂｅルーチンカテゴリコード
一実施形態において、Ｄｅｓｃｒｉｂｅルーチンについてのカテゴリコードは規定されない。一実施形態において、Ａｃｔｉｏｎルーチンのために規定されるものと同一のローカルフラグがＤｅｓｃｒｉｂｅルーチンに適用され、Ｄｅｓｃｒｉｂｅルーチンは、返されるＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋにおいて、下記に指定される「Ｄｅｓｃｒｉｐｔｉｏｎ」という名前のパラメータを含むべきである。一実施形態において、Ｄｅｓｃｒｉｂｅルーチンは、返されるＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋにおいて、義務またはコールバックパラメータを含まない。しかしながら、Ｄｅｓｃｒｉｂｅルーチンは、ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋにおいて、対応するアクションまたはリンク制約に適用できる制約の一部または全部を記述するパラメータを含むべきである。
【０４４２】
１．２８．１．３．リンク制約ルーチンカテゴリコード
【表４３】
2009512096.tif 000045
一実施形態において、Ａｃｔｉｏｎルーチンのために規定されるものと同一のローカルフラグが、これらのカテゴリの各々に適用される。
【０４４３】
一実施形態において、リンク制約ルーチンによって返されるＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋパラメータのコンテキストにおいて、制約とは、真実であることを必要とする条件、またはルーチンの結果が、カテゴリＬＩＮＫ ＶＡＬＩＤを有するＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋを返すために、満たされる必要のある基準を意味する。
【０４４４】
１．２８．２．キャッシュ持続時間
ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋのＣａｃｈｅＤｕｒａｔｉｏｎフィールドは、ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋにおいてコード化される情報の有効期間を示すものである。ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋがゼロ以外の有効期間を有する場合、ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋがキャッシュに格納可能であることを意味し、その期間中は、同一のパラメータを有する正確に同一のルーチン呼び出しを呼び出すことによって、同一のＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋが返されるので、ルーチンを呼び出す代わりに、キャッシュに格納された値がホストアプリケーションに返されることを意味する。
【０４４５】
１．２８．３．パラメータ
一部のパラメータは、戻りステータス、ならびにテンプレート処理のための可変連結に関する、詳細な情報を伝達するために使用される（セクション９．４を参照）。
【０４４６】
一実施形態において、義務およびコールバックを除き、ここに記載するすべての制約は、ホストアプリケーションによる分類および表示を補助することを厳密に目的とするものであり、使用規則を施行するためではない。規則の施行は、制御プログラムの責任である。
【０４４７】
一実施形態において、以下のセクションにおいて規定されるパラメータは、パラメータフラグが適用できない場合はＰａｒａｍｅｔｅｒＢｌｏｃｋとしてコード化され、または１つ以上のフラグが適用できる場合はＥｘｔｅｎｄｅｄＰａｒａｍｅｔｅｒＢｌｏｃｋとしてコード化される。代表的なフラグを、以下に記載する。
【０４４８】
１．２８．３．１．記述
パラメータ名：Ｄｅｓｃｒｉｐｔｉｏｎ
【０４４９】
パラメータタイプ：ＶａｌｕｅＬｉｓｔ
【０４５０】
説明：記述パラメータのリスト。リストの各値は、タイプＰａｒａｍｅｔｅｒまたはＥｘｔｅｎｄｅｄ  Ｐａｒａｍｅｔｅｒのものである。一実施形態において、Ｄｅｆａｕｌｔ、Ｓｈｏｒｔ、およびＬｏｎｇのパラメータが規定される。これらの各々は、存在する場合は、値のために、制御のリソースのうちの１つのＩＤを有する。そのリソースは、テキストペイロードまたはテンプレートペイロードを含むべきである。リソースがテンプレートである場合、結果のテキスト記述（制御プログラム全体の記述、または特定のアクションの記述）を入手するために処理される。テンプレートは、可変連結として、リストの他のパラメータ（その中に「Ｄｅｓｃｒｉｐｔｉｏｎ」パラメータが現れる）を使用して処理される。
【０４５１】
一実施形態において、「Ｄｅｆａｕｌｔ」記述も含まれる場合、「Ｓｈｏｒｔ」および「Ｌｏｎｇ」記述のみが含まれ得る。
【表４４】
2009512096.tif 000046
【０４５２】
１．２８．３．２．制約
一実施形態において、制約パラメータは、類似のタイプの制約を含むリストにおいて分類される。一実施形態において、タイプの一部のために標準制約が規定される。一実施形態において、制御は、標準制約のセットに含まれない制約パラメータを返してもよい。但し、制約パラメータの名前が、その名前の一意性を保証する名前空間におけるＵＲＮであることを条件とする。このことは、ベンダー特定の制約、または他の仕様において規定される制約を含んでもよい。
【０４５３】
１．２８．３．２．１．一般的制約
パラメータ名：ＧｅｎｅｒｉｃＣｏｎｓｔｒａｉｎｔｓ
【０４５４】
パラメータタイプ：ＶａｌｕｅＬｉｓｔ
【０４５５】
説明：適用可能な一般的制約のリスト。リストの各値は、タイプＰａｒａｍｅｔｅｒまたはＥｘｔｅｎｄｅｄＰａｒａｍｅｔｅｒのものである。
【０４５６】
一実施形態において、一般的制約は、このセクションにおいて規定される他の制約タイプのいずれにも帰属しない制約である。一実施形態において、一般的な制約パラメータは、規定されない。
【０４５７】
１．２８．３．２．２．時間的制約
パラメータ名：ＴｅｍｐｏｒａｌＣｏｎｓｔｒａｉｎｔｓ
【０４５８】
パラメータタイプ：ＶａｌｕｅＬｉｓｔ
【０４５９】
説明：適用可能な時間的制約のリスト。リストの各値は、タイプＰａｒａｍｅｔｅｒまたはＥｘｔｅｎｄｅｄ  Ｐａｒａｍｅｔｅｒのものである。時間的制約は、時間、日付、持続時間などに関連する制約である。一実施形態において、以下の時間的制約パラメータが規定される。
【表４５】
2009512096.tif 000047
【０４６０】
１．２８．３．２．３．空間的制約
パラメータ名：ＳｐａｔｉａｌＣｏｎｓｔｒａｉｎｔｓ
【０４６１】
パラメータタイプ：ＶａｌｕｅＬｉｓｔ
【０４６２】
説明：適用可能な空間的制約のリスト。一実施形態において、リストの各値は、タイプＰａｒａｍｅｔｅｒまたはＥｘｔｅｎｄｅｄＰａｒａｍｅｔｅｒのものである。空間的制約は、物理的位置に関連する制約である。一実施形態において、標準的な空間的制約は規定されない。
【０４６３】
１．２８．３．２．４．グループ制約
パラメータ名：ＧｒｏｕｐＣｏｎｓｔｒａｉｎｔｓ
【０４６４】
パラメータタイプ：ＶａｌｕｅＬｉｓｔ
【０４６５】
説明：適用可能なグループ制約のリスト。リストの各値は、タイプＰａｒａｍｅｔｅｒまたはＥｘｔｅｎｄｅｄ  Ｐａｒａｍｅｔｅｒのものである。グループ制約は、グループ、グループ帰属関係、識別グループなどに関連する制約である。一実施形態において、以下のパラメータが規定される。
【表４６】
2009512096.tif 000048
【０４６６】
１．２８．３．２．５．装置制約
パラメータ名：ＤｅｖｉｃｅＣｏｎｓｔｒａｉｎｔｓ
【０４６７】
パラメータタイプ：ＶａｌｕｅＬｉｓｔ
【０４６８】
説明：適用可能な装置制約のリスト。リストの各値は、タイプＰａｒａｍｅｔｅｒまたはＥｘｔｅｎｄｅｄ  Ｐａｒａｍｅｔｅｒのものである。装置制約は、装置の特徴（例えば、機能、属性、名前、識別子など）に関連する制約である。一実施形態において、以下のパラメータが規定される。
【表４７】
2009512096.tif 000049
【０４６９】
１．２８．３．２．６．カウンタ制約
パラメータ名：ＣｏｕｎｔｅｒＣｏｎｓｔｒａｉｎｔｓ
【０４７０】
パラメータタイプ：ＶａｌｕｅＬｉｓｔ
【０４７１】
説明：適用可能なカウンタ制約のリスト。リストの各値は、タイプＰａｒａｍｅｔｅｒまたはＥｘｔｅｎｄｅｄＰａｒａｍｅｔｅｒのものである。カウンタ制約は、カウントされた値（例えば、再生カウント、累算カウントなど）に関連する制約である。一実施形態において、標準的なカウンタ制約は規定されない。
【０４７２】
１．２８．３．３．パラメータフラグ
一実施形態において、セクション９．２．３に記載されるすべてのパラメータについて、ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋとしてコード化される場合、以下のフラグを使用してもよい。
【表４８】
2009512096.tif 000050
【０４７３】
１．２９．義務およびコールバック
一実施形態において、一定のアクションは、認可される際に、ホストアプリケーションからの更なる関与を必要とする。義務は、リクエストするコンテンツ鍵の使用時または使用後に、ホストアプリケーションによって実行される必要のある操作を表す。コールバックは、リクエストするコンテンツ鍵の使用時または使用後に、ホストアプリケーションによって実行される必要のある制御プログラムのルーチンのうちの１つ以上に対する呼び出しを表す。
【０４７４】
一実施形態において、アプリケーションがサポートまたは理解しない任意の重要な義務またはコールバックに遭遇した場合（例えばアプリケーションを実行した後で義務の種類が規定されたため）、アプリケーションは、この義務パラメータまたはコールバックパラメータが返されたアクションの継続を拒絶しなければならない。一実施形態において、重要な義務またはコールバックは、それを記述するパラメータのためのＣＲＩＴＩＣＡＬパラメータフラグを設定することによって示される。
【０４７５】
制御は、副作用（例えば再生カウントを減らすこと）を有する場合、すべての重要な義務およびコールバックを理解してそれに従うことが可能であれば、ＯｎＡｃｃｅｐｔコールバックを使用することによって、ホストアプリケーションに一定のルーチンを呼び出すことを要求すべきである。副作用は、コールバックルーチンにおいて発生するべきである。１つの例示的実施形態において、インプリメンテーションは、ＯｎＡｃｃｅｐｔコールバックを理解および実現する必要がある。なぜなら、そのことは、副作用（例えば状態データベースに対する更新）が時期尚早に（例えば、ホストアプリケーションが、所与の重要な義務またはコールバックに従えないことを決定し、アクションの実行を終了することを必要とする前に）生じることを防止する際に有用だからである。従って、処理の最小単位の方策が提供される。
【０４７６】
１．２９．１．パラメータ
以下のパラメータは、ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋデータ構造において返され得るいくつかのタイプの義務およびコールバックを規定する。
【０４７７】
１．２９．１．１．義務
パラメータ名：Ｏｂｌｉｇａｔｉｏｎｓ
【０４７８】
パラメータタイプ：ＶａｌｕｅＬｉｓｔ
【０４７９】
説明：義務パラメータのリスト。リストの各値は、タイプＰａｒａｍｅｔｅｒまたはＥｘｔｅｎｄｅｄ  Ｐａｒａｍｅｔｅｒのものである。一実施形態において、以下の義務パラメータが規定される。
【表４９】
2009512096.tif 000051
【０４８０】
１．２９．１．２．コールバック
パラメータ名：Ｃａｌｌｂａｃｋｓ
【０４８１】
パラメータタイプ：ＶａｌｕｅＬｉｓｔ
【０４８２】
説明：コールバックパラメータのリスト。リストの各値は、タイプＰａｒａｍｅｔｅｒまたはＥｘｔｅｎｄｅｄ  Ｐａｒａｍｅｔｅｒのものである。一実施形態において、以下のコールバックパラメータが規定される。
【表５０】
2009512096.tif 000052
【表５１】
2009512096.tif 000053
【０４８３】
一実施形態において、上記の表において言及される「Ｃａｌｌｂａｃｋ」タイプは、３つのＶａｌｕｅＢｌｏｃｋ要素を有するＶａｌｕｅＬｉｓｔＢｌｏｃｋである。
【表５２】
2009512096.tif 000054
【０４８４】
１．２９．１．３．パラメータフラグ
一実施形態において、上記のセクションにおいて規定されるものと同一のパラメータフラグが使用される。一実施形態において、呼出し元が実現する必要のあるコールバックおよび義務は、ＣＲＩＴＩＣＡＬとしてマーキングされるので、これらのパラメータを無視する選択をホストアプリケーションに与えることを回避する。
【０４８５】
１．２９．２．イベント
一実施形態において、イベントは、名前によって指定される。イベントのタイプに依存して、イベントを更に指定するように規定されたフラグのセットがあり得る。一実施形態において、特定のイベントのためにフラグが規定されない場合、フラグフィールドの値は、０に設定される。更に、一部のイベントは、イベントが生じるときに一部の情報がコールバックルーチンに出力されるように指定してもよい。一実施形態において、ホストアプリケーションから特別な情報が必要とされない場合、ホストアプリケーションは、空のＡｒｇｕｍｅｎｔｓＢｌｏｃｋを用いて呼び出さなければならない（下記のセクション３．３におけるコールバックルーチンインタフェースの記載を参照）。
【０４８６】
一実施形態において、ＣＲＩＴＩＣＡＬとしてマーキングされたコールバックパラメータにおけるイベントの名前が、ホストアプリケーションによって理解またはサポートされない場合、ホストアプリケーションは、このパラメータを、理解されないＣＲＩＴＩＣＡＬパラメータとしてみなさなければならない（さらに、許可がリクエストされたアクションは実行されてはならない）。
【０４８７】
一実施形態において、以下のイベント名が規定される。
【表５３】
2009512096.tif 000055
【表５４】
2009512096.tif 000056
【０４８８】
１．２９．３．コールバックルーチン
一実施形態において、コールバックルーチンは、同一の入力を受け取る：
【０４８９】
入力：スタックの最上部
【表５５】
2009512096.tif 000057
【０４９０】
Ｃｏｏｋｉｅ：コールバックパラメータにおいて指定されたＣｏｏｋｉｅフィールドの値。
【０４９１】
ＡｒｇｕｍｅｎｔｓＢｌｏｃｋＳｉｚｅ：このパラメータの下でスタック上に渡されるデータのバイト数。ルーチンが呼び出されるときに、スタックは、呼出し元によって出力される値ＡｒｇｕｍｅｎｔｓＢｌｏｃｋＳｉｚｅを含み、アーギュメントブロックのサイズを示し、その後にデータのＡｒｇｕｍｅｎｔｓＢｌｏｃｋＳｉｚｅバイトが続く。サイズが４の倍数でない場合、スタック上のデータをゼロ値バイトによってパッドすることによって、スタックポインタが４の倍数であることが確実にされる。
【０４９２】
１．２９．３．１．ＣＯＮＴＩＮＵＥコールバック
一実施形態において、タイプＣＯＮＴＩＮＵＥを有するコールバック（タイプＩＤ＝０）は、以下の出力を有する。
【０４９３】
出力：スタックの最上部
【表５６】
2009512096.tif 000058
【０４９４】
ＲｅｓｕｌｔＣｏｄｅ：整数値。結果値は、ルーチンが実行できた場合は０であり、エラーが生じた場合はマイナスのエラーコードである。
【０４９５】
Ｄｅｓｃｒｉｐｔｉｏｎ：ＲｅｓｕｌｔＣｏｄｅが、コールバックルーチンが実行可能であったことを示す場合（すなわち値は０である）、ホストアプリケーションは、現在の操作を継続することができる。ＲｅｓｕｌｔＣｏｄｅが、エラーが生じたことを示す場合、ホストアプリケーションは、現在の操作を中止し、すべての保留中のコールバックおよび義務をキャンセルする。
【０４９６】
１．２９．３．２．ＲＥＳＥＴ  Ｃａｌｌｂａｃｋｓ
制御ルーチンが、ルーチンから返されたＥＳＢにおいてタイプＲＥＳＥＴの指定された１つ以上のコールバックを有する場合、ホストアプリケーションは、そのコールバックのための条件が満たされるときに、任意の指定されたコールバックルーチンを呼び出す。一実施形態において、コールバックのいずれかの条件が満たされるとすぐに、ホストアプリケーションは、以下のことを行う必要がある。
・他の全ての保留中コールバックをキャンセルする。
・すべての現在の義務をキャンセルする。
・必要とされるパラメータ（あるとすれば）をそのコールバックに提供する。
・指定されたコールバックルーチンを呼び出す。
【０４９７】
ルーチンからの戻りステータスは、ホストアプリケーションに対して、現在の操作の実行を継続できるか否かを示す。一実施形態において、許可が拒絶されるか、またはルーチンが首尾よく実行できない場合、ホストアプリケーションは、現在の操作の実行を中止しなければならない。同様に、許可が認可される場合、ホストアプリケーションは、あたかも本来のＣｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．＜Ａｃｔｉｏｎ＞．Ｐｅｒｆｏｒｍルーチンを呼び出したかのように、ＥＳＢにおいて返され得る任意の義務またはコールバックに従わなければならない。以前の義務またはコールバック指定は、もはや有効でない。
【０４９８】
一実施形態において、このタイプのコールバックのためのコールバックエントリポイントとして指定されるすべてのルーチンは、以下の出力を有する。
【０４９９】
出力：スタックの最上部
【表５７】
2009512096.tif 000059
【０５００】
ＲｅｓｕｌｔＣｏｄｅ：整数値。結果値は、ルーチンが実行できた場合は０であり、エラーが生じた場合はマイナスのエラーコードである。
【０５０１】
ＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒ：標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋのアドレス。
【０５０２】
Ｄｅｓｃｒｉｐｔｉｏｎ：このルーチンの戻りセマンティクスは、Ｃｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．＜Ａｃｔｉｏｎ＞．Ｐｅｒｆｏｒｍルーチンについて記述されるものと同等である。
【０５０３】
１．３０．メタデータリソース
一実施形態において、制御オブジェクトは、メタデータリソースを含むことができる。それは、ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋデータ構造において返されるパラメータから参照され得る。リソースは、単純なテキスト、テキストテンプレート、または他のデータタイプであり得る。各リソースは、リソースＩＤによって識別され、１つ以上のテキストストリングまたはコード化されたデータ（異なる言語の各バージョンごとに１つ）を含むことができる。リソースがすべての言語に提供される必要はない。どの言語バージョンがそのニーズに最適であるかを選択することは、ホストアプリケーションに依存する。
【表５８】
2009512096.tif 000060
【表５９】
2009512096.tif 000061
【０５０４】
リソースは、ＣｏｎｔｒｏｌオブジェクトにおけるＥｘｔｅｎｓｉｏｎｓとして含まれることによって、制御プログラムを伴う。リソースＩＤは、現在実行中のルーチンを有するコードモジュールを含むＣｏｎｔｒｏｌオブジェクトの内部拡張のＩＤに対してマッピングを行う。
【０５０５】
一実施形態において、Ｒｅｓｏｕｒｃｅオブジェクトのための標準的なバイト列を算出するために、データ構造記述は、以下の通りである。
【表６０】
2009512096.tif 000062
【０５０６】
１．３０．１．単純なテキスト
単純なテキストは、ＭＩＭＥタイプ「テキスト」として指定される。
【０５０７】
１．３０．２．テキストテンプレート
一実施形態において、標準テキストリソースに加えて、テキストテンプレートタイプが規定される。このためのＭＩＭＥタイプは、「ｔｅｘｔ／ｖｎｄ．ｉｎｔｅｒｔｒｕｓｔ．ｏｃｔｏｐｕｓ−ｔｅｘｔ−ｔｅｍｐｌａｔｅ」である。
【０５０８】
一実施形態において、テキストテンプレートは、ＵＴＦ−８においてコード化されるテキストキャラクタ、ならびにパラメータリストにおいて返されるパラメータから入手されるテキスト値によって置き換えられる名前付き記入子（例えばＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋの記入子）を含む。記入子のためのシンタックスは「＼ＰＬＡＣＥＨＯＬＤＥＲ＼」である。ここで、ＰＬＡＣＥＨＯＬＤＥＲは、Ｐｒａｍｅｔｅｒ  Ｂｌｏｃｋの名前および任意のフォーマッティングヒントを指定する。一実施形態において、テンプレートプロセッサは、トークン「＼ＰＬＡＣＥＨＯＬＤＥＲ＼」全体を、そのＰａｒａｍｅｔｅｒ  ＢｌｏｃｋのＶａｌｕｅフィールドのフォーマットされた表現と置き換えなければならない。Ｖａｌｕｅデータのフォーマッティングは、下記のセクション４．２．１において指定される。
【０５０９】
一実施形態において、キャラクタ「＼」が記入子の外のテキストに現れる場合、それは「＼＼」としてコード化されなければならず、テキストにおける「＼＼」のすべての発生は、テンプレートプロセッサによって「＼」に転じられる。
【０５１０】
記入子のためのシンタックスは、ＦＯＲＭＡＴＮＡＭＥであり、ここで、ＮＡＭＥは、Ｐａｒａｍｅｔｅｒ  Ｂｌｏｃｋの名前であり、ＦＯＲＭＡＴは、パラメータのデータをテキストに変換するフォーマッティングヒントである。パラメータ値のデータタイプについてのデフォルトフォーマッティング規則が充分である場合、フォーマッティングヒントは除外でき、記入子は単にＮＡＭＥである。
【０５１１】
１．３０．２．１．フォーマッティング
１．３０．２．１．１．デフォルトフォーマッティング
一実施形態において、異なる値タイプについてのデフォルトフォーマッティング規則は、以下の通りである。
【表６１】
2009512096.tif 000063
【０５１２】
１．３０．２．１．２．明示的フォーマッティング
明示的なフォーマット名は、記入子タグのＦＯＲＭＡＴ部分として使用できる。未知のＦＯＲＭＡＴ名に遭遇する場合、テンプレート処理エンジンは、デフォルトフォーマッティング規則を使用する。
【表６２】
2009512096.tif 000064
【０５１３】
１．３１．コンテキストオブジェクト
一実施形態において、制御ルーチンの実行中に、制御ルーチンは、Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔシステムコールを使用することによって、多くのコンテキストオブジェクトにアクセスする。
【０５１４】
１．３１．１．一般的コンテキスト
一実施形態において、制御を実行するために以下のコンテキストが存在する。
【表６３】
2009512096.tif 000065
【０５１５】
１．３１．２．実行時コンテキスト
一実施形態において、以下のコンテキストは、Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＳｐａｗｎＶｍシステムコールを使用して作成されたＶＭにおいて動作中のすべての制御のために存在する。一実施形態において、このコンテキストは、存在してはならないか、またはＳｙｓｔｅｍ．Ｈｏｓｔ．ＳｐａｗｎＶｍを使用して作成されなかったＶＭにおいて動作中の制御のための空のコンテナでなければならない。
【表６４】
2009512096.tif 000066
【０５１６】
１．３１．３．制御コンテキスト
一実施形態において、制御のルーチンが実行しているときはいつでも、以下のコンテキストが存在する。
【表６５】
2009512096.tif 000067
【０５１７】
１．３１．４．コントローラコンテキスト
一実施形態において、以下のコンテキストは、制御のルーチンの実行中、および制御がコントローラオブジェクトによって指し示されたときは、いつでも存在する（例えば、保護されたコンテンツを消費するためにＣｏｎｔｅｎｔＫｅｙオブジェクトにアクセスするとき）。
【表６６】
2009512096.tif 000068
【０５１８】
ホストアプリケーションが、所与のアクションについて、単一のコントローラオブジェクトによって制御されるグループコンテンツ鍵のみに対して許可される、という実施形態において、唯一の適用可能なコントローラオブジェクトがある。
【０５１９】
１．３１．５．アクションコンテキスト
一実施形態において、Ａｃｔｉｏｎを制御するために制御が呼び出されるときはいつでも、以下のコンテキストが存在する。
【表６７】
2009512096.tif 000069
【０５２０】
１．３１．６．リンクコンテキスト
一実施形態において、リンクオブジェクトの有効性を制限するために制御（例えばリンクオブジェクトに埋め込まれる制御オブジェクト）が呼び出されるときはいつでも、以下のコンテキストが存在する。
【表６８】
2009512096.tif 000070
【０５２１】
１．３１．７．エージェントコンテキスト
一実施形態において、制御のエージェントルーチンの実行中に、以下のコンテキストが存在する。
【表６９】
2009512096.tif 000071
【０５２２】
ＰａｒａｍｅｔｅｒコンテナおよびＳｅｓｓｉｏｎコンテナは、１つのエンティティを必要とするプロトコルが別のエンティティ上のエージェントを送信および実行すること可能にするために通常使用され、そのことによって、どの入力パラメータをエージェントに渡すべきかを指定し、および一定の条件下でホストがどのセッションコンテキストオブジェクトを設定する必要があるかを指定する。一定のセッションコンテキストオブジェクトの有無は、サポートするように設計されたプロトコルの一部として実行しているか、またはコンテキストの外で実行しているかを、エージェントコードが決定することを可能にし得る。後者の場合、実行を拒絶してもよい。例えば、実行するホスト上で状態オブジェクトを作成することを目的とするエージェントは、特定のプロトコル対話処理の間に実行されていない場合は、実行を拒絶してもよい。
【０５２３】
１．３２．アクション
一実施形態において、各アクションは、名前とパラメータのリストとを有する。一実施形態において、一部のパラメータが必要とされる。アプリケーションは、このアクションを実行するときにパラメータを提供しなければならない。一部のパラメータは任意であり、アプリケーションは、パラメータを提供してもよいし、または除外してもよい。
【０５２４】
一実施形態において、以下の標準的アクションが規定される。
【０５２５】
１．３２．１．再生
説明：マルチメディアコンテンツの通常のリアルタイム再生。
【０５２６】
１．３２．２．転送
説明：互換性のあるターゲットシステムへの転送。
【０５２７】
同一のＤＲＭ技術を備えるシステムに対してコンテンツを利用可能にしなければならないときに、互換性のあるターゲットシステムへの転送が使用される。その結果、ターゲットシステムは、この制御を含むライセンスと同一のライセンスを使用することができる。しかし、ソース、シンクまたは両方において、状態情報を変化させる必要があり得る。転送元のシステムは、ソースと呼ばれる。転送先のターゲットシステムは、シンクと呼ばれる。
【０５２８】
このアクションは、ソースおよびシンクの持続的な状態における必要な更新を行うために、Ａｇｅｎｔをソースからシンクまで転送することを可能にする、サービスプロトコルと連動して使用されるように意図される（例えば本明細書に記載する状態データベースにおけるオブジェクト）。一実施形態において、制御は、この目的のために、ＲｕｎＡｇｅｎｔＯｎＰｅｅｒ義務を使用する。状態データベースの説明と関連して、このサービスプロトコルの例示的実施形態に関する更なる情報を下記に提供する。
【０５２９】
Ｐａｒａｍｅｔｅｒｓ：
【表７０】
2009512096.tif 000072
【０５３０】
１．３２．３．エクスポート
説明：外部ターゲットシステムに対するエクスポート。
【０５３１】
外部ターゲットシステムへのエクスポートは、本来のコンテンツライセンスを使用できないシステムにコンテンツをエクスポートしなければならないときに使用されるアクションである。これは、異なるＤＲＭ技術を備えるシステム、ＤＲＭ技術を備えないシステム、または同一の技術を備えるシステムであり得るが、本来のライセンスと異なるライセンスを必要とする状況の下にある。転送元のシステムは、ソースと呼ばれる。転送先のターゲットシステムは、シンクと呼ばれる。
【０５３２】
一実施形態において、このアクションのＤｅｓｃｒｉｂｅ、Ｃｈｅｃｋ、およびＰｅｒｆｏｒｍａｎｃｅの方法のためのＥｘｔｅｎｄｅｄ  Ｓｔａｔｕｓの結果において、以下のパラメータが設定される。
【表７１】
2009512096.tif 000073
【０５３３】
Ｐａｒａｍｅｔｅｒｓ：
【表７２】
2009512096.tif 000074
【０５３４】
他の入力パラメータは、特定のターゲットシステムによって必要とされ得る。
【０５３５】
１．３２．３．１．標準ターゲットシステム
１．３２．３．１．１．オーディオＣＤまたはＤＶＤ
一実施形態において、ターゲットシステムが、圧縮されていないＰＣＭオーディオが書き込まれる暗号化されていない媒体（例えば、書き込み可能なオーディオＣＤまたはＤＶＤ）である場合、標準ＴａｒｇｅｔＳｙｓｔｅｍ  ＩＤ「ＣｌｅａｒｔｅｘｔＰｃｍＡｕｄｉｏ」が使用される。このターゲットシステムについて、ＥｘｐｏｒｔＩｎｆｏパラメータは、著作権フラグを表す単一のＩｎｔｅｇｅｒパラメータである。このフラグは、整数値の最下位ビットにおいて示される。
【表７３】
2009512096.tif 000075
【０５３６】
１０．状態データベース
安全な状態記憶メカニズムを提供するためにＤＲＭエンジンの好ましい実施形態によって使用できる安全なオブジェクト記憶装置を、以下に記載する。そのような機能は、呼出しから呼出しまで持続的な状態データベースの読込みおよび書込みを行うことが可能な制御プログラムを有効にするのに役立つ。そのような状態データベースは、状態オブジェクト（例えば、再生回数、最初の使用日、集積されたレンダリング時間など）を格納するために使用することができる。好ましい実施形態において、安全なデータベースは、不揮発性メモリ（例えば、携帯装置上のフラッシュメモリ、またはＰＣ上のハードディスクドライブの暗号化された領域）において実現される。しかしながら、安全なデータベースは、任意の適切な媒体上で実現し得ることが理解される。
【０５３７】
このセクションにおいて用いられる「オブジェクト」という用語は、安全なオブジェクト記憶装置に含まれるデータオブジェクトを一般に指し、本明細書の他の場所で論ずるオブジェクト（例えば、制御、コントローラ、リンクなど）を指さない。オブジェクトのこれらの２つのカテゴリを区別する必要がある場合、本明細書の他の場所に記載するオブジェクト（すなわち、制御、コントローラ、プロテクタ、ＣｏｎｔｅｎｔＫｅｙｓ、リンク、ノードなど）を指すために、「ＤＲＭオブジェクト」という用語が使用される。その一方で、「状態オブジェクト」という用語は、状態データベースの中に格納されるオブジェクトを指すために使用される。以下の説明において、「シーシェル（Ｓｅａｓｈｅｌｌ）」と呼ばれる状態データベースの例示的なインプリメンテーションに言及することがある。これは、本明細書の他の場所に記載するオクトパスＤＲＭエンジンの実施形態と関連して使用される。しかしながら、本明細書に記載するシステムおよび方法の実施形態は、この例示的なインプリメンテーションの機能の一部または全部なしで実施できることが理解される。
【０５３８】
１．３３．データベースオブジェクト
オブジェクト記憶装置（例えばデータベース）は、データオブジェクトを含む。一実施形態において、オブジェクトは論理階層に配置される。ここで、コンテナオブジェクトは、それに含まれる子オブジェクトの親である。一実施形態において、４つのタイプのオブジェクト（ストリング、整数、バイト列、およびコンテナ）がある。各オブジェクトは、関連するメタデータおよびタイプを有する。オブジェクトは、そのタイプに依存して、値を有することもできる。
【０５３９】
一実施形態において、状態オブジェクトは、Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔおよびＳｙｓｔｅｍ．Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔシステムコールを使用して、仮想マシンプログラムからアクセスできる。以下に詳述するように、オブジェクトメタデータは、仮想名を使用してアクセスすることができる。一実施形態において、メタデータフィールドの一部は、データベースのクライアントによって変化し得る（すなわち、読み書き（ＲＷ）アクセス可能である）。その一方で、他のメタデータフィールドは、読取り専用（ＲＯ）である。
【０５４０】
一実施形態において、以下の表に示すメタデータフィールドが規定される。
【表７４】
2009512096.tif 000076
【０５４１】
一実施形態において、以下の表に示すメタデータフラグが規定される。
【表７５】
2009512096.tif 000077
【０５４２】
上述のように、一実施形態において、４つのタイプの状態オブジェクト（ストリング、整数、バイト列、およびコンテナ）がある。この実施形態において、ストリングオブジェクトの値は、ＵＴＦ−８コード化された文字列であり、整数オブジェクトにおける値は、３２ビット整数値であり、バイト列オブジェクトの値は、バイトのアレイである。この実施形態において、コンテナオブジェクトは、０以上のオブジェクトを含む。コンテナオブジェクトは、それが含むオブジェクトの親と呼ばれる。含まれるオブジェクトは、コンテナの子と呼ばれる。オブジェクトの親、親の親などのチェーンを構成する、すべてのコンテナオブジェクトは、オブジェクトの先祖と呼ばれる。オブジェクトが、別のオブジェクトを先祖として有する場合、そのオブジェクトは、先祖オブジェクトの子孫と呼ばれる。
【０５４３】
１．３４．オブジェクト存続期間
一実施形態において、状態データベースのオブジェクトの存続期間は、多くの規則に従う。オブジェクトは、明示的に抹消、または暗黙的に抹消され得る。オブジェクトは、データベースガーベジコレクションの結果としても抹消され得る。一実施形態において、オブジェクトが抹消される方法に関係なく、以下の規則が適用される。
・オブジェクトの親コンテナのためのＭｏｄｉｆｉｃａｔｉｏｎＤａｔｅは、現在のローカルタイムに設定される。
・オブジェクトがコンテナである場合、オブジェクトが抹消されるときに、そのすべての子は抹消される。
【０５４４】
１．３４．１．明示的オブジェクト抹消
データベースのクライアントが、オブジェクトの削除をリクエストするときに、明示的なオブジェクト抹消が発生する（Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔシステムコールを使用してこれを行う方法の詳細については、オブジェクトアクセスを参照されたい）。
【０５４５】
１．３４．２．暗黙的オブジェクト抹消
祖先におけるオブジェクトのうちの１つが抹消される結果として、オブジェクトが抹消されるときに、暗黙的オブジェクト抹消が発生する。
【０５４６】
１．３４．３．ガーベジコレクション
一実施形態において、状態データベースは、失効した任意のオブジェクトを抹消する。データベースを実現するシステム上のローカルタイムが、オブジェクトのメタデータのＥｘｐｉｒａｔｉｏｎＤａｔｅフィールドより後であるときに、オブジェクトは失効したとみなされる。インプリメンテーションは、失効したオブジェクトについてデータベースを定期的にスキャンして抹消してもよく、またはオブジェクトがアクセスされるまで待ち、その失効日を照合してもよい。一実施形態において、インプリメンテーションは、失効されたオブジェクトをクライアントに返してはならない。一実施形態において、コンテナオブジェクトが（例えば失効したために）抹消されるとき、その子オブジェクト（および再帰的にそれらのすべての子孫）も、（たとえまだ失効していなくとも）抹消される。
【０５４７】
１．３５．オブジェクトアクセス
一実施形態において、状態データベースのオブジェクトは、システムコールのペア（オブジェクトの値を読み取るＳｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔ、およびオブジェクトの値を作成、抹消または設定するＳｙｓｔｅｍ．Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔ）によって、仮想マシンプログラムからアクセスすることができる。
【０５４８】
一実施形態において、状態データベースは、ホストオブジェクトのツリーとして可視であるために、ホストオブジェクトツリーの一定の名前のもとに「マウントされる」。このように、データベースは、ホストオブジェクトのより一般的なツリーにおけるサブツリーとして可視である。これを達成するために、一実施形態において、状態データベースは、常に存在するトップレベルのビルトインルートコンテナオブジェクトを含む。このルートコンテナは、基本的にデータベースの名前である。データベースの他の全てのオブジェクトは、ルートコンテナの子孫である。複数の状態データベースは、ホストオブジェクトツリーの異なる場所においてマウントできる（同一のホストコンテナの下でマウントされる２つのデータベースは、それらのルートコンテナについて異なる名前を有する必要がある）。例えば、Ｄａｔａｂａｓｅ１という名前のルートコンテナを有する状態データベースが、Ｃｈｉｌｄ１という名前の単一の整数子オブジェクトを含む場合、データベースは、ホストオブジェクトコンテナ「／ＳｅａＳｈｅｌｌ」の下でマウントできる。その場合、Ｃｈｉｌｄ１オブジェクトは、「／Ｓｅａｓｈｅｌｌ／Ｄａｔａｂａｓｅ１／Ｃｈｉｌｄ１」として可視である。一実施形態において、状態データベースのオブジェクトに対するアクセスは、アクセスポリシーによって管理される。
【０５４９】
１．３５．１．オブジェクトの読み取り
オブジェクトの値は、システムコールＳｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔを使用することによって読み取ることができる。状態データベースの一実施形態において、データベースに存在できる４つのオブジェクトタイプ（整数、ストリング、バイト列、およびコンテナ）は、仮想マシンのそれらの対応物上へ直接にマッピングされる。オブジェクト値は、通常の方法でアクセスでき、標準仮想名を実現することができる。
【０５５０】
１．３５．２．オブジェクトの作成
オブジェクトは、まだ存在しないオブジェクト名のためにＳｙｓｔｅｍ．Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔを呼び出すことによって、作成することができる。オブジェクト作成は、システムコール指定に従って行われる。一実施形態において、オブジェクトが作成されるときに、状態データベースは以下のことを行う。
・オブジェクトメタデータの「所有者」フィールドを、親コンテナオブジェクトのメタデータの「所有者」フィールドの値に設定する。
・メタデータのＣｒｅａｔｉｏｎＤａｔｅフィールドを、現在のローカルタイムに設定する。
・メタデータのＭｏｄｉｆｉｃａｔｉｏｎＤａｔｅフィールドを、現在のローカルタイムに設定する。
・メタデータのＥｘｐｉｒａｔｉｏｎＤａｔｅフィールドを、０（失効しない）に設定する。
・メタデータのＦｌａｇｓフィールドを、０に設定する。
・親コンテナのＭｏｄｉｆｉｃａｔｉｏｎＤａｔｅを、現在のローカルタイムに設定する。
【０５５１】
一実施形態において、既存のコンテナ階層より深い経路の下でオブジェクトを作成するときに、状態データベースは、作成されるオブジェクトへの経路を作成するために存在する必要のあるコンテナオブジェクトを暗黙に作成する。一実施形態において、暗黙的なコンテナオブジェクト作成は、明示的な作成と同一の規則に従う。例えば、子のないコンテナ「Ａ」がある場合、「Ａ／Ｂ／Ｃ／ＳｏｍｅＯｂｊｅｃｔ」を設定するリクエストは、「Ａ／Ｂ／Ｃ／ＳｏｍｅＯｂｊｅｃｔ」を作成する前に、コンテナ「Ａ／Ｂ」および「Ａ／Ｂ／Ｃ」を暗黙に作成する。
【０５５２】
１．３５．３．オブジェクトの書き込み
オブジェクトの値は、すでに存在するオブジェクトのためのＳｙｓｔｅｍ．Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔを呼び出すことによって、変化させることができる。指定されたＯｂｊｅｃｔＴｙｐｅが、既存のオブジェクトのタイプＩＤと一致しない場合、ＥＲＲＯＲ ＩＮＶＡＬＩＤ ＰＡＲＡＭＥＴＥＲが返される。一実施形態において、タイプＩＤがＯＢＪＥＣＴ ＴＹＰＥ ＣＯＮＴＡＩＮＥＲである場合、値を指定する必要はない（ＯｂｊｅｃｔＡｄｄｒｅｓｓは、ゼロでないでなければならないが、その値は無視される）。既存のオブジェクトが設定されるときに、状態データベースは、オブジェクトのＭｏｄｉｆｉｃａｔｉｏｎＤａｔｅを現在のローカルタイムに設定する。
【０５５３】
１．３５．４．オブジェクトの抹消
オブジェクトは、すでに存在するオブジェクトのためのＳｙｓｔｅｍ．ＨｏｓｔＳｅｔＯｂｊｅｃｔを呼び出すことによって、明示的に抹消することができる。これによって、ＯｂｊｅｃｔＡｄｄｒｅｓｓの値は０となる。
オブジェクトが抹消されるときに、状態データベースは、好ましくは以下のことを行う。
・親コンテナのＭｏｄｉｆｉｃａｔｉｏｎＤａｔｅを、現在のローカルタイムに設定する。
・抹消されたオブジェクトがコンテナである場合、そのすべての子オブジェクトを抹消する。
【０５５４】
１．３５．５．オブジェクトメタデータ
一実施形態において、状態データベースオブジェクトのためのメタデータは、仮想名を有するＳｙｓｔｅｍ．Ｈｏｓｔ．ＧｅｔＯｂｊｅｃｔおよびＳｙｓｔｅｍ．Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔシステムコールを用いてアクセスされる。以下の表は、状態データベースの一実施形態のオブジェクトのために利用可能な標準仮想名および拡張仮想名、ならびにそれらをメタデータフィールドにマッピングする方法を記載する。
【表７６】
2009512096.tif 000078
【０５５５】
一実施形態において、１つ以上の未定義フラグが１に設定される場合、インプリメンテーションは、フラグメタデータフィールドを設定するリクエストを拒絶しなければならない。この場合、Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔに対する戻り値は、ＥＲＲＯＲ ＩＮＶＡＬＩＤ Ｐ  ＡＲＡＭＥＴＥＲである。一実施形態において、Ｆｌａｇｓメタデータフィールドを読み取るときに、クライアントは、定義済みでない任意のフラグを無視しなければならず、オブジェクトのＦｌａｇｓフィールドを設定するときに、クライアントは、まずその既存の値を読み出し、定義済みでない任意のフラグの値を保たなければならない（例えば、システム仕様において）。
【０５５６】
１．３６．オブジェクト所有権およびアクセス制御
一実施形態において、オブジェクトの読み取り、書き込み、作成、または抹消のリクエストが行われるときは必ず、状態データベースインプリメンテーションは、まず、呼出し元がリクエストを実行する許可を有するか否かを照合する。オブジェクトにアクセスを管理するポリシーは、主要な識別および委託のコンセプトに基づく。ポリシーを実現するために、インプリメンテーションが動作する信用モデルは、認証された制御プログラムの概念をサポートする必要がある。このことは、ＰＫＩ鍵ペアの秘密鍵を用いて、プログラムを含む仮想マシンコードモジュールにデジタル的に署名することによって（直接的または間接的に安全な参照を通して）、 および主要な名前を署名鍵に関連づける名前証明書を有することによって、一般に行われる。しかしながら、制御プログラム識別を決定する異なる方法が可能であり、そのうちの任意の適切な一つを使用できることが理解される。 
【０５５７】
一実施形態において、状態データベースにおけるオブジェクトのためのアクセスポリシーは、少数の単純な規則からなる。
・呼出し元の識別が、オブジェクトの所有者と同一である場合、またはＰＵＢＬＩＣ ＲＥＡＤフラグが、オブジェクトのＦｌａｇｓメタデータフィールドにおいて設定される場合、オブジェクトの値に対する読み込みアクセスは、認可される。
・呼出し元が、オブジェクトの親コンテナに対する読み込みアクセスを有する場合、オブジェクトの値に対する読み込みアクセスは、認可される。
・呼出し元の識別が、オブジェクトの所有者と同一である場合、オブジェクトの値に対する書き込みアクセスは、認可される。
・呼出し元が、オブジェクトの親コンテナに対する書き込みアクセスを有する場合、オブジェクトの値に対する書き込みアクセスは、認可される。
・呼出し元が、オブジェクトの親コンテナに対する書き込みアクセスを有する場合、オブジェクトに対する作成アクセスまたは末梢アクセスは、認可される。
・オブジェクトのメタデータに対する読出し書込みアクセス（仮想名を使用する）は、オブジェクトの値に対する読出し書込みアクセスと同じポリシーに従い、読取り専用フィールドに書き込むことができないという更なる制約を有する。
【０５５８】
一実施形態において、アクセスポリシーがクライアントのリクエストを拒絶するときに、リクエストに対するシステムコールの戻り値は、ＥＲＲＯＲ ＰＥＲＭＩＳＳＩＯＮ ＤＥＮＩＥＤである。
【０５５９】
データベースが作成されるときに、状態データベースのルートコンテナは、好ましくは固定される。オブジェクトが作成されるときに、その所有者メタデータフィールドの値は、その親コンテナ所有者メタデータフィールドの値と同じ値に設定される。オブジェクトの所有権は、変化し得る。オブジェクトの所有権を変化させるために、Ｏｗｎｅｒメタデータフィールドの値は、そのオブジェクトの「＠Ｏｗｎｅｒ」仮想名のためのＳｙｔｅｍ．Ｈｏｓｔ．ＳｅｔＯｂｊｅｃｔシステムコールを呼び出すことによって、設定することができる。ただし、アクセス制御規則の下でそれが許可されることを条件とする。
【０５６０】
識別の下で実行中の主体と同一の主体によって所有されないアクセスオブジェクトに対して、制御プログラムがアクセスできない実施形態において、制御プログラムは、「外部」オブジェクトの所有者の識別の下で実行する能力を有するコードモジュールからロードされるプログラムに対して、「外部」オブジェクトへのアクセスを委任する必要がある。これを行うために、制御プログラムは、制御仮想マシンのＳｙｓｔｅｍ．Ｈｏｓｔ．ＳｐａｗｎＶｍ、Ｓｙｓｔｅｍ．Ｈｏｓｔ．ＣａｌｌＶｍ、およびＳｙｓｔｅｍ．Ｈｏｓｔ．ＲｅｌｅａｓｅＶｍシステムコールを使用してもよい。
【０５６１】
１．３７．ライセンス転送プロトコル
上述のようなデータベースにおける状態情報の記憶は、著作権を、装置間で移動したり、またはドメインからエクスポートしたりすることを可能にする（例えば、状態情報を別の装置へ転送することによって）。以下のセクションは、データベースの状態をソースからシンクまで転送できるプロトコルの実施形態を記載する。このプロセスは、ライセンス転送プロトコルと呼ばれるが、単なる実際のライセンス（例えば制御オブジェクトなど）とは対照的に、状態データベースの状態が転送されることに留意されたい。このプロトコルは、ライセンス転送プロトコルと呼ばれる。なぜなら、一実施形態において、制御プログラムにおける転送アクションの実行によって転送が開始されるからであり、状態情報の転送によって、シンクがコンテンツの関連ライセンスを首尾よく実行できるからである。
【０５６２】
図３２は、ライセンス転送３２００の実施例を示し、３つのメッセージ３２０２、３２０４、３２０６からなる。図３２に示す実施例において、リクエスト３２０２をソース３２１２に送信することによって、シンク３２１０によってプロトコルが開始される。一実施形態において、リクエスト３２０２は、転送されるコンテンツのＩＤを保持する。ソース３２１２は、応答３２０４をシンク３２１０に送信する。応答３２０４は、（ｉ）シンク３２１０の状態データベースにおける状態を設定するエージェント、ならびに（ｉｉ）シンク３２１０を対象にしたＣｏｎｔｅｎｔＫｅｙオブジェクトを含む。図３２に示すように、シンク３２１０は、エージェントが実行したという確認３２０６を、ソース３２１２に送信する。コンテンツ鍵および／またはコンテンツを受信すると、シンクは、それに関連する制御に従ってコンテンツを使用してもよい（例えば、スピーカでそれを再生し、ビデオスクリーン上にそれを表示し、および／または他の何らかの態様でそれをレンダリングする）。
【０５６３】
図３２に示す方法は、一部の実施形態において使用できるが、以下のような一部の潜在的問題がある。
【０５６４】
先を見越してそのレンダリングの終了をソースに告げる方法がない。一実施形態において、図３２に示すプロトコルは、２つのモードをサポートするが、これが問題である。すなわち（ｉ）レンダリング（レンダリング停止がない）、および（ｉｉ）チェックアウト（チェックインがない）である。この問題のために、制御の発行者は、転送される状態におけるタイムアウトを発行することになり得る。しかしながら、例えば、ユーザがある装置上のコンテンツをレンダリングしたいが、ユーザが実際には別の装置上でこのコンテンツをレンダリングしたいと決断する場合に、ユーザは消費者として悪い経験をすることになる。すなわち、現在の設計において、ユーザは、他の装置上でコンテンツをレンダリングできるようになる前に、第１の装置上でコンテンツ全体がレンダリングされるのを待たなければならない可能性がある。このことは、コンテンツが比較的に長い場合（例えば映画）、望ましくない。
【０５６５】
リクエストにおけるコンテンツＩＤに関連するライセンスを解決することは、困難であり得る。一実施形態において、リクエストは、コンテンツＩＤのみを含み、ソースは、コンテンツＩＤに関連するライセンスをそのライセンスデータベースから検索する。しかしながら、このプロセスは、エラーを起こしやすくなり得る。なぜなら、ライセンスは、取り外し可能媒体に保存され得るし、プロトコルの連動時に、媒体が取り外されると特定のライセンスが利用可能でなくなることがあるからである。さらに、たとえライセンスが利用可能であっても、ライセンス記憶装置におけるライセンスのためのルックアップの実行が扱いにくくなり得る。また、コンテンツＩＤのセットに関連する複数のライセンスがあり得るので、解決されたライセンスがリクエストにおいて意図されたライセンスと同一であるか否かを決定することが困難であり得る。
【０５６６】
制御プログラムが先を見越して近似照合を求める方法はない。一実施形態において、システムコール／コールバック／義務のセットは、制御がピアの近似照合を求める方法をサポートしない。これに代わって、制御は、近似照合プロトコルの以前の実行から獲得された値を用いて転送中にアプリケーションによって占有されたホストオブジェクトＯｃｔｏｐｕｓ／Ａｃｔｉｏｎ／Ｐａｒａｍｅｔｅｒｓ／Ｓｉｎｋ／Ｐｒｏｘｉｍｉｔｙ／ＬａｓｔＰｒｏｂｅの値のみを読み込むことができる。そのような近似照合が必要でない場合（例えばシンクが一定のドメイン内で知られている場合）に、近似照合を回避することが望ましい場合には、これは問題であり得る。
【０５６７】
プロトコルにとっては、３ラウンドしかない。図３２に示す実施形態において、プロトコルは、３ラウンドに限定されている。これは、重大な制限であり得る。なぜなら、ＯｎＡｇｅｎｔＣｏｍｐｌｅｔｉｏｎコールバックが、別のＲｕｎＡｇｅｎｔＯｎＰｅｅｒ義務を有する拡張状態ブロックを返す場合について、プロトコルは処理ができないからである。さらに、プロトコルが完了した後、シンクは、プロトコルが成功したか否かを実際に知ることがない。それに加えて、近似照合は、応答が送信される前に生じる必要があるが（上記の問題を参照）、ソースおよびシンクが同一のドメイン内にある場合には、これは必要ではない。それに加えて、図３２に示すプロトコルにおいて、ソースは、コンテンツ鍵が果たして使用されるか否かを知ることなく、コンテンツ鍵をシンクに与える。
【０５６８】
ライセンス転送が必要であるというヒントがＥＳＢの中にない。図３２に示す実施形態において、ＤＲＭクライアントがライセンス（例えばＣｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．Ｐｌａｙ．Ｃｈｅｃｋ）を評価する際に、制御の良好な評価を可能にする状態を得るためにはライセンス転送が必要であるということを制御ライタが示唆する容易な方法がない。
【０５６９】
ソースは、転送を開始することができない。図３２に示すプロトコルにおいて、ライセンス転送は、シンクによって開始される。ソースも転送を開始できることが望ましい。
【０５７０】
改善された実施形態
【０５７１】
下記の実施形態は、上記の問題の一部または全部を解決または改善することができる。
【０５７２】
リリース問題のための解決策。一実施形態において、新しいリリース操作を紹介する。
この操作がリクエストにおいて指定されるときに、転送モードＩＤはＲｅｌｅａｓｅに設定される。クライアントがレンダリング／チェックアウトとリリース操作との間の相関を行うために、選択要素ＳｅｓｓｉｏｎＩｄが、リクエストに追加される（下記のセクションを参照）。一実施形態において、この要素が存在するときには、ＳｅｓｓｉｏｎＩｄの下のＴｒａｎｓｆｅｒ  Ａｃｔｉｏｎコンテキストのホストオブジェクトツリーに反映される。
【０５７３】
シンクは、Ｔｅａｒｄｏｗｎメッセージにおいて獲得するＥｘｔｅｎｄｅｄ  Ｓｔａｔｕｓ  Ｂｌｏｃｋ（下記参照）が以下のパラメータを含む場合、リリースリクエストにおいてこのＳｅｓｓｉｏｎＩｄを送信しなければならないということを知っている。
【０５７４】
パラメータ名：ＳｅｓｓｉｏｎＩｄ
【０５７５】
パラメータタイプ：Ｓｔｒｉｎｇ
【０５７６】
このパラメータのフラグは、ＣＲＩＴＩＣＡＬに設定される。
【０５７７】
ライセンス解決問題のための解決策（リクエストのリファクタリング）。一実施形態において、解決策は、シンク装置にライセンスバンドルをリクエストに入れさせることである。その結果、基本的に、シンクおよびソースが同一のライセンスを実行するという保証になる。図３２に示す実施形態において、リクエストのためのＸＭＬスキーマは、以下の通りである。
【表７７】
2009512096.tif 000079
【０５７８】
ＣｏｎｔｅｎｔＩｄＬｉｓｔが、コンテンツを識別するＣｏｎｔｅｎｔ  ＩＤのリストを（トラック／ストリームごとに１つ）含む場合、Ｏｐｅｒａｔｉｏｎは、ライセンス転送動作のタイプを含み、Ｂｕｎｄｌｅは、リクエスト側のＰｅｒｓｏｎａｌｉｔｙノードおよび関連する署名を含む。
【０５７９】
上述したライセンス解決の問題を回避するために、例えば以下の通りにスキーマを訂正することによって、ライセンスバンドルをリクエストに含ませることができる。
【表７８】
2009512096.tif 000080
【０５８０】
このスキーマにおいて、ＣｏｎｔｅｎｔＩｄＬｉｓｔ要素は、Ｌｉｃｅｎｓｅ要素によって置き換えられる。この要素は、ＬｉｃｅｎｓｅＰａｒｔ要素のセットを運ぶ。ＬｉｃｅｎｓｅＰａｒｔ要素は、ｏｃｔ：Ｂｕｎｄｌｅ要素（ライセンスオブジェクトを含む）、ならびに任意のＣｏｎｔｅｎｔＩｄ属性（ライセンスオブジェクトがこの特定のＣｏｎｔｅｎｔＩｄに適用されることを示す）を運ぶ。ＣｏｎｔｅｎｔＩｄ属性を有さないＬｉｃｅｎｓｅＰａｒｔ要素は、根本的なバンドルに含まれるオブジェクトが、すべてのＣｏｎｔｅｎｔ  ＩＤ（一般にコントローラおよび制御オブジェクト）に適用されることを意味する。
【０５８１】
一実施形態において、ＳｅｓｓｉｏｎＩｄ選択要素は存在し得ない。ただし例外は、操作がｕｒｎ：ｍａｒｌｉｎ：ｃｏｒｅ：ｌ−２：ｓｅｒｖｉｃｅ：ｌｉｃｅｎｓｅ−ｔｒａｎｓｆｅｒ：ｒｅｌｅａｓｅである場合であり、対応するレンダリングまたはチェックアウトアクションのＥｘｔｅｎｄｅｄ  Ｓｔａｔｕｓ  ＢｌｏｃｋにおいてＳｅｓｓｉｏｎＩｄパラメータが受信された場合に、ＳｅｓｓｉｏｎＩｄ選択要素が存在し得る（上記参照）。
【０５８２】
一実施形態において、シンクがコンテンツ鍵をすでに解読できることを知っている場合、ＮｅｅｄｓＣｏｎｔｅｎｔＫｅｙｓ選択要素は、偽の値を有して存在するべきである。この要素の欠如は、プロトコルが成功した場合に、ソースがシンクのコンテンツ鍵を再暗号化しなければならないことを意味する。
【０５８３】
一実施形態において、そのようなリクエストを受信するときに、ライセンス要素は以下の通りに処理される。
【０５８４】
（１）ＬｉｃｅｎｓｅＰａｒｔ要素に見いだされるすべてのＣｏｎｔｅｎｔＩｄ属性を収集する。
【０５８５】
（２）ＬｉｃｅｎｓｅＰａｒｔ要素に見いだされるすべてのＢｕｎｄｌｅ要素を処理する。
【０５８６】
（３）上記において収集されたコンテンツＩＤのセットを開く。
【０５８７】
（４）関連オブジェクト上の適切な署名を検証する。
【０５８８】
（５）処理されたＣｏｎｔｒｏｌオブジェクト上のＣｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．Ｔｒａｎｓｆｅｒ．Ｃｈｅｃｋ方法を任意に呼び出す。
【０５８９】
（６）処理されたＣｏｎｔｒｏｌオブジェクト上のＣｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．Ｔｒａｎｓｆｅｒ．Ｐｅｒｆｏｒｍを呼び出す。
【０５９０】
Ｃｏｎｔｒｏｌプログラムが先を見越してシンクの近似照合を求めることを可能にすること。Ｃｏｎｔｒｏｌプログラムがこれを行えるようにするために、Ｏｂｌｉｃａｔｉｏｎｓ／Ｃａｌｌｂａｃｋｓの新しいペアを規定することができる。具体的には、制御は、「ＰｒｏｘｉｍｉｔｙＣｈｅｃｋＳｉｎｋ」義務をその拡張状態ブロックに置くことができる。これは、シンクとの近似を照合しなければならないことをアプリケーションに対して示す。近似照合が行われるときに、アプリケーションは、「ＯｎＳｉｎｋＰｒｏｘｉｍｉｔｙＣｈｅｃｋｅｄ」コールバックを使用して、制御をコールバックする。
【０５９１】
一実施形態において、ライセンス転送の状況においてのみ適用可能なＰｒｏｘｉｍｉｔｙＣｈｅｃｋ義務が規定される。この実施形態において、拡張状態ブロックごとにゼロまたは１つのそのような義務が存在する必要があり、存在する場合には、ＯｎＳｉｎｋＰｒｏｘｉｍｉｔｙＣｈｅｃｋｅｄコールバックも存在する必要がある。
【表７９】
2009512096.tif 000081
【０５９２】
ＯｎＳｉｎｋＰｒｏｘｉｍｉｔｙＣｈｅｃｋｅｄコールバック
【表８０】
2009512096.tif 000082
【０５９３】
プロトコルにおいて複数のラウンドトリップを可能にすること。図３３は、複数のラウンドトリップを可能にするプロトコルの変更を概説する。図３３に示す実施形態において、Ｓｅｔｕｐメッセージ３３０２は、例えば、ライセンス解決問題／解決策と関連して上述した改善されたライセンス転送リクエストメッセージと同一であり得る。
【０５９４】
図３３に示すように、Ｓｅｔｕｐ３３０２の後に、アプリケーションは、上記のようにＣｏｎｔｒｏｌを実行し、Ｅｘｔｅｎｄｅｄ  Ｓｔａｔｕｓ  Ｂｌｏｃｋ（ＥＳＢ）を獲得する。このＥＳＢは、ＲｕｎＡｇｅｎｔＯｎＰｅｅｒ義務／ＯｎＡｇｅｎｔＣｏｍｐｌｅｔｉｏｎコールバックを含んでもよい。一実施形態において、ＲｕｎＡｇｅｎｔＯｎＰｅｅｒ義務は、ソース３３１２アプリケーションがＲｕｎＡｇｅｎｔメッセージ３３０４を構築することを必要とするすべてのパラメータを含む。一実施形態において、アプリケーションが、ＯｎＡｇｅｎｔＣｏｍｐｌｅｔｉｏｎコールバックのＥｘｔｅｎｄｅｄ  Ｓｔａｔｕｓ  Ｂｌｏｃｋにおける別のＲｕｎＡｇｅｎｔＯｎＰｅｅｒ／ＯｎＡｇｅｎｔＣｏｍｐｌｅｔｉｏｎコールバック／義務のペアに遭遇する場合、ＲｕｎＡｇｅｎｔメッセージ３３０４も送信されることに留意されたい（１つ以上のＲｕｎＡｇｅｎｔ／ＡｇｅｎｔＲｅｓｕｌｔメッセージ交換の後）。
【０５９５】
一実施形態において、ＥＳＢが、ＲｕｎＡｇｅｎｔＯｎＰｅｅｒ義務／ＯｎＡｇｅｎｔＣｏｍｐｌｅｔｉｏｎコールバックを含まない場合、Ｔｅａｒｄｏｗｎメッセージを送信する必要があることを意味する（下記参照）。このＥＳＢは、ＰｒｏｘｉｍｉｔｙＣｈｅｃｋ義務／ＯｎＳｉｎｋＰｒｏｘｉｍｉｔｙＣｈｅｃｋｅｄコールバックを含んでもよいことに留意されたい。その場合、Ｔｅａｒｄｏｗｎメッセージを送信する前に、近似照合プロトコルが実行され、ＯｎＳｉｎｋＰｒｏｘｉｍｉｔｙ照合がされたコールバックのＥＳＢから結果が読み出される。
【０５９６】
一実施形態において、ＲｕｎＡｇｅｎｔメッセージ３３０４のペイロードは、ＣｏｎｔｅｎｔＫｅｙＬｉｓｔを運ばないことを除いて、以前の設計のＲｅｓｐｏｎｓｅメッセージと同一である。
【０５９７】
図３３に示すように、シンク３３１０は、ＲｕｎＡｇｅｎｔメッセージ３３０４のソースによって送信されるエージェントを実行した後、ＡｇｅｎｔＲｅｓｕｌｔメッセージ３３０６をソース３３１２に送信する。一実施形態において、メッセージペイロードは、図３２に関連して記載されるＣｏｎｆｉｒｍａｔｉｏｎメッセージと同一である。
【０５９８】
図３３に示すように、ＯｎＡｇｅｎｔＣｏｍｐｌｅｔｉｏｎの拡張状態ブロックが、任意のＲｕｎＡｇｅｎｔＯｎＰｅｅｒ／ＯｎＡｇｅｎｔＣｏｍｐｌｅｔｉｏｎコールバック／義務のペアを運ばないときに、ソースアプリケーション３３１２によってＴｅａｒｄｏｗｎメッセージ３３０８が送信され、これはプロトコルが終わっていることを意味する。一実施形態において、Ｔｅａｒｄｏｗｎメッセージ３３０８は、以下の２つの情報を運ぶ。（ｉ）プロトコル結果の記述（その結果、シンク３３１０は、プロトコルが成功したか否かを知り、成功しなかった場合は、なぜ失敗したかが示される（詳細は以下を参照））。（ｉｉ）プロトコルが成功した場合、アップデートされたＣｏｎｔｅｎｔＫｅｙオブジェクト（以前のメッセージにおけるＲｅｓｐｏｎｓｅのＣｏｎｔｅｎｔＫｅｙＬｉｓｔ）（設定メッセージのＮｅｅｄｓＣｏｎｔｅｎｔＫｅｙ要素が真に設定されるかまたは存在しない場合）。
【０５９９】
一実施形態において、プロトコル結果の記述は、実際に、制御の最後の呼出しのＥｘｔｅｎｄｅｄ  Ｓｔａｔｕｓ  Ｂｌｏｃｋ（ＥＳＢ）であり、エージェント関連の義務／コールバックのペアを運ばない。
【０６００】
失敗した場合、ＥＳＢのパラメータは、リソースを指し示してもよい。一実施形態において、これらのリソースは、Ｓｅｔｕｐメッセージにおいて送信されたＣｏｎｔｒｏｌのＲｅｓｏｕｒｃｅＬｉｓｔ拡張に位置づけられる。
【０６０１】
成功した場合、一実施形態において、キャッシュ持続時間は、制御を再び求めることなくＣｏｎｔｅｎｔ  Ｋｅｙが使用され得る時間の長さを示す。
【０６０２】
そのようなＥＳＢ  ＸＭＬ表現の実施例を、下記に示す。これを仮想マシンスキーマに追加することができる。
【表８１】
2009512096.tif 000083
【０６０３】
以下は、上述の改善されたライセンス転送メカニズムの実施形態に従うレンダリングユースケースの実施例である。この実施例において、ブロードキャストインポート関数は、以下のライセンスを有するコンテンツをインポートする。−Ｐｌａｙ：ローカル状態が存在する場合はＯＫである。
−Ｔｒａｎｓｆｅｒ：
−Ｒｅｎｄｅｒ：シンクがドメインＸにある場合、またはシンクが近似にある場合はＯＫである。
一度に１つの平行ストリームのみをレンダリングできる。
【０６０４】
Ｃｏｒｅ  ＤＲＭＣｌｉｅｎｔ１がコンテンツストリームをレンダリングする許可をリクエストすると仮定されたい。Ｓｅｔｕｐ  Ｒｅｑｕｅｓｔは、シンク（Ｃｏｒｅ  ＤＲＭＣｌｉｅｎｔｌ）から、以下のパラメータを含むＳｏｕｒｃｅ（ＢＣインポート関数）まで送信される。
−Ｌｉｃｅｎｓｅ：シンクがレンダリングすることを望むコンテンツに関連するライセンス
−Ｏｐｅｒａｔｉｏｎ＝ｕｒｎ：ｍａｒｌｉｎ：ｃｏｒｅ：１−０：ｓｅｒｖｉｃｅ：ｌｉｃｅｎｓｅ−ｔｒａｎｓｆｅｒ：ｒｅｎｄｅｒ
−Ｂｕｎｄｌｅ＝シンクのＰｅｒｓｏｎａｌｉｔｙノード
【０６０５】
リクエストを受信すると、ソースアプリケーションは、関連するホストオブジェクトにデータを読み込み、Ｃｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．Ｔｒａｎｓｆｅｒ．Ｐｅｒｆｏｒｍ方法を呼び出す。レンダリング転送を管理する方法のための例示的な擬似コードを以下に示す。
【表８２】
2009512096.tif 000084
【０６０６】
レンダリングがロックされないと仮定して、ＲｕｎＡｇｅｎｔＯｎＰｅｅｒ義務が実行される。ＲｕｎＡｇｅｎｔメッセージは、ＣｈｅｃｋＤｏｍａｉｎＡｇｅｎｔ方法を含むＣｏｎｔｒｏｌとともに送信される。このメッセージを受信すると、シンクは、関連するホストオブジェクトにデータを読み込み、ＣｈｅｃｋＤｏｍａｉｎＡｇｅｎｔ方法を呼び出す。ＣｈｅｃｋＤｏｍａｉｎＡｇｅｎｔのための例示的な擬似コードを以下に示す。
【表８３】
2009512096.tif 000085
【０６０７】
説明のために、シンクが実際にドメイン内にあると仮定されたい。シンクは、このエージェント結果を含むＡｇｅｎｔＲｅｓｕｌｔメッセージを送信する。ＡｇｅｎｔＲｅｓｕｌｔを受信すると、ソースは、コールバック方法を呼び出す。ＲｅｎｄｅｒＡｇｅｎｔＣｏｍｐｌｅｔｅｄのための例示的な擬似コードを以下に示す。
【表８４】
2009512096.tif 000086
【０６０８】
シンク上のドメイン帰属関係をエージェントが首尾よく照合したと仮定されたい。Ｔｅａｒｄｏｗｎメッセージは、以下の２つとともに送信される。（ｉ）シンクのための再暗号化されたコンテンツ鍵（Ｓｅｔｕｐリクエストにおいてシンクノードが提供される鍵を使用する）。（ｉｉ）上記で指定されたキャッシュ持続時間を運ぶＥＳＢ（この場合は０であり、次回にコンテンツへのアクセスを望む際に、シンクは再要求をしなければならないことを意味する）。シンクは、このメッセージを受信するときに、コンテンツのレンダリングが許可され、必要なコンテンツ鍵を有する、ということを知る。
【０６０９】
ここで、ユーザが自分の他の装置（ＤＲＭＣｌｉｅｎｔ２）上のコンテンツをレンダリングすることを望むと仮定されたい。問題は、コンテンツがソース上で１８０分にわたってロックされるということである。幸いにも、ユーザがＤＲＭＣｌｉｅｎｔｌ上のＳＴＯＰを押すと、ＤＲＭＣｌｉｅｎｔｌは、Ｒｅｌｅａｓｅという操作によって新しいライセンス転送プロトコルを開始する。リクエストを受信すると、ソースアプリケーションは、関連するホストオブジェクトにデータを読み込み、Ｃｏｎｔｒｏｌ．Ａｃｔｉｏｎｓ．Ｔｒａｎｓｆｅｒ．Ｐｅｒｆｏｒｍ方法を呼び出す。転送リリースを管理する方法のための例示的な擬似コードを以下に示す。
【表８５】
2009512096.tif 000087
【０６１０】
義務／コールバックがＥＳＢに見いだされないので、このことは、ＴｅａｒｄｏｗｎメッセージがこのＥＳＢとともに送信されることを意味する。
【０６１１】
従って、このレンダリングユースケースは、一定の実施形態において、以下のことを示す。レンダリング操作のリクエスト側のＤＲＭＣｌｉｅｎｔは、ローカルに制御を再評価する必要がない。状態は、ソースからシンクまで転送される必要がない。制御は、先を見越して近似照合を求めることができる。それによってレンダリングが行われたときに、コンテンツをリリースすることができる。
１１．証明書
【０６１２】
一実施形態において、証明書は、鍵によって作成されるデジタル署名に基づいて決定を行う前に、暗号鍵に関連する証明を照合するために使用される。
【０６１３】
一部の実施形態において、ＤＲＭエンジンは、標準的な証明技術と互換性があるように設計され、そのような証明の要素（例えば有効期間、名前など）に見いだされる情報に影響を及ぼすことができる。それらの基本的制約に加えて、一部の実施形態において、認証された鍵を使用できる（およびできない）目的に関する、更なる制約を規定することができる。例えば、このことは、証明書の標準的なコード化の一部として利用可能な鍵使用拡張を使用することによって達成することができる。そのような拡張においてコード化される情報は、特化オブジェクトに署名した鍵をこの目的のために使用することが認可されたか否かを、ＤＲＭエンジンが照合することを可能にする。例えば、一定の鍵は、証明書を有してもよい。この証明書によって、リンクが、特定の属性を有するノードから、別の特定の属性を有するノードに対するものであり、他のいかなるリンクもない場合のみに、鍵はリンクオブジェクトに署名することができる。証明書を表現するために使用される一般的な技術のセマンティクスは、そのような制約を表現することが一般にできない（例えばリンクおよびノードなどのＤＲＭエンジン特有の要素に関する条件を表現する方法を有しない）。従って、一実施形態において、そのようなＤＲＭエンジン特有の制約は、ＤＲＭエンジンを使用するように構成されたアプリケーションによって処理される基本的証明書の鍵使用の拡張を意味する。
【０６１４】
一実施形態において、鍵使用法拡張における制約は、使用カテゴリおよびＶＭ制約プログラムによって表現される。使用カテゴリは、鍵が署名することを認可されるオブジェクトのタイプを指定する。制約プログラムは、コンテキストに基づいて動的な条件を表現することができる。一実施形態において、そのような証明書の有効性を検証するよう求められる任意の検査機構は、ＤＲＭエンジンセマンティクスを理解する必要があり、鍵使用拡張表現の評価をＤＲＭエンジンに委任する。ＤＲＭエンジンは、仮想マシンのインスタンスを使用することによってプログラムを実行する。そのプログラムの実行の結果が成功である場合、証明書は有効であるとみなされる。
【０６１５】
一実施形態において、制約プログラムの役割は、ブール値を返すことである。「真」は、制約条件が満たされることを意味し、「偽」は、制約条件が満たされないことを意味する。一実施形態において、制御プログラムは、決定に到達するために使用できる一部のコンテキスト情報（例えば仮想マシンのホストオブジェクトインタフェースを通してプログラムに利用可能な情報）にアクセスする。コンテキストとして利用可能な情報は、ＤＲＭエンジンが証明書の検証をリクエストするときに実行を試みる決定のタイプに依存する。例えば、一実施形態において、リンクオブジェクトにおける情報を使用する前に、ＤＲＭエンジンは、オブジェクトに署名した鍵の証明書がその目的のためにその鍵の使用を許可することを検証する。制約プログラムを実行するときに、仮想マシンの環境は、リンクの属性（ならびにリンクによって参照されるノードの属性）に関する情報によって占有される。
【０６１６】
一実施形態において、鍵使用拡張に埋め込まれる制約プログラムは、「Ｏｃｔｏｐｕｓ．Ｃｅｒｔｉｆｉｃａｔｅ．＜Ｃａｔｅｇｏｒｙ＞．Ｃｈｅｃｋ」という名前の少なくとも１つのエントリポイントをエクスポートする仮想マシンコードモジュールとしてコード化される。ここで「カテゴリ」は、照合する必要のある証明書のカテゴリを示す。検証プログラムに対するパラメータは、エントリポイントを呼び出す前に、スタック上にプッシュされる。スタックに渡されるパラメータの数およびタイプは、評価される証明書拡張のカテゴリに一般に依存する。
【０６１７】
１２．デジタル署名
好ましい実施形態において、ＤＲＭエンジンにより用いられるオブジェクトの一部または全部は、署名される。以下は、一実施形態において、ＸＭＬデジタル署名仕様（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｍｌｄｓｉｇ−ｃｏｒｅ）（「ＸＭＬＤＳｉｇ」）を使用して、オブジェクトにデジタル署名をする方法の説明である。それに加えて、ＸＭＬ排他的標準化と互換性のあるＸＭＬの標準化方法（ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｘｍｌ−ｅｘｃ−ｃｌ４ｎ／）（「ｃｌ４ｎ−ｅｘ」）も記載する。この出力は、非ＸＭＬ名前空間認識パーサによって処理できる。付録Ｄは、例示的なオブジェクトシリアライゼーションに関する詳細な情報を提供するものであり、コード化に依存しない態様におけるオブジェクトのための標準的なバイト列を算出する例示的な方法を含む。
【０６１８】
図２８、図３４、および図３５に示すように、好ましい実施形態において、ＤＲＭライセンスの一定の要素は署名される。図２８、図３４、および図３５に示すような技術は、ライセンス構成要素の不正操作または置換を防止または妨害するのに有用である。図３４に示すように、好ましい実施形態において、コントローラオブジェクト３４０２は、コンテンツ鍵オブジェクト３４０４および制御オブジェクト３４０６のそれぞれの、暗号ダイジェストまたはハッシュ（または他の適切な結合）３４０５、３４０７を含む。コントローラ３４０２自体は、ＭＡＣ（または好ましくはコンテンツ鍵を利用するＨＭＡＣ）、および（一般にコンテンツまたはライセンスプロバイダの）公開鍵署名３４１２によって署名される。好ましい実施形態において、コントローラ３４１２の公開鍵署名自体は、コンテンツ鍵を使用するＨＭＡＣ３４１０によって署名される。他の実施形態において、所望の安全レベルおよび／または他のシステム要件に依存して、他の署名スキームを使用できることが理解される。例えば、コントローラおよび／または制御（例えばＰＫＩ、標準ＭＡＣなど）の署名のために、異なる署名スキームを使用することができる。別の例として、制御およびコントローラについて、独立したＭＡＣ署名を算出することができる（コントローラに制御のダイジェストを含んだり、コントローラの単一のＭＡＣ署名を算出したりするかわりに）。さらに別の例において、コントローラは、ＭＡＣおよび公開鍵署名によって署名され得る。それに代わって、またはそれに加えて、上述の鍵とは異なる鍵を使用することによって、様々な署名を生成することができる。従って、図２８、図３４、および図３５は、一部の実施形態に従ういくつかの有利な署名技術を例示するが、これらの技術は例示的かつ非限定的なものであることが理解される。図３５は、コントローラが複数のコンテンツ鍵を参照する実施形態を例示する。図３５に示すように、一実施形態において、コンテンツ鍵の各々は、コントローラおよびＰＫＩ署名のＨＭＡＣを生成するために使用される。
【０６１９】
一実施形態において、ＸＭＬ標準化のためのデータモード、処理、入力パラメータ、および出力データは、名前空間接頭語が除去される（名前空間はデフォルト名前空間メカニズムを使用して示される）こと、および外部実体がサポートされず、キャラクタエンティティのみがサポートされることを除いて、排他的標準ＸＭＬ（ｃｌ４ｎ−ｅｘ）に関するものと同一である。第１の限定は、属性およびその要素が同一の名前空間の中にある必要があることを意味する。
【０６２０】
図４２は、一実施形態における、ｃｌ４ｎ−ｅｘと例示的ＸＭＬ標準化との関係を示す。ここで、＜ｘｍｌ＞は任意の有効なＸＭＬであり、＜ｘｍｌ＞が外部実体および名前空間接頭語を有する場合のみに、＜ｘｍｌ＞'＝＜ｘｍｌ＞''である。
【０６２１】
簡略化された署名スキームの単純な実施例を、以下に提供する。しかしながら、好ましい実施形態において、標準ＸＭＬ標準化が使用される。
【表８６】
2009512096.tif 000088
【０６２２】
このセクションにおいて論ずる署名要素は、ＸＭＬＤＳｉｇ名前空間に帰属し（ｘｍｌｎｓ＝ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃）、ＸＭＬＤＳｉｇ仕様で規定されるＸＭＬスキーマにおいて規定される。一実施形態において、ＤＲＭオブジェクトのＸＭＬ表現のコンテナ要素は、＜Ｂｕｎｄｌｅ＞要素である。
【０６２３】
一実施形態において、以下のオブジェクトは、署名される必要がある。
・Ｎｏｄｅ
・Ｌｉｎｋ
・Ｃｏｎｔｒｏｌｌｅｒ
・Ｃｏｎｔｒｏｌ（任意）
・Ｅｘｔｅｎｓｉｏｎ（運ぶデータに依存する）
【０６２４】
一実施形態において、署名は切り離される必要があり、＜Ｓｉｇｎａｔｕｒｅ＞要素は、署名される必要のあるオブジェクトのＸＭＬ表現を含む＜Ｂｕｎｄｌｅ＞オブジェクトの中に存在する必要がある。
【０６２５】
一実施形態において、＜Ｓｉｇｎａｔｕｒｅ＞ブロックは、以下を含む。
・＜ＳｉｇｎｅｄＩｎｆｏ＞要素
・＜ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞要素
・＜ＫｅｙＩｎｆｏ＞要素
【０６２６】
一実施形態において、＜ＳｉｇｎｅｄＩｎｆｏ＞は、以下の要素を埋め込む。
【０６２７】
＜ＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ＞。一実施形態において、＜ＣａｎｏｎｉｃａｌｉｚａｔｉｏｎＭｅｔｈｏｄ＞要素は、空であり、そのＡｌｇｏｒｉｔｈｍ属性は、以下の値を有する。
・ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２００１／１０／ｘｍｌ−ｅｘｃ−ｃｌ４ｎ＃
【０６２８】
＜ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ＞。一実施形態において、＜ＳｉｇｎａｔｕｒｅＭｅｔｈｏｄ＞要素は、空であり、そのＡｌｇｏｒｉｔｈｍ属性は、以下の値を有する。
・ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇｔ＃ｈｍａｃ−ｓｈａｌ（ＨＭＡＣ署名）
・ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇｔ＃ｒｓａ−ｓｈａｌ（公開鍵署名）
【０６２９】
＜Ｒｅｆｅｒｅｎｃｅ＞。一実施形態において、複数のオブジェクトが同一の鍵によって署名される必要がある場合、＜ＳｉｇｎｅｄＩｎｆｏ＞ブロックの内部に１つ以上の＜Ｒｅｆｅｒｅｎｃｅ＞要素があり得る（例えばＣｏｎｔｒｏｌおよびＣｏｎｔｒｏｌｌｅｒオブジェクトの場合がそうである）。
【０６３０】
一実施形態において、オブジェクトに署名するときに、＜Ｒｅｆｅｒｅｎｃｅ＞要素の「ＵＲＩ」属性の値は、参照されるオブジェクトのＩＤである。ローカルなＸＭＬ要素に署名するときに（例えばＣｏｎｔｒｏｌｌｅｒオブジェクトのための公開署名方法の複数署名の場合において）、ＵＲＩの値は、参照される要素の「ＩＤ」属性の値である。
【０６３１】
一実施形態において、参照がオブジェクトを指し示すときに、参照においてダイジェストされるものは、オブジェクトのＸＭＬ表現ではなく、その標準的バイト列である。オブジェクトのこのトランスフォームは、＜Ｔｒａｎｆｏｒｍｓ＞ブロックによってＸＭＬＤＳｉｇにおいて示される。従って、一実施形態において、＜Ｒｅｆｅｒｅｎｃｅ＞要素は、以下のブロックを埋め込む。
【表８７】
2009512096.tif 000089
【０６３２】
付録Ｄは、追加情報を提供する。一実施形態において、オブジェクト参照のために他の＜Ｔｒａｎｆｏｒｍ＞は許可されない。
【０６３３】
一実施形態において、＜ＤｉｇｅｓｔＭｅｔｈｏｄ＞要素は、空であり、そのＡｌｇｏｒｉｔｈｍ属性は、以下の値を有する。
・ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｓｈａｌ
【０６３４】
＜ＤｉｇｅｓｔＶａｌｕｅ＞要素は、ダイジェストのベース６４コード化された値を含む。
【０６３５】
＜ＳｉｇｎａｔｕｒｅＶａｌｕｅ＞。一実施形態において、署名値は、＜ＫｅｙＩｎｆｏ＞要素において記述される鍵を有する標準化された（ｅｘ−ｃｌ４ｎ）＜ＳｉｇｎｅｄＩｎｆｏ＞要素の署名の、ベース６４コード化された値である。
【０６３６】
＜ＫｅｙＩｎｆｏ＞
・コントローラオブジェクトの署名のためのＨＭＡＣ−ＳＨＡ１の場合
【０６３７】
一実施形態において、この場合、＜ＫｅｙＩｎｆｏ＞は、１つの子のみ、すなわちＨＭＡＣ署名のために使用された鍵のＩＤを示す＜ＫｅｙＮａｍｅ＞を有する。
【０６３８】
【表８８】
2009512096.tif 000090
【０６３９】
一実施形態において、この場合、署名を検証するために使用される公開鍵は、Ｘ．５０９  ｖ３証明書において運ばれ、ＣＡルートに証明書経路を完了するのに必要な他の証明書を伴い得る。
【０６４０】
これらの証明書は、＜Ｘ５０９Ｃｅｒｔｉｆｉｃａｔｅ＞要素において、運ばれ、ベース６４においてコード化される。これらの＜Ｘ５０９Ｃｅｒｔｉｆｉｃａｔｅ＞要素は、＜ＫｅｙＩｎｆｏの＞要素の＜Ｘ５０９Ｄａｔａ＞要素の子に埋め込まれ、署名する鍵の証明書から始まる順番で現れる。ルートの証明書は、通常は除外される。
【０６４１】
実施例（簡潔さのために、例示的な証明書の値をすべて再現するわけではなく、削除されたマテリアルは省略記号によって示される）。
【表８９】
2009512096.tif 000091
【０６４２】
一実施形態において、コントローラオブジェクトは、制御されるターゲットのリストにおいて参照されるＣｏｎｔｅｎｔＫｅｙごとに、少なくとも１つのＨＭＡＣ署名を有する必要がある。それらの署名の各々のために使用される鍵は、参照されるＣｏｎｔｅｎｔＫｅｙオブジェクトに含まれるコンテンツ鍵の値である。
【０６４３】
コントローラはまた、ＲＳＡ署名を有してもよい。一実施形態において、そのような署名が存在する場合、この署名は、オブジェクトのためのＨＭＡＣ署名の各々における＜Ｒｅｆｅｒｅｎｃｅ＞としても現れる。このことを達成するために、一実施形態において、ＲＳＡ署名のための＜Ｓｉｇｎｔｕｒｅ＞要素は、囲むＸＭＬ文書の範囲内で一意の「ＩＤ」属性を有しなければならない。この属性は、ＨＭＡＣ署名の各々の＜Ｒｅｆｅｒｅｎｃｅ＞要素のうちの１つにおける「ＵＲＩ」属性として使用される。一実施形態において、検査機構は、ＨＭＡＣ署名によって実証されないＲＳＡ署名を拒絶しなければならない。
【０６４４】
実施例
【表９０】
2009512096.tif 000092
【０６４５】
１３．近似照合プロトコル
一部の実施形態において、リクエストするエンティティの物理的な近似に基づいて、コンテンツ、サービスおよび／または他のシステム資源へのアクセスを限定することは、望ましい場合がある（例えば、保護されたコンテンツが、ユーザのホームネットワークやオフィス総合ビルなどの外ではコピーできないことを示す規則の実施を補助するため）。近似照合プロトコルの実施形態を以下に記載する。これは、近似照合自体の実行を不適当に妨げることなくセキュリティを提供するものである。近似照合プロトコルは、多種多様な状況における応用に役立つ。そのうちの１つは、上記のように、デジタル著作権管理の状況である。しかしながら、以下に記載する近似照合のシステムおよび方法は、応用において、デジタル著作権管理の状況に限定されないことが理解される。例えば、限定するものではないが、本明細書に示す近似照合技術は、ネットワークサービス編成システム（例えば'５５１出願および／または任意の他の適切な文脈において記載されるようなシステム）の状況においても使用できる。
【０６４６】
一実施形態において、近似照合は、第１コンピューティングノードのリクエストに対する第２コンピューティングノードからの応答を第１コンピューティングノードが受信するのに要する時間の量を計測することによって実行される。その時間が定義済みの閾値未満である場合（一般に第２コンピューティングノードが第１コンピューティングノードの一定の物理的距離の範囲内にあることを示す）、近似照合は成功とみなされる。
【０６４７】
リクエストおよび／または応答が送信され得る多種多様な異なるネットワーク接続のために、所与の時間は、可能な距離の範囲に対応してもよいことが理解される。一部の実施形態において、リクエスト／応答の交換の往復の時間が定義済みの閾値（例えば８ミリ秒または他の任意の適切な時間）未満である場合、例えば高速ネットワーク接続が使用されているか否かに関係なく、このバリエーションは単に無視され、近似照合は成功とみなされる。このことは、リクエストするノードと応答するノードとが、実際に互いに比較的遠くに離れていることを意味し得る。他の実施態様において、使用されるネットワーク接続のタイプに関する決定を行うことができ、異なる往復時間の必要条件は、それぞれの異なるネットワーク接続に適用され得る。
【０６４８】
好ましい実施形態において、近似照合は、アンカー（例えばクライアント）がターゲット（例えばサービス）の近似を照合することを可能にする。一実施形態において、アンカーは、使用される秘密シードを生成し、安全なタイマーを利用する唯一のものであるという点において、プロトコルは非対称である。さらに、ターゲットは、アンカーを信頼する必要はない。近似照合の好ましい実施形態はまた、暗号的に効率的であり、一実施形態において、２つの公開鍵操作のみが利用される。
【０６４９】
シードＳからのＱペアのセットＲの生成
【０６５０】
一実施形態において、セットＲは、以下の式に従ってシードＳから入手される：Ｒi＝Ｈ2Q-i（Ｓ）。ここで、Ｈ（Ｍ）は、メッセージＭにわたるハッシュ関数Ｈのダイジェスト値であり、ｎ＞＝ｌについてＨn（Ｍ）＝Ｈ（Ｈn-1（Ｍ））であり、Ｈ0（Ｍ）＝Ｍである。これは、共有された秘密を生成するための単なる１つの例示的な技術であり、他の実施形態において、本発明の原理から逸脱することなく、他の技術を使用できることが理解される。
【０６５１】
一実施形態において、ハッシュ関数Ｈのために使用されるアルゴリズムはＳＨＡ１である（米国商務省／国立標準技術研究所のＦＩＰＳ  ＰＵＢ１８０−１．Ｓｅｃｕｒｅ  Ｈａｓｈ  Ｓｔａｎｄａｒｄを参照）。但し、他の実施例において、他のハッシュ、メッセージダイジェスト、または機能を使用できることが理解される。
【０６５２】
一実施形態において、近似照合は以下の通りに実行される。ここで、「Ａ」はアンカー（例えばクライアント）であり、「Ｂ」はターゲット（例えばサービス）である。
【０６５３】
（ａ）Ａは、乱数のＱペアのセットＲを、｛Ｒ0、Ｒ1｝、｛Ｒ2、Ｒ3｝…｛Ｒ2Q-2、Ｒ2Q-1｝のように生成する。
【０６５４】
（ｂ）Ａは、Ｅ（ＰｕｂＢ｛Ｑ，Ｓ｝）をＢに送信する。ここでＥ（Ｙ（Ｘ））は、鍵Ｙを有するＸの暗号化を表し、ＰｕｂＢは、公開鍵／秘密鍵のペアにおけるＢの公開鍵を表す。
【０６５５】
（ｃ）Ｂは、上記のような｛Ｑ，Ｓ｝を解読し、Ｒを事前計算する。
【０６５６】
（ｄ）Ｂは、Ａに受信通知を送信することにより、進行準備ができていることを示す。
【０６５７】
（ｅ）Ａは、ループカウンタｋをゼロに設定する。
【０６５８】
（ｆ）Ａは、Ｔ0＝現在時刻を測定する。
【０６５９】
（ｇ）Ａは、｛ｋ、Ｒ2*k｝をＢに送信する。
【０６６０】
（ｈ）Ｒ2*kの値が正しい場合、ＢはＲ2*k+1によって応答する。
【０６６１】
（ｉ）Ａは、Ｄ＝新しい現在時刻−Ｔ0を測定する。
【０６６２】
（ｊ）ＢがＲ2*k+1の正しい値をAに応答し、およびＤが定義済みの閾値未満である場合、近似照合は成功とみなされる。
【０６６３】
ｋ＋１＜Ｑである場合、Ａは、ｋを増加させ、ステップ（ｆ）に行くことによって、新しい測定を再試行することができる。Ｑ以上の測定を実行する必要がある場合、Ａは、新しいセットＲを用いて、ステップ（ａ）から開始することができる。例えば、一部の実施形態において、定義済みの閾値の範囲内で正しい応答が受信されるまで（または一連の呼掛け／応答の定義済みのパーセントを超える定義済みの閾値の範囲内で正しい応答が受信される場合に）、近似照合を繰り返し（または定義済みの回数にわたって）実行することができる。なぜなら、たとえ２つのコンピューティングノードが互いに必要な近似の範囲内にある場合であっても、異常に遅いネットワーク接続、重いトラフィック、ノイズなどのために、Ｂの応答が遅れることがあるからである。
【０６６４】
図３６は、上述のプロトコルの実施形態を例示する。ここで、アンカー（Ａ）は、ターゲット（Ｂ）がアンカー（Ａ）の許容可能な近似の範囲内にあるか否かを決定する。例えば、図３６に示すように、Ａは、コンピューティングノード３６０２を含んでもよい。コンピューティングノード３６０２は、保護されたコンテンツ（例えば音楽、ビデオ、テキスト、ソフトウェアなど）、および／またはコンテンツアクセスマテリアル（例えばリンク、鍵など）を含み、これらは、リモートコンピューティングノードＢ３６０６が、コンピューティングノードＢ３６０６に格納された（またはアクセス可能な）保護されたコンテンツにアクセスするために必要とするものである。コンテンツまたはコンテンツアクセスマテリアルに関連する制御は、ノードＡ３６０２の一定の近似の範囲内で装置との共有が可能であることを示してもよい（例えば、コンテンツの配信をホームネットワークに制限することを近似する）。それに代わって、またはそれに加えて、そのようなポリシーは、コンピューティングノードＡ３６０２のシステムレベルにおいて実施されてもよい（例えば、ホームネットワークまたは社内ネットワークのドメインマネージャを含んでもよい）。すなわち、近似照合は、仮想マシンによって実行される制御プログラムにおける条件である必要はない。これに代わって、近似照合は、単に、コンピューティングノードＡ３６０２が、コンテンツまたはコンテンツアクセスマテリアルをコンピューティングノードＢ３６０６に送信する前に、操作上のポリシーの問題として必要とするものである。そのような制御および／またはポリシーを実施するために、コンピューティングノードＡ３６０２上で実行するソフトウェアおよび／またはハードウェアは、保護されたコンテンツまたはコンテンツアクセスマテリアルをコンピューティングノードＢ３６０６に配信するリクエストが行われるたびに、上記の近似照合プロトコルを実行することができる。それに代わって、またはそれに加えて、近似照合は、ノードＢ３６０６が必要な近似の中にあるか否かを決定するために、定義済みの間隔で（例えば、一日に一回）実行することができる。近似照合が成功した場合、ノードＢ３６０６は、定義済みの期間にわたって（例えば、次回の照合が実行されるまで、または定義済みの時間が経過するまでなど）必要とされる近似の範囲内にあるものとして扱われる。
【０６６５】
図３６に示すように、ＡおよびＢが任意の初期設定ステップ（例えば上記のステップ（ａ）〜（ｅ））３６０４および３６０８を完了すると、ＡおよびＢは、安全な計時された呼掛け応答交換（例えば上記のステップ（ｆ）〜（ｉ））３６１０を行うことによって、Ａは、Ｂが許容可能な近似の範囲内にあるか否かを決定できる。
【０６６６】
図３６に示すように、一実施形態において、Ａ３６０２は、Ｂ３６０６に、Ｅ（ＰｕｂＢ｛Ｑ、Ｓ｝）（すなわち、Ｂの公開暗号化鍵（例えばサービス編成の状況においてＢによって使用される鍵）によって暗号化された、ペアの数Ｑ、ならびに秘密ペアシードＳ）を含む設定リクエスト３６０４を送信する。一実施形態において、｛Ｑ、Ｓ｝は、ネットワークバイト順におけるＱ（１バイト）およびＳ（１６バイト）のバイトストリーム結合である。一実施形態において、暗号化は、ＲＳＡ公開鍵暗号を使用して実行される（例えば、Ｂ．ＫａｌｉｓｋｉおよびＪ．ＳｔａｄｄｏｎによるＰＫＣＳ＃１：ＲＳＡ暗号仕様バージョン２．０．ＩＥＴＦ  ＲＦＣ２４３７（１９９８年１０月）に記載される）。好ましい実施形態において、ＰｕｂＢは、検査を通してＡによってすでにアクセスされており、その証明書は検証されている。図３６には、Ｂ３６０６からＡ３６０２への設定応答３６０８が示されているが、他の実施例において、設定応答３６０８は使用されない。前述のように、設定リクエスト３６０４を受信した後に、Ｂ３６０６は、好ましくはセットＲを事前計算することによって、Ａ３６０２からの次の呼掛けに対する迅速な応答を容易にする。
【０６６７】
図３６に示すように、Ａ３６０２は、Ｂに対して、［ｋ、Ｒ2*k］（すなわち、インデックスｋ、およびシードから算出される対応する秘密）からなる呼掛けリクエスト３６１２を送信する。一実施形態において、［ｋ、Ｒ2*k］は、ネットワークバイト順におけるｋ（１バイト）およびＲ2*k（２０バイト）のバイトストリーム結合である（トランスポートのためにベース６４においてコード化されている）。図３６に示すように、一実施形態において、Ｂ３６０６は、Ａ３６０２に呼掛け応答３６１４を送信するように操作可能である。呼掛け応答３６１４は、Ｒ2*k+1（すなわち呼掛けリクエスト３６１２からの対応する秘密）からなる。一実施形態において、Ｒ2*k+1は、ネットワークバイト順におけるＲ2*k+1（２０バイト）のバイトストリームであり、トランスポートのためにベース６４においてコード化されている。
【０６６８】
図３７は、保護されたコンテンツへのアクセスを制御するために上述の近似照合プロトコルの実施形態を使用する方法の実施例を示す。図３７を参照して、ケーブルまたは衛星コンテンツプロバイダは、ユーザの個人ビデオレコーダ（ＰＶＲ）３７０２の定義済みの近似３７０８の範囲内にあるすべての装置がＰＶＲを通してコンテンツにアクセスすることを可能にするポリシーを有する、と仮定されたい。従って、例えば、ＰＶＲ３７０２上で実行するドメインマネージャソフトウェアは、ＰＶＲ３７０２を通してコンテンツにアクセスすることをリクエストする装置３７０４および３７０６について、近似照合を実行してもよい。図３７に示す実施例において、装置３７０６は、サービスプロバイダのポリシーによって規定される近似３７０８の範囲内にないので、ＰＶＲ３７０２によるアクセスを拒絶され得る。これとは対照的に、装置３７０４は、近似の範囲内にあるので、アクセスを提供され得る（例えば、装置３７０４からＰＶＲ３７０２への失効するリンクとともにコンテンツを受信することによって）。それに代わって、またはそれに加えて、リンクは、制御プログラムを含んでもよい。制御プログラムは、ＰＶＲ３７０２による近似照合を開始し、装置３７０４がＰＶＲ３７０２の定義済みの近似３７０８の範囲を越えて移動する場合、装置３７０４がコンテンツに更にアクセスすることを拒絶するように操作可能である。
【０６６９】
セキュリティ考慮事項
【０６７０】
好ましい実施形態において、以下の一部又は全部を順守するような配慮を行うべきである。
・任意のセットＲの同一の値ｋについて、ステップ（ｆ）〜（ｉ）からなるループが繰り返されないこと。
・いずれかの当事者によって予想外のメッセージが受信される場合（以下の場合を含む）、プロトコルが中断されること。
○ステップ（ｇ）において、Ｂが、Ｒ2*kｉｎについて正しくない値を受信する場合。
○ステップ（ａ）において、Ｑが、指定された範囲内にない場合。
○ｋが、ループにおいて繰り返される場合。
○ｋがＱを超過する場合。
【０６７１】
それに代わって、またはそれに加えて、ステップ（ｈ）において、Ａが、Ｒ2*k+1ｉｎについて正しくない値を受信する場合、プロトコルは中断され得る。他の実施態様において、一定数のＢからの正しくない応答は許容されてもよい。
【０６７２】
Ｑおよび定義済みの時間閾値についての最適な値は、手元にあるアプリケーションの一意な状況（例えば、ネットワークの速度、比較的厳重な近似を確実にする重要性など）に一般に依存することが理解される。従って、インプリメンテーションは、これらの値を構成する際に、好ましくは柔軟性を提供すべきである。一実施形態において、インプリメンテーションは、Ｑについては６４の極小値を、閾値については８ｍｓの値をサポートすることが仮定される（現今のネットワーク速度の一部において、８ｍｓは数マイルの近似に対応し得る）。
【０６７３】
プロトコルセキュリティポリシー
【０６７４】
好ましい実施形態において、リクエストおよび応答の交換のために、更なるセキュリティは必要ではない。交換されるメッセージのサイズ（例えば２０バイト）、およびそれらの有効なランダム性のために（ＳＨＡ１ハッシュアルゴリズムまたは他の方法を用いることにより）、たとえ攻撃者がリクエストをどうにか傍受したとしても、攻撃者が正しい応答を決定することは暗号的に実行不可能である。
【０６７５】
上記の実施形態は例示的なものであり、本明細書に提示する進歩性のある原理から逸脱することなく、数多くの変更を行うことができることが理解されるべきである。例えば、再帰的にハッシュされた秘密のシードを記載するが、呼掛け／応答のために任意の適切な共有される秘密を使用できる。一実施形態において、共有された秘密は、ＡからＢに送信される暗号化された数／メッセージを単に含んでもよく、呼掛け／応答は、ＡおよびＢが数／メッセージの一部を交換することを単に含み得る（例えば、ＡはＢにメッセージの第１キャラクタを送信し、ＢはＡにメッセージの第２キャラクタを送信する、などである）。そのような技術は、図３６に関連して記載する実施形態のセキュリティを欠くことがあるが（メッセージ内のキャラクタは２０バイトハッシュよりもはるかに推測が容易だからである）、一部の実施形態において、そのようなレベルのセキュリティが適切であり得る（例えば、特に、ネットワーク遅延の可変性によって、近似照合メカニズムが実際の近似の粗い制御になる場合）。また、他の実施形態において、近似照合を複数回実行することによって、セキュリティを高めることができる。その場合、任意の特定の数字またはビットは比較的に容易に推測できるが、攻撃者が数字またはビットの所与のシーケンスを正しく推測できる可能性は、シーケンスの長さとともに急速に減少する。そのような実施形態において、連続的な正しい応答の定義済みの数（または正しい応答の定義済みのパーセント）よりも多くを、Ｂが提供できる場合のみに、近似照合は成功とみなされ得る。
【０６７６】
実例および説明のために、近似照合プロトコルの更なる例示的な実施例を以下に提供する。この実施例において、第１装置ＳＲＣは、通信チャネル（例えばコンピュータネットワーク）を通じて、第２装置ＳＮＫと通信する。ＳＮＫがＳＲＣからの通信リクエストに応答する所用時間によって測定されるように、ＳＲＣおよびＳＮＫが互いの近似の範囲内にあるか否かを確実に決定できることが望ましい。呼掛けまたはプローブメッセージは、ＳＲＣからＳＮＫに送信され、ＳＮＫは応答メッセージによって応じる。呼掛けの放出と応答の受信と間の期間は、ラウンドトリップ時間またはＲＴＴと呼ばれる。ＳＮＫが算出して呼掛けに応答を送信するためにかかる時間に、不必要なオーバヘッドを導入することを回避するために、呼掛け／応答通信を可能な限り軽量にすることが一般に望ましい。特に、呼掛けの放出と応答の受信との間で、ＳＲＣまたはＳＮＫによる暗号操作を必要とすることを回避することは、一般に望ましい。
【０６７７】
また、ＳＮＫのみがＳＲＣからの呼掛けに対して有効な応答を生成できることを確実にするために（例えば、あたかもＳＮＫが応答したかのように、第三者がＳＲＣからの呼掛けを傍受して応答を送信できる、という介入者攻撃を回避するために）、プロトコルは、以下の通りに進行することができる。
【０６７８】
（１）ＳＲＣは、秘密を作成する。この秘密は、ランダム数または疑似ランダム数の１つ以上のペアからなる。
【０６７９】
（２）ＳＲＣは、秘密をＳＮＫに送信する。プロトコルのこの部分は、時間に影響されやすくない。秘密は、ＳＲＣおよびＳＮＫによって機密に保たれる。秘密はまた、ＳＮＫのみがそれを知っていることを確実にする方法で送信される。このことは、ＳＲＣとＳＮＫとの間の安全な認証済みチャンネルを通して秘密を送信することを一般に含む（例えば、ＳＲＣは公開鍵を用いて秘密データを暗号化することができ、ＳＲＣはＳＮＫのみが対応する秘密鍵を有することを知っている）。秘密データは、上述のランダム数または疑似ランダム数のペアである必要はない。そのようなペアが使用される実施形態においてさえも、このステップにおいて送信される秘密データは、ＳＮＫが数のペアを算出または演繹できるのに十分な情報であるだけでよい。例えば、秘密のデータは、ランダムシード数であり得、シードされた疑似乱数ジェネレータを使用して、そこから疑似乱数の１つ以上のペアが生成され得る。
【０６８０】
（３）ＳＮＫが呼掛けを受信する準備ができていることをＳＲＣが知ると（例えばＳＮＫは秘密データを受信および処理した後にＲＥＡＤＹメッセージを送信してもよい）、ＳＲＣは呼掛けメッセージを作成する。呼掛けメッセージを作成すること。例えば、好ましい実施形態において、ＳＲＣは、乱数のペアのうちの１つを選択する。複数のペアが使用される場合、呼掛けメッセージデータは、どのペアが選択されたか、ならびにそのペアにおける２つの数のうちの１つを示す情報を含む。
【０６８１】
（４）ＳＲＣは、現在時刻（Ｔ０）の値を測定する。その直後に、ＳＲＣは、呼掛けメッセージ（暗号化またはデジタル署名のためには必要ではない）をＳＮＫに送信し、応答を待つ。それに代わって、ＳＲＣは、呼掛けメッセージを送信する直前に、現在時刻（Ｔ０）を測定することができる。但し、任意の付随する暗号操作（例えば暗号化、署名など）を実行がした後が好ましい。
【０６８２】
（５）ＳＮＫは、呼掛けを受信する。ＳＮＫは、そのなかから、すでに受信したペアのうちの１つを識別することができる。ＳＮＫは、呼掛けにおける乱数がペアの一部であることを照合し、そのペアの他の乱数の値を含む応答メッセージを構成する。
【０６８３】
（６）ＳＮＫは、応答メッセージをＳＲＣに送信する（暗号化またはデジタル署名のためには必要ではない）。
【０６８４】
（７）ＳＲＣは、応答メッセージを受信し、現在時刻（Ｔ１）の値を測定する。ラウンドトリップ時間ＲＴＴは、Ｔ１〜Ｔ０に等しい。
【０６８５】
（８）ＳＲＣは、応答において受信した数が、呼掛けのために選択したペアの他の値と等しいことを検証する。数が一致する場合、呼掛け応答は成功であり、ＳＲＣは、ＳＮＫがラウンドトリップ時間によって示される近似の範囲内にあることを確信できる。数が一致しない場合、ＳＲＣはプロトコルを中断することができる。または複数のペアが共有され、使用されなかった少なくとも１つのペアがある場合、ＳＲＣはステップ（３）に戻り、異なるペアを使用することができる。
【０６８６】
本発明の原理から逸脱することなく、上述の例示的な近似照合プロトコルに対して多くのバリエーションが可能であることが理解される。例えば、限定するものではないが、異なる暗号化アルゴリズムを使用すること、異なる共有された秘密を使用すること、などができる。
【０６８７】
１４．セキュリティ
本明細書に記載するシステムおよび方法の現実的応用において、セキュリティは、様々な異なる技術を使用して、様々な異なるレベルで提供することができる。本明細書における説明は、潜在的に複雑な仕事の関係を効率的に調整する際の、主にＤＲＭエンジンおよび関連するホストアプリケーションの設計および操作に集中する。ＤＲＭエンジンおよびホストアプリケーションが意図される通りに動作するときに、コンテンツは、それに関連するライセンス条件の施行によって、無認可のアクセスまたは他の使用から保護される。
【０６８８】
ＤＲＭエンジンおよび／またはＤＲＭエンジンが実行する環境（例えばＤＲＭエンジンが対話するアプリケーションおよびハードウェア）を、悪意のある不正操作または変更から保護することは、セキュリティ技術の任意の適切な組み合わせを使用して行うことができる。例えば、暗号メカニズム（例えば、暗号化、デジタル署名、デジタル証明書、メッセージ認証コードなど）を使用することによって、例えば本明細書の他の場所に記載するように、ＤＲＭエンジン、ホストアプリケーションおよび／または他のシステムソフトウェアまたはハードウェアを、不正操作および／または他が攻撃から保護することができる。構造的および／または戦術的なセキュリティ対策（例えば、ソフトウェア混乱、自己検査、カスタマイズ、ウォーターマーク、反デバッグ、および／または他のメカニズム）も同様にできる。そのような技術の代表例は、例えば、米国特許第６，６６８，３２５Ｂｌ号明細書（ソフトウェアセキュリティを高めるための混乱技術）、本願と同一譲受人に譲渡された米国特許出願第１１／１０２，３０６号明細書（米国特許出願第２００５−０１８３０７２−Ａ１号明細書として公開）、米国特許出願第０９／６２９８０７号明細書、米国特許出願第１０／１７２，６８２号明細書（米国特許出願第２００３−００２３８５６−Ａ１号明細書として公開）、米国特許出願第１１／３３８，１８７号（米国特許出願２００６−０１２３２４９−Ａ１号明細書として公開）、および米国特許第７，１２４，１７０号Ｂｌ号明細書（安全な演算処理装置のシステムおよび方法）に見いだされ、それぞれの全体が参照によって本明細書に援用されている。それに代わって、またはそれに加えて、物理的セキュリティ技術（例えば、比較的にアクセスしにくいメモリ、安全なプロセッサ、安全なメモリ管理ユニット、ハードウェアによって保護されたオペレーティングシステムモードなど）は、セキュリティを更に高めるために使用することができる。そのようなセキュリティ技術は、当業者には周知であり、これらの技術の一部または全部の任意の適切な組合せ、またはこれらの技術を用いない組合せは、所望のレベルの保護および／または手元にある特定のアプリケーションの詳細に依存して使用できる、ということが理解される。従って、一定のセキュリティ対策（例えば鍵導出技術、デジタル署名技術、暗号化技術など）を一定の実施形態に関連して本明細書に記載するが、すべての実施形態においてこれらの技術を使用する必要があるわけではないことが理解される。
【０６８９】
セキュリティのさらに別の形態は、システムの組織的な設計および操作によって、および参加者の法的および社会的な規制によって提供することができる。例えば、個人ノード、キーイングマテリアル、保護されたコンテンツなどを入手するために、装置またはエンティティは、システム仕様および必要条件の順守を契約的に同意することを要求されてもよく、エンティティのシステム要件のコンプライアンスを検証できる証明プロセスを提出することなどを要求されてもよい。例えば、装置またはアプリケーションは、環境における他のインプリメンテーションと互換性のある方法でＤＲＭエンジンを実現することを要求されてもよく、および／または一定のタイプまたはレベルの不正操作抵抗手段または他のセキュリティを提供することを要求されてもよい。装置のまたは他のエンティティがそのような必要条件を遵守することを証明するデジタル証明書を発行することができ、これらの証明書は、装置またはエンティティがシステムに関与することを許可する前に、またはアクセスの継続を許可する条件として検証できる。
【０６９０】
進歩性のある一連の作業と関連して使用できるセキュリティ技術に関する、更なる非限定的な情報を、以下に提供する。
【０６９１】
システムセキュリティ
【０６９２】
一部の実施形態において、システム設計者は、更新可能性、拒絶および／または改善技術の組み合わせを使用することを選択することにより、装置、アプリケーション、およびサービスへの攻撃およびその危殆化から生じ得るリスクを管理し脅威を減らすことができる。脅威を減らすために使用できる様々な技術的メカニズムの実施例を以下に示す。
【０６９３】
更新メカニズムは、少なくとも２つの異なる目的において役割を果たすために使用できる。第１に、それらを使用して、信頼されるシステムエンティティに最新の情報を伝達することにより、信頼できないシステムエンティティに対するアクセスまたはサービスを拒絶することができる。第２に、更新メカニズムは、信頼できないエンティティが任意の危殆化された構成要素をアップデートすることによって信頼された状態を回復することを可能にする。拒絶による防護措置は、以下の行動の１つ以上を呈するものとして更に特徴づけられる。
・証明の取り消しまたは無効化（一般に、一部のエンティティをブラックリストに記載することによる）。
・暗号メカニズムまたはポリシー施行メカニズムを適用することによるアクセスの除外または拒絶。
・証明に結合された識別または一部の他の属性に基づく、アクセスまたはサービスの回避または拒絶。
・時間的イベントに基づく、証明または特権の失効または無効化。
【０６９４】
例えば、拒絶メカニズムは、装置クローン化、偽装攻撃、プロトコル失敗、ポリシー施行失敗、アプリケーションセキュリティ失敗、および陳腐化した情報または疑わしい情報、などの脅威に対抗するために使用されることができる。
【０６９５】
以下の表は、潜在的な脅威の例、それらがもたらすリスクの一部、および脅威を軽減してシステムセキュリティを更新するメカニズムを提供する。
【表９１】
2009512096.tif 000093
【０６９６】
取り消し
【０６９７】
取り消しは、エンティティをブラックリストに記載することに依存する改善メカニズムとみなすことができる。一般に、無効にされるものは、公開鍵証明書などの証明である。証明を無効にすると、ブラックリストはアップデートされる必要があり、更新メカニズムを使用してアップデートが伝達されるので、依存する当事者はそこから利益を得る。
【０６９８】
従って、例えば、装置、ユーザ、および／または他のエンティティは、コンテンツまたはサービスを消費するために必要な情報を与えられる前に、識別証明書、他の証明および様々なセキュリティデータを示すことを要求され得る。同様に、クライアントがサービスを信頼するために、サービスはクライアントにその証明を提供する必要がある。
【０６９９】
サービスにアクセスするために必要な情報をエンティティが効果的に無効にできる方法の例は、以下を含む。
・証明書失効リスト（ＣＲＬ）。
・証明およびデータ有効性サービス（例えばオンライン証明書状態プロトコル（ＯＣＳＰ）応答側）。
・証明およびデータの自己破壊のためのコマンド。
【０７００】
証明書失効リスト（ＣＲＬ）
【０７０１】
失効リストは、識別証明書、ライセンス、リンク、および他のセキュリティアサーションを無効にするために、異なるエンティティにより用いられることができる。このメカニズムは、サービスの危殆化に起因する状況を改善するために最も有効である。ＣＲＬを配信するために多くの技術を使用することができる。例えば、一部のシステムは間接的なＣＲＬを使用してもよい。その結果、単一のＣＲＬがエコシステム全体を管理する。それに加えて、エンティティは、所有権のＣＲＬを広告（または公表）することができ、および／または更新サービスを購読することができる。ＣＲＬは、ウィルス様式においてピアツーピアで配信され得、および／または携帯機器は接続されると公開されたＣＲＬを受信することができる。'５５１出願に記載されるサービス編成技術も、この目的のために使用できる。
【０７０２】
有効性サービス
【０７０３】
有効性サービスは、証明の状態および他のセキュリティ関連データに関する最新の情報を提供するために使用できる。有効性サービスは、依存する当事者に代わってアクティブ評価操作を実行することができ、または依存する当事者に代わってセキュリティ情報を管理するために使用され得る。アクティブ有効性サービスの例は、証明または属性の有効性を照合できるサービスである。セキュリティ情報を管理する有効性サービスの例は、ＣＲＬまたはセキュリティポリシー更新を宣伝し、または安全なタイムサービスを提供するサービスである。有効性サービスの使用は、依存する当事者がガバナンス決定を通知するために最新のデータを有することを確実にするのを補助することができる。
【０７０４】
一般に、すべてのシステムエンティティが、証明およびセキュリティデータの有効性に関する最新の情報を必要とするというわけではない。例えば、ライセンスを使用したり新しいライセンスを入手したりするたびに、すべての消費者向け装置が、ライセンスサーバの証明書チェーンを検証するためにオンライン証明書状態プロトコル（ＯＣＳＰ）サービスを使用するというわけではない。しかしながら、ライセンスサーバは、購読者証明の有効性を照合するために、ある程度の頻度でＯＣＳＰサービスを使用してもよい。ポリシー（容易にアップデートされ得る）は、どのようなサービスをいつ使用しなければならないかを決定することができる。ポリシーを動的に更新する機会を提供することによって、ライセンスサーバは、操作上の変更に適合することができる。従って、セキュリティポリシーは、経験、技術的発展、および市場要因に基づいて進化することができる。
【０７０５】
セキュリティオブジェクトの有向自己破壊
【０７０６】
エンティティのセキュリティ処理の完全性が疑わしくない場合、エンティティによる証明およびデータの自己破壊は適切である。このオプションは、利用可能な場合には、最も簡単で迅速かつ効率的な失効の方法であることが多い。完全性が侵害される疑いがほとんどまたはまったくなく、抹消が完了したという検証とともに、抹消のための特定の方向を可能にするプロトコルを、両方向通信がサポートする場合、これは特に有用であり得る。
【０７０７】
抹消または使用停止にされることが有益であるセキュリティオブジェクトが数多くある。例えば、装置がドメインから離れたり、またはコンテンツライセンスがタイムアウトしたりするときに、鍵を含んでいてアクセスにコンテンツするために使用できる関連オブジェクトが抹消されることは有益である。本明細書の他の場所で更に詳細に記載するエージェント制御プログラムは、自己破壊メカニズムを実現するために便利である。エージェントは、保証格納域（例えば状態データベース）における状態を抹消し、ドメイン帰属関係における変化に影響を及ぼし、または（例えば帰属関係またはポリシーの変化により）もはや使用可能でなくなった鍵を削除するように、巧みに作ることができる。
【０７０８】
除外
【０７０９】
除外は、悪い行為者（または悪い行為者のグループ）が商品およびサービスの将来の消費に関与することを妨げる改善メカニズムである。除外がもたらす苛酷な結果のために、除外は一般に、状況によって正当化されるときに、最後の手段としてのみ使用される。除外は、悪い行為者をブラックリストに効果的に記載するメカニズムに依存し、それによって悪い行為者が媒体および媒体関連サービスを消費することを禁ずる。ブラックリストの宣伝は、この改善を有効にする更新メカニズムに依存する。しかしながら、除外は、更新メカニズムを提供することによって、必ずしも悪い行為者に信頼された状態を回復させるわけではない。
【０７１０】
鍵除外
【０７１１】
鍵除外は、任意の所与の時間において、受信器の一部のサブセットを将来のコンテンツを解読する能力から論理的に除外するという決定ができるように、受信器のセットに鍵情報をブロードキャストするために使用される鍵管理メカニズムである。このことは、ブロードキャストキーブロック（ＢＫＢ）を構成する効率的な技術を使用することによって、アクティブにされる。ＢＫＢは、受信器の大きいグループの各構成員がコンテンツを解読するために必要な情報を含む。ＢＫＢは、容易にアップデートできる方法で構築され、グループの１以上の構成員をコンテンツ解読能力から除外する。換言すれば、ＢＫＢの設計は、当局が新しいＢＫＢによってシステムをアップデートすることを可能にするので、コンテンツプロバイダは、アクセスを有する場合であっても装置の対象セットをＢＫＢの利用から具体的に除外することができる。
【０７１２】
このメカニズムは、特にクローニング攻撃に対して有効である。クローニング攻撃において、著作権侵害者は、合法的な装置を逆行分析し、その鍵を抽出し、鍵のコピーをクローン装置に展開する。クローンは、ガバナンスモデルを必ずしも順守するわけではないという点を除いて、あたかもオリジナルのように外部で作動する。危殆化が発見されると、危殆化された装置およびそのクローンすべてを除外するようにアップデートされたＢＫＢを配備することができる。しかしながら、鍵除外は、一部の記憶、トランスポート、および計算のオーバヘッドを招くので、一部の状況においては他の方法よりも効率的でない。コンテンツがブロードキャストされない場合、またはバックチャネルがある場合に、このことは特に真実である。
【０７１３】
回避
【０７１４】
回避は、除外と非常に類似した改善メカニズムであるが、その影響は除外ほど苛酷ではない。基本的に、回避は、実行時ポリシー決定によってサービスを拒絶するための手段である。鍵除外は、有向自己破壊またはアクセス拒否によって装置の機能を使用停止にする、より強引な方法である。これに代わって、回避は、装置へのサービス供給をサービスプロバイダに拒絶させることによって装置を使用停止にする、単純な方法を提供する。現在の傾向は、外部的に提供されるサービスを使用して装置の値を拡張することに向かっているので、回避は、より有効なセキュリティ対策になる。
【０７１５】
回避する装置は、ポリシーによって駆動され、ポリシーが必要とする適切な証明の全てを必ずしも生成しないエンティティ（例えば、クライアント、サーバ、および特定の役割のプレーヤ）を差別するために使用できる。ポリシーは、例えば、エンティティが最新のセキュリティアップデートを実施したことをエンティティが示すことを要求し得る。従って、回避は、失効の結果、または一部の特定のアクションを取れない結果であり得る。回避は、検査サービス、および'５５１出願に記載されるようなサービスを使用して、ピアツーピア様式において容易にすることができる。また、データ証明サービス（例えば有効性サービスのインスタンス）は、ポリシー施行時間において回避を実行することができる。システムエンティティを回避した後で、サービスのポリシーに従うことができない特定の証明またはオブジェクトを通知することができる。これにより、回避されたエンティティをトリガすることによって、適切なサービスインタフェースを通してオブジェクトを更新することができる。
【０７１６】
失効
【０７１７】
失効は、証明またはオブジェクトを無効にする際に一部の時間的イベントに依存する、改善メカニズムである。失効は、媒体または媒体サービスに対する一時的なアクセスを有効にする際に効果的である。これらが失効すると、ガバナンスモデルは、アクセスがもはや許可されないことを確実にする。失効の有効活用は、更新メカニズムを必要としてもよい。それによって証明またはオブジェクトをリフレッシュすることができ、媒体または媒体サービスに対するアクセスを継続することが可能になる。
【０７１８】
証明の失効
【０７１９】
認証された鍵は、依存する当事者を保護するために割り当てられる様々な失効属性を有することができる。証明の失効を利用することによって、証明書が失効したエンティティが、サービスを拒絶され、鍵ロールオーバおよび鍵更新手順と連動して使用されることを確実にすることができる。エンティティが広域ネットワークに頻繁に接続されると予想される場合、最も有効な方法は、証明および他のセキュリティデータを定期的に更新することである。もう１つの最も有効な方法は、これらのオブジェクトの有効期間をなるべく適切に短く保つことである。様々な技術（例えば、有効性を照合するポリシーにおける有効期間と猶予期間を部分的に重複させること）を使用することによって、遷移の際の滑らかな操作を確実にすることができる。短い有効期間はまた、ＣＲＬのサイズを低減するのに役立つ。
【０７２０】
リンクの失効
【０７２１】
前述のとおり、リンクオブジェクトに有効期間を割り当てることができる。失効すると、リンクは無効であるとみなされ、ＤＲＭエンジンは、そのグラフの構造の中にそのリンクがないものとみなす。このメカニズムは、商品およびサービスへの一時的なアクセスを有効にするために使用することができる。リンクは更新できるので、ポリシーによって許可される限り、媒体への継続的アクセスが認可され得る。一実施形態において、リンクは、比較的に軽量で自己保護されたオブジェクトであるので、ピアツーピアプロトコルを介して容易に配信できる。
【０７２２】
更新可能メカニズム：アプリケーションおよびポリシー更新可能性
【０７２３】
効率的な更新可能性は、プロトコル失敗に対する改善を迅速に展開することを一般に伴う。このことは、セキュリティアプリケーション（ＤＲＭシステムを含む）に見られる顕著なセキュリティ問題であることが多い。ソフトウェアアップデートは、ビジネス論理およびセキュリティプロトコルを更新するために使用することができる。アプリケーションが、セキュリティポリシーおよび信用ポリシーをアプリケーション論理から分離するように設計されている場合、分離メカニズムを用いてポリシーをアップデートすることができる。これは、より危険の少ない方法である。実際に、ピアツーピア公開メカニズムは、ポリシーを迅速にアップデートするために使用できる。そうではない場合、アプリケーションデプロイヤのソフトウェアアップデート方法は、セキュリティおよび信用ポリシーをアップデートするために使用できる。
【０７２４】
正しいジョブのために正しいツールを使用すること
【０７２５】
可能な場合には比較的に軽量のツールを使用することが一般に望ましい。限定された有効期間と有効日を照合するポリシーとを有する証明を使用することは、エンティティの全体の母集団を対処可能なサイズに保ち、ＣＲＬをあまりに急速に増大させる必要性を排除するのに役立つ。鍵へのアクセスからエンティティを除外する代わりに、エンティティを回避することによって、ＢＫＢの存続期間を延長することができる。さらに、エンティティの回避は、一時的であり状況によって変化できるきめが細かいポリシーを有効にするという利点を有する。異なるＣＲＬは、異なる役割プレーヤに対して特定のタイプの証明を追跡するものであり、ＢＫＢの代わりに使用することができる。ＢＫＢがもっとも有効に展開できるのは、クローンされた受信器を扱う場合などである。オンライン有効性サービスが、時間および努力の合理的な投資に対する見返りを提供することが期待される場合、ポリシーは、オンライン有効性サービスの使用を導くことができる。ここで、新しい証明は非常に重要であり、より遅い失効メカニズムは不適切である。ノードが完全性を有する可能性が高く、正しいことを行うと期待される場合、およびライセンスまたはセキュリティオブジェクト（例えば購読またはドメインリンクのためのリンク）を無効にする必要がある場合、合理的な方法は一般に、ノードにオブジェクトを抹消するように通知することである。こうした状況において、ライセンスが無効であることを全体に報告する必要はなく、ＢＫＢを展開したりドメインを再度キー入力したりする必要はない。ローカルなポリシーまたは命令的コマンドによって駆動される自己破壊は、失効のためのより効率的な方法の１つである。
【０７２６】
様々な失効、更新、改善、および他の技術および実行方法を記載したが、異なる状況は異なるツールを必要とし、本明細書に記載するシステムおよび方法の好ましい実施形態は、これらの技術の一部の任意の適切な組合せを用いて、またはこれらの技術を用いずに、実施できることが理解される。
【０７２７】
ネットワークサービスセキュリティ
【０７２８】
以下の説明は、実施形態に関連し得るセキュリティ考慮事項および技術の一部を例示するものであり、この実施形態において、上記のＤＲＭエンジンおよびアプリケーションは、５５１出願に記載されるようなネットワーク化されたサービス編成システムおよび方法と関連して使用される。
【０７２９】
本明細書に開示されるようなＤＲＭエンジンおよびアーキテクチャを使用するＤＲＭシステムの実際的なインプリメンテーションは、コンテンツおよびＤＲＭオブジェクトにアクセスするためのネットワーク化されたトランザクションを実行することが多い。そのような状況において、５５１出願に記載されるシステムおよび方法は、なかでもメッセージレイヤセキュリティ（認可属性（役割）のためのエンティティ認証およびフォーマットを含む）を標準化するために使用できる。
【０７３０】
説明のために、ＤＲＭシステムにおいて生じるトランザクションは、アクセス、獲得、または操作される情報のタイプに基づいて、少なくとも２つの一般的なカテゴリに分けることができる。
【０７３１】
コンテンツアクセストランザクションは、ＤＲＭシステムによって保護される媒体、企業コンテンツ、または他の機密情報に対する直接アクセスまたは操作に関わる。コンテンツアクセストランザクションの例は、保護されたビデオクリップをレンダリングすること、保護されたオーディオトラックのコピーをコンパクトディスク焼きつけること、保護されたファイルを携帯機器へ移動させること、機密文書を電子メールで送信することなどを含む。コンテンツアクセストランザクションは、コンテンツ記憶保護キーへの直接アクセスを一般に含み、ユーザの指示の下で消費の時点において実行される。
【０７３２】
オブジェクトトランザクションは、保護されたコンテンツへのアクセスを何らかの方法で管理するＤＲＭシステムによって規定されるオブジェクトについて、ユーザまたはシステムが獲得または対話をするトランザクションである。そのようなオブジェクトは、ＤＲＭライセンス、帰属関係トークン、失効リストなどを含む。コンテンツアクセストランザクションを実行するのに必要な付帯事実の全てが利用可能になる前に、１つ以上のオブジェクトトランザクションが通常必要とされる。オブジェクトトランザクションは、消費の時点においてＤＲＭオブジェクトをアセンブルするために、一部のタイプの通信ネットワークを使用することによって、一般に特徴づけられる。
【０７３３】
これらの２つのタイプのトランザクションは、大部分のＤＲＭシステムに一般に関連するガバナンスの２つの点を規定する。図３８は、ＤＲＭ対応クライアント３８００が適切なＤＲＭライセンスサービス３８０４からＤＲＭライセンス３８０２をリクエストする対話処理の代表的なペアを示す。図３８に示す実施例において、ＤＲＭライセンス３８０２は、ＤＲＭライセンスサービス３８０４からクライアント３８００まで送信され、そこでコンテンツ３８０６へのアクセスを提供するために評価される。
【０７３４】
ＤＲＭシステムは、コンテンツアクセスおよびオブジェクトトランザクションのいずれもが、コンテンツへの認可されていないアクセス、およびコンテンツを保護するオブジェクトの作成を防止する態様において実行することを一般に要求する。しかしながら、２つのタイプのトランザクションに対するセキュリティ懸念は、おのずと異なる。例えば、以下の通りである。
【０７３５】
コンテンツアクセストランザクションは、人間主体を認証すること、安全なレンダリングカウントを照合すること、コンテンツ保護鍵を導出するためにＤＲＭライセンスを評価することなどを必要としてもよい。コンテンツアクセストランザクションの合法的な実行に対する大きな脅威は、オブジェクトおよびその中のデータを保護する不正操作防止の境界の違反である。
【０７３６】
オブジェクトトランザクションは、通常、ＤＲＭオブジェクトを必要とするエンティティと、それを提供できるエンティティとの間に、通信チャネルを含む。このように、オブジェクトトランザクションは、以下のような通信ベースの脅威に直面する。すなわち、介入者攻撃、リプレイアタック、サービス拒絶攻撃、認可されていないエンティティが合法的に有するべきでないＤＲＭオブジェクトを獲得する攻撃である。
【０７３７】
一般に、オブジェクトトランザクションは、２つの対話するエンティティの認証、それらの間で交わされるメッセージの保護、およびトランザクションの認可を含む。そのようなトランザクションの主な目的は、コンテンツアクセストランザクションを実行できるように、合法的なソースから完全性で保護されたＤＲＭオブジェクトを集めることである。ＤＲＭオブジェクトを入手するメカニズム、およびそれらを入手するために使用する付帯事実情報は、コンテンツアクセストランザクションの視野とは基本的に無関係である。これらのメカニズムは、コンテンツアクセス自体にとって不可視であり得る（好ましくは不可視であるべきである）。好ましい実施形態において、この自然な分離は、階層通信モデルにつながる。階層通信モデルは、信頼された通信フレームワークを、その上に構築されるアプリケーションと区別する。
【０７３８】
図３８に示す簡略化されたライセンス獲得および消費の例は、現実的応用において一般に重要な一部の詳細を不明確にする。例えば、ＤＲＭライセンスをリクエストするエンティティが実際に合法的なＤＲＭクライアントであり、かつ認可されていないライセンスを入手することを試みるおよび悪意のあるエンティティでないことを、ＤＲＭライセンスサービスが検証する方法、またはネットワークバンド幅および処理パワーを消費することによって合法的なクライアントに対するサービスを、ＤＲＭライセンスサービスが拒絶する方法を、この例は示さない。また、クライアントおよびサービスを接続する通信チャネルを通して機密情報が移動する際に、機密情報の機密性および完全性を保護する方法も示されない。
【０７３９】
図３９に、この例示的なトランザクションのより詳細な図を示す。図３９を参照して、点線は、アプリケーションレイヤコンテンツレンダリングクライアント３８００の視点からＤＲＭライセンスサーバ３８０４への論理トランザクションを表す。下のスタック３９００は、２つのエンドポイントの間の信頼および保護された配信を確実にするために使用される処理のレイヤを表す。
【０７４０】
図３９において、レンダリングクライアント３８００は、ＤＲＭライセンスサーバ３８０４からライセンス３８０２をリクエストする。図の点線は、情報のオリジナルソースおよび最終消費者が、コンテンツレンダリングクライアント３８００およびＤＲＭライセンスサーバ３８０４であることを示す。しかしながら、実際には、メッセージペイロードは、２つのエンドポイントを接続する、アプリケーションレイヤ論理とセキュリティが施されていない通信チャネル３９０２との間に配置される処理の、いくつかのレイヤによって処理されてもよい。
【０７４１】
アプリケーションレイヤ構成要素を、セキュリティが施されていない通信チャネルから切り離す、処理レイヤは、集合的にセキュリティスタックと呼ばれる。セキュリティスタックは、信頼されたエンドポイントの間のメッセージの、完全性に保護された機密の配信を確実にする、安全なメッセージングフレームワークとみなし得る。階層スタックモデルは、以下のような利点を提供する。
【０７４２】
（１）アプリケーションレイヤ論理の設計者は、エンドポイントを接続する根本的な安全な通信メカニズムを開発するための努力を費やす必要はない。信頼されたメッセージングインフラストラクチャは、ひとたび設計されれば、サポートするアプリケーションレイヤ論理に関係なく、多くの異なる状況において展開することができる共通設計パターンである。
【０７４３】
（２）メッセージングフレームワーク自体は、伝達するメッセージの正確なセマンティクスには寛容なままであり得て、通信関連の攻撃、およびメッセージングエンドポイントの確実性に対する攻撃を防止することにその努力を集中することができる。
【０７４４】
一実施形態において、後述するように、セキュリティスタックは、処理のいくつかの異なるレイヤからなる。一実施形態において、５５１出願に記載されるサービス編成のシステムおよび方法は、セキュリティスタックの操作の一部または全部を提供するために使用することができる。
【０７４５】
認証
【０７４６】
一実施形態において、メッセージングエンドポイントは、認証されてもよい。認証は、所与のエンドポイントが、この目的のために信用された当局によって有効な名前を与えられたことを、他のエンドポイントに対して示すプロセスである。名前をつける当局は、トランザクションにおける依存するエンドポイントによって信頼されるべきである。そのような当局を確立することは、信頼された技術を展開する組織によって一般に保証される。
【０７４７】
有効な名前の所有権を示すための共通メカニズムは、公開鍵暗号およびデジタル署名を使用する。この方法を使用して、エンティティは、３つの情報を提供される。
【０７４８】
（１）エンティティに識別子を提供する識別名。
【０７４９】
（２）公開鍵および秘密鍵からなる非対称鍵のペア。
【０７５０】
（３）秘密鍵の保有者が所与の識別名を有することを表明する、デジタル署名された証明書。
【０７５１】
証明書は、識別名および秘密鍵を結合する。情報に署名する秘密鍵を使用するエンティティは、所与の識別名を有することを信頼される。署名は、公開鍵のみを使用して検証することができる。例えば、認証は、Ｘ．５０９ｖ３標準に基づくことができる。
【０７５２】
一実施形態において、認証された秘密鍵の所有権を示すことができるエンティティは、証明書に示される識別名を有することを信頼されるので、情報に署名するために使用される秘密鍵を保護することは、重要な考慮事項になる。実質的に、秘密署名鍵を使用する能力は、識別名によって識別されるエンティティの境界を規定する。アプリケーションレイヤにおいて、送信者および受信者は、メッセージが信頼された対応物に源を発することを知っている必要がある。そのように、一実施形態において、アプリケーションレイヤ論理そのものが認証されたエンティティの一部であることは重要である。このために、一実施形態において、これに依存するセキュリティスタックおよびアプリケーションレイヤは、好ましくは信用境界に入れられる。その結果、信用境界の中に含まれるサブシステムは、エンティティの個人メッセージ署名鍵に対するアクセスを共有すると想定される。
【０７５３】
認可
【０７５４】
上述した認証メカニズムは、配信されたメッセージングエンドポイントに対して、その通信者の識別が信頼できるということを証明する。多くの用途において、この情報はあまりに粗い。一定のトランザクションについてポリシー決定を行うために、機能およびエンドポイントの特性に関するより詳細な情報が必要であり得る。例えば、図３８の状況において、コンテンツレンダリングクライアントは、認証されたエンドポイントと通信しているということのみならず、有効なＤＲＭライセンスオブジェクトを提供する能力があるとみなされたサービスと通信しているか否かを知る必要があり得る。
【０７５５】
セキュリティスタックの実施形態は、認可メカニズムを介して認証されたエンティティについてよりきめが細かい属性に基づくポリシーを表明、伝達、および適用するためのメカニズムを提供する。このメカニズムを使用して、認証証明をすでに有するエンティティは、機能の命名されたセットをエンティティの識別名に関連づける役割アサーションを割り当てられる。例えば、役割名は、ＤＲＭクライアントおよびＤＲＭライセンスサーバについて規定することができる。
【０７５６】
命名された役割は、エンティティによって保持される特定の機能を伝えるように意図される。実際には、エンティティの識別名と役割名との関連を表明することによって、エンティティに役割を付与することができる。一実施形態において、鍵を識別名に関連づける認証証明書と同様に、認可のために使用される役割アサーションは、名前発行者と異なる信頼された役割当局によって署名される。エンティティの内部で、メッセージングエンドポイントのアプリケーションレイヤにアクセスを認可する条件として、役割アサーションは、認証証明とともに検証される。
【０７５７】
エンティティは、構築されるアプリケーションによって必要とされるだけの数の役割属性を保持してもよい。図４０の実施例は、複数の役割を有するエンティティを示す。１つはＤＲＭクライアントとして機能する能力を示す役割であり、２つはサービスの役割である。
例えば、１つのエンティティは、同時に、ＤＲＭクライアント、ＤＲＭオブジェクトプロバイダ、およびセキュリティデータプロバイダであり得る。一実施形態において、実体属性に関するアサーションのために、ＳＡＭＬ  １．１が使用される。
【０７５８】
メッセージセキュリティ
【０７５９】
セキュリティスタックの最下層は、メッセージセキュリティレイヤであり、完全性、機密性、およびフレッシュネス保護をメッセージに提供し、通信チャネルへの攻撃（例えばリプレイアタック）のリスクを緩和する。メッセージセキュリティレイヤにおいて、以下の通りである。
・アプリケーションレイヤプロセス間のメッセージは、エンティティの個人メッセージ署名鍵を使用して署名され、完全性保護および介入者攻撃に対する抵抗を提供する。
・メッセージは、デスティネーションエンティティによって保持される公開鍵を使用して暗号化される。このことは、意図されていない受信者が移動中にメッセージを傍受して読み取ることができないことを保証する。
・ノンスおよびタイムスタンプは、メッセージに追加される。これにより、リプレイアタックにイミュニティを提供し、メッセージングエンドポイント間の生存性の証明を容易にする。
・ＤＲＭエンジンの信頼された時間をアップデートするためにサーバタイムスタンプを使用する。
【０７６０】
１つの例示的実施形態において、ＡＥＳ共通暗号化、ＲＳＡ公開鍵暗号、ＳＨＡ−２５６ 署名ダイジェスト、およびメッセージに他のアルゴリズムを表示するメカニズムのためのサポートが提供される。
【０７６１】
１５．ブートストラッププロトコル
一部の実施形態において、ブートストラッププロトコルは、エンティティ（例えば装置およびソフトウェアクライアント）に初期機密構成データを配信するために使用される。例えば、エンティティが、暗号プロトコルを使用して、より大きいネットワークまたはシステムに接続し、他のエンティティと通信することを望む場合、エンティティは、個人化されたデータ（鍵（共有鍵、秘密鍵、および公開鍵）のセットを含む）によって構成される必要があり得る。個人化されたデータによってエンティティを予め設定することが不可能または非実際的である場合、暗号プロトコルを使用してエンティティ自体を「ブートストラップする」必要がある。
【０７６２】
以下に記載する例示的なプロトコルは、鍵のセットおよび他のコンフィギュレーションデータを用いてエンティティをブートストラップするための基盤として、共有された秘密を使用する。以下のセクションにおいて、以下の表記法を使用する。
・Ｅ（Ｋ、Ｄ）は、鍵Ｋを用いた一部のデータＤの暗号化である。
・Ｄ（Ｋ、Ｄ）は、鍵Ｋを用いた一部の暗号化されたデータＤの解読である。
・Ｓ（Ｋ、Ｄ）は、鍵Ｋを用いた一部のデータＤの署名である。これは、公開鍵署名またはＭＡＣであり得る。
・Ｈ（Ｄ）は、データＤのメッセージダイジェストである。
・Ｖ（Ｋ、Ｄ）は、鍵Ｋを用いた一部のデータＤにわたる署名の検証である。これは、公開鍵署名またはＭＡＣの検証であり得る。
・ＣｅｒｔＣｈａｉｎ（Ｋ）は、公開鍵Ｋに関連する証明書チェーンである。Ｋの値は、チェーンの第１証明書に含まれる。
・ＣｅｒｔＶｅｒｉｆｙ（ＲｏｏｔＣｅｒｔ、ＣｅｒｔＣｈａｉｎ）は、証明書チェーンＣｅｒｔＣｈａｉｎ（チェーンの第１証明書に見いだされる公開鍵を含む）が、ルート証明書ＲｏｏｔＣｅｒｔの下で有効であるという検証である。
・Ａ｜Ｂ｜Ｃ｜…は、個々のバイト列Ａ、Ｂ、Ｃ、…を連結することによって得られるバイト列である。
・ＣＮ（Ａ）は、Ａについての標準的なバイト列である。
・ＣＮ（Ａ、Ｂ、Ｃ．．．）は、複合フィールドＡ、Ｂ、Ｃについての標準的なバイト列である。
【０７６３】
１．３８．初期状態
１．３８．１．クライアント
一実施形態において、クライアントは、（製造時間および／またはファームウェア／ソフトウェアにおいてプレロードされる）ブートストラップトークンの以下のセットを有する。
・ブートストラッププロセスのための信用のルートである一つ以上の読取り専用証明書：ＢｏｏｔＲｏｏｔＣｅｒｔｉｆｉｃａｔｅ。
・一つ以上の秘密ブートストラップ認証キー：ＢＡＫ（共有される）。
・任意の秘密ブートストラップシード生成鍵（各クライアントに一意である）：ＢＳＧＫ。
クライアントがランダムデータの良好なソースを有する場合、このシードは必要でない。
・クライアントが機密鍵を獲得するためにブートストラップサービスに与える必要のある一部の情報：ＣｌｉｅｎｔＩｎｆｏｒｍａｔｉｏｎ（例えば、ＣｌｉｅｎｔＩｎｆｏｒｍａｔｉｏｎは、装置のシリアルナンバ、製造業者の名前などを含むことができる）。この情報は、属性のリストから成る。各属性は、ペア（名前および値）である。
【０７６４】
異なる信用ドメインを必要とする異なるブートサーバを用いてブートプロトコルに関与することができるために、クライアントは、複数のＢｏｏｔＲｏｏｔＣｅｒｔｉｆｉｃａｔｅ証明書およびＢＡＫ認証キーによって構成され得る。
【０７６５】
１．３８．２．サーバ
一実施形態において、サーバは、以下のトークンを有する。
・クライアントのブートストラップ認証キーのうちの少なくとも１つ：ＢＡＫ（共有された秘密）。
・署名のために使用される公開鍵／秘密鍵のペア：（Ｅｓ、Ｄｓ）。
・ルート証明書ＢｏｏｔＲｏｏｔＣｅｒｔｉｆｉｃａｔｅのうちの１つの下で有効である証明書チェーン：ＳｅｒｖｅｒＣｅｒｔｉｆｉｃａｔｅＣｈａｉｎ＝ＣｅｒｔＣｈａｉｎ（Ｅｓ）。
・暗号化のために使用される公開鍵／秘密鍵のペア：（Ｅｅ／Ｄｅ）。
【０７６６】
１．３９．プロトコル記述
ブートストラッププロトコルの例示的実施形態を、図４１に示し、以下に記載する。プロセスの最中（例えば、署名または証明書チェーンを検証する際）の失敗は、エラーにつながり、プロトコル進行を停止する。
【０７６７】
ＢｏｏｔｓｔｒａｐＲｅｑｕｅｓｔＭｅｓｓａｇｅ
【０７６８】
クライアントは、サーバにリクエストを送信する。リクエストは、クライアントが、ブートストラップセッションを開始することを望み、一部の初期パラメータ（例えばプロトコルバージョン、プロファイルなど）、ならびにセッションＩＤ（リプレイアタックを防止するため）、および関与できる信用ドメインのリストを提供することを望む、ということを示す。以下の表は、ＢｏｏｔｓｔｒａｐＲｅｑｕｅｓｔＭｅｓｓａｇｅのための例示的なフォーマットを示す。
【表９２】
2009512096.tif 000094
【０７６９】
Ｐｒｏｔｏｃｏｌ属性およびＶｅｒｓｉｏｎメッセージ属性は、クライアントがどのプロトコル仕様を使用するかを指定する。Ｐｒｏｆｉｌｅフィールドは、メッセージおよびデータを交換するために使用される暗号プロトコルおよびコード化形式の定義済みセットを識別する。
【０７７０】
Ｃｌｉｅｎｔは、ＳｅｓｓｉｏｎＩｄを選択する。ＳｅｓｓｉｏｎＩｄは、そのクライアントに一意であり、再利用されるべきではない。例えば、クライアントの一意なＩＤおよび増加するカウンタ値は、一意なセッションＩＤを生成する方法として使用することができる。
【０７７１】
一実施形態において、Ｃｌｉｅｎｔはまた、その構成の対象となったすべてのＴｒｕｓｔ  Ｄｏｍａｉｎのリストを送信する。
【０７７２】
一実施形態において、サーバは、ＢｏｏｔｓｔｒａｐＲｅｑｕｅｓｔＭｅｓｓａｇｅを受信し、以下のステップを実行する。
・クライアントによってリクエストされる指定されたＰｒｏｔｏｃｏｌ、Ｖｅｒｓｉｏｎ、およびＰｒｏｆｉｌｅをサポートすることを照合する。
・ノンス（非常にランダムな数）を生成する。
・セッション全体にわたって持続する情報（例えば、タイムスタンプ、セッショントークン、または他の任意のサーバー側情報）を運ぶために、任意にＣｏｏｋｉｅを生成する。
クッキーの値は、サーバのみにとって意味があり、クライアントによって不透明なデータブロックとみなされる。
・ＳｅｓｓｉｏｎＩｄの値を、ＢｏｏｔｓｔｒａｐＲｅｑｕｅｓｔＭｅｓｓａｇｅから抽出する。
・呼掛けを生成する：Ｃｈａｌｌｅｎｇｅ＝［Ｎｏｎｃｅ、Ｅｅ、Ｃｏｏｋｉｅ、ＳｅｓｓｉｏｎＩｄ］。
・Ｄｓを用いて呼掛けに署名するために、Ｓ（Ｄｓ、Ｃｈａｌｌｅｎｇｅ）を算出する。
・ＣｈａｌｌｅｎｇｅＲｅｑｕｅｓｔＭｅｓｓａｇｅを構成し、応答としてクライアントにそれを送信する。
【０７７３】
ＣｈａｌｌｅｎｇｅＲｅｑｕｅｓｔＭｅｓｓａｇｅ
【０７７４】
以下の表は、ＣｈａｌｌｅｎｇｅＲｅｑｕｅｓｔＭｅｓｓａｇｅのための例示的なフォーマットを示す。
【表９３】
2009512096.tif 000095
【０７７５】
一実施形態において、ＣｈａｌｌｅｎｇｅＲｅｑｕｅｓｔＭｅｓｓａｇｅを受信した後に、クライアントは、以下のステップを実行する。
・ルート証明書ＢｏｏｔＲｏｏｔＣｅｒｔｉｆｉｃａｔｅの下で証明書チェーンＳｅｒｖｅｒＣｅｒｔｉｆｉｃａｔｅＣｈａｉｎが有効であることを検証する：ＣｅｒｔＶｅｒｉｆ（ＢｏｏｔＲｏｏｔＣｅｒｔｉｆｉｃａｔｅ、ＳｅｒｖｅｒＣｅｒｔｉｆｉｃａｔｅＣｈａｉｎ）。
・ＳｅｒｖｅｒＣｅｒｔｉｆｉｃａｔｅＣｈａｉｎから公開鍵Ｅｓを抽出する。
・呼掛けの署名を検証する：Ｖ（Ｅｓ、Ｃｈａｌｅｎｇｅ）。
・ＳｅｓｓｉｏｎＩｄが、ＢｏｏｔＲｅｑｕｅｓｔＭｅｓｓａｇｅが送信されたときにセッションのために選択されたＳｅｓｓｉｏｎＩｄと一致する、ことを照合する。
・ＣｈａｌｌｅｎｇｅＲｅｓｐｏｎｓｅＭｅｓｓａｇｅを構成し、サーバに送信する。
【０７７６】
ＣｈａｌｌｅｎｇｅＲｅｓｐｏｎｓｅＭｅｓｓａｇｅ
【０７７７】
ＣｈａｌｌｅｎｇｅＲｅｓｐｏｎｓｅＭｅｓｓａｇｅを生成するために、クライアントは、以下のステップを実行する。
・以下の２つの方法の１つを使用して、セッション鍵ＳＫを生成する。
○安全なランダムな鍵ジェネレータを直接に使用すること。
○ＮｏｎｃｅおよびＢＳＧＫを間接的に使用して、ＨＳＫ＝Ｈ（ＢＳＧＫ｜Ｎｏｎｃｅ）を算出し、ＳＫ＝Ｆｉｒｓｔ  Ｎ  ｂｙｔｅｓ  ｏｆ  ＨＳＫを設定する。
・［Ｃｈａｌｌｅｎｇｅ、Ｃｌｉｅｎｔｌｎｆｏｒｍａｔｉｏｎ、ＳｅｓｓｉｏｎＫｅｙ］を含むＣｈａｌｌｅｎｇｅＲｅｐｓｏｎｓｅオブジェクトを生成する。ここで、Ｃｈａｌｌｅｎｇｅは、すでに受信したＣｈａｌｌｅｎｇｅＲｅｑｕｅｓｔＭｅｓｓａｇｅからの呼掛けであり、ＳｅｒｖｅｒＥｎｃｒｙｐｔｉｏｎＫｅｙは除く。
・ＢＡＫを用いて応答に署名するために、Ｓ（ＢＡＫ、ＣｈａｌｌｅｎｇｅＲｅｓｐｏｎｓｅ）を算出する。
・署名されたＣｈａｌｌｅｎｇｅＲｅｐｏｎｓｅをＳＫを用いて暗号化する：Ｅ（ＳＫ［ChallengeResponse、Ｓ（ＢＡＫ、ＣｈａｌｌｅｎｇｅＲｅｓｐｏｎｓｅ）］）。
・サーバの公開鍵Ｅｅを用いてＳｅｓｓｉｏｎＫｅｙを暗号化する。
・ＣｈａｌｌｅｎｇｅＲｅｓｐｏｎｓｅＭｅｓｓａｇｅを構成し、サーバに送信する。
【表９４】
2009512096.tif 000096
【０７７８】
サーバは、ＢｏｏｔｓｔｒａｐＣｈａｌｌｅｎｇｅＲｅｓｐｏｎｓｅを受信し、以下のステップを実行する。
○秘密鍵Ｄｅを使用してセッション鍵ＳＫを解読する：Ｄ（Ｄｅ、ＳｅｓｓｉｏｎＫｅｙ）。
○前のステップからのセッション鍵ＳＫを用いてＣｈａｌｌｅｎｇｅＲｅｓｐｏｎｓｅを解読する：Ｄ（ＳＫ、Ｃｈａｌｌｅｎｇｅ）。
○呼掛けの署名を検証する：Ｖ（ＢＡＫ、ＣｈａｌｌｅｎｇｅＲｅｓｐｏｎｓｅ）。
○セッション鍵ＳＫが暗号復元に使用されるセッション鍵と一致することを照合する。
○必要に応じてＣｏｏｌｉｅおよびＮｏｎｃｅの値（例えばタイムスタンプ）を照合する。
○ＳｅｓｓｉｏｎＩｄが、ＢｏｏｔＲｅｑｕｅｓｔＭｅｓｓａｇｅが送信されたときにセッションのために選択されたＳｅｓｓｉｏｎＩｄと一致する、ことを照合する。
○ＢｏｏｔｓｔｒａｐＲｅｓｐｏｎｓｅＭｅｓｓａｇｅを構成し、サーバに送信する。
【０７７９】
ＢｏｏｔｓｔｒａｐＲｅｓｐｏｎｓｅＭｅｓｓａｇｅ
【０７８０】
ＢｏｏｔｓｔｒａｐＲｅｓｐｏｎｓｅＭｅｓｓａｇｅを生成するために、サーバは、以下のステップを実行する。
○ＣｈａｌｌｅｎｇｅＲｅｓｐｏｎｓｅＭｅｓｓａｇｅにおいて受信したＣｌｉｅｎｔＩｎｆｏｒｍａｔｉｏｎを解析し、このブートストラップリクエストのために送信する必要のあるクライアントコンフィギュレーションＤａｔａをルックアップまたは生成する（これは、クライアントを表すノードのための機密鍵（Ｅｃ／Ｄｃ）を含んでもよい）。
サーバは、クライアントのための正確な情報を検索するのを補助するために、ＮｏｎｃｅおよびＣｏｏｋｉｅの値を一般に使用する。
○ＳｅｓｓｉｏｎＩｄおよび構成Ｄａｔａを用いて、ＢｏｏｔｓｔｒａｐＲｅｓｐｏｎｓｅを作成する。
○Ｄｓを用いてＤａｔａに署名するために、Ｓ（Ｄｓ、ＢｏｏｔｓｔｒａｐＲｅｓｐｏｎｓｅ）を算出する。
○署名されたＢｏｏｔｓｔｒａｐＲｅｓｐｏｎｓｅをセッション鍵ＳＫを用いて暗号化する：Ｅ（ＳＫ［ＢｏｏｔｓｔｒａｐＲｅｓｐｏｎｓｅ、Ｓ（ｄｓ、ＢｏｏｔｓｔｒａｐＲｅｓｐｏｎｓｅ）］）。
【表９５】
2009512096.tif 000097
【０７８１】
１．４０．信用ドメイン
一実施形態において、各信用ドメインは、ルート証明機関と、ドメインの一意の名前とを含む。クライアントは、ＢｏｏｔｓｔｒａｐＲｅｑｕｅｓｔを送信するときに、受け入れることを望むすべての信用ドメイン（すなわちクライアントが有効であるとみなす証明書）を識別する。サーバは、クライアントによって送信されるリストから、信用ドメインを選択する（サーバがサポートする場合）。
【０７８２】
１．４１．署名
一実施形態において、署名がメッセージペイロードにおいて使用されるときは必ず、署名は、メッセージの署名された部分に含まれるデータフィールドの標準的なバイト列を通じて算出される。標準的なバイト列は、フィールド値のコード化からでなく、フィールド値から算出される。各プロファイルは、メッセージタイプごとにフィールドの標準的なバイト列を算出するために使用されるアルゴリズムを、好ましくは規定する。
【０７８３】
１．４２．プロファイル
ブートストラッププロトコルのプロファイルは、様々な暗号およびシリアライゼーションフォーマットについての選択のセットである。各プロファイルは、好ましくは一意の名前を有し、以下の選択を含む。
・公開鍵暗号化アルゴリズム
・公開鍵署名アルゴリズム
・秘密鍵暗号化アルゴリズム
・秘密鍵署名アルゴリズム
・公開鍵コード化
・ダイジェストアルゴリズム
・標準的なオブジェクトシリアライゼーション
・証明書フォーマット
・最低限ノンスサイズ
・メッセージマーシャリング
付録Ａ
以下は、複数の連動する署名を有するコントローラオブジェクトの実施例である。
【表９６】
2009512096.tif 000098
【表９７】
2009512096.tif 000099
【表９８】
2009512096.tif 000100
【０７８４】
付録Ｂ
この付録Ｂは、本明細書の他の場所に記載する例示的なオクトパスＤＲＭエンジンを使用するシステムの一実施形態におけるオブジェクトのＸＭＬコード化を示す。特定のアプリケーションのために、アプリケーション指定ＸＭＬスキーマは、以下に示すＸＭＬスキーマ（「オクトパスＸＭＬスキーマ」）をインポートし、アプリケーションに特定の要素（例えば失効のために使用される拡張）を追加することによって、作成することができる。一実施形態において、ＸＭＬにおけるオブジェクトのコード化は、アプリケーション指定ＸＭＬスキーマに対して検証可能である必要がある。これらのＸＭＬコード化に対する更なる可能な制約は、下記に見いだされる。
【０７８５】
この付録Ｂに例示する実施例において、すべてのＤＲＭオブジェクトのための基本的なＸＭＬスキーマタイプは、ＯｃｔｏｐｕｓＯｂｊｅｃｔＴｙｐｅである。このことは、すべてのオブジェクトが属性および拡張をサポートすることを意味する。各Ｏｃｔｏｐｕｓオブジェクト要素のタイプは、この基本タイプに由来する。これらのタイプは、例えばＣｏｎｔｅｎｔＫｅｙＴｙｐｅのためのＳｅｃｒｅｔＫｅｙ要素のような他の要素を集めてもよい。
【０７８６】
この例示的実施形態において、スキューバ鍵配信システムキーは、拡張に関して記載される。ＳｃｕｂａＫｅｙｓ要素は、延長要素の子である。同じことは、Ｔｏｒｐｅｄｏ拡張を有する失効鍵にもあてはまる。
【０７８７】
本明細書の他の場所に記載するように、異なる種類のＯｃｔｏｐｕｓオブジェクト（例えばＣｏｎｔｅｎｔＫｅｙ、Ｐｒｏｔｅｃｔｏｒ、Ｃｏｎｔｒｏｌｌｅｒ、Ｃｏｎｔｒｏｌ、Ｎｏｄｅ、およびＬｉｎｋ）がある。これらのオブジェクトは、＜Ｂｕｎｄｌｅ＞要素を使用する拡張とともに、共にバンドルされ得る。一実施形態において、オブジェクトまたは拡張が＜Ｂｕｎｄｌｅ＞の中で署名される場合、本明細書の他の場所に記載するように、＜Ｂｕｎｄｌｅ＞は＜Ｓｉｇｎａｔｕｒｅ＞要素を含む。
【０７８８】
【表９９】
2009512096.tif 000101
【表１００】
2009512096.tif 000102
【表１０１】
2009512096.tif 000103
【表１０２】
2009512096.tif 000104
【表１０３】
2009512096.tif 000105
【０７８９】
【表１０４】
2009512096.tif 000106
【０７９０】
Ｂ．１．更なる制約
Ｂ．１．１．ノード
一実施形態において、以下のタイプのノードが規定される。
・オクトパス個人ノード。これは、所与のＤＲＭエンジンのルートノードである（例えば装置ノードまたはＰＣソフトウェアノード）。
・他のタイプのノード（例えばユーザノード）、またはユーザのグループのためのノード（例えば購読ノードまたは帰属関係ノード）。
【０７９１】
一実施形態において、ノードは、鍵（例えばＳｃｕｂａＫｅｙなどの拡張）を含み、ノードの公開情報（例えばＩＤ、属性、および公開鍵）と、その秘密の拡張（例えば秘密鍵を運ぶ）とを切り離すことができる必要がある。さらに、（公開および秘密の）部分ごとに１つの署名があるので、署名を有する公開ノードは、そのままエクスポートされ得る（例えばライセンスサービスに対するリクエストのパラメータとして）。
【０７９２】
一実施形態において、秘密の拡張は、ＥｘｔｅｒｎａｌＥｘｔｅｎｓｉｏｎにおいて運ばれて、署名される。公開のノードおよびその秘密の拡張は、同一の＜Ｂｕｎｄｌｅ＞要素においてパッケージングされ得るか、またはそれとは別に到達可能である。署名されたオクトパス個人ノードの実施例は、付録Ｂに対する下記の補遺Ａに示す。
【０７９３】
Ｂ．１．１．１．属性
一実施形態において、ノードオブジェクトの各ＸＭＬコード化は、以下の＜Ａｔｔｒｉｂｕｔｅ＞を有する＜ＡｔｔｒｉｂｕｔｅＬｉｓｔ＞を運ぶ。
【０７９４】
【表１０５】
2009512096.tif 000107
【０７９５】
【表１０６】
2009512096.tif 000108
【０７９６】
Ｂ．１．１．２．拡張
付録Ｂに対する補遺Ａに示すように、一実施形態において、オクトパス個人ノードは、ＳｃｕｂａＫｅｙ（共有鍵および機密鍵）およびＴｏｒｐｅｄｏ（ブロードキャスト秘密鍵）のための拡張を運ぶ。他の種類のノードは、Ｓｃｕｂａを共有する鍵のみを運ぶ。
【０７９７】
すべての公開鍵は、＜ＥｘｔｅｎｓｉｏｎＬｉｓｔ＞における＜Ｅｘｔｅｎｓｉｏｎ＞要素における＜Ｎｏｄｅ＞要素の内部で運ばれる。他の鍵は、＜Ｎｏｄｅ＞要素の外にある別々の＜Ｅｘｔｅｎｓｉｏｎ＞要素において運ばれる。
【０７９８】
一実施形態において、＜ＳｃｕｂａＫｅｙｓ＞拡張は、＜Ｎｏｄｅ＞において署名される。この実施形態において、＜Ｎｏｄｅ＞（公開鍵）の内部の＜ＳｃｕｂａＫｅｙｓ＞を運ぶ＜Ｅｘｔｅｎｓｉｏｎ＞は、＜ｄｓ：ＤｉｇｅｓｔＭｅｔｈｏｄ＞要素ならびに＜ｄｓ：ＤｉｇｅｓｔＶａｌｕｅ＞要素を含む必要がある。外部＜Ｅｘｔｅｎｓｉｏｎ＞において運ばれる秘密鍵は、署名される必要があり、全部の拡張に署名することによってこれを必要とする。同様に、＜Ｔｏｒｐｅｄｏ＞拡張は、署名される。
【０７９９】
Ｂ．１．２．リンク
一実施形態において、＜Ｌｉｎｋ＞要素の＜ＬｉｎｋＴｏ＞要素および＜ＬｉｎｋＦｒｏｍ＞要素は、＜ＩＤ＞要素のみを含み、＜Ｄｉｇｅｓｔ＞要素を含まない。＜Ｃｏｎｔｒｏｌ＞、要素は、任意である。この付録Ｂに対する補遺Ｃは、署名されたリンクオブジェクトの実施例を含む。
【０８００】
Ｂ．１．１．１．属性
一実施形態において、リンクは、必須属性を有しない。このことは、＜ＡｔｔｒｉｂｕｔｅＬｉｓｔ＞が必要とされず、対応するインプリメンテーションによって無視されることを意味する。
【０８０１】
Ｂ．１．１．２．拡張
この付録Ｂに示す例示的実施形態において、リンクは、＜Ｌｉｎｋ＞の内部で運ばれる＜ＳｃｕｂａＫｅｙｓ＞内部拡張を有するので、＜ＥｘｔｅｎｓｉｏｎＬｉｓｔ＞要素は必須である。それに加えて、リンクにおける＜ＳｃｕｂａＫｅｙｓ＞拡張は署名されないので、＜ｄｓ：ＤｉｇｅｓｔＭｅｔｈｏｄ＞要素および＜ｄｓ：ＤｉｇｅｓｔＶａｌｕｅ＞要素は、＜Ｅｘｔｅｎｓｉｏｎ＞要素の内部で運ばれない。この＜ＳｃｕｂａＫｅｙｓ＞拡張は、（＜ＰｒｉｖａｔｅＫｅｙ＞要素および＜ＳｅｃｒｅｔＫｅｙ＞要素において）「Ｆｒｏｍ  Ｎｏｄｅ」の公開または秘密Ｓｃｕｂａ共有鍵を有する「Ｔｏ  Ｎｏｄｅ」の秘密Ｓｃｕｂａ共有鍵を含む。この暗号化は、ＸＭＬ暗号化シンタックスを使用して表示される。この付録Ｂに例示する実施形態において、＜ＫｅｙＤａｔａ＞要素、ならびに＜ＰｒｉｖａｔｅＫｅｙ＞および＜ＳｅｃｒｅｔＫｅｙ＞要素の子の、「コード化」属性は、「ｘｍｌｅｎｃ」に設定される。この＜ＫｅｙＤａｔａ＞要素の子は、＜ｘｅｎｃ：ＥｎｃｒｙｐｔｅｄＤａｔａ＞要素である。暗号化鍵の名前は、＜ＫｅｙＩｎｆｏ＞／＜Ｋｅｙｎａｍｅ＞要素において広告される。
【０８０２】
一実施形態において、暗号化鍵が公開鍵である場合、以下の通りになる。
・＜Ｋｅｙｎａｍｅ＞要素は、鍵が帰属するペアの名前である。
・暗号化されるデータ（例えば秘密鍵）が、あまりに大きすぎて公開鍵によって直接に暗号化できない場合、媒介１２８ビット秘密鍵が生成される。データは、例えばａｅｓ−１２８−ｃｂｃを使用して媒介鍵によって暗号化され、媒介鍵は、公開鍵によって暗号化される（＜ＥｎｃｒｙｐｔｅｄＫｅｙ＞要素を使用して）。
【０８０３】
ＸＭＬチャンクは、以下のようになる。
【表１０７】
2009512096.tif 000109
【０８０４】
Ｂ．１．３．ライセンスオブジェクト
この付録Ｂに対する補遺Ｃは、署名されたライセンスの実施例を提供する（最初の失効が生じる前）（下記のＣｏｎｔｅｎｔＫｅｙセクションを参照）。
【０８０５】
Ｂ．１．３．１．プロテクタ
この付録Ｂに示す例示的実施形態において、＜ＣｏｎｔｅｎｔＫｅｙＲｅｆｅｒｅｎｃｅ＞要素および＜ＣｏｎｔｅｎｔＲｅｆｅｒｅｎｃｅ＞要素（例えば＜ＰｒｏｔｅｃｔｅｄＴａｒｇｅｔｓ＞要素の内部）は、＜ＩＤ＞要素のみを含み、＜Ｄｉｇｅｓｔ＞要素を含まない。この例示的実施形態において、プロテクタオブジェクトは、必須属性または拡張を含まない。＜ＡｔｔｒｉｂｕｔｅＬｉｓｔ＞および＜ＥｘｔｅｎｓｉｏｎＬｉｓｔ＞要素は、任意であり、無視される。
【０８０６】
Ｂ．１．３．２．ＣｏｎｔｅｎｔＫｅｙ
この付録Ｂに示す例示的実施形態において、ＣｏｎｔｅｎｔＫｅｙオブジェクトは、必須属性または拡張を含まない。従って、＜ＡｔｔｒｉｂｕｔｅＬｉｓｔ＞要素および＜ＥｘｔｅｎｓｉｏｎＬｉｓｔ＞要素は、任意であり、無視される。
【０８０７】
一実施形態において、＜ＣｏｎｔｅｎｔＫｅｙ＞要素は、コンテンツを解読するために使用される実際の鍵を表す＜ＳｅｃｒｅｔＫｅｙ＞要素を含む。＜ＳｅｃｒｅｔＫｅｙ＞に関連する＜ＫｅｙＤａｔａ＞は、暗号化される。一実施形態において、＜ＫｅｙＤａｔａ＞の「コード化」属性が「ｘｍｌｅｎｃ」に設定されることは、必須である。
【０８０８】
一実施形態において、ＣｏｎｔｅｎｔＫｅｙオブジェクトについて２つの異なる場合がある。（１）装置またはＰＣアプリケーションの最初に失効する前。この場合、＜ＳｅｃｒｅｔＫｅｙ＞によって表されるコンテンツ鍵ｋｃ要素は、コンテンツが結合される（公開または秘密の）エンティティ（例えばユーザ）のＳｃｕｂａ鍵によってのみ暗号化される。（２）Ｍａｎｇｒｏｖｅブロードキャスト暗号化スキームに従ってコンテンツ鍵が暗号化される最初の失効の後。結果データは、コンテンツが結合されるエンティティの（公開または秘密の）Ｓｃｕｂａ鍵によって暗号化される。この場合、スーパー暗号化となる。
【０８０９】
スーパー暗号化の場合に＜ＥｎｃｒｙｐｔｅｄＤａｔａ＞要素を暗号化する例示的な方法は、本明細書の他の場所に記載する。以下は、これをケースｂに適用する方法を説明する。
【０８１０】
一実施形態において、Ｍａｇｒｏｖｅブロードキャストスキームによってコンテンツ鍵ｋｃを暗号化するためのｘｍｌｅｎｃシンタックスは、以下の通りである。
【表１０８】
2009512096.tif 000110
【０８１１】
一実施形態において、上述の＜ＥｎｃｒｙｐｔｅｄＤａｔａ＞のバイト列は、ライセンスが結合されるエンティティの（公開または秘密の）スキューバ共有鍵によって暗号化される。公開鍵が使用される場合、下記と同一の規則が適用され（例えば公開鍵による暗号化を参照）、＜ＥｎｃｒｙｐｔｅｄＤａｔａ＞のバイト列がＲＳＡ１０２４公開鍵にとって大きすぎる場合、媒介鍵が必要である。そのようなＣｏｎｔｅｎｔＫｅｙオブジェクトのＸＭＬコード化の実施例は、この付録Ｂに対する補遺Ｄに見いだされる。
【０８１２】
Ｂ．１．３．３．コントローラ
一実施形態において、コントローラオブジェクトは、必須属性または拡張を含まない。従って、＜ＡｔｔｒｉｂｕｔｅＬｉｓｔ＞および＜ＥｘｔｅｎｓｉｏｎＬｉｓｔ＞要素は、任意であり、対応するインプリメンテーションによって無視される。
【０８１３】
一実施形態において、＜ＤｉｇｅｓｔＭｅｔｈｏｄ＞要素のアルゴリズム属性の値は、常にｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／２０００／０９／ｘｍｌｄｓｉｇ＃ｓｈａ１である。
【０８１４】
一実施形態において、＜ＣｏｎｔｒｏｌＲｅｆｅｒｅｎｃｅ＞は、＜Ｄｉｇｅｓｔ＞要素を有しなければならない。＜ＤｉｇｅｓｔＶａｌｕｅ＞、要素は、参照される制御のダイジェストのベース６４コード化を含まなければならない。
【０８１５】
一実施形態において、コントローラにわたる署名がＰＫＩ署名（ｒｓａ−ｓｈａｌ）である場合、＜ＣｏｎｔｅｎｔＫｅｙＲｅｆｅｎｃｅ＞要素（＜ＣｏｎｔｒｏｌｌｅｄＴａｒｇｅｔｓ＞要素の中にある）は、＜Ｄｉｇｅｓｔ＞要素を含む必要があり、＜ＤｉｇｅｓｔＶａｌｕｅ＞要素は、ＣｏｎｔｅｎｔＫｅｙオブジェクトに埋め込まれるプレーンテキストのコンテンツ鍵のダイジェストを含まなければならない。
【０８１６】
Ｂ．１．３．４．制御
一実施形態において、制御オブジェクトは、必須属性または拡張を含まない。従って、＜ＡｔｔｒｉｂｕｔｅＬｉｓｔ＞および＜ＥｘｔｅｎｓｉｏｎＬｉｓｔ＞要素は、任意であり、対応するインプリメンテーションによって無視される。
【０８１７】
一実施形態において、＜ＣｏｎｔｒｏｌＰｒｏｇｒａｍ＞要素のタイプ属性は「プランクトン」に設定され、＜ＣｏｄｅＭｏｄｕｌｅ＞要素のｂｙｔｅＣｏｄｅＴｙｐｅ属性は「Ｐｌａｎｋｔｏｎ−１−０」に設定される。
【０８１８】
【表１０９】
2009512096.tif 000111
【表１１０】
2009512096.tif 000112
【表１１１】
2009512096.tif 000113
【０８１９】
【表１１２】
2009512096.tif 000114
【表１１３】
2009512096.tif 000115
【０８２０】
【表１１４】
2009512096.tif 000116
【表１１５】
2009512096.tif 000117
【０８２１】
【表１１６】
2009512096.tif 000118
付録Ｃ
【０８２２】
この付録Ｃは、上述のブートストラッププロトコルとともに用いる単純なプロファイルの実施例を示す。単純な標準的なシリアライゼーション、例示的なＸＭＬマーシャリング、およびＯｃｔｏｐｕｓブートストラップＳＯＡＰウェブサービスのための例示的なＷＳＤＬも提供される。
【０８２３】
単純なプロファイル
【０８２４】
一実施形態において、以下から成る単純なプロファイルが使用される。
【表１１７】
2009512096.tif 000119
【０８２５】
単純な標準的なシリアライゼーション１．０
【０８２６】
一実施形態において、上述の単純なプロファイルにおいて使用される単純な標準的なバイト列は、メッセージにおけるオブジェクトのフィールドの値からバイト列を構成することからなる。各メッセージおよび各オブジェクトは、１つ以上のフィールドからなる。各フィールドは、単純フィールドまたは複合フィールドである。
【０８２７】
単純フィールドは、４つのタイプ（フィールドの整数、ストリング、バイト列、またはアレイ）のうちの１つであり得る。複合フィールドは、１つ以上のサブフィールドからなり、各サブフィールドは単純または複合である。
【０８２８】
一実施形態において、フィールドタイプごとに標準的なバイト列を構成するための規則は、以下の通りである。
【０８２９】
複合フィールド
【表１１８】
2009512096.tif 000120
【０８３０】
標準的なバイト列は、各サブフィールドの標準的なバイト列の結合である（任意フィールドは、スキップされず、任意フィールドのための規則に従ってシリアル化される）。
【０８３１】
フィールドのアレイ
【表１１９】
2009512096.tif 000121
【０８３２】
フィールド数は、ビッグエンディアン順における４バイトのシーケンスとしてコード化され、その後に各フィールドの標準的なバイト列が続く。フィールド数が０である場合、４バイトフィールド数の後に何も続かない（この場合、すべての４バイトは、値０を有する）。
【０８３３】
整数
【表１２０】
2009512096.tif 000122
【０８３４】
ビッグエンディアン順において４バイトのシーケンスとしてコード化される３２ビット符号付きの値。
【０８３５】
ストリング
【表１２１】
2009512096.tif 000123
【０８３６】
ストリングは、８ビットバイトのＵＴＦ−８コード化されるシーケンスによって表される。コード化されたバイト列のバイト数は、ビッグエンディアン順における４バイトのシーケンスとしてコード化される。バイト数の後には、ＵＴＦ−８コード化されたストリングのバイト列が続く。
【０８３７】
バイト列
【表１２２】
2009512096.tif 000124
【０８３８】
バイト数は、ビッグエンディアン順における４バイトのシーケンスとしてコード化される（バイト列が空である場合、または対応するフィールドが省略される場合、バイト数は０であり、４バイトのバイト数の後にバイト値は続かない）。各バイトは、そのままコード化される。
【０８３９】
単純なＸＭＬマーシャリング１．０
【０８４０】
【表１２３】
2009512096.tif 000125
【表１２４】
2009512096.tif 000126
【表１２５】
2009512096.tif 000127
【０８４１】
【表１２６】
2009512096.tif 000128
【表１２７】
2009512096.tif 000129
【０８４２】
【表１２８】
2009512096.tif 000130
【表１２９】
2009512096.tif 000131
付録Ｄ
【０８４３】
オブジェクトのための標準的なバイト列（ＣＢ）を算出するコード化中立方法を以下に提示するが、好ましい実施形態において、これはオブジェクトにデジタル署名する使用のためのダイジェストの計算において使用される。このバイト列は、オブジェクトを表したり送信したりする方法から独立しているので、システムに一貫して同一のダイジェストおよび署名値を使用できる。そのシステムにおいて、複数のコード化形式（例えばＸＭＬ、ＡＮＳＩ）、プログラミング言語などが使用される。
【０８４４】
１．標準的なバイト列アルゴリズム
標準的なバイト列アルゴリズムは、フィールドの値からバイト列を構成することからなる。各フィールドは、単純タイプまたは複合タイプの値を有する。一部のフィールドは、任意であるように指定できる（フィールドは存在するかまたは省略され得る）。
【０８４５】
一実施形態において、単純タイプは、整数、ストリング、バイト、およびブーリアンである。
【０８４６】
複合タイプは、１つ以上のサブフィールドから成る。各サブフィールドは、単純タイプまたは複合タイプの値を有する。複合タイプは、異種または同種である。すなわち、異なるタイプ（すなわち異種）の１つ以上のサブフィールド値（単純または複合）があるか、あるいはすべて同一のタイプ（すなわち同種）の１つ以上のサブフィールド値（単純または複合）があることを意味する。
【０８４７】
フィールドの標準的なバイト列は、フィールドが常に存在する場合には、符号化則をフィールド値に適用することによって入手され、あるいはフィールドが任意であるように指定される場合には、符号化則を任意フィールドに適用することによって入手される。以下の符号化則の記載において、バイトという用語は、８ビット値（オクテット）を意味する。
【０８４８】
１．１．任意フィールド
任意フィールドが存在する場合、その値はバイト値１としてシリアル化され、その後にフィールド値の標準的なバイト列が続く。それが省略される場合、その値はバイト値０としてシリアル化される。
【０８４９】
１．２．異種複合
標準的なバイト列は、各サブフィールド値の標準的なバイト列の結合である（任意フィールドは、スキップされず、任意フィールドのための規則に従ってシリアル化される）。
【０８５０】
１．３．同種複合
標準的なバイト列は、サブフィールドカウントであり、ビッグエンディアン順における４バイトのシーケンスとしてコード化され、その後に各サブフィールド値の標準的なバイト列の結合が続く。サブフィールド数が０である場合、４バイトフィールド数の後に何も続かない（この場合、すべての４バイトは、値０を有する）。
【０８５１】
１．４．整数
ビッグエンディアン順において４バイトのシーケンスとしてコード化される３２ビット整数値。
１．５．ストリング
【表１３０】
2009512096.tif 000132
【０８５２】
ストリングは、ＵＴＦ−８コード化されるバイト列によって表される（ヌル終了しない）。（１）ビッグエンディアン順における４バイトのシーケンスとしてコード化されるストリングのバイト数と、それに続く（２）ストリングのバイト列とからなる、ストリングのための標準的なバイト列。
１．６．バイト
【０８５３】
８ビット値
１．７. ブーリアン
【０８５４】
８ビット値：偽の場合は０、真の場合は１。
２．オクトパスオブジェクトへの応用
【０８５５】
一実施形態において、Ｏｃｔｏｐｕｓオブジェクトのための標準的なバイト列は、オブジェクトモデルにおいて規定される順序におけるフィールドの各々の標準的なバイト列の結合である。
【０８５６】
異種複合タイプについて、フィールドの順序は、タイプ規定において指定される順序である。同種の複合タイプについて、要素の順序は、以下の段落において指定される。
【０８５７】
○属性
オブジェクトの「属性」フィールドは、タイプ「リスト」の命名されていない属性として処理される（それは命名された属性の未ソートのコンテナである）。タイプ「リスト」の属性の値に含まれる命名された属性は、それらの「名前」フィールドによって辞書編集的にソートされる。タイプ「アレイ」の値属性に含まれる命名されていない属性は、ソートされない（アレイ順にシリアル化される）。
【０８５８】
○拡張
オブジェクトの内部拡張は、それらの「ＩＤ」フィールドによって辞書編集的にソートされる。一実施形態において、内部拡張のために、「ｅｘｔｅｎｓｉｏｎＤａｔａ」フィールドは、標準的なバイト列の計算において使用されない。そのような拡張は、署名のためにダイジェストの計算に含まれる必要がある場合、「ｅｘｔｅｎｓｉｏｎＤａｔａ」において運ばれる実際データのダイジェストを表す「ダイジェスト」フィールドを含む。拡張データのタイプごとに、その標準的なバイト列の計算を可能にする定義が与えられる。
【０８５９】
○コントローラ
ＣｏｎｔｅｎｔＫｅｙ参照は、それらの「ＩＤ」フィールドによって辞書編集的にソートされる。
【０８６０】
３．ＳｃｕｂａＫｅｙｓ
「ｐｕｂｌｉｃＫｅｙｓ」、「ｐｒｉｖａｔｅＫｅｙｓ」、および「ｓｅｃｒｅｔＫｅｙｓ」フィールドの鍵は、それらの「ＩＤ』フィールドによって辞書編集的にソートされる。
４．実施例
【表１３１】
2009512096.tif 000133
【０８６１】
クラスＢのインスタンスの標準的なバイト列（ａ［］＝｛７，８，９｝，ｓ＝Ａｂｃ，ｘ＝｛５，４｝，ｓ２＝''''であり、ｏｐｔｉｏｎａｌ ｘは存在しない）は、以下のようにシリアル化される。
【表１３２】
2009512096.tif 000134
【０８６２】
Ｃａｎｏ（Ｘ）は、以下の通りである。
【表１３３】
2009512096.tif 000135
【０８６３】
付録Ｅ
制御プログラムの実施例を以下に提供する。この実施例において、帰属関係状態（登録中に供給される）またはライセンス状態（ライセンス転送中に供給される）を、状態データベース（この例示的実施形態において「Ｓｅａｓｈｅｌｌ」データベースと呼ばれる）に見いだすことができる場合、再生アクションを認可できるということを、ライセンスは示す。ライセンスはまた、ピアがライセンス転送をリクエストすることを可能にする。２つのピアが所与の近似にある場合、この転送は認可される。ライセンスは、ピア上のライセンス状態を設定するエージェントを含む。
【０８６４】
これに続くコードファイルにおいて、以下の通りである。「ＭｏｖａｂｌｅＤｏｍａｉｎＢｏｕｎｄＬｉｃｅｎｓｅ．ａｓｍ」は、主制御である。「ＬｉｃｅｎｓｅＵｔｉｌｓ／＊」は、ライセンスのためのヘルパーである。「ＧｅｎｅｒｉｃＵｔｉｌｓ／＊」は、機能（ストリングの長さの算出、ストリングの比較、スタックの操作など）を実行する一般的なヘルパーである。「ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋＰａｒａｍｅｔｅｒｓ／＊」は、拡張状態ブロックパラメータのＸＭＬ記述、およびＸＭＬからコンパイルされる一連のバイトとしての対応する表現を含む。
【表１３４】
2009512096.tif 000136
【表１３５】
2009512096.tif 000137
【表１３６】
2009512096.tif 000138
【表１３７】
2009512096.tif 000139
【表１３８】
2009512096.tif 000140
【表１３９】
2009512096.tif 000141
【表１４０】
2009512096.tif 000142
【表１４１】
2009512096.tif 000143
【表１４２】
2009512096.tif 000144
【表１４３】
2009512096.tif 000145
【表１４４】
2009512096.tif 000146
【表１４５】
2009512096.tif 000147
【表１４６】
2009512096.tif 000148
【表１４７】
2009512096.tif 000149
【表１４８】
2009512096.tif 000150
【表１４９】
2009512096.tif 000151
【表１５０】
2009512096.tif 000152
【表１５１】
2009512096.tif 000153
【表１５２】
2009512096.tif 000154
【表１５３】
2009512096.tif 000155
【表１５４】
2009512096.tif 000156
【表１５５】
2009512096.tif 000157
【表１５６】
2009512096.tif 000158
【表１５７】
2009512096.tif 000159
【表１５８】
2009512096.tif 000160
【表１５９】
2009512096.tif 000161
【０８６５】
明瞭さを目的として上記を詳細に説明したが、特許請求の範囲内で一定の変更および改造を行ってもよいことは明らかである。本明細書に記載するプロセスおよび装置を実現する多くの代替的方法があるという点に留意すべきである。従って、本実施形態は、例示的なものであって限定的なものではないとみなされるべきであり、進歩性のある一連の作業は、本明細書に提供する詳細に限定されるものではなく、特許請求および同等物の範囲内で変更が可能である。
【図面の簡単な説明】
【０８６６】
進歩性のある一連の作業は、添付の図面に関連して以下の詳細な説明を参照することによって、容易に理解される。
【図１】電子コンテンツの使用を管理するための例示的システムを示す図である。
【図２】進歩性のある一連の作業の実施形態を実施するために使用できるシステムのより詳細な例を示す図である。
【図３】例示的なデジタル著作権管理（ＤＲＭ）エンジンが、ＤＲＭを使用するネットワーク内で機能し得る方法を示す図である。
【図４】ＤＲＭシステムにおける関係をモデル化するために使用するノードおよびリンクのセットを示す図である。
【図５】リクエストされた動作が認可されるか否かをＤＲＭエンジンの実施形態が決定する方法を例示するフローチャートである。
【図６】進歩性のある一連の作業の一実施形態によるＤＲＭライセンスの例を示す図である。
【図７Ａ】一実施形態におけるエージェントの使用方法を例示する図である。
【図７Ｂ】一実施形態におけるエージェントの使用方法を例示する図である。
【図８】ＤＲＭライセンスの実施例を示す図である。
【図９】リクエストされた動作が認可されるか否かをＤＲＭエンジンが決定し得る方法のより詳細な実施例を示す図である。
【図１０】一実施形態のオブジェクトの制御プログラムをＤＲＭエンジンが実行する方法のより詳細な実施例を示す図である。
【図１１】装置上で実行する例示的実施形態のＤＲＭエンジンを示す図である。
【図１２】一実施形態において制御プログラムを実行する際に関わるステップを例示するフローチャートである。
【図１３】一実施形態においてコンテンツを消費するクライアントアプリケーションを構成する要素を示す図である。
【図１４】一実施形態においてコンテンツパッケージングアプリケーションを構成する要素を示す図である。
【図１５】一実施形態による鍵導出メカニズムを示す図である。
【図１６】ＤＲＭシステムの実施例を示す図である。
【図１７】一時的なログインを提供するＤＲＭシステムの実施例を示す図である。
【図１８】企業文書を管理する例示的システムの高水準アーキテクチャを示す。
【図１９】図１８に示すようなシステムを使用することによって、文書に対するアクセスまたは文書の他の使用を管理する、方法の実施例を示す図である。
【図２０】図１８に示すようなシステムを使用することによって、文書に対するアクセスまたは文書の他の使用を管理する、方法の更なる実施例を示す図である。
【図２１】図２０に示す実施例の更なる機能を示す図である。
【図２２】企業内で電子コンテンツを管理するための別の例示的システムを示す図である。
【図２３】本明細書に記載するシステムおよび方法を健康管理記録の管理に応用できる方法を説明する図である。
【図２４】本明細書に示すシステムおよび方法を電子購読サービスの状況に使用できる方法を示す図である。
【図２５】本明細書に記載するシステムおよび方法をホームネットワークドメインの状況に使用できる方法を示す図である。
【図２６】一つの例示的実施形態においてホストアプリケーションとＤＲＭクライアントエンジンとの間で行われる対話処理を示す図である。
【図２７】一つの例示的実施形態においてホストアプリケーションとパッケージングエンジンとの間で行われる対話処理を示す図である。
【図２８Ａ】一実施形態によるライセンスをより詳細に示す図である。
【図２８Ｂ】一つの例示的実施形態におけるリンクとノードとの関係を示す図である。
【図２９】仮想マシンの例示的な実現の操作環境を示す図である。
【図３０】一実施形態による拡張状態ブロックデータ構造を示す図である。
【図３１Ａ】一実施形態におけるデータセグメントのメモリイメージを示す図である。
【図３１Ｂ】一実施形態におけるコードセグメントのメモリイメージの実施例を示す図である。
【図３１Ｃ】一実施形態におけるエクスポートエントリメモリイメージの実施例を示す図である。
【図３１Ｄ】一実施形態におけるエクスポートテーブルエントリの一般的な実施例を示す図である。
【図３１Ｅ】例示的なエントリポイントのためのエクスポートテーブルエントリの実施例を示す図である。
【図３２】ライセンス転送プロトコルの実施例を示す図である。
【図３３】一実施形態によるライセンス転送プロトコルの別の実施例を示す図である。
【図３４】一実施形態におけるライセンスオブジェクトの完全性を保護するためのメカニズムを示す図である。
【図３５】別の実施形態におけるライセンスオブジェクトの完全性を保護するためのメカニズムを示す図である。
【図３６】一実施形態による近似照合プロトコルを示す図である。
【図３７】一実施形態による近似照合プロトコルの使用方法を示す図である。
【図３８】一実施形態におけるクライアントとライセンスサーバとの間の対話処理を示す図である。
【図３９】一実施形態におけるクライアントとライセンスサーバとの間の対話処理をより詳細に示す図である。
【図４０】複数の役割を有するエンティティの実施例を示す図である。
【図４１】一実施形態によるブートストラッププロトコルを示す図である。
【図４２】一実施形態におけるｃｌ４ｎ―ｅｘと例示的ＸＭＬ標準化との関係を示す図である。
【図１】
2009512096.tif 000162
【図２】
2009512096.tif 000163
【図３】
2009512096.tif 000164
【図４】
2009512096.tif 000165
【図５】
2009512096.tif 000166
【図６】
2009512096.tif 000167
【図７Ａ】
2009512096.tif 000168
【図７Ｂ】
2009512096.tif 000169
【図８】
2009512096.tif 000170
【図９】
2009512096.tif 000171
【図１０】
2009512096.tif 000172
【図１１】
2009512096.tif 000173
【図１２】
2009512096.tif 000174
【図１３】
2009512096.tif 000175
【図１４】
2009512096.tif 000176
【図１５】
2009512096.tif 000177
【図１６】
2009512096.tif 000178
【図１７】
2009512096.tif 000179
【図１８】
2009512096.tif 000180
【図１９】
2009512096.tif 000181
【図２０】
2009512096.tif 000182
【図２１】
2009512096.tif 000183
【図２２】
2009512096.tif 000184
【図２３】
2009512096.tif 000185
【図２４】
2009512096.tif 000186
【図２５】
2009512096.tif 000187
【図２６】
2009512096.tif 000188
【図２７】
2009512096.tif 000189
【図２８Ａ】
2009512096.tif 000190
【図２８Ｂ】
2009512096.tif 000191
【図２９】
2009512096.tif 000192
【図３０】
2009512096.tif 000193
【図３１Ａ】
2009512096.tif 000194
【図３１Ｂ】
2009512096.tif 000195
【図３１Ｃ】
2009512096.tif 000196
【図３１Ｄ】
2009512096.tif 000197
【図３１Ｅ】
2009512096.tif 000198
【図３２】
2009512096.tif 000199
【図３３】
2009512096.tif 000200
【図３４】
2009512096.tif 000201
【図３５】
2009512096.tif 000202
【図３６】
2009512096.tif 000203
【図３７】
2009512096.tif 000204
【図３８】
2009512096.tif 000205
【図３９】
2009512096.tif 000206
【図４０】
2009512096.tif 000207
【図４１】
2009512096.tif 000208
【図４２】
2009512096.tif 000209
【国際調査報告】
2009512096.tif 000210
2009512096.tif 000211
2009512096.tif 000212
2009512096.tif 000213
2009512096.tif 000214
2009512096.tif 000215