(57)【要約】【課題】保護されたリソースへのアクセスを、使用権に従って付与するシステムにおいて、保護されたリソースの状態を管理する方法およびシステムを提供する。【解決手段】保護されたリソースへのアクセスを、使用権に従って付与するシステムにおいて、保護されたリソースの状態を管理する方法およびシステム。使用権は、関連づけられた被保護リソースのステータスを示す少なくとも１つの状態変数を含む。状態変数に関連したメッセージが、リソース制御デバイスからインタフェース・フレームワークへ送信される。リソース制御デバイスは、使用権を実施することによってリソースの使用を制御するため、リソースへ結合される。状態変数の値を追跡するように動作する状態コントローラが、フレームワークへロードされ、前記メッセージに従って状態変数の値を操作するように命令される。たとえば、メッセージは、状態変数の現在値のクエリーとなり得る。【選択図】図１
2012018701.tif 000002
【特許請求の範囲】
【請求項１】
保護されたリソースの使用の方法を指定する使用権に従って、前記保護されたリソースへのアクセスを付与するシステムにおいて、前記保護されたリソースの状態を管理するシステムであって、前記使用権は、状態変数を含み、前記システムは、
前記状態変数によって少なくとも部分的に定義された前記使用権に関連づけられた被保護リソースと、
前記使用権実施による前記リソースの使用を制御する、状態マネージャと、
前記状態変数の値を追跡する、状態コントローラと、
を含むシステムであって、
前記状態コントローラが、前記状態変数に関連したメッセージを前記状態マネージャから受け取り、前記メッセージに従って前記状態変数の値を操作する、
システム。
【請求項２】
保護されたリソースの使用の方法を指定する使用権に従って、前記保護されたリソースへのアクセスを付与するシステムにおいて、前記保護されたリソースの状態を管理するシステムであって、前記使用権は、状態変数を含み、前記システムは、
前記状態変数によって少なくとも部分的に定義された前記使用権に関連づけられた被保護リソースと、
前記使用権実施による前記リソースの使用を制御する、状態マネージャと、
前記状態変数の値を追跡する、状態コントローラと、
を含むシステムであって、
前記使用権は、前記状態変数の値がどのようにして得られるかを示すメソッド指定を更に含み、前記メソッド指定は、前記状態変数の値が記憶されているロケーションを含む、又は、前記状態コントローラと通信するための通信プロトコルを含む、
システム。
【発明の詳細な説明】
【技術分野】
【０００１】
（著作権表示）
この特許文書の開示の一部分は、著作権の保護を受ける資料を含んでいる。著作権の所有者は、特許商標庁の特許ファイルまたはレコードに現れる通りの特許文書または特許開示を、何人が複製しようとも異議を有しないが、それ以外の場合は、全ての著作権を留保する。
【０００２】
本発明は、コンピュータ・システムにおけるリソースの管理に関する。更に具体的には、本発明は、保護されたリソース、たとえばディジタル・コンテンツの状態、および保護されたリソースに関連づけられた使用権を追跡する方法および装置に関する。
【背景技術】
【０００３】
電子手段、特にインターネットを介して広範囲に頒布されるディジタル作品（即ち、コンピュータによって読み取り可能な形式の文書または他のコンテンツ）に関して、差し迫った最も重要な問題の１つは、現在、ディジタル作品が頒布および使用される間、コンテンツ・オーナーが知的所有権を実施する能力を欠いていることである。この問題を解決する努力は、これまで「知的所有権マネジメント（Ｉｎｔｅｌｌｅｃｔｕａｌ  Ｐｒｏｐｅｒｔｙ  Ｒｉｇｈｔｓ  Ｍａｎａｇｅｍｅｎｔ（ＩＰＲＭ））」、「ディジタル所有権マネジメント（Ｄｉｇｉｔａｌ  Ｐｒｏｐｅｒｔｙ  Ｒｉｇｈｔｓ  Ｍａｎａｇｅｍｅｎｔ（ＤＰＲＭ））」、「知的財産マネジメント（Ｉｎｔｅｌｌｅｃｔｕａｌ  Ｐｒｏｐｅｒｔｙ  Ｍａｎａｇｅｍｅｎｔ（ＩＰＭ））」、「権利マネジメント（Ｒｉｇｈｔｓ  Ｍａｎａｇｅｍｅｎｔ（ＲＭ））」、および「電子著作権マネジメント（Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｐｙｒｉｇｈｔ  Ｍａｎａｇｅｍｅｎｔ（ＥＣＭ））」と呼ばれてきたが、ここでは集約的に「ディジタルライツ・マネジメント（Ｄｉｇｉｔａｌ  Ｒｉｇｈｔｓ  Ｍａｎａｇｅｍｅｎｔ（ＤＲＭ））」と呼ぶことにする。ＤＲＭシステムを達成するには、考慮すべき多くの問題が存在する。たとえば、認証、許可、アカウンティング、支払いおよび金融決済、権利指定、権利確認、権利実施、および文書保護の問題が考慮されなければならない。参照によってここに開示を組み込まれる特許文献１、特許文献２、特許文献３、特許文献４、特許文献５は、これらの問題を考慮しているＤＲＭシステムを開示している。
【０００４】
たとえば、特許文献２は、ディジタル文書の頒布を制御するシステムを開示している。各々のレンダリングデバイスは、それに関連したリポジトリを有する。使用トランザクション・ステップの所定のセットが、文書に関連づけられた使用権を実施するため、リポジトリによって使用されるプロトコルを定義する。使用権は文書コンテンツと一緒に存続する。使用権は、コンテンツ使用の様々な方法、たとえば、閲覧のみ、一回の使用、頒布などを指定する。使用権に従ってコンテンツへのアクセスを許す前に、事前条件、たとえば料金の支払い、アイデンティティの証明、または他の条件を要求可能である。一度、事前条件が満足されると、コンテンツへのアクセスが付与される。条件付きアクセスの概念は、アクセス制御アプリケーションでも良く知られている。たとえば、ログイン名およびパスワードを入力すると、ネットワーク・リソースへのアクセスが付与されることが知られている。
【０００５】
条件付きアクセスの概念は、アクセス制御およびＤＲＭシステムの双方の基礎である。典型的な事前条件、即ち、アクセスを付与する条件は、許可されたユーザのリスト、および所与のリソースへのアクセス権利並びに条件のセットを定義する。所与のリソースに関連づけられた事前条件は、或るユーザに関連づけられたリソースとして定義が可能である。これは、「役割ベース」のアクセス制御として知られる。更に、事前条件は、「規則ベース」のアクセス制御として知られるプロセスで、規則によって定義が可能である。事前条件の双方のタイプは、アクセス制御リストとして表現される。アクセス制御リストは、或る言語またはデータ構造の中で定義されたリソースまたは規則のセットである。
【０００６】
条件付きアクセスは、典型的には、大部分のシステムによって、許可プロセスとして実現される。その場合、本人（たとえば、人、システム、またはプロセス）は、或る条件が満足および／または確認された後に、保護されたリソースへのアクセスを許される。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】米国特許第５，５３０，２３５号
【特許文献２】米国特許第５，６３４，０１２号
【特許文献３】米国特許第５，７１５，４０３号
【特許文献４】米国特許第５，６３８，４４３号
【特許文献５】米国特許第５，６２９，９４０号
【発明の概要】
【課題を解決するための手段】
【０００８】
本発明の第１の態様は、使用権に従って、保護されたリソースへのアクセスを付与するシステムにおいて、保護されたリソースの状態を管理するシステムである。使用権は、関連づけられた被保護リソースのステータスを示す状態変数を含む。このシステムは、状態変数によって少なくとも部分的に定義された使用権に関連づけられた被保護リソース、前記リソースに結合され、使用権を実施することによって前記リソースの使用を制御するリソース制御デバイス、状態変数の値を追跡するように動作する状態コントローラ、および前記リソース制御デバイスから前記状態変数に関連したメッセージを受け取り、前記状態コントローラをロードし、前記メッセージに従って状態変数の値を操作することを前記状態コントローラへ命令するように動作するインタフェース・フレームワークを含む。
【０００９】
本発明の第２の態様は、関連づけられた被保護リソースのステータスを示す状態変数を含む使用権に従って、保護されたリソースへのアクセスを付与するシステムにおいて、保護されたリソースの状態を管理する方法である。この方法は、状態変数に関連したメッセージを、リソース制御デバイスからインタフェース・フレームワークへ送信し、前記リソース制御デバイスは、前記リソースへ結合され、使用権を実施することによって前記リソースの使用を制御し、状態変数の値を追跡するように動作する状態コントローラを前記フレームワークへロードし、前記メッセージに従って状態変数の値を操作するように前記状態コントローラへ命令することを含む。
【図面の簡単な説明】
【００１０】
【図１】好ましい実施形態のコンピュータ・アーキテクチャのブロック図である。
【図２】従来のアクセス制御モデルの状態の略図である。
【図３】好ましい実施形態の状態の略図である。
【図４】好ましい実施形態の条件／権利の略図である。
【図５】好ましい実施形態の権利の状態の略図である。
【図６】好ましい実施形態の状態マネージャの略図であって、権利状態フレームワークの詳細を示す。
【図７】状態マネージャの略図であって、リソース・マネージャの詳細を示す。
【発明を実施するための形態】
【００１１】
本発明は、好ましい実施形態および添付の図面を使用して説明される。
【００１２】
異なったタイプのリソースは、許可されない使用からそれらを保護するため、異なったタイプの条件および異なったメカニズムを必要とする。好ましい実施形態において、条件および権利は、保護されたリソースの全体のライフサイクルの一部分である。これは、権利の条件がアクセス許可の前に評価されるだけでなく、リソースの実際の消費の間にも評価されることを意味する。更に、条件は、保護されたリソース、および保護されたリソースの状態の双方に関連づけられる。条件を、保護されたリソースの様々な状態に関連づけることは、異なったタイプのリソースを保護する柔軟な方法を、コンテンツ・オーナーまたはサービス・プロバイダへ提供する。リソースは、ディジタル・コンテンツ、ハードウェア、ソフトウェア・プログラム、メモリ空間、商品、サービス（ウェブ・サービスを含む）、時間、料金、使用権、またはライセンスとなり得る。
【００１３】
使用権は、使用の方法を指定する。たとえば、使用の方法は、或るアイテムを、指定された方法で指定された期間、使用する能力を含む場合がある。更に、使用権は、譲渡権、たとえば頒布権を指定可能であり、他人への使用権の付与または使用権の派生を許可できる。好ましい実施形態において、条件および権利は、リソースの使用の方法を定義するために関連づけられる。したがって、条件および権利は、好ましい実施形態では単一の実体を意味する。しかし、条件および権利は別々に存在できる。
【００１４】
好ましい実施形態は、保護されたリソースの使用または消費の前、間、および後で、権利の条件を確認および認証有効化とする。権利、および関連づけられた条件は、状態として表され、各々の権利の現在の状態および履歴は、ログされて、後で使用可能である。「状態変数」は、可能的にダイナミックな条件を追跡する。状態変数は、リソースのステータスまたは他のダイナミックな条件を表す値を有する変数である。状態変数は追跡可能であり、状態変数の値は条件の中で使用可能である。たとえば、使用権は、リソースとして、コンテンツを閲覧する権利となり得、条件は、使用権が行使されるとき他のユーザがネットワークへログインされないようにできる。この例では、適切な状態の値が、他のユーザがログインされていることを示すとき、条件は、もはや満足されず、コンテンツを閲覧不可能か、閲覧が終了する。
【００１５】
図１は、好ましい実施形態のコンピュータ・アーキテクチャ１０を示す。条件８０は、後で詳細に説明され、アイテムの頒布者、コンテンツ・サービス・プロバイダ、企業マネージャ、またはリソース、たとえばディジタル・コンテンツへのアクセスを制御したいと望む他の当事者に関連づけられた作成アプリケーション７０で、準備できる。条件８０を指定するためには、文法、たとえばＸｒＭＬ（商標）を使用可能である。しかし、条件８０は、任意の方法で指定可能である。ユーザは、コンピュータまたはユーザに関連づけられた他のデバイスを含むクライアント環境３０内でオペレーションを行う。ソフトウェア・アプリケーション１２、たとえばレンダリング・エンジンまたは他のアプリケーションを、クライアント環境３０へインストールできる。状態マネージャ４０は、以下で説明するように、保護されたリソース１００および派生リソース１００ａへのアクセスを制御する。
【００１６】
好ましい実施形態ではコンピュータデバイスである状態マネージャ４０は、リソース１００および派生リソース１００ａへのアクセスのセキュリティ面を処理する。具体的には、状態マネージャ４０は、署名、たとえば暗号署名、またはメッセージの他の識別特性を、公知の方法で確認および認証有効化することによって、メッセージを認証可能である。状態マネージャ４０は、リソース・マネージャ４２および条件確認器（バリデター）４４を含む。リソース・マネージャ４２は、リソースの登録、リソースの変換、およびリソースの終了に責任を有する。「変換」とは、リソース１００から派生リソース１００ａを派生することを意味する。図７で示されるように、変換は、リソース・マネージャ４２のリソース変換モジュール４８によって達成される。たとえば、リソースが、画像などを表す暗号化ファイルである場合、派生リソース１００ａは、平文画像自身およびその画像を保持するメモリのアドレスを含むことができる。リソースの登録の間、画像を保持するメモリ・アドレスは、リソース・マネージャ４２のリソース・リポジトリ４６によって記録され、そのメモリ、すなわち派生リソース１００ａへのアクセスは、追跡可能である。更に、追跡マーク（たとえば透かし模様）が画像へ挿入され、いつでも追跡可能である。
【００１７】
条件バリデター４４は、設定条件をモニタし、「権利状態」、即ち、以下で説明するように、所与の権利について状態変数の現在値の集合を管理する。条件バリデター４４は、以下で詳細に説明するように、リソース・マネージャ４６と交信し、派生リソース１００ａを制御する。現在の権利状態４４ｂが、もはや有効ではないとき、即ち、許可された権利状態４４ａに対応しないとき、条件バリデター４４は、以下で詳細に説明するように、全ての派生リソース１００ａを削除する（使用不能にする）か、派生リソース１００ａの使用が、もはや許されないことをアプリケーション１２に通知するようにリソース・マネージャ４２に要求する。更に、状態マネージャ４０は、権利状態フレームワーク２０、状態コントローラ２２、および状態バリデター２４を含む。これらの全ては、以下で詳細に説明する。
【００１８】
保護されたリソース１００へのアクセスは、条件８０に基づく。このタイプの条件は、アクセス条件または「事前条件」と呼ばれる。しかし、条件をリソース１００、およびリソース１００の状態の双方に関連づけることによって、リソース１００のライフサイクルの様々な段階で、リソース１００を保護することが可能になる。リソース１００は、ユーザがアクセスを付与される前、アクセスが付与される時、リソース１００の実際の使用の間、およびリソース１００の使用の後で、保護可能である。保護されたリソースの全体のライフサイクルに関連づけられる条件８０は、言語、たとえばＸｒＭＬ（商標）、データ構造、規則のセットを含む文法を使用することによって、表現可能である。好ましい実施形態は、条件を表すため言語としてのＸｒＭＬ（商標）を使用する。
【００１９】
リソース１００を保護するため、リソース１００それ自身、または有形であれ無形であれ他のリソースへ条件８０を課すことができる。それらのリソースは、保護されたリソース１００がアクセスおよび使用される実行環境を作り上げているリソース、たとえばクライアント環境３０のアプリケーション１２を含む。
【００２０】
条件８０は、本人としてアクセスを付与され、保護されたリソース１００を使用するユーザまたはユーザ・グループのアイデンティティとなり得る。条件８０の例は、ＸｒＭＬ（商標）言語の表現として以下で説明される。例Ａは、保護されたディジタル・コンテンツ「ＸｒＭＬブック」を「閲覧」する権利を付与された本人「エドガー」に関連づけられた条件を表す。例Ｂは、本人のグループ、即ち、保護されたディジタル作品「ＸｒＭＬブック」を印刷する権利を付与されたカテゴリ「コンテンツガード従業員」に入る全ての人に関連づけられた条件を表す。
例Ａ：
＜ライセンス＞
＜インベントリ＞
＜ディジタル作品  ライセンス部分ＩＤ＝"ＸｒＭＬブック"／＞
＜キーホルダ  ライセンス部分ＩＤ＝"エドガー"／＞
＜／インベントリ＞
＜付与＞
＜キーホルダ  ライセンス部分ＤＲｅｆ＝"エドガー"／＞
＜閲覧／＞
＜ディジタル作品  ライセンス部分ＩＤＲｅｆ＝"ＸｒＭＬブック"／＞
＜／付与＞
＜／ライセンス＞
例Ｂ：
＜ライセンス＞
＜インベントリ＞
＜ディジタル作品  ライセンス部分ＩＤ＝"ＸｒＭＬブック"／＞
＜／インベントリ＞
＜付与＞
＜ｆｏｒＡｌｌ  ｖａｒＮａｍｅ＝"コンテンツガード従業員"／＞
＜本人  ｖａｒＲｅｆ＝"コンテンツガード従業員"／＞
＜印刷／＞
＜ディジタル作品  ライセンス部分ＩＤＲｅｆ＝"ＸｒＭＬブック"／＞
＜／付与＞
＜／ライセンス＞
【００２１】
条件８０は、或る特性、たとえば或る資格、または権利、たとえばセキュリティ許容度を所有していなければならない本人の条件となり得る。例Ｃは、本人が管理者のバッジを所有していなければならない条件を表す。
例Ｃ：
＜ライセンス＞
＜インベントリ＞
＜ディジタル作品  ライセンス部分ＩＤ＝"ＸｒＭＬブック"／＞
＜キーホルダ  ライセンス部分ＩＤ＝"エドガー"／＞
＜／インベントリ＞
＜付与＞
＜ｆｏｒＡｌｌ  ｖａｒＮａｍｅ＝"誰でも"／＞
＜本人  ｖａｒＲｅｆ＝"誰でも"／＞
＜所有特性／＞
＜バッジ＞
＜資格＞管理者＜／資格＞
＜／バッジ＞
＜閲覧／＞
＜ディジタル作品  ライセンス部分ＩＤＲｅｆ＝"ＸｒＭＬブック"／＞
＜／付与＞
＜／ライセンス＞
【００２２】
条件８０は、保護されたアイテムへアクセスする時間間隔の条件となり得る。下記の例Ｄは、本人としての鍵保持者「エドガー」が、２００２年５月２９日の前、および２００３年５月２９日の後では、コンテンツ「ＸｒＭＬブック」を閲覧できない条件を表す。
例Ｄ：
＜ライセンス＞
＜インベントリ＞
＜ディジタル作品  ライセンス部分ＩＤ＝"ＸｒＭＬブック"／＞
＜キーホルダ  ライセンス部分ＩＤ＝"エドガー"／＞
＜／インベントリ＞
＜付与＞
＜キーホルダ  ライセンス部分ＩＤＲｅｆ＝"エドガー"／＞
＜閲覧／＞
＜ディジタル作品  ライセンス部分ＩＤＲｅｆ＝"ＸｒＭＬブック"／＞
＜有効期間＞
＜前でない＞２００２−０５−２９Ｔ００：００：００＜／前でない＞
＜後でない＞２００３−０５−２９Ｔ００：００：００＜／後でない＞
＜／有効期間＞
＜／付与＞
＜／ライセンス＞
【００２３】
条件８０は、本人の物理的ロケーションまたはコンテンツにアクセスするために使用されるリソースに関連し得る。下記の例Ｅは、現在米国にいる人は、誰でもコンテンツ「ＸｒＭＬブック」を印刷できる条件を表す。
例Ｅ：
＜ライセンス＞
＜インベントリ＞
＜ディジタル作品  ライセンス部分ＩＤ＝"ＸｒＭＬブック"／＞
＜／インベントリ＞
＜付与＞
＜ｆｏｒＡｌｌ  ｖａｒＮａｍｅ＝"誰でも"／＞
＜本人  ｖａｒＲｅｆ＝"誰でも"／＞
＜印刷／＞
＜ディジタル作品  ライセンス部分Ｉｄ＝"ＸｒＭＬブック"／＞
＜地域＞
＜国＞米国＜／国＞
＜／地域＞
＜／付与＞
＜／ライセンス＞
【００２４】
条件８０は、本人がアクセスに対して支払わなければならない料金を指定可能である。下記の例Ｆは、３．１０ドルの料金を支払えば、誰でもコンテンツ「ＸｒＭＬブック」を印刷できる条件を表す。下記の例Ｇは、各々の印刷について３．１０ドルの料金を支払えば、誰でもコンテンツ「ＸｒＭＬブック」を印刷できる条件を表す。下記の例Ｈは、１時間の閲覧時間ごとに１０．００ドルを支払えば、誰でもコンテンツ「ＸｒＭＬブック」を閲覧できる条件を表す。
例Ｆ：
＜ライセンス＞
＜インベントリ＞
＜ディジタル作品  ライセンス部分ＩＤ＝"ＸｒＭＬブック"／＞
＜／インベントリ＞
＜付与＞
＜ｆｏｒＡｌｌ  ｖａｒＮａｍｅ＝"誰でも"／＞
＜本人  ｖａｒＲｅｆ＝"誰でも"／＞
＜印刷／＞
＜ディジタル作品  ライセンス部分Ｉｄ＝"ＸｒＭＬブック"／＞
＜料金＞
＜一律支払い＞
＜レート通貨＝"米国ドル"＞３．１０＜／レート＞
＜／一律支払い＞
＜ｔｏ＞
＜ａｂａ＞
＜金融機関＞１２３４５６７８９＜／金融機関＞
＜アカウント＞９８７６５４３２１＜／アカウント＞
＜／ａｂａ＞
＜／ｔｏ＞
＜／料金＞
＜／付与＞
＜／ライセンス＞
例Ｇ：
＜ライセンス＞
＜インベントリ＞
＜ディジタル作品  ライセンス部分ＩＤ＝"ＸｒＭＬブック"／＞
＜／インベントリ＞
＜付与＞
＜ｆｏｒＡｌｌ  ｖａｒＮａｍｅ＝"誰でも"／＞
＜本人  ｖａｒＲｅｆ＝"誰でも"／＞
＜印刷／＞
＜ディジタル作品  ライセンス部分ＩＤＲｅｆ＝"ＸｒＭＬブック"／＞
＜料金＞
＜使用当たりの支払い＞
＜レート通貨＝"米国ドル"＞３．１０＜／レート＞
＜／使用当たりの支払い＞
＜／料金＞
＜／付与＞
＜／ライセンス＞
例Ｈ：
＜ライセンス＞
＜インベントリ＞
＜ディジタル作品  ライセンス部分ＩＤ＝"ＸｒＭＬブック"／＞
＜／インベントリ＞
＜付与＞
＜ｆｏｒＡｌｌ  ｖａｒＮａｍｅ＝"誰でも"／＞
＜本人  ｖａｒＲｅｆ＝"誰でも"／＞
＜閲覧／＞
＜ディジタル作品  ライセンス部分ＩＤＲｅｆ＝"ＸｒＭＬブック"／＞
＜料金＞
＜時間ベース支払い＞
＜レート通貨＝"米国ドル"＞１０．００＜／レート＞
＜ｐｅｒ＞ＰＴ１Ｈ＜／ｐｅｒ＞
＜フェーズ＞ＰＴ１０Ｍ＜／フェーズ＞
＜／時間ベース支払い＞
＜ｔｏ＞
＜ａｂａ＞
＜金融機関＞１２３４５６７８９＜／金融機関＞
＜アカウント＞９８７６５４３２１＜／アカウント＞
＜／ａｂａ＞
＜／ｔｏ＞
＜／料金＞
＜／付与＞
＜／ライセンス＞
【００２５】
下記の例Ｉは、誰でもコンテンツを印刷できるが、印刷の前に、印刷権の行使が追跡サービスによって追跡される条件を表す。
例Ｉ：
＜ライセンス＞
＜インベントリ＞
＜ディジタル作品  ライセンス部分ＩＤ＝"ＸｒＭＬブック"／＞
＜キーホルダ  ライセンス部分ＩＤ＝"エドガー"／＞
＜／インベントリ＞
＜付与＞
＜ｆｏｒＡｌｌ  ｖａｒＮａｍｅ＝"誰でも"／＞
＜本人  ｖａｒＲｅｆ＝"誰でも"／＞
＜印刷／＞
＜ディジタル作品  ライセンス部分ＩＤＲｅｆ＝"ＸｒＭＬブック"／＞
＜追跡レポート＞
＜状態リファレンス＞
＜ｕｄｄｉ＞
＜サービスキー＞
＜ｕｕｉｄ＞．．．＜／ｕｕｉｄ＞
＜／サービスキー＞
＜／ｕｄｄｉ＞
＜サービス・パラメータ＞
＜／サービス・パラメータ＞
＜／状態リファレンス＞
＜／追跡レポート＞
＜／付与＞
＜／ライセンス＞
【００２６】
更に、条件８０は、リソース１００が消費されるシステムの条件となり得る。たとえば、条件８０は、システムが、許可されたセキュリティ・メカニズムまたは他の特定のハードウェアまたはソフトウェアを有するか、特定最大数のユーザだけがログオンされることを要求可能である。
【００２７】
条件８０は、リソース１００、たとえばコンテンツが存在するリポジトリまたは他のデバイスを指定可能である。更に、条件８０は、本人が、保護されたリソース１００を使用する前に獲得しなければならない承認表示に関連し得る。条件８０は、リソース１００の使用前または使用後に通知を要求できる。条件８０は、保護されたリソース１００または他のリソースに関連した以前の権利を指定可能である。更に、条件８０は、他の条件８０、たとえば条件の確認方法に課されることができる。
【００２８】
もちろん、条件８０は、上記の例に限定されず、事前条件、アクセス中の条件、事後条件、または他の条件として、保護されたリソース１００に対する権利に関連づけられる任意の制限、義務、または要件となり得る。更に、上記の例はＸｒＭＬ（商標）を使用して表されたが、条件はＸｒＭＬに限定されず、任意の方法で表される。
【００２９】
図４は概略的に、好ましい実施形態に従った条件８０を示す。条件８０は、暗黙的または明示的に表されるリソース表示８２を含む。たとえば、前記の例Ａにおいて、リソース表示８２は、「ディジタル作品」要素の属性「ライセンス部分ＩＤ」によって示される。更に、条件８０は、状態変数８４、および状態変数８４の値がどのようにして得られるかを示すメソッド指定８６を含む。メソッド指定８６は、状態変数８４の値が記憶されているロケーション（たとえば、以下で説明するように条件を管理する遠隔状態コントローラ）、条件が管理される状態コントローラと通信するための通信プロトコル、および値を獲得するために必要なパラメータ（たとえばサービス・パラメータなど）を含むことができる。代替的に、メソッドはシステムの中でハードコードされることができ、メソッド指定８６は省略可能である。
【００３０】
前述したように、状態変数８４は、条件８０のステータスを表す。各々の状態変数４４は、本人、権利、およびリソースについて任意の時点の対応値を有する。前述したように、所与の権利に対する状態変数の現在値の集合は、ここでは「権利状態」と呼ばれる。図５は、条件８０、および条件８０の状態変数８４の現在値５２を含む好ましい実施形態の権利状態５０を示す。メソッド指定５６は、状態変数８４の現在値５２を得るために使用されるメソッドを示し、可能性として、その現在値が得られるソース、信任状のディジタル署名、リクエストのセッションＩＤ、および他の適切な情報を含む。注意すべきは、メソッド指定５６は、メソッド指定８６に対して冗長であると考えられ、単にその繰り返しであり得る。しかし、幾つかの場合には、値５２を実際に獲得するために使用されるメソッド指定５６は、条件８０で使用されることを暗示されるメソッド指定８６とは異なる場合がある。
【００３１】
権利について条件８０を表すため権利状態５０を使用することは、条件８０を確認するプロセスを簡単にする。なぜなら、条件８０を確認するために必要な全ての情報を、容易にアクセスできるからである。権利状態５０は、対応する条件８０が評価および確認されるとき、常に構成されて使用される。各々の権利状態５０は、状態変数８４の値５２を確認するために必要な全ての情報を含むことができる。
【００３２】
認証された本人は、システムによって処理されたユーザである。システムはそのユーザの真正性を確認し、たとえば、ユーザがユーザ名およびパスワードを使用して成功裏にログインしたとき、そのユーザは、認証された本人または正に「本人」になる。権利の所与のセットに対する条件８０は、本人が、保護されたリソース１００にアクセスすることを許される必要状態変数値のセットとして定義される。認証された本人が、保護されたリソース１００のアクセスを望むとき、システムの状態は、「オリジナル状態」から「許可状態」へ変化する。
【００３３】
一度、システムが許可状態に置かれると、本人は、許可されたオペレーションについて、保護されたリソース１００にアクセス可能である。多くの場合、保護されたリソース１００へ実際にアクセスするのは、認証された本人自身ではない。たとえば、アクセスは他の認証された本人、たとえばレンダリング・アプリケーション、サービスなどへ委任可能である。保護されたリソース１００がアクセスおよび消費される間、最初のアクセスを付与する事前条件８０のセットは、もはや継続アクセスを許可するために適用できないことがある。更に、保護されたリソース１００の消費は、リソースを一時的、即ち、派生されたリソース１００ａのセットへ変換し、オリジナル・リソースの上に課されたアクセス条件８０も、それから適用することはできない。リソース１００およびその派生リソース１００ａを、アクセスされている間に保護するため、好ましい実施形態は、以下で詳細に説明する「アクセス中条件」と呼ばれる許可および保護概念を使用する。
【００３４】
従来のシステムにおいて、リソースは２つの状態の１つにある。図２で示されるように、リソース１００がアクティブでないとき、システムは、事前条件が満足されるまで、オリジナル状態１０２にある。事前条件が満足された時点で、リソース１００はアクティブになり、システムは、許可またはアクティブ状態１０４へ入る。リソースの制御を増進するため、好ましい実施形態は、「オリジナル状態」および「許可状態」に加えて、２つの追加状態を定義する。図３で示されるように、保護されたリソース１００の使用またはアクセスの間に、システム状態は、次の状態を経て変化する。即ち、オリジナル状態１０２、許可状態１０４、使用状態１０６、および終了状態１０８である。各々の状態について、次の状態へ移行するか、同じ状態の中で継続するため、満足されなければならない条件８０を定義可能である。図１に関して説明したように、条件８０は、必要なユーザ・インタフェースおよび編集能力を含む作成アプリケーション７０を使用して定義および準備できる。許可状態へ入るために満足されなければならない条件８０は「事前条件」と呼ばれる。リソース１００の使用中に満足されなければならない条件８０は「アクセス中条件」と呼ばれ、使用の終了時に必要な条件８０は「事後条件」と呼ばれる。条件バリデター４４は、各々の状態に必要な条件８０を呼び出すことができる。
【００３５】
アクセス中条件は、オリジナル・リソース１００および派生リソース１００ａが、認証された本人によってアクセスおよび消費されている間、オリジナル・リソース１００から、それ自身および派生リソース１００ａへ転移する。たとえば、もしリソース１００が、許可されたオペレーション「閲覧」の間にクライアント環境３０のスクリーン上に表示される文書であれば、派生リソース１００ａは、文書からのデータを含むメモリ、文書のプレゼンテーション・フォーマット、および表示されたウィンドウを含むことができる。派生リソース１００ａの全ては、アクセス中条件のセットによって保護されるであろう。言い換えれば、本人は、アクセス中条件が満足される限りでのみ、派生リソース１００ａへのアクセスを有する。アクセス中条件は、他の条件８０と同じように定義が可能である。
【００３６】
他の例は、アプリケーション、たとえばアプリケーション１２が、保護されたリソース１００であるサービスをリクエストする場合である。一度、リクエストが許可されると、そのサービスを実行するアプリケーションは派生リソースとして考えられ、サービスが実行されている間、アクセス中条件のセットに従う。アクセス中条件は、以下で詳細に説明するように現在の権利状態４４ｂへ適用される許可された権利状態４４ａを定義する。一度、リクエストされたオペレーションが強制的または任意的に終了すると、アクセス中条件によって保護された全ての派生リソース１００ａは削除（または使用不能に）され、システム状態は事後アクセス条件のセットによって最終状態へ移行する。
【００３７】
リソースの使用またはアクセスの後または間の条件８０は、変化してもよいし変化しなくてもよい。状態が変化しない条件は、「ステートレス（ｓｔａｔｅｌｅｓｓ）条件」と呼ばれ、リソースの使用の後または間に変化する条件は、「ステートフル（ｓｔａｔｅｆｕｌ）条件」と呼ばれる。事前条件８０は、通常、ステートレス条件８０であり、保護された文書へのアクセスを制御するために使用される。アクセス中条件および事後条件は、通常、ステートフル条件８０である。それらは、保護されたリソース１００のライフタイムを制御するために使用される。（たとえば、保護されたリソース１００は、一度ネットワークへログインしたユーザの数が特定の数を超過すると、もはやアクセスされることはできない。）保護されたリソース１００の異なった段階に関連づけられた条件８０のこれらの拡張タイプを使用することによって、好ましい実施形態は、保護されたリソース１００の使用を許可し、リソース１００が使用されている間にリソース１００を保護および追跡するメカニズムを提供する。
【００３８】
図３に示されるように、また図１を参照すると、好ましい実施形態に従ったシステムは、３つの段階を経て進行する。アクセス許可段階３０２は、状態マネージャ４０が、事前条件が満足されたことを確認することによって、許可されたオペレーションについて、保護されたリソース１００のアクセスを、認証された本人に許可する段階である。リソース保護段階３０４は、状態マネージャ４０が、アクセス中条件が満足されたままであることを確認することによって、リソース１００および派生リソース１００ａが使用されている間、それらのリソースを保護する段階である。オペレーション終了段階３０６は、事後アクセス条件が満足されるか、アクセス中条件が満足されるのを終了したとき、状態マネージャ４０が、所与のオペレーションについて、保護されたリソース１００および派生リソース１００ａの使用を終了する段階である。
【００３９】
同じリソース１００に対して多数のアクセスが与えられる再帰的な状況では、事後条件は、次のサイクルの事前条件と同じである場合がある。そのような場合、無限ループの状況を防止するため、非静止パラメータを使用可能である。たとえば、時間依存条件、または外部実体、たとえば人間の介在によって修正または強制される条件である。
【００４０】
アクセス許可は、許可されたオペレーションについて、保護されたリソース１００にアクセスする権利を、認証された本人に付与する。事前条件は、権利状態に対して評価、即ち、実施される。もし実施が成功すれば、リソース１００および派生リソース１００ａは、ステップ４０６で許可状態へ入り、アクセス中条件が実施を開始される。
【００４１】
前述したように、リソースの保護は、アクセス中条件のセットを実施することによって、最初の保護されたリソース１００および派生リソース１００ａの双方を保護する。アクセス許可状態から返された許可状態は、許可されたオペレーションの間に実施されるべきアクセス中条件のリストを含む。強制システムでは、全ての派生リソース１００ａは、それが生成および使用されるとき、リソース・マネージャ４２のリソース・リポジトリ４６（図７および以下の説明を参照）を使用して登録可能である。もしアクセス中条件が無効になれば、リソース・マネージャ４２は、アプリケーション１２によって、保護されたリソース１００および派生リソース１００ａへのアクセスを不能にする。
【００４２】
許可されたオペレーションの終了は、事後条件のセット（もし存在すれば）を実行する。事後条件の実行は、権利状態を永続的に変更可能であり、リソース１００への次のアクセス・リクエストに影響を与える。たとえば、もし事後条件が、行使限度に達した後のリソース１００へのアクセスの除去であれば、限度に到達したとき、リソース１００は削除されるか、アクセスを不能にするか禁止する他のアクションが取られる。オペレーションの終了は、リソースの終了を含むことができる。オペレーションが終了されつつあるとき、そのオペレーションが終了を強制されているか、またはアプリケーションが任意的にオペレーションを終了しているか否かを問わず、リソース・マネージャ４２は、派生リソース１００ａを削除（使用不能に）可能である。派生リソース１００ａの削除（または使用不能）は、リソース１００の保護プロセスで重要である。条件バリデター４４は、保護されたリソース１００の使用をコミット、制約し、事後条件のセットを実施する。条件バリデター４４は、もしリソース１００が、システム状態の変化の結果として無効になれば、保護されたリソース１００を無効（使用不能）にする。
【００４３】
権利状態は、リソース１００の使用の間に変化し、したがって権利状態を維持、更新、および検索する必要があることが分かる。前述したように、条件バリデター４４は、現在の権利状態４４ｂにアクセスし、権利に関連づけられた条件８０を認証有効化する。リソース１００が使用またはアクセスされている間、条件バリデター４４は、アクセス中条件のセットをモニタし、現在の権利状態４４ｂを管理する。条件バリデター４４は、リソース・マネージャ４２と交信し、派生リソース１００ａを制御する。現在の権利状態がもはや有効でないとき、即ち、もはやアクセス中条件を満足させないとき、アクセス中条件バリデター４４は、全ての派生リソース１００ａを削除（または使用不能に）するか、派生リソース１００ａの使用がもはや許されないことをアプリケーション１２へ通知するようにリソース・マネージャ４２へリクエストする。条件８０を表すために権利状態を使用することは、条件８０の確認プロセスを簡単にする。なぜなら、特定の条件８０を確認するために必要な情報の全てを容易に得ることができるからである。
【００４４】
図１および図６で示されるように、状態マネージャ４０は、更に、権利状態フレームワーク２０を含む。権利状態フレームワーク２０は、ＡＰＩを条件バリデター４４へ提供し、またプラグイン・インフラストラクチャを状態コントローラ２２および状態バリデター２４へ提供する。フレームワーク２０は、複数の状態コントローラ２２およびバリデター２４の間でタスクの協調及び通信を処理する。
【００４５】
各々の状態コントローラ２２は、所与の状態変数の状態を管理、即ち、その値を追跡するコンポーネントである。状態コントローラ２２の基本構造は、権利状態フレームワーク２０によって定義されたＡＰＩを処理するソフトウェア・コンポーネントから構成される。このソフトウェア・コンポーネントは、持続性記憶またはサービスと交信して、状態変数の現在値および状態変数の履歴を記憶、更新、および質問するプロトコルによる。したがって、状態変数を管理する持続性記憶またはサービスのロケーションは、権利状態フレームワーク２０に対して明らかである。
【００４６】
各々の状態バリデター２４は、状態変数の値を確認するコンポーネントである。各々の状態バリデター２４は、権利フレームワーク２０の状態認証有効化およびモニタリングＡＰＩ２０ｃによって定義されたインタフェースのセットを実現するソフトウェア・コンポーネントを含む。状態コントローラ２２と同じように、状態バリデター２４は、ローカルまたはリモートで動作可能である。
【００４７】
図６で示されるように、権利状態フレームワーク２０は、権利状態の値を初期化、質問、更新、および転移するインタフェースのセットである状態操作ＡＰＩ２０ｂを含む。前述したように、条件８０の基本構造は、状態変数、および状態変数の現在値を獲得するために必要なメソッドを含む。
【００４８】
状態変数と同じように、値は、文法、たとえば現在値を記述するデータ構造またはＸｒＭＬ（商標）権利言語によって表されることができる。好ましい実施形態は、ＸｒＭＬ（商標）を使用して、状態変数およびその拡張を定義し、状態変数の値を定義する。しかし、状態変数およびその値の表現は、ＸｒＭＬ（商標）に限定されない。次の例は、ＸｒＭＬ（商標）を使用して、どのように状態変数を定義できるかを示す。
例５：
＜印刷／＞
＜ｓｘ：状態リファレンス＞
＜ｕｄｄｉ＞
＜サービスキー＞
＜ｕｕｉｄ＞１Ｆ８９０３ＢＯ−ＦＣ０３−４ｃ５ｂ−Ａ４４５−
ＡＡＦＣＣＥＣ０１１１１１＜／ｕｕｉｄ＞
＜／サービスキー＞
＜／ｕｄｄｉ＞
＜／ｓｘ：状態リファレンス＞
＜ｓｘ：行使限度＞９＜／ｓｘ：行使限度
【００４９】
上記の例は、印刷されるリソースのコピーが９つを超えることを許さない印刷権の状態変数を記述する。状態に関連づけられた値は、行使限度の例と同じように簡単な数値にするか、承認を必要とする例のようにブール値「イエス」または「ノー」となり得る。更に、値は、下記の例Ｋで示されるように、サービスまたはコンポーネントによって記憶および管理が可能である。
例Ｋ：
＜再生／＞
＜有効期間浮動＞
＜ｓｘ：状態リファレンス＞
＜ｕｄｄｉ＞
＜サービスキー＞
＜ｕｕｉｄ＞１Ｆ８９０３Ｂ０−ＦＣ０３−４ｃ５ｂ−Ａ４４５−
ＡＡＦＣＣＥＣ０１１１１１＜／ｕｕｉｄ＞
＜／サービスキー＞
＜／ｕｄｄｉ＞
＜／ｓｘ：状態リファレンス＞
＜／有効期間浮動＞
【００５０】
例Ｋは、「再生」権の浮動期間に関連づけられた状態を示す。この例では、状態変数は、条件に関連づけられた実際の値を含まない。むしろ、状態コントローラ２２として働く遠隔サービス（状態リファレンス）が値を管理する。それは、状態変数の表現では「不透明」である。
【００５１】
状態操作ＡＰＩ２０ｂは、状態変数の値を質問する質問（クエリー）・インタフェースを含む。状態変数値のクエリーは、質問される状態変数、およびレスポンスの値のタイプを含む入力を必要とする。状態クエリーのレスポンス値は、状態値、状態履歴、またはこれらの双方となり得る。
【００５２】
次の例Ｌでは、状態変数「行使限度」の値が、「印刷」権に関連づけられる。
例Ｌ：
＜状態クエリー＞
＜！  印刷権の状態または行使限度条件＞
＜印刷／＞
＜ｓｘ：状態リファレンス＞
＜ｕｄｄｉ＞
＜サービスキー＞
＜ｕｕｉｄ＞１Ｆ８９０３Ｂ０−ＦＣ０３−４ｃ５ｂ−Ａ４４５−
ＡＡＦＣＣＥＣ０１１１１１＜／ｕｕｉｄ＞
＜／サービスキー＞
＜／ｕｄｄｉ＞
＜／ｓｘ：状態リファレンス＞
＜ｓｘ：行使限度／＞
＜！特定のレスポンス・タイプのリクエスト＞
＜レスポンス・タイプ＝"値"＞
＜／状態クエリー＞
【００５３】
クエリーを処理するため、権利状態フレームワーク２０は、どの状態コントローラ２２がこのリクエストに責任を有するかを決定し、その特定の状態コントローラ２２を位置決め、認証、およびロードし、そのリクエストを処理のために状態コントローラ２２へ渡す。状態コントローラ２２は、ローカルまたはリモートとなり得る。一度、リクエストが処理されると、権利状態フレームワーク２０を介してレスポンスがリクエスト発信者へ返却される。次の例Ｍは、レスポンスを記述する。
例Ｍ：
＜状態レスポンス＞
＜！次のクエリー・リクエストへのレスポンス＞
＜状態クエリー＞
＜印刷／＞
＜ｓｘ：状態リファレンス＞
＜ｕｄｄｉ＞
＜サービスキー＞
＜ｕｕｉｄ＞１Ｆ８９０３Ｂ０−ＦＣ０３−４ｃ５ｂ−Ａ４４５−
ＡＡＦＣＣＥＣ０１１１１１＜／ｕｕｉｄ＞
＜／サービスキー＞
＜／ｕｄｄｉ＞
＜／ｓｘ：状態リファレンス＞
＜ｓｘ：行使限度＞９＜／ｓｘ：行使限度＞
＜／状態クエリー＞
＜！状態クエリーから返却された状態値＞
＜／状態値＞８＜／状態値＞
＜！信任状のディジタル署名＞
＜ｄｓｉｇ：署名＞
．．．
＜／ｄｓｉｇ：署名＞
＜／状態レスポンス＞
【００５４】
クエリー・レスポンスは、元のクエリー、もし該当すれば、質問された状態変数の現在値、状態変数の現在のステータスまたは状態履歴、識別子、セッションＩＤ、およびレスポンスのディジタル署名を含む。ディジタル署名は、レスポンスの完全性を保証するために使用可能である。
【００５５】
状態は、もし状態クエリー・レスポンス内の「セッションＩＤ」が有効であれば、状態クエリーの前のレスポンスに基づいてのみ更新可能である。セッションＩＤは、好ましい実施形態でリクエストを識別するために使用されるが、クエリーと更新をマッチさせるため、任意の他の識別子を使用可能である。したがって、状態マネージャ４０は、状態変数の現在値を質問して状態変数値および有効なセッションＩＤを獲得し、ターゲットの状態変数を更新しなければならない。状態変数値の更新は、状態変数の現在値を新しい値へ変更するであろう。
【００５６】
状態変数値の更新には、多くの制約を課すことができる。たとえば、状態変数に関連づけられた権利は、更新リクエストの前に有効でなければならない。他の制約は、更新の後の状態変数の新しい値が、状態変数に許された有効値でなければならないことである。たとえば、もし最大印刷コピーが４であり（状態変数）、現在の印刷コピーが３であれば（状態変数の現在値）、あと２つのコピーのリクエスト（更新値）は拒絶されるであろう。なぜなら、更新後の状態変数の値は、許された値ではないからである。更に、更新をリクエストしている本人またはアプリケーションは、それを許可されていなければならない。権利状態フレームワーク２０は、状態コントローラ２２を識別、認証、およびロードして、更新リクエストを処理する。下記の例Ｍは、状態値を更新するリクエストの例である。
例Ｍ：
＜状態更新＞
＜！以前のクエリー値の更新。もしクエリーが状態変数の現在値と＞
＜！マッチしなければ、更新リクエストは失敗する＞
＜状態クエリー＞
＜ｓｘ：状態リファレンス＞
＜ｕｄｄｉ＞
＜サービスキー＞
＜ｕｕｉｄ＞１Ｆ８９０３Ｂ０−ＦＣ０３−４ｃ５ｂ−Ａ４４５−
ＡＡＦＣＣＥＣ０１１１１１＜／ｕｕｉｄ＞
＜／サービスキー＞
＜／ｕｄｄｉ＞
＜／ｓｘ：状態リファレンス＞
＜ｓｘ：より多くない＞９＜／ｓｘ：より多くない＞
＜！セッションＩＤは、更新されたリクエストおよび以前のクエリーとマッチするように＞
＜処理系によって特定される。代わりに、他の識別スキームを使用可能である＞
＜セッションＩＤ＞．．．＜／セッションＩＤ＞
＜状態コントローラ＞
＜ｉｄ＞．．．＜／ｉｄ＞
＜／状態コントローラ＞
＜状態値＞８＜／状態値＞
＜ｄｓｉｇ：署名＞
．．．
＜／ｄｓｉｇ：署名＞
＜／状態クエリー＞
＜更新値＞１＜／更新値＞
＜／状態更新＞
【００５７】
状態値の転移は、状態管理に関して状態値の更新と類似している。２つの間の主な相違は、状態変数の状態履歴が、どのようにして維持されるかの点である。一度、状態が転移すると、状態変数の現在値およびその履歴は、転移に従って更新される。もし状態を転移された権利が、状態転移の結果として満了すれば、転移は完全転移と呼ばれ、そうでなければ、部分転移と呼ばれる。状態値の転移は、状態値の更新と同じ制約を有し得る。状態値の転移に伴うエレメントは、転移が起こる前に許可されることができる。
【００５８】
状態マネージャ４０は、更に、状態バリデター２４のセットを管理し、各々の状態変数を個別的に確認するか、権利状態を表すセットとして確認するアプリケーションへ、インタフェースのセットを提供する。権利状態は、所与の権利に関連づけられた状態変数の現在値の集合であることを想起されたい。権利状態フレームワーク２０は、状態変数の各々のために、適切な状態バリデター２４を選択およびロードする。一度、状態バリデター２４が選択およびロードされると、権利状態フレームワーク２０は、ターゲットの状態バリデター２４へリクエストを渡し、レスポンス・メッセージとしての結果を待つ。状態マネージャ４０は、状態変数とシステム構成との間の依存性に依存して、全ての状態バリデター２４を一度だけ同時に実行するか、逐次に実行可能である。
【００５９】
状態バリデター２４は、状態クエリー・レスポンスを与えられた状態変数値を確認する。状態変数の発効リクエストを受け取ると、権利状態フレームワーク２０は、状態クエリー・レスポンスを検査し、適切な状態バリデター２４を選択、認証、およびロードし、状態クエリー・レスポンスを状態バリデター２４へ渡す。構成可能なポリシーおよび状態クエリーに記憶された情報に基づいて、状態バリデター２４は、状態クエリーおよびレスポンスの双方に記憶された情報を受け入れるか問題にすることができる。一度、状態クエリーおよびレスポンスに記憶された情報が確認されると、確認プロセスは、状態変数の現在値と状態変数の可能な（または許された）値のセットとを比較するだけの簡単なものにすることができる。各々の状態バリデター２４は、権利状態フレームワーク２０によって定義されたインタフェースのセットを実現するソフトウェア・コンポーネントを含むことができる。状態バリデター２４は、ローカルまたはリモートでオペレーション可能である。
【００６０】
好ましい実施形態は、様々なデバイス、たとえばパーソナル・コンピュータ、サーバ、ワークステーション、ＰＤＡ、シンクライアントなどを利用可能である。たとえば、クライアント環境は、ハンドヘルドデバイス、たとえば携帯電話またはＰＤＡとなり得る。様々な通信チャネルを使用可能である。更に、様々な機能を１つのデバイスに集積可能である。開示された機能デバイスおよびモジュールは、明瞭性を目的として機能ごとに区分されている。しかし、様々な機能を、ハードウェアおよび／またはソフトウェア・モジュールおよびデバイスとして、どのようにでも結合または分離可能である。様々な機能モジュールおよびデバイスは、別個または組み合わせた有用性を有する。
【００６１】
様々なレコード、メッセージ、要素、および、それらの部分は、同じデバイスまたは異なったデバイスに記憶可能である。様々なリンク、リファレンス、指定などは、要素を関連づけるために使用可能である。任意のタイプのリソースへのアクセスを制御可能である。状態変数の値を追跡するため、任意のメカニズムを使用可能である。
【００６２】
本発明は、好ましい実施形態および例を使用して説明された。しかし、添付のクレイムおよび法的均等物によって規定される本発明の範囲から逸脱することなく、様々な修正を行うことができる。
【図１】
2012018701.tif 000003
【図２】
2012018701.tif 000004
【図３】
2012018701.tif 000005
【図４】
2012018701.tif 000006
【図５】
2012018701.tif 000007
【図６】
2012018701.tif 000008
【図７】
2012018701.tif 000009
【手続補正書】
【提出日】平成23年10月25日(2011.10.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ユーザがオペレーションを行うクライアント環境に接続され、
前記クライアント環境内での前記ユーザのオペレーションによる保護されたリソースへのアクセスの許可・不許可を、前記保護されたリソースに関連付けられた使用権に基づいて判断するコンピュータデバイスであって、
前記使用権は、前記保護されたリソースの使用の方法を指定するものであって、前記ユーザに対する前記保護されたリソースへのアクセスの許可条件を表す値であって、かつ、前記ユーザによる前記保護されたリソースへのアクセスが実際に付与される時にその値が更新されて変化する変数である状態変数を含み、
前記コンピュータデバイスは、
前記クライアント環境内での前記ユーザのオペレーションによる前記保護されたリソースへのアクセス状況を監視して、前記使用権の前記状態変数の現時点での値を表す現在値を獲得する状態コントローラと、
前記状態コントローラで獲得された前記状態変数の前記現在値と、前記保護されたリソースへのアクセスの前記許可条件との比較に基づいて、前記ユーザによる前記保護されたリソースへのアクセスのアクセス許可、不許可の判断を実行する条件バリスターと、
を含む、こと特徴とする、コンピュータデバイス。