説明

TEL−URIを用いた、IMS呼のルーティング

【課題】呼の目標ユーザの識別子として電話番号(そして、埋め込み電話番号の付いたSIP URIではなく)を用いて呼のルーティングを可能にする。
【解決手段】変換モジュールを導入し、その変換モジュールは、IMS着信ネットワーク内に位置していて、埋め込み電話番号付きSIP URIを、同等のtel URIに変換することができ、それが次いで、呼を目標ユーザまでルーティングできるように着信I−CSCFおよびS−CSCFによってSLFおよび/またはHSSに問い合わせを行うために使用される。

【発明の詳細な説明】
【技術分野】
【0001】
<以前に出願された米国出願の利益を主張する>
本願は、2005年10月21日に出願され、「Tel−URIを用いた、IMS呼のルーティング」と題された米国仮出願第60/729,012号の利益を主張する。この文書の内容は、ここに参照により本願に援用する。
【0002】
<技術分野>
本発明は一般に、特定の目標ユーザの識別子として(埋め込まれた形で電話番号を持つSIP URIではなく)電話番号であるtel URIを用いて目標ユーザまでの呼のルーティングを可能にする、IMS着信ネットワーク(terminating network)に関する。
【背景技術】
【0003】
ここでは下記の略語を定義する。少なくともその一部は、以下の先行技術および本発明の記述の中で言及される。
【0004】
3GPP 第3世代パートナシップ・プロジェクト
AS アプリケーション・サーバ
CSCF 呼セッション制御機能
DNS ドメイン・ネーム・システム
HSS ホーム加入者サーバ
IAM 初期アドレスメッセージ
IBCF インタワーキング・ボーダ制御機能
I−CSCF インテロゲーティングCSCF
IMS IPマルチメディア・サブシステム
IP インターネット・プロトコル
MGCF メディア・ゲートウェイ制御機能
MMS マルチメディア・メッセージング・サービス
POTS 普通の旧来の電話サービス(Plain Old Telephone Service)
PSTN 公衆交換電話網
PUI パブリック・ユーザ・アイデンティティ
RFC リクエスト・フォー・コメント
RTP リアルタイム・トランスポート・プロトコル
S−CSCF サービングCSCF
SIP セッション開始プロトコル
SLF 加入者ロケータ機能
TCP 伝送制御プロトコル
UA ユーザ・エージェント
UE ユーザ装置
URI ユニフォーム・リソース識別子
UTM URI翻訳モジュール
【0005】
IMSネットワークは、IMSネットワークのユーザ・エージェント(UA)および他の従来型ネットワークのユーザ装置(UE)が、他のUAとのマルチメディア・セッションを確立することを可能にし、それらが、あらゆる種類のリアルタイム情報(例えば音声、動画)または非リアルタイム情報(例えばメッセージ、写真)をも交換できるようにする、IPベースのネットワークである。現状ではIMSネットワークは、マルチメディア・セッションを確立するのにSIPプロトコルを使用し、マルチメディア・セッションのペイロードを搬送するのにRTPのような伝送プロトコルを使用する。
【0006】
IMSネットワークでは、目標ユーザを識別するURIを用いて、且つ、IMSネットワーク内のすべての要素が従わなければならない厳密に定義された一連のルーティング規則を用いて、そのユーザとの間で確立されたマルチメディア・セッション上で情報がルーティングされる。この一連の規則は、「セッション開始プロトコル(SIP)およびセッション記述プロトコル(SDP)に基づくIPマルチメディア呼制御プロトコル」と題された3GPP TS 24.229 V.5.14.0(2005年10月)(その内容は参照により本願に援用する)の中で3GPP準拠のIMSネットワークのために定義されている。
【0007】
マルチメディア・セッションを確立する場合に特定の目標ユーザを識別するのに用いられうるURIには2つのタイプがあり、すなわち、(1)SIP URIと(2)tel URIである。SIP URIは、2002年6月の「SIP:セッション開始プロトコル」と題されたRFC3261(その内容は参照により本願に援用する)の中で定義される形式を持つ。SIP URIの例をあげると次のようになる。
【0008】
sip:peter@yahoo.com
sip:James.Rowling@RowlingAndAssociates.co.uk
sip:voice_mail@vodafone.com;reason=no_answer
【0009】
他方、tel URIの形式は、「電話番号のためのtel URI」と題されたRFC3966(その内容は参照により本願に援用する)の中で定義される。tel URIの例をあげると次のようになる。
【0010】
tel:+1-234-567-89
tel:2997;phone-context=+3491339
【0011】
加えて、RFC3261の中で論じられていることであるが、埋め込まれたtel URIを持つSIP URIを表す方法もある。例えば、典型的なtel URIを、次のようにSIP URIの中に埋め込むこともできよう。
【0012】
sip:+1-234-567-89@cingular.com;user=phone
sip:2997;phone-context=+3491339@vodafone.com;user=phone
【0013】
上記の一連のルーティング規則の1つのセクションは、2つの異なるネットワークオペレータ間で呼をルーティングすることに充てられている。具体的には、2つのネットワークオペレータ間で呼をルーティングする場合、呼の目標ユーザを識別するためには、SIP URIもしくはSIP URI/埋め込みtel URIが使用されなければならない。図1(先行技術)は、第1のルーティングプロセス、すなわち、発信ネットワーク102に位置するUAから着信/宛先ネットワーク104に位置するUAまで呼をルーティングするためにSIP URI/埋め込みtel URIを使用するオペレータ間プロセス、を記述する一助とするのに用いられる信号フロー図である。ステップは、以下のようである(詳細については、3GPP TS 24.229を参照する)。
【0014】
1−3. 発信S−CSCFが、UAからSIP要求(例えばINVITE tel:+123)を受信する(ステップ1)。S−CSCFは、受信したセッション開始INVITE要求からRequest−URI(要求URI)を取り込み、Request−URIがtel URIを含む場合、S−CSCFは、ENUMサービスに問い合わせを行う(ステップ2)。ENUMは、tel URIをSIP URI/埋め込みtel URI(例えば、sip:+123@op.com;user=phone)に変更し、それをS−CSCFへ送信する(ステップ3)。S−CSCFは、SIP要求の中の最初のRequest−URIを、クエリから取得したSIP URI/埋め込みtel URIと置き換えて、新規のSIP要求(例えば、INVITE sip:+123@op.com;user=phone)を形成する。
【0015】
4. 発信S−CSCFは、新規のRequest−URIのドメイン部分(例えばop.com)を取り込み、新規のINVITE SIP要求を、そのドメインで識別されるアドレスまで転送する(ドメインが、IPv4アドレスもしくはIPv6アドレスである場合、INVITEをそのアドレスに直接転送可能であるし、それ以外の場合は、着信ネットワーク104の中のIBCFかまたはI−CSCFのいずれか一方に対応する宛先IPアドレスを取得するため、ドメイン部を用いてDNSに問い合わせを行う必要がある)。この例では、S−CSCFは、新規のSIP要求(例えばINVITE sip:+123@op.com;user=phone)を直接I−CSCFまで転送する(ステップ4)。
【0016】
5−6. I−CSCFは、着信呼について接触される最初のCSCFであり、呼の目標であるUAにサービス提供するS−CSCFを特定する役割を持つ。UAにサービス提供するS−CSCFを特定するため、I−CSCFは、(1)SLFおよび(2)HSSという、2つのネットワーク・データベースの使用が必要になることがある。SLFは、(どのS−CSCFが現時点でサービス提供しているかも含めて)UAの加入者データを保持する特定のHSSインスタンスを見つける、データベース特定機能であり、着信ネットワーク104内に複数のHSSインスタンスがある場合に使用される。この例では、I−CSCFは、SIP要求の中のRequest−URIを、クエリ(例えば、Dx−Location−Query PUI=sip:+123@op.com;user=phone)をSLFまで送信するためのパブリック・ユーザ・アイデンティティとして使用する(ステップ5)。次いで、SLFは、HSSを示す応答(例えば、Dx−Location−Query_Rsp Server−Name=HSS)をI−CSCFへ返信する。ネットワーク内に一意のHSSが存在する場合、SLFおよびステップ5乃至6は省略されてもよい。
【0017】
7−8. I−CSCFは、SIP要求の中のRequest−URIを、クエリ(例えば、Cx−Location−Query PUI=sip:+123@op.com;user=phone)をHSSまで送信するためのパブリック・ユーザ・アイデンティティとして使用する(ステップ7)。次いでHSSは、S−CSCFを示す応答(例えば、Cx−Location−Query_Rsp Server−Name=S−CSCF)をI−CSCFに返信する(ステップ8)。
【0018】
9−10. 一旦I−CSCFがS−CSCFを特定すると、I−CSCFは、呼(例えばINVITE sip:+123@op.com;user=phone)をそのS−CSCFまでルーティングする(ステップ9)。次いで、着信S−CSCFは、その内部位置テーブルを使って、目標ユーザUAによって登録された連絡先アドレス(上記の例において、この連絡先アドレスは、B−UE@op.comである)までINVITE要求をルーティングする(ステップ10)。登録された連絡先アドレスはないけれども、目標ユーザUAが、未登録状態である何らかのサービスを起動していた場合、S−CSCFは、SIP要求を、S−CSCF内に記憶されたサービス情報によって示されたASまで転送する。
【0019】
図2(先行技術)を参照すると、第2のルーティングプロセス、すなわち、上記のようなリモートネットワーク102においてピアS−CSCFから呼が来るのではなく代わりにMGCFから来る場合に発生するルーティングプロセスを記述する一助とするのに用いられる信号フロー図がある。この特定の第2のルーティングプロセスは、ユーザUEがPSTN202の中に位置していて、IMS着信ネットワーク104の中に位置するUAに対してtel URIを用いて呼を開始する場合に発生する。この特定のルーティングプロセスのステップは、以下のとおりである(詳細については、3GPP TS 24.229を参照する)。
【0020】
1a. MGCFは、UEから送信されたIAMを受信するPSTNシグナリング・インタフェースを有する(ステップ1a)。MGCFは、IAMを用いて目標ユーザのE.164番号を取得し、(E.164番号を含む)tel URIかまたは(E.164番号を埋め込んだ)SIP URIのいずれか一方を有するRequest−URIフィールドを含むINVITE SIP要求を生成する。
【0021】
2a. この特定の例において、INVITE SIP要求は、tel URI(例えばtel:+123)を含む(このステップ2aを図1のステップ4と比較されたい)。MGCFは、INVITE SIP要求(例えばINVITE tel:+123)を、着信ネットワーク104に位置するI−CSCFまで転送する(ステップ2a)。
【0022】
3a−8a. ステップ3a乃至8aは、SIP URI(例えばsip:+123@op.com;user=phone)ではなくtel URI(例えばtel:+123)が信号の一部において使用されることを除いて、図1に示す前のルーティング手順におけるステップ5乃至10と同様である。
【発明の開示】
【発明が解決しようとする課題】
【0023】
残念ながら、上記のルーティング手順には、若干の問題がある。
【0024】
1.第1のルーティングプロセスにおいて、呼を開始するのに用いられる目標電話番号が、INVITE SIP要求が着信ネットワーク104に到達する前に失われる。特に、発信S−CSCFが、最初にダイアルされたtel URIをENUMから取得されたSIP URI/埋め込みtel URIと置き換える際に、目標電話番号が、発信S−CSCFによってSIP要求の中の要求−URIから除去される(ステップ2乃至3を参照)。着信ネットワーク104が、この電話番号をある種のサービス(例えばMMS)に提供することが必要になることがあるため、これはあまり望ましくない。
【0025】
2.いずれのルーティングプロセスにおいても、着信ネットワーク104内で呼を内部的にルーティングするために、HSS内のユーザプロフィールと、SLF内のユーザ−サーバ間の関連付けとには、tel URIとそのtel URIのSIP形式(SIP URI/埋め込みtel URI)とが両方共含まれていなければならない。ルーティング手順では、着信ネットワーク104で受信されたSIP要求が、SIP URI/埋め込みtel URI(図1を参照)かまたはtel URI(図2を参照)のいずれか一方を含むことがある事例があることから、このことは必要である。所与の発信ネットワーク102によってどの形式が実際に使用されるのか事前に分らないことから、着信ネットワーク104内で内部的に呼をルーティングできるためには、SLF内のユーザ−サーバ間の関連付けとHSS内のユーザプロフィールとは、tel URIとそのtel URIのSIP形式(SIP URI/埋め込みtel URI)とを両方共含む必要がある。従って、SLFとHSSとは、それぞれ、tel URIとSIP URI/埋め込みtel URIとの両方について重複した情報を維持する必要があり、それは管理上の負荷を増加させるだけでなく、メモリスペースを無駄遣いする。これは望ましくない。
【0026】
従って、先行技術に関連するこれらの短所およびその他の短所に取り組む必要性がこれまでもあったし、今もある。これらの必要性およびその他の必要性は、本発明によって満たされる。
【課題を解決するための手段】
【0027】
本発明は、呼の目標ユーザの識別子として電話番号(そして、埋め込まれた電話番号を持つSIP URIではなく)を用いて呼のルーティングを可能にする目的で、IMS着信ネットワーク内でのtel URIの特定の取扱を提案する。具体的には、本発明は変換モジュールを導入し、その変換モジュールは、IMS着信ネットワーク内に位置していて、埋め込まれた電話番号を持つSIP URIを、同等のtel URIに変換することができ、それが次いで、呼を目標ユーザまでルーティングできるように着信I−CSCFおよびS−CSCFによってSLFおよび/またはHSSに問い合わせを行うために使用される。
【0028】
あるシナリオにおいて、変換モジュールは、SIP URI/埋め込み電話番号付(電話番号が埋め込まれたSIP URI)を、同等のtel URIに変換することができるが、それは(1)目標ユーザ部分をSIP URI/埋め込み電話番号付から抽出すること、および(2)同等のtel URIを生成するために、「tel:」という文字列を目標ユーザ部分の前に付ける(付加する)こと、によって可能になる。別のシナリオにおいて、変換モジュールは、SIP URI/埋め込み電話番号付を、同等のtel URIに変換することができるが、それは(1)第1の数字の組、すなわち、SIP URI/埋め込み電話番号付の中の「phone−context」引数の後に位置するphone context記述子(phone context記述子は、ドメイン名でもよいし国際ネットワーク・プレフィックスでもよい)を抽出すること、(2)SIP URI/埋め込み電話番号付の中の「sip:」引数の後で且つ「phone−context」引数の前に位置する第2の数字の組を抽出すること、および(3)同等のtel URIを生成するために、「tel:」という文字列を第1の数字の組の前に付け、その後に第2の数字の組が挿入されること、によって可能になる。更に別のシナリオにおいて、変換モジュールはSIP URI/埋め込み電話番号付を、同等のtel URIに変換することができるが、それは(1)第1の数字の組、すなわち、「phone−context」引数の後に位置するphone context記述子を抽出すること、(2)「sip:」引数の後で且つ「phone−context」引数の前に位置する第2の数字の組を抽出すること、(3)第1の数字の組(phone context記述子/国際ネットワーク・プレフィックス)を、一連の置換規則を見つけるための事前定義された置換規則のテーブルへの手がかり(キー)として使用すること、(4)これらの置換規則を第2の数字の組に適用して第3の数字の組を生成すること、そして、(5)同等のtel URIを生成するために、「tel:」という文字列を第3の数字の組の前に付けること、によって可能になる。
【0029】
更に、本発明は、SIP要求を受信するための受信器と、SIP URI/埋め込み電話番号(電話番号が埋め込まれたSIP URI)を含む要求URIをSIP要求が有するかどうか判断するためのプロセッサとを有する、I−CSCFを含む。あるシナリオにおいて、要求URIの中に「user=phone」引数がある場合に、SIP要求がSIP URI/埋め込み電話番号を有する、とプロセッサは判断する。SIP要求がSIP URI/埋め込み電話番号を有する場合、I−CSCFは、要求URIを(SIP URI/埋め込み電話番号から対応するtel URIを生成する)変換モジュールまで転送し、次いで変換モジュールから対応するtel URIを受信する、クエリ装置を有する。その後、プロセッサは、SIP URI/埋め込み電話番号を削除して、受信したtel URIをSIP要求の要求URIに挿入し、改変されたSIP要求を形成する。最後に、I−CSCFは、対応するtel URIの付いた要求URIを含む改変されたSIP要求をS−CSCFへ提出(送信)する送信器を有する。
【0030】
加えて、本発明は、SIP要求を受信するための受信器と、SIP URI/埋め込み電話番号を含む要求URIをSIP要求が有するかどうか判断するためのプロセッサとを有する、S−CSCFを含む。あるシナリオにおいて、要求URIの中に「user=phone」引数がある場合に、SIP要求がSIP URI/埋め込み電話番号を有する、とプロセッサは判断する。SIP要求がSIP URI/埋め込み電話番号を有する場合、S−CSCFは、要求URIを(SIP URI/埋め込み電話番号から対応するtel URIを生成する)変換モジュールまで転送し、次いで変換モジュールから対応するtel URIを受信する、クエリ装置を有する。その後、プロセッサは、SIP URI/埋め込み電話番号を削除して、受信したtel URIをSIP要求の要求URIに挿入し、改変されたSIP要求を形成する。最後に、S−CSCFは、対応するtel URIの付いた要求URIを含む改変されたSIP要求を着信ネットワークへ送信する送信器を有する。
【0031】
本発明の利点は、I−CSCFとS−CSCFとが、同等のtel URIを用いて呼をルーティングすることができることから、SLFおよび/またはHSS(SLF及びHSSのうちの少なくとも一方)が、目標ユーザのtel URIを維持するだけでよく、目標ユーザのtel URIとSIP URI/埋め込み電話番号とを両方共維持しなくてもよいことである。本発明のもう1つの利点は、発信ネットワーク内のS−CSCFによってSIP要求から取り除かれていたかもしれない、発信時にダイアルされた目標ユーザの電話番号を変換モジュールが取得できることであり、着信ネットワークが、例えばMMSのような電話番号に基づくサービスまたは旧来のサービスをサポートするために発信電話番号を必要とすることがあることから、これは望ましいことである。
【0032】
本発明のより完全な理解は、添付の図面に関連して下記の詳細な説明を参照することで得られるであろう。
【発明を実施するための最良の形態】
【0033】
図3を参照すると、本発明を説明する一助とするのに用いられる、(I−CSCF302aとS−CSCF302bとを含む)CSCF302と、SLF304と、HSS306と、UTM308とを有する典型的なIMS着信ネットワーク300のブロック図がある。図示するように、I−CSCF302aは、もしあるならばSLF304と、そしてHSS306と、リンク310および312を介してそれぞれ通信し、他方、S−CSCF302bは、HSS306とリンク314を介してそれぞれ通信する。加えて、I−CSCF302aとS−CSCF302bとは、例えばTCP/IP上で動作するクエリ応答プロトコルを用いて、リンク316および318上でUTM308とそれぞれ通信する。あるいは、UTM308は、CSCF302と、具体的にはI−CSCF302aもしくはS−CSCF302bと統合されてもよく、その場合、それらの間の通信リンクは、CSCF302の外側からは見えない内部リンクであってもよいだろう。または、UTM308は、SLF304およびHSS306と統合されてもよいであろうし、その場合、CSCF−UTMインタフェースをCSCF−HSSインタフェース312、314(Cx)およびCSCF−SLFインタフェース310(Dx)と結合することも可能であろう。ここで理解されるべきだが、当業者にはよく知られていて、本発明を理解するのに必要ない、CSCF302、SLF304、HSS306に関するその他の詳細を、本明細書で提供する記述では論じない。
【0034】
図4を参照すると、(少なくとも受信器402、プロセッサ404、クエリ装置406、および送信器408を含む)I−CSCF302aによって呼が受信された場合に、本発明によって呼はどのようにしてS−CSCF302bまでルーティングされうるかを説明する一助とするのに用いられる、典型的な信号フロー図がある。基本的に、I−CSCF302a、特に受信器402は、SIP要求を受信すると、そのRequest URIがSIP URI形式のtel URIを含むかどうか(ステップ1乃至2を参照)を見るために、プロセッサ404にSIP要求を検査させる(しかし、tel URIは現時点では登録されていないため、REGISTER SIP要求は検査しない)。これを行うため、I−CSCF302a、特にプロセッサ404は、Request URIの中のURI引数「user=phone」を探し、それを発見すると、I−CSCF302a、特にクエリ装置406は、クエリの中で完全なRequest URIをUTM308へ送信する(ステップ3を参照)。UTM308は、(a)クエリを受信し、(b)SIP URI/埋め込み電話番号を取り込み、(c)同等のtel URIを生成し、そして(d)同等のtel URIを含むクエリ応答をI−CSCF302aへ返信する(ステップ4乃至5および図6を参照)ように機能する。
【0035】
その後、I−CSCF302a、特に送信器408は、もしあればSLF304を、そしてHSS306に問い合わせをする場合、UTM308から受信したtel URIをパブリックIDとして用いる(ステップ6乃至9を参照)。加えて、I−CSCF302a、特にプロセッサ404は、送信器408が、改変されたSIP要求をS−CSCF302bへ送信できるように、最初のSIP要求の中のSIP URI/埋め込みtel URIをUTM308から受信したtel URIと置き換える(ステップ10を参照)。I−CSCF302aが、最初のSIP要求の中のSIP URI/埋め込みtel URIをUTM308から受信したtel URIと置き換えるのだから、これは、IMS目標ネットワーク300の内側での改変されたSIP要求のルーティングは、それ以降、tel URIに基づいて行えるということを意味する。結果として、SLF304およびHSS306は、tel URIに関連するパブリックIDを記憶するだけでよく、tel URIとSIP形式のそのtel URIとの両方についてパブリックIDを記憶しなくてもよい。これは、SLFとHSSとがtel URIとSIP URI/埋め込みtel URIとの両方について情報を記憶する必要があった従来のルーティングプロセスに比べて著しい進歩である。
【0036】
図5を参照すると、中継ネットワークにおいて(少なくとも受信器502、プロセッサ504、クエリ装置506、送信器508を含む)S−CSCF302bによって呼が受信された場合、本発明によって呼はどのようにして次のホップ320までルーティングされうるかを説明する一助とするのに用いられる、典型的な信号フロー図がある。基本的に、S−CSCF302b、特に受信器502は、SIP要求を受信すると、そのRequest URIがtel URIのSIP URI形式を含むかどうかを見るために、プロセッサ504にSIP要求を検査させる(しかし、tel URIは現時点では登録されていないため、REGISTER SIP要求は検査しない)(ステップ1乃至2を参照)。これを行うため、S−CSCF302b、特にプロセッサ504は、Request URIの中のURI引数「user=phone」を探し、それを発見すると、S−CSCF302b、特にクエリ装置506は、クエリの中で完全なRequest URIをUTM308へ送信する(ステップ3を参照)。UTM308は、(a)クエリを受信し、(b)SIP URI/埋め込み電話番号を取り込み、(c)同等のtel URIを生成し、そして(d)同等のtel URIを含むクエリ応答をS−CSCF302bまで返信する(ステップ4乃至5および図6を参照)ように機能する。
【0037】
その後、S−CSCF302b、特に送信器508は、SLF304とHSS306とに問い合わせをする場合、UTM308から受信したtel URIをパブリックIDとして用いる(ステップ6乃至9を参照)。加えて、S−CSCF302b、特にプロセッサ504は、送信器508が、改変されたSIP要求を次のホップ320へ送信できるように、SIP要求の中のSIP URI/埋め込みtel URIをUTM308から受信したtel URIと置き換える(ステップ10を参照)。S−CSCF302bは、最初のSIP要求の中のSIP URI/埋め込みtel URIをUTM308から受信したtel URIと置き換えるのだから、これは、IMS目標ネットワーク300の内側での改変されたSIP要求のルーティングは、それ以降、tel URIに基づいて行えるということを意味する。結果として、SLF304およびHSS306は、tel URIに関連するパブリックIDを記憶するだけでよく、tel URIとSIP形式のそのtel URIとの両方についてパブリックIDを記憶しなくてもよい。これは、SLFとHSSとがtel URIとSIP URI/埋め込みtel URIとの両方について情報を記憶する必要があった従来のルーティングプロセスに比べて著しい進歩である。
【0038】
上記の2つの実施形態のいずれにおいても、UTM308から送信されたクエリ応答が、エラーコードまたはエラーメッセージを含むことが起きるかもしれない(下記の説明を参照)。その場合、I−CSCF302a/S−CSCF302bは、例えば「tel URI内のドメインが間違い」のような何らかの記述テキストを含む404(見つからなかった(not found))応答を発信者に返信することによって、要求に答えてもよいだろう。これは、SIP要求を開始した発信者に、tel URIの代わりにSIP URIを用いてSIP要求を再送信する機会を与えることになるが、但しそれを行うことが可能な場合に限る(例えば、POTS電話を用いる発信者は、SIP URIを用いて要求を再送信することはできないであろう)。
【0039】
図6を参照すると、本発明に従って埋め込み電話番号を有するSIP URIから同等のtel URIを取得するためにUTM308が行う方法600の基本ステップを図解するフローチャートがある。基本的に、UTM308は、SIP URI/埋め込み電話番号を取り込んで同等のtel URIを生成するため、プロセッサ322と、プロセッサ322によってアクセス可能で処理可能な命令をその中に記憶するメモリ324とを含む。
【0040】
ステップ602で始まって、UTM308は、SIP URI/埋め込みtel URIを含むrequest URIを受信する(図4乃至図5のステップ3を参照)。ステップ604において、UTM308は、SIP URI/埋め込みtel URIが認識可能な国際番号を有するかどうか判断する。有しない場合、UTM308は、ステップ606で、エラーメッセージ(例えば404(見つからなかった)応答)を出力する。例えば、SIP URI/埋め込みtel URIが、例えば「tel:2997:phone−context=91339」のような認識不可能なローカル・ネットワーク・プレフィックスもしくは認識不可能なプライベート・プレフィックスの付いた「phone−context」引数を含む場合に、SIP URI/埋め込みtel URIは認識可能な国際番号を表していない、とUTM308は判断するであろう。加えて、例えば「tel:2997;phone−context=unknown.domain.net」のような、UTM308が認識しないドメイン名の付いた「phone−context」引数をSIP URI/埋め込みtel URIが含む場合に、SIP URI/埋め込みtel URIは認識可能な国際番号を表していない、とUTM308は判断してもよい。一般に、UTM308は、特定の単数もしくは複数のドメインを自分が認識できるようにするかまたは認識できないようにする、何らかの種類のオペレータ依存のポリシーを実装するであろう。例えば、UTM308は、オペレータが割当てたドメイン名だけを認識できてもよい。
【0041】
ステップ604での答えが「イエス」である場合、UTM308は、ステップ608において、SIP URI/埋め込みtel URIが「phone−context」引数を含むかどうか判断する。含まない場合、UTM308は、ステップ610において、目標ユーザ部分をSIP URI/埋め込みtel URIから抽出し、次いで「tel:」という文字列を目標ユーザ部分の前に付けることによって、同等のtel URIを生成する。例えば、UTM308は、SIP URI(例えばsip:+1−234−567−89@cingular.com;user=phone)の目標ユーザ部分(例えば+1−234−567−89)を抽出し、次いで、「tel:」という文字列を抽出された目標ユーザ部分(例えば+1−234−567−89)の前に付けることによって同等のtel URI(例えばtel:+1−234−567−89)を生成することができる。ステップ612において、UTM308は、同等のtel URIをメモリ324の中に記憶し、次いで、同等のtel URIを出力する(図4乃至図5のステップ5を参照)。
【0042】
ステップ608への答えが「イエス」である場合、UTM308は、ステップ614において、「phone−context」引数の後に位置する第1の数字の組を抽出し、「sip:」の後だが「phone−context」引数の前に位置する第2の数字の組を抽出し、次いで、「tel:」という文字列を第1の数字の組の前に付けて、その後に、同等のtel URIを生成する目的で第2の数字の組を挿入することによって、同等のtel URIを生成する。例えば、受信したSIP URI/埋め込みtel URI(例えばtel:2997;phone−context=+3491339)が、国際ネットワーク・プレフィックスもしくはUTM308が認識するドメイン名を含む場合、国際ネットワーク・プレフィックスに関連する第1の数字の組(例えば3491339)を、「tel:」というプレフィックスと最初の「tel:」という文字列に続く第2の数字の組(例えば2997)との間に挿入することによって、同等のtel URI(例えばtel:+34913392997)が構築される。加えて、UTM308は、「phone−context」引数と(存在するならば)「service−provider」引数とを含む数字以外のあらゆる文字を削除するであろう。ステップ612において、UTM308は、メモリ324の中に同等のtel URIを記憶し、次いで、同等のtel URIを出力する(図4乃至図5のステップ5を参照)。
【0043】
別の実施形態において、ステップ608への答えが「イエス」である場合、UTM308は、ステップ614’において、「phone−context」引数の後に位置する第1の数字の組、すなわちphone−context記述子を抽出し、「sip:」の後で且つ「phone−context」引数の前に位置する第2の数字の組を抽出し、一連の置換規則を見つけるための事前定義された置換規則テーブルへの手がかり(キー)として第1の数字の組(phone−context記述子/国際ネットワーク・プレフィックス)を使用し、これらの置換規則を第2の数字の組に適用して第3の数字の組を生成し、そして最後に、同等のtel URIを生成するため、「tel:」という文字列を第3の数字の組の前に付けることによって、同等のtel URIを生成する。例えば、受信したSIP URI/埋め込みtel URI(例えばtel:2997;phone−context=+3491339)が、UTM308の認識する国際ネットワーク・プレフィックスを伴う「phone−context」引数を含む場合、国際ネットワーク・プレフィックス(例えば3491339)に関連する第1の数字の組を、国際ネットワーク・プレフィックスについて有効な一連の置換規則を見つけるための事前定義された置換規則のテーブルへの手がかりとして使用し、これらの置換規則を第2の数字の組(例えば2997)に適用して第3の数字の組(例えば+34913392997)を生成し、そして最後に同等のtel URI(例えばtel:+34913392997)を得るため「tel:」という文字列を第3の数字の組の前に付けることによって、同等のtel URI(例えばtel:+34913392997)が構築される。ステップ612において、UTM308は、同等のtel URIをメモリ324に記憶し、次いで、同等のtel URIを出力する(図4乃至図5のステップ5を参照)。
【0044】
図7を参照すると、本発明に従い、発信ネットワーク702内に位置するUAから着信/宛先ネットワーク704内に位置するUAまで呼をルーティングするオペレータ間プロセスを説明する一助とするのに用いられる信号フロー図がある(図1と比較されたい)。ステップは以下のとおりである。
【0045】
1−3. 発信S−CSCF706が、UAからSIP要求(例えばINVITE tel:+123)を受信する(ステップ1)。S−CSCF706は、受信したセッション開始INVITE要求からRequest−URIを取り込み、Request−URIがtel URIを含む場合、S−CSCF706は、ENUM708サービスに問い合わせを行う(ステップ2)。ENUM708は、tel URIをSIP URI/埋め込みtel URI(例えば、sip:+123@op.com;user=phone)に変更し、それをS−CSCF706へ送信する(ステップ3)。またS−CSCF706は、SIP要求の中の最初のRequest−URIを、クエリから取得したSIP URI/埋め込みtel URIと置き換えて、新規のSIP要求(例えば、INVITE sip:+123@op.com;user=phone)を形成する。
【0046】
4. 発信S−CSCF706は、新規のRequest−URIのドメイン部分(例えばop.com)を取り込み、新規のINVITE SIP要求を、そのドメインで識別されるアドレスまで転送する(ドメインが、IPv4アドレスもしくはIPv6アドレスである場合、INVITEをそのアドレスに直接転送可能であるし、それ以外の場合は、着信ネットワーク704の中のIBCFかまたはI−CSCF302aのいずれか一方に対応する宛先IPアドレスを取得するため、ドメイン部を用いてDNSに問い合わせを行う必要がある)。この例では、S−CSCF706は、新規のSIP要求(例えばINVITEsip:+123@op.com;user=phone)を直接I−CSCF302aまで転送する(ステップ4)。
【0047】
5−8. I−CSCF302aは、SIP要求を受信して、それが、Request URIの中にSIP URI形式のtel URIを含むかどうかを見るために、検査する。これを行うため、I−CSCF302aは、要求URIの中のURI引数「user=phone」を探し、それを発見すると、I−CSCF302aは、クエリの中で完全なRequest URI(例えばQuery sip:+123@op.com;user=phone)をUTM308へ送信する(ステップ6)。UTM308は、クエリを受信し、方法600を実施することによって、SIP URI/埋め込み電話番号を用いて同等のtel URI(例えばtel:+123)を生成する(ステップ7)。次いで、UTM308は、クエリ応答(例えばRsp tel:+123)をI−CSCF302aへ返信する(ステップ8)。
【0048】
9−10. 複数のHSSが着信ネットワーク内に存在する場合、I−CSCF302aは、パブリックIDとしてUTM308から受信したtel URIを用いて、クエリ(例えばDx−Location−Query PUI=tel:+123)をSLF304まで送信する(ステップ9を参照)。次いで、SLF304は、HSS306を示す応答(例えばDx−Location−Query_Rsp Server−Name=HSS 306)をI−CSCF302aへ返信する(ステップ10)。HSSが1つしか存在しない場合、SLF304およびステップ9乃至10は省略されてもよい。
【0049】
11−12. I−CSCF302aは、パブリックIDとしてUTM308から受信したtel URIを用いて、クエリ(例えば、Cx−Location−Query PUI=tel:+123)をHSS306まで送信する(ステップ11)。次いでHSS306は、S−CSCF302bを示す応答(例えば、Cx−Location−Query_Rsp Server−Name=S−CSCF302b)をI−CSCF302aに返信する(ステップ12)。
注意:I−CSCF302aは、呼の宛先であるユーザUAにサービス提供するS−CSCF302bを特定するために、ステップ9乃至12を行う。
【0050】
13−14. 一旦I−CSCF302aがS−CSCF302bを特定すると、I−CSCF302aは、呼(例えばINVITE sip:+123)をS−CSCF302bまでルーティングする(ステップ13)。次いで、着信S−CSCF302bは、その内部位置テーブルを使って、目標ユーザUAによって登録された連絡先アドレス(上記の例において、この連絡先アドレスは、B−UE@op.comである)までINVITE要求をルーティングする(ステップ14)。登録された連絡先アドレスはないけれども、目標ユーザUAが、未登録状態である何らかのサービスを起動していた場合、S−CSCF302bは、SIP要求を、S−CSCF302b内に記憶されたサービス情報によって示されたASまで転送する。
【0051】
前記から、当業者には理解されるべきだが、本発明は、呼の目標ユーザの識別子として電話番号を(そして、埋め込まれた電話番号を持つSIP URIではなく)用いて呼のルーティングを可能にする目的で、IMS着信ネットワーク300および704内でのtel URIの特定の取扱を提案する。具体的には、本発明は変換モジュール308を導入し、その変換モジュール308は、IMS着信ネットワーク300および704内に位置していて、埋め込まれた電話番号を持つSIP URIを同等のtel URIに変換することができ、それが次いで、呼を目標ユーザまでルーティングできるようにIMS着信I−CSCFおよびS−CSCFによってSLFおよび/またはHSSに問い合わせを行うために使用される。基本的に、本発明は、IMS着信ネットワーク内での呼のルーティングプロセスを、(例えば)下記のように進化させる。
【0052】
●UTM308は、HSSおよびSLFにおいて2種類のパブリック・ユーザ・アイデンティティを管理することに関して暗示される問題なしに、オペレータ間ルーティングプロセスにおけるキャリア−ENUMサービスと共に電話番号の利用を可能にする。
【0053】
●UTM308は、例えばMMSのような電話番号に基づいたサービスまたは旧来サービスをサポートするのに必要となりうる、最初にダイアルされた電話番号およびその特性を、実装には依存しないでIMS着信ネットワークへ転送することを可能にする。
【0054】
●UTM308は、ユーザ毎に複数の完全なURIをSLFおよびHSSに提供する必要がないようなかたちで、ネットワークオペレータがキャリア−ENUMサービスを展開することを可能にする。これによって、過去にはtel URIと同じURIのSIPバージョンとの両方が提供される必要があったのに対し、ユーザのtel URIだけが提供されればよいのだから、サービスの運営及び管理に関係する経済性が高まる。
【0055】
●UTM308は、目標ユーザに関する重複したパブリックIDでHSSデータベースもしくはSLFデータベースを更新する必要なしに、多様な方法で発信ユーザのE.164番号を符号化する各種のMGCFとのインタフェーシングを可能にする。
【0056】
本発明のいくつかの実施形態が、添付の図面の中で図解され、先述の詳細説明の中で記述されてきたけれども、理解されるべきだが、本発明は、開示された実施形態に限定されるのではなく、それどころか、先述されそして添付の請求項によって定義された本発明の精神から逸脱することなく、幾多の再構成、修正、及び置換が可能である。
【図面の簡単な説明】
【0057】
【図1】IMS発信ネットワーク内に位置するUAからIMS着信ネットワーク内に位置するUAまで呼をルーティングする従来のプロセスに関連する諸問題を説明する一助とするのに用いられる信号フロー図(先行技術)である。
【図2】PSTN内に位置するUEからIMS着信ネットワーク内に位置するUAまで呼をルーティングする従来のプロセスに関連する諸問題を説明する一助とするのに用いられる信号フロー図(先行技術)である。
【図3】本発明に従って先行技術に関連する諸問題に取り組むように機能するUTMで機能強化されたIMS着信ネットワークのブロック図である。
【図4】本発明の第1の実施形態に従い、(IMS着信ネットワーク内に位置する)I−CSCFによって受信された呼が、(IMS着信ネットワーク内に位置する)S−CSCFにどのようにしてルーティングされうるかを説明する一助とするのに用いられる典型的な信号フロー図である。
【図5】本発明の第2の実施形態に従い、(IMS中継ネットワーク内に位置する)S−CSCFによって受信された呼が、(IMS着信ネットワーク内に位置する)次のホップにどのようにしてルーティングされうるかを説明する一助とするのに用いられる典型的な信号フロー図である。
【図6】本発明に従って、埋め込み電話番号を有するSIP URIから同等のtel URIを取得するためにUTMが行う基本ステップを図解するフローチャートである。
【図7】本発明の一実施形態に従い、IMS発信ネットワーク内に位置するUAから発信された呼が、IMS着信ネットワーク内に位置するUAまでルーティングされるプロセスを説明する一助とするのに用いられる信号フロー図である。

【特許請求の範囲】
【請求項1】
変換モジュールであって、
プロセッサと、
前記プロセッサがアクセス可能且つ処理可能な命令を格納したメモリと、
を備え、
前記命令は、
要求URIを受信するステップと、
認識可能な国際番号を伴うSIP URIを前記要求URIが有するか否かを判定するステップと、
有さない場合に、エラーメッセージを出力するステップと、
有する場合に、前記SIP URIを用いて電話番号「tel URI」を生成するステップと、当該電話番号「tel URI」を出力するステップと、
を実行させる
ことを特徴とする変換モジュール。
【請求項2】
前記SIP URIが「phone−context」引数を含まない場合に、前記プロセッサは、
前記SIP URIから目標ユーザ部分を抽出するステップと、
前記電話番号「tel URI」を生成するために文字列「tel:」を前記目標ユーザ部分の前に付加するステップと、
を実行することによって前記生成するステップを実行することを特徴とする請求項1に記載の変換モジュール。
【請求項3】
前記SIP URIが「phone−context」引数を含む場合に、前記プロセッサは、
前記「phone−context」引数の後ろに位置する第1の数字の組を抽出するステップと、
前記SIP URI中の「sip:」の後ろで前記「phone−context」引数の前に位置する第2の数字の組を抽出するステップと、
前記電話番号「tel URI」を生成するために、前記第2の数字の組が後ろに挿入される前記第1の数字の組の前に文字列「tel:」を付加するステップと、
を実行することによって前記生成するステップを実行することを特徴とする請求項1に記載の変換モジュール。
【請求項4】
前記SIP URIが「phone−context」引数を含む場合に、前記プロセッサは、
前記「phone−context」引数の後ろに位置する第1の数字の組を抽出するステップと、
前記SIP URI中の「sip:」の後ろで前記「phone−context」引数の前に位置する第2の数字の組を抽出するステップと、
一連の置換規則を見つけるための事前定義された置換規則のテーブルへのキーとして前記第1の数字の組を使用するステップと、
第3の数字の組を生成するために前記一連の置換規則を前記第2の数字の組に適用するステップと、
前記電話番号「tel URI」を生成するために、前記第3の数字の組の前に文字列「tel:」を付加するステップと、
を実行することによって前記生成するステップを実行することを特徴とする請求項1に記載の変換モジュール。
【請求項5】
埋め込まれた電話番号を有するSIP URIからtel URIを取得する方法であって、
要求URIを受信するステップと、
認識可能な国際番号を伴うSIP URIを前記要求URIが有するか否かを判定するステップと、
有さない場合に、エラーメッセージを出力するステップと、
有する場合に、前記SIP URIを用いて電話番号「tel URI」を生成するステップと、当該電話番号「tel URI」を出力するステップと、
を備えることを特徴とする方法。
【請求項6】
前記SIP URIが「phone−context」引数を含まない場合に、前記生成するステップが、
前記SIP URIから目標ユーザ部分を抽出するステップと、
前記電話番号「tel URI」を生成するために文字列「tel:」を前記目標ユーザ部分の前に付加するステップと、
を含むことを特徴とする請求項5に記載の方法。
【請求項7】
前記SIP URIが「phone−context」引数を含む場合に、前記生成するステップが、
前記「phone−context」引数の後ろに位置する第1の数字の組を抽出するステップと、
前記SIP URI中の「sip:」の後ろで前記「phone−context」引数の前に位置する第2の数字の組を抽出するステップと、
前記電話番号「tel URI」を生成するために、前記第2の数字の組が後ろに挿入される前記第1の数字の組の前に文字列「tel:」を付加するステップと、
を更に含むことを特徴とする請求項5に記載の方法。
【請求項8】
前記SIP URIが「phone−context」引数を含む場合に、前記生成するステップが、
前記「phone−context」引数の後ろに位置する第1の数字の組を抽出するステップと、
前記SIP URI中の「sip:」の後ろで前記「phone−context」引数の前に位置する第2の数字の組を抽出するステップと、
一連の置換規則を見つけるための事前定義された置換規則のテーブルへのキーとして前記第1の数字の組を使用するステップと、
第3の数字の組を生成するために前記一連の置換規則を前記第2の数字の組に適用するステップと、
前記電話番号「tel URI」を生成するために、前記第3の数字の組の前に文字列「tel:」を付加するステップと、
を更に含むことを特徴とする請求項5に記載の方法。
【請求項9】
ネットワークであって、
ノードと、
変換モジュールと、
データベースと、
を備え、
前記ノードは、SIP要求を受信し、前記SIP要求がSIP URI/埋め込み電話番号を有するか否かを判定し、
有する場合、前記ノードは、前記SIP URI/埋め込み電話番号を前記変換モジュールに転送し、
有さない場合、前記ノードは、前記SIP要求を次にどこへルーティングするかを判断する目的で前記データベースに問い合わせるために、前記埋め込み電話番号を有さない前記SIP URIを使用し、
前記変換モジュールは、認識可能な国際番号を前記SIP URI/埋め込み電話番号が有するか否かを判定し、
有さない場合、前記変換モジュールは、エラーメッセージを前記ノードへ送信し、
有する場合、前記変換モジュールは、前記SIP URI/埋め込み電話番号を用いて電話番号tel URI」を生成し、当該電話番号「tel URI」を前記ノードへ送信し、前記ノードは、前記SIP要求を次にどこへルーティングするかを判断する目的で前記データベースに問い合わせるために、当該電話番号「tel URI」を使用する
ことを特徴とするネットワーク。
【請求項10】
前記ノードは、「user=phone」引数を伴うRequest URIを前記SIP要求が有する場合に、前記SIP要求がSIP URI/埋め込み電話番号を有すると判断することを特徴とする請求項9に記載のネットワーク。
【請求項11】
前記ノードは、前記変換モジュールから前記電話番号「tel URI」を受信すると、前記SIP要求において前記SIP URI/埋め込み電話番号を前記電話番号「tel URI」に置換し、この改変されたSIP要求をルーティングすることを特徴とする請求項9に記載のネットワーク。
【請求項12】
前記ノードは、インテロゲーティング呼セッション制御機能またはサービング呼セッション制御機能であることを特徴とする請求項9に記載のネットワーク。
【請求項13】
前記データベースは、前記電話番号「tel URI」に関する情報を含むが、前記SIP URI/埋め込み電話番号に関する情報を含まないことを特徴とする請求項9に記載のネットワーク。
【請求項14】
前記データベースは、加入者ロケータ機能またはホーム加入者サーバであることを特徴とする請求項9に記載のネットワーク。
【請求項15】
前記変換モジュールは、前記SIP URI/埋め込み電話番号が「phone−context」引数を含まない場合に、
前記SIP URI/埋め込み電話番号から目標ユーザ部分を抽出するステップと、
前記電話番号「tel URI」を生成するために文字列「tel:」を前記目標ユーザ部分の前に付加するステップと、
を実行することを特徴とする請求項9に記載のネットワーク。
【請求項16】
前記変換モジュールは、前記SIP URI/埋め込み電話番号が「phone−context」引数を含む場合に、
前記「phone−context」引数の後ろに位置する第1の数字の組を抽出するステップと、
前記SIP URI/埋め込み電話番号中の「sip:」の後ろで前記「phone−context」引数の前に位置する第2の数字の組を抽出するステップと、
前記電話番号「tel URI」を生成するために、前記第2の数字の組が後ろに挿入される前記第1の数字の組の前に文字列「tel:」を付加するステップと、
を実行することを特徴とする請求項9に記載のネットワーク。
【請求項17】
前記変換モジュールは、前記SIP URI/埋め込み電話番号が「phone−context」引数を含む場合に、
前記「phone−context」引数の後ろに位置する第1の数字の組を抽出するステップと、
前記SIP URI/埋め込み電話番号中の「sip:」の後ろで前記「phone−context」引数の前に位置する第2の数字の組を抽出するステップと、
一連の置換規則を見つけるための事前定義された置換規則のテーブルへのキーとして前記第1の数字の組を使用するステップと、
第3の数字の組を生成するために前記一連の置換規則を前記第2の数字の組に適用するステップと、
前記電話番号「tel URI」を生成するために、前記第3の数字の組の前に文字列「tel:」を付加するステップと、
を実行することを特徴とする請求項9に記載のネットワーク。
【請求項18】
着信ネットワークにおいてSIP要求をサービング呼セッション制御機能へルーティングするインテロゲーティング呼セッション制御機能であって、
前記SIP要求を受信する受信器と、
SIP URI/埋め込み電話番号を含む要求URIを前記SIP要求が有するか否かを判定するプロセッサと、
前記要求URIを変換モジュールへ転送し、当該変換モジュールから対応するtel URIを受信するクエリ装置と、
を備え、
前記プロセッサは、改変されたSIP要求を形成するために、前記SIP要求の前記要求URIにおいて、前記SIP URI/埋め込み電話番号を削除して前記受信したtel URIを挿入し、
当該インテロゲーティング呼セッション制御機能は、
前記tel URIを伴う前記要求URIを含む前記改変されたSIP要求を前記サービング呼セッション制御機能へ送信する送信器を更に備える
ことを特徴とするインテロゲーティング呼セッション制御機能。
【請求項19】
前記プロセッサは、前記要求URI中に「user=phone」引数が存在する場合に、前記SIP要求が前記SIP URI/埋め込み電話番号を有すると判断することを特徴とする請求項18に記載のインテロゲーティング呼セッション制御機能。
【請求項20】
前記変換モジュールから前記対応するtel URIを受信すると、前記プロセッサは、前記SIP要求において前記SIP URI/埋め込み電話番号を前記対応するtel URIに置換し、この改変されたSIP要求をルーティングすることを特徴とする請求項18に記載のインテロゲーティング呼セッション制御機能。
【請求項21】
中継ネットワークを通って着信ネットワークへSIP要求をルーティングするサービング呼セッション制御機能であって、
前記SIP要求を受信する受信器と、
SIP URI/埋め込み電話番号を含む要求URIを前記SIP要求が有するか否かを判定するプロセッサと、
前記要求URIを変換モジュールへ転送し、当該変換モジュールから対応するtel URIを受信するクエリ装置と、
を備え、
前記プロセッサは、改変されたSIP要求を形成するために、前記SIP要求の前記要求URIにおいて、前記SIP URI/埋め込み電話番号を削除して前記受信したtel URIを挿入し、
当該サービング呼セッション制御機能は、
前記tel URIを伴う前記改変されたSIP要求を前記着信ネットワークへ送信する送信器を更に備える
ことを特徴とするサービング呼セッション制御機能。
【請求項22】
前記プロセッサは、前記要求URI中に「user=phone」引数が存在する場合に、前記SIP要求が前記SIP URI/埋め込み電話番号を有すると判断することを特徴とする請求項21に記載のサービング呼セッション制御機能。
【請求項23】
前記変換モジュールから前記対応するtel URIを受信すると、前記プロセッサは、前記SIP要求において前記SIP URI/埋め込み電話番号を前記対応するtel URIに置換し、この改変されたSIP要求をルーティングすることを特徴とする請求項21に記載のサービング呼セッション制御機能。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate


【公開番号】特開2013−59100(P2013−59100A)
【公開日】平成25年3月28日(2013.3.28)
【国際特許分類】
【外国語出願】
【出願番号】特願2012−252572(P2012−252572)
【出願日】平成24年11月16日(2012.11.16)
【分割の表示】特願2008−536149(P2008−536149)の分割
【原出願日】平成18年10月20日(2006.10.20)
【出願人】(598036300)テレフオンアクチーボラゲット エル エム エリクソン(パブル) (2,266)
【Fターム(参考)】