(57)【要約】静的な識別子と動的な住所が関連付けられることによってホスト到達性が得られる網にあって、サイン・アンド・カウンターサインを用いて、通信ノードの活死および到達性を確認する。
2004059925.tif 000002
【特許請求の範囲】
【請求項１】
静的な識別子と動的な住所が関連付けられることによってホスト到達性が得られる蓄積交換網において、
マッピング公示システム（１０００）における被到達性確認通信ノード（４１００）を示す静的な識別子と動的な住所からなる組の写像と、
被到達性確認通信ノード（４１００）における静的な識別子と動的な住所からなる組の実像とを比較することによって、
被到達性確認通信ノード（４１００）への到達性の真偽を判定することを特徴とする通信モデル。
【請求項２】
請求項１の通信モデルにあって、
以下のシーケンスによって、前記通信モデルにおける比較する要素のすべてを到達性確認通信ノード（２０００）が知る手順。
（１）到達性確認通信ノード（２０００）は被到達性確認通信ノード（４１００）の静的な識別子をキーにマッピング公示システムに対して要求する名前問合せ。
（２）マッピング公示システムは、この問合せに対して被到達性確認通信ノード（４１００）の動的な住所を応答する名前解決。
（３）到達性確認通信ノード（２０００）は前記応答された被到達性確認通信ノード（４１００）を示す動的な住所あてに単に応答することを要求するサイン。
（４）被到達性確認通信ノード（４１００）が答えるべき返事を新規のキャリア信号に載せて応答するカウンターサイン。
【請求項３】
請求項１に記載の通信モデルにおいて、
被到達性確認通信ノード（４１００）が到達性確認通信ノード（２０００）に到達性を確認させる情報を搬送することを特徴とする信号。
【請求項４】
請求項３に記載の信号において、
被到達性確認通信ノード（４１００）が到達性確認通信ノード（２０００）に到達性を確認させる情報が、被到達性確認通信ノード（４１００）が答えるべき返事である情報を搬送することを特徴とする信号。
【請求項５】
請求項３に記載の信号において、
被到達性確認通信ノード（４１００）が到達性確認通信ノード（２０００）に到達性を確認させる情報が、被到達性確認通信ノード（４１００）が答えるべき返事である情報に加えて、さらに附加情報を搬送することを特徴とする信号。
【請求項６】
被到達性確認通信ノード（４１００）において、到達性確認通信ノード（２０００）からの応答要求に応じてする応答において、答えるべき返事をキャリーする機能を有するキャリア信号。
【請求項７】
請求項６に記載の信号において、答えるべき返事に加えてさらに附加情報をキャリーすること機能を有するキャリア信号。
【請求項８】
静的な識別子と動的な住所が関連付けられることによってホスト到達性が得られる蓄積交換網において、
到達性確認通信ノード（２０００）に任意の情報を被到達性確認通信ノード（４１００）への到達性を確認させる情報として記憶させ、到達性確認通信ノード（２０００）と被到達性確認通信ノード（４１００）とが所定の通信をすることによって被到達性確認通信ノード（４１００）が到達性確認通信ノード（２０００）に対してした返信を前記記憶した情報と比較することによって、被到達性確認通信ノード（４１００）への到達性を到達性確認通信ノード（２０００）に確認させることを特徴とする到達性確認の方法。
【請求項９】
請求項８に記載された到達性確認の方法において、
任意の情報が、被到達性確認通信ノード（４１００）における静的な識別子であることを特徴とする到達性確認の方法。
【請求項１０】
請求項８に記載された到達性確認の方法において、
任意の情報が、被到達性確認通信ノード（４１００）と関連づけられていることを到達性確認通信ノード（２０００）が知っている場合に静的な識別子に置き換えられたあらゆる文字列であることを特徴とする到達性確認の方法。
【請求項１１】
請求項８に記載された到達性確認の方法において、
任意の情報が、被到達性確認通信ノード（４１００）と関連づけられていることを到達性確認通信ノード（２０００）が知っている場合に静的な識別子に替わって使用される変形ルールであることを特徴とする到達性確認の方法。
【請求項１２】
請求項８に記載の到達性確認の方法において、
被到達性確認通信ノード（４１００）において、被到達性確認通信ノード（４１００）の記憶装置に任意の情報を答えるべき返事として保存し、あらかじめ合意された方式での通信に対して前記保存された情報を記憶装置より読み出し、少なくとも該情報を含めたカウンターサインを返信することによって、被到達性確認通信ノード（４１００）が到達性の被到達性確認通信ノード（４１００）であることを到達性確認通信ノード（２０００）に確認させることを特徴とする到達性確認の方法。
【請求項１３】
請求項８に記載の到達性確認の方法において、
被到達性確認通信ノード（４１００）の静的な識別子を管理する複数存在するマッピング公示システム（１０００）の内の１のマッピング公示システム（１０００）を選択して正引き名前問合せをして、参照する被到達性確認通信ノード（４１００）毎に異なるマッピング公示システム（１０００）に切り替えることによって、被到達性確認通信ノード（４１００）の動的な住所を取得して、請求項８に記載の被到達性確認通信ノード（４１００）と前記所定の通信をするために前記取得した動的な住所を用いておこなうことを特徴とする到達性確認の方法。
【請求項１４】
請求項８から請求項１３のいずれかに記載の到達性確認の方法において、
被到達性確認通信ノード（４１００）への到達性確認に失敗した場合に、所定の時間間隔を経過した後、再度請求項８から請求項１３のいずれかに記載の到達性確認の方法を実施することによって、被到達性確認通信ノード（４１００）に対する到達性の真偽を確認することを特徴とする到達性確認の方法。
【請求項１５】
請求項８から請求項１４のいずれかに記載の到達性確認の方法において、到達性確認通信ノード（２０００）が到達性を確認する機能を有しない端末に替わってする到達性確認の方法
【請求項１６】
請求項８から請求項１４のいずれかに記載の到達性確認の方法において、
前記到達性確認の結果を、所定の対象者または公衆に通知することをさらに具備することを特徴とする到達性確認の方法。
【請求項１７】
請求項８から請求項１６のいずれかに記載の到達性確認の方法において、到達性確認通信ノード（２０００）が到達性確認する機能を有しない端末からの被到達性確認通信ノード（４１００）に対する到達性確認要求を受け、到達性確認通信ノード（２０００）が被到達性確認通信ノード（４１００）に対する到達性の真偽を確認し、その結果を到達性確認する機能を有しない端末に応答することを特徴とする到達性確認の方法。
【請求項１８】
請求項１７に記載の到達性確認の方法において、到達性確認の結果を到達性確認する機能を有しない端末に応答する際に、さらに到達性確認する機能を有しない端末がキャッシュの影響を受ける時間を予測して、正常にアクセスできる時間を更に前記応答に含めることを特徴とする到達性確認の方法。
【請求項１９】
ＳＮＭＰマネージャを用いてする到達性確認の方法に先だって、請求項８から請求項１４のいずれかに記載の被到達性確認通信ノード（４１００）への到達性確認を実施し、ここで被到達性確認通信ノード（４１００）の到達性が確認された場合に、到達性が確認された被到達性確認通信ノード（４１００）の動的な住所を、ＳＮＭＰマネージャを用いてする到達性確認の方法に引き渡すことによって、動的に住所が変化する被到達性確認通信ノード（４１００）を管理することを特徴とする到達性確認の方法。
【請求項２０】
請求項８から請求項１４のいすれかに記載の到達性確認の方法において、到達性確認することによって、被到達性確認通信ノード（４１００）が網上に存在しないことが検知された場合に、マッピング公示システムが公示する被到達性確認通信ノード（４１００）に関する静的な識別子と動的な住所の関連付けを公示しないようにマッピング公示システムを構成しなおす方法。
【請求項２１】
請求項２０に記載の到達性確認の方法において、到達性確認することによって、被到達性確認通信ノード（４１００）が網上に存在しないことが検知された場合に、被到達性確認通信ノード（４１００）の属するドメイン名を管理するＤＮＳサーバにおいて、被到達性確認通信ノード（４１００）に関するリソースレコードの消込みをする方法。
【請求項２２】
請求項８から請求項１４のいすれかに記載の到達性確認の方法を用いて、蓄積交換網において発信者番号通知する方法。
【請求項２３】
請求項２２に記載の方法を用いてする閉域接続する方法。
【請求項２４】
請求項８から請求項１４のいすれかに記載の到達性確認の方法において、被到達性確認通信ノード（４１００）に関する到達性の確認が取れた住所を到達性確認通信ノード（２０００）が記憶することによって、ＤＮＳに対する名前解決過程を省略し、このことによって、ＤＮＳトラフィックを減ずる方法。
【請求項２５】
請求項８から請求項１４のいずれかに記載の到達性確認の方法において、
到達性確認の結果を次の処理の入力として用いるあらゆるプログラム。
【請求項２６】
請求項８から請求項２４のいずれかに記載の到達性確認の方法を、
計算機もしくはネットワーク接続機器に実行させるためのプログラム。
【請求項２７】
計算機もしくはネットワーク接続機器であって、
該装置に被到達性確認通信ノード（４１００）毎に少なくともサインが設定され、答えられるべき返事が被到達性確認通信ノード（４１００）を示す静的な識別子そのものでない場合には答えられるべき返事をも設定され、該装置から被到達性確認通信ノード（４１００）にサインを送信する手段と、被到達性確認通信ノード（４１００）から応答されるカウンターサインを受信する手段と、前記受信されたカウンターサインによって搬送された答えるべき返事と前記設定された答えられるべき返事とを比較する手段とを備え、比較された結果の真偽によって被到達性確認通信ノード（４１００）に対する到達性の真偽を確認することを特徴とする通信ノード。
【請求項２８】
請求項２７に記載の通信ノードにおいて、
被到達性確認通信ノード（４１００）の使用する静的な識別子を管理する複数存在するマッピング公示システム（１０００）の内の１のマッピング公示システム（１０００）を、被到達性確認通信ノード（４１００）毎に選択して正引き名前問合せをして、被到達性確認通信ノード（４１００）の動的な住所を取得して、被到達性確認通信ノード（４１００）と通信するために前記取得した動的な住所を用いておこなうことを特徴とする通信ノード。
【請求項２９】
請求項２７から請求項２８のいずれかに記載の通信ノードにおいて、
被到達性確認通信ノード（４１００）への到達性確認に失敗した場合に、所定の時間間隔を経過した後、再度請求項２７に記載の到達性確認を再度実施することによって、正しい到達性の被到達性確認通信ノード（４１００）に到達するか否かを確認することを特徴とする通信ノード。
【請求項３０】
請求項２７から請求項２９のいずれかに記載の通信ノードにおいて、
一般利用者の使用する通信ノードからの要求に応じて、前記到達性確認をすることを特徴とする通信ノード。
【請求項３１】
請求項２７から請求項３０のいずれかに記載の通信ノードにおいて、
前記到達性確認の結果を、所定の対象者または公衆に通知することをさらに具備することを特徴とする装置。
【請求項３２】
請求項２７から請求項３１のいずれかに記載の通信ノードにおいて、
到達性確認する機能を有しない端末からの被到達性確認通信ノード（４１００）に対する到達性確認要求を受け、到達性確認通信ノード（２０００）が被到達性確認通信ノード（４１００）に対する到達性の真偽を確認し、その結果を到達性確認する機能を有しない端末に応答することを特徴とする通信ノード。
【請求項３３】
請求項３２に記載の通信ノードにおいて、
到達性確認の結果を到達性確認する機能を有しない端末に応答する際に、さらに到達性確認する機能を有しない端末がキャッシュの影響を受ける時間を予測して、正常にアクセスできる時間を更に前記応答に含めることを特徴とする通信ノード。
【請求項３４】
請求項２７から請求項３１のいずれかに記載の到達性確認に後続して、ＳＮＭＰマネージャを用いてする到達性確認の方法に接続するために、
請求項２７から請求項３１のいずれかに記載された到達性が確認された被到達性確認通信ノード（４１００）の動的な住所を、ＳＮＭＰマネージャを用いてする到達性確認の方法に引き渡すことによって動的な住所が変化する被到達性確認通信ノード（４１００）を管理することを特徴とする通信ノード。
【請求項３５】
請求項２７から請求項２９のいずれかに記載の通信ノードにおいて、
到達性確認することによって、被到達性確認通信ノード（４１００）の網上における不存在を検知したときに、マッピング公示システム（１０００）における被到達性確認通信ノード（４１００）を示す静的な識別子と動的な住所からなる組の写像の公示を公示しないように変更するマッピング公示システム（１０００）。
【請求項３６】
請求項３５に記載のマッピング公示システム（１０００）において、
到達性確認することによって、被到達性確認通信ノード（４１００）が網上に存在しないことが検知された場合に、被到達性確認通信ノード（４１００）の属するドメイン名を管理するＤＮＳサーバにおいて、被到達性確認通信ノード（４１００）に関するリソースレコードの消込みをするＤＮＳサーバ。
【請求項３７】
請求項２７から請求項２９のいずれかに記載の通信ノードにおいて、
カウンターサインによってキャリーされた、蓄積交換網における発信者番号通知を受信する通信ノード。
【請求項３８】
請求項３７に記載の通信ノードにおいて、
事前に設定された発信者番号を通知する通信ノードのみに対して、所定のサービスを提供する通信ノード。
【請求項３９】
請求項２７から請求項２９のいずれかに記載の通信ノードにおいて、
被到達性確認通信ノード（４１００）に関する到達性の確認が取れた住所を記憶することによって、ＤＮＳに対する名前解決過程を省略した到達性確認通信ノード（２０００）。
【請求項４０】
請求項２７から請求項３９のいずれかに記載の通信ノードにおいて、
通信ノードの機能が、複数の装置によって共有されることからなるセンタ側のシステム。
【請求項４１】
請求項２７から請求項３９のいずれかに記載の通信ノードにおいて、
計算機もしくはネットワーク接続機器に実行させるためのプログラム。
【請求項４２】
計算機もしくはネットワーク接続機器であって、
住所の割当てを動的に受けてなる通信ノードもしくは外部ネットワークからは該通信ノードと一体となって参照される通信ノードのいずれかであって、
該通信ノードの記憶装置に任意の情報を答えるべき返事として保存し、サインもしくはあらかじめ合意された方式での通信に対して前記保存された情報を該記憶装置より読み出し、少なくとも該情報を含めたカウンターサインもしくはあらかじめ合意された方式での通信に対するカウンターサインを返信するように構成されることを特徴とする通信ノード。
【請求項４３】
請求項４２に記載の通信ノードにおいて、
該通信ノードにおいて保存された答えるべき返事が到達性確認通信ノード（２０００）に対して事前に通知されていること条件として、あらゆる文字列で以って設定されるものであって、該文字列が該通信ノードの記憶装置に保存され、所定のポートへの通信要求を受けた際に、前記保存された文字列を該記憶装置より読み出し、少なくとも該文字列を含めた返信をするように構成されることを特徴とする通信ノード。
【請求項４４】
請求項４２に記載の通信ノードにおいて、
該通信ノードにはホスト名が設定されるものであって、該ホスト名が該通信ノードの記憶装置に保存され、所定のポートへの通信要求を受けた際に、前記保存されたホスト名を該記憶装置より読み出し、少なくとも該ホスト名を含めた文字列を返信するように構成されることを特徴とする通信ノード。
【請求項４５】
請求項４２に記載の通信ノードにおいて、
ダイナミックＤＮＳによって動的更新されるセンタ側マッピング公示システム（１０００）において設定されるホスト名をＦＱＤＮでもって、該通信ノードに読み出し可能な文字列として設定されるものであって、該文字列が該通信ノードの記憶装置に保存され、所定のポートへの通信要求を受けた際に、前記保存された文字列を該記憶装置より読み出し、少なくとも該文字列を含めた文字列を返信するように構成されることを特徴とする通信ノード。
【請求項４６】
請求項４２から請求項４５のいずれかに記載の通信ノードにおいて、
請求項４２から請求項４５のいずれかに記載の待受けされる所定のポート以外に、該通信ノードの設定変更用のポートあるいは、一般の閲覧に供するためのウェブサービスを提供するウェルノウンなポートのいずれかのポート、あるいはその両方のポートで待受けされる所定のポートを備えるように構成されることを特徴とする通信ノード。
【請求項４７】
請求項４２から請求項４６のいずれかに記載の通信ノードにおいて、
到達性確認通信ノード（２０００）からのサインもしくはあらかじめ合意された方式での通信に対して、
被到達性確認通信ノード（４１００）がカウンターサインもしくはあらかじめ合意された方式での通信に対するカウンターサインを返信することによって、
到達性確認通信ノード（２０００）に、被到達性確認通信ノード（４１００）への到達性を判定させることを特徴とする通信ノード。
【請求項４８】
請求項４２から請求項４７のいずれかに記載の通信ノードにおいて、
答えるべき返事をキャリーするキャリア信号をサインに応答して送出することを特徴とする通信ノード。
【請求項４９】
請求項４９に記載の通信ノードにおいて、
答えるべき返事として自己の識別情報をキャリーするキャリア信号をサインに応答して送出することを特徴とする通信ノード。
【請求項５０】
請求項４９に記載の通信ノードにおいて、
前記キャリア信号をサインに応答して送出することによって、発信者番号通知に替えることを特徴とする通信ノード。
【請求項５１】
請求項４２から請求項５０のいずれかに記載の通信ノードとしての機能を、
計算機もしくはネットワーク接続機器に実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】  本発明は、蓄積交換型の通信網において、あて先端末を発見する過程における不備を解決する通信モデル、信号、方法および装置に関する。
詳しくは、静的な識別子を動的な住所に変形することによって、あて先端末への到達性を発信元に提供する場合において、発信元があて先端末への誤った到達性を持つ場合と正しい到達性を持つ場合とを峻別する。
【背景技術】  （特許文献１）特許公表２００１−５１９６０７  亦はＷＯ９９／１８５１５（米インテル）静的な識別子を動的に割当てられたネットワーク・アドレスに変形する方法および装置
（特許文献２）特開２００１−１３５３０１（ＮＴＴ）ＩＰアドレス情報通知方法およびＩＰアドレス情報通知装置並びにこのプログラムを記憶した記憶媒体
（特許文献３）特開２００２−３１８７３７（インデックス）管理サーバ
（特許文献４）特開２００２−２８１０３２（東芝）監視対象切替プログラム、方法及び監視システム
（特許文献５）特開Ｈ７−２００５０２（オムロン）トランザクション処理システムに関する二重化装置
インターネット（＝ｔｈｅ  Ｉｎｔｅｒｎｅｔ）は非常に多数の計算機と計算機による網（以下、単に「網」とする）から構成され、これらはＴＣＰ／ＩＰプロトコルを用いた通信リンクを通して世界的な規模で相互に接続されている。相互に接続された計算機は、電子メール、ゴーファー、およびワールドワイドウェブ等の、様々なインターネットサービスを利用して情報をやりとりしている。
インターネットは、網割当て団体から一意に割当てられたＩＰアドレスによって、そのホストを識別している。ＩＰアドレスは、計算機が処理し易いように固定長の数字の羅列として表現されており、人間にとっては無意味綴りであり、覚えたり毎回間違えずに入力したりするのが困難である。ＴＣＰ／ＩＰ網においては、ホストを特定する為には少なくともＩＰアドレスが必要であり、ＩＰアドレスでホストを特定することが人間にとって判りにくいものであるという問題を軽減する為に、ドメインネームシステム（以下、「ＤＮＳ」とする）を用いてホストを特定することがおこなわれてきた。
ＤＮＳは、ＩＰアドレスのような数字の羅列ではなく、人間にとって意味がある文字列でインターネット上のホストを特定するためのデータベースシステムである。階層的な名前空間を構成しており、ドメイン名と呼ばれる文字列を登録しておき、これをＩＰアドレスと対応づけることによって、インターネット上のホストを特定する。これを正引き名前解決という。逆に、ＩＰアドレスからドメイン名を検索することを逆引き名前解決という。ＤＮＳの特徴は、ルートサーバを頂点とする木構造の分散データベースである。また、ＩＰアドレスはルーティングの制約を受ける（すなわちＩＰアドレスは、ＩＰアドレス体系の中での位置情報である）が、ＤＮＳにおける名前はホストの網的な位置とは無関係に存在できる。
一般にインターネットに常時接続し、ＩＰアドレスの割当てを受けた各利用組織は、ドメイン名の登録団体に対して、ドメインの登録をおこない、自組織のためのドメイン名の運用をおこなう。この時にドメイン運用をおこなうサーバがＤＮＳサーバである。なお、ＤＮＳサーバの登録には、ドメイン名の登録団体に対してＩＰアドレスおよびホスト名を指定して、ＤＮＳサーバの登録をおこなう。
ルートサーバは第一レベルのＤＮＳサーバに、第一レベルのＤＮＳサーバは第二レベルのＤＮＳサーバに、そして最終的に上で示したＩＰアドレスの割当てを受けた各利用組織のＤＮＳサーバにドメイン運用の権限の委譲をおこなう。図１７に、ＤＮＳの検索順を示す。ＩＰアドレスの割当てを受けた各利用組織のＤＮＳサーバでは、ドメイン名に対するホスト名とＩＰアドレスの対応づけや、メールの配送経路の指定等といった実際の設定をおこなう。
旧来ＤＮＳは設定ファイルを手動で設定および更新されてきた。ところが主に社内で利用されるプライベートＬＡＮ等において、Ｗｉｎｄｏｗｓ（登録商標、以下同様）パソコンの普及とダイナミック・ホスト・コンフィグレーション・プロトコル（ＤＨＣＰ）による端末となるパソコンの動的な網設定の普及によって、Ｗｉｎｄｏｗｓパソコンが再起動されるたびにＩＰアドレスが変化する等の、従来のように静的に１のホスト名と１のＩＰアドレスを対応づけることが難しくなってきた。ダイナミックＤＮＳとは、ＤＮＳサーバのレコードの更新をクライアントからのアップデート要求によって自動的に更新するしくみを提供するものである。ダイナミックＤＮＳの利用について、社内ＬＡＮ等の直接インターネットに接しない網における利用だけではなく、インターネットのグローバルサービスの中でも、現在、実用性の検証がされている。
インターネットのグローバルサービスの中でダイナミックＤＮＳサービスを利用した場合には、網割当て団体から網の割当てを受けないあるいはプロバイダから固定的なＩＰアドレス割当てを受けない（ダイヤルアップの）ホストで、インターネットサービスを提供することが出来るようになる。
ところで、ダイヤルアップとは、主にダイヤルアップ接続としてインターネットに接続する際に電話をかける行為を伴うものをいうが、近年ケーブルテレビやデジタル加入者回線、光ファイバや衛星リンク等をアクセス回線に用いた定額制のＩＰ接続役務等によるアクセス回線の多様化により、必ずしも電話をかける行為を必要としなくなっている。これら近年の常時接続型と呼ばれるインターネット接続役務は、単に接続時間による課金体系でなくなったことを意味し、ルータのセッション異常終了（停電等）、回線の異常、センタの故障やメンテナンス等により接続が異常切断された場合や接続業者もしくはダイヤルアップするホストの無通信タイマによって回線が切断された場合等に再接続すると、ＩＰアドレスが変わる場合があるという点で専用線による接続と異なる。また、移動体通信端末の場合において、無線基地局を移動した場合等にＩＰアドレスが付け変わることがある。このような場合（すなわちハンドオーバした場合）にも、本明細書では便宜上、端末ノードのＩＰアドレスが変化するという点で、ダイヤルアップに含めることとする。
そこで本発明では、従来の専用線による接続に代表される網割当団体から恒常的な網の割当てを受けて接続する場合かプロバイダ（あるいはＩＰアドレスの割当てを受けた各利用組織）から恒常的なＩＰアドレスの割当てを受けて接続する場合と対比して、プロバイダ（あるいはＩＰアドレスの割当てを受けた各利用組織）からの一時的な利用を前提としたＩＰアドレスの割当てを受けて接続することを（モデムを用いて電話をかけるという行為を伴わず、ＤＨＣＰやＰＰＰｏＥ等による割当てであったとしても）「ダイヤルアップ接続」といい、一時的なＩＰアドレスの割当てを受けるための動作をすることを「ダイヤルアップする」という。また、ＩＰアドレスの一時的な割当てそのものを「ダイヤルアップ」ということとする。
ダイナミックＤＮＳ特有の問題
従来の技術では、ＩＰアドレスが変化するホストでのインターネットサービスの提供はできなかったが、ごく最近になってダイナミックＤＮＳを用いることによって、限定的に（グローバルサービスとしてのＤＮＳは固定ＩＰアドレスが必要なことからＤＮＳを除く）インターネットサービスを提供できるようになった。しかし、ダイナミックＤＮＳを用いることに特有の以下の問題点があった。これを以下、図０１乃至図１２にダイナミックＤＮＳ特有の問題の発生から収束までの過程を紙芝居形式で説明する。
図０１。管理対象機器（以下、「Ｔ」とする）（４１００）からプロバイダ（以下、「Ｐ」とする）（４０００）へダイヤルアップ（ＰＰＰｏＥ等を含む）する。
図０２。Ｔ（４１００）はＰ（４０００）からＩＰアドレスの動的割当てを受ける。この時、割当てを受けたＩＰアドレスを仮に１７２．１６．１００．１００とする。
図０３。Ｔ（４１００）はダイナミックＤＮＳサーバ（以下、「Ｄ」とする）（１０００）へＤＮＳの更新要求をし、これを受けてＤ（１０００）は図０２で説明したＴ（４１００）に割当てられたＩＰアドレス（仮に１７２．１６．１００．１００）とＴ（４１００）のホスト名を関連付けて設定する。
図０４。Ｔ（４１００）は、インターネットの一般利用者（以下、「Ｓ−２」とする）（５３００）からのアクセスを受ける事ができる（正常状態）。
図０５。なんらかの理由でＴ（４１００）からＰ（４０００）への接続が失われる等の障害が発生する。
図０６。Ｔ（４１００）からＰ（４０００）へ再接続（ＰＰＰｏＥ等を含む）する。
図０７。Ｔ（４１００）はＰ（４０００）からＩＰアドレスの動的割当てを受ける。ＩＰアドレスが変化するまで割当てられていたＩＰアドレス（仮に１７２．１６．１００．１００）とは別のＩＰアドレス（仮に１７２．１６．２００．１０）が割当てられる。
図０８。Ｔ（４１００）はＤ（１０００）への更新要求をし、Ｄ（１０００）は図０７で説明したＴ（４１００）に割当てられたＩＰアドレス（仮に１７２．１６．２００．１０）とＴ（４１００）のホスト名を設定する。
図０９。図０７において、この時、Ｔ（４１００）のＩＰアドレスはＩＰアドレスが変化するまで割当てられていたＩＰアドレスとは別のアドレス（仮に１７２．１６．２００．１０）を割当てられており、Ｔ（４１００）にＩＰアドレスが変化するまで割当てられていたＩＰアドレス（仮に１７２．１６．１００．１００）は同一プロバイダの別のユーザＴ’（以下、「Ｔ’」とする）（４２００）に割当てられている。この場合において、Ｓ−２（５３００）から見るとホストがすり替わっているかのように見える。
図１０。インターネット全体では参照されるＤＮＳはここでいうＤ（１０００）ではあり得ず、利用者毎に直接接続されたプロバイダのＤＮＳ（４５００や５５００等）である。そのため、仮にＤ（１０００）が正常に更新されたとしても、キャッシュの生存時間内には、利用者毎に直接接続されたプロバイダのＤＮＳ（４５００や５５００等）からＤ（１０００）への名前問合せは行われない為に、これらのＤＮＳサーバにＴ（４１００）のＩＰアドレス（仮に１７２．１６．２００．１０）が反映されるには時間がかかる。
ＤＮＳ（４５００や５５００等）は、一度問合せをおこなったリソースレコードに関して、一定期間ローカルに記憶しておく。これをキャッシュという。キャッシュは、リソースレコードのＴＴＬ（＝ｔｉｍｅ  ｔｏ  ｌｉｖｅ）で指定された期間だけ記憶され、その後破棄される。これをキャッシュの生存時間という。ＤＮＳ（４５００や５５００等）はキャッシュの生存時間中、リゾルバ（４１００や４２００あるいは５３００等）からの問合せに対して、ローカルな記憶を参照して名前解決する。キャッシュは一度おこなった名前問合せを繰り返すことを抑制し、効率をよくする為に考えられた。しかしＤ（１０００）においては、このキャッシュというメカニズムが逆にＴ（４１００）のＩＰアドレスの変化に追従できない等のうまく合致していない部分があるので、以下に説明する。
図１６に、Ｓ−２（５３００）からどのようにＤＮＳが探索され、目的ホストであるＴ（４１００）に到達するかを順に見てみる。
▲１▼、Ｓ−２（５３００）からＰ−２のＤＮＳ（以下、「Ｐ−２−Ｄ」とする）（５５００）へ、Ｔ（４１００）について正引き名前問合せをおこなう。
▲２▼、Ｐ−２−Ｄ（５５００）は、まず、目的ドメイン名を知っているかどうかを調べ、知っている場合は、即座に目的ホストであるＴ（４１００）のＩＰアドレスをＳ−２（５３００）に返す。この時、Ｐ−２−Ｄ（５５００）が目的ドメイン名を知っている場合とは、目的ドメイン名をＰ−２−Ｄ（５５００）が運用している場合と、目的ホストであるＴ（４１００）に対するＩＰアドレスがＰ−２−Ｄ（５５００）に、キャッシュされている場合である。Ｐ−２−Ｄ（５５００）が目的ドメイン名を知らない場合を、図１７に示す。
▲３▼、▲２▼によってＴ（４１００）のＩＰアドレスを知ることができたＳ−２（５３００）は、これをもとに、Ｔ（４１００）へアクセスする。
図１７は、図１６の▲２▼で、Ｐ−２−Ｄ（５５００）がＴ（４１００）のドメインを運用していない場合と、キャッシュされていない場合（最初の名前問合せの時）のＤＮＳの探索順である。
▲１▼で、Ｓ−２（５３００）からＰ−２−Ｄ（５５００）へ、Ｔ（４１００）について正引き名前問合せをおこなう。
▲２▼、Ｐ−２−Ｄ（５５００）は、目的ドメイン名であるＴ（４１００）のドメインを運用しておらず、キャッシュの中からも見つけられなかった場合、Ｒｏｏｔ  ＤＮＳに、名前問合せをする。
▲３▼、Ｒｏｏｔ  ＤＮＳは、仮に目的ホストであるＴ（４１００）のドメイン名が例としてＪＰドメインであった場合には、ＪＰ  ＤＮＳの所在を返す。（Ｔ（４１００）のドメイン名がＪＰドメインではない場合には、ｃｃＴＬＤなり、ｇＴＬＤなりを管理するネームサーバの所在をＰ−２−Ｄ（５５００）に返す。）
▲４▼、Ｐ−２−Ｄ（５５００）は、▲３▼で得たＪＰドメインのＤＮＳに対して、目的ドメイン名であるＴ（４１００）のドメイン名について名前問合せをする。
▲５▼、ＪＰドメインのＤＮＳは、目的ホストであるＴ（４１００）のドメイン名を運用するサーバ（ここではＤ（１０００））の所在を（ＪＰ配下のドメインは、ＪＰＮＩＣおよび会員のサーバに登録されるツリー構造であり、第二レベル毎のＤＮＳには分かれていないため、すぐに）Ｐ−２−Ｄ（５５００）にＤ（１０００）の所在を返す。
▲６▼、Ｐ−２−Ｄ（５５００）は、▲５▼で得たＤ（１０００）に対して、Ｔ（４１００）の名前をキーに、ＩＰアドレスを正引き名前問合せをする。
▲７▼、Ｄ（１０００）は、Ｔ（４１００）の所在をＰ−２−Ｄ（５５００）に返す。
▲８▼、Ｐ−２−Ｄ（５５００）は、▲７▼で得たＴ（４１００）の所在をＳ−２（５３００）に返す。
▲９▼、Ｓ−２（５３００）は、Ｔ（４１００）へアクセスする。
図１８。ＤＮＳ（４５００や５５００等）は、最初の名前問合せによってキャッシュされ、その後キャッシュの期限が過ぎた事によって、キャッシュが無効となるよう設定するのが一般的である。このキャッシュが無効なタイミング（図１７）では、Ｄ（１０００）に対して名前問合せがおこなわれる為に正しくＴ（４１００）のＩＰアドレスが得られる。しかし、キャッシュが有効な間（図１６）にＴ（４１００）のＩＰアドレスが変ってしまった場合、Ｄ（１０００）に対する名前問合せなしにキャッシュされたＩＰアドレスが返される為に、図０８での更新より以前の（キャッシュされた）ＩＰアドレス（仮に１７２．１６．１００．１００）が返される。なお、図１６の▲２▼のとおり、Ｓ−２（５３００）の接続先であるＰ−２−Ｄ（５５００）がＴ（４１００）のドメインを運用している場合には、キャッシュの問題は発生しない。
図１１。その為に、インターネット全体から見れば、キャッシュを参照するこのタイミングで、Ｔ’（４２００）がＴ（４１００）として誤認されてしまうおそれがある。
またこの時、Ｔ（４１００）はメールサーバやｗｗｗサーバの機能が設定されたホストであるものとしてもＴ’（４２００）はメールサーバやｗｗｗサーバの設定はされていないホストであるか、仮に設定されていたとしてもＴ（４１００）の設定とは違う内容である為に、Ｓ−２（５３００）からは、Ｔ（４１００）が正常でない状態（障害発生中）にあるように見えてしまう。
図１２。この問題は、インターネット上の各プロバイダのＤＮＳ（４５００や５５００等）が、キャッシュの生存時間が過ぎ、Ｄ（１０００）に再度、名前問合せをおこなえば、収束される問題である。その為に、時間が経過するにしたがって、図１２のような正常な状態となる。
次に、図０１乃至図０５および図１３乃至図１４に回線断後、Ｔ（４１００）が再接続しない（回線断のままの）場合について、時間の経過とともに正常に復帰する通常の場合（図０１乃至図１２）と同様に、紙芝居形式で説明する。
この場合に、考えられる理由は回線障害や（ダイヤルアップをする、あるいはダイナミックＤＮＳ更新する）プログラムの障害等である。
図０１乃至図０５までは、前述の説明と同じである。次に（図０６乃至図１２はキャッシュ問題の説明であるため、とばしていただきたい）、
図１３において、この時、Ｔ（４１００）はインターネットへ接続されていない状態のためＰ（４０００）は、Ｔ（４１００）にＩＰアドレスが変化するまで割当てられていたＩＰアドレス（仮に１７２．１６．１００．１００）をＴ’（４２００）がダイヤルアップした時点で、Ｔ’（４２００）に割当てる。
図１４。Ｄ（１０００）に設定されているＴ（４１００）のＩＰアドレスは、更新そのものが出来ない為に、切断前のＩＰアドレス（仮に１７２．１６．１００．１００）が設定されている。その為に、やはりＴ’（４２００）がＴ（４１００）と誤認されてしまう。
ところで回線断は、Ｔ（４１００）において検出可能なイベントであると同時に、外部環境の変化でもある。
表０１は、Ｔ（４１００）における、Ｔ（４１００）の状態と割当てＩＰアドレスの関係からの障害のパターンである。
2004059925.tif 000003
パターン１は、回線断のままの場合である。Ｔ（４１００）が回線断後再接続出来なかった場合には、回線断以前に割当てられていたＩＰアドレスがＴ’（４２００）に割当てられている場合に、誤認となる。割当てられていなかった場合に、アクセス不可となる。アクセス不可とは、目的ホストであるＴ（４１００）に到達せずに見失われた状態である。回線断のままの場合は、ＤＮＳ（４５００や５５００等）への再更新を、Ｔ（４１００）は当然することが出来ない。
パターン２は、ＤＮＳへのダイナミックアップデートに失敗した場合である。Ｔ（４１００）のダイナミックアップデートに係る部分のプログラム障害やＤ（１０００）の障害等によって起こる。この場合において回線は、接続されているか、切断されても再接続されているものとする。この時の動作は、パターン１のＴ（４１００）が回線断後再接続出来なかった（回線断のまま）場合と同様に、回線断以前に割当てられていたＩＰアドレスがＴ’（４２００）に割当てられている場合に、誤認となる。割当てられていなかった場合に、アクセス不可となる。また、割当てＩＰアドレスが変化しなかった場合には、Ｓ−２（５３００）からの通信には問題がない為に、正常であるようかのようにみえる。
パターン３は、回線断後再接続した場合である。キャッシュの生存時間の影響を受け、網掛け部分はキャッシュの生存時間の影響を受ける部分であり、それ以外は、キャッシュされていない為に、名前問合せがうまく行っている場合である。ここでＴ（４１００）にアクセスしてくるＳ−２（５３００）は、インターネットの一般的な利用者であるため広域的に拡散して存在している。このとき、個別の各Ｓ−２（５３００）が以前に名前参照したことがあるか、あればキャッシュされている間の名前参照であったかによって、網掛け部分に含まれるか否かが決定される。
表０１において、網掛け部分は、Ｔ（４１００）が回線断後再接続し、Ｄ（１０００）への更新も成功している場合における、Ｔ（４１００）の動作としては正常であるにも関わらず、ＤＮＳ（４５００や５５００等）がＴ（４１００）のＩＰアドレスをキャッシュしている為に、Ｔ（４１００）が一時的に障害状態にあるように見えてしまうタイミングである。
以上に、キャッシュというメカニズムが逆にＴ（４１００）のＩＰアドレスの変化に追従できない等のうまく合致していない部分があることを説明してきた。
この問題はダイナミックＤＮＳの仕組が旧来のＤＮＳへの拡張であり、後付けされたものである為に、発生する。
前記した通り、旧来ＤＮＳは手動で設定および更新されていた。Ｄ（１０００）を利用した場合には、Ｔ（４１００）からＤ（１０００）への更新の間隔が短い場合に、Ｄ（１０００）を参照（正引き）して得られたＴ（４１００）のＩＰアドレスは必ずしも正しいとは言えない場合があり得ることを説明してきた。
キャッシュの生存時間経過後、Ｄ（１０００）へ名前問合せするタイミングに比して、Ｔ（４１００）の回線断およびＩＰアドレス更新の間隔が短すぎると、Ｓ−２（５３００）は常にＴ’（４２００）をＴ（４１００）と誤認することになる。回線の不安定を原因とするこのような場合にも、ＤＮＳとしては機能することが望まれるが、Ｄ（１０００）としてはこの場合において、機能し得ず一種の障害状態とみなし得る。
これはＤＮＳをめぐるインターネット全体の問題であり、個別の実装等によって（個々のホストが対応するだけでは）解決することができない問題である。
キャッシュ問題の実例
以下に、キャッシュ問題の実例を示す。
図１９乃至図２１にキャッシュの生存時間の為に、キャッシュされたＤＮＳ（４５００で計測）を参照する場合とＤ（１０００）から直接正引きした場合とで、Ｔ（４１００）のＩＰアドレスが違っている実例を示す。
図１９に実際に計測した際のプログラムを示す。本プログラムはＵＮＩＸのシェルスクリプトである。行末の矢印（−＞）は表示の都合上折り返されているだけで、本当は１行であることを示している。
図２０乃至図２１に計測結果を示す。各試行は、１行目が試行番号、２行目が試行した時間を示し、３行目がインターネットワーキングにおいて標準的なＤＮＳの実装であるＩＳＣ版ＢＩＮＤのｄｉｇコマンドがＤ（１０００）を参照した結果に文字列処理を施し、Ｔ（４１００）のＩＰアドレスを抽出したもの（ａ、ｃ、ｅ）であり、４行目から６行目までがｐｉｎｇコマンドがキャッシュされたＤＮＳであるところのＰのＤＮＳサーバ（以下、「Ｐ−Ｄ」とする）（４５００）を参照した場合のＴ（４１００）のＩＰアドレス（ｂ、ｄ、ｆ）である。（註：Ｐ−Ｄ（４５００）はＴ（４１００）が通常参照するところのＤＮＳサーバである。ここではＴ（４１００）において試験した為にＰ−Ｄ（４５００）を参照したが、Ｓ−２（５３００）において試験する場合にはＰ−２−Ｄ（５５００）を参照するべきである。各端末において参照されるＤＮＳは、リゾルバによって決定される）なお７行目から１０行目は前記ｐｉｎｇコマンドの付帯する出力である。
試行に用いたＤＮＳサーバは、既にダイナミックＤＮＳサービスを提供しているＤｙｎＤＮＳ．ＯＲＧをＤ（１０００）として用いた。試行時において、このサーバのキャッシュの生存時間の設定は１分である。なお、この１分という値はきわめて短い。
第１回目の試行と同時にＴ（４１００）からの更新要求を送信し、第１回目の試行と第２回目の試行の間に更新が完了している。そのため、第２回目の試行から前記ｄｉｇコマンドの出力（Ｄ（１０００）が示すＴ（４１００）のＩＰアドレス）とｐｉｎｇコマンドの出力（この試験ではＰ−Ｄ（４５００）を参照したが、Ｐ−Ｄ（４５００）はキャッシュの生存時間の影響を受ける）は、それぞれ、別のＩＰアドレスを示している（下線部ａ＝下線部ｂから下線部ｃ≠下線部ｄへと変化）。
これが収束（下線部ｅ＝下線部ｆ）するのは、第１６回目の試行である。この時、第１６回目の試行は第２回目の試行からちょうど１分後に試行されている。
このように、キャッシュの生存時間の影響により、どのＤＮＳを参照するかによってアドレスのずれが生じている。しかし時間の経過とともに収束している。Ｄ（１０００）のキャッシュの生存時間は１分と短いが、それでもこのようなずれは生じる。
一般的な誤解
ところでここまでの説明に反して、ダイナミックＤＮＳ特有の問題はあまり一般には知られておらず、特許出願においてすら以下のような誤解がある。
例えば、特許文献３の段落００４７において、「ｎｓｌｏｏｋｕｐの回答が異常になる」とある。
しかし、これは異常にならない。
なぜならば、
１、ｎｓｌｏｏｋｕｐした返事はエラーではない。特許文献３には、エラーでないにも係らず異常であると判断できる根拠は示されていない。
２、ｎｓｌｏｏｋｕｐ問合せに対してＤＮＳが返すものは、仮に、Ｔ（４１００）のプレゼンスが失われているとしても（またＴ’（４２００）が使用しているにしても）、最終更新されたＩＰアドレスである。（キャッシュされたＩＰアドレスである場合がある。問合せ先ＤＮＳに依存する。しかし、いずれの場合でも問題がある）
この場合、単純に異常であるとすることはできず、アプリケーション的な比較判断が必要である。すなわち、ここでＤＮＳが返すＩＰアドレスが異常であることを検出する為には、まず到達性確認等によって、ＤＮＳがポイントするＩＰアドレスがＴそのもの（４１００）によって使用されているかＴでないホストすなわちＴ’（４２００）によって使用されているかを判別することができて、はじめて異常かどうかがわかるのである。
Ｔ（４１００）による明示のオフライン処理があった場合も同じである。この場合は、Ｔ’（４２００）を生じさせないという効果はあるにせよ、やはりｎｓｌｏｏｋｕｐした返事はエラーではない為に、設定されたＩＰアドレスに対してアプリケーション的な比較判断が必要である。また、Ｔ（４１００）障害時や回線障害時には、オフライン処理等は一般にされないので、注意が必要である。
ここで仮にＳ−２（５３００）もしくは管理サーバ（以下、「Ｓ−１」とする）（２０００）が、Ｔ（４１００）の従前のＩＰアドレスを記憶しておいた場合も、従前のＩＰアドレスとｎｓｌｏｏｋｕｐした返事としてのＩＰアドレスを比較すれば、ＩＰアドレスの更新がされたことを知ることができる。しかし、それが現在の状態を反映しているかどうかについては、知る事ができない。この理由は、前記２による。キャッシュ問題の影響も受けるが、この場合はＴ（４１００）がＤ（１０００）に対する更新処理ができない場合（例：回線断が継続している場合や更新プログラムの障害の場合等）には、Ｄ（１０００）がＴ（４１００）のＩＰアドレスとして返す値は、あてにならないことによる。つまり既にＴ（４１００）が使用していないＩＰアドレスを返すおそれがある。
ただし、特許文献３では、Ｔ（４１００）そのものがｎｓｌｏｏｋｕｐした返事を自ホスト（Ｔ（４１００）：特許文献３では分散サーバ３）のＩＰアドレスと比較しているようにも読み取れる。その場合は、ｎｓｌｏｏｋｕｐした返事が異常であるとの判断は可能である。単に自ホストのＩＰアドレスとｎｓｌｏｏｋｕｐした結果を比較（ただし後述する接続形態１乃至３の場合のみ可能）しているためである。しかし、分散サーバ３を除くすべてのホストにとって、異常かどうかを知ることができない。すなわち分散サーバ３のみが知る事ができる。しかし分散サーバ３に相当するＴ（４１００）が自己に割当てられたＩＰアドレスを知ることができるのは、むしろ自明である。本発明ではＳ−２（５３００）において、Ｔ（４１００）に正しく到達しているかどうかを確認できるようにすることがテーマである。
なお更にいえば、分散サーバ３は、わざわざｎｓｌｏｏｋｕｐするのではなく、単に自らに割当てられたＩＰアドレスの変化をトリガとしてＩＰアドレス更新依頼メールを動的ＤＮＳサーバへ送信した方が、妥当する。
また、特許文献３の段落００４８において、「例えば、ＩＣＭＰ（Ｉｎｔｅｒｎｅｔ  Ｃｏｎｔｒｏｌ  Ｍｅｓｓａｇｅ  Ｐｒｏｔｏｃｏｌ）の回答がなくなる」とある。
しかし、「回答がなくなる」とはいえない。この場合は不定である。
ＩＣＭＰはＩＣＭＰエコー要求のことだと思われる。これはコマンド実装に由来して、通常ｐｉｎｇと呼ばれる。
タイミングの問題であるが、仮にＴ（４１００）が回線断に陥った直後に、Ｐ（４０００）がＴ（４１００）からでない接続要求を受ければ、直前までＴ（４１００）が割当てられていたＩＰアドレスを割当てられる可能性は高い。すると、Ｔ’（４２００）が出来上がる。するとｐｉｎｇは、Ｔ（４１００）は生きていることを示す。
よって、「回答がある」場合がある。
例えば、キャッシュ問題の実例の図２０に示す試行回数２の場合である。図２０中のｃとｄが異なった値を示すことに注目されたい。
試行回数１と試行回数２の間にＴ（４１００）は、図０４の状態（正常）から図０５（切断）、その後再接続して、図０８の状態にいたっている。図０９に示す別のユーザがダイヤルアップした場合に、Ｔ’（４２００）が出来上がる。Ｔ（４１００）がＴ’（４２００）にすり替わって、かつＤＮＳを正引きしてもＩＰアドレスの変化がないためである。当然にＴ’（４２００）から「ｐｉｎｇの回答がある」。タイミングさえうまく合えば、ｐｉｎｇの回答は、途切れることなくＴ’（４２００）に引き継がれるだろう。
そして、「ｐｉｎｇの回答がある」からといって、Ｔ（４１００）（特許文献３では分散サーバ３）が正常であるとはいえない。
前記の場合は、Ｔ（４１００）が復帰した時点でＤＮＳ更新する為に、キャッシュ問題を考慮しても、時間の経過に伴ってやがては収束される。しかし、最も問題となるのは、Ｔ（４１００）が図０５の状態のままであって、図０６以降の状態に移行する事ができなかった場合（障害）である。キャッシュの問題とは異なり、図１３で別のユーザがＴ’（４２００）に化けたが最後（図１４）、Ｔ’（４２００）からのｐｉｎｇの回答を受取って、Ｔ（４１００）が正常だと判断し続けることになる。
以上から、
ビデオカメラによって、撮影された動く物体が仮に大きさまで判ったとしても、それが犬なのか人間の子供なのか、あるいはボールなのかは機械には識別できない。
しかし、この映像を人間が見れば上記のいずれであるかは、見た瞬間に判別できる。
同様に、ｎｓｌｏｏｋｕｐやｐｉｎｇ等では、上記問題は解決され得ず、正常に見える（特許文献３では、これを異常であることが分かるとしている）。
これは、通信の相手方が、Ｔ’（４２００）であった場合に、例えば、Ａさんのウェブページを見に行ったはずなのに、Ｂさんのウェブページが表示されれば、明らかに間違いであることが、人間には見た瞬間に判別できるが、機械にはそれが誤っていることが、分からないという問題である。
よって、到達性確認なしに、正しい到達性を有するＴ（４１００）と、そしてＴと誤認されたホストであるところのＴ’（４２００）との区別をつけることは、機械にはできない。
以上によって、一時的に動的なＩＰアドレスを割当てられたホストにおいては、ホストの動作としては正常であったとしても、障害状態に見えてしまう等の問題があり、ダイナミックＤＮＳの出現によって解決されたかに見える発呼すべき相手先識別は十分とはいえない状況にある。
ダイナミックＤＮＳ特有の問題点のまとめ
ここで、ダイナミックＤＮＳ特有の問題点をまとめてみる。
まとめ１。Ｄ（１０００）は、Ｔ（４１００）が接続されなくなった後も、最終更新されたリソースレコードをアナウンスし続ける。Ｔ（４１００）からの明示のオフライン処理等がされれば、存在しないＴ（４１００）に関する情報をＤ（１０００）がアナウンスし続けることはない。しかし、Ｔ（４１００）の障害時や回線断の際には、オフライン処理をすることができない。
まとめ２。Ｔ（４１００）のＩＰアドレスが変化した場合に、キャッシュの生存時間内は誤認される。
拡大された先行技術の範囲
ここまでは、ダイナミックＤＮＳに関して、あて先端末を発見する過程における不備について見てきた。しかし同様の問題は、ダイナミックＤＮＳのみに限らずおこりうる。例えば、特許文献１や特許文献２、ＥＮＵＭ等である。
このうち、ＥＮＵＭに関しては、ダイナミックＤＮＳの拡張であって、従来の電話網（ＰＳＴＮ）における電話番号体系をＤＮＳ上にマッピングするものである。
特許文献１は、ユーザ・ロケーション・サーバなる概念が附加されているが、ＥＮＵＭと類似のものと考えてよい。
特許文献２は、ＤＮＳを用いずに、替りにホストを特定する静的な識別子と動的に割当てられた住所に対する特定のマッピング公示システムが提案されている。
ダイナミックＤＮＳ特有の問題点のまとめの１に挙げた「Ｄ（１０００）は、Ｔ（４１００）が接続されなくなった後も、最終更新されたリソースレコードをアナウンスし続ける」ことが、誤認を生じさせる原因であるので、特許文献１および特許文献２に関しては、これを解決する特定の方法を開示している。曰く、特許文献１では、端末側からＤＮＳへキープアライブ信号を送信することによって、生存していることを通知している。特許文献２は、ＤＮＳを用いないながらも、ＤＮＳ相当側からＴ相当側に向かってヘルスチェックを行い、Ｔ相当が接続されない状態になったことを検出している。
いずれの場合も、端末が網上に存在しなくなった場合に、マッピング公示システム上の該当するレコードを消し込むことによって、発信元端末がそもそもあて先端末を発見しないようにしている。
しかし、いずれの場合も、第三者端末ＳからのＴ（４１００）への到達性の正しさ（エンド−エンドでのアクセス可能性）は、検証されない。
【発明が解決しようとする課題】
Ｓ−２（５３００）がＴ（４１００）だと認識していたとしても、実際には別の無関係なホストであり得る。そこで、Ｔ（４１００）だと認識されているホストとして本当に正しい通信相手であること、すなわち、Ｔ’（４２００）に到達しているのでなく、あて先たるＴ（４１００）に対して正しく到達していることを確認する手段を提供する。
あわせて、前記到達性確認の結果をどのように利用するかについて、提案する。
【発明の効果】
固定的なＩＰアドレスを与えられたＴＣＰ／ＩＰ網上のホストの管理は、通常であれば機器監視としてｐｉｎｇコマンド等を利用してホストの活死を監視することができる。しかし、ダイヤルアップのホストにあっては、そのＩＰアドレスが変化することから、ｐｉｎｇによる管理では、誤った（Ｔ（４１００）でない）ホストがｐｉｎｇに応えていても、正常に稼動していることになってしまう。本発明では、Ｔ（４１００）が正しい到達性を有するホストであることを確認するようにして、これまで管理することのできなかったＩＰアドレスの変化するホストを、管理できるようにした。また、通常の管理をおこなう場合にも、従来であればＩＰアドレスが変化するホストは管理することができなかったが、通常の管理の前段の処理として本発明を用いることによって、その後のより高度な管理（例えば、ＣＰＵ負荷やトラフィックの監視）をも可能とした。
（概要）
Ｔ（４１００）だと認識されている通信相手に本当に正しく到達していることを確認する手段は、以下の方法で以って確認する。ここではＳ−１（２０００）からＴ（４１００）に対して通信をした結果から、Ｔ（４１００）が正しい到達性を有するホストであるかどうかの判定を、Ｓ−１（２０００）がする。
課題を解決するための手段は、以下の２の段階による、外部的なホスト間通信の過程によっておこなう。
第一の段階はアドレス確認であり、
第二の段階はサイン・アンド・カウンターサインである。
図２３に、第一の段階および第二の段階によって、Ｓ−１（２０００）がＴ（４１００）の到達性確認をおこなう場合の動作を示す。
アドレス確認は、第一の段階であって到達性確認のためのパラメータの対のうちの一を形成する（後述する通信モデルを参照）。
Ｓ２０２において、Ｓ−１（２０００）からキャッシュの生存時間の問題を避ける為に、Ｄ（１０００）に対して名前問合せ（正引き）をする。
Ｓ２０４において、Ｓ２０２の返事からＴ（４１００）のＩＰアドレスを得る。
なお、Ｔ（４１００）のＩＰアドレスの確認は、Ｓ−１（２０００）とＤ（１０００）が同一のホストである場合かＳ−１（２０００）のリゾルバがＤ（１０００）を向いている場合や、Ｄ（１０００）のＴＴＬ（キャッシュの生存時間）の設定が極めて短い場合等は、省略することができる。
また、Ｄ（１０００）には冗長化された場合があるが、ここでは単に冗長化されたサーバ群を以って、単一のサーバと同じだと考えて差し支えない。
サイン・アンド・カウンターサインは、第二の段階である。
アドレス確認が省略できる場合があることから、狭義の到達性確認でもある。
Ｓ２０２およびＳ２０４でＴ（４１００）のＩＰアドレスが得られたこの時点では、Ｔ（４１００）が正しく認識されたとおりのＴ（４１００）であるかどうかは、未だ確認されていない。Ｔ（４１００）とＰ（４０００）間の回線断やＤ（１０００）に対してＴ（４１００）が更新することができない場合等では、到達性確認の過程を通じて、Ｔだと思われたホストが正しい到達性を有していないことが初めて判明する。また、Ｔ（４１００）において提供されているサービスがあらかじめわかっていたとして、このサービスに正常にアクセスできない場合も、キャッシュの影響と言い切ることはできず、単にそれだけでＴ（４１００）が網から断たれた状態にあるとは、判断できない。例えば、Ｔ（４１００）がＰ（４０００）に正常に接続されておりかつＤ（１０００）への更新も正常にされている場合であって、かつキャッシュの問題も発生していない場合であってなお、サービスを提供するプログラムに障害がある場合が考えられるからである。網管理的な考え方としては、Ｔ（４１００）がインターフェース障害や回線断等の網的な障害（根本的な障害）に陥っているのか、あるいはサービス障害（アプリケーションレベルの障害）なのかを切分けたいところである。ここで、障害切分けは低レイヤからするのが定石である。そこでこの時点では、とりあえずＴ（４１００）だと思われるホストに対して通信を試み、その結果から本当にＴ（４１００）なのかどうかを判別することによって、まず網的な障害の有無を確認することとする（詳しくは後述する設計思想を参照されたい。ここでは、とりあえずＴ（４１００）のインターフェースまで到達できるかどうかを確認したい）。
Ｓ２０６において、Ｓ−１（２０００）からアドレス確認Ｓ２０２およびＳ２０４の結果から求められたＴ（４１００）のＩＰアドレスに対して、あらかじめ合意された方式での通信（これを「サイン」という）をおこなう。
Ｓ２０８において、Ｓ２０６の返事（この返事の内容を「答えるべき返事」といい、この返事を運搬するものを「カウンターサイン」という）の有無を判断し、返事があればその返事をＳ２１０に受渡し、返事がなければＴ（４１００）が見失われている旨を表示するＳ２１６へ進む。
Ｓ２１０において、Ｓ２０６の返事を受取り、この返事に対して、文字列処理をして、不要な文字列を取除いた文字列を求める。
Ｓ２１２において、Ｓ２０８で抽出された文字列とＳ−１（２０００）に記憶されたあらかじめ合意された方式での通信に対してＴ（４１００）からの答えられるべき返事とを比較する。
ここで、Ｔ（４１００）が答えるべき返事とＳ−１（２０００）が受取るべき返事は同じ物であることが合意されている。
あらかじめ合意された方式での通信に対する答えられるべき返事と一致した場合は、Ｔ（４１００）は正しい到達性を有している。
一致しない場合は、キャッシュの生存時間の問題とは無関係に、Ｔ（４１００）はインターネットに接続されていないか何らかの問題でセンタ側ＤＮＳに対する更新が出来ない状態にある、との判定をおこなう。
判定の結果を表示する。Ｓ２１２の判定によって、Ｔ（４１００）が正常稼動しかつ正しい到達性を有するＴ（４１００）であることが確認された場合Ｓ２１４か、あるいは障害状態であることが確認された場合Ｓ２１６かに分けられる。この判定結果を受けてどうするかは、Ｔ（４１００）の運用責任者と到達性を確認する者との契約に基づくべきものであるため、ここでは単に結果の表示とする。Ｔ（４１００）が正常稼動しかつ到達性が正しい場合Ｓ２１４では、従来は監視不可能であったＩＰアドレスが変化するホストに対して、トラフィック監視等の通常の監視に後続させることができる。一般的には、Ｓ２１４の場合には正常である旨のみをログに書出す等してあえて通知せず、Ｔ（４１００）が正常でない状態の場合Ｓ２１６は、アラートをあげる等の状態を通知する処理に進むのがよい。Ｓ２１６の場合、Ｔ（４１００）がＤ（１０００）を更新したタイミングと重なった場合等に、Ｄ（１０００）が更新を反映するのに遅延が生じる可能性を考慮して、やや時間をおいて再度本プロセスを実行しそれでも障害が検出されるのを待った後、初めてアラートをあげるのか、あるいは誰にどのような方法でアラートをあげるのかを考慮するとよい。
カウンターサインの本質
次に、到達性確認とは、何かについて述べる。例えばＴ（４１００）において公開されているウェブページを見た場合、人間であれば、それがＡさんのウェブページであるのかＢさんのウェブページであるのかは、容易に識別がつく。分かり易くいえば、Ａさんのウェブページを見に行ったはずが、Ｂさんのウェブページが表示されれば、Ｔ’（４２００）であり（もちろんＢさんのウェブページが表示されるのではなく、単にタイムアウトするまで待たされた挙句、エラーになった場合でも同じ）、Ａさんのウェブページが表示されれば、相手先は正しい到達性を有するＡさんのウェブページである。このように人間が見れば即座に判別できる。ところが、前記した通り、機械にはそれを識別することができない。これを機械（＝通信ノード）にも識別できるようにすることをいう。
到達性確認の結果は、真偽で表される。結果が真の場合とは、正しい到達性を有する場合である。真性のホスト等と表現されることもある。結果が偽の場合とは、正しい到達性を有しない場合である。
では、ここで仮にＴ（４１００）が固定的なＩＰアドレスを割当てられていた場合はどうであろうか？
１、前記同様、ウェブページの例のように、もちろん人間が見ればわかる。いわゆる人間による目視確認である。
仮に見てわからなくても、調べればわかる。このとき、大体次のようなことを調べる。
２、ｎｓｌｏｏｋｕｐでもわかる。ｐｉｎｇでもわかる。
３、ホストそのものが名乗るので、わかる。ただし、ここでホストが名乗るとは、サービスと呼ばれる通信プログラム（以下、この通信プログラムを「Ｄａｅｍｏｎ」と呼ぶこととする）を経由して、名乗ることとする。また、従来は、ここで名乗った返事を聞いた通信の相手方が、それに基づいて特別なアクションを起こすことはなかった。ここで特別なアクションとは、例えばそれによって接続の許可拒否を判断する等である。
４、アカウントがあれば、パスワード認証を利用することもできる。
さて、本発明の前提であるＴ（４１００）がダイヤルアップのホストである場合に戻るとしよう。
１については、到達性確認の目的は人間だけでなく機械にもわかるようにすることなので、ここでは考慮しない。
２のｎｓｌｏｏｋｕｐは、既に説明した通り、本当に正しい相手先かどうかが不明なままである。ｐｉｎｇも同じである。
４は、サーバにおけるアカウントの問題である。本発明は相手先サーバ（あるいはホスト）にアカウントがあることを前提としていない。そのため、アカウントがあることを前提としての認証については、別論である。
さて、では、３はどうであろうか？
Ｄａｅｍｏｎは通信ポートを開けて接続を待つ常駐型のプロセスのことであるが、だいたいホスト名、プログラム名、バージョン名等を名乗るものである。
よって、３は使うことができる。
これは、Ｔ（４１００）が固定ＩＰアドレスの場合には、当然に通信の開始時点において、行なっていたことである（ただしこれを元に通信をするかしないかを判断することは、従来はされていない）。
ここでホスト名に対するアクセスに対して、Ｄａｅｍｏｎが名乗るということは、単に自己の識別情報を示しているに過ぎない。
これは認証という概念には含まれないものである。
そして、単に名乗るだけで到達性確認はできる。
すなわち、到達性確認とは、
サインとして、「Ｗｈｏ  ａｒｅ  ｙｏｕ？」とたずね、
答えるべき返事として、「私は誰某です」と、答えさえすればよいのだ。
よってカウンターサインの本質とは、当然に名乗るべき自己の識別情報を名乗るためのキャリアである。
そしてサインとは、Ｔ（４１００）に名乗らせる為にどのように尋ねるかという取決めである。
ここで、ダイナミックＤＮＳ亦は静的な識別子と動的な住所が関連付けられることがある程度普及したことによって、初めて気付かされた、網の新たな特性について説明する。
静的な識別子と動的な住所の関連付けにおける一方向性
Ｄ（１０００）で利用できるのは、一般に正引き名前解決のみである。
逆引き名前解決をした場合には、ＩＰアドレスに対して、ダイナミックアップデートされるべきホスト名を返さない。
では、何を返すか？
一般にＩＰアドレス割当を受けた当該アドレスブロック（ＣＩＤＲブロックを含む）の網を運営する網運営主体の設定したホスト名を返す。この表現はわかりにくいかも知れない。代表例としてインターネット接続業者（＝Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ。以下、「ＩＳＰ」とする。ＩＳＰはＰ（４０００）の一形態である）のホスト名が挙げられる。
以下に例を示す。
正引きｈｏｓｔ．ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐ−＞１９２．１６８．０．９９
逆引き１９２．１６８．０．９９−＞ｐｐｐ００００９９．ｏｔｅｍａｃｈｉ．ｐｒｏｖｉｄｅｒ．ｃｏｍ
正引きｐｐｐ００００９９．ｏｔｅｍａｃｈｉ．ｐｒｏｖｉｄｅｒ．ｃｏｍ−＞１９２．１６８．０．９９
となって、ｈｏｓｔ．ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐは隔絶されている。すなわち、ｐｐｐ００００９９．ｏｔｅｍａｃｈｉ．ｐｒｏｖｉｄｅｒ．ｃｏｍが誤認されたホストである場合に、ｐｐｐ００００９９．ｏｔｅｍａｃｈｉ．ｐｒｏｖｉｄｅｒ．ｃｏｍは、ｈｏｓｔ．ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐというホスト名を知ることができない。
ここで、
ｈｏｓｔ．ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐは、Ｔ（４１００）がＤ（１０００）に対して更新するホスト名、
１９２．１６８．０．９９は、Ｔ（４１００）がその時点で割当てられているＩＰアドレス、
ｐｐｐ００００９９．ｏｔｅｍａｃｈｉ．ｐｒｏｖｉｄｅｒ．ｃｏｍは、前記ＩＰアドレスに対して逆引きして得られるホスト名であって、ＩＳＰが名前を付けたものである。
この理由は、以下のとおりである。
委任（＝ＤＮＳ  ｄｅｌｅｇａｔｉｏｎ）（ＤＮＳ  Ｒｅｖｅｒｓｅ  Ｄｅｌｅｇａｔｉｏｎに関連するものとして、ＲＦＣ２０５０、２３１７、３１５２等がある）の前提に反するので、つまり、管理権限の問題として、他人（他の組織）が管理する網への逆引きを設定することができないということである。例えば、Ｄ（１０００）の所属する網と、Ｐ（４０００）の網が異なる組織によって運営管理される場合において、Ｄ（１０００）はＰ（４０００）に対する逆引きを設定することができない。
ところが、ｈｏｓｔ．ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐは、Ｓ−２（５３００）からアクセスを受付ける為に、Ｔ（４１００）の所有者が、広くアナウンスするものである。
すなわち、このｈｏｓｔ．ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐなるホスト名は正引きの際に使用される周知のキーワードでありながら、逆引きでは知ることができないという特徴を有する。
Ｔ’（４２００）がサインを受付けとった場合には、静的な識別子と動的な住所が関連付けられることによってホスト到達性が得られる網の特性から、発信元があて先として何というホスト名を指定していたかを知ることはできない。
偽装
ただし、そうでない場合がある。例えば、あて先ポートがＨＴＴＰの場合等は、セション確立時にはホスト名は当然に含まれないが、その後のＧＥＴ命令等にあて先（閲覧者が見たいと思っている）ホスト名が含まれる場合がある。そのような場合には、ＧＥＴ命令以下に含まれるホスト名を抽出し、オウム返しにするプログラムを誤認されるおそれのあるホストに実装すれば、答えるべき返事、そしてこれをキャリーするカウンターサインを偽装できる。これは、受動的攻撃である。
偽装された場合の影響範囲
しかし、現実的ではない。なぜならば、
偽装しようとする場合には、誤認されたホストＴ’（４２００）へのアクセスをひたすら待つ必要があり、
仮にこのような偽装が成功したとしても、Ｔ（４１００）の割当ＩＰアドレスが次に変化したタイミングで、追従することができなくなるからである。
このことから、Ｔ（４１００）の割当ＩＰアドレスが変化しない間を限度として、偽装が成立する。
そのため、Ｄ（１０００）への更新処理をのっとらない限りは、あまり効果がない（偽装できたとしても、長くは続かない）ことになる。すなわち更新処理をのっとった場合のみ、完全にそして誤認なく偽装することができる。ただしこの場合は、既に偽装ではない。
そして、カウンターサインは更新の際に用いられるパスワードとは、関係がない。
よって、Ｄ（１０００）への更新処理は守る必要のある通信である。
偽装される場合はこんなとき
まず、誤認が発生する必要がある。誤認されたホストＴ’（４２００）でなければ、偽装することができない。
偽装したホストＴ’（４２００）は、サインを受取った際にＴを名乗る「答えるべき返事」をキャリーするカウンターサインを返すことによって偽装する。
ここで、Ｔ’（４２００）はＴ（４１００）と同様にＰ（４０００）からＩＰアドレスを割当てられる。そして、Ｔ’（４２００）のＩＰアドレスはＴ（４１００）と同様に変化し得るものである。このことから、以下のことがいえる。
Ｔ’（４２００）は、Ｔ（４１００）と同様にＰ（４０００）配下のアドレス範囲に属する。すなわち誤認され得る範囲はあらかじめＰ（４０００）のＩＰアドレス範囲によって制限されている。しかし、この制限は、網のありようから決定されるものであって、なんら人為的な制限ではない。
Ｔ’（４２００）は、Ｔ（４１００）と同様にＰ（４０００）から一時的に割当てを受けた住所であるところのＩＰアドレスを使い続けることができない。そのため、仮に偽装された場合であっても、偽装したホストＴ’（４２００）は、いつまでも偽装し続けることができない。
偽装が成立する場合は以下の通りである。
基本的には、キャッシュの問題を除けば、Ｔ（４１００）が障害状態に陥った場合にのみ偽装可能である。その上で、偽装が成立する期間は以下の通りである。
Ｔ’（４２００）のＩＰアドレスが変わらないあいだ
Ｔ（４１００）が復帰して、再度更新するまでのあいだ
以上のことから、前記偽装される場合はありうるが、しかし影響範囲は許容されるものとして扱う。
ただし、サインとして「あなたは誰？」といった単に応答をうながすのが推奨されるのであって、「あなたは誰某ですか？」のように偽装し易い状況を作るサインは、推奨されない。誰某の部分には、具体的な名前等が入るものとする。
到達性確認独立の効果
到達性確認と更新の乗っ取りについて比較してみた。以上から、到達性確認は守る必要がないといえる。
到達性確認と更新とは、直接の関係を有しない独立した過程である。
そして、到達性確認はアカウントに対するパスワードといったものではない。
これが、到達性確認独立の効果である。
（理論）
１、通信モデル
登場人物一覧
まず、本発明において特別な意味を持つ「値」を示す。
Ａ：動的な住所（＝ｎｅｔｗｏｒｋ  ａｄｄｒｅｓｓ）
網のための値であって、端末への実際の到達性を司る住所
Ｐから一時的に割当てられる
Ｂ：静的な識別子
ヒトのための値であって、あて先端末を特定するための識別子
次に、機能を示す。
Ｄ：マッピング公示システム
発信元が通信を開始しようとする時に、静的な識別子と動的な住所を対応づけて参照させることによって、あて先端末への到達性を発信元に提供する
Ｔに替わって、組Ａ：Ｂを公示するもの
Ｔ：あて先端末
本モデルにおいてあて先となる端末
Ｄに対して組Ａ：Ｂが関連することを設定するものである
計算機である必要はなく、通信ノードでありさえすればよい
Ｓ：発信元端末
Ｔをあて先とする場合の、Ｔへの到達性の正しさを確認する端末
Ｔに対して、到達性の正しさを確認する
計算機である必要はなく、通信ノードでありさえすればよい
Ｐ：Ｔに対して、一時的な住所であるところのＡを割当てる機能
一般に網の場合と特定のサーバの場合がある。
電話会社的な考え方をすれば、Ｔを内包する網そのものである。（電話会社の例でいえば、ＤＣＥはクロックを出す側、ＤＴＥはクロックを受ける側と考えられる。すなわちクロックは網そのものから受ける。これを援用して、例えばインターネット接続に係るＩＳＰの場合は、ＩＰアドレスを割当てるものは、ネットワーク・アクセス・サーバ（例：Ｌｉｖｉｎｇｓｔｏｎ  ＰｏｒｔｍａｓｔｅｒやＡｓｃｅｎｄ  ＭＡＸ等のこと）やＲＡＤＩＵＳサーバではなく、ＩＳＰの網そのものが割当てるものと考えられる）
ＬＡＮ的な考え方をすれば、ＤＨＣＰサーバ等がこれにあたる。
ここで、ＡとＢからなる組を「組Ａ：Ｂ」と表現する。
組Ａ：Ｂの実像
Ｔにおいて、ＢはＴ自らを示すことを公にするための識別子である。そして、Ａは、Ｐから一時的に割当てられた住所である。ここで、Ｂのみでは、Ｔから見た第三者であるところのＳからは、網的な到達性を有するものではない。Ａのみでは、網的な到達性は有しているものの、Ａは一時的にＴがＰから借受けて使用する住所であり、また、Ｔ以外の端末も利用するものであるから、第三者からはＴとＡを結び付けることができない。しかしながら、Ｂは本来的にＴを指し示すべく公示された情報であり、また、この時点において、ＡはまさしくＴに割当てられている住所である。この事実を以って、Ｔは組Ａ：Ｂの実体（以下、「実像」とする）を有するものとする。
組Ａ：Ｂの写像
マッピング公示システムＤは、Ｔによって組Ａ：Ｂが対応づけられたものであることを通知され、記憶し、第三者Ｓからの問合せに応答して、組Ａ：Ｂが対応づけられたものであることを問合せをする者に対して公示する。具体的には、ＡもしくはＢのいずれかについて問い合せを受けると、ＢもしくはＡのいずれか問合せを受けなかった方を応答するものである。また、別の観点からはＡもしくはＢのいずれかを入力とする場合に、組Ａ：Ｂの残る一方を出力するシステムともみなせる。ここで特徴的なのは、Ｔは公示することができないので、ＤがＴに替わって公示するということである。
このことから、Ｄにおいて公示されるのは、組Ａ：Ｂの写像である。
ところで、誤った到達性を持つ場合に、よくＴが誤っていてＤが正しい等とされるが、これは正しくない。
すなわち、ＤにおいてマッピングされるＡとＢの組が実状を反映していなければ、ＳはＴに到達することができない。
実状とは、Ｔにおける組Ａ：Ｂの実像である。
ＡとＢからなる組は、それぞれ個別に正しいとか誤っているということができないものであって、ＡとＢからなる組となって、そして、正しく実状を反映して、はじめてＳはＴに到達する事ができる。
逆に言えば、ＳからＴに対して正しく到達しない場合には、組Ａ：Ｂの実像を有するところのＴが正しく、組Ａ：Ｂの写像を公告するＤが誤っているというものでも、その逆でもない。すなわちいずれかが正しく、いずれかが誤っているという類のものではなく、両者が一致していることが重要なのである。
ここで、両者とは、Ｄが記憶するＴに関する情報の写像と、Ｔが保持するＢとＴがＰから与えられたその時点での被アクセス条件であるところのＡからなる情報の実像、すなわち組Ａ：Ｂの実像と写像である。
以下、単に実像あるいは写像とする場合であっても、「組Ａ：Ｂの」が省略されているものとする。
ここで、図２２を参照されたい。
（１）乃至（５）は、順序だった過程である。
（１）において、ＴからＤに対して、組Ａ：Ｂが写像される。
（２）および（３）によって、ＤＳ間の組Ａ：Ｂが検査される。
（４）および（５）によって、ＴＳ間の組Ａ：Ｂが検査される。
以下、単に（１）乃至（５）のいずれかを示したときは、図２２におけるものとする。
ここで、再度強調したいのは、Ｄにおける組Ａ：Ｂの写像と、Ｔにおける組Ａ：Ｂの実像が一致していなければ、第三者ＳはＴに到達することができないということである。
この理由は、組Ａ：Ｂの実像がＴであることは疑う余地のないことであるが、ＴやＤから見て第三者であるところのＳはそもそもＴを直接参照することができず、それゆえＳはＤの組Ａ：Ｂの写像を参照することによって、Ｔに対する到達性を得ている。
すなわち、Ｔは実像をＤのみに写像するものであって、第三者であるところのＳからＴが参照されることはない。
この理由は、Ｔは第三者Ｓから見てあて先にあたるので、Ｔを発見する為にまずＤを参照するのであるから、Ｔが発見できない時点でＴを参照することはできない。
ＳからＴへのアクセスが可能になるのは、ＳがＴを発見した後の話である。
よって、以下のようにすれば、発信元Ｓがあて先Ｔに正しく到達することが検証される。
（２）および（３）によって、検査されたＤＳ間の組Ａ：Ｂ（すなわち、組Ａ：Ｂの実体の写像）と（４）および（５）によって、検査されたＴＳ間の組Ａ：Ｂ（すなわち、組Ａ：Ｂの実体の実像）とが、一致すれば、発信元Ｓからあて先Ｔへの到達性は正しい。
２、シーケンス
ではどのようにして、組Ａ：Ｂの実像と写像が一致しているか否かを判定するのだろうか？
これには、シーケンスにおとして考えてみる必要がある。
再び図２２を参照されたい。
値ＡおよびＢの関係をシーケンスで説明する。
（１）ＴがＤに、組Ａ：Ｂの写像を作成する。
（２）ＳはＤに対して、Ｂで以って問合せる。
（３）ＤはＳに対して、Ａを応答する。
（４）ＳはＴに対して、（３）で得られたＡを用いて（Ｔであろうと思われるあて先に）問合せる。
（５）ＴはＳに対して、Ｂを応答する。（Ｔであろうと思われたあて先が、実は）Ｔでなかった場合には、不明な応答となる。ここでＴが応答しない場合は、応答がないという応答があったものとする。これも不明な応答に含める。つまり０という値はない訳ではなく、存在するとの考え方に基づく。以下、本明細書はこのような抽象化に基づいて記載される。
各シーケンスの内容を説明する。
（１）は、Ｔが組Ａ：Ｂの実像を、Ｄに写像する過程である。この結果、出来上がるものがＤにおける組Ａ：Ｂの写像である。この際、適当な第三者が適当なＴに対する嘘の組Ａ：Ｂを写像できないようにする為に、通常はＴＤ間では認証過程を要する。
なお、後に詳述するが、組Ａ：Ｂの実像は、Ｔ単体の場合のみでなく実施例８に詳述するＴと一体となった装置を含めた集合である場合がある。また、写像する主体は、ＤＨＣＰサーバやＩＳＰ等の場合（やオペレータＥＮＵＭ）等のＰがする場合がある。
（２）および（３）は、一連の手続きとしてセットで考える。一般的な表現でいうところの名前問合せに相当する。
（２）において、Ｄが組Ａ：Ｂのうちいずれかを入力すると残る一方を出力するシステムであることを利用して、Ｓは、周知のキーワードであるところの静的な識別子ＢをＤに名前問合せをする。
（３）では、（２）の結果として（１）で設定されたＤにおける組Ａ：Ｂの写像から、残る片方であるところの動的な住所であるところのＡを応答する。
ここまでの（１）乃至（３）の動作については、従来技術である。ここでは、（２）および（３）の動作をセットで、利用すべき自然現象（外部オブジェクト）として捉える。
（４）において、Ｓは、（３）で得られたＴに対する到達性を有するはずのＡをあて先として、単に何らかの応答をすることをうながす。Ａは（３）から（４）にいたる過程で、一時的に利用されるものであるので、単に代入されるだけでよくＳでは別段記憶する必要がない。（ただし、記憶した方がよい場合があるので、これを考察に説明する）
（５）は、組Ａ：Ｂのうち、残る方すなわちＢを応答する。応答されたもの、すなわちＳがＴから受け取った返事がＢであるならば、（２）でした最初の問合せと（５）の返事がオウム返しの関係にあるので、正しくＴに到達していることになる。なお、（４）でされた（何かを応答しろという）要求に対して、Ｔが不明な応答をする場合と峻別される。
これによってＳは、
（２）および（３）の過程から、組Ａ：Ｂの写像を、
（４）および（５）の過程から、組Ａ：Ｂの実像を、
知ることができる。
上記シーケンスの後、Ｓは、（２）および（３）の過程で得られた組Ａ：Ｂの写像と、（４）および（５）の過程で得られた組Ａ：Ｂの実像について、一致しているか否かを比較する。
なお、以下にタイミングについて説明する。
（１）の実像から写像をコピーする動作は、Ｓから見てあずかり知らぬ動作であり、そのタイミングについては、知ることができない。
（２）および（３）の、組Ａ：Ｂの写像を得る過程は、Ｓにとっては能動的な振舞いであるので、任意のタイミングで実行できる。
同様に、（４）および（５）の組Ａ：Ｂの実体を問合せる過程も、任意である。これは、Ｓが欲したタイミングでも良いし、また、Ｓの内部タイマに基づいても良い。そして、この（４）および（５）の動作は、必ずしも（２）および（３）の直後である必要はない。
例えば、いったん到達性が確認された後の（２回目以降の）到達性確認においては、（４）でするサインのあて先であるところのＴの住所を記憶しておき、通常は（２）および（３）の過程を省略し、ＳからＴに到達しなくなった時点、すなわち到達性の正しさが確認されなくなった後に、再度（２）および（３）の過程を実行しても良い。
（２）及び（３）、そして（４）及び（５）の過程は、要求と応答の関係にある。
また、特に（５）の過程において、（５）は動作であると同時に、（５）はＢのキャリアであって、バケツと水の関係にある。
３、拡張
ところで、写像同士を比較する場合であっても、前記理論は適用できる。
ただし、Ｄが既にプライマリ・セカンダリあるいはマスタ・スレーブ等のモデルによって、冗長化されている場合は、その冗長化されているグループ内で写像同士の比較判定をおこなったのでは、不十分であるので注意されたい。すなわちこの場合は、（２）および（３）のみを２度試行し、これを比較しているにほかならないのであって、これでは本来的に比較にならない。
したがって、写像同士を比較する場合は、本来的に無関係なマッピング公示システムに対して、Ｔが別々に写像している場合に有効である。すなわちＤに相当するマッピング公示システムが、冗長化されない異なるＤが２系統以上ある場合である。しかし、このような条件を付せば、対応できるＴは多いとは言えないはずである。そのため、別の方法を考える。
この場合の方法は、（４）および（５）の過程で、ＳはやはりＴに対して通信を試みるのだが、特に（５）の過程で、Ｔが応答するものにＢ以外を用いる方法である。
この方法は、Ｓにおいて、Ｔと関連付けられて記憶された文字列を、（５）においてＴはＢの替りに応答すれば良い。したがって、この場合の（５）においてＴが応答する文字列の内容は、Ｔと関連付けられていることをＳが知っている限りにおいて、あらゆる文字列が使用可能である。
同様に、ＴＳ間で合意されたなんらかのルールに基づいて、あらゆる文字列を更に変形された場合をも許容されるべきである。すなわちＢの代替は、置換の場合だけでなく、変形の場合であってもよい。
あらゆる文字列とＢそのものの関係は微妙である。
一方であらゆる文字列は、Ｂの拡張であり、Ｂからの派生である。
他方、あらゆる文字列であるということは、Ｂを単に文字列と見た場合には、当然にあらゆる文字列はＢをも含むものである。
このようにいずれが上位概念であるかは、微妙なところである。本明細書では、あらゆる文字列はＢの代替物であるとする。この際、あらゆる文字列を成立させる為には、Ｔと関連付けられていることをＳが知っているとの条件付きではあるが、この条件については、以降いちいち条件付きである旨を書かずに省略することとする。
（５）において、ＴがＳに対して応答する文字列の内容について、整理してみる。
Ｂそのものの場合は、Ｓは、あて先としてのＴの静的な識別子Ｂのみを、知っていれば良い。
あらゆる文字列の場合は、Ｔを示す静的な識別子に加えて、Ｔと関連付けられた文字列もしくは変形ルールを、知っている必要がある。
以降の記載では、単にＢとした場合はＢの代替物を含むものとし、ＢそのものあるいはＢの代替物のいずれであるかが重要な場合のみ、Ｂそのもの、Ｂの代替物とあえて記載するものとする。また、Ｂの代替物の中で特に置換の場合と変形の場合を区別する必要がない限り、単にＢの代替物あるいはあらゆる文字列と記載することとする。
なお、Ｓにおいて（２）の過程でＢを以って問合せることから、（５）でＢそのものが応答された時には、略してオウム返しの関係と記載することがある。この場合は、あきらかにＢそのものであって、Ｂの代替物を含むことはない。
ここまでが、本発明を実施するための通信モデルである。
以下に、機能を実際につかさどる具体的な装置を示す。具体的な装置がいずれの装置であるかについては、網の状況や位置関係等から複数の装置がありうる。これら特定の機能を実現する具体的な装置は、代替可能なものであって、その範囲において、特定の集合を形作る。
Ｄ：マッピング公示システム
Ｄは、本来的に冗長化されたサーバ群を構成する場合が多いので、このグループ内では、代替関係がある。典型的には、ダイナミックＤＮＳやＥＮＵＭ  ＤＮＳ、そして特許文献１や特許文献２に開示されたＢとＡとのマッピングを公示するものである。
Ｔ：あて先端末
ＴがＬＡＮ内にあり、ゲートウェイについで公衆の蓄積交換網を経由して、ＤやＳと通信する場合には、Ｐから見たエッジノードと一体となったものの間で、代替関係がある。この際の役割分担の実際については、実施例８に詳述する。
Ｓ：発信元端末
Ｓ−２の場合とＳ−１の場合がある。（基本的にＳは、Ｓ−１とＳ−２のいずれであってもよい。そして、Ｓ−１とＳ−２とを明確に分けて考えなければならない場合は、クライアントサーバ型で動作するときのみである。クライアント・サーバ型で動作するときのＳ−２は、到達性確認する機能を有しない場合がある）
本発明の実施にあたって、クライアント・サーバ・モデルを採用し、Ｓ−２がＳ−１に問合せ、Ｓ−１がＳ−２に替わってあて先への到達性を確認する場合は、Ｓ−１が発信元となる。
例外的にＳは、Ｄと一体となっている場合がある。
Ｐ：Ｔに対して、一時的な住所であるところのＡを割当てるものものである。
ＴがＬＡＮ上にあって、ＰがＤＨＣＰサーバの場合は、通常はＤＨＣＰサーバである。しかし、これはＤやＳをも、同一のＬＡＮかＬＡＮ間接続によって到達できる場合の考え方である。ＤやＳと通信する為に、公衆網を経由しなければならない場合は、ＩＳＰ等の網をＰとするべきである。逆に言えば、ＰはＴに対して一時的な住所であるところのＡを割当てるのではなく、単にエッジノードに対して、Ａを割当てている（すなわち、Ｔに対してでない場合がある）。そしてこの場合のＴは既に説明したように、ゲートウェイたるエッジノードと一体となって、参照されるノードである。これも実施例８に詳述する。
これらの位置関係および具体的なＰやＴが何であるかは、網の構成（接続のされ具合）によって、いずれかの具体的な装置が代替物の中から選択されるべきである。
以下に、動作について名前をつける。
（１）この過程は、ＴからＳへ、組Ａ：Ｂを写像する過程である。従来の技術であって、ＤＮＳの場合は「更新」動作にあたる。
（２）ＤＮＳの例では、「名前問合せ」である。用語の統一の為に、ＤがＤＮＳでない場合も「名前問合せ」とする。
（３）ＤＮＳの例では、「名前解決」である。やはり同様に、ＤがＤＮＳでない場合も「名前解決」とする。
（２）と（３）はセットである為に、片方の表現で残る一方の存在を暗示するものとする。
（４）従来は到達性を確認するための過程は存在せず、ウェブアクセス等の通常の通信がこれにあたる。「サイン」と呼ぶこととする。「あらかじめ合意された方式での通信」ともいう。
（５）サインに対する応答であるので、「カウンターサイン」と呼ぶこととする。
（２）乃至（５）による一連のシーケンスによって、組Ａ：Ｂの実像と写像が得られる。こうして得られた実像と写像を比較することによって、到達性を判断するのが、到達性確認である。
（４）乃至（５）の過程では、置換亦は変形しても同様の比較をすることができる。そのため、答えるべき返事に用いることのできる文字列は、あらゆる文字列である。
さて、（１）乃至（３）の過程は、従来からされていることであることを既に説明した。
（４）については、それが一般的なアクセスである場合は、そのアクセス方法に応じた応答をＴはする。
しかしそれゆえに、（５）においては、ＴはＢを応答したり、あるいはＳとのあいだで合意されたあらゆる文字列を応答したりはしないものである。
よって、（５）については特別に考慮して何らかの流用をするか、新たに実装しなければ、前記理論を用いることができない。
（５）の過程を担う者
以下、（５）の過程を担う者がどのように振舞うべきかについて説明する。ここでは答えるべき返事にはＢそのものを名乗るものとして、例示する。
１、標準状態ではＴ（４１００）は名乗らないか、もしくは関係ない名前を名乗る。ここで関係ない名前を名乗るとは、例えばパソコンの場合には、あらかじめ適当な名前（ここで適当な名前とは、少なくともＴ（４１００）がドメイン名まで含めて、Ｄ（１０００）に対して動的更新するホスト名が設定されることは、よほど意図的にやらない限りはありえない）がついているので、それを名乗るということである。
２、しかし、これでは答えるべき返事として使うことは出来ず、適切な名前を名乗っているとはいえない。
３、したがってＴ（４１００）は、答えるべき返事として使用する名前を名乗らなければならない。答えるべき返事として使用する名前とは、Ｄ（１０００）において動的更新されるホスト名を指す。１から、これは明示的な設定変更を意味する。なぜならば、Ｓ−１（２０００）はＴ（４１００）のドメインを管理するＤ（１０００）を参照して、Ｔ（４１００）のＩＰアドレスを得るわけであるが、この際の名前問合せに用いるキーであるところのホスト名を、Ｔ（４１００）からはオウム返しにしてほしいからである。
４、上記設定は特別な設定であって、普通はＴ（４１００）はこのように（３のこと）なっていない。
このような設定をあえてすることが、本発明のサイン・アンド・カウンターサインを成立させる上で必要なことである。
答えるべき返事が、Ｂの代替物である場合にも、同じ考え方でよい。
以上について、整理してみる。
到達性確認は、組Ａ：Ｂの実像と写像を比較することによって成立する。この為には、組Ａ：Ｂの実像と写像に関する４つの要素（値）を得る必要がある。そしてこの内、実像におけるＢを示す値のみが、唯一従来からある方法では入手できなかった。そこで「カウンターサイン」というキャリアを提案した。キャリアは明らかに信号であって、情報を運ぶモノの意味である。
「答えるべき返事」とは、「カウンターサイン」によってキャリーされるものであり、情報である。前記したＢそのものであるとか、Ｂの代替物であるとかは、この情報の類型に当たる。「カウンターサイン」がバケツで、「答えるべき返事」が水である。「答えられるべき返事」とは、Ｓにおいて記憶される、「答えるべき返事」と対応付けられた情報である。（５）の過程において「カウンターサイン」によってキャリーされた、Ｔが「答えるべき返事」を受け取ったＳが、Ｓにおいて内部的に記憶した「答えられるべき返事」と比較し、一致したかどうかによって到達性が正しいか誤っているかを、判断するものである。
前記（５）の過程を担う者では、流用として説明した。実施例１乃至実施例７に示す通信の方式は、従来技術である。しかし通信の方式を従来とは異なる使い方をすることによって、到達性確認という新たな価値を生み出すことができる。通信の方式とは、すなわちどの通信ポートを用いるかに過ぎない。したがって新規であろうと流用であろうと、いずれにしても通信ポートの範囲内に収めるしかない。そのため本来的には、新規のポートであることが望ましいが、これに関しては特許とは別の手続による標準化を待つべきである。流用とした理由は単純で、通信ポートに依存せずに、実施できることを明らかにしたかったからである。
ホスト名に何を名乗るかは、通常はＴ（４１００）の記憶装置に保存される。そして、Ｓからの通信要求（＝サイン）に対して、Ｔが応答する（＝カウンターサイン）際に読み出された後、応答に埋め込まれて返信されるものである。この返信の内容を答えるべき返事と呼ぶ。
そのためＴ（４１００）は、Ｄ（１０００）に更新するホスト名を名乗るように、明示的に設定されることが必要である。
しかし、置換もしくは変形されたものであっても、Ｂそのものと同様であるとしている。以下の答えるべき返事の類型で以って、この説明に替える。
答えるべき返事の類型
ここでカウンターサインによってキャリーされるＴが答えるべき返事に用いることのできる文字列を類型してみる。ＤＮＳを例として挙げる。
１、ホスト名
Ｂそのものの場合である。ホスト名はＦＱＤＮであるものと仮定する。
あて先ホスト名＝返事のホスト名の場合を、理想的とする。しかし、ホスト名のみを返す場合はむしろ少なく、現実にはかなり冗長な返事が返されるものと思われる。
よって、当然に返事の中から答えるべき返事を抽出し、判断する必要がある。
すなわち、この場合はサイン・アンド・カウンターサインの典型にあたり、Ｔ（４１００）が答えるべき返事として使用するホスト名を名乗るようにする明示の設定変更との前記条件が満たされている場合は、単にオウム返しですむ為に、Ｓ−１（２０００）における答えられるべき返事の設定は省略可能である。アルゴリズムについては実施例１で、設定内容については実施例１および表０２で説明する。
すなわち（２）の過程でＳからＤ（１０００）に問合わせられる内容がＢであるのに対して、（３）および（４）の過程を経て（５）の答えるべき返事の内容もＢである場合である。
Ｓにおいて、Ｂを二度記憶する必要はない。あて先と答えるべき返事が同じ場合（すなわちＢそのもの）は、答えるべき返事を省略できる。
答えるべき返事は、複数であってもよい。
ところで、マッピング公示システムがＤＮＳでない場合には、ＦＱＤＮではなく静的な識別子そのものであると考えればよい。例えばＦＱＤＮを、特許文献２の場合には、ハンドル名と読替えればよい。
２、ＵＲＩスキーム（＝ｕｒｉ＿ｓｃｈｅｍｅ）
ホスト名を含むが冗長である場合が多ければ、いっそプロトコル名を含んでしまおうという考え方である。
プロトコル名を含むことによって、単一のホストで異なるサービスを提供している場合に、複数のホスト名の各々と関連付けられたサービスで待ち受けしても、各々のホスト名とサービスの対を別個に到達性確認できるのでよい。すなわち、単一のホスト上で別名（ドメイン違いを含む）のホスト名でサービスを提供する場合である。
唯一性がある。Ｓ−１（２０００）における答えられるべき返事の設定は、場合によっては省略可能である。
例として、ｕｓｅｒ０１．ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐという単一のホストで、以下のサービスを提供しそれぞれに到達性確認する場合を挙げる。
ｈｔｔｐ：／／ｗｗｗｈｏｓｔ０１．ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐ
ｍａｉｌｔｏ：ｓａｌｅｓ＠ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐ
ｍａｉｌｔｏ：ｉｎｆｏ−ｆａｘ＠ｆａｘｓｖｒ．ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐ
ｓｉｐ：ｉｎｆｏ＠ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐ
ｈ３２３：ｉｎｆｏ＠ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐ
ｈ３２３：ｉｎｆｏ−ｆａｘ＠ｃｕｓｔｏｍｅｒ．ｃｏ．ｊｐ
ｔｅｌ：８１−３−１２３４−５６７８
ｅｎｕｍ：８．７．６．５．４．３．２．１．３．１．８．ｅ１６４．ａｒｐａ
等である。
ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ，ＲＦＣ２３９６）は、永続的であいまい性なしに参照できるという特徴を持つ。ここでは、ＵＲＬはＵＲＩの特化されたフォームであるものとして取扱い、ＵＲＩはＵＲＬ（ＲＦＣ１７３８）を含むものとする。本発明では、ＵＲＩはホスト名を含むという点で、ホスト名の拡張亦はホスト名の延長上に位置する概念として取扱う。
この際、Ｔ（４１００）で待受けする到達性確認用のポートは、ウェルノウンであってもよいが、サービス用でない到達性確認専用のポートを別途ウェルノウンでないポートとして用意してもよい。
ＩＴＵ−Ｔ  Ｅ．１６４勧告に規定される国際公衆電気通信番号（以下、「電話番号」とする）を逆順電話番号．ｅ１６４．ａｒｐａというホスト名（ＦＱＤＮ）に変形し、ダイナミックＤＮＳへの入力とする（ＲＦＣ３２６３）ことによって、既存の電話網との接続をはかろうとするものが、通称ＥＮＵＭである。この際、ＲＦＣ３４０３で文字列変形される際に発信人が受取人として指定する電話番号（ＲＦＣ２９１６）も、答えるべき返事として用いることが出来る。この場合は、１に示した「あて先ホスト名＝返事のホスト名」の場合と同様に、「最初と最後が同じ」でオウム返しの関係ならば到達性確認できるという点で、理想的である（電話番号あるいは前記変形された後の電話番号ホスト名の場合は、本来的には前記１のホスト名の場合に含まれる）。もちろん、前記変形の中間過程において得られるＵＲＩも答えるべき返事として用いることができる。
電話番号は、もちろん静的な識別子である。ＥＮＵＭにおける、逆順電話番号．ｅ１６４．ａｒｐａは、ホスト名であると同時に電話番号そのもの（異論はあるかもしれないが、単にＤＮＳ上にマッピングしただけであって、等価なので、電話番号そのものとした。すなわち単に表記法の違いである）でもある。電話番号そのものの場合は、答えるべき返事の類型において、ＵＲＩではなくホスト名の場合に含めた方がよい。
すなわち、名前問合せの結果得られた最終文字列（＝Ｔ（４１００）の正引き名前問合せ＞サインを送る相手としてのＩＰアドレス−＞サインとしての問合せ−＞答えるべき返事としての文字列）は、もちろんＴ（４１００）と結び付けられたものだが、Ｔ（４１００）は自らの自己の識別情報を示すものを答えるべき返事として返しさえすれば到達性確認できる。
ところで、ＵＲＩ形式を用いる場合には、Ｔ（４１００）のみならず、Ｔ（４１００）のユーザ（ヒト）を識別することも可能である。当業者であるならば容易に想到することができるが、実施例１に開示するアルゴリズム中での文字列処理部分を多段にするだけでよい。
すなわち、答えるべき返事には附加情報を含めることができる。
また、答えるべき返事は、複数であってもよいことから、一台のＴ（４１００）は、複数のサービス、複数の別名を各々到達性確認させることができる。
ＵＲＩスキームの場合は、Ｂそのものである場合と、Ｂの代替物である場合との、境界線上に位置する。
ＵＲＩスキーム中にＢそのものが含まれる場合は、１ホスト名の場合に示したように、冗長な返事の中からＴ（４１００）が答えるべき返事を抽出するのであるから、１の場合と同じでＢそのものだとみなせる。
しかし、ＵＲＩスキーム中にＢそのものが含まれない場合や、ＢそのものでなくＵＲＩスキーム全体を合意した場合には、Ｂの代替物だと考えるべきである。
３、返事のホスト名が足りない場合。
Ｂの代替物の場合である。
ここまでは、ホスト名＝ＦＱＤＮであることを仮定して、説明してきた。
ところが、ＦＱＤＮでないホスト名を返す実装は存在する。
ＦＱＤＮでないホスト名は、答えるべき返事からＴ（４１００）を特定できない場合である。
以下の３パターンが考えうる。
ドメイン名のみであって、狭義のホスト名が存在しない場合。
この場合はやや特別である。ドメイン名をカスタマが専用する場合は、ＦＱＤＮと同じに扱ってよい。ドメイン名をカスタマが専用しない場合は、識別性がない（自己の識別情報として十分でない）。
狭義のホスト名のみであって、サブドメイン名、ドメイン名を含まない（非修飾シングルラベルの）場合。
ホスト名＋サブドメイン名であって、ドメイン名を含まない（非修飾マルチラベルの）場合。
名前検索する場合と異なり、Ｓ−１（２０００）がＴ（４１００）の到達性確認の為にサフィックスを追加したりすることはない。
ホスト名がＵＳＥＲ０１とかＨＯＳＴ０１等の場合は、（ヒトにとっても）識別姓がない。むろん、一意性はない。
しかし、これはこれでよい。
一意性がない為にＳ−１（２０００）が受取った、Ｔ（４１００）が答えるべき返事から、Ｔ（４１００）を特定することができないだけである。
その他、Ｓ−１（２０００）に登録されている文字列であって、ホスト名でもＵＲＩスキームでもない文字列も、Ｂの代替物である。
Ｘ５０９証明書や単にＴ（４１００）の公開かぎでもよいこととし、必ずしもホスト名をベースにする必要がない。すなわちホスト名でなくても、Ｔ（４１００）は自己の識別情報を名乗りさえすればよい。更に言えば、この識別情報はＴＳ間において合意されていれば足る。ここでいうＴＳ間の合意は、単にＴ（４１００）が勝手に決めて公衆にアナウンスした文字列である場合を含む。そのためＦＱＤＮやＵＲＩの場合と異なり、グローバルに一意である必要がない。
そして、Ｔ（４１００）の識別情報は当然にＳ−１（２０００）は知っている必要があり、Ｓ−１（２０００）はＳ−１（２０００）内にあらかじめ保存されたＴ（４１００）の識別情報（＝答えられるべき返事）と、Ｔ（４１００）であろうと思われる装置（通信の相手方）からの返事（＝答えるべき返事）を比較することによって、到達性確認する。
以上、返事のホスト名が足りない場合そしてその他の文字列が、Ｂそのものの置換の場合である。置換の場合には、置換えられた後の文字列を直接ＴＳ間で合意する。それゆえ、置換の場合は静的である。変形の場合とは、変形ルールを合意するものである。それゆえ変形の場合とは、動的な置換にほかならない。
それゆえ、カウンターサインはＳにＴ（４１００）の到達性を確認させるように機能する信号である。
答えるべき返事の特徴
偽装の項で既に説明したように、答えるべき返事はパスワードではない。すなわち、セキュリティ上の脅威たり得ない。よって、秘密にする必要がない。
従来からされてきた個体識別によって、Ｔ（４１００）を識別しようとするものではない。網の特性から得られる値を比較することによって、到達性が判断されるものである。
更に、Ｓは特定の一の通信ノードではない。ＳとしてＳ−２（５３００）が挙げられているように、不特定多数である一般利用者をも想定されている。この場合は、秘密にする必要がないのではなく、実は答えるべき返事を秘密にすることができない場合である。この際に、Ｂの代替物を用いる場合には、Ｔ（４１００）を示す静的な識別子だけでなく、置換え後の文字列や変形ルールをも事前にＳに対して知らせておく必要がある。こう書くと現実的でないように思われるかもしれない。しかし、そうではない。例えば、ドメイン名のみでなく、ＵＲＬとメールアドレスをセットで知らせることは、普通にされていることである。この例と同じだと考えれば、別段Ｔ（４１００）側そしてＳ側における負担が増すわけではない。
しかし、別の場合もある。例えば、特定のＳ−１（２０００）のみにＢの代替物を知らせて、これを答えるべき返事に用いる場合には、実質的に秘密である。しかし、だからといって何らかのパスワードと混同すべきではない。本発明の柔軟に実施をすることができることを表すのみである。
以上から、Ｓ−１（２０００）に記憶された（期待された）返事を含む文字列をＴ（４１００）が返しさえすれば、到達性確認は可能である。
ところで、ＤＮＳは、リゾルバからは以下のように定義づけられる
（従来）
リゾルバからの問合せに対して
静的な識別子を
静的なＩＰアドレスに変形して出力するシステム。
（最近）
リゾルバからの問合せに対して
静的な識別子（ホスト名、電話番号）を
動的な識別子（ＵＲＩ）に変形し
多段の再帰クエリ（中間処理）を用いて
静的なあるいは動的なＩＰアドレスに変形して出力するシステム。
なお、最近の場合は従来のものを含む。
このように、ＤＮＳの位置付けが変化してきている。
この時、ＤＮＳが識別子を変形する過程は、以下のようになる。
別名（＝ＣＮＡＭＥ）−＞ホスト名−＞ＩＰアドレス
電話番号−＞ホスト名−＞ＵＲＩ−＞ＩＰアドレス
答えるべき返事は、上記のうち、
ＩＰアドレスを除く、
ＤＮＳへの最初の入力である静的な識別子の、あるいはＤＮＳでの識別子変形過程上で得られる（中間過程の）識別子の、
いずれであってもよい。
なお、上記のうち、別名で始まるものは、特別な意味を持つ場合がある。
第一に、別名によって、別のＤＮＳ上のホストを参照させることは従来からされてきたことである。すなわち、再帰性はＥＮＵＭ以前からあった。
第二に、その別のＤＮＳ上でポイントされたＴ（４１００）が動的更新される場合である。文字列変形を無視して単に動作として考えたとき、ＥＮＵＭと同じ動作ということができる。
ここでカウンターサインを複数返してもよいものとすると、エンド・エンドの場合のみならず、名前検索過程における中間過程のホスト（この場合はＤＮＳ）に対しても、到達性を確認することができる。Ｓでは複数返された答えるべき返事の中から、目的たる答えるべき返事を抽出すればよい。
この際、１のカウンターサインの中で、複数の答えるべき返事を返す方法と、カウンターサインによってキャリーされる答えるべき返事は１のみに固定し、複数のカウンターサインを返す方法とがある。
このように、複数のカウンターサインを返すことは、概ね２つのことに貢献する。
１つは、単一のＴ（４１００）において、複数の識別を可能とすること。
もう１つは、名前変形過程上の中間段階におけるノードがカウンターサインを複数返すことによって、追跡性を増すことが可能となること。この際、Ｔ（４１００）では、中間ノードがした応答の中から、お目当てのＴ（４１００）を示す答えられるべき返事を抽出するようにすればよい。こうすることによってｔｒａｃｅｒｏｕｔｅのように、中間ノードの到達性を確認することができ、障害時の障害個所の特定に多いに役立てることができる。
設計思想
網管理とは
ここで念の為に網管理の必要性について説明する。まず、用語の説明として、網管理自体は、いわゆる構成管理や課金管理等をも含む通常の管理の概念であって、その対象を網としているものである。次に、管理と監視の関係は、網管理という大カテゴリの中で、ホストや網そのもの（例えば、トラフィック（＝流量）は個別のノードに対してだけでなく、全体に対しても計測できる）の監視という具体的な手法があるものと解されたい。網の状態は常に変動している為に、その状態を監視することが障害対応の第一であり、また、網設計へのフィードバックや将来の拡張計画の根拠資料となるべきものである。
しかし本発明では、Ｔ（４１００）は動的ＩＰアドレス割当てを受けたカスタマ網の境界ノードあるいは境界ノードと一体となって参照されるホストであり、きわめて小規模なものである。しかし、何らかのＴＣＰ／ＩＰサービスを提供するのであるから、回線断やシステム障害等によって、サービス提供ができなくなっているにもかかわらず気づかずにいたのでは、問題がある。そこで、なんらかの障害が発生した場合に、すみやかに通知され復旧すべきと考えて、このような小規模な網においても網管理は必要なものであるとして、従来管理することのできなかったＩＰアドレスが変化するホストにおいても管理できるようにしようというものである。
ｐｉｎｇの意味
ｐｉｎｇは、ＩＣＭＰプロトコルのエコー要求を実装したプログラムとして、従来はホストの到達性（活死）確認に用いられてきた。
ｐｉｎｇは、魚群探知機のごときものであって、はね返ってくれば、魚群（もしくはホスト）がそこに居ることがわかるというものである。
ところがこのｐｉｎｇは、ＩＰアドレスが変化するホストをあて先とする場合には、仮にＴ（４１００）でなくＴ’（４２００）からｐｉｎｇの返事があった場合であっても、正しく相手先のホストが応答していることを示してしまう。しかしこの場合は、ホストへの到達性が確認できたとはいえない。
ｐｉｎｇでは通信の相手方が本物かどうかがわからないので、本発明では「あなたは誰」とたずね、「私は誰某」と名乗った返事を聞いて、この返事が想定していた名前と合致していれば、Ｔ（４１００）がそこに居ることがわかるとしている。
本発明は、（従来のホストとは異なる）ＩＰアドレスが変化するホストに対しては使用をすることができなくなった「ｐｉｎｇ」を代替するものとして、設計した。すなわちｐｉｎｇを全面的に代替することは目的としておらず（事実ｐｉｎｇで実装される多くの機能を本発明では実装していない）、ｐｉｎｇで到達性を知る事ができない場面ではじめて本発明をｐｉｎｇに代替して用いるものである。
そこで、本発明の理解を助ける為に、いわゆるｐｉｎｇ代替としての使用をする場合（Ｓ−２（５３００）がＴ（４１００）の到達性を確認する手段として本発明を用いる場合）のイメージを、図３９にしめす。（詳しくは実際的応用に示す）
なおここでは、Ｔ（４１００）の到達性を確認が出来ている場合とは、正しく通信の相手方に到達し反射が返されている場合であり、ｐｉｎｇ本来の目的である到達性確認に相当する。よって、到達性確認はｐｉｎｇを代替しうる。なお、ｐｉｎｇの出力に含まれる経路周回時間（ｒｏｕｎｄ  ｔｒｉｐ  ｔｉｍｅ）等については考慮していないが、本発明の実装に経路周回時間の計算を附加することは、当業者であれば容易である。ただし、実際的応用に示す本発明をフィルタとして用いる場合には、経路周回時間等といった冗長な出力は望ましくないことを、実装上の注意点として挙げておく。
ｐｉｎｇが相手先からはね返ってくる過程において、途中経路にいかなる網の雲が存在していようとも、あるいは網の雲を経由せずに単に同一のイーサネット上にあったとしても、これを意識しないのと同様に、本発明でも意識する必要はない（すなわち、エンド・エンドの通信である）。
設計上留意したこと
蓄積交換型の網が、本来持つ自律性を生かすことを目指した。
そして単純かつ明快であることを心掛けた。この単純さについては、後の時代にあってこれは自明であるといわれる程度の単純さによって構成される理念を目指した。
その他には、適用可能性が高いこと、可用性が高いこと、柔軟で規模に依存しないこと等を目指した。
実施可能性について。
従来技術を捨てることに対する人々の心理的な抵抗は大きい。
社会のインフラを変えなければ実施できないような発明は実際問題として、実施可能性は低いといえよう。よって、従来の技術を変更する要なく、附加することによって、利便性有用性を提供できるような実施の仕方が望ましい。
その意味で本発明は、スモールスタートでき、かつ規模に依存せず実施できるという点、そして従来の技術との高い整合を図り、従来技術を何一つ捨てずに実施できるという点で、普及の可能性は高いといえよう。
適用の範囲
本発明においては、ＩＰｖ４およびＩＰｖ６で利用可能である。
動作モデルとしては、ピア・トゥ・ピア型でもクライアント・サーバ型でも動作する。
また、ＩＰアドレスの携帯性および移動性の双方に適用可能である。
ここで、ＩＰアドレスの携帯性とは、ノートパソコンの電源を一度切って、移動して（出張先のホテルや訪問先の会社）から再び電源を入れて使用する場合等をいう。
そして、ＩＰアドレスの移動性とは、（移動体端末等において）通信を維持したままで、ＩＰアドレス的にハンドオーバした場合等をいう。
ＩＰアドレスの移動性について、混同されやすいものに、モバイルＩＰ（＝ＩＰ  Ｍｏｂｉｌｉｔｙ、ＲＦＣ２００２乃至２００６）がある。
まず目的が異なる。モバイルＩＰは自ら発呼した通信の返事をロストせずに受信することを目指す技術であって、少なくとも発呼側端末に被呼側（であるモバイル）端末の識別性を提供することは主たる目的ではない。
さらに、モバイルＩＰでは、動的な住所と静的な住所を関連付けるという点で、本発明とは考え方が異なる。その意味では、前記ＩＰアドレスの移動性としたのは適切ではなく、住所の移動にかかわらず、本発明は静的な識別子と動的な住所の対を検証するものである。
実装について
本発明はアプリケーション層で動作し、トランスポート層には依存しない。ただし前記アプリケーション層は、ＯＳＩ（＝Ｏｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ。ＩＳＯおよびＩＴＵ−Ｔによる標準）でいうところのセション層、プレゼンテーション層、アプリケーション層を含むものとする。このことから理解されるように、本明細書は連綿と続くＵＮＩＸ的な標準に従って記載されるものであって、ＯＳＩ等のその他の標準に従う場合は、その旨明記されるものとする。また、前記アプリケーション層で動作するとしたことは制限でなく、本発明が後にＩＣＭＰ等のネットワーク層で動作するプロトコルに代替されるものとして提案された場合にも、この場合は本発明の最初の実装がアプリケーション層で動作したものであったに過ぎず、本発明の思想の範囲内であるものとする。
（実装）
以下、本発明の実装を図面に基づいて説明する。なお、各図面において同様の機能を有する箇所には同一の符号を付している。以下に掲げる実施例は、制限でなく例である。
実施例ではＳ−１（２０００）として説明したが、Ｓ−２（５３００）と置換てもよい。ダイナミックＤＮＳを例に説明するが、既に説明したように、ＥＮＵＭや特許文献１や特許文献２の場合でも適用可能である。
実施例１乃至実施例７は、サインの仕方として、どのような通信を用いることができるがを例示した。サインの仕方のことを、あらかじめ合意された通信の方式と表現する。この際、通信ポートに関しては通常そのポートを使用するプロトコルに従うものとする。実施例１乃至実施例７は、通信ポートについては、既存の（ウェルノウンな）ポートを流用して説明した。
実施例１の中で、前提となる考え方とアルゴリズムについて示す。
実施例１および実施例２は、Ｔ（４１００）＝網境界（＝エッジノード）の場合。典型的には端末そのものの場合。
実施例３および実施例４は、Ｔ（４１００）が網接続機器である場合、典型的にはＮＡＴＢＯＸの場合。
実施例５乃至実施例７は、Ｔ（４１００）がどのような機器であるかを問わない場合を示す。
実施例８の中で、網の構成と位置について示す。
実施例９の中で、新規の実装であるところの、例えばＮＡＴＢＯＸ等の装置への本発明の実装例を示す。
実施例１０の中で、端末そのものであって、典型的にはモバイル端末の場合の実装例を示す。
【実施例１】  実施例１は、あらかじめ合意された通信の方式に、ＳＮＭＰを用いるものである。
Ｔ（４１００）は計算機であり、直接ダイヤルアップ接続している。ＳＮＭＰエージェントを実装しており、通常の正しい設定がされているものとする。実施例８で詳説する図３７の接続形態１である。
Ｓ−１（２０００）では、監視プログラムをタイマ実行している。
Ｓ−１（２０００）において、
１、インターネットではＵＮＩＸ（登録商標、以下同様）サーバが非常に多く使われているため、本発明実施の場合にも、ＵＮＩＸ上で動作させる場合が多いだろうことが想定されること。
２、ＵＮＩＸにはウェルノウンポート等で待受けする主要なインターネットサービスがあらかじめ導入されているか、少ない費用と労力で導入することができること。
３、ＵＮＩＸには文字列処理環境が最初からＯＳの一部として提供されていること。
等によって、本発明部分のみの実装で実験環境が構築できることから、ＵＮＩＸ上で実験した。
Ｗｉｎｄｏｗｓ系のＯＳの場合は、ＤＮＳについてはＩＳＣ版ＢＩＮＤ（最初のＤＮＳの実装としてバークレー版ＵＮＩＸに採用されて以来、インターネットの標準ＤＮＳである）に入替える。あるいはＩＳＣ版ＢＩＮＤの代替物に入替える。代替物とは、ＩＳＣ版ＢＩＮＤに含まれるｄｉｇコマンドのようにＤＮＳサーバの情報を外部から精査できるものをいう。ＳＮＭＰマネージャについては、マイクロソフト社製のものを用いてもよいし、ＯｐｅｎＶｉｅｗ（登録商標、以下同様）等の製品を新たに導入してもよい。文字列処理環境については、Ｗｉｎｄｏｗｓ系のＯＳにあっては十分にはＯＳに含まれていないので別途文字列処理環境を用意するか、本発明を実装する際のプログラム開発中に組み込みとした方がよいかもしれない（ただしこの場合、ＩＳＣ版ＢＩＮＤに含まれるｄｉｇコマンドの出力に対するプログラムインターフェースの問題もあるので、いっそｄｉｇコマンド代替から作成してしまった方が、労力が少ないかもしれない）。
Ｔ（４１００）においてＰＣが使われる場合には、Ｗｉｎｄｏｗｓ系のＯＳの場合は、ＷｉｎｄｏｗｓＮＴやＷｉｎｄｏｗｓ２０００にはＳＮＭＰエージェントが含まれている為に、そのまま利用することができる。
以上によって、ＯＳの種類に関わらずに、本発明を実施可能である。
ＳＮＭＰ等の通信の方式は、待受け側のポート番号として、以下特にことわりのない場合は、ＲＦＣ１７００  ＡＳＳＩＧＮＥＤ  ＮＵＭＢＥＲＳに規定されたウェルノウン・ポートと同じか類似のものとする。ＲＦＣは、ＡＲＰＡＮＥＴ開発時代に、通信の方式を合意する（よりよくする）為に「意見を求む（＝Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔｓ）」として公開された文書を起源とし、現在ではインターネットあるいはＴＣＰ／ＩＰによる通信における標準的な規約集として機能している。
ＳＮＭＰ（＝Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）は、けして単純とはいえない標準的な網管理用のプロトコルである。ＳＮＭＰにおける通信ではコミュニティ名およびＴ（４１００）の到達性確認で用いるべきオブジェクトＩＤを通信の方式として合意し、Ｔ（４１００）に設定されるオブジェクトＩＤの値を答えられるべき返事として合意する。例としてコミュニティ名に初期値のままのＰＵＢＬＩＣとし、オブジェクトＩＤにホスト名を意味するｓｙｓＮａｍｅを用いる。
ｓｙｓＮａｍｅはＳＮＭＰエージェントの設定上、ほとんどの場合で明示的に設定するものではなく、単にシステムのホスト名をそのまま引用する。ここでは、「（５）の過程を担う者」における明示の設定変更および「答えるべき返事の類型」に従うものとする。Ｔ（４１００）に設定されたホスト名は、Ｄ（１０００）に登録される完全修飾ドメイン名（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ。ホスト名＋サブドメイン名＋ドメイン名からなる。以下、「ＦＱＤＮ」とする）が設定されているものとする。ごく一部の装置ではＦＱＤＮを設定できずドメイン名を含まないホスト名のみ設定できる場合がある。この場合であって、あえてＢそのものを答えるべき返事の値に用いたい場合には、実施例２を参照されたい。この場合は、Ｂの代替物を答えるべき返事の値に用いた方が単純である。
ここでオブジェクトＩＤは、返事の内容（＝識別子）が代入される変数だと考えればよいので、以下のようになる。
オブジェクトＩＤ（ｓｙｓＮａｍｅ）の値＝ＦＱＤＮ＝返事の内容＝Ｔ（４１００）のホスト名。
Ｓ−１（２０００）に登録されたＴ（４１００）名や返されるべき返事等の通信の設定に必要な項目を、表０２に示す。
2004059925.tif 000004
表０２から判るように、Ｓにおいてあて先たるＴ（４１００）を示す静的な識別子が追加される他は、ＳＴともに共通である。Ｔ（４１００）が答えるべき返事が、Ｂそのものである場合には、Ｓ側においてのみその設定を省略することができる。
Ｓにおいては、カウンターサインを受取る事によって、通信モデルにおけるシーケンスを完成させる。この後、ＳではＳの内部に記憶されていた答えられるべき返事を読出し、カウンターサインによってキャリーされたＴ（４１００）からの答えるべき返事と比較する。そして受取った返事（Ｔが答えるべき返事）と内部記憶した答えられるべき返事とを比較した結果の真偽によって、Ｔ（４１００）に対して正しい到達性を有するか否かを峻別するのである。なお、返事を受取った際に、受取った返事を一時記憶する変数が必要であるが、これについては計算機工学上自明でもあり、また、この変数そのものは本発明においてさして重要でない為に、単に受取るべき返事とする。
Ｓ−１（２０００）においては、到達性の確認に必要な項目を設定する場合は、シーケンシャルファイルのレコードとして記憶装置に保存してもよいし、ＤＢＭＳを通じてアクセスされるデータベースであっても、かまわない。また、Ｔ（４１００）毎にプログラムを用意し、そのプログラム中に設定情報を記述する方法でもよい。これらはＳ−１（２０００）において管理するＴ（４１００）のボリュームに応じて選択すればよい。プログラム中に直接埋め込む方式は、Ｔ（４１００）の数が多くとも数百等の比較的少ない場合によい選択である。ここで設定される内容は、Ｔ（４１００）あたりに必要な項目が含まれていればよく、附加情報が追加されていてもよい。附加情報の例として、Ｔ（４１００）の使用するドメイン名を運用するＤ（１０００）の住所等が考えられる。特許文献２に適用する場合には、ＩＰアドレス情報通知サーバの住所を記憶する。また、項目が並ぶ順序についても表０２の通りでなくても、Ｔ（４１００）あたりとして混乱のないように保存されるようにすればよい。
本発明では、記憶装置については、レジスタやキャッシュについては考慮せず、メモリおよび外部記憶装置を指すこととする。また、外部記憶装置は、Ｓ−１（２０００）やＴ（４１００）の当該機器内に内蔵されるローカルな装置である必要はないものとする。例えばハードディスクドライブにおいて、ファイバーチャネル等を経由してアクセスされるディスクアレイであっても、ＮＦＳマウント等をされるような共有型のディスクであっても、単にハードディスクドライブとして扱う。一時記憶は、機器の再起動等の際には保持される必要がないものであり、比較的短時間で消去されるものであるが、一時記憶はメモリ上に展開されても、ハードディスクドライブ等に一時ファイルとして展開されてもよい。
Ｔ（４１００）においては、通信の設定に必要な項目は多くない。これらは、合意された方式での通信要求に応答するプログラム部分と返事そのものであるところの通信の設定に必要な項目すなわち、パラメータからなる。プログラムが実装済みであるならば、保存すべきデータ量が少ないこととなる。これらの通信の設定に必要な項目を保存する記憶装置には以下のものが考えられる。機器内の不揮発メモリ、ＣＦカード・スマートカード等のメモリカード類、ＰＣＭＣＩＡインタフェースを有したハードディスクドライブか通常のハードディスクドライブ、ディスケットドライブ、ＭＯドライブ、テープ装置等の記憶装置（か、ＤＶＤ−ＲＡＭやパケットライト方式のＣＤ−ＲＷもしくはイメージを作成するものとしてＣＤ−Ｒ等の取り外し可能な記憶媒体を利用した記憶媒体読取り装置）が利用可能であるし、書換えの頻度が極めて低い場合が考えられることから、当該機器において直接に記憶媒体に対する書換えをするのではなく交換によって保存内容の修正をおこなうＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＲＯＭカートリッジ等の取り外し可能な記憶媒体を利用した記憶装置まで可能である。ところで、ＵＳＢインターフェースやＩＥＥＥ１３９４インターフェースの記憶装置であっても、ハードディスクドライブにおいてＳＣＳＩインターフェースなのかＩＤＥインターフェースなのかを区別する必要がないのと同様に、インターフェースの種類については区別する必要がない。その他にも、例えば、システムの起動時にあらかじめ指定されたホストからＴＦＴＰ等の通信を用いて、設定をロードすることも可能である。この場合の記憶装置は通信を経由した外部のホストであり、内部の記憶装置に一時記憶させることによって用いる。
これらは、実施しようとする環境（具体的な装置）にあわせて利用可能なものの中から選択すればよいものとする。
ところで、図１５に示すように、Ｔ（４１００）の使用するドメイン名を運用するＤ（１０００）に対して、名前問い合せをしなければならない。すなわち、Ｄ（１０００）は基本的に複数あるのが前提であり、問合せ毎に問合せ先であるＤ（１０００）を切り替えることになる。例えば、Ｔ１（４１０１）の使用するドメイン名を運用するＤＮＳがＤ１（１００１）であり、Ｔ２（４１０２）の使用するドメイン名を運用するＤＮＳがＤ２（１００２）である場合等は、Ｓ−１（２０００）の動作としてそれぞれ異なるＤであるところのＤ１（１００１）とＤ２（１００２）とを切り替えて、名前問合せをする。もちろん、ここに図示しないＴ３（４１０３）の使用するドメインを運用するＤＮＳがＤ１（１００１）である場合には、Ｔ１（４１０１）およびＴ３（４１０３）の名前問合せを、Ｄ１（１００１）に対してまとめた方が良い。
よって、以下に示すアルゴリズムは、Ｔ（４１００）毎亦はＤ（１０００）毎に、毎回するものである。
図２３にアルゴリズムを示す。
アドレス確認
Ｓ２０２およびＳ２０４はアドレス確認である。これにより、キャッシュの生存時間の問題を解決している。
キャッシュの生存時間の問題とは、ＤＮＳサーバ（４５００や５５００等）からＴ（４１００）のＩＰアドレスを正引き名前問合せをしようとする時に、Ｄ（１０００）の指定したキャッシュの生存時間中の２度目以降のアクセスであって、かつＴ（４１００）がその間に更新していた場合には、誤ったＴ（４１００）のＩＰアドレスを得る為に、Ｔ（４１００）以外のホストにアクセスしようとしてしまうことをいう。
このキャッシュの生存時間の問題を解決する為に、Ｓ２０２では、Ｓ−１（２０００）からＤ（１０００）に対して名前問合せ（正引き）をしている。
図２５に名前問合せの出力の例を示す。下線部がＤ（１０００）に対して最後に更新されたＴ（４１００）のＩＰアドレスである。この出力結果に文字列処理を施し、下線部のみを抽出し、Ｔ（４１００）のＩＰアドレスを得る（Ｓ２０４）と、これを記憶装置に一時的に保存する。より正確には、次のステップでする到達性確認の為に、あて先であるＴ（４１００）を示す住所に代入する。
図２６に名前問合せでエラーになった場合の出力の例を示す。ＤＮＳサーバが正しくない場合かＤＮＳサーバがダウンしている場合の例である。
図２７に名前問合せのエラーになった場合の出力の例を示す。Ｔ（４１００）が見つからなかった場合（Ｔ（４１００）を示す情報がＤＮＳレコード中に存在しない場合）の例である。
キャッシュ問題の実例から、Ｔ（４１００）のＩＰアドレスの確認は、Ｓ−１（２０００）のリゾルバがＤ（１０００）を向いている場合や、Ｄ（１０００）のＴＴＬ（キャッシュの生存時間）の設定が極めて短い場合等は、省略することができる。
Ｓ２０４では、必要に応じて図２４のようなエラーチェックをするとよい。Ｄ（１０００）で障害が発生している場合には、Ｓ２０４で受取る返事が不整なものになる。Ｓ２０４で受取る返事の中にＴ（４１００）を示すデータが含まれない場合をＳ４０２において検出した場合は、エラーとして扱う。また、Ｄからの返事がない場合も、同様にＳ４０２においてエラーとして扱う。この際、冗長化されたＤ（１０００）の範囲で別のＤ（１０００）に切り替えてみたり（Ｓ４０８乃至Ｓ４１０）、それでもだめな時は処理を中止するようにするとよい。ここで中止された場合には、Ｔ（４１００）の状態が仮に正常であったとしても、Ｔ（４１００）への到達性はないと判断されることになる。また、Ｄ（１０００）の信頼性がじゅうぶんある場合には、このエラーチェックは省略することができる。この項ではＤ（１０００）の冗長化範囲内での巡回について説明した。
サイン・アンド・カウンターサイン
Ｓ２０６ではＳ２０４で求められたＴ（４１００）のＩＰアドレスに対して、あらかじめ合意された方式での通信すなわちサインをおこなっている。なお、アドレス確認が省略できるときには、あえてＩＰアドレスに変形する必要はない（この場合でも、ＤＮＳを正引きした際に得られるＩＰアドレスで問合せをおこなう）。Ｓ２０８では、Ｓ２０６の返事が返ってきた場合には返ってきた返事を一時的に記憶し、Ｓ２０６の返事が返ってこなかった場合には、Ｓ２０６の終了コードを一時的に記憶する等して、Ｓ２１６のエラー処理へ進む。
図２８に、ＳＮＭＰのＧｅｔＲｅｑｕｅｓｔ命令でＴ（４１００）のホスト名を引いた場合の出力例を示す。
図２９は、Ｓ２０６の通信に失敗した場合として、キャッシュの生存時間の影響等でホスト名が間違っていた場合すなわち相手先ホストがＳＮＭＰを受付けるよう設定されていなかった場合、あるいは相手先ホストが存在しなかった場合の例を示す。
図３０は、Ｓ２０６の通信に失敗した場合として、相手先はＳＮＭＰを受付けたがコミュニティ名が間違っていた場合の例を示す。
Ｓ２０８では、前記図２９および図３０の場合等のように、Ｔ（４１００）がＳ−１（２０００）からのＳＮＭＰのＧｅｔＲｅｑｕｅｓｔ命令を受付けなかった場合のエラー処理をしている。図２９や図３０等のＳＮＭＰのＧｅｔＲｅｑｕｅｓｔ命令でエラーとなった場合には、Ｓ２０６の返事はエラー出力のみに返され、標準出力には何も返ってこない。このような場合には、終了コード（エラーを示すもの）をフラグとして代入する等の対応を取ればよい。
図３１に、ＳＮＭＰのオブジェクトＩＤの指定間違いの場合を示す。この場合は該当するオブジェクトＩＤの値が正常に返され、ＳＮＭＰのＧｅｔＲｅｑｕｅｓｔ命令におけるエラーにはならない為に、Ｓ２１２で判定されるべきである。例ではｓｙｓＬｏｃａｔｉｏｎを用いている。
その外、Ｓ２０６の通信が正常であってかつ合意された返事と違う内容の返事が返された場合すなわち答えられるべき返事でなかった場合には、Ｓ２１２で判断される。
Ｓ２１０では、この通信の返事に対して、文字列処理をして、Ｔ（４１００）のホスト名（ＦＱＤＮ）を抽出する。
Ｓ２１２では、この返事をＳ−１（２０００）に設定された、Ｔ（４１００）からの返事であるべき、あらかじめ合意された方式での通信に対する答えられるべき返事との比較をおこない、判定する。
あらかじめ合意された方式での通信に対する、Ｓ−１（２０００）に記憶されたＴ（４１００）からの答えられるべき返事と、Ｓ−１（２０００）からの問合せ（合意された方式での通信）に対して実際にＴ（４１００）が答えてきた返事とが一致した場合Ｓ２１４では、Ｔ（４１００）は正常に動作し正しい到達性を有するホストである。
出力
ここでＳ２１４およびＳ２１６の結果表示の出力手段であるが、標準出力、キーボードとディスプレイ装置からなる通常のコンソールあるいは端末装置に出力してもよいし、記憶装置に保存されるログファイルとして書出すか、あるいはＳｙｓｌｏｇやＸ、ＳＮＭＰＴＲＡＰ等のＴＣＰ／ＩＰ上の通信路を経由して別のホストに出力してもよい。また、ＳＭＴＰサーバプログラムへの入力として接続することによってメール送信でき、後述する保守に連係させる際に都合がよい場合もある。これらは複数を組合せて出力してもよいし、もちろん紙媒体へ印刷出力してもよい。本発明を実施する場合には前記の出力方法からその環境に最適な方法で出力するか、あるいは後続する処理に進むようにするとよい。
出力は到達性確認の結果の真偽によって分類される。
真の場合が、Ｓ２１４である。
この場合の出力は、障害検知を目的とする場合は、何も出力しなくてもよい。
その他の目的の為には、単にＴ（４１００）に対して正しく到達している旨を表示すればよい。表示する場合は、前記出力方法から最適な方法ですればよい。
偽の場合が、Ｓ２１６である。
一致しない場合Ｓ２１６は、Ｔ（４１００）はインターネットに接続されていないか何らかの問題でＤ（１０００）に対する更新が出来ない状態にある。
Ｓ２１６では、到達不能理由をＳ２０８で返事がなかった場合か、Ｓ２１２で一致しなかった場合かを分けて表示することも可能である。この場合はメッセージ内容に到達不能理由を示して、ログファイル等に書出すようにした方がよい。
ところで、Ｔ（４１００）がＤ（１０００）に更新要求したタイミングと偶然重なった為にＴ（４１００）で障害が発生しているように見えてしまう場合等は２回目の監視タイミングまで待てば、自然と正常状態に収束するはずである。このような場合を考慮するならば、この時点では障害として検出しない方がよい場合がある。
Ｓ−１（２０００）では監視プログラムをタイマ実行しているため、図示しないＳ２１６の次のステップで、エラーフラグをたてることにより、Ｓ２１６のステップを通るのが、１回目なのか、２回目以降なのかを別々に検出することができる。なお、正常復帰時には図示しないＳ２１４の次のステップで、エラーフラグを消去した方がよい。
タイマ実行による２回目のＳ２１６では、タイミングの問題ではなく、Ｔ（４１００）が見失われていることが明らかなので、単にログファイルに書出すだけではなく、アラートをあげるなりポケベルを鳴らすなりメールにて通知する等の方法で、保守亦は復旧をうながすようにするとよい。この場合は、到達できないＴ（４１００）そのものに通知することはできないので、Ｔ（４１００）の管理者宛に連絡のつく方法で通知するべきである。ただしこの場合にも、以降の表現においてＴ（４１００）に対して通知するという。
この時、必要であって保守亦は復旧段階へ移行する場合にあって、Ｔ（４１００）が何らかの理由でインターネットから切断された状態にある時等の、Ｔ（４１００）が発見できないか亦は、Ｔ’（４２００）のみが発見された場合においては、Ｔ（４１００）は、Ｓ−１（２０００）から見失われているため、一般にアクセスするには、Ｔ（４１００）の設置場所に行かなくてはならない。しかし、これでは障害からの迅速な復旧をはかることができない。図１４におけるＳ−１（２０００）からＴ（４１００）に向かう線のように、例えば、Ｔ（４１００）あるいはＴ（４１００）に接続されたＬＡＮ上にシリアルコンソールを用意しておき、電話回線等が考えられるが第二の保守経路を経由してＴ（４１００）の復旧をはかる等をするとよい。
【実施例２】  実施例１と同様の環境であって、かつ同様にＳＮＭＰをあらかじめ合意された通信の方式に用いるものであって、ｓｙｓＮａｍｅの替わりに、ｓｙｓＮａｍｅと比較して使うことの出来る文字列の制限が少ないｓｙｓＬｏｃａｔｉｏｎを用いる事もできる。ｓｙｓＬｏｃａｔｉｏｎを用いる場合には、一般に「答えるべき返事」の値にＢの置換え後の文字列を用いる場合である。ただし、Ｂそのものを用いることもできる。この場合は、ｓｙｓＬｏｃａｔｉｏｎにＢそのものを設定すればよい。
なお、設定に必要な項目は表０２を参照されたい。
実施例１および実施例２は、ともに合意された通信の方法にＳＮＭＰを用いるものであるので、その注意点を以下に挙げる。
ＳＮＭＰは通信可能な状態であれば、Ｔ（４１００）のシステムの状態をほぼ何でも知りうる。また、設定変更も可能である。
本発明はＳＮＭＰの強力な管理機能を利用することが目的ではなく、見失われがちな動的ＩＰアドレス割当てを受けた本来なら特定できないホストが、本当に意図している相手として正しいかどうかを確認しようとするものである。ここで、後続する従来の管理に接続しようとするならば、後続する管理の方法はＳＮＭＰである可能性が高い。この場合、ＳＮＭＰはＴ（４１００）において既に利用可能な状態となっているはずのものなので、この環境をそのまま利用するものとして、ＳＮＭＰを真偽の判定に用いてみた（後続する管理が不要な場合やＳＮＭＰ以外の方法で到達性確認をおこなう場合については後述する）。
ＳＮＭＰを合意された通信の方式（すなわちサイン）に用いる上で、セキュリティ上、以下の点に注意した方がよい。本発明では実験環境としてコミュニティ名は初期値であるＰＵＢＬＩＣを用いたが、初期値のままでは侵入者を含め誰でもアクセスできてしまうため、本番環境ではＰＵＢＬＩＣやＰＲＩＶＡＴＥ等の初期値を決して用いてはいけない。また、Ｔ（４１００）側においてＳ−１（２０００）のＩＰアドレスがわかっている場合には、Ｓ−１（２０００）のＩＰアドレス以外からのアクセスを受付けない等のアクセス制御もあわせておこなうべきである。
【実施例３】  実施例１および２はＴ（４１００）が直接ダイヤルアップしていた。実施例３では、Ｔ（４１００）が直接ダイヤルアップするのではなく、間に網接続機器が介されており、この網接続機器がダイヤルアップする場合である。
ＩＳＤＮルータ等と呼ばれるダイヤルアップルータ、あるいはブロードバンドルータ等と呼ばれるＰＰＰｏＥ、ＰＰＰｏＡ、ＤＨＣＰ等によってＩＰアドレスを取得できＩＰマスカレード等の動的なネットワーク・アドレス変換（以下、「ＮＡＴ」とする。ＮＡＰＴを含むものとする）を用いてＬＡＮ上の複数のパソコンにグローバルサービスを受けさせるような網接続機器（以下、「ＮＡＴＢＯＸ」とする）がダイヤルアップし、Ｔ（４１００）はカスタマのＬＡＮにのみ接している場合（図３７の接続形態４乃至接続形態６のいずれかを参照）には、網接続機器に静的ＮＡＴあるいはポートフォワーディング等の設定をすることによって、Ｔ（４１００）が直接ダイヤルアップしていなくても（直接インターネットに接していなくても）実施例１や実施例２と同様にＳ−１（２０００）から真偽の判定ができる。
この場合の条件はダイヤルアップする機能がＴ（４１００）でなく網接続機器であること、静的ＮＡＴあるいはポートフォワーディング等の設定が網接続機器になされていること等をのぞけば、Ｔ（４１００）にＳＮＭＰエージェントを実装されておりかつ設定されていることを含め、実施例１および２と同様である。
【実施例４】  実施例３と同様に計算機が直接にダイヤルアップするのではなく網接続機器がダイヤルアップする場合において、ダイヤルアップルータ等の網接続機器がＳＮＭＰを実装していれば、これをＴ（４１００）として利用することが出来る。
伝統的なＵＮＩＸの考え方では、ＩＰアドレスを割当て可能な装置はすべてホストと呼ばれる。本発明では、この考え方を援用してルータやＮＡＴＢＯＸであろうとも、ＩＰアドレスが割当てられていれば（すなわち通信ノードでありさえすれば）、ホストと呼ぶこととする。すなわち、実施例４ではダイヤルアップするルータがＴ（４１００）たるホストである。Ｔ（４１００）はＳＮＭＰを実装していることからダイヤルアップルータ等の網接続機器である（図３７の接続形態２参照）が、この際に、前記ルータにＩＰマスカレード等の動的ＮＡＴの機能があれば、前記ルータにＤＮＳへの動的更新する機能がない場合でも、ＬＡＮ上のパソコンにＤＮＳ更新させることもできる（図３７の接続形態３を参照）。
この場合においては、ダイヤルアップルータにＤ（１０００）に登録され動的更新されるホスト名と同じ名前を設定すれば実施例１と同様にＳ−１（２０００）からＴ（４１００）の真偽を判定することができる。しかし、実施例２のようにｓｙｓＬｏｃａｔｉｏｎを用いてより柔軟な任意の文字列を、Ｔ（４１００）が返すべき返事として合意した方がスマートな構成となる。
【実施例５】  実施例５は、あらかじめ合意された通信の方式に、ＤＯＭＡＩＮ（ＤＮＳ）を用いるものである。
Ｔ（４１００）は計算機であり、ＢＩＮＤを実装しており、バージョン情報が設定（明示的に変更）されているものとする。ここでは、あらかじめ合意された通信の方式にＤＯＭＡＩＮ（ＤＮＳ）を用い、双方で合意された返事にこのバージョン情報を用いるものとする。
Ｔ（４１００）は、直接ダイヤルアップ接続しているか、あるいは網接続機器経由で静的ＮＡＴあるいはポートフォワーディングの設定がされているものとする。
Ｓ−１（２０００）では、監視プログラムをタイマ実行している。
その他の条件や設定内容は実施例１と同様とする。
準備段階として、以下の件が合意され設定されているものとする。
Ｔ（４１００）に設定される、あらかじめ合意された方式での通信に対する答えるべき返事はＴ（４１００）で動作するＢＩＮＤが返す任意の文字列に変更されたバージョン情報とする。
グローバルなインターネット向けの名前サービスを提供していない場合でも、局域的なＬＡＮ環境の為にＴ（４１００）はＤＮＳサービスを提供することができる。
図３２に、Ｔ（４１００）において設定する、ＢＩＮＤにおけるバージョン情報の設定の仕方を示す。
ＢＩＮＤの標準的な動作として、このバージョン情報は明示的に設定されていないと、図３５のように通常はプログラムそのもののバージョンを返す。もともとは網を経由した攻撃者に対して、プログラムのバージョン情報がわかると攻撃する時の方法も明らかになるので、攻撃者の手間を増やす為に、バージョン情報をわざと変更していたものである。しかし任意に設定できることから、Ｂの置換え後の文字列を答えるべき返事として、ここでは例示する。
ふたたび図２３を参照されたい。
Ｓ２０２およびＳ２０４はアドレス確認である。実施例１と同様である。
Ｓ２０６では上で求められたＴ（４１００）のＩＰアドレスに対して、あらかじめ合意された方式での通信をおこなっている。
Ｓ２０８では、返事が返ってきた場合には返ってきた返事を一時的に記憶し、返事が返ってこなかった場合には、Ｓ２０６の終了コードを一時的に記憶する。
図３３に、ｄｉｇでＢＩＮＤにおけるバージョン情報を引いた場合の出力例を示す。下線部がＳ−１（２０００）に設定された、Ｔ（４１００）からの返事であるべき、あらかじめ合意された方式での通信に対する答えられるべき返事にあたる部分である（図３２下線部）。
ここには任意の文字列を用いることができるが、答えるべき返事の類型に従う。
図３４に、Ｔ（４１００）がかつて割当てられていたＩＰアドレスを現在割当てられているホストが存在しない場合および、Ｔ（４１００）がかつて割当てられていたＩＰアドレスを割当てられているＴ’（４２００）が存在する場合であって、そのＴ’（４２００）でＢＩＮＤが動作していなかった場合を示す。
エラー出力に出力されるエラーのみ四角で囲んであり、その他は標準出力に出力されるエラーである。
図３５に、Ｔ（４１００）がかつて割当てられていたＩＰアドレスを割当てられているＴ’（４２００）が存在する場合であって、そのＴ’（４２００）でＢＩＮＤが動作していた場合を示す。この場合はｄｉｇコマンドの出力としてはエラーにならない為に、Ｓ２１２で判定されるべきである。
Ｓ２１０では、この通信の返事に対して、文字列処理をして、Ｔ（４１００）で動作するＢＩＮＤのバージョン情報を抽出する。
Ｓ２１２では、この返事を、Ｓ−１（２０００）に記憶された答えられるべき返事との比較をおこない、判定する。
カウンターサインによってＴ（４１００）からキャリーされた答えるべき返事とＳ−１（２０００）に記憶された答えられるべき返事とが一致した場合Ｓ２１４では、Ｔ（４１００）は正しい到達性を有するホストである。Ｓ２１４では、実施例１と同様にログファイル等に書出すなり後続する通常の監視へ進むなりした方がよい。
一致しない場合Ｓ２１６でも、実施例１と同じようにすればよい。
【実施例６】  実施例６は、あらかじめ合意された通信の方式に、ＳＭＴＰを用いるものである。
Ｔ（４１００）は計算機であり、ＳＭＴＰサーバを実装しているものとする。ここでは、あらかじめ合意された通信の方式にＳＭＴＰを用い、双方で合意された返事にＴ（４１００）のホスト名（ＦＱＤＮ）を用いるものとする。
Ｔ（４１００）は、直接ダイヤルアップ接続しているか、あるいは網接続機器経由で静的ＮＡＴあるいはポートフォワーディングの設定がされているものとする。
Ｓ−１（２０００）では、監視プログラムをタイマ実行している。
その他の条件や設定内容は実施例１と同様とする。
Ｔ（４１００）に設定される、あらかじめ合意された方式での通信に対する答えるべき返事はＴ（４１００）に設定されたホスト名そのものとする。
ＳＭＴＰサーバに接続した時には多くの場合、図３６のようなメッセージを出力する（例はＳＭＴＰサーバとして最も普及しているＳＥＮＤＭＡＩＬの場合であるが、ＳＥＮＤＭＡＩＬに次いで普及しているＱＭＡＩＬの場合でも、メッセージ中にホスト名が含まれるか含めることができる）。
このメッセージには、ホスト名がＦＱＤＮで表示（図３６下線部参照）されているので、これをＴ（４１００）が到達可能であるかどうかを判定する識別子すなわち答えるべき返事に用いることができる。
【実施例７】  実施例７は、あらかじめ合意された通信の方式に、ＨＴＴＰを用いるものである。
Ｔ（４１００）は計算機であり、ウェブサーバを実装しているものとする。ここでは、あらかじめ合意された通信の方式にＨＴＴＰを用いる。すなわち、Ｔ（４１００）で待受けするサービスがウェブサーバであることから、双方で合意された返事には、どのような文字列でも用いることができる。
Ｔ（４１００）は、直接ダイヤルアップ接続しているか、あるいは網接続機器経由で静的ＮＡＴあるいはポートフォワーディングの設定がされているものとする。
Ｓ−１（２０００）では、監視プログラムをタイマ実行している。
その他の条件や設定内容は実施例１および２と同様とする。
Ｔ（４１００）に設定される、あらかじめ合意された方式での通信に対する答えるべき返事はＴ（４１００）で動作するＨＴＴＰサーバが返す文字列中に埋め込まれた任意の文字列とする。
計算機系の技術者以外の人にとっても馴染み深いものである為に、おそらくウェブサーバは、Ｔ（４１００）もしくはカスタマの網におけるＴＣＰ／ＩＰサービスを提供するサーバにおいて、最も提供したいサービスのひとつだろう。ＨＴＴＰでは、どのような文字列でも転送することができることから、これを合意された通信の返事として利用可能である。多くのウェブサーバはファイル名の指定がない場合は、ｉｎｄｅｘ．ｈｔｍｌという名前のファイルが開かれる（ウェブサーバからクライアントへ転送される）。ここに返事となるべき文字列を記述しておくだけでよい。例えばトップページのｉｎｄｅｘ．ｈｔｍｌ中、本文の３ワード目の文字列を合意しておく等である。しかし、これでは更新の際に誤って本文の３ワード目の文字列を変更してしまったりすることがあるので、別のファイル名を合意しかつそのファイル中の特定の文字列を返事として合意しておいた方がよい。また、ＨＴＭＬ文の＜ＭＥＴＡ＞文中に埋め込むこともできるし、＜ＴＩＴＬＥ＞を合意した返事として用いることもできる。要するに、ＨＴＴＰを用いる場合には、合意された通信の方式と意図された返事の境界があいまいになる。例えばＵＲＬ中に特定のディレクトリ名とファイル名を含む場合、これは通信の方式と考えるべきであろう。では、ここで転送されたＨＴＭＬ文中の本文の３ワード目は、返事とみなすべきだろうか？これもやはり通信の方式として合意すべきだが、実施例１や実施例２、あるいは実施例５のようなプロトコルによる制約がない分、より具体的な合意が必要であることに注意した方がよい。
また、ＨＴＴＰＳを合意された通信に用いる場合であって、Ｔ（４１００）にＳＳＬサーバ証明書が組み込まれている場合には、ＳＳＬサーバ証明書のシリアルナンバやフィンガープリントか、あるいは単にオーガニゼーション名やカンパニー名、サーバ名等のいずれかを利用することもできる。
実施例１や実施例２の場合は、Ｔ（４１００）の確認をするＳ−１（２０００）以外からのアクセスを制限する方向であったが、実施例１や実施例２と違い、通信の方式にＨＴＴＰを用いる場合は、むしろ公開サーバとして、より多くの人から確認できるようにしたい場合に有効であろう。
ところで、ＨＴＴＰは通常ＴＣＰポートの８０番で待受けするが、しばしば別のポート番号に意図的に変更して待受けされることがある。このような場合でも、変更されたＴＣＰポート番号がＳ−１（２０００）とＴ（４１００）の間で合意されていれば、Ｔ（４１００）が正しい到達性のホストであるか否かを確認する為に用いることができる。
また、静的ＮＡＴでもポートフォワーディングでもないが実施例３との複合型として、ＮＡＴＢＯＸは、例えば８８番ポートでＮＡＴＢＯＸ自体の設定変更のためのウェブアクセスを受付け、８０番ポートでリバースプロクシが動作しているような場合には、リバースプロクシによる転送先ウェブサーバにおいて、実施例７のあらかじめ合意された通信を実装可能である。
以上実施例１乃至実施例７は、答えるべき返事をどのように返すかについて説明してきた。ここでは理解されやすいように、既存のＤａｅｍｏｎを利用して説明してきた。これが流用の例である。この際には「（５）の過程を担う者」で説明したように、Ｔ（４１００）を実装すべきである。
【実施例８】  実施例１乃至実施例７におけるＴ（４１００）側の接続形態について、説明する。
実施例８では、Ｔ（４１００）がダイヤルアップルータあるいはＮＡＴＢＯＸ経由で接続している場合とＴ（４１００）が直接ダイヤルアップをしている場合とを問わず、Ｔ（４１００）の記憶装置に任意の情報を答えるべき返事として保存し、あらかじめ合意された任意の方式での通信に対して前記保存された情報を記憶装置より読み出し、少なくとも前記情報を含めた返事を返信することさえ出来れば、通信の方式を問わずにＴ（４１００）が正しい到達性のホストであるか否かを確認する為に用いることができる。この例は実施例７の通常でないＴＣＰポートで待受けするウェブサーバの例を既に挙げた。あるいはＦＴＰサーバへクライアントが接続する際に表示されるウェルカムメッセージもあらかじめ合意された通信の方式として用いることができる。その外、Ｓ−１（２０００）とＴ（４１００）の間で合意されていれば、独自プロトコル等の一般的でない（ウェルノウンでない）通信の方式でも同様に合意された通信の方式として用いることができる。
Ｔ（４１００）は、機能的に以下に分割され得る。ａのダイヤルアップするホスト、ｂのＤ（１０００）へ動的更新をするホスト、ｃのＴ（４１００）の機能を有するホストである。これらの機能は、各機能毎に異なるホストに分散されていてもよいし、各機能が１のホストに集約されていてもよい。これらの関係は、網の接続形態によって影響される。
Ｔ（４１００）のカスタマ網における接続形態を図３７にまとめる。
モデム上部の雷型の線は電気通信回線を意味し、その上部にある楕円は網の雲を意味する。最上部の小さく描かれた四角がＳ−１（２０００）である。
モデムとは、通常変復調装置を指すが、ここではケーブルモデムやＡＤＳＬモデム（やＴＡ）等を（あるいはデジタル回線終端装置（＝Ｄｉｇｉｔａｌ  Ｓｅｒｖｉｃｅ  Ｕｎｉｔ）や光終端装置（＝Ｏｐｔｉｃａｌ  Ｎｅｔｗｏｒｋ  Ｕｎｉｔ）等があるときは、説明の便宜上これをも）含み、ルーティング機能を提供しない、通信路上の物理的な境界を構成する装置を指すこととする。図３７ではモデムを独立した装置として描いたが、網接続機器や計算機に組込まれている場合がある。モデムに類する機能が、網接続機器や計算機に組込まれている場合には、網接続機器や計算機としてあつかうこととする。よって本発明では、モデムは通信の機能上必要なものであっても、ＴＣＰ／ＩＰ的な網境界を構成しないことから、モデム単独については考慮しないものとする。
図３７で、モデムのすぐ下に描かれているものは、必ずダイヤルアップする機能を有するものである。これに属するものは、網接続機器と計算機がある。
網接続機器とは、ルーティング機能あるいはプロトコル変換機能を提供し、ＴＣＰ／ＩＰ的な網境界を構成する装置を指すこととする。図３７では、「ルータ等」と表記している。
計算機とは、利用者によってプログラム可能なものを計算機と呼ぶこととし、仮に計算機が網接続機器と同様の機能を有している場合であったとしても、この点において網接続機器と区別されることとする。利用者端末等もこれに含まれる。
以下各接続形態に応じて、Ｔ（４１００）がどの装置であるかを中心に説明する。
実施例１の典型を接続形態１とする。これは、計算機が直接ダイヤルアップする場合である。実施例２も同じである。この形態では、ｂのＤ（１０００）を更新するホスト、ｃのＴ（４１００）の機能を有するホストがａのダイヤルアップするホストと同一の場合である。この場合において、ａのダイヤルアップするホストすなわち計算機が網境界を構成する。このことから、例えばＮＡＴを実装している場合やＶＰＮトンネリングしている場合のように網接続機器の機能を有しているか、アプリケーションゲートウェイを構成していれば、破線部分の計算機に対して、網接続を提供することも可能である。
実施例４は、網接続機器を介して計算機が接続される場合であって、網接続機器がｃのＴ（４１００）の機能を有するホストである場合である。典型例が接続形態２である。また、接続形態２に対して、網接続機器がＤ（１０００）を更新できない場合に、ｂのＤ（１０００）を更新するホストを計算機とした場合が、接続形態３である。
実施例３および実施例５乃至実施例７では、ａのダイヤルアップするホスト、ｂのＤ（１０００）を更新するホスト、ｃのＴ（４１００）の機能を有するホスト等が機能的に分割され、この機能が計算機および網接続機器に分散されている場合である。この場合の典型が接続形態６である。ここで、例えば接続形態４の場合は、網接続機器がＤ（１０００）を更新できる場合であって、かつＴ（４１００）たりえない（すなわちｂの機能があって、ｃの機能がない）場合にこのような構成をとることができる。なお、接続形態４乃至接続形態６において、ａのダイヤルアップするホストはルータ等とされているが、接続形態１の応用としてこれは計算機によっても代替し得る。ここで、網接続機器がダイヤルアップすることを明示している実施例３および実施例４を除けば、一般に計算機は網接続機器と比してソフトウェアを追加することによってｃのＴ（４１００）の機能を有するホストとしてもｂのＤ（１０００）を更新するホストとしても用いることができることから、接続形態１はどの実施例にも用いることができる。すなわち実施例３および実施例４（網接続機器がダイヤルアップすることが明記されている場合）を除き、ａの位置にあるルータ等は計算機であってもよい。この場合、ａのダイヤルアップするホストには、少なくともｃのＴ（４１００）の機能を有するホストに対して静的ＮＡＴあるいはポートフォワーディング等が設定されているものとする。図３７ではモデムのすぐ下にａのダイヤルアップするホストがあるが、この下には計算機だけではなく、網接続機器があってもよい。これはカスタマ網を構成するＬＡＮが多段のＬＡＮを構成していてもよいことを示す。
実施例５乃至実施例７は、すべての接続形態で用いることができる。ただし、実施例５乃至実施例７を接続形態２や接続形態３に適用する場合には、網接続機器がサインに対し、答えるべき返事をキャリーするカウンターサインを返し得るように構成できる必要がある。
ａのダイヤルアップするホスト、ｂのＤ（１０００）へ動的更新をするホスト、ｃのＴ（４１００）の機能を有するホストは、同一のＬＡＮ上（あるいは同一の場所）に設置されるものとするすると、広域の網から見れば、このＬＡＮは網端側にあることになる。ここで広域の網をインターネットとした場合（正確にはＮＡＴを必要とする場合）、広域の網を経由した通信では、ａ、ｂ、ｃのそれぞれを識別することはできない。よって、このＬＡＮは外部に対して単一の通信ノードのように振舞う、計算機および網接続機器の集合である（インターネット・サービス・プロバイダーへの端末型ダイヤルアップのようにＬＡＮを構成しておらず、端末一台のみの場合にあっても同じである）。これを本発明では、カスタマ網もしくはエンドサイトと呼ぶこととする。エンドサイトは特に広域の網から見た場合のエッジ側を指すものとして扱うが、着目点が違うだけでカスタマ網と同じ物を指している。図３７のモデム以下の点線で囲まれた部分である。接続形態１から接続形態６は、カスタマ網の内訳であり、Ｓ−１（２０００）から見れば、カスタマ網が接続形態１から接続形態６のいずれの類型に属していようと、ａ、ｂ、ｃのそれぞれを識別することはできないという点で共通している。そのため、Ｓ−１（２０００）ではカスタマ網の構成やＴ（４１００）がカスタマ網のＬＡＮ上でどこに、位置しているかについて考慮する必要がない。
なお、カスタマ網はプライベートＩＰアドレスが使用されている状態を仮定している。このため、インターネットからは、カスタマ網に対して、直接ルーティングされることはない。ａのダイヤルアップするホストは、インターネットとカスタマ網の接点を構成する。ルーティングはａのダイヤルアップするホストで止まるから、インターネットからｂ、ｃには直接到達できない。
上記は、広域の網をインターネットとした場合であった。
ところが、広域の網としては、インターネット以外にも、第一種電気通信事業者や第二種電気通信事業者が提供するかあるいは自営網によるインターネットに接続されない、ＴＣＰ／ＩＰによる網が考えられる。この場合には、ＮＡＴを前提とするのでなく、ルーティングによって別の網にあるＤ（１０００）やＳ−１（２０００）からＴ（４１００）へのアクセスが、直接にＴ（４１００）に到達できる場合がある。
実施例１乃至実施例７では、説明上インターネットと表現してきた。しかし、グローバルなインターネットでのみ本発明は実施可能なものではなく、実際はＴＣＰ／ＩＰを用いた通信でありさえすればよい。
カスタマ網と外部網の関係を表０３に示す。
2004059925.tif 000005
▲１▼は、インターネットサービス・プロバイダーへの端末型ダイヤルアップのようにＬＡＮを構成しておらず、端末一台のみの場合を指す。この場合はＬＡＮを構成していないが、インターネットに接している為に、やはり網に接続されている（スタンドアロンではない）ものとみなす。ＬＡＮを構成していないことから、カスタマ網は存在しないのではとの議論がありうるが、ループバックのみのカスタマ網が存在し、ＷＡＮ接続されているものと考えればよい。▲３▼および▲５▼は、▲１▼に準ずるものとする。
▲２▼は、代表的なインターネット接続の場合である。これまでの説明は、このパターンを想定して、説明してきた。以下、このパターンとの相違点がどのように影響するかについて、説明する。
▲４▼は、第一種電気通信事業者や第二種電気通信事業者が提供するインターネットに接続されない、ＴＣＰ／ＩＰによる網をＷＡＮとする場合である。パソコン通信やフレッツ（登録商標）オフィス等がこれに該当する。▲２▼の場合と同様に扱って問題ない。Ｄ（１０００）が私設のものであることは、従来からあるプライベート網に使用するドメイン名の命名規則において制限があるのみで、本発明には影響しない。
▲６▼は、自営網による場合である。自営網は一般に組織内の利用の為に、専用線（および類似の役務。例としてＡＴＭメガリンクやＩＰ−ＶＰＮ等を挙げておく）等によって構成され、ルーティングされているものをいう。▲４▼の場合は、ＩＰ−ＶＰＮ等の契約がなければ通常はカスタマ網（の内側。網端までは当然に到達するので）へのルーティングは提供されない。しかし、第一種電気通信事業者や第二種電気通信事業者が提供する役務であって、ルーティングがされる場合は、▲６▼に含めて考えた方が筋道がよい。網境界を越えて、外部網がルーティングによって直接にカスタマ網上のホストにアクセスできる場合である。すなわち、この場合は、Ｔ（４１００）がモデムのすぐ下に位置しない場合であっても、ａのダイヤルアップするホストは上流の網からＩＰアドレスを動的に割当てられるのではなく、カスタマ網上のＤＨＣＰサーバ（ＤＨＣＰリレーされている場合を含む）からＩＰアドレスを動的に割当てられ、かつＴ（４１００）であるという点で、図３７の接続形態１乃至接続形態３に相当することになる。ところで、古くから自営網を運用している会社や大学の中には、ＩＰアドレス体系がグローバル・アドレスになっているところがある。このような自営網は、インターネットそのものの構成要素であるものと考えてさしつかえない。
▲８▼は、ＬＡＮのみで構成された網にあって、ＬＡＮが多段となっている場合である。例を挙げると、１の事業所であって、フロア毎に別の部に分かれている場合に、各フロアが事業所内バックボーン・網を経由して相互に接続されている場合等である。ＷＡＮが存在しておらず、インターネットに接続しない場合やインターネットに接続しない広域の網に接続しない場合か、仮にインターネットに接続していたとしてもこの接続を無視できる（セキュリティポリシが強力な組織等にあってインターネット等へ接続する際に障壁が大きい）場合であるという特徴を除けば、自営網の場合と酷似する。ここで、ＬＡＮが多段になっているとは、単にハブ等によって多段となっているだけではなく、論理セグメントが分かれており、ルーティングされている状態を指す。この場合、Ｓ−１（２０００）の接するＬＡＮがＴ（４１００）の接するＬＡＮとは別のＬＡＮであれば、Ｔ（４１００）の接するＬＡＮをカスタマ網と考え、▲４▼▲６▼と同じと考えればよい。
以上は、物理セグメントと論理セグメントがともに分かれている場合であったが、例外として、物理セグメントが１で論理セグメントのみ２以上に分かれている場合、例えば１のインターフェースに異なる網に属する２以上のＩＰアドレスを割当て、これを中継するよう構成されたゲートウェイ装置等がある場合には、単一の（＝一段の）ＬＡＮの場合と同様となる。
▲７▼は、単一のＬＡＮの場合である。本発明は実施可能だが、ＬＡＮが一段のみの場合すなわち外部網がまったく存在しない場合には、ＴＣＰ／ＩＰ的な中継を要せず、各ホストがすべて直接かつローカルに通信できるので、動的ＩＰアドレス割当てのホストであっても、わざわざ私設のＤ（１０００）を参照することなく、ＴＣＰ／ＩＰ以外のプロトコルによって、到達性確認をした方が現実的であろう。
当然のことであるが、Ｔ（４１００）がスタンドアロンの場合を、本発明では考慮していない。通信する相手が存在しないからである。
なお、▲２▼▲４▼▲６▼の場合は▲８▼と共存する。
以上によって、（▲７▼の場合に意味があるかどうかは別論だが）▲１▼乃至▲８▼のすべてのパターンで本発明を実施可能である。
ここで図３８に、主に多段のＬＡＮの場合に問題になり得る点について説明する。図３８は、カスタマ網におけるＬＡＮの内訳でもあるが、自営網の場合およびインターネットに接続されない電気通信事業者が提供する役務の場合も同様であるものとし、この場合にあってはカスタマ網はＴ（４１００）が直接接続されている部分を指すものと考えられる。網１および網２は、それぞれＬＡＮの場合とＷＡＮの場合がある。
図３８には、パターン１乃至パターン３までを挙げた。パターン２およびパターン３は、表０３における▲４▼▲６▼と類似のパターンであって問題がない。ここで問題となり得る場合は、パターン１の場合であって、網１がＬＡＮの場合である。表０３における▲７▼に挙げた単一のＬＡＮの場合と同様に、Ｔ（４１００）とＳ−１（２０００）とが同一のＬＡＮ上にあるため、ＴＣＰ／ＩＰ以外のプロトコルによって、到達性確認をした方が現実的と考えることができる。しかし、この場合であっても、別の網上にＴ（４１００）が存在し、かつここでいうＳ−１（２０００）が前記Ｔ（４１００）をも管理するものとすれば、本発明を実施する意義はじゅうぶんにあると考える。なぜならば、別の網上のＴ（４１００）を管理する際には、本発明の実施が必要なものであって、Ｓ−１（２０００）が集中管理する為には、管理の方法を統一した方がよいからである。なお、表０３の▲８▼においてパターン２のように装置が配置されている場合は、Ｔ（４１００）から見てＳ−１（２０００）やＤ（１０００）が外部の網に属しているという点で、表０３の▲２▼▲４▼▲６▼の場合に相当する。
なお、ＴＣＰ／ＩＰ以外のプロトコルはルーティングされないものとする。
Ｐ（４０００）はＴ（４１００）を含む網であると考えられるので、今度はＰ（４０００）の観点から、機能が複合した場合の特徴について説明する。なお、図３８ではＴ（４１００）を含む網１がＰ（４０００）にあたる。Ｐ（４０００）がＤＨＣＰである場合であっても、網１はＤＨＣＰサーバを含む網であるとして、以下説明する。また、網２はここでは単に網１でない網とする。
機能が複合した場合の特徴
Ｓ−１（２０００）とＰ（４０００）が一体となっている場合。図３８のパターン１の場合である。
Ｐ（４０００）の網に属するＴ（４１００）に関して、後述する条件１によって、Ｓ−１（２０００）は本発明によらずにＴ（４１００）の到達性を確認出来る。しかし、Ｔ（４１００）とＤ（１０００）は異なる網に属しているため、実像と写像のの関係の正しさについて、Ｓ−１（２０００）は確認することができない。すなわち、Ｔ（４１００）に関してＤ（１０００）によって獲得するホスト識別性については、本発明の到達性確認を要する。
Ｓ−１（２０００）とＤ（１０００）が一体となっている場合。図３８でいうパターン２の場合である。
アドレス確認は不要である。この他別の効果もあるが、これについては後述する実際的応用の第三のフィルタ例で説明する。
Ｄ（１０００）とＰ（４０００）が一体となっている場合。図３８のパターン３の場合である。
ＩＰアドレスの割当て主体であるところの、Ｔ（４１００）を含む網すなわちＰ（４０００）と、Ｄ（１０００）とが同一の組織に属する場合である。
先に説明したように、一般的にこの場合は問題がない。
しかし、条件１から、Ｐ（４０００）がＤ（１０００）を更新する場合は、境界線上の場合である。
条件１
Ｐ（４０００）は特別な立場にある。
Ｐ（４０００）とは、ここではＴ（４１００）に対しＩＰアドレスを割当てるものをいう。
よって、当然にＰ（４０００）はＴ（４１００）のＩＰアドレスを把握しているものとする。
そして、当然にＰ（４０００）はＴ（４１００）が接続しているか接続してないかをも把握できる。
以上を条件１とする。
さらに、Ｐ−Ｄ（４５００）は、逆引きの設定が可能である。「静的な識別子と動的な住所の関連付けにおける一方向性」で説明した、「ＤＮＳは正逆あるが、ダイナミックＤＮＳは正引きのみである」と書いた前記に反する場合である。Ｐ（４０００）とＤ（１０００）が一体となっている以上、Ｐ−Ｄ（４５００）はＤ（１０００）と同一の場合であり、この場合には、管理権限の問題が発生しないためＰ（４０００）はＰ−Ｄ（４５００）すなわちこの場合はＤ（１０００）を更新することができる。ただし、Ｐ−Ｄ（４５００）とＤ（１０００）が同一の場合とは、Ｐ−Ｄ（４５００）がＴ（４１００）のアナウンスする静的な識別子を公示するもの（すなわちＤの機能を有するもの）である場合に限られる。
以上から、Ｐ（４０００）はＴ（４１００）の状態の変化を知ることができ、かつ、Ｔ（４１００）の状態の変化をＤ（１０００）に反映することができる。
よって、ダイナミックＤＮＳにおけるホスト名そのものが、追従性および識別性を有する場合である。
ここでは、静的な識別子による外部の網からの参照可能性のことを、ホスト識別性という。
到達性を確認するまでもなく、もとから網におけるホスト識別性を有するホストに対しては、到達性確認のプロセスによって、はじめて真偽が分かる訳ではない。
よって、境界線上の場合である。
ただし、Ｐ（４０００）とＤ（１０００）を完全に連携させることはかなり複雑な設定を必要とする。そのため、チェックの為に本発明を用いることはよい。
また、Ｄ（１０００）がＤＮＳの場合、外部の網からのアクセスについてはキャッシュの影響を受ける。
ここまで、場合分けして説明してきたが、複雑でわかりにくいものである。これは網の接続のされ方を網羅的に説明する困難さに起因すると思われるので、以下のように、ＬＡＮがＷＡＮかを問わず、ルーティングがどこで止まるかによって、大別できる。
ルーティングによって、直接Ｔ（４１００）に到達できる場合にはＳ−１（２０００）は、当然にＴ（４１００）の１つ１つを別のホストとして識別できる。この場合においては、Ｔ（４１００）は、ダイヤルアップする（動的アドレス割当てを受ける）機能と、Ｄ（１０００）を更新する機能とＴ（４１００）であることの機能を備えていなければならない。そして、この場合は、比較的単純な場合である。
ルーティングがダイヤルアップするホストで止まる場合には、ダイヤルアップするホストにおいてポートフォワーディング等によって、外部網からはＴ（４１００）にＳ−１（２０００）からのアクセスが到達するようにするかダイヤルアップするホストをＴ（４１００）としなければならない。これはルーティングによって到達できる場合と比べてやや複雑であり、具体例については既に実施例として詳述した。ダイヤルアップする（動的アドレス割当てを受ける）機能と、Ｄ（１０００）を更新する機能とＴ（４１００）たる機能（すなわちカウンターサインを返す機能亦は到達性を確認させる機能）は、独立した３のホストが担ってもまた集約された１のホストが担ってもよいが、外部からはカスタマ網の代表として、Ｔ（４１００）が確認されるという点で特徴がある。
【実施例９】  ルータ等の網接続機器であって、設定変更用のウェブインターフェースを有する場合は、ウェルノウンポート（ＲＦＣ１７００  ＡＳＳＩＧＮＥＤ  ＮＵＭＢＥＲＳでいうところのウェルノウンポートと同じか類似するもの）に従って８０番ポートで待受けする。ファイヤウォール等の一部の機器は、例えば８８番ポート（等の８０番ポート以外のポート）で設定変更のためのウェブアクセスを待受けする場合がある。最近のエンドサイト向けのこれらの製品はＷＡＮ側とＬＡＮ側に分かれてインターフェースを用意しており、多くの場合、ＷＡＮ側ポートにはアクセス制御が施されている。
ここで、網接続機器において（ファイヤウォールでなくとも）、設定変更のためのウェブアクセスの待受けを８８番ポート（等の８０番ポート以外のポート）でし、アクセス制御されるものとする。この際、８０番ポートで通常のウェブアクセスを待受け、これにはアクセス制御等を施さないものとする。８０番ポートでリバースプロクシを動作させ、リバースプロクシによる転送先ウェブサーバにおいて、実施例８のあらかじめ合意された通信を実装可能とするのも手なのだが、ここで、装置にはホスト名が登録されるものとし（エンドサイト向け製品の内、低価格製品の多くにはホスト名の設定ができないものがある）、このホスト名は写像を公示するＤ（１０００）において設定されるＦＱＤＮで登録されるものとし不揮発メモリ等の記憶装置に保存され、８０番ポートへの通信要求を受けた際に、前記保存されたＦＱＤＮを記憶装置より読み出し、該ＦＱＤＮすなわちホスト名を含めた文字列を返信するように構成する。
Ｓ−１（２０００）がＴ（４１００）に対して通信を試みる方法として、このように実施例４のように網接続機器に対して、実施例７のようにＨＴＴＰを合意された通信の方式として用い、実施例１のように（ＳＮＭＰのｓｙｓＮａｍｅではなくＨＴＴＰだが）ＦＱＤＮを返事として合意した方法等のように実施例を組合せた方法として用いることができる。なお、カスタマ網上の位置だが、図３７の接続形態のすべての場所だけでなく、接続形態６における計算機の位置にあっても、既に説明したように機能するものであって、ここで構成した装置が網接続機器であった場合に、配下に別の網を有している場合が考えられる。また、ここで構成した装置が直接図３７におけるａのダイヤルアップするホストである必要は必ずしもない。
このとき仮に、ここで述べた機器が図３７にいうａのダイヤルアップするホストであって、網の到達性からＮＡＴを必要とする網である場合には、８０番ポートを上記のようなサイン・アンド・カウンターサインに用いてしまうと、ウェブサービスを提供する際にポートフォワーディング等が必要であるから、ウェルノウンでないポートをアナウンスしなければならなくなる。これでは、カスタマ網においてウェブサービスを提供しようとする場合の利便性をそこなうことになる。そこでウェブサービスを提供したい場合には、類似のポートでサインを待受けするようにするとよい。すなわち、ＨＴＴＰアクセスを待受けするポートにおいて、機器設定用のポート、サイン・アンド・カウンターサインを用いた網管理用のポート、一般の閲覧に供するためのウェブサービスを提供するウェルノウンなポート（ただし、ここで述べた機器が応答するのでなく、ポートフォワーディング等してもよい）のように３種類のポートで待受けするように構成することもできる。
これを実施例９とする。実施例９では通信の方式をＨＴＴＰ固定とし、返事をＦＱＤＮとすることによって、単純化した。通常、網接続機器にあっては、いわゆる計算機に比して拡張性に劣るものである。これは、例えば機能追加する際に単にプログラムを追加実装すればよいというものではなく、ファームウェアの書換え等が必要であって、利用者によっては、簡単にできない等の問題があるものである。そこで、、実施例９は、ルータやＮＡＴＢＯＸ等のように記憶装置の容量に制限がある網接続機器に対しても、あらかじめコンパクトに実装しておくことが可能である。
Ｔ（４１００）としては、網接続機器だけでなく、もちろん計算機であってもよいし、コンパクトに実装可能なことから、カウンターサインを返すためだけの専用の装置でもよい。この場合、専用の装置は、単にＳ−１（２０００）に到達性確認させるためだけの機能を有しておればよく、インターフェースももちろん１でよい。例えば、図３７の接続形態６の場合であって、ｃに位置していたとすると（図３７では計算機だが、これが上記専用の装置の場合）、ダイヤルアップするホストの外側にある網がインターネット等のルーティングによってＴ（４１００）に到達できない網である場合に、ダイヤルアップするホストに静的ＮＡＴやポートフォワーディング等が設定されていれば、外部網からは装置に到達可能である。この場合において、システムは単にＬＡＮ上のＩＰアドレスを割当てられていれば、外部網からは、一体となって参照される為に、ここでいう専用の装置が到達性確認することによって、Ｓ−１（２０００）からは、カスタマ網およびその境界ノードが正しい到達性を有することを確認することができる。つまり、ここでは、単に実施例９を実装した１のインターフェースを有する機器を準備すれば、ポートフォワーディング等の設定をダイヤルアップするホストにするだけで、到達性確認できることになる。このような装置は、単純な為に、安価に製造することができるし、完成品ではなく組込み用の基盤あるいはキットとしても提供できる。また、これをソフトウェアとして実装すれば、計算機に用いる場合でも、設定作業を省略化することができる。この場合は、記憶装置に述べた記憶媒体読取り装置に実装される取り外し可能な記憶媒体とすればよい。
【実施例１０】  Ｔ（４１００）が例えば、モバイル端末である場合に有効な方法を提案する。
ここでモバイル端末とは、例えば携帯電話そのものである場合と、いわゆるＰＣである場合を指す。ここでいうＰＣは、単に一般利用者が用いる計算機による端末を指す。
このような場合には、Ｔ（４１００）の機能はアプリケーションプログラムとして実装してもよい。
しかし、独立したアプリケーションプログラムとしてだけではなく、従来から存在するプログラム、例えば、ブラウザソフトの組込としてもよい。
ブラウザソフトの組込とする場合には、ブラウザソフトを答えるべき返事設定用等の制御用として用い、ブラウザソフトからコールされる別途待受け用の常駐ソフトによって、答えるべき返事を返すようにするとよい。
この際、実施例７等のように既にウェブサーバが実装されている場合にはもちろんそれを利用してもかまわないのだが、別途待受け用の常駐ソフトを用意し、別のポートでサインを待つようにしてもよい。
また、このような常駐ソフトは、停止できるように実装されてもよい。
こうすることには実は別の意図があって、実際的応用に示すＳ−２（５３００）が到達性を確認する場合の、ユーザーインターフェースとして用いることができるからである。
すなわち、ブラウザソフトは、別途コールされる到達性確認用プログラムによって、到達性確認した結果を表示するものともなる。
要するにブラウザソフトは、外部プログラムであるか内部プログラムであるかを問わずに、Ｔ（４１００）の機能とＳの機能の両方を提供するユーザーインターフェースとして、用いることができる。
（実際的応用）
到達性確認は、後続するアクションの有無によらずに、結果を表示（図２３のＳ２１４亦はＳ２１６）して終了するものと考えればよい。実際的応用（＝ｐｒａｃｔｉｃａｌ  ａｐｐｌｉｃａｔｉｏｎ）は、到達性確認の結果を用いてどのように役立てるかという用途的な分類である。
これは以下の観点から分類される。
動作モデルの観点からは、ピア・トゥ・ピア・モデルとクライアント・サーバ・モデルに。
到達性を確認する主体であるところのＳは何かという観点からは、Ｓ−１（２０００）、Ｓ−２（５３００）およびＤ（１０００）に分類される。これを、Ｓの主体と表現する。
結果の表示をする相手先は何であるかという観点からは、Ｔ（４１００）、Ｓ−１（２０００）、Ｓ−２（５３００）およびＤ（１０００）に分類される。これを客体と表現する。（もちろん到達性確認の客体は常にＴ（４１００）である。ここで客体とは、結果表示を利用して利益を得る者は誰かを意味する）
何の役に立つかという観点からは、障害検知、表示、フィルタ、組Ａ：Ｂの写像の消込（第三のフィルタ例）に分類される。これを用途と表現する。
以上から代表的な例をまとめると、以下の表となる。
2004059925.tif 000006
Ｔ（４１００）の為にする障害検知と、
Ｓ−２（５３００）の為にする表示は、類似の概念である。
いずれも到達性確認をｐｉｎｇ代替として用いるものである。
Ｔ（４１００）の為にする障害検知が、より限定的な概念であって、既に実施例１に説明したように、Ｔ（４１００）の障害を検知して、Ｔ（４１００）に障害対応をうながすことである。この場合のＴ（４１００）は、通信ノードとしてのＴ（４１００）ではなく、Ｔの所有者亦はＴの管理者等のヒトである。
Ｓ−２（５３００）の為にする表示は、より単純で広範な場合であって、Ｔ（４１００）に対して正しく到達するか否かを、単に表示するものである。
フィルタとは、単に表示するだけでなく、到達性確認の結果を後続するアクションに生かそうとするものである。
障害検知とフィルタの場合は、後続するアクションが想定されているという点で、類似する。
障害検知では、後続するアクションは、ヒトによる復旧処理であった。それに対して、フィルタの場合は、後続するアクションはプログラムであって、一連の処理に組み込まれて実施されることを想定している。
ここで、Ｔ（４１００）への到達不能が検知されたときに、Ｔ（４１００）が障害であると考えるべきかどうかについて説明する。例えば、特許文献２では、ヘルスチェックによってＴ（４１００）相当が到達不能である場合には、異常として検知される。本発明でいう障害検知も同様の考え方である。しかし、それ以外の場合、例えばフィルタや表示の場合等は、断続的に接続と切断を繰返すＴ（４１００）にあっては、接続され正しい到達性を有している場合のみがＴ（４１００）として正常であるとのスタンスは取っておらず、到達不能な場合もまた正常である。要するに、Ｔ（４１００）の性質に応じる。Ｔ（４１００）が常に他ホストからの被アクセス可能性を維持しなければならない場合には、アクセスできない状態は障害である。網への接続と切断を繰返す為に、必ずしもアクセスできなくてもよいＴ（４１００）の場合には、アクセスできない状態であっても、別段障害ではない。
障害検知の場合
管理対象機器の所有者向けの通知として、メールやポケベル等が挙げられる。管理業者向けの通知として、ＳＹＳＬＯＧ、ＳＮＭＰｔｒａｐ等が挙げられる。これらはヒトを対象とする通知でありながら、実際には後続するプログラムへの代入であるので、後述するフィルタに含めて考えてもよい。実施例１に詳しく説明した。
表示の場合
いわゆるｐｉｎｇ代替として（つまり単にホストへの正しい到達性があるかないかを知る為に）用いる場合である。
公共の為にする表示とは、Ｔ（４１００）の到達性確認の結果が真であるとか偽であるとかを、Ｓ−２（５３００）に対して表示するというものである。Ｓ−１（２０００）でする場合をクライアントサーバ・モデルでの動作とする。一般利用者の使う端末であるところのＳ−２（５３００）でする場合がピア・トゥ・ピア・モデルである。
クライアント・サーバ・モデルの場合のＳ−２（５３００）は、不特定多数であってよい。この場合のＳ−２（５３００）は、網上の単なる通信ノードであって、Ｓの機能すなわち到達性を確認する機能を実装している必要がない。それゆえこの場合は、Ｓ−２（５３００）そのもののためではなく、公共の為にする表示である。
また、この場合の到達性を確認する主体Ｓ−１（２０００）は、Ｔ（４１００）の為に障害検知するものと同一である必要はない。例えば、主体がＳ−２（５３００）であっても、他のＳ−２（５３００）の為に到達性確認の結果を表示するものは、Ｓ−１（２０００）であると考えればよい。ただし、Ｓ−２（５３００）を主体とする場合には、単に自らの為に到達性確認する場合が一般的である。
Ｓ−２（５３００）について、まとめる。
Ｓ−２（５３００）は２通りある。
一般利用者であって、Ｓの機能を有するもの。
一般利用者であって、Ｓの機能を有しないもの。この場合は、クライアントサーバ型で動作し、Ｓ−１（２０００）とセットで用いる。
到達性確認の結果の利用方法として、表示の場合が最も従来のｐｉｎｇに近い。しかし、当然にｐｉｎｇの方がシンプルで応用がきく。ただしここでは、ｐｉｎｇでは到達性を知ることのできない動的な住所を割当てられたホストに対して、到達性確認では到達性を知ることができるという点で、優位性がある。
Ｓ−２（５３００）がＴ（４１００）の到達性を確認する手段として本発明を用いる場合のイメージを、図３９に示す。（ａ）がｐｉｎｇの場合、（ｂ）が到達性確認の場合である。
従来のｐｉｎｇの場合は、図３９（ａ）のように、Ｓ−２（５３００）は直接調べたい相手先のホスト名あるいはＩＰアドレスを指定する。
それに対して本発明では、Ｓ−２（５３００）の利用者がＴ（４１００）の到達性を調べたい時には、調べたいＴ（４１００）のホスト名を指定して、Ｓ−１（２０００）に到達性確認を依頼する。図３９（ｂ）の▲１▼
すると、Ｓ−１（２０００）がＳ−２（５３００）に替わって、Ｔ（４１００）の到達性を確認すなわち図３９（ｂ）の▲２▼＝サイン、同▲３▼＝答えるべき返事をやりとりし、
その結果をＳ−２（５３００）に通知する。図３９（ｂ）の▲４▼
これはコマンドでもよいが、Ｓ−２（５３００）の利用者が計算機や通信の知識がない場合にも簡易に利用することが出来るように、ウェブページを例として挙げてみる。
これはＣＧＩ等によって生成される、メッセージとボタンからなる画面をイメージされればよい。
第一は、図３９（ｂ）の▲１▼のフェーズに相当し、Ｓ−２（５３００）がウェブページに入力する、到達性確認したいＴ（４１００）を指定する画面例である。
「到達性を確認したいホストはなんですか？」亦は「到達性確認対象ホスト名を入力してください」等のメッセージが表示されており、その下に、ホスト名の入力欄がある。そして、「実行する」亦は「確認する」等のボタンを配したウェブページを生成すればよい。なお、特許文献２の場合のように、ＤＮＳを用いない場合には、これに先立って、あるいはこの画面のオプションとして、条件を入力させるようにすればよい。この条件とは、例えば特許文献２におけるＤ相当の所在情報等である。
第二は、結果としての図３９（ｂ）の▲４▼を表示している画面であり、Ｔ（４１００）が正しい到達性の場合である。メッセージ内容はインスタントメッセンジャ風に「オンライン」や「出席」としてもよいし、亦はｐｉｎｇ風に「到達可能」としてもよい。
第三は、結果としての図３９（ｂ）の▲４▼を表示している画面であり、Ｔ（４１００）が到達性を有しない場合である。第二の場合と同様に、「オフライン」や「欠席」亦は「到達不能」としてもよい。第二、第三の画面では、「戻る」ボタンを配した方が親切である。
なお、この場合は、Ｓ−１（２０００）がＴ（４１００）に対して到達性確認するタイミングは
Ｓ−１（２０００）の内部タイマに基づいても、
Ｓ−２（５３００）からの到達性確認要求を受けたことをトリガとして、
到達性確認してもよい。
ところで、クライアント・サーバ・モデルの場合であって、Ｓ−２（５３００）がＳの機能を有しない場合には、前記画面で到達可能とされても、たまたまＴ（４１００）の住所が変化した直後には、Ｔ（４１００）とＳ−２（５３００）間の通信において、キャッシュの影響を受けてＳ−２（５３００）からはＴ（４１００）に到達することができない場合がある。なぜならば、Ｓ−２（５３００）がＳの機能を有しない場合にはキャッシュは無効化されておらず、当然にキャッシュの影響を受けて誤認を生じさせるからである。このとき、Ｓ−１（２０００）では到達性確認をした時刻およびＴ（４１００）に対するＤ（１０００）のキャッシュの生存時間を知ることができる。履歴情報と比較することによって、Ｔ（４１００）の住所が変化したことも知ることができる。そのためＳ−１（２０００）では、到達性確認した時刻から導き出される、Ｓ−２（５３００）からの最遅アクセス可能時刻をあわせて表示するようにしてもよい。亦は、キャッシュの生存時間を示し、再度のアクセスをするよう表示してもよい。
フィルタの場合
Ｓ−１（２０００）でする場合であって、従来の管理に接続するための前置処理の場合である。到達性確認の結果を、従来の管理の入力として代入することによってなる。
例：Ｔ（４１００）のトラフィック計測への代入等。
方法：到達性確認済みのホストを代入させることによっての通常のＳＮＭＰ管理へ接続する。
いわゆる、フィルタとして動作させる場合である。フィルタの概念は先行するプログラムの出力を、後続するプログラムの入力とする考え方である。ＵＮＩＸでいうパイプの概念に相当する。例を挙げれば、ソートプログラム等がこれに類する。ソートプログラムは、何らかの出力結果を並べ直して、次の処理に接続する。
第一のフィルタ例として、本発明をセンサーとして用いる場合を挙げる。管理対象の変化を検知し、この結果を従来の管理に接続する。
後続するアクションは明らかにプログラムであって、例えばＭＲＴＧやＯｐｅｎＶｉｅｗ等による通常の管理である。その他、本番の通信に先立って通信相手の到達性が確認されている必要のある場合すべてにおいて、有効である。Ｓ−２（５３００）たる人間が直接Ｔ（４１００）にアクセスして、何らかの処理を行う場合でなく、機械によって自動化されている場合に有効である。
Ｔ（４１００）が正しい到達性を有するホストであることが確認された場合には、後続する処理に接続することができる。例えばＭＲＴＧやＯｐｅｎＶｉｅｗ等による従来（Ｔ（４１００）が固定ＩＰアドレスであり、到達性確認をあえて必要としない場合と同等）の監視処理をあげておく。従来の監視（＝後続する処理）の例として、ｕｃｄ−ｓｎｍｐ−４．２．１およびｍｒｔｇ−２．９．１７を用いてみた。ＭＲＴＧは、現在の網のトラフィックの状態および時間によって変化する情報（例えば、ＣＰＵ負荷率等）をグラフィカルに表示してくれるソフトウェアツールである。ＭＲＴＧはＳＮＭＰマネージャの機能を含んでいる（そのため、ここではＳＮＭＰマネージャとして扱った）が、トラフィック履歴ファイル生成用に特化している（つまりユーザーインターフェースを持たない）為に、通常は別途ＳＮＭＰマネージャと組合せて用いる。従来の管理方法については、本発明の対象外なので説明しないが、接続の際に問題があったので、その解決方法については以下に説明する。ここで試験の結果、少なくともＭＲＴＧではＩＰアドレスが変化するホストに対しては、Ｔ（４１００）をＦＱＤＮで指定しても（ＩＰアドレスの変化に追従できず）、通常の監視をおこなうことはできなかった。そのため、ＭＲＴＧで指定するＴ（４１００）名にその時点でのＴ（４１００）のＩＰアドレスを代入したＭＲＴＧの設定ファイルを生成しなおす処理を追加することによって、通常の監視処理に接続した。
例えば特許文献４は、変化する下位監視対象に追随するシステムの提案であるが、下位監視対象が変化したことを検知する方法については説明されていない。
そこで本発明を特許文献４に開示された発明の、更に前段の処理（フィルタ）として追加することによって、下位監現対象が変化したことを検知することができる。こうして検知された結果から下位監視対象のリストを作り直し、特許文献４の入力とする。この際、下位監視対象を示す静的な識別子を記述したリストから、個別に到達性確認し、正しい到達性を有するホストを対応付けたリストを作り直し、これを特許文献４の入力とするとよい。リストを作り直す処理は当然に、プログラムが行うものとする。
こうすることによって、手作業による入力なしで変動する下位監視対象に追従できるようになる。
このとき、ホスト名、現在のＩＰアドレスのみをプログラム間のパラメータとして受渡しするのではなく、従前のＩＰアドレスをも引渡すとよい。本発明の開示中、従前のＩＰアドレスを保存しておくことは開示していない。しかしこのような実装上の軽微な変更は本発明の本質になんら影響するものでなく、当然に本発明の開示から容易に想到されるものである。
もちろんＴ（４１００）のＩＰアドレスが変化した履歴情報を追跡の為に保持するような変更も、明示するまでもなく本発明の範疇に含まれる。
ところで、Ｓ−１（２０００）でするフィルタの場合、到達性確認の結果を処理として引継ぐ客体は、Ｓ−１（２０００）の場合とＴ（４１００）の所有者亦は管理者の場合とがある。ここでＴ（４１００）の所有者亦は管理者は、別途到達性のある管理用のシステムを運用しているものとする。Ｔ（４１００）の所有者亦は管理者を客体とする場合は、障害検知の場合を参照されたい。この際、静的な識別子と正しい到達性を有することを確認された動的なその時点での住所を、ＳＮＭＰＴＲＡＰ等に含めてＴ（４１００）の所有者亦は管理者あてに通知するようにするとよい。その後は、Ｓ−１（２０００）でする場合と同じである。
ところで、本発明をフィルタとして用いる場合には、後続する処理は従来の管理に限定されるものではない。この場合が第二のフィルタ例であって、第一の例よりも更に、フィルタ然とした用法である。利用者端末であるＳ−２（５３００）においてする場合を例示する。
例えば、「ＩＰ  Ｍｅｓｓｅｎｇｅｒ」というＰＣ上で動作するフリーウェアがある。これは、通信相手のＩＰアドレスを直接指定することによって実現した、サーバ不要の（つまりピア・トゥ・ピアの）リアルタイム・メッセージ送受信ソフトウェア（註：用途が同じであっても、サーバ不要なので「ＩＰ  Ｍｅｓｓｅｎｇｅｒ」はインスタント・メッセージング（ＲＦＣ２７７８、ＲＦＣ２７７９）の範疇に含まれない）である。
このようなプログラムに本発明を前置処理として実装することによって、例えば「ＩＰ  Ｍｅｓｓｅｎｇｅｒ」は、ＩＰアドレスといった動的な住所でなく、単にホスト名等の静的な識別子で通信相手を指定できるようになる。
更に、それだけに止まらない。
ちょうどリゾルバがありとあらゆる通信アプリケーションソフトの前置処理として動作するように、本発明もあらゆるプログラムの前置処理として動作させることができる。
なお、この場合の主体は、Ｓ−２（５３００）のみでなく、Ｓ−１（２０００）であってもよい。
（註：「ＩＰ  Ｍｅｓｓｅｎｇｅｒ」はあて先としてホスト名指定ができるようになりました。しかし、本発明で開示した問題点は解決されていないようです）
第三のフィルタの例を挙げる。
ＳとＤ（１０００）が一体となっている場合（図３８パターン２参照）、というよりはＤ（１０００）においてＳの機能を実施するときには、ある特殊なことが出来るようになる。
公示された組Ａ：Ｂの関連を公示しないようにする。
この方法は、マッピング公示システムＤ（１０００）において、Ｔ（４１００）に対する組Ａ：Ｂの写像を公示しなくする方法である。ＤＮＳサーバの場合には、Ｔ（４１００）に対するリソースレコードを消去する（以下、ＤＮＳにおけるリソースレコードの消込みは、更新の一形態として、更新に含むものとする）。Ｄ（１０００）においてＳの機能を実施した結果、Ｔ（４１００）に対して到達性が確認出来ない場合には、その他のホストからも同様にＴ（４１００）に到達することができないはずである。この際、誤認されたホストＴ’（４２００）に到達するおそれがあることは、既に説明した通りである。このとき、マッピング公示システムＤ（１０００）において、Ｔ（４１００）に対する組Ａ：Ｂの写像を公示しなくすることによって、誤認を生じなくさせることができる。
これは、本来的にはＴ（４１００）がするはずのオフライン処理を、Ｄ（１０００）が替わってすることである。このような提案は既にされており、特許文献１や特許文献２に開示されている。
特許文献１では、Ｔ（４１００）からＤ（１０００）へ、キープアライブ信号というものが送信され、Ｄ（１０００）ではこれが受信されなくなった場合に、Ｄ（１０００）で公示する組Ａ：Ｂを公示しないようにしている。この場合の考え方は、ビーコンやハートビートと同様に端末から信号を送信するという考え方である。同様の例に、特許文献５等がある。
特許文献２では、ＤＮＳを用いない独自システムではあるが、Ｄ（１０００）からＳへ、ヘルスチェックという処理を施している。ヘルスチェックの実体は、Ｔ（４１００）がＤ（１０００）に対して組Ａ：Ｂを設定する際に用いるパスワードを、盗聴対策の為にチャレンジ・レスポンス形式で暗号化している。方向としては、Ｄ（１０００）からＴ（４１００）へチャレンジを送信し、Ｔ（４１００）からＤ（１０００）へレスポンスを返すという流れである。これをある時間間隔の元に繰り返し、やはり途切れたことを以って、Ｔ（４１００）が網上に存在しなくなったことを検知している。
以上から、Ｔ（４１００）が網上に存在しなくなったことをいかにして検知するかが問われているわけだが、この方法に本発明を用いることを提案するものである。
この提案は、通信の方向としてＤ（１０００）からＴ（４１００）に対してアクションするという点で、特許文献２に類似する。そのため、特許文献２を引用して、進歩性が否定されるかもしれない。争点は、Ｂの代替物はパスワードと類似するかどうかである。
この点に関しては、基礎となる考え方が全く異なるということを考慮されたい。
第一に、パスワードを発想の基礎においていないこと。本発明によって実現される到達性確認は、そもそも網の特性によって、自動的に得られる値のみで足る。偽装を許容していることからも明らかなように、パスワードに代表される個体識別といった発想ではない。本発明でＢの代替物を許容している理由は答えるべき返事の類型に挙げた通りであって、基本思想に織込まれた、柔軟性を増すための工夫である。それゆえ、パスワードというＤ（１０００）とＳが一体となっていなければ知ることができないものを根拠にする特許文献２とは、自ずから異なる。
以下に、特許文献２との比較を表に示す。
2004059925.tif 000007
答えるべき返事がパスワードでないことは、答えるべき返事は漏洩しても良く、第三者に知られてもかまわないことを意味する。むしろ、アナウンスされた文字列で以って、到達性確認ができるということに特徴を有する。
そして、パスワードでないということは、Ｔ（４１００）において、なんらセキュリティ上の脅威にも結びつかない。到達性確認独立の効果でも触れたように、更新と到達性確認は、理論的にも機能的にも、完全に分離されているからである。
それ故、本発明でＢそのものがＢの代替物に置換あるいは変形された後であっても、特許文献２に比して進歩性を有するものである。
よって、パスワードをベースとして、パスワードの盗聴対策としてチャレンジ・レスポンスを用いた特許文献２とは異なり、網の特性に基づいてより高次の理論（＝到達性確認）によって単純化し、Ｔ（４１００）が網上に存在しなくなっていることを検知する為にはパスワードをも不要とした。
到達性確認独立の効果は、更にある。
特許文献１に示されたキープアライブを送出するＴ相当や、特許文献２に示されたヘルスチェックに応答するＴ相当は、一般的な動的更新端末ではなく、Ｄ相当に対する専用の端末にならざるをえないという問題があった。それに対して、本発明のＴ（４１００）は独立しているので、専用の端末である必要がない。
この考え方は、網の自律性にそった考え方であるので、Ｄ相当とＴ相当の固定的な関係に束縛される特許文献１や特許文献２と比較して優れている。
ところで、余談であるが、例えばＳ−１（２０００）やＳ−２（５３００）においても、リソースレコードを消込むことができる。Ｔ（４１００）への到達性が失われたことを、Ｓは検知することができるので、これをトリガとしてＤ（１０００）に対して（消込みの）更新をすればよい。しかし、この場合はＴ（４１００）が更新する際に用いるパスワードをＳ−１（２０００）やＳ−２（５３００）が知っている必要がある。パスワードを知っている人間は、少なければ少ないほど良いのは当然であるので、おススメしない。
なお、この場合の実装であるが、到達性確認の結果が偽であった場合に、図４０に開示したシェルスクリプトを実行する等のようにすればよい。図４０ではＢＩＮＤにおけるＴＳＩＧを用いた場合の例である。この際、Ｂそのもの（上記スクリプト例では＄ＴＡＲＧＥＴＨＯＳＴである。この場合はあて先としてのＢそのもの）を示すエントリを消す方法とＢに対する住所を０．０．０．０やプライベートアドレス等の到達性のない住所に変更する方法がある。上記では前者を採用した。
ＧＮＵＤＩＰ等のパッケージを用いる場合は、ＧＮＵＤＩＰが動作するホストで実施するべきである。この場合、Ｄ（１０００）とＧＮＵＤＩＰが異なるホストで動作していたとしても、一体となっているとみなすべきである。
更新方法については、更新を受付けるホスト上で動作するプログラムに応じて、個別実装されるがよい。更新過程は、図３７のａにいうところのダイヤルアップする機能と連携の取れる方法を用いるべきである。更新処理そのものは従来技術である。Ｄ（１０００）における消込みの更新のトリガとなる網上におけるＴ（４１００）の不存在の検知に到達性確認を用いることができる。
Ｄ（１０００）がＳの機能を実装してする到達性確認の場合には、外部的なホスト間通信としての（２）および（３）の過程は存在しない。しかし、これはＤ（１０００）が内部的に自分自身に対して、問合せればよいだけである。そのため、比較すべき組Ａ：Ｂの実像と写像が不十分ということはない。
ダイナミックＤＮＳ特有の問題点のまとめ１で、「Ｄ（１０００）は、Ｔ（４１００）が接続されなくなった後も、最終更新されたリソースレコードをアナウンスし続ける。Ｔ（４１００）からの明示のオフライン処理等がされれば、存在しないＴ（４１００）に関する情報をＤ（１０００）がアナウンスし続けることはない。しかし、Ｔ（４１００）の障害時や回線断の際には、オフライン処理をすることができない」と説明した。
ここから、解決すべき課題は、以下のことである。
以下の２つの条件が重なったとき、誤認されたホストＴ’（４２００）を発生させる。
Ｔ（４１００）が網上に存在しなくなる。
Ｄ（１０００）ではＴ（４１００）に関する静的な識別子と動的な住所の関連付けが公示されている。（より正確には前記２つの条件が重なったときに、さらに別のホストがダイヤルアップしてくると、それがＴ’（４２００）に化けるのだが、ここでは問わない）
この問題を解決するための方法として当初は、Ｔ（４１００）からＤ（１０００）に対してオフライン処理することによって、Ｄ（１０００）ではＴ（４１００）に関する静的な識別子と動的な住所の関連付けを公示しないようにしていた。
歴史的に、Ｔ（４１００）が回線断やＴ（４１００）そのものの障害等によってオフライン処理等をすることなく、網上に存在しなくなった場合には、効果がないことが判ってきた。
そこで、Ｄ（１０００）において、Ｔ（４１００）からのオフライン処理によらずに写像を公示しなくする方法が提案された。その方法における課題は、Ｔ（４１００）が網上に存在しなくなったことを如何にして検知するかであった。曰く、特許文献１では、端末側からＤＮＳへキープアライブ信号を送信することによって、生存していることを通知している。特許文献２は、ＤＮＳを用いないながらも、ＤＮＳ相当側からＴ相当側に向かってヘルスチェックを行い、Ｔ相当が接続されない状態になったことを検出している。
しかし、この方法でもまだ問題が残っている。それはＤ（１０００）は、Ｔ（４１００）がＤ（１０００）に対する専用の端末でなければ、Ｔ（４１００）が網上に存在しなくなったことを検知することができないことだった。Ｄ（１０００）はＴ（４１００）を、Ｄ（１０００）とＴ（４１００）との関係の上でのみ成立つ個体識別という考え方によって識別していたために、Ｔ（４１００）が専用の端末であることをＤ（１０００）は必須とした。
しかし、この問題も本発明によって解決された。すなわち、本発明によって、専用の端末である必要がなくなったのである。
ダイナミックＤＮＳ特有の問題点のまとめ１で指摘した問題点は、実は事象的な問題点であった。すなわち、目に見える問題点である。そしてこれを解決するためには、特許文献１や特許文献２等によるアプローチがあった。すなわち、Ｄ（１０００）の公示が正しくないがゆえに、Ｄ（１０００）の公示を是正しようとするものである。しかし、上記問題点は事象であって、原因は他にある。発明者の洞察に拠れば、その原因は実像と写像の不一致である。従来はＳの視点がなかったのだ。この視点によって、ＳがＴ（４１００）への到達性を確認することを実現した。この際Ｓは、ＴＤ間の直接的な関係に依存することなく、Ｔ（４１００）とＤ（１０００）からそれぞれ別個に網の構成要件としての４つの要素を得て、その対応の正しさすなわち実像と写像の一致によって、到達性の正しさを確認する。
この考え方に至った時点で、特許文献１や特許文献２のようなＤ（１０００）がＴ（４１００）を個体識別するという考え方ではなくなっている。そしてこの時点で、到達性確認することのできる通信ノードは、Ｓである以上あらゆる通信ノードである。それゆえ、本発明によって、専用の端末である必要がなくなったのである。
そしてもちろん、到達性確認は、特許文献１や特許文献２が検知することを目指したＴ（４１００）が網上から存在しなくなっている場合をも、検知できるものである。それゆえ当然に、Ｄ（１０００）においても到達性確認をすることはできる。そして、既に挙げたような優位性を有する以上、到達性確認は特許文献１や特許文献２に比して、進歩性を否定されるものではない。本発明は、通信における発信元とあて先がエンド・エンドで到達性確認できるようにしたことに特徴を有する。すなわち、本発明の根幹は到達性確認を実現する理論と実装である。ここでは静的な識別子と動的な住所が関連付けられることによってホスト到達性が得られる網にあっては、実像と写像を比較することによって、そのホスト到達性を確認することができるとの、新たな理論を提示した。
この際、カウンターサインという新規のキャリア信号を提案することによって、前記４つの要素のうち、従来では入手することのできなかった要素（すなわち実像におけるＢ）を入手することを可能にした。
更なる応用
Ｔ（４１００）を発信元として、Ｗｅｂサーバ等に接続する際に、Ｗｅｂサーバ側で到達性確認を行うことによって、閉域接続が可能になる。これは情報は公開したいが、誰もが参照できるようにはしたくない等の場合に有効である。例えば、有料課金等の際に、特定のグループを対象にして公開したい場合等である。
手順の１例を以下に挙げる。
手順１。Ｗｅｂサーバ側では、まず特定のグループのメンバとしてＴ（４１００）を登録しておく。このようにして登録されたＴ（４１００）の集合を、データベースと呼ぶ。
手順２。Ｔ（４１００）からアクセスを受けた際に、到達性確認を行う。ここでは仮にＴ（４１００）は答えるべき返事として、ホスト名（つまりＢそのもの）を返すこととする。
手順３。Ｗｅｂサーバ側では、データベース内から前記得られたホスト名が、合致しているグループを検索する。
手順４。合致したグループに応じたアクセス許可を、発信元であるＴ（４１００）に対して許可する。
手順５。いずれのグループにも合致しなかったＴ（４１００）、到達性確認で偽とされたＴ（４１００）、あるいはＴ（４１００）の機能を実装しない端末からのアクセスの場合には、接続を拒否する。
こうすることによって、閉域接続が可能となる。
この例は、通常あて先として論じられてきたＴ（４１００）を、立場を逆転させてみた。すなわち、答えるべき返事を発信者番号通知として、利用する場合である。
この際、回線交換とは異なり、着信側が自動的に発信者番号を受け取ることができないので、到達性確認によって発信者番号の受け取りに替えるものである。カウンターサインが発信者番号すなわち答えるべき返事を運搬するキャリア信号となる。ここで、例えばＩＰヘッダにおける発信元住所とは異なる概念であることを示しておく。前記ＩＰヘッダにおける発信元住所は、動的な住所であるところのＡであって、静的な識別子であるところのＢではない。よって、回線交換でいうところの発信者番号通知に替える機能を持たせる為には、到達性確認が必要なのである。
念の為に記載するが、上記ではＷｅｂサーバとしたが、到達性確認に後続する閉域接続することができる処理は、Ｗｅｂサーバのみに制限されるものではない。また、前記手順の２でホスト名としたが、当然にＢの代替物であってよい。
なお、ＴＳ間において、相互にＴの機能とＳの機能を実施することもできる。実施例１０を参照されたい。こうすることによって、前記した閉域接続の場合よりもさらに閉じた回路をつくることができる。
ところで回線交換の場合は、着信側は発信者番号通知に応じて、選択的に発信元に対して着信を許可したり拒否したりできる。同様に本発明を応用することによって、Ｔ（４１００）がした答えるべき返事により、ＳではＴ（４１００）からの着信を許可したり拒否したりすることもできる。前記したようにＴ（４１００）とＳとの立場が逆転していることに注意されたい。このような応用によって、アクセス制御に替えることも可能になる。この方法については、単に閉域接続の逆パターンで足るので、ここまでの説明で容易に想到されるものと考える。
（考察）
キャッシュとトラフィックに関する考察
この項は、マッピング公示システムとしてＤＮＳのみがあてはまる。
キャッシュの影響によって発生する誤認を回避する為には、キャッシュを無効化するしかなかった。
キャッシュの機構は、ＤＮＳに織り込まれたトラフィックを減ずるための工夫である。したがって、単にキャッシュを無効化すると、トラフィックが増大するおそれがある。
この二律背反を整合する方法を、既に説明してきたものの中から再度２つ挙げて説明する。なお、ここでいうトラフィックはＤＮＳトラフィックのみを指す。したがって、ＤＮＳトラフィックのみを減ずることを目的とする。公衆の役務であるＤＮＳについて必要以上に負荷を増大させないことは社会の要請であり、これに応えるものである。ＴＳ間のトラフィックは、ＴＳ間の通信の頻度に応ずる。
アプリケーション的な解決
通信モデルのシーケンスの最後で、以下のように説明した。
「例えば、いったん到達性が確認された後の（２回目以降の）到達性確認においては、（４）でするサインのあて先であるところのＴ（４１００）の住所を記憶しておき、通常は（２）および（３）の過程を省略し、ＳからＴ（４１００）に到達しなくなった時点、すなわち到達性の正しさが確認されなくなった後に、再度（２）および（３）の過程を実行しても良い。」
この件について、更に説明する。
Ｓでは到達性が確認された後の、あて先であるＴ（４１００）に対する動的な住所を記憶しておき、名前解決や実施例１に示したアドレス確認をするのではなく、このローカルに記憶されたＴ（４１００）を示す住所あてに、以後サインを送るようにする。このローカルに記憶をする領域は、Ｓにおけるアドレス確認の過程で、新たに専用の記憶域を確保するやり方でもよいし、キャッシュをＳ上に展開してもよい。
前者の新たに専用の記憶域を確保するやり方は、アプリケーションプログラム的な解決方法である。この場合は、Ｔ（４１００）が答えるべき返事として不明な応答を返した時点で、再度実施例１に示すアドレス確認をすればよい。実施例１に示した２回目のＳ２１６のときに、一定時間待つのではなく、すぐにアドレス確認の過程に戻るようにする。この際、切分の実装にはフラグ等を用いればよい。
これを実装的に説明すると、図示しないが図２３で説明すると以下のようになる。
最初に到達性確認に成功した場合をから説明する。
Ｓ２１４の後で、フラグを立てる。既に立っている場合はそのまま。そして、Ｔ（４１００）の住所を記憶して終了する。
次回到達性確認したときは、Ｓ２０２の前で、フラグが立っているかどうかを判断して分岐する。フラグが立っていれば、前記記憶された住所を、Ｓ２０４におけるＴ（４１００）を示す住所に代入する。そして、Ｓ２０６から始める。フラグが立っていなければ、通常どおりＳ２０２から始める。
次に到達性確認に失敗した場合である。Ｓ２１６の後で、フラグが立っていればフラグを消す。フラグが元から立っていないない場合はそのまま。Ｔの住所が記憶されていれば、これも消す。そして、次回到達性確認のタイミングが回ってくるまで待つのではなく、すぐにＳ２０２に戻り、やり直す。ただし、この際２回目以降のＳ２１６に該当する場合があるので、一時フラグ等を用いて永久ループを回避するとよい。
フラグの立て方は、ここでは到達性あり（Ｓ２１４）の場合に立てたが、逆（Ｓ２１６）にしてもよい。この際、当然にＳ２０２以前の分岐も逆にする。
後者のキャッシュをＳ上に展開する方法では、キャッシュの生存時間経過後、再度名前問合せをすることになる。もちろん、この場合であっても、Ｔ（４１００）が答えるべき返事として不明な応答を返した場合には、アドレス確認を省略している訳だからすぐさまＴ（４１００）は到達しないと判断するべきでなく、アドレス確認からやり直すべきである。
どちらも、名前解決に関するホスト間通信の頻度を減らすことができ、かつキャッシュによる誤認を発生させないようにする効果がある。どちらかというと、前者の方がお勧めである。この理由は、Ｔ（４１００）に到達しなくなるまでの間、名前問合せしないのであるから、結果として名前問合せする頻度が前者の方が少ないことによる。また、Ｓが網接続機器等の比較的資源に余裕がない装置である場合には、キャッシュを展開させるような変更が負担である場合等があり、その際にもアプリケーション的解決の方が有利である。
アプリケーション的解決は、Ｓとして、Ｓ−１（２０００）、Ｓ−２（５３００）を許容する。実際的応用に示した第三のフィルタ例Ｄ（１０００）をＳとする場合と似る。Ｄ（１０００）をＳとする場合には、名前問合せを省略したのではなく、名前問合せが内部的に完結するので、実質的にホスト間の通信を省略したのと同じことになる。Ｄ（１０００）とは異なり、内部的な名前解決をすることができないＳ−１（２０００）やＳ−２（５３００）において、正しく到達したＴ（４１００）の住所を記憶することによって、内部的な名前解決をさせるようにした。
このようにして、アドレス確認しつつ、ＤＮＳ参照回数を減らし、トラフィックを減ずることができる。
クライアント・サーバ・モデル
クライアント・サーバ・モデルの場合のＳ−２（５３００）は、不特定多数であってよく、かつＳの機能を実装している必要がない。つまりクライアント・サーバ・モデルを採用する理由は、Ｓの機能を実装しない既存の通信ノードに対して、到達性確認というサービスを提供できるようにするものである。しかし、クライアントサーバ・モデルを採用するもうひとつの理由がある。
集約効果である。
これは図で説明すると判り易い。
図４１（ａ）にピア・トゥ・ピア・モデルを採用した場合を示す。ピア・トゥ・ピアの場合は、Ｓ−１（２０００）とＳ−２（５３００）はいずれであってもよい。そのため図中のＳ−２（５３００）はＳ−１（２０００）と読替えてもよい。
図４１（ｂ）にクライアント・サーバ・モデルを採用した場合を示す。
図４１（ａ）の場合であって、仮にあらゆる端末がＳ−２（５３００）になる場合を考えると、クライアント・サーバ・モデルの必要性は明らかである。これがエンド・エンドで到達性確認できるにもかかわらず、クライアント・サーバ・モデルを提案した理由である。
従来からいわれているように、ピア・トゥ・ピア・モデルが小規模通信向け、クライアント・サーバ・モデルが大規模通信向けと考えればよい。
クライアント・サーバ・モデルは名前問合せに係るトラフィックを減ずるだけのための工夫ではないが、キャッシュの無効化とトラフィックの増大の関係を整合することに貢献する。
哲学的な考察
発明の過程において発明者は、認証とは、網上におけるホストとヒトの違いは何かと、考えていた。
ヒトは網上では、ホストの向こう側にいる存在であった。すなわち、レイヤが違う。そんなことは、わかっているのだ。しかし、どうも明確にヒトとホストを分かつ境界が見えないのであった。
そこで、以下のように考えることにした。
人間の認証がパスワードである。ホストは、Ｘ５０９証明書や、ＩＰＳｅｃ認証ヘッダ等によって、認証することができる。そして、機械（通信ノード）の網上での到達性確認がサイン・アンド・カウンターサインである。その意味で、人間の認証、ホストの認証と、ホストの到達性確認は並立する概念である。ここで、機械（通信ノード）の到達性確認とは、特別の許可ではないという点で認証より緩やかな概念（例：アクセス権の許可ではない）であって、通信の相手方として、正しい相手方であることを確認する過程である。
以上によって、従来の端末認証等の個体識別という概念によらず、網の特性によって網上の通信相手を確認する方法を提案した。
（今後の課題）
課題１
Ｓ−１（２０００）やＳ−２（５３００）において、以下の条件が重なった時に、本発明は効果がない。
条件１  Ｔ（４１００）が網上に存在しない。
条件２  Ｄ（１０００）において、Ｔ（４１００）に対する組Ａ：Ｂの写像を公示。（この場合、Ｔ（４１００）が存在しない以上、Ａに誤りがある。そして、Ｄ（１０００）においてＳの機能を実施し、Ｔ（４１００）を示す写像の消込みもされていない。）
条件３  Ｔ’（４２００）が網上に存在しない。（つまり、誤認発生していない）
以上の条件が重なった時には、ＳからＴ（４１００）への通常の通信と同様、到達性確認もまた、単にタイムアウトするまで待つという点で、到達性をあえて確認する利益がない。
課題２
処理を含む各過程に対して、インターフェースの標準化をした方がよい。
本明細書による開示では、各構成要素（特にＳ）における後続する処理については、個別実装とした。後続する処理は従来技術である。本明細書の開示のみでは本発明と従来技術の接続点に関して、個別に作り込まなければならない。
そこで、各処理におけるやり取りを規定することによって、到達性確認をモジュール化することができる。
プログラム間インターフェースを標準化するという提案である。
インターフェースが標準化されれば、例えばＳで動作するプログラムをマネージャ、Ｔ（４１００）で動作するプログラムをエージェントとする等によって、更に理論化できる。
インターフェースを標準化することによって、個別の作り込みをするのでなく、
「ちょうどリゾルバがありとあらゆる通信アプリケーションソフトの前置処理として動作するように、本発明もあらゆるプログラムの前置処理として動作させることができる」ようになる。
課題３
カウンターサインの用いる通信ポートに関しても、標準化をした方がよい。
（用語の説明）
以下に、本文中で説明できなかった重要な用語について説明する。
・暗号化とは：
あるルールに従ってオリジナルの文字列を変形したものであって、復号化が必要なもの。ここでは目的は問わない。すなわち必ずしも秘密の漏洩を防ぐことを目的としない場合がある。例えば、通信路そのものやディスクそのものが暗号化されている場合には、暗号化された情報のうちには、秘密にする必要のあったものは本のわずかであって、その大半は秘密にする必要がなかったものかもしれない。あるいは秘密にする必要のないものしか含まれていないこともあり得る。この際、秘密にする必要のなかった情報が暗号化された目的は、秘密の漏洩を防ぐことではない。秘密にする必要があるかないかは、情報の質の問題である。本発明において、Ｔが答えるべき返事が、仮にＢの変形である場合であっても、そもそもＢそのものが秘密にする必要のない情報であるので、秘密の漏洩を防ぐことを目的とするとはいえない。本文中で触れたように、基本思想に織込まれた、柔軟性を増すための工夫である。
・認証とは：
認証とは、正規利用者本人だと確認する過程。例えば、システムにログインする権利の確認あるいはファイルシステムへのアクセス権を獲得する過程。
・パスワードとは：
暗号化とは異なる慨念であって、何らルールに基づかず、また復号を必要としない、単に秘密の文字列であって、認証の為に用いるもの。
これは、暗号化パスワードと平文パスワードが区別されることからも明らかである。パスワードは、知識による認証とよばれるものに属し、ユーザＩＤに対応するパスワードを知っているという事実を以って、そのユーザが正規の利用者であるという判断をするものである。すなわち、本人を正しく特定できることを目的としている。パスワードは、通常個体識別名とともに、個体識別に用いる。すなわち、認証とパスワードはともに、個体識別をベースとして発想されたものである。
ところで、チャレンジ・レスポンス形式によって暗号化されたパスワードやＳ／ＫＥＹ等のワンタイムパスワードも、ここではパスワードに含めて考える。
また、ＤＮＳの場合であって、更新に用いるパスワードには、便宜上ＴＳＩＧ（ＲＦＣ２８４５）を含めて考えている。これは、Ｔ（４１００）とＤ（１０００）において秘密鍵を共有することから、知識による認証に準ずるものと考えて差し支えないからである。
・ホストとは：
端末、ルータ等を含む、住所を割当てられた通信ノードすべて。よって、本発明では、ホストという用語には、計算機のみでなくゲートウェイをも含むものとする。
・ゲートウェイとは：
アプリケーションゲートウェイのみをゲートウェイとする説があるが、本明細書ではルータ、アプリケーションゲートウェイ、プロトコル変換装置等のＩＰ的網境界を構成するものを総称する。
・カスタマとは：
Ｔ（４１００）の所有者のこと。カスタマ網とは、Ｔ（４１００）の所有者が管理する網であって、公共の網でないもの。
・リゾルバとは：
ＤＮＳに対して名前問合せをする機能のことＤＮＳから見れば名前問合せをしてくるものである。
本発明で多用される技術以外の重要な概念について定義する。
・代替とは：
他のもので代えること※
・集合とは：
一定の範囲にあるものを一つの全体として考えたもの※
本発明では、この一定の範囲とは、特定の機能を代替し得るものと考える。さらに独立した機能が集合することによって、上位の機能を形成する場合もこれに含む。
・代表とは：
団体の中から選ばれ、その団体の意見や意志を反映する者として他との交渉に当たる・こと※
その一つを取り出しただけで全体の特徴が概観できる・こと（もの）※
・典型とは：
特定の集合の中で最も特徴的であるか、目立つものをいう。
したがって、集合の持つ性質を、正確に反映している訳ではない。
・一体となった場合とは：
一の具体的な装置において、複数の機能が複合した場合をいう。
・関連付けとは：
マッピング公示システムによって対応付けられる、静的な識別子と動的な住所は、本来的には１対１に対応付けられるべきものである。しかし、１対１でない場合があることや、中間識別子である場合等を考慮して、静的な識別子と動的な住所は関連付けられるものとした。
なお、※印あるものについては、新明解国語辞典を引用した。
その他の用語については一般的な、もしくは当業者の技術常識にしたがって解釈されたい。
【図面の簡単な説明】図０１  Ｔもしくはカスタマ網において、ダイヤルアップを示す図である。
図０２  Ｔもしくはカスタマ網において、アドレス割当てを示す図である。
図０３  Ｔもしくはカスタマ網において、ＤＮＳ更新を示す図である。
図０４  Ｔもしくはカスタマ網において、正常状態を示す図である。
図０５  Ｔもしくはカスタマ網において、回線断発生を示す図である。
図０６  Ｔもしくはカスタマ網において、再接続を示す図である。
図０７  Ｔもしくはカスタマ網において、アドレス割当て（再）を示す図である。
図０８  Ｔもしくはカスタマ網において、ＤＮＳ更新（再）を示す図である。
図０９  Ｔもしくはカスタマ網において、ホストがすり替わっているように見える状態を示す図である。
図１０  各網において、参照されるＤＮＳを示す図である。
図１１  Ｔもしくはカスタマ網において、誤認を示す図である。
図１２  Ｔもしくはカスタマ網において、正常状態（収束）を示す図である。
図１３  Ｔもしくはカスタマ網において、回線断のまま（図０６以降の別パターン）を示す図である。
図１４  Ｔもしくはカスタマ網において、回線断のままの場合の誤認、亦は第二の保守経路による保守を示す図である。
図１５  ＴとＤの対応状況を示す図である。
図１６  Ｔを正引き名前問合せする場合において、キャッシュが有効な時のＤＮＳの探索順を示す図である。
図１７  Ｔを正引き名前問合せする場合において、キャッシュが有効でない時のＤＮＳの探索順を示す図である。
図１８  キャッシュの生存時間を示す図である。
図１９  キャッシュの生存時間の収束１（計測プログラム）を示す図である。
図２０  キャッシュの生存時間の収束２（計測結果１）を示す図である。
図２１  キャッシュの生存時間の収束４（計測結果２の続き）を示す図である。
図２２  通信モデルを示す図である。
図２３  課題を解決するための手段を示すフローチャートである。
図２４  課題を解決するための手段２（Ｓ２０４のオプション処理）を示すフローチャートである。
図２５  ＤＩＧコマンド正常出力例を示す図である。
図２６  ＤＩＧコマンドエラー出力例（ＤＮＳサーバが存在しない場合）を示す図である。
図２７  ＤＩＧコマンドエラー出力例（Ｔが存在しない場合）を示す図である。
図２８  ＳＮＭＰ正常出力例（Ｔが正しい到達性の場合）を示す図である。
図２９  ＳＮＭＰエラー出力例（ホストが間違いの場合）を示す図である。
図３０  ＳＮＭＰエラー出力例（コミュニティ名が間違いの場合）を示す図である。
図３１  ＳＮＭＰエラー出力例（オブジェクトＩＤの指定間違いの場合）を示す図である。
図３２  ＢＩＮＤにおけるバージョン情報の設定の為にする設定ファイルの変更箇所を示す図である。
図３３  ＤＩＧコマンド正常出力例を示す図である。
図３４  ＤＩＧコマンドエラー出力例（Ｔが存在しなかった場合）を示す図である。
図３５  ＤＩＧコマンドエラー出力例（別のネームサーバを参照してしまった場合）を示す図である。なお、バージョン情報が設定されていない場合の標準的な出力例（正常）でもある。
図３６  ＳＭＴＰサーバ（ＳＥＮＤＭＡＩＬ）に接続した際の最初のメッセージ例を示す図である。
図３７  Ｔのカスタマ網における接続形態を示す図である。
図３８  各ホストと網の位置関係を示す図である。
図３９  本発明をいわゆるｐｉｎｇ代替として用いる場合の動作の違いを示す図である。
図４０  ＤＮＳ更新スクリプト・サンプルを示す図である。
図４１  クライアント・サーバ・モデルにおける集約効果を示す図である。
【符号の説明】
記号  名称
１０００  Ｄ。マッピング公示システムである。ＤＮＳが代表例であるが、ＤＮＳのみを指す訳ではなく、特許文献２の場合等も含む。ＤＮＳと表記された場合には、ＤＮＳのみを指す場合と、ＤＮＳでないが組Ａ：Ｂの写像を公示するものである場合がある。
２０００  Ｓ−１。発信元管理サーバである。Ｓ−２（５３００）とあわせて、発信元であるＳという概念に抽象化される。この際、発信元とは、Ｔへの到達性の正しさを確認しようとするものである。
４０００  Ｐ。管理対象機器の接続先たるプロバイダである。あるいはカスタマ網から見て上流の網（ＤＮＳサーバ等がある側）を構成し、これに接続される網境界ノードに住所を動的に割当てる機能を有する網を指す。ＤＨＣＰサーバ、そしてＤＨＣＰサーバと管理対象機器を含む網を許容する。
４１００  Ｔ。網に対して、断続的に接続および切断（移動亦は携帯を含む）を繰返すダイヤルアップのホストであって、あて先たる管理対象機器である。
４２００  Ｔ’。プロバイダＰの別のユーザ。プロバイダＰから住所の割当てを受けるユーザ（亦はホスト）であって、管理対象機器でないユーザである。管理対象機器がかつて割当を受けていた住所を割当てられる可能性があるという点で、管理対象機器と誤認されるおそれのあるホストのこと。
４５００  Ｐ−Ｄ。プロバイダＰのＤＮＳサーバ。
５０００  Ｐ−２。プロバイダＰでないプロバイダである。管理対象機器の接続先以外のプロバイダ。すなわちインターネットの一般利用者（５３００）の接続先たるプロバイダである。この概念はプロバイダＰがインターネットに接続しているかもしくはプロバイダＰがその他の網と相互接続されている場合にのみ有効な考え方である。
５３００  Ｓ−２（５３００）。一般利用者たる発信元である。インターネットの一般利用者（５３００）。管理サーバやＤＮＳの管理者および管理対象機器の運用者、管理対象機器の直接利用者（閲覧者を除く）から見た、第三者のことである（管理対象機器に対する閲覧者は、一般利用者に当たる）。管理対象機器（あるいはカスタマ網とプロバイダＰの網境界）に住所を動的に割当てるプロバイダＰがインターネットに接続しておりかつプロバイダＰ−２がインターネットに接続しているか、もしくはプロバイダＰとプロバイダＰ−２が相互接続されている場合にのみ一般利用者（５３００）の概念は（管理対象機器から見て）プロバイダＰ−２の上で成立する。すなわち、プロバイダＰ−２は（プロバイダＰから見て）ルーティングによって到達する別の網でありさえすればよい。管理対象機器に対して通信を始めようとするノードである。
５５００  Ｐ−２−Ｄ。プロバイダＰ−２のＤＮＳサーバ
【図１】
2004059925.tif 000008
【図２】
2004059925.tif 000009
【図３】
2004059925.tif 000010
【図４】
2004059925.tif 000011
【図５】
2004059925.tif 000012
【図６】
2004059925.tif 000013
【図７】
2004059925.tif 000014
【図８】
2004059925.tif 000015
【図９】
2004059925.tif 000016
【図１０】
2004059925.tif 000017
【図１１】
2004059925.tif 000018
【図１２】
2004059925.tif 000019
【図１３】
2004059925.tif 000020
【図１４】
2004059925.tif 000021
【図１５】
2004059925.tif 000022
【図１６】
2004059925.tif 000023
【図１７】
2004059925.tif 000024
【図１８】
2004059925.tif 000025
【図１９】
2004059925.tif 000026
【図２０】
2004059925.tif 000027
【図２１】
2004059925.tif 000028
【図２２】
2004059925.tif 000029
【図２３】
2004059925.tif 000030
【図２４】
2004059925.tif 000031
【図２５】
2004059925.tif 000032
【図２６】
2004059925.tif 000033
【図２７】
2004059925.tif 000034
【図２８】
2004059925.tif 000035
【図２９】
2004059925.tif 000036
【図３０】
2004059925.tif 000037
【図３１】
2004059925.tif 000038
【図３２】
2004059925.tif 000039
【図３３】
2004059925.tif 000040
【図３４】
2004059925.tif 000041
【図３５】
2004059925.tif 000042
【図３６】
2004059925.tif 000043
【図３７】
2004059925.tif 000044
【図３８】
2004059925.tif 000045
【図３９】
2004059925.tif 000046
【図４０】
2004059925.tif 000047
【図４１】
2004059925.tif 000048
【国際調査報告】
2004059925.tif 000049
2004059925.tif 000050
2004059925.tif 000051
2004059925.tif 000052