２層の（ｂｉ−ｌｅｖｅｌ）アドレス指定スキームを用いて通信をルーティングするための方法および通信ノード
方法および通信ノードが、相互接続オペレータネットワーク経由で通信をルーティングするために提供される。これらの通信は、個人および／または組織間でルーティング可能である。典型的には、これらの通信は、データベース（４１０）内の情報に基づいてルーティングされ、セッション開始プロトコル（ＳＩＰ）通信の中に記憶される。
【発明の詳細な説明】
【技術分野】
【０００１】
本書の例示的実施形態は、一般にシステムとデバイスとソフトウェアと方法とに関し、より詳細には、相互接続ネットワークを通ってメッセージをルーティングするためのメカニズムおよび技法に関する。
【背景技術】
【０００２】
技術的能力が拡大を続けるのにつれて、通信の選択肢は多様化してきた。例えば、この３０年余りの間に通信業界では個人間の通信が進化し、以前は家庭にダイヤル式電話が１台しかなかったのに、今では家庭には電話とケーブルと、および／または、音声とデータとの両方に対応する光ファイバ回線とが複数ある。さらに、携帯電話およびＷｉ−Ｆｉによって、通信に移動要素が加わった。同様に娯楽業界では、３０年前にはテレビ用のフォーマットは１つしかなく、このフォーマットが電波で送信され、家庭にあるアンテナを介して受信された。これが進化して、例えばＳＤＴＶ（ｓｔａｎｄａｒｄ ｄｅｆｉｎｉｔｉｏｎ ｔｅｌｅｖｉｓｉｏｎ：標準画質テレビ）、ＥＤＴＶ（ｅｎｈａｎｃｅｄ ｄｅｆｉｎｉｔｉｏｎ ＴＶ）、およびＨＤＴＶ（ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ＴＶ：高精細度テレビジョン）のように画質の標準が多様化しただけでなく、ケーブルや衛星というように、これらの多様なテレビジョン表示フォーマットを配信するためのシステムも多様化した。さらに、これらの２つの業界の間で各種のサービスが成長してオーバラップするようになってきた。これらのシステムが両方の業界において進化し続けるにつれて、サービス提供は融合し続けるであろうし、消費者は新たなサービスの利用可能性を期待できよう。また、これらのサービスの一部は、より多くの情報を処理して出力するための技術的能力に基づくことが予想される。
【０００３】
通信業界と娯楽業界との両方に影響を与えるもう１つの関連技術は、相互接続ネットワークである。また、これらの通信ネットワークと関連の通信ストリームとの物理的構造の進化によって、より多量のデータフローを処理できるようになってきた。サーバは、かつてないほど多量のメモリを有し、これまで以上の高い帯域幅を有する通信リンクが存在し、プロセッサは以前より高速かつ高性能であり、そして、これらの要素を活用するプロトコルが存在する。これらの通信ネットワークは、ユーザと企業とを結びつけるものであれば、いかなるネットワークであってもよい。消費者によるこれらのネットワークの利用が増加すれば、この増加は、サービス提供のための、相互接続されうるより多くのネットワークの創造を促す可能性がある。これらのサービスには、例えば、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｔｅｌｅｖｉｓｉｏｎ：ＩＰデータパケットを用いるネットワーク経由でテレビ番組を配信するシステムまたはサービスのことを言う）と、インターネットラジオと、ビデオ・オン・デマンド（ＶｏＤ）と、ライブイベントと、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ：ＩＰ電話）と、その他の単独で受信されるかまたはバンドルで一緒に受信されるウェブ関連サービスとが含まれてもよい。また、技術革新とサービス拡大とに伴って、新たなネットワークと通信プロトコル、例えば、ＩＭＳ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ：ＩＰマルチメディア・サブシステム）ネットワークおよびＳＩＰ（ｓｅｓｓｉｏｎ ｉｎｉｔｉａｔｉｏｎ ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）が開発されて、これらの多様なサービスを改良し、それらの利用を進めた。
【０００４】
通信ネットワークの１つの特徴は、そのようなネットワークが多数存在し（それぞれがネットワークオペレータによって運用され）、そして、これらのネットワークが相互接続されていることである。この相互接続は、２つのネットワーク間で直接的であってもよいし、１つ以上の相互接続ネットワークまたは中継ネットワークを介して間接的であってもよい。これらのネットワークオペレータ各社は、その相互接続パートナ各社と業務上のＳＬＡ（サービス品質保証契約）を締結しているであろうし、１）宛先ユーザアドレスと、２）業務上のＳＬＡと、に基づいてルーティングの決定を行う装置を有するであろう。宛先ユーザアドレスは或るユーザを識別し、このユーザは或るネットワークオペレータによってサービス提供される。宛先ユーザアドレスは、電話番号であってもよいし、何らかの電子メールのような形式のＵＲＩ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ：ユニフォーム・リソース・アイデンティファイア）であってもよい。後者の場合、宛先ユーザアドレスは、例えばｊｏｈｎ＠ｂａｎｋ．ｃｏｍ、ｊｏｈｎ＠ｂａｌｄｗｉｎ．ｏｒｇのように、在圏ネットワークオペレータを即座に識別しないことがある。これは、要求をどうルーティングするかを発信側ネットワークオペレータが知ることの難しさを示す。
【０００５】
従って、多様な相互接続ネットワーク経由の通信を改良するためのデバイス、システム、および方法を提供することが望ましいであろう。
【発明の概要】
【０００６】
例示的実施形態によるシステムおよび方法が、とりわけ、多様な相互接続ネットワーク経由の通信を改良するための２層のアドレス指定スキームおよびルーティングスキームによって、このニーズなどに対応する。
【０００７】
例示的な一実施形態によれば、在圏ネットワーク経由で発信側ネットワークから宛先ユーザアドレスへ通信をルーティングする方法が、前記発信側ネットワークから、前記宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージを送信するステップと、前記発信側ネットワークにおいて、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する前記在圏ネットワークを識別する情報を含む応答メッセージを受信するステップと、前記発信側ネットワークにおいて、メッセージ中に、前記宛先ユーザアドレスに関連する前記宛先識別情報と前記在圏ネットワークを識別する前記情報とを組み込むステップと、前記発信側ネットワークから、前記メッセージを前記在圏ネットワークへ送信するステップと、を備える。
【０００８】
別の例示的実施形態によれば、通信ノードにおける、通信をルーティングするための方法が、各々が宛先ユーザアドレスに関連する複数の宛先識別情報および対応する在圏ネットワーク識別情報を記憶するステップであって、宛先ユーザアドレスに関連する各宛先識別情報が少なくとも１つの在圏ネットワークにも関連する、ステップと、宛先ユーザアドレスに関連する、前記複数の宛先識別情報のうちの１つを含むクエリメッセージを受信するステップと、前記宛先ユーザアドレスに関連する前記宛先識別情報を用いてルックアップを実行して前記対応する少なくとも１つの在圏ネットワークを判定するステップと、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する少なくとも１つの在圏ネットワークを識別する、前記ルックアップに基づく情報を含む応答メッセージを送信するステップと、を備える。
【０００９】
更に別の例示的実施形態によれば、通信ノードが、宛先ユーザアドレスに関連する宛先識別情報と、当該宛先ユーザアドレスに関連する当該宛先識別情報によって識別されるエンティティに対してサービスを提供する少なくとも１つの在圏オペレータネットワークと、の間のマッピングを記憶するメモリと、前記宛先ユーザアドレスに関連する前記宛先識別情報を受信する通信インタフェースと、前記宛先ユーザアドレスに関連する前記受信した宛先識別情報に関するルックアップを実行するプロセッサと、を備え、前記ルックアップは、セッション開始プロトコル（ＳＩＰ）メッセージ中で前記宛先ユーザアドレスに関連する前記宛先識別情報を含むクエリメッセージを前記通信インタフェースが受信した場合に、前記少なくとも１つの在圏オペレータネットワークを結果として返し、前記通信インタフェースは、前記少なくとも１つの在圏オペレータネットワークを含む応答メッセージを送信する。
【００１０】
添付の図面は、本明細書に組み込まれて本明細書の一部を構成するものであって、１つ以上の実施形態を図解し、記述と共にこれらの実施形態を説明する。
【図面の簡単な説明】
【００１１】
【図１】例示的実施形態による、通信ネットワークの枠組みを示す図である。
【図２】ＩＭＳ（インターネットプロトコル・マルチメディア・サブシステム）ネットワークの相互接続を図解する図である。
【図３（ａ）】加入相互接続のためのＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｉｏｎ） ＴＳ １８２ ０２５のアーキテクチャを示す図である。
【図３（ｂ）】ピアリング相互接続のためのＥＴＳＩ ＴＳ １８２ ０２５のアーキテクチャを示す図である。
【図４】例示的実施形態による、相互接続ネットワークを描いた図である。
【図５】例示的実施形態による、メッセージトラヒックをルーティングするためのシグナリング図である。
【図６】例示的実施形態による、１つの企業が２つの在圏オペレータネットワークに関連する場合の通信アーキテクチャを示す図である。
【図７】例示的実施形態による、メッセージトラヒックをルーティングするための複数の在圏オペレータの選択肢を伴う応答を含むシグナリング図である。
【図８】例示的実施形態による、通信ノードを示す図である。
【図９】例示的実施形態による、発信側ネットワークから通信をルーティングするためのフローチャートである。
【図１０】例示的実施形態による、通信ノードから通信をルーティングするためのフローチャートである。
【発明を実施するための形態】
【００１２】
例示的実施形態についての下記の記述は、添付の図面を参照する。別の図面における同じ参照番号は、同じかまたは類似の要素を示す。下記の詳細記述は、本発明を限定するものではない。そうではなく、本発明の範囲は、添付の請求項によって定義される。下記の実施形態は、話を簡単にするために、以下に記述する通信ネットワークの用語および構造に関して論じている。しかし、次に論じることになる実施形態は、これらのシステムに限定されるのではなく、他の既存の通信システムに適用されうる。
【００１３】
本明細書を通じて、「一実施形態」または「ある実施形態」または「例示的実施形態」への言及は、ある実施形態に関連して述べた特定の特徴、構造、または特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。従って、本明細書の全体を通じていろいろな箇所で「一実施形態では」または「ある実施形態では」または「例示的実施形態では」という表現があっても、必ずしもそれらすべてが同じ実施形態に言及しているとは限らない。また、特定の特徴、構造または特性が、１つ以上の実施形態においていずれかの適切なやり方で組み合わされてもよい。
【００１４】
上記のように、各種の相互接続ネットワーク経由の通信を改良するためのデバイス、システム、および方法を提供することが望ましい。以下の例示的実施形態は、メッセージ、例えばＳＩＰ（セッション開始プロトコル）メッセージを、多様な相互接続ネットワーク経由で、例えば、ＩＭＳ（インターネットプロトコル・マルチメディア・サブシステム）を用いるネットワーク経由で、ルーティングすることについて記述する。この議論について何らかの文脈を提供するために、図１に例示的な通信の枠組みを示す。
【００１５】
例示的実施形態によれば、図１は、複数の相互接続ネットワーク経由で中継される通信を使って、或るユーザが別のユーザ（または、企業内のリソース、例えば会社内のデバイスまたは人物）と通信することを示す。詳細には、例示的な通信の枠組み１００は、ユーザ１ １０２が、例えばＳＩＰメッセージを送信することができるデバイス、例えば移動電話およびコンピュータを使って企業／ユーザ２ １１０と通信することを示す。これらのＳＩＰメッセージは、最初に発信側ネットワーク１０４を通って、次いで１つ以上の中継ネットワーク１０６を通って、次いで在圏ネットワーク１０８を通って送信される。しかし、これらの多様なネットワーク、例えば各種のパブリック通信ネットワークおよび相互接続ネットワークにおいてそのようなメッセージをアドレス指定するのに用いられるＤＮＳ（ｄｏｍａｉｎ ｎａｍｅ ｓｙｓｔｅｍ：ドメイン・ネーム・システム）の規則に関して多様な提案が存在し、それが、今度は、これらのＳＩＰメッセージの正確かつ効率的な配信についての課題となる。また本書では、「発信側ネットワーク」、「発信側オペレータネットワーク」および「発信側ネットワークオペレータ」とは、呼を開始するデバイスが接続している発信側ネットワークのことを言う。また本書では、「在圏ネットワーク」、「在圏オペレータネットワーク」および「在圏ネットワークオペレータ」とは、エンドユーザにサービス提供し、呼を宅内ユーザまたは企業内ユーザに配信するネットワークのことを言う。
【００１６】
ＩＭＳネットワークを相互接続するための１つのありうる枠組みが、図２に示すようにＧＳＭＡ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ａｓｓｏｃｉａｔｉｏｎ）によって提案されている。このグローバルなサービスプロバイダ間のＩＰバックボーンは、典型的にはＩＰＸ（Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｐａｃｋｅｔ Ｅｘｃｈａｎｇｅ）と呼ばれ、ＧＳＭＡ ＩＲ．３４の中に記述されている。この枠組みの中には、オペレータＡ ２０２とオペレータＢ ２０４とが含まれ、それらはいずれもＩＰＸプロバイダＸ ２０８に接続しており、さらにオペレータＣ ２１４も含まれるが、こちらはＩＰＸプロバイダＹ ２１０に接続している。ＩＰＸプロバイダＸ ２０８およびＩＰＸプロバイダＹ ２１０は、ＩＰＸ２０６の一部であり、ＥＮＵＭ（Ｅｌｅｃｔｒｏｎｉｃ Ｎｕｍｂｅｒ Ｍａｐｐｉｎｇ Ｓｙｓｔｅｍ）を備えたＤＮＳ（ｄｏｍａｉｎ ｎａｍｅ ｓｙｓｔｅｍ）ルートデータベース２１２と通信する。ＩＰＸ２０６の１つの目的は、合意された共同利用できるサービス定義および業務契約、例えばＳＬＡ（サービス品質保証契約）に従ってサービスプロバイダ間の相互接続を円滑化することである。これを円滑化するために、ＩＰＸ２０６は、この通信の枠組みに複数の利害関係者を導入することによって、ＧＰＲＳ（ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅ）のアーキテクチャの上にＧＲＸ（ｒｏａｍｉｎｇ ｅｘｃｈａｎｇｅ）を構築してＧＰＲＳのアーキテクチャを拡張する。これらの利害関係者には、固定ネットワークオペレータ、インターネットサービスプロバイダ、およびアプリケーションサービスプロバイダが含まれうる。ＩＰＸ２０６は、メッセージトラヒックをルーティングする目的で、自分自身のＤＮＳインフラストラクチャを有すると想定され、その関連情報はＤＮＳルートデータベース２１２の中に記憶されうる。ＩＰＸに接続するオペレータのためのＧＳＭＡが定義したＤＮＳ命名規則は、ＭＮＣ（ｍｏｂｉｌｅ ｎｅｔｗｏｒｋ ｃｏｄｅ）とＭＣＣ（ｍｏｂｉｌｅ ｃｏｕｎｔｒｙ ｃｏｄｅ）とを利用することに基づいている。ＧＳＭＡ提案に基づくＳＩＰメッセージのための一意の識別情報の一例をあげると、以下のようであろう。
ｓｉｐ：＋４４７７０３１２３４５６＠ｍｎｃ００１．ｍｃｃ２３４．３ｇｐｐｎｅｔｗｏｒｋｓ．ｏｒｇ
【００１７】
ネットワークの相互接続のためのもう１つの提案が、ＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｉｏｎ）ＴＩＳＰＡＮ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｓ）ＮＧＮ（ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ ｎｅｔｗｏｒｋ：次世代ネットワーク）リリース２によって行われた。より詳細には、図３（ａ）に示すように、ＥＴＳＩ ＴＳ １８２ ０２５は、ビジネス・トランキング(business trunking)ＮＧＣＮ（ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ ｃｏｒｐｏｒａｔｅ ｎｅｔｗｏｒｋ：次世代企業ネットワーク）３０４が、加入に基づいて在圏オペレータのＩＭＳネットワーク３０２にどのようにして接続されうるかについてのアーキテクチャ３００を提供する。Ｇｍ参照ポイント３０６は、在圏オペレータのＩＭＳネットワーク３０２と企業ネットワークとの境界を示す。加入相互接続の場合、ＮＧＣＮ３０４は、ＩＭＳの文脈の中の単一ユーザとして実現され、ＮＧＣＮ３０４は、在圏オペレータのＩＭＳネットワーク３０２にユーザ登録を行うと想定される。次いで、在圏オペレータのＩＭＳネットワーク３０２は、ＣＳＣＦ（呼セッション制御機能）、例えばＳ−ＣＳＣＦ（サービングＣＳＣＦ）３１０およびＰ−ＣＳＣＦ（プロキシＣＳＣＦ）３０８、並びにＡＳ（アプリケーションサーバ）３１２を通してユーザにサービスを提供することができる。
【００１８】
ＥＴＳＩ ＴＳ １８２ ０２５は、その他のビジネスシナリオについて図３（ａ）に示すアーキテクチャの変形を可能にし、そしてそれを特定する。一例では、図３（ｂ）に示すように、ビジネス・トランキングＮＧＣＮが、加入協定の代わりにピアリング協定によって在圏オペレータのＩＭＳネットワーク３０２に接続する。ピアリング相互接続の場合、在圏オペレータのＩＭＳネットワーク３０２の中には、ＮＧＣＮ３０４についてのユーザがいない。代わりに、ＮＧＣＮ３０４は、在圏オペレータのＩＭＳネットワーク３０２の中で、ＩＢＣＦ（Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ：相互接続境界制御機能）３１４を通してルーティングされるセッション情報と共にＩＢＣＦ３１４によって示される。
【００１９】
Ｈｏｓｔｅｄ Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ（ホストされた企業サービス）ＮＧＣＮと呼ばれる別のケースでは、ＮＧＣＮ３０４の中の各ユーザが、在圏オペレータのＩＭＳネットワーク３０２の中の１人のユーザとして実現され、従って、ＮＧＣＮ３０４の中の各ユーザが、在圏オペレータのＩＭＳネットワーク３０２にユーザ登録し、ＣＳＣＦを通してサービスをルーティングしてもらうと想定される。また、大企業のネットワーク（または複数のネットワーク）については、ＮＧＣＮ３０４のサイトと在圏オペレータネットワーク（または各種の在圏オペレータネットワーク）との間のこれらの接続に複数の事例がある可能性があり、この場合、これらの接続の事例は、上記の３つのケースが混じり合ったものでありうる。
【００２０】
上述したこれらのケースの各々において、ＴＩＳＰＡＮアーキテクチャを用いてＳＩＰメッセージを通信することができ、それによってユーザは、ＲＦＣ（ｒｅｑｕｅｓｔ ｆｏｒ ｃｏｍｍｅｎｔｓ）３２６１の中で記述されたようにｓｉｐ：ｕｓｅｒ＠ｄｏｍａｉｎという形式のＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）によってアドレス指定されることができる。企業、例えば会社の場合には、ＵＲＩは、電子メールアドレスから導出することができ、例えば、ｓｉｐ：ｊｏｈｎ＠ｅｎｔｅｒｐｒｉｓｅ．ｃｏｍのように表されてもよいだろうし、あるいは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）−ＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇｅ）から導出することができ、例えばｓｉｐ：８５０１２３４＠ｅｎｔｅｒｐｒｉｓｅ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅのように表されてもよいだろう。その他の許容される選択肢には、宅内ユーザ、例えばｓｉｐ：ｊｏｈｎ＠ｂａｌｄｗｉｎ．ｏｒｇまたは、ユーザフレンドリーなオペレータ名、例えば、ｓｉｐ：ｊｏｈｎ＠ｔｅｌｉａ．ｓｅ等がある。
【００２１】
ＧＳＭＡおよびＴＩＳＰＡＮによって定義された、提案のネットワークアーキテクチャの文脈では、既存の標準および解決策は、ＲＦＣ３２６１に基づいて上記で示した形式のＳＩＰ ＵＲＩにアドレス指定されたセッションを発信側オペレータがどのようにルーティングできるかに関して、決定的とはいえない。この分野では、諸標準は、ＳＩＰ ＵＲＩにアドレス指定されたセッションをルーティングするため、ＤＮＳの使用を一般的に言及するが、それは、いろいろな理由で大規模な展開には不十分である。例えば、複数のネットワークが関与する場合、各ネットワークは、ＩＰＸ用に提案されたもののような共有ＤＮＳに接続するだけでなく、内部的なＤＮＳを有することがある。しかし、各種の標準は、これらの多様なＤＮＳがどのようにして設定され使用されることになるのかを記述していない。事態を一層複雑にするのだが、完全修飾ドメイン名（ｆｕｌｌｙ ｑｕａｌｉｆｉｅｄ ｄｏｍａｉｎ ｎａｍｅｓ：ＦＱＤＮ）がパブリックインターネット上に数千万も存在することを考えると、一意のアドレスの全体量は相互接続ネットワークでも同様となりうるだろうと想定されることから、スケーラビリティが問題である。これは、トラヒック、例えばＳＩＰトラヒックを複数の相互接続ネットワーク経由でルーティングするための課題となりうる。
【００２２】
加えて、オペレータ各社は、他のパブリックネットワークへの自社の相互接続の知識だけでなく、これらのネットワークオペレータ各社に対する相互接続合意に基づいてルーティングの決定をしたいと望むことが多い。この情報は、彼らのローカルなＤＮＳサーバや関連のインフラストラクチャによって完全に供給されるとは限らない。在圏ネットワークオペレータがＵＲＩから容易に導出できないＳＩＰ ＵＲＩも多い。例えば、ｓｉｐ：ｊｏｈｎ＠ｅｎｔｅｒｐｒｉｓｅ．ｃｏｍまたはｓｉｐ：ｊｏｈｎ＠ｂａｌｄｗｉｎ．ｏｒｇまたはｊｏｈｎ＠ｂｒａｎｄ＿ｎａｍｅ．ｃｏｍのようなＳＩＰ ＵＲＩには、在圏ネットワークオペレータが示されない。従って、特定のオペレータにメッセージをルーティングするのに複数のやり方がある場合、発信側オペレータがどの相互接続選択肢を用いるかという決定は、典型的には、企業ユーザまたは宅内ユーザにサービス提供しているオペレータの知識に基づいて行われうるだけである。また、電話セッションについての既存の課金モデルは、一部は発呼ユーザと被呼ユーザの地理的位置に基づき、そして多くの場合、一部は発呼ユーザと被呼ユーザにサービス提供するオペレータにも基づく。言い換えれば、オペレータ各社は、典型的には、着信側オペレータについての情報に基づいて課金の決定を行うことを望むのだが、それはｓｉｐ：ｊｏｈｎ＠ｅｎｔｅｒｐｒｉｓｅ．ｃｏｍまたはｓｉｐ：ｊｏｈｎ＠ｂａｌｄｗｉｎ．ｏｒｇのようなＳＩＰ ＵＲＩには示されない。従って、以下の例示的実施形態は、ＳＩＰ ＵＲＩにアドレス指定されたセッションが、複数のネットワークを通って正確な宛先までルーティングされることを可能にする、アドレス指定メカニズムとルーティングメカニズムとを提供する。
【００２３】
上記のように、これらの例示的実施形態についての一般的な文脈には、各種の通信ネットワークと在圏ネットワークとを含むオペレータネットワーク上の電話が含まれる。しかし、理解されるであろうが、本発明は、電話に限らず、いかなるタイプのメッセージをルーティングするのにも使用されうる。これらのネットワークは典型的には、多様な通信経路と、各種のネットワークを分離するＩＢＣＦと、に関する可能性を有するであろう。加えて、メッセージトラヒックが所望のエンドポイントに到達することができるように、これらの各種のネットワーク間で通信を転送するための必要な詳細を詳述するＳＬＡ（サービス品質保証契約）が作成されるであろうと予想される。一部の詳細には、サービス品質要件やコストを含んでもよいし、さらに、例えばネットワークを識別するためにネットワークによって用いられることになる合意済み形式のようなアドレス指定の規則が含まれてもよい。
【００２４】
例示的実施形態によれば、要求またはメッセージの所望のルーティング経路を（例えば発信側ネットワークが）判定するための解決策には、発信側ネットワークがデータベースにクエリを行って、メッセージのルーティングを判定するのに用いられる応答を受信することが含まれる。例えば、発信側ネットワークが、宛先ユーザアドレス、例えばｓｉｐ：ｊｏｈｎ＠ｂａｎｋ．ｃｏｍというＳＩＰ ＵＲＩを含むＳＩＰメッセージをユーザから受信すると仮定しよう。この発信側ネットワークは発信側ネットワークとして動作しているため、どの在圏ネットワークがサービスをｂａｎｋ．ｃｏｍに提供するのか分からず、従って、どこにメッセージを送信するのか分からない。次いで、発信側ネットワークが、何らかのタイプの宛先識別情報、例えばｓｉｐ：ｊｏｈｎ＠ｂａｎｋ．ｃｏｍ、またはｂａｎｋ．ｃｏｍ、または、宛先ユーザアドレスに関連するいずれかの他のタイプの宛先識別情報を使って、（マスタＤＮＳデータベースを含みうるであろう）在圏オペレータデータベースにクエリを行って、そして、在圏ネットワークを識別する情報、例えば在圏ネットワークのＦＱＤＮまたはその他の合意された識別情報を含む応答を受信する。
【００２５】
例示的実施形態によれば、この在圏オペレータデータベースは、典型的なネットワークレベルＤＮＳサーバより相当多くの情報を含むことが可能であり、例えば、在圏オペレータデータベースは、すべてのＦＱＤＮについての情報と、相互接続されている各種ネットワークについての情報とを含んでもよいだろう。それに比べて、ネットワークレベルＤＮＳは典型的には、共有の相互接続からのネットワークオペレータの入口ポイント(ingress points)についてのレコードを保持するだけであり、各種のオペレータまたはＩＰＸのようなグループによって運用される。従って、本書で議論されるネットワークレベルＤＮＳが、典型的にはネットワーク毎に用いられて、単一のオペレータネットワークについてドメイン名とＩＰアドレスとの間の翻訳を行うのに対し、本書で議論される在圏オペレータデータベースは、特に、特定のメッセージに関連する在圏ネットワークを識別するのに用いられる。その後、在圏オペレータデータベースからデータを受信した時点で、発信側ネットワークは、例えば、各種のネットワーク間の適切なＳＬＡと、コストと、トラヒック管理の検討材料とのうちのいずれか、または一部、または全部に基づいて、ルーティング経路を判定する。次いで、発信側ネットワークは、メッセージを在圏ネットワークに向けて送信し、そして、宛先ユーザアドレスと在圏オペレータを識別するための情報とを両方含める。このように宛先ユーザアドレスと在圏オペレータを識別するための情報とを両方共用いることは、２層のアドレス指定の一例である。
【００２６】
例示的実施形態によって、一企業（または複数の企業）および個人ユーザに通信をルーティングすることができる各種の相互接続ネットワークを図４に示す。この例示的通信の枠組みは、２つのオペレータネットワークであるＴｅｌｅ２ ４０２およびＴｅｌｉａ４０４と、ＩＰＸ４０６と、企業ネットワークであるＢａｎｋ４０８とを含む。ＳＢＧ（セッション境界ゲートウェイ）は典型的にはアクセスポイントであるが、同時に、各種のオペレータネットワークおよびＩＰＸ４０６に出入りする通信のためのファイアウォールとしても動作することができる。加えて、オペレータネットワークであるＴｅｌｅ２ ４０２およびＴｅｌｉａ４０４はそれぞれ、少なくともローカルに格納されたドメイン情報を有する、自分自身のネットワークレベルＤＮＳサーバ４２２および４２４（またはその同等物）を有する。在圏オペレータデータベース４１０は、ＩＰＸ４０６に関連するすべてのネットワークについてのＤＮＳ情報を含む。この例ではＩＰＸ４０６の中に位置しているが、在圏オペレータデータベース４１０は、オペレータネットワークに接続されていてそれらにアクセス可能ならばどこに存在してもよく、例えば、第三者の所在地に存在してもよい。在圏オペレータデータベース４１０に記憶されたＤＮＳ情報は、例を挙げれば、例えばＴｅｌｅ２ ４０２およびＴｅｌｉａ４０４のようなネットワークによって在圏オペレータデータベース４１０に報告された、各ネットワークによってサービス提供される住居や企業について記述する情報を含んでもよい。
【００２７】
企業ネットワークＢａｎｋ４０８は、各種のリソースおよび個人をアドレス可能な場所を表すＢａｎｋ Ｃｅｎｔｒｅｘ４１２と２つのＢａｎｋ ＰＢＸ４１４および４１６とを含む。ユーザ１ ４１８は、Ｔｅｌｅ２によってサービスを提供されるユーザを表し、ユーザ２ ４２０は、Ｂａｎｋ ＰＢＸ４１４に関連することが知られているＢａｎｋ４０８のために働いているユーザを表す。本書ではＢａｎｋ Ｃｅｎｔｒｅｘ４１２は、バーチャルＰＢＸであると考えられている。バーチャルＰＢＸは、典型的には小規模なリモートの企業拠点に関連付けられる。本書で記述する例示的実施形態において、在圏ネットワークは、通常のＰＢＸとバーチャルＰＢＸとをいずれも呼とメッセージとをエンドユーザに配信することについては同様に取り扱い、すなわち、本書で記述する例示的実施形態は、通常のＰＢＸとバーチャルなＰＢＸとのうちのいずれを利用するのかによって制約されない。
【００２８】
上記の例示的実施形態によれば、在圏オペレータデータベース４１０は、ユーザに関連する宛先識別情報と、それらの個別の在圏オペレータネットワークについての情報との両方に関連する情報を含む。在圏オペレータデータベース４１０は、この情報を用いてこれらの情報の集合間のマッピングを行うことができる。加えて、この情報は、さまざまなかたちで存在しうる。例えば、各種のネットワークおよびユーザを識別するのに、一般的なドメイン名、例えばｅｒｉｃｓｓｏｎ．ｃｏｍ、ｔｅｌｉａ．ｓｅ、ｂａｌｄｗｉｎ．ｏｒｇが用いられてもよいし、構造化された通信名、例えばｍｎｃ００１、ｍｃｃ２３４が用いられてもよい。また、在圏オペレータデータベース４１０は、一般的なドメイン名と、ｍｎｃやｍｃｃを用いる構造化された識別情報との間のマッピングを行ってもよい。
【００２９】
次に、図５に示すシグナリング図に関して、例示的実施形態によって、例えば図４に示す通信ネットワーク経由で呼をルーティングするメッセージについて記述しよう。最初に、ユーザ１ ４１８が、メッセージＩＮＶＩＴＥ ｓｉｐ：ｇｅｒｔ＠ｂａｎｋ．ｃｏｍ ５０２を、発信側オペレータネットワークとして動作するＴｅｌｅ２ ４０２に送信する。Ｔｅｌｅ２ ４０２は、どのネットワークがサービスをｂａｎｋ．ｃｏｍに提供するのか分からず、従って、「ｂａｎｋ．ｃｏｍ」（またはその翻訳バージョン）を含むクエリメッセージ５０４を在圏オペレータデータベース４１０に送信する。在圏オペレータデータベース４１０は、ルックアップを行って、「ｂａｎｋ．ｃｏｍ」がＴｅｌｉａ４０４によってサービス提供されることを見つけ、応答メッセージ５０６の一部として「ｖｐｎｓｅｒｖｉｃｅ＠ｔｅｌｉａ．ｓｅ」を送信する。Ｔｅｌｅ２ ４０２は、この情報を用いて、Ｔｅｌｅ２ ４０２とＴｅｌｉａ４０４との間の相互接続および契約、例えばＳＬＡに基づいてルーティング経路を判定する。
【００３０】
図４に示すように、Ｔｅｌｅ２ ４０２は、直接接続とＩＰＸ４０６経由との両方を通してＴｅｌｉａ４０４に接続している。この事例では、Ｔｅｌｅ２ ４０２は、「ＩＮＶＩＴＥ ｖｐｎｓｅｒｖｉｃｅ＠ｔｅｌｉａ．ｓｅ Ｔａｒｇｅｔ ｓｉｐ：ｇｅｒｔ＠ｂａｎｋ．ｃｏｍ」を含むメッセージ５０８で示すようにＩＰＸ４０６を通してトラヒックをルーティングすることを選ぶ。ＩＰＸ４０６は受信したメッセージ５０８の中の「ｔｅｌｉａ．ｓｅ」を見て、メッセージ５１０をＴｅｌｉａ４０４へルーティングする。次いでＴｅｌｉａ４０４は、「ＩＮＶＩＴＥ ｓｉｐ：ｇｅｒｔ＠ｂａｎｋ．ｃｏｍを含むメッセージ５１２をユーザ２ ４２０に送信する。
【００３１】
上記のように、上述したルーティング情報は、宛先アドレスと、例えばユーザまたは企業のような宛先にサービスを提供するネットワークについて記述する情報とを両方含む。後者の情報は、在圏オペレータデータベース４１０への発信側ネットワークのクエリへの応答を介して発信側ネットワークが利用できるようにされる。例示的実施形態によれば、ルーティング情報は、さまざまなやり方でＳＩＰメッセージに組み込むことができる。当業者であれば理解するであろうが、ＳＩＰメッセージは、Ｒｅｑｕｅｓｔ ＵＲＩとＴａｒｇｅｔ ＵＲＩヘッダとを両方含むことができる。例示的な一実施形態によれば、在圏オペレータＩＤ、例えばｔｅｌｉａ．ｓｅをＲｅｑｕｅｓｔ ＵＲＩに入れることができ、そして、宛先の元のＳＩＰ ＵＲＩ、例えばｇｅｒｔ＠ｂａｎｋ．ｃｏｍを、ＳＩＰメッセージのＴａｒｇｅｔ ＵＲＩヘッダに入れることができる。呼が在圏オペレータネットワークに到着すると、在圏オペレータは、Ｔａｒｇｅｔ ＵＲＩをＲｅｑｕｅｓｔ ＵＲＩに戻すように促し、呼をＮＧＣＮ３０４へとさらに配信させる。
【００３２】
別の例示的実施形態によれば、在圏オペレータＩＤを、Ｒｅｑｕｅｓｔ ＵＲＩに添付することができる（例えば、ｓｉｐ：ｊｏｈｎ＠ｅｎｔｅｒｐｒｉｓｅ．ｃｏｍ．ｍａｒｋｅｒ．ｍｎｃ１２３．ｍｃｃ２３４．３ｇｐｐｎｅｔｗｏｒｋｓ．ｏｒｇのように）。あるいは、新たなパラメータをＳＩＰ Ｒｅｑｕｅｓｔ ＵＲＩに入れることができる。例えば、在圏オペレータをパラメータとしてＳＩＰ Ｒｅｑｕｅｓｔ ＵＲＩに追加し、ｓｉｐ：ｊｏｈｎ＠ｅｎｔｅｒｐｒｉｘｅ．ｃｏｍ；ｓｏ＝ｍｎｃ１２３．ｍｃｃ２３４．３ｇｐｐｎｅｔｏｗｏｒｋｓ．ｏｒｇのようにすることができる。別の例示的実施形態によれば、情報をＲｅｑｕｅｓｔ ＵＲＩに添付するために上記で述べたのと同様のやり方でＲＮ（ルーティング番号）またはＴＲＧＰ（トランクグループパラメータ）のような他の既存のパラメータを拡張することによって、必要な在圏オペレータ情報を搬送することができる。
【００３３】
上記の例示的実施形態によれば、ＳＩＰメッセージの中で最初のＳＩＰ ＵＲＩと在圏オペレータＩＤとを両方搬送することによって、発信側ネットワークと中継／相互接続ネットワークとが、中枢の在圏オペレータデータベース４１０によって取得された在圏オペレータ識別情報に基づいてメッセージをルーティングすることが可能になる。従って、在圏オペレータネットワークルーティング情報は、中継／相互接続ネットワークが知っていて読み取ることができるＳＩＰメッセージについての通常のルーティング情報の一部として提供されるのだから、中継／相互接続ネットワークは、典型的には、企業または住宅用ＦＱＤＮについての情報を知る必要はないし、在圏オペレータデータベース４１０にクエリを行う必要もない。
【００３４】
例示的な一実施形態によれば、メッセージがその中を移動できる各種のネットワークはそれぞれ、典型的には、内部では別個のローカルＩＰアドレスを用いる。従って、ＩＰアドレスとＩＰアドレスを用いたルーティングとを求める従来のＤＮＳクエリは、典型的には、発信側オペレータネットワークから在圏ネットワークおよび宛先までルーティングするためには用いられない。加えて、ＩＰアドレスによるルーティングは、発信側ネットワークによって制御されない状態で使用ルートの選択を行う自動ルーティングであると考え得ることから、典型的には望まれない。これでは、発信側オペレータネットワークが経路を制御することができず、ＳＬＡに関する問題や、収入が最適にならないことにつながりうるであろう。
【００３５】
一企業について複数の在圏オペレータの事例
上記の例示的実施形態は、企業が単一の在圏オペレータネットワークによってサービス提供される場合にメッセージトラヒックをルーティングするためのシステムおよび方法を記述する。しかし、大企業については、ＮＧＣＮサイトと在圏オペレータネットワークとの間に複数の接続事例がありうる。例えば、大規模な企業ネットワークについては、企業は、企業の各部門が地理的に広域に位置していることや、ビジネス上の競合の理由等から、複数の在圏オペレータを望むことがある。例示的実施形態によって、企業が２つの異なる在圏オペレータネットワークを用いる通信の枠組みについて、図６に関して以下に述べる。
【００３６】
図６は、例示的な通信の枠組みを示すが、ここにはＩＰＸ４０６が含まれ、それが各種のオペレータネットワーク、例えばＴｅｌｉａ４０４、Ｔｅｌｅ２ ４０２、Ｊｅｒｓｅｙ Ｔｅｌ６０４、Ｇａｍｍａ Ｔｅｌ６０８に接続する。また、この例では、ＩＰＸ４０６は、一次ＤＮＳデータベース４１０を含むが、これは宛先のＦＱＤＮを、その宛先にサービスを提供する在圏ネットワークにマッピングするための情報を含む。企業Ｂａｎｋが、Ｔｅｌｉａ４０４によってサービス提供されるＢａｎｋ ＰＢＸ４１４と、Ｊｅｒｓｙ Ｔｅｌ６０４によってサービス提供されるＢａｎｋ ＰＢＸ６０２とで示すように、２つの異なる在圏オペレータネットワークによってサービス提供され、Ｂａｎｋ ＰＢＸ４１４とＢａｎｋ ＰＢＸ６０２とはＶＰＮ６０６によって接続される。さらに、ユーザ１ ４１８とユーザ２ ４２０とを示す。
【００３７】
次に、例示的実施形態によって、一企業について複数の在圏オペレータネットワークを有するケースについて図６に示すアーキテクチャを用いる、図７に示すようなシグナリングフローについて記述しよう。最初に、ユーザ１ ４１８が、「ＩＮＶＩＴＥ ｓｉｐ：ｇｅｒｔ＠ｂａｎｋ．ｃｏｍ」を含むメッセージ７０２を、発信側ネットワークとして動作するＴｅｌｅ２ ４０２に送信する。次いでＴｅｌｅ２ ４０２は、例えば「ｂａｎｋ．ｃｏｍ」や「ｇｅｒｔ＠ｂａｎｋ．ｃｏｍ」のような宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージ７０４を在圏オペレータデータベース４１０に送信する。在圏オペレータデータベース４１０は、ルックアップを行って、２つの在圏オペレータネットワーク、例えばｖｐｎｓｅｒｖｉｃｅ＠ｔｅｌｉａ．ｓｅやｖｐｎｓｅｒｖｉｃｅ＠ｊｅｒｓｅｙ．ｕｋについての識別情報を含む応答メッセージ７０６を送信する。次いでＴｅｌｅ２ ４０２は、どの在圏オペレータネットワークに要求を送信し、要求をどのようにルーティングするかを決定する。これらの決定は、既知の相互接続、ＳＬＡ、地理的位置、コスト、その他の関連情報に基づいて行われてもよい。これらの決定に基づいて、Ｔｅｌｅ２ ４０２は、「ＩＮＶＩＴＥ ｖｐｎｓｅｒｖｉｃｅ＠ｔｅｌｉａ．ｓｅおよびＴａｒｇｅｔ ｓｉｐ：ｇｅｒｔ＠ｂａｎｋ．ｃｏｍ」を含むメッセージ７０８をＩＰＸ４０６に送信する。ＩＰＸ４０６は、自分が必要とするルーティング情報、例えばｔｅｌｉａ．ｓｅが分かり、そして、メッセージ７１０に示すように、メッセージをＴｅｌｉａ４０４に転送する。ついでＴｅｌｉａ４０４は、メッセージの内容をよく調査して、それらを、ｇｅｒｔ＠ｂａｎｋ．ｃｏｍであることが分かっているユーザ２ ４２０に転送する。
【００３８】
上記のように、企業は、その企業の異なる部門について各種の在圏オペレータネットワークを有することがある。例示的実施形態によれば、すべての在圏オペレータネットワークが、対応する識別情報またはルーティング情報を在圏オペレータデータベース４１０の中に記憶しておく必要はない。加えて、クエリメッセージ７０４に応じて、在圏オペレータデータベース４１０の中に記憶された１つの、または少数の、またはすべての在圏オペレータネットワークが、応答メッセージ７０６の中で返信されてもよい。応答メッセージ７０６の中で用いられる在圏オペレータネットワークは、在圏オペレータネットワークと企業との間で事前に定められ、それに従って一次ＤＮＳデータベース４１０に記憶されてもよい。
【００３９】
例示的実施形態によれば、不適切な在圏オペレータネットワークがメッセージを受信した場合、すなわち、在圏オペレータネットワークがそのメッセージについてはその宛先にサービス提供しないと判定する場合、システムと方法とを用いてメッセージを別の在圏オペレータネットワークにさらにルーティングすることができる。ある場合には、例えば、宅内ユーザが企業に電話をかけることによって、呼がパブリックネットワークにおいて開始される。発信側オペレータネットワークが、（そのクエリによって受信された）複数の在圏オペレータのうちの１つを選択し、呼をその在圏オペレータに配信した。しかし、これは実際には、当該ユーザにとっては不適切な在圏オペレータであった。在圏オペレータネットワークは、企業にクエリを行うことができ、例えば企業内のデータベースにルーティングについての指示を求めるクエリを行って、次いで、上記の２層のアドレス指定スキームを用いて呼を正しい在圏オペレータネットワークにルーティングすることができる。
【００４０】
別の例示的実施形態によれば、呼は、企業内で、例えば企業ユーザが別の企業ユーザに対して開始することができる。宛先企業ユーザは、発信企業ユーザとは別の在圏ネットワークオペレータによってサービス提供される企業ネットワークの一部である。この場合、これはオンネット・コールとして知られるものだが、呼は、各種の相互接続ネットワークを経て正しい在圏オペレータネットワークにルーティングされる必要がある。また、上記の２層のアドレス指定スキームを用いてこの呼を正しい在圏オペレータに転送することもできる。
【００４１】
ドメイン名ポータビリティ
例示的実施形態によれば、上記のシステムおよび方法の実装によって、ドメイン名ポータビリティが可能になる。本書ではドメイン名ポータビリティとは、ユーザまたは企業のドメインを、１つの在圏オペレータから別の在圏オペレータに最小限のオーバーヘッドまたは作業で移動させることを言う。例えば、上記のように、これらの例示的実施形態で用いられる在圏オペレータデータベース４１０は、各ネットワークで用いられる典型的なネットワークレベルのＤＮＳデータベース４２２、４２４とは別である。この在圏オペレータデータベース４１０は、在圏オペレータデータベース４１０のプロバイダと各ネットワークオペレータとによって定められたように各ネットワークによって更新されるが、更新は変更が行われる時にタイムリーに行われることが望ましく、それによってドメイン名ポータビリティが円滑化される。
【００４２】
例えば、企業Ｂａｎｋ４０８が、Ｔｅｌｉａ４０４を自社のサービスプロバイダとして用いていると仮定する。次いで、企業Ｂａｎｋ４０８は、自社のサービスプロバイダとしてＴｅｌｅ２ ４０２に変更することを決め、すなわち、Ｂａｎｋ４０８から在圏ネットワークへの接続ポイントが、新たな在圏ネットワークに変更されるが、Ｂａｎｋ４０８の中の内部アドレス指定は典型的には変更されず、例えば個別のＳＩＰ ＵＲＩ、内線番号、直通電話番号（ｄｉｒｅｃｔ ｄｉａｌｉｎｇ ｉｎｗａｒｄｓ：ＤＤＩ）は以前と同じであろう。次いで、この変更が行われた後、Ｔｅｌｅ２ ４０２は、その変更について、在圏オペレータデータベース４１０を更新する。典型的には、２つのネットワークがこの変更によって直接影響を受ける場合を除き、ＤＮＳインフラストラクチャの低い方のレベルでは変更が行われる必要はない。また、Ｂａｎｋ４０８のネットワーク構造の範囲内での内部変更は、大部分は、修正される必要はないだろう。また、このプロセスは、住宅用についても当てはまるであろう。例えば、ユーザがｇｅｒｔ＠ｂａｌｄｗｉｎ．ｏｒｇというドメイン名を有していて、在圏オペレータネットワークを変更した場合、ドメイン名は、新たな在圏オペレータネットワークへ持ち運ぶことができるであろうし、依然としてｇｅｒｔ＠ｂａｌｄｗｉｎ．ｃｏｍへのシームレスな移行により使用することができるであろう。
【００４３】
上述の例示的実施形態は、相互接続ネットワーク（例えば、相互接続ＩＭＳネットワーク）経由でトラヒックをルーティングするために使用される在圏オペレータネットワークと照合される宛先アドレス情報を記憶するために、在圏オペレータデータベース４１０を使用する方法およびシステムを図解する。ここで、図８に関して、在圏オペレータデータベース４１０を表す例示的通信ノード８００を説明する。通信ノード８００は、プロセッサ８０２（または複数のプロセッサコア）と、メモリ８０４と、１つ以上の二次ストレージデバイス８０６と、通信を円滑化する通信インタフェースユニット８０８とを含むことができる。メモリ８０４（または二次ストレージデバイス８０６）は、宛先アドレス（例えば、ＦＱＤＮ）およびこれらの宛先にサービス提供する在圏オペレータネットワークに関するストレージとして使用可能である。それゆえ、例示的実施形態による通信ノード８００は、クエリを受信し、宛先に関連する在圏オペレータネットワーク（または複数のネットワーク）を返すことができる。加えて、通信ノード８００は、上記の各種の通信ネットワークにおけるその他のノード、例えばネットワークレベル（ローカル）ＤＮＳサーバ、またはＤＮＳサーバおよび在圏オペレータデータベース４１０の組み合わせ、の機能を実行することができる。
【００４４】
例示的実施形態による上述の例示的システムを利用して、通信をルーティングするための方法を図９のフローチャートに示す。最初に、在圏ネットワーク経由で発信側ネットワークから宛先ユーザアドレスへ通信をルーティングする方法は、ステップ９０２において、前記発信側ネットワークから、前記宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージを送信するステップと、ステップ９０４において、前記発信側ネットワークにおいて、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する前記在圏ネットワークを特定する情報を含む応答メッセージを受信するステップと、ステップ９０６において、前記発信側ネットワークにおいて、メッセージ中に、前記宛先ユーザアドレスに関連する前記宛先識別情報と前記在圏ネットワークを特定する前記情報とを組み込むステップと、ステップ９０８において、前記発信側ネットワークから、前記メッセージを前記在圏ネットワークへ送信するステップと、を備える。
【００４５】
例示的実施形態による上述の例示的システムを利用して、通信をルーティングするための方法を図１０のフローチャートに示す。最初に、通信ノードにおける、通信をルーティングするための方法は、ステップ１００２において、各々が宛先ユーザアドレスに関連する複数の宛先識別情報および対応する在圏ネットワーク識別情報を記憶するステップであって、前記宛先ユーザアドレスに関連する各宛先識別情報が少なくとも１つの在圏ネットワークにも関連する、ステップと、ステップ１００４において、宛先ユーザアドレスに関連する、前記複数の宛先識別情報のうちの１つを含むクエリメッセージを受信するステップと、ステップ１００６において、宛先ユーザアドレスに関連する前記宛先識別情報を用いてルックアップを実行して前記対応する少なくとも１つの在圏ネットワークを判定するステップと、ステップ１００６において、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する少なくとも１つの在圏ネットワークを特定する、前記ルックアップに基づく情報を含む応答メッセージを送信するステップと、を備える。
【００４６】
上記で開示した例示的実施形態は、相互接続ネットワークを経てメッセージトラヒックをルーティングすることに関連するシステムおよび方法について記述する。理解されるべきだが、この記述は、本発明を限定することを意図していない。例えば、上述の例示的実施形態は、各々が移動電話を使用している２人の別個のユーザ間で相互接続ＩＭＳネットワーク経由で呼をルーティングするために実装可能である。対照的に、例示的実施形態は、代替形態、修正形態、均等形態をカバーすることが意図されており、それらは添付の請求項によって定義されるように本発明の精神と範囲に含まれる。さらに、例示的実施形態の詳細記述において、請求された本発明の完全な理解を提供することを目的として多数の個別の詳細が記述されている。しかし、当業者であれば、そのような個別の詳細がなくても各種の実施形態が実施されうることを理解するであろう。
【００４７】
本書の例示的実施形態の特徴および要素は、特定の組み合わせにおける実施形態として記述されているけれども、それぞれの特徴または要素は、実施形態のその他の特徴および要素なしに単独で用いられてもよいし、本書で開示した他の特徴および要素と共にかまたはそれらなしに各種の組み合わせで用いられてもよい。本願で提供した方法またはフローチャートは、汎用コンピュータまたはプロセッサによって実行するための、コンピュータ可読記録媒体に収録されるコンピュータプログラム、ソフトウェア、またはファームウェアとして実装されてもよい。
【技術分野】
【０００１】
本書の例示的実施形態は、一般にシステムとデバイスとソフトウェアと方法とに関し、より詳細には、相互接続ネットワークを通ってメッセージをルーティングするためのメカニズムおよび技法に関する。
【背景技術】
【０００２】
技術的能力が拡大を続けるのにつれて、通信の選択肢は多様化してきた。例えば、この３０年余りの間に通信業界では個人間の通信が進化し、以前は家庭にダイヤル式電話が１台しかなかったのに、今では家庭には電話とケーブルと、および／または、音声とデータとの両方に対応する光ファイバ回線とが複数ある。さらに、携帯電話およびＷｉ−Ｆｉによって、通信に移動要素が加わった。同様に娯楽業界では、３０年前にはテレビ用のフォーマットは１つしかなく、このフォーマットが電波で送信され、家庭にあるアンテナを介して受信された。これが進化して、例えばＳＤＴＶ（ｓｔａｎｄａｒｄ ｄｅｆｉｎｉｔｉｏｎ ｔｅｌｅｖｉｓｉｏｎ：標準画質テレビ）、ＥＤＴＶ（ｅｎｈａｎｃｅｄ ｄｅｆｉｎｉｔｉｏｎ ＴＶ）、およびＨＤＴＶ（ｈｉｇｈ ｄｅｆｉｎｉｔｉｏｎ ＴＶ：高精細度テレビジョン）のように画質の標準が多様化しただけでなく、ケーブルや衛星というように、これらの多様なテレビジョン表示フォーマットを配信するためのシステムも多様化した。さらに、これらの２つの業界の間で各種のサービスが成長してオーバラップするようになってきた。これらのシステムが両方の業界において進化し続けるにつれて、サービス提供は融合し続けるであろうし、消費者は新たなサービスの利用可能性を期待できよう。また、これらのサービスの一部は、より多くの情報を処理して出力するための技術的能力に基づくことが予想される。
【０００３】
通信業界と娯楽業界との両方に影響を与えるもう１つの関連技術は、相互接続ネットワークである。また、これらの通信ネットワークと関連の通信ストリームとの物理的構造の進化によって、より多量のデータフローを処理できるようになってきた。サーバは、かつてないほど多量のメモリを有し、これまで以上の高い帯域幅を有する通信リンクが存在し、プロセッサは以前より高速かつ高性能であり、そして、これらの要素を活用するプロトコルが存在する。これらの通信ネットワークは、ユーザと企業とを結びつけるものであれば、いかなるネットワークであってもよい。消費者によるこれらのネットワークの利用が増加すれば、この増加は、サービス提供のための、相互接続されうるより多くのネットワークの創造を促す可能性がある。これらのサービスには、例えば、ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｔｅｌｅｖｉｓｉｏｎ：ＩＰデータパケットを用いるネットワーク経由でテレビ番組を配信するシステムまたはサービスのことを言う）と、インターネットラジオと、ビデオ・オン・デマンド（ＶｏＤ）と、ライブイベントと、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ：ＩＰ電話）と、その他の単独で受信されるかまたはバンドルで一緒に受信されるウェブ関連サービスとが含まれてもよい。また、技術革新とサービス拡大とに伴って、新たなネットワークと通信プロトコル、例えば、ＩＭＳ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ：ＩＰマルチメディア・サブシステム）ネットワークおよびＳＩＰ（ｓｅｓｓｉｏｎ ｉｎｉｔｉａｔｉｏｎ ｐｒｏｔｏｃｏｌ：セッション開始プロトコル）が開発されて、これらの多様なサービスを改良し、それらの利用を進めた。
【０００４】
通信ネットワークの１つの特徴は、そのようなネットワークが多数存在し（それぞれがネットワークオペレータによって運用され）、そして、これらのネットワークが相互接続されていることである。この相互接続は、２つのネットワーク間で直接的であってもよいし、１つ以上の相互接続ネットワークまたは中継ネットワークを介して間接的であってもよい。これらのネットワークオペレータ各社は、その相互接続パートナ各社と業務上のＳＬＡ（サービス品質保証契約）を締結しているであろうし、１）宛先ユーザアドレスと、２）業務上のＳＬＡと、に基づいてルーティングの決定を行う装置を有するであろう。宛先ユーザアドレスは或るユーザを識別し、このユーザは或るネットワークオペレータによってサービス提供される。宛先ユーザアドレスは、電話番号であってもよいし、何らかの電子メールのような形式のＵＲＩ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ：ユニフォーム・リソース・アイデンティファイア）であってもよい。後者の場合、宛先ユーザアドレスは、例えばｊｏｈｎ＠ｂａｎｋ．ｃｏｍ、ｊｏｈｎ＠ｂａｌｄｗｉｎ．ｏｒｇのように、在圏ネットワークオペレータを即座に識別しないことがある。これは、要求をどうルーティングするかを発信側ネットワークオペレータが知ることの難しさを示す。
【０００５】
従って、多様な相互接続ネットワーク経由の通信を改良するためのデバイス、システム、および方法を提供することが望ましいであろう。
【発明の概要】
【０００６】
例示的実施形態によるシステムおよび方法が、とりわけ、多様な相互接続ネットワーク経由の通信を改良するための２層のアドレス指定スキームおよびルーティングスキームによって、このニーズなどに対応する。
【０００７】
例示的な一実施形態によれば、在圏ネットワーク経由で発信側ネットワークから宛先ユーザアドレスへ通信をルーティングする方法が、前記発信側ネットワークから、前記宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージを送信するステップと、前記発信側ネットワークにおいて、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する前記在圏ネットワークを識別する情報を含む応答メッセージを受信するステップと、前記発信側ネットワークにおいて、メッセージ中に、前記宛先ユーザアドレスに関連する前記宛先識別情報と前記在圏ネットワークを識別する前記情報とを組み込むステップと、前記発信側ネットワークから、前記メッセージを前記在圏ネットワークへ送信するステップと、を備える。
【０００８】
別の例示的実施形態によれば、通信ノードにおける、通信をルーティングするための方法が、各々が宛先ユーザアドレスに関連する複数の宛先識別情報および対応する在圏ネットワーク識別情報を記憶するステップであって、宛先ユーザアドレスに関連する各宛先識別情報が少なくとも１つの在圏ネットワークにも関連する、ステップと、宛先ユーザアドレスに関連する、前記複数の宛先識別情報のうちの１つを含むクエリメッセージを受信するステップと、前記宛先ユーザアドレスに関連する前記宛先識別情報を用いてルックアップを実行して前記対応する少なくとも１つの在圏ネットワークを判定するステップと、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する少なくとも１つの在圏ネットワークを識別する、前記ルックアップに基づく情報を含む応答メッセージを送信するステップと、を備える。
【０００９】
更に別の例示的実施形態によれば、通信ノードが、宛先ユーザアドレスに関連する宛先識別情報と、当該宛先ユーザアドレスに関連する当該宛先識別情報によって識別されるエンティティに対してサービスを提供する少なくとも１つの在圏オペレータネットワークと、の間のマッピングを記憶するメモリと、前記宛先ユーザアドレスに関連する前記宛先識別情報を受信する通信インタフェースと、前記宛先ユーザアドレスに関連する前記受信した宛先識別情報に関するルックアップを実行するプロセッサと、を備え、前記ルックアップは、セッション開始プロトコル（ＳＩＰ）メッセージ中で前記宛先ユーザアドレスに関連する前記宛先識別情報を含むクエリメッセージを前記通信インタフェースが受信した場合に、前記少なくとも１つの在圏オペレータネットワークを結果として返し、前記通信インタフェースは、前記少なくとも１つの在圏オペレータネットワークを含む応答メッセージを送信する。
【００１０】
添付の図面は、本明細書に組み込まれて本明細書の一部を構成するものであって、１つ以上の実施形態を図解し、記述と共にこれらの実施形態を説明する。
【図面の簡単な説明】
【００１１】
【図１】例示的実施形態による、通信ネットワークの枠組みを示す図である。
【図２】ＩＭＳ（インターネットプロトコル・マルチメディア・サブシステム）ネットワークの相互接続を図解する図である。
【図３（ａ）】加入相互接続のためのＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｉｏｎ） ＴＳ １８２ ０２５のアーキテクチャを示す図である。
【図３（ｂ）】ピアリング相互接続のためのＥＴＳＩ ＴＳ １８２ ０２５のアーキテクチャを示す図である。
【図４】例示的実施形態による、相互接続ネットワークを描いた図である。
【図５】例示的実施形態による、メッセージトラヒックをルーティングするためのシグナリング図である。
【図６】例示的実施形態による、１つの企業が２つの在圏オペレータネットワークに関連する場合の通信アーキテクチャを示す図である。
【図７】例示的実施形態による、メッセージトラヒックをルーティングするための複数の在圏オペレータの選択肢を伴う応答を含むシグナリング図である。
【図８】例示的実施形態による、通信ノードを示す図である。
【図９】例示的実施形態による、発信側ネットワークから通信をルーティングするためのフローチャートである。
【図１０】例示的実施形態による、通信ノードから通信をルーティングするためのフローチャートである。
【発明を実施するための形態】
【００１２】
例示的実施形態についての下記の記述は、添付の図面を参照する。別の図面における同じ参照番号は、同じかまたは類似の要素を示す。下記の詳細記述は、本発明を限定するものではない。そうではなく、本発明の範囲は、添付の請求項によって定義される。下記の実施形態は、話を簡単にするために、以下に記述する通信ネットワークの用語および構造に関して論じている。しかし、次に論じることになる実施形態は、これらのシステムに限定されるのではなく、他の既存の通信システムに適用されうる。
【００１３】
本明細書を通じて、「一実施形態」または「ある実施形態」または「例示的実施形態」への言及は、ある実施形態に関連して述べた特定の特徴、構造、または特性が、本発明の少なくとも１つの実施形態に含まれることを意味する。従って、本明細書の全体を通じていろいろな箇所で「一実施形態では」または「ある実施形態では」または「例示的実施形態では」という表現があっても、必ずしもそれらすべてが同じ実施形態に言及しているとは限らない。また、特定の特徴、構造または特性が、１つ以上の実施形態においていずれかの適切なやり方で組み合わされてもよい。
【００１４】
上記のように、各種の相互接続ネットワーク経由の通信を改良するためのデバイス、システム、および方法を提供することが望ましい。以下の例示的実施形態は、メッセージ、例えばＳＩＰ（セッション開始プロトコル）メッセージを、多様な相互接続ネットワーク経由で、例えば、ＩＭＳ（インターネットプロトコル・マルチメディア・サブシステム）を用いるネットワーク経由で、ルーティングすることについて記述する。この議論について何らかの文脈を提供するために、図１に例示的な通信の枠組みを示す。
【００１５】
例示的実施形態によれば、図１は、複数の相互接続ネットワーク経由で中継される通信を使って、或るユーザが別のユーザ（または、企業内のリソース、例えば会社内のデバイスまたは人物）と通信することを示す。詳細には、例示的な通信の枠組み１００は、ユーザ１ １０２が、例えばＳＩＰメッセージを送信することができるデバイス、例えば移動電話およびコンピュータを使って企業／ユーザ２ １１０と通信することを示す。これらのＳＩＰメッセージは、最初に発信側ネットワーク１０４を通って、次いで１つ以上の中継ネットワーク１０６を通って、次いで在圏ネットワーク１０８を通って送信される。しかし、これらの多様なネットワーク、例えば各種のパブリック通信ネットワークおよび相互接続ネットワークにおいてそのようなメッセージをアドレス指定するのに用いられるＤＮＳ（ｄｏｍａｉｎ ｎａｍｅ ｓｙｓｔｅｍ：ドメイン・ネーム・システム）の規則に関して多様な提案が存在し、それが、今度は、これらのＳＩＰメッセージの正確かつ効率的な配信についての課題となる。また本書では、「発信側ネットワーク」、「発信側オペレータネットワーク」および「発信側ネットワークオペレータ」とは、呼を開始するデバイスが接続している発信側ネットワークのことを言う。また本書では、「在圏ネットワーク」、「在圏オペレータネットワーク」および「在圏ネットワークオペレータ」とは、エンドユーザにサービス提供し、呼を宅内ユーザまたは企業内ユーザに配信するネットワークのことを言う。
【００１６】
ＩＭＳネットワークを相互接続するための１つのありうる枠組みが、図２に示すようにＧＳＭＡ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ａｓｓｏｃｉａｔｉｏｎ）によって提案されている。このグローバルなサービスプロバイダ間のＩＰバックボーンは、典型的にはＩＰＸ（Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｐａｃｋｅｔ Ｅｘｃｈａｎｇｅ）と呼ばれ、ＧＳＭＡ ＩＲ．３４の中に記述されている。この枠組みの中には、オペレータＡ ２０２とオペレータＢ ２０４とが含まれ、それらはいずれもＩＰＸプロバイダＸ ２０８に接続しており、さらにオペレータＣ ２１４も含まれるが、こちらはＩＰＸプロバイダＹ ２１０に接続している。ＩＰＸプロバイダＸ ２０８およびＩＰＸプロバイダＹ ２１０は、ＩＰＸ２０６の一部であり、ＥＮＵＭ（Ｅｌｅｃｔｒｏｎｉｃ Ｎｕｍｂｅｒ Ｍａｐｐｉｎｇ Ｓｙｓｔｅｍ）を備えたＤＮＳ（ｄｏｍａｉｎ ｎａｍｅ ｓｙｓｔｅｍ）ルートデータベース２１２と通信する。ＩＰＸ２０６の１つの目的は、合意された共同利用できるサービス定義および業務契約、例えばＳＬＡ（サービス品質保証契約）に従ってサービスプロバイダ間の相互接続を円滑化することである。これを円滑化するために、ＩＰＸ２０６は、この通信の枠組みに複数の利害関係者を導入することによって、ＧＰＲＳ（ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｅｒｖｉｃｅ）のアーキテクチャの上にＧＲＸ（ｒｏａｍｉｎｇ ｅｘｃｈａｎｇｅ）を構築してＧＰＲＳのアーキテクチャを拡張する。これらの利害関係者には、固定ネットワークオペレータ、インターネットサービスプロバイダ、およびアプリケーションサービスプロバイダが含まれうる。ＩＰＸ２０６は、メッセージトラヒックをルーティングする目的で、自分自身のＤＮＳインフラストラクチャを有すると想定され、その関連情報はＤＮＳルートデータベース２１２の中に記憶されうる。ＩＰＸに接続するオペレータのためのＧＳＭＡが定義したＤＮＳ命名規則は、ＭＮＣ（ｍｏｂｉｌｅ ｎｅｔｗｏｒｋ ｃｏｄｅ）とＭＣＣ（ｍｏｂｉｌｅ ｃｏｕｎｔｒｙ ｃｏｄｅ）とを利用することに基づいている。ＧＳＭＡ提案に基づくＳＩＰメッセージのための一意の識別情報の一例をあげると、以下のようであろう。
ｓｉｐ：＋４４７７０３１２３４５６＠ｍｎｃ００１．ｍｃｃ２３４．３ｇｐｐｎｅｔｗｏｒｋｓ．ｏｒｇ
【００１７】
ネットワークの相互接続のためのもう１つの提案が、ＥＴＳＩ（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｉｏｎ）ＴＩＳＰＡＮ（Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ａｄｖａｎｃｅｄ Ｎｅｔｗｏｒｋｓ）ＮＧＮ（ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ ｎｅｔｗｏｒｋ：次世代ネットワーク）リリース２によって行われた。より詳細には、図３（ａ）に示すように、ＥＴＳＩ ＴＳ １８２ ０２５は、ビジネス・トランキング(business trunking)ＮＧＣＮ（ｎｅｘｔ ｇｅｎｅｒａｔｉｏｎ ｃｏｒｐｏｒａｔｅ ｎｅｔｗｏｒｋ：次世代企業ネットワーク）３０４が、加入に基づいて在圏オペレータのＩＭＳネットワーク３０２にどのようにして接続されうるかについてのアーキテクチャ３００を提供する。Ｇｍ参照ポイント３０６は、在圏オペレータのＩＭＳネットワーク３０２と企業ネットワークとの境界を示す。加入相互接続の場合、ＮＧＣＮ３０４は、ＩＭＳの文脈の中の単一ユーザとして実現され、ＮＧＣＮ３０４は、在圏オペレータのＩＭＳネットワーク３０２にユーザ登録を行うと想定される。次いで、在圏オペレータのＩＭＳネットワーク３０２は、ＣＳＣＦ（呼セッション制御機能）、例えばＳ−ＣＳＣＦ（サービングＣＳＣＦ）３１０およびＰ−ＣＳＣＦ（プロキシＣＳＣＦ）３０８、並びにＡＳ（アプリケーションサーバ）３１２を通してユーザにサービスを提供することができる。
【００１８】
ＥＴＳＩ ＴＳ １８２ ０２５は、その他のビジネスシナリオについて図３（ａ）に示すアーキテクチャの変形を可能にし、そしてそれを特定する。一例では、図３（ｂ）に示すように、ビジネス・トランキングＮＧＣＮが、加入協定の代わりにピアリング協定によって在圏オペレータのＩＭＳネットワーク３０２に接続する。ピアリング相互接続の場合、在圏オペレータのＩＭＳネットワーク３０２の中には、ＮＧＣＮ３０４についてのユーザがいない。代わりに、ＮＧＣＮ３０４は、在圏オペレータのＩＭＳネットワーク３０２の中で、ＩＢＣＦ（Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｂｏｒｄｅｒ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ：相互接続境界制御機能）３１４を通してルーティングされるセッション情報と共にＩＢＣＦ３１４によって示される。
【００１９】
Ｈｏｓｔｅｄ Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｉｃｅ（ホストされた企業サービス）ＮＧＣＮと呼ばれる別のケースでは、ＮＧＣＮ３０４の中の各ユーザが、在圏オペレータのＩＭＳネットワーク３０２の中の１人のユーザとして実現され、従って、ＮＧＣＮ３０４の中の各ユーザが、在圏オペレータのＩＭＳネットワーク３０２にユーザ登録し、ＣＳＣＦを通してサービスをルーティングしてもらうと想定される。また、大企業のネットワーク（または複数のネットワーク）については、ＮＧＣＮ３０４のサイトと在圏オペレータネットワーク（または各種の在圏オペレータネットワーク）との間のこれらの接続に複数の事例がある可能性があり、この場合、これらの接続の事例は、上記の３つのケースが混じり合ったものでありうる。
【００２０】
上述したこれらのケースの各々において、ＴＩＳＰＡＮアーキテクチャを用いてＳＩＰメッセージを通信することができ、それによってユーザは、ＲＦＣ（ｒｅｑｕｅｓｔ ｆｏｒ ｃｏｍｍｅｎｔｓ）３２６１の中で記述されたようにｓｉｐ：ｕｓｅｒ＠ｄｏｍａｉｎという形式のＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）によってアドレス指定されることができる。企業、例えば会社の場合には、ＵＲＩは、電子メールアドレスから導出することができ、例えば、ｓｉｐ：ｊｏｈｎ＠ｅｎｔｅｒｐｒｉｓｅ．ｃｏｍのように表されてもよいだろうし、あるいは、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）−ＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇｅ）から導出することができ、例えばｓｉｐ：８５０１２３４＠ｅｎｔｅｒｐｒｉｓｅ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅのように表されてもよいだろう。その他の許容される選択肢には、宅内ユーザ、例えばｓｉｐ：ｊｏｈｎ＠ｂａｌｄｗｉｎ．ｏｒｇまたは、ユーザフレンドリーなオペレータ名、例えば、ｓｉｐ：ｊｏｈｎ＠ｔｅｌｉａ．ｓｅ等がある。
【００２１】
ＧＳＭＡおよびＴＩＳＰＡＮによって定義された、提案のネットワークアーキテクチャの文脈では、既存の標準および解決策は、ＲＦＣ３２６１に基づいて上記で示した形式のＳＩＰ ＵＲＩにアドレス指定されたセッションを発信側オペレータがどのようにルーティングできるかに関して、決定的とはいえない。この分野では、諸標準は、ＳＩＰ ＵＲＩにアドレス指定されたセッションをルーティングするため、ＤＮＳの使用を一般的に言及するが、それは、いろいろな理由で大規模な展開には不十分である。例えば、複数のネットワークが関与する場合、各ネットワークは、ＩＰＸ用に提案されたもののような共有ＤＮＳに接続するだけでなく、内部的なＤＮＳを有することがある。しかし、各種の標準は、これらの多様なＤＮＳがどのようにして設定され使用されることになるのかを記述していない。事態を一層複雑にするのだが、完全修飾ドメイン名（ｆｕｌｌｙ ｑｕａｌｉｆｉｅｄ ｄｏｍａｉｎ ｎａｍｅｓ：ＦＱＤＮ）がパブリックインターネット上に数千万も存在することを考えると、一意のアドレスの全体量は相互接続ネットワークでも同様となりうるだろうと想定されることから、スケーラビリティが問題である。これは、トラヒック、例えばＳＩＰトラヒックを複数の相互接続ネットワーク経由でルーティングするための課題となりうる。
【００２２】
加えて、オペレータ各社は、他のパブリックネットワークへの自社の相互接続の知識だけでなく、これらのネットワークオペレータ各社に対する相互接続合意に基づいてルーティングの決定をしたいと望むことが多い。この情報は、彼らのローカルなＤＮＳサーバや関連のインフラストラクチャによって完全に供給されるとは限らない。在圏ネットワークオペレータがＵＲＩから容易に導出できないＳＩＰ ＵＲＩも多い。例えば、ｓｉｐ：ｊｏｈｎ＠ｅｎｔｅｒｐｒｉｓｅ．ｃｏｍまたはｓｉｐ：ｊｏｈｎ＠ｂａｌｄｗｉｎ．ｏｒｇまたはｊｏｈｎ＠ｂｒａｎｄ＿ｎａｍｅ．ｃｏｍのようなＳＩＰ ＵＲＩには、在圏ネットワークオペレータが示されない。従って、特定のオペレータにメッセージをルーティングするのに複数のやり方がある場合、発信側オペレータがどの相互接続選択肢を用いるかという決定は、典型的には、企業ユーザまたは宅内ユーザにサービス提供しているオペレータの知識に基づいて行われうるだけである。また、電話セッションについての既存の課金モデルは、一部は発呼ユーザと被呼ユーザの地理的位置に基づき、そして多くの場合、一部は発呼ユーザと被呼ユーザにサービス提供するオペレータにも基づく。言い換えれば、オペレータ各社は、典型的には、着信側オペレータについての情報に基づいて課金の決定を行うことを望むのだが、それはｓｉｐ：ｊｏｈｎ＠ｅｎｔｅｒｐｒｉｓｅ．ｃｏｍまたはｓｉｐ：ｊｏｈｎ＠ｂａｌｄｗｉｎ．ｏｒｇのようなＳＩＰ ＵＲＩには示されない。従って、以下の例示的実施形態は、ＳＩＰ ＵＲＩにアドレス指定されたセッションが、複数のネットワークを通って正確な宛先までルーティングされることを可能にする、アドレス指定メカニズムとルーティングメカニズムとを提供する。
【００２３】
上記のように、これらの例示的実施形態についての一般的な文脈には、各種の通信ネットワークと在圏ネットワークとを含むオペレータネットワーク上の電話が含まれる。しかし、理解されるであろうが、本発明は、電話に限らず、いかなるタイプのメッセージをルーティングするのにも使用されうる。これらのネットワークは典型的には、多様な通信経路と、各種のネットワークを分離するＩＢＣＦと、に関する可能性を有するであろう。加えて、メッセージトラヒックが所望のエンドポイントに到達することができるように、これらの各種のネットワーク間で通信を転送するための必要な詳細を詳述するＳＬＡ（サービス品質保証契約）が作成されるであろうと予想される。一部の詳細には、サービス品質要件やコストを含んでもよいし、さらに、例えばネットワークを識別するためにネットワークによって用いられることになる合意済み形式のようなアドレス指定の規則が含まれてもよい。
【００２４】
例示的実施形態によれば、要求またはメッセージの所望のルーティング経路を（例えば発信側ネットワークが）判定するための解決策には、発信側ネットワークがデータベースにクエリを行って、メッセージのルーティングを判定するのに用いられる応答を受信することが含まれる。例えば、発信側ネットワークが、宛先ユーザアドレス、例えばｓｉｐ：ｊｏｈｎ＠ｂａｎｋ．ｃｏｍというＳＩＰ ＵＲＩを含むＳＩＰメッセージをユーザから受信すると仮定しよう。この発信側ネットワークは発信側ネットワークとして動作しているため、どの在圏ネットワークがサービスをｂａｎｋ．ｃｏｍに提供するのか分からず、従って、どこにメッセージを送信するのか分からない。次いで、発信側ネットワークが、何らかのタイプの宛先識別情報、例えばｓｉｐ：ｊｏｈｎ＠ｂａｎｋ．ｃｏｍ、またはｂａｎｋ．ｃｏｍ、または、宛先ユーザアドレスに関連するいずれかの他のタイプの宛先識別情報を使って、（マスタＤＮＳデータベースを含みうるであろう）在圏オペレータデータベースにクエリを行って、そして、在圏ネットワークを識別する情報、例えば在圏ネットワークのＦＱＤＮまたはその他の合意された識別情報を含む応答を受信する。
【００２５】
例示的実施形態によれば、この在圏オペレータデータベースは、典型的なネットワークレベルＤＮＳサーバより相当多くの情報を含むことが可能であり、例えば、在圏オペレータデータベースは、すべてのＦＱＤＮについての情報と、相互接続されている各種ネットワークについての情報とを含んでもよいだろう。それに比べて、ネットワークレベルＤＮＳは典型的には、共有の相互接続からのネットワークオペレータの入口ポイント(ingress points)についてのレコードを保持するだけであり、各種のオペレータまたはＩＰＸのようなグループによって運用される。従って、本書で議論されるネットワークレベルＤＮＳが、典型的にはネットワーク毎に用いられて、単一のオペレータネットワークについてドメイン名とＩＰアドレスとの間の翻訳を行うのに対し、本書で議論される在圏オペレータデータベースは、特に、特定のメッセージに関連する在圏ネットワークを識別するのに用いられる。その後、在圏オペレータデータベースからデータを受信した時点で、発信側ネットワークは、例えば、各種のネットワーク間の適切なＳＬＡと、コストと、トラヒック管理の検討材料とのうちのいずれか、または一部、または全部に基づいて、ルーティング経路を判定する。次いで、発信側ネットワークは、メッセージを在圏ネットワークに向けて送信し、そして、宛先ユーザアドレスと在圏オペレータを識別するための情報とを両方含める。このように宛先ユーザアドレスと在圏オペレータを識別するための情報とを両方共用いることは、２層のアドレス指定の一例である。
【００２６】
例示的実施形態によって、一企業（または複数の企業）および個人ユーザに通信をルーティングすることができる各種の相互接続ネットワークを図４に示す。この例示的通信の枠組みは、２つのオペレータネットワークであるＴｅｌｅ２ ４０２およびＴｅｌｉａ４０４と、ＩＰＸ４０６と、企業ネットワークであるＢａｎｋ４０８とを含む。ＳＢＧ（セッション境界ゲートウェイ）は典型的にはアクセスポイントであるが、同時に、各種のオペレータネットワークおよびＩＰＸ４０６に出入りする通信のためのファイアウォールとしても動作することができる。加えて、オペレータネットワークであるＴｅｌｅ２ ４０２およびＴｅｌｉａ４０４はそれぞれ、少なくともローカルに格納されたドメイン情報を有する、自分自身のネットワークレベルＤＮＳサーバ４２２および４２４（またはその同等物）を有する。在圏オペレータデータベース４１０は、ＩＰＸ４０６に関連するすべてのネットワークについてのＤＮＳ情報を含む。この例ではＩＰＸ４０６の中に位置しているが、在圏オペレータデータベース４１０は、オペレータネットワークに接続されていてそれらにアクセス可能ならばどこに存在してもよく、例えば、第三者の所在地に存在してもよい。在圏オペレータデータベース４１０に記憶されたＤＮＳ情報は、例を挙げれば、例えばＴｅｌｅ２ ４０２およびＴｅｌｉａ４０４のようなネットワークによって在圏オペレータデータベース４１０に報告された、各ネットワークによってサービス提供される住居や企業について記述する情報を含んでもよい。
【００２７】
企業ネットワークＢａｎｋ４０８は、各種のリソースおよび個人をアドレス可能な場所を表すＢａｎｋ Ｃｅｎｔｒｅｘ４１２と２つのＢａｎｋ ＰＢＸ４１４および４１６とを含む。ユーザ１ ４１８は、Ｔｅｌｅ２によってサービスを提供されるユーザを表し、ユーザ２ ４２０は、Ｂａｎｋ ＰＢＸ４１４に関連することが知られているＢａｎｋ４０８のために働いているユーザを表す。本書ではＢａｎｋ Ｃｅｎｔｒｅｘ４１２は、バーチャルＰＢＸであると考えられている。バーチャルＰＢＸは、典型的には小規模なリモートの企業拠点に関連付けられる。本書で記述する例示的実施形態において、在圏ネットワークは、通常のＰＢＸとバーチャルＰＢＸとをいずれも呼とメッセージとをエンドユーザに配信することについては同様に取り扱い、すなわち、本書で記述する例示的実施形態は、通常のＰＢＸとバーチャルなＰＢＸとのうちのいずれを利用するのかによって制約されない。
【００２８】
上記の例示的実施形態によれば、在圏オペレータデータベース４１０は、ユーザに関連する宛先識別情報と、それらの個別の在圏オペレータネットワークについての情報との両方に関連する情報を含む。在圏オペレータデータベース４１０は、この情報を用いてこれらの情報の集合間のマッピングを行うことができる。加えて、この情報は、さまざまなかたちで存在しうる。例えば、各種のネットワークおよびユーザを識別するのに、一般的なドメイン名、例えばｅｒｉｃｓｓｏｎ．ｃｏｍ、ｔｅｌｉａ．ｓｅ、ｂａｌｄｗｉｎ．ｏｒｇが用いられてもよいし、構造化された通信名、例えばｍｎｃ００１、ｍｃｃ２３４が用いられてもよい。また、在圏オペレータデータベース４１０は、一般的なドメイン名と、ｍｎｃやｍｃｃを用いる構造化された識別情報との間のマッピングを行ってもよい。
【００２９】
次に、図５に示すシグナリング図に関して、例示的実施形態によって、例えば図４に示す通信ネットワーク経由で呼をルーティングするメッセージについて記述しよう。最初に、ユーザ１ ４１８が、メッセージＩＮＶＩＴＥ ｓｉｐ：ｇｅｒｔ＠ｂａｎｋ．ｃｏｍ ５０２を、発信側オペレータネットワークとして動作するＴｅｌｅ２ ４０２に送信する。Ｔｅｌｅ２ ４０２は、どのネットワークがサービスをｂａｎｋ．ｃｏｍに提供するのか分からず、従って、「ｂａｎｋ．ｃｏｍ」（またはその翻訳バージョン）を含むクエリメッセージ５０４を在圏オペレータデータベース４１０に送信する。在圏オペレータデータベース４１０は、ルックアップを行って、「ｂａｎｋ．ｃｏｍ」がＴｅｌｉａ４０４によってサービス提供されることを見つけ、応答メッセージ５０６の一部として「ｖｐｎｓｅｒｖｉｃｅ＠ｔｅｌｉａ．ｓｅ」を送信する。Ｔｅｌｅ２ ４０２は、この情報を用いて、Ｔｅｌｅ２ ４０２とＴｅｌｉａ４０４との間の相互接続および契約、例えばＳＬＡに基づいてルーティング経路を判定する。
【００３０】
図４に示すように、Ｔｅｌｅ２ ４０２は、直接接続とＩＰＸ４０６経由との両方を通してＴｅｌｉａ４０４に接続している。この事例では、Ｔｅｌｅ２ ４０２は、「ＩＮＶＩＴＥ ｖｐｎｓｅｒｖｉｃｅ＠ｔｅｌｉａ．ｓｅ Ｔａｒｇｅｔ ｓｉｐ：ｇｅｒｔ＠ｂａｎｋ．ｃｏｍ」を含むメッセージ５０８で示すようにＩＰＸ４０６を通してトラヒックをルーティングすることを選ぶ。ＩＰＸ４０６は受信したメッセージ５０８の中の「ｔｅｌｉａ．ｓｅ」を見て、メッセージ５１０をＴｅｌｉａ４０４へルーティングする。次いでＴｅｌｉａ４０４は、「ＩＮＶＩＴＥ ｓｉｐ：ｇｅｒｔ＠ｂａｎｋ．ｃｏｍを含むメッセージ５１２をユーザ２ ４２０に送信する。
【００３１】
上記のように、上述したルーティング情報は、宛先アドレスと、例えばユーザまたは企業のような宛先にサービスを提供するネットワークについて記述する情報とを両方含む。後者の情報は、在圏オペレータデータベース４１０への発信側ネットワークのクエリへの応答を介して発信側ネットワークが利用できるようにされる。例示的実施形態によれば、ルーティング情報は、さまざまなやり方でＳＩＰメッセージに組み込むことができる。当業者であれば理解するであろうが、ＳＩＰメッセージは、Ｒｅｑｕｅｓｔ ＵＲＩとＴａｒｇｅｔ ＵＲＩヘッダとを両方含むことができる。例示的な一実施形態によれば、在圏オペレータＩＤ、例えばｔｅｌｉａ．ｓｅをＲｅｑｕｅｓｔ ＵＲＩに入れることができ、そして、宛先の元のＳＩＰ ＵＲＩ、例えばｇｅｒｔ＠ｂａｎｋ．ｃｏｍを、ＳＩＰメッセージのＴａｒｇｅｔ ＵＲＩヘッダに入れることができる。呼が在圏オペレータネットワークに到着すると、在圏オペレータは、Ｔａｒｇｅｔ ＵＲＩをＲｅｑｕｅｓｔ ＵＲＩに戻すように促し、呼をＮＧＣＮ３０４へとさらに配信させる。
【００３２】
別の例示的実施形態によれば、在圏オペレータＩＤを、Ｒｅｑｕｅｓｔ ＵＲＩに添付することができる（例えば、ｓｉｐ：ｊｏｈｎ＠ｅｎｔｅｒｐｒｉｓｅ．ｃｏｍ．ｍａｒｋｅｒ．ｍｎｃ１２３．ｍｃｃ２３４．３ｇｐｐｎｅｔｗｏｒｋｓ．ｏｒｇのように）。あるいは、新たなパラメータをＳＩＰ Ｒｅｑｕｅｓｔ ＵＲＩに入れることができる。例えば、在圏オペレータをパラメータとしてＳＩＰ Ｒｅｑｕｅｓｔ ＵＲＩに追加し、ｓｉｐ：ｊｏｈｎ＠ｅｎｔｅｒｐｒｉｘｅ．ｃｏｍ；ｓｏ＝ｍｎｃ１２３．ｍｃｃ２３４．３ｇｐｐｎｅｔｏｗｏｒｋｓ．ｏｒｇのようにすることができる。別の例示的実施形態によれば、情報をＲｅｑｕｅｓｔ ＵＲＩに添付するために上記で述べたのと同様のやり方でＲＮ（ルーティング番号）またはＴＲＧＰ（トランクグループパラメータ）のような他の既存のパラメータを拡張することによって、必要な在圏オペレータ情報を搬送することができる。
【００３３】
上記の例示的実施形態によれば、ＳＩＰメッセージの中で最初のＳＩＰ ＵＲＩと在圏オペレータＩＤとを両方搬送することによって、発信側ネットワークと中継／相互接続ネットワークとが、中枢の在圏オペレータデータベース４１０によって取得された在圏オペレータ識別情報に基づいてメッセージをルーティングすることが可能になる。従って、在圏オペレータネットワークルーティング情報は、中継／相互接続ネットワークが知っていて読み取ることができるＳＩＰメッセージについての通常のルーティング情報の一部として提供されるのだから、中継／相互接続ネットワークは、典型的には、企業または住宅用ＦＱＤＮについての情報を知る必要はないし、在圏オペレータデータベース４１０にクエリを行う必要もない。
【００３４】
例示的な一実施形態によれば、メッセージがその中を移動できる各種のネットワークはそれぞれ、典型的には、内部では別個のローカルＩＰアドレスを用いる。従って、ＩＰアドレスとＩＰアドレスを用いたルーティングとを求める従来のＤＮＳクエリは、典型的には、発信側オペレータネットワークから在圏ネットワークおよび宛先までルーティングするためには用いられない。加えて、ＩＰアドレスによるルーティングは、発信側ネットワークによって制御されない状態で使用ルートの選択を行う自動ルーティングであると考え得ることから、典型的には望まれない。これでは、発信側オペレータネットワークが経路を制御することができず、ＳＬＡに関する問題や、収入が最適にならないことにつながりうるであろう。
【００３５】
一企業について複数の在圏オペレータの事例
上記の例示的実施形態は、企業が単一の在圏オペレータネットワークによってサービス提供される場合にメッセージトラヒックをルーティングするためのシステムおよび方法を記述する。しかし、大企業については、ＮＧＣＮサイトと在圏オペレータネットワークとの間に複数の接続事例がありうる。例えば、大規模な企業ネットワークについては、企業は、企業の各部門が地理的に広域に位置していることや、ビジネス上の競合の理由等から、複数の在圏オペレータを望むことがある。例示的実施形態によって、企業が２つの異なる在圏オペレータネットワークを用いる通信の枠組みについて、図６に関して以下に述べる。
【００３６】
図６は、例示的な通信の枠組みを示すが、ここにはＩＰＸ４０６が含まれ、それが各種のオペレータネットワーク、例えばＴｅｌｉａ４０４、Ｔｅｌｅ２ ４０２、Ｊｅｒｓｅｙ Ｔｅｌ６０４、Ｇａｍｍａ Ｔｅｌ６０８に接続する。また、この例では、ＩＰＸ４０６は、一次ＤＮＳデータベース４１０を含むが、これは宛先のＦＱＤＮを、その宛先にサービスを提供する在圏ネットワークにマッピングするための情報を含む。企業Ｂａｎｋが、Ｔｅｌｉａ４０４によってサービス提供されるＢａｎｋ ＰＢＸ４１４と、Ｊｅｒｓｙ Ｔｅｌ６０４によってサービス提供されるＢａｎｋ ＰＢＸ６０２とで示すように、２つの異なる在圏オペレータネットワークによってサービス提供され、Ｂａｎｋ ＰＢＸ４１４とＢａｎｋ ＰＢＸ６０２とはＶＰＮ６０６によって接続される。さらに、ユーザ１ ４１８とユーザ２ ４２０とを示す。
【００３７】
次に、例示的実施形態によって、一企業について複数の在圏オペレータネットワークを有するケースについて図６に示すアーキテクチャを用いる、図７に示すようなシグナリングフローについて記述しよう。最初に、ユーザ１ ４１８が、「ＩＮＶＩＴＥ ｓｉｐ：ｇｅｒｔ＠ｂａｎｋ．ｃｏｍ」を含むメッセージ７０２を、発信側ネットワークとして動作するＴｅｌｅ２ ４０２に送信する。次いでＴｅｌｅ２ ４０２は、例えば「ｂａｎｋ．ｃｏｍ」や「ｇｅｒｔ＠ｂａｎｋ．ｃｏｍ」のような宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージ７０４を在圏オペレータデータベース４１０に送信する。在圏オペレータデータベース４１０は、ルックアップを行って、２つの在圏オペレータネットワーク、例えばｖｐｎｓｅｒｖｉｃｅ＠ｔｅｌｉａ．ｓｅやｖｐｎｓｅｒｖｉｃｅ＠ｊｅｒｓｅｙ．ｕｋについての識別情報を含む応答メッセージ７０６を送信する。次いでＴｅｌｅ２ ４０２は、どの在圏オペレータネットワークに要求を送信し、要求をどのようにルーティングするかを決定する。これらの決定は、既知の相互接続、ＳＬＡ、地理的位置、コスト、その他の関連情報に基づいて行われてもよい。これらの決定に基づいて、Ｔｅｌｅ２ ４０２は、「ＩＮＶＩＴＥ ｖｐｎｓｅｒｖｉｃｅ＠ｔｅｌｉａ．ｓｅおよびＴａｒｇｅｔ ｓｉｐ：ｇｅｒｔ＠ｂａｎｋ．ｃｏｍ」を含むメッセージ７０８をＩＰＸ４０６に送信する。ＩＰＸ４０６は、自分が必要とするルーティング情報、例えばｔｅｌｉａ．ｓｅが分かり、そして、メッセージ７１０に示すように、メッセージをＴｅｌｉａ４０４に転送する。ついでＴｅｌｉａ４０４は、メッセージの内容をよく調査して、それらを、ｇｅｒｔ＠ｂａｎｋ．ｃｏｍであることが分かっているユーザ２ ４２０に転送する。
【００３８】
上記のように、企業は、その企業の異なる部門について各種の在圏オペレータネットワークを有することがある。例示的実施形態によれば、すべての在圏オペレータネットワークが、対応する識別情報またはルーティング情報を在圏オペレータデータベース４１０の中に記憶しておく必要はない。加えて、クエリメッセージ７０４に応じて、在圏オペレータデータベース４１０の中に記憶された１つの、または少数の、またはすべての在圏オペレータネットワークが、応答メッセージ７０６の中で返信されてもよい。応答メッセージ７０６の中で用いられる在圏オペレータネットワークは、在圏オペレータネットワークと企業との間で事前に定められ、それに従って一次ＤＮＳデータベース４１０に記憶されてもよい。
【００３９】
例示的実施形態によれば、不適切な在圏オペレータネットワークがメッセージを受信した場合、すなわち、在圏オペレータネットワークがそのメッセージについてはその宛先にサービス提供しないと判定する場合、システムと方法とを用いてメッセージを別の在圏オペレータネットワークにさらにルーティングすることができる。ある場合には、例えば、宅内ユーザが企業に電話をかけることによって、呼がパブリックネットワークにおいて開始される。発信側オペレータネットワークが、（そのクエリによって受信された）複数の在圏オペレータのうちの１つを選択し、呼をその在圏オペレータに配信した。しかし、これは実際には、当該ユーザにとっては不適切な在圏オペレータであった。在圏オペレータネットワークは、企業にクエリを行うことができ、例えば企業内のデータベースにルーティングについての指示を求めるクエリを行って、次いで、上記の２層のアドレス指定スキームを用いて呼を正しい在圏オペレータネットワークにルーティングすることができる。
【００４０】
別の例示的実施形態によれば、呼は、企業内で、例えば企業ユーザが別の企業ユーザに対して開始することができる。宛先企業ユーザは、発信企業ユーザとは別の在圏ネットワークオペレータによってサービス提供される企業ネットワークの一部である。この場合、これはオンネット・コールとして知られるものだが、呼は、各種の相互接続ネットワークを経て正しい在圏オペレータネットワークにルーティングされる必要がある。また、上記の２層のアドレス指定スキームを用いてこの呼を正しい在圏オペレータに転送することもできる。
【００４１】
ドメイン名ポータビリティ
例示的実施形態によれば、上記のシステムおよび方法の実装によって、ドメイン名ポータビリティが可能になる。本書ではドメイン名ポータビリティとは、ユーザまたは企業のドメインを、１つの在圏オペレータから別の在圏オペレータに最小限のオーバーヘッドまたは作業で移動させることを言う。例えば、上記のように、これらの例示的実施形態で用いられる在圏オペレータデータベース４１０は、各ネットワークで用いられる典型的なネットワークレベルのＤＮＳデータベース４２２、４２４とは別である。この在圏オペレータデータベース４１０は、在圏オペレータデータベース４１０のプロバイダと各ネットワークオペレータとによって定められたように各ネットワークによって更新されるが、更新は変更が行われる時にタイムリーに行われることが望ましく、それによってドメイン名ポータビリティが円滑化される。
【００４２】
例えば、企業Ｂａｎｋ４０８が、Ｔｅｌｉａ４０４を自社のサービスプロバイダとして用いていると仮定する。次いで、企業Ｂａｎｋ４０８は、自社のサービスプロバイダとしてＴｅｌｅ２ ４０２に変更することを決め、すなわち、Ｂａｎｋ４０８から在圏ネットワークへの接続ポイントが、新たな在圏ネットワークに変更されるが、Ｂａｎｋ４０８の中の内部アドレス指定は典型的には変更されず、例えば個別のＳＩＰ ＵＲＩ、内線番号、直通電話番号（ｄｉｒｅｃｔ ｄｉａｌｉｎｇ ｉｎｗａｒｄｓ：ＤＤＩ）は以前と同じであろう。次いで、この変更が行われた後、Ｔｅｌｅ２ ４０２は、その変更について、在圏オペレータデータベース４１０を更新する。典型的には、２つのネットワークがこの変更によって直接影響を受ける場合を除き、ＤＮＳインフラストラクチャの低い方のレベルでは変更が行われる必要はない。また、Ｂａｎｋ４０８のネットワーク構造の範囲内での内部変更は、大部分は、修正される必要はないだろう。また、このプロセスは、住宅用についても当てはまるであろう。例えば、ユーザがｇｅｒｔ＠ｂａｌｄｗｉｎ．ｏｒｇというドメイン名を有していて、在圏オペレータネットワークを変更した場合、ドメイン名は、新たな在圏オペレータネットワークへ持ち運ぶことができるであろうし、依然としてｇｅｒｔ＠ｂａｌｄｗｉｎ．ｃｏｍへのシームレスな移行により使用することができるであろう。
【００４３】
上述の例示的実施形態は、相互接続ネットワーク（例えば、相互接続ＩＭＳネットワーク）経由でトラヒックをルーティングするために使用される在圏オペレータネットワークと照合される宛先アドレス情報を記憶するために、在圏オペレータデータベース４１０を使用する方法およびシステムを図解する。ここで、図８に関して、在圏オペレータデータベース４１０を表す例示的通信ノード８００を説明する。通信ノード８００は、プロセッサ８０２（または複数のプロセッサコア）と、メモリ８０４と、１つ以上の二次ストレージデバイス８０６と、通信を円滑化する通信インタフェースユニット８０８とを含むことができる。メモリ８０４（または二次ストレージデバイス８０６）は、宛先アドレス（例えば、ＦＱＤＮ）およびこれらの宛先にサービス提供する在圏オペレータネットワークに関するストレージとして使用可能である。それゆえ、例示的実施形態による通信ノード８００は、クエリを受信し、宛先に関連する在圏オペレータネットワーク（または複数のネットワーク）を返すことができる。加えて、通信ノード８００は、上記の各種の通信ネットワークにおけるその他のノード、例えばネットワークレベル（ローカル）ＤＮＳサーバ、またはＤＮＳサーバおよび在圏オペレータデータベース４１０の組み合わせ、の機能を実行することができる。
【００４４】
例示的実施形態による上述の例示的システムを利用して、通信をルーティングするための方法を図９のフローチャートに示す。最初に、在圏ネットワーク経由で発信側ネットワークから宛先ユーザアドレスへ通信をルーティングする方法は、ステップ９０２において、前記発信側ネットワークから、前記宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージを送信するステップと、ステップ９０４において、前記発信側ネットワークにおいて、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する前記在圏ネットワークを特定する情報を含む応答メッセージを受信するステップと、ステップ９０６において、前記発信側ネットワークにおいて、メッセージ中に、前記宛先ユーザアドレスに関連する前記宛先識別情報と前記在圏ネットワークを特定する前記情報とを組み込むステップと、ステップ９０８において、前記発信側ネットワークから、前記メッセージを前記在圏ネットワークへ送信するステップと、を備える。
【００４５】
例示的実施形態による上述の例示的システムを利用して、通信をルーティングするための方法を図１０のフローチャートに示す。最初に、通信ノードにおける、通信をルーティングするための方法は、ステップ１００２において、各々が宛先ユーザアドレスに関連する複数の宛先識別情報および対応する在圏ネットワーク識別情報を記憶するステップであって、前記宛先ユーザアドレスに関連する各宛先識別情報が少なくとも１つの在圏ネットワークにも関連する、ステップと、ステップ１００４において、宛先ユーザアドレスに関連する、前記複数の宛先識別情報のうちの１つを含むクエリメッセージを受信するステップと、ステップ１００６において、宛先ユーザアドレスに関連する前記宛先識別情報を用いてルックアップを実行して前記対応する少なくとも１つの在圏ネットワークを判定するステップと、ステップ１００６において、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する少なくとも１つの在圏ネットワークを特定する、前記ルックアップに基づく情報を含む応答メッセージを送信するステップと、を備える。
【００４６】
上記で開示した例示的実施形態は、相互接続ネットワークを経てメッセージトラヒックをルーティングすることに関連するシステムおよび方法について記述する。理解されるべきだが、この記述は、本発明を限定することを意図していない。例えば、上述の例示的実施形態は、各々が移動電話を使用している２人の別個のユーザ間で相互接続ＩＭＳネットワーク経由で呼をルーティングするために実装可能である。対照的に、例示的実施形態は、代替形態、修正形態、均等形態をカバーすることが意図されており、それらは添付の請求項によって定義されるように本発明の精神と範囲に含まれる。さらに、例示的実施形態の詳細記述において、請求された本発明の完全な理解を提供することを目的として多数の個別の詳細が記述されている。しかし、当業者であれば、そのような個別の詳細がなくても各種の実施形態が実施されうることを理解するであろう。
【００４７】
本書の例示的実施形態の特徴および要素は、特定の組み合わせにおける実施形態として記述されているけれども、それぞれの特徴または要素は、実施形態のその他の特徴および要素なしに単独で用いられてもよいし、本書で開示した他の特徴および要素と共にかまたはそれらなしに各種の組み合わせで用いられてもよい。本願で提供した方法またはフローチャートは、汎用コンピュータまたはプロセッサによって実行するための、コンピュータ可読記録媒体に収録されるコンピュータプログラム、ソフトウェア、またはファームウェアとして実装されてもよい。
【特許請求の範囲】
【請求項１】
在圏ネットワーク経由で発信側ネットワークから宛先ユーザアドレスへ通信をルーティングする方法であって、
前記発信側ネットワークから、前記宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージを送信するステップと、
前記発信側ネットワークにおいて、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する前記在圏ネットワークを識別する情報を含む応答メッセージを受信するステップと、
前記発信側ネットワークにおいて、メッセージ中に、前記宛先ユーザアドレスに関連する前記宛先識別情報と前記在圏ネットワークを識別する前記情報とを組み込むステップと、
前記発信側ネットワークから、前記メッセージを前記在圏ネットワークへ送信するステップと、
を備えることを特徴とする方法。
【請求項２】
前記メッセージは、セッション開始プロトコル（ＳＩＰ）メッセージである
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報を前記ＳＩＰメッセージのＴａｒｇｅｔユニフォーム・リソース・アイデンティファイア（ＵＲＩ）ヘッダに配置し、前記在圏ネットワークを識別する前記情報を前記ＳＩＰメッセージのＲｅｑｕｅｓｔ ＵＲＩに配置するステップをさらに備える
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報を前記ＳＩＰメッセージのＲｅｑｕｅｓｔ ＵＲＩに配置し、前記在圏ネットワークを識別する前記情報を前記ＳＩＰメッセージの前記Ｒｅｑｕｅｓｔ ＵＲＩに添付するステップをさらに備える
ことを特徴とする請求項２に記載の方法。
【請求項５】
前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報を前記ＳＩＰメッセージのＲｅｑｕｅｓｔ ＵＲＩに配置し、前記在圏ネットワークを識別する前記情報を、前記ＳＩＰメッセージの前記Ｒｅｑｕｅｓｔ ＵＲＩ中の新しいパラメータとして追加するステップをさらに備える
ことを特徴とする請求項２に記載の方法。
【請求項６】
前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報をＲｅｑｕｅｓｔ ＵＲＩに配置し、前記在圏ネットワークを識別する前記情報を、前記ＳＩＰメッセージ中の既存のパラメータを用いて添付するステップをさらに備える
ことを特徴とする請求項２に記載の方法。
【請求項７】
前記ＳＩＰメッセージ中の前記既存のパラメータは、ルーティング番号パラメータおよびトランクグループパラメータのうちの少なくとも一方である
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記応答メッセージの中で、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する複数の在圏ネットワークに関する識別情報を受信するステップと、
コスト、サービス品質保証契約、およびトラヒック管理の検討材料のうちの少なくとも１つに基づいて、前記複数の在圏ネットワークのうちの１つへ前記メッセージをルーティングすることを決定するステップと、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項９】
前記宛先ユーザアドレスに関連する前記宛先識別情報は、住宅および企業のうちの少なくとも一方に関連する
ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記宛先ユーザアドレスに関連する前記宛先識別情報は、完全修飾ドメイン名（ＦＱＤＮ）である
ことを特徴とする請求項１に記載の方法。
【請求項１１】
前記宛先ユーザアドレスに関連する前記宛先識別情報は、ＦＱＤＮの一部である
ことを特徴とする請求項１に記載の方法。
【請求項１２】
通信ノードにおける、通信をルーティングするための方法であって、
各々が宛先ユーザアドレスに関連する複数の宛先識別情報および対応する在圏ネットワーク識別情報を記憶するステップであって、前記宛先ユーザアドレスに関連する各宛先識別情報が少なくとも１つの在圏ネットワークにも関連する、ステップと、
宛先ユーザアドレスに関連する、前記複数の宛先識別情報のうちの１つを含むクエリメッセージを受信するステップと、
前記宛先ユーザアドレスに関連する前記宛先識別情報を用いてルックアップを実行して前記対応する少なくとも１つの在圏ネットワークを判定するステップと、
前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する少なくとも１つの在圏ネットワークを識別する、前記ルックアップに基づく情報を含む応答メッセージを送信するステップと、
を備えることを特徴とする方法。
【請求項１３】
前記少なくとも１つの在圏ネットワークは、複数の在圏ネットワークである
ことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記少なくとも１つの在圏ネットワークの中でメッセージのルーティングをサポートするステップを更に備え、
前記少なくとも１つの在圏ネットワークは、ドメイン・ネーム・システム（ＤＮＳ）サーバを含み、
前記ＤＮＳサーバは、前記通信ノードとは別物である
ことを特徴とする請求項１２に記載の方法。
【請求項１５】
前記通信ノードはデータベースである
ことを特徴とする請求項１２に記載の方法。
【請求項１６】
前記宛先ユーザアドレスに関連する前記宛先識別情報の１つと前記対応する少なくとも１つの在圏ネットワークとの間の変更を示すメッセージまたはデータベース管理アクションを受信するステップと、
前記受信したメッセージに基づいて前記記憶された対応を更新するステップと、
を更に備えることを特徴とする請求項１２に記載の方法。
【請求項１７】
前記宛先ユーザアドレスに関連する前記宛先識別情報は、企業を識別する
ことを特徴とする請求項１２に記載の方法。
【請求項１８】
前記宛先ユーザアドレスに関連する前記宛先識別情報は、宅内ユーザを識別する
ことを特徴とする請求項１２に記載の方法。
【請求項１９】
通信ノードであって、
宛先ユーザアドレスに関連する宛先識別情報と、当該宛先ユーザアドレスに関連する当該宛先識別情報によって識別されるエンティティに対してサービスを提供する少なくとも１つの在圏オペレータネットワークと、の間のマッピングを記憶するメモリと、
前記宛先ユーザアドレスに関連する前記宛先識別情報を受信する通信インタフェースと、
前記宛先ユーザアドレスに関連する前記受信した宛先識別情報に関するルックアップを実行するプロセッサと、
を備え、
前記ルックアップは、セッション開始プロトコル（ＳＩＰ）メッセージ中で前記宛先ユーザアドレスに関連する前記宛先識別情報を含むクエリメッセージを前記通信インタフェースが受信した場合に、前記少なくとも１つの在圏オペレータネットワークを結果として返し、
前記通信インタフェースは、前記少なくとも１つの在圏オペレータネットワークを含む応答メッセージを送信する
ことを特徴とする通信ノード。
【請求項２０】
前記少なくとも１つの在圏オペレータネットワークは、複数の在圏オペレータネットワークである
ことを特徴とする請求項１９に記載の通信ノード。
【請求項２１】
前記少なくとも１つの在圏オペレータネットワークの各々は、当該在圏オペレータネットワークの中でメッセージのルーティングをサポートするドメイン・ネーム・システム（ＤＮＳ）サーバを含み、
前記ＤＮＳサーバは、前記通信ノードとは別物である
ことを特徴とする請求項１９に記載の通信ノード。
【請求項２２】
前記通信ノードはデータベースである
ことを特徴とする請求項１９に記載の通信ノード。
【請求項２３】
前記宛先ユーザアドレスに関連する宛先識別情報と、当該宛先ユーザアドレスに関連する当該宛先識別情報によって識別されるエンティティに対してサービスを提供する少なくとも１つの在圏オペレータネットワークと、の間の前記マッピングは、一般的なドメイン名と構造化された名前との間で行われる
ことを特徴とする請求項１９に記載の通信ノード。
【請求項２４】
前記構造化された名前は、ｍｎｃｘｘｘ．ｍｃｃｙｙｙというフォーマットを持ち、
ｍｎｃは移動体網コードであり、ｍｃｃは移動体国コードである
ことを特徴とする請求項２３に記載の通信ノード。
【請求項１】
在圏ネットワーク経由で発信側ネットワークから宛先ユーザアドレスへ通信をルーティングする方法であって、
前記発信側ネットワークから、前記宛先ユーザアドレスに関連する宛先識別情報を含むクエリメッセージを送信するステップと、
前記発信側ネットワークにおいて、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する前記在圏ネットワークを識別する情報を含む応答メッセージを受信するステップと、
前記発信側ネットワークにおいて、メッセージ中に、前記宛先ユーザアドレスに関連する前記宛先識別情報と前記在圏ネットワークを識別する前記情報とを組み込むステップと、
前記発信側ネットワークから、前記メッセージを前記在圏ネットワークへ送信するステップと、
を備えることを特徴とする方法。
【請求項２】
前記メッセージは、セッション開始プロトコル（ＳＩＰ）メッセージである
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報を前記ＳＩＰメッセージのＴａｒｇｅｔユニフォーム・リソース・アイデンティファイア（ＵＲＩ）ヘッダに配置し、前記在圏ネットワークを識別する前記情報を前記ＳＩＰメッセージのＲｅｑｕｅｓｔ ＵＲＩに配置するステップをさらに備える
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報を前記ＳＩＰメッセージのＲｅｑｕｅｓｔ ＵＲＩに配置し、前記在圏ネットワークを識別する前記情報を前記ＳＩＰメッセージの前記Ｒｅｑｕｅｓｔ ＵＲＩに添付するステップをさらに備える
ことを特徴とする請求項２に記載の方法。
【請求項５】
前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報を前記ＳＩＰメッセージのＲｅｑｕｅｓｔ ＵＲＩに配置し、前記在圏ネットワークを識別する前記情報を、前記ＳＩＰメッセージの前記Ｒｅｑｕｅｓｔ ＵＲＩ中の新しいパラメータとして追加するステップをさらに備える
ことを特徴とする請求項２に記載の方法。
【請求項６】
前記組み込むステップは、前記宛先ユーザアドレスに関連する前記宛先識別情報をＲｅｑｕｅｓｔ ＵＲＩに配置し、前記在圏ネットワークを識別する前記情報を、前記ＳＩＰメッセージ中の既存のパラメータを用いて添付するステップをさらに備える
ことを特徴とする請求項２に記載の方法。
【請求項７】
前記ＳＩＰメッセージ中の前記既存のパラメータは、ルーティング番号パラメータおよびトランクグループパラメータのうちの少なくとも一方である
ことを特徴とする請求項６に記載の方法。
【請求項８】
前記応答メッセージの中で、前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する複数の在圏ネットワークに関する識別情報を受信するステップと、
コスト、サービス品質保証契約、およびトラヒック管理の検討材料のうちの少なくとも１つに基づいて、前記複数の在圏ネットワークのうちの１つへ前記メッセージをルーティングすることを決定するステップと、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項９】
前記宛先ユーザアドレスに関連する前記宛先識別情報は、住宅および企業のうちの少なくとも一方に関連する
ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記宛先ユーザアドレスに関連する前記宛先識別情報は、完全修飾ドメイン名（ＦＱＤＮ）である
ことを特徴とする請求項１に記載の方法。
【請求項１１】
前記宛先ユーザアドレスに関連する前記宛先識別情報は、ＦＱＤＮの一部である
ことを特徴とする請求項１に記載の方法。
【請求項１２】
通信ノードにおける、通信をルーティングするための方法であって、
各々が宛先ユーザアドレスに関連する複数の宛先識別情報および対応する在圏ネットワーク識別情報を記憶するステップであって、前記宛先ユーザアドレスに関連する各宛先識別情報が少なくとも１つの在圏ネットワークにも関連する、ステップと、
宛先ユーザアドレスに関連する、前記複数の宛先識別情報のうちの１つを含むクエリメッセージを受信するステップと、
前記宛先ユーザアドレスに関連する前記宛先識別情報を用いてルックアップを実行して前記対応する少なくとも１つの在圏ネットワークを判定するステップと、
前記宛先ユーザアドレスに関連する前記宛先識別情報に関連する少なくとも１つの在圏ネットワークを識別する、前記ルックアップに基づく情報を含む応答メッセージを送信するステップと、
を備えることを特徴とする方法。
【請求項１３】
前記少なくとも１つの在圏ネットワークは、複数の在圏ネットワークである
ことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記少なくとも１つの在圏ネットワークの中でメッセージのルーティングをサポートするステップを更に備え、
前記少なくとも１つの在圏ネットワークは、ドメイン・ネーム・システム（ＤＮＳ）サーバを含み、
前記ＤＮＳサーバは、前記通信ノードとは別物である
ことを特徴とする請求項１２に記載の方法。
【請求項１５】
前記通信ノードはデータベースである
ことを特徴とする請求項１２に記載の方法。
【請求項１６】
前記宛先ユーザアドレスに関連する前記宛先識別情報の１つと前記対応する少なくとも１つの在圏ネットワークとの間の変更を示すメッセージまたはデータベース管理アクションを受信するステップと、
前記受信したメッセージに基づいて前記記憶された対応を更新するステップと、
を更に備えることを特徴とする請求項１２に記載の方法。
【請求項１７】
前記宛先ユーザアドレスに関連する前記宛先識別情報は、企業を識別する
ことを特徴とする請求項１２に記載の方法。
【請求項１８】
前記宛先ユーザアドレスに関連する前記宛先識別情報は、宅内ユーザを識別する
ことを特徴とする請求項１２に記載の方法。
【請求項１９】
通信ノードであって、
宛先ユーザアドレスに関連する宛先識別情報と、当該宛先ユーザアドレスに関連する当該宛先識別情報によって識別されるエンティティに対してサービスを提供する少なくとも１つの在圏オペレータネットワークと、の間のマッピングを記憶するメモリと、
前記宛先ユーザアドレスに関連する前記宛先識別情報を受信する通信インタフェースと、
前記宛先ユーザアドレスに関連する前記受信した宛先識別情報に関するルックアップを実行するプロセッサと、
を備え、
前記ルックアップは、セッション開始プロトコル（ＳＩＰ）メッセージ中で前記宛先ユーザアドレスに関連する前記宛先識別情報を含むクエリメッセージを前記通信インタフェースが受信した場合に、前記少なくとも１つの在圏オペレータネットワークを結果として返し、
前記通信インタフェースは、前記少なくとも１つの在圏オペレータネットワークを含む応答メッセージを送信する
ことを特徴とする通信ノード。
【請求項２０】
前記少なくとも１つの在圏オペレータネットワークは、複数の在圏オペレータネットワークである
ことを特徴とする請求項１９に記載の通信ノード。
【請求項２１】
前記少なくとも１つの在圏オペレータネットワークの各々は、当該在圏オペレータネットワークの中でメッセージのルーティングをサポートするドメイン・ネーム・システム（ＤＮＳ）サーバを含み、
前記ＤＮＳサーバは、前記通信ノードとは別物である
ことを特徴とする請求項１９に記載の通信ノード。
【請求項２２】
前記通信ノードはデータベースである
ことを特徴とする請求項１９に記載の通信ノード。
【請求項２３】
前記宛先ユーザアドレスに関連する宛先識別情報と、当該宛先ユーザアドレスに関連する当該宛先識別情報によって識別されるエンティティに対してサービスを提供する少なくとも１つの在圏オペレータネットワークと、の間の前記マッピングは、一般的なドメイン名と構造化された名前との間で行われる
ことを特徴とする請求項１９に記載の通信ノード。
【請求項２４】
前記構造化された名前は、ｍｎｃｘｘｘ．ｍｃｃｙｙｙというフォーマットを持ち、
ｍｎｃは移動体網コードであり、ｍｃｃは移動体国コードである
ことを特徴とする請求項２３に記載の通信ノード。
【図１】
【図２】
【図３（ａ）】
【図３（ｂ）】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３（ａ）】
【図３（ｂ）】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公表番号】特表２０１２−５１４３６３（Ｐ２０１２−５１４３６３Ａ）
【公表日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願番号】特願２０１１−５４２９０１（Ｐ２０１１−５４２９０１）
【出願日】平成２０年１２月２６日（２００８．１２．２６）
【国際出願番号】ＰＣＴ／ＩＢ２００８／００３６２６
【国際公開番号】ＷＯ２０１０／０７３０５８
【国際公開日】平成２２年７月１日（２０１０．７．１）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願日】平成２０年１２月２６日（２００８．１２．２６）
【国際出願番号】ＰＣＴ／ＩＢ２００８／００３６２６
【国際公開番号】ＷＯ２０１０／０７３０５８
【国際公開日】平成２２年７月１日（２０１０．７．１）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]