JP5351158B2 - テザード装置システム及び方法 - Google Patents

Description

関連出願
本出願は、２００７年７月２３日付けで出願された「Ｄｙｎａｍｉｃ Ｍｅｄｉａ Ｚｏｎｅｓ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ」という名称の米国仮特許出願第６０／９５１，３４９号に伴う優先権を主張するものであり、この内容は、本引用により、本明細書に包含される。

著作権の許諾
本特許明細書の開示内容の一部には、著作権保護の対象物が含まれる。著作権者は、特許商標庁の特許ファイル又は記録への掲載に伴う本特許明細書又は特許開示の複写には異議を提起しないが、それ以外については、どのようなものであれ、全ての著作権を制限する。

現代のコンピュータシステムにおいては、電子コンテンツ、サービス、又は処理リソースに対するアクセスを制限し又は特定の動作の実行を特定のエンティティに対してのみ許容することが大抵の場合には望ましい。このような制御を可能にするために様々な技法が開発又は提案されている。これらの技法は、しばしば、デジタル著作権管理（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ：ＤＲＭ）法と呼ばれている。その理由は、一般には、デジタル又はその他の電子コンテンツ、サービス、又はリソースにおける様々なエンティティの権利を管理することを目的とするからである。本明細書には、電子コンテンツの管理を容易にするためのシステム及び方法が示され、好適な実施例のグループにおいては、テザード装置を構成、制御、及び／又は使用するためのシステム及び方法が示されている。これらのシステム及び方法は、そこで用いられているコンポーネント、システム及び方法の多くと同様に新規であることを理解されたい。本明細書に記述されている本発明の実施例は、プロセス、装置、システム、機器、方法、コンピュータによって読取り可能な媒体、及び／又はこれらの組み合わせを含む多数の方式において実現可能であることを理解されたい。以下、実施の態様について説明する。

添付の図面との関連において以下の詳細な説明を参照することにより、本発明について容易に理解することができよう。

本発明の実施例を実施するためのシステムを示す。 ホストシステムの一例を示す。 テザード装置の一例を示す。 ホスト及びテザード装置を有するシステムの一例を示す。 装置記述文書の一例を示す。 ホストと装置の間に安全な認証チャネルを確立するプロセスを示すフローチャートである。 ホストとテザード装置の間にペアリングを確立するプロセスを示すフローチャートである。 ホストからテザード装置にライセンスをエクスポートするプロセスの一例を示す。 ホストからテザード装置にライセンスをエクスポートするプロセスを更に詳細に示す。 ライセンス及びリンクオブジェクトからのＳＶＳ及びＬＶＳレコードの生成を示す。 保護されたコンテンツ片をレンダリングするためにクライアントによって実行される例示用の一連の動作を示す。 コンテンツ片に対するアクセス又はコンテンツ片の他の使用がＳＶＳによって許容されるか否かを決定するプロセスを示すフローチャートである。 テザード装置のセキュリティデータを更新するためにホストによって実行可能な例示用のプロセスを示す。 ホストとテザード装置の間におけるＴＬＳの実装を示す。 ハンドシェークプロトコルを示す。 拡張ＳＣＳＩコマンドを使用してＵＳＢ接続上においてホストとテザード装置の間の通信を開始する例示用のプロセスを示す。 データベースのファイルレイアウトの一例を示す。 ドメインに参加するテザード装置の一例を示す。 メッセージのカプセル化の一例を示す。

以下、本発明について詳細に説明する。いくつかの実施例について説明するが、本発明は、いずれか１つの実施例に限定されるものではなく、多数の代替、変更、及び均等物を包含することを理解されたい。更には、本発明に関する完全な理解のために、以下の説明において多数の特定の詳細事項についても記述しているが、一部の実施例は、これらの詳細事項のいくつか又は全てを伴うことなしに実施可能である。更には、明瞭のために、不必要に本発明を曖昧にすることを回避するために関連分野において既知の特定の技術内容を詳細に説明していない。

好適な実施例のグループにおいては、テザード装置を構成、制御、及び／又は使用するシステム及び方法が提供されている。例えば、本明細書に記述されているシステムおよび方法を使用し、本引用によって本明細書にその内容が包含される、本譲受人に譲渡された、２００６年１０月１８日付けで出願され、且つ、米国特許出願公開第２００７−０１８０５１９−１Ａ号として公開された、「Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ Ｅｎｇｉｎｅ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ」という名称の同時係属中の米国特許出願第１１／５８３，６９３号（「’６９３号」出願）に記述されているようなＤＲＭシステムを拡張することにより、簡単な装置よりも大きな能力を有するホストエンティティが、１つ又は複数のオリジナルのライセンスから使用規則及びコンテンツ鍵をエクスポートすると共に、オリジナルのライセンスによって管理されたコンテンツを簡単な装置が消費できるようにする、オリジナルのライセンスにおいてコード化された使用規則の更に限定された表現を有する、非常に簡単なデータ構造を生成することができるようにすることができる。ホストは、（「’６９３号」出願に記述されているような）使用規則を表現するために使用されたコントロールから、装置内における使用規則を表す簡単な有効性ステートメント（Ｓｉｍｐｌｅ Ｖａｌｉｄｉｔｙ ｓｔａｔｅｍｅｎｔ：ＳＶＳ）レコードを生成する。ホストは、ホストＤＲＭシステム内におけるエンティティ間の関係を表現するために使用されたリンクから、ホストシステム内に存在するノードのグラフに類似したノードのグラフの内部表現を装置が構築できるようにするリンク有効性ステートメントレコードを生成する。

図１は、コンテンツをデジタル著作権管理システムを使用して配布及び管理するシステム１００の一例を示す。好適な実施例においては、「’６９３号」出願に記述されているようなデジタル著作権管理システムを使用可能であるが、本明細書に記述されている原理に従い、任意の適切なデジタル著作権管理システムを使用可能であることを理解されたい。

図１に示されているように、電子コンテンツ１０３の権利を保有するエンティティ１０２は、配布と、エンドユーザ１０８ａ、１０８ｂによる消費のために、コンテンツをパッケージングする（尚、以下においては、これらのエンドユーザは、「エンドユーザ１０８」と総称され、この場合に、参照符号１０８は、文脈から明らかなように、エンドユーザ又はエンドユーザのコンピュータシステムをほとんど同じ意味で言及する。）。例えば、エンティティ１０２は、音楽家、映画スタジオ、出版社、ソフトウェア会社、著者、モバイルサービスプロバイダ、インターネットコンテンツダウンロード又は有料加入サービス、ケーブル又は衛星テレビプロバイダ、企業の従業員、又はこれらに類似したもの、或いは、これらの代理として機能するエンティティなどのコンテンツ所有者、クリエータ、又はプロバイダを有することが可能であり、且つ、コンテンツ１０３は、任意の電子コンテンツを有することができる。例えば、コンテンツ１０３は、デジタルビデオ、オーディオ、又はテキストコンテンツ、映画、テレビショー、ビデオクリップ、楽曲、ポッドキャスト、ビデオゲーム、ソフトウェア片、電子メールメッセージ、テキストメッセージ、ワードプロセッサ文書、レポート、又は任意のその他のエンターテインメント、事業計画、又はその他のコンテンツを有することができる。パッケージングプロセスには、通常、デジタル著作権管理システムによって要求されるセキュリティ保護をコンテンツに対して適用するステップが伴うことになる。例えば、コンテンツは、適切な暗号鍵、証明書、及び／又はこれらに類似したものを得るためにトラストオーソリティ１１０を使用することができる暗号化又はデジタル署名法などの１つ又は複数の暗号メカニズムによって保護可能である。

図１に示されている例においては、エンティティ１０２は、ライセンス又はその他の形態の電子コントロール１０６をパッケージング済みのコンテンツ１０４と関連付けるためにパッケージングエンジン１０９を使用する。ライセンス１０６は、ポリシー１０５又はエンティティ１０２のその他の所望に基づいたものであり、且つ、コンテンツの許容された及び／又は禁止された使用法、及び／又は、コンテンツを利用するために満足しなければならない又は使用の条件又は結果として満足しなければならない１つ又は複数の条件を規定している。図１は、エンティティ１０２によってコンテンツと関連付けられたライセンスを示しているが、その他の実施例においては、このようなライセンスを別のエンティティ（例えば、再販業者又はその他の権利保有者）によって関連付け及び／又は変更することも可能であることを理解されたい。

図１に示されているように、パッケージング済みのコンテンツ１０４及び関連する１つのライセンス（又は、複数のライセンス）１０６は、任意の適切なメカニズムを介して（例えば、インターネット、ローカルエリアネットワーク、無線ネットワーク、仮想プライベートネットワーク、ワイドエリアネットワーク、及び／又はこれらに類似したものなどのネットワーク１１２上におけるダウンロード又はストリームを介して、コンパクトディスク（ＣＤ）、デジタルバーサタイルディスク（ＤＶＤ）、フラッシュメモリカード（例えば、セキュアデジタル（ＳＤ）カード）、及び／又はこれらに類似したものなどの記録可能な媒体を介して、ケーブル、衛星、放送、又はセルラー通信を介して、及び／又はこれらの類似したものを介して）エンドユーザ１０８に配布され、そこで、コンテンツは、関連するライセンスの条件に従って、ユーザ１０８のためにレンダリングされる。図１に示されているように、パッケージング済みのコンテンツ１０４は、ライセンス１０６と共に、単一のパッケージ又は伝送１１３において、或いは、同一の又は異なる供給元から受領される別個のパッケージ又は伝送１１４、１１５において、ユーザに対して供給可能である。

通常、ライセンス条件は、ユーザのシステム１０８上において稼働するデジタル著作権管理エンジンによって強制される。エンドユーザのシステムは、相対的に高い能力の装置（例えば、パーソナルコンピュータ１０８ａ、携帯電話機１０８ｂ、テレビ及び／又はテレビセットトップボックス、携帯型オーディオ及び／又はビデオプレーヤー、電子ブックリーダー、ゲームシステム、パーソナルデジタルアシスタント、及び／又はその他の電子装置）を有することも可能であり、或いは、相対的に低い能力の装置（例えば、いくつかの携帯電話機１０９ａ、携帯型オーディオ及び／又はビデオプレーヤー１０９ｂ、パーソナルデジタルアシスタント１０９ｃ、及び／又はこれらに類似したもの）を有することも可能である。装置１０８、１０９は、通常、コンテンツを取り出してレンダリングするアプリケーションソフトウェア１１６、ハードウェア、及び／又は専用論理を含む。相対的に高い能力の装置１０８は、通常、ライセンスによって許容された場合にのみコンテンツに対するユーザアクセスを選択的に許容することによって、パッケージング済みのコンテンツ１０４と関連するライセンス１０６を評価し、且つ、その条件を強制（し及び／又はアプリケーション１１６を起動してそのような条件を強制）する相対的に高い性能のデジタル著作権管理エンジン１１８を含む。デジタル著作権管理エンジン１１８は、アプリケーション１１６と共に構造的又は機能的に統合することも可能であり、或いは、別個のソフトウェア及び／又はハードウェア片を有することも可能である。或いは、この代わりに、相対的に低い能力の装置１０９は、相対的に高い能力の装置１０８上において稼働するＤＲＭエンジン１１８によってライセンス１０６から導出された相対的に簡単な条件１２０を強制する能力しか有していないアプリケーション１１６及び／又は相対的に簡単なデジタル著作権管理エンジンを包含可能である。

デジタル著作権管理エンジン及び／又はユーザのシステム上又はこれとのリモート通信状態にあるその他のソフトウェアは、保護されたコンテンツに対するユーザのアクセス又は保護されたコンテンツの他の使用に関する情報を記録してもよい。一部の実施例においては、この情報の一部又は全部は、例えば、収入の配分（ロイヤリティ、広告に基づいた収入など）、ユーザの好みの決定、システムポリシーの強制（例えば、機密情報を使用する方法及び時期の監視）、及び／又はこれらに類似したものなどにおける使用のために、遠隔地の関係者（例えば、クリアリングハウス１２２、コンテンツクリエータ、所有者、又はプロバイダ１０２、ユーザの管理者、これらの代わりに機能するエンティティ、及び／又はこれらに類似したもの）に対して伝達可能である。図１は、例示的なＤＲＭアーキテクチャ及び例示的な関係の組を示しているが、本明細書に記述されているシステム及び方法は、任意の適切な環境において実施可能であり、従って、図１は、例示及び説明を目的として提供されており、限定を目的としたものではないことを理解されたい。

図２は、本発明の実施例を実施するために使用可能なシステムの１つの可能な実施例３００の更に詳細な例を示す。例えば、システム２００は、エンドユーザの装置１０８、コンテンツプロバイダの装置１０２、及び／又はこれらに類似したものの実施例を備える。例えば、システム１００は、パーソナルコンピュータ１０８ａ，１０８ｂ又はネットワークサーバーなどの汎用演算装置、或いは、セルラー電話機、パーソナルデジタルアシスタント、携帯型オーディオ又はビデオプレーヤ、テレビセットトップボックス、キオスク、ゲームシステム、又はこれらに類似したものなどの専用演算装置を備える。システム２００は、通常、プロセッサ２０２、メモリ２０４、ユーザインターフェイス２０６、着脱自在のメモリ２０８を受け付けるポート２０７、ネットワークインターフェイス２１０、及び前述の要素を接続するための１つ又は複数のバス２１２を含む。システム２００の動作は、通常、メモリ２０４（及び／又は、着脱自在のメモリ２０８などのその他のコンピュータ読取り可能な媒体）内に保存されたプログラムのガイダンスの下で動作するプロセッサ２０２によって制御される。メモリ２０４は、一般的には、高速ランダムアクセスメモリ（ＲＡＭ）と、磁気ディスク及び／又はフラッシュＥＥＰＲＯＭなどの不揮発性メモリとの両方を含む。メモリ２０４の一部を、システム２００のその他のコンポーネントによって読み取り又は書き込みできないように制限してもよい。ポート２０７は、ディスクドライブ、又はディスケット、ＣＤ−ＲＯＭ、ＤＶＤ、メモリカード、ＳＤカード、その他の磁気又は光媒体、及び／又はこれらに類似したものなどの着脱自在のメモリ２０８を受け入れるためのメモリスロットを有することができる。ネットワークインターフェイス２１０は、通常、インターネット又は（例えば、ＬＡＮ、ＷＡＮ、ＶＰＮなどの）イントラネットなどのネットワーク２２０を介してシステム２００とその他の演算装置の間の接続（及び／又は、演算装置のネットワーク）を提供し、且つ、そのような接続（例えば、無線、Ｅｔｈｅｒｎｅｔ（登録商標）、及び／又はこれらに類似したもの）を物理的に構成するために１つ又は複数の通信技法を利用することができる。一部の実施例においては、システム２００は、システム２００のユーザ又はその他のエンティティによる改竄から保護された処理ユニット２０３を包含することもできる。このような安全な処理ユニットは、鍵管理、署名検証、及びデジタル著作権管理プロセスのその他の側面などの機密操作のセキュリティを強化するのに有用である。

図２に示されているように、演算装置２００のメモリ２０４は、演算装置２００の動作を制御するための様々なプログラム及びモジュールを包含可能である。例えば、メモリ２０４は、通常、アプリケーション、周辺装置、及びこれらに類似したものの実行を管理するためのオペレーティングシステム２２１と、保護された電子コンテンツをレンダリングするためのホストアプリケーション２３０と、本明細書に記述されている著作権管理機能の一部又は全部を実装するためのＤＲＭエンジン２３２と、を包含する。本明細書の別の部分及び「’６９３号」出願に記述されているように、ＤＲＭエンジン２３２は、制御プログラムを実行するためのバーチャルマシン、状態情報を保存するための状態データベース２２４、及び／又は、コンテンツの暗号化及び／又は暗号解読、ハッシュ関数及びメッセージ認証コードの演算、デジタル署名の評価、及び／又はこれらに類似したものなどの暗号動作を実行するための１つ又は複数の暗号モジュール２２６などの様々なその他のモジュールを有し、これらと相互運用し、及び／又は、これらを制御することが可能である。メモリ２０４は、通常、保護されたコンテンツ２２８及び関連するライセンス２２９をも包含し、且つ、暗号鍵、証明書、及びこれらに類似したもの（図示せず）をも包含可能である。

図３は、演算装置２００よりも低い能力であり、及び／又は、低いデジタル著作権管理能力を有する演算装置３００の可能な１つの実施例の更に詳細な例を示す。例えば、システム３００は、セルラー電話機１０９ａ、パーソナルデジタルアシスタント１０９ｃ、携帯型オーディオ又はビデオプレーヤー１０９ｂ、テレビセットトップボックス、キオスク、ゲームシステム、又はこれらに類似したものを有することができる。システム３００は、通常、プロセッサ３０２、メモリ３０４、ユーザインターフェイス３０６、着脱自在のメモリを受け入れるポート３０７、ネットワークインターフェイス３１０、ＵＳＢインターフェイス３１１、及び前述の要素を接続するための１つ又は複数のバス３１２を含む。システム３００の動作は、通常、メモリ３０４内に保存されたプログラムのガイダンスの下で動作するプロセッサ３０２によって制御される。メモリ３０４は、一般的には、高速ランダムアクセスメモリ（ＲＡＭ）と、磁気ディスク及び／又はフラッシュＥＥＰＲＯＭなどの不揮発性メモリとの両方を含む。メモリ３０４の一部を、システム３００のその他のコンポーネントによって読み取り又は書き込みできないように制限してもよい。ＵＳＢインターフェイス３１１及び／又はネットワークインターフェイス３１０は、システム３００と、更に高い性能のＤＲＭ能力を具備するシステム２００などのシステムと、の間に接続を提供する。一部の実施例においては、システム３００は、システム３００のユーザ又はその他のエンティティによる改竄から保護された処理装置３０３を包含することもできる。

図３に示されているように、演算装置３００のメモリ３０４は、演算装置３００の動作を制御するための様々なプログラム及びモジュールを包含可能である。例えば、メモリ３０４は、通常、アプリケーション及びこれらに類似したものの実行を管理するためのオペレーティングシステム３２１と、保護された電子コンテンツを比較的簡単なライセンス３２９に従ってレンダリングするためのホストアプリケーション３３０と、を包含する。この代わりに又はこれに加えて、一部の実施例において、システム３００は、本明細書に記述されている著作権管理機能（及び、特に、テザード装置に関係した機能）の一部又はすべてを実装するための別個のＤＲＭエンジンを包含可能である。メモリ３０４は、通常、保護されたコンテンツ３２８、（更に詳しく後述する）装置記述文書３２７、並びに、暗号鍵、証明書、及びこれらに類似したもの（図示せず）をも包含可能である。

本明細書に記述されているシステム及び方法は、図２及び図３に示されているものに類似した又はこれと同一の演算装置により、或いは、図２及び／又は図３に示されているコンポーネントのいくつかを処理しない演算装置及び／又は図示されてはいない他のコンポーネントを処理する演算装置を含む仮想的な他の適切な演算装置により実施可能であることを、当業者は理解する。従って、図２及び図３は、例示のために提供されており、限定を意図したものではないことを理解されたい。

本明細書における説明は、ホストシステム及びテザード装置が意図したように動作した場合にライセンスの条件が強制されることになるという仮定の下に、主には、相対的に低い能力のＤＲＭを有する相対的に低い能力の装置及び／又は高い能力の装置（「テザード装置」と総称する）が、相対的に高い能力のホストシステムによって提供された関連するライセンス制限に従って、保護された電子コンテンツを安全に処理することを可能にするシステム及び方法に焦点を絞っている。本明細書に記述されているシステム及び方法を実際に適用する際には、セキュリティ技法の任意の適切な組み合わせを使用し、悪意のある改竄又は変更からホストシステム及びテザード装置（例えば、それぞれによって利用されているアプリケーション及びハードウェア）を保護可能である。例えば、「’６９３号」出願に記述されているように、例えば、暗号化、デジタル署名、デジタル証明書、メッセージ認証コード、及びこれらに類似したものなどの暗号メカニズムを利用し、ＤＲＭエンジン、ホストアプリケーション、及び／又はその他のシステムソフトウェア又はハードウェアを改竄及び／又はその他の攻撃から保護可能であり、ソフトウェア難読化、自己チェック、カスタマイズ、ウォーターマーキング、アンチデバッギング、及び／又はその他のメカニズムなどの構造的及び／又は戦術的なセキュリティ対策も同様に可能である。このような技法の代表的な例は、例えば、「Ｏｂｆｕｓｃａｔｉｏｎ Ｔｅｃｈｎｉｑｕｅｓ ｆｏｒ Ｅｎｈａｎｃｉｎｇ Ｓｏｆｔｗａｒｅ Ｓｅｃｕｒｉｔｙ」という名称の米国特許第６，６６８，３２５号、本譲受人に譲渡された第ＵＳ−２００５−０１８３０７２−Ａ１号として公開された「Ｓｏｆｔｗａｒｅ Ｓｅｌｆ−Ｄｅｆｅｎｓｅ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ」という名称の米国特許出願第１１／１０２，３０６号、第ＵＳ−２００８−００２８４７４−Ａ１号として公開された「Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｗａｔｅｒｍａｒｋｉｎｇ Ｓｏｆｔｗａｒｅ ａｎｄ Ｏｔｈｅｒ Ｍｅｄｉａ」という名称の米国特許出願第１１／７３７，４２８号、第ＵＳ−２００３−００２３８５６−Ａ１号として公開された「Ｓｏｆｔｗａｒｅ Ｓｅｌｆ−Ｃｈｅｃｋｉｎｇ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ」とい名称の米国特許出願第１０／１７２，６８２号、第ＵＳ−２００６−０１２３２４９−Ａ１号として公開された「Ｔｒｕｓｔｅｄ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ」という名称の米国特許出願第１１／３３８，１８７号、「Ｓｅｃｕｒｅ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ」という名称の米国特許第７，１２４，１７０号に記載されており、このそれぞれの内容は、本引用により、その全てが本明細書に包含される。或いは、この代わりに又はこれに加えて、セキュリティを更に強化するために、物理的なセキュリティ技法（例えば、相対的にアクセス不能なメモリ、安全なプロセッサ、安全なメモリ管理ユニット、ハードウェア的に保護されたオペレーティングシステムモード、及び／又はこれらに類似したもの）を使用することも可能である。システムの制度設計及び稼働により、且つ、その内部の参加者の法的及び社会的な規則により、更に別の形態のセキュリティを提供可能である。例えば、システム内のエンティティに対して、システムの仕様及び要件の遵守に合意するように契約書によって要求することも可能であり、システム要件をエンティティが遵守していることを検証可能な証明プロセスに従うように要求することも可能であり、及び／又は、これらに類似したものを実行可能である。例えば、装置又はアプリケーションに対して、環境内の他の実装と互換性を有するように、ＤＲＭエンジンを実装するために要求可能であり、及び／又は、特定のタイプ又はレベルの改竄に対する抵抗又はその他のセキュリティを提供するように要求可能である。このような要件に関する装置又はその他のエンティティによる遵守状況を証明したデジタル証明書を発行可能であり、且つ、それらの装置又はエンティティによるシステムへの参加を許容する前に、又はアクセスの継続を許容する条件として、これらの証明書を検証可能にすることができる。このようなセキュリティ技法については、当業者に周知であり、且つ、所望の保護のレベル及び／又は手元の特定のアプリケーションの詳細に応じて、これらの技法のいくつか又は全ての任意の適切な組み合わせを使用し、又はこれらをまったく使用しないことも可能であることを理解されたい。本明細書においては、特定の実施例との関連において特定のセキュリティメカニズムについて説明しているが、これらの技法の使用が全ての実施例において必要であるわけではないことをも理解されたい。本発明との関連において使用可能であるセキュリティ技法に関する更なる非限定的な情報は、「’６９３号」出願に記述されている。

以下、関連するライセンス制限に従って保護された電子コンテンツをテザード装置が安全に処理することを可能にする例示用のシステム及び方法について更に詳細に説明する。好適な実施例のグループにおいては、「’６９３号」出願に記述されているもの（本明細書及び「’６９３号」出願においては、しばしば、「Ｏｃｔｏｐｕｓ」ＤＲＭエンジンと呼称する）のようなＤＲＭエンジンを利用するＤＲＭシステムを使用している。例示用の実施例に関する以下の説明においては、しばしば、このようなＤＲＭエンジンを参照することになるが、この説明に示されている概念は、異なるタイプのＤＲＭシステムの状況においても容易に適用可能であることを理解されたい。

用語
本明細書においては、所定の好適な実施例の説明との関連において以下の用語が使用される。

「ＭＳＴＤ」とは、「Ｍａｒｌｉｎ Ｓｉｍｐｌｅ Ｔｅｔｈｅｒｅｄ Ｄｅｖｉｃｅ」の略号であり、ここで、「Ｍａｒｌｉｎ」は、「’６９３号」出願に記述されているＤＲＭエンジンの実施例を利用したＤＲＭシステムの一例である。

「ＭＳＴＤホスト」とは、本明細書に更に詳細に記述されているホスト拡張を伴う「’６９３号」出願に記述されているものなどのＤＲＭシステムを利用したホストシステムを意味する。

「ＭＳＴＤ装置」又は「テザード装置」とは、本明細書に記述されている機能の装置側の部分を実装した装置を意味する。尚、「テザード（ｔｅｔｈｅｒｅｄ)」装置という用語が使用されてはいるが、テザード装置は、ホストに対して永久的に又は物理的に接続される必要はないことを理解されたい。その代わりに、本明細書において使用されている「テザード（ｔｅｔｈｅｒｅｄ）」という用語は、テザード装置によって実行されるＤＲＭがホストによって実行されるＤＲＭから導出されたものである又はこれと関係しているという事実を意味している。

「バインディング」とは、ＵＳＢマスストレージなどの特定の技術に対する特定のプロトコル要素のマッピングを意味する。

「ペアリング」とは、ＭＳＴＤホストとＭＳＴＤ装置のようなホストと装置の関連付けを意味する。

概要
図４は、テザードシステム４０２（例えば、図１のシステム１０９又は図３のシステム３００のようなシステム）とやり取りするホストシステム４００（例えば、図１のシステム１０８又は図２のシステム２００のようなシステム）を示す。本明細書に記述されているシステム及び方法を使用することにより、ホスト４００が、使用規則及びコンテンツ鍵を１つ又は複数のオリジナルのライセンス４０４からエクスポートすると共に、１つ又は複数のオリジナルのライセンス４０４によって管理されたコンテンツ４０６を装置４０２が消費することを可能にする、オリジナルのライセンスにおいてコード化された使用規則の更に限定された表現を有する、非常に簡単なデータ構造４１０、４１２を生成することができる。ホスト４００は、（「’６９３号」出願に記述されているような）使用規則を表現するために使用されたコントロールから、装置４０２内における使用規則を表す簡単な有効性ステートメント（Ｓｉｍｐｌｅ Ｖａｌｉｄｉｔｙ Ｓｔａｔｅｍｅｎｔ：ＳＶＳ）レコード４１０を生成する。ホスト４００は、ホストＤＲＭシステム内のエンティティ間の関係を表現するために使用されたリンクから、ホストシステム内に存在するノードのグラフに似たノードのグラフの内部表現を装置が構築できるようにするリンク有効性ステートメント（Ｌｉｎｋ Ｖａｌｉｄｔｙ Ｓｔａｔｅｍｅｎｔ：ＬＶＳ）レコード４１２を生成する。

装置記述
図３及び図４に示されているように、好適な実施例においては、それぞれのテザード装置は、装置記述文書３２７を具備する。この文書は、バインディングパラメータを含む装置に関する静的な情報を含む。一実施例においては、ホストは、自身がディスカバリーフェーズにおいてペアになることを所望する装置の装置記述文書を見つける。ディスカバリーフェーズを実装する方法の詳細は、通常、ホスト及び装置によってサポートされている特定のバインディングに依存することになることを理解されたい。

一実施例においては、テザード装置に関する公開情報は、サポートされている仕様及びバインディングのバージョン並びに装置を表すＤＲＭノードオブジェクトに関する情報を含む。例えば、「’６９３号」出願に記述されているＤＲＭエンジンに基づいた一実施例においては、それぞれのテザード装置は、自身を表す対応するＤＲＭノードを具備する。このノードは、「パーソナリティ」タイプであり、且つ、サポートされたテザード装置であることを示す属性名を具備する。

図５は、一実施の形態における装置記述文書の一例を示す。図５に示されている装置記述文書は、アペンディックスＡとして添付されているスキーマに示された構文を具備するＸＭＬ文書である。図５に示されているように、一実施例においては、装置記述文書は、次のものを含む相対的に単純な構造を具備する。

＜Ｐｅｒｓｏｎａｌｉｔｙ＞：テザード装置を表すＤＲＭノード
＜ＴｒａｎｓｐｏｒｔＢｉｎｄｉｎｇｓ＞：サポートされているトランスポートバインディング
＜ＳｅｃｕｒｉｔｙＢｉｎｄｉｎｇｓ＞：サポートされているセキュリティバインディング

安全な認証チャネル
ホスト４００と装置４０２の間の一部の通信に対して、安全な認証チャネル（Ｓｅｃｕｒｅ Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｃｈａｎｎｅｌ：ＳＡＣ）を確立することが望ましい。例えば、状態変数を更新し、装置４０２上における信頼できる時刻を設定し、装置４０２上における証明書失効リストを更新し、及び／又は、これらに類似した内容を実行するために、ＳＡＣを使用することができる。チャネルが確立されたら、ホストは、要求メッセージを装置に対して送信し、且つ、応答メッセージを受信することができる。ＳＡＣは、機密性と、完全性と、リプレイ攻撃に対する保護と、を提供する。一実施例においては、一部のバインディングにおいて、装置が、基礎となる通信チャネルを開始できるとしても、ホストは、要求／応答交換を論理的に開始することができる。装置は、ホストに対する応答者である。好適な実施例においては、更に詳しく後述するように、安全な認証チャネルをＵＳＢ接続上に実装可能である。一般に、これは、使用されていないＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）コマンドを利用して装置とホストの間の通信を可能にすることにより実現可能である。

図６は、ホスト４００と装置４０２の間にＳＡＣ（例えば、ＵＳＢ上におけるトランスポートレイヤセキュリティ（ＴＬＳ）ＳＡＣ）を確立するためのプロセスを示すフローチャートである。図６に示されているように、ユーザは、装置をホストのＵＳＢポートに接続する（６０２）。次いで、ホストは、装置のＵＳＢマスストレージインターフェイスを通じてファイルシステムをマウントし、且つ、装置記述文書を見つけて解析する（６０４）。ホストは、装置記述をチェックし、且つ、自身が正しい拡張ＳＣＳＩコマンドを装置に対して送信することができるように、装置が互換性のあるＵＳＢマスストレージバインディングを実装するか否かを決定する（６０６）。装置が互換性のあるＵＳＢマスストレージバインディングを実装する場合には、ホストは、トランスポートレイヤセキュリティセッションを確立する（６０８）。この結果、ホストは、ＳＡＣ上において装置と通信することができる（６１０）。

図６に示されているブロック６０６、６０８及び６１０の一実施例においては、ホストは、ＧＥＴ＿ＤＥＳＣＲＩＰＴＯＲ ＵＳＢ要求を装置に対して送信することにより、特定のディスクリプタ（例えば、更に詳しく後述するストリングディスクリプタ２５５）を要求する。ディスクリプタが特定のＭＳＴＤ ＵＳＢディスクリプタとマッチングした場合に、ホストは、装置がＭＳＴＤコマンド用に使用するＳＣＳＩ ＣＢＤオペレーションコードに関する知識を得る。ホストは、ＴＬＳレコードを交換することにより、装置との間にＴＬＳセッションをセットアップし、且つ、ホストは、ＭＳＴＤ要求／応答レコードを交換することにより、装置と通信する。

ペアリング
一実施例においては、一意のホスト及び一意の装置のそれぞれのペアがペアリングを構成する。一実施例においては、それぞれのペアリングは、ペアリングＩＤを具備し、これは、ホストのパーソナリティノードＩＤ、オクテット０、及び装置のノードＩＤを連結したもののダイジェストの１２８個の最下位ビットに等しい１２８ビット値である（例えば、ｐａｒｉｎｇＩｄ＝Ｈ−１２８（ｈｏｓｔＩｄ｜０｜ｄｅｖｉｃｅＩｄ）である）。それぞれのペアリングは、関連するペアリング鍵をも具備する。ペアリング用のペアリング鍵は、ホストによって選択される。ホストと装置が通信する時期とは無関係にそれぞれのペアリングに同一のペアリング鍵を演算するという条件の下に、ホストは、任意の鍵をペアリングのために選択可能である。例えば、ホストは、ホストシークレットと連結されたｐａｉｒｉｎｇＩｄのダイジェストを演算することにより、ペアリング鍵を演算可能である。

図７は、ホストとテザード装置の間の新しいペアリングを確立するプロセスを示すフローチャートであり、これは、特定のホスト−装置ペアについてペアリングレコードを見つけることができない場合に実行される。図７に示されているように、ホスト及び装置は、（例えば、図６との関係において前述したように）安全な認証チャネルを確立する（７０２）。次に、ホストは、ペアリング鍵を装置に対して送信する（７０４）。テザード装置は、（例えば、テザード装置にのみ既知であるシークレット値によってコード化された鍵のような）コード化されたペアリング鍵により、これに応答する（７０６）。次いで、コード化されたペアリング鍵を、将来使用するためにペアリングレコード内に保存するが（７０８）、この例については、更に詳しく後述する。

ノード及びリンク
一実施例においては、装置のＤＲＭシステム（及び／又は、なんらかのＤＲＭ機能を実装する、装置上において稼働するプレーヤーアプリケーションなどのアプリケーション）は、「’６９３号」出願に記述されているノード及びリンクオブジェクトに類似したノード及びリンクを使用している。「’６９３号」出願に記述されているように、リンクを使用し、装置を表すノード及び任意の数のその他のノードとの間に経路を確立する。

一実施例においては、ノードは、１２８ビットのノード識別子を使用して参照される。「’６９３号」出願に記述されているタイプのノードに対応した（装置自体を表すノードなどの）ノードの場合には、ＵＴＦ−８−ｅｎｃｏｄｅｄ ＵＲＬである対応する完全なノードＩＤのＳＨＡ−１ダイジェスト値の最初の１２８ビットを取得することにより、短縮されたノード識別子を得ることが可能である。この変換を「ＨａｓｈＩｄ」と呼ぶこととする。

「’６９３号」出願に更に詳しく記述されているように、リンクは、「ｆｒｏｍ」ノードと「ｔｏ」ノードの間の経路を表す。リンクのコレクションは、グラフを表し、この場合に、それぞれのリンクは、２つのノードの間の有向の頂点（ｄｉｒｅｃｔｅｄ ｖｅｒｔｉｃｅ）である。ノードＮは、装置の独自のノードとノードＮの間に経路を生成するリンクの組が存在する場合に、到達可能（ｒｅａｃｈａｂｌｅ）であると表現される。

ホストからテザード装置へのライセンスのエクスポート
図８に示されているように、ホストが、テザード装置がファイルを使用することを可能にするために、保護されたファイルをテザード装置に送信することを所望するとき、ホストは、まず、ファイルと関連する１つ又は複数のライセンスを見つけ、且つ、このような動作がライセンスの条件によって許容されているか否かを決定する（８０２）。次いで、ホストは、ライセンスの簡略化されたバージョン（例えば、ＳＶＳ）と、必要に応じて、関連するリンクの簡略化されたバージョン（例えば、ＬＶＳレコード）と、を生成し（８０４）、且つ、これらの簡略化されたライセンス及びリンクをテザード装置に対して送信する（８０６）。この結果、更に詳しく後述するように、装置は、これらを使用し、保護されたコンテンツに対するアクセスを管理する。保護されたコンテンツ自体は、ライセンス及びリンクとは無関係に、（例えば、ホスト又はなんらかのその他のエンティティから）装置に対して送信可能である。複数のコンテンツ片を管理するために所定のライセンス（並びに、これから導出されたＳＶＳ及びＬＶＳレコード）を使用することができる。

図９は、「’６９３号」出願に記述されているようなＤＲＭシステムの状況において、ライセンスをホストからテザード装置（例えば、低い能力の装置及び／又は相対的にプリミティブな形態のＤＲＭを実装する装置）にエクスポートするプロセスの更に詳細なフローチャートである。図９を参照すると、ホストがファイルのライセンスを見つけると、ホストは、入力としてテザード装置のノード情報を提供することにより、ターゲットシステムをテザード装置のＩＤに設定した状態において、ライセンスの「Ｅｘｐｏｒｔ」メソッドを実行する（９０２）。次いで、ホストは、保護されたファイルのコンテンツ鍵を含むＳＶＳを生成し（９０３）、テザード装置のペアリング鍵を使用して暗号化する（９０４）。このＳＶＳは、コントロールによって返された拡張状態ブロック（ＥＳＢ）を使用して生成された条件の組（９０６）と、ペアリング鍵を使用して生成されたＳＶＳペイロードの署名（９０８）と、をも含む。ＳＶＳ内に含まれている条件の組が到達可能要件を含む場合には（即ち、ブロック９１０の「Ｙｅｓ」選択肢）、ホストは、適切なＬＶＳレコードを生成する（９１２）。一実施例においては、これには、装置のノードと関連のターゲットノード（例えば、ドメインノード）の間に経路を確立することができるＴｏＬＶＳメソッドをリンクオブジェクトに対して起動するステップが伴う。更に詳しく後述するように、一実施例においては、ＬＶＳレコードは、コントロールから返されたＥＳＢから生成された条件と、ペアリング鍵を使用して生成されたＬＶＳペイロードの署名と、を含む。

ＳＶＳ及びＬＶＳレコードの生成
既に説明したように、一実施例においては、ホストが、保護されたコンテンツを装置に対してエクスポートすることを所望する際には、ホストは、（例えば、「’６９３号」出願に記述されているタイプのライセンスなどの）適切なコンテンツライセンスのＥｘｐｏｒｔ操作を使用し、そのコンテンツライセンスに対応したＳＶＳ及びＬＶＳレコードを生成する。好適な実施例においては、ＳＶＳは、対応する保護されたコンテンツ片を利用するために満足されなければならないいくつかの条件を包含可能である。一部の実施例においては、これらの条件は、（ａ）コンテンツが使用される時刻（例えば、特定の時刻の前ではない、及び／又は、特定の時刻の後ではない）、（ｂ）ターゲット装置によってサポートされている又はその上部においてアクティブである出力のタイプ（例えば、レンダリングされたコンテンツを複写するための特定のインターフェイスがアクティブであるのか否か）、（ｃ）様々なノードの到達可能性（例えば、ドメインノード、加入ノード、及び／又はこれらに類似したもの）、及び／又は、（ｄ）様々な状態の値（例えば、クラブにおけるメンバーシップを示す状態や特定の動作の以前の性能など）に関係する条件を包含可能である。他の実施例において、条件のその他の組を使用可能であることを理解されたい。
一実施例においては、ホストは、次の動作パラメータをＥｘｐｏｒｔ操作に対する引数として提供する。

Ｅｘｐｏｒｔが許可された場合には（例えば、それ自体が特定のターゲット装置に対してエクスポートされることをライセンスが許容している場合）、ライセンスのコントロールから返されるＥＳＢは、次の情報を含むことになる。

条件コンストラクタは、ＶａｌｕｅＬｉｓｔタイプであり、リスト内のそれぞれの値は、パラメータタイプである。一実施例においては、次のパラメータが定義されている。

ホストは、エクスポート対象のライセンスに対応するＳＶＳレコードの「ｖａｌｉｄｉｔｙ」フィールドを生成するために条件コンストラクタを使用する。「ｖａｌｉｄｉｔｙ」フィールドは、条件レコードである。

ホストは、条件コンストラクタのフィールドを使用し、条件レコードを次のように生成する。

条件レコードの「ｎｏｔＢｅｆｏｒｅ」及び「ｎｏｔＡｆｔｅｒ」フィールドをコンストラクタの「ＮｏｔＢｅｆｏｒｅ」及び「ＮｏｔＡｆｔｅｒ」パラメータの値に設定する。

コンストラクタが「ｓｔａｔｅｓ」パラメータを具備する場合、条件レコードの「ｓｔａｔｅｓ」フィールドは、ＳｔａｔｅＩｄＢｌｏｃｋ値のリストから得られたタプルのリストである。そうでない場合、条件レコードの「ｓｔａｔｅｓ」フィールドは、空のリストである。

コンストラクタが「ＭｕｓｔＲｅａｃｈＮｏｄｅ」パラメータを具備する場合、条件レコードの「ｎｏｄｅｓ」フィールドは、ＨａｓｈＩｄ関数を使用してリスト内のそれぞれのストリングを１２８ビットの識別子に変換することによりこのパラメータの値から生成された１２８ビットのノード識別子のリストである。そうでない場合、条件レコードの「ｎｏｄｅｓ」フィールドは、空のリストである。

コンストラクタが「ＯｕｔｐｕｔＣｏｎｔｒｏｌ」パラメータを具備する場合、ｏｕｔｐｕｔＣｏｎｔｏｒｌＶａｌｕｅ及びｏｕｔｐｕｔＣｏｎｔｒｏｌＭａｓｋフィールドは、パラメータから得られる。そうでない場合、ｏｕｔｐｕｔＣｏｎｔｒｏｌＶａｌｕｅ及びｏｕｔｐｕｔＣｏｎｔｒｏｌＭａｓｋフィールドは、０に設定される。

ＬＶＳは、リンクオブジェクトから構築される。（例えば、無条件に有効であるために）コントロールを具備しないリンクの場合には、対応するＬＶＳは、制約レコードを具備し、この場合には、ｎｏｔＢｅｆｏｒｅフィールドは、０に設定され、ｎｏｔＡｆｔｅｒフィールドは、２＾３２−１に設定され、且つ、ｎｏｄｅｓ及びｓｔａｔｅｓフィールドは、空のリストである。

コントロールを具備するリンク（例えば、その有効性が特定の条件に依存しているリンク）の場合には、ホストは、リンクオブジェクトのコントロール内の特定のメソッドを呼び出すことにより、対応するＬＶＳレコードのフィールドを取得する。例示用の一実施例においては、メソッド名は、Ｃｏｎｔｒｏｌ．Ｌｉｎｋ．Ｃｏｎｓｔｒａｉｎｔ．ＴｏＬＶＳであり、次の特徴を具備する。
入力：なし
出力：スタック上においてＲｅｓｕｌｔＣｏｄｅ及びＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒを返す。

ＲｅｓｕｌｔＣｏｄｅは、整数値である。結果値は、ルーチンが稼働することができなかった場合にはゼロであり、エラーが発生した場合には負のエラーコードである。成功ＲｅｓｕｌｔＣｏｄｅ（０）は、制約が満足されたことを意味しないことに留意されたい。これは、ルーチンがエラーを伴うことなしに稼動することができたことを意味するのみである。制約が満足されるか否かを示すものは、ＳｔａｔｕｓＢｌｏｃｋである。

ＳｔａｔｕｓＢｌｏｃｋＰｏｉｎｔｅｒは、（例えば、「’６９３号」出願に記述されているように）標準ＥｘｔｅｎｄｅｄＳｔａｔｕｓＢｌｏｃｋのアドレスである。

一実施例においては、ＲｅｓｕｌｔＣｏｄｅがゼロでない場合には、ＤＲＭエンジンは、そのリンクを表すためにＬＶＳレコードを生成することができないと見なす。

ＬＶＳへの変換を許容する場合には、コントロールは、次のパラメータを利用し、ＥＳＢ内においてＬＶＳ記述を返す。

ＬＶＳコンストラクタは、ＶａｌｕｅＬｉｓｔタイプであり、好ましくは、前述のＳＶＳコンストラクタと同一の構造を具備する。

図１０は、ＤＲＭライセンス１００６及びリンクオブジェクト１００８ａ、１００８ｂからのＳＶＳ１００２及びＬＶＳレコード１００４ａ、１００４ｂの生成を示す。図１０に示されている擬似コード例においては、ライセンス１００６は、ライセンスが対応しているコンテンツに対して装置がアクセス可能となるためには、特定のノード（例えば、コンテンツプロバイダのサービスへのユーザの加入と関連したノード「ｓｕｂ」）が到達可能でなければならないという要件を含んでいる。ホストは、テザード装置から加入ノードへの経路を確立するリンクの組１００８ａ、１００８ｂを具備してはいるが、リンク１００８ｂは、リンク１００８ｂに含まれた又はこれによって参照された制御コードによって決定される特定の日付までしか有効ではない。ライセンスのＥｘｐｏｒｔメソッドは、テザード装置がメータリングをサポートしている場合には、満了日を含まないＳＶＳを生成可能であるが、そうでない場合、満了日を包含しなければならないことを示している。この代わりに又はこれに加えて、ライセンスは、エクスポートの許可を付与する際に、ターゲット装置が特定の出力制御条件を満足すること（例えば、特定タイプの出力が、無効になる、無効になることができる、又は存在しない）などのその他の条件を強制することも可能である。ターゲット装置へのエクスポートに対する条件が満足された場合には、ＳＶＳ１００２及びＬＳＶレコード１００４ａ、１００４ｂが生成される。ＳＶＳ１００２は、暗号化されたコンテンツ暗号解読鍵（Ｅ（ｋ））と、（例えば、そのＨａｓｈＩＤを使用して）ノードｓｕｂを識別する条件レコードと、デジタル署名と、を含む。この例においては、装置がメータリングをサポートしていると仮定されており、従って、ＳＶＳには、時間制限が課せられてはいない。ＳＶＳ１００２がノード「ｓｕｂ」を識別しているため、ＬＶＳレコード１００４ａ、１００４ｂは、リンク１００８ａ、１００８ｂ内のＬＶＳコンストラクタを使用して生成される。ＬＶＳレコード１００４ａは、ユーザノードｕｌが装置のノードから到達可能であることを示しており、装置がユーザのドメインに属することを示す状態オブジェクトを装置が具備する場合にのみリンクが有効であることを示す条件レコードをも含む。この例においては、ＬＶＳ内におけるこの条件の包含は、リンク１００８ａ内のＬＶＳコンストラクタによって管理される。同様に、ＬＶＳレコード１００４ｂは、加入ノードがユーザノードｕｌから到達可能であるが、現在の日付が指定された終了日付よりも前である場合にのみリンクが有効であることを示している。従って、この例においては、ターゲット装置は、所望のノードに対する経路を確立可能であり、それぞれのＬＶＳレコードが有効であると仮定した場合には（例えば、加入に対するリンクが満了しておらず、且つ、装置が、依然としてユーザのドメインの一部であるため）、ＳＶＳ１００２内に含まれている条件は、満足される。好適な実施例においては、ＳＶＳは、ターゲット装置上のデータベース（ｓｖｓ．ｄｂ）内に保存され、所与のコンテンツ片の適切なＳＶＳの検出を促進する情報を含む別のデータベース（ｓｖｓｌｏｃ．ｄｂ）も維持される。

クライアント再生
簡略化されたライセンス（例えば、前述の１つ又は複数のＬＶＳ及び／又はＳＶＳ）を受け取る際に、クライアントは、簡略化されたラインセスと関係するコンテンツの再生を開始することができる。

図１１は、保護されたファイル内に含まれる保護されたコンテンツ片を再生（又は、そうでない場合、レンダリング）するためにクライアントによって実行される例示用の一連の動作を示す。図１１に示されているように、装置は、ファイルを開き（１１０２）、且つ、１つ又は複数のコンテンツＩＤを取得するためにファイルを解析する。説明のために、ファイルは、２つのストリーム（ＣＩＤ０、ＣＩＤ１）を有するものと仮定する。装置は、ｓｖｓｌｏｃ．ｄｂを使用し、それらのコンテンツＩＤのＳＶＳのＳＶＳ ＩＤを見つけ、次いで、ｓｖｓ．ｄｂを使用し、そのＳＶＳ ＩＤのＳＶＳレコードを見つける（１１０４）。次いで、装置は、ＳＶＳを解析し、ＳＶＳの署名を検証する（１１０６）。一実施例においては、これには、ＳＶＳ署名からＳＶＳペアリングｉｄを取得するステップと、ｐａｉｒｉｎｇ．ｄｂを使用し、このＳＶＳのペアリングレコードを見つけるステップと、このペアリングのペアリング鍵値（ＰＫ０）を演算するステップと、このペアリング鍵を使用してＳＶＳ署名を検証するステップと、を伴う。

再度図１１を参照すれば、装置は、次いで、（例えば、ＳＶＳの「ｖａｌｉｄｉｔｙ」フィールドをチェックし、且つ、その中に表現されている状態を評価することによって）ＳＶＳが有効であるか否かを決定し、ＳＶＳが有効である場合には（即ち、ブロック１１０８の「Ｙｅｓ」選択肢）、それぞれのコンテンツＩＤの暗号化されたコンテンツ鍵（即ち、ＥＫ０、ＥＫ１）を取得し、これらの鍵をＰＫ０によって暗号解読してコンテンツ鍵値（Ｋ０、Ｋ１）を取得し（１１１０）、且つ、ＯｕｔｐｕｔＣｏｎｔｒｏｌフィールドに従って出力制御を設定する。この段階で、装置は、コンテンツに対するアクセスを提供する準備が整う（１１１２）。

図１２は、コンテンツ片に対するアクセス又はコンテンツ片の他の使用がＳＶＳによって許容されるか否かを決定するプロセスを示すフローチャートである。図１２に示されているように、これには、ＳＶＳ内に含まれている様々な条件が満足されるか否かをチェックするステップが伴う。図１２に示されている例においては、これには、現在時刻をｎｏｔＢｅｆｏｒｅ及びｎｏｔＡｆｔｅｒフィールドと比較するステップと（１２０２）、現在時刻が許容された範囲外である場合に、ファイルへのアクセスを拒絶するステップと、が伴う。また、「ｓｔａｔｅｓ」リスト内に一覧表示されている状態をチェックしてそれらが満了しているか否かを確認し（１２０４）、それらが満了している場合には、アクセスを拒絶する。更には、ＳＶＳの「ｎｏｄｅｓ」リスト内のすべてのノードが到達可能であるか否かに関する決定を実行する（１２０６）。これには、例えば、リスト内のそれぞれのノードについて、（ｉ）そのノードと装置のノードの間のすべての経路を決定するためにｌｖｓ．ｄｂ内のＬＶＳレコードを使用するステップと、（ｉｉ）それぞれの経路について、（ａ）経路のＬＶＳレコードの署名をチェックするステップと、（ｂ）それぞれのＬＶＳレコードの条件フィールドがその経路が有効であることを示していることを検証するステップと、を実行するステップが伴う可能性がある。すべての署名が検証され、且つ、すべてのリンクが有効である場合には、ノードは、到達可能である。ＳＶＳによって規定されている条件が満足された場合に、ファイルへのアクセス又はファイルの他の使用の要求を認可することができる（１２０８）。

以下、「’６９３号」出願に記述されているＤＲＭエンジンを利用した例示用の実施例において使用される様々なデータ構造、プロトコル、表記規則、及び実装固有のパラメータに関する詳細について説明する。尚、これらの詳細は、例示のために提供されるものであって、限定を意図したものではなく、且つ、本発明の実施例は、これらの詳細なプロトコル、データ構造、表記規則、及びその他の実装固有のパラメータの一部のみを利用することも可能であり、或いは、これらをまったく利用しないことも可能であることを理解されたい。

データ構造
一実施の形態においては、以下のデータ構造、用語、及び表記規則が使用されている。

データタイプ
本明細書において使用されるアブストラクトタイプ表記は、次の構文を具備する。

＜ｎａｍｅ＞： ＜ｔｙｐｅ＞、ここで、＜ｔｙｐｅ＞は、単一値の場合には、＜ｖａｌｕｅ−ｔｙｐｅ＞（ｓｉｚｅ−ｉｎ−ｂｉｔｓ）の形態であり、値のアレイの場合には、＜ｖａｌｕｅ−ｔｙｐｅ＞（ｓｉｚｅ−ｉｎ−ｂｉｔｓ）［ａｒｒａｙ−ｓｉｚｅ］の形態であり、複合データ構造の場合には、｛．．．｝の形態である。

＜ｔｙｐｅ＞［ｎ］という表記は、＜ｔｙｐｅ＞タイプの＜ｎ＞個の要素のアレイを意味する。＜ｔｙｐｅ＞［］という表記は、＜ｔｙｐｅ＞タイプの可変数の個数の要素を有するアレイを意味する。

以下の様々な例示用の実施例の説明においては、整数値は、ビッグエンディアンバイト順（これは、ネットワークバイト順とも呼称される）を使用してコード化されているものと仮定され、すべてのビットベクトルは、ビッグエンディアンバイト順において８ビットバイトの倍数となる。又、特記していない限り、時刻及び日付の値は、１９７０年１月１日の００：００：００ＵＴＣ以降に経過した分の数を表す３２ビットの符号なし整数として表現されるＵＴＣ日付となる。これらの表記規則は、例示を目的とし、且つ、本発明の明瞭な説明を円滑に実行するために使用されるものであり、本発明は、これらの例示用のエンコーディングに限定されるものではないことを理解されたい。任意の適切なエンコーディング表記規則並びに時刻及び日付のフォーマットを使用可能である。

アトム（Ａｔｏｍ）
アトムとは、いくつかの特定のデータ構造のベースとして機能する簡単なカプセル化データ構造である。アトムは、サイズ、タイプ、及びペイロードを具備する。一実施例においては、アトムのサイズは、ビッグエンディアンバイト順において３２ビットの符号なし整数としてコード化され、且つ、サイズ及びタイプをコード化するために使用される８バイトのヘッダを含むアトムの全体サイズを表している。タイプは、ビッグエンディアンバイト順における３２ビットの識別子である。表記規則により、アトムタイプの３２ビット識別子は、４文字ワードとして表記され、ここで、それぞれの文字の８ビットＡＳＣＩＩコードは、識別子の対応する８ビットバイトの部分である。例えば、識別子の値０ｘ６１７４６ｆ６ｄ（１６進）は、「ａ」のＡＳＣＩＩコードが０ｘ６１であるため、「ａｔｏｍ」と表記される。

ＥｎｃｒｙｐｔｅｄＤａｔａ
ＥｎｃｒｙｐｔｅｄＤａｔａレコードは、暗号化鍵及びアルゴリズムに関する暗号化されたデータ及び情報を含む。

ここで、「ａｌｇｏｒｉｔｈｍＩｄ」は、データを暗号化するために使用された暗号化アルゴリズムの識別子である。一実施例においては、以下のアルゴリズム識別子が定義されている。

「ＫｅｙＩｎｆｏ」は、データを暗号解読するために必要な鍵を識別する。

「ｃｉｐｈｅｒＤａｔａＳｉｚｅ」は、暗号化されたデータのサイズ（単位：バイト）である。

「ｃｉｐｈｅｒＤａｔａ」は、暗号化されたデータである。

「ＫｅｙＩｎｆｏ」レコードは、鍵を一意に識別するのに必要な情報を含む。

「ｋｅｙＩｄＴｙｐｅ」は、ｋｅｙＩｄ識別子が参照するものを規定する。一実施例においては、少なくとも次のタイプが定義されている。

「ｋｅｙｅｄ」は、一意の鍵識別子である。

Ｓｉｇｎａｔｕｒｅ
Ｓｉｇｎａｔｕｒｅレコードは、なんらかのデータペイロードの署名と、署名鍵及びアルゴリズムに関する情報と、を含む。

ここで、「ａｌｇｏｒｉｔｈｍＩｄ」は、データに署名するために使用された署名アルゴリズムの識別子である。一実施例においては、少なくとも次のアルゴリズム識別子が定義されている。

「ｋｅｙＩｎｆｏ」は、データに署名するために使用された鍵を識別する。

「ｓｉｇｎａｔｕｒｅＤａｔａＳｉｚｅ」は、署名データのサイズ（単位：バイト）である。

「ｓｉｇｎａｔｕｒｅＤａｔａ」は、署名データである。

Ｃｏｎｄｉｔｉｏｎｓレコード
Ｃｏｎｄｉｔｉｏｎｓレコードは、基本的な有効性条件を表す。

このレコード内のそれぞれのフィールドは、個別のサブ条件である。条件は、そのすべてのサブ条件が満足された場合にのみ満足される。

ここで、「ｎｏｔＢｅｆｏｒｅ」は、現在の日付が指定された日付以降である場合にのみ満足されるサブ条件である。

「ｎｏｔＡｆｔｅｒ」は、現在の日付が指定された日付以前である場合にのみ満足されるサブ条件である。

「ｎｏｄｅｓ」は、ゼロ個以上のノードＩＤのリストである。この例示用の実施例においては、それぞれのノードＩＤは、１２８ビットの識別子である。このサブ条件は、一覧表示されたＩＤを有するすべてのノードが到達可能である場合にのみ満足される。

「ｓｔａｔｅｓ」は、ゼロ個以上の状態ＩＤのリストである。それぞれの状態ＩＤは、（ｇｉｄ，ｖｉｄ）というタプルであり、ここで、ｇｉｄ及びｖｉｄは、いずれも、１２８ビットの識別子である。状態ＩＤは、状態オブジェクトを一意に識別する。このサブ条件は、リスト内のすべての状態オブジェクトが存在し、且つ、満了していない場合にのみ満足される。

ＳＶＳレコード
ＳＶＳレコードは、Ｓｉｍｐｌｅ Ｖａｌｉｄｉｔｙ Ｓｔａｔｅｍｅｎｔを表しており、コンテンツＩＤと関連する１つ又は複数の鍵に適用される使用規則を表現するために使用される。

一実施例においては、ＳＶＳレコードは、次のデータ構造を具備する。

ここで、「ｓｖｓＩｄ」は、ＳＶＳレコードの一意の識別子である。

「ｋｅｙＣｏｕｎｔ」は、ｋｅｙｓアレイ内の鍵の数である。

「ｋｅｙｓ」は、１つ又は複数のＥｎｃｒｙｐｔｅｄＫｅｙレコードのアレイである。それぞれのＥｎｃｒｙｐｔｅｄＫｅｙレコードは、ペアリング鍵によって暗号化されたコンテンツＩＤ及び対応するコンテンツ鍵を含む。

「ｕｓａｇｅＲｕｌｅ」は、ＳＶＳ内において搬送される鍵の使用を管理する規則の記述である。一実施例においては、鍵を使用するためには、有効性条件が満足されなければならないと共に、出力制御要件も実現されなければならない。

「ｏｕｔｕｐｔＣｏｎｔｒｏｌＶａｌｕｅ」は、ゼロ個以上の出力制御フィールドの値を示すビットフィールドである。一実施例においては、フィールドは、次のようにコード化されている。

「ｏｕｔｐｕｔＣｏｎｔｒｏｌＦｌａｇｓ」は、ｏｕｔｐｕｔＣｏｎｔｒｏｌＶａｌｕｅにおいて通知されるフィールドを示すフラグのビットベクトルである。フィールドのビットフラグが１に設定されているときには、それは、ｏｕｔｐｕｔＣｏｎｔｒｏｌＶａｌｕｅ内のその対応するフィールドが通知されることを示す。一実施例においては、通知されないｏｕｔｐｕｔＣｏｎｔｒｏｌＶａｌｕｅのフィールドのビットは、０に設定されている。

「ｓｉｇｎａｔｕｒｅ」は、レコードのペイロード部分の署名である。

ＬＶＳレコード
ＬＶＳレコードは、Ｌｉｎｋ Ｖａｌｉｄｉｔｙ Ｓｔａｔｅｍｅｎｔを表している。リンクは、「ｆｒｏｍ」ノードと「ｔｏ」ノードの間の経路を表す。

一実施例においては、ＬＶＳレコードは、次のデータ構造から構成されている。

ここで、「ｆｒｏｍ」は、ノード識別子である。

「ｔｏ」は、ノード識別子である。

「ｖａｌｉｄｉｔｙ」は、このＬＶＳが有効と見なされるために満足されなければならない制約を決定する条件レコードである。

「ｓｉｇｎａｔｕｒｅ」は、レコードのペイロード部分の署名である。

ＦｉｌｅＬｏｃａｔｏｒレコード
ＦｉｌｅＬｏｃａｔｏｒレコードは、ＳＶＳを、そのＳＶＳが生成される元となったファイルの名前と関連付けている。

一実施例においては、ＦｉｌｅＬｏｃａｔｏｒレコードは、次のデータ構造を具備する。

ここで、「ｓｖｓＩｄ」は、ＳＶＳ ＩＤである。

「ｆｉｌｅＮａｍｅＳｉｚｅ」は、ｆｉｌｅＮａｍｅ内の文字の数である。

「ｆｉｌｅｎａｍｅ」は、そのファイルが配置されているファイルシステムのルートとの関係におけるファイルの名前である。

ＳｖｓＬｏｃａｔｏｒレコード
ＳｖｓＬｏｃａｔｏｒレコードは、コンテンツＩＤを、そのコンテンツＩＤを有するＥｎｃｒｙｐｔｅｄＫｅｙを含むＳＶＳと関連付けている。

一実施例においては、ＳｖｓＬｏｃａｔｏｒレコードは、次のデータ構造を具備する。

ここで、「ｃｏｎｔｅｎｔＩｄ」は、コンテンツＩＤである。

「ｓｖｓＩｄ」は、ＳＶＳ ＩＤである。

Ｄａｔａアトム
Ｄａｔａアトムは、一般的なデータペイロードをコード化するために使用される。

ここで、「ｐａｙｌｏａｄ」は、ゼロ個以上のペイロードバイトを意味する。

ペアリングレコード
ペアリングレコードは、予め共有されたペアリング鍵を装置及びホストが演算することを可能にする情報を含む。ペアリング鍵は、コンテンツ鍵を暗号化すると共にその他のレコードに署名するために使用される。

ホストが装置に遭遇し、且つ、このホスト−装置ペアのペアリングレコードが存在しないときには、ホストは、ペアリングレコード内に保存するペイロードを装置から入手し、そのペアリングレコードをペアリングレコードデータベース内に挿入する。ペアリングレコード内のペアリング鍵は、装置によってコード化される（通常は、これは、その他のエンティティとは絶対に共有されない装置秘密鍵によって暗号化されることを意味する）。装置が単一の装置秘密鍵によって暗号化することによってすべてのペアリング鍵をコード化することを選択した場合には、装置は、非対称暗号操作を実行することなしに、すべてのペアリング鍵の値を演算可能である。

装置と通信する際に、ホストは、ＳｅｔＰａｉｒｉｎｇＫｅｙ要求の応答として、現在のペアリングのＥｎｃｏｄｅｄＰａｉｒｉｎｇＫｅｙの値を入手する。

Ｒｅｑｕｅｓｔレコード
Ｒｅｑｕｅｓｔレコードは、ホストから装置への要求をコード化している。

ここで、「ｃｏｍｍａｎｄＩｄ」は、実行対象のコマンドの識別子であり、「ｃｏｍｍａｎｄＰａｒａｍｅｔｅｒｓ」は、コマンドのパラメータを含むゼロ個以上のアトムを意味する。

一実施例においては、次のコマンドが定義されている。

Ｒｅｓｐｏｎｓｅレコード
Ｒｅｓｐｏｎｓｅレコードは、装置からホストへの応答をコード化している。

ここで、「ｓｔａｔｕｓ」は、この応答が対応する要求が成功したか又は失敗したかを示す状態コードであり、「ｒｅｓｐｏｎｓｅＥｌｅｍｅｎｔｓ」は、応答データを含むゼロ個以上のアトムを意味する。アトムは、応答状態と関係するテキスト情報を含むＩｎｆｏアトムを包含可能である。一実施例においては、次の状態コードが定義されている。

メッセージ
一実施例においては、ホスト及び装置は、要求／応答パターンを使用して通信を行う。要求を送信するエンティティは、要求者であり、要求を受信すると共に応答を返送するエンティティは、応答者である。この文脈においては、通常、ホストが要求者であり、装置が応答者である。要求者によって送信されたそれぞれの要求について、応答者は、応答を返送するが、この応答は、要求が成功裏に受信及び処理されたことを通知する正常な応答であるか、又はエラーの発生を通知する応答であってよい。

一実施例においては、応答者は、自身が理解できないコマンドを有する要求を受信した場合には、ＥＲＲＯＲ＿ＮＯＴ＿ＵＮＤＥＲＳＴＯＯＤ状態コードによって応答する。応答者は、自身が理解するがサポートしてはいないコマンドを有する要求を受信した場合には、ＥＲＲＯＲ＿ＮＯＴ＿ＳＵＰＰＯＲＴＥＤ状態コードによって応答する。応答者は、要求のフォーマット内にエラーを検出した場合には、ＥＲＲＯＲ＿ＰＲＯＴＯＣＯＬ＿ＦＡＩＬＵＲＥによって応答する。

要求者は、自身が理解できない状態コードを有する応答を受信した場合には、それを障害状態として取り扱い、その要求が成功しなかったものと仮定する。要求者は、自身が理解するが必須の応答要素に加えて自身が理解しないいくつかの応答要素を含む状態コードを有する応答を受信した場合には、それらの余分な応答要素を無視する。

セキュリティデータの更新
ホストは、装置のセキュリティデータの問合せ又は更新を実行することができる。セキュリティデータは、信頼できる時刻の値を含む。

信頼できる時刻の値は、１９７０年１月１日の００：００：００ＵＴＣ以降に経過した秒の数として表現されるＵＴＣ時刻値である。

次のコマンドが、この目的のために使用される。

ＧｅｔＴｒｕｓｔｅｄＴｉｍｅ
要求：
ｃｏｍｍａｎｄＩｄ： ＣＭＤ＿ＧＥＴ＿ＴＲＵＳＴＥＤ ＴＩＭＥ
パラメータ：なし
応答：

ここで、「ｔｉｍｅ」は、応答者の信頼できる時刻の値である。
説明：装置の信頼できる時刻を取得する。
ｓｅｔＴｒｕｓｔｅｄＴｉｍｅ
要求：
ｃｏｍｍａｎｄＩｄ： ＣＭＤ＿ＳＥＴ＿ＴＲＵＳＴＥＤ＿ＴＩＭＥ
パラメータ：次のデータを含む単一のＤａｔａアトム

ここで、「ｔｉｍｅ」は、応答者がその信頼できる時刻を更新しようとする変更後の時刻値である。
応答：
ｒｅｓｐｏｎｓｅＥｌｅｍｅｎｔｓ：なし
説明：装置の信頼できる時刻を設定する。
ｇｅｔＣｒｌＮｕｍｂｅｒ
要求：
ｃｏｍｍａｎｄＩｄ：ＣＭＤ＿ＧＥＴ＿ＣＲＬ＿ＮＵＭＢＥＲ
パラメータ：なし
応答：
ｒｅｓｐｏｎｓｅＥｌｅｍｅｎｔｓ：次のデータを含む単一のＤａｔａアトム

ｃｒｌ＿ｎｕｍｂｅｒ：例えば、「Ｉｎｔｅｒｎｅｔ Ｘ．５０９ Ｐｕｂｌｉｃ Ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ − Ｃｅｒｔｉｆｉｃａｔｅ ａｎｄ Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｖｏｃａｔｉｏｎ Ｌｉｓｔ （ＣＲＬ） Ｐｒｏｆｉｌｅ」（ＩＥＴＦ ＲＦＣ３２８０、２００２年４月）に規定されているＡＳＮ．１ ＩＮＴＥＧＥＲとしてコード化されたＣＲＬ数を表すバイトアレイである。
説明：装置の現在のＣＲＬ数を取得する。
ＳｅｔＣｒｌＮｕｍｂｅｒ
要求：
ｃｏｍｍａｎｄＩｄ： ＣＭＤ＿ＳＥＴ＿ＣＲＬ＿ＮＵＭＢＥＲ
パラメータ：次のデータを含む単一のＤａｔａアトム

ここで、ｃｒｌ＿ｎｕｍｂｅｒは、ＲＦＣ３２８０に規定されているＡＳＮ．１ ＩＮＴＥＧＥＲとしてコード化されたＣＲＬ数を表すバイトアレイである。
応答：
ｒｅｓｐｏｎｓｅＥｌｅｍｅｎｔｓ：なし
説明：
装置のＣＲＬ数を設定する。一実施例においては、装置は、そのＣＲＬ数の現在値よりも小さいＣＲＬ数を拒絶しなければならない（且つ、ＦＡＩＬＵＲＥを返さなければならない）。

図１３は、テザード装置のセキュリティデータを更新するためにホストによって実行可能な例示用のプロセスを示す。図示のように、ホストは、装置との間に安全な認証チャネルを確立する（１３０２）。次いで、ホストは、例えば、ＳｅｔＴｒｕｓｔｅｄＴｉｍｅコマンドを使用することによって装置の時刻を更新し（１３０４）、装置が最新のＣＲＬを具備することをチェックすることができる（１３０６）。装置が最新のＣＲＬを具備していない場合には（即ち、ブロック１３０６の「Ｎｏ」選択肢）、ホストは、（例えば、ｃｒｌ．ｂｉｎ内において）装置のＣＲＬを更新することができる（１３０８）。

装置の状態
装置は、状態オブジェクトの組を管理する。これらのオブジェクトは、好ましくは、改竄することができないように、且つ、システムの仕様によって許容されたもの以外の状態オブジェクトを生成、削除、又は変更することができないように管理される。

一実施例においては、それぞれの状態は、グループＩＤ、値ＩＤ、値、及び任意選択の満了日付を具備する。値は、３２ビットの符号なし整数である。

一実施例においては、装置は、状態オブジェクトの存在の有無をチェックすることしか必要としない。装置は、ホスト要求によって指示されない限り、状態オブジェクトを生成又な削除せず、且つ、装置は、ホスト要求によって指示されない限り、状態オブジェクト値を判読又は変更しない。但し、装置は、状態オブジェクトの満了日付を利用し、それらの値の保存と関連した内部リソースを解放することができる。例えば、満了した状態オブジェクトは、装置によってガベージコレクト可能である。

ホストは、コマンド要求を装置に送信することにより、装置内に保存されている状態オブジェクトの値を生成、削除、判読、及び変更可能である。

一実施例においては、状態管理のために次のコマンドが使用されている。

ＧｅｔＳｔａｔｅＯｂｊｅｃｔＢｙＩｄ
要求：
ｃｏｍｍａｎｄＩｄ： ＣＭＤ＿ＧＥＴ＿ＳＴＡＴＥ＿ＯＢＪＥＣＴ＿ＢＹ＿ＩＤ
パラメータ：次のデータを含む単一のＤａｔａアトム

応答：
ｒｅｓｐｏｎｓｅＥｌｅｍｅｎｔｓ：要求されたｇｉｄ及びｖｉｄを有するオブジェクトを具備する場合には、装置は、次のデータを含む単一のＤａｔａアトムを返す。

説明：装置によって管理されている状態オブジェクトの値及び満了日付を取得する。要求されたｇｉｄ及びｖｉｄを有する状態オブジェクトを具備していない場合には、装置は、ＥＲＲＯＲ＿ＮＯ＿ＳＵＣＨ＿ＩＴＥＭに設定された状態フィールドを有する応答を返す。
ＧｅｔＳｔａｔｅＯｂｊｅｃｔＢｙＩｎｄｅｘ
要求：
ｃｏｍｍａｎｄＩｄ：ＣＭＤ＿ＧＥＴ＿ＳＴＡＴＥ＿ＯＢＪＥＣＴ＿ＢＹ＿ＩＮＤＥＸ
パラメータ：次のデータを含む単一のＤａｔａアトム

ここで、「ｇｉｄ」は、要求された状態オブジェクトのグループＩＤである。
「ｉｎｄｅｘ」は、要求されたｇｉｄを有する状態オブジェクトの中の１つのものを選択する０に基づいたインデックスである。
応答：
ｒｅｓｐｏｎｓｅＥｌｅｍｅｎｔｓ：次のデータを含む単一のＤａｔａアトム

説明：装置によって管理されている状態オブジェクトの値Ｉｄ、値、及び満了日付を取得する。装置は、要求されたｇｉｄ及びｉｎｄｅｘを有する状態オブジェクトを具備していない場合には、ＥＲＲＯＲ＿ＮＯ＿ＳＵＣＨ＿ＩＴＥＭに設定された状態フィールドを有する応答を返す。
ＧｅｔＳｔａｔｅＯｂｊｅｃｔＣｏｕｎｔ
要求：
ｃｏｍｍａｎｄＩｄ： ＣＭＤ＿ＧＥＴ＿ＳＴＡＴＥ＿ＯＢＪＥＣＴ＿ＣＯＵＮＴ
パラメータ：次のデータを含む単一のＤａｔａ ａｔｏｍ

応答：
ｒｅｓｐｏｎｓｅＥｌｅｍｅｎｔｓ：次のデータを含む単一のＤａｔａアトム

説明：指定されたグループＩＤを有する状態オブジェクトの数を返す。装置は、要求されたｇｉｄを有する状態オブジェクトを具備していない場合には、ＥＲＲＯＲ＿ＮＯ＿ＳＵＣＨ＿ＩＴＥＭに設定された状態フィールドを有する応答を返す。
ＳｅｔＳｔａｔｅＯｂｊｅｃｔ
要求：
ｃｏｍｍａｎｄＩｄ：ＣＭＤ＿ＳＥＴ＿ＳＴＡＴＥ＿ＯＢＪＥＣＴ
パラメータ：次のデータを含む単一のＤａｔａアトム

応答：
ｒｅｓｐｏｎｓｅＥｌｅｍｅｎｔｓ：なし
ＤｅｌｅｔｅＳｔａｔｅＯｂｊｅｃｔ
要求：
ｃｏｍｍａｎｄＩｄ：ＣＭＤ＿ＤＥＬ＿ＳＴＡＴＥ＿ＯＢＪＥＣＴ
パラメータ：次のデータを含む単一のＤａｔａアトム

応答：
ｒｅｓｐｏｎｓｅＥｌｅｍｅｎｔｓ：なし

ホストから状態オブジェクトへのアクセス
装置状態オブジェクトには、ホスト上において稼働しているコントロールから、ホストオブジェクトインターフェイスを通じてアクセス可能である。例えば、一実施例においては、グループＩＤ＜ｇｉｄ＞及び値ＩＤ＜ｖｉｄ＞を有する状態オブジェクトには、／Ｍａｒｌｉｎ／ＭＳＴＤ／＜ｇｉｄ＞／＜ｖｉｄ＞というパスによってアクセス可能である。

ホストオブジェクトの値は、状態値及び満了日付をコード化した８バイトの複合データ構造である（例えば、３２ビットの状態値と、これに後続する１９７０年１月１日の００：００：００以降に経過した分の数によって表現された３２ビットのＵＴＣ満了日付である）。

一実施例においては、ホストオブジェクトツリーの中のこの部分に対するアクセス制御は、次のように実行されている。

コントロールは、そのアイデンティティ（そのアイデンティティは、そのコードに署名した鍵にバインドされたすべてのプリンシパル名のコレクションである）内の名前の中の１つのものがグループＩＤとマッチングした場合にのみ、状態値ホストオブジェクトを読み取り及び書き込み可能であり、ここで、マッチングは、プリンシパル名のＳＨＡ−１ダイジェスト値の１２８個の最下位ビットを１２８ビットのグループＩＤと比較することによって実行可能である。

ペアリング
ＳｅｔＰａｉｒｉｎｇＫｅｙ
要求：
ｃｏｍｍａｎｄＩｄ：ＣＭＤ＿ＳＥＴ＿ＰＡＩＲＩＮＧ＿ＫＥＹ
パラメータ：次のデータを有する単一のＤａｔａアトム

応答：
ｒｅｓｐｏｎｓｅＥｌｅｍｅｎｔｓ：装置は、次のデータを有するＤａｔａアトムを応答要素内に包含可能である。

ここで、「ｅｎｃｏｄｅｄＰａｒｉｎｇＫｅｙ」は、ペアリングレコード内に保存することができるようにコード化されたペアリング鍵である。一実施例においては、コード化されたペアリング鍵は、装置のみがコード化されたペアリング鍵を使用してペアリング鍵の値を演算可能であることを保証するように暗号化されている。

ＴＬＳバインディング
このバインディングは、ＴＬＳを使用してホストから装置へのＳＡＣを確立する方法を規定している。

一実施例においては、ホスト及び装置は、それぞれ、ＲＳＡ秘密鍵と、対応する公開鍵を保持するＸ．５０９証明書と、を具備する。ホスト及び装置は、ＡＥＳ ｃｉｐｈｅｒ ｓｕｉｔｅ用に構成されたＴＬＳ通信を確立する。

ＴＬＳセッションが確立されると、ホスト及び装置は、通信ループに入り、そこで、ホスト又は装置がセッションを終了する時点まで、ホストは、要求アトムを送信し、且つ、応答アトムを受信する。

以下、この安全な認証チャネル（ＳＡＣ）用のＴＬＳバインディングの例示用の実装について更に詳細に説明する。この例に規定されているバインディングは、Ｄｉｅｒｋｓ他による「Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．０」（ＩＥＴＦ ＲＦＣ２２４６）の１つのプロファイルであり、ＭＳＴＤホスト及び装置の間の最大限の相互運用性及び実装の容易性のために最適化された選択肢の非常に限られた組を有する。

バインディング記述
一実施例においては、このセキュリティバインディングをサポートする装置は、その旨をその装置記述文書内において告知しなければならない。一実施例においては、このセキュリティバインディングに対応する＜Ｂｉｎｄｉｎｇ＞要素は、次のように定義されている。

ｔｙｐｅ Ｕｒｎ：ｍａｒｌｉｎ：ｔｅｔｈｅｒｅｄ： １−０：ｔｌｓ

一実施例においては、唯一の＜Ｏｐｔｉｏｎ＞要素が存在しなければならない。

ＴＬＳプロファイル
図１４は、ホスト１４００とテザード装置１４０２の間のＴＬＳの実装を示しており、且つ、ホスト１４００と装置１４０２の間の通信を階層化する方法をも示す。

図１４に示されているように、最上位のアプリケーションレイヤ１４０４は、前述のタイプの１つ又は複数のメッセージから構成されている。最下位のトランスポートレイヤ１４０６は、所与の配備のために選択されたトランスポートバインディングに依存している。以下においては、ＵＳＢマスストレージに基づいた例示用のトランスポートバインディングについて説明する。中間レイヤ１４０８は、セキュリティ及び認証を通信に付加するものであり、これは、ＴＬＳのプロファイルとして定義されている。一実施例においては、ホストは、ＴＬＳクライアントに対してマッピングされ、且つ、装置は、ＴＬＳサーバーに対してマッピングされる。

一実施例においては、このＴＬＳのプロファイルにおいて使用される唯一のｃｉｐｈｅｒ ｓｕｉｔｅは、Ｃｈｏｗｎによる「Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ （ＡＥＳ） Ｃｉｐｈｅｒｓｕｉｔｅｓ ｆｏｒ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ （ＴＬＳ）」（ＩＥＴＦ ＲＦＣ３２６８、２００２年６月）に定義されているＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡである。この選択されたｃｉｐｈｅｒｓｕｉｔｅは、認証及び鍵交換アルゴリズムがＲＳＡであることを意味している。好適な実施例においては、Ｔｅｍｐｏｒａｒｙ ＲＳＡ鍵は使用されない。又、これは、ＴＬＳサーバー（即ち、テザード装置）のＸ．５０９証明書が、鍵使用フィールド内に設定されたｋｅｙＥｎｃｉｐｈｅｒｍｅｎｔ及びｄｉｇｉｔａｌＳｉｇｎａｔｕｒｅビットの両方を具備することをも意味している。

ハンドシェーク
前述のＴＬＳのプロファイル内において、ＴＬＳサーバー（即ち、テザード装置）とＴＬＳクライアント（即ち、ホスト）の両方が認証される。図１５は、このプロファイルのハンドシェークプロトコルを示している。一部の実施例においては、短縮されたハンドシェークを使用可能である。

メッセージ
このプロファイル内においては、いくつかのフィールドが次のメッセージ内において特定されている。一実施例においては、特記されない限り、以下に示されている値が必須である。

ＣｌｉｅｎｔＨｅｌｌｏ
− ｃｌｉｅｎｔ＿ｖｅｒｓｉｏｎ：｛３，１｝に設定される（ＴＬＳ １．０）。
− ｃｉｐｈｅｒ＿ｓｕｉｔｅｓ：１つの要素がＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡに設定される。
− ｃｏｍｐｒｅｓｓｉｏｎ＿ｍｅｔｈｏｄｓ：１つの要素が０（ＣｏｍｐｒｅｓｓｉｏｎＭｅｔｈｏｄ．ｎｕｌｌ）に設定される。

ＳｅｒｖｅＨｅｌｌｏ
− ｓｅｒｖｅｒ＿ｖｅｒｓｉｏｎ：｛３，１｝に設定される（ＴＬＳ １．０）。
− ｃｉｐｈｅｒ＿ｓｕｉｔｅ：ＴＬＳ＿ＲＳＡ＿ＷＩＴＨ＿ＡＥＳ＿１２８＿ＣＢＣ＿ＳＨＡに設定される。
− ｃｏｍｐｒｅｓｓｉｏｎ＿ｍｅｔｈｏｄ：０（ＣｏｍｐｒｅｓｓｉｏｎＭｅｔｈｏｄ．ｎｕｌｌ）に設定される。

ＳｅｒｖｅｒＣｅｒｔｉｆｉｃａｔｅ
− ｃｅｒｔｉｆｉｃａｔｅ＿ｌｉｓｔ：装置のＲＳＡ鍵のＸ．５０９証明書チェーンを含む。

ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔ
− ｃｅｒｔｉｆｉｃａｔｅ＿ｔｙｐｅｓ：１つの要素がｒｓａ＿ｓｉｇｎ（１）に設定される。
− ｃｅｒｔｉｆｉｃａｔｅ＿ａｕｔｈｏｒｉｔｉｅｓ：トラストアンカーが固定されている場合には、空である。

ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅ
このプロファイル内においては、更に規定されるものはない。

ＣｌｉｅｎｅｔＣｅｒｔｉｆｉｃａｔｅ
− ｃｅｒｔｉｆｉｃａｔｅ＿ｌｉｓｔ：ホストのＲＳＡ鍵のＸ．５０９証明書チェーンを含む。

ＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅ
− ｅｘｃｈａｎｇｅ＿ｋｅｙｓ：ＲＳＡ ｅｎｃｒｙｐｔｅｄＰｒｅＭａｓｔｅｒＳｅｃｒｅｔに設定される。

ＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙ
ＳｉｇｎａｔｕｒｅＡｌｇｏｒｉｔｈｍは、ＲＳＡである。

鍵の使用
一実施例においては、テザード装置の鍵証明書は、設定されたｄｉｇｉｔａｌＳｉｇｎａｔｕｒｅ及びｋｅｙＥｎｃｉｐｈｅｒｍｅｎｔビットを具備しなければならず、且つ、ホストの鍵証明書は、設定されたｄｉｇｉｔａｌＳｉｇｎａｔｕｒｅビットを具備しなければならない。

ＵＳＢマスストレージのバインディング
既に説明したように、一実施例においては、新しい技法を使用し、拡張ＳＣＳＩコマンドを使用することにより、ＵＳＢインターフェイス上において、ホストと装置の間において、前述したようなメッセージの通信を円滑に実行する。この通信の形態をサポートする装置（即ち、拡張ＳＣＳＩコマンドを処理するために設計された装置）は、そのＵＳＢディスクリプタの中の１つのものの内部に、この旨の表示を含む。図１６に示されているように、このようにテザード装置と通信することを所望するホストは、まず、標準的なＵＳＢディスカバリー／検査プロセス（１６０２）を実行し、装置のＵＳＢディスクリプタを入手することになる。次いで、ホストは、それらのＵＳＢディスクリプタを解析し、それらが、この形態の通信が装置によってサポートされているという表示を含んでいるか否かを確認し（１６０４）、含んでいる場合には、装置がサポートしている１つ又は複数の拡張ＳＣＳＩコマンドを確認する（１６０６）。次いで、ホスト及び装置は、その１つ又は複数の拡張ＳＣＳＩコマンドを使用し、通信を開始することができる（１６０８）。以下、例示用の実装について更に詳細に説明する。

一実施例においては、ＵＳＢマスストレージのバインディングを使用し、装置のコンテンツストレージをそのホストに対して開示する主な方法として（例えば、「Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ Ｍａｓｓ Ｓｔｏｒａｇｅ Ｃｌａｓｓ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｏｖｅｒｖｉｅｗ Ｒｅｖｉｓｉｏｎ １．２」（２００３年６月２３日）に記述されている）ＵＳＢマスストレージプロファイルを実装する装置に対してシステムを具体的に適用する方法を定義している。

装置は、従来のファイルシステムに対するアクセスを提供するＵＳＢマスストレージインターフェイスを開示するものと仮定されている。テザード装置は、ホストとの通信を実行している際には、ストレージにアクセス不能であるものと仮定されている。

装置のディスカバリー
一実施例においては、このバインディングを実装するテザード装置は、ＧＥＴ＿ＤＥＳＣＲＩＰＴＯＲ要求に対して応答することにより、特殊なＵＳＢディスクリプタを提供してバインディングのバージョン及びパラメータを通知する必要があり、この場合に、ディスクリプタタイプは、ＳＴＲＩＮＧ（０ｘ０３）であり、且つ、言語ＩＤは、０である。一実施例においては、これは、２５５であることを要し、装置が、インデックス２５５においてＵＳＢディスクリプタを提供することができない場合には、これは、１〜２５５の中の任意のインデックスであってよく、２５５に最も近い利用可能なインデックスを選択するべきである。

一実施例においては、このディスクリプタのストリング値は、「ｕｒｎ：ｍａｒｌｉｎ：ｍｓｔｄ：ｕｓｂ−ｍｓｃ：１．０：＜ｓｃｓｉ−ｃｄｂ−ｏｐ＞」であり、ここで、＜ｓｃｓｉ−ｃｄｂ−ｏｐ＞は、２文字の１６進数としてコード化された後述するＳＣＳＩオペレーションコードである。例えば、装置によって選択されたＳＣＳＩコマンドＩＤが０ｘ２０である場合には、ＭＳＴＤ ＵＳＢディスクリプタストリングは、ｕｒｎ：ｍａｒｌｉｎ：ｍｓｔｄ：ｕｓｂ−ｍｓｃ：１．０：２０である。

バインディングの記述
一実施例においては、このトランスポートバインディングをサポートする装置は、その旨をその装置記述文書内において告知しなければならない。一実施例においては、このトンラスポートバインディングに対応する＜Ｂｉｎｄｉｎｇ＞要素は、次のように定義されている。

一実施例においては、このバインディングのために、＜Ｏｐｔｉｏｎ＞要素が定義されていない。

ＳＣＳＩコマンド
一実施例においては、ホスト及び装置は、ＳＣＳＩコマンドを使用し、マスストレージＳＣＳＩコマンドを交換するために使用されるものと同一のメカニズムを介して通信する。このバインディングにおいて使用されるＳＣＳＩコマンドは、Ｃｏｍｍａｎｄ Ｄｅｓｃｒｉｐｔｏｒ Ｂｌｏｃｋ（ＣＤＢ）の観点において規定されている。その他の目的に使用されていないオペレーションコードが選択される。一実施例においては、このオペテーションコードの値は、０ｘ２０であるが、任意のその他の未使用のオペレーションコードであってもよい。

一実施例においては、ＣＤＢは、長さが１０バイトであり、次のフィールドを有する。

ここで、「ＭＳＴＤ ＣＯＭＭＡＮＤ」は、ＭＳＴＤ＿ＣＭＤ＿ＲＥＡＤ（０ｘ０１）、ＭＳＴＤ＿ＣＭＤ＿ＷＲＩＴＥ（０ｘ０２）、及びＭＳＴＤ＿ＣＭＤ＿ＲＥＳＥＴ（０ｘ０３）という３つのＭＳＴＤコマンドの中の１つである。

ＭＳＴＤ＿ＣＭＤ＿ＲＥＡＤ
ＭＳＴＤ＿ＣＤＭ＿ＲＥＡＤコマンドは、装置からのデータのバッファを読み取るためにホストによって使用される。このコマンドの場合には、ＤＡＴＡ ＳＩＺＥフィールドは、リターンバッファ用にホストによって割り当てられたバッファのサイズに設定され、ＲＥＴＵＲＮ＿ＳＩＺＥ＿ＯＦＦＳＥＴは、バッファ内のオフセットに設定され、この場合に、装置は、返されたバイトの数に等しい３２ビットビッグエンディアン値を書き込むことになる。

ＭＳＴＤ＿ＣＭＤ＿ＷＲＩＴＥ
ＭＳＴＤ＿ＣＭＤ＿ＷＲＩＴＥコマンドは、データのバッファを装置に書き込むためにホストによって使用される。このコマンドの場合には、ＤＡＴＡ ＳＩＺＥフィールドは、ホストによって書き込まれたペイロードのサイズに設定され、ＲＥＴＵＲＮ＿ＳＩＺＥ＿ＯＦＦＳＥＴフィールドは、０に設定される。

ＭＳＴＤ＿ＣＭＤ＿ＲＥＳＥＴ
ＭＳＴＤ＿ＣＭＤ＿ＲＥＳＥＴコマンドは、装置との通信状態をリセットするためにホストによって使用される。このコマンドの場合には、ＤＡＴＡ＿ＳＩＺＥ及びＲＥＴＵＲＮ＿ＳＩＺＥ＿ＯＦＦＳＥＴフィールドは、０に設定される。

コマンドのシーケンス
ホストと装置の間の通信プロトコルは、ＴＬＳレコード及びＭＳＴＤ要求／応答ペアのシーケンスから構成される。ホストから装置に送信されるそれぞれのレコードごとに、ホストは、１つ又は複数のＭＳＴＤ＿ＣＭＤ＿ＷＲＩＴＥコマンドを発行する（レコードが単一のＭＳＴＤ＿ＣＭＤ＿ＷＲＩＴＥコマンド内に書き込み不可能である場合には、レコードは、複数のＭＳＴＤ＿ＣＭＤ＿ＷＲＩＴＥコマンドに分割される）。装置から受け取るためにホストが予想しているそれぞれのレコードについて、ホストは、完全なレコードが装置から読み取られる時点まで、ＭＳＴＤ＿ＣＭＤ＿ＲＥＡＤコマンドを発行する。

（不良な形態のレコード、タイムアウト、又はその他の問題などの）通信エラーが発生した場合には、ホストは、ＭＳＴＤ＿ＣＭＤ＿ＲＥＳＥＴコマンドを発行し、通信をリセット可能である。一実施例においては、リセットの後に、通信は、ホスト及び装置がなんらのレコードをも未だ交換していなかったかのように再開される。

装置記述文書
一実施例においては、装置記述は、ファイルシステム上の装置記述文書内に保存されている。一実施例においては、この文書のファイル名は固定されている（例えば、／．ｍａｒｌｉｎ／ｄｅｖｉｃｅ．ｘｍｌであり、ここで、「／」は、ファイルシステムのルートを表し、．ｍａｒｌｉｎは、ファイルシステムのルートにおけるディレクトリである。）

ルートディレクトリ
ルートディレクトリは、ホストによって書き込まれると共に装置によって読み取られるファイルを含むディレクトリである。ルートディレクトリは、装置記述文書が配置されるディレクトリのサブディレクトリであることが推奨される。一実施例においては、次のファイルがルートディレクトリ内に配置されている。

ｓｖｓ．ｄｂ：このファイルは、それぞれのｓｖｓＩｄフィールドによってインデックス付けされたＳＶＳエントリのデータベースを含む。

ｌｖｓ．ｄｂ：このファイルは、それぞれのｆｒｏｍフィールドによってインデックス付けされたＬＶＳレコードのデータベースを含む。

ｓｖｓｌｏｃ．ｄｂ：このファイルは、それぞれのｃｏｎｔｅｎｔＩｄフィールドによってインデックス付けされたｓｖｓＬｏｃａｔｏｒエントリのデータベースを含む。

ｆｉｌｅｌｏｃ．ｄｂ：このファイルは、それぞれのｓｖｓＩｄフィールドによってインデックス付けされたＦｉｌｅＬｏｃａｔｏｒレコードのデータベースを含む。

ｐａｉｒｉｎｇ．ｄｂ：このファイルは、それぞれのｐａｉｒｉｎｇＩｄフィールドによってインデックス付けされたペアリングレコードのデータベースを含む。

ｃｒｌ．ｂｉｎ：このファイルは、現在のＣＲＬを含む。

リンクディレクトリ
一実施例においては、ホストは、この装置のノードとユーザノードの間の関係を表現するリンクオブジェクトを具備していない異なるホストとのペアリングを円滑に実行するために、リンクオブジェクトをリンクディレクトリ内に保存可能である。

一実施例においては、このディレクトリは、「ｌｉｎｋｓ」と命名され、ルートディレクトリ内に配置されている。

データベースフォーマット
一実施例においては、このバインディング内において使用されるデータベースファイルは、非常に単純である。それらは、装置上におけるコードの複雑な解析を必要とすることなしに、レコードに対するインデックスによる高速アクセスを提供するために設計されている。

一実施例においては、ファイルは、２＾ｎ個のエントリを有するハッシュテーブルと、セルの１つ又は複数のリンクされたリストと、から構成される。セルは、ペイロード（バイトアレイ）と、チェーニングポインタ（別のセルに対するファイルオフセット、又はリスト内の最後のセルの場合には、ゼロ）と、含む。鍵がそれぞれのペイロードに対応している。所定のペイロードの鍵の値は、ペイロードタイプに依存する。一実施例においては、それぞれの鍵値ごとに、ｎビットのハッシュ値が演算される。この値は、鍵値のＳＨＡ−１ダイジェスト値のｎ個の最下位ビットに等しい。ハッシュテーブルインデックス内のそれぞれのエントリは、２＾ｎ個のｎビット鍵ハッシュ値の中の１つのものに対応し、その鍵ハッシュを有するセルが存在しない場合には、ゼロを含み、そのハッシュを有する鍵を有するセルが存在する場合には、そのセルの３２ビットファイルオフセットを含む。セルは、１つにリンク可能である。ファイルは、テーブルの記述を含むヘッダ（例えば、データベース識別子や「ｎ」の値など）によって始まっている。

図１７は、データベースファイルのレイアウトの一例を示す。図１７に示されているように、一実施例においては、データベースファイルは、「ｄｂｈｄ」（データベースヘッダ）アトムを有し、これに、「ｄｂｃｏ」（セルオフセットテーブル）アトムが後続し、これに、１つ又は複数のその他のトップレベルアトムが後続している。これらのその他のトップレベルアトムは、「ｃｅｌｌ」アトム、「ｆｒｅｅ」アトム、又は任意のその他のアトムを包含可能である。一実施例においては、データベースファイルパーサーによって理解されないすべてのアトムは無視される。「ｄｂｈｄ」アトムは、ファイル内の最初のアトムであり、ファイルの第１バイトから始まっている。「ｄｂｃｏ」アトムは、ファイルの第２アトムであり、「ｄｂｈｄ」アトムの後の第１バイトから始まっている。その他のアトムは、任意の順序で出現可能である。

ＤａｔａｂａｓｅＨｅａｄｅｒアトムの例示用の構造を以下に示す。

ここで、「ｄａｔａｂａｓｅＩｄ」は、データベースの識別子である。一実施例においては、次の識別子が定義されている。

ＣｅｌｌＯｆｆｓｅｔＴａｂｌｅアトムの例示用の構造を次に示す。

Ｃｅｌｌアトムの例示用の構造を次に示す。

Ｆｒｅｅ アトムの例示用の構造が次に示される。

ドメイン
テザード装置は、その他の装置をドメイン内において管理可能である方法に似た方法によって管理可能である。図１８は、その一例を示す。図１８に示されているように、テザード装置をドメインに参加させるには、ホストアプリケーションは、ＤＲＭシステムのリンク取得プロトコルを使用し、テザード装置のパーソナリティノードとユーザノードの間にリンクを生成するように、ドメインマネージャに対して要求する（１８０２）。これに応答し、エージェントがホストに送信される（１８０４）。エージェントは、稼働した際に、ホストオブジェクトインターフェイスを介してテザード装置内の状態オブジェクトを設定する（１８０６）。ホストは、新しく取得されたリンクオブジェクトから、テザード装置用のＬＶＳオブジェクトを生成する（１８０８）。このＬＶＳは、条件を使用し、ＬＶＳの有効性を、エージェントによって設定された状態オブジェクトの存在に依存するようにさせる。ドメインを離脱するためには、ホストは、ドメインマネージャとの間において登録解除動作を実行することになり、この結果、このドメインと関連する状態オブジェクトを削除することになるエージェントが送信される。テザード装置用のＳＶＳに変換可能なドメインライセンスが、その有効性条件の中の１つのものとして、ドメインのノードＩＤの到達可能性をコード化する。到達可能性は、装置がその独自のノードＩＤからドメインノードＩＤへのＬＶＳを具備しているか否かと、設定された対応する状態オブジェクトと、に依存する。

アペンディックスＡ
次の内容は、例示用の装置記述文書の構文を記述するＸＭＬスキーマの一例である。

アペンディックスＢ
図１９は、例示用のメッセージのカプセル化を示す。一実施例においては、ＵＳＢ上においてＴＬＳバインディングを使用する際に、ホスト要求の例が図示のようにカプセル化される。

以上の内容は、明瞭のために多少詳細に説明したが、添付の請求項の範囲内において、特定の変更又は変形を実施可能であることは明らかである。本明細書に記述されているプロセス及び装置の両方を実装するための多数の代替方法が存在することに留意されたい。従って、本実施例は、例示を目的としたものであって、限定を意図したものではないと解釈することを要するものであり、本発明は、本明細書に付与された詳細に限定されるものではなく、添付の請求項の範囲及びその均等物内において変更可能である。

Claims (3)

1. 電子コンテンツ片に対するアクセス又は前記電子コンテンツ片の他の使用を管理する際に使用されるライセンスを、ホスト装置からターゲット装置にエクスポートする方法であって、
   前記電子コンテンツ片を暗号解読するよう構成された第１暗号鍵を暗号化するためにペアリング鍵を使用し、
   前記電子コンテンツ片に対するアクセスの認可に関係する１つ又は複数の条件を取得するために、前記ライセンスに含まれた制御プログラムを実行し、
   前記暗号化された第１暗号鍵及び前記１つ又は複数の条件の表示を含むデータ構造を生成し、
   前記ペアリング鍵を使用して前記データ構造の少なくとも一部にデジタル署名し、
   前記データ構造を前記ターゲット装置に対して送信すること、
   を有することを特徴とする方法。
2. 前記１つ又は複数の条件が少なくとも１つのノードを参照するか否かについての決定を行い、
   前記決定の結果に基づいて、１つ又は複数のリンク有効性ステートメントレコードを条件付きで生成し、前記１つ又は複数のリンク有効性ステートメントレコードのそれぞれは、少なくとも１つのノードが少なくとも別のノードから到達可能であるか否かの表示を提供すること、
   を更に有する請求項１に記載の方法。
3. 少なくとも第１リンク有効性ステートメントレコードは、前記第１リンク有効性ステートメントレコードが有効になるために満足されなければならない条件の表示を含む請求項２に記載の方法。

Images