"分散アプリケーションへの参加を通して値の交換を可能にする十分な相互運用性と共にネットワークピアにより提供される編成サービスのためのシステムにおいて、a.第1発見可能バインディングを介して、ネットワークピアがアクセスできるようにする第1サービスインタフェースを公開する第1サービス適応レイヤを有し、第1サービスを提供する第1サービスプロバイダと、b.前記第1サービスプロバイダにより公開される前記第1サービスインタフェースにアクセスし、前記第1バインディングを発見し、かつ、そのバインディングを用いることにより前記第1サービスを呼び出す第1サービスアクセスポイントを有する第1サービス消費部と、c.前記第1サービスプロバイダに、前記第1サービス消費部のための前記第1サービスを実行できるようにするために必要なステップを編成する第1ワークフロー照合部と、を有するシステム。前記第1サービスは、遠隔インターネットベースサーバに位置する暗号化されたメディアコンテンツへの限定的アクセスを提供し、及び、前記第1ワークフロー照合部は、前記第1サービス消費部が、コンテンツへのアクセスを認証されているかどうかを検証し、そうであるならば、コンテンツの所在位置を突き止め、かつ、前記第1サービス適応レイヤを介して該コンテンツを前記第1サービス消費部に提供する第1制御プログラムを含む請求項1に記載のシステム。前記第1サービスインタフェースは、WSDLで指定される請求項1に記載のシステム。ネットワークピアにより提供されるサービスを編成するシステムにおいて、a.第1発見可能バインディングを介して、ネットワークピアにアクセスすることを可能にする第1サービスインタフェースを公開する第1サービス適応レイヤを有し、第1サービスを提供する第1サービスプロバイダと、b.前記第1サービスプロバイダにより公開される前記第1サービスインタフェースへアクセスし、前記第1バインディングを発見し、かつ、そのバインディングを用いることにより前記第1サービスを呼び出す第1サービスアクセスポイントを有する第1サービス消費部と、c.前記第1サービスプロバイダに、前記第1サービス消費部のための前記第1サービスを実行することを可能にするために必要なステップを編成する第1ワークフロー照合部と、d.第2発見可能バインディングを介して、ネットワークピアにアクセスできるようにする第2サービスインタフェースを公開する第2サービス適応レイヤを有し、前記第1サービスの所在位置を突き止め、かつ、呼び出すための情報と共にディレクトリ項目を有するサービスレジストリへのアクセスを与える第2サービスを提供する第2サービスプロバイダと、を有し、前記第1サービスアクセスポイントは、前記ディレクトリ項目へアクセスを行い、かつ、前記第1サービスの所在位置を突き止め、及び、呼び出すために、前記情報を使用するシステム。前記サービスレジストリは、UDDIレジストリである請求項4に記載のシステム。a.第1発見可能バインディングを介して、ネットワークピアにアクセスできるようにする第1サービスインタフェースを公開する第1サービス適応レイヤを有し、第1サービスを提供する第1サービスプロバイダと、b.前記第1サービスプロバイダにより公開される前記第1サービスインタフェースへアクセスし、前記第1バインディングを発見し、かつ、そのバインディングを用いることにより前記第1サービスを呼び出す第1サービスアクセスポイントを有する第1サービス消費部と、c.第1サービスプロバイダに、前記第1サービス消費部のための前記第1サービスを実行できるために必要なステップを編成する第1ワークフロー照合部と、d.認証された第1サービス消費部のみによるアクセスのための前記第1サービスを保障する信用管理証明書と、e.前記信用管理証明書を用いて前記第1サービスへの限定アクセスを提供する制御プログラムと、を有し、前記第1アクセスポイントは、前記第1サービスへの認証アクセスのための前記第1サービス消費部を検証するために前記信用管理証明書を使用するシステム。前記信用管理証明書は、X.509証明書である請求項6に記載のシステム。前記信用管理証明書は、SSL証明書である請求項6に記載のシステム。分散処理アプリケーションへの参加を介して値の交換を可能にする十分な相互運用性と共にネットワークピアにより提供されるサービスを編成する方法において、a.第1発見可能バインディングを介して、第1サービスを提供する第1サービスプロバイダの第1サービス適応レイヤから、ネットワークピアにアクセスできるようにする第1サービスインタフェースを公開し、b.サービス消費部の第1サービスアクセスポイントから、前記第1サービスプロバイダにより公開される前記第1サービスインタフェースにアクセスし、前記第1バインディングを発見し、及び、そのバインディングを用いることにより前記第1サービスを呼び出し、かつ、c.第1ワークフロー照合部を用いて、前記第1サービスプロバイダに、前記第1サービス消費部のための前記第1サービスを実行できるために必要なステップを編成することを有する方法。第1サービスは、遠隔インターネットベースサーバに位置する暗号化されたメディアコンテンツへの限定アクセスを提供し、かつ、第1ワークフロー照合部は、第1サービス消費部がコンテンツへのアクセスを認証されているかどうかを検証し、そうであるならばコンテンツ所在位置を突き止め、及び、前記第1サービス適応レイヤを介して該コンテンツを前記第1サービス消費部に提供する第1制御プログラムを含む請求項9に記載の記載の方法。前記第1サービスインタフェースは、WSDLで指定される請求項9に記載の方法。a.第1発見可能バインディングを介して、第1サービスを提供する第1サービスプロバイダの第1サービス適応レイヤから、ネットワークピアにアクセスできるようにする第1サービスインタフェースを公開し、b.サービス消費部の第1サービスアクセスポイントから、前記第1サービスプロバイダにより公開される前記第1サービスインタフェースにアクセスし、前記第1バインディングを発見し、及び、そのバインディングを用いることにより前記第1サービスを呼び出し、c.第1ワークフロー照合部を用いて、前記第1サービスプロバイダに、前記第1サービス消費部のための前記第1サービスを実行できるために必要なステップを編成し、d.第2サービスプロバイダの第2適応レイヤから、第2発見可能バインディングを介して、ネットワークピアにアクセスできるようにし、かつ、前記第1サービスの所在位置を突き止め、かつ、アクセスするための情報と共にディレクトリ項目を有するサービスレジストリへのアクセスを与える第2サービスを提供する第2インタフェースを公開することを有し、前記第1サービスアクセスポイントは、ディレクトリ項目にアクセスし、及び、前記第1サービスの所在位置を突き止め、及び、呼び出すために前記情報を使用する方法。前記サービスレジストリは、UDDIレジストリである請求項12に記載の方法。a.第1発見可能バインディングを介して、第1サービスを提供する第1サービスプロバイダの第1サービス適応レイヤから、ネットワークピアにアクセスできるようにする第1サービスインタフェースを公開し、b.サービス消費部の第1サービスアクセスポイントから、前記第1サービスプロバイダにより公開される前記第1サービスインタフェースにアクセスし、前記第1バインディングを発見し、及び、そのバインディングを用いることにより前記第1サービスを呼び出し、c.第1ワークフロー照合部を用いて、前記第1サービスプロバイダに、前記第1サービス消費部のための前記第1サービスを実行できるために必要なステップを編成し、d.信用管理証明書を用いて、認証されたサービス消費部のみによるアクセスのために第1サービスを保証し、e.信用管理証明書を用いて、前記第1サービスへの限定アクセスを提供する制御プログラムを実行することを有し、前記第1アクセスポイントは、前記第1サービスへの認証アクセスのための前記第1サービス消費部を証明するために信用管理証明書を使用する方法。前記信用管理証明書は、X.509証明書である請求項14に記載の方法。前記信用管理証明書は、SSL証明書である請求項14に記載の方法。サービスを編成する方法において、a.サービス消費部の第1サービスアクセスポイントから、第1サービスを提供する第1サービスプロバイダにより公開され、第1発見可能バインディングを介して、ネットワークピアにアクセスできるようにするために操作可能である第1サービスインタフェースへアクセスし、b.前記第1発見可能バインディングを発見し、かつ、c.そのバインディングを用いることにより前記第1サービスを呼び出すことを有し、前記第1サービスを実行するために必要なステップは、第1ワークフロー照合部を用いて編成される方法。前記第1サービスは、遠隔インターネットベースサーバに位置する暗号化されたメディアコンテンツへの限定アクセスを提供し、かつ、第1ワークフロー照合部は、第1サービス消費部が前記コンテンツへのアクセスを認証されているかどうかを検証し、そうであるならばコンテンツ所在位置を突き止め、かつ、第1サービス適応レイヤを介して該コンテンツを第1サービス消費部に提供するする第1制御プログラムを含む請求項17に記載の方法。a.第1発見可能バインディングを介して、第1サービスを提供する第1サービスプロバイダの第1サービス適応レイヤから、ネットワークピアにアクセスできるようにする第1サービスインタフェースを公開し、b.第1サービス消費部の第1サービスアクセスポイントから前記第1サービスのための要求を受け取り、かつ、c.第1ワークフロー照合部を用いて、前記第1サービスプロバイダに、前記第1サービス消費部のための前記第1サービスを実行できるために必要なステップを編成することを有する方法。a.第1発見可能バインディングを介して、第1サービスを提供する第1サービスプロバイダの第1サービス適応レイヤから、ネットワークピアにアクセスできるようにする第1サービスインタフェースを公開し、b.第1サービス消費部の第1サービスアクセスポイントから前記第1サービスのための要求を受け取り、c.信用管理証明書を用いて、認証されたサービス消費部のみによるアクセスのために第1サービスを保証し、d.信用管理証明書を用いて、前記第1サービスへの限定アクセスを提供する制御プログラムを実行し、e.第1ワークフロー照合部を用いて、前記第1サービスプロバイダに、前記第1サービス消費部のための前記第1サービスを実行できるために必要なステップを編成することを有する方法。ここに記述されるシステム及び方法の実施例は、前述の問題の一部又は全てに対応するために使用可能である。実施例の一つにおいて、公開されたサービスインタフェースを介しリッチrichかつ動的な方法で、消費者又は企業メディアスペース例、消費者、コンテンツプロバイダ、機器製造業者、サービスプロバイダの複数の種類の利害関係者に、お互いを探し出し、信頼関係を築き、価値を交換することができるサービスフレームワークを提供する。一般的にメディア編成のネットワーク環境NEMO:NetworkEnvironmentMediaOrchestrationと呼ばれるこのフレームワークの実施例は、異機種の消費者機器、メディアフォーマット、通信プロトコル及びセキュリティ機構を取り扱う分野において、相互運用可能で、セキュアなメディア関連の電子商取引を可能とするプラットフォームを提供できる。サービスインタフェースの分散ポリシー管理は、信頼とセキュリティをもたらすことを促進するために使用でき、その結果、商業的な価値の交換を容易にする。新たなウェブサービス基準が、インターネット上でのサービスの相互運用性の問題に対応し始めているが、NEMOの実施例は、家庭、企業及び業界部門のゲートウェイ等のパーソナル及びローカルエリアネットワークや、ワイドエリアネットワークでの複数ネットワークレイヤの相互運用性に対応するために使用可能である。例えばNEMOは、携帯電話、ゲームプラットフォーム、PDA、パソコン、ウェブベースのコンテンツサービス、ディスカバリサービスdiscoveryservise、通知サービス及び更新サービスを使用した1つの相互接続システムにおける相互運用性を提供できる。NEMOの実施例はさらに、さまざまなローカル及びリモートインタフェースの結合例、WS11、Java登録商標RMI、DCOM、C、Net等を用いた、単純及び複雑なサービス両方の動的なピアツーピア編成peertopeerorchestrationを提供するために使用可能で、それにより、レガシーアプリケーションの統合が可能となる。メディアの世界において、利害関係者コンテンツ発行者、販売業者、小売業務、消費者機器プロバイダ及び消費者内の主要なグループにより必要とされ、好まれるシステムとインタフェースは、多くの場合様々に異なる。そのため、これらのエンティティentityにより提供される能力を、関与するエンティティの必要性を満たす最適な構造へと即時に発展できる総合的なサービスへとまとめることが望ましい。例えば、とりわけBluetooth登録商標、UPnP、Rendezvous、JINI、UDDI及びLDAP等のさまざまなサービスディスカバリプロトコルやレジストリは、同じサービス内で共存でき、各ノードがそのノードをホストする機器に最も適したディスカバリサービスを使用することを可能とする。他にはIPベース機器、ワイヤレスSMS通知、さまざまなメディアフォーマットMP4、WMF等に対応するサービスもあるだろう。NEMOの実施例は、ピアツーピアP2Pサービス編成を使用してこれらの目標を果たす。P2Pフレームワークの有利性は、音楽や映像の配布等で見受けられる一方、P2P技術はさらに広範囲に使用できる。ウェブサービスの活動の大半は、比較的静的なネットワーク構成とクライアント側とのサービス交流のほか、マシン同士の交流に焦点を合わせてきた。NEMOはまた、個人がその人のパーソナルエリアネットワークPAN部分を持ち、LAN又はその他のPAN付近へ移動し、ピアを基準としさらに多くのサービスと接続できるばかりでなく即座にサービスアクセスを再構成することを望む状況を取り扱うことができる。メディアやその他さまざまな企業システムサービスの中にも機会は存在し、特に2つ以上の企業間での交流にその機会は存在する。企業は、ほとんどの場合階層的に編成され、それらの情報システムはその組織を反映したものであるが、異なる企業の人々は多くの場合、ピア型のインタフェースを介してより効果的に交流できる。例えば、会社Aの受注担当者/サービス担当者は、会社Bの出荷担当者と直接話すことにより問題を解決し、及び、有益な情報のより直接的な入手することができる。横断階層及び不要なインタフェースは一般的に実用的ではない。FedExやUPS等の輸送会社はこれに気付き、それらの工程に直接的な視認性を許し、顧客が直接事象を監視できるようにした。会社や市政機関は企業ポータルを通じてサービスを編成し、セルフサービスの粗野な形式を可能とした。しかし、既存のピアツーピアフレームワークでは、その顧客や供給者が自然な同等なレベルで交流することを可能とし、それらのエンティティが自分たちに最も適した方法で企業のサービスを編成することができるように、ある企業に、その顧客や供給者にさまざまなサービスインタフェースを公開することを許さしていない。これは例えば、それらのピアインタフェースのある形式の信頼管理を必要とするだろう。本発明の好ましい実施例は、サービスインタフェースのこのP2P公開を許可するだけでなく、促進することに使用できる。DRMデジタル著作権管理等の特定のアプリケーションとの関連において、NEMOの実施例は、クローズcloseで同種のDRMシステムの欠陥や制限を扱うように設計された、サービス指向アーキテクチャを供給するために使用できる。好ましい実施例は、異種の消費者機器、メディアフォーマット及びセキュア機構のための相互運用可能で、セキュアなメディア関連取引及び運用を提供するために使用可能である。保護されたコンテンツを取り扱うための比較的高性能で負荷の高いクライアント側のエンジンを必要とする多くの従来型のDRMシステムとは対照的に、本発明の好ましい実施例は、クライアント側のDRMエンジンを比較的単純にし、サービスレベルで操作することのできる、よりリッチなポリシー管理システムricherpolicymanagementsystemにより設定される支配ポリシーgovernancepolicyを実施する。本発明の好ましい実施例は、また、メディアフォーマットと暗号化プロトコルの選択において、より高い柔軟性を供給でき、そして、DRMシステム間の相互運用性を容易にすることができる。単純でオープンな柔軟性のあるクライアント側のDRMエンジンは、力強いDRM対応アプリケーションを構築するために使用できる。実施例の1つでは、DRMエンジンはウェブサービスアプリケーションに容易に統合され、またどのようなホスト環境やソフトウェアキテクチャにも実質的に統合されるよう設計される。サービス編成は、相互運用性の障壁を乗り越えるために使用される。例えば、コンテンツ検索がある場合、その要求を満たすために、さまざまなサービス例、ディスカバリ、検索、照合、更新、権利交換及び通知を統合可能である。編成能力の好ましい実施例により、ユーザは動的な複数レイヤのネットワークにおいて、どの時点であっても、あらゆる機器から全ホーム及びインターネットベースのコンテンツキャッシュを見ることができる。この能力は、ストリームとプレイリストの共有を容易にするするために拡張でき、ユーザの権利が尊重される一方、多くの異なる機器を使用し、即座のブロードキャスト及びナローキャストを容易に発見及び接続させる。NEMOの好ましい実施例では、メディアフォーマット、著作権管理及び実現プロトコルのスタンダードの単一セットに依存しないエンドツーエンド相互運用メディア配信システムを提供する。コンテンツ発信者、販売業者、小売業者、サービスプロバイダ、デバイスメーカ及び消費者を含む価値連鎖では、各区分において多くの局部的なニーズがある。これは特に、コンテンツ発信者が、異なる流れに沿った価値連鎖要素に、さまざまな状況を異なって適用する著作権の使用を提示する可能性がある著作権管理において当てはまる。消費者ゲートウェイには通常、より限定された懸念があり、エンドユーザの機器にはまだ単純な懸念、すなわちコンテンツの再生という懸念がある。十分自動化された動的に自己構成された配信サービスシステムにより、コンテンツ発信者は、どこにおいてもまたどの種類の機器を使用しているかにもかかわらず、コンテンツ制作及びパッケージ化を行い、著作権を提示したり、また関心のある消費者に瞬時にコンテンツを供給するその他のサービスプロバイダによって付加された価値に確信を持って依存することができる。NEMOの好ましい実施例は、完全に統制されたエンドツーエンド基準の一式を待つ又はそれに依存することなく、消費者とサービスプロバイダの両者に利益をもたらす新しいサービスを作り出し導入する複数のサービスプロバイダに手段を提供することで、この目標を達成する。ポリシー管理は、海賊版がそれらの合法サービスを利用できる範囲を制限できる。NEMOは、ネットワーク効果に、賊版が提供できるものよりもさらに優れた価値を提供する極めて豊富な合法サービスのセットの発展を容易にすることができるを可能にする。下記を含む多くのNEMO実施例に共通する最良形態技術のいくつかを次に議論する。複雑な機器指向ポリシーとサービス指向のポリシーの区別より単純なサービスからより高度化したサービスの構成動的な構成及びサービスの広告異機種環境におけるさまざまなサービスの動的な発見と実行単純な機器からゲートウェイサービスを利用NEMOフレームワークとの併用が可能な新しい種類のDRMエンジンとアーキテクチャを導入することができる。このDRMシステムは以下の目標の一部又は全てを達成するために使用できる。簡潔さ。ある実施例では、制御プログラム例、管理ポリシーを実施するプログラムを実行する、必要最低限度のスタックベースのバーチャルマシンVMを使用したDRMエンジンが提供される。例えば、VMは数ページのコードのみから構成されても良い。モジュール性。ある実施例では、DRMエンジンはより大きなDRM対応アプリケーションへ統合される1つのモジュールとして機能するよう設計される。かつて暗号化サービスなどの巨大なDRMカーネルにより実行された機能の多くは、ホスト環境から要求され、そのホスト環境は、その他のコードモジュールにこれらのサービスを提供しても良い。これにより設計者は、比較的容易に標準又は独自に開発した技術を組み込むことができる。柔軟性。モジュールタイプの設計であるために、DRMエンジンの好ましい実施例を、組み込み機器から汎用PCまで、広く多様なソフトウェア環境で使用することができる。開放性open。DRMエンジンの実施例は、参照ソフトウェアとしての使用に適しているため、コードモジュール及びAPIは、ユーザにより、事実上あらゆるプログラミング言語、及び、ユーザが完全に制御するシステムに導入することができる。ある実施例では、システムは、ユーザに特定のコンテンツフォーマットを導入するよう強要したり、コンテンツのエンコーディングを制限したりすることはない。意味的に不可知semanticallyagnostic。ある実施例では、DRMエンジンは、承認要求をグラフgraph構造についての検索に変換する、単純なグラフベースモデルに基づく。グラフの頂点はシステムのエンティティを表し、そして、有向辺は、これらのエンティティ間の関係を表す。しかし、DRMエンジンは任意のアプリケーションにおいてこれらの頂点や辺の意味を認識しなくてもよい。ウェブサービスとの円滑な統合。DRMクライアントエンジンはいくつかの方法でウェブサービスを使用することができる。例えば、グラフの頂点や辺をサービスにより動的に検出することも可能である。なお、コンテンツ及びコンテンツのライセンスは、高度なウェブサービスを通じて検出されDRMエンジンへ配信される場合がある。DRMエンジンの実施例の1つは、複数の箇所でウェブサービスを利用するように構成可能であるが、そのアーキテクチャはウェブサービスとは別のものであるため、独立してクライアント側のDRMカーネルとして使用することができる。簡易化した鍵管理。ある実施例では、グラフトポロジーは暗号の再標的化を必要とせずに、コンテンツ保護鍵の導出を簡略化するために再利用できる。鍵導出方法はDRMエンジンのオプションではあるが強力な機能である。システムはまた、あるいは代替として、その他の鍵管理システムに統合することができる。管理、暗号化、コンテンツの区別。ある実施例では、コンテンツを管理するコントロールcontrolは、管理を実施するために使用される暗号化情報と論理的に区別される。同様に、制御と暗号化情報はコンテンツとコンテンツフォーマットから論理上区別される。これらの各要素は別々又は1つにまとめられたパッケージで配信できるため、コンテンツ配信システムの設計において、高度な柔軟性を可能とする。NEMOフレームワーク、そのアプリケーション及びそのコンポーネント部品の実施例をここに記述する。そのコンポーネントとアプリケーションの多くがそうであるように、フレームワーク自体は新しい種類であることを理解する必要がある。また本発明は、処理、器具、システム、機器、方法、コンピュータで読み込むことのできるメディア又はこれらの組合せなどの数々の方法で導入できることを十分理解する必要がある。これらとその他の特長及び有利性は、以下の詳述と、発明主体の原理を一例として説明する添付の図面でより詳細に示す。本発明の一連の実施例は、参照数字が構造要素を指す以下にある添付の図面と併せ、以下の詳細な記述を参照することにより容易に理解である。発明本体の詳述を下記に挙げる。この説明はいくつかの実施例と併せて示される一方、進歩的な一連の構成は、ある1つの実施例に制限されるばかりでなく、多くの代替案、変更及び同等物を網羅することを理解する必要がある。例えば、いくつかの実施例は消費者指向のコンテンツ及びアプリケーションに関連して説明される一方、技術に熟練した者は、公開されたシステムと方法は容易により幅広いアプリケーションに適応できることを認識するだろう。例えば、制限なしにこれらの実施例は企業のコンテンツやアプリケーションの状況に容易に適応、又は応用できる。さらに、数々の具体的な詳細が、独創的な一連の製作物を完全理解するために以下の説明に示される一方、いくつかの実施例は、これらの一部又は全ての詳細なしに実施できる可能性がある。その上、明確にするために、不必要に独創的な一連の製作物を不明瞭にすることを避けるために、当技術分野では周知のある一定の技術資料は詳細に説明されていない。1.概念1.1ウェブサービスウェブサービスアーキテクチャWSAはサービス指向アーキテクチャSOAの特定のインスタンスである。SOA自体は、柔軟結合された協調ソフトウェアエージェントで構成される分散システムの一種である。SOAのエージェントはサービスを提供、サービスを要求消費、又はその双方を行う場合がある。サービスは、サービスプロバイダの役割を行うエージェントにより管理される、明確な自己完結の操作セットとして見ることができる。操作は、標準プロトコルとデータフォーマットを使用し、エンドポイントと呼ばれるいくつかのネットワークのアドレス可能な場所において、ネットワーク上で呼び出される。自己完結に関しては、サービスはその他のサービス又は包括的なアプリケーションの状態や状況に直接的に依存しないことを意味する。CORBA、DCOM及びJ2EEを含むSOAの概念を裏づけする確立された技術の例。WSAは、特定のプラットフォーム、プログラミング言語、アプリケーションプロトコルスタック又はデータフォーマット変換に頼らないため、魅力的である。WSAは、サービスを記述し、プロバイダと消費者間の柔軟結合と相互運用性を容易にするメッセージを交換するXMLに基づいた、標準フォーマットを使用し、潜在的に全世界に分散するシステムの配置と参加を促す、複数の標準インターネットプロトコルとりわけHTTPをサポートする。新生の動向としては、プラグアンドプレイサービスバスというコンテキストcontextで、SOAを見ることである。サービスバスの取り組みは、記述、メッセージング、移送基準を利用し、サービスの編成に備える。インフラストラクチャはまた、発見、変換、セキュアのほか、おそらくその他の基準を組み込むことができる。WSAに組み込まれた偏在するスタンダードに本来備わっている質により、インフラストラクチャは柔軟性、伸張性があり、拡張可能であるため、調整されたサービスバスモデルを構築するための適切な基盤を提供できる。このモデルでは、ワークサービスの基本的な単位はウェブサービスと呼ばれる。ウェブサービスには多くの定義がある。以下の定義は、ワールドワイドウェブコンソーシアムW3Cウェブサービスアーキテクチャ作業草案2003年8月8日-wwww3orgTRwsarch参照に由来する。ウェブサービスは、ネットワーク上の相互運用可能な、マシン同士のインタラクションをサポートするように設計されたソフトウェアシステムである。ウェブサービスは、マシンで処理できるフォーマット具体的にはWSDLで記述されたインタフェースを持つ。他のシステムは、その他のウェブ関連の基準と併せたXMLシリアライゼーションのHTTPを使用し、一般的に伝達されるSOAPメッセージを使用した記述で規定される方法で、ウェブサービスとインタラクションする。W3C定義は、有益な開始ポイントを提供する一方、ウェブサービスという用語は、例えば特定のスタンダード、フォーマット及びプロトコル例、WSDL、SOAP、XML、HTTPなどの使用に対し、制限なく幅広い意味でここでは使用されることを理解する必要がある。特定のウェブサービスは、サービスプロバイダとサービスリクエスタ間の一時的である可能性がある関係の基盤を提供する、論理的に整合性のある操作セットのための抽象的なインタフェースとして表すことができる。もちろん、実際のウェブサービスは具体的な実装を有する。プロバイダの具体的な実装は、ウェブサービスとは区別されサービスと呼ばれることもある。サービスプロバイダの機能を実際に実行するソフトウェアは、プロバイダエージェントで、サービスの要求元の機能を実際に実行するソフトウェアは、リクエスタエージェントである。エージェントを所有する個人又は組織を、必要に応じてプロバイダエンティティ又はリクエスタエンティティと呼ぶ。それ自身で使用された場合、リクエスタ又はプロバイダは状況により、それぞれエンティティ又はエージェントと呼ばれる場合がある。ウェブサービスは目的を果たすために存在し、どのようにこれが達成されるかは、特定のウェブサービスメッセージ交換の構造とセマンティックsemanticで特定される。構造は、ネットワーク上で起こるメッセージ交換を可能にする、正確なマシンで処理可能な技術仕様を意味する。構造は正確に定義することができるが、セマンティックはそうはいかない場合がある。セマンティックは、どのような形で存在しようと、ウェブサービスのリクエスタとプロバイダエンティティ間の理解と全体的な要求を管理する、明白な又は暗黙の規約contractを意味する。ウェブサービスは多くの場合、3つの役割の相互関係の観点から表せる:iサービスプロバイダ;iiサービスリクエスタ;及びiiiサービスレジストリ。このモデルでは、サービスプロバイダは、サービスレジストリにウェブサービスに関する記述情報を公開する。サービスリクエスタは、あるディスカバリメカニズムを通じてこの情報を発見、次にこの情報を使用し、サービスを利用するサービスプロバイダにバインドする。バインディングbindingは単に、公開されたサービス記述でプロバイダが特定するメッセージフォーマッティング、データマッピング及びトランスポートプロトコル仕様を使用し、プロバイダによって利用可能となる操作をリクエスタが呼び出すことを意味する。この情報を記述するために使用されるXMLベースの言語は、ウェブサービス記述言語:WSDLと呼ばれる。サービスプロバイダは、WSDLサービス記述で記述される特定の目的のための、いくつかの操作セットへのアクセスを与える;このサービス記述は多くの手段のうちのどれかによってレジストリに公開されているため、サービスが発見される可能性がある。レジストリは特定のドメイン内において公開される又は非公開とされる場合がある。サービスレジストリは、以前公開されたサービス記述を返すことで、サービス検索要求に応じるソフトウェアである。サービスリクエスタは、レジストリから得たWSDLに指定されるバインディング情報に沿って、プロバイダから与えられたさまざまな操作を呼び出すソフトウェアである。サービスレジストリは概念的にのみ存在する場合と、特定のサービスをクエリ、場所を見つけ及びバインドするために使用される、サービス記述のデータベースを提供する現実のソフトウェアとして事実上存在する場合がある。しかし、リクエスタが実際にサービスのアクティブな検索を行おうと、サービス記述が静的又は動的に与えられようと、レジストリはウェブサービスモデルにおける論理的にはっきりと識別されることのできる側面である。現実世界の実装では、サービスレジストリは、サービスリクエスタのプラットフォーム、又はサービスプロバイダのプラットフォームの一部である場合があること、もしくはあるよく知られたアドレスもしくはその他の手段によって提供されるアドレスにより、完全に識別される別の場所に存在する場合があることは注目に値する。WSDLサービス記述は疎結合loosecouplingに対応するもので、しばしばSOAの真のテーマとなる。サービスリクエスタは、目的の結果を達成するためにかかるサービスのインタフェースのセマンティックを最終的には理解する一方、そのサービス記述は、特定のサービスバインディング情報からサービスインタフェースを分離し、極めて動的なウェブサービスモデルをサポートする。サービス指向のアーキテクチャは、多くの可能性のある技術レイヤ上に構築することができる。現在行われているようにウェブサービスは通常、以下の技術形態を組み入れる、又は、含んでいる。HTTP-ほとんどのウェブサービス通信向けの標準アプリケーションプロトコル。ウェブサービスはさまざまなネットワークプロトコル例、SMTP、FTPなどに展開できるが、HTTPは使用されているもののなかで最も偏在する、ファイヤーウォールとなじみ易いトランスポートである。一部のアプリケーション、特にイントラネット内では、他のネットワークプロトコルの方が必要条件によって道理にかなう場合がある。それにもかかわらずHTTPは、今日構築されているほとんど全てのウェブサービスプラットフォームの一部である。XML-構造化された情報のコンテンツ及びコンテンツに関する情報をフォーマットしアクセスするためのスタンダード。XMLは、ウェブサービスエージェント間の情報を通信するための、テキストベースのスタンダードである。ここで留意すべき点は、XMLの使用は、ウェブサービスのメッセージペイロードが少しもバイナリデータを含んでいない可能性があることを意味するのではなく、このデータはXML仕様に沿ってフォーマットされることを意味する、ということである。ほとんどのウェブサービスアーキテクチャは、必ずしもメッセージとデータが文字ストリームにシリアル化することを指示するわけではない-それらは適切であれば、バイナリデータにシリアル化される可能性もある-しかしXML使用の場合、これらのストリームはXML文書を意味する。つまり、トランスポート機構のレベルに関係なく、ウェブサービスメッセージングはしばしば、XML文書を使用して行われる。多くのウェブサービスに特に重要な、2つのXMLサブセット技術は、XMLネームスペースXMLNamespacesとXMLスキーマXMLSchemaである。XMLネームスペースはネーミングの重複を解決し、XML文書に含まれる要素に特定の意味を有効にするために使用される。XMLスキーマは、XML文書内に含まれるさまざまな情報項目を定義及び制約するために使用される。これらの目的を他の手段で達成することは可能及び任意であるが、XMLの使用は恐らく今日使用されている最も一般的な技術である。ウェブサービス文書自体のXML文書フォーマットは、XMLスキーマを使用し定義され、最も多く現実的に利用されているウェブサービス操作とメッセージ自体も、XMLスキーマを組み入れた形でさらに定義される。SOAP-他方の受信側へ送信し処理される特別にフォーマットされたパッケージに指示と情報をカプセル化するための、XMLベースのスタンダード。ソープSOAP簡易オブジェクトアクセスプロトコルは、エージェント間で送信するためのウェブサービスメッセージをパッケージ化するための標準機構である。多少誤った名称であるが、その名残は、分散型オブジェクトを呼び出す手段であり、その点においてその他の代替物と比べ確かにより簡易である。しかし最近の傾向としては、頭字語の本来の意味を超えるために、SOAPはXMLベースのワイヤプロトコルwireprotocolと考えられる。SOAPは、メッセージを構築しコンテンツに関する意味を提供するための、比較的重要でない仕様を定義する。各SOAP文書は、ヘッダとボディに分けられるエンベロープを持つ。構造上は類似しているが、ヘッダは通常、ボディに含まれるコンテンツの処理に関連する受信側のメタ情報又は指示に使用される。SOAPはまた、機能と機能の責任を果たすために必要な処理を識別するための手段を特定する。メッセージ交換パターンMEPは、ノード間でどのようにメッセージが交換されるかといったパターンを定義する機能である。一般的なMEPは要求に応答し、要求と応答ノード間の単独で完全なメッセージ取引を確立するhttpwwww3orgTR2003RECsoap12part220030624soapsupmepを参照。。WSDL-ウェブサービスの使用方法を説明するXMLベースの標準。WSDLの観点からすれば、サービスはサービスリクエスタとプロバイダ間で交換されるメッセージの一式に関連したものである。メッセージは、特定のプロトコルにマッピング可能な抽象的な方法で記述される。いくつかの機能を呼び出すメッセージ交換は操作と呼ばれる。特定の操作セットはインタフェースを定義する。インタフェースはネームバインディングにより、具体的なメッセージフォーマットとプロトコルに結びついている。バインディング具体的なプロトコルに対するインタフェースのマッピングは、プロトコルに適切なURIと関連し、エンドポイントとなる。1つ以上の関連するエンドポイントのまとまり特定のURIで、具体的なプロトコルにインタフェースをマッピングするは、サービスを構成する。これらの定義は特定のWSDL要素に関連する:タイプタイプ定義用のコンテナ要素メッセージ送信されるデータのタイプの抽象定義オペレーションoperationインプット、アウトプット及びフォルトメッセージの組合せに基づく活動の抽象的な記述ポートタイプportType抽象的なオペレーションセット-インタフェースバインディングインタフェースportType用の具体的なプロトコルとデータフォーマットの仕様ポートバインディングと実際のネットワークアドレスの組合せ-1つのエンドポイントanendpointサービス関連ポートの集まり複数のエンドポイントendpointsWSDLは一般的なバインディング機構を定義し、その後SOAP、HTTPGETPOST及びMIMEの特定のバインディング拡張を定義する。そのため、バインディングは必ずしもトランスポートプロトコルに直接バインディングすることを意味するのではなく、特定のワイヤフォーマットにバインディングすることを意味する。実際のSOAPメッセージの交換は一般的に、httpURIを介しポート80のHTTP上で起こるが、ウェブサービスで最も一般的なバインディングはSOAPである。しかし、インタフェースはHTTPに直接バインドされる;あるいは例えばSOAPのバインディングはmailtoURIを介しSMTPを使用できる。実装は、それ独自のワイヤフォーマットを定義し、カスタムバインディング拡張を使用することができる。WSDLは、要素をサポートしており、維持性と再利用性を促進する。WSDL文書は、importを使用し、ある組織に対し妥当な方法で、別々の要素に分割できる。インタフェース定義と実装定義とのある程度の分離が要求される結束性の高いウェブサービス環境では、以下の3つの文書に分けるのが妥当である:スキーマXsd文書-ルートノードはで、ネームスペースはhttpwwww3org2001XMLSchema。再利用可能な部分とみなされているものを含む、サービスインタフェースの記述特定のサービスエンドポイントを含む、サービス実装定義WSDLインタフェースは、Java登録商標又はIDLやその他のプログラミング言語インタフェースと全く同じではない。例えばJava登録商標インタフェース宣言は、そのインタフェースを実装しようと要求するクラスのメソッドの少なくとも1つのサブセットに合うメソッドセットを宣言する。1つ以上のクラスがインタフェースを実装でき、各実装は異なる可能性がある;しかしメソッドのシグネチャメソッド名及び全ての入力又は出力タイプは一般的に同一でなければならない。これは言語により命令され、コンパイル時間やランタイム時、又はその双方で厳守される。WSDLインタフェースは異なっており、単独では十分に役立たない実際には抽象型クラスに近い。1つのウェブサービスのさまざまなWSDLインタフェースやportTypeは、オペレーション名の一式が同一でなければならない、という意味では論理的に関連がある-それはまるでportTypeが実際、他で定義された特定の規約を実装するかのようである-だが実際にはそのような要素は存在せず、portTypeの均整を強化するための機構はない。各portTypeは一般的に、サポートするバインディングのタイプを識別するよう名前が付けられる-だがportType単独ではバインディングを作成しない。関連するportTypeのportTypeオペレーションは同じ名前が付けられるが、インプット、アウトプット及びフォルトメッセージ存在する場合は、特定のバインディングをサポートするためにもやはり必要な名前の部分を含む、特定のメッセージにマッピングされる。これはメッセージ自体が十分抽象的でないという点を提起する。ウェブサービスは、必要となるさまざまなバインディングのため、類似しているが独自のメッセージを定義する必要がある場合があり、また頻繁にそうする必要がある。下記に説明されるように新生のウェブサービスと関連スタンダードを利用し、システムアーキテクチャは開発することができ、それは広範囲のハードウェア及びソフトウェアプラットフォームと操作環境で、さまざまな異なるプロトコルとインタフェースを利用するネットワーク化された相互運用メディア関連サービスの作成を容易にする。1.2役割本発明の好ましい実施例では、ピアがサービスを公開することでさまざまな機能を自然に提供できるピアツーピア環境を実現し、推進し、及び又は、積極的に対応することを求めている。フレームワークにおけるある実施例では、特定の一連の機能を持つものとしてピアをみることを推奨せず、代わりに、時間内のある時点におけるピアが1つ以上の役割に参加するというモデルを推奨している。役割は、あるピアが特定の行動パターンと共に公開する一連のサービスによって定義される。ある時点にて、NEMOが有効になったノードは、次のようなさまざまな要素に基づいて複数の役割を果たすことができる。ある一連のサービスに対応する機能を提供する実際の実装フットプリントfootprint、管理構成、ピアが公開できるサービスの宣言情報、及びサービスインタフェースにおける読み込み及び実行時ポリシーなどである。明示的な一連の役割は、異なるサービスのタイプに基づいて定義することができる。今後、参加に関する一般的なパターンが決定され、新規サービスが導入されるにつれて、より形式化された役割分類ス鍵ムが定義できる。今後、公式化される可能性のある予備的な一連の役割には以下のものが含まれる。クライアント-サービスを公開しない比較的単純な役割、このピアは単に他のピアのサービスを利用する。オーソライザAuthorizer-この役割は、要求している主体が、ある一連の事前条件及び事後条件を持つ指定リソースへのアクセスを持つかどうかを判断するポリシー決定ポイントPDPとして操作するピアであることを示す。ゲートウェイ-以下の理由により、特定の状況において、ピアは他のサービスプロバイダを直接探したり、他のサービスプロバイダと相互関係を持ってはならない。トランスポートプロトコルの非互換性、信頼コンテキストのネゴシエーション不可、又はあるサービスに関連する必要なメッセージの作成処理に関する処理能力の不足。ゲートウェイとは、ピアがサービスプロバイダとのインタラクションinteractionを可能にするために、別のピアへの橋渡しをするピアである。自己証明並びにオペレーション用の信頼コンテキストcontext、信頼コンテキストの構築の観点からすれば、要求しているピアは自身の自己証明をゲートウェイピアへ実際に委譲し、代わりにネゴシエーションnegotiationを行ったり、決定を行ったりすることを許可することもある。又は、ゲートウェイピアは単純なリレーポイントとして操作し、要求及び応答の転送や経路の決定を行うこともある。オーケストレータorchestrator-一連のサービスプロバイダとのインタラクションがサービスの重要な連携場合により取引、分散状態管理等を含むを必要とする状況において、オーケストレータは、参加するためのピアの能力を超えたものであってもよい。オーケストレータは、ゲートウェイの役割を特殊化したものである。ピアは、代わりとして1つ以上のサービスを提供するための仲介となるように、オーケストレータへ要求することができる。編成するピアorchestratingpeerは、編成要件を満たすために適切に構成されたワークフロー照合部のような、特定の追加NEMOコンポーネントを使用してもよい。いかなるメディアへの、いかなるフォーマットにおける、いかなる提供元からの、いかなる場所にて、いかなる時間における、いかなる好ましい一連の使用ルールに従ったいかなるデバイス上での要求を満たすことで即座に要求を満足させるという目的を前提として、以下の非公式なモデルは、NEMOフレームワークの実施例を使用し、この目的がどのように達成できるかを説明する。NEMOによりモデル内の異なるレイヤにある下位レベルのサービスを、より豊富なエンドツーエンドのメディアサービスへ作り上げることを可能にする方法は、NEMOが、想像可能な全てのメディアサービスを可能にする方法の全形態を列挙することなくモデルの最高レベルから明白になる。本モデルのある実施例においては、次の4つのレイヤのサービスコンポーネントがある。1コンテンツオーサリングcontentauthoring、アセンブリ、及び、パッケージ化サービス、2ウェブベースのコンテンツ統合流通サービス、3ホームゲートウェイサービス、及び4消費者向け電子機器。これら4つのレイヤのそれぞれには一般的に、セキュリティ、著作権管理、サービス探索、サービス編成、ユーザインタフェースの複雑性、及びその他サービス属性に関する異なる要件がある。最初の2つのレイヤは従来のウェブサービスに見られるモデルにおおよそ適合するが、最後の2つのレイヤは、2種類のモデル間の繋ぎ目にあるホームゲートウェイの特定サービスを持つパーソナル論理ネットワークモデルと呼ばれるものに、より適合する。しかし、CEデバイス用のサービスはいずれのレイヤにも時々現れる。あるエンドツーエンドソリューションを網羅するのに十分なほど一般的であるものの、実装の効率のためにフレームワークのパーツを特殊化したい場合、1つのジレンマがある。例えば、UDDIディレクトリ及びディスカバリの取り組みは、比較的静的で中央化されたウェブサービスではうまく機能するかもしれないが、パーソナルネットワークの動的で一時的な融合に対して、UPnP及びRandezvousにあるような探索モデルの方がより適切な場合もある。したがって一部の実施例では、複数のディスカバリスタンダードがフレームワークに組み込まれている。同様に、著作権管理がホールセールwholesale、アグリゲータaggregate、及びリテールretail分散下層を通じてメディア分散に適用される場合、表明及び追跡が必要な多数の異なる種類の複合権利及び義務が存在することがある。そのため、高度に明示的でかつ複雑な権利の専門用語、洗練されたコンテンツ統治及び除去サービス、及びグローバルな信頼モデルに関する必要性があると思われる。しかし、ホームゲートウェイレイヤ及びCEデバイスレイヤに対する著作権管理及びコンテンツ統治は、消費者の視点から見て比較的単純である公平な使用権を強調する異なる信頼モデルを伴うことができる。パーソナル論理ネットワーク内のピアデバイスは、グローバルな信頼モデルを使用するワイドエリアネットワーク全体においてピアとインタラクションする能力と共に、おそらくプロキシゲートウェイサービスを通じて、そのネットワークの比較的単純な信頼モデルを使用するインタラクションを要求できる。消費者側では、デバイス全体におけるコンテンツ有用性の自動化された管理から複雑性が生じ、その一部はモバイルであるが、複数のネットワークを断続的に行き来する。したがって、エンドツーエンド分散を可能にしたままでの著作権管理への効果的な取り組みは、売買取引又はサービス予約権が行使されるような別の事象と統合される取引において、頒布権の表現を翻訳し、状況に合わせて個々の消費者使用権に変換するサービスを含むさまざまな著作権管理サービスに対応する多元的なものの場合もある。1.3論理モデルある実施例では、システムフレームワークは、ピアツーピアP2P方式でインタラクションする論理的に接続された一連のノードから構成される。ピアツーピアコンピューティングは、しばしば、コンピュータ及び他の知的デバイス間におけるハードドライブ及び処理サイクルなどのリソースの共有として定義される。HTTPwwwintelcomcurepeerhtmを参照のこと。ここでは、P2Pは、ネットワークノードが全種類のサービスを対称的に消費及び提供することを可能にする通信モデルとしてみられるかもしれない。P2Pのメッセージング及びワークフロー照合により、リッチサービスを異種の一連のより基本的なサービスから動的に作成することが可能となる。これにより、共有リソースが、多数の異なる種類のサービスである場合、そして異なるサービスバインディングを使用するものでさえ、P2Pコンピューティングの可能性の検査が可能になる。異なる実施例では、関係者例:消費者、コンテンツプロバイダ、デバイスメーカ、及びサービスプロバイダがお互いを見つけ出し、有意義で動的な方法で相互関係を持ち、価値を交換し、協力することを可能にするメディアサービスフレームワークを提供できる。これら異なる種類のサービスは、基本的なもの探索、通知、検索、及びファイル共有からより複雑で高レベルのサービスロッカー、ライセンス供与、マッチング、権限付与、支払取引、及び更新などまで、及びそれら全て又は一部の組合せの範囲に及ぶ。サービスはピアツーピアの通信ノード全体に渡って流通することができ、それぞれメッセージの経路決定、及びこのネットワーク用に設計されたメッセージポンプとワークフロー照合部以下に詳述を使用した統合を提供する。ノードは、サービス実施要求を作成し、応答を受けることでインタラクションする。要求及び応答メッセージのフォーマット及びペイロードは、サービス及び関連するインタフェースバインディングの記述及び構成が可能で、拡張可能な一連のデータタイプを具体化した、標準XMLスキーマベースであるウェブサービス記述言語例、WSDLにて定義してあることが望ましい。WSDLにおいて多くのオブジェクトタイプは多様であり、新規機能に対応するように拡張できる。システムフレームワークは、単一のサービスプロバイダとのインタラクションから、複数のサービスプロバイダからの反応が一定な一連のサービスの複雑な集合まで、さまざまな通信パターンの構成に対応する。ある実施例において、フレームワークは既存のサービス振る舞いスタンダードWSCI、BPEL等の使用のための基本的な仕組みに対応しており、またサービスプロバイダが独自の仕様を取り入れることも可能である。サービス呼び出しに関連するメッセージ構文は、システムフレームワーク内で使用されるコアデータタイプのように、比較的柔軟で可搬性のある方法で記述されることが望ましい。ある実施例において、これはWSDLを用いて達成されることができ、記述されたサービスに関連するセマンティック記述を参照する比較的簡単な方法を提供する。サービスインタフェースには1つ以上のサービスバインディングがあるかもしれない。このような実施例において、あるノードは、別のノードのインタフェースバインディングが例えばWSDLで表現できる限り、かつ、要求ノードがバインディングに関連する仕様及びプロトコルに対応できる限り、そのノードのインタフェースを実施できる。例えば、ノードがウェブサービスインタフェースに対応する場合、要求ノードはSOAP、HTTP、WSSecurity等の対応が必要であろう。いかなるサービスインタフェースも、著作権管理の形態を直接提供する標準的な方法で制御される例、管理された著作権。ノード間のインタラクションは、統治されたオペレーションとして見ることもできる。実質的にいかなる種類のデバイス物理的又は仮想的も潜在的にNEMOに対応されているとみることができ、NEMOフレームワークの主要な形態を実施することができる。デバイス種類には例えば、消費者向け電子機器、ネットワーク型サービス、及びソフトウェアクライアントを含む。望ましい実施例において、NEMOが有効になったデバイスノードは一般的に、以下の論理モジュール以下にて詳述の一部又は全てを含む。ネイティブサービスAPI-デバイスが実装する一連の1つ以上のサービス。NEMOノードがNEMOフレームワークにおいて直接的又は間接的にいかなるサービスをも公開する必要はない。ネイティブサービスの実装-ネイティブサービスAPIに対応する一連の実装。サービス適応レイヤ-エンティティのネイティブサービスのうち公開されているサブセットが、WSDLなどで記述された1つ以上の探索可能なバインディングを使用してアクセスされる際の論理レイヤ。フレームワークサポートライブラリ-サービスインタフェース、メッセージ処理、サービス編成等の実施サポートを含む、NEMOフレームワークとの連携に必要なサポート機能を提供するコンポーネント。1.4用語ある実施例において、基本的なWSDLプロファイルは、インタラクションのパターン及び下部的な機能を支援するための、最低限のコアとなる一連のデータ型及びメッセージを定義する。ユーザは、直接的に、アドホックadhoc法で、又は標準化処理の形式を介し、このコアの上に構築され、新規データ及びサービス種類を追加し、既存のものを拡張する他のプロファイルを定義できる。ある実施例において、このコアプロファイルは、以下の主要基本データ型の一部又は全ての定義を含む。ノード-システムフレームワークにおける関与を示す。ノードは、サービス消費部及び又はサービスプロバイダを含む、複数の役割を果たすことができる。ノードは、消費者向け電子機器、メディアプレーヤなどのソフトウェアエージェント、コンテンツサーチエンジンなどの仮想サービスプロバイダ、DRMライセンスプロバイダ、コンテンツロッカーを含む、さまざまな形式で実装されることができる。デバイス-仮想デバイス又は物理デバイスとして表現されるものをカプセル化するの。ユーザ-クライアントユーザとして表現されるものをカプセル化する。要求-一連の対象ノードに対するサービスの要求をカプセル化する。要求入力-要求の入力をカプセル化する。応答-要求に関連する応答をカプセル化する。要求結果-要求に関連する個々の応答の中へ結果をカプセル化する。サービスプロバイダノードによって公開又は提供された一連の明確な機能の表現をカプセル化する。これには例えば、携帯電話例、音声認識サービスなどのデバイス内で提供される低レベル機能、又はワールドワイドウェブ例、買い物サービス上で提供される多面的機能が含まれる。サービスは、クライアントのパーソナル化及びライセンス取得などDRM関連のサービスを含む、幅広いアプリケーションを網羅し得る。サービスプロバイダ特定のサービスを公開するエンティティ例、ノード又はデバイス。サービスプロバイダとなり得るものには、携帯電話、PDF、携帯メディアプレーヤ、及びホームゲートウェイなどの消費者向け電子機器、及びネットワークオペレータケーブル電波中継局など、セルラーネットワークプロバイダ、ウェブベースの小売業者、コンテンツライセンスプロバイダ等が含まれる。サービスインタフェース1つ以上のサービスとインタラクションする明確に定義された方法。サービスバインディング-サービスインタフェースの実施に使用される仕様及びプロトコルを含むサービスと通信する具体的な方法をカプセル化する。これらは、WSI標準XMLプロトコル、WSDL定義に基づくRPC、又はDLLからの機能実行など、さまざまな明確に定義された方法にて実現される。サービスアクセスポイントSAP-ノードが、対象となる一連のサービス提供ノードに対するサービス実施要求を行い、一連の応答を受信することを可能にするために必要な機能をカプセル化したもの。ワークフロー照合部WFC-ノードがサービス実施に関する要求及び応答の収集を管理し処理することを可能にする共通インタフェースを提供するサービス編成の仕組み。このインタフェースは基本的なビルディングブロックを提供し、サービスに関連するメッセージの管理を通じてサービスを調整する。デジタル権利管理DRMなどの特定のアプリケーションのもとでは、一般的なプロファイルは、システムにおけるエンティティを意味し、コンテンツを保護、使用ルールをコンテンツに関連付け、コンテンツの要求時にアクセスが許可できるかを判断する、以下のような一連のコンテンツ保護及び統治オブジェクトに対するさまざまなDRM関連のサービスを含むことがある。コンテンツ参照-コンテンツアイテムへの参照又はポインタの表現をカプセル化する。当該参照は、一般的にコンテンツフォーマット、位置等の標準化された方法を活用することになる。DRM参照-デジタル権利管理フォーマットの記述への参照又はポインタの表現をカプセル化する。リンク-エンティティ例、ノード間のリンク。コンテンツ-メディア又はその他コンテンツを表す。コンテンツ鍵-コンテンツの暗号化に使用される暗号化鍵を表す。コントロールcontroll-使用方法又はコンテンツとのインタラクションを統治するその他ルールを表す。コントローラcontroller-コントロール及びコンテンツ鍵オブジェクト間の関連を表す。プロジェクタ-コンテンツ及びコンテンツ鍵オブジェクト間の関連を表す。ある実施例において、コアプロファイルは以下の基本サービスの一部又は全ての定義を含む。承認-一部の参加者にサービスへのアクセスを許可する要求又は応答。統治-ソフトウェアップグレードをダウンロード及びインストールする能力など、一部のアイテム例、音楽ファイル、文書、又はサービス操作へ権威的又は支配的影響を行使する処理。統治は一般的に、信用管理、ポリシー管理、及びコンテンツ保護などの機能を提供するサービスとのインタラクションを行う。メッセージルーティング-サービス提供ノードにメッセージを転送、又はメッセージを収集及び組み立てる能力を含むメッセージルーティング機能を提供する要求又は応答。ノード登録-ノードの登録操作を行うための要求又は応答。これにより、中間ノードを通じてノードによる探索が可能になる。ノード探索クエリ-ノードの探索に関連する要求又は応答。通知notification-ある一連のノードに対して対象の通知メッセージを送る又は届ける要求又は応答。セキュリティ信用証明交換SecurityCredentialExchange-ノードが、対の鍵keypairs、証明書certificate、又はそれらと同等のものなど、セキュリティ関連の情報を交換することを可能にする要求又は応答。サービス探索クエリ-一連の1つ以上のノードによって提供されるサービスの探索に関する要求又は応答。サービス編成サービスプロバイダにより指定されたルールに従った管理可能な、単位の大きいサービス、再利用可能なコンポーネント、完全なアプリケーション向けサービスの組み立て及び連携を行うこと。実例には、プロバイダの自己証明、サービスの種類、サービスへのアクセス方法、サービスを構成する順序等に基づいたルール等が挙げられる。信用管理TrustManagement-ノード間のインタラクションのための許可信用状況の作成に関する共通の一連の仕様及びプロトコルを提供する。一部の実施例において、NEMO信用管理は、ウェブサービス分野におけるWSSecurity及びWSPolicyを含む既存のセキュリティ仕様及び機構を活用及び又は拡張できる。アップグレード-機能アップグレードの受信に関する要求又は応答を表す。ある実施例において、このサービスは、具体的な表現を提供するその他プロファイルと共に純粋に抽象的である。1.5ノード間の具体的なインタラクション以下に詳細が論じられている通り、2つのシステムノードサービス要求者及びサービス提供者間の基本的な論理インタラクションは、一般的に以下の一連の事象を含む。これらはサービス要求ノードの観点から見たものとする。サービス要求ノードはサービス探索要求を作成して、指定のサービスバインディングを使用する必要なサービスを提供できる、NEMOが有効となるいかなるノードを探す。ノードは探索したサービスに関する情報のキャッシュを選択できる。ノード間のサービス探索用インタフェースメカニズムは、NEMOノードが実装を選択する別のサービスであると言える。ノードを提供する候補サービスが見つかると、要求ノードは、指定のサービスバインディングに基づいてノードを提供する1つ以上のサービスへ要求を送信することを選択できる。ある実施例において、お互いにセキュアな通信を行うことを望む2つのノードはWSDLメッセージを交換する目的で信頼関係を構築する。例えば、それら2つのノードは、自己証明の判断、許可の確認、セキュアなチャネルの構築等に使用される、一連の互換性のある信頼証明例、X500証明書、デバイス鍵等を交渉できる。時には、これら証明書の交渉は、サービスインタフェースバインディング例、WSIXMLプロトコル使用時にはWSSecurity、又は2つのよく知られたノード間におけるSSL要求の暗黙的な性質のものであるかもしれない。その他の場合では、信頼証明書の交渉は、明示的な別の手順であるかもしれない。ある実施例において、どの証明書が別のノードとのインタラクションにとって十分であるかの判断、またあるノードを信頼できるかの判断は所定のノード次第である。要求ノードは、要求されたサービスに対応する適切なWSDL要求メッセージを作成する。メッセージが作成されると、対象のサービス提供ノードへ送信される。要求の通信スタイルは、例えば同期又は非同期のRPCスタイル、又はサービスバインディングに基づくメッセージ指向であるかもしれない。サービス要求の送信及び応答の受信は、デバイスによって直接行われても、NEMOサービスプロキシを通じて行われてもよい。サービスプロキシ以下で説明は、他の参加者へメッセージを送信するための抽象化及びインタフェースを提供し、互換性のあるメッセージフォーマット、運搬の仕組み、メッセージルーティング問題等、特定のサービスバインディング問題を隠蔽できる。要求を送信後、要求ノードは一般的に1つ以上の応答を受信する。サービスインタフェースバインディングの仕様及び要求ノードのタイプに従って、応答は、RPCスタイルの応答又は通知メッセージを含むなど、さまざまな方法で返される。対象のノードへ送られる応答は、例えばルーティング、信用交渉、照合、及び相関機能等を含む多数の関連サービスを提供する他の中間ノードを経由することもある。要求ノードは応答を検証し、そのノードとサービス提供ノード間で交渉した信頼操作に固守していることを確認する。そしてメッセージペイロードの種類及び内容に基づいて適切な処理が適用される。サービス提供ノードの観点から、一連の事象は一般的に以下のものを含む。要求されたサービスに対応しているかどうかを判断する。ある実施例において、NEMOフレームワークはスタイル、又はサービスインタフェースがサービスへのエントリーポイントとしてマップする方法の精度を指定しない。最も簡単な場合では、サービスインタフェースは所定のサービス及びバインディングの操作に対して詳細にマップでき、実施によりサービスの対応を構成できる。しかし、一部の実施例では、単一のサービスインタフェースが複数の種類の要求を取り扱うこともあり、あるサービスの種類が、ノードが明確に所望の機能に対応するという決定を行う前に検討が必要な追加の属性を含むかもしれない。ある場合では、サービスプロバイダが、要求ノードを信頼しているかを判断し、一連の互換性のある信頼証明書を取り決めることが必要かもしれない。ある実施例において、サービスプロバイダが信頼性を判断するかどうかに関係なく、サービスインタフェースに関連するポリシーが依然として適用される。サービスプロバイダは、要求ノードがアクセス権を持つかを判断するために、インタフェースへのアクセスを許可する責任を持つそれらノードに対して決定を下し、許可要求を送信する。多くの場合、許可ノード及びサービス提供ノードは同一のエンティティであり、許可要求の送信及び処理は、C言語関数のエントリーポイントといった処理が軽いサービスインタフェースバインディングを通じて実行される局部的な処理である。許可応答の受信時に、要求ノードが許可された場合、サービスプロバイダは要求に応じる。許可されない場合、適切な応答メッセージが生成される。応答メッセージは、サービスインタフェースバインディング及び要求ノードのプリファレンスpreferenceに基づいて返信される。要求ノードへのルーティング時に、メッセージは、必要なサービス又は付加価値のあるサービスを提供する他の中間ノードを経由できる。例えば、中間ノードはルーティング、信用交渉、又は要求ノードに受け入れ可能な方法でメッセージを配送できる通知処理ノードへの配送を提供する場合がある。付加価値のあるサービスの例としては、要求ノードの興味に応じてメッセージにクーポンを付け加えるクーポンサービスがある。2.システム構造DRMアプリケーションを実装している図1に図示される、NEMOシステムフレームワークのサンプル実施例について考察する。上記で言及した通り、NEMOノードは、サービス実施要求を作成し応答を受信することによりインタラクションを行うことができる。NEMOフレームワークは、単一のサービスプロバイダでの単純なポイントツーポイントのインタラクションから、複数のサービスプロバイダにより規定された一連のサービスの複雑な集合まで、多様で内容の込み入った通信パターンの構造に対応する。図1の状況において、NEMOノードはお互いにインタラクションし、全体として音楽ライセンスシステムを実装するさまざまなサービスを提供する。消費者音楽ロッカー110に格納された音楽は、ウェブ音楽小売業者120によって引き出され、エンタテーメントホームゲートウェイ130を通じて各家庭のエンドユーザに提供できる。消費者音楽ロッカー110の音楽は、その音楽がウェブ音楽小売業者120に提供され、その後さらなる使用及び分散のために他人へ渡される状況を統治するルールを含むこともある。エンタテーメントホームゲートウェイ130は、例えば、ユーザの家庭用PC例、PCソフトウェアビデオプレーヤ140を通じて又はユーザの携帯型再生デバイス例、携帯音楽プレーヤ150など、当該音楽ビデオ及びその他コンテンツを再生できる箱である。ユーザは、例えば携帯音楽プレーヤ150を持って旅行に出かけ、ワイヤレスインターネット接続を通じて例、デジタル権利ライセンスサービス160へアクセスしライセンスを入手して追加の楽曲を購入又は既存の楽曲をさらに再生したり、ソフトウェアップグレードサービス170を通じて携帯音楽プレーヤ150に新規機能を追加したりさえするかもしれない。NEMOノードはさまざまな異なった方法でお互いにインタラクション又は他のデバイスとインタラクションできる。図2Aに図示されているようなNEMOホストは、少なくとも1つのNEMOノードを持つ何かしらの機械又はデバイスである。ホストはパーソナルエリアネットワーク210内に、又はインターネットを通じてアクセス可能な遠隔地220に常駐することができる。ホストは、例えばサーバ230、デスクトップPC240、ラップトップ250、又はPDA260であり得る。NEMOノードはソフトウェアエージェントで、サードパーティ製のウェブサービスを提供するホスト235など他のノードへサービスを提供できるばかりでなく、NEMO管理フレームワーク内にある他のノードのサービスを実施できる。一部のノード270は、Bluetooth登録商標など専用通信チャネルを通じて別のホストへ拘束される。これらホスト240及び250はネットワーク接続が可能なであり、他の参加NEMOノードに対して仮想ノードを示す十分な処理能力を持つ。図2Bに図示の通り、NEMOノードはローカルエリアネットワーク又はパーソナルエリアネットワーク210内で完全なピアとなることができる。ノードはサービスの公開及び実施という対称的な能力を共有する。しかし、各ノードは通常、同一セットのサービスを提供しない。ノードは実行するサービスを告知、及び又は、それらのノードが実行するサービスについての具体的に問い合わせを受ける。図2Cに示す通りインターネット接続がある場合、ローカルのNEMOノード例、パーソナルエリアネットワーク210内は遠隔ノード220のサービスにアクセスもできる。ローカルネットワークの構成及びポリシー次第で、ローカル及び遠隔ノード例、インターネット可能なNEMOホスト280がNEMOピアとして相互運用することも可能である。図2Dに図示の通り、遠隔でもNEMOノードの全てが他のホストと通信可能なホスト上になくてはならないということはない。NEMOホスト280は、拘束ノード285又はパーソナルエリアネットワーク210内のノードなど、あるノードが別のサービスを実施できるようなゲートウェイサービスを提供できる。図2Eに図示の通り、拘束デバイス上のノード295は、上述の通りゲートウェイを通じて他のノードのサービスにアクセスできる。また、別のホスト290上のプロキシサービスを通じて他のノードによりアクセスできる。プロキシサービスはNEMOホスト上で実行する仮想ノードを作成するものである。これらプロキシノードは完全なNEMOピアとなることができる。図2Fに図示の通り、NEMOホストはNEMOノードアダプタを通じて拘束デバイスのための専用サポートを提供できる。専用通信チャネル296は、適切なプロトコルを使用するホストNEMOデバイスアダプタ297及び拘束ノード298の間で使用される。拘束ノード298は、他のNEMOピアノードを見ることはなく、他のNEMOピアノードからの可視性もない。次に、特定の実施例においてNEMOが有効になっているデバイスにより提供が可能な、又はNEMO状況外で使用可能な、模範的なデジタル権利管理DRM機能について考察する。以前述べた通り、NEMOシステムフレームワークの望ましい実施例の主要目的の1つは、商用ネットワークレイヤ及び消費者指向ネットワークレイヤの双方が、メディア関連サービス間で、セキュアで相互運用可能な相互接続の開発をサポートすることである。サービス接続に加え、メディア関連サービス間の相互運用は、それらサービスを通じて利用可能なコンテンツに適用されるように、しばしば使用権の組織的な管理を必要とする。ここで述べられているNEMOサービス及び模範的なDRMエンジンは、NEMOフレームワークに基づくデバイスが、異種DRM及びメディアフォーマット基盤のタイプにもかかわらず、消費者にシームレスな性能及び使用経験を提供することを可能にする相互運用を達成するために組合せて使用することができる。DRMアプリケーションの状況において、図3に図示の通り、NEMOが有効になったデバイスのネットワークは、他のDRMデバイス、及び保護コンテンツを再生できるだけでなく、携帯デバイス340向けに配信できるコンテンツを保存することもできる消費者PCプレーヤ330及び消費者PCパッケージャプレーヤ320向けのコンテンツを保存できるコンテンツプロバイダサーバ310を含む。各DRMデバイス内で、DRMエンジンは、特定のDRM機能例、ライセンス条件の施行、ホストアプリケーションへの鍵の引渡し等を実行し、暗号化、復号化、及びファイル管理などホストによって最も効果的に提供されるこれらサービス用のホストアプリケーションを頼る。以下で詳述される通り、ある実施例においては、DRMエンジンは、保護コンテンツ上で特定の挙動が許可されるかどうかを判断するために設計されたバーチャルマシンVMを含む。この制御VMは、最低限の指示セットを持つ単純なスタックベースのマシンとして実装できる。ある実施例では、論理的及び算術的な計算、及びホスト環境に状態情報を問合せ、システム時間、カウンタ状況等のパラメータをチェックすることができる。ある実施例では、DRMエンジンは、エンティティ及びDRMの価値連鎖間の関係を検証するために、グラフベースのアルゴリズムを活用する。図4は、そのグラフの概念的な実施例を図示する。グラフはリンクによって接続されたノード又は頂点の集合から構成される。システム内の各エンティティは頂点オブジェクトvertexobejectにより表される。リンクオブジェクトにより参照の必要がある、又は、暗号化の対象情報の受信機となる必要があるエンティティのみ、対応する頂点オブジェクトを持つ必要がある。ある実施例では、頂点は一般的にユーザ、デバイス、グループを表す。頂点オブジェクトは、頂点に関連するエンティティの特定の特性を表す関連属性も持つ。例えば、図4は、2人のユーザシャン及びノックス、2つのデバイスMac及び携帯デバイス、及びグループを表すいくつかのエンティティケーリー一家のメンバー、公共図書館のメンバー、特定の音楽サービスの加入者、RIAA承認デバイス、及び特有の会社で製造されたデバイスを示す。これらのそれぞれが関連する頂点オブジェクトを持つ。リンクの意味は、各アプリケーションに固有の方法において変化しうる。例えば、Macの頂点からノックスの頂点までの方向を持つ辺directededgeは、ノックスがMacの所有者であることを意味する。ノックスから公共図書館への辺はノックスが公共図書館のメンバーであることを指す。ある実施例では、DRMエンジンはこれらの意味を強要したり翻訳したりせず、単にグラフにあるパスの存在又は非存在を確認する。この頂点グラフは、2つの頂点間のパス又は関係直接的又は間接的の存在が片方の頂点から別の頂点へのアクセス許可として解釈されるという点から、承認authorizationグラフとして考慮できる。例えば、ノックスはケーリー一家へリンクされ、ケーリー一家は音楽サービスへリンクされているため、ノックス及び音楽サービス間のパスが存在する。音楽サービス頂点は、ある頂点から音楽サービスへのパスがある場合にその頂点から到達可能と考慮される。これは、アクセスを要求するアプリケーション例、DRMクライアントホストアプリケーションが実行する携帯デバイスから音楽サービスへ到達可能であるという条件に基づき、保護コンテンツにアクセスする許可が、コントロールに書き込むことを認める。例えば、コンテンツ所有者は、消費デバイスが公共図書館のメンバーによって所有され、RIAAの承認を受けている場合に特定の音楽を再生できる制御VMによって翻訳interpretされる制御プログラムを作成できる。デバイス上で操作している制御VMがこの制御プログラムを評価するとき、DRMエンジンは、携帯デバイス及び公共図書館の間、並びに携帯デバイス及び承認RIAAの間にリンクが存在するかを判断する。グラフの辺及び頂点は静的であり、かつ、デバイス内に構築され、又は、動的で、そして、ホストアプリケーションと通信するサービスを通じて発見される。頂点及びリンク上に意味semanticsを課さないことで、DRMエンジンには大きな柔軟性が可能となる。システムは、従来の委譲ベースのポリシーシステムから、承認ドメイン及びパーソナルエリアネットワークへの多数の使用モデルに適用できる。ある実施例では、DRMクライアントは承認グラフをコンテンツ保護鍵導出用に再利用もできる。システム設計者は、リンクの存在が特定の暗号情報の共有を意味するように選択することもできる。そのような場合、承認グラフは、明示的に消費デバイスを再度暗号化の対象とすることなく、コンテンツ鍵の導出に使用できる。3ノード構造3.1概要消費者向け電子機器、ネットワーク型サービス、又はソフトウェアクライアントを含むあらゆる種類のデバイス物理的又は仮想的は潜在的にNEMOが有効であり、デバイスの機能はNEMOシステムに参加できるように拡張できることを意味する。ある実施例では、NEMOが有効なデバイスノードは、図5Aに図示の通り、特定の標準モジュールから概念的に構成される。ネイティブサービスAPI510は、デバイスが実装する1つ以上のサービスの論理的なセットを表す。NEMOノードは、直接的又は間接的に、いかなるサービスをも公開する要求はない。ネイティブサービス実装520は、ネイティブサービスAPIに対応する一連の実装を表す。サービスアクセスポイント530は、公開されたサービスインタフェース実施への呼び出しを提供する。それは、NEMOノードがサービス実施要求を対象となる一連のサービス提供NEMOノードに対して行い、一連の応答を受信することを可能にするために必要な機能をカプセル化する。NEMOが有効になっているノードは、柔軟で拡張可能な通信APIの作成を伴う多様な探索、名前解決、及びトランスポートプロトコルを使用することもある。サービスアクセスポイントは、特定の実行環境及びアプリケーションフレームワークスタイルに合わせ、さまざまな方法で実現できる。インタフェース用のある共通の一般的モデルの1つは、一部の形式によるXMLメッセージを受信でき、XMLメッセージを返信するインタフェースである。より多くのネイティブインタフェースを持つ他のモデルもサポート可能である。NEMOサービス適応レイヤ540は、任意のレイヤを表し、そのレイヤを通して、ネイティブサービスのエンティティの公開サブセットは、1つ以上の発見可能discoverableなバインディングを用いてアクセスされる。そのレイヤは、ネイティブサービスAPIの上に抽象レベルを提供し、サービスプロバイダが複数の種類のサービスインタフェースバインディングにより簡単にサポートできるようにする。サービス適応レイヤが存在しない状況では、必要な通信プロトコルにサポートしていれば、サービスアクセスポイント530を通じて直接サービスにインタラクションすることは、やはり可能である。サービス適応レイヤ540は、サービスプロバイダがNEMOフレームワーク内でサービスを公開し、要求及び応答を処理し、サービスを調整する共通の方法を提供する。そのレイヤは、サービスを公開する論理ポイントであり、他の特定のサービスインタフェースバインディングを実装する基礎を提供する。サービス適応レイヤ540はサービスプロバイダのネイティブサービスを他のNEMOが有効なノードに公開する一般的方法を提供することに加え、図5Bに図示の通り、追加のサービスインタフェースバインディング560に対応するためにコンポーネントをレイヤ状にする平常の場所も提供する。追加のサービスインタフェースバインディングに対応することで、サービスプロバイダは、互換性のあるバインディングをネゴシエートでき、サービスアクセスポイントによって又はその他ネイティブAPIを通じて使用できる可能性が増加する。図5Aに戻るが、ワークフロー照合部550は、サービスメッセージ及びサービス編成のサポート管理を提供する。それは、ノードが要求及び応答メッセージの集合を管理及び処理できるようにする共通のインタフェースを提供する。このインタフェースは、基本的なビルディングブロックを提供し、それらサービスに関連するメッセージの管理を通じてサービスを編成する。このインタフェースは一般的に、メッセージルーティング機能及びメッセージの中間待ち状態及び照合に対応するノードによって実装される。一部の実施例では、NEMOフレームワークは、ネットワークへのエンティティの参加を容易にする任意のサポートサービスのコレクションを含む。当該サービスは、さまざまな種類の機能、及び当該サービスを必要とする実態の種類例えば、サービスプロバイダが必要とするものに反した、クライアントアプリケーションに対応するサービスにしたがって分類することができる。一般的に対応するサービスには以下のものが含まれる。WSDLフォーマット化及び操作ルーチン-WSDLベースのサービスメッセージの作成及び操作用の機能を提供する。サービスキャッシュ-ノードが、発見可能なノード、及び、それらがサポートするサービス間のマッピングのコレクションを管理できるようにする共通のインタフェースを提供する。通知プロセッサインタフェース-一部の明確に定義された通知処理エンジンへの通知処理に対応するNEMOノードを拡張するための共通サービスプロバイダインタフェースを提供する。その他サポート機能-メッセージID、タイムスタンプ等を生成するルーチンを含む。3.2基本ノードインタラクションNEMOノードの個々の構造的要素をさらに詳細に検討する前に、そのノードが他のノードとインタラクションして通信を行う方法を理解しておくことは有意義である。これらノードは、同期及び非同期のRPCスタイル通信から、一方通行のインタフェース呼び出し、及び、クライアントのコールバックまでさまざまな通信スタイルをサポートする。非同期RPC配送スタイル-このモデルは、要求を満たすことに時間がかかり、クライアントが待つことを望まないと予想される場合に特に適切である。クライアントは、要求がサービス提供ノードによって非同期の方法で処理されるという期待と共に要求を出す。この場合、サービス提供エンドポイントは、このモデルに対応しないという応答をすることができる、又は、サービス提供ノードがこのモデルに対応しない場合、クライアントの要求に対する応答があるかどうか判断する要求に続き、所定のサービス提供ノードに送ることができるチケットを含む応答を返す。ある実施例では、このモデルに対応しないいかなるサービス提供エンドポイントも、内部ポリシーに基づいてクライアント要求を保留するために、応答のキャッシュが義務付けられる。クライアントが当該要求に関連したチケットの償還を試み、応答が全く無い場合、又はサービス提供ノードによって応答が破棄された場合、適切なエラー応答が返される。この実施例において、応答のためのチケットを償還する試みの中で、いつそのような後続の要求を行うかの判断はクライアントに依存する。同期RPC配送スタイル-クライアントは要求を送り出し、返される1つ以上の応答を待つ。NEMOが有効なサービスを提供する側のエンドポイントは、このモデルに対応しないという応答を返すことができる。メッセージベース配送スタイル-クライアントは、サービスインタフェースを取り扱う1つ以上の通知に関連するメッセージ通知を通じて応答を受信したいという要求を送り出す。NEMOが有効な、サービスを提供する側のエンドポイントは、このモデルに対応しないという応答を返すことができる。クライアントアプリケーションの視点から、上記インタラクションパターンのいずれも、応答をブロックして待たなければいけない又は明示的にポーリングを行わなければいけないという構造を必要としない。スレッド又は他のプラットフォーム固有の仕組みを使用して、上記配送スタイルの仕組みと共にブロッキング及び非ブロッキング構造の双方をモデル化することが可能である。また、上記スタイルのいずれも、ある通信チャネルの遅延に関連する問題に直接取り組むことを目的としていない。要求に対する実際の達成に関連する潜在的な遅延のみである。通信チャネルの遅延に関連する問題を扱う仕組みは、サービスアクセスポイントなどコンポーネントの特定の実装にて、又は直接クライアントの実装内にて取り組むべきである。3.3.サービスアクセスポイント上記の通り、サービスアクセスポイントSAPは、サービス実装の目的で、再使用可能な共通APIとして使用できる。トランスポートチャネルの交渉や使用をカプセル化できる。例えば、トランスポートチャネルによっては、TCPIP上にSSLセッションの設定が必要であるが、チャンネルによっては、比較的信頼性の低い通信だけをUDPIP上でサポートしているか、また、まだIPベースでは全くないものもある。SAPはメッセージ経路の決定の初期のNEMOノードセットのディスカバリをカプセル化できる。例えば、ケーブルセットトップボックスは、ネットワークへの専用接続があり、全てのメッセージが、特定のルートと中継を通過するように命令することができる。ホームネットワークの携帯用メディアプレーヤは、直接アクセス可能な複数のノードを見つけるUPnPディスカバリを使用することができる。クライアントは、XMLメッセージを交換することにより、その他のNEMOノードと直接会話することそのものができない、あるいは、会話することを選択できない場合がある。この場合、SAPのバージョンを使用することができ、ネイティブインタフェースがサポートされているものを公開して使用する。好ましい実施例においては、SAPパターンは次の2つの共通通信モデルをサポートするこの2つの組合せに加えてその他の組合せもサポートされる場合がある。iメッセージベース上記で検討したとおり-SAPがXML要求メッセージを形成し、いくつかのインタフェースバインディングによりNEMOメッセージをサービスプロバイダと直接交換する場所、又はiiネイティブ-SAPが、いくつかのネイティブ通信プロトコルによりサービスプロバイダとインタラクションを行うことができる場所。SAPはフレームワーク内にどこでも定義されたXMLメッセージとの翻訳を内部で行うことができる。2つのNEMOピアノード間でのインタラクションの例が図6Aに示される。クライアントノード610は、NEMOサービスアクセスポイントSAP620を使用して、サービス提供ノード660とインタラクションしている。この例では、ウェブサービスプロトコルや標準仕様は、サービスの公開とトランスポート双方に使用される。サービス提供ノード660は、ノード610のようなクライアントにそのサービスを公開するために、そのウェブサービスレイヤ670を使用する例えば、WSDLやSOAPベースのメッセージングを使用する。クライアントノード610のウェブサービスレイヤ630は、マッピングレイヤ640SOAPメッセージとSAPインタフェース620との間をマッピングするやトラスト管理処理レイヤ650例えば、SOAPヘッダ内で運ばれた信用証明を使用して、WSセキュリティを利用することができるからの助けにより、SOAPメッセージを作成し、かつ、翻訳する。NEMOノード間のインタラクションの別の例は、図6Bに示される。サービス提供ノード682は、SAP686を使用して、クライアントノード684とインタラクションする。この例では、サービス提供ノード682は、クライアント684ではなく、相互運用可能なトラスト管理レイヤを含む。特に、サービス提供ノード682はトラストエンジン688と認証エンジン690の双方を含む。この例では、トラストエンジン688は、一般的に、デジタル証明書及びその他の基本的な暗号操作のために、SOAPメッセージの暗号化と解読の実施に責任を持つ場合もあるが、承認エンジン690は、より高度なポリシー決定に責任を持つ場合もある。図6Bに示された例では、クライアントノード684は、トラストエンジン692を含むが、認証エンジンは含まない。このように、この例では、クライアントノード684は、基本的な暗号化と解読、及び、比較的簡単なポリシー例えば、メッセージ承認、機密性などに関するポリシーを実施する機能を持つ場合があるが、サービス及びあるいはサービス提供ノード682により提供されるコンテンツに対するクライアントの使用や、インタラクションを支配する高度なポリシーの評価や実行にはサービス提供ノード682に依存する場合がある。図6Bは、図解の目的で提供されているが、これに限定されず、その他の実施例では、クライアントノード684が、クライアントが特定のポリシーに関連する一連の義務を厳守することを必要とした場合など、承認エンジンも含む場合があることを理解されたい。このように、それぞれの要件に応じて、別のNEMOピアにはトラスト管理フレームワークの別部分を含むことが理解できる。図6Bは、ノード間の通信リンクがトランスポートにとらわれないことが可能であることも示す。SOAP処理モデルの状況においても、任意の最適なデータコード化及びあるいはルール処理が使用できる。例えば、XMLセキュリティモデルは、異なるコード化方法でサポートされた別のセキュリティモデルで置換できる。サービスアクセスポイントは、クライアント境界内共有ライブラリの形、あるいは、クライアントの境界外異なるプロセスを実行しているエージェントの形など、さまざまな形で実装できる。サービスアクセスポイント実装の正確な形は、特定の種類のプラットフォームあるいはクライアントの必要性に応じて、カスタマイズすることができる。クライアントの立場からは、以下に示すように一般的にはサービスアクセスポイントの使用は重要なユーティリティを提供するが、サービスアクセスポイントの使用はオプションにできる。サービスアクセスポイントは、決まった一連のサービスプロトコルバインディングだけをサポートする静的コンポーネントとして実装できるが、新しいバインディングを動的にサポートすることもできる。サービスアクセスポイントが関与するインタラクションは、少なくとも2つの立場、つまり、参加者の使用を要求するクライアント側と他のNEMOが有効なエンドポイントノードとインタラクションするサービス側から特徴づけられる。クライアント側の一例は、図7Aに示されるが、サービスアクセスポイント710は、クライアント720と直接XMLメッセージを交換する。クライアント720は、直接要求メッセージ740を形成し、それらをサービスアクセスポイント710に提出する。サービスアクセスポイント710は、1つ以上の返信メッセージ750をクライアント720に作成して送信し、それらは収集、分析、処理される。クライアント720は、要求の配信を目的として使用するために要求時にはサービスバインディング730の明示的セットも提出する場合がある。これらのサービスバインディングは、さまざまな方法で取得されている場合がある。例えば、クライアント720は、サービスディスカバリ操作を実施して、どのサービスバインディングが適用可能であるかを選択することができる。あるいは、以前の応答から取得された情報を使用できる。別のクライアント側の実施例は、図7Bに示されるが、サービスアクセスポイント760は、クライアント780のネイティブプロトコル770を直接サポートする。サービスアクセスポイント760は、XMLとそのネイティブプロトコル770の間で内部的にメッセージを翻訳するので、クライアント780のNEMOシステム内の関与を可能にする。このようなサポートを有効にするために、ネイティブプロトコル770あるいはネイティブ770と実行環境の組合せは、適当な要求を生成し、必要であれば、適切なターゲットサービスバインディングを決定するサービスアクセスポイント760になんらかの形で任意の必要な情報を提供しなければならない。サービス側では、クライアントのサービスアクセスポイントとNEMOが有効なサービスを提供するエンドポイントの間での複数のパターンのインタラクションをサポートすることが可能である。クライアント側のように、インタラクションパターンはカスタマイズすることが可能で、要求の性質、基本の通信ネットワーク、ターゲットのサービスバインディングに関連するアプリケーション及びあるいはトランスポートプロトコルの性質など、さまざまな条件を基本にして、変行することができる。比較的簡単な種類のサービス側のインタラクションパターンが図7Cに示されているが、ここでは、サービスアクセスポイント711は、ポイントツーポイント方式で、目的のサービス提供ノード712と直接通信する。図7Dを見ると、サービスアクセスポイント721は、複数の潜在的サービスプロバイダ725と直接通信を開始することができるそして、直接応答を受け取ることができる。この種類のインタラクションパターンは、サービスアクセスポイント721による使用を目的として、クライアントからの複数のサービスバインディングを中継することにより実装できる。あるいは、ブロードキャストあるいはマルチキャストネットワークがメッセージを中継するためにサービスアクセスポイント721により利用することができる。要求に指定された優先事項を基に、サービスアクセスポイント721は、送信を収集し照合するあるいは、単に最初に許可可能な応答を返すことができる。図7Eでは、サービスアクセスポイント731は、どの目的のサービス提供エンドポイント735とも直接的に通信しない。代わりに、要求は、その要求を中継し、応答を受信し、それらをサービスアクセスポイント731に中継して戻す仲介ノード733を通じて経路が決定される。このようなインタラクションのパターンは、サービスアクセスポイント731がサービス提供エンドポイント735に関連するサービスバインディングを全く直接サポートできない、あるいはサポートしないが、ゲートウェイとして機能することを期待している中間ノード733との関係を確立できる場合には好ましい。あるいは、クライアントは、適切なサービス提供ノードを発見できない、あるいは発見できれば適切なサービス提供ノードに対するサービスバインディングを決定するが、中間ノード733が任意の適切なサービスプロバイダを自ら発見する試みを許可したいと期待しているかもしれない。更には、サービスアクセスポイント731は、中間ノードがより強固な収集や照合機能をサポートし、結果として、サービスアクセスポイント731とエンドポイント735のようなサービスプロバイダとの間に柔軟性の高い通信パターンを許可するため、中間ノード733の利点を好む場合もある。上記のサービス側の基本的なインタラクションパターンに加えて、このようなパターンや新しいパターンの組合せはサービスアクセスポイント内に実装できる。サービスアクセスポイントは、共通インタフェースを提供することを目的としているが、一般的に、その実装はNEMOが有効になったエンドポイントにより採用された通信モデルや関連プロトコルの特徴に強く関わる。実際には、サービスアクセスポイントは、XML表示WSDLの表示形式による、あるいは、オブジェクトを適切な表示にシリアル化する等や、適切な形式のXMLでコード化されたオブジェクトをエンベロープ化envalopingした表示等のような、IO関連データのマーシャリングmarshallingや非マーシャリングの処理論理をカプセル化するために使用できる。好ましい実施例では、SAPは1つ以上のサポートされたアプリケーション、セッション、及びあるいは、SOAPのエンベロープ化を使用したHTTP上でのサービス実施といったトランスポートプロトコル経由の通信論理もカプセル化する。最後に、いくつかの実施例では、SAPは、SSLTLSセッションの確立、及び又は、XML署名やXML暗号化のような標準仕様によるデータの署名検証のサポートのような、メッセージ調整や機密の論理をカプセル化することもできる。サービスインタフェースの特定のアドレスが未知、あるいは未指定例えば、いくつかの検索条件に基づき複数のノードでサービスを起動する場合である場合、SAPはサービスが発見あるいは解決される場所にあるデフォルト初期セットのNEMOノードを確立する論理をカプセル化することができる。以下は、SAP実施の一例としてエクスポートされた高レベルでの無制限タイプAPI記述の実施例である。ServiceAccessPointCreateは明示的にサービスクエリーサービスインタフェース1815aをサポートするノード群に向けて、そのノードが特定のサービスをサポートするかどうかを尋ねる要求を発する。もし要求ノード1810aが認証されると、サービス提供ノード1820aは、要求されたインタフェースそしてその関連サービスインタフェースバインディングがサポートされるかどうかの返答を発信する。これはノードがサービスを表明する場合、ノードによりサポートされる比較的一般的なインタフェースである。ノード登録-NEMOノード1810bは、そのサポートサービスを含む詳細をサービス提供ノード1820bのようなその他のノードに登録することができる。もしノードがインタフェース1815bをサポートする場合、その他のノードからの要求を受入れ、特定の規則に従ってそれらの詳細がキャッシュに格納される。これらのノード詳細は、キャッシュされた詳細があるノードへのサービスクエリーを実施する受理側のノード又はその他のノードにより利用可能なディレクトリとなる。P2Pへの登録に変わる方法として、ノードは検索サービス用のUDDI一般登録のようなパブリック登録を利用することもできる。イベントベース-ノードは状態の変化の通知1815aを関心があるノード1820cに送信するか、又は特定のサービスをサポートすることを宣伝する。通知1815aはノードとそのサービスの完全な記述を含んでいることもあれば、イベントに関連したノードのIDのみを含んでいることもある。関心があるノードは受入れ承認を選択し、通知をプロセスすることができる。4.4サービス認証と信頼の確立上記の通り、ある実施例では、NEMOは要請されたサービスへのアクセスを許可する前にまず要求ノードがそのサービスへのアクセスを許可されているか、またその場合にはどのような条件が付加されているかを決定する。アクセス許可はサービスリクエスタとサービスプロバイダ間の交信の信頼に基づいている。以下に説明されるように、ノードは信頼できると判断した場合でも、サービス提供ノードにより特定のサービス又は複数のサービスへのアクセスを認可する前に特定の規則を満たすことを要求することもある。ある実施例では、NEMOはお互いに信頼するかどうかを決定するための、任意のノード群により使用される特定の要求、カテゴリ又は意思決定論理を指定していない。トラスト動作はノードによりかなりの差があることもある。その代わり、MEMOはノードがお互いに受入れ可能な信頼関係を交渉するための一連の標準ファシリティーを提供する。ノード間の信頼の決定と確立にあたり、NEMOは信頼できる内容の確立に使用されるノード間の証明書の交換をサポートする。そのような信頼関係信用証明は、以下を含む各種のモデルを通じて交換することができる。サービスバインディングプロパティ-信頼信用証明がサービスインタフェースバインディングの一部として自動的に交換されるモデル。例えば、ノード1920aがサービスをSSL上でHTTPポストとして、又はWSセキュリティXML署名を必要とするウェブサービスとして表示する場合、当該サービスバインディングの実際のプロパティは、要求ノード1910aと共に必要とされる全ての信頼関連信用証明1915aを交信する。要請返答属性-信用証明の交換が、要求ノード1910bとサービス提供ノード1920bの間のWSDL要請と返答メッセージを通じて行われ、信用証明が任意にメッセージ1915bの属性として含まれる。例えば、デジタル証明書は要請と返答メッセージに添付されまた流通され、信頼関係を確立するために使用される。明示的交換-信用証明が、ノードに含まれる信用証明に関する情報のクエリーを許可するサービスプロバイダインタフェースを通じて明示的に交換されるモデル。これは通常最も綿密なモデルで、要求ノード1910cとサービス提供ノード1920c間で信用証明の交換が行われるには個別の往復セッションが必要とされる。サービスインタフェースバインディング自体は、信用証明の明示的交換のためのお互いに受入れ可能な信頼チャンネルを提供する。これらの基本的モデルの他にも、NEMOは個別の方法の組み合わせもサポートできる。例えば、完全に信頼できないサービスバインディングに関連したコミュニケーションチャンネルが、セキュリティ関連信用証明の交換をより直接ブートするため、又はセキュリティ関連信用証明に直接使用するため、あるいはサービスインタフェースバインディングに関連したセキュアなコミュニケーションチャンネルを確立するために使用されることもある。上記の通り、トラストモデル動作と信用を確立する処理は、エンティティにより差がある。ある状況においては、ノード間の相互信頼は必要とされないこともある。この形態のダイナミックな異機種環境では、個別のエンティティがコンテクストに敏感な信頼動作を施行するために、一定の設備を提供する融通性のあるモデルが必要とされる。4.5ポリシー管理されたアクセス実施様態の一例では、サービス提供ノードは、要求ノードがリソースにアクセスすることを許可する前に信頼できる状況を確立する要求に加え、要求ノードが当該リソースに関連したポリシーを満たすことを要求することもある。実施様態の一例では、NEMOはこの機能性をサポートするために一定の、融通性がある機構を提供している。サービス詳細の一部として、利用者は特定のNEMOノードを認証authorizationサービスプロバイダとして指定できる。実施様態の一例では、認証サービス提供ノードは、認定クエリー要請を処理し、対応するスタンダードサービスを実施する。サービスインタフェースにアクセスが許可される前に、対象サービスプロバイダは、サービスのために認証クエリー要求を任意の認証ノードに発し、一つ又はそれ以上のノードによりアクセスが許可されたという返答が得られた場合にのみアクセスが許される。図20に示されるように、要求ノード2010は特定のサービスの当初の要求を含め、サービス提供ノード2020とメッセージ2015を交換する。サービス提供ノード2020は次に要求ノード2010が当該サービスを呼び起こすことを許可されているかを決定し、これらのノード2030への当初の認証要求を含む要請されたサービスへのアクセスを管理する認証ノード2025と認証メッセージ2025を交換する。返答に従って、サービス提供ノード2020は関連サービス返答を処理し返信するか、又はアクセスが拒否されたことを処理し返信する。このように、認証サービスによりNEMOノードはポリシー決定ポイントの役割を分担できる。好ましい実施例においては、NEMOはポリシー管理システムに関して中立であり、認証ノードがどのように認証クエリーを基に認証決定を行うかを指示しない。しかし、相互運用のためには、認証要請と返答が同一の基準に従っており、また各種のポリシー管理システムの状況において多様の認証クエリー要請に対応するために、融通性があるペイロードを運べるように拡張が可能であることが好ましい。ある実施例においては、少なくとも以下の二つの認証フォーマットにサポートが提供されている。入力、シンプルリクエスタID、リソースID、及び又は、アクションIDなどの、きわめてまれな共通基準カテゴリを使用した非常に単純なエンベロープを提供する単純なフォーマット認証クエリーを内包するための標準セキュリティアサーションマークアップ言語ある実施例においては、認証ノードは少なくとも所定のシンプルフォーマットを認知サポートし、認証ノードのネイティブポリシー表現フォーマットに位置付けなくてはならない。その他のフォーマットについては、認証ノードは認証クエリー要請のパイロードを処理できないか又は理解できない場合は適切なエラー返答を返送する。拡張により、ノードが認証クエリーの受入れ可能のフォーマットをネゴシエートし、どのフォーマットが認証サービス提供ノードによってサポートされているかを決定するクエリーを行うことが可能となることがある。4.6基本的DRMノードインタラクションここで特定のNEMOにおけるDRMアプリケーションに戻る。図21は、DRMノードグラフであり、DRMノード間のインタラクションとその関係を示している。携帯機器2110がコンテンツプレイバック機器であるとする。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を暗号化するために使用される鍵である。GBC1はC1の管理情報である。Eはbが鍵aにより暗号化されていることを意味する。説明を目的として、ここでは機器は機器が図書館の会員に属し、機器がACMEにより製造されている限り、C1のコンテンツを再生できるという規則を確立することが希望されていると仮定する。コンテンツC1はKc1により暗号化されている。規制プログラム及び暗号化されたコンテンツ鍵RKC1Eが作成される。規制プログラムとRKC1は双方ともにコンテンツの管理ブロックGBC1に含めることができる。携帯機器はC1とGBC1を受信する。例えば両方とも同一のファイルに包含されていることもあれば、個別に受理されることもある。携帯機器はユーザが機器を購入し、最初にインストールしたときにL1を受理する。携帯機器はまたユーザが公立図書館に会員費を支払った時点でL2を受理する。さらに、携帯機器は製造された時点でL3を受け取っている。携帯機器は、L1、L2、L3を通じてNp1がNg、Npl、そしてNampへのグラフパスがあることを確認できる。携帯機器はC1を再生することを欲する。携帯機器はGBC1で認知した規則を起動する。規則はNip1がACME機器であり、公立図書館の会員に属していることを確認する。こうして規則はイエスと注文されたリストを返信する。携帯機器はKgを計算するためにL1を使用し、そしてKgからKplを算出するためにL2を使用する。また、携帯機器もKampを算出するためにL3を使用する。携帯機器はKplとKampをRKC1に適用し、GBC1を認知し、Kc1を算出する。ここで解読にKc1が使用され、C1が再生される。ノード鍵が前述の例のように左右対称の鍵である場合、コンテンツパッケージャは、コンテンツをバインドすることを希望するノードの鍵にアクセスする必要がある。これは、パッケージャを象徴するノードを作成し、そのノードと規則をバインドすることを希望するノードとの間にリンクを設けることにより達成される。また、サービスを通じてバインド外で同様の結果を達成することもできる。しかし、特定状況下ではこれは不可能であることもあり、対象鍵を使用することが実用的であることもある。この場合、知識を共有無しでバインドが必要とされるノードに一対の鍵を割り当てることが可能である。ここで、パッケージャはコンテンツ鍵をターゲットノードの公開鍵により暗号化することによりコンテンツ鍵をノードにバインドする。クライアントは当該ノードへのリンクを通じてノードの秘密鍵へアクセスすることにより、暗号解読のための鍵を取得できる。最も一般的な例では、規則に使用されるノードとコンテンツ暗号化鍵の算出に使用されるノードは同一である必要はない。コンテンツを管理する規則とそれを暗号化するために使用される鍵には密接な関係があるため、同一のノードを使用することは自然であるが、必ずしもその必要ない。特定のシステムでは、一部のノードは会員条件の表示に使用されないコンテンツ保護鍵に使用されることも、またその逆の場合もあり、そして特定の状況では二つの別々のノードのグラフ-一つは規則用でもう一つはコンテンツ保護用―が使用されることもある。例えば、規則は、全てのNplグループの会員はコンテンツC1へのアクセスがあるが、コンテンツ鍵Kc1は必ずしもKplにより保護されておらず、代わりにNplだけでなく全ての公立図書館を象徴するノードNaplのノード鍵Kaplにより保護されるとすることもある。又は、規則は、利用者はNampの会員である必要があるが、コンテンツ暗号化鍵はNplに限ってバインドされるとする場合もある。4.7.DRMの運用とバーチャルマシーン上記の図21に関する記述では、コンテンツ管理ポリシーの形成と実施を含め、DRMシステムがハイレベルで運用されている。図22には、そのようなコンテンツ管理ポリシーの形成と実施を行うDRMエンジンのVMの典型的なコードモジュール2200が示されている。図22に示される、コードモジュール2200の具体例の4つの主要素は以下の通りである。pkCMAtom:pkCMAtom2210はトップレベルのコードモジュールアトムであり、サブアトムのシーケンスを含む。pkDSAtom:pkDSAtom2220はデータセグメントにロードできるメモリイメージを含む。このペイロードのアトムはオクテット値の元シーケンスである。pkCSAtom:pkCSAtom2230はコードセグメントにロードできるメモリイメージを含む。このペイロードのアトムはオクテット値の元シーケンスである。pkEXAtom:pkEXAtom2240はエクスポートエントリーのリストを含む。各エクスポートエントリーは、8ビットサイズのコード化された名前、それに続く最後に0を加えた名前の漢字表記、それに続く名前が付けられたエントリーポイントのバイトオフセットを象徴する32ビットの整数値。4.7.1.モジュールローダある実施例では、コントロールVMはコードモジュールのローディングに責任を負う。コードモジュールがロードされると、pkDSアトム2220にコード化されたメモリイメージは、データセグメントのメモリー住所にロードされる。この住所はVMローダによって選択され、DS疑似レジスタに格納される。pkCSアトム2230にコード化されたメモリイメージはコードセグメントのメモリ住所にロードされる。この住所はVMローダによって選択され、CS疑似レジスタに格納される。4.7.2.システムコールある実施例では、コントロールVMプログラムは、コードモジュールのコードセグメント外で実施された機能を呼び出すことができる。これは、整数スタックオペランドを取り入れ、システムコール番号を指定するOPCALL指示の使用により行われる。システムコールにより、施行はVM固有の実施形態でVMにより指示される別のコードモジュールの制御VMバイトコードルーチンか、又はVMのホスト環境のような外部のソフトウェアモジュールに委託されることもある。ある実施例では、いくつかのシステムコール番号が指定されている:SYSNOP0:このコールは非オペレーションコールであり、単に返送を施行する。主にVMのテスト用に使用される。SYSDEBUGPRINT1:テキストをデバッグ出力にプリントする。このコールは単一のスタック引数を待ち、プリント用に空終結文字列を含むメモリ位置の住所を指定する。SYSFINDSYSCALLBYNAME2:VMが指名されたシステムコールを施行するかどうか決定する。その場合、システムコール番号はスタックに戻される。さもなければ、値1が返される。このコールは単一のスタック引数を待ち、要求された空終結システムコール名を含むメモリ位置の住所を指定する。4.7.3.システムコール番号割り当てある実施例では、制御VMはシステムコール番号の0から1023までを命令システムコール用に維持する。VMは、システムコール番号16384~32767を同時割り当てすることができる。4.7.4.標準システムコールある実施例では、制御プログラムの書き込みを促進するためにいくつかの標準システムコールが提供されている。そのような標準システムコールには、ホストからタイムスタンプを取得するコール、ノードが連絡可能かどうか決定するコール、そして又はそれに類似したコールが含まれる。システムコールは同時決定された番号であることが好まれる48.DRMエンジンインタフェースとホストアプリケーションの間のインタフェース以下は、DRMエンジンからホストアプリケーションに提供されたインタフェース形態の代表的な高水準記述の実例である。SystemNameCreateSessionSessionホストアプリケーションコンテクストに与えられたセッションを作成する。コンテクストオブジェクトは、コールバックをアプリケーションに組み入れるためにDRMエンジンにより使用される。SessionProcessObjectこの機能は、ホストアプリケーションがDRMシステムに属することが判明されたメディアファイルのオブジェクトの特定形態に遭遇したときにホストアプリケーションにより呼び出されるべきである。そのようなオブジェクトには、コンテンツコントロールプログラムや会員トークンなどが含まれる。これらのオブジェクトの構文解析や動作はホストアプリケーションには明らかでない。SessionOpenContentContentホストアプリケーションは、マルチメディアファイルと交信する必要があるときにこの機能を呼び出す。DRMエンジンは、コンテンツオブジェクトを返還し、コンテンツオブジェクトはその後そのコンテンツに関するDRM情報を検索し、またそのような情報と交信する必要がある場合に使用される。ContentGetDrmInfoコンテンツに関するDRMメタデータを返還する。これによりファイル用に通常のメタデータが利用できるようになる。ContentCreateActionActionホストアプリケーションは、コンテンツオブジェクトと交信する必要がある場合にこの機能を呼び出す。actionInfoパラメーターはアプリケーションがどのようなタイプのアクションを施行する必要があるか、また必要な場合はその関連パラメーターも指示する。ファンクションはアクションオブジェクトを返還し、アクションオブジェクトはその後アクションを施行し、コンテント鍵を検索するために使用される。ActionGetKeyInfo暗号解読サブシステムがコンテンツの暗号解読に必要な情報を返還する。ActionCheckDRMサブシステムがこのアクションの施行を許可するかどうかを検査するが施行されるかどうか。ActionPerformアクションを施行し、そのアクションを管理する規則により指定された帰結を遂行する。例示的HostApplicationによりDRMクライアント消費エンジンに対して提供されるインタフェースの種類の高レベル記述の例を次に示す。HostContextGetFileSystemFileSystemDRMサブシステムが占有的アクセスを有する仮想FileSystemオブジェクトを返す。この仮想FileSystemは、DRM状態情報を保存するために使用される。このFileSystem中のデータはDRMサブシステムだけが読出し書込み可能である。HostContextGetCurrentTimeホストシステムが維持する現在の日付時刻を返す。HostContextGetIdentityこのホストの一意的IDを返す。HostContextProcessObjectDRMオブジェクト中に埋込まれたかもしれないが、DRMサブシステムがホストにより管理されているもの例えば証書であると識別したデータオブジェクトをホストサービスに返す。HostContextVerifySignatureデータオブジェクトへのデジタル署名の有効性を検証する。好適には、signatureInfoオブジェクトはXMLSig要素に存在する情報と等価の情報を含むものである。HostServicesは、署名の有効性を図るために必要な鍵及び鍵証書を管理する責任がある。HostContextCreateCipherCipherデータを暗号化したり復号するためにDRMサブシステムが使用できるCipherオブジェクトを作成する。好適には、最小限の暗号型のセットが定義され、各型には暗号実現に必要な鍵情報を記述するための形式が定義される。CipherEncryptデータの暗号化で使用される上記のCipherオブジェクト。CipherDecryptデータの復号化で使用される上記のCipherオブジェクトHostContextCreateDigesterDigesterあるデータ上でセキュアなハッシュを計算するためにDRMサブシステムが使用できるDigesterオブジェクトを作成する。ダイジェスト型の最小限のセットが定義される。DigesterUpdateセキュアなハッシュを計算するために使用される上記のDigesterオブジェクト。DigesterGetDigestDRMサブシステムが計算したセキュアなハッシュを取得するために使用される上記のDigesterオブジェクト。例示的DRMエンジンによりHostApplicationに提供される種類のインタフェースの例示的高レベル記述を次に示す。SystemNameCreateSessionSessionHostApplicationContextが与えられるとセッションを作成する。DRMPackagingエンジンはコンテキストオブジェクトを使用してそのアプリケーションに対してコールバックを行う。SessionCreateContentContentHostApplicationは、以降のステップでライセンスオブジェクトに対応付けられるContentオブジェクトを作成するためにこの関数を呼ぶ。contentReferences配列中に複数のコンテンツ参照を持つことは、これらは1つのバンドル例えば1つのオーディオと1つのビデオトラックに束ねられており、発行されたライセンスは1つの分離不可能なグループとしてこれらにターゲットされなければならないことを示唆する。ContentSetDrmInfodrmInfoパラメータは、発行されるライセンスのメタデータを指定するものである。構造体は読み出され、ライセンスをVMのバイトコードに計算するためのガイドラインとして行為する。ContentGetDRMObjectsdrmObjectsDRMPackagingエンジンが作成したdrmObjectsをHostApplicationが取得する準備ができている時、この関数が呼ばれる。形式パラメータは、これらのオブジェクト例えばXML又はバイナリアトムに対して期待される形式を指定する。ContentGetKeyskeysこの関数は、コンテンツを暗号化するためにHostApplicationが鍵を必要とする時、呼ばれる。1つの実施例では、コンテンツ参照ごとに1つの鍵が存在する。例示的HostApplicationによりDRMエンジンに対して提供される種類のインタフェースの例示的高レベル記述を次に示す。HostContextGetFileSystemFileSystemDRMサブシステムが占有的アクセスを有する仮想FileSystemオブジェクトを返す。この仮想FileSystemは、DRM状態情報を保存するために使用される。このFileSystem中のデータはDRMサブシステムだけが読出し書込み可能である。HostContextGetCurrentTimeTimeホストシステムが維持する現在の日付時刻を返す。HostContextGetIdentifyIDこのホストの一意的IDを返す。HostContextPerformSignatureDRMPackagingエンジンによって作成されたDRMオブジェクトのうちあるものは信用されなければならない。ホストにより提供されるこのサービスは、指定されたオブジェクトに署名するために使用される。HostContextCreateCipherCipherDRMPackagingエンジンがデータ暗号化及び復号化に使用できるCipherオブジェクトを作成する。これは、ContentKeyオブジェクト中のコンテンツ鍵データの暗号化に使用される。CipherEncrypt上記の、データ暗号化に使用されるCipherオブジェクト。CipherDecrypt上記の、データ復号化に使用されるCipherオブジェクトHostContextCreateDigesterDigesterあるデータ上でセキュアなハッシュを計算するためにDRMPackagingエンジンが使用できるDigesterオブジェクトを作成する。DigesterUpdate上記の、セキュアなハッシュを計算するために使用されるDigesterオブジェクト。DigesterGetDigest上記の、DRMサブシステムが計算したセキュアなハッシュを取得するために使用されるDigesterオブジェクト。HostContextGenerateRandomNumber鍵生成に使用される乱数を生成する。5.サービス5.1概要アーキテクチャ的そして操作的視点の両方からNEMODRMシステムを説明したので、次に本システムの機能性を実現するために使用できるサービス、データ型、及び関連したオブジェクトプロファイルprofileの例示的集まりに焦点を当てる。前述のように、NEMOアーキテクチャの好適な実施例では、サービス呼出しに付随する要求と応答のシンタックス、フレームワーク内で使用されるデータ型、メッセージ包絡、及びNEMOフレームワーク内で公開され使用されるデータ値の柔軟性に富み、移植性のある方法が使用される。WSDL11以上では、様々な種類のサービスインタフェース及び呼び出しパターンを記述し、表現するために十分な柔軟性が提供されており、多様な通信プロトコルを介して様々な、異なるエンドポイントNodeへのバインディングを受入れるための十分な抽象性がある。1つの実施例では、プロフィルを主題的に関連したデータ型及びWSDLで定義されたインタフェースの集合と定義する。NEMOでは基本的NEMOノードインタラクションパターン及びインフラ機能性をサポートするために必要なデータ型とサービスメッセージの機能的集合を含むCoreプロファイルは、NEMOで実現可能なDigitalRightsManagementサービスを表すDRMプロファイルなどのアプリケーション特有のプロファイルから区別されている。その両者を次に述べる。これらのプロファイルで定義されるデータ型及びサービスのうち多くのものは抽象的で、使用の前に専化する必要があることを理解されたい。他のプロファイルはCoreプロファイルの上に構築される。5.2NEMOプロファイルの階層1つの実施例では、サービスインタフェース及び関連するデータ型の定義は、相互上に構築され、そして拡張可能な必須及び任意プロファイルの集合として構造化されている。あるプロファイルとプロファイル拡張との相違は比較的微妙である。一般的に、プロファイル拡張では新規データ型やサービス型の定義の追加は発生しない。これらは単に既存の抽象型及び具体型を拡張するものである。図23にNEMO及びDRM機能性の例示プロファイル階層を示す。このプロファイル階層の主要素には次が含まれる:CoreProfileこのプロファイル階層の基本には、CoreProfile2300が配置されているが、それは好適にはNEMO機能性とDRM機能性の双方を共有するものである。このプロファイルは、他の全てのプロファイルの土台を成す。それには、フレームワーク中でより多くの複合型を作成する基となる下記に述べる汎用型の基本集合も含まれる。CoreProfile中の型の多くのものは抽象的で、使用の前に専化する必要がある。CoreProfileExtensionsCoreProfile2300の直ぐ上には、CoreProfileExtensions2320があるが、それはCoreProfile2300中の型の一次専化であり、その結果具体的な表現が生じる。CoreServicesProfileCoreProfile2300の直ぐ上にさらに存在するものはCoreServicesProfile2310で後者は下記に述べる一般インフラサービスの集合を定義するものである。このプロファイルでは、サービス定義は抽象的で、使用の前に専化する必要がある。CoreServicesProfileExtensionsCoreProfileExtensions2320及びCoreServicesProfile2310の両方の直ぐ上には、CoreServicesProfileExtensions2330が構築されており、それはCoreServicesProfile2310中で定義されているサービスの一次専化であり、その結果具体的な表現が生じる。DRMProfileCoreProfile2300の直ぐ上にはDRMProfile2340が存在し、後者は他のDRM関連のプロファイルの土台を成す。DRMProfile2340は、より多くの複合DRM特定型を作成する基となる下記に述べる汎用型の基本集合も含まれる。DRMProfile2340中の型の多くのものは抽象的で、使用の前に専化する必要がある。DRMProfileExtensionsDRMProfile2340上に構築されているものはDRMProfileExtensions2350であり、それはDRMProfile2340中で定義されている型の一次専化であり、その結果具体的な表現が生じる。DRMServicesProfileDRMProfile2340の上にさらに構築されているものはDRMServicesProfile2360であり、それは、下記に述べる一般DRMサービスの集合を定義する。このプロファイルでは、サービス定義は抽象的で、使用の前に専化する必要がある。SpecificDRMProfileDRMProfileExtensions2350及びDRMServicesProfile2360の両方の上に構築されているのはSpecificDRMProfile2370であり、それはDRMServicesProfile2360に定義されているDRMサービスのさらなる専化である。このプロファイルもある種の新規の型を導入し、CoreProfileExtensions2320で指定されているある種の型を拡張するものである。5.3NEMOサービス及びサービス仕様このプロファイル階層内に、1つの実施例では、上記で詳細が説明されている次の主要なサービスコンストラクトが存在する。PeerDiscoveryシステム中のピアに相互発見をせしめる能力。ServiceDiscovery異なるピアにより提供されるサービスに関する情報を発見し、取得する能力。Authorization特定のピア例えばノードが特定の例えばサービスのような資源へのアクセスを認可されるかどうかを判定する能力。Notification特定のピア例えばノードの集合への、指定された基準に基づく、対象メッセージのデリバリに関連するサービス。この例示プロファイル階層中の主要DRMコンストラクトの上述の定義のうちあるものを次に示す。Personalization特定のDRMシステムのコンテキストで有効な自己識別を設立するために必要なDRM関連のエンドポイント例えば、CEデバイス、ミュージックプレイヤー、DRMライセンスサーバなどのために必要な信用証明、ポリシー、及び他のオブジェクトを取得するサービス。LicensingAcquisition新規DRMライセンスを取得するサービス。LicensingTranslation1つの新規DRMライセンス形式を他の形式に取り替えるサービス。Membershipある指定されたドメイン内でメンバーシップを設立する様々な型のオブジェクトを取得するサービス。NEMODRMプロファイル階層は、1つの実施例で、サービス、通信パターン、及びオペレーションの抽象集合を表すGenericInterfaceSpecifications、NEMOプロファイル中で定義されたデータ型を含むTypeSpecifications、及び抽象サービスインタフェースを、特定のプロトコルへのバインディングを含む具体的サービスインタフェースに写像するConcreteSpecificationsの集合として記述できる。これらの仕様の1つの実施例は、サービス定義及びプロファイルスキーマの形で本書の付記Cで規定されている。6他のアプリケーションシナリオDRMで保護された歌を再生する新しいミュージックプレイヤーを消費者が使用するというコンテキストで、NEMO操作の実施例の比較的簡単な例を図24に示す。しかし下記に示すように、このような簡単な例でも、多くの異なった、潜在的に関連するアプリケーションシナリオが示される。この例では、発見サービスの連結、すなわちUDDIベースのディレクトリサービスを見つけ出し、それにリンクする機構としてユニバーサルプラグアンドプレイベースのサービス発見の使用、が示される。また、この例では、PersonalAreaNetworkサービス及びWideAreaNetworkサービス間のサービスインタラクションサービス使用の信用されているコンテキストの交渉、及び新規デバイスとDRMサービスの提供の詳細が示されている。図24では、新しいミュージックプレイヤー2400を購入した消費者は、DRMで保護された歌を再生したいと考える。Player2400はこのDRMシステムをサポートするものであるが、個人化する必要がある。すなわち、Player2400はそれをNEMO有効でDRM対応にするある種の要素図示せずを含むものであるが、このシステムの一部となるためには最初に個人化プロセスを行う必要がある。典型的には、ひとつのNEMOクライアントは、他のノードのサービスを呼び出すServiceAccessPoint、それはある種の保護されたコンテンツを再生するための信用された資源であることを示すTrustManagementProcessing、そしてサービス呼び出し及びメッセージの作成と受理をサポートするWebServicesレイヤ、などの上記図5a及び6に示すある種の基本的要素を含んでいる。しかし下記に述べるように、ひとつのノードがNEMOシステムに参加できるようにするためにはこれらの要素の全てが必要なわけではない。ある実施例では、上記の図12A及び13-15に示すように、クライアントノードはある種の基本的、DRM関連の要素を含むことができる。例えば、保護された歌を復号したり、それらの歌を再生するための媒体レンダリングエンジンも含めて、保護されたコンテンツの処理を有効化するDRMクライアントエンジン及び暗号化サービスそして関連するオブジェクト及び暗号化鍵などである。ここでも、そのような要素のうちの一部は存在する必要はない。例えば、Player2400が非保護のコンテンツのみを再生できるミュージックプレイヤーであった場合、それは他のミュージックプレイヤーに含まれているコア暗号化要素は必要でないかもしれないのである。より具体的には、図24に示す例では、Player2400はワイヤーレスで、UPnPプロトコル及びBluetooth登録商標プロトコルをサポートし、署名を検証し、メッセージに署名するために使用する一組のX509証書を有している。Player2400は、限定された数のNEMOサービスメッセージを形成し、処理できるという点ではNEMO対応であるが、資源制約上それはNEMOServiceAccessPointを含んでいない。しかしPlayer2400はユーザの家庭ではPersonalAreaNetwork2410に参加できる。後者は、NEMO対応の、インターネットに接続されたBluetooth登録商標及びNEMOSAP2430搭載のHomeGatewayDevice2420を含む。Player2400及びGateway2420の双方のUPnPスタックは、下記に述べるNEMO対応Gatewayサービス用の新しいサービスプロファイルをサポートするために拡張された。ユーザが1つの歌をダウンロードしてそれを再生しようとした場合、Player2400はそれを個人化する必要があると判断して、そのプロセスを開始する。例えば、Player2400はPAN2410上のNEMOゲートウェイのためのUPnPサービス要求を開始する。それは1個のNEMOゲートウェイサービスを見つけだし、Gateway2420はPlayer2400がそのサービスに接続できるようにするために必要な情報を返す。次に、Player2400はNEMOPersonalization要求メッセージを形成し、それをゲートウェイサービスに送信する。その要求には、Player2400のデバイス識別体に対応する1つのX509証書が含まれている。その要求を受取ると、Gateway2420は要求をローカル的に満たすことができないと判断するが、他の潜在的サービスプロバイダを発見する能力がある。しかし、Gateway2420はそれが受取る全てのメッセージはデジタル的に署名されたものでなければならないというポリシーを持っており、従ってその要求を拒絶して、この種類の要求の処理に付随するポリシーを表明した認可失敗を返す。この拒絶を受取るとPlayer2400はサービス拒絶の理由に留意し、デジタル的に署名して例えば、図15に関連して前述のように、要求をGateway2420に再提出する。後者はメッセージを受け入れる。上記のように、Gateway2420はこの要求をローカル的には満たせないが、サービス発見を行うことはできる。Gateway2420は、そのSAP2430実現がサポートする特定の発見プロトコルは知らないので、所望のサービスの種類個人化に基づいて一般的属性ベースのサービス発見要求を作成して、その要求をSAP2430を介して送信する。インターネットベースのUDDIRegistry2440などのUDDIレジストリーと通信するのに必要な情報で構成されているSAP2430は、その要求を適正な形式のネイティブUDDI照会に変換し、その照会を送信する。UDDIRegistry2440はDRM個人化をサポートしているサービスプロバイダを知っており、照会の結果を返す。SAP2430はこれらの結果を受け取り、必要なサービスプロバイダ情報を含めて、正しい形式で適正な応答をGateway2420に返す。Gateway2420は、サービス発見応答からサービスプロバイダ情報を抽出し、初期の要求に基づいてPlayer2400のためにPersonalizationの新規要求を作成する。この要求がSAP2430に提出される。サービスプロバイダ情報特にPersonalizationService2450のサービスインタフェース記述は、WSDLに記述されているウェブサービスを介してそのサービスを公開する個人化サービスとどのようにしてSAP2430が通信すべきであるかを明らかにする。それらの案件に従って、SAP2430はPersonalizationService2450を呼び出し、応答を受け取る。次にGateway2420は応答をPlayer2400に返し、後者は応答のペイロードを使用してそのDRMエンジンを個人化できる。この時点で、Player2400は供給され、様々なローカル及びグローバルの消費者指向サービスに完全に参加できる。これらは、様々なローカル及び遠隔コンテンツサービス、ルックアップ、突合せ、及びライセンス授与サービス、そして追加自動供給サービスへの完全なビジビリティー及びアクセスを提供でき、全ては消費者のサービスで協働する。上記で説明したように、コンテンツプロバイダーにより課せられるどのようなポリシーをも消費者とPlayer2400が満たすことを前提として、ある種の保護されたコンテンツへのアクセスのために様々な復号化鍵が必要である。このようにして、家庭でパーソナルメディアプレイヤーを使用する消費者は、CEデバイスの単純性を享受できるが、ゲートウェイ及びピアデバイスにより提供されるサービスも利用できる。消費者が別の施設に移動すると、デバイスは家庭で使用可能なサービスの大部分か全てのサービスを再発見して利用することができる。そして、新規ゲートウェイサービスを介して、ホームネットワークに論理的に接続され、同時にそれらのサービスに付随する様々なポリシーに従って許容されている、利用可能なサービスを新しい施設で享受できる。また反対に、消費者のデバイスはその新しい施設で見つけられた各ピアにサービスを提供できる。明らかに、これらの同じコンストラクトNEMONode、SAP、ServiceApplicationLayer、XML、WSDL、SOAP、UDDIなどの様々の標準、などのうち幾つかあるいは全てを使用して、このDRMミュージックプレイヤーの例の範囲内でもその他の多くのシナリオが可能である。例えば、Player2400にそれ自体のSAPを含めて、Gateway2420の必要性を解消させることもできるであろう。UDDIRegistry2440を、例えばミュージックコンテンツを見つけたり及び又はライセンス授与をしたりなどの他の目的に使用してもよい。更に、他の幾つものDRMアプリケーションも構築できる。例えば、様々な区分のユーザのために幾つもの種類のオーディオ及びビデオのための、複雑な使用及び配布ポリシーを課したライセンス授与ス鍵ムを利用するアプリケーションなどである。また、DRMコンテキスト以外にも、実質上他のいかなるサービスベースのアプリケーションもNEMOフレームワークを使用して構築できる。別の例として、ビジネスピアツーピア環境におけるNEMOのアプリケーションが考えられる。ビジネスアプリケーション開発と統合化の手法は、多くのIT部門で行われている従来のツール及びソフトウェア開発ライフサイクルの限界を超えて速やかに進化している。これには、ワープロ文書、グラフィックプレゼンテーション、表計算などの開発が含まれる。その最も単純な形体ではこれらの文書が真のアプリケーションであるかどうかは議論の余地があるが、これらの文書の幾つもの形体は正式に記述された、明確に定義された複雑なオブジェクトモデルを有するという点を考慮に入れる必要がある。そのような文書や他のオブジェクトには、例えばオブジェクトのライフサイクル中、検査更新できる状態情報、複数のユーザがそれらのオブジェクトを同時に操作できる能力、及び又は他の機能などが含まれるかもしれない。より複雑なシナリオでは、文書ベースの情報をプログラム的に組み立てて本格的なアプリケーションとして挙動せしめることも可能である。従来のソフトウェア開発と全く同様に、これらの種類のオブジェクトのためにソース制御と責任の利用が有用である。現在において、文書管理を支援する多数のシステムが存在しており、多くのアプリケーションはある形態の文書管理を直接支援している。しかし、分散処理環境のコンテキストでは、これらのシステムのうちその大部分は限界がある。すなわち、明示的なチェックイン、チェックアウトモデルを使用するバージョン管理の中央集中的アプローチ、及びクライアントレンダリングアプリケーションや特に特定のアプリケーション例えば1つの文書のコンテキスト内の形式に連結した柔軟性を欠く非常に弱いか非常に剛直なコヒーレンスポリシーなどの限界である。これらの限界は、能力発見及び形式交渉を強調するP2PポリシーアーキテクチャでもってNEMOの好適な各実施例を使用して対処できる。あるアプリケーション例えば1つの文書の作成をより豊かな方法で構造化することが可能であり、それにより複数の利点が生じる。各オブジェクト及びアプリケーションの構造に豊かなポリシーを適用できる。例えば、1つのポリシーで下記の項目の内いくつか、あるいは全てを指定できる。ある種のモジュールだけが変更可能。オブジェクトインタフェースだけが拡張可能、又は各インプリメンテーションが変更可能。削除のみが許されるが、拡張は許されない。非矛盾性の更新の自動的合併などの機能性を含めて、更新が如何にして適用されるか、そして特定のピアの前の更新の適用はその更新を他のピアに送信できる。最適の機構を介して直接同期化に参加できるように、全てのピアが望むなら、全てのピアに通知されるようなポリシーベースのアプリケーション。それらの能力に基づき、異なった種類のクライアントからの更新をサポートする。この機能性を達成するために、各参加者が使用するオーサリングアプリケーションはNEMO対応のピアであってもよい。作成された文書に関しては、誰が認可されているか、そして文書の各部分に対してその文書の通常の書式化規則の他に何が行えるかを含めて、ポリシーを記述する雛形を使用できる。NEMOピアにより使用されるポリシーエンジンがそれらのセマンティックスと一貫性のあるポリシー規則を解釈して施行できる限り、そしてその文書の作成で許容されたピアインタフェースによりサポートされているオペレーションをServiceAdaptationLayerを介して特定のピアの環境に写像できる限り、任意のピアが参加できるが、それらのピアはその文書を内部的には異なった方法で表現できる。プレゼンテーション文書に関する協調のためのNEMOフレームワーク上に構築されたサービスを利用する異なったNEMOピアで構成されている1つのシステムの場合を考える。この例では、Java登録商標で記述されたアプリケーションをワイヤーレスPDAアプリケーションが実行しているとする。PDAアプリケーションはJava登録商標アプリケーションを使用してその文書を処理してそれをテキストに変換している。デスクトップワークステーション上のMicrosoftWindows登録商標の元で実行されている別のインプリメンテーションが、MicrosoftWord形式を使用して同一の文書を処理する。PDAとワークステーションは両方とも例えばローカルエリアネットワーク上の接続を介してお互いに通信でき、したがってPDAのユーザとワークステーションのユーザは同一の文書アプリケーションに関して協調できる。この例では、この協調に関与する各NEMOピアは相互に発見でき、彼らの状態、及び性能を発見できる。各NEMOピアは各コミット可能な変更、その自己識別、変更、及びオペレーション例えば削除、拡張などを提出する。全ての変更は各NEMOピアに伝播される。これは、各NEMOピアは、別のピアのプロファイル及び性能を、それらが公示された場合、発見できるからである。この時点で、通知するピアは、通知対象のピアがそれをできない場合、通知対象のピアが受け入れることのできる形でコンテンツ変更符号化を持てる。別の方法では、受け入れるピアはそのインタフェースを受け取るとそれが適切であると考える任意の形式でそれらの変更を表現できる。ある変更を受け入れる前に、ピアはそれが認可されているNEMO参加者からのものであることを確認する。変更は文書ポリシーに基づいて適用される。もう1つの例として、NEMO対応ノードであり、DRM形式Aをサポートするが、コンテンツをDRM形式Bで再生したい携帯ワイヤーレスコンシューマ電子デバイスを考える。Xはコンテンツをレンダーする意図及びその特性その自己識別が何であるか、どのOSをそれがサポートするか、その更新性プロファイル、それがサポートする支払方法、及び又はその他の内容を公表して、潜在的ソリューションを提供する他のNEMOピアからの応答を待つ。その照会に対して、Xは次の3件の応答を受け取る。1ピア1はクリアMP3形式で、200の料金でコンテンツの低品質のダウンロード可能バーションを提供できる。2ピア2は再生1回あたり050の料金で、セキュアなチャネルを介して高品質payperplayストリームを提供できる。3ピア3は1000の料金で、DRM形式Bのコンテンツのレンダリングを可能とするソフトウェア更新をXに提供できる。提示されたものをレビューした後、Xは第1オプションが最適の選択であると判断し、第1提示を介して要求を提出する。その要求には、別のNEMOサービスを介してXの支払い口座から200をPeer1が差し引いてもよいという委譲の断定を含む。Xに対して課金されると、Peer1からの応答でXは1つのトークンを受け、そのトークンでMP3ファイルをダウンロードできる。そうではなく、オプション3が最適のソリューションであるとXが判断すると、比較的より複雑なビジネス取引が発生するかもしれない。例えば、オプション3は、NEMO対応の参加している各ピアに含まれるNEMOWorkflowCollator要素で実現されているNEMOOrchestrationDescriptorを使用して記述されるトランスアクションビジネスプロセスで表現する必要があるかもしれない。必要なソフトウェア更新をXに対して遂行するために、NEMOフレームワークを使用して次のアクションが実行される。Xは、それが更新を受け取ることが許されているという認可をそのワイヤーレスサービスプロバイダから取得する。ワイヤーレスサービスプロバイダは、その自己識別を確立するためにピア3の信用証明を直接検証する。Xは、それが第三者更新をインストールすることを許容する必須の更新をBからダウンロードする。これに対してポリシー制約は無いが、このシナリオはこのアクションを発生させる最初の惹起イベントである。Xはピア3が提供する更新に関して課金される。Xはピア3から更新をダウンロードする。このビジネスプロセスでは、ある種のアクションはWFC要素により同時に実行可能であるが、他のアクティビティは特定の順序で認可され、実行されなければならない。0508NEMOフレームワークのもう1つの潜在的アプリケーションは、オンラインゲームのコンテキストで発生する。多くの人気のある複数プレイヤーゲーム環境ネットワークは、オンラインゲーム者がゲームセッションを作成し、それに参加ですることを許容する中央集中的、閉鎖的ポータルとして構造化されている。そのような環境の限界の1つは、一般的にユーザはゲームネットワークと緊密な関係を持つ必要があり、そのサービスを利用するために1つのアカウント通常は特定のゲームタイトルに付随するアカウントを持つ必要があるということである。典型的なゲーム者は、通常複数のタイトルを対象として、そして複数のゲームネットワークに関して幾つかのゲームアカウントを管理する必要があり、複数プレイヤーゲームを立ち上げてそのネットワーク内で参加するためにゲームプロバイダー特定のクライアントアプリケーションとのインタラクションを行う必要がある。これはしばしば不便であり、その結果オンライン利用に対して消極的になる。NEMOフレームワークの各実施例を使用してより連邦的な、分散処理的なゲーム経験を作りだすことによりオンラインゲームをさらに楽しむことができる。それにより、特定のオンラインゲームネットワークの詳細がユーザとサービスプロバイダにとって透明になる。これはより良いユーザ経験を提供してこれらのサービスの採用と利用を促進させるだけでなく、ゲームネットワークプロバイダーの管理負担が軽減できるのである。これらの利点を達成するために、ゲームクライアントをNEMOモジュールで個人化して、それらのクライアントがNEMOピアとして参加できるようにする。更に、ゲームネットワークをNEMOモジュールで個人化して、それらのネットワークがそれらの管理インタフェースを標準的な方法で公開できるようにする。最後に、NEMO信用管理を使用して、認可されたピアだけが意図された方法でインタラクションすることを確実にする。例えば、A、B、Cという3つのゲームネットワークプロバイダー及び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システムは任意の適切なコンテキストで使用できるものであり、これらの具体的な例に限定されないものであることを理解されたい。明確性のために上記はいくらか詳細にわたって説明されたが、添付の特許請求の範囲内におけるある種の変更と修正を行えることは明らかである。本発明のプロセス及び装置の両方を実現するための多くの代替方法が存在することに注意されたい。従って、これらの実施例は例示的なもので、限定的なものではないと考えられるべきであり、この発明的作品は本書記載の詳細に限定されるものではなく、添付の特許請求範囲及び等価の範囲内で変更可能である。以下に示す付記A内の図1~15は、それぞれ、表3~17として示す。<付記A>ピアツーピアサービス編成のシステムおよび方法<0001>本付記は、2003年6月5日付で出願されたWilliamBradleyおよびDavidMaherによる標題ピアツーピアサービス編成のシステムおよび方法の米国仮特許出願番号60/476,357に対応する。本明細書と共に提出されるPCT出願全体におけるBradley他の出願に対する参照は、この付記Aにおける情報に関する。<0002>著作権許可本特許文書の開示内容の一部が、著作権保護の対象となる資料を含む。著作権所有者は、WIPOまたは米国特許商標庁の特許ファイルまたは記録に示されているように、いかなる者にもよる特許文書の複写複製または特許公開も認めるが、それ以外は、どのようなものであれ、すべての著作権の権利を留保する。<0003>発明の分野本発明は、一般的に、ディジタル情報およびディジタルサービスの配布および使用に関する。さらに明確に述べると、ピアツーピアサービス編成を提供および/またはサポートするシステムおよび方法が開示される。<0004>発明の背景と要約今日では、メディア関連サービスの相互運用可能で安全な世界という目標に対して、大きな障害が存在する。例えば、複数の重複し合う事実上の標準と正規の標準とが直接的な相互運用性を阻害する。必要とされるサービスを発見して、それに接続することが困難である場合が多く、インプリメンテーション技術が相互運用不可能であることが多く、および、互いに異なる信用および保護モデルtrustandprotectionmodelの間にインピーダンスの不一致が存在することが多い。<0005>新興のウェブサービス規格がウェブ上でのこれらの問題の幾つかに対処し始めてはいるが、こうしたアプローチは不完全である。これに加えて、こうしたアプローチは、パーソナルエリアネットワーク、ローカルエリアネットワーク、家庭ゲートウェイ、企業ゲートウェイ、部門ゲートウェイ、および、ワイドエリアネットワークに及ぶ複数のネットワークノード階層全体にわたってこれらの問題に対処することはできない。さらに、こうしたアプローチは、多くのレガシーアプリケーションの統合を可能にするローカルとリモートとをバインドする様々なサービスインタフェース例えば、WS-I、Java登録商標RMI、DCOM、C関数呼出し、.Net等を使用して、単純なサービスと複雑なサービスの両方の動的な編成を可能にしない。<0006>本発明の実施態様は、これらの問題の一部分または全部を解決するために、すなわち、これらの問題の一部分または全部に対処するために、使用されることが可能である。例えば、特定の実施態様では、サービスプロバイダが、特定の雑多なサービスネットワークに関与するデバイス、サービス、または、アプリケーションに関して最も適切であるサービス発見プロトコルを使用することが可能である。例えば、BlueTooth登録商標、UpNp、rendezvous、JINI、UDDI等が同一のサービスに中に統合され、および、各ノードが、そのノードをホストするデバイスに関して最も適切な1つまたは複数の発見サービスを使用することが可能である。<0007>メディアの世界において、利害関係者例えば、コンテント発行者、ディストリビュータ、リテールサービス、コンシューマデバイスプロバイダ、および、コンシューマの主要なグループによって必要とされ好まれているシステムとインタフェースとが、多くの場には様々に異なる。したがって、これらのエンティティにより提供される機能を、関与するエンティティすべての要求を満たす最適な構造へと即時に進化できる統合サービスの形に一体化することが望ましいだろう。本発明の実施態様は、ピアツーピアP2Pサービス編成を使用することによって、この目標を達成するために使用されることが可能である。<0008>P2Pフレームワークの有利性が、音楽配信と現在ではビデオ配信とのような事柄に関してすでに見受けられるが、P2P技術はさらに広範囲に使用できる。例えば、様々な企業サービスにおいて、特に2つ以上の企業間でのインタラクションにおいて、利用可能性が存在している。企業はほとんどの場合に階層的に組織され、および、その情報システムがその組織を反映しているが、2つの企業内の人々がインタラクトする時に、これらの人々はピア型のインタフェースを介してより効果的にインタラクトするだろう。A社の受注担当者/サービスは、B社の出荷担当者と対話することによってより直接的に問題を解決したり有益な情報を得ることが可能である。横断階層や不要なインタフェースが実用的でないことが多い。FedExやUPSのような輸送会社はこれに気付き、そのプロセスにおいて直接的な可視性を可能にし、および、イベントがカスタマによって直接監視されることを可能にする。企業と地方自治体はそのサービスを企業ポータルを通して編成しており、それによってセルフサービスの原型を可能とする。しかし、現在までのところ、ピアツーピアフレームワークは、1つの企業が、その企業のカスタマとサプライヤというエンティティが自然なピアリングレベルpeeringlevelでインタラクトすることを可能にして、これらのエンティティがこれらのエンティティに最適な形で企業のサービスをオーケストレートすることを可能にするように、そのカスタマとサプライヤに対して様々なサービスインタフェースを露出させることは可能にはしない。<0009>ネットワークされた計算環境内でサービス編成を提供するためのシステムおよび方法が開示される。この開示された実施態様が、プロセス、機器、システム、デバイス、方法、または、コンピュータ可読媒体を含む、様々な形で実現されることが可能であるということが理解されるべきである。次では幾つかの本発明の実施態様を説明する。<0010>1組の実施態様では、カスタマまたは企業のメディアスペース例えば、コンシューマ、コンテントプロバイダ、デバイス製造業者、サービスプロバイダ、企業部門内の様々な利害関係者が互いを発見し、信用できる関係を確立し、および、信用できるサービスインタフェースによってリッチかつ動的な形で価値交換することを可能にする、サービスフレームワークが提供される。このサービスフレームワークは、雑多なカスタマデバイス、メディアフォーマット、通信プロトコル、および、機密保護メカニズムの世界において、相互運用可能でかつセキュリティ保護されたメディア関連ecommerceを可能にするためのプラットフォームと言い表されることが可能である。<0011>本発明のこれらの特徴と利点と実施態様とその他の特徴と利点と実施態様とが、以下の詳細な説明と添付図面とによってさらに詳細に示されるだろう。<0012>図面の簡単な説明<0013>本発明の実施形態が、同じ照合数字が同じ構造要素を示す次の添付図面と組み合わせて、以下の詳細な説明を参照することによって、容易に理解されるだろう。<0014>図1は、MediaDriveフレームワークの実施形態を示す。<0015>図2は、MediaDriveノードの概念図である。<0016>図3は、MediaDriveノード相互間の一般的なインタラクションパターンを示す。<0017>図4は、サービス適合層ServiceAdaptationLayerの実施形態を示す。<0018>図5aは、クライアント側のMSDLインタラクションに関与しているサービスプロキシを示す。<0019>図5bは、クライアント側のネイティブなインタラクションに関与しているサービスプロキシを示す。<0020>図6は、サービス側のポイントツーインターメディアリインタラクションパターンpoint-to-intermediaryinteractionpatternに関与しているサービスプロキシを示す。<0021>図7は、MediaDriveワークフローコレータのインタラクションパターンを示す。<0022>図8は、通知ハンドラサービスをサポートするノードを発見する1組の通知処理ノードを示す。<0023>図9は、好ましい実施形態による通知の配信を示す。<0024>図10は、ターゲットであるサービス提供ノードに対して要求ノードがサービスクエリー要求を行うクライアント駆動のシナリオを示す。<0025>図11は、要求ノードが別のノードと共にその記述を登録することを望むノード登録シナリオを示す。<0026>図12は、サービスの存在を通知されているMediaDrive対応ノードを示す。<0027>図13は、明示的な交換に基づいて信用を確立するプロセスを示す。<0028>図14は、サービスに対するポリシー管理されたアクセスを示す。<0029>図15は、異なった利害関係者に対するCRM関連サービスの配信に関連してMediaDriveがどのように使用されることが可能であるかを示す。<0030>詳細な説明本発明主体の詳細な説明が以下に示されている。この説明は幾つかの実施形態に関連した形で示されているが、本発明がどの1つの実施形態にも限定されず、その代わりに、多くの代替案と変型と等価物とを含むということを理解されたい。例えば、幾つかの実施形態がコンシューマ志向のコンテントおよびアプリケーションに関連付けて説明されているが、当業者は、開示されているシステムおよび方法がより広範囲のアプリケーションに容易に適合可能であるということを理解するだろう。例えば、非限定的に、本発明の実施形態は、企業のコンテントおよびアプリケーションに関連付けて容易に適用されることが可能である。さらには、本発明の完全な理解を実現するために以下の説明において数多くの具体的な詳細事項が記述されているが、本発明はこれらの詳細事項の一部または全部なしに実施されてよい。さらに、理解しやすいように、本発明に関連した技術において既知である特定の技術的題材は、本発明を不必要に不明瞭にすることを避けるために、詳細には説明していない。<0031>新規性のある、ポリシー管理されたピアツーピア型のサービス編成フレームワークMediaDriveフレームワークの実施形態を、本明細書で説明する。このフレームワークは、当初においては、リッチなメディア体験を実現可能にするグラスルーツ型grass-rootの自己組織型サービスネットワークの形成をサポートするために設計された。当業者は、このフレームワーク自体と、その特徴と側面と用途の多くとに新規性があるということを理解するだろう。<0032>好ましい実施形態では、このフレームワークは、サービス記述言語theMediaDriveServicesDescriptionLanguageMSDLを使用して多数の異なったタイプのサービスの動的な構成と進化とを可能にするように設計されている。サービスは、このフレームワークのために特に設計されているメッセージポンプおよびワークフローコレータを使用して各々がメッセージルーティングおよび編成を実現する、ピアツーピア型通信ノードの全体にわたって分散させられることが可能である。MediaDriveサービスインタフェースの分散ポリシー管理は、信用と機密保護を実現して商業的な価値交換を容易にすることを促進するために、使用されることが可能である。<0033>ピアツーピア型計算が、コンピュータおよび他のインテリジェントデバイスの中でハードドライブおよび処理サイクルのようなリソースの共用として定義されることが多い。http://www.intel.com/cure/peer.htmを参照されたい。本明細書では、P2Pは、ネットワークノードがあらゆる種類のサービスを対称的に消費および提供することを可能にする通信モデルと見なされるだろう。P2Pメッセージングおよびワークフローコレーションは、リッチなサービスが、より原始的なサービスの雑多なセットから動的に生成されることを可能にする。このことが、共有リソースが様々な異なったタイプのサービスである時に、異なったサービスバインディングを使用してさえ、P2Pコンピューティングの可能性の検査を可能にする。MediaDriveの実施形態が、リッチで動的な形でインタラクションし価値交換し協働するために、利害関係者コンシューマ、コンテントプロバイダ、デバイス製造業者、および、サービスプロバイダが互いを発見することを可能にするメディアサービスフレームワークを提供するために使用されることが可能である。MediaDriveの実施形態が、基本サービス発見、通知、探索、および、ファイル共有から、より複雑でより高レベルのサービス例えば、ロッカーlocker、ライセンス供与、マッチング、認可、支払いトランザクション、および、更新とこれらのどれかまたは全部の組合せに及ぶ範囲を協調させるために使用されることが可能である。<0034>MediaDriveの企業アプリケーションが、企業がサービス志向アーキテクチャに移行する時に特に魅力的である。ピアツーピア型サービス編成と分散ポリシー管理との使用によって、企業は、カスタマとサプライヤとによるリッチで個人化されたサービスの形に構成されることが可能なサービスインタフェースをその企業の部門が発表することを可能にすることができ、その結果として、人工的なヒエラル鍵を分解し、および、内部エンティティと外部エンティティの両方がその企業とのインタラクションを最適化することを可能にする。<0035>説明を容易にするために、次の術語が使用されるだろう。<0036>サービス-特定のプロバイダによって提供されるあらゆる明確に定義された機能性。これは、例えば、セル電話のようなデバイス内で提供される低レベルの機能性例えば音声認識サービス、または、ワールドワイドウェブを介して提供される多面的な機能性例えば、商品購入サービスであることが可能である。<0037>サービスインタフェース-1つまたは複数のサービスとインタラクトするあらゆる明確に定義された方法。<0038>サービスバインディング-サービスインタフェースを呼び出すために使用される取り決めconventionおよびプロトコル。これらは、WS-I規格XMLプロトコル、WSDL定義に基づいたRPC、または、DLLからの機能呼出しのような様々な明確に定義された形で表現されてよい。<0039>サービス編成-サービスプロバイダによって指定されたルールに準拠する、管理可能でありかつ粗粒度が高いサービス、再使用可能なコンポーネント、または、完全アプリケーションfullapplicationへの、サービスのアセンブリおよび協調。この例は、プロバイダの自己識別、サービスのタイプ、サービスがアクセスされる方法、サービスが構成される順序等に基づいたルールを含む。<0040>統治-音楽ファイル、文書、または、ソフトウェアアップグレードをダウンロードおよびインストールする機能のようなサービスオペレーションといった特定のアイテムに対して、命令的または支配的な影響を与えるプロセス。統治は、典型的には、信用管理とポリシー管理とコンテント保護とインタラクトする。<0041>ピアツーピア型P2Pフィロソフィ-パティシパントparticipantのためのサービスに対する対称アクセスをサポートする通信モデル。<0042>MediaDriveノード-MediaDriveフレームワーク内のパティシパント。好ましい実施形態では、ノードが、サービスコンシューマおよび/またはサービスプロバイダの役割を含む複数の役割を果たすだろう。ノードは、コンシューマ電子デバイス、メディアプレイヤのようなソフトウェアエージェント、または、コンテント検索エンジンやDRMライセンスプロバイダやコンテントロッカcontentlockerのような仮想サービスプロバイダを含む、様々な形態でインプリメントされてよい。MediaDriveサービスは、より堅固な複合サービスを提供するためにオーケストレートされてもよい。<0043>MediaDriveサービス記述言語MSDL-一実施形態では、MediaDriveフレームワークの実施形態におけるノードの相互間の通信のために使用されるデータタイプとメッセージとの拡張可能セットを定義および記述する、XMLスキーマに基づいた言語。<0044>7.論理モデル図1が、MediaDriveフレームワークの比較的単純な事例を示す。好ましい実施形態では、MediaDriveフレームワークは、PSP型にインタラクトする論理的に接続されたノードのセットから成る。<0045>好ましい実施形態では、このインタラクションの幾つかの特徴は次の通りである。MediaDriveノードが、サービス呼出し要求を行うことと応答を受け取ることとによってインタラクトする。この要求および応答メッセージのフォーマットとペイロードpayloadはMSDLに定義されている。このMediaDriveフレームワークは、単一のサービスプロバイダとの直接的なインタラクションから、複数のサービスプロバイダからの振り付けられたchoreographedサービスのセットの複雑な集約までを範囲とする、様々な通信パターンの構築をサポートする。好ましい実施形態では、このフレームワークは、既存のサービスコレオグラフィservicechoreography規格を使用するための基本メカニズムをサポートし、および、サービスプロバイダがそれ自体の取り決めを使用することを可能にする。サービスインタフェースは1つまたは複数のサービスバインディングを有してよい。好ましい実施形態では、サービスバインディングの記述がMSDLで表現される。この実施形態では、MediaDriveノードは、そのノードのインタフェースバインディングがMSDLで表現されることが可能である限り、かつ、要求ノードがそのバインディングに関連付けられている取り決めとプロトコルとをサポートすることが可能である限り、別のノードのインタフェースを呼び出してよい。例えば、ノードがウェブサービスインタフェースをサポートする場合には、要求ノードが、SOAP、HTTP、WS-Security等をサポートするように要求されてよい。任意のサービスインタフェースが、権利管理の側面を直接的に提供する標準化された仕方で制御例えば、権利管理されてよい。MediaDriveノードの相互間のインタラクションは、統治された動作と見なされることが可能である。<0046>実質的にあらゆるタイプのデバイス物理的デバイスまたは仮想デバイスが、潜在的にMediaDrive対応化されていると見なされることが可能であり、かつ、MediaDriveフレームワークの主要側面をインプリメントすることが可能である。デバイスのタイプは、例えば、コンシューマ電子装置、ネットワーク化サービス、または、ソフトウェアクライアントを含む。好ましい実施形態では、MediaDrive対応デバイスノードは、典型的には、次の論理モジュールの一部または全部を含む。ネイティブサービスAPI-デバイスがインプリメントする1つまたは複数のサービスのセット。MediaDriveノードがあらゆるサービスをMediaDriveフレームワーク内で直接的または間接的に露出させるという要件は存在しない。ネイティブサービスインプリメンテーション-ネイティブサービスAPIのためのインプリメンテーションの対応するセット。MediaDriveサービス適合層MediaDriveServiceAdaptationLayer-MSDLで記述された1つまたは複数の発見可能なバインディングを使用することによってエンティティのネイティブなサービスの露出させられたサブセットがその層を通してアクセスされる論理層。MediaDriveフレームワークサポートライブラリMediaDriveFrameworkSupportLibrary-サービスインタフェース、メッセージ処理、サービス編成等を呼び出すためのサポートを含む、MediaDriveフレームワークと共に機能するためのサポート機能性を提供するコンポーネント。<0047>図2は、MediaDriveノードの例示的な実施形態の概念図を示す。上述のモジュールの各々に対応するこの実際の設計とインプリメンテーションは、典型的には、デバイス毎に異なるだろう。<0048>8.基本的なインタラクションパターン図3は、2つのMediaDriveノード、すなわち、サービスリクエスタとサービスプロバイダとの間の典型的な論理インタラクションパターンを示す。<0049>要求ノードの観点から見ると、イベントフローが、典型的には、指定されたサービスバインディングを使用して必要なサービスを提供することが可能なあらゆるMediaDrive対応ノードを発見するために、サービス発見要求を行う。ノードは、発見されたサービスに関する情報をキャッシュすることを選択してもよい。MediaDriveノード間におけるサービス発見のためのインタフェース/メカニズムは、MediaDriveノードがインプリメントすることを選択する単なる別のサービスであることが可能である。候補となるサービス提供ノードが発見されると、その要求ノードは、特定のサービスバインディングに基づいてそのサービス提供ノードの1つまたは複数に要求を送り出すことを選択してよい。好ましい実施形態では、互いにセキュアに通信することを望む2つのノードが、MSDLメッセージを交換するために信用関係を確立するだろう。例えば、これらのノードは、自己識別の判定、認可、セキュアなチャンネルの確立等において使用されてよい互換性のある信用証明書例えば、X.500信用証明書、デバイス鍵等のセットをネゴシエートしてもよい。特定の場合には、これらの信用証明書のネゴシエーションは、サービスインタフェースバインディングの暗黙の属性であってよい例えば、WS-IXMLプロトコルが使用される場合にはWS-Security、または、2つの既知のノードの間のSSL要求。特定の場合には、信用証明書のネゴシエーションは、明示的に別々の段階であってよい。好ましい実施形態では、どの信用証明書が別のMediaDriveノードとインタラクトするのに十分であるかを判定することと、それが特定のノードを信用することが可能であるという判断を行うことは、特定のノード次第である。要求ノードは、要求されたサービスに対応する1つまたは複数の適切なMSDL要求メッセージを生成する。このメッセージが生成されると、このメッセージは、ターゲットである1つまたは複数のサービス提供ノードに送られる。この要求の通信スタイルは、サービスバインディングに基づいて、例えば、同期的または非同期的なRPC型であるか、または、メッセージ志向であってよい。サービス要求の送信と応答の受信は、直接的にデバイスによって、または、MediaDriveサービスプロキシを通して行われてよい。後述するこのサービスプロキシは、MediaDriveフレームワーク内の他のパティシパントにメッセージを送るためのアブストラクションとインタフェースとを提供し、および、互換メッセージフォーマット、トランスポートメカニズム、メッセージルーティング問題等のような特定のサービスバインディング問題を隠蔽してよい。要求を送り出した後に、要求ノードは、典型的には、1つまたは複数の応答を受け取るだろう。サービスインタフェースバインディングと要求ノードの選好との詳細に基づいて、1つまたは複数の要求が、例えばRPC型の応答または通知メッセージを含む様々な仕方で戻されてよい。これらの応答は、1つまた複数のターゲットノードへの途上で、例えば、ルーティング、信用翻訳trusttranslation、照合collation、および、相関関数等を含む、幾つかのMediaDriveサービスを提供してよい他の中間ノードを通過してもよい。要求ノードは、応答がその要求ノードとサービス提供ノードとの間のネゴシエートされた信用セマンティクスに準拠することを確実なものにするために、1つまたは複数の応答を検証する。その次に、適切な処理が、メッセージペイロードのタイプとコンテントとに基づいて適用される。<0050>サービス提供ノードの観点から再び図3を参照すると、イベントフローが次の通りである。要求されたサービスがサポートされかるどうかを判定する。好ましい実施形態では、MediaDriveフレームワークは、サービスに対するエントリポイントとしてサービスインタフェースがどのようにマップするかに関するスタイルまたは粒度granularityを規定しない。最も単純な場合では、サービスインタフェースは、特定のサービスに対して明確にマップしてよく、および、そのサービスに対するバインディングと呼出しの行為が、そのサービスのためのサポートを構成してよい。しかし、特定の実施形態では、単一のサービスインタフェースが複数のタイプの要求を取り扱ってよく、および、特定のサービスタイプが、具体的に必要とされる機能性をノードがサポートするという判定が行われることが可能である前に調査される必要がある追加の属性を含んでもよい。特定の場合には、サービスプロバイダが、そのサービスプロバイダが要求ノードを信用するかどうかを判断することと、互換性のある信用証明書のセットをネゴシエートすることとが必要だろう。好ましい実施形態では、サービスプロバイダが信用を判定するかどうかに係わらず、サービスインタフェースに関連したあらゆるポリシーが該当するだろう。サービスプロバイダは、要求ノードがアクセス権を有するかどうかを判定するために、サービスインタフェースに対するアクセスを認可する役割を有する1つまたは複数のMediaDriveノードに対して1つまたは複数の認可要求を判定して送出する。多くの状況においては、認可するノードとサービス提供ノードとが同一のエンティティだろうし、認可要求の送出と処理は、C機能エントリポイントのような軽量MediaDriveサービスインタフェースバインディングを経由して呼び出されるローカルなオペレーションだろう。認可応答を受け取ると、要求ノードが認可される場合には、サービスプロバイダが要求を満たすだろう。そうでない場合には、適切な応答メッセージが生成されることが可能である。応答メッセージが、サービスインタフェースバインディングと要求ノードの選好とに基づいて戻される。要求ノードへの途上で、このメッセージは、必要なサービスすなわち付加価値サービスを提供してよい他の中間ノードを通過してもよい。例えば、中間ノードが、ルーティング、信用翻訳、または、その要求ノードにとって許容可能な仕方でメッセージを配信することが可能な通知処理ノードへの配送を可能にしてもよい。付加価値サービスの一例が、そのサービスが要求ノードの関心interestに関して知っている場合に、そのメッセージにクーポンを添付するクーポンサービスである。<0051>9.MSDLサービス呼出しに関連したメッセージの構文が、MediaDriveフレームワーク内で使用されるコアデータタイプのような比較的フレキシブルでポータブルな形で記述されることが好ましい。好ましい実施形態では、これは、本明細書ではMediaDriveサービス記述言語すなわちMSDLと呼ばれることになるサービス記述言語を使用して実現される。さらに、MSDLは、記述されたサービスに関連している意味記述を参照するための単純な方法を提供する。<0052>好ましい実施形態では、MSDLは、サービスとこれに関連したインタフェースバインディングとの記述と複合とを可能にする拡張可能なデータタイプセットを具体化するXMLスキーマに基づいた記述言語である。MSDLにおけるオブジェクトタイプの多くがポリモルフィックであり、および、新たな機能性をサポートするために拡張されることが可能である。好ましい実施形態では、基本MSDLプロファイルが、MediaDriveインタラクションパターンとインフラストラクチャ上の機能性とをサポートするためのデータタイプとメッセージとの最小セットを定義する。この基本プロファイルはMSDLCoreと呼ばれるだろう。MSDLユーザは、アドホックに直接的に、または、何らかの形態の標準化プロセスによって、新たなデータタイプおよびサービスタイプを追加すると共に既存のデータタイプおよびサービスタイプを拡張する、MSDLCore上に構築された他のMSDLプロファイルを定義する。一実施形態では、MSDLCoreは、次の主要な基本データタイプの一部または全部に関する定義を含む。ノード-MediaDriveフレームワークのパティシパントの表現。デバイス-仮想デバイスまたは物理デバイスの表現をカプセル化する。ユーザ-クライアントユーザの表現をカプセル化する。コンテント参照contentreference-コンテントアイテムに対する参照すなわちポインタの表現をカプセル化する。この参照は、典型的には、コンテントフォーマット、ロケーション等を記述する他の標準化された方法をレバレッジleverageするだろう。DRM参照-ディジタル権利管理フォーマットの記述に対する参照すなわちポインタの表現をカプセル化する。サービス-ノードからエクスポートされた明確に定義された機能性のセットの表現をカプセル化する。サービスバインディング-サービスと通信する特定の方法をカプセル化する。要求-ターゲットであるノードのセットに対するサービスの要求をカプセル化する。要求入力-要求のための入力をカプセル化する。応答-要求に関連している応答をカプセル化する。要求結果-特定の要求に関連している応答の中の結果をカプセル化する。<0053>一実施形態では、MSDLCoreは、次の基本サービスの一部または全部に関する定義を含む。認可-特定のパティシパントがサービスにアクセスすることを認可するための要求または応答。メッセージルーティング-サービス提供ノードにメッセージを転送させるか、または、メッセージを収集およびコレートさせる機能を含む、メッセージルーティング機能性を提供するための要求または応答。ノード登録-ノードのための登録オペレーションを行い、これによって中間ノードを経由してそのノードが発見されることを可能にする要求または応答。ノード発見クエリー-MediaDriveノードの発見に関係している要求または応答。通知-ターゲットである通知メッセージを特定のノードセットに送信または配信するための要求または応答。サービス発見クエリー-1つまたは複数のノードの特定のセットによって提供されるサービスの発見に関係している要求または応答。セキュリティ証明書交換-鍵対や信用証明書等のようなセキュリティ関連情報をノードが交換することを可能にすることに関係している要求または応答。アップグレード-機能性のアップグレードを受け取ることに関係している要求または応答を表現する。一実施形態では、このサービスは純粋に抽象的であり、他のプロファイルが具体的な表現を提供する。<0054>10.アーキテクチャの概観10.1.サービス適合層再び図2を参照すると、サービス適合層が、MediaDriveフレームワーク内のパティシパントの1つまたは複数のネイティブなサービスを露出させるために使用されることが可能である。好ましい実施形態では、MSDLは、1つまたは複数のインタフェース上でのサービスに明確にバインドする仕方を記述するために使用される。サービス記述が、さらに、次のものの一部または全部を含む他の情報を含んでもよい。サービスに対するアクセスを認可する役割を果たす1つまたは複数のサービスプロバイダのリスト。サービスの目的と使用の意味記述に対するポインタ。サービスが、他のサービスのセットの振り付けられた実行の結果として生じた複合サービスである場合には、必要な編成の記述。<0055>サービスがMSDLで公表される論理点logicalpointとしての役割に加えて、好ましい実施形態では、サービス適合層は、さらに、特定のパティシパントによってサポートされるそれらのプラットフォームのための任意のMSDLプロファイル内に含まれているMSDLデータタイプおよびオブジェクトの具体的な表現をカプセル化する。このサービス適合層は、さらに、適切なネイティブサービスインプリメンテーションに対して、サービス要求に対応するMSDLメッセージをマッピングするためのロジックを含む。<0056>典型的には、サービス適合層のインプリメンテーションは、図4に示されている要素を含む。具体的には、典型的なサービス適合層インプリメンテーションは、階層的設計において次の要素を含むだろう。サービスインタフェースのMSDLバインディングにおいて説明したようにサービスインタフェースエントリポイントをカプセル化する層。これらのアクセスポイントを経由して、サービス呼出しが行われ、入力パラメータデータが送り込まれ、および、結果が出て行く。MSDLメッセージ処理のためのロジックに対応する層。これは、典型的に、その処理を駆動する特定の種類のメッセージポンプと、特定のタイプのXMLデータバインディングサポートと、低レベルのXMLパーサとデータ表現サポートとを含む。対応する/MSDLで記述されたサービスがその上にマッピングされる使用可能なネイティブサービスを表す層。<0057>10.2フレームワークサポートライブラリ再び図2を参照すると、フレームワークサポートライブラリが、エンティティがMediaDriveフレームワークに関与するのを可能にすることをより簡単にする採用随意のサポート機能の集まりを提供する。このサポートライブラリがどのようにファクタfactorされるかオブジェクトの集まり、機能の集まり等ということと、それがどのようにインプリメントされるかということは、ターゲットであるプラットフォームに応じて様々だろう。異なった機能性をサポートするこのサポートライブラリの複数のバージョンが存在してよい。一般的な場合には、このサポートライブラリ中の使用可能な機能性が次のものの一部または全部を含む。サービスプロキシ-MediaDriveノードがサービス呼出し要求をターゲットであるサービス提供ノードセットのセットに対して行って応答セットを受け取ることを可能にする機能性をカプセル化する。MSDLメッセージ操作ルーチン-MSDLメッセージ部品を操作するための機能性。サービスキャッシュインタフェース-発見されたノードとこの発見されたノードがサポートするサービスとの間のマッピングをノードが管理することを可能にする一般的なサービスプロバイダインタフェース。ワークフローコレータインタフェース-MSDLメッセージの集まりをノードが管理および処理することを可能にするサービスプロバイダインタフェース。これは、サービスをオーケストレートするための基本的なビルディングブロックを提供する。現時点では、このインタフェースは、メッセージルーティングをサポートしかつメッセージの中間的な待ち行列管理と照合とをサポートするノードによって、インプリメントされることが最も多い。通知プロセッサインタフェース-通知処理をサポートするMediaDriveノードを特定の明確に定義された通知処理エンジンにフックhookするためのサービスプロバイダインタフェース。その他のサポート機能性-メッセージIDとタイムスタンプ等を生成するためのルーチン。<0058>10.3通信スタイルMediaDriveフレームワークの好ましい実施形態でサポートされており、かつ、サービスプロキシのような異なったサポートライブラリコンポーネントで使用される、一般的な通信スタイルの基本的な概観を示すことが有益である。次のような通信パターンの少数の基本タイプがある。<0059>非同期RPC配信スタイル-要求の実現が長時間の時間期間を要しかつクライアントが待機することを望まないという予想がある時に、このモデルが適切である。この場合には、クライアントは、1つまたは複数の特定のサービス提供ノードによって要求が非同期的に処理されるだろうということを予想して要求を送る。サービス提供エンドポイントが、そのサービス提供エンドポイントがこのモデルをサポートしないという表示によって応答することがあり、または、サービス提供ノードがこのモデルをサポートしない場合には、そのサービス提供ノードは、それがクライアントの要求に対する応答を有するかどうかを判定するために後続の要求においてサービス提供ノードに送られることが可能なチケットを搬送する応答を戻すだろう。好ましい実施形態では、このモデルをサポートするサービス提供エンドポイントは、特定の内部ポリシーに基づいた保留中の要求に対する応答をキャッシュするだろう。クライアントがこうした要求に関連しているチケットを回収することを試みており、かつ、応答が利用不可能であるか、または、応答がサービス提供ノードによって破棄されている場合には、適切な誤り応答が戻されることが可能である。<0060>同期RPC配信スタイル-この場合には、クライアントは要求を送り、その次に、戻される1つまたは複数の応答を待機する。サービス提供MediaDrive対応エンドポイントが、それがこのモデルをサポートしないという表示を伴って応答してよい。<0061>メッセージベースの配信スタイル-この場合には、クライアントが、その通知ハンドリングサービスインタフェースの1つまたは複数に関連付けられているメッセージ通知によって、あらゆる応答を受け取ることをそのクライアントが望むということを表示する要求を送る。ノードが応答して、そのノードがこのモデルをサポートしないということを表示する。通知フレームワークの典型的な実施形態を次で説明する。<0062>上述のインタラクションパターンはどれも、応答の阻止と待機、または、明示的なポーリングを必要としない。上述の配信スタイルメカニズムによってブロッキングセマンティクスblockingsemanticsおよび非ブロッキングセマンティクスをモデル化するために、スレッディングthreadingまたは他のプラットフォーム固有のメカニズムを使用することが可能である。<0063>10.4サービスプロキシMediaDrive対応エンドポイントは、様々な発見プロトコルと、名称プロトコルと、分解プロトコルと、搬送プロトコルとを使用してよい。この結果として、典型的には、フレキシブルで拡張可能な通信APIを使用することが望ましいだろう。サービスプロキシAPIは、MediaDriveノードがサービス要求を行い、かつ、ターゲットであるMediaDriveノードのセットのための応答を受け取ることを可能にするための機能性に対する一般的なインタフェースを提供する。サービスプロキシは、共用ライブラリの形でクライアントの境界の内側で、または、異なったプロセスで実行するエージェントの形でクライアントの境界の外側で、様々な形態でインプリメントされてよい。サービスプロキシのインプリメンテーションの正確な形態は、プラットフォームまたはクライアントの必要に適合させられることが好ましい。一般的にサービスプロキシは大きな有用性を提供するが、サービスプロキシの使用は随意である。サービスプロキシの一般的な使用の幾つかが次のものを含む。サービス呼出しのための一般的な再利用可能なAPI。搬送チャンネルのネゴシエーションと使用とを取り巻く問題のカプセル化。幾つかの搬送チャンネルはTCP/IPを経由したSSLセッションのセットアップを要求し、幾つかのチャンネルはUDP/IPを経由した不信頼通信だけをサポートすることがあり、および、他のチャンネルは全くIPベースではないことがある。好ましい実施形態では、クライアントは、一般的に、これらの詳細から遮断される。メッセージルーティングのためのMediaDriveノードの初期セットの発見を取り巻く問題のカプセル化。例えば、ケーブルセットトップボックスが、ネットワークに対する専用の接続を有し、かつ、すべてのメッセージが特定のルートとインターメディアリとを経由して流れることを命令してもよく、一方、ホームネットワーク内のポータブルメディアプレイヤが、直接的にアクセス可能な複数のエンドポイントを発見するためにUPnP発見を使用してもよい。この場合も同様に、クライアントがこれらの詳細から遮断されることが好ましい。レガシークライアントが、MSDLメッセージの生成によって他のMediaDriveノードと直接的に会話することが不可能であるか、または、会話することを選択しないことがある。この場合には、クライアントがサポートするあらゆるネイティブプロトコルを理解するサービスプロキシのバージョンが生成されてよい。<0064>サービスプロキシは、プロトコルバインディングの固定されたセットをサポートするだけの静的コンポーネントとしてインプリメントされてよく、または、新たなバインディングを動的にサポートすることが可能であるようにインプリメントされてもよい。一般的なサービスプロキシモデルの2つの例は次の通りである。1サービスプロキシがMSDLメッセージを直接受け取ってクライアントに戻し、2サービスプロキシが、クライアントによって理解される幾つかのネイティブなプロトコルをサポートする。サービスプロキシは、2つの側面、すなわち、要求パティシパントが使用するクライアント側面と、他のMediaDrive対応エンドポイントとインタラクトするサービス側面とを有するものと見なされることが可能である。<0065>クライアントとサービスプロキシとの間の2つの主要なインタラクションパターンは次の通りである。<0066>パターン1図5a。クライアントがMSDL要求メッセージを直接形成し、および、そのメッセージをサービスプロキシに送る。サービスプロキシは、それが典型的には収集と解析と処理とを行うことを必要とする、MSDLフォーマットの形の1つまたは複数の応答を受け取る。クライアントは、さらに、要求の配信をターゲットにすることに使用するために、サービスバインディングの1つまたは複数の明示的なセットを送ってもよい。これらのサービスバインディングは、サービス発見オペレーションを行うクライアントによって、または、以前の要求応答から得られた情報を使用することによって、すでに得られていてもよい。<0067>パターン2図5b。サービスプロキシは、そのサービスプロキシが受け入れる特定のネイティブな通信プロトコルによってクライアントがインタラクトしてよいクライアント側のモデルに適応し、MediaDriveフレームワーク内にクライアントが関与することを可能にするためにMSDLに/MSDLから翻訳する。この場合には、ネイティブなプロトコル、または、ネイティブなプロトコルと実行環境との組合せが、サービスプロキシが適切なMSDL要求を生成するための、および、サービスプロキシが必要に応じて適切なターゲットのサービスバインディングを決定するための必要な情報を提供する。<0068>サービス側では、サービスプロキシとサービス提供MediaDrive対応エンドポイントとの間の複数のタイプのインタラクションパターンがサポートされ、および、クライアント側と同様に、要求の種類、基礎となる通信ネットワーク、アプリケーションの種類、および/または、ターゲットである任意のサービスバインディングに関連している搬送プロトコルを含む様々な判定基準に基づいて、そのインタラクションパターンが適合させられることが可能であり、および、変化してよい。<0069>1つのパターンでは、サービスプロキシは、複数の潜在的なサービスプロバイダとの通信を直接的に開始し、および、応答を受け取る。このタイプのインタラクションパターンは、サービスプロキシによる使用のためにクライアントから中継されている複数のサービスバインディングに準拠してよく、または、メッセージの中継においてサービスプロキシが使用するブロードキャストネットワークまたはマルチキャストネットワークが存在することを示してもよい。サービスプロキシは、応答を収集および照合することを選択してもよく、または、最初の受け入れ可能な応答を戻すだけでもよい。<0070>図6に示されているモデルでは、サービスプロキシは、ターゲットであるサービス提供エンドポイントと直接的には通信せず、その代わりに、要求を中継する中間ノードを介して要求を送り、あらゆる応答を受け取り、および、サービスプロキシに応答を送り返す。このインタラクションパターンは次の理由によるだろう。サービスプロキシは、サービス提供エンドポイントに関連しているあらゆるサービスバインディングを直接サポートすることが不可能である/そうすることを望まないが、ゲートウェイとして働くことを望む中間ノードとの関係を確立することが可能である。クライアントが、任意の適切なサービス提供ノードに関するサービスバインディングを発見するか他の形で決定することが不可能であることがあり、および、任意の適切なサービスプロバイダを発見することを中間ノードが試みることを可能にすることを望んでいる。サービスプロキシが、より堅固な収集をサポートする中間ノードを利用することを望み、および、サービスプロキシとサービスプロバイダとの間のよりフレキシブルな通信パターンを可能にする機能性を照合する。<0071>あるいは、または、上述の基本的なサービス側インタラクションパターンに加えて、上述のパターンまたは新たなパターンの組合せをインプリメントするサービスプロキシのインプリメンテーションを有することが可能である。<0072>10.5ワークフローコレータ好ましい実施形態では、ほとんどの非自明なMediaDriveサービス要求の履行が、要求のイベントフローを管理することと、過渡的な結果と中間結果とを含むあらゆる関連データを管理することと、履行に関連したルールもしあればが守られることを確実なものにすることとが可能な特定のタイプの協調メカニズムを必要とすることが多い。この機能性は、リレーショナルデータベース内の単純なトランザクションモニタからMicrosoftMTS/COMに見られるようなより一般化されたエージェントに及ぶ範囲内のトランザクションコーディネータの形態で実現されることが可能である。好ましい実施形態では、ワークフローコレータが、MediaDriveノードがサービス呼出しの処理と履行とをオーケストレートするのを可能にするプログラム可能なメカニズムである。<0073>好ましい実施形態では、ワークフローコレータは、特定のMediaDriveエンドポイントの特性と要件とに適合させられることが可能であり、および、従来のメッセージ待ち行列管理からより高度な分散トランザクション協調に及ぶ様々な機能性をサポートするように設計される。単純なワークフローコレータは、任意のMSDLメッセージの格納と探索とのためのインタフェースを提供する。この上に構築することによって、次のものを含む様々な機能性をサポートすることが可能である。より効果的な処理のためのサービス要求の収集。複合応答の形へのサービス応答の単純な集約。複合サービスを生成するための、複数のサービス要求とサービス応答との手動編成。複合サービスを生成するための、複数のサービス要求とサービス応答との自動編成。<0074>図7は別の潜在的なインタラクションパターンを示す。このインタラクションパターンは、MediaDriveノードに到着してそのノードのサービス適合層を経由して受け入れられるサービス要求で開始する。メッセージが、要求を履行しおよび応答を返すためにワークフローコレータを最初に駆動しおよびワークフローコレータによって駆動されるMSDLメッセージポンプに渡される。このパターンは幾つかのサービス処理パターンのための基礎である。一般的な単純な事例では、サービス要求の履行は、処理が等冪であり、かつ、その要求を処理するためのルールがMSDLの形でその要求の一部として完全に表現されている、単純な要求/応答インタラクションパターンの形で表現されることが可能である。しかし、サービス要求の履行は、特定の時間期間全体にわたって非同期的に処理された、到着する複数のMSDLに依存するだろう。この場合には、この処理は、ワークフローコレータによって監視される潜在的に長寿命であるトランザクションの一部分である。<0075>さらに複雑なシナリオでは、特定のサービス要求の履行が、協調した形での複数のノードの関与を必要とする。その要求を処理するためのルールが、BPELのような他のサービス編成記述規格からのメッセージを随意にラップwrapすることが可能なMSDLの形で表現されてよい。要求の履行において、ノードのワークフローコレータがローカルインタフェースの特定のセットを通して機能性に依存してよく、または、他のMediaDriveノードとインタラクトしてよい。<0076>MSDL要求メッセージがワークフローコレータに与えられる時には、この要求メッセージは、何の適正なルールがその要求を処理するためであるかを判定する。ワークフローコレータのインプリメンテーションに応じて、サービス記述ロジックが、ノードが露出させるサービスのセットのための固定状態マシンの形態で表現されてよく、または、BPEL4WSを使用して記述できるサービス処理ロジックのようなサービス処理ロジックのより自由な形態の表現の処理をサポートする形で表現されてよい。ワークフローコレータのアーキテクチャがモジュール型かつ拡張可能であり、プラグインをサポートすることが好ましい。好ましい実施形態では、MSDL自体が、複数のMediaDriveサービスを複合サービスにオーケストレートするためのルールを表現する単純な方法をサポートする。<0077>サービス統合と処理ルールとを翻訳することに加えて、好ましい実施形態では、ワークフローコレータは、サービス履行処理ライフサイクルの開始に関連してMSDLメッセージが使用されるべきかどうか、または、MSDLメッセージが進行中のトランザクションの連鎖の中でさらに別に入力されるかどうかを決定することを必要とするだろう。MSDLメッセージは、これらのタイプの決定を行うために使用されることが可能なIDとメタデータとを含む。さらに、サービストランザクションに固有であってよい追加の情報を含み、および、メッセージの処理を容易化するように、MSDLメッセージを拡張することも可能である。<0078>10.6通知サービス非同期および同期RPC型の通信パターンの両方に加えて、クライアントが特に要求を開始し、その次に応答を待機するか、または、チケットの回収によって応答を周期的に調べる場合には、MediaDriveフレームワークの好ましい実施形態は、さらに、通知の概念に基づいた純粋なメッセージングタイプの通信パターンもサポートする。次の要素が、好ましい実施形態の通知フレームワークで使用されるコアMSDLデータおよびメッセージタイプを構成する。通知-関係のあるMediaDrive対応エンドポイントノードをターゲットにされた、指定されたタイプのペイロードを含むメッセージ。通知インタレストnotificationinterest-特定のノードが特定の通知を受け入れるかどうかを判定するために使用される判定基準。通知インタレストは、特定のタイプの自己識別例えば、ノードID、ユーザID等、イベント例えば、ノード発見、サービス発見等、アフィニティグループaffinitygroup例えば、ニュージャズクラブコンテントnewjazzclubcontent、または、一般的なカテゴリ例えば、広告に基づいたインタレストを含んでもよい。通知ペイロード-分類された通知のコンテント。ペイロードタイプは、単純なテキストメッセージからより複雑なオブジェクトまでを範囲としてよい。通知ハンドラサービスインタフェース-通知がそのインタフェース上で受け取られてよいサービスプロバイダインタフェースのタイプ。サービスプロバイダは、さらに、そのインタフェースに関連した通知インタレストとアクセス可能なペイロードタイプとを記述する。このインタフェースをサポートするノードが通知のための最終宛先または中間処理エンドポイントであってよい。通知プロセッササービス-通知を関係ノードにマッチングさせて、特定のポリシーに基づいて通知を配信することが可能なノード。通知発信元notificationoriginator-関係ノードのセットおよび/または通知処理ノードの中間セットをターゲットした通知を送り出すノード。<0079>すべてのMSDLデータタイプとメッセージと同様に、通知、通知インタレスト、および、通知ペイロードが拡張可能であることが好ましい。さらに、通知ハンドラサービスインタフェースが、他のあらゆるMediaDriveサービスインタフェースが受けるのと同じ認可プロセスを受けることが好ましい。したがって、特定の通知がインタレストと受け入れ可能なペイロードとに関してマッチする可能性があっても、ノードは、その通知の中間送信元または発信ソースに関係した特定の関連インタフェースポリシーに基づいて、通知を受け取ることを拒絶することができる。<0080>図8は、通知ハンドラサービスをサポートするノードを発見する通知処理ノードのセットを示す。通知の受け取りをサポートするノードが、そのサービス記述の一部分として、その通知インタレストが何であるか、および、どの通知ペイロードタイプが受け入れ可能であるかを指定する。<0081>図9は、通知がどのように配信されるかを示す。任意のノードが通知の発信ソースであると同時に通知のプロセッサであることが可能であり、および、通知の配信の役割を果たすことが可能である。外部の通知発生ノードからの通知を取り扱うことを選択する通知プロセッサは、効率を改善するために、MicrosoftNotificationServicesのような市販の通知処理エンジンと一体化してよい。<0082>10.7サービス発見MediaDriveフレームワークの好ましい実施形態が、発見サービスのためのフレキシブルなモデルのセットをサポートする。これらのモデルは既存の発見モデルにマッピングされることが可能である。一実施形態では、このフレームワークは、次の3つのサービス発見の基本モデルをサポートする。クライアント駆動-MediaDriveノードが、ターゲットであるノードが特定のサービスセットをサポートするかどうかを質問するサービスクエリーサービスインタフェースをサポートするターゲットノードの特定のセットに対して明示的に要求を送る。この要求ノードが認可されると、サービス提供ノードは、そのサービス提供ノードが要求されたインタフェースとこれに関連したサービスインタフェースバインディングとをサポートするということを報告するだろう。これは、ノードが任意のサービスを露出させる場合にそのノードがサポートするより一般的なインタフェースの1つである。ノード登録-ノードは、他のノードと共に、そのノードのサポートされたサービスを含むその記述を登録することが可能である。ノードがこのインタフェースをサポートする場合には、他のノードからの要求を受け入れ、および、特定のポリシーに基づいてそれらの記述をキャッシュすることが望ましい。これらのノード記述は、その次に、受け取りノードによる使用のために直接的に利用可能であるか、または、キャッシュされた記述を有するノードをターゲットとしたサービスクエリーを行う他のノードに対して利用可能である。イベントベースevent-based-ノードが、状態の変化例えば、ノードのアクティブ/利用可能を示す通知を送り出すか、または、ノードが、そのノードが特定のサービスをサポートすることを発表する。通知は、そのノードとそのノードのサービスとの完全な記述を含むことが可能であるか、または、イベントに関連したノードのIDだけを含むことが可能である。その次に、関係したノードが、その通知を受け入れて処理することを選択してよい。<0083>図10は、特定の要求ノードが、ターゲットであるサービス提供ノードに対してサービスクエリー要求を行い、および、要求された1つまたは複数のサービスをサービスプロバイダがサポートするかどうかを表示する応答を受け取る、クライアント駆動のシナリオを示す。<0084>図11は、特定の内部ポリシーに基づいて特定の要求ノードの記述を受け取ることと、この記述をキャッシュすることとを望んでいる特定の他のターゲットノードと共に、この記述を登録することをその特定の要求ノードが望む、ノード登録シナリオを示す。要求ノードは、ターゲットであるサービス提供ノードに対して登録要求を行い、および、サービスプロバイダがその記述をキャッシュしたことを表示する応答を受け取る。<0085>図12は、通知によってサービスの存在に対して警告されるMediaDrive対応ノードを示す。こうした通知は、ノードの状態の一般的な状態変化に関係した通知を含む様々な形態で到着してよく、または、ノードがサービスの利用可能性に関係した通知を明示的に送り出す。<0086>10.8サービス認可MediaDriveノードが、指定されたサービスに対するアクセスを許可する前に、MediaDriveノードが、要求ノードがアクセスを許可されているかどうかを最初に判定することが好ましい。好ましい実施形態では、アクセスを許可することが、2つの異なってはいるが互いに関係している判定基準に基づいている。第1の判定基準は、サービス提供ノードがこの通信に関して要求ノードを信用するかどうかであり、第2の判定基準は、要求されたサービスのインタフェースに対して要求ノードがアクセスすることを許可するポリシーが存在するかどうかである。<0087>10.8.1信用の確立好ましい実施形態では、MediaDriveフレームワークは、どのようにノードの任意のセットが互いを信用することになるかに関する、特定の要件、判定基準、または、決定ロジックを命令しない。信用セマンティクスは、ノード毎に大きく異なるだろう。MediaDriveフレームワークは、相互に許容された信用関係をノードがネゴシエートすることを可能にする標準的な機能セットを提供しようと試みる。ノード間の信用の判定と確立においては、MediaDriveフレームワークの好ましい実施形態が、信用関係を確立するために使用されることが可能なノード間の信用証明書の交換をサポートする。MediaDriveフレームワーク内では、信用関連の信用証明書が、様々な異なったモデルを使用して交換されてよい。例えば、サービスバインディング属性-信用証明書がサービスインタフェースバインディングの一部分として明示的に交換されるモデル。例えば、ノードが、そのサービスをSSLによってHTTPPOST上の書式において露出させるか、または、WS-SecurityXMLSignatureを必要とするウェブサービスとして露出させる場合には、このサービスバインディングの実際の属性がすべての必要な信用関連の信用証明書を通信してよい。要求/応答属性-信用証明書がMSDL要求および応答メッセージを通して交換され、メッセージ上の属性として信用証明書を随意に含むモデル。明示的交換-特定のノードが含む信用証明書に関係した情報の照会を可能にするサービスプロバイダインタフェースを通して信用証明書が明示的に交換されるモデル。これは、一般的に、信用証明書を交換するために別個の往復セッションを典型的に必要とする、最も複雑なモデルである。サービスインタフェースバインディング自体が相互に許容可能な信用できるチャンネルを提供する。<0088>信用関連の信用証明書が、要求および応答メッセージ上の属性として直接的に交換されてよい。例えば、ディジタル信用証明書が、要求および応答メッセージに添付されるか、または、要求および応答メッセージと共に流通してもよく、および、信用できる関係を形成するために使用されることが可能である。<0089>図13に示されているシナリオでは、特定のノードがこのインタフェースをサポートする場合に、ノードが直接的にセキュリティ信用証明書サービスを介して信用証明書を交換してよい。<0090>これらの基本モデルに加えて、MediaDriveフレームワークが、これらの異なったアプローチの組合せをサポートすることが好ましい。例えば、セミトラステッドsemi-trustedサービスバインディングに関連した通信チャンネルが、他のセキュリティ関連信用証明書の交換をより直接的にブートストラップするために使用されてよく、または、特定のタイプの固有の完全性を有してもよいセキュリティ関連信用証明書を直接的に交換し、および、特定のサービスインタフェースバインディングに関連したセキュアな通信チャンネルを確立するようにそのセキュリティ関連信用証明書を使用するために、使用されてよい。<0091>要約すると、信用モデルのセマンティクスと、信用を確立するために準拠されなければならないプロセスとが、エンティティ毎に異なるだろう。特定の状況では、ノード間の相互信用が不要であってもよい。このタイプの動的な雑多な環境が、異なったエンティティが文脈依存型の信用セマンティックスをネゴシエートすることを可能にする機能の一般的なセットを提供するフレキシブルなモデルを必要とする。<0092>10.8.2ポリシー管理されたアクセス1組のインタラクトするノードの相互間の信用できる関係を確立することに加えて、サービス提供ノードがサービスに要求ノードがアクセスすることを可能にする前に、さらに、サービス提供ノードが、サービスインタフェースに関連したあらゆるポリシーに基づいてこのアクセスが許可されるかどうかを判定しなければならないことが好ましい。MediaDriveフレームワークは、この判定を行うための首尾一貫したフレキシブルな方法を提供する。好ましい実施形態では、サービス記述の一部分として、1つまたは複数のMediaDriveノードが、認可サービスプロバイダとして指定されるだろう。これらの認可サービス提供ノードの各々は、認可クエリー要求をハンドリングするための、および、この認可クエリー要求に応答するための、標準的なサービスをインプリメントすることが要求されるだろう。例えば、サービスインタフェースに対するアクセスが許可される前に、ターゲットであるサービスプロバイダが、そのサービスに対するアクセスを認可するすべてのMediaDriveノードに対して認可クエリー要求を送ってもよく、および、すべての認可エンティティが応答して、アクセスが許可されるということ表示する場合にだけ、アクセスが許可されてよい。<0093>図14が示すように、サービス提供ノードは、要求されたサービスに対するアクセスを管理するすべてのノードに対して認可要求を行い、その次に、1つまたは複数の決定に基づいて、適用可能なサービス応答を処理して戻すか、または、アクセスが拒否されたことを表示する応答を戻す。首尾一貫したメカニズムを提供することに加えて、認可ノードを決定に到達させるメカニズムが、最も適切なポリシー決定メカニズムが特定のプラットフォームとクライアントとに関してインプリメントされることが可能であるように、実用上可能な限りオープンであることが望ましい。MediaDriveが中立のポリシー管理システムであることが好ましい。MediaDriveは、どのように認可ノードが認可クエリーに基づいてサービスに対する認可に関する決定に到達するかを命令しない。<0094>MediaDriveが、特定のプラットフォームに関して認可ノードによって使用される特定のポリシーエンジンまたはポリシー言語を指示しないことが好ましいが、好ましい実施形態では、認証要求が、交換され取り扱われることが可能な特定の標準的な形態を有することが、相互運用性のために必要である。拡張可能な認可クエリー要求が、異なったポリシー管理システムとの関連において異なったタイプの認可クエリー要求にその認可クエリーが適合できるように、フレキシブルなペイロードを有することが可能である。一実施形態では、サポートが、少なくとも2つの認可フォーマット、すなわち、1単純なリクエスタID、リソースID、および、アクションIDのような、入力として特定の最小公分母基準を使用する非常に単純な包絡線を提供する単純なフォーマットと、2認可クエリーの包絡されたセキュリティ表明マークアップ言語SecurityAssertionMarkupLanguage形式を送る方法を提供するSAMLフォーマットに関して提供される。<0095>好ましい実施形態では、あらゆる認可ノードが、少なくとも単純なフォーマットを認識してサポートし、および、どんなネイティブなポリシー表現フォーマットが認可ノード上に存在しても、それをマッピングすることが可能なことが要件である。他のフォーマットの場合には、認可ノードは、それが認可クエリー要求のペイロードを取り扱わないかまたは理解しないならば、適切な誤り応答を戻すべきである。基本MediaDriveフレームワークに対する拡張が、認可クエリーの許容可能なフォーマットをノードがネゴシエートするための、および、特定の認可サービスプロバイダノードによって何のフォーマットがサポートされるかを判定するためにノードが問い合わせるための機能を含んでもよい。<0096>一実施形態では、認可クエリー応答は、拡張可能であるが、アクセスが容認されるか否かを表示するために単純な形式から成る。このサービスのためのこの応答の他の形式が採用可能であり、特定のインタフェースに対するアクセスが容認されるべきである場合には要求ノードが履行されなければならないだろうという義務の仕様を含む。<0097>11.コンシューマメディアアプリケーションMediaDriveの実施形態が、パーソナルエリアネットワーク、ローカルエリアネットワーク、ホームゲートウェイ、および、IPベースと非IPベースとのワイドエリアネットワークを含む多層環境内の幾つかの異なったサービスに対して、様々なコンシューマデバイスをリンクさせるために使用されることが可能である。例えば、相互運用性が、セル電話、ゲームプラットフォーム、PDA、PC、ウェブベースのコンテントサービス、発見サービス、通知サービス、および、アップデートサービスを使用する1つの相互接続されたシステムにおいて成功裏に実証されている。この実施形態は、複数のメディアフォーマット例えば、MP4、WMF等、Bluetooth登録商標経由またはUDDI、LDAP、ActiveDirectoryのようなレジストリ経由のサービスの発見のための複数の発見プロトコル、および、同一のデバイス上のIPベースの通知とワイヤレスSMS通知をサポートする。編成の特徴が、相互運用性の障壁をコンシューマが克服することを補助するために使用される。コンテントに関するクエリーが存在する時には、要求を履行するために、発見サービス、探索サービス、マッチングサービス、アップデートサービス、権利交換サービス、および、通知サービスを含む様々なサービスが協調させられる。好ましい実施形態では、コンシューマが、ほとんどあらゆるデバイスを使用し、コンテントを希望し、そのコンテントと権利とがほぼ瞬時に履行されることが可能であり、コンテントを使用しかつ共有する能力を与えることが望ましい。この編成能力は、コンシューマが動的な多層ネットワーク内の任意のポイントで実質的にあらゆるデバイスからのホームおよびインターネットベースのコンテントのキャッシュを閲覧することを可能にする。この能力は、ストリームとプレイリストを共用することと、発見と接続とが容易な即座のブロードキャストとナローキャストを行うことと、権利が尊重されることを確実なものとしながら様々な異なったデバイスを使用することとを促進する、より先進的なサービスに拡張されることが可能である。<0098>コンシューマ中心の側面を越えて、メディアフォーマットのための規格と権利管理と履行プロトコルとの単一のセットに依存しないエンドツーエンドの相互運用可能なメディア配信システムを提供する方法を発見することが一般的に望ましい。コンテント発信元、ディストリビュータ、リテーラ、サービスプロバイダ、デバイス製造業者、および、コンシューマを含む価値連鎖の中には、幾つかのローカライズされた要求が各セグメント毎に存在する。これは、特に権利管理の場合に当てはまり、この場合には、コンテント発信元が、下流の異なった価値連鎖要素に対して様々な文脈において異なった形で適用されてよい、使用権利を表現することを必要とする場合が多い。コンシューマゲートウェイが、典型的には、関心concernのより著しく狭いセットを有し、および、エンドユーザデバイスが、典型的には、関心のさらに単純なセットを有し、すなわち、コンテントを再生playするだけである。<0099>動的な自己構成配信システムの充分に自動化されたシステムの場合には、コンテント発信元が、コンテントを作成してパッケージングし、権利を表現し、および、すべての関係コンシューマがどこにいようとも、または、すべての関係コンシューマが何の種類のデバイスを使用していようとも、すべての関係コンシューマに対してコンテントをほぼ瞬時に提供するために他のサービスプロバイダによって付加された価値に確信をもって依存することが可能である。MediaDriveの実施形態が、この目標またはこの目標の諸側面を履行するまたは履行に接近するために使用されることが可能であり、および、エンドツーエンド規格のモノリシックなセットを待つ必要なしに、または、これに依存することなしに、コンシューマとサービスプロバイダの両方に利益を与える新たなサービスを発明および導入するために手段を複数のサービスプロバイダに提供することが可能である。1つの採用可能なアプローチが、コピー保護ではなくサービスインタフェースのポリシー管理に焦点を当てる、より自然な関心の分離によってコンポーネントの形にディジタル権利の管理が分解されることを可能にする。このアプローチは、有用な情報と瞬時の満足とをコンシューマに提供するサービスのリッチなインフラストラクチャによってコンテントが提供されるので、ディジタルコンテントドメイン内におけるコンシューマとコンテントプロバイダとの間の緊張を変化させる可能性を有する。ポリシー管理が、著作権侵害者が合法的なサービスをレバレッジすることが可能な度合いを制限することが可能である。実際には、MediaDriveは、ネットワーク効果が、著作権侵害者によって提供されることが可能な価値を超える価値を結果的にもたらす合法的なサービスの非常にリッチなセットの進化を促進することを可能するように設計される。<0100>12.一般的な企業アプリケーションポリシー管理されたP2Pサービス編成が、サプライチェーンマネジメントSCMとカスタマリレーションシップマネジメントCRMとのような領域に対してビジネスの世界における幾つかの関連アプリケーションを有するように思われる。CRMはカスタマの発見と獲得と維持とに関する。これは、統合された情報システムと、任意の所望の通信チャンネルを経由してカスタマが通信することを可能にするコンタクトセンターインプリメンテーションとを使用してカスタマに焦点を合わせることが有利である、概ねあらゆるカストマー中心のeBusinessストラテジにおけるコアエレメントである。これは、さらに、サプライヤにも当てはまる。大半の企業は何らかの種類の階層制度と部門細分化を有し、内部的には適切に機能する部門およびプロセスのビューが、カスタマおよびサプライヤにとっては適切に機能するとは限らない。企業の部門がその部門のためのサービスインタフェースの包括的なセットを公開することを可能にすることが望ましく、この結果として、企業の部門のサービスが、異なったカスタマとサプライヤとによって、それら自体のプロセスとサービスを最適化する仕方でポリシーにしたがって適合させられることが可能である。これは、企業情報ポータルを上回る重要なステップであり得る。<0101>今日では、大半の企業が、所有権を主張できるクライアント/サーバインフラストラクチャを使用するモノリシックなソフトウェアアプリケーションとして出現する比較的に高コストの汎用アプリケーションスーツを使用して、CRMをインプリメントする。これらのアプリケーションスーツは、大量のコンフィギュレーションの後に企業内で相互運用する。ウェブサービスは、オープンプロトコルと、通信がクローズドLANだけでなくMANおよびWANを経由しても行われる分散ウェブサービスインフラストラクチャとの使用を可能にする。このモデルは、リモートアプリケーションサービスプロバイダASPが、様々なデータセンタからの企業内の複数のエンティティに対するサービスの集まりとしてのCRMアプリケーション能力を管理し配信することを可能にする。ビジネスユニットまたは部門がポータルとなり、および、場合によってはこれらのサービスのためのアグレゲータaggregatorとなる。これは、サービス志向アーキテクチャ/アプリケーションSOAの領域においてIT産業に生じている進化との関連において理解されることが可能である。アプリケーションに関連したサービスに対する企業のインタフェースとカスタマのインタフェースの両方が、単純なブラウザベースのアプリケーションから、より大きなフットプリントのPC中心のアプリケーションまでを範囲に含むことが可能である。<0102>この新しいモデルは、依然として、このモデルがメインストリームに受け入れられることを妨げる障壁をもたらす幾つかの大きなハードルに直面する。例えば、<0103>情報の機密性とアクセスコントロール。ASPがSRMソリューションを提供する時に、企業が、別の企業の手中に機密カスタマデータを置くことに関する問題に遭遇することがある。企業は、合法的なエンティティだけがこの情報にアクセスできるということを確実なものにしなければならない。カスタマの観点からは、彼らは別の企業と公然のまたは暗黙の新しい関係を潜在的に有する。必要とされるものは、カスタマと企業の両方がそれらの情報に対してアクセスコントロールを行うことを可能にするインフラストラクチャ上のメカニズムである。<0104>アプリケーションの拡張性。ASPは、テクノロジベンダとこれらに関連した製品またはサービスとの特に小さなセットと提携することが多い。企業は、異なったベンダからの多様なテクノロジのセットをレバレッジするためにフレキシビリティを好むことが多い。アプリケーションフレームワークは、特定のASPの現在の企業関係またはテクノロジ選択によって必ずしも制限されるべきではなく、この代わりに、異なったテクノロジベンダまたは他のASPから提供される新たな機能性とASPが迅速かつ効果的に統合することを可能にするインフラストラクチャ上のメカニズムを有することが望ましいだろう。このアプリケーションフレームワークは、さらに、例えば企業内で開発された拡張機能に基づいて、ビジネスユニット自体によって直接的に提供されるCRMサービスの統合も可能にするはずである。<0105>サービスレベル合意ServiceLevelAgreementSLA。ビジネスのサービス要件は一般的に静的ではないだろう。この代わりに、企業のサービス要件は、典型的には、競争によって促進される新たな機能性、内部ビジネスアクティビティと特定のアクティビティのためにサポートされるカスタマの数とに基づいたオペレーション負荷、および、より低コストのサービス代替策をレバレッジする能力を含む可変的な条件に基づいて変化するだろう。場合によっては、これらの変化が長期間にわたる人間の介入を必要とすることがあるが、他の場合には、これらの変化は、指定されたルールのセットに基づいて自動化されるか迅速に再構成されることが可能である。これらの場合の両方に関して、CRMアプリケーションサービスが、既存の環境と、ASPとビジネスユニットとの間の認可された合意とに基づいて、新たなコンフィギュレーションにオーケストレートされると見なされることが可能である。これらのアプリケーションのタイプは、自己編成として特徴付けられることが可能である。<0106>MediaDriveの実施形態が、これらの要求の一部または全部に対処する上で一定の役割を果たすことが可能である。例えば、MediaDriveの実施形態が、信用できる認可されたエンティティだけが関連のサービスと情報とに対するアクセス権を有する、CRMおよびSCMのような動的でサービス志向の自己編成アプリケーションを構築することにおいて、上述の要件に対応するために必要とされる必要なインフラストラクチャ上のビルディングブロックを提供するために使用されることが可能である。<0107>図15は、異なった利害関係者にCRM関連サービスを配信するという文脈においてMediaDriveがどのように使用されることが可能であるかを示すシナリオを図示する。図15に示されているシナリオでは、ビジネスユニットが、異なったタイプのCRMアプリケーションを構築するために、または、ビジネスユニットの組織内の異なった部門に対して、または、そのカスタマに対してカスタマデータの異なったビューを提供するために、必要なサービスを提供するように様々な異なったASPを使用することが可能である。<0108>このシナリオは、次に示すものの一部または全部を含む、MediaDriveフレームワークの好ましい実施形態によって提供される機能性を使用する幾つかの側面を示す。異なったCRMテクノロジベンダの間の公然または暗黙の相互運用性。必要なインタフェースを記述することによって、および、ASPのレベルにおいて、または、既存のCRMソフトウェアスーツの最上位で、サービス適合層を使用して適切なバインディングを提供することによって、異なったプロバイダからの多様なCRMテクノロジによって単一のASPまたは複数のASPをビジネスが使用することが可能である。MediaDriveフレームワークを通してカスタマデータにアクセスすることによって、アクセスコントロールのためにそのリッチなポリシー管理フレームワークをレバレッジすることが可能である。部門が、サービスプロキシを通してその部門のアプリケーションのために必要なCRM関連サービスを配信にアクセスし、これによって搬送プロトコルやデータフォーマット等の互換性を取り巻く問題からビジネスユニットを隔離することが可能である。MediaDriveフレームワーク内の部門とデータウェアハウスとアプリケーションサービスプロバイダとの間のインタラクションが統治されることが可能である。合法的に認可されたエンティティだけがサービスにアクセスすることが可能であると共に、異なったMediaDriveフレームワークのパティシパントが許容可能なレベルの信用をそのパティシパントのインタラクションにおいて確立することが可能である場合にだけ、サービス呼出しが生じるだろう。サービスの合成と編成。CRMアプリケーションが、互いにオーケストレートされた幾つかの異なったASPからのサービスからなるか、または、そのアプリケーションが単一のASPから配信されるが、しかし、異なったカスタマビューのために動的にコンフィギュレーションされることをその合成と使用とが必要とする複数のサービスから依然として成るという点で、CRMアプリケーションは自己組織的である。サービスプロバイダによって露出される機能性がサービスレベル合意SLAと実行環境とによって駆動される時間全体にわたって変化することが可能である。MediaDriveワークフローコレータが、サービスをオーケストレートするために使用されることが可能である。このインタラクションを制御するために使用されるルールがMSDLにおいて直接的に指定されてもよく、または、記述を理解し翻訳することが可能なワークフローコレータのために書かれたプラグインが存在する限りは、SLAにおいて何らかの標準的な仕方で成文化されてもよい。ワークフローコレータが、要件に基づいて指定されたサービスを提供する方法を決定するために、必要なメッセージを収集して処理するようにMediaDriveメッセージポンプと協働して機能するということが想起されなければならない。<0109>この実施形態では、MediaDriveが、InterTrustのPolicyWorksおよびPolicySpeak表現言語に基づいた分散ポリシー管理サービスのセットを使用してインプリメントされている。しかし、MediaDriveは、IBMのPolicyDirectorおよびXACMLのような他のポリシー管理フレームワークおよび言語を使用するように設計され、および、好ましい実施形態では、MediaDriveはポリシー管理サービスインタフェースを提供し、したがって、あらゆる適切なポリシー管理フレームワークおよび/またはポリシー表現言語が使用可能である。<0110>背景として、PolicyWorksは、企業内と、企業間と、企業とカスタマとの間とにおけるネットワークベースのコンテントとサービスとリソースとの使用に関するルールと権利とポリシーとを作成し配備し管理し執行するように構成されることが可能であるソフトウェアコンポーネントのセットである。企業のポリシーおよびコントロールが、ユーザと信用証明書とディレクトリとコンテントメタデータと他のポリシーおよびコントロールとを識別するための手段とインタラクトする必要があることが多いので、PolicyWorksは、企業の中に効率的に統合されるように、かつ、既存のアプリケーションとディレクトリと識別システムとをレバレッジするように設計されている。PolicyWorksの目的は、ネットワークおよびファイルシステムアクセス管理と企業情報ポータルと資産管理から、サプライチェーン管理とウェブサービスとディジタルロッカサービスとコンシューマメディアサブスクリプションアプリケーションまでを範囲とする様々な主要なアプリケーションの全体にわたるポリシーおよびルールのセキュアな管理を簡素化し統合することである。<0111>好ましい実施形態では、PolicyWorksアーキテクチャは、次の幾つかの基本インタフェースを露出させる論理モデルに基づいている。統治されたオペレーション-このインタフェースは、特定のリソースやコンテントアイテムやサービスに関する上述のアプリケーションのようなアプリケーションのアクションを統治するために、こうしたアプリケーションによって使用される。実質的にすべてのアイテムが、永続的な機密保護、アクセスコントロール、使用量の監視と検査、または、トランザクション管理を実現する、PolicyWorksを使用して統治されることが可能である。このインタフェースを経由して、アプリケーションが、使用のためのルールと要件とが準拠されるという保証を伴って、ポリシーコントロール下で、アイテム、サービス、または、リソースを利用可能にする。統治コンポーネントが、アイテムを統治するために必要な方法とオペレーションとをカプセル化する。PolicyWorksは、MicrosoftOfficeとAdobeAcrobatにおけるネイティブな文書保護メカニズムと、J2EEEJBとMicrosoft.NetFrameworkとによって与えられるコードリソースおよびサービス保護メカニズムとのような、こうした統治のための幾つかのカスタマイズ可能な標準規格品としてソリューションの使用を可能にする。ポリシークエリー-このインタフェースは、特定のユーザのための統治されたアイテムやリソースやサービスと、条件のセットと、環境データと、他のあらゆる関連ファクタとに関して何のアクションが許可されるかを厳密に決定するために使用される。クエリーに対する応答が、アイテムの使用に付随している許可および/または追加の条件と義務を含むことが可能である。統治コンポーネントは、クエリーに対する応答を受け取ると、そのポリシーの執行と、あらゆる義務の実行または実行の起動と、要求された使用の結果の監視との責務を負う。信用証明書クエリー-このインタフェースは、統治されたオペレーションに関連しているポリシーにおいて役割を演じる可能性があるユーザの属性を決定するために、ポリシーマネジャーによって使用される。この論理モデルは実際のインプリメンテーションにおいて強化され、したがって、例えば、幾つかのディレクトリと、アクターactorユーザ、ポリシークリエータ、リソースマネジャー等と統治されたアイテム自体とに関するルールとメタデータとのソースが存在する可能性があるので、ポリシーマネジャーコンポーネントが、ポリシークエリーに対する応答を決定するために外部および内部の両方の幾つかのインタフェースおよびリソースに対するアクセス権を有する。セキュリティサービス-このインタフェースは、統治されたアクションのリクエスタのための自己識別管理サービスを得るために、および、統治されたアイテムのための永続的な保護サービスを得るために使用される。ポリシーアドミンpolicyadmin-このインタフェースは、統治されたアイテムに属するルールとコントロールの分散ポリシー管理データベースを管理するために使用される。ポリシーをオーサリングおよび維持するための様々なツールがこのインタフェースを使用する。これらのツールは、ポリシーを適用し管理するための非常に簡単な方法を提供することが可能である。例えば、このインタフェースを使用することによって、ファイルシステムにおける共用フォルダにポリシーを関連付けるツールが生成されることが可能であり、および、文書をドラッグしてそのフォルダの中に入れることによってあらゆるユーザが簡単に文書または、他のオブジェクトにポリシーを適用することを可能にすることができる。他のツールが、非常に厳密でターゲットにされた条件でポリシーを指定するために任意の数のポリシー表現言語を使用する、より先進的なオーサリング技術を使用することが可能である。<0112>SCMが、実質的にあらゆる企業の構成員が、その外部ベンダネットワークを、MediaDriveサービスによって管理された発送命令ポリシーと、MediaDrive互換の通知サービスによって調整された請求業務とを伴う、1つの大きな仮想貯蔵庫と見なすことが可能である、別のアプリケーションである。<0113>理解しやすいように上述の発明をある程度詳細に説明してきたが、本発明の原理から逸脱することなしに特定の変更と改変とが行われてよいということが明らかだろう。本発明のプロセスと装置との両方を実現する多くの代替の方法があるということに留意されたい。したがって、この実施形態は例示的でありかつ非限定的であると理解されなければならず、および、本発明は本明細書に示されている特定の詳細事項に限定されない。以下に示す付記B内の図1~7は、それぞれ、表18~24として示す。<付記B>ディジタル管理エンジンシステムおよび方法<0001>関連出願付記Bは、2003年9月15日付で出願されたGillesBoccon-Gibodによる標題ディジタル権利管理エンジンシステムおよび方法の米国仮特許出願番号60/504,524に対応する。この出願付記Bは、2003年6月5日付で出願されたWilliamBradleyとDavidMaherによる標題ピアツーピアサービス編成のためのシステムおよび方法の共通して譲渡された米国仮特許出願番号60/476,357Bradley他の出願、付記Aに関係している。この付記AにおけるBradley他の出願に対する参照が、上述の付記Aを参照する。<0002>著作権認可本特許文書の開示内容の一部が、著作権保護の対象となる資料を含む。著作権所有者は、WIPOまたは米国特許商標庁の特許ファイルまたは記録に示されているように、いかなる者による特許文書の複写複製または特許公開も認めるが、それ以外は、どのようなものであれ、すべての著作権の権利を留保する。<0003>発明の分野本発明は、一般的に、ディジタル情報およびサービスの配信と使用とに関する。さらに明確に述べると、ディジタル権利管理エンジンを提供し、サポートし、および/または、使用するためのシステムおよび方法が開示される。<0004>背景インターネットのようなネットワークがディジタルコンテント配信の支配的な媒体と成っている。ウェブサービスのための規格の出現が、標準化されたメカニズムによって複数のソフトウェアプラットフォームと共に相互運用しかつ他のウェブサービスと協働する高度なサービスを企業が提供することを可能にするこのトレンドを加速するだろう。<0005>発明の要約本発明の実施態様が、ウェブサービスモデルをレバレッジするディジタル権利管理エンジンを提供する。保護されたコンテントを取り扱うために比較的複雑で重量級のクライアント側エンジンを必要とする多くの従来のディジタル権利管理DRMシステムとは対照的に、本発明はクライアント側のDRMエンジンが比較的単純であることを可能にし、および、サービスレベルで動作するよりリッチなポリシー管理システムによって設定された統治ポリシーを執行する。本発明の実施態様は、さらに、メディアフォーマットと暗号プロトコルとの選択におけるフレキシビリティの増大を実現し、および、DRMシステムの相互間の相互運用性を促進することが可能である。<0006>本発明の好ましい実施態様が、強力なDRM対応アプリケーションを構築するために使用されることが可能な単純でオープンでフレキシブルなクライアント側のDRMエンジンを提供する。好ましい実施態様では、そのDRMエンジンは、Bradley他の出願で説明されているウェブサービス環境のようなウェブサービス環境に容易に統合されるように、および、実質的にあらゆるホスト環境またはソフトウェアアーキテクチャに統合されるように設計されている。好ましい実施態様では、このDRMエンジンは個別のメディアフォーマットと暗号プロトコルとから独立しており、標準化された技術または所有権を主張できる技術を使用するためのフレキシビリティを必要に応じて設計者に与える。これに加えて、好ましい実施態様で使用される統治モデルは比較的単純であるが、高度な関係とビジネスモデルとを表現するために使用されることも可能である。<0007>本発明の好ましい実施態様が、次の目標の一部または全部を実現するために使用されることが可能である。<0008>単純性。好ましい実施態様では、DRMエンジンは、コントロールプログラム例えば、統治ポリシーを執行するプログラムを実行するために必要最小限のスタックベースのバーチャルマシンVMを使用する。例えば、一実施態様では、このVMは数ページのコードだけから成ってよい。<0009>モジュール性。好ましい実施態様では、DRMエンジンは、より大きなDRM対応アプリケーションに統合された単一のモジュールとして機能するように設計されている。かつてはモノリシックなDRMカーネルによって行われた暗号化サービスのような機能の多くが、ホスト環境から要求されることが可能であり、このホスト環境はこれらのサービスを他のコードモジュールに提供してよい。このことが、設計者が比較的容易に標準的な技術または所有権を主張できる技術を組み込むことを可能にする。<0010>フレキシビリティ。このDRMエンジンの好ましい実施態様は、そのモジュール型の設計の故に、組込型デバイスから汎用PCに至る様々なソフトウェア環境で使用されることが可能である。<0011>オープンである。DRMエンジンの好ましい実施態様は、基準ソフトウェアとしての使用に適しており、したがってコードモジュールとAPIとが、実質的にあらゆるプログラミング言語とそのプログラミング言語が完全にコントロールするシステムとにおいてユーザによってインプリメントされることが可能である。好ましい実施態様では、そのシステムは、特定のコンテントフォーマットを採用するかコンテントエンコーディングを制限することをユーザに強制しない。<0012>意味論的に寛容であるsemanticallyagnostic。好ましい実施態様では、DRMエンジンは、認可要求をグラフの構造に関するクエリーに変える単純なグラフベースのモデルに基づいている。このグラフの頂点はそのシステムのエンティティを表し、および、有向辺がこれらのエンティティの間の関係を表す。しかし、このDRMエンジンは、これらの頂点と辺とが任意の特定のアプリケーションにおいて表すものを認識する必要はない。<0013>ウェブサービスとのシームレスな統合。DRMクライアントエンジンはウェブサービスを幾つかの形で使用することが可能である。例えば、認可グラフ中の頂点と辺とがサービスを通して動的に発見されることが可能である。さらに、コンテントとコンテントライセンスとが発見されて、高度なウェブサービスを介してそのDRMエンジンに配信されてよい。この好ましい実施態様のDRMエンジンが多くの場所においてウェブサービスをレバレッジするように構成されることが可能であるが、そのアーキテクチャはウェブサービスから独立しており、および、スタンドアロンのクライアント側DRMカーネルとして使用されることが可能である。<0014>簡略化された鍵管理。好ましい実施態様では、認可グラフのトポロジが、暗号リターゲティングcryptographicretargetingを必要とせずにコンテント保護鍵の導出を簡易化するために再使用されることが可能である。この鍵導出方法は採用随意であるが、DRMエンジンの強力な特徴であり、および、そのシステムは、さらに、または、この代わりに、他の鍵管理システムと統合することが可能であることが可能である。<0015>統治と暗号化とコンテントとの分離。好ましい実施態様では、コンテントを統治するコントロールが、統治を執行するために使用される暗号情報とは論理的に別個である。同様に、そのコントロールと暗号情報はコンテントとコンテントフォーマットとは論理的に別個である。これらの要素の各々が別々にまたは一体化されたパッケージの形で配信されることが可能であり、したがってコンテント配信システムの設計において高度のフレキシビリティを可能にすることが可能である。<0016>本発明の好ましい実施態様は上述の目標の一部または全部を実現するために使用されることが可能である。しかし、さらに本発明がこれらの目標を実現しないシステムによっても実施されることが可能であるということを理解されたい。<0017>好ましい実施態様では、DRMエンジンは、保護されたコンテントに対する特定のアクションが許可可能であるかどうかを判定するように設計されているバーチャルマシンVMを含む。このコントロールVMは、最小の命令セットを有する単純なスタックベースのマシンとしてインプリメントされてよい。一実施態様では、このコントロールVMは、論理計算と算術計算とを行うことと、システムタイム、カウンタ状態等のようなパラメータを検査するためにホスト環境から状態情報を問い合わせることとが可能である。<0018>好ましい実施態様では、DRMエンジンは、DRM価値連鎖内のエンティティの相互間の関係を検証するためにグラフベースのアルゴリズムを使用する。図1は、こうした認可グラフの一例を示す。図1に示されているように、このグラフは、リンクによって連結されたノードの集まりを含む。好ましい実施態様では、このリンクのセマンティックスはアプリケーションに特有の形で変化してよい。例えば、Mac頂点からノックス頂点への有向辺が、ノックスがそのMacの所有者であるということを意味する。ノックスから公立図書館への辺が、ノックスが公立図書館のメンバであるということを表示するだろう。好ましい実施形態では、DRMエンジンはこれらのセマンティックスを強制も翻訳もしない。DRMエンジンは、そのグラフ内の経路の有無を単純に確認する。<0019>例えば、コンテント所有者が、消費デバイスが公共図書館のメンバによって所有されかつRIAA承認されている場合に特定の音楽楽曲が再生されることを可能にするコントロールVMによって翻訳されるコントロールプログラムを生成してもよい。そのデバイス上で実行しているコントロールVMがこのコントロールプログラムを評価する時には、DRMエンジンは、ポータブルデバイスと公共図書館との間のリンクと、ポータブルデバイスとRIAA承認との間のリンクとが存在するかどうかを判定する。グラフの辺と頂点とが静的でありかつデバイスの中に組み込まれてよく、または、動的であり、かつ、ホストアプリケーションと通信するサービスによって発見されてよい。<0020>ノードとリンクとにセマンティクスを強制しないことによって、この好ましい実施態様のDRMエンジンは大きなフレキシビリティを可能にする。このシステムは、伝統的な委任delegationベースのポリシーシステムから、認可されたドメインおよびパーソナルエリアネットワークまでの、様々なユーセージモデルに適合させられることが可能である。<0021>好ましい実施態様では、DRMクライアントは、さらに、コンテント保護鍵導出のために認可グラフを再使用することも可能である。システム設計者は、リンクの存在が特定の暗号情報の共用も表示することを可能にすることを選択してもよい。この場合には、認可グラフは、消費デバイスに対する明示的な暗号リターゲティングなしにコンテント鍵を導出するために使用されることが可能である。<0022>DRMエンジンの好ましい実施態様はモジュール型であり、これによって様々な異なったデバイスおよびソフトウェア環境への統合を可能にする。図2は、コンテント消費デバイスの中へのDRMクライアントエンジンの典型的な統合を示す。図2に示されているシステムのようなシステムでは、典型的なコンテント消費イベントは次のように進行してよい。<0023>ホストアプリケーション202が、典型的にはそのユーザインタフェース204を通して、コンテントの特定部分にアクセスするための要求を受け取る。ホストアプリケーション202は、すべての関連したDRMエンジンオブジェクト好ましくはホストアプリケーションに対して不透明であると共に、その要求をDRMエンジン206に送る。DRMエンジン206は、明確に定義されたインタフェースを通してホストサービスモジュール208に対して追加の情報と暗号サービスとを求める要求を行う。例えば、DRMエンジン206は、特定のリンクが信用できるかどうかをホストサービス208に質問してよく、または、特定のオブジェクトが暗号解読されることを求めてもよい。必要な情報の一部分が非ローカルであってもよく、この場合には、ホストサービス208は、サービスアクセスポイント214を通して、ネットワークされたサービスからその情報を要求することが可能である。<0024>特定のオペレーションが許可されるとDRMエンジン206が判定すると直ちに、このDRMエンジン206は、このことを表示し、および、要求されたあらゆる暗号化鍵をホストサービス208に対して戻し、このことは、必要に応じて、暗号サービス212と協調させられたメディアレンダリング210例えば、スピーカによってコンテントを再生すること、画面上にコンテントを表示すること等を開始させる。<0025>図2に示されているシステムアーキテクチャは、DRMエンジンがアプリケーションにおいてどのように使用されることが可能であるかの単純な例であるが、これは多数の可能性の中の1つに過ぎない。例えば、他の実施態様では、DRMエンジンは、比較的高度なポリシー管理システムの統治下でパッケージングアプリケーションに統合されることが可能である。<0026>この開示されている実施態様が、プロセス、機器、システム、デバイス、方法、または、コンピュータ可読媒体を含む様々な形でインプリメントされることが可能であるということを理解されたい。本発明のこれらの特徴と利点と実施態様と他の特徴と利点と実施態様とが、以下の詳細な説明と添付図面とによってさらに詳細に示されるだろう。図面の簡単な説明<0027>本発明の実施形態が、同じ照合番号が同じ構造要素を示す次の添付図面と組み合わせて以下の詳細な説明を参照することによって、容易に理解されるだろう。<0028>図1は、本発明の実施形態による認可グラフを示す。<0029>図2は、本発明の実施形態によるディジタル権利管理システムを示す。<0030>図3は、本発明の好ましい実施形態におけるコンテント保護と統治とのためにDRMエンジンが使用可能な様々なオブジェクトを示す。<0031>図4は、本発明の実施形態によるノードオブジェクトとリンクオブジェクトとを示す。<0032>図5は、本発明の実施形態によるコントロールバーチャルマシンとDRMエンジンとの統合を示す。<0033>図6は、本発明の実施形態によるコードモジュールを示す。<0034>図7は、コンテントの暗号化と暗号解読とを容易にするためのノードグラフの使用を示す。詳細な説明<0035>新規性のあるディジタル権利管理エンジンの実施形態が本明細書で説明される。当業者は理解するように、このエンジンの特徴と側面と構成要素とアプリケーションの多くと同様に、このエンジン自体に新規性がある。本発明主体の詳細な説明が以下に示されている。この説明は幾つかの実施形態に関連付けて行われているが、本発明がどれか1つの実施形態に限定されることがなく、その代わりに、数多くの代替案と変型と等価物とを含むということを理解されたい。例えば、幾つかの実施形態がコンシューマ志向のコンテントとアプリケーションとに関連付けて説明されているが、当業者は、開示されているシステムおよび方法がより広範なアプリケーションに容易に適合可能であるということを理解するだろう。例えば、本発明の実施形態は、非限定的に、企業コンテントおよびアプリケーションに関連して容易に適用されることが可能である。これに加えて、本発明の完全な理解を実現するために数多くの具体的な詳細が後述の説明において記述されているが、本発明はこれらの詳細の一部または全部を伴わずに実現されてよい。さらに、理解を容易にするように、本発明に関連した技術分野では公知である特定の技術的資料は、本発明を不必要に不明瞭にすることを避けるために、詳細に説明されてはいない。<0036>好ましい実施形態では、DRMクライアントエンジンが基本オブジェクトまたはビルディングブロックのグループに対して作用する。図3が、これらのオブジェクトの高レベルの図表を示す。図3に示されているように、好ましい実施形態では、コンテントオブジェクト302によって表されるデータが、鍵を使用して暗号化される。この鍵は、コンテント鍵オブジェクト304によって表現されており、および、コンテントと鍵との間のバインディングがプロテクタオブジェクト306によって表現されている。コンテントを暗号解読するための鍵の使用を統治するルールがコントロールオブジェクト308によって表され、および、コンテント鍵304とコントロール308との間のバインディングがコントローラオブジェクト310によって表されている。準拠したシステムが、コントロールオブジェクト308においてバイトコードによって表現されるルールの統治下でコンテント暗号解読鍵を使用する。<0037>コンテントオブジェクト302:好ましい実施形態では、コンテントオブジェクト302は外部オブジェクトである。そのフォーマットと記憶はDRMエンジンの制御を受けず、むしろ、ホストアプリケーション例えば、MP4映画ファイル、MP3音楽トラック等であることが可能であるのコンテント管理サブシステムのコントロールを受ける。しかし、好ましい実施形態では、コンテントのフォーマットは、IDをコンテントペイロードに関連付けることを可能にするようなフォーマットである。コンテントペイロードは、フォーマットに依存した形で例えば、AESのような対称暗号によって暗号化される。<0038>コンテント鍵オブジェクト304:好ましい実施形態では、コンテント鍵オブジェクト304は、固有の暗号化鍵とこれに関連したIDとを含む。このIDの目的は、プロテクタオブジェクト306とコントローラオブジェクト310とがコンテント鍵オブジェクト304を参照することを可能にすることである。コンテント鍵オブジェクト304にカプセル化されている実際の鍵データ自体が、コンテントを暗号解読することを認可されているレシピエントだけによってこの鍵データ自体が読み出されることが可能であるように暗号化される。コンテント鍵オブジェクト304は、さらに、鍵データを暗号化するために使用された暗号化システムを指定することが好ましい。コンテント鍵データを保護するために使用されるこの暗号化システムは、鍵配布システムと呼ばれる。様々な鍵配布システムが使用されることが可能である。<0039>プロテクタオブジェクト306:好ましい実施形態では、プロテクタオブジェクト306が、コンテントオブジェクト302に含まれているデータを暗号化するためにどの鍵が使用されたかをDRMエンジンが発見することを可能にする情報を含む。プロテクタオブジェクト306は、さらに、そのデータを暗号化するためにどの暗号化アルゴリズムが使用されたかに関する情報も含む。プロテクタオブジェクト306は、コンテントオブジェクト302を参照する1つまたは複数のIDと、データを暗号化するために使用された鍵を保持するコンテント鍵オブジェクト304を参照するIDとを含む。好ましい実施形態では、プロテクタ304が2つ以上のコンテントオブジェクト302をポイントする場合に、これらのコンテントオブジェクトのすべてが、同一の暗号化アルゴリズムと同一の鍵とを使用して暗号化されているデータを表す。<0040>コントロールオブジェクト308:コントロールオブジェクト308は、ホストアプリケーションによって要求される時にコンテントに対する特定のアクションが許可されるべきであるかどうかに関してDRMエンジンが決定することを可能にする情報を含む。コンテント鍵の使用を統治するルールは、コントロールバイトコードとしてコントロールオブジェクト308において符号化される。コントロールオブジェクト308は、さらに、それがコントローラオブジェクト310によって参照されることが可能であるように、固有IDを含む。好ましい実施形態では、コントロールオブジェクト308は署名され、その結果として、DRMエンジンは、決定のためにコントロールバイトコードが使用される前にそのコントロールバイトコードが有効でありかつ信用できるということを検証することが可能である。コントロールオブジェクト308の妥当性は、さらに、コントローラオブジェクト310に含まれているセキュアハッシュの情報が利用可能である時に、このセキュアハッシュの検証によって随意に導出されることも可能である。<0041>コントローラオブジェクト310:コントローラオブジェクト310は、コンテント鍵オブジェクト304によって表された1つまたは複数の鍵の使用をどの1つまたは複数のコントロールオブジェクト308が統治するかをDRMエンジンが発見することを可能にする情報を含む。好ましい実施形態では、コントローラオブジェクト310は、さらに、そのコントローラオブジェクト310が参照するコンテント鍵オブジェクト304に含まれている鍵データのためのハッシュ値も含み、したがって鍵データとコンテント鍵オブジェクト304との間のバインディングが容易に改ざんされることは不可能である。コントローラオブジェクト310は、さらに、それらが関連付けられているコントロールオブジェクト308の完全性の検証を容易にする情報も含んでよい。コントローラオブジェクト310が署名されることが好ましく、したがってDRMエンジンは、コンテント鍵304とそれを統治するコントロールオブジェクト308との間のバインディングの妥当性と、コンテント鍵IDと実際の鍵データとの間のバインディングの妥当性とを信用することができる。コントローラオブジェクト310によって参照されるコントロールオブジェクト308のハッシュがコントローラオブジェクト310に含まれている実施形態では、コントロールオブジェクト308の妥当性が、コントロールオブジェクト308の署名を別個に検証する必要なしに導出されることが可能である。<0042>図1に関連して上述したように、好ましい実施形態では、DRMエンジンは、DRM価値連鎖におけるエンティティの間の関係を検証するために、グラフをベースとしたアルゴリズムを使用する。図1に示されているように、このグラフは、リンクによって連結されているノードの集まりを含む。ノードオブジェクトはDRMプロファイルのエンティティを表す。好ましい実施形態では、DRMエンジンは、ノードオブジェクトが表すものに関する明示的なまたは暗黙のセマンティクスを持たない。<0043>DRMエンジンを使用するシステムの特定の配備DRMプロファイルが、何のタイプのプリンシパルが存在するか、および、異なったノードオブジェクトが何の役割と自己識別とを表すかを定義するだろう。図4に示されているように、そのセマンティック情報は、典型的には、ノードオブジェクトの属性を使用して表現される。リンクオブジェクトがノード間の関係を表す。リンクオブジェクトは、さらに、DRMエンジンがコンテント鍵導出計算ためにリンクを使用することを可能にする何らかの暗号データを含むことが随意に可能である。ノードの場合と同様に、好ましい実施形態では、DRMエンジンは、リンク関係が意味するものに関する暗黙のまたは明示的なセマンティックスを持たない。リンクのからのfromまたはへのtoノードが特定のDRMプロファイルで表すものに応じて、リンク関係の意味がメンバシップ、所有権、関連付け、および/または、様々な他のタイプの関係を表現することが可能である。例えば、典型的なDRMプロファイルでは、特定のノードオブジェクトがユーザを表してよく、他のノードがデバイスを表してよく、および、他のノードがユーザグループを表してよい。この文脈においては、デバイスとユーザとの間のリンクが所有権関係を表してよく、および、ユーザとユーザグループとの間のリンクがメンバシップ関係を表してよい。図4がノードオブジェクトとリンクオブジェクトとの例を示す。<0044>ノード402:ノードオブジェクトがシステム内のエンティティを表す。ノードオブジェクトの属性が、DRMプロファイルに関連してノードオブジェクトによって表される役割または自己識別のような、ノードオブジェクトが表すものの特定の側面を定義する。好ましい実施形態では、ノードオブジェクトは、さらに、ノードオブジェクト典型的には、ノードによって表されるエンティティ、または、そのノードを管理する役割を持つ何らかのエンティティの機密部分に対するアクセス権を有するサブシステムに対して機密情報をターゲットするために使用される機密保持非対称鍵対も有する。ノードをターゲットにした機密情報が、そのノードの機密保持公開鍵によって暗号化されることが好ましい。コンテント保護非対称鍵対とコンテント保護対称鍵とが、コンテント鍵配布のための採用随意のコンテント鍵導出システムを使用する実施形態において、リンクオブジェクトと組み合わせて使用される。<0045>リンク404:好ましい実施形態では、リンクオブジェクト404が署名され、その頂点がノードオブジェクトであるグラフの中のToノードとFromノードとの間に有向辺が存在するということを表明する。ノードとリンクとの特定のセットでは、そのグラフ中のノードX頂点とノードY頂点との間に有向の経路が存在する場合に、ノードXとノードYとの間の経路が存在する。ノードXとノードYとの間の経路が存在する時には、ノードYはノードXから到達可能であると言い表される。したがって、リンクオブジェクトによって表される表明は、どのノードが他のノードから到達可能であるかを表現するために使用される。コンテントオブジェクトを統治するコントロールが、コンテントオブジェクトに対するアクションを要求しているエンティティを表すノードからの特定のターゲットノードへの到達可能性を特定のアクションが生じさせることを可能にするための条件として、使用することが可能である。例えば、ノードDが、コンテントオブジェクトに対して再生アクションを行うことを望むデバイスを表す場合には、このコンテントオブジェクトを統治するコントロールが、特定のユーザを表す特定のノードUが到達可能であるかどうかを試験することが可能である。ノードUが到達可能であるかどうかを判定するために、DRMエンジンは、ノードDとノードUとの間に経路を確立することが可能なリンクのオブジェクトセットが存在するかどうかを検査する。<0046>DRMエンジンが、ノードグラフ中の経路の存在を確認するためにリンクオブジェクトを使用する前に、そのリンクオブジェクトを検証することが好ましい。リンクオブジェクト例えば、x509v3に署名するために使用される証明書システムの特定の特徴に応じて、リンクオブジェクトは、限定された寿命を与えられたり、取り消されたりすることが可能である。さらに、好ましい実施形態では、どのエンティティがリンクオブジェクトに署名することが可能であるかということ、どのリンクオブジェクトが生成可能であるかということ、および、リンクオブジェクトの寿命とを統治するポリシーは、DRMエンジンによって直接的には処理されない。これらのポリシーはDRMエンジンの外側に存在し、および、典型的にはノードの属性情報をレバレッジするだろう。例えば、特定のポリシーの下でデバイスノードとユーザノードとをリンクさせるリンクオブジェクトを生成する能力がすでに与えられているエンティティが、そのノードオブジェクトが実際にデバイスを表しているということを表示する属性を有するノードオブジェクトと、そのノードがユーザを表すということを表示する属性を有するノードとの間のリンクだけを、そのエンティティが生成するということを恐らくは検査するだろう。<0047>最後に、リンクオブジェクトは、鍵配布のためのノードのコンテント保護鍵の使用を可能にする暗号化データを含むことが可能である。特定の実施形態では、この暗号化データは、メタデータに加えて、Toノードのコンテント保護公開鍵および/またはコンテント保護対称鍵で暗号化された、Fromノードのプライベートおよび/または対称コンテント保護鍵を含む。ノードとリンクの関係とオペレーションとに関する追加情報を、見出しノード、リンク、および、コンテント保護の下で後述する。<0048>好ましい実施形態では、DRMエンジンが、これらの基本オブジェクトに付与されているセマンティックスを明示的にまたは暗黙に指定しないので、そのDRMエンジンを使用するシステムは、セマンティック文脈にこれらのオブジェクトを入れる、これらのオブジェクトに関する1つまたは複数の使用パターンに関与するだろう。これらのセマンティック文脈がDRMプロファイルと呼ばれるだろう。この意味において、DRMエンジンオブジェクトは、DRMシステムを構築するために使用されるDRMビルディングブロックであると見なされることが可能である。<0049>次のパラグラフは、DRMエンジンオブジェクトを使用して構築されることが可能な典型的なタイプのDRMプロファイルを示す。<0050>事例1:ユーザ、PC、および、デバイス<0051>このDRMプロファイルの事例では、ユーザコンテントを消費している個人、PCコンテントを使用するソフトウェアアプリケーションを実行するコンピュータ、および、デバイスコンテントを使用例えば、再生するハードウェアとソフトウェアとの組合せというエンティティが定義される。このプロファイルの例では、あらゆるユーザが無制限な数のデバイスを所有することが可能であり、および、予め決められた数までのPC例えば、4つのPCに関連付けられることが可能である。コンテントは、コンテントがユーザにバインドされることを可能にするルールによって統治されることが可能である例えば、ルールは、コンテントを再生するPCまたはデバイスが特定のユーザに属するか関連付けられていることを検査することが可能である。<0052>ユーザ、PC、および、デバイスの各々はノードオブジェクトに割り当てられる。これらのノードオブジェクトは、これがユーザ、PC、または、デバイスを表すかどうかを表示するタイプ属性を有する。<0053>バックエンドシステムがユーザの自己識別を管理し、および、ユーザノードと、PCノードとユーザノードの間のリンクオブジェクトとを生成する。ユーザノードオブジェクトがPCソフトウェアインスタンスに送られる前に、バックエンドサーバが、ユーザ情報データベース内のユーザをルックアップすることと、特定のPCに関連付けられることを望んだユーザが4人という限界に達したかどうかを判定することとによって、ユーザ1人当たり4つのPCポリシーを執行するだろう。特定の実施形態では、そのシステムは、時間の経過に応じてユーザが関連付けられるPCのセットをそのユーザが変更できるように、既存のPC/ユーザ関連付けをそのユーザが取り除くための方法を提供することができる。PCソフトウェアはPC対ユーザのリンクオブジェクトを保持し、および、このリンクオブジェクトが有効状態のままである限りこのリンクオブジェクトを使用することが可能である。<0054>PCソフトウェアが、デバイスをユーザに関連付ける能力を与えられる。このことは、PCノードオブジェクトに加えてユーザノードオブジェクトを管理する責務がPCソフトウェアに与えられることを意味する。ソフトウェアは、これらのノードの機密部分に対するアクセス権を有する。ユーザが自分のコンテントをデバイス上で再生することを望むのでユーザがデバイスに関連付けられることを望む時には、デバイスノードとユーザノードとからのリンクオブジェクトが存在する必要がある。そのリンクが存在しない場合には、PCソフトウェアがそのリンクを生成し、および、そのリンクをデバイスに対して使用可能にするだろう。デバイスはそのリンクオブジェクトを保持し、および、そのリンクオブジェクトが有効状態のままである限りそのリンクオブジェクトを使用するだろう。<0055>コンテントをユーザにバインドするために、パッケージャアプリケーションがIDを選択するか、または、コンテントのために既存IDを使用するだろう。パッケージャは、コンテントオブジェクトとコンテント鍵オブジェクトとをバインドするために、暗号化鍵と、これに関連付けられているコンテント鍵オブジェクトと、プロテクタオブジェクトとを生成する。その次に、パッケージャは、再生アクションの遂行を要求しているPCまたはデバイスノードからユーザノードが到達可能である場合に、および、この場合にだけ、再生アクションが生じることを可能にするコントロールVMバイトコードの形にコンパイルされていることが好ましいコントロールプログラムによってコントロールオブジェクトを生成する。典型的には、コントロールオブジェクト、コントローラオブジェクト、プロテクタオブジェクト、および、コンテント鍵オブジェクトは、場合に応じてパッケージングされたコンテント内に埋め込まれるだろうし、その結果としてPCおよびデバイスがそれらを別個に得る必要がないだろう。<0056>デバイスまたはPCがコンテントを再生することを望む時には、DRMエンジンがコンテントのコンテントIDのためのプロテクタオブジェクトを発見し、その次に、そのプロテクタによって参照されるコンテント鍵オブジェクトを発見し、その次に、そのコンテント鍵オブジェクトを参照するコントローラオブジェクトを発見し、最後にそのコントローラによって参照されるコントロールオブジェクトを発見するだろう。DRMエンジンは、コントールオブジェクトのコントロールプログラムを実行し、このコントロールプログラムは、ユーザノードが到達可能であるかどうかを検査するだろう。デバイスまたはPCノードが、そのノードとユーザノードとの間に経路が存在するということを検証するために必要なリンクオブジェクトを有する場合には、コントロールプログラムは、コンテント鍵オブジェクトに表されている鍵の使用を可能にし、および、デバイスまたはPCのメディアレンダリングエンジンがコンテントを暗号解読してレンダリング例えば、再生するだろう。<0057>事例2:一時的なログイン<0058>第2の事例が、PCノードとユーザノードとの間のリンクオブジェクトの生成を統治するポリシーが、ユーザがすでに別のPCに一時的にログインしていない限り、例えば12時間にすぎない一時的なログインを可能にするという新たな特徴が追加されている、上述の事例に関係して使用されるシステムと概ね同一のシステムを使用する。この特徴の目的は、例えば、ユーザが友人のPCに対して自分のコンテントを持って行き、一定の時間期間にわたってそのPCにログインし、および、自分のコンテントをその友人のPC上で再生することを可能にすることである。ユーザが自分の友人のPCにログインしようとする時には、そのユーザは自分のログイン信用証明書これは、ユーザ名/パスワード、移動電話認証、スマートカード、または、そのシステムのポリシーの下で許可された任意の認証システムであることが可能であるを入力し、および、バックエンドシステムが、リンクが要求されているユーザノードとPCノードとの属性を検査して、依然として有効であるアクティブな一時的なログインリンクが存在しないことを確認する。これらの条件が満たされると、バックエンドサービスは、ポリシーに準拠するために、要求されたログイン持続時間例えば12時間未満に制限された有効期間を有する、そのPCとユーザとをリンクさせるリンクオブジェクトを生成する。この時点では、そのリンクを有することが、リンクが期限切れになるまでユーザのコンテントをそのPCが再生することを可能にする。<0059>コントロールバーチャルマシン<0060>コントロールバーチャルマシンまたは、コントロールVMは、コンテントに対するアクセスを統治するコントロールプログラムを実行するために、DRMエンジンの好ましい実施形態によって使用されるバーチャルマシンである。コントロールVMがDRMエンジンアーキテクチャ内のどこに収まるかということの説明と、そのVMの基本要素の幾つかの説明と、メモリモデルおよび命令セットに関するさらに詳しい説明とを次に示す。<0061>好ましい実施形態では、コントロールVMは、様々なプログラミング言語を使用してインプリメントしやすいように設計されている小さなフットプリントのバーチャルマシンである。好ましい実施形態では、コントロールVMは、実行速度またはコード密度に関するそれほど大きな関心なしに、必要最小限に設計されているスタック志向の命令セットに基づいている。しかし、実行速度および/またはコード密度が特定のアプリケーションで問題である場合には、従来の技術例えば、データ圧縮が性能の改善のために使用されることが可能であるということが理解されるだろう。<0062>好ましい実施形態では、コントロールVMは、低レベルまたは高レベルのプログラミング言語のためのターゲットとして適しており、および、アセンブラ、C、および、FORTHのような言語をサポートする。Java登録商標またはカスタム言語のような他の言語のためのコンパイラも、比較的容易にインプリメントされることが可能である。<0063>好ましい実施形態では、コントロールVMは、プロセッサ上でまたはシリコン内で直接的に実行されるのではなく、ホスト環境内にホストされるように設計されている。コントロールVMのための本来のホスト環境がDRMエンジンである。図5は、本発明の好ましい実施形態において、どのようにコントロールVMがDRMエンジンと統合されるかを示す。<0064>コントロールVMはそのホスト環境の文脈の中で実行し、このホスト環境は、このVMがプログラムを実行する時にこのVMによって必要とされる機能の幾つかをインプリメントする。典型的には、コントロールVMはDRMエンジン内で実行し、このDRMエンジンはそのホスト環境を実現する。<0065>このVMは、コードモジュール内に格納された命令を実行することによって、プログラムを実行する。これらの命令の幾つかが、システムコールを行うことによってプログラム自体の外側でインプリメントされる機能を呼び出す。システムコールは、コントロールVM自体によってインプリメントされるか、または、ホスト環境に委任される。<0066>コントロールVMの好ましい実施形態の幾つかの基本要素を次で説明する。<0067>実行モデル<0068>コントロールVMは、メモリ内にロードされたバイトコードのストリームとしてコードモジュールに格納されている命令を実行する。このVMは、命令が実行されるにつれて増分されるプログラムカウンタPCと呼ばれる仮想レジスタを維持する。VMは、OP_STOP命令が発生するまで、OP_RET命令が空のコールスタックに遭遇するまで、または、例外が生じるまで、各命令を逐次的に実行する。ジャンプが、PCの現在値からのバイトオフセットとして指定される相対ジャンプとして、または、絶対アドレスとして指定される。<0069>メモリモデル<0070>好ましい実施形態では、コントロールVMは比較的単純なメモリモデルを有する。VMメモリはデータセグメントDSとコードセグメントCSとに分けられる。データセグメントは、アドレス0で開始する単一のフラットで連続したメモリ空間である。データセグメントは、典型的には、ホストアプリケーションまたはホスト環境のヒープメモリ内に割り当てられたバイトのアレイである。特定のVMインプリメンテーションの場合に、メモリ空間のサイズが最大に固定されることが好ましく、および、メモリ空間の外側のメモリにアクセスを試みることが、誤りの原因となってプログラムの実行を終了させるだろう。データセグメントは、VMによって同時にロードされる幾つかのコードモジュールの間で潜在的に共用される。データセグメント内のメモリは、32ビットアクセスまたは8ビットアクセスであることが可能なメモリアクセス命令によってアクセスされることが可能である。32ビットメモリアクセスは、ビッグエンディアン型のバイト順を使用して行われる。VM可視メモリとホスト管理メモリホストCPUの仮想または物理メモリとの間の整合に関して仮定は行われない。<0071>一実施形態では、コードセグメントは、アドレス0で開始するフラットで連続したメモリ空間である。コードセグメントは、典型的には、ホストアプリケーションまたはホスト環境のヒープメモリ内に割り当てられたバイトのアレイである。<0072>好ましい実施形態では、VMは幾つかのコードモジュールをロードしてよく、および、コードモジュールのすべてが同一のデータセグメントを共用してよい各モジュールのデータが異なったアドレスにロードされることが好ましいが、各々がそれ自体のコードセグメントを有する例えば、1つのコードモジュールからのジャンプ命令が別のコードモジュール内のコードに対する直接的なジャンプを引き起こすことが不可能であることが好ましい。<0073>データスタック<0074>好ましい実施形態では、VMが、データセグメント内に格納された32ビットデータセルを表すデータスタックの観念を有する。VMは仮想レジスタコール、スタックポインタSPを維持する。リセット後に、SPはデータセグメントの末端をポイントし、および、スタックが下方に成長するデータがデータスタック上にプッシュされる時に、SPレジスタが減分される。スタック上の32ビット値が、スタックデータを参照する命令に応じて、32ビットアドレス整数または32ビット符号付き整数に翻訳される。<0075>コールスタック<0076>好ましい実施形態では、ネストされたサブルーチン呼出しを行うために、VMがコールスタックを管理する。このスタックにプッシュされる値は、メモリアクセス命令によって直接的に読み出し/書き込みされることが不可能であるが、OP_JSRおよびOR_RET命令を実行する時にVMによって間接的に使用される。特定のVMプロファイルの場合に、この戻りアドレススタックのサイズが最大に固定されることが好ましく、このことが、超過不可能な特定の数のネストされたコールを可能にする。<0077>命令セット<0078>好ましい実施形態では、コントロールVMが非常に単純な命令セットを使用する。しかし、限定された数の命令によってさえ、依然として単純なプログラムを表現することが可能である。好ましい実施形態では、命令セットがスタックベースである。OP_PUSH命令を除いて、命令はどれも直接のオペランドを持たない。オペランドはデータスタックから読み出され、および、結果がデータスタック上にプッシュされる。好ましい実施形態では、VMは32ビットVMである。すべての命令が、メモリアドレスまたは符号付き整数を表す32ビットスタックオペランド上で動作する。符号付き整数は、2の補数バイナリ符号化を使用して表される。<0079>好ましい実施形態で使用される典型的な命令セットを次に示す。<0080>モジュールフォーマット<0081>好ましい実施形態では、コードモジュールが、MPEG-4ファイルフォーマットで使用されるAtom構造と基本的に同等であるAtomベースのフォーマットで格納される。1つのatomは、ビッグエンディアン型のバイト順の4オクテットとして格納された32ビットと、この後に続く4オクテットタイプ一般的には、アルファベット文字のASCII値に対応するオクテットと、この後に続くAtomのペイロードサイズ8オクテットとから成る。<0082>例示的なコードモジュールを図6に示し、および、次で説明する。<0083>pkCMAtom:pkCMAtomは最上位レベルのコードモジュールAtomである。これはサブアトムのシーケンスを含む。<0084>pkDSAtom:pkDSAtomは、データセグメント内にロードされることが可能なメモリイメージを含む。このAtomのペイロードはオクテット値の生シーケンスである。<0085>pkCSAtom:pkCSAtomは、コードセグメント内にロードされることが可能なメモリイメージを含む。このAtomのペイロードはオクテット値の生シーケンスである。<0086>pkEXAtom:pkEXAtomはエクスポートエントリのリストを含む。各エクスポートエントリは、8ビットのネームサイズと、これに続く終端ゼロを含む名前の文字として符号化された名前と、これに続く名前が付けられたエントリポイントのバイトオフセットこれは、pkCSAtom内に格納されているデータの先頭からのオフセットであるを表す32ビット整数とから成る。<0087>モジュールローダ<0088>好ましい実施形態では、コントロールVMはコードモジュールをロードする責務を有する。コードモジュールがロードされると、pkDSAtom内の符号化されたメモリイメージがデータセグメント内のメモリアドレスにロードされる。このアドレスはVMローダによって選択され、および、DS疑似レジスタ内に格納される。pkCSAtom内の符号化されたメモリイメージがコードセグメント内のメモリアドレスにロードされる。このアドレスはVMローダによって選択され、および、CS疑似レジスタ内に格納される。<0089>システムコール<0090>コントロールVMプログラムがそのコードモジュールのコードセグメントの外側でインプリメントされる機能を呼び出すことが可能である。これは、呼出しのためにシステムコール番号を指定する整数スタックオペランドをとるOP_CALL命令の使用によって行われる。システムコールに応じて、このインプリメンテーションが、VMのネイティブなインプリメンテーションフォーマットにおける直接的にVMによる、または、VMのホスト環境のような外部ソフトウェアモジュールに委任された、異なったコードモジュール例えば、効用関数のライブラリのコントロールVMバイトコードルーチンであることが可能である。<0091>好ましい実施形態では、次の指定される幾つかのシステムコール数がある。<0092>SYS_NOP=0:この呼出しは非操作的な呼出しである。これは単に戻すだけである他に何もしない。これは主としてVMを試験するために使用される。<0093>SYS_DEBUG_PRINT=1:テキストの文字列をデバッグ出力にプリントする。この呼出しは、プリントすべきナル終了文字列を含む記憶場所のアドレスを指定する単一のスタック引数を求める。<0094>SYS_FIND_SYSCALL_BY_NAME=2:VMが名前付きのシステムコールをインプリメントするかどうかを決定する。そうである場合には、システムコール数がスタック上に戻され、そうではない場合には、値-1が戻される。この呼出しは、要求されているナル終了システムコール名を含む記憶場所のアドレスを指定する単一のスタック引数を求める。<0095>システムコール数アロケーション<0096>好ましい実施形態では、コントロールVMが、必須システムコールVMの全プロファイルによってインプリメントされなければならないシステムコールのためにシステムコール数0-1023を予約する。<0097>システムコール数16384-32767が、VMが動的に割り当てるために利用可能である例えば、SYS_FIND_SYSCALL_BY_NAMEによって戻されるシステムコール数がVMによって動的に割り当てられることが可能であり、および、全VMインプリメンテーション上で同一の数である必要はない。<0098>標準システムコール<0099>好ましい実施形態では、幾つかの標準システムコールが、コントロールプログラムを記述することを容易にするために提供される。こうした標準システムコールは、ホストからタイムスタンプを得るための呼出し、ノードが到達可能であるかどうかを判定するための呼出し、および/または、これらの類似物を含んでもよい。システムコールが動的に決定された数を有することが好ましい例えば、そのシステムコール数が、引数として渡された名前を有するSYS_FIND_SYSCALL_BY_NAMEシステムコールを呼び出すことによって探索されることが可能である。<0100>リンク、ルール、および、コンテント暗号化<0101>DRMエンジンおよび/またはシステムの好ましい実施形態におけるプリンシパル、グループ、ルール、表明、および、鍵管理の間の関係に関する追加情報を次で提供する。<0102>リンクおよびノード<0103>上述したように、DRMシステムは、ノードとリンクとのセットを有するものとして概念化されることが可能である。ノードは異なったエンティティを表すことが可能であるが、典型的には幾つかのグループが1つだけの自己識別である自己識別のグループを表し、および、リンクによって連結されることが可能である。リンクは、ノードがリンクさせられているノードによって表されるグループにそのノードが属するという表明と見なされることが可能である。<0104>リンクは、典型的には、ポリシーの統治下におけるユーザおよび/またはDRMエンジンクリエータ以外のエンティティによって行われる表明である。この表明がどのように行われ統治されるかは、任意の適切な仕方で行われることが可能である。しかし、リンクが信用できることが好ましい。実際には、これは、一般的に、そのリンクに基づいて判断を行うことが必要なシステムの一部分が、信用できる仕方でそうすることが可能であるように、リンクが存在するという表明の表現が署名されるだろうということを意味するだろう。<0105>ノード間のリンクの存在によって含意される関係は過渡的である。リンクが、ノードのグラフ中の有向辺によって表されることが可能であり、および、そのグラフ中のノードNaとグループノードNxとの間に有向の経路が存在するならば、ノードNaはグループノードNxに属すると言い表すことが可能である。<0106>次のパラグラフは、ルール条件を表現するために、および、暗号化鍵を管理するために、これらのノードのグラフがどのように使用されることが可能であるかを説明する。<0107>ルールおよびメンバシップ条件<0108>このシステムは、特定の要求されたアクションまたは意図が許可されるか否か、および、そうである場合には、結果および/または義務が何であるかを決定するコントロールプログラムとして表現されたルールを通して、コンテントを統治するために使用されることが可能である。好ましい実施形態では、ルールは、入力として幾つかのパラメータ例えば、コンテント識別情報、時間/日付、特定のカウンタの値、アクションを要求するプリンシパルのID等をとり、かつ、特定のアクションが生じることを可能にするかどうかを判定する、小さなコントロールプログラムである。アクションが発生することが許可される場合には、このプログラムは、さらに、ルールの規定された義務例えば、カウンタの更新も行うことが可能である。特定の実施形態では、そのプログラムが取り扱うことが可能な入力と出力のタイプが比較的に制限されてよい。<0109>ルールが、アクションを行うことが可能なプリンシパルのための条件が、例えば、プリンシパルがこのコンテントのサブスクライバのグループのメンバである場合に、そのプリンシパルがこのコンテントを再生することが可能であるというようなルールを表現するために各経路毎に1つずつターゲットノードまたはターゲットノードのセットに対してアクションを要求するプリンシパルを表すノードからの経路または経路のセットの存在であるということを表現することが可能である。2つのノードNa、Nbの間のリンクが、Nbによって表されるグループにNaが属するということの信用できる表明である。このルールの執行の時点で例えば、ルールプログラムが実行中である場合に、すべての要求されたターゲットノードに対してグラフを横断するために必要なすべてのリンクを得ることが可能である場合には、その条件が満たされる。このノードのグラフは、メンバシップグラフと呼ばれることがあるだろうし、および、そのグラフのリンクがメンバシップリンクと呼ばれることがあるだろう。<0110>コンテント暗号化<0111>このシステムと共に機能するように設計されている準拠要素が、保護されたコンテント部品に対してその準拠要素がアクションを行うことを望む時に、適切なルールを理解し執行することが可能だろう。しかし、非準拠システムが、一般的に、この仕方でコンテントを使用するために信用されることが不可能である。したがって、暗号技術を使用してコンテントを保護することが望ましい。好ましい実施形態では、典型的には保護されるコンテントに固有であるコンテント鍵Kcによって、コンテントが暗号化される。プリンシパルがコンテントに対してアクションを行うことを望む時には、そのプリンシパルは最初にルールプログラムを実行し、および、yes/noの回答を得るだろう。プリンシパルがそのアクションを行うことをルールが許可する場合には、そのプリンシパルはコンテント鍵Kcを得ることを必要とするだろう。好ましい実施形態では、ルールシステムと、ノード/リンクグラフと、Kcを要求ノードに対して明示的にターゲットにする外部エンティティなしにプリンシパルが効率的な仕方でコンテント鍵を得ることを可能にするコンテント保護システムとの間に関係が存在する。<0112>好ましい実施形態では、これは、ノードのグラフとしてプリンシパル/オブジェクト間の関係を概念化することによって実現される。幾つかのノードがメンバシップグラフで使用されるノードと同じノードであってよいが、これは必ずしも必要ではない。しかし、単純なシステムでは、このグラフがメンバシップグラフのサブセットであることが求められる。このグラフは保護グラフと呼ばれるだろう。<0113>このシステムの各ノードNは、他の属性の中で特に、関連したコンテント保護鍵Kc[N]または鍵対を有することが可能である。他の属性が、署名を行うための、および、ノードに対して情報を潜在的にターゲットするための公開/プライベート鍵対を含んでもよい。例示のために、次の例が単一の鍵の使用を示すが、しかし、同一の原理が鍵対に関しても有効であるということを理解されたい。このグラフでは、2つのノードNa、Nbの間のリンクが、Kc[Na]を有する者は誰でもKc[Nb]を計算することが可能であるという信用できる表明である。典型的には、このことは、そのリンクが、Kc[Na]によって暗号化されたKc[Nb]の表現を含むだろうということを意味する。このことは、ノード間のリンクを連鎖させることと、ターゲットノードのKcを計算することとを可能にする。<0114>鍵に対する経路を生成するために使用されるグラフが、メンバシップ条件を表現するために使用されるグラフとは違っていてもよいが、単純な例では、同じグラフとリンクとが再使用されることが可能であり、したがって、ノードグラフの並列のまたは別の使用を生じさせる。この場合には、ルールの条件を検査するために横断させられた同一の経路が、コンテント保護鍵を計算するために横断させられる。Naに対するKc[Nb]の明示的なターゲティングがこれまでに行われていない場合にさえ、ノードNbに到達するために辿られることが可能なリンクに対するアクセス権を有するあらゆるノードNaが、Kc[Nb]を計算することが可能である。<0115>これらの鍵は、典型的に、次の仕方で使用されるだろう。コンテントCiはコンテント鍵K[Ci]で暗号化される。1つまたは複数のルールが生成されることが可能であり、このルールは、特に、アクションを要求するノードと、グループを表す条件ターゲットノードのリストとの間の経路の存在を検査する。この1つまたは複数のルールは、条件および、恐らくは、さらに義務の副作用の検査を行うプログラムと、要求ノードが属さなければならないノードのKc[Ni]ノードコンテント暗号化鍵の各々を使用した連続的な暗号化によって保護されたK[Ci]のコピーとを含んでよい。<0116>ノードNaがコンテントCiに対するアクションを行うことを望む時には、このノードNaは、そのアクションのためにそのコンテントを統治するルールプログラムを実行するだろう。このルールが、1つまたは複数のグループNp、Nq等におけるNaのメンバシップを要求する場合には、このルールは、Np、Nq等に対する必要なリンクが存在することを検査し、および、アクションが許可されるか否かに関する判定を生じさせるだろう。そのアクションが許可される場合には、システムが、ルール中でそのコンテント鍵の暗号化されたコピーが発見されることが可能であるコンテント鍵K[Ci]を得るために逐次的に使用される必要があるコンテント保護鍵Kc[Nm]、Kc[Nn]等を有するノードNm、Nn等に対する、保護グラフにおける1組のリンクを、そのシステムが有するかどうかを判定するだろう。K[Ci]は、コンテント鍵のための保護メタデータによって指定された順序で、ノードのコンテント暗号化鍵Kc[Nm]、Kc[Nn]等によって、この暗号化されたコンテント鍵を暗号解読することによって得られるだろう。この場合も同様に、単純なシステムでは、ノードNp、Nq等のセットがNm、Nn等と同じであることが多いだろう。<0117>図7は、ノードグラフの二重の使用を示す例示的なシナリオを図示する。図7を参照すると、iPod1がコンテント再生デバイスである。Nip1がこのデバイスを表すノードである。Kip1がNip1に関連付けられているコンテント暗号化鍵である。ジルGillesがiPod1の所有者であり、Ngがジルを表すノードである。KgがNgに関連付けられているコンテント暗号化鍵である。<0118>PubLibが公立図書館である。Nplがこの図書館のメンバを表し、および、Kp1がNplに関連付けられているコンテント暗号化鍵である。ACMEがすべてのACME製造のミュージックプレイヤを表す。Nampがデバイスのクラスを表し、および、Kampがこのグループに関連付けられているコンテント暗号化鍵を表す。<0119>L1がNip1からNgへのリンクであり、このことはiPod1がジルに属していることを意味する。L2がNgからNplへのリンクであり、このことがジルが公立図書館のメンバであることを意味する。L3がNip1からNampへのリンクであり、このことがiPod1がACMEデバイスであることを意味する。<0120>C1が、公立図書館がそのメンバに対して利用可能にする映画ファイルである。Kc1が、C1を暗号化するために使用される鍵である。GB[C1]がC1に関する統治情報例えば、コンテントに対するアクセス権を統治するために使用されるルールと関連情報である。Ea,bが、鍵aによって暗号化されたbを意味する。<0121>例示のために、aそのデバイスが図書館のメンバである誰かに属し、かつ、bそのデバイスがACMEによって製造されている限り、そのデバイスがコンテントC1を再生することが可能であるということを述べるルールを設定することが望ましいと仮定する。<0122>コンテントC1がKclによって暗号化される。ルールプログラムが生成され、および、暗号化されたコンテント鍵RK[C1]=EKamp,EKpl,Kclが生成される。ルールプログラムとRK[C1]の両方が、コンテントGB[C1]のための統治ブロックに含まれることが可能である。<0123>iPod1はC1とGB[C1]とを受け取る。例えば、この両方が同一のファイルの形でパッケージされてもよく、または、別々に受け取られてもよい。ジルが自分のデバイスを購入した後で最初にそのデバイスをインストールした時に、iPod1はL1を受け取った。ジルが自分のサブスクリプション料金を公立図書館に支払った時に、iPod1はL2を受け取った。iPod1は、それが製造された時にL3を受け取った例えば、L3が組み込み済みだった。<0124>L1、L2、および、L3から、iPod1は、Nip1がNgL1とNplL1L2とNampL3とに対するグラフ経路graphpathを有することを検査することが可能である。iPod1はC1を再生することを望む。iPod1は、GB[C1]で発見されたルールを実行する。このルールは、Nip1が実際にACMEデバイスでありNampへの経路、かつ、公立図書館のメンバに属するNplへの経路ということを検査することが可能である。したがって、このルールは、yesと、順序付けられたリストNamp,Nplとを戻す。<0125>iPod1は、Kgを計算するためにL1を使用し、その次に、KgからKplを計算するためにL2を使用する。さらに、iPod1は、Kampを計算するためにL3を使用する。iPod1は、KplとKampを、GB[C1]で発見されたRK[C1]に適用し、および、Kc1を計算する。その次に、iPod1は、C1を暗号解読して再生するためにKc1を使用する。<0126>上述の実施形態と同様にノード鍵が対称鍵である場合には、コンテントパッケージャが、それがコンテントをバインドしようと望むノードの鍵に対してアクセス権を有することが必要である。これは、パッケージャを表すノードと、そのノードとそのパッケージャがルールをそのノードに対してバインドしようと望むノードとの間のリンクとを生成することによって実現されることが可能である。これは、さらに、例えば、サービスによってアウトオブバンドoutofbandで実現されることも可能である。しかし、状況によっては、対称鍵を使用することが可能ではなく、または、実際的ではないことがある。その場合には、共用された知識なしに、そのノードとのバインディングが必要とされるノードに対して鍵対を割り当てることが可能である。その場合には、パッケージャは、ターゲットノードの公開鍵によってコンテント鍵を暗号化することによって、コンテント鍵をノードにバインドするだろう。暗号解読のための鍵を得るために、クライアントが、そのノードに対するリンクによってそのノードのプライベート鍵に対するアクセス権を有するだろう。<0127>最も一般的な場合には、ルールのために使用されるノードと、コンテント暗号化鍵を計算するために使用されるノードとが、必ずしも同一である必要はない。コンテントを統治するルールとコンテントを暗号化するために使用される鍵との間に強力な関係が存在するので、同一のノードを使用することが自然であるが、このことは必ずしも必要であるわけではない。特定のシステムでは、幾つかのノードが、メンバシップ条件を表現するために使用されないコンテント保護鍵のために使用されてよく、および、これとは逆であってよく、および、状況によっては、1つのグラフがルールに関するものであり、かつ、1つのグラフがコンテント保護に関するものである、2つの互いに異なった2つのノードグラフが使用されることが可能である。例えば、ルールが、グループNplの全メンバがコンテントC1に対するアクセス権を有することが可能であるが、コンテント鍵Kc1がKplによって保護されなくてもよいが、その代わりに、Np1だけでなく、すべての公共図書館を表すノードNfのノード鍵Kfによって保護されてもよいと命じることが可能である。または、ルールが、あなたがNampのメンバである必要があるが、コンテント暗号化鍵がNp1だけにバインドされることが可能であると命じることが可能である。<0128>理解しやすいように、上述の内容をある程度詳細に説明してきたが、本発明の原理から逸脱することなしに特定の変更と変型とを加えてよいということが明らかだろう。本発明のプロセスと機器の両方を実現する数多くの代案の方法が存在するということに留意されたい。したがって、これらの実施形態は例示的でかつ非限定的であると見なされるべきであり、および、本発明はここで示されている特定の詳細事項に限定されない。<付記C>"