(57)【要約】【課題】移動元と移動先とでの同時存在を禁止する著作権保護機構によって保護されたコンテンツの移動を確実に行うことを可能とするコンテンツ送信装置を提供する。【解決手段】クライアント装置１は、著作権保護されたコンテンツをサーバ装置２にＭＯＶＥする場合、まず、コンテンツの暗号化および復号に用いる暗号鍵を交換する鍵交換で相手側が必要とする自装置の情報を送信する（４）。また、クライアント装置１は、この鍵交換が完了するまでの間、格納されたデータが暗号化されており、かつ、そのデータサイズが零である旨の設定がなされたパケットを送信し（５）、鍵交換が完了した後に、コンテンツを暗号化した暗号データを格納させたパケットの送信を開始する（８）。【選択図】      図２
2006339900.tif 000002
【特許請求の範囲】
【請求項１】
移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置に送信するコンテンツ送信装置において、
前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換手段と、
前記鍵交換手段により実行される鍵交換で相手側が必要とする自装置の情報を前記他の装置に送信する第１の制御手段と、
前記第１の制御手段による自装置の情報の送信後、前記鍵交換手段による鍵交換が完了するまでの間、格納されたデータが暗号化されており、かつ、そのデータサイズが零である旨の設定がなされたパケットを前記他の機器に送信する第２の制御手段と、
前記鍵交換手段による鍵交換が完了した後に、前記コンテンツを暗号化した暗号データを格納させたパケットの前記他の機器に対する送信を開始する第３の制御手段と
を具備することを特徴とするコンテンツ送信装置。
【請求項２】
ネットワークインフラストラクチャとしてＩＰ（Internet protocol）、前記コンテンツの伝送プロトコルとしてＨＴＴＰ（hypertext transfer protocol）がそれぞれ用いられ、
前記第１の制御手段は、ポート番号およびホストアドレスを含むＨＴＴＰヘッダを前記他の装置に送信することを特徴とする請求項１記載のコンテンツ送信装置。
【請求項３】
前記第１の送信手段は、さらにデバイスＩＤを含むＨＴＴＰヘッダを前記他の装置に送信することを特徴とする請求項２記載のコンテンツ送信装置。
【請求項４】
前記コンテンツの伝送プロトコルとしてＨＴＴＰが用いられ、
前記第２の制御手段は、そのサイズを零としたＰＣＰ（protect content packet）のみを含むＨＴＴＰボディを前記他の装置に送信することを特徴とする請求項１記載のコンテンツ送信装置。
【請求項５】
移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置から受信するコンテンツ受信装置において、
前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換手段と、
前記コンテンツを格納するためのリソース確保を前記他の機器から要求された際に、前記鍵交換を前記鍵交換手段に開始させる第１の制御手段と、
前記鍵交換手段による鍵交換が完了した後に、前記要求されたリソース確保を実行し、その結果通知を前記他の機器に返信する第２の制御手段と
を具備することを特徴とするコンテンツ受信装置。
【請求項６】
前記第１の制御手段は、前記他の機器との間で鍵交換を行う必要があるか否かを判断する手段を有し、
前記第２の制御手段は、前記第１の制御手段が鍵交換を不要と判断した場合には、前記要求されたリソース確保を即時的に実行することを特徴とする請求項５記載のコンテンツ受信装置。
【請求項７】
ネットワークインフラストラクチャとしてＩＰが用いられ、
前記第１の制御手段は、前記他の装置のＩＰアドレスに基づき、当該他の装置との間の鍵交換の要否を判断することを特徴とする請求項６記載のコンテンツ受信装置。
【請求項８】
前記第１の制御手段は、前記他の装置のデバイスＩＤに基づき、当該他の装置との間の鍵交換の要否を判断することを特徴とする請求項６記載のコンテンツ受信装置。
【請求項９】
移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置から受信するコンテンツ受信装置において、
前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換手段と、
前記コンテンツを暗号化した暗号データの受信開始時、前記鍵交換手段による鍵交換に必要な前記他の装置の情報が格納された領域部分のみを読み出す第１の制御手段と、
前記第１の制御手段により読み出された領域部分に格納された前記他の装置の情報を用いた鍵交換を前記鍵交換手段に開始させる第２の制御手段と、
前記鍵交換手段による鍵交換が完了した後に、前記コンテンツを暗号化した暗号データが格納された領域部分の読み出しを開始する第３の制御手段と
を具備することを特徴とするコンテンツ受信装置。
【請求項１０】
前記コンテンツの伝送プロトコルとしてＨＴＴＰが用いられ、
前記第１の制御手段は、ＨＴＴＰヘッダのみを前記他の装置の情報が格納された領域部分として読み出し、
前記第３の制御手段は、ＨＴＴＰボディを前記コンテンツを暗号化した暗号データが格納された領域部分としてその内部に含まれるＰＣＰを順次に読み出していく
ことを特徴とする請求項９記載のコンテンツ受信装置。
【請求項１１】
前記第２の制御手段は、前記他の機器との間で鍵交換を行う必要があるか否かを判断する手段を有し、
前記第３の制御手段は、前記第２の制御手段が鍵交換を不要と判断した場合には、前記ＨＴＴＰボディ内部に含まれるＰＣＰの読み出しを即時的に開始することを特徴とする請求項９記載のコンテンツ受信装置。
【請求項１２】
ネットワークインフラストラクチャとしてＩＰが用いられ、
前記第２の制御手段は、前記他の装置のＩＰアドレスに基づき、当該他の装置との間の鍵交換の要否を判断することを特徴とする請求項１１記載のコンテンツ受信装置。
【請求項１３】
前記第２の制御手段は、前記他の装置のデバイスＩＤに基づき、当該他の装置との間の鍵交換の要否を判断することを特徴とする請求項１１記載のコンテンツ受信装置。
【請求項１４】
移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置に送信するコンテンツ送信装置のコンテンツ送信方法において、
前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換するために相手側が必要とする自装置の情報を前記他の装置に送信し、
前記自装置の情報の送信後、前記鍵交換が完了するまでの間、格納されたデータが暗号化されており、かつ、そのデータサイズが零である旨の設定がなされたパケットを前記他の機器に送信し、
前記鍵交換が完了した後に、前記コンテンツを暗号化した暗号データを格納させたパケットの前記他の機器に対する送信を開始する
ことを特徴とするコンテンツ送信装置のコンテンツ送信方法。
【請求項１５】
移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置から受信するコンテンツ受信装置のコンテンツ受信方法において、
前記コンテンツを格納するためのリソース確保を前記他の機器から要求された場合、前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換を開始し、
前記鍵交換が完了した後に、前記要求されたリソース確保を実行し、その結果通知を前記他の機器に返信する
ことを特徴とするコンテンツ受信装置のコンテンツ受信方法。
【請求項１６】
移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置から受信するコンテンツ受信装置のコンテンツ受信方法において、
前記コンテンツを暗号化した暗号データの受信開始時、前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換に必要な前記他の装置の情報が格納された領域部分のみを読み出し、
前記読み出した領域部分に格納された前記他の装置の情報を用いた鍵交換を開始し、
前記鍵交換が完了した後に、前記コンテンツを暗号化した暗号データが格納された領域部分の読み出しを開始する
ことを特徴とするコンテンツ受信装置のコンテンツ受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、例えば２台のＨＤＤ（hard disc drive）レコーダ間におけるコピーワンス番組の録画データの移動等を確実に行うためのコンテンツ送受信技術に関する。
【背景技術】
【０００２】
ネットワークインフラストラクチャとしてＩＰを用いた環境において、制御プロトコルとしてＵＰｎＰ  ＡＶ、コンテンツ伝送プロトコルとしてＨＴＴＰを用いる場合、著作権保護機構としてＤＴＣＰ−ＩＰが用いられる（例えば特許文献１等参照）。
【０００３】
ＵＰｎＰデバイスに対するコンテンツ伝送を実行する場合、送信側は、コンテンツ伝送前に当該ＵＰｎＰデバイス上のリソース確保を行い、その後に、コンテンツを暗号化した暗号データの送信を開始する。また、受信側で暗号を解くために、送信側と受信側との間における機器認証および鍵交換（ＡＫＥ）がコンテンツ送出前に行われる。
【０００４】
さらに、このＤＴＣＰ−ＩＰによって保護されたコンテンツを移動（ＭＯＶＥ）する場合、ＭＯＶＥ元とＭＯＶＥ先との双方での同時存在が禁止されていることから、ＭＯＶＥ元は、ＭＯＶＥ先へ送出した部分を消しながら、または、読み出し不可能としながらコンテンツの送出を行わなければならない（例えば特許文献２等参照）。
【特許文献１】特開２００４−１０４７５２号公報
【特許文献２】特開２００３−１０１５２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
したがって、（移動元と移動先との双方での同時存在を禁止する）ＤＴＣＰ−ＩＰによって保護されたコンテンツを移動する際には、受信側で確実に記録ができないと、コンテンツが消去されてしまうことになる。
【０００６】
ところで、ＡＫＥの開始タイミングに関しては、ＤＴＬＡでは特段定めてはいない。したがって、クライアント装置からのコンテンツ転送を受け付けるサーバ装置がどのようなタイミングでＡＫＥを開始するかは実装依存となっている。つまり、コンテンツが暗号化されているかどうかを判断した後にＡＫＥを行うといった実装でも良いわけである。
【０００７】
このような実装においては、ＨＴＴＰボディ内のＰＣＰ（protect content packet)ヘッダのＥ−ＥＭＩを基に暗号化有無の判断が行われることになる。よって、この実装のサーバ装置との間でＡＫＥを行うためには、クライアント装置は、ＨＴＴＰボディを送信しなければならない。
【０００８】
しかしながら、ＭＯＶＥを行う場合、ＡＫＥ完了前に、暗号化したコンテンツ本体をＨＴＴＰボディに格納して送信してしまうと、ＡＫＥ処理中はコンテンツの暗号化が解けずに、（送信元で消去済みの）一部のコンテンツが失われてしまうことになる。
【０００９】
このような事態に対処するために、受信側のＵＰｎＰデバイスに対してリソース確保が要求された際、この要求を受けた受信側がＡＫＥを開始し、その後に、ＨＴＴＰ  ＰＯＳＴによってコンテンツの伝送を行うという方法が考えられる。しかしながら、この方法であっても、リソース確保直後にコンテンツの送信が行われてしまうと、ＡＫＥを実行していないため暗号が解けないコンテンツが発生し、移動後のコンテンツの一部が再生できなくなってしまうという問題を生じさせる。また、この方法では、このＡＫＥに失敗してしまった場合には、送信側では、確保した受信側のＵＰｎＰデバイスのリソースを削除する手間が生じ、一方、受信側では、一時的に無駄なリソースが残るという問題があった。
【００１０】
この発明は、このような事情を考慮してなされたものであり、移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツの移動を確実に行うことを可能とするコンテンツ送信装置、コンテンツ受信装置、コンテンツ送信方法およびコンテンツ受信方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
前述した目的を達成するために、この発明のコンテンツ送信装置は、移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置に送信するコンテンツ送信装置において、前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換手段と、前記鍵交換手段により実行される鍵交換で相手側が必要とする自装置の情報を前記他の装置に送信する第１の制御手段と、前記第１の制御手段による自装置の情報の送信後、前記鍵交換手段による鍵交換が完了するまでの間、格納されたデータが暗号化されており、かつ、そのデータサイズが零である旨の設定がなされたパケットを前記他の機器に送信する第２の制御手段と、前記鍵交換手段による鍵交換が完了した後に、前記コンテンツを暗号化した暗号データを格納させたパケットの前記他の機器に対する送信を開始する第３の制御手段とを具備することを特徴とする。
【００１２】
また、この発明のコンテンツ受信装置は、移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置から受信するコンテンツ受信装置において、前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換手段と、前記コンテンツを格納するためのリソース確保を前記他の機器から要求された際に、前記鍵交換を前記鍵交換手段に開始させる第１の制御手段と、前記鍵交換手段による鍵交換が完了した後に、前記コンテンツを格納するためのリソース確保を実行し、その結果通知を前記他の機器に返信する第２の制御手段とを具備することを特徴とする。
【００１３】
また、この発明のコンテンツ受信装置は、移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置から受信するコンテンツ受信装置において、前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換手段と、前記コンテンツを暗号化した暗号データの受信開始時、前記鍵交換手段による鍵交換に必要な前記他の装置の情報が格納された領域部分のみを読み出す第１の制御手段と、前記第１の制御手段により読み出された領域部分に格納された前記他の装置の情報を用いた鍵交換を前記鍵交換手段に開始させる第２の制御手段と、前記鍵交換手段による鍵交換が完了した後に、前記コンテンツを暗号化した暗号データが格納された領域部分の読み出しを開始する第３の制御手段とを具備することを特徴とする。
【発明の効果】
【００１４】
この発明によれば、移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツの移動を確実に行うことを可能とする。
【発明を実施するための最良の形態】
【００１５】
以下、図面を参照してこの発明の実施形態を説明する。図１は、本実施形態に係るコンテンツ送受信システムの概略ブロック図である。このコンテンツ送受信システムは、クライアント装置１とサーバ装置２とがネットワーク３を介して接続される。
【００１６】
クライアント装置１は、著作権保護コンテンツ送信制御部１０１、送信側ＡＫＥ完了機器管理部１０２、ＵＰｎＰ Media Server Control Point処理部１０３、送信側ＡＫＥ処理部１０４、ＨＴＴＰクライアントＰＯＳＴメソッド処理部１０５、ＤＴＣＰ暗号処理部１０６、クライアントコンテンツ蓄積部１０７、コンテンツ送信管理部１０８およびＴＣＰ／ＩＰネットワークＩ／Ｆ処理部１０９で構成される。
【００１７】
著作権保護コンテンツ送信制御部１０１は、著作権保護コンテンツをサーバ装置２に移動（ＭＯＶＥ）するためのシステム制御を実行する。送信側ＡＫＥ完了機器管理部１０２は、鍵交換（ＡＫＥ）を行った機器の情報を記憶する。ＵＰｎＰ Media Server Control Point処理部１０３は、サーバ装置２の後述するＵＰｎＰ Media Server Device処理部２０３に対する制御指示を実行する。
【００１８】
送信側ＡＫＥ処理部１０４は、送信側のＡＫＥ処理を実行する。ＨＴＴＰクライアントＰＯＳＴメソッド処理部１０５は、ＨＴＴＰ  ＰＯＳＴメソッドのクライアントに関する処理を行い、コンテンツをサーバ装置２に送信する。ＤＴＣＰ暗号処理部１０６は、著作権保護コンテンツをＤＴＣＰで定めた暗号化手法により暗号化する。
【００１９】
クライアントコンテンツ蓄積部１０７は、著作権保護コンテンツを記録蓄積する。コンテンツ送信管理部１０８は、ユーザからの指示を受け付けて、コンテンツの移動処理を開始する。そして、ＴＣＰ／ＩＰネットワークＩ／Ｆ処理部１０９は、ＵＰｎＰ Media Server Control Point処理部１０３、送信側ＡＫＥ処理部１０４およびＨＴＴＰクライアントＰＯＳＴメソッド処理部１０５からのＴＣＰ／ＩＰ処理要求を受信し、サーバ装置２との通信を行う。
【００２０】
一方、サーバ装置２は、著作権保護コンテンツ受信制御部２０１、受信側ＡＫＥ完了機器管理部２０２、ＵＰｎＰ Media Server Device処理部２０３、受信側ＡＫＥ処理部２０４、ＨＴＴＰサーバＰＯＳＴメソッド処理部２０５、ＤＴＣＰ復号処理部２０６、サーバコンテンツ蓄積部２０７、サーバリソース管理部２０８およびＴＣＰ／ＩＰネットワークＩ／Ｆ処理部２０９で構成される。
【００２１】
著作権保護コンテンツ受信制御部２０１は、クライアント装置１から著作権保護コンテンツのＭＯＶＥを受けるためのシステム制御を実行する。受信側ＡＫＥ完了機器管理部２０２は、ＡＫＥを行った機器の情報を記憶する。ＵＰｎＰ Media Server Device処理部２０３は、クライアント装置１のＵＰｎＰ Media Server Control Point処理部１０３からの制御指示に基づき動作する。
【００２２】
受信側ＡＫＥ処理部２０４は、受信側のＡＫＥ処理を実行する。ＨＴＴＰサーバＰＯＳＴメソッド処理部２０５は、ＨＴＴＰ  ＰＯＳＴメソッドのサーバに関する処理を行い、クライアント装置１からコンテンツを受信する。ＤＴＣＰ復号処理部２０６は、暗号化された著作権保護コンテンツをＤＴＣＰで定めた復号化手法により復号する。
【００２３】
サーバコンテンツ蓄積部２０７は、著作権保護コンテンツを記録蓄積する。サーバリソース管理部２０８は、クライアント装置１から送信される著作権保護コンテンツを記録するためのサーバ装置２のリソース管理を行う。そして、ＴＣＰ／ＩＰネットワークＩ／Ｆ処理部２０９は、ＵＰｎＰ Media Server Device処理部２０３、受信側ＡＫＥ処理部２０４およびＨＴＴＰサーバＰＯＳＴメソッド処理部２０５からのＴＣＰ／ＩＰ処理要求を受信し、クライアント装置１との通信を行う。
【００２４】
次に、図２を参照して、このような構成をもつ本実施形態のコンテンツ送受信システムにおけるクライアント装置１およびサーバ装置２間での著作権保護コンテンツの送受信シーケンスを説明する。
【００２５】
クライアント装置１は、著作権保護されたコンテンツをサーバ装置２に対してＭＯＶＥする場合、まず、ＵＰｎＰ  ＡＶで定めたContentDirectoryServiceのＣＤＳ：CreateObjectアクションによって、サーバ装置２上のリソースを確保する（図２（１））。サーバ装置２上のリソースを確保する際、クライアント装置１は、ＡＫＥを行うための自装置のポート番号とホストのアドレスとをプロパティとして付加する。例えば、図３に示すように、res@ProtocolInfoの４番目の領域（4th field）にそれぞれの値を定義する。図３の例では、MIME-TYPEがvideo/mpeg、ポート番号が23455、ホストアドレスが192.168.0.10の場合である。
【００２６】
サーバ装置２は、このＣＤＳ：CreateObjectアクション要求を受信すると、まず、クライアント装置１と既にＡＫＥを行っているかどうかをＩＰアドレスで確認し、行っていなければ、ＡＫＥ処理を開始する（図２（２））。そして、サーバ装置２は、このＡＫＥ処理の完了後に、要求されたリソース確保を行うと共に、その結果通知の返答を行う（図２（３））。つまり、ＡＫＥ処理の完了後にリソース確保を行うことにより、リソース確保を行ったもののＡＫＥ処理が失敗してしまったという状況を発生させることがない。
【００２７】
次に、クライアント装置１は、ＣＤＳ:CreateObjectアクションの返答データに含まれるＵＲＬに対して、コンテンツ伝送のためのＨＴＴＰ  ＰＯＳＴメソッドを用いて、ヘッダデータのみを送信する（図２（４））。このヘッダデータは、図４に示すContent-Typeエンティティヘッダを持ち、クライアント装置１のＡＫＥで用いられるポート番号とホストアドレスとが記載されている。また、ＨＴＴＰ１．１で定めるＥｘｐｅｃｔメカニズムを用い、Ｅｘｐｅｃｔ：100-Continueヘッダが付いている。
【００２８】
ここで、クライアント装置１は、サーバ装置２との間のＡＫＥが完了するまで、ＨＴＴＰ  ＰＯＳＴのボディとして、図５に示すＰＣＰ（Protected Content Packet）のＣＬを０としたコンテンツ本体を含まないＨＴＴＰボディを送信する（図２（５））。一方、サーバ装置２は、（図２（４）で受けた）ＨＴＴＰ  ＰＯＳＴメソッドのヘッダ部分のみを読み出し、クライアント装置１と既にＡＫＥを行っているかどうかをＩＰアドレスで確認する。もし、行っていなければ（ＣＤＳ：CreateObjectアクション要求後にクライアント装置１のＩＰアドレスが変更された等）、サーバ装置２は、図４に示した形式のリクエストから取得したクライアント装置１のポート番号およびホストアドレスを用いてＡＫＥを行い（図２（６））、これが完了したら、ＨＴＴＰ  ＰＯＳＴレスポンスを100 Continueで返答する（図２（７））。
【００２９】
そして、クライアント装置１は、このＨＴＴＰ  ＰＯＳＴメソッドのレスポンスを受信したら、暗号化したコンテンツを格納するＰＣＰをＨＴＴＰボディとしてサーバ装置２へ送信する（図２（８））。
【００３０】
つまり、ＡＫＥが完了するまで、ＰＣＰのＣＬを０としたコンテンツ本体を含まないＨＴＴＰボディを送受信し合い、ＡＫＥの完了後に、暗号化したコンテンツを格納するＰＣＰを含むＨＴＴＰボディの送受信を開始することにより、暗号化が解けずに一部のコンテンツを失ってしまうということを確実に防止する。
【００３１】
図６は、クライアント装置１の動作手順を示すフローチャートである。
【００３２】
クライアント装置１は、まず、ＡＫＥポート番号とホストアドレスとを取得し（ステップＡ１）、この取得した情報を用いて、ＣＤＳ：CreateObjectアクションを生成する（ステップＡ２）。そして、クライアント装置１は、この生成したＣＤＳ：CreateObjectアクションをサーバ装置２に送信すると共に（ステップＡ３）、これに対するＣＤＳ：CreateObjectレスポンスをサーバ装置２から受信する（ステップＡ４）。
【００３３】
クライアント装置１は、このＣＤＳ：CreateObjectレスポンスが成功レスポンスかどうかを調べ（ステップＡ５）、成功レスポンスであれば（ステップＡ５のＹＥＳ）、ＨＴＴＰ  ＰＯＳＴリクエストヘッダを生成し（ステップＡ６）、この生成したＨＴＴＰ  ＰＯＳＴリクエストヘッダをサーバ装置２に送信する（ステップＡ７）。また、クライアント装置１は、ＨＴＴＰ  ＰＯＳＴリクエストヘッダの送信後、今度は、ＰＣＰのコンテントの長さを０と設定したＨＴＴＰボディをサーバ装置２に送信する（ステップＡ７）。
【００３４】
クライアント装置１は、このＰＣＰのコンテントの長さを０と設定したＨＴＴＰボディの送信を、ＡＫＥが完了するまで行い、ＡＫＥが完了したら、ＨＴＴＰレスポンスを受信する（ステップＡ１０）。そして、クライアント装置１は、このＨＴＴＰレスポンスが100Continueかどうかを調べ（ステップＡ１１）、100Continueであれば（ステップＡ１１のＹＥＳ）、コンテンツを暗号化してＨＴＴＰボディを送信する（ステップＡ１２）。
【００３５】
図７および図８は、サーバ装置２の動作手順を示すフローチャートである。
【００３６】
サーバ装置２は、CreateObjectアクションを受信すると（図７ステップＢ１）、ＡＫＥが完了しているかどうかをＩＰアドレスにより調べ（図７ステップＢ２）、完了していなければ（図７ステップＢ２のＮＯ）、ＡＫＥを実行する（図７ステップＢ３）。もし、ＡＫＥが失敗した場合には（図７ステップＢ４のＮＯ）、サーバ装置２は、CreateObjectアクションに対する失敗レスポンスを送信する（図７ステップＢ５）。
【００３７】
ＡＫＥが成功すると（図７ステップＢ４のＹＥＳ）、サーバ装置２は、その機器情報を記憶し（図７ステップＢ６）、リソース確保を実行する（図７ステップＢ７）。なお、ここで実行されるリソース確保は、クライアント装置１から送信されてくるコンテンツ本体を格納する実領域を確保するものではなく、いずれかの領域をコンテンツ本体格納用にアサインするためのエントリを確保するものである。
【００３８】
このリソース確保が失敗すると（図７ステップＢ８のＮＯ）、サーバ装置２は、ＡＫＥ失敗時と同様、CreateObjectアクションに対する失敗レスポンスを送信し（図７ステップＢ５）、リソースが確保できれば（図７ステップＢ８のＹＥＳ）、CreateObjectアクションに対する成功レスポンスを送信する（図７ステップＢ９）。
【００３９】
この成功レスポンスを送信すると、サーバ装置２は、ＨＴＴＰ  ＰＯＳＴヘッダ部を受信し（図８ステップＣ１）、このタイミングでもＡＫＥが完了しているかどうかをＩＰアドレスにより調べる（図８ステップＣ２）。ＡＫＥが完了していなければ（図８ステップＣ２のＮＯ）、サーバ装置２は、ＡＫＥを実行し（図８ステップＣ３）、もし、このＡＫＥが失敗したら（図８ステップＣ４のＮＯ）、ＨＴＴＰレスポンスとして406 Not Allowedを送信する（図８ステップＤ５）。
【００４０】
一方、ＡＫＥに成功すると（図８ステップＣ４のＹＥＳ）、サーバ装置２は、その機器情報を記憶し（図８ステップＣ６）、リソース確保を実行する（図８ステップＣ７）。ここで実行されるリソース確保は、クライアント装置１から送信されてくるコンテンツ本体を格納する実領域を確保し、先に確保したエントリに関係づけるものである。
【００４１】
このリソース確保が失敗すると（図８ステップＣ８のＮＯ）、サーバ装置２は、ＨＴＴＰレスポンスとして413Request Entity Too Largeを送信し（図８ステップＣ９）、リソースが確保できれば（図８ステップＣ８のＹＥＳ）、ＨＴＴＰレスポンスとして100Continueを送信すると共に（図８ステップＣ１０）、ＨＴＴＰボディの受信、復号および蓄積を実行する（図８ステップＣ１１）。
【００４２】
ところで、この図６乃至図８のフローチャートでは、ＣＤＳ：CreateObjectアクション後の「ＡＫＥ処理」および「リソース確保処理」について、「ＡＫＥ処理」→「リソース確保処理」の順でこれらを実施する手順を示したが、これに限らず、これらは逆の順で行っても構わない。図９および図１０は、その手順を逆にした場合の図６および図８に対応するフローチャートである。
【００４３】
この場合、クライアント装置１は、ＰＣＰのコンテントの長さを０と設定したＨＴＴＰボディをサーバ装置２に送信した後（図９ステップＤ８）、ＨＴＴＰレスポンスを受信したかどうかをまず調べ（図９ステップＤ９）、このＨＴＴＰレスポンスを受信するまで、当該ＨＴＴＰボディの送信を行う。そして、ＨＴＴＰレスポンスを受信したら（図９ステップＤ９のＹＥＳ）、クライアント装置１は、そのＨＴＴＰレスポンスが100Continueかどうかを調べ（図９ステップＤ１０）、100Continueであれば（図９ステップＤ１０のＹＥＳ）、ここで、ＡＫＥが成功しているかどうかを調べる（図９ステップＤ１１）。そして、ＡＫＥが成功していれば（図９ステップＤ１１のＹＥＳ）、クライアント装置１は、コンテンツを暗号化してＨＴＴＰボディを送信する（図９ステップＥ１２）。
【００４４】
一方、サーバ装置２は、ＨＴＴＰ  ＰＯＳＴヘッダ部を受信すると（図１０ステップＥ１）、まず、（実領域の）リソース確保を実行し（図１０ステップＥ２）、リソースが確保できなければ（図１０ステップＥ３のＮＯ）、ＨＴＴＰレスポンスとして413Request Entity Too Largeを送信する（図８ステップＣ４）。また、リソースが確保できれば（図１０ステップＥ３のＹＥＳ）、サーバ装置２は、ＨＴＴＰレスポンスとして100Continueを送信し（図１０ステップＤ５）、ＨＴＴＰボディを受信する（図１０ステップＤ６）。ここで、サーバ装置２は、コンテンツが暗号化されているかどうかを調べ（図１０ステップＤ７）、暗号化されていなければ（図１０ステップＤ７のＮＯ）、このＨＴＴＰボディ部の受信、蓄積を実行する（図１０ステップＤ８）。
【００４５】
コンテンツが暗号化されていれば（図１０ステップＤ７のＹＥＳ）、サーバ装置２は、ここで、ＡＫＥが完了しているかどうかを調べる（図１０ステップＤ９）。ＡＫＥが完了していなければ（図１０ステップＥ９のＮＯ）、サーバ装置２は、ＡＫＥを実行し（図１０ステップＥＣ３）、もし、このＡＫＥが失敗したら（図１０ステップＥ１１のＮＯ）、ＴＣＰ接続を切断する（図１０ステップＥ１２）。そして、ＡＫＥに成功したら（図１０ステップＥ１１のＹＥＳ）、サーバ装置２は、その機器情報を記憶すると共に（図１０ステップＥ１３）、ＨＴＴＰボディの受信、復号および蓄積を実行する（図１０ステップＥ１４）。
【００４６】
このように、ＣＤＳ：CreateObjectアクション後の「ＡＫＥ処理」および「リソース確保処理」は、その順番を入れ替えることが可能である。
【００４７】
また、（図２（１）のタイミングの）サーバリソースの確保の際、ＡＫＥを行うための情報として、前述の自装置のポート番号とホストのアドレスとに加えて、さらにデバイスＩＤをプロパティとして付加することも有効である。図１１には、MIME-TYPEがvideo/mpeg、ポート番号が23455、 ホストアドレスが192.168.0.10、Device IDが3821の場合の例が示されている。この場合、サーバ装置２は、CDS:CreateObjectアクション要求を受信した際、クライアント装置１との間でＡＫＥを行っているかどうかを、このデバイスＩＤで確認する。
【００４８】
そして、この場合、クライアント装置１は、（図２（５）のタイミングの）ＨＴＴＰ  ＰＯＳＴのヘッダを送信する際、例えば図１２に示すような、機器固有の値としてＤＴＣＰで定めるDeivceを表すヘッダを付加する。一方、サーバ装置２は、（図２（７）のタイミングの）レスポンスの返信時、図１３に示すような形式で、その機器固有の値を100 Continueに付加する。
【００４９】
これにより、たとえＣＤＳ：CreateObjectアクション要求後にクライアント装置１のＩＰアドレスが変更されたとしても、デバイスＩＤでＡＫＥの完了を認識でき、不要なＡＫＥの実行を省略できる。
【００５０】
以上詳述したように、本実施形態のコンテンツ送受信システムでは、ＡＫＥが完了した場合のみ、サーバ装置２のリソースが確保され、また、暗号が解けるようになった場合にのみコンテンツが送受信される。そのため、サーバ装置２での無駄なリソース確保がなくなると共に、クライアント装置１が無駄なリソースを消す手間が無くなり、また、ＡＫＥ完了前に暗号化されたコンテンツ伝送が行われることがないので、コンテンツの消失を確実に防止する。
【００５１】
また、サーバ装置２は、メディア伝送のヘッダ情報からもＡＫＥを実行し、コンテンツ伝送直前で伝送可能であることを確認するため、コンテンツ伝送の直前でＩＰアドレスが変更されたクライアント装置１からのデータも確実に取得できる。
【００５２】
さらに、クライアント装置１は、ヘッダ部分を送出後、ＡＫＥが完了するまでＰＣＰヘッダのみを含むＨＴＴＰボディを送出するので、本実施形態のサーバ装置２のような実装ではなく、ＨＴＴＰボディを受け取った場合にのみＡＫＥを開始するような実装のサーバ装置に対しても、当該ＡＫＥが完了するまで待つことができる。
【００５３】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００５４】
【図１】この発明の実施形態に係るコンテンツ送受信システムの概略ブロック図
【図２】同実施形態のコンテンツ送受信システムのクライアント／サーバ間の概略シーケンス図
【図３】同実施形態のコンテンツ送受信システムのＣＤＳ：CreateObjectアクションにおけるＡＫＥ情報の例を示す図
【図４】同実施形態のコンテンツ送受信システムのＨＴＴＰ  ＰＯＳＴリクエストにおけるＡＫＥ情報の例を示す図
【図５】同実施形態のコンテンツ送受信システムで用いられるＰＣＰのフォーマットを示す図
【図６】同実施形態のコンテンツ送受信システムのクライアント装置の動作手順を示すフローチャート
【図７】同実施形態のコンテンツ送受信システムのサーバ装置の第１の動作手順を示すフローチャート
【図８】同実施形態のコンテンツ送受信システムのサーバ装置の第２の動作手順を示すフローチャート
【図９】同実施形態のコンテンツ送受信システムのクライアント装置の動作手順の変形例を示すフローチャート
【図１０】同実施形態のコンテンツ送受信システムのサーバ装置の第２の動作手順の変形例を示すフローチャート
【図１１】同実施形態のコンテンツ送受信システムのＣＤＳ：CreateObjectアクションにおけるＡＫＥ情報の変形例を示す図
【図１２】同実施形態のコンテンツ送受信システムのＨＴＴＰ  ＰＯＳＴリクエストにおけるＡＫＥ情報の変形例を示す図
【図１３】同実施形態のコンテンツ送受信システムのＨＴＴＰ  ＰＯＳＴレスポンスにおけるＡＫＥ情報の変形例を示す図
【符号の説明】
【００５５】
１…クライアント装置、２…サーバ装置、３…ネットワーク、１０１…著作権保護コンテンツ送信制御部、１０２…送信側ＡＫＥ完了機器管理部、１０３…ＵＰｎＰ Media Server Control Point処理部、１０４…送信側ＡＫＥ処理部、１０５…ＨＴＴＰクライアントＰＯＳＴメソッド処理部、１０６…ＤＴＣＰ暗号処理部、１０７…クライアントコンテンツ蓄積部、１０８…コンテンツ送信管理部、１０９…ＴＣＰ／ＩＰネットワークＩ／Ｆ処理部、２０１…著作権保護コンテンツ受信制御部、２０２…受信側ＡＫＥ完了機器管理部、２０３…ＵＰｎＰ Media Server Device処理部、２０４…受信側ＡＫＥ処理部、２０５…ＨＴＴＰサーバＰＯＳＴメソッド処理部、２０６…ＤＴＣＰ復号処理部、２０７…サーバコンテンツ蓄積部、２０８…サーバリソース管理部、２０９…ＴＣＰ／ＩＰネットワークＩ／Ｆ処理部。
【図１】
2006339900.tif 000003
【図２】
2006339900.tif 000004
【図３】
2006339900.tif 000005
【図４】
2006339900.tif 000006
【図５】
2006339900.tif 000007
【図６】
2006339900.tif 000008
【図７】
2006339900.tif 000009
【図８】
2006339900.tif 000010
【図９】
2006339900.tif 000011
【図１０】
2006339900.tif 000012
【図１１】
2006339900.tif 000013
【図１２】
2006339900.tif 000014
【図１３】
2006339900.tif 000015
【手続補正書】
【提出日】平成18年5月19日(2006.5.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で他の装置に送信するデータ送信装置であって、
前記他の装置と鍵交換し、コンテンツデータの暗号化に用いる暗号鍵を作成する鍵交換手段と、
前記鍵交換手段が行う鍵交換で前記他の装置が必要とする自装置の情報を前記他の装置に送信する第１の制御手段と、
前記第１の制御手段による自装置の情報の送信後、データサイズが零である旨の設定がされたパケットを前記他の装置に送信する第２の制御手段と、
前記鍵交換手段による鍵交換が完了した後に、コンテンツデータを暗号化した暗号データを格納するパケットを前記他の装置に送信する第３の制御手段と
を具備することを特徴とするデータ送信装置。
【請求項２】
ネットワークインフラストラクチャとしてＩＰ（Internet Protocol）、コンテンツデータの伝送プロトコルとしてＨＴＴＰ（Hypertext Transfer Protocol）をそれぞれ用い、
前記第１の制御手段は、ポート番号およびホストアドレスを含むＨＴＴＰヘッダを自装置の情報として前記他の装置に送信すること
を特徴とする請求項１記載のデータ送信装置。
【請求項３】
前記第１の送信手段は、さらにデバイスＩＤを含むＨＴＴＰヘッダを自装置の情報として前記他の装置に送信すること
を特徴とする請求項２記載のデータ送信装置。
【請求項４】
コンテンツデータの伝送プロトコルとしてＨＴＴＰを用い、
前記第２の制御手段は、データサイズを零である旨の設定がされたＰＣＰ（Protect Content Packet）のみをＨＴＴＰボディとするパケットを前記他の装置に送信すること
を特徴とする請求項１記載のデータ送信装置。
【請求項５】
移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で他の装置から受信するデータ受信装置であって、
前記他の装置と鍵交換し、コンテンツデータの復号に用いる暗号鍵を作成する鍵交換手段と、
コンテンツデータを格納するためのリソース確保を前記他の装置から要求された際に、前記鍵交換手段に鍵交換させる第１の制御手段と、
前記鍵交換手段が鍵交換を完了した後に、前記他の装置から要求されたリソース確保を行い、その結果を前記他の装置に通知する第２の制御手段と
を具備することを特徴とするデータ受信装置。
【請求項６】
前記第１の制御手段は、前記他の装置との間で鍵交換する必要があるか否かを判断し、
前記第２の制御手段は、前記第１の制御手段が鍵交換を不要と判断した場合に、鍵交換を行わずに前記他の装置から要求されたリソース確保を行うこと
を特徴とする請求項５記載のデータ受信装置。
【請求項７】
ネットワークインフラストラクチャとしてＩＰを用い、
前記第１の制御手段は、前記他の装置のＩＰアドレスに基づき、当該他の装置との間の鍵交換の要否を判断すること
を特徴とする請求項６記載のデータ受信装置。
【請求項８】
前記第１の制御手段は、前記他の装置のデバイスＩＤに基づき、当該他の装置との間の鍵交換の要否を判断すること
を特徴とする請求項６記載のデータ受信装置。
【請求項９】
移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で他の装置から受信するデータ受信装置であって、
前記他の装置からのパケット受信開始時、鍵交換に必要な前記他の装置の情報を格納する領域部分を読み出す第１の制御手段と、
前記第１の制御手段が読み出した前記他の装置の情報を用いて前記他の装置と鍵交換し、コンテンツデータの復号に用いる暗号鍵を作成する鍵交換手段と、
前記鍵交換手段による鍵交換が完了した後に、前記他の装置から受信したパケットの内、コンテンツデータが暗号化された暗号データを格納する領域部分の読み出しを開始する第３の制御手段と
を具備することを特徴とするデータ受信装置。
【請求項１０】
前記コンテンツデータの伝送プロトコルとしてＨＴＴＰを用い、
前記第１の制御手段はＨＴＴＰヘッダを、前記他の装置の情報を格納する領域部分として読み出し、
前記第３の制御手段はＨＴＴＰボディに含まれ、前記コンテンツデータが暗号化された暗号データを格納する領域部分を内部に含むＰＣＰを順次読み出すこと
を特徴とする請求項９記載のデータ受信装置。
【請求項１１】
前記鍵交換手段は、前記他の装置との間で鍵交換する必要があるか否かを判断し、
前記第３の制御手段は、前記鍵交換手段が鍵交換を不要と判断した場合には、鍵交換を行わずに暗号データを格納した領域部分の読み出しを開始すること
を特徴とする請求項９記載のデータ受信装置。
【請求項１２】
ネットワークインフラストラクチャとしてＩＰを用い、
前記鍵交換手段は、前記他の装置のＩＰアドレスに基づき、当該他の装置との間の鍵交換の要否を判断すること
を特徴とする請求項１１記載のデータ受信装置。
【請求項１３】
前記鍵交換手段は、前記他の装置のデバイスＩＤに基づき、当該他の装置との間の鍵交換の要否を判断すること
を特徴とする請求項１１記載のデータ受信装置。
【請求項１４】
移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で他の装置に送信するデータ送信装置のデータ送信方法であって、
コンテンツデータの暗号化に用いる暗号鍵を作成するための鍵交換に前記他の装置が必要とする自装置の情報を送信し、
自装置の情報の送信後、データサイズが零である旨の設定がされたパケットを前記他の装置に送信し、
鍵交換が完了した後に、コンテンツデータを暗号化した暗号データを格納したパケットを前記他の装置に送信する
ことを特徴とするデータ送信装置のデータ送信方法。
【請求項１５】
移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で他の装置から受信するデータ受信装置のデータ受信方法であって、
コンテンツデータを格納するためのリソース確保を前記他の装置から要求された場合、コンテンツデータの復号に用いる暗号鍵を作成するための鍵交換を前記他の装置と行い、
鍵交換が完了した後に、前記他の装置から要求されたリソース確保を行い、その結果を前記他の装置に通知すること
を特徴とするデータ受信装置のデータ受信方法。
【請求項１６】
移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で他の装置から受信するデータ受信装置のデータ受信方法であって、
前記他の装置からのパケットの受信開始時、鍵交換に必要な前記他の装置の情報が格納された領域部分を読み出し、
読み出した前記他の装置の情報を用いて前記他の装置と鍵交換して、コンテンツデータの復号に用いる暗号鍵を作成し、
鍵交換が完了した後に、前記他の装置から受信したパケットの内、コンテンツデータが暗号化された暗号データを格納した領域部分の読み出しを開始すること
を特徴とするデータ受信装置のデータ受信方法。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
この発明は、このような事情を考慮してなされたものであり、移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツの移動を確実に行うことを可能とするデータ送信装置、データ受信装置、データ送信方法およびデータ受信方法を提供することを目的とする。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【００１１】
前述した目的を達成するために、この発明のデータ送信装置は、移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で他の装置に送信するデータ送信装置であって、前記他の装置と鍵交換し、コンテンツデータの暗号化に用いる暗号鍵を作成する鍵交換手段と、前記鍵交換手段が行う鍵交換で前記他の装置が必要とする自装置の情報を前記他の装置に送信する第１の制御手段と、前記第１の制御手段による自装置の情報の送信後、データサイズが零である旨の設定がされたパケットを前記他の装置に送信する第２の制御手段と、前記鍵交換手段による鍵交換が完了した後に、コンテンツデータを暗号化した暗号データを格納するパケットを前記他の装置に送信する第３の制御手段とを具備することを特徴とする。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】変更
【補正の内容】
【００１２】
また、この発明のデータ受信装置は、移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で他の装置から受信するデータ受信装置であって、前記他の装置と鍵交換し、コンテンツデータの復号に用いる暗号鍵を作成する鍵交換手段と、コンテンツデータを格納するためのリソース確保を前記他の装置から要求された際に、前記鍵交換手段に鍵交換させる第１の制御手段と、前記鍵交換手段が鍵交換を完了した後に、前記他の装置から要求されたリソース確保を行い、その結果を前記他の装置に通知する第２の制御手段とを具備することを特徴とする。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】変更
【補正の内容】
【００１３】
また、この発明のデータ受信装置は、移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で他の装置から受信するデータ受信装置であって、前記他の装置からのパケット受信開始時、鍵交換に必要な前記他の装置の情報を格納する領域部分を読み出す第１の制御手段と、前記第１の制御手段が読み出した前記他の装置の情報を用いて前記他の装置と鍵交換し、コンテンツデータの復号に用いる暗号鍵を作成する鍵交換手段と、前記鍵交換手段による鍵交換が完了した後に、前記他の装置から受信したパケットの内、コンテンツデータが暗号化された暗号データを格納する領域部分の読み出しを開始する第３の制御手段とを具備することを特徴とする。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００５３
【補正方法】変更
【補正の内容】
【００５３】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
例えば、以下のように発明を形成することもできる。
（１）移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置に送信するコンテンツ送信装置において、前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換手段と、前記鍵交換手段により実行される鍵交換で相手側が必要とする自装置の情報を前記他の装置に送信する第１の制御手段と、前記第１の制御手段による自装置の情報の送信後、前記鍵交換手段による鍵交換が完了するまでの間、格納されたデータが暗号化されており、かつ、そのデータサイズが零である旨の設定がなされたパケットを前記他の機器に送信する第２の制御手段と、前記鍵交換手段による鍵交換が完了した後に、前記コンテンツを暗号化した暗号データを格納させたパケットの前記他の機器に対する送信を開始する第３の制御手段とを具備することを特徴とするコンテンツ送信装置。
（２）移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置から受信するコンテンツ受信装置において、前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換手段と、前記コンテンツを格納するためのリソース確保を前記他の機器から要求された際に、前記鍵交換を前記鍵交換手段に開始させる第１の制御手段と、前記鍵交換手段による鍵交換が完了した後に、前記要求されたリソース確保を実行し、その結果通知を前記他の機器に返信する第２の制御手段とを具備することを特徴とするコンテンツ受信装置。
（３）移動元と移動先との双方での同時存在を禁止する著作権保護機構によって保護されたコンテンツをネットワーク経由で他の装置から受信するコンテンツ受信装置において、前記コンテンツの暗号化および復号に用いる暗号鍵を前記他の機器との間で交換する鍵交換手段と、前記コンテンツを暗号化した暗号データの受信開始時、前記鍵交換手段による鍵交換に必要な前記他の装置の情報が格納された領域部分のみを読み出す第１の制御手段と、前記第１の制御手段により読み出された領域部分に格納された前記他の装置の情報を用いた鍵交換を前記鍵交換手段に開始させる第２の制御手段と、前記鍵交換手段による鍵交換が完了した後に、前記コンテンツを暗号化した暗号データが格納された領域部分の読み出しを開始する第３の制御手段とを具備することを特徴とするコンテンツ受信装置。