権利共有をサポートする方法およびシステム
【課題】ユーザが、ユーザ自身の必要性にしたがって権利を共有することを可能とする権利共有をサポートする。
【解決手段】計算環境内でリソースの使用を制御するために譲与者から被譲与者に譲与される共有可能権利からサブ権利を導出することを可能とすることによって権利共有をサポートする。計算装置が、サブ権利の少なくとも一つのコンポーネントを譲与された権利の対応している少なくとも一つのコンポーネントから導出することが可能であることを確認し、計算装置が、前記確認ステップによりサブ権利のコンポーネントを譲与された権利の対応するコンポーネントから導出することが可能であることを確認された場合、前記計算環境内での前記リソースの使用制御のための、前記サブ権利からなる消費ライセンスを作成する。
【解決手段】計算環境内でリソースの使用を制御するために譲与者から被譲与者に譲与される共有可能権利からサブ権利を導出することを可能とすることによって権利共有をサポートする。計算装置が、サブ権利の少なくとも一つのコンポーネントを譲与された権利の対応している少なくとも一つのコンポーネントから導出することが可能であることを確認し、計算装置が、前記確認ステップによりサブ権利のコンポーネントを譲与された権利の対応するコンポーネントから導出することが可能であることを確認された場合、前記計算環境内での前記リソースの使用制御のための、前記サブ権利からなる消費ライセンスを作成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＤＲＭ（デジタル権利管理）の分野およびデジタルリソース管理に関し、詳しくは、権利およびリソースの分配および共有に関する。
【背景技術】
【０００２】
現在の最新のＤＲＭシステムでは、人間であったりデバイスやサービスなどの人間以外のエンティティであったりする潜在的ユーザの集合で権利を共有する機能は、市販のプロダクツで利用可能である。譲与された権利の集合とこれらの権利を共有する方法は一般的にはライセンスという形態で指定される。
【０００３】
権利の共有専用のライセンスの１つの形態は、並列ユーザライセンス（サイトライセンスまたはネットワークライセンスとしても知られている）と呼ばれる。並列ユーザライセンスは、ネットワークサーバに拘束されているライセンスのプールを表し、このネットワーク上のユーザだけがこのライセンスにアクセスすることが可能であり、これに同時にアクセス可能なユーザの数は限られる。
【０００４】
並列ユーザライセンスの従来型の実施例では、ライセンスにアクセス可能なユーザ各々に、このライセンスに指定されているすべての権利が譲与されている、すなわち、ユーザすべてが同じ権利を有する。Ｍａｃｒｏｖｉｓｉｏｎ ＦＬＥＸｎｅｔによるこのタイプのライセンスのより進歩した実施例では、並列ユーザライセンスのユーザは、権利の集合を動的に共有することが許可される。このライセンスは、ユーザ各々が有することが可能な権利の集合を指定する代わりに、すべてのユーザが共有することが可能な権利の最大集合を指定する。これらの権利をどのように共有するかは、ライセンスの購入者次第であり、したがって、オプションファイルとソフトウエアプラグインモジュールとからなるカスタムアクセス制御メカニズムを用いて構成することが可能である。このオプションファイルを用いると、特に、特定の一人もしくは複数のユーザのためのライセンスプールで利用可能な多くのライセンスの予約、ユーザもしくはユーザグループがアクセス可能なある特定の特徴的機能の予約およびオフラインで使用する目的でこのプールからあるライセンスを誰が借用することが可能であるかの規定を制御することが可能である。このオプションファイルによってサポートされる特徴的機能の一部を解説すると、「ＲＥＳＥＲＶＥ１インストールＵＳＥＲロバート」は「ロバート」というユーザに対して「インストール」という特徴的機能の１つのライセンスを予約し、「ＲＥＳＥＲＶＥ４プレイＧＲＯＵＰアカウンティング」は、アカウンティンググループがコンテンツをプレイするためのライセンスを予約し、「ＩＮＣＬＵＤＥ＿ＢＯＲＲＯＷプレイＵＳＥＲトム」は、特徴的機能「プレイ」を借用することが可能なユーザのリストに「トム」というユーザを含む。共有することに加えて、オプションファイルには、使用を報告するオプションが含まれている。これは、事実上、ライセンスが、使用を追跡するという条件をユーザに課す方法である。あるユーザがコンテンツにアクセス可能であるかどうかを判定する認可プロセスでは、オプションファイルをプラグインが処理して合成応答を発生している間に、このライセンスを一般的ライセンスマネージャが処理する。
【０００５】
Ｍａｃｒｏｖｉｓｉｏｎ ＦＬＥＸｎｅｔの方式では、ユーザには、自分の必要にしたがって権利の共有を制御する特別のメカニズムが提供されるが、それには限度があることは否定できない。例えば、そのライセンスはネットワークサーバに拘束され、このネットワーク上のユーザだけがこのライセンスにアクセスまたはこれを借用することが可能である。また、オプションファイルは人間によって構成され、エラーが発生しやすい。例えば、アドミニストレータは、ある部門内の様々なグループに対してライセンスを予約している場合に、予約されたライセンスの数がプールのキャパシティを超えるようなミスを犯すことがあり得る。このミスが気付かれないままとなって、あるグループが、結局予測していたより少ないライセンスしか共有できないことになるという結果になりかねない。オプションファイル（および、それゆえの共有分配）は明瞭なテキストファイルである。これはアドミニストレータのパスワードでしか保護されていないものである。ライセンスサーバは、ライセンスに対して実施するのと同じ権利管理タスクを実行することは不可能であるが、このタスクとは、信憑性とオプションの整合性とを検証することである。加えて、ライセンスよりもオプションファイルに基づいてアクセスを制御するため、コンテンツの携帯性が制限されるが、これは、上述のアクセス制御メカニズムが存在しないと、コンテンツにアクセスすることが不可能であるためである。コンテンツがペリメータ（ネットワークサーバのドメイン）から離れると、意図したアクセス制御はもはや当てはまらない。
【０００６】
使用を報告するというハードコーディングされたオプションは、ライセンスの購入者がライセンスのユーザに対して課すことを希望することが考えられる条件のうちの１つに過ぎない。ライセンスの購入者は、自分自身の条件を分配された権利に追加することが可能であるべきである。カスタムアクセス制御メカニズムは、委譲の１レベルをサポートするだけである。アドミニストレータだけが、これ以上自分の権利を分配することが不可能なネットワークユーザに対して権利を分配することが可能である。この委譲は、マルチレベルの委譲を必要とする階層構造には適していない。共有は、アクセス態様またはある行動の制御に焦点が合わされる。これは、規則やポリシーによって管理される汎用のリソース共有メカニズムではない。その設計は、ソフトウエアプログラムの動作を制御することにその重点がある。文書、オーディオファイル、ビデオファイルなどの他のタイプのデジタルリソースの制御を意図するものではない。
【０００７】
個人的ドメイン内での共有を可能とする別の形態のライセンスは、典型的にはエンドユーザライセンスと呼ばれるものである。このタイプのライセンスでは、ライセンス自体が、デバイスＩＤやユーザＩＤなどの特定の環境に拘束されていることが必要である。共有は、権利の所有者によってサポートされているビジネスモデルによって、特定の集合のデバイスタイプおよび／または最大数のデバイス内での共有に限られる。すべての共有デバイスが同じ権利を有するかまたは、各々のデバイスがそれ自体の別個の集合の権利を有するかのどちらかである。
【０００８】
エンドユーザライセンスの１つの例では、マイクロソフトのＷｉｎｄｏｗｓ（登録商標）のメディア権利管理システム（Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｍｅｄｉａ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）は、自分のパソコン上でコンテンツをプレイして他のデバイスにコンテンツを転送する権利を含む権利集合を、コンテンツの購入者に対して譲与してよい。このような転送権利には、このコンテンツを受信する資格があるデバイスのタイプと、このようなデバイスに対するいくつかの所定の権利とが指定される。転送された結果、さらに、パソコン上のライセンスにしたがって、対象デバイスは各々が、それ自体の別個の権利集合を有することになる。
【０００９】
別の例では、リアルネットワークへリックスＤＲＭ（Ｒｅａｌ Ｎｅｔｗｏｒｋｓ Ｈｅｌｉｘ ＤＲＭ）は、パソコン、セットトップボックス、ホームメディアサーバ、携帯電話などのあらゆるネットワーク接続されたデバイス（ネイティブデバイス（Ｎａｔｉｖｅ Ｄｅｖｉｃｅ）と呼ばれる）に対して、自分自身のコンテンツとライセンスを獲得する能力を提案する。へリックスデバイスＤＲＭは、ネイティブデバイスから、データの転送とこのデータに対するビジネス規則の執行とを目的としてネイティブデバイスに対する接続を必要としているデバイスであるセキュア受信機デバイスへの転送をサポートする。セキュア受信機デバイスの例には、専用音楽プレイヤや専用ビデオプレイヤが含まれる。セキュア受信機デバイス上で利用可能なのは再生権利だけである。
【００１０】
さらに別の例では、ＦＬＥＸｎｅｔのノードロックライセンスを特定のデバイスに拘束しておいて、このデバイスのみ上でこのライセンスを消費させるようにすることが可能であったり、または、特定のユーザ名に拘束しておいて、このライセンスを消費するデバイスが同じユーザ名を有していなければならないようにすることが可能である。この２つの要件のうち、前者は共有を許可しないのに対して、後者は同じユーザ名を有するデバイス間での共有を許可しているが、デバイスは名前で区別するのが好ましいため、これはあまり実用的ではない。
【００１１】
さらに別の例では、ＦＬＥＸｎｅｔモバイルライセンスはＦＬＥＸｎｅｔ ＩＤに拘束される。ＦＬＥＸｎｅｔ ＩＤを含むハードウエア（ドングル）は、認可されたユーザがライセンスを新しいデバイス上で消費することを決定すれば、この新しいデバイスに移動させなければならない。
【００１２】
したがって、エンドユーザライセンスによって許可された共有方式では、ユーザが、獲得した権利を、自分が適していると見なす何らかの方法で用いることが可能な最大限の権利として用いることは許可されない。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
このため、ユーザが、自分達の必要性にしたがって権利を共有することを可能とする動的権利共有をサポートするシステムに対する必要性が存在する。このシステムでは、獲得されたライセンスは権利のプールを表しているが、ここで、各々の権利をさらにサブ権利に分割することが可能である。サブ権利とは、権利を分配する単位である。
【課題を解決するための手段】
【００１４】
本発明は、権利からサブ権利を導出する方法に関するが、この権利は複数のコンポーネントを含み、これらコンポーネントはその各々が、権利の態様を指定している。本方法は一般的に、サブ権利を受信するステップであって、前記サブ権利が前記コンポーネントのうちの少なくとも１つを含み、前記コンポーネントの各々が前記サブ権利の態様を指定するステップと、前記サブ権利の前記コンポーネントの値が前記権利のうちの対応しているコンポーネントの値から導出することが可能であることを確認するステップと、を含む。コンポーネントは、例えば、主役、動作、リソースおよび条件であってよい。
【００１５】
本発明はまた、第１の権利を第２の権利と統合する方法に関する。この場合、本方法は、前記第１の権利のコンポーネントの各々がこれに対応する前記第２の権利のコンポーネントから導出することが可能であることを検証することによって、前記第１の権利が前記第２の権利から導出可能であることを判定するステップと、前記第１の権利を前記第２の権利のうちの前記対応するコンポーネントと合成するステップを含む。
【００１６】
さらに、本発明は権利を共有する方法に関する。本方法は、権利からサブ権利を導出し、前記サブ権利の使用を許可し、前記サブ権利を前記権利と統合するステップを含む。その結果、サブ権利は、共有目的でさらに導出することが可能である。加えて、権利はライセンス中に指定されることがあり、本方法はさらに、デバイス上で前記ライセンスをインストールするステップと、前記ライセンスをアンインストールするステップと、これらのライセンスを他のインストール動作に利用可能とするステップを含むことができる。
【００１７】
加えて、本発明は、権利からサブ権利を導出することを可能とすることによって権利共有をサポートするシステムに関するが、この権利は複数のコンポーネントを含み、このコンポーネント各々がこの権利の態様を指定し、前記システムは、サブ権利を受信するための受信モジュールであって、前記サブ権利が、各々が前記サブ権利の態様を指定する複数のコンポーネントを含む受信モジュールと、前記サブ権利の前記コンポーネントの値が前記権利のうちの対応するコンポーネントの値から導出可能であることを確認するための確認モジュールを備える。本システムはさらに、グループライセンスをデバイス上にインストールし、これを共有目的に対して利用可能とし、インストールされたグループライセンスをアンインストールし、これを現在のデバイス上での共有目的に対しては利用不可能とするためのインストールモジュールと、前記インストールされた／アンインストールされたグループライセンスを追跡するインストール追跡モジュールと、グループライセンスの権利の状態を追跡する追跡モジュールと、共有モジュールを備える。
【００１８】
本発明はさらに、譲与者から被譲与者に譲与された権利のプールからサブ権利を導出し、これによって、計算環境内でのリソースの使用を制御する方法に関するが、この計算環境は、この権利にしたがってリソースの使用を制御するためにこの環境内で権利を執行するメカニズムを有し、前記方法は、被譲与者が譲与者から権利のプールを受信し、前記権利のプールが少なくとも１つのリソースと関連付けられ、前記被譲与者が前記権利のプールを１つ以上の権利コンポーネントに解析し、前記権利コンポーネントの各々が前記権利プールの態様を指定し、前記権利コンポーネントのうちの少なくとも１つからサブ権利コンポーネントを導出し、前記サブ権利コンポーネントが対応する権利コンポーネントの部分集合であり、前記サブ権利コンポーネントからサブ権利を指定するライセンスを作成することを含み、前記ライセンスが、前記サブ権利に従って、また、前記権利のプールの範囲内で前記リソースの使用を制御するために前記計算環境によって執行することが可能である。本方法はさらに、前記ライセンスをサブ被譲与者に譲与するステップと、前記サブ被譲与者によって前記ライセンス中の前記権利を権利のサブプールとして１つ以上の第２の権利コンポーネントに解析するステップであり、前記第２の権利コンポーネントの各々が前記権利のサブプールの態様を指定するステップと、前記第２の権利コンポーネントのうちの少なくとも１つから第２のサブ権利コンポーネントを導出するステップであり、前記第２のサブ権利コンポーネントが対応する第２の権利コンポーネントの部分集合であるステップと、前記第２のサブ権利コンポーネントからサブサブ権利を指定するサブライセンスを作成するステップであり、前記サブライセンスが、前記サブサブ権利に従って、および前記権利のサブプールの範囲内で前記リソースの使用を制御するために前記計算環境によって執行することが可能であるステップを含む。
【００１９】
サブ権利について開示されている概念を解説するために、電子書籍（本）を５回プレイする権利を検討する。この権利のサブ権利とは、電子書籍をｎ回プレイする権利（ここで、０＜ｎ＜５）であり得る。プールのキャパシティ以内で共有される限りでは、このシステムは、ユーザが、獲得した権利を自由に分割して分配することを許可するが、これは、権利が同じネットワーク上のユーザに分配されるか互いに別々のネットワーク上のユーザに分配されるか、前記分配された権利が受信者によって消費されるか、または、他の認可済みのエンティティにさらに分配されるかとは無関係である。本システムは、権利をサブ権利に分割して、サブ権利の残余の部分を統合して、他者が使用するようにプールに戻す方法などの、権利のプールを維持するメカニズムを提供する。
【図面の簡単な説明】
【００２０】
【図１】譲与された権利のデータモデルと擬似表現言語との間のマッピングを示す。
【図２】擬似表現言語における無条件権利を示す。
【図３】プレイの回数に対する条件が付いた譲与権利を示す。
【図４】時間条件付きの譲与権利を示す。
【図５】２つ以上の条件が付いた譲与権利を示す。
【図６】図２に示す譲与権利をＭＰＥＧ−ＲＥＬで表現したものを示す。
【図７】図３に示す譲与権利をＭＰＥＧ−ＲＥＬで表現したものを示す。
【図８】図４に示す譲与権利をＭＰＥＧ−ＲＥＬで表現したものを示す。
【図９】図５に示す譲与権利をＭＰＥＧ−ＲＥＬで表現したものを示す。
【図１０】主体に基づいて、図４に示す譲与権利から導出された権利を示す。
【図１１】主体および条件に基づいて、図４に示す譲与権利から導出された権利を示す。
【図１２】指定された主体に基づいて譲与権利から権利を導出するプロセスを示す。
【図１３】条件に基づいて譲与権利から権利を導出するプロセスを示す。
【図１４】新しい権利が分割可能権利から導出されるシナリオを示す。
【図１５】新しい権利が無条件並列権利から導出されるシナリオを示す。
【図１６】新しい権利が条件付き並列権利から導出されるシナリオを示す。
【図１７】新しい権利が共有可能権利から導出されるシナリオを示す。
【図１８】グループライセンスを示す。
【図１９】新しいグループライセンスがグループライセンスから導出されるシナリオを示す。
【図２０】第２世代グループライセンスを導出するプロセスを示す。
【図２１】権利がグループライセンスに返却されるシナリオを示す。
【図２２】図１８に示すグループライセンスをＭＰＥＧ ＲＥＬで表現したものを示す。
【図２３】図１９に示すグループライセンスをＭＰＥＧ−ＲＥＬで表現したものを示す。
【図２４】グループライセンスの導出階層を示す。
【図２５】一般的なＤＲＭシステムを示す。
【図２６】動的な共有権利をサポートする基本的なコンポーネントを示す。
【図２７】共有権利をサポートする基本的コンポーネントの１つの可能性のある構成を示す。
【図２８】共有権利をサポートする基本的コンポーネントの１つの可能性のある構成を示す。
【図２９】共有権利をサポートする基本的コンポーネントの１つの可能性のある構成を示す。
【図３０】企業アプリケーション用の基本的コンポーネントの１つの可能性のある構成を示す。
【図３１】グループライセンスをインストールするプロセスを示す。
【図３２】情報を追跡する好ましい構造を示す。
【図３３】グループライセンスをアンインストールするプロセスを示す。
【図３４】権利の状態を証明して検証するプロセスを示す。
【図３５】グループライセンスをインストールするプロセスを示す。
【図３６】インストール要求を構築して認可するプロセスを示す。
【図３７】一般的に共有要求の一部である情報を示す。
【図３８】共有要求を処理する例示のデータフローを示す。
【図３９】権利を導出するプロセスを示す。
【発明を実施するための形態】
【００２１】
定義
【００２２】
権利とは、指定された状況または条件の集合の下で、一般的にはリソースに対して権利の被譲与者が動作または活動を実行するステートメントを表す。
【００２３】
権利表記(rights expression)とは、権利をデジタル形態で明示したものである。権利表記の例としては、これに限られないが、ＩＳＯ ＭＰＥＧ ＲＥＬ、ＸｒＭＬ、ＳＡＭＬ、ＸＡＣＭＬ、ＯＤＲＬ、ＯＭＡ ＲＥＬなどのＸＭＬベースの権利表記言語や、データ構造や、ビットフィールドがある。
【００２４】
ライセンスとは、権利表記を用いて捕獲された規則の表現である。ライセンスは、譲与された権利の完全な文脈を伝えている。ライセンス中で捕獲されている情報には、権利の譲与者、権利の被譲与者、リソース、許可ならびに関連する条項および条件が含まれている。
【００２５】
リソースとは、アクセス、使用、操作および／または分配が規則またはポリシーの集合によって管理され統御されるようなあらゆるコンテンツ、サービス、さらに権利さえも表すものである。
【００２６】
本開示に定義される動的な権利共有によって、権利の譲与者の決定権に対抗する権利の被譲与者の決定権において共有する能力が可能とされる。権利の譲与者は、権利の限度を指定する。この限度を示す条件内で、権利の被譲与者は、特定の権利共有メカニズムを決定することが可能である。権利の被譲与者はまた、多段階権利譲与連鎖においては譲与者でもあり得る。
【００２７】
権利の共有とは、譲与された権利をサブ権利に分割することを含む。次に、サブ権利がサブ被譲与者の集合に発行される。帰納的に、各々の被譲与者またはサブ譲与者はさらに、譲与連鎖を下るにつれて、他のサブ被譲与者とサブ権利を共有することが可能である。例えば、中心ライブラリＸは、ある本３０冊に対する権利を購入する。次に、ライブラリＸはこの３０冊のうちの１０冊を自分の姉妹ライブラリＹに分配する。したがって、ライブラリＸは、権利の譲与者として動作して、１０冊に対するサブ権利をライブラリＹに発行する。ライブラリＸから１０冊を受領すると、ライブラリＹはさらに、このうちの３冊をそのローカルライブラリＺのうちの１つと共有する。
【００２８】
本発明の第１の態様は、権利をサブ権利に導出して、サブ権利を、これらの導出元であるオリジナルの権利に統合して戻す方法である。本発明全体を通じて、サブ権利は導出された権利とも呼ばれる。権利の導出と統合は、権利を権利の被譲与者間で共有する基本的メカニズムとして働く。権利の被譲与者は、新しいサブ権利を導出することによって自分の権利を他者と共有する。その結果、新しいサブ権利の被譲与者は各々が、サブ権利を消費したり他者とさらに共有したりすることが可能となる。
【００２９】
本発明の第２の態様はグループライセンスであり、これは、一人以上の権利被譲与者の集合に対して最大限の権利を譲与して、これらの権利をこれら被譲与者間で動的に共有することを許可するシステム内で用いられる。グループライセンスの共有メカニズムは、サブ権利を導出して、これらサブ権利を含む共有ライセンスを発行する能力に基づいている。共有ライセンスとは、自分自身が、さらに共有可能なグループライセンスであり得る。したがって、グループライセンスは動的で多段階の権利共有をサポートする。
【００３０】
本発明の第３の態様は、権利被譲与者のグループ間で、および権利被譲与者のグループ全体にわたって権利を共有し、また、多段階に権利を共有することをサポートするためのグループライセンスを実施するシステムである。この開示されるシステムは、権利の消費を認可して、権利の使用と状態を追跡することが可能ないかなるＤＲＭシステム中でも実施することが可能である。
【００３１】
本発明は第１に、所与の権利からサブ権利を導出する方法を開示する。この方法は、サブ権利が、これらサブ権利の導出元であるオリジナルの権利の限度内であることを保証する。本方法は、動的権利共有システム中で権利の分割目的で用いることが可能である。
【００３２】
各々のサブ権利は、次の一人の（または複数の）権利被譲与者に対して、このサブ権利の導出元である権利の一部分または全体を譲与する。その結果、各々のサブ権利の消費が、このサブ権利の導出元の権利とも、また、他のサブ権利とも無関係に認可される。したがって、サブ権利を導出する能力は、動的権利共有のための基本的メカニズムである。
【００３３】
本発明はまた、グループライセンスと呼ばれる新しい概念を提示する。グループライセンスとは、一人以上の被譲与者に対して最大限の権利を譲与して、これら被譲与者による共有がこのグループライセンスによって許可された場合に、これらの被譲与者が、これら譲与された権利をこのような共有のポリシーにしたがって共有することを許可するライセンスのことである。このような共有がグループライセンスによって許可される場合には、共有するメンバーをこれら被譲与者以外にも拡大して、他の認可済みのユーザを含むようにしてもよい。
【００３４】
グループライセンスのセマンティックスでは、サブ権利の指定を導出する開示の方法が採用される。グループライセンスシステムは、サブ権利をライセンス発行認可プロセスの一部として導出し得る。グループライセンスシステムは、サブ権利が発行の時点でライセンスの限度内にある場合にだけ、これらサブ権利を含むライセンスの発行を認可する。この発行されたライセンスを被譲与者が用いたり、またはさらに分割したりして、グループライセンスを含むようにすることが可能である。加えて、グループライセンスのセマンティックスは、サブ権利の未使用の部分を統合して、サブ権利の導出元である権利に戻すことをサポートしている。
【００３５】
本発明はまた、権利の被譲与者間での動的な共有目的でグループライセンスを処理する例示のシステムを提示する。本システムはまた、未使用の共有権利を再統合してグループライセンスに戻す能力を有する。本開示のシステムは、様々な構成で設計して、権利の認可と追跡をサポートするＤＲＭシステムに統合することが可能な基本的コンポーネントの集合を含む。この好ましい例示のシステムに加えて、開示の概念を組み込んだ他の実施例を設計することが可能である。
【００３６】
共有のための権利を導出する方法
【００３７】
現行の権利共有メカニズムは、特定の用途向けに具体的に実現されるか、中心的認可によって共有を制御することを必要とするか、特定の環境内で共有することを必要とするかのいずれかである。このような共有方式では、権利の被譲与者が自身の権利を共有する機能が制限される。本発明は、権利の導出に基づいた新しい共有方法を開示する。本開示方法によって、権利を権利の被譲与者間で動的に共有することが可能となり、また、共有された権利をさらに他の権利被譲与者と共有することが可能となる。本開示方法は汎用性があり、権利とリソースを共有することを必要とするいかなるシステムにも適用可能である。
【００３８】
本発明は、最初に、権利の既存の実施例にマッピングすることが可能な権利の一般的なデータモデルを導入する。次に、本発明は、譲与された権利からサブ権利を導出して、サブ権利を統合してオリジナルの譲与された権利に戻す方法を開示する。権利を導出する方法と共に、本発明はまた、本開示の方法をどのように現行の共有方式に応用してその限界の一部に対処するかを記述する。
【００３９】
権利のデータモデル
【００４０】
権利の一般的なデータモデルｕは次のように表される。
ｕ＝（ｐ，ａ，ｒ，ｃ）
ここで、
ｐは、動作ａが譲与される対象である主体、主体の集合または匿名の主体である。したがって、ｐは一人以上の権利の被譲与者である。
ａは、ｐが実行することを許可された動作または活動であり、
ｒは、動作ａと関連付けられたリソースであり、
ｃ＝｛ｃi｜ｉ＝０．．ｎ｝は、ｐがｒに対してａを実行する指定された状況を構成する条件の集合である。ｃiはｕと関連付けられた条項および条件と呼ばれる。
【００４１】
ｕ中に指定されているｐ、ａ、ｒおよびｃiはその各々が、譲与された権利ｕのコンポーネントと呼ばれる。解説目的で、この一般的データモデルは、次の擬似表現言語にマッピング可能とされる。
GRANTED RIGHTS（譲与された権利）
PRINCIPAL p（主体ｐ）
ACTION a（動作ａ）
RESOURCE r（リソースｒ）
CONDITIONS c（条件ｃ）
【００４２】
図１に、権利ｕ（１００）のデータモデルと上記の擬似表現言語１０１との間のマッピングを示すが、ここで、譲与された権利ｕは表現「GRANTED RIGHTS（譲与された権利）」にマッピングされ、主体ｐは表現「PRINCIPAL p（主体ｐ）」にマッピングされ、動作ａは表現「RIGHTS a（権利ａ）」にマッピングされ、リソースｒは表現「RESOURCE r（リソースｒ）」にマッピングされ、条件ｃは表現「CONDITIONS c（条件ｃ）」にマッピングされている。
【００４３】
この権利のデータモデルはまた、一般目的用のリソース共有にも適している。ａを「使用する」や「所有する」などの一般的動作として定義すると、本発明の開示するデータモデルやシステムおよび方法を用いて、ｃ中に指定されている条件によって統御される広範囲のリソース共有を達成することが可能である。この場合、権利ｕ中に指定されている動作ａはどのような用途にも応用される。その結果、本発明の残りの部分に開示される共有システムと共有方法は、リソースを共有するシステムおよび方法と見なすことが可能である。例えば、計算リソースの所有者が、ＣＰＵサイクルを共有して、学問的研究のプロジェクトに対する並行処理を容易化することを意図する。この所有者は、委託された同僚がＣＰＵのアイドルサイクルを用いて実行する特定のタイプのプログラムを知りたいとは思わない。この使用シナリオでは、所有者は、主体ｐを委託された研究コミュニティ内のいずれかのメンバーとして、動作ａをいずれかの使用として、リソースｒをＣＰＵサイクルとして、条件ｃを１０ｐｍ〜６ａｍのいずれかの時点として定義している権利ｕを発行する。この譲与された権利によって、委託された研究コミュニティのメンバーは、１０ｐｍ〜６ａｍでのＣＰＵサイクルを共有することを許可される。この例では、共有される第一の対象は、動作ａではなくてリソースｒである。
【００４４】
本明細書に記載する以下の図面は、上記の擬似表現言語で表現された譲与権利の例を示すものである。図２は、アリス(Alice)であると特定された主体に、「風とともに去りぬ(Gone With The Wind)」というタイトルのＤＶＤを見る(View)権利が譲与されるという、条件を有さない譲与権利１２０を示す。図３は、１つの条件が付いた譲与権利１３０を示す。音楽クラブ(Music Club)と特定された主体に、ルイ・アームストロング(Louis Armstrong)の「この素晴らしい世界(What a wonderful world)」というＣＤをプレイ(Play)する権利が譲与される。この譲与された権利には、このＣＤのプレイ回数(Number of Play)を１００回に制限する条件１３１が付いている。図４は、１つの条件付きの譲与権利１４０を示す。音楽クラブと特定された主体に、ルイ・アームストロングの「この素晴らしい世界」というＣＤをプレイする権利が譲与される。この譲与された権利には、このＣＤをプレイすることが許される期間を２００６年１月までに制限する条件１４１(Not after Jan. 2006)が付いている。図５は、２つの条件が付いた譲与権利１５０を示す。音楽クラブと特定された主体に、ルイ・アームストロングの「この素晴らしい世界」というＣＤをプレイする権利が譲与される。この譲与権利には、このＣＤをプレイする回数を１００回に制限する条件１５１と、このＣＤをプレイすることを許される期間を２００６年１月までとする条件１５２が付いている。
【００４５】
上記の擬似表現言語は例示目的で本発明の全般にわたって用いられているが、本発明は、いずれの特定の権利表記言語も、データ構造も、表現などにも制限されるものではない。
【００４６】
権利のデータモデルは、多目的のものであり、どのような形態の権利表記をもモデリングすることが可能である。例えば、図６、７、８および９では、図２、３、４および５とそれぞれ同じ譲与権利を表現するのにＭＰＥＧ ＲＥＬ（１２５、１３５、１４５および１５５）を用いる。
【００４７】
別の例では、上記の権利データモデルを用いて、コピー絶対禁止、コピー自由、１世代コピーなどの保護されたコンテンツの保護状態を表す２ビットであるコピー制御情報ビット（ＣＣＩビット）の構造を次のようにモデリングすることが可能である。
ｕ＝（ｐ＝ｎｕｌｌ，ａ＝ＣＣＩ，ｒ＝ｎｕｌｌ，ｃ）
ここで、ｐはコンテンツを受信するデバイスを意味し、ａはコピー動作であり、ｒはＣＣＩビットが関連付けられているコンテンツを意味し、条件ｃはコピー動作に対する制限である。このような制限には、コピー絶対禁止、コピー自由、１世代コピーなどが含まれる。
【００４８】
第３の例では、次のＦＬＥＸｎｅｔライセンスは、ライセンスサーバマシン「ｌｕｌｕ」にアクセス可能なすべてのデバイスに対して、特徴「ｆ１」に対する２つのライセンス、特徴「ｆ２」に対する６つのライセンスおよび特徴「ｆ３」に対する１つのライセンスを譲与する。
「SERVER lulu 17007ea8
VENDOR sampled
FEATURE f1 sampled 1.00 1-jan-2005 2 SIGN=signature1
FEATURE f2 sampled 1.00 1-jan-2005 6 SIGN=signature2
FEATURE f3 sampled 1.00 1-jan-2005 1 SIGN=signature3」
SERVER：サーバ
VENDOR：ベンダー
sampled：サンプリング済み
FEATURE：特徴
1-jan-2005：２００５年１月１日
SIGN：サイン
signature：著名
【００４９】
上記の権利データモデルを用いると、上記のＦＬＥＸｎｅｔライセンスを、次のように互いに別個の３つ権利にマッピングすることが可能である。主体ｐは、ＦＬＥＸｎｅｔフロートライセンス中の認可サーバのホストＩＤまたはＦＬＥＸｎｅｔ特徴が拘束されるノードのホストＩＤである。上記のＦＬＥＸｎｅｔの例では、主体ｐは、ライセンスサーバ「ｌｕｌｕ」にアクセス可能なすべてのデバイスである。動作ａは、ＦＬＥＸｎｅｔライセンスの特徴(FEATURE)ラインに指定されている特徴を実行する権利である。リソースｒは、ＦＬＥＸｎｅｔライセンス中に指定されている特徴である。上の例では、リソースｒは、ＦＬＥＸｎｅｔの特徴ｆ１、ｆ２およびｆ３である。条件ｃは、ＦＬＥＸｎｅｔライセンスの特徴(FEATURE)ライン中に指定されている制限である。上の例では、特徴ｆ１に対する条件は２つのライセンスであり、特徴ｆ２に対する条件は６つのライセンスであり、特徴ｆ３に対する条件は３つのライセンスである。
【００５０】
上記の権利データモデルに基づくと、権利は無条件となるが、これは、図２に示す譲与権利などのように関連の条件を何も有さないことを意味する。他方、権利は条件付きであるとは、図３および４に示す譲与権利の例などのように１つ以上の条件と関連していることを意味する。
【００５１】
譲与権利ｕ＝（ｐ、ａ、ｒ、ｃ）に指定されている条件ｃは、一般的には、満足しなければならない条件または、主体ｐにとってリソースｒに対して動作ａを実行するために実施しなければならない義務である。権利と関連付けることが可能な条件には、無状態条件および状態条件という２つのタイプが存在する。
【００５２】
無状態条件とは、状態とは無関連の条件である。このような条件は、譲与権利を行使するために実行されなければならない義務のことである。このような条件は、譲与権利の寿命には直接には関連していない。無状態条件は一般的には、ビジネス上の規則（支払い方法、関連者各々に支払うべきパーセンテージなど）、認可規則（権利の行使の承認要請など）、システム要件などに関連している。
【００５３】
状態条件とは、１つ以上の状態と関連付けられた条件のことである。このような条件は、譲与された権利を行使可能な回数や、譲与権利が行使される時間ウインドウなどの譲与権利の寿命中のある活動に直接的に関連している。状態条件は、その状態の特徴によってさらに２つのタイプに分割することが可能である。
【００５４】
基準条件とは、状態を修正することなく読み取る状態条件のことである。このタイプの条件によれば、現在の値から次の値への状態の遷移は、譲与権利の行使や消費とは無関係である。例えば、図４に、譲与権利が行使される時間ウインドウを規定する条件を示す。この例では、状態の現在値は、譲与権利が行使されようとされまいと、時間の経過とともに変化し続ける。
【００５５】
分割可能条件とは、状態を読み取って更新する状態条件のことである。このタイプの条件によれば、現在値から次の値への状態の遷移は、譲与権利が行使されるごとに始動される。例えば、図３に、譲与権利が行使される回数を規定する条件を示す。この例では、状態の現在値は、譲与権利が行使されるごとに減少する。
【００５６】
状態に対する条件の依存性を組み込むため、上に開示した譲与権利ｕ＝（ｐ、ａ、ｒ、ｃ）のデータモデルは次のように展開可能である。
ｕ＝（ｐ，ａ，ｒ，ｃi⇒Ｑi：ｉ＝１，．．，ｎ）
【００５７】
ここで、（ｃi⇒ Ｑi：ｉ＝１，．．，ｎ）は、Ｑiが、ｉ＝１，．．，ｎの場合に条件ｃiと関連している状態であることを意味する。条件ｃiが無状態条件であれば、Ｑiは
空である。権利の状態は、この権利と関連しているすべての条件の状態で表される。
【００５８】
権利の導出と統合
【００５９】
譲与権利ｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）に指定されている主体ｐは、１つの主体ではなく主体のグループを表している。例えば、図４に、２００６年１月までに行使を制限する条件付きのルイ・アームストロングの「この素晴らしい世界」というＣＤをプレイする権利が音楽クラブに譲与されている様子を示す。「音楽クラブ」とは、人々のグループのことであり、音楽クラブの人であれば誰でも、現在の時点が２００６年１月以降でなければこのＣＤをプレイしてもよい。
【００６０】
アリスであると特定された主体が音楽クラブのメンバーであれば、アリスは、図４に指定されている権利を行使して、「この素晴らしい世界」というＣＤをプレイすることが可能である。しかしながら、図１０に示すように、アリスはまた、図４に指定されている譲与権利と同じ条件１４１が付いた「この素晴らしい世界」というＣＤをプレイする権利１４２も譲与されている。主体のアリスにとっては、図４に指定されている譲与権利と図１０に指定されている譲与権利の双方はまったく同じである。したがって、図１０の譲与権利は図４の譲与権利の具体的なインスタンスであるので、図１０の譲与権利は、図４の譲与権利から導出された権利であると考えることが可能である。同様に、図１１に、図４の譲与権利から導出された権利１４３を示す。この例では、条件１４４は変更されてはいるが（Not After Jan. 2005：２００５年１月まで）、図４の譲与権利の条件１４１の範囲内にとどまっている。
【００６１】
主体ｐと同様に、ｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）中のｐ、ａ、ｒまたはｃiの各々は、それぞれ主体のグループ、動作、リソースまたは条件を互いに独立に示すことが可能である。したがって、様々な権利が、所与の文脈内ではまったく同じであるという場合がある。この場合、このような権利は互いに関連し、ある権利を他の権利から導出される。
【００６２】
導出規則
【００６３】
ｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）とｖ＝（ｐ’、ａ’、ｒ’、ｃ’i⇒Ｑ’i：ｉ＝１，．．，ｍ）とを２つの権利であるとする。ｖは、ｍ≦ｎであり、次の規則が当てはまれば、ｕから導出されたといわれる。
規則Ｄ１：ｐ⇒ｐ’，ａ⇒ａ’，ｒ⇒ｒ’
規則Ｄ２：∀i≦ｍ，ｃi⇒ｃi’
規則Ｄ２．１：Ｑiが、ｃiの可能な状態値を表す非順序集合であれば、Ｑ’i＝Ｑi、0−ＱiここでＱi、0はｖの導出に先立つｕの状態である。
規則Ｄ２．２：Ｑiが、ｃiの累積値を表す唯一の値を含む場合、‖Ｑ’i‖≦‖Ｑi,0‖，‖Ｑi‖≦‖Ｑi,0‖および‖Ｑi‖＋‖Ｑ’i‖≦‖Ｑi,0‖、ここでＱi、0はｖの導出に先立つｃiの状態を表し、表記‖Ｑi‖はＱiのノルム（すなわち値）を意味する。
規則Ｄ２．３：Ｑiが、ｃiの可能な範囲値を表す順序集合であれば、Ｑ’i⊂Ｑi,0およびＱ’i∩Ｑi＝、ここでＱi、0はｖの導出に先立つｕの状態である。
【００６４】
表記ｐ⇒ｐ’は、ｐはｐ’を意味するまたはｐはｐ’を導出するまたはｐ’はｐから導出されたことを意味する。例えば、アリスはまた「キーホルダーＡ(Key Holder A)」としても知られ、したがって、アリスは「キーホルダーＡ」を意味する。ｐ⇒ｐ’であるかどうかを判定する規則はアプリケーションによって異なる。しかしながら、ｐ’がｐと同じであったり、ｐ’がｐのインスタンスであったり、ｐが空であったりする特殊な場合があるが、このような場合にはｐ⇒ｐ’となる。
【００６５】
規則Ｄ１は、サブ権利は、これが導出された元の権利によって許可されている主体、動作およびリソースだけを指定すべきことを定めている。より具体的には、規則Ｄ１は、サブ権利を遵守することを必要としている。主体ｐ’はｐから導出されなければならない。例えば、ｐが「部門Ｘのいずれかの被雇用者」である場合、アリスが実際に部門Ｘの被雇用者であれば、ｐ’＝”Ａｌｉｃｅ（アリス）”はｐから導出されたと言われる。動作ａ’はａから導出されなければならない。例えば、ａが「修正（注釈という動作を含む）という動作と変更するという動作」であれば、ａ’＝"the annotation of annotating（注
釈する動作）"は、ａから導出されたと言われる。リソースｒ’はｒから導出されなけれ
ばならない。例えば、ｒが「出版社Ｙのいずれかの本」である場合、「ラーニングＸＭＬ」が出版社Ｙから出版されていれば、ｒ’＝"Learning XML（ラーニングＸＭＬ）"は、ｒから導出されたと言われる。
【００６６】
規則Ｄ２は、各々の条件ｃ’iがこれに対応するｃiから導出されなければならないことを述べている。ある条件の状態の導出は、この条件のタイプ、そのあり得る状態およびその現在値によって異なる。規則Ｄ２．１〜Ｄ２．３は、以下に解説するようにこの依存性を定めている。
【００６７】
規則Ｄ２．１を解説するために、ｃを、異なる多くのチャプタ、例えば、チャプタ１、３および５に対する印刷を制限する条件であるとすると、Ｑ＝｛chapter 1, chapter 3, chapter 5（チャプタ１、チャプタ３、チャプタ５）｝となる。第１のサブ権利を導出する場合、有効なＱ’の集合は、｛chapter 1｝、｛chapter 3｝、｛chapter 5｝、｛chapter 1, chapter 3｝、｛chapter 1, chapter 5｝、｛chapter 3, chapter 5｝および｛chapter 1, chapter 3, chapter 5｝となる。｛chapter 1｝が第１のサブ権利に譲与された後、Ｑは｛chapter 3, chapter 5｝となり、Ｑ’は、｛chapter 3｝、｛chapter 5｝および｛chapter 3, chapter 5｝のうちの１つでしかあり得ないことになる。
【００６８】
規則Ｄ２．２を解説するために、ｃを、再生動作を３回に制限する条件であるとすると、Ｑ＝｛３｝となる。第１のサブ権利を導出する場合、有効なＱ’の集合は、｛１｝、｛２｝および｛３｝である。例えば、｛２｝が第１のサブ権利に譲与された場合、ｃの現在値は１であり、Ｑ’は、｛１｝でしかあり得ないことになる。
【００６９】
規則Ｄ２．３を解説するために、ｃを、再生動作の有効期間を１１／１／２００４〜１１／５／２００４に制限する条件であるとする。Ｑを、｛｛１１／１／２００４〜１１／２／２００４｝、｛１１／１／２００４〜１１／３／２００４｝、｛１１／２１／２００４〜１１／３／２００４｝｝などの１１／１／２２０４〜１１／３／２００４の可能なすべてのサブインターバルの順序集合であるとする。インターバル｛１１／２／２００４〜１１／３／２００４｝が第１のサブ権利に譲与されると、Ｑは｛｛１１／１／２００４〜１１／２／２００４｝、｛１１／３／２００４〜１１／５／２００４｝｝となる。
【００７０】
したがって、上記で定義した導出規則は、ｐがｐ’を意味し、ａがａ’を意味し、ｒがｒ’を意味し、ｃiがｃ’iを意味し、Ｑ’i⊂Ｑi ∀ｉ≦ｍ≦ｎであれば、譲与された権利ｖ＝（ｐ’、ａ’、ｒ’、ｃ’i⇒Ｑ’i：ｉ＝１，．．，ｍ）をｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）から導出可能であることを提示している。
【００７１】
ここで、ｖは、ｕから導出されなかった条件を含むことがあり得る。これらの条件は本発明では制限された条件と呼ばれる。制限された条件によって、サブ権利の譲与者は、権利の被譲与者がサブ権利を消費するのをさらに制限することが許可される。サブ権利ｖが何らかの制限された条件を含む場合、これはときとして条件付きサブ権利と呼ばれる。例えば、会社Ｘがその部門Ｙに対して、この部門Ｙが部門の目標の少なくとも８０％を達成すればＤＶＤ Ｚを１０コピー譲与する。ｖをｕに統合して戻す場合、すべての制限された条件が無視される。
【００７２】
ｐとｐ’との間、ａとａ’との間、ｒとｒ’との間、ｃiとｃ’iとの間の関係はアプリケーションによって異なる。これらの関係は、アプリケーション内で定義可能であったり、権利表記中で表現可能であったりする。このような関係をアプリケーション内で定義すると、このアプリケーションは一方の式が他方によって意味されるかどうか判定する。関係を権利表記中で表現すると、アプリケーションは、１つの式が別の式を意味するかどうかを、これらの式を権利表記に照らし合わせて評価することによって検証することが可能である。
【００７３】
ｖ＝（ｐ’、ａ’、ｒ’、ｃ’i⇒Ｑ’i：ｉ＝１，．．，ｍ）がｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）から導出されると、ｖは、ｕの導出またはｕのサブ権利であると言われる。言い換えれば、ｕはｖの統合と言われる。例えば図１０および１１に示す譲与された権利は、図１４に指定した譲与された権利のサブ権利である。ｖがｕから導出されると、ｖはｕの導出またはサブ権利と呼ばれる。
【００７４】
図１２に、譲与権利１６０の導出を示す。譲与権利１６０は主体ライブラリＡに譲与され、コピーの数に関連する１つの条件を有する。主体であるジョン・ドエがライブラリＡのメンバーであれば、譲与権利１６２は譲与権利１６０から導出される。この例では、譲与権利１６１は２つの条件を含む。条件１６３はジョン・ドエに対してリソースを１コピーだけ与える。条件１６４は、ジョン・ドエがリソースを使用することに対して時間制限を割り当てる。
【００７５】
同様に、図１３は、別のデバイス上で用いられる譲与権利１７０の導出を示している。譲与権利１７０は、主体のジェーンがリソースを２コピー用いることを提示する１つの条件１７１を有する。導出された権利１７２は、ジェーンがリソースを１コピー用いることを制限する条件１７３を含む。
【００７６】
統合規則
【００７７】
権利を統合する方法は、権利を導出する方法の逆である。
【００７８】
権利をｕ、サブ権利をｖとすると、ｖを統合してｕに戻す規則は次のように定義される。
定義：ｕ＝（ｐ、ａ、ｒ、ｃi、1⇒Ｑi：ｉ＝１，．．，ｎ）を権利として、ｖ＝（ｐ’、ａ’、ｒ’、ｃ’i、2⇒Ｑ’i：ｉ＝１，．．，ｍ）をｕのサブ権利とする。ｍ≦ｎであって、次の規則が適用されると、権利ｕ’＝（ｐ、ａ、ｒ、ｃi⇒Ｑ*i：ｉ＝１，．．，ｎ）は権利ｕとそのサブ権利ｖの統合であると定義される。
規則Ｉ１：ｐ⇒ｐ’、ａ⇒ａ’、ｒ⇒ｒ’
規則Ｉ２：∀i≦ｍ、ｃi⇒ｃi’
規則Ｉ２．１：Ｑiが、ｃiの可能な状態値を表す非順序集合であれば、Ｑ’iもまたｃ’iの可能な状態値を表す非順序集合でなければならず、また、Ｑ*i＝Ｑi∪Ｑ’iである。
規則Ｉ２．２：Ｑiが、ｃiの累積値を表す唯一の値を含む場合、‖Ｑ*i‖＝‖Ｑi‖＋‖Ｑ’i‖、ここで‖Ｑi‖は、Ｑiのノルム（すなわち値）を意味する。
規則Ｉ２．３：Ｑiが、ｃiの可能な範囲値を表す順序集合であれば、Ｑ’iもまたｃ’iの可能な範囲値を表す非順序集合でなければならず、また、Ｑ*i＝Ｑi（＋）Ｑ’iである。（＋）は、カスタマイズされた和集合演算であり、システムによって異なる。例えば、範囲の粒状性と、範囲をどのようにすれば合併可能な（範囲を合併しながらもギャップをどのように取り扱うかを含めて）定義することが可能である。
【００７９】
規則Ｉ１は、サブ権利が、この導出元の権利によって許可されたような主体、動作およびリソースのみを含まなければならないことを定めている。規則Ｉ２は、条件ｃ’i各々が、その対応するｃiから導出されなければならないことを提示している。条件の状態の導出は、この条件のタイプ、その可能な状態値およびその現在状態値によって異なる。規則Ｉ２．１〜Ｉ２．３は、この依存性を定義している。特に、規則Ｉ２．１は、ＱおよびＱ’が双方とも判明している値の非順序集合であれば、統合されたＱ*はＱおよびＱ’の和集合であると述べている。規則Ｉ２．２は、ＱおよびＱ’各々が、累積値を表す１つのエレメントを有すれば、統合された累積値はこれら２つの値の和であることを述べている。規則Ｉ２．３は、ＱおよびＱ’がインターバルを表す順序集合であれば、統合されたＱ*は双方の集合の和集合であることを述べている。
【００８０】
分割可能権利、現在の権利、共有可能権利およびグループライセンス
【００８１】
上記で定義した導出規則は、サブ権利を所与の権利から導出する、または、所与の権利が別の権利から導出可能であるかを判定するための一般的なメカニズムである。この規則は、サブ権利が次のメカニズム、すなわち、譲与権利のいずれかのコンポーネントを用いてサブ権利を導出するメカニズムと、何らかの状態条件を分割して、譲与権利からサブ権利を作成するメカニズムのうちのどちらかまたは双方を用いて導出することが可能であることを指定している。
【００８２】
しかしながら、様々なアプリケーションでは、譲与権利のあるコンポーネントだけをサブ権利を導出するために用いることを許可、または、ある状態条件だけを分割してサブ権利を作成することを許可し得る。例えば、ライブラリアプリケーションは、譲与権利に指定されている主体を用いてサブ権利を導出することを許可しているため、ライブラリは、そのメンバーのためのサブ権利をライブラリに譲与された権利から導出することが可能である。図１２は、ライブラリＡが、そのメンバーであるジョン・ドエのためにその譲与権利からサブ権利を導出する様子を示している。図１２では、サブ権利は主体に基づいて導出される。
【００８３】
別の例では、ホームネットワークアプリケーションが、ある条件状態を分割することを許可している。この場合、ホームネットワークのユーザは、ユーザに譲与された権利からユーザのホームネットワーク内の各々のデバイス用の権利を導出することが可能である。図１３は、ユーザのジェーンがジェーンの譲与権利から別のデバイス上で用いるための権利を導出するシナリオを示している。この例では、サブ権利は、譲与権利と関連する条件状態の分割可能性に基づいて導出される。
【００８４】
譲与された権利は、サブ権利を導出する機能に基づいて次のタイプ、すなわち、分割可能権利、並列権利、共有可能権利およびグループ権利に分類することが可能である。これらのタイプの権利の各々を以下に説明する。
【００８５】
分割可能権利
【００８６】
分割可能権利とは、ある権利をサブ権利を作成するために分割しながらも同時にこの分割可能権利の他のコンポーネントを不変のままとすることが可能なような１つ以上の状態条件付きのこのような権利のことである。分割可能権利の用途は多い。例えば、これらは、消費者が権利を公平に用いることを刺激するために用いることが可能である。消費者は、ある権利を獲得すると、これをサブ権利に分割して、様々なデバイス上で、様々な場所で、様々な時間でなどのように用いる。
【００８７】
サブ権利が分割可能権利から導出されると、オリジナルの分割可能権利中の各々の分割可能条件の現在状態を、この導出されたサブ権利の各々中の対応する条件の初期状態とこの条件の状態関数とにしたがって更新される。例えば、分割可能権利は、ユーザが権利を行使可能な回数を制限する条件を有し、また、現在の条件状態が、まだ行使の回数が５回残っていることを示していると仮定する。最大で２回の行使回数を有するサブ権利を導出する場合、導出元の分割可能権利の条件の現在状態を更新して、３回行使回数が残っていることを反映する（行使回数５回から２回を差し引く）。
【００８８】
導出されたサブ権利の基準条件は、オリジナルの分割可能権利の同じ基準条件に関して制限される。例えば、分割可能権利が、この権利を行使し得る時間範囲を指定する条件を有する場合、導出されたサブ権利もまた、権利を行使し得る時間範囲を規定する基準条件を有さなければならず、また、サブ権利の時間範囲は、この分割可能権利に対して指定された時間範囲内に完全に入らなければならない。
【００８９】
したがって、権利ｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）は、ｃｉが分割可能条件であるようなｉが少なくとも１つあれば、分割可能である。さらに、ｖ＝（ｐ、ａ、ｒ、ｃ’i⇒Ｑ’i：ｉ＝１，．．，ｍ）は、次の仮定が成立すれば導出またはｕのサブ権利である。
ｃiが分割可能条件であるようなｉが少なくとも１つ存在する、
ｖが、ｕ中に指定されているすべての条件を含み、ｃ’i＝ｃi、ｉ＝１，．．，ｎ、および、Ｑ’i⊂Ｑi、∀i≦ｍ≦ｎであり、
導出ｖ後のｕの各々の分割可能条件ｃiの現在状態が、導出ｖ前のｃiの現在状態と、導出ｖの初期状態およびｃiの現在関数にしたがって更新され、
すべての基準条件ｃiに対して、ｃ’iがｃiであるかｃiの制限であるかである。例えば、条件ｃiが時点ｔ１以前ではなく、導出された条件ｃ’iはｔ３以前ではなくｔ４以後ではないが、ここでｔ１＜＝ｔ３＜＝ｔ４＜＝ｔ２であり、表記＜＝は「以下」を表し、
すべての無状態条件ｃiに対して、ｃi’はｃiである。
【００９０】
図１４は、分割可能権利ｕ（２００）からサブ権利ｖ（２１０）を導出するプロセスを示す。この例では、分割可能権利ｕは３つの条件を有する。
行使許可回数が１０であると規定している分割可能条件２０１の現在状態２０２は行使回数が５回残っている、
権利行使可能な時間範囲を基準条件２０３が（２００４年１月以後であり、２００６年１月以前）規定している、
譲与権利を行使している間に宣伝Ｙを実施しなければならないと無状態条件２０４が規定している。
【００９１】
同じ条件集合付きのｕからサブ権利ｖ（２１０）が導出される。特に、
分割可能条件２１１の場合、ｖは、行使許可回数として２回を規定している条件を有する。ｕ中の同じ条件の現在状態が、残余行使回数５回から残余行使回数３回に更新される。
基準条件２１３の場合、ｖは、権利を行使し得る時間範囲を規定している条件を有する。この条件はｕから導出され、したがって、ｖに規定されている時間範囲条件は、ｕ中に規定されている時間範囲内に完全に入る。
無状態条件２１４の場合、ｖはｕとまったく同じ条件を有する。
【００９２】
導出後、分割可能権利ｕ（３００）の現在状態２０５は残余プレイ回数が３回である。
【００９３】
この例では、擬似言語のフォーマットが、譲与された権利と条件の特徴を反映するように変更されている。したがって、「GRANTED RIGHTS（譲与権利）」は、譲与権利が実際に分割可能であることを示す「DIVISIBLE RIGHTS（分割可能権利）」に変更されている。「CONDITION（条件）」は、条件タイプを反映するように、「DIVISIBLE CONDITION（分割可能条件）」、「REFERENCE CONDITION（基準条件）」または単に「CONDITION（条件）」に変更されている。分割可能条件の宣言には、条件の現在状態が含まれている。
【００９４】
このフォーマット変更は、特定の実現を提案するものではない。譲与された権利と条件のタイプを特定するために用いられる方法は、実現に委ねられる。例えば、このタイプは表現に明示的に宣言されている（図４のように）または他のいずれかのメカニズムを用いて特定された名前によって特定可能である。しかしながら、条件タイプの明示的な宣言には利点がある。同じ条件（例えば、最大の許可行使回数）が、１つの譲与権利中で分割可能であるが、他の権利中ではそうではない。分割可能条件の現在状態は、条件内（図４のように）宣言されるか、または、既知の認可ソース（認可された追跡デバイス、遠隔サービス、中央サービスなど）から検索されるかである。
【００９５】
並列権利
【００９６】
並列権利とは、サブ権利を主体に基づいて導出可能な元の権利であり、この場合、この並列権利の他のコンポーネントは不変のままである。並列権利においては、主体とは、主体のグループ、多数の識別を有する同じ主体または双方のことである。グループ中の主体はその各々が、並列権利中に指定されている同じ権利を継承する。並列権利によって、譲与権利中に指定されている主体が導出可能となり、指定されている主体に対するサブ権利が導出可能となるようにする。
【００９７】
並列権利は状態条件を含むが、このような条件は分割可能ではない。サブ権利が状態条件付きの並列権利から導出されると、状態条件がサブ権利中で正確に（同じ状態値で）再現される。その結果、サブ権利中の条件状態は、導出された主体ごとに個々に管理される。したがって、導出された主体は各々が、状態を個々に維持して、譲与権利の消費を追跡する。
【００９８】
例えば、並列権利として、グループの各メンバーに対して同じ権利集合を与えるメンバー資格がある。一部のアプリケーションでは、権利消費デバイスが、並列権利中の主体によって指定されているグループに対して特定の主体が実際に属していることを証明することが不可能である場合には、サブ権利を並列権利から導出することが必要となる。
【００９９】
権利ｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）は、次の条件が成立すれば並列権利である。
ｃiが、すべてのｉに対して分割可能条件ではなく、
ｐ⇒ｐ’となるようなｐ’が少なくとも１つ存在し、また、権利ｖ＝（ｐ’、ａ、ｒ、ｃi⇒Ｑi：ｉ＝０，．．，ｎ）がｕの導出である。例えば、ｐが音楽クラブであり、ｐ’が音楽クラブのメンバーであるアリスであれば、ｐ⇒ｐ’である。別の例では、ｐがアリスであり、アリスはまた、「Key Holder A（キーホルダーＡ）」としても知られている。すると、ｐ⇒ｐ’であり、ここで、ｐ’は「キーホルダーＡ」である。
【０１００】
図１５は、音楽クラブの各々のメンバーに、ルイ・アームストロングの「What a wonderful world（この素晴らしい世界）」というＣＤをプレイする無制限の権利を譲与する並列権利ｕ（２２０）を示す。この例では、主体のジョン・ドエは、音楽クラブのメンバーである。したがって、ジョン・ドエは、主体ジョン・ドエに同じＣＤをプレイする無制限の権利を譲与するサブ権利ｖ（２２１）を導出することが可能である。
【０１０１】
図１６は、状態条件２２６を含む並列権利ｕ（２２５）を示す。この例では、この並列権利は、音楽クラブのメンバーが、ルイ・アームストロングの「この素晴らしい世界」というＣＤを５回プレイすることを指定している。導出前の現在状態２２７では、プレイ回数が３回残っている。サブ権利ｖ（２３０）とｗ（２３５）を導出する場合、並列権利中の状態条件の現在状態（オリジナルの最大回数である５回のうちの３回が残っている）が、それぞれ条件２３１と２３６としてサブ権利の各々中で再現される。導出後は、サブ権利ｖおよびｗの条件状態は互いに独立に追跡される。グループの各々のメンバーの条件状態は、中央認可サーバ、ユーザデバイスなどで追跡可能である。
【０１０２】
共有可能権利
【０１０３】
共有可能権利とは、主体と、もしあれば、その分割可能条件の状態との双方に基づいてサブ権利を導出することが可能な元の権利のことである。したがって、共有可能権利は、指定された主体間で共有可能な最大限の権利を指定する。導出された主体が共有可能権利からサブ権利を導出すると、条件状態を、導出されたサブ権利に割り当てられた条件状態にしたがって共有権利から推論する。
【０１０４】
並列権利と分割可能権利は、共有権利の特殊な場合である。特に、並列権利は、分割可能条件無しの共有可能権利の特殊なケースであり、分割可能権利は、少なくとも１つの分割可能条件付きであるが、それから導出することが不可能な主体（主体はグループを指定しない）付きの共有権利の特殊なケースである。
【０１０５】
共有権利と並列権利間の主要な相違は、導出されたサブ権利中の状態条件の状態をどのように追跡するかという点である。並列権利中の状態条件は分割可能ではないため、各々の導出されたサブ権利の条件状態は互いに独立に追跡される（状態は、各々のサブ権利の主体に対して別個に追跡される）。共有可能権利中の状態条件は分割可能であるため、導出されたサブ権利の条件状態は共有される（すべての導出されたサブ権利は、各々の分割可能条件に対して同じ状態を指し示している）。この結果、サブ権利の主体が条件状態を共有することになる。
【０１０６】
図１７は、「この素晴らしい世界」というＣＤを１００コピー所有して、この１００コピーをメンバー間で分配する権利を音楽クラブに譲与する共有可能権利ｕ（２４０）を示す。この例では、分割可能条件の現在状態２４１は、１０コピーが今までに分配され、９０コピーが残っていることを示している。音楽クラブのメンバーであるジョン・ドエという主体は、サブ権利ｖ（２４２）中にこのＣＤを１コピー譲与される。サブ権利ｖは、１コピーの状態２４３付きの共有可能権利ｕから導出される。共有可能権利ｕ中の分割可能条件の現在状態２４４は、残りのコピー数が８９に減少する。
【０１０７】
分割可能権利と並列権利用のアプリケーションを含む、共有可能権利の特徴を利用可能なアプリケーションは多く存在する。このようなアプリケーションの１つは、「グループライセンス」と呼ばれ、以下に説明する。
【０１０８】
グループライセンス
【０１０９】
グループライセンスとは、一人以上の認可されたユーザに対して最大限の権利を譲与して、この認可済みユーザが、自分たちの間での自分たち自身の共有ポリシーにしたがって譲与権利を共有したり、他の認可済みユーザの集合と共有したり、認可済みユーザが共有権利を返却したり、さらに、他の認可済みユーザと各々の共有権利をさらに共有したりすることを許可する権利のことである。したがって、グループライセンスは、サブ権利を返却したり、統合してグループライセンスに戻したりすることを許可する共有権利である。
【０１１０】
本発明中に定義するように、ライセンスとは、あるユーザに譲与された権利のことである。したがって、「ライセンス」と「権利」という用語は、交換可能である。多くのＤＲＭシステムがライセンスに対して異なった定義をしているが、ライセンスは少なくとも１つの譲与された権利を含まなければならない。したがって、ＤＲＭシステムで使用されるライセンスの定義を、本発明中のライセンスの定義にマッピングすることが可能である。例えば、ＭＰＥＧ ＲＥＬでは、「ライセンス」という用語は、譲与権利の集合に、他の情報（発行者、ライセンスの整合性などに関する情報など）を足したものである。したがって、ＭＰＥＧ ＲＥＬライセンスは、本発明に定義するように多数のライセンス中にマッピングすることが可能である。
【０１１１】
上記のようなグループライセンスの概念は、共有可能な権利と権利の統合という概念を用いて実現することが可能である。グループライセンスは、共有可能権利であるため、認可されたユーザおよび／または認可済みユーザのグループ中で共有されるように動的に分割可能である。あるグループライセンスを共有目的で分割すると、新しいライセンスが作成されて、グループライセンス中に指定されている条件状態が、新しいライセンス中に指定されている条件状態を推論するように調整される。この作成された新しいライセンスは共有されたライセンスと呼ばれるが、また、グループライセンスでもある。したがって、共有されたライセンスは、認可済みのユーザによって消費するか、または、認可済みのユーザおよび／または認可済みユーザのグループ間で共有目的でさらに分割することが可能である。
【０１１２】
共有されたライセンスはまたグループライセンスでもあるため、この共有ライセンスの権利被譲与者は、権利譲与者として動作して、下流での共有目的でその共有ライセンスから新たな共有ライセンスをさらに導出することが可能である。したがって、多段階権利共有や、権利被譲与者の決定権に基づいた共有や、異なったグループの主体および／またはデバイス間での共有などの動的権利共有がサポートされる。
【０１１３】
共有ライセンスは、一旦作成されると、消費目的利用可能となる。共有ライセンスが使用されるごとに、その条件状態が更新されて、その使用を反映するようにする。どの時点でも、共有ライセンスの残っている権利は、上に開示した権利統合方法を用いて、このライセンスの導出元であるグループライセンスに対して返却することが可能である。
【０１１４】
グループライセンスの概念は、権利とリソースの共有、デバイス間での共有、ユーザ間での共有、組織間での共有などに関するあらゆる態様をカバーしている。グループライセンスは、権利とリソースの動的共有を可能とする多くのアプリケーションに対する基本的な要素となりえる。このようなアプリケーションには、これに限られないが、次のものがある。
ライブラリ：あるライブラリが、「風とともに去りぬ」という題名の本をある数だけに対するグループライセンスを譲与される。いつでも、このライブラリは、この本のコピーを、そのグループライセンスから共有ライセンスを導出することによってライブラリメンバーに貸し出すことが可能である。このライブラリが共有ライセンスを導出すると、利用可能なコピーの総数は、ライブラリメンバーがこの本を返却するまで減少する。
ホームネットワーク：ユーザのホームネットワークは、様々なＤＲＭ能力を有する様々なデバイスを含んでよい。ユーザは、前もってどのネットワークデバイスがライセンスを消費するかを指定することなく、ユーザのホームネットワーク内で使用する目的でライセンスを購入するという利便性を欲しがる。この目的のため、ユーザはグループライセンスを獲得して、ホームネットワーク中の特定のデバイスのためにそれから共有ライセンスを導出する。
メンバー資格：あるグループのメンバーは、このグループに譲与されている一般的なライセンスを用いる代わりに自分たち自身のための特定的なライセンスを導出したがるが、これは、ユーザデバイスが一般的ライセンスを執行することが不可能であるからである。
【０１１５】
次の例は、グループライセンスの概念とグループライセンスからどのように共有ライセンスを導出するかを示している。
【０１１６】
図１８は、映画Ｂの１００コピーの権利を企業Ａに譲与するグループライセンス２５０を示す。グループライセンスは、最初に作成されたときは、最大コピー数を１００と規定し、１００コピーが残っているという現在状態を規定する分割可能条件を含む。企業Ａは、営業上の必要性にしたがってその被雇用者または被雇用者グループ間に映画Ｂの１００コピーというプールを分割してよい。
【０１１７】
図１９は、グループライセンス２５０中のその１００コピーというプールから映画Ｂの１０コピーをその人事部門に譲与する。企業Ａは、人事部門に対して映画Ｂの１０コピーに対する権利を譲与する共有ライセンスを導出するが、これは条件２５６に反映される。図１９はまた、図１８に示すグループライセンス中の条件状態２５１をどのように更新して、１００コピーのプールから１０コピーを差し引いて９０コピーが残るようにするかを示している。
【０１１８】
企業Ａが人事部門に譲与する共有ライセンス２５５もまた、さらに分割可能なグループライセンスである。図２０は、グループライセンス２５７と条件２６１に反映されるように、企業Ａの人事部門がその被雇用者のうちの一人であるジョン・ドエに対して、映画Ｂの１コピーに対する権利を譲与する様子を示している。図２０はまた、人事部門のライセンス中の条件状態２５６をどのように条件状態２５７に更新して、１０コピーのそのプールから１コピーを差し引いて９コピーが残るようにするかを示している。図２０はまた、人事部門が映画Ｂの１コピーをジョン・ドエに譲与する動作が、企業Ａのオリジナルのグループライセンス中の条件状態２５１に影響しない（企業Ａにはいまだ９０コピーが残っている）ことを示している。
【０１１９】
ジョン・ドエに映画Ｂの１コピーを譲与した後では、図２１に示すように、人事部門は、その残っているコピーのうちの２つを企業Ａに返却すると決心する。返却したら、企業Ａのグループライセンス２５０に対する残りのコピーの数は２だけ増加して条件状態２５１中の９０コピーから条件状態２５２中の９２コピーとなり、同時に、人事部門のライセンス２５５に対する残りのコピーの数は２だけ減少して条件状態２５７中の９コピーから条件状態２５８中の７コピーになる。
【０１２０】
図２２は、映画Ｂの１００コピーというプールの共有を許可する企業Ａのグループライセンス（図１８に示す）の擬似ＭＰＥＧ ＲＥＬ表現２６０を示す。企業Ａは、このプールを被雇用者のグループ間に、コピーの総数がプールのキャパシティを超えない限り各々のグループに対して共有ライセンスを発行することによって分割してよい。分配する権利は、ｓｅｅｋＡｐｐｒｏｖａｌ条件を条件とする発行権利を用いて指定される。このｓｅｅｋＡｐｐｒｏｖａｌ条件は、追跡サーバが、プール中のコピーの残数と共有ライセンスに対して要求されているコピーの数とを追跡することに依存している。分配可能な使用権利は、内部譲与に含まれている。これには、受領側ユーザグループの識別のプレースホルダとしての変数Ｙと、受領側グループに割り当てられたコピーの数のプレースホルダとしての変数Ｘと、企業Ａが共有ライセンスに追加したがっているいずれかのカスタム条件のプレースホルダとしての変数Ｚが含まれている。
【０１２１】
図２３は、企業Ａの人事部門（図１９に示す）に対するライセンスの擬似ＭＰＥＧ ＲＥＬ表現２６５を示す。変数Ｙ、Ｘ、およびＺに、人事部門（受領側グループの識別）、１０（人事部門に割り当てられたコピー数）および使用報告（すべての使用を指定されたサーバによって追跡される必要がある）が代入される。その他の情報は、現在のライセンスと、現在のライセンスが導出する元のライセンスとを特定する。
【０１２２】
図２４は、サブグループライセンスと共有ライセンスの双方がグループライセンスから導出される使用事例を示す。中心ライブラリＣは、本Ｂを１００回コピーすることを許可するグループライセンス２８０を獲得する。中心ライブラリは、その必要性によってローカルライブラリのためにそのグループライセンスからサブグループライセンス２８１と２８２を作成する。Ｃは、２０コピーをサブループライセンス２８２中でローカルライブラリＸに分配し、３０コピーをサブグループライセンス２８１中でライブラリＹに分配する。ローカルライブラリＹはさらに、サブグループライセンス２８４中でライブラリＺにそのコピーの１０コピーを分配する。さらに、共有ライセンス２８３、２８６、２８７が、グループライセンス２８０、サブグループライセンス２８２、サブグループライセンス２８１またはサブグループライセンス２８４から発行されてよい。
【０１２３】
権利とリソースの動的共有をサポートするシステム
【０１２４】
上記に開示したグループライセンスの概念は、権利共有のあらゆる態様をカバーしている。これは、共有可能権利の消費を認可し、分散された共有権利を含むライセンスを発行し、グループライセンスと共有可能ライセンスの双方に対する権利の状態の管理が可能なあらゆるＤＲＭシステムによって実現可能である。図２５は、このようなＤＲＭシステムの例を示す。ＤＲＭシステム３００は、例えば、起動サーバ３０２、認可サーバ３０３、１つ以上の権利消費デバイス３０５、保護コンテンツ／アセット分配サーバ３０８、ライセンスサーバ３１０および保護アプリケーション／サービス３１１を含む。認可サーバ３０３は、１つ以上のキー３０４と関連付けられてよい。権利消費デバイス３０５はＤＲＭコンポーネント３０６を含み、また、１つ以上のライセンス３０７と関連付けられる。保護コンテンツ／アセット分配サーバ３０８は、保護されたコンテンツ／サーバ３０９を分配する。ライセンスサーバ３１０は、本システムにライセンス３０７を提供する。保護アプリケーション／サービス３１１は、明瞭なコンテンツ／アセット３１２と権利提案を提供するが、これは権利と条件とを含む。
【０１２５】
図２６は、動的な権利とリソースの共有をサポートするシステムの基本的なコンポーネントを示す。これらのコンポーネントには、インストールコンポーネント３２１、インストール追跡コンポーネント（ＴＣＩ）３２２、共有追跡コンポーネント（ＴＣＳ）３２３、共有コンポーネント３２４、委託コンポーネント３２５、消費コンポーネント３２６および消費認可コンポーネント３２７が含まれる。各々のコンポーネントは、ハードウエアコンポーネント、ソフトウエアコンポーネント、デバイス、サービスなどとして実現可能である。グループライセンスは、一旦権限によって発行されると、その使用を追跡する元となる特定の環境に拘束されたりされなかったりする。本発明の好ましい実施形態では、グループライセンスは環境には初期は（ライセンス発行時は）拘束されない。このプロセスによってより大きなフレキシビリティが与えられるが、これは、グループライセンスは、特定の環境に限られることなくどこでもいつでも獲得することが可能であるからである。
【０１２６】
図２６に示すように、グループライセンス３２０は、環境に拘束されなかった場合には、共有されたり使用されたりすることが可能となる前にインストールコンポーネント（ＩＣ）３２１によってインストールされなければならない。ＴＣＩ３２２がこのインストールを認可する。このインストールの目的は、グループライセンス３２０が以前にはインストールされていなかったこと、そして、これからはグループライセンスの権利の状態を追跡する、共有追跡コンポーネント（ＴＣＳ）と呼ばれる追跡コンポーネント３２３にグループライセンスが拘束されることを保証することにある。
【０１２７】
グループライセンスの権利の状態はどのデバイスにでも保存可能であるが、権利の状態は、権利の共有を制御する共有コンポーネントによって証明され、検証されなければならない。例えば、権利の状態は、インストールされたグループライセンスと同じデバイスに保存するか、グループライセンスが拘束されている認可コンポーネントと同じデバイスに保存するか、遠隔サービスに保存するか、または、グループライセンス内に保存することが可能である。権利の状態の保存する様々な考えられる戦略が、図１７、１８、１９、２０および２１ならびに本発明の他の図面に図示されている。権利の状態がグループライセンス自体内に保存された場合、権利の状態が更新されるごとにグループライセンスは変換されて（なぜならライセンスが消費されたか、または、権利が行使されたからである）、新しい状態を反映するようにする。この新しい状態を有するグループライセンスが交換グループライセンスであれば、オリジナルのグループライセンスは、一旦交換グループライセンス中の新しい状態を反映するために変換されたら無効となる。
【０１２８】
グループライセンスは、一旦インストールされれば、インストール済みグループライセンスと呼ばれ、共有目的に対して利用可能となる。共有コンポーネント（ＳＣ）３２４は、要求を、インストールされたグループライセンスを解釈し、ＴＣＳ３２３から現在の権利状態を検索し、この現在の権利状態をこの要求に照らし合わせて検証し、共有ライセンス（認可されれば）作成することによって処理する。インストールされたグループライセンスから導出されたこの共有ライセンスは、委託証明目的で委託コンポーネント３２５に対して利用可能なものとされる。
【０１２９】
この共有ライセンスは、これ自体が、さらなる共有目的で利用可能とされるグループライセンスである。これは、次の形態のうちの１つであり得る。
拘束グループライセンス：このタイプのライセンスは、作成されるとＴＣＳに対して拘束される。共有ライセンスが拘束されるＴＣＳは、インストールされたグループライセンスが拘束されるＴＣＳと同じでも異なっていてもよい。編成が小さい場合、追跡コンポーネントは同じでもよいが、編成が大きかったり主体のグループが多様であったりすれば異なったものとなる。
非拘束グループライセンス：このタイプのライセンスは、発行されたときには特定のＴＣＳに拘束されていないが、後になってＴＣＳに拘束されることがあり得る。このタイプのライセンスは、ライセンスが生成されるときに対象の消費環境または対象のＴＣＳが知られていない場合に生成される（例えば、別の権利被譲与者グループ、別のネットワークなどとの共有のためにライセンスを作成する）。別のシナリオでは、ライセンスの譲与者は、ＴＣＳに拘束するオプションを維持することによってライセンスのフレキシビリティをより大きいものとすることを提案したがる。このような状況下では、ＴＣＳ拘束権限をライセンス被譲与者または他の当事者に委譲することも可能である。
消費ライセンス：このタイプのライセンスは、共有ではなく主として消費目的で作成される。しかしながら、これは、認可された主体またはデバイス間で共有することが可能である。
【０１３０】
図２６に示す基本的コンポーネントを用いて、様々な構成でシステムを設計することが可能である。消費ライセンスが作成されると、消費コンポーネント３２６は、消費認可コンポーネント３２７によって認可されればリソースの消費を可能とする。
【０１３１】
図２７は、主要な２つのデバイス、すなわち、グループライセンスデバイス３５０と消費デバイス３５６を含む１つの好ましい実施形態を示す。グループライセンスデバイス３５０は、インストールコンポーネント３５１と共有コンポーネント３５２をそれぞれ含む。これは、グループライセンスをインストールしたり、アンインストールしたり、共有ライセンスを作成したりするすべての要求を取り扱う。消費デバイス３５６は、ライセンスを消費するための消費コンポーネント３５７を含む。この例示の構成では、インストール追跡コンポーネント（ＴＣＩ）３５３、ＴＣＳ３５４および委託コンポーネント３５５は、グループライセンスデバイス３５０の外部にある。共有認可デバイスは、自身に拘束されたすべてのインストール済みグループライセンスの権利の状態を追跡する。
【０１３２】
図２８は、代替の構成を用いる別の好ましい実施形態を示す。この実施形態では、ＴＣＳ３５４はグループライセンスデバイス３５０の内部にある。この構成では、グループライセンス３５０は、共有要求を処理して、インストールされたすべてのライセンスの権利の状態を追跡する。したがって、グループライセンスデバイス３５０は、外部のＴＣＳを必要とすることなく共有要求を認可することが可能である。一旦共有要求が認可されたら、グループライセンスデバイス３５０は、共有ライセンスを作成してこの共有ライセンスを委託の証明目的で委託デバイス３５５に対して利用可能とする。
【０１３３】
図２９は、別の代替構成を用いるさらに別の好ましい実施形態を示す。この構成では、ＴＣＳコンポーネント３５４と委託コンポーネント３５５は双方ともがそれぞれ、グループライセンスデバイス３５０の内部にある。グループライセンスデバイス３５０は、すべての共有要求を処理し、インストールされたすべてのグループライセンスの権利の状態を追跡し、デバイスによって生成された共有ライセンスを証明する。これは、現在最新のＤＲＭシステムに統合するには最も実用的な構成である。
【０１３４】
図３０は、企業Ａの場合の図２９に示す構成のアプリケーションを示す。企業Ａのネットワーク内では、グループライセンスデバイス３６０がグループライセンスサーバ３６１にインストールされている。グループライセンスデバイス３５０は、この企業のネットワーク内のすべてのデバイスに対するすべての共有要求の処理専門のデバイスである。グループライセンスサーバ３６１は、グループライセンスのあらゆるインストール要求を認可する目的でネットワークを介してインストール認可デバイス３７０を含むインストール認可サーバ３６９に接続されている。企業Ａではまた、共有認可デバイス３６３をインストールしている認可サーバ３６２は、この企業内で用いられるグループライセンスの権利のすべての状態を追跡する業務専門となっている。加えて、企業Ａのネットワークは、プリンタ３６４、ワークステーション３６５、ｉＢｏｏｋ３６６およびラップトップコンピュータ３６７などの他のデバイスと、さらにアダプタデバイス３６８を含む。ネットワーク内での通信は、例えば、ハブ３７１によって容易化される。
【０１３５】
追跡コンポーネント
【０１３６】
どのＤＲＭシステムにも、追跡コンポーネントは存在する。追跡コンポーネントの機能は、権利の使用または状態を追跡することである。本発明内では、追跡とは、グループライセンスのインストールステータスを追跡したり、インストールされたグループライセンスに対する権利の状態を追跡したりすることが含まれる。本発明では、インストールを追跡するコンポーネントをインストール追跡コンポーネント（ＴＣＩ）と呼び、グループライセンスに対する権利の状態を追跡するコンポーネントを共有追跡コンポーネント（ＴＣＳ）と呼ぶ。
【０１３７】
ＴＣＩとＴＣＳの機能は、上記と同じまたは別のコンポーネントでも実施可能である。これらの機能は、同じデバイスやサービスまたは別のデバイスやサービスで実施されるように構成可能である。追跡用のデバイスやサービスは、どこに置かれても、動的権利共有をサポートするシステム中の他のコンポーネントによって委託されなければならない。システム内のすべてのコンポーネントによって委託される権限による証明などのこのような委託を確立する多くのメカニズムが知られている。
【０１３８】
インストール追跡コンポーネント（ＴＣＩ）
【０１３９】
このコンポーネントは、インストールされたグループライセンスの権利の初期状態と、インストールされたライセンスの権利の状態を追跡する共有追跡コンポーネントの識別（ＴＣＳＩＤ）とともにグループライセンスのインストールステータスを追跡する。上述したように、インストールステータスを追跡する目的は、グループライセンスが、その権利の状態を追跡するＴＣＳにしか拘束できないことを保証することである。
【０１４０】
図３１は、どのようにしてインストール要求を追跡するかを示す。このプロセスに対する入力には、グループライセンスとＴＳＣのＴＣＳＩＤを含む。グループライセンスの整合性と信憑性はステップ４００で確認される。整合性は、グループライセンスが変更されたり改竄されたりされていないことを保証するために確認される。信憑性は、グループライセンスがＴＣＩに委託された権限によって発行されたことを保証するために確認される。入力されたグループライセンスが有効で真正であれば、グループライセンスは、ステップ４０１で、期限切れや取り消しされていないかどうかチェックする。次に、ＩＡＣはステップ４０３で追跡情報を検索して、このグループライセンスが現在インストールされているかどうかステップ４０４でチェックする。グループライセンスが有効でなければ、真正でなければ、期限切れであれば、取り消されていればまたは現在インストールされていれば、この要求はステップ４０２で拒絶される。そのようでなければ、権利の初期状態がグループライセンスから初期化され、追跡情報がステップ４０５で作成されて、ステップ４０６で権利の初期状態で更新される。
【０１４１】
グループライセンスが以前にはインストールされているが現在はインストールされていない場合、ＴＣＩは権利の状態を検証して、グループライセンスに指定されている権利が今は有効であることを保証する。そのようでない場合、インストール要求は拒絶される。
【０１４２】
追跡情報が見つからないまたはグループライセンスがインストールされたことがないことを示している場合、新しい追跡情報を作成して、権利の初期状態で更新して、この追跡情報をインストール済みであるとマーキングする。グループライセンスが以前にインストールされていて権利がまだ有効である場合、追跡情報はインストール済みであるとマーキングされる。
【０１４３】
図３２は、追跡情報４１０の好ましい構造を示す。これは、インストールされたグループライセンスもしくはライセンスＩＤ４１１、（アンインストールプロセス中に用いられる）権利の状態を追跡するコンポーネントのＴＣＳＩＤ４１２、現在のインストールステータス４１３、最初にインストールされたときもしくはアンインストールされたときのグループライセンスに対する権利の状態４１４およびアプリケーションが必要とする他の情報４１５を含む。
【０１４４】
一旦インストール要求が譲与されると、追跡情報に保存されている現在の権利状態が、インストールコンポーネント（ＩＣ）である要求元に返却される。その結果、このインストールコンポーネントは、この権利の状態を共有コンポーネント（ＳＣ）に渡して、グループライセンスの権利の初期状態を初期化することが可能となる。
【０１４５】
グループライセンスは、一旦インストールされると、最初にアンインストールされるまでは再度インストールすることは不可能となる。アンインストールプロセスによって、グループライセンスは、その権利の状態を現在追跡しているＴＣＳから解放される。アンインストールプロセスでは、インストールされたグループライセンスまたはライセンスＩＤと要求メッセージが必要とされる。この要求メッセージは、グループライセンスに対する現在の権利状態を含む認証可能メッセージである。
【０１４６】
図３３は、アンインストールするプロセスを示す。追跡情報が、入力されたグループライセンスまたはライセンスＩＤを用いてステップ４２０で検索される。次に、追跡情報がステップ４２１で検証されて、これが、グループライセンスが現在インストールされていることを示していることを保証する。加えて、ステップ４２２で、追跡情報に照らし合わせて要求を検証する。追跡情報が見つからなければ、グループライセンスは現在インストールされていないか、または追跡情報が要求に照らし合わせて検証されていない場合、ステップ４２５で要求は拒絶される。
【０１４７】
グループライセンスが現在インストールされていれば、ステップ４２２で、ＴＣＳＩＤ中に保存されているＩＤを用いて、要求メッセージを検証する。要求メッセージには、インストールされたグループライセンスに対する現在の権利状態が保存されている。多くの既知のメカニズムを用いて、要求メッセージを検証することが可能である。例えば、要求メッセージをＴＣＳで署名すると、ＴＣＳＩＤがＴＣＳのキーを含み、このキーを用いてＴＣＳの署名を検証する。ＴＣＳの署名が検証可能であれば、要求は真正である。そうでなければ、アンインストール要求は信用されない。
【０１４８】
認証可能なメッセージと証明された現在の権利の状態とが検証されたら、ＴＣＩはステップ４２３で、グループライセンスの現在の権利の状態で追跡情報を更新して、ステップ４２４で、証明された現在の権利の状態で追跡情報をアンインストールされたものとしてマーキングする。
【０１４９】
共有追跡コンポーネント（ＴＣＳ）
【０１５０】
このコンポーネントは、インストールされたグループライセンスに対する権利の状態を追跡する。グループライセンスは、一旦インストールされると、ＴＣＳに拘束される。ＴＣＳに拘束されることの利点は、権利の状態がたった１集合だけ維持されるように保証されることである。これによって、多くの様々なグループライセンスデバイスが、グループライセンスに対する権利の状態にコンフリクトを引き起こすことなく権利共有要求を処理して、共有ライセンスを発行することが可能となる。例えば、ホームネットワークにおいて、ＴＣＳがインストールされているデバイスに接続可能であればどのグループライセンスデバイスでも、ホームネットワーク中のデバイスで用いられるように共有ライセンスを発行することが可能である。
【０１５１】
グループライセンスがインストールされると、ＴＣＳの認証可能ＩＤ（ＴＣＳＩＤ）が検索されて、ＴＣＩに対して利用可能なものとされる。ＴＣＳＩＤは、アンインストール要求メッセージを認証するために後で用いられる。一旦インストールされると、ＴＣＩによって返却されたグループライセンスに対する権利の状態を用いて、ＴＣＳに保存されている権利の状態を初期化する。さらにセキュリティを高めるため、ＴＣＳは、権利の状態と他の情報に、これらをＴＣＳに保存する前にサインする。図３４に、ＴＣＳに保存する以前にそしてこれらをＴＣＳから検索した後で、権利の状態にサインし、証明し、検証するプロセスを示す。
【０１５２】
インストールされているグループライセンスがアンインストールされると、ＴＣＳは要求メッセージを生成するが、このメッセージは、アンインストールされたグループライセンスに対する現在の権利状態を含む認証可能メッセージである。すると、現在の権利状態がアンインストールの対象となるＴＣＩに渡される。インストールされたライセンスが使用、共有、統合目的で処理された場合はいつでも、ＴＣＳは、権利の状態が変化すると、その新しい状態で更新される。
【０１５３】
一部のアプリケーションでは、権利の状態はＴＣＳがインストールされているデバイスのところには保存されない。権利の状態は、維持されるかどうかとは無関係に、委託可能となるようにＴＣＳによって証明されなければならない。例えば、権利の状態はグループライセンス内に保存可能である。この場合、グループライセンス自体がレポジトリとして動作する。共有ライセンスが作成されたり統合されたりした結果、グループライセンスが変化すると、このグループライセンスも変化する。新しい権利の状態を持つグループライセンスは対象のＴＣＳによって証明されなければならない。証明されたグループライセンスは新たなグループライセンスとなって、以前のグループライセンスに取って代わる。新たなグループライセンスは、一旦作成されると、以前のグループライセンスと同じＴＣＳに拘束され、以前のグループライセンスはＴＣＳから解放される。新しいグループライセンスと以前のグループライセンスは双方とも、同じＩＤを共有する。この場合、以前のグループライセンスのインストール状態が新しいグループライセンスに転送される。
【０１５４】
インストールコンポーネント
【０１５５】
インストールコンポーネントは、グループライセンスをＴＣＩにインストールしたりアンインストールしたり、インストールされたグループライセンスをＴＣＳに対して拘束したりこれから解放したりする。拘束プロセスでは、ＴＣＳへのインストールされたグループライセンスに対する権利の状態を初期化し、これで、認可された共有コンポーネントが権利の状態を管理して追跡することが可能となるようにする。ＴＣＩにグループライセンスをインストールすることによって、このインストールされたグループライセンスが別のＴＣＳにこれ以上インストールされて拘束されることがあり得ないことを保証する。これによって、グループライセンスに譲与された権利が、複数のＴＣＳ上で複製されたり増殖されたりされることを防止する。例えば、映画Ａの２つのコピーを譲与するグループライセンスが互いに異なった２つのＴＣＳに拘束されると、ＴＣＳはその各々が譲与された権利の状態を２に初期化する。これは、各々のＴＣＳがコピーを２つ共有することを許可し、したがって、グループライセンスの条項と条件に違反することを意味する。
【０１５６】
グループライセンスが獲得されたりインストールされたりすると、インストール追跡コンポーネント（ＴＣＩ）のＩＤをインストールコンポーネントに通信し、これが正しいＴＣＩからのインストールを要求することが可能となるようにしなければならない。発行されたグループライセンス中のＴＣＩのＩＤやアドレスの符号化、何らかの既知のプロトコルを通じてのＴＣＩのＩＤやアドレスの獲得、グループライセンス権利の譲与者と被譲与者間の合意の利用など、この通信を実行する方法が多く存在する。一部のアプリケーションでは、ＴＣＩは、グループライセンス権利の譲与者のシステムの一部である。ＴＣＩがグループライセンス権利の被譲与者のシステムの一部であるアプリケーションもある。さらに、ＴＣＩが独立したサービスであるような他のアプリケーションもある。
【０１５７】
図３４に示すように、拘束するプロセスでは、グループライセンスに対する権利の初期状態が、このグループライセンスが拘束されるＴＣＳに登録される。ステップ４３０および４３１では、権利の状態の整合性値が計算され、次いで証明される。権利の状態は、一旦初期化されて証明されると、状態レポジトリ４３２に保存される。次に、ＴＣＳは、グループライセンスが使用されるごとに権利の状態を管理して追跡する。一部のアプリケーションや構成では、ＴＣＳとＴＣＩの機能が１つのコンポーネントに合成されるが、これらの機能を別々のコンポーネントに分離する他のアプリケーションや構成もある。例えば、組織Ｙ用にグループライセンスを発行するシステムＺの認可サーバＸがＴＣＩとして動作し、一方、組織Ｙ内の認可サーバＺがＴＣＳとして動作する。しかしながら、組織Ｙの認可サーバＺがシステムＺによって委託コンプライアンスしていることが証明されると、Ｚは、ＴＣＩとＴＣＳ双方として機能することが許可される。
【０１５８】
上述したように、インストールされると、グループライセンスはＴＣＳに拘束され、権利の状態を初期化して管理することが可能となるようにする。例えば、証明内容はステップ４３３で検証可能であり、整合性値はステップ４３４で再計算可能であり、また、整合性値はステップ４３５で比較可能である。しかしながら、グループライセンスは、共有または使用目的でグループライセンスを処理するデバイスが、グループライセンスの権利の状態を適切に管理可能となるようにＴＣＳと対話可能であるかぎり、いかなるデバイスにも保存することが可能である。
【０１５９】
以下のセクションでは、グループライセンスのインストールとアンインストールをより詳細に説明する。
【０１６０】
グループライセンスのインストール
【０１６１】
インストールプロセスでは、ＴＣＩによって認可を要求し、グループライセンスが現在はインストールされていないことを保証し、また、現在の権利状態を獲得するようにしなければならない。インストールプロセスでは、グループライセンスに対する権利の現在の状態でＴＣＳが初期化される。
【０１６２】
図３５は、次のステップからなるグループライセンスをインストールするプロセスを示す。最初のステップ４４０では、グループライセンスの整合性および信憑性ならびにグループライセンスに対する権利の状態が検証される。グループライセンスの整合性を検証することによってこれが改竄されていないことを保証し、これが信頼すべきソースから発行されたことを保証するグループライセンスの信憑性を検証する。整合性と信憑性を検証する方法は、グループライセンスの表現によって異なる。最も一般的な方法では、デジタル署名を用いてグループライセンスの整合性を保証し、デジタル証明書を用いてグループライセンスの信憑性を保証する。しかしながら、アプリケーションが異なれば、グループライセンスの整合性と信憑性を保証する採用方法も異なる。グループライセンスに対する権利の状態を検証することによって、いずれかの条件の現在状態がこの条件が期限切れであることを示していると判定されると、このグループライセンスはインストール目的で処理されることはない。
【０１６３】
次のステップ４４１では、対象とするＴＣＩからの認可を要求する。このステップでは、対象のＴＣＩとＴＣＳを特定する。ＴＣＩとＴＣＳの双方が一旦特定されたら、インストール要求が構築される。すると、ＴＣＳが認可されて、そのＴＣＳＩＤが検索されて、インストール要求が構築される。図３６に示すように、目標とするＴＣＩによる認可に対する要求は、グループライセンスとＴＣＳのＴＣＳＩＤとからなる。このＴＣＳＩＤを後で用いて、アンインストールに対する要求を認証する。ＴＣＩは、グループライセンスが譲与される組織の外部またはその一部である。ＴＣＩは、要求されたグループライセンスがインストールの要求時にはまだインストールされていないことを検証する。一旦インストール要求が認可されると、グループライセンスに対する現在の権利状態が返却されて、グループライセンスは、アンインストールされるまでは再度インストールすることは不可能である。したがって、インストールすることによって、グループライセンスが複数回インストールされることが効果的に防止される。
【０１６４】
３番目のステップ４４２では、目標のＴＣＳ付きのインストール済みグループライセンスに対する現在の権利状態が初期化される。ＴＣＳは、（グループライセンス中でのように）前もって指定したり、何らかのプロトコルや合意によって獲得することが可能である。ＴＣＳ付きのインストール済みグループライセンスに対する権利の状態を初期化するプロセスによって、ＴＣＳは、グループライセンスに対する権利の状態を、これらの権利が変更される度に追跡することが可能となる。
【０１６５】
４番目のステップ４４３では、インストールされたグループライセンスをライセンスレポジトリに保存する。このライセンスレポジトリは、グループライセンスが拘束されるＴＣＳとは独立しているが、ライセンスレポジトリは一部の構成ではＴＣＳの一部である。
【０１６６】
図３６は、インストール要求を構築して認可するプロセスを示す。最初に、グループライセンスのＴＣＩとＴＣＳの双方がステップ４５０で特定される。この特定が合格すれば、目標となるＴＣＳがステップ４５１で認証される。目標ＴＣＳが認証可能であれば、グループライセンスとインストール要求のＴＣＳＩＤとがステップ４５２で構築される。次に、目標ＴＣＩがステップ４５３で認証される。目標ＴＣＩが認証可能であれば、次のステップ４５４でインストールの認可が要求される。要求が認可されれば、インストール要求は合格である。上記のステップのうちのいずれかが不合格であれば、要求はステップ４５５で不合格となる。
【０１６７】
グループライセンスのアンインストール
【０１６８】
アンインストール動作によって、グループライセンスが目標とするＴＣＩからアンインストールされて、ＴＣＳが、アンインストールされたグループライセンスを追跡することから解放される。グループライセンスは、一旦アンインストールされたら、再インストールされるまで使用不可能である。このアンインストールプロセスは、アンインストール要求を検証するステップと、目標とするＴＣＳからグループライセンスを追跡することを解放するステップと、グループライセンスをＴＣＩからアンインストールするステップからなる。解放要求が合格すれば、ＴＣＳは、アンインストールされたグループライセンスの現在の権利状態付きの認証可能メッセージを返却する。この認証可能メッセージは、次のステップでのアンインストール要求のためにＴＣＩに送られる。加えて、アンインストール要求には、グループライセンスもしくはグループライセンスＩＤおよび、権利の証明済み現在状態を含むＴＣＳによって返却された認証可能メッセージが含まれている。ＴＣＩは、以前にはＴＣＩに保存されていたＴＣＳのＴＣＳＩＤを用いて、ＴＣＳの認証可能メッセージと現在の権利状態とを検証する。要求が合格すれば、ＴＣＩは追跡情報を更新して、グループライセンスが権利の証明済み現在状態によってアンインストールされたことを示す。グループライセンスがＴＣＩで現在インストールされていないまたは認証可能メッセージが検証不可能であれば、アンインストール要求は不合格となる。
【０１６９】
共有コンポーネント
【０１７０】
共有コンポーネントは、認可された主体による共有または使用のために共有ライセンスを作成（導出）して、これら共有ライセンスを統合して、導出されたインストール済みグループライセンスに戻す。
【０１７１】
共有ライセンスを作成して統合するプロセスでは、インストールされたグループライセンスが拘束されるＴＣＳを認可する必要がある。ＴＣＳは、共有コンポーネントが共有要求をグループライセンスに照らし合わせて確認するために必要とするインストール済みグループライセンスの権利の状態を管理する。現在の権利状態が、共有要求が許可されたことを示していれば、共有ライセンスが作成されて、必要であれば委託の証明目的で委託コンポーネントに対して利用可能とされる。次に、グループライセンスの現在の権利状態を更新して、新たに作成された共有ライセンス中の権利の状態と初期状態を反映するようにする。
【０１７２】
共有要求次第で、様々な方法を用いて、上述したように、共有ライセンス中の権利の状態と初期状態とを作成し、また、インストールされたグループライセンスの現在の権利状態を更新する。
【０１７３】
共有ライセンスを返却して発信元であるグループライセンスに統合する場合、共有コンポーネントは統合要求と、この共有ライセンスの返却先であるグループライセンスを確認する。返却が許可されると、共有コンポーネントはこの要求を、グループライセンスが拘束されているＴＣＳに送って、グループライセンスの現在の権利状態を更新する。
【０１７４】
以下のセクションでは、共有ライセンスを導出するプロセスと、共有ライセンスを統合して発信元のインストール済みグループライセンスに戻すプロセスをより詳細に説明する。
【０１７５】
権利の導出
【０１７６】
権利の導出とは、インストールされたグループライセンスから共有ライセンスを作成するプロセスである。共有要求は、権利の被譲与者から直接にまたは共有ライセンスが消費される予定のデバイスから間接的に来る。対象となる消費デバイスが要求時には知られていない場合、要求に起因する共有ライセンスはどの消費デバイスにも拘束されない。この場合、共有ライセンスは、これが消費またはさらなる共有目的で使用可能となる以前に拘束されなければならない。
【０１７７】
図３７は、一般的に共有要求の一部である情報４６０を示す。要求タイプ４６１は、この要求が権利の導出要求または統合要求を示す。導出はサブ権利を作成する要求である。統合はサブ権利を返却する要求である。要求側のデバイスの情報４６２は権利消費デバイスを特定し、このデバイスが要求されているサブ権利を受領することを認可されていることを検証するために用いられる。デバイス情報はオプションである。要求された権利の情報４６３は、グループライセンスから共有されるべき権利を特定する。利用可能ライセンス４６４には、要求を譲与するグループライセンスと、要求を認可し、また、要求を満足させるためにライセンスを発行するために必要な他のライセンスが含まれる。
【０１７８】
共有要求を受信すると、権利消費デバイスは、この要求を満足するライセンスを発生しようとして機能の集合を実行する。このような機能には、要求を対象グループライセンスに照らし合わせて検証する機能、グループライセンスと関連のライセンスとを検証する機能、目標ＴＣＳに対して共有要求と関連するグループライセンスの現在の権利状態を要求する機能、要求を処理する機能および認可されたら共有ライセンスを作成する機能が含まれる。要求が認可されたら、ＴＣＳ中の目標グループライセンスの権利の状態が、発信元のグループライセンス中の現在の権利状態と共有ライセンス中の権利の初期状態とにしたがって更新される。
【０１７９】
図３８は、共有コンポーネントが共有要求を受信することで始まって、共有権利を含むライセンスを出力することで終了する共有要求処理の例示のデータフローを示す。このプロセスは多くのコンポーネントからなるが、これらはサブプロセスとデータベースである。このプロセス全体またはそのコンポーネントのいずれかは、共有コンポーネントが置かれているグループライセンスデバイスに常駐している。
【０１８０】
要求が消費デバイスコンポーネント４７０からグループライセンスデバイス４７１に送られ、ここで、一般的には処理される。グループライセンスデバイス４７１は、共有要求を処理する責任を負っている共有コンポーネントを含む。共有要求を受信すると、グループライセンスデバイスは、目標グループライセンスを、これを要求からまたはレポジトリ４７２から抽出することによって位置付ける。目標のグループライセンスと要求を確認して、その信憑性と整合性をステップ４７３で保証する。目標消費デバイスの識別に関する情報は、要求から抽出されて検証され、消費デバイスがこのような要求をすることを認可されることを保証する。目標消費デバイスは通常は、要求をする第２のデバイスである。
【０１８１】
要求は目標ＴＣＳから現在の権利状態に対して、共有要求はステップ４７４で処理される。この要求が認可されると、権利がステップ４７５で導出されて、この導出権利の状態４７７が状態マネージャ４７６によって更新される。図３９は、権利を導出するプロセスを示す。
【０１８２】
権利の導出には次のステップが含まれる。
要求に適合するグループライセンスと共有可能権利を位置付けするステップ。このステップは、要求を確認するステップと、グループライセンスを位置付けするステップと、共有可能権利を特定するステップと、ライセンスを確認するステップなどを含む、
目標の共有可能権利と関連付けられた状態の集合を特定するステップと、
要求を、目標の共有可能現在の権利状態とオリジナルの状態とに照らし合わせて確認するステップと、
共有権利を作成するステップと、
共有権利を含むライセンスを作成するステップ。このライセンスは、認可されたメンバーが、グループの他のメンバーのために共有権利を作成することを許可する新しいグループライセンスであり得る。
【０１８３】
図３９に示すように、ステップ４８０では、入力されたライセンスからライセンスを獲得し、また、このライセンスが共有要求を適合したことをステップ４８１で確認する。適合しなければ、ステップ４８２で、処理すべきライセンスがまだあるかどうか判定する。処理すべきライセンスがなければ、ステップ４８８で空（ヌル:null）という出力を返却する。ライセンスが要求と適合すれば、次のステップ４８３で、ライセンスから権利を獲得し、ステップ４８４で、この権利が分割可能であるか判定する。可能であれば、ステップ４８５で、この分割可能権利の分割である権利を導出する。次に、分割された権利、または分割不可能権利をステップ４８６で出力ライセンスに挿入する。次に、ステップ４８７で、処理すべき権利がまだあるかどうか判定する。なければ、出力ライセンスはステップ４８８で返却される。
【０１８４】
権利の統合
【０１８５】
権利の統合とは、共有ライセンスを発信元のグループライセンスに戻して統合して、その結果として新たなグループライセンスを作成するプロセスである。この権利統合プロセスは、上に開示した権利導出プロセスと類似している。権利導出と権利統合間との相違は、次の通りである。
権利の統合の場合、目標のグループライセンスに対する権利の状態が、より多くの権利を反映するように更新される。
権利の導出の場合、統合された共有ライセンスは無効となる。
導出が正しく行われた場合、新しい共有ライセンスが作成される。
【０１８６】
消費コンポーネント
【０１８７】
消費コンポーネントは消費ライセンスを消費する。上記に開示したように、消費ライセンスはまた共有ライセンスでもある。しかしながら、消費ライセンスは、共有目的ではなくて使用目的のものである。消費ライセンスを消費するには認可が必要であり、このような認可は、あらゆるＤＲＭシステムで指定される既知のプロセスである。認可プロセスは、ライセンスに照らし合わせて要求を確認するステップと、ユーザとデバイスを認証するステップと、要求を条件の現在状態に照らし合わせて検証するステップと、使用認可された場合に条件の現在状態を更新するステップなどを含む。
【０１８８】
消費ライセンスは、期限切れになるまでまたは消費デバイスによって解放されるまで消費デバイスによって消費される。消費ライセンスは、一旦解放されれば、共有コンポーネントに送って、その導出元であるグループライセンスに戻して統合することが可能である。
【技術分野】
【０００１】
本発明は、ＤＲＭ（デジタル権利管理）の分野およびデジタルリソース管理に関し、詳しくは、権利およびリソースの分配および共有に関する。
【背景技術】
【０００２】
現在の最新のＤＲＭシステムでは、人間であったりデバイスやサービスなどの人間以外のエンティティであったりする潜在的ユーザの集合で権利を共有する機能は、市販のプロダクツで利用可能である。譲与された権利の集合とこれらの権利を共有する方法は一般的にはライセンスという形態で指定される。
【０００３】
権利の共有専用のライセンスの１つの形態は、並列ユーザライセンス（サイトライセンスまたはネットワークライセンスとしても知られている）と呼ばれる。並列ユーザライセンスは、ネットワークサーバに拘束されているライセンスのプールを表し、このネットワーク上のユーザだけがこのライセンスにアクセスすることが可能であり、これに同時にアクセス可能なユーザの数は限られる。
【０００４】
並列ユーザライセンスの従来型の実施例では、ライセンスにアクセス可能なユーザ各々に、このライセンスに指定されているすべての権利が譲与されている、すなわち、ユーザすべてが同じ権利を有する。Ｍａｃｒｏｖｉｓｉｏｎ ＦＬＥＸｎｅｔによるこのタイプのライセンスのより進歩した実施例では、並列ユーザライセンスのユーザは、権利の集合を動的に共有することが許可される。このライセンスは、ユーザ各々が有することが可能な権利の集合を指定する代わりに、すべてのユーザが共有することが可能な権利の最大集合を指定する。これらの権利をどのように共有するかは、ライセンスの購入者次第であり、したがって、オプションファイルとソフトウエアプラグインモジュールとからなるカスタムアクセス制御メカニズムを用いて構成することが可能である。このオプションファイルを用いると、特に、特定の一人もしくは複数のユーザのためのライセンスプールで利用可能な多くのライセンスの予約、ユーザもしくはユーザグループがアクセス可能なある特定の特徴的機能の予約およびオフラインで使用する目的でこのプールからあるライセンスを誰が借用することが可能であるかの規定を制御することが可能である。このオプションファイルによってサポートされる特徴的機能の一部を解説すると、「ＲＥＳＥＲＶＥ１インストールＵＳＥＲロバート」は「ロバート」というユーザに対して「インストール」という特徴的機能の１つのライセンスを予約し、「ＲＥＳＥＲＶＥ４プレイＧＲＯＵＰアカウンティング」は、アカウンティンググループがコンテンツをプレイするためのライセンスを予約し、「ＩＮＣＬＵＤＥ＿ＢＯＲＲＯＷプレイＵＳＥＲトム」は、特徴的機能「プレイ」を借用することが可能なユーザのリストに「トム」というユーザを含む。共有することに加えて、オプションファイルには、使用を報告するオプションが含まれている。これは、事実上、ライセンスが、使用を追跡するという条件をユーザに課す方法である。あるユーザがコンテンツにアクセス可能であるかどうかを判定する認可プロセスでは、オプションファイルをプラグインが処理して合成応答を発生している間に、このライセンスを一般的ライセンスマネージャが処理する。
【０００５】
Ｍａｃｒｏｖｉｓｉｏｎ ＦＬＥＸｎｅｔの方式では、ユーザには、自分の必要にしたがって権利の共有を制御する特別のメカニズムが提供されるが、それには限度があることは否定できない。例えば、そのライセンスはネットワークサーバに拘束され、このネットワーク上のユーザだけがこのライセンスにアクセスまたはこれを借用することが可能である。また、オプションファイルは人間によって構成され、エラーが発生しやすい。例えば、アドミニストレータは、ある部門内の様々なグループに対してライセンスを予約している場合に、予約されたライセンスの数がプールのキャパシティを超えるようなミスを犯すことがあり得る。このミスが気付かれないままとなって、あるグループが、結局予測していたより少ないライセンスしか共有できないことになるという結果になりかねない。オプションファイル（および、それゆえの共有分配）は明瞭なテキストファイルである。これはアドミニストレータのパスワードでしか保護されていないものである。ライセンスサーバは、ライセンスに対して実施するのと同じ権利管理タスクを実行することは不可能であるが、このタスクとは、信憑性とオプションの整合性とを検証することである。加えて、ライセンスよりもオプションファイルに基づいてアクセスを制御するため、コンテンツの携帯性が制限されるが、これは、上述のアクセス制御メカニズムが存在しないと、コンテンツにアクセスすることが不可能であるためである。コンテンツがペリメータ（ネットワークサーバのドメイン）から離れると、意図したアクセス制御はもはや当てはまらない。
【０００６】
使用を報告するというハードコーディングされたオプションは、ライセンスの購入者がライセンスのユーザに対して課すことを希望することが考えられる条件のうちの１つに過ぎない。ライセンスの購入者は、自分自身の条件を分配された権利に追加することが可能であるべきである。カスタムアクセス制御メカニズムは、委譲の１レベルをサポートするだけである。アドミニストレータだけが、これ以上自分の権利を分配することが不可能なネットワークユーザに対して権利を分配することが可能である。この委譲は、マルチレベルの委譲を必要とする階層構造には適していない。共有は、アクセス態様またはある行動の制御に焦点が合わされる。これは、規則やポリシーによって管理される汎用のリソース共有メカニズムではない。その設計は、ソフトウエアプログラムの動作を制御することにその重点がある。文書、オーディオファイル、ビデオファイルなどの他のタイプのデジタルリソースの制御を意図するものではない。
【０００７】
個人的ドメイン内での共有を可能とする別の形態のライセンスは、典型的にはエンドユーザライセンスと呼ばれるものである。このタイプのライセンスでは、ライセンス自体が、デバイスＩＤやユーザＩＤなどの特定の環境に拘束されていることが必要である。共有は、権利の所有者によってサポートされているビジネスモデルによって、特定の集合のデバイスタイプおよび／または最大数のデバイス内での共有に限られる。すべての共有デバイスが同じ権利を有するかまたは、各々のデバイスがそれ自体の別個の集合の権利を有するかのどちらかである。
【０００８】
エンドユーザライセンスの１つの例では、マイクロソフトのＷｉｎｄｏｗｓ（登録商標）のメディア権利管理システム（Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｍｅｄｉａ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）は、自分のパソコン上でコンテンツをプレイして他のデバイスにコンテンツを転送する権利を含む権利集合を、コンテンツの購入者に対して譲与してよい。このような転送権利には、このコンテンツを受信する資格があるデバイスのタイプと、このようなデバイスに対するいくつかの所定の権利とが指定される。転送された結果、さらに、パソコン上のライセンスにしたがって、対象デバイスは各々が、それ自体の別個の権利集合を有することになる。
【０００９】
別の例では、リアルネットワークへリックスＤＲＭ（Ｒｅａｌ Ｎｅｔｗｏｒｋｓ Ｈｅｌｉｘ ＤＲＭ）は、パソコン、セットトップボックス、ホームメディアサーバ、携帯電話などのあらゆるネットワーク接続されたデバイス（ネイティブデバイス（Ｎａｔｉｖｅ Ｄｅｖｉｃｅ）と呼ばれる）に対して、自分自身のコンテンツとライセンスを獲得する能力を提案する。へリックスデバイスＤＲＭは、ネイティブデバイスから、データの転送とこのデータに対するビジネス規則の執行とを目的としてネイティブデバイスに対する接続を必要としているデバイスであるセキュア受信機デバイスへの転送をサポートする。セキュア受信機デバイスの例には、専用音楽プレイヤや専用ビデオプレイヤが含まれる。セキュア受信機デバイス上で利用可能なのは再生権利だけである。
【００１０】
さらに別の例では、ＦＬＥＸｎｅｔのノードロックライセンスを特定のデバイスに拘束しておいて、このデバイスのみ上でこのライセンスを消費させるようにすることが可能であったり、または、特定のユーザ名に拘束しておいて、このライセンスを消費するデバイスが同じユーザ名を有していなければならないようにすることが可能である。この２つの要件のうち、前者は共有を許可しないのに対して、後者は同じユーザ名を有するデバイス間での共有を許可しているが、デバイスは名前で区別するのが好ましいため、これはあまり実用的ではない。
【００１１】
さらに別の例では、ＦＬＥＸｎｅｔモバイルライセンスはＦＬＥＸｎｅｔ ＩＤに拘束される。ＦＬＥＸｎｅｔ ＩＤを含むハードウエア（ドングル）は、認可されたユーザがライセンスを新しいデバイス上で消費することを決定すれば、この新しいデバイスに移動させなければならない。
【００１２】
したがって、エンドユーザライセンスによって許可された共有方式では、ユーザが、獲得した権利を、自分が適していると見なす何らかの方法で用いることが可能な最大限の権利として用いることは許可されない。
【発明の概要】
【発明が解決しようとする課題】
【００１３】
このため、ユーザが、自分達の必要性にしたがって権利を共有することを可能とする動的権利共有をサポートするシステムに対する必要性が存在する。このシステムでは、獲得されたライセンスは権利のプールを表しているが、ここで、各々の権利をさらにサブ権利に分割することが可能である。サブ権利とは、権利を分配する単位である。
【課題を解決するための手段】
【００１４】
本発明は、権利からサブ権利を導出する方法に関するが、この権利は複数のコンポーネントを含み、これらコンポーネントはその各々が、権利の態様を指定している。本方法は一般的に、サブ権利を受信するステップであって、前記サブ権利が前記コンポーネントのうちの少なくとも１つを含み、前記コンポーネントの各々が前記サブ権利の態様を指定するステップと、前記サブ権利の前記コンポーネントの値が前記権利のうちの対応しているコンポーネントの値から導出することが可能であることを確認するステップと、を含む。コンポーネントは、例えば、主役、動作、リソースおよび条件であってよい。
【００１５】
本発明はまた、第１の権利を第２の権利と統合する方法に関する。この場合、本方法は、前記第１の権利のコンポーネントの各々がこれに対応する前記第２の権利のコンポーネントから導出することが可能であることを検証することによって、前記第１の権利が前記第２の権利から導出可能であることを判定するステップと、前記第１の権利を前記第２の権利のうちの前記対応するコンポーネントと合成するステップを含む。
【００１６】
さらに、本発明は権利を共有する方法に関する。本方法は、権利からサブ権利を導出し、前記サブ権利の使用を許可し、前記サブ権利を前記権利と統合するステップを含む。その結果、サブ権利は、共有目的でさらに導出することが可能である。加えて、権利はライセンス中に指定されることがあり、本方法はさらに、デバイス上で前記ライセンスをインストールするステップと、前記ライセンスをアンインストールするステップと、これらのライセンスを他のインストール動作に利用可能とするステップを含むことができる。
【００１７】
加えて、本発明は、権利からサブ権利を導出することを可能とすることによって権利共有をサポートするシステムに関するが、この権利は複数のコンポーネントを含み、このコンポーネント各々がこの権利の態様を指定し、前記システムは、サブ権利を受信するための受信モジュールであって、前記サブ権利が、各々が前記サブ権利の態様を指定する複数のコンポーネントを含む受信モジュールと、前記サブ権利の前記コンポーネントの値が前記権利のうちの対応するコンポーネントの値から導出可能であることを確認するための確認モジュールを備える。本システムはさらに、グループライセンスをデバイス上にインストールし、これを共有目的に対して利用可能とし、インストールされたグループライセンスをアンインストールし、これを現在のデバイス上での共有目的に対しては利用不可能とするためのインストールモジュールと、前記インストールされた／アンインストールされたグループライセンスを追跡するインストール追跡モジュールと、グループライセンスの権利の状態を追跡する追跡モジュールと、共有モジュールを備える。
【００１８】
本発明はさらに、譲与者から被譲与者に譲与された権利のプールからサブ権利を導出し、これによって、計算環境内でのリソースの使用を制御する方法に関するが、この計算環境は、この権利にしたがってリソースの使用を制御するためにこの環境内で権利を執行するメカニズムを有し、前記方法は、被譲与者が譲与者から権利のプールを受信し、前記権利のプールが少なくとも１つのリソースと関連付けられ、前記被譲与者が前記権利のプールを１つ以上の権利コンポーネントに解析し、前記権利コンポーネントの各々が前記権利プールの態様を指定し、前記権利コンポーネントのうちの少なくとも１つからサブ権利コンポーネントを導出し、前記サブ権利コンポーネントが対応する権利コンポーネントの部分集合であり、前記サブ権利コンポーネントからサブ権利を指定するライセンスを作成することを含み、前記ライセンスが、前記サブ権利に従って、また、前記権利のプールの範囲内で前記リソースの使用を制御するために前記計算環境によって執行することが可能である。本方法はさらに、前記ライセンスをサブ被譲与者に譲与するステップと、前記サブ被譲与者によって前記ライセンス中の前記権利を権利のサブプールとして１つ以上の第２の権利コンポーネントに解析するステップであり、前記第２の権利コンポーネントの各々が前記権利のサブプールの態様を指定するステップと、前記第２の権利コンポーネントのうちの少なくとも１つから第２のサブ権利コンポーネントを導出するステップであり、前記第２のサブ権利コンポーネントが対応する第２の権利コンポーネントの部分集合であるステップと、前記第２のサブ権利コンポーネントからサブサブ権利を指定するサブライセンスを作成するステップであり、前記サブライセンスが、前記サブサブ権利に従って、および前記権利のサブプールの範囲内で前記リソースの使用を制御するために前記計算環境によって執行することが可能であるステップを含む。
【００１９】
サブ権利について開示されている概念を解説するために、電子書籍（本）を５回プレイする権利を検討する。この権利のサブ権利とは、電子書籍をｎ回プレイする権利（ここで、０＜ｎ＜５）であり得る。プールのキャパシティ以内で共有される限りでは、このシステムは、ユーザが、獲得した権利を自由に分割して分配することを許可するが、これは、権利が同じネットワーク上のユーザに分配されるか互いに別々のネットワーク上のユーザに分配されるか、前記分配された権利が受信者によって消費されるか、または、他の認可済みのエンティティにさらに分配されるかとは無関係である。本システムは、権利をサブ権利に分割して、サブ権利の残余の部分を統合して、他者が使用するようにプールに戻す方法などの、権利のプールを維持するメカニズムを提供する。
【図面の簡単な説明】
【００２０】
【図１】譲与された権利のデータモデルと擬似表現言語との間のマッピングを示す。
【図２】擬似表現言語における無条件権利を示す。
【図３】プレイの回数に対する条件が付いた譲与権利を示す。
【図４】時間条件付きの譲与権利を示す。
【図５】２つ以上の条件が付いた譲与権利を示す。
【図６】図２に示す譲与権利をＭＰＥＧ−ＲＥＬで表現したものを示す。
【図７】図３に示す譲与権利をＭＰＥＧ−ＲＥＬで表現したものを示す。
【図８】図４に示す譲与権利をＭＰＥＧ−ＲＥＬで表現したものを示す。
【図９】図５に示す譲与権利をＭＰＥＧ−ＲＥＬで表現したものを示す。
【図１０】主体に基づいて、図４に示す譲与権利から導出された権利を示す。
【図１１】主体および条件に基づいて、図４に示す譲与権利から導出された権利を示す。
【図１２】指定された主体に基づいて譲与権利から権利を導出するプロセスを示す。
【図１３】条件に基づいて譲与権利から権利を導出するプロセスを示す。
【図１４】新しい権利が分割可能権利から導出されるシナリオを示す。
【図１５】新しい権利が無条件並列権利から導出されるシナリオを示す。
【図１６】新しい権利が条件付き並列権利から導出されるシナリオを示す。
【図１７】新しい権利が共有可能権利から導出されるシナリオを示す。
【図１８】グループライセンスを示す。
【図１９】新しいグループライセンスがグループライセンスから導出されるシナリオを示す。
【図２０】第２世代グループライセンスを導出するプロセスを示す。
【図２１】権利がグループライセンスに返却されるシナリオを示す。
【図２２】図１８に示すグループライセンスをＭＰＥＧ ＲＥＬで表現したものを示す。
【図２３】図１９に示すグループライセンスをＭＰＥＧ−ＲＥＬで表現したものを示す。
【図２４】グループライセンスの導出階層を示す。
【図２５】一般的なＤＲＭシステムを示す。
【図２６】動的な共有権利をサポートする基本的なコンポーネントを示す。
【図２７】共有権利をサポートする基本的コンポーネントの１つの可能性のある構成を示す。
【図２８】共有権利をサポートする基本的コンポーネントの１つの可能性のある構成を示す。
【図２９】共有権利をサポートする基本的コンポーネントの１つの可能性のある構成を示す。
【図３０】企業アプリケーション用の基本的コンポーネントの１つの可能性のある構成を示す。
【図３１】グループライセンスをインストールするプロセスを示す。
【図３２】情報を追跡する好ましい構造を示す。
【図３３】グループライセンスをアンインストールするプロセスを示す。
【図３４】権利の状態を証明して検証するプロセスを示す。
【図３５】グループライセンスをインストールするプロセスを示す。
【図３６】インストール要求を構築して認可するプロセスを示す。
【図３７】一般的に共有要求の一部である情報を示す。
【図３８】共有要求を処理する例示のデータフローを示す。
【図３９】権利を導出するプロセスを示す。
【発明を実施するための形態】
【００２１】
定義
【００２２】
権利とは、指定された状況または条件の集合の下で、一般的にはリソースに対して権利の被譲与者が動作または活動を実行するステートメントを表す。
【００２３】
権利表記(rights expression)とは、権利をデジタル形態で明示したものである。権利表記の例としては、これに限られないが、ＩＳＯ ＭＰＥＧ ＲＥＬ、ＸｒＭＬ、ＳＡＭＬ、ＸＡＣＭＬ、ＯＤＲＬ、ＯＭＡ ＲＥＬなどのＸＭＬベースの権利表記言語や、データ構造や、ビットフィールドがある。
【００２４】
ライセンスとは、権利表記を用いて捕獲された規則の表現である。ライセンスは、譲与された権利の完全な文脈を伝えている。ライセンス中で捕獲されている情報には、権利の譲与者、権利の被譲与者、リソース、許可ならびに関連する条項および条件が含まれている。
【００２５】
リソースとは、アクセス、使用、操作および／または分配が規則またはポリシーの集合によって管理され統御されるようなあらゆるコンテンツ、サービス、さらに権利さえも表すものである。
【００２６】
本開示に定義される動的な権利共有によって、権利の譲与者の決定権に対抗する権利の被譲与者の決定権において共有する能力が可能とされる。権利の譲与者は、権利の限度を指定する。この限度を示す条件内で、権利の被譲与者は、特定の権利共有メカニズムを決定することが可能である。権利の被譲与者はまた、多段階権利譲与連鎖においては譲与者でもあり得る。
【００２７】
権利の共有とは、譲与された権利をサブ権利に分割することを含む。次に、サブ権利がサブ被譲与者の集合に発行される。帰納的に、各々の被譲与者またはサブ譲与者はさらに、譲与連鎖を下るにつれて、他のサブ被譲与者とサブ権利を共有することが可能である。例えば、中心ライブラリＸは、ある本３０冊に対する権利を購入する。次に、ライブラリＸはこの３０冊のうちの１０冊を自分の姉妹ライブラリＹに分配する。したがって、ライブラリＸは、権利の譲与者として動作して、１０冊に対するサブ権利をライブラリＹに発行する。ライブラリＸから１０冊を受領すると、ライブラリＹはさらに、このうちの３冊をそのローカルライブラリＺのうちの１つと共有する。
【００２８】
本発明の第１の態様は、権利をサブ権利に導出して、サブ権利を、これらの導出元であるオリジナルの権利に統合して戻す方法である。本発明全体を通じて、サブ権利は導出された権利とも呼ばれる。権利の導出と統合は、権利を権利の被譲与者間で共有する基本的メカニズムとして働く。権利の被譲与者は、新しいサブ権利を導出することによって自分の権利を他者と共有する。その結果、新しいサブ権利の被譲与者は各々が、サブ権利を消費したり他者とさらに共有したりすることが可能となる。
【００２９】
本発明の第２の態様はグループライセンスであり、これは、一人以上の権利被譲与者の集合に対して最大限の権利を譲与して、これらの権利をこれら被譲与者間で動的に共有することを許可するシステム内で用いられる。グループライセンスの共有メカニズムは、サブ権利を導出して、これらサブ権利を含む共有ライセンスを発行する能力に基づいている。共有ライセンスとは、自分自身が、さらに共有可能なグループライセンスであり得る。したがって、グループライセンスは動的で多段階の権利共有をサポートする。
【００３０】
本発明の第３の態様は、権利被譲与者のグループ間で、および権利被譲与者のグループ全体にわたって権利を共有し、また、多段階に権利を共有することをサポートするためのグループライセンスを実施するシステムである。この開示されるシステムは、権利の消費を認可して、権利の使用と状態を追跡することが可能ないかなるＤＲＭシステム中でも実施することが可能である。
【００３１】
本発明は第１に、所与の権利からサブ権利を導出する方法を開示する。この方法は、サブ権利が、これらサブ権利の導出元であるオリジナルの権利の限度内であることを保証する。本方法は、動的権利共有システム中で権利の分割目的で用いることが可能である。
【００３２】
各々のサブ権利は、次の一人の（または複数の）権利被譲与者に対して、このサブ権利の導出元である権利の一部分または全体を譲与する。その結果、各々のサブ権利の消費が、このサブ権利の導出元の権利とも、また、他のサブ権利とも無関係に認可される。したがって、サブ権利を導出する能力は、動的権利共有のための基本的メカニズムである。
【００３３】
本発明はまた、グループライセンスと呼ばれる新しい概念を提示する。グループライセンスとは、一人以上の被譲与者に対して最大限の権利を譲与して、これら被譲与者による共有がこのグループライセンスによって許可された場合に、これらの被譲与者が、これら譲与された権利をこのような共有のポリシーにしたがって共有することを許可するライセンスのことである。このような共有がグループライセンスによって許可される場合には、共有するメンバーをこれら被譲与者以外にも拡大して、他の認可済みのユーザを含むようにしてもよい。
【００３４】
グループライセンスのセマンティックスでは、サブ権利の指定を導出する開示の方法が採用される。グループライセンスシステムは、サブ権利をライセンス発行認可プロセスの一部として導出し得る。グループライセンスシステムは、サブ権利が発行の時点でライセンスの限度内にある場合にだけ、これらサブ権利を含むライセンスの発行を認可する。この発行されたライセンスを被譲与者が用いたり、またはさらに分割したりして、グループライセンスを含むようにすることが可能である。加えて、グループライセンスのセマンティックスは、サブ権利の未使用の部分を統合して、サブ権利の導出元である権利に戻すことをサポートしている。
【００３５】
本発明はまた、権利の被譲与者間での動的な共有目的でグループライセンスを処理する例示のシステムを提示する。本システムはまた、未使用の共有権利を再統合してグループライセンスに戻す能力を有する。本開示のシステムは、様々な構成で設計して、権利の認可と追跡をサポートするＤＲＭシステムに統合することが可能な基本的コンポーネントの集合を含む。この好ましい例示のシステムに加えて、開示の概念を組み込んだ他の実施例を設計することが可能である。
【００３６】
共有のための権利を導出する方法
【００３７】
現行の権利共有メカニズムは、特定の用途向けに具体的に実現されるか、中心的認可によって共有を制御することを必要とするか、特定の環境内で共有することを必要とするかのいずれかである。このような共有方式では、権利の被譲与者が自身の権利を共有する機能が制限される。本発明は、権利の導出に基づいた新しい共有方法を開示する。本開示方法によって、権利を権利の被譲与者間で動的に共有することが可能となり、また、共有された権利をさらに他の権利被譲与者と共有することが可能となる。本開示方法は汎用性があり、権利とリソースを共有することを必要とするいかなるシステムにも適用可能である。
【００３８】
本発明は、最初に、権利の既存の実施例にマッピングすることが可能な権利の一般的なデータモデルを導入する。次に、本発明は、譲与された権利からサブ権利を導出して、サブ権利を統合してオリジナルの譲与された権利に戻す方法を開示する。権利を導出する方法と共に、本発明はまた、本開示の方法をどのように現行の共有方式に応用してその限界の一部に対処するかを記述する。
【００３９】
権利のデータモデル
【００４０】
権利の一般的なデータモデルｕは次のように表される。
ｕ＝（ｐ，ａ，ｒ，ｃ）
ここで、
ｐは、動作ａが譲与される対象である主体、主体の集合または匿名の主体である。したがって、ｐは一人以上の権利の被譲与者である。
ａは、ｐが実行することを許可された動作または活動であり、
ｒは、動作ａと関連付けられたリソースであり、
ｃ＝｛ｃi｜ｉ＝０．．ｎ｝は、ｐがｒに対してａを実行する指定された状況を構成する条件の集合である。ｃiはｕと関連付けられた条項および条件と呼ばれる。
【００４１】
ｕ中に指定されているｐ、ａ、ｒおよびｃiはその各々が、譲与された権利ｕのコンポーネントと呼ばれる。解説目的で、この一般的データモデルは、次の擬似表現言語にマッピング可能とされる。
GRANTED RIGHTS（譲与された権利）
PRINCIPAL p（主体ｐ）
ACTION a（動作ａ）
RESOURCE r（リソースｒ）
CONDITIONS c（条件ｃ）
【００４２】
図１に、権利ｕ（１００）のデータモデルと上記の擬似表現言語１０１との間のマッピングを示すが、ここで、譲与された権利ｕは表現「GRANTED RIGHTS（譲与された権利）」にマッピングされ、主体ｐは表現「PRINCIPAL p（主体ｐ）」にマッピングされ、動作ａは表現「RIGHTS a（権利ａ）」にマッピングされ、リソースｒは表現「RESOURCE r（リソースｒ）」にマッピングされ、条件ｃは表現「CONDITIONS c（条件ｃ）」にマッピングされている。
【００４３】
この権利のデータモデルはまた、一般目的用のリソース共有にも適している。ａを「使用する」や「所有する」などの一般的動作として定義すると、本発明の開示するデータモデルやシステムおよび方法を用いて、ｃ中に指定されている条件によって統御される広範囲のリソース共有を達成することが可能である。この場合、権利ｕ中に指定されている動作ａはどのような用途にも応用される。その結果、本発明の残りの部分に開示される共有システムと共有方法は、リソースを共有するシステムおよび方法と見なすことが可能である。例えば、計算リソースの所有者が、ＣＰＵサイクルを共有して、学問的研究のプロジェクトに対する並行処理を容易化することを意図する。この所有者は、委託された同僚がＣＰＵのアイドルサイクルを用いて実行する特定のタイプのプログラムを知りたいとは思わない。この使用シナリオでは、所有者は、主体ｐを委託された研究コミュニティ内のいずれかのメンバーとして、動作ａをいずれかの使用として、リソースｒをＣＰＵサイクルとして、条件ｃを１０ｐｍ〜６ａｍのいずれかの時点として定義している権利ｕを発行する。この譲与された権利によって、委託された研究コミュニティのメンバーは、１０ｐｍ〜６ａｍでのＣＰＵサイクルを共有することを許可される。この例では、共有される第一の対象は、動作ａではなくてリソースｒである。
【００４４】
本明細書に記載する以下の図面は、上記の擬似表現言語で表現された譲与権利の例を示すものである。図２は、アリス(Alice)であると特定された主体に、「風とともに去りぬ(Gone With The Wind)」というタイトルのＤＶＤを見る(View)権利が譲与されるという、条件を有さない譲与権利１２０を示す。図３は、１つの条件が付いた譲与権利１３０を示す。音楽クラブ(Music Club)と特定された主体に、ルイ・アームストロング(Louis Armstrong)の「この素晴らしい世界(What a wonderful world)」というＣＤをプレイ(Play)する権利が譲与される。この譲与された権利には、このＣＤのプレイ回数(Number of Play)を１００回に制限する条件１３１が付いている。図４は、１つの条件付きの譲与権利１４０を示す。音楽クラブと特定された主体に、ルイ・アームストロングの「この素晴らしい世界」というＣＤをプレイする権利が譲与される。この譲与された権利には、このＣＤをプレイすることが許される期間を２００６年１月までに制限する条件１４１(Not after Jan. 2006)が付いている。図５は、２つの条件が付いた譲与権利１５０を示す。音楽クラブと特定された主体に、ルイ・アームストロングの「この素晴らしい世界」というＣＤをプレイする権利が譲与される。この譲与権利には、このＣＤをプレイする回数を１００回に制限する条件１５１と、このＣＤをプレイすることを許される期間を２００６年１月までとする条件１５２が付いている。
【００４５】
上記の擬似表現言語は例示目的で本発明の全般にわたって用いられているが、本発明は、いずれの特定の権利表記言語も、データ構造も、表現などにも制限されるものではない。
【００４６】
権利のデータモデルは、多目的のものであり、どのような形態の権利表記をもモデリングすることが可能である。例えば、図６、７、８および９では、図２、３、４および５とそれぞれ同じ譲与権利を表現するのにＭＰＥＧ ＲＥＬ（１２５、１３５、１４５および１５５）を用いる。
【００４７】
別の例では、上記の権利データモデルを用いて、コピー絶対禁止、コピー自由、１世代コピーなどの保護されたコンテンツの保護状態を表す２ビットであるコピー制御情報ビット（ＣＣＩビット）の構造を次のようにモデリングすることが可能である。
ｕ＝（ｐ＝ｎｕｌｌ，ａ＝ＣＣＩ，ｒ＝ｎｕｌｌ，ｃ）
ここで、ｐはコンテンツを受信するデバイスを意味し、ａはコピー動作であり、ｒはＣＣＩビットが関連付けられているコンテンツを意味し、条件ｃはコピー動作に対する制限である。このような制限には、コピー絶対禁止、コピー自由、１世代コピーなどが含まれる。
【００４８】
第３の例では、次のＦＬＥＸｎｅｔライセンスは、ライセンスサーバマシン「ｌｕｌｕ」にアクセス可能なすべてのデバイスに対して、特徴「ｆ１」に対する２つのライセンス、特徴「ｆ２」に対する６つのライセンスおよび特徴「ｆ３」に対する１つのライセンスを譲与する。
「SERVER lulu 17007ea8
VENDOR sampled
FEATURE f1 sampled 1.00 1-jan-2005 2 SIGN=signature1
FEATURE f2 sampled 1.00 1-jan-2005 6 SIGN=signature2
FEATURE f3 sampled 1.00 1-jan-2005 1 SIGN=signature3」
SERVER：サーバ
VENDOR：ベンダー
sampled：サンプリング済み
FEATURE：特徴
1-jan-2005：２００５年１月１日
SIGN：サイン
signature：著名
【００４９】
上記の権利データモデルを用いると、上記のＦＬＥＸｎｅｔライセンスを、次のように互いに別個の３つ権利にマッピングすることが可能である。主体ｐは、ＦＬＥＸｎｅｔフロートライセンス中の認可サーバのホストＩＤまたはＦＬＥＸｎｅｔ特徴が拘束されるノードのホストＩＤである。上記のＦＬＥＸｎｅｔの例では、主体ｐは、ライセンスサーバ「ｌｕｌｕ」にアクセス可能なすべてのデバイスである。動作ａは、ＦＬＥＸｎｅｔライセンスの特徴(FEATURE)ラインに指定されている特徴を実行する権利である。リソースｒは、ＦＬＥＸｎｅｔライセンス中に指定されている特徴である。上の例では、リソースｒは、ＦＬＥＸｎｅｔの特徴ｆ１、ｆ２およびｆ３である。条件ｃは、ＦＬＥＸｎｅｔライセンスの特徴(FEATURE)ライン中に指定されている制限である。上の例では、特徴ｆ１に対する条件は２つのライセンスであり、特徴ｆ２に対する条件は６つのライセンスであり、特徴ｆ３に対する条件は３つのライセンスである。
【００５０】
上記の権利データモデルに基づくと、権利は無条件となるが、これは、図２に示す譲与権利などのように関連の条件を何も有さないことを意味する。他方、権利は条件付きであるとは、図３および４に示す譲与権利の例などのように１つ以上の条件と関連していることを意味する。
【００５１】
譲与権利ｕ＝（ｐ、ａ、ｒ、ｃ）に指定されている条件ｃは、一般的には、満足しなければならない条件または、主体ｐにとってリソースｒに対して動作ａを実行するために実施しなければならない義務である。権利と関連付けることが可能な条件には、無状態条件および状態条件という２つのタイプが存在する。
【００５２】
無状態条件とは、状態とは無関連の条件である。このような条件は、譲与権利を行使するために実行されなければならない義務のことである。このような条件は、譲与権利の寿命には直接には関連していない。無状態条件は一般的には、ビジネス上の規則（支払い方法、関連者各々に支払うべきパーセンテージなど）、認可規則（権利の行使の承認要請など）、システム要件などに関連している。
【００５３】
状態条件とは、１つ以上の状態と関連付けられた条件のことである。このような条件は、譲与された権利を行使可能な回数や、譲与権利が行使される時間ウインドウなどの譲与権利の寿命中のある活動に直接的に関連している。状態条件は、その状態の特徴によってさらに２つのタイプに分割することが可能である。
【００５４】
基準条件とは、状態を修正することなく読み取る状態条件のことである。このタイプの条件によれば、現在の値から次の値への状態の遷移は、譲与権利の行使や消費とは無関係である。例えば、図４に、譲与権利が行使される時間ウインドウを規定する条件を示す。この例では、状態の現在値は、譲与権利が行使されようとされまいと、時間の経過とともに変化し続ける。
【００５５】
分割可能条件とは、状態を読み取って更新する状態条件のことである。このタイプの条件によれば、現在値から次の値への状態の遷移は、譲与権利が行使されるごとに始動される。例えば、図３に、譲与権利が行使される回数を規定する条件を示す。この例では、状態の現在値は、譲与権利が行使されるごとに減少する。
【００５６】
状態に対する条件の依存性を組み込むため、上に開示した譲与権利ｕ＝（ｐ、ａ、ｒ、ｃ）のデータモデルは次のように展開可能である。
ｕ＝（ｐ，ａ，ｒ，ｃi⇒Ｑi：ｉ＝１，．．，ｎ）
【００５７】
ここで、（ｃi⇒ Ｑi：ｉ＝１，．．，ｎ）は、Ｑiが、ｉ＝１，．．，ｎの場合に条件ｃiと関連している状態であることを意味する。条件ｃiが無状態条件であれば、Ｑiは
空である。権利の状態は、この権利と関連しているすべての条件の状態で表される。
【００５８】
権利の導出と統合
【００５９】
譲与権利ｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）に指定されている主体ｐは、１つの主体ではなく主体のグループを表している。例えば、図４に、２００６年１月までに行使を制限する条件付きのルイ・アームストロングの「この素晴らしい世界」というＣＤをプレイする権利が音楽クラブに譲与されている様子を示す。「音楽クラブ」とは、人々のグループのことであり、音楽クラブの人であれば誰でも、現在の時点が２００６年１月以降でなければこのＣＤをプレイしてもよい。
【００６０】
アリスであると特定された主体が音楽クラブのメンバーであれば、アリスは、図４に指定されている権利を行使して、「この素晴らしい世界」というＣＤをプレイすることが可能である。しかしながら、図１０に示すように、アリスはまた、図４に指定されている譲与権利と同じ条件１４１が付いた「この素晴らしい世界」というＣＤをプレイする権利１４２も譲与されている。主体のアリスにとっては、図４に指定されている譲与権利と図１０に指定されている譲与権利の双方はまったく同じである。したがって、図１０の譲与権利は図４の譲与権利の具体的なインスタンスであるので、図１０の譲与権利は、図４の譲与権利から導出された権利であると考えることが可能である。同様に、図１１に、図４の譲与権利から導出された権利１４３を示す。この例では、条件１４４は変更されてはいるが（Not After Jan. 2005：２００５年１月まで）、図４の譲与権利の条件１４１の範囲内にとどまっている。
【００６１】
主体ｐと同様に、ｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）中のｐ、ａ、ｒまたはｃiの各々は、それぞれ主体のグループ、動作、リソースまたは条件を互いに独立に示すことが可能である。したがって、様々な権利が、所与の文脈内ではまったく同じであるという場合がある。この場合、このような権利は互いに関連し、ある権利を他の権利から導出される。
【００６２】
導出規則
【００６３】
ｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）とｖ＝（ｐ’、ａ’、ｒ’、ｃ’i⇒Ｑ’i：ｉ＝１，．．，ｍ）とを２つの権利であるとする。ｖは、ｍ≦ｎであり、次の規則が当てはまれば、ｕから導出されたといわれる。
規則Ｄ１：ｐ⇒ｐ’，ａ⇒ａ’，ｒ⇒ｒ’
規則Ｄ２：∀i≦ｍ，ｃi⇒ｃi’
規則Ｄ２．１：Ｑiが、ｃiの可能な状態値を表す非順序集合であれば、Ｑ’i＝Ｑi、0−ＱiここでＱi、0はｖの導出に先立つｕの状態である。
規則Ｄ２．２：Ｑiが、ｃiの累積値を表す唯一の値を含む場合、‖Ｑ’i‖≦‖Ｑi,0‖，‖Ｑi‖≦‖Ｑi,0‖および‖Ｑi‖＋‖Ｑ’i‖≦‖Ｑi,0‖、ここでＱi、0はｖの導出に先立つｃiの状態を表し、表記‖Ｑi‖はＱiのノルム（すなわち値）を意味する。
規則Ｄ２．３：Ｑiが、ｃiの可能な範囲値を表す順序集合であれば、Ｑ’i⊂Ｑi,0およびＱ’i∩Ｑi＝、ここでＱi、0はｖの導出に先立つｕの状態である。
【００６４】
表記ｐ⇒ｐ’は、ｐはｐ’を意味するまたはｐはｐ’を導出するまたはｐ’はｐから導出されたことを意味する。例えば、アリスはまた「キーホルダーＡ(Key Holder A)」としても知られ、したがって、アリスは「キーホルダーＡ」を意味する。ｐ⇒ｐ’であるかどうかを判定する規則はアプリケーションによって異なる。しかしながら、ｐ’がｐと同じであったり、ｐ’がｐのインスタンスであったり、ｐが空であったりする特殊な場合があるが、このような場合にはｐ⇒ｐ’となる。
【００６５】
規則Ｄ１は、サブ権利は、これが導出された元の権利によって許可されている主体、動作およびリソースだけを指定すべきことを定めている。より具体的には、規則Ｄ１は、サブ権利を遵守することを必要としている。主体ｐ’はｐから導出されなければならない。例えば、ｐが「部門Ｘのいずれかの被雇用者」である場合、アリスが実際に部門Ｘの被雇用者であれば、ｐ’＝”Ａｌｉｃｅ（アリス）”はｐから導出されたと言われる。動作ａ’はａから導出されなければならない。例えば、ａが「修正（注釈という動作を含む）という動作と変更するという動作」であれば、ａ’＝"the annotation of annotating（注
釈する動作）"は、ａから導出されたと言われる。リソースｒ’はｒから導出されなけれ
ばならない。例えば、ｒが「出版社Ｙのいずれかの本」である場合、「ラーニングＸＭＬ」が出版社Ｙから出版されていれば、ｒ’＝"Learning XML（ラーニングＸＭＬ）"は、ｒから導出されたと言われる。
【００６６】
規則Ｄ２は、各々の条件ｃ’iがこれに対応するｃiから導出されなければならないことを述べている。ある条件の状態の導出は、この条件のタイプ、そのあり得る状態およびその現在値によって異なる。規則Ｄ２．１〜Ｄ２．３は、以下に解説するようにこの依存性を定めている。
【００６７】
規則Ｄ２．１を解説するために、ｃを、異なる多くのチャプタ、例えば、チャプタ１、３および５に対する印刷を制限する条件であるとすると、Ｑ＝｛chapter 1, chapter 3, chapter 5（チャプタ１、チャプタ３、チャプタ５）｝となる。第１のサブ権利を導出する場合、有効なＱ’の集合は、｛chapter 1｝、｛chapter 3｝、｛chapter 5｝、｛chapter 1, chapter 3｝、｛chapter 1, chapter 5｝、｛chapter 3, chapter 5｝および｛chapter 1, chapter 3, chapter 5｝となる。｛chapter 1｝が第１のサブ権利に譲与された後、Ｑは｛chapter 3, chapter 5｝となり、Ｑ’は、｛chapter 3｝、｛chapter 5｝および｛chapter 3, chapter 5｝のうちの１つでしかあり得ないことになる。
【００６８】
規則Ｄ２．２を解説するために、ｃを、再生動作を３回に制限する条件であるとすると、Ｑ＝｛３｝となる。第１のサブ権利を導出する場合、有効なＱ’の集合は、｛１｝、｛２｝および｛３｝である。例えば、｛２｝が第１のサブ権利に譲与された場合、ｃの現在値は１であり、Ｑ’は、｛１｝でしかあり得ないことになる。
【００６９】
規則Ｄ２．３を解説するために、ｃを、再生動作の有効期間を１１／１／２００４〜１１／５／２００４に制限する条件であるとする。Ｑを、｛｛１１／１／２００４〜１１／２／２００４｝、｛１１／１／２００４〜１１／３／２００４｝、｛１１／２１／２００４〜１１／３／２００４｝｝などの１１／１／２２０４〜１１／３／２００４の可能なすべてのサブインターバルの順序集合であるとする。インターバル｛１１／２／２００４〜１１／３／２００４｝が第１のサブ権利に譲与されると、Ｑは｛｛１１／１／２００４〜１１／２／２００４｝、｛１１／３／２００４〜１１／５／２００４｝｝となる。
【００７０】
したがって、上記で定義した導出規則は、ｐがｐ’を意味し、ａがａ’を意味し、ｒがｒ’を意味し、ｃiがｃ’iを意味し、Ｑ’i⊂Ｑi ∀ｉ≦ｍ≦ｎであれば、譲与された権利ｖ＝（ｐ’、ａ’、ｒ’、ｃ’i⇒Ｑ’i：ｉ＝１，．．，ｍ）をｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）から導出可能であることを提示している。
【００７１】
ここで、ｖは、ｕから導出されなかった条件を含むことがあり得る。これらの条件は本発明では制限された条件と呼ばれる。制限された条件によって、サブ権利の譲与者は、権利の被譲与者がサブ権利を消費するのをさらに制限することが許可される。サブ権利ｖが何らかの制限された条件を含む場合、これはときとして条件付きサブ権利と呼ばれる。例えば、会社Ｘがその部門Ｙに対して、この部門Ｙが部門の目標の少なくとも８０％を達成すればＤＶＤ Ｚを１０コピー譲与する。ｖをｕに統合して戻す場合、すべての制限された条件が無視される。
【００７２】
ｐとｐ’との間、ａとａ’との間、ｒとｒ’との間、ｃiとｃ’iとの間の関係はアプリケーションによって異なる。これらの関係は、アプリケーション内で定義可能であったり、権利表記中で表現可能であったりする。このような関係をアプリケーション内で定義すると、このアプリケーションは一方の式が他方によって意味されるかどうか判定する。関係を権利表記中で表現すると、アプリケーションは、１つの式が別の式を意味するかどうかを、これらの式を権利表記に照らし合わせて評価することによって検証することが可能である。
【００７３】
ｖ＝（ｐ’、ａ’、ｒ’、ｃ’i⇒Ｑ’i：ｉ＝１，．．，ｍ）がｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）から導出されると、ｖは、ｕの導出またはｕのサブ権利であると言われる。言い換えれば、ｕはｖの統合と言われる。例えば図１０および１１に示す譲与された権利は、図１４に指定した譲与された権利のサブ権利である。ｖがｕから導出されると、ｖはｕの導出またはサブ権利と呼ばれる。
【００７４】
図１２に、譲与権利１６０の導出を示す。譲与権利１６０は主体ライブラリＡに譲与され、コピーの数に関連する１つの条件を有する。主体であるジョン・ドエがライブラリＡのメンバーであれば、譲与権利１６２は譲与権利１６０から導出される。この例では、譲与権利１６１は２つの条件を含む。条件１６３はジョン・ドエに対してリソースを１コピーだけ与える。条件１６４は、ジョン・ドエがリソースを使用することに対して時間制限を割り当てる。
【００７５】
同様に、図１３は、別のデバイス上で用いられる譲与権利１７０の導出を示している。譲与権利１７０は、主体のジェーンがリソースを２コピー用いることを提示する１つの条件１７１を有する。導出された権利１７２は、ジェーンがリソースを１コピー用いることを制限する条件１７３を含む。
【００７６】
統合規則
【００７７】
権利を統合する方法は、権利を導出する方法の逆である。
【００７８】
権利をｕ、サブ権利をｖとすると、ｖを統合してｕに戻す規則は次のように定義される。
定義：ｕ＝（ｐ、ａ、ｒ、ｃi、1⇒Ｑi：ｉ＝１，．．，ｎ）を権利として、ｖ＝（ｐ’、ａ’、ｒ’、ｃ’i、2⇒Ｑ’i：ｉ＝１，．．，ｍ）をｕのサブ権利とする。ｍ≦ｎであって、次の規則が適用されると、権利ｕ’＝（ｐ、ａ、ｒ、ｃi⇒Ｑ*i：ｉ＝１，．．，ｎ）は権利ｕとそのサブ権利ｖの統合であると定義される。
規則Ｉ１：ｐ⇒ｐ’、ａ⇒ａ’、ｒ⇒ｒ’
規則Ｉ２：∀i≦ｍ、ｃi⇒ｃi’
規則Ｉ２．１：Ｑiが、ｃiの可能な状態値を表す非順序集合であれば、Ｑ’iもまたｃ’iの可能な状態値を表す非順序集合でなければならず、また、Ｑ*i＝Ｑi∪Ｑ’iである。
規則Ｉ２．２：Ｑiが、ｃiの累積値を表す唯一の値を含む場合、‖Ｑ*i‖＝‖Ｑi‖＋‖Ｑ’i‖、ここで‖Ｑi‖は、Ｑiのノルム（すなわち値）を意味する。
規則Ｉ２．３：Ｑiが、ｃiの可能な範囲値を表す順序集合であれば、Ｑ’iもまたｃ’iの可能な範囲値を表す非順序集合でなければならず、また、Ｑ*i＝Ｑi（＋）Ｑ’iである。（＋）は、カスタマイズされた和集合演算であり、システムによって異なる。例えば、範囲の粒状性と、範囲をどのようにすれば合併可能な（範囲を合併しながらもギャップをどのように取り扱うかを含めて）定義することが可能である。
【００７９】
規則Ｉ１は、サブ権利が、この導出元の権利によって許可されたような主体、動作およびリソースのみを含まなければならないことを定めている。規則Ｉ２は、条件ｃ’i各々が、その対応するｃiから導出されなければならないことを提示している。条件の状態の導出は、この条件のタイプ、その可能な状態値およびその現在状態値によって異なる。規則Ｉ２．１〜Ｉ２．３は、この依存性を定義している。特に、規則Ｉ２．１は、ＱおよびＱ’が双方とも判明している値の非順序集合であれば、統合されたＱ*はＱおよびＱ’の和集合であると述べている。規則Ｉ２．２は、ＱおよびＱ’各々が、累積値を表す１つのエレメントを有すれば、統合された累積値はこれら２つの値の和であることを述べている。規則Ｉ２．３は、ＱおよびＱ’がインターバルを表す順序集合であれば、統合されたＱ*は双方の集合の和集合であることを述べている。
【００８０】
分割可能権利、現在の権利、共有可能権利およびグループライセンス
【００８１】
上記で定義した導出規則は、サブ権利を所与の権利から導出する、または、所与の権利が別の権利から導出可能であるかを判定するための一般的なメカニズムである。この規則は、サブ権利が次のメカニズム、すなわち、譲与権利のいずれかのコンポーネントを用いてサブ権利を導出するメカニズムと、何らかの状態条件を分割して、譲与権利からサブ権利を作成するメカニズムのうちのどちらかまたは双方を用いて導出することが可能であることを指定している。
【００８２】
しかしながら、様々なアプリケーションでは、譲与権利のあるコンポーネントだけをサブ権利を導出するために用いることを許可、または、ある状態条件だけを分割してサブ権利を作成することを許可し得る。例えば、ライブラリアプリケーションは、譲与権利に指定されている主体を用いてサブ権利を導出することを許可しているため、ライブラリは、そのメンバーのためのサブ権利をライブラリに譲与された権利から導出することが可能である。図１２は、ライブラリＡが、そのメンバーであるジョン・ドエのためにその譲与権利からサブ権利を導出する様子を示している。図１２では、サブ権利は主体に基づいて導出される。
【００８３】
別の例では、ホームネットワークアプリケーションが、ある条件状態を分割することを許可している。この場合、ホームネットワークのユーザは、ユーザに譲与された権利からユーザのホームネットワーク内の各々のデバイス用の権利を導出することが可能である。図１３は、ユーザのジェーンがジェーンの譲与権利から別のデバイス上で用いるための権利を導出するシナリオを示している。この例では、サブ権利は、譲与権利と関連する条件状態の分割可能性に基づいて導出される。
【００８４】
譲与された権利は、サブ権利を導出する機能に基づいて次のタイプ、すなわち、分割可能権利、並列権利、共有可能権利およびグループ権利に分類することが可能である。これらのタイプの権利の各々を以下に説明する。
【００８５】
分割可能権利
【００８６】
分割可能権利とは、ある権利をサブ権利を作成するために分割しながらも同時にこの分割可能権利の他のコンポーネントを不変のままとすることが可能なような１つ以上の状態条件付きのこのような権利のことである。分割可能権利の用途は多い。例えば、これらは、消費者が権利を公平に用いることを刺激するために用いることが可能である。消費者は、ある権利を獲得すると、これをサブ権利に分割して、様々なデバイス上で、様々な場所で、様々な時間でなどのように用いる。
【００８７】
サブ権利が分割可能権利から導出されると、オリジナルの分割可能権利中の各々の分割可能条件の現在状態を、この導出されたサブ権利の各々中の対応する条件の初期状態とこの条件の状態関数とにしたがって更新される。例えば、分割可能権利は、ユーザが権利を行使可能な回数を制限する条件を有し、また、現在の条件状態が、まだ行使の回数が５回残っていることを示していると仮定する。最大で２回の行使回数を有するサブ権利を導出する場合、導出元の分割可能権利の条件の現在状態を更新して、３回行使回数が残っていることを反映する（行使回数５回から２回を差し引く）。
【００８８】
導出されたサブ権利の基準条件は、オリジナルの分割可能権利の同じ基準条件に関して制限される。例えば、分割可能権利が、この権利を行使し得る時間範囲を指定する条件を有する場合、導出されたサブ権利もまた、権利を行使し得る時間範囲を規定する基準条件を有さなければならず、また、サブ権利の時間範囲は、この分割可能権利に対して指定された時間範囲内に完全に入らなければならない。
【００８９】
したがって、権利ｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）は、ｃｉが分割可能条件であるようなｉが少なくとも１つあれば、分割可能である。さらに、ｖ＝（ｐ、ａ、ｒ、ｃ’i⇒Ｑ’i：ｉ＝１，．．，ｍ）は、次の仮定が成立すれば導出またはｕのサブ権利である。
ｃiが分割可能条件であるようなｉが少なくとも１つ存在する、
ｖが、ｕ中に指定されているすべての条件を含み、ｃ’i＝ｃi、ｉ＝１，．．，ｎ、および、Ｑ’i⊂Ｑi、∀i≦ｍ≦ｎであり、
導出ｖ後のｕの各々の分割可能条件ｃiの現在状態が、導出ｖ前のｃiの現在状態と、導出ｖの初期状態およびｃiの現在関数にしたがって更新され、
すべての基準条件ｃiに対して、ｃ’iがｃiであるかｃiの制限であるかである。例えば、条件ｃiが時点ｔ１以前ではなく、導出された条件ｃ’iはｔ３以前ではなくｔ４以後ではないが、ここでｔ１＜＝ｔ３＜＝ｔ４＜＝ｔ２であり、表記＜＝は「以下」を表し、
すべての無状態条件ｃiに対して、ｃi’はｃiである。
【００９０】
図１４は、分割可能権利ｕ（２００）からサブ権利ｖ（２１０）を導出するプロセスを示す。この例では、分割可能権利ｕは３つの条件を有する。
行使許可回数が１０であると規定している分割可能条件２０１の現在状態２０２は行使回数が５回残っている、
権利行使可能な時間範囲を基準条件２０３が（２００４年１月以後であり、２００６年１月以前）規定している、
譲与権利を行使している間に宣伝Ｙを実施しなければならないと無状態条件２０４が規定している。
【００９１】
同じ条件集合付きのｕからサブ権利ｖ（２１０）が導出される。特に、
分割可能条件２１１の場合、ｖは、行使許可回数として２回を規定している条件を有する。ｕ中の同じ条件の現在状態が、残余行使回数５回から残余行使回数３回に更新される。
基準条件２１３の場合、ｖは、権利を行使し得る時間範囲を規定している条件を有する。この条件はｕから導出され、したがって、ｖに規定されている時間範囲条件は、ｕ中に規定されている時間範囲内に完全に入る。
無状態条件２１４の場合、ｖはｕとまったく同じ条件を有する。
【００９２】
導出後、分割可能権利ｕ（３００）の現在状態２０５は残余プレイ回数が３回である。
【００９３】
この例では、擬似言語のフォーマットが、譲与された権利と条件の特徴を反映するように変更されている。したがって、「GRANTED RIGHTS（譲与権利）」は、譲与権利が実際に分割可能であることを示す「DIVISIBLE RIGHTS（分割可能権利）」に変更されている。「CONDITION（条件）」は、条件タイプを反映するように、「DIVISIBLE CONDITION（分割可能条件）」、「REFERENCE CONDITION（基準条件）」または単に「CONDITION（条件）」に変更されている。分割可能条件の宣言には、条件の現在状態が含まれている。
【００９４】
このフォーマット変更は、特定の実現を提案するものではない。譲与された権利と条件のタイプを特定するために用いられる方法は、実現に委ねられる。例えば、このタイプは表現に明示的に宣言されている（図４のように）または他のいずれかのメカニズムを用いて特定された名前によって特定可能である。しかしながら、条件タイプの明示的な宣言には利点がある。同じ条件（例えば、最大の許可行使回数）が、１つの譲与権利中で分割可能であるが、他の権利中ではそうではない。分割可能条件の現在状態は、条件内（図４のように）宣言されるか、または、既知の認可ソース（認可された追跡デバイス、遠隔サービス、中央サービスなど）から検索されるかである。
【００９５】
並列権利
【００９６】
並列権利とは、サブ権利を主体に基づいて導出可能な元の権利であり、この場合、この並列権利の他のコンポーネントは不変のままである。並列権利においては、主体とは、主体のグループ、多数の識別を有する同じ主体または双方のことである。グループ中の主体はその各々が、並列権利中に指定されている同じ権利を継承する。並列権利によって、譲与権利中に指定されている主体が導出可能となり、指定されている主体に対するサブ権利が導出可能となるようにする。
【００９７】
並列権利は状態条件を含むが、このような条件は分割可能ではない。サブ権利が状態条件付きの並列権利から導出されると、状態条件がサブ権利中で正確に（同じ状態値で）再現される。その結果、サブ権利中の条件状態は、導出された主体ごとに個々に管理される。したがって、導出された主体は各々が、状態を個々に維持して、譲与権利の消費を追跡する。
【００９８】
例えば、並列権利として、グループの各メンバーに対して同じ権利集合を与えるメンバー資格がある。一部のアプリケーションでは、権利消費デバイスが、並列権利中の主体によって指定されているグループに対して特定の主体が実際に属していることを証明することが不可能である場合には、サブ権利を並列権利から導出することが必要となる。
【００９９】
権利ｕ＝（ｐ、ａ、ｒ、ｃi⇒Ｑi：ｉ＝１，．．，ｎ）は、次の条件が成立すれば並列権利である。
ｃiが、すべてのｉに対して分割可能条件ではなく、
ｐ⇒ｐ’となるようなｐ’が少なくとも１つ存在し、また、権利ｖ＝（ｐ’、ａ、ｒ、ｃi⇒Ｑi：ｉ＝０，．．，ｎ）がｕの導出である。例えば、ｐが音楽クラブであり、ｐ’が音楽クラブのメンバーであるアリスであれば、ｐ⇒ｐ’である。別の例では、ｐがアリスであり、アリスはまた、「Key Holder A（キーホルダーＡ）」としても知られている。すると、ｐ⇒ｐ’であり、ここで、ｐ’は「キーホルダーＡ」である。
【０１００】
図１５は、音楽クラブの各々のメンバーに、ルイ・アームストロングの「What a wonderful world（この素晴らしい世界）」というＣＤをプレイする無制限の権利を譲与する並列権利ｕ（２２０）を示す。この例では、主体のジョン・ドエは、音楽クラブのメンバーである。したがって、ジョン・ドエは、主体ジョン・ドエに同じＣＤをプレイする無制限の権利を譲与するサブ権利ｖ（２２１）を導出することが可能である。
【０１０１】
図１６は、状態条件２２６を含む並列権利ｕ（２２５）を示す。この例では、この並列権利は、音楽クラブのメンバーが、ルイ・アームストロングの「この素晴らしい世界」というＣＤを５回プレイすることを指定している。導出前の現在状態２２７では、プレイ回数が３回残っている。サブ権利ｖ（２３０）とｗ（２３５）を導出する場合、並列権利中の状態条件の現在状態（オリジナルの最大回数である５回のうちの３回が残っている）が、それぞれ条件２３１と２３６としてサブ権利の各々中で再現される。導出後は、サブ権利ｖおよびｗの条件状態は互いに独立に追跡される。グループの各々のメンバーの条件状態は、中央認可サーバ、ユーザデバイスなどで追跡可能である。
【０１０２】
共有可能権利
【０１０３】
共有可能権利とは、主体と、もしあれば、その分割可能条件の状態との双方に基づいてサブ権利を導出することが可能な元の権利のことである。したがって、共有可能権利は、指定された主体間で共有可能な最大限の権利を指定する。導出された主体が共有可能権利からサブ権利を導出すると、条件状態を、導出されたサブ権利に割り当てられた条件状態にしたがって共有権利から推論する。
【０１０４】
並列権利と分割可能権利は、共有権利の特殊な場合である。特に、並列権利は、分割可能条件無しの共有可能権利の特殊なケースであり、分割可能権利は、少なくとも１つの分割可能条件付きであるが、それから導出することが不可能な主体（主体はグループを指定しない）付きの共有権利の特殊なケースである。
【０１０５】
共有権利と並列権利間の主要な相違は、導出されたサブ権利中の状態条件の状態をどのように追跡するかという点である。並列権利中の状態条件は分割可能ではないため、各々の導出されたサブ権利の条件状態は互いに独立に追跡される（状態は、各々のサブ権利の主体に対して別個に追跡される）。共有可能権利中の状態条件は分割可能であるため、導出されたサブ権利の条件状態は共有される（すべての導出されたサブ権利は、各々の分割可能条件に対して同じ状態を指し示している）。この結果、サブ権利の主体が条件状態を共有することになる。
【０１０６】
図１７は、「この素晴らしい世界」というＣＤを１００コピー所有して、この１００コピーをメンバー間で分配する権利を音楽クラブに譲与する共有可能権利ｕ（２４０）を示す。この例では、分割可能条件の現在状態２４１は、１０コピーが今までに分配され、９０コピーが残っていることを示している。音楽クラブのメンバーであるジョン・ドエという主体は、サブ権利ｖ（２４２）中にこのＣＤを１コピー譲与される。サブ権利ｖは、１コピーの状態２４３付きの共有可能権利ｕから導出される。共有可能権利ｕ中の分割可能条件の現在状態２４４は、残りのコピー数が８９に減少する。
【０１０７】
分割可能権利と並列権利用のアプリケーションを含む、共有可能権利の特徴を利用可能なアプリケーションは多く存在する。このようなアプリケーションの１つは、「グループライセンス」と呼ばれ、以下に説明する。
【０１０８】
グループライセンス
【０１０９】
グループライセンスとは、一人以上の認可されたユーザに対して最大限の権利を譲与して、この認可済みユーザが、自分たちの間での自分たち自身の共有ポリシーにしたがって譲与権利を共有したり、他の認可済みユーザの集合と共有したり、認可済みユーザが共有権利を返却したり、さらに、他の認可済みユーザと各々の共有権利をさらに共有したりすることを許可する権利のことである。したがって、グループライセンスは、サブ権利を返却したり、統合してグループライセンスに戻したりすることを許可する共有権利である。
【０１１０】
本発明中に定義するように、ライセンスとは、あるユーザに譲与された権利のことである。したがって、「ライセンス」と「権利」という用語は、交換可能である。多くのＤＲＭシステムがライセンスに対して異なった定義をしているが、ライセンスは少なくとも１つの譲与された権利を含まなければならない。したがって、ＤＲＭシステムで使用されるライセンスの定義を、本発明中のライセンスの定義にマッピングすることが可能である。例えば、ＭＰＥＧ ＲＥＬでは、「ライセンス」という用語は、譲与権利の集合に、他の情報（発行者、ライセンスの整合性などに関する情報など）を足したものである。したがって、ＭＰＥＧ ＲＥＬライセンスは、本発明に定義するように多数のライセンス中にマッピングすることが可能である。
【０１１１】
上記のようなグループライセンスの概念は、共有可能な権利と権利の統合という概念を用いて実現することが可能である。グループライセンスは、共有可能権利であるため、認可されたユーザおよび／または認可済みユーザのグループ中で共有されるように動的に分割可能である。あるグループライセンスを共有目的で分割すると、新しいライセンスが作成されて、グループライセンス中に指定されている条件状態が、新しいライセンス中に指定されている条件状態を推論するように調整される。この作成された新しいライセンスは共有されたライセンスと呼ばれるが、また、グループライセンスでもある。したがって、共有されたライセンスは、認可済みのユーザによって消費するか、または、認可済みのユーザおよび／または認可済みユーザのグループ間で共有目的でさらに分割することが可能である。
【０１１２】
共有されたライセンスはまたグループライセンスでもあるため、この共有ライセンスの権利被譲与者は、権利譲与者として動作して、下流での共有目的でその共有ライセンスから新たな共有ライセンスをさらに導出することが可能である。したがって、多段階権利共有や、権利被譲与者の決定権に基づいた共有や、異なったグループの主体および／またはデバイス間での共有などの動的権利共有がサポートされる。
【０１１３】
共有ライセンスは、一旦作成されると、消費目的利用可能となる。共有ライセンスが使用されるごとに、その条件状態が更新されて、その使用を反映するようにする。どの時点でも、共有ライセンスの残っている権利は、上に開示した権利統合方法を用いて、このライセンスの導出元であるグループライセンスに対して返却することが可能である。
【０１１４】
グループライセンスの概念は、権利とリソースの共有、デバイス間での共有、ユーザ間での共有、組織間での共有などに関するあらゆる態様をカバーしている。グループライセンスは、権利とリソースの動的共有を可能とする多くのアプリケーションに対する基本的な要素となりえる。このようなアプリケーションには、これに限られないが、次のものがある。
ライブラリ：あるライブラリが、「風とともに去りぬ」という題名の本をある数だけに対するグループライセンスを譲与される。いつでも、このライブラリは、この本のコピーを、そのグループライセンスから共有ライセンスを導出することによってライブラリメンバーに貸し出すことが可能である。このライブラリが共有ライセンスを導出すると、利用可能なコピーの総数は、ライブラリメンバーがこの本を返却するまで減少する。
ホームネットワーク：ユーザのホームネットワークは、様々なＤＲＭ能力を有する様々なデバイスを含んでよい。ユーザは、前もってどのネットワークデバイスがライセンスを消費するかを指定することなく、ユーザのホームネットワーク内で使用する目的でライセンスを購入するという利便性を欲しがる。この目的のため、ユーザはグループライセンスを獲得して、ホームネットワーク中の特定のデバイスのためにそれから共有ライセンスを導出する。
メンバー資格：あるグループのメンバーは、このグループに譲与されている一般的なライセンスを用いる代わりに自分たち自身のための特定的なライセンスを導出したがるが、これは、ユーザデバイスが一般的ライセンスを執行することが不可能であるからである。
【０１１５】
次の例は、グループライセンスの概念とグループライセンスからどのように共有ライセンスを導出するかを示している。
【０１１６】
図１８は、映画Ｂの１００コピーの権利を企業Ａに譲与するグループライセンス２５０を示す。グループライセンスは、最初に作成されたときは、最大コピー数を１００と規定し、１００コピーが残っているという現在状態を規定する分割可能条件を含む。企業Ａは、営業上の必要性にしたがってその被雇用者または被雇用者グループ間に映画Ｂの１００コピーというプールを分割してよい。
【０１１７】
図１９は、グループライセンス２５０中のその１００コピーというプールから映画Ｂの１０コピーをその人事部門に譲与する。企業Ａは、人事部門に対して映画Ｂの１０コピーに対する権利を譲与する共有ライセンスを導出するが、これは条件２５６に反映される。図１９はまた、図１８に示すグループライセンス中の条件状態２５１をどのように更新して、１００コピーのプールから１０コピーを差し引いて９０コピーが残るようにするかを示している。
【０１１８】
企業Ａが人事部門に譲与する共有ライセンス２５５もまた、さらに分割可能なグループライセンスである。図２０は、グループライセンス２５７と条件２６１に反映されるように、企業Ａの人事部門がその被雇用者のうちの一人であるジョン・ドエに対して、映画Ｂの１コピーに対する権利を譲与する様子を示している。図２０はまた、人事部門のライセンス中の条件状態２５６をどのように条件状態２５７に更新して、１０コピーのそのプールから１コピーを差し引いて９コピーが残るようにするかを示している。図２０はまた、人事部門が映画Ｂの１コピーをジョン・ドエに譲与する動作が、企業Ａのオリジナルのグループライセンス中の条件状態２５１に影響しない（企業Ａにはいまだ９０コピーが残っている）ことを示している。
【０１１９】
ジョン・ドエに映画Ｂの１コピーを譲与した後では、図２１に示すように、人事部門は、その残っているコピーのうちの２つを企業Ａに返却すると決心する。返却したら、企業Ａのグループライセンス２５０に対する残りのコピーの数は２だけ増加して条件状態２５１中の９０コピーから条件状態２５２中の９２コピーとなり、同時に、人事部門のライセンス２５５に対する残りのコピーの数は２だけ減少して条件状態２５７中の９コピーから条件状態２５８中の７コピーになる。
【０１２０】
図２２は、映画Ｂの１００コピーというプールの共有を許可する企業Ａのグループライセンス（図１８に示す）の擬似ＭＰＥＧ ＲＥＬ表現２６０を示す。企業Ａは、このプールを被雇用者のグループ間に、コピーの総数がプールのキャパシティを超えない限り各々のグループに対して共有ライセンスを発行することによって分割してよい。分配する権利は、ｓｅｅｋＡｐｐｒｏｖａｌ条件を条件とする発行権利を用いて指定される。このｓｅｅｋＡｐｐｒｏｖａｌ条件は、追跡サーバが、プール中のコピーの残数と共有ライセンスに対して要求されているコピーの数とを追跡することに依存している。分配可能な使用権利は、内部譲与に含まれている。これには、受領側ユーザグループの識別のプレースホルダとしての変数Ｙと、受領側グループに割り当てられたコピーの数のプレースホルダとしての変数Ｘと、企業Ａが共有ライセンスに追加したがっているいずれかのカスタム条件のプレースホルダとしての変数Ｚが含まれている。
【０１２１】
図２３は、企業Ａの人事部門（図１９に示す）に対するライセンスの擬似ＭＰＥＧ ＲＥＬ表現２６５を示す。変数Ｙ、Ｘ、およびＺに、人事部門（受領側グループの識別）、１０（人事部門に割り当てられたコピー数）および使用報告（すべての使用を指定されたサーバによって追跡される必要がある）が代入される。その他の情報は、現在のライセンスと、現在のライセンスが導出する元のライセンスとを特定する。
【０１２２】
図２４は、サブグループライセンスと共有ライセンスの双方がグループライセンスから導出される使用事例を示す。中心ライブラリＣは、本Ｂを１００回コピーすることを許可するグループライセンス２８０を獲得する。中心ライブラリは、その必要性によってローカルライブラリのためにそのグループライセンスからサブグループライセンス２８１と２８２を作成する。Ｃは、２０コピーをサブループライセンス２８２中でローカルライブラリＸに分配し、３０コピーをサブグループライセンス２８１中でライブラリＹに分配する。ローカルライブラリＹはさらに、サブグループライセンス２８４中でライブラリＺにそのコピーの１０コピーを分配する。さらに、共有ライセンス２８３、２８６、２８７が、グループライセンス２８０、サブグループライセンス２８２、サブグループライセンス２８１またはサブグループライセンス２８４から発行されてよい。
【０１２３】
権利とリソースの動的共有をサポートするシステム
【０１２４】
上記に開示したグループライセンスの概念は、権利共有のあらゆる態様をカバーしている。これは、共有可能権利の消費を認可し、分散された共有権利を含むライセンスを発行し、グループライセンスと共有可能ライセンスの双方に対する権利の状態の管理が可能なあらゆるＤＲＭシステムによって実現可能である。図２５は、このようなＤＲＭシステムの例を示す。ＤＲＭシステム３００は、例えば、起動サーバ３０２、認可サーバ３０３、１つ以上の権利消費デバイス３０５、保護コンテンツ／アセット分配サーバ３０８、ライセンスサーバ３１０および保護アプリケーション／サービス３１１を含む。認可サーバ３０３は、１つ以上のキー３０４と関連付けられてよい。権利消費デバイス３０５はＤＲＭコンポーネント３０６を含み、また、１つ以上のライセンス３０７と関連付けられる。保護コンテンツ／アセット分配サーバ３０８は、保護されたコンテンツ／サーバ３０９を分配する。ライセンスサーバ３１０は、本システムにライセンス３０７を提供する。保護アプリケーション／サービス３１１は、明瞭なコンテンツ／アセット３１２と権利提案を提供するが、これは権利と条件とを含む。
【０１２５】
図２６は、動的な権利とリソースの共有をサポートするシステムの基本的なコンポーネントを示す。これらのコンポーネントには、インストールコンポーネント３２１、インストール追跡コンポーネント（ＴＣＩ）３２２、共有追跡コンポーネント（ＴＣＳ）３２３、共有コンポーネント３２４、委託コンポーネント３２５、消費コンポーネント３２６および消費認可コンポーネント３２７が含まれる。各々のコンポーネントは、ハードウエアコンポーネント、ソフトウエアコンポーネント、デバイス、サービスなどとして実現可能である。グループライセンスは、一旦権限によって発行されると、その使用を追跡する元となる特定の環境に拘束されたりされなかったりする。本発明の好ましい実施形態では、グループライセンスは環境には初期は（ライセンス発行時は）拘束されない。このプロセスによってより大きなフレキシビリティが与えられるが、これは、グループライセンスは、特定の環境に限られることなくどこでもいつでも獲得することが可能であるからである。
【０１２６】
図２６に示すように、グループライセンス３２０は、環境に拘束されなかった場合には、共有されたり使用されたりすることが可能となる前にインストールコンポーネント（ＩＣ）３２１によってインストールされなければならない。ＴＣＩ３２２がこのインストールを認可する。このインストールの目的は、グループライセンス３２０が以前にはインストールされていなかったこと、そして、これからはグループライセンスの権利の状態を追跡する、共有追跡コンポーネント（ＴＣＳ）と呼ばれる追跡コンポーネント３２３にグループライセンスが拘束されることを保証することにある。
【０１２７】
グループライセンスの権利の状態はどのデバイスにでも保存可能であるが、権利の状態は、権利の共有を制御する共有コンポーネントによって証明され、検証されなければならない。例えば、権利の状態は、インストールされたグループライセンスと同じデバイスに保存するか、グループライセンスが拘束されている認可コンポーネントと同じデバイスに保存するか、遠隔サービスに保存するか、または、グループライセンス内に保存することが可能である。権利の状態の保存する様々な考えられる戦略が、図１７、１８、１９、２０および２１ならびに本発明の他の図面に図示されている。権利の状態がグループライセンス自体内に保存された場合、権利の状態が更新されるごとにグループライセンスは変換されて（なぜならライセンスが消費されたか、または、権利が行使されたからである）、新しい状態を反映するようにする。この新しい状態を有するグループライセンスが交換グループライセンスであれば、オリジナルのグループライセンスは、一旦交換グループライセンス中の新しい状態を反映するために変換されたら無効となる。
【０１２８】
グループライセンスは、一旦インストールされれば、インストール済みグループライセンスと呼ばれ、共有目的に対して利用可能となる。共有コンポーネント（ＳＣ）３２４は、要求を、インストールされたグループライセンスを解釈し、ＴＣＳ３２３から現在の権利状態を検索し、この現在の権利状態をこの要求に照らし合わせて検証し、共有ライセンス（認可されれば）作成することによって処理する。インストールされたグループライセンスから導出されたこの共有ライセンスは、委託証明目的で委託コンポーネント３２５に対して利用可能なものとされる。
【０１２９】
この共有ライセンスは、これ自体が、さらなる共有目的で利用可能とされるグループライセンスである。これは、次の形態のうちの１つであり得る。
拘束グループライセンス：このタイプのライセンスは、作成されるとＴＣＳに対して拘束される。共有ライセンスが拘束されるＴＣＳは、インストールされたグループライセンスが拘束されるＴＣＳと同じでも異なっていてもよい。編成が小さい場合、追跡コンポーネントは同じでもよいが、編成が大きかったり主体のグループが多様であったりすれば異なったものとなる。
非拘束グループライセンス：このタイプのライセンスは、発行されたときには特定のＴＣＳに拘束されていないが、後になってＴＣＳに拘束されることがあり得る。このタイプのライセンスは、ライセンスが生成されるときに対象の消費環境または対象のＴＣＳが知られていない場合に生成される（例えば、別の権利被譲与者グループ、別のネットワークなどとの共有のためにライセンスを作成する）。別のシナリオでは、ライセンスの譲与者は、ＴＣＳに拘束するオプションを維持することによってライセンスのフレキシビリティをより大きいものとすることを提案したがる。このような状況下では、ＴＣＳ拘束権限をライセンス被譲与者または他の当事者に委譲することも可能である。
消費ライセンス：このタイプのライセンスは、共有ではなく主として消費目的で作成される。しかしながら、これは、認可された主体またはデバイス間で共有することが可能である。
【０１３０】
図２６に示す基本的コンポーネントを用いて、様々な構成でシステムを設計することが可能である。消費ライセンスが作成されると、消費コンポーネント３２６は、消費認可コンポーネント３２７によって認可されればリソースの消費を可能とする。
【０１３１】
図２７は、主要な２つのデバイス、すなわち、グループライセンスデバイス３５０と消費デバイス３５６を含む１つの好ましい実施形態を示す。グループライセンスデバイス３５０は、インストールコンポーネント３５１と共有コンポーネント３５２をそれぞれ含む。これは、グループライセンスをインストールしたり、アンインストールしたり、共有ライセンスを作成したりするすべての要求を取り扱う。消費デバイス３５６は、ライセンスを消費するための消費コンポーネント３５７を含む。この例示の構成では、インストール追跡コンポーネント（ＴＣＩ）３５３、ＴＣＳ３５４および委託コンポーネント３５５は、グループライセンスデバイス３５０の外部にある。共有認可デバイスは、自身に拘束されたすべてのインストール済みグループライセンスの権利の状態を追跡する。
【０１３２】
図２８は、代替の構成を用いる別の好ましい実施形態を示す。この実施形態では、ＴＣＳ３５４はグループライセンスデバイス３５０の内部にある。この構成では、グループライセンス３５０は、共有要求を処理して、インストールされたすべてのライセンスの権利の状態を追跡する。したがって、グループライセンスデバイス３５０は、外部のＴＣＳを必要とすることなく共有要求を認可することが可能である。一旦共有要求が認可されたら、グループライセンスデバイス３５０は、共有ライセンスを作成してこの共有ライセンスを委託の証明目的で委託デバイス３５５に対して利用可能とする。
【０１３３】
図２９は、別の代替構成を用いるさらに別の好ましい実施形態を示す。この構成では、ＴＣＳコンポーネント３５４と委託コンポーネント３５５は双方ともがそれぞれ、グループライセンスデバイス３５０の内部にある。グループライセンスデバイス３５０は、すべての共有要求を処理し、インストールされたすべてのグループライセンスの権利の状態を追跡し、デバイスによって生成された共有ライセンスを証明する。これは、現在最新のＤＲＭシステムに統合するには最も実用的な構成である。
【０１３４】
図３０は、企業Ａの場合の図２９に示す構成のアプリケーションを示す。企業Ａのネットワーク内では、グループライセンスデバイス３６０がグループライセンスサーバ３６１にインストールされている。グループライセンスデバイス３５０は、この企業のネットワーク内のすべてのデバイスに対するすべての共有要求の処理専門のデバイスである。グループライセンスサーバ３６１は、グループライセンスのあらゆるインストール要求を認可する目的でネットワークを介してインストール認可デバイス３７０を含むインストール認可サーバ３６９に接続されている。企業Ａではまた、共有認可デバイス３６３をインストールしている認可サーバ３６２は、この企業内で用いられるグループライセンスの権利のすべての状態を追跡する業務専門となっている。加えて、企業Ａのネットワークは、プリンタ３６４、ワークステーション３６５、ｉＢｏｏｋ３６６およびラップトップコンピュータ３６７などの他のデバイスと、さらにアダプタデバイス３６８を含む。ネットワーク内での通信は、例えば、ハブ３７１によって容易化される。
【０１３５】
追跡コンポーネント
【０１３６】
どのＤＲＭシステムにも、追跡コンポーネントは存在する。追跡コンポーネントの機能は、権利の使用または状態を追跡することである。本発明内では、追跡とは、グループライセンスのインストールステータスを追跡したり、インストールされたグループライセンスに対する権利の状態を追跡したりすることが含まれる。本発明では、インストールを追跡するコンポーネントをインストール追跡コンポーネント（ＴＣＩ）と呼び、グループライセンスに対する権利の状態を追跡するコンポーネントを共有追跡コンポーネント（ＴＣＳ）と呼ぶ。
【０１３７】
ＴＣＩとＴＣＳの機能は、上記と同じまたは別のコンポーネントでも実施可能である。これらの機能は、同じデバイスやサービスまたは別のデバイスやサービスで実施されるように構成可能である。追跡用のデバイスやサービスは、どこに置かれても、動的権利共有をサポートするシステム中の他のコンポーネントによって委託されなければならない。システム内のすべてのコンポーネントによって委託される権限による証明などのこのような委託を確立する多くのメカニズムが知られている。
【０１３８】
インストール追跡コンポーネント（ＴＣＩ）
【０１３９】
このコンポーネントは、インストールされたグループライセンスの権利の初期状態と、インストールされたライセンスの権利の状態を追跡する共有追跡コンポーネントの識別（ＴＣＳＩＤ）とともにグループライセンスのインストールステータスを追跡する。上述したように、インストールステータスを追跡する目的は、グループライセンスが、その権利の状態を追跡するＴＣＳにしか拘束できないことを保証することである。
【０１４０】
図３１は、どのようにしてインストール要求を追跡するかを示す。このプロセスに対する入力には、グループライセンスとＴＳＣのＴＣＳＩＤを含む。グループライセンスの整合性と信憑性はステップ４００で確認される。整合性は、グループライセンスが変更されたり改竄されたりされていないことを保証するために確認される。信憑性は、グループライセンスがＴＣＩに委託された権限によって発行されたことを保証するために確認される。入力されたグループライセンスが有効で真正であれば、グループライセンスは、ステップ４０１で、期限切れや取り消しされていないかどうかチェックする。次に、ＩＡＣはステップ４０３で追跡情報を検索して、このグループライセンスが現在インストールされているかどうかステップ４０４でチェックする。グループライセンスが有効でなければ、真正でなければ、期限切れであれば、取り消されていればまたは現在インストールされていれば、この要求はステップ４０２で拒絶される。そのようでなければ、権利の初期状態がグループライセンスから初期化され、追跡情報がステップ４０５で作成されて、ステップ４０６で権利の初期状態で更新される。
【０１４１】
グループライセンスが以前にはインストールされているが現在はインストールされていない場合、ＴＣＩは権利の状態を検証して、グループライセンスに指定されている権利が今は有効であることを保証する。そのようでない場合、インストール要求は拒絶される。
【０１４２】
追跡情報が見つからないまたはグループライセンスがインストールされたことがないことを示している場合、新しい追跡情報を作成して、権利の初期状態で更新して、この追跡情報をインストール済みであるとマーキングする。グループライセンスが以前にインストールされていて権利がまだ有効である場合、追跡情報はインストール済みであるとマーキングされる。
【０１４３】
図３２は、追跡情報４１０の好ましい構造を示す。これは、インストールされたグループライセンスもしくはライセンスＩＤ４１１、（アンインストールプロセス中に用いられる）権利の状態を追跡するコンポーネントのＴＣＳＩＤ４１２、現在のインストールステータス４１３、最初にインストールされたときもしくはアンインストールされたときのグループライセンスに対する権利の状態４１４およびアプリケーションが必要とする他の情報４１５を含む。
【０１４４】
一旦インストール要求が譲与されると、追跡情報に保存されている現在の権利状態が、インストールコンポーネント（ＩＣ）である要求元に返却される。その結果、このインストールコンポーネントは、この権利の状態を共有コンポーネント（ＳＣ）に渡して、グループライセンスの権利の初期状態を初期化することが可能となる。
【０１４５】
グループライセンスは、一旦インストールされると、最初にアンインストールされるまでは再度インストールすることは不可能となる。アンインストールプロセスによって、グループライセンスは、その権利の状態を現在追跡しているＴＣＳから解放される。アンインストールプロセスでは、インストールされたグループライセンスまたはライセンスＩＤと要求メッセージが必要とされる。この要求メッセージは、グループライセンスに対する現在の権利状態を含む認証可能メッセージである。
【０１４６】
図３３は、アンインストールするプロセスを示す。追跡情報が、入力されたグループライセンスまたはライセンスＩＤを用いてステップ４２０で検索される。次に、追跡情報がステップ４２１で検証されて、これが、グループライセンスが現在インストールされていることを示していることを保証する。加えて、ステップ４２２で、追跡情報に照らし合わせて要求を検証する。追跡情報が見つからなければ、グループライセンスは現在インストールされていないか、または追跡情報が要求に照らし合わせて検証されていない場合、ステップ４２５で要求は拒絶される。
【０１４７】
グループライセンスが現在インストールされていれば、ステップ４２２で、ＴＣＳＩＤ中に保存されているＩＤを用いて、要求メッセージを検証する。要求メッセージには、インストールされたグループライセンスに対する現在の権利状態が保存されている。多くの既知のメカニズムを用いて、要求メッセージを検証することが可能である。例えば、要求メッセージをＴＣＳで署名すると、ＴＣＳＩＤがＴＣＳのキーを含み、このキーを用いてＴＣＳの署名を検証する。ＴＣＳの署名が検証可能であれば、要求は真正である。そうでなければ、アンインストール要求は信用されない。
【０１４８】
認証可能なメッセージと証明された現在の権利の状態とが検証されたら、ＴＣＩはステップ４２３で、グループライセンスの現在の権利の状態で追跡情報を更新して、ステップ４２４で、証明された現在の権利の状態で追跡情報をアンインストールされたものとしてマーキングする。
【０１４９】
共有追跡コンポーネント（ＴＣＳ）
【０１５０】
このコンポーネントは、インストールされたグループライセンスに対する権利の状態を追跡する。グループライセンスは、一旦インストールされると、ＴＣＳに拘束される。ＴＣＳに拘束されることの利点は、権利の状態がたった１集合だけ維持されるように保証されることである。これによって、多くの様々なグループライセンスデバイスが、グループライセンスに対する権利の状態にコンフリクトを引き起こすことなく権利共有要求を処理して、共有ライセンスを発行することが可能となる。例えば、ホームネットワークにおいて、ＴＣＳがインストールされているデバイスに接続可能であればどのグループライセンスデバイスでも、ホームネットワーク中のデバイスで用いられるように共有ライセンスを発行することが可能である。
【０１５１】
グループライセンスがインストールされると、ＴＣＳの認証可能ＩＤ（ＴＣＳＩＤ）が検索されて、ＴＣＩに対して利用可能なものとされる。ＴＣＳＩＤは、アンインストール要求メッセージを認証するために後で用いられる。一旦インストールされると、ＴＣＩによって返却されたグループライセンスに対する権利の状態を用いて、ＴＣＳに保存されている権利の状態を初期化する。さらにセキュリティを高めるため、ＴＣＳは、権利の状態と他の情報に、これらをＴＣＳに保存する前にサインする。図３４に、ＴＣＳに保存する以前にそしてこれらをＴＣＳから検索した後で、権利の状態にサインし、証明し、検証するプロセスを示す。
【０１５２】
インストールされているグループライセンスがアンインストールされると、ＴＣＳは要求メッセージを生成するが、このメッセージは、アンインストールされたグループライセンスに対する現在の権利状態を含む認証可能メッセージである。すると、現在の権利状態がアンインストールの対象となるＴＣＩに渡される。インストールされたライセンスが使用、共有、統合目的で処理された場合はいつでも、ＴＣＳは、権利の状態が変化すると、その新しい状態で更新される。
【０１５３】
一部のアプリケーションでは、権利の状態はＴＣＳがインストールされているデバイスのところには保存されない。権利の状態は、維持されるかどうかとは無関係に、委託可能となるようにＴＣＳによって証明されなければならない。例えば、権利の状態はグループライセンス内に保存可能である。この場合、グループライセンス自体がレポジトリとして動作する。共有ライセンスが作成されたり統合されたりした結果、グループライセンスが変化すると、このグループライセンスも変化する。新しい権利の状態を持つグループライセンスは対象のＴＣＳによって証明されなければならない。証明されたグループライセンスは新たなグループライセンスとなって、以前のグループライセンスに取って代わる。新たなグループライセンスは、一旦作成されると、以前のグループライセンスと同じＴＣＳに拘束され、以前のグループライセンスはＴＣＳから解放される。新しいグループライセンスと以前のグループライセンスは双方とも、同じＩＤを共有する。この場合、以前のグループライセンスのインストール状態が新しいグループライセンスに転送される。
【０１５４】
インストールコンポーネント
【０１５５】
インストールコンポーネントは、グループライセンスをＴＣＩにインストールしたりアンインストールしたり、インストールされたグループライセンスをＴＣＳに対して拘束したりこれから解放したりする。拘束プロセスでは、ＴＣＳへのインストールされたグループライセンスに対する権利の状態を初期化し、これで、認可された共有コンポーネントが権利の状態を管理して追跡することが可能となるようにする。ＴＣＩにグループライセンスをインストールすることによって、このインストールされたグループライセンスが別のＴＣＳにこれ以上インストールされて拘束されることがあり得ないことを保証する。これによって、グループライセンスに譲与された権利が、複数のＴＣＳ上で複製されたり増殖されたりされることを防止する。例えば、映画Ａの２つのコピーを譲与するグループライセンスが互いに異なった２つのＴＣＳに拘束されると、ＴＣＳはその各々が譲与された権利の状態を２に初期化する。これは、各々のＴＣＳがコピーを２つ共有することを許可し、したがって、グループライセンスの条項と条件に違反することを意味する。
【０１５６】
グループライセンスが獲得されたりインストールされたりすると、インストール追跡コンポーネント（ＴＣＩ）のＩＤをインストールコンポーネントに通信し、これが正しいＴＣＩからのインストールを要求することが可能となるようにしなければならない。発行されたグループライセンス中のＴＣＩのＩＤやアドレスの符号化、何らかの既知のプロトコルを通じてのＴＣＩのＩＤやアドレスの獲得、グループライセンス権利の譲与者と被譲与者間の合意の利用など、この通信を実行する方法が多く存在する。一部のアプリケーションでは、ＴＣＩは、グループライセンス権利の譲与者のシステムの一部である。ＴＣＩがグループライセンス権利の被譲与者のシステムの一部であるアプリケーションもある。さらに、ＴＣＩが独立したサービスであるような他のアプリケーションもある。
【０１５７】
図３４に示すように、拘束するプロセスでは、グループライセンスに対する権利の初期状態が、このグループライセンスが拘束されるＴＣＳに登録される。ステップ４３０および４３１では、権利の状態の整合性値が計算され、次いで証明される。権利の状態は、一旦初期化されて証明されると、状態レポジトリ４３２に保存される。次に、ＴＣＳは、グループライセンスが使用されるごとに権利の状態を管理して追跡する。一部のアプリケーションや構成では、ＴＣＳとＴＣＩの機能が１つのコンポーネントに合成されるが、これらの機能を別々のコンポーネントに分離する他のアプリケーションや構成もある。例えば、組織Ｙ用にグループライセンスを発行するシステムＺの認可サーバＸがＴＣＩとして動作し、一方、組織Ｙ内の認可サーバＺがＴＣＳとして動作する。しかしながら、組織Ｙの認可サーバＺがシステムＺによって委託コンプライアンスしていることが証明されると、Ｚは、ＴＣＩとＴＣＳ双方として機能することが許可される。
【０１５８】
上述したように、インストールされると、グループライセンスはＴＣＳに拘束され、権利の状態を初期化して管理することが可能となるようにする。例えば、証明内容はステップ４３３で検証可能であり、整合性値はステップ４３４で再計算可能であり、また、整合性値はステップ４３５で比較可能である。しかしながら、グループライセンスは、共有または使用目的でグループライセンスを処理するデバイスが、グループライセンスの権利の状態を適切に管理可能となるようにＴＣＳと対話可能であるかぎり、いかなるデバイスにも保存することが可能である。
【０１５９】
以下のセクションでは、グループライセンスのインストールとアンインストールをより詳細に説明する。
【０１６０】
グループライセンスのインストール
【０１６１】
インストールプロセスでは、ＴＣＩによって認可を要求し、グループライセンスが現在はインストールされていないことを保証し、また、現在の権利状態を獲得するようにしなければならない。インストールプロセスでは、グループライセンスに対する権利の現在の状態でＴＣＳが初期化される。
【０１６２】
図３５は、次のステップからなるグループライセンスをインストールするプロセスを示す。最初のステップ４４０では、グループライセンスの整合性および信憑性ならびにグループライセンスに対する権利の状態が検証される。グループライセンスの整合性を検証することによってこれが改竄されていないことを保証し、これが信頼すべきソースから発行されたことを保証するグループライセンスの信憑性を検証する。整合性と信憑性を検証する方法は、グループライセンスの表現によって異なる。最も一般的な方法では、デジタル署名を用いてグループライセンスの整合性を保証し、デジタル証明書を用いてグループライセンスの信憑性を保証する。しかしながら、アプリケーションが異なれば、グループライセンスの整合性と信憑性を保証する採用方法も異なる。グループライセンスに対する権利の状態を検証することによって、いずれかの条件の現在状態がこの条件が期限切れであることを示していると判定されると、このグループライセンスはインストール目的で処理されることはない。
【０１６３】
次のステップ４４１では、対象とするＴＣＩからの認可を要求する。このステップでは、対象のＴＣＩとＴＣＳを特定する。ＴＣＩとＴＣＳの双方が一旦特定されたら、インストール要求が構築される。すると、ＴＣＳが認可されて、そのＴＣＳＩＤが検索されて、インストール要求が構築される。図３６に示すように、目標とするＴＣＩによる認可に対する要求は、グループライセンスとＴＣＳのＴＣＳＩＤとからなる。このＴＣＳＩＤを後で用いて、アンインストールに対する要求を認証する。ＴＣＩは、グループライセンスが譲与される組織の外部またはその一部である。ＴＣＩは、要求されたグループライセンスがインストールの要求時にはまだインストールされていないことを検証する。一旦インストール要求が認可されると、グループライセンスに対する現在の権利状態が返却されて、グループライセンスは、アンインストールされるまでは再度インストールすることは不可能である。したがって、インストールすることによって、グループライセンスが複数回インストールされることが効果的に防止される。
【０１６４】
３番目のステップ４４２では、目標のＴＣＳ付きのインストール済みグループライセンスに対する現在の権利状態が初期化される。ＴＣＳは、（グループライセンス中でのように）前もって指定したり、何らかのプロトコルや合意によって獲得することが可能である。ＴＣＳ付きのインストール済みグループライセンスに対する権利の状態を初期化するプロセスによって、ＴＣＳは、グループライセンスに対する権利の状態を、これらの権利が変更される度に追跡することが可能となる。
【０１６５】
４番目のステップ４４３では、インストールされたグループライセンスをライセンスレポジトリに保存する。このライセンスレポジトリは、グループライセンスが拘束されるＴＣＳとは独立しているが、ライセンスレポジトリは一部の構成ではＴＣＳの一部である。
【０１６６】
図３６は、インストール要求を構築して認可するプロセスを示す。最初に、グループライセンスのＴＣＩとＴＣＳの双方がステップ４５０で特定される。この特定が合格すれば、目標となるＴＣＳがステップ４５１で認証される。目標ＴＣＳが認証可能であれば、グループライセンスとインストール要求のＴＣＳＩＤとがステップ４５２で構築される。次に、目標ＴＣＩがステップ４５３で認証される。目標ＴＣＩが認証可能であれば、次のステップ４５４でインストールの認可が要求される。要求が認可されれば、インストール要求は合格である。上記のステップのうちのいずれかが不合格であれば、要求はステップ４５５で不合格となる。
【０１６７】
グループライセンスのアンインストール
【０１６８】
アンインストール動作によって、グループライセンスが目標とするＴＣＩからアンインストールされて、ＴＣＳが、アンインストールされたグループライセンスを追跡することから解放される。グループライセンスは、一旦アンインストールされたら、再インストールされるまで使用不可能である。このアンインストールプロセスは、アンインストール要求を検証するステップと、目標とするＴＣＳからグループライセンスを追跡することを解放するステップと、グループライセンスをＴＣＩからアンインストールするステップからなる。解放要求が合格すれば、ＴＣＳは、アンインストールされたグループライセンスの現在の権利状態付きの認証可能メッセージを返却する。この認証可能メッセージは、次のステップでのアンインストール要求のためにＴＣＩに送られる。加えて、アンインストール要求には、グループライセンスもしくはグループライセンスＩＤおよび、権利の証明済み現在状態を含むＴＣＳによって返却された認証可能メッセージが含まれている。ＴＣＩは、以前にはＴＣＩに保存されていたＴＣＳのＴＣＳＩＤを用いて、ＴＣＳの認証可能メッセージと現在の権利状態とを検証する。要求が合格すれば、ＴＣＩは追跡情報を更新して、グループライセンスが権利の証明済み現在状態によってアンインストールされたことを示す。グループライセンスがＴＣＩで現在インストールされていないまたは認証可能メッセージが検証不可能であれば、アンインストール要求は不合格となる。
【０１６９】
共有コンポーネント
【０１７０】
共有コンポーネントは、認可された主体による共有または使用のために共有ライセンスを作成（導出）して、これら共有ライセンスを統合して、導出されたインストール済みグループライセンスに戻す。
【０１７１】
共有ライセンスを作成して統合するプロセスでは、インストールされたグループライセンスが拘束されるＴＣＳを認可する必要がある。ＴＣＳは、共有コンポーネントが共有要求をグループライセンスに照らし合わせて確認するために必要とするインストール済みグループライセンスの権利の状態を管理する。現在の権利状態が、共有要求が許可されたことを示していれば、共有ライセンスが作成されて、必要であれば委託の証明目的で委託コンポーネントに対して利用可能とされる。次に、グループライセンスの現在の権利状態を更新して、新たに作成された共有ライセンス中の権利の状態と初期状態を反映するようにする。
【０１７２】
共有要求次第で、様々な方法を用いて、上述したように、共有ライセンス中の権利の状態と初期状態とを作成し、また、インストールされたグループライセンスの現在の権利状態を更新する。
【０１７３】
共有ライセンスを返却して発信元であるグループライセンスに統合する場合、共有コンポーネントは統合要求と、この共有ライセンスの返却先であるグループライセンスを確認する。返却が許可されると、共有コンポーネントはこの要求を、グループライセンスが拘束されているＴＣＳに送って、グループライセンスの現在の権利状態を更新する。
【０１７４】
以下のセクションでは、共有ライセンスを導出するプロセスと、共有ライセンスを統合して発信元のインストール済みグループライセンスに戻すプロセスをより詳細に説明する。
【０１７５】
権利の導出
【０１７６】
権利の導出とは、インストールされたグループライセンスから共有ライセンスを作成するプロセスである。共有要求は、権利の被譲与者から直接にまたは共有ライセンスが消費される予定のデバイスから間接的に来る。対象となる消費デバイスが要求時には知られていない場合、要求に起因する共有ライセンスはどの消費デバイスにも拘束されない。この場合、共有ライセンスは、これが消費またはさらなる共有目的で使用可能となる以前に拘束されなければならない。
【０１７７】
図３７は、一般的に共有要求の一部である情報４６０を示す。要求タイプ４６１は、この要求が権利の導出要求または統合要求を示す。導出はサブ権利を作成する要求である。統合はサブ権利を返却する要求である。要求側のデバイスの情報４６２は権利消費デバイスを特定し、このデバイスが要求されているサブ権利を受領することを認可されていることを検証するために用いられる。デバイス情報はオプションである。要求された権利の情報４６３は、グループライセンスから共有されるべき権利を特定する。利用可能ライセンス４６４には、要求を譲与するグループライセンスと、要求を認可し、また、要求を満足させるためにライセンスを発行するために必要な他のライセンスが含まれる。
【０１７８】
共有要求を受信すると、権利消費デバイスは、この要求を満足するライセンスを発生しようとして機能の集合を実行する。このような機能には、要求を対象グループライセンスに照らし合わせて検証する機能、グループライセンスと関連のライセンスとを検証する機能、目標ＴＣＳに対して共有要求と関連するグループライセンスの現在の権利状態を要求する機能、要求を処理する機能および認可されたら共有ライセンスを作成する機能が含まれる。要求が認可されたら、ＴＣＳ中の目標グループライセンスの権利の状態が、発信元のグループライセンス中の現在の権利状態と共有ライセンス中の権利の初期状態とにしたがって更新される。
【０１７９】
図３８は、共有コンポーネントが共有要求を受信することで始まって、共有権利を含むライセンスを出力することで終了する共有要求処理の例示のデータフローを示す。このプロセスは多くのコンポーネントからなるが、これらはサブプロセスとデータベースである。このプロセス全体またはそのコンポーネントのいずれかは、共有コンポーネントが置かれているグループライセンスデバイスに常駐している。
【０１８０】
要求が消費デバイスコンポーネント４７０からグループライセンスデバイス４７１に送られ、ここで、一般的には処理される。グループライセンスデバイス４７１は、共有要求を処理する責任を負っている共有コンポーネントを含む。共有要求を受信すると、グループライセンスデバイスは、目標グループライセンスを、これを要求からまたはレポジトリ４７２から抽出することによって位置付ける。目標のグループライセンスと要求を確認して、その信憑性と整合性をステップ４７３で保証する。目標消費デバイスの識別に関する情報は、要求から抽出されて検証され、消費デバイスがこのような要求をすることを認可されることを保証する。目標消費デバイスは通常は、要求をする第２のデバイスである。
【０１８１】
要求は目標ＴＣＳから現在の権利状態に対して、共有要求はステップ４７４で処理される。この要求が認可されると、権利がステップ４７５で導出されて、この導出権利の状態４７７が状態マネージャ４７６によって更新される。図３９は、権利を導出するプロセスを示す。
【０１８２】
権利の導出には次のステップが含まれる。
要求に適合するグループライセンスと共有可能権利を位置付けするステップ。このステップは、要求を確認するステップと、グループライセンスを位置付けするステップと、共有可能権利を特定するステップと、ライセンスを確認するステップなどを含む、
目標の共有可能権利と関連付けられた状態の集合を特定するステップと、
要求を、目標の共有可能現在の権利状態とオリジナルの状態とに照らし合わせて確認するステップと、
共有権利を作成するステップと、
共有権利を含むライセンスを作成するステップ。このライセンスは、認可されたメンバーが、グループの他のメンバーのために共有権利を作成することを許可する新しいグループライセンスであり得る。
【０１８３】
図３９に示すように、ステップ４８０では、入力されたライセンスからライセンスを獲得し、また、このライセンスが共有要求を適合したことをステップ４８１で確認する。適合しなければ、ステップ４８２で、処理すべきライセンスがまだあるかどうか判定する。処理すべきライセンスがなければ、ステップ４８８で空（ヌル:null）という出力を返却する。ライセンスが要求と適合すれば、次のステップ４８３で、ライセンスから権利を獲得し、ステップ４８４で、この権利が分割可能であるか判定する。可能であれば、ステップ４８５で、この分割可能権利の分割である権利を導出する。次に、分割された権利、または分割不可能権利をステップ４８６で出力ライセンスに挿入する。次に、ステップ４８７で、処理すべき権利がまだあるかどうか判定する。なければ、出力ライセンスはステップ４８８で返却される。
【０１８４】
権利の統合
【０１８５】
権利の統合とは、共有ライセンスを発信元のグループライセンスに戻して統合して、その結果として新たなグループライセンスを作成するプロセスである。この権利統合プロセスは、上に開示した権利導出プロセスと類似している。権利導出と権利統合間との相違は、次の通りである。
権利の統合の場合、目標のグループライセンスに対する権利の状態が、より多くの権利を反映するように更新される。
権利の導出の場合、統合された共有ライセンスは無効となる。
導出が正しく行われた場合、新しい共有ライセンスが作成される。
【０１８６】
消費コンポーネント
【０１８７】
消費コンポーネントは消費ライセンスを消費する。上記に開示したように、消費ライセンスはまた共有ライセンスでもある。しかしながら、消費ライセンスは、共有目的ではなくて使用目的のものである。消費ライセンスを消費するには認可が必要であり、このような認可は、あらゆるＤＲＭシステムで指定される既知のプロセスである。認可プロセスは、ライセンスに照らし合わせて要求を確認するステップと、ユーザとデバイスを認証するステップと、要求を条件の現在状態に照らし合わせて検証するステップと、使用認可された場合に条件の現在状態を更新するステップなどを含む。
【０１８８】
消費ライセンスは、期限切れになるまでまたは消費デバイスによって解放されるまで消費デバイスによって消費される。消費ライセンスは、一旦解放されれば、共有コンポーネントに送って、その導出元であるグループライセンスに戻して統合することが可能である。
【特許請求の範囲】
【請求項１】
計算環境内でリソースの使用を制御するために譲与者から被譲与者に譲与される共有可能権利からサブ権利を導出することを可能とすることによって権利共有をサポートする方法であって、
前記計算環境は、権利に従ってリソースの使用を制御するために該計算環境内で権利を執行するメカニズムを有し、
前記譲与される権利は、該権利の態様を指定する少なくとも一つのコンポーネントを含み、
前記方法が、
権利共有を制御する計算装置が、使用制御のためのサブ権利の要求を受信し、
該サブ権利は当該サブ権利の形態を指定する少なくとも一つのコンポーネントを含み、
前記計算装置が、前記サブ権利の前記少なくとも一つのコンポーネントを前記譲与された権利の対応している少なくとも一つのコンポーネントから導出することが可能であることを確認し、
前記計算装置が、前記確認ステップによりサブ権利のコンポーネントを譲与された権利の対応するコンポーネントから導出することが可能であることを確認された場合、前記計算環境内での前記リソースの使用制御のための、前記サブ権利からなる消費ライセンスを作成する、
ことを含む方法であって、
前記サブ権利は、前記被譲与者に対し前記リソースの使用制御を許可する権利であるとともに、被譲与者のニーズに従って、更なるサブ権利を導出可能な共有可能権利であり、
前記少なくとも一つのコンポーネントにより指定される前記権利の形態は、リソース、前記権利被譲与者に該当するところの前記リソースを使用する主体、該主体が前記リソースに対して実行することを許可される動作、および前記主体が前記リソースに対して許可される前記動作を実行するための実行条件のうちの少なくとも一つであり、
前記確認ステップによる前記確認は、
（ａ）前記サブ権利の少なくとも一つのコンポーネントが、前記譲与された権利の対応する少なくとも一つのコンポーネントと同じか、もしくは等価である；
（ｂ）前記譲与された権利の対応する少なくとも一つのコンポーネントが集合体を表す場合、前記サブ権利の少なくとも一つのコンポーネントが、該譲与された権利の少なくとも一つのコンポーネントの集合体の一部である；並びに
（ｃ）前記譲与された権利の対応する少なくとも一つのコンポーネントが前記実行条件である場合、前記サブ権利の少なくとも一つのコンポーネントの実行条件が、前記譲与された権利の少なくとも一つのコンポーネントの実行条件で許容される範囲内のものである、
の少なくともいずれかを検証することで達成される、
方法。
【請求項２】
計算環境内でリソースの使用を制御するために譲与者から被譲与者に譲与される共有可能権利からサブ権利を導出することを可能とすることによって権利共有をサポートするシステムであって、
前記計算環境は、権利に従ってリソースの使用を制御するために該計算環境内で権利を執行するメカニズムを有し、
前記譲与される権利は、該権利の態様を指定する少なくとも一つのコンポーネントを含み、
前記システムが、権利共有を制御する計算装置を含み、
該計算装置が、
使用制御のためのサブ権利の要求を受信する受信モジュールであって、該サブ権利は当該サブ権利の形態を指定する少なくとも一つのコンポーネントを含むものである、受信モジュールと、
前記サブ権利の前記少なくとも一つのコンポーネントが前記譲与された権利の対応している少なくとも一つのコンポーネントから導出可能であることを確認する確認モジュールと、
前記確認モジュールによりサブ権利のコンポーネントを譲与された権利の対応するコンポーネントから導出することが可能であることを確認された場合、前記計算環境内での前記リソースの制御使用のための、前記サブ権利からなる消費ライセンスを作成する作成モジュールを、
実行するシステムであって、
前記サブ権利は、前記被譲与者に対し前記リソースの使用制御を許可する権利であるとともに、被譲与者のニーズに従って、更なるサブ権利を導出可能な共有可能権利であり、
前記少なくとも一つのコンポーネントにより指定される前記権利の形態は、リソース、前記権利被譲与者に該当するところの前記リソースを使用する主体、該主体が前記リソースに対して実行することを許可される動作、および前記主体が前記リソースに対して許可される前記動作を実行するための実行条件のうちの少なくとも一つであり、
前記確認モジュールによる前記確認は、
（ａ）前記サブ権利の少なくとも一つのコンポーネントが、前記譲与された権利の対応する少なくとも一つのコンポーネントと同じか、もしくは等価である；
（ｂ）前記譲与された権利の対応する少なくとも一つのコンポーネントが集合体を表す場合、前記サブ権利の少なくとも一つのコンポーネントが、該譲与された権利のコンポーネントの集合体の一部である； 並びに
（ｃ）前記譲与された権利の対応する少なくとも一つのコンポーネントが前記実行条件である場合、前記サブ権利の少なくとも一つのコンポーネントの実行条件が、前記譲与された権利の少なくとも一つのコンポーネントの実行条件で許容される範囲内のものである、
の少なくともいずれかを検証することで達成される、
システム。
【請求項１】
計算環境内でリソースの使用を制御するために譲与者から被譲与者に譲与される共有可能権利からサブ権利を導出することを可能とすることによって権利共有をサポートする方法であって、
前記計算環境は、権利に従ってリソースの使用を制御するために該計算環境内で権利を執行するメカニズムを有し、
前記譲与される権利は、該権利の態様を指定する少なくとも一つのコンポーネントを含み、
前記方法が、
権利共有を制御する計算装置が、使用制御のためのサブ権利の要求を受信し、
該サブ権利は当該サブ権利の形態を指定する少なくとも一つのコンポーネントを含み、
前記計算装置が、前記サブ権利の前記少なくとも一つのコンポーネントを前記譲与された権利の対応している少なくとも一つのコンポーネントから導出することが可能であることを確認し、
前記計算装置が、前記確認ステップによりサブ権利のコンポーネントを譲与された権利の対応するコンポーネントから導出することが可能であることを確認された場合、前記計算環境内での前記リソースの使用制御のための、前記サブ権利からなる消費ライセンスを作成する、
ことを含む方法であって、
前記サブ権利は、前記被譲与者に対し前記リソースの使用制御を許可する権利であるとともに、被譲与者のニーズに従って、更なるサブ権利を導出可能な共有可能権利であり、
前記少なくとも一つのコンポーネントにより指定される前記権利の形態は、リソース、前記権利被譲与者に該当するところの前記リソースを使用する主体、該主体が前記リソースに対して実行することを許可される動作、および前記主体が前記リソースに対して許可される前記動作を実行するための実行条件のうちの少なくとも一つであり、
前記確認ステップによる前記確認は、
（ａ）前記サブ権利の少なくとも一つのコンポーネントが、前記譲与された権利の対応する少なくとも一つのコンポーネントと同じか、もしくは等価である；
（ｂ）前記譲与された権利の対応する少なくとも一つのコンポーネントが集合体を表す場合、前記サブ権利の少なくとも一つのコンポーネントが、該譲与された権利の少なくとも一つのコンポーネントの集合体の一部である；並びに
（ｃ）前記譲与された権利の対応する少なくとも一つのコンポーネントが前記実行条件である場合、前記サブ権利の少なくとも一つのコンポーネントの実行条件が、前記譲与された権利の少なくとも一つのコンポーネントの実行条件で許容される範囲内のものである、
の少なくともいずれかを検証することで達成される、
方法。
【請求項２】
計算環境内でリソースの使用を制御するために譲与者から被譲与者に譲与される共有可能権利からサブ権利を導出することを可能とすることによって権利共有をサポートするシステムであって、
前記計算環境は、権利に従ってリソースの使用を制御するために該計算環境内で権利を執行するメカニズムを有し、
前記譲与される権利は、該権利の態様を指定する少なくとも一つのコンポーネントを含み、
前記システムが、権利共有を制御する計算装置を含み、
該計算装置が、
使用制御のためのサブ権利の要求を受信する受信モジュールであって、該サブ権利は当該サブ権利の形態を指定する少なくとも一つのコンポーネントを含むものである、受信モジュールと、
前記サブ権利の前記少なくとも一つのコンポーネントが前記譲与された権利の対応している少なくとも一つのコンポーネントから導出可能であることを確認する確認モジュールと、
前記確認モジュールによりサブ権利のコンポーネントを譲与された権利の対応するコンポーネントから導出することが可能であることを確認された場合、前記計算環境内での前記リソースの制御使用のための、前記サブ権利からなる消費ライセンスを作成する作成モジュールを、
実行するシステムであって、
前記サブ権利は、前記被譲与者に対し前記リソースの使用制御を許可する権利であるとともに、被譲与者のニーズに従って、更なるサブ権利を導出可能な共有可能権利であり、
前記少なくとも一つのコンポーネントにより指定される前記権利の形態は、リソース、前記権利被譲与者に該当するところの前記リソースを使用する主体、該主体が前記リソースに対して実行することを許可される動作、および前記主体が前記リソースに対して許可される前記動作を実行するための実行条件のうちの少なくとも一つであり、
前記確認モジュールによる前記確認は、
（ａ）前記サブ権利の少なくとも一つのコンポーネントが、前記譲与された権利の対応する少なくとも一つのコンポーネントと同じか、もしくは等価である；
（ｂ）前記譲与された権利の対応する少なくとも一つのコンポーネントが集合体を表す場合、前記サブ権利の少なくとも一つのコンポーネントが、該譲与された権利のコンポーネントの集合体の一部である； 並びに
（ｃ）前記譲与された権利の対応する少なくとも一つのコンポーネントが前記実行条件である場合、前記サブ権利の少なくとも一つのコンポーネントの実行条件が、前記譲与された権利の少なくとも一つのコンポーネントの実行条件で許容される範囲内のものである、
の少なくともいずれかを検証することで達成される、
システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【公開番号】特開２０１２−２５６３７３（Ｐ２０１２−２５６３７３Ａ）
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願番号】特願２０１２−２０７７２８（Ｐ２０１２−２０７７２８）
【出願日】平成２４年９月２１日（２０１２．９．２１）
【分割の表示】特願２００８−５３７７２６（Ｐ２００８−５３７７２６）の分割
【原出願日】平成１８年１０月４日（２００６．１０．４）
【出願人】（５００４７０７０３）コンテントガード ホールディングズ インコーポレイテッド (54)
【氏名又は名称原語表記】ＣｏｎｔｅｎｔＧｕａｒｄ Ｈｏｌｄｉｎｇｓ， Ｉｎｃ．
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願日】平成２４年９月２１日（２０１２．９．２１）
【分割の表示】特願２００８−５３７７２６（Ｐ２００８−５３７７２６）の分割
【原出願日】平成１８年１０月４日（２００６．１０．４）
【出願人】（５００４７０７０３）コンテントガード ホールディングズ インコーポレイテッド (54)
【氏名又は名称原語表記】ＣｏｎｔｅｎｔＧｕａｒｄ Ｈｏｌｄｉｎｇｓ， Ｉｎｃ．
[ Back to top ]