JP2009500944A

JP2009500944A - ストリーミング用制御プロトコルおよびトランスポートプロトコルを使用した、保護付きコンテンツの搬送

Info

Publication number: JP2009500944A
Application number: JP2008520256A
Authority: JP
Inventors: パカアナンド; イー．クレメッツアンダース; ピー．オリベイラエドアルド; バットサンジェイ
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-07-07
Filing date: 2006-06-22
Publication date: 2009-01-08
Anticipated expiration: 2026-06-22
Also published as: KR101203266B1; US20070011344A1; EP1899838B1; EP1899838A2; WO2007008362A3; US7769880B2; WO2007008362A2; CN101506790B; KR20080033930A; CN101506790A; EP1899838A4; JP5021639B2

Abstract

本発明の様々な実施形態は、ディジタル著作権管理（ＤＲＭ）などのコンテンツ保護方法を利用して、ホームメディアネットワークなどのローカルネットワーク内のマシンおよびデバイス上での安全なコンテンツ再生を可能にする。少なくともいくつかの実施形態では、メッセージおよびコンテンツは、ストリーミング用制御プロトコルおよびトランスポートプロトコルをそれぞれ使用して送達される。少なくともいくつかの実施形態では、ストリーミング用制御プロトコルはリアルタイムストリーミングプロトコル（ＲＴＳＰ）であり、トランスポートプロトコルはリアルタイムトランスポートプロトコル（ＲＴＰ）である。

Description

本発明は、ＤＲＭなどの保護付きコンテンツを他のマシンに移して、そのマシン上でコンテンツの再生を可能にする技術に関する。

ディジタル著作権管理（ＤＲＭ、Digital Rights Management）は、電子デバイス上でのディジタルメディアコンテンツの使用を制御または制限することなどによってコンテンツを保護するのに用いられる技法を指す。ＤＲＭの特性の１つは、メディアコンテンツを所与のマシンまたはデバイスに束縛できることである。すなわち、特定のコンテンツに属するライセンスであって、このコンテンツに関連する権利および制限を定義するライセンスは、通常、所与のマシンまたはデバイスに束縛されることになる。この結果、ユーザは通常、このコンテンツを再生するために、このコンテンツを取り込んで別のマシンに移すことはできなくなる。

http://www.ietf.org/rfc/rfc2326.txtで入手可能なRTSP RFC, Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326、１９９８年４月ＲＦＣ−２３９７（http://www.ietf.org/rfc/rfc2397.txt） http://download.microsoft.com/download/5/5/a/55a7b886-b742-4613-8ea8-d8b8b5c27bbc/RTPPayloadFormat_for_WMAandWMV_vl.doc

ＤＲＭ保護付きコンテンツを他のマシンに移してこれらのマシン上でコンテンツの再生を可能にできるようにする技術はいくつかあるが、このような技術は、コンテンツの転送と再生とを同時に行うのには適さない非リアルタイムのコンテンツ転送用プロトコルを使用しがちな可能性がある。

（概観）
本明細書に述べる様々な実施形態は、ディジタル著作権管理（ＤＲＭ）などのコンテンツ保護方法を利用して、ホームメディアネットワークなどのローカルネットワーク内のマシンおよびデバイス上での安全なコンテンツ再生を可能にする。少なくともいくつかの実施形態では、メッセージおよびコンテンツは、ストリーミング用制御プロトコルおよびトランスポートプロトコルをそれぞれ使用して送達される。少なくともいくつかの実施形態では、ストリーミング用制御プロトコルはリアルタイムストリーミングプロトコル（ＲＴＳＰ）であり、トランスポートプロトコルはリアルタイムトランスポートプロトコル（ＲＴＰ）である。これらの実施形態では、ＲＴＳＰ／ＲＴＰによってもたらされる利点を享受するプロトコル拡張子（protocol extension）が導入され、当業者には理解されるであろうが、これらの利点には、ユーザデータグラムプロトコル（ＵＤＰ）を介したデータ送達、および、クライアントとサーバとの間の双方向通信が含まれる。

具体的には、少なくともいくつかの実施形態では、プロトコル拡張子は、ＲＴＳＰを使用してセッションを安全に確立し、ＲＴＰ中にカプセル化された保護付きデータを転送し、ＲＴＰペイロードフォーマットに応じてデータを暗号化および転送する方式を提供し、暗号化済みコンテンツデータと共に暗号化パラメータを転送するための様々な方法を提供する。

以下の説明では、「コンテンツセキュリティおよびライセンス転送プロトコル」という題名のセクションを提供し、発明的技法をその中で利用できる１つの特定のシステムについて述べる。これに続いて、「ＲＴＳＰ」という題名のセクションを提供して、ＲＴＳＰに馴染みのない読者に、ＲＴＳＰ空間で発明的技法を理解するための少なくともいくらかのコンテキストを提供する。このセクションに続いて、「ＲＴＳＰを使用した例示的な実装形態」という題名のセクションを提供し、制御フローの確立にＲＴＳＰを利用してデータフローの確立にＲＴＰを利用する様々な発明的技法について述べる。

（コンテンツセキュリティおよびライセンス転送プロトコル）
以下、ディジタルリンクを介して流れるコンテンツのためにセキュリティを提供し、ライセンスを転送する例示的なプロトコルに関する説明を提供する。このプロトコルは、様々な発明的技法をそれと共に利用することのできる１つの例示的なプロトコルを構成するに過ぎない。特許請求する主題の趣旨および範囲を逸脱することなく他のプロトコルを利用することもできることを認識および理解されたい。

本明細書では、以下の暗号表記法を使用する。
Ｋ｛ｄａｔａ｝データは秘密鍵Ｋで暗号化されている。
Ｋ［ｄａｔａ］データは秘密鍵Ｋで署名されている。
｛ｄａｔａ｝_{Ｄｅｖｉｃｅ} データはデバイスの公開鍵で暗号化されている。
［ｄａｔａ］_{Ｄｅｖｉｃｅ} データはデバイスの秘密鍵で署名されている。

この特定のプロトコルでは、５つの主要なプロシージャがある。すなわち、登録、再妥当性検査、近接検出、セッション確立、およびデータ転送である。

登録プロシージャでは、送信側（すなわち別のデバイスに送信されるコンテンツを有するデバイス）は、意図された受信側（すなわちコンテンツの送信先となるデバイス）を、一意かつ安全に識別することができる。この特定のプロトコルでは、送信側は、登録された受信側を含むデータベースを維持し、わずかな所定数の受信側よりも多くの受信側が同時に使用されないようにする。登録プロセスの間、送信側はまた、保護付きコンテンツが広く配信されるのを防止するために、近接検出プロシージャを利用して、受信側がネットワーク中で送信側の「近く」に位置するようにする。

再妥当性検査プロシージャは、受信側が送信側の「近く」にあり続けるようにするために使用される。受信側が過去の所定期間内に登録または再妥当性検査されていない限り、コンテンツは受信側に送達されない。

セッション確立プロシージャは、受信側が送信側にコンテンツを要求するときはいつでも使用される。送信側は、デバイスが登録され最近に妥当性検査されていなければならないことを守らせた後で、セッション確立を完了することができる。

セッションが確立されると、要求されたコンテンツのデータ転送を安全な方式で行うことができる。受信側は、セッションを再利用してコンテンツの特定部分を取り出すことはできるが（シーキング）、異なるコンテンツを取り出すには新しいセッションを確立しなければならない。

次に、図１と、登録の間に送信側と受信側との間でやり取りされる様々なメッセージを記述した以下の表と共に、登録プロシージャを考えてみる。

ここで、受信側は登録要求メッセージを送信するが、この登録要求メッセージは、情報の中でもとりわけ、受信側のディジタル証明書を含む。送信側は、登録要求メッセージを受信するのに応答して、受信側の証明書を妥当性検査し、シードおよびランダムなセッションＩＤを生成し、これらを、上に示す形で、登録応答メッセージ中で受信側に返す。次いで受信側は、送信側の署名を妥当性検査し、セッションＩＤを入手し、図に示す他のアクションを実施する。次いで受信側および送信側は、後述する近接検出プロセスを経ることができる。

再妥当性検査に関しては、上に概説したのと同じプロシージャが実施されるが、相違点として、再妥当性検査の間は、受信側はすでにデータベースに登録されている。

近接検出に関しては、図２と共に以下を考えてみる。

近接検出の間、受信側は、近接検出初期化メッセージ中で示されたセッションＩＤを含むメッセージを、送信側に送信する。次いで送信側は、ナンス（Nonce）（１２８ビットのランダム値）を含むメッセージを受信側に送信し、コンテンツ暗号化鍵を使用して暗号化されたナンスで受信側が返信するのにかかる時間を測定する。最後に、送信側は、近接検出が成功したか否かを示すメッセージを受信側に送信する。

受信側は、近接検出が成功したという確証を有するまで、このプロセスを繰り返すことができる。この特定のプロトコルがＩＰベースのネットワークを介して使用されるときは、近接検出メッセージはＵＤＰを介して交換される。受信側は、登録応答メッセージを介して、送信側のアドレスを知る。受信側のアドレスは、近接検出初期化メッセージを搬送するＵＤＰパケットの入来ＩＰヘッダを調べることによって決定することができるので、別個に通信する必要はない。

以下の表に、近接検出の間に交換されるメッセージを記述する。

セッション確立に関しては、図３と、セッション確立の間に交換されるメッセージを記述した以下の表と共に、以下を考えてみる。

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

この特定の例では、ライセンスはＸＭＲフォーマットで表され、コンテンツ暗号化鍵、コンテンツインテグリティ鍵（content integrity key）、送信側のＣＲＬのバージョン、１２８ビットの権利ＩＤ、および１２８ビットのシリアル番号を含む。ライセンスはまた、ＯＭＡＣを使用するコンテンツインテグリティ鍵を使用して計算されたＯＭＡＣも含む。

データ転送プロシージャに関しては、図４と共に以下を考えてみる。セッション確立が完了すると、制御プロトコル特有の方式でデータ転送が実行される。データ転送要求と応答は両方とも、制御プロトコルおよびコンテンツタイプに対して具体的に定義されなければならない。これを図４に概念的に表す。

発明的な実施形態をそれと共に利用することのできる例示的なプロトコルの簡単な概観をここに提供したが、次に、ＲＴＳＰに関するいくらかの背景情報を考えてみる。

（ＲＴＳＰ）
当業者には理解されるであろうが、リアルタイムストリーミングプロトコルすなわちＲＴＳＰは、リアルタイムプロパティを有するデータの送達（すなわちストリーミング）に対する制御のための、アプリケーションレベルのプロトコルである。ＲＴＳＰは、オーディオやビデオなどのリアルタイムデータの、制御されたオンデマンドの送達を可能にするための、拡張可能フレームワークを提供する。データのソースは、ライブデータフィードと記憶済みクリップとの両方を含むことができる。このプロトコルは、複数のデータ送達セッションを制御し、ＵＤＰやマルチキャストＵＤＰやＴＣＰなどの送達チャネルを選択する手段を提供し、ＲＴＰに基づく送達機構を選択する手段を提供するように意図されている。

ＲＴＳＰは、オーディオやビデオなど連続的なメディアの、単一またはいくつかの時間同期ストリームを確立および制御する。連続的なメディアストリームに制御ストリームをインタリーブすることは可能だが、ＲＴＳＰは通常、連続的なストリーム自体は送達しない。言い換えれば、ＲＴＳＰは、マルチメディアサーバに対する「ネットワークリモートコントロール」としての働きをする。

制御されることになる１組のストリームは、プレゼンテーション記述（presentation description）によって定義される。ＲＴＳＰでは、ＲＴＳＰ接続の概念はない。そうではなく、サーバが、識別子でラベル付けされたセッションを維持する。ＲＴＳＰセッションは、ＴＣＰ接続などのトランスポートレベルの接続に結び付けられることは決してない。ＲＴＳＰセッションの間、ＲＴＳＰクライアントは、サーバへの多くの信頼できるトランスポート接続を開閉して、ＲＴＳＰ要求を発行することができる。あるいは、当業者には理解されるであろうが、ＵＤＰなどのコネクションレストランスポートプロトコルを使用することもできる。

ＲＴＳＰによって制御されるストリームは、ＲＴＰを使用することができるが、ＲＴＳＰの動作は、連続的なメディアを搬送するのに使用されるトランスポート機構に依存しない。

次に、図５と共に、クライアント／受信側５００とサーバ／送信側５０２との間の典型的なＲＴＳＰ要求／応答交換を考えてみる。

ＲＴＳＰ要求／応答はヘッダを有するが、話を簡単にするために、ヘッダについては述べない。ＲＴＳＰでは、クライアント／受信側５００は通常、ＤＥＳＣＲＩＢＥ要求として知られるものを発行する。これは、要求ＵＲＬで識別されるプレゼンテーションまたはメディアオブジェクトの記述をサーバ５０２から取り出すことに向けられている。サーバ５０２は、ＳＥＳＳＩＯＮＤＥＳＣＲＩＰＴＩＯＮＰＲＯＴＯＣＯＬ（ＳＤＰ）中で表される要求されたリソースの記述で応答する。ＤＥＳＣＲＩＢＥ応答（ＳＤＰ）は、それが記述するリソースに関するすべてのメディア初期化情報を含む。

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

この時点で、クライアントはＰＬＡＹ要求を発行することができるが、このＰＬＡＹ要求は、ＳＥＴＵＰ中で指定された機構を介してデータ送信を開始するようサーバに伝える。ＰＬＡＹ要求の受信に応答して、サーバはコンテンツのストリーミングを開始することができ、コンテンツは、この例ではオーディオ／ビデオコンテンツである。当業者には理解されるであろうが、この例では、ストリーミングコンテンツは、ＲＴＰパケットを使用してカプセル化され、ＵＤＰを介して送信される。

ＲＴＳＰプロトコルは、ＰＡＵＳＥ、ＴＥＡＲＤＯＷＮ、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲ、ＲＥＤＩＲＥＣＴ、およびＲＥＣＯＲＤを含めて、他にも興味を引くメソッドを有する。ＲＴＳＰに関する追加の背景については、文献を参照されたい（例えば、非特許文献１参照。）。

（ＲＴＳＰを使用した例示的な実装形態）
以下の説明では、２つの主要なサブセクションが現れる。一方は「制御フロー」という題名であり、ＤＲＭ保護付きコンテンツのための制御フローが、ＲＴＳＰを使用してどのように確立されるかについて述べる。もう一方は「データフロー」という題名であり、ＤＲＭ保護付きコンテンツのためのデータフローが、ＲＴＰを使用してどのように確立されるかについて述べる。これらの主要なサブセクションはそれぞれ、発明的な実施形態の態様について述べるそれ自体の関連サブセクションを有する。

以下の説明では、前述のプロトコルのセッション確立プロシージャおよびデータ転送プロシージャが、一実施形態によりＲＴＳＰ／ＲＴＰを使用してどのように達成されるかについて述べる。より具体的には、以下の「制御フロー」セクションでは、セッション確立がＲＴＳＰを使用してどのように達成されるかについて述べる。「データフロー」セクションでは、データ転送がＲＴＰを使用してどのように達成されるかについて述べる。

（制御フロー）
この実施形態によれば、ＤＲＭ保護付きコンテンツ、すなわち関連するライセンスを有するコンテンツを再生したい受信側デバイスによって、セッション確立が開始される。上記のコンテンツセキュリティおよびライセンスプロトコルの説明から、クライアント／受信側はライセンス要求メッセージをサーバ／送信側に相応に送信することになり、サーバ／送信側はこれにライセンス応答メッセージで返信することになることを想起されたい。ライセンス応答メッセージは、ライセンスを搬送するが、このライセンスは、上の例では拡張可能メディア権利（eXtensible Media Rights）（ＸＭＲ）で表される。ライセンスは、要求されているコンテンツに関連するポリシーおよびコンテンツ鍵を含む。

（ＤＥＳＣＲＩＢＥ要求におけるライセンス要求メッセージの搬送）
次に、図６と共に、コンテンツセキュリティおよびライセンスプロトコルとＲＴＳＰとの合流を考えてみる。具体的には、図６には、一実施形態によるクライアント／受信側６００およびサーバ／送信側６０２を示す。この実施形態によれば、クライアント／受信側６００がＤＲＭ保護付きコンテンツにアクセスしたいとき、クライアントは、ＤＥＳＣＲＩＢＥ要求の本文にライセンス要求メッセージを挿入する。

実装例の１つに過ぎないが、一実施形態による、ライセンス要求メッセージを組み込んだ以下のＤＥＳＣＲＩＢＥ要求の抜粋を考えてみる。

この例では、サーバが特定タイプの送信側であると受信側が予想していることを示すために、「Require:com.microsoft.wmdrm-nd」が使用されている。この例では、ＤＥＳＣＲＩＢＥの本文がライセンス要求メッセージを含むことを示すために、「Content-Type:application/vnd.ms-wmdrm-license-request」が使用されている。

エラーがない限り、送信側は、すぐ下のセクションで述べるライセンス応答メッセージを含むＳＤＰ記述で返信すべきである。

（ＳＤＰ記述中へのライセンス応答メッセージの埋め込み）
ライセンス要求メッセージを本文に含むＤＥＳＣＲＩＢＥ要求を受信すると、サーバは、ライセンス応答メッセージを返すことができる。この例では、サーバは、前述の様々なパラメータを含むだけでなく、ライセンス応答メッセージをも含むＳＤＰ記述を返す。この実施形態では、ライセンス応答メッセージは、前に示したように、どのポリシーがこのコンテンツに適用されるかを指示するＸＭＲライセンスを搬送することになる。

実装例の１つに過ぎないが、一実施形態による、ライセンス応答メッセージを組み込んだ以下のＳＤＰの抜粋を考えてみる。

一実施形態によれば、送信側から返されるＳＤＰは、非特許文献２中の仕様に従ってデータＵＲＬに符号化されたライセンス応答メッセージを含む。データＵＲＬに含まれるデータは、この例では、Ｂａｓｅ６４符号化されなければならず、ＭＩＭＥタイプは「application/vnd.ms-wmdrm-license-response」に設定されなければならない。

この構文の一例として、以下を考えてみる。

データＵＲＬは、この例では、ＳＤＰ鍵管理拡張子（SDP key management extensions）の仕様（現時点では引き続き進行中の作業である）に従って、「a=key-mgmt」属性を使用してＳＤＰセッションレベルで挿入されなければならない。この構文は、以下のとおりである。

a=key-mgmt:wmdrm-nd URL
ＵＲＬパラメータは、上述したデータＵＲＬである。

（ＡＮＮＯＵＮＣＥ要求におけるライセンス応答メッセージの搬送）
次に、いくつかのメディアファイルが、異なるポリシーの施行を必要とする複数のセグメントを含むと考えてみる。ＴＶ録画のためにウィンドウズ（登録商標）メディアセンタエディション（Windows（登録商標） Media Center Edition）によって生成されたファイルの場合を例にとる。このようなファイルは、ＷＭＤＲＭによって保護され、複数のポリシーが関連する。例えば、ＴＶショーにはマクロビジョン（Macrovision）が必要とされるが、これと同じ録画内に現れるコマーシャルセグメントには必要とされない場合がある。

この要件の結果、ストリームの途中で更新済みポリシーを送達するための機構を定義することが必要になる。一実施形態によれば、更新済みポリシーは、ＲＴＳＰのＡＮＮＯＵＮＣＥ要求を使用してストリームの途中で送達することができる。この実施形態では、ＡＮＮＯＵＮＣＥ要求は、新しいＸＭＲライセンスを含むライセンス応答メッセージを搬送する。

この例では、ストリーミングメディアに関連するポリシーが変化するかもしれない２つの異なる場合がある。第１の場合では、特定のストリームに関連するポリシーのみが変化することがある。第２の場合では、ポリシーとコンテンツフォーマット自体との両方が変化する可能性がある。

ストリーミングメディアに関連するポリシーのみが変化する第１の場合を考えてみる。この場合の一例は、ＴＶショーのセグメントとコマーシャルとの間の切替えであろう。ここで、ＴＶセグメントでは、マクロビジョンがアナログ出力に対してイネーブルにされる必要があるが、コマーシャルではその必要はない。この例では、ポリシーのみが変化し、ビットレートやコーデックなどの符号化パラメータは同じままであることに留意されたい。

ポリシーとコンテンツフォーマットとの両方が変化する第２の場合を考えてみる。この場合の一例もまた、ＴＶショーのセグメントとコマーシャルとの間の切替えであろう。ここで、ポリシーについては同じタイプの変化がある。しかしこの例では、ＴＶショーとコマーシャルは、高精細度符号化から標準精細度符号化への移行など、異なる符号化パラメータを使用して符号化される。このようなシナリオは一般に「フォーマット変更」と呼ばれる。この場合の別の例は、「エントリ変更」として一般に知られるものに関係する。エントリ変更は通常、「サーバ側プレイリスト」の一部としてサーバによって送達されているメディアファイル中の切替えの結果である。これらのプレイリストは、どんな符号化パラメータやポリシーも共有するとは限らないメディアファイルの集まりで構成される場合がある。

第１の場合で例示したように、ポリシーは変化するがフォーマットは変化しないときはいつでも、サーバは、新しいポリシーのみをＡＮＮＯＵＮＣＥ要求の本文の一部としてクライアントに送信する。この場合、ＡＮＮＯＵＮＣＥメッセージの本文にライセンス応答メッセージが含まれる。例として図７を考えてみるが、図７には、例示的なクライアント／受信側７００およびサーバ／送信側７０２が示してあり、サーバ／送信側７０２は、新しいライセンスを更新済みポリシーと結び付けるために、ＡＮＮＯＵＮＣＥ要求をクライアント／受信側に発行している。

第２の場合で例示したように、ポリシーが変化してフォーマットもまた変化するときはいつでも、サーバは、更新済みＳＤＰ記述をクライアントに送達する。このＳＤＰ記述は、行われたフォーマット変更を記述するのに必要とされる。この例では、フォーマット変更の場合のＳＤＰ記述もまた、ＡＮＮＯＵＮＣＥ要求として送達される。したがって、一方がフォーマット変更を含み、もう一方がポリシー変更を含む、２つの連続したＡＮＮＯＵＮＣＥ要求を送達する代わりに、サーバは、ＳＤＰ記述を搬送する１つのＡＮＮＯＵＮＣＥ要求のみを送信すればよい。この場合、ポリシー変更は、ＳＤＰ記述に埋め込まれたライセンス応答メッセージとして通信される。再び図７を考えてみると、図７には、ライセンス応答メッセージが埋め込まれた更新済みＳＤＰを本文に含むＡＮＮＯＵＮＣＥ要求が示してある。

ＡＮＮＯＵＮＣＥ要求の一部であるＳＤＰ記述にライセンス応答メッセージを埋め込むためのフォーマットは、ＤＥＳＣＲＩＢＥ応答の一部であるＳＤＰ記述を埋め込むための前述のフォーマットと同じである。

図８は、一実施形態による方法のステップを記述した流れ図である。この方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはこれらの組合せと共に実施することができる。一実施形態では、この方法は、何らかのタイプのコンピュータ可読媒体上に組み入れられた１組のコンピュータ可読命令またはソフトウェアコードとして実施される。

ステップ８００で、ストリーミングプロトコルを介して、ＤＲＭ保護付きコンテンツのためのライセンスを求める要求を送信することによって、制御フローの確立を試みる。図示および記述する実施形態では、このステップはクライアント／受信側によって実行される。ライセンスを求める要求の具体的な一例は、前述のライセンス要求メッセージである。特許請求する主題の趣旨および範囲を逸脱することなく、他の要求タイプまたはフォーマットを利用することもできる。加えて、ストリーミングプロトコルの一例（すなわちＲＴＳＰ）も上述してある。特許請求する主題の趣旨および範囲を逸脱することなく、他のストリーミングプロトコルを使用することもできる。ＲＴＳＰ実施形態では、要求はＤＥＳＣＲＩＢＥ要求の本文に挿入される。

ステップ８０２で、ライセンスを求める要求を受信することによって、制御フローの確立を試みる。このステップは、この例ではサーバ／送信側によって実施される。要求を受信するのに応答して、ステップ８０４で、ストリーミングプロトコルを使用してライセンスをクライアント／受信側に送信することができる。ライセンスがクライアント／受信側に返される場合の具体的な一例は、ライセンスがライセンス応答メッセージの形でクライアント／受信側に送信される場合として上に提供してある。特許請求する主題の趣旨および範囲を逸脱することなく、他の応答タイプまたはフォーマットを利用することもできる。加えて、ストリーミングプロトコルの一例（すなわちＲＴＳＰ）も上述してある。特許請求する主題の趣旨および範囲を逸脱することなく、他のストリーミングプロトコルを使用することもできる。ＲＴＳＰ実施形態では、応答はＳＤＰで送信される。

ステップ８０４はまた、更新をクライアント／受信側に送信するために実施することもできることを認識および理解されたい。この場合では、かつＲＴＳＰ実施例のコンテキストでは、更新は、前述のようにＡＮＮＯＵＮＣＥ要求を使用して送達することができる。

ステップ８０６で、ストリーミングプロトコルを介してライセンスを受信する。図示および記述する実施形態では、このステップはクライアント／受信側によって実施される。ライセンスの受信後、クライアントは、ライセンスに定義された条件に従って、コンテンツにアクセスしてコンテンツを消費することができる。

ライセンス獲得プロセスに続くデータフローについて、以下に述べる。

（データフロー）
ＲＴＳＰをＤＲＭ保護付きコンテンツと共に利用する制御フローの例示的な実施形態について述べたが、次に、実際のＤＲＭ保護付きコンテンツの通信を含むかまたは可能にするデータフローを考えてみる。

以下に述べる実施形態では、ＲＴＰをデータ転送プロトコルとして使用して、ＤＲＭ保護付きコンテンツが送信側と受信側との間で通信される。すなわち、ＤＲＭ保護付きコンテンツは、送信側から通信され、受信側に通信される。

提供する特定の例では、２つの異なる手法について述べる。第１の手法では、利用されるＲＴＰペイロードフォーマットは拡張子をサポートし、拡張子は、暗号化済みペイロードデータが復号プロセスを経て復号されることができるように、鍵ＩＤ拡張子や初期化ベクトルなどの暗号化パラメータをＲＴＰパケットに含めることを可能にする。第２の手法では、ＲＴＰペイロードフォーマットは拡張子をサポートしない。したがってこの手法では、記述子が定義され、記述子は、暗号化済みペイロードを含むＲＴＰパケットに関連付けられる。記述子は、暗号化済みペイロードデータを復号するために復号プロセスで使用することのできる鍵ＩＤ拡張子や初期化ベクトルなどの暗号化パラメータを含む。

（ウィンドウズ（登録商標）メディアペイロードフォーマットを介したサンプル暗号化済みペイロードの搬送）
図９に、一実施形態によるＲＴＰパケットの例示的な各部分を、９００において一般に示す。この実施形態では、利用されるＲＴＰペイロードフォーマットは、暗号化済みペイロードコンテンツと共に鍵ＩＤ拡張子や初期化ベクトルなどの暗号化パラメータをＲＴＰパケットに含めることができるようにして、拡張子をサポートする。このようなフォーマットの一例は、ウィンドウズ（登録商標）メディアＲＴＰペイロード（Windows（登録商標） Media RTP Payload）フォーマットであり、これは非特許文献３で述べられている。しかし、特許請求する主題の趣旨および範囲を逸脱することなく、他のフォーマットを利用することもできる。

パケット９００は、この例では、ＲＴＰヘッダ９０２およびペイロードフォーマットヘッダ９０４を含む。ペイロードフォーマットヘッダは、この例では、拡張子を可能にする。したがって、パケット９００はさらに、暗号化済みペイロードデータ９１０（オーディオデータまたはビデオデータ）と共に、鍵ＩＤ拡張子９０６および初期化ベクトル９０８を含み、暗号化済みペイロードデータ９１０は、鍵ＩＤ拡張子９０６および初期化ベクトル９０８に関連付けられており、これらを使用して復号することができる。さらに、ＲＴＰパケット９００は、他の複数の暗号化済みペイロードを含むこともできる。この特定の例では、パケット９００はさらに、暗号化済みペイロードデータ９１０ａ（オーディオデータまたはビデオデータ）と共に、別のペイロードフォーマットヘッダ９０４ａ、鍵ＩＤ拡張子９０６ａ、初期化ベクトル９０８ａを含み、暗号化済みペイロードデータ９１０ａは、鍵ＩＤ拡張子９０６ａおよび初期化ベクトル９０８ａに関連付けられており、これらを使用して復号することができる。

この特定の実施形態では、１つのＲＴＰパケットが、複数の異なる暗号化済みペイロードを含むことができる。具体的なコンテキストの１つにおける具体的な一実装例として、ウィンドウズ（登録商標）メディアオーディオビデオコンテンツ（Windows（登録商標） Media Audio and Video Content）に関して以下を考えてみる。

前述のようにライセンスで保護されたウィンドウズ（登録商標）メディアコンテンツを搬送するとき、ＲＴＰパケット中では、以下の値およびフィールドが設定されなければならない。

１．「ＭＡＵプロパティ」セクションのビットフィールド２中の「暗号化」ビット（Ｅ）は１に設定されなければならない。

２．拡張子フィールドがあることを示すために「ＭＡＵタイミング」セクション中の「拡張子存在」ビット（Ｘ）は１にセットされなければならない。

３．「暗号化済みペイロード境界」拡張子があってはならない。

４．「ＷＭＤＲＭ初期化ベクトル」拡張子が含まれなければならない。以下の値が設定されなければならない。
ａ．「拡張子タイプ」は２に設定されなければならない。
ｂ．「拡張子長さ」は８に設定されなければならない（６４ビットを意味する）。
ｃ．「拡張子データ」は、以下の「サンプル暗号化」という題名のセクションで定義するサンプルＩＤ値に設定されなければならない。
ｄ．この拡張子は、あらゆるＭＡＵの第１のペイロードに対して含まれなければならない。ＭＡＵが複数のペイロードに断片化されている場合、この拡張子は第１のペイロード中のみにあるべきである。

５．「ＷＭＤＲＭ鍵ＩＤ」拡張子が含まれなければならない。以下の値が設定されなければならない。
ａ．「拡張子タイプ」は３に設定されなければならない。
ｂ．「拡張子長さ」は１６に設定されなければならない（１２８ビットを意味する）。
ｃ．「拡張子データ」は、ＡＳＦコンテンツを搬送するときのＡＳＦコンテンツ暗号化オブジェクトからの鍵ＩＤ値に設定されなければならない。あるいは、ＤＶＲ−ＭＳなどの非ＡＳＦコンテンツを搬送するときに使用される暗号化鍵を表す鍵ＩＤ値に設定される。
ｄ．この拡張子は、パケット損失の問題に対処するために、複数ペイロードを含むＲＴＰパケットそれぞれの中の、第１のペイロードに対して含まれなければならない。

（サンプル暗号化）
上の項目４（ｃ）のさらなる説明として、以下を考えてみる。この実施形態では、カウンタモードのＡＥＳを使用して各サンプルを暗号化すべきである。図１０に、この技法を使用して単一のサンプルを暗号化するためのプロセスを示す。

この実施形態では、カウンタモードがバイトのストリームを生み出し、次いでこれらのバイトは、メディアサンプルの平文テキストバイトと排他的論理和がとられて、暗号化済みメディアサンプルが生み出される。鍵ストリームジェネレータが、ＡＥＳラウンドを使用して、一度に１６バイトブロックの鍵ストリームを生成する。ＡＥＳラウンドへの入力は、コンテンツ暗号化鍵（Ｋｃ）、および、サンプルＩＤとサンプル内のブロック番号との１２８ビット連結である。

鍵ストリームジェネレータの出力は、メディアサンプルの対応するブロック（ｉ）からのデータと、バイトごとに排他的論理和がとられるべきである。メディアサンプルが１６バイトで均等に分割可能でない場合は、最後のブロックからのメディアデータの有効バイトのみが、鍵ストリームと排他的論理和がとられて、暗号化済みサンプルに対して保持されるべきである。

ＡＳＦファイルからサンプルを暗号化するときは、サンプルＩＤは、ペイロード拡張子からのサンプルＩＤと等価である。

したがって、この実施形態では、データは「サンプル」境界に従って暗号化および復号され、「サンプル」境界は、所与のメディアタイプの自然な境界である。例えば、ビデオストリームの場合はビデオフレームであり、あるいはオーディオストリームの場合はオーディオサンプルのブロックである。

（データセグメント記述子を使用するＲＴＰペイロードフォーマットを介したリンク暗号化済みペイロードの搬送）
図１１に、別の実施形態によるパケットの態様を、１１００において一般に示す。この例では、パケット１１００は、ＩＰヘッダ１１０２、ＵＤＰヘッダ１１０４、ＲＴＰヘッダ１１０６、ペイロードフォーマットヘッダ１１０８、ペイロードデータ１１１０、および記述子１１１２を含むことができる。この特定の例では、記述子はペイロードデータの最後に付加されているが、記述子は任意の適切な位置に配置することができる。当業者には理解されるであろうが、記述子をペイロードデータの最後に配置することで、後方互換性問題を緩和することができる。

この実施形態では、ＲＴＰヘッダを除くＲＴＰパケットは、記述子１１１２に関連するデータセグメントとして扱われる。記述子１１１２は、ペイロードデータ１１１０の復号を可能にする復号プロセスで使用することのできる暗号化パラメータを伴う。この特定の例では、単一のポリシーおよびコンテンツ暗号化鍵が、ペイロードデータ１１１０に適用される。

一実施形態によれば、記述子１１１２は、以下のデータ構造を備える。

この例で、フラグセクションは、データの属性を示すビットフィールドである。現在、次の値が定義されている。すなわち、０×０１は、暗号化済みデータを示す。このフラグが設定されているとき、これは、データが暗号化された形であることを示す。そうでないときは、データは平文である。

拡張子セクションに関しては、拡張子数フィールドは、この記述子に含まれる可変長の拡張子の数を示す。可変長拡張子フィールドに関しては、各拡張子が以下のフォーマットを有する。

一実施形態によれば、鍵ＩＤ拡張子およびデータセグメントＩＤ拡張子が、以下のように定義される。

（鍵ＩＤ拡張子）
拡張子タイプ：鍵ＩＤ拡張子について０×０１に設定されなければならない。
拡張子長さ：１２８ビット（１６バイト）を表す１６に設定されなければならない。
拡張子：この記述子と共に送達される暗号化済みメディアについての鍵ＩＤ値を含まなければならない。この拡張子は、暗号化済みデータフラグが設定されているときにのみ使用される。

（データセグメントＩＤ拡張子）
拡張子タイプ：データセグメントＩＤ拡張子について０×０２に設定されなければならない。
拡張子長さ：６４ビット（８バイト）を表す８に設定されなければならない。
拡張子：この記述子と共に送達される暗号化済みメディアについてのデータセグメントＩＤを含まなければならない。この拡張子は、暗号化済みデータフラグが設定されているときにのみ使用される。

長さセクションに関しては、この実施形態では、このセクションはデータセグメント記述子の長さの総計をバイトで含まなければならない。この長さは、この記述子と共に送達されるメディアデータのサイズは含まない。

（結び）
上述した様々な実施形態は、ディジタル著作権管理（ＤＲＭ）などのコンテンツ保護方法を利用して、ホームメディアネットワークなどのローカルネットワーク内のマシンおよびデバイス上での安全なコンテンツ再生を可能にする。少なくともいくつかの実施形態では、メッセージおよびコンテンツはリアルタイムストリーミングプロトコル（ＲＴＳＰ）およびリアルタイムトランスポートプロトコル（ＲＴＰ）を介して送達され、また、ＲＴＳＰ／ＲＴＰによってもたらされる利点を享受するプロトコル拡張子が導入されるが、これらの利点には、ユーザデータグラムプロトコル（ＵＤＰ）を介したデータ送達、および、クライアントとサーバとの間の双方向通信が含まれる。

構造上の特徴および／または方法上のステップに特有の言葉で本発明を述べたが、添付の特許請求の範囲に定義する本発明は、上述した特定の特徴またはステップに必ずしも限定されないことを理解されたい。これらの特定の特徴およびステップは、特許請求する本発明を実施する好ましい形として開示する。

本発明の一実施形態によるプロトコルの例示的な登録プロシージャを示す図である。本発明の一実施形態によるプロトコルの例示的な近接検出プロシージャを示す図である。本発明の一実施形態によるプロトコルの例示的なセッション確立プロシージャを示す図である。本発明の一実施形態によるプロトコルの例示的なデータ転送プロシージャを示す図である。本発明の一実施形態によるストリーミングプロトコルの態様を示す図である。本発明の一実施形態に関して利用される図５のストリーミングプロトコルを示す図である。本発明の一実施形態に関して利用される図５のストリーミングプロトコルを示す図である。本発明の一実施形態による方法のステップを記述した流れ図である。本発明の一実施形態によるパケットを示す図である。本発明の一実施形態によるサンプル暗号化を示す図である。本発明の一実施形態によるパケットを示す図である。

Claims

コンピュータによって実施される方法であって、
ストリーミング用制御プロトコルを使用して、保護付きコンテンツを交換するための制御フローの確立を試みること、および、
データフローを使用して保護付きコンテンツの通信を可能にすることを含み、前記データフローはトランスポートプロトコルを使用することを特徴とする方法。
制御フローの確立を試みる前記動作は、
前記保護付きコンテンツを送信するように構成された送信側にライセンス要求メッセージを送信すること、および、
ライセンスを含むライセンス応答メッセージを前記送信側から受信することを含むことを特徴とする請求項１に記載の方法。
制御フローの確立を試みる前記動作は、
前記保護付きコンテンツを再生するように構成された受信側からライセンス要求メッセージを受信すること、および、
ライセンスを含むライセンス応答メッセージを前記受信側に送信することを含むことを特徴とする請求項１に記載の方法。
制御フローの確立を試みる前記動作は、ＲＴＳＰを使用して達成されることを特徴とする請求項１に記載の方法。
制御フローの確立を試みる前記動作は、
ＲＴＳＰＤＥＳＣＲＩＢＥ要求の本文中でライセンス要求メッセージを送信側に送信すること、および、
ライセンスを含むライセンス応答メッセージを含むＲＴＳＰＳＥＳＳＩＯＮＤＥＳＣＲＩＰＴＩＯＮＰＲＯＴＯＣＯＬ（ＳＤＰ）を前記送信側から受信することをさらに含むことを特徴とする請求項４に記載の方法。
制御フローの確立を試みる前記動作は、
ＲＴＳＰＤＥＳＣＲＩＢＥ要求の本文中でライセンス要求メッセージを受信側から受信すること、および、
ライセンスを含むライセンス応答メッセージを含むＲＴＳＰＳＥＳＳＩＯＮＤＥＳＣＲＩＰＴＩＯＮＰＲＯＴＯＣＯＬ（ＳＤＰ）を前記受信側に送信することをさらに含むことを特徴とする請求項４に記載の方法。
保護付きコンテンツの通信を可能にする前記動作は、ＲＴＰを使用して達成されることを特徴とする請求項１に記載の方法。
前記保護付きコンテンツのストリーミング中に前記保護付きコンテンツに関連するポリシーまたはフォーマット情報を更新することをさらに含むことを特徴とする請求項１に記載の方法。
前記保護付きコンテンツに関連するポリシーまたはフォーマット情報を更新する前記動作は、前記ストリーミング用制御プロトコルを介して更新を送信することを含むことを特徴とする請求項８に記載の方法。
前記ストリーミング用制御プロトコルはＲＴＳＰを含み、前記更新はＲＴＳＰＡＮＮＯＵＮＣＥ要求を介して送信されることを特徴とする請求項９に記載の方法。
前記保護付きコンテンツに関連するポリシーまたはフォーマット情報を更新する前記動作は、前記ストリーミング用制御プロトコルを介して更新を受信することを含むことを特徴とする請求項８に記載の方法。
前記ストリーミング用制御プロトコルはＲＴＳＰを含み、前記更新はＲＴＳＰＡＮＮＯＵＮＣＥ要求を介して受信されることを特徴とする請求項１１に記載の方法。
コンピュータによって実施される方法であって、
ＲＴＳＰを使用して、保護付きコンテンツを交換するための制御フローを確立すること、および、
データフローを使用して保護付きコンテンツの通信を可能にすることを含み、保護付きコンテンツはＲＴＰを使用してカプセル化されることを特徴とする方法。
保護付きコンテンツの通信を可能にする前記動作は、暗号化された保護付きコンテンツを含むＲＴＰパケット中に、前記暗号化された保護付きコンテンツを復号するために復号プロセスで利用することのできる暗号化パラメータを含めることを含むことを特徴とする請求項１３に記載の方法。
前記ＲＴＰパケットは、複数の異なる暗号化済みペイロードを含むことができることを特徴とする請求項１４に記載の方法。
前記暗号化パラメータは、各暗号化済みペイロードにつき鍵ＩＤ拡張子および初期化ベクトルを含むことを特徴とする請求項１５に記載の方法。
保護付きコンテンツの通信を可能にする前記動作は、
暗号化された保護付きコンテンツを復号するために復号プロセスで利用することのできる暗号化パラメータを含む記述子を定義すること、および、
前記記述子を前記保護付きコンテンツに関連付けることを含むことを特徴とする請求項１３に記載の方法。
前記記述子を前記保護付きコンテンツに関連付ける前記動作は、前記記述子を前記ＲＴＰパケットの最後に付加することを含むことを特徴とする請求項１７に記載の方法。
前記暗号化された保護付きコンテンツは、前記記述子によって参照される単一の鍵を使用して復号することができることを特徴とする請求項１７に記載の方法。
保護付きコンテンツの通信を可能にする前記動作は、
ＲＴＳＰＤＥＳＣＲＩＢＥ要求の本文中でライセンス要求メッセージを送信側に送信すること、
前記ＲＴＳＰＤＥＳＣＲＩＢＥ要求の本文中で前記ライセンス要求メッセージを受信側から受信すること、
ライセンスを含むライセンス応答メッセージを含むＲＴＳＰＳＥＳＳＩＯＮＤＥＳＣＲＩＰＴＩＯＮＰＲＯＴＯＣＯＬ（ＳＤＰ）を前記受信側に送信すること、および、
前記ライセンスを含む前記ライセンス応答メッセージを含む前記ＲＴＳＰＳＥＳＳＩＯＮＤＥＳＣＲＩＰＴＩＯＮＰＲＯＴＯＣＯＬ（ＳＤＰ）を前記送信側から受信することをさらに含むことを特徴とする請求項１３に記載の方法。