(57)【特許請求の範囲】
【請求項１】
通信ノードに割り当てられる識別子及び住所であって取得済みの識別子及び住所を保持する保持手段と、
識別子と住所とが一対で記憶されている記憶媒体に対して第一の識別子を送信することによって対応する第一の住所を取得する取得手段と、
前記保持手段によって保持されている識別子又は住所と前記取得手段によって取得された前記第一の識別子又は第一の住所とが一致しているか否か判定する判定手段とを備える通信ノード。
【請求項２】
前記保持手段によって保持されている識別子は、前記取得手段によって取得された第一の住所が割り当てられている通信ノードからネットワークを介して取得された識別子である、請求項１記載の通信ノード。
【請求項３】
前記第一の識別子は、前記保持手段によって保持されている識別子である、請求項１記載の通信ノード。
【請求項４】
前記保持手段によって保持されている識別子及び住所は、自通信ノードに割り当てられている識別子及び住所である、請求項１記載の通信ノード。
【請求項５】
前記第一の住所が割り当てられている通信ノードに対してサイン信号を送信し、
前記サイン信号に応答して返信されるカウンターサイン信号を受信し、
前記サイン信号の受信元から送信される任意の情報を受信する請求項１記載の通信ノード。
【請求項６】
前記第一の住所が割り当てられている通信ノードに対してサイン信号を送信し、
前記サイン信号に応答して返信される任意の情報が附加されているカウンターサイン信号を受信し、
前記カウンターサイン信号から任意の情報を抽出する請求項１記載の通信ノード。
【請求項７】
前記任意の情報は、前記第一の住所が割り当てられている通信ノード内の変数亦は前記第一の住所が割り当てられている通信ノードの利用者が設定したメッセージ、或いは、これらに基づく情報である請求項６記載の通信ノード。
【請求項８】
前記任意の情報は、附加情報設定ポインタによって、任意のプログラムが呼び出された結果出力される情報である請求項６記載の通信ノード。
【請求項９】
前記任意の情報は、前記第一の住所が割り当てられている通信ノードが前記第一の住所が割り当てられている通信ノードの外のデバイスと通信して得た応答である請求項6記載の通信ノード。
【請求項１０】
前記任意の情報は、通信相手の状態情報である請求項6記載の通信ノード。
【請求項１１】
前記第一の住所が割り当てられている通信ノードに対してサイン信号を送信し、
前記サイン信号に応答して返信される任意の情報が附加されているカウンターサイン信号を受信し、
前記カウンターサイン信号から任意の情報を抽出し、
任意の情報を表示亦は後続する処理に接続する請求項１記載の通信ノード。
【請求項１２】
前記第一の住所が割り当てられている通信ノードに対してサイン信号を送信し、
前記サイン信号に応答して返信される任意の情報が附加されているカウンターサイン信号を受信し、
前記カウンターサイン信号から任意の情報を抽出し、
前記任意の情報の形式を自通信ノードの利用者が識別可能な形式に変換して結果表示する請求項１記載の通信ノード。
【請求項１３】
前記第一の住所が割り当てられている通信ノードに係るプレゼンスを検知する請求項１記載の通信ノード。
【請求項１４】
サイン信号の送信先の住所が記憶されるメモリと、
前記第一の住所が割り当てられている通信ノードに対してサイン信号を送信する手段と、
前記サイン信号に応答して他のサイン信号を受信する手段と、
前記他のサイン信号に基づいてカウンターサイン信号の送信の可否を制御する手段と、
前記他のサイン信号の送信元の住所と前記記憶している住所との一致の有無を判定する手段と、
前記住所が相互に一致している場合にはカウンターサイン信号を送信する手段と、
前記住所が相互に一致しなかった場合にはサイン信号を送信する手段とを備える請求項１記載の通信ノード。
【請求項１５】
通信ノードに割り当てられている住所が記憶されるメモリに対して、サイン信号を受信したとき当該サイン信号に含まれている住所を登録する手段を有する請求項１記載の通信ノード。
【請求項１６】
請求項１記載の通信ノードからの要求に応じて、ネットワークを介して識別子を送信する通信ノード。
【請求項１７】
自ノードに対してアクセスしてくる予定の通信ノードに割り当てられている識別子を登録しておき、
前記他の通信ノードに割り当てられている識別子と前記登録された識別子とが一致したか否かに基づいて前記要求に応じた識別子の送信の可否を制御する請求項16記載の通信ノード。
【請求項１８】
自通信ノードに割り当てられている識別子を含むサイン信号を請求項１記載の通信ノードへ送信する通信ノード。
【請求項１９】
前記第一の識別子は、サイン信号に含まれて送信される、請求項１記載の通信ノード。
【請求項２０】
識別子と住所とが一対で記憶されている記憶媒体に対して自通信ノードに割り当てられる識別子を送信し、
前記記憶媒体から返信される前記識別子に対応する住所と自通信ノードに実際に割り当てられている住所との一致の有無を判定する通信ノードのループバック試験方法。
【請求項２１】
請求項１記載の通信ノードを用いた通信システム。
【請求項２２】
前記通信ノードと他の通信ノードとが共有するサインリストを有する請求項21記載の通信システム。
【請求項２３】
請求項21記載の通信システムを利用した地図情報システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は蓄積交換網において、動的な住所を割当てられてなる通信ノードに対する宛先発見過程と、本番の通信に先立ってする予備的な通信に関する。
【背景技術】
【０００２】
インターネット商用化後の一般利用者の用いる端末は、変動する住所を有し、通信相手として特定する識別子を有しない端末であった。このような端末とも通信したいという要望があった。最初に試みられたのは、通信相手を一意に特定する識別子を設定し、これに変動する住所を追随させるシステムに、通信相手を特定することを委ねることであった。このようなシステムには、例えばｗｅｂｈｏｐ 、ＩＭＰＰ（RFC2778, RFC2779）、動的ＤＮＳ（RFC2136, RFC3007）、ＳＩＰ（RFC3261-3265, RFC3856）、ＥＮＵＭ（RFC2916, RFC3401-3406, RFC3761）等がある。（前期の中からＩＭＰＰを除いたものを「マッピング公示システム」と以下表記する）
このとき、通信相手がオンラインでなければ通信を開始することが出来なかったことから、本番の通信を始める前に通信相手の到達性を知ることが重要だった。これがプレゼンスが必要とされた背景である。
「プレゼンスとは、本番の通信を始める前に相手の状態を確認すること」である。通信相手が、現在網上に存在しているか？ どのような状態であるか？ を知ることによって、適切な通信を開始するものとされている。
プレゼンスの例は、「オンライン／オフライン」や「在席／離席」等である。
【０００３】
しかし、「通信相手が現在網上に存在しているか？」と、「どのような状態であるか？」とは、次元の異なる課題ではなかったか？
発明者には、体にセンサーをつけて生活している叔父がいる。彼は病気なのだが、入院はしていない。こういうヒトであるならば、ヒトの状態情報も判るだろう。しかしこういうヒトは滅多にいない。
そもそも利用者の状態なんてものは、厳密には知ることのできない種類の情報ではないのか？  本来これは通信ノードの情報ではないのか？
「在席・離席」は通信相手がオンラインの場合であって、その上でヒトがどのような状態かを表す情報である。よって、オンラインかオフラインかは、状態を知る以前の課題である。すなわち、「オンライン／オフライン」と「在席／離席」とは該情報を検知し得る段階（＝レイヤ）がそもそも異なる。
現在プレゼンスを提供するものの代表は、ＩＭＰＰである。
プレゼンスは一旦プレゼンスを検知するサーバ（以下、「ブローカ」とする）によって、検知されていた。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
エッジノード間で、すなわちブローカなしで、通信相手の状態情報を検知する。
【課題を解決するための手段】
【０００５】
（ＩＭＰＰとの相違点）
通信モデル上の宛先が異なる。これを図１に示す。（イ）がＩＭＰＰモデル、（ロ）が到達性確認モデルである。
ＩＭＰＰモデルでは、ブローカを表面的な宛先とし、更にその奥に本当の宛先がある。ＩＭＰＰのブローカは代理応答的であって、本当の宛先の住所について発信元は知ることが出来ない。このためＩＭＰＰモデルでは、エッジノード間の直接通信は出来ない。
【０００６】
（用語）
静的な識別子＝宛先発見させる際の目的語。通常は宛先を網上で特定するために用いられる。具体的にはホスト名やハンドル名、ＵＲＬ等が含まれる。発明者の他の文献との整合の為に、単に「Ｂ」ともいう。
住所＝通信ノードに対する実際のアクセスを掌る網上の住所。単に「Ａ」とも。
第二の通信ノード＝通信の開始を欲する発意者の用いる通信ノード。発信元の役割をする場合、単に「Ｓ」とも。
第一の通信ノード＝発信者が通信の開始時点で、通信相手として特定する静的な識別子でもって、発見した通信ノード。単に「Ｔ」とも。（本願では発見されなかった場合は、ＮＵＬＬ値でもって発見されたものとみなす。つまり実ノードの存在不存在を問わない）
宛先とは、発信者が発信する時点で、意図している通信相手のこと。静的な識別子で以って発見される。本質的には通信ノードであるべきだが、ヒトをして通信ノードにケ体（化体）されている場合がある。なお利用者との表現は、ヒトであることを示す。
マッピング公示システム＝静的な識別子と動的な住所の写像を公示するサーバ亦はシステム。単に「Ｄ」とも。
【０００７】
（未公開の出願）
「オンライン／オフライン」を検知する手段については到達性確認として、本出願人による本願出願時点で未公開の特許出願PCT/JP03/16538（以下、「特許文献１」とする）及び特願2002-371448によって発明されている。
図２に特許文献１の基本的なシーケンスを示す。
Ｓ１０２では、第一通信ノードは静的な識別子と自ノードに割当てられてなる住所を、マッピング公示システムに写像する。
Ｓ１０４では、第二通信ノードは宛先を示す静的な識別子に対する現在住所をマッピング公示システムに対して問合せる。
Ｓ１０６では、マッピング公示システムは問合せを受けた静的な識別子と対応付けられた住所を、第二通信ノードに応答する。
Ｓ１０８では、第二通信ノードはＳ１０６で知り得た住所宛にカウンターサイン信号を要求するサイン信号を送信する。
Ｓ１１０では、第一通信ノードはカウンターサイン信号を応答する。
Ｓ１１２では、第二通信ノードは記憶する「答えられるべき返事」が前記カウンターサイン信号に含まれているか否かによって、到達性の真偽を判断する。
Ｓ１１９では、到達性確認の結果が真だった場合には、後続する処理に連結してもよい。例えばインスタント・メッセージング等である出来る。
【０００８】
（概要）
第一部：附加情報をもキャリーするカウンターサイン信号
第ニ部：発信元識別
第三部：発信元識別を用いて選択的に応答する附加情報をもキャリーするカウンターサイン信号
【発明の効果】
【０００９】
１．エッジノード間で、すなわちブローカなしで、通信相手の状態情報を検知することに成功した。
【００１０】
２．ＩＭＰＰでは混同されていた、本来異なるレイヤに属する情報を整理した。
ＩＭＰＰでは、「オンライン／オフライン」と「在席／離席」が一体となっており、未分化であった。
本発明では、表のように分割する。
（表１）
0004829111.tif 000002
したがって附加情報とは、高度なプレゼンスを指す。
更に、通信相手の状態情報とは、以下のように分割され得るものである。
（表２）
0004829111.tif 000003
ヒトの状態情報については、ヒトの状態情報検知手段が別途用意されているのならば、検知可能である。しかしＩＭＰＰでは、単にヒトが設定したメッセージに過ぎない。例えば「忙しい」は、本発明ではヒトの状態情報ではなく、メッセージとして扱う。
【００１１】
３．到達性確認では、宛先に対して到達するか否かのニ値しか知ることが出来なかった。
それに対して本発明では、通信相手の状態情報を知ることが出来る。また、通信相手の状態情報に替えて、簡易メッセージを送ることが出来る。ただしこれはＩＭＰＰにおけるインスタントメッセ−ジ的なリアルタイムさもないし、基本は双方向の通信ではない。（その意味では、単なるメッセージ通知システムである。リアルタイム性が必要ならば後続する処理として、従来のインスタントメッセージ亦はその代替物等に接続すればよい。）
通信相手の状態情報には、ヒトの状態情報の場合と、モノの状態情報の場合とがある。
【図面の簡単な説明】
【００１２】
【図１】ＩＭＰＰとの比較
【図２】到達性確認のシーケンスを表す図
【図３】網全体ブロック図
【図４】通信モデル（理論）
【図５】第一通信ノードの処理の概要（理論）
【図６】第一通信ノードがルータでコンソールがＰＣ（第一通信ノードの動作）
【図７】電文フォーマット（理論）
【図８】第ニ通信ノードにおいて記憶されるレコード（理論）
【図９】第ニ通信ノードのブロック図（第ニ通信ノードの動作）
【図１０】第ニ通信ノードのフローチャート（第ニ通信ノードの動作）
【図１１】第ニ通信ノードの表現形式を変更して表示する際のフローチャート（第ニ通信ノードの動作）
【図１２】第一通信ノードのブロック図（第一通信ノードの動作）
【図１３】第一通信ノードのフローチャート（第一通信ノードの動作）
【図１４】第一通信ノードのプログラム呼出のフローチャート（第一通信ノードの動作）
【図１５】第ニ通信ノードの結果表示画面例（特許文献１の到達性確認の結果が真の場合）（第ニ通信ノードの画面例）
【図１６】第ニ通信ノードの結果表示画面例（特許文献１の到達性確認の結果が偽の場合）（第ニ通信ノードの画面例）
【図１７】第ニ通信ノードの結果表示画面例（本発明の場合）（第ニ通信ノードの画面例）
【図１８】第一通信ノードの設定画面例（特許文献１の範囲）（第一通信ノードの画面例）
【図１９】第一通信ノードの附加情報設定画面例１（第一通信ノードの画面例）
【図２０】第一通信ノードの附加情報設定画面例２（第一通信ノードの画面例）
【図２１】第一通信ノードの附加情報設定画面例１の別案（第一通信ノードの画面例）
【図２２】第一通信ノードの設定時エラー画面例（第一通信ノードの画面例）
【図２３】ＧＰＳの出力例（第一通信ノードの画面例）
【図２４】第ニ通信ノードの結果表示画面例（地図形式の表示例）（実際的応用）
【図２５】第ニ通信ノードの結果表示画面例（住所形式の表示例）（実際的応用）
【図２６】第ニ通信ノードの結果表示画面例（地図形式の表示例２）（実際的応用）
【図２７】宛先発信元間において、相互に受信部１３０と発信部２３０を実施した場合のホストの関係を示す図である。
【図２８】宛先と発信元の通信ノードが等価な場合に発生するピンポン現象を示す図である。
【図２９】宛先が発信元を知る過程を示すシーケンス図である。
【図３０】宛先の役割と発信元の役割とを一の通信ノードで果たす場合のブロック図である。（実施例２）
【図３１】発信元の動作であって最初のサイン信号の送信からカウンターサイン信号の受信までを示すフローチャートである。（実施例２）
【図３２】宛先の動作であってサイン信号を受信した場合を示すフローチャートである。（実施例２）
【図３３】フローチャートを第ニ通信ノードと第一通信ノードのシーケンスとして表した図である。（実施例２）
【図３４】発信元の動作であってカウンターサイン信号が返ってこなかった場合を示すフローチャートである。（実施例２）
【図３５】特許文献１図３７に対応する図である。（実施例３）
【図３６】特許文献１図３７に示す宛先側カスタマ網に対して、発信元を追加したことを示す図である。（実施例３）
【図３７】発信元が自らの静的な識別子を含むサイン信号を送信したことによって発信元識別する場合のブロック図である。
【図３８】宛先の動作であって発信元付のサイン信号をトリガとしてする到達性確認を示すフローチャートである。（実施例４）
【図３９】第一通信ノードであって発信元識別をより確実にするための融合型のフローチャートである。（実施例５）
【図４０】特許文献１と本発明のシーケンスを比較した図である。
【図４１】ループバックテストの通信モデルを比較した図である。
【図４２】通信ノードがループバックで到達性を試験するための必要最小限の構成を示したブロック図である。
【図４３】選択的応答の概念図である。
【図４４】選択的応答のブロック図である。
【図４５】選択的応答のフロ−チャートである。
【図４６】選択的に附加情報をもキャリーする場合のブロック図である。
【図４７】選択的に附加情報をもキャリーする場合のフロ−チャートである。
【図４８】知合いにのみ応答する場合のブロック図である。
【図４９】知合いにのみ応答する場合のフロ−チャートである。
【図５０】知合いにのみ附加情報をもキャリーする場合のブロック図である。
【図５１】知合いにのみ附加情報をもキャリーする場合のフロ−チャートである。
【図５２】発信元毎に異なる応答をする場合のフロ−チャートである。
【図５３】電文フォーマットである。
【図５４】レコードフォーマットである。
【図５５】第二通信ノードの特別のメッセージ通知画面例である。
【図５６】第一通信ノードの設定画面例である。
【符号の説明】
【００１３】
10      第一通信ノード
20      第ニ通信ノード
30      マッピング公示システム
40      網
【発明を実施するための最良の形態】
【００１４】
（網全体ブロック図）
図３は、本発明の実施形態の模式的なシステム構成図である。図３には、第一通信ノードと、第ニ通信ノードと、発信元となる通信ノードからの問合せに応じて発信先となる通信ノードの動的な住所を返信するマッピング公示システムとが、インターネットなどの網４０を介して相互に接続される状態を示している。第一通信ノード及び第ニ通信ノードは、共に、ＰＣ、携帯電話機、ルータ等を含む。
【００１５】
（附加情報をもキャリーするカウンターサイン）
特許文献１の３３頁８行目に「すなわち、答えるべき返事には附加情報をも含めることが出来る」として開示したが、これは正確な表現とはいえない。カウンターサインは、「答えるべき返事」に加えてさらに「附加情報」をもキャリーすることが出来るという方が正確である。特許文献１では、「附加情報をもキャリーするカウンターサイン」の具体的な手段、有用性については開示していない。特許文献１では到達性確認出来ることが主題であって、カウンターサインは到達性確認を実現するキャリア信号として開示した。本発明では、カウンターサイン信号が「答えるべき返事」のみならず、附加情報をもキャリーすることによって、有用な成果を得ることが出来るので、この点を説明する。
【００１６】
以下、本発明を図面に基づいて説明する。なお、各図面において同様の機能を有する箇所には同一の符号を付している。以下に掲げる説明は、制限でなく例である。
【００１７】
附加情報を用いるための理論、附加情報を如何にキャリーするか、キャリーされた情報から如何に附加情報を分離するか、そして附加情報は何の役に立つかについて説明する。
附加情報を用いるための理論については、理論編で説明する。
附加情報を如何にキャリーするかについては、第一通信ノードの動作で説明する。
キャリーされた情報から如何に附加情報を分離するかについては、第二通信ノードの動作で説明する。
附加情報は何の役に立つかについては、発明の効果で説明した。さらに具体的な例としては、実際的応用に示す。
【００１８】
（理論）
図４は特許文献１図２２の(4)乃至(5)の過程を切出したものである。
第ニ通信ノードにおいては、「答えられるべき返事」として静的な識別子Ｂのみを、あらかじめ知っているものとしてここでは例示する。
(5)の過程で、第一通信ノードは静的な識別子Ｂ＋αという情報をカウンターサインはキャリーする。
すなわちαが附加情報である。
【００１９】
第ニ通信ノードでは既に静的な識別子Ｂを知っているから、これを差引いた残余の部分が附加情報である。これを抽出し、表示する。
【００２０】
第一通信ノードでは、単に「答えるべき返事」に「附加情報」を追加した情報をカウンターサインにキャリーさせるようにすればよい。（図５参照）
なお、「答えるべき返事」は静的な識別子のみに限定される訳ではなく、特許文献１に示した「類型」に従う。その際には図４中の静的な識別子を前記類型に従って代入されたい。
【００２１】
フォーマット
カウンターサインがキャリーする情報は、図７の論理フォーマットに従う。
亦図７に示した論理フォーマットは、特許文献１に開示したように前記論理フォーマットを１レコードとして複数個からなるレコードとして送信することも可能である。
「答えるべき返事」は、静的な識別子そのものを基本類型とし、そのバリエーションは特許文献１に示した「答えるべき返事の類型」に従う。
【００２２】
以下にフォーマットの具体例を挙げる。
特許文献１で「答えるべき返事」を如何に埋め込むかについて、Daemonに埋め込む方法を紹介した。この場合はDaemonの設定ファイルを変更し、リコンパイルし、Daemonを再起動しなければならない。よって附加情報をもカウンターサインがキャリーする場合には、あまり現実的ではない。附加情報は比較的短時間で変更される種類の情報であることが予想されるからである。しかし特許文献１にはＨＴＭＬ文に埋め込む方法も紹介した。こちらは問題がない。ＨＴＭＬが利用可能なら当然に、ＸＭＬ、ＳＤＰ等も利用可能である。加えて、ＲＦＣ２７７９の「IDENTIFIER」の項に紹介される「多数のCGIパラメーターや長い不定な識別子を含むURL等」を利用して附加情報を埋め込むことが可能である。
不定な識別子を連続して埋め込むことによって電文長は長くなるが、これらは識別子とはみなされない（ＲＦＣ２７７９）為、逆に附加情報を埋め込む場所として用いることが出来る。
【００２３】
サンプルはインターネット上の動的に応答するウェブページを参照されればすぐに見つけられるはずである。
例えばこんな感じである。
http://www.example.com/search?q=%E7%AE%B1%E3%81%AE%E4%B8%AD%E3%81%AE%E5&ie=UTF-8&oe=UTF-8&hl=ja&lr=
特許文献１の３１頁１行目乃至３行目及び
特許文献１の３３頁１２行目乃至１５行目から、
カウンターサインによってキャリーされた情報の中から不要な文字列を取除いた後（特許文献１図２３Ｓ２１０）の文字列中に、「答えるべき返事」が含まれていれば到達性確認で真である。ここから、カウンターサインによってキャリーされた有意な情報には、「答えるべき返事」でないものが含まれる場合がある。これが附加情報の起源である。すなわち、「答えるべき返事」でない情報を第一通信ノードであえて附加することによって、第ニ通信ノードで受取る情報のうちの無駄な部分を附加情報とするという思想である。
【００２４】
前記した例は通常は、ＨＴＴＰでいうところのＰＯＳＴリクエスト等で用いられる表現である。
フォームの変数名と変数値を "=" にて結び、それらを "&" や ";" 等のデリミタにて連結することは従来からよくされていることなので、このような表現によってもカウンターサイン上において「答えるべき返事」のみでなく「附加情報」をもキャリーすることが出来る。
なお、この場合頭のhttp://は決め打ちの情報である。この際、既に説明したように、「答えるべき返事」は、静的な識別子そのものを基本類型とし、そのバリエーションは特許文献１に示した「答えるべき返事の類型」に従う。すなわち、「答えるべき返事」がＵＲＩスキームの場合には必要だが、それ以外の場合は無視するべきである。よって、第一通信ノードがカウンターサインを生成する時点で、「答えるべき返事」がＵＲＩスキームでない場合には、http://は含めないようにしたほうがよい。亦http://はプロトコルを表すが、本発明ではプロトコルは問わない。したがっていかなるプロトコルであってもよい。このような表現形式の問題は発明の本質ではない。以上によって、カウンターサインからの差分抽出によって、附加情報をも伝達可能であることを示した。
【００２５】
なお、前記表現形式の問題は文法や表現に属するものなので、特許明細として言及するのはここまでとする。本明細書ではこれらの文法や表現については、何ひとつ規定していない。（前記は文法に属するものと考える。そして日本では、文法は「人為的な取り決め」と考えられており、特許の対象とならない。その意味で前記は本発明の本質ではなく、利用可能な文法について例を挙げたに過ぎない。）ただ、実施可能性があることを示すために例を挙げただけである。亦プロトコルについても規定していない。すでに特許文献１や特許文献２でも挙げたように表現や合意については、自由にデザインする余地を残してある。
【００２６】
フォーマットについてまとめれば、以下のようになる。
図７が電文フォーマットである。なお（イ）については、図示しない制御用ヘッダやプロトコル的に自明な部分が含まれているが、省略してある。
【００２７】
第一通信ノードにおいて記憶されるレコードフォーマットについては図は省略する。特許文献１から、「答えるべき返事」のみ記憶しておけばよい。附加情報については、Ｓ８０２の説明に譲る。これは附加情報をもキャリーするカウンターサインは、サインの受信の後に動的に生成されることを基本とするからである。
【００２８】
第ニ通信ノードにおいて記憶されるレコードフォーマットについては図８にまとめた。ただし、図８においては、特許文献１に示した「答えるべき返事の類型」にしたがう。すなわち「答えられるべき返事」が自明である場合には、第ニ通信ノードはあえてレコードとして記憶する必要がない。例えば「答えられるべき返事」が宛先の静的な識別子そのものである場合等である。そしてこの場合には、対応する第一通信ノードの静的な識別子をも記憶する必要がないことは、特許文献１に説明したとおりである。第ニ通信ノードの利用者の発意によって、宛先としての静的な識別子を手動にて入力してもよい。すなわち事前の設定が不要な場合である。このことによって、特定の宛先のみでなく、あらゆる通信ノードを宛先として指定することが可能となる。図８は、第ニ通信ノードのブロック図である図９の登録済宛先情報２１２に相当する。
【００２９】
（第ニ通信ノードの説明）
図９は、図３に示す第ニ通信ノードの模式的な構成を示すブロック図である。図９には、例えばコンソール等のユーザＩ／Ｆを提供する設定部２２０と、到達性確認する際の制御をする発信部２３０と、諸々の情報を記憶する記憶装置２１０と、網４０に接続するための物理的な通信Ｉ／Ｆ２９０とを示している。
ブロック図では、コンソールについては図示していない。コンソールは、シリアルやイーサネットによって接続されたＰＣであっても、直接接続されたディスプレイとキーボードからなる組であっても、亦その他のものであってもよい。第一通信ノードについても同じとする。
【００３０】
発信部２３０は、以下説明する、住所取得部２３１と、サイン信号送信部２３２と、カウンターサイン信号受信部２３５と、判定部２３６と、附加情報処理部２３７と、表示部２３８とを備える。
住所取得部２３１は、第一通信ノードに係る静的な識別子をマッピング公示システムに問合せることによって、宛先通信ノードの住所を取得するものである。
サイン信号送信部２３２は、住所取得部２３１によって取得された住所宛てにサイン信号を送信するものである。
カウンターサイン信号受信部２３５は、他の通信ノードから送信されてきたカウンターサイン信号を受信するとともに、作業領域２１９に一時記憶するものである。
判定部２３６は、作業領域２１９に一時記憶された返事に基づいて当該カウンターサイン信号が所望の通信ノードから送信されたものであるか否かという到達性確認を行うものである。
附加情報処理部２３７は、作業領域２１９に一時記憶された返事から附加情報を抽出し、表示部２３８に受渡し可能な情報に変形するものである。
表示部２３８は、到達性確認の結果亦は附加情報がある場合にはその内容等を、第二通信ノードの使用者に図示しないユーザＩ／Ｆを介して表示亦は第二通信ノードでする後続する処理に接続するものである。
【００３１】
第ニ通信ノードの主要な役割は、特許文献１に開示した到達性確認に加えて、受信したカウンターサインから附加情報を分離し表示することである。
【００３２】
再度、図４を参照されたい。
図４は、到達性確認の手順を表した特許文献１図２２の(4)乃至(5)の過程を切出したものである。
【００３３】
シーケンス(5)は、図４のＳ１１０に相当する。第ニ通信ノードはカウンターサインを受け取る。
第二通信ノードは、この受け取ったカウンターサインから抽出した「答えるべき返事」と保持していた「答えられるべき返事」を比較し、第一通信ノードへの到達性の正しさ（つまり通信相手の正しさ）を確認する。
そして第ニ通信ノードでは特許文献１図２３Ｓ２１０「その返事から不要な文字列を取除く」。ここで「不要な」とはプロトコル的亦は文法的に自明の部分と考えればよい。するとデータのみが抽出される。
【００３４】
次いで特許文献１図２３Ｓ２１２で「返事が一致したか」を判断する。ただし、フォーマットの項で説明したように、完全一致の場合だけでなく、含まれていればよい。
ここまでは、特許文献１の技術である。
しかし附加情報を含む場合には、完全に一致することはない。しかしカウンターサインによってキャリーされてきた情報には、第一通信ノードの「答えるべき返事」が含まれている。そしてこの部分のみは完全に一致するはずのものである。すなわち第ニ通信ノードは受取ったカウンターサインから「答えられるべき返事」を差引いた残余の部分が附加情報である。
なお附加情報には、デリミタ等が含まれる場合がある。ＸＭＬ等では有意な附加情報を明示にキャリーすることも出来る。
このようにしてカウンターサインは附加情報をキャリーすることが出来る。
【００３５】
これをフローチャートにしたものが図１０である。
Ｓ２０２は、到達性確認の結果によって、分岐している。なおＳ２０２は、特許文献１図２３Ｓ２１２に相当する。亦Ｓ２０２以前にサインを送るなどの到達性確認のステップが必要だが省略してある。
Ｓ２０４が、ここまでに説明した部分である。すなわち受信したカウンターサインから附加情報を分離、そして少なくとも表示するまでの期間記憶する部分が含まれる。附加情報が含まれるかどうかの判断は、受取ったカウンターサインから「答えられるべき返事」を差引いた残余の部分（プロトコル的に自明な部分は除く）があるかないかで判断する。
Ｓ２０６は、真の到達性確認の結果表示と供に、附加情報を表示する。なおここで、特許文献１に示したフィルタの場合、すなわち表示ではなく後続する処理に接続する場合も同様である。
Ｓ２０８は、到達性確認の真の結果表示である。これは特許文献１に示した技術である。しかし、あえてここで「附加情報はありません」等のメッセージを追加して表示しても良い。
Ｓ２１０は、到達性確認の偽の結果表示である。特許文献１に示したものと同じである。
【００３６】
Ｓ２０６については以下のステップを含めても良い。これを図１１に示す。
Ｓ６０２では、附加情報の形式を判断する。
Ｓ６０４は、形式に合ったプログラムをコールし、（Ｓ２０４で）抽出された附加情報を代入する。（すなわちこの間において一時記憶する必要がある。しかし一時記憶については自明の技術に該当するため、以降では説明しない）
Ｓ６０６は、該プログラムの出力を受取る。
Ｓ６０８は、表現形式に合ったもので表示する。入力を文字列とし、該プログラムの出力が文字列でないものである場合がある。例えば画像データ等である。この場合には、画像を表示する結果表示画面を作成するのがＳ６０８である。ここでは既に到達性確認の結果が真である事が判っているから、これと併せて附加情報を表示する。ただし、到達性確認の結果が真であることが第ニ通信ノードの利用者にとって関心がないことが判っている場合や、フィルタとして用いる場合には、単に附加情報のみであってもよい。なお表示とは、例えばブラウザで見る場合には、ＨＴＭＬ文の作成が含まれるものとする（これは自明である。そうでなければ、描画手段やブラウン管の走査まで説明しなければならない）。ここでのポイントは、理解しやすい表現形式に変更することによって、第ニ通信ノードの利用者にとっての利便性を向上させることである。
このようにすることによって例えば、附加情報としてＧＰＳ出力を文字列として受取った場合に、第一通信ノードの現在位置を地図として表示すること等に役立つ。
ただしこれは任意である。例えば附加情報がヒトに対してするメッセージそのものである場合等は、表現形式をあえて変更する必要がない。
亦この時図７（ロ）のように附加情報が複数含まれている場合には、附加情報の個数を限度として必要な回数だけ図１１に示した変換作業を繰返してもよい。
【００３７】
（第一通信ノードの説明）
図１２は、図３に示す第一通信ノードの模式的な構成を示すブロック図である。図１２には、例えばコンソール等のユーザＩ／Ｆを提供する設定部１２０と、被到達性確認する際の制御をする受信部１３０と、諸々の情報を記憶する記憶装置１１０と、網４０に接続するための物理的な通信Ｉ／Ｆ１９０とを示している。
【００３８】
受信部１３０は、以下説明する、サイン信号受信部１３１と、「答えるべき返事」読出部１３５と、附加情報処理部１３６と、カウンターサイン生成部１３７と、カウンターサイン送出部１３８とを備える。
サイン信号受信部１３１は、第ニ通信ノードからのサイン信号を受信するものである。
答えるべき返事読出部１３５は、答えるべき返事記憶部１１２から「答えるべき返事」を読出すものである。
附加情報処理部１３６は、附加情報記憶部１１３に記憶されてなる、メッセージ亦は状態情報取得手段に基づいて通信ノード亦はヒトの状態情報を取得するものである。この際状態情報取得手段は、附加情報記憶部１１３に記憶されてなる外部プログラムへのポインタであることが許容される。
カウンターサイン生成部１３７は、「答えるべき返事」読出部１３５および附加情報処理部１３６の出力に基づきカウンターサイン信号を生成するものである。
カウンターサイン送出部１３８は、カウンターサイン生成部１３７によって生成されたカウンターサインを送信するものである。
なお自ノードを示す静的な識別子記憶部１１１はマッピング公示システムに静的な識別子と動的な住所からなる組を写像する際に用いるものであって、被到達性確認の際には必須ではない。
【００３９】
第一通信ノードの基本的な役割は、特許文献１に開示したカウンターサインを実装した上で、さらに附加情報をも埋め込んだカウンターサイン信号を生成することである。
すなわち第一通信ノードの動作に関しては、単に「答えるべき返事」に「附加情報」を追記してカウンターサインにキャリーさせるようにすればよい。これを図５に示す。
【００４０】
この際、特許文献１同様に第一通信ノードが網接続機器の場合と端末（計算機を含む）の場合の両方が考えられる。
ａ、端末で直接
ｂ、網接続機器がカウンターサインを返す場合に、
端末から網接続機器に更新
ｂの場合のイメージを図６に示す。なおｂの場合の端末は、以下で説明するコンソールだと考えればよい。
【００４１】
フローチャートを図１３に示す。
図１３は、サインを受けたときの第一通信ノードにおける動作を示すフローチャートである。
開始は、サインを受取った後から始まる。
Ｓ４０２は、まず自ノード内において「答えるべき返事」が設定されているかどうかを判断する。ここで設定されていない場合には、そもそもカウンターサインは返信する必要がない。（ただしこの場合であっても、カウンターサインを返信すること自体を妨げるものではない。すなわち「答えるべき返事」が空文のカウンターサインを返すことは、図１３中の「何もしない」に含まれる。「答えるべき返事」が空文のカウンターサインを応答する場合には、Ｓ４０２は省略可能である。もちろんこの場合は、カウンターサインを受取った第ニ通信ノードは、不明な「答えられるべき返事」しか受取ることができないので、実際の到達性の如何に係らずに到達性確認の結果は偽になる）
Ｓ４０４は、附加情報の設定の有無を判断している。
附加情報が記憶されている場合には、附加情報の設定があるので、Ｓ４０６に進む。附加情報の設定が存在しない場合には、Ｓ４０６をスキップしてＳ４０８に進む。Ｓ４０６をスキップした場合には、特許文献１の場合となんら変わりはない。すなわちここでは「答えるべき返事」は、自明のものとして含まれている（すなわち「答えるべき返事」の読み出しについては図示していない）。
Ｓ４０６は、「答えるべき返事」に「附加情報」を追記したカウンターサインを生成するステップである。
Ｓ４０８は、カウンターサインを返信するステップである。Ｓ４０６で生成された結果か、単に「答えるべき」返事を読み出して、カウンターサイン信号にキャリーさせて送出すればよい。
【００４２】
（画面例）
本発明の場合にあっては、結果表示や、どのような情報をどのように設定するかについて、画面例を示すことは大いに理解を助けるものと思われる。
以下に、本発明を図面に基づいて説明する。なお、各図面において同様の機能を有する箇所には同一の符号を付している。以下に掲げる画面例は、制限でなく例である。
【００４３】
（第ニ通信ノードの画面例）
まず、特許文献１の範囲の結果表示例を示す。
図１５は、到達性確認の結果が真の場合の結果表示画面例である。メッセージ内容は、特許文献１実際的応用の表示の場合にしたがって、「オンライン」や「出席」亦は「到達可能」としてもよい。
図１６は、到達性確認の結果が偽の場合の結果表示画面例である。メッセージ内容は、特許文献１実際的応用の表示の場合にしたがって、「オフライン」や「欠席」亦は「到達不能」としてもよい。
【００４４】
本発明の結果表示例を示す。
図１７は、本発明の場合の結果表示画面例である。図１７は図１５に対して、さらに附加情報が表示されているものである。この際メッセージの内容は、「相手先の状態は△△△△△△△△△です」等でもよい。
【００４５】
（第一通信ノードの画面例）
第一通信ノードの動作に関して、附加情報を如何に設定するかを設定画面例で説明する。
ここでは設定画面例を通して、どのような情報を附加情報として第ニ通信ノードに伝達出来るかのイメージを持ってもらいたい。
ラジオボタンは複数あるうちから一が選択されるものとする。亦エラーについては網羅しているわけではなく、本発明と関連のあるもののみを示した。例えばラジオボタンが選択されていなかった場合のエラーについては、本発明に限ったエラーではないために触れていない。
【００４６】
まず、特許文献１の範囲の設定画面例を示す。
図１８は、「答えるべき返事」の設定画面である。図１８には、画面１から画面２に進み、画面１−２に戻る第一通信ノードで表示する設定画面の様子を、手順に従って示した。画面１−２は画面１の設定内容を反映したものである。
画面１は、いわゆるメニュー画面である。ここでカウンターサインを「変更する」ボタンを選択することによって、画面２の「答えるべき返事」の設定画面に移動する。なおボタンに表示する文言は「変更する」ではなく「設定する」であってもよい。
画面１でカウンターサイン（「答えるべき返事」を指す）を設定する以前に、附加情報を「変更する」ボタンを押下した場合は、図２２のようなエラーが表示されるようにすると親切である。これは以下の理由による。「答えるべき返事」がなければ「附加情報」のみがあっても意味がない。カウンターサインは原始的に「答えるべき返事」がなければ成立たないからである。（特許文献１「不明な応答」を参照されたい。特許文献１では「不明な応答」を以って、到達性確認の結果が偽であると判断している）
画面２は、「答えるべき返事」の設定画面である。ここでラジオボタンから「カウンターサインを設定する」を選択し、入力フィールドに「答えるべき返事」を入力する。
なお、画面例２の選択されたラジオボタンは「カウンターサインを設定する」ではなく、「答えるべき返事を設定する」とのメッセージであってもよい。
そして「反映する」ボタンを押下することによって、画面１−２に戻る。ここで画面１−２は画面１を意味するものであって、画面２でした設定内容が反映されたものであるところの画面１である。以下、枝番付の画面例は同じとする。
画面１−２で附加情報を変更するボタンを押下した場合には、附加情報の設定画面であるところの画面３に移動する。
以上は、特許文献１で説明した「答えるべき返事」を設定する際の例を、画面例に従って説明しなおしたものである。
【００４７】
次に本発明の設定画面例を示す。
図１９乃至図２０は、附加情報設定画面である。附加情報としては、以下のメッセージや状態情報を通知出来る。
図１９画面３は附加情報の設定画面である。ここでは附加情報としてキャリー出来る文言の例を多く挙げた。上から「パターン選択」と「自由文字列」は、主にヒトの状態情報の場合である。
「プルダウンメニューからパターンを選択」は、パターン例を睡眠中、入浴中、食事中、外出中等の中から選択するものである。
自由文字列があることから、単純な一方向の通知にも使用することが出来る。例として「出奔します。捜さないでください・・・」等がある。亦、「あけましておめでとう」といった季節の挨拶や「新商品Ｘをよろしく」といった広告等もよい。（この例は象徴的かもしれない。本発明はメッセージ交換するものではない。単に通知するのみである。プッシュ型・プル型でいえばプル型に属する。メールやショートメッセージの方向を逆にしたものと考えることが出来る。あえて云えば「受動型通知」とでも呼ぶべきものである。メッセージを交換するためには、第一通信ノードと第ニ通信ノードが相互にその役割を交換することによって可能である。）
以上が、従来のＩＭＰＰでよく見かけられるメッセージの例である。
しかし、単にＩＭＰＰでいうところのプレゼンスサーバ（すなわちブローカ）の機能を、網におけるエッジ側の通信ノードに移動させただけではない。
【００４８】
次いで「プログラム出力」、「外部プログラムの出力を代入」、「プラグイン」は通信ノードの状態情報の例である。
プログラム出力や内部変数を附加情報として、カウンターサインに埋込むことが出来る。
ＩＭＰＰと比較して優位な点は、以下の通りである。
・拡張可能性があり、
・柔軟である。
「プルダウンメニューからプログラム出力を選択」した場合は、（ヒトではなく）通信ノードの状態情報としてよくあるものを例示してみた。例えばメモリ使用率は、第一通信ノード内の変数を参照するだけでよいだろう。しかし、ＣＰＵ負荷率やトラフィック状況等は通常は、集計を要する。メモリ使用率も変数としてあえて記憶されていない場合が多いと思われるので、これら情報へのアクセス手段は、通常はプログラムを経由する。
亦プルダウンメニューに含まれないものであっても、別途外部プログラムを起動し、その出力を附加情報へ代入出来るようにした。コマンドラインで入力するのと同じように引数を付けることが出来る。これを入力フィールドに入力すればよい。
なお外部プログラムの起動法であるが、図１３Ｓ４０６でする生成をトリガにプログラムを起動するようにすればよい。これを図１４に示す。
図１４については、注意点のみ挙げる。
Ｓ８０２の附加情報設定ポインタとは、図１９乃至図２０の附加情報設定作業終了後に生成されるポインタであって、附加情報記憶部１１３に記憶される附加情報の取得方法が記述されたものである。図１９画面３で、「パターン選択」および「自由文字列」は単に記憶された変数を指せばよい。亦「プログラム出力」や「プラグイン」についてはプログラムを呼出す場合である。よって、附加情報設定ポインタの中身は、フラグとして、変数であるかプログラム呼出しであるかの別、変数なら変数名、プログラムならプログラム呼び出し方法、そしてその他の情報が記憶されているものである。後はこれに従って分岐し、所要の手続（変数を得るか、プログラムの返り値を得るか）を経た後、Ｓ８１０の追記を行えばよい。
亦プログラムの返り値がキャリー可能な文字でない場合には、Ｓ８０８において、キャリー可能な文字列に変換すればよい。ただしこの時点ではヒトにとって意味のある文字列である必要はない。第二通信ノードでする図１０Ｓ２０６亦は図１１の一連の処理によって、表示する時点でヒトにとって意味のある表現形式に変形されれば足るからである。
【００４９】
プラグインは既に一般的な概念になっている。本発明では、以下のように考える。
一般的にはプラグインとは、機能を追加するための拡張モジュールを指す。拡張モジュールとは、取り外しや交換が簡単に出来る部品やプログラムのことである。そしてここでは単に外部プログラムの出力を附加情報の内容として設定するするしくみである。場合によって、外部デバイスとの通信モジュールであることが最大の機能である。
本発明におけるプラグインの実際の位置付けとしては、「外部プログラムの出力を代入」のうちのよく使いそうなもの亦は（／かつ）標準で用意することが難しいものを、単に「プラグイン」に置換えた（表示上の位置を移動した）だけである。
画面４はプラグインの選択画面の例である。ポップアップウィンドウとして表現してみたが、ポップアップウィンドウではなく通常の画面であってもよい。プラグイン選択後は、通常はプラグインとして選択されたプログラムの設定画面に移行する。
【００５０】
ここで、サインを受信したことをトリガにプラグインが起動される。（画面３および画面４によって、附加情報の生成方法として「プラグイン」が選択された場合）
プラグインの機能は以下の３つに集約される。
１、ローカルの変数を取得する。
２、外部プログラム亦はサブルーチンをコールし、その返り値を得る。
３、外部の通信ノード亦は、デバイスと通信してその返り値を得る。
１については、ローカルの変数を直接参照できないときに、プラグインによって機能追加すればよい。その意味で、１と２は同じである。３については、デバイスとは通信ノードでないものを指す。例えば計測装置であるが通信ノードでないものであって、バスやシリアルを経由してデータ収集出来るようなものである。
３の場合には、外部からは一体となって見える範囲の第一通信ノードたる通信ノードが直接入手できない情報を附加情報とすることが出来る。具体例で考える。
例えば、ＧＰＳレシーバと通信して位置情報を得る場合を考えてみる。場合によってはフォーマット変換してもよい。
規格によっては、すべての文字がASCIIテキストの「センテンス」で位置情報を得ることが出来る。センテンスとは、ＧＰＳレシーバとデータをやりとりするためのレコードをいう。
例えば、図２３のようにである。
このように文字列として表現されている場合には、そのまま附加情報に埋め込むことが出来る。このようにヒトにとって意味のない文字列の場合には、第ニ通信ノードでする図１１によって、ヒトにとって意味のある表現に変形して表示すると親切である。例えば前記ＧＰＳ出力は所番地を示す文字列として表示されても地図として表示されてもよい。この具体例は実際的応用に示す。
【００５１】
プラグインは外部プログラムである。そしてこの外部プログラムの返り値を附加情報に設定する。具体的には、附加情報を示す記憶域を示すポインタの先に書き込むようにすればよい。
ＧＰＳレシーバは通常はＲＳ２３２Ｃシリアルを通じて通信する。多くのルータではシリアルポートは存在するので問題がないが、より小型の装置、例えばＮＡＴＢＯＸの場合にはシリアルポートが存在しない場合も多い。そのような場合には、プラグインが通信する相手をＧＰＳレシーバ亦はＧＰＳアンテナと接続されたＰＣ等の通信ノードとすればよい。この場合のプラグインの動作は、単に通信ノードが返してきた返り値を附加情報に設定すればよい。
【００５２】
ところで図１９の変形例を図２１に示す。
図２１は、図１９画面３の「外部プログラムの出力を代入」を「プラグイン選択」の中で表示するように変更したものである。この場合には、外部プログラムの呼出方を指定する画面をポップアップウィンドウ等によって入力させるようにするとよい。要するに、通信ノードの状態情報を収集する手段であるところの画面３中に示した、「プログラム出力」、「外部プログラムの出力を代入」、「プラグイン」は、いずれも外部プログラムの出力結果を附加情報の内容として設定するものである。
【００５３】
図２０は、プラグインで「ＧＰＳ（ＰＣ）による位置情報」を選択した場合に、画面３に戻った場合を示す。ラジオボタン「プラグイン」の下に設定内容を表示するメッセージが追加されていることに注意されたい。これが画面３―２である。ここで「反映する」ボタンを押下することによって、メニュー画面であるところの画面１に戻る。この際、メッセージに設定内容が反映されたものを画面１―３に示す。なおメッセージ内容の反映は、ここまでにした説明の都合上、設定したことを明確にするために、あえて画面１、画面１−２、画面１―３等と変化させたものである。実装の際には、変化させてもさせなくてもよい。
【００５４】
なお図１９画面３の「附加情報を設定しない」を選択した場合は、単に明示に附加情報を設定しないようにしただけであるので、別段説明を要しない。
その他、図に示した例のみでなく、インターフェース・リンクアップ速度やアプリケーション使用状況、ベンダーコード・製品番号・製造番号といったハードウェアを個体識別する情報やファームウェアバージョン、網接続機器等の場合には網設定情報等といった情報を附加情報としてキャリーしてもよい。これらについては画面例には示さなかったので、適宜変更されればよい。
【００５５】
（実際的応用）
本発明の直接的な受益者は第ニ通信ノードである。
第ニ通信ノードの動作で説明した「Ｓ２０６には以下のステップを含めても良い」を思い起されたい。
仮にキャリーされた附加情報の内容が、図２３のようなＧＰＳ出力であって、文字列であった場合か亦は文字列に変換後のものであった場合には、以下のことが出来る。
附加情報の形式判断によって表現形式に合った出力、例えば第一通信ノードの現在位置を示す地図的な画像という表現形式を取ることが出来る。例えば、図２４のようにである。
図２４は、地図に変換して表示する場合である。
図２５は、住所に変換して表示する場合である。
図２６は、第一通信ノードの移動した軌跡と第一通信ノードの現在位置を表示する場合である。図が不鮮明である場合に備えて、登山した場合のルートについて表示したものであることを附言しておく。
本発明はＩＭＰＰでいうところのフェッチャとして第ニ通信ノードを説明してきた。ポーラは、単にフェッチャを反復的に実施するだけなので、一定時間毎にフェッチャの動作を繰返すことによって、第一通信ノードの移動履歴を得ることが出来る。図２６は、この履歴情報を第一通信ノードの移動した軌跡として表示し、かつ第一通信ノードの現在位置と供に表示した場合である。
【００５６】
類似の効果を有するものに移動電話会社が提供する役務が既に存在する。しかしこれは、移動電話システムが呼の確立手順上必要である、移動体端末の位置する場所を管理する基地局認識番号を利用してなされたものである。しかしこれは特定の電話会社の網に閉じた役務である。さらに蓄積交換網を経由して、第一通信ノードの位置を通知するしくみは存在しない。よって本発明の特許性を損なうものではない。ところで、第一通信ノードの位置情報はＧＰＳ出力のみでなく、基地局認識番号でもって代替することが出来る。いずれにしても第ニ通信ノードにおいては、第一通信ノードからキャリーされてきた附加情報を、ヒトにとって見易い形式に変換して表示することが出来る。図２３に例示したＧＰＳ出力のようにヒトが見ても一般に理解することができない情報の場合には、このような過程は重要である。
なお、公共のためにする到達性確認の結果を表示するＳ−１においてする場合は、到達性確認することのできない通信ノードに対しても、第一通信ノードの位置を知る手段を提供することが出来る。この際Ｓ−１ではログインによって契約者を識別し、契約者のみに第一通信ノードの位置情報を提供するシステムであってもよい。
【００５７】
もちろん、「ＧＰＳレシーバと通信して位置情報を得る場合」とはあくまでも例である。第一通信ノードにおいて外部に存在する、何らかのデバイスでありさえすればよい。これは温度計であっても計測装置であってもよい。このようにして得られた情報を第ニ通信ノードに通知（受動的に送信？）するためのキャリア信号が附加情報をもキャリーするカウンターサイン信号である。この場合の利益は、住所を有しない計測機器等の装置が示す計測データをも遠隔地において知ることが出来るようになるということである。ちなみにＧＰＳ装置を第一通信ノードが内包している場合には、単に第一通信ノード内でＧＰＳが記憶する情報を参照するか亦はプログラム経由で当該情報を得た後、附加情報に設定すればよい。この場合は単に「プログラム出力」の例と同じだと考えればよい。
【００５８】
（附加情報の用途）
附加情報の内容については、以下に大別出来る。
１、ヒトの状態情報（すなわちメッセージ）。
２、通信ノードの状態情報（あるいはセンサー出力）。
１については、ＩＭＰＰ代替として用いる場合である。ここで例えば、「忙しい」というヒトの状態情報が附加情報としてキャリーされたとしよう。しかしこの「忙しい」という情報が、ヒトの状態を表すのか、あるいは別の情報であるのかについて識別する方法がない。すなわち内容を理解するのはヒトである。結局、この場合というのは、単なるメッセージ通知こそが本質である。（冒頭において「ＩＭＰＰでいうところのヒトの状態情報は、本来知ることのできないものではないか」との疑問を呈した。これがその答えであって、ヒトの状態情報ではなく、単なるヒトがヒトに対してするメッセージである。つまり「忙しい」は状態情報ではなく、メッセージである）  これはＩＭＰＰにおいては、ヒトが設定した情報であることからも明らかである。
２については、ＩＭＰＰでは使い難かったものである。ＩＭＰＰはあくまでヒト同士でのやりとりを想定されているものであった。そのためこのような機械処理的な部分については、苦手な分野であった。例えば、ログイン後にしか、相手方の状態情報を得ることができない等である（実際にはお互いがログインしている必要がある。本発明ではそもそもログインという概念が存在しない）。すでに説明した通り、この場合は宛先通信ノードそのものの情報だけでなく、宛先通信ノードに接続された計測機器等の収集したデータであってもよい。
以上から、附加情報の用途については、どのような場面で役に立つかという観点で捉えればよかろうと思う。技術的には、文字列で表現可能であれば、いかなる情報でも附加情報として、キャリーすることが出来る。
【００５９】
（プレゼンスの本質）
予備的な通信は、発意に基づいて、すなわち発信者が通信を欲したときに、本番の通信に先立ってすればよい。
ＩＭＰＰの場合は、プレゼンスにおいて予備的な通信であるという性格はそれほど強調されていなかった。むしろリアルタイム性という側面が強調されていたものである。例として特開2003-296259段落０００４（従来の技術）を引用してみる。「従来のプレゼンス技術においては、端末内で登録している対話者の状態を、すべての対話者を平等な間隔で、しかも非常に短い間隔（１０秒〜３０秒）で問合せている。この理由は、コミュニケーションにおいては、相手に連絡したい時に相手が現在コミュニケーション可能な状態かどうかを知ることが非常に重要であり、これを実現するためには、リアルタイムに近い状態確認作業が必要になるからである」。これはＩＭＰＰにおける一般的な認識を代弁しているといえよう。しかしこれによって実現されるものはアウェアネスであって、予備的な通信ではない。本発明ではＩＭＰＰとは異なって、常に通信相手の状態を捕捉しておく必要がない。常に捕捉しているのだとすれば、それは予備的な通信とはいえない。
すなわちプレゼンス検知のタイミングは、「常に」ではなく、発信者が通信を欲した時にのみすればよい。したがって本発明では心電図の如きリアルタイム性は必要ない。当然に流量は、ＩＭＰＰモデルと比較して激減するだろう。
［００６０］  プレゼンスの本質はアウェアネスではなく、予備的な通信にある。
このことからＩＭＰＰでは実現できなかった、更なる細かい制御が可能となる。例えば、もしデータ収集の精度の為にリアルタイム性が必要な場合には、第ニ通信ノードでするポーリング間隔を短くするだけでよい。タイミングは第ニ通信ノードの欲する任意のタイミングであってよい。重要なことは、ブローカが一方的に押し付けてきたタイミングに従うのではなく、第ニ通信ノードがそのタイミングを決定出来ることである。
ところでＩＭＰＰの場合であっても、後続する処理である所のインスタント・メッセージングに接続されずに満足される場合は非常に多かった。同様に本発明でも発信者は宛先の状態情報を知ることで満足し、本番の通信に接続しない場合はあってよい。
［００６１］  ここまでの発明では通信相手について開かれている。ＩＭＰＰとは異なって、事前の対話者の登録によって、プレゼンス情報を相互に交換するものではない。誰もが、そしていかなる通信ノードも、第一通信ノードの附加情報を参照することが出来る。
そこで第一通信ノードが第二通信ノードに対して、通信相手によって選択的に応答する手段を示す。
このためにはまず第一通信ノードが第二通信ノードを識別できなければならない。
これを発信元識別と言う。
なお、この際に第一通信ノードの静的な識別子が属している宛先発見過程と第ニ通信ノードの静的な識別子が属している宛先発見過程とは、同一の宛先発見過程である必要はない。
［００６２］（発信元識別）
これについては、実は特許文献１の中で触れていたものである。
これまでの説明の通り第一通信ノードは、通信の開始時点において宛先である。
第二通信ノードは、同時点で発信元である。
特許文献１では第一通信ノードがサイン信号を受信した時に、今度は発信元として第二通信ノードに対してサイン信号を送信することによって、最初の発信元（すなわち第二通信ノード）の静的な識別子を知ることが出来るとした。
【００６３】
これを図にすると図２７のようになる。（イ）が特許文献１の場合、（ロ）が本発明である。
本発明では、第一通信ノードは、最初の通信である宛先としての立場での通信を受けて、今度は発信元として第二通信ノードを宛先として通信する。よって、立場が逆転する。
発信元と宛先の関係は、電話を例にとると判りやすい。当然に電話を掛ける側が、発信元である。電話を受ける側が、電話を掛ける側から見て宛先である。
電話は双方向通信といえども、このように電話を掛ける側（発信元）と電話が掛かって来る側（宛先）との関係は存在する。つまり電話をするという発意を誰がしたのかによって、決定付けられる関係である。すなわちここで云う発信元とは、通信の発意者の用いる通信ノードを指す。
なお、前記のような関係の逆転は回線交換では有り得ず、蓄積交換であってこそありうる──本発明では意図的にこうしている。
回線交換の場合と異なり、網が発信者番号通知を保証しない以上、第一通信ノードはマッピング公示システムが公示する写像との比較によって、発信元が単に名乗った静的な識別子について自力で保証しなければならない。
【００６４】
しかし以下の問題があった。
宛先側の動作であって、サイン信号を受けて（カウンターサイン信号を返信する前に、発信元の静的な識別子を知る目的で以って）サイン信号を送信する場合は、ちょっとした矛盾である。
本来なら、
要求には応答が返される。
サイン信号にはカウンターサイン信号が返される。
このように動作するべきである。
しかし、前記場合にはサイン信号に対してサイン信号が返されている。
この場合は、要求に対して要求が返されているということが出来る。この意味で、発信元にとっては矛盾である（ヒトのする日常生活でも、質問に対して質問が返された場合には、困ることが多い）。
【００６５】
実際問題として、第一通信ノードと第二通信ノードが同一の構成の場合には、図２８のように、ピンポン現象が発生する。
亦は、各通信ノードが置かれている網が到達性確認出来るという外部環境にある場合にも、双方共にタイムアウトするまで待ち状態になって、結局は到達性確認に失敗することがある等で不都合がある。これらの問題を総称して、以下デッドロックとする。
【００６６】
これを解決するためには、図２９のように動作すればよい。以下では、宛先としての役割を示す記号をＴとし、発信元としての役割を示す記号をＳとする。
そのためにはサイン信号に対して、カウンターサイン信号ではなくサイン信号が応答された場合に、更にサイン信号を応答しないようにする。
【００６７】
そこで、第一の解決手段では「要求に対して要求が返された場合」を検知することによって、デッドロックを回避する。したがって重要なのは、いかにして「要求に対して要求が返された場合」と「普通に要求された場合」とを峻別するかである。
発信元はサイン信号の送信時にサイン信号を送信した宛先住所をリストし、サイン信号を受信したときに発信元の住所がリストされていることによって、サイン信号に対するサイン信号であることを検知する。これを実施例２に示す。
第二の解決手段は、サイン信号に発信元の静的な識別子を含めるようにすることである。これを実施例４に示す。
【００６８】
（発信元識別の効果）
１、宛先たる通信ノードが発信元たる通信ノードをその静的な識別子において識別することが出来る。
通信のシーケンス上の最初の宛先であるところの通信ノードが、
発信元であるところの通信ノードの、
静的な識別子による到達性の正しさを知ることが出来るようにした。
【００６９】
２、これによって、発信元としての役割も果たし、かつ宛先としての役割も果たす一台の通信ノードを実現する。
無線機を例に挙げれば、送信機と受信機を別々に用意するのではなく、送受信機になっている場合の方が、利便性が高い。
【００７０】
実施例２は、基本的な解決方法である。
本発明では、発信元通信ノードと宛先通信ノードは、その役割によって独立しておらず、単一の通信ノードにおいてその両方の役割をこなすものとして発明した。よって第一通信ノードと第二通信ノードとは、同一の構成となる。
その結果、例えば記憶装置について、第一通信ノードに備える１１０と第二通信ノードに備える２１０は代用可能である。本発明の記載では、番号の若い方で説明する。同様に、作業領域１１９と２１９も同じである。第一通信ノードにおける設定部１２０と第ニ通信ノードにおける設定部２２０も同じである。通信Ｉ／Ｆも同じとする。
【００７１】
図３０に、本発明を実施するための通信ノードの模式的な構成を示すブロック図を示す。
先に示したブロック図に対する変更箇所を、以下示す。
受信部１３０は、サイン信号受信部１３１と、「答えるべき返事」読出部１３５と、カウンターサイン信号送出部１３８とを備える。ここでは、附加情報は扱わないので、附加情報処理部１３６、カウンターサイン信号生成部１３７は不要である。替りに発信元識別部１３２と、マッチング処理部１３３とを備える。
発信元識別部１３２は、サイン信号を受信した際に、発信元の静的な識別子を知るために、自ノード内に備えられた発信部２３０に接続するものである。その結果知ることが出来た発信元の制的な識別子Ｂを、亦は発信部２３０の中で呼ばれる判定部２３６のした判定の結果を、後続する処理での参照の為に、識別発信元記憶部１１４に記憶するものである。
マッチング処理部１３３は、サイン信号を受信した際に、そのサイン信号が発信元識別のためのサイン信号なのか通常のサイン信号なのかを、すなわち親セションなのか子セションなのかを検知するためにマッチングするものである。
発信部２３０は、住所取得部２３１と、サイン信号送信部２３２と、カウンターサイン信号受信部２３５と、判定部２３６と、表示部２３８と、タイマ２３９とを備える。附加情報処理部２３７については、本発明では附加情報は扱わない為に不要である。替りにサインリスト処理部２３３とを備える。
サインリスト処理部２３３は、サイン信号を送信した際に、サインリスト２１３に、サイン信号送信中の宛先住所を記憶するものである。
【００７２】
発信部２３０において
図３１は、発信部２３０の動作（最初のサイン信号の送信からカウンターサイン信号の受信まで）を示すフローチャートである。
Ｓ１２０２は、サイン信号送信部２３２がするもので、図２９のシーケンス(1)に相当する。なおＳ１２０２に先立って、第二通信ノードがする場合は、住所取得部２３１はマッピング公示システム３０に問合せ、第一通信ノードの住所を得ている。亦は第一通信ノードがする場合は、最初に受信したサインのヘッダに含まれる発信元住所から、第二通信ノードの住所を知っている。
Ｓ１２０６は、カウンターサイン信号受信部２３５がするもので、図２９のシーケンス(4)に相当する。
よってＳ１２０２とＳ１２０６で以って、特許文献１図２３Ｓ２０６でしたサイン信号から、同Ｓ２０８で受信したカウンターサイン信号までの、一連のサイン・アンド・カウンターサインの過程である。
このことから、Ｓ１２０４のステップが本発明によって追加されていることがわかる。Ｓ１２０２で、発信部２３０はサイン信号を送信する際に、Ｓ１２０４においてサインリスト処理部２３３がサイン信号を送信した宛先であるところの宛先の住所をサインリスト２１３にリストする。なお、Ｓ１２０２とＳ１２０４の順序はいずれが先であってもよい。
ここまでを最初の段階とする。
通信相手がサイン信号を返してきた場合は、後述する図３２を参照されたい。これが中間段階であるが、図３２は受信部１３０の動作を示すものなので、図３１では図示しない。したがって、Ｓ１２０４で「サイン信号を送信した宛先の住所をリストする」のは、図３２においてサイン信号を受取ったときに、サイン信号の送信元が既にサイン信号を送信中の通信相手からのものであるかどうかを判断するためのものである。
通信相手がサイン信号を返してこなかった場合（すなわちカウンターサイン信号が返信された通常の場合）は、Ｓ１２０６に進む。
なお図示しなかったが、カウンターサイン信号も返ってこなかった場合は、到達性を確認できなかった場合である（特許文献１）。
【００７３】
Ｓ１２０６は、カウンターサイン信号受信部２３５がカウンターサイン信号を受信したことを示す。ここからが最後の段階である。
Ｓ１２０８およびＳ１２１０は、サインリスト処理部２３３がするもので、Ｓ１２０６で受信したカウンターサイン信号送信元の住所がサインリスト２１３の中にリストされているかを判断する。リストされていればＳ１２１０に進む。リストされていなければＳ１２１０をスキップする。
Ｓ１２１０では、サインリスト２１３から該住所を削除する。一連のサイン・アンド・カウンターサインの過程が終了したのだから、もはやサイン信号を送信した宛先の住所を記憶しておく必要がないからである。
なおサインリスト２１３中の１レコードあたりのフォーマットは、住所のみでよい。しかしサイン信号した時刻（亦はサイン信号に対するカウンターサイン信号を受取るまでのタイムアウト時刻）等を含めてもよい。
【００７４】
受信部１３０において
課題に対する第一の解決手段は、サイン信号送信中の通信相手から受信した更なるサイン信号には、直ちに単に「答えるべき返事」のみをキャリーするカウンターサイン信号を返信するように、構成することである。
図３２は、受信部１３０の（サイン信号を受信したときの）動作を示すフローチャートである。
図３２は、図３１で省略した中間段階である。すなわち図３１も図３２も、ともに同一構成の通信ノードでの動作を示す。
図３２で「開始」は、サイン信号の受信をトリガとして開始されることを示す。
したがって、「開始」は図２９のシーケンス(1)亦は図２９のシーケンス(2)の受信する側（すなわちサイン信号を受信する側であるところの宛先）に相当する。
Ｓ１４０２は、受信したサイン信号が、親セションに相当するのか子セションに相当するのかを判断するステップである。マッチング処理部１３３が「サインリスト２１３の中にサイン信号の送信元の住所があったか」を判定する。ここで住所がリストされている場合とは、既にサイン信号を送信している宛先となる（図３１Ｓ１２０４）。そしてＹＥＳの場合にはＳ１４０６に、ＮＯの場合にはＳ１４０４に進む。つまりリストされていない住所を発信元とするサイン信号は、通常のサイン信号（親セションに相当）である。との判断をする。
Ｓ１４０４は、子セションの開始をするステップである。発信元識別部が１３２が「発信部２３０を呼出す」（いわばサブルーチンに相当すると考えればよい）。ここで呼出す発信部２３０は、特許文献１に示した通りの動作をする。すなわちこの場合は（図３３中に破線で示したように）リストせずに、サイン信号を送信する。
亦、Ｓ１４０４の中で実施されるサイン信号の送信（すなわち子セションのＳ１２０２）の際には、タイマ２３９によってタイムアウト時間を短く変更してやるとよい。単純計算で親セションは子セションの２倍の通信時間が必要だからである。
Ｓ１４０６は、子セションの中でカウンターサインを送信するステップである。カウンターサイン送出部１３８が「答えるべき返事をキャリーするカウンターサイン信号を返信」する。ポイントは、「サイン信号を返ない」ということである。なお、Ｓ１４０６でサイン信号を返信するとデッドロックが発生する。
なお、図３１Ｓ１２１０でした「サインリスト２１３から該住所を削除」するステップは、Ｓ１４０６の後でしてもよい。該ステップは、リストに不要な情報がどんどん積み上がっていかないようにするためのものであり、本質ではない矛盾の整理である。
【００７５】
図３３に、ここまでにしたフローチャートの説明を、シーケンスに当てはめたものを示す。
最も重要な点について説明する。
第ニ通信ノードの発信部２３０の内、Ｓ１２０４でサインリスト処理部２３３がサインを送信した宛先住所を、サインリスト２１３にリストしている。このサインリスト２１３は、受信部１３０のＳ１４０２で引継がれる。このことによって、「要求に対して要求が返された場合」と「普通に要求された場合」とを峻別するものである。その結果、第ニ通信ノードにあっては、Ｓ１４０６で子セションのカウンターサイン信号を送信する。このように、子セションのサイン信号に対して更にサイン信号を送信することはない。
第二に重要な点は、サインリスト２１３は第ニ通信ノードと第一通信ノードで独立しているという点である。発信部２３０及び受信部１３０はサインリスト２１３を共有するが、単一の通信ノード内での参照のためである。例として、第一通信ノードでは、サイン信号を受けた際に、サイン信号を送信していないのだから当然にリストされていない。第一通信ノードのサインリスト処理部１３９でするＳ１４０２は分岐して、Ｓ１４０４「発信部２３０を呼出す」に接続をする（すなわちＳ１４０６ではない）。
【００７６】
（発信元に対する到達性確認）
ところで、発信元の静的な識別子を知るだけでは足らず発信元の正しさを知ることが必要な場合には、この後Ｓ１４０４は更に住所取得部２３１を呼出し、マッピング公示システムに問合せた後、判定部２３６で到達性の正しさを判定すればよい。第一通信ノードではＳ１２０６の後（図示しない）で、カウンターサイン信号によってキャリーされた答えるべき返事が静的な識別子Ｂそのものであれば、この後マッピング公示システムから写像を得ることが出来る。これによって到達性の正しさを知るために必要な４つの要素がそろうので、発信元に対する到達性の正しさを知ることが出来る。亦この際、第一通信ノードの属する宛先発見過程を提供するマッピング公示システムでないマッピング公示システムに対して問い合わせてもよい。静的な識別子Ｂそのものでない場合は、答えるべき返事から静的な識別子に対して可逆的であることが要求される。発信元の正しさを知る必要がなく、単に発信元の静的な識別子を知るだけで足る場合にはマッピング公示システムの参照は不要である。第ニ通信ノードでは、特許文献１の記載から、第一通信ノードへのサイン信号の送信前にマッピング公示システムへの問合せは済んでいる。
なお図３３はシーケンスに従った典型的な通信ノードの動作の例を示したものであって、装置としては第ニ通信ノードも第一通信ノードも同一の装置でよい。
【００７７】
サインリスト２１３のメンテナンス。
図３４は、発信部２３０の動作（カウンターサイン信号が返ってこなかった場合）を示すフローチャートである。
発信部２３０のカウンターサイン信号受信部２３５がカウンターサイン信号を受取らなかった場合（代表例が到達性確認で偽と判断される場合）であっても、サインリスト２１３はメンテナンスされるべきである。メンテナンスは、リストの不必要な肥大を抑えたり、同一の宛先住所が複数リストされるケースを避けたりするためにする。メンテナンスの内容は、タイムアウト時間を超えて、カウンターサイン信号が返ってこなかったサイン信号の宛先住所をサインリスト２１３から削除する（Ｓ１６０２）。これをタイマーによって、一定時間毎に繰返す（Ｓ１６０４）。
なお、タイムアウト時間を超えた時点で、到達性確認の結果は偽であるとの判断がされている。そのため到達性確認の結果の判断がされた後（すなわちタイムアウト後）では、サイン信号送信中の宛先住所を記憶しておく必要はない。
レコードフォーマットは「住所：時刻」となる。
この場合も単なるリストの整理なので、発明の本質ではない。
【００７８】
実施例２は、受信部１３０と発信部２３０とが同一の通信ノード内に共存している場合（つまり一のホストが宛先であり発信元でもある場合）であった。
実施例３は、第ニ通信ノードがＮＡＴ内にある場合等の実施例２適用例である。宛先と発信元とが外部からは一つの通信ノードに見えるが、実際には二つの装置に分割されている場合である。
ここでは、特許文献１実施例８を参照されたい。宛先の属するカスタマ網が示されている。同一のカスタマ網に対して、更に発信元を加えてみる。すなわち宛先と発信元とが独立したホストでありながら、外部網からは個々のホストを識別することができない場合である。この場合にはホスト間で連携しなければならない。
【００７９】
特許文献１実施例８図３７接続形態６に示したように、カスタマ網内において機能を司るホストが独立している場合には、注意が必要である。
１、まず発信部２３０がサイン信号を送信する。
２、図示しない相手方の宛先（第一通信ノード）は、発信元を知るために、更にサイン信号を発信元宛に送信する（図２９のシーケンス(2)）。このとき、カスタマ網と外部網の境界ノードは、フォワーディングまたは何らかの技術により、該サイン信号を宛先に転送する。すなわち該サイン信号の受信は宛先がするのであって、発信元がするのではない。すなわち、この点において連携をしなければならない。
これを図３５に示す。
図３５は、特許文献１図３７に対応する図である。図３５は、第ニ通信ノードに相当する。
特許文献１図３７により近い図を図３６として示す。すなわち図３６では、特許文献１に示した宛先側のカスタマ網が単に宛先側であるだけでなく、発信元側としても動作する場合の発信部２３０を追加したことを示す図である。
この場合宛先たるホストと発信元たるホストは、（装置として独立していたとしても）サインリスト２１３を共有ファイルとして持ち得る場合は、実施例２と同様に考えてよい。
そうでない場合には、
(1)の後、発信元たるホストは宛先たるホストに対して、サイン信号を送信した宛先住所をリストに加えるよう要求する。
発信部２３０がサイン信号を送信した宛先住所を宛先に通知するようにすればよい。宛先ではこれを受け、発信部２３０から送信された住所をリストに加える。以後は実施例２と同じでよい。
【００８０】
実施例４は、サイン信号に発信元の静的な識別子を含める場合である。
第二の解決手段は、サイン信号に発信元の静的な識別子を含めるようにすることである。
特許文献１には、サイン信号に宛先を示す静的な識別子は極力含めないようにすることを提案した。
これは偽装の原因になるからである。しかし、サイン信号に宛先を示す静的な識別子を含めることを１００％排除することはできない。そこで、偽装があり得るケースを検討し、その影響を考慮して、偽装を許容したものである。
しかしサイン信号の中に、発信元を示す静的な識別子は含められていてもよい。特許文献１では、サイン信号について「単にカウンターサイン信号をうながす」信号としていた。
ここでは、サイン信号に発信元を示す静的な識別子を含めることを提案する。
【００８１】
こうすることによって得られる最大のメリットは、親セションのみで足り、子セションが不要になることである。
【００８２】
この場合サイン信号に含まれる発信元を示す静的な識別子は単に自己申告となるために、宛先ではサイン信号に含まれていた発信元の静的な識別子が正しいかどうかをこれだけでは、確認することができないことである。
【００８３】
ところで、サイン信号に発信元を示す静的な識別子が含まれていた場合には、実質的にカウンターサイン信号と同じである。
したがって、実施例４の場合には、サイン信号を受取った後、マッピング公示システムへの問合せをすれば、特許文献１に示した４つの要素がそろうことになる。
以下のシーケンスとなる。
１、サイン信号に発信元を示す静的な識別子が含まれている。
発信元の住所についてはサイン信号を受信した際のヘッダから自明である。これによって、静的な識別子と動的な住所からなる組の実像を知ることが出来る。
２、マッピング公示システムへは前記サイン信号に含まれていた静的な識別子で問合せる。
３、マッピング公示システムからの返事は、前記静的な識別子に対するその時点での住所であるはずである。シーケンス２および３から、静的な識別子と動的な住所からなる組の写像を知ることが出来る。
前記３つの過程によって、発信元通信ノードに関する静的な識別子と動的な住所からなる組の実像と写像（特許文献１）を構成する４つの要素のすべてを、宛先は知ることが出来る。
結果、３で宛先が知ることのできた発信元の住所と１で知ることのできた発信元の住所が一致すれば、発信元を示す静的な識別子に対して、正しい到達性を有していることがわかる。
【００８４】
サイン信号に含まれた発信元が正しくなくてもよい場合等には、マッピング公示システムへの問合せを省略して、カウンターサイン信号を返すようにしてもい。
ところで、リストのメンテナンスの話をしておこう。サイン信号に発信元を示す静的な識別子が含まれている場合には、そもそもリストは必要ない。
【００８５】
図３７は発信元を示す静的な識別子をサイン信号に含むことによって発信元を識別す場合の第一通信ノードのブロック図である。
受信部１３０は、サイン信号受信部１３１と、発信元識別部１３２と、「答えるべき返事」読出部１３５と、カウンターサイン信号送出部１３８とを備える。
発信元識別部１３２は、サイン信号を受信した際に、サイン信号によってキャリーされた発信元の静的な識別子抽出するために、亦は発信元の正しさを知るために自ノード内に備えられた発信部に接続するものである。亦、発信部２３０の中で呼ばれる判定部２３６のした判定の結果を、後続する処理での参照の為に、識別発信元記憶部１１４に記憶するものである。
【００８６】
発信部２３０は、住所取得部２３１と、サイン信号送信部２３２と、カウンターサイン信号受信部２３５と、判定部２３６と、表示部２３８とを備える。
なお、第一通信ノードとしてのみ動作させる場合には、発信部２３０は、住所取得部２３１と、判定部２３６と、表示部２３８のみを備えればよい。（図３７では、こちらの場合を示す）
更に、第一通信ノードであって、発信元通信ノードの正しさをも知る必要がない場合には、発信部２３０は不要である。
サイン信号送信部２３２は、通常のサイン信号ではなく、サイン信号送信に先立って、自ノードを示す静的な識別子記憶部２１１から自ノードを示す静的な識別子を読出し、これを含むサイン信号を生成する前処理を含むものである。
その他の部分については、既に説明が重複しているので割愛する。
【００８７】
これをフローチャートで表したものを図３８に示す。
図３８は、第一通信ノードである。基本は宛先である。図３８は、サイン信号を受信したところから始まる。
Ｓ１８０２は、サイン信号には発信元を示す静的な識別子が含まれているかを、判断して分岐する。サイン信号受信部１３１が一旦サイン信号を受信した後、受信したサインを作業領域１１９に転送し、発信元識別部１３２が発信元の静的な識別子が含まれているかどうかを判断すればよい。
ところでサイン信号に発信元を示す静的な識別子が含まれている場合とは、突然にカウンターサイン信号を送りつけることと同じなのだ。
（カウンターサイン信号で用いる）答えるべき返事と（サイン信号に含める）静的な識別子は別のものでよく、かつ発信元から宛先に送信するサイン信号に含めるのは静的な識別子でよい。
【００８８】
特許文献１に示した理論によれば、
したがって、「答えるべき返事」と前記１に示したシーケンスでする発信元の静的な識別子は同じでなくてよい。仮にサイン信号に含まれる発信元を示す値が、発信元を示す静的な識別子でない「答えるべき返事」であった場合には、該答えるべき返事は静的な識別子に対して可逆的でなければ、宛先はマッピング公示システムへの問合せをする際に用いる発信元を示す静的な識別子を知ることができない。また静的な識別子はそもそも秘密ではない。よって「答えるべき返事」が置換亦は変形されている場合であっても、前記１に示したシーケンスでするサイン信号には、単に発信元の静的な識別子を含めればよい。
Ｓ１８０４は、前記受信したサイン信号から発信元を示す静的な識別子を発信元識別部１３２が抽出し、該静的な識別子で以って住所取得部２３１がマッピング公示システムに問合せをする。
Ｓ１８０６は、住所取得部２３１が返事を受信する部分である。なおここでは「返事があったか」を判断しているが、ここで返事がない場合とは、マッピング公示システムそのものに障害が発生している場合であるので、本来は無視してよい。事実特許文献１では、ここで「返事があったか」は問うていない（特許文献１図２３Ｓ２０４参照）。
Ｓ１８０８は、住所取得部２３１がＳ１８０６で受取った返事から発信元の住所を抽出している。
Ｓ１８１０は、判定部２３６が「前記得た住所とサインの送信元住所が一致したか」を判定する。これについては、別の表現をしてみる。ここでは、以下について一致しているかいないかについて判断している。マッピング公示システムにおける静的な識別子と動的な住所からなる組の写像と、発信元における静的な識別子と動的な住所からなる組の実像について、その一致を判断している。
もちろん一致すれば到達性確認の結果は真である。すなわち「発信元を知ることができた」場合である。この場合は、Ｓ１８１２で後の参照のために、識別した発信元の静的な識別子を識別発信元記憶部１１４に記憶し、Ｓ１８１４に進む。
一致しなければ偽である。すなわち「発信元を知ることができなかった」場合である。この場合は、Ｓ１８１６に進む。Ｓ１８１６とは、実は発信元を知ることができなかった場合なので、通常の場合である。ここでＳ１８１４が真、Ｓ１８１６が偽とし、真偽の判定をする元となる概念は到達性確認であるとした。しかしここでは到達性確認の概念は逆転していることによって、実は発信元に対する静的な識別子による到達性であることを忘れてはならない。
よってＳ１８１４は、発信元を知ることができた場合、Ｓ１８１６は発信元を知ることができなかった場合である。
このことによって後続するアクションについては、発信元識別に基づく選択的応答をすることが可能になる。最も一般的な後続するアクションの例は、単なる結果の表示の場合である。しかしこの場合は第一通信ノードの場合であるので、カウンターサイン信号の返信が一般的な後続するアクションである。
一例として、発信元が識別できた場合（Ｓ１８１４）にのみカウンターサイン信号を返し、発信元が識別できなかった場合（Ｓ１８１６）にはカウンターサイン信号を返さない等の選択的応答が可能となる。更にＳ１８１４の場合には、発信元が識別できているのだから、より細かく発信元毎に異なる応答をすることも可能となる。
後続するアクションの例については詳しく後述する。ここでは、Ｓ１８１４の場合とＳ１８１６の場合で、異なるアクションを取り得ることが重要であるとしておく。
【００８９】
実施例５は、発信元識別をより確実にするための融合型である。
最後に、発信元を示す静的な識別子を含めたサイン信号であっても、発信元を示す静的な識別子を含めないサイン信号であっても、発信元を示す静的な識別子を知ることが出来る第一通信ノードについて示す（もちろん第ニ通信ノードも対称である）。
これは、最も単純に説明すれば、実施例４で発信元を示す静的な識別子を含めないサイン信号を受信した場合には、実施例２を実施するという融合型である。
これを図１５に示す。
図中の発信元（Ｓ１２０２乃至Ｓ１２１２）については、実施例２に挙げた過程（図では単純化してある）を引用している。Ｓ１８０２でサイン信号に発信元を示す静的な識別子が含まれていなかった場合に実施するようにするとよい。しかし任意である。すなわち図の左側の部分が宛先の部分であり、実施例２に挙げた部分を省略することも可能であることを示す。これは子セションは省略可能であることを示す。なお図ではＳ１８０６亦はＳ１８１０の判断でＮＯの場合はＳ１８１６「発信元を知ることができなかった場合」に分岐しているが、図中の発信部２３０に接続して子セションのサイン信号を送信してもよい。
発信元付のサイン信号ならあえて発信元（第ニ通信ノード）にサイン信号を送信する必要はない。しかし発信元がサイン信号に発信元を示す静的な識別子を含めることができない場合を想定するならば、図右側の発信部２３０を実施してあえて子セションを用いて発信元を示す静的な識別子を知ろうとしてもよい。
【００９０】
（新しい理論）
図４０に、通信のシーケンスを特許文献１と比較したものを示す。通信のシーケンスによって、静的な識別子（＝Ｂ）と動的な住所（＝Ａ）からなる組の実像と写像のうちのいずれの要素を知ることが出来るかについて示した。静的な識別子と動的な住所からなる組の実像と写像を知ることができれば、正しい到達性を有する通信相手であることがわかるとする理論については特許文献１を参照されたい。
図４０で、丸印で囲まれた通信ノードが、到達性を確認する通信ノードである。上段（イ）は特許文献１の技術を示す。特許文献１は発信元が宛先の到達性を判断する。下段（ロ）は本発明を示す。本発明では宛先が発信元の到達性を判断する。（余談だが、この場合は到達性の正しさというのは、いささか違和感がある。本来ならば発信元を示す静的な識別子の正しさとでもするべきなのだろうが、特許文献１との整合のためにここでは到達性のままとする）
なお特許文献１から、マッピング公示システムと通信して得られる要素が写像に該当し、マッピング公示システムでない通信ノードと通信して得られる要素が到達性確認したい相手方の実像である。
マッピング公示システムとの通信におけるＢ、Ａの順は、（イ）（ロ）の場合を問わずにこのようになる。これは特許文献１の「静的な識別子と動的な住所の関連付けにおける一方向性」に示したことを理由にこの順番になる。特許文献１実施例８の「機能が複合した場合」に挙げた例外を除くものとする。
結局、（ロ）の場合であっても静的な識別子と動的な住所からなる組の実像と写像を知ることが出来る。よって、到達性（この場合は発信元に対する）の正しさは確認することが出来る。
よって図４０（ロ）は、特許文献１で示した通信モデル（イ）を変形したものである。
【００９１】
（ループバック）
以上から、更に新たな通信モデルが生まれる。
特許文献１では宛先に対する到達性の正しさを確認するための通信モデルを示した。
本発明では、発信元に対する到達性の正しさを確認するための通信モデルを示した。
その理論は、静的な識別子と動的な住所からなる組の実像と写像という４つの要素の対応関係の正しさによって確認することができたものである。
ここで再度図４０を参照されたい。
自ノードは、静的な識別子と動的な住所からなる組の実像については当然に知ることが出来る。
そうであるならば、自ノードは自身の到達性の正しさについて、単にマッピング公示システムから静的な識別子と動的な住所からなる組の写像を得さえすれば、必要な４つの要素がそろうことになる。
結果、自ノードの到達性を確認することが出来る。
これを以って、到達性確認する通信ノードのループバック試験手段とする。
図４１にこれを説明する。
図４１（イ）は、発信元通信ノードでするループバック試験である。
図４１（ロ）は、宛先通信ノードでするループバック試験である。いずれであってもループバック試験は実施出来る。
四角で囲まれたＡ、Ｂは、外部との通信なしで知ることが出来る要素である。すなわち、宛先や発信元は、マッピング公示システムに対して自分自身について問合せ（普通は自分自身を問合せることはない）をするだけで前記４つの要素がそろう。ただし、もちろん実像と写像の一致を判定した後に、自己たる通信ノードの到達性の有無が判明するものである。
【００９２】
図４２は、通信ノードがループバックで到達性を試験するための必要最小限の構成を示したブロック図である。
通信ノードは、記憶装置２１０と、発信部２３０と、通信I/F２９０のみを備えればよい。
発信部２３０は、住所取得部２３１と、判定部２３６と、表示部２３８とを備える。
第一通信ノードであっても、受信部１３０はあってよいが、ループバック試験の為に必須ではない。
【００９３】
記憶装置２１０には、自ノードを示す静的な識別子記憶部２１１のみで足る。
自ノードの住所については、自明であるものとみなす。外部から参照される網境界の住所についても、本願出願時点で未公開の本出願人による特願2004-197478の記載から、やはり自明であるものとみなす。
これによって、静的な識別子と動的な住所からなる組の実像については、既知である。
よって、フローチャートは省略するが、住所取得部２３１がマッピング公示システムから、自ノードの静的な識別子に対応する住所を得れば、比較する４つの要素がそろうので、判定部２３６は到達性の真偽を判定出来る。
よって、ループバックで到達性を試験するためためには、サイン・アンド・カウンターサインは必要ない。（やってもよいが自ノードの記憶域から値を読み出すのと同等である）
【００９４】
実施例７。
以下では、第一通信ノードが第二通信ノードに対して、発信元識別に基づいて選択的に応答する手段を示す。
図４３に、選択的応答の概念図を示す。ここまでの説明で既に発信元識別に基づき、第一通信ノードは第二通信ノードを識別できている。これを利用して、マッチング（Ｓ２００２）をすればよい。マッチした時は、選択的応答をする（Ｓ２００４）。マッチしなかった時は、通常の応答をする（Ｓ２００６）。
【００９５】
図４４に、第一通信ノードの模式的な構成を示すブロック図を示す。図４４には、例えばコンソール等のユーザＩ／Ｆを提供する設定部１２０と、被到達性確認する際の制御をする受信部１３０と、諸々の情報を記憶する記憶装置１１０と、網４０に接続するための物理的な通信Ｉ／Ｆ１９０とを示している。
ここで新たに登場するのは、記憶装置１１０に記憶される登録済発信元情報１１５である。
登録済発信元情報１１５は、第一通信ノードの利用者によって事前に登録された通信相手を示す情報である。この情報は通常は複数の通信相手が登録される性質のもので、リストであってもＤＢであってもよい。フォーマットは、通信相手を示す静的な識別子でありさえすればよい。
その他の構成要素については、既に説明したので割愛する。
図４４には、記憶部２１０及び発信部２３０をも示してある。これらは、既に説明した発信元識別に際して利用するものである。構成要素については、発信元を識別する手段によるので、それに従う。なお選択的応答をする際には、発信部を直接利用することはない。
【００９６】
図４５に、本発明を実施するためのフローチャートを示す。
開始は、既に説明した発信元識別の終了から始まる。
Ｓ２２０２では、発信元識別部１３２がした発信元識別が成功して終了したか否かを判断している。  真の場合はＳ２２０４で、マッチング処理部１３３によって、前記発信元識別の結果判明した第二通信ノードを示す静的な識別子と、登録済発信元情報１１５に事前に登録された通信相手とのマッチングを取る。
この結果が真であれば、Ｓ２２０６で通常とは異なる応答をすることが出来る。具体的にはカウンターサインを意図的に応答しないことが出来る。
Ｓ２２０２亦はＳ２２０４のいずれかのステップで偽となった場合は、Ｓ２２０８で通常の応答をする。具体的には普通にカウンターサイン信号を送信する。
このように、発信元が識別できれば、事前に登録した相手であるかないかを判断して、特別な応答をすることが出来る。
【００９７】
実施例８。
以下では、第一通信ノードが第二通信ノードに対して、発信元識別に基づいて選択的に状態情報を検知させる手段を示す。
実施例７では、選択的応答の内容は、カウンターサイン信号を単に送信するかしないかであった。実施例８では、これに附加情報に係るステップを加えることによって、第二通信ノードが既に登録された通信相手であるかないかによって、第二通信ノードをして通常と異なる状態情報を検知させるものである。
【００９８】
図４６に、本発明を実施するための通信ノードの模式的な構成を示すブロック図を示す。
図４４に対して、附加情報に係る部分が追加されている。附加情報に係る部分に関しては既にした説明を参照されたい。
【００９９】
図４７に、本発明を実施するためのフローチャートを示す。実施例７に対して、附加情報に係る部分が追加されている。附加情報については既に説明したので、注意点のみ示す。
Ｓ２２０４で、識別された第二通信ノードの静的な識別子が登録済発信元情報１１５に登録されていた場合に、カウンターサイン信号を送信する前に、附加情報に係る処理を実施すればよい。ここでＳ１００とは、既に説明した附加情報に係る説明を全て含んでいるものである。
【０１００】
実施例９。
実施例７及び実施例８にて、如何にして選択的に応答をするかについて説明してきた。ところで、発信元識別してわざわざ選択的に応答しているにも係らず、その内容は単に明示の拒否である。しかしこれでは未知の応答をしたくない相手に対しては、普通に応答してしまう。このことから、知り合いに対してのみ応答する技術が待たれるところである。これを以下、実現する。
【０１０１】
図４８に、第一通信ノードの模式的な構成を示すブロック図を示す。図４８には、例えばコンソール等のユーザＩ／Ｆを提供する設定部１２０と、被到達性確認する際の制御をする受信部１３０と、諸々の情報を記憶する記憶装置１１０と、網４０に接続するための物理的な通信Ｉ／Ｆ１９０とを示している。
ここで新たに登場するのは、記憶装置１１０に記憶される標準動作反転フラグ１１６と、設定部１３０に含まれる回路反転部１３９である。
回路反転部１３９は、標準動作反転フラグ１１６のフラグがＯＮであるか、ＯＦＦであるかを見て、ＯＮであれば、標準動作を反転させるものである。
その他の構成要素については、既に説明したので割愛する。
【０１０２】
このときの動作を図４９に、フローチャートで示す。
Ｓ２４０２は、標準動作反転フラグ１１６を参照してフラグがＯＮであれば、回路反転部１３９によって、回路を反転させる。これによって、Ｓ２２０４で発信元を示す静的な識別子が登録済発信元情報１１５に既に登録されていた場合に（すなわち知り合いに対して）のみ、カウンターサイン信号を送信することが出来る。
なお単に、Ｓ２２０２の成功、Ｓ２２０４でマッチの時に、固定的に標準動作を反転させることも出来る。ただしこの際には、第一通信ノードの利用者の自由度は少なくなることに注意されたい。また、標準動作反転フラグ１１６のＯＮ亦はＯＦＦは、第一通信ノードの利用者が通信に先立って設定するものである。この際の設定手段については、単にフラグをＯＮにするかどうかなので、省略する。亦画面例も、省略する。
【０１０３】
実施例１０。
実施例９において、附加情報をも取り扱うことが出来る。
この際のブロック図を図５０に、フローチャートを図５１に示す。
これによって実現されることは、知り合いに対してのみ、状態情報を知らせることが出来るようになる。
【０１０４】
実施例１１。
ここまではブローカを利用した手段でも実現されていることである。さて、本発明はエッジノード間ですることに特徴を有するものである。ブローカを経由しないからこそ、実現出来ると言うことを以下に示す。
それは、単に選択的に応答するのみでなく、発信元毎に異なる応答をすることである。
ちなみにこれをブローカモデルでやろうとすると、端末の組合せ数がべき乗となるので、ブローカがこれらの組を紐付けして管理することは現実的ではない。更にその組合せに応じて、異なる内容というのは、将来においても難しいのではないかと思う。やって出来なくはないのかも知れないが、発明者はそんなことはしたくない。
本発明では、管理が分散すること、そしてその結果負荷の集中がなくなることという利点がある。また、利用者は自分で管理することにより、あらゆる仕組みを作り込むことが出来る。ブローカが事前に用意したサービスのみを利用するだけでなく、必要なものを利用者は自分で作り込むことが出来る。本発明はそのための基盤を提供する。
【０１０５】
図５２にフローチャートを示す。
Ｓ２６０２で、登録済発信元情報１１５の中に、単に発信元を示す静的な識別子のみでなく、アクションの記述があるかないかを判断している。ここでアクションと呼んでいるのは、実は単なる附加情報である。
発信元毎の附加情報があれば、その附加情報に書かれている通りのアクションを取ればよい。それがメッセージであれば単に読み出した後に、カウンターサインを生成すればよい。それがプログラム呼び出しであれば、その返り値に基づいてカウンターサインを生成すればよい（Ｓ２２１０）。なお、ブロック図は図５０と同じものでよい。
【０１０６】
既に説明した通り、本発明における附加情報はブローカモデルより柔軟である。例えば、固定的なメッセージのみを扱うのではなく、第一通信ノードに取り付けられたセンサ出力であってもよい。亦、附加情報は複数キャリーすることが出来ることを既に開示した。
図５３を参照されたい。これは登録済発信元情報１１５のレコードフォーマットの例である。既にした説明では、登録済発信元情報１１５のレコードフォーマットは、発信元を示す静的な識別子のみでよいとした。しかし、図５３（イ）のように、アクションを記述することが出来る。既に附加情報の項で説明したように、附加情報は第一通信ノード内の情報としては、メッセージであってもプログラム呼び出しであっても、同様に扱うことが出来る。すなわち附加情報設定ポインタのことである。これを登録済発信元情報１１５の通信相手の一つづつに異なるポインタを設定した場合には、通信相手毎に異なるアクションを取っていることを意味する。
【０１０７】
図５３（ロ）で示した、「差替か追加か」を示すフラグをアクションの中に追加することも出来る。図５４を参照されたい。図５４は、附加情報をもキャリーする電文フォーマットの例である（図０７も参照されたい）。
図５３（ロ）「追加」の場合が、図５４（イ）の例である。
図５３（ロ）「差替」の場合が、図５４（ロ）の例である。
すなわち図５４（イ）の場合は、マッチした発信元に対するアクションをした後（これは発信元毎の附加情報としてカウンターサイン信号の生成の際に組み込まれる）、更に通常の附加情報をも読出し、そしてカウンターサイン信号の生成の際に組み込まれてもよい（どちらを先にやるかは問わない）。
附加情報のＳ６０８の説明でした「０７（ロ）のように附加情報が複数含まれている場合には、附加情報の個数を限度として必要な回数だけ図１１に示した変換作業を繰返してもよい」は、第二通信ノードで表示する際の処理だが、第一通信ノードでカウンターサイン生成時点でも同じようにすることが出来る。ここでは、発信元毎の附加情報＋標準の附加情報の２回をやることを示している。
以上によって、発信元毎に異なる応答をすることが出来る。
【０１０８】
（第二通信ノードの結果表示画面例）
図５２Ｓ２２０８によって、第二通信ノードが第一通信ノードの到達性を確認した結果を表示する画面例を、図５５に示す。
（第一通信ノードでの設定画面例）
画面１ｂは、カウンターサイン設定のトップ画面の例である。ここでは図１８の画面１に対して、「知合い情報」という項目が追加されている。入力フィールドに発信元を示す静的な識別子を入力して、「反映する」ボタンを押下する。亦は「アクション」ボタンを押下する。
「アクション」ボタンを押下することによって、発信元に対して検知させたい状態情報（すなわち附加情報）を設定することが出来る。この附加情報の設定画面は、既に説明した図１９画面３であってよい。図１９画面３の「設定する」ボタンを押下することによって、画面５−２へ戻る。
画面１ｂで「アクション」を選択せずに、「反映する」ボタンを押下すると（入力フィールドには発信元の静的な識別子が入力されているものとする）、附加情報なしの発信元を登録することが出来る。この場合は実施例１０のように動作する。すなわち図１１で、Ｓ２２１０に進まず、Ｓ２２０６亦はＳ２２０８に進む場合である。
画面５−２で「反映する」ボタンを押下することによって、カウンターサイン設定トップに戻る。
画面１ｂ−２では、「知合い情報は設定されています。」とのメッセージに説明のために明示に変更してみた。
【産業上の利用可能性】
【０１０９】
ブローカを用いてするより、柔軟に通信相手の状態情報を検知できる。
【図１】
0004829111.tif 000004
【図２】
0004829111.tif 000005
【図３】
0004829111.tif 000006
【図４】
0004829111.tif 000007
【図５】
0004829111.tif 000008
【図６】
0004829111.tif 000009
【図７】
0004829111.tif 000010
【図８】
0004829111.tif 000011
【図９】
0004829111.tif 000012
【図１０】
0004829111.tif 000013
【図１１】
0004829111.tif 000014
【図１２】
0004829111.tif 000015
【図１３】
0004829111.tif 000016
【図１４】
0004829111.tif 000017
【図１５】
0004829111.tif 000018
【図１６】
0004829111.tif 000019
【図１７】
0004829111.tif 000020
【図１８】
0004829111.tif 000021
【図１９】
0004829111.tif 000022
【図２０】
0004829111.tif 000023
【図２１】
0004829111.tif 000024
【図２２】
0004829111.tif 000025
【図２３】
0004829111.tif 000026
【図２４】
0004829111.tif 000027
【図２５】
0004829111.tif 000028
【図２６】
0004829111.tif 000029
【図２７】
0004829111.tif 000030
【図２８】
0004829111.tif 000031
【図２９】
0004829111.tif 000032
【図３０】
0004829111.tif 000033
【図３１】
0004829111.tif 000034
【図３２】
0004829111.tif 000035
【図３３】
0004829111.tif 000036
【図３４】
0004829111.tif 000037
【図３５】
0004829111.tif 000038
【図３６】
0004829111.tif 000039
【図３７】
0004829111.tif 000040
【図３８】
0004829111.tif 000041
【図３９】
0004829111.tif 000042
【図４０】
0004829111.tif 000043
【図４１】
0004829111.tif 000044
【図４２】
0004829111.tif 000045
【図４３】
0004829111.tif 000046
【図４４】
0004829111.tif 000047
【図４５】
0004829111.tif 000048
【図４６】
0004829111.tif 000049
【図４７】
0004829111.tif 000050
【図４８】
0004829111.tif 000051
【図４９】
0004829111.tif 000052
【図５０】
0004829111.tif 000053
【図５１】
0004829111.tif 000054
【図５２】
0004829111.tif 000055
【図５３】
0004829111.tif 000056
【図５４】
0004829111.tif 000057
【図５５】
0004829111.tif 000058
【図５６】
0004829111.tif 000059