JP4709583B2

JP4709583B2 - データ送信装置およびデータ送信方法

Info

Publication number: JP4709583B2
Application number: JP2005160613A
Authority: JP
Inventors: 和宣紺田; 秀紀大喜多; 宏之茶木
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2005-05-31
Filing date: 2005-05-31
Publication date: 2011-06-22
Anticipated expiration: 2025-05-31
Also published as: JP2006339900A; US7688860B2; US20060271786A1

Description

この発明は、例えば２台のＨＤＤ（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処理部、２０４…受信側ＡＫＥ処理部、２０５…ＨＴＴＰサーバＰＯＳＴメソッド処理部、２０６…ＤＴＣＰ復号処理部、２０７…サーバコンテンツ蓄積部、２０８…サーバリソース管理部、２０９…ＴＣＰ／ＩＰネットワークＩ／Ｆ処理部。

Claims

移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で他の装置に送信するデータ送信装置であって、
前記他の装置と鍵交換し、コンテンツデータの暗号化に用いる暗号鍵を作成する鍵交換手段と、
前記鍵交換手段が行う鍵交換で前記他の装置が必要とする自装置の情報を前記他の装置に送信する第１の制御手段と、
前記第１の制御手段による自装置の情報の送信後、格納されたデータが暗号化されている旨およびデータサイズが零である旨の設定がされたパケットを前記他の装置に送信する第２の制御手段と、
前記鍵交換手段による鍵交換が完了した後に、コンテンツデータを暗号化した暗号データを格納する前記パケットを前記他の装置に送信する第３の制御手段と
を具備することを特徴とするデータ送信装置。
ネットワークインフラストラクチャとしてＩＰ（Internet Protocol）、コンテンツデータの伝送プロトコルとしてＨＴＴＰ（Hypertext Transfer Protocol）をそれぞれ用い、
前記第１の制御手段は、ポート番号およびホストアドレスを含むＨＴＴＰヘッダを自装置の情報として前記他の装置に送信すること
を特徴とする請求項１記載のデータ送信装置。
前記第１の送信手段は、さらにデバイスＩＤを含むＨＴＴＰヘッダを自装置の情報として前記他の装置に送信すること
を特徴とする請求項２記載のデータ送信装置。
コンテンツデータの伝送プロトコルとしてＨＴＴＰを用い、
前記第２の制御手段は、データサイズを零である旨の設定がされたＰＣＰ（Protect Content Packet）のみをＨＴＴＰボディとするパケットを前記他の装置に送信すること
を特徴とする請求項１記載のデータ送信装置。
他の装置と鍵交換し、コンテンツデータの暗号化に用いる暗号鍵を作成する鍵交換手段および移動元と移動先との双方での同時存在が禁止されたコンテンツデータをネットワーク経由で前記他の装置に送信するコンテンツ送信制御手段を有するデータ送信装置のデータ送信方法であって、
前記コンテンツ送信制御手段が、
前記鍵交換手段が行う鍵交換で前記他の装置が必要とする自装置の情報が前記他の装置に送信された後、格納されたデータが暗号化されている旨およびデータサイズが零である旨の設定がされたパケットを前記他の装置に送信し、
前記鍵交換手段による鍵交換が完了した後に、コンテンツデータを暗号化した暗号データを格納した前記パケットを前記他の装置に送信する
ことを特徴とするデータ送信装置のデータ送信方法。