情報通信装置及び情報通信方法、並びにコンピュータ・プログラム
【課題】 ＴＣＰストリームから正確にＡＫＥコマンドを抽出する。
【解決手段】 ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値のチェック、ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位及び下位それぞれ４ビットから抽出されるｒｅｓｅｒｖｅｒ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値のチェック、並びに、バイト・データの所定バイト位置から取得したｓｕｂｆｕｎｃｔｉｏｎを取得した後にＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする。
【解決手段】 ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値のチェック、ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位及び下位それぞれ４ビットから抽出されるｒｅｓｅｒｖｅｒ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値のチェック、並びに、バイト・データの所定バイト位置から取得したｓｕｂｆｕｎｃｔｉｏｎを取得した後にＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、著作権保護若しくはその他の目的で暗号化された伝送コンテンツを受信処理する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを実行する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。
【０００２】
さらに詳しくは、本発明は、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）の手続きを実行する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰ−ＩＰに準拠した別の情報機器から送られてくるＴＣＰペイロードから認証用制御（ＡＫＥ）コマンドを正確に抽出する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【０００３】
最近、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んに行なわれる。この種のサービスでは、ＣＤやＤＶＤなどのメディアの移動を必要とせず、ネットワークを経由して遠隔端末間でコンテンツ配信を行なうことができる。一方、ネットワーク経由で取り扱われるコンテンツは、著作物の１つとして、著作権法の下で無断の複製や改竄などの不正使用から保護を受ける。著作権法では、同法第３０条において、個人的に又は家庭内などを使用目的とした場合の使用者本人の複製を許容する一方、同法第４９条第１項においては、私的使用以外での複製物の使用を禁止している。また、デジタル・コンテンツはコピーや改竄などの不正な操作が比較的容易であることから、法的な整備だけでなく技術的な側面からも、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。
【０００４】
例えば、デジタル伝送コンテンツの保護に関する業界標準であるＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）では、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定している（例えば、非特許文献１を参照のこと）。ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器はＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。
【０００５】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。最近では、ＩＥＥＥ１３９４ベースで規定されたＤＴＣＰ技術をＩＰネットワークに移植した技術の開発が進められている（以降、この技術をＤＴＣＰ−ＩＰと呼ぶ）。
【０００６】
ＤＴＣＰ−ＩＰは、ＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であるが、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰやＲＴＰプロトコルを使用するという点で、ＩＥＥＥ１３９４ベースで規定された本来のＤＴＣＰとは相違する。ホーム・ネットワークの多くはルータなどを経由してインターネットなどの外部の広域ネットワークに接続されているので、ＤＴＣＰ−ＩＰ技術の確立により、デジタル・コンテンツを保護しながらＩＰネットワークを利用した柔軟で効率的なコンテンツの利用が図られる。他方、ＩＰネットワーク上にはＰＣを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高いことから、ＤＴＣＰ−ＩＰは、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献２を参照のこと）。
【０００７】
ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順について以下に説明しておく。但し、ＤＴＣＰに準拠した機器は２つの種類に分類される。１つはＤＴＣＰ＿Ｓｏｕｒｃｅと言い、コンテンツの要求を受理し、コンテンツを送信するサーバ機器である。もう１つはＤＴＣＰ＿Ｓｉｎｋと言い、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアント機器である。
【０００８】
ＤＴＣＰ＿ＳｏｕｒｃｅとＤＴＣＰ＿Ｓｉｎｋはまず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証をＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）と呼ばれる認可組織によりユニークな機器ＩＤや鍵が埋め込まれている。ＤＴＣＰ認証手続きでは、このような情報を用いて互いが正規のＤＴＣＰ準拠機器であることを確かめた後、コンテンツを暗号化若しくは復号するためのＤＴＣＰ＿Ｓｏｕｒｃｅが管理している鍵をＤＴＣＰ＿Ｓｉｎｋ機器と共有することができる。
【０００９】
そして、ＤＴＣＰ準拠の機器間で認証手続きが済んだ後、ＤＴＣＰ＿ＳｉｎｋはＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツを要求する。ＤＴＣＰ＿Ｓｏｕｒｃｅは、ＣＤＳ（Ｃｏｎｔｅｎｔｓ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＤＴＣＰ＿ＳｉｎｋにＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。ＤＴＣＰ＿Ｓｉｎｋがコンテンツを要求するとき、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）などのプロトコルを利用することができる。ＨＴＴＰの手続きに従ってコンテンツを要求する場合、ＤＴＣＰ＿ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＤＴＣＰ＿ＳｉｎｋがＨＴＴＰクライアントとなって、コンテンツの伝送を開始する。また、ＲＴＰによる伝送を要求するとき、ＤＴＣＰ＿ＳｏｕｒｃｅがＲＴＰ Ｓｅｎｄｅｒとなり、ＤＴＣＰ＿ＳｉｎｋがＲＴＰ Ｒｅｃｅｉｖｅｒとなってコンテンツの伝送を開始する。なお、これらの通信手続き以外にもＲＳＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などの伝送プロトコルも適用が可能である。
【００１０】
ＨＴＴＰでコンテンツ伝送を行なう際、ＤＴＣＰ認証のためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成される。そして、ＨＴＴＰクライアントは、通常のＨＴＴＰと全く同様の動作手順によりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。但し、ＨＴＴＰレスポンスとして伝送されるデータは、ＨＴＴＰサーバすなわちＤＴＣＰ＿Ｓｏｕｒｃｅ機器がＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。暗号化されたデータを受信したクライアント（ＤＴＣＰ＿Ｓｉｎｋ）は同様に、先の認証をした後に共有した鍵によりデータを復号し、再生若しくは記録を行なうことができる。
【００１１】
このように、ＤＴＣＰ−ＩＰは、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路の途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。
【００１２】
上述したように、ＤＴＣＰでは、コンテンツ提供元であるサーバ（ＤＴＣＰ Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（ＤＴＣＰ Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なうことを取り決めている。ここで、ＤＴＣＰ、並びにＤＴＣＰ−ＩＰそれぞれにおいてＡＫＥコマンドを伝送する手順について考察してみる。
【００１３】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４を伝送路に用いたデジタル・コンテンツの伝送について規定したものである。一方、ＤＴＣＰ−ＩＰは、基本的にはＤＴＣＰ規格に含まれるものであるが、伝送路にＩＥＥＥ１３９４に代えてＩＰネットワークを使用する点が大きな相違点となる。
【００１４】
ＩＥＥＥ１３９４は基本的にはＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤに相当する。このことから、コマンド送信元のＤＴＣＰ機器は、個々のＡＫＥコマンドをそれぞれ１つのＭＡＣフレームに乗せて転送すればよく、コマンド受信先のＤＴＣＰ機器はＭＡＣフレームから１つのＡＫＥコマンドを取り出せばよい（例えば、非特許文献３を参照のこと）。
【００１５】
これに対し、ＤＴＣＰ−ＩＰでは、送信データはＴＣＰバイト・ストリームの形式をとるため、ＡＫＥコマンド送信元のＤＴＣＰ機器側では、ＩＰプロトコル層によりＴＣＰペイロードを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける（例えば、非特許文献４を参照のこと）。一方、ＡＫＥコマンド受信先となるＤＴＣＰ機器側では、各ＩＰパケットを受信すると、これをＴＣＰバイト・ストリームに組み立て、さらにＴＣＰバイト・ストリームからＡＫＥコマンドを取り出さなければならない（図８を参照のこと）。
【００１６】
コマンド受信側でバイト・ストリームからＡＫＥコマンドを取り出すことができなければ、ＡＫＥによる認証手続き自体が成功せず、この結果コンテンツ鍵を共有できないことから、本来はコンテンツを利用できるＤＴＣＰ機器であってもコンテンツを利用できなくなるというという問題を招来する。
【００１７】
当業界において周知のように、通信プロトコルはＴＣＰやＩＰといった複数のプロトコルのスタック構造をなし、これらの最上位層としてアプリケーションが位置付けられる。ＴＣＰ／ＩＰ上でＤＴＣＰアプリケーションを実装するためには、ＴＣＰペイロードから個々のＡＫＥコマンドを取り出すための明確な意図を持った処理方法が必要である。しかしながら、ＤＴＣＰ−ＩＰ自体ではこの種の意味のある処理方法については特に取り決めは存在しない。
【００１８】
【非特許文献１】ＤＴＣＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｏｌｕｍｅ １ Ｖｅｒｓｉｏｎ １．３ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００４０１０７＿ｄｔｃｐ＿Ｖｏｌ＿１＿１ｐ３．ｐｄｆ
【非特許文献２】ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｍａｐｐｉｎｇ ＤＴＣＰ ｔｏ ＩＰ， Ｖｅｒｓｉｏｎ １．０ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００３１１２４＿ｄｔｃｐ＿ＶＩＳＥ＿１ｐ０．ｐｄｆ／
【非特許文献３】ＡＶ／Ｃ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ Ｃｏｍｍａｎｄ Ｓｅｔ Ｇｅｎｅｒａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ ４．１
【非特許文献４】ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ） ７９１ ＩＮＴＥＲＮＥＴ ＰＲＯＴＯＣＯＬ
【発明の開示】
【発明が解決しようとする課題】
【００１９】
本発明の目的は、著作権保護若しくはその他の目的で暗号化された伝送コンテンツを好適に受信処理することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【００２０】
本発明のさらなる目的は、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを好適に実行することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【００２１】
本発明のさらなる目的は、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）の手続きを好適に実行することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【００２２】
本発明のさらなる目的は、ＤＴＣＰ−ＩＰに準拠した別の情報機器から送られてくるＴＣＰペイロードから認証用制御（ＡＫＥ）コマンドを正確に抽出することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【課題を解決するための手段】
【００２３】
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した他の情報通信装置との間で相互認証及び鍵交換のための認証制御用（ＡＫＥ）コマンドを受信する情報通信装置であって、ＡＫＥコマンドは、先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドを備え、該他の情報通信装置からＴＣＰストリームとして送られてくるバイト・データからＡＫＥコマンドを抽出する際に、
受信したＴＣＰストリームからバイト・データをＡＫＥコマンド抽出用情報として取得するＡＫＥコマンド抽出用情報取得手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値を取得する第１の情報取得手段と、
Ｔｙｐｅフィールド及びＢＬＣフィールドの値をチェックする第１の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド値として取得するとともに、下位４ビットをＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを示すｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールド値として取得する第２の情報取得手段と、
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第２の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する第３の情報取得手段と、
ＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第３の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンドを抽出するコマンド抽出手段と、
ＡＫＥコマンドを送信するコマンド送信手段と、
ＡＫＥコマンドの受信処理を起動するコマンド受信処理起動手段と、
を具備することを特徴とする情報通信装置である。
【００２４】
本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システムに関するものであり、特に、具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信し、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なう情報通信システムに関する。
【００２５】
ＤＴＣＰ−ＩＰは、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送際に暗号化及び復号をすることにより、伝送路途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。
【００２６】
ここで、ＤＴＣＰに準拠したコンテンツ伝送を実現するには、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器間でＡＫＥ手続きを成功裏に実施する必要がある。
【００２７】
ＤＴＣＰは原初的にはＩＥＥＥ１３９４を伝送路に用いたデジタル・コンテンツの伝送を規定したものであるが、この場合、ＡＫＥコマンド毎に１つのＭＡＣフレームを用いて伝送が行なわれるので、受信側のＤＴＣＰ機器では正しくＡＫＥコマンドを読み取ることができる。
【００２８】
一方、ＤＴＣＰ−ＩＰでは、送信データはＴＣＰバイト・ストリームの形式をとるため、ＡＫＥコマンド受信先となるＤＴＣＰ機器側では、各ＩＰパケットを受信すると、これをＴＣＰバイト・ストリームに組み立て、さらにＴＣＰバイト・ストリームからＡＫＥコマンドを取り出さなければならない。ＴＣＰペイロードから個々のＡＫＥコマンドを取り出すための明確な意図を持った処理方法が必要であるが、ＤＴＣＰ−ＩＰ自体ではこの種の意味のある処理方法については特に取り決めは存在しない。
【００２９】
これに対し、本実施形態に係る情報通信装置は、ＡＫＥコマンドが先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドからなるデータ構造を備えていることに着目し、ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値のチェック、ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位及び下位それぞれ４ビットから抽出されるｒｅｓｅｒｖｅｒ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値のチェック、並びに、バイト・データの所定バイト位置から取得したｓｕｂｆｕｎｃｔｉｏｎを取得した後にＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックすることによって、ＴＣＰストリームの形で送られてくるバイト・データから正確にＡＫＥコマンドを抽出することができる。ここで言うＡＫＥコマンドにはＡＫＥコマンド・リクエストとＡＫＥコマンド・レスポンスの両方が含まれる。
【００３０】
勿論、当該情報通信装置は、受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容次第では、ＡＫＥコマンドを抽出することなく、取得したバイト・データを読み捨てることもある。あるいは、受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容に応じて、ＡＫＥコマンドを抽出せずに、ＡＫＥコマンド・レスポンスを送信することもある。
【００３１】
具体的には、前記第１の情報チェック手段は、取得したＴｙｐｅフィールド又はＢＬＣフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックする。そして、該チェック結果が否定的であるときには、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄手段が読み捨てるようにする。
【００３２】
また、前記第２の情報チェック手段は、取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド又はｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックする。そして、該チェック結果が否定的であるときには、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄手段が読み捨てるようにする。
【００３３】
また、前記第３の情報チェック手段は、ＢＬＣフィールドの値が示すバイト長ではＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できないときには、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする。
【００３４】
ここで、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときには、前記コマンド抽出手段はバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信手段は、非実装であることを示すＡＫＥコマンド・レスポンスを送信するようにする。あるいは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときには、前記コマンド・レスポンス抽出手段は非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理起動手段は非実装レスポンスの受信処理を起動するようにする。あるいは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が通常のレスポンス・コードであるときには、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄手段が読み捨てるようにする。
【００３５】
他方、ＢＬＣフィールドの値が示すバイト長でＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できるときには、前記第３の情報取得手段はＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する。そして、前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に応じてＢＬＣフィールドの値をチェックする。
【００３６】
ここで、前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときに、前記第３の情報取得手段により取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックする。そして、該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・リクエストを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・リクエストの受信処理を起動するようにする。あるいは、該チェック結果が否定的であれば、前記コマンド抽出手段はバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信手段は、非実装であることを示すＡＫＥコマンド・レスポンスを送信するようにする。
【００３７】
また、前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的でないレスポンス・コードを示すときに、前記第３の情報取得手段により取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックする。そして、該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・レスポンスの受信処理を起動するようにする。あるいは、該チェック結果が否定的であれば、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てるようにする。
【００３８】
また、前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的なレスポンス・コードを示すときに、ＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックする。そして、該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・レスポンスの受信処理を起動するようにする。あるいは、該チェック結果が否定的であれば、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てるようにする。
【００３９】
また、前記第３の情報チェック手段がｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときと判定したときには、前記コマンド・レスポンス抽出手段は非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理起動手段は非実装レスポンスの受信処理を起動するようにする。
【００４０】
また、本発明の第２の側面は、ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した他の情報通信装置との間で相互認証及び鍵交換のための認証制御用（ＡＫＥ）コマンドを受信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、ＡＫＥコマンドは、先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドを備え、該他の情報通信装置からＴＣＰストリームとして送られてくるバイト・データからＡＫＥコマンドを抽出する際に、前記コンピュータ・システムに対し、
受信したＴＣＰストリームからバイト・データをＡＫＥコマンド抽出用情報として取得するＡＫＥコマンド抽出用情報取得手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値を取得する第１の情報取得手順と、
Ｔｙｐｅフィールド及びＢＬＣフィールドの値をチェックする第１の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド値として取得するとともに、下位４ビットをＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを示すｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールド値として取得する第２の情報取得手順と、
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第２の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する第３の情報取得手順と、
ＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第３の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンドを抽出するコマンド抽出手順と、
ＡＫＥコマンドを送信するコマンド送信手順と、
ＡＫＥコマンドの受信処理を起動するコマンド受信処理起動手順と、
を実行させることを特徴とするコンピュータ・プログラムである。
【００４１】
本発明の第２の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係る情報通信装置と同様の作用効果を得ることができる。
【発明の効果】
【００４２】
本発明によれば、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを好適に実行することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。
【００４３】
また、本発明によれば、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）の手続きを好適に実行することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。
【００４４】
また、本発明によれば、ＤＴＣＰ−ＩＰに準拠した別の情報機器から送られてくるＴＣＰペイロードから認証用制御（ＡＫＥ）コマンドを正確に抽出することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。
【００４５】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【発明を実施するための最良の形態】
【００４６】
以下、図面を参照しながら本発明の実施形態について詳解する。
【００４７】
本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システムに関するものであり、特に、具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信し、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なう情報通信システムに関する。
【００４８】
ＤＴＣＰ−ＩＰでは、送信データはＴＣＰバイト・ストリームの形式をとるため、ＡＫＥコマンド送信元のＤＴＣＰ機器側では、ＩＰプロトコル層によりＴＣＰペイロードを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。一方、ＡＫＥコマンド受信先となるＤＴＣＰ機器側では、各ＩＰパケットを受信すると、これをＴＣＰバイト・ストリームに組み立て、さらにＴＣＰバイト・ストリームからＡＫＥコマンドを取り出さなければならない。
【００４９】
Ａ．システム構成
ＤＴＣＰ−ＩＰに従ったコンテンツ伝送は、コンテンツの要求を受理してコンテンツを送信するサーバとしてのＳｏｕｒｃｅ機器と、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアントとしてのＳｉｎｋ機器で構成される。図１には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。
【００５０】
図示の例では、Ｓｏｕｒｃｅ機器Ａ〜Ｂ、Ｓｉｎｋ機器Ａ〜Ｂ及び中継機器Ａ〜Ｃの各エンティティにより、ＤＴＣＰ−ＩＰ ＡＫＥシステムが構築されている。
【００５１】
ＤＴＣＰ−ＩＰ に準拠した認証サーバであるＳｏｕｒｃｅ機器ＡとＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器Ａが中継機器Ａと中継機器Ｂを経由してネットワークで接続されている。
【００５２】
また、中継機器Ａ、中継機器Ｂ、中継機器Ｃ を経由して、ＤＴＣＰ−ＩＰに準拠した認証サーバであるＳｏｕｒｃｅ機器ＢやＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器ＢがＩＰネットワークで接続されている。
【００５３】
図２及び図３には、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）及びサーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成をそれぞれ模式的に示している。Ｓｉｎｋ機器とＳｏｕｒｃｅ機器は、インターネットなどの図示しないＴＣＰ／ＩＰネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。
【００５４】
図２に示すＳｉｎｋ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｉｎｋとして動作する。図示のクライアント機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ受信ブロックと、コンテンツ再生／記録ブロックを備えている。
【００５５】
ＤＴＣＰ−ＩＰ認証ブロックは、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ復号ブロックを備えている。
【００５６】
ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｉｎｋ側）を実現するブロックでる。このＡＫＥブロックは後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。
【００５７】
メッセージ・ダイジェスト生成ブロックは、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる（ＳＨＡ−１は、ＭＤ５と同様、ＭＤ４を改良したものに相当するが、１６０ビットのハッシュ値を生成するので、強度はＭＤシリーズを上回る）。
【００５８】
メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【００５９】
コンテンツ復号ブロックは、サーバから受信した暗号化されたコンテンツ・データをＡＫＥで交換した鍵を用いてコンテンツの復号鍵を算出し、暗号コンテンツを復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生／記録ブロックへ渡される。
【００６０】
コンテンツ再生／記録ブロックは、渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合は保存する。
【００６１】
ＤＴＣＰ−ＩＰコンテンツ受信ブロックは、ＡＫＥを実施した後にコンテンツ伝送手続きを実行する処理モジュールである。図示の例では、ＤＴＣＰ−ＩＰコンテンツ受信ブロックはＨＴＴＰクライアント・ブロックを持ち、ＨＴＴＰクライアントとしてＨＴＴＰサーバへコンテンツを要求し、応答されたコンテンツをＨＴＴＰサーバから受信する。
【００６２】
ＨＴＴＰクライアント・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト送信ブロックとＨＴＴＰリクエスト生成ブロックへ分かれる。
【００６３】
ＨＴＴＰリクエスト生成ブロックは、送信するコンテンツ伝送要求（ＨＴＴＰリクエスト)を生成する。ここで生成されたＨＴＴＰリクエストは、ＨＴＴＰリクエスト送信ブロックによりサーバへ送信される。
【００６４】
ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス受信ブロックとＨＴＴＰレスポンス解釈ブロックに分かれる。サーバから返信されるＨＴＴＰレスポンスと暗号化されたコンテンツは、ＨＴＴＰ受信ブロックで受信される。ここで受信したＨＴＴＰレスポンスは、ＨＴＴＰレスポンス解釈ブロックでチェックされる。ここでのチェックがＯＫの場合は受信した暗号化コンテンツをＤＴＣＰに認証ブロック内のコンテンツ復号ブロックへ送る。また、このチェックがＮＧの場合は、エラー・レスポンスとしての処理を行なう。
【００６５】
ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ受信ブロックは、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【００６６】
また、図３に示すＳｏｕｒｃｅ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｏｕｒｃｅとして動作する。サーバ機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ送信ブロックと、コンテンツ管理ブロックを備えている。
【００６７】
ＤＴＣＰ−ＩＰ認証ブロックは、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ暗号化ブロックを備えている。
【００６８】
ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｏｕｒｃｅ側）を実現するブロックである。このブロックは、後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。ＡＫＥブロックは認証したＤＴＣＰ＿Ｓｉｎｋ機器に関する情報を認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。
【００６９】
メッセージ・ダイジェスト生成ブロックは指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定できる。あらかじめ用意されたアルゴリズムとは、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる（同上）。
【００７０】
メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【００７１】
コンテンツ暗号化ブロックは、ＤＴＣＰ−ＩＰコンテンツ送信ブロックの要求に応じて、コンテンツ管理ブロックより読み出したコンテンツ・データをＡＫＥで交換した鍵から生成したコンテンツ鍵を用いて暗号化するブロックである。ここで復号されたコンテンツは、クライアントへ送信するために、ＤＴＣＰ−ＩＰコンテンツ送信ブロックへ渡される。
【００７２】
コンテンツ管理ブロックは、ＤＴＣＰ−ＩＰの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。
【００７３】
ＤＴＣＰ−ＩＰコンテンツ送信ブロックは、ＨＴＴＰサーバ・ブロックを持ち、ＨＴＴＰサーバとしてクライアントからのリクエストを受理し要求に応じた処理を実行する。
【００７４】
ＨＴＴＰサーバ・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト受信ブロックと、ＨＴＴＰリクエスト解釈ブロックに分かれる。
【００７５】
ＨＴＴＰリクエスト受信ブロックは、クライアントからのＨＴＴＰリクエストを受信する。受信したＨＴＴＰリクエストはＨＴＴＰリクエスト解釈ブロックに送られ、チェックされる。ＨＴＴＰリクエスト解釈ブロックにおけるチェックがＯＫの場合、ＨＴＴＰリクエストの情報をＤＴＣＰ−ＩＰ認証ブロックへ通知する。
【００７６】
ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス生成ブロックとＨＴＴＰレスポンス送信ブロックに分かれる。
【００７７】
ＨＴＴＰレスポンス生成ブロックは、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合、暗号化されたコンテンツを返すためのＨＴＴＰレスポンスを作成する。一方、ＨＴＴＰリクエスト解釈ブロックでのチェックがＮＧの場合、エラーを返すためのＨＴＴＰレスポンスを作成する。
【００７８】
ＨＴＴＰレスポンス送信ブロックは、作成されたＨＴＴＰレスポンスを、要求元のクライアントへＨＴＴＰレスポンスを送信する。また、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合には、ＨＴＴＰレスポンス・ヘッダに続けて、ＤＴＣＰ−ＩＰ認証ブロック内のコンテンツ暗号化ブロックで暗号化したコンテンツを送信する。
【００７９】
ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ送信ブロックは、Ｓｉｎｋ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【００８０】
なお、ＤＴＣＰ−Ｓｉｎｋ機器及びＤＴＣＰ−Ｓｏｕｒｃｅ機器のいずれもがＤＴＣＰ−ＩＰ認証ブロック内に持つメッセージ・ダイジェスト生成ブロックはＤＴＣＰ−ＩＰ自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。例えば、本出願人に既に譲渡されている特願２００４−１１３４５９号公報にはメッセージ・ダイジェスト生成ブロックについて記述されている。
【００８１】
Ｂ．ＨＴＴＰを利用したコンテンツ伝送
図４には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥ手続き、及びＨＴＴＰプロトコルを利用したコンテンツ伝送を行なう仕組みを図解している。既に述べたように、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間では、ＡＫＥ手続き用のＴＣＰコネクションと、ＨＴＴＰを利用したコンテンツ要求用、並びにコンテンツ鍵の確認用のＴＣＰコネクションがそれぞれ独立して確立される（すなわち、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器はそれぞれ、ＡＫＥ手続き用とコンテンツ伝送用、コンテンツ鍵の確認用に個別のソケット（ＩＰアドレスとポート番号の組み合わせ）を持つ）。
【００８２】
まず、ＡＫＥ手続き用のＴＣＰコネクションを確立し、同手続きが成功すると、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間では認証鍵Ｋauthを共有することができる。ＡＫＥ手続きが終了すると、このＴＣＰコネクションは切断される。そして、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器は、それぞれ内部で同様の処理を行なってＫauthからコンテンツ鍵の種となる種鍵Ｋxを生成する。
【００８３】
次いで、ＤＴＣＰ−Ｓｉｎｋ機器側からのコンテンツ要求などに応じて、ＨＴＴＰプロトコルを用いたコンテンツ伝送用のＴＣＰコネクションが確立される。
【００８４】
ＤＴＣＰ＿Ｓｏｕｒｃｅ機器は、ＴＣＰコネクションを初期化する際に、乱数を用いてノンスＮcを生成して、ＫxとＮcを基にコンテンツ鍵Ｋcを生成する。そして、ＤＴＣＰ＿Ｓｉｎｋ機器から要求されているコンテンツを、コンテンツ鍵Ｋcを用いて暗号化し、暗号化コンテンツとノンスＮcからなるＰＣＰ（Ｐｒｏｔｅｃｔｅｄ Ｃｏｎｔｅｎｔ Ｐａｃｋｅｔ）をＴＣＰストリーム上に乗せてＤＴＣＰ＿Ｓｉｎｋ機器に送信する。ＩＰプロトコルは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。
【００８５】
ＤＴＣＰ＿Ｓｉｎｋ機器側では、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器からの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、ストリームからノンスＮcを取り出すと、これと認証鍵Ｋauthから求めた鍵Ｋxを用いてコンテンツ鍵Ｋcを算出する。そして、このコンテンツ鍵Ｋcを用いて受信した暗号化コンテンツを復号することができる。
【００８６】
ＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、コンテンツ伝送用のＴＣＰコネクションを適宜切断することができる。
【００８７】
ここで、長大なＴＣＰストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅ機器は１２８ＭＢのコンテンツ毎にノンスＮcすなわちコンテンツ鍵Ｋcを更新するよう取り決められている。バイト・ストリーム中で、同じノンスＮcから生成されたコンテンツ鍵Ｋcを用いて暗号化されたデータの範囲は、同じ鍵を用いて復号することができる復号化単位となる。
【００８８】
また、バイト・ストリームの途中で復号鍵が動的に変更されることから、コンテンツ鍵の確認手続きが必要となる。そこで、ＤＴＣＰ＿Ｓｉｎｋ機器は、コンテンツ伝送用のＴＣＰコネクションとは別に、コンテンツ鍵の確認用のＴＣＰコネクションをさらに確立し、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器に対しコンテンツ鍵確認のための手続きを行なう。ＤＴＣＰ＿Ｓｉｎｋ機器は、コンテンツ鍵の確認が必要になると、コンテンツ伝送用のＴＣＰコネクションとは別に、適宜このＴＣＰコネクションを確立する。
【００８９】
但し、コンテンツ鍵の動的な変更並びにコンテンツ鍵の確認手続き自体は本発明の要旨には直接関連しないので、ここではこれ以上説明しない。
【００９０】
Ｃ．ＴＣＰペイロードからの認証制御用コマンドの抽出処理
上述したように、ＤＴＣＰ−ＩＰは、ＴＣＰコネクションを介してＤＴＣＰに準拠した機器同士でＡＫＥ認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路の途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。
【００９１】
ＤＴＣＰに準拠したコンテンツ伝送を実現するには、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器間でＤＴＣＰ−ＩＰ ＡＫＥ手続きを成功裏に実施する必要がある。
【００９２】
ＡＫＥコマンドは、基本的にＩＥＥＥ１３９４の上位プロトコルであるＡＶ／Ｃ Ｇｅｎｅｒａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎのサブセットという位置付けである。図６には、ＡＫＥコマンドのパケット・フォーマットを示している（例えば、非特許文献２を参照のこと）。同図に示すように、ＡＫＥコマンドは、１バイトのＴｙｐｅフィールドと、２バイトのＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドからなる。
【００９３】
Ｔｙｐｅ、ＢＬＣ、Ｃｏｎｔｒｏｌ各フィールドの０バイト目は、ＤＴＣＰをＩＰにマッピングするために使用される。Ｔｙｐｅフィールドにより、当該パケットがバージョン１のＡＫＥ制御パケットであることが示される。
【００９４】
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅは、当該ＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを記載するフィールドであり、ＤＴＣＰ仕様第８章及びＡＶ／Ｃデジタル・インターフェース・コマンドによる規定と同じ値を持つ。
【００９５】
Ｃｏｎｔｒｏｌフィールドの１〜７バイトは、ＩＰプロトコルで使用されない場合にはＣｏｎｔｒｏｌフィールドの７バイト目のＭＳＢを除いては、セクション８．３．１に規定されている０〜６バイトのオペランドと同一である。
【００９６】
ＡＫＥコマンドは、サブファンクションという種類に分けることができる。サブファンクションは、ＡＫＥコマンドの６バイト目のｓｕｂｆｕｎｃｔｉｏｎフィールドに記載されている。
【００９７】
ＡＫＥ＿Ｉｎｆｏフィールドは、セクション８．３．１に規定されているデータ・フィールドと同様である。
【００９８】
ＡＫＥ＿ｌａｂｅｌと各制御コマンドのソース・ソケットは適当なコントローラから由来することを確認しなければならない。
【００９９】
また、図７にはＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンスを示している（例えば、非特許文献２を参照のこと）。
【０１００】
Ｓｏｕｒｃｅ機器（又はＳｉｎｋ機器）からＳｉｎｋ機器（又はＳｏｕｒｃｅ機器）へ、ＡＫＥ ｓｔａｔｕｓ ｃｏｍｍａｎｄが送信され、これに対し、Ｓｉｎｋ機器（又はＳｏｕｒｃｅ機器）からＡＫＥ Ｓｔａｔｕｓ ｒｅｓｐｏｎｓｅが返され、その後、Ｓｏｕｒｃｅ機器（又はＳｉｎｋ機器）からＳｉｎｋ機器（又はＳｏｕｒｃｅ機器）へＣＨＡＬＬＥＮＧＥ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器（又はＳｏｕｒｃｅ機器）からｒｅｓｐｏｎｓｅが返される。
【０１０１】
続いて、Ｓｏｕｒｃｅ機器（又はＳｉｎｋ機器）からＳｉｎｋ機器（又はＳｏｕｒｃｅ機器）へ、ＲＥＳＰＯＮＳＥ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器（又はＳｏｕｒｃｅ機器）からＡＫＥ Ｓｔａｔｕｓ ｒｅｓｐｏｎｓｅが返される。
【０１０２】
その後、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へ、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器からｒｅｓｐｏｎｓｅが返される。
【０１０３】
続いて、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へ、ＳＲＭ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器からｒｅｓｐｏｎｓｅが返される。
【０１０４】
続いて、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へ、ＣＯＮＴＥＮＴ＿ＫＥＹ＿ＲＥＱ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器からｒｅｓｐｏｎｓｅが返される。
【０１０５】
但し、ｒｅｑｕｅｓｔはターゲットとなる機器を制御するときに用いられ、ｒｅｓｐｏｎｓｅはｒｅｑｕｅｓｔを受けた機器の応答を示すときに用いられる。コマンド・タイプを持つＡＫＥコマンドは、ＡＫＥコマンド・リクエストであり、レスポンス・コードを持つＡＫＥコマンドはＡＫＥコマンド・レスポンスである。
【０１０６】
ここで、ＤＴＣＰ、並びにＤＴＣＰ−ＩＰそれぞれにおいてＡＫＥコマンドを伝送する手順について考察してみる。
【０１０７】
ＤＴＣＰは原初的にはＩＥＥＥ１３９４を伝送路に用いたデジタル・コンテンツの伝送を規定したものであるが、この場合、ＡＫＥコマンド毎に１つのＭＡＣフレームを用いて伝送が行なわれるので、受信側のＤＴＣＰ機器では正しくＡＫＥコマンドを読み取ることができる。
【０１０８】
これに対し、ＤＴＣＰ−ＩＰでは、送信データはＴＣＰバイト・ストリームの形式をとるため、ＡＫＥコマンド受信先となるＤＴＣＰ機器側では、各ＩＰパケットを受信すると、これをＴＣＰバイト・ストリームに組み立て、さらにＴＣＰバイト・ストリームからＡＫＥコマンドを取り出さなければならない。
【０１０９】
ＴＣＰペイロードから個々のＡＫＥコマンドを取り出すための明確な意図を持った処理方法が必要であるが、ＤＴＣＰ−ＩＰ自体ではこの種の意味のある処理方法については特に取り決めは存在しない。そこで、以下では、ＴＣＰペイロードから認証制御用のコマンドを正確に抽出するための処理手順について説明する。
【０１１０】
但し、以下の説明では、ＡＫＥコマンドをやり取りするに先立って、Ｓｏｕｒｃｅ機器とＳｉｎｋ機器の間で ＴＣＰコネクションを確立し、双方向にバイト・データを送受信できる状態になっているものとする。
【０１１１】
また、ここで利用するＴＣＰ／ＩＰレイヤの処理モジュールは、ネットワークから受信したデータをソケット・バッファというバッファに溜め込むことができるものとする。ＴＣＰ／ＩＰレイヤの処理モジュールを利用する立場のモジュールは、そのソケット・バッファに溜め込まれたデータ（ネットワークを流れてきたデータ）に対し、「読み出す」という処理を行なうことでそのデータを取得することができるものとする。
【０１１２】
図５には、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器とＤＴＣＰ−ＩＰ ＡＫＥを実施する際の処理手順をフローチャートの形式で示している。以下、図６に示したＡＫＥコマンドのパケット・フォーマットを適宜参照しながら説明する。
【０１１３】
なお、ＡＫＥコマンドを抽出するまでの過程ではＳｏｕｒｃｅ機器及びＳｉｎｋ機器で実行する処理に差はないが、以下では説明の便宜上 Ｓｏｕｒｃｅ機器とＳｉｎｋ機器に分けて考えているが、本質ではないという点を理解されたい。
【０１１４】
また、ＴＣＰペイロードよりＡＫＥコマンドを抽出した以降はそのＡＫＥコマンドの内容に対応した処理を行なうことになるが、本発明の要旨とは直接関連しないので、その処理に関する説明は省略する。
【０１１５】
Ｓｏｕｒｃｅ機器からＳｉｎｋ機器に対してＴＣＰペイロードにバイト・データが格納されたＴＣＰ／ＩＰパケット（バイト・ストリーム）が送信されると、Ｓｉｎｋ機器のソケット・バッファにバイト・データが溜め込まれ始める。このとき、Ｓｏｕｒｃｅ機器、若しくはＳｉｎｋ機器がデータ送受信を止めるまで（例えば、ＴＣＰコネクション確立が切断されるまで）、Ｓｉｎｋ機器ではＴＣＰストリームからＡＫＥコマンドを抽出する処理を実行する。
【０１１６】
まず、読み出し済みのバイト・データが、Ｔｙｐｅ［０］とＢＬＣ（Ｂｙｔｅ Ｌｅｎｇｔｈ Ｃｏｎｔｒｏｌ）を取得できるだけのサイズ以上となっているかどうか、具体的には、読み出し済みのバイト・データが３（＝１＋２＝Ｔｙｐｅ［０］＋ＢＬＣサイズ）以上となっているかどうかをチェックする（ステップＳ１）。
【０１１７】
ここで、読み出し済みのバイト・データがＴｙｐｅ［０］とＢＬＣを取得できるだけのサイズ未満であった場合には、ソケット・バッファよりバイト・データを可能な限り読み出して（ステップＳ１−１）、ステップＳ１へ戻る。
【０１１８】
また、読み出し済みのバイト・データがＴｙｐｅ［０］とＢＬＣを取得できるだけのサイズ以上である場合には、そのバイト・データの１バイト目をＴｙｐｅ［０］の値として、２〜３バイト目のバイト・データを連結してＢＬＣフィールドの値として取得した後（ステップＳ１−２）、次ステップＳ２に進む。
【０１１９】
ステップＳ２では、読み出し済みのバイト・データがＴｙｐｅ［０］とＢＬＣとＢＬＣフィールド値の合計、すなわち、１バイトのＴｙｐｅフィールドと２バイトのＢＬＣフィールドとＢＬＣで記述されたバイト長のＣｏｎｔｒｏｌフィールドを取得できるだけのサイズ以上となっているかどうか、具体的には、３＋ＢＬＣフィールド値以上となっているかどうかをチェックする。
【０１２０】
ここで、読み出し済みのバイト・データがＴｙｐｅ［０］とＢＬＣとＢＬＣフィールド値の合計を取得できるだけのサイズ未満であった場合には、ソケット・バッファよりバイト・データを可能な限り読み出して（ステップＳ２−１）、ステップＳ２へ戻る。
【０１２１】
また、読み出し済みのバイト・データがＴｙｐｅ［０］とＢＬＣとＢＬＣフィールド値の合計を取得できるだけのサイズ以上である場合には、次ステップ３へ進む。
【０１２２】
ステップＳ３では、ステップＳ１−２で取得したＴｙｐｅ［０］の値が０ｘ０１かどうか、すなわち取得したバイト・データがＡＫＥコマンドであるかどうかをチェックする。
【０１２３】
ここで、ステップＳ１−２で取得したＴｙｐｅ［０］の値が０ｘ０１でない場合には、正常なＡＫＥコマンドでないことになる。そこで、バイト・データからのＡＫＥコマンドの抽出を諦めて、３＋ＢＬＣフィールド値分のバイト・データを読み捨てて（ステップＳ３−１）、ステップＳ１へ戻る。
【０１２４】
また、ステップＳ１−２で取得したＴｙｐｅ［０］の値が０ｘ０１である場合には、次ステップＳ４へ進む。
【０１２５】
ステップＳ４では、ステップＳ１−２で取得したＢＬＣの値が０ｘ００００、若しくは０ｘ０００１以上かどうか、すなわちバイト・データの４バイト目が存在するかどうかをチェックする。
【０１２６】
ここで、ステップＳ１−２で取得したＢＬＣの値が０ｘ００００であった場合には、Ｃｏｎｔｒｏｌフィールドが０バイト長となり、正常なＡＫＥコマンドでないことになる。そこで、バイト・データからのＡＫＥコマンドの抽出を諦めて、３＋ＢＬＣ値分のバイト・データを読み捨てて（ステップＳ３−１）、ステップＳ１に戻る。
【０１２７】
また、ステップＳ１−２で取得したＢＬＣの値が０ｘ０００１以上であった場合には、バイト・データの４バイト目以降のＣｏｎｔｒｏｌフィールドが正常に存在することになる。この場合、バイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールドの値として、４バイト目の下位４ビットをｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値として、それぞれ取得し（ステップＳ４−２）、次ステップＳ５に進む。
【０１２８】
ステップＳ５では、ステップＳ４−２で取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏの値が０ｘ０かどうかをチェックする。
【０１２９】
ここで、ステップＳ４−２で取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏの値が０ｘ０でなかった場合には、正常なＡＫＥコマンドでないので、バイト・データからのＡＫＥコマンドの抽出を諦めて、３＋ＢＬＣ値分のバイト・データを読み捨てて（ステップＳ３−１）、ステップＳ１に戻る。
【０１３０】
また、ステップＳ４−２で取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏの値が正しく０ｘ０である場合には、次ステップＳ６に進む。
【０１３１】
ステップＳ６では、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が、いずれかのコマンド・タイプ若しくはレスポンス・コードを示す値と一致しているかをチェックする。
【０１３２】
この判断ブロックでは、具体的には、０ｘ０、０ｘ１、０ｘ８、０ｘ９、０ｘａ、０ｘｃのいずれかと一致しているかどうかをチェックする。ちなみに、０ｘ０は コマンド・タイプ（ｃｔｙｐｅ）の“ＣＯＮＴＲＯＬ”を表し、０ｘ１はコマンド・タイプ（ｃｔｙｐｅ）の“ＳＴＡＴＵＳ”を表し、０ｘ８はレスポンス・コードの“ＮＯＴ_ＩＭＰＬＥＭＥＮＴＥＤ”を表し、０ｘ９はレスポンス・コードの“ＡＣＣＥＰＴＥＤ”を表し、０ｘａはレスポンス・コードの“ＲＥＪＥＣＴＥＤ”を表し、０ｘｃはレスポンス・コードの“ＳＴＡＢＬＥ”を表す。
【０１３３】
ここで、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値がいずれかのコマンド・タイプ若しくはレスポンス・コードを示す値とも一致していなかった場合には、正常なＡＫＥコマンドではないので、バイト・データからのＡＫＥコマンドの抽出を諦めて、３＋ＢＬＣ値分のバイト・データを読み捨てて（ステップＳ３−１）、ステップＳ１に戻る。
【０１３４】
また、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値がいずれかのコマンド・タイプ若しくはレスポンス・コードを示す値と一致していた場合には、次ステップＳ７に進む。
【０１３５】
ステップＳ７では、ステップＳ１−２で取得したＢＬＣの値が０ｘ０００１、０ｘ０００２、又は０ｘ０００３以上かどうかをチェックする。
【０１３６】
ここで、ステップＳ１−２で取得したＢＬＣの値が０ｘ０００１又は０ｘ０００２のいずれかである場合には、受信したＡＫＥコマンドが当該ＤＴＣＰ機器において非実装（ＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤ）、又はＡＫＥコマンドとして正常でない可能性がある。そこで、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ０若しくは０ｘ１、０ｘ８、又は、０ｘ９、０ｘａ、０ｘｃのいずれであるかをさらにチェックする（ステップＳ７−１）。
【０１３７】
ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ０若しくは０ｘ１、すなわちコマンド・タイプのＡＫＥコマンドであった場合には、受信したＡＫＥコマンドが当該ＤＴＣＰ機器において非実装であることから、読み出していた３＋ＢＬＣ値分のバイト・データの処理を終了した後、このデータに対しＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスを生成し、Ｓｏｕｒｃｅ機器に対して当該レスポンスを送信してから（ステップＳ７−１−１）、ステップＳ１に戻る。
【０１３８】
また、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ８、すなわちＡＫＥコマンドがＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤのレスポンス・コードであった場合には、読み出していた３＋ＢＬＣ値分のバイト・データをＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤであると判断し、ＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤのＡＫＥコマンド・レスポンスとして抽出し（ステップＳ７−１−２）、処理を終了する。
【０１３９】
また、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ９、０ｘａ、０ｘｃのうちいずれか、すなわち通常のレスポンス・コードを示す場合には、受信したバイト・データはＡＫＥコマンドとして正常でないので、読み出していた３＋ＢＬＣ値分のバイト・データを読み捨てて、ステップＳ１へ戻る。
【０１４０】
また、ステップＳ１−２で取得したＢＬＣの値が０ｘ０００３以上であった場合には、ＡＫＥコマンドとして正常なバイト長のＣｏｎｔｒｏｌフィールドを持つことになるので、そのバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎフィールドの値として取得した後（ステップＳ７−２）、次ステップＳ８へ進む。
【０１４１】
ステップＳ８では、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ０、０ｘ１、０ｘ８、０ｘ９、０ｘａ、０ｘｃのいずれと一致するかをチェックする。
【０１４２】
ここで、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ０、すなわち受信したＡＫＥコマンドがコマンド・タイプのＣＯＮＴＲＯＬであった場合には、ＢＬＣがｓｕｂｆｕｎｃｔｉｏｎに対して期待通りであるか、すなわちステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致しているかどうかをさらにチェックする（ステップＳ８−１）。
【０１４３】
そして、ステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致していない場合、若しくはｓｕｂｆｕｎｃｔｉｏｎ値がＤＴＣＰ−ＩＰで規定されていない値であれば、当該ＤＴＣＰ機器は受信したＡＫＥコマンドを非実装であることになる。この場合には、読み出していた３＋ＢＬＣ値分のバイト・データの処理を終了すると、このデータに対しＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスを生成し、Ｓｏｕｒｃｅ機器に対して当該レスポンスを送信した後（ステップＳ７−１−１）、ステップＳ１に戻る。
【０１４４】
一方、ステップＳ８−１でサイズが一致すると判定された場合には、読み出していた３＋ＢＬＣフィールド値分のバイト・データを、当該サブファンクションによるＡＫＥコマンド・リクエストであると判断し、ＡＫＥコマンド・リクエストとして抽出して、処理を終了する。その後、ＡＫＥコマンド・リクエスト受信処理を行ないつつ（ステップＳ８−１−２）、ステップＳ１へ戻る。
【０１４５】
また、ステップＳ８において、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ１、すなわちＡＫＥコマンドがコマンド・タイプのＳＴＡＴＵＳであると判定された場合にも、ステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致しているかどうかをさらにチェックする（ステップＳ８−１）。
【０１４６】
この場合も、ステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致していない場合、若しくはｓｕｂｆｕｎｃｔｉｏｎ値がＤＴＣＰ−ＩＰで規定されていない値であった場合には、読み出していた３＋ＢＬＣ値分のバイト・データの処理を終了し、このデータに対しＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスを生成し、Ｓｏｕｒｃｅ機器に対して当該レスポンスを送信した後（ステップＳ７−１−１）、ステップＳ１に戻る。一方、サイズが一致すると判定された場合には、読み出していた３＋ＢＬＣフィールド値分のバイト・データを、当該サブファンクションによるＡＫＥコマンド・リクエストであると判断し、ＡＫＥコマンド・リクエストとして抽出して、処理を終了する。その後、ＡＫＥコマンド・リクエスト受信処理を行ないつつ（ステップＳ８−１−２）、ステップＳ１へ戻る。
【０１４７】
また、ステップＳ８において、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ８、すなわちＡＫＥコマンドがレスポンス・コードのＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤであると判定された場合には、読み出していた３＋ＢＬＣフィールド値分のバイト・データをＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスであると判断し、ＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤのＡＫＥコマンド・レスポンスとして抽出し（ステップＳ７−１−２）、処理を終了する。
【０１４８】
また、ステップＳ８において、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ９又は０ｘｃ、すなわちＡＫＥコマンドがＡＣＣＥＰＴＥＤ並びにＳＴＡＢＬＥを示すレスポンス・コードであると判定された場合には、ＢＬＣがｓｕｂｆｕｎｃｔｉｏｎに対して期待通り、すなわちステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致しているかどうかをさらにチェックする（ステップＳ８−４）。
【０１４９】
ここで、ステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致していない場合、若しくはｓｕｂｆｕｎｃｔｉｏｎ値がＤＴＣＰ−ＩＰで規定されていない値であった場合には、受信したバイト・データがＡＫＥコマンドとして正常でないので、読み出していた３＋ＢＬＣ値分のバイト・データを読み捨てて、ステップＳ１に戻る。
【０１５０】
一方、ステップＳ８−４においてサイズが一致すると判断された場合には、読み出していた３＋ＢＬＣフィールド値分のバイト・データを、当該サブファンクションによるＡＫＥコマンド・リクエストであると判断し、ＡＫＥコマンド・リクエストとして抽出して、処理を終了する。その後、ＡＫＥコマンド・リクエスト受信処理を行ないつつ（ステップＳ８−４−２）、ステップＳ１へ戻る。
【０１５１】
また、ステップＳ８において、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘａ、すなわちレスポンス・コードのＲＥＪＥＣＴＥＤであると判定された場合には、ステップＳ１−２で取得したＢＬＣの値がＲＥＪＥＣＴＥＤレスポンスでのサイズに一致しているかどうかをさらにチェックする（ステップＳ８−５）。
【０１５２】
ここで、ステップＳ１−２で取得したＢＬＣの値がＲＥＪＥＣＴＥＤレスポンスでのサイズに一致していない場合には、受信したバイト・データがＡＫＥコマンドとして正常でないので、読み出していた３＋ＢＬＣ値分のバイト・データを読み捨てて、ステップＳ１に戻る。
【０１５３】
一方、ステップＳ１−２で取得したＢＬＣの値がＲＥＪＥＣＴＥＤレスポンスでのサイズに一致する場合には、読み出していた３＋ＢＬＣフィールド値分のバイト・データを、ＲＥＪＥＣＴＥＤのＡＫＥコマンド・レスポンスであると判断し、ＲＥＪＥＣＴＥＤのＡＫＥコマンド・レスポンスとして抽出して、処理を終了する。その後、ＡＫＥコマンド・リクエスト受信処理を行ないつつ（ステップＳ８−５−２）、ステップＳ１へ戻る。
【０１５４】
なお、図５に示したフローチャートでは、ステップＳ３においてステップＳ１−２で取得したＴｙｐｅ［０］の値が０ｘ０１かどうかをチェックするようにしているが、ステップＳ３におけるチェックなしに直接ステップＳ４に進むようにしてもよい。
【０１５５】
また、ステップＳ５において、ステップＳ４−２で取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏの値が０ｘ０かどうかをチェックすることなしに、直接ステップＳ６に進むようにしてもよい。
【０１５６】
また、ステップＳ３においてステップＳ１−２で取得したＴｙｐｅ［０］の値が０ｘ０１かどうかをチェックすることなく、ステップＳ４へ進み、且つ、ステップＳ５においてｒｅｓｅｒｖｅｄ＿ｚｅｒｏの値が０ｘ０かどうかをチェックすることなしに、直接ステップＳ６に進むようにしてもよい。
【０１５７】
また、ステップＳ２−１では、ソケット・バッファよりバイト・データを可能な限り読み出した後にステップＳ２に戻るが、ステップＳ１に戻るようにしてもよい。
【産業上の利用可能性】
【０１５８】
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【０１５９】
本明細書では、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信するという実施形態を例にとって説明してきたが、本発明の要旨はこれに限定されるものではない。ＩＰプロトコルを利用したコンテンツ伝送手続きを規定したＤＴＣＰ以外のシステムにおいて、ＴＣＰバイト・ストリーム上で送られてくるコマンドを受信側で取り出す際に、同様に本発明を適用することができる。
【０１６０】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【図面の簡単な説明】
【０１６１】
【図１】図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。
【図２】図２は、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）として動作する情報通信装置の機能構成を模式的に示した図である。
【図３】図３は、図１に示した情報通信システムにおいて、サーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成を模式的に示した図である。
【図４】図４は、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥ手続き、及びＨＴＴＰプロトコルを利用したコンテンツ伝送を行なう仕組みを示した図である。
【図５】図５は、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器とＤＴＣＰ−ＩＰ ＡＫＥを実施する際の処理手順を示したフローチャートである。
【図６】図６は、ＡＫＥコマンドのパケット・フォーマットを示した図である。
【図７】図７は、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンスを示した図である。
【図８】図８は、ＤＴＣＰ、並びにＤＴＣＰ−ＩＰそれぞれにおいて伝送されるＡＫＥコマンドを受信側の機器で取り出す仕組みを説明するための図である。
【技術分野】
【０００１】
本発明は、著作権保護若しくはその他の目的で暗号化された伝送コンテンツを受信処理する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを実行する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。
【０００２】
さらに詳しくは、本発明は、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）の手続きを実行する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに係り、特に、ＤＴＣＰ−ＩＰに準拠した別の情報機器から送られてくるＴＣＰペイロードから認証用制御（ＡＫＥ）コマンドを正確に抽出する情報通信装置及び情報通信方法、並びにコンピュータ・プログラムに関する。
【背景技術】
【０００３】
最近、ネットワークを経由した映像や音楽などのコンテンツの流通・配信サービスが盛んに行なわれる。この種のサービスでは、ＣＤやＤＶＤなどのメディアの移動を必要とせず、ネットワークを経由して遠隔端末間でコンテンツ配信を行なうことができる。一方、ネットワーク経由で取り扱われるコンテンツは、著作物の１つとして、著作権法の下で無断の複製や改竄などの不正使用から保護を受ける。著作権法では、同法第３０条において、個人的に又は家庭内などを使用目的とした場合の使用者本人の複製を許容する一方、同法第４９条第１項においては、私的使用以外での複製物の使用を禁止している。また、デジタル・コンテンツはコピーや改竄などの不正な操作が比較的容易であることから、法的な整備だけでなく技術的な側面からも、個人的又は家庭的なコンテンツの使用を許容しながら不正使用に対する防御が必要である。
【０００４】
例えば、デジタル伝送コンテンツの保護に関する業界標準であるＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）では、著作権が保護された形でコンテンツを伝送させるための仕組みについて規定している（例えば、非特許文献１を参照のこと）。ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器はＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）など取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどを取り決めている。
【０００５】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホーム・ネットワーク上におけるデジタル・コンテンツの伝送について規定したものである。最近では、ＩＥＥＥ１３９４ベースで規定されたＤＴＣＰ技術をＩＰネットワークに移植した技術の開発が進められている（以降、この技術をＤＴＣＰ−ＩＰと呼ぶ）。
【０００６】
ＤＴＣＰ−ＩＰは、ＤＴＣＰ技術をＩＰネットワークに移植した同様の技術であるが、伝送路にＩＰネットワークを使用すること、暗号化されたコンテンツの伝送にＨＴＴＰやＲＴＰプロトコルを使用するという点で、ＩＥＥＥ１３９４ベースで規定された本来のＤＴＣＰとは相違する。ホーム・ネットワークの多くはルータなどを経由してインターネットなどの外部の広域ネットワークに接続されているので、ＤＴＣＰ−ＩＰ技術の確立により、デジタル・コンテンツを保護しながらＩＰネットワークを利用した柔軟で効率的なコンテンツの利用が図られる。他方、ＩＰネットワーク上にはＰＣを主としたさまざまな機器が接続され、データの盗聴、改竄が簡単に行なわれてしまう危険が高いことから、ＤＴＣＰ−ＩＰは、コンテンツを保護しながらネットワーク伝送するためのさらなる方法を規定している（例えば、非特許文献２を参照のこと）。
【０００７】
ＤＴＣＰ−ＩＰに従ったコンテンツの伝送手順について以下に説明しておく。但し、ＤＴＣＰに準拠した機器は２つの種類に分類される。１つはＤＴＣＰ＿Ｓｏｕｒｃｅと言い、コンテンツの要求を受理し、コンテンツを送信するサーバ機器である。もう１つはＤＴＣＰ＿Ｓｉｎｋと言い、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアント機器である。
【０００８】
ＤＴＣＰ＿ＳｏｕｒｃｅとＤＴＣＰ＿Ｓｉｎｋはまず１つのＴＣＰ／ＩＰコネクションを確立し、機器同士の認証を行なう。この認証をＤＴＣＰ認証、若しくはＡＫＥ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｎｄ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と言う。ＤＴＣＰ準拠機器には、ＤＴＬＡ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｌｉｃｅｎｓｉｎｇ Ａｄｍｉｎｉｓｔｒａｔｏｒ）と呼ばれる認可組織によりユニークな機器ＩＤや鍵が埋め込まれている。ＤＴＣＰ認証手続きでは、このような情報を用いて互いが正規のＤＴＣＰ準拠機器であることを確かめた後、コンテンツを暗号化若しくは復号するためのＤＴＣＰ＿Ｓｏｕｒｃｅが管理している鍵をＤＴＣＰ＿Ｓｉｎｋ機器と共有することができる。
【０００９】
そして、ＤＴＣＰ準拠の機器間で認証手続きが済んだ後、ＤＴＣＰ＿ＳｉｎｋはＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツを要求する。ＤＴＣＰ＿Ｓｏｕｒｃｅは、ＣＤＳ（Ｃｏｎｔｅｎｔｓ Ｄｉｒｅｃｔｏｒｙ Ｓｅｒｖｉｃｅ）などを通じてＤＴＣＰ＿ＳｉｎｋにＤＴＣＰ＿Ｓｏｕｒｃｅ上のコンテンツへのアクセス先を示すコンテンツ場所をあらかじめ伝えることができる。ＤＴＣＰ＿Ｓｉｎｋがコンテンツを要求するとき、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）などのプロトコルを利用することができる。ＨＴＴＰの手続きに従ってコンテンツを要求する場合、ＤＴＣＰ＿ＳｏｕｒｃｅがＨＴＴＰサーバとなり、ＤＴＣＰ＿ＳｉｎｋがＨＴＴＰクライアントとなって、コンテンツの伝送を開始する。また、ＲＴＰによる伝送を要求するとき、ＤＴＣＰ＿ＳｏｕｒｃｅがＲＴＰ Ｓｅｎｄｅｒとなり、ＤＴＣＰ＿ＳｉｎｋがＲＴＰ Ｒｅｃｅｉｖｅｒとなってコンテンツの伝送を開始する。なお、これらの通信手続き以外にもＲＳＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）などの伝送プロトコルも適用が可能である。
【００１０】
ＨＴＴＰでコンテンツ伝送を行なう際、ＤＴＣＰ認証のためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションがＨＴＴＰクライアントより作成される。そして、ＨＴＴＰクライアントは、通常のＨＴＴＰと全く同様の動作手順によりＨＴＴＰサーバ上のコンテンツを要求する。これに対し、ＨＴＴＰサーバは、要求通りのコンテンツをＨＴＴＰレスポンスとして返す。但し、ＨＴＴＰレスポンスとして伝送されるデータは、ＨＴＴＰサーバすなわちＤＴＣＰ＿Ｓｏｕｒｃｅ機器がＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。暗号化されたデータを受信したクライアント（ＤＴＣＰ＿Ｓｉｎｋ）は同様に、先の認証をした後に共有した鍵によりデータを復号し、再生若しくは記録を行なうことができる。
【００１１】
このように、ＤＴＣＰ−ＩＰは、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路の途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。
【００１２】
上述したように、ＤＴＣＰでは、コンテンツ提供元であるサーバ（ＤＴＣＰ Ｓｏｕｒｃｅ）とコンテンツ提供先であるクライアント（ＤＴＣＰ Ｓｉｎｋ）は、ＡＫＥコマンドの送受信により、認証手続きを経て鍵を共有化し、その鍵を用いて伝送路を暗号化してコンテンツの伝送を行なうことを取り決めている。ここで、ＤＴＣＰ、並びにＤＴＣＰ−ＩＰそれぞれにおいてＡＫＥコマンドを伝送する手順について考察してみる。
【００１３】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４を伝送路に用いたデジタル・コンテンツの伝送について規定したものである。一方、ＤＴＣＰ−ＩＰは、基本的にはＤＴＣＰ規格に含まれるものであるが、伝送路にＩＥＥＥ１３９４に代えてＩＰネットワークを使用する点が大きな相違点となる。
【００１４】
ＩＥＥＥ１３９４は基本的にはＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤに相当する。このことから、コマンド送信元のＤＴＣＰ機器は、個々のＡＫＥコマンドをそれぞれ１つのＭＡＣフレームに乗せて転送すればよく、コマンド受信先のＤＴＣＰ機器はＭＡＣフレームから１つのＡＫＥコマンドを取り出せばよい（例えば、非特許文献３を参照のこと）。
【００１５】
これに対し、ＤＴＣＰ−ＩＰでは、送信データはＴＣＰバイト・ストリームの形式をとるため、ＡＫＥコマンド送信元のＤＴＣＰ機器側では、ＩＰプロトコル層によりＴＣＰペイロードを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける（例えば、非特許文献４を参照のこと）。一方、ＡＫＥコマンド受信先となるＤＴＣＰ機器側では、各ＩＰパケットを受信すると、これをＴＣＰバイト・ストリームに組み立て、さらにＴＣＰバイト・ストリームからＡＫＥコマンドを取り出さなければならない（図８を参照のこと）。
【００１６】
コマンド受信側でバイト・ストリームからＡＫＥコマンドを取り出すことができなければ、ＡＫＥによる認証手続き自体が成功せず、この結果コンテンツ鍵を共有できないことから、本来はコンテンツを利用できるＤＴＣＰ機器であってもコンテンツを利用できなくなるというという問題を招来する。
【００１７】
当業界において周知のように、通信プロトコルはＴＣＰやＩＰといった複数のプロトコルのスタック構造をなし、これらの最上位層としてアプリケーションが位置付けられる。ＴＣＰ／ＩＰ上でＤＴＣＰアプリケーションを実装するためには、ＴＣＰペイロードから個々のＡＫＥコマンドを取り出すための明確な意図を持った処理方法が必要である。しかしながら、ＤＴＣＰ−ＩＰ自体ではこの種の意味のある処理方法については特に取り決めは存在しない。
【００１８】
【非特許文献１】ＤＴＣＰ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｏｌｕｍｅ １ Ｖｅｒｓｉｏｎ １．３ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００４０１０７＿ｄｔｃｐ＿Ｖｏｌ＿１＿１ｐ３．ｐｄｆ
【非特許文献２】ＤＴＣＰ Ｖｏｌｕｍｅ １ Ｓｕｐｐｌｅｍｅｎｔ Ｅ Ｍａｐｐｉｎｇ ＤＴＣＰ ｔｏ ＩＰ， Ｖｅｒｓｉｏｎ １．０ （Ｉｎｆｏｒｍａｔｉｏｎａｌ Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００３１１２４＿ｄｔｃｐ＿ＶＩＳＥ＿１ｐ０．ｐｄｆ／
【非特許文献３】ＡＶ／Ｃ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ Ｃｏｍｍａｎｄ Ｓｅｔ Ｇｅｎｅｒａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ ４．１
【非特許文献４】ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ） ７９１ ＩＮＴＥＲＮＥＴ ＰＲＯＴＯＣＯＬ
【発明の開示】
【発明が解決しようとする課題】
【００１９】
本発明の目的は、著作権保護若しくはその他の目的で暗号化された伝送コンテンツを好適に受信処理することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【００２０】
本発明のさらなる目的は、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを好適に実行することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【００２１】
本発明のさらなる目的は、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）の手続きを好適に実行することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【００２２】
本発明のさらなる目的は、ＤＴＣＰ−ＩＰに準拠した別の情報機器から送られてくるＴＣＰペイロードから認証用制御（ＡＫＥ）コマンドを正確に抽出することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することにある。
【課題を解決するための手段】
【００２３】
本発明は、上記課題を参酌してなされたものであり、その第１の側面は、ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した他の情報通信装置との間で相互認証及び鍵交換のための認証制御用（ＡＫＥ）コマンドを受信する情報通信装置であって、ＡＫＥコマンドは、先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドを備え、該他の情報通信装置からＴＣＰストリームとして送られてくるバイト・データからＡＫＥコマンドを抽出する際に、
受信したＴＣＰストリームからバイト・データをＡＫＥコマンド抽出用情報として取得するＡＫＥコマンド抽出用情報取得手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値を取得する第１の情報取得手段と、
Ｔｙｐｅフィールド及びＢＬＣフィールドの値をチェックする第１の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド値として取得するとともに、下位４ビットをＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを示すｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールド値として取得する第２の情報取得手段と、
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第２の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する第３の情報取得手段と、
ＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第３の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンドを抽出するコマンド抽出手段と、
ＡＫＥコマンドを送信するコマンド送信手段と、
ＡＫＥコマンドの受信処理を起動するコマンド受信処理起動手段と、
を具備することを特徴とする情報通信装置である。
【００２４】
本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システムに関するものであり、特に、具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信し、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なう情報通信システムに関する。
【００２５】
ＤＴＣＰ−ＩＰは、ＤＴＣＰに準拠した機器同士で認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送際に暗号化及び復号をすることにより、伝送路途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。
【００２６】
ここで、ＤＴＣＰに準拠したコンテンツ伝送を実現するには、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器間でＡＫＥ手続きを成功裏に実施する必要がある。
【００２７】
ＤＴＣＰは原初的にはＩＥＥＥ１３９４を伝送路に用いたデジタル・コンテンツの伝送を規定したものであるが、この場合、ＡＫＥコマンド毎に１つのＭＡＣフレームを用いて伝送が行なわれるので、受信側のＤＴＣＰ機器では正しくＡＫＥコマンドを読み取ることができる。
【００２８】
一方、ＤＴＣＰ−ＩＰでは、送信データはＴＣＰバイト・ストリームの形式をとるため、ＡＫＥコマンド受信先となるＤＴＣＰ機器側では、各ＩＰパケットを受信すると、これをＴＣＰバイト・ストリームに組み立て、さらにＴＣＰバイト・ストリームからＡＫＥコマンドを取り出さなければならない。ＴＣＰペイロードから個々のＡＫＥコマンドを取り出すための明確な意図を持った処理方法が必要であるが、ＤＴＣＰ−ＩＰ自体ではこの種の意味のある処理方法については特に取り決めは存在しない。
【００２９】
これに対し、本実施形態に係る情報通信装置は、ＡＫＥコマンドが先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドからなるデータ構造を備えていることに着目し、ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値のチェック、ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位及び下位それぞれ４ビットから抽出されるｒｅｓｅｒｖｅｒ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値のチェック、並びに、バイト・データの所定バイト位置から取得したｓｕｂｆｕｎｃｔｉｏｎを取得した後にＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックすることによって、ＴＣＰストリームの形で送られてくるバイト・データから正確にＡＫＥコマンドを抽出することができる。ここで言うＡＫＥコマンドにはＡＫＥコマンド・リクエストとＡＫＥコマンド・レスポンスの両方が含まれる。
【００３０】
勿論、当該情報通信装置は、受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容次第では、ＡＫＥコマンドを抽出することなく、取得したバイト・データを読み捨てることもある。あるいは、受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容に応じて、ＡＫＥコマンドを抽出せずに、ＡＫＥコマンド・レスポンスを送信することもある。
【００３１】
具体的には、前記第１の情報チェック手段は、取得したＴｙｐｅフィールド又はＢＬＣフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックする。そして、該チェック結果が否定的であるときには、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄手段が読み捨てるようにする。
【００３２】
また、前記第２の情報チェック手段は、取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド又はｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックする。そして、該チェック結果が否定的であるときには、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄手段が読み捨てるようにする。
【００３３】
また、前記第３の情報チェック手段は、ＢＬＣフィールドの値が示すバイト長ではＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できないときには、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする。
【００３４】
ここで、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときには、前記コマンド抽出手段はバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信手段は、非実装であることを示すＡＫＥコマンド・レスポンスを送信するようにする。あるいは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときには、前記コマンド・レスポンス抽出手段は非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理起動手段は非実装レスポンスの受信処理を起動するようにする。あるいは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が通常のレスポンス・コードであるときには、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄手段が読み捨てるようにする。
【００３５】
他方、ＢＬＣフィールドの値が示すバイト長でＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できるときには、前記第３の情報取得手段はＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する。そして、前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に応じてＢＬＣフィールドの値をチェックする。
【００３６】
ここで、前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときに、前記第３の情報取得手段により取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックする。そして、該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・リクエストを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・リクエストの受信処理を起動するようにする。あるいは、該チェック結果が否定的であれば、前記コマンド抽出手段はバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信手段は、非実装であることを示すＡＫＥコマンド・レスポンスを送信するようにする。
【００３７】
また、前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的でないレスポンス・コードを示すときに、前記第３の情報取得手段により取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックする。そして、該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・レスポンスの受信処理を起動するようにする。あるいは、該チェック結果が否定的であれば、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てるようにする。
【００３８】
また、前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的なレスポンス・コードを示すときに、ＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックする。そして、該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・レスポンスの受信処理を起動するようにする。あるいは、該チェック結果が否定的であれば、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てるようにする。
【００３９】
また、前記第３の情報チェック手段がｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときと判定したときには、前記コマンド・レスポンス抽出手段は非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理起動手段は非実装レスポンスの受信処理を起動するようにする。
【００４０】
また、本発明の第２の側面は、ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した他の情報通信装置との間で相互認証及び鍵交換のための認証制御用（ＡＫＥ）コマンドを受信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、ＡＫＥコマンドは、先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドを備え、該他の情報通信装置からＴＣＰストリームとして送られてくるバイト・データからＡＫＥコマンドを抽出する際に、前記コンピュータ・システムに対し、
受信したＴＣＰストリームからバイト・データをＡＫＥコマンド抽出用情報として取得するＡＫＥコマンド抽出用情報取得手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値を取得する第１の情報取得手順と、
Ｔｙｐｅフィールド及びＢＬＣフィールドの値をチェックする第１の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド値として取得するとともに、下位４ビットをＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを示すｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールド値として取得する第２の情報取得手順と、
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第２の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する第３の情報取得手順と、
ＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第３の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンドを抽出するコマンド抽出手順と、
ＡＫＥコマンドを送信するコマンド送信手順と、
ＡＫＥコマンドの受信処理を起動するコマンド受信処理起動手順と、
を実行させることを特徴とするコンピュータ・プログラムである。
【００４１】
本発明の第２の側面に係るコンピュータ・プログラムは、コンピュータ・システム上で所定の処理を実現するようにコンピュータ可読形式で記述されたコンピュータ・プログラムを定義したものである。換言すれば、本発明の第２の側面に係るコンピュータ・プログラムをコンピュータ・システムにインストールすることによって、コンピュータ・システム上では協働的作用が発揮され、本発明の第１の側面に係る情報通信装置と同様の作用効果を得ることができる。
【発明の効果】
【００４２】
本発明によれば、ＤＴＣＰに準拠した別の情報機器との間で相互認証及び鍵交換（ＡＫＥ）の手続きを好適に実行することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。
【００４３】
また、本発明によれば、ＩＰネットワーク上で別の情報機器との間でＤＴＣＰ−ＩＰに準拠した相互認証及び鍵交換（ＡＫＥ）の手続きを好適に実行することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。
【００４４】
また、本発明によれば、ＤＴＣＰ−ＩＰに準拠した別の情報機器から送られてくるＴＣＰペイロードから認証用制御（ＡＫＥ）コマンドを正確に抽出することができる、優れた情報通信装置及び情報通信方法、並びにコンピュータ・プログラムを提供することができる。
【００４５】
本発明のさらに他の目的、特徴や利点は、後述する本発明の実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【発明を実施するための最良の形態】
【００４６】
以下、図面を参照しながら本発明の実施形態について詳解する。
【００４７】
本発明は、ＩＰネットワーク上で著作権保護が必要となる情報コンテンツを伝送する情報通信システムに関するものであり、特に、具体的には、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信し、相互認証及び鍵交換を経て共有した鍵を用いて暗号化コンテンツ伝送を安全に行なう情報通信システムに関する。
【００４８】
ＤＴＣＰ−ＩＰでは、送信データはＴＣＰバイト・ストリームの形式をとるため、ＡＫＥコマンド送信元のＤＴＣＰ機器側では、ＩＰプロトコル層によりＴＣＰペイロードを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。一方、ＡＫＥコマンド受信先となるＤＴＣＰ機器側では、各ＩＰパケットを受信すると、これをＴＣＰバイト・ストリームに組み立て、さらにＴＣＰバイト・ストリームからＡＫＥコマンドを取り出さなければならない。
【００４９】
Ａ．システム構成
ＤＴＣＰ−ＩＰに従ったコンテンツ伝送は、コンテンツの要求を受理してコンテンツを送信するサーバとしてのＳｏｕｒｃｅ機器と、コンテンツを要求し、コンテンツを受信し、再生若しくは記録するクライアントとしてのＳｉｎｋ機器で構成される。図１には、本発明の一実施形態に係る情報通信システムの構成例を模式的に示している。
【００５０】
図示の例では、Ｓｏｕｒｃｅ機器Ａ〜Ｂ、Ｓｉｎｋ機器Ａ〜Ｂ及び中継機器Ａ〜Ｃの各エンティティにより、ＤＴＣＰ−ＩＰ ＡＫＥシステムが構築されている。
【００５１】
ＤＴＣＰ−ＩＰ に準拠した認証サーバであるＳｏｕｒｃｅ機器ＡとＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器Ａが中継機器Ａと中継機器Ｂを経由してネットワークで接続されている。
【００５２】
また、中継機器Ａ、中継機器Ｂ、中継機器Ｃ を経由して、ＤＴＣＰ−ＩＰに準拠した認証サーバであるＳｏｕｒｃｅ機器ＢやＤＴＣＰ−ＩＰに準拠した認証クライアントであるＳｉｎｋ機器ＢがＩＰネットワークで接続されている。
【００５３】
図２及び図３には、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）及びサーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成をそれぞれ模式的に示している。Ｓｉｎｋ機器とＳｏｕｒｃｅ機器は、インターネットなどの図示しないＴＣＰ／ＩＰネットワーク上でコネクションを確立することができ、このコネクションを利用して、認証手続きやコンテンツ伝送手続きを実行することができる。
【００５４】
図２に示すＳｉｎｋ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｉｎｋとして動作する。図示のクライアント機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ受信ブロックと、コンテンツ再生／記録ブロックを備えている。
【００５５】
ＤＴＣＰ−ＩＰ認証ブロックは、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ復号ブロックを備えている。
【００５６】
ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｉｎｋ側）を実現するブロックでる。このＡＫＥブロックは後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。
【００５７】
メッセージ・ダイジェスト生成ブロックは、指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定することができる。あらかじめ用意されたアルゴリズムとして、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げることができる（ＳＨＡ−１は、ＭＤ５と同様、ＭＤ４を改良したものに相当するが、１６０ビットのハッシュ値を生成するので、強度はＭＤシリーズを上回る）。
【００５８】
メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能であり、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【００５９】
コンテンツ復号ブロックは、サーバから受信した暗号化されたコンテンツ・データをＡＫＥで交換した鍵を用いてコンテンツの復号鍵を算出し、暗号コンテンツを復号するブロックである。ここで復号されたコンテンツは、コンテンツ再生／記録ブロックへ渡される。
【００６０】
コンテンツ再生／記録ブロックは、渡されたコンテンツを、再生モードの場合は再生を行ない、記録モードの場合は保存する。
【００６１】
ＤＴＣＰ−ＩＰコンテンツ受信ブロックは、ＡＫＥを実施した後にコンテンツ伝送手続きを実行する処理モジュールである。図示の例では、ＤＴＣＰ−ＩＰコンテンツ受信ブロックはＨＴＴＰクライアント・ブロックを持ち、ＨＴＴＰクライアントとしてＨＴＴＰサーバへコンテンツを要求し、応答されたコンテンツをＨＴＴＰサーバから受信する。
【００６２】
ＨＴＴＰクライアント・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト送信ブロックとＨＴＴＰリクエスト生成ブロックへ分かれる。
【００６３】
ＨＴＴＰリクエスト生成ブロックは、送信するコンテンツ伝送要求（ＨＴＴＰリクエスト)を生成する。ここで生成されたＨＴＴＰリクエストは、ＨＴＴＰリクエスト送信ブロックによりサーバへ送信される。
【００６４】
ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス受信ブロックとＨＴＴＰレスポンス解釈ブロックに分かれる。サーバから返信されるＨＴＴＰレスポンスと暗号化されたコンテンツは、ＨＴＴＰ受信ブロックで受信される。ここで受信したＨＴＴＰレスポンスは、ＨＴＴＰレスポンス解釈ブロックでチェックされる。ここでのチェックがＯＫの場合は受信した暗号化コンテンツをＤＴＣＰに認証ブロック内のコンテンツ復号ブロックへ送る。また、このチェックがＮＧの場合は、エラー・レスポンスとしての処理を行なう。
【００６５】
ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ受信ブロックは、サーバ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【００６６】
また、図３に示すＳｏｕｒｃｅ機器は、ＤＴＣＰ−ＩＰ規格に準拠しており、ＤＴＣＰ＿Ｓｏｕｒｃｅとして動作する。サーバ機器は、機能ブロックとして、ＤＴＣＰ−ＩＰ認証ブロックと、ＤＴＣＰ−ＩＰコンテンツ送信ブロックと、コンテンツ管理ブロックを備えている。
【００６７】
ＤＴＣＰ−ＩＰ認証ブロックは、ＡＫＥブロックと、メッセージ・ダイジェスト生成ブロックと、コンテンツ暗号化ブロックを備えている。
【００６８】
ＡＫＥブロックは、ＤＴＣＰ−ＩＰにおけるＡＫＥ機構（ＤＴＣＰ＿Ｓｏｕｒｃｅ側）を実現するブロックである。このブロックは、後述のメッセージ・ダイジェスト生成ブロックから要求されたパラメータを渡す機能も備えている。ＡＫＥブロックは認証したＤＴＣＰ＿Ｓｉｎｋ機器に関する情報を認証した機器の数だけ保持し、それをクライアントからコンテンツが要求された際に認証済みのクライアントかどうかを判別するのに使用する。
【００６９】
メッセージ・ダイジェスト生成ブロックは指定されたアルゴリズムに従い、パラメータのメッセージ・ダイジェストを生成するブロックである。メッセージ・ダイジェストを生成するアルゴリズムはあらかじめ用意されたアルゴリズムを指定できる。あらかじめ用意されたアルゴリズムとは、例えばＭＤ５やＳＨＡ−１といった一方向性ハッシュ関数に関するアルゴリズムが挙げられる（同上）。
【００７０】
メッセージ・ダイジェスト生成ブロックは、ＤＴＣＰ−ＩＰ認証ブロックの外に公開してはならないＡＫＥブロックが保持するパラメータのメッセージ・ダイジェストを生成できるようにＡＫＥブロックと密に配置され、ＡＫＥブロックへパラメータを要求して取得することが可能で、そのパラメータ若しくは外部から与えられたパラメータのメッセージ・ダイジェストを作成することができる。
【００７１】
コンテンツ暗号化ブロックは、ＤＴＣＰ−ＩＰコンテンツ送信ブロックの要求に応じて、コンテンツ管理ブロックより読み出したコンテンツ・データをＡＫＥで交換した鍵から生成したコンテンツ鍵を用いて暗号化するブロックである。ここで復号されたコンテンツは、クライアントへ送信するために、ＤＴＣＰ−ＩＰコンテンツ送信ブロックへ渡される。
【００７２】
コンテンツ管理ブロックは、ＤＴＣＰ−ＩＰの機構を用いて保護されるべきコンテンツを管理するブロックである。コンテンツ暗号化ブロックの読み出しに応じて、コンテンツのデータを渡す。
【００７３】
ＤＴＣＰ−ＩＰコンテンツ送信ブロックは、ＨＴＴＰサーバ・ブロックを持ち、ＨＴＴＰサーバとしてクライアントからのリクエストを受理し要求に応じた処理を実行する。
【００７４】
ＨＴＴＰサーバ・ブロックは、ＨＴＴＰリクエスト管理ブロックとＨＴＴＰレスポンス管理ブロックに分かれる。さらに、ＨＴＴＰリクエスト管理ブロックは、ＨＴＴＰリクエスト受信ブロックと、ＨＴＴＰリクエスト解釈ブロックに分かれる。
【００７５】
ＨＴＴＰリクエスト受信ブロックは、クライアントからのＨＴＴＰリクエストを受信する。受信したＨＴＴＰリクエストはＨＴＴＰリクエスト解釈ブロックに送られ、チェックされる。ＨＴＴＰリクエスト解釈ブロックにおけるチェックがＯＫの場合、ＨＴＴＰリクエストの情報をＤＴＣＰ−ＩＰ認証ブロックへ通知する。
【００７６】
ＨＴＴＰレスポンス管理ブロックは、ＨＴＴＰレスポンス生成ブロックとＨＴＴＰレスポンス送信ブロックに分かれる。
【００７７】
ＨＴＴＰレスポンス生成ブロックは、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合、暗号化されたコンテンツを返すためのＨＴＴＰレスポンスを作成する。一方、ＨＴＴＰリクエスト解釈ブロックでのチェックがＮＧの場合、エラーを返すためのＨＴＴＰレスポンスを作成する。
【００７８】
ＨＴＴＰレスポンス送信ブロックは、作成されたＨＴＴＰレスポンスを、要求元のクライアントへＨＴＴＰレスポンスを送信する。また、ＨＴＴＰリクエスト解釈ブロックでのチェックがＯＫの場合には、ＨＴＴＰレスポンス・ヘッダに続けて、ＤＴＣＰ−ＩＰ認証ブロック内のコンテンツ暗号化ブロックで暗号化したコンテンツを送信する。
【００７９】
ＤＴＣＰ−ＩＰ認証ブロックとＤＴＣＰ−ＩＰコンテンツ送信ブロックは、Ｓｉｎｋ機器との間で個別のＴＣＰ／ＩＰコネクションを確立して、それぞれ認証手続き及びコンテンツ伝送手続きを互いに独立して実行する。
【００８０】
なお、ＤＴＣＰ−Ｓｉｎｋ機器及びＤＴＣＰ−Ｓｏｕｒｃｅ機器のいずれもがＤＴＣＰ−ＩＰ認証ブロック内に持つメッセージ・ダイジェスト生成ブロックはＤＴＣＰ−ＩＰ自体で規定される機能モジュールではなく、また本発明の要旨には直接関連しない。例えば、本出願人に既に譲渡されている特願２００４−１１３４５９号公報にはメッセージ・ダイジェスト生成ブロックについて記述されている。
【００８１】
Ｂ．ＨＴＴＰを利用したコンテンツ伝送
図４には、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥ手続き、及びＨＴＴＰプロトコルを利用したコンテンツ伝送を行なう仕組みを図解している。既に述べたように、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間では、ＡＫＥ手続き用のＴＣＰコネクションと、ＨＴＴＰを利用したコンテンツ要求用、並びにコンテンツ鍵の確認用のＴＣＰコネクションがそれぞれ独立して確立される（すなわち、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器はそれぞれ、ＡＫＥ手続き用とコンテンツ伝送用、コンテンツ鍵の確認用に個別のソケット（ＩＰアドレスとポート番号の組み合わせ）を持つ）。
【００８２】
まず、ＡＫＥ手続き用のＴＣＰコネクションを確立し、同手続きが成功すると、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間では認証鍵Ｋauthを共有することができる。ＡＫＥ手続きが終了すると、このＴＣＰコネクションは切断される。そして、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器は、それぞれ内部で同様の処理を行なってＫauthからコンテンツ鍵の種となる種鍵Ｋxを生成する。
【００８３】
次いで、ＤＴＣＰ−Ｓｉｎｋ機器側からのコンテンツ要求などに応じて、ＨＴＴＰプロトコルを用いたコンテンツ伝送用のＴＣＰコネクションが確立される。
【００８４】
ＤＴＣＰ＿Ｓｏｕｒｃｅ機器は、ＴＣＰコネクションを初期化する際に、乱数を用いてノンスＮcを生成して、ＫxとＮcを基にコンテンツ鍵Ｋcを生成する。そして、ＤＴＣＰ＿Ｓｉｎｋ機器から要求されているコンテンツを、コンテンツ鍵Ｋcを用いて暗号化し、暗号化コンテンツとノンスＮcからなるＰＣＰ（Ｐｒｏｔｅｃｔｅｄ Ｃｏｎｔｅｎｔ Ｐａｃｋｅｔ）をＴＣＰストリーム上に乗せてＤＴＣＰ＿Ｓｉｎｋ機器に送信する。ＩＰプロトコルは、ＴＣＰストリームを所定の単位となるパケットの大きさに分割し、さらにヘッダ部を付加したＩＰパケットにし、指定されたＩＰアドレス宛てに届ける。
【００８５】
ＤＴＣＰ＿Ｓｉｎｋ機器側では、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器からの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、ストリームからノンスＮcを取り出すと、これと認証鍵Ｋauthから求めた鍵Ｋxを用いてコンテンツ鍵Ｋcを算出する。そして、このコンテンツ鍵Ｋcを用いて受信した暗号化コンテンツを復号することができる。
【００８６】
ＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、コンテンツ伝送用のＴＣＰコネクションを適宜切断することができる。
【００８７】
ここで、長大なＴＣＰストリーム全体に渡り同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなる。このため、ＤＴＣＰ−ＩＰでは、Ｓｏｕｒｃｅ機器は１２８ＭＢのコンテンツ毎にノンスＮcすなわちコンテンツ鍵Ｋcを更新するよう取り決められている。バイト・ストリーム中で、同じノンスＮcから生成されたコンテンツ鍵Ｋcを用いて暗号化されたデータの範囲は、同じ鍵を用いて復号することができる復号化単位となる。
【００８８】
また、バイト・ストリームの途中で復号鍵が動的に変更されることから、コンテンツ鍵の確認手続きが必要となる。そこで、ＤＴＣＰ＿Ｓｉｎｋ機器は、コンテンツ伝送用のＴＣＰコネクションとは別に、コンテンツ鍵の確認用のＴＣＰコネクションをさらに確立し、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器に対しコンテンツ鍵確認のための手続きを行なう。ＤＴＣＰ＿Ｓｉｎｋ機器は、コンテンツ鍵の確認が必要になると、コンテンツ伝送用のＴＣＰコネクションとは別に、適宜このＴＣＰコネクションを確立する。
【００８９】
但し、コンテンツ鍵の動的な変更並びにコンテンツ鍵の確認手続き自体は本発明の要旨には直接関連しないので、ここではこれ以上説明しない。
【００９０】
Ｃ．ＴＣＰペイロードからの認証制御用コマンドの抽出処理
上述したように、ＤＴＣＰ−ＩＰは、ＴＣＰコネクションを介してＤＴＣＰに準拠した機器同士でＡＫＥ認証を行ない、ＤＴＣＰ認証が完了した機器同士で鍵を共有し、コンテンツを伝送する際に暗号化及び復号をすることにより、伝送路の途中におけるコンテンツの盗聴、改竄を防ぐという、ＩＰネットワーク上においても安全なコンテンツ伝送手法を提供することができる。
【００９１】
ＤＴＣＰに準拠したコンテンツ伝送を実現するには、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器間でＤＴＣＰ−ＩＰ ＡＫＥ手続きを成功裏に実施する必要がある。
【００９２】
ＡＫＥコマンドは、基本的にＩＥＥＥ１３９４の上位プロトコルであるＡＶ／Ｃ Ｇｅｎｅｒａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎのサブセットという位置付けである。図６には、ＡＫＥコマンドのパケット・フォーマットを示している（例えば、非特許文献２を参照のこと）。同図に示すように、ＡＫＥコマンドは、１バイトのＴｙｐｅフィールドと、２バイトのＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドからなる。
【００９３】
Ｔｙｐｅ、ＢＬＣ、Ｃｏｎｔｒｏｌ各フィールドの０バイト目は、ＤＴＣＰをＩＰにマッピングするために使用される。Ｔｙｐｅフィールドにより、当該パケットがバージョン１のＡＫＥ制御パケットであることが示される。
【００９４】
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅは、当該ＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを記載するフィールドであり、ＤＴＣＰ仕様第８章及びＡＶ／Ｃデジタル・インターフェース・コマンドによる規定と同じ値を持つ。
【００９５】
Ｃｏｎｔｒｏｌフィールドの１〜７バイトは、ＩＰプロトコルで使用されない場合にはＣｏｎｔｒｏｌフィールドの７バイト目のＭＳＢを除いては、セクション８．３．１に規定されている０〜６バイトのオペランドと同一である。
【００９６】
ＡＫＥコマンドは、サブファンクションという種類に分けることができる。サブファンクションは、ＡＫＥコマンドの６バイト目のｓｕｂｆｕｎｃｔｉｏｎフィールドに記載されている。
【００９７】
ＡＫＥ＿Ｉｎｆｏフィールドは、セクション８．３．１に規定されているデータ・フィールドと同様である。
【００９８】
ＡＫＥ＿ｌａｂｅｌと各制御コマンドのソース・ソケットは適当なコントローラから由来することを確認しなければならない。
【００９９】
また、図７にはＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンスを示している（例えば、非特許文献２を参照のこと）。
【０１００】
Ｓｏｕｒｃｅ機器（又はＳｉｎｋ機器）からＳｉｎｋ機器（又はＳｏｕｒｃｅ機器）へ、ＡＫＥ ｓｔａｔｕｓ ｃｏｍｍａｎｄが送信され、これに対し、Ｓｉｎｋ機器（又はＳｏｕｒｃｅ機器）からＡＫＥ Ｓｔａｔｕｓ ｒｅｓｐｏｎｓｅが返され、その後、Ｓｏｕｒｃｅ機器（又はＳｉｎｋ機器）からＳｉｎｋ機器（又はＳｏｕｒｃｅ機器）へＣＨＡＬＬＥＮＧＥ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器（又はＳｏｕｒｃｅ機器）からｒｅｓｐｏｎｓｅが返される。
【０１０１】
続いて、Ｓｏｕｒｃｅ機器（又はＳｉｎｋ機器）からＳｉｎｋ機器（又はＳｏｕｒｃｅ機器）へ、ＲＥＳＰＯＮＳＥ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器（又はＳｏｕｒｃｅ機器）からＡＫＥ Ｓｔａｔｕｓ ｒｅｓｐｏｎｓｅが返される。
【０１０２】
その後、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へ、ＥＸＣＨＡＮＧＥ＿ＫＥＹ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器からｒｅｓｐｏｎｓｅが返される。
【０１０３】
続いて、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へ、ＳＲＭ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器からｒｅｓｐｏｎｓｅが返される。
【０１０４】
続いて、Ｓｏｕｒｃｅ機器からＳｉｎｋ機器へ、ＣＯＮＴＥＮＴ＿ＫＥＹ＿ＲＥＱ ｓｕｂｆｕｎｃｔｉｏｎが送信され、これに対し、Ｓｉｎｋ機器からｒｅｓｐｏｎｓｅが返される。
【０１０５】
但し、ｒｅｑｕｅｓｔはターゲットとなる機器を制御するときに用いられ、ｒｅｓｐｏｎｓｅはｒｅｑｕｅｓｔを受けた機器の応答を示すときに用いられる。コマンド・タイプを持つＡＫＥコマンドは、ＡＫＥコマンド・リクエストであり、レスポンス・コードを持つＡＫＥコマンドはＡＫＥコマンド・レスポンスである。
【０１０６】
ここで、ＤＴＣＰ、並びにＤＴＣＰ−ＩＰそれぞれにおいてＡＫＥコマンドを伝送する手順について考察してみる。
【０１０７】
ＤＴＣＰは原初的にはＩＥＥＥ１３９４を伝送路に用いたデジタル・コンテンツの伝送を規定したものであるが、この場合、ＡＫＥコマンド毎に１つのＭＡＣフレームを用いて伝送が行なわれるので、受信側のＤＴＣＰ機器では正しくＡＫＥコマンドを読み取ることができる。
【０１０８】
これに対し、ＤＴＣＰ−ＩＰでは、送信データはＴＣＰバイト・ストリームの形式をとるため、ＡＫＥコマンド受信先となるＤＴＣＰ機器側では、各ＩＰパケットを受信すると、これをＴＣＰバイト・ストリームに組み立て、さらにＴＣＰバイト・ストリームからＡＫＥコマンドを取り出さなければならない。
【０１０９】
ＴＣＰペイロードから個々のＡＫＥコマンドを取り出すための明確な意図を持った処理方法が必要であるが、ＤＴＣＰ−ＩＰ自体ではこの種の意味のある処理方法については特に取り決めは存在しない。そこで、以下では、ＴＣＰペイロードから認証制御用のコマンドを正確に抽出するための処理手順について説明する。
【０１１０】
但し、以下の説明では、ＡＫＥコマンドをやり取りするに先立って、Ｓｏｕｒｃｅ機器とＳｉｎｋ機器の間で ＴＣＰコネクションを確立し、双方向にバイト・データを送受信できる状態になっているものとする。
【０１１１】
また、ここで利用するＴＣＰ／ＩＰレイヤの処理モジュールは、ネットワークから受信したデータをソケット・バッファというバッファに溜め込むことができるものとする。ＴＣＰ／ＩＰレイヤの処理モジュールを利用する立場のモジュールは、そのソケット・バッファに溜め込まれたデータ（ネットワークを流れてきたデータ）に対し、「読み出す」という処理を行なうことでそのデータを取得することができるものとする。
【０１１２】
図５には、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器とＤＴＣＰ−ＩＰ ＡＫＥを実施する際の処理手順をフローチャートの形式で示している。以下、図６に示したＡＫＥコマンドのパケット・フォーマットを適宜参照しながら説明する。
【０１１３】
なお、ＡＫＥコマンドを抽出するまでの過程ではＳｏｕｒｃｅ機器及びＳｉｎｋ機器で実行する処理に差はないが、以下では説明の便宜上 Ｓｏｕｒｃｅ機器とＳｉｎｋ機器に分けて考えているが、本質ではないという点を理解されたい。
【０１１４】
また、ＴＣＰペイロードよりＡＫＥコマンドを抽出した以降はそのＡＫＥコマンドの内容に対応した処理を行なうことになるが、本発明の要旨とは直接関連しないので、その処理に関する説明は省略する。
【０１１５】
Ｓｏｕｒｃｅ機器からＳｉｎｋ機器に対してＴＣＰペイロードにバイト・データが格納されたＴＣＰ／ＩＰパケット（バイト・ストリーム）が送信されると、Ｓｉｎｋ機器のソケット・バッファにバイト・データが溜め込まれ始める。このとき、Ｓｏｕｒｃｅ機器、若しくはＳｉｎｋ機器がデータ送受信を止めるまで（例えば、ＴＣＰコネクション確立が切断されるまで）、Ｓｉｎｋ機器ではＴＣＰストリームからＡＫＥコマンドを抽出する処理を実行する。
【０１１６】
まず、読み出し済みのバイト・データが、Ｔｙｐｅ［０］とＢＬＣ（Ｂｙｔｅ Ｌｅｎｇｔｈ Ｃｏｎｔｒｏｌ）を取得できるだけのサイズ以上となっているかどうか、具体的には、読み出し済みのバイト・データが３（＝１＋２＝Ｔｙｐｅ［０］＋ＢＬＣサイズ）以上となっているかどうかをチェックする（ステップＳ１）。
【０１１７】
ここで、読み出し済みのバイト・データがＴｙｐｅ［０］とＢＬＣを取得できるだけのサイズ未満であった場合には、ソケット・バッファよりバイト・データを可能な限り読み出して（ステップＳ１−１）、ステップＳ１へ戻る。
【０１１８】
また、読み出し済みのバイト・データがＴｙｐｅ［０］とＢＬＣを取得できるだけのサイズ以上である場合には、そのバイト・データの１バイト目をＴｙｐｅ［０］の値として、２〜３バイト目のバイト・データを連結してＢＬＣフィールドの値として取得した後（ステップＳ１−２）、次ステップＳ２に進む。
【０１１９】
ステップＳ２では、読み出し済みのバイト・データがＴｙｐｅ［０］とＢＬＣとＢＬＣフィールド値の合計、すなわち、１バイトのＴｙｐｅフィールドと２バイトのＢＬＣフィールドとＢＬＣで記述されたバイト長のＣｏｎｔｒｏｌフィールドを取得できるだけのサイズ以上となっているかどうか、具体的には、３＋ＢＬＣフィールド値以上となっているかどうかをチェックする。
【０１２０】
ここで、読み出し済みのバイト・データがＴｙｐｅ［０］とＢＬＣとＢＬＣフィールド値の合計を取得できるだけのサイズ未満であった場合には、ソケット・バッファよりバイト・データを可能な限り読み出して（ステップＳ２−１）、ステップＳ２へ戻る。
【０１２１】
また、読み出し済みのバイト・データがＴｙｐｅ［０］とＢＬＣとＢＬＣフィールド値の合計を取得できるだけのサイズ以上である場合には、次ステップ３へ進む。
【０１２２】
ステップＳ３では、ステップＳ１−２で取得したＴｙｐｅ［０］の値が０ｘ０１かどうか、すなわち取得したバイト・データがＡＫＥコマンドであるかどうかをチェックする。
【０１２３】
ここで、ステップＳ１−２で取得したＴｙｐｅ［０］の値が０ｘ０１でない場合には、正常なＡＫＥコマンドでないことになる。そこで、バイト・データからのＡＫＥコマンドの抽出を諦めて、３＋ＢＬＣフィールド値分のバイト・データを読み捨てて（ステップＳ３−１）、ステップＳ１へ戻る。
【０１２４】
また、ステップＳ１−２で取得したＴｙｐｅ［０］の値が０ｘ０１である場合には、次ステップＳ４へ進む。
【０１２５】
ステップＳ４では、ステップＳ１−２で取得したＢＬＣの値が０ｘ００００、若しくは０ｘ０００１以上かどうか、すなわちバイト・データの４バイト目が存在するかどうかをチェックする。
【０１２６】
ここで、ステップＳ１−２で取得したＢＬＣの値が０ｘ００００であった場合には、Ｃｏｎｔｒｏｌフィールドが０バイト長となり、正常なＡＫＥコマンドでないことになる。そこで、バイト・データからのＡＫＥコマンドの抽出を諦めて、３＋ＢＬＣ値分のバイト・データを読み捨てて（ステップＳ３−１）、ステップＳ１に戻る。
【０１２７】
また、ステップＳ１−２で取得したＢＬＣの値が０ｘ０００１以上であった場合には、バイト・データの４バイト目以降のＣｏｎｔｒｏｌフィールドが正常に存在することになる。この場合、バイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールドの値として、４バイト目の下位４ビットをｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値として、それぞれ取得し（ステップＳ４−２）、次ステップＳ５に進む。
【０１２８】
ステップＳ５では、ステップＳ４−２で取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏの値が０ｘ０かどうかをチェックする。
【０１２９】
ここで、ステップＳ４−２で取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏの値が０ｘ０でなかった場合には、正常なＡＫＥコマンドでないので、バイト・データからのＡＫＥコマンドの抽出を諦めて、３＋ＢＬＣ値分のバイト・データを読み捨てて（ステップＳ３−１）、ステップＳ１に戻る。
【０１３０】
また、ステップＳ４−２で取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏの値が正しく０ｘ０である場合には、次ステップＳ６に進む。
【０１３１】
ステップＳ６では、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が、いずれかのコマンド・タイプ若しくはレスポンス・コードを示す値と一致しているかをチェックする。
【０１３２】
この判断ブロックでは、具体的には、０ｘ０、０ｘ１、０ｘ８、０ｘ９、０ｘａ、０ｘｃのいずれかと一致しているかどうかをチェックする。ちなみに、０ｘ０は コマンド・タイプ（ｃｔｙｐｅ）の“ＣＯＮＴＲＯＬ”を表し、０ｘ１はコマンド・タイプ（ｃｔｙｐｅ）の“ＳＴＡＴＵＳ”を表し、０ｘ８はレスポンス・コードの“ＮＯＴ_ＩＭＰＬＥＭＥＮＴＥＤ”を表し、０ｘ９はレスポンス・コードの“ＡＣＣＥＰＴＥＤ”を表し、０ｘａはレスポンス・コードの“ＲＥＪＥＣＴＥＤ”を表し、０ｘｃはレスポンス・コードの“ＳＴＡＢＬＥ”を表す。
【０１３３】
ここで、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値がいずれかのコマンド・タイプ若しくはレスポンス・コードを示す値とも一致していなかった場合には、正常なＡＫＥコマンドではないので、バイト・データからのＡＫＥコマンドの抽出を諦めて、３＋ＢＬＣ値分のバイト・データを読み捨てて（ステップＳ３−１）、ステップＳ１に戻る。
【０１３４】
また、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値がいずれかのコマンド・タイプ若しくはレスポンス・コードを示す値と一致していた場合には、次ステップＳ７に進む。
【０１３５】
ステップＳ７では、ステップＳ１−２で取得したＢＬＣの値が０ｘ０００１、０ｘ０００２、又は０ｘ０００３以上かどうかをチェックする。
【０１３６】
ここで、ステップＳ１−２で取得したＢＬＣの値が０ｘ０００１又は０ｘ０００２のいずれかである場合には、受信したＡＫＥコマンドが当該ＤＴＣＰ機器において非実装（ＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤ）、又はＡＫＥコマンドとして正常でない可能性がある。そこで、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ０若しくは０ｘ１、０ｘ８、又は、０ｘ９、０ｘａ、０ｘｃのいずれであるかをさらにチェックする（ステップＳ７−１）。
【０１３７】
ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ０若しくは０ｘ１、すなわちコマンド・タイプのＡＫＥコマンドであった場合には、受信したＡＫＥコマンドが当該ＤＴＣＰ機器において非実装であることから、読み出していた３＋ＢＬＣ値分のバイト・データの処理を終了した後、このデータに対しＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスを生成し、Ｓｏｕｒｃｅ機器に対して当該レスポンスを送信してから（ステップＳ７−１−１）、ステップＳ１に戻る。
【０１３８】
また、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ８、すなわちＡＫＥコマンドがＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤのレスポンス・コードであった場合には、読み出していた３＋ＢＬＣ値分のバイト・データをＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤであると判断し、ＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤのＡＫＥコマンド・レスポンスとして抽出し（ステップＳ７−１−２）、処理を終了する。
【０１３９】
また、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ９、０ｘａ、０ｘｃのうちいずれか、すなわち通常のレスポンス・コードを示す場合には、受信したバイト・データはＡＫＥコマンドとして正常でないので、読み出していた３＋ＢＬＣ値分のバイト・データを読み捨てて、ステップＳ１へ戻る。
【０１４０】
また、ステップＳ１−２で取得したＢＬＣの値が０ｘ０００３以上であった場合には、ＡＫＥコマンドとして正常なバイト長のＣｏｎｔｒｏｌフィールドを持つことになるので、そのバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎフィールドの値として取得した後（ステップＳ７−２）、次ステップＳ８へ進む。
【０１４１】
ステップＳ８では、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ０、０ｘ１、０ｘ８、０ｘ９、０ｘａ、０ｘｃのいずれと一致するかをチェックする。
【０１４２】
ここで、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ０、すなわち受信したＡＫＥコマンドがコマンド・タイプのＣＯＮＴＲＯＬであった場合には、ＢＬＣがｓｕｂｆｕｎｃｔｉｏｎに対して期待通りであるか、すなわちステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致しているかどうかをさらにチェックする（ステップＳ８−１）。
【０１４３】
そして、ステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致していない場合、若しくはｓｕｂｆｕｎｃｔｉｏｎ値がＤＴＣＰ−ＩＰで規定されていない値であれば、当該ＤＴＣＰ機器は受信したＡＫＥコマンドを非実装であることになる。この場合には、読み出していた３＋ＢＬＣ値分のバイト・データの処理を終了すると、このデータに対しＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスを生成し、Ｓｏｕｒｃｅ機器に対して当該レスポンスを送信した後（ステップＳ７−１−１）、ステップＳ１に戻る。
【０１４４】
一方、ステップＳ８−１でサイズが一致すると判定された場合には、読み出していた３＋ＢＬＣフィールド値分のバイト・データを、当該サブファンクションによるＡＫＥコマンド・リクエストであると判断し、ＡＫＥコマンド・リクエストとして抽出して、処理を終了する。その後、ＡＫＥコマンド・リクエスト受信処理を行ないつつ（ステップＳ８−１−２）、ステップＳ１へ戻る。
【０１４５】
また、ステップＳ８において、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ１、すなわちＡＫＥコマンドがコマンド・タイプのＳＴＡＴＵＳであると判定された場合にも、ステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致しているかどうかをさらにチェックする（ステップＳ８−１）。
【０１４６】
この場合も、ステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致していない場合、若しくはｓｕｂｆｕｎｃｔｉｏｎ値がＤＴＣＰ−ＩＰで規定されていない値であった場合には、読み出していた３＋ＢＬＣ値分のバイト・データの処理を終了し、このデータに対しＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスを生成し、Ｓｏｕｒｃｅ機器に対して当該レスポンスを送信した後（ステップＳ７−１−１）、ステップＳ１に戻る。一方、サイズが一致すると判定された場合には、読み出していた３＋ＢＬＣフィールド値分のバイト・データを、当該サブファンクションによるＡＫＥコマンド・リクエストであると判断し、ＡＫＥコマンド・リクエストとして抽出して、処理を終了する。その後、ＡＫＥコマンド・リクエスト受信処理を行ないつつ（ステップＳ８−１−２）、ステップＳ１へ戻る。
【０１４７】
また、ステップＳ８において、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ８、すなわちＡＫＥコマンドがレスポンス・コードのＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤであると判定された場合には、読み出していた３＋ＢＬＣフィールド値分のバイト・データをＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤレスポンスであると判断し、ＮＯＴ＿ＩＭＰＬＥＭＥＮＴＥＤのＡＫＥコマンド・レスポンスとして抽出し（ステップＳ７−１−２）、処理を終了する。
【０１４８】
また、ステップＳ８において、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘ９又は０ｘｃ、すなわちＡＫＥコマンドがＡＣＣＥＰＴＥＤ並びにＳＴＡＢＬＥを示すレスポンス・コードであると判定された場合には、ＢＬＣがｓｕｂｆｕｎｃｔｉｏｎに対して期待通り、すなわちステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致しているかどうかをさらにチェックする（ステップＳ８−４）。
【０１４９】
ここで、ステップＳ７−２で取得したｓｕｂｆｕｎｃｔｉｏｎ値に対応するサブファンクション毎に規定されているサイズと、ステップＳ１−２で取得したＢＬＣの値が一致していない場合、若しくはｓｕｂｆｕｎｃｔｉｏｎ値がＤＴＣＰ−ＩＰで規定されていない値であった場合には、受信したバイト・データがＡＫＥコマンドとして正常でないので、読み出していた３＋ＢＬＣ値分のバイト・データを読み捨てて、ステップＳ１に戻る。
【０１５０】
一方、ステップＳ８−４においてサイズが一致すると判断された場合には、読み出していた３＋ＢＬＣフィールド値分のバイト・データを、当該サブファンクションによるＡＫＥコマンド・リクエストであると判断し、ＡＫＥコマンド・リクエストとして抽出して、処理を終了する。その後、ＡＫＥコマンド・リクエスト受信処理を行ないつつ（ステップＳ８−４−２）、ステップＳ１へ戻る。
【０１５１】
また、ステップＳ８において、ステップＳ４−２で取得したｃｔｙｐｅ／ｒｅｓｐｏｎｓｅの値が０ｘａ、すなわちレスポンス・コードのＲＥＪＥＣＴＥＤであると判定された場合には、ステップＳ１−２で取得したＢＬＣの値がＲＥＪＥＣＴＥＤレスポンスでのサイズに一致しているかどうかをさらにチェックする（ステップＳ８−５）。
【０１５２】
ここで、ステップＳ１−２で取得したＢＬＣの値がＲＥＪＥＣＴＥＤレスポンスでのサイズに一致していない場合には、受信したバイト・データがＡＫＥコマンドとして正常でないので、読み出していた３＋ＢＬＣ値分のバイト・データを読み捨てて、ステップＳ１に戻る。
【０１５３】
一方、ステップＳ１−２で取得したＢＬＣの値がＲＥＪＥＣＴＥＤレスポンスでのサイズに一致する場合には、読み出していた３＋ＢＬＣフィールド値分のバイト・データを、ＲＥＪＥＣＴＥＤのＡＫＥコマンド・レスポンスであると判断し、ＲＥＪＥＣＴＥＤのＡＫＥコマンド・レスポンスとして抽出して、処理を終了する。その後、ＡＫＥコマンド・リクエスト受信処理を行ないつつ（ステップＳ８−５−２）、ステップＳ１へ戻る。
【０１５４】
なお、図５に示したフローチャートでは、ステップＳ３においてステップＳ１−２で取得したＴｙｐｅ［０］の値が０ｘ０１かどうかをチェックするようにしているが、ステップＳ３におけるチェックなしに直接ステップＳ４に進むようにしてもよい。
【０１５５】
また、ステップＳ５において、ステップＳ４−２で取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏの値が０ｘ０かどうかをチェックすることなしに、直接ステップＳ６に進むようにしてもよい。
【０１５６】
また、ステップＳ３においてステップＳ１−２で取得したＴｙｐｅ［０］の値が０ｘ０１かどうかをチェックすることなく、ステップＳ４へ進み、且つ、ステップＳ５においてｒｅｓｅｒｖｅｄ＿ｚｅｒｏの値が０ｘ０かどうかをチェックすることなしに、直接ステップＳ６に進むようにしてもよい。
【０１５７】
また、ステップＳ２−１では、ソケット・バッファよりバイト・データを可能な限り読み出した後にステップＳ２に戻るが、ステップＳ１に戻るようにしてもよい。
【産業上の利用可能性】
【０１５８】
以上、特定の実施形態を参照しながら、本発明について詳解してきた。しかしながら、本発明の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【０１５９】
本明細書では、ＤＴＣＰ−ＩＰに準拠した情報通信機器の間で相互認証及び鍵交換（ＡＫＥ）のためのＡＫＥコマンドを送受信するという実施形態を例にとって説明してきたが、本発明の要旨はこれに限定されるものではない。ＩＰプロトコルを利用したコンテンツ伝送手続きを規定したＤＴＣＰ以外のシステムにおいて、ＴＣＰバイト・ストリーム上で送られてくるコマンドを受信側で取り出す際に、同様に本発明を適用することができる。
【０１６０】
要するに、例示という形態で本発明を開示してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本発明の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【図面の簡単な説明】
【０１６１】
【図１】図１は、本発明の一実施形態に係る情報通信システムの構成例を模式的に示した図である。
【図２】図２は、図１に示した情報通信システムにおいて、クライアント（すなわち、Ｓｉｎｋ機器）として動作する情報通信装置の機能構成を模式的に示した図である。
【図３】図３は、図１に示した情報通信システムにおいて、サーバ（すなわち、Ｓｏｕｒｃｅ機器）として動作する情報通信装置の機能構成を模式的に示した図である。
【図４】図４は、ＤＴＣＰ＿Ｓｏｕｒｃｅ機器とＤＴＣＰ＿Ｓｉｎｋ機器の間でＡＫＥ手続き、及びＨＴＴＰプロトコルを利用したコンテンツ伝送を行なう仕組みを示した図である。
【図５】図５は、Ｓｏｕｒｃｅ機器がＳｉｎｋ機器とＤＴＣＰ−ＩＰ ＡＫＥを実施する際の処理手順を示したフローチャートである。
【図６】図６は、ＡＫＥコマンドのパケット・フォーマットを示した図である。
【図７】図７は、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンスを示した図である。
【図８】図８は、ＤＴＣＰ、並びにＤＴＣＰ−ＩＰそれぞれにおいて伝送されるＡＫＥコマンドを受信側の機器で取り出す仕組みを説明するための図である。
【特許請求の範囲】
【請求項１】
ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した他の情報通信装置との間で相互認証及び鍵交換のための認証制御用（ＡＫＥ）コマンドを受信する情報通信装置であって、ＡＫＥコマンドは、先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドを備え、該他の情報通信装置からＴＣＰストリームとして送られてくるバイト・データからＡＫＥコマンドを抽出する際に、
受信したＴＣＰストリームからバイト・データをＡＫＥコマンド抽出用情報として取得するＡＫＥコマンド抽出用情報取得手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値を取得する第１の情報取得手段と、
Ｔｙｐｅフィールド及びＢＬＣフィールドの値をチェックする第１の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド値として取得するとともに、下位４ビットをＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを示すｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールド値として取得する第２の情報取得手段と、
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第２の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する第３の情報取得手段と、
ＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第３の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンドを抽出するコマンド抽出手段と、
ＡＫＥコマンドを送信するコマンド送信手段と、
ＡＫＥコマンドの受信処理を起動するコマンド受信処理起動手段と、
を具備することを特徴とする情報通信装置。
【請求項２】
受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容に応じて、前記コマンド抽出手段がＡＫＥコマンドを抽出することなく、取得したバイト・データを読み捨てるデータ破棄手段をさらに備える、
ことを特徴とする請求項１に記載の情報通信装置。
【請求項３】
前記第１の情報チェック手段は、取得したＴｙｐｅフィールド又はＢＬＣフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックし、
該チェック結果が否定的であるとき、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄手段が読み捨てる、
ことを特徴とする請求項２に記載の情報通信装置。
【請求項４】
前記第２の情報チェック手段は、取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド又はｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックし、
該チェック結果が否定的であるとき、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄手段が読み捨てる、
ことを特徴とする請求項２に記載の情報通信装置。
【請求項５】
受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容に応じて、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、前記コマンド送信手段がＡＫＥコマンド・レスポンスを送信する、
ことを特徴とする請求項１に記載の情報通信装置。
【請求項６】
前記第３の情報チェック手段は、ＢＬＣフィールドの値が示すバイト長ではＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できないときには、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックし、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときには、前記コマンド抽出手段はバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信手段は、非実装であることを示すＡＫＥコマンド・レスポンスを送信し、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときには、前記コマンド・レスポンス抽出手段は非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理起動手段は非実装レスポンスの受信処理を起動し、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が通常のレスポンス・コードであるときには、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項１に記載の情報通信装置。
【請求項７】
ＢＬＣフィールドの値が示すバイト長でＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できるときには、前記第３の情報取得手段はＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得し、
前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に応じてＢＬＣフィールドの値をチェックする、
ことを特徴とする請求項１に記載の情報通信装置。
【請求項８】
前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときに、前記第３の情報取得手段により取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・リクエストを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・リクエストの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出手段はバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信手段は、非実装であることを示すＡＫＥコマンド・レスポンスを送信する、
ことを特徴とする請求項７に記載の情報通信装置。
【請求項９】
前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的でないレスポンス・コードを示すときに、前記第３の情報取得手段により取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・レスポンスの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項７に記載の情報通信装置。
【請求項１０】
前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的なレスポンス・コードを示すときに、ＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・レスポンスの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項７に記載の情報通信装置。
【請求項１１】
前記第３の情報チェック手段がｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときと判定したときには、前記コマンド・レスポンス抽出手段は非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理起動手段は非実装レスポンスの受信処理を起動する、
ことを特徴とする請求項７に記載の情報通信装置。
【請求項１２】
ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した他の情報通信装置との間で相互認証及び鍵交換のための認証制御用（ＡＫＥ）コマンドを受信する情報通信方法であって、ＡＫＥコマンドは、先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドを備え、該他の情報通信装置からＴＣＰストリームとして送られてくるバイト・データからＡＫＥコマンドを抽出する際に、
受信したＴＣＰストリームからバイト・データをＡＫＥコマンド抽出用情報として取得するＡＫＥコマンド抽出用情報取得ステップと、
ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値を取得する第１の情報取得ステップと、
Ｔｙｐｅフィールド及びＢＬＣフィールドの値をチェックする第１の情報チェック・ステップと、
ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド値として取得するとともに、下位４ビットをＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを示すｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールド値として取得する第２の情報取得ステップと、
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第２の情報チェック・ステップと、
ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する第３の情報取得ステップと、
ＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第３の情報チェック・ステップと、
ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンドを抽出するコマンド抽出ステップと、
ＡＫＥコマンドを送信するコマンド送信ステップと、
ＡＫＥコマンドの受信処理を起動するコマンド受信処理起動ステップと、
を具備することを特徴とする情報通信方法。
【請求項１３】
受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容に応じて、前記コマンド抽出ステップによりＡＫＥコマンドを抽出することなく、取得したバイト・データを読み捨てるデータ破棄ステップをさらに備える、
ことを特徴とする請求項１２に記載の情報通信方法。
【請求項１４】
前記第１の情報チェック・ステップでは、取得したＴｙｐｅフィールド又はＢＬＣフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックし、
該チェック結果が否定的であるとき、前記コマンド抽出ステップによりＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄ステップにおいて読み捨てる、
ことを特徴とする請求項１３に記載の情報通信方法。
【請求項１５】
前記第２の情報チェック・ステップでは、取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド又はｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックし、
該チェック結果が否定的であるとき、前記コマンド抽出ステップによりＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄ステップにおいて読み捨てる、
ことを特徴とする請求項１３に記載の情報通信方法。
【請求項１６】
受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容に応じて、前記コマンド抽出ステップによりＡＫＥコマンドを抽出せずに、前記コマンド送信手段がＡＫＥコマンド・レスポンスを送信する、
ことを特徴とする請求項１２に記載の情報通信方法。
【請求項１７】
前記第３の情報チェック・ステップでは、ＢＬＣフィールドの値が示すバイト長ではＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できないときには、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックし、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときには、前記コマンド抽出ステップによりバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信ステップにおいて、非実装であることを示すＡＫＥコマンド・レスポンスを送信し、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときには、前記コマンド・レスポンス抽出ステップにより非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理ステップにおいて非実装レスポンスの受信処理を起動し、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が通常のレスポンス・コードであるときには、前記コマンド抽出ステップによりＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項１２に記載の情報通信方法。
【請求項１８】
ＢＬＣフィールドの値が示すバイト長でＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できるときには、前記第３の情報取得ステップでは、ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得し、
前記第３の情報チェック・ステップでは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に応じてＢＬＣフィールドの値をチェックする、
ことを特徴とする請求項１２に記載の情報通信方法。
【請求項１９】
前記第３の情報チェック・ステップでは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときに、前記第３の情報取得ステップにより取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出ステップにおいてＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・リクエストを抽出するとともに、前記コマンド受信処理起動においてＡＫＥコマンド・リクエストの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出ステップではバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信ステップにおいて、非実装であることを示すＡＫＥコマンド・レスポンスを送信する、
ことを特徴とする請求項１８に記載の情報通信方法。
【請求項２０】
前記第３の情報チェック・ステップでは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的でないレスポンス・コードを示すときに、前記第３の情報取得手段により取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出ステップにおいて、ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動ステップにおいてＡＫＥコマンド・レスポンスの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出によりＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項１８に記載の情報通信方法。
【請求項２１】
前記第３の情報チェック・ステップでは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的なレスポンス・コードを示すときに、ＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出ステップにおいて、ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動ステップにおいてＡＫＥコマンド・レスポンスの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出ステップによりＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項１８に記載の情報通信方法。
【請求項２２】
前記第３の情報チェック・ステップにおいてｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときと判定したときには、前記コマンド・レスポンス抽出ステップにおいて、非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理起動ステップにおいて非実装レスポンスの受信処理を起動する、
ことを特徴とする請求項１８に記載の情報通信方法。
【請求項２３】
ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した他の情報通信装置との間で相互認証及び鍵交換のための認証制御用（ＡＫＥ）コマンドを受信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、ＡＫＥコマンドは、先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドを備え、該他の情報通信装置からＴＣＰストリームとして送られてくるバイト・データからＡＫＥコマンドを抽出する際に、前記コンピュータ・システムに対し、
受信したＴＣＰストリームからバイト・データをＡＫＥコマンド抽出用情報として取得するＡＫＥコマンド抽出用情報取得手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値を取得する第１の情報取得手順と、
Ｔｙｐｅフィールド及びＢＬＣフィールドの値をチェックする第１の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド値として取得するとともに、下位４ビットをＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを示すｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールド値として取得する第２の情報取得手順と、
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第２の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する第３の情報取得手順と、
ＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第３の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンドを抽出するコマンド抽出手順と、
ＡＫＥコマンドを送信するコマンド送信手順と、
ＡＫＥコマンドの受信処理を起動するコマンド受信処理起動手順と、
を実行させることを特徴とするコンピュータ・プログラム。
【請求項１】
ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した他の情報通信装置との間で相互認証及び鍵交換のための認証制御用（ＡＫＥ）コマンドを受信する情報通信装置であって、ＡＫＥコマンドは、先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドを備え、該他の情報通信装置からＴＣＰストリームとして送られてくるバイト・データからＡＫＥコマンドを抽出する際に、
受信したＴＣＰストリームからバイト・データをＡＫＥコマンド抽出用情報として取得するＡＫＥコマンド抽出用情報取得手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値を取得する第１の情報取得手段と、
Ｔｙｐｅフィールド及びＢＬＣフィールドの値をチェックする第１の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド値として取得するとともに、下位４ビットをＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを示すｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールド値として取得する第２の情報取得手段と、
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第２の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する第３の情報取得手段と、
ＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第３の情報チェック手段と、
ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンドを抽出するコマンド抽出手段と、
ＡＫＥコマンドを送信するコマンド送信手段と、
ＡＫＥコマンドの受信処理を起動するコマンド受信処理起動手段と、
を具備することを特徴とする情報通信装置。
【請求項２】
受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容に応じて、前記コマンド抽出手段がＡＫＥコマンドを抽出することなく、取得したバイト・データを読み捨てるデータ破棄手段をさらに備える、
ことを特徴とする請求項１に記載の情報通信装置。
【請求項３】
前記第１の情報チェック手段は、取得したＴｙｐｅフィールド又はＢＬＣフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックし、
該チェック結果が否定的であるとき、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄手段が読み捨てる、
ことを特徴とする請求項２に記載の情報通信装置。
【請求項４】
前記第２の情報チェック手段は、取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド又はｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックし、
該チェック結果が否定的であるとき、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄手段が読み捨てる、
ことを特徴とする請求項２に記載の情報通信装置。
【請求項５】
受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容に応じて、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、前記コマンド送信手段がＡＫＥコマンド・レスポンスを送信する、
ことを特徴とする請求項１に記載の情報通信装置。
【請求項６】
前記第３の情報チェック手段は、ＢＬＣフィールドの値が示すバイト長ではＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できないときには、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックし、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときには、前記コマンド抽出手段はバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信手段は、非実装であることを示すＡＫＥコマンド・レスポンスを送信し、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときには、前記コマンド・レスポンス抽出手段は非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理起動手段は非実装レスポンスの受信処理を起動し、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が通常のレスポンス・コードであるときには、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項１に記載の情報通信装置。
【請求項７】
ＢＬＣフィールドの値が示すバイト長でＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できるときには、前記第３の情報取得手段はＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得し、
前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に応じてＢＬＣフィールドの値をチェックする、
ことを特徴とする請求項１に記載の情報通信装置。
【請求項８】
前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときに、前記第３の情報取得手段により取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・リクエストを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・リクエストの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出手段はバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信手段は、非実装であることを示すＡＫＥコマンド・レスポンスを送信する、
ことを特徴とする請求項７に記載の情報通信装置。
【請求項９】
前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的でないレスポンス・コードを示すときに、前記第３の情報取得手段により取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・レスポンスの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項７に記載の情報通信装置。
【請求項１０】
前記第３の情報チェック手段は、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的なレスポンス・コードを示すときに、ＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出手段はＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動手段がＡＫＥコマンド・レスポンスの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出手段はＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項７に記載の情報通信装置。
【請求項１１】
前記第３の情報チェック手段がｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときと判定したときには、前記コマンド・レスポンス抽出手段は非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理起動手段は非実装レスポンスの受信処理を起動する、
ことを特徴とする請求項７に記載の情報通信装置。
【請求項１２】
ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した他の情報通信装置との間で相互認証及び鍵交換のための認証制御用（ＡＫＥ）コマンドを受信する情報通信方法であって、ＡＫＥコマンドは、先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドを備え、該他の情報通信装置からＴＣＰストリームとして送られてくるバイト・データからＡＫＥコマンドを抽出する際に、
受信したＴＣＰストリームからバイト・データをＡＫＥコマンド抽出用情報として取得するＡＫＥコマンド抽出用情報取得ステップと、
ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値を取得する第１の情報取得ステップと、
Ｔｙｐｅフィールド及びＢＬＣフィールドの値をチェックする第１の情報チェック・ステップと、
ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド値として取得するとともに、下位４ビットをＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを示すｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールド値として取得する第２の情報取得ステップと、
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第２の情報チェック・ステップと、
ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する第３の情報取得ステップと、
ＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第３の情報チェック・ステップと、
ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンドを抽出するコマンド抽出ステップと、
ＡＫＥコマンドを送信するコマンド送信ステップと、
ＡＫＥコマンドの受信処理を起動するコマンド受信処理起動ステップと、
を具備することを特徴とする情報通信方法。
【請求項１３】
受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容に応じて、前記コマンド抽出ステップによりＡＫＥコマンドを抽出することなく、取得したバイト・データを読み捨てるデータ破棄ステップをさらに備える、
ことを特徴とする請求項１２に記載の情報通信方法。
【請求項１４】
前記第１の情報チェック・ステップでは、取得したＴｙｐｅフィールド又はＢＬＣフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックし、
該チェック結果が否定的であるとき、前記コマンド抽出ステップによりＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄ステップにおいて読み捨てる、
ことを特徴とする請求項１３に記載の情報通信方法。
【請求項１５】
前記第２の情報チェック・ステップでは、取得したｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド又はｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に基づいて、ＡＫＥコマンド抽出用情報として取得したバイト・データがＡＫＥコマンドを含むかどうかをチェックし、
該チェック結果が否定的であるとき、前記コマンド抽出ステップによりＡＫＥコマンドを抽出せずに、取得したバイト・データを前記データ破棄ステップにおいて読み捨てる、
ことを特徴とする請求項１３に記載の情報通信方法。
【請求項１６】
受信したＴＣＰストリームから取得したＡＫＥコマンド抽出用情報の内容に応じて、前記コマンド抽出ステップによりＡＫＥコマンドを抽出せずに、前記コマンド送信手段がＡＫＥコマンド・レスポンスを送信する、
ことを特徴とする請求項１２に記載の情報通信方法。
【請求項１７】
前記第３の情報チェック・ステップでは、ＢＬＣフィールドの値が示すバイト長ではＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できないときには、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックし、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときには、前記コマンド抽出ステップによりバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信ステップにおいて、非実装であることを示すＡＫＥコマンド・レスポンスを送信し、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときには、前記コマンド・レスポンス抽出ステップにより非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理ステップにおいて非実装レスポンスの受信処理を起動し、
ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が通常のレスポンス・コードであるときには、前記コマンド抽出ステップによりＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項１２に記載の情報通信方法。
【請求項１８】
ＢＬＣフィールドの値が示すバイト長でＣｏｎｔｒｏｌフィールドにｓｕｂｆｕｎｃｔｉｏｎを記載できるときには、前記第３の情報取得ステップでは、ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得し、
前記第３の情報チェック・ステップでは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値に応じてＢＬＣフィールドの値をチェックする、
ことを特徴とする請求項１２に記載の情報通信方法。
【請求項１９】
前記第３の情報チェック・ステップでは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値がコマンド・タイプを示すときに、前記第３の情報取得ステップにより取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出ステップにおいてＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・リクエストを抽出するとともに、前記コマンド受信処理起動においてＡＫＥコマンド・リクエストの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出ステップではバイト・データからＡＫＥコマンドを抽出せず、前記コマンド送信ステップにおいて、非実装であることを示すＡＫＥコマンド・レスポンスを送信する、
ことを特徴とする請求項１８に記載の情報通信方法。
【請求項２０】
前記第３の情報チェック・ステップでは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的でないレスポンス・コードを示すときに、前記第３の情報取得手段により取得したｓｕｂｆｕｎｃｔｉｏｎに対してＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出ステップにおいて、ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動ステップにおいてＡＫＥコマンド・レスポンスの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出によりＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項１８に記載の情報通信方法。
【請求項２１】
前記第３の情報チェック・ステップでは、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が否定的なレスポンス・コードを示すときに、ＢＬＣフィールドの値が示すＣｏｎｔｒｏｌフィールドのバイト長が期待通りであるかどうかをチェックし、
該チェック結果が肯定的であれば、前記コマンド抽出ステップにおいて、ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンド・レスポンスを抽出するとともに、前記コマンド受信処理起動ステップにおいてＡＫＥコマンド・レスポンスの受信処理を起動し、
該チェック結果が否定的であれば、前記コマンド抽出ステップによりＡＫＥコマンドを抽出せずに、取得したバイト・データを読み捨てる、
ことを特徴とする請求項１８に記載の情報通信方法。
【請求項２２】
前記第３の情報チェック・ステップにおいてｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値が非実装を示すレスポンス・コードであるときと判定したときには、前記コマンド・レスポンス抽出ステップにおいて、非実装レスポンスとしてＡＫＥコマンド・レスポンスを抽出し、前記コマンド受信処理起動ステップにおいて非実装レスポンスの受信処理を起動する、
ことを特徴とする請求項１８に記載の情報通信方法。
【請求項２３】
ＩＰネットワーク上で、ＤＴＣＰ−ＩＰに準拠した他の情報通信装置との間で相互認証及び鍵交換のための認証制御用（ＡＫＥ）コマンドを受信するための処理をコンピュータ・システム上で実行するようにコンピュータ可読形式で記述されたコンピュータ・プログラムであって、ＡＫＥコマンドは、先頭から順に１バイト長のＴｙｐｅフィールドと、２バイト長のＢｙｔｅ Ｌｅｎｇｔｈ ｏｆ Ｃｏｎｔｒｏｌ（ＢＬＣ）フィールドと、ＢＬＣフィールドに記載されたバイト長を持つＣｏｎｔｒｏｌフィールドと、ＡＫＥ＿Ｉｎｆｏフィールドを備え、該他の情報通信装置からＴＣＰストリームとして送られてくるバイト・データからＡＫＥコマンドを抽出する際に、前記コンピュータ・システムに対し、
受信したＴＣＰストリームからバイト・データをＡＫＥコマンド抽出用情報として取得するＡＫＥコマンド抽出用情報取得手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの１〜３バイト目からＴｙｐｅフィールド及びＢＬＣフィールドの値を取得する第１の情報取得手順と、
Ｔｙｐｅフィールド及びＢＬＣフィールドの値をチェックする第１の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの４バイト目の上位４ビットをｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド値として取得するとともに、下位４ビットをＡＫＥコマンドのコマンド・タイプ又はレスポンス・コードを示すｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールド値として取得する第２の情報取得手順と、
ｒｅｓｅｒｖｅｄ＿ｚｅｒｏフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第２の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データの６バイト目をｓｕｂｆｕｎｃｔｉｏｎとして取得する第３の情報取得手順と、
ＢＬＣフィールド及びｃｔｙｐｅ／ｒｅｓｐｏｎｓｅフィールドの値をチェックする第３の情報チェック手順と、
ＡＫＥコマンド抽出用情報として取得したバイト・データからＡＫＥコマンドを抽出するコマンド抽出手順と、
ＡＫＥコマンドを送信するコマンド送信手順と、
ＡＫＥコマンドの受信処理を起動するコマンド受信処理起動手順と、
を実行させることを特徴とするコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２００７−３６３５０（Ｐ２００７−３６３５０Ａ）
【公開日】平成１９年２月８日（２００７．２．８）
【国際特許分類】
【出願番号】特願２００５−２１２６３０（Ｐ２００５−２１２６３０）
【出願日】平成１７年７月２２日（２００５．７．２２）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成１９年２月８日（２００７．２．８）
【国際特許分類】
【出願日】平成１７年７月２２日（２００５．７．２２）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]