保護されたリソースの使用の方法を指定する使用権に従って、前記保護されたリソースへのアクセスを付与するシステムにおいて、前記保護されたリソースの状態を管理するシステムであって、前記使用権は、状態変数を含み、前記システムは、前記状態変数によって少なくとも部分的に定義された前記使用権に関連づけられた被保護リソースと、前記使用権実施による前記リソースの使用を制御する、状態マネージャと、前記状態変数の値を追跡する、状態コントローラと、を含むシステムであって、前記状態コントローラが、前記状態変数に関連したメッセージを前記状態マネージャから受け取り、前記メッセージに従って前記状態変数の値を操作する、システム。保護されたリソースの使用の方法を指定する使用権に従って、前記保護されたリソースへのアクセスを付与するシステムにおいて、前記保護されたリソースの状態を管理するシステムであって、前記使用権は、状態変数を含み、前記システムは、前記状態変数によって少なくとも部分的に定義された前記使用権に関連づけられた被保護リソースと、前記使用権実施による前記リソースの使用を制御する、状態マネージャと、前記状態変数の値を追跡する、状態コントローラと、を含むシステムであって、前記使用権は、前記状態変数の値がどのようにして得られるかを示すメソッド指定を更に含み、前記メソッド指定は、前記状態変数の値が記憶されているロケーションを含む、又は、前記状態コントローラと通信するための通信プロトコルを含む、システム。本発明の第1の態様は、使用権に従って、保護されたリソースへのアクセスを付与するシステムにおいて、保護されたリソースの状態を管理するシステムである。使用権は、関連づけられた被保護リソースのステータスを示す状態変数を含む。このシステムは、状態変数によって少なくとも部分的に定義された使用権に関連づけられた被保護リソース、前記リソースに結合され、使用権を実施することによって前記リソースの使用を制御するリソース制御デバイス、状態変数の値を追跡するように動作する状態コントローラ、および前記リソース制御デバイスから前記状態変数に関連したメッセージを受け取り、前記状態コントローラをロードし、前記メッセージに従って状態変数の値を操作することを前記状態コントローラへ命令するように動作するインタフェースフレームワークを含む。本発明の第2の態様は、関連づけられた被保護リソースのステータスを示す状態変数を含む使用権に従って、保護されたリソースへのアクセスを付与するシステムにおいて、保護されたリソースの状態を管理する方法である。この方法は、状態変数に関連したメッセージを、リソース制御デバイスからインタフェースフレームワークへ送信し、前記リソース制御デバイスは、前記リソースへ結合され、使用権を実施することによって前記リソースの使用を制御し、状態変数の値を追跡するように動作する状態コントローラを前記フレームワークへロードし、前記メッセージに従って状態変数の値を操作するように前記状態コントローラへ命令することを含む。本発明は、好ましい実施形態および添付の図面を使用して説明される。異なったタイプのリソースは、許可されない使用からそれらを保護するため、異なったタイプの条件および異なったメカニズムを必要とする。好ましい実施形態において、条件および権利は、保護されたリソースの全体のライフサイクルの一部分である。これは、権利の条件がアクセス許可の前に評価されるだけでなく、リソースの実際の消費の間にも評価されることを意味する。更に、条件は、保護されたリソース、および保護されたリソースの状態の双方に関連づけられる。条件を、保護されたリソースの様々な状態に関連づけることは、異なったタイプのリソースを保護する柔軟な方法を、コンテンツオーナーまたはサービスプロバイダへ提供する。リソースは、ディジタルコンテンツ、ハードウェア、ソフトウェアプログラム、メモリ空間、商品、サービスウェブサービスを含む、時間、料金、使用権、またはライセンスとなり得る。使用権は、使用の方法を指定する。たとえば、使用の方法は、或るアイテムを、指定された方法で指定された期間、使用する能力を含む場合がある。更に、使用権は、譲渡権、たとえば頒布権を指定可能であり、他人への使用権の付与または使用権の派生を許可できる。好ましい実施形態において、条件および権利は、リソースの使用の方法を定義するために関連づけられる。したがって、条件および権利は、好ましい実施形態では単一の実体を意味する。しかし、条件および権利は別々に存在できる。好ましい実施形態は、保護されたリソースの使用または消費の前、間、および後で、権利の条件を確認および認証有効化とする。権利、および関連づけられた条件は、状態として表され、各々の権利の現在の状態および履歴は、ログされて、後で使用可能である。状態変数は、可能的にダイナミックな条件を追跡する。状態変数は、リソースのステータスまたは他のダイナミックな条件を表す値を有する変数である。状態変数は追跡可能であり、状態変数の値は条件の中で使用可能である。たとえば、使用権は、リソースとして、コンテンツを閲覧する権利となり得、条件は、使用権が行使されるとき他のユーザがネットワークへログインされないようにできる。この例では、適切な状態の値が、他のユーザがログインされていることを示すとき、条件は、もはや満足されず、コンテンツを閲覧不可能か、閲覧が終了する。図1は、好ましい実施形態のコンピュータアーキテクチャ10を示す。条件80は、後で詳細に説明され、アイテムの頒布者、コンテンツサービスプロバイダ、企業マネージャ、またはリソース、たとえばディジタルコンテンツへのアクセスを制御したいと望む他の当事者に関連づけられた作成アプリケーション70で、準備できる。条件80を指定するためには、文法、たとえばXrML商標を使用可能である。しかし、条件80は、任意の方法で指定可能である。ユーザは、コンピュータまたはユーザに関連づけられた他のデバイスを含むクライアント環境30内でオペレーションを行う。ソフトウェアアプリケーション12、たとえばレンダリングエンジンまたは他のアプリケーションを、クライアント環境30へインストールできる。状態マネージャ40は、以下で説明するように、保護されたリソース100および派生リソース100aへのアクセスを制御する。好ましい実施形態ではコンピュータデバイスである状態マネージャ40は、リソース100および派生リソース100aへのアクセスのセキュリティ面を処理する。具体的には、状態マネージャ40は、署名、たとえば暗号署名、またはメッセージの他の識別特性を、公知の方法で確認および認証有効化することによって、メッセージを認証可能である。状態マネージャ40は、リソースマネージャ42および条件確認器バリデター44を含む。リソースマネージャ42は、リソースの登録、リソースの変換、およびリソースの終了に責任を有する。変換とは、リソース100から派生リソース100aを派生することを意味する。図7で示されるように、変換は、リソースマネージャ42のリソース変換モジュール48によって達成される。たとえば、リソースが、画像などを表す暗号化ファイルである場合、派生リソース100aは、平文画像自身およびその画像を保持するメモリのアドレスを含むことができる。リソースの登録の間、画像を保持するメモリアドレスは、リソースマネージャ42のリソースリポジトリ46によって記録され、そのメモリ、すなわち派生リソース100aへのアクセスは、追跡可能である。更に、追跡マークたとえば透かし模様が画像へ挿入され、いつでも追跡可能である。条件バリデター44は、設定条件をモニタし、権利状態、即ち、以下で説明するように、所与の権利について状態変数の現在値の集合を管理する。条件バリデター44は、以下で詳細に説明するように、リソースマネージャ46と交信し、派生リソース100aを制御する。現在の権利状態44bが、もはや有効ではないとき、即ち、許可された権利状態44aに対応しないとき、条件バリデター44は、以下で詳細に説明するように、全ての派生リソース100aを削除する使用不能にするか、派生リソース100aの使用が、もはや許されないことをアプリケーション12に通知するようにリソースマネージャ42に要求する。更に、状態マネージャ40は、権利状態フレームワーク20、状態コントローラ22、および状態バリデター24を含む。これらの全ては、以下で詳細に説明する。保護されたリソース100へのアクセスは、条件80に基づく。このタイプの条件は、アクセス条件または事前条件と呼ばれる。しかし、条件をリソース100、およびリソース100の状態の双方に関連づけることによって、リソース100のライフサイクルの様々な段階で、リソース100を保護することが可能になる。リソース100は、ユーザがアクセスを付与される前、アクセスが付与される時、リソース100の実際の使用の間、およびリソース100の使用の後で、保護可能である。保護されたリソースの全体のライフサイクルに関連づけられる条件80は、言語、たとえばXrML商標、データ構造、規則のセットを含む文法を使用することによって、表現可能である。好ましい実施形態は、条件を表すため言語としてのXrML商標を使用する。リソース100を保護するため、リソース100それ自身、または有形であれ無形であれ他のリソースへ条件80を課すことができる。それらのリソースは、保護されたリソース100がアクセスおよび使用される実行環境を作り上げているリソース、たとえばクライアント環境30のアプリケーション12を含む。条件80は、本人としてアクセスを付与され、保護されたリソース100を使用するユーザまたはユーザグループのアイデンティティとなり得る。条件80の例は、XrML商標言語の表現として以下で説明される。例Aは、保護されたディジタルコンテンツXrMLブックを閲覧する権利を付与された本人エドガーに関連づけられた条件を表す。例Bは、本人のグループ、即ち、保護されたディジタル作品XrMLブックを印刷する権利を付与されたカテゴリコンテンツガード従業員に入る全ての人に関連づけられた条件を表す。例A:<ライセンス><インベントリ><ディジタル作品ライセンス部分ID=XrMLブック/><キーホルダライセンス部分ID=エドガー/></インベントリ><付与><キーホルダライセンス部分DRef=エドガー/><閲覧/><ディジタル作品ライセンス部分IDRef=XrMLブック/></付与></ライセンス>例B:<ライセンス><インベントリ><ディジタル作品ライセンス部分ID=XrMLブック/></インベントリ><付与><forAllvarName=コンテンツガード従業員/><本人varRef=コンテンツガード従業員/><印刷/><ディジタル作品ライセンス部分IDRef=XrMLブック/></付与></ライセンス>条件80は、或る特性、たとえば或る資格、または権利、たとえばセキュリティ許容度を所有していなければならない本人の条件となり得る。例Cは、本人が管理者のバッジを所有していなければならない条件を表す。例C:<ライセンス><インベントリ><ディジタル作品ライセンス部分ID=XrMLブック/><キーホルダライセンス部分ID=エドガー/></インベントリ><付与><forAllvarName=誰でも/><本人varRef=誰でも/><所有特性/><バッジ><資格>管理者</資格></バッジ><閲覧/><ディジタル作品ライセンス部分IDRef=XrMLブック/></付与></ライセンス>条件80は、保護されたアイテムへアクセスする時間間隔の条件となり得る。下記の例Dは、本人としての鍵保持者エドガーが、2002年5月29日の前、および2003年5月29日の後では、コンテンツXrMLブックを閲覧できない条件を表す。例D:<ライセンス><インベントリ><ディジタル作品ライセンス部分ID=XrMLブック/><キーホルダライセンス部分ID=エドガー/></インベントリ><付与><キーホルダライセンス部分IDRef=エドガー/><閲覧/><ディジタル作品ライセンス部分IDRef=XrMLブック/><有効期間><前でない>2002-05-29T00:00:00</前でない><後でない>2003-05-29T00:00:00</後でない></有効期間></付与></ライセンス>条件80は、本人の物理的ロケーションまたはコンテンツにアクセスするために使用されるリソースに関連し得る。下記の例Eは、現在米国にいる人は、誰でもコンテンツXrMLブックを印刷できる条件を表す。例E:<ライセンス><インベントリ><ディジタル作品ライセンス部分ID=XrMLブック/></インベントリ><付与><forAllvarName=誰でも/><本人varRef=誰でも/><印刷/><ディジタル作品ライセンス部分Id=XrMLブック/><地域><国>米国</国></地域></付与></ライセンス>条件80は、本人がアクセスに対して支払わなければならない料金を指定可能である。下記の例Fは、3.10ドルの料金を支払えば、誰でもコンテンツXrMLブックを印刷できる条件を表す。下記の例Gは、各々の印刷について3.10ドルの料金を支払えば、誰でもコンテンツXrMLブックを印刷できる条件を表す。下記の例Hは、1時間の閲覧時間ごとに10.00ドルを支払えば、誰でもコンテンツXrMLブックを閲覧できる条件を表す。例F:<ライセンス><インベントリ><ディジタル作品ライセンス部分ID=XrMLブック/></インベントリ><付与><forAllvarName=誰でも/><本人varRef=誰でも/><印刷/><ディジタル作品ライセンス部分Id=XrMLブック/><料金><一律支払い><レート通貨=米国ドル>3.10</レート></一律支払い><to><aba><金融機関>123456789</金融機関><アカウント>987654321</アカウント></aba></to></料金></付与></ライセンス>例G:<ライセンス><インベントリ><ディジタル作品ライセンス部分ID=XrMLブック/></インベントリ><付与><forAllvarName=誰でも/><本人varRef=誰でも/><印刷/><ディジタル作品ライセンス部分IDRef=XrMLブック/><料金><使用当たりの支払い><レート通貨=米国ドル>3.10</レート></使用当たりの支払い></料金></付与></ライセンス>例H:<ライセンス><インベントリ><ディジタル作品ライセンス部分ID=XrMLブック/></インベントリ><付与><forAllvarName=誰でも/><本人varRef=誰でも/><閲覧/><ディジタル作品ライセンス部分IDRef=XrMLブック/><料金><時間ベース支払い><レート通貨=米国ドル>10.00</レート><per>PT1H</per><フェーズ>PT10M</フェーズ></時間ベース支払い><to><aba><金融機関>123456789</金融機関><アカウント>987654321</アカウント></aba></to></料金></付与></ライセンス>下記の例Iは、誰でもコンテンツを印刷できるが、印刷の前に、印刷権の行使が追跡サービスによって追跡される条件を表す。例I:<ライセンス><インベントリ><ディジタル作品ライセンス部分ID=XrMLブック/><キーホルダライセンス部分ID=エドガー/></インベントリ><付与><forAllvarName=誰でも/><本人varRef=誰でも/><印刷/><ディジタル作品ライセンス部分IDRef=XrMLブック/><追跡レポート><状態リファレンス><uddi><サービスキー><uuid>...</uuid></サービスキー></uddi><サービスパラメータ></サービスパラメータ></状態リファレンス></追跡レポート></付与></ライセンス>更に、条件80は、リソース100が消費されるシステムの条件となり得る。たとえば、条件80は、システムが、許可されたセキュリティメカニズムまたは他の特定のハードウェアまたはソフトウェアを有するか、特定最大数のユーザだけがログオンされることを要求可能である。条件80は、リソース100、たとえばコンテンツが存在するリポジトリまたは他のデバイスを指定可能である。更に、条件80は、本人が、保護されたリソース100を使用する前に獲得しなければならない承認表示に関連し得る。条件80は、リソース100の使用前または使用後に通知を要求できる。条件80は、保護されたリソース100または他のリソースに関連した以前の権利を指定可能である。更に、条件80は、他の条件80、たとえば条件の確認方法に課されることができる。もちろん、条件80は、上記の例に限定されず、事前条件、アクセス中の条件、事後条件、または他の条件として、保護されたリソース100に対する権利に関連づけられる任意の制限、義務、または要件となり得る。更に、上記の例はXrML商標を使用して表されたが、条件はXrMLに限定されず、任意の方法で表される。図4は概略的に、好ましい実施形態に従った条件80を示す。条件80は、暗黙的または明示的に表されるリソース表示82を含む。たとえば、前記の例Aにおいて、リソース表示82は、ディジタル作品要素の属性ライセンス部分IDによって示される。更に、条件80は、状態変数84、および状態変数84の値がどのようにして得られるかを示すメソッド指定86を含む。メソッド指定86は、状態変数84の値が記憶されているロケーションたとえば、以下で説明するように条件を管理する遠隔状態コントローラ、条件が管理される状態コントローラと通信するための通信プロトコル、および値を獲得するために必要なパラメータたとえばサービスパラメータなどを含むことができる。代替的に、メソッドはシステムの中でハードコードされることができ、メソッド指定86は省略可能である。前述したように、状態変数84は、条件80のステータスを表す。各々の状態変数44は、本人、権利、およびリソースについて任意の時点の対応値を有する。前述したように、所与の権利に対する状態変数の現在値の集合は、ここでは権利状態と呼ばれる。図5は、条件80、および条件80の状態変数84の現在値52を含む好ましい実施形態の権利状態50を示す。メソッド指定56は、状態変数84の現在値52を得るために使用されるメソッドを示し、可能性として、その現在値が得られるソース、信任状のディジタル署名、リクエストのセッションID、および他の適切な情報を含む。注意すべきは、メソッド指定56は、メソッド指定86に対して冗長であると考えられ、単にその繰り返しであり得る。しかし、幾つかの場合には、値52を実際に獲得するために使用されるメソッド指定56は、条件80で使用されることを暗示されるメソッド指定86とは異なる場合がある。権利について条件80を表すため権利状態50を使用することは、条件80を確認するプロセスを簡単にする。なぜなら、条件80を確認するために必要な全ての情報を、容易にアクセスできるからである。権利状態50は、対応する条件80が評価および確認されるとき、常に構成されて使用される。各々の権利状態50は、状態変数84の値52を確認するために必要な全ての情報を含むことができる。認証された本人は、システムによって処理されたユーザである。システムはそのユーザの真正性を確認し、たとえば、ユーザがユーザ名およびパスワードを使用して成功裏にログインしたとき、そのユーザは、認証された本人または正に本人になる。権利の所与のセットに対する条件80は、本人が、保護されたリソース100にアクセスすることを許される必要状態変数値のセットとして定義される。認証された本人が、保護されたリソース100のアクセスを望むとき、システムの状態は、オリジナル状態から許可状態へ変化する。一度、システムが許可状態に置かれると、本人は、許可されたオペレーションについて、保護されたリソース100にアクセス可能である。多くの場合、保護されたリソース100へ実際にアクセスするのは、認証された本人自身ではない。たとえば、アクセスは他の認証された本人、たとえばレンダリングアプリケーション、サービスなどへ委任可能である。保護されたリソース100がアクセスおよび消費される間、最初のアクセスを付与する事前条件80のセットは、もはや継続アクセスを許可するために適用できないことがある。更に、保護されたリソース100の消費は、リソースを一時的、即ち、派生されたリソース100aのセットへ変換し、オリジナルリソースの上に課されたアクセス条件80も、それから適用することはできない。リソース100およびその派生リソース100aを、アクセスされている間に保護するため、好ましい実施形態は、以下で詳細に説明するアクセス中条件と呼ばれる許可および保護概念を使用する。従来のシステムにおいて、リソースは2つの状態の1つにある。図2で示されるように、リソース100がアクティブでないとき、システムは、事前条件が満足されるまで、オリジナル状態102にある。事前条件が満足された時点で、リソース100はアクティブになり、システムは、許可またはアクティブ状態104へ入る。リソースの制御を増進するため、好ましい実施形態は、オリジナル状態および許可状態に加えて、2つの追加状態を定義する。図3で示されるように、保護されたリソース100の使用またはアクセスの間に、システム状態は、次の状態を経て変化する。即ち、オリジナル状態102、許可状態104、使用状態106、および終了状態108である。各々の状態について、次の状態へ移行するか、同じ状態の中で継続するため、満足されなければならない条件80を定義可能である。図1に関して説明したように、条件80は、必要なユーザインタフェースおよび編集能力を含む作成アプリケーション70を使用して定義および準備できる。許可状態へ入るために満足されなければならない条件80は事前条件と呼ばれる。リソース100の使用中に満足されなければならない条件80はアクセス中条件と呼ばれ、使用の終了時に必要な条件80は事後条件と呼ばれる。条件バリデター44は、各々の状態に必要な条件80を呼び出すことができる。アクセス中条件は、オリジナルリソース100および派生リソース100aが、認証された本人によってアクセスおよび消費されている間、オリジナルリソース100から、それ自身および派生リソース100aへ転移する。たとえば、もしリソース100が、許可されたオペレーション閲覧の間にクライアント環境30のスクリーン上に表示される文書であれば、派生リソース100aは、文書からのデータを含むメモリ、文書のプレゼンテーションフォーマット、および表示されたウィンドウを含むことができる。派生リソース100aの全ては、アクセス中条件のセットによって保護されるであろう。言い換えれば、本人は、アクセス中条件が満足される限りでのみ、派生リソース100aへのアクセスを有する。アクセス中条件は、他の条件80と同じように定義が可能である。他の例は、アプリケーション、たとえばアプリケーション12が、保護されたリソース100であるサービスをリクエストする場合である。一度、リクエストが許可されると、そのサービスを実行するアプリケーションは派生リソースとして考えられ、サービスが実行されている間、アクセス中条件のセットに従う。アクセス中条件は、以下で詳細に説明するように現在の権利状態44bへ適用される許可された権利状態44aを定義する。一度、リクエストされたオペレーションが強制的または任意的に終了すると、アクセス中条件によって保護された全ての派生リソース100aは削除または使用不能にされ、システム状態は事後アクセス条件のセットによって最終状態へ移行する。リソースの使用またはアクセスの後または間の条件80は、変化してもよいし変化しなくてもよい。状態が変化しない条件は、ステートレスstateless条件と呼ばれ、リソースの使用の後または間に変化する条件は、ステートフルstateful条件と呼ばれる。事前条件80は、通常、ステートレス条件80であり、保護された文書へのアクセスを制御するために使用される。アクセス中条件および事後条件は、通常、ステートフル条件80である。それらは、保護されたリソース100のライフタイムを制御するために使用される。たとえば、保護されたリソース100は、一度ネットワークへログインしたユーザの数が特定の数を超過すると、もはやアクセスされることはできない。保護されたリソース100の異なった段階に関連づけられた条件80のこれらの拡張タイプを使用することによって、好ましい実施形態は、保護されたリソース100の使用を許可し、リソース100が使用されている間にリソース100を保護および追跡するメカニズムを提供する。図3に示されるように、また図1を参照すると、好ましい実施形態に従ったシステムは、3つの段階を経て進行する。アクセス許可段階302は、状態マネージャ40が、事前条件が満足されたことを確認することによって、許可されたオペレーションについて、保護されたリソース100のアクセスを、認証された本人に許可する段階である。リソース保護段階304は、状態マネージャ40が、アクセス中条件が満足されたままであることを確認することによって、リソース100および派生リソース100aが使用されている間、それらのリソースを保護する段階である。オペレーション終了段階306は、事後アクセス条件が満足されるか、アクセス中条件が満足されるのを終了したとき、状態マネージャ40が、所与のオペレーションについて、保護されたリソース100および派生リソース100aの使用を終了する段階である。同じリソース100に対して多数のアクセスが与えられる再帰的な状況では、事後条件は、次のサイクルの事前条件と同じである場合がある。そのような場合、無限ループの状況を防止するため、非静止パラメータを使用可能である。たとえば、時間依存条件、または外部実体、たとえば人間の介在によって修正または強制される条件である。アクセス許可は、許可されたオペレーションについて、保護されたリソース100にアクセスする権利を、認証された本人に付与する。事前条件は、権利状態に対して評価、即ち、実施される。もし実施が成功すれば、リソース100および派生リソース100aは、ステップ406で許可状態へ入り、アクセス中条件が実施を開始される。前述したように、リソースの保護は、アクセス中条件のセットを実施することによって、最初の保護されたリソース100および派生リソース100aの双方を保護する。アクセス許可状態から返された許可状態は、許可されたオペレーションの間に実施されるべきアクセス中条件のリストを含む。強制システムでは、全ての派生リソース100aは、それが生成および使用されるとき、リソースマネージャ42のリソースリポジトリ46図7および以下の説明を参照を使用して登録可能である。もしアクセス中条件が無効になれば、リソースマネージャ42は、アプリケーション12によって、保護されたリソース100および派生リソース100aへのアクセスを不能にする。許可されたオペレーションの終了は、事後条件のセットもし存在すればを実行する。事後条件の実行は、権利状態を永続的に変更可能であり、リソース100への次のアクセスリクエストに影響を与える。たとえば、もし事後条件が、行使限度に達した後のリソース100へのアクセスの除去であれば、限度に到達したとき、リソース100は削除されるか、アクセスを不能にするか禁止する他のアクションが取られる。オペレーションの終了は、リソースの終了を含むことができる。オペレーションが終了されつつあるとき、そのオペレーションが終了を強制されているか、またはアプリケーションが任意的にオペレーションを終了しているか否かを問わず、リソースマネージャ42は、派生リソース100aを削除使用不能に可能である。派生リソース100aの削除または使用不能は、リソース100の保護プロセスで重要である。条件バリデター44は、保護されたリソース100の使用をコミット、制約し、事後条件のセットを実施する。条件バリデター44は、もしリソース100が、システム状態の変化の結果として無効になれば、保護されたリソース100を無効使用不能にする。権利状態は、リソース100の使用の間に変化し、したがって権利状態を維持、更新、および検索する必要があることが分かる。前述したように、条件バリデター44は、現在の権利状態44bにアクセスし、権利に関連づけられた条件80を認証有効化する。リソース100が使用またはアクセスされている間、条件バリデター44は、アクセス中条件のセットをモニタし、現在の権利状態44bを管理する。条件バリデター44は、リソースマネージャ42と交信し、派生リソース100aを制御する。現在の権利状態がもはや有効でないとき、即ち、もはやアクセス中条件を満足させないとき、アクセス中条件バリデター44は、全ての派生リソース100aを削除または使用不能にするか、派生リソース100aの使用がもはや許されないことをアプリケーション12へ通知するようにリソースマネージャ42へリクエストする。条件80を表すために権利状態を使用することは、条件80の確認プロセスを簡単にする。なぜなら、特定の条件80を確認するために必要な情報の全てを容易に得ることができるからである。図1および図6で示されるように、状態マネージャ40は、更に、権利状態フレームワーク20を含む。権利状態フレームワーク20は、APIを条件バリデター44へ提供し、またプラグインインフラストラクチャを状態コントローラ22および状態バリデター24へ提供する。フレームワーク20は、複数の状態コントローラ22およびバリデター24の間でタスクの協調及び通信を処理する。各々の状態コントローラ22は、所与の状態変数の状態を管理、即ち、その値を追跡するコンポーネントである。状態コントローラ22の基本構造は、権利状態フレームワーク20によって定義されたAPIを処理するソフトウェアコンポーネントから構成される。このソフトウェアコンポーネントは、持続性記憶またはサービスと交信して、状態変数の現在値および状態変数の履歴を記憶、更新、および質問するプロトコルによる。したがって、状態変数を管理する持続性記憶またはサービスのロケーションは、権利状態フレームワーク20に対して明らかである。各々の状態バリデター24は、状態変数の値を確認するコンポーネントである。各々の状態バリデター24は、権利フレームワーク20の状態認証有効化およびモニタリングAPI20cによって定義されたインタフェースのセットを実現するソフトウェアコンポーネントを含む。状態コントローラ22と同じように、状態バリデター24は、ローカルまたはリモートで動作可能である。図6で示されるように、権利状態フレームワーク20は、権利状態の値を初期化、質問、更新、および転移するインタフェースのセットである状態操作API20bを含む。前述したように、条件80の基本構造は、状態変数、および状態変数の現在値を獲得するために必要なメソッドを含む。状態変数と同じように、値は、文法、たとえば現在値を記述するデータ構造またはXrML商標権利言語によって表されることができる。好ましい実施形態は、XrML商標を使用して、状態変数およびその拡張を定義し、状態変数の値を定義する。しかし、状態変数およびその値の表現は、XrML商標に限定されない。次の例は、XrML商標を使用して、どのように状態変数を定義できるかを示す。例5:<印刷/><sx:状態リファレンス><uddi><サービスキー><uuid>1F8903BO-FC03-4c5b-A445-AAFCCEC011111</uuid></サービスキー></uddi></sx:状態リファレンス><sx:行使限度>9</sx:行使限度上記の例は、印刷されるリソースのコピーが9つを超えることを許さない印刷権の状態変数を記述する。状態に関連づけられた値は、行使限度の例と同じように簡単な数値にするか、承認を必要とする例のようにブール値イエスまたはノーとなり得る。更に、値は、下記の例Kで示されるように、サービスまたはコンポーネントによって記憶および管理が可能である。例K:<再生/><有効期間浮動><sx:状態リファレンス><uddi><サービスキー><uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC011111</uuid></サービスキー></uddi></sx:状態リファレンス></有効期間浮動>例Kは、再生権の浮動期間に関連づけられた状態を示す。この例では、状態変数は、条件に関連づけられた実際の値を含まない。むしろ、状態コントローラ22として働く遠隔サービス状態リファレンスが値を管理する。それは、状態変数の表現では不透明である。状態操作API20bは、状態変数の値を質問する質問クエリーインタフェースを含む。状態変数値のクエリーは、質問される状態変数、およびレスポンスの値のタイプを含む入力を必要とする。状態クエリーのレスポンス値は、状態値、状態履歴、またはこれらの双方となり得る。次の例Lでは、状態変数行使限度の値が、印刷権に関連づけられる。例L:<状態クエリー><印刷権の状態または行使限度条件><印刷/><sx:状態リファレンス><uddi><サービスキー><uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC011111</uuid></サービスキー></uddi></sx:状態リファレンス><sx:行使限度/><特定のレスポンスタイプのリクエスト><レスポンスタイプ=値></状態クエリー>クエリーを処理するため、権利状態フレームワーク20は、どの状態コントローラ22がこのリクエストに責任を有するかを決定し、その特定の状態コントローラ22を位置決め、認証、およびロードし、そのリクエストを処理のために状態コントローラ22へ渡す。状態コントローラ22は、ローカルまたはリモートとなり得る。一度、リクエストが処理されると、権利状態フレームワーク20を介してレスポンスがリクエスト発信者へ返却される。次の例Mは、レスポンスを記述する。例M:<状態レスポンス><次のクエリーリクエストへのレスポンス><状態クエリー><印刷/><sx:状態リファレンス><uddi><サービスキー><uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC011111</uuid></サービスキー></uddi></sx:状態リファレンス><sx:行使限度>9</sx:行使限度></状態クエリー><状態クエリーから返却された状態値></状態値>8</状態値><信任状のディジタル署名><dsig:署名>...</dsig:署名></状態レスポンス>クエリーレスポンスは、元のクエリー、もし該当すれば、質問された状態変数の現在値、状態変数の現在のステータスまたは状態履歴、識別子、セッションID、およびレスポンスのディジタル署名を含む。ディジタル署名は、レスポンスの完全性を保証するために使用可能である。状態は、もし状態クエリーレスポンス内のセッションIDが有効であれば、状態クエリーの前のレスポンスに基づいてのみ更新可能である。セッションIDは、好ましい実施形態でリクエストを識別するために使用されるが、クエリーと更新をマッチさせるため、任意の他の識別子を使用可能である。したがって、状態マネージャ40は、状態変数の現在値を質問して状態変数値および有効なセッションIDを獲得し、ターゲットの状態変数を更新しなければならない。状態変数値の更新は、状態変数の現在値を新しい値へ変更するであろう。状態変数値の更新には、多くの制約を課すことができる。たとえば、状態変数に関連づけられた権利は、更新リクエストの前に有効でなければならない。他の制約は、更新の後の状態変数の新しい値が、状態変数に許された有効値でなければならないことである。たとえば、もし最大印刷コピーが4であり状態変数、現在の印刷コピーが3であれば状態変数の現在値、あと2つのコピーのリクエスト更新値は拒絶されるであろう。なぜなら、更新後の状態変数の値は、許された値ではないからである。更に、更新をリクエストしている本人またはアプリケーションは、それを許可されていなければならない。権利状態フレームワーク20は、状態コントローラ22を識別、認証、およびロードして、更新リクエストを処理する。下記の例Mは、状態値を更新するリクエストの例である。例M:<状態更新><以前のクエリー値の更新。もしクエリーが状態変数の現在値と><マッチしなければ、更新リクエストは失敗する><状態クエリー><sx:状態リファレンス><uddi><サービスキー><uuid>1F8903B0-FC03-4c5b-A445-AAFCCEC011111</uuid></サービスキー></uddi></sx:状態リファレンス><sx:より多くない>9</sx:より多くない><セッションIDは、更新されたリクエストおよび以前のクエリーとマッチするように><処理系によって特定される。代わりに、他の識別スキームを使用可能である><セッションID>...</セッションID><状態コントローラ><id>...</id></状態コントローラ><状態値>8</状態値><dsig:署名>...</dsig:署名></状態クエリー><更新値>1</更新値></状態更新>状態値の転移は、状態管理に関して状態値の更新と類似している。2つの間の主な相違は、状態変数の状態履歴が、どのようにして維持されるかの点である。一度、状態が転移すると、状態変数の現在値およびその履歴は、転移に従って更新される。もし状態を転移された権利が、状態転移の結果として満了すれば、転移は完全転移と呼ばれ、そうでなければ、部分転移と呼ばれる。状態値の転移は、状態値の更新と同じ制約を有し得る。状態値の転移に伴うエレメントは、転移が起こる前に許可されることができる。状態マネージャ40は、更に、状態バリデター24のセットを管理し、各々の状態変数を個別的に確認するか、権利状態を表すセットとして確認するアプリケーションへ、インタフェースのセットを提供する。権利状態は、所与の権利に関連づけられた状態変数の現在値の集合であることを想起されたい。権利状態フレームワーク20は、状態変数の各々のために、適切な状態バリデター24を選択およびロードする。一度、状態バリデター24が選択およびロードされると、権利状態フレームワーク20は、ターゲットの状態バリデター24へリクエストを渡し、レスポンスメッセージとしての結果を待つ。状態マネージャ40は、状態変数とシステム構成との間の依存性に依存して、全ての状態バリデター24を一度だけ同時に実行するか、逐次に実行可能である。状態バリデター24は、状態クエリーレスポンスを与えられた状態変数値を確認する。状態変数の発効リクエストを受け取ると、権利状態フレームワーク20は、状態クエリーレスポンスを検査し、適切な状態バリデター24を選択、認証、およびロードし、状態クエリーレスポンスを状態バリデター24へ渡す。構成可能なポリシーおよび状態クエリーに記憶された情報に基づいて、状態バリデター24は、状態クエリーおよびレスポンスの双方に記憶された情報を受け入れるか問題にすることができる。一度、状態クエリーおよびレスポンスに記憶された情報が確認されると、確認プロセスは、状態変数の現在値と状態変数の可能なまたは許された値のセットとを比較するだけの簡単なものにすることができる。各々の状態バリデター24は、権利状態フレームワーク20によって定義されたインタフェースのセットを実現するソフトウェアコンポーネントを含むことができる。状態バリデター24は、ローカルまたはリモートでオペレーション可能である。好ましい実施形態は、様々なデバイス、たとえばパーソナルコンピュータ、サーバ、ワークステーション、PDA、シンクライアントなどを利用可能である。たとえば、クライアント環境は、ハンドヘルドデバイス、たとえば携帯電話またはPDAとなり得る。様々な通信チャネルを使用可能である。更に、様々な機能を1つのデバイスに集積可能である。開示された機能デバイスおよびモジュールは、明瞭性を目的として機能ごとに区分されている。しかし、様々な機能を、ハードウェアおよび/またはソフトウェアモジュールおよびデバイスとして、どのようにでも結合または分離可能である。様々な機能モジュールおよびデバイスは、別個または組み合わせた有用性を有する。様々なレコード、メッセージ、要素、および、それらの部分は、同じデバイスまたは異なったデバイスに記憶可能である。様々なリンク、リファレンス、指定などは、要素を関連づけるために使用可能である。任意のタイプのリソースへのアクセスを制御可能である。状態変数の値を追跡するため、任意のメカニズムを使用可能である。本発明は、好ましい実施形態および例を使用して説明された。しかし、添付のクレイムおよび法的均等物によって規定される本発明の範囲から逸脱することなく、様々な修正を行うことができる。