JP4674502B2 - 情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラム - Google Patents

Description

本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＩＰネットワーク上でルータのホップ数を制限しながらＩＰパケットの伝送を行なう情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。

さらに詳しくは、本発明は、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）の手続きを実行する情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＩＰネットワーク上で別の機器との間で、ルータのホップ数を制限しながら相互認証及び鍵交換のためのＡＫＥコマンドを送受信する情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。

最近では、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んに行なわれる。この種のサービスでは、ＣＤやＤＶＤなどのメディアの移動を必要とせず、ネットワークを経由して遠隔端末間でコンテンツ配信を行なうことができる。

一方、ネットワーク経由で取り扱われるコンテンツは、著作物の１つとして、著作権法の下で無断の複製や改竄などの不正使用から保護を受ける。著作権法では、同法第３０条において、個人的に又は家庭内などを使用目的とした場合の使用者本人の複製を許容する一方、同法第４９条第１項においては、私的使用以外での複製物の使用を禁止している。

しかしながら、この種のコンテンツはデジタル・データであることからコピーや改竄などの不正な操作が比較的容易であることから、法的な整備だけではなく、技術的な側面からも不正使用に対する防御が必要であると考えられる。

このため、デジタル・コンテンツの利用に関して、著作権保護を目的とした多くの技術が開発されている。例えば、デジタル伝送コンテンツの保護に関する業界標準であるＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）では、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定している（例えば、非特許文献１を参照のこと）。

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

コンテンツ提供元であるサーバ（ＤＴＣＰ Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（ＤＴＣＰ Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なう。したがって、不正なクライアントは、サーバとの認証に成功しないと暗号鍵を取得できないから、コンテンツを享受することはできない。また、ＡＫＥコマンドを送受信する機器の台数や範囲を制限することによって、コンテンツが使用される範囲を著作権法で言うところの個人的又は家庭の範囲内に抑えることができる。

ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。ホーム・ネットワーク経由でのコンテンツ伝送は、著作権法で言うところの個人的又は家庭の範囲内での使用であると推定される。

また、最近では、ＩＥＥＥ１３９４ベースで規定されたＤＴＣＰ技術をＩＰネットワークに移植した技術の開発が進められている（以降、この技術をＤＴＣＰ−ＩＰと呼ぶ）。ホーム・ネットワークの多くはルータなどを経由してインターネットなどの外部の広域ネットワークに接続されているので、ＤＴＣＰ−ＩＰ技術の確立により、デジタル・コンテンツを保護しながらＩＰネットワークを利用した柔軟で効率的なコンテンツの利用が図られる。ＤＴＣＰ−ＩＰは、基本的にはＤＴＣＰ規格に含まれるものであるが、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰやＲＴＰプロトコルを使用するという点で、ＩＥＥＥ１３９４ベースで規定された本来のＤＴＣＰとは相違する。

ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）自体は、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）などの上位トランスポート層から来るデータ・ストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届けるネットワーク層であり、ルーティング機能を持つ（例えば、非特許文献２を参照のこと）。

ＩＰネットワーク上にはＰＣを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高い。このため、ＤＴＣＰ−ＩＰは、基本的にはＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であるものの、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献３を参照のこと）。

ここで、ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順について説明する。但し、ＤＴＣＰに準拠した機器は２つの種類に分類される。１つはＤＴＣＰ＿Ｓｏｕｒｃｅと言い、コンテンツの要求を受理し、コンテンツを送信するサーバ機器である。もう１つはＤＴＣＰ＿Ｓｉｎｋと言い、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアント機器である。

ＤＴＣＰ＿ＳｏｕｒｃｅとＤＴＣＰ＿Ｓｉｎｋはまず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証をＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ ＬｉｃｅｎｓｉｎｇＡｄｍｉｎｉｓｔｒａｔｏｒ）と呼ばれる認可組織によりユニークな機器ＩＤや鍵が埋め込まれている。ＤＴＣＰ認証手続きでは、このような情報を用いて互いが正規のＤＴＣＰ準拠機器であることを確かめた後、コンテンツを暗号化若しくは復号するためのＤＴＣＰ＿Ｓｏｕｒｃｅが管理している鍵をＤＴＣＰ＿Ｓｉｎｋ機器と共有することができる。

そして、ＤＴＣＰ準拠の機器間でＡＫＥによる認証手続きが済んだ後、ＤＴＣＰ＿ＳｉｎｋはＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツを要求する。ＤＴＣＰ＿Ｓｏｕｒｃｅは、ＣＤＳ（ＣｏｎｔｅｎｔｓＤｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＤＴＣＰ＿ＳｉｎｋにＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。ＤＴＣＰ＿Ｓｉｎｋがコンテンツを要求するとき、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）などのプロトコルを利用することができる。ＨＴＴＰの手続きに従ってコンテンツを要求する場合、ＤＴＣＰ＿ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＤＴＣＰ＿ＳｉｎｋがＨＴＴＰクライアントとなって、コンテンツの伝送を開始する。また、ＲＴＰによる伝送を要求するとき、ＤＴＣＰ＿ＳｏｕｒｃｅがＲＴＰＳｅｎｄｅｒとなり、ＤＴＣＰ＿ＳｉｎｋがＲＴＰ Ｒｅｃｅｉｖｅｒとなってコンテンツの伝送を開始する。なお、これらの通信手続き以外にもＲＳＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などの伝送プロトコルも適用が可能である。

ＨＴＴＰでコンテンツ伝送を行なう際、ＤＴＣＰ認証のためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成される。そして、ＨＴＴＰクライアントは、通常のＨＴＴＰと全く同様の動作手順によりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。但し、ＨＴＴＰレスポンスとして伝送されるデータは、ＨＴＴＰサーバすなわちＤＴＣＰ＿Ｓｏｕｒｃｅ機器がＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。暗号化されたデータを受信したクライアント（ＤＴＣＰ＿Ｓｉｎｋ）は同様に、先の認証をした後に共有した鍵によりデータを復号し、再生若しくは記録を行なうことができる。

このように、ＤＴＣＰ−ＩＰは、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送際に暗号化及び復号をすることにより、伝送路途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。

ＤＴＣＰでは、暗号化によりコンテンツ伝送路の安全性を確保するだけでなく、コンテンツの利用可能な範囲を著作権法で言うところの個人的又は家庭の範囲内に制限することを求めている。原初的なＤＴＣＰでは、ＩＥＥＥ１３９４などのホーム・ネットワークを前提としていることから、事実上コンテンツの使用範囲は個人的又は家庭の範囲内となる。これに対し、ＤＴＣＰ−ＩＰでは、ＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であるが、ルータを経由してインターネットなどの広域のＩＰネットワークに接続できることから、コンテンツの伝送範囲を制限する対策が必要である。

例えば、ＩＰネットワークでは、ＩＰパケットの寿命を制限するなどの目的で、ＩＰパケットのヘッダ部にはＴＴＬ（Ｔｉｍｅ Ｔｏ Ｌｉｖｅ）と呼ばれるパラメータが用意されている（例えば、非特許文献２を参照のこと）。ＩＰルータは、ＩＰパケットを通過させる度にそのヘッダ部のＴＴＬフィールド値をデクリメントすることによって（例えば、非特許文献４を参照のこと）、ＴＴＬフィールド値でＩＰパケットの生存期間や有効期限を表現することができる（例えば、特許文献１を参照のこと）。

ＤＴＣＰ−ＩＰでは、例えば、ＴＴＬフィールド値に３を設定し、ＩＰパケット毎にＴＴＬフィールド値が３を超えていないかどうかをチェックする、すなわちＡＫＥコマンドの送受信すなわち鍵交換を行なう相手のルータ・ホップ数を３以内に制限することで（例えば、非特許文献３を参照のこと）、コンテンツの利用可能範囲を個人的又は家庭の範囲に制限することができる。

しかしながら、ＤＴＣＰアプリケーションがＩＰパケットにおけるＴＴＬなどのヘッダ情報を取得してチェックするといった処理を実現するには、幾つかの技術的課題がある。以下ではこの点について説明する。

当業界において周知のように、通信プロトコルはＴＣＰやＩＰといった複数のプロトコルのスタック構造をなし、これらの最上位層としてアプリケーションが位置付けられる。

従来のＩＰプロトコル層では、ルータを通過する度にＴＴＬフィールド値を１ずつ減算する機能しか実装されていない。言い換えれば、ＩＰプロトコル層は、ＩＰパケットを受け取る度にそのヘッダ部からＴＴＬフィールド値を取り出して上位層アプリケーションに通知するようには構成されていないことから、ＤＴＣＰアプリケーションはＡＫＥコマンドを受信する毎に、そのＩＰパケットのＴＴＬフィールド値が３以下であるかどうかをチェックすることはできない。

また、既存のＩＰプロトコルは、ルータのホップの繰り返しによりＴＴＬフィールド値が消滅したＩＰパケットを破棄する機能を備えているものの、ＴＴＬフィールド値が所定値を超えるＩＰパケットを破棄するようには構成されていない。ＡＫＥコマンドの送信先でそのＩＰパケットのヘッダ内をチェックして、ＴＴＬフィールド値が３を超えるＩＰパケットを破棄するようにした場合、ＡＫＥコマンドの送信元では、ＴＣＰ／ＩＰにおいて標準的に装備されている再送制御機能により、ＡＫＥコマンドを再送と続けるという無駄な操作が発生する。

ＤＴＣＰ−ＩＰの規定に適合するように、ルータでホップする度に減算するＴＴＬフィールド値を用いてＡＫＥコマンドが届く範囲を制限する動作を実現する１つの方法として、ＩＰプロトコル層を改変することが考えられる。しかしながら、ＴＴＬフィールド値を取得し、且つチェックするといった処理を組み込んで、ＴＣＰ／ＩＰプロトコル層の処理モジュールをすべて独自に開発することは相当な負担がある。

また、Ｌｉｎｕｘや米マイクロソフト社のＷｉｎｄｏｗｓ（登録商標）といった最近主流となっているほとんどのオペレーティング・システム（ＯＳ）においては、ＴＣＰやＩＰなどの通信用のプロトコル・スタックがＯＳ内に組み込まれている。このため、ＩＰプロトコルを改変することは、ＯＳに深く関係するソースコードを改変することに相当し、過大なデメリットが発生する。

例えば、Ｗｉｎｄｏｗｓ（登録商標）のようにソースコードが公開されていないＯＳの場合には、改変そのものが不可能に等しい。

また、Ｌｉｎｕｘを始めとした所謂オープンソースのＯＳの場合、ソースコードが公開されていることから、各自において上記のＩＰプロトコル層の機能を追加することは可能である。しかしながら、その代償として関係するすべてのコードがＧＰＬ（Ｇｅｎｅｒａｌ Ｐｕｂｌｉｃ Ｌｉｃｅｎｓｅ）扱いとなり、自らもソースコードを公開しなければならなくなる。すなわち、オープンソースを変更することにより、開発元にとって今後の運用が面倒になってくる。また、ＯＳの内部機構に深く関わるカーネル（Ｋｅｒｎｅｌ）・ソースコードに変更を加える必要があることから、評価作業が増し、コスト増大を招来する。

また、ＯＳにはＴＣＰ／ＩＰプロトコル層の処理モジュールの一機能として、ネットワーク・フィルタが組み込まれている。Ｌｉｎｕｘにおける“ｉｐｔａｂｌｅ”（例えば、非特許文献５を参照のこと）がネットワーク・フィルタの一例である。この標準的なネットワーク・フィルタを設定することにより、既存のＴＣＰ／ＩＰ処理モジュールを利用してＴＴＬフィールド値を取得し且つそのチェックを行なうといった処理を実行することができる。

しかしながら、ネットワーク・フィルタを利用する場合には、（１）設定したネットワーク・フィルタが他の通信（若しくはサービスなど）の副作用を引き起こす可能性がある、（２）標準的なフィルタを使っていることから、設定したネットワーク・フィルタが他のユーザやプロセスによって容易に解除される、といった問題がある。

また、ネットワーク・フィルタに相当する処理モジュールを独自に開発し、ＴＴＬフィールド値を取得してチェックする処理を行なわせるという方法も当業者には想到される。しかしながら、開発に相当の負担がかかる上、設定したネットワーク・フィルタが他の通信（若しくはサービスなど）の副作用を引き起こす可能性がある。

特表２００３−５２１１３８号公報 ＤＴＣＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｏｌｕｍｅ １ Ｖｅｒｓｉｏｎ １．３ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００４０１０７＿ｄｔｃｐ＿Ｖｏｌ＿１＿１ｐ３．ｐｄｆ ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ） ７９１ ＩＮＴＥＲＮＥＴ ＰＲＯＴＯＣＯＬ ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｍａｐｐｉｎｇ ＤＴＣＰ ｔｏ ＩＰ， Ｖｅｒｓｉｏｎ １．０ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００３１１２４＿ｄｔｃｐ＿ＶＩＳＥ＿１ｐ０．ｐｄｆ／ ＲＦＣ １８１２ − Ｒｅｑｕｉｒｅｍｅｎｔｓ ｆｏｒ ＩＰ Ｖｅｒｓｉｏｎ ４ Ｒｏｕｔｅｒｓ Ｊｕｎｅ １９９５ ｈｔｔｐ：／／ｗｗｗ．ｊｐ.ｒｅｄｈａｔ.ｃｏｍ／ｍａｎｕａｌ／Ｄｏｃ７３／ＲＨ−ＤＯＣＳ／ｒｈｌ−ｒｇ−ｊａ／ｃｈ−ｉｐｔａｂｌｅｓ．ｈｔｍｌ

本発明の目的は、ＩＰネットワーク上において、著作権保護が必要となる情報コンテンツを好適に伝送することができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、ＩＰネットワーク上でルータのホップ数を制限しながらＩＰパケットの伝送を好適に行なうことができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、ＩＰネットワーク上で別の機器との間で、ルータのホップ数を制限しながら、ＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを好適に送受信することができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明のさらなる目的は、相互認証及び鍵交換用のＡＫＥコマンドを運ぶＩＰパケットのヘッダ内に含まれるＴＴＬフィールド値を監視しながら、相互認証及び鍵交換を行なう相手機器の範囲を所定のルータ・ホップ数以内に制限することができる、優れた情報通信システム、情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。

本発明は、上記課題を参酌してなされたものであり、その第１の側面は、
ＩＰネットワーク上で情報通信機器同士がＩＰパケットの交換を行なう情報通信システムであって、
前記情報通信機器は、
Ｓｉｎｋとなる他の情報通信機器に対してＳｏｕｒｃｅとしてＤＴＣＰ−ＩＰに準拠したコンテンツ配信する際に、
ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視して、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得し、
該取得したＴＴＬフィールド値を保持されている最大ＴＴＬフィールド値と比較し、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記保持されている最大ＴＴＬフィールド値を前記取得したＴＴＬフィールド値で更新し、
ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態が到来するとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックし、
前記保持されている最大ＴＴＬフィールド値が前記制限値以下の場合にはＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する、
ことを特徴とする情報通信システム、あるいは、
ＩＰネットワーク上で情報通信機器同士がＩＰパケットの交換を行なう情報通信システムであって、
前記情報通信機器は、
Ｓｏｕｒｃｅとなる他の情報通信機器からＳｉｎｋとしてＤＴＣＰ−ＩＰに準拠したコンテンツ取得を行なう際に、
ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視して、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得し、
該取得したＴＴＬフィールド値を保持されている最大ＴＴＬフィールド値と比較し、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記保持されている最大ＴＴＬフィールド値を前記取得したＴＴＬフィールド値で更新し、
ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを受信したとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックし、
前記保持されている最大ＴＴＬフィールド値が前記制限値以下のときにはＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄのＡＣＣＥＰＴＥＤｒｅｓｐｏｎｓｅを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する、
ことを特徴とする情報通信システムである。

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

本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システムに係り、特に、ＩＰパケットのヘッダ部に記載されるＴＴＬフィールド値を用いてルータのホップ数を規定して、コンテンツを配信可能な範囲を個人的又は家庭内に相当する範囲に制限する情報通信システムである。具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信する際に、ＡＫＥコマンドを運ぶＩＰパケットのヘッダ内に含まれるＴＴＬフィールド値を監視しながら、相互認証及び鍵交換を行なう相手機器の範囲を所定のルータ・ホップ数以内に制限するものである。

ＤＴＣＰ−ＩＰでは、例えば、ＴＴＬフィールド値に３を設定し、ＩＰパケット毎にＴＴＬフィールド値が消滅したかどうかをチェックすることで、ＤＴＣＰ機器にまでＡＫＥコマンドの送受信すなわち鍵交換を行なう相手をルータのホップ数が３以内とし、コンテンツの利用可能範囲をほぼ個人的又は家庭の範囲に制限することができる。

ここで、従来のＩＰプロトコル層では、ルータを通過する度にＴＴＬフィールド値を１ずつ減算する機能しか実装されていない。このため、受信したＩＰパケット毎にＴＴＬフィールド値が制限値以下であるかをチェックし、制限値を超えたＩＰパケットを逐次破棄するためには、ＡＫＥコマンドを運ぶＩＰパケットを受信する度に上位層のＤＴＣＰアプリケーションがＴＴＬフィールド値を取得しなければならず、ＩＰプロトコル層の改変が必要となる。

しかしながら、多くのＯＳがＴＣＰ／ＩＰプロトコル層を組み込んでいることから、問題が複雑化する。ソースコードが公開されていないＯＳにおいてはそもそもＩＰプロトコル層の改変が不可能である。また、ソースコードが公開されているＯＳにおいては改変可能だが、自らのソースコードも公開しなければならず、以後の運用が面倒になる。

ＴＣＰ／ＩＰプロトコル層を独自に開発することも考えられるが、負担が過大である。また、ＯＳに組み込まれたＴＣＰ／ＩＰプロトコル層処理モジュールの一機能であるネットワーク・フィルタを設定して、ＴＴＬフィールド値を取得することも考えられるが、他の通信への副作用が懸念されるとともに、他のユーザ又はプロセスにより設定が解除されるおそれがある。

これに対し、本発明に係る情報通信システムでは、各情報通信機器は、前記所定のパケット交換手続きを開始してから終了する直前までの期間において、受信したＩＰパケットのヘッダ部に記載されているＴＴＬフィールド値を監視し、該ＴＴＬフィールド値の最大値を更新し続け、前記所定のパケット交換手続きが終了する直前にＴＴＬフィールド値の最大値が前記制限値を超えていないかどうかをチェックするようになっている。

最上位層のアプリケーションは、後述するように、既存のライブラリを活用することによって、パケットのＴＴＬフィールド値を取り出す処理を実現することができる。したがって、本発明に係る情報通信システムにおいて、パケット交換を行なう所定の期間のＴＴＬフィールド値を監視し続けるという動作を実装する上で、ＩＰプロトコル層の改変や、ＴＣＰ／ＩＰプロトコル層の独自開発、ＯＳの改変といった作業を行なう必要はない。

そして、前記所定のパケット交換手続きを行なう情報通信機器は、前記所定のパケット交換手続きを開始してから終了する直前までの期間に監視したパケットから取り出したＴＴＬフィールド値の最大値が前記制限値以下であれば以後のパケット送受信処理を行なって前記所定のパケット交換手続きを完了させる一方、前記制限値を超えると以後のパケット送受信処理を行なわず前記所定のパケット交換手続きを中止するようにすれば、このパケット交換手続きを行なう通信相手を所定のＴＴＬフィールド値の範囲内に制限することができる。

本発明をＤＴＣＰ−ＩＰ認証に適用した場合、認証を行なう双方の情報通信装置は、ＤＴＣＰ−ＩＰ認証を開始してから終了する直前までに受信した、認証用の制御コマンドすなわちＡＫＥコマンドを監視し続け、受信するＡＫＥコマンドのＴＴＬフィールド値の最大値を更新し続け、認証手続きが終了する直前にＴＴＬフィールド値の最大値をチェックし、この最大値が所定の制限値（例えば３）以下であれば鍵交換を行なって認証手続きを完了するが、所定値を超えると鍵交換を行なわず認証手続きを中止する。

例えば、Ｓｉｎｋとなる情報通信機器に対してＳｏｕｒｃｅとしてＤＴＣＰ−ＩＰに準拠したコンテンツ配信を行なう情報通信機器は、ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後、すなわちＳｉｎｋからのｃｏｎｎｅｃｔ（）要求を受信してａｃｃｅｐｔ（）を返信した直後から、該ＴＣＰコネクション上で受信されるＩＰパケットを監視してＩＰパケット毎にＴＴＬフィールド値を取得して、該ＴＴＬフィールド値の最大値を更新し続ける。そして、ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態が到来するとき、最大のＴＴＬフィールド値が制限値以下であるかどうかをチェックする。ここで、最大のＴＴＬフィールド値が制限値以内のときにはＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する処理に移行するが、最大のＴＴＬフィールド値が制限値を超える場合にはＡＫＥ手続きを中止させるようにする。

また、Ｓｏｕｒｃｅとなる情報通信機器からＳｉｎｋとしてコンテンツを配信する情報通信機器は、ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後、該ＴＣＰコネクション上で受信されるＩＰパケットを監視してＩＰパケット毎にＴＴＬフィールド値を取得して、該ＴＴＬフィールド値の最大値を更新し続け、ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを受信したとき、最大のＴＴＬフィールド値が制限値以下であるかどうかをチェックし、最大のＴＴＬフィールド値が制限値以内のときにはＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄのＡＣＣＥＰＴＥＤ ｒｅｓｐｏｎｓｅを送信する処理に移行するが、最大のＴＴＬフィールド値が制限値を超える場合にはＡＫＥ手続きを中止させるようにする。

ＤＴＣＰアプリケーションが、ＡＫＥコマンドを運ぶＩＰパケット毎にＴＴＬフィールド値を取り出し制限値を超えていないかをチェックし、制限値を超えたＩＰパケットを逐次破棄するという処理を実現するには、ＴＣＰ／ＩＰプロトコル層の独自開発、又はこれらのプロトコル・スタックを組み込んだＯＳの改変といった困難な作業を伴う（前述）。これに対し、ＩＰパケット毎のＴＴＬフィールド値を取り出して監視し続けるだけであれば、“ｐｃａｐ”と呼ばれるＭＡＣフレームを監視することができるパケット・キャプチャ機能を持つ既存のライブラリ、すなわちｌｉｂｐｃａｐを利用して容易に実現することができる。

したがって、ＤＴＣＰアプリケーションは、ｌｉｂｐｃａｐを用いてＤＴＣＰ−ＩＰ認証を開始してから終了する直前までの間、受信した各ＡＫＥコマンドを監視し続け、ＴＴＬフィールド値の最大値を更新し続けることができる。そして、認証手続きが終了する直前にＴＴＬフィールド値の最大値をチェックし、この最大値が所定の制限値（例えば３）以下であれば鍵交換を行なって認証手続きを完了する一方、制限値を超えると、最終段階の処理を行なわずに認証手続きを終わらせる。これによって、ＩＰプロトコル層の改変を一切改変することなく、ＤＴＣＰアプリケーションは、認証及び鍵交換を行なう通信相手を所定のＴＴＬフィールド値の範囲内に制限することができる。

ｐｃａｐは、パケット・キャプチャ機能によりＭＡＣフレームを監視することができる。Ｗｉｎｄｏｗｓ（登録商標）のｌｉｂｐｃａｐとして“ＷｉｎＰｃａｐ”を挙げることができる（例えば、ｈｔｔｐ：／／ｗｗｗ．ｗｉｎｐｃａｐ．ｏｒｇ／を参照されたい）。

また、本発明の第2の側面は、
Ｓｉｎｋとなる他の情報通信機器に対してＳｏｕｒｃｅとしてＤＴＣＰ−ＩＰに準拠したコンテンツ配信を行なうための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視し、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得するＴＴＬフィールド値取得手順と、
前記ＴＴＬフィールド値取得手順で取得したＴＴＬフィールド値を、保持されている最大ＴＴＬフィールド値と比較するＴＴＬフィールド値比較手順と、
前記ＴＴＬフィールド値比較手順の比較結果に基づき、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記保持されている最大ＴＴＬフィールド値を、前記取得したＴＴＬフィールド値で更新する最大ＴＴＬフィールド値更新手順と、
ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態が到来するとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックして、前記保持されている最大ＴＴＬフィールド値が前記制限値以下のときにはＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する制御手順と、
を実行させることを特徴とするコンピュータ・プログラム、あるいは、
Ｓｏｕｒｃｅとなる他の情報通信機器からＳｉｎｋとしてＤＴＣＰ−ＩＰに準拠したコンテンツ取得を行なうための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視し、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得するＴＴＬフィールド値取得手順と、
前記ＴＴＬフィールド値取得手順で取得したＴＴＬフィールド値を、保持されている最大ＴＴＬフィールド値と比較するＴＴＬフィールド値比較手順と、
前記ＴＴＬフィールド値比較手順の比較結果に基づき、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記保持されている最大ＴＴＬフィールド値を、前記取得したＴＴＬフィールド値で更新する最大ＴＴＬフィールド値更新手順と、
ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを受信したとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックして、前記保持されている最大ＴＴＬフィールド値が前記制限値以下のときにはＥＸＣＨＡＮＧ＿ＫＥＹｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄのＡＣＣＥＰＴＥＤ ｒｅｓｐｏｎｓｅを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する制御手順と、
を実行させることを特徴とするコンピュータ・プログラムである。

本発明の第２の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによってコンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係る情報通信システムにおける１つの情報通信機器として動作する。このような情報通信装置を複数起動し、それぞれＳｏｕｒｃｅ機器及びＳｉｎｋ機器として動作させてＩＰパケットを交換し合うシステムを構築することによって、本発明の第１の側面に係る情報通信システムと同様の作用効果を得ることができる。

本発明によれば、ＩＰネットワーク上でルータのホップ数を制限しながらＩＰパケットの伝送を好適に行なうことができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。

また、本発明によれば、ＩＰネットワーク上で別の機器との間で、ルータのホップ数を制限しながら、ＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを好適に送受信することができる、優れた情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。

また、本発明によれば、相互認証及び鍵交換用のＡＫＥコマンドを運ぶＩＰパケットのヘッダ内に含まれるＴＴＬフィールド値を監視しながら、相互認証及び鍵交換を行なう相手機器の範囲を所定のルータ・ホップ数以内に制限することができる、優れた情報通信システム、情報通信システム、情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。

本発明をＤＴＣＰ−ＩＰ認証に適用した場合、認証を行なう双方の情報通信装置は、ＡＫＥコマンド毎にヘッダからＴＴＬフィールド値を取り出して所定の制限値を超えているかどうかをチェックして、制限値を越えたＡＫＥコマンドを逐次破棄するのではなく、ＤＴＣＰ−ＩＰ認証を開始してから終了する直前までの監視期間において受信したＡＫＥコマンドを監視し続け、受信するＡＫＥコマンドのＴＴＬフィールド値の最大値を更新し続ける。そして、認証手続きが終了する直前にＴＴＬフィールド値の最大値をチェックし、この最大値が所定値を超えると鍵交換を行なわず認証手続きを中止することによって、鍵交換を行なう相手を所定のルータ・ホップ数の範囲内に制限することができる。

ＤＴＣＰアプリケーションがＴＴＬフィールド値を取得するために、パケット・キャプチャ機能を提供するｌｉｂｐｃａｐを用いればよく、ＧＰＬを避けた開発が可能である。実際、ｌｉｂｐｃａｐはＢＳＤ（Ｂｅｒｋｅｌｅｙ Ｓｏｆｔｗａｒｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ）ラインセスなので、このライブラリを利用したバイナリを配布するに際して著作権表示を行なうだけで十分である。

すなわち、本発明によれば、ＤＴＣＰ−ＩＰにＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）の手続きにおいて実施するＴＴＬフィールド値のチェック処理機能を、外部ライブラリを利用することで実現することができる。したがって、ＯＳに深く関わるカーネルなどのコードを改変する必要がない。勿論、ＯＳのコードを改変する場合に比べ開発工数ははるかに少なくて済む。また、他のユーザやプロセスと共有しないでＴＴＬフィールド値のチェック処理に関わる制御を実現することができるので、他のユーザなどの介在により勝手に制御されるおそれはない。

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

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

本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システムに関するものであり、具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信し、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なう情報通信システムに関する。ＤＴＣＰ−ＩＰに準拠する情報通信機器間で相互認証及び鍵交換を行なう際、ＡＫＥコマンドを運ぶＩＰパケットのヘッダ内に含まれるＴＴＬフィールド値が３を超えないように規定され、相互認証及び鍵交換を行なう相手機器の範囲は所定のルータ・ホップ数以内に制限されている。

Ａ．システム構成
図１には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。

ＤＴＣＰ−ＩＰに従ったコンテンツ伝送は、コンテンツの要求を受理してコンテンツを送信するサーバとしてのＳｏｕｒｃｅ機器と、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアントとしてのＳｉｎｋ機器で構成される。図示の例では、ＤＴＣＰ−ＩＰに準拠した認証サーバであるＳｏｕｒｃｅ機器ＡとＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器Ａが中継機器Ａと中継機器Ｂを経由してネットワークで接続されている。

また、中継機器Ａ、中継機器Ｂ、中継機器Ｃを経由して、ＤＴＣＰ−ＩＰに準拠した認証サーバであるＳｏｕｒｃｅ機器ＢやＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器ＢがＩＰネットワークで接続されている。

既存のＩＰプロトコルでは、ＩＰルータはＩＰパケットを通過させるときにＩＰヘッダに埋め込まれているＴＴＬフィールド値を１ずつ減算することと、ＴＴＬフィールド値が消滅したＩＰパケットを破棄することを規定している。すなわち、中継機器は、ＩＰパケットをルーティングするときにはそのＴＴＬフィールド値を１ずつ減算するとともに、ＴＴＬフィールド値が０になったＩＰパケットが中継機器で受信されたときに、そのＩＰパケットを破棄しなければならない決まりとなっている。

図１に示した例で言えば、Ｓｏｕｒｃｅ機器ＡからＳｉｎｋ機器ＡへＩＰパケットが送信された場合、中継機器Ａ並びに中継機器Ｂを通過することにより、ＴＴＬフィールド値が２だけ減った状態でＩＰパケットがＳｉｎｋ機器Ａで受信されることになる。

例えば、Ｓｏｕｒｃｅ機器ＡにてＴＴＬフィールド値を３としてＩＰパケットを生成し、Ｓｉｎｋ機器Ｃに送信することを考えると、中継機器Ａ、中継機器Ｂを経由して中継機器ＣまでそのＩＰパケットは到着するものの、中継機器ＣではＴＴＬフィールド値が１から０になることでこのパケットを破棄することになる。この結果、Ｓｉｎｋ機器ＣにはＩＰパケットが到着しない。

また、Ｓｉｎｋ機器ＡからＳｏｕｒｃｅ機器ＢへＴＴＬフィールドの値を３としてＩＰパケットを送信した場合には、ＴＴＬフィールド値が１の状態のＩＰパケットがＳｏｕｒｃｅ機器Ｂへ到着する。ＴＴＬフィールド値が０の状態のＩＰパケットはネットワーク上に伝播されない。

本実施形態に係る情報通信システムでは、Ｓｏｕｒｃｅ機器Ａ〜Ｂ、Ｓｉｎｋ機器Ａ〜Ｂ及び中継機器Ａ〜Ｃの各エンティティにより、ＤＴＣＰ−ＩＰ ＡＫＥシステムが構築されている。ＤＴＣＰ−ＩＰによれば、暗号化コンテンツの伝送に用いられる鍵の交換すなわちＡＫＥを実施する範囲を、ＴＴＬフィールド値が３を超えない範囲、すなわちルータのホップ数が３を超えない範囲に制限している。したがって、Ｓｏｕｒｃｅ機器は、Ｓｉｎｋ機器Ａ及びＢのいずれともＡＫＥを実施することができ、また、Ｓｏｕｒｃｅ機器Ｂは、Ｓｉｎｋ機器Ａ及びＢのいずれともＡＫＥを実施することができる。

他方、中継機器Ｄを経由して同ネットワークに接続されるＳｉｎｋ機器Ｃは、Ｓｏｕｒｃｅ機器とパケット交換を行なう際のルータのホップ数が３を超えるため、ＡＫＥを実施することはできない。言い換えれば、図１に示したＤＴＣＰ−ＩＰ ＡＫＥシステムの外にある。

図２及び図３には、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）及びサーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成をそれぞれ模式的に示している。Ｓｉｎｋ機器とＳｏｕｒｃｅ機器は、インターネットなどの図示しないＴＣＰ／ＩＰネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。

これらＳｉｎｋ機器及びＳｏｕｒｃｅ機器として動作する情報通信装置は、専用のハードウェア装置として設計・製作することもできるが、例えばパーソナル・コンピュータなどの一般的なコンピュータ・システム上に所定のクライアント・アプリケーション及びサーバ・アプリケーションをインストールし起動するという形態でも実現することができる。

図２に示すＳｉｎｋ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｉｎｋとして動作する。図示のクライアント機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ受信ブロックと、コンテンツ再生／記録ブロックを備えている。

ＤＴＣＰ−ＩＰ認証ブロックは、認証手続き実行手段に相当し、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ復号ブロックを備えている。

ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｉｎｋ側）を実現するブロックでる。このＡＫＥブロックは後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。

メッセージ・ダイジェスト生成ブロックは、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる（ＳＨＡ−１は、ＭＤ５と同様、ＭＤ４を改良したものに相当するが、１６０ビットのハッシュ値を生成するので、強度はＭＤシリーズを上回る）。

メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。

コンテンツ復号ブロックは、サーバから受信した暗号化されたコンテンツ・データをＡＫＥで交換した鍵を用いて復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生／記録ブロックへ渡される。

コンテンツ再生／記録ブロックは、渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合は保存する。

ＤＴＣＰ−ＩＰコンテンツ受信ブロックは、ＡＫＥを実施した後にコンテンツ伝送手続きを実行する処理モジュールであり、ＨＴＴＰクライアント・ブロックを持ち、ＨＴＴＰクライアントとしてＨＴＴＰサーバへコンテンツを要求し、応答されたコンテンツをＨＴＴＰサーバから受信する。

ＨＴＴＰクライアント・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト送信ブロックとＨＴＴＰリクエスト生成ブロックへ分かれる。

ＨＴＴＰリクエスト生成ブロックは、送信するコンテンツ伝送要求（ＨＴＴＰリクエスト）を生成する。ここで生成されたＨＴＴＰリクエストは、ＨＴＴＰリクエスト送信ブロックによりサーバへ送信される。

ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス受信ブロックとＨＴＴＰレスポンス解釈ブロックに分かれる。サーバから返信されるＨＴＴＰレスポンスと暗号化されたコンテンツは、ＨＴＴＰ受信ブロックで受信される。ここで受信したＨＴＴＰレスポンスは、ＨＴＴＰレスポンス解釈ブロックでチェックされる。ここでのチェックがＯＫの場合は受信した暗号化コンテンツをコンテンツ復号ブロックへ送る。また、このチェックがＮＧの場合は、エラー・レスポンスとしての処理を行なう。

ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ受信ブロックは、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。

また、図３に示すＳｏｕｒｃｅ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｏｕｒｃｅとして動作する。サーバ機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ送信ブロックと、コンテンツ管理ブロックを備えている。

ＤＴＣＰ−ＩＰ認証ブロックは、認証手続き実行手段に相当し、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ暗号化ブロックを備えている。

ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｏｕｒｃｅ側）を実現するブロックである。このブロックは、後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。ＡＫＥブロックは認証したＤＴＣＰ＿Ｓｉｎｋ機器に関する情報を認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。

メッセージ・ダイジェスト生成ブロックは指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとは、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる（同上）。

メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。

コンテンツ暗号化ブロックは、ＤＴＣＰ−ＩＰコンテンツ送信ブロックの要求に応じて、コンテンツ管理ブロックより読み出したコンテンツ・データをＡＫＥで交換した鍵を用いて暗号化するブロックである。ここで復号されたコンテンツは、クライアントへ送信するために、ＤＴＣＰ−ＩＰコンテンツ送信ブロックへ渡される。

コンテンツ管理ブロックは、ＤＴＣＰ−ＩＰの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。

ＤＴＣＰ−ＩＰコンテンツ送信ブロックは、コンテンツ伝送手続き実行手段に相当し、ＨＴＴＰサーバ・ブロックを持ち、ＨＴＴＰサーバとしてクライアントからのリクエストを受理し要求に応じた処理を実行する。

ＨＴＴＰサーバ・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト受信ブロックと、ＨＴＴＰリクエスト解釈ブロックに分かれる。

ＨＴＴＰリクエスト受信ブロックは、クライアントからのＨＴＴＰリクエストを受信する。受信したＨＴＴＰリクエストはＨＴＴＰリクエスト解釈ブロックに送られ、チェックされる。ＨＴＴＰリクエスト解釈ブロックにおけるチェックがＯＫの場合、ＨＴＴＰリクエストの情報をＤＴＣＰ−ＩＰ認証ブロックへ通知する。

ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス生成ブロックとＨＴＴＰレスポンス送信ブロックに分かれる。

ＨＴＴＰレスポンス生成ブロックは、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合、暗号化されたコンテンツを返すためのＨＴＴＰレスポンスを作成する。一方、ＨＴＴＰリクエスト解釈ブロックでのチェックがＮＧの場合、エラーを返すためのＨＴＴＰレスポンスを作成する。

ＨＴＴＰレスポンス送信ブロックは、作成されたＨＴＴＰレスポンスを、要求元のクライアントへＨＴＴＰレスポンスを送信する。また、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合には、ＨＴＴＰレスポンス・ヘッダに続けて、暗号化コンテンツを送信する。

ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ送信ブロックは、Ｓｉｎｋ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。

なお、ＤＴＣＰ−Ｓｉｎｋ機器及びＤＴＣＰ−Ｓｏｕｒｃｅ機器のいずれもがＤＴＣＰ−ＩＰ認証ブロック内に持つメッセージ・ダイジェスト生成ブロックはＤＴＣＰ−ＩＰ自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。例えば、本出願人に既に譲渡されている特願２００４−１１３４５９号公報にはメッセージ・ダイジェスト生成ブロックについて記述されている。

Ｂ．ＤＴＣＰ−ＩＰに従ったコンテンツの伝送
Ｓｏｕｒｃｅ機器とＳｉｎｋ機器間でＤＴＣＰ−ＩＰに従ったコンテンツの伝送を行なう場合には、Ｓｏｕｒｃｅ機器とＳｉｎｋ機器はまず１つのＴＣＰ／ＩＰコネクションを確立してから、ＡＫＥコマンドの送受信を通して機器同士の認証を行なう。ＡＫＥ手続きにより、コンテンツを暗号化若しくは復号するためのＳｏｕｒｃｅ機器が管理している鍵をＳｉｎｋ機器と共有することができる。

ＡＫＥコマンドは、基本的にＩＥＥＥ１３９４の上位プロトコルであるＡＶ／Ｃ Ｇｅｎｅｒａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎのサブセットという位置付けである。図４には、ＡＫＥコマンドのパケット・フォーマットを示している。同図に示すように、ＡＫＥコマンドは、１バイトのＴｙｐｅフィールドと、２バイトのＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドからなる。

Ｔｙｐｅ、ＢＬＣ、Ｃｏｎｔｒｏｌ各フィールドの０バイト目は、ＤＴＣＰをＩＰにマッピングするために使用される。Ｔｙｐｅフィールドにより、当該パケットがバージョン１のＡＫＥ制御パケットであることが示される。

ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅは、当該ＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを記載するフィールドであり、ＤＴＣＰ仕様第８章及びＡＶ／Ｃデジタル・インターフェース・コマンドによる規定と同じ値を持つ。

Ｃｏｎｔｒｏｌフィールドの１〜７バイトは、ＩＰプロトコルで使用されない場合にはＣｏｎｔｒｏｌフィールドの７バイト目のＭＳＢを除いては、セクション８．３．１に規定されている０〜６バイトのオペランドと同一である。

ＡＫＥコマンドは、サブファンクションという種類に分けることができる。サブファンクションは、ＡＫＥコマンドの６バイト目のｓｕｂｆｕｎｃｔｉｏｎフィールドに記載されている。

ＡＫＥ＿Ｉｎｆｏフィールドは、セクション８．３．１に規定されているデータ・フィールドと同様である。

ＡＫＥ＿ｌａｂｅｌと各制御コマンドのソース・ソケットは適当なコントローラから由来することを確認しなければならない。

また、図５には、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンスを示している。同シーケンスにおいて、ｒｅｑｕｅｓｔはターゲットとなる機器を制御するときに用いられ、ｒｅｓｐｏｎｓｅはｒｅｑｕｅｓｔを受けた機器の応答を示すときに用いられる。コマンド・タイプを持つＡＫＥコマンドは、ＡＫＥコマンド・リクエストであり、レスポンス・コードを持つＡＫＥコマンドはＡＫＥコマンド・レスポンスである。また、ＤＴＣＰ−ＩＰでは、ＥＸＣＨＡＮＧＥ＿ＫＥＹｓｕｂｆｕｎｃｔｉｏｎ Ｃｏｍｍａｎｄは、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器に対してのみ送信されるＡＫＥコマンドであり、逆方向には送信されない、という点を理解されたい。

Ｓｏｕｒｃｅ機器（又はＳｉｎｋ機器）からＳｉｎｋ機器（又はＳｏｕｒｃｅ機器）へ、ＡＫＥ ｓｔａｔｕｓ ｃｏｍｍａｎｄが送信され、これに対し、Ｓｉｎｋ機器（又はＳｏｕｒｃｅ機器）からＡＫＥ Ｓｔａｔｕｓ ｒｅｓｐｏｎｓｅが返され、その後、Ｓｏｕｒｃｅ機器（又はＳｉｎｋ機器）からＳｉｎｋ機器（又はＳｏｕｒｃｅ機器）へＣＨＡＬＬＥＮＧＥ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器（又はＳｏｕｒｃｅ機器）からｒｅｓｐｏｎｓｅが返される。

続いて、Ｓｏｕｒｃｅ機器（又はＳｉｎｋ機器）からＳｉｎｋ機器（又はＳｏｕｒｃｅ機器）へ、ＲＥＳＰＯＮＳＥ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器（又はＳｏｕｒｃｅ機器）からＡＫＥ Ｓｔａｔｕｓ ｒｅｓｐｏｎｓｅが返される。

その後、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へ、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器からｒｅｓｐｏｎｓｅが返される。

続いて、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へ、ＳＲＭ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器からｒｅｓｐｏｎｓｅが返される。

続いて、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へ、ＣＯＮＴＥＮＴ＿ＫＥＹ＿ＲＥＱ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器からｒｅｓｐｏｎｓｅが返される。

なお、ＤＴＣＰ−ＩＰでは、ＡＫＥのトリガ方法そのものについては定義していないが、ＡＫＥをトリガするための情報（以下では、「ＡＫＥトリガ情報」とも呼ぶ）については規定している。ＡＫＥトリガ情報は、Ｓｏｕｒｃｅ機器においてＡＫＥを受け付けるためのＩＰ アドレスとポート番号の組み合わせを含んだ形で定義されている。よって、ＡＫＥトリガ情報がＳｏｕｒｃｅ機器からＳｉｎｋ機器へ渡された後、その情報を基にＳｉｎｋ機器からＳｏｕｒｃｅ機器に対してＴＣＰコネクションを確立することで、ＡＫＥはトリガ可能となる。ＡＫＥトリガ情報の性質から自明であるが、通常、Ｓｏｕｒｃｅ機器の方からＳｉｎｋ機器に対してＴＣＰコネクションの確立を試みる。

以下の説明では、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器へネットワーク経由でＡＫＥのトリガを渡すものとして扱う（実際には、ＵＰｎＰのＣＤＳを利用して渡される）。また、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へＡＫＥトリガ情報が渡されるより前に、Ｓｏｕｒｃｅ機器はＳｉｎｋ機器からのＡＫＥを受け付けられる状態になっているものとする。

そして、ＤＴＣＰ準拠の機器間でＡＫＥ手続きが済んだ後、Ｓｉｎｋ機器はＳｏｕｒｃｅ機器に対しコンテンツを要求する。Ｓｏｕｒｃｅ機器は、ＣＤＳ（ＣｏｎｔｅｎｔｓＤｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＳｉｎｋ機器にＳｏｕｒｃｅ機器上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。Ｓｉｎｋ機器がコンテンツを要求するとき、ＨＴＴＰやＲＴＰなどのプロトコルを利用することができる。

例えば、Ｓｏｕｒｃｅ機器がＨＴＴＰサーバとなり、Ｓｉｎｋ機器がＨＴＴＰクライアントとなって、コンテンツの伝送を開始する。この場合、ＤＴＣＰ認証のためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成される。そして、ＨＴＴＰクライアントは、通常のＨＴＴＰと全く同様の動作手順によりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。但し、ＨＴＴＰレスポンスとして伝送されるデータは、ＨＴＴＰサーバすなわちＳｏｕｒｃｅ機器がＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。暗号化されたデータを受信したクライアントすなわちＳｉｎｋ機器は同様に、先の認証をした後に共有した鍵によりデータを復号し、再生若しくは記録を行なうことができる。

このように、ＤＴＣＰ−ＩＰによれば、認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。

Ｃ．ＴＴＬチェックによるコンテンツ伝送可能範囲の制限
ＩＰプロトコルでは、ＩＰルータはＩＰパケットを通過させるときにＩＰヘッダに埋め込まれているＴＴＬフィールドの値を１ずつ減算することと、ＴＴＬフィールド値が消滅したＩＰパケットをネットワークに伝播しない（破棄する）ことを規定している。

ＤＴＣＰ−ＩＰではさらに、ＡＫＥコマンドとしてＩＰパケットを送信するに際して、ＴＴＬフィールドの値を３以下に設定することを定めている。また、ＡＫＥコマンドとしてＩＰパケットを受信するに際して、３を超えたＴＴＬフィールドの値だった場合にはそのＩＰパケットを破棄することを定めている。これは、ＡＫＥコマンドの送受信すなわち鍵交換を行なう相手をルータのホップ数が３以内とし、コンテンツの利用可能範囲をほぼ個人的又は家庭の範囲に制限するためである。

既存のＩＰプロトコルは、ルータのホップの繰り返しによりＴＴＬフィールド値が消滅したＩＰパケットを破棄する機能を備えているものの、ＴＴＬフィールド値が所定値を超えるＩＰパケットを破棄するようには構成されていない。このため、ＡＫＥコマンドを運ぶＩＰパケットを受信する度に、ＤＴＣＰアプリケーションがそのＴＴＬフィールド値をチェックして、ＴＴＬフィールド値が所定値を超えたＩＰパケットを破棄するためには、ＴＣＰ／ＩＰプロトコルを独自開発するか、又はＴＣＰ／ＩＰを組み込んだＯＳのカーネルに相当するコードを改変する必要があり、手間がかかる。

これに対し、本実施形態では、ＤＴＣＰ−ＩＰに準拠した情報通信機器は、ＡＫＥコマンドを受信する度にそのＴＴＬフィールド値をチェックしてパケットを破棄すべきかどうかを逐次的に決定するのではなく、ＡＫＥ手続きを開始してから終了する直前までの期間において、受信したＩＰパケットのヘッダ部に記載されているＴＴＬフィールド値を監視し、該ＴＴＬフィールド値の最大値を更新し続けるようにする。そして、鍵交換を行なう直前に、ＴＴＬフィールド値の最大値が３を超えていないかどうかをチェックし、３を超える場合には、ＤＴＣＰ−ＩＰアプリケーションは以降の鍵交換を行なう処理を中止する。

例えば、ＤＴＣＰ−ＩＰアプリケーションがＡＫＥコマンドを監視してそのＩＰヘッダのＴＴＬフィールド値を取得するには、ｌｉｂｐｃａｐなどのライブラリを活用すればよく、ＴＣＰ／ＩＰプロトコル層の独自開発、ＯＳの改変といった作業を行なう必要はない。なお、ｌｉｂｐｃａｐはＬｉｎｕｘ用のライブラリであり、例えばｈｔｔｐ：／／ｗｗｗ．ｔｃｐｄｕｍｐ．ｏｒｇ／を参照されたい。

図６には、Ｓｏｕｒｃｅ機器ＡとＳｉｎｋ機器Ｂの間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）手続きを行なうための動作シーケンス例を示している。同図に示す例では、Ｓｏｕｒｃｅ機器ＡとＳｉｎｋ機器Ｂの間はルータのホップ数が３以下であることから、互いの機器はＴＴＬフィールド値を３に設定してＡＫＥコマンドを送信すれば、途中で破棄されることなく相手に届くので、手続きは正常に行なわれる。なお、Ｓｏｕｒｃｅ機器ＡがＳｉｎｋ機器Ｂへネットワーク経由でＡＫＥのトリガを渡すものとし、また、Ｓｏｕｒｃｅ機器ＡからＳｉｎｋ機器ＢへＡＫＥトリガ情報が渡されるより前に、Ｓｏｕｒｃｅ機器ＡはＳｉｎｋ機器ＢからのＡＫＥを受け付けられる状態になっているものとする。

Ｓｏｕｒｃｅ機器Ａは、ＡＫＥトリガ情報に含まれるポート番号でＴＣＰコネクション確立要求を受けられる状態に遷移する。具体的には、Ｓｏｕｒｃｅ機器Ａは、ｓｏｃｋｅｔオブジェクトを作成して、ｂｉｎｄ（）メソッドとｌｉｓｔｅｎ（）メソッドを実行し、Ｓｉｎｋ機器Ｂからのｃｏｎｎｅｃｔ（）要求受信待機状態に遷移する。

次いで、Ｓｏｕｒｃｅ機器Ａは、ＡＫＥトリガ情報をＳｉｎｋ機器Ａに渡す。

一方、Ｓｉｎｋ機器Ｂは、ＡＫＥトリガ情報を受け取ると、ＴＣＰコネクション確立のための準備を行ない、ＩＰパケットのＴＴＬフィールド値をチェックするための処理を起動する。具体的には、ｓｏｃｋｅｔオブジェクトを作成し、そのｓｏｃｋｅｔに結び付いた状態でＴＴＬフィールド値のチェック処理を起動する。

Ｓｉｎｋ機器Ｂは、続いて、ＡＫＥトリガ情報に含まれるＩＰアドレスとポート番号を用いて、Ｓｏｕｒｃｅ機器Ａに対して、ＴＣＰコネクション確立要求を実施する。具体的には、Ｓｉｎｋ機器Ｂは、ｃｏｎｎｅｃｔ（）メソッドを実施する。

これに対し、Ｓｏｕｒｃｅ機器Ａは、Ｓｉｎｋ機器ＢよりＴＣＰコネクション確立要求を受けると、ＴＣＰコネクションを確立させ、ＩＰパケットのＴＴＬフィールド値のチェック処理を起動して、Ｓｉｎｋ機器ＢとＴＣＰ／ＩＰ通信ができる状態に遷移する。具体的には、Ｓｏｕｒｃｅ機器Ａは、ａｃｃｅｐｔ（）メソッドを実施してｓｏｃｋｅｔオブジェクトを取得し、そのｓｏｃｋｅｔに結び付いた状態でＴＴＬフィールド値をチェックするための処理を起動し、ｒｅｃｖ（）／ｓｅｎｄ（）メソッドによりバイト・データをＳｉｎｋ機器Ｂと送受信することが可能な状態に遷移する。

これによりＳｉｎｋ機器Ｂは、Ｓｏｕｒｃｅ機器ＡとＴＣＰ／ＩＰ通信ができる状態に遷移する。具体的には、Ｓｏｕｒｃｅ機器ＡがＴＣＰコネクション確立要求を受け付ける状態に遷移する際に作成したｓｏｃｋｅｔオブジェクトに対し、ｒｅｃｖ（）／ｓｅｎｄ（）メソッドによりバイト・データをＳｏｕｒｃｅ機器Ａと送受信することが可能な状態に遷移する。

これ以後、ＡＫＥによる認証及び鍵交換手続きが終了する直前までの期間において、Ｓｏｕｒｃｅ機器ＡとＳｉｎｋ機器Ｂはともに、ＤＴＣＰ−ＩＰ ＡＫＥで取り決められたＡＫＥコマンドの送受信手順を実行する。ＡＫＥが終了する直前とは、Ｓｏｕｒｃｅ機器Ａにとっては、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態になるまでの期間に相当し、Ｓｉｎｋ機器Ｂにとっては、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを受信するまでの期間に相当する。

すなわち、Ｓｏｕｒｃｅ機器Ａ及びＳｉｎｋ機器Ｂはともに、受信したＡＫＥ コマンドに対して適時処理を行なった後、そのＡＫＥコマンドを載せたＩＰパケットのヘッダ部からＴＴＬフィールドの値を取得して、それまでに保持していた最大のＴＴＬフィールド値（以下、「最大ＴＴＬフィールド保存値」と呼ぶ）と比較する。ここで、新たに受信したＡＫＥコマンドに対するＴＴＬフィールドの値がより大きかった場合には、最大ＴＴＬフィールド保存値をその値で更新し、最大ＴＴＬフィールド値がより大きかった場合は何もしない。Ｓｏｕｒｃｅ機器Ａ及びＳｉｎｋ機器Ｂは、これら処理を、ＡＫＥコマンドを受信する度に繰り返す。

Ｓｏｕｒｃｅ機器Ａでは、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する直前に、最大ＴＴＬフィールド保存値が３を超えてないかどうかを確認する。

最大ＴＴＬフィールド保存値が３を超えていた場合、コネクションした相手であるＳｉｎｋ機器から受け取った少なくとも一部のＡＫＥコマンドに対するＴＴＬフィールド値が３を超えていること、すなわち当該Ｓｉｎｋ機器がルータのホップ数が３を越える位置に存在することを意味する。したがって、ＴＴＬフィールド値を３以下に設定し、３を超えたＴＴＬフィールドの値であるＩＰパケットを破棄するというＤＴＣＰ−ＩＰの規定を遵守する必要がある。本実施形態では、Ｓｏｕｒｃｅ機器Ａは、ＥＸＣＨＡＮＧＥ＿ＫＥＹｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄ を送信せずに認証失敗として、ＡＫＥの手続きを中止させる。これによって、Ｓｉｎｋ機器Ｂとの間で認証が完了せず、且つコンテンツ伝送の際に暗号化及び復号するための鍵を共有することはなく、受信したいずれのＡＫＥコマンドも破棄したことと同様の効果を得ることができる。

なお、認証失敗をＳｉｎｋ機器Ｂへ伝える方法として、「確立していたＴＣＰコネクションを切断する」という方法や「ＡＫＥ＿ＣＡＮＣＥＬ ｓｕｂｆｕｎｃｔｉｏｎｃｏｍｍａｎｄ をＳｉｎｋ機器Ｂに送信する」という方法がある。通知を受けたＳｉｎｋ機器はＡＫＥコマンドを載せたＩＰパケットの再送手順を起動することはない。

一方、最大ＴＴＬフィールド保存値が３を超えていなかった場合には、コネクションした相手であるＳｉｎｋ機器Ｂから受け取ったいずれのＡＫＥコマンドに対するＴＴＬフィールド値が３を超えていないこと、すなわち当該Ｓｉｎｋ機器がルータのホップ数が３以内の位置に存在することを意味する。この場合、ＴＴＬフィールド値を３以下に設定するというＤＴＣＰ−ＩＰの規定に抵触しないので、Ｓｏｕｒｃｅ機器Ａは、ＥＸＣＨＡＮＧＥ＿ＫＥＹｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄ を送信し、その後の処理を継続する。

同様に、Ｓｉｎｋ機器Ｂでは、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄ を受信した直後に、最大ＴＴＬフィールド保存値が３を超えてないかどうかを確認する。

最大ＴＴＬフィールド保存値が３を超えていた場合、コネクションした相手であるＳｏｕｒｃｅ機器から受け取った少なくとも一部のＡＫＥコマンドに対するＴＴＬフィールド値が３を超えており、ＤＴＣＰ−ＩＰの規定に抵触していることを意味するから、３を超えたＴＴＬフィールドの値であるＩＰパケットを破棄する必要がある。本実施形態では、Ｓｉｎｋ機器Ｂは、ＲＥＪＥＣＴＥＤｒｅｓｐｏｎｓｅを送信し、ＡＫＥの手続きを中止させる。あるいは、ＲＥＪＥＣＴＥＤ ｒｅｓｐｏｎｓｅ を送信せずに、いきなり ＴＣＰコネクションを切断するなどの処理をとってもよい。これによって、Ｓｏｕｒｃｅ機器Ａとの間で認証が完了せず、且つコンテンツ伝送の際に暗号化及び復号するための鍵を共有することはなく、受信したいずれのＡＫＥコマンドも破棄したことと同様の効果を得ることができる。

一方、最大ＴＴＬフィールド保存値が３を超えていなかった場合には、コネクションした相手であるＳｏｕｒｃｅ機器Ａから受け取ったいずれのＡＫＥコマンドに対するＴＴＬフィールド値が３を超えていないこと、すなわち当該Ｓｏｕｒｃｅ機器がルータのホップ数が３以内の位置に存在することを意味する。この場合、ＴＴＬフィールド値を３以下に設定するというＤＴＣＰ−ＩＰの規定に抵触しないので、Ｓｉｎｋ機器Ｂは、ＥＸＣＨＡＮＧＥ＿ＫＥＹｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄに対応するＡＣＣＥＰＴＥＤ ｒｅｓｐｏｎｓｅを送信し、その後の処理を継続する。

なお、ＡＫＥコマンドを送受信する期間にＴＴＬフィールドの値をモニタすルータの方法として、ＩＰパケットをモニタしてＴＴＬフィールドの値を次々取得して最大のＴＴＬフィールド値のみを保持するのではなく、該当期間中に受信したすべてのＩＰパケットのＴＴＬフィールド値を保存してチェックするという方法も挙げられる。

図７には、Ｓｏｕｒｃｅ機器が、ＡＫＥコマンドを運ぶＩＰパケットのＴＴＬフィールド値が３を超えないようにチェックしながら相互認証及び鍵交換（ＡＫＥ）手続きを行なうための処理手順をフローチャートの形式で示している。但し、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へＡＫＥトリガ情報が渡されるより前に、Ｓｏｕｒｃｅ機器はＳｉｎｋ機器からのＡＫＥを受け付けられる状態になっているものとする。

Ｓｏｕｒｃｅ機器は、ＡＫＥトリガ情報に含まれるポート番号でＴＣＰコネクション確立要求を受けられる状態に遷移する（ステップＳ１）。具体的には、Ｓｏｕｒｃｅ機器は、ｓｏｃｋｅｔオブジェクトを作成して、ｂｉｎｄ（）メソッドとｌｉｓｔｅｎ（）メソッドを実行し、Ｓｉｎｋ機器からのｃｏｎｎｅｃｔ（）要求受信待機状態に遷移する。

次いで、Ｓｏｕｒｃｅ機器は、ＡＫＥトリガ情報をＳｉｎｋ機器に渡す（ステップＳ２）。

ここで、Ｓｉｎｋ機器よりＴＣＰコネクション確立要求を受けると（ステップＳ３）、ＴＣＰコネクションを確立させる（ステップＳ４）。そして、ＩＰパケットのＴＴＬフィールド値のチェック処理を起動して（ステップＳ５）、Ｓｉｎｋ機器とＴＣＰ／ＩＰ通信ができる状態に遷移する。具体的には、ａｃｃｅｐｔ（）メソッドを実施してｓｏｃｋｅｔオブジェクトを取得し、そのｓｏｃｋｅｔに結び付いた状態でＴＴＬフィールド値をチェックするための処理を起動し、ｒｅｃｖ（）／ｓｅｎｄ（）メソッドによりバイト・データをＳｉｎｋ機器と送受信することが可能な状態に遷移する。このとき、最大ＴＴＬフィールドの保存値に初期値０に代入しておく（ステップＳ６）。

これによりＳｉｎｋ機器は、Ｓｏｕｒｃｅ機器とＴＣＰ／ＩＰ通信ができる状態に遷移する。具体的には、Ｓｏｕｒｃｅ機器がＴＣＰコネクション確立要求を受け付ける状態に遷移する際に作成したｓｏｃｋｅｔオブジェクトに対し、ｒｅｃｖ（）／ｓｅｎｄ（）メソッドによりバイト・データをＳｏｕｒｃｅ機器と送受信することが可能な状態に遷移する。

これ以後、ＡＫＥによる認証及び鍵交換手続きが終了する直前までの期間、すなわちＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態になるまでの期間において、ＤＴＣＰ−ＩＰ ＡＫＥで取り決められたＡＫＥコマンドの送受信手順を実施するべく、ステップＳ７〜Ｓ１１を繰り返し実行する。

すなわち、ＡＫＥコマンドを受信すると（ステップＳ８）、ＡＫＥコマンドに対する適時処理を行なうとともに（ステップＳ７）、そのＡＫＥコマンドを載せたＩＰパケットのヘッダ部からＴＴＬフィールドの値を取得して（ステップＳ９）、それまでに保持していた最大のＴＴＬフィールド値（以下、「最大ＴＴＬフィールド保存値」と呼ぶ）と比較する（ステップＳ１０）。ここで、新たに受信したＡＫＥコマンドに対するＴＴＬフィールドの値がより大きかった場合には、最大ＴＴＬフィールド保存値をその値で更新する（ステップＳ１１）。Ｓｏｕｒｃｅ機器では、これらの処理を、ＡＫＥコマンドを受信する度に繰り返す。

ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態に到来すると、Ｓｏｕｒｃｅ機器は、最大ＴＴＬフィールド保存値が３を超えてないかどうかを確認する（ステップＳ１２）。

ここで、最大ＴＴＬフィールド保存値が３を超えていなかった場合には、コネクションした相手となるＳｉｎｋ機器から受け取ったいずれのＡＫＥコマンドに対するＴＴＬフィールドの値が３を超えていないこと、すなわち当該Ｓｉｎｋ機器がルータのホップ数が３以内の位置に存在することを意味する。この場合、ＴＴＬフィールドの値を３以下に設定するというＤＴＣＰ−ＩＰの規定に抵触しないので、Ｓｏｕｒｃｅ機器は、ＥＸＣＨＡＮＧＥ＿ＫＥＹｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄ を送信し（ステップＳ１３）、ＤＴＣＰ−ＩＰ ＡＫＥとしての以降の処理を継続して実行した後（ステップＳ１４）、本処理ルーチンを終了する。

一方、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態に至るまでの処理手続きで、最大ＴＴＬフィールド保存値が３を超えていた場合には（ステップＳ１２）、コネクションした相手となるＳｉｎｋ機器から受け取った少なくとも一部のＡＫＥコマンドに対するＴＴＬフィールド値が３を超えており、ＤＴＣＰ−ＩＰの規定に抵触していることを意味するから、３を超えたＴＴＬフィールドの値であるＩＰパケットを破棄する必要がある。

そこで、Ｓｏｕｒｃｅ機器は、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄ を送信せずに認証失敗として、ＡＫＥの手続きを中止させる（ステップＳ１５）。具体的には、Ｓｏｕｒｃｅ機器は、確立していたＴＣＰコネクションを切断する、あるいはＡＫＥ＿ＣＡＮＣＥＬｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄ をＳｉｎｋ機器に送信するという処理を実行した後、本処理ルーチンを終了する。これによって、Ｓｉｎｋ機器との間で認証が完了せず、且つコンテンツ伝送の際に暗号化及び復号するための鍵を共有することはなく、受信したいずれのＡＫＥコマンドも破棄したことと同様の効果を得ることができる。

図８には、Ｓｉｎｋ機器が、ＡＫＥコマンドを運ぶＩＰパケットのＴＴＬフィールド値が３を超えないようにチェックしながら相互認証及び鍵交換（ＡＫＥ）手続きを行なうための処理手順をフローチャートの形式で示している。但し、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へＡＫＥトリガ情報が渡されるより前に、Ｓｏｕｒｃｅ機器はＳｉｎｋ機器からのＡＫＥを受け付けられる状態になっているものとする。

まず、ＵＰｎＰ ＣＤＳなどを利用して、Ｓｏｕｒｃｅ機器よりＡＫＥトリガ情報を受信すると（ステップＳ２１）、ＴＣＰコネクション確立のための準備を行なう（ステップＳ２２）。そして、ＩＰパケットのＴＴＬフィールド値をチェックするための処理を起動する（ステップＳ２３）。具体的には、ｓｏｃｋｅｔオブジェクトを作成し、そのｓｏｃｋｅｔに結び付いた状態でＴＴＬフィールド値のチェック処理を起動する。このとき、最大ＴＴＬフィールドの保存値に初期値０に代入しておく（ステップＳ２４）。

続いて、ＡＫＥトリガ情報に含まれるＩＰアドレスとポート番号を用いて、Ｓｏｕｒｃｅ機器に対して、ＴＣＰコネクション確立要求を実施する（ステップＳ２５）。具体的には、ｃｏｎｎｅｃｔ（）メソッドを実施する。

これによりＳｉｎｋ機器は、Ｓｏｕｒｃｅ機器とＴＣＰ／ＩＰ通信ができる状態に遷移する。具体的には、Ｓｏｕｒｃｅ機器がＴＣＰコネクション確立要求を受け付ける状態に遷移する際に作成したｓｏｃｋｅｔオブジェクトに対し、ｒｅｃｖ（）／ｓｅｎｄ（）メソッドによりバイト・データをＳｏｕｒｃｅ機器と送受信することが可能な状態に遷移する。

これ以後、ＡＫＥによる認証及び鍵交換手続きが終了する直前までの期間、すなわちＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを受信するまでの期間において、ＤＴＣＰ−ＩＰ ＡＫＥで取り決められたＡＫＥコマンドの送受信手順を実施するべく、ステップＳ２７〜Ｓ３１を繰り返し実行する。

すなわち、ＡＫＥコマンドを受信すると（ステップＳ２８）、ＡＫＥコマンドに対する適時処理を行なうとともに（ステップＳ２７）、そのＡＫＥコマンドを載せたＩＰパケットのヘッダ部からＴＴＬフィールドの値を取得して（ステップＳ２９）、それまでに保持していた最大のＴＴＬフィールド値（以下、「最大ＴＴＬフィールド保存値」と呼ぶ）と比較する（ステップＳ３０）。ここで、新たに受信したＡＫＥコマンドに対するＴＴＬフィールド値がより大きかった場合には、最大ＴＴＬフィールド保存値をその値で更新する（ステップＳ３１）。Ｓｉｎｋ機器では、これらの処理を、ＡＫＥコマンドを受信する度に繰り返す。

そして、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄ を受信した直後に、最大ＴＴＬフィールド保存値が３を超えてないかどうかを確認する（ステップＳ３２）。

ここで、最大ＴＴＬフィールド保存値が３を超えていなかった場合には、コネクションした相手となるＳｏｕｒｃｅ機器から受け取ったいずれのＡＫＥコマンドに対するＴＴＬフィールド値が３を超えていないこと、すなわち当該Ｓｉｎｋ機器がルータのホップ数が３以内の位置に存在することを意味する。この場合、ＴＴＬフィールドの値を３以下に設定するというＤＴＣＰ−ＩＰの規定に抵触しないので、Ｓｉｎｋ機器は、ＥＸＣＨＡＮＧＥ＿ＫＥＹｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄに対応するＡＣＣＥＰＴＥＤ ｒｅｓｐｏｎｓｅを送信し（ステップＳ３３）、ＤＴＣＰ−ＩＰ ＡＫＥとしての以降の処理を継続して実行した後（ステップＳ３４）、本処理ルーチンを終了する。

一方、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄ を受信するまでの処理手続きで、最大ＴＴＬフィールド保存値が３を超えていた場合には（ステップＳ３２）、コネクションした相手となるＳｏｕｒｃｅ機器から受け取った少なくとも一部のＡＫＥコマンドに対するＴＴＬフィールドの値が３を超えており、ＤＴＣＰ−ＩＰの規定に抵触していることを意味するから、３を超えたＴＴＬフィールド値であるＩＰパケットを破棄する必要がある。

そこで、Ｓｉｎｋ機器は、ＡＫＥの手続きを中止させる（ステップＳ３５）。具体的には、ＲＥＪＥＣＴＥＤ ｒｅｓｐｏｎｓｅを送信する、あるいは、ＲＥＪＥＣＴＥＤｒｅｓｐｏｎｓｅ を送信せずに、いきなり ＴＣＰコネクションを切断するなどの処理をとる。これによって、Ｓｏｕｒｃｅ機器との間で認証が完了せず、且つコンテンツ伝送の際に暗号化及び復号するための鍵を共有することはなく、受信したいずれのＡＫＥコマンドも破棄したことと同様の効果を得ることができる。

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

本明細書では、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信するという実施形態を例にとって説明してきたが、本発明の要旨はこれに限定されるものではない。ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送するその他の情報通信システムや、ＩＰパケットのヘッダ部に記載されるＴＴＬフィールド値を用いてルータのホップ数を規定して情報通信可能な相手を所定の範囲に制限するその他の情報通信システムにも、同様に本発明を適用することができる。

また、本明細書では、ルータのホップ数を規定するために、ＩＰｖ４で規定される、ＩＰヘッダ内のＴＴＬフィールドを用いているが、本発明の要旨はこれに限定されるものではなく、パケット内でルータのホップ数を記述したその他の制御情報を利用することも可能である。

ＴＴＬフィールド以外の例として、ＩＰｖ６で規定されるＩＰヘッダ内のＨｏｐ Ｌｉｍｉｔフィールド値を利用することができる（例えば、ＲＦＣ ２４６０ ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ，Ｖｅｒｓｉｏｎ ６（ＩＰｖ６） Ｓｐｅｃｉｆｉｃａｔｉｏｎを参照のこと）。参考のため、図９にＩＰｖ６で規定されるヘッダ構造を図解する。Ｈｏｐ Ｌｉｍｉｔフィールドは８ビットの符号なし整数で構成され、ＩＰパケットがノードで転送される度に１ずつ減算される。そして、Ｈｏｐ Ｌｉｍｉｔ値が消滅したＩＰパケットはそのノードで破棄される。（ＩＰｖ６のＨｏｐＬｉｍｉｔＨｏｐ Ｌｉｍｉｔ Ｆｉｅｌｄ（中継限界数フィールド）は、ＩＰｖ４におけるＴＴＬフィールドとほぼ同じ機能を有する。但し、ＩＰｖ６の中継限界数フィールドではノード間を転送されていくパケットが通過できる中継点の最大数を指定するだけで、時間による制限はできないのに対し、ＩＰｖ４のＴＴＬフィールドでは中継点数だけでなく秒数でも指定することができる。）

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

図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。 図２は、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）として動作する情報通信装置の機能構成を模式的に示した図である。 図３は、図１に示した情報通信システムにおいて、サーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成を模式的に示した図である。 図４は、ＡＫＥコマンドのパケット・フォーマットを示した図である。 図５は、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンスを示した図である。 図６は、Ｓｏｕｒｃｅ機器ＡとＳｉｎｋ機器Ｂの間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）手続きを行なうための動作シーケンス例を示した図である。 図７は、Ｓｏｕｒｃｅ機器がＡＫＥコマンドを運ぶＩＰパケットのＴＴＬフィールド値が３を超えないようにチェックしながら相互認証及び鍵交換（ＡＫＥ）手続きを行なうための処理手順を示したフローチャートである。 図８は、Ｓｉｎｋ機器がＡＫＥコマンドを運ぶＩＰパケットのＴＴＬフィールド値が３を超えないようにチェックしながら相互認証及び鍵交換（ＡＫＥ）手続きを行なうための処理手順を示したフローチャートである。 図９は、ＩＰｖ６で規定されるヘッダ構造を示した図である。

Claims (8)

1. ＩＰネットワーク上で情報通信機器同士がＩＰパケットの交換を行なう情報通信システムであって、
   前記情報通信機器は、
   Ｓｉｎｋとなる他の情報通信機器に対してＳｏｕｒｃｅとしてＤＴＣＰ−ＩＰに準拠したコンテンツ配信する際に、
   ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視して、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得し、
   該取得したＴＴＬフィールド値を保持されている最大ＴＴＬフィールド値と比較し、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記保持されている最大ＴＴＬフィールド値を前記取得したＴＴＬフィールド値で更新し、
   ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態が到来するとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックし、
   前記保持されている最大ＴＴＬフィールド値が前記制限値以下の場合にはＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する、
   ことを特徴とする情報通信システム。
2. ＩＰネットワーク上で情報通信機器同士がＩＰパケットの交換を行なう情報通信システムであって、
   前記情報通信機器は、
   Ｓｏｕｒｃｅとなる他の情報通信機器からＳｉｎｋとしてＤＴＣＰ−ＩＰに準拠したコンテンツ取得を行なう際に、
   ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視して、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得し、
   該取得したＴＴＬフィールド値を保持されている最大ＴＴＬフィールド値と比較し、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記保持されている最大ＴＴＬフィールド値を前記取得したＴＴＬフィールド値で更新し、
   ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを受信したとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックし、
   前記保持されている最大ＴＴＬフィールド値が前記制限値以下のときにはＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄのＡＣＣＥＰＴＥＤｒｅｓｐｏｎｓｅを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する、
   ことを特徴とする情報通信システム。
3. Ｓｉｎｋとなる他の情報通信機器に対してＳｏｕｒｃｅとしてＤＴＣＰ−ＩＰに準拠したコンテンツ配信を行なう情報通信装置であって、
   ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視し、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得するＴＴＬフィールド値取得手段と、
   最大ＴＴＬフィールド値を保持する最大ＴＴＬフィールド値保持手段と、
   前記ＴＴＬフィールド値取得手段で取得したＴＴＬフィールド値を、前記最大ＴＴＬフィールド値保持手段に保持されている最大ＴＴＬフィールド値と比較するＴＴＬフィールド値比較手段と、
   前記ＴＴＬフィールド値比較手段の比較結果に基づき、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記最大ＴＴＬフィールド値保持手段に保持されている最大ＴＴＬフィールド値を、前記取得したＴＴＬフィールド値で更新する最大ＴＴＬフィールド値更新手段と、
   ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態が到来するとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックして、前記保持されている最大ＴＴＬフィールド値が前記制限値以下のときにはＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する制御手段と、
   を具備することを特徴とする情報通信装置。
4. Ｓｏｕｒｃｅとなる他の情報通信機器からＳｉｎｋとしてＤＴＣＰ−ＩＰに準拠したコンテンツ取得を行なう情報通信装置であって、
   ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視し、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得するＴＴＬフィールド値取得手段と、
   最大ＴＴＬフィールド値を保持する最大ＴＴＬフィールド値保持手段と、
   前記ＴＴＬフィールド値取得手段で取得したＴＴＬフィールド値を、前記最大ＴＴＬフィールド値保持手段に保持されている最大ＴＴＬフィールド値と比較するＴＴＬフィールド値比較手段と、
   前記ＴＴＬフィールド値比較手段の比較結果に基づき、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記最大ＴＴＬフィールド値保持手段に保持されている最大ＴＴＬフィールド値を、前記取得したＴＴＬフィールド値で更新する最大ＴＴＬフィールド値更新手段と、
   ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを受信したとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックして、前記保持されている最大ＴＴＬフィールド値が前記制限値以下のときにはＥＸＣＨＡＮＧ＿ＫＥＹｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄのＡＣＣＥＰＴＥＤ ｒｅｓｐｏｎｓｅを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する制御手段と、
   を具備することを特徴とする情報通信装置。
5. Ｓｉｎｋとなる他の情報通信機器に対してＳｏｕｒｃｅとしてＤＴＣＰ−ＩＰに準拠したコンテンツ配信を行なう情報通信方法であって、
   ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視し、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得するＴＴＬフィールド値取得ステップと、
   前記ＴＴＬフィールド値取得ステップで取得したＴＴＬフィールド値を、保持されている最大ＴＴＬフィールド値と比較するＴＴＬフィールド値比較ステップと、
   前記ＴＴＬフィールド値比較ステップの比較結果に基づき、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記保持されている最大ＴＴＬフィールド値を、前記取得したＴＴＬフィールド値で更新する最大ＴＴＬフィールド値更新ステップと、
   ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態が到来するとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックして、前記保持されている最大ＴＴＬフィールド値が前記制限値以下のときにはＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する制御ステップと、
   を具備することを特徴とする情報通信方法。
6. Ｓｏｕｒｃｅとなる他の情報通信機器からＳｉｎｋとしてＤＴＣＰ−ＩＰに準拠したコンテンツ取得を行なう情報通信方法であって、
   ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視し、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得するＴＴＬフィールド値取得ステップと、
   前記ＴＴＬフィールド値取得ステップで取得したＴＴＬフィールド値を、保持されている最大ＴＴＬフィールド値と比較するＴＴＬフィールド値比較ステップと、
   前記ＴＴＬフィールド値比較ステップの比較結果に基づき、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記保持されている最大ＴＴＬフィールド値を、前記取得したＴＴＬフィールド値で更新する最大ＴＴＬフィールド値更新ステップと、
   ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを受信したとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックして、前記保持されている最大ＴＴＬフィールド値が前記制限値以下のときにはＥＸＣＨＡＮＧ＿ＫＥＹｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄのＡＣＣＥＰＴＥＤ ｒｅｓｐｏｎｓｅを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する制御ステップと、
   を具備することを特徴とする情報通信方法。
7. Ｓｉｎｋとなる他の情報通信機器に対してＳｏｕｒｃｅとしてＤＴＣＰ−ＩＰに準拠したコンテンツ配信を行なうための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
   ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視し、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得するＴＴＬフィールド値取得手順と、
   前記ＴＴＬフィールド値取得手順で取得したＴＴＬフィールド値を、保持されている最大ＴＴＬフィールド値と比較するＴＴＬフィールド値比較手順と、
   前記ＴＴＬフィールド値比較手順の比較結果に基づき、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記保持されている最大ＴＴＬフィールド値を、前記取得したＴＴＬフィールド値で更新する最大ＴＴＬフィールド値更新手順と、
   ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する状態が到来するとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックして、前記保持されている最大ＴＴＬフィールド値が前記制限値以下のときにはＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する制御手順と、
   を実行させることを特徴とするコンピュータ・プログラム。
8. Ｓｏｕｒｃｅとなる他の情報通信機器からＳｉｎｋとしてＤＴＣＰ−ＩＰに準拠したコンテンツ取得を行なうための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、前記コンピュータ・システムに対し、
   ＡＫＥコマンドを送受信するためのＴＣＰコネクションを確立した後に、受信した前記ＡＫＥコマンドを運ぶＩＰパケットを監視し、該ＩＰパケットのヘッダ部からＴＴＬフィールド値を取得するＴＴＬフィールド値取得手順と、
   前記ＴＴＬフィールド値取得手順で取得したＴＴＬフィールド値を、保持されている最大ＴＴＬフィールド値と比較するＴＴＬフィールド値比較手順と、
   前記ＴＴＬフィールド値比較手順の比較結果に基づき、前記取得したＴＴＬフィールド値が前記保持されている最大ＴＴＬフィールド値より大きかった場合には、前記保持されている最大ＴＴＬフィールド値を、前記取得したＴＴＬフィールド値で更新する最大ＴＴＬフィールド値更新手順と、
   ＥＸＣＨＡＮＧ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄを受信したとき、前記保持されている最大ＴＴＬフィールド値が制限値以下であるかどうかをチェックして、前記保持されている最大ＴＴＬフィールド値が前記制限値以下のときにはＥＸＣＨＡＮＧ＿ＫＥＹｓｕｂｆｕｎｃｔｉｏｎ ｃｏｍｍａｎｄのＡＣＣＥＰＴＥＤ ｒｅｓｐｏｎｓｅを送信する処理に移行し、前記保持されている最大ＴＴＬフィールド値が前記制限値を超える場合にはＡＫＥ手続きを中止する制御手順と、
   を実行させることを特徴とするコンピュータ・プログラム。

Images