ライセンスデバイス
【課題】ユーザが、ユーザ自身の必要性にしたがって権利を共有することを可能とする権利共有をサポートする。
【解決手段】消費デバイスによる共有リソースの使用を譲与するサブ権利を指定する消費ライセンスを発行するライセンスデバイス。共有リソースの使用のためのサブ権利の要求であって、サブ権利に基づいて共有リソースに対し要求されている使用を管理するDRMコンポーネントを備える消費デバイスを特定するデバイス情報を含む要求を、前記消費デバイスから受信し、受信される要求を、ライセンス内で指定されている少なくとも一つの使用権に照らし合わせて確認し、デバイス情報により特定されている消費デバイスが、要求されているサブ権利を受領することが認可されていることを検証し、該検証に基づいてサブ権利を指定する消費ライセンスを作成する。
【解決手段】消費デバイスによる共有リソースの使用を譲与するサブ権利を指定する消費ライセンスを発行するライセンスデバイス。共有リソースの使用のためのサブ権利の要求であって、サブ権利に基づいて共有リソースに対し要求されている使用を管理するDRMコンポーネントを備える消費デバイスを特定するデバイス情報を含む要求を、前記消費デバイスから受信し、受信される要求を、ライセンス内で指定されている少なくとも一つの使用権に照らし合わせて確認し、デバイス情報により特定されている消費デバイスが、要求されているサブ権利を受領することが認可されていることを検証し、該検証に基づいてサブ権利を指定する消費ライセンスを作成する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、DRM(デジタル権利管理)の分野およびデジタルリソース管理に関し、詳しくは、権利およびリソースの分配および共有に関する。
【背景技術】
【0002】
現在の最新のDRMシステムでは、人間であったりデバイスやサービスなどの人間以外のエンティティであったりする潜在的ユーザの集合で権利を共有する機能は、市販のプロダクツで利用可能である。譲与された権利の集合とこれらの権利を共有する方法は一般的にはライセンスという形態で指定される。
【0003】
権利の共有専用のライセンスの1つの形態は、並列ユーザライセンス(サイトライセンスまたはネットワークライセンスとしても知られている)と呼ばれる。並列ユーザライセンスは、ネットワークサーバに拘束されているライセンスのプールを表し、このネットワーク上のユーザだけがこのライセンスにアクセスすることが可能であり、これに同時にアクセス可能なユーザの数は限られる。
【0004】
並列ユーザライセンスの従来型の実施例では、ライセンスにアクセス可能なユーザ各々に、このライセンスに指定されているすべての権利が譲与されている、すなわち、ユーザすべてが同じ権利を有する。Macrovision FLEXnetによるこのタイプのライセンスのより進歩した実施例では、並列ユーザライセンスのユーザは、権利の集合を動的に共有することが許可される。このライセンスは、ユーザ各々が有することが可能な権利の集合を指定する代わりに、すべてのユーザが共有することが可能な権利の最大集合を指定する。これらの権利をどのように共有するかは、ライセンスの購入者次第であり、したがって、オプションファイルとソフトウエアプラグインモジュールとからなるカスタムアクセス制御メカニズムを用いて構成することが可能である。このオプションファイルを用いると、特に、特定の一人もしくは複数のユーザのためのライセンスプールで利用可能な多くのライセンスの予約、ユーザもしくはユーザグループがアクセス可能なある特定の特徴的機能の予約およびオフラインで使用する目的でこのプールからあるライセンスを誰が借用することが可能であるかの規定を制御することが可能である。このオプションファイルによってサポートされる特徴的機能の一部を解説すると、「RESERVE1インストールUSERロバート」は「ロバート」というユーザに対して「インストール」という特徴的機能の1つのライセンスを予約し、「RESERVE4プレイGROUPアカウンティング」は、アカウンティンググループがコンテンツをプレイするためのライセンスを予約し、「INCLUDE_BORROWプレイUSERトム」は、特徴的機能「プレイ」を借用することが可能なユーザのリストに「トム」というユーザを含む。共有することに加えて、オプションファイルには、使用を報告するオプションが含まれている。これは、事実上、ライセンスが、使用を追跡するという条件をユーザに課す方法である。あるユーザがコンテンツにアクセス可能であるかどうかを判定する認可プロセスでは、オプションファイルをプラグインが処理して合成応答を発生している間に、このライセンスを一般的ライセンスマネージャが処理する。
【0005】
Macrovision FLEXnetの方式では、ユーザには、自分の必要にしたがって権利の共有を制御する特別のメカニズムが提供されるが、それには限度があることは否定できない。例えば、そのライセンスはネットワークサーバに拘束され、このネットワーク上のユーザだけがこのライセンスにアクセスまたはこれを借用することが可能である。また、オプションファイルは人間によって構成され、エラーが発生しやすい。例えば、アドミニストレータは、ある部門内の様々なグループに対してライセンスを予約している場合に、予約されたライセンスの数がプールのキャパシティを超えるようなミスを犯すことがあり得る。このミスが気付かれないままとなって、あるグループが、結局予測していたより少ないライセンスしか共有できないことになるという結果になりかねない。オプションファイル(および、それゆえの共有分配)は明瞭なテキストファイルである。これはアドミニストレータのパスワードでしか保護されていないものである。ライセンスサーバは、ライセンスに対して実施するのと同じ権利管理タスクを実行することは不可能であるが、このタスクとは、信憑性とオプションの整合性とを検証することである。加えて、ライセンスよりもオプションファイルに基づいてアクセスを制御するため、コンテンツの携帯性が制限されるが、これは、上述のアクセス制御メカニズムが存在しないと、コンテンツにアクセスすることが不可能であるためである。コンテンツがペリメータ(ネットワークサーバのドメイン)から離れると、意図したアクセス制御はもはや当てはまらない。
【0006】
使用を報告するというハードコーディングされたオプションは、ライセンスの購入者がライセンスのユーザに対して課すことを希望することが考えられる条件のうちの1つに過ぎない。ライセンスの購入者は、自分自身の条件を分配された権利に追加することが可能であるべきである。カスタムアクセス制御メカニズムは、委譲の1レベルをサポートするだけである。アドミニストレータだけが、これ以上自分の権利を分配することが不可能なネットワークユーザに対して権利を分配することが可能である。この委譲は、マルチレベルの委譲を必要とする階層構造には適していない。共有は、アクセス態様またはある行動の制御に焦点が合わされる。これは、規則やポリシーによって管理される汎用のリソース共有メカニズムではない。その設計は、ソフトウエアプログラムの動作を制御することにその重点がある。文書、オーディオファイル、ビデオファイルなどの他のタイプのデジタルリソースの制御を意図するものではない。
【0007】
個人的ドメイン内での共有を可能とする別の形態のライセンスは、典型的にはエンドユーザライセンスと呼ばれるものである。このタイプのライセンスでは、ライセンス自体が、デバイスIDやユーザIDなどの特定の環境に拘束されていることが必要である。共有は、権利の所有者によってサポートされているビジネスモデルによって、特定の集合のデバイスタイプおよび/または最大数のデバイス内での共有に限られる。すべての共有デバイスが同じ権利を有するかまたは、各々のデバイスがそれ自体の別個の集合の権利を有するかのどちらかである。
【0008】
エンドユーザライセンスの1つの例では、マイクロソフトのWindows(登録商標)のメディア権利管理システム(Microsoft Windows(登録商標) Media Rights Management System)は、自分のパソコン上でコンテンツをプレイして他のデバイスにコンテンツを転送する権利を含む権利集合を、コンテンツの購入者に対して譲与してよい。このような転送権利には、このコンテンツを受信する資格があるデバイスのタイプと、このようなデバイスに対するいくつかの所定の権利とが指定される。転送された結果、さらに、パソコン上のライセンスにしたがって、対象デバイスは各々が、それ自体の別個の権利集合を有することになる。
【0009】
別の例では、リアルネットワークへリックスDRM(Real Networks Helix DRM)は、パソコン、セットトップボックス、ホームメディアサーバ、携帯電話などのあらゆるネットワーク接続されたデバイス(ネイティブデバイス(Native Device)と呼ばれる)に対して、自分自身のコンテンツとライセンスを獲得する能力を提案する。へリックスデバイスDRMは、ネイティブデバイスから、データの転送とこのデータに対するビジネス規則の執行とを目的としてネイティブデバイスに対する接続を必要としているデバイスであるセキュア受信機デバイスへの転送をサポートする。セキュア受信機デバイスの例には、専用音楽プレイヤや専用ビデオプレイヤが含まれる。セキュア受信機デバイス上で利用可能なのは再生権利だけである。
【0010】
さらに別の例では、FLEXnetのノードロックライセンスを特定のデバイスに拘束しておいて、このデバイスのみ上でこのライセンスを消費させるようにすることが可能であったり、または、特定のユーザ名に拘束しておいて、このライセンスを消費するデバイスが同じユーザ名を有していなければならないようにすることが可能である。この2つの要件のうち、前者は共有を許可しないのに対して、後者は同じユーザ名を有するデバイス間での共有を許可しているが、デバイスは名前で区別するのが好ましいため、これはあまり実用的ではない。
【0011】
さらに別の例では、FLEXnetモバイルライセンスはFLEXnet IDに拘束される。FLEXnet IDを含むハードウエア(ドングル)は、認可されたユーザがライセンスを新しいデバイス上で消費することを決定すれば、この新しいデバイスに移動させなければならない。
【0012】
したがって、エンドユーザライセンスによって許可された共有方式では、ユーザが、獲得した権利を、自分が適していると見なす何らかの方法で用いることが可能な最大限の権利として用いることは許可されない。
【発明の概要】
【発明が解決しようとする課題】
【0013】
このため、ユーザが、自分達の必要性にしたがって権利を共有することを可能とする動的権利共有をサポートするシステムに対する必要性が存在する。このシステムでは、獲得されたライセンスは権利のプールを表しているが、ここで、各々の権利をさらにサブ権利に分割することが可能である。サブ権利とは、権利を分配する単位である。
【課題を解決するための手段】
【0014】
本発明は、権利からサブ権利を導出する方法に関するが、この権利は複数のコンポーネントを含み、これらコンポーネントはその各々が、権利の態様を指定している。本方法は一般的に、サブ権利を受信するステップであって、前記サブ権利が前記コンポーネントのうちの少なくとも1つを含み、前記コンポーネントの各々が前記サブ権利の態様を指定するステップと、前記サブ権利の前記コンポーネントの値が前記権利のうちの対応しているコンポーネントの値から導出することが可能であることを確認するステップと、を含む。コンポーネントは、例えば、主役、動作、リソースおよび条件であってよい。
【0015】
本発明はまた、第1の権利を第2の権利と統合する方法に関する。この場合、本方法は、前記第1の権利のコンポーネントの各々がこれに対応する前記第2の権利のコンポーネントから導出することが可能であることを検証することによって、前記第1の権利が前記第2の権利から導出可能であることを判定するステップと、前記第1の権利を前記第2の権利のうちの前記対応するコンポーネントと合成するステップを含む。
【0016】
さらに、本発明は権利を共有する方法に関する。本方法は、権利からサブ権利を導出し、前記サブ権利の使用を許可し、前記サブ権利を前記権利と統合するステップを含む。その結果、サブ権利は、共有目的でさらに導出することが可能である。加えて、権利はライセンス中に指定されることがあり、本方法はさらに、デバイス上で前記ライセンスをインストールするステップと、前記ライセンスをアンインストールするステップと、これらのライセンスを他のインストール動作に利用可能とするステップを含むことができる。
【0017】
加えて、本発明は、権利からサブ権利を導出することを可能とすることによって権利共有をサポートするシステムに関するが、この権利は複数のコンポーネントを含み、このコンポーネント各々がこの権利の態様を指定し、前記システムは、サブ権利を受信するための受信モジュールであって、前記サブ権利が、各々が前記サブ権利の態様を指定する複数のコンポーネントを含む受信モジュールと、前記サブ権利の前記コンポーネントの値が前記権利のうちの対応するコンポーネントの値から導出可能であることを確認するための確認モジュールを備える。本システムはさらに、グループライセンスをデバイス上にインストールし、これを共有目的に対して利用可能とし、インストールされたグループライセンスをアンインストールし、これを現在のデバイス上での共有目的に対しては利用不可能とするためのインストールモジュールと、前記インストールされた/アンインストールされたグループライセンスを追跡するインストール追跡モジュールと、グループライセンスの権利の状態を追跡する追跡モジュールと、共有モジュールを備える。
【0018】
本発明はさらに、譲与者から被譲与者に譲与された権利のプールからサブ権利を導出し、これによって、計算環境内でのリソースの使用を制御する方法に関するが、この計算環境は、この権利にしたがってリソースの使用を制御するためにこの環境内で権利を執行するメカニズムを有し、前記方法は、被譲与者が譲与者から権利のプールを受信し、前記権利のプールが少なくとも1つのリソースと関連付けられ、前記被譲与者が前記権利のプールを1つ以上の権利コンポーネントに解析し、前記権利コンポーネントの各々が前記権利プールの態様を指定し、前記権利コンポーネントのうちの少なくとも1つからサブ権利コンポーネントを導出し、前記サブ権利コンポーネントが対応する権利コンポーネントの部分集合であり、前記サブ権利コンポーネントからサブ権利を指定するライセンスを作成することを含み、前記ライセンスが、前記サブ権利に従って、また、前記権利のプールの範囲内で前記リソースの使用を制御するために前記計算環境によって執行することが可能である。本方法はさらに、前記ライセンスをサブ被譲与者に譲与するステップと、前記サブ被譲与者によって前記ライセンス中の前記権利を権利のサブプールとして1つ以上の第2の権利コンポーネントに解析するステップであり、前記第2の権利コンポーネントの各々が前記権利のサブプールの態様を指定するステップと、前記第2の権利コンポーネントのうちの少なくとも1つから第2のサブ権利コンポーネントを導出するステップであり、前記第2のサブ権利コンポーネントが対応する第2の権利コンポーネントの部分集合であるステップと、前記第2のサブ権利コンポーネントからサブサブ権利を指定するサブライセンスを作成するステップであり、前記サブライセンスが、前記サブサブ権利に従って、および前記権利のサブプールの範囲内で前記リソースの使用を制御するために前記計算環境によって執行することが可能であるステップを含む。
【0019】
サブ権利について開示されている概念を解説するために、電子書籍(本)を5回プレイする権利を検討する。この権利のサブ権利とは、電子書籍をn回プレイする権利(ここで、0<n<5)であり得る。プールのキャパシティ以内で共有される限りでは、このシステムは、ユーザが、獲得した権利を自由に分割して分配することを許可するが、これは、権利が同じネットワーク上のユーザに分配されるか互いに別々のネットワーク上のユーザに分配されるか、前記分配された権利が受信者によって消費されるか、または、他の認可済みのエンティティにさらに分配されるかとは無関係である。本システムは、権利をサブ権利に分割して、サブ権利の残余の部分を統合して、他者が使用するようにプールに戻す方法などの、権利のプールを維持するメカニズムを提供する。
【図面の簡単な説明】
【0020】
【図1】譲与された権利のデータモデルと擬似表現言語との間のマッピングを示す。
【図2】擬似表現言語における無条件権利を示す。
【図3】プレイの回数に対する条件が付いた譲与権利を示す。
【図4】時間条件付きの譲与権利を示す。
【図5】2つ以上の条件が付いた譲与権利を示す。
【図6】図2に示す譲与権利をMPEG−RELで表現したものを示す。
【図7】図3に示す譲与権利をMPEG−RELで表現したものを示す。
【図8】図4に示す譲与権利をMPEG−RELで表現したものを示す。
【図9】図5に示す譲与権利をMPEG−RELで表現したものを示す。
【図10】主体に基づいて、図4に示す譲与権利から導出された権利を示す。
【図11】主体および条件に基づいて、図4に示す譲与権利から導出された権利を示す。
【図12】指定された主体に基づいて譲与権利から権利を導出するプロセスを示す。
【図13】条件に基づいて譲与権利から権利を導出するプロセスを示す。
【図14】新しい権利が分割可能権利から導出されるシナリオを示す。
【図15】新しい権利が無条件並列権利から導出されるシナリオを示す。
【図16】新しい権利が条件付き並列権利から導出されるシナリオを示す。
【図17】新しい権利が共有可能権利から導出されるシナリオを示す。
【図18】グループライセンスを示す。
【図19】新しいグループライセンスがグループライセンスから導出されるシナリオを示す。
【図20】第2世代グループライセンスを導出するプロセスを示す。
【図21】権利がグループライセンスに返却されるシナリオを示す。
【図22】図18に示すグループライセンスをMPEG RELで表現したものを示す。
【図23】図19に示すグループライセンスをMPEG−RELで表現したものを示す。
【図24】グループライセンスの導出階層を示す。
【図25】一般的なDRMシステムを示す。
【図26】動的な共有権利をサポートする基本的なコンポーネントを示す。
【図27】共有権利をサポートする基本的コンポーネントの1つの可能性のある構成を示す。
【図28】共有権利をサポートする基本的コンポーネントの1つの可能性のある構成を示す。
【図29】共有権利をサポートする基本的コンポーネントの1つの可能性のある構成を示す。
【図30】企業アプリケーション用の基本的コンポーネントの1つの可能性のある構成を示す。
【図31】グループライセンスをインストールするプロセスを示す。
【図32】情報を追跡する好ましい構造を示す。
【図33】グループライセンスをアンインストールするプロセスを示す。
【図34】権利の状態を証明して検証するプロセスを示す。
【図35】グループライセンスをインストールするプロセスを示す。
【図36】インストール要求を構築して認可するプロセスを示す。
【図37】一般的に共有要求の一部である情報を示す。
【図38】共有要求を処理する例示のデータフローを示す。
【図39】権利を導出するプロセスを示す。
【発明を実施するための形態】
【0021】
定義
【0022】
権利とは、指定された状況または条件の集合の下で、一般的にはリソースに対して権利の被譲与者が動作または活動を実行するステートメントを表す。
【0023】
権利表記(rights expression)とは、権利をデジタル形態で明示したものである。権利表記の例としては、これに限られないが、ISO MPEG REL、XrML、SAML、XACML、ODRL、OMA RELなどのXMLベースの権利表記言語や、データ構造や、ビットフィールドがある。
【0024】
ライセンスとは、権利表記を用いて捕獲された規則の表現である。ライセンスは、譲与された権利の完全な文脈を伝えている。ライセンス中で捕獲されている情報には、権利の譲与者、権利の被譲与者、リソース、許可ならびに関連する条項および条件が含まれている。
【0025】
リソースとは、アクセス、使用、操作および/または分配が規則またはポリシーの集合によって管理され統御されるようなあらゆるコンテンツ、サービス、さらに権利さえも表すものである。
【0026】
本開示に定義される動的な権利共有によって、権利の譲与者の決定権に対抗する権利の被譲与者の決定権において共有する能力が可能とされる。権利の譲与者は、権利の限度を指定する。この限度を示す条件内で、権利の被譲与者は、特定の権利共有メカニズムを決定することが可能である。権利の被譲与者はまた、多段階権利譲与連鎖においては譲与者でもあり得る。
【0027】
権利の共有とは、譲与された権利をサブ権利に分割することを含む。次に、サブ権利がサブ被譲与者の集合に発行される。帰納的に、各々の被譲与者またはサブ譲与者はさらに、譲与連鎖を下るにつれて、他のサブ被譲与者とサブ権利を共有することが可能である。例えば、中心ライブラリXは、ある本30冊に対する権利を購入する。次に、ライブラリXはこの30冊のうちの10冊を自分の姉妹ライブラリYに分配する。したがって、ライブラリXは、権利の譲与者として動作して、10冊に対するサブ権利をライブラリYに発行する。ライブラリXから10冊を受領すると、ライブラリYはさらに、このうちの3冊をそのローカルライブラリZのうちの1つと共有する。
【0028】
本発明の第1の態様は、権利をサブ権利に導出して、サブ権利を、これらの導出元であるオリジナルの権利に統合して戻す方法である。本発明全体を通じて、サブ権利は導出された権利とも呼ばれる。権利の導出と統合は、権利を権利の被譲与者間で共有する基本的メカニズムとして働く。権利の被譲与者は、新しいサブ権利を導出することによって自分の権利を他者と共有する。その結果、新しいサブ権利の被譲与者は各々が、サブ権利を消費したり他者とさらに共有したりすることが可能となる。
【0029】
本発明の第2の態様はグループライセンスであり、これは、一人以上の権利被譲与者の集合に対して最大限の権利を譲与して、これらの権利をこれら被譲与者間で動的に共有することを許可するシステム内で用いられる。グループライセンスの共有メカニズムは、サブ権利を導出して、これらサブ権利を含む共有ライセンスを発行する能力に基づいている。共有ライセンスとは、自分自身が、さらに共有可能なグループライセンスであり得る。したがって、グループライセンスは動的で多段階の権利共有をサポートする。
【0030】
本発明の第3の態様は、権利被譲与者のグループ間で、および権利被譲与者のグループ全体にわたって権利を共有し、また、多段階に権利を共有することをサポートするためのグループライセンスを実施するシステムである。この開示されるシステムは、権利の消費を認可して、権利の使用と状態を追跡することが可能ないかなるDRMシステム中でも実施することが可能である。
【0031】
本発明は第1に、所与の権利からサブ権利を導出する方法を開示する。この方法は、サブ権利が、これらサブ権利の導出元であるオリジナルの権利の限度内であることを保証する。本方法は、動的権利共有システム中で権利の分割目的で用いることが可能である。
【0032】
各々のサブ権利は、次の一人の(または複数の)権利被譲与者に対して、このサブ権利の導出元である権利の一部分または全体を譲与する。その結果、各々のサブ権利の消費が、このサブ権利の導出元の権利とも、また、他のサブ権利とも無関係に認可される。したがって、サブ権利を導出する能力は、動的権利共有のための基本的メカニズムである。
【0033】
本発明はまた、グループライセンスと呼ばれる新しい概念を提示する。グループライセンスとは、一人以上の被譲与者に対して最大限の権利を譲与して、これら被譲与者による共有がこのグループライセンスによって許可された場合に、これらの被譲与者が、これら譲与された権利をこのような共有のポリシーにしたがって共有することを許可するライセンスのことである。このような共有がグループライセンスによって許可される場合には、共有するメンバーをこれら被譲与者以外にも拡大して、他の認可済みのユーザを含むようにしてもよい。
【0034】
グループライセンスのセマンティックスでは、サブ権利の指定を導出する開示の方法が採用される。グループライセンスシステムは、サブ権利をライセンス発行認可プロセスの一部として導出し得る。グループライセンスシステムは、サブ権利が発行の時点でライセンスの限度内にある場合にだけ、これらサブ権利を含むライセンスの発行を認可する。この発行されたライセンスを被譲与者が用いたり、またはさらに分割したりして、グループライセンスを含むようにすることが可能である。加えて、グループライセンスのセマンティックスは、サブ権利の未使用の部分を統合して、サブ権利の導出元である権利に戻すことをサポートしている。
【0035】
本発明はまた、権利の被譲与者間での動的な共有目的でグループライセンスを処理する例示のシステムを提示する。本システムはまた、未使用の共有権利を再統合してグループライセンスに戻す能力を有する。本開示のシステムは、様々な構成で設計して、権利の認可と追跡をサポートするDRMシステムに統合することが可能な基本的コンポーネントの集合を含む。この好ましい例示のシステムに加えて、開示の概念を組み込んだ他の実施例を設計することが可能である。
【0036】
共有のための権利を導出する方法
【0037】
現行の権利共有メカニズムは、特定の用途向けに具体的に実現されるか、中心的認可によって共有を制御することを必要とするか、特定の環境内で共有することを必要とするかのいずれかである。このような共有方式では、権利の被譲与者が自身の権利を共有する機能が制限される。本発明は、権利の導出に基づいた新しい共有方法を開示する。本開示方法によって、権利を権利の被譲与者間で動的に共有することが可能となり、また、共有された権利をさらに他の権利被譲与者と共有することが可能となる。本開示方法は汎用性があり、権利とリソースを共有することを必要とするいかなるシステムにも適用可能である。
【0038】
本発明は、最初に、権利の既存の実施例にマッピングすることが可能な権利の一般的なデータモデルを導入する。次に、本発明は、譲与された権利からサブ権利を導出して、サブ権利を統合してオリジナルの譲与された権利に戻す方法を開示する。権利を導出する方法と共に、本発明はまた、本開示の方法をどのように現行の共有方式に応用してその限界の一部に対処するかを記述する。
【0039】
権利のデータモデル
【0040】
権利の一般的なデータモデルuは次のように表される。
u=(p,a,r,c)
ここで、
pは、動作aが譲与される対象である主体、主体の集合または匿名の主体である。したがって、pは一人以上の権利の被譲与者である。
aは、pが実行することを許可された動作または活動であり、
rは、動作aと関連付けられたリソースであり、
c={ci|i=0..n}は、pがrに対してaを実行する指定された状況を構成する条件の集合である。ciはuと関連付けられた条項および条件と呼ばれる。
【0041】
u中に指定されているp、a、rおよびciはその各々が、譲与された権利uのコンポーネントと呼ばれる。解説目的で、この一般的データモデルは、次の擬似表現言語にマッピング可能とされる。
GRANTED RIGHTS(譲与された権利)
PRINCIPAL p(主体p)
ACTION a(動作a)
RESOURCE r(リソースr)
CONDITIONS c(条件c)
【0042】
図1に、権利u(100)のデータモデルと上記の擬似表現言語101との間のマッピングを示すが、ここで、譲与された権利uは表現「GRANTED RIGHTS(譲与された権利)」にマッピングされ、主体pは表現「PRINCIPAL p(主体p)」にマッピングされ、動作aは表現「RIGHTS a(権利a)」にマッピングされ、リソースrは表現「RESOURCE r(リソースr)」にマッピングされ、条件cは表現「CONDITIONS c(条件c)」にマッピングされている。
【0043】
この権利のデータモデルはまた、一般目的用のリソース共有にも適している。aを「使用する」や「所有する」などの一般的動作として定義すると、本発明の開示するデータモデルやシステムおよび方法を用いて、c中に指定されている条件によって統御される広範囲のリソース共有を達成することが可能である。この場合、権利u中に指定されている動作aはどのような用途にも応用される。その結果、本発明の残りの部分に開示される共有システムと共有方法は、リソースを共有するシステムおよび方法と見なすことが可能である。例えば、計算リソースの所有者が、CPUサイクルを共有して、学問的研究のプロジェクトに対する並行処理を容易化することを意図する。この所有者は、委託された同僚がCPUのアイドルサイクルを用いて実行する特定のタイプのプログラムを知りたいとは思わない。この使用シナリオでは、所有者は、主体pを委託された研究コミュニティ内のいずれかのメンバーとして、動作aをいずれかの使用として、リソースrをCPUサイクルとして、条件cを10pm〜6amのいずれかの時点として定義している権利uを発行する。この譲与された権利によって、委託された研究コミュニティのメンバーは、10pm〜6amでのCPUサイクルを共有することを許可される。この例では、共有される第一の対象は、動作aではなくてリソースrである。
【0044】
本明細書に記載する以下の図面は、上記の擬似表現言語で表現された譲与権利の例を示すものである。図2は、アリス(Alice)であると特定された主体に、「風とともに去りぬ(Gone With The Wind)」というタイトルのDVDを見る(View)権利が譲与されるという、条件を有さない譲与権利120を示す。図3は、1つの条件が付いた譲与権利130を示す。音楽クラブ(Music Club)と特定された主体に、ルイ・アームストロング(Louis Armstrong)の「この素晴らしい世界(What a wonderful world)」というCDをプレイ(Play)する権利が譲与される。この譲与された権利には、このCDのプレイ回数(Number of Play)を100回に制限する条件131が付いている。図4は、1つの条件付きの譲与権利140を示す。音楽クラブと特定された主体に、ルイ・アームストロングの「この素晴らしい世界」というCDをプレイする権利が譲与される。この譲与された権利には、このCDをプレイすることが許される期間を2006年1月までに制限する条件141(Not after Jan. 2006)が付いている。図5は、2つの条件が付いた譲与権利150を示す。音楽クラブと特定された主体に、ルイ・アームストロングの「この素晴らしい世界」というCDをプレイする権利が譲与される。この譲与権利には、このCDをプレイする回数を100回に制限する条件151と、このCDをプレイすることを許される期間を2006年1月までとする条件152が付いている。
【0045】
上記の擬似表現言語は例示目的で本発明の全般にわたって用いられているが、本発明は、いずれの特定の権利表記言語も、データ構造も、表現などにも制限されるものではない。
【0046】
権利のデータモデルは、多目的のものであり、どのような形態の権利表記をもモデリングすることが可能である。例えば、図6、7、8および9では、図2、3、4および5とそれぞれ同じ譲与権利を表現するのにMPEG REL(125、135、145および155)を用いる。
【0047】
別の例では、上記の権利データモデルを用いて、コピー絶対禁止、コピー自由、1世代コピーなどの保護されたコンテンツの保護状態を表す2ビットであるコピー制御情報ビット(CCIビット)の構造を次のようにモデリングすることが可能である。
u=(p=null,a=CCI,r=null,c)
ここで、pはコンテンツを受信するデバイスを意味し、aはコピー動作であり、rはCCIビットが関連付けられているコンテンツを意味し、条件cはコピー動作に対する制限である。このような制限には、コピー絶対禁止、コピー自由、1世代コピーなどが含まれる。
【0048】
第3の例では、次のFLEXnetライセンスは、ライセンスサーバマシン「lulu」にアクセス可能なすべてのデバイスに対して、特徴「f1」に対する2つのライセンス、特徴「f2」に対する6つのライセンスおよび特徴「f3」に対する1つのライセンスを譲与する。
「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:2005年1月1日
SIGN:サイン
signature:著名
【0049】
上記の権利データモデルを用いると、上記のFLEXnetライセンスを、次のように互いに別個の3つ権利にマッピングすることが可能である。主体pは、FLEXnetフロートライセンス中の認可サーバのホストIDまたはFLEXnet特徴が拘束されるノードのホストIDである。上記のFLEXnetの例では、主体pは、ライセンスサーバ「lulu」にアクセス可能なすべてのデバイスである。動作aは、FLEXnetライセンスの特徴(FEATURE)ラインに指定されている特徴を実行する権利である。リソースrは、FLEXnetライセンス中に指定されている特徴である。上の例では、リソースrは、FLEXnetの特徴f1、f2およびf3である。条件cは、FLEXnetライセンスの特徴(FEATURE)ライン中に指定されている制限である。上の例では、特徴f1に対する条件は2つのライセンスであり、特徴f2に対する条件は6つのライセンスであり、特徴f3に対する条件は3つのライセンスである。
【0050】
上記の権利データモデルに基づくと、権利は無条件となるが、これは、図2に示す譲与権利などのように関連の条件を何も有さないことを意味する。他方、権利は条件付きであるとは、図3および4に示す譲与権利の例などのように1つ以上の条件と関連していることを意味する。
【0051】
譲与権利u=(p、a、r、c)に指定されている条件cは、一般的には、満足しなければならない条件または、主体pにとってリソースrに対して動作aを実行するために実施しなければならない義務である。権利と関連付けることが可能な条件には、無状態条件および状態条件という2つのタイプが存在する。
【0052】
無状態条件とは、状態とは無関連の条件である。このような条件は、譲与権利を行使するために実行されなければならない義務のことである。このような条件は、譲与権利の寿命には直接には関連していない。無状態条件は一般的には、ビジネス上の規則(支払い方法、関連者各々に支払うべきパーセンテージなど)、認可規則(権利の行使の承認要請など)、システム要件などに関連している。
【0053】
状態条件とは、1つ以上の状態と関連付けられた条件のことである。このような条件は、譲与された権利を行使可能な回数や、譲与権利が行使される時間ウインドウなどの譲与権利の寿命中のある活動に直接的に関連している。状態条件は、その状態の特徴によってさらに2つのタイプに分割することが可能である。
【0054】
基準条件とは、状態を修正することなく読み取る状態条件のことである。このタイプの条件によれば、現在の値から次の値への状態の遷移は、譲与権利の行使や消費とは無関係である。例えば、図4に、譲与権利が行使される時間ウインドウを規定する条件を示す。この例では、状態の現在値は、譲与権利が行使されようとされまいと、時間の経過とともに変化し続ける。
【0055】
分割可能条件とは、状態を読み取って更新する状態条件のことである。このタイプの条件によれば、現在値から次の値への状態の遷移は、譲与権利が行使されるごとに始動される。例えば、図3に、譲与権利が行使される回数を規定する条件を示す。この例では、状態の現在値は、譲与権利が行使されるごとに減少する。
【0056】
状態に対する条件の依存性を組み込むため、上に開示した譲与権利u=(p、a、r、c)のデータモデルは次のように展開可能である。
u=(p,a,r,ci⇒Qi:i=1,..,n)
【0057】
ここで、(ci⇒ Qi:i=1,..,n)は、Qiが、i=1,..,nの場合に条件ciと関連している状態であることを意味する。条件ciが無状態条件であれば、Qiは
空である。権利の状態は、この権利と関連しているすべての条件の状態で表される。
【0058】
権利の導出と統合
【0059】
譲与権利u=(p、a、r、ci⇒Qi:i=1,..,n)に指定されている主体pは、1つの主体ではなく主体のグループを表している。例えば、図4に、2006年1月までに行使を制限する条件付きのルイ・アームストロングの「この素晴らしい世界」というCDをプレイする権利が音楽クラブに譲与されている様子を示す。「音楽クラブ」とは、人々のグループのことであり、音楽クラブの人であれば誰でも、現在の時点が2006年1月以降でなければこのCDをプレイしてもよい。
【0060】
アリスであると特定された主体が音楽クラブのメンバーであれば、アリスは、図4に指定されている権利を行使して、「この素晴らしい世界」というCDをプレイすることが可能である。しかしながら、図10に示すように、アリスはまた、図4に指定されている譲与権利と同じ条件141が付いた「この素晴らしい世界」というCDをプレイする権利142も譲与されている。主体のアリスにとっては、図4に指定されている譲与権利と図10に指定されている譲与権利の双方はまったく同じである。したがって、図10の譲与権利は図4の譲与権利の具体的なインスタンスであるので、図10の譲与権利は、図4の譲与権利から導出された権利であると考えることが可能である。同様に、図11に、図4の譲与権利から導出された権利143を示す。この例では、条件144は変更されてはいるが(Not After Jan. 2005:2005年1月まで)、図4の譲与権利の条件141の範囲内にとどまっている。
【0061】
主体pと同様に、u=(p、a、r、ci⇒Qi:i=1,..,n)中のp、a、rまたはciの各々は、それぞれ主体のグループ、動作、リソースまたは条件を互いに独立に示すことが可能である。したがって、様々な権利が、所与の文脈内ではまったく同じであるという場合がある。この場合、このような権利は互いに関連し、ある権利を他の権利から導出される。
【0062】
導出規則
【0063】
u=(p、a、r、ci⇒Qi:i=1,..,n)とv=(p’、a’、r’、c’i⇒Q’i:i=1,..,m)とを2つの権利であるとする。vは、m≦nであり、次の規則が当てはまれば、uから導出されたといわれる。
規則D1:p⇒p’,a⇒a’,r⇒r’
規則D2:∀i≦m,ci⇒ci’
規則D2.1:Qiが、ciの可能な状態値を表す非順序集合であれば、Q’i=Qi、0−QiここでQi、0はvの導出に先立つuの状態である。
規則D2.2:Qiが、ciの累積値を表す唯一の値を含む場合、‖Q’i‖≦‖Qi,0‖,‖Qi‖≦‖Qi,0‖および‖Qi‖+‖Q’i‖≦‖Qi,0‖、ここでQi、0はvの導出に先立つciの状態を表し、表記‖Qi‖はQiのノルム(すなわち値)を意味する。
規則D2.3:Qiが、ciの可能な範囲値を表す順序集合であれば、Q’i⊂Qi,0およびQ’i∩Qi=、ここでQi、0はvの導出に先立つuの状態である。
【0064】
表記p⇒p’は、pはp’を意味するまたはpはp’を導出するまたはp’はpから導出されたことを意味する。例えば、アリスはまた「キーホルダーA(Key Holder A)」としても知られ、したがって、アリスは「キーホルダーA」を意味する。p⇒p’であるかどうかを判定する規則はアプリケーションによって異なる。しかしながら、p’がpと同じであったり、p’がpのインスタンスであったり、pが空であったりする特殊な場合があるが、このような場合にはp⇒p’となる。
【0065】
規則D1は、サブ権利は、これが導出された元の権利によって許可されている主体、動作およびリソースだけを指定すべきことを定めている。より具体的には、規則D1は、サブ権利を遵守することを必要としている。主体p’はpから導出されなければならない。例えば、pが「部門Xのいずれかの被雇用者」である場合、アリスが実際に部門Xの被雇用者であれば、p’=”Alice(アリス)”はpから導出されたと言われる。動作a’はaから導出されなければならない。例えば、aが「修正(注釈という動作を含む)という動作と変更するという動作」であれば、a’="the annotation of annotating(注
釈する動作)"は、aから導出されたと言われる。リソースr’はrから導出されなけれ
ばならない。例えば、rが「出版社Yのいずれかの本」である場合、「ラーニングXML」が出版社Yから出版されていれば、r’="Learning XML(ラーニングXML)"は、rから導出されたと言われる。
【0066】
規則D2は、各々の条件c’iがこれに対応するciから導出されなければならないことを述べている。ある条件の状態の導出は、この条件のタイプ、そのあり得る状態およびその現在値によって異なる。規則D2.1〜D2.3は、以下に解説するようにこの依存性を定めている。
【0067】
規則D2.1を解説するために、cを、異なる多くのチャプタ、例えば、チャプタ1、3および5に対する印刷を制限する条件であるとすると、Q={chapter 1, chapter 3, chapter 5(チャプタ1、チャプタ3、チャプタ5)}となる。第1のサブ権利を導出する場合、有効なQ’の集合は、{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}が第1のサブ権利に譲与された後、Qは{chapter 3, chapter 5}となり、Q’は、{chapter 3}、{chapter 5}および{chapter 3, chapter 5}のうちの1つでしかあり得ないことになる。
【0068】
規則D2.2を解説するために、cを、再生動作を3回に制限する条件であるとすると、Q={3}となる。第1のサブ権利を導出する場合、有効なQ’の集合は、{1}、{2}および{3}である。例えば、{2}が第1のサブ権利に譲与された場合、cの現在値は1であり、Q’は、{1}でしかあり得ないことになる。
【0069】
規則D2.3を解説するために、cを、再生動作の有効期間を11/1/2004〜11/5/2004に制限する条件であるとする。Qを、{{11/1/2004〜11/2/2004}、{11/1/2004〜11/3/2004}、{11/21/2004〜11/3/2004}}などの11/1/2204〜11/3/2004の可能なすべてのサブインターバルの順序集合であるとする。インターバル{11/2/2004〜11/3/2004}が第1のサブ権利に譲与されると、Qは{{11/1/2004〜11/2/2004}、{11/3/2004〜11/5/2004}}となる。
【0070】
したがって、上記で定義した導出規則は、pがp’を意味し、aがa’を意味し、rがr’を意味し、ciがc’iを意味し、Q’i⊂Qi ∀i≦m≦nであれば、譲与された権利v=(p’、a’、r’、c’i⇒Q’i:i=1,..,m)をu=(p、a、r、ci⇒Qi:i=1,..,n)から導出可能であることを提示している。
【0071】
ここで、vは、uから導出されなかった条件を含むことがあり得る。これらの条件は本発明では制限された条件と呼ばれる。制限された条件によって、サブ権利の譲与者は、権利の被譲与者がサブ権利を消費するのをさらに制限することが許可される。サブ権利vが何らかの制限された条件を含む場合、これはときとして条件付きサブ権利と呼ばれる。例えば、会社Xがその部門Yに対して、この部門Yが部門の目標の少なくとも80%を達成すればDVD Zを10コピー譲与する。vをuに統合して戻す場合、すべての制限された条件が無視される。
【0072】
pとp’との間、aとa’との間、rとr’との間、ciとc’iとの間の関係はアプリケーションによって異なる。これらの関係は、アプリケーション内で定義可能であったり、権利表記中で表現可能であったりする。このような関係をアプリケーション内で定義すると、このアプリケーションは一方の式が他方によって意味されるかどうか判定する。関係を権利表記中で表現すると、アプリケーションは、1つの式が別の式を意味するかどうかを、これらの式を権利表記に照らし合わせて評価することによって検証することが可能である。
【0073】
v=(p’、a’、r’、c’i⇒Q’i:i=1,..,m)がu=(p、a、r、ci⇒Qi:i=1,..,n)から導出されると、vは、uの導出またはuのサブ権利であると言われる。言い換えれば、uはvの統合と言われる。例えば図10および11に示す譲与された権利は、図14に指定した譲与された権利のサブ権利である。vがuから導出されると、vはuの導出またはサブ権利と呼ばれる。
【0074】
図12に、譲与権利160の導出を示す。譲与権利160は主体ライブラリAに譲与され、コピーの数に関連する1つの条件を有する。主体であるジョン・ドエがライブラリAのメンバーであれば、譲与権利162は譲与権利160から導出される。この例では、譲与権利161は2つの条件を含む。条件163はジョン・ドエに対してリソースを1コピーだけ与える。条件164は、ジョン・ドエがリソースを使用することに対して時間制限を割り当てる。
【0075】
同様に、図13は、別のデバイス上で用いられる譲与権利170の導出を示している。譲与権利170は、主体のジェーンがリソースを2コピー用いることを提示する1つの条件171を有する。導出された権利172は、ジェーンがリソースを1コピー用いることを制限する条件173を含む。
【0076】
統合規則
【0077】
権利を統合する方法は、権利を導出する方法の逆である。
【0078】
権利をu、サブ権利をvとすると、vを統合してuに戻す規則は次のように定義される。
定義:u=(p、a、r、ci、1⇒Qi:i=1,..,n)を権利として、v=(p’、a’、r’、c’i、2⇒Q’i:i=1,..,m)をuのサブ権利とする。m≦nであって、次の規則が適用されると、権利u’=(p、a、r、ci⇒Q*i:i=1,..,n)は権利uとそのサブ権利vの統合であると定義される。
規則I1:p⇒p’、a⇒a’、r⇒r’
規則I2:∀i≦m、ci⇒ci’
規則I2.1:Qiが、ciの可能な状態値を表す非順序集合であれば、Q’iもまたc’iの可能な状態値を表す非順序集合でなければならず、また、Q*i=Qi∪Q’iである。
規則I2.2:Qiが、ciの累積値を表す唯一の値を含む場合、‖Q*i‖=‖Qi‖+‖Q’i‖、ここで‖Qi‖は、Qiのノルム(すなわち値)を意味する。
規則I2.3:Qiが、ciの可能な範囲値を表す順序集合であれば、Q’iもまたc’iの可能な範囲値を表す非順序集合でなければならず、また、Q*i=Qi(+)Q’iである。(+)は、カスタマイズされた和集合演算であり、システムによって異なる。例えば、範囲の粒状性と、範囲をどのようにすれば合併可能な(範囲を合併しながらもギャップをどのように取り扱うかを含めて)定義することが可能である。
【0079】
規則I1は、サブ権利が、この導出元の権利によって許可されたような主体、動作およびリソースのみを含まなければならないことを定めている。規則I2は、条件c’i各々が、その対応するciから導出されなければならないことを提示している。条件の状態の導出は、この条件のタイプ、その可能な状態値およびその現在状態値によって異なる。規則I2.1〜I2.3は、この依存性を定義している。特に、規則I2.1は、QおよびQ’が双方とも判明している値の非順序集合であれば、統合されたQ*はQおよびQ’の和集合であると述べている。規則I2.2は、QおよびQ’各々が、累積値を表す1つのエレメントを有すれば、統合された累積値はこれら2つの値の和であることを述べている。規則I2.3は、QおよびQ’がインターバルを表す順序集合であれば、統合されたQ*は双方の集合の和集合であることを述べている。
【0080】
分割可能権利、現在の権利、共有可能権利およびグループライセンス
【0081】
上記で定義した導出規則は、サブ権利を所与の権利から導出する、または、所与の権利が別の権利から導出可能であるかを判定するための一般的なメカニズムである。この規則は、サブ権利が次のメカニズム、すなわち、譲与権利のいずれかのコンポーネントを用いてサブ権利を導出するメカニズムと、何らかの状態条件を分割して、譲与権利からサブ権利を作成するメカニズムのうちのどちらかまたは双方を用いて導出することが可能であることを指定している。
【0082】
しかしながら、様々なアプリケーションでは、譲与権利のあるコンポーネントだけをサブ権利を導出するために用いることを許可、または、ある状態条件だけを分割してサブ権利を作成することを許可し得る。例えば、ライブラリアプリケーションは、譲与権利に指定されている主体を用いてサブ権利を導出することを許可しているため、ライブラリは、そのメンバーのためのサブ権利をライブラリに譲与された権利から導出することが可能である。図12は、ライブラリAが、そのメンバーであるジョン・ドエのためにその譲与権利からサブ権利を導出する様子を示している。図12では、サブ権利は主体に基づいて導出される。
【0083】
別の例では、ホームネットワークアプリケーションが、ある条件状態を分割することを許可している。この場合、ホームネットワークのユーザは、ユーザに譲与された権利からユーザのホームネットワーク内の各々のデバイス用の権利を導出することが可能である。図13は、ユーザのジェーンがジェーンの譲与権利から別のデバイス上で用いるための権利を導出するシナリオを示している。この例では、サブ権利は、譲与権利と関連する条件状態の分割可能性に基づいて導出される。
【0084】
譲与された権利は、サブ権利を導出する機能に基づいて次のタイプ、すなわち、分割可能権利、並列権利、共有可能権利およびグループ権利に分類することが可能である。これらのタイプの権利の各々を以下に説明する。
【0085】
分割可能権利
【0086】
分割可能権利とは、ある権利をサブ権利を作成するために分割しながらも同時にこの分割可能権利の他のコンポーネントを不変のままとすることが可能なような1つ以上の状態条件付きのこのような権利のことである。分割可能権利の用途は多い。例えば、これらは、消費者が権利を公平に用いることを刺激するために用いることが可能である。消費者は、ある権利を獲得すると、これをサブ権利に分割して、様々なデバイス上で、様々な場所で、様々な時間でなどのように用いる。
【0087】
サブ権利が分割可能権利から導出されると、オリジナルの分割可能権利中の各々の分割可能条件の現在状態を、この導出されたサブ権利の各々中の対応する条件の初期状態とこの条件の状態関数とにしたがって更新される。例えば、分割可能権利は、ユーザが権利を行使可能な回数を制限する条件を有し、また、現在の条件状態が、まだ行使の回数が5回残っていることを示していると仮定する。最大で2回の行使回数を有するサブ権利を導出する場合、導出元の分割可能権利の条件の現在状態を更新して、3回行使回数が残っていることを反映する(行使回数5回から2回を差し引く)。
【0088】
導出されたサブ権利の基準条件は、オリジナルの分割可能権利の同じ基準条件に関して制限される。例えば、分割可能権利が、この権利を行使し得る時間範囲を指定する条件を有する場合、導出されたサブ権利もまた、権利を行使し得る時間範囲を規定する基準条件を有さなければならず、また、サブ権利の時間範囲は、この分割可能権利に対して指定された時間範囲内に完全に入らなければならない。
【0089】
したがって、権利u=(p、a、r、ci⇒Qi:i=1,..,n)は、ciが分割可能条件であるようなiが少なくとも1つあれば、分割可能である。さらに、v=(p、a、r、c’i⇒Q’i:i=1,..,m)は、次の仮定が成立すれば導出またはuのサブ権利である。
ciが分割可能条件であるようなiが少なくとも1つ存在する、
vが、u中に指定されているすべての条件を含み、c’i=ci、i=1,..,n、および、Q’i⊂Qi、∀i≦m≦nであり、
導出v後のuの各々の分割可能条件ciの現在状態が、導出v前のciの現在状態と、導出vの初期状態およびciの現在関数にしたがって更新され、
すべての基準条件ciに対して、c’iがciであるかciの制限であるかである。例えば、条件ciが時点t1以前ではなく、導出された条件c’iはt3以前ではなくt4以後ではないが、ここでt1<=t3<=t4<=t2であり、表記<=は「以下」を表し、
すべての無状態条件ciに対して、ci’はciである。
【0090】
図14は、分割可能権利u(200)からサブ権利v(210)を導出するプロセスを示す。この例では、分割可能権利uは3つの条件を有する。
行使許可回数が10であると規定している分割可能条件201の現在状態202は行使回数が5回残っている、
権利行使可能な時間範囲を基準条件203が(2004年1月以後であり、2006年1月以前)規定している、
譲与権利を行使している間に宣伝Yを実施しなければならないと無状態条件204が規定している。
【0091】
同じ条件集合付きのuからサブ権利v(210)が導出される。特に、
分割可能条件211の場合、vは、行使許可回数として2回を規定している条件を有する。u中の同じ条件の現在状態が、残余行使回数5回から残余行使回数3回に更新される。
基準条件213の場合、vは、権利を行使し得る時間範囲を規定している条件を有する。この条件はuから導出され、したがって、vに規定されている時間範囲条件は、u中に規定されている時間範囲内に完全に入る。
無状態条件214の場合、vはuとまったく同じ条件を有する。
【0092】
導出後、分割可能権利u(300)の現在状態205は残余プレイ回数が3回である。
【0093】
この例では、擬似言語のフォーマットが、譲与された権利と条件の特徴を反映するように変更されている。したがって、「GRANTED RIGHTS(譲与権利)」は、譲与権利が実際に分割可能であることを示す「DIVISIBLE RIGHTS(分割可能権利)」に変更されている。「CONDITION(条件)」は、条件タイプを反映するように、「DIVISIBLE CONDITION(分割可能条件)」、「REFERENCE CONDITION(基準条件)」または単に「CONDITION(条件)」に変更されている。分割可能条件の宣言には、条件の現在状態が含まれている。
【0094】
このフォーマット変更は、特定の実現を提案するものではない。譲与された権利と条件のタイプを特定するために用いられる方法は、実現に委ねられる。例えば、このタイプは表現に明示的に宣言されている(図4のように)または他のいずれかのメカニズムを用いて特定された名前によって特定可能である。しかしながら、条件タイプの明示的な宣言には利点がある。同じ条件(例えば、最大の許可行使回数)が、1つの譲与権利中で分割可能であるが、他の権利中ではそうではない。分割可能条件の現在状態は、条件内(図4のように)宣言されるか、または、既知の認可ソース(認可された追跡デバイス、遠隔サービス、中央サービスなど)から検索されるかである。
【0095】
並列権利
【0096】
並列権利とは、サブ権利を主体に基づいて導出可能な元の権利であり、この場合、この並列権利の他のコンポーネントは不変のままである。並列権利においては、主体とは、主体のグループ、多数の識別を有する同じ主体または双方のことである。グループ中の主体はその各々が、並列権利中に指定されている同じ権利を継承する。並列権利によって、譲与権利中に指定されている主体が導出可能となり、指定されている主体に対するサブ権利が導出可能となるようにする。
【0097】
並列権利は状態条件を含むが、このような条件は分割可能ではない。サブ権利が状態条件付きの並列権利から導出されると、状態条件がサブ権利中で正確に(同じ状態値で)再現される。その結果、サブ権利中の条件状態は、導出された主体ごとに個々に管理される。したがって、導出された主体は各々が、状態を個々に維持して、譲与権利の消費を追跡する。
【0098】
例えば、並列権利として、グループの各メンバーに対して同じ権利集合を与えるメンバー資格がある。一部のアプリケーションでは、権利消費デバイスが、並列権利中の主体によって指定されているグループに対して特定の主体が実際に属していることを証明することが不可能である場合には、サブ権利を並列権利から導出することが必要となる。
【0099】
権利u=(p、a、r、ci⇒Qi:i=1,..,n)は、次の条件が成立すれば並列権利である。
ciが、すべてのiに対して分割可能条件ではなく、
p⇒p’となるようなp’が少なくとも1つ存在し、また、権利v=(p’、a、r、ci⇒Qi:i=0,..,n)がuの導出である。例えば、pが音楽クラブであり、p’が音楽クラブのメンバーであるアリスであれば、p⇒p’である。別の例では、pがアリスであり、アリスはまた、「Key Holder A(キーホルダーA)」としても知られている。すると、p⇒p’であり、ここで、p’は「キーホルダーA」である。
【0100】
図15は、音楽クラブの各々のメンバーに、ルイ・アームストロングの「What a wonderful world(この素晴らしい世界)」というCDをプレイする無制限の権利を譲与する並列権利u(220)を示す。この例では、主体のジョン・ドエは、音楽クラブのメンバーである。したがって、ジョン・ドエは、主体ジョン・ドエに同じCDをプレイする無制限の権利を譲与するサブ権利v(221)を導出することが可能である。
【0101】
図16は、状態条件226を含む並列権利u(225)を示す。この例では、この並列権利は、音楽クラブのメンバーが、ルイ・アームストロングの「この素晴らしい世界」というCDを5回プレイすることを指定している。導出前の現在状態227では、プレイ回数が3回残っている。サブ権利v(230)とw(235)を導出する場合、並列権利中の状態条件の現在状態(オリジナルの最大回数である5回のうちの3回が残っている)が、それぞれ条件231と236としてサブ権利の各々中で再現される。導出後は、サブ権利vおよびwの条件状態は互いに独立に追跡される。グループの各々のメンバーの条件状態は、中央認可サーバ、ユーザデバイスなどで追跡可能である。
【0102】
共有可能権利
【0103】
共有可能権利とは、主体と、もしあれば、その分割可能条件の状態との双方に基づいてサブ権利を導出することが可能な元の権利のことである。したがって、共有可能権利は、指定された主体間で共有可能な最大限の権利を指定する。導出された主体が共有可能権利からサブ権利を導出すると、条件状態を、導出されたサブ権利に割り当てられた条件状態にしたがって共有権利から推論する。
【0104】
並列権利と分割可能権利は、共有権利の特殊な場合である。特に、並列権利は、分割可能条件無しの共有可能権利の特殊なケースであり、分割可能権利は、少なくとも1つの分割可能条件付きであるが、それから導出することが不可能な主体(主体はグループを指定しない)付きの共有権利の特殊なケースである。
【0105】
共有権利と並列権利間の主要な相違は、導出されたサブ権利中の状態条件の状態をどのように追跡するかという点である。並列権利中の状態条件は分割可能ではないため、各々の導出されたサブ権利の条件状態は互いに独立に追跡される(状態は、各々のサブ権利の主体に対して別個に追跡される)。共有可能権利中の状態条件は分割可能であるため、導出されたサブ権利の条件状態は共有される(すべての導出されたサブ権利は、各々の分割可能条件に対して同じ状態を指し示している)。この結果、サブ権利の主体が条件状態を共有することになる。
【0106】
図17は、「この素晴らしい世界」というCDを100コピー所有して、この100コピーをメンバー間で分配する権利を音楽クラブに譲与する共有可能権利u(240)を示す。この例では、分割可能条件の現在状態241は、10コピーが今までに分配され、90コピーが残っていることを示している。音楽クラブのメンバーであるジョン・ドエという主体は、サブ権利v(242)中にこのCDを1コピー譲与される。サブ権利vは、1コピーの状態243付きの共有可能権利uから導出される。共有可能権利u中の分割可能条件の現在状態244は、残りのコピー数が89に減少する。
【0107】
分割可能権利と並列権利用のアプリケーションを含む、共有可能権利の特徴を利用可能なアプリケーションは多く存在する。このようなアプリケーションの1つは、「グループライセンス」と呼ばれ、以下に説明する。
【0108】
グループライセンス
【0109】
グループライセンスとは、一人以上の認可されたユーザに対して最大限の権利を譲与して、この認可済みユーザが、自分たちの間での自分たち自身の共有ポリシーにしたがって譲与権利を共有したり、他の認可済みユーザの集合と共有したり、認可済みユーザが共有権利を返却したり、さらに、他の認可済みユーザと各々の共有権利をさらに共有したりすることを許可する権利のことである。したがって、グループライセンスは、サブ権利を返却したり、統合してグループライセンスに戻したりすることを許可する共有権利である。
【0110】
本発明中に定義するように、ライセンスとは、あるユーザに譲与された権利のことである。したがって、「ライセンス」と「権利」という用語は、交換可能である。多くのDRMシステムがライセンスに対して異なった定義をしているが、ライセンスは少なくとも1つの譲与された権利を含まなければならない。したがって、DRMシステムで使用されるライセンスの定義を、本発明中のライセンスの定義にマッピングすることが可能である。例えば、MPEG RELでは、「ライセンス」という用語は、譲与権利の集合に、他の情報(発行者、ライセンスの整合性などに関する情報など)を足したものである。したがって、MPEG RELライセンスは、本発明に定義するように多数のライセンス中にマッピングすることが可能である。
【0111】
上記のようなグループライセンスの概念は、共有可能な権利と権利の統合という概念を用いて実現することが可能である。グループライセンスは、共有可能権利であるため、認可されたユーザおよび/または認可済みユーザのグループ中で共有されるように動的に分割可能である。あるグループライセンスを共有目的で分割すると、新しいライセンスが作成されて、グループライセンス中に指定されている条件状態が、新しいライセンス中に指定されている条件状態を推論するように調整される。この作成された新しいライセンスは共有されたライセンスと呼ばれるが、また、グループライセンスでもある。したがって、共有されたライセンスは、認可済みのユーザによって消費するか、または、認可済みのユーザおよび/または認可済みユーザのグループ間で共有目的でさらに分割することが可能である。
【0112】
共有されたライセンスはまたグループライセンスでもあるため、この共有ライセンスの権利被譲与者は、権利譲与者として動作して、下流での共有目的でその共有ライセンスから新たな共有ライセンスをさらに導出することが可能である。したがって、多段階権利共有や、権利被譲与者の決定権に基づいた共有や、異なったグループの主体および/またはデバイス間での共有などの動的権利共有がサポートされる。
【0113】
共有ライセンスは、一旦作成されると、消費目的利用可能となる。共有ライセンスが使用されるごとに、その条件状態が更新されて、その使用を反映するようにする。どの時点でも、共有ライセンスの残っている権利は、上に開示した権利統合方法を用いて、このライセンスの導出元であるグループライセンスに対して返却することが可能である。
【0114】
グループライセンスの概念は、権利とリソースの共有、デバイス間での共有、ユーザ間での共有、組織間での共有などに関するあらゆる態様をカバーしている。グループライセンスは、権利とリソースの動的共有を可能とする多くのアプリケーションに対する基本的な要素となりえる。このようなアプリケーションには、これに限られないが、次のものがある。
ライブラリ:あるライブラリが、「風とともに去りぬ」という題名の本をある数だけに対するグループライセンスを譲与される。いつでも、このライブラリは、この本のコピーを、そのグループライセンスから共有ライセンスを導出することによってライブラリメンバーに貸し出すことが可能である。このライブラリが共有ライセンスを導出すると、利用可能なコピーの総数は、ライブラリメンバーがこの本を返却するまで減少する。
ホームネットワーク:ユーザのホームネットワークは、様々なDRM能力を有する様々なデバイスを含んでよい。ユーザは、前もってどのネットワークデバイスがライセンスを消費するかを指定することなく、ユーザのホームネットワーク内で使用する目的でライセンスを購入するという利便性を欲しがる。この目的のため、ユーザはグループライセンスを獲得して、ホームネットワーク中の特定のデバイスのためにそれから共有ライセンスを導出する。
メンバー資格:あるグループのメンバーは、このグループに譲与されている一般的なライセンスを用いる代わりに自分たち自身のための特定的なライセンスを導出したがるが、これは、ユーザデバイスが一般的ライセンスを執行することが不可能であるからである。
【0115】
次の例は、グループライセンスの概念とグループライセンスからどのように共有ライセンスを導出するかを示している。
【0116】
図18は、映画Bの100コピーの権利を企業Aに譲与するグループライセンス250を示す。グループライセンスは、最初に作成されたときは、最大コピー数を100と規定し、100コピーが残っているという現在状態を規定する分割可能条件を含む。企業Aは、営業上の必要性にしたがってその被雇用者または被雇用者グループ間に映画Bの100コピーというプールを分割してよい。
【0117】
図19は、グループライセンス250中のその100コピーというプールから映画Bの10コピーをその人事部門に譲与する。企業Aは、人事部門に対して映画Bの10コピーに対する権利を譲与する共有ライセンスを導出するが、これは条件256に反映される。図19はまた、図18に示すグループライセンス中の条件状態251をどのように更新して、100コピーのプールから10コピーを差し引いて90コピーが残るようにするかを示している。
【0118】
企業Aが人事部門に譲与する共有ライセンス255もまた、さらに分割可能なグループライセンスである。図20は、グループライセンス257と条件261に反映されるように、企業Aの人事部門がその被雇用者のうちの一人であるジョン・ドエに対して、映画Bの1コピーに対する権利を譲与する様子を示している。図20はまた、人事部門のライセンス中の条件状態256をどのように条件状態257に更新して、10コピーのそのプールから1コピーを差し引いて9コピーが残るようにするかを示している。図20はまた、人事部門が映画Bの1コピーをジョン・ドエに譲与する動作が、企業Aのオリジナルのグループライセンス中の条件状態251に影響しない(企業Aにはいまだ90コピーが残っている)ことを示している。
【0119】
ジョン・ドエに映画Bの1コピーを譲与した後では、図21に示すように、人事部門は、その残っているコピーのうちの2つを企業Aに返却すると決心する。返却したら、企業Aのグループライセンス250に対する残りのコピーの数は2だけ増加して条件状態251中の90コピーから条件状態252中の92コピーとなり、同時に、人事部門のライセンス255に対する残りのコピーの数は2だけ減少して条件状態257中の9コピーから条件状態258中の7コピーになる。
【0120】
図22は、映画Bの100コピーというプールの共有を許可する企業Aのグループライセンス(図18に示す)の擬似MPEG REL表現260を示す。企業Aは、このプールを被雇用者のグループ間に、コピーの総数がプールのキャパシティを超えない限り各々のグループに対して共有ライセンスを発行することによって分割してよい。分配する権利は、seekApproval条件を条件とする発行権利を用いて指定される。このseekApproval条件は、追跡サーバが、プール中のコピーの残数と共有ライセンスに対して要求されているコピーの数とを追跡することに依存している。分配可能な使用権利は、内部譲与に含まれている。これには、受領側ユーザグループの識別のプレースホルダとしての変数Yと、受領側グループに割り当てられたコピーの数のプレースホルダとしての変数Xと、企業Aが共有ライセンスに追加したがっているいずれかのカスタム条件のプレースホルダとしての変数Zが含まれている。
【0121】
図23は、企業Aの人事部門(図19に示す)に対するライセンスの擬似MPEG REL表現265を示す。変数Y、X、およびZに、人事部門(受領側グループの識別)、10(人事部門に割り当てられたコピー数)および使用報告(すべての使用を指定されたサーバによって追跡される必要がある)が代入される。その他の情報は、現在のライセンスと、現在のライセンスが導出する元のライセンスとを特定する。
【0122】
図24は、サブグループライセンスと共有ライセンスの双方がグループライセンスから導出される使用事例を示す。中心ライブラリCは、本Bを100回コピーすることを許可するグループライセンス280を獲得する。中心ライブラリは、その必要性によってローカルライブラリのためにそのグループライセンスからサブグループライセンス281と282を作成する。Cは、20コピーをサブループライセンス282中でローカルライブラリXに分配し、30コピーをサブグループライセンス281中でライブラリYに分配する。ローカルライブラリYはさらに、サブグループライセンス284中でライブラリZにそのコピーの10コピーを分配する。さらに、共有ライセンス283、286、287が、グループライセンス280、サブグループライセンス282、サブグループライセンス281またはサブグループライセンス284から発行されてよい。
【0123】
権利とリソースの動的共有をサポートするシステム
【0124】
上記に開示したグループライセンスの概念は、権利共有のあらゆる態様をカバーしている。これは、共有可能権利の消費を認可し、分散された共有権利を含むライセンスを発行し、グループライセンスと共有可能ライセンスの双方に対する権利の状態の管理が可能なあらゆるDRMシステムによって実現可能である。図25は、このようなDRMシステムの例を示す。DRMシステム300は、例えば、起動サーバ302、認可サーバ303、1つ以上の権利消費デバイス305、保護コンテンツ/アセット分配サーバ308、ライセンスサーバ310および保護アプリケーション/サービス311を含む。認可サーバ303は、1つ以上のキー304と関連付けられてよい。権利消費デバイス305はDRMコンポーネント306を含み、また、1つ以上のライセンス307と関連付けられる。保護コンテンツ/アセット分配サーバ308は、保護されたコンテンツ/サーバ309を分配する。ライセンスサーバ310は、本システムにライセンス307を提供する。保護アプリケーション/サービス311は、明瞭なコンテンツ/アセット312と権利提案を提供するが、これは権利と条件とを含む。
【0125】
図26は、動的な権利とリソースの共有をサポートするシステムの基本的なコンポーネントを示す。これらのコンポーネントには、インストールコンポーネント321、インストール追跡コンポーネント(TCI)322、共有追跡コンポーネント(TCS)323、共有コンポーネント324、委託コンポーネント325、消費コンポーネント326および消費認可コンポーネント327が含まれる。各々のコンポーネントは、ハードウエアコンポーネント、ソフトウエアコンポーネント、デバイス、サービスなどとして実現可能である。グループライセンスは、一旦権限によって発行されると、その使用を追跡する元となる特定の環境に拘束されたりされなかったりする。本発明の好ましい実施形態では、グループライセンスは環境には初期は(ライセンス発行時は)拘束されない。このプロセスによってより大きなフレキシビリティが与えられるが、これは、グループライセンスは、特定の環境に限られることなくどこでもいつでも獲得することが可能であるからである。
【0126】
図26に示すように、グループライセンス320は、環境に拘束されなかった場合には、共有されたり使用されたりすることが可能となる前にインストールコンポーネント(IC)321によってインストールされなければならない。TCI322がこのインストールを認可する。このインストールの目的は、グループライセンス320が以前にはインストールされていなかったこと、そして、これからはグループライセンスの権利の状態を追跡する、共有追跡コンポーネント(TCS)と呼ばれる追跡コンポーネント323にグループライセンスが拘束されることを保証することにある。
【0127】
グループライセンスの権利の状態はどのデバイスにでも保存可能であるが、権利の状態は、権利の共有を制御する共有コンポーネントによって証明され、検証されなければならない。例えば、権利の状態は、インストールされたグループライセンスと同じデバイスに保存するか、グループライセンスが拘束されている認可コンポーネントと同じデバイスに保存するか、遠隔サービスに保存するか、または、グループライセンス内に保存することが可能である。権利の状態の保存する様々な考えられる戦略が、図17、18、19、20および21ならびに本発明の他の図面に図示されている。権利の状態がグループライセンス自体内に保存された場合、権利の状態が更新されるごとにグループライセンスは変換されて(なぜならライセンスが消費されたか、または、権利が行使されたからである)、新しい状態を反映するようにする。この新しい状態を有するグループライセンスが交換グループライセンスであれば、オリジナルのグループライセンスは、一旦交換グループライセンス中の新しい状態を反映するために変換されたら無効となる。
【0128】
グループライセンスは、一旦インストールされれば、インストール済みグループライセンスと呼ばれ、共有目的に対して利用可能となる。共有コンポーネント(SC)324は、要求を、インストールされたグループライセンスを解釈し、TCS323から現在の権利状態を検索し、この現在の権利状態をこの要求に照らし合わせて検証し、共有ライセンス(認可されれば)作成することによって処理する。インストールされたグループライセンスから導出されたこの共有ライセンスは、委託証明目的で委託コンポーネント325に対して利用可能なものとされる。
【0129】
この共有ライセンスは、これ自体が、さらなる共有目的で利用可能とされるグループライセンスである。これは、次の形態のうちの1つであり得る。
拘束グループライセンス:このタイプのライセンスは、作成されるとTCSに対して拘束される。共有ライセンスが拘束されるTCSは、インストールされたグループライセンスが拘束されるTCSと同じでも異なっていてもよい。編成が小さい場合、追跡コンポーネントは同じでもよいが、編成が大きかったり主体のグループが多様であったりすれば異なったものとなる。
非拘束グループライセンス:このタイプのライセンスは、発行されたときには特定のTCSに拘束されていないが、後になってTCSに拘束されることがあり得る。このタイプのライセンスは、ライセンスが生成されるときに対象の消費環境または対象のTCSが知られていない場合に生成される(例えば、別の権利被譲与者グループ、別のネットワークなどとの共有のためにライセンスを作成する)。別のシナリオでは、ライセンスの譲与者は、TCSに拘束するオプションを維持することによってライセンスのフレキシビリティをより大きいものとすることを提案したがる。このような状況下では、TCS拘束権限をライセンス被譲与者または他の当事者に委譲することも可能である。
消費ライセンス:このタイプのライセンスは、共有ではなく主として消費目的で作成される。しかしながら、これは、認可された主体またはデバイス間で共有することが可能である。
【0130】
図26に示す基本的コンポーネントを用いて、様々な構成でシステムを設計することが可能である。消費ライセンスが作成されると、消費コンポーネント326は、消費認可コンポーネント327によって認可されればリソースの消費を可能とする。
【0131】
図27は、主要な2つのデバイス、すなわち、グループライセンスデバイス350と消費デバイス356を含む1つの好ましい実施形態を示す。グループライセンスデバイス350は、インストールコンポーネント351と共有コンポーネント352をそれぞれ含む。これは、グループライセンスをインストールしたり、アンインストールしたり、共有ライセンスを作成したりするすべての要求を取り扱う。消費デバイス356は、ライセンスを消費するための消費コンポーネント357を含む。この例示の構成では、インストール追跡コンポーネント(TCI)353、TCS354および委託コンポーネント355は、グループライセンスデバイス350の外部にある。共有認可デバイスは、自身に拘束されたすべてのインストール済みグループライセンスの権利の状態を追跡する。
【0132】
図28は、代替の構成を用いる別の好ましい実施形態を示す。この実施形態では、TCS354はグループライセンスデバイス350の内部にある。この構成では、グループライセンス350は、共有要求を処理して、インストールされたすべてのライセンスの権利の状態を追跡する。したがって、グループライセンスデバイス350は、外部のTCSを必要とすることなく共有要求を認可することが可能である。一旦共有要求が認可されたら、グループライセンスデバイス350は、共有ライセンスを作成してこの共有ライセンスを委託の証明目的で委託デバイス355に対して利用可能とする。
【0133】
図29は、別の代替構成を用いるさらに別の好ましい実施形態を示す。この構成では、TCSコンポーネント354と委託コンポーネント355は双方ともがそれぞれ、グループライセンスデバイス350の内部にある。グループライセンスデバイス350は、すべての共有要求を処理し、インストールされたすべてのグループライセンスの権利の状態を追跡し、デバイスによって生成された共有ライセンスを証明する。これは、現在最新のDRMシステムに統合するには最も実用的な構成である。
【0134】
図30は、企業Aの場合の図29に示す構成のアプリケーションを示す。企業Aのネットワーク内では、グループライセンスデバイス360がグループライセンスサーバ361にインストールされている。グループライセンスデバイス350は、この企業のネットワーク内のすべてのデバイスに対するすべての共有要求の処理専門のデバイスである。グループライセンスサーバ361は、グループライセンスのあらゆるインストール要求を認可する目的でネットワークを介してインストール認可デバイス370を含むインストール認可サーバ369に接続されている。企業Aではまた、共有認可デバイス363をインストールしている認可サーバ362は、この企業内で用いられるグループライセンスの権利のすべての状態を追跡する業務専門となっている。加えて、企業Aのネットワークは、プリンタ364、ワークステーション365、iBook366およびラップトップコンピュータ367などの他のデバイスと、さらにアダプタデバイス368を含む。ネットワーク内での通信は、例えば、ハブ371によって容易化される。
【0135】
追跡コンポーネント
【0136】
どのDRMシステムにも、追跡コンポーネントは存在する。追跡コンポーネントの機能は、権利の使用または状態を追跡することである。本発明内では、追跡とは、グループライセンスのインストールステータスを追跡したり、インストールされたグループライセンスに対する権利の状態を追跡したりすることが含まれる。本発明では、インストールを追跡するコンポーネントをインストール追跡コンポーネント(TCI)と呼び、グループライセンスに対する権利の状態を追跡するコンポーネントを共有追跡コンポーネント(TCS)と呼ぶ。
【0137】
TCIとTCSの機能は、上記と同じまたは別のコンポーネントでも実施可能である。これらの機能は、同じデバイスやサービスまたは別のデバイスやサービスで実施されるように構成可能である。追跡用のデバイスやサービスは、どこに置かれても、動的権利共有をサポートするシステム中の他のコンポーネントによって委託されなければならない。システム内のすべてのコンポーネントによって委託される権限による証明などのこのような委託を確立する多くのメカニズムが知られている。
【0138】
インストール追跡コンポーネント(TCI)
【0139】
このコンポーネントは、インストールされたグループライセンスの権利の初期状態と、インストールされたライセンスの権利の状態を追跡する共有追跡コンポーネントの識別(TCSID)とともにグループライセンスのインストールステータスを追跡する。上述したように、インストールステータスを追跡する目的は、グループライセンスが、その権利の状態を追跡するTCSにしか拘束できないことを保証することである。
【0140】
図31は、どのようにしてインストール要求を追跡するかを示す。このプロセスに対する入力には、グループライセンスとTSCのTCSIDを含む。グループライセンスの整合性と信憑性はステップ400で確認される。整合性は、グループライセンスが変更されたり改竄されたりされていないことを保証するために確認される。信憑性は、グループライセンスがTCIに委託された権限によって発行されたことを保証するために確認される。入力されたグループライセンスが有効で真正であれば、グループライセンスは、ステップ401で、期限切れや取り消しされていないかどうかチェックする。次に、IACはステップ403で追跡情報を検索して、このグループライセンスが現在インストールされているかどうかステップ404でチェックする。グループライセンスが有効でなければ、真正でなければ、期限切れであれば、取り消されていればまたは現在インストールされていれば、この要求はステップ402で拒絶される。そのようでなければ、権利の初期状態がグループライセンスから初期化され、追跡情報がステップ405で作成されて、ステップ406で権利の初期状態で更新される。
【0141】
グループライセンスが以前にはインストールされているが現在はインストールされていない場合、TCIは権利の状態を検証して、グループライセンスに指定されている権利が今は有効であることを保証する。そのようでない場合、インストール要求は拒絶される。
【0142】
追跡情報が見つからないまたはグループライセンスがインストールされたことがないことを示している場合、新しい追跡情報を作成して、権利の初期状態で更新して、この追跡情報をインストール済みであるとマーキングする。グループライセンスが以前にインストールされていて権利がまだ有効である場合、追跡情報はインストール済みであるとマーキングされる。
【0143】
図32は、追跡情報410の好ましい構造を示す。これは、インストールされたグループライセンスもしくはライセンスID411、(アンインストールプロセス中に用いられる)権利の状態を追跡するコンポーネントのTCSID412、現在のインストールステータス413、最初にインストールされたときもしくはアンインストールされたときのグループライセンスに対する権利の状態414およびアプリケーションが必要とする他の情報415を含む。
【0144】
一旦インストール要求が譲与されると、追跡情報に保存されている現在の権利状態が、インストールコンポーネント(IC)である要求元に返却される。その結果、このインストールコンポーネントは、この権利の状態を共有コンポーネント(SC)に渡して、グループライセンスの権利の初期状態を初期化することが可能となる。
【0145】
グループライセンスは、一旦インストールされると、最初にアンインストールされるまでは再度インストールすることは不可能となる。アンインストールプロセスによって、グループライセンスは、その権利の状態を現在追跡しているTCSから解放される。アンインストールプロセスでは、インストールされたグループライセンスまたはライセンスIDと要求メッセージが必要とされる。この要求メッセージは、グループライセンスに対する現在の権利状態を含む認証可能メッセージである。
【0146】
図33は、アンインストールするプロセスを示す。追跡情報が、入力されたグループライセンスまたはライセンスIDを用いてステップ420で検索される。次に、追跡情報がステップ421で検証されて、これが、グループライセンスが現在インストールされていることを示していることを保証する。加えて、ステップ422で、追跡情報に照らし合わせて要求を検証する。追跡情報が見つからなければ、グループライセンスは現在インストールされていないか、または追跡情報が要求に照らし合わせて検証されていない場合、ステップ425で要求は拒絶される。
【0147】
グループライセンスが現在インストールされていれば、ステップ422で、TCSID中に保存されているIDを用いて、要求メッセージを検証する。要求メッセージには、インストールされたグループライセンスに対する現在の権利状態が保存されている。多くの既知のメカニズムを用いて、要求メッセージを検証することが可能である。例えば、要求メッセージをTCSで署名すると、TCSIDがTCSのキーを含み、このキーを用いてTCSの署名を検証する。TCSの署名が検証可能であれば、要求は真正である。そうでなければ、アンインストール要求は信用されない。
【0148】
認証可能なメッセージと証明された現在の権利の状態とが検証されたら、TCIはステップ423で、グループライセンスの現在の権利の状態で追跡情報を更新して、ステップ424で、証明された現在の権利の状態で追跡情報をアンインストールされたものとしてマーキングする。
【0149】
共有追跡コンポーネント(TCS)
【0150】
このコンポーネントは、インストールされたグループライセンスに対する権利の状態を追跡する。グループライセンスは、一旦インストールされると、TCSに拘束される。TCSに拘束されることの利点は、権利の状態がたった1集合だけ維持されるように保証されることである。これによって、多くの様々なグループライセンスデバイスが、グループライセンスに対する権利の状態にコンフリクトを引き起こすことなく権利共有要求を処理して、共有ライセンスを発行することが可能となる。例えば、ホームネットワークにおいて、TCSがインストールされているデバイスに接続可能であればどのグループライセンスデバイスでも、ホームネットワーク中のデバイスで用いられるように共有ライセンスを発行することが可能である。
【0151】
グループライセンスがインストールされると、TCSの認証可能ID(TCSID)が検索されて、TCIに対して利用可能なものとされる。TCSIDは、アンインストール要求メッセージを認証するために後で用いられる。一旦インストールされると、TCIによって返却されたグループライセンスに対する権利の状態を用いて、TCSに保存されている権利の状態を初期化する。さらにセキュリティを高めるため、TCSは、権利の状態と他の情報に、これらをTCSに保存する前にサインする。図34に、TCSに保存する以前にそしてこれらをTCSから検索した後で、権利の状態にサインし、証明し、検証するプロセスを示す。
【0152】
インストールされているグループライセンスがアンインストールされると、TCSは要求メッセージを生成するが、このメッセージは、アンインストールされたグループライセンスに対する現在の権利状態を含む認証可能メッセージである。すると、現在の権利状態がアンインストールの対象となるTCIに渡される。インストールされたライセンスが使用、共有、統合目的で処理された場合はいつでも、TCSは、権利の状態が変化すると、その新しい状態で更新される。
【0153】
一部のアプリケーションでは、権利の状態はTCSがインストールされているデバイスのところには保存されない。権利の状態は、維持されるかどうかとは無関係に、委託可能となるようにTCSによって証明されなければならない。例えば、権利の状態はグループライセンス内に保存可能である。この場合、グループライセンス自体がレポジトリとして動作する。共有ライセンスが作成されたり統合されたりした結果、グループライセンスが変化すると、このグループライセンスも変化する。新しい権利の状態を持つグループライセンスは対象のTCSによって証明されなければならない。証明されたグループライセンスは新たなグループライセンスとなって、以前のグループライセンスに取って代わる。新たなグループライセンスは、一旦作成されると、以前のグループライセンスと同じTCSに拘束され、以前のグループライセンスはTCSから解放される。新しいグループライセンスと以前のグループライセンスは双方とも、同じIDを共有する。この場合、以前のグループライセンスのインストール状態が新しいグループライセンスに転送される。
【0154】
インストールコンポーネント
【0155】
インストールコンポーネントは、グループライセンスをTCIにインストールしたりアンインストールしたり、インストールされたグループライセンスをTCSに対して拘束したりこれから解放したりする。拘束プロセスでは、TCSへのインストールされたグループライセンスに対する権利の状態を初期化し、これで、認可された共有コンポーネントが権利の状態を管理して追跡することが可能となるようにする。TCIにグループライセンスをインストールすることによって、このインストールされたグループライセンスが別のTCSにこれ以上インストールされて拘束されることがあり得ないことを保証する。これによって、グループライセンスに譲与された権利が、複数のTCS上で複製されたり増殖されたりされることを防止する。例えば、映画Aの2つのコピーを譲与するグループライセンスが互いに異なった2つのTCSに拘束されると、TCSはその各々が譲与された権利の状態を2に初期化する。これは、各々のTCSがコピーを2つ共有することを許可し、したがって、グループライセンスの条項と条件に違反することを意味する。
【0156】
グループライセンスが獲得されたりインストールされたりすると、インストール追跡コンポーネント(TCI)のIDをインストールコンポーネントに通信し、これが正しいTCIからのインストールを要求することが可能となるようにしなければならない。発行されたグループライセンス中のTCIのIDやアドレスの符号化、何らかの既知のプロトコルを通じてのTCIのIDやアドレスの獲得、グループライセンス権利の譲与者と被譲与者間の合意の利用など、この通信を実行する方法が多く存在する。一部のアプリケーションでは、TCIは、グループライセンス権利の譲与者のシステムの一部である。TCIがグループライセンス権利の被譲与者のシステムの一部であるアプリケーションもある。さらに、TCIが独立したサービスであるような他のアプリケーションもある。
【0157】
図34に示すように、拘束するプロセスでは、グループライセンスに対する権利の初期状態が、このグループライセンスが拘束されるTCSに登録される。ステップ430および431では、権利の状態の整合性値が計算され、次いで証明される。権利の状態は、一旦初期化されて証明されると、状態レポジトリ432に保存される。次に、TCSは、グループライセンスが使用されるごとに権利の状態を管理して追跡する。一部のアプリケーションや構成では、TCSとTCIの機能が1つのコンポーネントに合成されるが、これらの機能を別々のコンポーネントに分離する他のアプリケーションや構成もある。例えば、組織Y用にグループライセンスを発行するシステムZの認可サーバXがTCIとして動作し、一方、組織Y内の認可サーバZがTCSとして動作する。しかしながら、組織Yの認可サーバZがシステムZによって委託コンプライアンスしていることが証明されると、Zは、TCIとTCS双方として機能することが許可される。
【0158】
上述したように、インストールされると、グループライセンスはTCSに拘束され、権利の状態を初期化して管理することが可能となるようにする。例えば、証明内容はステップ433で検証可能であり、整合性値はステップ434で再計算可能であり、また、整合性値はステップ435で比較可能である。しかしながら、グループライセンスは、共有または使用目的でグループライセンスを処理するデバイスが、グループライセンスの権利の状態を適切に管理可能となるようにTCSと対話可能であるかぎり、いかなるデバイスにも保存することが可能である。
【0159】
以下のセクションでは、グループライセンスのインストールとアンインストールをより詳細に説明する。
【0160】
グループライセンスのインストール
【0161】
インストールプロセスでは、TCIによって認可を要求し、グループライセンスが現在はインストールされていないことを保証し、また、現在の権利状態を獲得するようにしなければならない。インストールプロセスでは、グループライセンスに対する権利の現在の状態でTCSが初期化される。
【0162】
図35は、次のステップからなるグループライセンスをインストールするプロセスを示す。最初のステップ440では、グループライセンスの整合性および信憑性ならびにグループライセンスに対する権利の状態が検証される。グループライセンスの整合性を検証することによってこれが改竄されていないことを保証し、これが信頼すべきソースから発行されたことを保証するグループライセンスの信憑性を検証する。整合性と信憑性を検証する方法は、グループライセンスの表現によって異なる。最も一般的な方法では、デジタル署名を用いてグループライセンスの整合性を保証し、デジタル証明書を用いてグループライセンスの信憑性を保証する。しかしながら、アプリケーションが異なれば、グループライセンスの整合性と信憑性を保証する採用方法も異なる。グループライセンスに対する権利の状態を検証することによって、いずれかの条件の現在状態がこの条件が期限切れであることを示していると判定されると、このグループライセンスはインストール目的で処理されることはない。
【0163】
次のステップ441では、対象とするTCIからの認可を要求する。このステップでは、対象のTCIとTCSを特定する。TCIとTCSの双方が一旦特定されたら、インストール要求が構築される。すると、TCSが認可されて、そのTCSIDが検索されて、インストール要求が構築される。図36に示すように、目標とするTCIによる認可に対する要求は、グループライセンスとTCSのTCSIDとからなる。このTCSIDを後で用いて、アンインストールに対する要求を認証する。TCIは、グループライセンスが譲与される組織の外部またはその一部である。TCIは、要求されたグループライセンスがインストールの要求時にはまだインストールされていないことを検証する。一旦インストール要求が認可されると、グループライセンスに対する現在の権利状態が返却されて、グループライセンスは、アンインストールされるまでは再度インストールすることは不可能である。したがって、インストールすることによって、グループライセンスが複数回インストールされることが効果的に防止される。
【0164】
3番目のステップ442では、目標のTCS付きのインストール済みグループライセンスに対する現在の権利状態が初期化される。TCSは、(グループライセンス中でのように)前もって指定したり、何らかのプロトコルや合意によって獲得することが可能である。TCS付きのインストール済みグループライセンスに対する権利の状態を初期化するプロセスによって、TCSは、グループライセンスに対する権利の状態を、これらの権利が変更される度に追跡することが可能となる。
【0165】
4番目のステップ443では、インストールされたグループライセンスをライセンスレポジトリに保存する。このライセンスレポジトリは、グループライセンスが拘束されるTCSとは独立しているが、ライセンスレポジトリは一部の構成ではTCSの一部である。
【0166】
図36は、インストール要求を構築して認可するプロセスを示す。最初に、グループライセンスのTCIとTCSの双方がステップ450で特定される。この特定が合格すれば、目標となるTCSがステップ451で認証される。目標TCSが認証可能であれば、グループライセンスとインストール要求のTCSIDとがステップ452で構築される。次に、目標TCIがステップ453で認証される。目標TCIが認証可能であれば、次のステップ454でインストールの認可が要求される。要求が認可されれば、インストール要求は合格である。上記のステップのうちのいずれかが不合格であれば、要求はステップ455で不合格となる。
【0167】
グループライセンスのアンインストール
【0168】
アンインストール動作によって、グループライセンスが目標とするTCIからアンインストールされて、TCSが、アンインストールされたグループライセンスを追跡することから解放される。グループライセンスは、一旦アンインストールされたら、再インストールされるまで使用不可能である。このアンインストールプロセスは、アンインストール要求を検証するステップと、目標とするTCSからグループライセンスを追跡することを解放するステップと、グループライセンスをTCIからアンインストールするステップからなる。解放要求が合格すれば、TCSは、アンインストールされたグループライセンスの現在の権利状態付きの認証可能メッセージを返却する。この認証可能メッセージは、次のステップでのアンインストール要求のためにTCIに送られる。加えて、アンインストール要求には、グループライセンスもしくはグループライセンスIDおよび、権利の証明済み現在状態を含むTCSによって返却された認証可能メッセージが含まれている。TCIは、以前にはTCIに保存されていたTCSのTCSIDを用いて、TCSの認証可能メッセージと現在の権利状態とを検証する。要求が合格すれば、TCIは追跡情報を更新して、グループライセンスが権利の証明済み現在状態によってアンインストールされたことを示す。グループライセンスがTCIで現在インストールされていないまたは認証可能メッセージが検証不可能であれば、アンインストール要求は不合格となる。
【0169】
共有コンポーネント
【0170】
共有コンポーネントは、認可された主体による共有または使用のために共有ライセンスを作成(導出)して、これら共有ライセンスを統合して、導出されたインストール済みグループライセンスに戻す。
【0171】
共有ライセンスを作成して統合するプロセスでは、インストールされたグループライセンスが拘束されるTCSを認可する必要がある。TCSは、共有コンポーネントが共有要求をグループライセンスに照らし合わせて確認するために必要とするインストール済みグループライセンスの権利の状態を管理する。現在の権利状態が、共有要求が許可されたことを示していれば、共有ライセンスが作成されて、必要であれば委託の証明目的で委託コンポーネントに対して利用可能とされる。次に、グループライセンスの現在の権利状態を更新して、新たに作成された共有ライセンス中の権利の状態と初期状態を反映するようにする。
【0172】
共有要求次第で、様々な方法を用いて、上述したように、共有ライセンス中の権利の状態と初期状態とを作成し、また、インストールされたグループライセンスの現在の権利状態を更新する。
【0173】
共有ライセンスを返却して発信元であるグループライセンスに統合する場合、共有コンポーネントは統合要求と、この共有ライセンスの返却先であるグループライセンスを確認する。返却が許可されると、共有コンポーネントはこの要求を、グループライセンスが拘束されているTCSに送って、グループライセンスの現在の権利状態を更新する。
【0174】
以下のセクションでは、共有ライセンスを導出するプロセスと、共有ライセンスを統合して発信元のインストール済みグループライセンスに戻すプロセスをより詳細に説明する。
【0175】
権利の導出
【0176】
権利の導出とは、インストールされたグループライセンスから共有ライセンスを作成するプロセスである。共有要求は、権利の被譲与者から直接にまたは共有ライセンスが消費される予定のデバイスから間接的に来る。対象となる消費デバイスが要求時には知られていない場合、要求に起因する共有ライセンスはどの消費デバイスにも拘束されない。この場合、共有ライセンスは、これが消費またはさらなる共有目的で使用可能となる以前に拘束されなければならない。
【0177】
図37は、一般的に共有要求の一部である情報460を示す。要求タイプ461は、この要求が権利の導出要求または統合要求を示す。導出はサブ権利を作成する要求である。統合はサブ権利を返却する要求である。要求側のデバイスの情報462は権利消費デバイスを特定し、このデバイスが要求されているサブ権利を受領することを認可されていることを検証するために用いられる。デバイス情報はオプションである。要求された権利の情報463は、グループライセンスから共有されるべき権利を特定する。利用可能ライセンス464には、要求を譲与するグループライセンスと、要求を認可し、また、要求を満足させるためにライセンスを発行するために必要な他のライセンスが含まれる。
【0178】
共有要求を受信すると、権利消費デバイスは、この要求を満足するライセンスを発生しようとして機能の集合を実行する。このような機能には、要求を対象グループライセンスに照らし合わせて検証する機能、グループライセンスと関連のライセンスとを検証する機能、目標TCSに対して共有要求と関連するグループライセンスの現在の権利状態を要求する機能、要求を処理する機能および認可されたら共有ライセンスを作成する機能が含まれる。要求が認可されたら、TCS中の目標グループライセンスの権利の状態が、発信元のグループライセンス中の現在の権利状態と共有ライセンス中の権利の初期状態とにしたがって更新される。
【0179】
図38は、共有コンポーネントが共有要求を受信することで始まって、共有権利を含むライセンスを出力することで終了する共有要求処理の例示のデータフローを示す。このプロセスは多くのコンポーネントからなるが、これらはサブプロセスとデータベースである。このプロセス全体またはそのコンポーネントのいずれかは、共有コンポーネントが置かれているグループライセンスデバイスに常駐している。
【0180】
要求が消費デバイスコンポーネント470からグループライセンスデバイス471に送られ、ここで、一般的には処理される。グループライセンスデバイス471は、共有要求を処理する責任を負っている共有コンポーネントを含む。共有要求を受信すると、グループライセンスデバイスは、目標グループライセンスを、これを要求からまたはレポジトリ472から抽出することによって位置付ける。目標のグループライセンスと要求を確認して、その信憑性と整合性をステップ473で保証する。目標消費デバイスの識別に関する情報は、要求から抽出されて検証され、消費デバイスがこのような要求をすることを認可されることを保証する。目標消費デバイスは通常は、要求をする第2のデバイスである。
【0181】
要求は目標TCSから現在の権利状態に対して、共有要求はステップ474で処理される。この要求が認可されると、権利がステップ475で導出されて、この導出権利の状態477が状態マネージャ476によって更新される。図39は、権利を導出するプロセスを示す。
【0182】
権利の導出には次のステップが含まれる。
要求に適合するグループライセンスと共有可能権利を位置付けするステップ。このステップは、要求を確認するステップと、グループライセンスを位置付けするステップと、共有可能権利を特定するステップと、ライセンスを確認するステップなどを含む、
目標の共有可能権利と関連付けられた状態の集合を特定するステップと、
要求を、目標の共有可能現在の権利状態とオリジナルの状態とに照らし合わせて確認するステップと、
共有権利を作成するステップと、
共有権利を含むライセンスを作成するステップ。このライセンスは、認可されたメンバーが、グループの他のメンバーのために共有権利を作成することを許可する新しいグループライセンスであり得る。
【0183】
図39に示すように、ステップ480では、入力されたライセンスからライセンスを獲得し、また、このライセンスが共有要求を適合したことをステップ481で確認する。適合しなければ、ステップ482で、処理すべきライセンスがまだあるかどうか判定する。処理すべきライセンスがなければ、ステップ488で空(ヌル:null)という出力を返却する。ライセンスが要求と適合すれば、次のステップ483で、ライセンスから権利を獲得し、ステップ484で、この権利が分割可能であるか判定する。可能であれば、ステップ485で、この分割可能権利の分割である権利を導出する。次に、分割された権利、または分割不可能権利をステップ486で出力ライセンスに挿入する。次に、ステップ487で、処理すべき権利がまだあるかどうか判定する。なければ、出力ライセンスはステップ488で返却される。
【0184】
権利の統合
【0185】
権利の統合とは、共有ライセンスを発信元のグループライセンスに戻して統合して、その結果として新たなグループライセンスを作成するプロセスである。この権利統合プロセスは、上に開示した権利導出プロセスと類似している。権利導出と権利統合間との相違は、次の通りである。
権利の統合の場合、目標のグループライセンスに対する権利の状態が、より多くの権利を反映するように更新される。
権利の導出の場合、統合された共有ライセンスは無効となる。
導出が正しく行われた場合、新しい共有ライセンスが作成される。
【0186】
消費コンポーネント
【0187】
消費コンポーネントは消費ライセンスを消費する。上記に開示したように、消費ライセンスはまた共有ライセンスでもある。しかしながら、消費ライセンスは、共有目的ではなくて使用目的のものである。消費ライセンスを消費するには認可が必要であり、このような認可は、あらゆるDRMシステムで指定される既知のプロセスである。認可プロセスは、ライセンスに照らし合わせて要求を確認するステップと、ユーザとデバイスを認証するステップと、要求を条件の現在状態に照らし合わせて検証するステップと、使用認可された場合に条件の現在状態を更新するステップなどを含む。
【0188】
消費ライセンスは、期限切れになるまでまたは消費デバイスによって解放されるまで消費デバイスによって消費される。消費ライセンスは、一旦解放されれば、共有コンポーネントに送って、その導出元であるグループライセンスに戻して統合することが可能である。
【技術分野】
【0001】
本発明は、DRM(デジタル権利管理)の分野およびデジタルリソース管理に関し、詳しくは、権利およびリソースの分配および共有に関する。
【背景技術】
【0002】
現在の最新のDRMシステムでは、人間であったりデバイスやサービスなどの人間以外のエンティティであったりする潜在的ユーザの集合で権利を共有する機能は、市販のプロダクツで利用可能である。譲与された権利の集合とこれらの権利を共有する方法は一般的にはライセンスという形態で指定される。
【0003】
権利の共有専用のライセンスの1つの形態は、並列ユーザライセンス(サイトライセンスまたはネットワークライセンスとしても知られている)と呼ばれる。並列ユーザライセンスは、ネットワークサーバに拘束されているライセンスのプールを表し、このネットワーク上のユーザだけがこのライセンスにアクセスすることが可能であり、これに同時にアクセス可能なユーザの数は限られる。
【0004】
並列ユーザライセンスの従来型の実施例では、ライセンスにアクセス可能なユーザ各々に、このライセンスに指定されているすべての権利が譲与されている、すなわち、ユーザすべてが同じ権利を有する。Macrovision FLEXnetによるこのタイプのライセンスのより進歩した実施例では、並列ユーザライセンスのユーザは、権利の集合を動的に共有することが許可される。このライセンスは、ユーザ各々が有することが可能な権利の集合を指定する代わりに、すべてのユーザが共有することが可能な権利の最大集合を指定する。これらの権利をどのように共有するかは、ライセンスの購入者次第であり、したがって、オプションファイルとソフトウエアプラグインモジュールとからなるカスタムアクセス制御メカニズムを用いて構成することが可能である。このオプションファイルを用いると、特に、特定の一人もしくは複数のユーザのためのライセンスプールで利用可能な多くのライセンスの予約、ユーザもしくはユーザグループがアクセス可能なある特定の特徴的機能の予約およびオフラインで使用する目的でこのプールからあるライセンスを誰が借用することが可能であるかの規定を制御することが可能である。このオプションファイルによってサポートされる特徴的機能の一部を解説すると、「RESERVE1インストールUSERロバート」は「ロバート」というユーザに対して「インストール」という特徴的機能の1つのライセンスを予約し、「RESERVE4プレイGROUPアカウンティング」は、アカウンティンググループがコンテンツをプレイするためのライセンスを予約し、「INCLUDE_BORROWプレイUSERトム」は、特徴的機能「プレイ」を借用することが可能なユーザのリストに「トム」というユーザを含む。共有することに加えて、オプションファイルには、使用を報告するオプションが含まれている。これは、事実上、ライセンスが、使用を追跡するという条件をユーザに課す方法である。あるユーザがコンテンツにアクセス可能であるかどうかを判定する認可プロセスでは、オプションファイルをプラグインが処理して合成応答を発生している間に、このライセンスを一般的ライセンスマネージャが処理する。
【0005】
Macrovision FLEXnetの方式では、ユーザには、自分の必要にしたがって権利の共有を制御する特別のメカニズムが提供されるが、それには限度があることは否定できない。例えば、そのライセンスはネットワークサーバに拘束され、このネットワーク上のユーザだけがこのライセンスにアクセスまたはこれを借用することが可能である。また、オプションファイルは人間によって構成され、エラーが発生しやすい。例えば、アドミニストレータは、ある部門内の様々なグループに対してライセンスを予約している場合に、予約されたライセンスの数がプールのキャパシティを超えるようなミスを犯すことがあり得る。このミスが気付かれないままとなって、あるグループが、結局予測していたより少ないライセンスしか共有できないことになるという結果になりかねない。オプションファイル(および、それゆえの共有分配)は明瞭なテキストファイルである。これはアドミニストレータのパスワードでしか保護されていないものである。ライセンスサーバは、ライセンスに対して実施するのと同じ権利管理タスクを実行することは不可能であるが、このタスクとは、信憑性とオプションの整合性とを検証することである。加えて、ライセンスよりもオプションファイルに基づいてアクセスを制御するため、コンテンツの携帯性が制限されるが、これは、上述のアクセス制御メカニズムが存在しないと、コンテンツにアクセスすることが不可能であるためである。コンテンツがペリメータ(ネットワークサーバのドメイン)から離れると、意図したアクセス制御はもはや当てはまらない。
【0006】
使用を報告するというハードコーディングされたオプションは、ライセンスの購入者がライセンスのユーザに対して課すことを希望することが考えられる条件のうちの1つに過ぎない。ライセンスの購入者は、自分自身の条件を分配された権利に追加することが可能であるべきである。カスタムアクセス制御メカニズムは、委譲の1レベルをサポートするだけである。アドミニストレータだけが、これ以上自分の権利を分配することが不可能なネットワークユーザに対して権利を分配することが可能である。この委譲は、マルチレベルの委譲を必要とする階層構造には適していない。共有は、アクセス態様またはある行動の制御に焦点が合わされる。これは、規則やポリシーによって管理される汎用のリソース共有メカニズムではない。その設計は、ソフトウエアプログラムの動作を制御することにその重点がある。文書、オーディオファイル、ビデオファイルなどの他のタイプのデジタルリソースの制御を意図するものではない。
【0007】
個人的ドメイン内での共有を可能とする別の形態のライセンスは、典型的にはエンドユーザライセンスと呼ばれるものである。このタイプのライセンスでは、ライセンス自体が、デバイスIDやユーザIDなどの特定の環境に拘束されていることが必要である。共有は、権利の所有者によってサポートされているビジネスモデルによって、特定の集合のデバイスタイプおよび/または最大数のデバイス内での共有に限られる。すべての共有デバイスが同じ権利を有するかまたは、各々のデバイスがそれ自体の別個の集合の権利を有するかのどちらかである。
【0008】
エンドユーザライセンスの1つの例では、マイクロソフトのWindows(登録商標)のメディア権利管理システム(Microsoft Windows(登録商標) Media Rights Management System)は、自分のパソコン上でコンテンツをプレイして他のデバイスにコンテンツを転送する権利を含む権利集合を、コンテンツの購入者に対して譲与してよい。このような転送権利には、このコンテンツを受信する資格があるデバイスのタイプと、このようなデバイスに対するいくつかの所定の権利とが指定される。転送された結果、さらに、パソコン上のライセンスにしたがって、対象デバイスは各々が、それ自体の別個の権利集合を有することになる。
【0009】
別の例では、リアルネットワークへリックスDRM(Real Networks Helix DRM)は、パソコン、セットトップボックス、ホームメディアサーバ、携帯電話などのあらゆるネットワーク接続されたデバイス(ネイティブデバイス(Native Device)と呼ばれる)に対して、自分自身のコンテンツとライセンスを獲得する能力を提案する。へリックスデバイスDRMは、ネイティブデバイスから、データの転送とこのデータに対するビジネス規則の執行とを目的としてネイティブデバイスに対する接続を必要としているデバイスであるセキュア受信機デバイスへの転送をサポートする。セキュア受信機デバイスの例には、専用音楽プレイヤや専用ビデオプレイヤが含まれる。セキュア受信機デバイス上で利用可能なのは再生権利だけである。
【0010】
さらに別の例では、FLEXnetのノードロックライセンスを特定のデバイスに拘束しておいて、このデバイスのみ上でこのライセンスを消費させるようにすることが可能であったり、または、特定のユーザ名に拘束しておいて、このライセンスを消費するデバイスが同じユーザ名を有していなければならないようにすることが可能である。この2つの要件のうち、前者は共有を許可しないのに対して、後者は同じユーザ名を有するデバイス間での共有を許可しているが、デバイスは名前で区別するのが好ましいため、これはあまり実用的ではない。
【0011】
さらに別の例では、FLEXnetモバイルライセンスはFLEXnet IDに拘束される。FLEXnet IDを含むハードウエア(ドングル)は、認可されたユーザがライセンスを新しいデバイス上で消費することを決定すれば、この新しいデバイスに移動させなければならない。
【0012】
したがって、エンドユーザライセンスによって許可された共有方式では、ユーザが、獲得した権利を、自分が適していると見なす何らかの方法で用いることが可能な最大限の権利として用いることは許可されない。
【発明の概要】
【発明が解決しようとする課題】
【0013】
このため、ユーザが、自分達の必要性にしたがって権利を共有することを可能とする動的権利共有をサポートするシステムに対する必要性が存在する。このシステムでは、獲得されたライセンスは権利のプールを表しているが、ここで、各々の権利をさらにサブ権利に分割することが可能である。サブ権利とは、権利を分配する単位である。
【課題を解決するための手段】
【0014】
本発明は、権利からサブ権利を導出する方法に関するが、この権利は複数のコンポーネントを含み、これらコンポーネントはその各々が、権利の態様を指定している。本方法は一般的に、サブ権利を受信するステップであって、前記サブ権利が前記コンポーネントのうちの少なくとも1つを含み、前記コンポーネントの各々が前記サブ権利の態様を指定するステップと、前記サブ権利の前記コンポーネントの値が前記権利のうちの対応しているコンポーネントの値から導出することが可能であることを確認するステップと、を含む。コンポーネントは、例えば、主役、動作、リソースおよび条件であってよい。
【0015】
本発明はまた、第1の権利を第2の権利と統合する方法に関する。この場合、本方法は、前記第1の権利のコンポーネントの各々がこれに対応する前記第2の権利のコンポーネントから導出することが可能であることを検証することによって、前記第1の権利が前記第2の権利から導出可能であることを判定するステップと、前記第1の権利を前記第2の権利のうちの前記対応するコンポーネントと合成するステップを含む。
【0016】
さらに、本発明は権利を共有する方法に関する。本方法は、権利からサブ権利を導出し、前記サブ権利の使用を許可し、前記サブ権利を前記権利と統合するステップを含む。その結果、サブ権利は、共有目的でさらに導出することが可能である。加えて、権利はライセンス中に指定されることがあり、本方法はさらに、デバイス上で前記ライセンスをインストールするステップと、前記ライセンスをアンインストールするステップと、これらのライセンスを他のインストール動作に利用可能とするステップを含むことができる。
【0017】
加えて、本発明は、権利からサブ権利を導出することを可能とすることによって権利共有をサポートするシステムに関するが、この権利は複数のコンポーネントを含み、このコンポーネント各々がこの権利の態様を指定し、前記システムは、サブ権利を受信するための受信モジュールであって、前記サブ権利が、各々が前記サブ権利の態様を指定する複数のコンポーネントを含む受信モジュールと、前記サブ権利の前記コンポーネントの値が前記権利のうちの対応するコンポーネントの値から導出可能であることを確認するための確認モジュールを備える。本システムはさらに、グループライセンスをデバイス上にインストールし、これを共有目的に対して利用可能とし、インストールされたグループライセンスをアンインストールし、これを現在のデバイス上での共有目的に対しては利用不可能とするためのインストールモジュールと、前記インストールされた/アンインストールされたグループライセンスを追跡するインストール追跡モジュールと、グループライセンスの権利の状態を追跡する追跡モジュールと、共有モジュールを備える。
【0018】
本発明はさらに、譲与者から被譲与者に譲与された権利のプールからサブ権利を導出し、これによって、計算環境内でのリソースの使用を制御する方法に関するが、この計算環境は、この権利にしたがってリソースの使用を制御するためにこの環境内で権利を執行するメカニズムを有し、前記方法は、被譲与者が譲与者から権利のプールを受信し、前記権利のプールが少なくとも1つのリソースと関連付けられ、前記被譲与者が前記権利のプールを1つ以上の権利コンポーネントに解析し、前記権利コンポーネントの各々が前記権利プールの態様を指定し、前記権利コンポーネントのうちの少なくとも1つからサブ権利コンポーネントを導出し、前記サブ権利コンポーネントが対応する権利コンポーネントの部分集合であり、前記サブ権利コンポーネントからサブ権利を指定するライセンスを作成することを含み、前記ライセンスが、前記サブ権利に従って、また、前記権利のプールの範囲内で前記リソースの使用を制御するために前記計算環境によって執行することが可能である。本方法はさらに、前記ライセンスをサブ被譲与者に譲与するステップと、前記サブ被譲与者によって前記ライセンス中の前記権利を権利のサブプールとして1つ以上の第2の権利コンポーネントに解析するステップであり、前記第2の権利コンポーネントの各々が前記権利のサブプールの態様を指定するステップと、前記第2の権利コンポーネントのうちの少なくとも1つから第2のサブ権利コンポーネントを導出するステップであり、前記第2のサブ権利コンポーネントが対応する第2の権利コンポーネントの部分集合であるステップと、前記第2のサブ権利コンポーネントからサブサブ権利を指定するサブライセンスを作成するステップであり、前記サブライセンスが、前記サブサブ権利に従って、および前記権利のサブプールの範囲内で前記リソースの使用を制御するために前記計算環境によって執行することが可能であるステップを含む。
【0019】
サブ権利について開示されている概念を解説するために、電子書籍(本)を5回プレイする権利を検討する。この権利のサブ権利とは、電子書籍をn回プレイする権利(ここで、0<n<5)であり得る。プールのキャパシティ以内で共有される限りでは、このシステムは、ユーザが、獲得した権利を自由に分割して分配することを許可するが、これは、権利が同じネットワーク上のユーザに分配されるか互いに別々のネットワーク上のユーザに分配されるか、前記分配された権利が受信者によって消費されるか、または、他の認可済みのエンティティにさらに分配されるかとは無関係である。本システムは、権利をサブ権利に分割して、サブ権利の残余の部分を統合して、他者が使用するようにプールに戻す方法などの、権利のプールを維持するメカニズムを提供する。
【図面の簡単な説明】
【0020】
【図1】譲与された権利のデータモデルと擬似表現言語との間のマッピングを示す。
【図2】擬似表現言語における無条件権利を示す。
【図3】プレイの回数に対する条件が付いた譲与権利を示す。
【図4】時間条件付きの譲与権利を示す。
【図5】2つ以上の条件が付いた譲与権利を示す。
【図6】図2に示す譲与権利をMPEG−RELで表現したものを示す。
【図7】図3に示す譲与権利をMPEG−RELで表現したものを示す。
【図8】図4に示す譲与権利をMPEG−RELで表現したものを示す。
【図9】図5に示す譲与権利をMPEG−RELで表現したものを示す。
【図10】主体に基づいて、図4に示す譲与権利から導出された権利を示す。
【図11】主体および条件に基づいて、図4に示す譲与権利から導出された権利を示す。
【図12】指定された主体に基づいて譲与権利から権利を導出するプロセスを示す。
【図13】条件に基づいて譲与権利から権利を導出するプロセスを示す。
【図14】新しい権利が分割可能権利から導出されるシナリオを示す。
【図15】新しい権利が無条件並列権利から導出されるシナリオを示す。
【図16】新しい権利が条件付き並列権利から導出されるシナリオを示す。
【図17】新しい権利が共有可能権利から導出されるシナリオを示す。
【図18】グループライセンスを示す。
【図19】新しいグループライセンスがグループライセンスから導出されるシナリオを示す。
【図20】第2世代グループライセンスを導出するプロセスを示す。
【図21】権利がグループライセンスに返却されるシナリオを示す。
【図22】図18に示すグループライセンスをMPEG RELで表現したものを示す。
【図23】図19に示すグループライセンスをMPEG−RELで表現したものを示す。
【図24】グループライセンスの導出階層を示す。
【図25】一般的なDRMシステムを示す。
【図26】動的な共有権利をサポートする基本的なコンポーネントを示す。
【図27】共有権利をサポートする基本的コンポーネントの1つの可能性のある構成を示す。
【図28】共有権利をサポートする基本的コンポーネントの1つの可能性のある構成を示す。
【図29】共有権利をサポートする基本的コンポーネントの1つの可能性のある構成を示す。
【図30】企業アプリケーション用の基本的コンポーネントの1つの可能性のある構成を示す。
【図31】グループライセンスをインストールするプロセスを示す。
【図32】情報を追跡する好ましい構造を示す。
【図33】グループライセンスをアンインストールするプロセスを示す。
【図34】権利の状態を証明して検証するプロセスを示す。
【図35】グループライセンスをインストールするプロセスを示す。
【図36】インストール要求を構築して認可するプロセスを示す。
【図37】一般的に共有要求の一部である情報を示す。
【図38】共有要求を処理する例示のデータフローを示す。
【図39】権利を導出するプロセスを示す。
【発明を実施するための形態】
【0021】
定義
【0022】
権利とは、指定された状況または条件の集合の下で、一般的にはリソースに対して権利の被譲与者が動作または活動を実行するステートメントを表す。
【0023】
権利表記(rights expression)とは、権利をデジタル形態で明示したものである。権利表記の例としては、これに限られないが、ISO MPEG REL、XrML、SAML、XACML、ODRL、OMA RELなどのXMLベースの権利表記言語や、データ構造や、ビットフィールドがある。
【0024】
ライセンスとは、権利表記を用いて捕獲された規則の表現である。ライセンスは、譲与された権利の完全な文脈を伝えている。ライセンス中で捕獲されている情報には、権利の譲与者、権利の被譲与者、リソース、許可ならびに関連する条項および条件が含まれている。
【0025】
リソースとは、アクセス、使用、操作および/または分配が規則またはポリシーの集合によって管理され統御されるようなあらゆるコンテンツ、サービス、さらに権利さえも表すものである。
【0026】
本開示に定義される動的な権利共有によって、権利の譲与者の決定権に対抗する権利の被譲与者の決定権において共有する能力が可能とされる。権利の譲与者は、権利の限度を指定する。この限度を示す条件内で、権利の被譲与者は、特定の権利共有メカニズムを決定することが可能である。権利の被譲与者はまた、多段階権利譲与連鎖においては譲与者でもあり得る。
【0027】
権利の共有とは、譲与された権利をサブ権利に分割することを含む。次に、サブ権利がサブ被譲与者の集合に発行される。帰納的に、各々の被譲与者またはサブ譲与者はさらに、譲与連鎖を下るにつれて、他のサブ被譲与者とサブ権利を共有することが可能である。例えば、中心ライブラリXは、ある本30冊に対する権利を購入する。次に、ライブラリXはこの30冊のうちの10冊を自分の姉妹ライブラリYに分配する。したがって、ライブラリXは、権利の譲与者として動作して、10冊に対するサブ権利をライブラリYに発行する。ライブラリXから10冊を受領すると、ライブラリYはさらに、このうちの3冊をそのローカルライブラリZのうちの1つと共有する。
【0028】
本発明の第1の態様は、権利をサブ権利に導出して、サブ権利を、これらの導出元であるオリジナルの権利に統合して戻す方法である。本発明全体を通じて、サブ権利は導出された権利とも呼ばれる。権利の導出と統合は、権利を権利の被譲与者間で共有する基本的メカニズムとして働く。権利の被譲与者は、新しいサブ権利を導出することによって自分の権利を他者と共有する。その結果、新しいサブ権利の被譲与者は各々が、サブ権利を消費したり他者とさらに共有したりすることが可能となる。
【0029】
本発明の第2の態様はグループライセンスであり、これは、一人以上の権利被譲与者の集合に対して最大限の権利を譲与して、これらの権利をこれら被譲与者間で動的に共有することを許可するシステム内で用いられる。グループライセンスの共有メカニズムは、サブ権利を導出して、これらサブ権利を含む共有ライセンスを発行する能力に基づいている。共有ライセンスとは、自分自身が、さらに共有可能なグループライセンスであり得る。したがって、グループライセンスは動的で多段階の権利共有をサポートする。
【0030】
本発明の第3の態様は、権利被譲与者のグループ間で、および権利被譲与者のグループ全体にわたって権利を共有し、また、多段階に権利を共有することをサポートするためのグループライセンスを実施するシステムである。この開示されるシステムは、権利の消費を認可して、権利の使用と状態を追跡することが可能ないかなるDRMシステム中でも実施することが可能である。
【0031】
本発明は第1に、所与の権利からサブ権利を導出する方法を開示する。この方法は、サブ権利が、これらサブ権利の導出元であるオリジナルの権利の限度内であることを保証する。本方法は、動的権利共有システム中で権利の分割目的で用いることが可能である。
【0032】
各々のサブ権利は、次の一人の(または複数の)権利被譲与者に対して、このサブ権利の導出元である権利の一部分または全体を譲与する。その結果、各々のサブ権利の消費が、このサブ権利の導出元の権利とも、また、他のサブ権利とも無関係に認可される。したがって、サブ権利を導出する能力は、動的権利共有のための基本的メカニズムである。
【0033】
本発明はまた、グループライセンスと呼ばれる新しい概念を提示する。グループライセンスとは、一人以上の被譲与者に対して最大限の権利を譲与して、これら被譲与者による共有がこのグループライセンスによって許可された場合に、これらの被譲与者が、これら譲与された権利をこのような共有のポリシーにしたがって共有することを許可するライセンスのことである。このような共有がグループライセンスによって許可される場合には、共有するメンバーをこれら被譲与者以外にも拡大して、他の認可済みのユーザを含むようにしてもよい。
【0034】
グループライセンスのセマンティックスでは、サブ権利の指定を導出する開示の方法が採用される。グループライセンスシステムは、サブ権利をライセンス発行認可プロセスの一部として導出し得る。グループライセンスシステムは、サブ権利が発行の時点でライセンスの限度内にある場合にだけ、これらサブ権利を含むライセンスの発行を認可する。この発行されたライセンスを被譲与者が用いたり、またはさらに分割したりして、グループライセンスを含むようにすることが可能である。加えて、グループライセンスのセマンティックスは、サブ権利の未使用の部分を統合して、サブ権利の導出元である権利に戻すことをサポートしている。
【0035】
本発明はまた、権利の被譲与者間での動的な共有目的でグループライセンスを処理する例示のシステムを提示する。本システムはまた、未使用の共有権利を再統合してグループライセンスに戻す能力を有する。本開示のシステムは、様々な構成で設計して、権利の認可と追跡をサポートするDRMシステムに統合することが可能な基本的コンポーネントの集合を含む。この好ましい例示のシステムに加えて、開示の概念を組み込んだ他の実施例を設計することが可能である。
【0036】
共有のための権利を導出する方法
【0037】
現行の権利共有メカニズムは、特定の用途向けに具体的に実現されるか、中心的認可によって共有を制御することを必要とするか、特定の環境内で共有することを必要とするかのいずれかである。このような共有方式では、権利の被譲与者が自身の権利を共有する機能が制限される。本発明は、権利の導出に基づいた新しい共有方法を開示する。本開示方法によって、権利を権利の被譲与者間で動的に共有することが可能となり、また、共有された権利をさらに他の権利被譲与者と共有することが可能となる。本開示方法は汎用性があり、権利とリソースを共有することを必要とするいかなるシステムにも適用可能である。
【0038】
本発明は、最初に、権利の既存の実施例にマッピングすることが可能な権利の一般的なデータモデルを導入する。次に、本発明は、譲与された権利からサブ権利を導出して、サブ権利を統合してオリジナルの譲与された権利に戻す方法を開示する。権利を導出する方法と共に、本発明はまた、本開示の方法をどのように現行の共有方式に応用してその限界の一部に対処するかを記述する。
【0039】
権利のデータモデル
【0040】
権利の一般的なデータモデルuは次のように表される。
u=(p,a,r,c)
ここで、
pは、動作aが譲与される対象である主体、主体の集合または匿名の主体である。したがって、pは一人以上の権利の被譲与者である。
aは、pが実行することを許可された動作または活動であり、
rは、動作aと関連付けられたリソースであり、
c={ci|i=0..n}は、pがrに対してaを実行する指定された状況を構成する条件の集合である。ciはuと関連付けられた条項および条件と呼ばれる。
【0041】
u中に指定されているp、a、rおよびciはその各々が、譲与された権利uのコンポーネントと呼ばれる。解説目的で、この一般的データモデルは、次の擬似表現言語にマッピング可能とされる。
GRANTED RIGHTS(譲与された権利)
PRINCIPAL p(主体p)
ACTION a(動作a)
RESOURCE r(リソースr)
CONDITIONS c(条件c)
【0042】
図1に、権利u(100)のデータモデルと上記の擬似表現言語101との間のマッピングを示すが、ここで、譲与された権利uは表現「GRANTED RIGHTS(譲与された権利)」にマッピングされ、主体pは表現「PRINCIPAL p(主体p)」にマッピングされ、動作aは表現「RIGHTS a(権利a)」にマッピングされ、リソースrは表現「RESOURCE r(リソースr)」にマッピングされ、条件cは表現「CONDITIONS c(条件c)」にマッピングされている。
【0043】
この権利のデータモデルはまた、一般目的用のリソース共有にも適している。aを「使用する」や「所有する」などの一般的動作として定義すると、本発明の開示するデータモデルやシステムおよび方法を用いて、c中に指定されている条件によって統御される広範囲のリソース共有を達成することが可能である。この場合、権利u中に指定されている動作aはどのような用途にも応用される。その結果、本発明の残りの部分に開示される共有システムと共有方法は、リソースを共有するシステムおよび方法と見なすことが可能である。例えば、計算リソースの所有者が、CPUサイクルを共有して、学問的研究のプロジェクトに対する並行処理を容易化することを意図する。この所有者は、委託された同僚がCPUのアイドルサイクルを用いて実行する特定のタイプのプログラムを知りたいとは思わない。この使用シナリオでは、所有者は、主体pを委託された研究コミュニティ内のいずれかのメンバーとして、動作aをいずれかの使用として、リソースrをCPUサイクルとして、条件cを10pm〜6amのいずれかの時点として定義している権利uを発行する。この譲与された権利によって、委託された研究コミュニティのメンバーは、10pm〜6amでのCPUサイクルを共有することを許可される。この例では、共有される第一の対象は、動作aではなくてリソースrである。
【0044】
本明細書に記載する以下の図面は、上記の擬似表現言語で表現された譲与権利の例を示すものである。図2は、アリス(Alice)であると特定された主体に、「風とともに去りぬ(Gone With The Wind)」というタイトルのDVDを見る(View)権利が譲与されるという、条件を有さない譲与権利120を示す。図3は、1つの条件が付いた譲与権利130を示す。音楽クラブ(Music Club)と特定された主体に、ルイ・アームストロング(Louis Armstrong)の「この素晴らしい世界(What a wonderful world)」というCDをプレイ(Play)する権利が譲与される。この譲与された権利には、このCDのプレイ回数(Number of Play)を100回に制限する条件131が付いている。図4は、1つの条件付きの譲与権利140を示す。音楽クラブと特定された主体に、ルイ・アームストロングの「この素晴らしい世界」というCDをプレイする権利が譲与される。この譲与された権利には、このCDをプレイすることが許される期間を2006年1月までに制限する条件141(Not after Jan. 2006)が付いている。図5は、2つの条件が付いた譲与権利150を示す。音楽クラブと特定された主体に、ルイ・アームストロングの「この素晴らしい世界」というCDをプレイする権利が譲与される。この譲与権利には、このCDをプレイする回数を100回に制限する条件151と、このCDをプレイすることを許される期間を2006年1月までとする条件152が付いている。
【0045】
上記の擬似表現言語は例示目的で本発明の全般にわたって用いられているが、本発明は、いずれの特定の権利表記言語も、データ構造も、表現などにも制限されるものではない。
【0046】
権利のデータモデルは、多目的のものであり、どのような形態の権利表記をもモデリングすることが可能である。例えば、図6、7、8および9では、図2、3、4および5とそれぞれ同じ譲与権利を表現するのにMPEG REL(125、135、145および155)を用いる。
【0047】
別の例では、上記の権利データモデルを用いて、コピー絶対禁止、コピー自由、1世代コピーなどの保護されたコンテンツの保護状態を表す2ビットであるコピー制御情報ビット(CCIビット)の構造を次のようにモデリングすることが可能である。
u=(p=null,a=CCI,r=null,c)
ここで、pはコンテンツを受信するデバイスを意味し、aはコピー動作であり、rはCCIビットが関連付けられているコンテンツを意味し、条件cはコピー動作に対する制限である。このような制限には、コピー絶対禁止、コピー自由、1世代コピーなどが含まれる。
【0048】
第3の例では、次のFLEXnetライセンスは、ライセンスサーバマシン「lulu」にアクセス可能なすべてのデバイスに対して、特徴「f1」に対する2つのライセンス、特徴「f2」に対する6つのライセンスおよび特徴「f3」に対する1つのライセンスを譲与する。
「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:2005年1月1日
SIGN:サイン
signature:著名
【0049】
上記の権利データモデルを用いると、上記のFLEXnetライセンスを、次のように互いに別個の3つ権利にマッピングすることが可能である。主体pは、FLEXnetフロートライセンス中の認可サーバのホストIDまたはFLEXnet特徴が拘束されるノードのホストIDである。上記のFLEXnetの例では、主体pは、ライセンスサーバ「lulu」にアクセス可能なすべてのデバイスである。動作aは、FLEXnetライセンスの特徴(FEATURE)ラインに指定されている特徴を実行する権利である。リソースrは、FLEXnetライセンス中に指定されている特徴である。上の例では、リソースrは、FLEXnetの特徴f1、f2およびf3である。条件cは、FLEXnetライセンスの特徴(FEATURE)ライン中に指定されている制限である。上の例では、特徴f1に対する条件は2つのライセンスであり、特徴f2に対する条件は6つのライセンスであり、特徴f3に対する条件は3つのライセンスである。
【0050】
上記の権利データモデルに基づくと、権利は無条件となるが、これは、図2に示す譲与権利などのように関連の条件を何も有さないことを意味する。他方、権利は条件付きであるとは、図3および4に示す譲与権利の例などのように1つ以上の条件と関連していることを意味する。
【0051】
譲与権利u=(p、a、r、c)に指定されている条件cは、一般的には、満足しなければならない条件または、主体pにとってリソースrに対して動作aを実行するために実施しなければならない義務である。権利と関連付けることが可能な条件には、無状態条件および状態条件という2つのタイプが存在する。
【0052】
無状態条件とは、状態とは無関連の条件である。このような条件は、譲与権利を行使するために実行されなければならない義務のことである。このような条件は、譲与権利の寿命には直接には関連していない。無状態条件は一般的には、ビジネス上の規則(支払い方法、関連者各々に支払うべきパーセンテージなど)、認可規則(権利の行使の承認要請など)、システム要件などに関連している。
【0053】
状態条件とは、1つ以上の状態と関連付けられた条件のことである。このような条件は、譲与された権利を行使可能な回数や、譲与権利が行使される時間ウインドウなどの譲与権利の寿命中のある活動に直接的に関連している。状態条件は、その状態の特徴によってさらに2つのタイプに分割することが可能である。
【0054】
基準条件とは、状態を修正することなく読み取る状態条件のことである。このタイプの条件によれば、現在の値から次の値への状態の遷移は、譲与権利の行使や消費とは無関係である。例えば、図4に、譲与権利が行使される時間ウインドウを規定する条件を示す。この例では、状態の現在値は、譲与権利が行使されようとされまいと、時間の経過とともに変化し続ける。
【0055】
分割可能条件とは、状態を読み取って更新する状態条件のことである。このタイプの条件によれば、現在値から次の値への状態の遷移は、譲与権利が行使されるごとに始動される。例えば、図3に、譲与権利が行使される回数を規定する条件を示す。この例では、状態の現在値は、譲与権利が行使されるごとに減少する。
【0056】
状態に対する条件の依存性を組み込むため、上に開示した譲与権利u=(p、a、r、c)のデータモデルは次のように展開可能である。
u=(p,a,r,ci⇒Qi:i=1,..,n)
【0057】
ここで、(ci⇒ Qi:i=1,..,n)は、Qiが、i=1,..,nの場合に条件ciと関連している状態であることを意味する。条件ciが無状態条件であれば、Qiは
空である。権利の状態は、この権利と関連しているすべての条件の状態で表される。
【0058】
権利の導出と統合
【0059】
譲与権利u=(p、a、r、ci⇒Qi:i=1,..,n)に指定されている主体pは、1つの主体ではなく主体のグループを表している。例えば、図4に、2006年1月までに行使を制限する条件付きのルイ・アームストロングの「この素晴らしい世界」というCDをプレイする権利が音楽クラブに譲与されている様子を示す。「音楽クラブ」とは、人々のグループのことであり、音楽クラブの人であれば誰でも、現在の時点が2006年1月以降でなければこのCDをプレイしてもよい。
【0060】
アリスであると特定された主体が音楽クラブのメンバーであれば、アリスは、図4に指定されている権利を行使して、「この素晴らしい世界」というCDをプレイすることが可能である。しかしながら、図10に示すように、アリスはまた、図4に指定されている譲与権利と同じ条件141が付いた「この素晴らしい世界」というCDをプレイする権利142も譲与されている。主体のアリスにとっては、図4に指定されている譲与権利と図10に指定されている譲与権利の双方はまったく同じである。したがって、図10の譲与権利は図4の譲与権利の具体的なインスタンスであるので、図10の譲与権利は、図4の譲与権利から導出された権利であると考えることが可能である。同様に、図11に、図4の譲与権利から導出された権利143を示す。この例では、条件144は変更されてはいるが(Not After Jan. 2005:2005年1月まで)、図4の譲与権利の条件141の範囲内にとどまっている。
【0061】
主体pと同様に、u=(p、a、r、ci⇒Qi:i=1,..,n)中のp、a、rまたはciの各々は、それぞれ主体のグループ、動作、リソースまたは条件を互いに独立に示すことが可能である。したがって、様々な権利が、所与の文脈内ではまったく同じであるという場合がある。この場合、このような権利は互いに関連し、ある権利を他の権利から導出される。
【0062】
導出規則
【0063】
u=(p、a、r、ci⇒Qi:i=1,..,n)とv=(p’、a’、r’、c’i⇒Q’i:i=1,..,m)とを2つの権利であるとする。vは、m≦nであり、次の規則が当てはまれば、uから導出されたといわれる。
規則D1:p⇒p’,a⇒a’,r⇒r’
規則D2:∀i≦m,ci⇒ci’
規則D2.1:Qiが、ciの可能な状態値を表す非順序集合であれば、Q’i=Qi、0−QiここでQi、0はvの導出に先立つuの状態である。
規則D2.2:Qiが、ciの累積値を表す唯一の値を含む場合、‖Q’i‖≦‖Qi,0‖,‖Qi‖≦‖Qi,0‖および‖Qi‖+‖Q’i‖≦‖Qi,0‖、ここでQi、0はvの導出に先立つciの状態を表し、表記‖Qi‖はQiのノルム(すなわち値)を意味する。
規則D2.3:Qiが、ciの可能な範囲値を表す順序集合であれば、Q’i⊂Qi,0およびQ’i∩Qi=、ここでQi、0はvの導出に先立つuの状態である。
【0064】
表記p⇒p’は、pはp’を意味するまたはpはp’を導出するまたはp’はpから導出されたことを意味する。例えば、アリスはまた「キーホルダーA(Key Holder A)」としても知られ、したがって、アリスは「キーホルダーA」を意味する。p⇒p’であるかどうかを判定する規則はアプリケーションによって異なる。しかしながら、p’がpと同じであったり、p’がpのインスタンスであったり、pが空であったりする特殊な場合があるが、このような場合にはp⇒p’となる。
【0065】
規則D1は、サブ権利は、これが導出された元の権利によって許可されている主体、動作およびリソースだけを指定すべきことを定めている。より具体的には、規則D1は、サブ権利を遵守することを必要としている。主体p’はpから導出されなければならない。例えば、pが「部門Xのいずれかの被雇用者」である場合、アリスが実際に部門Xの被雇用者であれば、p’=”Alice(アリス)”はpから導出されたと言われる。動作a’はaから導出されなければならない。例えば、aが「修正(注釈という動作を含む)という動作と変更するという動作」であれば、a’="the annotation of annotating(注
釈する動作)"は、aから導出されたと言われる。リソースr’はrから導出されなけれ
ばならない。例えば、rが「出版社Yのいずれかの本」である場合、「ラーニングXML」が出版社Yから出版されていれば、r’="Learning XML(ラーニングXML)"は、rから導出されたと言われる。
【0066】
規則D2は、各々の条件c’iがこれに対応するciから導出されなければならないことを述べている。ある条件の状態の導出は、この条件のタイプ、そのあり得る状態およびその現在値によって異なる。規則D2.1〜D2.3は、以下に解説するようにこの依存性を定めている。
【0067】
規則D2.1を解説するために、cを、異なる多くのチャプタ、例えば、チャプタ1、3および5に対する印刷を制限する条件であるとすると、Q={chapter 1, chapter 3, chapter 5(チャプタ1、チャプタ3、チャプタ5)}となる。第1のサブ権利を導出する場合、有効なQ’の集合は、{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}が第1のサブ権利に譲与された後、Qは{chapter 3, chapter 5}となり、Q’は、{chapter 3}、{chapter 5}および{chapter 3, chapter 5}のうちの1つでしかあり得ないことになる。
【0068】
規則D2.2を解説するために、cを、再生動作を3回に制限する条件であるとすると、Q={3}となる。第1のサブ権利を導出する場合、有効なQ’の集合は、{1}、{2}および{3}である。例えば、{2}が第1のサブ権利に譲与された場合、cの現在値は1であり、Q’は、{1}でしかあり得ないことになる。
【0069】
規則D2.3を解説するために、cを、再生動作の有効期間を11/1/2004〜11/5/2004に制限する条件であるとする。Qを、{{11/1/2004〜11/2/2004}、{11/1/2004〜11/3/2004}、{11/21/2004〜11/3/2004}}などの11/1/2204〜11/3/2004の可能なすべてのサブインターバルの順序集合であるとする。インターバル{11/2/2004〜11/3/2004}が第1のサブ権利に譲与されると、Qは{{11/1/2004〜11/2/2004}、{11/3/2004〜11/5/2004}}となる。
【0070】
したがって、上記で定義した導出規則は、pがp’を意味し、aがa’を意味し、rがr’を意味し、ciがc’iを意味し、Q’i⊂Qi ∀i≦m≦nであれば、譲与された権利v=(p’、a’、r’、c’i⇒Q’i:i=1,..,m)をu=(p、a、r、ci⇒Qi:i=1,..,n)から導出可能であることを提示している。
【0071】
ここで、vは、uから導出されなかった条件を含むことがあり得る。これらの条件は本発明では制限された条件と呼ばれる。制限された条件によって、サブ権利の譲与者は、権利の被譲与者がサブ権利を消費するのをさらに制限することが許可される。サブ権利vが何らかの制限された条件を含む場合、これはときとして条件付きサブ権利と呼ばれる。例えば、会社Xがその部門Yに対して、この部門Yが部門の目標の少なくとも80%を達成すればDVD Zを10コピー譲与する。vをuに統合して戻す場合、すべての制限された条件が無視される。
【0072】
pとp’との間、aとa’との間、rとr’との間、ciとc’iとの間の関係はアプリケーションによって異なる。これらの関係は、アプリケーション内で定義可能であったり、権利表記中で表現可能であったりする。このような関係をアプリケーション内で定義すると、このアプリケーションは一方の式が他方によって意味されるかどうか判定する。関係を権利表記中で表現すると、アプリケーションは、1つの式が別の式を意味するかどうかを、これらの式を権利表記に照らし合わせて評価することによって検証することが可能である。
【0073】
v=(p’、a’、r’、c’i⇒Q’i:i=1,..,m)がu=(p、a、r、ci⇒Qi:i=1,..,n)から導出されると、vは、uの導出またはuのサブ権利であると言われる。言い換えれば、uはvの統合と言われる。例えば図10および11に示す譲与された権利は、図14に指定した譲与された権利のサブ権利である。vがuから導出されると、vはuの導出またはサブ権利と呼ばれる。
【0074】
図12に、譲与権利160の導出を示す。譲与権利160は主体ライブラリAに譲与され、コピーの数に関連する1つの条件を有する。主体であるジョン・ドエがライブラリAのメンバーであれば、譲与権利162は譲与権利160から導出される。この例では、譲与権利161は2つの条件を含む。条件163はジョン・ドエに対してリソースを1コピーだけ与える。条件164は、ジョン・ドエがリソースを使用することに対して時間制限を割り当てる。
【0075】
同様に、図13は、別のデバイス上で用いられる譲与権利170の導出を示している。譲与権利170は、主体のジェーンがリソースを2コピー用いることを提示する1つの条件171を有する。導出された権利172は、ジェーンがリソースを1コピー用いることを制限する条件173を含む。
【0076】
統合規則
【0077】
権利を統合する方法は、権利を導出する方法の逆である。
【0078】
権利をu、サブ権利をvとすると、vを統合してuに戻す規則は次のように定義される。
定義:u=(p、a、r、ci、1⇒Qi:i=1,..,n)を権利として、v=(p’、a’、r’、c’i、2⇒Q’i:i=1,..,m)をuのサブ権利とする。m≦nであって、次の規則が適用されると、権利u’=(p、a、r、ci⇒Q*i:i=1,..,n)は権利uとそのサブ権利vの統合であると定義される。
規則I1:p⇒p’、a⇒a’、r⇒r’
規則I2:∀i≦m、ci⇒ci’
規則I2.1:Qiが、ciの可能な状態値を表す非順序集合であれば、Q’iもまたc’iの可能な状態値を表す非順序集合でなければならず、また、Q*i=Qi∪Q’iである。
規則I2.2:Qiが、ciの累積値を表す唯一の値を含む場合、‖Q*i‖=‖Qi‖+‖Q’i‖、ここで‖Qi‖は、Qiのノルム(すなわち値)を意味する。
規則I2.3:Qiが、ciの可能な範囲値を表す順序集合であれば、Q’iもまたc’iの可能な範囲値を表す非順序集合でなければならず、また、Q*i=Qi(+)Q’iである。(+)は、カスタマイズされた和集合演算であり、システムによって異なる。例えば、範囲の粒状性と、範囲をどのようにすれば合併可能な(範囲を合併しながらもギャップをどのように取り扱うかを含めて)定義することが可能である。
【0079】
規則I1は、サブ権利が、この導出元の権利によって許可されたような主体、動作およびリソースのみを含まなければならないことを定めている。規則I2は、条件c’i各々が、その対応するciから導出されなければならないことを提示している。条件の状態の導出は、この条件のタイプ、その可能な状態値およびその現在状態値によって異なる。規則I2.1〜I2.3は、この依存性を定義している。特に、規則I2.1は、QおよびQ’が双方とも判明している値の非順序集合であれば、統合されたQ*はQおよびQ’の和集合であると述べている。規則I2.2は、QおよびQ’各々が、累積値を表す1つのエレメントを有すれば、統合された累積値はこれら2つの値の和であることを述べている。規則I2.3は、QおよびQ’がインターバルを表す順序集合であれば、統合されたQ*は双方の集合の和集合であることを述べている。
【0080】
分割可能権利、現在の権利、共有可能権利およびグループライセンス
【0081】
上記で定義した導出規則は、サブ権利を所与の権利から導出する、または、所与の権利が別の権利から導出可能であるかを判定するための一般的なメカニズムである。この規則は、サブ権利が次のメカニズム、すなわち、譲与権利のいずれかのコンポーネントを用いてサブ権利を導出するメカニズムと、何らかの状態条件を分割して、譲与権利からサブ権利を作成するメカニズムのうちのどちらかまたは双方を用いて導出することが可能であることを指定している。
【0082】
しかしながら、様々なアプリケーションでは、譲与権利のあるコンポーネントだけをサブ権利を導出するために用いることを許可、または、ある状態条件だけを分割してサブ権利を作成することを許可し得る。例えば、ライブラリアプリケーションは、譲与権利に指定されている主体を用いてサブ権利を導出することを許可しているため、ライブラリは、そのメンバーのためのサブ権利をライブラリに譲与された権利から導出することが可能である。図12は、ライブラリAが、そのメンバーであるジョン・ドエのためにその譲与権利からサブ権利を導出する様子を示している。図12では、サブ権利は主体に基づいて導出される。
【0083】
別の例では、ホームネットワークアプリケーションが、ある条件状態を分割することを許可している。この場合、ホームネットワークのユーザは、ユーザに譲与された権利からユーザのホームネットワーク内の各々のデバイス用の権利を導出することが可能である。図13は、ユーザのジェーンがジェーンの譲与権利から別のデバイス上で用いるための権利を導出するシナリオを示している。この例では、サブ権利は、譲与権利と関連する条件状態の分割可能性に基づいて導出される。
【0084】
譲与された権利は、サブ権利を導出する機能に基づいて次のタイプ、すなわち、分割可能権利、並列権利、共有可能権利およびグループ権利に分類することが可能である。これらのタイプの権利の各々を以下に説明する。
【0085】
分割可能権利
【0086】
分割可能権利とは、ある権利をサブ権利を作成するために分割しながらも同時にこの分割可能権利の他のコンポーネントを不変のままとすることが可能なような1つ以上の状態条件付きのこのような権利のことである。分割可能権利の用途は多い。例えば、これらは、消費者が権利を公平に用いることを刺激するために用いることが可能である。消費者は、ある権利を獲得すると、これをサブ権利に分割して、様々なデバイス上で、様々な場所で、様々な時間でなどのように用いる。
【0087】
サブ権利が分割可能権利から導出されると、オリジナルの分割可能権利中の各々の分割可能条件の現在状態を、この導出されたサブ権利の各々中の対応する条件の初期状態とこの条件の状態関数とにしたがって更新される。例えば、分割可能権利は、ユーザが権利を行使可能な回数を制限する条件を有し、また、現在の条件状態が、まだ行使の回数が5回残っていることを示していると仮定する。最大で2回の行使回数を有するサブ権利を導出する場合、導出元の分割可能権利の条件の現在状態を更新して、3回行使回数が残っていることを反映する(行使回数5回から2回を差し引く)。
【0088】
導出されたサブ権利の基準条件は、オリジナルの分割可能権利の同じ基準条件に関して制限される。例えば、分割可能権利が、この権利を行使し得る時間範囲を指定する条件を有する場合、導出されたサブ権利もまた、権利を行使し得る時間範囲を規定する基準条件を有さなければならず、また、サブ権利の時間範囲は、この分割可能権利に対して指定された時間範囲内に完全に入らなければならない。
【0089】
したがって、権利u=(p、a、r、ci⇒Qi:i=1,..,n)は、ciが分割可能条件であるようなiが少なくとも1つあれば、分割可能である。さらに、v=(p、a、r、c’i⇒Q’i:i=1,..,m)は、次の仮定が成立すれば導出またはuのサブ権利である。
ciが分割可能条件であるようなiが少なくとも1つ存在する、
vが、u中に指定されているすべての条件を含み、c’i=ci、i=1,..,n、および、Q’i⊂Qi、∀i≦m≦nであり、
導出v後のuの各々の分割可能条件ciの現在状態が、導出v前のciの現在状態と、導出vの初期状態およびciの現在関数にしたがって更新され、
すべての基準条件ciに対して、c’iがciであるかciの制限であるかである。例えば、条件ciが時点t1以前ではなく、導出された条件c’iはt3以前ではなくt4以後ではないが、ここでt1<=t3<=t4<=t2であり、表記<=は「以下」を表し、
すべての無状態条件ciに対して、ci’はciである。
【0090】
図14は、分割可能権利u(200)からサブ権利v(210)を導出するプロセスを示す。この例では、分割可能権利uは3つの条件を有する。
行使許可回数が10であると規定している分割可能条件201の現在状態202は行使回数が5回残っている、
権利行使可能な時間範囲を基準条件203が(2004年1月以後であり、2006年1月以前)規定している、
譲与権利を行使している間に宣伝Yを実施しなければならないと無状態条件204が規定している。
【0091】
同じ条件集合付きのuからサブ権利v(210)が導出される。特に、
分割可能条件211の場合、vは、行使許可回数として2回を規定している条件を有する。u中の同じ条件の現在状態が、残余行使回数5回から残余行使回数3回に更新される。
基準条件213の場合、vは、権利を行使し得る時間範囲を規定している条件を有する。この条件はuから導出され、したがって、vに規定されている時間範囲条件は、u中に規定されている時間範囲内に完全に入る。
無状態条件214の場合、vはuとまったく同じ条件を有する。
【0092】
導出後、分割可能権利u(300)の現在状態205は残余プレイ回数が3回である。
【0093】
この例では、擬似言語のフォーマットが、譲与された権利と条件の特徴を反映するように変更されている。したがって、「GRANTED RIGHTS(譲与権利)」は、譲与権利が実際に分割可能であることを示す「DIVISIBLE RIGHTS(分割可能権利)」に変更されている。「CONDITION(条件)」は、条件タイプを反映するように、「DIVISIBLE CONDITION(分割可能条件)」、「REFERENCE CONDITION(基準条件)」または単に「CONDITION(条件)」に変更されている。分割可能条件の宣言には、条件の現在状態が含まれている。
【0094】
このフォーマット変更は、特定の実現を提案するものではない。譲与された権利と条件のタイプを特定するために用いられる方法は、実現に委ねられる。例えば、このタイプは表現に明示的に宣言されている(図4のように)または他のいずれかのメカニズムを用いて特定された名前によって特定可能である。しかしながら、条件タイプの明示的な宣言には利点がある。同じ条件(例えば、最大の許可行使回数)が、1つの譲与権利中で分割可能であるが、他の権利中ではそうではない。分割可能条件の現在状態は、条件内(図4のように)宣言されるか、または、既知の認可ソース(認可された追跡デバイス、遠隔サービス、中央サービスなど)から検索されるかである。
【0095】
並列権利
【0096】
並列権利とは、サブ権利を主体に基づいて導出可能な元の権利であり、この場合、この並列権利の他のコンポーネントは不変のままである。並列権利においては、主体とは、主体のグループ、多数の識別を有する同じ主体または双方のことである。グループ中の主体はその各々が、並列権利中に指定されている同じ権利を継承する。並列権利によって、譲与権利中に指定されている主体が導出可能となり、指定されている主体に対するサブ権利が導出可能となるようにする。
【0097】
並列権利は状態条件を含むが、このような条件は分割可能ではない。サブ権利が状態条件付きの並列権利から導出されると、状態条件がサブ権利中で正確に(同じ状態値で)再現される。その結果、サブ権利中の条件状態は、導出された主体ごとに個々に管理される。したがって、導出された主体は各々が、状態を個々に維持して、譲与権利の消費を追跡する。
【0098】
例えば、並列権利として、グループの各メンバーに対して同じ権利集合を与えるメンバー資格がある。一部のアプリケーションでは、権利消費デバイスが、並列権利中の主体によって指定されているグループに対して特定の主体が実際に属していることを証明することが不可能である場合には、サブ権利を並列権利から導出することが必要となる。
【0099】
権利u=(p、a、r、ci⇒Qi:i=1,..,n)は、次の条件が成立すれば並列権利である。
ciが、すべてのiに対して分割可能条件ではなく、
p⇒p’となるようなp’が少なくとも1つ存在し、また、権利v=(p’、a、r、ci⇒Qi:i=0,..,n)がuの導出である。例えば、pが音楽クラブであり、p’が音楽クラブのメンバーであるアリスであれば、p⇒p’である。別の例では、pがアリスであり、アリスはまた、「Key Holder A(キーホルダーA)」としても知られている。すると、p⇒p’であり、ここで、p’は「キーホルダーA」である。
【0100】
図15は、音楽クラブの各々のメンバーに、ルイ・アームストロングの「What a wonderful world(この素晴らしい世界)」というCDをプレイする無制限の権利を譲与する並列権利u(220)を示す。この例では、主体のジョン・ドエは、音楽クラブのメンバーである。したがって、ジョン・ドエは、主体ジョン・ドエに同じCDをプレイする無制限の権利を譲与するサブ権利v(221)を導出することが可能である。
【0101】
図16は、状態条件226を含む並列権利u(225)を示す。この例では、この並列権利は、音楽クラブのメンバーが、ルイ・アームストロングの「この素晴らしい世界」というCDを5回プレイすることを指定している。導出前の現在状態227では、プレイ回数が3回残っている。サブ権利v(230)とw(235)を導出する場合、並列権利中の状態条件の現在状態(オリジナルの最大回数である5回のうちの3回が残っている)が、それぞれ条件231と236としてサブ権利の各々中で再現される。導出後は、サブ権利vおよびwの条件状態は互いに独立に追跡される。グループの各々のメンバーの条件状態は、中央認可サーバ、ユーザデバイスなどで追跡可能である。
【0102】
共有可能権利
【0103】
共有可能権利とは、主体と、もしあれば、その分割可能条件の状態との双方に基づいてサブ権利を導出することが可能な元の権利のことである。したがって、共有可能権利は、指定された主体間で共有可能な最大限の権利を指定する。導出された主体が共有可能権利からサブ権利を導出すると、条件状態を、導出されたサブ権利に割り当てられた条件状態にしたがって共有権利から推論する。
【0104】
並列権利と分割可能権利は、共有権利の特殊な場合である。特に、並列権利は、分割可能条件無しの共有可能権利の特殊なケースであり、分割可能権利は、少なくとも1つの分割可能条件付きであるが、それから導出することが不可能な主体(主体はグループを指定しない)付きの共有権利の特殊なケースである。
【0105】
共有権利と並列権利間の主要な相違は、導出されたサブ権利中の状態条件の状態をどのように追跡するかという点である。並列権利中の状態条件は分割可能ではないため、各々の導出されたサブ権利の条件状態は互いに独立に追跡される(状態は、各々のサブ権利の主体に対して別個に追跡される)。共有可能権利中の状態条件は分割可能であるため、導出されたサブ権利の条件状態は共有される(すべての導出されたサブ権利は、各々の分割可能条件に対して同じ状態を指し示している)。この結果、サブ権利の主体が条件状態を共有することになる。
【0106】
図17は、「この素晴らしい世界」というCDを100コピー所有して、この100コピーをメンバー間で分配する権利を音楽クラブに譲与する共有可能権利u(240)を示す。この例では、分割可能条件の現在状態241は、10コピーが今までに分配され、90コピーが残っていることを示している。音楽クラブのメンバーであるジョン・ドエという主体は、サブ権利v(242)中にこのCDを1コピー譲与される。サブ権利vは、1コピーの状態243付きの共有可能権利uから導出される。共有可能権利u中の分割可能条件の現在状態244は、残りのコピー数が89に減少する。
【0107】
分割可能権利と並列権利用のアプリケーションを含む、共有可能権利の特徴を利用可能なアプリケーションは多く存在する。このようなアプリケーションの1つは、「グループライセンス」と呼ばれ、以下に説明する。
【0108】
グループライセンス
【0109】
グループライセンスとは、一人以上の認可されたユーザに対して最大限の権利を譲与して、この認可済みユーザが、自分たちの間での自分たち自身の共有ポリシーにしたがって譲与権利を共有したり、他の認可済みユーザの集合と共有したり、認可済みユーザが共有権利を返却したり、さらに、他の認可済みユーザと各々の共有権利をさらに共有したりすることを許可する権利のことである。したがって、グループライセンスは、サブ権利を返却したり、統合してグループライセンスに戻したりすることを許可する共有権利である。
【0110】
本発明中に定義するように、ライセンスとは、あるユーザに譲与された権利のことである。したがって、「ライセンス」と「権利」という用語は、交換可能である。多くのDRMシステムがライセンスに対して異なった定義をしているが、ライセンスは少なくとも1つの譲与された権利を含まなければならない。したがって、DRMシステムで使用されるライセンスの定義を、本発明中のライセンスの定義にマッピングすることが可能である。例えば、MPEG RELでは、「ライセンス」という用語は、譲与権利の集合に、他の情報(発行者、ライセンスの整合性などに関する情報など)を足したものである。したがって、MPEG RELライセンスは、本発明に定義するように多数のライセンス中にマッピングすることが可能である。
【0111】
上記のようなグループライセンスの概念は、共有可能な権利と権利の統合という概念を用いて実現することが可能である。グループライセンスは、共有可能権利であるため、認可されたユーザおよび/または認可済みユーザのグループ中で共有されるように動的に分割可能である。あるグループライセンスを共有目的で分割すると、新しいライセンスが作成されて、グループライセンス中に指定されている条件状態が、新しいライセンス中に指定されている条件状態を推論するように調整される。この作成された新しいライセンスは共有されたライセンスと呼ばれるが、また、グループライセンスでもある。したがって、共有されたライセンスは、認可済みのユーザによって消費するか、または、認可済みのユーザおよび/または認可済みユーザのグループ間で共有目的でさらに分割することが可能である。
【0112】
共有されたライセンスはまたグループライセンスでもあるため、この共有ライセンスの権利被譲与者は、権利譲与者として動作して、下流での共有目的でその共有ライセンスから新たな共有ライセンスをさらに導出することが可能である。したがって、多段階権利共有や、権利被譲与者の決定権に基づいた共有や、異なったグループの主体および/またはデバイス間での共有などの動的権利共有がサポートされる。
【0113】
共有ライセンスは、一旦作成されると、消費目的利用可能となる。共有ライセンスが使用されるごとに、その条件状態が更新されて、その使用を反映するようにする。どの時点でも、共有ライセンスの残っている権利は、上に開示した権利統合方法を用いて、このライセンスの導出元であるグループライセンスに対して返却することが可能である。
【0114】
グループライセンスの概念は、権利とリソースの共有、デバイス間での共有、ユーザ間での共有、組織間での共有などに関するあらゆる態様をカバーしている。グループライセンスは、権利とリソースの動的共有を可能とする多くのアプリケーションに対する基本的な要素となりえる。このようなアプリケーションには、これに限られないが、次のものがある。
ライブラリ:あるライブラリが、「風とともに去りぬ」という題名の本をある数だけに対するグループライセンスを譲与される。いつでも、このライブラリは、この本のコピーを、そのグループライセンスから共有ライセンスを導出することによってライブラリメンバーに貸し出すことが可能である。このライブラリが共有ライセンスを導出すると、利用可能なコピーの総数は、ライブラリメンバーがこの本を返却するまで減少する。
ホームネットワーク:ユーザのホームネットワークは、様々なDRM能力を有する様々なデバイスを含んでよい。ユーザは、前もってどのネットワークデバイスがライセンスを消費するかを指定することなく、ユーザのホームネットワーク内で使用する目的でライセンスを購入するという利便性を欲しがる。この目的のため、ユーザはグループライセンスを獲得して、ホームネットワーク中の特定のデバイスのためにそれから共有ライセンスを導出する。
メンバー資格:あるグループのメンバーは、このグループに譲与されている一般的なライセンスを用いる代わりに自分たち自身のための特定的なライセンスを導出したがるが、これは、ユーザデバイスが一般的ライセンスを執行することが不可能であるからである。
【0115】
次の例は、グループライセンスの概念とグループライセンスからどのように共有ライセンスを導出するかを示している。
【0116】
図18は、映画Bの100コピーの権利を企業Aに譲与するグループライセンス250を示す。グループライセンスは、最初に作成されたときは、最大コピー数を100と規定し、100コピーが残っているという現在状態を規定する分割可能条件を含む。企業Aは、営業上の必要性にしたがってその被雇用者または被雇用者グループ間に映画Bの100コピーというプールを分割してよい。
【0117】
図19は、グループライセンス250中のその100コピーというプールから映画Bの10コピーをその人事部門に譲与する。企業Aは、人事部門に対して映画Bの10コピーに対する権利を譲与する共有ライセンスを導出するが、これは条件256に反映される。図19はまた、図18に示すグループライセンス中の条件状態251をどのように更新して、100コピーのプールから10コピーを差し引いて90コピーが残るようにするかを示している。
【0118】
企業Aが人事部門に譲与する共有ライセンス255もまた、さらに分割可能なグループライセンスである。図20は、グループライセンス257と条件261に反映されるように、企業Aの人事部門がその被雇用者のうちの一人であるジョン・ドエに対して、映画Bの1コピーに対する権利を譲与する様子を示している。図20はまた、人事部門のライセンス中の条件状態256をどのように条件状態257に更新して、10コピーのそのプールから1コピーを差し引いて9コピーが残るようにするかを示している。図20はまた、人事部門が映画Bの1コピーをジョン・ドエに譲与する動作が、企業Aのオリジナルのグループライセンス中の条件状態251に影響しない(企業Aにはいまだ90コピーが残っている)ことを示している。
【0119】
ジョン・ドエに映画Bの1コピーを譲与した後では、図21に示すように、人事部門は、その残っているコピーのうちの2つを企業Aに返却すると決心する。返却したら、企業Aのグループライセンス250に対する残りのコピーの数は2だけ増加して条件状態251中の90コピーから条件状態252中の92コピーとなり、同時に、人事部門のライセンス255に対する残りのコピーの数は2だけ減少して条件状態257中の9コピーから条件状態258中の7コピーになる。
【0120】
図22は、映画Bの100コピーというプールの共有を許可する企業Aのグループライセンス(図18に示す)の擬似MPEG REL表現260を示す。企業Aは、このプールを被雇用者のグループ間に、コピーの総数がプールのキャパシティを超えない限り各々のグループに対して共有ライセンスを発行することによって分割してよい。分配する権利は、seekApproval条件を条件とする発行権利を用いて指定される。このseekApproval条件は、追跡サーバが、プール中のコピーの残数と共有ライセンスに対して要求されているコピーの数とを追跡することに依存している。分配可能な使用権利は、内部譲与に含まれている。これには、受領側ユーザグループの識別のプレースホルダとしての変数Yと、受領側グループに割り当てられたコピーの数のプレースホルダとしての変数Xと、企業Aが共有ライセンスに追加したがっているいずれかのカスタム条件のプレースホルダとしての変数Zが含まれている。
【0121】
図23は、企業Aの人事部門(図19に示す)に対するライセンスの擬似MPEG REL表現265を示す。変数Y、X、およびZに、人事部門(受領側グループの識別)、10(人事部門に割り当てられたコピー数)および使用報告(すべての使用を指定されたサーバによって追跡される必要がある)が代入される。その他の情報は、現在のライセンスと、現在のライセンスが導出する元のライセンスとを特定する。
【0122】
図24は、サブグループライセンスと共有ライセンスの双方がグループライセンスから導出される使用事例を示す。中心ライブラリCは、本Bを100回コピーすることを許可するグループライセンス280を獲得する。中心ライブラリは、その必要性によってローカルライブラリのためにそのグループライセンスからサブグループライセンス281と282を作成する。Cは、20コピーをサブループライセンス282中でローカルライブラリXに分配し、30コピーをサブグループライセンス281中でライブラリYに分配する。ローカルライブラリYはさらに、サブグループライセンス284中でライブラリZにそのコピーの10コピーを分配する。さらに、共有ライセンス283、286、287が、グループライセンス280、サブグループライセンス282、サブグループライセンス281またはサブグループライセンス284から発行されてよい。
【0123】
権利とリソースの動的共有をサポートするシステム
【0124】
上記に開示したグループライセンスの概念は、権利共有のあらゆる態様をカバーしている。これは、共有可能権利の消費を認可し、分散された共有権利を含むライセンスを発行し、グループライセンスと共有可能ライセンスの双方に対する権利の状態の管理が可能なあらゆるDRMシステムによって実現可能である。図25は、このようなDRMシステムの例を示す。DRMシステム300は、例えば、起動サーバ302、認可サーバ303、1つ以上の権利消費デバイス305、保護コンテンツ/アセット分配サーバ308、ライセンスサーバ310および保護アプリケーション/サービス311を含む。認可サーバ303は、1つ以上のキー304と関連付けられてよい。権利消費デバイス305はDRMコンポーネント306を含み、また、1つ以上のライセンス307と関連付けられる。保護コンテンツ/アセット分配サーバ308は、保護されたコンテンツ/サーバ309を分配する。ライセンスサーバ310は、本システムにライセンス307を提供する。保護アプリケーション/サービス311は、明瞭なコンテンツ/アセット312と権利提案を提供するが、これは権利と条件とを含む。
【0125】
図26は、動的な権利とリソースの共有をサポートするシステムの基本的なコンポーネントを示す。これらのコンポーネントには、インストールコンポーネント321、インストール追跡コンポーネント(TCI)322、共有追跡コンポーネント(TCS)323、共有コンポーネント324、委託コンポーネント325、消費コンポーネント326および消費認可コンポーネント327が含まれる。各々のコンポーネントは、ハードウエアコンポーネント、ソフトウエアコンポーネント、デバイス、サービスなどとして実現可能である。グループライセンスは、一旦権限によって発行されると、その使用を追跡する元となる特定の環境に拘束されたりされなかったりする。本発明の好ましい実施形態では、グループライセンスは環境には初期は(ライセンス発行時は)拘束されない。このプロセスによってより大きなフレキシビリティが与えられるが、これは、グループライセンスは、特定の環境に限られることなくどこでもいつでも獲得することが可能であるからである。
【0126】
図26に示すように、グループライセンス320は、環境に拘束されなかった場合には、共有されたり使用されたりすることが可能となる前にインストールコンポーネント(IC)321によってインストールされなければならない。TCI322がこのインストールを認可する。このインストールの目的は、グループライセンス320が以前にはインストールされていなかったこと、そして、これからはグループライセンスの権利の状態を追跡する、共有追跡コンポーネント(TCS)と呼ばれる追跡コンポーネント323にグループライセンスが拘束されることを保証することにある。
【0127】
グループライセンスの権利の状態はどのデバイスにでも保存可能であるが、権利の状態は、権利の共有を制御する共有コンポーネントによって証明され、検証されなければならない。例えば、権利の状態は、インストールされたグループライセンスと同じデバイスに保存するか、グループライセンスが拘束されている認可コンポーネントと同じデバイスに保存するか、遠隔サービスに保存するか、または、グループライセンス内に保存することが可能である。権利の状態の保存する様々な考えられる戦略が、図17、18、19、20および21ならびに本発明の他の図面に図示されている。権利の状態がグループライセンス自体内に保存された場合、権利の状態が更新されるごとにグループライセンスは変換されて(なぜならライセンスが消費されたか、または、権利が行使されたからである)、新しい状態を反映するようにする。この新しい状態を有するグループライセンスが交換グループライセンスであれば、オリジナルのグループライセンスは、一旦交換グループライセンス中の新しい状態を反映するために変換されたら無効となる。
【0128】
グループライセンスは、一旦インストールされれば、インストール済みグループライセンスと呼ばれ、共有目的に対して利用可能となる。共有コンポーネント(SC)324は、要求を、インストールされたグループライセンスを解釈し、TCS323から現在の権利状態を検索し、この現在の権利状態をこの要求に照らし合わせて検証し、共有ライセンス(認可されれば)作成することによって処理する。インストールされたグループライセンスから導出されたこの共有ライセンスは、委託証明目的で委託コンポーネント325に対して利用可能なものとされる。
【0129】
この共有ライセンスは、これ自体が、さらなる共有目的で利用可能とされるグループライセンスである。これは、次の形態のうちの1つであり得る。
拘束グループライセンス:このタイプのライセンスは、作成されるとTCSに対して拘束される。共有ライセンスが拘束されるTCSは、インストールされたグループライセンスが拘束されるTCSと同じでも異なっていてもよい。編成が小さい場合、追跡コンポーネントは同じでもよいが、編成が大きかったり主体のグループが多様であったりすれば異なったものとなる。
非拘束グループライセンス:このタイプのライセンスは、発行されたときには特定のTCSに拘束されていないが、後になってTCSに拘束されることがあり得る。このタイプのライセンスは、ライセンスが生成されるときに対象の消費環境または対象のTCSが知られていない場合に生成される(例えば、別の権利被譲与者グループ、別のネットワークなどとの共有のためにライセンスを作成する)。別のシナリオでは、ライセンスの譲与者は、TCSに拘束するオプションを維持することによってライセンスのフレキシビリティをより大きいものとすることを提案したがる。このような状況下では、TCS拘束権限をライセンス被譲与者または他の当事者に委譲することも可能である。
消費ライセンス:このタイプのライセンスは、共有ではなく主として消費目的で作成される。しかしながら、これは、認可された主体またはデバイス間で共有することが可能である。
【0130】
図26に示す基本的コンポーネントを用いて、様々な構成でシステムを設計することが可能である。消費ライセンスが作成されると、消費コンポーネント326は、消費認可コンポーネント327によって認可されればリソースの消費を可能とする。
【0131】
図27は、主要な2つのデバイス、すなわち、グループライセンスデバイス350と消費デバイス356を含む1つの好ましい実施形態を示す。グループライセンスデバイス350は、インストールコンポーネント351と共有コンポーネント352をそれぞれ含む。これは、グループライセンスをインストールしたり、アンインストールしたり、共有ライセンスを作成したりするすべての要求を取り扱う。消費デバイス356は、ライセンスを消費するための消費コンポーネント357を含む。この例示の構成では、インストール追跡コンポーネント(TCI)353、TCS354および委託コンポーネント355は、グループライセンスデバイス350の外部にある。共有認可デバイスは、自身に拘束されたすべてのインストール済みグループライセンスの権利の状態を追跡する。
【0132】
図28は、代替の構成を用いる別の好ましい実施形態を示す。この実施形態では、TCS354はグループライセンスデバイス350の内部にある。この構成では、グループライセンス350は、共有要求を処理して、インストールされたすべてのライセンスの権利の状態を追跡する。したがって、グループライセンスデバイス350は、外部のTCSを必要とすることなく共有要求を認可することが可能である。一旦共有要求が認可されたら、グループライセンスデバイス350は、共有ライセンスを作成してこの共有ライセンスを委託の証明目的で委託デバイス355に対して利用可能とする。
【0133】
図29は、別の代替構成を用いるさらに別の好ましい実施形態を示す。この構成では、TCSコンポーネント354と委託コンポーネント355は双方ともがそれぞれ、グループライセンスデバイス350の内部にある。グループライセンスデバイス350は、すべての共有要求を処理し、インストールされたすべてのグループライセンスの権利の状態を追跡し、デバイスによって生成された共有ライセンスを証明する。これは、現在最新のDRMシステムに統合するには最も実用的な構成である。
【0134】
図30は、企業Aの場合の図29に示す構成のアプリケーションを示す。企業Aのネットワーク内では、グループライセンスデバイス360がグループライセンスサーバ361にインストールされている。グループライセンスデバイス350は、この企業のネットワーク内のすべてのデバイスに対するすべての共有要求の処理専門のデバイスである。グループライセンスサーバ361は、グループライセンスのあらゆるインストール要求を認可する目的でネットワークを介してインストール認可デバイス370を含むインストール認可サーバ369に接続されている。企業Aではまた、共有認可デバイス363をインストールしている認可サーバ362は、この企業内で用いられるグループライセンスの権利のすべての状態を追跡する業務専門となっている。加えて、企業Aのネットワークは、プリンタ364、ワークステーション365、iBook366およびラップトップコンピュータ367などの他のデバイスと、さらにアダプタデバイス368を含む。ネットワーク内での通信は、例えば、ハブ371によって容易化される。
【0135】
追跡コンポーネント
【0136】
どのDRMシステムにも、追跡コンポーネントは存在する。追跡コンポーネントの機能は、権利の使用または状態を追跡することである。本発明内では、追跡とは、グループライセンスのインストールステータスを追跡したり、インストールされたグループライセンスに対する権利の状態を追跡したりすることが含まれる。本発明では、インストールを追跡するコンポーネントをインストール追跡コンポーネント(TCI)と呼び、グループライセンスに対する権利の状態を追跡するコンポーネントを共有追跡コンポーネント(TCS)と呼ぶ。
【0137】
TCIとTCSの機能は、上記と同じまたは別のコンポーネントでも実施可能である。これらの機能は、同じデバイスやサービスまたは別のデバイスやサービスで実施されるように構成可能である。追跡用のデバイスやサービスは、どこに置かれても、動的権利共有をサポートするシステム中の他のコンポーネントによって委託されなければならない。システム内のすべてのコンポーネントによって委託される権限による証明などのこのような委託を確立する多くのメカニズムが知られている。
【0138】
インストール追跡コンポーネント(TCI)
【0139】
このコンポーネントは、インストールされたグループライセンスの権利の初期状態と、インストールされたライセンスの権利の状態を追跡する共有追跡コンポーネントの識別(TCSID)とともにグループライセンスのインストールステータスを追跡する。上述したように、インストールステータスを追跡する目的は、グループライセンスが、その権利の状態を追跡するTCSにしか拘束できないことを保証することである。
【0140】
図31は、どのようにしてインストール要求を追跡するかを示す。このプロセスに対する入力には、グループライセンスとTSCのTCSIDを含む。グループライセンスの整合性と信憑性はステップ400で確認される。整合性は、グループライセンスが変更されたり改竄されたりされていないことを保証するために確認される。信憑性は、グループライセンスがTCIに委託された権限によって発行されたことを保証するために確認される。入力されたグループライセンスが有効で真正であれば、グループライセンスは、ステップ401で、期限切れや取り消しされていないかどうかチェックする。次に、IACはステップ403で追跡情報を検索して、このグループライセンスが現在インストールされているかどうかステップ404でチェックする。グループライセンスが有効でなければ、真正でなければ、期限切れであれば、取り消されていればまたは現在インストールされていれば、この要求はステップ402で拒絶される。そのようでなければ、権利の初期状態がグループライセンスから初期化され、追跡情報がステップ405で作成されて、ステップ406で権利の初期状態で更新される。
【0141】
グループライセンスが以前にはインストールされているが現在はインストールされていない場合、TCIは権利の状態を検証して、グループライセンスに指定されている権利が今は有効であることを保証する。そのようでない場合、インストール要求は拒絶される。
【0142】
追跡情報が見つからないまたはグループライセンスがインストールされたことがないことを示している場合、新しい追跡情報を作成して、権利の初期状態で更新して、この追跡情報をインストール済みであるとマーキングする。グループライセンスが以前にインストールされていて権利がまだ有効である場合、追跡情報はインストール済みであるとマーキングされる。
【0143】
図32は、追跡情報410の好ましい構造を示す。これは、インストールされたグループライセンスもしくはライセンスID411、(アンインストールプロセス中に用いられる)権利の状態を追跡するコンポーネントのTCSID412、現在のインストールステータス413、最初にインストールされたときもしくはアンインストールされたときのグループライセンスに対する権利の状態414およびアプリケーションが必要とする他の情報415を含む。
【0144】
一旦インストール要求が譲与されると、追跡情報に保存されている現在の権利状態が、インストールコンポーネント(IC)である要求元に返却される。その結果、このインストールコンポーネントは、この権利の状態を共有コンポーネント(SC)に渡して、グループライセンスの権利の初期状態を初期化することが可能となる。
【0145】
グループライセンスは、一旦インストールされると、最初にアンインストールされるまでは再度インストールすることは不可能となる。アンインストールプロセスによって、グループライセンスは、その権利の状態を現在追跡しているTCSから解放される。アンインストールプロセスでは、インストールされたグループライセンスまたはライセンスIDと要求メッセージが必要とされる。この要求メッセージは、グループライセンスに対する現在の権利状態を含む認証可能メッセージである。
【0146】
図33は、アンインストールするプロセスを示す。追跡情報が、入力されたグループライセンスまたはライセンスIDを用いてステップ420で検索される。次に、追跡情報がステップ421で検証されて、これが、グループライセンスが現在インストールされていることを示していることを保証する。加えて、ステップ422で、追跡情報に照らし合わせて要求を検証する。追跡情報が見つからなければ、グループライセンスは現在インストールされていないか、または追跡情報が要求に照らし合わせて検証されていない場合、ステップ425で要求は拒絶される。
【0147】
グループライセンスが現在インストールされていれば、ステップ422で、TCSID中に保存されているIDを用いて、要求メッセージを検証する。要求メッセージには、インストールされたグループライセンスに対する現在の権利状態が保存されている。多くの既知のメカニズムを用いて、要求メッセージを検証することが可能である。例えば、要求メッセージをTCSで署名すると、TCSIDがTCSのキーを含み、このキーを用いてTCSの署名を検証する。TCSの署名が検証可能であれば、要求は真正である。そうでなければ、アンインストール要求は信用されない。
【0148】
認証可能なメッセージと証明された現在の権利の状態とが検証されたら、TCIはステップ423で、グループライセンスの現在の権利の状態で追跡情報を更新して、ステップ424で、証明された現在の権利の状態で追跡情報をアンインストールされたものとしてマーキングする。
【0149】
共有追跡コンポーネント(TCS)
【0150】
このコンポーネントは、インストールされたグループライセンスに対する権利の状態を追跡する。グループライセンスは、一旦インストールされると、TCSに拘束される。TCSに拘束されることの利点は、権利の状態がたった1集合だけ維持されるように保証されることである。これによって、多くの様々なグループライセンスデバイスが、グループライセンスに対する権利の状態にコンフリクトを引き起こすことなく権利共有要求を処理して、共有ライセンスを発行することが可能となる。例えば、ホームネットワークにおいて、TCSがインストールされているデバイスに接続可能であればどのグループライセンスデバイスでも、ホームネットワーク中のデバイスで用いられるように共有ライセンスを発行することが可能である。
【0151】
グループライセンスがインストールされると、TCSの認証可能ID(TCSID)が検索されて、TCIに対して利用可能なものとされる。TCSIDは、アンインストール要求メッセージを認証するために後で用いられる。一旦インストールされると、TCIによって返却されたグループライセンスに対する権利の状態を用いて、TCSに保存されている権利の状態を初期化する。さらにセキュリティを高めるため、TCSは、権利の状態と他の情報に、これらをTCSに保存する前にサインする。図34に、TCSに保存する以前にそしてこれらをTCSから検索した後で、権利の状態にサインし、証明し、検証するプロセスを示す。
【0152】
インストールされているグループライセンスがアンインストールされると、TCSは要求メッセージを生成するが、このメッセージは、アンインストールされたグループライセンスに対する現在の権利状態を含む認証可能メッセージである。すると、現在の権利状態がアンインストールの対象となるTCIに渡される。インストールされたライセンスが使用、共有、統合目的で処理された場合はいつでも、TCSは、権利の状態が変化すると、その新しい状態で更新される。
【0153】
一部のアプリケーションでは、権利の状態はTCSがインストールされているデバイスのところには保存されない。権利の状態は、維持されるかどうかとは無関係に、委託可能となるようにTCSによって証明されなければならない。例えば、権利の状態はグループライセンス内に保存可能である。この場合、グループライセンス自体がレポジトリとして動作する。共有ライセンスが作成されたり統合されたりした結果、グループライセンスが変化すると、このグループライセンスも変化する。新しい権利の状態を持つグループライセンスは対象のTCSによって証明されなければならない。証明されたグループライセンスは新たなグループライセンスとなって、以前のグループライセンスに取って代わる。新たなグループライセンスは、一旦作成されると、以前のグループライセンスと同じTCSに拘束され、以前のグループライセンスはTCSから解放される。新しいグループライセンスと以前のグループライセンスは双方とも、同じIDを共有する。この場合、以前のグループライセンスのインストール状態が新しいグループライセンスに転送される。
【0154】
インストールコンポーネント
【0155】
インストールコンポーネントは、グループライセンスをTCIにインストールしたりアンインストールしたり、インストールされたグループライセンスをTCSに対して拘束したりこれから解放したりする。拘束プロセスでは、TCSへのインストールされたグループライセンスに対する権利の状態を初期化し、これで、認可された共有コンポーネントが権利の状態を管理して追跡することが可能となるようにする。TCIにグループライセンスをインストールすることによって、このインストールされたグループライセンスが別のTCSにこれ以上インストールされて拘束されることがあり得ないことを保証する。これによって、グループライセンスに譲与された権利が、複数のTCS上で複製されたり増殖されたりされることを防止する。例えば、映画Aの2つのコピーを譲与するグループライセンスが互いに異なった2つのTCSに拘束されると、TCSはその各々が譲与された権利の状態を2に初期化する。これは、各々のTCSがコピーを2つ共有することを許可し、したがって、グループライセンスの条項と条件に違反することを意味する。
【0156】
グループライセンスが獲得されたりインストールされたりすると、インストール追跡コンポーネント(TCI)のIDをインストールコンポーネントに通信し、これが正しいTCIからのインストールを要求することが可能となるようにしなければならない。発行されたグループライセンス中のTCIのIDやアドレスの符号化、何らかの既知のプロトコルを通じてのTCIのIDやアドレスの獲得、グループライセンス権利の譲与者と被譲与者間の合意の利用など、この通信を実行する方法が多く存在する。一部のアプリケーションでは、TCIは、グループライセンス権利の譲与者のシステムの一部である。TCIがグループライセンス権利の被譲与者のシステムの一部であるアプリケーションもある。さらに、TCIが独立したサービスであるような他のアプリケーションもある。
【0157】
図34に示すように、拘束するプロセスでは、グループライセンスに対する権利の初期状態が、このグループライセンスが拘束されるTCSに登録される。ステップ430および431では、権利の状態の整合性値が計算され、次いで証明される。権利の状態は、一旦初期化されて証明されると、状態レポジトリ432に保存される。次に、TCSは、グループライセンスが使用されるごとに権利の状態を管理して追跡する。一部のアプリケーションや構成では、TCSとTCIの機能が1つのコンポーネントに合成されるが、これらの機能を別々のコンポーネントに分離する他のアプリケーションや構成もある。例えば、組織Y用にグループライセンスを発行するシステムZの認可サーバXがTCIとして動作し、一方、組織Y内の認可サーバZがTCSとして動作する。しかしながら、組織Yの認可サーバZがシステムZによって委託コンプライアンスしていることが証明されると、Zは、TCIとTCS双方として機能することが許可される。
【0158】
上述したように、インストールされると、グループライセンスはTCSに拘束され、権利の状態を初期化して管理することが可能となるようにする。例えば、証明内容はステップ433で検証可能であり、整合性値はステップ434で再計算可能であり、また、整合性値はステップ435で比較可能である。しかしながら、グループライセンスは、共有または使用目的でグループライセンスを処理するデバイスが、グループライセンスの権利の状態を適切に管理可能となるようにTCSと対話可能であるかぎり、いかなるデバイスにも保存することが可能である。
【0159】
以下のセクションでは、グループライセンスのインストールとアンインストールをより詳細に説明する。
【0160】
グループライセンスのインストール
【0161】
インストールプロセスでは、TCIによって認可を要求し、グループライセンスが現在はインストールされていないことを保証し、また、現在の権利状態を獲得するようにしなければならない。インストールプロセスでは、グループライセンスに対する権利の現在の状態でTCSが初期化される。
【0162】
図35は、次のステップからなるグループライセンスをインストールするプロセスを示す。最初のステップ440では、グループライセンスの整合性および信憑性ならびにグループライセンスに対する権利の状態が検証される。グループライセンスの整合性を検証することによってこれが改竄されていないことを保証し、これが信頼すべきソースから発行されたことを保証するグループライセンスの信憑性を検証する。整合性と信憑性を検証する方法は、グループライセンスの表現によって異なる。最も一般的な方法では、デジタル署名を用いてグループライセンスの整合性を保証し、デジタル証明書を用いてグループライセンスの信憑性を保証する。しかしながら、アプリケーションが異なれば、グループライセンスの整合性と信憑性を保証する採用方法も異なる。グループライセンスに対する権利の状態を検証することによって、いずれかの条件の現在状態がこの条件が期限切れであることを示していると判定されると、このグループライセンスはインストール目的で処理されることはない。
【0163】
次のステップ441では、対象とするTCIからの認可を要求する。このステップでは、対象のTCIとTCSを特定する。TCIとTCSの双方が一旦特定されたら、インストール要求が構築される。すると、TCSが認可されて、そのTCSIDが検索されて、インストール要求が構築される。図36に示すように、目標とするTCIによる認可に対する要求は、グループライセンスとTCSのTCSIDとからなる。このTCSIDを後で用いて、アンインストールに対する要求を認証する。TCIは、グループライセンスが譲与される組織の外部またはその一部である。TCIは、要求されたグループライセンスがインストールの要求時にはまだインストールされていないことを検証する。一旦インストール要求が認可されると、グループライセンスに対する現在の権利状態が返却されて、グループライセンスは、アンインストールされるまでは再度インストールすることは不可能である。したがって、インストールすることによって、グループライセンスが複数回インストールされることが効果的に防止される。
【0164】
3番目のステップ442では、目標のTCS付きのインストール済みグループライセンスに対する現在の権利状態が初期化される。TCSは、(グループライセンス中でのように)前もって指定したり、何らかのプロトコルや合意によって獲得することが可能である。TCS付きのインストール済みグループライセンスに対する権利の状態を初期化するプロセスによって、TCSは、グループライセンスに対する権利の状態を、これらの権利が変更される度に追跡することが可能となる。
【0165】
4番目のステップ443では、インストールされたグループライセンスをライセンスレポジトリに保存する。このライセンスレポジトリは、グループライセンスが拘束されるTCSとは独立しているが、ライセンスレポジトリは一部の構成ではTCSの一部である。
【0166】
図36は、インストール要求を構築して認可するプロセスを示す。最初に、グループライセンスのTCIとTCSの双方がステップ450で特定される。この特定が合格すれば、目標となるTCSがステップ451で認証される。目標TCSが認証可能であれば、グループライセンスとインストール要求のTCSIDとがステップ452で構築される。次に、目標TCIがステップ453で認証される。目標TCIが認証可能であれば、次のステップ454でインストールの認可が要求される。要求が認可されれば、インストール要求は合格である。上記のステップのうちのいずれかが不合格であれば、要求はステップ455で不合格となる。
【0167】
グループライセンスのアンインストール
【0168】
アンインストール動作によって、グループライセンスが目標とするTCIからアンインストールされて、TCSが、アンインストールされたグループライセンスを追跡することから解放される。グループライセンスは、一旦アンインストールされたら、再インストールされるまで使用不可能である。このアンインストールプロセスは、アンインストール要求を検証するステップと、目標とするTCSからグループライセンスを追跡することを解放するステップと、グループライセンスをTCIからアンインストールするステップからなる。解放要求が合格すれば、TCSは、アンインストールされたグループライセンスの現在の権利状態付きの認証可能メッセージを返却する。この認証可能メッセージは、次のステップでのアンインストール要求のためにTCIに送られる。加えて、アンインストール要求には、グループライセンスもしくはグループライセンスIDおよび、権利の証明済み現在状態を含むTCSによって返却された認証可能メッセージが含まれている。TCIは、以前にはTCIに保存されていたTCSのTCSIDを用いて、TCSの認証可能メッセージと現在の権利状態とを検証する。要求が合格すれば、TCIは追跡情報を更新して、グループライセンスが権利の証明済み現在状態によってアンインストールされたことを示す。グループライセンスがTCIで現在インストールされていないまたは認証可能メッセージが検証不可能であれば、アンインストール要求は不合格となる。
【0169】
共有コンポーネント
【0170】
共有コンポーネントは、認可された主体による共有または使用のために共有ライセンスを作成(導出)して、これら共有ライセンスを統合して、導出されたインストール済みグループライセンスに戻す。
【0171】
共有ライセンスを作成して統合するプロセスでは、インストールされたグループライセンスが拘束されるTCSを認可する必要がある。TCSは、共有コンポーネントが共有要求をグループライセンスに照らし合わせて確認するために必要とするインストール済みグループライセンスの権利の状態を管理する。現在の権利状態が、共有要求が許可されたことを示していれば、共有ライセンスが作成されて、必要であれば委託の証明目的で委託コンポーネントに対して利用可能とされる。次に、グループライセンスの現在の権利状態を更新して、新たに作成された共有ライセンス中の権利の状態と初期状態を反映するようにする。
【0172】
共有要求次第で、様々な方法を用いて、上述したように、共有ライセンス中の権利の状態と初期状態とを作成し、また、インストールされたグループライセンスの現在の権利状態を更新する。
【0173】
共有ライセンスを返却して発信元であるグループライセンスに統合する場合、共有コンポーネントは統合要求と、この共有ライセンスの返却先であるグループライセンスを確認する。返却が許可されると、共有コンポーネントはこの要求を、グループライセンスが拘束されているTCSに送って、グループライセンスの現在の権利状態を更新する。
【0174】
以下のセクションでは、共有ライセンスを導出するプロセスと、共有ライセンスを統合して発信元のインストール済みグループライセンスに戻すプロセスをより詳細に説明する。
【0175】
権利の導出
【0176】
権利の導出とは、インストールされたグループライセンスから共有ライセンスを作成するプロセスである。共有要求は、権利の被譲与者から直接にまたは共有ライセンスが消費される予定のデバイスから間接的に来る。対象となる消費デバイスが要求時には知られていない場合、要求に起因する共有ライセンスはどの消費デバイスにも拘束されない。この場合、共有ライセンスは、これが消費またはさらなる共有目的で使用可能となる以前に拘束されなければならない。
【0177】
図37は、一般的に共有要求の一部である情報460を示す。要求タイプ461は、この要求が権利の導出要求または統合要求を示す。導出はサブ権利を作成する要求である。統合はサブ権利を返却する要求である。要求側のデバイスの情報462は権利消費デバイスを特定し、このデバイスが要求されているサブ権利を受領することを認可されていることを検証するために用いられる。デバイス情報はオプションである。要求された権利の情報463は、グループライセンスから共有されるべき権利を特定する。利用可能ライセンス464には、要求を譲与するグループライセンスと、要求を認可し、また、要求を満足させるためにライセンスを発行するために必要な他のライセンスが含まれる。
【0178】
共有要求を受信すると、権利消費デバイスは、この要求を満足するライセンスを発生しようとして機能の集合を実行する。このような機能には、要求を対象グループライセンスに照らし合わせて検証する機能、グループライセンスと関連のライセンスとを検証する機能、目標TCSに対して共有要求と関連するグループライセンスの現在の権利状態を要求する機能、要求を処理する機能および認可されたら共有ライセンスを作成する機能が含まれる。要求が認可されたら、TCS中の目標グループライセンスの権利の状態が、発信元のグループライセンス中の現在の権利状態と共有ライセンス中の権利の初期状態とにしたがって更新される。
【0179】
図38は、共有コンポーネントが共有要求を受信することで始まって、共有権利を含むライセンスを出力することで終了する共有要求処理の例示のデータフローを示す。このプロセスは多くのコンポーネントからなるが、これらはサブプロセスとデータベースである。このプロセス全体またはそのコンポーネントのいずれかは、共有コンポーネントが置かれているグループライセンスデバイスに常駐している。
【0180】
要求が消費デバイスコンポーネント470からグループライセンスデバイス471に送られ、ここで、一般的には処理される。グループライセンスデバイス471は、共有要求を処理する責任を負っている共有コンポーネントを含む。共有要求を受信すると、グループライセンスデバイスは、目標グループライセンスを、これを要求からまたはレポジトリ472から抽出することによって位置付ける。目標のグループライセンスと要求を確認して、その信憑性と整合性をステップ473で保証する。目標消費デバイスの識別に関する情報は、要求から抽出されて検証され、消費デバイスがこのような要求をすることを認可されることを保証する。目標消費デバイスは通常は、要求をする第2のデバイスである。
【0181】
要求は目標TCSから現在の権利状態に対して、共有要求はステップ474で処理される。この要求が認可されると、権利がステップ475で導出されて、この導出権利の状態477が状態マネージャ476によって更新される。図39は、権利を導出するプロセスを示す。
【0182】
権利の導出には次のステップが含まれる。
要求に適合するグループライセンスと共有可能権利を位置付けするステップ。このステップは、要求を確認するステップと、グループライセンスを位置付けするステップと、共有可能権利を特定するステップと、ライセンスを確認するステップなどを含む、
目標の共有可能権利と関連付けられた状態の集合を特定するステップと、
要求を、目標の共有可能現在の権利状態とオリジナルの状態とに照らし合わせて確認するステップと、
共有権利を作成するステップと、
共有権利を含むライセンスを作成するステップ。このライセンスは、認可されたメンバーが、グループの他のメンバーのために共有権利を作成することを許可する新しいグループライセンスであり得る。
【0183】
図39に示すように、ステップ480では、入力されたライセンスからライセンスを獲得し、また、このライセンスが共有要求を適合したことをステップ481で確認する。適合しなければ、ステップ482で、処理すべきライセンスがまだあるかどうか判定する。処理すべきライセンスがなければ、ステップ488で空(ヌル:null)という出力を返却する。ライセンスが要求と適合すれば、次のステップ483で、ライセンスから権利を獲得し、ステップ484で、この権利が分割可能であるか判定する。可能であれば、ステップ485で、この分割可能権利の分割である権利を導出する。次に、分割された権利、または分割不可能権利をステップ486で出力ライセンスに挿入する。次に、ステップ487で、処理すべき権利がまだあるかどうか判定する。なければ、出力ライセンスはステップ488で返却される。
【0184】
権利の統合
【0185】
権利の統合とは、共有ライセンスを発信元のグループライセンスに戻して統合して、その結果として新たなグループライセンスを作成するプロセスである。この権利統合プロセスは、上に開示した権利導出プロセスと類似している。権利導出と権利統合間との相違は、次の通りである。
権利の統合の場合、目標のグループライセンスに対する権利の状態が、より多くの権利を反映するように更新される。
権利の導出の場合、統合された共有ライセンスは無効となる。
導出が正しく行われた場合、新しい共有ライセンスが作成される。
【0186】
消費コンポーネント
【0187】
消費コンポーネントは消費ライセンスを消費する。上記に開示したように、消費ライセンスはまた共有ライセンスでもある。しかしながら、消費ライセンスは、共有目的ではなくて使用目的のものである。消費ライセンスを消費するには認可が必要であり、このような認可は、あらゆるDRMシステムで指定される既知のプロセスである。認可プロセスは、ライセンスに照らし合わせて要求を確認するステップと、ユーザとデバイスを認証するステップと、要求を条件の現在状態に照らし合わせて検証するステップと、使用認可された場合に条件の現在状態を更新するステップなどを含む。
【0188】
消費ライセンスは、期限切れになるまでまたは消費デバイスによって解放されるまで消費デバイスによって消費される。消費ライセンスは、一旦解放されれば、共有コンポーネントに送って、その導出元であるグループライセンスに戻して統合することが可能である。
【特許請求の範囲】
【請求項1】
DRMコンポーネントを備える消費デバイスとコミュニケーション媒体を介して接続され、この消費デバイスによる共有リソースの使用を譲与するサブ権利を指定する消費ライセンスを発行するライセンスデバイスであって、
前記ライセンスデバイスが、
共有リソースに対するライセンスであって、DRMコンポーネントを備える消費デバイス上の共有リソースの使用を譲与する少なくとも一つの使用権を指定するライセンスをインストールするインストールコンポーネントと、
共有コンポーネントを備え、
前記共有コンポーネントは、
共有リソースの使用のためのサブ権利の要求であって、サブ権利に基づいて共有リソースに対し要求されている使用を管理する前記DRMコンポーネントを備える前記消費デバイスを特定するデバイス情報を含む要求を、前記消費デバイスから受信し、
前記受信される要求を、前記ライセンス内で指定されている前記少なくとも一つの使用権に照らし合わせて確認し、
前記デバイス情報により特定されている消費デバイスが、前記要求されているサブ権利を受領することが認可されていることを検証し、
前記検証に基づいて前記サブ権利を指定する消費ライセンスを作成する、
ことを特徴とするライセンスデバイス。
【請求項1】
DRMコンポーネントを備える消費デバイスとコミュニケーション媒体を介して接続され、この消費デバイスによる共有リソースの使用を譲与するサブ権利を指定する消費ライセンスを発行するライセンスデバイスであって、
前記ライセンスデバイスが、
共有リソースに対するライセンスであって、DRMコンポーネントを備える消費デバイス上の共有リソースの使用を譲与する少なくとも一つの使用権を指定するライセンスをインストールするインストールコンポーネントと、
共有コンポーネントを備え、
前記共有コンポーネントは、
共有リソースの使用のためのサブ権利の要求であって、サブ権利に基づいて共有リソースに対し要求されている使用を管理する前記DRMコンポーネントを備える前記消費デバイスを特定するデバイス情報を含む要求を、前記消費デバイスから受信し、
前記受信される要求を、前記ライセンス内で指定されている前記少なくとも一つの使用権に照らし合わせて確認し、
前記デバイス情報により特定されている消費デバイスが、前記要求されているサブ権利を受領することが認可されていることを検証し、
前記検証に基づいて前記サブ権利を指定する消費ライセンスを作成する、
ことを特徴とするライセンスデバイス。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【公開番号】特開2012−256374(P2012−256374A)
【公開日】平成24年12月27日(2012.12.27)
【国際特許分類】
【出願番号】特願2012−207729(P2012−207729)
【出願日】平成24年9月21日(2012.9.21)
【分割の表示】特願2008−537726(P2008−537726)の分割
【原出願日】平成18年10月4日(2006.10.4)
【出願人】(500470703)コンテントガード ホールディングズ インコーポレイテッド (54)
【氏名又は名称原語表記】ContentGuard Holdings, Inc.
【公開日】平成24年12月27日(2012.12.27)
【国際特許分類】
【出願日】平成24年9月21日(2012.9.21)
【分割の表示】特願2008−537726(P2008−537726)の分割
【原出願日】平成18年10月4日(2006.10.4)
【出願人】(500470703)コンテントガード ホールディングズ インコーポレイテッド (54)
【氏名又は名称原語表記】ContentGuard Holdings, Inc.
[ Back to top ]