(57)【要約】デジタル権利管理ポリシが任意のコンテンツ・タイプ又は転送制御プロファイルを有するデジタル・メディアと関連付けられることを可能にするシステム及び／又は方法（「ツール」）が説明される。ある実施例では、このツールは、メディア・ファイルのデータ・セグメントを暗号化し、デスクリプタをこれらのセグメントのそれぞれに追加する。これらのデスクリプタは、暗号化されたメディア・ファイルの受信機がそのファイルを復号し、正しいデジタル権利管理ポリシに従ってそれを消費することを可能にする。
2009505506.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ実装される方法であって、
任意のコンテンツ店タイプを有するメディア・ファイルのデータ・セグメントを暗号化して暗号化されたデータ・セグメントを提供するステップと、
前記暗号化されたデータ・セグメントにデスクリプタを追加するステップと、
を含んでおり、それぞれの暗号化されたデータ・セグメントのデスクリプタは、当該暗号化されたデータ・セグメントに対する関連付けされたデジタル権利管理ポリシと前記暗号化されたデータ・セグメントを複合するのに用いることができる鍵ＩＤとを示すことを特徴とする方法。
【請求項２】
請求項１記載の方法において、前記暗号化するステップはＡＥＳをカウンタ・モードで用いて前記データ・セグメントを暗号化することを特徴とする方法。
【請求項３】
請求項１記載の方法において、前記デスクリプタは初期化ベクトルを含み、暗号化されたそれぞれのデータ・セグメントの初期化ベクトルは、当該暗号化されたデータ・セグメントを複合するのに用いることができるコンテンツ鍵と関連付けられていることを特徴とする方法。
【請求項４】
請求項１記載の方法において、それぞれのデスクリプタは、その関連付けられたデジタル権利管理ポリシに含まれる鍵ＩＤを有することを特徴とする方法。
【請求項５】
請求項１記載の方法において、暗号化されたそれぞれのデータ・セグメントのデスクリプタは、前記暗号化されたデータ・セグメントとそのデスクリプタとの間の区別を可能にする長さインジケータを含むことを特徴とする方法。
【請求項６】
請求項１記載の方法において、前記メディア・ファイルは、第１のデジタル権利管理ポリシと関連付けられた第１の部分と第２のデジタル権利管理ポリシと関連付けられた第２の部分とを含み、前記追加するステップは、前記第１のデジタル権利管理ポリシを示す第１のデスクリプタを前記第１の部分の暗号化されたデータ・セグメントに追加し、前記第２の関連付けされたデジタル権利管理ポリシを示す第２のデスクリプタを前記第２の部分の暗号化されたデータ・セグメントに追加することを特徴とする方法。
【請求項７】
請求項１記載の方法において、前記暗号化されたデータ・セグメントはＲＴＰデータ・プロトコルに従うパケット又はＨＴＴＰプロトコルに従うフレームを含むことを特徴とする方法。
【請求項８】
請求項７記載の方法において、前記追加するステップは、前記暗号化されたデータ・セグメントがＲＴＰプロトコルに従うパケットを含む場合には前記暗号化されたデータ・セグメントの最後に前記デスクリプタを結合し、前記暗号化されたデータ・セグメントがＨＴＴＰに従うフレームを含む場合には前記暗号化されたデータ・セグメントの最初に前記デスクリプタを結合することを特徴とする方法。
【請求項９】
１又は複数のコンピュータ可読の媒体を含むシステムであって、前記コンピュータ可読な媒体はデータ・セグメントを含むデジタルメディア・ファイルを含み、それぞれのデータ・セグメントは、デスクリプタに追加され、暗号化されたペイロード・データを含み、それぞれのデータ・セグメントのデスクリプタは、前記データ・セグメントのペイロード・データの復号と、前記データ・セグメントのペイロード・データをデジタル権利管理ポリシとの関連付けとを可能にする暗号化パラメータを有していることを特徴とするシステム。
【請求項１０】
請求項９記載のシステムにおいて、それぞれのデスクリプタの暗号化パラメータは、前記デジタル権利管理ポリシによる鍵ＩＤを含むことを特徴とするシステム。
【請求項１１】
請求項９記載のシステムにおいて、それぞれのデータ・セグメントのペイロード・データはコンテンツ鍵を用いて暗号化され、前記データ・セグメントのデスクリプタは前記コンテンツ鍵と関連付けされた鍵ＩＤを含み、前記コンテンツ鍵は前記ペイロード・データを復号するのに用いることができることを特徴とするシステム。
【請求項１２】
請求項９記載のシステムにおいて、前記デジタル・メディアは、第１のデータ・セグメントと有する第１の部分と第２のデータ・セグメントを有する第２の部分とを含み、前記第１のデータ・セグメントのデスクリプタの中の少なくとも１つは前記第１の部分が第１のデジタル権利管理ポリシと関連付けられることを可能にし、前記第２のデータ・セグメントのデスクリプタの中の少なくとも１つは前記第２の部分が第２のデジタル権利管理ポリシと関連付けられることを可能にすることを特徴とするシステム。
【請求項１３】
請求項９記載のシステムにおいて、それぞれのデータ・セグメントのペイロード・データは暗号化されており、そのデスクリプタは暗号化されていないことを特徴とするシステム。
【請求項１４】
請求項９記載のシステムにおいて、前記デジタル・メディア・ファイルは、デスクリプタに追加されたデータ・セグメントを更に含み、クリア・ペイロード・データを含み、前記データ・セグメントのデスクリプタは前記データ・セグメントのクリア・ペイロード・データと別のデジタル権利管理ポリシとの関連付けを可能にすることを特徴とするシステム。
【請求項１５】
請求項９記載のシステムにおいて、前記デジタル・メディア・ファイルはストリーミング媒体であることを特徴とするシステム。
【請求項１６】
コンピュータ実装される方法であって、
第１の部分と第２の部分とを有する暗号化されたメディア・ファイルを受信機に送信するステップと、
前記暗号化されたメディア・ファイルの受信機が前記第１の部分と前記第２の部分とを復号することを可能にするステップと、
前記受信機が、前記第１の部分と前記第１の部分の使用の許容を支持する第１の権利ポリシとの関連付けと、前記第２の部分と前記第２の部分の使用の許容を支持する第２の権利ポリシとの関連付けとを可能にするステップと、
を含むことを特徴とするシステム。
【請求項１７】
請求項１６記載の方法において、前記第１の権利ポリシと前記第２の権利ポリシとを前記受信機に送るステップを更に含むことを特徴とする方法。
【請求項１８】
請求項１６記載の方法において、前記受信機の関連付けを可能にするステップは、第１のデスクリプタを前記第１の部分の中に第２のデスクリプタを前記第２の部分の中に構築し、前記第１のデスクリプタは前記第１の部分が前記第１の権利ポリシと関連付けられていることを指示し、前記第２のデスクリプタは前記第２の部分が前記第２の権利ポリシと関連付けられていることを指示することを特徴とする方法。
【請求項１９】
請求項１８記載の方法において、前記受信機の復号を可能にするステップは、第１の鍵ＩＤを前記第１のデスクリプタの中に第２の鍵ＩＤを前記第２のデスクリプタの中に構築し、前記第１の鍵ＩＤは前記第１の部分を復号するのに用いることができ、前記第２の鍵ＩＤは前記第２の部分を復号するのに用いることができることを指示することを特徴とする方法。
【請求項２０】
請求項１６記載の方法において、任意のコンテンツ・タイプのメディア・ファイルを受け取るステップと、前記メディア・ファイルを暗号化して暗号化されたメディア・ファイルを提供するステップと、を更に含むことを特徴とする方法。
【発明の詳細な説明】
【技術分野及び背景技術】
【０００１】
デジタル権利管理（デジタル著作権管理、ＤＲＭ）は、電子デバイス上のデジタル・メディア・コンテンツの使用を制御又は制限するなどにより、コンテンツを保護するのに用いられる技術を指す。ＤＲＭの１つの特性は、ＤＲＭがメディア・コンテンツを与えられたマシン又はデバイスに結び付けることができるという点にある。従って、特別の１つコンテンツに関係しコンテンツに関連する権利と制限とを定義するライセンスは、与えられたマシン又はデバイスに結び付けられるのが通常である。その結果、ユーザーは、そのコンテンツを再生するためにコンテンツを取り出して別のマシンに移動させることが許されない。
【０００２】
現在のＤＲＭ技術は、制限を有する。それらは、デジタル媒体を転送する２つのタイプだけのプロトコルと互換性を有することが多い。すなわち、ＨＴＴＰ及びＲＴＳＰである。しかし、他のプロトコルが、現時点で又は将来に、デジタル媒体の転送により適していることがありうる。更に、ＤＲＭによって保護されるコンテンツは、特定のコンテンツ点タイプに限定される可能性がある。ある１つの特定のコンテンツ・タイプであるＡＳＦファイルは、ただ１組の権利及び制限（つまりポリシ）だけがＡＳＦファイルの全体に適用されることを許容する。例えば、ビデオ・ファイルのレンダリングの際には、ファイル全体の対するアナログ・ビデオ出力にマクロビジョンが要求されるか、又は、全く要求されないかのどちらかである。
【発明の概要】
【０００３】
任意のコンテンツ・タイプか転送制御プロトコルを有するデジタル媒体に関連するデジタル権利管理ポリシを可能にするシステム及び／又は方法（「ツール」）が説明される。いくつかの実施例では、ツールは、メディア・ファイルのデータ・セグメントを暗号化し、それらのセグメントのそれぞれにデスクリプタ（記述子）を追加する。これらのデスクリプタは、暗号化されたメディア・ファイルの受信機がファイルを復号し正確なデジタル著作権管理ポリシによってそれを消費することを可能にすることができる。
【０００４】
この概要は、以下の詳細な説明において更に詳述される、単純化された形式を有する概念の選択を導入するために提供される。この概要は、特許請求された発明の主題の鍵となるすなわち基本的な特徴を識別することは意図していないし、特許請求された主題の範囲を確定するのに役立つことも意図していない。
【発明を実施するための最良の形態】
【０００５】
概観
デジタル権利管理ポリシが任意のコンテンツ・タイプ又は転送制御プロトコルを有するデジタル媒体と関連付けされることを可能にするツールについて、説明する。いくつかの実施例では、このツールは、メディア・ファイルのデータ・セグメントを暗号化し、それらのセグメントのそれぞれにデスクリプタを追加する。これらのデスクリプタは、暗号化されたメディア・ファイルの受信機がファイルを復号し、正確なデジタル著作権管理ポリシに従ってそれを消費することを可能にする。
【０００６】
以下の議論では、「コンテンツセキュリティ及びライセンス転送プロトコル」とタイトルをつけられたセクションが提供され、本発明による技術を用いることができる１つの特別のシステムについて説明する。その後で、「ＲＴＳＰ」及び「ＨＴＴＰ」とタイトルをつけられたセクションが、これらのプロトコルに慣れていない読者に対して、本発明による技術に関する理解をここで提供する。
【０００７】
このセクションに続いて、「ルート及びリーフ・ライセンス」とタイトルをつけられたセクションが提供され、メディア・ファイルの多数の他のライセンスを可能にする当初のルート・ライセンスの概念について記述する。次のセクションでは、「複数のリーフ・ライセンスを備えた単一の暗号化されたメディア・ファイル」とダイされたセクションが提供され、メディア・ファイルの一部に関連したリーフ・ライセンスを使用して、どのようにしてメディア・ファイルを複数のデジタル著作権管理ポリシと関連付けるかについて説明する。
【０００８】
これらのセクションの後には、２つのセクションが続くが、その第１は「デスクリプタ」と題するものであり、第２は「コンテンツ独立なデータ暗号化」である。これらのセクションでは、メディア・ファイルのデータ・セグメントのためのデスクリプタと、デジタル・コンテンツのそのタイプにかかわらずメディア・ファイルの暗号化を可能にするようにツールがこれらのデスクリプタを使用する態様とについて、説明する。最後のセクションである「ルート及びリーフ・ライセンスを使用する」では、ツールがルート及びリーフ・ライセンスを使用する方法について記述する。
コンテンツ・セキュリティ及びライセンス転送プロトコル
以下では、セキュリティを提供しデジタル・リンクを介して流れるコンテンツのライセンスを転送する典型的なプロトコルに関する議論を提供する。このプロトコルは、ただ１つのプロトコルを構成し、そのプロトコルでは、様々な創造性のある技術を用いることができる。特許請求の範囲から逸脱することなく他のプロトコルを用いることができることが考えられる。
【０００９】
次の暗号学的な記号を、この明細書では用いる。
【００１０】
Ｋ｛データ｝：  データは、秘密鍵Ｋを用いて暗号化される。
【００１１】
Ｋ［データ］：  データは、秘密鍵Ｋを用いて署名される。
【００１２】
｛データ｝デバイス：  データは、デバイスの公開鍵を用いて暗号化される。
【００１３】
［データ］デバイス：  データは、デバイスの秘密鍵を用いて署名される。
【００１４】
この特定のプロトコルでは、５つの主要な手続きがある。すなわち、登録、再確認、近接性（proximity）検出、セッション確立、及びデータ転送である。
【００１５】
登録手順では、送信機、すなわち、別のデバイスに送信されることになっているコンテンツを有するデバイスは、一意的かつ安全に意図した受信機、すなわち、コンテンツが送信されることになっているデバイスを識別することができる。この特定のプロトコルでは、送信機は、登録された受信機と共にデータベースを維持し、小型の所定の数の受信機だけが同時に使用されることを保証する。登録手続中に、送信機は、近接性検出手順を用いて、保護されたコンテンツの広範な分配を防ぐため、ネットワークにおいて受信機が当該送信機に近接して位置していることを保証する。
【００１６】
再確認手続きは、受信機が引き続き送信機の近くにあることを保証するために利用される。もし過去の時間の所定期間内に登録されなかったし再確認されなかったならば、コンテンツは、受信機に配達されない。
【００１７】
セッション確立手順は、受信機が送信機にコンテンツを要請する場合には常に使用される。送信機は、セッション確立が完成されうる前に、デバイスが登録され最近確認されていることを強制する。
【００１８】
いったんセッションが確立されれば、要求されたコンテンツのデータ転送は、安全な方法で生じうる。受信機は、コンテンツの特定の部分を検索する（求める）ためにセッションを再使用することがあるが、異なるコンテンツを検索するために新しいセッションを確立しなければならない。
【００１９】
ここで、図１に関する登録手順と、送信機と受信機との間で送られる各種メッセージについて記述している次の表１とについて、考察する。
【００２０】
【表１】
2009505506.tif 000003
ここで、受信機は、他の情報と共に受信機のデジタル証明書を含む登録リクエスト・メッセージを送る。登録要求メッセージを受け取ることに反応して、送信機は、受信機の証明書を確認し、シーズ（種）及びランダム・セッションＩＤを生成し、上で示されている形式を有するのと同じものを、登録応答メッセージにおいて受信機に返送する。その後、受信機は、送信機の書名を確認し、セッションＩＤを得て、図の中で示された他の動作を行なう。次に、受信機と送信機は、下記に述べられる近接性検出プロセス（近接性検出プロセス）を経験することができる。
【００２１】
再確認に関しては、上に概説されるのと同じ手続きが実行され、再確認中の違いと共に行なわれ、受信機は、データベースに既に登録されている。
【００２２】
近接性検出に関しては、図２に関して下記を考慮してほしい。
【００２３】
近接性検出手続きの間に、受信機は、近接性検出初期設定メッセージの中で示されているセッションＩＤを含むメッセージを送信機に送る。その後、送信機は、受信機へノンス（１２８ビットのランダム値）を含んでいるメッセージを送り、受信機がコンテンツ暗号鍵を使用して暗号化されたノンスで応答するために要する時間を測定する。最後に、送信機は、近接性検出が成功したかどうか示すメッセージを受信機へを送る。
【００２４】
それが近接性検出が成功したという確証を有するまで、受信機は、プロセスを繰り返すことがある。特にこのプロトコルがＩＰベースのネットワーク上で使用される場合、近接性検出メッセージは、ＵＤＰの上で交換される。受信機は、登録応答メッセージを介して送信機のアドレスを学習する。受信機のアドレスは、別々に通信される必要はないが、その理由は、近接性検出初期設定メッセージを伝えるＵＤＰパケットの入ってくるＩＰヘッダを調べることにより、決定することができるからである。
【００２５】
次の表では、近接性検出の間に交換されるメッセージについて説明している。
【００２６】
【表２】
2009505506.tif 000004
セッション確立に関しては、図３と、セッション確立中に交換されるメッセージについて記述している次の表とを考察してほしい。
【００２７】
【表３】
2009505506.tif 000005
この例では、ライセンス要求メッセージは、受信機から送信機へ送られ、上に記述された情報を含んでいる。これを受けて、送信機は、上に記述された情報を含んでいるライセンス応答メッセージを送信することができる。
【００２８】
特にこの例において、ライセンスは、ＸＭＲフォーマットで表わされ、コンテンツ暗号鍵、コンテンツ保全（完全性、保全性、integrity）鍵、送信機のＣＲＬのバージョン、１２８ビットの権利ＩＤ、及び１２８ビットのシリアル番号を含んでいる。ライセンスは、更に、ＯＭＡＣを用いたコンテンツ完全性鍵を使用して計算されたＯＭＡＣを含んでいる。
【００２９】
データ転送手順に関しては、図４を参照しながら下記を考慮してほしい。セッション確立が完全ならば、データ転送は、制御プロトコルの特定のやり方で実行される。データ転送リクエストとレスポンスとの両方は、制御プロトコルとコンテンツ・タイプとのために特に定義されなければならない。これは、図４に概念的に表わされている。
【００３０】
以上では、本発明による実施例を用いることができる典型的なプロトコルの概要を提供したが、ここで、ＲＴＳＰに関するある背景的事項を考察する。
【００３１】
ＲＴＳＰ
当業者には理解されるように、リアルタイム・ストリーミング・プロトコルすなわちＲＴＳＰは、連続的な媒体（例えば、ストリーミングのようなリアルタイム・プロパティを備えたデータ）の配信の制御のためのアプリケーション・レベルのプロトコルである。ＲＴＳＰは、オーディオとビデオのような実時間データの制御されたオン・デマンドのデリバリ（配信）を可能にする拡張可能なフレームワークを提供する。データのソースは、実際のデータ・フィード及び格納されたクリップの両方を含むことができる。このプロトコルは、複数のデータ配信セッションを制御し、ＵＤＰのような配信チャネルを選ぶための手段を提供し、ＵＤＰとＴＣＰをマルチキャストし、ＲＴＰに基づいた配信機構を選ぶための手段を提供することを意図している。
【００３２】
ＲＴＳＰは、オーディオとビデオのような連続媒体の単一の又は複数の時間同期されたストリームを確立し制御する。制御ストリームを用いて連続媒体ストリームをインターリーブすることは可能であるが、典型的にはそれ自体連続的なストリームを伝えない。言いかえれば、ＲＴＳＰは、マルチメディア・サーバ用の「ネットワーク・リモート制御」として働く。
【００３３】
制御されるストリームの組は、提示記述によって定義される。ＲＴＳＰでは、ＲＴＳＰ接続についての概念は存在しない。代わりに、サーバは、識別子によってラベル付けされたセッションを維持する。ＲＴＳＰセッションは、ＴＣＰ接続のようなトランスポート・レベルの接続に結び付けられることは全くない。ＲＴＳＰセッションの間に、ＲＴＳＰクライアントは、ＲＴＳＰリクエストを出すサーバに、多くの信頼できるトランスポート接続を開閉することができる。又は、当業者であれば理解するように、ＵＤＰのようなコネクションレスのトランスポート・プロトコルを使用することがある。
【００３４】
ＲＴＳＰによって制御されたストリームは、ＲＴＰを使用することがある。しかし、ＲＴＳＰの動作は、連続媒体を運ぶために使用されるトランスポート機構に依存しない。
【００３５】
ここで、図５を参照しながら、クライアント／受信機５００とサーバ／送信機５０２の間の典型的なＲＴＳＰリクエスト／レスポンス交換を考察する。
【００３６】
まず、ＲＴＳＰリクエスト／レスポンスはヘッダを有するが、簡潔さのために、説明しない。ＲＴＳＰでは、クライアント／受信機５００は、典型的にはサーバ５０２からのリクエストＵＲＬによって識別された提示又はメディア・オブジェクトの説明の検索に向けられているＤＥＳＣＲＩＢＥリクエストとして知られているものを生じる。サーバ５０２は、ＳＥＳＳＩＯＮ  ＤＥＳＣＲＩＰＴＩＯＮ  ＰＲＯＴＯＣＯＬ（ＳＤＰ）で表わされる、要求されたリソースの銘柄で答える。ＤＥＳＣＲＩＢＥレスポンス（ＳＤＰ）は、それが記述するリソース用の媒体初期化情報をすべて含んでいる。
【００３７】
次に、クライアント５００は、ストリーミングされた媒体に使用されるトランスポート機構を指定するＵＲＩのＳＥＴＵＰリクエストを送信する。図５の例で、ＳＥＴＵＰリクエストは、オーディオとビデオの両方のために送信される。クライアント５００は、更にＳＥＴＵＰリクエストで、それが利用するトランスポート・パラメータを示す。ＳＥＴＵＰリクエストでのトランスポート・ヘッダは、データ伝送用のクライアントに受理可能なトランスポート・パラメータを指定する。サーバ５０２からのＲＥＳＰＯＮＳＥは、サーバによって選択されたトランスポート・パラメータを含んでいる。サーバは、更にＳＥＴＵＰリクエストに応じてセッション識別子を生成する。
【００３８】
この時点で、クライアントは、ＳＥＴＵＰの中で指定された機構によってデータを送信し始めるようにサーバに命じるＰＬＡＹリクエストを生じることができる。ＰＬＡＹリクエストを受け取ることに応答して、サーバは、この例では、オーディオ／ビデオ・コンテンツであるコンテンツのストリーミングを開始することができる。この例において、ストリーミング・コンテンツは、当業者が利用するように、ＲＴＰパケットを使用して、カプセル化され、ＵＤＰに送られる。
【００３９】
ＲＴＳＰプロトコルには、ＰＡＵＳＥ、ＴＥＡＲＤＯＷＮ、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＲＥＤＩＲＥＣＴ及びＲＥＣＯＲＤを含んでいる他の興味のある方法がある。ＲＴＳＰに関する補足的な背景については、読者は、ＲＴＳＰ  ＲＦＣ、Ｓｃｈｕｌｚｒｉｎｎｅ、Ｈ、Ｒａｏ．Ａ、及びＲ．Ｌａｎｐｈｉｅｒによる「リアルタイム・ストリーミング・プロトコル」（ＲＴＳＰ）、ＲＦＣ  ２３２６を参照すべきである。これは、１９９８年４月において、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２３２６．ｔｘｔにおいて入手可能である。
ルート及びリーフ・ライセンス
絵入りで記述された実施例では、ルート・ライセンス及びリーフ・ライセンスについての概念は雇われる。ここで、ルート・ライセンスはクライアント／受信機が続いて伝えられたリーフ・ライセンスを復号することができるように、クライアント／受信機のコンテンツ鍵（ルート・コンテンツ鍵）をセット・アップし安全に運ぶために利用される。いったんルート・コンテンツ鍵がクライアント／受信機に安全に配達されれば、様々なリーフ・ライセンス｛リーフ・コンテンツ鍵用のコンテンツ鍵は、クライアント／受信機に送られたルート・コンテンツ鍵を用いて、サーバ／送信機によって暗号化できる。ルート・コンテンツ鍵を使用すると、クライアントは、リーフ・ライセンスでのリーフ・コンテンツ鍵及び関連するポリシを復号することができる。リーフ・ライセンスの各々は、更に一意的な名称をメディア・ファイルの一部にリーフ・ライセンスを関連させることができるする。ここで、一意的な名前は、鍵ＩＤ又はＫＩＤと呼ばれ、リーフ１、リーフ２、．．．、リーフｎ）、ＫＩＤリーフｎというように、１からｎまでの番号が付されている。
【００４０】
提供するために、しかしどのように特にこのスキームをインプリメントすることができるかの１つの例、図６に関して下記を考慮する。特にこの例において、図６のシステムは１０２４ビットのＲＳＡ鍵を暗号のオペレーション及び１２８ビットのＡＥＳが対称な暗号のオペレーションのために施錠する公開鍵に使用するように構成される。もちろん、これは単なる一例として提供され、特許請求の範囲を制限することは、意図されない。
【００４１】
この例において、クライアント／受信機６００は、公開／秘密鍵のペア６５０を持っている。また、サーバ／送信機６０２にはクライアント／受信機の公開鍵がある。この例において、各々のクライアント／受信機の公開及び秘密鍵は、１０２４ビットのＲＳＡ鍵である。クライアント／受信機の公開鍵を使用して、サーバ／送信機は、クライアント／受信機の公開鍵で暗号化されるルート・コンテンツ鍵を含んでいるルート・ライセンスを構築する。ルート・コンテンツ鍵は１２８ビットのＡＥＳコンテンツ鍵である。その後、このルート・ライセンスはクライアント／受信機に送られる。図６では、暗号化されたルート・コンテンツ鍵が｛コンテンツ鍵ｒｏｏｔ｝ＣＬＩＥＮＴとして表わされる場合、これは、クライアント／受信機とサーバ送信機との間で生じる最初のコミュニケーションとして示され、評価される。しかし、絵入りのコミュニケーションに先立つそれ以外のコミュニケーションも生じうる。
【００４２】
サーバ／送信機から暗号化されたルート・コンテンツ鍵を受け取って、クライアント／受信機は、その秘密鍵を使用し、ルート・コンテンツ鍵を復号することができ、将来の使用のために復号されたルート・コンテンツ鍵を安全に格納することができる。
【００４３】
ここで以上で何が生じたのか確認したい。サーバ／送信機は、今、後の暗号のオペレーションの根拠として役立つことができるクライアント／受信機の鍵を安全に通信した。より明確には、単一のメディア・ファイル中の多数の特別のいくつかのＤＲＭに保護されたコンテンツに多数の特別のポリシが関係することがあると考えられる。この場合、サーバ／送信機は、複数のリーフを準備することができ、各々を許可する、デジタル著作権管理ポリシ及び特別のリーフ・コンテンツ鍵の暗号化されたバージョンを含む。この例において、リーフ・コンテンツ鍵はそれぞれ、ルート・コンテンツ鍵を使用して暗号化された１２８ビットのＡＥＳコンテンツ鍵である。従って、復号する新しく付加的なリーフに関連したクライアント／受信機によって経験され招かれた計算量及び費用は、鍵を満足させ、１０２４ビットのＲＳＡ鍵操作に関連したその上に縮小されるので、クライアント／受信機は、復号する必要があり、１２８ビットのＡＥＳコンテンツ鍵（つまりルート・コンテンツ鍵）を用いる。
ＨＴＴＰ
以上では、ルート及びリーフ・ライセンスについての概念について議論した、そして、各々は、どのように上に記述されたコンテキスト中で雇うことができるか、ルート及びリーフ・ライセンスはどのようにＨＴＴＰを使用して伝えることができるかを検討する。
【００４４】
ＨＴＴＰがＤＲＭに保護されたコンテンツを運ぶために利用される場合、クライアントはサーバ／送信機への２つのリクエストを出す。最初に、クライアントは、ルート・ライセンスを検索するＰＯＳＴリクエストを出す。次に、クライアントは、ＤＲＭに保護されたコンテンツの検索のＧＥＴ要請を出す。ＨＴＴＰでは、サーバが典型的にはクライアントとのコミュニケーションを始めることができないので、クライアントは、この例におけるリクエストを出す。
【００４５】
特に、以下の説明に関し、図７を参照する。クライアントがルート・ライセンスを受け取りたい場合、それはサーバへのＰＯＳＴリクエストを出す。上に議論されるように、ＰＯＳＴリクエストはライセンス要求メッセージを含んでいる。この知らせを受けることに反応するので、サーバは、少なくとも１つの実施例中で、ＸＭＲの中で表現されるルート・ライセンスを含んでいるライセンス応答メッセージで応答する。ルート・ライセンスを受け取ったこと、またそれを従って処理し、クライアントはＧＥＴを出し、ＤＲＭに保護されたコンテンツを求めるサーバに要求する。ＧＥＴリクエストに反応するので、サーバは、１つ以上のライセンス応答メッセージがはさまれた、要求されたコンテンツのセグメントで返答する。ライセンス応答メッセージは各々、ＤＲＭの特別の部分に関係するリーフ・ライセンスである保護されたコンテンツを含む。どんな適切な機構又はインタリービング・テクニックもサーバの返答の公式化のために使用することができる。
【００４６】
単に１つの特別のコンテキスト中の１つのインプリメンテーションの例として、下記を検討する。
【００４７】
ある１つの例では、４バイトのフレーミング・ヘッダはデータと管理区画をカプセルに入れるために使用される。フレーミング・ヘッダは１バイトのＡＳＣＩＩドル記号（０Ｘ２４）を含んでいる、ネットワーク・バイトオーダー中で表わされたカプセルに入れられたデータの２人のバイト長が後続する１バイトのブロック識別子によって続いた。
【００４８】
【表４】
2009505506.tif 000006
制御ブロックは、そのタイプＩＤとしてＡＳＣＩＩ「ｃ」キャラクタ（０ｘ６３）を使用する。このブロックは、メッセージを典型的に含むライセンス応答メッセージである。
【００４９】
データ・ブロックは、そのタイプＩＤとして、ＡＳＣＩＩ「ｄ」キャラクタ（０ｘ６３）を使用する。このブロックは、媒体データが直後に続くデータ・セグメント・デスクリプタを含んでいる。
【００５０】
データ・セグメントデスクリプタは、暗号化されるコンテンツ又は明瞭に関係している可能性がある。デスクリプタ中の暗号化されたフラグはこの情報を伝える。データ・セグメント・デスクリプタは対応付けられる送信されたファイルの一部や、もし暗号化されれば、単一のポリシ及びコンテンツ暗号鍵は当てはまる。言いかえれば、コンテンツ暗号鍵及びポリシはセグメントの内で変更することができない。
【００５１】
１つの実施例に従って、リンク暗号化を備えた典型的なＨＴＴＰレスポンスは次ブロックで構成される：
１．連鎖式のライセンスを備えたライセンス応答メッセージを伝える制御ブロック［＄ｃ］。
【００５２】
２．１つ以上のデータ・ブロック［＄ｄ］。
【００５３】
ファイルのトランスミッションの間に鍵かポリシの変更があった場合、その後に下記の工程は加えられる：
３．新しいつながれたライセンスを備えたライセンス応答メッセージを伝える新しい制御ブロック［＄ｃ］。
【００５４】
４．１つ以上のデータ・ブロック［＄ｄ］。
【００５５】
複数の鍵又は政策変更の場合には、ステップ３及び４が生じることがあることに注意すべきである。
複数のリーフ・ライセンスを備えた単一の暗号化されたメディア・ファイル
単一の暗号化されたメディア・ファイルは、ツールによって異なるポリシに部分を関連することができる。単一の暗号化されたメディア・ファイルは、任意のコンテンツ・タイプ（例えばＡＳＦ、ＭＰＥＧ、ＷＡＶ又は他のファイル）で、様々な制御プロトコルを使用して転送されることがある。
【００５６】
下記では、図８の実施例における単一のメディア・ファイル８００を暗号化し、７つの部分８０２、８０４、８０６、８０８、８１０、８１４の図解である。このメディア・ファイルがミュージック・ビデオの歴史に関するメディア番組であると仮定する。前半部はミュージック・ビデオへの入門である、第２はミュージック・ビデオである、３番目、広告、４番目は別のミュージック・ビデオである、５番目は別のミュージック・ビデオである、６番目は別の広告である。また、７番目はプログラムへの結論である。
【００５７】
ここで、メディア番組の創造者は、様々な部分のための異なる権利を持つことを望む。クリエータ（創造者）は、メディア番組のユーザーがイントロダクションと結論の部分を実行し、それらを一定の回数だけコピーすることを喜んで可能にすることがある。創造者は、喜んでミュージック・ビデオへの同じ権利を与えないことがあるし、プログラムの創造者がこれらのミュージック・ビデオを所有しないとここで仮定する。従って、それらは役に立つ異なるポリシに従う。創造者は更に喜んで自由に広告を使用することがある。また、従って、それらはコピーされ、使用されることがあり、ユーザーが好きな任意の方法中で実行した。
【００５８】
使用法を管理するために、それぞれがこれらの部分のうち、各々は対応付けられるポリシである。ここに、ポリシは、ＫＩＤとコンテンツの鍵があるリーフ・ライセンスにある。１つのルート・ライセンス及び５つのリーフ・ライセンスがこのメディア番組用に受け取られると仮定する。リーフ・ライセンスは８１６、８１８、８２０、８２２及び８２４で図８に示される。リーフ・ライセンスの各々にはユニークなＫＩＤ（ＫＩＤ１、ＫＩＤ２、ＫＩＤ３、ＫＩＤ４及びＫＩＤ５）及びユニークなリーフ・コンテンツ鍵（リーフ、ｋｅｙ１リーフを満足させる、ｋｅｙ２を満足させる、リーフ、ｋｅｙ３を満足させる、リーフ、ｋｅｙ４とリーフを満足させる、ｋｅｙ５を満足させる）がある。リーフ・ライセンスはそれぞれ更にポリシ（ｐｏｌｉｃｙｌ、ｐｏｌｉｃｙ２、ｐｏｌｉｃｙ３、ｐｏｌｉｃｙ４及びポリシ５）又は媒体を使用するためのある権利以外にそれぞれ関連する部分のを可能にすることを含む。他の言語は使用されてもよいが、これらのリーフ・ライセンスはＸＭＲ（拡張可能な媒体権）の中で表現される。
【００５９】
第１のポリシ（リーフ・ライセンス＃１のそれ）は、１０回まで実行されるためにそれに関連した媒体を許し、３回以内コピーした。このポリシは従って、イントロダクション及び実行されるプログラムの結論を許し、一定回数をコピーした。
【００６０】
第２のポリシは、一度だけ実行され、かつコピーされないためにそれに関連した媒体を許す。従って、プログラムの最初のミュージック・ビデオは、一度だけ再生することができる。ユーザーが全プログラムを実行することを試みる場合、２回目、このビデオは実行しない。
【００６１】
第３のポリシは、望まれた任意の方法で使用されるためにそれに関連した媒体を許す。ポリシはそれ自身これを述べることができる。プレー、複写又は関連する媒体の他の使用上に制限はない。いくつかの実施例では、しかし、媒体の部分はその代りに、明瞭な（暗号化されなかった）ものにあることがある。この一例が下記に述べられる。いずれの場合も、第１と第２の両方の広告は望まれた任意の方法で使用されてもよい。
【００６２】
４番目のポリシは、それに関連した媒体を許すーザーの好きなだけ多くの回実行され、しかしコピーすることができない。従って、第２のミュージック・ビデオは再生することができるが、コピーすることができない。
【００６３】
５番目のポリシは、ユーザーが好きでコピーしたのと同じくらい多くの回だがアナログファイルとしてのみ実行されるためにそれに関連した媒体を許す。従って、３番目のミュージック・ビデオは再生されることがあり、ある方法のみでコピーした。
【００６４】
各々（部分）とライセンスの間の関連性は破線を備えた図８に示される。ツールがこの結合を設立することがある方法は、より非常に詳しく下に述べられる。
デスクリプタ
このツールは、単一のメディア・ファイルの部分にポリシを関連させることができる。図８の絵入りで記述された実施例を継続して、部分の各々はリーフ・ライセンスによってポリシに関係している。この結合がどのように設立されることがあるかよりよく説明するために、単一のメディア・ファイル８００の１つの部分は、より非常に詳しく図解されている。
【００６５】
図９は、メディア・ファイル８００をこの部分がポリシに関係しているかもしれない１つの方法を示すために拡張した４番目の部分８０８で例証する。ここで、メディア・ファイルは、部分で一般に順番に受け取られる。この例で、ルート・ライセンスは受け取られる、最初のリーフ・ライセンスによって続いた、メディア・ファイルの前半部によって続いた、第２のリーフ・ライセンスによって続いた、第２の部分によって続いた、などである。ここで、リーフ・ライセンスは必ずしもすべては、上に記述されるようなメディア・ファイルの始めを受け取る前に受け取られない。このため、最初でと３番目リーフ・ライセンスは、それら（従って、最初のリーフ・ライセンスは前半部、及び再び７番目の部分の前に送られることがある）に関連した部分に先立って再び送られることがある。
【００６６】
新しいポリシがメディア・ファイルの一部のために続かれることになっている場合、新しいリーフ・ライセンス（ここに４番目のリーフ・ライセンス８２２）は、４番目のリーフ・ライセンスに関連した媒体の一部に先立って送られる。
【００６７】
ここで、リーフ・ライセンスは４番目の部分８０８のデータ・セグメント９０４−９１４を後に続けて、制御ブロック９０２の一部として送られる。ＲＴＳＰでは、しかし、ライセンスはＳＤＰデスクリプタかＡＮＮＯＵＮＣＥメッセージに伝えられる。リーフ・ライセンス及びデータの使用及びコミュニケーションは更に上記の図７に関係のある銘柄で述べられるように、ＲＴＳＰを使用することがあるが、特にこの実施例はＨＴＴＰの使用に注目する。制御ブロックは、図８及び９のリーフ・ライセンス８２２を含む。リーフ・ライセンスにはリーフ・コンテンツｋｅｙ４、ｐｏｌｉｃｙ４及びＫＥＤ４がある。いったん受け取られたならば、４番目のリーフ・ライセンスはルート・コンテンツ鍵を使用して復号することができる。ＫＩＤの中で送ることができ、明瞭か暗号化され、しかし復号することができる。
【００６８】
データ・セグメントの各々は対応付けられる、ポリシ、ここで、データ・セグメント９０４−９１４は対応付けられる、対応する４番目のポリシ。この結合は４番目のリーフ・ライセンスのＫＩＤで設立される。ＫＩＤ（すなわちＫＩＤに関連した識別子）は各データ・セグメントに格納される。ＫＩＤは、比較的短い１片（記憶の１バイト未満の整数引き受けさえ）の情報でありえる。従って、受信機は、適切なポリシを示すＫＩＤに基づいた適切なポリシにデータ・セグメントを関連させることができる。デスクリプタは様々な制御及びデータプロトコルと共に使用することができる。また、今存在有無中のパケット構造又はそれは今後作られることがある。そのような典型的な１つのデータプロトコルはＲＴＰである。ここで、デスクリプタは各パケットのエンドへ付加され適応する。別の実施例では、ＨＴＴＰ制御プロトコルは使用される。ここで、デスクリプタは各フレームの初めにアペンドされて適応させられる。
【００６９】
図１０は、ＲＴＳＰに従ってリーフ・ライセンスにデータ・セグメントを関連させるデスクリプタを例証する。
【００７０】
この例において、データ・セグメント１０００はＲＴＰペイロード・フォーマット・ヘッダ１００８及びペイロードデータ１０１０を含むことができる。ここで、ペイロードデータ及びペイロード・フォーマット・ヘッダは暗号化される、その一例は、図１１の一部と下に評される。
【００７１】
ここで、データプロトコルによって許されたどんな適切な場所でもそれを置くことができるが、デスクリプタは、ＲＴＰプロトコルを与えるペイロード・データのエンドへアペンドされる。当業者は理解するように、ペイロード・データの端にデスクリプタを置くことは後方互換性問題を緩和することがある。
【００７２】
この実施例（ＲＴＰパケット）では、ＲＴＰヘッダの例外で、デスクリプタ１０１２に関係している。デスクリプタ１０１２は、次には、それでペイロード・データ１０１０及びＲＴＰペイロード・フォーマット・ヘッダ１００８が復号されることを（例えば４番目のリーフ・コンテンツ鍵に関連した初期化ベクトル（ＩＶ））可能にする復号プロセスの中で使用することができる暗号化パラメーターを運ぶ。特にこの例において、単一のポリシとコンテンツの暗号鍵はペイロードデータ１０１０に当てはまる。
【００７３】
１つの実施例によると、デスクリプタ１０１２は以下のようにデータ構造を含む。
【００７４】
【表５】
2009505506.tif 000007
この例において、フラグ・セクションはデータ・セグメントの少しのフィールドの示す属性である。次のビットが現在定義される。すなわち、ビット０（暗号化されたデータ）である。このビットが１にセットされる場合、それはデータ・セグメントが暗号化されたフォームであることを示す。そうでなければ、データ・セグメントは明瞭になる。
【００７５】
延期セクションはＫＩＤとＩＶを含み、ＫＩＤはＫＩＤ４である。また、ＩＶはリーフ・コンテンツｋｅｙ４に関係している。
【００７６】
延期セクションに関して、延期フィールドの数は、このデスクリプタに含まれた可変長延期の数を示す。可変長拡大体に関して、延期にはそれぞれ次のフォーマットがある：
【００７７】
【表６】
2009505506.tif 000008
１つの実施例に従って、ＫＩＤとＩＶは以下のように定義される。
ＫＩＤ
延長（延期）タイプ：  鍵ＩＤの延期のために１に設定されなければならない。
【００７８】
延長の長さ：  １６にセットされ、１２８ビット（１６バイト）に相当する。
【００７９】
延長：  このデスクリプタと共に運ばれ、暗号化された媒体用の重要なＩＤ値を含む。暗号化されたデータフラグが１にセットされる場合のみ、この延期が使用される。
初期化ベクトル（ＩＶ）
延長タイプ：  初期化ベクトル延期用に２にセットされる。
【００８０】
延長の長さ：  ８にセットされ、６４ビット（８バイト）に相当する。
【００８１】
延長：  このデスクリプタと共に運ばれ、暗号化された媒体用の初期化ベクトルを含み、暗号化されたデータフラグが１にセットされる場合のみ、この延期が使用される。長さセクションに関して、この実施例では、このセクションは、バイトにデスクリプタの合計長さを含んでいるに違いない。この長さは、このデスクリプタと共に運ばれた媒体データのサイズを含んでいない。
コンテンツ独立なデータ暗号化
図１１は、１つの実施例に従って方法のステップについて記述するフローダイアグラムである。この方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア又はその組合せとして実行可能である。１つの実施例では、この方法は、上に例証され記述されたもののようなシステムに関して実現することができる。更に、続くディスカッションでは、実行される行為（動作）のうちのいくつかはサーバ／送信機によって実行されることとして描かれる。また、他の行為はクライアント／受信機によって実行されることとして描かれる。サーバ／送信機及びクライアント／受信機の例は、上で提供された。
【００８２】
ステップ１１０２は、メディア・ファイルを受け取る。メディア・ファイルにはメディア・ファイルがデータ・セグメントに分割され、暗号化され、送受信され、復号されることを可能にするどんなコンテンツ・タイプもありえる。それは、例えばＡＳＦ、ＭＰＥＧ２  ＴＳ、ＭＰＥＧ２  ＥＳ又はＷＡＶファイルでありえる。
【００８３】
ステップ１１０４は、メディア・ファイルをデータ・セグメントに分割する。これらのデータ・セグメントはパケット、他の数片のデータ又はＲＴＰ又はＨＴＴＰのような様々な制御プロトコルに一致するフレームを含むことができる。
【００８４】
ステップ１１０６は、各データ・セグメントを暗号化する。ステップ１１０６はここに記述された実施例のうちのどれによってもそうすることがある。従って、それは、リーフ・コンテンツ鍵を備えたペイロードデータを暗号化し、ルート・コンテンツ鍵でそのリーフ・コンテンツ鍵を暗号化することがある。ルート・コンテンツ鍵で、受信機は後でリーフ・コンテンツ鍵を復号し、ペイロードデータを復号するそのリーフ・コンテンツ鍵を使用することがある。
【００８５】
１つの実施例では、ステップ１１０６は、それの反対のモードの中でＡＥＳを使用する個々のデータ・セグメント又は部分を暗号化する。図１２は、このテクニックを使用して、単一データ・セグメントを暗号化する過程を図解する。この実施例では、反対のモードは、データ・セグメントのクリアテキスト・バイトとＸＯＲされるバイトのストリームを作る暗号化されたデータ・セグメントを作成する。重要なストリーム・ジェネレータは、一度に鍵・ストリームの１６バイトのブロックを生成するためにＡＥＳラウンドを使用する。ＡＥＳラウンドへのインプットは、コンテンツ暗号鍵（Ｋｃ）（例えばリーフ・コンテンツ鍵）、データ・セグメントＩＤの１２８ビットの縦続及びデータ・セグメント内のブロック番号である。
【００８６】
鍵ストリーム・ジェネレータのアウトプットはバイトごとにＸＯＲされたデータ・セグメントの対応ブロック（ｉ）からのデータを備えたバイトによる。データ・セグメントが１６バイトずつ平等に割り切れないというその場合では、最後のブロックからの媒体データの有効バイトだけが、ＸＯＲされるべきである重要なストリームを備え、また暗号化されたデータ・セグメントのために保存された。
【００８７】
ステップ１１０８は各暗号化されたデータ・セグメントにデスクリプタを追加する。デスクリプタはＫＩＤ、ＩＶ又はここに述べられた他のエレメントを含むことができる。デスクリプタはそれぞれ、データ・セグメントのペイロードデータが管理されるべき関連するデジタル著作権管理ポリシを示す。このデジタル著作権管理ポリシは、１つの上記の実施例によれば、以前に受信リーフ・ライセンス内に含まれている。デスクリプタはそれぞれ更にデータ・セグメントを復号するのに使用可能なコンテンツ鍵（例えば特別のリーフ・コンテンツ鍵）を示すことができる。
【００８８】
これらのステップの結果がデータ・セグメント、暗号化された各データ・セグメント、及び暗号化されたデータが後でデジタル著作権管理ポリシに関係しているかもしれないデスクリプタを持っていることへ故障した任意のコンテンツ・タイプのメディア・ファイルでありえることに注意すべきである。
【００８９】
１つの実施例では、デスクリプタは長さインジケータを含んでいる。この長さインジケータで、暗号化されたデータ・セグメントの受信機は、デスクリプタがいつ終了するか始まるか決めることができる。この長さインジケータは、データ・セグメント又はそのパケット中の様々な場所で暗号化されたデータ・セグメントにデスクリプタが加えられることを可能にする。ＲＴＰプロトコルについては、例えば、デスクリプタは、データ・セグメントがあるＲＴＰパケットのエンドに加えられる。ＨＴＴＰプロトコルについては、例えば、デスクリプタはデータ・セグメントがあるフレームの始めに加えられる。認識可能な長さを過ごすことによって、データ・セグメントの様々な部分にデスクリプタを追加することができこのように、様々な転送プロトコルを備えたデスクリプタの使用を可能にすることができることに注意すべきである。
【００９０】
ステップ１１１０は、受信機にデスクリプタで暗号化されたデータ・セグメント（またもしあれば明瞭なデータ・セグメント）を送信する。受信機は、当技術中で既知であるようにデータ・セグメントを適応させることを（例えば正確なオーダーでの配設位置）可能にされる。受信機は、データ・セグメントに関連したコンテンツ鍵を使用して、データ・セグメントを復号することがある。更に、デスクリプタを使用する受信機、鍋、メディア・ファイル又はそれの部分と共にどの権利ポリシを使用しなければならないか決める。メディア・ファイルに異なる権利ポリシによって管理されるべき部分がある場合、この方法は更にメディア・ファイルのそれらの部分に基づいたデータ・セグメントを分割し、ステップ１１０４で異なる部分のデータ・セグメントに異なるデスクリプタを帰することができる。
【００９１】
ステップ１１１２は、暗号化されたデータ・セグメントを受け取り復号する。受信機（クライアント／受信機５００又は６００のような）はデータ・セグメントを復号し、そのデスクリプタに基づいて、適切な権利ポリシを割り当てる。１つの実施例では、受信機は、デスクリプタの中で初期化ベクトルを使用して、データ・セグメントを復号する。受信機は、ＫＩＤに基づいた適切なリーフ・コンテンツ鍵を決定する。その後、それは、ルート・コンテンツ鍵でリーフ・コンテンツ鍵を復号した後にデータ・セグメントを復号するためにそれを使用する。
【００９２】
ステップ１１１４は、権利ポリシに各データ・セグメントを関連させる。１つの実施例では、受信機は、デスクリプタ及び権利ポリシを持っているリーフ・ライセンスで見出される重要なＩＤ（ＫＩＤ）を用いて、それを行う。
ルート及びリーフ・ライセンスの使用
図１３は、１つの実施例に従って方法のステップについて記述するフローダイアグラムである。この方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア又はその組合せに関して行なうことができる。１つの実施例では、この方法は、上に例証され記述されたもののようなシステムに関して実現することができる。更に、続くディスカッションでは、行なわれる行為のうちのいくつかはサーバ／送信機によって行なわれることとして描かれる。また、他の行為はクライアント／受信機によって行なわれることとして描かれる。サーバ／送信機及びクライアント／受信機の例は上に提供される。
【００９３】
ステップ１３００はクライアント／受信機の公開鍵を使用して、ルート・コンテンツ鍵を暗号化する。どんな適切なコンテンツ鍵でも利用することができる、しかし上に挙げられているのは１つの例である。ステップ１３０２は、クライアント／受信機の暗号化されたルート・コンテンツ鍵を含んでいるルート・ライセンスを送る。どんな適切な方法もこのステップを実行するために利用することができる。続くディスカッションでは、２つの異なるプロトコルで引く２つの具体例が提供される。これらが例を構成し記述される特定のプロトコルだけへの要求された主題の応用範囲を狭めるようには意図されないことを理解すべきである。
【００９４】
ステップ１３０４は、サーバ／送信機によって送られたルート・ライセンスを受け取る。また、ステップ１３０６は暗号化されたルート・コンテンツ鍵を復号する。この例において、このステップは、暗号化されたルート・コンテンツ鍵を復号するためにクライアント／受信機の秘密鍵を使用することにより行なわれる。
【００９５】
ステップ１３０８はリーフ・ライセンスを準備し、ルート・コンテンツ鍵でリーフ・コンテンツ鍵を暗号化する。ステップ１３１０はクライアント／受信機にリーフ・ライセンスを送る。リーフ・ライセンスは典型的にはＤＲＭに保護されたコンテンツ用ポリシを含んでいることを想起すべきである。ステップ１３０８及び１３１０が与えられた１片のＤＲＭに保護されたコンテンツ用の実行された複数回でありえることを理解すべきである。すなわち異なるポリシを持っている各部分については、対応するリーフ・ライセンスは準備することができ、クライアント／受信機に送ることができる。
【００９６】
ステップ１３１２はリーフ・ライセンスを受け取る。また、ステップ１３１４は以前に受け取られたルート・コンテンツ鍵を使用して、リーフ・コンテンツ鍵を復号する。その後、ステップ１３１６は、コンテンツを復号する復号されたリーフ・コンテンツ鍵を使用する。更に、それは、上に記述されたデスクリプタを使用して、メディア・ファイル（メディア・ファイルに一部がある場合）の一部に適切なリーフ・ライセンスを関連させる。
【００９７】
クライアント／受信機によって受け取られる個々の新しいリーフ・ライセンスのためにステップ１３１２、１３１４及び１３１６を行なえることを理解すべきである。
結論
このドキュメントは、デジタル著作権管理ポリシが任意のコンテンツ・タイプか制御権移動プロトコルがあるデジタル媒体に関係していることがあるテクニックについて記述している。ある場合には、暗号化されたメディア・ファイルの受信機がこれによってファイルを復号し、異なるデジタル著作権管理ポリシによるファイルの部分を消費することができる。ある場合には、これが、更に送信機がテクニックの１つのセットを備えた様々なタイプのメディア・ファイルを暗号化することを可能にする。本発明は、構造的特徴及び／又は方法論のステップに特有の言語に述べられているが、冒頭の特許請求の範囲において定義された発明は、特定の特徴に必ずしも制限されない。より正確に言えば、特定の特徴及びステップは、特許請求の範囲に記載された発明を実行する好ましい形態で開示されている。
【図面の簡単な説明】
【００９８】
【図１】本発明の実施例をある１つの実施例で用いることができるプロトコルの例示的な登録手順を図解している。
【図２】本発明の実施例をある１つの実施例で用いることができるプロトコルの例示的な近接性検出手順を図解している。
【図３】本発明の実施例をある１つの実施例で用いることができるプロトコルの例示的なセッション確立手順を図解している。
【図４】本発明の実施例をある１つの実施例で用いることができるプロトコルの例示的なデータ転送手順を図解している。
【図５】本発明の実施例をある１つの実施例で用いることができるストリーミング・プロトコルの側面を図解している。
【図６】ある１つの実施例によりルーツ・ライセンス及びリーフ・ライセンスと関連付けされた側面を図解している。
【図７】ある１つの実施例によりルーツ・ライセンス及びリーフ・ライセンスと関連付けされた側面を図解している。
【図８】５つの異なる例示的なデジタル権利管理ポリシと関連付けられた７つの部分を有する例示的な単一のメディア・ファイルを図解している。
【図９】鍵ＩＤ（ＫＩＤ）と関連付けられた例示的なデータ・セグメントと有する図８の単一のメディア・ファイルを図解している。
【図１０】ある１つの実施例によるパケットを、図９に示されたデータ・セグメントに対して図解している。
【図１１】本発明によるツールがコンテンツ独立な暗号化及び復号化を可能にする１つの態様を示す流れ図である。
【図１２】ある１つの実施例によるサンプルの暗号化を図解している。
【図１３】ある１つの実施例によるルーツ及びリーフ・ライセンスの通信を示す流れ図である。
【図１】
2009505506.tif 000009
【図２】
2009505506.tif 000010
【図３】
2009505506.tif 000011
【図４】
2009505506.tif 000012
【図５】
2009505506.tif 000013
【図６】
2009505506.tif 000014
【図７】
2009505506.tif 000015
【図８】
2009505506.tif 000016
【図９】
2009505506.tif 000017
【図１０】
2009505506.tif 000018
【図１１】
2009505506.tif 000019
【図１２】
2009505506.tif 000020
【図１３】
2009505506.tif 000021
【国際調査報告】
2009505506.tif 000022
2009505506.tif 000023