JP4898966B2 - 共有状態変数を用いる権利のオファー及び許諾のための方法 - Google Patents

Description

本発明は一般的には権利のオファー（提案）と許諾に関し、より詳しくは、共有状態変数を用いて権利をオファーしたり許諾したりする方法、システムおよびデバイスに関する。

デジタル時代の到来によって、著作権を有する情報、限定されたサービスおよび価値あるリソースの所有権、アクセスおよび制御に関する関心が高まっている。コンピュータと、セルラー電話や、ポケベル、ＰＤＡ、電子ブックリーダー等の他の電子機器とが、急速に進歩し広範囲にわたって展開され、また、このようなデバイスが、インターネットや、イントラネット、他のネットワークを含む通信リンクを介して相互接続されている。このような相互接続されたデバイスは、コンテンツの公開や、サービスの提供や、リソースの利用可能性に特に資するものである。

デジタル作品（すなわち、コンピュータで読み取り可能な形態を有する文書や他のコンテンツ）を電子的手段、とくにインターネットを介して広範囲に流通させることを妨げる最も重要な問題点の１つは、デジタル作品の配信と使用に際してコンテンツの所有者の知的財産権を執行する能力が現在のところ欠如していることである。この問題を解決する努力は、「知的財産権管理」（“ＩＰＲＭ”）、「デジタル財産権管理」（“ＤＰＲＭ”）、「知的財産管理」（“ＩＰＭ“）、「権利管理」（“ＲＭ“）および「電子著作権管理」（“ＥＣＭ”）と呼ばれてきたが、本書では「デジタル権管理（ＤＲＭ）」と総称する。ＤＲＭシステムの実効に際しては多くの問題が考えられる。たとえば、認証、認可、会計、支払いと金融決済、権利の指定、権利の検証、権利の執行および文書保護という問題点が取り組まれるべきである。その開示内容を参照してここに組み込む特許文献１、特許文献２、特許文献３、特許文献４および特許文献５には、このような問題点に対処するＤＲＭシステムが開示されている。

機密保護コンテナと高信頼性システム（trusted system）という、２つの基本的な方式が採用されている。「機密保護コンテナ」（または単に暗号化文書）は、ある認可条件の集合が満たされ、いくつかの著作権条項（たとえば、使用のための支払い）が守られるまで、文書のコンテンツを暗号化された状態に保つ方法を提供するものである。これら様々な条件と条項が文書の提供者によって検証された後、この文書はクリアな形態でユーザに対して開放される。Ｃｒｙｐｔｏｌｏｐｅｓ（商標）やＤｉｇｉｂｏｘｅｓなどの商品はこのカテゴリに入る。機密保護コンテナ方式は、安全でないチャネルを介しての配送に際して文書を保護するソリューションとなるが、合法的なユーザがクリアな文書を得て、次にそれをコンテンツの所有者の知的財産を侵害して使用したり再配信させたりすることを防止するメカニズムは何ら提供しないことは明らかである。

「高信頼性システム」方式では、システム全体が、文書を無認可で使用したり配信させたりすることを防止することに責任を持つ。トラステッドシステムを構築するには、通常、機密保護プロセッサ、機密保護記憶デバイスおよび機密保護レンダリングデバイスなどのハードウエアを新たに導入しなければならない。また、高信頼性システム上で稼動するすべてのソフトウエアアプリケーションが、信頼するに足ることを証明する必要がある。改竄防止性を有する高信頼性システムを構築することは既存の技術にとっては実に困難な課題であるが、その一方で、現在のマーケットの傾向は、ブラウザを用いてＷｅｂにアクセスするＰＣやワークステーションなどのオープンな非信頼性システムがデジタル作品にアクセスするために用いられるシステムとして支配的となることを示唆している。この意味で、利用者が多いオペレーティングシステム（たとえば、Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ、ＵＮＩＸ（登録商標））やブラウザなどのレンダリングアプリケーションを備えたＰＣやワークステーションなどの既存の計算環境は、高信頼性システムではなく、そのアーキテクチャを大幅に変更しない限り信頼性あるものとすることは不可能である。もちろん、アーキテクチャを変更することは、Ｗｅｂの主要な目的、すなわち柔軟性と互換性を損なうものである。

一部のＤＲＭシステムでは、コンテンツの所有者が、使用権と条件を指定して、これらをコンテンツと関連付けることを可能としている。これらの使用権は、コンテンツの受信者がこのコンテンツをどのように使用することが可能であるかを制御するものである。通常は、コンテンツの配信者または消費者が特定のコンテンツの指定と注文を完了すると、このコンテンツはなんらかのコンテンツレポジトリから電子的に、または一般的な搬送手段（キャリア）を介して送られる有形のメディアなどの従来の流通チャネルを介して、受信者に対して供給される。たとえば配信者または消費者のような受信者が用いる対応するＤＲＭシステムは次いで、コンテンツに関連付けられている権利と条件を解釈し、これらを用いてコンテンツをどのように配信および／または使用するかを制御する。使用権の例としては、コンテンツの閲覧、印刷および抽出、ならびにコンテンツの配信、再パッケージングおよびコンテンツの貸し出しがある。関連付けられる条件には、支払い、識別、時間期間等の、権利に付随する任意の条項がありうる。

特許文献２には、デジタル文書の配信を制御するシステムが開示されている。レンダリングデバイスは各々が、自身と関連付けられたレポジトリを有している。使用トランザクションステップの所定の集合によって、文書に関連付けられている使用権を執行する際にレポジトリが用いるプロトコル（手続）を定義する。使用権は文書のコンテンツに最後まで付きまとう。使用権は、閲覧のみ、１回の使用のみ、配信等の、様々な用い方を許可可能とすることができる。使用権は、支払いや他の条件次第とすることが可能である。

米国特許第５，５３０，２３５号明細書 米国特許第５，６３４，０１２号明細書 米国特許第５，７１５，４０３号明細書 米国特許第５，６３８，４４３号明細書 米国特許第５，６２９，９８０号明細書

しかしながら、コンテンツを関連する使用権と条件だけがコンテンツの所有者または他の権利許諾者によって指定される上記のパラダイムには制限が付きまとう。コンテンツのエンドユーザ、消費者または配信者がいったんコンテンツを関連する使用権および条件に沿って購入すると、配信の連鎖における次の受信者に対して合法的にこれを受け渡す手段がない。また、この関連する使用権には、他の権利、すなわち、修正、転送、オファー（提案）、許諾、取得、移転（譲渡）、委託、追跡、放棄、交換、移送、行使、取り消し等の派生した権利を指定する用意はない。一般的なコンテンツ配信モデルにはしばしば、多層構造の配信と使用の連鎖が含まれる。周知のＤＲＭシステムでは、コンテンツの配信と使用の連鎖に連なるすべての関係者に対する権利と条件を規定することは支援されていない。したがって、コンテンツの所有者自身が配信の連鎖の当事者各々との関係性がない限り、コンテンツを商業的に利用することは困難である。

本発明の例示的な態様には、コンテンツと関連付けられるように構成された権利を共有するための方法、システムおよびデバイスが含まれ、前記方法とシステムは、コンテンツに対して使用権及びメタ権利のうちの少なくとも１つを生成し、前記コンテンツの使用法を、使用権を用いて定義し、前記コンテンツの権利移転（譲渡）方法をメタ権利によって定義することを含んでいる。前記デバイスは、コンテンツに対する使用権とメタ権利の少なくとも一方を受信し、前記コンテンツの使用法を使用権により解釈し、前記コンテンツの権利移転の仕方をメタ権利によって解釈することを含んでいる。前記使用権またはメタ権利は、１つ以上の権利が共有する少なくとも１つの状態変数を含んでいる。
本発明の一態様は、複数のデバイスの間で共有するため、第１メタ権利から権利を派生する方法であって、前記第１メタ権利は、コンテンツと関係付けられるとともに、複数のデバイスの少なくとも一つがコンテンツに対する使用権もしくは第２メタ権利を派生するのを許可する機械読み取り可能な表現であって、前記第１メタ権利は、前記複数のデバイスの少なくとも一つのユーザに固有のＩＤが割り当てられる状態変数と関係付けられ、該状態変数はリモート権利状態サーバの物理アドレスと関連付けられるものであり、前記方法は、前記第１メタ権利とコンテンツを、前記複数のデバイスの内の第１のデバイス上に記憶し、前記第１のデバイスが、コンテンツを前記複数のデバイスの内の第２のデバイスに移転するリクエストを受け、前記第１のデバイスが、前記第１メタ権利を行使し、前記第１のデバイスのライセンスマネージャが、前記第１メタ権利に基づいて、前記状態変数を含む一つ以上の権利を派生し、前記第１のデバイスが、前記第２のデバイスに前記派生した権利とコンテンツを移転し、これにより第１のデバイスと第２のデバイス間での権利の共有を許可することを含むものであり、該移転のステップは更に、前記第１のデバイスが、前記リモート権利状態サーバに、権利の移転を通知し、前記第１のデバイスが、前記第２のデバイスに、前記状態変数の管理を移転することを含む。

本発明のさらに他の態様、特徴および長所は、本発明を実行するために考えられる最良の形態を含む、多くの例示的な実施形態と実施例を単純に解説している以下の詳細な説明を読めば容易に理解されるであろう。本発明はまた、他にも様々な実施形態が可能であり、本発明の精神と範囲から逸脱することなく、いくつかの詳細を修正して様々な態様とすることが可能である。したがって、図面と説明は、本質的に例示的なものであり、限定的なものであるとは考えるべきではない。

コンテンツ配信のための三層モデルの概略図である。 図１のモデルにおける権利のオファーと許諾を示す概略図である。 権利を生成し、発行し、行使するための、単純な供給者／消費者プッシュモデルの概略図である。 権利を生成し、発行し、行使するための、単純な供給者／消費者プルモデルの概略図である。 好ましい実施形態による権利オファー／許諾アーキテクチャのブロック図である。 権利供給者と権利消費者間でプッシュモデルとプルモデルをそれぞれ用いて権利をオファーする例と許諾する例のワークフローチャートである。 権利供給者と権利消費者間でプッシュモデルとプルモデルをそれぞれ用いて権利をオファーする例と許諾する例のワークフローチャートである。 好ましい実施形態による権利オファー生成プロセスのフローチャートである。 好ましい実施形態による権利オファー検討プロセスのフローチャートである。 好ましい実施形態による権利オファーカスタマイズプロセスのフローチャートである。 好ましい実施形態と関連して利用されるＤＲＭシステムのブロック図である。 好ましい実施形態の使用権とメタ権利を含んでいるライセンスの例示的な構造のブロック図である。 好ましい実施形態の権利ラベルの概略図である。 権利状態サーバを含んでいる例示的なシステムを示す図である。 独占（排他）的使用権を派生させる際の状態変数を用いる方法を示す図である。 継承した使用権を派生させる際の状態変数を用いる方法を示す図である。 既知の権利受信者の集合によって共有される権利を派生させる際の状態変数を用いる方法を示す図である。 動的な権利受信者の集合によって共有される権利を派生させる際の状態変数を用いる方法を示す図である。 複数の権利により共有される状態を維持する際の状態変数を用いる方法を示す図である。 権利の１つの状態を表すために複数の状態変数を用いる方法を示す図である。 すべての権利が状態と関連しているものではない場合を示す図である。 状態と関連しているすべての権利が共有されたり継承されたりするものではない場合を示す図である。 メタ権利を明示的には含まないオファーに基づく権利共有の場合を示す図である。

本発明の例示的な実施形態は、以下の添付図面を参照して詳細に説明される。

権利をオファーして許諾したりする装置と方法を詳細に説明するに先立って、特定のコンテンツ、サービスまたはその他の品目に対して使用権とメタ権利を指定して行使するために利用することができるＤＲＭシステムを、最初に以下で説明する。

図９に、公開鍵と秘密鍵の対またはその他の識別メカニズムを周知の保護された方法でコンテンツユーザに対して発行する有効化（activation）サーバ２０という形態で、ユーザ有効化コンポーネントを含んでいるＤＲＭシステム１０を示す。通常、ユーザは最初にＤＲＭシステム１０を用いる際に、特定のコンテンツフォーマット用のレンダリングアプリケーションと共一緒に作動するか、またはこれを含んでいるソフトウエアをインストールする。このソフトウエアは、クライアント環境３０、たとえばコンテンツ受信者と関連しているコンピュータにインストールされる。このソフトウエアは、ＤＲＭ１０システムの一部であり、保護されているコンテンツに対する使用権を執行するために用いられる。有効化プロセスの間、いくらかの情報が有効化サーバ２０とクライアント環境３０間で交換される。クライアントコンポーネント６０は好ましくは改竄耐性があり、有効化サーバ２０が発行した公開鍵と秘密鍵ならびに、たとえばレンダリングコンポーネントなどの他のコンポーネントから成る集合を含んでいる。

権利ラベル４０はコンテンツ４２と関連付けられており、対応する条件が満たされた場合に、受信者、すなわち権利の消費者にとって利用可能な使用権とメタ権利を指定する。ライセンスサーバ５０は暗号鍵を管理し、保護されたコンテンツ４２のライセンス５２を発行する。ライセンス５２は、使用権とメタ権利を含む権利のエンドユーザに対する実際の許諾を具体化するものである。たとえば、権利のオファー４０によって、ユーザに５ドルの料金でコンテンツを閲覧し、１０ドルの料金でコンテンツを印刷することを許可することができ、または、ユーザに、たとえば以下に説明するメタ権利という概念を利用することによって別のユーザに対して権利をオファーすることを許可することができる。５ドルの料金が支払われれば、閲覧権利に対するライセンス５２を発行することが可能である。クライアントコンポーネント６０は、ライセンス中に指定されている使用権とメタ権利を含む権利を解釈して執行する。権利ラベル４０とライセンス５２を以下に詳述する。

図１１に、好ましい実施形態による権利ラベル４０を示す。権利ラベル４０は、複数の権利オプション４４を含む。権利オプション４４の各々が、使用権４４ａ、条件４４ｂおよびコンテンツ指定４４ｃを含んでいる。コンテンツ指定４４ｃは、権利のオファー４４と関連するコンテンツ４２を参照したり、検出したり、別様に指定したりする何らかのメカニズムを含むことができる。

図１０に示すように、ライセンス５２は、ライセンス５２ａ、許諾５２ｂおよびデジタル署名５２ｃを含んでいる。許諾５２ｂは、ラベルから選択された、許諾された使用権および／メタ権利を含んでいる。許諾の構造もまた、指定された使用権および／メタ権利が許諾される１人以上の主要者、条件のリスト、およびライセンスを執行するために必要な状態変数を含んでいる。使用権と同様に、許諾されたメタ権利のアクセスと行使は、以下に説明するように条件リストと状態変数によって制御される。

クリアな（保護されていない）コンテンツは、コンテンツ公開者、コンテンツ配信者、コンテンツサービス提供者またはその他のあらゆる当事者に関連するコンピュータ７０にインストールされた、文書準備アプリケーション７２によって作成可能である。コンテンツの準備（作成）は、コンテンツ４２を使用し配信させることができる使用権、メタ権利および条件を指定し、権利ラベル４０をコンテンツ４２と関連付け、なんらかの暗号アルゴリズムでコンテンツ４２を保護することから成っている。ＸｒＭＬなどの権利記述言語を用いて、権利と条件を指定することが可能である。しかしながら、使用権とメタ権利は、どのような仕方で指定してもよい。また、権利は、単にコンテンツを関連している所定の仕様やテンプレートという形態でもあり得る。したがって、権利を指定するプロセスとは、権利をコンテンツと関連付けるなんらかのプロセスのことである。コンテンツ４２と関連している権利ラベル４０と、コンテンツを暗号化するために用いられた暗号鍵とは、ライセンスサーバ５０に送信されることができる。

権利は、配信権などの移転権を指定することが可能であり、権利を他者に許諾したり、権利を派生させたりすることを許可することができる。このような権利は「メタ権利」と呼ばれる。メタ権利とは、他のメタ権利または使用権を操作したり、修正したり、別様に派生したりすべき権利のことである。メタ権利は、使用権に対する使用権と考えることができる。メタ権利には、他者に対して／他者からの、使用権をオファー、許諾、取得、移転（譲渡）、委託、追跡、放棄、交換、および取り消し等を行う権利が含まれ得る。メタ権利は、他の権利と関連する条件の内のいずれかを修正する権利を含むことが可能である。たとえば、メタ権利は、特定の権利の範囲を拡大したり減少させたりする権利であってもよい。メタ権利はまた、権利の有効期限を拡大したり減少させたりする権利であってもよい。

多くの場合、権利に指定された使用法を行使するためには条件を満たさなければならない。たとえば条件は、料金の支払いや、個人的データの提出や、その他の使用法の行使を許可する前のなんらかの所望の要件であってよい。たとえば「アクセス条件」もまた条件であり得るが、アクセス条件は、たとえば、大学の学生や読書クラブのメンバーなどの特定のユーザグループに適用され得る。言い換えれば、条件とは、ユーザが特定の人物又は特定のグループのメンバーであることである。権利と条件は、互いに別個のエンティティ（実体）であるか、又は組み合わせることが可能である。 状態変数は、潜在的にダイナミック（動的）な状態条件を追跡するものである。状態変数とは、品目のステータス、使用権、ライセンスまたはその他のダイナミックな条件を表す値を有する変数のことである。状態変数は、情報交換所９０のライセンスやサーバ３０の別のデバイスによって、ライセンス５２中の識別メカニズムに基づいて追跡することが可能である。さらに、状態変数の値はある条件で用いることが可能である。たとえば、使用権は、コンテンツ４２を３回印刷する権利であり得る。使用権を行使するたびに、状態変数の値「印刷回数」がインクリメント（増分）される。この例では、状態変数の値が３であれば、条件はもはや満たされず、コンテンツ４２は印刷不可能となる。状態変数の別の例として、時間がある。ライセンス５２の条件として、コンテンツ４２を３０日以内に印刷すること等があってもよい。状態変数を用いて、３０日が満了したか否かを追跡することが可能である。さらに、権利の状態を、状態変数の集合（collection）として追跡することが可能である。変更の集合は、自身の使用履歴を表す使用権の状態である。

ＤＲＭシステム１０の例示的なワークフローを以下に説明する。ユーザなどの受信者は、クライアント環境３０で操作する間、有効化サーバ２０によって有効化されてコンテンツを受信する。この結果、公開鍵と秘密鍵の対（および何らかのユーザ／マシンの固有情報）が、周知の方法でクライアントソフトウエアコンポーネント６０という形態でクライアント環境３０にダウンロードされる。この有効化プロセスは、ライセンスを発行する以前であればいつでも遂行可能である。

ユーザは、保護されているコンテンツ４２を使用したい場合、コンテンツ４２を要求する。たとえば、ユーザは、コンテンツの配信者などの権利の許諾者と関連するＷｅｂサーバ８０上で稼動しているＷｅｂサイトを、クライアント環境３０にインストールされているブラウザを用いてブラウズ（閲覧）して、保護されているコンテンツ４２をダウンロードしようとする。このプロセス中、ユーザは、料金トランザクション（コンテンツの販売の際など）や他のトランザクション（情報の収集など）を含む可能性のある一連のステップを実施してもよい。適切な条件および、料金の徴収やユーザが有効化されたことの検証やその他の前提条件が満たされると、Ｗｅｂサーバ８０は、機密保護ソケットレイヤー（ＳＳＬ）を用いたチャネルなどの機密保護通信チャネルを介してライセンスサーバ５０とを連絡する。すると、ライセンスサーバ５０はコンテンツに対するライセンス５２を生成し、Ｗｅｂサーバ８０は、保護されているコンテンツ４２とライセンス５２の双方をダウンロードさせる。ライセンス５２は、ライセンスサーバ５０または関連するデバイスからダウンロード可能である。コンテンツ４２は、公開者、配信者またはその他の当事者と関連するコンピュータ７０からダウンロード可能である。

次に、クライアント環境３０下のクライアントコンポーネント６０がさらに、ライセンス５２を解釈して、ライセンス５２中で指定されている権利と条件に基づいてコンテンツ４２の使用を許可する。使用権の解釈と行使は一般に周知である。上記のステップは、連続して行われるか、または様々な順序でほぼ同時に行われてもよい。

ＤＲＭシステム１０は、コンテンツ４２のセキュリティ面に対応している。特に、ＤＲＭシステム１０は、ライセンスサーバ５０が発行したライセンス５２を認証してもよい。このような認証をアプリケーション６０が遂行する１つの方法は、このライセンスが信頼可能であるか否かを判定することである。言い換えれば、アプリケーション６０は、デジタル署名５２ｃの暗号署名またはその他のライセンスの識別特徴を検証して確認する機能を有している。上記の有効化ステップ中、クライアント環境３０とライセンスサーバ５０の双方が、有効化されたクライアント環境３０がライセンス５２の書名５２を周知の仕方で検証するための必要とされるコンポーネントなどの他のコンポーネントをも含んでいる改竄防止性を有するソフトウエア「パッケージ」で鍵の集合を受信する。もちろん、上記の例は単にＤＲＭシステムを実効化するための１つの方法に過ぎない。たとえば、ライセンスとコンテンツは、互いに異なったエンティティから配信可能である。また、権利のオファー４０は、コンテンツを作成する当事者とは別の当事者によってコンテンツに関連付けられることが可能である。また、情報交換所９０を用いて、支払いトランザクションを処理し、ライセンスを発行する前に支払いを検証することが可能である。

いずれの権利の集合の場合にも、２種類のエンティティ、すなわち、「供給者」と「消費者」が関与する。供給者の機能は、権利をオファーし、場合によっては許諾することであり、消費者の機能は権利を選択し、場合によっては行使することである。供給者と消費者は双方が、実際には２つ以上のエンティティを表してもよい。一般に、複数のエンティティが複数のエンティティに対してまとめて権利をオファーし許諾してもよい。供給者と消費者は、権利の許諾に関して相互に直接的な関係を持つ、コンテンツ価値の連鎖中の任意の２つのエンティティを表している。価値連鎖の最初の部分では、供給者と消費者は著者と公開者であってもよい。価値連鎖を沿って行くにつれて、供給者と消費者は公開者と別の公開者（コンテンツ集約目的のもの）、公開者と配信者（コンテンツ配信するもの）、配信者と小売店（コンテンツ小売のためのもの）、小売店と消費者（コンテンツを消費するもの）、さらに消費者と別の消費者（コンテンツを超流通（super-distribution）させたりまたは個人的に貸与したりするもの）となっていく。

「権利のオファー（提案）」または「権利オファー」は、消費者（たとえばコンテンツの配信者またはユーザ）がどのようにすれば、コンテンツの特定のインスタンス（実体）とそれに関連する使用権および／またはメタ権利をともに取得することが可能であるかを表現するものである。オファーは金融条項を含んでいてもいなくてもよい。オファーは、単に交渉を始めようとする意思の表現であり、また、そこに記述された条項であれば許諾するという意思の表現である。オファーは、権利ラベルという形態で表現されてよい。「権利の検討」とは、権利の消費者が、オファーされ、場合によっては売買契約されている関連する条項および条件とを検討する、権利許諾のプロセスの一部である。「権利の選択」とは、権利とそれに関連する条項および条件を権利のオファー内容から選択することである。これは、これらの権利とそれに対応する条項および条件とを受け入れるという消費者の意図を示すものである。たとえば、選択は、ラベル４０から１つのオプションを選ぶ動作を含むことが可能である。「権利のカスタマイズ」とは、権利の供給者が権利と条項および条件とを権利消費者の選択内容に基づいて組み立てる、権利許諾のプロセスの一部である。このプロセスの結果は、権利の消費者に受け入れられるべきライセンス案（ドラフトライセンス）でもあり得る。「権利のライセンス」とは、権利の供給者と消費者が受け入れて同意した権利と、場合によっては条件の表現である。これは、権利のオファーと許諾のプロセスの出力である。ライセンスとは、コンテンツまたはその他の品目の使用（場合によってはさらなる配信を含む）を統御する権利を行使することへの許諾である。

上述したように、権利ラベル４０などの権利ラベルは、消費者が選択と交渉（許可されている場合）とを実行することを許可する多くのオプション４４を含んでいる一方、ライセンス５２は消費者が選択して受け入れた権利を含んでいる。ここで、受け入れられた権利には、他者に対してオファーを提示したりオファーを選択したりする権利が含まれてもよい。

配信連鎖モデルの例を図１に示す。この配信連鎖には、コンテンツ供給者１００、配信者１１０およびエンドユーザ１２０が含まれている。もちろん、コンテンツは上述した方法で作成されてよい。コンテンツはすでに図１のモデルで作成されているものと仮定する。図１は、コンテンツの移転を対象としたものであり、この例では、提供者１００がコンテンツを配信者１１０に対して公開する、または配信者１１０からコンテンツを再使用する目的で受信することができることを示している。配信者１１０は次いで、コンテンツをユーザ１２０に配信したり返送コンテンツをユーザ１２０から受信したりすることができる。ユーザ１００はコンテンツを使用することが可能である。多層構造の配信連鎖がどれほど複雑になり得るかをさらに例示すると、供給者１００は他者からコンテンツを収集することができ、配信者１１０は他の配信者から再配信のためにコンテンツを受信することができ、ユーザ１２０は他のユーザとコンテンツを共有可能である。コンテンツの寿命のサイクルには複数の段階があり、また、様々な当事者間には複数の関係があること明らかである。権利の指定は、寿命サイクルの様々な段階と関係において正確で首尾一貫していることが重要であり、多層構造の配信と使用に際してコンテンツを持続的に保護するためには必須である。

図２に、権利の生成、収集、発行、放棄、推進、許諾、解約、委託および行使を含む、同じモデル中での権利の流れを示す。図２のモデルは、同じエンティティ、すなわち、供給者１００、配信者１１０およびユーザ１２０を含んでいる。権利の流れに関して、当事者各々が権利を許諾して受け入れることが可能であることが理解される。ユーザ１２０は、他のユーザから権利を許諾されて受け入れることが可能であり、これはこの例では「委託」と呼ばれるプロセスである。

図２のモデルでは、特定のコンテンツの公開、配信および使用という多くの関係が含まれている。当事者を別様に統合したり分離したりすることによってその他のモデルをこのモデルから派生することが可能である。たとえば、いずれの提供者も配信者となることが可能である。これは「直接公開」であって、著者個々人が、一切の中間的な公開者を介さず自身のコンテンツを配信／販売することが可能となる。さらに、いずれの消費者も潜在的な配信者となることが可能である。これによって、消費者は、コンテンツを相互に渡すことが可能となる。これには、超流通、贈与および個人的貸与が含まれる。「Ｗｅｂコミュニティ」では、すべての人がコンテンツを公開し、配信させ、消費することが可能である。「コンテンツの収集（contents aggregation）」によって、公開者は、他の公開者からのコンテンツを合成して複合した作品とすることが可能である。サイトライセンス及び企業使用によって、消費者間でコンテンツを共有することが可能となる。

一般に、図２に示すすべての権利関係は、図３Ａと図３Ｂに示すように２つの一般的な供給者／消費者モデルによって把握可能である。図３Ａは「プッシュ」モデルを示し、図３Ｂは「プル」モデルを示す。図３Ａに示すプッシュモデルでは、権利の供給者２００が権利のオファーと許諾のプロセスを開始して、権利消費者２１０に対するオファーを生成し、これに対する権利を許諾する。図３Ｂに示すプルモデルでは、権利消費者２１０がプロセスを開始して、権利供給者２００からオファーを要求し、権利を受け入れる。

権利のオファーと許諾の好ましい実施形態のアーキテクチャを図４に示す。アーキテクチャ４００は、コンピュータのハードウエアとソフトウエアの組み合わせとして実現可能であり、権利供給者コンポーネント４０２、権利消費者コンポーネント４３８およびこれら２つのコンポーネントをリンクする通信チャネル４２２を含むことが可能である。たとえば、通信チャネル４２は、インターネット、コンピュータ間コンピュータ直接接続、ＬＡＮ、無線接続等であってよい。供給者コンポーネント４０２は供給者、すなわち権利を行使しようとしている（消費しようとしている）エンティティである消費者が権利を利用できるようにするエンティティと関連している。この供給者は、コンテンツの所有者もしくは提供者、または配信者、もしくは小売業者やＷｅｂサイトのオペレータなどのいずれかの「仲介者」であってよい。消費者コンポーネント４３８は、最終ユーザ（すなわちコンテンツ消費者）または小売業者、問屋、再販業者などの「仲介者」でありうる消費者と関連している。消費者は権利を消費するが、コンテンツを必ずしも使用する（すなわち消費する）わけではないことに留意されたい。供給者コンポーネント４０２と消費者コンポーネント４３８は双方ともが、パソコン、携帯用コンピュータ、モバイル電話、サーバ、ネットワークまたはこれらのいずれかの組み合わせなどのいずれかのタイプのハードウエアデバイスおよび／またはソフトウエアモジュールからなっていてよい。供給者コンポーネント４０２は、消費者に対して権利ラベル４０を生成すると共に、オファーを生成し、ライセンス案を提示し、ライセンス５２を許諾する。消費者コンポーネント４３８は、要求を発行し、権利ラベル４０からオプション４４の選択肢を選び、修正オファーを生成し、ライセンス５２を受け入れる。供給者コンポーネント４０２と消費者コンポーネント４３８は同じデバイス中に組み込み可能であり、通信チャネル４２２は内部チャネルであってもよい。

供給者コンポーネント４０２は、ユーザインタフェースモジュール４０４、通信インタフェースモジュール４２０、アイデンティティモジュール４０６と、供給者の権利の（発行されたライセンスという形態での）レポジトリ４１２と、関連情報管理用のデータベース４１４を含んでいる。ユーザインタフェース４０４は周知の方法で、コンポーネント機能をユーザに対して提示し、ユーザとの相互作用（インタラクション）を受け入れる。通信インタフェース４２２は、供給者コンポーネント４０２と消費者コンポーネント４３８間のメッセージ用の適切なフォーマッティングとプロトコルを提供する。アイデンティティモジュール４０６は、供給者コンポーネント４０２のアイデンティティが消費者コンポーネント４３８によって認証されることを保証し、また、供給者コンポーネント４０２のユーザのパスワード、暗号鍵または生体認証情報のような認証情報を含んでいてもよい。権利レポジトリ４１２は、供給者コンポーネント４０２のユーザに対して許諾された権利を記憶し、内部に記憶されている権利を索引付けし、探索し、更新する機能を含んでいてよい。管理データベース４１４は、権利のオファーと許諾のプロセス中に生成された情報をアーカイブするために用いられる。このような情報には、初期オファー、消費者の選択、場合によっては修正オファー、取り決めおよび最終的なライセンスに関連する情報が含まれる。 消費者コンポーネント４３８は、ユーザインタフェースモジュール４２８、通信インタフェースモジュール４２４、アイデンティティモジュール４２６、消費者権利の（発行されたライセンスという形態での）レポジトリ４３４および関連情報管理用のデータベース４３６を含んでいる。ユーザインタフェース４２４は、ユーザに対するコンポーネントの提示と、ユーザインタラクションの受け入れとを取り扱い、処理する。通信インタフェース４２２は、供給者コンポーネント４０２と消費者コンポーネント４３８間の権利のオファーと許諾のメッセージ用の適切なフォーマッティングとプロトコルを提供する。アイデンティティモジュール４２６は、消費者コンポーネント４３８のアイデンティティが供給者コンポーネント４０２によって認証されることを保証し、ユーザのパスワード、暗号鍵または生体認証情報のような認証情報を含むことができる。権利レポジトリ４３４は、消費者コンポーネント４３８のユーザに対して許諾された権利を記憶し、内部に記憶されている権利を索引付けし、探索し、更新する機能を含んでいてよい。管理データベース４３６は、権利のオファーと許諾のプロセス中に生成された情報をアーカイブするために用いられる。この情報には、オファー４４、消費者の選択、場合によっては修正オファー、取り決めおよびライセンス５２に関連する情報が含まれる。ここで、データベース４３６は、データベース４１４と同じまたはこれと異なった情報が記憶可能であるが、これは、当事者が他の当事者とインタラクト（対話）可能であり、したがって相互に異なったアーカイブ情報を有するためである。

供給者コンポーネント４０２は、オファーを生成するオファー生成モジュール４０８、ライセンスを構成する権利構成モジュール４１０、オファー生成用テンプレートを以前のトランザクションとオファーの共通した形式に基づいて提供するオファーテンプレートモジュール４１８および、過去の消費者の特性と消費者との関係に基づいて権利をカスタマイズし許諾する消費者プロフィールモジュール４１６をも含んでいる。

消費者コンポーネント４３８はまた、オファー中に提示されている権利と条項および条件を理解するためのオファー分析モジュール４３０、オファーに指定されている好ましいオプションを選択する選択実行モジュール４３２、過去と現在の供給者の特性と関係に基づいていずれかの好ましい供給者を記述する供給者優先傾向（選好）モジュール４３８およびオファー中の選択オプションのパターンと興味を提供する選択パターンモジュール４４０をも含んでいる。たとえば、選択範囲パターンモジュール４４０は、好ましい供給者のリストまたは消費者にとって興味のある品目の最低価格のリストを含んでもよい。オファー分析モジュール４３０と選択実行モジュール４３２はそれぞれ１つのモジュールに組み合わせてもよい。

アーキテクチャ４００内で権利をオファーし許諾するプロセスは、供給者コンポーネント４０２と消費者コンポーネント４３８が従うプロトコル（手続）に基づいている。これらのプロトコルは全般的に、オファーとこのオファーの受け入れとから成っている。具体的には、これらのプロトコルは、１つの当事者から別の当事者へのオファーとこのオファーの、オファー対象である人物による受け入れとを含んでいる。いったんオファーが為されたら、受け入れられる前に取り消せる形式とされるか、または全く取り消せないか、オファーするものが定義可能なある条件下でしか取り消せない形式とされることができる。オファーはまた、たとえば受け入れの期限が切れた場合など様々な仕方で期限切れとすることができる。期限が指定されていない場合、オファーは、このオファーの対象事項により、所定の妥当な期間で期限切れとすることができる。雑誌、機関紙、さらには新聞などの定期的に利用可能となるコンテンツの場合、妥当な期間は、たとえば、コンテンツの出版期間次第としてもよい。ストリーミングコンテンツなどの動的に生成または提供されるコンテンツの場合、妥当な期間は、コンテンツが利用可能となる前の任意の時間であってよい。権利供給者は、権利の消費者が拘束される他の受け入れ条項を決定することが可能である。たとえばオファーは、受け入れ（承諾）をｅメールやある種のＷｅｂページインタフェースを介してある形態で返送することを要求してもよい。

図５Ａに、権利許諾のプッシュモデルのプロトコル５００のワークフローを示す。供給者コンポーネント４０２は、たとえば、権利ラベル４０という形態で権利のオファーを場合によっては多くのオプション４４と共に生成し、それを消費者４３８に送る（５１０）。消費者コンポーネント４３８は、このオファーとその可能なオプションとを検討し、供給者コンポーネント４０２に対して権利オファー４４のオプションのいずれかを選択して応答する（５１２）。供給者コンポーネント４０２は、この消費者の応答にしたがって権利をカスタマイズし、消費者コンポーネント４３２のユーザに対してライセンス案という形態でこの権利を発行する（５１４）。

次に、消費者コンポーネント４３８は、このライセンス案が為された上記の選択に対応しているか、或いは受け入れ可能であれば受け入れる（５１６）。受け入れられた（承認された）場合、供給者コンポーネント４０２はライセンス５２を発行し、ライセンス５２を消費者コンポーネントに送信する（５１８）。ライセンス５２の許諾５２ｂは使用権および／またはメタ権利を含み得ることに留意されたい。したがって、ライセンス５２によって消費者コンポーネント４３８のユーザは、類似の方法で他者に対して権利を許諾することが可能である。しかしながら、派生可能な権利は、メタ権利を用いることによって上流側の当事者によって制御される。追加的に、上記のプロトコルは、供給者コンポーネント４０２が、消費者コンポーネント４３８のユーザにクレジットカードによって支払いを行うことを要求するステップと、ユーザコンポーネント４０２が情報を提供して課金を承認するステップを含み得る。供給者コンポーネント４０２と消費者コンポーネント４３８の双方は、このプロセスが成功であったか失敗であったかに関するステータスレポートを生成することが可能である。さらに、当事者たちは、このプロセス中に互いを認証し、このプロセス全体にわたって認証を維持することが可能である。

図５Ｂに、権利許諾のプルモデルのプロトコルを示す。最初に、消費者コンポーネント４３８は、コンテンツ内のある権利の取得に興味があることを示す要求を供給者コンポーネント４０２に送る（５２０）。すると、供給者コンポーネント４０２はそれに応じて、消費者コンポーネント４３８が要求した権利を範囲に含む複数のオファーオプション４４を有するラベル４０の形態を有するオファーを示し、このオファーを消費者コンポーネント４３８に送る（５２２）。

消費者コンポーネント４３８は次いで、このオファーとそのオプションを検討し、供給者コンポーネント４０２に対して、これらオファーオプションの内の１つを選択して応答する（５２４）。供給者コンポーネント４０２は、この応答にしたがって権利をカスタマイズし、ライセンス案の形態でこの権利を消費者に対して許諾する（５２６）。次に、消費者コンポーネント４３８はこのライセンス案を受け入れ（５２８）、供給者コンポーネント４０２は消費者コンポーネント４３８に対する権利を許諾するライセンス５２を発行する（５３０）。この権利もまた、メタ権利を含み得る。

図６に、供給者コンポーネント４０２内のオファー生成モジュール４０８によって実行されるオファー生成プロセス６００を示す。オファー生成プロセス６００では、最初にブロック６０２において利用可能な権利が収集される。権利は、供給者に対して許諾されたメタ権利から派生されることにより前の供給者から入手されるか、最初に作成されることができる。ステップ６０４で、供給者が消費者に対してオファーを行える権利があるか判定される。たとえば、消費者が未成年者であることが既知であり、コンテンツが成人の消費者に限られているような場合、または、消費者がコンテンツ受信の禁止者のリストに載っているような場合、供給者はオファーしないことができる。このような場合、オファー生成プロセスはステップ６０６で終了する。供給者がオファーできる権利がある場合、プロセスはステップ６０８で、ステップ６０２で収集された権利を解析することによって、消費者に対してオファー可能なすべての権利を決定する。次に、ステップ６１０で、本プロセスは、消費者が何らかの特定の権利を要求しているか否かを判定する。要求が受信されていれば、本プロセスはさらに、受信した消費者が要求した権利について考慮し、これらを利用可能な権利と比較することによって、オファー可能と判定された権利をフィルタリングする。次に、本プロセスはステップ６１４で、オファーテンプレートを適用する必要があるか否かを判定する。

たとえば、消費者は、テンプレートに含まれる、コンテンツを印刷する権利やアーカイブする権利などの標準的な権利をオファーされることができる。オファーテンプレートが利用可能であり、また必要とされる場合、オファーテンプレートがステップ６１６で適用される。ステップ６１８で、人間が介入して、このオファーテンプレートまたは本プロセス中でこの時点までオファー目的で利用可能な権利の内のいずれかをさらに調整してもよい。次に、条件変数および／または状態変数によって制限を掛けることが可能である。たとえばステップ６２０で、時間制限をある権利に対して掛けたりしてもよい。最後にステップ６２２で、デジタル署名または他の認証を、オファー予定の権利の集合と共に提供し、ステップ６２４において権利ラベル４０の形態で認証済みオファーを行って、ステップ６２４で消費者コンポーネント４３８に対して提示する。

図８に、供給者コンポーネント４０２内の権利構成モジュール４１０によって実行される権利カスタマイズプロセス８００を示す。最初に、消費者の選択がステップ８０２で受信される。選択とは、ステップ６２４（図６）で選択されたラベル４０中の権利および条件のオプション４４のことである。次に、供給者コンポーネント４０２が消費者コンポーネント４３８に対して権利を許諾する権利を有するか否かがステップ８０４で判定される。たとえば、消費者が、最少年齢やコンテンツがライセンスされ得る場所に居住している証拠などの、ある種の要件を満たしていない場合には、ライセンスを許諾することは不適当であり、権利カスタマイズプロセス８００はステップ８０６で終了する。このような要件を満たしていれば、消費者が選んだ選択内容をステップ８０８で分析して、これらの内容が供給者コンポーネント４０２によって認識可能であるか否かを確認する。たとえば、この選択内容を解析し、理解（解釈）可能であるか否かを確認することが可能である。

次に、消費者情報が入手可能であるか否かをステップ８１０で判定する。たとえば、消費者のプロフィールはデータベース４１４に記憶されていることができる（図４）。入手可能であれば、ステップ８１２でこの消費者情報を考慮検討して消費者の選択内容をさらに分析する。ステップ８１２では、以下の説明するように動的情報を考慮することもまた可能である。たとえば、プロフィールには、ある権利を提供することが望ましいか望ましくないかを示す信頼度格付けまたは消費者の住所が含まれる場合がある。次いでステップ８１４で選択内容が妥当であるか否かが判定される。この判定は、たとえばコンピュータ計算によって、または人間が介入して実施される。消費者の選択内容が不適当であると見為されれば、ブロック８１６で消費者の選択について再交渉が行われる。この再交渉プロセスでは、顧客には、前の選択内容の分析に基づいた新たなオファーが提示され、新たなオファーの選択内容を提出するチャンスが与えられ、権利カスタマイズプロセス８００が再度ステップ８０２から開始される。内容が適当であれば、選択された権利を含むライセンスがステップ８１８で作成される。

ライセンスの作成後、消費者による受け入れが必要であれば（ステップ８２０）、ステップ８２２で閲覧のために消費者に対して提示される。ステップ８２４で消費者がライセンス内の条項に同意しなければ、ステップ８１６で再交渉が開始され、これにより権利カスタマイズプロセス８００が再度ステップ８０２から再開始される。ステップ８２０で、消費者による閲覧が不必要であれば、ライセンスはステップ８２６で認証され、ステップ８２８で完成されたライセンス５２が作成され、発行されて、コンテンツ４２と関連付けられる。

図７に、消費者コンポーネント４３８のオファー分析モジュール４３０と選択実行モジュール４３２とによって実行されるオファー検討プロセス７００を示す。利用可能なオファーが最初にステップ７０２で収集される。ステップ７０４で、プロセス７００は、供給者からのオファーを受け入れられる権利があるか否かを判定する。たとえば、消費者は、年齢制限や企業外からのコンテンツ受け入れに対する制限などのコンテンツの購入に対するある種の制限があれば、オファーを受け入れられない場合がある。このような場合、オファー検討プロセスはステップ７０６で終了する。消費者が供給者からのオファーを受け入れる権利を有していれば、このオファーがステップ７０８で分析されて、認識可能であるか否かが判定される。供給者の優先傾向が入手可能であるとステップ７１０で判定されたら、ステップ７１２で、オファーがこの優先傾向に基づいてフィルタリングされる。たとえば、消費者は特定の供給者を信頼したり、その他の理由で他の供給者よりこの供給者とのトランザクションを好んだりする場合がある。次に、ステップ７１４で、消費者の優先傾向が入手可能であるか否かを判定し、そうであれば、ステップ７１６でオファーに対してこの優先傾向が適用される。ステップ７０８〜７１４のロジックと他のいずれかの所望のロジックを適用することによっていったんすべてのオファーが分析されると、消費者はブロック７１８でオプションを選択し、ブロック７２０で付随事項（contingency）を
指定する。オプションの選択は自動的に実行することが可能である。人間の介入が必要であれば、消費者が介入して、さらに追加の選択事項や条件を所望により指定することが可能である。あらゆる優先傾向、ルールまたは他のロジックがオファーを分析するために用いられてもよい。

全体として、上記の図６、７、８の説明から分かるように、消費者が要求を送り、そしてライセンスが構築される。供給者と消費者のいずれがライセンスの内容を起草しても良いが、上記の例では供給者がコンテンツを起草している。この要求はオファーのサブ集合であり、このオファーは１つ以上のオプション（選択肢）を有している。供給者は、要求を送る消費者に（および、所望により他の消費者にも）対してこのオファーを利用可能なものとし、次いで消費者は（適用可能であれば他の消費者も）選択を行う。次に、供給者がこの選択内容を分析して、ライセンスを構築（すなわち権利の許諾）する。ここで、この要求は拒絶されたり、修正提案を行って、同じプロセスをこの修正提案に対して繰り返したりすることも可能である。

また、供給者が要求を分析するに際しても、この分析は自動的に実施しても、人間の介入によって実施してもよい。消費者がオファーについて検討する際、選択または受け入れは自動的に、または人間の介入によって実行されてもよい。オファーもしくはライセンス、またはこれらの双方が、動的情報、消費者情報および、上述のような消費者の要求に基づいて生成されてもよい。

この動的情報には、価格付け、ネットワークの状態、瞬時ごとのＷｅｂサイトのトラフィック、付与されるディスカウント、付与されるクーポン券、消費者の趣味、コンテンツの使用回数、コンテンツの使用時間、コンテンツの使用場所等に関連する情報を含む多くの種類の情報が含まれてもよい。動的情報は状態変数として追跡可能であり、この状態変数の値を必要に応じてチェックして更新することが可能である。

ダイナミック情報は、非静的な要素を参照して変更したり、作成したりする（実際にする必要はないが）ことが可能な情報である。たとえば、動的情報は、公式、データベース、曲線、所定の表、値のパーセンテージ、関数、公定歩合や株式市場の指数の変化などの他のデータに対する参照、および／またはユーザや配信者による人手の介入、および／または消費者の入力に基づいて得ることが可能である。

消費者情報には、消費者の年齢、消費者のクレジット履歴、消費者のクレジット限度額、消費者の収入、得られた権利やライセンスの種類、消費者のパスワード、消費者に割り当てられた鍵、アクセスやディスカウントのクラブメンバーシップ、所定の判断基準に基づいた消費者の等級、または他のデータ、識別のための特徴および情報などの情報が含まれてもよい。供給者情報には、消費者情報としての情報対象の一部または全部が含まれ、また、たとえば、利用可能なオプションやバリエーション、供給者、出荷情報および他の情報も含まれてもよい。

本発明に開示するシステムとプロセスは、コンテンツの多層構造と超流通をサポートするものである。以下に説明するのは、どのようにこれをモデリングしサポートすることが可能であるかを示す使用ケースである。権利供給者（この場合ではコンテンツ配信者）に対するオファーされた権利を、権利消費者（この場合ではエンドユーザ）に対する許諾された権利に変換するプロセスを示すことによって、権利をオファーし許諾するプロセスを解説する。具体的には、どのようにしてオファーが既存のライセンスから生成されるか、どのようにしてこのオファーが選択にしたがって検討されるか、およびどのようにして最終的なライセンスが発行されるかを示す。メタ権利は、コンテンツ配信連鎖中である当事者から次の当事者に権利を移転することを可能とするメカニズムとなる。

あるコンテンツＣのコンテンツ提供者Ｐが、配信者Ｄが、アメリカ合衆国（ＵＳ）の領域内のあらゆるエンドユーザに１ドルという均一料金で「プレイ」権利を、１枚当たり４ドルの費用で「印刷」権利を販売してもよいことを（双方ともＤからＰに支払われる）指定するように望んでいるものと仮定する。この提供者はまた、コンテンツ配信者が自分自身の条件を、自身がエンドユーザに対して発行する「プレイ」権利と「印刷」権利に付加することを許可している。

コンテンツ提供者から配信者に対するライセンスは、ＸｒＭＬ権利言語を用いると以下のようになる。

配信者は、上記のライセンス中に表現した権利に基づいてエンドユーザに対してオファーすることができる。ここで、使用権と各々のオプションの条件とは、＜ｇｒａｎｔ＞タグの間にＸＭＬとして記載されている。下記のオファーでは、配信者は、エンドユーザに対して２ドル（提供者に対する支払いより１ドル多い）課金するという「プレイ」権利取得に対する料金条件と、エンドユーザに対して１枚印刷するごとに６ドル（提供者に対する支払いより１ドル多い）課金するという「印刷」権利取得に対する料金条件とを追加していることに注意されたい。配信者はまた、オファーの受け入れ期間（２００２年１２月３１日まで）を制限している。配信者に対して許諾されたメタ権利によって、配信者は、上述したようにライセンス中の許諾事項を修正して、オファーすることが可能である。

このオファーがエンドユーザに対して提示されると、エンドユーザは、均一料金２ドルの「プレイ」権利だけを取得することを選択してもよく、以下に示すように、配信者に＜ｃｈｏｉｃｅ＞タグの間にＸＭＬとして記載された選択で応答する。

ここで、この要求は拒絶することも可能であることに留意されたい。また、応答を、配信者が最初にオファーしていない権利のための修正オファーとして構築することも可能であることにも留意しなければならない。配信者は、この選択をエンドユーザから受信すると、以下に示すようなライセンスをユーザに対して発行する。

ここで、上記のすべてのＸＭＬ文書において、発行者は、なんらかのデジタル署名アルゴリズムを用いて文書にデジタル署名することを選択できることに留意されたい。このような文書の受信者は、添付されたデジタル署名の有効性をチェックすることによってこれらの文書の有効性を検証するという選択肢を有している。様々な文書とその要素とに対するアクセスは、周知の技法を用いて制御可能である。

ある状況下では、オファーし許諾されると、その結果、ライセンスには、コンテンツの新たな使用状態が記される。権利を行使し始めると、メタ権利の結果として得られた派生された権利は、この権利と関連する状態変数の値を継承および／または共有する。たとえば、ある文書を５回印刷して４枚コピーする権利を許諾されると、新しいコピーはすべて同じ権利集合を有していてもよいが、オリジナルと状態（または残余の権利）を共有する。原稿が２回印刷されて新たにコピーされると、このコピーと原稿は合計３回印刷してもう２部コピーを作成することが可能である。

このように、この例示的な実施形態は、品目と関連するように構成される使用権を移転する方法を含んでいる。本方法は、品目に対する使用権とメタ権利とを含んでいる少なくとも１つの第１のオファーを供給者によって生成し、使用権はこの品目の使用方法を定義し、メタ権利は使用権または他のメタ権利を派生するための権利を指定しており、このオファーを第１の消費者に提示し、所望の使用権とメタ権利とを示す選択を第１の消費者から受信し、この所望の使用権とメタ権利を第１の消費者に対して許諾する第１のライセンスを生成することを含む。本例示的な実施形態は、多層構造の流通チャネルで、ライセンスされる品目と関連するように構成された使用権を、少なくとも１レベル下流に割り当てられた下流の権利および条件と共に転送するシステムをさらに含む。本システムは、供給者ユーザインタフェースモジュールと、少なくとも使用権とメタ権利を含んでいるオファーを生成するオファー生成モジュールと、ライセンス案を合成する権利構成モジュールと、供給者の権利のレポジトリと、供給者管理データベースとを備える供給者コンポーネントを含んでいる。本システムは、消費者ユーザインタフェースモジュールと、供給者コンポーネントが生成したオファーを分析してこの分析に基づいてオファーを選択するように構成されたオファー検討モジュールと、消費者の権利のレポジトリと、消費者管理データベースを備える消費者コンポーネントをさらに含んでいる。本例示的な実施形態は、デジタルコンテンツの管理と配信の内の少なくとも一方を実施するシステム内で用いられるデジタルコンテンツに対してライセンスを生成する方法をさらに含んでいる。本方法は、メタ権利を含んでいるオファーを消費者に対して提示し、消費者によるオファー内の少なくとも１つのメタ権利の選択を受信し、この選択に基づいてライセンスを生成することを含み、このライセンスは、消費者がこの少なくとも１つのメタ権利を行使することを可能とし、また、消費者が、この少なくとも１つのメタ権利から派生された少なくとも１つの派生した権利をオファーし、この少なくとも１つの派生した権利を含むライセンスを生成することを可能とする。

図１２に、本発明による、共通の権利状態サーバを含む例示的なシステムを示す。図１２で、この例示的システムは、権利状態マネージャ１２０９および１つ以上の権利状態レポジトリ１２１４を含んでいるシステムの共通権利状態サーバ１２０１と、メタ権利マネージャ１２１０、使用権マネージャ１２１２、認証コンポーネント１２０８、条件バリデータ１２０６、権利状態マネージャ１２０４、１つ以上の権利状態レポジトリ１２１６、ライセンスマネージャ１２０３、ライセンスインタープリタ１２０２および１つ以上のライセンスレポジトリ１２１８を含んでいる１つ以上のライセンスサーバ１２００とを含むことが可能である。

共通権利状態サーバ１２０１は、１つ以上のライセンスサーバ１２００と接続されているリモートサーバとして構成可能である。共通権利状態サーバ１２０１は、権利状態マネージャ１２０９を介して、ライセンスサーバ１２００内の権利状態マネージャ２０４に匹敵するサービスを提供する。権利状態サーバ１２０１から提供されるサービスと、サーバ１２０１が管理する状態とは、１以上の権利供給者と権利消費者（図示せず）とによって共有可能である。

権利状態サーバ１２０１は、１つ以上のライセンスサーバ１２００と１つ以上のリモート通信リンク１２２０等を介して接続されるリモートサーバとして構成することが可能である。権利状態サーバ１２０１によって提供されるサービスもまた、ライセンスサーバ１２００の内の１つ以上に統合することが可能であり、このようなサービスは、他の権利供給者、権利消費者等からアクセス可能である。

ライセンスマネージャ１２０３は、任意の適切な機械読み取り可能な表現を含むことができ、オプションとしてはメタ権利を含んでいるオファーに基づいて新しい権利を派生させることが可能である。権利を派生させるとき、ライセンスマネージャ１２０３は、派生した権利と関連付けられる新しい状態変数を作成することが可能である。状態変数の作成とその適用範囲（scope）は、オファーの中に、またはシステム中のいずれか他の機能に
よって規定することが可能である。この状態変数は、たとえば、権利の派生前に、権利の派生中に、条件が満たされ次第、状態変数と関連する権利の最初の行使中などに、１つ以上のインスタンスにおいて作成可能である。状態変数は、特定の権利消費者に対して排他的に指定されたり、権利消費者間で共有されたり、権利消費者と権利供給者等の他のエンティティ間で共有されたりすることが可能である。ライセンスマネージャ１２３０は、権利状態マネージャ１２０４と対話して、新しい状態変数を１つ以上の権利状態レポジトリ１２１６中の物理アドレスと関連付けることが可能である。権利状態マネージャ１２０４は、１つ以上の権利状態レポジトリ１２１６にアクセスすることが可能であり、また、権利状態サーバ１２０１と対話して、１つ以上の権利状態レポジトリ１２１４からの共有状態変数にアクセスすることが可能である。

指定された状態変数を用いて、ライセンスの受信者に対してコンテンツを５回印刷する権利を許諾するライセンスをサポートすることが可能であり、共有された状態変数を用いて、認可されたユーザのグループに対して、コンテンツを一括して合計１００回印刷する権利を許諾するサイトライセンスをサポートすることなどが可能である。指定された状態変数は、対応する権利が行使されると更新することが可能であり、共有された状態変数は、認可されたユーザが対応する権利が行使すると、更新することが可能である。言い換えれば、共有状態変数は、複数のユーザによる動作に応答して更新され、これらユーザの各々に対してグローバルに適用されるデータ変数を含むことが可能である。

状態変数の範囲を指定するには複数の方法があるが、これらの方法のいずれもが、派生的状態変数が共有可能であるか否か、派生的状態変数をどのようにしたら共有可能であるか、などに関して影響を及ぼしうる。たとえば、状態変数は、ローカルであって受信者にだけ単独に限定されるか、又はグローバルであって所定の受信者グループによって共有可能であってよい。グローバル状態変数は、派生された権利が発行されたときには指定されておらず、おそらくライセンス内で定義されているあるルールまたは他の手段に基づいて、後で指定される受信者グループによって共有可能である。グローバル状態変数は、１つ以上の権利供給者、所定の受信者、未指定の受信者等の間で共有可能である。有利には、所与のビジネスモデルとメタ権利内で許諾されている権利による共有関係により、状態変数を値連鎖の様々な段階で作成可能である。

状態変数の非排他的な例示的使用法のセットを以下に説明する。たとえば、状態変数はメタ権利内では未指定であり得るが、これは、状態変数の識別子と値とが、メタ権利マネージャモジュール１２１０によって未だ決定されておらず、派生した権利に未だ含まれてはいないことを意味する。相互に別個の状態変数を各々の派生した権利に割り当てると、派生した権利のこの状態変数の範囲は、通常、受信者に限られる。

図１３に、本発明による、排他的（exclusive）使用権を派生させる際の状態変数を用
いる方法を示す。図１３で、オファー１３０１から派生された権利１３０２と１３０３は、それぞれの消費者に対して専用（exclusive）である。オファー１３０１は、特定の派生的権利を得る条件が満たされると前記派生的権利を得る権利を受信者が有するタイプのメタ権利である。したがって、例示的オファー１３０１は、未指定の状態変数１３０４を有している。しかしながら、特定的な状態変数１３０５と１３０６は、各々が固有のＩＤを割り当てられており、派生した権利１３０２と１３０３に含まれている。派生状態変数１３０５と１３０６は、その関連の派生した権利に拘束されている、たとえば、“ＡｌｉｃｅＰＬａｙＥｂｏｏｋ”（すなわち、アリスはｅブックをプレイする権利がある）は、派生した権利１３０２に拘束されており、“ＢｏｂＰｌａｙＥｂｏｏｋ”（すなわち、ボブはｅブックをプレイする権利がある）は、派生した権利１３０３に拘束されている。“ＡｌｉｃｅＰＬａｙＥｂｏｏｋ”変数は、アリスが自分のプレイ権利を行使すると更新されることができ、“ＢｏｂＰｌａｙＥｂｏｏｋ”変数はボブが自分のプレイ権利を行使すると更新されることができる。

オファーから権利を派生する以外にも、権利はあるエンティティから受信者に移転可能である。権利が移転されると、関連の状態変数の統御もこの受信者に移転される。権利が移転されると、ソース（移転元）の当事者は、通常、もはやその権利は行使不可能となるが、受信者はその権利を行使することが可能である。受信者の権利の行使を統御するライセンスサーバは、状態の管理を担っている。しかしながら、状態変数を共通の権利状態サーバ１２０１が管理する場合、権利状態サーバ１２０１に権利の移転を通知する必要がある。具体的には、状態変数は、権利の移転以後は、受信者の状況（context）で管理する
ことが可能である。

権利をソースの当事者と受信者間で共有する場合、関連する状態変数が派生した権利内で参照される。この権利を複数の受信者で共有する場合、一般的にこれら受信者のすべてが、ソースの当事者と同じ状態変数を共有する。この場合、共有された状態は、すべての共有者からアクセス可能なエンティティによって管理することが可能である。

図１４に、本発明による、継承した使用権を派生させる際に状態変数を用いる方法を示す。図１４で、派生した権利はメタ権利から状態変数を継承することが可能である。たとえば、ユーザであるアリスのパソコン（ＰＣ）を、ライセンス１４０３にしたがってｅブックをプレイするように構成することが可能である。ＰＣとＰＤＡが同じ状態変数１４０４と１４０５、たとえば、“ＡｌｉｃｅＰＬａｙＥｂｏｏｋ”を共有する場合、アリスのＰＤＡ（携帯情報端末）もまた、オファー１４０１にしたがってｅブックをプレイする権利を取得することが可能である。派生した権利１４０２によって、アリスは、ＰＤＡとＰＣが５回という同じカウント制限値１４０６を共有する限り、自分のＰＤＡでもｅブックをプレイすることが可能である。

使用権を所定の受信者の集合で共有する場合、対応する使用権を追跡する状態変数を、すべての受信者に対して同じ状態変数ＩＤを用いてメタ権利内に指定することが可能である。このメタ権利を行使している間、同じ状態変数ＩＤがすべての派生した権利内に含まれる。

図１５に、本発明による、権利の受信者の既知の集合の中で共有される権利を派生させる際の状態変数を用いる方法を示す。図１５で、サイトライセンス１５０１がＦｏｏＵ大学に対して発行される。たとえば、サイトライセンス１５０１によって、図書館員は、ＦｏｏＵの学生が、ｅブック等の対応するコンテンツに対しプレイ、閲覧等の行為を行うことを、このような使用権が状態変数１５０４、たとえば、“ｗｗｗ．ｆｏｏｕ．ｅｄｕ”によって追跡されている限り、可能とするような権利を発行する権利を許諾される。したがって、サイトライセンス１５０１から派生した権利１５０２と１５０３は、状態変数１５０５と１５０６である、“ｗｗｗ．ｆｏｏｕ．ｅｄｕ”、を含んでいるが、これは、対応する学生であるアリス及びボブがｅブックをプレイすると更新されることができる。

使用権を動的な受信者集合で共有する場合、状態変数は使用権内で未指定のままでもよい。メタ権利の行使と、受信者の集合が既知であれば、状態変数を、この既知の受信者に一意である何らかのＩＤを用いて指定可能であり、派生した権利内に含めることが可能である。

図１６を用いて、本発明による、権利の受信者からなる動的な集合によって共有される権利を派生させる際の状態変数を用いる方法を示す。図１６で、オファー１６０１は、配信者が提携しているクラブに対してサイトライセンスを発行して、各クラブの５人のメンバーに対して、ｅブックなどのコンテンツを閲覧、プレイ等の行為を同時に実行することを可能とすることを指定する。このような権利と関連する対応する状態変数１６０７は、オファー１６０１中では未指定であってよい。対応する権利１６０２と１６０３が提携クラブに対して発行されると、対応するクラブ識別子を用いて、この発行済み権利中の状態変数１６０８と１６０９を指定する。オファー１６０２と１６０３は、オファー１６０１から派生したメタ権利であり、別個の状態変数１６０８と１６０１を割り当てられているオファーである。さらなるオファー１６０４〜１６０６を、オファー１６０２と１６０３から派生させて、それぞれのクラブのメンバー内で共有させることが可能である。ライセンス１６０４と１６０５はオファー１６０２から派生した権利の例であり、状態変数１６０８、たとえば、“ｕｍ：ａｃｍｅ：ｃｌｕｂ”を継承しており、ライセンス１６０６は状態変数１６０９、たとえば、“ｕｍ：ｆｏｏ：ｃｌｕｂ”を継承している。

状態変数は、権利供給者、消費者等の当事者によって共有可能であるばかりではなく、複数の行使可能権利によっても共有可能である。図１７を用いて、本発明による、複数の権利で共有された状態を維持するために状態変数を用いる方法を示す。図１７では、同じ状態変数１７０３が印刷権利１７０２とプレイ権利１７０１の双方に関連付けられ、これにより、プレイ、印刷等の行為の総数をまとめて追跡可能とする。

権利の状態は、２つ以上の状態変数に基づくことができる。図１８を用いて、本発明による、権利の１つの状態を表すために複数の状態変数を用いる方法を示す。図１８を参照して説明する例は、図１６で説明した例を踏まえている。図１８では、使用権を、オファー１８０１中の複数の状態変数１８０７と１８０８を用いて追跡することが可能である。たとえば、優先レベルを表す状態変数１８０８は、対応するオファー１８０２と１８０３（たとえば、サイトライセンス）中で未指定のままでもよい。たとえば優先順位を設定する対応する状態変数１８０９〜１８１１が、対応する１８０４、１８０５および１８０６中の各々のメンバーに対して割り当て可能である。このように閲覧、プレイ等の行為を行う対応する権利は、２つの状態変数次第とすることが可能であり、事実上、優先レベルごとに、閲覧、プレイ等の行為を同時に５回までに制限する。

１つの状態変数で状態の集合を表すことが可能である。たとえば、一意のＩＤを用いて状態変数を表すことが可能であり、また、適当なメカニズムを用いて、このような一意のＩＤを、各々が別個の状態を表している複数の変数のデータベースにマッピングすることが可能である。

状態変数の適用範囲を用いて、状態変数を管理できるエンティティを決定することが可能である。たとえば、ローカル状態変数の場合、その関連の権利の使用追跡を、メディアプレイヤ等の権利消費環境内に埋め込まれている信頼されているエージェントだけによって管理することが可能である。追加的に、このような使用追跡は、共通権利状態サーバ１２０１などの信頼されているリモートサービスによって実行することが可能である。さらに、共有されているグローバル状態変数を、複数の信頼されているエージェントによってアクセス可能なものとすることが可能である。ピア（peer）権利消費環境内に含まれるデータ等のコンテンツのアクセスに関連するプライバシ問題、セキュリティ問題、信頼問題、権利問題等を避けるために、このような共有されているグローバル状態変数の管理を、権利状態サーバ１２０１などのリモートサービスによって実行することができる。

カウンタは、状態変数を用いる一般的な形態である。たとえば、このような状態の共有にはカウンタの共有を含み、この場合の状態は、権利行使の回数、イベントの発生回数等を表している。このようなカウンタの共有は様々な形態で見られることができ、また多くの状況で発生可能であるが、このような状況には、同時使用数の追跡、連続使用回数の追跡、順序付け（たとえば、コマーシャルは、フリーコンテンツがアクセス可能となる前に閲覧されなければならない）、１回使用制限、トランザクション数、委託制御レベル、超流通レベル、少なくとも１つ以上のサービスやデバイスに依存場合等がある。

加えて、状態変数は様々な形態で具体化可能である。たとえば、状態変数を用いて、映画スタジオにより放映権を特定のテレビ局に移転したり、あるテレビ局のグループが共有する放映権を移転したり、入札プロセスで割り当てられた放映権の移転等を実行するために用いられたりするような、ある期間中の特定のタイムスロットを追跡することが可能である。

状態変数はまた、たとえば、地域的な販売や権利配信で、金融情報交換所からのステートメントという形態で用いられることができ、フリーコンテンツがアクセス可能となる以前にコマーシャルが見られたか否かの状態として、適切な料金が支払われたこと等を確認することが可能である。

全ての権利が状態に関連付けられる必要はない。図１９を用いて、本発明による、すべての権利が状態と関連しているわけではない場合を示す。図１９では、オファー１９０１によって、ユーザのアリスは、無制限のプレイ権、閲覧権等の権利を自身のＰＤＡに対して許諾することが可能である。このようなプレイ権はいかなる状態とも関連付ける必要はない。したがって、派生した権利１９０２もまた、自身のＰＣに対する権利１９０３と同様に、コンテンツに対する無制限のプレイ権を有している。

状態と関連している権利がすべて共有されたり、継承されたりするわけではない。たとえば、オフラインで用いられるような権利もあり、これは、全体として別のデバイスに対して移転されることができ、したがって、他のデバイスと共有されない。図２０を用いて、本発明による、状態と関連しているすべての権利が共有されたり継承されたりするわけではない場合を示す。図２０では、ユーザであるアリスのプレイ権２００３、アリスのＰＤＡのプレイ権２００２およびアリスのＰＣのプレイ権２００３は同じ状態変数ＩＤ２００４を指定されているとはいえ、同じ状態を共有する必要はなく、これは、デバイスは各々が自身の状態をローカルで追跡可能であるからである。このような実施例によって、ＰＣとＰＤＡとは各々が、対応するコンテンツを最大で５回までプレイすることが可能である点で有利である。

図２１に、メタ権利を明示的には含まないオファーの形態を示す。図２１では、オファー２１０１は、英語で書かれたサイトライセンスとして構成されている。ライセンス２１０２と２１０３は、オファー２１０１から派生したインスタンスである。本例示的な実施形態では、変数２１０４と２１０５は、たとえば図１２のシステムによるオファー２１０１の解釈に基づいて作成することが可能である。

本好ましい実施形態は、パソコン、サーバ、ワークステーション、ＰＤＡ、シンクライアント物などの様々なデバイスを利用することが可能である。たとえば、クライアント環境は、モバイル電話やＰＤＡなどの携帯デバイスであってよい。様々な通信チャネルが使用可能である。さらに、様々な機能が１つのデバイスに統合可能である。たとえば、ライセンスサーバ機能が、クライアント環境内のソフトウエアで実施可能である。さらに、オファーをしたり、権利を選択したり、ライセンス許諾したりするライセンスサーバの機能を同じデバイス中で実施可能である。本明細書に開示した機能モジュールは、分かりやすいように機能別に分離している。しかしながら、これら様々な機能を、任意の方法でハードウエアおよび／またはソフトウエアとして組み合わせたり分離したりすることが可能である。これら様々な機能は相互に分離しても組み合わせても有用であり得る。

様々な要素とその部分は、同じデバイスまたは別々のデバイスに記憶可能である。たとえば、ライセンスはコンテンツと一緒に、または別々に記憶されることができる。さらに、ライセンスの様々な要素を相互に別のデバイスに記憶することができる。たとえば、状態変数の値を、状態変数の現在値を追跡するシステムの状態変数レポジトリに記憶することができる。様々なリンク、参照、指定等を用いて、これらの要素を関連付けすることが可能である。

本発明を例示的な実施形態と例を用いて説明した。しかしながら、添付のクレームと法的な均等物によって定義される本発明の範囲から逸脱することなく、様々な修正が可能である。

Claims (1)

1. 複数のデバイスの間で共有するために第１メタ権利から権利を派生する方法であって、
   前記第１メタ権利は、コンテンツと関係付けられるとともに、前記複数のデバイスの少なくとも一つが前記コンテンツに対する使用権もしくは、前記第１メタ権利とは異なる別のメタ権利である第２メタ権利を派生するのを許可する機械読み取り可能な表現であって、
   前記第１メタ権利は、前記複数のデバイスの内の少なくとも一つのユーザに固有のＩＤが割り当てられる状態変数と関係付けられ、前記状態変数はリモート権利状態サーバの物理アドレスと関連付けられ、
   前記方法は、
   前記第１メタ権利と前記コンテンツを、前記複数のデバイスの内の第１のデバイス上に記憶し、
   前記第１のデバイスが、前記コンテンツを前記複数のデバイスの内の第２のデバイスに移転するリクエストを受け、
   前記第１のデバイスの権利構成モジュールが、前記第１メタ権利によって前記第１のデバイスが前記第２のデバイスに対して前記使用権もしくは第２メタ権利を派生することが許可されているか否かを判定し、
   許可されている場合、前記第１のデバイスが、前記リモート権利状態サーバに、前記使用権もしくは第２メタ権利の移転を通知するとともに、前記第１のデバイスのライセンスマネージャが、前記第１メタ権利に基づいて、前記使用権もしくは第２メタ権利を派生させ、前記派生は、前記第１メタ権利から派生される前記使用権もしくは第２メタ権利と前記状態変数とをライセンスに含めること、並びに前記ライセンスを前記コンテンツに関連付けることを含み、
   前記第１のデバイスが、前記第２のデバイスに前記ライセンスと前記コンテンツを移転することにより、前記第１のデバイスが、前記第２のデバイスに、前記状態変数の管理の移転を許可すること
   を含む、方法。

Images