JP5686951B2 - 様々なコンテンツ・タイプのデジタル媒体の保護 - Google Patents

Description

技術分野及び背景技術

デジタル権利管理（デジタル著作権管理、ＤＲＭ）は、電子デバイス上のデジタル・メディア・コンテンツの使用を制御又は制限するなどにより、コンテンツを保護するのに用いられる技術を指す。ＤＲＭの１つの特性は、ＤＲＭがメディア・コンテンツを与えられたマシン又はデバイスに結び付けることができるという点にある。従って、特別の１つコンテンツに関係しコンテンツに関連する権利と制限とを定義するライセンスは、与えられたマシン又はデバイスに結び付けられるのが通常である。その結果、ユーザーは、そのコンテンツを再生するためにコンテンツを取り出して別のマシンに移動させることが許されない。

現在のＤＲＭ技術は、制限を有する。それらは、デジタル媒体を転送する２つのタイプだけのプロトコルと互換性を有することが多い。すなわち、ＨＴＴＰ及びＲＴＳＰである。しかし、他のプロトコルが、現時点で又は将来に、デジタル媒体の転送により適していることがありうる。更に、ＤＲＭによって保護されるコンテンツは、特定のコンテンツ・タイプに限定される可能性がある。ある１つの特定のコンテンツ・タイプであるＡＳＦファイルは、ただ１組の権利及び制限（つまりポリシ）だけがＡＳＦファイルの全体に適用されることを許容する。例えば、ビデオ・ファイルのレンダリングの際には、ファイル全体の対するアナログ・ビデオ出力にマクロビジョンが要求されるか、又は、全く要求されないかのどちらかである。

発明の概要

任意のコンテンツ・タイプか転送制御プロトコルを有するデジタル媒体に関連するデジタル権利管理ポリシを可能にするシステム及び／又は方法（「ツール」）が説明される。いくつかの実施例では、ツールは、メディア・ファイルのデータ・セグメントを暗号化し、それらのセグメントのそれぞれにデスクリプタ（記述子）を追加する。これらのデスクリプタは、暗号化されたメディア・ファイルの受信機がファイルを復号し、当該受信機が正しいデジタル著作権管理ポリシによってそれを使用することを可能にすることができる。

この概要は、以下の詳細な説明において更に詳述される、単純化された形式を有する概念の選択を導入するために提供される。この概要は、特許請求された発明の主題の鍵となるすなわち基本的な特徴を識別することは意図していないし、特許請求された主題の範囲を確定するのに役立つことも意図していない。

概観
デジタル権利管理ポリシが任意のコンテンツ・タイプ又は転送制御プロトコルを有するデジタル媒体と関連付けされることを可能にするツールについて、説明する。いくつかの実施例では、このツールは、メディア・ファイルのデータ・セグメントを暗号化し、それらのセグメントのそれぞれにデスクリプタを追加する。これらのデスクリプタは、暗号化されたメディア・ファイルの受信機がファイルを復号し、当該受信機が正しいデジタル著作権管理ポリシに従ってそれを使用することを可能にする。

以下の議論では、「コンテンツセキュリティ及びライセンス転送プロトコル」とタイトルをつけられたセクションが提供され、本発明による技術を用いることができる１つの特別のシステムについて説明する。その後で、「ＲＴＳＰ」及び「ＨＴＴＰ」とタイトルをつけられたセクションが、これらのプロトコルに慣れていない読者に対して、本発明による技術に関する理解をここで提供する。

このセクションに続いて、「ルート及びリーフ・ライセンス」とタイトルをつけられたセクションが提供され、メディア・ファイルの多数の他のライセンスを可能にする当初のルート・ライセンスの概念について記述する。次のセクションでは、「複数のリーフ・ライセンスを備えた単一の暗号化されたメディア・ファイル」とダイされたセクションが提供され、メディア・ファイルの一部に関連したリーフ・ライセンスを使用して、どのようにしてメディア・ファイルを複数のデジタル著作権管理ポリシと関連付けるかについて説明する。

これらのセクションの後には、２つのセクションが続くが、その第１は「デスクリプタ」と題するものであり、第２は「コンテンツ独立なデータ暗号化」である。これらのセクションでは、メディア・ファイルのデータ・セグメントのためのデスクリプタと、デジタル・コンテンツのそのタイプにかかわらずメディア・ファイルの暗号化を可能にするようにツールがこれらのデスクリプタを使用する態様とについて、説明する。最後のセクションである「ルート及びリーフ・ライセンスを使用する」では、ツールがルート及びリーフ・ライセンスを使用する方法について記述する。
コンテンツ・セキュリティ及びライセンス転送プロトコル
以下では、セキュリティを提供しデジタル・リンクを介して流れるコンテンツのライセンスを転送する典型的なプロトコルに関する議論を提供する。このプロトコルは、ただ１つのプロトコルを構成し、そのプロトコルでは、様々な創造性のある技術を用いることができる。特許請求の範囲から逸脱することなく他のプロトコルを用いることができることが考えられる。

次の暗号学的な記号を、この明細書では用いる。

Ｋ｛データ｝： データは、秘密鍵Ｋを用いて暗号化される。

Ｋ［データ］： データは、秘密鍵Ｋを用いて署名される。

｛データ｝_デバイス： データは、デバイスの公開鍵を用いて暗号化される。

［データ］_デバイス： データは、デバイスの秘密鍵を用いて署名される。

この特定のプロトコルでは、５つの主要な手続きがある。すなわち、登録、再確認、近接性（proximity）検出、セッション確立、及びデータ転送である。

登録手順では、送信機、すなわち、別のデバイスに送信されることになっているコンテンツを有するデバイスは、一意的かつ安全に意図した受信機、すなわち、コンテンツが送信されることになっているデバイスを識別することができる。この特定のプロトコルでは、送信機は、登録された受信機と共にデータベースを維持し、小型の所定の数の受信機だけが同時に使用されることを保証する。登録手続中に、送信機は、近接性検出手順を用いて、保護されたコンテンツの広範な分配を防ぐため、ネットワークにおいて受信機が当該送信機に近接して位置していることを保証する。

再確認手続きは、受信機が引き続き送信機の近くにあることを保証するために利用される。もし過去の時間の所定期間内に登録されなかったし再確認されなかったならば、コンテンツは、受信機に配達されない。

セッション確立手順は、受信機が送信機にコンテンツを要請する場合には常に使用される。送信機は、セッション確立が完成されうる前に、デバイスが登録され最近確認されていることを強制する。

いったんセッションが確立されれば、要求されたコンテンツのデータ転送は、安全な方法で生じうる。受信機は、コンテンツの特定の部分を検索する（求める）ためにセッションを再使用することがあるが、異なるコンテンツを検索するために新しいセッションを確立しなければならない。

ここで、図１に関する登録手順と、送信機と受信機との間で送られる各種メッセージについて記述している次の表１とについて、考察する。

ここで、受信機は、他の情報と共に受信機のデジタル証明書を含む登録リクエスト・メッセージを送る。登録要求メッセージを受け取ることに反応して、送信機は、受信機の証明書を確認し、シーズ（種）及びランダム・セッションＩＤを生成し、上で示されている形式を有するのと同じものを、登録応答メッセージにおいて受信機に返送する。その後、受信機は、送信機の書名を確認し、セッションＩＤを得て、図の中で示された他の動作を行なう。次に、受信機と送信機は、下記に述べられる近接性検出プロセス（近接性検出プロセス）を経験することができる。

再確認に関しては、上に概説されるのと同じ手続きが実行され、再確認中の違いと共に行なわれ、受信機は、データベースに既に登録されている。

近接性検出に関しては、図２に関して下記を考慮してほしい。

近接性検出手続きの間に、受信機は、近接性検出初期設定メッセージの中で示されているセッションＩＤを含むメッセージを送信機に送る。その後、送信機は、受信機へノンス（１２８ビットのランダム値）を含んでいるメッセージを送り、受信機がコンテンツ暗号鍵を使用して暗号化されたノンスで応答するために要する時間を測定する。最後に、送信機は、近接性検出が成功したかどうか示すメッセージを受信機へを送る。

それが近接性検出が成功したという確証を有するまで、受信機は、プロセスを繰り返すことがある。特にこのプロトコルがＩＰベースのネットワーク上で使用される場合、近接性検出メッセージは、ＵＤＰの上で交換される。受信機は、登録応答メッセージを介して送信機のアドレスを学習する。受信機のアドレスは、別々に通信される必要はないが、その理由は、近接性検出初期設定メッセージを伝えるＵＤＰパケットの入ってくるＩＰヘッダを調べることにより、決定することができるからである。

次の表では、近接性検出の間に交換されるメッセージについて説明している。

セッション確立に関しては、図３と、セッション確立中に交換されるメッセージについて記述している次の表とを考察してほしい。

この例では、ライセンス要求メッセージは、受信機から送信機へ送られ、上に記述された情報を含んでいる。これを受けて、送信機は、上に記述された情報を含んでいるライセンス応答メッセージを送信することができる。

特にこの例において、ライセンスは、ＸＭＲフォーマットで表わされ、コンテンツ暗号鍵、コンテンツ保全（完全性、保全性、integrity）鍵、送信機のＣＲＬのバージョン、１２８ビットの権利ＩＤ、及び１２８ビットのシリアル番号を含んでいる。ライセンスは、更に、ＯＭＡＣを用いたコンテンツ完全性鍵を使用して計算されたＯＭＡＣを含んでいる。

データ転送手順に関しては、図４を参照しながら下記を考慮してほしい。セッション確立が完全ならば、データ転送は、制御プロトコルの特定のやり方で実行される。データ転送リクエストとレスポンスとの両方は、制御プロトコルとコンテンツ・タイプとのために特に定義されなければならない。これは、図４に概念的に表わされている。

以上では、本発明による実施例を用いることができる典型的なプロトコルの概要を提供したが、ここで、ＲＴＳＰに関するある背景的事項を考察する。

ＲＴＳＰ
当業者には理解されるように、リアルタイム・ストリーミング・プロトコルすなわちＲＴＳＰは、連続的な媒体（例えば、ストリーミングのようなリアルタイム・プロパティを備えたデータ）の配信の制御のためのアプリケーション・レベルのプロトコルである。ＲＴＳＰは、オーディオとビデオのような実時間データの制御されたオン・デマンドのデリバリ（配信）を可能にする拡張可能なフレームワークを提供する。データのソースは、実際のデータ・フィード及び格納されたクリップの両方を含むことができる。このプロトコルは、複数のデータ配信セッションを制御し、ＵＤＰのような配信チャネルを選ぶための手段を提供し、ＵＤＰとＴＣＰをマルチキャストし、ＲＴＰに基づいた配信機構を選ぶための手段を提供することを意図している。

ＲＴＳＰは、オーディオとビデオのような連続媒体の単一の又は複数の時間同期されたストリームを確立し制御する。制御ストリームを用いて連続媒体ストリームをインターリーブすることは可能であるが、典型的にはそれ自体連続的なストリームを伝えない。言いかえれば、ＲＴＳＰは、マルチメディア・サーバ用の「ネットワーク・リモート制御」として働く。

制御されるストリームの組は、提示記述によって定義される。ＲＴＳＰでは、ＲＴＳＰ接続についての概念は存在しない。代わりに、サーバは、識別子によってラベル付けされたセッションを維持する。ＲＴＳＰセッションは、ＴＣＰ接続のようなトランスポート・レベルの接続に結び付けられることは全くない。ＲＴＳＰセッションの間に、ＲＴＳＰクライアントは、ＲＴＳＰリクエストを出すサーバに、多くの信頼できるトランスポート接続を開閉することができる。又は、当業者であれば理解するように、ＵＤＰのようなコネクションレスのトランスポート・プロトコルを使用することがある。

ＲＴＳＰによって制御されたストリームは、ＲＴＰを使用することがある。しかし、ＲＴＳＰの動作は、連続媒体を運ぶために使用されるトランスポート機構に依存しない。

ここで、図５を参照しながら、クライアント／受信機５００とサーバ／送信機５０２の間の典型的なＲＴＳＰリクエスト／レスポンス交換を考察する。

まず、ＲＴＳＰリクエスト／レスポンスはヘッダを有するが、簡潔さのために、説明しない。ＲＴＳＰでは、クライアント／受信機５００は、典型的にはサーバ５０２からのリクエストＵＲＬによって識別された提示又はメディア・オブジェクトの説明の検索に向けられているＤＥＳＣＲＩＢＥリクエストとして知られているものを生じる。サーバ５０２は、ＳＥＳＳＩＯＮ ＤＥＳＣＲＩＰＴＩＯＮ ＰＲＯＴＯＣＯＬ（ＳＤＰ）で表わされる、要求されたリソースの説明で答える。ＤＥＳＣＲＩＢＥレスポンス（ＳＤＰ）は、それが記述するリソース用の媒体初期化情報をすべて含んでいる。

次に、クライアント５００は、ストリーミングされた媒体に使用されるトランスポート機構を指定するＵＲＩのＳＥＴＵＰリクエストを送信する。図５の例で、ＳＥＴＵＰリクエストは、オーディオとビデオの両方のために送信される。クライアント５００は、更にＳＥＴＵＰリクエストで、それが利用するトランスポート・パラメータを示す。ＳＥＴＵＰリクエストでのトランスポート・ヘッダは、データ伝送用のクライアントに受理可能なトランスポート・パラメータを指定する。サーバ５０２からのＲＥＳＰＯＮＳＥは、サーバによって選択されたトランスポート・パラメータを含んでいる。サーバは、更にＳＥＴＵＰリクエストに応じてセッション識別子を生成する。

この時点で、クライアントは、ＳＥＴＵＰの中で指定された機構によってデータを送信し始めるようにサーバに命じるＰＬＡＹリクエストを生じることができる。ＰＬＡＹリクエストを受け取ることに応答して、サーバは、この例では、オーディオ／ビデオ・コンテンツであるコンテンツのストリーミングを開始することができる。この例において、ストリーミング・コンテンツは、当業者が利用するように、ＲＴＰパケットを使用して、カプセル化され、ＵＤＰに送られる。

ＲＴＳＰプロトコルには、ＰＡＵＳＥ、ＴＥＡＲＤＯＷＮ、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＲＥＤＩＲＥＣＴ及びＲＥＣＯＲＤを含んでいる他の興味のある方法がある。ＲＴＳＰに関する補足的な背景については、読者は、ＲＴＳＰ ＲＦＣ、Ｓｃｈｕｌｚｒｉｎｎｅ、Ｈ、Ｒａｏ．Ａ、及びＲ．Ｌａｎｐｈｉｅｒによる「リアルタイム・ストリーミング・プロトコル」（ＲＴＳＰ）、ＲＦＣ ２３２６を参照すべきである。これは、１９９８年４月において、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２３２６．ｔｘｔにおいて入手可能である。
ルート及びリーフ・ライセンス
図示されて説明された実施例では、ルート・ライセンス及びリーフ・ライセンスについての概念が用いられる。ここで、ルート・ライセンスはクライアント／受信機が続いて伝えられたリーフ・ライセンスを復号することができるように、クライアント／受信機のコンテンツ鍵（ルート・コンテンツ鍵）をセット・アップし安全に運ぶために利用される。いったんルート・コンテンツ鍵がクライアント／受信機に安全に配達されれば、様々なリーフ・ライセンス｛リーフ・コンテンツ鍵用のコンテンツ鍵は、クライアント／受信機に送られたルート・コンテンツ鍵を用いて、サーバ／送信機によって暗号化できる。ルート・コンテンツ鍵を使用すると、クライアントは、リーフ・ライセンスでのリーフ・コンテンツ鍵及び関連するポリシを復号することができる。リーフ・ライセンスの各々は、更に一意的な名称をメディア・ファイルの一部にリーフ・ライセンスを関連させることができるする。ここで、一意的な名前は、鍵ＩＤ又はＫＩＤと呼ばれ、リーフ１、リーフ２、．．．、リーフｎ）、ＫＩＤ_リーフｎというように、１からｎまでの番号が付されている。

この特定のスキームをどのように実施することができるかについてのほんの１つの例を提供するために、図６に関して下記を考慮する。特にこの例において、図６のシステムは１０２４ビットのＲＳＡ鍵を暗号のオペレーション及び１２８ビットのＡＥＳが対称な暗号のオペレーションのために施錠する公開鍵に使用するように構成される。もちろん、これは単なる一例として提供され、特許請求の範囲を制限することは、意図されない。

この例において、クライアント／受信機６００は、公開／秘密鍵のペア６５０を持っている。また、サーバ／送信機６０２にはクライアント／受信機の公開鍵がある。この例において、各々のクライアント／受信機の公開及び秘密鍵は、１０２４ビットのＲＳＡ鍵である。クライアント／受信機の公開鍵を使用して、サーバ／送信機は、クライアント／受信機の公開鍵で暗号化されるルート・コンテンツ鍵を含んでいるルート・ライセンスを構築する。ルート・コンテンツ鍵は１２８ビットのＡＥＳコンテンツ鍵である。その後、このルート・ライセンスはクライアント／受信機に送られる。図６では、暗号化されたルート・コンテンツ鍵が｛コンテンツ鍵_ｒｏｏｔ｝_{ＣＬＩＥＮＴ}として表わされる場合、これは、クライアント／受信機とサーバ送信機との間で生じる最初のコミュニケーションとして示され、評価される。しかし、絵入りのコミュニケーションに先立つそれ以外のコミュニケーションも生じうる。

サーバ／送信機から暗号化されたルート・コンテンツ鍵を受け取って、クライアント／受信機は、その秘密鍵を使用し、ルート・コンテンツ鍵を復号することができ、将来の使用のために復号されたルート・コンテンツ鍵を安全に格納することができる。

ここで以上で何が生じたのか確認したい。サーバ／送信機は、今、後の暗号のオペレーションの根拠として役立つことができるクライアント／受信機の鍵を安全に通信した。より明確には、単一のメディア・ファイル中の多数の特別のいくつかのＤＲＭに保護されたコンテンツに多数の特別のポリシが関係することがあると考えられる。この場合、サーバ／送信機は、複数のリーフを準備することができ、各々を許可する、デジタル著作権管理ポリシ及び特別のリーフ・コンテンツ鍵の暗号化されたバージョンを含む。この例において、リーフ・コンテンツ鍵はそれぞれ、ルート・コンテンツ鍵を使用して暗号化された１２８ビットのＡＥＳコンテンツ鍵である。従って、復号する新しく付加的なリーフに関連したクライアント／受信機によって経験され招かれた計算量及び費用は、鍵を満足させ、１０２４ビットのＲＳＡ鍵操作に関連したその上に縮小されるので、クライアント／受信機は、復号する必要があり、１２８ビットのＡＥＳコンテンツ鍵（つまりルート・コンテンツ鍵）を用いる。
ＨＴＴＰ
以上では、ルート及びリーフ・ライセンスについての概念、及び、上述の文脈においてそれぞれをどのように用いることができるかについて議論したが、ここで、ルート及びリーフ・ライセンスはどのようにＨＴＴＰを使用して伝えることができるかを検討する。

ＨＴＴＰがＤＲＭに保護されたコンテンツを運ぶために利用される場合、クライアントはサーバ／送信機への２つのリクエストを出す。最初に、クライアントは、ルート・ライセンスを検索するＰＯＳＴリクエストを出す。次に、クライアントは、ＤＲＭに保護されたコンテンツの検索のＧＥＴ要請を出す。ＨＴＴＰでは、サーバが典型的にはクライアントとのコミュニケーションを始めることができないので、クライアントは、この例におけるリクエストを出す。

特に、以下の説明に関し、図７を参照する。クライアントがルート・ライセンスを受け取りたい場合、それはサーバへのＰＯＳＴリクエストを出す。上に議論されるように、ＰＯＳＴリクエストはライセンス要求メッセージを含んでいる。この知らせを受けることに反応するので、サーバは、少なくとも１つの実施例中で、ＸＭＲの中で表現されるルート・ライセンスを含んでいるライセンス応答メッセージで応答する。ルート・ライセンスを受け取ったこと、またそれを従って処理し、クライアントはＧＥＴを出し、ＤＲＭに保護されたコンテンツを求めるサーバに要求する。ＧＥＴリクエストに反応するので、サーバは、１つ以上のライセンス応答メッセージがはさまれた、要求されたコンテンツのセグメントで返答する。ライセンス応答メッセージは各々、ＤＲＭの特別の部分に関係するリーフ・ライセンスである保護されたコンテンツを含む。どんな適切な機構又はインタリービング・テクニックもサーバの返答の公式化のために使用することができる。

単に１つの特別のコンテキスト中の１つのインプリメンテーションの例として、下記を検討する。

ある１つの例では、４バイトのフレーミング・ヘッダはデータと管理区画をカプセルに入れるために使用される。フレーミング・ヘッダは１バイトのＡＳＣＩＩドル記号（０Ｘ２４）を含んでいる、ネットワーク・バイトオーダー中で表わされたカプセルに入れられたデータの２人のバイト長が後続する１バイトのブロック識別子によって続いた。

制御ブロックは、そのタイプＩＤとしてＡＳＣＩＩ「ｃ」キャラクタ（０ｘ６３）を使用する。このブロックは、メッセージを典型的に含むライセンス応答メッセージである。

データ・ブロックは、そのタイプＩＤとして、ＡＳＣＩＩ「ｄ」キャラクタ（０ｘ６３）を使用する。このブロックは、媒体データが直後に続くデータ・セグメント・デスクリプタを含んでいる。

データ・セグメント・デスクリプタは、暗号化された又は普通の文のコンテンツに関係付けられていることができる。デスクリプタ中の暗号化されたフラグはこの情報を伝える。データ・セグメント・デスクリプタは、送信されたファイルの部分に関係付けられており、暗号化されれば、そのファイルの部分に対して単一のポリシ及びコンテンツ暗号鍵が適用される。言いかえれば、コンテンツ暗号鍵及びポリシはセグメントの内で変更することができない。

１つの実施例に従って、リンク暗号化を備えた典型的なＨＴＴＰレスポンスは次ブロックで構成される：
１．連鎖式のライセンスを備えたライセンス応答メッセージを伝える制御ブロック［＄ｃ］。

２．１つ以上のデータ・ブロック［＄ｄ］。

ファイルのトランスミッションの間に鍵かポリシの変更があった場合、その後に下記の工程は加えられる：
３．新しいつながれたライセンスを備えたライセンス応答メッセージを伝える新しい制御ブロック［＄ｃ］。

４．１つ以上のデータ・ブロック［＄ｄ］。

複数の鍵又は政策変更の場合には、ステップ３及び４が生じることがあることに注意すべきである。
複数のリーフ・ライセンスを備えた単一の暗号化されたメディア・ファイル
単一の暗号化されたメディア・ファイルは、ツールによって異なるポリシに部分を関連することができる。単一の暗号化されたメディア・ファイルは、任意のコンテンツ・タイプ（例えばＡＳＦ、ＭＰＥＧ、ＷＡＶ又は他のファイル）で、様々な制御プロトコルを使用して転送されることがある。

下記では、図８の実施例における単一のメディア・ファイル８００を暗号化し、７つの部分８０２、８０４、８０６、８０８、８１０、８１４の図解である。このメディア・ファイルがミュージック・ビデオの歴史に関するメディア番組であると仮定する。前半部はミュージック・ビデオへの入門である、第２はミュージック・ビデオである、３番目、広告、４番目は別のミュージック・ビデオである、５番目は別のミュージック・ビデオである、６番目は別の広告である。また、７番目はプログラムへの結論である。

ここで、メディア番組の創造者は、様々な部分のための異なる権利を持つことを望む。クリエータ（創造者）は、メディア番組のユーザーがイントロダクションと結論の部分を実行し、それらを一定の回数だけコピーすることを喜んで可能にすることがある。創造者は、喜んでミュージック・ビデオへの同じ権利を与えないことがある；ここで、プログラムの創造者がこれらのミュージック・ビデオを所有せず、従って、これらのミュージック・ビデオが使用について異なるポリシに従うと仮定する。創造者は更に喜んで自由に広告を使用することがある。また、従って、それらはコピーされ、使用されることがあり、ユーザーが好きな任意の方法中で実行した。

これらの部分のうちのそれぞれの使用法を管理するために、それぞれの部分はポリシと関連付けられる。ここに、ポリシは、ＫＩＤとコンテンツの鍵があるリーフ・ライセンスにある。１つのルート・ライセンス及び５つのリーフ・ライセンスがこのメディア番組用に受け取られると仮定する。リーフ・ライセンスは８１６、８１８、８２０、８２２及び８２４で図８に示される。リーフ・ライセンスの各々にはユニークなＫＩＤ（ＫＩＤ１、ＫＩＤ２、ＫＩＤ３、ＫＩＤ４及びＫＩＤ５）及びユニークなリーフ・コンテンツ鍵（リーフ・コンテンツ鍵 _１ 、リーフ・コンテンツ鍵 _２ 、リーフ・コンテンツ鍵 _３ 、リーフ・コンテンツ鍵 _４ 、及びリーフ・コンテンツ鍵 _５ ）がある。リーフ・ライセンスはそれぞれ更に、それぞれの関連付けられた部分の媒体を用いる権利を許容する又は除外するポリシ（ポリシ _ｌ 、ポリシ _２ 、ポリシ _３ 、ポリシ _４ 及びポリシ _５ ）を含む。他の言語は使用されてもよいが、これらのリーフ・ライセンスはＸＭＲ（拡張可能な媒体権）の中で表現される。

第１のポリシ（リーフ・ライセンス＃１のそれ）は、それに関連した媒体が１０回まで再生され、３回までコピーされることを許す。このポリシは従って、プログラムの始めと終わりが一定回数だけ再生され、コピーされることを許す。

第２のポリシは、一度だけ実行され、かつコピーされないためにそれに関連した媒体を許す。従って、プログラムの最初のミュージック・ビデオは、一度だけ再生することができる。ユーザーが全プログラムを実行することを試みる場合、２回目、このビデオは実行しない。

第３のポリシは、望まれた任意の方法で使用されるためにそれに関連した媒体を許す。ポリシはそれ自身これを述べることができる。プレー、複写又は関連する媒体の他の使用上に制限はない。いくつかの実施例では、しかし、媒体の部分はその代りに、明瞭な（暗号化されなかった）ものにあることがある。この一例が下記に述べられる。いずれの場合も、第１と第２の両方の広告は望まれた任意の方法で使用されてもよい。

４番目のポリシは、それに関連した媒体を許すーザーの好きなだけ多くの回実行され、しかしコピーすることができない。従って、第２のミュージック・ビデオは再生することができるが、コピーすることができない。

５番目のポリシは、ユーザーが好きでコピーしたのと同じくらい多くの回だがアナログファイルとしてのみ実行されるためにそれに関連した媒体を許す。従って、３番目のミュージック・ビデオは再生されることがあり、ある方法のみでコピーした。

各々（部分）とライセンスの間の関連性は破線を備えた図８に示される。ツールがこの結合を設立することがある方法は、より非常に詳しく下に述べられる。
デスクリプタ
このツールは、単一のメディア・ファイルの部分にポリシを関連させることができる。図８の絵入りで記述された実施例を継続して、部分の各々はリーフ・ライセンスによってポリシに関係している。この結合がどのように設立されることがあるかよりよく説明するために、単一のメディア・ファイル８００の１つの部分は、より非常に詳しく図解されている。

図９は、メディア・ファイル８００を示しており、４番目の部分８０８は、この部分をポリシに関連付けることができる１つの方法を示すために拡張されている。ここで、メディア・ファイルは、部分で一般に順番に受け取られる。この例では、ルート・ライセンス、最初のリーフ・ライセンス、メディア・ファイルの第１の部分、第２のリーフ・ライセンス、第２の部分、などの順番で受け取られる。ここで、リーフ・ライセンスは必ずしもすべて、上に記述されるようなメディア・ファイルの始めを受け取る前に受け取られる訳ではない。このため、最初と３番目のリーフ・ライセンスは、それらに関連した部分に先立って再び送られる（従って、最初のリーフ・ライセンスは第１の部分の前に送られ、第７の部分の前に再び送られる）。

新しいポリシがメディア・ファイルの一部のために続かれることになっている場合、新しいリーフ・ライセンス（ここに４番目のリーフ・ライセンス８２２）は、４番目のリーフ・ライセンスに関連した媒体の一部に先立って送られる。

ここで、リーフ・ライセンスは４番目の部分８０８のデータ・セグメント９０４−９１４を後に続けて、制御ブロック９０２の一部として送られる。ＲＴＳＰでは、しかし、ライセンスはＳＤＰデスクリプタかＡＮＮＯＵＮＣＥメッセージに伝えられる。リーフ・ライセンス及びデータの使用及びコミュニケーションは更に上記の図７に関係のある説明で述べられるように、ＲＴＳＰを使用することがあるが、特にこの実施例はＨＴＴＰの使用に注目する。制御ブロックは、図８及び９のリーフ・ライセンス８２２を含む。リーフ・ライセンスにはリーフ・コンテンツｋｅｙ４、ｐｏｌｉｃｙ４及びＫＥＤ４がある。いったん受け取られたならば、４番目のリーフ・ライセンスはルート・コンテンツ鍵を使用して復号することができる。ＫＩＤは普通の文で送ることができ、又は暗号化されるが復号されることができる。

データ・セグメントの各々はポリシに関連付けられ、ここで、データ・セグメント９０４−９１４は対応する４番目のポリシに関連付けられる。この関連は４番目のリーフ・ライセンスのＫＩＤで設立される。ＫＩＤ（又はＫＩＤに関連した識別子）は各データ・セグメントに格納される。ＫＩＤは、比較的短い情報であり、メモリの１バイト未満しか取らない整数でありえる。従って、受信機は、適切なポリシを示すＫＩＤに基づいた適切なポリシにデータ・セグメントを関連させることができる。デスクリプタは、既存の又は今後作られることがある様々な制御及びデータプロトコルやパケット構造と共に使用することができる。そのような典型的な１つのデータプロトコルはＲＴＰである。ここで、デスクリプタは各パケットのエンドへ付加され適応する。別の実施例では、ＨＴＴＰ制御プロトコルは使用される。ここで、デスクリプタは各フレームの初めにアペンドされて適応させられる。

図１０は、ＲＴＳＰに従ってリーフ・ライセンスにデータ・セグメントを関連させるデスクリプタを例証する。

この例において、データ・セグメント１０００はＲＴＰペイロード・フォーマット・ヘッダ１００８及びペイロードデータ１０１０を含むことができる。ここで、ペイロードデータ及びペイロード・フォーマット・ヘッダは暗号化される、その一例は、図１１の一部と下に評される。

ここで、データプロトコルによって許されたどんな適切な場所でもそれを置くことができるが、デスクリプタは、ＲＴＰプロトコルを与えるペイロード・データのエンドへアペンドされる。当業者は理解するように、ペイロード・データの端にデスクリプタを置くことは後方互換性問題を緩和することがある。

この実施例（ＲＴＰパケット）では、ＲＴＰヘッダの例外で、デスクリプタ１０１２に関係している。デスクリプタ１０１２は、次には、それでペイロード・データ１０１０及びＲＴＰペイロード・フォーマット・ヘッダ１００８が復号されることを（例えば４番目のリーフ・コンテンツ鍵に関連した初期化ベクトル（ＩＶ））可能にする復号プロセスの中で使用することができる暗号化パラメーターを運ぶ。特にこの例において、単一のポリシとコンテンツの暗号鍵はペイロードデータ１０１０に当てはまる。

１つの実施例によると、デスクリプタ１０１２は以下のようにデータ構造を含む。

この例において、フラグ・セクションはデータ・セグメントの少しのフィールドの示す属性である。次のビットが現在定義される。すなわち、ビット０（暗号化されたデータ）である。このビットが１にセットされる場合、それはデータ・セグメントが暗号化されたフォームであることを示す。そうでなければ、データ・セグメントは明瞭になる。

延期セクションはＫＩＤとＩＶを含み、ＫＩＤはＫＩＤ４である。また、ＩＶはリーフ・コンテンツｋｅｙ４に関係している。

延期セクションに関して、延期フィールドの数は、このデスクリプタに含まれた可変長延期の数を示す。可変長拡大体に関して、延期にはそれぞれ次のフォーマットがある：

１つの実施例に従って、ＫＩＤとＩＶは以下のように定義される。
ＫＩＤ
延長（延期）タイプ： 鍵ＩＤの延期のために１に設定されなければならない。

延長の長さ： １６にセットされ、１２８ビット（１６バイト）に相当する。

延長： このデスクリプタと共に運ばれ、暗号化された媒体用の重要なＩＤ値を含む。暗号化されたデータフラグが１にセットされる場合のみ、この延期が使用される。
初期化ベクトル（ＩＶ）
延長タイプ： 初期化ベクトル延期用に２にセットされる。

延長の長さ： ８にセットされ、６４ビット（８バイト）に相当する。

延長： このデスクリプタと共に運ばれ、暗号化された媒体用の初期化ベクトルを含み、暗号化されたデータフラグが１にセットされる場合のみ、この延期が使用される。長さセクションに関して、この実施例では、このセクションは、バイトにデスクリプタの合計長さを含んでいるに違いない。この長さは、このデスクリプタと共に運ばれた媒体データのサイズを含んでいない。
コンテンツ独立なデータ暗号化
図１１は、１つの実施例に従って方法のステップについて記述するフローダイアグラムである。この方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア又はその組合せとして実行可能である。１つの実施例では、この方法は、上に例証され記述されたもののようなシステムに関して実現することができる。更に、続くディスカッションでは、実行される行為（動作）のうちのいくつかはサーバ／送信機によって実行されることとして描かれる。また、他の行為はクライアント／受信機によって実行されることとして描かれる。サーバ／送信機及びクライアント／受信機の例は、上で提供された。

ステップ１１０２は、メディア・ファイルを受け取る。メディア・ファイルにはメディア・ファイルがデータ・セグメントに分割され、暗号化され、送受信され、復号されることを可能にするどんなコンテンツ・タイプもありえる。それは、例えばＡＳＦ、ＭＰＥＧ２ ＴＳ、ＭＰＥＧ２ ＥＳ又はＷＡＶファイルでありえる。

ステップ１１０４は、メディア・ファイルをデータ・セグメントに分割する。これらのデータ・セグメントはパケット、他の数片のデータ又はＲＴＰ又はＨＴＴＰのような様々な制御プロトコルに一致するフレームを含むことができる。

ステップ１１０６は、各データ・セグメントを暗号化する。ステップ１１０６はここに記述された実施例のうちのどれによってもそうすることがある。従って、それは、リーフ・コンテンツ鍵を備えたペイロードデータを暗号化し、ルート・コンテンツ鍵でそのリーフ・コンテンツ鍵を暗号化することがある。ルート・コンテンツ鍵で、受信機は後でリーフ・コンテンツ鍵を復号し、ペイロードデータを復号するそのリーフ・コンテンツ鍵を使用することがある。

１つの実施例では、ステップ１１０６は、それの反対のモードの中でＡＥＳを使用する個々のデータ・セグメント又は部分を暗号化する。図１２は、このテクニックを使用して、単一データ・セグメントを暗号化する過程を図解する。この実施例では、反対のモードは、データ・セグメントのクリアテキスト・バイトとＸＯＲされるバイトのストリームを作る暗号化されたデータ・セグメントを作成する。重要なストリーム・ジェネレータは、一度に鍵・ストリームの１６バイトのブロックを生成するためにＡＥＳラウンドを使用する。ＡＥＳラウンドへのインプットは、コンテンツ暗号鍵（Ｋｃ）（例えばリーフ・コンテンツ鍵）、データ・セグメントＩＤの１２８ビットの縦続及びデータ・セグメント内のブロック番号である。

鍵ストリーム・ジェネレータのアウトプットはバイトごとにＸＯＲされたデータ・セグメントの対応ブロック（ｉ）からのデータを備えたバイトによる。データ・セグメントが１６バイトずつ平等に割り切れないというその場合では、最後のブロックからの媒体データの有効バイトだけが、ＸＯＲされるべきである重要なストリームを備え、また暗号化されたデータ・セグメントのために保存された。

ステップ１１０８は各暗号化されたデータ・セグメントにデスクリプタを追加する。デスクリプタはＫＩＤ、ＩＶ又はここに述べられた他のエレメントを含むことができる。デスクリプタはそれぞれ、データ・セグメントのペイロードデータが管理されるべき関連するデジタル著作権管理ポリシを示す。このデジタル著作権管理ポリシは、１つの上記の実施例によれば、以前に受信リーフ・ライセンス内に含まれている。デスクリプタはそれぞれ更にデータ・セグメントを復号するのに使用可能なコンテンツ鍵（例えば特別のリーフ・コンテンツ鍵）を示すことができる。

これらのステップの結果は、データ・セグメントへ分解された任意のコンテンツ・タイプのメディア・ファイルであり、それぞれのデータ・セグメントは暗号化されていてデスクリプタを持ち、デスクリプタによって、暗号化されたデータはデジタル著作権管理ポリシに後に関連付けられることに注意すべきである。

１つの実施例では、デスクリプタは長さインジケータを含んでいる。この長さインジケータで、暗号化されたデータ・セグメントの受信機は、デスクリプタがいつ終了するか始まるか決めることができる。この長さインジケータは、データ・セグメント又はそのパケット中の様々な場所で暗号化されたデータ・セグメントにデスクリプタが加えられることを可能にする。ＲＴＰプロトコルについては、例えば、デスクリプタは、データ・セグメントがあるＲＴＰパケットのエンドに加えられる。ＨＴＴＰプロトコルについては、例えば、デスクリプタはデータ・セグメントがあるフレームの始めに加えられる。デスクリプタは、認識可能な長さを有することによって、データ・セグメントの様々な部分に追加することができ、したがって、様々な転送プロトコルを備えたデスクリプタの使用を可能にすることができることに注意すべきである。

ステップ１１１０は、受信機にデスクリプタと共に、暗号化されたデータ・セグメント（またもしあれば明瞭なデータ・セグメント）を送信する。受信機は、当技術中で既知であるようにデータ・セグメントを適応させることを（例えば正しいオーダーで配置することを）可能にされる。受信機は、データ・セグメントに関連したコンテンツ鍵を使用して、データ・セグメントを復号することができる。更に、デスクリプタを使用して、受信機は、メディア・ファイル又はそれの部分と共にどの権利ポリシを使用しなければならないか決める。メディア・ファイルに異なる権利ポリシによって管理されるべき部分がある場合、この方法は更にメディア・ファイルのそれらの部分に基づいたデータ・セグメントを分割し、ステップ１１０４で異なる部分のデータ・セグメントに異なるデスクリプタを割り当てることができる。

ステップ１１１２は、暗号化されたデータ・セグメントを受け取り復号する。受信機（クライアント／受信機５００又は６００のような）はデータ・セグメントを復号し、そのデスクリプタに基づいて、適切な権利ポリシを割り当てる。１つの実施例では、受信機は、デスクリプタの中で初期化ベクトルを使用して、データ・セグメントを復号する。受信機は、ＫＩＤに基づいた適切なリーフ・コンテンツ鍵を決定する。その後、それは、ルート・コンテンツ鍵でリーフ・コンテンツ鍵を復号した後にデータ・セグメントを復号するためにそれを使用する。

ステップ１１１４は、権利ポリシに各データ・セグメントを関連させる。１つの実施例では、受信機は、デスクリプタ及び権利ポリシを持っているリーフ・ライセンスで見出される重要なＩＤ（ＫＩＤ）を用いて、それを行う。
ルート及びリーフ・ライセンスの使用
図１３は、１つの実施例に従って方法のステップについて記述するフローダイアグラムである。この方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア又はその組合せに関して行なうことができる。１つの実施例では、この方法は、上に例証され記述されたもののようなシステムに関して実現することができる。更に、続くディスカッションでは、行なわれる行為のうちのいくつかはサーバ／送信機によって行なわれることとして描かれる。また、他の行為はクライアント／受信機によって行なわれることとして描かれる。サーバ／送信機及びクライアント／受信機の例は上に提供される。

ステップ１３００はクライアント／受信機の公開鍵を使用して、ルート・コンテンツ鍵を暗号化する。どんな適切なコンテンツ鍵でも利用することができる、しかし上に挙げられているのは１つの例である。ステップ１３０２は、クライアント／受信機の暗号化されたルート・コンテンツ鍵を含んでいるルート・ライセンスを送る。どんな適切な方法もこのステップを実行するために利用することができる。続くディスカッションでは、２つの異なるプロトコルで引く２つの具体例が提供される。これらが例を構成し記述される特定のプロトコルだけへの要求された主題の応用範囲を狭めるようには意図されないことを理解すべきである。

ステップ１３０４は、サーバ／送信機によって送られたルート・ライセンスを受け取る。また、ステップ１３０６は暗号化されたルート・コンテンツ鍵を復号する。この例において、このステップは、暗号化されたルート・コンテンツ鍵を復号するためにクライアント／受信機の秘密鍵を使用することにより行なわれる。

ステップ１３０８はリーフ・ライセンスを準備し、ルート・コンテンツ鍵でリーフ・コンテンツ鍵を暗号化する。ステップ１３１０はクライアント／受信機にリーフ・ライセンスを送る。リーフ・ライセンスは典型的にはＤＲＭに保護されたコンテンツ用ポリシを含んでいることを想起すべきである。ステップ１３０８及び１３１０が与えられた１片のＤＲＭに保護されたコンテンツ用の実行された複数回でありえることを理解すべきである。すなわち異なるポリシを持っている各部分については、対応するリーフ・ライセンスは準備することができ、クライアント／受信機に送ることができる。

ステップ１３１２はリーフ・ライセンスを受け取る。また、ステップ１３１４は以前に受け取られたルート・コンテンツ鍵を使用して、リーフ・コンテンツ鍵を復号する。その後、ステップ１３１６は、コンテンツを復号する復号されたリーフ・コンテンツ鍵を使用する。更に、それは、上に記述されたデスクリプタを使用して、メディア・ファイル（メディア・ファイルに一部がある場合）の一部に適切なリーフ・ライセンスを関連させる。

クライアント／受信機によって受け取られる個々の新しいリーフ・ライセンスのためにステップ１３１２、１３１４及び１３１６を行なえることを理解すべきである。
結論
このドキュメントは、デジタル著作権管理ポリシが任意のコンテンツ・タイプか制御権移動プロトコルがあるデジタル媒体に関係していることがあるテクニックについて記述している。ある場合には、暗号化されたメディア・ファイルの受信機がこれによってファイルを復号し、異なるデジタル著作権管理ポリシによるファイルの部分を使用することができる。ある場合には、これが、更に送信機がテクニックの１つのセットを備えた様々なタイプのメディア・ファイルを暗号化することを可能にする。本発明は、構造的特徴及び／又は方法論のステップに特有の言語に述べられているが、冒頭の特許請求の範囲において定義された発明は、特定の特徴に必ずしも制限されない。より正確に言えば、特定の特徴及びステップは、特許請求の範囲に記載された発明を実行する好ましい形態で開示されている。

本発明の実施例をある１つの実施例で用いることができるプロトコルの例示的な登録手順を図解している。 本発明の実施例をある１つの実施例で用いることができるプロトコルの例示的な近接性検出手順を図解している。 本発明の実施例をある１つの実施例で用いることができるプロトコルの例示的なセッション確立手順を図解している。 本発明の実施例をある１つの実施例で用いることができるプロトコルの例示的なデータ転送手順を図解している。 本発明の実施例をある１つの実施例で用いることができるストリーミング・プロトコルの側面を図解している。 ある１つの実施例によりルーツ・ライセンス及びリーフ・ライセンスと関連付けされた側面を図解している。 ある１つの実施例によりルーツ・ライセンス及びリーフ・ライセンスと関連付けされた側面を図解している。 ５つの異なる例示的なデジタル権利管理ポリシと関連付けられた７つの部分を有する例示的な単一のメディア・ファイルを図解している。 鍵ＩＤ（ＫＩＤ）と関連付けられた例示的なデータ・セグメントと有する図８の単一のメディア・ファイルを図解している。 ある１つの実施例によるパケットを、図９に示されたデータ・セグメントに対して図解している。 本発明によるツールがコンテンツ独立な暗号化及び復号化を可能にする１つの態様を示す流れ図である。 ある１つの実施例によるサンプルの暗号化を図解している。 ある１つの実施例によるルーツ及びリーフ・ライセンスの通信を示す流れ図である。

Claims (13)

1. 公開鍵と秘密鍵との対を有するクライアント／受信機コンピュータと、公開鍵と秘密鍵との対を有するサーバ／送信機コンピュータとを備えるシステムにおいて前記サーバ／送信機コンピュータにより実施される方法であって、
   前記クライアント／受信機コンピュータの公開鍵を用いて暗号化されたルート・コンテンツ鍵を生成するステップであって、前記ルート・コンテンツ鍵は、前記クライアント／受信機コンピュータの秘密鍵によって復号され、且つ、前記クライアント／受信機コンピュータがリーフ・コンテンツ鍵を復号するのに使用されるステップと、
   前記ルート・コンテンツ鍵を前記クライアント／受信機コンピュータへ送るステップと、
   単一のメディア・ファイルを、複数のデータ・セグメントに分割するステップと、
   それぞれの前記データ・セグメントを、それぞれの前記リーフ・コンテンツ鍵で暗号化して、暗号化されたデータ・セグメントを生成するステップと、
   それぞれの前記暗号化されたデータ・セグメントにデスクリプタを追加するステップと、
   前記暗号化されたデータ・セグメントと前記デスクリプタとを前記クライアント／受信機コンピュータへ送信するステップと、
   を実行し、
   それぞれの前記デスクリプタは、当該データ・セグメントを暗号化した前記リーフ・コンテンツ鍵と、当該データ・セグメントに関連するデジタル権利管理ポリシとを示すよう機能する
   ことを特徴とする方法。
2. 請求項１記載の方法において、前記データ・セグメントを暗号化する前記ステップはＡＥＳをカウンタ・モードで用いることを特徴とする方法。
3. 請求項１記載の方法において、それぞれの前記デスクリプタは初期化ベクトルを含み、
   それぞれの前記初期化ベクトルは、前記デジタル権利管理ポリシを示す鍵ＩＤと関連付けられていることを特徴とする方法。
4. 請求項１記載の方法において、それぞれの前記デスクリプタは、前記関連付けられたデジタル権利管理ポリシに含まれる鍵ＩＤを有することを特徴とする方法。
5. 請求項１記載の方法において、それぞれの前記デスクリプタは、前記暗号化されたデータ・セグメントとそれぞれの前記デスクリプタとの間の区別を可能にする長さインジケータを含むことを特徴とする方法。
6. 請求項１記載の方法において、前記暗号化されたデータ・セグメントは、ＲＴＰデータ・プロトコルに従うパケットとＨＴＴＰプロトコルに従うフレームとのうちの少なくとも一方を含むことを特徴とする方法。
7. 請求項６記載の方法において、デスクリプタを追加する前記ステップは、前記暗号化されたデータ・セグメントがＲＴＰプロトコルに従うパケットを含む場合には前記暗号化されたデータ・セグメントの最後にそれぞれの前記デスクリプタを結合し、前記暗号化されたデータ・セグメントがＨＴＴＰに従うフレームを含む場合には前記暗号化されたデータ・セグメントの最初にそれぞれの前記デスクリプタを結合することを特徴とする方法。
8. 請求項１〜７のうちのいずれか１つに記載の方法をコンピュータに実行させるためのコンピュータ実行可能命令を記憶したコンピュータ可読記憶媒体。
9. 複数の部分を有するメディア・ファイルをサーバ／送信機コンピュータからクライアント／受信機コンピュータへ送るための、コンピュータ実装される方法であって、
   前記サーバ／送信機コンピュータが、
   前記クライアント／受信機コンピュータの公開鍵を用いてルート・コンテンツ鍵を暗号化するステップであって、前記ルート・コンテンツ鍵は前記クライアント／受信機コンピュータの秘密鍵によって復号されるステップと、
   暗号化された前記ルート・コンテンツ鍵を前記クライアント／受信機コンピュータへ送るステップと、
   前記メディア・ファイルを、複数の部分へ分割するステップと、
   複数のリーフ・コンテンツ鍵を生成するステップであって、それぞれの前記リーフ・コンテンツ鍵を、前記メディア・ファイルのうちの関連する部分に対して且つ前記ルート・コンテンツ鍵で暗号化して生成するステップと、
   前記メディア・ファイルのそれぞれの前記部分に対し、前記リーフ・コンテンツ鍵と、前記部分に関連する権利ポリシとを示すためのデスクリプタを生成するステップと、
   前記メディア・ファイルのそれぞれの前記部分を、それに関連する前記リーフ・コンテンツ鍵で暗号化するステップと、
   暗号化された前記部分と前記デスクリプタとを前記クライアント／受信機コンピュータへ送るステップと、
   を実行して、前記クライアント／受信機コンピュータが、それぞれの前記リーフ・コンテンツ鍵を前記ルート・コンテンツ鍵により復号するとともに、それぞれの前記部分を、当該部分に関連する前記デスクリプタにおいて特定された前記リーフ・コンテンツ鍵により復号することができるようにする方法。
10. 請求項９記載の方法であって、前記権利ポリシを前記クライアント／受信機コンピュータへ送るステップを更に含むことを特徴とする方法。
11. 請求項９記載の方法であって、それぞれの前記部分を復号する前記ステップが、それぞれの前記部分に対する前記デスクリプタに鍵ＩＤを含ませるステップを備え、前記クライアント／受信機コンピュータは前記鍵ＩＤを用いて前記部分を前記権利ポリシに関連付けることを特徴とする方法。
12. 請求項９記載の方法であって、任意のコンテンツ・タイプのメディア・ファイルを受け取って、該メディア・ファイルを暗号化し、前記暗号化されたメディア・ファイルを提供するステップを更に含むことを特徴とする方法。
13. 請求項９〜１２のうちのいずれか１つに記載の方法をコンピュータに実行させるためのコンピュータ実行可能命令を記憶したコンピュータ可読記憶媒体。

Images