(57)【要約】【課題】  エンドトゥエンド制御を維持しながら、また、多くの複雑さを導入することなく、本システムを通じて、コンテンツのセキュアな転送を実現する解決法を提供すること。【解決手段】  ネットワークに相互に接続された複数のデバイスを有する コンディショナルアクセスシステムであって、前記デバイスが、第1のグループと第2のグループとにグループ化され、前記第1のグループの前記デバイスが、第1のセキュリティフレームワークにしたがって作動し、前記第2のグループの前記デバイスが、第2のセキュリティフレームワークにしたがって作動するシステムにおいて、各デバイスが、特定のミドルウェア層を用いて作動し、当該ミドルウェア層が、他のデバイスの他のミドルウェア層を認証するように配置され、当該ミドルウェア層が、前記デバイスがそれにしたがって作動している前記セキュリティフレームワークによって認証される、システム。
2005527011.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに相互に接続された複数のデバイスを有するコンディショナルアクセスシステムであって、前記デバイスが、第1のグループと第2のグループとにグループ化され、前記第1のグループの前記デバイスが、第1のセキュリティフレームワークにしたがって作動し、前記第2のグループの前記デバイスが、第2のセキュリティフレームワークにしたがって作動するシステムにおいて、各デバイスが、特定のミドルウェア層を用いて作動し、当該ミドルウェア層が、他のデバイスの他のミドルウェア層を認証するように配置され、当該ミドルウェア層が、前記デバイスがそれにしたがって作動している前記セキュリティフレームワークによって認証される、システム。
【請求項２】
前記第1のグループからのデバイスが、前記第2のグループからのデバイスのミドルウェア層にリモートプロシージャコール(remote procedure call: RPC）を行うことによって、前記第2のセキュリティフレームワークのファンクションを実行することができる、請求項1に記載のシステム。
【請求項３】
前記RPCが、セキュア認証済チャンネル(secure authenticated channel: SAC）を通じて、前記第2のグループからのデバイスに伝送される、請求項2に記載のシステム。
【請求項４】
前記デバイスが、目的の特定のクラスにしたがってコンテンツにアクセスする許可を与えられる請求項1に記載のシステムであって、1セットのそのようなクラスが、定められており、各クラスが、いくつかのコンディショナルアクセス操作または目的を有するシステム。
【請求項５】
前記セットからの第1のクラスが、操作：レンダ、移動、および、コピーを有する、請求項4に記載のシステム。
【請求項６】
前記セットからの第2のクラスが、操作：記憶、レンダ、編集、削除、および、処理を有する、請求項5に記載のシステム。
【請求項７】
前記処理操作が、前記コンテンツに連係した権利に対するどんな制限にも無関係に認可される、請求項6に記載のシステム。
【請求項８】
デバイスが、1つのコンテンツにコンディショナルにアクセスすることを可能にする方法であって、前記デバイスが、目的の特定のクラスにしたがってコンテンツにアクセスする許可を与えられている方法において、1セットのそのようなクラスが、定められており、各クラスが、いくつかのコンディショナルアクセス操作または目的を有する方法。
【請求項９】
前記セットからの第1のクラスが、操作：記憶、レンダ、編集、削除、および、処理を有する、請求項8に記載のシステム。
【請求項１０】
前記処理操作が、前記コンテンツに連係した権利に対するどんな制限にも無関係に認可される、請求項9に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
ネットワークに相互に接続された複数のデバイスを有するコンディショナルアクセスシステムに関するものである。
【背景技術】
【０００２】
通常のデジタルホームネットワークは、多くのデバイス、例えば、ラジオ受信機、チューナ／デコーダ、CDプレーヤ、スピーカ対、テレビジョン、VCR、テープデッキなどを含んでいる。これらのデバイスは、一般に、1つのデバイス、例えば、テレビジョンが、他のデバイス、例えば、VCRを制御することを可能にするように相互に接続される。例えば、チューナ／デコーダまたはセットトップボックス(STB)のような、1つのデバイスが、一般に、他のデバイスに対する中央制御を備えた中央デバイスである。制御ボタンおよびスイッチが、一般に、ハンドヘルドリモートコントロールユニット上だけではなく、チューナの前面にも置かれる。ユーザは、中央デバイスまたはリモートコントロールユニットを用いて全てのデバイスを制御することができる。
【０００３】
これらのデバイスが、より多用途となり、より複雑になるにつれて、単純なマニュアル制御では、もはや十分でなくなっている。さらに、ますます多くのデバイスが、利用可能になるとともに、相互運用性（相互接続性）が、問題になり始めている。多くのベンダが、自分自身の通信プロトコルを用いて、自分のデバイスをインタラクトさせているが、異なるベンダからのデバイスは、インタラクトすることができない。これらの問題を克服するために、いくつかの相互運用性標準（規格）が、定められ、それらは、いろいろのデバイスが、互いにメッセージおよび情報を交換し合い、そして、制御し合うことを可能にしている。よく知られた1つの標準は、Home Audio/Video Interoperability (HAVi)標準である。そのバージョン1.0は、2000年1月に公表されており、インターネット上でアドレスhttp://www.havi.org/で入手できる。よく知られた他の標準は、domestic digital bus (D2B)標準、IEC 1030に記述されている通信プロトコル、および、Universal Plug and Play (http://www.upnp.org)である。
【０００４】
そのような標準にしたがうシステムにおいては、デバイスは、標準バス、例えば、IEEE 1394シリアル通信バス、を用いたネットワーク内で相互に接続して、その標準にしたがって、このネットワーク上でメッセージ、データ、および、コマンドのような情報を交換する。HAViのような標準は、そのような交換のためのプロトコルを定めており、いろいろのベンダからのデバイスが、インタラクトすることを可能にする。ユーザは、ネットワークに新しいデバイスを加えることができ、そして、それらは、直ちに他のデバイスに利用可能になる。そのような新しいデバイスを「発見する」ためのプロトコルも、標準化されている。
【０００５】
家庭内デジタルネットワーク(IHDN)内のデバイスのいくつかは、外部接続を持つであろう。この接続を用いると、コンテンツを、ブロードバンド伝送を用いて、または、インターネットからダウンロードすることによって、ネットワークに入ることができる。さらに、デジタル多用途ディスク(DVD)またはハードディスクのような記憶メディアからコンテンツを読み出すことによって、そのコンテンツをネットワークに入れることができる。
【０００６】
本ドキュメントに提示される解決法が取り組む課題は、エンドトゥエンド制御を維持しながら、また、多くの複雑さを導入することなく、いかにして、本システムを通じて、コンテンツのセキュアな転送を実現するかということである。
【発明の開示】
【課題を解決するための手段】
【０００７】
本発明の第1の観点によれば、ネットワークに相互に接続された複数のデバイスを有するコンディショナルアクセスシステムであって、前記デバイスが、第1のグループと第2のグループとにグループ化され、前記第1のグループの前記デバイスが、第1のセキュリティフレームワークにしたがって作動し、前記第2のグループの前記デバイスが、第2のセキュリティフレームワークにしたがって作動するシステムにおいて、各デバイスが、特定のミドルウェア層を用いて作動し、当該ミドルウェア層が、他のデバイスの他のミドルウェア層を認証するように配置され、当該ミドルウェア層が、前記デバイスがそれにしたがって作動している前記セキュリティフレームワークによって認証される、システムが、提供される。
【０００８】
ネットワーク中のデバイスは全て、セキュリティフレームワークを実装している。このフレームワークを用いて、これらのデバイスは、互いに認証し合って、セキュアにコンテンツを配給することができ、そして、コンテンツへのアクセスが、セキュリティシステムによって管理される。これは、保護されていないコンテンツが、認可されていないデバイスに「流出する」ことを防止する。これが働くためには、デバイスは、互いの、および、自分自身のミドルウェア層、および、他のデバイスのセキュリティフレームワークを信頼することができなければならない。本発明は、セキュリティフレームワークが、システム中の各ミドルウェア層を認証しなければならなくなること、および、種々のミドルウェア層の全てにおいて、全ての種類のミドルウェア細目をサポートしなければならなくなることを防止する。
【０００９】
一実施例において、前記第1のグループからのデバイスが、前記第2のグループからのデバイスのミドルウェア層にremote procedure call（RPC：リモートプロシージャコール）を行うことによって、前記第2のセキュリティフレームワークのファンクションを実行することができる。この実施例は、セキュリティフレームワークが、互いを探し出して、通信することを可能にし、そして、HN-MWおよびネットワーク技術に依存しない。
【００１０】
さらなる一実施例において、前記RPCが、secure authenticated channel（SAC：セキュア認証済チャンネル）を通じて、前記第2のグループからのデバイスに伝送される。これは、互いに通信したいと望んでいるセキュリティフレームワークが、セキュアに通信することを可能にする。いくつかのセキュリティデバイスが、1つのネットワーク中に存在する場合には、それらの間のSACのセットを、virtual private network（VPN：仮想私設網）と見なすことができる。
【００１１】
さらなる一実施例において、前記デバイスが、目的の特定のクラスにしたがってコンテンツにアクセスする許可を与えられ、1セットのそのようなクラスが、定められており、各クラスが、いくつかのコンディショナルアクセス操作または目的を有する。ミドルウェアは、そのクラスの範囲内で、このコンテンツアクセスのコンテンツを扱う。
【００１２】
前記セットからの第1のクラスが、操作：レンダ、移動、および、コピーを有することが好ましい。さらに、前記セットからの第2のクラスが、操作：記憶、レンダ、編集、削除、および、処理を有することが好ましい。さらなる一実施例において、前記処理操作が、前記コンテンツに連係した権利に対するどんな制限にも無関係に認可されるのが好ましい。その処理操作は、保護されているコンテンツへのネットワークアクセス中のコンプライアントデバイスが、権利を変更せずに、そのコンテンツ上の権利を変更しない操作を実行することを可能にする。そのような操作の例は、トリックプレー、画質改善をサポートするのに必要とされるプロセシングである、コンテンツトランスコーディングおよびビットレートトランスコーディングである。
【００１３】
本発明の第2の観点によれば、デバイスが、1つのコンテンツにコンディショナルにアクセスすることを可能にする方法であって、前記デバイスが、目的の特定のクラスにしたがってコンテンツにアクセスする許可を与えられている方法において、1セットのそのようなクラスが、定められており、各クラスが、いくつかのコンディショナルアクセス操作または目的を有する方法が、提供される。
【００１４】
一実施例において、前記セットからの第1のクラスが、操作：記憶、レンダ、編集、削除、および、処理を有する。さらなる一実施例において、前記処理操作が、前記コンテンツに連係した権利に対するどんな制限にも無関係に認可される。
【発明を実施するための最良の形態】
【００１５】
本発明のこれらの、そして、他の観点が、図面に示されている、実例となる実施例から明白になり、また、それを参照して解明される。
【００１６】
図を通して、同じ参照番号は、同等の、または、対応するフィーチャを指示する。図面に指示されるフィーチャのいくつかは、通常、ソフトウェアで実装され、それ自体、ソフトウェアモジュールまたはオブジェクトのようなソフトウェアエンティティ（ソフトウェア実体）を表わしている。
【００１７】
家庭内ネットワークアーキテクチャ
図1は、ソース、シンク、および、2つの記憶メディアS1, S2を有する、本発明による家庭内ネットワークの好適な一レイアウトを線図的に例証している。そのネットワークは、概念的に、コンディショナルアクセス(CA)ドメインとコピー保護(CP)ドメインとに分割される。
【００１８】
通常、音楽、歌、映画、TV番組、画像等を有するほとんどのコンテンツは、家庭内ネットワークのCAドメインに入る。ソースは、恐らく、ブロードバンドケーブルネットワーク、インターネット接続、衛星ダウンリンクなどへの接続である。このようにして受信されたコンテンツは、記憶メディアS1に記憶することができ、その結果、それは、後で、読み出して、シンク上でレンダリングすることができる。記憶メディアS1は、恐らく、ある種のパーソナルデジタルレコーダ(PDR)、例えば、DVD+RWレコーダである。ソースも、DVDディスクが挿入されているDVDプレーヤであってもよく、そうすると、そのディスクからコンテンツを読み出すことができる。
【００１９】
コンテンツアイテムがレンダリングされる厳密な態様は、シンクのタイプおよびコンテンツのタイプに依存する。例えば、ラジオ受信機では、レンダリングは、オーディオ信号の生成、および、それらのスピーカへの供給を有している。テレビジョン受像機では、レンダリングは、オーディオ信号およびビデオ信号の生成、および、それらのディスプレイスクリーンおよびスピーカへの供給を有している。他のタイプのコンテンツでも、同様の適合した動作をとらなければならない。レンダリングは、さらに、受信した信号の解読またはデスクランブリング、オーディオ信号とビデオ信号との同期化などの操作を含んでいてもよい。
【００２０】
シンクは、例えば、テレビジョンシステムまたはオーディオ再生デバイスであってもよい。通常、シンクは、CPドメインに置かれる。これによって、コンテンツがシンクに供給されたとき、CPドメインに適所に置かれたコピー保護体系のために、認可されていないコンテンツのコピーを作ることが全くできない。CPドメインは、コンテンツの（一時）コピーを、コピー保護ルールにしたがって記憶することのできる記憶メディアS2を有している。
【００２１】
セキュリティフレームワークを実装する家庭内ネットワーク内のデバイスは全て、その実装要件にしたがって実装されている。このフレームワークを用いて、これらのデバイスが、互いに認証し合って、コンテンツをセキュアに配給することができ、それゆえ、コンテンツへのアクセスが、そのセキュリティシステムによって管理される。これは、保護されていないコンテンツが、認可されていないデバイスに「流出する」ことを防止する。
【００２２】
セキュリティフレームワーク
Rights Management & Protection (RMP：著作権管理および保護)の好適な一セキュリティフレームワークの基本的な構造が、図2に例証されている。このセキュリティフレームワークは、TV Anytime Call For Contributions（CFC：投稿への呼びかけ）に定められている（TV Anytimeのウェブサイト http://www.tv-anytime.org/cfcs/ 参照のこと）。図2において、以下の要素が、記述されている。
−  アプリケーションAPI：アプリケーションが、相互運用可能な態様で、RMPシステム      と通信することを可能にする。
−  アプリケーション：RMP要件にしたがって、コンテンツおよびPDR作品へのユーザ
アクセスを可能にするソフトウェアおよび／またはサービス。
−  ベースラインRMPシステム：TV Anytime RMPベースライン仕様に準拠する機能。
−  専有RMPシステム (proprietary RMP system)：RMPサービスAPIを通してTVA RMP
ベースラインシステムとインターフェイスで接続する専有コンテンツ保護システム。
−  RMP情報マネージャ：どんな種類の動作がコンテンツに許されるか（例えば、プレー、
コピー、移動など）を決定する、そして、セキュリティツールに暗号キーを渡しても
よい。
−  RMPサービスAPI：RMPシステムが、相互運用可能な態様で、RMPベースライン
セキュリティファンクションと通信することを可能にする。
−  RMPシステムファンクション層：ベースラインシステムを実装するファンクション
を収集。
−  RMPシステムマネージャ：ベースラインシステムの操作を管理する。
−  セキュリティツール：恐らく、デスクランブラ、電子透かし検出器／埋め込み器、
署名検証器などが含まれる。
−  TVAベースラインRMPシステムに対する標準化されたエンハンスメント：TVA 
RMPベースラインシステムに対する、任意選択のTVAの標準化された拡張。
−  TVAF RMPベースラインデバイスインターフェイス：TVAコンプライアント
デバイス間のセキュア通信層
【００２３】
本ドキュメントは、以下のシステムエレメントに対する解を提供する。
−  アプリケーションAPI
−  RMPサービスAPI
−  デバイス間通信
【００２４】
アプリケーションAPI
サードパーティからのソフトウェアを展開しなければならないときに、標準化されたAPIが、必要となる。したがって、標準化されたアプリケーションAPIは、この要求を持つプラットフォームでしか必要とされない。そのようなプラットフォームの例は、ダウンロードされたアプリケーションをサポートするプラットフォームである。そのようなデバイスでしか、アプリケーションAPIは、必要とされない。
【００２５】
DAVIC CA-API（DAVIC(Digital Audio-Visual Council)、1998年、DAVIC 1.4仕様、http://ww.davic.org/）が、アプリケーションAPIとして提案されている。DAVIC CA APIは、アプリケーションから保護されたコンテンツを用いるために必要とされる機能の大多数に取り組んでいる。しかしながら、いくつかの拡張が、記憶装置およびネットワークに関連する問題に取り組むために必要となるようである。
【００２６】
RMPサービスAPI
RMPサービスAPIは、RMPシステムが、相互運用可能な態様で、RMPベースラインセキュリティファンクションと通信することを可能にする。RMPサービスAPIは、本セクションで与えるように、OPIMAからのメソッドの部分集合から成る。以降のセクションにおいて、RMP APIに対するOPIMAメソッドが、機能に応じてグループ化される。OPIMAについては、参照によって本明細書に組み込まれるOPIMA (Open Platform Initiative for Multimedia Access)、仕様バージョン1.1、2000年 (http://www.cselt.it/opima/)を参照されたい。
【００２７】
コンテンツへのアクセス
この部分は、OPIMA標準のセクション3.3.4.7, 'Abstract Access to Content：コンテンツへのアクセスを抜粋する'インターフェイスのインターフェイス定義を反映する。このインターフェイスを介して、アプリケーションは、コンテンツに対して望みの動作を指示することができる。
【００２８】
OPIMAにおいて、RMPが、コンテンツへのアクセスがもはや許可されないことを決定したときに（例えば、コンテンツルールが、アクセス権の変更を転送したために）、そのRMPシステムは、コンテンツの中止動作への制御をほとんど持っていない。RMPシステムにとって利用可能な唯一のメカニズムは、OPIMAバーチャルマシン(OVM)に間違った解読キーを送ることである。この動作が、システムのクラッシュに帰するかどうかは、そのOVMの実装に依存する。コンテンツアクセスの、より優美なシャットダウンが、追加メソッドとして必要である。
【００２９】
以下のメソッドが、コンテンツへのアクセスのために使用される。
−  installCallbackContentAccess：コールバックコンテンツアクセスをインストールする
−  abstractContentAccess：コンテンツアクセスを抜粋する
−  replyToContentAccess：コンテンツアクセスに応答する
【００３０】
オプションとして、以下の追加メソッドを用いることができる。
−  stopContent(ContentId)：コンテンツ（コンテンツId）を停止する
【００３１】
ルール／キーへのアクセス
この部分は、OPIMA標準のセクション3.3.4.8, 'Abstract Access to Rules：ルールへのアクセスを抜粋する'インターフェイスのインターフェイス定義を反映する。このインターフェイスを介して、RMPシステムは、それが、どのルール／権利データを受信したいと望んでいるかを指示することができる。
【００３２】
以下のメソッドが、ユーザインタラクションのために使用される。
−  obtainUserRules：ユーザルールを得る
−  obtainContentRules：コンテンツルールを得る
−  newRules：新しいルール
−  updateContentRules：コンテンツルールを更新する
【００３３】
オプションとして、以下の追加メソッドを用いることができる。
−  addContentRules：コンテンツルールを追加する
【００３４】
スマートカード
この部分は、OPIMA標準のセクション3.3.4.6, 'Smart Cards：スマートカード'インターフェイスのインターフェイス定義を反映する。RMPシステムは、本システムを介してスマートカードにアクセスして、標準のISO 7816 APDUを送信／受信することができる。
【００３５】
以下のメソッドが、スマートカードインタラクションのために使用される。
−  addCTListener：CT(Card Terminal)リスナを加える
−  removeCTListener：CTリスナを取り除く
−  cardInserted：カードが挿入されている
−  cardRemoved：カードが取り除かれている
−  getSlotId：スロットIdを得る
−  isCardPresent：カードが存在するか
−  openSlotChannel：スロットチャンネルを開ける
−  closeSlotChannel：スロットチャンネルを閉じる
−  getATR：ATR (answer-to-reset)を得る
−  reset：リセットする
−  sendAPDU：APDU (Application-layer Protocol Data Unit)を送信する
【００３６】
暗号化および解読
この部分は、OPIMA標準のセクション3.3.4.3, 'Encryption and Decryption Engines：暗号化および解読エンジン'インターフェイスのインターフェイス定義を反映する。RMPシステムは、このインターフェイスを介して、コンテンツ暗号と、種々雑多なデータに対する暗号動作との両方を制御することができる。
【００３７】
以下のメソッドが、暗号化および解読のために用いられる。
−  queryEncryptionAlgorithms：暗号化アルゴリズムを照会する
−  encrypt：暗号化する
−  initEncryption：暗号化をイニシャライズする
−  updateEncryptionKeys：暗号化キーを更新する
−  stopEncryption：暗号化を停止する
−  decrypt：解読する
−  initDecryption：解読をイニシャライズする
−  updateDecryptionKeys：解読キーを更新する
−  stopDecryption：解読を停止する
【００３８】
署名
この部分は、OPIMA標準のセクション3.3.4.4, 'Signature Engines（署名エンジン）'インターフェイスのインターフェイス定義を反映する。このインターフェイスを介して、RMPシステムは、コンテンツ上の署名と、種々雑多なデータ上の署名との両方をチェックし、また、生成することができる。
【００３９】
以下のメソッドが、署名のために用いられる。
−  querySignatureAlgorithms：署名アルゴリズムを照会する
−  verifySignature：署名を確認する
−  verifyContentSignature：コンテンツ署名を確認する
−  generateSignature：署名を生成する
−  generateContentSignature：コンテンツ署名を生成する
【００４０】
電子透かし
この部分は、OPIMA標準のセクション3.3.4.5, "Watermark Engine（電子透かしエンジン）"インターフェイスのインターフェイス定義を反映する。このインターフェイスを介して、RMPシステムは、コンテンツ中の電子透かしを検出し、また、埋め込むことができる。
【００４１】
以下のメソッドが、電子透かしのために使用される。
−  queryWatermarkAlgorithms：電子透かしアルゴリズムを照会する
−  extractWatermark：電子透かしを抽出する
−  stopWatermarkExtraction：電子透かし抽出を中止する
−  insertWatermark：電子透かしを挿入する
−  stopWatermarkInsertion：電子透かし挿入を停止する
【００４２】
RMPへのアクセス
この部分は、OPIMA標準のセクション3.3.4.9, 'Abstract Access to OPIMA Peers（OPIMAピアへのアクセスを抜粋する）'インターフェイスのインターフェイス定義を反映する。このインターフェイスを介して、ベースラインシステムが、互いにインタラクトすることができる。
【００４３】
以下のメソッドが、RMPシステム間のインタラクションのために使用される。
−  openConnection：接続を開く
−  closeConnection：接続を閉じる
−  addConnectionListener：接続リスナを加える
−  sendMessage：メッセージを送信する
−  newConnection：新しい接続
−  receiveMessageFromPeer：ピアからメッセージを受信する
【００４４】
ユーザインタラクション
この部分は、OPIMA標準のセクション3.3.4.1, ' User Interface（ユーザインターフェイス）'のインターフェイス定義を反映する。このインターフェイスを介して、ユーザは、RMPシステムと情報を交換することができる。
【００４５】
以下のメソッドが、ユーザインタラクションのために用いられる。
−  sendMessageToUser：ユーザにメッセージを送信する
−  receiveMessageFromUser：ユーザからメッセージを受信する
【００４６】
receiveMessageFromUserメソッドは、RMPシステムとユーザとの間の文字ストリングの転送しか考慮されていない。RMPシステムは、情報のフォーマッティングおよび提示に対する制御を全く持たない。receiveMessageFromUserメソッドにそのようなフォーマッティングをサポートするために、MessageText（メッセージテキスト）値（単数または複数）が、CENELEC EN 50221（欧州電気標準化委員会の欧州規格50221）：1997年、Common Interface for Conditional Access and other Digital Video Decoder Applications（コンディショナルアクセスおよび他のデジタルビデオデコーダ応用のための共通インターフェイス）、および、CENELEC R 206-001（欧州電気標準化委員会の推薦規格206-001）：1997年、Guidelines for the Implementation and Use of the Common Interface for DVB 15 Decoder Applications（DVB 15デコーダ応用のための共通インターフェイスの実装および使用に対するガイドライン）、に標準化されているような共通インターフェイスハイレベルMMIメッセージにしたがう。
【００４７】
アプリケーションインタラクション
この部分は、OPIMA標準のセクション3.3.4.10, 'Abstract Access to Applications（アプリケーションへのアクセスを抜粋する）'のインターフェイス定義を反映する。このインターフェイスは、アプリケーションとRMPシステムとの間の透過ビットチャンネルを定義している。
【００４８】
DVBフレームワークでは、複数のアプリケーションおよび複数のRMPシステムが、存在できる。したがって、このインターフェイスは、ある基本的な機能に対するアプリケーションとRMPシステムとの間の相互運用性を可能にするいくつかの特定のメソッドでエンハンスされる。
【００４９】
以下のメソッドが、アプリケーションインタラクションのために用いられる。
−  installCallbackApplication：コールバックアプリケーションをインストールする
−  replyMessage：メッセージに応答する
−  receiveMessageFromApplication：アプリケーションからメッセージを受信する
【００５０】
以下の拡張が、任意選択である。
receiveMessageFromApplicationメソッドが、追加メッセージタイプ'QUERY_ENTITLEMENT：照会_エンタイトルメント'を含む。このメッセージタイプに対する応答として、RMPシステムが、規格の'replyMessage'を介して、現在のユーザに利用可能なエンタイトルメントのリストを返す。
【００５１】
ライフサイクル制御
この部分は、OPIMA標準のセクション3.3.4.11, 'Life-cycle Control（ライフサイクル制御）'インターフェイスのインターフェイス定義を反映する。
【００５２】
以下のメソッドが、ライフサイクル制御のために使用される。
−  initialize：初期化する
−  terminate：終結する
−  update：更新する
−  remove：取り除く
【００５３】
TVAF RMPベースラインデバイスインターフェイス
デバイスインターフェイスは、TVAコンプライアントデバイス間にセキュアな通信層を備えていなければならない。このインターフェイスに関連するエレメントには、ホームネットワーキングミドルウェア（例えば、UPnP, HAVi, Jini）のような他のシステムエレメントに対するセキュリティフレームワークの関係が含まれる。さらに、コンプライアントデバイスの認証、および、これらのデバイス間のセキュアな通信は、ベースラインデバイスインターフェイスによって取り組まれる。そのデバイスインターフェイスを、ホームネットワークへのOPIMAの拡張として定めた。
【００５４】
ベースラインRMPシステム
ベースラインRMPシステムは、TVAシステムに、標準化されたコピー保護システムを供給する。それが、そのフレームワークを実装している各デバイスにおいて標準化され、そして、必須のものであるから、ベースラインRMPシステムを実装しているどんなデバイスも、このRMPシステムによって保護されているコンテンツにアクセスすることができる。さらに、このベースラインシステムが、単純かつ容易に実装されるということが、非常に重要である。このベースラインシステムは、小さく安価な移動デバイスもサポートしなければならないので、これは、最も重要である。
【００５５】
このベースラインRMPシステムは、どのようなRMPシステムとも同じように、2つの部分：キー管理およびコンテンツ暗号化から成る。次のセクションで説明されるシステムを用いると、これは、ベースラインコンテンツ暗号化体系を用いて、エンドトゥエンド制御を遂行する専有RMPシステムを可能にする。ベースラインRMPシステムは提案されていないが、提案されるどのRMPシステムも、OPIMA RMPサービスAPIと互換性を持たなければならない。
【００５６】
単純なベースラインシステムは、少なくともコンテンツルール：copy_free, copy_one_generation, copy_no_more（コピー_自由、コピー_1回_生成、コピー_もはや_なし）をサポートしなければならない。このベースラインRMPシステムは、各コンプライアントデバイスに存在することになるであろうから、コンテンツ暗号化アルゴリズムは、安価で、容易に入手可能で、ロバストでなければならない。AESは、これらの要件を全て満たすから、ベースラインコンテンツ暗号化体系として、Advanced Encryption Standard （AES：次世代暗号化標準)を用いるのが好適である。
【００５７】
ベースラインデバイスインターフェイス
前セクションでは、OPIMAシステムが導入された。OPIMAは、アプリケーションおよびDigital Rights Management（DRM：デジタル著作権管理）システムのためのセキュリティフレームワークを備えており、相互運用性を持つ。本セクションでは、OPIMAシステムが、ホームネットワーク内で作動するように拡張される。ホームネットワークにおけるDRMの使用の概論に関しては、F.L.A.J. Kamperman, S.A.F.A. van den Heuvel, M.H. Verberkt, Digital Rights Management in Home Networks（ホームネットワークにおけるデジタル著作権管理）、Philips Research、オランダ、 IBC 2001 conference publication 第1巻、70-77ページを参照されたい。
【００５８】
ホームネットワークは、ある種類のネットワーク技術（例えば、イーサネット、IEEE 1394、ブルートゥース、802.11b、…）を用いて相互に接続する1セットのデバイスとして定義することができる。ネットワーク技術は、種々のデバイスが通信することを可能にするが、これは、デバイスが相互運用することを可能にするほどには十分ではない。これを可能にするためには、デバイスは、そのネットワーク内の他のデバイスに存在するファンクションを発見して、それにアドレスすることができる必要がある。そのような相互運用性は、ホームネットワーキングミドルウェア(HN-MW)によって供給される。ホームネットワーキングミドルウェアの例は、Jini, HAVi, UpnP, AVCである。
【００５９】
ネットワーク技術およびHN-MWの使用は、1セットの個々のデバイスを、1つの大きなバーチャルデバイスに変化させる。HN-MWの視点から見て、ネットワークは、用いることができ、そして、接続することができる1セットのファンクションと見なすことができる。そのようなシステムは、ユーザに、ホームネットワーク内のいかなるところからのいかなるコンテンツまたはサービスにもアドレスする能力を供給する。
【００６０】
HN-MWは、2つのサービスを提供するシステムとして定義することができる。それは、ネットワーク中のアプリケーションが、ネットワーク中のデバイスおよびファンクションを探し出すことを可能にする。さらに、ある種類のremote procedure call（RPC：リモートプロシージャコール）メカニズムが、いかにして、これらのファンクションを用いるかを決定する。
【００６１】
HN-MWの視点から見て、セキュアなコンテンツの扱いに関連するシステムは、いくつかの態様で現われる。ネットワーク中のいくつかのファンクションは、保護されたコンテンツへのアクセスを必要とする。ネットワーク中の他のファンクションは、コンテンツセキュリティを扱う、ネットワーク中のエレメントが用いることのできる機能を供給する。さらに、OPIMAのようなセキュリティフレームワークは、HN-MWを用いて、互いを探し出し、かつ、相互運用可能な態様で通信することができる。
【００６２】
セキュリティフレームワークおよびホームネットワーク
このサブセクションは、この直前の任意選択「セキュリティフレームワークを探し出し、そして、その間で通信するために、ホームネットワーキングミドルウェアをいかに用いるか」について検討する。この場合、セキュリティフレームワークは、ホームネットワーク中の1つのファンクションとして表わすことができる。これは、セキュリティファンクションが、ネットワーク中の他のセキュリティファンクションを探し出し、そして、アドレスすることを可能にする。
【００６３】
このアプローチを用いると、他のセキュリティフレームワークを探し出して、それらの機能を用いることができる。これは、通常のアプリケーションに対しては十分である。セキュアなコンテンツにアドレスするアプリケーションの場合には、そのコンテンツがセキュアなままであり、そして、そのコンテンツを保護しているシークレットを傍受されることがないということが必要である。さらに、他のセキュリティデバイスが信頼できるものである証明が、必要である。
【００６４】
そのような機能は、secure authenticated channel （SAC：セキュア認証済チャンネル）を備えていることが好ましい。SACが作り出されると、両パーティが、互いを認証し、そして、暗号化されたメッセージのセキュアなチャンネルを作り出す。これは、互いに通信し合いたいと望んでいるセキュリティフレームワークが、セキュアに通信することを可能にする。いくつかのセキュリティデバイスが、1つのネットワーク中に存在する場合には、それらの間のSACのセットを、virtual private network（VPN：仮想私設網）と見なすことができる。
【００６５】
そのようなVPNの内部において、この場合にもやはり、デバイスおよびファンクションを探し出して、それにアドレスする必要がある。したがって、ホームネットワークミドルウェア(HN-MW)が、VPNの内部で作動する必要がある。そのような機能は、システム中に既に存在する（HN-MWが、セキュリティデバイスを探し出すために用いられる）から、VPNの範囲内において、それを再使用することができる。
【００６６】
そうするために、セキュリティフレームワークは、HN-MW技術を用いて、メッセージを送受信できなければならないし、また、メッセージを送信することを可能にするメソッドを実装しなければならない（付録Eを参照のこと）。
【００６７】
このことをより詳細に説明するために、図3は、1つのセキュリティフレームワークから他のセキュリティフレームワークに送信されるメッセージを記述している。この図において、左側の灰色のブロックは、メッセージヘッダを指示しており、白いブロックは、メッセージ本体を指示している。ネットワークメッセージには、セキュリティファンクションのリモートプロシージャコール (RPC)であるHN-MWメッセージが、含まれている。
【００６８】
リモートプロシージャコールのデータは、SACによって処理されるメッセージ本体である。各HN-MW標準ごとに1つのSACを定めることができるであろうが、本発明者達は、全てのHN-MW標準に対して1つのSAC（SSL (RFC 2246)が好ましい）を用いることを提案する。SACのデータエレメントは、やはり、リモートプロシージャコールであるが、この場合には、セキュリティファンクションのファンクションに関するものである。この場合、それは、OPIMAファンクションコールである。その後、HN-MWメッセージが、ネットワークメッセージに組み込まれ、そして、ホームネットワーク上に伝送される。
【００６９】
この解決法は、セキュリティフレームワークが、互いを探し出して、通信することを可能にし、そして、HN-MWおよびネットワーク技術に依存しない。もちろん、SACを、HN-MWまたはネットワーク技術に組み込むこともできる。この場合には、状況が若干変化するかもしれないが、その機能は、そのままである。
【００７０】
認証および信頼
デバイスが、セキュアな態様で保護されたコンテンツを用いるためには、ネットワーク中のRMPシステムとセキュリティフレームワークとは、互いに信頼し合う必要がある。信頼できるデバイスは、標準によってセットされたパラメータの範囲内で働くと期待できる。これをするために、信頼できるサードパーティが、認証のために必要とされるキーを定める前に、デバイスをチェックする必要がある。
【００７１】
これは、2段階のアプローチ：RMPシステムがTVAFを認証し、次に、TVAFが互いを認証する、を用いて実施される。これは、RMPシステムが、システム内の各TVAFを認証しなければならなくなること、および、全ての種類のHN-MWの細目をサポートしなければならなくなることを防止する。
【００７２】
RMPシステムが、デバイスに埋め込まれると、RMPシステムとセキュリティフレームワークとは、互いに信頼し合うことができるものであるから、セキュリティフレームワークの認証を要求すべきではない。これは、RMPシステムによるセキュリティフレームワークの（時間のかかりすぎる）認証を省くことができるという利点を持つ。
【００７３】
リモートツールの使用
セキュリティフレームワークおよびホームネットワークに関するセクションにおいて上に説明したように、VPNは、TVAFの間に作り出される。これは、1つの大きなTVAFとみなすことができる。VPNは、リモートTVAFのツールを局所的に備えるために用いることができる。この場合、コールは、他のTVAFのパブリックインターフェイスへのRPCコールを用いて行われる。OPIMA OVM（TVAFとして用いることができる）の状況におけるそのようなコールの一例が、図4に例証されている。デバイス2において、コールおよびリターンの経路が、OVMを通っており、SACを備えたRPCが、抽出されて、コールされることを記号で表している。
【００７４】
TVAFが、ネットワーク内の他のところで実施されるツールを備える他の1つの任意選択は、そのHN-MWで直接利用可能なツールを備えることである。恐らく、そのようなツールの最良の例は、スマートカードリーダである。スマートカードとの通信は、RMPシステムによって既に保護されており、無保護のチャンネルを通じてアクセスされても構わない。
【００７５】
このセットアップは、TVAFが、そのHN-MW内のツールであって、そのVPN中の他のTVAFで利用可能なツールを備えることを可能にする。性能の視点から見ると、利用可能な場合には、局所的なツールを用いる方が得策である。ネットワーク化されたツールは、正規のOPIMA APIを用いて行使される。もちろん、TVAF実装は、ネットワーク化されたツールを備えるように選ぶこともでき、局所的なツールを用いることを強いられることは全くない。
【００７６】
コンテンツデコーディング、ストリーミング、および、HN-MW
ネットワーク化された環境でコンテンツにアクセスする場合、そのコンテンツを、ソースから他のデバイスに流し／輸送しなければならないであろう。ほとんどの場合、これは、ネットワークからの，あるQoSサポートを必要とする。ネットワーク内に接続をセットアップし、そして、QoSを管理する態様は、ネットワーク技術に極度に依存する。通常、そのようなストリームは、HN-MW内に定められるメカニズムを用いて作り出され、また、停止される。
【００７７】
コンテンツは、デバイスインターフェイス上で常に傍受することができるから、TVAFを離れるどんなコンテンツも、保護しなければならない。通常、これは、ある種類の暗号化を用いてなされる。RMPシステムは、コンテンツのデスクランブリングを可能にするキーへのアクセスを制御することによって、コンテンツの制御を維持する。コンテンツは、ある種類のRMPシステムによって保護されているTVAデバイスのドメインからしか離れない。さらに、1つのRMPシステムから他のRMPシステムへのコンテンツの各転送は、そのRMPシステムによって制御される。このように、RMPシステムは、コンテンツに何が起こるかをずっと制御している。
【００７８】
配給されたコンテンツアクセス
ホームネットワーキングミドルウェアを用いる別の1つの態様は、他のデバイス上に実装されたエレメントを用いて、コンテンツアクセスを実施することである。そのように配給されたコンテンツアクセスを実現する方法の一例を、図5に見ることができる。この例において、以下の役割を認めることができる。
【００７９】
−  ソース；コンテンツのソース。
−  シンク；コンテンツのシンク。
−  処理；1つ以上の処理ファンクションが、ストリーミングパス内に存在することができる。処理ファンクションは、ある操作がコンテンツ上で行われるファンクションである。
−  アプリケーション；いろいろのHN-MWファンクションを接続して、コンテンツアクセスを開始するアプリケーション。この「アプリケーション」は、実際には、DVB-MHP 
API（または、任意の他の同様のAPI）の実装であることに注意されたい。
−  RMP；コンテンツを制御するRMPシステム。
【００８０】
配給されたコンテンツアクセスでは、これらの役割の各々を、相異なるデバイスに置くことができる。
【００８１】
HN-MWおよびOPIMAコンパートメント
多くのコンテンツフォーマットおよびRMPシステムが、存在する。各可能なそれらの任意選択をモデル化して、サポートしなければならなくなることを防止するために、OPIMAは、コンパートメントの概念を用いる。OPIMAによれば、コンパートメントは、RMPインターフェイスおよび／またはアーキテクチャコンポーネントにおけるいくつかの共通エレメントを共有する、OPIMAによって動作可能なデバイスのクラスである。例えば、DVBは、コンパートメントと考えることができ、次には、そのコンパートメントは、特定のRMPシステムによって定められる他のコンパートメントを含んでいると考えることができる。コンパートメントは、階層的であってもよい。即ち、コンパートメントは、サブコンパートメントを含むことができる。
【００８２】
コンパートメントは、そのコンパートメント内で利用可能ないろいろなシステムエレメントおよびツールを定める。RMPシステムは、コンパートメントの範囲内で作動するから、それは、どのツールおよびシステムを予期し得るかを知っている。コンパートメントの範囲内で定められるエレメントの例としては、暗号化アルゴリズムおよびルールフィルタがある。
【００８３】
HN-MWの範囲内で、コンパートメントは、HN-MWを用いて相互接続されるIHDNにおいて利用可能なネットワーク化されたファンクションを定めるために用いられる。これらのセキュリティファンクションは、1つのコンパートメントに定められ、そして、HN-MWに個々のファンクションとして実装することができる、または、それらのファンクションは、他のファンクションに組み込むことができる（例えば、チューナは、ルールフィルタを、ディスプレイは、デスクランブラを保持してもよい）。コンパートメントを用いて、ある種類のRMPシステムによって保護されたデバイスインターフェイス上でしかコンテンツを利用可能にできないように、セキュリティファンクションを定めることができる。
【００８４】
保護されたコンテンツおよびメタデータ
コンテンツにアクセスするためには、そのコンテンツを保護しているRMPシステムを知らなければならない。通常のセットアップでは、コンテンツは、さらにセキュリティコンポーネントも保持しているデバイスにおいて利用可能である。1つのネットワーク内において、これは、もはや、そうである必要がない。したがって、アプリケーションは、どのRMPシステムが、コンテンツを保護するために用いられているかを決定する手段を必要とする。これは、コンテンツフォーマットのような既に存在するメタデータに加えて必要とされる追加情報である。
【００８５】
理想的な世界では、コンテンツをレンダリングするときにしか、そのコンテンツを処理しなくともよい。しかしながら、いくつかの場合に、RMPシステムは、いくつかの操作をコンテンツに実行することを必要とするであろう。そのような操作の例は、キー置き換えおよび再暗号化である。これらの操作は、そのコンテンツ上で必要とされ、そして、アプリケーションが知っていなければならない操作に依存する。そのような機会の一例は、コピーが行われるときであり、そのコンテンツに関連するルールが、変化するであろう（copy_one_generation -> copy_no_more：コピー_1回_生成 -> コピー_もはや_なし） 。アプリケーションが、いくつかの操作が、ある操作のために必要であることを知っているときにしか、これらの操作を、ストリーミングパスに組み込むことができない。ストリーミングパスに特定のルールを組み込まなければならない他のエレメントが、漏れ出ていく。
【００８６】
したがって、アプリケーションは、どのセキュリティファンクションが、ストリーミングパスに組み込まれるかを知らなければならない。アプリケーションは、メタデータから、これらのファンクションを知ることができる。コンテンツメタデータには、含まれていなければならない各コンテンツアクセスタイプの操作のリストが包含されている。
【００８７】
必要とされるセキュリティファンクションは、そのコンテンツに必要なアクセスタイプに依存する。言いかえれば、それらは、コンテンツアクセスの目的に依存する。OPIMA内には、1セットの目的が、定められている。このセットを、ネットワークの視点から見たコンテンツアクセスの完全なセットに合うように拡張した。
【００８８】
目的の3つのメインクラスが、定められている。目的の完全なリストが、以降の付録Bに与えられている。
−  放出；この目的クラスは、1つのRMPシステムから他のRMPシステムへのコンテン
ツの転送を管理する。この目的クラスの次に、他のRMPシステムの内部のコンテン
ツの目的が、指示される。
−  受信；この目的クラスは、コンテンツが他のRMPシステムから受信されることを指
示する。
−  アクセス；この目的クラスは、1つのRMPシステム内のコンテンツへのアクセスを扱
う。この目的クラスの次に、その目的が、より詳細に指示される。
【００８９】
コンテンツの放出は、そのコンテンツの権利を、1つのRMPシステムから他のRMPシステムに移し換えるときに必要とされ、通常、これは、そのコンテンツのルールの変更と、恐らく、さらに再暗号化とを必要とする。コンテンツ（フォーマット）トランスコーディング、トリックプレー、および、画質改善処理のようなアクセスは、コンテンツを変更せず、そのRMPシステムの範囲内で許可されるべきである。そのような機能は、通常、処理ファンクションの一部である。
【００９０】
したがって、RMPシステムに関連するメタデータは、以下の情報を保持しなければならない。
−  コンパートメント定義（付録Cを参照のこと）。
−  RMP定義（付録Cを参照のこと）。
−  各目的に対して、要求されるセキュリティファンクションのURNを持つ目的のリス
ト。
−  恐らく、あるコンパートメントに特有の情報。
【００９１】
HN-MW内のファンクション中に存在するセキュリティファンクションを認識するために、HN-MW内の各関連するファンクションが、それを指示するメソッドを実装している。
【００９２】
セキュリティファンクションおよびフレームワーク
この時点で、必要なセキュリティファンクションを全て保持するストリーミンググラフを作り出すことができ、したがって、この特定のコンテンツセッションを開始することができる。そのようなセッションの1つ以上を、コンテンツにアクセスするために必要とされるエレメントを全て含むようにつなぐことができる。
【００９３】
OPIMAにおいて、そのようなセッションは、いわゆるContentIdによって表わされており、TVAF内のストリームの1つをユニーク（唯一無二）に識別する。ネットワーク化された環境においては、各ContentIdをユニークに決定して、そのようなContentIdを定めることができるということが重要になる。これは、OPIMA ContentIdを、以下の値を含有する構造に置き換えることによってなされる。
−  tvafId：tvafId； TVAFのユニーク識別子。
−  contentAccessId：コンテンツアクセスId；このTVAFの範囲内のこのセッションを識
別するユニーク識別子。
−  streamId：ストリームId；参照されているこのセッション内のストリームを指示する
番号。
【００９４】
付録CのC.1.5において、この構造が、IDL（ContentSessionId：コンテンツセッションID）に表わされている。
【００９５】
tvafIdとcontentAccessIdとの組み合わせが、このセッションをユニークに識別する。この情報を用いて、ネットワーク中のセキュリティファンクションのTVAFが、マスタTVAFに登録して、このコンテンツアクセスに関連するメッセージを受信することができる。まず第1に、新しいセッションを作り出さなければならない。付録Aには、セッションを作り出すために用いることができる内部メソッドの定義の一例が、含まれている。
【００９６】
tvafIdとContentAccessIdとを用いて、このコンテンツアクセスに絡んだセキュリティファンクションが、自らを、このコンテンツアクセスが開始されるTVAF（マスタTVAF）に登録することができる。これは、セキュリティファンクションのHN-MW APIのattachToContentAccess：コンテンツアクセスに連結するメソッドを用いてなされる。このメソッドがコールされると、セキュリティファンクションのTVAFが、自らを、マスタTVAFに登録する。
【００９７】
登録に際して、マスタTVAFは、登録TVAFをコールして、その登録を確認し、そして、そのコンテンツアクセスに連係している目的を指示する。そのTVAFは、この目的の範囲内で、このコンテンツアクセスのコンテンツを扱う。
【００９８】
全てのセキュリティファンクションが、登録されたら、そのセッションを開始することができる。そのセッションは、ホームネットワークにストリーミングを開始し、次いで、そのコンテンツへのアクセスが要求されていることを指示することによって、開始される。ソースデバイス以外のデバイスに置かれたルールフィルタが、コンテンツにアクセスする必要があるので、ストリーミングを、最初に開始しなければならない。これは、開始するべきストリーミングを必要とする。専有拡張をサポートするため、どの時点においても、アプリケーションは、RMPシステムと直接通信することができる（付録AのA.3およびA.4を参照のこと）。
【００９９】
この時点で、このセッションを、開始することができる。TVAFがRMPシステムにコンタクトし、ルールがフィルタされ、そして、コンテンツへのアクセスが、容認されるか、または、否定される。
【０１００】
配給されたコンテンツアクセスおよびRPC
RMPシステムにおいて、局所的なコンテンツアクセスと配給されたコンテンツアクセスとは、同じやり方で扱うべきである。ネットワーク化されたアクセスかどうかに関わらずOPIMA APIを用いるためには、RPCの取り扱いに関するいくつかのガイドラインが必要である。RPCコールは、図6に指示されているシステムにしたがって管理される。
【０１０１】
「コール」と指示されているRMPシステムコールは全て、マスタOVMによって、そのセッションに登録されている全てのOVMに再送される。全てのコールの応答が、組み合わされて、戻り値が、RMPシステムへのコールバックに指示される。
【０１０２】
2つのタイプの（リモートプロシージャ）コールを決定することができ、それらは、コンテンツアクセスおよびツールを用いているコールに関係している。コンテンツアクセスに関連するコールは、コンテンツアクセスに関連するために、ContentIdを用いる。普通の、コンテンツアクセスに関連しない、ツールに関するコールは、利用可能であれば局所的に、そうでなければリモートにコールされる。コンテンツアクセスに関連するコールは、以下のガイドラインを用いて扱われる。
1.  コールがRPCであれば、それを局所的に扱って、その結果を返す。
2.  コールが局所的であり、そして、このコールのコンテンツアクセスが局所的であれば、
すべての登録されているTVAF上のファンクションをコールする（さらに、このTVAF
がストリームの一部であれば、局所的に）。
3.  コールが局所的であるが、このコールのコンテンツアクセスが局所的でなければ、そ
のコンテンツアクセスを保持しているマスタTVAFをコールする。
【０１０３】
相異なるTVAFが、どの機能がどのTVAFに置かれているかを知る必要がないので、本解決法のマスタ／スレーブ特質が、通信を単純化する。
【０１０４】
付録A：アプリケーションサービスAPI
DAVIC CA APIは、本ドキュメントの範囲内で、アプリケーションAPIとして働く。このAPIをホストするデバイスの内部に、このAPIを実装するために、ある特定の情報をTVAFに渡さなければならない。これは、仕様化する必要のない内部専有APIを用いて行われる。以下の（情報的な）メソッドが、コンテンツアクセスを開始、停止、および、制御するために用いられるメソッドの一例を与える。
【０１０５】
attachToContentAccess：コンテンツアクセスに連結する
このメソッドは、そのTVAFを、指示されているコンテンツアクセスを管理しているTVAFに登録し、それによって、それは、任意の関連するRPCを受信する。コンテンツアクセスが開始するときに、全ての値が、TVAFによって指示される。
【０１０６】
A.1  アプリケーションサービス
A.1.1  createContentRelease：コンテンツ放出を作り出す
他のRMPシステムにコンテンツを放出する意図のTVAFを持つセッションを作り出す。
【表１】
2005527011.tif 000003
【０１０７】
A.1.2   createContentAccess：コンテンツアクセスを作り出す
コンテンツにアクセスする意図のTVAFを持つセッションを作り出す。
【表２】
2005527011.tif 000004
【０１０８】
A.1.3   createContentReceive：コンテンツ受信を作り出す
他のRMPシステムからコンテンツを受信する意図のTVAFを持つセッションを作り出す。
【表３】
2005527011.tif 000005
【０１０９】
A.1.4   startContentSession：コンテンツセッションを開始する
このセッションを開始する。
【表４】
2005527011.tif 000006
【０１１０】
A.1.5   stopContent：コンテンツを停止する
コンテンツアクセス、放出、または、受信を停止する。
【表５】
2005527011.tif 000007
【０１１１】
A.2  アプリケーションサービスリスナ
A.2.1   startContentSessionResponse：コンテンツセッション応答を開始する
この非同期応答は、あるイベントが生じていることを知らせるために、TVAFによってアプリケーションに出される。それは、同期化の目的のために用いることができる。
【表６】
2005527011.tif 000008
【０１１２】
A.3  アプリケーションRMPサービス
A.3.1   queryRMPSystems：RMPシステムを照会する
このメソッドは、アプリケーションが、TVAFにインストールされたRMPシステムにメッセージを送信し、そして、答えを受信することを可能にする。
【表７】
2005527011.tif 000009
【０１１３】
A.3.2   sendMessageToRMP：RMPにメッセージを送信する
このメソッドは、アプリケーションが、TVAFにインストールされたRMPシステムにメッセージを送信し、そして、答えを受信することを可能にする。
【表８】
2005527011.tif 000010
【０１１４】
A.4  アプリケーションRMPサービスリスナ
A.4.1  msgFromRMP：RMPからのメッセージ
この非同期応答は、あるイベントが生じていることを知らせるために、TVAFによってアプリケーションに出される。それは、同期化の目的のために用いることができる。
【表９】
2005527011.tif 000011
【０１１５】
A.4.2   indicateRmpList：RmpListを指示する
この非同期応答は、利用可能なRMPシステムのリストを知らせるために、TVAFによってアプリケーションに出される。
【表１０】
2005527011.tif 000012
【０１１６】
付録B：目的
以下の目的が、定義されている。
【表１１】
2005527011.tif 000013
【０１１７】
付録C：HN-MWの使用に関連するTVAF API
C.1   TVAFネットワークサービス
C.1.1   getTVAFId：TVAFIdを得る
このTVAFのTVAF idを戻す。
【表１２】
2005527011.tif 000014
【０１１８】
C.1.2  registerWithContentSession：コンテンツセッションに登録する
コールしているTVAFを、指示されているコンテンツセッションに登録する。
【表１３】
2005527011.tif 000015
【０１１９】
C.1.3   unRegisterWithContentSession：指示されているコンテンツセッションに未登録にする
コールしているTVAFを、指示されているコンテンツセッションに未登録にする。
【表１４】
2005527011.tif 000016
【０１２０】
C.1.4   contentSessionRegistered：登録されたコンテンツセッション
マスタTVAFによる登録の確認。その目的は、このコンテンツアクセスに関連する目的を指示する。TVAFは、この目的の範囲内のコンテンツを扱う。
【表１５】
2005527011.tif 000017
【０１２１】
C.1.5   contentSessionStopped：停止されたコンテンツセッション
コンテンツセッションが停止されていることの他のTVAFへの指示。
【表１６】
2005527011.tif 000018
【０１２２】
C.2   IDL
前のメソッドのIDLコードは、以下のとおりである。
【０１２３】
// 一般的な構造
enum Purpose { RELEASE_RENDER, RELEASE_MOVE, RELEASE_COPY, RECEIVE, ACCESS_STORE, ACCESS_RENDER, ACCESS_EDIT, ACCESS_DELETE, ACCESS_PROCESS, OTHER};
typedef sequence <octet, 16> TvafId;
struct ContentId {
TvafId tvafId;
long  contentSessionId;
long  streamId
} ;
// TVAFネットワークに関連するインターフェイス
interface TvafNetworkServices {
long getTvafId( out TvafId tvafId );
long registerWithContentSession( in TvafId tvafId, in long contentSessionId );
long unRegisterWithContentSession(in TvafId tvafId, in long contentSessionId );
long contentSessionRegistered( in TvafId tvafId, in long contentSessionId, Purpose p );
}
【０１２４】
付録D：TVAF URLおよびURN
D.1  ユニフォームリソースロケータ(URL)定義
TVAFにおける使用のために、以下のURL定義が、与えられる。
【０１２５】
−  RMPシステム
tvaf:://<network_address>/<TVAFid>/ipmp/<rmp_id>
−  アプリケーション
tvaf:://<network_address>/<TVAFid>/app/<app_id>
−  ツール
tvaf::// <network_address>/<TVAFid>/tool/<tool_id>
【０１２６】
これらのURLにおいて、いろいろのフィールドは、以下の意味を持っている。
tvaf::、メッセージがSACを通じて送り出されることを指示する。
<network_address>、TVAFをホスティングしているデバイスのアドレス。
<TVAF_id>、TVAFのid。
<RMP_id>、RMPモジュールのid。
<app_id>、アプリケーションのid。
<tool_id>、ツールのid。
【０１２７】
例：
tvaf:://130.130.120.4/34535/ipmp/1213
tvaf:://130.130.120.4/34535/app/113
tvaf:://130.130.120.4/34535/tool/12234
【０１２８】
D.2  ユニフォームリソースネーム(URN)定義
TVAFシステムURNは、以下のように定義される。
−  コンパートメント：
tvaf:://<compartment_source>/compartment
−  セキュリティファンクション
tvaf:://<compartment_source>/compartment/<function>
【０１２９】
これらのURNにおいて、いろいろのフィールドは、以下の意味を持っている。
<compartment_source>、コンパートメントを定めた母体の名前（インターネットスタイル）。
<function>、このコンパートメントのこの特定のファンクションの名前。
【０１３０】
例：
tvaf:://org.dvb/mpeg2
tvaf:://org.dvb/mpeg2/sink
tvaf:://org.dvb/mpeg2/receive
tvaf:://org.dvb/mpeg2/source
tvaf:://org.dvb/mpeg2/processor
【０１３１】
付録E：HN-MWメソッド上のメソッド
【０１３２】
E.1   TVAF API
TVAFは、HN-MWにおいて、独立のメソッドとして表わされる。以下のメソッドが、そのようなファンクションで利用可能である。
【０１３３】
E.1.1   newMessage：新しいメッセージ
このTVAFに対する新しいメッセージが、受信されている。
【表１７】
2005527011.tif 000019
【０１３４】
E.2  セキュリティファンクションAPI
以下のメソッドが、セキュリティファンクションをサポートしているHN-MWのファンクションで利用可能である。
【０１３５】
E.2.1  getSecurityFunctions：セキュリティファンクションを得る
このメソッドは、このHN-MWファンクションによってサポートされるセキュリティファンクション（付録D）のURNを指示する。
【表１８】
2005527011.tif 000020
【０１３６】
E.2.2  attachToContentAccess：コンテンツアクセスに連結する
このメソッドは、そのTVAFを、指示されているコンテンツアクセスを管理しているTVAFに登録し、それによって、それは、任意の関連するRPCを受信する。コンテンツアクセスが開始するとき、全ての値が、TVAFによって指示される。
【表１９】
2005527011.tif 000021
【０１３７】
付録F：略語
以下は、本ドキュメントにおいて用いられる略語と、それらに意図されている意味とのリストである。
AES                     Advanced Encryption Standard
APDU                  Application Protocol Data Unit
API                      Application Programming Interface
CFC                    Call for Contribution
DAVIC                Digital Audio & Visual Council
DVB                    Digital Video Broadcasting
HAVi                   Home Audio Video interoperability
HN-MW                            Home Networking Middleware
ISO                      International Organization for Standardisation 
MMI                    Man Machine Interface
MPEG                 Moving/motion Pictures Expert Group 
OVM                   OPIMA Virtual Machine
QoS                     Quality of Service
RMP                    Rights Management and Protection
RPC                     Remote procedure call
SAC                    Secure Authenticated Channel
TLS                     Transport Layer Security protocol
TTP                     Trusted Third Party
TVA                    TV-Anytime
TVAF                  TV-Anytime Framework
UPnP                   Universal Plug and Play
VPN                    Virtual Private Network
【０１３８】
上述の実施例は、本発明を制限するものではなくて例証するものであること、および、当業者であれば、付されている請求項の範囲を逸脱することなく、多くの代替実施例を設計することができることに注意されたい。例えば、上記において、OPIMAが用いられているが、もちろん、他のセキュリティフレームワークで置き換えることもできる。例えば、MPEG-4 IPMP拡張を、同様に用いることができる。
【０１３９】
請求項において、括弧内に置かれたどの参照符号も、請求項を制限すると解釈されないものとする。用語「有する」は、請求項でリストされている以外のエレメントまたはステップの存在を除外するものではない。エレメントの前の語「1」または「1つの」は、複数のそのようなエレメントの存在を除外するものではない。本発明は、いくつかの個別エレメントを有するハードウェアによって、および、適切にプログラムされたコンピュータによって、実施することができる。
【０１４０】
いくつかの手段を列挙しているデバイス請求項において、それらの手段のいくつかは、全く同一のアイテムのハードウェアによって具体化することができる。いくつかの施策が互いに異なる従属請求項で列挙されているという単なる事実は、これらの施策の組み合わせを有利に生かして用いることができないということを指示するものではない。
【図面の簡単な説明】
【０１４１】
【図１】ソース、シンク、2個の記憶メディアを有する、本発明による家庭内ネットワークの好適な一レイアウトを線図的に例証する。
【図２】Rights Management & Protection (RMP)の好適な一セキュリティフレームワークの基本構造を例証する。
【図３】1つのセキュリティフレームワークから他のフレームワークに送信されるメッセージを記述する。
【図４】どのようにして、OPIMA OVMのパブリックインターフェイスにRPCコールを用いて、コールがなされるかを例証する。
【図５】どのように、配給されたコンテンツアクセスを実現するかを例証する。
【図６】どのように、RPCコールを管理するのが好ましいかを例証する。
【図１】
2005527011.tif 000022
【図２】
2005527011.tif 000023
【図３】
2005527011.tif 000024
【図４】
2005527011.tif 000025
【図５】
2005527011.tif 000026
【図６】
2005527011.tif 000027
【国際調査報告】
2005527011.tif 000028
2005527011.tif 000029
2005527011.tif 000030
2005527011.tif 000031
2005527011.tif 000032