(57)【要約】  本発明は、呼の目標ユーザの識別子として電話番号（そして、埋め込み電話番号の付いたＳＩＰ  ＵＲＩではなく）を用いて呼のルーティングを可能にする目的で、ＩＭＳ着信ネットワーク内でのｔｅｌ  ＵＲＩの特定の取扱を提案する。具体的には、本発明は変換モジュールを導入し、その変換モジュールは、ＩＭＳ着信ネットワーク内に位置していて、埋め込み電話番号付きＳＩＰ  ＵＲＩを、同等のｔｅｌ  ＵＲＩに変換することができ、それが次いで、呼を目標ユーザまでルーティングできるように着信Ｉ−ＣＳＣＦおよびＳ−ＣＳＣＦによってＳＬＦおよび／またはＨＳＳに問い合わせを行うために使用される。
2009513052.tif 000002
【特許請求の範囲】
【請求項１】
変換モジュールであって、
プロセッサと、
前記プロセッサがアクセス可能且つ処理可能な命令を格納したメモリと、
を備え、
前記命令は、
要求ＵＲＩを受信するステップと、
認識可能な国際番号を伴うＳＩＰ  ＵＲＩを前記要求ＵＲＩが有するか否かを判定するステップと、
有さない場合に、エラーメッセージを出力するステップと、
有する場合に、前記ＳＩＰ  ＵＲＩを用いて電話番号「ｔｅｌ  ＵＲＩ」を生成するステップと、当該電話番号「ｔｅｌ  ＵＲＩ」を出力するステップと、
を実行させる
ことを特徴とする変換モジュール。
【請求項２】
前記ＳＩＰ  ＵＲＩが「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含まない場合に、前記プロセッサは、
前記ＳＩＰ  ＵＲＩから目標ユーザ部分を抽出するステップと、
前記電話番号「ｔｅｌ  ＵＲＩ」を生成するために文字列「ｔｅｌ：」を前記目標ユーザ部分の前に付加するステップと、
を実行することによって前記生成するステップを実行することを特徴とする請求項１に記載の変換モジュール。
【請求項３】
前記ＳＩＰ  ＵＲＩが「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含む場合に、前記プロセッサは、
前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の後ろに位置する第１の数字の組を抽出するステップと、
前記ＳＩＰ  ＵＲＩ中の「ｓｉｐ：」の後ろで前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の前に位置する第２の数字の組を抽出するステップと、
前記電話番号「ｔｅｌ  ＵＲＩ」を生成するために、前記第２の数字の組が後ろに挿入される前記第１の数字の組の前に文字列「ｔｅｌ：」を付加するステップと、
を実行することによって前記生成するステップを実行することを特徴とする請求項１に記載の変換モジュール。
【請求項４】
前記ＳＩＰ  ＵＲＩが「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含む場合に、前記プロセッサは、
前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の後ろに位置する第１の数字の組を抽出するステップと、
前記ＳＩＰ  ＵＲＩ中の「ｓｉｐ：」の後ろで前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の前に位置する第２の数字の組を抽出するステップと、
一連の置換規則を見つけるための事前定義された置換規則のテーブルへのキーとして前記第１の数字の組を使用するステップと、
第３の数字の組を生成するために前記一連の置換規則を前記第２の数字の組に適用するステップと、
前記電話番号「ｔｅｌ  ＵＲＩ」を生成するために、前記第３の数字の組の前に文字列「ｔｅｌ：」を付加するステップと、
を実行することによって前記生成するステップを実行することを特徴とする請求項１に記載の変換モジュール。
【請求項５】
埋め込まれた電話番号を有するＳＩＰ  ＵＲＩからｔｅｌ  ＵＲＩを取得する方法であって、
要求ＵＲＩを受信するステップと、
認識可能な国際番号を伴うＳＩＰ  ＵＲＩを前記要求ＵＲＩが有するか否かを判定するステップと、
有さない場合に、エラーメッセージを出力するステップと、
有する場合に、前記ＳＩＰ  ＵＲＩを用いて電話番号「ｔｅｌ  ＵＲＩ」を生成するステップと、当該電話番号「ｔｅｌ  ＵＲＩ」を出力するステップと、
を備えることを特徴とする方法。
【請求項６】
前記ＳＩＰ  ＵＲＩが「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含まない場合に、前記生成するステップが、
前記ＳＩＰ  ＵＲＩから目標ユーザ部分を抽出するステップと、
前記電話番号「ｔｅｌ  ＵＲＩ」を生成するために文字列「ｔｅｌ：」を前記目標ユーザ部分の前に付加するステップと、
を含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記ＳＩＰ  ＵＲＩが「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含む場合に、前記生成するステップが、
前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の後ろに位置する第１の数字の組を抽出するステップと、
前記ＳＩＰ  ＵＲＩ中の「ｓｉｐ：」の後ろで前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の前に位置する第２の数字の組を抽出するステップと、
前記電話番号「ｔｅｌ  ＵＲＩ」を生成するために、前記第２の数字の組が後ろに挿入される前記第１の数字の組の前に文字列「ｔｅｌ：」を付加するステップと、
を更に含むことを特徴とする請求項５に記載の方法。
【請求項８】
前記ＳＩＰ  ＵＲＩが「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含む場合に、前記生成するステップが、
前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の後ろに位置する第１の数字の組を抽出するステップと、
前記ＳＩＰ  ＵＲＩ中の「ｓｉｐ：」の後ろで前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の前に位置する第２の数字の組を抽出するステップと、
一連の置換規則を見つけるための事前定義された置換規則のテーブルへのキーとして前記第１の数字の組を使用するステップと、
第３の数字の組を生成するために前記一連の置換規則を前記第２の数字の組に適用するステップと、
前記電話番号「ｔｅｌ  ＵＲＩ」を生成するために、前記第３の数字の組の前に文字列「ｔｅｌ：」を付加するステップと、
を更に含むことを特徴とする請求項５に記載の方法。
【請求項９】
ネットワークであって、
ノードと、
変換モジュールと、
データベースと、
を備え、
前記ノードは、ＳＩＰ要求を受信し、前記ＳＩＰ要求がＳＩＰ  ＵＲＩ／埋め込み電話番号を有するか否かを判定し、
有する場合、前記ノードは、前記ＳＩＰ  ＵＲＩ／埋め込み電話番号を前記変換モジュールに転送し、
有さない場合、前記ノードは、前記ＳＩＰ要求を次にどこへルーティングするかを判断する目的で前記データベースに問い合わせるために、前記埋め込み電話番号を有さない前記ＳＩＰ  ＵＲＩを使用し、
前記変換モジュールは、認識可能な国際番号を前記ＳＩＰ  ＵＲＩ／埋め込み電話番号が有するか否かを判定し、
有さない場合、前記変換モジュールは、エラーメッセージを前記ノードへ送信し、
有する場合、前記変換モジュールは、前記ＳＩＰ  ＵＲＩ／埋め込み電話番号を用いて電話番号ｔｅｌ  ＵＲＩ」を生成し、当該電話番号「ｔｅｌ  ＵＲＩ」を前記ノードへ送信し、前記ノードは、前記ＳＩＰ要求を次にどこへルーティングするかを判断する目的で前記データベースに問い合わせるために、当該電話番号「ｔｅｌ  ＵＲＩ」を使用する
ことを特徴とするネットワーク。
【請求項１０】
前記ノードは、「ｕｓｅｒ＝ｐｈｏｎｅ」引数を伴うＲｅｑｕｅｓｔ  ＵＲＩを前記ＳＩＰ要求が有する場合に、前記ＳＩＰ要求がＳＩＰ  ＵＲＩ／埋め込み電話番号を有すると判断することを特徴とする請求項９に記載のネットワーク。
【請求項１１】
前記ノードは、前記変換モジュールから前記電話番号「ｔｅｌ  ＵＲＩ」を受信すると、前記ＳＩＰ要求において前記ＳＩＰ  ＵＲＩ／埋め込み電話番号を前記電話番号「ｔｅｌ  ＵＲＩ」に置換し、この改変されたＳＩＰ要求をルーティングすることを特徴とする請求項９に記載のネットワーク。
【請求項１２】
前記ノードは、インテロゲーティング呼セッション制御機能またはサービング呼セッション制御機能であることを特徴とする請求項９に記載のネットワーク。
【請求項１３】
前記データベースは、前記電話番号「ｔｅｌ  ＵＲＩ」に関する情報を含むが、前記ＳＩＰ  ＵＲＩ／埋め込み電話番号に関する情報を含まないことを特徴とする請求項９に記載のネットワーク。
【請求項１４】
前記データベースは、加入者ロケータ機能またはホーム加入者サーバであることを特徴とする請求項９に記載のネットワーク。
【請求項１５】
前記変換モジュールは、前記ＳＩＰ  ＵＲＩ／埋め込み電話番号が「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含まない場合に、
前記ＳＩＰ  ＵＲＩ／埋め込み電話番号から目標ユーザ部分を抽出するステップと、
前記電話番号「ｔｅｌ  ＵＲＩ」を生成するために文字列「ｔｅｌ：」を前記目標ユーザ部分の前に付加するステップと、
を実行することを特徴とする請求項９に記載のネットワーク。
【請求項１６】
前記変換モジュールは、前記ＳＩＰ  ＵＲＩ／埋め込み電話番号が「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含む場合に、
前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の後ろに位置する第１の数字の組を抽出するステップと、
前記ＳＩＰ  ＵＲＩ／埋め込み電話番号中の「ｓｉｐ：」の後ろで前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の前に位置する第２の数字の組を抽出するステップと、
前記電話番号「ｔｅｌ  ＵＲＩ」を生成するために、前記第２の数字の組が後ろに挿入される前記第１の数字の組の前に文字列「ｔｅｌ：」を付加するステップと、
を実行することを特徴とする請求項９に記載のネットワーク。
【請求項１７】
前記変換モジュールは、前記ＳＩＰ  ＵＲＩ／埋め込み電話番号が「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含む場合に、
前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の後ろに位置する第１の数字の組を抽出するステップと、
前記ＳＩＰ  ＵＲＩ／埋め込み電話番号中の「ｓｉｐ：」の後ろで前記「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の前に位置する第２の数字の組を抽出するステップと、
一連の置換規則を見つけるための事前定義された置換規則のテーブルへのキーとして前記第１の数字の組を使用するステップと、
第３の数字の組を生成するために前記一連の置換規則を前記第２の数字の組に適用するステップと、
前記電話番号「ｔｅｌ  ＵＲＩ」を生成するために、前記第３の数字の組の前に文字列「ｔｅｌ：」を付加するステップと、
を実行することを特徴とする請求項９に記載のネットワーク。
【請求項１８】
着信ネットワークにおいてＳＩＰ要求をサービング呼セッション制御機能へルーティングするインテロゲーティング呼セッション制御機能であって、
前記ＳＩＰ要求を受信する受信器と、
ＳＩＰ  ＵＲＩ／埋め込み電話番号を含む要求ＵＲＩを前記ＳＩＰ要求が有するか否かを判定するプロセッサと、
前記要求ＵＲＩを変換モジュールへ転送し、当該変換モジュールから対応するｔｅｌ  ＵＲＩを受信するクエリ装置と、
を備え、
前記プロセッサは、改変されたＳＩＰ要求を形成するために、前記ＳＩＰ要求の前記要求ＵＲＩにおいて、前記ＳＩＰ  ＵＲＩ／埋め込み電話番号を削除して前記受信したｔｅｌ  ＵＲＩを挿入し、
当該インテロゲーティング呼セッション制御機能は、
前記ｔｅｌ  ＵＲＩを伴う前記要求ＵＲＩを含む前記改変されたＳＩＰ要求を前記サービング呼セッション制御機能へ送信する送信器を更に備える
ことを特徴とするインテロゲーティング呼セッション制御機能。
【請求項１９】
前記プロセッサは、前記要求ＵＲＩ中に「ｕｓｅｒ＝ｐｈｏｎｅ」引数が存在する場合に、前記ＳＩＰ要求が前記ＳＩＰ  ＵＲＩ／埋め込み電話番号を有すると判断することを特徴とする請求項１８に記載のインテロゲーティング呼セッション制御機能。
【請求項２０】
前記変換モジュールから前記対応するｔｅｌ  ＵＲＩを受信すると、前記プロセッサは、前記ＳＩＰ要求において前記ＳＩＰ  ＵＲＩ／埋め込み電話番号を前記対応するｔｅｌ  ＵＲＩに置換し、この改変されたＳＩＰ要求をルーティングすることを特徴とする請求項１８に記載のインテロゲーティング呼セッション制御機能。
【請求項２１】
中継ネットワークを通って着信ネットワークへＳＩＰ要求をルーティングするサービング呼セッション制御機能であって、
前記ＳＩＰ要求を受信する受信器と、
ＳＩＰ  ＵＲＩ／埋め込み電話番号を含む要求ＵＲＩを前記ＳＩＰ要求が有するか否かを判定するプロセッサと、
前記要求ＵＲＩを変換モジュールへ転送し、当該変換モジュールから対応するｔｅｌ  ＵＲＩを受信するクエリ装置と、
を備え、
前記プロセッサは、改変されたＳＩＰ要求を形成するために、前記ＳＩＰ要求の前記要求ＵＲＩにおいて、前記ＳＩＰ  ＵＲＩ／埋め込み電話番号を削除して前記受信したｔｅｌ  ＵＲＩを挿入し、
当該サービング呼セッション制御機能は、
前記ｔｅｌ  ＵＲＩを伴う前記改変されたＳＩＰ要求を前記着信ネットワークへ送信する送信器を更に備える
ことを特徴とするサービング呼セッション制御機能。
【請求項２２】
前記プロセッサは、前記要求ＵＲＩ中に「ｕｓｅｒ＝ｐｈｏｎｅ」引数が存在する場合に、前記ＳＩＰ要求が前記ＳＩＰ  ＵＲＩ／埋め込み電話番号を有すると判断することを特徴とする請求項２１に記載のサービング呼セッション制御機能。
【請求項２３】
前記変換モジュールから前記対応するｔｅｌ  ＵＲＩを受信すると、前記プロセッサは、前記ＳＩＰ要求において前記ＳＩＰ  ＵＲＩ／埋め込み電話番号を前記対応するｔｅｌ  ＵＲＩに置換し、この改変されたＳＩＰ要求をルーティングすることを特徴とする請求項２１に記載のサービング呼セッション制御機能。
【発明の詳細な説明】
【技術分野】
【０００１】
＜以前に出願された米国出願の利益を主張する＞
本願は、２００５年１０月２１日に出願され、「Ｔｅｌ−ＵＲＩを用いた、ＩＭＳ呼のルーティング」と題された米国仮出願第６０／７２９，０１２号の利益を主張する。この文書の内容は、ここに参照により本願に援用する。
【０００２】
＜技術分野＞
本発明は一般に、特定の目標ユーザの識別子として（埋め込まれた形で電話番号を持つＳＩＰ  ＵＲＩではなく）電話番号であるｔｅｌ  ＵＲＩを用いて目標ユーザまでの呼のルーティングを可能にする、ＩＭＳ着信ネットワーク(terminating network)に関する。
【背景技術】
【０００３】
ここでは下記の略語を定義する。少なくともその一部は、以下の先行技術および本発明の記述の中で言及される。
【０００４】
３ＧＰＰ        第３世代パートナシップ・プロジェクト
ＡＳ            アプリケーション・サーバ
ＣＳＣＦ        呼セッション制御機能
ＤＮＳ          ドメイン・ネーム・システム
ＨＳＳ          ホーム加入者サーバ
ＩＡＭ          初期アドレスメッセージ
ＩＢＣＦ        インタワーキング・ボーダ制御機能
Ｉ−ＣＳＣＦ    インテロゲーティングＣＳＣＦ
ＩＭＳ          ＩＰマルチメディア・サブシステム
ＩＰ            インターネット・プロトコル
ＭＧＣＦ        メディア・ゲートウェイ制御機能
ＭＭＳ          マルチメディア・メッセージング・サービス
ＰＯＴＳ        普通の旧来の電話サービス(Plain Old Telephone Service)
ＰＳＴＮ        公衆交換電話網
ＰＵＩ          パブリック・ユーザ・アイデンティティ
ＲＦＣ          リクエスト・フォー・コメント
ＲＴＰ          リアルタイム・トランスポート・プロトコル
Ｓ−ＣＳＣＦ    サービングＣＳＣＦ
ＳＩＰ          セッション開始プロトコル
ＳＬＦ          加入者ロケータ機能
ＴＣＰ          伝送制御プロトコル
ＵＡ            ユーザ・エージェント
ＵＥ            ユーザ装置
ＵＲＩ          ユニフォーム・リソース識別子
ＵＴＭ          ＵＲＩ翻訳モジュール
【０００５】
ＩＭＳネットワークは、ＩＭＳネットワークのユーザ・エージェント（ＵＡ）および他の従来型ネットワークのユーザ装置（ＵＥ）が、他のＵＡとのマルチメディア・セッションを確立することを可能にし、それらが、あらゆる種類のリアルタイム情報（例えば音声、動画）または非リアルタイム情報（例えばメッセージ、写真）をも交換できるようにする、ＩＰベースのネットワークである。現状ではＩＭＳネットワークは、マルチメディア・セッションを確立するのにＳＩＰプロトコルを使用し、マルチメディア・セッションのペイロードを搬送するのにＲＴＰのような伝送プロトコルを使用する。
【０００６】
ＩＭＳネットワークでは、目標ユーザを識別するＵＲＩを用いて、且つ、ＩＭＳネットワーク内のすべての要素が従わなければならない厳密に定義された一連のルーティング規則を用いて、そのユーザとの間で確立されたマルチメディア・セッション上で情報がルーティングされる。この一連の規則は、「セッション開始プロトコル（ＳＩＰ）およびセッション記述プロトコル（ＳＤＰ）に基づくＩＰマルチメディア呼制御プロトコル」と題された３ＧＰＰ  ＴＳ  ２４．２２９  Ｖ．５．１４．０（２００５年１０月）（その内容は参照により本願に援用する）の中で３ＧＰＰ準拠のＩＭＳネットワークのために定義されている。
【０００７】
マルチメディア・セッションを確立する場合に特定の目標ユーザを識別するのに用いられうるＵＲＩには２つのタイプがあり、すなわち、（１）ＳＩＰ  ＵＲＩと（２）ｔｅｌ  ＵＲＩである。ＳＩＰ  ＵＲＩは、２００２年６月の「ＳＩＰ：セッション開始プロトコル」と題されたＲＦＣ３２６１（その内容は参照により本願に援用する）の中で定義される形式を持つ。ＳＩＰ  ＵＲＩの例をあげると次のようになる。
【０００８】
sip:peter@yahoo.com
sip:James.Rowling@RowlingAndAssociates.co.uk
sip:voice_mail@vodafone.com;reason=no_answer
【０００９】
他方、ｔｅｌ  ＵＲＩの形式は、「電話番号のためのｔｅｌ  ＵＲＩ」と題されたＲＦＣ３９６６（その内容は参照により本願に援用する）の中で定義される。ｔｅｌ  ＵＲＩの例をあげると次のようになる。
【００１０】
tel:+1-234-567-89
tel:2997;phone-context=+3491339
【００１１】
加えて、ＲＦＣ３２６１の中で論じられていることであるが、埋め込まれたｔｅｌ  ＵＲＩを持つＳＩＰ  ＵＲＩを表す方法もある。例えば、典型的なｔｅｌ  ＵＲＩを、次のようにＳＩＰ  ＵＲＩの中に埋め込むこともできよう。
【００１２】
sip:+1-234-567-89@cingular.com;user=phone
sip:2997;phone-context=+3491339@vodafone.com;user=phone
【００１３】
上記の一連のルーティング規則の１つのセクションは、２つの異なるネットワークオペレータ間で呼をルーティングすることに充てられている。具体的には、２つのネットワークオペレータ間で呼をルーティングする場合、呼の目標ユーザを識別するためには、ＳＩＰ  ＵＲＩもしくはＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩが使用されなければならない。図１（先行技術）は、第１のルーティングプロセス、すなわち、発信ネットワーク１０２に位置するＵＡ１から着信／宛先ネットワーク１０４に位置するＵＡ２まで呼をルーティングするためにＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩを使用するオペレータ間プロセス、を記述する一助とするのに用いられる信号フロー図である。ステップは、以下のようである（詳細については、３ＧＰＰ  ＴＳ  ２４．２２９を参照する）。
【００１４】
１−３．  発信Ｓ−ＣＳＣＦ１が、ＵＡ１からＳＩＰ要求（例えばＩＮＶＩＴＥ  ｔｅｌ：＋１２３）を受信する（ステップ１）。Ｓ−ＣＳＣＦ１は、受信したセッション開始ＩＮＶＩＴＥ要求からＲｅｑｕｅｓｔ−ＵＲＩ（要求ＵＲＩ）を取り込み、Ｒｅｑｕｅｓｔ−ＵＲＩがｔｅｌ  ＵＲＩを含む場合、Ｓ−ＣＳＣＦ１は、ＥＮＵＭ１サービスに問い合わせを行う（ステップ２）。ＥＮＵＭ１は、ｔｅｌ  ＵＲＩをＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩ（例えば、ｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）に変更し、それをＳ−ＣＳＣＦ１へ送信する（ステップ３）。Ｓ−ＣＳＣＦ１は、ＳＩＰ要求の中の最初のＲｅｑｕｅｓｔ−ＵＲＩを、クエリから取得したＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩと置き換えて、新規のＳＩＰ要求（例えば、ＩＮＶＩＴＥ  ｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）を形成する。
【００１５】
４．  発信Ｓ−ＣＳＣＦ１は、新規のＲｅｑｕｅｓｔ−ＵＲＩのドメイン部分（例えばｏｐ．ｃｏｍ）を取り込み、新規のＩＮＶＩＴＥ  ＳＩＰ要求を、そのドメインで識別されるアドレスまで転送する（ドメインが、ＩＰｖ４アドレスもしくはＩＰｖ６アドレスである場合、ＩＮＶＩＴＥをそのアドレスに直接転送可能であるし、それ以外の場合は、着信ネットワーク１０４の中のＩＢＣＦかまたはＩ−ＣＳＣＦ２のいずれか一方に対応する宛先ＩＰアドレスを取得するため、ドメイン部を用いてＤＮＳに問い合わせを行う必要がある）。この例では、Ｓ−ＣＳＣＦ１は、新規のＳＩＰ要求（例えばＩＮＶＩＴＥ  ｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）を直接Ｉ−ＣＳＣＦ２まで転送する（ステップ４）。
【００１６】
５−６．  Ｉ−ＣＳＣＦ２は、着信呼について接触される最初のＣＳＣＦであり、呼の目標であるＵＡ２にサービス提供するＳ−ＣＳＣＦ２を特定する役割を持つ。ＵＡ２にサービス提供するＳ−ＣＳＣＦ２を特定するため、Ｉ−ＣＳＣＦ２は、（１）ＳＬＦ２および（２）ＨＳＳ２という、２つのネットワーク・データベースの使用が必要になることがある。ＳＬＦ２は、（どのＳ−ＣＳＣＦ２が現時点でサービス提供しているかも含めて）ＵＡ２の加入者データを保持する特定のＨＳＳ２インスタンスを見つける、データベース特定機能であり、着信ネットワーク１０４内に複数のＨＳＳインスタンスがある場合に使用される。この例では、Ｉ−ＣＳＣＦ２は、ＳＩＰ要求の中のＲｅｑｕｅｓｔ−ＵＲＩを、クエリ（例えば、Ｄｘ−Ｌｏｃａｔｉｏｎ−Ｑｕｅｒｙ  ＰＵＩ＝ｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）をＳＬＦ２まで送信するためのパブリック・ユーザ・アイデンティティとして使用する（ステップ５）。次いで、ＳＬＦ２は、ＨＳＳ２を示す応答（例えば、Ｄｘ−Ｌｏｃａｔｉｏｎ−Ｑｕｅｒｙ＿Ｒｓｐ  Ｓｅｒｖｅｒ−Ｎａｍｅ＝ＨＳＳ２）をＩ−ＣＳＣＦ２へ返信する。ネットワーク内に一意のＨＳＳが存在する場合、ＳＬＦ２およびステップ５乃至６は省略されてもよい。
【００１７】
７−８．  Ｉ−ＣＳＣＦ２は、ＳＩＰ要求の中のＲｅｑｕｅｓｔ−ＵＲＩを、クエリ（例えば、Ｃｘ−Ｌｏｃａｔｉｏｎ−Ｑｕｅｒｙ  ＰＵＩ＝ｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）をＨＳＳ２まで送信するためのパブリック・ユーザ・アイデンティティとして使用する（ステップ７）。次いでＨＳＳ２は、Ｓ−ＣＳＣＦ２を示す応答（例えば、Ｃｘ−Ｌｏｃａｔｉｏｎ−Ｑｕｅｒｙ＿Ｒｓｐ  Ｓｅｒｖｅｒ−Ｎａｍｅ＝Ｓ−ＣＳＣＦ２）をＩ−ＣＳＣＦ２に返信する（ステップ８）。
【００１８】
９−１０．  一旦Ｉ−ＣＳＣＦ２がＳ−ＣＳＣＦ２を特定すると、Ｉ−ＣＳＣＦ２は、呼（例えばＩＮＶＩＴＥ  ｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）をそのＳ−ＣＳＣＦ２までルーティングする（ステップ９）。次いで、着信Ｓ−ＣＳＣＦ２は、その内部位置テーブルを使って、目標ユーザＵＡ２によって登録された連絡先アドレス（上記の例において、この連絡先アドレスは、Ｂ−ＵＥ＠ｏｐ．ｃｏｍである）までＩＮＶＩＴＥ要求をルーティングする（ステップ１０）。登録された連絡先アドレスはないけれども、目標ユーザＵＡ２が、未登録状態である何らかのサービスを起動していた場合、Ｓ−ＣＳＣＦ２は、ＳＩＰ要求を、Ｓ−ＣＳＣＦ２内に記憶されたサービス情報によって示されたＡＳまで転送する。
【００１９】
図２（先行技術）を参照すると、第２のルーティングプロセス、すなわち、上記のようなリモートネットワーク１０２においてピアＳ−ＣＳＣＦ１から呼が来るのではなく代わりにＭＧＣＦ１から来る場合に発生するルーティングプロセスを記述する一助とするのに用いられる信号フロー図がある。この特定の第２のルーティングプロセスは、ユーザＵＥ３がＰＳＴＮ２０２の中に位置していて、ＩＭＳ着信ネットワーク１０４の中に位置するＵＡ２に対してｔｅｌ  ＵＲＩを用いて呼を開始する場合に発生する。この特定のルーティングプロセスのステップは、以下のとおりである（詳細については、３ＧＰＰ  ＴＳ  ２４．２２９を参照する）。
【００２０】
１ａ．  ＭＧＣＦ１は、ＵＥ３から送信されたＩＡＭを受信するＰＳＴＮシグナリング・インタフェースを有する（ステップ１ａ）。ＭＧＣＦ１は、ＩＡＭを用いて目標ユーザのＥ．１６４番号を取得し、（Ｅ．１６４番号を含む）ｔｅｌ  ＵＲＩかまたは（Ｅ．１６４番号を埋め込んだ）ＳＩＰ  ＵＲＩのいずれか一方を有するＲｅｑｕｅｓｔ−ＵＲＩフィールドを含むＩＮＶＩＴＥ  ＳＩＰ要求を生成する。
【００２１】
２ａ．  この特定の例において、ＩＮＶＩＴＥ  ＳＩＰ要求は、ｔｅｌ  ＵＲＩ（例えばｔｅｌ：＋１２３）を含む（このステップ２ａを図１のステップ４と比較されたい）。ＭＧＣＦ１は、ＩＮＶＩＴＥ  ＳＩＰ要求（例えばＩＮＶＩＴＥ  ｔｅｌ：＋１２３）を、着信ネットワーク１０４に位置するＩ−ＣＳＣＦ２まで転送する（ステップ２ａ）。
【００２２】
３ａ−８ａ．  ステップ３ａ乃至８ａは、ＳＩＰ  ＵＲＩ（例えばｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）ではなくｔｅｌ  ＵＲＩ（例えばｔｅｌ：＋１２３）が信号の一部において使用されることを除いて、図１に示す前のルーティング手順におけるステップ５乃至１０と同様である。
【発明の開示】
【発明が解決しようとする課題】
【００２３】
残念ながら、上記のルーティング手順には、若干の問題がある。
【００２４】
１．第１のルーティングプロセスにおいて、呼を開始するのに用いられる目標電話番号が、ＩＮＶＩＴＥ  ＳＩＰ要求が着信ネットワーク１０４に到達する前に失われる。特に、発信Ｓ−ＣＳＣＦ１が、最初にダイアルされたｔｅｌ  ＵＲＩをＥＮＵＭ１から取得されたＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩと置き換える際に、目標電話番号が、発信Ｓ−ＣＳＣＦ１によってＳＩＰ要求の中の要求−ＵＲＩから除去される（ステップ２乃至３を参照）。着信ネットワーク１０４が、この電話番号をある種のサービス（例えばＭＭＳ）に提供することが必要になることがあるため、これはあまり望ましくない。
【００２５】
２．いずれのルーティングプロセスにおいても、着信ネットワーク１０４内で呼を内部的にルーティングするために、ＨＳＳ２内のユーザプロフィールと、ＳＬＦ２内のユーザ−サーバ間の関連付けとには、ｔｅｌ  ＵＲＩとそのｔｅｌ  ＵＲＩのＳＩＰ形式（ＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩ）とが両方共含まれていなければならない。ルーティング手順では、着信ネットワーク１０４で受信されたＳＩＰ要求が、ＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩ（図１を参照）かまたはｔｅｌ  ＵＲＩ（図２を参照）のいずれか一方を含むことがある事例があることから、このことは必要である。所与の発信ネットワーク１０２によってどの形式が実際に使用されるのか事前に分らないことから、着信ネットワーク１０４内で内部的に呼をルーティングできるためには、ＳＬＦ２内のユーザ−サーバ間の関連付けとＨＳＳ２内のユーザプロフィールとは、ｔｅｌ  ＵＲＩとそのｔｅｌ  ＵＲＩのＳＩＰ形式（ＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩ）とを両方共含む必要がある。従って、ＳＬＦ２とＨＳＳ２とは、それぞれ、ｔｅｌ  ＵＲＩとＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩとの両方について重複した情報を維持する必要があり、それは管理上の負荷を増加させるだけでなく、メモリスペースを無駄遣いする。これは望ましくない。
【００２６】
従って、先行技術に関連するこれらの短所およびその他の短所に取り組む必要性がこれまでもあったし、今もある。これらの必要性およびその他の必要性は、本発明によって満たされる。
【課題を解決するための手段】
【００２７】
本発明は、呼の目標ユーザの識別子として電話番号（そして、埋め込まれた電話番号を持つＳＩＰ  ＵＲＩではなく）を用いて呼のルーティングを可能にする目的で、ＩＭＳ着信ネットワーク内でのｔｅｌ  ＵＲＩの特定の取扱を提案する。具体的には、本発明は変換モジュールを導入し、その変換モジュールは、ＩＭＳ着信ネットワーク内に位置していて、埋め込まれた電話番号を持つＳＩＰ  ＵＲＩを、同等のｔｅｌ  ＵＲＩに変換することができ、それが次いで、呼を目標ユーザまでルーティングできるように着信Ｉ−ＣＳＣＦおよびＳ−ＣＳＣＦによってＳＬＦおよび／またはＨＳＳに問い合わせを行うために使用される。
【００２８】
あるシナリオにおいて、変換モジュールは、ＳＩＰ  ＵＲＩ／埋め込み電話番号付（電話番号が埋め込まれたＳＩＰ  ＵＲＩ）を、同等のｔｅｌ  ＵＲＩに変換することができるが、それは（１）目標ユーザ部分をＳＩＰ  ＵＲＩ／埋め込み電話番号付から抽出すること、および（２）同等のｔｅｌ  ＵＲＩを生成するために、「ｔｅｌ：」という文字列を目標ユーザ部分の前に付ける（付加する）こと、によって可能になる。別のシナリオにおいて、変換モジュールは、ＳＩＰ  ＵＲＩ／埋め込み電話番号付を、同等のｔｅｌ  ＵＲＩに変換することができるが、それは（１）第１の数字の組、すなわち、ＳＩＰ  ＵＲＩ／埋め込み電話番号付の中の「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の後に位置するｐｈｏｎｅ  ｃｏｎｔｅｘｔ記述子（ｐｈｏｎｅ  ｃｏｎｔｅｘｔ記述子は、ドメイン名でもよいし国際ネットワーク・プレフィックスでもよい）を抽出すること、（２）ＳＩＰ  ＵＲＩ／埋め込み電話番号付の中の「ｓｉｐ：」引数の後で且つ「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の前に位置する第２の数字の組を抽出すること、および（３）同等のｔｅｌ  ＵＲＩを生成するために、「ｔｅｌ：」という文字列を第１の数字の組の前に付け、その後に第２の数字の組が挿入されること、によって可能になる。更に別のシナリオにおいて、変換モジュールはＳＩＰ  ＵＲＩ／埋め込み電話番号付を、同等のｔｅｌ  ＵＲＩに変換することができるが、それは（１）第１の数字の組、すなわち、「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の後に位置するｐｈｏｎｅ  ｃｏｎｔｅｘｔ記述子を抽出すること、（２）「ｓｉｐ：」引数の後で且つ「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の前に位置する第２の数字の組を抽出すること、（３）第１の数字の組（ｐｈｏｎｅ  ｃｏｎｔｅｘｔ記述子／国際ネットワーク・プレフィックス）を、一連の置換規則を見つけるための事前定義された置換規則のテーブルへの手がかり（キー）として使用すること、（４）これらの置換規則を第２の数字の組に適用して第３の数字の組を生成すること、そして、（５）同等のｔｅｌ  ＵＲＩを生成するために、「ｔｅｌ：」という文字列を第３の数字の組の前に付けること、によって可能になる。
【００２９】
更に、本発明は、ＳＩＰ要求を受信するための受信器と、ＳＩＰ  ＵＲＩ／埋め込み電話番号（電話番号が埋め込まれたＳＩＰ  ＵＲＩ）を含む要求ＵＲＩをＳＩＰ要求が有するかどうか判断するためのプロセッサとを有する、Ｉ−ＣＳＣＦを含む。あるシナリオにおいて、要求ＵＲＩの中に「ｕｓｅｒ＝ｐｈｏｎｅ」引数がある場合に、ＳＩＰ要求がＳＩＰ  ＵＲＩ／埋め込み電話番号を有する、とプロセッサは判断する。ＳＩＰ要求がＳＩＰ  ＵＲＩ／埋め込み電話番号を有する場合、Ｉ−ＣＳＣＦは、要求ＵＲＩを（ＳＩＰ  ＵＲＩ／埋め込み電話番号から対応するｔｅｌ  ＵＲＩを生成する）変換モジュールまで転送し、次いで変換モジュールから対応するｔｅｌ  ＵＲＩを受信する、クエリ装置を有する。その後、プロセッサは、ＳＩＰ  ＵＲＩ／埋め込み電話番号を削除して、受信したｔｅｌ  ＵＲＩをＳＩＰ要求の要求ＵＲＩに挿入し、改変されたＳＩＰ要求を形成する。最後に、Ｉ−ＣＳＣＦは、対応するｔｅｌ  ＵＲＩの付いた要求ＵＲＩを含む改変されたＳＩＰ要求をＳ−ＣＳＣＦへ提出（送信）する送信器を有する。
【００３０】
加えて、本発明は、ＳＩＰ要求を受信するための受信器と、ＳＩＰ  ＵＲＩ／埋め込み電話番号を含む要求ＵＲＩをＳＩＰ要求が有するかどうか判断するためのプロセッサとを有する、Ｓ−ＣＳＣＦを含む。あるシナリオにおいて、要求ＵＲＩの中に「ｕｓｅｒ＝ｐｈｏｎｅ」引数がある場合に、ＳＩＰ要求がＳＩＰ  ＵＲＩ／埋め込み電話番号を有する、とプロセッサは判断する。ＳＩＰ要求がＳＩＰ  ＵＲＩ／埋め込み電話番号を有する場合、Ｓ−ＣＳＣＦは、要求ＵＲＩを（ＳＩＰ  ＵＲＩ／埋め込み電話番号から対応するｔｅｌ  ＵＲＩを生成する）変換モジュールまで転送し、次いで変換モジュールから対応するｔｅｌ  ＵＲＩを受信する、クエリ装置を有する。その後、プロセッサは、ＳＩＰ  ＵＲＩ／埋め込み電話番号を削除して、受信したｔｅｌ  ＵＲＩをＳＩＰ要求の要求ＵＲＩに挿入し、改変されたＳＩＰ要求を形成する。最後に、Ｓ−ＣＳＣＦは、対応するｔｅｌ  ＵＲＩの付いた要求ＵＲＩを含む改変されたＳＩＰ要求を着信ネットワークへ送信する送信器を有する。
【００３１】
本発明の利点は、Ｉ−ＣＳＣＦとＳ−ＣＳＣＦとが、同等のｔｅｌ  ＵＲＩを用いて呼をルーティングすることができることから、ＳＬＦおよび／またはＨＳＳ（ＳＬＦ及びＨＳＳのうちの少なくとも一方）が、目標ユーザのｔｅｌ  ＵＲＩを維持するだけでよく、目標ユーザのｔｅｌ  ＵＲＩとＳＩＰ  ＵＲＩ／埋め込み電話番号とを両方共維持しなくてもよいことである。本発明のもう１つの利点は、発信ネットワーク内のＳ−ＣＳＣＦによってＳＩＰ要求から取り除かれていたかもしれない、発信時にダイアルされた目標ユーザの電話番号を変換モジュールが取得できることであり、着信ネットワークが、例えばＭＭＳのような電話番号に基づくサービスまたは旧来のサービスをサポートするために発信電話番号を必要とすることがあることから、これは望ましいことである。
【００３２】
本発明のより完全な理解は、添付の図面に関連して下記の詳細な説明を参照することで得られるであろう。
【発明を実施するための最良の形態】
【００３３】
図３を参照すると、本発明を説明する一助とするのに用いられる、（Ｉ−ＣＳＣＦ３０２ａとＳ−ＣＳＣＦ３０２ｂとを含む）ＣＳＣＦ３０２と、ＳＬＦ３０４と、ＨＳＳ３０６と、ＵＴＭ３０８とを有する典型的なＩＭＳ着信ネットワーク３００のブロック図がある。図示するように、Ｉ−ＣＳＣＦ３０２ａは、もしあるならばＳＬＦ３０４と、そしてＨＳＳ３０６と、リンク３１０および３１２を介してそれぞれ通信し、他方、Ｓ−ＣＳＣＦ３０２ｂは、ＨＳＳ３０６とリンク３１４を介してそれぞれ通信する。加えて、Ｉ−ＣＳＣＦ３０２ａとＳ−ＣＳＣＦ３０２ｂとは、例えばＴＣＰ／ＩＰ上で動作するクエリ応答プロトコルを用いて、リンク３１６および３１８上でＵＴＭ３０８とそれぞれ通信する。あるいは、ＵＴＭ３０８は、ＣＳＣＦ３０２と、具体的にはＩ−ＣＳＣＦ３０２ａもしくはＳ−ＣＳＣＦ３０２ｂと統合されてもよく、その場合、それらの間の通信リンクは、ＣＳＣＦ３０２の外側からは見えない内部リンクであってもよいだろう。または、ＵＴＭ３０８は、ＳＬＦ３０４およびＨＳＳ３０６と統合されてもよいであろうし、その場合、ＣＳＣＦ−ＵＴＭインタフェースをＣＳＣＦ−ＨＳＳインタフェース３１２、３１４（Ｃｘ）およびＣＳＣＦ−ＳＬＦインタフェース３１０（Ｄｘ）と結合することも可能であろう。ここで理解されるべきだが、当業者にはよく知られていて、本発明を理解するのに必要ない、ＣＳＣＦ３０２、ＳＬＦ３０４、ＨＳＳ３０６に関するその他の詳細を、本明細書で提供する記述では論じない。
【００３４】
図４を参照すると、（少なくとも受信器４０２、プロセッサ４０４、クエリ装置４０６、および送信器４０８を含む）Ｉ−ＣＳＣＦ３０２ａによって呼が受信された場合に、本発明によって呼はどのようにしてＳ−ＣＳＣＦ３０２ｂまでルーティングされうるかを説明する一助とするのに用いられる、典型的な信号フロー図がある。基本的に、Ｉ−ＣＳＣＦ３０２ａ、特に受信器４０２は、ＳＩＰ要求を受信すると、そのＲｅｑｕｅｓｔ  ＵＲＩがＳＩＰ  ＵＲＩ形式のｔｅｌ  ＵＲＩを含むかどうか（ステップ１乃至２を参照）を見るために、プロセッサ４０４にＳＩＰ要求を検査させる（しかし、ｔｅｌ  ＵＲＩは現時点では登録されていないため、ＲＥＧＩＳＴＥＲ  ＳＩＰ要求は検査しない）。これを行うため、Ｉ−ＣＳＣＦ３０２ａ、特にプロセッサ４０４は、Ｒｅｑｕｅｓｔ  ＵＲＩの中のＵＲＩ引数「ｕｓｅｒ＝ｐｈｏｎｅ」を探し、それを発見すると、Ｉ−ＣＳＣＦ３０２ａ、特にクエリ装置４０６は、クエリの中で完全なＲｅｑｕｅｓｔ  ＵＲＩをＵＴＭ３０８へ送信する（ステップ３を参照）。ＵＴＭ３０８は、（ａ）クエリを受信し、（ｂ）ＳＩＰ  ＵＲＩ／埋め込み電話番号を取り込み、（ｃ）同等のｔｅｌ  ＵＲＩを生成し、そして（ｄ）同等のｔｅｌ  ＵＲＩを含むクエリ応答をＩ−ＣＳＣＦ３０２ａへ返信する（ステップ４乃至５および図６を参照）ように機能する。
【００３５】
その後、Ｉ−ＣＳＣＦ３０２ａ、特に送信器４０８は、もしあればＳＬＦ３０４を、そしてＨＳＳ３０６に問い合わせをする場合、ＵＴＭ３０８から受信したｔｅｌ  ＵＲＩをパブリックＩＤとして用いる（ステップ６乃至９を参照）。加えて、Ｉ−ＣＳＣＦ３０２ａ、特にプロセッサ４０４は、送信器４０８が、改変されたＳＩＰ要求をＳ−ＣＳＣＦ３０２ｂへ送信できるように、最初のＳＩＰ要求の中のＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩをＵＴＭ３０８から受信したｔｅｌ  ＵＲＩと置き換える（ステップ１０を参照）。Ｉ−ＣＳＣＦ３０２ａが、最初のＳＩＰ要求の中のＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩをＵＴＭ３０８から受信したｔｅｌ  ＵＲＩと置き換えるのだから、これは、ＩＭＳ目標ネットワーク３００の内側での改変されたＳＩＰ要求のルーティングは、それ以降、ｔｅｌ  ＵＲＩに基づいて行えるということを意味する。結果として、ＳＬＦ３０４およびＨＳＳ３０６は、ｔｅｌ  ＵＲＩに関連するパブリックＩＤを記憶するだけでよく、ｔｅｌ  ＵＲＩとＳＩＰ形式のそのｔｅｌ  ＵＲＩとの両方についてパブリックＩＤを記憶しなくてもよい。これは、ＳＬＦ２とＨＳＳ２とがｔｅｌ  ＵＲＩとＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩとの両方について情報を記憶する必要があった従来のルーティングプロセスに比べて著しい進歩である。
【００３６】
図５を参照すると、中継ネットワークにおいて（少なくとも受信器５０２、プロセッサ５０４、クエリ装置５０６、送信器５０８を含む）Ｓ−ＣＳＣＦ３０２ｂによって呼が受信された場合、本発明によって呼はどのようにして次のホップ３２０までルーティングされうるかを説明する一助とするのに用いられる、典型的な信号フロー図がある。基本的に、Ｓ−ＣＳＣＦ３０２ｂ、特に受信器５０２は、ＳＩＰ要求を受信すると、そのＲｅｑｕｅｓｔ  ＵＲＩがｔｅｌ  ＵＲＩのＳＩＰ  ＵＲＩ形式を含むかどうかを見るために、プロセッサ５０４にＳＩＰ要求を検査させる（しかし、ｔｅｌ  ＵＲＩは現時点では登録されていないため、ＲＥＧＩＳＴＥＲ  ＳＩＰ要求は検査しない）（ステップ１乃至２を参照）。これを行うため、Ｓ−ＣＳＣＦ３０２ｂ、特にプロセッサ５０４は、Ｒｅｑｕｅｓｔ  ＵＲＩの中のＵＲＩ引数「ｕｓｅｒ＝ｐｈｏｎｅ」を探し、それを発見すると、Ｓ−ＣＳＣＦ３０２ｂ、特にクエリ装置５０６は、クエリの中で完全なＲｅｑｕｅｓｔ  ＵＲＩをＵＴＭ３０８へ送信する（ステップ３を参照）。ＵＴＭ３０８は、（ａ）クエリを受信し、（ｂ）ＳＩＰ  ＵＲＩ／埋め込み電話番号を取り込み、（ｃ）同等のｔｅｌ  ＵＲＩを生成し、そして（ｄ）同等のｔｅｌ  ＵＲＩを含むクエリ応答をＳ−ＣＳＣＦ３０２ｂまで返信する（ステップ４乃至５および図６を参照）ように機能する。
【００３７】
その後、Ｓ−ＣＳＣＦ３０２ｂ、特に送信器５０８は、ＳＬＦ３０４とＨＳＳ３０６とに問い合わせをする場合、ＵＴＭ３０８から受信したｔｅｌ  ＵＲＩをパブリックＩＤとして用いる（ステップ６乃至９を参照）。加えて、Ｓ−ＣＳＣＦ３０２ｂ、特にプロセッサ５０４は、送信器５０８が、改変されたＳＩＰ要求を次のホップ３２０へ送信できるように、ＳＩＰ要求の中のＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩをＵＴＭ３０８から受信したｔｅｌ  ＵＲＩと置き換える（ステップ１０を参照）。Ｓ−ＣＳＣＦ３０２ｂは、最初のＳＩＰ要求の中のＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩをＵＴＭ３０８から受信したｔｅｌ  ＵＲＩと置き換えるのだから、これは、ＩＭＳ目標ネットワーク３００の内側での改変されたＳＩＰ要求のルーティングは、それ以降、ｔｅｌ  ＵＲＩに基づいて行えるということを意味する。結果として、ＳＬＦ３０４およびＨＳＳ３０６は、ｔｅｌ  ＵＲＩに関連するパブリックＩＤを記憶するだけでよく、ｔｅｌ  ＵＲＩとＳＩＰ形式のそのｔｅｌ  ＵＲＩとの両方についてパブリックＩＤを記憶しなくてもよい。これは、ＳＬＦ２とＨＳＳ２とがｔｅｌ  ＵＲＩとＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩとの両方について情報を記憶する必要があった従来のルーティングプロセスに比べて著しい進歩である。
【００３８】
上記の２つの実施形態のいずれにおいても、ＵＴＭ３０８から送信されたクエリ応答が、エラーコードまたはエラーメッセージを含むことが起きるかもしれない（下記の説明を参照）。その場合、Ｉ−ＣＳＣＦ３０２ａ／Ｓ−ＣＳＣＦ３０２ｂは、例えば「ｔｅｌ  ＵＲＩ内のドメインが間違い」のような何らかの記述テキストを含む４０４（見つからなかった(not found)）応答を発信者に返信することによって、要求に答えてもよいだろう。これは、ＳＩＰ要求を開始した発信者に、ｔｅｌ  ＵＲＩの代わりにＳＩＰ  ＵＲＩを用いてＳＩＰ要求を再送信する機会を与えることになるが、但しそれを行うことが可能な場合に限る（例えば、ＰＯＴＳ電話を用いる発信者は、ＳＩＰ  ＵＲＩを用いて要求を再送信することはできないであろう）。
【００３９】
図６を参照すると、本発明に従って埋め込み電話番号を有するＳＩＰ  ＵＲＩから同等のｔｅｌ  ＵＲＩを取得するためにＵＴＭ３０８が行う方法６００の基本ステップを図解するフローチャートがある。基本的に、ＵＴＭ３０８は、ＳＩＰ  ＵＲＩ／埋め込み電話番号を取り込んで同等のｔｅｌ  ＵＲＩを生成するため、プロセッサ３２２と、プロセッサ３２２によってアクセス可能で処理可能な命令をその中に記憶するメモリ３２４とを含む。
【００４０】
ステップ６０２で始まって、ＵＴＭ３０８は、ＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩを含むｒｅｑｕｅｓｔ  ＵＲＩを受信する（図４乃至図５のステップ３を参照）。ステップ６０４において、ＵＴＭ３０８は、ＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩが認識可能な国際番号を有するかどうか判断する。有しない場合、ＵＴＭ３０８は、ステップ６０６で、エラーメッセージ（例えば４０４（見つからなかった）応答）を出力する。例えば、ＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩが、例えば「ｔｅｌ：２９９７：ｐｈｏｎｅ−ｃｏｎｔｅｘｔ＝９１３３９」のような認識不可能なローカル・ネットワーク・プレフィックスもしくは認識不可能なプライベート・プレフィックスの付いた「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含む場合に、ＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩは認識可能な国際番号を表していない、とＵＴＭ３０８は判断するであろう。加えて、例えば「ｔｅｌｐｈｏｎｅ：ｐｈｏｎｅ−ｃｏｎｔｅｘｔ＝ｕｎｋｎｏｗｎ．ｄｏｍａｉｎ．ｎｅｔ」のような、ＵＴＭ３０８が認識しないドメイン名の付いた「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数をＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩが含む場合に、ＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩは認識可能な国際番号を表していない、とＵＴＭ３０８は判断してもよい。一般に、ＵＴＭ３０８は、特定の単数もしくは複数のドメインを自分が認識できるようにするかまたは認識できないようにする、何らかの種類のオペレータ依存のポリシーを実装するであろう。例えば、ＵＴＭ３０８は、オペレータが割当てたドメイン名だけを認識できてもよい。
【００４１】
ステップ６０４での答えが「イエス」である場合、ＵＴＭ３０８は、ステップ６０８において、ＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩが「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含むかどうか判断する。含まない場合、ＵＴＭ３０８は、ステップ６１０において、目標ユーザ部分をＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩから抽出し、次いで「ｔｅｌ：」という文字列を目標ユーザ部分の前に付けることによって、同等のｔｅｌ  ＵＲＩを生成する。例えば、ＵＴＭ３０８は、ＳＩＰ  ＵＲＩ（例えばｓｉｐ：＋１−２３４−５６７−８９＠ｃｉｎｇｕｌａｒ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）の目標ユーザ部分（例えば＋１−２３４−５６７−８９）を抽出し、次いで、「ｔｅｌ：」という文字列を抽出された目標ユーザ部分（例えば＋１−２３４−５６７−８９）の前に付けることによって同等のｔｅｌ  ＵＲＩ（例えばｔｅｌ：＋１−２３４−５６７−８９）を生成することができる。ステップ６１２において、ＵＴＭ３０８は、同等のｔｅｌ  ＵＲＩをメモリ３２４の中に記憶し、次いで、同等のｔｅｌ  ＵＲＩを出力する（図４乃至図５のステップ５を参照）。
【００４２】
ステップ６０８への答えが「イエス」である場合、ＵＴＭ３０８は、ステップ６１４において、「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の後に位置する第１の数字の組を抽出し、「ｓｉｐ：」の後だが「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の前に位置する第２の数字の組を抽出し、次いで、「ｔｅｌ：」という文字列を第１の数字の組の前に付けて、その後に、同等のｔｅｌ  ＵＲＩを生成する目的で第２の数字の組を挿入することによって、同等のｔｅｌ  ＵＲＩを生成する。例えば、受信したＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩ（例えばｔｅｌ：２９９７；ｐｈｏｎｅ−ｃｏｎｔｅｘｔ＝＋３４９１３３９）が、国際ネットワーク・プレフィックスもしくはＵＴＭ３０８が認識するドメイン名を含む場合、国際ネットワーク・プレフィックスに関連する第１の数字の組（例えば３４９１３３９）を、「ｔｅｌ：」というプレフィックスと最初の「ｔｅｌ：」という文字列に続く第２の数字の組（例えば２９９７）との間に挿入することによって、同等のｔｅｌ  ＵＲＩ（例えばｔｅｌ：＋３４９１３３９２９９７）が構築される。加えて、ＵＴＭ３０８は、「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数と（存在するならば）「ｓｅｒｖｉｃｅ−ｐｒｏｖｉｄｅｒ」引数とを含む数字以外のあらゆる文字を削除するであろう。ステップ６１２において、ＵＴＭ３０８は、メモリ３２４の中に同等のｔｅｌ  ＵＲＩを記憶し、次いで、同等のｔｅｌ  ＵＲＩを出力する（図４乃至図５のステップ５を参照）。
【００４３】
別の実施形態において、ステップ６０８への答えが「イエス」である場合、ＵＴＭ３０８は、ステップ６１４’において、「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の後に位置する第１の数字の組、すなわちｐｈｏｎｅ−ｃｏｎｔｅｘｔ記述子を抽出し、「ｓｉｐ：」の後で且つ「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数の前に位置する第２の数字の組を抽出し、一連の置換規則を見つけるための事前定義された置換規則テーブルへの手がかり（キー）として第１の数字の組（ｐｈｏｎｅ−ｃｏｎｔｅｘｔ記述子／国際ネットワーク・プレフィックス）を使用し、これらの置換規則を第２の数字の組に適用して第３の数字の組を生成し、そして最後に、同等のｔｅｌ  ＵＲＩを生成するため、「ｔｅｌ：」という文字列を第３の数字の組の前に付けることによって、同等のｔｅｌ  ＵＲＩを生成する。例えば、受信したＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩ（例えばｔｅｌ：２９９７；ｐｈｏｎｅ−ｃｏｎｔｅｘｔ＝＋３４９１３３９）が、ＵＴＭ３０８の認識する国際ネットワーク・プレフィックスを伴う「ｐｈｏｎｅ−ｃｏｎｔｅｘｔ」引数を含む場合、国際ネットワーク・プレフィックス（例えば３４９１３３９）に関連する第１の数字の組を、国際ネットワーク・プレフィックスについて有効な一連の置換規則を見つけるための事前定義された置換規則のテーブルへの手がかりとして使用し、これらの置換規則を第２の数字の組（例えば２９９７）に適用して第３の数字の組（例えば＋３４９１３３９２９９７）を生成し、そして最後に同等のｔｅｌ  ＵＲＩ（例えばｔｅｌ：＋３４９１３３９２９９７）を得るため「ｔｅｌ：」という文字列を第３の数字の組の前に付けることによって、同等のｔｅｌ  ＵＲＩ（例えばｔｅｌ：＋３４９１３３９２９９７）が構築される。ステップ６１２において、ＵＴＭ３０８は、同等のｔｅｌ  ＵＲＩをメモリ３２４に記憶し、次いで、同等のｔｅｌ  ＵＲＩを出力する（図４乃至図５のステップ５を参照）。
【００４４】
図７を参照すると、本発明に従い、発信ネットワーク７０２内に位置するＵＡ１から着信／宛先ネットワーク７０４内に位置するＵＡ２まで呼をルーティングするオペレータ間プロセスを説明する一助とするのに用いられる信号フロー図がある（図１と比較されたい）。ステップは以下のとおりである。
【００４５】
１−３．  発信Ｓ−ＣＳＣＦ７０６が、ＵＡ１からＳＩＰ要求（例えばＩＮＶＩＴＥ  ｔｅｌ：＋１２３）を受信する（ステップ１）。Ｓ−ＣＳＣＦ７０６は、受信したセッション開始ＩＮＶＩＴＥ要求からＲｅｑｕｅｓｔ−ＵＲＩを取り込み、Ｒｅｑｕｅｓｔ−ＵＲＩがｔｅｌ  ＵＲＩを含む場合、Ｓ−ＣＳＣＦ７０６は、ＥＮＵＭ７０８サービスに問い合わせを行う（ステップ２）。ＥＮＵＭ７０８は、ｔｅｌ  ＵＲＩをＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩ（例えば、ｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）に変更し、それをＳ−ＣＳＣＦ７０６へ送信する（ステップ３）。またＳ−ＣＳＣＦ７０６は、ＳＩＰ要求の中の最初のＲｅｑｕｅｓｔ−ＵＲＩを、クエリから取得したＳＩＰ  ＵＲＩ／埋め込みｔｅｌ  ＵＲＩと置き換えて、新規のＳＩＰ要求（例えば、ＩＮＶＩＴＥ  ｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）を形成する。
【００４６】
４．  発信Ｓ−ＣＳＣＦ７０６は、新規のＲｅｑｕｅｓｔ−ＵＲＩのドメイン部分（例えばｏｐ．ｃｏｍ）を取り込み、新規のＩＮＶＩＴＥ  ＳＩＰ要求を、そのドメインで識別されるアドレスまで転送する（ドメインが、ＩＰｖ４アドレスもしくはＩＰｖ６アドレスである場合、ＩＮＶＩＴＥをそのアドレスに直接転送可能であるし、それ以外の場合は、着信ネットワーク７０４の中のＩＢＣＦかまたはＩ−ＣＳＣＦ３０２ａのいずれか一方に対応する宛先ＩＰアドレスを取得するため、ドメイン部を用いてＤＮＳに問い合わせを行う必要がある）。この例では、Ｓ−ＣＳＣＦ７０６は、新規のＳＩＰ要求（例えばＩＮＶＩＴＥｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）を直接Ｉ−ＣＳＣＦ３０２ａまで転送する（ステップ４）。
【００４７】
５−８．  Ｉ−ＣＳＣＦ３０２ａは、ＳＩＰ要求を受信して、それが、Ｒｅｑｕｅｓｔ  ＵＲＩの中にＳＩＰ  ＵＲＩ形式のｔｅｌ  ＵＲＩを含むかどうかを見るために、検査する。これを行うため、Ｉ−ＣＳＣＦ３０２ａは、要求ＵＲＩの中のＵＲＩ引数「ｕｓｅｒ＝ｐｈｏｎｅ」を探し、それを発見すると、Ｉ−ＣＳＣＦ３０２ａは、クエリの中で完全なＲｅｑｕｅｓｔ  ＵＲＩ（例えばＱｕｅｒｙ  ｓｉｐ：＋１２３＠ｏｐ．ｃｏｍ；ｕｓｅｒ＝ｐｈｏｎｅ）をＵＴＭ３０８へ送信する（ステップ６）。ＵＴＭ３０８は、クエリを受信し、方法６００を実施することによって、ＳＩＰ  ＵＲＩ／埋め込み電話番号を用いて同等のｔｅｌ  ＵＲＩ（例えばｔｅｌ：＋１２３）を生成する（ステップ７）。次いで、ＵＴＭ３０８は、クエリ応答（例えばＲｓｐ  ｔｅｌ：＋１２３）をＩ−ＣＳＣＦ３０２ａへ返信する（ステップ８）。
【００４８】
９−１０．  複数のＨＳＳが着信ネットワーク内に存在する場合、Ｉ−ＣＳＣＦ３０２ａは、パブリックＩＤとしてＵＴＭ３０８から受信したｔｅｌ  ＵＲＩを用いて、クエリ（例えばＤｘ−Ｌｏｃａｔｉｏｎ−Ｑｕｅｒｙ  ＰＵＩ＝ｔｅｌ：＋１２３）をＳＬＦ３０４まで送信する（ステップ９を参照）。次いで、ＳＬＦ３０４は、ＨＳＳ３０６を示す応答（例えばＤｘ−Ｌｏｃａｔｉｏｎ−Ｑｕｅｒｙ＿Ｒｓｐ  Ｓｅｒｖｅｒ−Ｎａｍｅ＝ＨＳＳ  ３０６）をＩ−ＣＳＣＦ３０２ａへ返信する（ステップ１０）。ＨＳＳが１つしか存在しない場合、ＳＬＦ３０４およびステップ９乃至１０は省略されてもよい。
【００４９】
１１−１２．  Ｉ−ＣＳＣＦ３０２ａは、パブリックＩＤとしてＵＴＭ３０８から受信したｔｅｌ  ＵＲＩを用いて、クエリ（例えば、Ｃｘ−Ｌｏｃａｔｉｏｎ−Ｑｕｅｒｙ  ＰＵＩ＝ｔｅｌ：＋１２３）をＨＳＳ３０６まで送信する（ステップ１１）。次いでＨＳＳ３０６は、Ｓ−ＣＳＣＦ３０２ｂを示す応答（例えば、Ｃｘ−Ｌｏｃａｔｉｏｎ−Ｑｕｅｒｙ＿Ｒｓｐ  Ｓｅｒｖｅｒ−Ｎａｍｅ＝Ｓ−ＣＳＣＦ３０２ｂ）をＩ−ＣＳＣＦ３０２ａに返信する（ステップ１２）。
注意：Ｉ−ＣＳＣＦ３０２ａは、呼の宛先であるユーザＵＡ２にサービス提供するＳ−ＣＳＣＦ３０２ｂを特定するために、ステップ９乃至１２を行う。
【００５０】
１３−１４．  一旦Ｉ−ＣＳＣＦ３０２ａがＳ−ＣＳＣＦ３０２ｂを特定すると、Ｉ−ＣＳＣＦ３０２ａは、呼（例えばＩＮＶＩＴＥ  ｓｉｐ：＋１２３）をＳ−ＣＳＣＦ３０２ｂまでルーティングする（ステップ１３）。次いで、着信Ｓ−ＣＳＣＦ３０２ｂは、その内部位置テーブルを使って、目標ユーザＵＡ２によって登録された連絡先アドレス（上記の例において、この連絡先アドレスは、Ｂ−ＵＥ＠ｏｐ．ｃｏｍである）までＩＮＶＩＴＥ要求をルーティングする（ステップ１４）。登録された連絡先アドレスはないけれども、目標ユーザＵＡ２が、未登録状態である何らかのサービスを起動していた場合、Ｓ−ＣＳＣＦ３０２ｂは、ＳＩＰ要求を、Ｓ−ＣＳＣＦ３０２ｂ内に記憶されたサービス情報によって示されたＡＳまで転送する。
【００５１】
前記から、当業者には理解されるべきだが、本発明は、呼の目標ユーザの識別子として電話番号を（そして、埋め込まれた電話番号を持つＳＩＰ  ＵＲＩではなく）用いて呼のルーティングを可能にする目的で、ＩＭＳ着信ネットワーク３００および７０４内でのｔｅｌ  ＵＲＩの特定の取扱を提案する。具体的には、本発明は変換モジュール３０８を導入し、その変換モジュール３０８は、ＩＭＳ着信ネットワーク３００および７０４内に位置していて、埋め込まれた電話番号を持つＳＩＰ  ＵＲＩを同等のｔｅｌ  ＵＲＩに変換することができ、それが次いで、呼を目標ユーザまでルーティングできるようにＩＭＳ着信Ｉ−ＣＳＣＦおよびＳ−ＣＳＣＦによってＳＬＦおよび／またはＨＳＳに問い合わせを行うために使用される。基本的に、本発明は、ＩＭＳ着信ネットワーク内での呼のルーティングプロセスを、（例えば）下記のように進化させる。
【００５２】
●ＵＴＭ３０８は、ＨＳＳおよびＳＬＦにおいて２種類のパブリック・ユーザ・アイデンティティを管理することに関して暗示される問題なしに、オペレータ間ルーティングプロセスにおけるキャリア−ＥＮＵＭサービスと共に電話番号の利用を可能にする。
【００５３】
●ＵＴＭ３０８は、例えばＭＭＳのような電話番号に基づいたサービスまたは旧来サービスをサポートするのに必要となりうる、最初にダイアルされた電話番号およびその特性を、実装には依存しないでＩＭＳ着信ネットワークへ転送することを可能にする。
【００５４】
●ＵＴＭ３０８は、ユーザ毎に複数の完全なＵＲＩをＳＬＦおよびＨＳＳに提供する必要がないようなかたちで、ネットワークオペレータがキャリア−ＥＮＵＭサービスを展開することを可能にする。これによって、過去にはｔｅｌ  ＵＲＩと同じＵＲＩのＳＩＰバージョンとの両方が提供される必要があったのに対し、ユーザのｔｅｌ  ＵＲＩだけが提供されればよいのだから、サービスの運営及び管理に関係する経済性が高まる。
【００５５】
●ＵＴＭ３０８は、目標ユーザに関する重複したパブリックＩＤでＨＳＳデータベースもしくはＳＬＦデータベースを更新する必要なしに、多様な方法で発信ユーザのＥ．１６４番号を符号化する各種のＭＧＣＦとのインタフェーシングを可能にする。
【００５６】
本発明のいくつかの実施形態が、添付の図面の中で図解され、先述の詳細説明の中で記述されてきたけれども、理解されるべきだが、本発明は、開示された実施形態に限定されるのではなく、それどころか、先述されそして添付の請求項によって定義された本発明の精神から逸脱することなく、幾多の再構成、修正、及び置換が可能である。
【図面の簡単な説明】
【００５７】
【図１】ＩＭＳ発信ネットワーク内に位置するＵＡからＩＭＳ着信ネットワーク内に位置するＵＡまで呼をルーティングする従来のプロセスに関連する諸問題を説明する一助とするのに用いられる信号フロー図（先行技術）である。
【図２】ＰＳＴＮ内に位置するＵＥからＩＭＳ着信ネットワーク内に位置するＵＡまで呼をルーティングする従来のプロセスに関連する諸問題を説明する一助とするのに用いられる信号フロー図（先行技術）である。
【図３】本発明に従って先行技術に関連する諸問題に取り組むように機能するＵＴＭで機能強化されたＩＭＳ着信ネットワークのブロック図である。
【図４】本発明の第１の実施形態に従い、（ＩＭＳ着信ネットワーク内に位置する）Ｉ−ＣＳＣＦによって受信された呼が、（ＩＭＳ着信ネットワーク内に位置する）Ｓ−ＣＳＣＦにどのようにしてルーティングされうるかを説明する一助とするのに用いられる典型的な信号フロー図である。
【図５】本発明の第２の実施形態に従い、（ＩＭＳ中継ネットワーク内に位置する）Ｓ−ＣＳＣＦによって受信された呼が、（ＩＭＳ着信ネットワーク内に位置する）次のホップにどのようにしてルーティングされうるかを説明する一助とするのに用いられる典型的な信号フロー図である。
【図６】本発明に従って、埋め込み電話番号を有するＳＩＰ  ＵＲＩから同等のｔｅｌ  ＵＲＩを取得するためにＵＴＭが行う基本ステップを図解するフローチャートである。
【図７】本発明の一実施形態に従い、ＩＭＳ発信ネットワーク内に位置するＵＡ１から発信された呼が、ＩＭＳ着信ネットワーク内に位置するＵＡ２までルーティングされるプロセスを説明する一助とするのに用いられる信号フロー図である。
【図１】
2009513052.tif 000003
【図２】
2009513052.tif 000004
【図３】
2009513052.tif 000005
【図４】
2009513052.tif 000006
【図５】
2009513052.tif 000007
【図６】
2009513052.tif 000008
【図７】
2009513052.tif 000009
【国際調査報告】
2009513052.tif 000010
2009513052.tif 000011
2009513052.tif 000012