(57)【要約】【課題】所定のＩＰルーターのホップ回数（ＴＴＬ）内という制限を順守してコマンド送受信を行ない、コンテンツの不正配信を好適に防止する。【解決手段】３台以上のルーターを経由した不正機器が３を超えるＴＴＬを設定して、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦを送信する。これに対し、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０が３以下のＴＴＬを設定して送信したＡＫＥ  Ｓｔａｔｕｓは不正機器まで届かない。したがって、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、所定期間内にレスポンスを受け取らないので、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦの送信元はＴＴＬの制限の範囲内にはいないと判断できる。【選択図】  図９Ｂ
2014013972.tif 000002
【特許請求の範囲】
【請求項１】
コマンド及びレスポンスを載せたパケットを送受信する通信部と、
受信したパケットのヘッダーを参照せずに、コマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する送信元確認部と、
前記送信元確認部による確認結果に応じて受信したコマンドの処理、又は、コマンドの送信元との以後の通信を制御する制御部と、
を具備する通信装置。
【請求項２】
前記送信元確認部は、一連のコマンドのやり取りにより認証処理を行なうコマンドを受信したときには、そのコマンドの送信元の確認処理を行なわない、
請求項１に記載の通信装置。
【請求項３】
前記送信元確認部は、コマンドの処理が単発で完結し、相互のコマンドのやり取りを伴わない要確認コマンドを受信したときには、そのコマンドの送信元の確認処理を行なう、
請求項１に記載の通信装置。
【請求項４】
前記送信元確認部は、コマンドを受信する前の所定期間以内に当該コマンドの送信元にコマンドを送信しており且つタイムアウト時間前にそのレスポンスを受信したときには、当該コマンドの送信元がＴＴＬの制限の範囲内にいると判断する、
請求項１に記載の通信装置。
【請求項５】
前記送信元確認部は、コマンドを受信してから所定期間以内に当該コマンドの送信元に対し制限の範囲内のＴＴＬを設定した確認用パケットを送信し、タイムアウト時間前にそのレスポンスを受信したときには、当該コマンドの送信元がＴＴＬの制限の範囲内にいると判断する、
請求項１に記載の通信装置。
【請求項６】
前記送信元確認部は、前記確認用パケットとして、コマンドの処理が単発で完結し相互のコマンドのやり取りを伴わないコマンド、又は、ＰＩＮＧを送信する、
請求項５に記載の通信装置。
【請求項７】
前記制御部は、前記コマンドの送信元に対してコンテンツ伝送中に、前記コマンドの送信元がＴＴＬの制限の範囲内でないことが確認されたときには、前記コンテンツ伝送を停止する、
請求項１に記載の通信装置。
【請求項８】
前記制御部は、前記コマンドの送信元がＴＴＬの制限の範囲内であることが確認されたときには、前記コマンドが要求する処理を実行する、
請求項１に記載の通信装置。
【請求項９】
前記制御部は、前記コマンドの送信元がＴＴＬの制限の範囲内であることが確認されたときには、前記コマンドが要求する処理を実行するとともに、前記コマンドの送信元にレスポンスを返す、
請求項１に記載の通信装置。
【請求項１０】
コマンドを載せたパケットを受信するコマンド受信ステップと、
受信したパケットのヘッダーを参照せずに、コマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する送信元確認ステップと、
前記送信元確認ステップにおける確認結果に応じて受信したコマンドの処理、又は、コマンドの送信元との以後の通信を制御する制御ステップと、
を有する通信方法。
【請求項１１】
コマンドを載せたパケットを任意のＴＴＬを設定して送信する第１の機器と、
ＴＴＬの値を１ずつデクリメントして前記パケットを転送する任意の台数（０台を含む）のルーターと、
前記パケットを受信して、そのヘッダーを参照せずに前記第１の機器がＴＴＬの制限の範囲内にいるかどうかを確認し、確認結果に応じて受信したコマンドの処理を行なう第２の機器と、
を具備する通信システム。
【請求項１２】
コマンド及びレスポンスを載せたパケットを送受信する通信部、
受信したパケットのヘッダーを参照せずに、コマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する送信元確認部、
前記送信元確認部による確認結果に応じて受信したコマンドの処理、又は、コマンドの送信元との以後の通信を制御する制御部、
としてコンピューターを機能させるようコンピューター可読形式で記述されたコンピューター・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書で開示する技術は、暗号化コンテンツの復号鍵を所定の相互認証及び鍵交換（ＡＫＥ）アルゴリズムに従って交換して暗号化コンテンツを伝送し、コンテンツの不正配信を防止する通信装置及び通信方法、通信システム、並びにコンピューター・プログラムに係り、特に、所定のＩＰルーターのホップ回数（ＴＴＬ）の制限内でコンテンツの不正配信を防止する通信装置及び通信方法、通信システム、並びにコンピューター・プログラムに関する。
【背景技術】
【０００２】
ディジタル化されたコンテンツはコピーや改竄などの不正な操作が比較的容易である。とりわけ、リモート・アクセスにおいては、個人的又は家庭的なコンテンツの使用を許容しながら、コンテンツ伝送に介在する不正利用の防止、すなわち著作権保護の仕組みが必要である。ディジタル・コンテンツの伝送保護に関する業界標準的な技術として、ＤＴＬＡ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｌｉｃｅｎｓｉｎｇ  Ａｄｍｉｎｉｓｔｒａｔｏｒ）が開発したＤＴＣＰ（Ｄｉｇｉｔａｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｅｎｔ  Ｐｒｏｔｅｃｔｉｏｎ）が挙げられる。
【０００３】
ＤＴＣＰでは、コンテンツ伝送時における機器間の認証プロトコルと、暗号化コンテンツの伝送プロトコルについて取り決められている。その規定は、要約すれば、ＤＴＣＰ準拠機器は取り扱いが容易な圧縮コンテンツを非暗号の状態で機器外に送出しないことと、暗号化コンテンツを復号するために必要となる鍵交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうこと、並びにＡＫＥコマンドにより鍵交換を行なう機器の範囲を制限することなどである。
【０００４】
ＤＴＣＰは、原初的には、ＩＥＥＥ１３９４などを伝送路に用いたホームネットワーク上におけるコンテンツ伝送について規定したものである。最近では、ＤＬＮＡ（Ｄｉｇｉｔａｌ  Ｌｉｖｉｎｇ  Ｎｅｔｗｏｒｋ  Ａｌｌｉａｎｃｅ）に代表されるように、家庭内でもディジタル・コンテンツをＩＰネットワーク経由で流通させようという動きが本格的になっている。そこで、ＤＴＣＰ技術をＩＰネットワークに移植した、ＤＴＣＰ−ＩＰ（ＤＴＣＰ  ｍａｐｐｉｎｇ  ｔｏ  ＩＰ）の開発が進められている。
【０００５】
現在のＤＴＣＰ−ＩＰ（ＤＴＣＰ  Ｖｏｌｕｍｅ  １  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｓｕｐｐｌｅｍｅｎｔ  Ｅ  Ｒｅｖｉｓｉｏｎ  １．３１）は、主にコンテンツの家庭内のみの利用を確保することを意図している。このため、ＡＫＥ手続きを行なう範囲を家庭内に抑えるべく、ＤＴＣＰコマンドの送信にはいくつかの制限が課されている。例えば、ＡＫＥコマンドに対し往復遅延時間（ＲＴＴ：Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）は最大７ミリ秒に制限されている。また、ＩＰルーターのホップ回数の上限が課されている。ＤＴＣＰコマンドの送信側は、ＩＰパケットのヘッダー内のＴＴＬ（ＴＴＬ：Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ）フィールドに３以下の値を設定することと、受信側はＴＴＬが３を超えるＤＴＣＰコマンドを破棄することが課され、３台以上のＩＰルーターを経由して、遠方までＤＴＣＰコマンドが届かないようにしている（例えば、非特許文献１を参照のこと）。
【０００６】
例えば、ＤＴＣＰ−ＩＰ対応機器同士で認証鍵交換処理を開始する際、当該認証鍵交換処理用に最初に送信するＴＣＰパケットのＴＴＬ値をＤＴＣＰ−ＩＰでの許容数に設定し、このＴＣＰパケットに対する応答がなかった場合、ＩＰネットワークの構成上の不具合を警告するメッセージを表示する通信装置について提案がなされている（例えば、特許文献１を参照のこと）。
【０００７】
ＴＴＬの制限について図１０〜図１２を参照しながら説明する。各図は、コンテンツを要求するＤＴＣＰ＿ＳｉｎｋからＤＴＣＰコマンドを送信し、これに対し、コンテンツを供給するＤＴＣＰ＿Ｓｏｕｒｃｅがレスポンスを返信する例を示している。各図とも、ＤＴＣＰ＿ＳｉｎｋとＤＴＣＰ＿Ｓｏｕｒｃｅ間はＩＰネットワークで相互接続され、複数のＩＰルーターが介在することを想定している。ＤＴＣＰ＿Ｓｉｎｋは、ＤＴＣＰコマンドをＩＰパケットに載せて送信する際、ＩＰヘッダー内のＴＴＬフィールドに３を設定する。ＩＰルーターは、ＩＰパケットを転送する際に、ＴＴＬフィールドの値を１ずつデクリメントし、値がゼロになった時点でそのＩＰパケットを破棄するようになっている。
【０００８】
図１０に示す例では、ＤＴＣＰ＿ＳｉｎｋとＤＴＣＰ＿Ｓｏｕｒｃｅ間に２台のＩＰルーターが介在するので、ＤＴＣＰ＿Ｓｉｎｋが送信したＤＴＣＰコマンドは、最終的にＴＴＬが１までデクリメントされたＩＰパケットで、ＤＴＣＰ＿Ｓｏｕｒｃｅに届く。ＤＴＣＰ＿ＳｏｕｒｃｅはレスポンスをＩＰパケットに載せて返信するが、同様にＩＰヘッダー内のＴＴＬフィールドに３を設定し、ＩＰルーターは２台しか介在しないので、ＤＴＣＰ＿Ｓｉｎｋに届く。
【０００９】
一方、図１１に示す例では、３台のＩＰルーターが介在するので、ＤＴＣＰ＿Ｓｉｎｋが送信したＤＴＣＰコマンドは、３台目のＩＰルーターでＴＴＬの値がゼロになって破棄されるので、ＤＴＣＰ＿Ｓｏｕｒｃｅには届かない。よって、ＤＴＣＰ＿Ｓｉｎｋは、ＤＴＣＰ＿Ｓｏｕｒｃｅからのレスポンスを受け取ることはない。また、ＤＴＣＰ＿ＳｏｕｒｃｅからＤＴＣＰコマンドを送信する場合も、ＤＴＣＰ＿Ｓｉｎｋまで届かない。
【００１０】
また、図１２に示す例では、不正な機器が正規のＤＴＣＰ＿Ｓｉｎｋを装って、ＴＴＬに１００という値を設定してＤＴＣＰコマンドを送信している。この場合、３台目のＩＰルーターを経由する時点でもＴＴＬの値はまだゼロにならず、ＤＴＣＰ＿ＳｏｕｒｃｅまでＤＴＣＰコマンドが届く。ＤＴＣＰ＿Ｓｏｕｒｃｅは、受信したＤＴＣＰコマンドのＴＴＬが３を超えているので、破棄する。
【００１１】
ここで、ＩＰパケットにおけるＴＴＬをチェックする処理は、基本的には、ＤＴＣＰアプリケーションが行なう。当業界において周知のように、通信プロトコルはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）やＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）といった複数のプロトコルのスタック構造をなし、これらの最上位層としてアプリケーションが位置付けられる。したがって、ＤＴＣＰアプリケーションは、オペレーティング・システムを経由して、ＩＰプロトコル層に対してＴＴＬフィールドの値を参照する。ちなみに、ＩＰプロトコル層自体は、ルーターを通過する度にＴＴＬフィールド値を１ずつ減算する機能しか実装しておらず、ＴＴＬフィールドの値をチェックできない。
【００１２】
ところが、オペレーティング・システムの中には、ＩＰヘッダー内のＴＴＬフィールドを参照しないものもある。このようなオペレーティング・システムの実行環境下で動作するＤＴＣＰ機器は、ＴＴＬフィールドに制限を超えた値が設定されたＤＴＣＰコマンドを排除することができない。すなわち、ＤＴＣＰ仕様が求める「ＴＴＬが３を超えるＤＴＣＰコマンドの破棄」を実現できず、結果としてＤＴＣＰ対応のアプリケーションを実装することができない。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】特開２００７−６７９０５号公報
【非特許文献】
【００１４】
【非特許文献１】ＤＴＣＰ  Ｖｏｌｕｍｅ  １  Ｓｕｐｐｌｅｍｅｎｔ  Ｅ  Ｍａｐｐｉｎｇ  ＤＴＣＰ  ｔｏ  ＩＰ，Ｖｅｒｓｉｏｎ  １．０（Ｉｎｆｏｒｍａｔｉｏｎａｌ  Ｖｅｒｓｉｏｎ）ｈｔｔｐ：／／ｗｗｗ．ｄｔｃｐ．ｃｏｍ／ｄａｔａ／ｉｎｆｏ＿２００３１１２４＿ｄｔｃｐ＿ＶＩＳＥ＿１ｐ０．ｐｄｆ／
【発明の概要】
【発明が解決しようとする課題】
【００１５】
本明細書で開示する技術の目的は、所定のＩＰルーターのホップ回数（ＴＴＬ）内という制限を順守してコマンド送受信を行ない、コンテンツの不正配信を好適に防止することができる、優れた通信装置及び通信方法、通信システム、並びにコンピューター・プログラムを提供することにある。
【００１６】
本明細書で開示する技術のさらなる目的は、受信パケットのＴＴＬの値を確認できない環境下でも、ＴＴＬの制限を超えた範囲から送信されたコマンドを排除して、安全な通信を行なうことができる、優れた通信装置及び通信方法、通信システム、並びにコンピューター・プログラムを提供することにある。
【課題を解決するための手段】
【００１７】
本願は、上記課題を参酌してなされたものであり、請求項１に記載の技術は、
コマンド及びレスポンスを載せたパケットを送受信する通信部と、
受信したパケットのヘッダーを参照せずに、コマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する送信元確認部と、
前記送信元確認部による確認結果に応じて受信したコマンドの処理、又は、コマンドの送信元との以後の通信を制御する制御部と、
を具備する通信装置である。
【００１８】
本願の請求項２に記載の技術は、請求項１に記載の通信装置の前記送信元確認部は、一連のコマンドのやり取りにより認証処理を行なうコマンドを受信したときには、そのコマンドの送信元の確認処理を行なわないように構成されている。
【００１９】
本願の請求項３に記載の技術は、請求項１に記載の通信装置の前記送信元確認部は、コマンドの処理が単発で完結し、相互のコマンドのやり取りを伴わない要確認コマンドを受信したときには、そのコマンドの送信元の確認処理を行なうように構成されている。
【００２０】
本願の請求項４に記載の技術は、請求項１に記載の通信装置の前記送信元確認部は、コマンドを受信する前の所定期間以内に当該コマンドの送信元にコマンドを送信しており且つタイムアウト時間前にそのレスポンスを受信したときには、当該コマンドの送信元がＴＴＬの制限の範囲内にいると判断するように構成されている。
【００２１】
本願の請求項５に記載の技術は、請求項１に記載の通信装置の前記送信元確認部は、コマンドを受信してから所定期間以内に当該コマンドの送信元に対し制限の範囲内のＴＴＬを設定した確認用パケットを送信し、タイムアウト時間前にそのレスポンスを受信したときには、当該コマンドの送信元がＴＴＬの制限の範囲内にいると判断するように構成されている。
【００２２】
本願の請求項６に記載の技術は、請求項５に記載の通信装置の前記送信元確認部は、前記確認用パケットとして、コマンドの処理が単発で完結し相互のコマンドのやり取りを伴わないコマンド、又は、ＰＩＮＧを送信するように構成されている。
【００２３】
本願の請求項７に記載の技術は、請求項１に記載の通信装置の前記制御部は、前記コマンドの送信元に対してコンテンツ伝送中に、前記コマンドの送信元がＴＴＬの制限の範囲内でないことが確認されたときには、前記コンテンツ伝送を停止するように構成されている。
【００２４】
本願の請求項８に記載の技術は、請求項１に記載の通信装置の前記制御部は、前記コマンドの送信元がＴＴＬの制限の範囲内であることが確認されたときには、前記コマンドが要求する処理を実行するように構成されている。
【００２５】
本願の請求項９に記載の技術は、請求項１に記載の通信装置の前記制御部は、前記コマンドの送信元がＴＴＬの制限の範囲内であることが確認されたときには、前記コマンドが要求する処理を実行するとともに、前記コマンドの送信元にレスポンスを返すように構成されている。
【００２６】
また、本願の請求項１０に記載の技術は、
コマンドを載せたパケットを受信するコマンド受信ステップと、
受信したパケットのヘッダーを参照せずに、コマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する送信元確認ステップと、
前記送信元確認ステップにおける確認結果に応じて受信したコマンドの処理、又は、コマンドの送信元との以後の通信を制御する制御ステップと、
を有する通信方法である。
【００２７】
また、本願の請求項１１に記載の技術は、
コマンドを載せたパケットを任意のＴＴＬを設定して送信する第１の機器と、
ＴＴＬの値を１ずつデクリメントして前記パケットを転送する任意の台数（０台を含む）のルーターと、
前記パケットを受信して、そのヘッダーを参照せずに前記第１の機器がＴＴＬの制限の範囲内にいるかどうかを確認し、確認結果に応じて受信したコマンドの処理を行なう第２の機器と、
を具備する通信システムである。
【００２８】
但し、ここで言う「システム」とは、複数の装置（又は特定の機能を実現する機能モジュール）が論理的に集合した物のことを言い、各装置や機能モジュールが単一の筐体内にあるか否かは特に問わない。
【００２９】
また、本願の請求項１２に記載の技術は、
コマンド及びレスポンスを載せたパケットを送受信する通信部、
受信したパケットのヘッダーを参照せずに、コマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する送信元確認部、
前記送信元確認部による確認結果に応じて受信したコマンドの処理、又は、コマンドの送信元との以後の通信を制御する制御部、
としてコンピューターを機能させるようコンピューター可読形式で記述されたコンピューター・プログラムである。
【００３０】
本願の請求項１２に係るコンピューター・プログラムは、コンピューター上で所定の処理を実現するようにコンピューター可読形式で記述されたコンピューター・プログラムを定義したものである。換言すれば、本願の請求項１２に係るコンピューター・プログラムをコンピューターにインストールすることによって、コンピューター上では協働的作用が発揮され、本願の請求項１に係る通信装置と同様の作用効果を得ることができる。
【発明の効果】
【００３１】
本明細書で開示する技術によれば、所定のＩＰルーターのホップ回数（ＴＴＬ）内という制限を順守してコマンド送受信を行ない、コンテンツの不正配信を好適に防止することができる、優れた通信装置及び通信方法、通信システム、並びにコンピューター・プログラムを提供することができる。
【００３２】
また、本明細書で開示する技術によれば、受信パケットのＴＴＬの値を確認できない環境下でも、ＴＴＬの制限の範囲内の相手から送られたパケットかどうかを別途の手続きにより確認して、安全な通信を行なうことができる、優れた通信装置及び通信方法、通信システム、並びにコンピューター・プログラムを提供することができる。
【００３３】
本明細書で開示する技術のさらに他の目的、特徴や利点は、後述する実施形態や添付する図面に基づくより詳細な説明によって明らかになるであろう。
【図面の簡単な説明】
【００３４】
【図１】図１は、本明細書で開示する技術を適用可能な通信システム１００の構成例を模式的に示した図である。
【図２Ａ】図２Ａは、ＤＴＣＰ＿Ｓｉｎｋ１１０として動作する通信装置のハードウェア構成を模式的に示した図である。
【図２Ｂ】図２Ｂは、ＤＴＣＰ＿Ｓｉｎｋ１１０の機能的構成を模式的に示した図である。
【図３Ａ】図３Ａは、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０として動作する通信装置のハードウェア構成を模式的に示した図である。
【図３Ｂ】図３Ｂは、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０の機能的構成を模式的に示した図である。
【図４Ａ】図４Ａは、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンス（全体）を示した図である。
【図４Ｂ】図４Ｂは、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンス（チャレンジ・レスポンス部分の詳細）を示した図である。
【図４Ｃ】図４Ｃは、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンス（ＲＴＴプロトコル手続きの詳細）を示した図である。
【図５】図５は、ＤＴＣＰ−ＩＰにより暗号化コンテンツ伝送を行なう仕組みを説明するための図である。
【図６】図６は、ＤＴＣＰ機器がＤＴＣＰコマンドを受信した際の処理手順を示したフローチャートである。
【図７】図７は、ＤＴＣＰ機器がＤＴＣＰコマンドを受信した際の処理手順を示したフローチャートである。
【図８】図８は、ＤＴＣＰ機器がＤＴＣＰコマンドを受信した際の処理手順を示したフローチャートである。
【図９Ａ】図９Ａは、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０がＤＴＣＰコマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する通信シーケンス例（経由するＩＰルーターの台数がＴＴＬの制限の範囲内の場合）を示した図である。
【図９Ｂ】図９Ｂは、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０がＤＴＣＰコマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する通信シーケンス例（経由するＩＰルーターの台数がＴＴＬの制限の範囲を超える場合）を示した図である。
【図１０】図１０は、ＤＴＣＰ＿ＳｉｎｋとＤＴＣＰ＿Ｓｏｕｒｃｅ間で、ＩＰルーターを経由してＤＴＣＰコマンド並びにそのレスポンスをやり取りする様子を示した図である。
【図１１】図１１は、ＤＴＣＰ＿ＳｉｎｋとＤＴＣＰ＿Ｓｏｕｒｃｅ間で、ＩＰルーターを経由してＤＴＣＰコマンド並びにそのレスポンスをやり取りする様子を示した図である。
【図１２】図１２は、ＤＴＣＰ＿ＳｉｎｋとＤＴＣＰ＿Ｓｏｕｒｃｅ間で、ＩＰルーターを経由してＤＴＣＰコマンド並びにそのレスポンスをやり取りする様子を示した図である。
【図１３】図１３は、ＩＰパケットの構成を模式的に示した図である。
【発明を実施するための形態】
【００３５】
以下、図面を参照しながら本明細書で開示する技術の実施形態について詳細に説明する。
【００３６】
図１には、本明細書で開示する技術を適用可能な通信システム１００の構成例を模式的に示している。図示の通信システム１００は、コンテンツを利用するＤＴＣＰ＿Ｓｉｎｋ１１０と、コンテンツを提供するＤＴＣＰ＿Ｓｏｕｒｃｅ１３０で構成される。ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０間は、ＤＴＣＰ−ＩＰ技術が適用されたＩＰネットワークで接続されている。
【００３７】
ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０はそれぞれ、ＤＴＣＰコマンド並びにこれに対するレスポンスを、ＩＰパケットに載せて送受信する。図１３には、ＤＴＣＰコマンドの伝送に用いられるＩＰパケットの構成を模式的に示している。但し、本明細書で開示する技術の要旨に直接関連しないフィールドについては、適宜捨象して描いている。ＩＰヘッダー内には、送信元のＩＰアドレスを記載するＳｏｕｒｃｅ  ＩＰ  Ａｄｄｒｅｓｓフィールド、並びに、ＴＴＬの値を記載するＴｉｍｅ  ｔｏ  Ｌｉｖｅフィールドが設けられている。また、ＩＰパケットのデータ部分は、ＴＣＰヘッダー並びにＤＴＣＰコマンド・データを含んでいる。ＤＴＣＰコマンド・データ内には、当該ＤＴＣＰコマンドの種別を示すコマンドＩＤ（ｓｕｂｆｕｎｃｔｉｏｎ）が記載されている。
【００３８】
また、図１中でＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０間を接続するＩＰネットワークの一部又は全部はホームネットワークである。ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０間には、１以上のＩＰルーターが介在することもある。図１では、図面の簡素化のため、１台のＩＰルーター１２０のみを描いている。
【００３９】
ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０間での暗号化コンテンツの伝送には、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）といった、ＩＰネットワーク上で実装されたコンテンツ伝送用プロトコルが使用される。例えば、ＨＴＴＰの手続きに従ってコンテンツを伝送する場合、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０がＨＴＴＰサーバーとなり、ＤＴＣＰ＿Ｓｉｎｋ１１０がＨＴＴＰクライアントとなって、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションが作成され、暗号化コンテンツのダウンロード伝送が行なわれる（但し、アップロード伝送を行なうときには、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０がＨＴＴＰクライアントとなりＤＴＣＰ＿Ｓｉｎｋ１１０がＨＴＴＰサーバーとなる）。
【００４０】
ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、正規なＤＴＣＰ機器である場合には、ＤＴＣＰコマンド又はそのレスポンスを載せたＩＰパケットを送信するときには、ＩＰヘッダーのＴＴＬフィールドに３を設定し、また、受信したＩＰパケットに３を超えるＴＴＬが設定されているときには破棄するようになっている。
【００４１】
図２Ａには、ＤＴＣＰ＿Ｓｉｎｋ１１０として動作する通信装置のハードウェア構成を模式的に示している。この通信装置は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１１と、通信部１１２と、記憶部１１３と、コンテンツ再生出力部１１４を備えている。
【００４２】
ＣＰＵ１１１は、ＤＴＣＰアプリケーションを実行することで、この通信装置をＤＴＣＰ＿Ｓｉｎｋとして動作させる。ＣＰＵ１１１で処理する通信プロトコルはＴＣＰやＩＰといった複数のプロトコルのスタック構造をなし、ＤＴＣＰアプリケーションは、オペレーティング・システムが提供する実行環境下で最上位層として動作する。
【００４３】
通信部１１２は、ＣＰＵ１１１の制御下で、ＴＣＰ／ＩＰなどの所定の通信プロトコルに従って、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０との通信処理を行なう。記憶部１１３は、ＤＴＣＰ＿Ｓｏｕｒｃｅから取得したコンテンツや、インストールしたプログラム、その他のファイルを蓄積するために利用される。コンテンツ再生出力部１１４は、通信部１１２を介して受信するコンテンツ・ストリーム、又は記憶部１１３から読み出したコンテンツを再生出力する。
【００４４】
また、図２Ｂには、ＤＴＣＰ＿Ｓｉｎｋ１１０の機能的構成を模式的に示している。ＤＴＣＰアプリケーションは、ＴＣＰ／ＩＰ層及びオペレーティング・システムの上位層で動作する。ＤＴＣＰアプリケーションは、認証部とコンテンツ伝送部を含んでいる。認証部は、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０とＡＫＥ手続により認証及び鍵交換を行なう。また、コンテンツ伝送部は、認証部から渡された鍵情報に基づいて暗号鍵を生成し、コンテンツの暗号化伝送を行なう。
【００４５】
図３Ａには、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０として動作する通信装置のハードウェア構成を模式的に示している。この通信装置は、ＣＰＵ１３１と、通信部１３２と、記憶部１３３を備えている。
ＣＰＵ１３１は、ＤＴＣＰアプリケーションを実行することで、この通信装置をＤＴＣＰ＿Ｓｏｕｒｃｅとして動作させる。ＣＰＵ１３１で処理する通信プロトコルはＴＣＰやＩＰといった複数のプロトコルのスタック構造をなし、ＤＴＣＰアプリケーションは、オペレーティング・システムが提供する実行環境下で最上位層として動作する。
【００４６】
通信部１３２は、ＣＰＵ１３１の制御下で、ＴＣＰ／ＩＰなどの所定の通信プロトコルに従って、ＤＴＣＰ＿Ｓｉｎｋ１１０との通信処理を行なう。記憶部１２３は、ＤＴＣＰ＿Ｓｉｎｋに提供するコンテンツや、インストールしたプログラム、その他のファイルを蓄積するために利用される。
【００４７】
ＤＴＣＰ仕様では、ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０はコンテンツを非暗号の状態で機器外に送出しないことと、ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０間でコンテンツの暗号化及び復号に使用する鍵の交換を所定の相互認証及び鍵交換（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  ａｎｄ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ：ＡＫＥ）アルゴリズムに従って行なうことが取り決められている。
【００４８】
また、図３Ｂには、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０の機能的構成を模式的に示している。ＤＴＣＰアプリケーションは、ＴＣＰ／ＩＰ層及びオペレーティング・システムの上位層で動作する。ＤＴＣＰアプリケーションは、認証部とコンテンツ伝送部を含んでいる。認証部は、ＤＴＣＰ＿Ｓｉｎｋ１１０とＡＫＥ手続により認証及び鍵交換を行なう。また、コンテンツ伝送部は、認証部から渡された鍵情報に基づいて暗号鍵を生成し、コンテンツの暗号化伝送を行なう。
【００４９】
図４Ａには、ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０間で行なわれる、ＡＫＥコマンドを用いた相互認証及び鍵交換の動作シーケンス（ＡＫＥ手続き）全体を示している。また、図４Ｂには、ＡＫＥ手続きのチャレンジ・レスポンス部分（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ  ｐｏｒｔｉｏｎ  ｏｆ  ＡＫＥ）の詳細を示し、図４Ｃには、ＲＴＴプロトコル手続き（Ｐｒｏｔｅｃｔｅｄ  ＲＴＴ  Ｐｒｏｔｏｃｏｌ）の詳細を示している。
【００５０】
ＡＫＥ手続きのチャレンジ・レスポンス部分では、図４Ｂに示すように、まず、ＤＴＣＰ＿Ｓｉｎｋ１１０からＣＨＡＬＬＥＮＧＥサブファンクション・コマンドが送信される。このＣＨＡＬＬＥＮＧＥサブファンクションには、Ｒｘ乱数とＲｘ証明書が含まれている。これに対し、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０からはレスポンスが返される。続いて、今度はＤＴＣＰ＿Ｓｏｕｒｃｅ１３０からはＣＨＡＬＬＥＮＧＥサブファンクション・コマンドが送信される。このＣＨＡＬＬＥＮＧＥサブファンクションには、Ｔｘ乱数及びＴｘ証明書が含まれている。これに対し、ＤＴＣＰ＿Ｓｉｎｋ１１０からはレスポンスが返される。続いて、ＤＴＣＰ＿Ｓｉｎｋ１１０から、Ｔｘ乱数、Ｒｘメッセージ、Ｒｘ署名を含んだレスポンス・サブファンクション・コマンドが送信され、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０からはレスポンスが返される。また、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０から、Ｒｘ乱数、Ｔｘメッセージ、Ｔｘ署名を含んだレスポンス・サブファンクション・コマンドが送信され、ＤＴＣＰ＿Ｓｉｎｋ１１０からはレスポンスが返される。チャレンジ・レスポンス部分で送信される各コマンドには、送信元の機器固有の識別情報であるＤｅｖｉｃｅ  ＩＤが含まれている。
【００５１】
基本的には、上記のチャレンジ・レスポンス部分を含むすべてのＤＴＣＰコマンドに対して、ＴＴＬ（ＩＰルーターのホップ回数）の制限が課されている。すなわち、正規のＤＴＣＰ機器は、ＤＴＣＰコマンド送信時にはＩＰパケットのヘッダー内のＴＴＬに３以下の値を設定し、ＴＴＬが３を超えるＩＰパケットを受信したときにはそのＤＴＣＰコマンドを破棄する。
【００５２】
ＲＴＴプロトコル手続きでは、図４Ｃに示すように、まず、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０からコマンドＲＴＴ＿ＲＥＡＤＹ．ＣＭＤが送信され、ＤＴＣＰ＿Ｓｉｎｋ１１０からレスポンスＲＴＴ＿ＲＥＡＤＹ．ＲＳＰが返信されるとともに、ＤＴＣＰ＿Ｓｉｎｋ１１０からコマンドＲＴＴ＿ＲＥＡＤＹ．ＣＭＤが送信され、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０からレスポンスＲＴＴ＿ＲＥＡＤＹ．ＲＳＰが返信されることによって、ＲＴＴプロトコル手続き（Ｐｒｏｔｅｃｔｅｄ  ＲＴＴ  Ｐｒｏｔｏｃｏｌ）が開始する。その際、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０側では２種類のメッセージ認証コード（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅ）ＭＡＣ１Ａ、ＭＡＣ２Ａを計算し、ＤＴＣＰ＿Ｓｉｎｋ１１０側でも同様の計算方法により２種類のメッセージ認証コードＭＡＣ１Ｂ、ＭＡＣ２Ｂを計算しておく。そして、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、コマンドＲＴＴ＿ＳＥＴＵＰ（Ｎ）．ＣＭＤにより変数Ｎを送信し、これに対し、ＤＴＣＰ＿Ｓｉｎｋ１１０はレスポンスとＡＣＣＥＰＴＥＤ（Ｎ）．ＲＳＰを返信する。ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０、ＤＴＣＰ＿Ｓｉｎｋ１１０ともに、ここで伝送される変数Ｎに対するメッセージ認証コードを用意する。
【００５３】
次いで、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、ＲＴＴ測定用のコマンドであるＲＴＴ＿ＴＥＳＴ（ＭＡＣ１Ａ）．ＣＭＤを送信し、ＤＴＣＰ＿Ｓｉｎｋ１１０は、これに対するレスポンスであるＡＣＣＥＰＴＥＤ（ＭＡＣ２Ｂ）．ＲＳＰを返信する。そして、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、ＲＴＴ測定用のコマンドを送信してからレスポンスを受信するまでの往復遅延時間ＲＴＴが規定の閾値（７ミリ秒）以下であるか否か、すなわちＲＴＴチェックを行なう。
【００５４】
ＲＴＴが閾値を超えるときには、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、試行回数が１０２３回を超えていないかどうかをさらにチェックする。試行回数が１０２３回を超えていないときには、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、Ｎを１だけ増分してから、新たなＮに対応するメッセージ認証コードを用意してＲＴＴ＿ＳＥＴＵＰ（Ｎ）コマンドを送信し、ＤＴＣＰ＿Ｓｉｎｋ１１０も新たなＮに対応するメッセージ認証コードを用意してＡＣＣＥＰＴＥＤ（Ｎ）レスポンスを送信し、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０とＤＴＣＰ＿Ｓｉｎｋ１１０間でＲＴＴ測定用コマンドの送信とレスポンスの返信を繰り返す。また、試行回数が１０２３回を超えたときには、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、この認証手順を中止（Ａｂｏｒｔ）する。
【００５５】
一方、ＲＴＴが閾値以下であるときには、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、ＡＣＣＥＰＴＥＤ（ＭＡＣ２Ｂ）．ＲＳＰで受け取ったメッセージ認証コードＭＡＣ２Ｂが、自分で生成したＭＡＣ２Ａと一致するかどうかをさらにチェックする。一致しなければ、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、この認証手順を中止（Ａｂｏｒｔ）する。
【００５６】
互いのメッセージ認証コードＭＡＣ２ＡとＭＡＣ２Ｂが一致したときには、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、ＲＴＴ検証コマンドＲＴＴ＿ＶＥＲＩＦＹ．ＣＭＤを送信する。ＤＴＣＰ＿Ｓｉｎｋ１１０は、このコマンドに応答して、ＲＴＴ＿ＴＥＳＴ（ＭＡＣ１Ａ）．ＣＭＤで受け取ったメッセージ認証コードＭＡＣ１Ａが、自分で生成したＭＡＣ１Ｂと一致するかどうかをチェックする。一致しなければ、ＤＴＣＰ＿Ｓｉｎｋ１１０は、この認証手順を中止（Ａｂｏｒｔ）し、一致すれば、ＡＣＣＥＰＴＥＤ（ＯＫＭＳＧ）．ＲＳＰを返信する。
【００５７】
ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、ＤＴＣＰ＿Ｓｉｎｋ１１０からＡＣＣＥＰＴＥＤ（ＯＫＭＳＧ）．ＲＳＰを受け取ると、これに含まれているメッセージＯＫＭＳＧを検証する。メッセージＯＫＭＳＧの検証に成功すれば、Ｓｏｕｒｃｅは、ＳｉｎｋをＲＴＴレジストリーに追加するとともに、コンテンツ伝送カウンターを４０時間に設定する。また、メッセージＯＫＭＳＧの検証に失敗したときには、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、この認証手順を中止（Ａｂｏｒｔ）する。
【００５８】
その後、図４Ａに示すように、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０からＥＸＣＨＡＮＧＥ＿ＫＥＹサブファンクション・コマンドが送信され、これに対し、ＤＴＣＰ＿Ｓｉｎｋ１１０からレスポンスが返される。
【００５９】
また、図５には、ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０間でＤＴＣＰ−ＩＰにより暗号化コンテンツ伝送を行なう仕組みを図解している。
【００６０】
ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、まず１つのＴＣＰ／ＩＰコネクションを確立して、上述したＡＫＥ手続きを行なう。そして、ＡＫＥ手続きが成功すると、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、コンテンツ鍵Ｋcの種となる交換鍵Ｋxを生成し、これを認証鍵Ｋauthで暗号化してＤＴＣＰ＿Ｓｉｎｋ１１０に送る。
【００６１】
そして、ＤＴＣＰ＿Ｓｉｎｋ１１０とＤＴＣＰ＿Ｓｏｕｒｃｅ１３０間でＡＫＥによる認証及び鍵交換手続きが済んだ後、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）などのプロトコルを利用してコンテンツ伝送が開始される。図示の例では、ＨＴＴＰの手続きに従ってコンテンツ伝送が行なわれる。その際、ＡＫＥ手続きのためのＴＣＰ／ＩＰコネクションとは別に、ＨＴＴＰのためのＴＣＰ／ＩＰコネクションが作成される。
【００６２】
ＨＴＴＰプロトコルに従ってコンテンツ伝送を行なうには、ＤＴＣＰ＿Ｓｉｎｋ１１０がＤＴＣＰ＿Ｓｏｕｒｃｅ１３０にコンテンツを要求するダウンロード形式と、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０側からＤＴＣＰ＿Ｓｉｎｋ１１０にコンテンツをプッシュするアップロード形式の２通りが挙げられる。前者の場合、ＨＴＴＰクライアントとしてのＤＴＣＰ＿Ｓｉｎｋ１１０は、例えばＨＴＴＰ  ＧＥＴメソッドを用いたＨＴＴＰリクエストにより、ＨＴＴＰサーバーとしてのＤＴＣＰ＿Ｓｏｕｒｃｅ１３０にコンテンツを要求し、これに対し、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０からは要求通りのコンテンツがＨＴＴＰレスポンスとして伝送される。また後者の場合、ＨＴＴＰクライアントとしてのＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、例えばＨＴＴＰ  ＰＯＳＴメソッドを用いたＨＴＴＰリクエストにより、ＨＴＴＰサーバーとしてのＤＴＣＰ＿Ｓｉｎｋ１１０との伝送を開始する。
【００６３】
ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０から伝送されるデータは、ＳｏｕｒｃｅがＡＫＥ認証をした後に共有した鍵を用いてコンテンツを暗号化したデータとなっている。具体的には、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、乱数を用いてノンスＮcを生成して、交換鍵ＫxとノンスＮcと暗号モードに応じたコンテンツ鍵Ｋcを生成する。そして、ＤＴＣＰ＿Ｓｉｎｋ１１０から要求されているコンテンツを、コンテンツ鍵Ｋcを用いて暗号化し、暗号化コンテンツからなるペイロードとノンスＮcと暗号モードの情報を含んだヘッダーからなるパケットをＴＣＰストリーム上に乗せて送信する。
【００６４】
ＤＴＣＰ＿Ｓｉｎｋ１１０側では、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０からの各ＩＰパケットを受信すると、これをＴＣＰストリームに組み立てる。そして、ＤＴＣＰ＿Ｓｉｎｋ１１０は、このストリームから取り出したノンスＮcと交換鍵Ｋxを用いてコンテンツ鍵Ｋcを算出し、コンテンツ鍵Ｋcを用いて暗号化コンテンツを復号することができる。このようにしてＨＴＴＰプロトコルを利用したコンテンツ伝送が終了すると、例えばＤＴＣＰ＿Ｓｉｎｋ１１０側から、コンテンツ伝送に使用したＴＣＰコネクションを適宜切断する。
【００６５】
なお、ＤＴＣＰ−ＩＰでは、連続不使用時間が所定の期間（例えば２時間）を超える前に交換鍵Ｋxを破棄することが規定されている。同じ暗号鍵を使用し続けると、鍵が解読される危険は高くなるためである。すなわち、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、１２８ＭＢのコンテンツ毎にノンスＮcすなわちコンテンツ鍵Ｋcを更新する。
【００６６】
一方、ＤＴＣＰ＿Ｓｉｎｋ１１０は、最新の交換鍵Ｋxを入手できなければ、暗号化コンテンツを利用不能となる。そこで、ＤＴＣＰ＿Ｓｉｎｋ１１０は、コンテンツ伝送用のＴＣＰコネクションとは別に、コンテンツ鍵の確認用のＴＣＰコネクションをさらに確立し、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０に対しコンテンツ鍵確認のための手続きを行なう。例えば、ＤＴＣＰ−ＩＰ  Ｖｏｌｕｍｅ  １  Ｓｕｐｐｌｅｍｅｎｔ  ＳｅｃｔｉｏｎＶ１ＳＥ．８．６には、Ｃｏｎｔｅｎｔ  Ｋｅｙ  Ｃｏｎｆｉｒｍａｔｉｏｎについて規定している。同仕様によれば、ＤＴＣＰ＿Ｓｉｎｋ１１０は、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦサブファンクションを用いて、現在のノンスＮcに関連付けられたコンテンツ鍵の確認を行なう。
【００６７】
続いて、ＤＴＣＰ−ＩＰ仕様で決められているＴＴＬの制限の遵守について検討する。
【００６８】
正規のＤＴＣＰ機器には、ＤＴＣＰコマンド又はそのレスポンスを載せたＩＰパケットを送信するときには、ＩＰヘッダーのＴＴＬフィールドに３を設定し、また、受信したＩＰパケットに３を超えるＴＴＬが設定されているときには破棄することが課されている。その目的は、３台以上のルーターを経由してＤＴＣＰコマンドがやり取りされるのを防止することである。
【００６９】
図１２に示したように、ＴＴＬフィールドに３を超える値が設定されたＤＴＣＰコマンドを受信したときには、これを破棄しなければならない。この処理はＤＴＣＰアプリケーションが行なう。ところが、オペレーティング・システムの中にはＩＰヘッダー内のＴＴＬフィールドを参照しないものもあり、ＤＴＣＰ仕様が求める「ＴＴＬが３を超えるＤＴＣＰコマンドの破棄」を実現できないことが懸念される。結果として、ＤＴＣＰアプリケーションを実装できなくなってしまう。
【００７０】
互いのＤＴＣＰコマンドが正常に相手に届いて処理が完了する処理の場合、正常なＤＴＣＰ機器は、相手から受信したＩＰパケットのＴＴＬフィールドを参照できなくても、自らはＴＴＬフィールドに３以下の値を設定してＤＴＣＰコマンドを送信することにより、３台以上のルーターを経由してＤＴＣＰコマンドがやり取りされるのを防止することができる。
【００７１】
例えば、図４に示した通信シーケンスでは、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０が、ＤＴＣＰ＿Ｓｉｎｋ１１０から受信したＣＨＡＬＬＥＮＧＥサブファンクション・コマンドのＴＴＬフィールドの値を確認できなくても、自らＣＨＡＬＬＥＮＧＥサブファンクション・コマンドを送信する際に、そのＩＰパケットのヘッダー内でＴＴＬを３以下に設定すると、３台以上のルーターを経由した場所にいるＤＴＣＰ＿Ｓｉｎｋ１１０には届かず、以後のＤＴＣＰコマンドのやり取りを防止することができる。
【００７２】
なお、ＣＨＡＬＬＥＮＧＥサブファンクション・コマンド以外にも、ＲＥＳＰＯＮＳＥ、ＲＥＳＰＯＮＳＥ２、ＥＸＣＨＡＮＧＥ＿ＫＥＹ、ＳＲＭ、ＲＴＴ＿ＲＥＡＤＹ、ＲＴＴ＿ＳＥＴＵＰ、ＲＴＴ＿ＴＥＳＴ、ＲＴＴ＿ＶＥＲＩＦＹ、ＭＶ＿ＩＮＩＴＩＡＴＥ、ＣＡＰＡＢＩＬＩＴＹ＿ＥＸＣＨＡＮＧＥ、ＭＶ＿ＥＸＣＨＡＮＧＥ＿ＫＥＹ、ＲＡ＿ＲＥＧＩＳＴＥＲなどのコマンドも、互いのＤＴＣＰコマンドが正常に相手に届いて処理が完了する処理（一連のコマンドのやり取りにより認証処理を行なう、単発でないコマンド処理）となる（但し、各コマンドの意味や役割についての詳細な説明は省略する）。したがって、正常なＤＴＣＰ機器は、相手から受信したＩＰパケットのＴＴＬフィールドを参照できなくても、自らはＴＴＬフィールドに３以下の値を設定してＤＴＣＰコマンドを送信することにより、同様に３台以上のルーターを経由してＤＴＣＰコマンドがやり取りされるのを防止することができる。
【００７３】
これに対し、１つのＤＴＣＰコマンドで処理が完了する場合には、受信したＩＰパケットのＴＴＬフィールドの値を参照できないＤＴＣＰ機器は、自らはＴＴＬを３以下に設定するというだけでは、３台以上のルーターを経由した相手とのＤＴＣＰコマンドのやり取りを防止することはできない。
【００７４】
例えば、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０側でのノンスＮcの更新に伴い、ＤＴＣＰ＿Ｓｉｎｋ１１０がコンテンツ鍵の確認のためにＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦサブファンクション・コマンドを送信することは既に述べた。ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦサブファンクション・コマンドを受け取ると処理が完結し、以後のＤＴＣＰコマンドのやり取りがないので、ＴＴＬフィールドを参照できなければ、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦサブファンクション・コマンドの送信元が３台以上のルーターを経由した場所にいるかどうかを判別できない。
【００７５】
なお、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦサブファンクション・コマンドの他にも、ＣＯＮＴＥＮＴ＿ＫＥＹ＿ＲＥＱ、ＣＡＰＡＢＩＬＩＴＹ＿ＲＥＱなどのコマンドも、１つのＤＴＣＰコマンドで処理が完了し（すなわち、単発のコマンド処理となり）、相互にＤＴＣＰコマンドを送信することはない（但し、各コマンドの意味や役割についての詳細な説明は省略する）。したがって、受信したＩＰパケットのＴＴＬフィールドの値を参照できないＤＴＣＰ機器は、同様に３台以上のルーターを経由した相手とのＤＴＣＰコマンドのやり取りを防止することはできない。
【００７６】
そこで、本実施形態では、正規のＤＴＣＰ機器は、受信した１つのＤＴＣＰコマンドで処理が完了する場合には、ＴＴＬの制限の範囲内の相手から送られたパケットかどうかを別途の手続きによって確認することにより、安全な通信を行なうようにしている。
【００７７】
ここで言う別途の手続きは、具体的には、ＤＴＣＰコマンドを受信したＤＴＣＰ機器が自ら、ＴＴＬフィールドに３を設定してＤＴＣＰコマンドを送信して、相手からのレスポンスに基づいて、相手がＴＴＬの制限の範囲内にいるかどうかを確認する処理である。
【００７８】
以下では、説明の便宜上、送信元がＴＴＬの制限の範囲内かどうかを別途確認する必要がある受信パケットを「要確認パケット」、送信元がＴＴＬの制限の範囲内かどうかを別途確認するために送信するパケットを「確認用パケット」と呼ぶことにする。
【００７９】
とりわけ、単発なコマンド処理となるＤＴＣＰコマンドを載せたパケットが要確認パケットとなる。単発なコマンド処理となるＤＴＣＰコマンドの具体例として、Ｓｉｎｋから送信されるＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦ、ＣＯＮＴＥＮＴ＿ＫＥＹ＿ＲＥＱ、ＣＡＰＡＢＩＬＩＴＹ＿ＲＥＱ、さらには、Ｓｉｎｋ及びＳｏｕｒｃｅの双方から送信されるＡＫＥ  Ｓｔａｔｕｓ、ＡＫＥ＿ＣＡＮＣＥＬ、ＭＶ＿ＣＡＮＣＥＬを挙げることができる（但し、各コマンドの意味や役割についての詳細な説明は省略する）。
【００８０】
なお、上記に挙げた、単発でない、一連のコマンドのやり取りにより認証処理を行なうコマンド処理となるＤＴＣＰコマンドを載せたパケットも、勿論、要確認パケットとして扱うことができる。但し、ＳｉｎｋとＳｏｕｒｃｅ間で互いにコマンドを送信する過程で、相手がＴＴＬの制限の範囲内にいるかどうかを確認できてしまうので、敢えて確認用コマンドを追加して送信するまでもない。
【００８１】
また、上述した単発なコマンド処理となるＤＴＣＰコマンドを、ＩＰヘッダー内で規定のＴＴＬの値を設定することで、確認用パケットとして用いることができる。但し、Ｓｏｕｒｃｅ又はＳｉｎｋのいずれが確認のための別途手続を行なうかで、確認用パケットに使用できるＤＴＣＰコマンドが変わる（Ｓｉｎｋのみから送信されるＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦ、ＣＯＮＴＥＮＴ＿ＫＥＹ＿ＲＥＱ、ＣＡＰＡＢＩＬＩＴＹ＿ＲＥＱは、Ｓｏｕｏｒｃｅの確認用パケットに使用できない）。あるいは、ＤＴＣＰコマンドではなく、ＩＰネットワークで到達性の確認用として周知のＰＩＮＧを確認用パケットとして利用することもできる。
【００８２】
図９Ａ及び図９Ｂには、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦサブファンクション・コマンドを受信したＤＴＣＰ＿Ｓｏｕｒｃｅ１３０がＡＫＥ  Ｓｔａｔｕｓコマンドを確認用パケットに用いて、ＤＴＣＰコマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する通信シーケンス例を示している。ＡＫＥ  Ｓｔａｔｕｓコマンドは、本来、相手のケイパビリティ―などを確認する目的で使用されるＤＴＣＰコマンドである。
【００８３】
ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、ＴＴＬフィールドの値を３に設定して、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦサブファンクション・コマンドの送信元にＡＫＥ  Ｓｔａｔｕｓコマンドを送信する。図９Ａに示す例では、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦサブファンクション・コマンドの送信元は、１台のルーターを経由したＤＴＣＰ＿Ｓｉｎｋ１１０であり、ＡＫＥ  Ｓｔａｔｕｓコマンドが届く。したがって、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、ＤＴＣＰ＿Ｓｉｎｋ１１０からのレスポンスを受信することにより、ＤＴＣＰ＿Ｓｉｎｋ１１０がＴＴＬの制限の範囲内にいることを確認することができる。
【００８４】
一方、図９Ｂに示す例では、３台以上のルーターを経由した不正機器が、３を超える値をＴＴＬフィールドに設定して、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦサブファンクション・コマンドを送信している。この場合、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０がＴＴＬフィールドの値を３に設定して送信したＡＫＥ  Ｓｔａｔｕｓコマンドは、途中のＩＰルーターでＴＴＬの値が消滅してしまい、不正機器まで届かない。したがって、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、所定期間内にＡＫＥ  Ｓｔａｔｕｓコマンドに対するレスポンスを受け取ることができないので、ＣＯＮＴ＿ＫＥＹ＿ＣＯＮＦサブファンクション・コマンドの送信元はＴＴＬの制限の範囲内にはいないと判断することができる。
【００８５】
ＤＴＣＰ機器は、要確認パケットを受信した時点から前後の所定時間Ｔ以内に、その送信元がＴＴＬの制限の範囲内かどうかを確認する必要がある。ここで言う所定時間Ｔとは、ＤＴＣＰ機器がパケットを送信してから、ＴＴＬの制限の範囲内の相手からのレスポンスの処理に必要な最小限の値を基本とする。所定時間Ｔ以内に制限するのは、時間Ｔが経過すると、送信元がＴＴＬの制限の範囲内から範囲外の領域に移動する可能性があるからである。
【００８６】
ＤＴＣＰ機器は、要確認パケットを受信した時点から遡って所定時間Ｔ以内に、同じ送信元がＴＴＬの制限の範囲以内にいることを確認できているときには、要確認パケットを受信した後に確認用パケットを送信する必要はない。例えば、同じ送信元に対し、所定時間Ｔ以内に、ＴＴＬフィールドに３以下の値を設定したＤＴＣＰコマンドを送信し、これに対するレスポンスを受信できているときには、要確認パケットの送信元がＴＴＬの制限の範囲以内にいることを事前に確認できている。
【００８７】
また、ＤＴＣＰ機器は、上記のように事前に確認できていない相手から要確認パケットを受信したときには、別途の手続きとして、要確認パケットを受信した時点から所定時間Ｔ以内に確認用パケットを送信する。そして、コマンドのタイムアウト時間前にレスポンスを受信できたときには、要確認パケットの送信元がＴＴＬの制限の範囲以内にいると確認することができる。
【００８８】
ＤＴＣＰ機器は、受信した要確認パケットに含まれるＤＴＣＰコマンドを処理する前に、送信元がＴＴＬの制限の範囲以内にいると確認するべきである。但し、ＤＴＣＰコマンドを一旦受け付けて、送信元がＴＴＬの制限の範囲内にいることが分かった時点で止めればよい処理については、ＤＴＣＰコマンドの処理とは別途に送信元の確認を行なうようにしてもよい。
【００８９】
ＤＴＣＰ技術は、コンテンツの伝送が主目的である。例えばＤＴＣＰ＿Ｓｏｕｒｃｅ１３０は、ＤＴＣＰコマンドを受信した直後に、送信元がＴＴＬの制限の範囲以内にいるかどうかを確認する。そして、送信元がＴＴＬの制限の範囲を超えていたら、ＤＴＣＰ＿Ｓｏｕｒｃｅ１３０はコンテンツの伝送を止めることで、所定台数（３台）以上のＩＰルーターを超えるコンテンツ伝送を制限することができる。
【００９０】
また、ＤＴＣＰ機器は、受信した要確認パケットに含まれるＤＴＣＰコマンドが何らかの処理を要求するものである場合には、別途の手続きにより送信元がＴＴＬの制限の範囲以内にいることを確認した後に、要求された処理を行なうようにしてもよい。
【００９１】
また、ＤＴＣＰ機器は、受信した要確認パケットに含まれるＤＴＣＰコマンドに対するレスポンスを返す前に、別途の手続きにより送信元がＴＴＬの制限の範囲以内にいることを確認し、その後にレスポンスを返すようにしてもよい。
【００９２】
図６には、ＤＴＣＰ＿Ｓｉｎｋ１１０又はＤＴＣＰ＿Ｓｏｕｒｃｅ１３０などのＤＴＣＰ機器がＤＴＣＰコマンドを受信した際の処理手順をフローチャートの形式で示している。図示の処理手順は、基本的には、ＤＴＣＰアプリケーションが実行するものであり、受信したＩＰパケットのヘッダー内のＴＴＬフィールドを参照できないため、送信元がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きを実施する。
【００９３】
ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が要求する処理を実行する（ステップＳ６０１）。また、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）に対するレスポンスを返信するとともに（ステップＳ６０２）、このＤＴＣＰコマンド（Ｘ）の送信元をＤ１として、そのＩＰアドレスとともに記憶する（ステップＳ６０３）。
【００９４】
そして、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が一連のコマンドのやり取りにより認証処理を行なう、単発でないコマンド処理となるものかどうかをチェックする（ステップＳ６０４）。
【００９５】
ここで、受信したＤＴＣＰコマンド（Ｘ）が単発でないコマンド処理となるものである場合には（ステップＳ６０４のＹｅｓ）、一連のコマンドのやり取りを通じた認証処理により、ＴＴＬの制限の範囲内にいる相手を確認することができる。すなわち、送信元Ｄ１がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きは不要なので、ＤＴＣＰアプリケーションは、本処理ルーチンを終了する。
【００９６】
次いで、ＤＴＣＰアプリケーションは、送信元Ｄ１との間でコンテンツを伝送中であるかどうかをチェックする（ステップＳ６０５）。ここで、送信元Ｄ１との間でコンテンツを伝送中でない場合には（ステップＳ６０５のＮｏ）、送信元Ｄ１がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きは不要なので、ＤＴＣＰアプリケーションは、本処理ルーチンを終了する。
【００９７】
次いで、ＤＴＣＰアプリケーションは、ＤＴＣＰコマンド（Ｘ）の受信より前の所定期間Ｔ以内で、送信元Ｄ１に対して制限以内のＴＴＬを設定したＤＴＣＰコマンド（Ｙ１）を送信したかどうかをチェックする（ステップＳ６０６）。ここで、所定期間Ｔ以内で送信元Ｄ１にＴＴＬが３以下のＤＴＣＰコマンド（Ｙ１）を送信していた場合には（ステップＳ６０６のＹｅｓ）、このＤＴＣＰコマンド（Ｙ１）に対応するレスポンスをタイムアウト時間内に送信元Ｄ１から受信したかどうかをさらにチェックする（ステップＳ６０７）。ここで、ＤＴＣＰコマンド（Ｙ１）のレスポンスの送信元がＤ１であるかどうかは、Ｓｏｕｒｃｅ  ＩＰアドレスの一致によって確認することができる。また、レスポンスがＤＴＣＰコマンド（Ｙ１）に対応するかどうかは、ＤＴＣＰコマンド・データ内に記載されたコマンドＩＤ（ｓｕｂｆｕｎｃｔｉｏｎ）の値が一致するかどうかで確認することができる。
【００９８】
ＤＴＣＰコマンド（Ｙ１）に対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信した場合には（ステップＳ６０７のＹｅｓ）、送信元Ｄ１がＴＴＬの制限の範囲内にいることが分かる。したがって、送信元Ｄ１がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きは不要なので、ＤＴＣＰアプリケーションは、本処理ルーチンを終了する。
【００９９】
一方、送信元Ｄ１との間でコンテンツを伝送中で（ステップＳ６０５のＹｅｓ）、所定期間Ｔ以内で送信元Ｄ１にＴＴＬが３以下のＤＴＣＰコマンド（Ｙ１）を送信していない場合（ステップＳ６０６のＮｏ）、並びに、ＤＴＣＰコマンド（Ｙ１）に対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信できなかった場合には（ステップＳ６０７のＮｏ）には、受信パケット（Ｘ）は要確認パケットであることが分かる。この場合、送信元Ｄ１がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きが必要になる。
【０１００】
そこで、ＤＴＣＰアプリケーションは、ＤＴＣＰコマンド（Ｘ）を受信してから所定期間Ｔ以内に、確認用パケットを送信元Ｄ１に送信する（ステップＳ６０８）。確認用パケットは、単発のコマンド処理となるＤＴＣＰコマンド（Ｙ２）、又は、ＰＩＮＧである。
【０１０１】
そして、ＤＴＣＰアプリケーションは、確認用パケット、すなわちＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧに対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信したかどうかをチェックする（ステップＳ６０９）。ここで、ＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧのレスポンスの送信元がＤ１であるかどうかは、Ｓｏｕｒｃｅ  ＩＰアドレスの一致によって確認することができる。
【０１０２】
ＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧに対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信した場合には（ステップＳ６０９のＹｅｓ）、送信元Ｄ１がＴＴＬの制限の範囲内にいることが分かる。この場合、ＤＴＣＰアプリケーションは、本処理ルーチンを終了し、送信元Ｄ１とのコンテンツ伝送を継続する。
【０１０３】
一方、ＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧに対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信しなかった場合には（ステップＳ６０９のＮｏ）、送信元Ｄ１がＴＴＬの制限の範囲内にいないことが分かる。この場合、ＤＴＣＰアプリケーションは、送信元Ｄ１とのコンテンツ伝送を停止して（ステップＳ６１０）、本処理ルーチンを終了する。
【０１０４】
また、図７には、ＤＴＣＰ＿Ｓｉｎｋ１１０又はＤＴＣＰ＿Ｓｏｕｒｃｅ１３０などのＤＴＣＰ機器がＤＴＣＰコマンドを受信した際に実行する処理手順の他の例をフローチャートの形式で示している。図示の処理手順は、基本的には、ＤＴＣＰアプリケーションが実行するものであり、受信したＩＰパケットのヘッダー内のＴＴＬフィールドを参照できないため、送信元がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きを実施する。
【０１０５】
ＤＴＣＰアプリケーションは、ＤＴＣＰコマンド（Ｘ）を受信すると、これに対するレスポンスを返信するとともに（ステップＳ７０１）、このＤＴＣＰコマンド（Ｘ）の送信元をＤ１として、そのＩＰアドレスとともに記憶する（ステップＳ７０２）。
【０１０６】
そして、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が一連のコマンドのやり取りにより認証処理を行なう、単発でないコマンド処理となるものかどうかをチェックする（ステップＳ７０３）。
【０１０７】
ここで、受信したＤＴＣＰコマンド（Ｘ）が単発でないコマンド処理となるものである場合には（ステップＳ７０３のＹｅｓ）、一連のコマンドのやり取りを通じた認証処理により、ＴＴＬの制限の範囲内にいる相手を確認することができる。したがって、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が要求する処理を実行して（ステップＳ７０８）、本処理ルーチンを終了する。
【０１０８】
一方、受信したＤＴＣＰコマンド（Ｘ）が単発のコマンド処理となる場合には（ステップＳ７０３のＮｏ）、次いで、ＤＴＣＰアプリケーションは、ＤＴＣＰコマンド（Ｘ）の受信より前の所定期間Ｔ以内で、送信元Ｄ１に対して制限以内のＴＴＬを設定したＤＴＣＰコマンド（Ｙ１）を送信したかどうかをチェックする（ステップＳ７０４）。
【０１０９】
ここで、所定期間Ｔ以内で送信元Ｄ１にＴＴＬが３以下のＤＴＣＰコマンド（Ｙ１）を送信していた場合には（ステップＳ７０４のＹｅｓ）、このＤＴＣＰコマンド（Ｙ１）に対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信したかどうかをさらにチェックする（ステップＳ７０５）。ここで、ＤＴＣＰコマンド（Ｙ１）のレスポンスの送信元がＤ１であるかどうかは、Ｓｏｕｒｃｅ  ＩＰアドレスの一致によって確認することができる。また、レスポンスがＤＴＣＰコマンド（Ｙ１）に対応するかどうかは、ＤＴＣＰコマンド・データ内に記載されたコマンドＩＤ（ｓｕｂｆｕｎｃｔｉｏｎ）の値が一致するかどうかで確認することができる。
【０１１０】
ＤＴＣＰコマンド（Ｙ１）に対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信した場合には（ステップＳ７０５のＹｅｓ）、送信元Ｄ１がＴＴＬの制限の範囲内にいることが分かる。したがって、送信元Ｄ１がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きは不要なので、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が要求する処理を実行して（ステップＳ７０８）、本処理ルーチンを終了する。
【０１１１】
また、所定期間Ｔ以内で送信元Ｄ１にＴＴＬが３以下のＤＴＣＰコマンド（Ｙ１）を送信していない場合（ステップＳ７０４のＮｏ）、並びに、ＤＴＣＰコマンド（Ｙ１）に対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信できなかった場合には（ステップＳ７０５のＮｏ）には、受信パケット（Ｘ）は要確認パケットであることが分かる。この場合、送信元Ｄ１がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きが必要になる。
【０１１２】
そこで、ＤＴＣＰアプリケーションは、ＤＴＣＰコマンド（Ｘ）を受信してから所定期間Ｔ以内に、確認用パケットとして、単発のコマンド処理となるＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧを送信元Ｄ１に送信する（ステップＳ７０６）。そして、ＤＴＣＰアプリケーションは、確認用パケット、すなわちＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧに対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信したかどうかをチェックする（ステップＳ７０７）。ここで、ＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧのレスポンスの送信元がＤ１であるかどうかは、Ｓｏｕｒｃｅ  ＩＰアドレスの一致によって確認することができる。
【０１１３】
ＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧに対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信した場合には（ステップＳ７０７のＹｅｓ）、送信元Ｄ１がＴＴＬの制限の範囲内にいることが分かる。この場合、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が要求する処理を実行して（ステップＳ７０８）、本処理ルーチンを終了する。
【０１１４】
一方、ＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧに対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信しなかった場合には（ステップＳ７０７のＮｏ）、送信元Ｄ１がＴＴＬの制限の範囲内にいないことが分かる。この場合、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が要求する処理を実行することなく、本処理ルーチンを終了する。
【０１１５】
また、図８には、ＤＴＣＰ＿Ｓｉｎｋ１１０又はＤＴＣＰ＿Ｓｏｕｒｃｅ１３０などのＤＴＣＰ機器がＤＴＣＰコマンドを受信した際に実行する処理手順のさらに他の例をフローチャートの形式で示している。図示の処理手順は、基本的には、ＤＴＣＰアプリケーションが実行するものであり、受信したＩＰパケットのヘッダー内のＴＴＬフィールドを参照できないため、送信元がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きを実施する。
【０１１６】
ＤＴＣＰアプリケーションは、ＤＴＣＰコマンド（Ｘ）を受信すると、このＤＴＣＰコマンド（Ｘ）の送信元をＤ１として、そのＩＰアドレスとともに記憶する（ステップＳ８０１）。
【０１１７】
そして、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が一連のコマンドのやり取りにより認証処理を行なう、単発でないコマンド処理となるものかどうかをチェックする（ステップＳ８０２）。
【０１１８】
ここで、受信したＤＴＣＰコマンド（Ｘ）が単発でないコマンド処理となるものである場合には（ステップＳ８０２のＹｅｓ）、一連のコマンドのやり取りを通じた認証処理により、ＴＴＬの制限の範囲内にいる相手を確認することができる。したがって、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が要求する処理を実行する（ステップＳ８０７）。そして、要求処理を実行した後に、ＤＴＣＰコマンド（Ｘ）に対するレスポンスを送信元Ｄ１に返信して（ステップＳ８０８）、本処理ルーチンを終了する。
【０１１９】
一方、受信したＤＴＣＰコマンド（Ｘ）が単発のコマンド処理となる場合には（ステップＳ８０２のＮｏ）、次いで、ＤＴＣＰアプリケーションは、ＤＴＣＰコマンド（Ｘ）の受信より前の所定期間Ｔ以内で、送信元Ｄ１に対して制限以内のＴＴＬを設定したＤＴＣＰコマンド（Ｙ１）を送信したかどうかをチェックする（ステップＳ８０３）。
【０１２０】
ここで、所定期間Ｔ以内で送信元Ｄ１にＴＴＬが３以下のＤＴＣＰコマンド（Ｙ１）を送信していた場合には（ステップＳ８０３のＹｅｓ）、このＤＴＣＰコマンド（Ｙ１）に対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信したかどうかをさらにチェックする（ステップＳ８０４）。ここで、ＤＴＣＰコマンド（Ｙ１）のレスポンスの送信元がＤ１であるかどうかは、Ｓｏｕｒｃｅ  ＩＰアドレスの一致によって確認することができる。また、レスポンスがＤＴＣＰコマンド（Ｙ１）に対応するかどうかは、ＤＴＣＰコマンド・データ内に記載されたコマンドＩＤ（ｓｕｂｆｕｎｃｔｉｏｎ）の値が一致するかどうかで確認することができる。
【０１２１】
ＤＴＣＰコマンド（Ｙ１）に対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信した場合には（ステップＳ８０４のＹｅｓ）、送信元Ｄ１がＴＴＬの制限の範囲内にいることが分かる。したがって、送信元Ｄ１がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きは不要なので、受信したＤＴＣＰコマンド（Ｘ）が要求する処理を実行する（ステップＳ８０７）。そして、要求処理を実行した後に、ＤＴＣＰコマンド（Ｘ）に対するレスポンスを送信元Ｄ１に返信して（ステップＳ８０８）、本処理ルーチンを終了する。
【０１２２】
また、所定期間Ｔ以内で送信元Ｄ１にＴＴＬが３以下のＤＴＣＰコマンド（Ｙ１）を送信していない場合（ステップＳ８０３のＮｏ）、並びに、ＤＴＣＰコマンド（Ｙ１）に対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信できなかった場合には（ステップＳ８０４のＮｏ）には、受信パケット（Ｘ）は要確認パケットであることが分かる。この場合、送信元Ｄ１がＴＴＬの制限の範囲内にいるかどうかを確認するための別途の手続きが必要になる。
【０１２３】
そこで、ＤＴＣＰアプリケーションは、ＤＴＣＰコマンド（Ｘ）を受信してから所定期間Ｔ以内に、確認用パケットとして、単発のコマンド処理となるＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧを送信元Ｄ１に送信する（ステップＳ８０５）。そして、ＤＴＣＰアプリケーションは、確認用パケット、すなわちＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧに対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信したかどうかをチェックする（ステップＳ８０６）。ここで、ＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧのレスポンスの送信元がＤ１であるかどうかは、Ｓｏｕｒｃｅ  ＩＰアドレスの一致によって確認することができる。
【０１２４】
ＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧに対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信した場合には（ステップＳ８０６のＹｅｓ）、送信元Ｄ１がＴＴＬの制限の範囲内にいることが分かる。この場合、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が要求する処理を実行する（ステップＳ８０７）。そして、要求処理を実行した後に、ＤＴＣＰコマンド（Ｘ）に対するレスポンスを送信元Ｄ１に返信して（ステップＳ８０８）、本処理ルーチンを終了する。
【０１２５】
一方、ＤＴＣＰコマンド（Ｙ２）又はＰＩＮＧに対するレスポンスをタイムアウト時間内に送信元Ｄ１から受信しなかった場合には（ステップＳ８０６のＮｏ）、送信元Ｄ１がＴＴＬの制限の範囲内にいないことが分かる。この場合、ＤＴＣＰアプリケーションは、受信したＤＴＣＰコマンド（Ｘ）が要求する処理の実行や、ＤＴＣＰコマンド（Ｘ）に対するレスポンスの返信を行なうことなく、本処理ルーチンを終了する。
【０１２６】
このように、本実施形態によれば、ＤＴＣＰ機器は、ＤＴＣＰコマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを、当該コマンドの受信とは別の手続きにより確認することができる。したがって、受信したＩＰパケットのＴＴＬフィールドの値を参照できない環境下でも、ＤＴＣＰ仕様が求める「ＴＴＬが３を超えるＤＴＣＰコマンドの破棄」を実現することができ、ＤＴＣＰに対応したアプリケーションを実装することができる。
【０１２７】
なお、本明細書の開示の技術は、以下のような構成をとることも可能である。
（１）コマンド及びレスポンスを載せたパケットを送受信する通信部と、受信したパケットのヘッダーを参照せずに、コマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する送信元確認部と、前記送信元確認部による確認結果に応じて受信したコマンドの処理、又は、コマンドの送信元との以後の通信を制御する制御部と、を具備する通信装置。
（２）一連のコマンドのやり取りにより認証処理を行なうコマンドを受信したときには、前記送信元確認部はそのコマンドの送信元の確認処理を行なわない、上記（１）に記載の通信装置。
（３）コマンドの処理が単発で完結し、相互のコマンドのやり取りを伴わない要確認コマンドを受信したときには、前記送信元確認部はそのコマンドの送信元の確認処理を行なう、上記（１）に記載の通信装置。
（４）前記送信元確認部は、コマンドを受信する前の所定期間以内に当該コマンドの送信元にコマンドを送信しており且つタイムアウト時間前にそのレスポンスを受信したときには、当該コマンドの送信元がＴＴＬの制限の範囲内にいると判断する、上記（１）に記載の通信装置。
（５）前記送信元確認部は、コマンドを受信してから所定期間以内に当該コマンドの送信元に対し制限の範囲内のＴＴＬを設定した確認用パケットを送信し、タイムアウト時間前にそのレスポンスを受信したときには、当該コマンドの送信元がＴＴＬの制限の範囲内にいると判断する、上記（１）に記載の通信装置。
（６）前記送信元確認部は、前記確認用パケットとして、コマンドの処理が単発で完結し相互のコマンドのやり取りを伴わないコマンド、又は、ＰＩＮＧを送信する、上記（５）に記載の通信装置。
（７）前記制御部は、前記コマンドの送信元に対してコンテンツ伝送中に、前記コマンドの送信元がＴＴＬの制限の範囲内でないことが確認されたときには、前記コンテンツ伝送を停止する、上記（１）に記載の通信装置。
（８）前記制御部は、前記コマンドの送信元がＴＴＬの制限の範囲内であることが確認されたときには、前記コマンドが要求する処理を実行する、上記（１）に記載の通信装置。
（９）前記制御部は、前記コマンドの送信元がＴＴＬの制限の範囲内であることが確認されたときには、前記コマンドが要求する処理を実行するとともに、前記コマンドの送信元にレスポンスを返す、上記（１）に記載の通信装置。
（１０）コマンドを載せたパケットを受信するコマンド受信ステップと、受信したパケットのヘッダーを参照せずに、コマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する送信元確認ステップと、前記送信元確認ステップにおける確認結果に応じて受信したコマンドの処理、又は、コマンドの送信元との以後の通信を制御する制御ステップと、を有する通信方法。
（１１）コマンドを載せたパケットを任意のＴＴＬを設定して送信する第１の機器と、ＴＴＬの値を１ずつデクリメントして前記パケットを転送する任意の台数（０台を含む）のルーターと、前記パケットを受信して、そのヘッダーを参照せずに前記第１の機器がＴＴＬの制限の範囲内にいるかどうかを確認し、確認結果に応じて受信したコマンドの処理を行なう第２の機器と、を具備する通信システム。
（１２）コマンド及びレスポンスを載せたパケットを送受信する通信部、受信したパケットのヘッダーを参照せずに、コマンドの送信元がＴＴＬの制限の範囲内にいるかどうかを確認する送信元確認部、前記送信元確認部による確認結果に応じて受信したコマンドの処理、又は、コマンドの送信元との以後の通信を制御する制御部、としてコンピューターを機能させるようコンピューター可読形式で記述されたコンピューター・プログラム。
【産業上の利用可能性】
【０１２８】
以上、特定の実施形態を参照しながら、本明細書で開示する技術について詳細に説明してきた。しかしながら、本明細書で開示する技術の要旨を逸脱しない範囲で当業者が該実施形態の修正や代用を成し得ることは自明である。
【０１２９】
本明細書では、本明細書で開示する技術をＩＰネットワーク並びにＤＴＣＰ仕様のネットワークに適用した実施形態を中心に説明してきたが、本明細書で開示する技術の要旨はこれに限定されるものではない。ＤＴＣＰ以外の、ＴＴＬの制限が課されたネットワークや、ＩＰプロトコルに準拠しないネットワークでＴＴＬの制限を課したい場合にも、同様に本明細書で開示する技術で開示する技術を適用することができる。
【０１３０】
勿論、受信パケットのＴＴＬの値を確認できる環境下でも、本明細書で開示する技術を適用することによって、ＴＴＬの制限の範囲内の相手から送られたパケットかどうかを別途の手続により確認して、安全な通信を行なうことができる。
【０１３１】
要するに、例示という形態により本明細書で開示する技術について説明してきたのであり、本明細書の記載内容を限定的に解釈するべきではない。本明細書で開示する技術の要旨を判断するためには、特許請求の範囲を参酌すべきである。
【符号の説明】
【０１３２】
１００…通信システム
１１０…ＤＴＣＰ＿Ｓｉｎｋ
１１１…ＣＰＵ、１１２…通信部
１１３…記憶部、１１４…コンテンツ再生出力部
１２０…ＩＰルーター
１３０…ＤＴＣＰ＿Ｓｏｕｒｃｅ
１３１…ＣＰＵ、１３２…通信部、１３３…記憶部
【図１】
2014013972.tif 000003
【図２Ａ】
2014013972.tif 000004
【図２Ｂ】
2014013972.tif 000005
【図３Ａ】
2014013972.tif 000006
【図３Ｂ】
2014013972.tif 000007
【図４Ａ】
2014013972.tif 000008
【図４Ｂ】
2014013972.tif 000009
【図４Ｃ】
2014013972.tif 000010
【図５】
2014013972.tif 000011
【図６】
2014013972.tif 000012
【図７】
2014013972.tif 000013
【図８】
2014013972.tif 000014
【図１０】
2014013972.tif 000015
【図１１】
2014013972.tif 000016
【図１２】
2014013972.tif 000017
【図９Ａ】
2014013972.tif 000018
【図９Ｂ】
2014013972.tif 000019
【図１３】
2014013972.tif 000020