(57)【要約】【課題】  ＩＭＰＰではＩＭＰＰサーバからの制約によって、ウォッチャはそのポーリング間隔を自由に決めることができなかった。  発信元通信ノードの利用者が他の通信ノードのプレゼンスを検知するタイミングを、自由に指定したタイミングで、検知できるようにする。  より具体的には、ポーリングする際の時間間隔をブローカの制約を無視して、利用者が自由に指定できるポーラを実現する。【解決手段】  到達性確認を用いて、利用者が時間間隔を指定し、その時間間隔で通信相手のオンライン／オフライン亦は通信相手の状態情報を検知できるようにした。【選択図】図１６
2007201663.tif 000002
【特許請求の範囲】
【請求項１】
静的な識別子と動的な住所が関連付けられることによって宛先発見される蓄積交換網にあって、一定期間到達性の正しさが確認されなかった場合には、到達性確認をされる通信ノードにおいてカウンターサインを応答しないようにすることによって、宛先発見過程上の誤認を減少させることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は蓄積交換網において、動的な住所からなる通信ノードに対する宛先発見過程と、通信相手についてする状態検知に関する。
【背景技術】
【０００２】
【特許文献１】WO2004/059925
【０００３】
インターネット商用化後の一般利用者の用いる端末は、変動する住所を有し、通信相手として特定する識別子を有しない端末であった。このような端末とも通信したいという要望があった。最初に試みられたのは、通信相手を一意に特定する静的な識別子（以下、「静的な識別子」とする）を設定し、これに変動する住所を追随させるシステムに、通信相手を特定することを委ねることであった。このようなシステムには、例えばｗｅｂｈｏｐ 、ＩＭＰＰ（RFC2778, RFC2779）、動的ＤＮＳ（RFC2136, RFC3007）、ＳＩＰ（RFC3261-3265, RFC3856）、ＥＮＵＭ（RFC2916, RFC3401-3406, RFC3761）等がある。
このとき、通信相手がオンラインでなければ通信を開始することが出来なかったことから、本番の通信を始める前に通信相手の到達性を知ることが重要だった。これがプレゼンスが必要とされた背景である。
【０００４】
ＲＦＣ２７７８にはウォッチャの内、フェッチャとサブスクライバが定義されている。フェッチャはポーラを含む。
前記システムの内、プレゼンスを提供するものは、ＳＩＰとＩＭＰＰである。ＳＩＰはサブスクライバ型であり、ＩＭＰＰはポーラ型である。
【０００５】
以下に、通信相手のプレゼンスを検知するタイミングは、ブローカとの関係で決まることを、ポーラについて示す。
ＩＭＰＰでは自ノードを宛先発見させるための「登録の更新」とともに、自ノードの状態情報を登録し、事前登録された通信相手（ＩＭＰＰでは一般に「バディ」という）についてのプレゼンスをも検知していた。
これを図１８に、バディＢがバディＡのプレゼンスを検知する場合を例として示す。
プレゼンスは、オンライン／オフライン（＝到達性）を少なくとも含み、通信相手の状態情報（実は単なるメッセージ）を含む場合がある。
バディＡでは、「登録の更新」をするとともに自己の状態情報をもブローカ（ＲＦＣ２７７８で言うプレゼンスサービスのこと）に登録する（ステップＳ１−ａ）。
バディＢでは、バディＡと同様に「登録の更新」をするとともに自己の状態情報をもブローカに登録する（ステップＳ１−ｂ）。そして同タイミングで事前登録されたバディ（図ではバディＡ）のプレゼンスをブローカから取得する（ステップＳ２−ｂ）。
このときバディＢが知るバディＡのプレゼンスは、バディＡがＳ１−ａでした「登録の更新」およびプレゼンスの登録に基づく。
すなわちブローカでは、ステップＳ１−ａをステップＳ２−ｂに関連付けてバディＢに伝播する（ステップＳ３）。
ブローカではステップＳ１−ａが一定時間受信されない場合には、バディＡの登録を時間切れで破棄（＝エキスパイア）する。この際ブローカはＳ２−ｂによって、バディＢが知るバディＡのプレゼンスをオンラインからオフラインに切替える。
【０００６】
すなわちエッジノードからの「登録の更新」は、ブローカにおいて登録がエキスパイアされるより前にしなければならない。このことから「登録の更新」はキープアライブに相当するものと言える。
そして、このタイミングで通信相手のプレゼンスをも検知していた。
【０００７】
以上のことから、プレゼンスの検知のタイミングは、ブローカがする登録のエキスパイア時間より短い間隔でされていた。プレゼンスを検知する側の利用者がそのタイミングを指定することが仮にできたとしても、その限界は「登録の更新」のタイミングに拘束される。すなわちこれは、ブローカがプレゼンス検知のタイミングを制約するすることを意味する。
よってＩＭＰＰモデルでは、フェッチャの内、より限定された形態であるポーラのみが実現されており、フェッチャそのものは実現されていなかった。
【０００８】
一方、特許文献１には、静的な識別子と動的な住所とが関連付けられることによって到達性が得られる網において、宛先通信ノードがオンラインであるかオフラインであるかを発信元通信ノードが検知する手段について開示されている。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
発信元通信ノードの利用者が他の通信ノードのプレゼンスを検知するタイミングを、自由に指定したタイミングで、検知できるようにする。
より具体的には、ポーリングする際の時間間隔をブローカの制約を無視して、利用者が自由に指定できるポーラを実現する。
【課題を解決するための手段】
【００１０】
特許文献１を応用して、利用者が時間間隔を指定し、その時間間隔で通信相手のオンライン／オフライン亦は通信相手の状態情報を検知できるようにした。
【００１１】
（目次）
（実施例１）附加情報なしの場合である。通信ノードの到達性のありなしの変化を利用者が指定した時間間隔で検知し、表示する。
（実施例２）附加情報ありの場合である。通信ノードの状態情報を利用者が指定した時間間隔で検知し、表示する。
（実施例３）イベント・マッチングでアクションするの場合である。通信ノードの状態変化に対してイベント・ゴールを設定し、これを検知した時に事前に設定した動作を取らせる。
【００１２】
（用語の対応）
マッピング公示システム３０≒ＩＭＰＰサーバ＝ブローカである。
第二通信ノード２０＝バディＢ＝プレゼンス検知する通信ノードである。
第一通信ノード１０＝バディＡ＝被プレゼンス検知通信ノードである。
【発明の効果】
【００１３】
１．宛先通信ノード（亦は宛先通信ノードの利用者）の状態変化を発信元通信ノードの利用者の指定する時間間隔で検知して、表示する。
２．予想される宛先通信ノード（亦は宛先通信ノードの利用者）の変化した状態をゴールとして設定し、ゴール到達時点で発信元通信ノードの利用者の注意を喚起することができる。
３．到達性確認を用いることにより、「登録の更新」に依存せずに、プレゼンスを知ろうとする通信ノード亦は該通信ノードの利用者に、通信相手の、その時点でのプレゼンスを検知することを可能にした。
以って柔軟なプレゼンス検知を実現し、（特に発信元通信ノードの）利用者の利便を向上する。
【発明を実施するための最良の形態】
【００１４】
以下、本発明を図面に基づいて説明する。なお、各図面において同様の機能を有する箇所には同一の符号を付している。以下に掲げる実施例は、制限でなく例である。
【００１５】
（網全体ブロック図）
図０１は、本発明における網全体を示すブロック図である。図０1には、第一通信ノード１０と、第二通信ノード２０と、通信ノードからの問い合わせに応じて第一通信ノード１０の住所を返信するマッピング公示システム３０とが、インターネット等の網４０を介して相互に接続される状態を示している。
【００１６】
（実施例１）
図０２は、図０１に示す第ニ通信ノード２０のブロック構成を示している。図０２には、作業用の一時記憶を含む記憶装置２１０と、宛先指定部２２０と、発信部２３０と、網４０に接続するための物理的な通信インタフェース２９０とを示している。
【００１７】
記憶装置２１０は、登録済宛先情報２１１と、宛先情報２１２とを備える。
登録済宛先情報２１１は、宛先についての情報を事前に登録されたものである。登録済宛先情報２１１は、複数の宛先レコードからなるテーブルであってよい。１レコード当たりのフォーマットを図０５（イ）に示す。
宛先情報２１２は、以下に示す少なくとも１つのレコードからなるテーブルであってよい。１つのレコードは、宛先を示す静的な識別子２１３と、答えられるべき返事２１４と、指定時間間隔２１５と、宛先住所２１６とからなる
宛先を示す静的な識別子２１３は、宛先の静的な識別子を記憶するものである。
答えられるべき返事２１４は、宛先からの答えられるべき返事を記憶するものである。
指定時間間隔２１５は、宛先毎にポーリングする指定時間間隔を記憶するものである。
宛先住所２１６は、マッピング公示システム３０からの応答によって知り得た宛先の静的な識別子に対応する住所を記憶するものである。
【００１８】
宛先指定部２２０は、プレゼンス検知したい通信ノードを指定する手段をユーザに提供するものである。宛先指定部２２０には、図示しないユーザ・インタフェースが含まれる。ユーザ・インタフェースの代表例は画面と鍵盤とからなるものである。宛先指定部２２０は、宛先情報２１２を生成する。
【００１９】
発信部２３０は、発信のみをするものではなく受信することもある。その本質は宛先通信ノードに対して到達性確認するものである。
発信部２３０は、以下説明する、住所取得部２３１と、サイン信号送信部２３２と、カウンターサイン信号受信部２３３と、判定部２３４と、表示部２３９と、タイマ２４０とを備える。
住所取得部２３１は、第一通信ノードに係る静的な識別子をマッピング公示システムに問合せることによって、宛先通信ノードの住所を取得するものである。
サイン信号送信部２３２は、住所取得部２３１によって取得された住所宛てにサイン信号を送信するものである。
カウンターサイン信号受信部２３３は、他の通信ノードから送信されてきたカウンターサイン信号を受信するとともに、一時記憶するものである。
判定部２３４は、一時記憶された返事に基づいて当該カウンターサイン信号が所望の通信ノードから送信されたものであるか否かという到達性確認を行うものである。
表示部２３９は、ユーザインターフェースを含み、到達性確認の結果を、第二通信ノードの使用者に表示亦は第二通信ノードでする後続する処理に接続するものである。
タイマ２４０は、計時するものである。
【００２０】
図０３に、第二通信ノード２０のフローチャートを示す。
ステップＳ２０２では、ユーザからの指示によって宛先指定部２２０が登録済宛先情報２１１を読み出すか亦はユーザからの手入力によって、宛先情報２１２を生成する。
【００２１】
図０４に手入力の場合の画面例を示す。図０４では、宛先の「静的な識別子」を入力フィールド１に入力させ、「答えられるべき返事」を入力フィールド２に入力させ、指定時間間隔をプルダウンメニューから選択させるようにしている。入力フィールド１の入力は必須である。入力フィールド２は、「静的な識別子」と「答えられるべき返事」とが同一の場合には省略可である。また「答えられるべき返事」は特許文献１から、文字列のみでなくルールであってもよい。指定時間間隔は、プルダウンメニューではなく、図示しない入力フィールド３を用意して時間を指定させるようにしてもよい。また指定時間間隔も省略可能である。
【００２２】
これらの情報を基に、宛先指定部２２０が宛先情報２１２を生成する。宛先情報２１２には、宛先を示す静的な識別子２１３と、宛先からの答えられるべき返事２１４と、指定時間間隔２１５と、宛先住所２１６とを含む。
図０４に示す画面例の入力フィールド１に入力された情報は、宛先指定部２２０によって宛先を示す静的な識別子２１３にコピーされる。
図０４入力フィールド２に入力された情報に中身があれば、宛先からの答えられるべき返事２１４に宛先指定部２２０がコピーする。図０４入力フィールド２に情報が入力されていなければ、宛先指定部２２０が宛先を示す静的な識別子２１３を宛先からの答えられるべき返事２１４にコピーする。
宛先指定部２２０がユーザが選択したプルダウンメニューの値を指定時間間隔２１５にコピーする。プルダウンメニューの替りに図示しない入力フィールド３を用意した場合には、入力フィールド３の内容を指定時間間隔２１５にコピーする。なお、単位は秒であっても時間であってもよい。亦は１日１回といった指定も可能である。明示の指定なき場合には図示しない既定値をコピーしてもよい。この場合であっても、ＩＭＰＰの場合と異なり、この既定値はブローカからの制約によらずに、利用者亦は開発者が値を決定することができる。
なお宛先住所２１６については、この時点では空でよい。念の為にこの時点で、宛先住所２１６を初期化しておいてもよい。このようにして宛先指定部２２０は、宛先情報２１２のレコードを生成する。
宛先情報２１２のフォーマットを、図０５（ロ）に示す。宛先情報２１２は処理に先立って生成され、処理の終了と供に消滅するものであってよい。
【００２３】
このようにしてユーザによって入力された情報は次回に入力の手間を省く為に、登録済宛先情報２１１に記憶しておいてもよい。登録済宛先情報２１１に記憶される情報をフォーマットとして図０５（イ）に示す。フォーマットには少なくとも宛先の静的な識別子を含み、必要なら答えられるべき返事と、望ましくは指定時間間隔とを含む。その他の情報が含まれていることは差支えない。次回以降は登録済宛先情報２１１を一覧表示させ、その中からお目当ての相手を指定すれば足る。
【００２４】
ステップＳ２０４以降はステップＳ２２０までをループする。ループを抜ける時は割込み等を用いればよい。
ステップＳ２０４では、住所取得部２３１が、マッピング公示システム３０に宛先を示す静的な識別子２１３でもって問合せる。
【００２５】
ステップＳ２０６では、住所取得部２３１がマッピング公示システム３０からの応答があったかどうかを検査している。ここで応答があればステップＳ２０８に進み、応答がなければステップＳ２１８に分岐する。なお応答がない場合においては、マッピング公示システム３０に問題がある可能性が高いので図示しないアラートをあげても良い。
【００２６】
ステップＳ２０８では、住所取得部２３１が、マッピング公示システムからの返事に含まれる住所を宛先住所２１６にセットする。なお住所取得部２３１の替りに宛先指定部２２０がセットするようにしてもよい。
【００２７】
ステップＳ２１０では、サイン信号送信部２３２が宛先住所２１６宛に、サイン信号を送信する。
【００２８】
ステップＳ２１２では、カウンターサイン信号受信部２３３が、第一通信ノード１０からのカウンターサイン信号を受信する。なおカウンターサイン信号は受信されない場合がある。
【００２９】
ステップＳ２１４では、判定部２３４が、受信したカウンターサイン信号亦はカウンターサイン信号を受信しなかったことから第一通信ノード１０への到達性の真偽を判断する。到達性確認の結果が真の場合は、ステップＳ２１６に進む。偽の場合は、ステップＳ２１８に分岐する。
【００３０】
ステップＳ２１６では、第一通信ノード１０がオンラインであることを表示部２３９によって表示する。
【００３１】
ステップＳ２１８では、第一通信ノード１０がオフラインであることを表示部２３９によって表示する。なお特許文献１から、表示とは必ずしもコンソールに対するものだけでなく、その他の手段であっても良い。
【００３２】
ステップＳ２２０では、タイマ２４０が指定時間間隔２１５に指定された時間待機し、その後に、本ループ先頭のステップＳ２０４から再び開始する。すなわち指定時間間隔２１５がポーリングする間隔となる。
【００３３】
（実施例１変形例）
実施例１に対して、特許文献１に開示されたトラフィックを減ずるためのアプリケーション的な解決を適用した変形例を示す。特許文献１と比較して、ステップＳ２０４の前にする判断分岐が省略してある。特許文献１と異なり、本発明ではＤＮＳトラフィックのみを減ずるものではない。トラフィックを減ずることはポーラの場合こそ特に有効である。
【００３４】
図０６は、図０１に示す第ニ通信ノード２０のブロック構成を示している。図０６には、作業用の一時記憶を含む記憶装置２１０と、宛先指定部２２０と、発信部２３０と、網４０に接続するための物理的な通信インタフェース２９０とを示している。
【００３５】
記憶装置２１０は、登録済宛先情報２１１と、宛先情報２１２とを備える。
登録済宛先情報２１１については、変更がないので説明を省略する。以下、変更点のみを説明する。
宛先情報２１２には、図０２に示したものに対して、フラグ２１７が追加されている。
フラグ２１７は、トラフィックを減ずるためのループ制御で用いるものであり、その意味は、オフラインの時にのみ２回目のループを回すことを判断するためのものである。
宛先情報２１２のフォーマットを、図０５（ハ）に示す。
【００３６】
発信部２３０は、図０２に示したものに対して、フラグ処理部２３５が追加されている。
フラグ処理部２３５は、フラグ２１７を見て１回目のループか２回目のループかを判断し、ループ制御するものである。またフラグ２１７のオン／オフも切替える。
【００３７】
図０７に、第二通信ノード２０のフローチャートを示す。
実施例１の場合と比較して、以下変更点のみ説明する。
ステップＳ２０２では、宛先指定部２２０がフラグ２１７をオンにしておく。
【００３８】
ステップＳ２０６およびステップＳ２１４の判断分岐ではＮＯの場合にステップＳ２１８ではなく、ステップＳ４１０に分岐する。
【００３９】
ステップＳ４１０では、フラグのオン／オフを判断している。オンの場合は、ステップＳ２１８に進む。オフの場合は、ステップＳ４１２に分岐する。
【００４０】
ステップＳ４１２では、フラグ２１７をオンにセットする。これより２回目のループに入る。ループする先は、ステップＳ２１０ではなくステップＳ２０４である。
【００４１】
ステップＳ２１６およびステップＳ２１８では、ステップＳ２２０に進むのではなく、ステップＳ４１４に進む。
【００４２】
ステップＳ４１４では、フラグ２１７をオフにする。
ステップＳ２２０では、ループする先が実施例１の場合と比較して変更されている。ループする先は、ステップＳ２０４ではなくステップＳ２１０である。
以上をまとめると以下のようにして、トラフィックを減じ、マッピング公示システム３０の負荷を減ずることができる。最初の処理では、必ずマッピング公示システム３０に問合せる。そして最初の処理以後は宛先住所２１６が記憶されているので、マッピング公示システム３０への問合せを省略して単にループする（これを「１回目のループ」という）。第一通信ノード１０の住所が変化した場合には、記憶された宛先住所２１６は既に古い情報であるために、必ずオフラインが検知される。よって、マッピング公示システム３０への問合せを省略していると、第一通信ノード１０が本当にオフラインであるとは断定できない。そこでオフライン検知の時のみ、マッピング公示システム３０への問合せからやり直して、最新の宛先住所２１６で再度到達性確認をする（これを「２回目のループ」という）。
【００４３】
（実施例２）
本発明と同一の出願人、同一の発明者による本願出願時点で未公開のPCT/JP2005/011775（以下、「特許文献２」とする）では、単にオンライン／オフラインのみでなく、通信相手の状態情報を検知する手段について開示している。要約すると、第一通信ノード１０は、状態情報を附加情報としてカウンターサイン信号に埋め込んでキャリーし、第二通信ノード２０は、カウンターサイン信号から附加情報を分離して通信相手の状態情報を検知するというものである。
【００４４】
図０８は、図０１に示す第ニ通信ノード２０のブロック構成を示している。図０８には、作業用の一時記憶を含む記憶装置２１０と、宛先指定部２２０と、発信部２３０と、網４０に接続するための物理的な通信インタフェース２９０とを示している。
【００４５】
記憶装置２１０は、登録済宛先情報２１１と、宛先情報２１２とを備える。実施例１に示したものと同様である。以下、実施例１に対する変更点のみ説明する。
【００４６】
発信部２３０は、図０２に示したものに対して、附加情報処理部２３６が追加されている。
附加情報処理部２３６は、附加情報に係る処理を行うものである。
【００４７】
図０９に、第二通信ノード２０のフローチャートを示す。
実施例１の場合と比較して、以下変更点のみ説明する。
ステップＳ２１４の判断分岐でＹＥＳの場合には、ステップＳ６１０に進む。
【００４８】
ステップＳ６１０では、附加情報処理部２３６がカウンターサイン信号に附加情報が含まれていたかどうかを判断している。附加情報が含まれていなければ、ステップＳ２１６に分岐する。附加情報が含まれていれば、ステップＳ６１２に進む。
【００４９】
ステップＳ６１２では、附加情報処理部２３６がカウンターサイン信号から附加情報を抽出する。
【００５０】
ステップＳ６１４では、表示部２３９が附加情報を表示する。亦は第一通信ノード１０がオンラインであることを明示して、附加情報を表示する。この後、ステップＳ２２０に進む。
【００５１】
ステップＳ２２０では、タイマ２４０がユーザが指定した指定時間間隔２１５を待機した後、ステップＳ２０４にループする。ポーリング間隔の指定の仕方は、実施例１に示した通りである。
【００５２】
（実施例２変形例）
実施例２に対する変形例を示す。変形の内容は、実施例１に対する実施例１変形例と同様で、マッピング公示システム３０への問合せを通常時は省略することによって、トラフィックを減じマッピング公示システム３０の負荷を減ずるものである。
【００５３】
図１０は、図０１に示す第ニ通信ノード２０のブロック構成を示している。図１０には、作業用の一時記憶を含む記憶装置２１０と、宛先指定部２２０と、発信部２３０と、網４０に接続するための物理的な通信インタフェース２９０とを示している。
【００５４】
記憶装置２１０は、登録済宛先情報２１１と、宛先情報２１２とを備える。
宛先情報２１２には、図０８に示したものに対して、フラグ２１７が追加されている。
フラグ２１７は、トラフィックを減ずるためのループ制御で用いるものであり、その意味は、オフラインの時にのみ２回目のループを回すことを判断するためのものである。
【００５５】
発信部２３０は、図０８に示したものに対して、フラグ処理部２３５が追加されている。
フラグ処理部２３５は、フラグ２１７を見て１回目のループか２回目のループかを判断し、ループ制御するものである。またフラグ２１７のオン／オフも切替える。
【００５６】
図１１に、第二通信ノード２０のフローチャートを示す。
実施例２の場合と比較して、以下変更点のみ説明する。
ステップＳ２０２では、宛先指定部２２０がフラグ２１７をオンにしておく。
【００５７】
ステップＳ２０６およびステップＳ２１４の判断分岐ではＮＯの場合にステップＳ２１８ではなく、ステップＳ４１０に分岐する。
【００５８】
ステップＳ４１０では、フラグのオン／オフを判断している。オンの場合は、ステップＳ２１８に進む。オフの場合は、ステップＳ４１２に分岐する。
【００５９】
ステップＳ４１２では、フラグ２１７をオンにセットする。これより２回目のループに入る。ループする先は、ステップＳ２０４である。これによって、２回目のループは、マッピング公示システム３０への問合せからすることになり、逆に１回目のループではマッピング公示システム３０への問合せが省略できることから、トラフィックを減じマッピング公示システム３０の負荷を減ずることができる。
【００６０】
ステップＳ２１６およびステップＳ２１８、ステップＳ６１４では、ステップＳ２２０に進むのではなく、ステップＳ４１４に進む。
【００６１】
ステップＳ４１４では、フラグ２１７をオフにする。
【００６２】
ステップＳ２２０では、ループする先が実施例２の場合と比較して変更されている。ループする先は、ステップＳ２０４ではなくステップＳ２１０である。
【００６３】
（実施例３）
図１２は、図０１に示す第ニ通信ノード２０のブロック構成を示している。図１２には、作業用の一時記憶を含む記憶装置２１０と、宛先指定部２２０と、発信部２３０と、網４０に接続するための物理的な通信インタフェース２９０とを示している。
【００６４】
記憶装置２１０は、登録済宛先情報２１１と、宛先情報２１２とを備える。
登録済宛先情報２１１のフォーマットには、イベントゴールと、アクションの記述とが追加されている。１レコード当たりのフォーマットを図０５（ニ）に示す。
宛先情報２１２には、図０８に示したものに対して、イベントゴール２１８と、アクションの記述２１９とが追加されている。
イベントゴール２１８は、附加情報のマッチングを図るものである。
アクションの記述２１９は、附加情報がイベントゴールにマッチした時に実行する処理を記述したものである。
【００６５】
発信部２３０は、図０８に示したものに対して、イベントマッチ部２３７と、アクション部２３８とが追加されている。
イベントマッチ部２３７は、イベントゴール２１８と受信した附加情報とがマッチしているかどうかを判断するものである。
アクション部２３８は、アクションの記述２１９に記載の処理を実行するものである。
【００６６】
図１３に、第二通信ノード２０のフローチャートを示す。
ステップＳ２０２では、宛先指定部２２０が宛先情報２１２を生成するのに先立って、ユーザが手入力する場合には、イベントゴールと、アクションの記述とを、図０４に示す入力画面で図示しない入力フィールド４および図示しない入力フィールド５を用意しておいて、これに入力させる。
このようにして入力された入力フィールド４の内容を、宛先指定部２２０はイベントゴール２１８にコピーし、入力フィールド５の内容をアクションの記述２１９にコピーする。
もちろん同様の情報は、次回以降の為に登録済宛先情報２１１に記憶してもよい。また、既に登録済宛先情報２１１に同内容が記憶されている場合には、登録済宛先情報２１１の内容を読出すことを以って手入力に替えても差支えない。このようにして、宛先指定部２２０が宛先情報２１２を生成する。なお、アクションの記述２１９は処理の呼出し方であってもよい。
【００６７】
実施例２の場合と比較して、以下変更点のみ説明する。
ステップＳ６１２では、附加情報処理部２３６がカウンターサイン信号から附加情報を抽出した後に、ステップＳ６１４ではなくステップＳ８１０に進む。
【００６８】
ステップＳ８１０では、前記抽出した附加情報がイベントゴール２１８とマッチしているかどうかをイベントマッチ部２３７が判断する。マッチングには幅を持たせてもよい。マッチしていれば、ステップＳ８１２に進む。マッチしていなければ、ステップＳ８１２をスキップしてステップＳ６１４に進む。
【００６９】
ステップＳ８１２では、アクション部２３８がアクションの記述２１９に記載の処理を実行する。なおアクションの記述２１９の記載によって、アクションの最後にブレークして処理を抜けるようにしてもよい。
【００７０】
以後、実施例２と同様にステップＳ６１４、ステップＳ２２０に進む。
【００７１】
ステップＳ２２０では、タイマ２４０がユーザが指定した指定時間間隔２１５を待機した後、ステップＳ２０４にループする。ポーリング間隔の指定の仕方は、実施例２に示した通りである。
【００７２】
（実施例３変形例）
実施例３に対する変形例を示す。変形の内容は、実施例１に対する実施例１変形例と同様で、マッピング公示システム３０への問合せを通常時は省略することによって、トラフィックを減じマッピング公示システム３０の負荷を減ずるものである。
【００７３】
図１４は、図０１に示す第ニ通信ノード２０のブロック構成を示している。図１４には、作業用の一時記憶を含む記憶装置２１０と、宛先指定部２２０と、発信部２３０と、網４０に接続するための物理的な通信インタフェース２９０とを示している。
【００７４】
記憶装置２１０は、登録済宛先情報２１１と、宛先情報２１２とを備える。
宛先情報２１２には、図１２に示したものに対して、フラグ２１７が追加されている。
フラグ２１７は、トラフィックを減ずるためのループ制御で用いるものであり、その意味は、オフラインの時にのみ２回目のループを回すことを判断するためのものである。
【００７５】
発信部２３０は、図１２に示したものに対して、フラグ処理部２３５が追加されている。
フラグ処理部２３５は、フラグ２１７を見て１回目のループか２回目のループかを判断し、ループ制御するものである。またフラグ２１７のオン／オフも切替える。
【００７６】
図１５に、第二通信ノード２０のフローチャートを示す。
実施例３の場合と比較して、以下変更点のみ説明する。
ステップＳ２０２では、宛先指定部２２０がフラグ２１７をオンにしておく。
【００７７】
ステップＳ２０６およびステップＳ２１４の判断分岐ではＮＯの場合にステップＳ２１８ではなく、ステップＳ４１０に分岐する。
【００７８】
ステップＳ４１０では、フラグのオン／オフを判断している。オンの場合は、ステップＳ２１８に進む。オフの場合は、ステップＳ４１２に分岐する。
【００７９】
ステップＳ４１２では、フラグ２１７をオンにセットする。これより２回目のループに入る。ループする先は、ステップＳ２０４である。これによって、２回目のループは、マッピング公示システム３０への問合せからすることになり、逆に１回目のループではマッピング公示システム３０への問合せが省略できることから、トラフィックを減じマッピング公示システム３０の負荷を減ずることができる。
【００８０】
ステップＳ２１６およびステップＳ２１８、ステップＳ６１４では、ステップＳ２２０に進むのではなく、ステップＳ４１４に進む。
【００８１】
ステップＳ４１４では、フラグ２１７をオフにする。
【００８２】
ステップＳ２２０では、ループする先が実施例３の場合と比較して変更されている。ループする先は、ステップＳ２０４ではなくステップＳ２１０である。
【産業上の利用可能性】
【００８３】
（実際的応用）
実施例３を用いて、予定行動通知・目標達成通知を実現してみる。
例として、第一通信ノード１０が移動し目的地に到達したことを、第二通信ノード２０が検知した場合に、赤色灯を回してみる。これを図１６に示す。
【００８４】
第一通信ノード１０は、図１７に示すＧＰＳセンテンスを附加情報としてカウンターサイン信号に含めてキャリーするものとする。
第二通信ノード２０では、図１７に示すＧＰＳセンテンスと同様の形式でゴール地点での第一通信ノード１０からキャリーされてきて欲しい附加情報を、イベントゴール２１８に記憶しておく。アクションの記述２１９には、図示しない第二通信ノード２０のインターフェースを経由して第二通信ノード２０から見た外部装置であるところの赤色灯を回すことが記述されているものとする。
【００８５】
第一通信ノード１０が、図１６に示す１０−ａ地点から１０−ｂ地点に移動した時に、第二通信ノード２０はポーリングを続けており、これによって附加情報をもキャリーするカウンターサイン信号から、第二通信ノード２０は第一通信ノード１０がゴール地点に到達したことを検知すると、実施例３に従って赤色灯を回すことができる。
【００８６】
ここでは、第二通信ノード２０が第一通信ノード１０の移動による目的到着を赤色灯を回すことによって、ヒトに明示に通知したが、自動化処理等を含むあらゆる用途に応用できる。もちろんこの時点で、従来と同様に音声による呼出を行ってもよい。
例えばこの例では、第一通信ノード１０においては、自ノードの地理的な位置を把握しておかなくてもよい。これは利点である。例えば、第一通信ノード１０が通信機能を有してはいるがハードウェア的に制限が多い等の理由によって、多くの機能を詰め込むことができない場合に、第一通信ノード１０の替りにその機能を第二通信ノード２０が負担することができるようになる。
【００８７】
（むすび）
以下に、ＩＭＰＰとの比較を試みる。
ＩＭＰＰとの共通点。
プレゼンス検知である。
【００８８】
ＩＭＰＰとの相違点。
１．ウォッチャとプレゼンティティは等価である必要がない。
ＩＭＰＰでは通信する両端がお互いにウォッチャとプレゼンティティの役割を交代する。すなわち、お互いが通信相手の状態を検知する。本発明では、第ニ通信ノード２０が第一通信ノード１０の状態を検知するものである。もっとも第一通信ノード１０側で同じことをやれば、お互いで検知しあうことができる。両端でお互いを検知しあうことは必須ではない（すなわち片方向のみで成立つ）ことは、スケーラビリティに寄与すると発明者は考えている。
２．ログインしない。
ＩＭＰＰと異なり、本提案ではログインした時点で、通信相手がオフラインであるかオンラインであるかが表示されるということはない。当然に通信相手を事前登録することも必須ではない（利用者の利便のために事前登録することはよい）。
３．ブローカからのポーリング間隔に関する制約を受けない。
効果に示した通りである。キープアライブと同タイミングで、常にプレゼンス検知する必要はないのである。リアルタイム性が必要な場合には、任意の短い時間間隔でポーリングすることによって容易にリアルタイム化できる。
４．後続する通信はＩＭでなくともよい。
以上から、ウォッチャとプレゼンティティは完全に分離されており、またログインも必要ない。すなわちＩＭＰＰで実現されたプレゼンス・サービスとは異なり、従来にないプレゼンス検知のあり方を提案するものである。
【図面の簡単な説明】
【００８９】
【図０１】網全体ブロック図である。
【図０２】実施例１に係る第二通信ノード２０のブロック図である。
【図０３】実施例１に係る第二通信ノード２０のフローチャートである。
【図０４】入力画面例である。
【図０５】レコードフォーマットである。
【図０６】実施例１変形例に係る第二通信ノード２０のブロック図である。
【図０７】実施例１変形例に係る第二通信ノード２０のフローチャートである。
【図０８】実施例２に係る第二通信ノード２０のブロック図である。
【図０９】実施例２に係る第二通信ノード２０のフローチャートである。
【図１０】実施例２変形例に係る第二通信ノード２０のブロック図である。
【図１１】実施例２変形例に係る第二通信ノード２０のフローチャートである。
【図１２】実施例３に係る第二通信ノード２０のブロック図である。
【図１３】実施例３に係る第二通信ノード２０のフローチャートである。
【図１４】実施例３変形例に係る第二通信ノード２０のブロック図である。
【図１５】実施例３変形例に係る第二通信ノード２０のフローチャートである。
【図１６】実際的応用のイメージ図である。
【図１７】ＧＰＳのセンテンス例である。
【図１８】従来技術を示す図である。
【符号の説明】
【００９０】
10      第一通信ノード
20      第ニ通信ノード
30      マッピング公示システム
40      網
20      第ニ通信ノード（Ｓ）
210         記憶装置２１０
211             登録済宛先情報２１１
212             宛先情報２１２
213             宛先を示す静的な識別子２１３
214             宛先からの答えられるべき返事２１４
215             指定時間間隔２１５
216             宛先住所２１６
217             フラグ２１７
218             イベントゴール２１８
219             アクションの記述２１９
220         宛先指定部２２０（宛先毎のレコード生成部）
230         発信部２３０（到達性確認部）
231             住所取得部２３１
232             サイン信号送信部２３２
233             カウンターサイン信号受信部２３３
234             判定部２３４
235             フラグ処理部２３５
236             附加情報処理部２３６
237             イベントマッチ部２３７
238             アクション部２３８
239             表示部２３９
240             タイマ２４０
290         通信インタフェース
【図０１】
2007201663.tif 000003
【図０２】
2007201663.tif 000004
【図０３】
2007201663.tif 000005
【図０４】
2007201663.tif 000006
【図０５】
2007201663.tif 000007
【図０６】
2007201663.tif 000008
【図０７】
2007201663.tif 000009
【図０８】
2007201663.tif 000010
【図０９】
2007201663.tif 000011
【図１０】
2007201663.tif 000012
【図１１】
2007201663.tif 000013
【図１２】
2007201663.tif 000014
【図１３】
2007201663.tif 000015
【図１４】
2007201663.tif 000016
【図１５】
2007201663.tif 000017
【図１６】
2007201663.tif 000018
【図１７】
2007201663.tif 000019
【図１８】
2007201663.tif 000020
【手続補正書】
【提出日】平成18年2月4日(2006.2.4)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
静的な識別子と住所とが関連付けられることによって宛先発見過程を提供する網において、
通信相手がオンラインであるかオフラインであるかを検知する通信ノードであって、
通信相手を指定するとともにポーリング間隔をも指定し、該ポーリング間隔で通信相手にサイン信号を送信し、通信相手が応答したカウンターサイン信号の内容か亦はカウンターサイン信号を受信しなかったことから、通信相手がオンラインであるかオフラインであるかをポーリングすることを特徴とする通信ノード。
【請求項２】
請求項１に記載の通信ノードを実現するプログラム。
【請求項３】
請求項１に記載の通信ノードにおいて、
通信相手の住所が判った後には、住所取得過程を省略することを特徴とする通信ノード。
【請求項４】
請求項３に記載の通信ノードを実現するプログラム。
【請求項５】
請求項３に記載の通信ノードにおいて、
オフラインが検知された場合に再度通信相手の住所取得過程からやり直すことを特徴とする通信ノード。
【請求項６】
請求項５に記載の通信ノードを実現するプログラム。
【請求項７】
静的な識別子と住所とが関連付けられることによって宛先発見過程を提供する網において、
通信相手がどのような状態にあるかを検知する通信ノードであって、
通信相手を指定するとともにポーリング間隔をも指定し、該ポーリング間隔で通信相手にサイン信号を送信し、通信相手が附加情報をもキャリーするカウンターサイン信号を応答した場合には、該カウンターサイン信号から附加情報を抽出することによって、通信相手の状態をポーリングすることを特徴とする通信ノード。
【請求項８】
請求項７に記載の通信ノードを実現するプログラム。
【請求項９】
請求項７に記載の通信ノードにおいて、
通信相手の住所が判った後には、住所取得過程を省略することを特徴とする通信ノード。
【請求項１０】
請求項９に記載の通信ノードを実現するプログラム。
【請求項１１】
請求項９に記載の通信ノードにおいて、
オフラインが検知された場合に再度通信相手の住所取得過程からやり直すことを特徴とする通信ノード。
【請求項１２】
請求項１１に記載の通信ノードを実現するプログラム。
【請求項１３】
請求項７に記載の通信ノードにおいて、状態を検知する通信ノードに状態を検知させる通信ノードから検知される予定の状態情報を記憶し、
通信相手の状態情報を検知した際に該情報と実際に検知した通信相手の状態情報とを比較し、その一致を見たときには、
状態を検知する通信ノードにあらかじめ記憶したアクションを実施することを特徴とする通信ノード。
【請求項１４】
請求項１３に記載の通信ノードを実現するプログラム。
【請求項１５】
請求項１３に記載の通信ノードにおいて、
通信相手の住所が判った後には、住所取得過程を省略することを特徴とする通信ノード。
【請求項１６】
請求項１５に記載の通信ノードを実現するプログラム。
【請求項１７】
請求項１５に記載の通信ノードにおいて、
オフラインが検知された場合に再度通信相手の住所取得過程からやり直すことを特徴とする通信ノード。
【請求項１８】
請求項１７に記載の通信ノードを実現するプログラム。
【請求項１９】
状態を検知させる通信ノードと、状態を検知する通信ノードとが網を経由して接続される場合であって、
状態を検知する通信ノードに状態を検知させる通信ノードの状態をあらかじめ登録しておき、
状態を検知した通信ノードが検知した状態を検知させる通信ノードの状態が前記登録された情報と一致した場合に、
状態を検知する通信ノードにあらかじめ設定されたアクションをとらせることを特徴とするシステム。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００８８
【補正方法】変更
【補正の内容】
【００８８】
ＩＭＰＰとの相違点。
１．ウォッチャとプレゼンティティは等価である必要がない。
ＩＭＰＰでは通信する両端がお互いにウォッチャとプレゼンティティの役割を交代する。すなわち、お互いが通信相手の状態を検知する。本発明では、第ニ通信ノード２０が第一通信ノード１０の状態を検知するものである。もっとも第一通信ノード１０側で同じことをやれば、お互いで検知しあうことができる。両端でお互いを検知しあうことは必須ではない（すなわち片方向のみで成立つ）ことは、スケーラビリティに寄与すると発明者は考えている。
２．ログインしない。
ＩＭＰＰと異なり、本提案ではログインした時点で、通信相手がオフラインであるかオンラインであるかが表示されるということはない。当然に通信相手を事前登録することも必須ではない（利用者の利便のために事前登録することはよい）。
３．ブローカからのポーリング間隔に関する制約を受けない。
効果に示した通りである。キープアライブと同タイミングで、常にプレゼンス検知する必要はないのである。リアルタイム性が必要な場合には、任意の短い時間間隔でポーリングすることによって容易にリアルタイム化できる。
４．後続する通信はＩＭでなくともよい。
以上から、ウォッチャとプレゼンティティは完全に分離されており、またログインも必要ない。すなわちＩＭＰＰで実現されたプレゼンス・サービスとは異なり、従来にないプレゼンス検知のあり方を提案するものである。
最後に本発明を実施するに当たっての利点を示す。それは親和性である。
本発明は、既存のブローカを否定するものでなく、既存のブローカと排他的な関係にあるものでもない。すなわちたとえ既存のブローカが存在する環境であっても、本発明は実施をすることができる。
【手続補正４】
【補正対象書類名】図面
【補正対象項目名】図０５
【補正方法】変更
【補正の内容】
【図０５】
2007201663.tif 000021