(57)【要約】【課題】自己組織型サービスネットワークの形成に寄与するポリシー管理されたピアツーピアサービス編成を行うためのシステム及び方法。【解決手段】サービスがピアツーピア通信ノードに配信され、各ノードからメッセージポンプ及びワークフロー照合部を使用してメッセージのルーティング及び編成を提供する。ピアツーピアメッセージング及びワークフロー照合部により、動的にサービスを生成可能である。共有リソースは、UDDI、SOAP、及びWSDLに搭載されたウェブサービス展開で一般的にサポートされるものを超えた異なるサービスインタフェースバインディングを使用した、多様なタイプのサービスである。ノードが互いを検出し、インタラクションし、価値を交換し、WANからPANまでのネットワークレイヤにわたり相互運用することが可能なメディアサービスのフレームワークが提供される。【選択図】図１
2014146345.tif 000002
【特許請求の範囲】
【請求項１】
ａ．第１発見可能バインディングを介して、第１サービスを提供する第１サービスプロバイダの第１サービス適応レイヤから、ネットワークピアにアクセスできるようにする第１サービスインタフェースを公開し、
ｂ．サービス消費部の第１サービスアクセスポイントから、前記第１サービスプロバイダにより公開される前記第１サービスインタフェースにアクセスし、前記第１バインディングを発見し、及び、そのバインディングを用いることにより前記第１サービスを呼び出し、
ｃ．第１ワークフロー照合部を用いて、前記第１サービスプロバイダに、前記第１サービス消費部のための前記第１サービスを実行できるために必要なステップを編成し、
ｄ．信用管理証明書を用いて、認証されたサービス消費部のみによるアクセスのために第１サービスを保証し、
ｅ．信用管理証明書を用いて、前記第１サービスへの限定アクセスを提供する制御プログラムを実行することを有し、
前記第１アクセスポイントは、前記第１サービスへの認証アクセスのための前記第１サービス消費部を証明するために信用管理証明書を使用する方法。
【請求項２】
前記信用管理証明書は、Ｘ．５０９証明書である請求項１に記載の方法。
【請求項３】
前記信用管理証明書は、ＳＳＬ証明書である請求項１に記載の方法。
【請求項４】
サービスを編成する方法において、
ａ．サービス消費部の第１サービスアクセスポイントから、第１サービスを提供する第１サービスプロバイダにより公開され、第１発見可能バインディングを介して、ネットワークピアにアクセスできるようにするために操作可能である第１サービスインタフェースへアクセスし、
ｂ．前記第１発見可能バインディングを発見し、かつ、
ｃ．そのバインディングを用いることにより前記第１サービスを呼び出すことを有し、
前記第１サービスを実行するために必要なステップは、第１ワークフロー照合部を用いて編成される方法。
【請求項５】
前記第１サービスは、遠隔インターネットベース・サーバに位置する暗号化されたメディアコンテンツへの限定アクセスを提供し、かつ、第１ワークフロー照合部は、第１サービス消費部が前記コンテンツへのアクセスを認証されているかどうかを検証し、そうであるならばコンテンツ所在位置を突き止め、かつ、第１サービス適応レイヤを介して該コンテンツを第１サービス消費部に提供するする第１制御プログラムを含む請求項４に記載の方法。
【請求項６】
ａ．第１発見可能バインディングを介して、第１サービスを提供する第１サービスプロバイダの第１サービス適応レイヤから、ネットワークピアにアクセスできるようにする第１サービスインタフェースを公開し、
ｂ．第１サービス消費部の第１サービスアクセスポイントから前記第１サービスのための要求を受け取り、かつ、
ｃ．第１ワークフロー照合部を用いて、前記第１サービスプロバイダに、前記第１サービス消費部のための前記第１サービスを実行できるために必要なステップを編成することを有する方法。
【請求項７】
ａ．第１発見可能バインディングを介して、第１サービスを提供する第１サービスプロバイダの第１サービス適応レイヤから、ネットワークピアにアクセスできるようにする第１サービスインタフェースを公開し、
ｂ．第１サービス消費部の第１サービスアクセスポイントから前記第１サービスのための要求を受け取り、
ｃ．信用管理証明書を用いて、認証されたサービス消費部のみによるアクセスのために第１サービスを保証し、
ｄ．信用管理証明書を用いて、前記第１サービスへの限定アクセスを提供する制御プログラムを実行し、
ｅ．第１ワークフロー照合部を用いて、前記第１サービスプロバイダに、前記第１サービス消費部のための前記第１サービスを実行できるために必要なステップを編成することを有する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
＜関連出願＞
本出願は、同一出願人による、２００３年６月５日に出願のウイリアム・ブラッドリー及びデビッド・マーヘルによる「ピア・ツー・ピア・サービス編成のシステム及び方法」という表題の米国仮特許出願番号６０／４７６，３５７、及び、２００３年９月１５日に出願のジル・ボッコンギボによる「デジタル権利管理エンジンシステム及び方法」という表題の米国仮特許出願番号６０／５０４，５２４からの優先権を主張し、そして、その２つの出願は参照により全体としてここに含まれる。これらの２つの仮特許出願は、本明細書及び記述の部分を形成し、付記Ａ及びＢとして、それぞれここに付け加えられる。
【０００２】
＜著作権許可＞
本特許文書の公開部分に著作権保護の対象となる資料が含まれている。著作者は、特許商標庁の特許ファイル又は記録にあるように、いかなる者による特許文書の複写又は特許公開に対して異議を有さないが、それ以外はどのようなものであれ、全著作権を留保する。
【背景技術】
【０００３】
インターネット等のネットワークは、デジタルコンテンツやメディア関連の配信の主要なメディアとなっている。標準ウェブサービスプロトコルの出現によりこの傾向が加速することが期待され、それにより企業は、複数のソフトウェアプラットフォーム間を相互運用できるサービスの提供と、標準化機構を介したビジネスサービスと消費者との間の協調に対するサポートを可能にする。
【０００４】
しかし、メディア関連サービスにおいて相互運用可能（interoperable）でセキュア（secure）な世界を目指すにあたり、大きな障壁が存在する。例えば、複数の重複するデファクト・スタンダードあるいは正式に認められたスタンダードは、同じ基本的な相互運用性又は相互接続問題に対応するための一般的には標準と認められていない、あるいは互換性のない、代替の技術的アプローチを選択する異なる実装を課すことにより、実際には複雑でない相互運用性が抑制される。一部では、これらの非互換性は異なる世代の技術を統合しようと試みたことから発生したと考えられるが、その他では、同時期ではあるが異なるロケール、異なる必要条件で活動する複数のグループによって行われた市場の選択が問題の原因となっている。このため、標準化にもかかわらず、必要とされるサービスを提供する機器を設置、接続し、交信することはしばしば困難である。さらに、異なる委託サービスと保護モデル間の非互換性の問題が頻繁にある。
【０００５】
ＷＳＤＬ（ウェブサービス記述言語）等の新たなウェブサービス・スタンダードが、インターネット向けシステムの問題のいくつかに対して取り組み始めているが、そのようなアプローチは不完全である。それらのスタンダードでは、家庭、企業及び業界部門のゲートウェイ等のパーソナル及びローカルエリアネットワークやワイド・エリア・ネット・ワークにおける複数のネットワークレイヤ全体の問題を扱うことができない。又は、さまざまなサービスインタフェースの結合（例、CORBA、WS-I、Java（登録商標）RMI、DCOM、C関数呼び出し、.NET等）を使用し、単純及び複雑なサービスでの動的な編成（orchestration）に基づく相互運用性に関する必要性を適切に扱うこともできていないため、多くのレガシーアプリケーションの統合が制限されている。幅広く展開され導入されたピア・ツー・ピア（P2P）アプリケーションとネットワークの出現は、１つにはデジタルコンテンツの使用権の主張と実行方法の統一された概念がないという事実にため、相互運用可能なメディア関連サービスの作成に対する課題をさらに作り上げている。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】「SOAP Version 1.2 Part 2: Adjuncts」、W3C Recommendation 24 June 2003  （http://www.w3.org/TR/2003/REC-soap12-part2-20030624/）
【非特許文献２】「XML Schema」  12 September 2005  （http://www.w3.org/2001/XMLSchema）
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ここに記述されるシステム及び方法の実施例は、前述の問題の一部又は全てに対応するために使用可能である。実施例の一つにおいて、公開されたサービスインタフェースを介しリッチ（rich）かつ動的な方法で、消費者又は企業メディアスペース（例、消費者、コンテンツプロバイダ、機器製造業者、サービスプロバイダ）の複数の種類の利害関係者に、お互いを探し出し、信頼関係を築き、価値を交換することができるサービスフレームワークを提供する。一般的にメディア編成のネットワーク環境（ＮＥＭＯ：Network Environment Media Orchestration）と呼ばれるこのフレームワークの実施例は、異機種の消費者機器、メディアフォーマット、通信プロトコル及びセキュリティ機構を取り扱う分野において、相互運用可能で、セキュアなメディア関連の電子商取引を可能とするプラットフォームを提供できる。サービスインタフェースの分散ポリシー管理は、信頼とセキュリティをもたらすことを促進するために使用でき、その結果、商業的な価値の交換を容易にする。
【０００８】
新たなウェブサービス基準が、インターネット上でのサービスの相互運用性の問題に対応し始めているが、NEMOの実施例は、家庭、企業及び業界部門のゲートウェイ等のパーソナル及びローカルエリアネットワークや、ワイドエリアネットワークでの複数ネットワークレイヤの相互運用性に対応するために使用可能である。例えばNEMOは、携帯電話、ゲームプラットフォーム、PDA、パソコン、ウェブベースのコンテンツサービス、ディスカバリ・サービス（discovery servise）、通知サービス及び更新サービスを使用した１つの相互接続システムにおける相互運用性を提供できる。NEMOの実施例はさらに、さまざまなローカル及びリモートインタフェースの結合（例、WS-1 [1] 、Java（登録商標） RMI、DCOM、C、Net等）を用いた、単純及び複雑なサービス両方の動的なピア・ツー・ピア編成（peer to peer orchestration）を提供するために使用可能で、それにより、レガシーアプリケーションの統合が可能となる。
【０００９】
メディアの世界において、利害関係者（コンテンツ発行者、販売業者、小売業務、消費者機器プロバイダ及び消費者）内の主要なグループにより必要とされ、好まれるシステムとインタフェースは、多くの場合様々に異なる。そのため、これらのエンティティ（entity）により提供される能力を、関与するエンティティの必要性を満たす最適な構造へと即時に発展できる総合的なサービスへとまとめることが望ましい。
【００１０】
例えば、（とりわけ）Bluetooth（登録商標）、UPnP、Rendezvous、JINI、UDDI及びLDAP等のさまざまなサービス・ディスカバリ・プロトコルやレジストリは、同じサービス内で共存でき、各ノードがそのノードをホストする機器に最も適したディスカバリ・サービスを使用することを可能とする。他にはIPベース機器、ワイヤレスSMS通知、さまざまなメディアフォーマット（MP4、WMF等）に対応するサービスもあるだろう。
【００１１】
NEMOの実施例は、ピア・ツー・ピア（P2P）サービス編成を使用してこれらの目標を果たす。P2Pフレームワークの有利性は、音楽や映像の配布等で見受けられる一方、P2P技術はさらに広範囲に使用できる。
【００１２】
ウェブサービスの活動の大半は、比較的静的なネットワーク構成とクライアント側とのサービス交流のほか、マシン同士の交流に焦点を合わせてきた。NEMOはまた、個人がその人のパーソナルエリアネットワーク（PAN）部分を持ち、LAN又はその他のPAN付近へ移動し、ピアを基準としさらに多くのサービスと接続できるばかりでなく即座にサービスアクセスを再構成することを望む状況を取り扱うことができる。
【００１３】
メディアやその他さまざまな企業システムサービスの中にも機会は存在し、特に２つ以上の企業間での交流にその機会は存在する。企業は、ほとんどの場合階層的に編成され、それらの情報システムはその組織を反映したものであるが、異なる企業の人々は多くの場合、ピア型のインタフェースを介してより効果的に交流できる。例えば、会社Ａの受注担当者／サービス担当者は、会社Ｂの出荷担当者と直接話すことにより問題を解決し、及び、有益な情報のより直接的な入手することができる。横断階層及び不要なインタフェースは一般的に実用的ではない。（FedExやUPS等の）輸送会社はこれに気付き、それらの工程に直接的な視認性を許し、顧客が直接事象を監視できるようにした。会社や市政機関は企業ポータルを通じてサービスを編成し、セルフサービスの粗野な形式を可能とした。
【００１４】
しかし、既存のピア・ツー・ピア・フレームワークでは、その顧客や供給者が自然な同等なレベルで交流することを可能とし、それらのエンティティが自分たちに最も適した方法で企業のサービスを編成することができるように、ある企業に、その顧客や供給者にさまざまなサービスインタフェースを公開することを許さしていない。これは例えば、それらのピア・インタフェースのある形式の信頼管理を必要とするだろう。本発明の好ましい実施例は、サービスインタフェースのこのP2P公開を許可するだけでなく、促進することに使用できる。
【課題を解決するための手段】
【００１５】
DRM（デジタル著作権管理）等の特定のアプリケーションとの関連において、NEMOの実施例は、クローズ（close）で同種のDRMシステムの欠陥や制限を扱うように設計された、サービス指向アーキテクチャを供給するために使用できる。好ましい実施例は、異種の消費者機器、メディアフォーマット及びセキュア機構のための相互運用可能で、セキュアなメディア関連取引及び運用を提供するために使用可能である。
【００１６】
保護されたコンテンツを取り扱うための比較的高性能で負荷の高いクライアント側のエンジンを必要とする多くの従来型のDRMシステムとは対照的に、本発明の好ましい実施例は、クライアント側のDRMエンジンを比較的単純にし、サービスレベルで操作することのできる、よりリッチなポリシー管理システム（richer policy management system）により設定される支配ポリシー（governance policy）を実施する。本発明の好ましい実施例は、また、メディアフォーマットと暗号化プロトコルの選択において、より高い柔軟性を供給でき、そして、DRMシステム間の相互運用性を容易にすることができる。
【００１７】
単純でオープンな柔軟性のあるクライアント側のDRMエンジンは、力強いDRM対応アプリケーションを構築するために使用できる。実施例の１つでは、DRMエンジンはウェブサービスアプリケーションに容易に統合され、またどのようなホスト環境やソフトウェアキテクチャにも実質的に統合されるよう設計される。
【００１８】
サービス編成は、相互運用性の障壁を乗り越えるために使用される。例えば、コンテンツ検索がある場合、その要求を満たすために、さまざまなサービス（例、ディスカバリ、検索、照合、更新、権利交換及び通知）を統合可能である。編成能力の好ましい実施例により、ユーザは動的な複数レイヤのネットワークにおいて、どの時点であっても、あらゆる機器から全ホーム及びインターネットベースのコンテンツキャッシュを見ることができる。この能力は、ストリームとプレイリストの共有を容易にするするために拡張でき、ユーザの権利が尊重される一方、多くの異なる機器を使用し、即座のブロードキャスト及びナローキャストを容易に発見及び接続させる。NEMOの好ましい実施例では、メディアフォーマット、著作権管理及び実現プロトコルのスタンダードの単一セットに依存しないエンド・ツー・エンド相互運用メディア配信システムを提供する。
【００１９】
コンテンツ発信者、販売業者、小売業者、サービスプロバイダ、デバイスメーカ及び消費者を含む価値連鎖では、各区分において多くの局部的なニーズがある。これは特に、コンテンツ発信者が、異なる流れに沿った価値連鎖要素に、さまざまな状況を異なって適用する著作権の使用を提示する可能性がある著作権管理において当てはまる。消費者ゲートウェイには通常、より限定された懸念があり、エンドユーザの機器にはまだ単純な懸念、すなわちコンテンツの再生という懸念がある。十分自動化された動的に自己構成された配信サービス・システムにより、コンテンツ発信者は、どこにおいてもまたどの種類の機器を使用しているかにもかかわらず、コンテンツ制作及びパッケージ化を行い、著作権を提示したり、また関心のある消費者に瞬時にコンテンツを供給するその他のサービスプロバイダによって付加された価値に確信を持って依存することができる。
【００２０】
NEMOの好ましい実施例は、完全に統制されたエンド・ツー・エンド基準の一式を待つ又はそれに依存することなく、消費者とサービスプロバイダの両者に利益をもたらす新しいサービスを作り出し導入する複数のサービスプロバイダに手段を提供することで、この目標を達成する。ポリシー管理は、海賊版がそれらの合法サービスを利用できる範囲を制限できる。NEMOは、ネットワーク効果に、賊版が提供できるものよりもさらに優れた価値を提供する極めて豊富な合法サービスのセットの発展を容易にすることができるを可能にする。
【００２１】
下記を含む多くのNEMO実施例に共通する「最良形態」技術のいくつかを次に議論する。
・複雑な機器指向ポリシーとサービス指向のポリシーの区別
・より単純なサービスからより高度化したサービスの構成
・動的な構成及びサービスの広告
・異機種環境におけるさまざまなサービスの動的な発見と実行
・単純な機器からゲートウェイサービスを利用
【００２２】
NEMOフレームワークとの併用が可能な新しい種類のDRMエンジンとアーキテクチャを導入することができる。このDRMシステムは以下の目標の一部又は全てを達成するために使用できる。
【００２３】
簡潔さ。ある実施例では、制御プログラム（例、管理ポリシーを実施するプログラム）を実行する、必要最低限度のスタックベースのバーチャルマシン（VM）を使用したDRMエンジンが提供される。例えば、VMは数ページのコードのみから構成されても良い。
【００２４】
モジュール性。ある実施例では、DRMエンジンはより大きなDRM対応アプリケーションへ統合される１つのモジュールとして機能するよう設計される。かつて（暗号化サービスなどの）巨大なDRMカーネルにより実行された機能の多くは、ホスト環境から要求され、そのホスト環境は、その他のコードモジュールにこれらのサービスを提供しても良い。これにより設計者は、比較的容易に標準又は独自に開発した技術を組み込むことができる。
【００２５】
柔軟性。モジュールタイプの設計であるために、DRMエンジンの好ましい実施例を、組み込み機器から汎用PCまで、広く多様なソフトウェア環境で使用することができる。
【００２６】
開放性（open）。DRMエンジンの実施例は、参照ソフトウェアとしての使用に適しているため、コードモジュール及びAPIは、ユーザにより、事実上あらゆるプログラミング言語、及び、ユーザが完全に制御するシステムに導入することができる。ある実施例では、システムは、ユーザに特定のコンテンツ・フォーマットを導入するよう強要したり、コンテンツのエンコーディングを制限したりすることはない。
【００２７】
意味的に不可知（semantically agnostic）。ある実施例では、DRMエンジンは、承認要求をグラフ（graph）構造についての検索に変換する、単純なグラフベースモデルに基づく。グラフの頂点はシステムのエンティティを表し、そして、有向辺は、これらのエンティティ間の関係を表す。しかし、DRMエンジンは任意のアプリケーションにおいてこれらの頂点や辺の意味を認識しなくてもよい。
【００２８】
ウェブサービスとの円滑な統合。DRMクライアントエンジンはいくつかの方法でウェブサービスを使用することができる。例えば、グラフの頂点や辺をサービスにより動的に検出することも可能である。なお、コンテンツ及びコンテンツのライセンスは、高度なウェブサービスを通じて検出されDRMエンジンへ配信される場合がある。DRMエンジンの実施例の１つは、複数の箇所でウェブサービスを利用するように構成可能であるが、そのアーキテクチャはウェブサービスとは別のものであるため、独立してクライアント側のDRMカーネルとして使用することができる。
【００２９】
簡易化した鍵管理。ある実施例では、グラフトポロジーは暗号の再標的化を必要とせずに、コンテンツ保護鍵の導出を簡略化するために再利用できる。鍵導出方法はDRMエンジンのオプションではあるが強力な機能である。システムはまた、あるいは代替として、その他の鍵管理システムに統合することができる。
【００３０】
管理、暗号化、コンテンツの区別。ある実施例では、コンテンツを管理するコントロール（control）は、管理を実施するために使用される暗号化情報と論理的に区別される。同様に、制御と暗号化情報はコンテンツとコンテンツ・フォーマットから論理上区別される。これらの各要素は別々又は１つにまとめられたパッケージで配信できるため、コンテンツ配信システムの設計において、高度な柔軟性を可能とする。
【００３１】
NEMOフレームワーク、そのアプリケーション及びそのコンポーネント部品の実施例をここに記述する。そのコンポーネントとアプリケーションの多くがそうであるように、フレームワーク自体は新しい種類であることを理解する必要がある。また本発明は、処理、器具、システム、機器、方法、コンピュータで読み込むことのできるメディア又はこれらの組合せなどの数々の方法で導入できることを十分理解する必要がある。これらとその他の特長及び有利性は、以下の詳述と、発明主体の原理を一例として説明する添付の図面でより詳細に示す。
【図面の簡単な説明】
【００３２】
【図１】システムフレームワークの見本の実施例を説明する図である。
【図２Ａ】システムノードの概念的ネットワークを説明する図である。
【図２Ｂ】P2Pネットワークのシステムノードを説明する図である。
【図２Ｃ】インターネット上で操作するシステムノードを説明する図である。
【図２Ｄ】システム・ゲートウェイ・ノードを説明する図である。
【図２Ｅ】システム・プロキシ・ノードを説明する図である。
【図２Ｆ】システム機器アダプタ・ノードを説明する図である。
【図３】DRM機器の概念的ネットワークを説明する図である。
【図４】概念的DRMノード承認グラフを説明する図である。
【図５Ａ】システム・ノードのアーキテクチャの概念的図を説明する図である。
【図５Ｂ】システム・ノードのサービス適応レイヤでサポートされる、複数のサービスインタフェース・バインディングを説明する図である。
【図６Ａ】サービス提供システム・ノードとサービス消費システム・ノードの基本的な相互関係を説明する図である。
【図６Ｂ】サービス提供システムノードとサービス消費システムノードの相互関係のもう１つの例を説明する図である。
【図７Ａ】クライアント側のWSDL交信に関連するサービス・アクセス・ポイントを説明する図である。
【図７Ｂ】クライアント側のネイティブ交信に関連するサービス・アクセス・ポイントを説明する図である。
【図７Ｃ】サービス側のポイント・ツー・ポイント交信パターンに関連するサービス・アクセス・ポイントを説明する図である。
【図７Ｄ】サービス側のポイント・ツー・マルチポイント交信パターンに関連するサービス・アクセス・ポイントを説明する図である。
【図７Ｅ】サービス側のポイント・ツー・中継交信パターンに関連するサービス・アクセス・ポイントを説明する図である。
【図８】サービスアダプテーションレイヤのアーキテクチャの実施例を説明する図である。
【図９Ａ】外部サービスプロバイダに依存するワークフロー照合部の交信パターンを説明する図である。
【図９Ｂ】クライアントノードとの直接的な多レイヤ通信に関係した、ワークフロー照合部の交信パターンを説明する図である。
【図９Ｃ】ワークフロー照合部のノード内部の基本的な交信パターンを説明する図である。
【図９Ｄ】ワークフロー照合部の比較的複雑な交信パターンを説明する図である。
【図１０】DRMエンジンのシステム統合を説明する図である。
【図１１】DRMエンジンのアーキテクチャの実施例を説明する図である。
【図１２Ａ】クライアント側のシステム・ノード内のDRMエンジンと関連要素を説明する図である。
【図１２Ｂ】サービス側のシステムノード内のDRMエンジンと関連要素を説明する図である。
【図１３】コンテンツ保護と管理DRMオブジェクトの実施例を説明する図である。
【図１４】ノードとリンクDRMオブジェクトの実施例を説明する図である。
【図１５】DRM暗号鍵要素の実施例説明する図である。
【図１６】クライアントとサービス提供システムノード間の基本的な交信パターンを説明する図である。
【図１７Ａ】通知ハンドラサービスをサポートするノードの発見、通知処理ノードの一式を説明する図である。
【図１７Ｂ】通知配信のプロセスを説明する図である。
【図１８Ａ】要求ノードが目的のサービス提供ノードに対してサービス発見要求を行う、クライアント駆動のサービス発見シナリオを説明する図である。
【図１８Ｂ】要求ノードがサービス提供ノードと共に、その記述を登録しようと求めるピア登録サービス発見シナリオを説明する図である。
【図１８Ｃ】関与するノードがサービス利用（例、サービス提供ノード内のサービスの存在）の変化の通知を受け取る、イベントベースのサービス発見シナリオを説明する図である。
【図１９Ａ】暗黙のうちに信頼されるチャネルのサービスバインディングを使用し、信頼を築くプロセスを説明する。
【図１９Ｂ】要求/応答モデルを基に、信頼を築くプロセスを説明する図である。
【図１９Ｃ】セキュア信用証明物の明白な交換を基に、信頼を築くプロセスを説明する図である。
【図２０】ポリシー管理されたサービスへのアクセスを説明する図である。
【図２１】メンバーシップと鍵アクセスリンクを含んだ見本DRMノードグラフを説明する図である。
【図２２】DRM VMコードモジュールのフォーマットの実施例を説明する図である。
【図２３】システム機能のプロファイル階層を説明する図である。
【図２４】DRM音楽プレーヤーアプリケーションにおけるシナリオを説明する図である。
【発明を実施するための形態】
【００３３】
本発明の一連の実施例は、参照数字が構造要素を指す以下にある添付の図面と併せ、以下の詳細な記述を参照することにより容易に理解である。
【実施例】
【００３４】
発明本体の詳述を下記に挙げる。この説明はいくつかの実施例と併せて示される一方、進歩的な一連の構成は、ある１つの実施例に制限されるばかりでなく、多くの代替案、変更及び同等物を網羅することを理解する必要がある。例えば、いくつかの実施例は消費者指向のコンテンツ及びアプリケーションに関連して説明される一方、技術に熟練した者は、公開されたシステムと方法は容易により幅広いアプリケーションに適応できることを認識するだろう。例えば、制限なしにこれらの実施例は企業のコンテンツやアプリケーションの状況に容易に適応、又は応用できる。さらに、数々の具体的な詳細が、独創的な一連の製作物を完全理解するために以下の説明に示される一方、いくつかの実施例は、これらの一部又は全ての詳細なしに実施できる可能性がある。その上、明確にするために、不必要に独創的な一連の製作物を不明瞭にすることを避けるために、当技術分野では周知のある一定の技術資料は詳細に説明されていない。
【００３５】
１．概念
１．１  ウェブサービス
ウェブサービスアーキテクチャ（WSA）はサービス指向アーキテクチャ（SOA）の特定のインスタンスである。SOA自体は、柔軟結合された協調ソフトウェアエージェントで構成される分散システムの一種である。SOAのエージェントはサービスを提供、サービスを要求（消費）、又はその双方を行う場合がある。サービスは、サービスプロバイダの役割を行うエージェントにより管理される、明確な自己完結の操作セットとして見ることができる。操作は、標準プロトコルとデータ・フォーマットを使用し、エンドポイントと呼ばれるいくつかのネットワークのアドレス可能な場所において、ネットワーク上で呼び出される。自己完結に関しては、サービスはその他のサービス又は包括的なアプリケーションの状態や状況に直接的に依存しないことを意味する。
【００３６】
CORBA、DCOM及びJ2EEを含むSOAの概念を裏づけする確立された技術の例。WSAは、特定のプラットフォーム、プログラミング言語、アプリケーションプロトコルスタック又はデータ・フォーマット変換に頼らないため、魅力的である。WSAは、サービスを記述し、プロバイダと消費者間の柔軟結合と相互運用性を容易にするメッセージを交換するXMLに基づいた、標準フォーマットを使用し、潜在的に全世界に分散するシステムの配置と参加を促す、複数の標準インターネットプロトコル（とりわけHTTP）をサポートする。
【００３７】
新生の動向としては、「プラグアンドプレイ」サービスバスというコンテキスト（context）で、SOAを見ることである。サービスバスの取り組みは、記述、メッセージング、移送基準を利用し、サービスの編成に備える。インフラストラクチャはまた、発見、変換、セキュアのほか、おそらくその他の基準を組み込むことができる。WSAに組み込まれた偏在するスタンダードに本来備わっている質により、インフラストラクチャは柔軟性、伸張性があり、拡張可能であるため、調整されたサービスバスモデルを構築するための適切な基盤を提供できる。このモデルでは、ワーク（サービス）の基本的な単位はウェブサービスと呼ばれる。
【００３８】
ウェブサービスには多くの定義がある。以下の定義は、ワールド・ワイド・ウェブ・コンソーシアム（W3C）ウェブサービスアーキテクチャ作業草案（2003年8月8日−www.w3.org/TR.ws-arch参照）に由来する。
【００３９】
ウェブサービスは、ネットワーク上の相互運用可能な、マシン同士のインタラクションをサポートするように設計されたソフトウェアシステムである。ウェブサービスは、マシンで処理できるフォーマット（具体的にはWSDL）で記述されたインタフェースを持つ。他のシステムは、その他のウェブ関連の基準と併せたXMLシリアライゼーションのHTTPを使用し、一般的に伝達されるSOAPメッセージを使用した記述で規定される方法で、ウェブサービスとインタラクションする。
【００４０】
Ｗ3Ｃ定義は、有益な開始ポイントを提供する一方、「ウェブサービス」という用語は、例えば特定のスタンダード、フォーマット及びプロトコル（例、WSDL、SOAP、XML、HTTPなど）の使用に対し、制限なく幅広い意味でここでは使用されることを理解する必要がある。
【００４１】
特定のウェブサービスは、サービスプロバイダとサービス・リクエスタ間の（一時的である可能性がある）関係の基盤を提供する、論理的に整合性のある操作セットのための抽象的なインタフェースとして表すことができる。
【００４２】
もちろん、実際のウェブサービスは具体的な実装を有する。プロバイダの具体的な実装は、（ウェブサービスとは区別され）サービスと呼ばれることもある。サービスプロバイダの機能を実際に実行するソフトウェアは、プロバイダエージェントで、サービスの要求元の機能を実際に実行するソフトウェアは、リクエスタ・エージェントである。エージェントを所有する個人又は組織を、必要に応じてプロバイダエンティティ又はリクエスタエンティティと呼ぶ。それ自身で使用された場合、リクエスタ又はプロバイダは状況により、それぞれエンティティ又はエージェントと呼ばれる場合がある。
【００４３】
ウェブサービスは目的を果たすために存在し、どのようにこれが達成されるかは、特定のウェブサービスメッセージ交換の構造とセマンティック（semantic）で特定される。構造は、ネットワーク上で起こるメッセージ交換を可能にする、正確なマシンで処理可能な技術仕様を意味する。構造は正確に定義することができるが、セマンティックはそうはいかない場合がある。セマンティックは、どのような形で存在しようと、ウェブサービスのリクエスタとプロバイダエンティティ間の理解と全体的な要求を管理する、明白な又は暗黙の「規約（contract）」を意味する。
【００４４】
ウェブサービスは多くの場合、３つの役割の相互関係の観点から表せる：（i）サービスプロバイダ；（ii）サービス・リクエスタ；及び（iii）サービスレジストリ。このモデルでは、サービスプロバイダは、サービスレジストリにウェブサービスに関する記述情報を「公開する」。サービス・リクエスタは、あるディスカバリ・メカニズムを通じてこの情報を「発見」、次にこの情報を使用し、サービスを利用するサービスプロバイダに「バインドする」。バインディング（binding）は単に、公開されたサービス記述でプロバイダが特定するメッセージフォーマッティング、データマッピング及びトランスポート・プロトコル仕様を使用し、プロバイダによって利用可能となる操作をリクエスタが呼び出すことを意味する。この情報を記述するために使用されるXMLベースの言語は、（ウェブサービス記述言語：WSDL）と呼ばれる。
【００４５】
サービスプロバイダは、WSDLサービス記述で記述される特定の目的のための、いくつかの操作セットへのアクセスを与える；このサービス記述は多くの手段のうちのどれかによってレジストリに公開されているため、サービスが発見される可能性がある。レジストリは特定のドメイン内において公開される又は非公開とされる場合がある。
【００４６】
サービスレジストリは、以前公開されたサービス記述を返すことで、サービス検索要求に応じるソフトウェアである。サービス・リクエスタは、レジストリから得たWSDLに指定されるバインディング情報に沿って、プロバイダから与えられたさまざまな操作を呼び出すソフトウェアである。
【００４７】
サービスレジストリは概念的にのみ存在する場合と、特定のサービスをクエリ、場所を見つけ及びバインドするために使用される、サービス記述のデータベースを提供する現実のソフトウェアとして事実上存在する場合がある。しかし、リクエスタが実際にサービスのアクティブな検索を行おうと、サービス記述が静的又は動的に与えられようと、レジストリはウェブサービスモデルにおける論理的にはっきりと識別されることのできる側面である。現実世界の実装では、サービスレジストリは、サービス・リクエスタのプラットフォーム、又はサービスプロバイダのプラットフォームの一部である場合があること、もしくはあるよく知られたアドレスもしくはその他の手段によって提供されるアドレスにより、完全に識別される別の場所に存在する場合があることは注目に値する。
【００４８】
WSDLサービス記述は疎結合（loose coupling）に対応するもので、しばしばSOAの真のテーマとなる。サービス・リクエスタは、目的の結果を達成するためにかかるサービスのインタフェースのセマンティックを最終的には理解する一方、そのサービス記述は、特定のサービス・バインディング情報からサービスインタフェースを分離し、極めて動的なウェブサービスモデルをサポートする。
【００４９】
サービス指向のアーキテクチャは、多くの可能性のある技術レイヤ上に構築することができる。現在行われているようにウェブサービスは通常、以下の技術形態を組み入れる、又は、含んでいる。
【００５０】
HTTP−ほとんどのウェブサービス通信向けの標準アプリケーションプロトコル。ウェブサービスはさまざまなネットワークプロトコル（例、SMTP、FTPなど）に展開できるが、HTTPは使用されているもののなかで最も偏在する、ファイヤーウォールとなじみ易いトランスポートである。一部のアプリケーション、特にイントラネット内では、他のネットワークプロトコルの方が必要条件によって道理にかなう場合がある。それにもかかわらずHTTPは、今日構築されているほとんど全てのウェブサービスプラットフォームの一部である。
【００５１】
XML−構造化された情報のコンテンツ（及びコンテンツに関する情報）をフォーマットしアクセスするためのスタンダード。XMLは、ウェブサービスエージェント間の情報を通信するための、テキストベースのスタンダードである。ここで留意すべき点は、XMLの使用は、ウェブサービスのメッセージペイロードが少しもバイナリデータを含んでいない可能性があることを意味するのではなく、このデータはXML仕様に沿ってフォーマットされることを意味する、ということである。ほとんどのウェブサービスアーキテクチャは、必ずしもメッセージとデータが文字ストリームにシリアル化することを指示するわけではない−それらは適切であれば、バイナリデータにシリアル化される可能性もある−しかしXML使用の場合、これらのストリームはXML文書を意味する。つまり、トランスポート機構のレベルに関係なく、ウェブサービスメッセージングはしばしば、XML文書を使用して行われる。
【００５２】
多くのウェブサービスに特に重要な、２つのXMLサブセット技術は、XMLネームスペース（XML Namespaces）とXMLスキーマ（XML Schema）である。XMLネームスペースはネーミングの重複を解決し、XML文書に含まれる要素に特定の意味を有効にするために使用される。XMLスキーマは、XML文書内に含まれるさまざまな情報項目を定義及び制約するために使用される。これらの目的を他の手段で達成することは可能（及び任意）であるが、XMLの使用は恐らく今日使用されている最も一般的な技術である。ウェブサービス文書自体のXML文書フォーマットは、XMLスキーマを使用し定義され、最も多く現実的に利用されているウェブサービス操作とメッセージ自体も、XMLスキーマを組み入れた形でさらに定義される。
【００５３】
SOAP−他方の受信側へ送信し処理される特別にフォーマットされたパッケージに指示と情報をカプセル化するための、XMLベースのスタンダード。ソープ（SOAP）（簡易オブジェクトアクセスプロトコル）は、エージェント間で送信するためのウェブサービスメッセージをパッケージ化するための標準機構である。多少誤った名称であるが、その名残は、分散型オブジェクトを呼び出す手段であり、その点においてその他の代替物と比べ確かに「より簡易」である。しかし最近の傾向としては、頭字語の本来の意味を超えるために、SOAPはXMLベースのワイヤプロトコル（wire protocol）と考えられる。
【００５４】
SOAPは、メッセージを構築しコンテンツに関する意味を提供するための、比較的重要でない仕様を定義する。各SOAP文書は、ヘッダとボディに分けられるエンベロープを持つ。構造上は類似しているが、ヘッダは通常、ボディに含まれるコンテンツの処理に関連する受信側のメタ情報又は指示に使用される。
【００５５】
SOAPはまた、機能と機能の責任を果たすために必要な処理を識別するための手段を特定する。メッセージ交換パターン（MEP）は、ノード間でどのようにメッセージが交換されるかといったパターンを定義する機能である。一般的なMEPは要求に応答し、要求と応答ノード間の単独で完全なメッセージ取引を確立する（http://www. w3.org/TR/2003/REC-soap12-part2-20030624#soapsupmepを参照。）。
【００５６】
WSDL−ウェブサービスの使用方法を説明するXMLベースの標準。WSDLの観点からすれば、サービスはサービス・リクエスタとプロバイダ間で交換されるメッセージの一式に関連したものである。メッセージは、特定のプロトコルにマッピング可能な抽象的な方法で記述される。いくつかの機能を呼び出すメッセージ交換は操作と呼ばれる。特定の操作セットはインタフェースを定義する。インタフェースはネームバインディングにより、具体的なメッセージフォーマットとプロトコルに結びついている。バインディング（具体的なプロトコルに対するインタフェースのマッピング）は、プロトコルに適切なURIと関連し、エンドポイントとなる。１つ以上の関連するエンドポイントのまとまり（特定のURIで、具体的なプロトコルにインタフェースをマッピングする）は、サービスを構成する。
【００５７】
これらの定義は特定のWSDL要素に関連する：
タイプ  タイプ定義用のコンテナ要素
メッセージ  送信されるデータのタイプの抽象定義
オペレーション（operation）  インプット、アウトプット及びフォルトメッセージの組合せに基づく活動の抽象的な記述
【００５８】
ポートタイプ（portType）  抽象的なオペレーション・セット−インタフェース
バインディング  インタフェース（portType）用の具体的なプロトコルとデータ・フォーマットの仕様
ポート  バインディングと実際のネットワークアドレスの組合せ−１つのエンドポイント（an endpoint）
サービス  関連ポートの集まり（複数のエンドポイント（endpoints））
【００５９】
WSDLは一般的なバインディング機構を定義し、その後SOAP、HTTP  GET/POST及びMIMEの特定のバインディング拡張を定義する。そのため、バインディングは必ずしもトランスポート・プロトコルに直接バインディングすることを意味するのではなく、特定のワイヤフォーマットにバインディングすることを意味する。実際のSOAPメッセージの交換は一般的に、（http ://URIを介し）ポート80のHTTP上で起こるが、ウェブサービスで最も一般的なバインディングはSOAPである。しかし、インタフェースはHTTPに直接バインドされる；あるいは例えばSOAPのバインディングは（mailto://URIを介し）SMTPを使用できる。実装は、それ独自のワイヤフォーマットを定義し、カスタムバインディング拡張を使用することができる。
【００６０】
WSDLは、<import>要素をサポートしており、維持性と再利用性を促進する。WSDL文書は、importを使用し、ある組織に対し妥当な方法で、別々の要素に分割できる。インタフェース定義と実装定義とのある程度の分離が要求される結束性の高いウェブサービス環境では、以下の３つの文書に分けるのが妥当である：
【００６１】
スキーマ（.Xsd）文書−ルートノードは<schema>で、ネームスペースは「http://www.w3.org/2001/XMLSchema」。
【００６２】
再利用可能な部分とみなされているものを含む、サービスインタフェースの記述
<message>
<portType>
<binding>
【００６３】
特定のサービスエンドポイントを含む、サービス実装定義
<service>
【００６４】
WSDLインタフェースは、Java（登録商標）（又はIDLやその他のプログラミング言語）インタフェースと全く同じではない。例えばJava（登録商標）インタフェース宣言は、そのインタフェースを実装しようと要求するクラスのメソッドの少なくとも１つのサブセットに合うメソッドセットを宣言する。１つ以上のクラスがインタフェースを実装でき、各実装は異なる可能性がある；しかしメソッドのシグネチャ（メソッド名及び全ての入力又は出力タイプ）は一般的に同一でなければならない。これは言語により命令され、コンパイル時間やランタイム時、又はその双方で厳守される。
【００６５】
WSDLインタフェースは異なっており、単独では十分に役立たない実際には抽象型クラスに近い。１つのウェブサービスのさまざまなWSDLインタフェースやportTypeは、オペレーション名の一式が同一でなければならない、という意味では論理的に関連がある−それはまるでportTypeが実際、他で定義された特定の規約を実装するかのようである−だが実際にはそのような要素は存在せず、portTypeの均整を強化するための機構はない。各portTypeは一般的に、サポートするバインディングのタイプを識別するよう名前が付けられる−だがportType単独ではバインディングを作成しない。関連するportTypeのportTypeオペレーションは同じ名前が付けられるが、インプット、アウトプット及びフォルト・メッセージ（存在する場合）は、特定のバインディングをサポートするためにもやはり必要な名前の部分を含む、特定のメッセージにマッピングされる。これはメッセージ自体が十分抽象的でないという点を提起する。ウェブサービスは、必要となるさまざまなバインディングのため、類似しているが独自のメッセージを定義する必要がある場合があり、また頻繁にそうする必要がある。
【００６６】
下記に説明されるように新生のウェブサービスと関連スタンダードを利用し、システム・アーキテクチャは開発することができ、それは広範囲のハードウェア及びソフトウェアプラットフォームと操作環境で、さまざまな異なるプロトコルとインタフェースを利用するネットワーク化された相互運用メディア関連サービスの作成を容易にする。
【００６７】
１．２  役割
本発明の好ましい実施例では、ピアがサービスを公開することでさまざまな機能を自然に提供できるピア・ツー・ピア環境を実現し、推進し、及び/又は、積極的に対応することを求めている。フレームワークにおけるある実施例では、特定の一連の機能を持つものとしてピアをみることを推奨せず、代わりに、時間内のある時点におけるピアが１つ以上の役割に参加するというモデルを推奨している。
【００６８】
役割は、あるピアが特定の行動パターンと共に公開する一連のサービスによって定義される。ある時点にて、NEMOが有効になったノードは、次のようなさまざまな要素に基づいて複数の役割を果たすことができる。ある一連のサービスに対応する機能を提供する実際の実装フットプリント（footprint）、管理構成、ピアが公開できるサービスの宣言情報、及びサービスインタフェースにおける読み込み及び実行時ポリシーなどである。
【００６９】
明示的な一連の役割は、異なるサービスのタイプに基づいて定義することができる。今後、参加に関する一般的なパターンが決定され、新規サービスが導入されるにつれて、より形式化された役割分類ス鍵ムが定義できる。今後、公式化される可能性のある予備的な一連の役割には以下のものが含まれる。
【００７０】
クライアント−サービスを公開しない比較的単純な役割、このピアは単に他のピアのサービスを利用する。
【００７１】
オーソライザ（Authorizer）−この役割は、要求している主体が、ある一連の事前条件及び事後条件を持つ指定リソースへのアクセスを持つかどうかを判断するポリシー決定ポイント（PDP）として操作するピアであることを示す。
【００７２】
ゲートウェイ−以下の理由により、特定の状況において、ピアは他のサービスプロバイダを直接探したり、他のサービスプロバイダと相互関係を持ってはならない。トランスポート・プロトコルの非互換性、信頼コンテキストのネゴシエーション不可、又はあるサービスに関連する必要なメッセージの作成・処理に関する処理能力の不足。ゲートウェイとは、ピアがサービスプロバイダとのインタラクション（interaction）を可能にするために、別のピアへの橋渡しをするピアである。自己証明並びにオペレーション用の信頼コンテキスト（context）、信頼コンテキストの構築の観点からすれば、要求しているピアは自身の自己証明をゲートウェイピアへ実際に委譲し、代わりにネゴシエーション（negotiation）を行ったり、決定を行ったりすることを許可することもある。又は、ゲートウェイピアは単純なリレーポイントとして操作し、要求及び応答の転送や経路の決定を行うこともある。
【００７３】
オーケストレータ（orchestrator）−一連のサービスプロバイダとのインタラクションがサービスの重要な連携（場合により取引、分散状態管理等を含む）を必要とする状況において、オーケストレータは、参加するためのピアの能力を超えたものであってもよい。オーケストレータは、ゲートウェイの役割を特殊化したものである。ピアは、代わりとして１つ以上のサービスを提供するための仲介となるように、オーケストレータへ要求することができる。編成するピア（orchestrating peer）は、編成要件を満たすために適切に構成されたワークフロー照合部のような、特定の追加NEMOコンポーネントを使用してもよい。
【００７４】
「いかなるメディアへの、いかなるフォーマットにおける、いかなる提供元からの、いかなる場所にて、いかなる時間における、いかなる好ましい一連の使用ルールに従ったいかなるデバイス上での要求を満たすことで即座に要求を満足させる」という目的を前提として、以下の非公式なモデルは、NEMOフレームワークの実施例を使用し、この目的がどのように達成できるかを説明する。NEMOによりモデル内の異なるレイヤにある下位レベルのサービスを、より豊富なエンド・ツー・エンドのメディアサービスへ作り上げることを可能にする方法は、（NEMOが、想像可能な全てのメディアサービスを可能にする方法の全形態を列挙することなく）モデルの最高レベルから明白になる。
【００７５】
本モデルのある実施例においては、次の４つのレイヤのサービスコンポーネントがある。１）  コンテンツオーサリング（content authoring）、アセンブリ、及び、パッケージ化サービス、２）  ウェブベースのコンテンツ統合・流通サービス、３）  ホームゲートウェイサービス、及び４）  消費者向け電子機器。
【００７６】
これら４つのレイヤのそれぞれには一般的に、セキュリティ、著作権管理、サービス探索、サービス編成、ユーザインタフェースの複雑性、及びその他サービス属性に関する異なる要件がある。最初の２つのレイヤは「従来の」ウェブサービスに見られるモデルにおおよそ適合するが、最後の２つのレイヤは、２種類のモデル間の繋ぎ目にあるホームゲートウェイの特定サービスを持つパーソナル論理ネットワークモデルと呼ばれるものに、より適合する。しかし、ＣＥデバイス用のサービスはいずれのレイヤにも時々現れる。
【００７７】
あるエンド・ツー・エンドソリューションを網羅するのに十分なほど一般的であるものの、実装の効率のためにフレームワークのパーツを特殊化したい場合、１つのジレンマがある。例えば、UDDIディレクトリ及びディスカバリの取り組みは、比較的静的で中央化されたウェブサービスではうまく機能するかもしれないが、パーソナルネットワークの動的で一時的な融合に対して、UPnP及びRandezvousにあるような探索モデルの方がより適切な場合もある。したがって一部の実施例では、複数のディスカバリ・スタンダードがフレームワークに組み込まれている。
【００７８】
同様に、著作権管理がホールセール（wholesale）、アグリゲータ（aggregate）、及びリテール（retail）分散下層を通じてメディア分散に適用される場合、表明及び追跡が必要な多数の異なる種類の複合権利及び義務が存在することがある。そのため、高度に明示的でかつ複雑な権利の専門用語、洗練されたコンテンツ統治及び除去サービス、及びグローバルな信頼モデルに関する必要性があると思われる。しかし、ホームゲートウェイレイヤ及びＣＥデバイスレイヤに対する著作権管理及びコンテンツ統治は、消費者の視点から見て比較的単純である公平な使用権を強調する異なる信頼モデルを伴うことができる。パーソナル論理ネットワーク内のピア・デバイスは、グローバルな信頼モデルを使用するワイド・エリア・ネットワーク全体においてピアとインタラクションする能力と共に、おそらくプロキシゲートウェイサービスを通じて、そのネットワークの比較的単純な信頼モデルを使用するインタラクションを要求できる。消費者側では、デバイス全体におけるコンテンツ有用性の自動化された管理から複雑性が生じ、その一部はモバイルであるが、複数のネットワークを断続的に行き来する。したがって、エンド・ツー・エンド分散を可能にしたままでの著作権管理への効果的な取り組みは、売買取引又はサービス予約権が行使されるような別の事象と統合される取引において、頒布権の表現を翻訳し、（状況に合わせて）個々の消費者使用権に変換するサービスを含むさまざまな著作権管理サービスに対応する多元的なものの場合もある。
【００７９】
１．３  論理モデル
ある実施例では、システムフレームワークは、ピア・ツー・ピア（P2P）方式でインタラクションする論理的に接続された一連のノードから構成される。ピア・ツー・ピア・コンピューティングは、しばしば、コンピュータ及び他の知的デバイス間における（ハードドライブ及び処理サイクルなどの）リソースの共有として定義される。HTTP://www.intel.com/cure/peer.htmを参照のこと。ここでは、P2Pは、ネットワークノードが全種類のサービスを対称的に消費及び提供することを可能にする通信モデルとしてみられるかもしれない。P2Pのメッセージング及びワークフロー照合により、リッチサービスを異種の一連のより基本的なサービスから動的に作成することが可能となる。これにより、共有リソースが、多数の異なる種類のサービスである場合、そして異なるサービス・バインディングを使用するものでさえ、P2Pコンピューティングの可能性の検査が可能になる。
【００８０】
異なる実施例では、関係者（例：消費者、コンテンツ・プロバイダ、デバイス・メーカ、及びサービスプロバイダ）がお互いを見つけ出し、有意義で動的な方法で相互関係を持ち、価値を交換し、協力することを可能にするメディア・サービス・フレームワークを提供できる。これら異なる種類のサービスは、基本的なもの（探索、通知、検索、及びファイル共有）からより複雑で高レベルのサービス（ロッカー、ライセンス供与、マッチング、権限付与、支払取引、及び更新など）まで、及びそれら全て又は一部の組合せの範囲に及ぶ。
【００８１】
サービスはピア・ツー・ピアの通信ノード全体に渡って流通することができ、それぞれメッセージの経路決定、及びこのネットワーク用に設計されたメッセージ・ポンプとワークフロー照合部（以下に詳述）を使用した統合を提供する。
【００８２】
ノードは、サービス実施要求を作成し、応答を受けることでインタラクションする。要求及び応答メッセージのフォーマット及びペイロードは、サービス及び関連するインタフェース・バインディングの記述及び構成が可能で、拡張可能な一連のデータタイプを具体化した、標準XMLスキーマベースであるウェブサービス記述言語（例、WSDL）にて定義してあることが望ましい。WSDLにおいて多くのオブジェクトタイプは多様であり、新規機能に対応するように拡張できる。システムフレームワークは、単一のサービスプロバイダとのインタラクションから、複数のサービスプロバイダからの反応が一定な一連のサービスの複雑な集合まで、さまざまな通信パターンの構成に対応する。ある実施例において、フレームワークは既存のサービス振る舞いスタンダード（WSCI、BPEL等）の使用のための基本的な仕組みに対応しており、またサービスプロバイダが独自の仕様を取り入れることも可能である。
【００８３】
サービス呼び出しに関連するメッセージ構文は、システムフレームワーク内で使用されるコアデータタイプのように、比較的柔軟で可搬性のある方法で記述されることが望ましい。ある実施例において、これはWSDLを用いて達成されることができ、記述されたサービスに関連するセマンティック記述を参照する比較的簡単な方法を提供する。
【００８４】
サービスインタフェースには１つ以上のサービス・バインディングがあるかもしれない。このような実施例において、あるノードは、別のノードのインタフェース・バインディングが例えばWSDLで表現できる限り、かつ、要求ノードがバインディングに関連する仕様及びプロトコルに対応できる限り、そのノードのインタフェースを実施できる。例えば、ノードがウェブサービスインタフェースに対応する場合、要求ノードはSOAP、HTTP、WS-Security等の対応が必要であろう。
【００８５】
いかなるサービスインタフェースも、著作権管理の形態を直接提供する標準的な方法で制御される（例、管理された著作権）。ノード間のインタラクションは、統治されたオペレーションとして見ることもできる。
【００８６】
実質的にいかなる種類のデバイス（物理的又は仮想的）も潜在的にNEMOに対応されているとみることができ、NEMOフレームワークの主要な形態を実施することができる。デバイス種類には例えば、消費者向け電子機器、ネットワーク型サービス、及びソフトウェアクライアントを含む。望ましい実施例において、NEMOが有効になったデバイス（ノード）は一般的に、以下の論理モジュール（以下にて詳述）の一部又は全てを含む。
【００８７】
ネイティブサービスAPI−デバイスが実装する一連の１つ以上のサービス。NEMOノードがNEMOフレームワークにおいて直接的又は間接的にいかなるサービスをも公開する必要はない。
【００８８】
ネイティブサービスの実装−ネイティブサービスAPIに対応する一連の実装。
【００８９】
サービス適応レイヤ−エンティティのネイティブサービスのうち公開されているサブセットが、WSDLなどで記述された１つ以上の探索可能なバインディングを使用してアクセスされる際の論理レイヤ。
【００９０】
フレームワークサポートライブラリ−サービスインタフェース、メッセージ処理、サービス編成等の実施サポートを含む、NEMOフレームワークとの連携に必要なサポート機能を提供するコンポーネント。
【００９１】
１．４  用語
ある実施例において、基本的なWSDLプロファイルは、インタラクションのパターン及び下部的な機能を支援するための、最低限の「コア」となる一連のデータ型及びメッセージを定義する。ユーザは、直接的に、アドホック（adhoc）法で、又は標準化処理の形式を介し、このコアの上に構築され、新規データ及びサービス種類を追加し、既存のものを拡張する他のプロファイルを定義できる。ある実施例において、このコアプロファイルは、以下の主要基本データ型の一部又は全ての定義を含む。
【００９２】
ノード−システムフレームワークにおける関与を示す。ノードは、サービス消費部及び/又はサービスプロバイダを含む、複数の役割を果たすことができる。ノードは、消費者向け電子機器、メディアプレーヤなどのソフトウェアエージェント、コンテンツサーチエンジンなどの仮想サービスプロバイダ、DRMライセンスプロバイダ、コンテンツロッカーを含む、さまざまな形式で実装されることができる。
【００９３】
デバイス−仮想デバイス又は物理デバイスとして表現されるものをカプセル化するの。
【００９４】
ユーザ−クライアントユーザとして表現されるものをカプセル化する。
【００９５】
要求−一連の対象ノードに対するサービスの要求をカプセル化する。
【００９６】
要求入力−要求の入力をカプセル化する。
【００９７】
応答−要求に関連する応答をカプセル化する。
【００９８】
要求結果−要求に関連する個々の応答の中へ結果をカプセル化する。
【００９９】
サービスプロバイダ・ノードによって公開又は提供された一連の明確な機能の表現をカプセル化する。これには例えば、携帯電話（例、音声認識サービス）などのデバイス内で提供される低レベル機能、又はワールド・ワイド・ウェブ（例、買い物サービス）上で提供される多面的機能が含まれる。サービスは、クライアントのパーソナル化及びライセンス取得などDRM関連のサービスを含む、幅広いアプリケーションを網羅し得る。
【０１００】
サービスプロバイダ特定のサービスを公開するエンティティ（例、ノード又はデバイス）。サービスプロバイダとなり得るものには、携帯電話、PDF、携帯メディアプレーヤ、及びホームゲートウェイなどの消費者向け電子機器、及びネットワークオペレータ（ケーブル電波中継局など）、セルラー・ネットワーク・プロバイダ、ウェブベースの小売業者、コンテンツ・ライセンス・プロバイダ等が含まれる。
【０１０１】
サービスインタフェース１つ以上のサービスとインタラクションする明確に定義された方法。
【０１０２】
サービスバインディング−サービスインタフェースの実施に使用される仕様及びプロトコルを含むサービスと通信する具体的な方法をカプセル化する。これらは、WS-I標準XMLプロトコル、WSDL定義に基づくRPC、又はDLLからの機能実行など、さまざまな明確に定義された方法にて実現される。
【０１０３】
サービス・アクセス・ポイント（SAP）−ノードが、対象となる一連のサービス提供ノードに対するサービス実施要求を行い、一連の応答を受信することを可能にするために必要な機能をカプセル化したもの。
【０１０４】
ワークフロー照合部（WFC）−ノードがサービス実施に関する要求及び応答の収集を管理し処理することを可能にする共通インタフェースを提供するサービス編成の仕組み。このインタフェースは基本的なビルディングブロックを提供し、サービスに関連するメッセージの管理を通じてサービスを調整する。
【０１０５】
デジタル権利管理（DRM）などの特定のアプリケーションのもとでは、一般的なプロファイルは、システムにおけるエンティティを意味し、コンテンツを保護、使用ルールをコンテンツに関連付け、コンテンツの要求時にアクセスが許可できるかを判断する、以下のような一連のコンテンツ保護及び統治オブジェクトに対するさまざまなDRM関連のサービスを含むことがある。
【０１０６】
コンテンツ参照−コンテンツアイテムへの参照又はポインタの表現をカプセル化する。当該参照は、一般的にコンテンツ・フォーマット、位置等の標準化された方法を活用することになる。
【０１０７】
DRM参照−デジタル権利管理フォーマットの記述への参照又はポインタの表現をカプセル化する。
【０１０８】
リンク−エンティティ（例、ノード）間のリンク。
【０１０９】
コンテンツ−メディア又はその他コンテンツを表す。
【０１１０】
コンテンツ鍵−コンテンツの暗号化に使用される暗号化鍵を表す。
【０１１１】
コントロール（controll）−使用方法又はコンテンツとのインタラクションを統治するその他ルールを表す。
【０１１２】
コントローラ（controller）−コントロール及びコンテンツ鍵オブジェクト間の関連を表す。
【０１１３】
プロジェクタ−コンテンツ及びコンテンツ鍵オブジェクト間の関連を表す。
【０１１４】
ある実施例において、コアプロファイルは以下の基本サービスの一部又は全ての定義を含む。
【０１１５】
承認−一部の参加者にサービスへのアクセスを許可する要求又は応答。
【０１１６】
統治−ソフトウェアップグレードをダウンロード及びインストールする能力など、一部のアイテム（例、音楽ファイル、文書、又はサービス操作）へ権威的又は支配的影響を行使する処理。統治は一般的に、信用管理、ポリシー管理、及びコンテンツ保護などの機能を提供するサービスとのインタラクションを行う。
【０１１７】
メッセージ・ルーティング−サービス提供ノードにメッセージを転送、又はメッセージを収集及び組み立てる能力を含むメッセージ・ルーティング機能を提供する要求又は応答。
【０１１８】
ノード登録−ノードの登録操作を行うための要求又は応答。これにより、中間ノードを通じてノードによる探索が可能になる。
【０１１９】
ノード探索（クエリ）−ノードの探索に関連する要求又は応答。
【０１２０】
通知（notification）−ある一連のノードに対して対象の通知メッセージを送る又は届ける要求又は応答。
【０１２１】
セキュリティ信用証明交換（Security Credential Exchange）−ノードが、対の鍵（key pairs）、証明書（certificate）、又はそれらと同等のものなど、セキュリティ関連の情報を交換することを可能にする要求又は応答。
【０１２２】
サービス探索（クエリ）−一連の１つ以上のノードによって提供されるサービスの探索に関する要求又は応答。
【０１２３】
サービス編成サービスプロバイダにより指定されたルールに従った管理可能な、単位の大きいサービス、再利用可能なコンポーネント、完全なアプリケーション向けサービスの組み立て及び連携を行うこと。実例には、プロバイダの自己証明、サービスの種類、サービスへのアクセス方法、サービスを構成する順序等に基づいたルール等が挙げられる。
【０１２４】
信用管理（Trust Management）−ノード間のインタラクションのための許可・信用状況の作成に関する共通の一連の仕様及びプロトコルを提供する。一部の実施例において、NEMO信用管理は、ウェブサービス分野におけるWS-Security及びWS-Policyを含む既存のセキュリティ仕様及び機構を活用及び/又は拡張できる。
【０１２５】
アップグレード−機能アップグレードの受信に関する要求又は応答を表す。ある実施例において、このサービスは、具体的な表現を提供するその他プロファイルと共に純粋に抽象的である。
【０１２６】
１．５  ノード間の具体的なインタラクション
以下に詳細が論じられている通り、２つのシステムノード（サービス要求者及びサービス提供者）間の基本的な論理インタラクションは、一般的に以下の一連の事象を含む。これらはサービス要求ノードの観点から見たものとする。
【０１２７】
サービス要求ノードはサービス探索要求を作成して、指定のサービスバインディングを使用する必要なサービスを提供できる、NEMOが有効となるいかなるノードを探す。ノードは探索したサービスに関する情報のキャッシュを選択できる。ノード間のサービス探索用インタフェース/メカニズムは、NEMOノードが実装を選択する別のサービスであると言える。
【０１２８】
ノードを提供する候補サービスが見つかると、要求ノードは、指定のサービスバインディングに基づいてノードを提供する１つ以上のサービスへ要求を送信することを選択できる。
【０１２９】
ある実施例において、お互いにセキュアな通信を行うことを望む２つのノードはWSDLメッセージを交換する目的で信頼関係を構築する。例えば、それら２つのノードは、自己証明の判断、許可の確認、セキュアなチャネルの構築等に使用される、一連の互換性のある信頼証明（例、X.500証明書、デバイス鍵等）を交渉できる。時には、これら証明書の交渉は、サービスインタフェース・バインディング（例、WS-I XMLプロトコル使用時にはWS-Security、又は２つのよく知られたノード間におけるSSL要求）の暗黙的な性質のものであるかもしれない。その他の場合では、信頼証明書の交渉は、明示的な別の手順であるかもしれない。ある実施例において、どの証明書が別のノードとのインタラクションにとって十分であるかの判断、またあるノードを信頼できるかの判断は所定のノード次第である。
【０１３０】
要求ノードは、要求されたサービスに対応する適切なWSDL要求メッセージを作成する。
【０１３１】
メッセージが作成されると、対象のサービス提供ノードへ送信される。要求の通信スタイルは、例えば同期又は非同期のRPCスタイル、又はサービスバインディングに基づくメッセージ指向であるかもしれない。サービス要求の送信及び応答の受信は、デバイスによって直接行われても、NEMOサービスプロキシを通じて行われてもよい。サービスプロキシ（以下で説明）は、他の参加者へメッセージを送信するための抽象化及びインタフェースを提供し、互換性のあるメッセージフォーマット、運搬の仕組み、メッセージ・ルーティング問題等、特定のサービス・バインディング問題を隠蔽できる。
【０１３２】
要求を送信後、要求ノードは一般的に１つ以上の応答を受信する。サービスインタフェース・バインディングの仕様及び要求ノードのタイプに従って、応答は、RPCスタイルの応答又は通知メッセージを含むなど、さまざまな方法で返される。対象のノードへ送られる応答は、例えばルーティング、信用交渉、照合、及び相関機能等を含む多数の関連サービスを提供する他の中間ノードを経由することもある。
【０１３３】
要求ノードは応答を検証し、そのノードとサービス提供ノード間で交渉した信頼操作に固守していることを確認する。
【０１３４】
そしてメッセージペイロードの種類及び内容に基づいて適切な処理が適用される。
【０１３５】
サービス提供ノードの観点から、一連の事象は一般的に以下のものを含む。
要求されたサービスに対応しているかどうかを判断する。ある実施例において、NEMOフレームワークはスタイル、又はサービスインタフェースがサービスへのエントリー・ポイントとしてマップする方法の精度を指定しない。最も簡単な場合では、サービスインタフェースは所定のサービス及びバインディングの操作に対して詳細にマップでき、実施によりサービスの対応を構成できる。しかし、一部の実施例では、単一のサービスインタフェースが複数の種類の要求を取り扱うこともあり、あるサービスの種類が、ノードが明確に所望の機能に対応するという決定を行う前に検討が必要な追加の属性を含むかもしれない。
【０１３６】
ある場合では、サービスプロバイダが、要求ノードを信頼しているかを判断し、一連の互換性のある信頼証明書を取り決めることが必要かもしれない。ある実施例において、サービスプロバイダが信頼性を判断するかどうかに関係なく、サービスインタフェースに関連するポリシーが依然として適用される。
【０１３７】
サービスプロバイダは、要求ノードがアクセス権を持つかを判断するために、インタフェースへのアクセスを許可する責任を持つそれらノードに対して決定を下し、許可要求を送信する。多くの場合、許可ノード及びサービス提供ノードは同一のエンティティであり、許可要求の送信及び処理は、Ｃ言語関数のエントリー・ポイントといった処理が軽いサービスインタフェース・バインディングを通じて実行される局部的な処理である。
【０１３８】
許可応答の受信時に、要求ノードが許可された場合、サービスプロバイダは要求に応じる。許可されない場合、適切な応答メッセージが生成される。
【０１３９】
応答メッセージは、サービスインタフェース・バインディング及び要求ノードのプリファレンス（preference）に基づいて返信される。要求ノードへのルーティング時に、メッセージは、必要なサービス又は「付加価値のある」サービスを提供する他の中間ノードを経由できる。例えば、中間ノードはルーティング、信用交渉、又は要求ノードに受け入れ可能な方法でメッセージを配送できる通知処理ノードへの配送を提供する場合がある。「付加価値のある」サービスの例としては、要求ノードの興味に応じてメッセージにクーポンを付け加えるクーポンサービスがある。
【０１４０】
２．  システム構造
DRMアプリケーションを実装している図１に図示される、NEMOシステムフレームワークのサンプル実施例について考察する。
【０１４１】
上記で言及した通り、NEMOノードは、サービス実施要求を作成し応答を受信することによりインタラクションを行うことができる。NEMOフレームワークは、単一のサービスプロバイダでの単純なポイント・ツー・ポイントのインタラクションから、複数のサービスプロバイダにより規定された一連のサービスの複雑な集合まで、多様で内容の込み入った通信パターンの構造に対応する。
【０１４２】
図１の状況において、NEMOノードはお互いにインタラクションし、全体として音楽ライセンスシステムを実装するさまざまなサービスを提供する。消費者音楽ロッカー110に格納された音楽は、ウェブ音楽小売業者120によって引き出され、エンタテーメントホームゲートウェイ130を通じて各家庭のエンドユーザに提供できる。消費者音楽ロッカー110の音楽は、その音楽がウェブ音楽小売業者120に提供され、その後さらなる使用及び分散のために他人へ渡される状況を統治するルールを含むこともある。エンタテーメントホームゲートウェイ130は、例えば、ユーザの家庭用PC（例、PCソフトウェアビデオプレーヤ140を通じて）又はユーザの携帯型再生デバイス（例、携帯音楽プレーヤ150）など、当該音楽（ビデオ及びその他コンテンツ）を再生できる箱である。ユーザは、例えば携帯音楽プレーヤ150を持って旅行に出かけ、ワイヤレスインターネット接続を通じて（例、デジタル権利ライセンスサービス160へアクセスし）ライセンスを入手して追加の楽曲を購入又は既存の楽曲をさらに再生したり、ソフトウェアップグレードサービス170を通じて携帯音楽プレーヤ150に新規機能を追加したりさえするかもしれない。
【０１４３】
NEMOノードはさまざまな異なった方法でお互いにインタラクション又は他のデバイスとインタラクションできる。図２Ａに図示されているようなNEMOホストは、少なくとも１つのNEMOノードを持つ何かしらの機械又はデバイスである。ホストはパーソナルエリアネットワーク210内に、又はインターネットを通じてアクセス可能な遠隔地220に常駐することができる。ホストは、例えばサーバ230、デスクトップPC 240、ラップトップ250、又はPDA260であり得る。
【０１４４】
NEMOノードはソフトウェアエージェントで、（サードパーティ製のウェブサービスを提供するホスト235など）他のノードへサービスを提供できるばかりでなく、NEMO管理フレームワーク内にある他のノードのサービスを実施できる。一部のノード270は、Bluetooth（登録商標）など専用通信チャネルを通じて別のホストへ拘束される。これらホスト240及び250はネットワーク接続が可能なであり、他の参加NEMOノードに対して仮想ノードを示す十分な処理能力を持つ。
【０１４５】
図２Ｂに図示の通り、NEMOノードはローカルエリアネットワーク又はパーソナルエリアネットワーク210内で完全なピアとなることができる。ノードはサービスの公開及び実施という対称的な能力を共有する。しかし、各ノードは通常、同一セットのサービスを提供しない。ノードは実行するサービスを告知、及び/又は、それらのノードが実行するサービスについての具体的に問い合わせを受ける。
【０１４６】
図２Ｃに示す通りインターネット接続がある場合、ローカルのNEMOノード（例、パーソナルエリアネットワーク210内）は遠隔ノード220のサービスにアクセスもできる。ローカルネットワークの構成及びポリシー次第で、ローカル及び遠隔ノード（例、インターネット可能なNEMOホスト280）がNEMOピアとして相互運用することも可能である。
【０１４７】
図２Ｄに図示の通り、遠隔でもNEMOノードの全てが他のホストと通信可能なホスト上になくてはならないということはない。NEMOホスト280は、拘束ノード285又はパーソナルエリアネットワーク210内のノードなど、あるノードが別のサービスを実施できるようなゲートウェイサービスを提供できる。
【０１４８】
図２Ｅに図示の通り、拘束デバイス上のノード295は、上述の通りゲートウェイを通じて他のノードのサービスにアクセスできる。また、別のホスト290上のプロキシサービスを通じて他のノードによりアクセスできる。プロキシサービスはNEMOホスト上で実行する仮想ノードを作成するものである。これらプロキシノードは完全なNEMOピアとなることができる。
【０１４９】
図２Ｆに図示の通り、NEMOホストはNEMOノードアダプタを通じて拘束デバイスのための専用サポートを提供できる。専用通信チャネル296は、適切なプロトコルを使用するホスト/NEMOデバイスアダプタ297及び拘束ノード298の間で使用される。拘束ノード298は、他のNEMOピアノードを見ることはなく、他のNEMOピアノードからの可視性もない。
【０１５０】
次に、特定の実施例においてNEMOが有効になっているデバイスにより提供が可能な、又はNEMO状況外で使用可能な、模範的なデジタル権利管理（DRM）機能について考察する。以前述べた通り、NEMOシステムフレームワークの望ましい実施例の主要目的の１つは、商用ネットワークレイヤ及び消費者指向ネットワークレイヤの双方が、メディア関連サービス間で、セキュアで相互運用可能な相互接続の開発をサポートすることである。サービス接続に加え、メディア関連サービス間の相互運用は、それらサービスを通じて利用可能なコンテンツに適用されるように、しばしば使用権の組織的な管理を必要とする。ここで述べられているNEMOサービス及び模範的なDRMエンジンは、NEMOフレームワークに基づくデバイスが、異種DRM及びメディアフォーマット基盤のタイプにもかかわらず、消費者にシームレスな性能及び使用経験を提供することを可能にする相互運用を達成するために組合せて使用することができる。
【０１５１】
DRMアプリケーションの状況において、図３に図示の通り、NEMOが有効になったデバイスのネットワークは、他のDRMデバイス、及び保護コンテンツを再生できるだけでなく、携帯デバイス340向けに配信できるコンテンツを保存することもできる消費者PCプレーヤ330及び消費者PCパッケージャ/プレーヤ320向けのコンテンツを保存できるコンテンツプロバイダ/サーバ310を含む。
【０１５２】
各DRMデバイス内で、DRMエンジンは、特定のDRM機能（例、ライセンス条件の施行、ホストアプリケーションへの鍵の引渡し等）を実行し、暗号化、復号化、及びファイル管理などホストによって最も効果的に提供されるこれらサービス用のホストアプリケーションを頼る。
【０１５３】
以下で詳述される通り、ある実施例においては、DRMエンジンは、保護コンテンツ上で特定の挙動が許可されるかどうかを判断するために設計されたバーチャルマシン（VM）を含む。この制御VMは、最低限の指示セットを持つ単純なスタックベースのマシンとして実装できる。ある実施例では、論理的及び算術的な計算、及びホスト環境に状態情報を問合せ、システム時間、カウンタ状況等のパラメータをチェックすることができる。
【０１５４】
ある実施例では、DRMエンジンは、エンティティ及びDRMの価値連鎖間の関係を検証するために、グラフベースのアルゴリズムを活用する。図４は、そのグラフの概念的な実施例を図示する。グラフはリンクによって接続されたノード又は頂点の集合から構成される。システム内の各エンティティは頂点オブジェクト（vertex obeject）により表される。リンクオブジェクトにより参照の必要がある、又は、暗号化の対象情報の受信機となる必要があるエンティティのみ、対応する頂点オブジェクトを持つ必要がある。ある実施例では、頂点は一般的にユーザ、デバイス、グループを表す。頂点オブジェクトは、頂点に関連するエンティティの特定の特性を表す関連属性も持つ。
【０１５５】
例えば、図４は、２人のユーザ（シャン及びノックス）、２つのデバイス（Mac及び携帯デバイス）、及びグループを表すいくつかのエンティティ（ケーリー一家のメンバー、公共図書館のメンバー、特定の音楽サービスの加入者、RIAA承認デバイス、及び特有の会社で製造されたデバイス）を示す。これらのそれぞれが関連する頂点オブジェクトを持つ。
【０１５６】
リンクの意味は、各アプリケーションに固有の方法において変化しうる。例えば、Macの頂点からノックスの頂点までの方向を持つ辺（directed edge）は、ノックスがMacの所有者であることを意味する。ノックスから公共図書館への辺はノックスが公共図書館のメンバーであることを指す。ある実施例では、DRMエンジンはこれらの意味を強要したり翻訳したりせず、単にグラフにあるパスの存在又は非存在を確認する。この頂点グラフは、２つの頂点間のパス又は関係（直接的又は間接的）の存在が片方の頂点から別の頂点へのアクセス許可として解釈されるという点から、「承認（authorization）」グラフとして考慮できる。
【０１５７】
例えば、ノックスはケーリー一家へリンクされ、ケーリー一家は音楽サービスへリンクされているため、ノックス及び音楽サービス間のパスが存在する。音楽サービス頂点は、ある頂点から音楽サービスへのパスがある場合にその頂点から到達可能と考慮される。これは、アクセスを要求するアプリケーション（例、DRMクライアント・ホスト・アプリケーション）が実行する携帯デバイスから音楽サービスへ到達可能であるという条件に基づき、保護コンテンツにアクセスする許可が、コントロールに書き込むことを認める。
【０１５８】
例えば、コンテンツ所有者は、消費デバイスが公共図書館のメンバーによって所有され、RIAAの承認を受けている場合に特定の音楽を再生できる制御VMによって翻訳（interpret）される制御プログラムを作成できる。デバイス上で操作している制御VMがこの制御プログラムを評価するとき、DRMエンジンは、携帯デバイス及び公共図書館の間、並びに携帯デバイス及び承認RIAAの間にリンクが存在するかを判断する。グラフの辺及び頂点は静的であり、かつ、デバイス内に構築され、又は、動的で、そして、ホストアプリケーションと通信するサービスを通じて発見される。
【０１５９】
頂点及びリンク上に意味（semantics）を課さないことで、DRMエンジンには大きな柔軟性が可能となる。システムは、従来の委譲ベースのポリシーシステムから、承認ドメイン及びパーソナルエリアネットワークへの多数の使用モデルに適用できる。
【０１６０】
ある実施例では、DRMクライアントは承認グラフをコンテンツ保護鍵導出用に再利用もできる。システム設計者は、リンクの存在が特定の暗号情報の共有を意味するように選択することもできる。そのような場合、承認グラフは、明示的に消費デバイスを再度暗号化の対象とすることなく、コンテンツ鍵の導出に使用できる。
【０１６１】
３  ノード構造
３．１  概要
消費者向け電子機器、ネットワーク型サービス、又はソフトウェアクライアントを含むあらゆる種類のデバイス（物理的又は仮想的）は潜在的にNEMOが有効であり、デバイスの機能はNEMOシステムに参加できるように拡張できることを意味する。ある実施例では、NEMOが有効なデバイス（ノード）は、図５Ａに図示の通り、特定の標準モジュールから概念的に構成される。
【０１６２】
ネイティブサービスAPI510は、デバイスが実装する１つ以上のサービスの論理的なセットを表す。NEMOノードは、直接的又は間接的に、いかなるサービスをも公開する要求はない。ネイティブサービス実装520は、ネイティブサービスAPIに対応する一連の実装を表す。
【０１６３】
サービス・アクセス・ポイント530は、公開されたサービスインタフェース実施への呼び出しを提供する。それは、NEMOノードがサービス実施要求を対象となる一連のサービス提供NEMOノードに対して行い、一連の応答を受信することを可能にするために必要な機能をカプセル化する。NEMOが有効になっているノードは、柔軟で拡張可能な通信APIの作成を伴う多様な探索、名前解決、及びトランスポート・プロトコルを使用することもある。サービス・アクセス・ポイントは、特定の実行環境及びアプリケーションフレームワークスタイルに合わせ、さまざまな方法で実現できる。インタフェース用のある共通の一般的モデルの１つは、一部の形式によるXMLメッセージを受信でき、XMLメッセージを返信するインタフェースである。より多くのネイティブ・インタフェースを持つ他のモデルもサポート可能である。
【０１６４】
NEMOサービス適応レイヤ540は、任意のレイヤを表し、そのレイヤを通して、ネイティブサービスのエンティティの公開サブセットは、１つ以上の発見可能（discoverable）なバインディングを用いてアクセスされる。そのレイヤは、ネイティブサービスAPIの上に抽象レベルを提供し、サービスプロバイダが複数の種類のサービスインタフェース・バインディングにより簡単にサポートできるようにする。サービス適応レイヤが存在しない状況では、必要な通信プロトコルにサポートしていれば、サービス・アクセス・ポイント530を通じて直接サービスにインタラクションすることは、やはり可能である。
【０１６５】
サービス適応レイヤ540は、サービスプロバイダがNEMOフレームワーク内でサービスを公開し、要求及び応答を処理し、サービスを調整する共通の方法を提供する。そのレイヤは、サービスを公開する論理ポイントであり、他の特定のサービスインタフェース・バインディングを実装する基礎を提供する。
【０１６６】
サービス適応レイヤ540はサービスプロバイダのネイティブサービスを他のNEMOが有効なノードに公開する一般的方法を提供することに加え、図５Ｂに図示の通り、追加のサービスインタフェース・バインディング560に対応するためにコンポーネントをレイヤ状にする平常の場所も提供する。追加のサービスインタフェース・バインディングに対応することで、サービスプロバイダは、互換性のあるバインディングをネゴシエートでき、サービス・アクセス・ポイントによって又はその他ネイティブAPIを通じて使用できる可能性が増加する。
【０１６７】
図５Ａに戻るが、ワークフロー照合部550は、サービスメッセージ及びサービス編成のサポート管理を提供する。それは、ノードが要求及び応答メッセージの集合を管理及び処理できるようにする共通のインタフェースを提供する。このインタフェースは、基本的なビルディングブロックを提供し、それらサービスに関連するメッセージの管理を通じてサービスを編成する。このインタフェースは一般的に、メッセージ・ルーティング機能及びメッセージの中間待ち状態及び照合に対応するノードによって実装される。
【０１６８】
一部の実施例では、NEMOフレームワークは、ネットワークへのエンティティの参加を容易にする任意のサポートサービスのコレクションを含む。当該サービスは、さまざまな種類の機能、及び当該サービスを必要とする実態の種類（例えば、サービスプロバイダが必要とするものに反した、クライアント・アプリケーションに対応するサービス）にしたがって分類することができる。一般的に対応するサービスには以下のものが含まれる。
【０１６９】
WSDLフォーマット化及び操作ルーチン−WSDLベースのサービスメッセージの作成及び操作用の機能を提供する。
【０１７０】
サービスキャッシュ−ノードが、発見可能なノード、及び、それらがサポートするサービス間のマッピングのコレクションを管理できるようにする共通のインタフェースを提供する。
【０１７１】
通知プロセッサ・インタフェース−一部の明確に定義された通知処理エンジンへの通知処理に対応するNEMOノードを拡張するための共通サービスプロバイダ・インタフェースを提供する。
【０１７２】
その他サポート機能−メッセージID、タイムスタンプ等を生成するルーチンを含む。
【０１７３】
３．２  基本ノードインタラクション
NEMOノードの個々の構造的要素をさらに詳細に検討する前に、そのノードが他のノードとインタラクションして通信を行う方法を理解しておくことは有意義である。これらノードは、同期及び非同期のRPCスタイル通信から、一方通行のインタフェース呼び出し、及び、クライアントのコールバックまでさまざまな通信スタイルをサポートする。
【０１７４】
非同期RPC配送スタイル−このモデルは、要求を満たすことに時間がかかり、クライアントが待つことを望まないと予想される場合に特に適切である。クライアントは、要求がサービス提供ノードによって非同期の方法で処理されるという期待と共に要求を出す。この場合、サービス提供エンドポイントは、このモデルに対応しないという応答をすることができる、又は、サービス提供ノードがこのモデルに対応しない場合、クライアントの要求に対する応答があるかどうか判断する要求に続き、所定のサービス提供ノードに送ることができるチケットを含む応答を返す。
【０１７５】
ある実施例では、このモデルに対応しないいかなるサービス提供エンドポイントも、内部ポリシーに基づいてクライアント要求を保留するために、応答のキャッシュが義務付けられる。クライアントが当該要求に関連したチケットの償還を試み、応答が全く無い場合、又はサービス提供ノードによって応答が破棄された場合、適切なエラー応答が返される。この実施例において、応答のためのチケットを償還する試みの中で、いつそのような後続の要求を行うかの判断はクライアントに依存する。
【０１７６】
同期RPC配送スタイル−クライアントは要求を送り出し、返される１つ以上の応答を待つ。NEMOが有効なサービスを提供する側のエンドポイントは、このモデルに対応しないという応答を返すことができる。
【０１７７】
メッセージベース配送スタイル−クライアントは、サービスインタフェースを取り扱う１つ以上の通知に関連するメッセージ通知を通じて応答を受信したいという要求を送り出す。NEMOが有効な、サービスを提供する側のエンドポイントは、このモデルに対応しないという応答を返すことができる。
【０１７８】
クライアントアプリケーションの視点から、上記インタラクションパターンのいずれも、応答をブロックして待たなければいけない又は明示的にポーリングを行わなければいけないという構造を必要としない。スレッド又は他のプラットフォーム固有の仕組みを使用して、上記配送スタイルの仕組みと共にブロッキング及び非ブロッキング構造の双方をモデル化することが可能である。また、上記スタイルのいずれも、ある通信チャネルの遅延に関連する問題に直接取り組むことを目的としていない。要求に対する実際の達成に関連する潜在的な遅延のみである。通信チャネルの遅延に関連する問題を扱う仕組みは、サービス・アクセス・ポイントなどコンポーネントの特定の実装にて、又は直接クライアントの実装内にて取り組むべきである。
【０１７９】
３．３．サービス・アクセス・ポイント
上記の通り、サービス・アクセス・ポイント（SAP）は、サービス実装の目的で、再使用可能な共通APIとして使用できる。トランスポートチャネルの交渉や使用をカプセル化できる。例えば、トランスポートチャネルによっては、TCP/IP上にSSLセッションの設定が必要であるが、チャンネルによっては、比較的信頼性の低い通信だけをUDP/IP上でサポートしているか、また、まだIPベースでは全くないものもある。
【０１８０】
SAPはメッセージ経路の決定の初期のNEMOノードセットのディスカバリをカプセル化できる。例えば、ケーブルセットトップボックスは、ネットワークへの専用接続があり、全てのメッセージが、特定のルートと中継を通過するように命令することができる。ホームネットワークの携帯用メディアプレーヤは、直接アクセス可能な複数のノードを見つけるUPnPディスカバリを使用することができる。クライアントは、XMLメッセージを交換することにより、その他のNEMOノードと直接会話することそのものができない、あるいは、会話することを選択できない場合がある。この場合、SAPのバージョンを使用することができ、ネイティブ・インタフェースがサポートされているものを公開して使用する。
【０１８１】
好ましい実施例においては、SAPパターンは次の２つの共通通信モデルをサポートする（この２つの組合せに加えてその他の組合せもサポートされる場合がある）。（i）メッセージベース（上記で検討したとおり）−SAPがXML要求メッセージを形成し、いくつかのインタフェース・バインディングによりNEMOメッセージをサービスプロバイダと直接交換する場所、又は（ii）ネイティブ−SAPが、いくつかのネイティブ通信プロトコルによりサービスプロバイダとインタラクションを行うことができる場所。SAPはフレームワーク内にどこでも定義されたXMLメッセージとの翻訳を内部で行うことができる。
【０１８２】
２つのNEMOピアノード間でのインタラクションの例が図６Ａに示される。クライアントノード610は、NEMOサービス・アクセス・ポイント（SAP）620を使用して、サービス提供ノード660とインタラクションしている。この例では、ウェブサービスプロトコルや標準仕様は、サービスの公開とトランスポート双方に使用される。サービス提供ノード660は、ノード610のようなクライアントにそのサービスを公開するために、そのウェブサービスレイヤ670を使用する（例えば、WSDLやSOAPベースのメッセージングを使用する）。クライアントノード610のウェブサービスレイヤ630は、マッピングレイヤ640（SOAPメッセージとSAPインタフェース620との間をマッピングする）やトラスト管理処理レイヤ650（例えば、SOAPヘッダ内で運ばれた信用証明を使用して、WSセキュリティを利用することができる）からの助けにより、SOAPメッセージを作成し、かつ、翻訳する。
【０１８３】
NEMOノード間のインタラクションの別の例は、図６Ｂに示される。サービス提供ノード682は、SAP686を使用して、クライアントノード684とインタラクションする。この例では、サービス提供ノード682は、クライアント684ではなく、相互運用可能なトラスト管理レイヤを含む。特に、サービス提供ノード682はトラストエンジン688と認証エンジン690の双方を含む。この例では、トラストエンジン688は、一般的に、デジタル証明書及びその他の基本的な暗号操作のために、SOAPメッセージの暗号化と解読の実施に責任を持つ場合もあるが、承認エンジン690は、より高度なポリシー決定に責任を持つ場合もある。図６Ｂに示された例では、クライアントノード684は、トラストエンジン692を含むが、認証エンジンは含まない。このように、この例では、クライアントノード684は、基本的な暗号化と解読、及び、比較的簡単なポリシー（例えば、メッセージ承認、機密性などに関するポリシー）を実施する機能を持つ場合があるが、サービス及び/あるいはサービス提供ノード682により提供されるコンテンツに対するクライアントの使用や、インタラクションを支配する高度なポリシーの評価や実行にはサービス提供ノード682に依存する場合がある。図６Ｂは、図解の目的で提供されているが、これに限定されず、その他の実施例では、クライアントノード684が、クライアントが特定のポリシーに関連する一連の義務を厳守することを必要とした場合など、承認エンジンも含む場合があることを理解されたい。このように、それぞれの要件に応じて、別のNEMOピアにはトラスト管理フレームワークの別部分を含むことが理解できる。図６Ｂは、ノード間の通信リンクがトランスポートにとらわれないことが可能であることも示す。SOAP処理モデルの状況においても、任意の最適なデータコード化及び/あるいはルール処理が使用できる。例えば、XMLセキュリティモデルは、異なるコード化方法でサポートされた別のセキュリティモデルで置換できる。
【０１８４】
サービス・アクセス・ポイントは、クライアント境界内（共有ライブラリの形）、あるいは、クライアントの境界外（異なるプロセスを実行しているエージェントの形）など、さまざまな形で実装できる。サービス・アクセス・ポイント実装の正確な形は、特定の種類のプラットフォームあるいはクライアントの必要性に応じて、カスタマイズすることができる。クライアントの立場からは、以下に示すように一般的にはサービス・アクセス・ポイントの使用は重要なユーティリティを提供するが、サービス・アクセス・ポイントの使用はオプションにできる。
【０１８５】
サービス・アクセス・ポイントは、決まった一連のサービス・プロトコル・バインディングだけをサポートする静的コンポーネントとして実装できるが、新しいバインディングを動的にサポートすることもできる。
【０１８６】
サービス・アクセス・ポイントが関与するインタラクションは、少なくとも２つの立場、つまり、参加者の使用を要求するクライアント側と他のNEMOが有効なエンドポイント（ノード）とインタラクションするサービス側から特徴づけられる。
【０１８７】
クライアント側の一例は、図７Ａに示されるが、サービス・アクセス・ポイント710は、クライアント720と直接XMLメッセージを交換する。クライアント720は、直接要求メッセージ740を形成し、それらをサービス・アクセス・ポイント710に提出する。サービス・アクセス・ポイント710は、１つ以上の返信メッセージ750をクライアント720に作成して送信し、それらは収集、分析、処理される。クライアント720は、要求の配信を目的として使用するために（要求時には）サービス・バインディング730の明示的セットも提出する場合がある。これらのサービス・バインディングは、さまざまな方法で取得されている場合がある。例えば、クライアント720は、サービス・ディスカバリ操作を実施して、どのサービス・バインディングが適用可能であるかを選択することができる。あるいは、以前の応答から取得された情報を使用できる。
【０１８８】
別のクライアント側の実施例は、図７Ｂに示されるが、サービス・アクセス・ポイント760は、クライアント780のネイティブ・プロトコル770を直接サポートする。サービス・アクセス・ポイント760は、XMLとそのネイティブ・プロトコル770の間で内部的にメッセージを翻訳するので、クライアント780のNEMOシステム内の関与を可能にする。このようなサポートを有効にするために、ネイティブ・プロトコル770（あるいはネイティブ770と実行環境の組合せ）は、適当な要求を生成し、必要であれば、適切なターゲットサービス・バインディングを決定するサービス・アクセス・ポイント760になんらかの形で任意の必要な情報を提供しなければならない。
【０１８９】
サービス側では、クライアントのサービス・アクセス・ポイントとNEMOが有効なサービスを提供するエンドポイントの間での複数のパターンのインタラクションをサポートすることが可能である。クライアント側のように、インタラクションパターンはカスタマイズすることが可能で、要求の性質、基本の通信ネットワーク、ターゲットのサービス・バインディングに関連するアプリケーション及び/あるいはトランスポート・プロトコルの性質など、さまざまな条件を基本にして、変行することができる。
【０１９０】
比較的簡単な種類のサービス側のインタラクションパターンが図７Ｃに示されているが、ここでは、サービス・アクセス・ポイント711は、ポイント・ツー・ポイント方式で、目的のサービス提供ノード712と直接通信する。
【０１９１】
図７Ｄを見ると、サービス・アクセス・ポイント721は、複数の潜在的サービスプロバイダ725と直接通信を開始することができる（そして、直接応答を受け取ることができる）。この種類のインタラクションパターンは、サービス・アクセス・ポイント721による使用を目的として、クライアントからの複数のサービス・バインディングを中継することにより実装できる。あるいは、ブロードキャストあるいはマルチキャストネットワークがメッセージを中継するためにサービス・アクセス・ポイント721により利用することができる。要求に指定された優先事項を基に、サービス・アクセス・ポイント721は、送信を収集し照合するあるいは、単に最初に許可可能な応答を返すことができる。
【０１９２】
図７Ｅでは、サービス・アクセス・ポイント731は、どの目的のサービス提供エンドポイント735とも直接的に通信しない。代わりに、要求は、その要求を中継し、応答を受信し、それらをサービス・アクセス・ポイント731に中継して戻す仲介ノード733を通じて経路が決定される。
【０１９３】
このようなインタラクションのパターンは、サービス・アクセス・ポイント731がサービス提供エンドポイント735に関連するサービス・バインディングを全く直接サポートできない、あるいはサポートしないが、ゲートウェイとして機能することを期待している中間ノード733との関係を確立できる場合には好ましい。あるいは、クライアントは、適切なサービス提供ノードを発見できない、あるいは発見できれば適切なサービス提供ノードに対するサービス・バインディングを決定するが、中間ノード733が任意の適切なサービスプロバイダを自ら発見する試みを許可したいと期待しているかもしれない。更には、サービス・アクセス・ポイント731は、中間ノードがより強固な収集や照合機能をサポートし、結果として、サービス・アクセス・ポイント731とエンドポイント735のようなサービスプロバイダとの間に柔軟性の高い通信パターンを許可するため、中間ノード733の利点を好む場合もある。
【０１９４】
上記のサービス側の基本的なインタラクションパターンに加えて、このようなパターンや新しいパターンの組合せはサービス・アクセス・ポイント内に実装できる。サービス・アクセス・ポイントは、共通インタフェースを提供することを目的としているが、一般的に、その実装はNEMOが有効になったエンドポイントにより採用された通信モデルや関連プロトコルの特徴に強く関わる。
【０１９５】
実際には、サービス・アクセス・ポイントは、XML表示（WSDLの表示形式による）、あるいは、オブジェクトを適切な表示にシリアル化する等や、適切な形式のXMLでコード化されたオブジェクトをエンベロープ化（envaloping）した表示等のような、I/O関連データのマーシャリング（marshalling）や非マーシャリングの処理論理をカプセル化するために使用できる。
【０１９６】
好ましい実施例では、SAPは１つ以上のサポートされたアプリケーション、セッション、及び/あるいは、SOAPのエンベロープ化を使用したHTTP上でのサービス実施といったトランスポート・プロトコル経由の通信論理もカプセル化する。
【０１９７】
最後に、いくつかの実施例では、SAPは、SSL/TLSセッションの確立、及び/又は、XML署名やXML暗号化のような標準仕様によるデータの署名/検証のサポートのような、メッセージ調整や機密の論理をカプセル化することもできる。サービスインタフェースの特定のアドレスが未知、あるいは未指定（例えば、いくつかの検索条件に基づき複数のノードでサービスを起動する場合）である場合、SAPはサービスが発見あるいは解決される場所にあるデフォルト/初期セットのNEMOノードを確立する論理をカプセル化することができる。
【０１９８】
以下は、SAP実施の一例としてエクスポートされた高レベルでの無制限タイプAPI記述の実施例である。
【０１９９】
ServiceAccessPoint::Create(Environment [] ） → ServiceAccessPoint−これは、SAPの初期化されたインスタンスを返す１つのインタフェースである。SAPはオプションでの環境パラメータセットにより初期化できる。
【０２００】
ServiceAccessPoint : : InvokeService （ServiceRequestMessage, Boolean） → Service Response Message−同期サービス実施APIは、クライアント（WSDLを使用）がXMLサービス要求メッセージを形成し、応答でXMLメッセージを受信する場合にサポートされる。APIは、クライアントが応答を待つべきかどうかを示すブーリアン型のフラッグも受け取る。通常、このフラッグの値は、関連応答のないメッセージあるいは別のチャネル（通知経由のような）経由で非同期の応答がされるメッセージを除き、真である。結果のメッセージもいくつかの結果エラー条件を実施できる。
【０２０１】
ServiceAccessPoint::ApplyIntegrityProtection（Boolean, Desc[] ） → Boolean−このAPIでは、呼び出し者が、整合性保護を適用できるかどうか、メッセージのどの要素に適用すべきかを指定できる。
【０２０２】
ServiceAccessPoint::ApplyConfidentiality（Boolean, Desc[] ） → Boolean−このAPIでは、呼び出し者が、機密が適用されるかどうか、メッセージのどのオブジェクトに適用すべきかを指定できる。
【０２０３】
ServiceAccessPoint::SetKeyCallbacks（SigningKeyCallback,
SignatureVerificationKeyCallbac k,
EncryptionKeyCallback, DecryptionKeyCallback）→
Boolean
上記APIで示されたように、メッセージが送受信される場合、整合性保護あるいは機密を必要とするオブジェクトを含む場合がある。このAPIでは、クライアントがクライアントとSAPの間に任意に必要なフックを設定できるので、SAPは特定の種類の信用管理操作に関連する鍵を取得できる。実施例の一つでは、インタフェースはデジタル署名や承認、暗号化と解読による機密性による整合性保護をサポートするコールバックを基本とする。実施例の一つでは、それぞれのコールバックは次の形式である。
【０２０４】
KeyCallback（KeyDesc） → Key []
ここで、KeyDescは必要な鍵を記述するオプションのオブジェクトであり、適切な鍵のリストが返される。署名は、InvokeService （...）APIを使用する時に応答サービスメッセージを受信する一部として検証される。メッセージ要素が検証に失敗すれば、検証に失敗したこの状態と要素を示すXMLメッセージがInvokeService （...）から返される。
【０２０５】
３．  ４．サービス適応レイヤ
上記のように、サービス適応レイヤは、サービスを公開し、要求を処理し、サービスの応答を生成し、NEMOフレームワークでサービスを編成する共通方法をサービスプロバイダに提供する。また、その他の特定のサービスインタフェース・バインディングが実装できる基礎も提供する。実施例の一つでは、システム内のサービスのインタフェースを記述するためにWSDLが使用される。
【０２０６】
このようなサービス記述は、特定のインタフェースでサービスのバインディング方法を定義することに加えて、サービスへのアクセス承認に責任を持つ１つ以上の承認サービスプロバイダ、サービスの目的と使用の意味的記述へのポインタ、１つ以上の他のサービスの計画された実行から生じる複合サービスに必要な編成の記述のリストも含む。
【０２０７】
サービスが公開される論理ポイントとして機能することだけでなく、サービス適応レイヤは、NEMOデータタイプの具体的な表示や関与者によりサポートされたプラットフォームのNEMOサービスに指定されたオブジェクトをむしろカプセル化する。また、適切なネイティブサービス実装にサービス関連メッセージをマッピングする機構も含む。
【０２０８】
実施例の一つでは、NEMOフレームワークは、あるプラットフォームあるいは参加者のサービス適応レイヤの認識方法を決定しない。サービス提供ノードがサービスプロトコルの翻訳を必要としない状況、つまり、そのネイティブ・プロトコル経由で通信できるクライアントノードだけにそのサービスが公開されている場合は、そのサービス提供ノードは、サービス適応レイヤを含む必要がない。
【０２０９】
さもなければ、そのサービス適応レイヤは、図８に示されるように、一般的には以下の要素を含む。
【０２１０】
エントリー・ポイント−サービスインタフェース・エントリー・ポイント810と関連のWSDLバインデイングをカプセル化するレイヤ。これらのアクセス・ポイントにより、その他のノードがサービスを起動し、パラメータデータを渡し、結果を収集する。
【０２１１】
メッセージ処理論理−メッセージ処理の論理に対応するレイヤ820で、一般的には、メッセージ処理を制御するメッセージポンプ825、ある種類のXMLデータバインディングサポート826、低レベルのXMLパーサー及びデータ表示サポート827を含む。
【０２１２】
ネイティブサービス−ネイティブサービスAPI830や対応する実装840など、（対応するサービスメッセージがマッピングされている）利用可能なネイティブサービスを表示するレイヤ。
【０２１３】
３．５．ワークフロー照合部（Workflow Collator）
好ましい実施例では、ワークフロー照合部（WFC）は、要求の場合のフローを調整し、一時及び中間結果など任意の関連データを管理し、要求を満たすためのルールを実施することにより、ほとんどの非自明なNEMOサービス要求の解決を支援する。この種類の機能の例は、リレーショナルデータベースの簡単な取引モニターから、Microsoft MTS/COM+に見られるより一般的なモニターまで、取引調整機能の形で見られる。
【０２１４】
実施例の一つでは、ワークフロー照合部は、NEMOノードがサービス実施の要求を満たしたり処理したりする調整を行うことにより、プログラム可能な機構である。WFCは、特定のNEMOノード特性や要件に合わせてカスタマイズが可能であり、従来のメッセージキューからより高度な配信取引調整機能にいたるまで、さまざまな機能をサポートするために設計できる。比較的簡単なWFCは、任意のサービス関連メッセージの保管や検索のインタフェースを提供することもある。この上に構築することにより、以下を含む広範囲の機能をサポートすることが可能になる。（i）より効果的な処理のサービス要求の収集、（ii）合成応答へのサービス応答の簡単な蓄積、（iii）合成サービスを作成するための複数サービス要求とサービス応答の手動編成、（iv）合成サービスを作成するための複数サービス要求とサービス応答の自動編成。
【０２１５】
基本的なサービスインタラクションパターンは、ノードのサービス適応レイヤ経由でNEMOノードに到着するサービス要求により開始される。メッセージは、要求を実現して、応答を返すために、最初にまずWSDLメッセージ・ポンプが管理され、その結果WFCによる管理が発生する。もっと複雑な場合にでも、サービス要求の実現は、複数メッセージと応答、複数ノードの調整参加を要求する場合がある。要求を処理するルールは、システムのサービス記述言語、あるいは、BPELなどのようなその他のサービス結合記述仕様を使用して表現される。
【０２１６】
メッセージがWFCに与えられると、WFCはこの要求を処理する正しいルールを決定する。WFCの実装に応じて、サービス記述論理は、ノードが公開する一連のサービス向けの特定状態のマシンの形で表現されている場合や、より緩やかな形のサービス処理論理形式の処理をサポートする方法で表現される場合もある。
【０２１７】
好ましい実施例では、WFC設計はモジュール式で拡張可能であり、プラグインをサポートする。サービス作成や処理ルールを翻訳することに加えて、WFCではサービス実現処理ライフサイクルを開始する状況下で、又は、一連の継続的なトランザクションにおける入力として、NEMOメッセージを使用するかどうかを決定する必要がある場合がある。実施例の一つでは、NEMOメッセージは、これらの種類を決定するために使用されるIDやメタデータを含む。また、NEMOメッセージは、サービストランザクションの特定、メッセージ処理の促進などの追加の情報を含むこともできる。
【０２１８】
以下に詳細にわたって検討するように、通知サービスは、NEMOシステムのさまざまな実施例により直接的にサポートされる。通知（notification）は、処理の専用サービスインタフェースで受信された、NEMOの利用が可能で関心のあるノードをターゲットとするメッセージを表す。通知は、IDベース及びイベントベースの条件など、通知が拡張可能であるかどうかということに、あるノードが関心があるかどうかを決定するために使用される情報及び条件を運ぶための多様なペイロードタイプのセットを持つこともできる。
【０２１９】
実施例の一つでは、図９Ａに示されているように、サービス提供NEMOノード910は、クライアントノード940からのサービスに対する要求を実現するために、ワークフロー照合部914（例えば、２つのその他のサービスプロバイダからの結果の収集と処理）による編成処理を必要とするサービスを提供する。
【０２２０】
クライアントノード940上のNEMOが有効になったアプリケーション942は、要求を開始して、サービスプロバイダ910により提供されるサービスを起動する。ワークフロー914により、次にそれ自身の要求（アプリケーション942の代わりに）を開始するメッセージ、ノード920上にサービスプロバイダ「Y」922、ノード930にサービスプロバイダ「Z」932それぞれを作成する。そして、ワークフロー914は、クライアントノード940からの本来の要求を実現するために、これら２つのその他のサービス提供ノードからの結果を照合して、処理する。
【０２２１】
要求されたサービスは、複数のサービス提供ノードのサービスを要求しない場合もあるが、代わりにサービス提供ノードと要求しているクライアントノード間の複数のラウンドあるいはフェーズを要求する場合もある。図９Ｂに示されているように、クライアントノード940上のNEMOが有効になったアプリケーション942がサービスプロバイダ910により提供されるサービスを起動する要求を開始するとき、次に、ワークフロー照合部914は、本来の要求を実現するために、クライアントノード940のある複数の通信フェーズに関わる。例えば、ワークフロー照合部914は、メッセージを作成して、クライアントノード940に（アクセス・ポイント944を経由して）送信し、応答を受信処理し、以降の通信フェーズの間に追加のメッセージを作成して（そして追加の応答を受信し）、究極的には、クライアントノード940からの本来の要求を実行する。
【０２２２】
この場合、ワークフロー照合部914は、正しい処理のためにクライアントによる操作のフェーズを追跡するために（おそらく、サービス要求の部分としてのサービス特定のセッションIDあるいは取引IDを基に）、サービスプロバイダ910により使用される。上記のように、これらの複数の通信フェーズ950を処理するために、状態機械あるいは同様な機構や手法が採用できる。
【０２２３】
図９Ｃは、サービス提供ノード960内で、ワークフロー照合部914とメッセージポンプ965の間で起こる比較的基本的なインタラクションの実施の例を示す（ノードのサービス適応レイヤ内、非表示）。上記のように、ワークフロー照合部914は、この編成プロセスの状態を維持する保管及び検索機構966を採用しており、１つ以上のサービス要求962を処理して、応答964を作成する。この簡単な例では、ワークフロー照合部914は、複数のサービス要求と応答を処理でき、比較的簡単な状態機械で実施可能である。
【０２２４】
しかしながら、もっと複雑な処理では、図９Ｄは、サービス編成を管理及び管理されるノード設計を示す。このような機能には、複数サービス要求の収集、合成応答への応答の蓄積、合成サービスを作成するための複数サービス要求と応答の手動あるいは自動編成を含む。
【０２２５】
図９Ｄでは、ワークフロー照合部914を取り囲むアーキテクチャにより、さまざまなケースがサポートされる。例えば、NEMOノードの機能を処理調整の意味を理解する外部のコーディネータ970の機能（サービスに関連するビジネス処理の高度な記述により管理されるビジネスプロセス言語など）、あるいは、使用するセマンティック（semantic）と組合せることにより（お互いの関係においてリソースの意味により管理できるリソース記述フレームワークエンジンなど）、簡単なサービスを土台としてより強力なサービスを作成することが可能である。カスタム外部BPL972及び/あるいはRDF973プロセッサは、手動編成処理966、つまり人間の干渉を含む、処理記述を実行するために、外部ポンプ975を利用することができる。
【０２２６】
NEMOノードのメッセージパンプに伴って機能する外部のコーディネータに依存する手動処理への依存に加えて、モジュールが自動形式のサービス調節や編成968をサポートするワークフロー照合部914と直接統合するアーキテクチャを作成することも可能である。例えば、BPELやEBXMLに表示したり、サービスインタフェースにより関連のウェブサービス・バインディングで通信するような一般的な種類のサービス編成パターンでは、ワークフロー照合部914は、時間の経過とともに到着する要求や応答のメッセージ967や収集により直接管理できる。この場合、合成応答メッセージは、所定の編成プロセッサプラグイン（例えばBPEL 982やEBXML 983など）に関係する状態機械が、そのメッセージが適当であると決定した場合にのみ、メッセージパンプ965にプッシュされる。
【０２２７】
以下は、NEMOワークフロー照合部の実施例により公開される比較的高レベルなAPI記述の実施例である。
【０２２８】
WorkflowCollator::Create （Environment[]） → WorkflowCollator−これは、単独のインタフェースで、初期化されたWFCのインスタンスを返す。WFCは、オプションの環境パラメータセットを基に初期化される。
【０２２９】
WorkflowCollator::Store（Key[] , XML Message） → Boolean−このAPIにより、呼び出し側は、特定の鍵セット経由でWFC内にサービスメッセージを保管できる。
【０２３０】
WorkflowCollator::RetrieveByKey（Key[] , XML Message） → XML Message[]−このAPIにより、呼び出し側は、特定の鍵セット経由で一連のメッセージを検索できる。返されたメッセージはWFC内には含まれなくなる。
【０２３１】
WorkflowCollator::PeekByKey（Key[] , XML Message） → XMLMessage[]−このAPIにより、呼び出し側は、特定の鍵セット経由で一連のメッセージを検索できる。返されたメッセージはまだWFC内に含まれている。
【０２３２】
WorkflowCollator::Clear（） → Boolean−このAPIにより、呼び出し側は、WFC内に保管されている全てのメッセージをクリアできる。
【０２３３】
比較的固定されたBPEL編成標準仕様の代わりとして、別の実施例はよりアドホックなXMLベースの編成記述、例えば分散検索のようなより動的なアプリケーション、を許す。NEMOワークフロー照合部により解釈できる（そして、おそらく十分なリッチランゲージ（rich language）によりサービス全体を置換できる）以下の記述を検討する。
【０２３４】
<WSDL>
<NEMO編成記述（NEMO Orchestration Descriptor）>
<コントロールフロー（Control Flow）>  例えば、サービスAを実行;
もし 結果 = Yes であれば
サービス B;
そうでなければサービスC
<共有状態/コンテキスト（Shared State/Context）>  例えば、デバイス状態
<取引（Transaction）> 例えば、状態、ロールバックなど
<トラスト/認証（Trust/Authorization）> トラストは必ずしもトランジティブでないことに注意
【０２３５】
３．６．典型的DRMエンジンアーキテクチャ
上記のNEMOノードアーキテクチャのさまざまな実施例の状況において、図１０は、DRMエンジン1000のモジュール実施例のNEMOコンテンツ消費デバイスへの統合を示しており、したがって、多くの異種デバイスや環境への統合を容易にする。
【０２３６】
ホストアプリケーション1002は、一般的にユーザインタフェース1004からコンテンツの特定部分にアクセスする要求を受け取る。そして、ホストアプリケーション1002は、関連DRMエンジンオブジェクト（ホストアプリケーションからは、不透明であることが好ましい）とともに要求をDRMエンジン1000に送信する。DRMエンジン1000は、明確に定義されたインタフェースから追加の情報や暗号化サービスをホストサービスモジュール1008に要求することができる。例えば、DRMエンジン1000は、ホストサービス1008に特定のリンクがトラストされているかどうかを問い合わせできる。あるいは、あるオブジェクトが解読されているかどうかを問い合わせできる。いくつかの必要な情報はリモートの場合もあるが、その場合には、ホストサービス1008はサービス・アクセス・ポイント1014によりネットワークサービスから情報を要求できる。
【０２３７】
DRMエンジン1000が特定の操作が許可されると決定したら、これを示し、必要な暗号鍵を全てホストサービス1008に返す。そして、ホストサービスは、ホストアプリケーション1002の指示により、コンテンツサービス1016に依存して必要なコンテンツを取得してその使用を管理する。その後、ホストサービス1008は、必要に応じて暗号サービス1012により調節されるメディアレンダリング1010の処理（例えば、スピーカによりコンテンツを再生、画面にコンテンツを表示など）を開始する。
【０２３８】
図１０に示されたシステム・アーキテクチャは、アプリケーションにおいてDRMエンジンがどのように使用できるかという比較的簡単な例であり、これは多くの可能性のうちの１つに過ぎない。例えば、その他の実施例としては、DRMエンジンは、比較的高レベルなポリシー管理システムの下で、パッケージアプリケーションに統合される。このようなアプリケーションにより依存される異種のDRM関連オブジェクトの記述など、DRMエンジンのクライアント（コンテンツ消費側）とサーバ（コンテンツパッケージ側）双方のアプリケーションについて、以下で検討し、その後にDRMエンジン自体の内部アーキテクチャの実施の一例を示す。
【０２３９】
DRMエンジン1100は、図１１に示されているが、バーチャルマシン、コントロールVM1110に依存して、ノードのアプリケーション1130とインタラクションするためにホスト環境1120（上記、及び以下に詳細）、そして、究極的には、例えばNEMOや他のシステム内のほかのノードを利用して、広範囲のホストプラットフォーム内の内部DRM処理（例えば、コンテンツへのアクセスを管理する制御プログラムを実行）を行う。
【０２４０】
実施例の一つでは、コントロールVM1110は、コンテンツへのアクセスを管理する制御プログラムを実行するDRMエンジン1100の実施例により使用されるバーチャルマシンである。以下は、DRMエンジン1100のアーキテクチャへのコントロールVM1110の統合、及び、その指示セット、メモリモデル、コードモジュール、システム呼び出し1106によりホスト環境1120との統合など、コントロールVMの基本的ないくつかの要素の説明である。
【０２４１】
実施例の一つにおいて、コントロールVM1110は、さまざまなプログラム言語を用いて容易に実装するように設計された比較的小さい容量（footprint）のバーチャルマシンである。実行速度やコード密度をあまり考慮せず、事実上必要最低限度となるように設計されたスタック中心の指令セットを基本とする。しかしながら、実行速度、及び/又は、コード密度がある特定のアプリケーションで出され、パフォーマンスを改善するための従来の手法（例えばデータ比較）が使用できれば、それは高く評価される。
【０２４２】
コントロールVM1100は、低度及び高度なプログラム言語のターゲットとして最適であり、アセンブラー、C、FORTHといった言語をサポートする。Java（登録商標）やカスタム言語のような他の言語のコンパイラも比較的容易に実装される。
【０２４３】
コントロールVM1110は、プロセッサ上あるいはシリコン内で直接実行されるのではなく、ホスト環境1120などDRMエンジン1100内でホストされるように設計される。コントロールVM1110は、コードモジュール1102に保管されている指令を実行することによりプログラムを稼働する。これらの指令の中には、１件以上のシステムコール1106を行うことにより、プログラム自体の外部に実装された関数を呼び出すことができ、システムコール1106は、コントロールVM1110自体により実装されか、ホスト環境1120に委任されるかのどちらかである。
【０２４４】
実行モデル
コントロールVM1110は、メモリ1104にロードされた一連のバイトコードとして、コードモジュール1102に保管された指令を実行する。コントロールVM1110は、指令が実行されるにつれ、増えるプログラムカウンタ（PC:program counter）と呼ばれる仮想レジスタを維持する。VMは、OP_STOP指令に遭遇するまで、あるいは空の呼び出しスタックによりOP_RET指令に遭遇するまで、あるいは例外が発生するまで、順番に各指令を実行する。ジャンプは相対的ジャンプ（現在のPC値からのバイトオフセットとして指定される）、あるいは絶対アドレスとして指定される。
【０２４５】
メモリモデル
実施例の一つでは、コントロールVM1110は比較的簡単なメモリモデルを持つ。VMメモリ1104は、データセグメント（DS）とコードセグメント（CS）に分かれる。データセグメントは、アドレス0から開始する単独のフラットで連続的メモリスペースである。データセグメントは、一般的に、ホストアプリケーション1130あるいはホスト環境1120のヒープメモリ内に割り当てられたバイト配列である。所定のVM実装では、メモリスペースのサイズは、最大に固定されていることが好ましい。そして、スペースの外側のメモリにアクセスしようとすると、障害が発生してプログラムの実行を停止する。データセグメントは、潜在的には、VMにより同時にロードされるいくつかのコードモジュール1102間で共有される。データセグメントのメモリは、メモリアクセス指令によりアクセスでき、32ビットあるいは8ビットアクセスが可能である。32ビットメモリアクセスは、ビッグエンディアン・バイト順（big-endian bute order）使用して実現される。VM可視メモリとホスト管理メモリ（ホストCPUの仮想あるいは物理メモリ）の間の配列に関する仮定は行われない。
【０２４６】
実施例の一つでは、コードセグメントは、アドレス0から開始するフラットで連続的なメモリスペースである。コードセグメントは、一般的に、ホストアプリケーション1130あるいはホスト環境1120のヒープメモリに割り当てられたバイト配列である。
【０２４７】
コントロールVM1110はいくつかのコードモジュールをロードすることができる。そして、全てのコードモジュールは同じデータセグメント（各モジュールのデータは異なるアドレスにロードされることが好ましい）を共有できるが、それぞれは独自のコードセグメントを持つ（例えば、１つのコードモジュール1102のジャンプ指令が別のコードモジュール1102のコードに直接ジャンプすることが可能でないことが好ましい）。
【０２４８】
データスタック
好ましい実施例では、VMは、データセグメントに保管された32ビットのデータセルを示す、データスタックの概念を持つ。VMは、スタックポインタ（SP）と呼ばれる仮想レジスタを維持する。リセット後、SPはデータセグメントの最後をポイントし、スタックは下向きに増加する（データがデータスタックの上にプッシュされると、SPレジスタは減少する）。スタック上の32ビットの値は、スタックデータを参照している指令に応じて、32ビットのアドレス整数あるいは32ビットの符合付き整数として解釈される。
【０２４９】
コールスタック
実施例の一つでは、コントロールVM1110は、ネスト化されたサブルーチン呼び出しを行うコールスタックを管理する。このスタックにプッシュされた値は、メモリアクセス命令により直接読み出しあるいは書込みできないが、OP_JSRやOP_RET指令を実行時にVMにより間接的に使用される。所定のVMプロファイルでは、この返されるアドレススタックのサイズは、ネストされた呼び出しの一定数を超えることができないように、最大に固定されていることが好ましい。
【０２５０】
指令セット
実施例の一つでは、コントロールVM1110は、比較的簡単な指令セットを使用する。指令の数が限定されている場合でも、簡単なプログラムを表記することが可能である。指令セットは、OP_PUSH指令を除き、スタックベースであり、直接的なオペランド（operand）を持つ指令はない。オペランドはデータスタックから読み込まれて、結果はデータスタックにプッシュされる。VMは32ビットVMである。この説明での実施例の全指令は、32ビットスタックオペランドで操作し、メモリアドレスあるいは符合付き整数を表す。符合付き整数は2の補数バイナリコード化を使用して表される。
【０２５１】
以下はある実施例に使用された指令セットの具体例である。
【０２５２】
【表１】
2014146345.tif 000003
【０２５３】
【表２】
2014146345.tif 000004
【０２５４】
モジュールフォーマット
実施例の一つでは、コードモジュール1102は、MPEG-4ファイル形式で使用されるアトム（atom）構造に本質的には同様であるアトムベース形式に保管される。１つのアトムは32ビットから構成され、ビッグエンディアンバイトオーダーに4オクテットとして保管され、その後に4オクテットタイプ（通常、アルファベットの文字のASCII値に対応するオクテット）、その後にアトムのペイロード（サイズ8オクテット）が続く。
【０２５５】
３．７．DRMクライアント-サーバアーキテクチャ：コンテンツ消費とパッケージ
上記のように、DRMクライアント側の消費アプリケーション（例えばメディアプレーヤ）は、DRMコンテンツ（例えば、歌の再生、映画の表示など）を消費する。DRMサービス側のパッケージアプリケーション（一般的にはサーバに常駐）は、DRMクライアント向けコンテンツ（例えば、コンテンツの関連使用や配信権利、暗号鍵関連など）をパッケージする。
【０２５６】
図１２Ａは、DRMクライアントのアーキテクチャの主要素の実施の一例を示す。ホストアプリケーション1200は、ユーザインタフェース1210によりデバイスユーザ（例えば、音楽のプレーヤーの所有者）のインタフェースとなる。ユーザは、例えば、保護されたコンテンツへのアクセスを要求し、コンテンツとともにメタデータを受け取る（例えば、歌とともにアーティストや曲名のテキスト表示）。
【０２５７】
ホストアプリケーション1200は、ユーザインタフェース1210とのインタラクションに加えて、ユーザの要求を実行するために必要なさまざまな機能も実行し、これには、一定の機能を委任している他のDRMクライアントモジュールとのインタラクションを管理することを含むことができる。例えば、ホストアプリケーション1200は、要求されたコンテンツを抽出するために、ファイルシステムとのインタラクションを管理することができる。また、ホストアプリケーションは、保護されたコンテンツのオブジェクト形式を認識して、（例えば、関連制御プログラムを実行することなどにより）保護されたコンテンツにアクセスする許可を与えるかどうかを判断するために、ライセンスを構成するDRMオブジェクトを評価する要求をDRMエンジン1220に発行することが好ましい。
【０２５８】
許可が与えられれば、ホストアプリケーション1200は、必要な署名を検証して、DRMエンジン1220により要求されるその他一般的な目的の暗号機能を暗号サービス1230に委任することが必要になることもある。DRMエンジン1220は、DRMオブジェクトの評価に責任を持ち、許可を確認あるいは拒否して、コンテンツを解読する鍵をホストアプリケーション1200に提供する。
【０２５９】
ホストサービス1240は、ホストアプリケーション1200により管理されるデータのアクセス（及び実装された一定のライブラリ機能）をDRMエンジン1220に提供する。ホストアプリケーション1200は、保護されたコンテンツにアクセスするためにコンテンツサービス1250とインタラクションして、処理が必要なコンテンツの部分だけをDRMエンジン1220に引き渡す。コンテンツサービス1250は、クライアントの一定の保管機構に応じて、外部メディアサーバからそのコンテンツを取得し、コンテンツを管理する。
【０２６０】
コンテンツがアクセスのためにクリアされると、ホストアプリケーション1200は、メディアレンダリングエンジン1260とインタラクション（例えば、鍵の送信などにより）し、クライアントのAV出力装置経由でコンテンツを解読してレンダリング（rendering）する。DRMエンジン1220により必要な情報の中には、コンテンツによる帯域内で利用できるので、コンテンツサービス1250経由で取得管理できるが、その他の情報は外部のNEMO DRMサービスあるいは他の入力から取得することが必要な場合もある。
【０２６１】
好ましい実施例では、全ての暗号操作（暗号化、署名検証など）は、ホストサービス1240から間接的にDRMエンジン1220とインタラクションし、要求を転送する暗号サービス1230により処理される。暗号サービス1230は、コンテンツの解読を実行するメディアレンダリングエンジン1260によっても使用できる。
【０２６２】
サービス側を見ると、図１２Ｂは、典型的DRMサービス側パッケージノードのアーキテクチャの主要要素の実施例を示す。ホストアプリケーション1200は、ユーザインタフェース1210からコンテンツパッケージの実施者（音楽コンテンツの所有者あるいは配信者）とインタラクションする。パッケージの実施者は、例えば、コンテンツが保護され（例えば、暗号化や限定されたアクセス権利関連など）、また、さまざまなエンドユーザや中間コンテンツ提供ノードに配信されるよう、コンテンツやライセンス情報をホストアプリケーション1200に提供する場合もある。
【０２６３】
ホストアプリケーション1200は、ユーザインタフェース1210とインタラクションすることに加えて、例えば、ある機能を委任するその他のDRMパッケージモジュールとのインタラクション管理など、パッケージの実施者の要求を実行するために必要なさまざまな機能も実施することができる。例えば、コンテンツを暗号化するために一般暗号サービス1235とのインタラクションを管理することができる。また、コンテンツを含み、かつ、参照し、そして、ライセンスを含み、又は、参照するコンテンツオブジェクトを作成することもできる（例えば、DRMパッケージエンジン1225がライセンスを構成するDRMオブジェクトを作成後）。メタデータは人間が判読可能な方法でライセンスを説明するライセンスに関係する（例えば、クライアントのユーザが表示する可能性のため）。
【０２６４】
上記のように、ホストアプリケーション1200は、ユーザインタフェース1210からユーザとインタラクションする。コンテンツの参照やパッケージャが実施したいアクション（例えば、コンテンツを誰にバインドするか）などに関する情報の取得に責任を持つ。また、、もし障害が発生すれば、この障害の理由を含む発行されたライセンスのテキストなどのパッケージ処理に関する情報も表示できる。ホストアプリケーション1200が必要な情報の中には、NEMOサービス1270の使用を要求するものもある（例えば、認証や承認、及びメンバーシップなどのようなサービスの利用など）。
【０２６５】
実施例の一つでは、ホストアプリケーション1200は、トランスコード化（transcoding）やパッケージ化などのような、全てのメディア形式の管理をメディアフォーマットサービス1255に委任する。一般暗号サービス1235は、署名の発行や検証、及び、あるデータの暗号や解読に責任を持つ。このような操作の要求は、外部、あるいはホストサービス1240を経由してDRMパッケージエンジン1225から発行される。
【０２６６】
実施例の一つでは、コンテンツ暗号サービス1237は、ホストアプリケーション1200を認識しないので、一般暗号サービス1235とは論理的に分かれる。コンテンツのパッケージ時には、DRMパッケージエンジン1225により以前に発行された鍵セットにより、メディアフォーマットサービス1255により管理される（これら全てはホストアプリケーション1200により調整される）。
【０２６７】
３．８．DRMコンテンツ保護とオブジェクトの管理
実施例の一つとして、コンテンツプロバイダは、コンテンツの暗号鍵の取得に必要な情報を伝達するなど、コンテンツを保護し、その使用を制御するオブジェクトセットを作成するためにDRMパッケージエンジンに依存するホストアプリケーションをユーザに提供する。この条件、つまりライセンスは、このオブジェクトセットを含むために使用される。
【０２６８】
好ましい実施例の一つにおいて、コンテンツとそのライセンスは論理的に分離されているが、オブジェクトIDを使用する内部参照により結合されている。コンテンツとライセンスは、通常一緒に保管されるが、必要あるいは適切であれば別に保管できる。ライセンスは、コンテンツの２つ以上の項目に適用でき、２つ以上のライセンスはコンテンツで任意の単独項目に適用できる。
【０２６９】
図１３は、以下で検討するオブジェクトセット間の関係を含めて、このようなライセンスの実施例を示す。コントロールオブジェクト1320とコントローラオブジェクト1330の双方がこの実施例では署名されたオブジェクトであることに注意する。それゆえ、DRMクライアントエンジンは、保護されたコンテンツへアクセスする許可によりホストアプリケーションへの提供を行う前に、コントロール情報が信頼された情報元からのものであるかどうかを検証できる。この実施例では、これら全てのオブジェクトは、コンテンツオブジェクト1300を除き、DRMクライアントエンジンにより作成される。
【０２７０】
コンテンツオブジェクト−コンテンツオブジェクト1300は、コンテンツとその関連鍵の間のバインディングを促進する固有のID1302を使用して、暗号化されたコンテンツ1304を示す。コンテンツオブジェクト1300は「外部」オブジェクトである。暗号化されたコンテンツ1304の形式と保管（例えば、MP4動画ファイル、MP3ミュージックトラックなど）は、部分的にはコンテンツの種類を基にホストアプリケーションにより決定（あるいはサービスに委任）される。コンテンツの形式は、暗号化されたコンテンツ1304により、関連するID1302のサポートも提供する。パッケージ実施者のホストアプリケーションは、利用可能な任意の暗号化システムを使用して（例えば、AESのような、対照鍵暗号を使用）、コンテンツを形式依存方法で暗号化し、コンテンツオブジェクト1300を管理する。
【０２７１】
コンテンツ鍵オブジェクト−コンテンツ鍵オブジェクト1310は、暗号化された鍵データ1314（オプションでオブジェクト内部に保管された固有の暗号鍵など）を表し、また、対応する固有ID1312も持つ。この鍵データは、コンテンツ鍵オブジェクト1310内に入れられているのであれば、コンテンツを解読することを承認されたものだけに認識できるように、それ自体暗号化されていることが好ましい。また、コンテンツ鍵オブジェクト1310は、この鍵データを暗号化するために使用された暗号化システムも指定する。以下で詳細に検討する実施例であるこの暗号システムは、「鍵配信システム」と呼ばれる。
【０２７２】
コントロールオブジェクト−コントロールオブジェクト1320は、コンテンツの暗号化と解読に使用される鍵の使用を監督するルールを表すコントロールプログラム（例えはコントロールバイトコード1324）を含み、保護する。また、対応するコンテンツ鍵オブジェクトにバインドできるようにID1322も含む。上記のように、コントロールオブジェクト1320は、DRMクライアントエンジンはコンテンツ鍵1310とコントロール1320の間のバインディング、及び、コンテンツ鍵ID1312と暗号化された鍵データ1314の間のバインディングの有効性を検証できるように、署名されている。コントロールバイトコード1324の有効性は、オプションで、コントロールオブジェクト1330に含まれるセキュアハッシュ（例えば、あればコントロールハッシュ1338など）により導くことができる。
【０２７３】
コントローラオブジェクト−コントローラオブジェクト1330は、コンテンツ鍵1310とコントロール1320オブジェクトをバインドするID1312と1322をそれぞれ使用して、鍵とコントロールを監視するルールの間のバインディングを表す。コントローラオブジェクト1330は、そのコンテンツに対するルールのアプリケーションをコントロールすることにより、つまり、どのコントロールがどのコンテンツ鍵オブジェクト1310の使用を監視するかを決定することにより、保護されたコンテンツの使用を監視する。コントローラオブジェクト1330は、各コンテンツ鍵オブジェクト1310とその対応する暗号化された鍵データ1314の間のバインディングによる干渉を防ぐために、参照する各コンテンツ鍵オブジェクト1310のハッシュ1336値も含む。上記のように、コントローラオブジェクト1330は、コンテンツ鍵1310とコントロール1320オブジェクトの間のバインディング、及び、コンテンツ鍵ID1312と暗号化された鍵データ1314の間のバインディングの有効性を検証できるように、署名されることが好ましい（例えば、以下で検討されるように、公開鍵あるいは対称鍵署名を使用して、コントローラオブジェクトを署名できる証明書を持つパッケージ実施者のアプリケーション）。また上記のように、コントローラオブジェクト1330は、署名を別に検証しなくてもコントロールオブジェクト1320の検証を可能にするコントロールハッシュ1338もオプションで含む。
【０２７４】
対照鍵署名−好ましい実施例では、対称鍵署名は、コントローラオブジェクト1330の最も一般的な種類の署名である。実施例の一つでは、この種類の署名は、コントローラオブジェクト1330のMAC（メッセージ承認コード）を計算することにより実装され、コンテンツ鍵オブジェクト1310により表される鍵と同じ鍵によりロックされる。
【０２７５】
公開鍵署名− 好ましい実施例では、この種類の署名は、コントローラオブジェクト1330の署名者のIDが特別に主張されることが必要な場合に使用される。この種類の署名は、このオブジェクトの有効性を主張している本人の非公開鍵をもって署名して、公開鍵署名アルゴリズムにより実装される。この種類の署名を使用する場合は、コントローラオブジェクト1330にあるコンテンツ鍵のバインディング情報は、署名する非公開鍵に追加され、コンテンツ鍵オブジェクト1310に含まれる鍵のハッシュ1336を含むことが好ましい（一般的には非公開鍵のハッシュ）。このバインディングにより、オブジェクトの署名者がコンテンツを保護するために使用された鍵の存在を知っていることを確認する。
【０２７６】
プロテクタオブジェクト−プロテクタオブジェクト1340は、コンテンツの暗号化と解読に使用された鍵の使用をコントロールすることにより、コンテンツへの保護されたアクセスを提供する。プロテクタオブジェクト1340は、保護されたコンテンツをその対応する鍵に関連づけるために、コンテンツオブジェクト1300をコンテンツ鍵オブジェクト1310にバインドする。このバインディングを実現するためには、参照1342と1344はそれぞれ、コンテンツ1300のID1302とコンテンツ鍵1310のID1312を含む。実施例の一つでは、プロテクタオブジェクト1340は、１つ以上のコンテンツ項目に使用された鍵だけではなく、採用された暗号化アルゴリズムの情報を含む。実施例の一つでは、コンテンツ参照1342が１つ以上のコンテンツオブジェクト1300を参照すれば、コンテンツ鍵参照1344は１つだけのコンテンツ鍵オブジェクト1310を依然として参照している場合があり、これらのコンテンツ項目全ては同じ暗号化アルゴリズムと同じ鍵を使用して暗号化されたことを示す。
【０２７７】
３．９．DRMノードとリンクオブジェクト
図１３は、保護されたコンテンツへのアクセスをコントロールするためにDRMエンジンにより作成されたコンテンツ保護及び監視オブジェクトを示すが、図１４は、システム内のエンティティを表すDRMオブジェクト（例えば、ユーザ、デバイス、グループなど）、及び、それらエンティティ間の関係を示す。
【０２７８】
上記の図４は、エンティティとそれらの関係を記述するノードあるいは承認グラフの実施概念を示すが、図１４は、この実施例の概念グラフを実装する次の２種類のオブジェクトを示す。エンティティとその属性を表す頂点（又は「ノード」）オブジェクト（1400aと1400b）と、ノードオブジェクト間の関係を表すリンクオブジェクト（1420）である。実施例の一つでは、制御プログラムを実行することにより、DRMエンジンは、これらのオブジェクトに関与する１つ以上のパターンを引き起こす。例えば、歌を暗号化し、それを特定個人に配信を限定するライセンスに関連付ける。しかし、この実施例のDRMエンジンは、これらのオブジェクトに添付された意味を明示的にも暗示的にも指定しない（例えば、その歌が配信された特定の個人など）。
【０２７９】
実施例の一つでは、DRMプロファイルと呼ばれるこの意味のコンテキストは、ノードオブジェクト自体の属性内に定義される。DRMプロファイルには、一般的にはノード属性（1401aと1401b）を使用して表現される、これらのエンティティの記述、及び、それらが表すさまざまな役割を含むことができる。上記のように、２つのノード1400aと1400bの間のリンク1420は、さまざまな種類の意味関係を表す。例えば、１つのノードが「ユーザ」で、もう１つが「デバイス」であれば、リンク1420は「所有権」を表すだろう。もう１つのノードが「デバイス」ではなく「ユーザグループ」であれば、リンク1420は「メンバーシップ」を表すであろう。リンク1420は、ある場合には一方向性の場合であり、別の場合には双方向性がある（例えば、同じ２つのノード間を２つのリンクで表す場合）。
【０２８０】
ノードオブジェクト1400aと1400bは、一般的には、機密情報をノードの承認された部分にだけ制限するオブジェクト機密保護非対称鍵の組（例えば、ノード1400aの非公開鍵1405aと公開鍵1406aと、ノード1400bの非公開鍵1405bと公開鍵1406b）も持つ。ノードを対象とする機密情報は、ノードの機密保護公開鍵により暗号化される。オプションで、コンテンツ保護非対称鍵組（例えば、ノード1400aの非公開鍵1403aと公開鍵1403bと、ノード1400bの非公開鍵1403bと公開鍵1403b）は、システムが以下で詳細に検討するコンテンツ鍵を配信するためのコンテンツ鍵導出システムを使用する場合、リンクオブジェクトと結合して使用することができる。コンテンツ項目自体は、ノード1400aの対称鍵1402aやノード1400bの鍵1402bといった、コンテンツ保護対称鍵により保護できる。
【０２８１】
上記の通り、実施例の一つ（例えばリンク1420）では、リンクオブジェクトはノード間の関係を表示する。これらの関係の意味はノード属性（例えばノード1400aの1401aやノード1400bの1401b）に保管され、リンクオブジェクト内で参照（例えばノードリファレンス1422からノード1400a、ノードリファレンス1424からノード1400b）される。また、リンクオブジェクトは任意に暗号情報（例えば鍵誘導情報1426）を含ませることで、以下に記述されるようにリンクオブジェクトをカウンタ鍵導出として使用することが可能になる。
【０２８２】
実施例の一つでは、リンクオブジェクトは自体は、単一のオブジェクトであり、上記の図4のようにグラフ内の有向辺で表わされる。あるノード（例えばノードX）と別のノード（例えばノードY）の間にそのような有向辺が存在する場合、ノードXからノードYへの「パス」には、ノードYがノードXから「連絡可能」であることが示唆される。パスは特定の機能を果たす条件として、他のDRMオブジェクトにより使用されることもある。コントロールオブジェクトは、ターゲットノードが連絡可能であるかを決定するために、関連した内容のオブジェクトを施行する前に事前にチェックすることもある。
【０２８３】
例えば、仮にノードDがコントロールオブジェクトに「プレイ」アクションを施行するデバイスである場合、このコンテントオブジェクトを統括するコントロールは、特定のユーザを表すノードUがノードDから到達可能かどうかをテストし（例えばそのユーザがデバイスの「所有者」であるかどうか等）、条件が満たされている場合にのみ「プレイ」アクションの施行を許可することもある。ノードUが到達可能かどうかを決定するにあたり、DRMエンジンは制御プログラムを実行し、ノードDとノードU間にパスを設立（例えば直接的又は間接的関係）できるリンクオブジェクトが存在するかを判断することができる。上記の通り、実施例の一つでは、DRMエンジンは関係の意味を認識しておらず、単にパスの存在のみを判断し、例えばホストアプリケーション等がこのパスを条件付許可として解釈し、保護されたコンテントへのアクセスを認可するようにする。
【０２８４】
実施例の一つでは、DRMエンジンは、システムのノードグラフ内にパスが存在するかを判断するために、リンクオブジェクトをその使用前に検証する。リンクオブジェクトの有効性は、いつでもリンクオブジェクトの署名に使用される証明システム（以下に詳細する）の特定の機能にしたがって変化することがある。例えば、各種の条件を基にして、しばしば有効性「存続期間」が制限されたり、撤回されたり又は再有効化されたりする。
【０２８５】
さらに、実施例の一つにおいて、どのエンティティがリンクオブジェクトに署名できるか、どのリンクオブジェクトが創造可能かを統括するポリシー、そしてリンクオブジェクトの存続期間がDRMエンジンによって直接決定されていない。その代わりに、ノード属性情報が活用されることがある。特定のポリシーの施行を容易にするため、システムは標準証明フォーマットに追加制約チェックを付加するための方法を提供することもある。これらの拡張は、リンクを署名する鍵の証明に認証制約を付すことを可能にし、リンクが有効と見なされる前に制約（例えばリンクにより連結されるノードの種類やそのほかの属性等）のチェックを行うことができる。
【０２８６】
最後に、実施例の一つにおいて、リンクオブジェクトに、ユーザに対して鍵分配用のノードのコンテンツ保護鍵を提供する特定の暗号情報が含まれていることがある。例えば暗号情報には、メタデータに加え、「to」ノードのコンテンツ保護公開鍵、及び/又は、コンテンツ保護対称鍵により暗号化された「from」ノードの非公開そして/又は対称コンテンツ保護鍵が含まれていることがある。例えば、デバイス・ノードとユーザ・ノードを特定規定に則りリンクするリンクオブジェクトを作る能力が付与されたエンティティは、確かにデバイスを表しているということを示す属性を持つノードオブジェクトと、ユーザを表しているということを示す属性を持つノードの間にのみリンクを作ることを保証するための検査を施行ことができる。
【０２８７】
３．１０．DRM暗号鍵
図１５は、DRM鍵分配システムの施行態様の一例である。図１５に示される鍵分配システムの基本原理は、リンクオブジェクトを、ノードオブジェクト間の連結を設立するという主要目的に加えて、鍵の分配にも使用するということにある。
【０２８８】
上記の通り、コントロールオブジェクトには、要求された操作が許可されるべきかを決定する制御プログラムが含まれていることがある。制御プログラムは、特定のノードが一連のリンクオブジェクトを通じて連絡可能かどうか判断するための検査を行う。図１５に示される鍵分配システムは、鍵の分配を容易にする目的でリンクオブジェクトのサーチを活用し、制御プログラムを施行しているDRMエンジンによる使用を可能にする。
【０２８９】
実施例の一つでは、鍵分配システムを使用する各ノードオブジェクトは、１つ又はそれ以上の鍵を有する。これらの鍵は、コンテンツ鍵やその他ノードの鍵分配鍵の暗号化に使用される。同様の方法で使用されるために作られたリンクオブジェクトには、DRMエンジンが一連のリンクをプロセスした場合に鍵情報の獲得を許可するいくつかの暗号情報ペイロードが含まれている。
【０２９０】
このようにノードやリンクがを鍵を所持し、一連のリンクがあれば（例えばノードA から、ノードB…ノードZへ等）、ノードAの非公開鍵にアクセスできるエンティティは、ノードZの非公開鍵にもアクセスが可能である。ノードZの非公開鍵へのアクセスがあれば、エンティティはこれらの鍵により暗号化されたどのコンテンツ鍵にもアクセスできる。
【０２９１】
鍵分配システムに関与するノードオブジェクトには、その情報の一部として鍵が含まれている。図１５に示されるように、実施例の一つには各ノードに以下の３つの鍵が含まれている（1500a、1500b及び1500c）。
【０２９２】
公開鍵Kpub [N]−これは一対の公開/非公開鍵の公開部分で、公開鍵解読用に使用される。実施例の一つでは、この鍵（1500aノードの1505a、1500bノードの1505b及び1500cノードの1505c）には認証（以下に記述）が含まれており、暗号化した秘密情報を付加することを希望するエンティティによりその信用証明が認証される。
【０２９３】
非公開鍵Kpriv [N]−これは一対の公開/非公開鍵の秘密部分である。ノードを管理するエンティティは、この非公開鍵（1500aノードの1515a、1500bノードの1515b及び1500cノードの1515c）を守秘する責任がある。そのため、実施例の一つでは、この非公開鍵は、その他のノード情報とは別に格納・運搬されている。
【０２９４】
対称鍵Ks [N]−この鍵は相称的暗号（以下に記述）と共に使用される。この非公開鍵（1500aノードの1525a、1500bノードの1525b及び1500cノードの1525c）が秘密であるため、ノードを管理するエンティティは、この鍵を守秘する責任がある。
【０２９５】
図１５に示される鍵分配システムは、別の暗号アルゴリズムを使用して運用することもできるが、これには通常エンティティによりサポートされるアルゴリズム群が承認されなくてはならない。別の実施例においては、少なくとも公開鍵暗号（例えばRSA）が１つ、対称鍵暗号（例えばAES）が１つサポートされている。
【０２９６】
以下は各表記法が意味する暗号機能である。
Ep（Kpub [N], M）は、「公開鍵暗号を使用し、ノードNの公開鍵Kpubにより暗号化されたメッセージM」を意味する。
【０２９７】
Dp（Kpriv [N], M）は、「公開鍵暗号を使用し、ノードNの非公開鍵Kprivにより解読されたメッセージM」を意味する。
【０２９８】
Es（Ks [N], M）は、「対称鍵暗号を使用し、ノードNの対称鍵Ksにより暗号化されたメッセージM」を意味する。
【０２９９】
Ds（Ks [N], M）は、「対称鍵暗号を使用し、ノードNの対称鍵Ksにより解読されたメッセージM」を意味する。
【０３００】
「コンテンツ・鍵」をノードに連結することは、当該ノードの非公開鍵にアクセスできるエンティティがその鍵を利用できるようにすることを意味する。実施例の一つでは、これは以下の一つ又は双方の方法により、鍵を暗号化することを通じて行われる。
【０３０１】
公開バインディング：Ep（Kpub[N], CK）を含むコンテンツ鍵オブジェクトを作る。
対象バインディング：Es（Ks[N], CK）を含むコンテンツ鍵オブジェクトを作る。
【０３０２】
本実施例では、受け入れ側のエンティティの負担を削減するために、コンピューターによるアルゴリズム使用がより少ない対象バインディングができる限り使用されている。しかし、コンテンツ鍵オブジェクトを作成するエンティティ（例えばコンテンツパッケージャ）が常にKs[N]へのアクセスがあるとは限らない。この場合には、Kpub[N]が秘密情報ではなく利用できることから、公開バインディングが使用される。Kpub[N]は通常、カウンター鍵との連結が必要なエンティティに認証と共に提供され、エンティティはKpub[N]が確かに同意方針にしたがってコンテンツ鍵を処理できるノードの鍵であることをが判断するためにこれを検査できる。
【０３０３】
実施例の一つでは、エンティティが連絡可能な全ての分配鍵にアクセスできるように、リンクオブジェクトに「ペイロード」が含まれている。ペイロードにより、リンクの「fromノード」の非公開鍵にアクセスできるエンティティは、同様にリンクの「toノード」の非公開鍵にアクセスできる。このようにして、エンティティは、そのノードから到達可能なあらゆるコンテンツ鍵のターゲットノードを解読できる。
【０３０４】
ここで図１５を再び参照する。以上から分かるように、ノード1500aをノード1500bに連結する1530aリンクには、ノード1500bの非公開鍵1515bと1525bの暗号化により作成されたペイロードがノード1500aの対称鍵1515aと共に含まれているか、万一これが（例えば守秘義務などにより）利用できない場合には、ノード1500aの公開鍵1525aが含まれる。同様に、ノード1500bをノード1500cに連結する1530bリンクには、ノード1500cの非公開鍵1515cと1525cの暗号化により作成されたペイロードがノード1500bの対称鍵1515bと共に含まれているか、万一これが利用できない場合には、ノード1500bの公開鍵1525bが含まれる。
【０３０５】
DRMエンジンがリンクオブジェクトを処理すると、アクセスがある鍵の内部連鎖1550を更新するために各リンクのペイロードが処理される。実施例の一つでは、ノードAからノードBへのリンクのペイロードは以下のいずれかから構成されている。
【０３０６】
公開派生情報
Ep（Kpub [A], ｛Ks [B], Kpriv[B]｝）
又は、
対象派生情報
Ep（Ks [A], ｛Ks [B], Kpriv [B]｝ ）
ここで、｛Ks[B], Kpriv[B]｝はKs[B]とKpriv[B]を含むデータ構造である。
【０３０７】
公開派生情報は、ノードB、Ks [B]とKpriv [B]の非公開鍵をノードA、Kpriv[A]の非公開鍵へのアクセスがある全てのエンティティに提供するために使用される。また、対象派生情報は、ノードB Ks[B]とKpriv[B]の非公開鍵をノードA、Kpriv[A]の対称鍵へのアクセスがある全てのエンティティに提供するために使用される。
【０３０８】
このように、鍵連鎖1550に関連し、ノード1500a（非公開鍵1515aと対称鍵1525a）の非公開鍵にアクセスできるエンティティは、DRMエンジンにこれらの非公開鍵1560を鍵連鎖1550において「第一リンク」（そしてそれ以降の生成の出発点として）として利用させることができる。スキューバ鍵（Scuba key）1560はリンク1530a内で1555aコンテンツ鍵オブジェクトを解読するために使用され（公開鍵1505aを通じて公開バインディングが使用されている場合は公開派生用に非公開鍵1515aを使用、また対称鍵1525aを通じて対象バインディングが使用されている場合は対象派生用に非公開鍵1525aを使用）、結果として次のリンク1570を鍵連鎖1550内に生じる−つまりノード1500b（非公開鍵1515bと対称鍵1525b）の秘密鍵である。DRMエンジンは、これらの鍵1570をリンク1530b内で1555bコンテンツ鍵オブジェクトを解読するために使用し（公開鍵1505bを通じて公開バインディングが使用されている場合は公開派生用に非公開鍵1515bを使用、また対称鍵1525bを通じて対象バインディング（symmetric bunding）が使用されている場合は対照導出用に非公開鍵1525bを使用）、結果として最終リンク1580を鍵連鎖1550内に生じる−つまりノード1500c（非公開鍵1515cと対称鍵1525c）の秘密鍵である。
【０３０９】
実施例の一つでは、DRMエンジンはリンクをどの順序でも処理できるため、リンクが処理された時点では鍵導出を施行できないことがある（例えば、当該リンクの「from」ノードの鍵が生成されていないため等）。この場合、リンクは記憶され、そのような情報が利用できるようになった時点で再び処理される（例えば、ノードが「to」ノード状態でリンクが処理された場合）。
【０３１０】
３．１１．DRM証明書（certificates）
以上の通り、ある実施例では、暗号鍵と関連してこれらの鍵により作成された電子署名に基づく決定以前に、信用証明（credential）を検査するために証明書が使用される。ある実施例では、複数の証明書技術がサポートされ、有効期間や名前などの証明書の一般的要素として通常利用可能な既存の情報が活用される。これらの一般的要素に加え、証明書鍵の潜在的使用を制限するために、その他の制約をコード化することもできる。
【０３１１】
ある実施例では、これは鍵使用拡張を証明書暗号化処理に含めることにより実行されている。そのような拡張でコード化された情報により、DRMエンジンは特定のオブジェクトを署名した鍵がそのような目的で使用されることが許可されているかを判断できるようになる。例えば、ある鍵は特定の属性があるノードからのリンク、及び/又は、別の特定の属性があるノードへのリンクを含むオブジェクトのみ署名することを許可する証明書を含む。
【０３１２】
証明書を表現する基盤技術は、そのセマンティックスが、リンクやノードのような要素を読み取れないので、通常は、そのような制約を表現することはできない。したがって、ある実施例では、以上のような特定の制約は「使用カテゴリ」やそれに対応した「制約プログラム」などを含む基本証明書の鍵使用の拡張として搬送される。
【０３１３】
使用カテゴリは、鍵がどのタイプのオブジェクトを署名することが許可されているかを指定している。制約プログラムは、動的条件を状況にしたがって表すことができる。ある実施例では、証明書の有効性を検査することを要請された検証者には、鍵使用拡張表示の査定はDRMエンジンに帰属されているにもかかわらず、関連操作を理解することが要求される。証明書は、プログラムの施行が好ましい結果を生み出す場合のみ有効とみなされる。
【０３１４】
ある実施例では、制約プログラムの役割はブーリアン型の値を返すことで、「真（True）」は制約条件が満たされたことを示し、「為（False）」は制約条件が満たされていないことを示す。制御プログラムは、決定に必要な状況情報へのアクセスを有することもある。利用可能な状況情報は、DRMエンジンが証明書の認証を要求する際に行う決定のタイプにより変わってくる。例えば、ある情報をリンクプロジェクトに使用する前に、DRMエンジンはオブジェクトを署名した鍵の証明書がその目的に鍵を使用することを許可することを検査することがある。制約プログラムが実行される場合、DRMエンジンの環境にはリンクの属性関連情報及びリンクにより参照されるノードの属性情報が流入する。
【０３１５】
鍵使用拡張に組み込まれた制約プログラムは、ある実施例ではコードモジュールとして（上記で説明）コード化されている。このコードモジュールは、例えば「EngineName.Certificate.<Category>.Check」などの少なくとも１つのエントリー・ポイントを読み込むのが好ましく、ここでのCategoryはどのカテゴリの証明書をチェックすべきかを指示する名前である。認証プログラムのパラメータはエントリー・ポイントが呼び出される前にスタックに保管される。スタックに保管されるパラメータの数とタイプは検査される証明書の拡張カテゴリにより異なる。
【０３１６】
４．システム操作
４．１．基本ノードインタラクション
以上でDRMアプリケーションに関連した実施例を含めたNEMOシステムの主要構築要素の各種実施例の検討を終わりにし、次にNEMOシステムの運用に移る−これは、アプリケーション特有の機能性が階層化できるような基盤を設立するNEMOモードの又はその中におけるイベントシーケンスである。
【０３１７】
ある実施例では、NEMOモードがアプリケーション特有の機能を呼び起こす前に、初期化と認証のプロセスが実施される。ノードはまず希望するサービスを（要求、登録や通知などを通して）判明し、これらのサービスを使用する許可を取得する（例えば、サービスが信用できるものであり、関連するサービスプロバイダ規定を満たしている等）。
【０３１８】
図１６は、この処理を示しており、サービスプロバイダ1600（この実施例では、サービス提供ノード1610と許可ノード1620の間で機能性が共用されている）とサービス・リクエスタ1630（例えばサービス利用者であるクライアント）間の基本的対話をまとめたものである。この対話は直接行われなくともよい。サービス・リクエスタ1630とサービスプロバイダ1600との間のパスに不特定数の中間ノード1625を設けることができる。この処理の基本的ステップは、以下に詳細されるように、クライアント・サービス・リクエスタ1630とサービスプロバイダ1600の双方の点から説明される。
【０３１９】
サービス・リクエスタ1630からの視点では、図１６に示されるイベントの論理的流れは以下の通りである：
【０３２０】
サービス・ディスカバリ−ある実施例では、サービス・リクエスタ1630は希望するサービスを提供するNEMO使用可能ノードを検索し、どのサービス・バインディングが関連サービスインタフェースのアクセスをサポートしているかに関する情報を取得するためにサービス・ディスカバリ・要求を起動する。サービス・リクエスタ1630は発見されたサービスに関する情報をキャッシュに格納することがある。また、NEMOノード間のサービス・ディスカバリのインタフェース・メカニズムは、NEMOノードが施行し公表するサービスの一つに過ぎないことを記しておく。サービス・ディスカバリ・プロセスは、サービスプロバイダにより登録されたサービス・リクエスタへの通知などのその他のコミュニケーション形態と共に以下に詳細に記載される。
【０３２１】
サービス・バインディング選択−潜在的サービス提供ノードが見つかると、要請ノードは特定のサービス・バインディングにしたがって１つ又はそれ以上のサービス提供ノードを指定する（要請を発する）ことを選択できる。
【０３２２】
許容される範囲でのサービスプロバイダとの信頼関係のネゴシエーション−ある実施例では、２つのノードがセキュアに通信するには信頼できる関係を築くことが要求される。これには、自己識別（identity）を決定するために使用される完全性保護エンベロープ（integrity-protected envelope）内にあり互換性のある信用証明（trust credentials）（例えばX.500証明書、トークン等）の交換、及び／又は、お互いに信頼できる証明書（certificates）に基づくSSLチャンネルのようなセキュアなチャンネルの設立が含まれるだろう。特定の場合には、信用証明の交換やネゴシエーションがサービスインタフェース・バインディングの潜在的特性であることがある（例えばインタフェースがウェブサービスのように公表されている場合に使用されるWS-XMLプロトコルではWS-セキュリティ、また既知の２つのノード間ではSSL要求）。その他の場合には、信用証明の交換やネゴシエーションは、明確に別々のステップであることもある。NEMOは、一定の融通性があるフレームワークを提供するため、ノードは通信をする上で信頼できるチャンネルを設立できる。各ノードは、その特性と対話に関連するサービスの特性にしたがって、別のノードと対話する上でどの信用証明が必要であるか決定し、さらにそのノードを信頼するかどうかの決定をする。ある実施例では、NEMOフレームワークは、特にセキュリティ関係のデータタイプやプロトコルの分野では、既存又は新規の基準を活用する。例えば、ある実施例では、フレームワークは、サービスを呼び出す場合にサービス・リクエスタからサービスプロバイダへ提供された双方の信用証明（証拠）を記述することを目的としたSAMLの使用、そしてSAMLを認証クエリーや認証応答を表す方法として使用することをサポートする。
【０３２３】
要求メッセージの作成−要求ノード1630の次のステップは希望するサービスに対応する的確な要求メッセージの作成である。この操作はサービス・アクセス・ポイントにより隠蔽されていることがある。上記の通り、サービス・アクセス・ポイントはNEMOフレームワーク内でサービスプロバイダと対話する場合にはアブストラクションとインタフェースを提供し、メッセージマッピングサービスのための固有インタフェース、オブジェクト・シリアライゼーション/デシリアライゼーション、互換性のあるメッセージフォーマットのネゴシエーション、トランスポート機構やメッセージ・ルーティング問題などの特定サービスの実施を隠蔽することがある。
【０３２４】
要求の発送−一度要求されたメッセージが作成されると、ターゲットのサービス提供ノード−たとえばノード1610−に発送される。要求の通信形態はサービス・バインディングそして/又は要求先のクライアントの好みにより、同期/非同期RPC形態又はメッセージ志向である場合がある。サービスとの交信はサービスメッセージの送信もしくは処理、又はNEMOサービス・アクセス・ポイントを通じたネイティブ・インタフェースにより行われる。
【０３２５】
返答メッセージの受理−要求を発信すると、要求ノード1610は１つかそれ以上の返答を受け取る。サービスインタフェース・バインディングの詳細と要求ノード1610のプリファレンスにより、返答はRPC返答形式や通知メッセージなどの多様な方法で行われる。上記の通り、要求と返答は中間ノード1625によりターゲットノードにルーティングすることができ、また中間ノード1625はそれ自体ルーティング、トラストのネゴシエーション、照合、相互関係機能などのサービスを提供することができる。本実施例における全てのサービスは、同一の一定フレームワーク内で記述、発見、許可、拘束そして交信された「標準」NEMOサービスである。サービス・アクセス・ポイントは、ノードからメッセージレベルのアブストラクションを隠蔽することがある。例えば、ノードの視点では、サービスの呼び出しは単純な一定のパラメータによる通常のサービス呼び出しであるように解釈される。
【０３２６】
ネゴシエート信頼セマンティックに関する応答の認証−ある実施例では、要求ノード1630は、返答メッセージがサービス提供ノード1610とのネゴシエート信頼セマンティックに準拠していることを保証するために返答メッセージを認証する。
【０３２７】
メッセージペイロードの処理−最後に、適切な処理は（特定アプリケーションの）メッセージペイロードの種類と内容にしたがって適用される。
【０３２８】
以下は、サービスプロバイダ1600の観点から見たイベントの（ある程度類似した）論理的な流れである。
【０３２９】
サービスサポートの決定−まず、要求されたサービスがサポートされているかが決定される。ある実施例では、NEMOフレームワークは、サービスインタフェースによるサービス・エントリー・ポイントのマップイングに関する形態や精度を指定しない。基も単純な場合には、サービスインタフェースは与えられたサービスを疑うことなくマップし、インタフェースのバインディングと実施によりサービスのサポートを構成する。ただし、単一のサービスインタフェースが多種の要求を処理することもあり、またサービスタイプにノードが希望する特定の機能をサポートするかどうか決定する前に抽出する必要がある追加属性が含まれていることもある。
【０３３０】
サービス・リクエスタとの許容される信頼関係のネゴシエーション−特定のケースでは、サービスプロバイダ1600は要求ノード1630を信頼するかどうか決定する必要があり、信頼できるコミュニケーションチャンネルを設立する必要がある。この処理は上記で詳細に説明されている。
【０３３１】
サービスインタフェースへのアクセスを許可するノードへの要求承認発信−サービス提供ノード1610は、要求ノード1630がサービスへアクセスすることが認証されているか又はその信用証明があるか、また認証又は信用証明を有する場合、どのような条件が付されているか決定する。この決定はローカル情報にしたがって、又はネイティブサポートの認証決定機構を通じて行われる。ローカルでサポートされない場合、サービス提供ノード1610は、要求ノード1610が要求サービスへのアクセスが許可されているか決定するために、認証要求をサービス統括する既知のNEMO認証サービスプロバイダ（例えば認証ノード1620）に発信することがある。多くの状況において、認証ノードとサービス提供ノード1610は同一のエンティティであり、この場合、認証要求の発信と処理はＣ関数のエントリー・ポイントといった処理の軽いサービスインタフェース・バインディングにより呼び起こされたローカル操作により実施される。ただし、この機構はそれ自体が単にNEMOサービスであるため、施行を完全に分散することも可能である。認証要求は識別情報及び/又はNEMOノード自体と関連した属性、又はユーザに関した情報及び/又はノードに関連したデバイスを参照できる。
【０３３２】
認証応答の受領時におけるメッセージ処理−認証応答を受け取った時点で要求ノード1630が認証されていれば、サービスプロバイダ1600は要求を遂行するために必要な処理を実施する。要求ノード1630が認証されていない場合、適当な「認証否定」メッセージが出力される。
【０３３３】
応答返信メッセージ−応答はそこでサービスインタフェース・バインディングと要求ノード1630のプリファレンスにしたがって、RPC応答形式又は通知メッセージなどの通信方法の一つを使用して返される。上記の通り、要求と返答は中間ノード1625によりターゲットノードにルーティングすることができ、また中間ノード1625はそれ自体ルーティング、トラスト・ネゴシエーション、照合、相互関係機能などのサービスを提供することができる。中間ノード1625により提供される必要なサービスの一例としては、要求ノード1630により認知される方法でメッセージを発信する通知処理ノードへの発信である。「付加価値」サービスの一例としては、例えば要求ノード1630のプリファレンスが知られている場合、クーポンを応答に結び付けるクーポンサービスが挙げられる。
【０３３４】
４．２通知
上記の通り、クライアントが要求し返答を待つか、又はチケットの償還を通じて返答を定期的にチェックする非同期と同期RPC類似コミュニケーションパターンに加え、NEMOの実施例の中には、通知の概念にしたがって通信パターンの純粋なメッセージ形態をサポートできるものもある。以下の要素は、実施例の一つにおけるこの通知の概念をサポートするデータ及びメッセージ形態を形成している。
【０３３５】
通知−興味が示されたエンドポイントノードでの特別形態ペイロードを含むメッセージ。
【０３３６】
通知条件−特定のノードが特定の通知を受け入れるかどうか決定するために使用されるカテゴリ。通知条件には、特別な種類の自己識別（例えばノードID、ユーザID等）、イベント（例えばノードディスカバリ、サービス・ディスカバリ等）や類似グループ（例えば新しいジャズクラブに関する内容）、又は一般カテゴリ（例えば広告）に基づく事項が含まれる。
【０３３７】
通知ペイロード−カテゴリ化された通知内容。ペイロードカテゴリは単純なテキストメッセージである場合もあれば、複雑なオブジェクトである場合もある。
【０３３８】
通知ハンドラ・サービスインタフェース通知が受理されるサービスプロバイダのインタフェースのカテゴリ。サービスプロバイダはまた、インタフェースに関連した通知条件や、受け入れ可能のペイロードカテゴリも表す。このインタフェースをサポートするノードは、通知の最終目的である場合と中間プロセシング・エンド・ポイントである場合がある。
【０３３９】
通知プロセッサ・サービス−ノードに対し通知を照合することができるサービスで、特定の規定にしたがって通知を発送する。
【０３４０】
通知発信元−通知を関心があるノード群、又は中間通知処理ノード群に向けて発信するノード。
【０３４１】
通知、通知インタレストそして通知ペイロードは拡張可能であることが好ましい。さらに、通知ハンドラ・サービスインタフェースは、他のノード・サービスインタフェースと同様の認証プロセスであることが好ましい。このように、特定の通知が関心（interest）と受け入れ可能なペイロードと一致しても、ノードは中間発信者又は通知の発信元に関連したインタフェース規制に基づきその通知を拒否することがある。
【０３４２】
図１７Ａは通知処理ノード1710群による通知ハンドラサービスをサポートする1715aノード1720の探知を示している。サービス内容の一部として、ノード1720は通知関心ならびにどの通知ペイロードタイプが受け入れ可能かを指定する。
【０３４３】
図１７Ｂには、通知がどのように発信されるかが示されている。どのノードも通知の発信元、又はプロセッサとなることができ、また通知ハンドラ・サービスをサポートするノード1720への通知の発送を行う場合がある。このように、ノード1710aが通知処理ノードの発信元である場合と、そのような機能がノード1710c（通知の発信元）とノード1710b（通知のプロセッサ）の間で分担される場合がある。さらに、別のノード（表示されていない）が通知の発送を行う場合もある。外部通知発信元であるノードからの通知を処理することを決定した通知プロセッサは、効率性を向上するためにマイクロソフト通知サービスのような市販の通知処理エンジンを統合することもある。
【０３４４】
４．３  サービスディスカバリ（service discovery）
NEMOサービスを使用するに当たり、NEMOノードはまずそのサービスに関する知識を必要とする。図１８Ａ〜Ｃは、NEMOの実施例の一つで、３つのダイナミックディスカバリ機構がサポートされている。
【０３４５】
クライアントドリブン−NEMOノード1810a(図１８Ａ)は明示的に「サービスクエリー」サービスインタフェース1815aをサポートするノード群(例えば1820a)に向けて、そのノードが特定のサービスをサポートするかどうかを尋ねる要求を発する。もし要求ノード1810aが認証されると、サービス提供ノード1820aは、要求されたインタフェースそしてその関連サービスインタフェースバインディングがサポートされるかどうかの返答を発信する。これはノードがサービスを表明する場合、ノードによりサポートされる比較的一般的なインタフェースである。
【０３４６】
ノード登録−NEMOノード1810b(図１８Ｂ)は、そのサポートサービスを含む詳細をサービス提供ノード1820bのようなその他のノードに登録することができる。もしノードがインタフェース1815bをサポートする場合、その他のノードからの要求を受入れ、特定の規則に従ってそれらの詳細がキャッシュに格納される。これらのノード詳細は、キャッシュされた詳細があるノードへのサービスクエリーを実施する受理側のノード又はその他のノードにより利用可能なディレクトリとなる。P2Pへの登録に変わる方法として、ノードは検索サービス用のUDDI(ユニバーサル・ディスカバリ、ディスクリプション＆インテグレーション)一般登録のようなパブリック登録を利用することもできる。
【０３４７】
イベントベース−ノード(例えば図18cのノード1810c)は状態の変化(例えばノードのアクティブ/利用可能など)の通知1815aを関心があるノード1820c(「通知認知」している、又は以前に関心を示したノード)に送信するか、又は特定のサービスをサポートすることを宣伝する。通知1815aはノードとそのサービスの完全な記述を含んでいることもあれば、イベントに関連したノードのIDのみを含んでいることもある。関心があるノードは受入れ承認を選択し、通知をプロセスすることができる。
【０３４８】
４．４  サービス認証と信頼の確立
上記の通り、ある実施例では、NEMOは要請されたサービスへのアクセスを許可する前にまず要求ノードがそのサービスへのアクセスを許可されているか、またその場合にはどのような条件が付加されているかを決定する。アクセス許可はサービスリクエスタとサービスプロバイダ間の交信の信頼に基づいている。以下に説明されるように、ノードは信頼できると判断した場合でも、サービス提供ノードにより特定のサービス又は複数のサービスへのアクセスを認可する前に特定の規則を満たすことを要求することもある。
【０３４９】
ある実施例では、NEMOはお互いに信頼するかどうかを決定するための、任意のノード群により使用される特定の要求、カテゴリ又は意思決定論理を指定していない。トラスト動作はノードによりかなりの差があることもある。その代わり、MEMOはノードがお互いに受入れ可能な信頼関係を交渉するための一連の標準ファシリティーを提供する。ノード間の信頼の決定と確立にあたり、NEMOは信頼できる内容の確立に使用されるノード間の証明書(そして/又は関連情報)の交換をサポートする。そのような信頼関係信用証明は、以下を含む各種のモデルを通じて交換することができる。
【０３５０】
サービスバインディングプロパティ−信頼信用証明がサービスインタフェースバインディングの一部として自動的に交換されるモデル。例えば、ノード1920a(図１９Ａ)がサービスをSSL上でHTTPポストとして、又はWS-セキュリティXML署名を必要とするウェブサービスとして表示する場合、当該サービスバインディングの実際のプロパティは、要求ノード1910aと共に必要とされる全ての信頼関連信用証明1915aを交信する。
【０３５１】
要請/返答属性−信用証明の交換が、要求ノード1910bとサービス提供ノード1920bの間のWSDL要請と返答メッセージを通じて行われ、信用証明が任意にメッセージ1915bの属性として含まれる。例えば、デジタル証明書は要請と返答メッセージに添付されまた流通され、信頼関係を確立するために使用される。
【０３５２】
明示的交換−信用証明が、ノードに含まれる信用証明に関する情報のクエリーを許可するサービスプロバイダインタフェース(図１９Ｃの1915c)を通じて明示的に交換されるモデル。これは通常最も綿密なモデルで、要求ノード1910cとサービス提供ノード1920c間で信用証明の交換が行われるには個別の往復セッションが必要とされる。サービスインタフェースバインディング自体は、信用証明の明示的交換のためのお互いに受入れ可能な信頼チャンネルを提供する。
【０３５３】
これらの基本的モデルの他にも、NEMOは個別の方法の組み合わせもサポートできる。例えば、完全に信頼できないサービスバインディングに関連したコミュニケーションチャンネルが、セキュリティ関連信用証明の交換をより直接ブートするため、又は(インテグリティを内包する形態を持つかもしれない)セキュリティ関連信用証明に直接使用するため、あるいはサービスインタフェースバインディングに関連したセキュアなコミュニケーションチャンネルを確立するために使用されることもある。
【０３５４】
上記の通り、トラストモデル動作と信用を確立する処理は、エンティティにより差がある。ある状況においては、ノード間の相互信頼は必要とされないこともある。この形態のダイナミックな異機種環境では、個別のエンティティがコンテクストに敏感な信頼動作を施行するために、一定の設備を提供する融通性のあるモデルが必要とされる。
【０３５５】
４．５  ポリシー管理されたアクセス
【０３５６】
実施様態の一例では(上記の通り)、サービス提供ノードは、要求ノードがリソースにアクセスすることを許可する前に信頼できる状況を確立する要求に加え、要求ノードが当該リソースに関連したポリシーを満たすことを要求することもある。実施様態の一例では、NEMOはこの機能性をサポートするために一定の、融通性がある機構を提供している。
【０３５７】
サービス詳細の一部として、利用者は特定のNEMOノードを「認証（authorization）」サービスプロバイダとして指定できる。実施様態の一例では、認証サービス提供ノードは、認定クエリー要請を処理し、対応するスタンダードサービスを実施する。サービスインタフェースにアクセスが許可される前に、対象サービスプロバイダは、サービスのために「認証」クエリー要求を任意の認証ノードに発し、一つ又はそれ以上のノード(又は事前に指定された組み合わせ)によりアクセスが許可されたという返答が得られた場合にのみアクセスが許される。
【０３５８】
図２０に示されるように、要求ノード2010は特定のサービスの当初の要求を含め、サービス提供ノード2020とメッセージ2015を交換する。サービス提供ノード2020は次に要求ノード2010が当該サービスを呼び起こすことを許可されているかを決定し、これらのノード2030への当初の認証要求を含む要請されたサービスへのアクセスを管理する認証ノード2025と認証メッセージ2025を交換する。返答に従って、サービス提供ノード2020は関連サービス返答を処理し返信するか、又はアクセスが拒否されたことを処理し返信する。
【０３５９】
このように、認証サービスによりNEMOノードはポリシー決定ポイント(PDP)の役割を分担できる。好ましい実施例においては、NEMOはポリシー管理システムに関して中立であり、認証ノードがどのように認証クエリーを基に認証決定を行うかを指示しない。しかし、相互運用のためには、認証要請と返答が同一の基準に従っており、また各種のポリシー管理システムの状況において多様の認証クエリー要請に対応するために、融通性があるペイロードを運べるように拡張が可能であることが好ましい。ある実施例においては、少なくとも以下の二つの認証フォーマットにサポートが提供されている。(1)入力、シンプルリクエスタID、リソースID、及び/又は、アクションIDなどの、きわめてまれな共通基準カテゴリを使用した非常に単純なエンベロープを提供する単純なフォーマット(2)認証クエリーを内包するための標準「セキュリティ・アサーション・マークアップ言語(SAML:Security Assertion Markup Language)」
【０３６０】
ある実施例においては、認証ノードは少なくとも所定の「シンプル」フォーマットを認知・サポートし、認証ノードのネイティブポリシー表現フォーマットに位置付けなくてはならない。その他のフォーマットについては、認証ノードは「認証」クエリー要請のパイロードを処理できないか又は理解できない場合は適切なエラー返答を返送する。拡張により、ノードが認証クエリーの受入れ可能のフォーマットをネゴシエートし、どのフォーマットが認証サービス提供ノードによってサポートされているかを決定するクエリーを行うことが可能となることがある。
【０３６１】
４．６  基本的DRMノードインタラクション
ここで特定のNEMOにおけるDRMアプリケーションに戻る。図２１は、DRMノード(又は頂点)グラフであり、DRMノード間のインタラクションとその関係を示している。携帯機器2110がコンテンツプレイバック機器(例えばiPod1)であるとする。Nip1はこの機器を象徴するノードである。Kip1はNip1に関連したコンテンツ暗号化鍵である。「ユーザ」は携帯機器の持ち主で、Ngはユーザを象徴するノードである。KgはNgに関連したコンテンツ暗号化鍵である。
【０３６２】
PubLibは公立図書館である。Nplは図書館の会員、そしてKplはNplに関連したコンテンツ暗号化鍵である。ACMEはACME製造の全てのミュージック・プレイヤーを象徴する。Nampは機器グループを象徴し、Kampはこのグループのコンテンツ暗号化鍵である。
【０３６３】
L1はNip1からNgへのリンクであり、これは携帯機器がユーザに属すること(そしてユーザの鍵にアクセスできること)を意味する。L2はNg からNplへのリンクであり、これはユーザが公立図書館の会員である(そして鍵へのアクセスがある)ことを意味する。L3はNip1からNampへのリンクであり、これは携帯機器がACME機器(会社が鍵を所持しないため、単なる会員)であることを意味する。L4はNplからNaplへのリンクであり、Naplは全ての公立図書館 (そしてグループ全体の鍵へのアクセスがあること) を象徴する。
【０３６４】
C1は公立図書館の会員が利用できる映画ファイルである。KclはC1を暗号化するために使用される鍵である。GB[C1](図から省略)はC1の管理情報(例えば、コンテンツへのアクセスを管理する規則やその関連情報)である。E(a、b)は「b」が鍵「a」により暗号化されていることを意味する。
【０３６５】
説明を目的として、ここでは機器は(a)機器が図書館の会員に属し、(b)機器がACMEにより製造されている限り、C1のコンテンツを再生できるという規則を確立することが希望されていると仮定する。
【０３６６】
コンテンツC1はKc1により暗号化されている。規制プログラム及び暗号化されたコンテンツ鍵RK[C1] = E(Kamp, E(Kpl, Kcl))が作成される。規制プログラムとRK[C1]は双方ともにコンテンツの管理ブロックGB[C1]に含めることができる。
【０３６７】
携帯機器はC1とGB[C1]を受信する。例えば両方とも同一のファイルに包含されていることもあれば、個別に受理されることもある。携帯機器はユーザが機器を購入し、最初にインストールしたときにL1を受理する。携帯機器はまたユーザが公立図書館に会員費を支払った時点でL2を受理する。さらに、携帯機器は製造された時点でL3を受け取っている(例えば、L3が内蔵されている)。
【０３６８】
携帯機器は、L1、L2、L3を通じてNp1がNg(L1)、Npl(L1+L2)、そしてNamp(L3)へのグラフパスがあることを確認できる。携帯機器はC1を再生することを欲する。携帯機器はGB[C1]で認知した規則を起動する。規則はNip1がACME機器(Nampへのパス)であり、公立図書館の会員(Nplへのパス)に属していることを確認する。こうして規則は「イエス」と注文されたリスト(Namp、Npl)を返信する。
【０３６９】
携帯機器はKgを計算するためにL1を使用し、そしてKgからKplを算出するためにL2を使用する。また、携帯機器もKampを算出するためにL3を使用する。携帯機器はKplとKampをRK[C1]に適用し、GB[C1]を認知し、Kc1を算出する。ここで解読にKc1が使用され、C1が再生される。
【０３７０】
ノード鍵が前述の例のように左右対称の鍵である場合、コンテンツパッケージャは、コンテンツを「バインド」することを希望するノードの鍵にアクセスする必要がある。これは、パッケージャを象徴するノードを作成し、そのノードと規則をバインドすることを希望するノードとの間にリンクを設けることにより達成される。また、サービスを通じて「バインド外で」同様の結果を達成することもできる。しかし、特定状況下ではこれは不可能であることもあり、対象鍵を使用することが実用的であることもある。この場合、知識を共有無しでバインドが必要とされるノードに一対の鍵を割り当てることが可能である。ここで、パッケージャはコンテンツ鍵をターゲットノードの公開鍵により暗号化することによりコンテンツ鍵をノードにバインドする。クライアントは当該ノードへのリンクを通じてノードの秘密鍵へアクセスすることにより、暗号解読のための鍵を取得できる。
【０３７１】
最も一般的な例では、規則に使用されるノードとコンテンツ暗号化鍵の算出に使用されるノードは同一である必要はない。コンテンツを管理する規則とそれを暗号化するために使用される鍵には密接な関係があるため、同一のノードを使用することは自然であるが、必ずしもその必要ない。特定のシステムでは、一部のノードは会員条件の表示に使用されないコンテンツ保護鍵に使用されることも、またその逆の場合もあり、そして特定の状況では二つの別々のノードのグラフ−一つは規則用でもう一つはコンテンツ保護用―が使用されることもある。例えば、規則は、全てのNplグループの会員はコンテンツC1へのアクセスがあるが、コンテンツ鍵Kc1は必ずしもKplにより保護されておらず、代わりにNplだけでなく全ての公立図書館を象徴するノードNaplのノード鍵Kaplにより保護されるとすることもある。又は、規則は、利用者はNampの会員である必要があるが、コンテンツ暗号化鍵はNplに限ってバインドされるとする場合もある。
【０３７２】
４．７．DRMの運用とバーチャル・マシーン(VM)
【０３７３】
上記の図２１に関する記述では、コンテンツ管理ポリシーの形成と実施を含め、DRMシステムがハイ(ノードとリンク)レベルで運用されている。図２２には、そのようなコンテンツ管理ポリシーの形成と実施を行うDRMエンジンのVMの典型的なコードモジュール2200が示されている。
【０３７４】
図２２に示される、コードモジュール2200の具体例の４つの主要素は以下の通りである。
【０３７５】
pkCM Atom：pkCM Atom2210はトップレベルのコードモジュールアトムであり、サブアトムのシーケンスを含む。
【０３７６】
pkDS Atom：pkDS Atom2220はデータセグメントにロードできるメモリイメージを含む。このペイロードのアトムはオクテット値の元シーケンスである。
【０３７７】
pkCS Atom：pkCS Atom2230はコードセグメントにロードできるメモリイメージを含む。このペイロードのアトムはオクテット値の元シーケンスである。
【０３７８】
pkEX Atom：pkEX Atom2240はエクスポートエントリーのリストを含む。各エクスポートエントリーは、8ビットサイズのコード化された名前、それに続く最後に0を加えた名前の漢字表記、それに続く名前が付けられたエントリーポイントのバイトオフセットを象徴する32ビットの整数値(これはpkCSAtomに格納された情報のスタートのオフセットである)。
【０３７９】
４．７．１．  モジュールローダ
ある実施例では、コントロールVMはコードモジュールのローディングに責任を負う。コードモジュールがロードされると、pkDSアトム2220にコード化されたメモリイメージは、データセグメントのメモリー住所にロードされる。この住所はVMローダによって選択され、DS疑似レジスタに格納される。pkCSアトム2230にコード化されたメモリイメージはコードセグメントのメモリ住所にロードされる。この住所はVMローダによって選択され、CS疑似レジスタに格納される。
【０３８０】
４．７．２．システムコール
ある実施例では、コントロールVMプログラムは、コードモジュールのコードセグメント外で実施された機能を呼び出すことができる。これは、整数スタックオペランドを取り入れ、システムコール番号を指定するOP_CALL指示の使用により行われる。システムコールにより、施行はVM固有の実施形態でVMにより指示される別のコードモジュール(例えば、ユーティリティ機能のライブラリー)の制御VMバイトコードルーチンか、又はVMのホスト環境のような外部のソフトウェアモジュールに委託されることもある。
【０３８１】
ある実施例では、いくつかのシステムコール番号が指定されている：
【０３８２】
SYS_NOP = 0：このコールは非オペレーションコールであり、単に返送を施行する(他の機能はない)。主にVMのテスト用に使用される。
【０３８３】
SYS_DEBUG_PRINT = 1：テキストをデバッグ出力にプリントする。このコールは単一のスタック引数を待ち、プリント用に空終結文字列を含むメモリ位置の住所を指定する。
【０３８４】
SYS_FIND_SYSCALL_BY_NAME = 2：VMが指名されたシステムコールを施行するかどうか決定する。その場合、システムコール番号はスタックに戻される。さもなければ、値１が返される。このコールは単一のスタック引数を待ち、要求された空終結システムコール名を含むメモリ位置の住所を指定する。
【０３８５】
４．７．３．システムコール番号割り当て
ある実施例では、制御VMはシステムコール番号の0から1023までを命令システムコール(全てのVMプロファイルにより施行されなければならないシステムコール)用に維持する。
【０３８６】
VMは、システムコール番号16384〜32767を同時割り当てすることができる(例えば、VMはSYS_FIND_SYSCALL_BY_NAMEにより返却されたシステムコール番号を同時割り当てすることができ、また全てのVM施行は同一の番号である必要はない)。
【０３８７】
４．７．４．標準システムコール
ある実施例では、制御プログラムの書き込みを促進するためにいくつかの標準システムコールが提供されている。そのような標準システムコールには、ホストからタイムスタンプを取得するコール、ノードが連絡可能かどうか決定するコール、そして/又はそれに類似したコールが含まれる。システムコールは同時決定された番号であることが好まれる(例えば、システムコール番号はSYS_FIND_SYSCALL_BY_NAMEシステムコールを呼び出し、名前を引数としてパスすることにより検索できる)
【０３８８】
4.8．DRMエンジンインタフェースとホストアプリケーションの間のインタフェース
以下は、DRM(クライアント消費)エンジンからホストアプリケーションに提供されたインタフェース形態の代表的な高水準記述の実例である。
【０３８９】
SystemName::CreateSession(hostContextObject) ・ Session
ホストアプリケーションコンテクストに与えられたセッションを作成する。コンテクストオブジェクトは、コールバックをアプリケーションに組み入れるためにDRMエンジンにより使用される。
【０３９０】
Session:: ProcessObject(drmObject)
この機能は、ホストアプリケーションがDRMシステムに属することが判明されたメディアファイルのオブジェクトの特定形態に遭遇したときにホストアプリケーションにより呼び出されるべきである。そのようなオブジェクトには、コンテンツコントロールプログラムや会員トークンなどが含まれる。これらのオブジェクトの構文解析や動作はホストアプリケーションには明らかでない。
【０３９１】
Session::OpenContent(counterReference)・ Content
ホストアプリケーションは、マルチメディアファイルと交信する必要があるときにこの機能を呼び出す。DRMエンジンは、コンテンツオブジェクトを返還し、コンテンツオブジェクトはその後そのコンテンツに関するDRM情報を検索し、またそのような情報と交信する必要がある場合に使用される。
【０３９２】
Content::GetDrmInfo()
コンテンツに関するDRMメタデータを返還する。これによりファイル用に通常のメタデータが利用できるようになる。
【０３９３】
Content::CreateAction(actionInfo) ・ Action
ホストアプリケーションは、コンテンツオブジェクトと交信する必要がある場合にこの機能を呼び出す。actionInfoパラメーターはアプリケーションがどのようなタイプのアクション(例えば再生)を施行する必要があるか、また必要な場合はその関連パラメーターも指示する。ファンクションはアクションオブジェクトを返還し、アクションオブジェクトはその後アクションを施行し、コンテント鍵を検索するために使用される。
【０３９４】
Action::GetKeyInfo()  暗号解読サブシステムがコンテンツの暗号解読に必要な情報を返還する。
【０３９５】
Action::Check()  DRMサブシステムがこのアクションの施行を許可するかどうかを検査する(例えばAction::Perform()が施行されるかどうか)。
【０３９６】
Action::Perform()  アクションを施行し、そのアクションを管理する規則により指定された帰結(及びその副作用)を遂行する。
【０３９７】
例示的Host ApplicationによりDRM（クライアント消費）エンジンに対して提供されるインタフェースの種類の高レベル記述の例を次に示す。
【０３９８】
HostContext::GetFileSystem(type)  FileSystem
DRMサブシステムが占有的アクセスを有する仮想FileSystemオブジェクトを返す。この仮想FileSystemは、DRM状態情報を保存するために使用される。このFileSystem中のデータはDRMサブシステムだけが読出し/書込み可能である。
【０３９９】
HostContext::GetCurrentTime()
ホスト・システムが維持する現在の日付/時刻を返す。
HostContext::GetIdentity() 
このホストの一意的IDを返す。
HostContext::ProcessObject(dataObject)
DRMオブジェクト中に埋込まれたかもしれないが、DRMサブシステムがホストにより管理されているもの（例えば証書）であると識別したデータ・オブジェクトをホスト・サービスに返す。
【０４００】
HostContext::VerifySignature(signatureInfo) 
データ・オブジェクトへのデジタル署名の有効性を検証する。好適には、signatureInfoオブジェクトはXMLSig要素に存在する情報と等価の情報を含むものである。Host Servicesは、署名の有効性を図るために必要な鍵及び鍵証書を管理する責任がある。
【０４０１】
HostContext::CreateCipher(cipherType, keyInfo)  Cipher 
データを暗号化したり復号するためにDRMサブシステムが使用できるCipherオブジェクトを作成する。好適には、最小限の暗号型のセットが定義され、各型には暗号実現に必要な鍵情報を記述するための形式が定義される。
【０４０２】
Cipher::Encrypt(data)
データの暗号化で使用される上記のCipherオブジェクト。
Cipher::Decrypt(data)
データの復号化で使用される上記のCipherオブジェクト
HostContext::CreateDigester(digesterType)  Digester 
あるデータ上でセキュアなハッシュを計算するためにDRMサブシステムが使用できるDigesterオブジェクトを作成する。ダイジェスト型の最小限のセットが定義される。
【０４０３】
Digester::Update(data)
セキュアなハッシュを計算するために使用される上記のDigesterオブジェクト。
【０４０４】
Digester::GetDigest()
DRMサブシステムが計算したセキュアなハッシュを取得するために使用される上記のDigesterオブジェクト。
【０４０５】
例示的DRM (サービス側パッケージング)エンジンによりHost Applicationに提供される種類のインタフェースの例示的高レベル記述を次に示す。
【０４０６】
SystemName::CreateSession(hostContextObject)  Session
Host Application Contextが与えられるとセッションを作成する。DRM Packagingエンジンはコンテキスト・オブジェクトを使用してそのアプリケーションに対してコールバックを行う。
【０４０７】
Session::CreateContent(contentReferences[]) Content
Host Applicationは、以降のステップでライセンス・オブジェクトに対応付けられるContentオブジェクトを作成するためにこの関数を呼ぶ。contentReferences配列中に複数のコンテンツ参照を持つことは、これらは１つのバンドル（例えば１つのオーディオと１つのビデオ・トラック）に束ねられており、発行されたライセンスは１つの分離不可能なグループとしてこれらにターゲットされなければならないことを示唆する。
【０４０８】
Content::SetDrmInfo(drmInfo)
drmInfoパラメータは、発行されるライセンスのメタデータを指定するものである。構造体は読み出され、ライセンスをVMのバイトコードに計算するためのガイドラインとして行為する。
【０４０９】
Content::GetDRMObjects(format)   drmObjects
DRM Packagingエンジンが作成したdrmObjectsをHost Applicationが取得する準備ができている時、この関数が呼ばれる。形式パラメータは、これらのオブジェクト（例えばXML又はバイナリ・アトム）に対して期待される形式を指定する。
【０４１０】
Content::GetKeys()   keys[]
この関数は、コンテンツを暗号化するためにHost Applicationが鍵を必要とする時、呼ばれる。１つの実施例では、コンテンツ参照ごとに１つの鍵が存在する。
【０４１１】
例示的Host ApplicationによりDRM (サービス側パッケージング)エンジンに対して提供される種類のインタフェースの例示的高レベル記述を次に示す。
【０４１２】
HostContext::GetFileSystem(type)  FileSystem 
DRMサブシステムが占有的アクセスを有する仮想FileSystemオブジェクトを返す。この仮想FileSystemは、DRM状態情報を保存するために使用される。このFileSystem中のデータはDRMサブシステムだけが読出し/書込み可能である。
【０４１３】
HostContext::GetCurrentTime()  Time
ホスト・システムが維持する現在の日付/時刻を返す。
【０４１４】
HostContext::GetIdentify()  ID
このホストの一意的IDを返す。
【０４１５】
HostContext::PerformSignature(signatureInfo, data)
DRM Packagingエンジンによって作成されたDRMオブジェクトのうちあるものは信用されなければならない。ホストにより提供されるこのサービスは、指定されたオブジェクトに署名するために使用される。
【０４１６】
HostContext::CreateCipher(cipherType, keyInfo)  Cipher
DRM Packagingエンジンがデータ暗号化及び復号化に使用できるCipher オブジェクトを作成する。これは、ContentKeyオブジェクト中のコンテンツ・鍵・データの暗号化に使用される。
【０４１７】
Cipher::Encrypt(data)
上記の、データ暗号化に使用されるCipher オブジェクト。
【０４１８】
Cipher::Decrypt(data)
上記の、データ復号化に使用されるCipher オブジェクト
【０４１９】
HostContext::CreateDigester(digesterType)  Digester 
あるデータ上でセキュアなハッシュを計算するためにDRM Packagingエンジンが使用できるDigesterオブジェクトを作成する。
【０４２０】
Digester::Update(data)
上記の、セキュアなハッシュを計算するために使用されるDigesterオブジェクト。
【０４２１】
Digester::GetDigest()
上記の、DRMサブシステムが計算したセキュアなハッシュを取得するために使用されるDigesterオブジェクト。
【０４２２】
HostContext::GenerateRandomNumber()
鍵生成に使用される乱数を生成する。
【０４２３】
５．  サービス
５．１  概要
アーキテクチャ的そして操作的視点の両方からNEMO/DRMシステムを説明したので、次に本システムの機能性を実現するために使用できるサービス、データ型、及び関連したオブジェクト（「プロファイル（profile）」）の例示的集まりに焦点を当てる。
【０４２４】
前述のように、NEMOアーキテクチャの好適な実施例では、サービス呼出しに付随する要求と応答のシンタックス、フレームワーク内で使用されるデータ型、メッセージ包絡、及びNEMOフレームワーク内で公開され使用されるデータ値の柔軟性に富み、移植性のある方法が使用される。WSDL 1.1以上では、様々な種類のサービスインタフェース及び呼び出しパターンを記述し、表現するために十分な柔軟性が提供されており、多様な通信プロトコルを介して様々な、異なるエンドポイントNodeへのバインディングを受入れるための十分な抽象性がある。
【０４２５】
１つの実施例では、プロフィルを主題的に関連したデータ型及びWSDLで定義されたインタフェースの集合と定義する。NEMOでは（基本的NEMO ノードインタラクションパターン及びインフラ機能性をサポートするために必要なデータ型とサービス・メッセージの機能的集合を含む）"Core" プロファイルは、（NEMOで実現可能なDigital Rights Managementサービスを表す）DRMプロファイルなどのアプリケーション特有のプロファイルから区別されている。その両者を次に述べる。
【０４２６】
これらのプロファイルで定義されるデータ型及びサービスのうち多くのものは抽象的で、使用の前に専化する必要があることを理解されたい。他のプロファイルはCoreプロファイルの上に構築される。
【０４２７】
５．２  NEMOプロファイルの階層
１つの実施例では、サービスインタフェース及び関連するデータ型の定義は、相互上に構築され、そして拡張可能な必須及び任意プロファイルの集合として構造化されている。あるプロファイルとプロファイル拡張との相違は比較的微妙である。一般的に、プロファイル拡張では新規データ型やサービス型の定義の追加は発生しない。これらは単に既存の抽象型及び具体型を拡張するものである。
【０４２８】
図２３にNEMO及びDRM機能性の例示プロファイル階層を示す。このプロファイル階層の主要素には次が含まれる：
【０４２９】
Core Profile - このプロファイル階層の基本には、Core Profile 2300が配置されているが、それは好適にはNEMO機能性とDRM機能性の双方を共有するものである。このプロファイルは、他の全てのプロファイルの土台を成す。それには、フレームワーク中でより多くの複合型を作成する基となる（下記に述べる）汎用型の基本集合も含まれる。Core Profile中の型の多くのものは抽象的で、使用の前に専化する必要がある。
【０４３０】
Core Profile Extensions - Core Profile 2300の直ぐ上には、Core Profile Extensions 2320があるが、それはCore Profile 2300中の型の一次専化であり、その結果具体的な表現が生じる。
【０４３１】
Core Services Profile - Core Profile 2300の直ぐ上にさらに存在するものはCore Services Profile 2310で後者は下記に述べる一般インフラ・サービスの集合を定義するものである。このプロファイルでは、サービス定義は抽象的で、使用の前に専化する必要がある。
【０４３２】
Core Services Profile Extensions - Core Profile Extensions 2320及びCore Services Profile 2310の両方の直ぐ上には、Core Services Profile Extensions 2330が構築されており、それはCore Services Profile 2310中で定義されているサービスの一次専化であり、その結果具体的な表現が生じる。
【０４３３】
DRM Profile - Core Profile 2300の直ぐ上にはDRM Profile 2340が存在し、後者は他のDRM関連のプロファイルの土台を成す。DRM Profile 2340は、より多くの複合DRM特定型を作成する基となる（下記に述べる）汎用型の基本集合も含まれる。DRM Profile 2340 中の型の多くのものは抽象的で、使用の前に専化する必要がある。
【０４３４】
DRM Profile Extensions - DRM Profile 2340上に構築されているものはDRM Profile Extensions 2350であり、それはDRM Profile 2340中で定義されている型の一次専化であり、その結果具体的な表現が生じる。
【０４３５】
DRM Services Profile - DRM Profile 2340の上にさらに構築されているものはDRM Services Profile 2360であり、それは、（下記に述べる）一般DRMサービスの集合を定義する。このプロファイルでは、サービス定義は抽象的で、使用の前に専化する必要がある。
【０４３６】
Specific DRM Profile - DRM Profile Extensions 2350及びDRM Services Profile 2360の両方の上に構築されているのはSpecific DRM Profile 2370であり、それはDRM Services Profile 2360に定義されているDRMサービスのさらなる専化である。このプロファイルもある種の新規の型を導入し、Core Profile Extensions 2320で指定されているある種の型を拡張するものである。
【０４３７】
５．３  NEMO サービス及びサービス仕様
このプロファイル階層内に、１つの実施例では、（上記で詳細が説明されている）次の主要なサービス・コンストラクトが存在する。
【０４３８】
Peer Discovery - システム中のピアに相互発見をせしめる能力。
【０４３９】
Service Discovery - 異なるピアにより提供されるサービスに関する情報を発見し、取得する能力。
【０４４０】
Authorization - 特定のピア（例えばノード）が特定の（例えばサービスのような）資源へのアクセスを認可されるかどうかを判定する能力。
【０４４１】
Notification -特定のピア（例えばノード）の集合への、指定された基準に基づく、対象メッセージのデリバリに関連するサービス。
【０４４２】
この例示プロファイル階層中の主要DRMコンストラクトの（上述の）定義のうちあるものを次に示す。
【０４４３】
Personalization -   特定のDRMシステムのコンテキストで有効な自己識別を設立するために必要なDRM関連のエンドポイント（例えば、CEデバイス、ミュージック・プレイヤー、DRMライセンス・サーバなど）のために必要な信用証明、ポリシー、及び他のオブジェクトを取得するサービス。
【０４４４】
Licensing Acquisition - 新規DRMライセンスを取得するサービス。
【０４４５】
Licensing Translation - １つの新規DRMライセンス形式を他の形式に取り替えるサービス。
【０４４６】
Membership - ある指定されたドメイン内でメンバーシップを設立する様々な型のオブジェクトを取得するサービス。
【０４４７】
NEMO/DRMプロファイル階層は、１つの実施例で、（サービス、通信パターン、及びオペレーションの抽象集合を表す）Generic Interface Specifications、（NEMOプロファイル中で定義されたデータ型を含む）Type Specifications、及び抽象サービスインタフェースを、特定のプロトコルへのバインディングを含む具体的サービスインタフェースに写像する） Concrete Specificationsの集合として記述できる。これらの仕様の１つの実施例は、サービス定義及びプロファイル・スキーマの形で本書の付記Cで規定されている。
【０４４８】
6.  他のアプリケーション・シナリオ
DRMで保護された歌を再生する新しいミュージック・プレイヤーを消費者が使用するというコンテキストで、NEMO操作の実施例の比較的簡単な例を図24に示す。しかし下記に示すように、このような簡単な例でも、多くの異なった、潜在的に関連するアプリケーション・シナリオが示される。この例では、発見サービスの連結、すなわちUDDIベースのディレクトリ・サービスを見つけ出し、それにリンクする機構としてユニバーサル・プラグ・アンド・プレイ(UPnP) ベースのサービス発見の使用、が示される。また、この例では、Personal Area Network (PAN)サービス及びWide Area Network (WAN)サービス間のサービスインタラクションサービス使用の信用されているコンテキストの交渉、及び新規デバイスとDRMサービスの提供の詳細が示されている。
【０４４９】
図２４では、新しいミュージック・プレイヤー2400を購入した消費者は、DRMで保護された歌を再生したいと考える。Player 2400はこのDRMシステムをサポートするものであるが、個人化する必要がある。すなわち、Player 2400はそれをNEMO有効でDRM対応にするある種の要素（図示せず）を含むものであるが、このシステムの一部となるためには最初に個人化プロセスを行う必要がある。
【０４５０】
典型的には、ひとつのNEMOクライアントは、他のノードのサービスを呼び出すService Access Point、それはある種の保護されたコンテンツを再生するための信用された資源であることを示すTrust Management Processing、そしてサービス呼び出し及びメッセージの作成と受理をサポートするWeb Servicesレイヤ、などの上記図5a及び6に示すある種の基本的要素を含んでいる。しかし下記に述べるように、ひとつのノードがNEMOシステムに参加できるようにするためにはこれらの要素の全てが必要なわけではない。
【０４５１】
ある実施例では、上記の図１２Ａ及び１３−１５に示すように、クライアント・ノードはある種の基本的、DRM関連の要素を含むことができる。例えば、保護された歌を復号したり、それらの歌を再生するための媒体レンダリング・エンジンも含めて、保護されたコンテンツの処理を有効化するDRMクライアント・エンジン及び暗号化サービス（そして関連するオブジェクト及び暗号化鍵）などである。ここでも、そのような要素のうちの一部は存在する必要はない。例えば、Player 2400 が非保護のコンテンツのみを再生できるミュージック・プレイヤーであった場合、それは他のミュージック・プレイヤーに含まれているコア暗号化要素は必要でないかもしれないのである。
【０４５２】
より具体的には、図２４に示す例では、Player 2400はワイヤーレスで、UPnPプロトコル及びBluetooth（登録商標）プロトコルをサポートし、署名を検証し、メッセージに署名するために使用する一組のX.509証書を有している。Player 2400は、限定された数のNEMOサービス・メッセージを形成し、処理できるという点ではNEMO対応であるが、資源制約上それはNEMO Service Access Pointを含んでいない。
【０４５３】
しかしPlayer 2400はユーザの家庭ではPersonal Area Network (PAN) 2410に参加できる。後者は、NEMO対応の、インターネットに接続されたBluetooth（登録商標）及びNEMO SAP 2430搭載のHome Gateway Device 2420を含む。Player 2400及びGateway 2420の双方のUPnPスタックは、下記に述べる「NEMO対応Gatewayサービス」用の新しいサービス・プロファイルをサポートするために拡張された。
【０４５４】
ユーザが１つの歌をダウンロードしてそれを再生しようとした場合、Player 2400はそれを個人化する必要があると判断して、そのプロセスを開始する。例えば、Player 2400はPAN 2410上のNEMOゲートウェイのためのUPnPサービス要求を開始する。それは1個のNEMOゲートウェイ・サービスを見つけだし、Gateway 2420はPlayer 2400がそのサービスに接続できるようにするために必要な情報を返す。
【０４５５】
次に、Player 2400はNEMO Personalization要求メッセージを形成し、それをゲートウェイ・サービスに送信する。その要求には、Player 2400のデバイス識別体に対応する１つのX.509証書が含まれている。その要求を受取ると、Gateway 2420は要求をローカル的に満たすことができないと判断するが、他の潜在的サービスプロバイダを発見する能力がある。しかし、Gateway 2420はそれが受取る全てのメッセージはデジタル的に署名されたものでなければならないというポリシーを持っており、従ってその要求を拒絶して、この種類の要求の処理に付随するポリシーを表明した認可失敗を返す。
【０４５６】
この拒絶を受取るとPlayer 2400はサービス拒絶の理由に留意し、デジタル的に署名して（例えば、図15に関連して前述のように）、要求をGateway 2420に再提出する。後者はメッセージを受け入れる。上記のように、Gateway 2420はこの要求をローカル的には満たせないが、サービス発見を行うことはできる。Gateway 2420は、そのSAP 2430実現がサポートする特定の発見プロトコルは知らないので、所望のサービスの種類（個人化）に基づいて一般的属性ベースのサービス発見要求を作成して、その要求をSAP 2430を介して送信する。
【０４５７】
インターネット・ベースのUDDI Registry 2440などのUDDIレジストリーと通信するのに必要な情報で構成されているSAP 2430は、その要求を適正な形式のネイティブUDDI照会に変換し、その照会を送信する。UDDI Registry 2440はDRM個人化をサポートしているサービスプロバイダを知っており、照会の結果を返す。SAP 2430はこれらの結果を受け取り、必要なサービスプロバイダ情報を含めて、正しい形式で適正な応答をGateway 2420に返す。
【０４５８】
Gateway 2420は、サービス発見応答からサービスプロバイダ情報を抽出し、初期の要求に基づいてPlayer 2400のためにPersonalizationの新規要求を作成する。この要求がSAP 2430に提出される。サービスプロバイダ情報（特にPersonalization Service 2450のサービスインタフェース記述）は、WSDLに記述されているウェブ・サービスを介してそのサービスを公開する個人化サービスとどのようにしてSAP 2430が通信すべきであるかを明らかにする。それらの案件に従って、SAP 2430はPersonalization Service 2450を呼び出し、応答を受け取る。
【０４５９】
次にGateway 2420は応答をPlayer 2400に返し、後者は応答のペイロードを使用してそのDRMエンジンを個人化できる。この時点で、Player 2400は供給され、様々なローカル及びグローバルの消費者指向サービスに完全に参加できる。これらは、様々なローカル及び遠隔コンテンツ・サービス、ルックアップ、突合せ、及びライセンス授与サービス、そして追加自動供給サービスへの完全なビジビリティー及びアクセスを提供でき、全ては消費者のサービスで協働する。上記で説明したように、コンテンツ・プロバイダーにより課せられるどのようなポリシーをも消費者とPlayer 2400が満たすことを前提として、ある種の保護されたコンテンツへのアクセスのために様々な復号化鍵が必要である。
【０４６０】
このようにして、家庭でパーソナル・メディア・プレイヤーを使用する消費者は、CEデバイスの単純性を享受できるが、ゲートウェイ及びピア・デバイスにより提供されるサービスも利用できる。消費者が別の施設に移動すると、デバイスは家庭で使用可能なサービスの大部分か全てのサービスを再発見して利用することができる。そして、新規ゲートウェイ・サービスを介して、ホーム・ネットワークに論理的に接続され、同時にそれらのサービスに付随する様々なポリシーに従って許容されている、利用可能なサービスを新しい施設で享受できる。また反対に、消費者のデバイスはその新しい施設で見つけられた各ピアにサービスを提供できる。
【０４６１】
明らかに、これらの同じコンストラクト（NEMO Node、SAP、Service Application Layer、XML、WSDL、SOAP、UDDIなどの様々の標準、など）のうち幾つかあるいは全てを使用して、このDRMミュージック・プレイヤーの例の範囲内でもその他の多くのシナリオが可能である。例えば、Player 2400 にそれ自体のSAPを含めて、Gateway 2420の必要性を解消させることもできるであろう。UDDI Registry 2440を、例えばミュージック・コンテンツを見つけたり及び/又はライセンス授与をしたりなどの他の目的に使用してもよい。更に、他の幾つものDRMアプリケーションも構築できる。例えば、様々な区分のユーザのために幾つもの種類のオーディオ及びビデオのための、複雑な使用及び配布ポリシーを課したライセンス授与ス鍵ムを利用するアプリケーションなどである。また、DRMコンテキスト以外にも、実質上他のいかなるサービス・ベースのアプリケーションもNEMOフレームワークを使用して構築できる。
【０４６２】
別の例として、ビジネス・ピア・ツー・ピア環境におけるNEMOのアプリケーションが考えられる。ビジネス・アプリケーション開発と統合化の手法は、多くのIT部門で行われている従来のツール及びソフトウェア開発ライフサイクルの限界を超えて速やかに進化している。これには、ワープロ文書、グラフィック・プレゼンテーション、表計算などの開発が含まれる。その最も単純な形体ではこれらの文書が真のアプリケーションであるかどうかは議論の余地があるが、これらの文書の幾つもの形体は正式に記述された、明確に定義された複雑なオブジェクト・モデルを有するという点を考慮に入れる必要がある。そのような文書や他のオブジェクトには、例えばオブジェクトのライフサイクル中、検査・更新できる状態情報、複数のユーザがそれらのオブジェクトを同時に操作できる能力、及び/又は他の機能などが含まれるかもしれない。より複雑なシナリオでは、文書ベースの情報をプログラム的に組み立てて本格的なアプリケーションとして挙動せしめることも可能である。
【０４６３】
従来のソフトウェア開発と全く同様に、これらの種類のオブジェクトのためにソース制御と責任の利用が有用である。現在において、文書管理を支援する多数のシステムが存在しており、多くのアプリケーションはある形態の文書管理を直接支援している。しかし、分散処理環境のコンテキストでは、これらのシステムのうちその大部分は限界がある。すなわち、明示的なチェックイン、チェックアウト・モデルを使用するバージョン管理の中央集中的アプローチ、及びクライアント・レンダリング・アプリケーションや特に特定のアプリケーション（例えば１つの文書）のコンテキスト内の形式に連結した柔軟性を欠く（非常に弱いか非常に剛直な）コヒーレンス・ポリシーなどの限界である。
【０４６４】
これらの限界は、能力発見及び形式交渉を強調するP2Pポリシー・アーキテクチャでもってNEMOの好適な各実施例を使用して対処できる。あるアプリケーション（例えば１つの文書）の作成をより豊かな方法で構造化することが可能であり、それにより複数の利点が生じる。各オブジェクト及びアプリケーションの構造に豊かなポリシーを適用できる。例えば、１つのポリシーで下記の項目の内いくつか、あるいは全てを指定できる。
【０４６５】
・    ある種のモジュールだけが変更可能。
・    オブジェクト・インタフェースだけが拡張可能、又は各インプリメンテーションが変更可能。
【０４６６】
・    削除のみが許されるが、拡張は許されない。
・    非矛盾性の更新の自動的合併などの機能性を含めて、更新が如何にして適用されるか、そして特定のピアの前の更新の適用はその更新を他のピアに送信できる。
【０４６７】
・    最適の機構を介して直接同期化に参加できるように、全てのピアが望むなら、全てのピアに通知されるようなポリシー・ベースのアプリケーション。
【０４６８】
・    それらの能力に基づき、異なった種類のクライアントからの更新をサポートする。
この機能性を達成するために、各参加者が使用するオーサリング・アプリケーションはNEMO対応のピアであってもよい。作成された文書に関しては、誰が認可されているか、そして文書の各部分に対して（その文書の通常の書式化規則の他に）何が行えるかを含めて、ポリシーを記述する雛形を使用できる。NEMOピアにより使用されるポリシー・エンジンがそれらのセマンティックスと一貫性のあるポリシー規則を解釈して施行できる限り、そしてその文書の作成で許容されたピア・インタフェースによりサポートされているオペレーションをService Adaptation Layerを介して特定のピアの環境に写像できる限り、任意のピアが参加できるが、それらのピアはその文書を内部的には異なった方法で表現できる。
【０４６９】
プレゼンテーション文書に関する協調のためのNEMOフレームワーク上に構築されたサービスを利用する異なったNEMOピアで構成されている１つのシステムの場合を考える。この例では、Java（登録商標）で記述されたアプリケーションをワイヤーレスPDAアプリケーションが実行しているとする。PDAアプリケーションはJava（登録商標）アプリケーションを使用してその文書を処理してそれをテキストに変換している。デスクトップ・ワークステーション上のMicrosoft Windows（登録商標）の元で実行されている別のインプリメンテーションが、Microsoft Word形式を使用して同一の文書を処理する。PDAとワークステーションは両方とも例えばローカル・エリア・ネットワーク上の接続を介してお互いに通信でき、したがってPDAのユーザとワークステーションのユーザは同一の文書アプリケーションに関して協調できる。この例では、
【０４７０】
・    この協調に関与する各NEMOピアは相互に発見でき、彼らの状態、及び性能を発見できる。
【０４７１】
・    各NEMOピアは各コミット可能な変更、その自己識別、変更、及びオペレーション（例えば削除、拡張など）を提出する。
【０４７２】
・    全ての変更は各NEMOピアに伝播される。これは、各NEMOピアは、別のピアのプロファイル及び性能を、それらが公示された場合、発見できるからである。この時点で、通知するピアは、通知対象のピアがそれをできない場合、通知対象のピアが受け入れることのできる形でコンテンツ変更符号化を持てる。別の方法では、受け入れるピアはそのインタフェースを受け取るとそれが適切であると考える任意の形式でそれらの変更を表現できる。
【０４７３】
・    ある変更を受け入れる前に、ピアはそれが認可されているNEMO参加者からのものであることを確認する。
【０４７４】
・    変更は文書ポリシーに基づいて適用される。
【０４７５】
もう１つの例として、NEMO対応ノード(X)であり、DRM形式Aをサポートするが、コンテンツをDRM形式Bで再生したい携帯ワイヤーレス・コンシューマ電子(CE)デバイスを考える。Xはコンテンツをレンダーする意図及びその特性（その自己識別が何であるか、どのOSをそれがサポートするか、その更新性プロファイル、それがサポートする支払方法、及び/又はその他）の内容を公表して、潜在的ソリューションを提供する他のNEMOピアからの応答を待つ。その照会に対して、Xは次の3件の応答を受け取る。
【０４７６】
（１）ピア1はクリアMP3形式で、$2.00の料金でコンテンツの低品質のダウンロード可能バーションを提供できる。
【０４７７】
（２）ピア2は再生1回あたり$0.50の料金で、セキュアなチャネルを介して高品質pay-per-playストリームを提供できる。
【０４７８】
（３）ピア3は$10.00の料金で、DRM形式Bのコンテンツのレンダリングを可能とするソフトウェア更新をXに提供できる。
【０４７９】
提示されたものをレビューした後、Xは第１オプションが最適の選択であると判断し、第１提示を介して要求を提出する。その要求には、別のNEMOサービスを介してXの支払い口座から$2.00をPeer 1が差し引いてもよいという委譲の断定を含む。Xに対して課金されると、Peer 1からの応答でXは１つのトークンを受け、そのトークンでMP3ファイルをダウンロードできる。
【０４８０】
そうではなく、オプション3が最適のソリューションであるとXが判断すると、比較的より複雑なビジネス取引が発生するかもしれない。例えば、オプション3は、NEMO対応の参加している各ピアに含まれるNEMO Workflow Collator (WFC)要素で実現されているNEMO Orchestration Descriptor (NOD)を使用して記述されるトランスアクション・ビジネス・プロセスで表現する必要があるかもしれない。必要なソフトウェア更新をXに対して遂行するために、NEMOフレームワークを使用して次のアクションが実行される。
【０４８１】
・Xは、それが更新を受け取ることが許されているという認可をそのワイヤーレス・サービスプロバイダ(B)から取得する。
【０４８２】
・ワイヤーレス・サービスプロバイダ(B)は、その自己識別を確立するためにピア3の信用証明を直接検証する。
【０４８３】
・Xは、それが第三者更新をインストールすることを許容する必須の更新をBからダウンロードする。これに対してポリシー制約は無いが、このシナリオはこのアクションを発生させる最初の惹起イベントである。
【０４８４】
・Xはピア3が提供する更新に関して課金される。
・Xはピア3から更新をダウンロードする。
【０４８５】
このビジネス・プロセスでは、ある種のアクションはWFC要素により同時に実行可能であるが、他のアクティビティは特定の順序で認可され、実行されなければならない。
【０４８６】
[0508] NEMOフレームワークのもう１つの潜在的アプリケーションは、オンライン・ゲームのコンテキストで発生する。多くの人気のある複数プレイヤー・ゲーム環境ネットワークは、オンライン・ゲーム者がゲーム・セッションを作成し、それに参加ですることを許容する中央集中的、閉鎖的ポータルとして構造化されている。
【０４８７】
そのような環境の限界の１つは、一般的にユーザはゲーム・ネットワークと緊密な関係を持つ必要があり、そのサービスを利用するために１つのアカウント（通常は特定のゲーム・タイトルに付随するアカウント）を持つ必要があるということである。典型的なゲーム者は、通常複数のタイトルを対象として、そして複数のゲーム・ネットワークに関して幾つかのゲーム・アカウントを管理する必要があり、複数プレイヤー・ゲームを立ち上げてそのネットワーク内で参加するためにゲーム・プロバイダー特定のクライアント・アプリケーションとのインタラクションを行う必要がある。これはしばしば不便であり、その結果オンライン利用に対して消極的になる。
【０４８８】
NEMOフレームワークの各実施例を使用してより連邦的な、分散処理的なゲーム経験を作りだすことによりオンライン・ゲームをさらに楽しむことができる。それにより、特定のオンライン・ゲーム・ネットワークの詳細がユーザとサービスプロバイダにとって透明になる。これはより良いユーザ経験を提供してこれらのサービスの採用と利用を促進させるだけでなく、ゲーム・ネットワーク・プロバイダーの管理負担が軽減できるのである。
【０４８９】
これらの利点を達成するために、ゲーム・クライアントをNEMOモジュールで個人化して、それらのクライアントがNEMOピアとして参加できるようにする。更に、ゲーム・ネットワークをNEMOモジュールで個人化して、それらのネットワークがそれらの管理インタフェースを標準的な方法で公開できるようにする。最後に、NEMO信用管理を使用して、認可されたピアだけが意図された方法でインタラクションすることを確実にする。
【０４９０】
例えば、A、B、Cという３つのゲーム・ネットワーク・プロバイダー及びXとYという2人のユーザがいるとする。ユーザXはAで口座を持ち、ユーザYはBで口座を持っているとする。XとYの両者はCで作動する新しいタイトルを取得して、お互い同士でプレイしたいと思う。NEMOフレームワークを使用して、Xのゲーム・ピアはオンライン・ゲーム・プロバイダーCを自動的に発見できる。AがCは正当なゲーム・ネットワークであると確認した後、Xの口座情報をAからCに送信できる。この時点で、XはCに登録され、Cとのインタラクションを行うために正しいトークンが供給される。ユーザYも同じ手続きを経て、そのBからの信用証明を使用してCへのアクセスを取得する。XとYの両者が登録された後、彼らはお互いを発見して、オンライン・ゲーム・セッションを作成できる。
【０４９１】
この簡単な登録の例を拡張して、ゲーム・トークン保存（例えばロッカー）、口座支払い、及び成績ボード履歴などの共有の状態情報なども含めて、オンライン・ゲーム環境が提供する他のサービスにも対応できる。
【０４９２】
エンタープライズ文書管理、オンライン・ゲーム、及び媒体コンテンツ消費のコンテキストで幾つかの例を紹介したが、本書記載のNEMOフレームワーク及びDRMシステムは任意の適切なコンテキストで使用できるものであり、これらの具体的な例に限定されないものであることを理解されたい。
【０４９３】
明確性のために上記はいくらか詳細にわたって説明されたが、添付の特許請求の範囲内におけるある種の変更と修正を行えることは明らかである。本発明のプロセス及び装置の両方を実現するための多くの代替方法が存在することに注意されたい。従って、これらの実施例は例示的なもので、限定的なものではないと考えられるべきであり、この発明的作品は本書記載の詳細に限定されるものではなく、添付の特許請求範囲及び等価の範囲内で変更可能である。
【０４９４】
以下に示す付記Ａ内の図１〜１５は、それぞれ、表３〜１７として示す。
【０４９５】
＜付記Ａ＞
ピアツーピアサービス編成のシステムおよび方法
＜０００１＞
本付記は、２００３年６月５日付で出願されたＷｉｌｌｉａｍ  ＢｒａｄｌｅｙおよびＤａｖｉｄ  Ｍａｈｅｒによる標題「ピアツーピアサービス編成のシステムおよび方法」の米国仮特許出願番号６０／４７６，３５７に対応する。本明細書と共に提出されるＰＣＴ出願全体における「Ｂｒａｄｌｅｙ他の出願」に対する参照は、この付記Ａにおける情報に関する。
＜０００２＞
著作権許可
本特許文書の開示内容の一部が、著作権保護の対象となる資料を含む。著作権所有者は、ＷＩＰＯまたは米国特許商標庁の特許ファイルまたは記録に示されているように、いかなる者にもよる特許文書の複写複製または特許公開も認めるが、それ以外は、どのようなものであれ、すべての著作権の権利を留保する。
＜０００３＞
発明の分野
本発明は、一般的に、ディジタル情報およびディジタルサービスの配布および使用に関する。さらに明確に述べると、ピアツーピアサービス編成を提供および／またはサポートするシステムおよび方法が開示される。
＜０００４＞
発明の背景と要約
今日では、メディア関連サービスの相互運用可能で安全な世界という目標に対して、大きな障害が存在する。例えば、複数の重複し合う事実上の標準と正規の標準とが直接的な相互運用性を阻害する。必要とされるサービスを発見して、それに接続することが困難である場合が多く、インプリメンテーション技術が相互運用不可能であることが多く、および、互いに異なる信用および保護モデル（ｔｒｕｓｔ  ａｎｄ  ｐｒｏｔｅｃｔｉｏｎ  ｍｏｄｅｌ）の間にインピーダンスの不一致が存在することが多い。
＜０００５＞
新興のウェブサービス規格がウェブ上でのこれらの問題の幾つかに対処し始めてはいるが、こうしたアプローチは不完全である。これに加えて、こうしたアプローチは、パーソナルエリアネットワーク、ローカルエリアネットワーク、家庭ゲートウェイ、企業ゲートウェイ、部門ゲートウェイ、および、ワイドエリアネットワークに及ぶ複数のネットワークノード階層全体にわたってこれらの問題に対処することはできない。さらに、こうしたアプローチは、多くのレガシーアプリケーションの統合を可能にするローカルとリモートとをバインドする様々なサービスインタフェース（例えば、ＷＳ−Ｉ、Ｊａｖａ（登録商標）  ＲＭＩ、ＤＣＯＭ、Ｃ関数呼出し、．Ｎｅｔ等）を使用して、単純なサービスと複雑なサービスの両方の動的な編成を可能にしない。
＜０００６＞
本発明の実施態様は、これらの問題の一部分または全部を解決するために、すなわち、これらの問題の一部分または全部に対処するために、使用されることが可能である。例えば、特定の実施態様では、サービスプロバイダが、特定の雑多なサービスネットワークに関与するデバイス、サービス、または、アプリケーションに関して最も適切であるサービス発見プロトコルを使用することが可能である。例えば、ＢｌｕｅＴｏｏｔｈ（登録商標）、ＵｐＮｐ、ｒｅｎｄｅｚｖｏｕｓ、ＪＩＮＩ、ＵＤＤＩ等が同一のサービスに中に統合され、および、各ノードが、そのノードをホストするデバイスに関して最も適切な１つまたは複数の発見サービスを使用することが可能である。
＜０００７＞
メディアの世界において、利害関係者（例えば、コンテント発行者、ディストリビュータ、リテールサービス、コンシューマデバイスプロバイダ、および、コンシューマ）の主要なグループによって必要とされ好まれているシステムとインタフェースとが、多くの場には様々に異なる。したがって、これらのエンティティにより提供される機能を、関与するエンティティすべての要求を満たす最適な構造へと即時に進化できる統合サービスの形に一体化することが望ましいだろう。本発明の実施態様は、ピアツーピア（「Ｐ２Ｐ」）サービス編成を使用することによって、この目標を達成するために使用されることが可能である。
＜０００８＞
Ｐ２Ｐフレームワークの有利性が、音楽配信と現在ではビデオ配信とのような事柄に関してすでに見受けられるが、Ｐ２Ｐ技術はさらに広範囲に使用できる。例えば、様々な企業サービスにおいて、特に２つ以上の企業間でのインタラクションにおいて、利用可能性が存在している。企業はほとんどの場合に階層的に組織され、および、その情報システムがその組織を反映しているが、２つの企業内の人々がインタラクトする時に、これらの人々はピア型のインタフェースを介してより効果的にインタラクトするだろう。Ａ社の受注担当者／サービスは、Ｂ社の出荷担当者と対話することによってより直接的に問題を解決したり有益な情報を得ることが可能である。横断階層や不要なインタフェースが実用的でないことが多い。（ＦｅｄＥｘやＵＰＳのような）輸送会社はこれに気付き、そのプロセスにおいて直接的な可視性を可能にし、および、イベントがカスタマによって直接監視されることを可能にする。企業と地方自治体はそのサービスを企業ポータルを通して編成しており、それによってセルフサービスの原型を可能とする。しかし、現在までのところ、ピアツーピアフレームワークは、１つの企業が、その企業のカスタマとサプライヤというエンティティが自然なピアリングレベル（ｐｅｅｒｉｎｇ  ｌｅｖｅｌ）でインタラクトすることを可能にして、これらのエンティティがこれらのエンティティに最適な形で企業のサービスをオーケストレートすることを可能にするように、そのカスタマとサプライヤに対して様々なサービスインタフェースを露出させることは可能にはしない。
＜０００９＞
ネットワークされた計算環境内でサービス編成を提供するためのシステムおよび方法が開示される。この開示された実施態様が、プロセス、機器、システム、デバイス、方法、または、コンピュータ可読媒体を含む、様々な形で実現されることが可能であるということが理解されるべきである。次では幾つかの本発明の実施態様を説明する。
＜００１０＞
１組の実施態様では、カスタマまたは企業のメディアスペース（例えば、コンシューマ、コンテントプロバイダ、デバイス製造業者、サービスプロバイダ、企業部門）内の様々な利害関係者が互いを発見し、信用できる関係を確立し、および、信用できるサービスインタフェースによってリッチかつ動的な形で価値交換することを可能にする、サービスフレームワークが提供される。このサービスフレームワークは、雑多なカスタマデバイス、メディアフォーマット、通信プロトコル、および、機密保護メカニズムの世界において、相互運用可能でかつセキュリティ保護されたメディア関連ｅｃｏｍｍｅｒｃｅを可能にするためのプラットフォームと言い表されることが可能である。
＜００１１＞
本発明のこれらの特徴と利点と実施態様とその他の特徴と利点と実施態様とが、以下の詳細な説明と添付図面とによってさらに詳細に示されるだろう。
＜００１２＞
図面の簡単な説明
＜００１３＞
本発明の実施形態が、同じ照合数字が同じ構造要素を示す次の添付図面と組み合わせて、以下の詳細な説明を参照することによって、容易に理解されるだろう。
＜００１４＞
図１は、ＭｅｄｉａＤｒｉｖｅフレームワークの実施形態を示す。
＜００１５＞
図２は、ＭｅｄｉａＤｒｉｖｅノードの概念図である。
＜００１６＞
図３は、ＭｅｄｉａＤｒｉｖｅノード相互間の一般的なインタラクションパターンを示す。
＜００１７＞
図４は、サービス適合層（Ｓｅｒｖｉｃｅ  Ａｄａｐｔａｔｉｏｎ  Ｌａｙｅｒ）の実施形態を示す。
＜００１８＞
図５ａは、クライアント側のＭＳＤＬインタラクションに関与しているサービスプロキシを示す。
＜００１９＞
図５ｂは、クライアント側のネイティブなインタラクションに関与しているサービスプロキシを示す。
＜００２０＞
図６は、サービス側のポイントツーインターメディアリインタラクションパターン（ｐｏｉｎｔ−ｔｏ−ｉｎｔｅｒｍｅｄｉａｒｙ  ｉｎｔｅｒａｃｔｉｏｎ  ｐａｔｔｅｒｎ）に関与しているサービスプロキシを示す。
＜００２１＞
図７は、ＭｅｄｉａＤｒｉｖｅワークフローコレータのインタラクションパターンを示す。
＜００２２＞
図８は、通知ハンドラサービスをサポートするノードを発見する１組の通知処理ノードを示す。
＜００２３＞
図９は、好ましい実施形態による通知の配信を示す。
＜００２４＞
図１０は、ターゲットであるサービス提供ノードに対して要求ノードがサービスクエリー要求を行うクライアント駆動のシナリオを示す。
＜００２５＞
図１１は、要求ノードが別のノードと共にその記述を登録することを望むノード登録シナリオを示す。
＜００２６＞
図１２は、サービスの存在を通知されているＭｅｄｉａＤｒｉｖｅ対応ノードを示す。
＜００２７＞
図１３は、明示的な交換に基づいて信用を確立するプロセスを示す。
＜００２８＞
図１４は、サービスに対するポリシー管理されたアクセスを示す。
＜００２９＞
図１５は、異なった利害関係者に対するＣＲＭ関連サービスの配信に関連してＭｅｄｉａＤｒｉｖｅがどのように使用されることが可能であるかを示す。
＜００３０＞
詳細な説明
本発明主体の詳細な説明が以下に示されている。この説明は幾つかの実施形態に関連した形で示されているが、本発明がどの１つの実施形態にも限定されず、その代わりに、多くの代替案と変型と等価物とを含むということを理解されたい。例えば、幾つかの実施形態がコンシューマ志向のコンテントおよびアプリケーションに関連付けて説明されているが、当業者は、開示されているシステムおよび方法がより広範囲のアプリケーションに容易に適合可能であるということを理解するだろう。例えば、非限定的に、本発明の実施形態は、企業のコンテントおよびアプリケーションに関連付けて容易に適用されることが可能である。さらには、本発明の完全な理解を実現するために以下の説明において数多くの具体的な詳細事項が記述されているが、本発明はこれらの詳細事項の一部または全部なしに実施されてよい。さらに、理解しやすいように、本発明に関連した技術において既知である特定の技術的題材は、本発明を不必要に不明瞭にすることを避けるために、詳細には説明していない。
＜００３１＞
新規性のある、ポリシー管理されたピアツーピア型のサービス編成フレームワーク（ＭｅｄｉａＤｒｉｖｅフレームワーク）の実施形態を、本明細書で説明する。このフレームワークは、当初においては、リッチなメディア体験を実現可能にするグラスルーツ型（ｇｒａｓｓ−ｒｏｏｔ）の自己組織型サービスネットワークの形成をサポートするために設計された。当業者は、このフレームワーク自体と、その特徴と側面と用途の多くとに新規性があるということを理解するだろう。
＜００３２＞
好ましい実施形態では、このフレームワークは、サービス記述言語（ｔｈｅ  ＭｅｄｉａＤｒｉｖｅ  Ｓｅｒｖｉｃｅｓ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ（「ＭＳＤＬ」））を使用して多数の異なったタイプのサービスの動的な構成と進化とを可能にするように設計されている。サービスは、このフレームワークのために特に設計されているメッセージポンプおよびワークフローコレータを使用して各々がメッセージルーティングおよび編成を実現する、ピアツーピア型通信ノードの全体にわたって分散させられることが可能である。ＭｅｄｉａＤｒｉｖｅサービスインタフェースの分散ポリシー管理は、信用と機密保護を実現して商業的な価値交換を容易にすることを促進するために、使用されることが可能である。
＜００３３＞
ピアツーピア型計算が、コンピュータおよび他のインテリジェントデバイスの中で（ハードドライブおよび処理サイクルのような）リソースの共用として定義されることが多い。ｈｔｔｐ：／／ｗｗｗ．ｉｎｔｅｌ．ｃｏｍ／ｃｕｒｅ／ｐｅｅｒ．ｈｔｍを参照されたい。本明細書では、Ｐ２Ｐは、ネットワークノードがあらゆる種類のサービスを対称的に消費および提供することを可能にする通信モデルと見なされるだろう。Ｐ２Ｐメッセージングおよびワークフローコレーションは、リッチなサービスが、より原始的なサービスの雑多なセットから動的に生成されることを可能にする。このことが、共有リソースが様々な異なったタイプのサービスである時に、異なったサービスバインディングを使用してさえ、Ｐ２Ｐコンピューティングの可能性の検査を可能にする。ＭｅｄｉａＤｒｉｖｅの実施形態が、リッチで動的な形でインタラクションし価値交換し協働するために、利害関係者（コンシューマ、コンテントプロバイダ、デバイス製造業者、および、サービスプロバイダ）が互いを発見することを可能にするメディアサービスフレームワークを提供するために使用されることが可能である。ＭｅｄｉａＤｒｉｖｅの実施形態が、基本サービス（発見、通知、探索、および、ファイル共有）から、より複雑でより高レベルのサービス（例えば、ロッカー（ｌｏｃｋｅｒ）、ライセンス供与、マッチング、認可、支払いトランザクション、および、更新）とこれらのどれかまたは全部の組合せに及ぶ範囲を協調させるために使用されることが可能である。
＜００３４＞
ＭｅｄｉａＤｒｉｖｅの企業アプリケーションが、企業がサービス志向アーキテクチャに移行する時に特に魅力的である。ピアツーピア型サービス編成と分散ポリシー管理との使用によって、企業は、カスタマとサプライヤとによるリッチで個人化されたサービスの形に構成されることが可能なサービスインタフェースをその企業の部門が発表することを可能にすることができ、その結果として、人工的なヒエラル鍵を分解し、および、内部エンティティと外部エンティティの両方がその企業とのインタラクションを最適化することを可能にする。
＜００３５＞
説明を容易にするために、次の術語が使用されるだろう。
＜００３６＞
サービス  −  特定のプロバイダによって提供されるあらゆる明確に定義された機能性。これは、例えば、セル電話のようなデバイス内で提供される低レベルの機能性（例えば音声認識サービス）、または、ワールドワイドウェブを介して提供される多面的な機能性（例えば、商品購入サービス）であることが可能である。
＜００３７＞
サービスインタフェース  −  １つまたは複数のサービスとインタラクトするあらゆる明確に定義された方法。
＜００３８＞
サービスバインディング  −  サービスインタフェースを呼び出すために使用される取り決め（ｃｏｎｖｅｎｔｉｏｎ）およびプロトコル。これらは、ＷＳ−Ｉ規格ＸＭＬプロトコル、ＷＳＤＬ定義に基づいたＲＰＣ、または、ＤＬＬからの機能呼出しのような様々な明確に定義された形で表現されてよい。
＜００３９＞
サービス編成  −  サービスプロバイダによって指定されたルールに準拠する、管理可能でありかつ粗粒度が高いサービス、再使用可能なコンポーネント、または、完全アプリケーション（ｆｕｌｌ  ａｐｐｌｉｃａｔｉｏｎ）への、サービスのアセンブリおよび協調。この例は、プロバイダの自己識別、サービスのタイプ、サービスがアクセスされる方法、サービスが構成される順序等に基づいたルールを含む。
＜００４０＞
統治  −  音楽ファイル、文書、または、ソフトウェアアップグレードをダウンロードおよびインストールする機能のようなサービスオペレーションといった特定のアイテムに対して、命令的または支配的な影響を与えるプロセス。統治は、典型的には、信用管理とポリシー管理とコンテント保護とインタラクトする。
＜００４１＞
ピアツーピア型（Ｐ２Ｐ）フィロソフィ  −  パティシパント（ｐａｒｔｉｃｉｐａｎｔ）のためのサービスに対する対称アクセスをサポートする通信モデル。
＜００４２＞
ＭｅｄｉａＤｒｉｖｅノード  −  ＭｅｄｉａＤｒｉｖｅフレームワーク内のパティシパント。好ましい実施形態では、ノードが、サービスコンシューマおよび／またはサービスプロバイダの役割を含む複数の役割を果たすだろう。ノードは、コンシューマ電子デバイス、メディアプレイヤのようなソフトウェアエージェント、または、コンテント検索エンジンやＤＲＭライセンスプロバイダやコンテントロッカ（ｃｏｎｔｅｎｔ  ｌｏｃｋｅｒ）のような仮想サービスプロバイダを含む、様々な形態でインプリメントされてよい。ＭｅｄｉａＤｒｉｖｅサービスは、より堅固な複合サービスを提供するためにオーケストレートされてもよい。
＜００４３＞
ＭｅｄｉａＤｒｉｖｅサービス記述言語（ＭＳＤＬ）  −  一実施形態では、ＭｅｄｉａＤｒｉｖｅフレームワークの実施形態におけるノードの相互間の通信のために使用されるデータタイプとメッセージとの拡張可能セットを定義および記述する、ＸＭＬスキーマに基づいた言語。
＜００４４＞
７．論理モデル
図１が、ＭｅｄｉａＤｒｉｖｅフレームワークの比較的単純な事例を示す。好ましい実施形態では、ＭｅｄｉａＤｒｉｖｅフレームワークは、ＰＳＰ型にインタラクトする論理的に接続されたノードのセットから成る。
＜００４５＞
好ましい実施形態では、このインタラクションの幾つかの特徴は次の通りである。
・ＭｅｄｉａＤｒｉｖｅノードが、サービス呼出し要求を行うことと応答を受け取ることとによってインタラクトする。この要求および応答メッセージのフォーマットとペイロード（ｐａｙｌｏａｄ）はＭＳＤＬに定義されている。このＭｅｄｉａＤｒｉｖｅフレームワークは、単一のサービスプロバイダとの直接的なインタラクションから、複数のサービスプロバイダからの振り付けられた（ｃｈｏｒｅｏｇｒａｐｈｅｄ）サービスのセットの複雑な集約までを範囲とする、様々な通信パターンの構築をサポートする。好ましい実施形態では、このフレームワークは、既存のサービスコレオグラフィ（ｓｅｒｖｉｃｅ  ｃｈｏｒｅｏｇｒａｐｈｙ）規格を使用するための基本メカニズムをサポートし、および、サービスプロバイダがそれ自体の取り決めを使用することを可能にする。
・サービスインタフェースは１つまたは複数のサービスバインディングを有してよい。好ましい実施形態では、サービスバインディングの記述がＭＳＤＬで表現される。この実施形態では、ＭｅｄｉａＤｒｉｖｅノードは、そのノードのインタフェースバインディングがＭＳＤＬで表現されることが可能である限り、かつ、要求ノードがそのバインディングに関連付けられている取り決めとプロトコルとをサポートすることが可能である限り、別のノードのインタフェースを呼び出してよい。例えば、ノードがウェブサービスインタフェースをサポートする場合には、要求ノードが、ＳＯＡＰ、ＨＴＴＰ、ＷＳ−Ｓｅｃｕｒｉｔｙ等をサポートするように要求されてよい。
・任意のサービスインタフェースが、権利管理の側面を直接的に提供する標準化された仕方で制御（例えば、権利管理）されてよい。ＭｅｄｉａＤｒｉｖｅノードの相互間のインタラクションは、統治された動作と見なされることが可能である。
＜００４６＞
実質的にあらゆるタイプのデバイス（物理的デバイスまたは仮想デバイス）が、潜在的にＭｅｄｉａＤｒｉｖｅ対応化されていると見なされることが可能であり、かつ、ＭｅｄｉａＤｒｉｖｅフレームワークの主要側面をインプリメントすることが可能である。デバイスのタイプは、例えば、コンシューマ電子装置、ネットワーク化サービス、または、ソフトウェアクライアントを含む。好ましい実施形態では、ＭｅｄｉａＤｒｉｖｅ対応デバイス（ノード）は、典型的には、次の論理モジュールの一部または全部を含む。
・ネイティブサービスＡＰＩ  −  デバイスがインプリメントする１つまたは複数のサービスのセット。ＭｅｄｉａＤｒｉｖｅノードがあらゆるサービスをＭｅｄｉａＤｒｉｖｅフレームワーク内で直接的または間接的に露出させるという要件は存在しない。
・ネイティブサービスインプリメンテーション  −  ネイティブサービスＡＰＩのためのインプリメンテーションの対応するセット。
・ＭｅｄｉａＤｒｉｖｅサービス適合層（ＭｅｄｉａＤｒｉｖｅ  Ｓｅｒｖｉｃｅ  Ａｄａｐｔａｔｉｏｎ  Ｌａｙｅｒ）  −  ＭＳＤＬで記述された１つまたは複数の発見可能なバインディングを使用することによってエンティティのネイティブなサービスの露出させられたサブセットがその層を通してアクセスされる論理層。
・ＭｅｄｉａＤｒｉｖｅフレームワークサポートライブラリ（ＭｅｄｉａＤｒｉｖｅ  Ｆｒａｍｅｗｏｒｋ  Ｓｕｐｐｏｒｔ  Ｌｉｂｒａｒｙ）  −  サービスインタフェース、メッセージ処理、サービス編成等を呼び出すためのサポートを含む、ＭｅｄｉａＤｒｉｖｅフレームワークと共に機能するためのサポート機能性を提供するコンポーネント。
＜００４７＞
図２は、ＭｅｄｉａＤｒｉｖｅノードの例示的な実施形態の概念図を示す。上述のモジュールの各々に対応するこの実際の設計とインプリメンテーションは、典型的には、デバイス毎に異なるだろう。
＜００４８＞
８．基本的なインタラクションパターン
図３は、２つのＭｅｄｉａＤｒｉｖｅノード、すなわち、サービスリクエスタとサービスプロバイダとの間の典型的な論理インタラクションパターンを示す。
＜００４９＞
要求ノードの観点から見ると、イベントフローが、典型的には、
・指定されたサービスバインディングを使用して必要なサービスを提供することが可能なあらゆるＭｅｄｉａＤｒｉｖｅ対応ノードを発見するために、サービス発見要求を行う。ノードは、発見されたサービスに関する情報をキャッシュすることを選択してもよい。ＭｅｄｉａＤｒｉｖｅノード間におけるサービス発見のためのインタフェース／メカニズムは、ＭｅｄｉａＤｒｉｖｅノードがインプリメントすることを選択する単なる別のサービスであることが可能である。
・候補となるサービス提供ノードが発見されると、その要求ノードは、特定のサービスバインディングに基づいてそのサービス提供ノードの１つまたは複数に要求を送り出すことを選択してよい。
・好ましい実施形態では、互いにセキュアに通信することを望む２つのノードが、ＭＳＤＬメッセージを交換するために信用関係を確立するだろう。例えば、これらのノードは、自己識別の判定、認可、セキュアなチャンネルの確立等において使用されてよい互換性のある信用証明書（例えば、Ｘ．５００信用証明書、デバイス鍵等）のセットをネゴシエートしてもよい。特定の場合には、これらの信用証明書のネゴシエーションは、サービスインタフェースバインディングの暗黙の属性であってよい（例えば、ＷＳ−Ｉ  ＸＭＬプロトコルが使用される場合にはＷＳ−Ｓｅｃｕｒｉｔｙ、または、２つの既知のノードの間のＳＳＬ要求）。特定の場合には、信用証明書のネゴシエーションは、明示的に別々の段階であってよい。好ましい実施形態では、どの信用証明書が別のＭｅｄｉａＤｒｉｖｅノードとインタラクトするのに十分であるかを判定することと、それが特定のノードを信用することが可能であるという判断を行うことは、特定のノード次第である。
・要求ノードは、要求されたサービスに対応する１つまたは複数の適切なＭＳＤＬ要求メッセージを生成する。
・このメッセージが生成されると、このメッセージは、ターゲットである１つまたは複数のサービス提供ノードに送られる。この要求の通信スタイルは、サービスバインディングに基づいて、例えば、同期的または非同期的なＲＰＣ型であるか、または、メッセージ志向であってよい。サービス要求の送信と応答の受信は、直接的にデバイスによって、または、ＭｅｄｉａＤｒｉｖｅサービスプロキシを通して行われてよい。（後述する）このサービスプロキシは、ＭｅｄｉａＤｒｉｖｅフレームワーク内の他のパティシパントにメッセージを送るためのアブストラクションとインタフェースとを提供し、および、互換メッセージフォーマット、トランスポートメカニズム、メッセージルーティング問題等のような特定のサービスバインディング問題を隠蔽してよい。
・要求を送り出した後に、要求ノードは、典型的には、１つまたは複数の応答を受け取るだろう。サービスインタフェースバインディングと要求ノードの選好との詳細に基づいて、１つまたは複数の要求が、例えばＲＰＣ型の応答または通知メッセージを含む様々な仕方で戻されてよい。これらの応答は、１つまた複数のターゲットノードへの途上で、例えば、ルーティング、信用翻訳（ｔｒｕｓｔ  ｔｒａｎｓｌａｔｉｏｎ）、照合（ｃｏｌｌａｔｉｏｎ）、および、相関関数等を含む、幾つかのＭｅｄｉａＤｒｉｖｅサービスを提供してよい他の中間ノードを通過してもよい。
・要求ノードは、応答がその要求ノードとサービス提供ノードとの間のネゴシエートされた信用セマンティクスに準拠することを確実なものにするために、１つまたは複数の応答を検証する。
・その次に、適切な処理が、メッセージペイロードのタイプとコンテントとに基づいて適用される。
＜００５０＞
サービス提供ノードの観点から再び図３を参照すると、イベントフローが次の通りである。
・要求されたサービスがサポートされかるどうかを判定する。好ましい実施形態では、ＭｅｄｉａＤｒｉｖｅフレームワークは、サービスに対するエントリポイントとしてサービスインタフェースがどのようにマップするかに関するスタイルまたは粒度（ｇｒａｎｕｌａｒｉｔｙ）を規定しない。最も単純な場合では、サービスインタフェースは、特定のサービスに対して明確にマップしてよく、および、そのサービスに対するバインディングと呼出しの行為が、そのサービスのためのサポートを構成してよい。しかし、特定の実施形態では、単一のサービスインタフェースが複数のタイプの要求を取り扱ってよく、および、特定のサービスタイプが、具体的に必要とされる機能性をノードがサポートするという判定が行われることが可能である前に調査される必要がある追加の属性を含んでもよい。
・特定の場合には、サービスプロバイダが、そのサービスプロバイダが要求ノードを信用するかどうかを判断することと、互換性のある信用証明書のセットをネゴシエートすることとが必要だろう。好ましい実施形態では、サービスプロバイダが信用を判定するかどうかに係わらず、サービスインタフェースに関連したあらゆるポリシーが該当するだろう。
・サービスプロバイダは、要求ノードがアクセス権を有するかどうかを判定するために、サービスインタフェースに対するアクセスを認可する役割を有する１つまたは複数のＭｅｄｉａＤｒｉｖｅノードに対して１つまたは複数の認可要求を判定して送出する。多くの状況においては、認可するノードとサービス提供ノードとが同一のエンティティだろうし、認可要求の送出と処理は、Ｃ機能エントリポイントのような軽量ＭｅｄｉａＤｒｉｖｅサービスインタフェースバインディングを経由して呼び出されるローカルなオペレーションだろう。
・認可応答を受け取ると、要求ノードが認可される場合には、サービスプロバイダが要求を満たすだろう。そうでない場合には、適切な応答メッセージが生成されることが可能である。
・応答メッセージが、サービスインタフェースバインディングと要求ノードの選好とに基づいて戻される。要求ノードへの途上で、このメッセージは、必要なサービスすなわち「付加価値」サービスを提供してよい他の中間ノードを通過してもよい。例えば、中間ノードが、ルーティング、信用翻訳、または、その要求ノードにとって許容可能な仕方でメッセージを配信することが可能な通知処理ノードへの配送を可能にしてもよい。「付加価値」サービスの一例が、そのサービスが要求ノードの関心（ｉｎｔｅｒｅｓｔ）に関して知っている場合に、そのメッセージにクーポンを添付するクーポンサービスである。
＜００５１＞
９．ＭＳＤＬ
サービス呼出しに関連したメッセージの構文が、ＭｅｄｉａＤｒｉｖｅフレームワーク内で使用されるコアデータタイプのような比較的フレキシブルでポータブルな形で記述されることが好ましい。好ましい実施形態では、これは、本明細書ではＭｅｄｉａＤｒｉｖｅサービス記述言語すなわちＭＳＤＬと呼ばれることになるサービス記述言語を使用して実現される。さらに、ＭＳＤＬは、記述されたサービスに関連している意味記述を参照するための単純な方法を提供する。
＜００５２＞
好ましい実施形態では、ＭＳＤＬは、サービスとこれに関連したインタフェースバインディングとの記述と複合とを可能にする拡張可能なデータタイプセットを具体化するＸＭＬスキーマに基づいた記述言語である。ＭＳＤＬにおけるオブジェクトタイプの多くがポリモルフィックであり、および、新たな機能性をサポートするために拡張されることが可能である。好ましい実施形態では、基本ＭＳＤＬプロファイルが、ＭｅｄｉａＤｒｉｖｅインタラクションパターンとインフラストラクチャ上の機能性とをサポートするためのデータタイプとメッセージとの最小セットを定義する。この基本プロファイルは「ＭＳＤＬ  Ｃｏｒｅ」と呼ばれるだろう。ＭＳＤＬユーザは、アドホックに直接的に、または、何らかの形態の標準化プロセスによって、新たなデータタイプおよびサービスタイプを追加すると共に既存のデータタイプおよびサービスタイプを拡張する、ＭＳＤＬ  Ｃｏｒｅ上に構築された他のＭＳＤＬプロファイルを定義する。一実施形態では、ＭＳＤＬ  Ｃｏｒｅは、次の主要な基本データタイプの一部または全部に関する定義を含む。
・ノード  −  ＭｅｄｉａＤｒｉｖｅフレームワークのパティシパントの表現。
・デバイス  −  仮想デバイスまたは物理デバイスの表現をカプセル化する。
・ユーザ  −  クライアントユーザの表現をカプセル化する。
・コンテント参照（ｃｏｎｔｅｎｔ  ｒｅｆｅｒｅｎｃｅ）  −  コンテントアイテムに対する参照すなわちポインタの表現をカプセル化する。この参照は、典型的には、コンテントフォーマット、ロケーション等を記述する他の標準化された方法をレバレッジ（ｌｅｖｅｒａｇｅ）するだろう。
・ＤＲＭ参照  −  ディジタル権利管理フォーマットの記述に対する参照すなわちポインタの表現をカプセル化する。
・サービス  −  ノードからエクスポートされた明確に定義された機能性のセットの表現をカプセル化する。
・サービスバインディング  −  サービスと通信する特定の方法をカプセル化する。
・要求  −  ターゲットであるノードのセットに対するサービスの要求をカプセル化する。
・要求入力  −  要求のための入力をカプセル化する。
・応答  −  要求に関連している応答をカプセル化する。
・要求結果  −  特定の要求に関連している応答の中の結果をカプセル化する。
＜００５３＞
一実施形態では、ＭＳＤＬ  Ｃｏｒｅは、次の基本サービスの一部または全部に関する定義を含む。
・認可  −  特定のパティシパントがサービスにアクセスすることを認可するための要求または応答。
・メッセージルーティング  −  サービス提供ノードにメッセージを転送させるか、または、メッセージを収集およびコレートさせる機能を含む、メッセージルーティング機能性を提供するための要求または応答。
・ノード登録  −  ノードのための登録オペレーションを行い、これによって中間ノードを経由してそのノードが発見されることを可能にする要求または応答。
・ノード発見（クエリー）  −  ＭｅｄｉａＤｒｉｖｅノードの発見に関係している要求または応答。
・通知  −  ターゲットである通知メッセージを特定のノードセットに送信または配信するための要求または応答。
・サービス発見（クエリー）  −  １つまたは複数のノードの特定のセットによって提供されるサービスの発見に関係している要求または応答。
・セキュリティ証明書交換  −  鍵対や信用証明書等のようなセキュリティ関連情報をノードが交換することを可能にすることに関係している要求または応答。
・アップグレード  −  機能性のアップグレードを受け取ることに関係している要求または応答を表現する。一実施形態では、このサービスは純粋に抽象的であり、他のプロファイルが具体的な表現を提供する。
＜００５４＞
１０．アーキテクチャの概観
１０．１．サービス適合層
再び図２を参照すると、サービス適合層が、ＭｅｄｉａＤｒｉｖｅフレームワーク内のパティシパントの１つまたは複数のネイティブなサービスを露出させるために使用されることが可能である。好ましい実施形態では、ＭＳＤＬは、１つまたは複数のインタフェース上でのサービスに明確にバインドする仕方を記述するために使用される。サービス記述が、さらに、次のものの一部または全部を含む他の情報を含んでもよい。
・サービスに対するアクセスを認可する役割を果たす１つまたは複数のサービスプロバイダのリスト。
・サービスの目的と使用の意味記述に対するポインタ。
・サービスが、他のサービスのセットの振り付けられた実行の結果として生じた複合サービスである場合には、必要な編成の記述。
＜００５５＞
サービスがＭＳＤＬで公表される論理点（ｌｏｇｉｃａｌ  ｐｏｉｎｔ）としての役割に加えて、好ましい実施形態では、サービス適合層は、さらに、特定のパティシパントによってサポートされるそれらのプラットフォームのための任意のＭＳＤＬプロファイル内に含まれているＭＳＤＬデータタイプおよびオブジェクトの具体的な表現をカプセル化する。このサービス適合層は、さらに、適切なネイティブサービスインプリメンテーションに対して、サービス要求に対応するＭＳＤＬメッセージをマッピングするためのロジックを含む。
＜００５６＞
典型的には、サービス適合層のインプリメンテーションは、図４に示されている要素を含む。具体的には、典型的なサービス適合層インプリメンテーションは、階層的設計において次の要素を含むだろう。
・サービスインタフェースのＭＳＤＬバインディングにおいて説明したようにサービスインタフェースエントリポイントをカプセル化する層。これらのアクセスポイントを経由して、サービス呼出しが行われ、入力パラメータデータが送り込まれ、および、結果が出て行く。
・ＭＳＤＬメッセージ処理のためのロジックに対応する層。これは、典型的に、その処理を駆動する特定の種類のメッセージポンプと、特定のタイプのＸＭＬデータバインディングサポートと、低レベルのＸＭＬパーサとデータ表現サポートとを含む。
・対応する／ＭＳＤＬで記述されたサービスがその上にマッピングされる使用可能なネイティブサービスを表す層。
＜００５７＞
１０．２  フレームワークサポートライブラリ
再び図２を参照すると、フレームワークサポートライブラリが、エンティティがＭｅｄｉａＤｒｉｖｅフレームワークに関与するのを可能にすることをより簡単にする採用随意のサポート機能の集まりを提供する。このサポートライブラリがどのようにファクタ（ｆａｃｔｏｒ）されるか（オブジェクトの集まり、機能の集まり等）ということと、それがどのようにインプリメントされるかということは、ターゲットであるプラットフォームに応じて様々だろう。異なった機能性をサポートするこのサポートライブラリの複数のバージョンが存在してよい。一般的な場合には、このサポートライブラリ中の使用可能な機能性が次のものの一部または全部を含む。
・サービスプロキシ  −  ＭｅｄｉａＤｒｉｖｅノードがサービス呼出し要求をターゲットであるサービス提供ノードセットのセットに対して行って応答セットを受け取ることを可能にする機能性をカプセル化する。
・ＭＳＤＬメッセージ操作ルーチン  −  ＭＳＤＬメッセージ部品を操作するための機能性。
・サービスキャッシュインタフェース  −  発見されたノードとこの発見されたノードがサポートするサービスとの間のマッピングをノードが管理することを可能にする一般的なサービスプロバイダインタフェース。
・ワークフローコレータインタフェース  −  ＭＳＤＬメッセージの集まりをノードが管理および処理することを可能にするサービスプロバイダインタフェース。これは、サービスをオーケストレートするための基本的なビルディングブロックを提供する。現時点では、このインタフェースは、メッセージルーティングをサポートしかつメッセージの中間的な待ち行列管理と照合とをサポートするノードによって、インプリメントされることが最も多い。
・通知プロセッサインタフェース  −  通知処理をサポートするＭｅｄｉａＤｒｉｖｅノードを特定の明確に定義された通知処理エンジンにフック（ｈｏｏｋ）するためのサービスプロバイダインタフェース。
・その他のサポート機能性  −  メッセージＩＤとタイムスタンプ等を生成するためのルーチン。
＜００５８＞
１０．３  通信スタイル
ＭｅｄｉａＤｒｉｖｅフレームワークの好ましい実施形態でサポートされており、かつ、サービスプロキシのような異なったサポートライブラリコンポーネントで使用される、一般的な通信スタイルの基本的な概観を示すことが有益である。次のような通信パターンの少数の基本タイプがある。
＜００５９＞
非同期ＲＰＣ配信スタイル  −  要求の実現が長時間の時間期間を要しかつクライアントが待機することを望まないという予想がある時に、このモデルが適切である。この場合には、クライアントは、１つまたは複数の特定のサービス提供ノードによって要求が非同期的に処理されるだろうということを予想して要求を送る。サービス提供エンドポイントが、そのサービス提供エンドポイントがこのモデルをサポートしないという表示によって応答することがあり、または、サービス提供ノードがこのモデルをサポートしない場合には、そのサービス提供ノードは、それがクライアントの要求に対する応答を有するかどうかを判定するために後続の要求においてサービス提供ノードに送られることが可能なチケットを搬送する応答を戻すだろう。好ましい実施形態では、このモデルをサポートするサービス提供エンドポイントは、特定の内部ポリシーに基づいた保留中の要求に対する応答をキャッシュするだろう。クライアントがこうした要求に関連しているチケットを回収することを試みており、かつ、応答が利用不可能であるか、または、応答がサービス提供ノードによって破棄されている場合には、適切な誤り応答が戻されることが可能である。
＜００６０＞
同期ＲＰＣ配信スタイル  −  この場合には、クライアントは要求を送り、その次に、戻される１つまたは複数の応答を待機する。サービス提供ＭｅｄｉａＤｒｉｖｅ対応エンドポイントが、それがこのモデルをサポートしないという表示を伴って応答してよい。
＜００６１＞
メッセージベースの配信スタイル  −  この場合には、クライアントが、その通知ハンドリングサービスインタフェースの１つまたは複数に関連付けられているメッセージ通知によって、あらゆる応答を受け取ることをそのクライアントが望むということを表示する要求を送る。ノードが応答して、そのノードがこのモデルをサポートしないということを表示する。通知フレームワークの典型的な実施形態を次で説明する。
＜００６２＞
上述のインタラクションパターンはどれも、応答の阻止と待機、または、明示的なポーリングを必要としない。上述の配信スタイルメカニズムによってブロッキングセマンティクス（ｂｌｏｃｋｉｎｇ  ｓｅｍａｎｔｉｃｓ）および非ブロッキングセマンティクスをモデル化するために、スレッディング（ｔｈｒｅａｄｉｎｇ）または他のプラットフォーム固有のメカニズムを使用することが可能である。
＜００６３＞
１０．４  サービスプロキシ
ＭｅｄｉａＤｒｉｖｅ対応エンドポイントは、様々な発見プロトコルと、名称プロトコルと、分解プロトコルと、搬送プロトコルとを使用してよい。この結果として、典型的には、フレキシブルで拡張可能な通信ＡＰＩを使用することが望ましいだろう。サービスプロキシＡＰＩは、ＭｅｄｉａＤｒｉｖｅノードがサービス要求を行い、かつ、ターゲットであるＭｅｄｉａＤｒｉｖｅノードのセットのための応答を受け取ることを可能にするための機能性に対する一般的なインタフェースを提供する。サービスプロキシは、（共用ライブラリの形で）クライアントの境界の内側で、または、（異なったプロセスで実行するエージェントの形で）クライアントの境界の外側で、様々な形態でインプリメントされてよい。サービスプロキシのインプリメンテーションの正確な形態は、プラットフォームまたはクライアントの必要に適合させられることが好ましい。一般的にサービスプロキシは大きな有用性を提供するが、サービスプロキシの使用は随意である。サービスプロキシの一般的な使用の幾つかが次のものを含む。
・サービス呼出しのための一般的な再利用可能なＡＰＩ。
・搬送チャンネルのネゴシエーションと使用とを取り巻く問題のカプセル化。幾つかの搬送チャンネルはＴＣＰ／ＩＰを経由したＳＳＬセッションのセットアップを要求し、幾つかのチャンネルはＵＤＰ／ＩＰを経由した不信頼通信だけをサポートすることがあり、および、他のチャンネルは全くＩＰベースではないことがある。好ましい実施形態では、クライアントは、一般的に、これらの詳細から遮断される。
・メッセージルーティングのためのＭｅｄｉａＤｒｉｖｅノードの初期セットの発見を取り巻く問題のカプセル化。例えば、ケーブルセットトップボックスが、ネットワークに対する専用の接続を有し、かつ、すべてのメッセージが特定のルートとインターメディアリとを経由して流れることを命令してもよく、一方、ホームネットワーク内のポータブルメディアプレイヤが、直接的にアクセス可能な複数のエンドポイントを発見するためにＵＰｎＰ発見を使用してもよい。この場合も同様に、クライアントがこれらの詳細から遮断されることが好ましい。
・「レガシー」クライアントが、ＭＳＤＬメッセージの生成によって他のＭｅｄｉａＤｒｉｖｅノードと直接的に会話することが不可能であるか、または、会話することを選択しないことがある。この場合には、クライアントがサポートするあらゆるネイティブプロトコルを理解するサービスプロキシのバージョンが生成されてよい。
＜００６４＞
サービスプロキシは、プロトコルバインディングの固定されたセットをサポートするだけの静的コンポーネントとしてインプリメントされてよく、または、新たなバインディングを動的にサポートすることが可能であるようにインプリメントされてもよい。一般的なサービスプロキシモデルの２つの例は次の通りである。（１）サービスプロキシがＭＳＤＬメッセージを直接受け取ってクライアントに戻し、（２）サービスプロキシが、クライアントによって理解される幾つかのネイティブなプロトコルをサポートする。サービスプロキシは、２つの側面、すなわち、要求パティシパントが使用するクライアント側面と、他のＭｅｄｉａＤｒｉｖｅ対応エンドポイントとインタラクトするサービス側面とを有するものと見なされることが可能である。
＜００６５＞
クライアントとサービスプロキシとの間の２つの主要なインタラクションパターンは次の通りである。
＜００６６＞
パターン１（図５ａ）。クライアントがＭＳＤＬ要求メッセージを直接形成し、および、そのメッセージをサービスプロキシに送る。サービスプロキシは、それが典型的には収集と解析と処理とを行うことを必要とする、ＭＳＤＬフォーマットの形の１つまたは複数の応答を受け取る。クライアントは、さらに、要求の配信をターゲットにすることに使用するために、サービスバインディングの１つまたは複数の明示的なセットを送ってもよい。これらのサービスバインディングは、サービス発見オペレーションを行うクライアントによって、または、以前の要求応答から得られた情報を使用することによって、すでに得られていてもよい。
＜００６７＞
パターン２（図５ｂ）。サービスプロキシは、そのサービスプロキシが受け入れる特定のネイティブな通信プロトコルによってクライアントがインタラクトしてよいクライアント側のモデルに適応し、ＭｅｄｉａＤｒｉｖｅフレームワーク内にクライアントが関与することを可能にするためにＭＳＤＬに／ＭＳＤＬから翻訳する。この場合には、ネイティブなプロトコル、または、ネイティブなプロトコルと実行環境との組合せが、サービスプロキシが適切なＭＳＤＬ要求を生成するための、および、サービスプロキシが必要に応じて適切なターゲットのサービスバインディングを決定するための必要な情報を提供する。
＜００６８＞
サービス側では、サービスプロキシとサービス提供ＭｅｄｉａＤｒｉｖｅ対応エンドポイントとの間の複数のタイプのインタラクションパターンがサポートされ、および、クライアント側と同様に、要求の種類、基礎となる通信ネットワーク、アプリケーションの種類、および／または、ターゲットである任意のサービスバインディングに関連している搬送プロトコルを含む様々な判定基準に基づいて、そのインタラクションパターンが適合させられることが可能であり、および、変化してよい。
＜００６９＞
１つのパターンでは、サービスプロキシは、複数の潜在的なサービスプロバイダとの通信を直接的に開始し、および、応答を受け取る。このタイプのインタラクションパターンは、サービスプロキシによる使用のためにクライアントから中継されている複数のサービスバインディングに準拠してよく、または、メッセージの中継においてサービスプロキシが使用するブロードキャストネットワークまたはマルチキャストネットワークが存在することを示してもよい。サービスプロキシは、応答を収集および照合することを選択してもよく、または、最初の受け入れ可能な応答を戻すだけでもよい。
＜００７０＞
図６に示されているモデルでは、サービスプロキシは、ターゲットであるサービス提供エンドポイントと直接的には通信せず、その代わりに、要求を中継する中間ノードを介して要求を送り、あらゆる応答を受け取り、および、サービスプロキシに応答を送り返す。このインタラクションパターンは次の理由によるだろう。
・サービスプロキシは、サービス提供エンドポイントに関連しているあらゆるサービスバインディングを直接サポートすることが不可能である／そうすることを望まないが、ゲートウェイとして働くことを望む中間ノードとの関係を確立することが可能である。
・クライアントが、任意の適切なサービス提供ノードに関するサービスバインディングを発見するか他の形で決定することが不可能であることがあり、および、任意の適切なサービスプロバイダを発見することを中間ノードが試みることを可能にすることを望んでいる。
・サービスプロキシが、より堅固な収集をサポートする中間ノードを利用することを望み、および、サービスプロキシとサービスプロバイダとの間のよりフレキシブルな通信パターンを可能にする機能性を照合する。
＜００７１＞
あるいは、または、上述の基本的なサービス側インタラクションパターンに加えて、上述のパターンまたは新たなパターンの組合せをインプリメントするサービスプロキシのインプリメンテーションを有することが可能である。
＜００７２＞
１０．５  ワークフローコレータ
好ましい実施形態では、ほとんどの非自明なＭｅｄｉａＤｒｉｖｅサービス要求の履行が、要求のイベントフローを管理することと、過渡的な結果と中間結果とを含むあらゆる関連データを管理することと、履行に関連したルール（もしあれば）が守られることを確実なものにすることとが可能な特定のタイプの協調メカニズムを必要とすることが多い。この機能性は、リレーショナルデータベース内の単純なトランザクションモニタからＭｉｃｒｏｓｏｆｔ  ＭＴＳ／ＣＯＭ＋に見られるようなより一般化されたエージェントに及ぶ範囲内のトランザクションコーディネータの形態で実現されることが可能である。好ましい実施形態では、ワークフローコレータが、ＭｅｄｉａＤｒｉｖｅノードがサービス呼出しの処理と履行とをオーケストレートするのを可能にするプログラム可能なメカニズムである。
＜００７３＞
好ましい実施形態では、ワークフローコレータは、特定のＭｅｄｉａＤｒｉｖｅエンドポイントの特性と要件とに適合させられることが可能であり、および、従来のメッセージ待ち行列管理からより高度な分散トランザクション協調に及ぶ様々な機能性をサポートするように設計される。単純なワークフローコレータは、任意のＭＳＤＬメッセージの格納と探索とのためのインタフェースを提供する。この上に構築することによって、次のものを含む様々な機能性をサポートすることが可能である。
・より効果的な処理のためのサービス要求の収集。
・複合応答の形へのサービス応答の単純な集約。
・複合サービスを生成するための、複数のサービス要求とサービス応答との手動編成。
・複合サービスを生成するための、複数のサービス要求とサービス応答との自動編成。
＜００７４＞
図７は別の潜在的なインタラクションパターンを示す。このインタラクションパターンは、ＭｅｄｉａＤｒｉｖｅノードに到着してそのノードのサービス適合層を経由して受け入れられるサービス要求で開始する。メッセージが、要求を履行しおよび応答を返すためにワークフローコレータを最初に駆動しおよびワークフローコレータによって駆動されるＭＳＤＬメッセージポンプに渡される。このパターンは幾つかのサービス処理パターンのための基礎である。一般的な単純な事例では、サービス要求の履行は、処理が等冪であり、かつ、その要求を処理するためのルールがＭＳＤＬの形でその要求の一部として完全に表現されている、単純な要求／応答インタラクションパターンの形で表現されることが可能である。しかし、サービス要求の履行は、特定の時間期間全体にわたって非同期的に処理された、到着する複数のＭＳＤＬに依存するだろう。この場合には、この処理は、ワークフローコレータによって監視される潜在的に長寿命であるトランザクションの一部分である。
＜００７５＞
さらに複雑なシナリオでは、特定のサービス要求の履行が、協調した形での複数のノードの関与を必要とする。その要求を処理するためのルールが、ＢＰＥＬのような他のサービス編成記述規格からのメッセージを随意にラップ（ｗｒａｐ）することが可能なＭＳＤＬの形で表現されてよい。要求の履行において、ノードのワークフローコレータがローカルインタフェースの特定のセットを通して機能性に依存してよく、または、他のＭｅｄｉａＤｒｉｖｅノードとインタラクトしてよい。
＜００７６＞
ＭＳＤＬ要求メッセージがワークフローコレータに与えられる時には、この要求メッセージは、何の適正なルールがその要求を処理するためであるかを判定する。ワークフローコレータのインプリメンテーションに応じて、サービス記述ロジックが、ノードが露出させるサービスのセットのための固定状態マシンの形態で表現されてよく、または、ＢＰＥＬ４ＷＳを使用して記述できるサービス処理ロジックのようなサービス処理ロジックのより自由な形態の表現の処理をサポートする形で表現されてよい。ワークフローコレータのアーキテクチャがモジュール型かつ拡張可能であり、プラグインをサポートすることが好ましい。好ましい実施形態では、ＭＳＤＬ自体が、複数のＭｅｄｉａＤｒｉｖｅサービスを複合サービスにオーケストレートするためのルールを表現する単純な方法をサポートする。
＜００７７＞
サービス統合と処理ルールとを翻訳することに加えて、好ましい実施形態では、ワークフローコレータは、サービス履行処理ライフサイクルの開始に関連してＭＳＤＬメッセージが使用されるべきかどうか、または、ＭＳＤＬメッセージが進行中のトランザクションの連鎖の中でさらに別に入力されるかどうかを決定することを必要とするだろう。ＭＳＤＬメッセージは、これらのタイプの決定を行うために使用されることが可能なＩＤとメタデータとを含む。さらに、サービストランザクションに固有であってよい追加の情報を含み、および、メッセージの処理を容易化するように、ＭＳＤＬメッセージを拡張することも可能である。
＜００７８＞
１０．６  通知サービス
非同期および同期ＲＰＣ型の通信パターンの両方に加えて、クライアントが特に要求を開始し、その次に応答を待機するか、または、チケットの回収によって応答を周期的に調べる場合には、ＭｅｄｉａＤｒｉｖｅフレームワークの好ましい実施形態は、さらに、通知の概念に基づいた純粋なメッセージングタイプの通信パターンもサポートする。次の要素が、好ましい実施形態の通知フレームワークで使用されるコアＭＳＤＬデータおよびメッセージタイプを構成する。
・通知  −  関係のあるＭｅｄｉａＤｒｉｖｅ対応エンドポイント（ノード）をターゲットにされた、指定されたタイプのペイロードを含むメッセージ。
・通知インタレスト（ｎｏｔｉｆｉｃａｔｉｏｎ  ｉｎｔｅｒｅｓｔ）  −  特定のノードが特定の通知を受け入れるかどうかを判定するために使用される判定基準。通知インタレストは、特定のタイプの自己識別（例えば、ノードＩＤ、ユーザＩＤ等）、イベント（例えば、ノード発見、サービス発見等）、アフィニティグループ（ａｆｆｉｎｉｔｙ  ｇｒｏｕｐ）（例えば、ニュージャズクラブコンテント（ｎｅｗ  ｊａｚｚ  ｃｌｕｂ  ｃｏｎｔｅｎｔ））、または、一般的なカテゴリ（例えば、広告）に基づいたインタレストを含んでもよい。
・通知ペイロード  −  分類された通知のコンテント。ペイロードタイプは、単純なテキストメッセージからより複雑なオブジェクトまでを範囲としてよい。
・通知ハンドラサービスインタフェース  −  通知がそのインタフェース上で受け取られてよいサービスプロバイダインタフェースのタイプ。サービスプロバイダは、さらに、そのインタフェースに関連した通知インタレストとアクセス可能なペイロードタイプとを記述する。このインタフェースをサポートするノードが通知のための最終宛先または中間処理エンドポイントであってよい。
・通知プロセッササービス  −  通知を関係ノードにマッチングさせて、特定のポリシーに基づいて通知を配信することが可能なノード。
・通知発信元（ｎｏｔｉｆｉｃａｔｉｏｎ  ｏｒｉｇｉｎａｔｏｒ）  −  関係ノードのセットおよび／または通知処理ノードの中間セットをターゲットした通知を送り出すノード。
＜００７９＞
すべてのＭＳＤＬデータタイプとメッセージと同様に、通知、通知インタレスト、および、通知ペイロードが拡張可能であることが好ましい。さらに、通知ハンドラサービスインタフェースが、他のあらゆるＭｅｄｉａＤｒｉｖｅサービスインタフェースが受けるのと同じ認可プロセスを受けることが好ましい。したがって、特定の通知がインタレストと受け入れ可能なペイロードとに関してマッチする可能性があっても、ノードは、その通知の中間送信元または発信ソースに関係した特定の関連インタフェースポリシーに基づいて、通知を受け取ることを拒絶することができる。
＜００８０＞
図８は、通知ハンドラサービスをサポートするノードを発見する通知処理ノードのセットを示す。通知の受け取りをサポートするノードが、そのサービス記述の一部分として、その通知インタレストが何であるか、および、どの通知ペイロードタイプが受け入れ可能であるかを指定する。
＜００８１＞
図９は、通知がどのように配信されるかを示す。任意のノードが通知の発信ソースであると同時に通知のプロセッサであることが可能であり、および、通知の配信の役割を果たすことが可能である。外部の通知発生ノードからの通知を取り扱うことを選択する通知プロセッサは、効率を改善するために、Ｍｉｃｒｏｓｏｆｔ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅｓのような市販の通知処理エンジンと一体化してよい。
＜００８２＞
１０．７  サービス発見
ＭｅｄｉａＤｒｉｖｅフレームワークの好ましい実施形態が、発見サービスのためのフレキシブルなモデルのセットをサポートする。これらのモデルは既存の発見モデルにマッピングされることが可能である。一実施形態では、このフレームワークは、次の３つのサービス発見の基本モデルをサポートする。
・クライアント駆動  −  ＭｅｄｉａＤｒｉｖｅノードが、ターゲットであるノードが特定のサービスセットをサポートするかどうかを質問する「サービスクエリー」サービスインタフェースをサポートするターゲットノードの特定のセットに対して明示的に要求を送る。この要求ノードが認可されると、サービス提供ノードは、そのサービス提供ノードが要求されたインタフェースとこれに関連したサービスインタフェースバインディングとをサポートするということを報告するだろう。これは、ノードが任意のサービスを露出させる場合にそのノードがサポートするより一般的なインタフェースの１つである。
・ノード登録  −  ノードは、他のノードと共に、そのノードのサポートされたサービスを含むその記述を登録することが可能である。ノードがこのインタフェースをサポートする場合には、他のノードからの要求を受け入れ、および、特定のポリシーに基づいてそれらの記述をキャッシュすることが望ましい。これらのノード記述は、その次に、受け取りノードによる使用のために直接的に利用可能であるか、または、キャッシュされた記述を有するノードをターゲットとしたサービスクエリーを行う他のノードに対して利用可能である。
・イベントベース（ｅｖｅｎｔ−ｂａｓｅｄ）  −  ノードが、状態の変化（例えば、ノードのアクティブ／利用可能）を示す通知を送り出すか、または、ノードが、そのノードが特定のサービスをサポートすることを発表する。通知は、そのノードとそのノードのサービスとの完全な記述を含むことが可能であるか、または、イベントに関連したノードのＩＤだけを含むことが可能である。その次に、関係したノードが、その通知を受け入れて処理することを選択してよい。
＜００８３＞
図１０は、特定の要求ノードが、ターゲットであるサービス提供ノードに対してサービスクエリー要求を行い、および、要求された１つまたは複数のサービスをサービスプロバイダがサポートするかどうかを表示する応答を受け取る、クライアント駆動のシナリオを示す。
＜００８４＞
図１１は、特定の内部ポリシーに基づいて特定の要求ノードの記述を受け取ることと、この記述をキャッシュすることとを望んでいる特定の他のターゲットノードと共に、この記述を登録することをその特定の要求ノードが望む、ノード登録シナリオを示す。要求ノードは、ターゲットであるサービス提供ノードに対して登録要求を行い、および、サービスプロバイダがその記述をキャッシュしたことを表示する応答を受け取る。
＜００８５＞
図１２は、通知によってサービスの存在に対して警告されるＭｅｄｉａＤｒｉｖｅ対応ノードを示す。こうした通知は、ノードの状態の一般的な状態変化に関係した通知を含む様々な形態で到着してよく、または、ノードがサービスの利用可能性に関係した通知を明示的に送り出す。
＜００８６＞
１０．８  サービス認可
ＭｅｄｉａＤｒｉｖｅノードが、指定されたサービスに対するアクセスを許可する前に、ＭｅｄｉａＤｒｉｖｅノードが、要求ノードがアクセスを許可されているかどうかを最初に判定することが好ましい。好ましい実施形態では、アクセスを許可することが、２つの異なってはいるが互いに関係している判定基準に基づいている。第１の判定基準は、サービス提供ノードがこの通信に関して要求ノードを信用するかどうかであり、第２の判定基準は、要求されたサービスのインタフェースに対して要求ノードがアクセスすることを許可するポリシーが存在するかどうかである。
＜００８７＞
１０．８．１  信用の確立
好ましい実施形態では、ＭｅｄｉａＤｒｉｖｅフレームワークは、どのようにノードの任意のセットが互いを信用することになるかに関する、特定の要件、判定基準、または、決定ロジックを命令しない。信用セマンティクスは、ノード毎に大きく異なるだろう。ＭｅｄｉａＤｒｉｖｅフレームワークは、相互に許容された信用関係をノードがネゴシエートすることを可能にする標準的な機能セットを提供しようと試みる。ノード間の信用の判定と確立においては、ＭｅｄｉａＤｒｉｖｅフレームワークの好ましい実施形態が、信用関係を確立するために使用されることが可能なノード間の信用証明書の交換をサポートする。ＭｅｄｉａＤｒｉｖｅフレームワーク内では、信用関連の信用証明書が、様々な異なったモデルを使用して交換されてよい。例えば、
・サービスバインディング属性  −  信用証明書がサービスインタフェースバインディングの一部分として明示的に交換されるモデル。例えば、ノードが、そのサービスをＳＳＬによってＨＴＴＰ  ＰＯＳＴ上の書式において露出させるか、または、ＷＳ−Ｓｅｃｕｒｉｔｙ  ＸＭＬ  Ｓｉｇｎａｔｕｒｅを必要とするウェブサービスとして露出させる場合には、このサービスバインディングの実際の属性がすべての必要な信用関連の信用証明書を通信してよい。
・要求／応答属性  −  信用証明書がＭＳＤＬ要求および応答メッセージを通して交換され、メッセージ上の属性として信用証明書を随意に含むモデル。
・明示的交換  −  特定のノードが含む信用証明書に関係した情報の照会を可能にするサービスプロバイダインタフェースを通して信用証明書が明示的に交換されるモデル。これは、一般的に、信用証明書を交換するために別個の往復セッションを典型的に必要とする、最も複雑なモデルである。サービスインタフェースバインディング自体が相互に許容可能な信用できるチャンネルを提供する。
＜００８８＞
信用関連の信用証明書が、要求および応答メッセージ上の属性として直接的に交換されてよい。例えば、ディジタル信用証明書が、要求および応答メッセージに添付されるか、または、要求および応答メッセージと共に流通してもよく、および、信用できる関係を形成するために使用されることが可能である。
＜００８９＞
図１３に示されているシナリオでは、特定のノードがこのインタフェースをサポートする場合に、ノードが直接的にセキュリティ信用証明書サービスを介して信用証明書を交換してよい。
＜００９０＞
これらの基本モデルに加えて、ＭｅｄｉａＤｒｉｖｅフレームワークが、これらの異なったアプローチの組合せをサポートすることが好ましい。例えば、セミトラステッド（ｓｅｍｉ−ｔｒｕｓｔｅｄ）サービスバインディングに関連した通信チャンネルが、他のセキュリティ関連信用証明書の交換をより直接的にブートストラップするために使用されてよく、または、（特定のタイプの固有の完全性を有してもよい）セキュリティ関連信用証明書を直接的に交換し、および、特定のサービスインタフェースバインディングに関連したセキュアな通信チャンネルを確立するようにそのセキュリティ関連信用証明書を使用するために、使用されてよい。
＜００９１＞
要約すると、信用モデルのセマンティクスと、信用を確立するために準拠されなければならないプロセスとが、エンティティ毎に異なるだろう。特定の状況では、ノード間の相互信用が不要であってもよい。このタイプの動的な雑多な環境が、異なったエンティティが文脈依存型の信用セマンティックスをネゴシエートすることを可能にする機能の一般的なセットを提供するフレキシブルなモデルを必要とする。
＜００９２＞
１０．８．２  ポリシー管理されたアクセス
１組のインタラクトするノードの相互間の信用できる関係を確立することに加えて、サービス提供ノードがサービスに要求ノードがアクセスすることを可能にする前に、さらに、サービス提供ノードが、サービスインタフェースに関連したあらゆるポリシーに基づいてこのアクセスが許可されるかどうかを判定しなければならないことが好ましい。ＭｅｄｉａＤｒｉｖｅフレームワークは、この判定を行うための首尾一貫したフレキシブルな方法を提供する。好ましい実施形態では、サービス記述の一部分として、１つまたは複数のＭｅｄｉａＤｒｉｖｅノードが、認可サービスプロバイダとして指定されるだろう。これらの認可サービス提供ノードの各々は、「認可」クエリー要求をハンドリングするための、および、この「認可」クエリー要求に応答するための、標準的なサービスをインプリメントすることが要求されるだろう。例えば、サービスインタフェースに対するアクセスが許可される前に、ターゲットであるサービスプロバイダが、そのサービスに対するアクセスを認可するすべてのＭｅｄｉａＤｒｉｖｅノードに対して「認可」クエリー要求を送ってもよく、および、すべての認可エンティティが応答して、アクセスが許可されるということ表示する場合にだけ、アクセスが許可されてよい。
＜００９３＞
図１４が示すように、サービス提供ノードは、要求されたサービスに対するアクセスを管理するすべてのノードに対して認可要求を行い、その次に、１つまたは複数の決定に基づいて、適用可能なサービス応答を処理して戻すか、または、アクセスが拒否されたことを表示する応答を戻す。首尾一貫したメカニズムを提供することに加えて、認可ノードを決定に到達させるメカニズムが、最も適切なポリシー決定メカニズムが特定のプラットフォームとクライアントとに関してインプリメントされることが可能であるように、実用上可能な限りオープンであることが望ましい。ＭｅｄｉａＤｒｉｖｅが中立のポリシー管理システムであることが好ましい。ＭｅｄｉａＤｒｉｖｅは、どのように認可ノードが認可クエリーに基づいてサービスに対する認可に関する決定に到達するかを命令しない。
＜００９４＞
ＭｅｄｉａＤｒｉｖｅが、特定のプラットフォームに関して認可ノードによって使用される特定のポリシーエンジンまたはポリシー言語を指示しないことが好ましいが、好ましい実施形態では、認証要求が、交換され取り扱われることが可能な特定の標準的な形態を有することが、相互運用性のために必要である。拡張可能な「認可」クエリー要求が、異なったポリシー管理システムとの関連において異なったタイプの認可クエリー要求にその認可クエリーが適合できるように、フレキシブルなペイロードを有することが可能である。一実施形態では、サポートが、少なくとも２つの認可フォーマット、すなわち、（１）単純なリクエスタＩＤ、リソースＩＤ、および、アクションＩＤのような、入力として特定の最小公分母基準を使用する非常に単純な包絡線を提供する単純なフォーマットと、（２）認可クエリーの包絡されたセキュリティ表明マークアップ言語（Ｓｅｃｕｒｉｔｙ  Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）形式を送る方法を提供するＳＡＭＬフォーマットに関して提供される。
＜００９５＞
好ましい実施形態では、あらゆる認可ノードが、少なくとも「単純な」フォーマットを認識してサポートし、および、どんなネイティブなポリシー表現フォーマットが認可ノード上に存在しても、それをマッピングすることが可能なことが要件である。他のフォーマットの場合には、認可ノードは、それが「認可」クエリー要求のペイロードを取り扱わないかまたは理解しないならば、適切な誤り応答を戻すべきである。基本ＭｅｄｉａＤｒｉｖｅフレームワークに対する拡張が、認可クエリーの許容可能なフォーマットをノードがネゴシエートするための、および、特定の認可サービスプロバイダノードによって何のフォーマットがサポートされるかを判定するためにノードが問い合わせるための機能を含んでもよい。
＜００９６＞
一実施形態では、「認可」クエリー応答は、拡張可能であるが、アクセスが容認されるか否かを表示するために単純な形式から成る。このサービスのためのこの応答の他の形式が採用可能であり、特定のインタフェースに対するアクセスが容認されるべきである場合には要求ノードが履行されなければならないだろうという義務の仕様を含む。
＜００９７＞
１１．コンシューマメディアアプリケーション
ＭｅｄｉａＤｒｉｖｅの実施形態が、パーソナルエリアネットワーク、ローカルエリアネットワーク、ホームゲートウェイ、および、ＩＰベースと非ＩＰベースとのワイドエリアネットワークを含む多層環境内の幾つかの異なったサービスに対して、様々なコンシューマデバイスをリンクさせるために使用されることが可能である。例えば、相互運用性が、セル電話、ゲームプラットフォーム、ＰＤＡ、ＰＣ、ウェブベースのコンテントサービス、発見サービス、通知サービス、および、アップデートサービスを使用する１つの相互接続されたシステムにおいて成功裏に実証されている。この実施形態は、複数のメディアフォーマット（例えば、ＭＰ４、ＷＭＦ等）、（Ｂｌｕｅｔｏｏｔｈ（登録商標）経由またはＵＤＤＩ、ＬＤＡＰ、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙのようなレジストリ経由のサービスの発見のための）複数の発見プロトコル、および、同一のデバイス上のＩＰベースの通知とワイヤレスＳＭＳ通知をサポートする。編成の特徴が、相互運用性の障壁をコンシューマが克服することを補助するために使用される。コンテントに関するクエリーが存在する時には、要求を履行するために、発見サービス、探索サービス、マッチングサービス、アップデートサービス、権利交換サービス、および、通知サービスを含む様々なサービスが協調させられる。好ましい実施形態では、コンシューマが、ほとんどあらゆるデバイスを使用し、コンテントを希望し、そのコンテントと権利とがほぼ瞬時に履行されることが可能であり、コンテントを使用しかつ共有する能力を与えることが望ましい。この編成能力は、コンシューマが動的な多層ネットワーク内の任意のポイントで実質的にあらゆるデバイスからのホームおよびインターネットベースのコンテントのキャッシュを閲覧することを可能にする。この能力は、ストリームとプレイリストを共用することと、発見と接続とが容易な即座のブロードキャストとナローキャストを行うことと、権利が尊重されることを確実なものとしながら様々な異なったデバイスを使用することとを促進する、より先進的なサービスに拡張されることが可能である。
＜００９８＞
コンシューマ中心の側面を越えて、メディアフォーマットのための規格と権利管理と履行プロトコルとの単一のセットに依存しないエンドツーエンドの相互運用可能なメディア配信システムを提供する方法を発見することが一般的に望ましい。コンテント発信元、ディストリビュータ、リテーラ、サービスプロバイダ、デバイス製造業者、および、コンシューマを含む価値連鎖の中には、幾つかのローカライズされた要求が各セグメント毎に存在する。これは、特に権利管理の場合に当てはまり、この場合には、コンテント発信元が、下流の異なった価値連鎖要素に対して様々な文脈において異なった形で適用されてよい、使用権利を表現することを必要とする場合が多い。コンシューマゲートウェイが、典型的には、関心（ｃｏｎｃｅｒｎ）のより著しく狭いセットを有し、および、エンドユーザデバイスが、典型的には、関心のさらに単純なセットを有し、すなわち、コンテントを再生（ｐｌａｙ）するだけである。
＜００９９＞
動的な自己構成配信システムの充分に自動化されたシステムの場合には、コンテント発信元が、コンテントを作成してパッケージングし、権利を表現し、および、すべての関係コンシューマがどこにいようとも、または、すべての関係コンシューマが何の種類のデバイスを使用していようとも、すべての関係コンシューマに対してコンテントをほぼ瞬時に提供するために他のサービスプロバイダによって付加された価値に確信をもって依存することが可能である。ＭｅｄｉａＤｒｉｖｅの実施形態が、この目標またはこの目標の諸側面を履行する（または履行に接近する）ために使用されることが可能であり、および、エンドツーエンド規格のモノリシックなセットを待つ必要なしに、または、これに依存することなしに、コンシューマとサービスプロバイダの両方に利益を与える新たなサービスを発明および導入するために手段を複数のサービスプロバイダに提供することが可能である。１つの採用可能なアプローチが、コピー保護ではなくサービスインタフェースのポリシー管理に焦点を当てる、より自然な関心の分離によってコンポーネントの形にディジタル権利の管理が分解されることを可能にする。このアプローチは、有用な情報と瞬時の満足とをコンシューマに提供するサービスのリッチなインフラストラクチャによってコンテントが提供されるので、ディジタルコンテントドメイン内におけるコンシューマとコンテントプロバイダとの間の緊張を変化させる可能性を有する。ポリシー管理が、著作権侵害者が合法的なサービスをレバレッジすることが可能な度合いを制限することが可能である。実際には、ＭｅｄｉａＤｒｉｖｅは、ネットワーク効果が、著作権侵害者によって提供されることが可能な価値を超える価値を結果的にもたらす合法的なサービスの非常にリッチなセットの進化を促進することを可能するように設計される。
＜０１００＞
１２．一般的な企業アプリケーション
ポリシー管理されたＰ２Ｐサービス編成が、サプライチェーンマネジメント（ＳＣＭ）とカスタマリレーションシップマネジメント（ＣＲＭ）とのような領域に対してビジネスの世界における幾つかの関連アプリケーションを有するように思われる。ＣＲＭはカスタマの発見と獲得と維持とに関する。これは、統合された情報システムと、任意の所望の通信チャンネルを経由してカスタマが通信することを可能にするコンタクトセンターインプリメンテーションとを使用してカスタマに焦点を合わせることが有利である、概ねあらゆるカストマー中心のｅＢｕｓｉｎｅｓｓストラテジにおけるコアエレメントである。これは、さらに、サプライヤにも当てはまる。大半の企業は何らかの種類の階層制度と部門細分化を有し、内部的には適切に機能する部門およびプロセスのビューが、カスタマおよびサプライヤにとっては適切に機能するとは限らない。企業の部門がその部門のためのサービスインタフェースの包括的なセットを公開することを可能にすることが望ましく、この結果として、企業の部門のサービスが、異なったカスタマとサプライヤとによって、それら自体のプロセスとサービスを最適化する仕方で（ポリシーにしたがって）適合させられることが可能である。これは、企業情報ポータルを上回る重要なステップであり得る。
＜０１０１＞
今日では、大半の企業が、所有権を主張できるクライアント／サーバインフラストラクチャを使用するモノリシックなソフトウェアアプリケーションとして出現する比較的に高コストの汎用アプリケーションスーツを使用して、ＣＲＭをインプリメントする。これらのアプリケーションスーツは、大量のコンフィギュレーションの後に企業内で相互運用する。ウェブサービスは、オープンプロトコルと、通信がクローズドＬＡＮだけでなくＭＡＮおよびＷＡＮを経由しても行われる分散ウェブサービスインフラストラクチャとの使用を可能にする。このモデルは、リモートアプリケーションサービスプロバイダ（ＡＳＰ）が、様々なデータセンタからの企業内の複数のエンティティに対するサービスの集まりとしてのＣＲＭアプリケーション能力を管理し配信することを可能にする。ビジネスユニットまたは部門がポータルとなり、および、場合によってはこれらのサービスのためのアグレゲータ（ａｇｇｒｅｇａｔｏｒ）となる。これは、サービス志向アーキテクチャ／アプリケーション（ＳＯＡ）の領域においてＩＴ産業に生じている進化との関連において理解されることが可能である。アプリケーションに関連したサービスに対する企業のインタフェースとカスタマのインタフェースの両方が、単純なブラウザベースのアプリケーションから、より大きなフットプリントのＰＣ中心のアプリケーションまでを範囲に含むことが可能である。
＜０１０２＞
この新しいモデルは、依然として、このモデルがメインストリームに受け入れられることを妨げる障壁をもたらす幾つかの大きなハードルに直面する。例えば、
＜０１０３＞
情報の機密性とアクセスコントロール。ＡＳＰがＳＲＭソリューションを提供する時に、企業が、別の企業の手中に機密カスタマデータを置くことに関する問題に遭遇することがある。企業は、合法的なエンティティだけがこの情報にアクセスできるということを確実なものにしなければならない。カスタマの観点からは、彼らは別の企業と（公然のまたは暗黙の）新しい関係を潜在的に有する。必要とされるものは、カスタマと企業の両方がそれらの情報に対してアクセスコントロールを行うことを可能にするインフラストラクチャ上のメカニズムである。
＜０１０４＞
アプリケーションの拡張性。ＡＳＰは、テクノロジベンダとこれらに関連した製品またはサービスとの特に小さなセットと提携することが多い。企業は、異なったベンダからの多様なテクノロジのセットをレバレッジするためにフレキシビリティを好むことが多い。アプリケーションフレームワークは、特定のＡＳＰの現在の企業関係またはテクノロジ選択によって必ずしも制限されるべきではなく、この代わりに、異なったテクノロジベンダまたは他のＡＳＰから提供される新たな機能性とＡＳＰが迅速かつ効果的に統合することを可能にするインフラストラクチャ上のメカニズムを有することが望ましいだろう。このアプリケーションフレームワークは、さらに、例えば企業内で開発された拡張機能に基づいて、ビジネスユニット自体によって直接的に提供されるＣＲＭサービスの統合も可能にするはずである。
＜０１０５＞
サービスレベル合意（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ）（ＳＬＡ）。ビジネスのサービス要件は一般的に静的ではないだろう。この代わりに、企業のサービス要件は、典型的には、競争によって促進される新たな機能性、内部ビジネスアクティビティと特定のアクティビティのためにサポートされるカスタマの数とに基づいたオペレーション負荷、および、より低コストのサービス代替策をレバレッジする能力を含む可変的な条件に基づいて変化するだろう。場合によっては、これらの変化が長期間にわたる人間の介入を必要とすることがあるが、他の場合には、これらの変化は、指定されたルールのセットに基づいて自動化されるか迅速に再構成されることが可能である。これらの場合の両方に関して、ＣＲＭアプリケーションサービスが、既存の環境と、ＡＳＰとビジネスユニットとの間の認可された合意とに基づいて、新たなコンフィギュレーションにオーケストレートされると見なされることが可能である。これらのアプリケーションのタイプは、自己編成として特徴付けられることが可能である。
＜０１０６＞
ＭｅｄｉａＤｒｉｖｅの実施形態が、これらの要求の一部または全部に対処する上で一定の役割を果たすことが可能である。例えば、ＭｅｄｉａＤｒｉｖｅの実施形態が、信用できる認可されたエンティティだけが関連のサービスと情報とに対するアクセス権を有する、ＣＲＭおよびＳＣＭのような動的でサービス志向の自己編成アプリケーションを構築することにおいて、上述の要件に対応するために必要とされる必要なインフラストラクチャ上のビルディングブロックを提供するために使用されることが可能である。
＜０１０７＞
図１５は、異なった利害関係者にＣＲＭ関連サービスを配信するという文脈においてＭｅｄｉａＤｒｉｖｅがどのように使用されることが可能であるかを示すシナリオを図示する。図１５に示されているシナリオでは、ビジネスユニットが、異なったタイプのＣＲＭアプリケーションを構築するために、または、ビジネスユニットの組織内の異なった部門に対して、または、そのカスタマに対してカスタマデータの異なったビューを提供するために、必要なサービスを提供するように様々な異なったＡＳＰを使用することが可能である。
＜０１０８＞
このシナリオは、次に示すものの一部または全部を含む、ＭｅｄｉａＤｒｉｖｅフレームワークの好ましい実施形態によって提供される機能性を使用する幾つかの側面を示す。
・異なったＣＲＭテクノロジベンダの間の公然または暗黙の相互運用性。必要なインタフェースを記述することによって、および、ＡＳＰのレベルにおいて、または、既存のＣＲＭソフトウェアスーツの最上位で、（サービス適合層を使用して）適切なバインディングを提供することによって、異なったプロバイダからの多様なＣＲＭテクノロジによって単一のＡＳＰまたは複数のＡＳＰをビジネスが使用することが可能である。
・ＭｅｄｉａＤｒｉｖｅフレームワークを通してカスタマデータにアクセスすることによって、アクセスコントロールのためにそのリッチなポリシー管理フレームワークをレバレッジすることが可能である。
・部門が、サービスプロキシを通してその部門のアプリケーションのために必要なＣＲＭ関連サービスを配信にアクセスし、これによって搬送プロトコルやデータフォーマット等の互換性を取り巻く問題からビジネスユニットを隔離することが可能である。
・ＭｅｄｉａＤｒｉｖｅフレームワーク内の部門とデータウェアハウスとアプリケーションサービスプロバイダとの間のインタラクションが統治されることが可能である。合法的に認可されたエンティティだけがサービスにアクセスすることが可能であると共に、異なったＭｅｄｉａＤｒｉｖｅフレームワークのパティシパントが許容可能なレベルの信用をそのパティシパントのインタラクションにおいて確立することが可能である場合にだけ、サービス呼出しが生じるだろう。
・サービスの合成と編成。ＣＲＭアプリケーションが、互いにオーケストレートされた幾つかの異なったＡＳＰからのサービスからなるか、または、そのアプリケーションが単一のＡＳＰから配信されるが、しかし、異なったカスタマビューのために動的にコンフィギュレーションされることをその合成と使用とが必要とする複数のサービスから依然として成るという点で、ＣＲＭアプリケーションは自己組織的である。サービスプロバイダによって露出される機能性がサービスレベル合意（ＳＬＡ）と実行環境とによって駆動される時間全体にわたって変化することが可能である。ＭｅｄｉａＤｒｉｖｅワークフローコレータが、サービスをオーケストレートするために使用されることが可能である。このインタラクションを制御するために使用されるルールがＭＳＤＬにおいて直接的に指定されてもよく、または、記述を理解し翻訳することが可能なワークフローコレータのために書かれたプラグインが存在する限りは、ＳＬＡにおいて何らかの標準的な仕方で成文化されてもよい。ワークフローコレータが、要件に基づいて指定されたサービスを提供する方法を決定するために、必要なメッセージを収集して処理するようにＭｅｄｉａＤｒｉｖｅメッセージポンプと協働して機能するということが想起されなければならない。
＜０１０９＞
この実施形態では、ＭｅｄｉａＤｒｉｖｅが、ＩｎｔｅｒＴｒｕｓｔのＰｏｌｉｃｙＷｏｒｋｓおよびＰｏｌｉｃｙＳｐｅａｋ表現言語に基づいた分散ポリシー管理サービスのセットを使用してインプリメントされている。しかし、ＭｅｄｉａＤｒｉｖｅは、ＩＢＭのＰｏｌｉｃｙＤｉｒｅｃｔｏｒおよびＸＡＣＭＬのような他のポリシー管理フレームワークおよび言語を使用するように設計され、および、好ましい実施形態では、ＭｅｄｉａＤｒｉｖｅはポリシー管理サービスインタフェースを提供し、したがって、あらゆる適切なポリシー管理フレームワークおよび／またはポリシー表現言語が使用可能である。
＜０１１０＞
背景として、ＰｏｌｉｃｙＷｏｒｋｓは、企業内と、企業間と、企業とカスタマとの間とにおけるネットワークベースのコンテントとサービスとリソースとの使用に関するルールと権利とポリシーとを作成し配備し管理し執行するように構成されることが可能であるソフトウェアコンポーネントのセットである。企業のポリシーおよびコントロールが、ユーザと信用証明書とディレクトリとコンテントメタデータと他のポリシーおよびコントロールとを識別するための手段とインタラクトする必要があることが多いので、ＰｏｌｉｃｙＷｏｒｋｓは、企業の中に効率的に統合されるように、かつ、既存のアプリケーションとディレクトリと識別システムとをレバレッジするように設計されている。ＰｏｌｉｃｙＷｏｒｋｓの目的は、ネットワークおよびファイルシステムアクセス管理と企業情報ポータルと資産管理から、サプライチェーン管理とウェブサービスとディジタルロッカサービスとコンシューマメディアサブスクリプションアプリケーションまでを範囲とする様々な主要なアプリケーションの全体にわたるポリシーおよびルールのセキュアな管理を簡素化し統合することである。
＜０１１１＞
好ましい実施形態では、ＰｏｌｉｃｙＷｏｒｋｓアーキテクチャは、次の幾つかの基本インタフェースを露出させる論理モデルに基づいている。
・統治されたオペレーション−このインタフェースは、特定のリソースやコンテントアイテムやサービスに関する上述のアプリケーションのようなアプリケーションのアクションを統治するために、こうしたアプリケーションによって使用される。実質的にすべてのアイテムが、永続的な機密保護、アクセスコントロール、使用量の監視と検査、または、トランザクション管理を実現する、ＰｏｌｉｃｙＷｏｒｋｓを使用して統治されることが可能である。このインタフェースを経由して、アプリケーションが、使用のためのルールと要件とが準拠されるという保証を伴って、ポリシーコントロール下で、アイテム、サービス、または、リソースを利用可能にする。統治コンポーネントが、アイテムを統治するために必要な方法とオペレーションとをカプセル化する。ＰｏｌｉｃｙＷｏｒｋｓは、Ｍｉｃｒｏｓｏｆｔ  ＯｆｆｉｃｅとＡｄｏｂｅ  Ａｃｒｏｂａｔにおけるネイティブな文書保護メカニズムと、Ｊ２ＥＥ  ＥＪＢとＭｉｃｒｏｓｏｆｔ  ．Ｎｅｔ  Ｆｒａｍｅｗｏｒｋとによって与えられるコードリソースおよびサービス保護メカニズムとのような、こうした統治のための幾つかのカスタマイズ可能な標準規格品としてソリューションの使用を可能にする。
・ポリシークエリー  −  このインタフェースは、特定のユーザのための統治されたアイテムやリソースやサービスと、条件のセットと、環境データと、他のあらゆる関連ファクタとに関して何のアクションが許可されるかを厳密に決定するために使用される。クエリーに対する応答が、アイテムの使用に付随している許可および／または追加の条件と義務を含むことが可能である。統治コンポーネントは、クエリーに対する応答を受け取ると、そのポリシーの執行と、あらゆる義務の実行（または実行の起動）と、要求された使用の結果の監視との責務を負う。
・信用証明書クエリー  −  このインタフェースは、統治されたオペレーションに関連しているポリシーにおいて役割を演じる可能性があるユーザの属性を決定するために、ポリシーマネジャーによって使用される。この論理モデルは実際のインプリメンテーションにおいて強化され、したがって、例えば、幾つかのディレクトリと、アクター（ａｃｔｏｒ）（ユーザ、ポリシークリエータ、リソースマネジャー等）と統治されたアイテム自体とに関するルールとメタデータとのソースが存在する可能性があるので、ポリシーマネジャーコンポーネントが、ポリシークエリーに対する応答を決定するために外部および内部の両方の幾つかのインタフェースおよびリソースに対するアクセス権を有する。
・セキュリティサービス  −  このインタフェースは、統治されたアクションのリクエスタのための自己識別管理サービスを得るために、および、統治されたアイテムのための永続的な保護サービスを得るために使用される。
・ポリシーアドミン（ｐｏｌｉｃｙ  ａｄｍｉｎ）  −  このインタフェースは、統治されたアイテムに属するルールとコントロールの分散ポリシー管理データベースを管理するために使用される。ポリシーをオーサリングおよび維持するための様々なツールがこのインタフェースを使用する。これらのツールは、ポリシーを適用し管理するための非常に簡単な方法を提供することが可能である。例えば、このインタフェースを使用することによって、ファイルシステムにおける共用フォルダにポリシーを関連付けるツールが生成されることが可能であり、および、文書をドラッグしてそのフォルダの中に入れることによってあらゆるユーザが簡単に文書（または、他のオブジェクト）にポリシーを適用することを可能にすることができる。他のツールが、非常に厳密でターゲットにされた条件でポリシーを指定するために任意の数のポリシー表現言語を使用する、より先進的なオーサリング技術を使用することが可能である。
＜０１１２＞
ＳＣＭが、実質的にあらゆる企業の構成員が、その外部ベンダネットワークを、ＭｅｄｉａＤｒｉｖｅサービスによって管理された発送命令ポリシーと、ＭｅｄｉａＤｒｉｖｅ互換の通知サービスによって調整された請求業務とを伴う、１つの大きな仮想貯蔵庫と見なすことが可能である、別のアプリケーションである。
＜０１１３＞
理解しやすいように上述の発明をある程度詳細に説明してきたが、本発明の原理から逸脱することなしに特定の変更と改変とが行われてよいということが明らかだろう。本発明のプロセスと装置との両方を実現する多くの代替の方法があるということに留意されたい。したがって、この実施形態は例示的でありかつ非限定的であると理解されなければならず、および、本発明は本明細書に示されている特定の詳細事項に限定されない。
【０４９６】
【表３】
2014146345.tif 000005
【０４９７】
【表４】
2014146345.tif 000006
【０４９８】
【表５】
2014146345.tif 000007
【０４９９】
【表６】
2014146345.tif 000008
【０５００】
【表７】
2014146345.tif 000009
【０５０１】
【表８】
2014146345.tif 000010
【０５０２】
【表９】
2014146345.tif 000011
【０５０３】
【表１０】
2014146345.tif 000012
【０５０４】
【表１１】
2014146345.tif 000013
【０５０５】
【表１２】
2014146345.tif 000014
【０５０６】
【表１３】
2014146345.tif 000015
【０５０７】
【表１４】
2014146345.tif 000016
【０５０８】
【表１５】
2014146345.tif 000017
【０５０９】
【表１６】
2014146345.tif 000018
【０５１０】
【表１７】
2014146345.tif 000019
【０５１１】
以下に示す付記Ｂ内の図１〜７は、それぞれ、表１８〜２４として示す。
【０５１２】
＜付記Ｂ＞
ディジタル管理エンジンシステムおよび方法
＜０００１＞
関連出願
付記Ｂは、２００３年９月１５日付で出願されたＧｉｌｌｅｓ  Ｂｏｃｃｏｎ−Ｇｉｂｏｄによる標題「ディジタル権利管理エンジンシステムおよび方法」の米国仮特許出願番号６０／５０４，５２４に対応する。この出願（付記Ｂ）は、２００３年６月５日付で出願されたＷｉｌｌｉａｍ  ＢｒａｄｌｅｙとＤａｖｉｄ  Ｍａｈｅｒによる標題「ピアツーピアサービス編成のためのシステムおよび方法」の共通して譲渡された米国仮特許出願番号６０／４７６，３５７（「Ｂｒａｄｌｅｙ他の出願」、付記Ａ）に関係している。この付記Ａにおける「Ｂｒａｄｌｅｙ他の出願」に対する参照が、上述の付記Ａを参照する。
＜０００２＞
著作権認可
本特許文書の開示内容の一部が、著作権保護の対象となる資料を含む。著作権所有者は、ＷＩＰＯまたは米国特許商標庁の特許ファイルまたは記録に示されているように、いかなる者による特許文書の複写複製または特許公開も認めるが、それ以外は、どのようなものであれ、すべての著作権の権利を留保する。
＜０００３＞
発明の分野
本発明は、一般的に、ディジタル情報およびサービスの配信と使用とに関する。さらに明確に述べると、ディジタル権利管理エンジンを提供し、サポートし、および／または、使用するためのシステムおよび方法が開示される。
＜０００４＞
背景
インターネットのようなネットワークがディジタルコンテント配信の支配的な媒体と成っている。ウェブサービスのための規格の出現が、標準化されたメカニズムによって複数のソフトウェアプラットフォームと共に相互運用しかつ他のウェブサービスと協働する高度なサービスを企業が提供することを可能にするこのトレンドを加速するだろう。
＜０００５＞
発明の要約
本発明の実施態様が、ウェブサービスモデルをレバレッジするディジタル権利管理エンジンを提供する。保護されたコンテントを取り扱うために比較的複雑で重量級のクライアント側エンジンを必要とする多くの従来のディジタル権利管理（ＤＲＭ）システムとは対照的に、本発明はクライアント側のＤＲＭエンジンが比較的単純であることを可能にし、および、サービスレベルで動作するよりリッチなポリシー管理システムによって設定された統治ポリシーを執行する。本発明の実施態様は、さらに、メディアフォーマットと暗号プロトコルとの選択におけるフレキシビリティの増大を実現し、および、ＤＲＭシステムの相互間の相互運用性を促進することが可能である。
＜０００６＞
本発明の好ましい実施態様が、強力なＤＲＭ対応アプリケーションを構築するために使用されることが可能な単純でオープンでフレキシブルなクライアント側のＤＲＭエンジンを提供する。好ましい実施態様では、そのＤＲＭエンジンは、Ｂｒａｄｌｅｙ他の出願で説明されているウェブサービス環境のようなウェブサービス環境に容易に統合されるように、および、実質的にあらゆるホスト環境またはソフトウェアアーキテクチャに統合されるように設計されている。好ましい実施態様では、このＤＲＭエンジンは個別のメディアフォーマットと暗号プロトコルとから独立しており、標準化された技術または所有権を主張できる技術を使用するためのフレキシビリティを必要に応じて設計者に与える。これに加えて、好ましい実施態様で使用される統治モデルは比較的単純であるが、高度な関係とビジネスモデルとを表現するために使用されることも可能である。
＜０００７＞
本発明の好ましい実施態様が、次の目標の一部または全部を実現するために使用されることが可能である。
＜０００８＞
単純性。好ましい実施態様では、ＤＲＭエンジンは、コントロールプログラム（例えば、統治ポリシーを執行するプログラム）を実行するために必要最小限のスタックベースのバーチャルマシン（ＶＭ）を使用する。例えば、一実施態様では、このＶＭは数ページのコードだけから成ってよい。
＜０００９＞
モジュール性。好ましい実施態様では、ＤＲＭエンジンは、より大きなＤＲＭ対応アプリケーションに統合された単一のモジュールとして機能するように設計されている。かつてはモノリシックなＤＲＭカーネルによって行われた（暗号化サービスのような）機能の多くが、ホスト環境から要求されることが可能であり、このホスト環境はこれらのサービスを他のコードモジュールに提供してよい。このことが、設計者が比較的容易に標準的な技術または所有権を主張できる技術を組み込むことを可能にする。
＜００１０＞
フレキシビリティ。このＤＲＭエンジンの好ましい実施態様は、そのモジュール型の設計の故に、組込型デバイスから汎用ＰＣに至る様々なソフトウェア環境で使用されることが可能である。
＜００１１＞
オープンである。ＤＲＭエンジンの好ましい実施態様は、基準ソフトウェアとしての使用に適しており、したがってコードモジュールとＡＰＩとが、実質的にあらゆるプログラミング言語とそのプログラミング言語が完全にコントロールするシステムとにおいてユーザによってインプリメントされることが可能である。好ましい実施態様では、そのシステムは、特定のコンテントフォーマットを採用するかコンテントエンコーディングを制限することをユーザに強制しない。
＜００１２＞
意味論的に寛容である（ｓｅｍａｎｔｉｃａｌｌｙ  ａｇｎｏｓｔｉｃ）。好ましい実施態様では、ＤＲＭエンジンは、認可要求をグラフの構造に関するクエリーに変える単純なグラフベースのモデルに基づいている。このグラフの頂点はそのシステムのエンティティを表し、および、有向辺がこれらのエンティティの間の関係を表す。しかし、このＤＲＭエンジンは、これらの頂点と辺とが任意の特定のアプリケーションにおいて表すものを認識する必要はない。
＜００１３＞
ウェブサービスとのシームレスな統合。ＤＲＭクライアントエンジンはウェブサービスを幾つかの形で使用することが可能である。例えば、認可グラフ中の頂点と辺とがサービスを通して動的に発見されることが可能である。さらに、コンテントとコンテントライセンスとが発見されて、高度なウェブサービスを介してそのＤＲＭエンジンに配信されてよい。この好ましい実施態様のＤＲＭエンジンが多くの場所においてウェブサービスをレバレッジするように構成されることが可能であるが、そのアーキテクチャはウェブサービスから独立しており、および、スタンドアロンのクライアント側ＤＲＭカーネルとして使用されることが可能である。
＜００１４＞
簡略化された鍵管理。好ましい実施態様では、認可グラフのトポロジが、暗号リターゲティング（ｃｒｙｐｔｏｇｒａｐｈｉｃ  ｒｅｔａｒｇｅｔｉｎｇ）を必要とせずにコンテント保護鍵の導出を簡易化するために再使用されることが可能である。この鍵導出方法は採用随意であるが、ＤＲＭエンジンの強力な特徴であり、および、そのシステムは、さらに、または、この代わりに、他の鍵管理システムと統合することが可能であることが可能である。
＜００１５＞
統治と暗号化とコンテントとの分離。好ましい実施態様では、コンテントを統治するコントロールが、統治を執行するために使用される暗号情報とは論理的に別個である。同様に、そのコントロールと暗号情報はコンテントとコンテントフォーマットとは論理的に別個である。これらの要素の各々が別々にまたは一体化されたパッケージの形で配信されることが可能であり、したがってコンテント配信システムの設計において高度のフレキシビリティを可能にすることが可能である。
＜００１６＞
本発明の好ましい実施態様は上述の目標の一部または全部を実現するために使用されることが可能である。しかし、さらに本発明がこれらの目標を実現しないシステムによっても実施されることが可能であるということを理解されたい。
＜００１７＞
好ましい実施態様では、ＤＲＭエンジンは、保護されたコンテントに対する特定のアクションが許可可能であるかどうかを判定するように設計されているバーチャルマシン（ＶＭ）を含む。このコントロールＶＭは、最小の命令セットを有する単純なスタックベースのマシンとしてインプリメントされてよい。一実施態様では、このコントロールＶＭは、論理計算と算術計算とを行うことと、システムタイム、カウンタ状態等のようなパラメータを検査するためにホスト環境から状態情報を問い合わせることとが可能である。
＜００１８＞
好ましい実施態様では、ＤＲＭエンジンは、ＤＲＭ価値連鎖内のエンティティの相互間の関係を検証するためにグラフベースのアルゴリズムを使用する。図１は、こうした認可グラフの一例を示す。図１に示されているように、このグラフは、リンクによって連結されたノードの集まりを含む。好ましい実施態様では、このリンクのセマンティックスはアプリケーションに特有の形で変化してよい。例えば、Ｍａｃ頂点からノックス頂点への有向辺が、ノックスがそのＭａｃの所有者であるということを意味する。ノックスから公立図書館への辺が、ノックスが公立図書館のメンバであるということを表示するだろう。好ましい実施形態では、ＤＲＭエンジンはこれらのセマンティックスを強制も翻訳もしない。ＤＲＭエンジンは、そのグラフ内の経路の有無を単純に確認する。
＜００１９＞
例えば、コンテント所有者が、消費デバイスが公共図書館のメンバによって所有されかつＲＩＡＡ承認されている場合に特定の音楽楽曲が再生されることを可能にするコントロールＶＭによって翻訳されるコントロールプログラムを生成してもよい。そのデバイス上で実行しているコントロールＶＭがこのコントロールプログラムを評価する時には、ＤＲＭエンジンは、ポータブルデバイスと公共図書館との間のリンクと、ポータブルデバイスとＲＩＡＡ承認との間のリンクとが存在するかどうかを判定する。グラフの辺と頂点とが静的でありかつデバイスの中に組み込まれてよく、または、動的であり、かつ、ホストアプリケーションと通信するサービスによって発見されてよい。
＜００２０＞
ノードとリンクとにセマンティクスを強制しないことによって、この好ましい実施態様のＤＲＭエンジンは大きなフレキシビリティを可能にする。このシステムは、伝統的な委任（ｄｅｌｅｇａｔｉｏｎ）ベースのポリシーシステムから、認可されたドメインおよびパーソナルエリアネットワークまでの、様々なユーセージモデルに適合させられることが可能である。
＜００２１＞
好ましい実施態様では、ＤＲＭクライアントは、さらに、コンテント保護鍵導出のために認可グラフを再使用することも可能である。システム設計者は、リンクの存在が特定の暗号情報の共用も表示することを可能にすることを選択してもよい。この場合には、認可グラフは、消費デバイスに対する明示的な暗号リターゲティングなしにコンテント鍵を導出するために使用されることが可能である。
＜００２２＞
ＤＲＭエンジンの好ましい実施態様はモジュール型であり、これによって様々な異なったデバイスおよびソフトウェア環境への統合を可能にする。図２は、コンテント消費デバイスの中へのＤＲＭクライアントエンジンの典型的な統合を示す。図２に示されているシステムのようなシステムでは、典型的なコンテント消費イベントは次のように進行してよい。
＜００２３＞
ホストアプリケーション２０２が、典型的にはそのユーザインタフェース２０４を通して、コンテントの特定部分にアクセスするための要求を受け取る。ホストアプリケーション２０２は、すべての関連したＤＲＭエンジンオブジェクト（好ましくはホストアプリケーションに対して不透明である）と共に、その要求をＤＲＭエンジン２０６に送る。ＤＲＭエンジン２０６は、明確に定義されたインタフェースを通してホストサービスモジュール２０８に対して追加の情報と暗号サービスとを求める要求を行う。例えば、ＤＲＭエンジン２０６は、特定のリンクが信用できるかどうかをホストサービス２０８に質問してよく、または、特定のオブジェクトが暗号解読されることを求めてもよい。必要な情報の一部分が非ローカルであってもよく、この場合には、ホストサービス２０８は、サービスアクセスポイント２１４を通して、ネットワークされたサービスからその情報を要求することが可能である。
＜００２４＞
特定のオペレーションが許可されるとＤＲＭエンジン２０６が判定すると直ちに、このＤＲＭエンジン２０６は、このことを表示し、および、要求されたあらゆる暗号化鍵をホストサービス２０８に対して戻し、このことは、必要に応じて、暗号サービス２１２と協調させられたメディアレンダリング２１０（例えば、スピーカによってコンテントを再生すること、画面上にコンテントを表示すること等）を開始させる。
＜００２５＞
図２に示されているシステムアーキテクチャは、ＤＲＭエンジンがアプリケーションにおいてどのように使用されることが可能であるかの単純な例であるが、これは多数の可能性の中の１つに過ぎない。例えば、他の実施態様では、ＤＲＭエンジンは、比較的高度なポリシー管理システムの統治下でパッケージングアプリケーションに統合されることが可能である。
＜００２６＞
この開示されている実施態様が、プロセス、機器、システム、デバイス、方法、または、コンピュータ可読媒体を含む様々な形でインプリメントされることが可能であるということを理解されたい。本発明のこれらの特徴と利点と実施態様と他の特徴と利点と実施態様とが、以下の詳細な説明と添付図面とによってさらに詳細に示されるだろう。
図面の簡単な説明
＜００２７＞
本発明の実施形態が、同じ照合番号が同じ構造要素を示す次の添付図面と組み合わせて以下の詳細な説明を参照することによって、容易に理解されるだろう。
＜００２８＞
図１は、本発明の実施形態による認可グラフを示す。
＜００２９＞
図２は、本発明の実施形態によるディジタル権利管理システムを示す。
＜００３０＞
図３は、本発明の好ましい実施形態におけるコンテント保護と統治とのためにＤＲＭエンジンが使用可能な様々なオブジェクトを示す。
＜００３１＞
図４は、本発明の実施形態によるノードオブジェクトとリンクオブジェクトとを示す。
＜００３２＞
図５は、本発明の実施形態によるコントロールバーチャルマシンとＤＲＭエンジンとの統合を示す。
＜００３３＞
図６は、本発明の実施形態によるコードモジュールを示す。
＜００３４＞
図７は、コンテントの暗号化と暗号解読とを容易にするためのノードグラフの使用を示す。
詳細な説明
＜００３５＞
新規性のあるディジタル権利管理エンジンの実施形態が本明細書で説明される。当業者は理解するように、このエンジンの特徴と側面と構成要素とアプリケーションの多くと同様に、このエンジン自体に新規性がある。本発明主体の詳細な説明が以下に示されている。この説明は幾つかの実施形態に関連付けて行われているが、本発明がどれか１つの実施形態に限定されることがなく、その代わりに、数多くの代替案と変型と等価物とを含むということを理解されたい。例えば、幾つかの実施形態がコンシューマ志向のコンテントとアプリケーションとに関連付けて説明されているが、当業者は、開示されているシステムおよび方法がより広範なアプリケーションに容易に適合可能であるということを理解するだろう。例えば、本発明の実施形態は、非限定的に、企業コンテントおよびアプリケーションに関連して容易に適用されることが可能である。これに加えて、本発明の完全な理解を実現するために数多くの具体的な詳細が後述の説明において記述されているが、本発明はこれらの詳細の一部または全部を伴わずに実現されてよい。さらに、理解を容易にするように、本発明に関連した技術分野では公知である特定の技術的資料は、本発明を不必要に不明瞭にすることを避けるために、詳細に説明されてはいない。
＜００３６＞
好ましい実施形態では、ＤＲＭクライアントエンジンが基本オブジェクトまたはビルディングブロックのグループに対して作用する。図３が、これらのオブジェクトの高レベルの図表を示す。図３に示されているように、好ましい実施形態では、コンテントオブジェクト３０２によって表されるデータが、鍵を使用して暗号化される。この鍵は、コンテント鍵オブジェクト３０４によって表現されており、および、コンテントと鍵との間のバインディングがプロテクタオブジェクト３０６によって表現されている。コンテントを暗号解読するための鍵の使用を統治するルールがコントロールオブジェクト３０８によって表され、および、コンテント鍵３０４とコントロール３０８との間のバインディングがコントローラオブジェクト３１０によって表されている。準拠したシステムが、コントロールオブジェクト３０８においてバイトコードによって表現されるルールの統治下でコンテント暗号解読鍵を使用する。
＜００３７＞
コンテントオブジェクト３０２：好ましい実施形態では、コンテントオブジェクト３０２は「外部」オブジェクトである。そのフォーマットと記憶はＤＲＭエンジンの制御を受けず、むしろ、ホストアプリケーション（例えば、ＭＰ４映画ファイル、ＭＰ３音楽トラック等であることが可能である）のコンテント管理サブシステムのコントロールを受ける。しかし、好ましい実施形態では、コンテントのフォーマットは、ＩＤをコンテントペイロードに関連付けることを可能にするようなフォーマットである。コンテントペイロードは、フォーマットに依存した形で（例えば、ＡＥＳのような対称暗号によって）暗号化される。
＜００３８＞
コンテント鍵オブジェクト３０４：好ましい実施形態では、コンテント鍵オブジェクト３０４は、固有の暗号化鍵とこれに関連したＩＤとを含む。このＩＤの目的は、プロテクタオブジェクト３０６とコントローラオブジェクト３１０とがコンテント鍵オブジェクト３０４を参照することを可能にすることである。コンテント鍵オブジェクト３０４にカプセル化されている実際の鍵データ自体が、コンテントを暗号解読することを認可されているレシピエントだけによってこの鍵データ自体が読み出されることが可能であるように暗号化される。コンテント鍵オブジェクト３０４は、さらに、鍵データを暗号化するために使用された暗号化システムを指定することが好ましい。コンテント鍵データを保護するために使用されるこの暗号化システムは、鍵配布システムと呼ばれる。様々な鍵配布システムが使用されることが可能である。
＜００３９＞
プロテクタオブジェクト３０６：好ましい実施形態では、プロテクタオブジェクト３０６が、コンテントオブジェクト３０２に含まれているデータを暗号化するためにどの鍵が使用されたかをＤＲＭエンジンが発見することを可能にする情報を含む。プロテクタオブジェクト３０６は、さらに、そのデータを暗号化するためにどの暗号化アルゴリズムが使用されたかに関する情報も含む。プロテクタオブジェクト３０６は、コンテントオブジェクト３０２を参照する１つまたは複数のＩＤと、データを暗号化するために使用された鍵を保持するコンテント鍵オブジェクト３０４を参照するＩＤとを含む。好ましい実施形態では、プロテクタ３０４が２つ以上のコンテントオブジェクト３０２をポイントする場合に、これらのコンテントオブジェクトのすべてが、同一の暗号化アルゴリズムと同一の鍵とを使用して暗号化されているデータを表す。
＜００４０＞
コントロールオブジェクト３０８：コントロールオブジェクト３０８は、ホストアプリケーションによって要求される時にコンテントに対する特定のアクションが許可されるべきであるかどうかに関してＤＲＭエンジンが決定することを可能にする情報を含む。コンテント鍵の使用を統治するルールは、コントロールバイトコードとしてコントロールオブジェクト３０８において符号化される。コントロールオブジェクト３０８は、さらに、それがコントローラオブジェクト３１０によって参照されることが可能であるように、固有ＩＤを含む。好ましい実施形態では、コントロールオブジェクト３０８は署名され、その結果として、ＤＲＭエンジンは、決定のためにコントロールバイトコードが使用される前にそのコントロールバイトコードが有効でありかつ信用できるということを検証することが可能である。コントロールオブジェクト３０８の妥当性は、さらに、コントローラオブジェクト３１０に含まれているセキュアハッシュの情報が利用可能である時に、このセキュアハッシュの検証によって随意に導出されることも可能である。
＜００４１＞
コントローラオブジェクト３１０：コントローラオブジェクト３１０は、コンテント鍵オブジェクト３０４によって表された１つまたは複数の鍵の使用をどの１つまたは複数のコントロールオブジェクト３０８が統治するかをＤＲＭエンジンが発見することを可能にする情報を含む。好ましい実施形態では、コントローラオブジェクト３１０は、さらに、そのコントローラオブジェクト３１０が参照するコンテント鍵オブジェクト３０４に含まれている鍵データのためのハッシュ値も含み、したがって鍵データとコンテント鍵オブジェクト３０４との間のバインディングが容易に改ざんされることは不可能である。コントローラオブジェクト３１０は、さらに、それらが関連付けられているコントロールオブジェクト３０８の完全性の検証を容易にする情報も含んでよい。コントローラオブジェクト３１０が署名されることが好ましく、したがってＤＲＭエンジンは、コンテント鍵３０４とそれを統治するコントロールオブジェクト３０８との間のバインディングの妥当性と、コンテント鍵ＩＤと実際の鍵データとの間のバインディングの妥当性とを信用することができる。コントローラオブジェクト３１０によって参照されるコントロールオブジェクト３０８のハッシュがコントローラオブジェクト３１０に含まれている実施形態では、コントロールオブジェクト３０８の妥当性が、コントロールオブジェクト３０８の署名を別個に検証する必要なしに導出されることが可能である。
＜００４２＞
図１に関連して上述したように、好ましい実施形態では、ＤＲＭエンジンは、ＤＲＭ価値連鎖におけるエンティティの間の関係を検証するために、グラフをベースとしたアルゴリズムを使用する。図１に示されているように、このグラフは、リンクによって連結されているノードの集まりを含む。ノードオブジェクトはＤＲＭプロファイルのエンティティを表す。好ましい実施形態では、ＤＲＭエンジンは、ノードオブジェクトが表すものに関する明示的なまたは暗黙のセマンティクスを持たない。
＜００４３＞
ＤＲＭエンジンを使用するシステムの特定の配備（ＤＲＭプロファイル）が、何のタイプのプリンシパルが存在するか、および、異なったノードオブジェクトが何の役割と自己識別とを表すかを定義するだろう。図４に示されているように、そのセマンティック情報は、典型的には、ノードオブジェクトの属性を使用して表現される。リンクオブジェクトがノード間の関係を表す。リンクオブジェクトは、さらに、ＤＲＭエンジンがコンテント鍵導出計算ためにリンクを使用することを可能にする何らかの暗号データを含むことが随意に可能である。ノードの場合と同様に、好ましい実施形態では、ＤＲＭエンジンは、リンク関係が意味するものに関する暗黙のまたは明示的なセマンティックスを持たない。リンクの「からの（ｆｒｏｍ）」または「への（ｔｏ）」ノードが特定のＤＲＭプロファイルで表すものに応じて、リンク関係の意味がメンバシップ、所有権、関連付け、および／または、様々な他のタイプの関係を表現することが可能である。例えば、典型的なＤＲＭプロファイルでは、特定のノードオブジェクトがユーザを表してよく、他のノードがデバイスを表してよく、および、他のノードがユーザグループを表してよい。この文脈においては、デバイスとユーザとの間のリンクが所有権関係を表してよく、および、ユーザとユーザグループとの間のリンクがメンバシップ関係を表してよい。図４がノードオブジェクトとリンクオブジェクトとの例を示す。
＜００４４＞
ノード４０２：ノードオブジェクトがシステム内のエンティティを表す。ノードオブジェクトの属性が、ＤＲＭプロファイルに関連してノードオブジェクトによって表される役割または自己識別のような、ノードオブジェクトが表すものの特定の側面を定義する。好ましい実施形態では、ノードオブジェクトは、さらに、ノードオブジェクト（典型的には、ノードによって表されるエンティティ、または、そのノードを管理する役割を持つ何らかのエンティティ）の機密部分に対するアクセス権を有するサブシステムに対して機密情報をターゲットするために使用される機密保持非対称鍵対も有する。ノードをターゲットにした機密情報が、そのノードの機密保持公開鍵によって暗号化されることが好ましい。コンテント保護非対称鍵対とコンテント保護対称鍵とが、コンテント鍵配布のための採用随意のコンテント鍵導出システムを使用する実施形態において、リンクオブジェクトと組み合わせて使用される。
＜００４５＞
リンク４０４：好ましい実施形態では、リンクオブジェクト４０４が署名され、その頂点がノードオブジェクトであるグラフの中の「Ｔｏ」ノードと「Ｆｒｏｍ」ノードとの間に有向辺が存在するということを表明する。ノードとリンクとの特定のセットでは、そのグラフ中のノードＸ頂点とノードＹ頂点との間に有向の経路が存在する場合に、ノードＸとノードＹとの間の経路が存在する。ノードＸとノードＹとの間の経路が存在する時には、ノードＹはノードＸから「到達可能である」と言い表される。したがって、リンクオブジェクトによって表される表明は、どのノードが他のノードから到達可能であるかを表現するために使用される。コンテントオブジェクトを統治するコントロールが、コンテントオブジェクトに対するアクションを要求しているエンティティを表すノードからの特定のターゲットノードへの到達可能性を特定のアクションが生じさせることを可能にするための条件として、使用することが可能である。例えば、ノードＤが、コンテントオブジェクトに対して「再生」アクションを行うことを望むデバイスを表す場合には、このコンテントオブジェクトを統治するコントロールが、特定のユーザを表す特定のノードＵが到達可能であるかどうかを試験することが可能である。ノードＵが到達可能であるかどうかを判定するために、ＤＲＭエンジンは、ノードＤとノードＵとの間に経路を確立することが可能なリンクのオブジェクトセットが存在するかどうかを検査する。
＜００４６＞
ＤＲＭエンジンが、ノードグラフ中の経路の存在を確認するためにリンクオブジェクトを使用する前に、そのリンクオブジェクトを検証することが好ましい。リンクオブジェクト（例えば、ｘ５０９ｖ３）に署名するために使用される証明書システムの特定の特徴に応じて、リンクオブジェクトは、限定された寿命を与えられたり、取り消されたりすることが可能である。さらに、好ましい実施形態では、どのエンティティがリンクオブジェクトに署名することが可能であるかということ、どのリンクオブジェクトが生成可能であるかということ、および、リンクオブジェクトの寿命とを統治するポリシーは、ＤＲＭエンジンによって直接的には処理されない。これらのポリシーはＤＲＭエンジンの外側に存在し、および、典型的にはノードの属性情報をレバレッジするだろう。例えば、特定のポリシーの下でデバイスノードとユーザノードとをリンクさせるリンクオブジェクトを生成する能力がすでに与えられているエンティティが、そのノードオブジェクトが実際にデバイスを表しているということを表示する属性を有するノードオブジェクトと、そのノードがユーザを表すということを表示する属性を有するノードとの間のリンクだけを、そのエンティティが生成するということを恐らくは検査するだろう。
＜００４７＞
最後に、リンクオブジェクトは、鍵配布のためのノードのコンテント保護鍵の使用を可能にする暗号化データを含むことが可能である。特定の実施形態では、この暗号化データは、メタデータに加えて、「Ｔｏ」ノードのコンテント保護公開鍵および／またはコンテント保護対称鍵で暗号化された、「Ｆｒｏｍ」ノードのプライベートおよび／または対称コンテント保護鍵を含む。ノードとリンクの関係とオペレーションとに関する追加情報を、見出し「ノード、リンク、および、コンテント保護」の下で後述する。
＜００４８＞
好ましい実施形態では、ＤＲＭエンジンが、これらの基本オブジェクトに付与されているセマンティックスを明示的にまたは暗黙に指定しないので、そのＤＲＭエンジンを使用するシステムは、セマンティック文脈にこれらのオブジェクトを入れる、これらのオブジェクトに関する１つまたは複数の使用パターンに関与するだろう。これらのセマンティック文脈がＤＲＭプロファイルと呼ばれるだろう。この意味において、ＤＲＭエンジンオブジェクトは、ＤＲＭシステムを構築するために使用されるＤＲＭビルディングブロックであると見なされることが可能である。
＜００４９＞
次のパラグラフは、ＤＲＭエンジンオブジェクトを使用して構築されることが可能な典型的なタイプのＤＲＭプロファイルを示す。
＜００５０＞
事例１：ユーザ、ＰＣ、および、デバイス
＜００５１＞
このＤＲＭプロファイルの事例では、ユーザ（コンテントを消費している個人）、ＰＣ（コンテントを使用するソフトウェアアプリケーションを実行するコンピュータ）、および、デバイス（コンテントを使用（例えば、再生）するハードウェアとソフトウェアとの組合せ）というエンティティが定義される。このプロファイルの例では、あらゆるユーザが無制限な数のデバイスを所有することが可能であり、および、予め決められた数までのＰＣ（例えば、４つのＰＣ）に関連付けられることが可能である。コンテントは、コンテントがユーザにバインドされることを可能にするルールによって統治されることが可能である（例えば、ルールは、コンテントを再生するＰＣまたはデバイスが特定のユーザに属するか関連付けられていることを検査することが可能である）。
＜００５２＞
ユーザ、ＰＣ、および、デバイスの各々はノードオブジェクトに割り当てられる。これらのノードオブジェクトは、これがユーザ、ＰＣ、または、デバイスを表すかどうかを表示する「タイプ」属性を有する。
＜００５３＞
バックエンドシステムがユーザの自己識別を管理し、および、ユーザノードと、ＰＣノードとユーザノードの間のリンクオブジェクトとを生成する。ユーザノードオブジェクトがＰＣソフトウェアインスタンスに送られる前に、バックエンドサーバが、ユーザ情報データベース内のユーザをルックアップすることと、特定のＰＣに関連付けられることを望んだユーザが４人という限界に達したかどうかを判定することとによって、「ユーザ１人当たり４つのＰＣ」ポリシーを執行するだろう。特定の実施形態では、そのシステムは、時間の経過に応じてユーザが関連付けられるＰＣのセットをそのユーザが変更できるように、既存のＰＣ／ユーザ関連付けをそのユーザが取り除くための方法を提供することができる。ＰＣソフトウェアはＰＣ対ユーザのリンクオブジェクトを保持し、および、このリンクオブジェクトが有効状態のままである限りこのリンクオブジェクトを使用することが可能である。
＜００５４＞
ＰＣソフトウェアが、デバイスをユーザに関連付ける能力を与えられる。このことは、ＰＣノードオブジェクトに加えてユーザノードオブジェクトを管理する責務がＰＣソフトウェアに与えられることを意味する。ソフトウェアは、これらのノードの機密部分に対するアクセス権を有する。（ユーザが自分のコンテントをデバイス上で再生することを望むので）ユーザがデバイスに関連付けられることを望む時には、デバイスノードとユーザノードとからのリンクオブジェクトが存在する必要がある。そのリンクが存在しない場合には、ＰＣソフトウェアがそのリンクを生成し、および、そのリンクをデバイスに対して使用可能にするだろう。デバイスはそのリンクオブジェクトを保持し、および、そのリンクオブジェクトが有効状態のままである限りそのリンクオブジェクトを使用するだろう。
＜００５５＞
コンテントをユーザにバインドするために、パッケージャアプリケーションがＩＤを選択するか、または、コンテントのために既存ＩＤを使用するだろう。パッケージャは、コンテントオブジェクトとコンテント鍵オブジェクトとをバインドするために、暗号化鍵と、これに関連付けられているコンテント鍵オブジェクトと、プロテクタオブジェクトとを生成する。その次に、パッケージャは、「再生」アクションの遂行を要求しているＰＣまたはデバイスノードからユーザノードが到達可能である場合に、および、この場合にだけ、「再生」アクションが生じることを可能にする（コントロールＶＭバイトコードの形にコンパイルされていることが好ましい）コントロールプログラムによってコントロールオブジェクトを生成する。典型的には、コントロールオブジェクト、コントローラオブジェクト、プロテクタオブジェクト、および、コンテント鍵オブジェクトは、場合に応じてパッケージングされたコンテント内に埋め込まれるだろうし、その結果としてＰＣおよびデバイスがそれらを別個に得る必要がないだろう。
＜００５６＞
デバイスまたはＰＣがコンテントを再生することを望む時には、ＤＲＭエンジンがコンテントのコンテントＩＤのためのプロテクタオブジェクトを発見し、その次に、そのプロテクタによって参照されるコンテント鍵オブジェクトを発見し、その次に、そのコンテント鍵オブジェクトを参照するコントローラオブジェクトを発見し、最後にそのコントローラによって参照されるコントロールオブジェクトを発見するだろう。ＤＲＭエンジンは、コントールオブジェクトのコントロールプログラムを実行し、このコントロールプログラムは、ユーザノードが到達可能であるかどうかを検査するだろう。デバイスまたはＰＣノードが、そのノードとユーザノードとの間に経路が存在するということを検証するために必要なリンクオブジェクトを有する場合には、コントロールプログラムは、コンテント鍵オブジェクトに表されている鍵の使用を可能にし、および、デバイスまたはＰＣのメディアレンダリングエンジンがコンテントを暗号解読してレンダリング（例えば、再生）するだろう。
＜００５７＞
事例２：一時的なログイン
＜００５８＞
第２の事例が、ＰＣノードとユーザノードとの間のリンクオブジェクトの生成を統治するポリシーが、ユーザがすでに別のＰＣに一時的にログインしていない限り、例えば１２時間にすぎない一時的なログインを可能にするという新たな特徴が追加されている、上述の事例に関係して使用されるシステムと概ね同一のシステムを使用する。この特徴の目的は、例えば、ユーザが友人のＰＣに対して自分のコンテントを持って行き、一定の時間期間にわたってそのＰＣにログインし、および、自分のコンテントをその友人のＰＣ上で再生することを可能にすることである。ユーザが自分の友人のＰＣにログインしようとする時には、そのユーザは自分のログイン信用証明書（これは、ユーザ名／パスワード、移動電話認証、スマートカード、または、そのシステムのポリシーの下で許可された任意の認証システムであることが可能である）を入力し、および、バックエンドシステムが、リンクが要求されているユーザノードとＰＣノードとの属性を検査して、依然として有効であるアクティブな一時的なログインリンクが存在しないことを確認する。これらの条件が満たされると、バックエンドサービスは、ポリシーに準拠するために、要求されたログイン持続時間（例えば１２時間未満）に制限された有効期間を有する、そのＰＣとユーザとをリンクさせるリンクオブジェクトを生成する。この時点では、そのリンクを有することが、リンクが期限切れになるまでユーザのコンテントをそのＰＣが再生することを可能にする。
＜００５９＞
コントロールバーチャルマシン
＜００６０＞
コントロールバーチャルマシン（または、「コントロールＶＭ」）は、コンテントに対するアクセスを統治するコントロールプログラムを実行するために、ＤＲＭエンジンの好ましい実施形態によって使用されるバーチャルマシンである。コントロールＶＭがＤＲＭエンジンアーキテクチャ内のどこに収まるかということの説明と、そのＶＭの基本要素の幾つかの説明と、メモリモデルおよび命令セットに関するさらに詳しい説明とを次に示す。
＜００６１＞
好ましい実施形態では、コントロールＶＭは、様々なプログラミング言語を使用してインプリメントしやすいように設計されている小さなフットプリントのバーチャルマシンである。好ましい実施形態では、コントロールＶＭは、実行速度またはコード密度に関するそれほど大きな関心なしに、必要最小限に設計されているスタック志向の命令セットに基づいている。しかし、実行速度および／またはコード密度が特定のアプリケーションで問題である場合には、従来の技術（例えば、データ圧縮）が性能の改善のために使用されることが可能であるということが理解されるだろう。
＜００６２＞
好ましい実施形態では、コントロールＶＭは、低レベルまたは高レベルのプログラミング言語のためのターゲットとして適しており、および、アセンブラ、Ｃ、および、ＦＯＲＴＨのような言語をサポートする。Ｊａｖａ（登録商標）またはカスタム言語のような他の言語のためのコンパイラも、比較的容易にインプリメントされることが可能である。
＜００６３＞
好ましい実施形態では、コントロールＶＭは、プロセッサ上でまたはシリコン内で直接的に実行されるのではなく、ホスト環境内にホストされるように設計されている。コントロールＶＭのための本来のホスト環境がＤＲＭエンジンである。図５は、本発明の好ましい実施形態において、どのようにコントロールＶＭがＤＲＭエンジンと統合されるかを示す。
＜００６４＞
コントロールＶＭはそのホスト環境の文脈の中で実行し、このホスト環境は、このＶＭがプログラムを実行する時にこのＶＭによって必要とされる機能の幾つかをインプリメントする。典型的には、コントロールＶＭはＤＲＭエンジン内で実行し、このＤＲＭエンジンはそのホスト環境を実現する。
＜００６５＞
このＶＭは、コードモジュール内に格納された命令を実行することによって、プログラムを実行する。これらの命令の幾つかが、システムコールを行うことによってプログラム自体の外側でインプリメントされる機能を呼び出す。システムコールは、コントロールＶＭ自体によってインプリメントされるか、または、ホスト環境に委任される。
＜００６６＞
コントロールＶＭの好ましい実施形態の幾つかの基本要素を次で説明する。
＜００６７＞
実行モデル
＜００６８＞
コントロールＶＭは、メモリ内にロードされたバイトコードのストリームとしてコードモジュールに格納されている命令を実行する。このＶＭは、命令が実行されるにつれて増分されるプログラムカウンタ（ＰＣ）と呼ばれる仮想レジスタを維持する。ＶＭは、ＯＰ＿ＳＴＯＰ命令が発生するまで、ＯＰ＿ＲＥＴ命令が空のコールスタックに遭遇するまで、または、例外が生じるまで、各命令を逐次的に実行する。ジャンプが、（ＰＣの現在値からのバイトオフセットとして指定される）相対ジャンプとして、または、絶対アドレスとして指定される。
＜００６９＞
メモリモデル
＜００７０＞
好ましい実施形態では、コントロールＶＭは比較的単純なメモリモデルを有する。ＶＭメモリはデータセグメント（ＤＳ）とコードセグメント（ＣＳ）とに分けられる。データセグメントは、アドレス０で開始する単一のフラットで連続したメモリ空間である。データセグメントは、典型的には、ホストアプリケーションまたはホスト環境のヒープメモリ内に割り当てられたバイトのアレイである。特定のＶＭインプリメンテーションの場合に、メモリ空間のサイズが最大に固定されることが好ましく、および、メモリ空間の外側のメモリにアクセスを試みることが、誤りの原因となってプログラムの実行を終了させるだろう。データセグメントは、ＶＭによって同時にロードされる幾つかのコードモジュールの間で潜在的に共用される。データセグメント内のメモリは、３２ビットアクセスまたは８ビットアクセスであることが可能なメモリアクセス命令によってアクセスされることが可能である。３２ビットメモリアクセスは、ビッグエンディアン型のバイト順を使用して行われる。ＶＭ可視メモリとホスト管理メモリ（ホストＣＰＵの仮想または物理メモリ）との間の整合に関して仮定は行われない。
＜００７１＞
一実施形態では、コードセグメントは、アドレス０で開始するフラットで連続したメモリ空間である。コードセグメントは、典型的には、ホストアプリケーションまたはホスト環境のヒープメモリ内に割り当てられたバイトのアレイである。
＜００７２＞
好ましい実施形態では、ＶＭは幾つかのコードモジュールをロードしてよく、および、コードモジュールのすべてが同一のデータセグメントを共用してよい（各モジュールのデータが異なったアドレスにロードされることが好ましい）が、各々がそれ自体のコードセグメントを有する（例えば、１つのコードモジュールからのジャンプ命令が別のコードモジュール内のコードに対する直接的なジャンプを引き起こすことが不可能であることが好ましい）。
＜００７３＞
データスタック
＜００７４＞
好ましい実施形態では、ＶＭが、データセグメント内に格納された３２ビットデータセルを表すデータスタックの観念を有する。ＶＭは仮想レジスタコール、スタックポインタ（ＳＰ）を維持する。リセット後に、ＳＰはデータセグメントの末端をポイントし、および、スタックが下方に成長する（データがデータスタック上にプッシュされる時に、ＳＰレジスタが減分される）。スタック上の３２ビット値が、スタックデータを参照する命令に応じて、３２ビットアドレス整数または３２ビット符号付き整数に翻訳される。
＜００７５＞
コールスタック
＜００７６＞
好ましい実施形態では、ネストされたサブルーチン呼出しを行うために、ＶＭがコールスタックを管理する。このスタックにプッシュされる値は、メモリアクセス命令によって直接的に読み出し／書き込みされることが不可能であるが、ＯＰ＿ＪＳＲおよびＯＲ＿ＲＥＴ命令を実行する時にＶＭによって間接的に使用される。特定のＶＭプロファイルの場合に、この戻りアドレススタックのサイズが最大に固定されることが好ましく、このことが、超過不可能な特定の数のネストされたコールを可能にする。
＜００７７＞
命令セット
＜００７８＞
好ましい実施形態では、コントロールＶＭが非常に単純な命令セットを使用する。しかし、限定された数の命令によってさえ、依然として単純なプログラムを表現することが可能である。好ましい実施形態では、命令セットがスタックベースである。ＯＰ＿ＰＵＳＨ命令を除いて、命令はどれも直接のオペランドを持たない。オペランドはデータスタックから読み出され、および、結果がデータスタック上にプッシュされる。好ましい実施形態では、ＶＭは３２ビットＶＭである。すべての命令が、メモリアドレスまたは符号付き整数を表す３２ビットスタックオペランド上で動作する。符号付き整数は、２の補数バイナリ符号化を使用して表される。
＜００７９＞
好ましい実施形態で使用される典型的な命令セットを次に示す。
＜００８０＞
モジュールフォーマット
＜００８１＞
好ましい実施形態では、コードモジュールが、ＭＰＥＧ−４ファイルフォーマットで使用されるＡｔｏｍ構造と基本的に同等であるＡｔｏｍベースのフォーマットで格納される。１つのａｔｏｍは、ビッグエンディアン型のバイト順の４オクテットとして格納された３２ビットと、この後に続く４オクテットタイプ（一般的には、アルファベット文字のＡＳＣＩＩ値に対応するオクテット）と、この後に続くＡｔｏｍのペイロード（サイズ８オクテット）とから成る。
＜００８２＞
例示的なコードモジュールを図６に示し、および、次で説明する。
＜００８３＞
ｐｋＣＭ  Ａｔｏｍ：ｐｋＣＭ  Ａｔｏｍは最上位レベルのコードモジュールＡｔｏｍである。これはサブアトムのシーケンスを含む。
＜００８４＞
ｐｋＤＳ  Ａｔｏｍ：ｐｋＤＳ  Ａｔｏｍは、データセグメント内にロードされることが可能なメモリイメージを含む。このＡｔｏｍのペイロードはオクテット値の生シーケンスである。
＜００８５＞
ｐｋＣＳ  Ａｔｏｍ：ｐｋＣＳ  Ａｔｏｍは、コードセグメント内にロードされることが可能なメモリイメージを含む。このＡｔｏｍのペイロードはオクテット値の生シーケンスである。
＜００８６＞
ｐｋＥＸ  Ａｔｏｍ：ｐｋＥＸ  Ａｔｏｍはエクスポートエントリのリストを含む。各エクスポートエントリは、８ビットのネームサイズと、これに続く終端ゼロを含む名前の文字として符号化された名前と、これに続く名前が付けられたエントリポイントのバイトオフセット（これは、ｐｋＣＳ  Ａｔｏｍ内に格納されているデータの先頭からのオフセットである）を表す３２ビット整数とから成る。
＜００８７＞
モジュールローダ
＜００８８＞
好ましい実施形態では、コントロールＶＭはコードモジュールをロードする責務を有する。コードモジュールがロードされると、ｐｋＤＳ  Ａｔｏｍ内の符号化されたメモリイメージがデータセグメント内のメモリアドレスにロードされる。このアドレスはＶＭローダによって選択され、および、ＤＳ疑似レジスタ内に格納される。ｐｋＣＳ  Ａｔｏｍ内の符号化されたメモリイメージがコードセグメント内のメモリアドレスにロードされる。このアドレスはＶＭローダによって選択され、および、ＣＳ疑似レジスタ内に格納される。
＜００８９＞
システムコール
＜００９０＞
コントロールＶＭプログラムがそのコードモジュールのコードセグメントの外側でインプリメントされる機能を呼び出すことが可能である。これは、呼出しのためにシステムコール番号を指定する整数スタックオペランドをとるＯＰ＿ＣＡＬＬ命令の使用によって行われる。システムコールに応じて、このインプリメンテーションが、ＶＭのネイティブなインプリメンテーションフォーマットにおける直接的にＶＭによる、または、ＶＭのホスト環境のような外部ソフトウェアモジュールに委任された、異なったコードモジュール（例えば、効用関数のライブラリ）のコントロールＶＭバイトコードルーチンであることが可能である。
＜００９１＞
好ましい実施形態では、次の指定される幾つかのシステムコール数がある。
＜００９２＞
ＳＹＳ＿ＮＯＰ＝０：この呼出しは非操作的な呼出しである。これは単に戻すだけである（他に何もしない）。これは主としてＶＭを試験するために使用される。
＜００９３＞
ＳＹＳ＿ＤＥＢＵＧ＿ＰＲＩＮＴ＝１：テキストの文字列をデバッグ出力にプリントする。この呼出しは、プリントすべきナル終了文字列を含む記憶場所のアドレスを指定する単一のスタック引数を求める。
＜００９４＞
ＳＹＳ＿ＦＩＮＤ＿ＳＹＳＣＡＬＬ＿ＢＹ＿ＮＡＭＥ＝２：ＶＭが名前付きのシステムコールをインプリメントするかどうかを決定する。そうである場合には、システムコール数がスタック上に戻され、そうではない場合には、値「−１」が戻される。この呼出しは、要求されているナル終了システムコール名を含む記憶場所のアドレスを指定する単一のスタック引数を求める。
＜００９５＞
システムコール数アロケーション
＜００９６＞
好ましい実施形態では、コントロールＶＭが、必須システムコール（ＶＭの全プロファイルによってインプリメントされなければならないシステムコール）のためにシステムコール数０−１０２３を予約する。
＜００９７＞
システムコール数１６３８４−３２７６７が、ＶＭが動的に割り当てるために利用可能である（例えば、ＳＹＳ＿ＦＩＮＤ＿ＳＹＳＣＡＬＬ＿ＢＹ＿ＮＡＭＥによって戻されるシステムコール数がＶＭによって動的に割り当てられることが可能であり、および、全ＶＭインプリメンテーション上で同一の数である必要はない）。
＜００９８＞
標準システムコール
＜００９９＞
好ましい実施形態では、幾つかの標準システムコールが、コントロールプログラムを記述することを容易にするために提供される。こうした標準システムコールは、ホストからタイムスタンプを得るための呼出し、ノードが到達可能であるかどうかを判定するための呼出し、および／または、これらの類似物を含んでもよい。システムコールが動的に決定された数を有することが好ましい（例えば、そのシステムコール数が、引数として渡された名前を有するＳＹＳ＿ＦＩＮＤ＿ＳＹＳＣＡＬＬ＿ＢＹ＿ＮＡＭＥシステムコールを呼び出すことによって探索されることが可能である）。
＜０１００＞
リンク、ルール、および、コンテント暗号化
＜０１０１＞
ＤＲＭエンジンおよび／またはシステムの好ましい実施形態におけるプリンシパル、グループ、ルール、表明、および、鍵管理の間の関係に関する追加情報を次で提供する。
＜０１０２＞
リンクおよびノード
＜０１０３＞
上述したように、ＤＲＭシステムは、ノードとリンクとのセットを有するものとして概念化されることが可能である。ノードは異なったエンティティを表すことが可能であるが、典型的には（幾つかのグループが１つだけの自己識別である）自己識別のグループを表し、および、リンクによって連結されることが可能である。リンクは、ノードがリンクさせられているノードによって表されるグループにそのノードが「属する」という表明と見なされることが可能である。
＜０１０４＞
リンクは、典型的には、ポリシーの統治下におけるユーザおよび／またはＤＲＭエンジンクリエータ以外のエンティティによって行われる表明である。この表明がどのように行われ統治されるかは、任意の適切な仕方で行われることが可能である。しかし、リンクが信用できることが好ましい。実際には、これは、一般的に、そのリンクに基づいて判断を行うことが必要なシステムの一部分が、信用できる仕方でそうすることが可能であるように、リンクが存在するという表明の表現が署名されるだろうということを意味するだろう。
＜０１０５＞
ノード間のリンクの存在によって含意される関係は過渡的である。リンクが、ノードのグラフ中の有向辺によって表されることが可能であり、および、そのグラフ中のノードＮａとグループノードＮｘとの間に有向の経路が存在するならば、ノードＮａはグループノードＮｘに属すると言い表すことが可能である。
＜０１０６＞
次のパラグラフは、ルール条件を表現するために、および、暗号化鍵を管理するために、これらのノードのグラフがどのように使用されることが可能であるかを説明する。
＜０１０７＞
ルールおよびメンバシップ条件
＜０１０８＞
このシステムは、特定の要求されたアクション（または意図）が許可されるか否か、および、そうである場合には、結果および／または義務が何であるかを決定するコントロールプログラムとして表現されたルールを通して、コンテントを統治するために使用されることが可能である。好ましい実施形態では、ルールは、入力として幾つかのパラメータ（例えば、コンテント識別情報、時間／日付、特定のカウンタの値、アクションを要求するプリンシパルのＩＤ等）をとり、かつ、特定のアクションが生じることを可能にするかどうかを判定する、小さなコントロールプログラムである。アクションが発生することが許可される場合には、このプログラムは、さらに、ルールの規定された義務（例えば、カウンタの更新）も行うことが可能である。特定の実施形態では、そのプログラムが取り扱うことが可能な入力と出力のタイプが比較的に制限されてよい。
＜０１０９＞
ルールが、アクションを行うことが可能なプリンシパルのための条件が、（例えば、「プリンシパルがこのコンテントのサブスクライバのグループのメンバである場合に、そのプリンシパルがこのコンテントを再生することが可能である」というようなルールを表現するために）各経路毎に１つずつターゲットノードまたはターゲットノードのセットに対してアクションを要求するプリンシパルを表すノードからの経路（または経路のセット）の存在であるということを表現することが可能である。２つのノードＮａ、Ｎｂの間のリンクが、Ｎｂによって表されるグループにＮａが属するということの信用できる表明である。このルールの執行の時点で（例えば、ルールプログラムが実行中である場合に）、すべての要求されたターゲットノードに対してグラフを横断するために必要なすべてのリンクを得ることが可能である場合には、その条件が満たされる。このノードのグラフは、メンバシップグラフと呼ばれることがあるだろうし、および、そのグラフのリンクがメンバシップリンクと呼ばれることがあるだろう。
＜０１１０＞
コンテント暗号化
＜０１１１＞
このシステムと共に機能するように設計されている準拠要素が、保護されたコンテント部品に対してその準拠要素がアクションを行うことを望む時に、適切なルールを理解し執行することが可能だろう。しかし、非準拠システムが、一般的に、この仕方でコンテントを使用するために信用されることが不可能である。したがって、暗号技術を使用してコンテントを保護することが望ましい。好ましい実施形態では、典型的には保護されるコンテントに固有であるコンテント鍵Ｋｃによって、コンテントが暗号化される。プリンシパルがコンテントに対してアクションを行うことを望む時には、そのプリンシパルは最初にルールプログラムを実行し、および、ｙｅｓ／ｎｏの回答を得るだろう。プリンシパルがそのアクションを行うことをルールが許可する場合には、そのプリンシパルはコンテント鍵Ｋｃを得ることを必要とするだろう。好ましい実施形態では、ルールシステムと、ノード／リンクグラフと、Ｋｃを要求ノードに対して明示的に「ターゲットにする」外部エンティティなしにプリンシパルが効率的な仕方でコンテント鍵を得ることを可能にするコンテント保護システムとの間に関係が存在する。
＜０１１２＞
好ましい実施形態では、これは、ノードのグラフとしてプリンシパル／オブジェクト間の関係を概念化することによって実現される。幾つかのノードがメンバシップグラフで使用されるノードと同じノードであってよいが、これは必ずしも必要ではない。しかし、単純なシステムでは、このグラフがメンバシップグラフのサブセットであることが求められる。このグラフは保護グラフと呼ばれるだろう。
＜０１１３＞
このシステムの各ノードＮは、他の属性の中で特に、関連したコンテント保護鍵Ｋｃ［Ｎ］または鍵対を有することが可能である。他の属性が、署名を行うための、および、ノードに対して情報を潜在的にターゲットするための公開／プライベート鍵対を含んでもよい。例示のために、次の例が単一の鍵の使用を示すが、しかし、同一の原理が鍵対に関しても有効であるということを理解されたい。このグラフでは、２つのノードＮａ、Ｎｂの間のリンクが、Ｋｃ［Ｎａ］を有する者は誰でもＫｃ［Ｎｂ］を計算することが可能であるという信用できる表明である。典型的には、このことは、そのリンクが、Ｋｃ［Ｎａ］によって暗号化されたＫｃ［Ｎｂ］の表現を含むだろうということを意味する。このことは、ノード間のリンクを連鎖させることと、ターゲットノードのＫｃを計算することとを可能にする。
＜０１１４＞
鍵に対する経路を生成するために使用されるグラフが、メンバシップ条件を表現するために使用されるグラフとは違っていてもよいが、単純な例では、同じグラフとリンクとが再使用されることが可能であり、したがって、ノードグラフの「並列の」または別の使用を生じさせる。この場合には、ルールの条件を検査するために横断させられた同一の経路が、コンテント保護鍵を計算するために横断させられる。Ｎａに対するＫｃ［Ｎｂ］の明示的なターゲティングがこれまでに行われていない場合にさえ、ノードＮｂに到達するために辿られることが可能なリンクに対するアクセス権を有するあらゆるノードＮａが、Ｋｃ［Ｎｂ］を計算することが可能である。
＜０１１５＞
これらの鍵は、典型的に、次の仕方で使用されるだろう。コンテントＣｉはコンテント鍵Ｋ［Ｃｉ］で暗号化される。１つまたは複数のルールが生成されることが可能であり、このルールは、特に、アクションを要求するノードと、グループを表す「条件」ターゲットノードのリストとの間の経路の存在を検査する。この１つまたは複数のルールは、条件（および、恐らくは、さらに義務の副作用）の検査を行うプログラムと、要求ノードが属さなければならないノードのＫｃ［Ｎｉ］ノードコンテント暗号化鍵の各々を使用した連続的な暗号化によって保護されたＫ［Ｃｉ］のコピーとを含んでよい。
＜０１１６＞
ノードＮａがコンテントＣｉに対するアクションを行うことを望む時には、このノードＮａは、そのアクションのためにそのコンテントを統治するルールプログラムを実行するだろう。このルールが、１つまたは複数のグループＮｐ、Ｎｑ等におけるＮａのメンバシップを要求する場合には、このルールは、Ｎｐ、Ｎｑ等に対する必要なリンクが存在することを検査し、および、アクションが許可されるか否かに関する判定を生じさせるだろう。そのアクションが許可される場合には、システムが、ルール中でそのコンテント鍵の暗号化されたコピーが発見されることが可能であるコンテント鍵Ｋ［Ｃｉ］を得るために逐次的に使用される必要があるコンテント保護鍵Ｋｃ［Ｎｍ］、Ｋｃ［Ｎｎ］等を有するノードＮｍ、Ｎｎ等に対する、保護グラフにおける１組のリンクを、そのシステムが有するかどうかを判定するだろう。Ｋ［Ｃｉ］は、コンテント鍵のための保護メタデータによって指定された順序で、ノードのコンテント暗号化鍵Ｋｃ［Ｎｍ］、Ｋｃ［Ｎｎ］等によって、この暗号化されたコンテント鍵を暗号解読することによって得られるだろう。この場合も同様に、単純なシステムでは、ノードＮｐ、Ｎｑ等のセットがＮｍ、Ｎｎ等と同じであることが多いだろう。
＜０１１７＞
図７は、ノードグラフの二重の使用を示す例示的なシナリオを図示する。図７を参照すると、ｉＰｏｄ１がコンテント再生デバイスである。Ｎｉｐ１がこのデバイスを表すノードである。Ｋｉｐ１がＮｉｐ１に関連付けられているコンテント暗号化鍵である。ジル（Ｇｉｌｌｅｓ）がｉＰｏｄ１の所有者であり、Ｎｇがジルを表すノードである。ＫｇがＮｇに関連付けられているコンテント暗号化鍵である。
＜０１１８＞
ＰｕｂＬｉｂが公立図書館である。Ｎｐｌがこの図書館のメンバを表し、および、Ｋｐ１がＮｐｌに関連付けられているコンテント暗号化鍵である。ＡＣＭＥがすべてのＡＣＭＥ製造のミュージックプレイヤを表す。Ｎａｍｐがデバイスのクラスを表し、および、Ｋａｍｐがこのグループに関連付けられているコンテント暗号化鍵を表す。
＜０１１９＞
Ｌ１がＮｉｐ１からＮｇへのリンクであり、このことはｉＰｏｄ１がジルに属していることを意味する。Ｌ２がＮｇからＮｐｌへのリンクであり、このことがジルが公立図書館のメンバであることを意味する。Ｌ３がＮｉｐ１からＮａｍｐへのリンクであり、このことがｉＰｏｄ１がＡＣＭＥデバイスであることを意味する。
＜０１２０＞
Ｃ１が、公立図書館がそのメンバに対して利用可能にする映画ファイルである。Ｋｃ１が、Ｃ１を暗号化するために使用される鍵である。ＧＢ［Ｃ１］がＣ１に関する統治情報（例えば、コンテントに対するアクセス権を統治するために使用されるルールと関連情報）である。Ｅ（ａ，ｂ）が、鍵「ａ」によって暗号化された「ｂ」を意味する。
＜０１２１＞
例示のために、（ａ）そのデバイスが図書館のメンバである誰かに属し、かつ、（ｂ）そのデバイスがＡＣＭＥによって製造されている限り、そのデバイスがコンテントＣ１を再生することが可能であるということを述べるルールを設定することが望ましいと仮定する。
＜０１２２＞
コンテントＣ１がＫｃｌによって暗号化される。ルールプログラムが生成され、および、暗号化されたコンテント鍵ＲＫ［Ｃ１］＝Ｅ（Ｋａｍｐ，Ｅ（Ｋｐｌ，Ｋｃｌ））が生成される。ルールプログラムとＲＫ［Ｃ１］の両方が、コンテントＧＢ［Ｃ１］のための統治ブロックに含まれることが可能である。
＜０１２３＞
ｉＰｏｄ１はＣ１とＧＢ［Ｃ１］とを受け取る。例えば、この両方が同一のファイルの形でパッケージされてもよく、または、別々に受け取られてもよい。ジルが自分のデバイスを購入した後で最初にそのデバイスをインストールした時に、ｉＰｏｄ１はＬ１を受け取った。ジルが自分のサブスクリプション料金を公立図書館に支払った時に、ｉＰｏｄ１はＬ２を受け取った。ｉＰｏｄ１は、それが製造された時にＬ３を受け取った（例えば、Ｌ３が組み込み済みだった）。
＜０１２４＞
Ｌ１、Ｌ２、および、Ｌ３から、ｉＰｏｄ１は、Ｎｉｐ１がＮｇ（Ｌ１）とＮｐｌ（Ｌ１＋Ｌ２）とＮａｍｐ（Ｌ３）とに対するグラフ経路（ｇｒａｐｈ  ｐａｔｈ）を有することを検査することが可能である。ｉＰｏｄ１はＣ１を再生することを望む。ｉＰｏｄ１は、ＧＢ［Ｃ１］で発見されたルールを実行する。このルールは、Ｎｉｐ１が実際にＡＣＭＥデバイスであり（Ｎａｍｐへの経路）、かつ、公立図書館のメンバに属する（Ｎｐｌへの経路）ということを検査することが可能である。したがって、このルールは、「ｙｅｓ」と、順序付けられたリスト（Ｎａｍｐ，Ｎｐｌ）とを戻す。
＜０１２５＞
ｉＰｏｄ１は、Ｋｇを計算するためにＬ１を使用し、その次に、ＫｇからＫｐｌを計算するためにＬ２を使用する。さらに、ｉＰｏｄ１は、Ｋａｍｐを計算するためにＬ３を使用する。ｉＰｏｄ１は、ＫｐｌとＫａｍｐを、ＧＢ［Ｃ１］で発見されたＲＫ［Ｃ１］に適用し、および、Ｋｃ１を計算する。その次に、ｉＰｏｄ１は、Ｃ１を暗号解読して再生するためにＫｃ１を使用する。
＜０１２６＞
上述の実施形態と同様にノード鍵が対称鍵である場合には、コンテントパッケージャが、それがコンテントを「バインド」しようと望むノードの鍵に対してアクセス権を有することが必要である。これは、パッケージャを表すノードと、そのノードとそのパッケージャがルールをそのノードに対してバインドしようと望むノードとの間のリンクとを生成することによって実現されることが可能である。これは、さらに、例えば、サービスによって「アウトオブバンド（ｏｕｔ  ｏｆ  ｂａｎｄ）」で実現されることも可能である。しかし、状況によっては、対称鍵を使用することが可能ではなく、または、実際的ではないことがある。その場合には、共用された知識なしに、そのノードとのバインディングが必要とされるノードに対して鍵対を割り当てることが可能である。その場合には、パッケージャは、ターゲットノードの公開鍵によってコンテント鍵を暗号化することによって、コンテント鍵をノードにバインドするだろう。暗号解読のための鍵を得るために、クライアントが、そのノードに対するリンクによってそのノードのプライベート鍵に対するアクセス権を有するだろう。
＜０１２７＞
最も一般的な場合には、ルールのために使用されるノードと、コンテント暗号化鍵を計算するために使用されるノードとが、必ずしも同一である必要はない。コンテントを統治するルールとコンテントを暗号化するために使用される鍵との間に強力な関係が存在するので、同一のノードを使用することが自然であるが、このことは必ずしも必要であるわけではない。特定のシステムでは、幾つかのノードが、メンバシップ条件を表現するために使用されないコンテント保護鍵のために使用されてよく、および、これとは逆であってよく、および、状況によっては、１つのグラフがルールに関するものであり、かつ、１つのグラフがコンテント保護に関するものである、２つの互いに異なった２つのノードグラフが使用されることが可能である。例えば、ルールが、グループＮｐｌの全メンバがコンテントＣ１に対するアクセス権を有することが可能であるが、コンテント鍵Ｋｃ１がＫｐｌによって保護されなくてもよいが、その代わりに、Ｎｐ１だけでなく、すべての公共図書館を表すノードＮｆのノード鍵Ｋｆによって保護されてもよいと命じることが可能である。または、ルールが、あなたがＮａｍｐのメンバである必要があるが、コンテント暗号化鍵がＮｐ１だけにバインドされることが可能であると命じることが可能である。
＜０１２８＞
理解しやすいように、上述の内容をある程度詳細に説明してきたが、本発明の原理から逸脱することなしに特定の変更と変型とを加えてよいということが明らかだろう。本発明のプロセスと機器の両方を実現する数多くの代案の方法が存在するということに留意されたい。したがって、これらの実施形態は例示的でかつ非限定的であると見なされるべきであり、および、本発明はここで示されている特定の詳細事項に限定されない。
【０５１３】
【表１８】
2014146345.tif 000020
【０５１４】
【表１９】
2014146345.tif 000021
【０５１５】
【表２０】
2014146345.tif 000022
【０５１６】
【表２１】
2014146345.tif 000023
【０５１７】
【表２２】
2014146345.tif 000024
【０５１８】
【表２３】
2014146345.tif 000025
【０５１９】
【表２４】
2014146345.tif 000026
【０５２０】
＜付記Ｃ＞
【０５２１】
【表２５】
2014146345.tif 000027
【０５２２】
【表２６】
2014146345.tif 000028
【０５２３】
【表２７】
2014146345.tif 000029
【０５２４】
【表２８】
2014146345.tif 000030
【０５２５】
【表２９】
2014146345.tif 000031
【０５２６】
【表３０】
2014146345.tif 000032
【０５２７】
【表３１】
2014146345.tif 000033
【０５２８】
【表３２】
2014146345.tif 000034
【０５２９】
【表３３】
2014146345.tif 000035
【０５３０】
【表３４】
2014146345.tif 000036
【０５３１】
【表３５】
2014146345.tif 000037
【０５３２】
【表３６】
2014146345.tif 000038
【０５３３】
【表３７】
2014146345.tif 000039
【０５３４】
【表３８】
2014146345.tif 000040
【０５３５】
【表３９】
2014146345.tif 000041
【０５３６】
【表４０】
2014146345.tif 000042
【０５３７】
【表４１】
2014146345.tif 000043
【０５３８】
【表４２】
2014146345.tif 000044
【０５３９】
【表４３】
2014146345.tif 000045
【０５４０】
【表４４】
2014146345.tif 000046
【０５４１】
【表４５】
2014146345.tif 000047
【０５４２】
【表４６】
2014146345.tif 000048
【０５４３】
【表４７】
2014146345.tif 000049
【０５４４】
【表４８】
2014146345.tif 000050
【０５４５】
【表４９】
2014146345.tif 000051
【０５４６】
【表５０】
2014146345.tif 000052
【０５４７】
【表５１】
2014146345.tif 000053
【０５４８】
【表５２】
2014146345.tif 000054
【０５４９】
【表５３】
2014146345.tif 000055
【０５５０】
【表５４】
2014146345.tif 000056
【０５５１】
【表５５】
2014146345.tif 000057
【０５５２】
【表５６】
2014146345.tif 000058
【０５５３】
【表５７】
2014146345.tif 000059
【０５５４】
【表５８】
2014146345.tif 000060
【０５５５】
【表５９】
2014146345.tif 000061
【０５５６】
【表６０】
2014146345.tif 000062
【０５５７】
【表６１】
2014146345.tif 000063
【０５５８】
【表６２】
2014146345.tif 000064
【０５５９】
【表６３】
2014146345.tif 000065
【０５６０】
【表６４】
2014146345.tif 000066
【０５６１】
【表６５】
2014146345.tif 000067
【０５６２】
【表６６】
2014146345.tif 000068
【図１】
2014146345.tif 000069
【図２Ａ】
2014146345.tif 000070
【図２Ｂ】
2014146345.tif 000071
【図２Ｃ】
2014146345.tif 000072
【図２Ｄ】
2014146345.tif 000073
【図２Ｅ】
2014146345.tif 000074
【図２Ｆ】
2014146345.tif 000075
【図３】
2014146345.tif 000076
【図４】
2014146345.tif 000077
【図５Ａ】
2014146345.tif 000078
【図５Ｂ】
2014146345.tif 000079
【図６Ａ】
2014146345.tif 000080
【図６Ｂ】
2014146345.tif 000081
【図７Ａ】
2014146345.tif 000082
【図７Ｂ】
2014146345.tif 000083
【図７Ｃ】
2014146345.tif 000084
【図７Ｄ】
2014146345.tif 000085
【図７Ｅ】
2014146345.tif 000086
【図８】
2014146345.tif 000087
【図９Ａ】
2014146345.tif 000088
【図９Ｂ】
2014146345.tif 000089
【図９Ｃ】
2014146345.tif 000090
【図９Ｄ】
2014146345.tif 000091
【図１０】
2014146345.tif 000092
【図１１】
2014146345.tif 000093
【図１２Ａ】
2014146345.tif 000094
【図１２Ｂ】
2014146345.tif 000095
【図１３】
2014146345.tif 000096
【図１４】
2014146345.tif 000097
【図１５】
2014146345.tif 000098
【図１６】
2014146345.tif 000099
【図１７Ａ】
2014146345.tif 000100
【図１７Ｂ】
2014146345.tif 000101
【図１８Ａ】
2014146345.tif 000102
【図１８Ｂ】
2014146345.tif 000103
【図１８Ｃ】
2014146345.tif 000104
【図１９Ａ】
2014146345.tif 000105
【図１９Ｂ】
2014146345.tif 000106
【図１９Ｃ】
2014146345.tif 000107
【図２０】
2014146345.tif 000108
【図２１】
2014146345.tif 000109
【図２２】
2014146345.tif 000110
【図２３】
2014146345.tif 000111
【図２４】
2014146345.tif 000112
【手続補正書】
【提出日】平成26年3月4日(2014.3.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
暗号化されたデジタル・コンテンツへのアクセスを可能にする暗号鍵を配送する方法であって、
複数のリンク・オブジェクトをつくるステップであって、各リンク・オブジェクトが、少なくとも２つのノードの間の論理的関係を表し、各リンク・オブジェクトが、少なくとも２つのノードを識別する情報を含み、各リンク・オブジェクトが、さらに、鍵導出情報であって、該鍵導出情報は、他のリンク・オブジェクトに含まれる鍵導出情報と結合して、デジタル・コンテンツへのアクセスまたはアクセスする権利を得るのに使用する復号化鍵を得るのに使用される、鍵導出情報を含む、ステップと、
前記復号化鍵を第１のノードに向けるステップと、
前記複数のリンク・オブジェクトを、第１のノードに配送するステップであって、該複数のリンク・オブジェクトは、前記第２のノードを前記第１のノードに論理的に接続し、前記鍵導出情報は、前記第２のノードに結合したコンピュータ・システムのメモリに格納された少なくとも１つの暗号鍵と組み合わせて、該複数のリンク・オブジェクトに含まれ、前記第２のノードが前記復号化鍵を得るのを可能にする、ステップと、を含む方法。
【請求項２】
前記復号化鍵を得るために、また、１つ以上の関連するコントロール・オブジェクトにしたがって、前記デジタル・コンテンツへのアクセスを得るために、前記複数のリンク・オブジェクトを処理するのにデジタル権利管理エンジンを実行するステップをさらに含む請求項１に記載の方法。
【請求項３】
少なくとも１つのリンク・オブジェクトに結びついたデジタル署名を検証するステップをさらに含む請求項１又は２に記載の方法。
【請求項４】
少なくとも１つのリンク・オブジェクトに署名するのに用いられる鍵と結合した証明書を検証するステップであって、該鍵が少なくとも１つのリンク・オブジェクトに署名することが認証されたか否かを判定する、ステップをさらに含む請求項３に記載の方法。
【請求項５】
複数のリンク・オブジェクトを受信するステップであって、各リンク・オブジェクトが、少なくとも２つのノードを識別するノード識別情報を含み、各リンク・オブジェクトが、さらに、鍵導出情報であって、該鍵導出情報は少なくとも１つの暗号化された暗号鍵を含む、鍵導出情報を含む、ステップと、
暗号化された第１の暗号鍵を復号化するためにローカルに格納された暗号鍵を使用するステップであって、該暗号化された第１の暗号鍵は第１のリンク・オブジェクトに含まれる、ステップと、
暗号化された第２の暗号鍵を復号化するために前記第１の暗号鍵を使用するステップであって、該暗号化された第２の暗号鍵は第２のリンク・オブジェクトに含まれる、ステップと、を含む方法。
【請求項６】
暗号化された第３の暗号鍵を復号化するために前記第２の暗号鍵を使用するステップであって、該暗号化された第３の暗号鍵は第３のリンク・オブジェクトに含まれる、ステップをさらに含む請求項５に記載の方法。
【請求項７】
電子コンテンツの部分、および／または、それに対する権利を制御しているオブジェクトを復号化するために、前記第３の暗号鍵を使用するステップをさらに含む請求項６に記載の方法。
【請求項８】
電子コンテンツの部分、および／または、それに対する権利を制御しているオブジェクトを復号化するために、前記第２の暗号鍵を使用するステップをさらに含む請求項５に記載の方法。
【請求項９】
電子コンテンツの部分にアクセスする要求をユーザから受信するステップと、
前記要求が許されるか否かを判定するためにデジタル権利管理エンジンを使用するステップであって、該ステップは、第１のエンティティと結びついた第２のノード・オブジェクトは、第２のエンティティと結びついた第２のノード・オブジェクトから到達可能であるか否かを判定するために、少なくとも前記第１のリンク・オブジェクトと前記第２のリンク・オブジェクトとを評価することを含む、ステップと、をさらに含む請求項５に記載の方法。
【請求項１０】
暗号鍵を配送するためのシステムであって、
複数のリンク・オブジェクトをつくる手段であって、各リンク・オブジェクトが、少なくとも２つのノードの間の論理的関係を表し、各リンク・オブジェクトが、少なくとも２つのノードを識別する情報を含み、各リンク・オブジェクトが、さらに、鍵導出情報であって、該鍵導出情報は、他のリンク・オブジェクトに含まれる鍵導出情報と結合して、デジタル・コンテンツへのアクセスまたはアクセスする権利を得るのに使用する復号化鍵を得るのに使用される、鍵導出情報を含む、手段と、
前記復号化鍵を第１のノードに向ける手段と、
前記複数のリンク・オブジェクトを、第１のノードに配送する手段であって、該複数のリンク・オブジェクトは、前記第２のノードを前記第１のノードに論理的に接続し、前記鍵導出情報は、前記第２のノードに結合したコンピュータ・システムのメモリに格納された少なくとも１つの暗号鍵と組み合わせて、該複数のリンク・オブジェクトに含まれ、前記第２のノードが前記復号化鍵を得るのを可能にする、手段と、を備えるシステム。
【請求項１１】
前記復号化鍵を得るために、また、１つ以上の関連するコントロール・オブジェクトにしたがって、前記デジタル・コンテンツへのアクセスを得るために、前記複数のリンク・オブジェクトを処理するのにデジタル権利管理エンジンを実行する手段をさらに含む請求項１０に記載のシステム。
【請求項１２】
複数のリンク・オブジェクトを受信する手段であって、各リンク・オブジェクトが、少なくとも２つのノードを識別するノード識別情報を含み、各リンク・オブジェクトが、さらに、鍵導出情報であって、該鍵導出情報は少なくとも１つの暗号化された暗号鍵を含む、鍵導出情報を含む、手段と、
暗号化された第１の暗号鍵を復号化するためにローカルに格納された暗号鍵を使用する手段であって、該暗号化された第１の暗号鍵は第１のリンク・オブジェクトに含まれる、手段と、
暗号化された第２の暗号鍵を復号化するために前記第１の暗号鍵を使用する手段であって、該暗号化された第２の暗号鍵は第２のリンク・オブジェクトに含まれる、手段と、を備えるシステム。
【請求項１３】
暗号化された第３の暗号鍵を復号化するために前記第２の暗号鍵を使用する手段であって、該暗号化された第３の暗号鍵は第３のリンク・オブジェクトに含まれる、手段をさらに備える請求項１２に記載のシステム。
【請求項１４】
電子コンテンツの部分にアクセスする要求をユーザから受信する手段と、
前記要求が許されるか否かを判定するためにデジタル権利管理エンジンを使用する手段であって、該手段は、第１のエンティティと結びついた第２のノード・オブジェクトは、第２のエンティティと結びついた第２のノード・オブジェクトから到達可能であるか否かを判定するために、少なくとも前記第１のリンク・オブジェクトと前記第２のリンク・オブジェクトとを評価する手段を含む、手段と、をさらに備える請求項１２に記載のシステム。
【請求項１５】
プログラム・コードを備えるコンピュータ可読媒体であって、該プログラム・コードは、コンピュータ・システムで実行されるとき、
該コンピュータ・システムに、複数のリンク・オブジェクトをつくるステップであって、各リンク・オブジェクトが、少なくとも２つのノードの間の論理的関係を表し、各リンク・オブジェクトが、少なくとも２つのノードを識別する情報を含み、各リンク・オブジェクトが、さらに、鍵導出情報であって、該鍵導出情報は、他のリンク・オブジェクトに含まれる鍵導出情報と結合して、デジタル・コンテンツへのアクセスまたはアクセスする権利を得るのに使用する復号化鍵を得るのに使用される、鍵導出情報を含む、ステップと、
前記復号化鍵を第１のノードに向けるステップと、
前記複数のリンク・オブジェクトを、第１のノードに配送するステップであって、該複数のリンク・オブジェクトは、前記第２のノードを前記第１のノードに論理的に接続し、前記鍵導出情報は、前記第２のノードに結合したコンピュータ・システムのメモリに格納された少なくとも１つの暗号鍵と組み合わせて、該複数のリンク・オブジェクトに含まれ、前記第２のノードが前記復号化鍵を得るのを可能にする、ステップと、
のステップを実行させるように動作可能である、コンピュータ可読媒体。
【請求項１６】
前記コンピュータ・システムで実行されるとき、前記コンピュータ・システムに、前記復号化鍵を得るために、１つ以上の関連するコントロール・オブジェクトにしたがって、デジタル・コンテンツへのアクセスを得るために、前記複数のリンク・オブジェクトを処理するのにデジタル権利管理エンジンを実行するステップを実行させるように動作可能であるプログラム・コードをさらに含む請求項１５に記載のコンピュータ可読媒体。
【請求項１７】
前記コンピュータ・システムで実行されるとき、前記コンピュータ・システムに、少なくとも１つのリンク・オブジェクトに結びついたデジタル署名を検証するステップを実行させるように動作可能であるプログラム・コードをさらに含む請求項１５に記載のコンピュータ可読媒体。
【請求項１８】
プログラム・コードを備えるコンピュータ可読媒体であって、該プログラム・コードは、コンピュータ・システムで実行されるとき、該コンピュータ・システムに、
複数のリンク・オブジェクトを得るステップであって、各リンク・オブジェクトが、少なくとも２つのノードを識別するノード識別情報を含み、各リンク・オブジェクトが、さらに、鍵導出情報であって、該鍵導出情報は少なくとも１つの暗号化された暗号鍵を含む、鍵導出情報を含む、ステップと、
暗号化された第１の暗号鍵を復号化するために前記コンピュータ・システムのメモリに格納された暗号鍵を用いるステップであって、該暗号化された第１の暗号鍵は第１のリンク・オブジェクトに含まれる、ステップと、
暗号化された第２の暗号鍵を復号化するために前記第１の暗号鍵を使用するステップであって、該暗号化された第２の暗号鍵は第２のリンク・オブジェクトに含まれる、ステップと、
のステップを実行させるように動作可能である、コンピュータ可読媒体。
【請求項１９】
前記コンピュータ・システムで実行されるとき、前記コンピュータ・システムに、電子コンテンツの部分、および／または、それに対する権利を制御しているオブジェクトを復号化するために、前記第２の暗号鍵を使用するステップを実行させるように動作可能であるプログラム・コードをさらに含む請求項１８に記載のコンピュータ可読媒体。
【請求項２０】
前記コンピュータ・システムで実行されるとき、該コンピュータ・システムに、
電子コンテンツの部分にアクセスする要求をユーザから受信するステップと、
前記要求が許されるか否かを判定するために前記コンピュータ・システム上で動作しているデジタル権利管理エンジンを使用するステップであって、該ステップは、第１のエンティティと結びついた第２のノード・オブジェクトは、前記コンピュータ・システム又は前記ユーザと結びついた第２のノード・オブジェクトから到達可能であるか否かを判定するために、少なくとも前記第１のリンク・オブジェクトと前記第２のリンク・オブジェクトとを評価することを含む、ステップと、
のステップを実行させるように動作可能であるプログラム・コードをさらに含む請求項１８に記載のコンピュータ可読媒体。