JP4843686B2 - 送信装置、受信装置及び送信方法 - Google Patents

Description

本発明は、著作権保護の必要な各種コンテンツを送信または受信する送信装置、受信装置及び送信方法に関する。

ブロードバンドや無線ＬＡＮ等のコンピュータネットワークの普及や、デジタル技術の進展に伴い、通信機能を備えたデジタル情報機器（以下、デジタル家電）と呼ばれる製品が普及しつつある。また、地上デジタル放送の開始に伴い、デジタル放送対応のテレビやセットトップボックス、ＤＶＤレコーダ等が、今後より一層普及することが予想される。複数のデジタル家電がネットワークに接続されれば、利用者はネットワーク経由でコンテンツを楽しむことができ、有益である。

ここで、コンテンツとは、各種のデジタルデータ、例えばＭＰＥＧ−２やＭＰＥＧ−４などの動画データや音声データ、テキストデータや画像データのようなドキュメント・データなどを指す。この種のデジタルデータからなるコンテンツは劣化することなく容易に複製することが可能であるという利点を持つ反面、コンテンツの著作権に関して注意を払わなければならない。例えば、著作権を保護すべきコンテンツを、ある送信装置から受信装置に移動（ムーブ）する場合を考える。著作権を保護すべきコンテンツをムーブする場合には、受信装置に送信したコンテンツが送信装置に残ることなく、また通信経路上で受信装置以外の他の装置に平文でコピーされることなく移動することが望ましい。通信経路上でコンテンツのコピーを防ぐ手段としては、送信装置と受信装置で鍵を共有し、その鍵によりコンテンツを暗号化して伝送する方法がある（非特許文献１参照）。

送信装置から同一のコンテンツを複数の受信装置に同時に配信するマルチキャスト、またはブロードキャストのモデルではコンテンツは同一の鍵により暗号化する方が通信の効率の観点からは効率がよい。従って、複数の受信装置が同一の鍵を共有する事態が生じる。しかし、複数の受信装置に配布した鍵でムーブすると、ムーブ対象のコンテンツを複数の受信装置が復号できることになってしまうため、コンテンツのムーブが正常に実行されない。
ＤＴＣＰ−ＩＰ仕様書"ＤＴＣＰ, Volume 1, Supplement E, Mapping DTCP to IP (Information Version)"(http://www.dtcp.com)

このように従来のコンテンツ送受信システムには、コンテンツのムーブが正常に実行されず、著作権が保護できないという事態が生じる可能性がある。

本発明は、上記の問題点に鑑みてなされたものであり、その目的は、コンテンツの不正利用を防止し、かつコンテンツを効率良く利用可能なコンテンツ送信装置、コンテンツ受信装置、コンテンツ送信方法を提供することである。

上記した課題を解決し目的を達成するために、本発明は以下に示す手段を用いている。

本発明の一実施態様によれば、送信装置から第１受信装置へコンテンツを送信する送信方法において、前記送信装置が前記第１受信装置へコンテンツ受信要求を送信する第１ステップと、前記第１受信装置が前記第１受信装置を含む複数の受信装置に共通なレンダリング用の第１鍵あるいは前記第１受信装置に固有なムーブ用の第２鍵のための認証、鍵交換の開始要求を前記送信装置へ送信する第２ステップと、前記送信装置が上記認証、鍵交換により得られた前記第１鍵あるいは第２鍵を前記第１受信装置へ送信する第３ステップと、前記第１受信装置が上記認証、鍵交換により得られた鍵のラベルを含むコンテンツ受信確認を前記送信装置へ送信する第４ステップと、前記送信装置が前記コンテンツ受信確認に含まれるラベルに応じた鍵を用いてコンテンツを暗号化して前記第１受信装置へ送信する第５ステップと、を具備する。

本発明の他の実施態様によれば、第１受信装置へコンテンツ受信要求を送信する第１手段と、前記第１受信装置から送信された前記第１受信装置を含む複数の受信装置に共通なレンダリング用の第１鍵あるいは前記第１受信装置に固有なムーブ用の第２鍵のための認証、鍵交換の開始要求を受信する第２手段と、上記認証、鍵交換により得られた前記第１鍵あるいは前記第２鍵を前記第１受信装置へ送信する第３手段と、前記第１受信装置から送信された上記認証、鍵交換により得られた鍵のラベルを含むコンテンツ受信確認を受信する第４手段と、前記コンテンツ受信確認に含まれるラベルに応じた鍵を用いてコンテンツを暗号化して前記第１受信装置へ送信する第５手段と、を具備する送信装置が提供される。

本発明の他の実施態様によれば、送信装置から送信されたコンテンツ受信要求を受信する第１手段と、複数の受信装置に共通なレンダリング用の第１鍵あるいは当該受信装置に固有なムーブ用の第２鍵のための認証、鍵交換の開始要求を前記送信装置へ送信する第２手段と、上記認証、鍵交換により得られた前記第１鍵または第２鍵を前記送信装置から受信する第３手段と、上記認証、鍵交換により得られた鍵のラベルを含むコンテンツ受信確認を前記送信装置へ送信する第４手段と、前記コンテンツ受信確認に含まれるラベルに応じた鍵を用いて暗号化されたコンテンツを前記送信装置から受信する第５手段と、を具備する受信装置が提供される。

本発明によれば、コンテンツの不正利用を防止し、かつコンテンツを効率良く利用可能なコンテンツ送信装置、コンテンツ受信装置、コンテンツ送信方法を提供することができる。

以下、図面を参照して本発明によるコンテンツ送信装置、コンテンツ受信装置及びコンテンツ送信方法の実施形態を説明する。

本実施形態はコンテンツ送信装置（以下、送信装置）からコンテンツ受信装置（以下、受信装置）へコンテンツをムーブ、あるいはレンダリング・コピーするコンテンツ送受信システムに関する。ムーブとは、コンテンツの送信後、送信側でコンテンツを無効化（削除）するものであるが、レンダリング・コピーは無効化しない。コピーとは、システム内で同一のコンテンツが複数存在するものである。レンダリングとは、送信装置が蓄積しているコンテンツを受信装置が表示するものであり、システム内で同一のコンテンツは複数存在しない。以下では説明の便宜上、単にレンダリングと称する場合は、コピーとレンダリングの両方を含む。

送信装置はコンテンツを蓄積しているので、送信装置はソース、受信装置はシンクとも呼ばれる。第１実施形態は受信装置から送信装置側にコンテンツのムーブ、またはレンダリングを要求する例であり、ユーザは受信装置側にいるので、受信装置はクライアントとも呼ばれ、送信装置はサーバとも呼ばれる。第２実施形態は送信装置から受信装置側にコンテンツのムーブ、あるいはレンダリングを要求する例であり、ユーザは送信装置側にいるので、送信装置はクライアント、受信装置はサーバとも呼ばれる。

第１の実施形態
図１は第１実施形態に係る送信装置１００の概略構成を示すブロック図である。図１に示すように、送信装置１００はコンテンツ供給部１２と、認証・鍵交換処理部１４と、コンテンツリスト管理部１６と、鍵選択処理部１８と、暗号処理部２０と、ネットワークインターフェース処理部２２と、コンテンツ伝送用コネクション管理部２４と、コンテンツ管理用コネクション管理部２６と、認証・鍵交換用コネクション管理部２８を有する。

コンテンツ供給部１２は、コンテンツやコンテンツのリストを蓄積する。

認証・鍵交換処理部１４は、受信装置との間で認証・鍵交換処理を行う。本実施形態では、図２に示すように、１つの送信装置Ｘ（またはＹ）に対して複数の受信装置Ａ、Ｂ、Ｃ（またはＤ、Ｅ）の存在を許容している。認証・鍵交換処理部１４は、受信装置との間で認証・鍵交換処理が成功すると、各受信装置に対して送信するコンテンツを暗号化する秘密鍵を生成する。本実施形態では、レンダリングとムーブとで別々の秘密鍵を用いてコンテンツを暗号化する。以下、レンダリング用コンテンツの暗号化に用いる秘密鍵を共通鍵Ｋｘ、ムーブ用コンテンツの暗号化に用いる秘密鍵をムーブ鍵Ｋｘｍと称する。

認証・鍵交換処理部１４が生成した共通鍵Ｋｘ、ムーブ鍵Ｋｘｍは鍵交換により送信装置と受信装置とで共有された鍵により暗号化して受信装置に送信される。共通鍵Ｋｘ、ムーブ鍵Ｋｘｍはそれぞれ共通鍵ラベル、ムーブ鍵ラベルをつけて認証・鍵交換処理部１４に格納される。後述するように、複数の鍵（共通鍵、ムーブ鍵）の存在が許容されているので、共通鍵ラベル及びムーブ鍵ラベルは、それぞれの鍵を区別するための識別情報である。

送信装置は認証・鍵交換処理が成功した全ての受信装置に対して同一の共通鍵Ｋｘを共有する。すなわち、共通鍵Ｋｘは送信装置毎に１つだけである。送信装置から同一のコンテンツを複数の受信装置に同時に配信するマルチキャスト、またはブロードキャストのモデルでは、通信効率の観点からはコンテンツは同一の鍵により暗号化する方が好ましい。従って、送信装置は複数の受信装置に対して同一の共通鍵Ｋｘを送信する。

一方、送信装置は各受信装置と、共通鍵Ｋｘとは異なるムーブ鍵Ｋｘｍを共有する。複数の受信装置に対してムーブを行う場合には、各受信装置に対応して複数のムーブ鍵Ｋｘｍを保持していてもよい。

ここで、認証・鍵交換処理とは、送信装置や受信装置があるライセンス機関から正しくライセンスをうけた装置であることを相互に認証し、正当な装置であると確認できた場合に、共通の鍵を生成する処理のことを指す。認証の方法としては、例えばＩＳＯ／ＩＥＣ ９７９８−３やＩＳＯ／ＩＥＣ ９７９８−２のような公知の手法がある。

コンテンツリスト管理部１６は、コンテンツ供給部１２に蓄積されたコンテンツのリストを管理したり、受信装置からのコンテンツ検索要求に対して蓄積コンテンツのリストを提示したりする。

鍵選択処理部１８は、受信装置から受け取ったコンテンツ要求がレンダリング要求かムーブ要求かに応じて、コンテンツを共通鍵Ｋｘで暗号化するか、あるいはムーブ鍵Ｋｘｍで暗号化するかを判別するための処理を行い、認証・鍵交換処理部１４に格納された受信装置と共有している鍵の中から適切な鍵を選択し、暗号処理部２０に供給する。

暗号処理部２０は、鍵選択処理部１８から供給された鍵を用いてコンテンツを暗号化する。これらのデータを暗号・復号化するための暗号アルゴリズムとしては、例えばＡＥＳなどの公知の手法がある。

ネットワークインターフェース処理部２２は、受信装置と通信を行うための物理レイヤ処理、データリンクレイヤ処理、ネットワークレイヤ・トランスポートレイヤ処理を実行する。物理レイヤおよびリンクレイヤは、ＩＥＥＥ８０２．１１に準拠した無線ＬＡＮ、イサーネット（登録商標）、ＩＥＥＥ１３９４などの種々の形態をとりうる。ネットワークレイヤは、インターネットプロトコル（以下、単にＩＰと呼ぶ）が使用されている場合には、ＩＰｖ４でもよいし、ＩＰｖ６でもよい。

コンテンツ伝送用コネクション管理部２４はコンテンツ送信用のコネクションを管理する。コンテンツ管理用コネクション管理部２６は、受信装置からの要求に応じてコンテンツリストを提示したり、コンテンツのＵＲＬを提示したりするコネクションを管理したりする。受信装置にコンテンツのリストを提示する方法としては、例えばＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）のようなプロトコルが用いられる。またコンテンツの場所を表すための手段としては、例えばＵＲＬが用いられる。

認証・鍵交換用コネクション管理部２８は認証・鍵交換用のコネクションを管理する。

図３は第１実施形態の受信装置１０２の概略構成を示すブロック図である。図３に示すように、受信装置１０２は、コンテンツ処理部３２と、認証・鍵交換処理部３４と、コンテンツ選択部３６と、鍵選択処理部３８と、暗号処理部４０と、ネットワークインターフェース処理部４２と、コンテンツ伝送用コネクション管理部４４と、コンテンツ管理用コネクション管理部４６と、認証・鍵交換用コネクション管理部４８を有する。

ネットワークインターフェース処理部４２、コンテンツ伝送用コネクション管理部４４と、コンテンツ管理用コネクション管理部４６と、認証・鍵交換用コネクション管理部４８については、送信装置内の対応するブロックと同様の機能を持ち、同様のブロックで構成することができる。

コンテンツ処理部３２は、受信したコンテンツを表示装置等に出力したり、図示しない記憶部に蓄積したりするための処理を行う。

認証・鍵交換処理部３４は、送信装置と認証・鍵交換処理を行う。認証・鍵交換処理部３４は、認証・鍵交換処理が成功すると、コンテンツを復号化するのに用いる秘密鍵である共通鍵Ｋｘ、ムーブ鍵Ｋｘｍを送信装置から受信し、それらをラベルをつけて格納する。

コンテンツ選択部３６は、送信装置と通信を行い、送信装置のコンテンツ供給部１２に蓄積されたコンテンツを検索したり、検索結果のリストとそれぞれのコンテンツのネットワーク上の場所を管理する。送信装置に蓄積されたコンテンツのリストを送信装置またはネットワーク上の機器から取得する手段としては、例えばＵＰｎＰといった手段が用いられる。また、コンテンツのネットワーク上の場所を特定する手段としては例えばＵＲＬといった手段が用いられる。ムーブ用のコンテンツとレンダリング用のコンテンツはＵＲＬで区別されていてもよい。

鍵選択処理部３８は、コンテンツ選択部３６からのコンテンツ要求がムーブ要求であるかレンダリング要求であるかを判別し、ムーブ要求であれば、ムーブ鍵ラベルを特定して送信装置に対してコンテンツ要求を送信する。一方、レンダリング要求であれば、何もつけずにコンテンツ要求を送信する。すなわち、送信装置からコンテンツを取得する際には、コンテンツ選択部３６から対応するコンテンツのＵＲＬを取得し、鍵選択処理部１８は当該ＵＲＬに対して例えばＨＴＴＰプロトコルでＧＥＴリクエストを送信し、送信装置からコンテンツを取得する。

暗号処理部４０は共通鍵またはムーブ鍵を使ってコンテンツの復号化を行う。

図４は本実施形態に係るコンテンツ送受信システムの処理手順を示すシーケンス図である。本実施形態では、送信装置１００と受信装置１０２との間に３つの通信コネクションＡ，Ｂ，Ｃが設けられる。コネクションＡはコンテンツ管理に用いられ、コネクションＢは認証・鍵交換に用いられ、コネクションＣはコンテンツ伝送に用いられる。

先ず、受信装置１０２はコネクションＡを用いて送信装置１００に対してコンテンツ検索を要求する（ステップ＃２）。このコンテンツ検索に先立ち、ネットワーク上の送信装置のＩＰアドレスを検索したり、コンテンツ検索を行うメッセージの送信先ＩＰアドレスやポート番号の特定したりする際には、ＵＰｎＰなどのよく知られた方法が用いられる。

送信装置１００はコンテンツ検索の結果としてコンテンツのリストとそのコンテンツのＵＲＬを提示する（ステップ＃４）。このとき、送信装置１００がムーブ用のコンテンツとレンダリング用のコンテンツとをＵＲＬで区別すれば、受信装置１０２はムーブ可能なコンテンツを知ることができる。

尚、コンテンツ検索のプロトコルとしては、ＵＰｎＰ Ｃｏｎｔｅｎｔ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ （ＵＰｎＰ ＣＤＳ）で定められて方法を使ってもよい。なお、コンテンツの場所を示すＵＲＬの付加情報として、受信装置と送信装置が認証・鍵交換を行うための送信装置のＩＰアドレスとＴＣＰポート番号を付与してもよい。また、送信装置が受信装置にコンテンツのリストを提示する際、同一のコンテンツに対して、レンダリング用のアドレスとムーブ用のアドレスを区別してリスティングしてもよい。ムーブ用のアドレスとレンダリング用のアドレスを区別する手段としては、（ａ）コンテンツのアドレスにムーブ用アドレスであることを示す付帯情報を付与する方法、（ｂ）コンテンツのアドレスにムーブ鍵ラベルを付ける方法、などが考えられる。

受信装置１０２は、コンテンツのリストから所望のコンテンツを選択する。ここでは、ムーブ用コンテンツを選択したとする。受信装置は、コンテンツの場所の付加情報から認証・鍵交換処理を行うべき送信装置のアドレスとポート番号を取得し、コネクションＢを用いて送信装置に対してムーブ用の認証・鍵交換処理開始を要求する（ステップ＃６）。認証・鍵交換処理が成功すれば、送信装置１００は各受信装置との間でコンテンツを暗号化するのに用いる秘密鍵である共通鍵Ｋｘ、ムーブ鍵Ｋｘｍを生成し、受信装置に対して共通鍵Ｋｘやムーブ鍵Ｋｘｍをラベル情報とともに送信する（ステップ＃８）。

セキュリティ確保のため、認証・鍵交換処理部３４は、ムーブ鍵Ｋｘｍとして毎回異なる値を生成し、受信装置が同一であるか否かに関わらず、生成したムーブ鍵Ｋｘｍをネットワーク上に一回しか送信しないことが望ましい。

認証・鍵交換によって受信装置が以前認証・鍵交換を行った装置と同一であると確認できる場合には同じムーブ鍵Ｋｘｍを送信してもよいが、少なくとも異なる受信装置に対しては同じムーブ鍵Ｋｘｍは渡さない点が重要である。これにより、ムーブ鍵Ｋｘｍを用いて暗号化したコンテンツは１台の受信装置のみが復号できることを保証できる。

例えば、図２に示す送信装置Ｘが受信装置Ａからはコンテンツａのムーブ要求を、受信装置Ｂからはコンテンツｂのレンダリング要求を受信した場合、受信装置Ａに対しては受信装置Ａに送信したムーブ鍵Ｋｘｍ１を用いてコンテンツａを暗号化し、受信装置Ｂに対しては共通鍵Ｋｘ１でコンテンツｂを暗号化して送信する。

このようにすると、レンダリング用コンテンツｂについては、受信装置Ｂ以外にも共通鍵Ｋｘ１を持つ受信装置Ａ、Ｃが何らかの手段で当該コンテンツを受信することにより復号される可能性がある。しかしながらムーブ用コンテンツａについては、ムーブ鍵Ｋｘｍ１を持つ受信装置Ａでは復号されるが、ムーブ鍵Ｋｘｍ１を持たない受信装置Ｂ、Ｃでは、たとえ受信することができたとしても、復号することはできない。このため、ムーブ対象のコンテンツａが２台以上の受信装置で復号されることを防止することができる。

しかも、送信装置は異なるコンテンツのレンダリング要求とムーブ要求とを同時に受け付けることが可能であるため、セキュリティとユーザの使い勝手の双方を向上させることができる。また、送信装置が複数の受信装置から異なるコンテンツのムーブ要求を受けた場合でも、それぞれの受信装置に送信した鍵を用いて個々のコンテンツを暗号化すればよいため、同時に複数のムーブ送信を実現することができる。

ムーブ鍵ラベルとは、各ムーブ鍵に対応したラベル情報であり、送信装置（例えば、図２の送信装置Ｘ）が複数のムーブ鍵（例えば、Ｋｘｍ１、Ｋｘｍ２、Ｋｘｍ３）を有する場合にそれぞれのムーブ鍵を区別したり、受信装置が複数の送信装置からコンテンツをムーブする際に、どの送信装置とムーブ用認証・鍵交換を行い、どのムーブ鍵を保持しているか、どのムーブ鍵を用いて復号したらよいかを判別したりするために用いる。ムーブ鍵は認証・鍵交換処理によって共有した鍵を用いて暗号化して送信するが、ムーブ鍵ラベルはそれ自体が秘密の値ではないため、平文のままネットワーク上に送信してもよい。

なお、受信装置が送信装置に対してムーブ鍵Ｋｘｍを要求する手段としては、例えば、以下の例が考えられる。

（１）共通鍵を受信するための認証・鍵交換要求（図５の（ａ））とは別に、ムーブ鍵を受信するための認証・鍵交換要求を行う（図５の（ｂ））
（２）共通鍵を受信するための認証・鍵交換要求を行い、一旦共通鍵を受信した後、送信装置へムーブ鍵要求を送信し、共通鍵を暗号化するのと同じ鍵で暗号化されたムーブ鍵を受信する（図６の（ａ））
（３）共通鍵を受信するための認証・鍵交換要求に基づいて、送信装置は共通鍵とムーブ鍵の両方を送信する（図６の（ｂ））
なお、共通鍵のみが受信可能な受信装置や、ムーブ鍵を送信する機能のない送信装置との互換性を考慮し、図６の（ａ）の場合には、受信装置がムーブ鍵要求を送信する前に、図６の（ｂ）の場合には、送信装置が共通鍵・ムーブ鍵を送信する前に、事前に互いの機能を確認してもよい。

また、送信装置のＩＰアドレス等から判断して、送信装置と既に認証・鍵交換を行ってムーブ鍵Ｋｘｍを既に取得していることが分かっている場合には、ムーブ鍵Ｋｘｍの認証・鍵交換の処理はスキップしてもよい。その場合、受信装置が持つムーブ鍵を送信装置が持っているか否かを確認するために、コンテンツ要求に先立ち、受信装置は送信装置に対して問い合わせを行ってもよい。その場合、問い合わせはムーブ鍵ラベルを含み、送信装置はムーブ鍵ラベルが自装置内に格納されているか否かの検索処理を行い、その検索結果を受信装置に返せばよい。

図４に戻り、受信装置１０２がムーブ鍵Ｋｘｍとムーブ鍵ラベルを受信すると、受信装置１０２はコネクションＣを用いて送信装置１００に対してコンテンツのムーブ要求を送信する（ステップ＃１０）。ムーブ要求には当該受信装置がどのムーブ鍵で暗号化されたコンテンツを受信可能かを示すムーブ鍵ラベルが含まれる。ＨＴＴＰプロトコルのムーブ要求（ＧＥＴリクエスト）の一例を以下に示す。５行目がムーブ鍵ラベルを示す。

Content-Type: application/x-dtcp1;
DTCP1HOST=<host>;
DTCP1PORT=<port>;
CONTENTFORMAT=<mimetype>;
DTCPKXM=<exchange_key_label>
送信装置１００はムーブ要求に含まれるムーブ鍵ラベルを見てどのムーブ鍵を用いてコンテンツを暗号化したらよいかを判別し、ムーブ鍵ラベルと合致するムーブ鍵を用いてコンテンツを暗号化し、受信装置１０２に対して送信する（ステップ＃１２）。

送信されるコンテンツのフォーマットを図７に示す。コンテンツは、ヘッダ部５２５２と暗号化コンテンツ部５４から構成されるパックの形で送信される。ヘッダ部５２にはムーブ鍵ラベル５８が含まれる。これ以外にもヘッダ部５２内には、コピー不可、一世代のみコピー可、ムーブ、コピー可などのコンテンツのコピー制御情報５６や、暗号化前コンテンツ部の長さ（コンテンツ長）６０等の情報を入れても良い。

なお、受信装置から指定されたムーブ鍵が送信装置に存在しない場合には、コンテンツの送信を行わず、エラーを返す。また、このムーブ鍵ラベルとは別に、受信装置が送信装置に対して、コンテンツ要求がムーブ要求なのか、レンダリング要求なのかを区別するための付加情報をコンテンツ要求に付けてもよい。付加情報はＵＲＬの引数としてもよいし、リクエストヘッダを新たに定義し、そのパラメタとして挿入してもよい。

送信装置はムーブ送信したコンテンツについて、コンテンツの送信が完了した後、削除もしくは利用不可能（無効）な状態にする。

受信装置は暗号化コンテンツを受信すると、コンテンツのヘッダ部５２に付けられたムーブ鍵ラベル５８と、認証・鍵交換処理部３４が格納するムーブ鍵ラベルを比較し、その値が一致すればコンテンツ復号を開始する。もしも一致しない場合には、コンテンツの受信を中止する。ムーブ鍵ラベルの値が異なる場合とは、送信装置がコンテンツの暗号化に用いたムーブ鍵と、受信装置の持つムーブ鍵の値が異なることを示す。ムーブの場合、送信装置は送信したコンテンツを削除または利用不可能な状態（無効化）にしてしまうので、受信装置がコンテンツを正しく復号できないと、コンテンツは消失してしまう。これを避けるために、コンテンツのヘッダ部５２にムーブ鍵ラベル５８を挿入して、受信装置がコンテンツを正しく復号できるか否かを判定している。

受信装置が受信したコンテンツのヘッダ部５２に含まれるムーブ鍵ラベル５８に基づいて復号可能なコンテンツかどうかを判別する代わりに、送信装置がコンテンツの送信に先立ち、コンテンツ要求に応答するコンテンツ応答を送信し、そのコンテンツ応答の中にムーブ鍵ラベルを含めてもよい。この場合、受信装置はコンテンツ応答の中のムーブ鍵ラベルが自装置が持つムーブ鍵ラベルと一致するか否かを判別する処理を行う。コンテンツ要求がＨＴＴＰプロトコルのＧＥＴリクエストで行われる場合、ムーブ鍵ラベルはＨＴＴＰ Ｒｅｓｐｏｎｓｅヘッダに含めればよい。

このように、受信装置がコンテンツ応答にて復号可能なコンテンツかどうかを判別できるため、仮に受信不可能なコンテンツである場合、受信装置はコンテンツを受信する前にコネクションを切断すれば、送信装置側はコンテンツを送信する前にコネクションを切断できるため、無駄な送信を行うことを防ぐとともに、コンテンツが消失することを防ぐことができる。

図８は送信装置の動作手順を示すフローチャートである。第１の実施形態では、受信装置が送信装置内のどのコンテンツをムーブさせるかを選択するモデルであるため、先ず送信装置１００はコネクションＡで受信装置１０２からのコンテンツ検索要求を受信し（ステップＳ２）、その応答としてコンテンツリストを送信する（ステップＳ４）。

その後、送信装置１００は受信装置１０２からコネクションＢでムーブ用の認証・鍵交換要求を受信し（ステップＳ６）、受信装置１０２と認証・鍵交換処理を行う。送信装置１００は、ステップＳ８で認証・鍵交換処理が成功したか否かを判定する。認証・鍵交換処理が失敗すれば、送信装置１００はエラー処理（その旨を通知するメッセージを受信装置に送信）を行い（ステップＳ１０）、以降の処理は行なわない。

認証・鍵交換が成功すると、送信装置１００は認証・鍵交換によって受信装置１０２と共有した鍵を用いてムーブ鍵を暗号化し、ラベルを付けて暗号化ムーブ鍵をコネクションＢで受信装置１０２に送信する（ステップＳ１２）。

その後送信装置１００は、実際のコンテンツをムーブするためのムーブ要求（ムーブ鍵ラベルを含む）をコネクションＣで受信装置１０２から受信し（ステップＳ１４）、そのムーブ要求に含まれるムーブ鍵ラベルで指定されるムーブ鍵が自装置内に存在するか否かを検索する（ステップＳ１６）。

ムーブ要求に含まれるムーブ鍵ラベルで指定されたムーブ鍵が自装置内に存在しない場合は、送信装置１００はエラー処理（その旨を通知するメッセージを受信装置に送信）を行い（ステップＳ１０）、コンテンツの送信は行なわない。

指定されたムーブ鍵が自装置内に存在する場合は、送信装置１００はそのムーブ鍵を用いてコンテンツを暗号化し（ステップＳ２０）、コネクションＣで暗号化コンテンツを受信装置１０２に送信する（ステップＳ２２）。

図９は受信装置１０２の動作手順を示すフローチャートである。受信装置１０２はコンテンツ検索要求をコネクションＡで送信装置１００に送信し（ステップＳ３２）、その応答として送信装置１００から送信（図８のステップＳ４）されたコンテンツリストを受信する（ステップＳ３４）。

その後、受信装置１０２はムーブ用の認証・鍵交換要求をコネクションＢで送信装置１００に送信し（ステップＳ３６）、認証・鍵交換処理を開始する。受信装置１０２は、ステップＳ３８で認証・鍵交換処理が成功したか否かを判定する。認証・鍵交換処理が失敗と判断した場合は、受信装置１０２はエラー処理（その旨を通知するメッセージを送信装置に送信）を行い（ステップＳ４０）、以降の処理は行なわない。

認証・鍵交換が成功すると受信装置１０２は、送信装置１００が送信（図８のステップＳ１２）した暗号化ムーブ鍵とムーブ鍵ラベルとをコネクションＢで受信する（ステップＳ４２）。受信装置１０２は、受信した暗号化ムーブ鍵を認証・鍵交換によって共有した鍵を用いて復号化し、ムーブ鍵ラベルとともに記憶しておく。

次に、受信装置１０２はコンテンツリストの中からムーブ対象コンテンツを選択し（ステップＳ４４）、送信装置１００と共有しているムーブ鍵に対応するムーブ鍵ラベルとともにムーブ要求をコネクションＣで送信装置１００に送信する（ステップＳ４６）。そして受信装置１０２は、ムーブ要求の応答として送信装置から送信（図８のステップＳ２２）された暗号化コンテンツを受信し（ステップＳ４８）、そのコンテンツのヘッダ部５２に含まれるムーブ鍵ラベルが、自装置の持つムーブ鍵ラベルに一致するか否かを確認する（ステップＳ５０）。

ヘッダ部５２に含まれるムーブ鍵ラベルが自装置の持つムーブ鍵ラベルに一致しない場合は、受信装置１０２はコンテンツ受信用コネクションを切断して（ステップＳ５２）、エラー処理（その旨を通知するメッセージを送信装置に送信）を行い（ステップＳ４０）、以降の処理は行なわない。

ムーブ鍵ラベルが自装置の持つムーブ鍵ラベルと一致する場合は、受信装置１０２は自装置の持つムーブ鍵を使って、送信装置１００からコネクションＣで受信した暗号化コンテンツを復号する（ステップＳ５４）。

以上説明したように、第１実施形態によれば、レンダリング鍵とムーブ鍵を区別し、複数の受信装置に対して同一のレンダリング鍵を配布するが、ムーブ鍵は受信装置毎に別々の鍵を配布するので、コンテンツの不正利用を確実に防止できるとともに、同時にムーブとレンダリングを行うことができ、コンテンツの有効利用を図ることができる。しかも同じ鍵は一度だけしか配布しないので、さらにセキュリティの向上を図ることができる。

つまり、コンテンツをムーブする際、受信可能な受信装置の数を１台に限定し、かつ送信装置はあるコンテンツをムーブ中に、別のコンテンツを別な受信機器に送信することが可能になるため、コンテンツの不正利用を確実に防止できるとともに、コンテンツの有効利用を図ることができる。

また、コンテンツ送受信用、コンテンツ管理用、鍵送受信用のコネクションを別々に接続、使用するので、送受信装置間の伝送中の安全性が高い。

受信装置はムーブコンテンツの受信前にコンテンツの復号に必要なムーブ鍵を格納しているか否か判定し、格納していない場合は、コンテンツの受信を中止し、送信装置はコンテンツ送信後にコンテンツを削除、または無効化するので、誤ってムーブしたコンテンツの消失を防ぐことができる。

さらに、送信装置は鍵と鍵を特定するための鍵ラベルとを受信装置に送信し、受信装置から鍵ラベルにより鍵を指定する要求があった場合にその鍵を用いてコンテンツを暗号化するので、システム全体で複数の鍵の存在を許容することができ、コンテンツの利用態様を増やすことができ、コンテンツの有効利用につながる。

第２の実施形態
第１の実施形態は受信装置側が送信装置側に対してコンテンツをムーブして送信するための要求を送信するモデルであった。第２の実施形態は送信装置側が受信装置側に対してムーブ受信するように要求するモデルである。

図１０は第２実施形態に係る送信装置２００の概略構成を示すブロック図である。図１０に示すように、送信装置２００はコンテンツ供給部１２と、認証・鍵交換処理部１４と、コンテンツ選択部６６と、鍵選択処理部１８と、暗号処理部２０と、ネットワークインターフェース処理部２２と、コンテンツ伝送用コネクション管理部２４と、コンテンツ管理用コネクション管理部２６と、認証・鍵交換用コネクション管理部２８を有する。

コンテンツ供給部１２、認証・鍵交換処理部１４、暗号処理部２０、ネットワークインターフェース処理部２２、コンテンツ伝送用コネクション管理部２４と、コンテンツ管理用コネクション管理部２６と、認証・鍵交換用コネクション管理部２８については、図１と同様の機能を持ち、同様のブロックで構成することができる。

コンテンツ選択部６６は、ムーブ対象のコンテンツを指定し、受信装置に対してコンテンツを受信する準備を整えるよう指示するメッセージを送信する機能を備える。

図１１は第２実施形態に係る受信装置２０２の概略構成を示すブロック図である。図１１に示すように、受信装置２０２はコンテンツ処理部３２と、認証・鍵交換処理部３４と、コンテンツ蓄積管理部６８と、鍵選択処理部３８と、暗号処理部４０と、ネットワークインターフェース部４２と、コンテンツ伝送用コネクション管理部４４と、コンテンツ管理用コネクション管理部４６と、認証・鍵交換用コネクション管理部４８を有する。

コンテンツ処理部３２、認証・鍵交換処理部３４、暗号処理部４０、ネットワークインターフェース処理部４２、コンテンツ伝送用コネクション管理部４４と、コンテンツ管理用コネクション管理部４６と、認証・鍵交換用コネクション管理部４８については、図３と同様の機能を持ち、同様のブロックで構成することができる。

コンテンツ蓄積管理部６８は、コンテンツを受信する準備を整えるよう指示するメッセージを送信装置から受信し、その応答としてコンテンツを蓄積するためのＵＲＬを送信装置に送信する機能を持つ。

図１２は本実施形態に係るコンテンツ送受信システムの処理（ここでは、ムーブ処理とする）手順を示すフローチャートである。本実施形態でも、送信装置２００と受信装置２０２との間に３つの通信コネクションＡ，Ｂ，Ｃがあり、コネクションＡはコンテンツ管理に用いられ、コネクションＢは認証・鍵交換に用いられ、コネクションＣはコンテンツ伝送に用いられる。

第１の実施形態とは異なり、第２の実施形態では、先ず送信装置２００がコネクションＡを用いて受信装置２０２に対してコンテンツを受信するよう指示するためのメッセージ（コンテンツ受信要求）を送信する（ステップ＃２２）。このメッセージには、送信するデータが暗号化したコンテンツであることを示す情報、受信装置２０２と送信装置２００が認証・鍵交換を行うための送信装置のＩＰアドレスとＴＣＰポート番号、ＭＩＭＥ−Ｔｙｐｅなどの暗号化前のコンテンツの種別を表す情報を含めてもよい。なお、このメッセージの送信に先立ち、ネットワークから受信装置を検索するための手段や、メッセージを送信するためのＩＰアドレス、ポート番号の決定には、ＵＰｎＰなどよく知られた方法が用いられる。コンテンツを受信するように指示するメッセージの送信には、例えば以下のようなＵＰｎＰのＣｒｅａｔｅ Ｏｂｊｅｃｔメッセージが用いられる。

Content-Type: application/x-dtcp1;
DTCP1HOST=<host>;
DTCP1PORT=<port>;
CONTENTFORMAT=<mimetype>;
DTCOKXM=NULL
次に、受信装置２０２はコネクションＢを用いて送信装置２００に対してムーブ用の認証・鍵交換処理開始を要求する（ステップ＃２４）。認証・鍵交換処理が成功すると、送信装置２００は各受信装置２０２との間でコンテンツを暗号化するのに用いる秘密鍵である共通鍵Ｋｘ、ムーブ鍵Ｋｘｍを生成し、受信装置２０２に対して共通鍵Ｋｘやムーブ鍵Ｋｘｍを送信する（ステップ＃２６）。なお、第１の実施形態と同様に、ムーブ鍵の送信と同時に、ムーブ鍵を区別するためのムーブ鍵ラベル情報も送信する。認証・鍵交換処理が失敗した場合には、エラー処理を行い、以下の処理は行わない。

認証・鍵交換が終了すると、受信装置２０２はコネクションＢを用いてコンテンツを受信する準備が整ったことを示すコンテンツ受信確認メッセージを送信装置２００に返信する（ステップ＃２８）。このとき、受信装置２０２は返信メッセージの中に、送信装置２００がどのアドレスに対してコンテンツを送信すればよいかを示すアドレス情報と、受信機器２０２が認証・鍵交換処理の結果送信装置から受信したムーブ鍵ラベルを含める。アドレス情報は例えばＵＲＬの形式で示せばよい。返信メッセージの一例を以下に示す。

<service>://<host>:<port>/<path>/<FileName>.<FileExtention>?CONTENTPROTECTIONTYPE=DTCP1&DTCPKXM=<exchange_key_label>
その後、送信装置２００は、コンテンツ受信確認メッセージにて指定されたアドレスに対してコンテンツの送信を開始する（ステップ＃３０、＃３２）。送信装置２００は送信したコンテンツについて、削除もしくは利用不可能な状態にする。コンテンツの暗号化に用いる鍵には、コンテンツ受信確認メッセージに含まれるムーブ鍵ラベルに対応するムーブ鍵を用いる。

もし、コンテンツ受信確認メッセージに含まれるムーブ鍵ラベルに対応するムーブ鍵が存在しない場合には、受信装置に対してエラーメッセージを送信する。コンテンツの形式は図７に示したフォーマットでよい。すなわち、コンテンツのヘッダ部５２にムーブ鍵ラベル５８をつけ、そのムーブ鍵ラベル５８に対応するムーブ鍵を使ってコンテンツを暗号化する。

コンテンツの送信にはＨＴＴＰプロトコルのＰＯＳＴリクエストがを用いる。このとき、ＨＴＴＰヘッダ情報として、ムーブ鍵ラベルをつけてＰＯＳＴリクエストを送信してもよい。ＰＯＳＴリクエストの一例を以下に示す。

Content-type: application/x-dtcp1;
DTCP1HOST=<host>;
DTCP1PORT=<port>;
CONTENTFORMAT=<mimetype>;
DTCPKXM=<exchange_key_label>
受信装置２０２は、コンテンツのヘッダ部５２もしくはＰＯＳＴリクエスト内のＨＴＴＰヘッダに定義されたムーブ鍵ラベルと、認証・鍵交換処理の結果、送信装置から送信され自装置が格納するムーブ鍵ラベルの値が一致するかどうかを比較し、一致している場合にはムーブ鍵ラベルに対応するムーブ鍵にてコンテンツを復号する。一致しない場合には、コンテンツの受信を中止し、コンテンツ送受信用のコネクションＣを切断する。

ムーブ鍵ラベルの値が異なる場合とは、送信装置がコンテンツの暗号化に用いたムーブ鍵と、受信装置の持つムーブ鍵の値が異なる場合のことである。第１の実施形態と同様に、コンテンツの暗号鍵と復号鍵が異なることにより、コンテンツが消失してしまうことを避けるために、ムーブ鍵ラベルを使って鍵が一致することを確認することで、コンテンツが不用意に消失することを避けることができる。

なお、第２の実施形態では、ムーブ対象のコンテンツを選択する処理は送信装置側で行われる。ユーザインターフェース上の観点から、ムーブするコンテンツの選択権はコンテンツを蓄積している側、すなわち送信装置側にあることが好ましい。従来の手法では認証・鍵交換処理の開始は受信装置側にあり、送信装置側から認証・鍵交換を開始することができない。しかし、本実施形態では、ムーブ対象のコンテンツを選択する権利を送信装置側に保持しつつ、受信装置がコンテンツ受信要求をトリガーとして認証・鍵交換処理を開始することでこの問題を解決している。さらに、ムーブ鍵ラベルを用いて復号不可能なコンテンツをムーブすることを防止することにより、コンテンツの不要な消失を避けることができる。

図１３は送信装置の動作手順を示すフローチャートである。第２の実施形態では、送信装置が自装置内のどのコンテンツをムーブさせるかを選択するモデルであるため、送信装置２００は、先ずどのコンテンツをムーブするのか決定する（ステップＳ５２)。

その後、受信装置２０２に対してそのコンテンツを受信する準備を整えるよう指示するために、送信装置２００はコネクションＡによりコンテンツ受信要求を送信する（ステップＳ５４)。その後、送信装置２００はコネクションＢにより受信装置が送信する認証・鍵交換要求を受信し（ステップＳ５６)、受信装置と認証・鍵交換処理を行う。このように認証・鍵交換処理をコンテンツ受信要求送信直後（コンテンツ受信確認の送信前）に開始することにより、送信装置２００はコンテンツ受信確認の受信直後にムーブ要求、暗号化コンテンツを送信することができ、待ち時間（認証・鍵交換）無くコンテンツの送信を開始することができる。

送信装置２００は、ステップＳ５８で認証・鍵交換処理が成功したか否かを判定する。認証・鍵交換処理が失敗すれば、送信装置２００はエラー処理を行い（その旨を通知するメッセージを受信装置に送信し）（ステップＳ６０）、以降の処理は行なわない。

認証・鍵交換が成功すると、送信装置２００は認証・鍵交換によって共有した鍵を用いて暗号化したムーブ鍵を生成し、ムーブ鍵ラベルを付けて暗号化ムーブ鍵をコネクションＢにより受信装置２０２に送信する（ステップＳ６２）。

その後送信装置２００は、コンテンツ受信要求に対応する応答メッセージとしてのコンテンツ受信確認を受信装置２０２から受信する（ステップＳ６４）。この応答メッセージには、コンテンツを送信する先の（コネクションＣの）アドレス情報と、受信機器が持つムーブ鍵ラベルが含まれている。送信装置２００は、その応答メッセージに含まれるムーブ鍵ラベルで指定されたムーブ鍵が自装置内に存在するか検索する（ステップＳ６６）。

検索に失敗すれば、送信装置２００は、その旨を通知するメッセージを受信装置２０２に送信し、エラー処理を行い（その旨を通知するメッセージを受信装置に送信し）（ステップＳ６８）、コンテンツの送信は行わない。検索に成功すれば、送信装置２００はそのムーブ鍵を用いてコンテンツを暗号化し（ステップＳ７０）、受信装置に送信する（ステップＳ７２）。

図１４は受信装置２０２の動作手順を示すフローチャートである。受信装置２０２は送信装置２００から送信（図１３のステップＳ５４）されたコンテンツ受信要求をコネクションＡで受信する（ステップＳ８２）。受信装置２０２は、ステップＳ８４でムーブ鍵を送信装置と既に共有しているか否かを判定する。

もし、送信装置２００とムーブ鍵を既に共有していれば、受信装置２０２はコンテンツ受信要求の応答メッセージとしてコンテンツ受信確認を送信する（ステップＳ９４）。送信装置とムーブ鍵を既に共有していなければ、受信装置はコネクションＢで認証・鍵交換要求を送信し（ステップＳ８６）、認証・鍵交換処理を開始する。

ステップＳ８８で受信装置２０２は認証・鍵交換処理が成功したか否かを判定する。認証・鍵交換処理が失敗すれば、受信装置２０２はエラー処理（その旨を通知するメッセージを送信装置に送信）を行い（ステップＳ９０）、以降の処理は行なわない。

認証・鍵交換が成功すると、受信装置２０２は送信装置２００が送信（図１３のステップＳ６２）した暗号化ムーブ鍵とムーブ鍵ラベルとをコネクションＢで受信する（ステップＳ９２）。認証・鍵交換によって共有した鍵を用いて暗号化ムーブ鍵を復号化し、ムーブ鍵をムーブ鍵ラベルとともに認証・鍵交換処理部３４に格納する。

その後、受信装置２０２はコンテンツ受信要求の応答メッセージとしてのコンテンツ受信確認を送信する（ステップＳ９４）。次に受信装置２０２は、コンテンツ受信確認にて示したアドレスに対するコンテンツのムーブ要求を送信装置２００から受信する（ステップＳ９６）。このムーブ要求にはムーブ鍵ラベルが含まれる。このムーブ鍵ラベルか、コンテンツムーブ要求に引き続き受信するコンテンツのヘッダ部５２に含まれるムーブ鍵ラベルが、自装置の持つムーブ鍵ラベルに一致するか否かを確認する（ステップＳ１００）。自装置の持つムーブ鍵ラベルに一致しない場合は、コンテンツを復号できないので、ムーブを中止させるために、受信装置２０２はコンテンツ受信用コネクションＣを切断してコンテンツの受信を中止し（ステップＳ１０４）、エラー処理を行い（ステップＳ９０）、以降の処理は行なわない。自装置の持つムーブ鍵ラベルに一致する場合は、受信装置２０２はムーブ鍵を用いてコンテンツを復号する（ステップＳ１０２）。

以上説明したように、第２実施形態によれば、第１実施形態の効果に加えて、送信装置からのコンテンツ受信要求をトリガーとして受信装置から認証・鍵交換処理を開始することにより、コンテンツを蓄積している送信装置にコンテンツの選択権を与え、送信装置をクライアントとすることができる効果を奏することができる。また、コンテンツ受信要求を送信後、その確認を待たずに、認証・鍵交換を開始し、認証・鍵交換の終了後にコンテンツ受信確認を受信することにより、送信装置はコンテンツ受信確認の受信直後にムーブ要求、暗号化コンテンツを送信することができ、待ち時間（認証・鍵交換）無くコンテンツの送信を開始することができる。

上述した実施形態で説明した送信装置、受信装置は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ソフトウェアで構成する場合には、情報処理装置の少なくとも一部の機能を実現するプログラムをフロッピー（登録商標）ディスクやＣＤ−ＲＯＭ等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の携帯可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。

また、送信装置、受信装置の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線（無線通信も含む）を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。また、レンダリング要求が生じた時は、上述の動作でムーブ用とある説明をレンダリング用と変えればよい。

第１の実施形態に係る送信装置の概略構成を示すブロック図。 第１の実施形態に係る送信装置と受信装置の鍵共有の状態を示すブロック図。 第１の実施形態に係る受信装置の概略構成を示すブロック図。 第１の実施形態に係るコンテンツ送受信システムの全体処理手順を示すフローチャート。 第１の実施形態に係るコンテンツ送受信システムの認証・鍵交換に関する処理手順を示すフローチャート。 第１の実施形態に係るコンテンツ送受信システムの認証・鍵交換に関する処理手順を示すフローチャート。 送信装置が暗号化コンテンツを受信装置に伝送する際の転送フォーマットの一例を示す図。 第１の実施形態に係る送信装置のフローチャートの一例を示す図。 第１の実施形態に係る受信装置のフローチャートの一例を示す図。 第２の実施形態に係る送信装置の概略構成を示すブロック図。 第２の実施形態に係る受信装置の概略構成を示すブロック図。 第２の実施形態に係るコンテンツ送受信システムの全体処理手順を示すフローチャート。 第２の実施形態に係る送信装置のフローチャートの一例を示す図。 第２の実施形態に係る受信装置のフローチャートの一例を示す図。

１２…コンテンツ供給部、１４…認証・鍵交換処理部と、１６…コンテンツリスト管理部、１８…鍵選択処理部、２０…暗号処理部、２２…ネットワークインターフェース処理部、２４…コンテンツ伝送用コネクション管理部、２６…コンテンツ管理用コネクション管理部、２８…認証・鍵交換用コネクション管理部。

Claims (7)

1. 送信装置から第１受信装置へコンテンツを送信する送信方法において、
   前記送信装置が前記第１受信装置へコンテンツ受信要求を送信する第１ステップと、
   前記第１受信装置が前記第１受信装置を含む複数の受信装置に共通なレンダリング用の第１鍵あるいは前記第１受信装置に固有なムーブ用の第２鍵のための認証、鍵交換の開始要求を前記送信装置へ送信する第２ステップと、
   前記送信装置が上記認証、鍵交換により得られた前記第１鍵あるいは第２鍵を前記第１受信装置へ送信する第３ステップと、
   前記第１受信装置が上記認証、鍵交換により得られた鍵のラベルを含むコンテンツ受信確認を前記送信装置へ送信する第４ステップと、
   前記送信装置が前記コンテンツ受信確認に含まれるラベルに応じた鍵を用いてコンテンツを暗号化して前記第１受信装置へ送信する第５ステップと、
   を具備する送信方法。
2. 前記第５ステップは前記コンテンツ受信確認に含まれるラベルに応じた鍵が前記送信装置内に存在していない場合はその旨の通知を前記第１受信装置へ送信するサブステップを具備することを特徴とする請求項１記載の送信方法。
3. 前記送信装置が暗号化コンテンツの送信の前に暗号化の鍵のラベルを前記第１受信装置へ送信する第６ステップと、
   前記第６ステップで前記送信装置から送信されたラベルに応じた鍵が前記第１受信装置内に存在していない場合はその旨の通知を前記送信装置へ送信する第７ステップをさらに具備することを特徴とする請求項１記載の送信方法。
4. 第１受信装置へコンテンツ受信要求を送信する第１手段と、
   前記第１受信装置から送信された前記第１受信装置を含む複数の受信装置に共通なレンダリング用の第１鍵あるいは前記第１受信装置に固有なムーブ用の第２鍵のための認証、鍵交換の開始要求を受信する第２手段と、
   上記認証、鍵交換により得られた前記第１鍵あるいは前記第２鍵を前記第１受信装置へ送信する第３手段と、
   前記第１受信装置から送信された上記認証、鍵交換により得られた鍵のラベルを含むコンテンツ受信確認を受信する第４手段と、
   前記コンテンツ受信確認に含まれるラベルに応じた鍵を用いてコンテンツを暗号化して前記第１受信装置へ送信する第５手段と、
   を具備する送信装置。
5. 前記第５手段は前記コンテンツ受信確認に含まれるラベルに応じた鍵を有していない場合はその旨の通知を前記第１受信装置へ送信することを特徴とする請求項４記載の送信装置。
6. 暗号化コンテンツの送信の前に暗号化の鍵のラベルを前記第１受信装置へ送信する第６手段と、
   前記第６手段により送信されたラベルに応じた鍵が前記第１受信装置内に存在していない旨の通知を前記第１受信装置から受信する第７手段をさらに具備することを特徴とする請求項４記載の送信装置。
7. 送信装置から送信されたコンテンツ受信要求を受信する第１手段と、
   複数の受信装置に共通なレンダリング用の第１鍵あるいは当該受信装置に固有なムーブ用の第２鍵のための認証、鍵交換の開始要求を前記送信装置へ送信する第２手段と、
   上記認証、鍵交換により得られた前記第１鍵または第２鍵を前記送信装置から受信する第３手段と、
   上記認証、鍵交換により得られた鍵のラベルを含むコンテンツ受信確認を前記送信装置へ送信する第４手段と、
   前記コンテンツ受信確認に含まれるラベルに応じた鍵を用いて暗号化されたコンテンツを前記送信装置から受信する第５手段と、
   を具備する受信装置。

Images