JP4714414B2 - 拡張可能な権利表記処理システム - Google Patents

Description

著作権表示
この特許文書の開示の一部分は、著作権の保護を受ける資料を含む。著作権の所有者は、いかなる人が、特許文書または特許開示を、特許および商標庁の特許ファイルまたはレコードに現れるとおりに複写しようとも異議を有しないが、それ以外の場合は全ての著作権を留保する。

本発明は、権利表記処理システムおよび権利表記を処理する方法に関する。具体的には、本発明は、新しい権利表記の処理を可能にする拡張可能な文法ベースの権利表記システムおよび方法に関する。

コンテンツの所有者が、インターネットを介してコンテンツをディジタル的に配布することは、インターネット・ユーザの潜在的に大きなマーケットへ到達する方法である。しかし、そのようなディジタル配布は、コンテンツの違法配布または許可（認証）されていない配布のリスクを伴っている。権利マネジメントは、このリスクを減らし、コンテンツの所有者が自分のディジタル・コンテンツを保護し、その利益を受けることができるようにする。権利マネジメント・システムは、コンテンツの使用権または他の事項を指定し、使用権を実施するために利用される。「コンテンツ」の用語は、ここでは広く使用され、ディジタル作品、たとえば、音楽、オーディオ・ファイル、テキスト・ファイル、電子書籍（ブック）、レポート、ビデオ、マルチメディア、写真、実行可能コード、またはこれらの組み合わせを含む。

特許文献１、特許文献２、特許文献３、および特許文献４で開示されるように、権利マネジメント・システムの様々な実現形態およびディジタル・コンテンツに関連した権利が知られている。したがって、権利マネジメント・システムの詳細は、ここでは特に説明されない。これらの参照文献から明かであるように、権利マネジメント・システムは、多くの形態を取ることができ、要求されるセキュリティ、管理される事物の性質、関連した権利および条件の複雑性、数量、および他の要因に依存して、様々なレベルの複雑性を有することができる。

図１２は、ディジタル・コンテンツを配布するために使用される例示的な権利マネジメント・システム５００および関連したワークフローを示す。通常、ユーザが認証処理を行うとき、認証サーバ５０２とクライアント・アプリケーション５０６との間で情報が交換され、情報がクライアント・アプリケーション５０６へダウンロードおよびインストールされる。クライアント・アプリケーション５０６は、耐タンパー性セキュリティ・コンポーネントとして働き、認証サーバ５０２によって発行された公開鍵および秘密鍵のセット５０４、および他のコンポーネント、たとえば、保護されたコンテンツ５０８を解析またはレンダリングするために必要なエンジンを含む。

権利マネジメント・システム５００は、更に、コンテンツ準備アプリケーション５０３を含む。コンテンツ準備アプリケーション５０３は、暗号化または他の保護メカニズムによって平文（クリア）コンテンツ５０１を保護し、保護されたコンテンツ５０８を提供する。コンテンツ準備アプリケーション５０３は、更に、保護されたコンテンツ５０８に関連づけられた権利ラベル５１０の中で使用権を指定する。権利ラベル５１０は、対応する条件が満足されたとき、エンドユーザが利用できる使用権を指定する。権利ラベル５１０の中で設定される権利および条件を指定するため、権利表記言語（以後、「ＲＥＬ」と呼ぶ）、たとえばＸｒＭＬ（商標）を使用することができる。次に、権利ラベル５１０、および平文コンテンツ５０１を暗号化するために使用された適切な暗号化キーは、ライセンス・サーバ５１２へ提供される。

ライセンス・サーバ５１２は、暗号化キーを管理し、使用権の行使を許諾するライセンス５１４を発行する。たとえば、権利ラベル５１０は、５ドルの料金を支払うことにより、保護されたコンテンツ５０８を閲覧でき、１０ドルの料金を支払うことにより、保護されたコンテンツ５０８を閲覧または印刷できる使用権を含むことができる。クライアント・アプリケーション５０６は、ライセンス５１４で指定された使用権を解釈および実施し、エンドユーザによって使用される平文コンテンツ５１６を提供する。

権利マネジメント・システム５００のコンポーネントおよびモジュールは、１つまたは複数の装置に置くことができる。たとえば、認証サーバ５０２およびライセンス・サーバ５１２は、同じサーバまたはその他の装置であるか、複数の別個の装置であることができる。保護されたコンテンツ５０８は、文書、画像、オーディオ・ファイル、ビデオ・ファイルなどを含む任意の種類のコンテンツであってよい。権利マネジメント・システムの更なる詳細は、前記の参照文献に詳細に記述されており、以降、ここでは特に説明しない。

このようにして、権利マネジメント・システムは、コンテンツを保護するだけでなく、コンテンツの所有者がライセンスという手段によって自分のコンテンツの販売および使用を管理できるようにする。ライセンスは権利表記を含み、権利表記は使用権を明確に表現し、使用権をコンテンツへ関連づける。ライセンスは、ディジタル・コンテンツのライフサイクルの異なった段階で指定されてよい。たとえば、ディジタル・コンテンツが頒布者へリリースされるとき、ディジタル・コンテンツの頒布を特定の地域または特定の期間に限定したり、コンテンツが再パッケージされる方法を制限するため、コンテンツの所有者によってライセンスが指定されてよい。もちろん、ライセンスは、コンテンツがどのように使用されるかを決定する制御的切り口であるから、ライセンス自体も保護されなければならない。この点に関して、ライセンスは、通常、発行者によってディジタル的に署名され、ライセンスの完全性および真正性が解釈前に検証されてよい。

ライセンスは、通常、許諾（付与）要素、本人要素、権利要素、リソース要素を含み、またオプションとして条件要素を含む。具体的には、ライセンスは、許諾される使用権の詳細を定義する１つまたは複数の許諾要素を含む。１つまたは複数の許諾要素は、本人要素、権利要素、リソース要素を指定することができ、またオプションとして条件要素を指定することができる。本人要素は、保護されたコンテンツにアクセスまたは使用する権利を許諾された本人（ユーザ）または本人グループを識別し、権利要素は、保護されたリソースのアクセスまたは使用に関して本人へ与えられる特定の権利（たとえば、再生、閲覧、印刷、複写）を指定する。リソース要素は、保護されたリソースを指定し、オプションの条件要素は、保護されたリソースを使用する権利に課される条件を指定する。

ライセンスは、通常、権利表記として具体化される。権利表記は、権利情報を伝達するため、定義された文法に基づいた構文的および意味的に正しい言語構造である。前述したように、権利表記言語の例はＸｒＭＬ（商標）である。重要な注意点として、ここで使用される「権利表記」の用語は、特定のライセンスに限定されず、情報を伝達するため権利マネジメント・システムによって使用される任意の表記を意味する。したがって、ここで使用される「権利表記」の用語、およびその派生用語は、一般的に、ライセンス、ライセンスの構成要素および／または構成部分（たとえば、許諾要素、本人要素、権利要素、リソース要素、および／または条件要素）の表記、および他の適切な表記を意味する。更に、権利表記は多様な形態であってよく、その範囲は、対象リソースが制約されたアプリケーションのバイナリエンコードシーケンスから、ディジタル・リソースの頒布を管理する複雑な権利情報および権利許諾パラダイムを記述するマルチレベルＲＥＬ構造までに及ぶ。
米国特許第５，６２９，９８０号公報 米国特許第５，６３４，０１２号公報 米国特許第５，６３８，４４３号公報 米国特許第５，７１５，４０３号公報

本発明の１つの態様によれば、１つまたはそれ以上の権利表記を処理する拡張可能な文法ベースの権利表記システムが提供される。このシステムは、権利表記を評価するように構成されたインタープリタであって権利表記の評価を可能にするように構成された１つまたは複数のプラグイン・サブコンポーネントを含むインタープリタと、インタープリタによって認証された１つまたはそれ以上の権利表記の中に設定された条件の遵守を確認するように構成されたバリデータと、インタープリタとバリデータとの間のインタフェースを提供するように構成されたフレームワークとを含む。

本発明の他の態様によれば、１つまたはそれ以上の権利表記を処理する拡張可能な文法ベースの権利表記システムであって、文法へ拡張部分を付加するための１つまたは複数の拡張可能ポイントを備えた拡張可能アーキテクチャを有するフレームワーク、および１つまたは複数の権利表記を評価するように構成されたインタープリタを含み、拡張部分が新しい権利表記の意味および構文を定義して、新しい権利表記の処理を可能にするシステムが提供される。

更に、本発明の他の態様によれば、１つまたはそれ以上の権利表記を処理する方法が提供される。１つまたはそれ以上の権利表記は、リソースに関連づけられた使用権を本人のために要求するリクエスト、およびリソースに関連づけられた使用権を本人へ発行する許諾を含む。前記方法は、プラグイン・コンポーネントをフレームワークへ登録し、１つまたはそれ以上の権利表記の中に設定された使用権へのリクエストを認証するためにフレームワークへプログラム呼び出しを行い、１つまたはそれ以上の権利表記の中に設定されたリクエストの各々を評価するように構成された１つまたはそれ以上の適切なプラグイン・コンポーネントを探索し、適切なプラグイン・コンポーネントを呼び出し、許諾に対するリクエストを評価し、リクエストが許諾によって認証されるかどうかを示す認証の結果を返却するステップを含む。

本発明の更に他の態様は、１つまたはそれ以上の権利表記を処理する方法であって、１つまたはそれ以上の権利表記を評価するように構成されたインタープリタを備えた拡張可能なアーキテクチャを有する拡張可能文法ベース権利表記システムを提供し、インタープリタを使用して、許諾に対するリクエストを評価し、リクエストが許諾によって認証されるかどうかを示す認証の結果を返却するステップを含む方法である。前記方法は、好ましくは、更に、拡張可能文法ベース権利表記システムに、新しい拡張部分を付加して、新しい権利表記の処理を可能にするステップを含み、前記拡張部分は、新しい権利表記の意味および構文を定義する。

権利マネジメント・システムは、ディジタル・コンテンツおよび他のアイテム、たとえばサービス、物品などへ適用することができる。たとえば、権利および条件は、任意の物理的または非物理的事物、オブジェクト、クラス、カテゴリー、サービス、またはアクセス、頒布、実行を行うためのアイテム、またはその他の制御、制限、記録、計測、請求、モニタ、または何らかの様式で使用が管理されるアイテムに関連づけることができる。したがって、権利マネジメント・システムは、コンテンツ、サービス、ソフトウェア・プログラム、物品など、任意のアイテムについて使用権および条件を指定および実施するために使用することができる。この点に関して、権利マネジメントの概念を有形のアイテムへ拡張するため、使用権をアイテムに関連づけるアイテム・チケットを使用することができる。ライセンスまたはその他の権利表記は、アイテム・チケットを示すチケット指定を使用して、図１３で示されるようなアイテム・チケット６００に関連づけられる。アイテム・チケット６００は、関連づけられたライセンスに従う場合以外はアイテム・チケット６００の処理またはレンダリングを防止するための、何らかの暗号化アルゴリズム、またはその他のメカニズムを使用して保護されることができる。セキュリティ・メカニズムをアンロックされたアイテム・チケット６００は、人間またはコンピュータが読み取ることのできるクーポン、コード、文書などとなる。したがって、「アイテム・チケット」の用語は、有形または無形のアイテム指示を意味する。アイテム・チケットは１つまたは複数のアイテムを指定し、したがって、使用権および条件は、前述したように使用、アクセス、頒布、または実行が、制御、制限、記録、計測、請求、モニタ、その他何らかの様式で管理される、オブジェクト、クラス、カテゴリー、およびサービスを含む任意のアイテムに関連づけることができる。

図１３で示されるように、アイテム・チケット６００は、アイテムリファレンス６０２およびアイテム・チケット６００のアイテムへの引き換えを制限するライセンス後条件６０４を指定することによって準備される。アイテム・チケット６００は、アイテムリファレンス６０２を介してアイテムへリンクすることができる。ここで使用される「リンク」の用語は、記述、ポインタなどのような任意のタイプの関連づけを意味する。たとえば、アイテム・チケット６００は、データベース・レコードを介してアイテムに関連づけられた一意のコードを含むことができる。コードがベンダへ与えられたとき、データベースが検索され、対応するアイテムを引き渡すことができる。アイテム・チケット６００は、更に、人間が読み取れるアイテムの記述、および未だ満足されていないライセンス後条件６０４、たとえば、アイテム・チケット６００が（アイテムに）引き換えられる特定のロケーションまたは時間を含むことができる。アイテム６００へのアクセスは、コンテンツに関して先に説明したように、ライセンスを使用して制御することができる。アイテム・チケットを利用する権利マネジメント・システムの更なる詳細は、２００２年６月３日に出願された「実施可能な財産権を頒布する方法および装置」と題する米国特許出願第１０／１５９２７２号公報に開示されており、この開示を参照することにより本明細に組み込まれる。

アイテムの詳細がどのようなものであれ、また、アイテムがディジタル・コンテンツ、オブジェクト、クラス、カテゴリー、サービス、またはその他のアイテムであれ、有効なライセンスを記述し、権利表記処理システムを設計および実現するのは、複雑で困難な仕事である。権利表記およびアプリケーション環境の動的な局面をサポートする場合、様々な困難に遭遇する。特に、権利表記は静的または動的であってよい。静的権利表記は、固定された権利情報を記述するため静的に定義され、したがって拡張されてはならない。しかし、動的権利表記は、権利表記の意味または文法を変更することなく、新しい構文の付加を可能にする。たとえば、ワイヤレス・コンテンツ頒布産業におけるベンダは、新しい権利、たとえば「ブロードキャスト」権を作成し、権利を管理されたコンテンツを加入者の装置へ「プッシュ」する権利を、権利マネジメントのサポートを受ける頒布者へ許諾したいと望むかも知れない。常に変化する技術およびビジネス・パラダイムは、新しい種類の権利を作成せざるを得なくする。拡張可能な権利表記処理システムがなければ、新しい権利表記の拡張、変形、および派生に適応するため、異なった静的システムを設計および実現しなければならない。

したがって、権利表記処理システムは、好ましくは、システムが設計および実現される時点で定義されていない新しい権利情報への適応を可能にするように拡張可能でなければならない。必然的に、拡張可能アーキテクチャを使用した拡張可能な権利表記処理システムを提供し、権利表記が静的であろうと動的であろうと、権利表記または基礎となるスキーマまたはデータ・ディクショナリの再設計を必要とすることなく権利表記を生成、変更、認証、および確認するために使用できるようにすることが望ましい。ここで説明されるように、拡張可能な権利表記処理システムの拡張可能アーキテクチャは、拡張された権利表記および新しい権利表記の動的処理を可能にする。

図１は、本発明の１つの実施形態に従った、文法ベースの権利表記を生成、変更、認証、および／または確認するために使用される、権利表記処理システム１０のブロック図を示す。以下の説明から明かであるように、権利表記処理システム１０は、既存の権利表記の意味または文法を変更することなく、新しい構文の付加を可能にするよう拡張可能であり、これにより新しい権利表記への適応が可能である。最初に注意すべきは、例示された実施形態は、ここでは権利表記処理システムと呼ばれるが、本発明は、ここで説明されるアーキテクチャを有する任意のシステムまたは装置で実現されてよいことである。この点に関して、権利表記処理システム１０は、任意のタイプのハードウェアおよびソフトウェアを使用して実現されてよく、また、前もってプログラムされた汎用コンピューティング装置であってよい。たとえば、権利表記処理システム１０は、パーソナル・コンピュータ、携帯用コンピュータ、シンクライアントなどを使用して実現されてもよい。権利表記処理システム１０は、単一のロケーションにおける単一の装置であるか、単一または複数のロケーションにおける複数の装置であってよい。これらの複数の装置は、電気ケーブル、光ファイバ・ケーブル、任意のケーブルのような、任意の通信媒体を介する任意の適切な通信プロトコルを使用して相互に接続されるか、無線周波数、赤外線、または他の技術を使用するワイヤレス方式で接続される。

更に注意すべきは、本発明の１つの実施形態に従った権利表記処理システム１０は、ここでは特定の機能を実行する複数のコンポーネントを有するように図示および説明されることである。これらのコンポーネントは、明瞭にする目的で機能に基づいて例示されるだけであり、必ずしも特定のハードウェアまたはソフトウェアを表すものではないことを理解されたい。これらのコンポーネントは、説明された特定の機能を実質的に実行するように実現されたハードウェアおよび／またはソフトウェアであってよい。更に、権利表記処理システム１０の中で、これらのコンポーネントの２つ以上を一緒に組み合わせるか、所望の特定の機能に基づいて、より多くのコンポーネントへ分割してよい。したがって、図１で具体化されたような本発明は、本発明の権利表記処理システム１０を限定するように解釈されてはならない。

図示された実施形態において、権利表記処理システム１０は、権利表記処理システム１０の他のコンポーネントのインタフェースを可能にするフレームワーク１２を含む。フレームワーク１２は、システムのその他の全てのコンポーネントの間の相互作用、および様々なコンポーネントによって実行される権利表記処理機能を調整する権利表記処理システム１０の基盤コンポーネントである。権利表記処理システム１０のフレームワーク１２は権利表記を言語的に認識しないことが好ましい。即ち、フレームワーク１２は、権利表記の特定の構文または文法と結びつけられていない。更に、フレームワーク１２は、様々な他のコンポーネントの付加を許して、新しい権利表記の処理を可能にする、拡張可能ポイントを有する拡張可能アーキテクチャを有する。もちろん、他の実施形態では、フレームワークは拡張可能ポイントを備えた拡張可能アーキテクチャを有する必要はないが、その代わりに、固定のコンポーネントを使用して実現されるであろう。

例示された実施形態の権利表記処理システム１０は、更に、データの解析および操作を可能にするように構成されたパーサ１４を含む。具体的には、パーサ１４は、基礎的な操作、たとえば、入力、出力、構文確認、および権利表記処理システム１０によって処理される権利表記２４の操作を実行するコンポーネントである。好ましくは、パーサ１４は汎用であり、権利表記処理システム１０の振る舞いに影響を与えることなく、互換性を有する他のパーサによって置換できるプラグイン・コンポーネントとして実現される。

再び、ここで使用される「権利表記」の用語は、特定のライセンスへ限定されず、情報を伝達するため権利表記処理システム１０によって使用される任意の表現を意味する。したがって、ここで使用される「権利表記」の用語およびその派生用語は、一般的に、ライセンス、ライセンスの構成要素および／または構成部分（たとえば、許諾要素、本人要素、権利要素、リソース要素、および／または条件要素）の表記、並びに他の適切な表記を意味する。

たとえば、権利表記２４は、ディジタル・リソースに関連づけられた使用権と、使用権が許諾された本人とを含む許諾であってよい。許諾が発行された当事者は「本人」と呼ばれ、権利の対象、たとえば、ｅブックは「ディジタル・リソース」と呼ばれ、この対象を使用する権利は「使用権」と呼ばれる。代替的に、権利表記２４は、ディジタル・リソースに関連づけられた使用権と、ディジタル・リソースの使用を要求する本人とを含むリクエストであってよい。更に、権利表記２４は、許諾およびリクエストを含んでよい。権利表記２４は、ＸＭＬまたはＸｒＭＬ（商標）のような、任意の適切な権利表記言語（以下では、「ＲＥＬ」と呼ぶ）で表記されてよい。好ましい実施形態において、基礎であるパーサ１４は、ＸＭＬまたはＸｒＭＬ（商標）スキーマのような、拡張可能な定義の使用によって、全ての権利表記に特定の構文および文法を包み隠している。

本発明の実施形態の権利表記処理システム１０は、更に、権利表記２４を評価および／または認証し、認証の結果を提供するように構成されるインタープリタ１６を含む。具体的には、インタープリタ１６は、権利表記２４に設定された許諾および／またはリクエストに基づいて権利表記２４を評価する。次に、インタープリタは、無条件で権利表記２４を認証し、権利表記２４の中で識別されたディジタル・リソースの消費を認証してもよい。代替的に、インタープリタ１６は、権利表記２４を条件付きで認証し、権利表記２４の中に設定された１つまたは複数の条件が満足された場合のみ、権利表記２４の中で識別されたディジタル・リソースの消費を認証してもよい。更に、インタープリタ１６は、権利表記２４の中で識別されたディジタル・リソースの消費がなされないように、権利表記２４を認証しなくてもよい。

例示された実施形態によれば、インタープリタ１６は、異なった権利表記２４の評価および／または認証を可能にするように構成される複数のプラグイン・サブコンポーネント１８を有する、プラグイン・コンポーネントとして実現される。更に、新しい権利表記の評価および／または認証を可能にするため、新しいプラグイン・サブコンポーネントをインタープリタ１６へ付加し、それによってインタープリタ１６を拡張してよい。代替的または付加的に、権利表記処理システム１０は拡張可能なアーキテクチャを有するので、新しい権利表記を評価および／または認証するように構成された新しいインタープリタを権利表記処理システム１０へ付加してもよい。

権利表記処理システム１０は、更に、評価されている権利表記の中に設定された条件がもしあれば、その満足を確認するように構成された１つまたは複数のバリデータ２０を含む。具体的には、前述のインタープリタ１６が、もし権利表記２４を条件付きで認証するならば、バリデータ２０は、権利表記２４の中で識別されたディジタル・リソースの消費を許す前に、条件の満足を確認する。権利表記処理システム１０の例示された実施形態では、バリデータＡからバリデータＭが設けられ、各々のバリデータは、たとえば、状態変数の値を検証することによって、特定のタイプの条件を評価するように構成される。権利表記処理システム１０の拡張可能アーキテクチャは、新しい権利表記を評価および／または認証するように構成された新しいバリデータが、権利表記処理システム１０へ付加されることを可能にする。たとえば、処理される権利表記の中に表記された新しい条件の確認を可能にするために、プラグイン・コンポーネントとして実現されたバリデータＮ（図示されていない）を後で付加することができる。

更に、権利表記処理システム１０は、ここではアプリケーション２２と呼ばれる権利表記使用可能コンポーネントを含む。アプリケーション２２のコンポーネントは、権利表記処理システム１０の「ユーザ」を表す。前記ユーザは、権利表記の創作者、頒布者、または消費者であってよい。アプリケーション２２の例は、権利オーサリング・アプリケーションおよびシステム、マルチメディア、ビデオ、写真の画像、および音楽作品のようなディジタル・コンテンツのレンダリング・アプリケーション、および／またはウェブ・サービス実行システムなどを含む。たとえば、もしアプリケーション２２が、権利表記の消費者、たとえば、ディジタル・コンテンツおよび／またはサービスのレンダリング・アプリケーションであれば、アプリケーション２２は、拡張可能な権利表記処理システム１０の様々なコンポーネントを利用して、権利表記の解析、確認、または評価のような様々な処理操作を実行することができる。

図２は、権利表記を処理している図１の拡張可能な権利表記処理システム１０のブロック図である。アプリケーション２２は、ディジタル・リソース２６に関連づけられ、ディジタル・リソース２６に関する情報を含む、権利表記２４を受け取る。前述したように、権利表記２４は、ディジタル・リソース２６に関連づけられた使用権、および、使用権が許諾される本人を含む許諾を含んでよい。代替的に、権利表記２４は、ディジタル・リソース２６に関連づけられた使用権、およびディジタル・リソース２６の使用を要求している本人を含むリクエストであるか、そのリクエストをさらに含んでよい。

アプリケーション２２は、ディジタル・リソース２６に関する情報とともに権利表記２４をフレームワーク１２へ渡す。次に、フレームワーク１２は、特定の権利表記２４を評価および／または認証することのできるインタープリタ１６を検出し、評価および／または認証のために権利表記２４をインタープリタ１６へ渡す。特定の権利表記２４を評価および／または認証することのできるインタープリタ１６の検出は、様々な方法で実現されてよい。１つの実施形態では、インタープリタ１６が、たとえばアプリケーション２２を使用して、フレームワーク１２を介して権利表記処理システム１０へ提供されるとき、インタープリタ１６は、インタープリタ１６によって評価および／または認証される特定の名前空間の全ての権利表記を権利表記処理システム１０に登録する。もしインタープリタ１６が、権利表記の評価および／または認証を要求された場合、その権利表記は検索され、権利表記がインタープリタ１６によって登録されたかどうかが確認され、登録されていれば、インタープリタ１６が権利表記を評価および／または認証できることを示す。もし権利表記がインタープリタ１６によって登録されていなければ、インタープリタが権利表記を評価および／または認証できないことを示し、インタープリタ１６はフレームワーク１２と交信して、権利表記処理システム１０へ権利表記を登録した異なるインタープリタを検出し、それに従って認証リクエストを渡し、権利表記が評価および／または認証されるようにする。もちろん、他の実施形態では、他の方法を使用して、権利表記を評価および／または認証する適切なインタープリタを検出してよい。上記の方法は、単なる１つの例として提供される。

インタープリタ１６は、異なった種類の権利表記を評価するように構成された１つまたは複数のプラグイン・サブコンポーネント１８を使用して、権利表記２４を評価する。前述したように、インタープリタ１６は無条件で権利表記２４を認証する認証の結果を提供し、それによってアプリケーション２２が、妨げられずにディジタル・リソース２６を消費する権利を有することを示すこともできる。代わりに、インタープリタ１６は、権利表記２４を条件付きで認証して、アプリケーション２２が、権利表記２４の中に設定された１つまたは複数の条件が満足されたときのみ、ディジタル・リソース２６を消費する権利を有することを示すこともできる。更に、インタープリタ１６は、権利表記２４を認証せず、アプリケーション２２が、ディジタル・リソース２６を消費する権利を有しないことを示してもよい。もちろん、インタープリタ１６による評価の結果は、権利表記２４の中に設定された許諾および／またはリクエストに基づく。

権利表記２４が許諾およびリクエストの双方を含む例では、インタープリタ１６による評価は、許諾をリクエストと比較することによって達成されるのが好ましい。具体的には、リクエストの中に設定された使用権、リソース、および本人が、許諾の中に含まれる使用権、リソース、および本人と比較される。したがって、インタープリタ１６は、この比較に基づいて認証の結果を提供することができる。更に具体的には、もしリクエストおよび許諾の使用権、リソース、および本人が相互に一致すれば、インタープリタ１６はリクエストを認証する。代替的に、もしリクエストおよび許諾の使用権、リソース、および本人が相互に一致し、許諾が更に１つまたは複数の条件を含むならば、インタープリタ１６はリクエストを条件付きで認証する。代替的に、もしリクエストおよび許諾の使用権、リソース、および本人が相互に一致しなければ、インタープリタ１６はリクエストを認証しない。

もしインタープリタ１６が権利表記２４を条件付きで認証するならば、バリデータ２０は、権利表記２４の中で識別されたディジタル・リソース２６の消費を許す前に、条件の満足を確認する。各々のバリデータ（バリデータＡからバリデータＭ）は、好ましくは、１つまたは複数の特定タイプの条件を評価するように構成される。したがって、フレームワーク１２は、ディジタル・リソース２６の消費を許す前に、権利表記２４の中に設定された条件の満足を確認するように構成された適切なバリデータを探索および識別する。適切なバリデータの探索および識別は、前述したインタープリタの検出と類似した方法で条件を登録および検索する方法によって達成されてよい。もちろん、他の方法も代替的に使用されてもよい。

前述したように、権利表記処理システム１０の好ましい実施形態は、拡張可能ポイントを備えた拡張可能アーキテクチャを有し、権利表記処理システム１０の様々なコンポーネントをプラグイン・コンポーネントとして実現することによって、既存の、および将来新しく定義される文法ベースの権利表記を評価できるように拡張することができる。したがって、インタープリタ１６は、追加のインタープリタおよび／またはプラグイン・サブコンポーネントが付加できるプラグイン・サブコンポーネント１８を有するプラグイン・コンポーネントとして実現され、権利表記処理システム１０によって最初はサポートされていなかった新しい権利表記の評価を可能にする。更に、バリデータ２０もプラグイン・コンポーネントとして実現され、追加のバリデータが容易に付加されて、新しい条件を処理できるようにする。こうして、権利表記処理システム１０は、好ましくは、新しい権利表記が新しい権利許諾パラダイムおよびアプリケーションに対応して開発されたとき、それら新しい権利表記を処理するように容易に拡張可能である。

たとえば、ベンダＡは、たとえばライセンスのような権利証明の総発行者および解釈者になることを意図してウェブ・サービスを開始することができる。ベンダＡが直面する１つの明かな困難は、その開始時点で可能な全ての権利許諾パラダイムに適応するような普遍的システムを構築することがほとんど不可能であることである。なぜなら、技術および商業の更なる発展は、新しい権利表記および／または新しい条件の使用を伴う新しい権利許諾パラダイムの必要性を生じる可能性があるからである。しかし、本発明に従った権利表記処理システム１０は、前述した方法により拡張可能であるから、ベンダＡは、インタープリタ１６および既存の権利表記を処理するバリデータ２０を使用して、権利表記処理システム１０を構築することができる。それに関連づけられた新しい権利表記および条件の必要性が生じたとき、ベンダＡは新しいコンポーネントを構築して、これらの新しい権利表記を処理することができる。たとえば、インタープリタ１６の新しいプラグイン・サブコンポーネント、新しいインタープリタ、および／または新しいバリデータが、新しい権利表記を処理するために構築され、権利表記処理システム１０へ付加されてよい。

前述したように、インタープリタ１６は、権利表記２４の評価および認証を可能にし、権利表記２４へ意味を与えるように構成されるプラグイン・コンポーネントである。たとえば、付録Ａは、権利表記２４の例示的ライセンス５０を示す。ライセンス５０は、２５．５５ドルの均一料金で主題「ｅブック」を閲覧、印刷、および複写する無制限の権利を、有効なキーを保持する本人または他の認証された人物に許諾する。

図１および図２を再び参照すると、権利表記処理システム１０の図示された実施形態のインタープリタ１６、フレームワーク１２、およびアプリケーション２２の間の相互作用は、次のとおりである。最初に、アプリケーション２２は、好ましくは、信頼されたプラグイン・コンポーネント、たとえば、インタープリタ１６、バリデータ２０、および他のサポートできるプラグイン・コンポーネントをフレームワーク１２へ登録する。次に、アプリケーション２２は、権利表記２４のリクエストを認証するためフレームワーク１２へプログラム呼び出しを行う。次に、フレームワーク１２は、権利表記２４の中の許諾に対してリクエストを認証することのできる適切なプラグイン・コンポーネントを探索して呼び出す。具体的には、フレームワーク１２は、たとえば、前述したような登録および検索の方法を使用して、権利表記２４を評価および認証するように構成された適切なインタープリタ１６およびバリデータ２０を識別する。

識別されたインタープリタ１６は、権利表記２４の中に含まれる許諾の記述に対してリクエストを評価する様々な操作を実行する。リクエストの権利、リソース、および本人は、許諾の権利、リソース、および本人に対して照合される。許諾を評価するステップは、更に、暗号化されている許諾を解読し、ディジタル署名がされている場合はディジタル署名を検証し、および／または許諾の発行者を認証することを含んでよい。更に、リクエストを評価するステップは、本人が真正であることを認証し、リソースを検証することを含んでよい。インタープリタ１６は、認証の結果をアプリケーション２２へ返却し、所与の権利表記２４によってリクエストが認証されたか、条件付きで認証されたか、認証されないかを示す。

もしインタープリタが権利表記２４を条件付きで認証すれば、アプリケーション２２は、フレームワーク１２を介して適切なバリデータ２０を呼び出し、要求された条件を確認することができる。これは、たとえば、設定された条件を確認するために必要な関連データをアプリケーション２２に提供させることによって達成されてよい。関連データを使用して、バリデータ２０は、権利表記２４の中に設定された条件の遵守を確認する。もし適切な関連データが提供されなければ、条件は満足されていないと考えてよい。もちろん、前述した方法は、バリデータ２０が権利表記２４の条件の遵守を確認する方法の単なる１つの例であり、他の実施形態では、他の方法が使用されてよい。

付録Ａのライセンス５０の中で設定された権利表記２４の例では、料金要素が、ｅブックを閲覧、印刷、および複写することの許諾に含まれる全ての権利に関連づけられた条件である。料金条件は、もし２５．９９ドルの料金が支払われたならば、その場合にのみ、アプリケーション２２が権利の行使を許されることを記述している。例に示されるように、バリデータ２０は、必要な関連データを提供する支払い記録（レコード）サービスにアクセスし、この条件が満足されたことを確認する。

もちろん、注意すべきは、多数の確認を必要とする多数の条件が権利表記の中に設定されてよいことである。この点に関して、複数のバリデータ２０が、条件を表す権利表記の中に設定された多数の条件を確認することができる。フレームワーク１２は、バリデータ２０を管理し、たとえば次の確認規則に基づいて、バリデータ２０を１つずつ呼び出す。

Ｆｏｒ ｅｖｅｒｙ ｃｏｎｄｉｔｉｏｎ ｏｎ ｔｈｅ ｃｏｎｄｉｔｉｏｎｓ ｌｉｓｔ
（条件リスト上の全ての条件について）
Ｆｏｒ ｅｖｅｒｙ ｖａｌｉｄａｔｏｒ ｏｎ ｔｈｅ ｖａｌｉｄａｔｏｒｓ ｌｉｓｔ
（バリデータ・リスト上の全てのバリデータについて）
Ｐｅｒｆｏｒｍ ｃｏｎｄｉｔｉｏｎ ｖａｌｉｄａｔｉｏｎ
（条件の確認を実行する）
Ｉｆ ｃｏｎｄｉｔｉｏｎ ｉｓ ｖａｌｉｄ， ｓｋｉｐ ｔｏ ｔｈｅ ｎｅｘｔ ｂｙ ｅｘｉｔｉｎｇ ｔｈｅ ｉｎｎｅｒ ｆｏｒ−ｌｏｏｐ
（もし条件が有効であれば、内部ｆｏｒループを出て次へスキップする）
Ｉｆ ｃｏｎｄｉｔｉｏｎ ｉｓ ｉｎｖａｌｉｄ， ｔｈｅｎ ｓｋｉｐ ｔｏ ｔｈｅ ｎｅｘｔ ｖａｌｉｄａｔｏｒ
（もし条件が無効であれば、次のバリデータへスキップする）
Ｅｎｄ−ｆｏｒ（ｖａｌｉｄａｔｏｒｓ ｌｉｓｔ）
（バリデータ・リストについて処理終了）
Ｅｎｄ−ｆｏｒ（ｃｏｎｄｉｔｉｏｎｓ ｌｉｓｔ）
（条件リストについて処理終了）
Ｉｆ ａｌｌ ｃｏｎｄｉｔｉｏｎｓ ａｒｅ ｖａｌｉｄ， ｅｘｉｔ ｖａｌｉｄａｔｉｏｎ ｐｒｏｃｅｓｓ ａｎｄ ｒｅｔｕｒｎ ａ ｓｕｃｃｅｓｓ ｓｔａｔｕｓ
（もし全ての条件が有効であれば、確認プロセスを出て成功状態を戻す）
Ｅｌｓｅ ｅｘｉｔ ｖａｌｉｄａｔｉｏｎ ｐｒｏｃｅｓｓ ａｎｄ ｒｅｔｕｒｎ ａ ｆａｉｌｕｒｅ ｓｔａｔｕｓ．
（そうでなければ、確認プロセスを出て失敗状態を戻す）

もちろん、上記の確認規則は、単なる１つの例であり、代わりに他の規則が使用されてよい。

図３は、本発明の１つの態様に従った権利表記ライフサイクル１００を示す。図示されるように、権利表記ライフサイクル１００は、４つの基本プロセス（処理）段階、即ち、生成１１０、変更１２０、認証１３０、および確認１４０を含む。これらのプロセス段階の各々は、この順序で実行され、図示された好ましい実施形態に従って、確実に実施可能な権利表記１０４の適切な処理をできるようにする。もちろん、他の実施形態では、順序および／またはライフサイクル自身が変更されてよい。

図３で示されるように、権利データ１０２および／または権利表記ＲＥ１０４は、生成プロセス段階１１０で入力処理され、処理された権利表記ＲＥは、処理されたものとしてプライム符号を付加されて示される。具体的には、権利表記ＲＥ’１１４が、生成プロセス段階１１０の出力として作り出される。次に、権利表記ＲＥ’１１４は、権利表記ＲＥ’１１４をＲＥ”１２４へ変換する変更プロセス段階１２０へ入力される。注意すべきは、権利表記ＲＥ、ＲＥ’、およびＲＥ”は異なっている必要はなく、或る場合には、もし権利表記が１つまたは複数のプロセス段階で変更される必要がなければ、同じであってよいことである。

認証プロセス段階１３０では、権利表記ＲＥ”１２４およびその他補助情報が受け取られ、権利表記ＲＥ”１２４の中に記述されて行使される権利が、たとえば図１および図２に関して説明されたようにして評価および認証される。認証プロセス段階１３０に続いて、確認プロセス段階１４０では、認証された権利表記ＲＥ”またはそのサブセットが、たとえば、図１および図２に関して説明したようにして確認され、設定された条件の遵守が確認される。こうして、権利表記ライフサイクル１００の様々なプロセス段階の終わりまでに、権利表記ＲＥ１０４は権利表記ＲＥ”１２４へ変換されて、ステップ１４４で新しい権利データ１０２と一緒に再び使用されてよい。

前述したプロセス段階の各々は、それら自身に拡張可能とするための手段を有することが明かであろう。この点に関して、各々のプロセス段階の明確な説明および理解を容易にするため、前述した「ｅブック」の例を使用して、各々のプロセス段階が、どのように権利表記に影響を及ぼし、権利表記処理システムのコア（中核）を修正する必要なしに拡張可能性を実現するかを説明する。たとえば、ｅブックの出版者は、出版者が信頼する誰かによって発行された有効なキーを保持する人なら誰でも、２５．９９ドルの均一料金を支払う限り、ｅブックの内容を閲覧、印刷、および複写する無制限の権利を許諾することができる。権利表記は様々なＲＥＬを使用して表されてよいが、１つのＲＥＬはＸｒＭＬ（商標）であってもよい。前述したように、ライセンスＸｒＭＬ（商標）の権利の実施可能なセットは、付録Ａのライセンス５０の中に設定されるように、権利表記２４の中に発見することができる。しかし、前述したように、ここで使用される「権利表記」の用語は、単独では実施可能でなく、実施可能なライセンスを意味するものと解釈されてはならないライセンスの断片を含む、いかなる権利表記をも意味する。

生成プロセス段階１１０で例示したｅブックについて権利表記を生成するため、様々な情報の断片が利用可能でなければならない。たとえば、ｅブックの名前、ｅブックの使用を望む本人を識別するキー、およびｅブックの使用について２５．９９ドルの均一料金を処理する支払いサービスに関する情報が利用可能にされなければならない。図３および図４において、この情報は権利データ１０２として表される。図４は、図３の権利表記ライフサイクル１００における権利表記生成プロセス段階の概略図を示す。具体的には、権利データ１０２は、権利表記１１４を生成するため権利表記処理システム１０によって使用される。この権利データ１０２は、この情報を、人間または機械の可読形式で伝達してよい。

注意すべきは、権利表記１０４は、ライフサイクル１００のこの段階で、実施可能であってもなくてもよいことである。この点に関して、権利表記１０４は、次の段階、即ち変更プロセス段階１２０で追加のデータとマージされることのできる単なる権利の断片であってよく、変更プロセス段階１２０でそれらをあわせて実施可能な権利を有する権利表記を形成する。更に、権利データ１０２は、たとえば、誰かが権利表記を直接コーディングすることによって、権利表記１０４へ手作業で操作されることが可能である。このプロセスが自動プロセスで起こるか、手作業プロセスで起こるかを問わず、最終的な結果は、任意の言語または構文で表される権利表記ＲＥ’１１４の生成である。

生成プロセス段階１１０の拡張可能性は、権利表記処理システム１０のコアをどのような様式でも変更する必要なしに、権利表記の追加または既存の権利表記の操作を可能にする。前述したように、この拡張可能性を可能にする１つの例示的ＲＥＬは、Ｗ３Ｃ ＸＭＬスキーマ標準に基づくＸｒＭＬ（商標）権利表記言語である。この標準は、言語を定義するコア・スキーマを不変のままに残すが、なお外部スキーマが参照することにより言語を利用および拡張することを許容する。

例を再び参照すると、もしｅブックを提案した出版者が、その使用について同じ２５．９９ドルを課金したいと望んだが、法律によって、その販売に対し適用可能な売上税を課金するように要求されたとすれば、出版者または出版者を代理する誰かが、「税金」という名前の新しい権利表記を付加することができる。この新しい権利表記は、ＸｒＭＬ（商標）コア・スキーマを基礎として参照しながら、それら自身のスキーマへ付加されるであろう。これは、ＸｒＭＬ（商標）スキーマの全ての権利表記を、新しい権利表記に使用することを可能にする。権利表記の操作を可能にする能力は、新しく特注された（カスタム）権利表記２０４がコア権利表記２０２と結合される概略図２００を示す、図５で最も明瞭に例示される。新しいカスタム権利表記２０４は、適用される税率を設定する＜ｓｘ：ｔａｘ＞０．０８２５＜／ｓｘ：ｔａｘ＞を記述している。コア権利表記２０２は、ｅブックの料金を設定している。コア権利表記２０２とカスタム権利表記２０４との結合の結果、料金および税金が設定された結合権利表記２０６を生成される。説明した方法によって、本発明の権利表記処理システム１０は、この新しい結合権利表記２０６を生成するように拡張されることができる。

この拡張可能性は、権利表記処理システム１０のパーサ１４を他のコンポーネントから分離することによって可能となる。図１で示されるように、パーサ１４は、フレームワーク１２によって、権利表記処理システム１０の他のコンポーネントから分離される。各々のコンポーネントは、したがって、フレームワーク１２を介してパーサ１４と交信し、様々なコンポーネントの間の直接交信は許されないのが好ましい。これは、標準化されたインタフェースを可能にし、プラグイン・サブコンポーネント１８および／またはバリデータ２０のような追加のコンポーネントが、前述の権利表記処理システム１０へ付加されることを可能にする。新しく付加された各々のコンポーネントは、そのアクションを実行するときフレームワーク１２と交信する限り、その意図されたアクションを実行することができる。

図５の概略図２００を参照すると、プラグイン・サブコンポーネント１８を有するインタープリタ１６および／またはバリデータ２０のような新しいコンポーネントは、権利表記処理システム１０へ付加されることができ、この新しいコンポーネントは、権利表記２０４の中で提供された税金表記を理解し、フレームワーク１２を介してパーサ１４とともに動作し、新しい「税金」要素を組み込んだ結合権利表記２０６を評価および／または確認する。パーサ１４は、フレームワーク１２が権利表記２０４の「税金」要素を評価および／または確認することのできる権利表記処理システム１０のコンポーネントを認知しているかどうかを、フレームワーク１２へ単純に照会する。次に、フレームワーク１２は、要求されたコンポーネントを検出し、構文またはそれに付随する関連データを確認するような何らかのアクションを実行するようにコンポーネントに求める。権利表記処理システム１０のコンポーネントが、新しい「税金」要素を処理する能力を有しないならば、新しい「税金」要素を処理するように構成されたコンポーネントを権利表記処理システム１０へ提供することができる。新しいコンポーネントを使用して、権利表記２０６は、権利表記処理システム１０によって適正に処理されることができる。このようにして、権利表記処理システム１０は、適当な権利表記を処理するようにまさに拡張可能である。

図３を再び参照すると、ライフサイクル１００の変更プロセス段階１２０は、一定の形式に既存の権利表記を取り込み、それらを一定の方法で変更して、権利表記の新規および／または実施可能なセットを生成する。これは、ここで説明する１つの例示的なアプリケーションから明かであるように、非常に望ましい特徴である。ｅブックの例を再び参照すると、ｅブックの出版者は、各々および全ての顧客について権利表記の新しいセットを生成することは避けたいと思うであろう。それは、時間を無駄にするだけでなく煩わしいであろう。１つの可能な解決法であり、変更プロセス段階１２０の中の拡張可能な領域は、出版者が生成プロセス段階１１０の間に権利表記を生成し、しかし実施可能な権利の１つのセットを他のセットから区別する重要なデータを残しておくことである。そのような重要なデータは、たとえば、ｅブックの使用を認証された本人を識別するキーであってもよい。本人が指名された権利表記の中のロケーションは、データが権利表記とマージされることを可能にし、その結果、実施可能な権利表記を生じる、プレースホルダまたは「トークン」を含むことができる。

具体的には、図６は、図３の権利表記ライフサイクル１００における権利表記変更プロセス段階１２０の１つの例を概略図３００で示す。図示された例では、マージ・データ３０２は、本人、即ち、ｅブックの使用を認証された人物としての「ボブ」を識別するキーであってよい。このキーは、不完全な権利表記、即ち権利テンプレート３０４とマージされ、その結果ボブについて実施可能な権利３０６の完全なセットを生じる。たとえば、ＸｒＭＬ（商標）を使用して、権利テンプレート３０４の不完全な権利表記は、権利表記変更プロセス１０２の間に、データ・マージに先立って以下のように設定されてよい。

＜ｋｅｙＨｏｌｄｅｒ＞
＜ｄｓｉｇ：ｋｅｙＶａｌｕｅ＞
＜ｄｓｉｇ：ＲＳＡＫｅｙＶａｌｕｅ＞
＜ｃｇＸｒＭＬ：ＣＧＴＯＫＥＮ ＴＯＫＥＮＮＡＭＥ＝“＜ｔｏｋｅｎＮａｍｅ＞”／＞
＜／ｄｓｉｇ：ＲＳＡＫｅｙＶａｌｕｅ＞
＜／ｄｓｉｇ：ｋｅｙＶａｌｕｅ＞
＜/ｋｅｙＨｏｌｄｅｒ＞

一度、キー・データが権利テンプレート３０４とマージされると、結果の実施可能な権利３０６は次の設定に類似したものとなる。

＜ｋｅｙＨｏｌｄｅｒ＞
＜ｄｓｉｇ：ｋｅｙＶａｌｕｅ＞
＜ｄｓｉｇ：ＲＳＡＫｅｙＶａｌｕｅ＞
＜ｄｓｉｇ：Ｍｏｄｕｌｕｓ＞
Ｉｄｖｙｐｊａｄ７ＸｏａＹｈｕ９ｔＸＡＹＸａＥＮｆ８ｌｉ０ＶｖＷＨＢＸｖｓ５ｎＧｌｙＳｗ７ｅｘｕＤＯｖ２ｏｌｑｎＮａｐＨｔｚ９ＯｖｉｕｐＺＲＱ／ｎＥａ１ｉ＋６ＴＳＲｕＧｓｗ＝＝
＜／ｄｓｉｇ：Ｍｏｄｕｌｕｓ＞
＜／ｄｓｉｇ：ＲＳＡＫｅｙＶａｌｕｅ＞
＜／ｄｓｉｇ：ｋｅｙＶａｌｕｅ＞
＜／ｋｅｙＨｏｌｄｅｒ＞
図７は、権利表記ライフサイクル１００の権利表記変更プロセス段階１２０の間に権利表記を変更する他の例示的方法を示す概略図３３０である。具体的には、概略図３３０は、中へデータをマージすることを可能にするトークンを含む、トークン化された権利表記３３２を示す。本例では、トークン化された権利表記３３２の中に現れている「＜ｃｇＸｒＭＬ：ＣＧＴＯＫＥＮ ＴＯＫＥＮＮＡＭＥ＝”＜ｔｏｋｅｎＮａｍｅ＞”／＞」と読める行は、権利の実施可能なセットが形成される前に、この行の全体が何らかの実際のデータで置換されるべきことを示す。トークン化された権利表記３３２の中のトークンの置換値は、置換値表記３３４の中で提供され、置換値表記３３４は、トークン化権利表記３３２の中のトークンと置換される。その結果、現在の例では権利の実施可能なセットである権利表記３３６を生じる。

他の実施形態では、権利表記が変更プロセス段階１２０の間に変更できる他の方法は、ディジタル署名要件を適用することである。ディジタル署名は、多くの場合、コンテンツが改竄されなかったことを保証するために使用される。署名は、それに署名した人物を識別するためだけでなく、内部のデータの完全性を保証するために使用することができる。ディジタル署名は、多くの場合、権利マネジメント・システムの重要な部分であるが、強制的なものではなく、ディジタル署名（たとえば、Ｗ３ＣのＤＳＩＧ標準）の使用は、システム・アプリケーションに要求されるセキュリティ・レベルに依存する。もちろん、権利表記は、権利表記の内容が改竄されなかったことを保証するため、そのようなディジタル署名を要求するように変更されてよい。

認証プロセス段階１３０は、図３の権利表記ライフサイクル１００の中で最も複雑なプロセス段階であり、ここで説明される１つの実施形態では、一定の使用権を行使するリクエストを、所与の許諾の中で規定された実施可能な権利のセットと照合する。本実施形態に従った認証プロセス段階１３０は、許諾の確認、許諾の解決、および許諾の照合を含む様々なサブプロセスを包含する。

図８は、１つの実施形態に従った権利表記ライフサイクル１００の例示的な権利表記認証プロセス段階１３０を図示する概略フローチャート４００である。図示されるように、フローチャート４００では、実施可能な許諾４０２およびリクエスト４０４が、認証プロセス段階１３０で使用される。リクエスト４０４は、所望の行使する権利４０５、行使する本人４０６の識別情報、およびディジタル・リソース４０７に関する情報を含んでよい。現在の実施形態の認証プロセス段階１３０は、許諾の評価４１０、許諾の解決４２０、許諾の照合４３０のサブプロセスを含み、これらの各々について、以下で更に詳細に説明する。認証プロセス段階１３０の結果は、リクエスト４０４が認証される４７０か、条件付きで認証される４８０か、認証されない４９０かである。もちろん、ここで説明される権利表記認証プロセス段階１３０およびサブプロセスは単なる例であり、プロセスは変更または修正されてよいことを理解されたい。たとえば、認証プロセス段階１３０のサブプロセスは、以下で詳細に説明される図８から図１０までとは異なったプロセス順序およびステップを有するように変更されてよい。更に、サブプロセスの各々は、単なる例であり、図示されたものとは異なったプロセス順序およびステップを有するように変更されてよい。したがって、本発明は、図示された例に限定されるように解釈されてはならない。

許諾の評価４１０のサブプロセスは、許諾４０２の重要な要素を検証する一連のタスクを実行し、重要な要素には、ディジタル署名、発行者本人、ディジタル・リソース、および行使する権利が含まれるが、それらに限定されない。許諾の評価４１０のサブプロセスは、新しい構文および／または意味を有する権利表記を評価することができるように置換可能なコンポーネントによって実行されてよい。図９は、図３の権利表記ライフサイクル１００の認証プロセス段階１３０の中の、１つの例示的実施形態に従った許諾評価サブプロセス４１０を示す概略図である。

例示された実施形態において、許諾４０２およびリクエスト４０４は、リクエスト４０４の様々な要素を許諾４０２と照合するため、要素照合ステップ４１２で評価される。言い換えれば、要素照合ステップ４１２では、リクエスト４０４の中に設定された様々な照合要素、たとえば、権利、ディジタル・リソース、ディジタル・アイデンティティ（本人を識別するキーのような）が、許諾４０２の中で探索される。もし要素が一致しなければ、ステップ４１６で、許諾４０２は無効とみなされる。上記の点に関して、本発明の権利表記処理システム１０は、好ましくは、拡張可能性を達成するため様々な比較を実行できるプラグインを使用するように構成される。要素照合ステップ４５０およびこの機能を提供するようにサポートするサブコンポーネントはプラグインとして実現されるので、新しい要素の照合をサポートするために新しい照合機能を設計および実現することができる。

もし要素が要素照合ステップ４１２で一致すれば、本例では、許諾の完全性が損なわれていないことを検証するため許諾４０２のディジタル署名が評価される、署名評価ステップ４１４が実行される。この署名評価ステップ４１４も、プラグイン・コンポーネントを使用して実行されてよい。そのようなプラグイン・コンポーネントは、拡張可能性を最大にサポートするため、暗号およびメッセージ・ダイジェストのような、ディジタル署名の評価および検証機能を実行する、プラグ可能コンポーネントを配置するように構成されてよい。もし署名を検証できない場合、許諾４０２はステップ４１６で無効とみなされ、リクエストは、図３の認証ステップ１０３のステップ４９０で認証されない。もし署名を検証できれば、本例のステップ４１８で、許諾４０２は有効とみなされる。

図８を再び参照すると、一度、許諾４０２がステップ４１８で有効とみなされると、本例では、リクエスト４０４の全ての可能な要素が許諾４０２の要素と一致することを確かめるため、許諾解決４２０のサブプロセスが実行される。例示の実施形態の許諾解決４２０のサブプロセスに含まれるステップは、図１０および図１１に示される。図１０を参照すると、許諾解決４２０のサブプロセスは、要素の全ての順列が考慮される変形（ｍｕｔａｔｉｏｎ）と照合ステップ４２２を含む。一例としての、変形と照合ステップ４２２の更なる詳細は、図１１に示され、図１１では、許諾４０２およびリクエスト４０４の要素が示される。図３、図１０、および図１１を参照すると、リクエスト４０４の要素は、変形と照合ステップ４２２の間に展開され、変分およびその変形が要素セット４２４の中に提供される。もし一致が発見されなければ、ステップ４２７で解決が提供されず、また、権利表記ライフサイクル１００の認証プロセス段階１３０のステップ４９０で、リクエスト４０４が認証されない。もし可能な一致が発見されるならば、以下で説明されるように、インスタンス・データ結合（バインド）ステップ４２６が実行される。

本例のインスタンス・データ結合ステップ４２６において、要素セット４２４として設定されたリクエスト４０４の要素の変分および変形の中で許諾４０２の１つまたは複数の要素と一致するものが、インスタンス・データに基づいて結合され、照合および結合要素セット４２８へ分離される。図１１の例示の実施形態で示されるように、許諾４０２は、許諾される本人が、その識別情報に文字「Ａ」を有する人物、次に「ボブ（Ｂｏｂ）」として識別される人物、次に識別情報に文字「Ｃ」を有する人物を含むようにリストされた要素を有するかも知れない。リクエスト４０４は、行使する本人を、「アリス（Ａｌｉｃｅ）」、次に「ボブ（Ｂｏｂ）」、次に「チャールズ（Ｃｈａｒｌｅｓ）」のリストとして有するかも知れない。結果として提供される、組み合わせ可能なリクエスト４０４の要素の順列は、要素セット４２４で示される。注意すべきは、要素セット４２４が、アリス、ボブ、およびチャールスの全ての可能な順列のセットではないことである。要素セット４２４は、ボブが第２の位置にある可能な組み合わせのみを含む。なぜなら、ボブは、変数要素ではなく、許諾４０２で設定されるように第２の位置で提供されなければならないからである。本例では、インスタンス・データ結合ステップ４２６の間に、要素セット４２４の中に設定された各々の可能な組み合わせが、許諾４０２の中に設定された権利表記「全てのＡ」、「ボブ（Ｂｏｂ）」、および「全てのＣ」に対して評価され、組み合わせおよび結合セット４２８を生成し、これは結合された解決４２９として示される。

注意すべきこととして、説明された許諾解決４２０の例示的サブプロセスは、許諾４０２の要素が、認証のために解決される変数を必ずしも必要としないことである。許諾解決４２０のサブプロセスは、変数の解決を必要としない許諾へ同じように適用されてよい。更に注意すべきこととして、好ましい実施形態では、前述した変形と照合４２２並びにインスタンス・データ結合４２６のサブプロセスを実行するために使用されるコンポーネントは、好ましくは、新しい権利表記の拡張をサポートするために置換または付加することのできるプラグイン・コンポーネントとして実現される。

図８の例示的な実施形態を再び参照すると、許諾照合サブプロセス４３０が次に実行される。許諾照合サブプロセス４３０は、組み合わせおよび結合セット４２８の各々の要素を、評価された、即ち、許諾４０２から取り出され結合および完全に解決された許諾と照合する。許諾は、全ての変数および表記が、許諾４０２からのデータでインスタンス化され評価されたとき、結合および完全に解決されたとされる。もし許諾４０２と組み合わせおよび結合セット４２８との間に一致する要素が存在しなければ、リクエストは、図３で示される権利表記ライフサイクル１００の認証ステップ１０３のステップ４９０で認証されない。もちろん、許諾照合サブプロセス４３０からの結果は、許諾４０２の要素と完全に一致する１つまたは複数の要素を含むこともある。そのような場合、リクエストは、それに従って認証される。たとえば、もしリクエスト４０４の一致する要素および許諾４０２が条件を与えなければ、ステップ４７０で示されるように、認証は無条件で発行される。しかし、もし許諾４０２が条件を与えれば、ステップ４８０で示されるように、条件付き認証が行われる。

ここで再び、留意すべきことは、図８の前述したプロセス、および図９並びに図１０のサブプロセスは、単なる例として提供され、他の実施形態では修正または変更されて、図示および説明されたものとは異なったプロセス順序およびステップを有してよいことである。たとえば、認証プロセス段階１３０において、署名評価ステップ４１４を有する許諾評価サブプロセス４１０は、認証プロセス段階１３０の任意の時点、たとえば、許諾解決サブプロセス４２０および／または許諾照合サブプロセス４３０の前または後に実行されてよい。もちろん、他の実施形態でも、プロセスおよびサブプロセスに対して他の変更が行われてよい。

図３を再び参照すると、権利表記ライフサイクル１００の確認プロセス段階１０４は、図１および図２について説明したように、バリデータ２０に、権利表記１０４の中で識別されたディジタル・リソースの消費を許す前に、権利表記１０４の中で設定された条件の満足を検証することを要求する。したがって、付録Ａで設定されたＸｒＭＬ（商標）ライセンス５０のｅブックの例を参照すると、ｅブックの使用に課される条件付きの権利表記は、ユーザのディジタル・キーの検証および２５．９９ドルの支払いである。これらの条件の双方は、関連づけられた権利がユーザへ許諾される前に確認されなければならない。要求される支払いを定義する付録ＡのＸｒＭＬ（商標）ライセンス５０の部分は、次のとおりである。

＜ｓｘ：ｆｅｅ＞
＜ｓｘ：ｐａｙｍｅｎｔＦｌａｔ＞
＜ｓｘ：ｒａｔｅ ｃｕｒｒｅｎｃｙ＝“ＵＳＤ”＞２５．９９＜／ｓｘ：ｒａｔｅ＞
＜ｓｘ：ｐａｙｍｅｎｔＲｅｃｏｒｄ＞
＜ｓｘ：ｓｔａｔｅＲｅｆｅｒｅｎｃｅ＞
＜ｕｄｄｉ＞
＜ｓｅｒｖｉｃｅＫｅｙ＞
＜ｕｕｉｄ＞Ｄ０４９５１Ｅ４−３３２Ｃ−４６９３−Ｂ７ＤＢ−Ｄ３Ｄ１Ｄ１Ｃ２０８４４＜／ｕｕｉｄ＞
＜／ｓｅｒｖｉｃｅＫｅｙ＞
＜／ｕｄｄｉ＞
＜／ｓｘ：ｓｔａｔｅＲｅｆｅｒｅｎｃｅ＞
＜／ｓｘ：ｐａｙｍｅｎｔＲｅｃｏｒｄ＞
＜／ｓｘ：ｐａｙｍｅｎｔＦｌａｔ＞
＜／ｓｘ：ｆｅｅ＞
この例で、バリデータ２０は、確認プロセス段階１４０の間に、サービス・キーの下位要素で指定された識別子「Ｄ０４９５１Ｅ４−３３２Ｃ−４６９３−Ｂ７ＤＢ−Ｄ３Ｄ１Ｄ１Ｃ２０８４４」を使用して、好ましい支払いサービスによって２５．９９ドルの料金を処理する。一度、支払いが認証されると、バリデータ２０は、肯定的な結果を返し、許諾の条件の遵守を表示する。一度、全ての他の条件が同じようにしてバリデータ２０によって確認されると、許諾の中で設定された関連の権利はユーザへ許諾される。付録Ａで設定された例示的なライセンス５０において、権利は次のとおりである。

＜！−−再生（閲覧）する権利が許諾される−−＞
＜ｇｒａｎｔ＞
＜ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｌｏｃａｔｏｒ＞
＜ｃｘ：ｎｏｎＳｅｃｕｒｅＩｎｄｉｒｅｃｔ ＵＲＩ＝“ｈｔｔｐ：／／ｗｗｗ．ｃｏｎｔｅｎｔｇｕａｒｄ．ｃｏｍ／ｓａｍｐｌｅｓ／ｅＢｏｏｋ” Ｔｙｐｅ＝“ＵＲＬ” ／＞
＜／ｃｘ：ｌｏｃａｔｏｒ＞
＜／ｃｘ： ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｐｌａｙ／＞
＜／ｇｒａｎｔ＞

＜！−−印刷する権利が許諾される−−＞
＜ｇｒａｎｔ＞
＜ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｌｏｃａｔｏｒ＞
＜ｃｘ：ｎｏｎＳｅｃｕｒｅＩｎｄｉｒｅｃｔ ＵＲＩ＝“ｈｔｔｐ：／／ｗｗｗ．ｃｏｎｔｅｎｔｇｕａｒｄ．ｃｏｍ／ｓａｍｐｌｅｓ／ｅＢｏｏｋ” Ｔｙｐｅ＝“ＵＲＬ” ／＞
＜／ｃｘ：ｌｏｃａｔｏｒ＞
＜／ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｐｒｉｎｔ／＞
＜／ｇｒａｎｔ＞

＜！−−複写する権利が許諾される−−＞
＜ｇｒａｎｔ＞
＜ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｌｏｃａｔｏｒ＞
＜ｃｘ：ｎｏｎＳｅｃｕｒｅＩｎｄｉｒｅｃｔ ＵＲＩ＝“ｈｔｔｐ：／／ｗｗｗ．ｃｏｎｔｅｎｔｇｕａｒｄ．ｃｏｍ／ｓａｍｐｌｅｓ／ｅＢｏｏｋ” Ｔｙｐｅ＝“ＵＲＬ”／＞
＜／ｃｘ：ｌｏｃａｔｏｒ＞
＜／ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｃｏｐｙ／＞
＜／ｇｒａｎｔ＞
＜／ｇｒａｎｔＧｒｏｕｐ＞
上記の説明によって、本発明の１つの実施形態に従った権利表記処理システムは、文法ベースの権利表記を生成、変更、認証、および確認するために使用される新規および有利なシステムを提供することが明かであろう。説明されたように、権利表記処理システムは、拡張可能ポイントを備えた拡張可能アーキテクチャによって実現されてよく、拡張可能アーキテクチャは、権利表記の意味または文法を変更することなく、新しい構文の付加を可能にし、新しい権利表記への適応を可能にする。この拡張可能性は、インタープリタおよびバリデータのような権利表記処理システムのコンポーネントを、プラグイン・コンポーネントとして実現するのが好ましい。

本発明に従った様々な実施形態が図示および説明されたが、本発明はそれらに限定されないことを理解されたい。本発明は、当業者によって変更、修正、および応用されてよい。したがって、本発明は、これまでに図示および説明された詳細部分に限定されず、添付の請求項および法的な相当物によって規定されるような全ての変更および修正を含む。

付録Ａ

対象「ｅブック」を閲覧、印刷、および複写する無制限の権利を、本人またはその他の認証された人物へ２５．９９ドルの均一料金で許諾する例示的な権利表記。（ライセンス５０）

＜ｌｉｃｅｎｓｅ＞
＜ｇｒａｎｔ＞
＜ｇｒａｎｔＧｒｏｕｐ＞
＜ｄｓｉｇ：ｋｅｙＶａｌｕｅ＞
＜ｄｓｉｇ：ＲＳＡＫｅｙＶａｌｕｅ＞
＜ｄｓｉｇ：Ｍｏｄｕｌｕｓ＞
Ｉｄｖｙｐｊａｄ７ＸｏａＹｈｕ９ｔＸＡＹＸａＥＮｆＳ８ｌｉ０ＶｖＷＨＢＸｖｓ５ｎＧｌｙＳｗ７ｅｘｕＤＯｖ２ｏｌｑｎＮａｐＨｔｚ９ＯｖｉｕｐＺＲＱ／ｎＥａ１ｉ＋６ＴＳＲｕＧｓｗ＝＝
＜ｄｓｉｇ：Ｍｏｄｕｌｕｓ＞
＜／ｄｓｉｇ：ＲＳＡＫｅｙＶａｌｕｅ＞
＜／ｄｓｉｇ：ｋｅｙＶａｌｕｅ＞
＜／ｋｅｙＨｏｌｄｅｒ＞
＜！−−再生（閲覧）する権利が許諾される−−＞
＜ｇｒａｎｔ＞
＜ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｌｏｃａｔｏｒ＞
＜ｃｘ：ｎｏｎＳｅｃｕｒｅＩｎｄｉｒｅｃｔ ＵＲＩ＝“ｈｔｔｐ：／／ｗｗｗ．ｃｏｎｔｅｎｔｇｕａｒｄ．ｃｏｍ／ｓａｍｐｌｅｓ／ｅＢｏｏｋ” Ｔｙｐｅ＝“ＵＲＬ” ／＞
＜／ｃｘ：ｌｏｃａｔｏｒ＞
＜／ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｐｌａｙ／＞
＜／ｇｒａｎｔ＞
＜！−−印刷する権利が許諾される−−＞
＜ｇｒａｎｔ＞
＜ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｌｏｃａｔｏｒ＞
＜ｃｘ：ｎｏｎＳｅｃｕｒｅＩｎｄｉｒｅｃｔ ＵＲＩ＝“ｈｔｔｐ：／／ｗｗｗ．ｃｏｎｔｅｎｔｇｕａｒｄ．ｃｏｍ／ｓａｍｐｌｅｓ／ｅＢｏｏｋ” Ｔｙｐｅ＝“ＵＲＬ” ／＞
＜／ｃｘ：ｌｏｃａｔｏｒ＞
＜／ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｐｒｉｎｔ＞
＜／ｇｒａｎｔ＞
＜！−−複写する権利が許諾される−−＞
＜ｇｒａｎｔ＞
＜ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｌｏｃａｔｏｒ＞
＜ｃｘ：ｎｏｎＳｅｃｕｒｅＩｎｄｉｒｅｃｔ ＵＲＩ＝“ｈｔｔｐ：／／ｗｗｗ．ｃｏｎｔｅｎｔｇｕａｒｄ．ｃｏｍ／ｓａｍｐｌｅｓ／ｅＢｏｏｋ” Ｔｙｐｅ＝“ＵＲＬ” ／＞
＜／ｃｘ：ｌｏｃａｔｏｒ＞
＜／ｃｘ：ｄｉｇｉｔａｌＷｏｒｋ＞
＜ｃｘ：ｃｏｐｙ／＞
＜／ｇｒａｎｔ＞
＜／ｇｒａｎｔＧｒｏｕｐ＞

＜ｓｘ：ｆｅｅ＞
＜ｓｘ：ｐａｙｍｅｎｔＦｌａｔ＞
＜ｓｘ：ｒａｔｅ ｃｕｒｒｅｎｃｙ＝“ＵＳＤ”＞２５．９９＜／ｓｘ：ｒａｔｅ＞
＜ｓｘ：ｐａｙｍｅｎｔＲｅｃｏｒｄ＞
＜ｓｘ：ｓｔａｔｅＲｅｆｅｒｅｎｃｅ＞
＜ｕｄｄｉ＞
＜ｓｅｒｖｉｃｅＫｅｙ＞
＜ｕｕｉｄ＞Ｄ０４９５１Ｅ４−３３２Ｃ−４６９３−Ｂ７ＤＢ−Ｄ３Ｄ１Ｄ１Ｃ２０８４４＜／ｕｕｉｄ＞
＜／ｓｅｒｖｉｃｅＫｅｙ＞
＜／ｕｄｄｉ＞
＜／ｓｘ：ｓｔａｔｅＲｅｆｅｒｅｎｃｅ＞
＜／ｓｘ：ｐａｙｍｅｎｔＲｅｃｏｒｄ＞
＜／ｓｘ：：ｐａｙｍｅｎｔＦｌａｔ＞
＜／ｓｘ：ｆｅｅ＞
＜／ｇｒａｎｔ＞

本発明の１つの実施形態に従った拡張可能な権利表記処理システムのブロック図である。 図１の拡張可能な権利表記処理システムが使用されているときのブロック図である。 本発明の１つの実施形態に従った権利表記ライフサイクルの概略図である。 図３の権利表記ライフサイクルにおける権利表記生成プロセス段階の概略図である。 権利表記を入力として使用する権利表記の生成を示す概略図である。 図３の権利表記ライフサイクルにおける権利表記変更プロセス段階の概略図である。 権利表記変更プロセス段階の間の権利表記の変更を示す概略図である。 図３の権利表記ライフサイクルにおける権利表記認証プロセス段階の流れ図である。 図３の権利表記ライフサイクルの認証プロセス段階における許諾確認サブプロセスを示す流れ図である。 図３の権利表記ライフサイクルの認証プロセス段階における許諾解決サブプロセスを示す流れ図である。 例示的データを使用して図１０の許諾解決サブプロセスを示す概略図である。 権利マネジメント・システムの概略図である。 アイテムの概略図である。

Claims (14)

1. リソースに関連づけられた使用権を本人のために要求するリクエストと、リソースに関連づけられた使用権を本人へ発行する許諾と、を各々含む複数種類の権利表記をコンピュータにより処理する方法であって、前記方法は前記コンピュータに、
   少なくとも一つのプラグイン・コンポーネントを、前記プラグイン・コンポーネントが認証できる権利表記と共に拡張可能フレームワークへ登録し、
   所望の権利表記の中に設定された使用権へのリクエストを認証するための前記フレームワークへのプログラム呼び出しを受け取り、
   前記登録された権利表記に基づいて、前記所望の権利表記の中に設定された前記リクエストの各々を認証できる少なくとも１つのプラグイン・コンポーネントを検出し、
   前記検出されたプラグイン・コンポーネントを呼び出し、
   前記呼び出されたプラグイン・コンポーネントにより、前記許諾と前記リクエストとを比較し、前記許諾と前記リクエストとに含まれるリソース、使用権、及び本人が各々一致する場合に前記リクエストを前記許諾に対して認証し、
   前記リクエストが前記許諾によって認証されるかどうかを示す認証の結果を返却する、
   ステップを実行させる方法。
2. 前記認証の結果を返却する前記ステップが、前記リクエストを認証すること、前記リクエストを条件付きで認証すること、前記リクエストを認証しないこと、の少なくとも１つを含む、請求項１に記載の方法。
3. 前記認証の結果を返却する前記ステップが前記リクエストを条件付きで認証することを含み、前記要求された使用権が前記許諾の中で設定された少なくとも１つの条件を付けて認証される場合、前記条件に関する関連データを使用して、前記許諾の中で設定された条件が満足されていると判断するステップをさらに含む、請求項２に記載の方法。
4. 前記認証の結果を返却する前記ステップが、
   前記リクエストおよび前記許諾の前記使用権、前記リソース、および前記本人が相互に一致した場合、前記リクエストを認証すること、
   前記リクエストおよび前記許諾の前記使用権、前記リソース、および前記本人が相互に一致し、前記許諾が更に少なくとも１つの条件を含む場合、前記リクエストを条件付きで認証すること、
   前記リクエストおよび前記許諾の前記使用権、前記リソース、および前記本人が相互に一致しない場合、前記リクエストを認証しないこと、
   の少なくとも１つを含む、請求項１に記載の方法。
5. 少なくとも１つの新しい権利表記を処理するステップをさらに実行させる、請求項１に記載の方法。
6. 少なくとも１つの新しい権利表記を認証する新しいプラグイン・コンポーネントを付加するステップをさらに実行させる、請求項５に記載の方法。
7. 少なくとも１つの新しい権利表記が、新しいリクエストおよび新しい許諾を含み、更に、前記新しいプラグイン・コンポーネントを使用して、前記新しいリクエストを前記新しい許諾に対して認証するステップを実行させる、請求項６に記載の方法。
8. 複数種類の権利表記を処理する拡張可能な文法ベースの権利表記システムであって、
   前記複数種類の権利表記の少なくとも１つが各々、リソースに関連づけられた使用権及び使用権が許諾される本人を含む許諾と、リソースに関連づけられた使用権及び前記リソースの使用を要求する本人を含むリクエストと、を含み、前記権利表記システムが、
   前記文法へ拡張部分を付加する少なくとも１つの拡張可能ポイントを備えた拡張可能アーキテクチャを有するフレームワークと、
   前記複数種類の権利表記を認証する少なくとも１つのインタープリタと、
   前記複数種類の権利表記の中に設定された少なくとも１つの条件が満足されているかどうかを判断する、少なくとも１つのバリデータと、
   を含み、
   前記フレームワークが、
   前記少なくとも１つのインタープリタ及び前記少なくとも１つのバリデータが認証又は判断できる権利表記を登録する登録手段と、
   アプリケーションからの所望の権利表記認証のためのプログラム呼び出しに応じて、前記登録された権利表記に基づき、所望の権利表記を認証及び判断できるインタープリタ及びバリデータを呼び出す呼び出し手段と、を含み、
   前記インタープリタは、前記フレームワークから呼び出されると、前記フレームワークから前記所望の権利表記を受け取り、前記所望の権利表記に含まれる許諾とリクエストとを比較し、前記許諾と前記リクエストとに含まれるリソース、使用権、及び本人が各々一致する場合に前記リクエストを認証し、
   前記バリデータは、前記インタープリタによる承認において前記許諾が満足すべき少なくとも１つの条件を含む場合、前記フレームワークから呼び出されると、前記少なくとも１つの条件が満足されているかどうかを判断し、
   前記拡張部分が新しい権利表記の意味および構文を定義して、前記新しい権利表記を処理する、システム。
9. 前記少なくとも１つのインタープリタの各々がプラグイン・サブコンポーネントとして実現される、請求項８に記載のシステム。
10. 前記少なくとも１つのインタープリタが、前記複数種類の権利表記の少なくとも１つの評価を可能にする少なくとも１つのプラグイン・サブコンポーネントを含む、請求項８に記載のシステム。
11. 前記インタープリタが、追加のプラグイン・サブコンポーネントを付加することによって拡張され、前記追加のプラグイン・サブコンポーネントが新しい権利表記を認証する、請求項１０に記載のシステム。
12. 前記少なくとも１つのバリデータが各々プラグイン・コンポーネントとして実現され、システムが、更に、新しい権利表記の中に設定された条件が満足されているかどうかを判断する追加のバリデータを含む、請求項８に記載のシステム。
13. 前記所望の権利表記を認証できるプラグイン・サブコンポーネントがフレームワークに登録されていない場合に、前記所望の権利表記を認証できるプラグイン・サブコンポーネントを追加するステップをさらに実行させる、請求項１に記載の方法。
14. 前記所望の権利表記を認証できるインタープリタがフレームワークに登録されていない場合に、前記所望の権利表記を認証できるインタープリタを追加することによって、前記権利表記システムが拡張される、請求項８に記載のシステム。

Images