JP6257497B2 - コンテンツ伝送装置並びにシンク機器 - Google Patents

Description

本発明は、コンテンツの伝送における不正利用を防止する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに係り、特に、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換（ＡＫＥ）アルゴリズムに従って交換して暗号化コンテンツを伝送する通信システム、通信装置及び通信方法、並びにコンピューター・プログラムに関する。

従来、放送コンテンツやパッケージ・メディア中のコンテンツは、コンテンツ利用装置や再生機器が設置された場所、又は、これらの機器とホームネットワーク経由で接続された機器で利用すること（以下、「ローカル・アクセス（ＬＡ）」とも呼ぶ）が基本であった。例えば、屋外から携帯機器で上記のコンテンツ利用装置や再生機器と接続し、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの外部ネットワーク経由の伝送を伴ってコンテンツを利用すること（以下、「リモート・アクセス（ＲＡ）」とも呼ぶ）は、通信路やコーデックなどの技術的な観点から困難であった。しかし、将来的には、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）やＷｉＭＡＸ（Ｗｏｒｌｄ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）といったデータ通信技術、並びに、Ｈ．２６４などの高圧縮コーデックの普及が見込まれ、これらを活用することでリモート・アクセスの実現可能性が見えてくる。例えば、ユーザーが出先から自宅のサーバーにリモート・アクセスして、コンテンツを再生するという使い方である。

ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。とりわけ、リモート・アクセスにおいては、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用を防止し、コンテンツの著作権を保護する必要がある。

ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）が挙げられる。ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどである。

また、ＩＰネットワークに移植したＤＴＣＰ技術、すなわちＤＴＣＰ−ＩＰ（ＤＴＣＰ ｍａｐｐｉｎｇ ｔｏ ＩＰ）によれば、家庭内においてもディジタル・コンテンツをＩＰネットワーク経由で流通させることができる。現在のＤＴＣＰ−ＩＰ（ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｒｅｖｉｓｉｏｎ １．２）は、主にコンテンツの家庭内のみの利用を確保することを意図し、ＡＫＥコマンドに対し往復遅延時間（ＲＴＴ：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）や、ＩＰルーターのホップ回数（ＴＴＬ：Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）に制限を設定している。

例えば、ＳｏｕｒｃｅがＤＴＣＰ−ＩＰ認証を開始してから終了する直前までの間、受信した各ＡＫＥコマンドを監視し続け、ＴＴＬ値の最大値を更新し続け、認証手続きが終了する直前にＴＴＬ値の最大値をチェックし、この最大値が３以下であれば鍵交換して認証手続きを完了するが、３を超えると、最終段階の処理を行なわずに認証手続きを終わらせる情報通信システムについて提案がなされている（例えば、特許文献１を参照のこと）。

また、コンテンツのオーナーは、コンテンツの不正利用を制限するために、１つのコンテンツ提供装置（Ｓｏｕｒｃｅ）が同時に多数のコンテンツ利用装置（Ｓｉｎｋ）にコンテンツ伝送を行なうことを禁止する可能性がある。

これに対し、コンテンツを利用するユーザーは、複数のコンテンツ利用装置を状況に応じて使い分けたり、家庭内に設置された１台のコンテンツ提供装置を家族で共用したりすることもあり得る。このような利用形態において、家庭内の１台のコンテンツ提供装置から複数のコンテンツ利用装置にコンテンツ伝送を行なうことはコンテンツの正当な利用の範囲内であり、上記のようにコンテンツのオーナーが台数制限を設定してコンテンツ伝送を禁止するのは、ユーザーのコンテンツ利用を不当に制限することになる。

特開２００７−３６３５１号公報

本発明の目的は、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換アルゴリズムに従って交換して暗号化コンテンツを好適に伝送することができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。

本発明のさらなる目的は、著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なうことができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することにある。

本願は、上記課題を参酌してなされたものであり、請求項１に記載の発明は、
コンテンツを提供するコンテンツ提供装置とコンテンツを利用する１以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムであって、
コンテンツ提供装置とコンテンツ利用装置の間で相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
コンテンツ提供装置が各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録手段と、
コンテンツ利用装置がコンテンツ提供装置に鍵ＩＤを含んだ鍵寿命管理コマンドを定期的に送信している間だけ、当該鍵ＩＤの情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信システムである。

但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。

また、本願の請求項２に記載の発明は、
コンテンツの提供先となる１以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録手段と、
コンテンツ利用装置から鍵ＩＤを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵ＩＤに対応する情報を前記鍵記録手段に維持する鍵管理手段と、
を具備する通信装置である。

本願の請求項３に記載の発明によれば、請求項２に記載の通信装置の鍵管理手段は、鍵寿命管理コマンドを所定の受信周期で受信できなかった鍵ＩＤに対応する情報を前記鍵記録手段から破棄するように構成されている。

本願の請求項４に記載の発明によれば、請求項２に記載の通信装置の鍵管理手段は、コンテンツ利用装置から鍵寿命管理コマンドを受信したことに応答して、受信した鍵寿命管理コマンドに含まれる鍵ＩＤに対応する情報が前記鍵記録手段に維持されているときには鍵が有効であることを示すレスポンスを返信し、対応する情報が前記鍵記録手段から破棄した後であれば鍵が無効であることを示すレスポンスを返信するように構成されている。

本願の請求項５に記載の発明によれば、請求項２に記載の通信装置の鍵管理手段は、鍵の破棄を指示する情報がセットされた鍵寿命管理コマンドを受信したことに応答して、対応する鍵の情報を前記鍵管理手段から破棄するように構成されている。

本願の請求項６に記載の発明によれば、請求項２に記載の通信装置は、鍵交換するコンテンツ利用装置の事前登録を行なう登録手段をさらに備えている。そして、鍵管理手段は、前記登録手段に事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信するように構成されている。

また、本願の請求項７に記載の発明は、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段と、
前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵ＩＤを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段と、
を具備する通信装置である。

本願の請求項８に記載の発明によれば、請求項７に記載の通信装置の鍵寿命管理手段は、鍵が不要になったときに、鍵の破棄を指示する情報をセットした鍵寿命管理コマンドを送信するように構成されている。

また、本願の請求項９に記載の発明は、
コンテンツの提供先となる１以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録ステップと、
コンテンツ利用装置から鍵ＩＤを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵ＩＤに対応する情報を前記鍵記録手段に維持する鍵管理ステップと、
を有する通信方法である。

また、本願の請求項１０に記載の発明は、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換ステップと、
前記相互認証及び鍵交換ステップにおいてコンテンツ提供装置から渡された鍵を特定する鍵ＩＤを含んだ鍵寿命管理コマンドを送信する鍵寿命管理ステップと、
を有する通信方法である。

また、本願の請求項１１に記載の発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する１以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ提供装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツの提供先となる１以上のコンテンツ利用装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
各コンテンツ利用装置に渡した鍵を、鍵を特定する鍵ＩＤ及びコンテンツ利用装置を特定する機器ＩＤと組み合わせて記録する鍵記録手段、
コンテンツ利用装置から鍵ＩＤを含んだ鍵寿命管理コマンドを所定の受信周期で受信している間だけ、当該鍵ＩＤに対応する情報を前記鍵記録手段に維持する鍵管理手段、
として機能させるためのコンピューター・プログラムである。

また、本願の請求項１２に記載の発明は、コンテンツを提供するコンテンツ提供装置とコンテンツを利用する１以上のコンテンツ利用装置の間でコンテンツ伝送のための通信を行なう通信システムにおいて、コンテンツ利用装置として動作するための処理をコンピューター上で実行するようにコンピューター可読形式で記述されたコンピューター・プログラムであって、前記コンピューターを、
コンテンツの提供元となるコンテンツ提供装置との間で、相互認証とコンテンツの暗号化のための鍵を交換する相互認証及び鍵交換手段、
前記相互認証及び鍵交換手段によりコンテンツ提供装置から渡された鍵を特定する鍵ＩＤを含んだ鍵寿命管理コマンドを送信する鍵寿命管理手段、
として機能させるためのコンピューター・プログラムである。

本願の請求項１１、１２に係る各コンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項１１、１２に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、それぞれ本願の請求項２、７に係る通信装置と同様の作用効果を得ることができる。

本発明によれば、著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なうことができる、優れた通信システム、通信装置及び通信方法、並びにコンピューター・プログラムを提供することができる。

本願の請求項１、２、３、７、９乃至１２に記載の発明によれば、コンテンツ利用装置は、コンテンツ提供装置へ、鍵ＩＤを含んだ鍵寿命管理コマンドを所定の送信周期毎に送信し、コンテンツ提供装置は、鍵寿命管理コマンドを所定の受信周期毎に受信できている期間だけ対応する鍵を維持するので、コンテンツ提供装置がコンテンツ伝送を同時に行なえるコンテンツ利用装置の台数を所定数以下に制限することができる。

本願の請求項に記載４の発明によれば、コンテンツ提供装置は、鍵寿命管理コマンドを受信したことに応答して、対応する鍵を維持しているときには、鍵が有効であることを示すレスポンスを返信する。また、所定の受信周期で鍵寿命管理コマンドを受信できなかったことにより対応する鍵を破棄した後に、コマンドを受信したときには、鍵が無効であることを示すレスポンスを返す。したがって、コンテンツ利用装置は、自分が持つ鍵の現在の状況を確認することができる。

本願の請求項５、８に記載の発明によれば、コンテンツ利用装置は不要になった鍵に対応する鍵寿命管理コマンドに不要である旨の情報をセットし、コンテンツ提供装置は、鍵が不要である旨の情報がセットされた鍵寿命管理コマンドを受信したことに応答して対応する鍵を破棄するので、台数の上限以内で他のコンテンツ利用装置と新たに鍵交換を行なうことができるようになる。

本願の請求項６に記載の発明によれば、コンテンツ提供装置は、コンテンツのオーナーの求めなどに応じて、鍵交換するコンテンツ利用装置の事前登録を行なうことができる。コンテンツ提供装置は、事前登録されていないコンテンツ利用装置から鍵寿命コマンドを受信したことに応答して、未登録であることを示すレスポンスを返信するので、コンテンツ利用装置は自分が未登録であることを認識することができる。

本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。

図１は、本発明に係る通信システムの一構成例を模式的に示した図である。 図２は、本発明に係る通信システムの他の構成例を模式的に示した図である。 図３は、コンテンツ提供装置１０の機能的構成を模式的に示した図である。 図４は、コンテンツ利用装置２０の機能的構成を模式的に示した図である。 図５は、ＳｏｕｒｃｅとＳｉｎｋの間でＤＴＣＰ−ＩＰにより暗号化コンテンツ伝送を行なう仕組みを説明するための図である。 図６は、ＳｏｕｒｃｅとＳｉｎｋ間で現行のＤＴＣＰ−ＩＰに従って行なわれる、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンスを示した図である。 図７は、コンテンツ提供装置に相当するＳｏｕｒｃｅとコンテンツ利用装置に相当するＳｉｎｋ間で行なわれる、コンテンツ伝送を同時に行なえるコンテンツ利用装置の台数制限を含んだ相互認証及び鍵交換の動作シーケンスを示した図である。 図８は、接続テーブルの更新処理の一例を示した図である。 図９は、ＫＥＥＰ＿ＡＬＩＶＥコマンドのフォーマット例を示した図である。 図１０は、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれる、交換鍵Ｋｒの寿命更新を行なう動作シーケンス例を示した図である。 図１１は、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれる、交換鍵Ｋｒの寿命更新を行なう他の動作シーケンス例を示した図である。

以下、図面を参照しながら本発明の実施形態について詳細に説明する。

本発明は、ＷＡＮなどの外部ネットワークを経由したリモート・アクセス（ＲＡ）を通じてコンテンツを安全に伝送する通信システムに関するものである。同通信システムは、基本的に、リモート・アクセスによりコンテンツを提供するサーバ（ＲＡ−Ｓｏｕｒｃｅ）と、リモート・アクセスによりコンテンツを要求するクライアント（ＲＡ−Ｓｉｎｋ）からなる。本明細書では、リモート・アクセス時に行なうＡＫＥ手続きを、「ＲＡ−ＡＫＥ」と呼ぶことにする。以下、図面を参照しながら本発明の実施形態について詳細に説明する。

図１には、本発明に係る通信システムの一構成例を模式的に示している。図示の通信システムでは、ＲＡ−Ｓｏｕｒｃｅに相当するコンテンツ提供装置１０が家庭内に設置され、ＲＡ−Ｓｉｎｋに相当するコンテンツ利用装置２０が屋外にいる。そして、コンテンツ利用装置２０は、携帯電話のような通信機能によってコンテンツ提供装置１０に対してリモート・アクセスする。

コンテンツ提供装置１０は、一般にルーター３０とモデム４０経由でＷＡＮ５０などの外部ネットワークに接続される。ＷＡＮ５０は例えばインターネットである。ルーター３０には、ＷＡＮ５０側のＩＰアドレスが、ユーザーが加入するＩｎｔｅｎｅｔ Ａｃｃｓｅｓｓ Ｓｅｒｖｉｃｅ（ＩＡＳ）プロバイダー６０から割り当てられる。また、コンテンツ利用装置２０も、基本的にこのＩＰアドレスにアクセスする。ルーター３０は、コンテンツ提供装置１０にはプライベートＩＰアドレスを割り当て、ＷＡＮ５０からのアクセスについてはポート・フォワーディングによって通信を中継する。なお、ルーター３０に割り当てられるＩＰアドレスは、ＩＡＳプロバイダー６０によって更新される場合があるが、そのようなケースではＤＤＮＳサービス７０を用い、ルーター３０乃至コンテンツ提供装置１０のＤＤＮＳ（Ｄｙｎａｍｉｃ ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ））機能を使うことで対応できる。

また、図２には、本発明に係る通信システムの他の構成例を模式的に示している。図示の通信システムでは、ＲＡ−Ｓｉｎｋに相当するコンテンツ利用装置２０も家庭内に設置され、ルーター３１とモデム４１経由でＷＡＮ５０に接続されている。コンテンツ利用装置２０から発信されるＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）通信は、ルーター３１のＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）機能によってアドレス変換されるが、それ以外は図１の場合と同様である。

図３には、コンテンツ提供装置１０の機能的構成を模式的に示している。コンテンツ提供装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、コンテンツ受信／再生部１２と、通信部１３と、記憶部１４と、タイマー１５を備えるが、ＲＡ−Ｓｏｕｒｃｅとして機能して、リモート・アクセスでコンテンツを送信する。

コンテンツ受信／再生部１２は、放送受信機能や、パッケージ・メディア再生機能を備えている。ＣＰＵ１１は、コンテンツ受信／再生部１２で得られるコンテンツについて、リモート・アクセス可能なものを適切な保護を施した後に、通信部１３を通じて、ＲＡ−ＡＫＥにより相互認証及び鍵交換を行なったＲＡ−Ｓｉｎｋ（コンテンツ利用装置２０）に送信する。

記憶部１４には、後述の登録処理によって記憶することになったＲＡ−Ｓｉｎｋの識別情報や、ＲＡ−ＡＫＥを通じてＲＡ−Ｓｉｎｋと共有したリモート・アクセス用の交換鍵とその交換鍵の識別情報（以下、「鍵ＩＤ」とも呼ぶ）などが記憶される。本実施形態では、同時に登録できる交換鍵及び鍵ＩＤの組はｎ個に制限される（但し、ｎは正の整数）。後述する接続テーブルや受信機器テーブルも、記憶部１４に保存される。また、記憶部１４は、コンテンツ受信／再生部１２で得たコンテンツを蓄積する用途で用いることもできる。

タイマー１５は、リモート・アクセス可能なコンテンツを扱う際に、時間管理が必要となる場合（例えば、後述するように、ＲＡ−Ｓｉｎｋからの鍵ＩＤの受信周期を管理する場合）に使われる。

図４には、コンテンツ利用装置２０の機能的構成を模式的に示している。コンテンツ利用装置２０は、ＣＰＵ２１と、通信部２２と、コンテンツ出力部２３と、記憶部２４を備えるが、ＲＡ−Ｓｉｎｋとして機能して、リモート・アクセスでコンテンツを受信する。

ＲＡ−Ｓｉｎｋとしてのコンテンツ利用装置２０は、通信部２２を通じてＲＡ−Ｓｏｕｒｃｅ（コンテンツ提供装置１０）に対して後述する交換鍵及び鍵ＩＤの登録処理を行なう他、ＲＡ−ＡＫＥを行なってＲＡ−Ｓｏｕｒｃｅから交換鍵を取得して記憶部２４に保持するとともに、その鍵を基に算出する暗号鍵でＲＡ−Ｓｏｕｒｃｅから得た暗号化コンテンツを復号して、コンテンツ出力部２３からコンテンツを出力する。記憶部２４は、ＲＡ−Ｓｏｕｒｃｅから受け取った交換鍵やコンテンツを蓄積する用途で用いられる。

タイマー２５は、リモート・アクセス可能なコンテンツを扱う際に、時間管理が必要となる場合（例えば、後述するように、ＲＡ−Ｓｏｕｒｃｅからの鍵ＩＤの送信周期を管理する場合）に使われる。

以下の説明では、交換鍵から暗号鍵を算出する方法はＤＴＣＰ−ＩＰに従うものとする（但し、本発明の要旨は必ずしもこの方法には限定されない）。

ここで、コンテンツ提供装置に相当するＳｏｕｒｃｅとコンテンツ利用装置に相当するＳｉｎｋの間でＤＴＣＰ−ＩＰにより暗号化コンテンツ伝送を行なう仕組みについて、図５を参照しながら説明しておく（ＲＡ−ＳｏｕｒｃｅとＲＡ−Ｓｉｎｋ間での仕組みも同様であると理解されたい）。コンテンツ伝送の形態は、Ｓｏｕｒｃｅ上のコンテンツをＳｉｎｋにコピーする方法と、ＳｏｕｒｃｅからＳｉｎｋへコンテンツを移動してＳｏｕｒｃｅにコンテンツを残さない方法があるが（周知）、同図では前者のコピーによるコンテンツ伝送方法を前提にして説明する。

ＳｏｕｒｃｅとＳｉｎｋは、まず１つのＴＣＰ／ＩＰコネクションを確立して、機器同士の認証（ＡＫＥ手続き）を行なう。ＤＴＣＰ準拠機器には、ＤＴＬＡ（前述）により発行された機器証明書が埋め込まれている。ＡＫＥ手続きでは、互いが正規のＤＴＣＰ準拠機器であることを確かめた後、認証鍵Ｋ_authをＳｏｕｒｃｅとＳｉｎｋで共有することができる。

ＡＫＥ手続きが成功すると、Ｓｏｕｒｃｅはコンテンツ鍵Ｋ_cの種となる交換鍵Ｋ_xを生成し、認証鍵Ｋ_authで暗号化してＳｉｎｋに送る。Ｓｏｕｒｃｅ及びＳｉｎｋそれぞれにおいて、交換鍵Ｋ_xに対して所定の演算処理を適用することによって、コンテンツ伝送時にコンテンツを暗号化するために使用されるコンテンツ鍵Ｋ_cを生成することができる。

そして、ＤＴＣＰ準拠の機器間でＡＫＥによる認証及び鍵交換手続きが済んだ後、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）などのプロトコルを利用してコンテンツ伝送が開始される。図示の例では、ＨＴＴＰの手続きに従ってコンテンツ伝送が行なわれる。その際、ＡＫＥ手続きのためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションが作成される（すなわち、ＳｏｕｒｃｅとＳｉｎｋはそれぞれ、ＡＫＥ手続き用とコンテンツ伝送用に個別のソケット情報（ＩＰアドレスとポート番号の組み合わせ）を持つ）。

ＨＴＴＰプロトコルに従ってコンテンツ伝送を行なうには、ＳｉｎｋがＳｏｕｒｃｅにコンテンツを要求するダウンロード形式と、Ｓｏｕｒｃｅ側からＳｉｎｋにコンテンツをプッシュするアップロード形式の２通りが挙げられる。前者の場合、ＨＴＴＰクライアントとしてのＳｉｎｋは、例えばＨＴＴＰ ＧＥＴメソッドを用いたＨＴＴＰリクエストにより、ＨＴＴＰサーバーとしてのＳｏｕｒｃｅにコンテンツを要求し、これに対し、Ｓｏｕｃｅからは要求通りのコンテンツがＨＴＴＰレスポンスとして伝送される。また後者の場合、ＨＴＴＰクライアントとしてのＳｏｕｒｃｅは、例えばＨＴＴＰ ＰＯＳＴメソッドを用いたＨＴＴＰリクエストにより、ＨＴＴＰサーバーとしてのＳｉｎｋとの伝送を開始する。

Ｓｏｕｒｃｅから伝送されるデータは、ＳｏｕｒｃｅがＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、Ｓｏｕｒｃｅは、乱数を用いてノンスＮ_cを生成して、交換鍵Ｋ_xとノンスＮ_cと暗号モードに応じたコンテンツ鍵Ｋ_cを生成する。そして、Ｓｉｎｋから要求されているコンテンツを、コンテンツ鍵Ｋ_cを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスＮ_cと暗号モードの情報を含んだヘッダーからなるパケットをＴＣＰストリーム上に乗せて送信する。ＩＰプロトコルでは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダー部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。

Ｓｉｎｋ側では、Ｓｏｕｒｃｅからの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、このストリームからノンスＮ_cとＥ−ＥＭＩを取り出すと、これらと交換鍵Ｋ_xを用いてコンテンツ鍵Ｋ_cを算出し、コンテンツ鍵Ｋ_cを用いて暗号化コンテンツを復号することができる。そして、復号化した後の平文のコンテンツに対し再生処理を実施することができる。あるいは、Ｓｉｎｋは、暗号化コンテンツを復号することなく、コンテンツを記憶部２４に格納したり、他の機器にスルーしたりする。このようにしてＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、例えばＳｉｎｋ側から、コンテンツ伝送に使用したＴＣＰコネクションを適宜切断する。（ＤＴＣＰ−ＩＰでは、パケットのヘッダー部に記述するＥ−ＥＭＩ（ＥｘｔｅｎｄｅｄＥｎｃｒｙｐｔｉｏｎ Ｍｏｄｅ Ｉｎｄｉｃａｔｏｒ）と、Ｅｍｂｅｄｄｅｄ ＣＣＩ（Ｃｏｐｙ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）という２つのメカニズムにより、コンテンツに付随したコピー制御情報の伝送を実現している。）

なお、ＤＴＣＰ−ＩＰでは、連続不使用時間が所定の期間（例えば２時間）を超える前に交換鍵Ｋ_xを破棄することが規定されている。ＳｉｎｋはＳｏｕｒｃｅから最新の交換鍵Ｋ_xを入手できなければ、暗号化コンテンツを利用不能となる。また、交換鍵Ｋ_xの運用方法には、Ｓｉｎｋ毎に１つずつ鍵を用意する方法と、Ｓｉｎｋによらず１つの鍵を使う方法がある。本実施形態では、Ｓｉｎｋ毎に１つずつ交換鍵Ｋ_xを用意するとともに、各交換鍵Ｋ_xに識別情報（鍵ＩＤ）が割り当てられるものとする。

図６には、コンテンツ提供装置に相当するＳｏｕｒｃｅとコンテンツ利用装置に相当するＳｉｎｋ間で現行のＤＴＣＰ−ＩＰに従って行なわれる、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンス（ＲＴＴ−ＡＫＥ）を示している。

ＡＫＥ手続きのチャレンジ・レスポンス部分（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ）では、まず、コンテンツを要求するＳｉｎｋから、Ｒｘ乱数とＲｘ証明書を含んだＲｘチャレンジが送信される。これに対し、Ｓｏｕｒｃｅからは、Ｔｘ乱数及びＴｘ証明書を含んだＴｘチャレンジが返信される。以降、Ｓｏｕｒｃｅから、Ｒｘ乱数、Ｔｘメッセージ、Ｔｘ署名を含んだＲｘレスポンスが送信されるとともに、ＳｉｎｋからはＴｘ乱数、Ｒｘメッセージ、Ｒｘ署名を含んだＴｘレスポンスが送信され、通常のチャレンジ・レスポンス認証手続きが続く。チャレンジ・レスポンス部分で送信されるコマンドには、各チャレンジ・コマンドには、機器固有の識別情報であるＤｅｖｉｃｅ ＩＤが含まれている。

上記のチャレンジ・レスポンス応答手続きでは、ＴＴＬ（ＩＰルーターのホップ回数）の制限が課されている。すなわち、現在のＤＴＣＰ−ＩＰでは、送信機器はＡＫＥで用いるコマンドを送るＴＣＰ／ＩＰ通信においてＴＴＬが３以下に設定され、受信機器はＴＴＬが３より大きい場合は受け取ったデータを無効にしなければならない。

その後、ＲＴＴ保護プロトコル（Ｐｒｏｔｅｃｔｅｄ ＲＴＴ Ｐｒｏｔｏｃｏｌ）を経て、ＳｏｕｒｃｅからＳｉｎｋへ、ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドが送信され、これに対し、Ｓｉｎｋからレスポンス（図示しない）が返される。

図６に示した現行のＤＴＣＰ−ＩＰに従うＲＴＴ−ＡＫＥでは、ＡＫＥコマンドに対し往復遅延時間（ＲＴＴ）やＩＰルーターのホップ回数（ＴＴＬ）に上限を設定して、ＩＰネットワーク経由でコンテンツを伝送できる範囲を制限している。コンテンツのオーナーによっては、さらにコンテンツの不正利用を制限するために、１台のコンテンツ提供装置（ＲＡ−Ｓｏｕｒｃｅ）から同時にコンテンツ伝送を行なうコンテンツ利用装置（ＲＡ−Ｓｉｎｋ）の台数に上限を設定する場合がある。

ところが、コンテンツを利用するユーザーは、複数のコンテンツ利用装置（ＲＡ−Ｓｉｎｋ）を状況に応じて使い分けたり、家庭内に設置された１台のコンテンツ提供装置（ＲＡ−Ｓｏｕｒｃｅ）を家族で共用したりすることもあり得る。家庭内の１台のコンテンツ提供装置から複数のコンテンツ利用装置にコンテンツ伝送を行なうことはコンテンツの正当な利用の範囲内であり、上記のようにコンテンツのオーナーが台数制限を設定してコンテンツ伝送を禁止するのは、ユーザーのコンテンツ利用を不当に制限することになる。

そこで、本実施形態に係る通信システムでは、１台のコンテンツ提供装置から同時にコンテンツ伝送を行なうコンテンツ利用装置の台数の上限をｎ台に設定しながら（但し、ｎは正の整数）、ユーザーによる特別な切り替え操作なしに、上限のｎ台に含まれるコンテンツ利用装置を適宜入れ替えることによって、コンテンツのオーナーからのコンテンツ保護の要求に応えながら、ユーザーによるコンテンツの正当な利用を確保する仕組みを導入している。

コンテンツ提供装置がコンテンツ伝送を同時に行なえるコンテンツ利用装置の台数を所定数以下に制限するために、コンテンツ利用装置は、コンテンツ提供装置へ、交換鍵と対応する鍵ＩＤを、所定の送信周期毎にコマンドで送信する。そして、コンテンツ提供装置は、鍵ＩＤを所定の受信周期毎に受信できている期間だけ、対応する交換鍵を保持する。他方、鍵ＩＤを含んだコマンドを所定の受信周期で受信できなかったときには、対応する交換鍵を破棄する。ＤＴＣＰ−ＩＰでは、連続不使用時間が所定の期間を超える前に交換鍵を破棄することが規定されているが（前述）、本実施形態では、２時間以内であっても鍵ＩＤを含んだコマンドを定期的に受信できなくなるとコンテンツ提供装置は対応する交換鍵を破棄する。

コンテンツ提供装置は、鍵ＩＤを含んだコマンドを受信すると、対応する交換鍵を維持しているかどうかを確認する。そして、交換鍵を維持している間に対応するコマンドを受信したときには、交換鍵が有効であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。他方、鍵ＩＤを含んだコマンドを所定の受信周期で受信できなかったことにより、対応する交換鍵を破棄した後にコマンドを受信したときには、交換鍵が無効であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。

また、コンテンツ提供装置は、鍵ＩＤを含んだコマンドを定期的に受信できなかったことにより、交換鍵を破棄した後に、これに対応する鍵ＩＤを含んだコマンドを受信したときには、コンテンツ提供装置は、送信元のコンテンツ利用装置に対して、当該交換鍵（若しくは交換鍵から生成したコンテンツ鍵）が無効であるという情報を含んだレスポンスを返信する。

また、コンテンツ利用装置は、コンテンツ提供装置との通信処理の終了などにより交換鍵が不要になったときには、定期的に送信するコマンドにそのことを示す情報をセットする。コンテンツ提供装置は、このコマンドを受信すると、対応する交換鍵を破棄する。

また、コンテンツ提供装置は、事前に登録しているコンテンツ利用装置としか鍵の寿命管理を行なわないようにしてもよい。コンテンツ利用装置は定期的に送信するコマンドの中に自分を特定する機器ＩＤを含ませ、これに対し、コマンドを受信したコンテンツ提供装置は、受信したコマンドに含まれる機器ＩＤに対応するコンテンツ利用装置が登録済みであるかどうかを確認する。そして、コマンド送信元のコンテンツ利用装置が登録済みでない場合には、コンテンツ提供装置は、コマンドに含まれる鍵ＩＤに対応する交換鍵の有効確認を行なう前に、コンテンツ利用装置が未登録であることを示す情報を含んだレスポンスを送信元のコンテンツ利用装置に返信する。

図７には、コンテンツ提供装置に相当するＳｏｕｒｃｅとコンテンツ利用装置に相当するＳｉｎｋ間で行なわれる、コンテンツ伝送を同時に行なえるコンテンツ利用装置の台数制限を含んだ相互認証及び鍵交換の動作シーケンスを示している。但し、図示のシーケンスは、ＤＴＣＰのＦｕｌｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ処理をベースとして用いるものとする。また、リモート・アクセスでは設定しない運用が一般的と考えられるが、図６に示した動作シーケンスと同様に、ＡＫＥコマンドに対し往復遅延時間（ＲＴＴ）やＩＰルーターのホップ回数（ＴＴＬ）に上限を設定してもよい。但し、図示を省略している。

Ｓｉｎｋは、コンテンツを必要とするときに、Ｓｏｕｒｃｅに、ＣＨＡＬＬＥＮＧＥコマンドを送信する。このとき、当該相互認証及び鍵交換の手続が、Ｓｏｕｒｃｅへのリモート・アクセス用の鍵（Ｋｒ）を共有することが目的であることを示すため、Ｓｉｎｋは、ＣＨＡＬＬＥＮＧＥコマンドの中に、Ｋｒ−ｂｉｔをセットする。また、Ｓｉｎｋの特定情報であるＤｅｖｉｃｅ ＩＤも、ＣＨＡＬＬＥＮＧＥコマンドで送信される。

以後、ＤＴＣＰのＦｕｌｌ Ａｕｔｈｅｎｔｉｃａｔｉｏｎプロトコルに基づいて、ＳｏｕｒｃｅからＣＨＡＬＬＥＮＧＥコマンド、ＳｉｎｋからＲＥＳＰＯＮＳＥコマンド、ＳｏｕｒｃｅからＲＥＳＰＯＮＳＥコマンド又はＲＥＳＰＯＮＳＥ２コマンドが順に送信される。

なお、チャレンジ・レスポンス部分の中では、ＳｉｎｋからＳｏｕｒｃｅへのレスポンスとして「ＲＥＳＰＯＮＳＥ２」が送られることがある。これは、機器がＣｏｍｍｏｎ Ｄｅｖｉｃｅ ＫｅｙとＣｏｍｍｏｎ Ｄｅｖｉｃｅ Ｃｅｒｔｉｆｉｃａｔｅを実装することで、Ｄｅｖｉｃｅ ＩＤがＳｉｎｋの特定情報とならない場合であり、ＲＥＳＰＯＮＳＥ２コマンドで送られるＩＤｕがＳｉｎｋの特定情報として用いられる。

Ｓｏｕｒｃｅは、Ｓｉｎｋを特定するための機器ＩＤを決める（ステップＳ７１）。Ｓｏｕｒｃｅは、ＲＥＳＰＯＮＳＥ２を受信したときはＩＤｕを、ＲＥＳＰＯＮＳＥ２コマンドを受信しなかったときはＤｅｖｉｃｅ ＩＤを、機器ＩＤとして使う。

Ｓｏｕｒｃｅは、Ｓｉｎｋとの相互認証及び鍵交換の手続の結果、Ｓｉｎｋにリモート・アクセス用の交換鍵Ｋｒを渡した場合、この交換鍵Ｋｒと、Ｋｒを特定するための鍵ＩＤと、Ｓｉｎｋの機器ＩＤの組からなるエントリーを、下表に示すように、接続テーブルに保存する。接続テーブルには、同時にコンテンツ伝送できるＳｉｎｋの制限台数分のエントリーを保存することができるものとする。下表ではエントリー数は２であるが、本発明の要旨は制限台数が２台に限定されるものではない。

また、Ｓｏｕｒｃｅは、下表に示すようなリモート・アクセス用の受信機器テーブルを管理しており、同時にコンテンツ伝送を行なうＳｉｎｋの機器ＩＤを同テーブルに保存している。コンテンツのオーナーがリモート・アクセスするＳｉｎｋの事前登録を求める場合には、Ｓｉｎｋの機器ＩＤを受信機器テーブルにあらかじめ登録しておく。受信機器テーブルに事前登録できるＳｉｎｋの台数に上限を設定してもよいが、本発明の要旨は特定の上限台数に限定されるものではない。なお、Ｓｉｎｋの機器ＩＤを受信機器テーブルに登録する方法の一例として、ＤＴＣＰにおけるＲＴＴ−ＡＫＥを行なった際に、ＳｏｕｒｃｅがＳｉｎｋを登録するといった方法が挙げられる。

Ｓｏｕｒｃｅは、上述したように、Ｓｉｎｋとの相互認証及び鍵交換の手続においてＳｉｎｋの機器ＩＤを決定すると（ステップＳ７１）、受信機器テーブルに登録済みであるかを確認する（ステップＳ７２）。コンテンツのオーナーは、リモート・アクセスするＳｉｎｋをＳｏｕｒｃｅにあらかじめ登録しておくことを求める場合があり、それを確認するための処理である。

Ｓｉｎｋの機器ＩＤが受信機器テーブルに未登録の場合には（ステップＳ７２のＮｏ）、Ｓｏｕｒｃｅは、当該相互認証及び鍵交換の手続の中断を知らせるＡＫＥ＿ＣＡＮＣＥＬコマンドをＳｉｎｋに送って、処理を終了する。Ｓｏｕｒｃｅは、ＡＫＥ＿ＣＡＮＣＥＬコマンドの中で、Ｓｉｎｋが受信機器テーブルに未登録であることを示す情報を記載するようにしてもよい。Ｓｉｎｋは、鍵交換の前に受信機器テーブルへの登録を行なうようにしてもよい。

一方、Ｓｉｎｋの機器ＩＤが受信機器テーブルに登録済みの場合には（ステップＳ７２のＹｅｓ）、続いて、Ｓｏｕｃｅは、Ｓｉｎｋの機器ＩＤが接続テーブルに記録されているかを確認する（ステップＳ７３）。

Ｓｉｎｋの機器ＩＤが接続テーブルに記録されていない場合には（ステップＳ７３のＮｏ）、Ｓｏｕｒｃｅは、接続テーブルに新たに機器ＩＤを記録する余裕があるかをさらに確認する（ステップＳ７５）。本実施形態では、Ｓｏｕｒｃｅは、接続テーブルに記録可能な鍵ＩＤの個数を、鍵カウンターを用いて管理するものとし、この鍵カウンターの値が上限値ｎ未満であれば記録可能とする。Ｓｏｕｒｃｅは、鍵カウンターの値が、接続テーブルに記録されている鍵ＩＤの数と同じになるように管理している。

鍵カウンターの値が既にｎに達している場合（ステップＳ７５のＮｏ）、Ｓｏｕｒｃｅは、当該相互認証及び鍵交換の手続の中断を知らせるＡＫＥ＿ＣＡＮＣＥＬコマンドをＳｉｎｋに送って、処理を終了する。Ｓｏｕｒｃｅは、ＡＫＥ＿ＣＡＮＣＥＬコマンドの中で、接続テーブルに登録されているエントリー数が上限ｎに達していることを示す情報を記載するようにしてもよい。

鍵カウンターの値がｎ未満の場合（ステップＳ７５のＹｅｓ）、Ｓｏｕｒｃｅは、鍵カウンターに１を加算した後（ステップＳ７６）、リモート・アクセス用の交換鍵Ｋｒと、Ｋｒを特定するための鍵ＩＤを生成し（ステップＳ７７）、この交換鍵Ｋｒ及び鍵ＩＤとＳｉｎｋの機器ＩＤの組からなるエントリーを接続テーブルに追加する（ステップＳ７８）。

また、Ｓｉｎｋの機器ＩＤが接続テーブルに既に記録されている場合には（ステップＳ７３のＹｅｓ）、当該機器ＩＤに対応するエントリーを接続テーブルから削除した後（ステップＳ７４）、リモート・アクセス用の交換鍵Ｋｒと、Ｋｒを特定するための鍵ＩＤを新たに生成し（ステップＳ７７）、この交換鍵Ｋｒ及び鍵ＩＤとＳｉｎｋの機器ＩＤの組からなるエントリーを接続テーブルに追加する（ステップＳ７８）。なお、別のパターンとして、当該機器ＩＤに対応するエントリーを接続テーブルから削除する代わりに、機器ＩＤと対応する交換鍵Ｋｒ及び鍵ＩＤを接続テーブルから取り出し、改めてこれらの情報を接続テーブルに追加しない処理も考えられる。但し、このパターンについては図示しない。

そして、Ｓｏｕｒｃｅは、ステップＳ７７で生成したリモート・アクセス用の交換鍵Ｋｒを、ＤＴＣＰ仕様で規定されている方法に従って暗号化した後、ＥＸＣＨＡＮＧＥ＿ＫＥＹコマンドによって、鍵ＩＤとともにＳｉｎｋに送信する。

Ｓｏｕｒｃｅは、交換鍵ＫｒをＳｉｎｋに送信すると同時に、この交換鍵Ｋｒの寿命管理をタイマーによって開始する（ステップＳ７９）。具体的には、Ｓｏｕｒｃｅは、鍵ＩＤと対応するタイマーを用意し（すなわち、接続テーブルに保存する鍵ＩＤ毎にタイマーを用意し）、所定の値（例えば１分に相当する値）をセットしてダウンカウントを開始する。

以後、Ｓｏｕｒｃｅは、タイマーを一定のクロックでカウントをゼロまで自動的に減らす。タイマーがゼロに達したら、Ｓｏｕｒｃｅは、接続テーブルの更新処理を起動する。

図８には、接続テーブルの更新処理の一例を示している。接続テーブルを更新することにより、鍵寿命管理コマンド（ＡＫＥ＿ＡＬＩＶＥ．ＣＭＤ）によって定期的に受信できなかった鍵ＩＤを含むエントリーが接続テーブルから削除される。

Ｓｏｕｒｃｅは、まず、ゼロになったタイマーに対応する鍵ＩＤを含むエントリーが接続テーブルに存在するか否かをチェックする（ステップＳ８１）。該当するエントリーが接続テーブルに存在しなければ（ステップＳ８１のＮｏ）、処理を終了する。

該当するエントリーが接続テーブルに存在するときには（ステップＳ８１のＹｅｓ）、Ｓｏｕｒｃｅは、ゼロになったタイマーに対応する鍵ＩＤを含むエントリーを接続テーブルから削除し（ステップＳ８２）、鍵カウンターを１だけ減算する（ステップＳ８３）。この結果、Ｓｏｕｒｃｅは新たに別のＳｉｎｋ（あるいは同じＳｉｎｋ）と改めて鍵交換を行なうことができるようになる。

なお、コマンドの通信に要する遅延を考慮して、タイマーがゼロになった時点から交換鍵を破棄するまでにマージンを設けることや、別のＳｉｎｋが新たに交換鍵を要求するまでは図８に示した処理を実行しない、という運用も考えられる。

このようにＳｏｕｏｒｃｅが交換鍵Ｋｒの寿命管理を行なうのに対し、Ｓｉｎｋは使用中の交換鍵Ｋｒの寿命更新を要求することができる。

本実施形態では、Ｓｉｎｋは、ＫＥＥＰ＿ＡＬＩＶＥコマンドを所定の送信周期で送信することによって交換鍵Ｋｒの寿命更新を要求する。また、Ｓｏｕｒｃｅは、ＫＥＥＰ＿ＡＬＩＶＥコマンドを所定の受信周期で受信することで、対応する鍵を維持する。図９には、ＫＥＥＰ＿ＡＬＩＶＥコマンドのフォーマット例を示している。図示の例では、ＫＥＥＰ＿ＡＬＩＶＥコマンドは、ペイロードに、送信元であるＳｉｎｋを特定する情報である機器ＩＤを記載するフィールドと、寿命更新を要求する交換鍵Ｋｒを特定する情報である鍵ＩＤを記載するフィールドを含み、最後の１ビットが交換鍵Ｋｒの破棄を指示する破棄フラグとして用いられる。

Ｓｏｕｒｃｅは、ＫＥＥＰ＿ＡＬＩＶＥコマンドを受信すると、寿命更新の処理を実行した後、ＫＥＥＰ＿ＡＬＩＶＥレスポンスを返信する。なお、図示を省略するが、ＫＥＥＰ＿ＡＬＩＶＥレスポンスの応答情報については、ＤＴＣＰのＡＫＥ Ｃｏｎｔｒｏｌ Ｃｏｍｍａｎｄ Ｆｏｒｍａｔに定義されているｓｔａｔｕｓフィールドを用いることが考えられる。

Ｓｏｕｒｃｅは、Ｓｉｎｋから受信したＫＥＥＰ＿ＡＬＩＶＥコマンドに含まれる鍵ＩＤに対応するタイマーに所定の時間を示す値をセットし、ダウンカウントを改めてその値から行なうように制御することで、寿命を更新する。なお、この寿命更新処理は、タイマーがゼロになった後でも、対応する鍵がまだ破棄されていなければ行なうものとする。

図１０には、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれる、交換鍵Ｋｒの寿命更新を行なう動作シーケンス例を示している。Ｓｉｎｋは、Ｓｏｕｒｃｅから交換鍵Ｋｒ及びその鍵ＩＤを渡されると、所定の送信周期でＫＥＥＰ＿ＡＬＩＶＥコマンドを送信する。

Ｓｏｕｒｃｅは、ＳｉｎｋからＫＥＥＰ＿ＡＬＩＶＥコマンドを受信すると、同コマンドに含まれる機器ＩＤが受信機器テーブルに登録済みかを確認する（ステップＳ１０１）。

ＫＥＥＰ＿ＡＬＩＶＥコマンド中の機器ＩＤが受信機器テーブルに未登録の場合は（ステップＳ１０１のＮｏ）、Ｓｏｕｒｃｅは、応答情報を「機器が未登録」として（ステップＳ１０５）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。

一方、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の機器ＩＤが受信機器テーブルに登録済みの場合は（ステップＳ１０１のＹｅｓ）、Ｓｏｕｒｃｅは、続いて、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在するかを確認する（ステップＳ１０２）。

ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在していなければ（ステップＳ１０２のＮｏ）、Ｓｏｕｒｃｅは、応答情報を「鍵が無効」として（ステップＳ１０６）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。

また、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在している場合には（ステップＳ１０２のＹｅｓ）、Ｓｏｕｒｃｅは、この鍵ＩＤと対応するタイマーを所定の時間を示す値で初期化して、改めてダウンカウントを開始する（ステップＳ１０３）。そして、Ｓｏｕｒｃｅは、応答情報を「鍵が有効」として（ステップＳ１０４）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。

Ｓｉｎｋは、Ｓｏｕｒｃｅとの相互認証及び鍵交換の手続が完了したら、取得した交換鍵Ｋｒを維持したい限り、所定の期間内の送信周期でＫＥＥＰ＿ＡＬＩＶＥコマンドを繰り返し送信する。

また、Ｓｉｎｋは、Ｓｏｕｒｃｅとの通信（コンテンツの受信）を終了して交換鍵Ｋｒが不要になったときに、Ｓｏｕｒｃｅに交換鍵Ｋｒの破棄を求めるようにしてもよい。Ｓｏｕｒｃｅは、接続テーブルから該当するエントリーを削除することによって、上限台数ｎ以内で新たに別のＳｉｎｋがＳｏｕｒｃｅに接続して通信（コンテンツ伝送）を行なうことができるようになる。

Ｓｉｎｋは、例えば所定の送信周期で送信するＫＥＥＰ＿ＡＬＩＶＥコマンドに交換鍵Ｋｒの破棄を求める情報を含めることで、Ｓｏｕｒｃｅに交換鍵Ｋｒの破棄を要求することができる。図９に示したＫＥＥＰ＿ＡＬＩＶＥコマンドのフォーマット例では、ペイロードに破棄フラグが含まれており、この破棄フラグをセットすることで、交換鍵Ｋｒの破棄を指示することができる。

図１１には、ＳｏｕｒｃｅとＳｉｎｋ間で行なわれる、交換鍵Ｋｒの寿命更新を行なう他の動作シーケンス例を示している。図示の動作シーケンスは、不要となった交換鍵Ｋｒを破棄する処理を含む点で、図１０に示した動作シーケンスとは相違する。

Ｓｏｕｒｃｅは、ＳｉｎｋからＫＥＥＰ＿ＡＬＩＶＥコマンドを受信すると、同コマンドに含まれる機器ＩＤが受信機器テーブルに登録済みかを確認する（ステップＳ１１１）。

ＫＥＥＰ＿ＡＬＩＶＥコマンド中の機器ＩＤが受信機器テーブルに未登録の場合は（ステップＳ１１１のＮｏ）、Ｓｏｕｒｃｅは、応答情報を「機器が未登録」として（ステップＳ１１６）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。

一方、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の機器ＩＤが受信機器テーブルに登録済みの場合は（ステップＳ１１１のＹｅｓ）、Ｓｏｕｒｃｅは、続いて、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在するかを確認する（ステップＳ１１２）。

ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在していなければ（ステップＳ１１２のＮｏ）、Ｓｏｕｒｃｅは、応答情報を「鍵が無効」として（ステップＳ１２０）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。

また、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の鍵ＩＤが接続テーブルに存在している場合には（ステップＳ１１２のＹｅｓ）、Ｓｏｕｒｃｅは、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の破棄フラグがセットされているかをさらに確認する（ステップＳ１１３）。

ＫＥＥＰ＿ＡＬＩＶＥコマンド中の破棄フラグがセットされているときには（ステップＳ１１３のＹｅｓ）、Ｓｏｕｒｃｅは、同コマンド中の鍵ＩＤと、これに対応する交換鍵を破棄するとともに（ステップＳ１１７）、同コマンド中の鍵ＩＤと対応する交換鍵と機器ＩＤのエントリーを接続テーブルから削除し（ステップＳ１１８）、鍵カウンターを１だけ減算する（ステップＳ１１９）。そして、Ｓｏｕｒｃｅは、応答情報を「鍵が無効」として（ステップＳ１２０）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。

一方、ＫＥＥＰ＿ＡＬＩＶＥコマンド中の破棄フラグがセットされていないときには（ステップＳ１１３のＮｏ）、Ｓｏｕｒｃｅは、この鍵ＩＤと対応するタイマーを所定の時間を示す値で初期化して、改めてダウンカウントを開始する（ステップＳ１１４）。そして、Ｓｏｕｒｃｅは、応答情報を「鍵が有効」として（ステップＳ１１５）、この応答情報を含めたＫＥＥＰ＿ＡＬＩＶＥレスポンスを要求元のＳｉｎｋに送信して、処理を終了する。

図１０並びに図１１に示した動作シーケンスによれば、家庭内に設置されたコンテンツ提供装置（Ｓｏｕｒｃｅ）の中のコンテンツを屋外から利用するようなケースで、コンテンツを同時に利用するコンテンツ利用装置（Ｓｉｎｋ）の台数を厳しく制限する必要が生じても、コンテンツ提供装置と相互認証及び鍵交換の手続を行なった各コンテンツ利用装置がそれぞれ所定の送信周期でＫＥＥＰ＿ＡＬＩＶＥコマンドを送信するので、コンテンツ提供装置は維持すべき交換鍵を正確に把握することができ、また、不要な交換鍵を破棄することで、別のコンテンツ利用装置と新たに通信を行なうことができる。

コンテンツ提供装置は、鍵ＩＤによって維持すべき交換鍵を管理するので、コンテンツ利用装置が移動通信中にアドレスが変化しても、その影響を受けずに処理することができる。

以上、特定の実施形態を参照しながら、本発明について詳細に説明してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。

本発明の適用例として、ＤＴＣＰ−ＩＰが適用されるホームネットワーク上のサーバーに、家庭外のクライアントからリモート・アクセスしてコンテンツを利用する通信システムを挙げることができるが、本発明の要旨は、ＤＴＣＰ−ＩＰを適用した通信システムにも、コンテンツにリモート・アクセスする通信システムにも限定されない。著作権やその他の目的で保護が必要となるコンテンツを同時に伝送する機器の台数を制限しながら、ユーザーの正当な使用の範囲でのコンテンツの伝送を行なう通信システムに、同様に本発明を適用することができる。

要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。

１０…コンテンツ提供装置（ＲＡ−ｓｏｕｒｃｅ）
１１…ＣＰＵ
１２…コンテンツ受信／再生部
１３…通信部
１４…記憶部
１５…タイマー
２０…コンテンツ利用装置（ＲＡ−ｓｉｎｋ）
２１…ＣＰＵ
２２…通信部
２３…コンテンツ出力部
２４…記憶部
２５…タイマー
３０、３１…ルーター
４０、４１…モデム
５０…ＷＡＮ
６０…ＩＡＳサービス
７０…ＤＤＮＳサービス

Claims (12)

1. 認証処理を実行し、
   シンク機器を特定する識別情報をシンク機器テーブルに登録し、
   チャレンジ及びレスポンス手順においてシンク機器からチャレンジ信号を受信し、
   前記シンク機器テーブルに登録されているシンク機器のうち所定の制限台数の範囲内で、前記チャレンジ信号とともに伝送される識別情報が前記シンク機器テーブルに登録されていること応じて生成した鍵をそのシンク機器に供給し、鍵を特定する鍵ＩＤ及び前記識別情報とともに接続テーブルに格納し、
   前記鍵を前記接続テーブル内に維持するためのタイマーを開始し、
   前記タイマーによってカウントされた時間に従って前記鍵ＩＤ及び前記識別情報とともに格納した前記鍵の情報を前記接続テーブルから破棄し、
   シンク機器からのＨＴＴＰ ＧＥＴを利用したＨＴＴＰ要求に応答してコンテンツ情報を伝送する、
   ように構成された回路を具備するコンテンツ伝送装置。
2. 認証処理を実行し、
   シンク機器を特定する識別情報をシンク機器テーブルに登録し、
   チャレンジ及びレスポンス手順においてシンク機器からチャレンジ信号を受信し、
   前記シンク機器テーブルに登録されているシンク機器のうち所定の制限台数の範囲内で、前記チャレンジ信号とともに伝送される識別情報が前記シンク機器テーブルに登録されていること応じて生成した鍵をそのシンク機器に供給し、鍵を特定する鍵ＩＤ及び前記識別情報とともに接続テーブルに格納し、
   前記鍵を前記接続テーブル内に維持するためのタイマーを開始し、
   前記タイマーによってカウントされた時間に従って前記鍵ＩＤ及び前記識別情報とともに格納した前記鍵の情報を前記接続テーブルから前記鍵を破棄し、
   ＨＴＴＰ ＰＯＳＴを利用したＨＴＴＰ要求によりシンク機器へのコンテンツ情報の伝送を開始する、
   ように構成された回路を具備するコンテンツ伝送装置。
3. 放送コンテンツを受信する受信部をさらに備え、
   前記回路は、ＨＴＴＰ要求に応答して、前記受信部で受信する放送コンテンツを伝送するように構成される、
   請求項１又は２のいずれかに記載のコンテンツ伝送装置。
4. 前記回路は、シンク機器から前記鍵ＩＤ及び前記識別情報を含んだ鍵寿命管理コマンドを受信したことに応答して、対応する鍵を維持するための前記タイマーの値を初期化するように構成される、
   請求項１又は２のいずれかに記載のコンテンツ伝送装置。
5. 前記回路は、シンク機器から前記鍵ＩＤ及び前記識別情報を含んだ鍵寿命管理コマンドを受信したことに応答して、対応する鍵を維持しているか否かを示すレスポンスを前記シンク機器に返信するように構成される、
   請求項１又は２のいずれかに記載のコンテンツ伝送装置。
6. 前記回路は、前記鍵ＩＤ及び前記識別情報を含むとともに鍵の破棄を指示する情報がセットされた鍵寿命管理コマンドを受信したことに応答して、対応する鍵を前記接続テーブルから破棄するように構成される、
   請求項１又は２のいずれかに記載のコンテンツ伝送装置。
7. ソース機器と認証処理を実行し、
   当該機器を特定する識別情報を前記ソース機器に伝送して、前記ソース機器のシンク機器テーブルに格納され、
   チャレンジ及びレスポンス手順においてチャレンジ信号を前記ソース機器に伝送し、前記シンク機器テーブルに登録されているシンク機器のうち所定の制限台数の範囲内で、前記チャレンジ信号とともに伝送した識別情報が前記ソース機器の前記シンク機器テーブルに格納されていること応じて生成された鍵を前記ソース機器から受け取り、その鍵が鍵を特定する鍵ＩＤ及び前記識別情報とともに前記ソース機器の接続テーブルに格納され、
   前記ソース機器の前記接続テーブルに格納されている鍵の寿命管理に関する鍵寿命管理コマンドを前記ソース機器に伝送し、
   ＨＴＴＰ ＧＥＴを指定する信号を前記ソース機器に伝送する、
   ように構成された回路を具備するシンク機器。
8. ソース機器と認証処理を実行し、
   当該機器を特定する識別情報を前記ソース機器に伝送して、前記ソース機器のシンク機器テーブに格納され、
   チャレンジ及びレスポンス手順においてチャレンジ信号を前記ソース機器に伝送し、前記シンク機器テーブルに登録されているシンク機器のうち所定の制限台数の範囲内で、前記チャレンジ信号とともに伝送した識別情報が前記ソース機器の前記シンク機器テーブルに格納されていること応じて生成された鍵を前記ソース機器から受け取り、その鍵が鍵を特定する鍵ＩＤ及び前記識別情報とともに前記ソース機器の接続テーブルに格納され、
   前記ソース機器の前記接続テーブルに格納されている鍵の寿命管理に関する鍵寿命管理コマンドを前記ソース機器に伝送し、
   ＨＴＴＰ ＰＯＳＴを指定する信号を前記ソース機器から受信する、
   ように構成された回路を具備するシンク機器。
9. ルーターと通信接続可能な通信部をさらに備え、
   前記回路は、前記通信部を用いてルーター経由で前記ソース機器と通信するように構成される、
   請求項７又は８のいずれかに記載のシンク機器。
10. 前記回路は、前記ソース機器の前記接続テーブルに格納された前記鍵の維持を指示する前記鍵ＩＤ及び前記識別情報を含んだ鍵寿命管理コマンドを伝送するように構成される、
    請求項７又は８のいずれかに記載のシンク機器。
11. 前記回路は、前記鍵ＩＤ及び前記識別情報を含んだ鍵寿命管理コマンドに応答した前記ソース機器から前記接続テーブル内に前記鍵を維持しているか否かを示すレスポンスを受信するように構成される、
    請求項７又は８のいずれかに記載のシンク機器。
12. 前記回路は、前記鍵ＩＤ及び前記識別情報を含むとともに前記ソース機器の前記接続テーブルに格納された前記鍵の破棄を指示する情報がセットされた鍵寿命管理コマンドを伝送するように構成される、
    請求項７又は８のいずれかに記載のシンク機器。

Images