(57)【要約】本発明は、異種ノード間でデータを送信する方法に関する。本発明による方法は、前記ノード間で通信セッションを設定する前に、前記ノードのうち１つにおいて、ユーザエージェントによって送信されるメッセージ（ＲＥ（１），Ｉ（１））内にタイプ指示子を挿入するステップを含み、前記タイプ指示子は前記ユーザエージェント（Ａ）と対応付けられたアドレスのタイプを表わす。本発明は、必要ならば、非互換性を解決する目的で、互いに通信することを要求している２つのタイプのユーザエージェント（Ａ，Ｂ）の間の非互換性の危険性を即座に識別する。ＩＰネットワークにおいてＩＰｖ４、ＩＰｖ６、または、デュアルスタック（ＤＳ）のユーザエージェントの相互通信に適用される。
2009528742.tif 000002
【特許請求の範囲】
【請求項１】
異種ノード間でデータを送信する方法であって、
前記ノード間で通信セッションを設定する前に、前記ノードのうち１つにおいて、ユーザエージェントによって送信される少なくとも１つのメッセージ内にタイプ指示子を挿入する少なくとも１つのステップを含み、
前記タイプ指示子は、前記ユーザエージェントに対応付けされた少なくとも１つのアドレスのタイプを表わすことを特徴とする方法。
【請求項２】
前記タイプ指示子は、ＳＩＰクエリーメッセージ内に含まれる“CONTACT”フィールド内に挿入されることを特徴とする請求項１に記載の方法。
【請求項３】
前記挿入するステップは、前記ユーザエージェントの主導で実行されることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記タイプ指示子は、ＩＰｖ４プロトコル、ＩＰｖ６プロトコル、または、ＩＰｖ４およびＩＰｖ６プロトコルを含むデュアルスタックプロトコルを表わす符号化された数値であることを特徴とする請求項１から３のいずれか１項に記載の方法。
【請求項５】
前記タイプ指示子を、対応付けされたユーザエージェントの識別子への参照とともに記憶するステップをさらに含むことを特徴とする請求項１から４のいずれか１項に記載の方法。
【請求項６】
タイプ指示子を送信するユーザエージェントを、ＩＰｖ４のみ、ＩＰｖ６のみ、または、デュアルスタックの３つのＩＰタイプのカテゴリのうち１つに分類するステップをさらに含むことを特徴とする請求項４または５に記載の方法。
【請求項７】
ユーザエージェントとの通信に入るための呼び出しメッセージ内に含まれる少なくとも１つアドレスを変換するステップをさらに含み、
前記変換するステップは、前記呼び出しメッセージを送信したユーザエージェントに対応付けされたタイプ指示子と前記呼び出しメッセージの宛先のユーザエージェントに対応付けされたタイプ指示子との間で非互換の場合に実行されることを特徴とする請求項１から６のいずれか１項に記載の方法。
【請求項８】
メッセージを送信するユーザエージェントに割り当てられた少なくとも１つのＩＰアドレスのタイプを表わすタイプ指示子を含むクエリーメッセージを伝達する信号。
【請求項９】
異種ノード間でデータを送信するためのシステムであって、
前記ノード間で通信セッションを設定する前に、前記ノードのうち１つにおいて、ユーザエージェントによって送信される少なくとも１つのメッセージ内にタイプ指示子を挿入するための手段を含み、
前記タイプ指示子は、前記ユーザエージェントに対応付けされた少なくとも１つのアドレスのタイプを表わすことを特徴とするシステム。
【請求項１０】
前記ユーザエージェントのタイプ指示子に基づいてクエリーメッセージを送信するユーザエージェントを区別および分類するための手段と、
前記分類を記憶するように構成されたデータベースと、
をさらに含むことを特徴とする請求項９に記載のシステム。
【請求項１１】
少なくとも１つの発信側のユーザエージェントおよび少なくとも１つの着信側のユーザエージェントに固有のタイプ指示子を比較するための手段をさらに含むことを特徴とする請求項１０に記載のシステム。
【請求項１２】
コンピュータで実行されるとき請求項１から４のいずれか１項に記載の方法のステップを実行するための一連のプログラムコード命令を含むコンピュータプログラム。
【請求項１３】
コンピュータで実行されるとき請求項５または６に記載の方法のステップを実行するための一連のプログラムコード命令を含むコンピュータプログラム。
【請求項１４】
コンピュータで実行されるとき請求項６または７に記載の方法のステップを実行するための一連のプログラムコード命令を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の分野は通信の分野であり、より詳しくはＩＰ電話の分野である。
【背景技術】
【０００２】
インターネットプロトコル（ＩＰ）ネットワークは、多数のサービスおよびアプリケーションのための普遍的な媒体としてますます使用されている。ＩＰは、このプロトコルを選択する多くの通信事業者のために、以前の異種サービスの提供を共通化して統合する役割を果たしてきた。
インターネットプロトコルのＩＰｖ４バージョンは何年も使用されてきた。
そのような通信サービスによって強いられる制約にかなうために、より詳しくは、アドレスに関して増加する要求条件を受け入れるために、通信事業者およびネットワーク設備製造業者は協力してＩＰｖ６として知られる新たな世代の通信プロトコルを規定した。ＩＰｖ６は、現在、通信事業者のネットワークにおいて運用の配備を構想することが可能な程度に十分に発展した開発段階にある仕様書および分析書類によって定義されている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
それにもかかわらず、この新たな世代のプロトコルの導入は、ＩＰｖ６プロトコルと、ＩＰネットワークに既に配備されたＩＰｖ４プロトコルとの間の相互運用および相互作用を保証するニーズに関する重大な問題を引き起こしている。この技術の現在の状態におけるそれらの課題への解決策は特定されているが、（特にアプリケーション層における）“サービス”レベルだけでなく（ＩＰ層における）“トランスポート”レベルにおいて影響を及ぼす欠点を有する。トランスポート層において、ＩＰｖ４データグラム内にＩＰｖ６データをカプセル化する、または、その逆のＮＡＴ−ＰＴ（Network Address Translation - Protocol Translation）技術および各種のトンネル技術のようなメカニズムがＩＥＴＦ（Internet Engineering Task Force）によって提案され標準化されてきた。
さらに、アーキテクチャおよびサービスプラットフォームは、エンドユーザのために可能な限り透過的に異種ＩＰ環境（ＩＰｖ４とＩＰｖ６）に位置するクライアント間で相互作用を可能とするように更新および適合されなければならない。
【０００４】
他のマルチメディア機能の中で、ＩＥＴＦはＳＩＰ（Session Initiation Protocol）を標準化し、その主要な機能はマルチメディアセッションを開始、変更、および終了することである。ＳＩＰは、本発明の適用の興味深い例である。それは関係のあるセッションに関するパラメータの記述を生成するためにＳＤＰ（Service Description Protocol）に基づく。２者間の呼へのネゴシエーションが成功すると、両者はＲＴＰ（Real-time Transport Protocol）を起動することによってメディアストリームを交換することができる。ＲＴＰセッションパラメータはＳＩＰシグナリングメッセージによって、特にＳＤＰ部において事前にネゴシエーションされる。それらは主に、設定される通信リンクの両端において使用される末端のアドレスおよびポート番号である。
【０００５】
ＳＩＰの最初のバージョンはＲＦＣ（Request For Comments）２５４３に記載されているので、ＩＰｖ６と互換性を有する。理論上は、ＳＩＰの実装はＩＰｖ４およびＩＰｖ６のアドレスを容易にデコードし、“CONTACT”ヘッダまたはＳＤＰ部のヘッダのような特定のフィールド内に導入することができる。しかし、そのようなアドレスの存在は、両方の端末が同一のＩＰ環境において交信することができないとき、すなわち、一方がＩＰｖ４アドレスを有し、他方がＩＰｖ６アドレスを有するとき、ＳＩＰ呼が設定されることを妨げうる。従って、ＩＰｖ４ユーザエージェントＡが、（“レジストラ”Ｒとしても知られる）ＩＰｖ４ロケーションサーバに登録されたＩＰｖ６ユーザエージェントとのＳＩＰセッションを開始するとき、結果として生じるＳＩＰメッセージの交換は、図１ａに表わされている通りであり、ここで、第２のユーザエージェントＢとの交信を求める第１のユーザエージェントＡは、それに固有のＩＰｖ４アドレスを使用してプロキシサーバＰＳに“INVITE”メッセージを送信する。ここで、プロキシサーバＰＳはＩＰｖ４のみの環境に接続している。そのメッセージがプロキシサーバＰＳによって受信されると、プロキシサーバは、第２のユーザエージェントＢのアドレスを取得するために、登録サーバとしても知られるロケーションサーバにクエリーを送信する。そのアドレスがＩＰｖ６アドレスであると仮定すると、プロキシサーバＰＳがＩＰｖ４のみのタイプであるならば、プロキシサーバＰＳはその宛先への経路を知らない。そして、第１および第２のユーザエージェントＡおよびＢの間にＳＩＰセッションを設定することが不可能であることを示すエラーメッセージがユーザエージェントＡに送信される。このエラーメッセージは、図１ａに表わされているように、“(2) 404 No Route”メッセージである。
【０００６】
ここで、プロキシサーバＰＳは、それにもかかわらず、第２のユーザエージェントＢとともに第１のユーザエージェントＡのロケーションアドレスと交信することができると仮定すると、図１ｂに表わされているように、第２のユーザエージェントＢが第１のユーザエージェントＡを呼び出すことを試みるもう１つのＳＩＰメッセージの交換が発生する。
この場合において、プロキシサーバＰＳは、第２のユーザエージェントＢから受信した“INVITE”メッセージを第１のユーザエージェントＡのロケーションアドレスにルーティングする。この“INVITE”メッセージは、第２のユーザエージェントＢによって提供されるコーデック（符号化器／復号化器）、ＲＴＰポート番号、第２のユーザエージェントＢがＲＴＰストリームを送受信するために使用できるアドレスに加えて、SDP offerの記述を含む。図１ｂにおいて、そのアドレスはＩＰｖ６アドレスである。従って、ユーザエージェントＡがこの“INVITE”メッセージを受信するとき、それはＩＰｖ４クライアントであるので、セッションのオープンを拒否することのみ可能である。それがどのように実装されるかに応じて、良くてユーザエージェントＢのＩＰアドレスにネットワーク接続をサポートしないことを示すエラーメッセージを返送しうる。従って、図１ａおよび１ｂを参照して説明したいずれの例もＳＩＰセッションを設定することができない。
【０００７】
異なるタイプのＩＰアドレスの共存は、図示し上述した以外に呼に影響しうる。従って、デュアルスタック（ＤＳ）クライアントへの呼はメディアストリームの交換において終了することを失敗しうる。ＤＳユーザエージェントはＩＰｖ４およびＩＰｖ６アドレスの両方のタイプを処理することが可能である。これは、基本的なＳＩＰがメディアストリームを送信または受信するためにただ１つのＩＰアドレスを与えることを許すためである。この課題を解決するために、ＲＦＣ４０９２は１つまたは複数のアドレスのタイプをユーザエージェントが通知および／または発見することを可能とする“sdp-agent”フラグを示す新たな一貫した意味論を導入している。従って、ＤＳユーザエージェントは、それらのSDP offer内にＩＰｖ４アドレスとＩＰｖ６アドレスの両方を示すことができる。この技術によって、ＤＳユーザエージェントから単一バージョンのクライアント（すなわち、ＩＰｖ４プロトコルのみ、または、ＩＰｖ６プロトコルのみと互換性があるクライント）へ、または、単一バージョンのクライアントからＤＳユーザエージェントへの全ての呼は、成功したＳＩＰセッション内で終了することができる。
【０００８】
所定の呼を伝達することを意図する通信リンクの端における２つのノードが単一バージョンのノードである場合において、関係するＳＩＰ電話サービス通信事業者は、サポートされるアドレスのタイプと受信したＳＩＰメッセージ内に含まれるタイプとの間の一貫性を保証するようにSDP offerを変更するために、アプリケーションレベルゲートウェイ（ＡＬＧ）アプリケーションを使用することができる。この目的のために、ＳＩＰサーバは、呼をルーディングするために、または、SDP offerの内容を変更するためにＡＬＧアプリケーションを使用することを決定するために、ＳＩＰに固有でないトランスポート層に関する情報を使用する。ＳＩＰサーバのそのような動作は、標準規格によってカバーされていない。
概して、２つの異種ユーザエージェント（すなわち、異なるＩＰタイプのユーザエージェント）を相互接続させることに関する課題は、通信コミュニティによって詳細に検討されていない。特に、課題の一部を解決するＲＦＣ４０９１およびＲＦＣ４０９２に記載されたＡＮＡＴ（Alternative Network Address Types）提案は別として、２つの異なるＩＰ環境において２つのユーザエージェントを接続する呼をルーティングするためのＳＩＰサーバの動作を記載したＩＥＴＦドキュメントは存在しない。
【０００９】
さらに、既存の技術は次の欠点を有する。
・ＡＬＧアプリケーションおよび付加機能を使用することは文書化されていない。プロキシサーバＰＳは、この作業を容易にするためにＲＦＣ３２６１によって指定された手段を有さない。
・プロキシサーバＰＳは、サービス層に関する決定を行うために（この明細書においてはトランスポート層としても参照される）ネットワーク層からの情報を使用しなければならない。従って、メッセージのソースアドレス、プロキシサーバに接続し、または、ＳＤＰ部を検査するために使用されるアドレス以外を考慮しなければならない。これは、サービスレベルの情報のみを処理するために先験的に構成されるプロキシの性能を劣化させる危険にさらす。
・これらのアドレスの使用は効率化されていない。成功したセッションを獲得する１つの方法は、ＳＤＰネゴシエーションが常に成功するように、呼に関与する両方のユーザエージェントが２つのタイプのアドレスを有することを可能とすることであるが、これは、（特に、ＩＰｖ４の）通信事業者に利用可能なアドレス空間の使用の効率化に課題を引き起こす。
・解決策は包括的でない。プロキシサーバＰＳによる呼のルーティングおよび介在の原理は、トランスポートレベルにおいて配備される相互接続の解決策に依存する。
・プロキシサーバＰＳは、ユーザエージェントがＩＰｖ４、ＩＰｖ６、または、ＤＳタイプであるか判定するための手段を有さない。
【課題を解決するための手段】
【００１０】
発明者らの検討は、上記検討から生じるニーズに逆らうことなく、ＩＰ通信ネットワーク内の通信手段が所定のユーザエージェントに対応付けられたアドレスのタイプを識別することを可能とする簡単な方法が現在の技術に存在しないという結論に導いた。これは、現在検討中の異種ノード間の呼を管理するための大多数の技術がなぜ不十分であるか、異種の呼を可能とするサービス要件になぜ対応しないかを説明している。
所定のユーザエージェントによってサポートされるアドレスのタイプを容易に識別することを可能とする送信方法の提案において、本発明は上記欠点を有さない解決策を提供する。
【００１１】
異種ノード間でデータを送信するための本発明による方法は、前記ノード間で通信セッションを設定する前に、前記ノードのうち１つにおいて、ユーザエージェントによって送信されるメッセージ内にタイプ指示子を挿入するステップを含み、前記タイプ指示子は、前記ユーザエージェントに対応付けされたアドレスのタイプを表わすことを特徴とする。
本発明は、必要ならば、このような非互換性を克服する目的で、互いに通信する必要がある２つのタイプのユーザエージェントの間の非互換性のリスクを識別する迅速な方法を提供する。
特に、本発明は、ユーザエージェントが同一のタイプであろうと、異なるタイプであろうと、前記サーバが、それらのユーザエージェント間での効果的な通信セッションの設定のために必要なリソースを識別し、適切に配置することを可能とするために、上述したようなプロキシサーバが互いに通信する必要がある２つのタイプのユーザエージェントを迅速に識別することを可能とする。
【００１２】
ここで、ユーザエージェントの“タイプ”とは、保有するＳＩＰノードのネットワークインタフェースを介してユーザエージェントが利用することができるインターネットプロトコルの１つまたは複数のバージョン（例えば、ＩＰｖ４、ＩＰｖ６）を示す。ノードＡの保有するユーザエージェントのタイプが、ノードＢの保有するユーザエージェントのタイプと異なるならば、２つのノードＡおよびＢは異種であると言う。
【００１３】
従って、本発明のプロトコルは、タイプ指示子を送信するユーザエージェントを、ＩＰｖ４のみ、ＩＰｖ６のみ、または、デュアルスタックの３つのＩＰタイプに従って分類するステップをさらに含みうる。
本発明の１つの特定の実施形態において、前記挿入するステップは、前記ユーザエージェントの主導で実行される。
これは、ユーザエージェントが、送信または受信する呼を、対応するネットワークインタフェースおよびインターネットプロトコルのタイプに制限することを可能とする。
好ましくは、前記タイプ指示子は、ＩＰｖ４プロトコル、ＩＰｖ６プロトコル、または、デュアルスタック（ＩＰｖ４＋ＩＰｖ６）プロトコルを表わす符号化された数値の形態をとりうる。
そのような数値は、いくつかのビットにたいへん容易に符号化することができ、従って、本発明の実装は、呼の目的のために交換されるメッセージの量において著しい増加は引き起こさない。
【００１４】
本発明の第１の効果的な変形において、前記方法は、前記タイプ指示子を、対応付けされたユーザエージェントの識別子とともに記憶するステップをさらに含む。
とりわけ、この記憶するステップは、タイプ指示子が記憶された各ユーザエージェントに対応付けされたＩＰアドレスのタイプを容易かつ直接に識別するために、データベース内に参照テーブルを生成し更新する。このデータベースは、接続の初期化において各ユーザエージェントによって自発的に与えられ、または、ロケーションサーバによって定期的に更新および管理される。ユーザエージェントは、ロケーションサーバを用いて、通信セッションの初期化において、または、登録期間の満了において登録する。
【００１５】
第１の変形に代えて、または、第１の変形とともに使用することができる本発明の第２の効果的な変形において、前記方法は、呼び出しメッセージを送信したユーザエージェントに対応付けされたタイプ指示子と前記呼び出しメッセージの宛先のユーザエージェントに対応付けされたタイプ指示子との間で非互換の場合に、ユーザエージェントとの通信に入るための呼び出しメッセージ内に含まれるアドレスを変換するステップをさらに含みうる。
本発明のこの変形によれば、発信側と着信側のユーザエージェントに対応付けされたタイプ指示子を単に比較することは、発信側と着信側との間で接続を設定する試みが行われる前に、それらの間の非互換性が修復されることを可能とする。
例えば、本発明は、ＶｏＩＰ（Voice over IP）として知られ、または、一般に対話サービスに分類されるＩＰ電話アプリケーションにおいて効果的に使用される。
そして、本発明は、ＲＦＣ３１６２によって定義され、ＩＰｖ４クライアントおよびＩＰｖ６クライアントの両方のために配備された、ＳＩＰを基にしたシグナリングサービスの一般的な課題に取り組む。これらのサービスは、音声、映像、音響、等のサービスでありうる。
【００１６】
上述したように、本発明は、一方がＩＰｖ４ドメインに接続し、他方がＩＰｖ６ドメインに接続した２つの異種クライアントの間でＳＩＰセッションを設定することを容易にするための簡単なメカニズムを提案する。
本発明を使用することによって、ＳＩＰプロキシサーバは、セッションが異種ノード間で設定されることを可能とするために、ＳＩＰ呼をルーティングし、ＲＦＣ２３２７によって定義され、ＳＩＰメッセージ内で伝達されるSDP offerの内容を修正する（または、修正を引き起こす）ために介入することができる。一方、本発明が実装されなければ、ＳＩＰプロキシサーバは、呼のルーティングの選択を助け、成功したＳＩＰセッションを実現するためにＳＩＰメッセージを修正する責任を持つＡＬＧアプリケーションの使用を効率化するために、アプリケーション層以外の情報、特に、ネットワーク層に関する情報にアクセスしなければならない。
同種のプロトコルスタックを使用せず、ＳＩＰサーバおよびＡＬＧアプリケーションによるそのような介入なしでは、ＳＩＰセッションを発生させることはできない。
本発明は、異種ＳＩＰノードの相互作用を可能とし、簡単にし、従って、ＳＩＰ通信システムにおいて呼のルーティングを容易にする。
特に、本発明は、ＩＰアドレスの使用を効率化し、サーバによって受信されるＳＩＰメッセージによって要求される処理を引き起こすために、トランスポート層からの情報に依存するＳＩＰプロキシサーバによるＳＩＰメッセージの処理を必要としない。
【００１７】
ここで言及される適用例に固有な一実施形態において、前記タイプ指示子は、ＳＩＰクエリーメッセージ内に含まれる“CONTACT”フィールド内に挿入されうる。
タイプ指示子をクエリーメッセージ内に導入することは、ユーザエージェントにおいて利用可能なネットワークインタフェースによってサポートされるＩＰアドレスのタイプをロケーションサーバおよびプロキシサーバに通知する。さらに、プロキシサーバは、ネットワーク層内の情報にアクセスする必要なく、タイプ指示子を使用してその宛先にルーティングするためにクエリーメッセージを処理することができる。
上述した本発明の第１の変形の上記例への適用を置き換えると、ユーザエージェントが“REGISTER”メッセージ内にタイプ指示子を挿入することが分かる。
従って、“REGISTER”メッセージを受信すると、ロケーションサーバは、登録アドレス、登録有効期限、タイプ指示子を記憶する処理を行う。また、他のデータを記憶することができる。
上述した本発明の第２の変形の上記例への適用を置き換えると、“INVITE”メッセージを送信するユーザエージェントに対応付けされたタイプ指示子と“INVITE”メッセージの宛先のユーザエージェントに対応付けされたタイプ指示子との間で非互換の場合に、プロキシサーバは“INVITE”メッセージ内に含まれるアドレスを変換することが分かる。
そのような非互換性は、特に、“INVITE”メッセージを送信および受信するユーザエージェントが異なるタイプであるとき生じる。
【００１８】
本発明のそのような適用は、異なるタイプの２つのユーザエージェントの間で呼のメッセージを修正するためにアプリケーションレベルにおいてゲートウェイを使用して呼のルーティング処理を実行しなければならないプロキシサーバは、
・ロケーションサーバによって更新され、発信側および着信側のユーザエージェントのタイプの特性を含む登録データベース内に記憶された分類に基づいて、
・または、着信側のユーザエージェントのタイプの特性、および、発信側のユーザエージェントによって送信された“INVITE”メッセージ内に含まれるタイプ指示子を含む登録データベース内に記憶された分類に基づいて、
そのような処理を実行する。
上記説明から明らかなように、本発明は、また、上述した適用における実現によって直接に得られる物によって、メッセージを送信するユーザエージェントに対応付けされたＩＰアドレスの特性を表わすタイプ指示子を含むクエリーメッセージを伝達する信号に関し、メッセージは、例えば、“REGISTER”、“INVITE”、または、“200 OK”とすることができる。タイプ指示子は、特に、“CONTACT”フィールド内に挿入することができる。
【００１９】
本発明のハードウェアの態様は、異種ノード間でデータを送信するためのシステムに関し、前記ノード間で通信セッションを設定する前に、前記ノードのうち１つにおいて、ユーザエージェントによって送信されるメッセージ内にタイプ指示子を挿入するための手段を含み、前記タイプ指示子は、前記ユーザエージェントに対応付けされたアドレスのタイプを表わすことを特徴とする。
本発明のこのハードウェアの態様の１つの変形は、前記ユーザエージェントのタイプ指示子に基づいてクエリーメッセージを送信するユーザエージェントを区別および分類するための手段と、前記分類を記憶するように構成されたデータベースと、をさらに含む上記送信システムに関する。
本発明のこのハードウェアの態様のもう１つの変形は、発信側のユーザエージェントおよび着信側のユーザエージェントに固有のタイプ指示子を比較するための手段をさらに含む上記送信システムに関する。
【００２０】
実現するために有効な手段を構成する本発明のもう１つのハードウェアの態様は、コンピュータで実行されるとき前記方法のあるステップを実行するための一連のプログラムコード命令を含むコンピュータプログラムに関する。
【発明を実施するための最良の形態】
【００２１】
本発明は、添付図面を参照して、限定しない例によって与えられる、続く説明に照らして、より良く理解することができる。
図２および続く図面を参照して、本発明による方法のより詳細な説明が与えられる。
概して、例えば、ＩＰｖ４、ＩＰｖ６、または、デュアルスタック（ＤＳ）ハイブリッドＩＰ端末によって構成される各々の異種ノードは特定のタイプのユーザエージェントＵＡを含み、そのタイプは関係する端末に利用可能なネットワークインタフェースを介してユーザエージェントが使用することができるＩＰのバージョンに対応する。
図２に表わされているように、本発明による方法は、ステップ１０において、ユーザエージェントＵＡによって送信されるクエリーメッセージＭ内にタイプ指示子“atypes”を挿入する。この挿入の後、クエリーメッセージは、Ｍ（“atypes”）と表記される。そのようなクエリーメッセージは、例えば、（“レジストラ”としても知られている）ロケーションサーバＲへの登録メッセージを含む。また、プロキシサーバＰＳに送信されるメッセージ、例えば、他のユーザエージェントとの通信に入ることを促すメッセージが存在しうる。
タイプ指示子が挿入されたメッセージの送信（１３）の後、本発明による方法は、含まれるタイプ指示子“atypes”に基づいてクエリーメッセージＭ（“atypes”）を処理する（１１）。この処理は、登録メッセージについてロケーションサーバ、または、他のユーザエージェントとの通信に入ることを促すメッセージについてプロキシサーバでありうる装置１２において行われる。
【００２２】
プロキシサーバ１２において実行される処理１１は、プロキシサーバ１２がトランスポート層内の情報にアクセスする必要なく、メッセージをルーティングする。
特に、タイプ指示子“atypes”は、この情報をロケーションサーバおよびプロキシサーバ１２に提供するために、メッセージを送信するユーザエージェントに利用可能なネットワークインタフェースおよびインターネットプロトコルの特性を表わす符号化された数値データを含み、
・通信することを試みる責任を負う各種のユーザエージェントのタイプについての情報を提供するデータベースを維持するように、ロケーションサーバ１２がユーザエージェントの識別子に対応付けられたタイプ指示子の登録１１に進むことを可能とし、
・プロキシサーバ１２がＭ（“atypes”）メッセージを送信するために使用されるトランスポート層内の情報にアクセスせずにルーティング１１を処理することを可能とすることが理解される。
【００２３】
以下、図３および図４を参照して、図２に表わされている本発明による方法のステップ１０の実現例を説明する。
１つの特定の類型の実施形態において、タイプ指示子“atypes”はＳＩＰクエリー、特に、“REGISTER”および“INVITE”クエリーの“CONTACT”フィールド内に挿入される。この指示子の定義を説明するために、ＲＦＣ３１６２によって定義されている“CONTACT”フィールドのＡＢＮＦ（Augmented Backus-Naur form（拡張バッカス・ナウア記法））記述を以下に示す。
下記のＡＢＮＦ記述において、この技術分野で周知の要素およびＲＦＣ３１６２に記載されている要素は通常の字体、追加の記述要素は太字の字体とした。
新たなＡＢＮＦ記述の全体を下記の表１に示す。
【００２４】
【表１】
2009528742.tif 000003
【００２５】
ユーザエージェントは、
・ＩＰｖ４インタフェースにおいて、
・ＩＰｖ６インタフェースにおいて、
・または、デュアルスタック（ＤＳ）インタフェースが設けられている（すなわち、ＩＰｖ４およびＩＰｖ６の両方のプロトコルバージョンと互換性を有する）ならば、両方のタイプのインタフェースにおいて、
発信呼または着信呼を制限することを要求しうる。
この動作はタイプ指示子“atype”によって通知される。
ユーザエージェントは、タイプ指示子“atype”を適切な値に設定することによって実際の利用可能性を通知しないように構成することができる。設定されたアドレスの１つがグローバルな範囲であるときのみ（ＩＰｖ６プロトコルは“リンクローカル”および“グローバル”なタイプのアドレスを区別する）、ＩＰｖ６インタフェースが利用可能であるとみなされる。ローカルな範囲のアドレスは、ルーティングすることができる（すなわち、ローカルなネットワークを越えて接続される）グローバルな範囲のアドレスと異なり、ローカルなネットワークを越えてルーティングすることができない。登録の間に、ＳＩＰユーザエージェントは、下記の値
・ユーザエージェントがＩＰｖ４のみサポートするならば４、
・ユーザエージェントがＩＰｖ６のみサポートするならば６、
・ユーザエージェントがデュアルスタックを利用可能ならば０
をとりうる追加の欄の“atype”を含む表１に記載されているように拡張された“CONTACT”フィールドを有する“REGISTER”メッセージを送信する。
ユーザエージェントは、登録サーバＲに送信される“REGISTER”メッセージ内のタイプ指示子“atype”を（例えば、ユーザエージェントがデュアルスタックタイプであっても）４に設定することによってＩＰｖ４プロトコルのみサポートすること、または、タイプ指示子“atype”を６に設定することによってＩＰｖ６プロトコルのみサポートすること、または、タイプ指示子“atype”を０に設定することによってデュアルスタックプロトコルＤＳをサポートすることをプロキシサーバＰＳに通知することができる。
図３において、ＲおよびＲ６は、それぞれ、ユーザエージェントＡおよびＢに対応するロケーションサーバを示す。
【００２６】
＜ＩＰｖ４ユーザエージェントの例＞
ユーザエージェントＡはアドレス192.165.25.2を有するＩＰｖ４ユーザエージェントであると仮定する。図３に表わされているように、ユーザエージェントＡは、表２に記載されている“(1) REGISTER”メッセージをロケーションサーバＲに送信する。
【００２７】
【表２】
2009528742.tif 000004
【００２８】
登録サーバＲは、表３に記載されている“(2) 200 OK”を用いてユーザエージェントＡに応答する。
【００２９】
【表３】
2009528742.tif 000005
【００３０】
＜ＩＰｖ６ユーザエージェントの例＞
ユーザエージェントＢはアドレス2001:688:1ffb:ff80::2を有するＩＰｖ６ユーザエージェントであると仮定する。図３に表わされているように、ユーザエージェントＢは、表４に記載されている“(1) REGISTER”メッセージをロケーションサーバＲ６に送信する。
【００３１】
【表４】
2009528742.tif 000006
【００３２】
登録サーバＲ６は、登録を確認するために、表５に記載されている“(2) 200 OK”を用いてユーザエージェントＡに応答する。
【００３３】
【表５】
2009528742.tif 000007
【００３４】
“CONTACT”フィールド内のＩＰアドレスは、タイプ指示子“atype”フィールド内に示されている以外のタイプのユニークなアドレスとすることができる。タイプ指示子“atype”を６に設定するユーザエージェントは“CONTACT”フィールド内にＩＰｖ４アドレスを使用することができ、タイプ指示子“atype”を０に設定するユーザエージェントは以下で説明するように２つではなく１つのみのアドレスを宣言することができる。“CONTACT”フィールド内に含まれるアドレスは、シグナリングメッセージをルーティングするためにＳＩＰプロキシサーバによって使用される。ユーザエージェントは（プロキシサーバに送信されるメッセージ内に挿入されるタイプ指示子に基づいて、または、このユーザエージェントのためにロケーションサーバによって記憶されたタイプ指示子に基づいて）そのプロキシサーバＰＳにＩＰｖ６ユーザエージェントとして宣言したので、メディアメッセージはＩＰｖ６インタフェースを介してユーザエージェントに送信される。
【００３５】
＜“CONTACT”フィールド内に１つのみのアドレスを有するＤＳユーザエージェントの例＞
図４を参照し、ユーザエージェントはアドレス2001:688:1ffb:ff80::2／192.168.25.5を有するデュアルスタック（ＤＳ）ユーザエージェントであると仮定する。図４に表わされているように、登録フェーズの間に、ＤＳユーザエージェントは、表６に記載されている“(1) REGISTER”メッセージをそのロケーションサーバＲに送信する。
【００３６】
【表６】
2009528742.tif 000008
【００３７】
ロケーションサーバＲ６は、登録を確認するために、表７に記載されている“(2) 200 OK”メッセージを用いて応答する。
【００３８】
【表７】
2009528742.tif 000009
【００３９】
＜タイプ指示子“atype”の処理＞
“REGISTER”メッセージを受信すると、ロケーションサーバＲは、Address of Record（ＡＯＲ）、登録有効期限、タイプ指示子“atype”を記憶する。このデータ（および、おそらく他のデータ）は、ロケーションサーバによって管理される登録データベース内に記憶される。これは同一のユーザエージェントから到達する他の“REGISTER”メッセージによって更新されうる。この処理は、最初にＲＦＣ３２６１において用意された処理を置き換える。タイプ指示子“atype”からの情報を使用して、ロケーションサーバはそのユーザエージェントを３つのカテゴリ
・ＩＰｖ４のみ
・ＩＰｖ６のみ
・デュアルスタック（ＤＳ）
に分類する。
この分類は、ロケーションサーバによって管理される登録データベースを検索することによってプロキシサーバに簡単にアクセス可能である。また、以下で説明するように、プロキシサーバのために意図されたメッセージ内にユーザエージェントによって挿入されたタイプ指示子を単に読み出すプロキシサーバによって直接に処理することができる。
また、ユーザエージェントは、それらが“INVITE”メッセージを送信するときに、タイプ指示子“atype”を設定することができる。
【００４０】
プロキシサーバＰＳは下記の場合（ケース１）にそれらの内容を修正せずにＳＩＰメッセージを送信しなければならない。
・ＩＰｖ４からＩＰｖ４へ
・ＩＰｖ６からＩＰｖ６へ
・ＩＰｖ４からＤＳへ、および、ＤＳからＩＰｖ４へ
・ＩＰｖ６からＤＳへ、および、ＤＳからＩＰｖ６へ
・ＤＳからＤＳへ
上記ケース１の場合において、ユーザエージェントは、同一のタイプであり（または、概して、それらは少なくとも１つの共通のタイプを有するので、ＤＳユーザエージェントを用いて、）、従って同一のＩＰバージョンを使用して対話することできるので、互換性を有すると言う。
【００４１】
下記の場合（ケース２）のみ修正が行われた後、ＳＩＰメッセージの修正は、同一タイプの着信側および発信側のユーザエージェントのＩＰアドレスを利用可能にする。
・ＩＰｖ６からＩＰｖ４へ
・ＩＰｖ４からＩＰｖ６へ
上記ケース２の場合において、ユーザエージェントは、同一のタイプでなく、従って通信できないので、互換性を有さないと言う。
呼のルーティング、および、異なるタイプの２つのユーザエージェントの間で成功してセッションを獲得するためにＡＬＧアプリケーションを使用するか、または、ＳＩＰメッセージを修正する決定のために、プロキシサーバ（ＰＳ）は、次のいずれかを行うことができる。
【００４２】
＜ロケーションサーバによって維持される登録データベースを検査する＞
この場合において、プロキシサーバＰＳは、発信側および着信側のユーザエージェントのタイプについてロケーションサーバＲに問い合わせる。すると、プロキシサーバＰＳは、ケース２の場合の１つであるシナリオにおいて、着信側によってサポートされるアドレスのタイプと一致させるために、ＳＩＰメッセージのＳＤＰの内容を修正することを決定することができる。図５に表わされている例は、ＩＰｖ４ユーザエージェントＡとＩＰｖ６ユーザエージェントＢとの間の呼を通して、この動作モードを説明している。ＩＰｖ４およびＩＰｖ６ネットワークを相互接続する機能はノードＩＮによって表わされ、これは中継局としての役割を果たし、特に、ＩＰｖ４データグラムとＩＰｖ６データグラムとの間でプロトコル変換を実行する。
ユーザエージェントＢはＩＰｖ６ユーザエージェントであると仮定する。サービスの開始において、ユーザエージェントＢはタイプ指示子“atype”を６に設定してロケーションサーバＲに設定されており、ユーザエージェントＡはタイプ指示子“atype”を４に設定してロケーションサーバＲに設定されている。簡単のために、この前置きの登録フェーズは図５に表わされていない。
ユーザエージェントＢは、ＮＡＴ−ＰＴメカニズムのようなＩＰｖ６−ＩＰｖ４相互接続メカニズムによってＩＰｖ４アドレスに変換されたＩＰｖ６アドレスによってＩＰｖ６環境内で知られている。そして、ユーザエージェントＢはＩＰｖ６ユーザエージェントとして識別され、ユーザエージェントＡはＩＰｖ４ユーザエージェントとして識別される。ユーザエージェントＡがユーザエージェントＢとのセッションを設定することを要求しているならば、下記のＳＩＰメッセージが交換される。
・ＲＥ（１）  ユーザエージェントＡはプロキシサーバＰＳに“INVITE”メッセージを送信する。
・ＲＥ（２）  プロキシサーバＰＳは、ユーザエージェントＢのロケーションアドレス、および、登録の間に指定されたユーザエージェントＡおよびＢのタイプ指示子“atype”についてロケーションサーバＲに問い合わせる。
・ＲＥ（３）  ロケーションサーバＲは、ユーザエージェントＢのアドレス、ユーザエージェントＢのタイプ指示子“atype”、ユーザエージェントＡのタイプ指示子“atype”を返送する。
・ＲＥ（４）  プロキシサーバＰＳは、ユーザエージェントＡおよびＢの２つのタイプ指示子“atype”を比較する。ロケーションサーバＲにおいて利用可能な分類のタイプに基づいて、プロキシサーバＰＳは、ＡがＩＰｖ４ユーザエージェントであり、ＢがＩＰｖ６ユーザエージェントであることを確認する。そして、プロキシサーバＰＳは、適合させるメカニズムに、ＩＰｖ６アドレスを含むようにユーザエージェントＡの最初のSDP offerを修正させる。そして、プロキシサーバＰＳは、修正された“INVITE”メッセージをロケーションサーバＲによって指定されたユーザエージェントＢのアドレスに送信する。
この手順なしでは、プロキシサーバＰＳは、ユーザエージェントＢに呼をルーティングする手段、および、ユーザエージェントＢへのメッセージの正しいルーティングのために必要な、適合させる機能を起動するための手段を有さない。プロキシサーバＰＳは、それを修正することなくユーザエージェントＢにクエリーを返送し、この場合においてユーザエージェントＡおよびＢの間のＳＩＰセッションは生じえない（図１ｂを参照）。
【００４３】
＜または、登録データベース、および、“INVITE”メッセージ内で伝達されるタイプ指示子“atype”を検査する＞
この場合において、プロキシサーバＰＳは、着信側のユーザエージェントＢのタイプについてロケーションサーバＲに問い合わせる。発信側のユーザエージェントＡのタイプは、送信された“INVITE”メッセージから導き出される。そして、プロキシサーバＰＳは、着信側のユーザエージェントＢによってサポートされるアドレスのタイプと一致させるために、ＳＩＰメッセージの内容を修正することを決定することができる。このシナリオは、ケース２の場合の１つである。このオプションのために、ユーザエージェントは、各セッションについて使用されるアドレスのタイプを制限することができる。図５を参照して説明される例は、ＩＰｖ４ユーザエージェントとＩＰｖ６ユーザエージェントとの間の呼を通して、他の動作モードを説明している。
ユーザエージェントＢはＩＰｖ６ユーザエージェントであると仮定する。サービスの開始において、ユーザエージェントＢはタイプ指示子“atype”を６に設定してロケーションサーバＲに設定されており、ユーザエージェントＡはタイプ指示子“atype”を４に設定してロケーションサーバＲに設定されている。ここで、ユーザエージェントＢはＩＰｖ６ユーザエージェントとして識別され、ユーザエージェントＡはＩＰｖ４ユーザエージェントとして識別される。ユーザエージェントＡがユーザエージェントＢとのセッションの設定を要求しているならば、下記のＳＩＰメッセージが交換される。
・Ｉ（１）  ユーザエージェントＡはプロキシサーバＰＳに“INVITE”メッセージを送信する。
・Ｉ（２）  プロキシサーバＰＳは、ユーザエージェントＢのロケーションアドレス、および、登録の間に指定されたユーザエージェントＢのタイプ指示子“atype”についてロケーションサーバＲに問い合わせる。
・Ｉ（３）  ロケーションサーバＲは、ユーザエージェントＢのアドレスおよびタイプ指示子“atype”を返送する。
・Ｉ（４）  プロキシサーバＰＳは、“Ｉ（１）INVITE”クエリーからユーザエージェントＡのタイプ指示子“atype”を抽出し、それをユーザエージェントＢのタイプ指示子“atype”と比較する。ロケーションサーバＲにおいて利用可能な分類のタイプに基づいて、プロキシサーバＰＳは、ユーザエージェントＡがＩＰｖ４ユーザエージェントであり、ユーザエージェントＢがＩＰｖ６ユーザエージェントであることを確認する。そして、プロキシサーバＰＳは、適合させるメカニズムに、ＩＰｖ６アドレスを含むようにユーザエージェントＡの最初のSDP offerを修正させる。そして、プロキシサーバＰＳは、修正された“INVITE”メッセージをロケーションサーバＲによって指定されたユーザエージェントＢのアドレスに送信する。
【００４４】
図５に表わされているプロトコルを使用するために、プロキシサーバＰＳは、好ましくは、発信側のユーザエージェントおよび着信側のユーザエージェントと対応付けされたタイプ指示子を比較するためのモジュールＭ１を含む。モジュールＭ１が発信側および着信側のユーザエージェントが異なるタイプであると判定したならば、プロキシサーバは発信側のユーザエージェントのＩＰアドレスを修正するためのリソースを呼び出すためにモジュールＭ２を起動させる。修正するためのリソースはプロキシサーバＰＳの外部に存在し、図５には表わされていない。モジュールＭ１およびＭ２は、コンピュータプログラムの形態で実現することができる。簡単のために、それらは、図５において同一の英数字の参照符号で示されている。
【００４５】
本発明は、さらに、ＩＰ端末のＩＰｖ４、ＩＰｖ６、または、デュアルスタックのユーザエージェントのような、コンピュータまたは専用装置によって実行するためのコンピュータプログラムＭ０を含む。コンピュータプログラムＭ０が実行されるとき、そのコード命令は、上述し、図２、３、４に表わされているように、そのユーザエージェントＵＡ内で利用可能なネットワークインタフェースによってサポートされる１つまたは複数のＩＰアドレスのタイプを表わすタイプ指示子“atype”をユーザエージェントＵＡによって送信されるクエリーメッセージ内に挿入する。
上述したように、本発明は、さらに、プロキシサーバＰＳのような、コンピュータまたは専用装置によって実行するための一連の命令を含むコンピュータプログラムＭ１、Ｍ２を含む。コンピュータプログラムＭ１、Ｍ２が実行されるとき、それらの命令は、ユーザエージェントによってプロキシサーバに送信され、そのユーザエージェント内で利用可能なネットワークインタフェースによってサポートされる１つまたは複数のＩＰアドレスのタイプを表わすタイプ指示子“atype”を含むクエリーメッセージを処理する。このような処理は、上述し、図２から５に表わされているように、トランスポート層内に含まれる情報へのアクセスなしでその宛先にクエリーメッセージをルーティングする。
本発明は、また、ロケーションサーバＲのような、コンピュータまたは専用装置によって実行するためのコード命令を含むコンピュータプログラムＭ３を含む。コンピュータプログラムＭ３が実行されるとき、その命令は、ユーザエージェントによって送信される登録メッセージからタイプ指示子を抽出し、登録データベース内に、関係するユーザエージェントの識別子に関するタイプ指示子を記憶する。また、それらは、上述し、図２から５に表わされているように、関係するユーザエージェントを３つのＩＰカテゴリ（ＩＰｖ４、ＩＰｖ６、デュアルスタック）のうち１つに分類する。
【図面の簡単な説明】
【００４６】
【図１ａ】先行技術に関する図である。
【図１ｂ】先行技術に関する図である。
【図２】本発明による方法の主要なステップのフローチャートの例を表わす。
【図３】ＩＰｖ４およびＩＰｖ６ユーザエージェントの登録の第１の例を表わす。
【図４】デュアルスタックユーザエージェントの登録の第２の例を表わす。
【図５】ユーザエージェントがロケーションサーバに“REGISTER”メッセージを送信し、プロキシサーバを通して“INVITE”メッセージを渡す場合において動作する、異種ＳＩＰノードの相互作用のための本発明によるシステムを表わす。
【符号の説明】
【００４７】
ＰＳ  プロキシサーバ
Ｒ  ロケーションサーバ
ＵＡ  ユーザエージェント
【図１ａ】
2009528742.tif 000010
【図１ｂ】
2009528742.tif 000011
【図２】
2009528742.tif 000012
【図３】
2009528742.tif 000013
【図４】
2009528742.tif 000014
【図５】
2009528742.tif 000015
【手続補正書】
【提出日】平成20年10月31日(2008.10.31)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
異種ノード間でデータを送信する方法であって、
前記ノード間で通信セッションを設定する前に、前記ノードのうち１つにおいて、ユーザエージェントによって送信される少なくとも１つのメッセージ内にタイプ指示子を挿入する少なくとも１つのステップを含み、
前記タイプ指示子は、前記ユーザエージェントに対応付けされた少なくとも１つのアドレスのタイプを表わすことを特徴とする方法。
【請求項２】
前記タイプ指示子は、ＳＩＰクエリーメッセージ内に含まれる“CONTACT”フィールド内に挿入されることを特徴とする請求項１に記載の方法。
【請求項３】
前記挿入するステップは、前記ユーザエージェントの主導で実行されることを特徴とする請求項１または２に記載の方法。
【請求項４】
前記タイプ指示子は、ＩＰｖ４プロトコル、ＩＰｖ６プロトコル、または、ＩＰｖ４およびＩＰｖ６プロトコルを含むデュアルスタックプロトコルを表わす符号化された数値であることを特徴とする請求項１から３のいずれか１項に記載の方法。
【請求項５】
前記タイプ指示子を、対応付けされたユーザエージェントの識別子への参照とともに記憶するステップをさらに含むことを特徴とする請求項１から４のいずれか１項に記載の方法。
【請求項６】
タイプ指示子を送信するユーザエージェントを、ＩＰｖ４のみ、ＩＰｖ６のみ、または、デュアルスタックの３つのＩＰタイプのカテゴリのうち１つに分類するステップをさらに含むことを特徴とする請求項４または５に記載の方法。
【請求項７】
ユーザエージェントとの通信に入るための呼び出しメッセージ内に含まれる少なくとも１つアドレスを変換するステップをさらに含み、
前記変換するステップは、前記呼び出しメッセージを送信したユーザエージェントに対応付けされたタイプ指示子と前記呼び出しメッセージの宛先のユーザエージェントに対応付けされたタイプ指示子との間で非互換の場合に実行されることを特徴とする請求項１から６のいずれか１項に記載の方法。
【請求項８】
メッセージを送信するユーザエージェントに割り当てられた少なくとも１つのＩＰアドレスのタイプを表わすタイプ指示子を含むクエリーメッセージを伝達する信号。
【請求項９】
異種ノード間でデータを送信するためのシステムであって、
前記ノード間で通信セッションを設定する前に、前記ノードのうち１つにおいて、ユーザエージェントによって送信される少なくとも１つのメッセージ内にタイプ指示子を挿入するための手段を含み、
前記タイプ指示子は、前記ユーザエージェントに対応付けされた少なくとも１つのアドレスのタイプを表わすことを特徴とするシステム。
【請求項１０】
前記ユーザエージェントのタイプ指示子に基づいてクエリーメッセージを送信するユーザエージェントを区別および分類するための手段と、
前記分類を記憶するように構成されたデータベースと、
をさらに含むことを特徴とする請求項９に記載のシステム。
【請求項１１】
少なくとも１つの発信側のユーザエージェントおよび少なくとも１つの着信側のユーザエージェントに固有のタイプ指示子を比較するための手段をさらに含むことを特徴とする請求項１０に記載のシステム。
【請求項１２】
コンピュータで実行されるとき請求項１から４のいずれか１項に記載の方法のステップを実行するための一連のプログラムコード命令を含むコンピュータプログラム。
【請求項１３】
コンピュータで実行されるとき請求項５または６に記載の方法のステップを実行するための一連のプログラムコード命令を含むコンピュータプログラム。
【請求項１４】
コンピュータで実行されるとき請求項６または７に記載の方法のステップを実行するための一連のプログラムコード命令を含むコンピュータプログラム。
【請求項１５】
データ送信システムのノードを構成する端末であって、
前記ノードにおいて、ユーザエージェントによって送信される少なくとも１つのメッセージ内にタイプ指示子を挿入するための手段を含み、
前記タイプ指示子は、前記ユーザエージェントに対応付けされた少なくとも１つのアドレスのタイプを表わすことを特徴とする端末。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１９
【補正方法】変更
【補正の内容】
【００１９】
本発明のハードウェアの態様は、異種ノード間でデータを送信するためのシステムに関し、前記ノード間で通信セッションを設定する前に、前記ノードのうち１つにおいて、ユーザエージェントによって送信されるメッセージ内にタイプ指示子を挿入するための手段を含み、前記タイプ指示子は、前記ユーザエージェントに対応付けされたアドレスのタイプを表わすことを特徴とする。また、そのようなデータ送信システムのノードを構成する端末に関し、前記ノードにおいて、ユーザエージェントによって送信されるメッセージ内にタイプ指示子を挿入するための手段を含み、前記タイプ指示子は、前記ユーザエージェントに対応付けされたアドレスのタイプを表わす。
本発明のこのハードウェアの態様の１つの変形は、前記ユーザエージェントのタイプ指示子に基づいてクエリーメッセージを送信するユーザエージェントを区別および分類するための手段と、前記分類を記憶するように構成されたデータベースと、をさらに含む上記送信システムに関する。
本発明のこのハードウェアの態様のもう１つの変形は、発信側のユーザエージェントおよび着信側のユーザエージェントに固有のタイプ指示子を比較するための手段をさらに含む上記送信システムに関する。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００２０
【補正方法】変更
【補正の内容】
【００２０】
実現するために有効な手段を構成する本発明のもう１つの態様は、コンピュータで実行されるとき前記方法のあるステップを実行するための一連のプログラムコード命令を含むコンピュータプログラムに関する。
【国際調査報告】
2009528742.tif 000016
2009528742.tif 000017
2009528742.tif 000018
2009528742.tif 000019
2009528742.tif 000020
2009528742.tif 000021