保護コンテンツのポリシー更新の配信
各種実施形態は、保護される所与のコンテンツについて、ＤＲＭポリシーの更新等のポリシーの更新を配信し、更新することを可能にする。少なくとも一部の実施形態では、各種プロトコルを拡張して、当該プロトコルによってポリシーの更新が表され、伝送されることを可能にすることができる。一実施形態では、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ ＰｒｏｔｏｃｏｌすなわちＨＴＴＰを利用してポリシーの更新を伝える。別の実施形態では、Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ ＰｒｏｔｏｃｏｌすなわちＲＴＳＰを使用してポリシーの更新を伝える。
【発明の詳細な説明】
【背景技術】
【０００１】
デジタル著作権管理（ＤＲＭ）とは、電子機器におけるデジタルメディアコンテンツの使用を規制または制約すること等によってコンテンツを保護するために使用される技術を指す。ＤＲＭの特徴の１つは、所与のマシンまたは機器にメディアコンテンツを結び付けられることである。そのため、通例は、特定のコンテンツに関連し、そのコンテンツに関連付けられた権利と制約を定義するライセンスが所与のマシンまたは機器に結び付けられる。その結果、ユーザは、通例、コンテンツ再生のためにそのコンテンツを取り出し、別のマシンに移すことはできない。
【発明の開示】
【発明が解決しようとする課題】
【０００２】
ＤＲＭで保護される一部のコンテンツの別の特徴は、ＡＳＦファイル等の一部のコンテンツタイプでは、当該ファイル全体には１組の権利と制約、すなわち「ポリシー」のみの適用が許可されることである。例えば、映像ファイルを描画する場合、そのファイル全体についてアナログビデオ出力でＭａｃｒｏｖｉｓｉｏｎを有効にする必要がある場合も、その必要が全くない場合もある。こうした特定タイプのファイルでは、コンテンツに関連付けられたポリシーを、ファイルの途中またはストリームの途中で変更することはできない。
【課題を解決するための手段】
【０００３】
各種実施形態は、保護される所与のコンテンツについて、ＤＲＭポリシーの更新等のポリシーの更新を配信し、更新することを可能にする。少なくとも一部の実施形態では、各種プロトコルを拡張して、当該プロトコルによってポリシーの更新が表され、伝送されることを可能にすることができる。一実施形態では、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ ＰｒｏｔｏｃｏｌすなわちＨＴＴＰを利用してポリシーの更新を伝える。別の実施形態では、Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ ＰｒｏｔｏｃｏｌすなわちＲＴＳＰを使用してポリシーの更新を伝える。
【発明を実施するための最良の形態】
【０００４】
概要
各種実施形態は、保護される所与のコンテンツについて、ＤＲＭポリシーの更新等のポリシーの更新を配信し、更新することを可能にする。少なくともいくつかの実施形態では、各種プロトコルを拡張して、そのプロトコルによってポリシーの更新が表され、伝送されることを可能にすることができる。一実施形態では、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ ＰｒｏｔｏｃｏｌすなわちＨＴＴＰを利用してポリシーの更新を伝える。別の実施形態では、Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ ＰｒｏｔｏｃｏｌすなわちＲＴＳＰを使用してポリシーの更新を伝える。
【０００５】
以下の説明では、「コンテンツセキュリティおよびライセンス転送プロトコル」と題する項が提供され、本発明の技術が用いられることが可能な特定の１つのシステムを説明する。その後、「ＲＴＳＰ」と題する項が提供され、ＲＴＳＰ空間における本発明の技術を理解するための少なくともいくらかの背景知識をＲＴＳＰに詳しくない読者に提供する。
【０００６】
その項の後、「更新されたポリシーを配信するためのライセンスのチェーン化」と題する項が提供され、チェーニングライセンスの概念と、本発明のコンテクストでどのようにチェーン化されたライセンスを利用できるかを説明する。その項の次に「ＨＴＴＰを使用した更新ポリシーの配信」と題する項が提供され、ポリシーの更新を配信するためにＨＴＴＰのコンテクストでどのようにチェーン化されたライセンスを使用できるかを説明する。その項の後に「ＲＴＳＰを使用したルートライセンスおよびリーフライセンスの伝送」と題する項が提供され、ポリシーの更新を配信するためにＲＴＳＰのコンテクストでどのようにチェーン化されたライセンスを使用できるかを説明する。
コンテンツセキュリティおよびライセンス転送プロトコル
以下に、デジタルリンクを流れるコンテンツのためにセキュリティを提供し、ライセンスを転送する例示的プロトコルの説明を提供する。このプロトコルは、本発明の各種技術をともに用いることができる例示的プロトコルの単なる一例である。請求される主題の主旨および範囲から逸脱することなく、他のプロトコルを利用できることを認識および理解されたい。
【０００７】
この説明では以下の暗号表記を使用する。
Ｋ｛データ｝ 秘密鍵Ｋでデータが暗号化される。
Ｋ［データ］ 秘密鍵Ｋでデータが署名される。
｛データ｝Ｄｅｖｉｃｅ 機器の公開鍵でデータが暗号化される。
［データ］Ｄｅｖｉｃｅ 機器の秘密鍵でデータが署名される。
【０００８】
この特定のプロトコルでは、登録、再検証、近接性（Proximity）の検出、セッションの確立、およびデータ転送、の５つの主要な手順がある。
【０００９】
登録の手順では、送信者（すなわち別の機器に送信すべきコンテンツを持つ機器）が、対象とされる受信者（すなわちコンテンツが送信される先の機器）を一意にかつセキュアに識別することができる。この特定のプロトコルでは、送信者は、登録された受信者を記憶したデータベースを保持し、あらかじめ決められた少数の受信者を超える受信者が同時に使用されないことを保証する。登録プロセス中に、送信者は、保護コンテンツが広く配布されることを防止するために、近接性検出の手順を用いて、受信者がネットワーク中で送信者の「近く」に位置することも保証する。
【００１０】
再検証の手順を利用して、受信者が送信者の「近く」に位置し続けることを保証する。コンテンツは、過去の所定期間内に登録または再検証されていない限り受信者には配信されない。
【００１１】
セッション確立手順は、受信者が送信者にコンテンツを要求した時に必ず使用される。送信者は、セッションの確立を完了するには、機器が登録され、最近検証されていなければならないことを順守させる。
【００１２】
セッションが確立されると、要求されるコンテンツのデータ転送をセキュアな方式で行うことができる。受信者は、そのセッションを再使用して、コンテンツの特定部分を取り出す（シーク）ことはできるが、別のコンテンツを取り出すには新しいセッションを確立しなければならない。
【００１３】
ここで、図１と、登録の際に送信者と受信者間でやり取りされる各種メッセージを示す下の表との関連で登録の手順を考える。
【００１４】
【表１】
【００１５】
ここで、受信者は、種々の情報の中でも特に受信者のデジタル証明書を含んだ登録要求メッセージを送信する。登録要求メッセージを受信するのに応答して、送信者は、受信者の証明書を検証し、シードおよび無作為のセッションＩＤを生成し、それらを上記に示す形態で登録応答メッセージとして受信者に返す。次いで、受信者は、送信者の署名を検証し、セッションＩＤを入手し、図に示す他の動作を行う。次いで、受信者と送信者は、下記の近接性検出プロセスを経ることができる。
【００１６】
再検証に関しては、上記で概説した手順と同じ手順が行われ、違いは、再検証の際には受信者がすでにデータベースに登録されていることである。
【００１７】
近接性の検出に関して、図２との関連で以下を考える。
【００１８】
近接性検出の手順では、受信者が、近接性検出初期化メッセージに示されるセッションＩＤを含んだメッセージを送信者に送信する。そして、送信者は、ノンス（１２８ビットの無作為値）を含んだメッセージを受信者に送信し、受信者がコンテンツ暗号鍵を使用して暗号化したノンスで応答するのに要する時間を測定する。最後に、送信者は、近接性の検出が成功したか否かを知らせるメッセージを受信者に送信する。
【００１９】
受信者は、近接性の検出が成功した旨の確認を得るまでこのプロセスを繰り返すことができる。ＩＰベースのネットワークでこの特定のプロトコルが使用される場合、近接性検出メッセージは、ＵＤＰを通じて交換される。受信者は、登録応答メッセージを介して送信者のアドレスを知る。受信者のアドレスは、近接性検出開始メッセージを伝送するＵＤＰパケットの受信ＩＰヘッダを調べることによって判定できるので、別個に通信される必要はない。
【００２０】
次の表は、近接性検出の際に交換されるメッセージを示す。
【００２１】
【表２】
【００２２】
セッションの確立に関して、図３と、セッション確立の際に交換されるメッセージを示す次の表との関連で以下を考える。
【００２３】
【表３】
【００２４】
この例では、受信者から送信者にライセンス要求メッセージが送信され、上記の情報を含んでいる。それに応答して、送信者は、上記の情報を含むライセンス応答メッセージを送信することができる。
【００２５】
この特定の例では、ライセンスは、ＸＭＲフォーマットで表され、コンテンツ暗号鍵、コンテンツインテグリティ鍵、送信者のＣＲＬのバージョン、１２８ビットの権利ＩＤ、および１２８ビットの通し番号を含む。ライセンスは、ＯＭＡＣを使用してコンテンツインテグリティ鍵を使用して計算されたＯＭＡＣも含んでいる。
【００２６】
データ転送手順に関して、図４との関連で以下を考える。セッションの確立が完了すると、制御プロトコルに固有の方式でデータ転送が実行される。データ転送の要求と応答は両方とも、制御プロトコルとコンテンツの種類に合わせて特別に定義されなければならない。これを図４に概念的に表す。
【００２７】
本発明の実施形態がともに用いられることが可能な例示的プロトコルの簡単な概要を提供したので、次いでＲＴＳＰの背景情報をいくらか検討する。
【００２８】
ＲＴＳＰ
Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ ＰｒｏｔｏｃｏｌすなわちＲＴＳＰは、当業者には理解されるように、リアルタイムのプロパティを持つデータの配信（すなわちストリーミング）を制御するためのアプリケーションレベルのプロトコルである。ＲＴＳＰは、音声や映像などのリアルタイムデータの制御されたオンデマンドの配信を可能にする、拡張可能な枠組みを提供する。データソースは、生のデータ供給と記憶されたクリップの両方を含むことができる。このプロトコルは、複数のデータ配信セッションを制御し、ＵＤＰ、マルチキャストＵＤＰ、ＴＣＰ等の配信チャネルを選択する手段を提供し、ＲＴＰに基づく配信機構を選択する手段を提供することを目的とする。
【００２９】
ＲＴＳＰは、音声や映像等の連続したメディアの単一のストリーム、または時間同期された数個のストリームを確立し、制御する。連続したメディアストリームを制御ストリームと交互にすることは可能であるが、ＲＴＳＰは、通例は、連続したストリーム自体は配信しない。すなわち、ＲＴＳＰは、マルチメディアサーバの「ネットワーク遠隔制御装置」の役割を果たす。
【００３０】
制御されるストリームのセットは、プレゼンテーション記述によって定義される。ＲＴＳＰでは、ＲＴＳＰ接続という概念はなく、代わりに、サーバが、識別子で区別されるセッションを維持する。ＲＴＳＰセッションは、決してＴＣＰ接続などのトランスポートレベルの接続に結び付けられることはない。ＲＴＳＰセッションの間は、ＲＴＳＰクライアントが、サーバへの高信頼のトランスポート接続を多数オープンおよびクローズしてＲＴＳＰ要求を発行することができる。あるいは、当業者には理解されるように、ＵＤＰなどのコネクションレスのトランスポートプロトコルを用いてもよい。
【００３１】
ＲＴＳＰで制御されるストリームは、ＲＴＰを使用することができるが、ＲＴＳＰの動作は、連続メディアを伝送するために使用されるトランスポート機構に依存しない。
【００３２】
次いで、図５との関連で、クライアント／受信者５００とサーバ／送信者５０２間の典型的なＲＴＳＰ要求／応答のやり取りを考える。
【００３３】
予備知識として、ＲＴＳＰ要求／応答はヘッダを持つが、説明の簡単のためにこのヘッダについては説明しない。ＲＴＳＰでは、クライアント／受信者５００は通例、要求ＵＲＬで識別されるプレゼンテーションまたはメディアオブジェクトの記述をサーバ５０２から取り出すことを目的とする、ＤＥＳＣＲＩＢＥ要求と称されるものを発行する。サーバ５０２は、セッション記述プロトコル（ＳＤＰ）で表された、要求されるリソースの記述で応答する。ＤＥＳＣＲＩＢＥ応答（ＳＤＰ）は、当該応答が記述するリソースについてのメディア初期化情報をすべて含んでいる。
【００３４】
次いで、クライアント５００は、ストリーミングされるメディアに使用されるトランスポート機構を指定するＵＲＩのＳＥＴＵＰ要求を送信する。図５の例では、ＳＥＴＵＰ要求は、音声と映像の両方について送信される。クライアント５００は、ＳＥＴＵＰ要求で、利用しようとするトランスポートパラメータも知らせる。ＳＥＴＵＰ要求のトランスポートヘッダで、データ送信のためにクライアントが許容可能なトランスポートパラメータを指定する。サーバ５０２からのＲＥＳＰＯＮＳＥは、サーバで選択されたトランスポートパラメータを含んでいる。サーバは、ＳＥＴＵＰ要求に応答してセッション識別子も生成する。
【００３５】
この時点で、クライアントは、ＳＥＴＵＰで指定された機構を介してデータ送信を開始するようにサーバに指示するＰＬＡＹ要求を発行することができる。ＰＬＡＹ要求の受信に応答して、サーバは、この例では音声／映像コンテンツであるコンテンツのストリーミングを開始することができる。この例では、当業者には理解されるように、ストリーミングコンテンツは、ＲＴＰパケットを使用してカプセル化され、ＵＤＰを通じて送信される。
【００３６】
ＲＴＳＰプロトコルは、他にも関心の対象となるメソッドを備え、それらには、ＰＡＵＳＥ、ＴＥＡＲＤＯＷＮ、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＲＥＤＩＲＥＣＴ、およびＲＥＣＯＲＤが含まれる。ＲＴＳＰについての追加的な背景知識については、読者は、http://www.ietf.org/rfc/rfc2326.txtで入手可能なRTSP RFC, Schulzrinne, H., Rao, A.および R. Lanphier, 「Real Time Streaming Protocol (RTSP)」, RFC 2326（1998年4月）を参照されたい。
【００３７】
更新されたポリシーを配信するためのライセンスのチェーン化
ここで例示し、説明する実施形態では、ライセンスのチェーン化の概念がポリシー更新プロセスで利用される。この特定の実施形態では、ルートライセンスおよびリーフ（leaf）ライセンスの概念が用いられる。ここで、ルートライセンスは、クライアント／受信者が後に配信されるポリシー更新をそのコンテンツ鍵を使用して解読できるように、クライアント／受信者にコンテンツ鍵を設定し、セキュアに配信するために利用される。最初のコンテンツ鍵がクライアント／受信者にセキュアに配信されると、最初に配信されたそのコンテンツ鍵を使用してサーバ／送信者によって後続のコンテンツ鍵が暗号化され、クライアント／受信者に送信されることができる。クライアントは、最初に配信されたコンテンツ鍵を使用して、関連付けられたポリシー更新を解読することができる。
【００３８】
この特定の方式を実施できる方法の単なる一例を提供するために、図６との関連で以下を考察されたい。この特定の例では、図６のシステムは、公開鍵による暗号動作のための１０２４ビットのＲＳＡ鍵と、対称暗号動作のための１２８ビットのＡＥＳ鍵を使用するように構成される。無論これは単なる一例として提供され、請求される主題の用途を限定するものではない。
【００３９】
この例では、クライアント／受信者６００は、公開鍵／秘密鍵の対６５０を持ち、サーバ／送信者６０２は、クライアント／受信者の公開鍵を持っている。この例では、クライアント／受信者の公開鍵と秘密鍵はそれぞれ、１０２４ビットのＲＳＡ鍵である。サーバ／送信者は、クライアント／受信者の公開鍵を使用して、クライアント／受信者の公開鍵で暗号化された初期コンテンツ鍵を含むルートライセンスを構築する。初期コンテンツ鍵は、１２８ビットのＡＥＳコンテンツ鍵である。このルートライセンスは、次いでクライアント／受信者に送信される。図６で、これは、クライアント／受信者とサーバ／送信者間で行われる最初の通信として示しており、暗号化されたコンテンツ鍵は、｛コンテンツ鍵１｝ＣＬＩＥＮＴと表す。ただし、図の通信より前に他の通信が行われてよいことは理解されたい。
【００４０】
サーバ／送信者から暗号化されたコンテンツ鍵を受信すると、クライアント／受信者は、自身の秘密鍵を使用してコンテンツ鍵を解読することができ、解読したコンテンツ鍵を将来の使用のためにセキュアに格納することができる。以下の説明では、この最初のコンテンツ鍵を初期コンテンツ鍵と呼ぶ。
【００４１】
ここで、ここまでに何が行われたかを考える。サーバ／送信者は、クライアント／受信者にセキュアに鍵を通信しており、この鍵は、後に行われる暗号動作の基盤の役割を果たすことができる。より具体的に、ここで、ストリーミング中に、ＤＲＭで保護された特定のコンテンツに関連するポリシーの更新が行われることを考える。この場合、サーバ／送信者は、更新後のポリシーを含むリーフライセンスを作成することができる。このリーフライセンスは、ポリシーの更新と、暗号化されたバージョンのコンテンツ鍵２を含む。この例では、コンテンツ鍵２は、初期コンテンツ鍵を使用して暗号化された１２８ビットのＡＥＳコンテンツ鍵である。そのため、新しい追加的なコンテンツ鍵を解読することに伴ってクライアント／受信者が受け、負担する計算上の複雑性と費用は、１０２４ビットのＲＳＡ鍵による動作に伴うものに比べて低減される。これは、クライアント／受信者は、この時点で、１２８ビットのＡＥＳコンテンツ鍵（すなわち初期コンテンツ鍵）を使用して解読するだけでよいからである。
【００４２】
ＸＭＲを利用してライセンスとライセンス更新を表す実装例については、次を考察されたい。
【００４３】
ライセンスのチェーン化を使用する目的の１つは、ライセンス更新の際に行われる非対称鍵操作（asymmetric key operations）の回数を減らすことである。この実装例では、権利と制約を伝達するための機構としてルートライセンスを利用することは重視されない。その結果、ルートライセンスは、非常に単純であり、権利や制約を伝えない。ただし、ルートライセンスは、少なくとも一部の実装では、権利と制約を伝送してよいことは理解されたい。
【００４４】
この例では、リーフライセンスは、アップリンクＫＩＤオブジェクトを介してルートライセンスに結び付けられる。以下の項では、一実施形態による、これらのライセンス中に存在するオブジェクトに着目する。
【００４５】
ルートライセンスに関して、以下に、再生のためのルートライセンスに存在するＸＭＲオブジェクトのセットを記載する。
【００４６】
【表４】
【００４７】
再生ポリシーコンテナオブジェクトは、再生を行わせるために存在しなければならない。それに対し、コピー動作のためのルートライセンスは、再生ポリシーコンテナの代わりにコピー権利コンテナオブジェクトを含まなければならない。
【００４８】
次に示すのは、コピーのためのルートライセンスに存在するＸＭＲオブジェクトのセットである。
【００４９】
【表５】
【００５０】
この実施形態では、コピーが許可されることを示すためにコピー権利コンテナオブジェクトが存在しなければならない。再生の権利は常に付与されなければならないため、再生ポリシーコンテナオブジェクトがなお存在することに留意されたい。
【００５１】
この特定の実施形態におけるリーフライセンスに関して、以下を考える。リーフライセンスは、ＸＭＲを介して表すことができる任意の種の権利または制約を含むことができる。リーフライセンスとチェーンおよび非チェーン化ライセンスとの主要な相違は、対称鍵を使用して、コンテンツ鍵と、アップリンクＫＩＤオブジェクトを介した別のライセンスまでのリンクとを暗号化することである。
【００５２】
次に示すのは、再生用のリーフライセンスの一例である。
【００５３】
【表６】
【００５４】
Ｃｏｎｔｅｎｔ Ｋｅｙオブジェクトは、鍵暗号化暗号タイプを０ｘ０００２（チェーン化ライセンス）に設定し、対称暗号タイプを０ｘ０００１（ＡＥＳ ＣＴＲ）に設定しなければならない。アップリンクＫＩＤオブジェクトは、アップリンクＫＩＤフィールドを、ルートライセンスのＫＩＤに設定しなければならない。
【００５５】
次に示すのは、この特定の実施形態における、コピーのためのリーフライセンスの例である。
【００５６】
【表７】
【００５７】
この実施形態では、コピー権利コンテナオブジェクトは、コピーが許可されることを示すために存在しなければならない。コピー回数制約オブジェクトは、許可されるコピー回数に制限がある場合に存在する。コピー保護レベル制約オブジェクトは、コピー先として使用されるシステムに制約がある場合に存在する。再生の権利は常に付与されなければならないので、再生ポリシーコンテナオブジェクトがやはり存在することに注意されたい。
【００５８】
図７は、一実施形態による方法におけるステップを説明する流れ図である。この方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せとの関連で行われることができる。一実施形態では、この方法は、上記で例示し、説明したシステムのようなシステムとの関連で実装されることができる。また、以下の説明では、行われる動作の一部はサーバ／送信者によって行われるものと記述し、他の動作は、クライアント／受信者によって行われるものと記述される。サーバ／送信者およびクライアント／受信者の例は、上記で提供した。
【００５９】
ステップ７００で、クライアント／受信者の公開鍵を使用して初期コンテンツ鍵を暗号化する。任意の適当なコンテンツ鍵を利用することができ、その単なる一例を上記で挙げた。ステップ７０２で、暗号化された初期コンテンツ鍵を含むルートライセンスをクライアント／受信者に送信する。任意の適切な方法を利用してこのステップを実装することができる。以下の説明では、２つの異なるプロトコルを用いた２つの具体例が提供される。それらは例であり、請求される主題の用途を、ここに記載される具体的なプロトコルのみに限定する意図ではないことを認識および理解されたい。
【００６０】
ステップ７０４で、サーバ／送信者から送信されたルートライセンスを受信し、ステップ７０６で、暗号化された初期コンテンツ鍵を解読する。この例では、このステップは、クライアント／受信者の秘密鍵を使用して、暗号化された初期コンテンツ鍵を解読することによって行われる。
【００６１】
ステップ７０８で、リーフライセンスを作成し、初期コンテンツ鍵で新しいコンテンツ鍵を暗号化する。ステップ７１０で、リーフライセンスをクライアント／受信者に送信する。リーフライセンスは、ＤＲＭで保護されたコンテンツのためのポリシーとポリシー更新を含むことができ、通例は実際に含んでいることを思い出されたい。ステップ７０８および７１０は、ＤＲＭで保護された所与のコンテンツについて複数回実行できることを理解および認識されたい。すなわち、ＤＲＭで保護された特定のコンテンツに関してポリシーが変化すると、それに対応するリーフライセンスが作成され、クライアント／受信者に送信されることができる。
【００６２】
ステップ７１２でリーフライセンスを受信し、ステップ７１４で、先に受信された初期コンテンツ鍵を使用して新しいコンテンツ鍵を解読する。次いでステップ７１６で、解読された新しいコンテンツ鍵を使用してコンテンツを解読し、リーフライセンスに入っているポリシーを更新する。
【００６３】
ステップ７１２、７１４、７１６は、クライアント／受信者に受信される新しいリーフライセンスごとに行うことができることを認識および理解されたい。
【００６４】
ＨＴＴＰを使用した更新ポリシーの配信
ルートライセンスおよびリーフライセンスの概念と、各ライセンスが上記のコンテクストでどのように使用されることができるかを説明したので、次いで、ＨＴＴＰを使用してルートライセンスとリーフライセンスがどのように配信されるかを考える。
【００６５】
ＤＲＭで保護されたコンテンツの伝送にＨＴＴＰが利用される場合、クライアントは、サーバ／送信者に２つの要求を発行する。第１に、クライアントは、ルートライセンスを取得するためのＰＯＳＴ要求を発行する。第２に、クライアントは、ＤＲＭで保護されるコンテンツを取得するためのＧＥＴ要求を発行する。通例、ＨＴＴＰでは、サーバはクライアントとの通信を開始することができないので、この例では、クライアントはこれらの要求を発行する。
【００６６】
具体的には、以下の説明との関連で図８を考察されたい。クライアントがルートライセンスを受信したい時、クライアントは、サーバにＰＯＳＴ要求を発行する。ＰＯＳＴ要求は、上述のようにライセンス要求メッセージを含んでいる。この通信を受信するのに応答して、サーバは、ルートライセンスを含んだライセンス応答メッセージで応答し、ルートライセンスは、少なくとも１つの実施形態ではＸＭＲで表される。ルートライセンスを受信し、適宜処理すると、クライアントは、サーバにＧＥＴ要求を発行してＤＲＭ保護コンテンツを要求する。ＧＥＴ要求に応答して、サーバは、１つまたは複数のライセンス応答メッセージと交互に配置された、要求されるコンテンツのセグメントで応答する。各ライセンス応答メッセージは、ＤＲＭで保護されるコンテンツの特定部分に関連するリーフライセンスを含んでいる。このサーバの応答を構築するために任意の適切な機構または交互配置技術（interleaving technique）を使用することができる。
【００６７】
ある特定のコンテクストにおける単なる一実装例として、以下を考える。
【００６８】
単なる一例で、４バイトのフレームヘッダを使用してデータブロックおよび制御ブロックをカプセル化する。フレームヘッダは、ネットワークバイト順で表された、１バイトのＡＳＣＩＩドル記号（０ｘ２４）、次いで１バイトのブロックタイプ識別子、次いで２バイトのカプセル化データ長を含む。
【００６９】
【表８】
【００７０】
制御ブロックは、タイプ識別子としてＡＳＣＩＩの「ｃ」の文字（０ｘ６３）を使用する。このブロックは、メッセージ、通例はライセンス応答メッセージを含む。
【００７１】
データブロックは、ＡＳＣＩＩの「ｄ」の文字（０ｘ６３）をタイプ識別子として使用する。このブロックは、データセグメント記述子を含み、そのすぐ後にメディアデータが続く。
【００７２】
データセグメント記述子は、暗号化されたコンテンツまたは平文のコンテンツと関連付けられることができる。この記述子内の暗号化されたフラグがこの情報を伝達する。データセグメント記述子は、送信されるファイルの一部に関連付けられ、ファイルが暗号化されている場合は、ファイルに単一のポリシーとコンテンツ暗号鍵が適用される。すなわち、コンテンツ暗号鍵とポリシーは、セグメント内では変更されることができない。
【００７３】
一実施形態によれば、リンクの暗号化を伴う典型的なＨＴＴＰ応答は、次のブロックから構成される。
【００７４】
１．チェーン化されたライセンスを含むライセンス応答メッセージを伝送する制御ブロック［＄ｃ］
２．１つまたは複数のデータブロック［＄ｄ］
【００７５】
ファイルの送信中に鍵またはポリシーの変更がある場合には、以下のステップが追加される。
【００７６】
３．新しいチェーン化ライセンスを含むライセンス応答メッセージを伝送する新しい制御ブロック［＄ｃ］
４．１つまたは複数のデータブロック［＄ｄ］
【００７７】
ステップ３および４は、複数の鍵またはポリシーの変更がある場合には複数回行われてよいことに留意されたい。
【００７８】
ＲＴＳＰを使用したルートライセンスおよびリーフライセンスの伝送
ルートライセンスおよびリーフライセンスの概念と、各ライセンスがＨＴＴＰを使用してどのように配信される方法を説明したので、次いで、ＲＴＳＰを使用してルートライセンスおよびリーフライセンスがどのように配信されることができるかを考える。
【００７９】
ＲＴＳＰとＨＴＴＰの違いの１つは、ＲＴＳＰは、ＨＴＴＰに比べてかなり高機能であることである。具体的には、ＲＴＳＰは、サーバによって開始される要求についての規定を備え、それにより、サーバは、いつでもクライアントにコマンドを送信することができる。この実施形態により、図９との関連で以下を考えられたい。
【００８０】
クライアント／受信者がＤＲＭで保護されるコンテンツを再生したい場合、クライアントは、ライセンス要求メッセージを含むＤＥＳＣＲＩＢＥ要求を送信する。このメッセージの受信に応答して、サーバは、ライセンス応答メッセージを埋め込むセッション記述プロトコル（ＳＤＰ）で応答する。このライセンス応答メッセージは、この特定の実施形態ではＸＭＲで表される、ルートライセンスを含む。
【００８１】
次いで、クライアントがＤＲＭで保護されるコンテンツを受信したい時、クライアントは、ＰＬＡＹ要求をサーバに送信してストリームを開始する。任意の適切な時に、サーバは、クライアントにＡＮＮＯＵＮＣＥ要求を送信してリーフライセンスを含んだライセンス応答メッセージを伝送することができる。
【００８２】
実装例として、以下を考えられたい。まず、一実施形態による、ライセンス要求メッセージを組み込んだ次のＤＥＳＣＲＩＢＥ要求の抜粋を考察する。
【００８３】
【表９】
【００８４】
「Require: com.microsoft.wmdrm-nd」は、この例では、サーバが特定タイプの送信者であることを受信者が予想していることを示すために使用される。「Content-Type: application/vnd.ms-wmdrm-license-request」は、この例では、ＤＥＳＣＲＩＢＥの本体がライセンス要求メッセージを含んでいることを示すために使用される。
【００８５】
エラーがなければ、送信者は、次の項で説明するライセンス応答メッセージを含んだＳＤＰ記述で応答しなければならない。
【００８６】
本体にライセンス要求メッセージを含んだＤＥＳＣＲＩＢＥ要求を受信すると、サーバは、ライセンス応答メッセージを返すことができる。この例では、サーバは、上記の各種パラメータだけでなくライセンス応答メッセージも含むＳＤＰ記述を返す。この実施形態では、ライセンス応答メッセージは、先に述べたように、コンテンツに適用すべきポリシーを指示するＸＭＲライセンスを伝送する。
【００８７】
単なる一実装例として、一実施形態による、ライセンス応答メッセージを組み込んだ下に示すＳＤＰの抜粋を考えられたい。
【００８８】
【表１０】
【００８９】
返されるライセンスは、当該セッションの継続時間にわたって使用されるルートライセンスに相当する。固有のリーフライセンスは、下記のＡＮＮＯＵＮＣＥ要求を介して後の時間に返される。
【００９０】
一実施形態によれば、送信者から返されるＳＤＰは、ＲＦＣ−２３９７（http://www.ietf.org/rfc/rfc2397.txt）の仕様に従ってデータＵＲＬの中に符号化されたライセンス応答メッセージを含む。データＵＲＬに含まれるデータは、この例では、Ｂａｓｅ６４で符号化されなければならず、ＭＩＭＥタイプは、「application/vnd.ms-wmdrm-license-response」に設定されなければならない。
【００９１】
構文の例として次を考える。
【００９２】
【表１１】
【００９３】
この例のデータＵＲＬは、現時点でもなお進行中の作業であるＳＤＰの鍵管理拡張の仕様に従って、「ａ＝ｋｅｙ−ｍｇｍｔ」属性を使用してＳＤＰセッションのレベルに挿入されなければならない。この構文を次に示す。
ａ＝ｋｅｙ−ｍｇｍｔ：ｗｍｄｒｍ−ｎｄ ＵＲＬ
【００９４】
この「ＵＲＬ」パラメータが、上記のデータＵＲＬである。
【００９５】
次いで、更新されたポリシーをストリームの途中で配信するためのＡＮＮＯＵＮＣＥ要求の使用を考察する。具体的には、次に示すＡＮＮＯＵＮＣＥ要求の抜粋は、一実施形態によりリーフライセンスがどのように配信されることができるかを説明するものである。
【００９６】
【表１２】
【００９７】
この例では、「Content-Type: application/vnd.ms-wmdrm-license-response」ヘッダは、要求の本体がライセンス応答メッセージを含んでいることを知らせるために使用されなければならない。「Event-Type: 4000 wmdrm-nd-message」ヘッダは、この例では、ＷＭＤＲＭ−ＮＤメッセージを伝送するイベントであることを示すために使用されなければならない。受信者は、ライセンス応答メッセージを処理して、権利ＩＤがライセンス要求中の権利ＩＤと一致することを確実にしなければならない。エラーがなければ、受信者は、下に示すような２００ ＯＫ応答を送信者に返さなければならない。
【００９８】
【表１３】
【００９９】
ＤＥＳＣＲＩＢＥ要求で返されるライセンスは、ルートライセンスに相当することに留意されたい。送信者は、データ配信の前に、受信者がコンテンツを解読できるようにするリーフライセンスを配信しなければならない。これは、受信者が最初のＰＬＡＹ要求を送信した直後に、送信者は、データフローを開始する前にＡＮＮＯＵＮＣＥ要求でリーフライセンスを送信する責任があることを意味する。
【０１００】
送信者がＡＮＮＯＵＮＣＥメッセージを配信する時と、コンテンツを解読するために新しいライセンスが必要とされる時の間には厳密な関係はない。これは、送信者は、関連付けられた保護コンテンツを含むパケットの配信を開始する前に、さらには後であってもＡＮＮＯＵＮＣＥを配信できることを意味する。保護されるコンテンツを伝送するために用いることが可能な方法の１つは、当業者には理解されるように、ＲＴＰパケットの使用によるものである。
【０１０１】
結論
上記の各種実施形態は、所与の保護されるコンテンツについて、ＤＲＭポリシーの更新等のポリシーの更新を配信し、更新することを可能にする。少なくとも一部の実施形態では、各種のプロトコルを拡張して、そのプロトコルによってポリシーの更新が表され、伝送されることを可能にすることができる。
【０１０２】
本発明について構造的特徴および／または方法論的ステップに固有の術語で説明したが、頭記の特許請求の範囲に定義される本発明は、必ずしもここに説明される特定の特徴またはステップに限定されないことを理解されたい。それら固有の特徴およびステップは、請求される本発明を実装するこのましい形態として開示される。
【図面の簡単な説明】
【０１０３】
【図１】一実施形態における本発明の実施形態に用いられることが可能なプロトコルの例示的な登録手順を説明する図である。
【図２】一実施形態において本発明の実施形態が用いられることが可能なプロトコルの例示的な近接性検出手順を説明する図である。
【図３】一実施形態において本発明の実施形態が用いられることが可能なプロトコルの例示的なセッション確立手順を説明する図である。
【図４】一実施形態において本発明の実施形態が用いられることが可能なプロトコルの例示的なデータ転送手順を説明する図である。
【図５】一実施形態において本発明の実施形態が用いられることが可能なストリーミングプロトコルの態様を説明する図である。
【図６】一実施形態によるルートライセンスおよびリーフライセンスに関連する態様を説明する図である。
【図７】一実施形態による方法におけるステップを記載する流れ図である。
【図８】一実施形態によるルートライセンスおよびリーフライセンスの通信を説明する図である。
【図９】一実施形態によるルートライセンスおよびリーフライセンスの通信を説明する図である。
【背景技術】
【０００１】
デジタル著作権管理（ＤＲＭ）とは、電子機器におけるデジタルメディアコンテンツの使用を規制または制約すること等によってコンテンツを保護するために使用される技術を指す。ＤＲＭの特徴の１つは、所与のマシンまたは機器にメディアコンテンツを結び付けられることである。そのため、通例は、特定のコンテンツに関連し、そのコンテンツに関連付けられた権利と制約を定義するライセンスが所与のマシンまたは機器に結び付けられる。その結果、ユーザは、通例、コンテンツ再生のためにそのコンテンツを取り出し、別のマシンに移すことはできない。
【発明の開示】
【発明が解決しようとする課題】
【０００２】
ＤＲＭで保護される一部のコンテンツの別の特徴は、ＡＳＦファイル等の一部のコンテンツタイプでは、当該ファイル全体には１組の権利と制約、すなわち「ポリシー」のみの適用が許可されることである。例えば、映像ファイルを描画する場合、そのファイル全体についてアナログビデオ出力でＭａｃｒｏｖｉｓｉｏｎを有効にする必要がある場合も、その必要が全くない場合もある。こうした特定タイプのファイルでは、コンテンツに関連付けられたポリシーを、ファイルの途中またはストリームの途中で変更することはできない。
【課題を解決するための手段】
【０００３】
各種実施形態は、保護される所与のコンテンツについて、ＤＲＭポリシーの更新等のポリシーの更新を配信し、更新することを可能にする。少なくとも一部の実施形態では、各種プロトコルを拡張して、当該プロトコルによってポリシーの更新が表され、伝送されることを可能にすることができる。一実施形態では、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ ＰｒｏｔｏｃｏｌすなわちＨＴＴＰを利用してポリシーの更新を伝える。別の実施形態では、Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ ＰｒｏｔｏｃｏｌすなわちＲＴＳＰを使用してポリシーの更新を伝える。
【発明を実施するための最良の形態】
【０００４】
概要
各種実施形態は、保護される所与のコンテンツについて、ＤＲＭポリシーの更新等のポリシーの更新を配信し、更新することを可能にする。少なくともいくつかの実施形態では、各種プロトコルを拡張して、そのプロトコルによってポリシーの更新が表され、伝送されることを可能にすることができる。一実施形態では、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｐｏｒｔ ＰｒｏｔｏｃｏｌすなわちＨＴＴＰを利用してポリシーの更新を伝える。別の実施形態では、Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ ＰｒｏｔｏｃｏｌすなわちＲＴＳＰを使用してポリシーの更新を伝える。
【０００５】
以下の説明では、「コンテンツセキュリティおよびライセンス転送プロトコル」と題する項が提供され、本発明の技術が用いられることが可能な特定の１つのシステムを説明する。その後、「ＲＴＳＰ」と題する項が提供され、ＲＴＳＰ空間における本発明の技術を理解するための少なくともいくらかの背景知識をＲＴＳＰに詳しくない読者に提供する。
【０００６】
その項の後、「更新されたポリシーを配信するためのライセンスのチェーン化」と題する項が提供され、チェーニングライセンスの概念と、本発明のコンテクストでどのようにチェーン化されたライセンスを利用できるかを説明する。その項の次に「ＨＴＴＰを使用した更新ポリシーの配信」と題する項が提供され、ポリシーの更新を配信するためにＨＴＴＰのコンテクストでどのようにチェーン化されたライセンスを使用できるかを説明する。その項の後に「ＲＴＳＰを使用したルートライセンスおよびリーフライセンスの伝送」と題する項が提供され、ポリシーの更新を配信するためにＲＴＳＰのコンテクストでどのようにチェーン化されたライセンスを使用できるかを説明する。
コンテンツセキュリティおよびライセンス転送プロトコル
以下に、デジタルリンクを流れるコンテンツのためにセキュリティを提供し、ライセンスを転送する例示的プロトコルの説明を提供する。このプロトコルは、本発明の各種技術をともに用いることができる例示的プロトコルの単なる一例である。請求される主題の主旨および範囲から逸脱することなく、他のプロトコルを利用できることを認識および理解されたい。
【０００７】
この説明では以下の暗号表記を使用する。
Ｋ｛データ｝ 秘密鍵Ｋでデータが暗号化される。
Ｋ［データ］ 秘密鍵Ｋでデータが署名される。
｛データ｝Ｄｅｖｉｃｅ 機器の公開鍵でデータが暗号化される。
［データ］Ｄｅｖｉｃｅ 機器の秘密鍵でデータが署名される。
【０００８】
この特定のプロトコルでは、登録、再検証、近接性（Proximity）の検出、セッションの確立、およびデータ転送、の５つの主要な手順がある。
【０００９】
登録の手順では、送信者（すなわち別の機器に送信すべきコンテンツを持つ機器）が、対象とされる受信者（すなわちコンテンツが送信される先の機器）を一意にかつセキュアに識別することができる。この特定のプロトコルでは、送信者は、登録された受信者を記憶したデータベースを保持し、あらかじめ決められた少数の受信者を超える受信者が同時に使用されないことを保証する。登録プロセス中に、送信者は、保護コンテンツが広く配布されることを防止するために、近接性検出の手順を用いて、受信者がネットワーク中で送信者の「近く」に位置することも保証する。
【００１０】
再検証の手順を利用して、受信者が送信者の「近く」に位置し続けることを保証する。コンテンツは、過去の所定期間内に登録または再検証されていない限り受信者には配信されない。
【００１１】
セッション確立手順は、受信者が送信者にコンテンツを要求した時に必ず使用される。送信者は、セッションの確立を完了するには、機器が登録され、最近検証されていなければならないことを順守させる。
【００１２】
セッションが確立されると、要求されるコンテンツのデータ転送をセキュアな方式で行うことができる。受信者は、そのセッションを再使用して、コンテンツの特定部分を取り出す（シーク）ことはできるが、別のコンテンツを取り出すには新しいセッションを確立しなければならない。
【００１３】
ここで、図１と、登録の際に送信者と受信者間でやり取りされる各種メッセージを示す下の表との関連で登録の手順を考える。
【００１４】
【表１】
【００１５】
ここで、受信者は、種々の情報の中でも特に受信者のデジタル証明書を含んだ登録要求メッセージを送信する。登録要求メッセージを受信するのに応答して、送信者は、受信者の証明書を検証し、シードおよび無作為のセッションＩＤを生成し、それらを上記に示す形態で登録応答メッセージとして受信者に返す。次いで、受信者は、送信者の署名を検証し、セッションＩＤを入手し、図に示す他の動作を行う。次いで、受信者と送信者は、下記の近接性検出プロセスを経ることができる。
【００１６】
再検証に関しては、上記で概説した手順と同じ手順が行われ、違いは、再検証の際には受信者がすでにデータベースに登録されていることである。
【００１７】
近接性の検出に関して、図２との関連で以下を考える。
【００１８】
近接性検出の手順では、受信者が、近接性検出初期化メッセージに示されるセッションＩＤを含んだメッセージを送信者に送信する。そして、送信者は、ノンス（１２８ビットの無作為値）を含んだメッセージを受信者に送信し、受信者がコンテンツ暗号鍵を使用して暗号化したノンスで応答するのに要する時間を測定する。最後に、送信者は、近接性の検出が成功したか否かを知らせるメッセージを受信者に送信する。
【００１９】
受信者は、近接性の検出が成功した旨の確認を得るまでこのプロセスを繰り返すことができる。ＩＰベースのネットワークでこの特定のプロトコルが使用される場合、近接性検出メッセージは、ＵＤＰを通じて交換される。受信者は、登録応答メッセージを介して送信者のアドレスを知る。受信者のアドレスは、近接性検出開始メッセージを伝送するＵＤＰパケットの受信ＩＰヘッダを調べることによって判定できるので、別個に通信される必要はない。
【００２０】
次の表は、近接性検出の際に交換されるメッセージを示す。
【００２１】
【表２】
【００２２】
セッションの確立に関して、図３と、セッション確立の際に交換されるメッセージを示す次の表との関連で以下を考える。
【００２３】
【表３】
【００２４】
この例では、受信者から送信者にライセンス要求メッセージが送信され、上記の情報を含んでいる。それに応答して、送信者は、上記の情報を含むライセンス応答メッセージを送信することができる。
【００２５】
この特定の例では、ライセンスは、ＸＭＲフォーマットで表され、コンテンツ暗号鍵、コンテンツインテグリティ鍵、送信者のＣＲＬのバージョン、１２８ビットの権利ＩＤ、および１２８ビットの通し番号を含む。ライセンスは、ＯＭＡＣを使用してコンテンツインテグリティ鍵を使用して計算されたＯＭＡＣも含んでいる。
【００２６】
データ転送手順に関して、図４との関連で以下を考える。セッションの確立が完了すると、制御プロトコルに固有の方式でデータ転送が実行される。データ転送の要求と応答は両方とも、制御プロトコルとコンテンツの種類に合わせて特別に定義されなければならない。これを図４に概念的に表す。
【００２７】
本発明の実施形態がともに用いられることが可能な例示的プロトコルの簡単な概要を提供したので、次いでＲＴＳＰの背景情報をいくらか検討する。
【００２８】
ＲＴＳＰ
Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ ＰｒｏｔｏｃｏｌすなわちＲＴＳＰは、当業者には理解されるように、リアルタイムのプロパティを持つデータの配信（すなわちストリーミング）を制御するためのアプリケーションレベルのプロトコルである。ＲＴＳＰは、音声や映像などのリアルタイムデータの制御されたオンデマンドの配信を可能にする、拡張可能な枠組みを提供する。データソースは、生のデータ供給と記憶されたクリップの両方を含むことができる。このプロトコルは、複数のデータ配信セッションを制御し、ＵＤＰ、マルチキャストＵＤＰ、ＴＣＰ等の配信チャネルを選択する手段を提供し、ＲＴＰに基づく配信機構を選択する手段を提供することを目的とする。
【００２９】
ＲＴＳＰは、音声や映像等の連続したメディアの単一のストリーム、または時間同期された数個のストリームを確立し、制御する。連続したメディアストリームを制御ストリームと交互にすることは可能であるが、ＲＴＳＰは、通例は、連続したストリーム自体は配信しない。すなわち、ＲＴＳＰは、マルチメディアサーバの「ネットワーク遠隔制御装置」の役割を果たす。
【００３０】
制御されるストリームのセットは、プレゼンテーション記述によって定義される。ＲＴＳＰでは、ＲＴＳＰ接続という概念はなく、代わりに、サーバが、識別子で区別されるセッションを維持する。ＲＴＳＰセッションは、決してＴＣＰ接続などのトランスポートレベルの接続に結び付けられることはない。ＲＴＳＰセッションの間は、ＲＴＳＰクライアントが、サーバへの高信頼のトランスポート接続を多数オープンおよびクローズしてＲＴＳＰ要求を発行することができる。あるいは、当業者には理解されるように、ＵＤＰなどのコネクションレスのトランスポートプロトコルを用いてもよい。
【００３１】
ＲＴＳＰで制御されるストリームは、ＲＴＰを使用することができるが、ＲＴＳＰの動作は、連続メディアを伝送するために使用されるトランスポート機構に依存しない。
【００３２】
次いで、図５との関連で、クライアント／受信者５００とサーバ／送信者５０２間の典型的なＲＴＳＰ要求／応答のやり取りを考える。
【００３３】
予備知識として、ＲＴＳＰ要求／応答はヘッダを持つが、説明の簡単のためにこのヘッダについては説明しない。ＲＴＳＰでは、クライアント／受信者５００は通例、要求ＵＲＬで識別されるプレゼンテーションまたはメディアオブジェクトの記述をサーバ５０２から取り出すことを目的とする、ＤＥＳＣＲＩＢＥ要求と称されるものを発行する。サーバ５０２は、セッション記述プロトコル（ＳＤＰ）で表された、要求されるリソースの記述で応答する。ＤＥＳＣＲＩＢＥ応答（ＳＤＰ）は、当該応答が記述するリソースについてのメディア初期化情報をすべて含んでいる。
【００３４】
次いで、クライアント５００は、ストリーミングされるメディアに使用されるトランスポート機構を指定するＵＲＩのＳＥＴＵＰ要求を送信する。図５の例では、ＳＥＴＵＰ要求は、音声と映像の両方について送信される。クライアント５００は、ＳＥＴＵＰ要求で、利用しようとするトランスポートパラメータも知らせる。ＳＥＴＵＰ要求のトランスポートヘッダで、データ送信のためにクライアントが許容可能なトランスポートパラメータを指定する。サーバ５０２からのＲＥＳＰＯＮＳＥは、サーバで選択されたトランスポートパラメータを含んでいる。サーバは、ＳＥＴＵＰ要求に応答してセッション識別子も生成する。
【００３５】
この時点で、クライアントは、ＳＥＴＵＰで指定された機構を介してデータ送信を開始するようにサーバに指示するＰＬＡＹ要求を発行することができる。ＰＬＡＹ要求の受信に応答して、サーバは、この例では音声／映像コンテンツであるコンテンツのストリーミングを開始することができる。この例では、当業者には理解されるように、ストリーミングコンテンツは、ＲＴＰパケットを使用してカプセル化され、ＵＤＰを通じて送信される。
【００３６】
ＲＴＳＰプロトコルは、他にも関心の対象となるメソッドを備え、それらには、ＰＡＵＳＥ、ＴＥＡＲＤＯＷＮ、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＲＥＤＩＲＥＣＴ、およびＲＥＣＯＲＤが含まれる。ＲＴＳＰについての追加的な背景知識については、読者は、http://www.ietf.org/rfc/rfc2326.txtで入手可能なRTSP RFC, Schulzrinne, H., Rao, A.および R. Lanphier, 「Real Time Streaming Protocol (RTSP)」, RFC 2326（1998年4月）を参照されたい。
【００３７】
更新されたポリシーを配信するためのライセンスのチェーン化
ここで例示し、説明する実施形態では、ライセンスのチェーン化の概念がポリシー更新プロセスで利用される。この特定の実施形態では、ルートライセンスおよびリーフ（leaf）ライセンスの概念が用いられる。ここで、ルートライセンスは、クライアント／受信者が後に配信されるポリシー更新をそのコンテンツ鍵を使用して解読できるように、クライアント／受信者にコンテンツ鍵を設定し、セキュアに配信するために利用される。最初のコンテンツ鍵がクライアント／受信者にセキュアに配信されると、最初に配信されたそのコンテンツ鍵を使用してサーバ／送信者によって後続のコンテンツ鍵が暗号化され、クライアント／受信者に送信されることができる。クライアントは、最初に配信されたコンテンツ鍵を使用して、関連付けられたポリシー更新を解読することができる。
【００３８】
この特定の方式を実施できる方法の単なる一例を提供するために、図６との関連で以下を考察されたい。この特定の例では、図６のシステムは、公開鍵による暗号動作のための１０２４ビットのＲＳＡ鍵と、対称暗号動作のための１２８ビットのＡＥＳ鍵を使用するように構成される。無論これは単なる一例として提供され、請求される主題の用途を限定するものではない。
【００３９】
この例では、クライアント／受信者６００は、公開鍵／秘密鍵の対６５０を持ち、サーバ／送信者６０２は、クライアント／受信者の公開鍵を持っている。この例では、クライアント／受信者の公開鍵と秘密鍵はそれぞれ、１０２４ビットのＲＳＡ鍵である。サーバ／送信者は、クライアント／受信者の公開鍵を使用して、クライアント／受信者の公開鍵で暗号化された初期コンテンツ鍵を含むルートライセンスを構築する。初期コンテンツ鍵は、１２８ビットのＡＥＳコンテンツ鍵である。このルートライセンスは、次いでクライアント／受信者に送信される。図６で、これは、クライアント／受信者とサーバ／送信者間で行われる最初の通信として示しており、暗号化されたコンテンツ鍵は、｛コンテンツ鍵１｝ＣＬＩＥＮＴと表す。ただし、図の通信より前に他の通信が行われてよいことは理解されたい。
【００４０】
サーバ／送信者から暗号化されたコンテンツ鍵を受信すると、クライアント／受信者は、自身の秘密鍵を使用してコンテンツ鍵を解読することができ、解読したコンテンツ鍵を将来の使用のためにセキュアに格納することができる。以下の説明では、この最初のコンテンツ鍵を初期コンテンツ鍵と呼ぶ。
【００４１】
ここで、ここまでに何が行われたかを考える。サーバ／送信者は、クライアント／受信者にセキュアに鍵を通信しており、この鍵は、後に行われる暗号動作の基盤の役割を果たすことができる。より具体的に、ここで、ストリーミング中に、ＤＲＭで保護された特定のコンテンツに関連するポリシーの更新が行われることを考える。この場合、サーバ／送信者は、更新後のポリシーを含むリーフライセンスを作成することができる。このリーフライセンスは、ポリシーの更新と、暗号化されたバージョンのコンテンツ鍵２を含む。この例では、コンテンツ鍵２は、初期コンテンツ鍵を使用して暗号化された１２８ビットのＡＥＳコンテンツ鍵である。そのため、新しい追加的なコンテンツ鍵を解読することに伴ってクライアント／受信者が受け、負担する計算上の複雑性と費用は、１０２４ビットのＲＳＡ鍵による動作に伴うものに比べて低減される。これは、クライアント／受信者は、この時点で、１２８ビットのＡＥＳコンテンツ鍵（すなわち初期コンテンツ鍵）を使用して解読するだけでよいからである。
【００４２】
ＸＭＲを利用してライセンスとライセンス更新を表す実装例については、次を考察されたい。
【００４３】
ライセンスのチェーン化を使用する目的の１つは、ライセンス更新の際に行われる非対称鍵操作（asymmetric key operations）の回数を減らすことである。この実装例では、権利と制約を伝達するための機構としてルートライセンスを利用することは重視されない。その結果、ルートライセンスは、非常に単純であり、権利や制約を伝えない。ただし、ルートライセンスは、少なくとも一部の実装では、権利と制約を伝送してよいことは理解されたい。
【００４４】
この例では、リーフライセンスは、アップリンクＫＩＤオブジェクトを介してルートライセンスに結び付けられる。以下の項では、一実施形態による、これらのライセンス中に存在するオブジェクトに着目する。
【００４５】
ルートライセンスに関して、以下に、再生のためのルートライセンスに存在するＸＭＲオブジェクトのセットを記載する。
【００４６】
【表４】
【００４７】
再生ポリシーコンテナオブジェクトは、再生を行わせるために存在しなければならない。それに対し、コピー動作のためのルートライセンスは、再生ポリシーコンテナの代わりにコピー権利コンテナオブジェクトを含まなければならない。
【００４８】
次に示すのは、コピーのためのルートライセンスに存在するＸＭＲオブジェクトのセットである。
【００４９】
【表５】
【００５０】
この実施形態では、コピーが許可されることを示すためにコピー権利コンテナオブジェクトが存在しなければならない。再生の権利は常に付与されなければならないため、再生ポリシーコンテナオブジェクトがなお存在することに留意されたい。
【００５１】
この特定の実施形態におけるリーフライセンスに関して、以下を考える。リーフライセンスは、ＸＭＲを介して表すことができる任意の種の権利または制約を含むことができる。リーフライセンスとチェーンおよび非チェーン化ライセンスとの主要な相違は、対称鍵を使用して、コンテンツ鍵と、アップリンクＫＩＤオブジェクトを介した別のライセンスまでのリンクとを暗号化することである。
【００５２】
次に示すのは、再生用のリーフライセンスの一例である。
【００５３】
【表６】
【００５４】
Ｃｏｎｔｅｎｔ Ｋｅｙオブジェクトは、鍵暗号化暗号タイプを０ｘ０００２（チェーン化ライセンス）に設定し、対称暗号タイプを０ｘ０００１（ＡＥＳ ＣＴＲ）に設定しなければならない。アップリンクＫＩＤオブジェクトは、アップリンクＫＩＤフィールドを、ルートライセンスのＫＩＤに設定しなければならない。
【００５５】
次に示すのは、この特定の実施形態における、コピーのためのリーフライセンスの例である。
【００５６】
【表７】
【００５７】
この実施形態では、コピー権利コンテナオブジェクトは、コピーが許可されることを示すために存在しなければならない。コピー回数制約オブジェクトは、許可されるコピー回数に制限がある場合に存在する。コピー保護レベル制約オブジェクトは、コピー先として使用されるシステムに制約がある場合に存在する。再生の権利は常に付与されなければならないので、再生ポリシーコンテナオブジェクトがやはり存在することに注意されたい。
【００５８】
図７は、一実施形態による方法におけるステップを説明する流れ図である。この方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せとの関連で行われることができる。一実施形態では、この方法は、上記で例示し、説明したシステムのようなシステムとの関連で実装されることができる。また、以下の説明では、行われる動作の一部はサーバ／送信者によって行われるものと記述し、他の動作は、クライアント／受信者によって行われるものと記述される。サーバ／送信者およびクライアント／受信者の例は、上記で提供した。
【００５９】
ステップ７００で、クライアント／受信者の公開鍵を使用して初期コンテンツ鍵を暗号化する。任意の適当なコンテンツ鍵を利用することができ、その単なる一例を上記で挙げた。ステップ７０２で、暗号化された初期コンテンツ鍵を含むルートライセンスをクライアント／受信者に送信する。任意の適切な方法を利用してこのステップを実装することができる。以下の説明では、２つの異なるプロトコルを用いた２つの具体例が提供される。それらは例であり、請求される主題の用途を、ここに記載される具体的なプロトコルのみに限定する意図ではないことを認識および理解されたい。
【００６０】
ステップ７０４で、サーバ／送信者から送信されたルートライセンスを受信し、ステップ７０６で、暗号化された初期コンテンツ鍵を解読する。この例では、このステップは、クライアント／受信者の秘密鍵を使用して、暗号化された初期コンテンツ鍵を解読することによって行われる。
【００６１】
ステップ７０８で、リーフライセンスを作成し、初期コンテンツ鍵で新しいコンテンツ鍵を暗号化する。ステップ７１０で、リーフライセンスをクライアント／受信者に送信する。リーフライセンスは、ＤＲＭで保護されたコンテンツのためのポリシーとポリシー更新を含むことができ、通例は実際に含んでいることを思い出されたい。ステップ７０８および７１０は、ＤＲＭで保護された所与のコンテンツについて複数回実行できることを理解および認識されたい。すなわち、ＤＲＭで保護された特定のコンテンツに関してポリシーが変化すると、それに対応するリーフライセンスが作成され、クライアント／受信者に送信されることができる。
【００６２】
ステップ７１２でリーフライセンスを受信し、ステップ７１４で、先に受信された初期コンテンツ鍵を使用して新しいコンテンツ鍵を解読する。次いでステップ７１６で、解読された新しいコンテンツ鍵を使用してコンテンツを解読し、リーフライセンスに入っているポリシーを更新する。
【００６３】
ステップ７１２、７１４、７１６は、クライアント／受信者に受信される新しいリーフライセンスごとに行うことができることを認識および理解されたい。
【００６４】
ＨＴＴＰを使用した更新ポリシーの配信
ルートライセンスおよびリーフライセンスの概念と、各ライセンスが上記のコンテクストでどのように使用されることができるかを説明したので、次いで、ＨＴＴＰを使用してルートライセンスとリーフライセンスがどのように配信されるかを考える。
【００６５】
ＤＲＭで保護されたコンテンツの伝送にＨＴＴＰが利用される場合、クライアントは、サーバ／送信者に２つの要求を発行する。第１に、クライアントは、ルートライセンスを取得するためのＰＯＳＴ要求を発行する。第２に、クライアントは、ＤＲＭで保護されるコンテンツを取得するためのＧＥＴ要求を発行する。通例、ＨＴＴＰでは、サーバはクライアントとの通信を開始することができないので、この例では、クライアントはこれらの要求を発行する。
【００６６】
具体的には、以下の説明との関連で図８を考察されたい。クライアントがルートライセンスを受信したい時、クライアントは、サーバにＰＯＳＴ要求を発行する。ＰＯＳＴ要求は、上述のようにライセンス要求メッセージを含んでいる。この通信を受信するのに応答して、サーバは、ルートライセンスを含んだライセンス応答メッセージで応答し、ルートライセンスは、少なくとも１つの実施形態ではＸＭＲで表される。ルートライセンスを受信し、適宜処理すると、クライアントは、サーバにＧＥＴ要求を発行してＤＲＭ保護コンテンツを要求する。ＧＥＴ要求に応答して、サーバは、１つまたは複数のライセンス応答メッセージと交互に配置された、要求されるコンテンツのセグメントで応答する。各ライセンス応答メッセージは、ＤＲＭで保護されるコンテンツの特定部分に関連するリーフライセンスを含んでいる。このサーバの応答を構築するために任意の適切な機構または交互配置技術（interleaving technique）を使用することができる。
【００６７】
ある特定のコンテクストにおける単なる一実装例として、以下を考える。
【００６８】
単なる一例で、４バイトのフレームヘッダを使用してデータブロックおよび制御ブロックをカプセル化する。フレームヘッダは、ネットワークバイト順で表された、１バイトのＡＳＣＩＩドル記号（０ｘ２４）、次いで１バイトのブロックタイプ識別子、次いで２バイトのカプセル化データ長を含む。
【００６９】
【表８】
【００７０】
制御ブロックは、タイプ識別子としてＡＳＣＩＩの「ｃ」の文字（０ｘ６３）を使用する。このブロックは、メッセージ、通例はライセンス応答メッセージを含む。
【００７１】
データブロックは、ＡＳＣＩＩの「ｄ」の文字（０ｘ６３）をタイプ識別子として使用する。このブロックは、データセグメント記述子を含み、そのすぐ後にメディアデータが続く。
【００７２】
データセグメント記述子は、暗号化されたコンテンツまたは平文のコンテンツと関連付けられることができる。この記述子内の暗号化されたフラグがこの情報を伝達する。データセグメント記述子は、送信されるファイルの一部に関連付けられ、ファイルが暗号化されている場合は、ファイルに単一のポリシーとコンテンツ暗号鍵が適用される。すなわち、コンテンツ暗号鍵とポリシーは、セグメント内では変更されることができない。
【００７３】
一実施形態によれば、リンクの暗号化を伴う典型的なＨＴＴＰ応答は、次のブロックから構成される。
【００７４】
１．チェーン化されたライセンスを含むライセンス応答メッセージを伝送する制御ブロック［＄ｃ］
２．１つまたは複数のデータブロック［＄ｄ］
【００７５】
ファイルの送信中に鍵またはポリシーの変更がある場合には、以下のステップが追加される。
【００７６】
３．新しいチェーン化ライセンスを含むライセンス応答メッセージを伝送する新しい制御ブロック［＄ｃ］
４．１つまたは複数のデータブロック［＄ｄ］
【００７７】
ステップ３および４は、複数の鍵またはポリシーの変更がある場合には複数回行われてよいことに留意されたい。
【００７８】
ＲＴＳＰを使用したルートライセンスおよびリーフライセンスの伝送
ルートライセンスおよびリーフライセンスの概念と、各ライセンスがＨＴＴＰを使用してどのように配信される方法を説明したので、次いで、ＲＴＳＰを使用してルートライセンスおよびリーフライセンスがどのように配信されることができるかを考える。
【００７９】
ＲＴＳＰとＨＴＴＰの違いの１つは、ＲＴＳＰは、ＨＴＴＰに比べてかなり高機能であることである。具体的には、ＲＴＳＰは、サーバによって開始される要求についての規定を備え、それにより、サーバは、いつでもクライアントにコマンドを送信することができる。この実施形態により、図９との関連で以下を考えられたい。
【００８０】
クライアント／受信者がＤＲＭで保護されるコンテンツを再生したい場合、クライアントは、ライセンス要求メッセージを含むＤＥＳＣＲＩＢＥ要求を送信する。このメッセージの受信に応答して、サーバは、ライセンス応答メッセージを埋め込むセッション記述プロトコル（ＳＤＰ）で応答する。このライセンス応答メッセージは、この特定の実施形態ではＸＭＲで表される、ルートライセンスを含む。
【００８１】
次いで、クライアントがＤＲＭで保護されるコンテンツを受信したい時、クライアントは、ＰＬＡＹ要求をサーバに送信してストリームを開始する。任意の適切な時に、サーバは、クライアントにＡＮＮＯＵＮＣＥ要求を送信してリーフライセンスを含んだライセンス応答メッセージを伝送することができる。
【００８２】
実装例として、以下を考えられたい。まず、一実施形態による、ライセンス要求メッセージを組み込んだ次のＤＥＳＣＲＩＢＥ要求の抜粋を考察する。
【００８３】
【表９】
【００８４】
「Require: com.microsoft.wmdrm-nd」は、この例では、サーバが特定タイプの送信者であることを受信者が予想していることを示すために使用される。「Content-Type: application/vnd.ms-wmdrm-license-request」は、この例では、ＤＥＳＣＲＩＢＥの本体がライセンス要求メッセージを含んでいることを示すために使用される。
【００８５】
エラーがなければ、送信者は、次の項で説明するライセンス応答メッセージを含んだＳＤＰ記述で応答しなければならない。
【００８６】
本体にライセンス要求メッセージを含んだＤＥＳＣＲＩＢＥ要求を受信すると、サーバは、ライセンス応答メッセージを返すことができる。この例では、サーバは、上記の各種パラメータだけでなくライセンス応答メッセージも含むＳＤＰ記述を返す。この実施形態では、ライセンス応答メッセージは、先に述べたように、コンテンツに適用すべきポリシーを指示するＸＭＲライセンスを伝送する。
【００８７】
単なる一実装例として、一実施形態による、ライセンス応答メッセージを組み込んだ下に示すＳＤＰの抜粋を考えられたい。
【００８８】
【表１０】
【００８９】
返されるライセンスは、当該セッションの継続時間にわたって使用されるルートライセンスに相当する。固有のリーフライセンスは、下記のＡＮＮＯＵＮＣＥ要求を介して後の時間に返される。
【００９０】
一実施形態によれば、送信者から返されるＳＤＰは、ＲＦＣ−２３９７（http://www.ietf.org/rfc/rfc2397.txt）の仕様に従ってデータＵＲＬの中に符号化されたライセンス応答メッセージを含む。データＵＲＬに含まれるデータは、この例では、Ｂａｓｅ６４で符号化されなければならず、ＭＩＭＥタイプは、「application/vnd.ms-wmdrm-license-response」に設定されなければならない。
【００９１】
構文の例として次を考える。
【００９２】
【表１１】
【００９３】
この例のデータＵＲＬは、現時点でもなお進行中の作業であるＳＤＰの鍵管理拡張の仕様に従って、「ａ＝ｋｅｙ−ｍｇｍｔ」属性を使用してＳＤＰセッションのレベルに挿入されなければならない。この構文を次に示す。
ａ＝ｋｅｙ−ｍｇｍｔ：ｗｍｄｒｍ−ｎｄ ＵＲＬ
【００９４】
この「ＵＲＬ」パラメータが、上記のデータＵＲＬである。
【００９５】
次いで、更新されたポリシーをストリームの途中で配信するためのＡＮＮＯＵＮＣＥ要求の使用を考察する。具体的には、次に示すＡＮＮＯＵＮＣＥ要求の抜粋は、一実施形態によりリーフライセンスがどのように配信されることができるかを説明するものである。
【００９６】
【表１２】
【００９７】
この例では、「Content-Type: application/vnd.ms-wmdrm-license-response」ヘッダは、要求の本体がライセンス応答メッセージを含んでいることを知らせるために使用されなければならない。「Event-Type: 4000 wmdrm-nd-message」ヘッダは、この例では、ＷＭＤＲＭ−ＮＤメッセージを伝送するイベントであることを示すために使用されなければならない。受信者は、ライセンス応答メッセージを処理して、権利ＩＤがライセンス要求中の権利ＩＤと一致することを確実にしなければならない。エラーがなければ、受信者は、下に示すような２００ ＯＫ応答を送信者に返さなければならない。
【００９８】
【表１３】
【００９９】
ＤＥＳＣＲＩＢＥ要求で返されるライセンスは、ルートライセンスに相当することに留意されたい。送信者は、データ配信の前に、受信者がコンテンツを解読できるようにするリーフライセンスを配信しなければならない。これは、受信者が最初のＰＬＡＹ要求を送信した直後に、送信者は、データフローを開始する前にＡＮＮＯＵＮＣＥ要求でリーフライセンスを送信する責任があることを意味する。
【０１００】
送信者がＡＮＮＯＵＮＣＥメッセージを配信する時と、コンテンツを解読するために新しいライセンスが必要とされる時の間には厳密な関係はない。これは、送信者は、関連付けられた保護コンテンツを含むパケットの配信を開始する前に、さらには後であってもＡＮＮＯＵＮＣＥを配信できることを意味する。保護されるコンテンツを伝送するために用いることが可能な方法の１つは、当業者には理解されるように、ＲＴＰパケットの使用によるものである。
【０１０１】
結論
上記の各種実施形態は、所与の保護されるコンテンツについて、ＤＲＭポリシーの更新等のポリシーの更新を配信し、更新することを可能にする。少なくとも一部の実施形態では、各種のプロトコルを拡張して、そのプロトコルによってポリシーの更新が表され、伝送されることを可能にすることができる。
【０１０２】
本発明について構造的特徴および／または方法論的ステップに固有の術語で説明したが、頭記の特許請求の範囲に定義される本発明は、必ずしもここに説明される特定の特徴またはステップに限定されないことを理解されたい。それら固有の特徴およびステップは、請求される本発明を実装するこのましい形態として開示される。
【図面の簡単な説明】
【０１０３】
【図１】一実施形態における本発明の実施形態に用いられることが可能なプロトコルの例示的な登録手順を説明する図である。
【図２】一実施形態において本発明の実施形態が用いられることが可能なプロトコルの例示的な近接性検出手順を説明する図である。
【図３】一実施形態において本発明の実施形態が用いられることが可能なプロトコルの例示的なセッション確立手順を説明する図である。
【図４】一実施形態において本発明の実施形態が用いられることが可能なプロトコルの例示的なデータ転送手順を説明する図である。
【図５】一実施形態において本発明の実施形態が用いられることが可能なストリーミングプロトコルの態様を説明する図である。
【図６】一実施形態によるルートライセンスおよびリーフライセンスに関連する態様を説明する図である。
【図７】一実施形態による方法におけるステップを記載する流れ図である。
【図８】一実施形態によるルートライセンスおよびリーフライセンスの通信を説明する図である。
【図９】一実施形態によるルートライセンスおよびリーフライセンスの通信を説明する図である。
【特許請求の範囲】
【請求項１】
コンピュータによって実施される方法であって、
意図される受信者の公開鍵を使用して暗号化された暗号化初期コンテンツ鍵を含むルートライセンスを構築することであって、前記ルートライセンスは、前記意図される受信者にストリーミングされるコンテンツに関連する、そのようなルートライセンスを構築することと、
前記ルートライセンスを前記意図される受信者に送信することと、
前記ルートライセンスにチェーン化で結び付けられた１つまたは複数のリーフライセンスを作成することであって、前記１つまたは複数のリーフライセンスは、前記ストリーミングされるコンテンツに関連付けられた更新後のポリシーに関連するものであり、前記１つまたは複数のリーフライセンスはそれぞれ、前記初期コンテンツ鍵を使用して暗号化された異なるコンテンツ鍵を含み、前記異なるコンテンツ鍵は、保護されるコンテンツを解読するために前記受信者によって使用されることができる、そのような１つまたは複数のリーフライセンスを作成することと、
前記１つまたは複数のリーフライセンスを前記意図される受信者に送信することと
を備えることを特徴とする方法。
【請求項２】
前記初期コンテンツ鍵は、前記公開鍵よりも少ないビットを有することを特徴とする請求項１に記載の方法。
【請求項３】
前記初期コンテンツ鍵は、１２８ビットのＡＥＳ鍵からなることを特徴とする請求項２に記載の方法。
【請求項４】
前記異なるコンテンツ鍵は、前記公開鍵よりも少ないビットを有することを特徴とする請求項１に記載の方法。
【請求項５】
前記異なるコンテンツ鍵は、１２８ビットのＡＥＳ鍵からなることを特徴とする請求項４に記載の方法。
【請求項６】
前記ルートライセンスと前記１つまたは複数のリーフライセンスを送信する動作は、ＨＴＴＰを使用して行われることを特徴とする請求項１に記載の方法。
【請求項７】
前記ルートライセンスと前記１つまたは複数のリーフライセンスを送信する動作は、ＨＴＴＰを使用して行われ、前記１つまたは複数のリーフライセンスを送信する動作は、保護されるコンテンツを、前記１つまたは複数のリーフライセンスを含むデータと交互に配置することを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記ルートライセンスと前記１つまたは複数のリーフライセンスを送信する動作は、ＲＴＳＰを使用して行われることを特徴とする請求項１に記載の方法。
【請求項９】
コンピュータによって実施される方法であって、
受信者にストリーミングされようとする保護されるコンテンツのルートライセンスを要求するＨＴＴＰ ＰＯＳＴ要求を受信することと、
前記受信に応答して、前記受信者にルートライセンスを送信することと、
保護されるコンテンツを要求するＨＴＴＰ ＧＥＴ要求を受信することと、
ＨＴＴＰ ＧＥＴ要求の前記受信に応答して、前記ルートライセンスにチェーン化された１つまたは複数のリーフライセンスを含むデータと交互に配置された、要求される保護コンテンツのセグメントを送信することと
を備えることを特徴とする方法。
【請求項１０】
前記ＨＴＴＰ ＰＯＳＴ要求は、ライセンス要求メッセージを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
ルートライセンスを送信する前記動作は、前記受信者にライセンス応答メッセージを送信することによって行われることを特徴とする請求項９に記載の方法。
【請求項１２】
前記１つまたは複数のリーフライセンスを含む前記データは、それぞれ、１つまたは複数のライセンス応答メッセージからなることを特徴とする請求項９に記載の方法。
【請求項１３】
コンピュータによって実施される方法であって、
受信者にストリーミングされる保護されるコンテンツのルートライセンスを要求するＲＴＳＰ ＤＥＳＣＲＩＢＥ要求を受信することと、
前記受信者にルートライセンスを送信することと、
前記ルートライセンスにチェーン化で結び付けられた１つまたは複数のリーフライセンスを送信することであって、前記１つまたは複数のリーフライセンスの送信は、コンテンツのストリーミング中に行われることと
を備えることを特徴とする方法。
【請求項１４】
前記ＤＥＳＣＲＩＢＥ要求は、ライセンス要求メッセージを含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記ルートライセンスを送信する前記動作は、前記ルートライセンスを含んだライセンス応答メッセージを埋め込むＲＴＳＰセッション記述プロトコル（ＳＤＰ）を送信することを含むことを特徴とする請求項１３に記載の方法。
【請求項１６】
１つまたは複数のリーフライセンスを送信する前記動作は、それぞれ、１つまたは複数のＲＴＳＰ ＡＮＮＯＵＮＣＥ要求を使用して行われることを特徴とする請求項１３に記載の方法。
【請求項１７】
１つまたは複数のリーフライセンスを送信する前記動作は、それぞれ、１つまたは複数のＲＴＳＰ ＡＮＮＯＵＮＣＥ要求を使用して行われ、前記ＲＴＳＰ ＡＮＮＯＵＮＣＥ要求は、それぞれ、ライセンス応答メッセージを含むことを特徴とする請求項１３に記載の方法。
【請求項１８】
前記ＤＥＳＣＲＩＢＥ要求は、ライセンス要求メッセージを含み、
前記ルートライセンスを送信する前記動作は、前記ルートライセンスを含んだライセンス応答メッセージを埋め込むＲＴＳＰセッション記述プロトコル（ＳＤＰ）を送信することを含む
ことを特徴とする請求項１３に記載の方法。
【請求項１９】
前記ルートライセンスを送信する前記動作は、前記ルートライセンスを含んだライセンス応答メッセージを埋め込むＲＴＳＰセッション記述プロトコル（ＳＤＰ）を送信することを含み、
１つまたは複数のリーフライセンスを送信する前記動作は、それぞれ、１つまたは複数のＲＴＳＰ ＡＮＮＯＵＮＣＥ要求を使用して行われる
ことを特徴とする請求項１３に記載の方法。
【請求項２０】
前記ＤＥＳＣＲＩＢＥ要求は、ライセンス要求メッセージを含み、
前記ルートライセンスを送信する前記動作は、前記ルートライセンスを含んだライセンス応答メッセージを埋め込むＲＴＳＰセッション記述プロトコル（ＳＤＰ）を送信することを含み、
１つまたは複数のリーフライセンスを送信する前記動作は、それぞれ、１つまたは複数のＲＴＳＰ ＡＮＮＯＵＮＣＥ要求を使用して行われる
ことを特徴とする請求項１３に記載の方法。
【請求項１】
コンピュータによって実施される方法であって、
意図される受信者の公開鍵を使用して暗号化された暗号化初期コンテンツ鍵を含むルートライセンスを構築することであって、前記ルートライセンスは、前記意図される受信者にストリーミングされるコンテンツに関連する、そのようなルートライセンスを構築することと、
前記ルートライセンスを前記意図される受信者に送信することと、
前記ルートライセンスにチェーン化で結び付けられた１つまたは複数のリーフライセンスを作成することであって、前記１つまたは複数のリーフライセンスは、前記ストリーミングされるコンテンツに関連付けられた更新後のポリシーに関連するものであり、前記１つまたは複数のリーフライセンスはそれぞれ、前記初期コンテンツ鍵を使用して暗号化された異なるコンテンツ鍵を含み、前記異なるコンテンツ鍵は、保護されるコンテンツを解読するために前記受信者によって使用されることができる、そのような１つまたは複数のリーフライセンスを作成することと、
前記１つまたは複数のリーフライセンスを前記意図される受信者に送信することと
を備えることを特徴とする方法。
【請求項２】
前記初期コンテンツ鍵は、前記公開鍵よりも少ないビットを有することを特徴とする請求項１に記載の方法。
【請求項３】
前記初期コンテンツ鍵は、１２８ビットのＡＥＳ鍵からなることを特徴とする請求項２に記載の方法。
【請求項４】
前記異なるコンテンツ鍵は、前記公開鍵よりも少ないビットを有することを特徴とする請求項１に記載の方法。
【請求項５】
前記異なるコンテンツ鍵は、１２８ビットのＡＥＳ鍵からなることを特徴とする請求項４に記載の方法。
【請求項６】
前記ルートライセンスと前記１つまたは複数のリーフライセンスを送信する動作は、ＨＴＴＰを使用して行われることを特徴とする請求項１に記載の方法。
【請求項７】
前記ルートライセンスと前記１つまたは複数のリーフライセンスを送信する動作は、ＨＴＴＰを使用して行われ、前記１つまたは複数のリーフライセンスを送信する動作は、保護されるコンテンツを、前記１つまたは複数のリーフライセンスを含むデータと交互に配置することを含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記ルートライセンスと前記１つまたは複数のリーフライセンスを送信する動作は、ＲＴＳＰを使用して行われることを特徴とする請求項１に記載の方法。
【請求項９】
コンピュータによって実施される方法であって、
受信者にストリーミングされようとする保護されるコンテンツのルートライセンスを要求するＨＴＴＰ ＰＯＳＴ要求を受信することと、
前記受信に応答して、前記受信者にルートライセンスを送信することと、
保護されるコンテンツを要求するＨＴＴＰ ＧＥＴ要求を受信することと、
ＨＴＴＰ ＧＥＴ要求の前記受信に応答して、前記ルートライセンスにチェーン化された１つまたは複数のリーフライセンスを含むデータと交互に配置された、要求される保護コンテンツのセグメントを送信することと
を備えることを特徴とする方法。
【請求項１０】
前記ＨＴＴＰ ＰＯＳＴ要求は、ライセンス要求メッセージを含むことを特徴とする請求項９に記載の方法。
【請求項１１】
ルートライセンスを送信する前記動作は、前記受信者にライセンス応答メッセージを送信することによって行われることを特徴とする請求項９に記載の方法。
【請求項１２】
前記１つまたは複数のリーフライセンスを含む前記データは、それぞれ、１つまたは複数のライセンス応答メッセージからなることを特徴とする請求項９に記載の方法。
【請求項１３】
コンピュータによって実施される方法であって、
受信者にストリーミングされる保護されるコンテンツのルートライセンスを要求するＲＴＳＰ ＤＥＳＣＲＩＢＥ要求を受信することと、
前記受信者にルートライセンスを送信することと、
前記ルートライセンスにチェーン化で結び付けられた１つまたは複数のリーフライセンスを送信することであって、前記１つまたは複数のリーフライセンスの送信は、コンテンツのストリーミング中に行われることと
を備えることを特徴とする方法。
【請求項１４】
前記ＤＥＳＣＲＩＢＥ要求は、ライセンス要求メッセージを含むことを特徴とする請求項１３に記載の方法。
【請求項１５】
前記ルートライセンスを送信する前記動作は、前記ルートライセンスを含んだライセンス応答メッセージを埋め込むＲＴＳＰセッション記述プロトコル（ＳＤＰ）を送信することを含むことを特徴とする請求項１３に記載の方法。
【請求項１６】
１つまたは複数のリーフライセンスを送信する前記動作は、それぞれ、１つまたは複数のＲＴＳＰ ＡＮＮＯＵＮＣＥ要求を使用して行われることを特徴とする請求項１３に記載の方法。
【請求項１７】
１つまたは複数のリーフライセンスを送信する前記動作は、それぞれ、１つまたは複数のＲＴＳＰ ＡＮＮＯＵＮＣＥ要求を使用して行われ、前記ＲＴＳＰ ＡＮＮＯＵＮＣＥ要求は、それぞれ、ライセンス応答メッセージを含むことを特徴とする請求項１３に記載の方法。
【請求項１８】
前記ＤＥＳＣＲＩＢＥ要求は、ライセンス要求メッセージを含み、
前記ルートライセンスを送信する前記動作は、前記ルートライセンスを含んだライセンス応答メッセージを埋め込むＲＴＳＰセッション記述プロトコル（ＳＤＰ）を送信することを含む
ことを特徴とする請求項１３に記載の方法。
【請求項１９】
前記ルートライセンスを送信する前記動作は、前記ルートライセンスを含んだライセンス応答メッセージを埋め込むＲＴＳＰセッション記述プロトコル（ＳＤＰ）を送信することを含み、
１つまたは複数のリーフライセンスを送信する前記動作は、それぞれ、１つまたは複数のＲＴＳＰ ＡＮＮＯＵＮＣＥ要求を使用して行われる
ことを特徴とする請求項１３に記載の方法。
【請求項２０】
前記ＤＥＳＣＲＩＢＥ要求は、ライセンス要求メッセージを含み、
前記ルートライセンスを送信する前記動作は、前記ルートライセンスを含んだライセンス応答メッセージを埋め込むＲＴＳＰセッション記述プロトコル（ＳＤＰ）を送信することを含み、
１つまたは複数のリーフライセンスを送信する前記動作は、それぞれ、１つまたは複数のＲＴＳＰ ＡＮＮＯＵＮＣＥ要求を使用して行われる
ことを特徴とする請求項１３に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公表番号】特表２００９−５０１３９３（Ｐ２００９−５０１３９３Ａ）
【公表日】平成２１年１月１５日（２００９．１．１５）
【国際特許分類】
【出願番号】特願２００８−５２１５３３（Ｐ２００８−５２１５３３）
【出願日】平成１８年７月１１日（２００６．７．１１）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０２６９１３
【国際公開番号】ＷＯ２００７／００８９１２
【国際公開日】平成１９年１月１８日（２００７．１．１８）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成２１年１月１５日（２００９．１．１５）
【国際特許分類】
【出願日】平成１８年７月１１日（２００６．７．１１）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０２６９１３
【国際公開番号】ＷＯ２００７／００８９１２
【国際公開日】平成１９年１月１８日（２００７．１．１８）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]