(57)【要約】【課題】呼のルーチングに適したルーチング情報を発信端末において記録及び利用する。【解決手段】通信端末１００は、電話番号と、電話番号に対応するルーチング情報とを関連付けて記憶する記憶部１０２と、所望の電話番号に対応する所望のルーチング情報を記憶部１０２から検索する検索部１０１と、所望のルーチング情報が検索されたならば所望の電話番号及び所望のルーチング情報を含む第１の呼を生成し、所望のルーチング情報が検索されないならば所望の電話番号を含む第２の呼を生成する生成部１０３と、第１の呼または第２の呼を発信する発信部１０４と、第２の呼が第２の呼に含まれる所望の電話番号によって識別される着信端末に着信すると、この着信端末までのルーチング情報をこの所望の電話番号に関連付けて記憶部１０２に記録する更新部１０５を含む。【選択図】図１
2011254399.tif 000002
【特許請求の範囲】
【請求項１】
電話番号と、前記電話番号に対応するルーチング情報とを関連付けて記憶する記憶部と、
所望の電話番号に対応する所望のルーチング情報を前記記憶部から検索する検索部と、
前記所望のルーチング情報が検索されたならば前記所望の電話番号及び前記所望のルーチング情報を含む第１の呼を生成し、前記所望のルーチング情報が検索されないならば前記所望の電話番号を含む第２の呼を生成する生成部と、
前記第１の呼または前記第２の呼を発信する発信部と、
前記第２の呼が前記第２の呼に含まれる所望の電話番号によって識別される着信端末に着信すると、この着信端末までのルーチング情報をこの所望の電話番号に関連付けて前記記憶部に記録する更新部と
を具備する通信端末。
【請求項２】
前記ルーチング情報は、対応する電話番号によって識別される着信端末を収容している通信事業者の識別情報を含む、請求項１記載の通信端末。
【請求項３】
前記ルーチング情報は、対応する電話番号によって識別される着信端末を収容している網の識別情報を更に含む、請求項２記載の通信端末。
【請求項４】
前記ルーチング情報は、対応する電話番号によって識別される着信端末を収容しているサーバの識別情報を更に含む、請求項３記載の通信端末。
【請求項５】
前記ルーチング情報は、前記網が使用するプロトコルの識別情報を更に含む、請求項３記載の通信端末。
【請求項６】
前記ルーチング情報は、対応する電話番号によって識別される着信端末が利用するサービスの識別情報を更に含む、請求項２記載の通信端末。
【請求項７】
前記更新部は、前記第１の呼が前記第１の呼に含まれる所望の電話番号によって識別される着信端末に着信し、かつ、この着信端末までのルーチング情報が前記第１の呼に含まれる所望のルーチング情報と異なるならば、この着信端末までのルーチング情報をこの所望の電話番号に関連付けて前記記憶部を記録する、請求項１記載の通信端末。
【請求項８】
電話番号と、前記電話番号に対応するルーチング情報とを関連付けて記憶部において記憶することと、
所望の電話番号に対応する所望のルーチング情報を前記記憶部から検索することと、
前記所望のルーチング情報が検索されたならば前記所望の電話番号及び前記所望のルーチング情報を含む第１の呼を生成し、前記所望のルーチング情報が検索されないならば前記所望の電話番号を含む第２の呼を生成することと、
前記第１の呼または前記第２の呼を発信することと、
前記第２の呼が前記第２の呼に含まれる電話番号によって識別される着信端末に着信すると、この着信端末までのルーチング情報をこの所望の電話番号に関連付けて前記記憶部に記録することと
を具備する通信方法。
【請求項９】
電話番号と、前記電話番号に対応するルーチング情報とを関連付けて記憶する記憶部と、所望の電話番号に対応する所望のルーチング情報を前記記憶部から検索する検索部と、前記所望のルーチング情報が検索されたならば前記所望の電話番号及び前記所望のルーチング情報を含む第１の呼を生成し、前記所望のルーチング情報が検索されないならば前記所望の電話番号を含む第２の呼を生成する生成部と、前記第１の呼または前記第２の呼を発信する発信部と、前記第２の呼が前記第２の呼に含まれる所望の電話番号によって識別される着信端末に着信すると、この着信端末までのルーチング情報をこの所望の電話番号に関連付けて前記記憶部に記録する更新部とを含む通信端末と、
前記第１の呼に含まれている所望のルーチング情報及び所望の電話番号の少なくとも一方に従って前記第１の呼のルーチングを行い、前記第２の呼に含まれている所望の電話番号に従って前記第２の呼のルーチングを行う、少なくとも１つのサーバと
を具備する通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼のルーチングに関する。
【背景技術】
【０００２】
ＰＳＴＮ（Public Switched Telephone Network）が主流の時代に、固定電話サービス及び移動体通信（携帯電話）サービスにおいて通信事業者間の番号ポータビリティが導入された。番号ポータビリティとは、個々の加入者を識別するための番号を継続利用しつつ、サービスを提供する通信事業者を移転（変更）する手続を意味する。加入者を識別するための番号とは、固定電話サービスにおける電話番号０−ＡＢＣＤＥ−ＦＧＨＪ、携帯電話サービスにおける電話番号０Ａ０−ＣＤＥ−ＦＧＨＪＫなどである。更に、その後、各通信事業者は、複数の網及び複数種類のサーバを運用するようになった。尚、以降の説明において、特に断りのない限り、「サーバ」という用語は、ＰＳＴＮ交換機、交換機、ＳＩＰ（Session Initiation Protocol）サーバ、呼処理装置などと同様の意味で使用される。
【０００３】
発信端末から呼が発信されると、何らかのエンティティ（サーバ、データベースなど）が着信端末までの経路（着信端末を収容する通信事業者、網及びサーバ）を呼の情報に基づいて特定し、経路上の各サーバが呼を着信端末まで中継する。このような処理（経路の特定及び呼の中継）をルーチングと呼ぶ。一般に、図２に示すように、ルーチングは発信番号（ＤＮ；Dialed Number）に従って行われている（非特許文献１及び非特許文献２を参照）。番号ポータビリティが利用されている場合には、加入者の移転先へどのようにルーチングを行うかが重要であり、様々な手法が提案されている。以下、図３乃至図６を用いて、代表的な４つのルーチング方式を簡単に説明する。尚、これら４つの方式は、いずれも非特許文献３において紹介されている。
【０００４】
図３は、ＡＣＱ（All Call Query）方式を示している。まず、発信端末が、所望のＤＮを備える呼を発信する（１）。発信網（例えば、発信網内のサーバ）は、ＤＮについて集中型データベース（ＣＤＢ；Centralized Database）に検索を要求する（２）。ＣＤＢは、ＤＮに対応するキャリア（即ち、通信事業者）ＩＤ（ＣＩＤ；Carrier Identifier）を応答として発信網に返す（３）。発信網は、ＣＩＤに従って、呼を所定の網（例えば、移転先の網内のサーバ）にルーチングする。この網は、ＤＮによって識別される着信端末に呼を着信させる（５）。即ち、ＡＣＱ方式では、発信網は、全ての呼に関してＣＤＢからＤＮに対応するＣＩＤを検索し、加入者の移転先へルーチングする。
【０００５】
図４は、ＱｏＲ（Query on Release）方式を示している。まず、発信端末が、所望のＤＮを備える呼を発信する（１）。発信網は、ＤＮに従って呼を所定の網にルーチングする（２）が、ＤＮに対応する加入者が番号ポータビリティを利用してこの網から別の網に移転していると切り戻しが生じる。発信網は、切り戻しが生じると、ＤＮについてＣＤＢに検索を要求する（３）。ＣＤＢは、ＤＮに対応するＣＩＤを応答として発信網に返す（４）。発信網は、ＣＩＤに従って、呼を移転先の網にルーチングする（５）。移転先の網は、ＤＮによって識別される着信端末に呼を着信させる（６）。即ち、ＱｏＲ方式では、発信網は、切り戻しが生じてから（即ち、加入者の移転が判明してから）ＣＤＢを検索し、加入者の移転先へ再ルーチングする。
【０００６】
図５は、ＣＤ（Call Dropback）方式（リダイレクション方式とも呼ばれる）を示している。まず、発信端末が、所望のＤＮを備える呼を発信する（１）。発信網はＤＮに従って呼を所定の網にルーチングする（２）が、ＤＮに対応する加入者が番号ポータビリティを利用してこの網から別の網に移転していると、この移転元の網は分散型データベース（ＤＤＢ；Distributed Database）から移転先の網のＣＩＤを検索し、このＣＩＤと一緒に呼を切り戻す。発信網は、ＣＩＤに従って、呼を移転先の網にルーチングする（３）。移転先の網は、ＤＮによって識別される着信端末に呼を着信させる（４）。即ち、ＣＤ方式では、移転元の網がＤＤＢから加入者の移転先を検索し、検索した移転先（ＣＩＤ）を呼と一緒に切り戻し、発信網が加入者の移転先へ再ルーチングする。
【０００７】
図６は、ＯＲ（Onward Routing）方式（転送方式とも呼ばれる）を示している。まず、発信端末が、所望のＤＮを備える呼を発信する（１）。発信網は、ＤＮに従って呼を所定の網にルーチングする（２）。ＤＮに対応する加入者が番号ポータビリティを利用してこの網から別の網に移転していると、この網はＤＤＢを検索して移転先の網のＣＩＤを取得し、このＣＩＤに従って呼を移転先の網にルーチングする（３）。移転先の網は、ＤＮによって識別される着信端末に呼を着信させる（４）。即ち、ＯＲ方式では、移転元の網がＤＤＢから加入者の移転先を検索し、加入者の移転先へ再ルーチングする。
【０００８】
以下、より実際的なルーチング方式について図７乃至図１０を用いて説明する。  
図７は、従来の日本の固定電話サービスにおける番号ポータビリティのためのルーチング方式を示している。この詳細は、非特許文献４に記載されている。日本の固定電話サービスでは、東日本電信電話株式会社または西日本電信電話株式会社（以下、ＮＴＴ東西と称する）から他の通信事業者への番号ポータビリティが運用されている。故に、図７における「移転元の事業者」は、実際には、ＮＴＴ東西であるとみなすこともできる。ちなみに、固定電話サービスにおける番号ポータビリティの運用は２００２年３月から始まっており、現在では０Ａ−Ｊ番号がその対象であるが、ＶｏＩＰ（Voice over Internet Protocol）を利用する０５０番号はその対象でない。加えて、運用当初は前述の転送方式が採用されていたものの、番号を二重に消費する問題を解消すべく２００７年２月１日に前述のリダイレクション方式も採用されることとなった。
【０００９】
図７のルーチング方式は、リダイレクション方式を採用している。まず、発信端末が、所望のＤＮ（番号０−ＡＢＣＤＥ−ＦＧＨＪ）を備える呼を発信する（１）。発信網がＤＮ中のＡＢＣＤＥコードに従って呼を移転元の事業者にルーチングし（２）、移転元の事業者がＡＢＣＤＥコードに従って呼を移転元の網にルーチングし（３）、移転元の網がＡＢＣＤＥコードに従って呼を移転元の交換機にルーチングする（４）。ＤＮに対応する加入者が番号ポータビリティを利用して別の事業者に移転していると、移転元の交換機は個別データベースから移転先の交換機を特定するコードを検索し、この移転先の交換機を特定するコードと一緒に呼を切り戻す（５）。尚、移転先の交換機を特定するコードは、ＩＳＵＰ（ISDN User Part）のリリース信号ＲＥＬを用いて発信網に通知される。発信網は移転先の交換機を特定するコード及びＤＮに従って呼を移転先の事業者にルーチングし（６）、移転先の事業者は移転先の交換機を特定するコード及びＤＮに従って呼を移転先の網にルーチングし（７）、移転先の網は移転先の交換機を特定するコード及びＤＮに従って呼を移転先の交換機にルーチングする（８）。移転先の交換機は、ＤＮによって識別される着信端末に呼を着信させる（９）。
【００１０】
図８は、従来の日本の携帯電話サービスにおける番号ポータビリティ（いわゆる、携帯番号ポータビリティ）のためのルーチング方式を示している。この詳細は、非特許文献５に記載されている。携帯番号ポータビリティは、携帯電話サービスの通信事業者間の移転を可能にする。ちなみに、携帯番号ポータビリティの運用は、２００６年１１月から開始されている。尚、運用当初には転送方式のみが採用されていたが、２００７年２月１日よりリダイレクション方式も採用されることとなった。
【００１１】
図８のルーチング方式は、リダイレクション方式を採用している。まず、発信端末が、所望のＤＮ（番号０Ａ０−ＣＤＥ−ＦＧＨＪＫ）を備える呼を発信する（１）。発信網がＤＮ中のＣＤＥコードに従って呼を移転元の事業者にルーチングする（２）。ＤＮに対応する加入者が番号ポータビリティを利用して別の事業者に移転していると、移転元の事業者はＤＮについてモビリティ／サービス制御データベースに検索を要求する（３）。モビリティ／サービス制御データベースは、ＤＮに対応する移転先情報（事業者固有のコード）を応答として移転元の事業者に返す（４）。移転元の事業者は、この事業者固有のコードと一緒に呼を切り戻す（５）。尚、事業者固有のコードは、ＩＳＵＰのリリース信号ＲＥＬを用いて発信網に通知される。発信網は事業者固有のコード及びＤＮに従って呼を移転先の事業者にルーチングする（６）。移転先の事業者は、モビリティ／サービス制御データベースに加入者認証／在圏検索を要求する（７）。モビリティ／サービス制御データベースは認証の応答（在圏情報を含む）を移転先の事業者に返す（８）。移転先の事業者は、在圏情報及びＤＮに従って呼をルーチングし（９）、ＤＮによって識別される着信端末に呼を着信させる（１０）。
【００１２】
図９は、従来の米国における番号ポータビリティのためのルーチング方式を示している。この詳細は、非特許文献６に記載されている。米国の番号ポータビリティは、固定電話、携帯電話、ＶｏＩＰ間の区別なく、各地域交換事業者（ＬＥＣ；Local Exchange Carrier）間の移転を可能にする。米国の番号ポータビリティは、固定電話のみならず、携帯電話であっても登録住所が提供エリア内であれば対象となる。また、ＶｏＩＰも品質による番号の違いがなく、同様に米国の番号ポータビリティの対象となる。
【００１３】
図９のルーチング方式は、ＡＣＱ方式を採用している。まず、発信端末が、所望のＤＮ（ＮＡＰ＋ＮＸＸ−ＸＸＸＸ）を備える呼を発信する（１）。発信網からＮ−１網まで、ＤＮ内のＮＡＰ＋ＮＮＮコードに従って呼のルーチングが行われる。ここで、Ｎ−１網とは、着信網の手前の網を意味しており、図９において発信網の一部とみなすことができる。Ｎ−１網は、番号ポータビリティ提供地区宛ての呼のＤＮについてデータベースに検索を要求する（２）。データベースは、移転先を示す情報（ＬＲＮ；Location Routing Number)を応答としてＮ−１網に返す（３）。ここで、ＬＲＮとは、ＮＰＡ＋ＮＸＸコードで始まる１０桁の非ダイヤル番号であり、移転先の交換機を識別する。尚、移転が行われていない場合には、データベースは与えられたＤＮをそのまま返す。Ｎ−１網はＬＲＮ及びＤＮに従って呼を移転先の事業者にルーチングし（４）、移転先の事業者はＬＲＮ及びＤＮに従って呼を移転先の網にルーチングし（５）、移転先の網はＬＲＮ及びＤＮに従って呼を移転先のサーバにルーチングする（６）。移転先のサーバは、ＤＮによって識別される着信端末に呼を着信させる（７）。
【００１４】
図１０は、３Ｇ／ＷＬＡＮ（Wireless Local Area Network）デュアル端末向けのルーチング方式を示している。この詳細は、非特許文献７に記載されている。まず、発信端末が、所望のＤＮ（＋ＣＣ  ＸＸＸＸ  ＸＸＸＸ）及びルーチング番号（ＲＮ）を備える呼を発信する（１）。ＲＮは、移転先の情報を含んでおり、これは発信端末の電話帳においてＤＮと対応付けて記憶されている。発信網（ＷＬＡＮ）内のサーバ（ＲＩＳ；Routing Information Server）はＲＮに従って移転先の事業者に呼をルーチングする（２）。ここで、ＲＩＳは、ＷＬＡＮ内に収容する通信端末の電話帳に記録された各ＤＮに対応するＲＮを集中型データベースから取得、蓄積及び更新することができる。また、ＲＩＳは、通信端末からのＲＮの問い合わせに応答することもできる。移転先の事業者はＲＮに従って移転先の網に呼をルーチングし（３）、移転先の網はＲＮに従って移転先のサーバに呼をルーチングする（４）。移転先のサーバは、ＲＮによって識別される着信端末に呼を着信させる（５）。
【００１５】
尚、この方式は、ＲＮが陳腐化している場合の処理も考慮されている。ＲＮが陳腐化している場合、呼はＲＩＳに切り戻される（＃１）。ＲＩＳは、呼に含まれるＤＮについて集中型データベース（ＤＢｃ）に検索を要求する（＃２）。集中型データベースは、ＤＮに対応する現行のＲＮを応答としてＲＩＳに返す（＃３）。そして、ＲＩＳはこの現行のＲＮに従って再ルーチングする。
【００１６】
図１０の方式は、発信端末が、電話帳においてＤＮ及びＲＮを関連付けて保持している点で先に紹介した従来のルーチング方式と比べて特徴的である。発信端末は、ＲＩＳ経由で集中型データベースからＲＮを取得する。具体的には、集中型データベースとＲＩＳとの間のデータ同期（図１１の点線矢印を参照）は、周期的（例えば低負荷時）にオフラインで実施される。また、ＲＩＳと発信端末の電話帳との間のデータ同期（図１１の実線矢印を参照）は、発信端末がＷＬＡＮ内で起動されるタイミングと、発信端末からＲＩＳに対してデータ同期を要求するタイミングとに実施される。この方式は、ＡＣＱ方式に分類されると思われるが、発呼の有無に関わらず電話帳内の全てのＤＮに対してＲＮを予め取得している点で異なる。
【先行技術文献】
【非特許文献】
【００１７】
【非特許文献１】米田正明、「電話はなぜつながるのか」、日経ＢＰ社、２００６年、第４章「ダイヤルすると電話交換機たちがおしゃべりを開始」
【非特許文献２】中嶋信生、有田武美、「携帯電話はなぜつながるのか」、日経ＢＰ社、２００７年、第６章「携帯電話を便利にする付加機能  〜国際ローミング、ＦＭＣ、位置情報、番号ポータビリティ」
【非特許文献３】［online］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc3482.txt＞
【非特許文献４】ＮＴＴ東日本、「インフォメーションＮＴＴ東日本２００９」、p.36、［online］、２００９年、インターネット＜ＵＲＬ：http://www.ntt-east.co.jp/databook/2009/pdf/2009_allpage.pdf＞
【非特許文献５】総務省、「携帯電話の番号ポータビリティの在り方に関する研究会  報告書」、［online］、２００４年４月２７日、インターネット＜ＵＲＬ：http://warp.da.ndl.go.jp/info:ndljp/pid/283520/www.soumu.go.jp/s-news/2004/pdf/040427_4bt1.pdf＞
【非特許文献６】NORTH AMERICAN NUMBERINGCOUNCIL ARCHITECTURE & ADMINISTRATIVE PLAN FOR LOCAL NUMBER PORTABILITY Issue 2 Revision 0, NANC - Local Number Portability Administration Working Group Wireless Wireline Integration Task Force
【非特許文献７】Ching-Wen Cheng, C. G. Chung, "Utilizing 3G/WLAN Dual-Mode Terminals to Enhance the Efficiency of Mobile Number Portability Service," IEEE Com. Mag., vol. 44, no. 6, pp. 110-116, June 2006.
【発明の概要】
【発明が解決しようとする課題】
【００１８】
従来のルーチング方式には、いくつかの課題が想定される。以下、従来のルーチング方式の課題について図１２乃至図１７を用いて説明する。  
一般に、通信料金の体系は、発信端末を収容する事業者と着信端末を収容する事業者とが同一か否かによって異なる（図１２を参照）。しかしながら、番号ポータビリティを考慮すると、呼の発信時点において着信端末を現在収容する事業者がＤＮから一意に識別できない。故に、呼を発信する時点では着信端末を収容する事業者が定まらず、ひいては料金体系が不明となりユーザにとって不便である。
【００１９】
現在、通信事業者は、従前の通信プロトコル（ＩＳＵＰ）を使用する網（ＰＳＴＮ）に加えて、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）のＳＩＰを使用するＳＩＰ網を導入することがある。即ち、各通信事業者は、複数の網を運用している可能性がある。しかしながら、着信端末を現在収容する網が使用する通信プロトコルはＤＮのみに基づいて一意に識別できない。従って、従来のルーチング方式によれば、ＤＮに基づいて適切なプロトコル変換装置を選択できないので、無駄な変換（例えば、図１３の変換１−１及び変換１−２は冗長である）、高コストな変換（例えば、図１３において変換２−１及び変換２−１のどちらが低コストになるかルーチング時点では不明なので）などが生じるおそれがある。
【００２０】
また、現在、ＦＭＣ（Fixed Mobile Convergence）と呼ばれる固定電話サービスと携帯電話サービスとの融合サービスが提案されている。このサービスによれば、例えば、発信側が相手方の固定電話端末及び携帯電話端末のうちの一方のＤＮを用いて発信すると、相手側は固定電話端末及び携帯電話端末のいずれによっても着信することができる。但し、従来のルーチング方式によれば、ルーチング時にＦＭＣなどのサービスの適用の有無を判定していない。故に、図１４に示すように、当初は呼に含まれるＤＮに従ってルーチング（（１）〜（６））を行い、場合により呼が切り戻されてから再ルーチングを行う（（７）〜（１１））ことによってサービスが実現される。即ち、サービス実現のために、着信端末を収容するサーバなどに場合分けのための判断ロジックを導入する必要がある。このような判断ロジックを導入すると、サーバの処理が複雑化し、ひいては接続遅延が増大するという問題がある。
【００２１】
従来、集中型データベースまたは分散型データベースを利用して、着信端末を収容する事業者などを特定（番号解決）している。集中型データベースを利用する形態では、この集中型データベースが単一故障点となる（図１５を参照）。従って、集中型データベースの稼働率を一定以上にする（集中型データベースが故障しにくくなるようにしたり、故障した場合に短時間で復旧するようにしたりする）ためには、高いコストが必要となる。一方、集中型データベースにかけることのできるコストには制限があるし、他の装置間でコストのバランスを取る必要もある。コストと信頼性または稼働率（可用性）との間にはトレードオフの関係があるので、集中型データベースにかけるコストを抑えれば信頼性または稼働率が低下するおそれがある。
【００２２】
一方、分散型データベースを利用する形態では、集中型データベースを利用する形態に比べてルーチングが複雑になりやすい。例えば、呼処理が移転元事業者と移転先事業者との両方に跨る（図１６を参照）ので、故障箇所の特定がより難しいという問題がある。また、リダイレクションの呼処理（無効となる呼処理、図１６における（２）〜（５））を含めた設備設計を行う必要があるので、より高いコストが必要になるという問題がある。更に、リダイレクションの呼処理の負担について、各事業者間で認識を合わせるのは一般に難しく、各事業者が公平と認識するような費用負担の制度設計が困難であるという問題がある。
【００２３】
また、図１０の方式では、通信端末とＲＩＳとの間でデータ同期を行うときに、この通信端末の電話帳に記録されている全てのＤＮについてＲＮを検索する点が非効率である。更に、ＲＩＳと集中型データベースとの間でデータ同期を行うときに、一度に多数のＲＮを検索するので集中型データベースに高い処理能力が要求されるという問題もある（図１７を参照）。多数のＲＩＳからの検索がまれに集中することを想定して集中型データベースを設計する必要があるが、このような設計は非効率である。
【００２４】
従って、本発明は、呼のルーチングに適したルーチング情報を発信端末において記録及び利用することを目的とする。
【課題を解決するための手段】
【００２５】
本発明の一態様に係る通信端末は、電話番号と、前記電話番号に対応するルーチング情報とを関連付けて記憶する記憶部と、所望の電話番号に対応する所望のルーチング情報を前記記憶部から検索する検索部と、前記所望のルーチング情報が検索されたならば前記所望の電話番号及び前記所望のルーチング情報を含む第１の呼を生成し、前記所望のルーチング情報が検索されないならば前記所望の電話番号を含む第２の呼を生成する生成部と、前記第１の呼または前記第２の呼を発信する発信部と、前記第２の呼が前記第２の呼に含まれる所望の電話番号によって識別される着信端末に着信すると、この着信端末までのルーチング情報をこの所望の電話番号に関連付けて前記記憶部に記録する更新部とを具備する。
【００２６】
本発明の別の態様に係る通信システムは、電話番号と、前記電話番号に対応するルーチング情報とを関連付けて記憶する記憶部と、所望の電話番号に対応する所望のルーチング情報を前記記憶部から検索する検索部と、前記所望のルーチング情報が検索されたならば前記所望の電話番号及び前記所望のルーチング情報を含む第１の呼を生成し、前記所望のルーチング情報が検索されないならば前記所望の電話番号を含む第２の呼を生成する生成部と、前記第１の呼または前記第２の呼を発信する発信部と、前記第２の呼が前記第２の呼に含まれる所望の電話番号によって識別される着信端末に着信すると、この着信端末までのルーチング情報をこの所望の電話番号に関連付けて前記記憶部に記録する更新部とを含む通信端末と、前記第１の呼に含まれている所望のルーチング情報及び所望の電話番号の少なくとも一方に従って前記第１の呼のルーチングを行い、前記第２の呼に含まれている所望の電話番号に従って前記第２の呼のルーチングを行う、少なくとも１つのサーバとを具備する。
【発明の効果】
【００２７】
本発明によれば、呼のルーチングに適したルーチング情報を発信端末において記録及び利用することができる。
【図面の簡単な説明】
【００２８】
【図１】一実施形態に係る通信端末を示すブロック図。
【図２】従来のルーチング方式の説明図。
【図３】ＡＣＱ方式の説明図。
【図４】ＱｏＲ方式の説明図。
【図５】ＣＤ方式の説明図。
【図６】ＯＲ方式の説明図。
【図７】従来の日本の固定電話サービスにおける番号ポータビリティのためのルーチング方式の説明図。
【図８】従来の日本の携帯番号ポータビリティのためのルーチング方式の説明図。
【図９】従来の米国の番号ポータビリティのためのルーチング方式の説明図。
【図１０】３Ｇ／ＷＬＡＮデュアル端末向けのルーチング方式の説明図。
【図１１】図１０のルーチング方式におけるデータ同期の説明図。
【図１２】従来のルーチング方式における課題の説明図。
【図１３】従来のルーチング方式における課題の説明図。
【図１４】従来のルーチング方式における課題の説明図。
【図１５】従来のルーチング方式における課題の説明図。
【図１６】従来のルーチング方式における課題の説明図。
【図１７】従来のルーチング方式における課題の説明図。
【図１８】一実施形態に係るルーチング方式の説明図。
【図１９】一実施形態に係るルーチング方式の効果の説明図。
【図２０】一実施形態に係るルーチング方式の効果の説明図。
【図２１】一実施形態に係るルーチング方式の効果の説明図。
【図２２】一実施形態に係るルーチング方式の効果の説明図。
【図２３】一実施形態に係るルーチング方式の効果の説明図。
【図２４】ルーチング情報ＣＩＤを利用するルーチングのcase1における様子の説明図。
【図２５】ルーチング情報ＣＩＤを利用するルーチングのcase2における様子の説明図。
【図２６】ルーチング情報ＣＩＤを利用するルーチングのcase3における様子の説明図。
【図２７】ルーチング情報ＮＩＤ．ＣＩＤを利用するルーチングのcase1における様子の説明図。
【図２８】ルーチング情報ＮＩＤ．ＣＩＤを利用するルーチングのcase2における様子の説明図。
【図２９】ルーチング情報ＮＩＤ．ＣＩＤを利用するルーチングのcase3における様子の説明図。
【図３０】ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを利用するルーチングのcase1における様子の説明図。
【図３１】ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを利用するルーチングのcase2における様子の説明図。
【図３２】ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを利用するルーチングのcase3における様子の説明図。
【発明を実施するための形態】
【００２９】
以下、図面を参照して、本発明の一実施形態について説明する。  
図１に示すように、本発明の一実施形態に係る発信端末１００は、ルーチング情報検索部１０１、ルーチング情報記憶部１０２、呼生成部１０３、発信部１０４及びルーチング情報更新部１０５を含む。尚、発信端末１００は、図示しない構成要素（例えば、呼の着信機能に関わる構成要素、ルーチング情報の表示機能に関わる構成要素）を含んでも勿論よい。また、本願において、発信端末及び着信端末の一方または両方を通信端末と称することもある。
【００３０】
ルーチング情報検索部１０１は、ルーチング情報記憶部１０２から所望の電話番号（ＤＮ）に対応するルーチング情報を検索する。所望の電話番号とは、発信端末１００のユーザが発信のために入力（ダイヤル、テンキーの押下、電話帳データの選択など）した電話番号を意味する。尚、ルーチング情報の詳細は後述する。
【００３１】
ルーチング情報記憶部１０２は、電話番号と、この電話番号に対応するルーチング情報とを関連付けて記憶する。ルーチング情報記憶部１０２は、例えば、電話番号及び対応するルーチング情報をテーブル形式で記憶することができる。ルーチング情報記憶部１０２は、典型的には、発信端末１００の電話帳機能によって管理されている電話番号に対応するルーチング情報を記憶する。ルーチング情報は、電話帳データの一部として扱われてもよいし、電話帳データと別に扱われてもよい。ルーチング情報記憶部１０２へのルーチング情報の記録及び更新は、後述するルーチング情報更新部１０５によって行われる。
【００３２】
呼生成部１０３は、ルーチング情報検索部１０１による検索の完了後に呼を生成する。具体的には、呼生成部１０３は、ルーチング情報検索部１０１による検索が成功すれば、所望の電話番号に加えて検索されたルーチング情報を備える呼（便宜的に第１の呼とも称する）を生成する。一方、呼生成部１０３は、ルーチング情報検索部１０１による検索が失敗すれば、所望の電話番号を備える呼（便宜的に第２の呼とも称する）を生成する。発信部１０４は、呼生成部１０３によって生成された呼（第１の呼または第２の呼）を発信網のサーバに発信する。
【００３３】
ルーチング情報更新部１０５は、発信部１０４から発信された呼に対して現行のルーチング情報が判明すると、ルーチング情報記憶部１０２に対して現行のルーチング情報の記録または更新を行う。現行のルーチング情報が判明するタイミングとしては、発信部１０４から発信された呼が着信端末に着信するときなどが挙げられる。
【００３４】
ルーチング情報更新部１０５は、第２の呼に関して、所望の電話番号がルーチング情報記憶部１０２に記録されていなければ（例えば、ユーザがＤＮをダイヤルまたはテンキーの押下によって入力する場合）、ルーチング情報更新部１０５は所望の電話番号及び現行のルーチング情報のセットをルーチング情報記憶部１０２に新規に記録してもよいし、無視してもよい（この選択は、ユーザによって手動でなされてもよいし、発信端末１００によって自動的になされてもよい）。また、所望の電話番号がルーチング情報記憶部１０２に記録されていれば、ルーチング情報更新部１０５は現行のルーチング情報をこの所望の電話番号に関連付けて記録する。
【００３５】
また、ルーチング情報更新部１０５は、第１の呼に関して、ルーチング情報を無条件に更新してもよいし、現行のルーチング情報が既に記録されているルーチング情報と異なること（即ち、既に記録されているルーチング情報が陳腐化していること）を確認してから更新してもよい。ルーチング情報の陳腐化は、例えば、着信端末の加入者が番号ポータビリティによって別の事業者に移転した場合、着信端末を収容するサーバ、網または事業者が分割または統合された場合などに生じるおそれがある。
【００３６】
また、ルーチング情報更新部１０５は、発信端末１００が呼を着信するときに、その呼の発信側の電話番号及び現行のルーチング情報に基づいてルーチング情報記憶部１０２に対する記録または更新を行ってもよい。例えば、発信側の電話番号がルーチング情報記憶部１０２に記録されていなければ、ルーチング情報更新部１０５は発信側の電話番号及び現行のルーチング情報のセットをルーチング情報記憶部１０２に新規に記録してもよいし、無視してもよい（この選択は、ユーザによって手動でなされてもよいし、発信端末１００によって自動的になされてもよい）。また、発信側の電話番号がルーチング情報記憶部１０２に記録されていれば、ルーチング情報更新部１０５はルーチング情報を無条件に記録または更新してもよいし、現行のルーチング情報が既に記録されているルーチング情報と異なることを確認してから更新してもよい。
【００３７】
前述のように、呼は、着信端末を収容する事業者にルーチングされ、この事業者内で着信端末を収容する網にルーチングされ、この網内で着信端末を収容するサーバにルーチングされる。本実施形態におけるルーチング情報は、呼のルーチングの基本構造に対応する階層的な構造を持つ。
【００３８】
具体的には、ルーチング情報は、対応する着信端末を収容する事業者の識別情報を含むことができる。ルーチング情報は、対応する着信端末を収容する事業者の識別情報に加えて、この着信端末を収容する網の識別情報を含むことができる。ルーチング情報は、対応する着信端末を収容する事業者の識別情報及びこの着信端末を収容する網の識別情報に加えて、この着信端末を収容するサーバの識別情報を含むことができる。即ち、ルーチング情報に特定の階層の識別情報を含める場合に、望ましくは、全てのより上位の階層の識別情報が含められる。
【００３９】
また、ルーチング情報は、対応する着信端末を収容する網の識別情報を含む場合に、この網が使用するプロトコルの識別情報を更に含むこともできる。また、ルーチング情報は、対応する着信端末がＦＭＣなどの特定のサービスを利用している場合には、このサービスの識別情報を更に含むこともできる。
【００４０】
図１８は、本実施形態に従うルーチング方式を示す。図１８は、ルーチング情報が、事業者の識別情報、網の識別情報及びサーバの識別情報（或いは、更にサービスの識別情報）が含む場合を例示している。発信端末（例えば、図１の発信端末１００）から、所望の電話番号及び対応するルーチング情報を備える呼（ＤＮ＠ＩＤ）が発信される。発信網はルーチング情報に従って呼を所定の事業者にルーチングし、所定の事業者はルーチング情報に従って呼を所定の網にルーチングし、所定の網はルーチング情報に従って呼を所定のサーバにルーチングする。所定のサーバは、所望の電話番号（ＤＮ）によって識別される着信端末に呼を着信させる。この時点で、着信端末までの現行のルーチング情報が判明するので、この現行のルーチング情報が発信端末内部においてルーチング情報の記録または更新に適宜利用される。
【００４１】
以下、図２４乃至図３２を用いて本実施形態に係るルーチング情報を利用するルーチング方式の詳細を説明する。ここでは、３種類のルーチング情報の夫々について、その情報を利用するルーチングの３種類の事例の夫々における様子を例示して説明する。ルーチング情報として、（１）ＣＩＤ、（２）ＮＩＤ．ＣＩＤ及び（３）ＳＩＤ．ＮＩＤ．ＣＩＤの３種類を規定する。ＣＩＤは事業者の識別情報を示し、ＮＩＤは網の識別情報を示し、ＳＩＤはサーバの識別情報を示している。また、ＮＩＤ．ＣＩＤは事業者の識別情報と網の識別情報との組み合わせを示し、ＳＩＤ．ＮＩＤ．ＣＩＤは事業者の識別情報と網の識別情報とサーバの識別情報との組み合わせを示している。また、事例としてcase1、case2及びcase3の３種類を規定する。case1は、所望の電話番号に対応するルーチング情報が前述のルーチング情報記憶部１０２に記録されていない事例（換言すれば、前述のルーチング情報検索部１０１による検索に失敗する事例）を示す。case2は、所望の電話番号に対するルーチング情報がルーチング情報記憶部１０２に記憶されているものの、そのルーチング情報が陳腐化している事例を示す。case3は、所望の電話番号に対するルーチング情報がルーチング情報記憶部１０２に記憶されており、かつ、そのルーチング情報が現行のルーチング情報と一致している事例を示す。
【００４２】
図２４は、ルーチング情報ＣＩＤを利用するルーチングのcase1における様子を示している。まず、ルーチング情報検索部１０１は、所望の電話番号（ＤＮ）に対応するルーチング情報ＣＩＤをルーチング情報記憶部１０２から検索する（１）。case1において検索は失敗するので、呼生成部１０３がＤＮを備える呼（第２の呼）を生成し、発信部１０４はこの呼を発信する（２）。この呼には、本実施形態に係るルーチング情報ＣＩＤが含まれていないので、従来と同じルーチングがＤＮに従って行われる（３）。尚、実際には、集中型データベース、分散データベースなどを利用した番号解決が行われるが、前述の説明と重複するので省略する。移転先のサーバ（着信端末を収容するサーバ）は、ＤＮによって識別される着信端末に呼を着信させる（４）。この時点で、着信端末までの現行のルーチング情報が判明するので、この現行のルーチング情報が発信端末内部においてルーチング情報の記録または更新に適宜利用される（５）。例えば、ルーチング情報更新部１０５は、ＤＮと関連付けて現行のルーチング情報をルーチング情報記憶部１０２に記録する。
【００４３】
図２５は、ルーチング情報ＣＩＤを利用するルーチングのcase2における様子を示している。まず、ルーチング情報検索部１０１は、所望の電話番号（ＤＮ）に対応するルーチング情報ＣＩＤをルーチング情報記憶部１０２から検索する（１）。case2において検索は成功するので、呼生成部１０３はＤＮ及び検索されたルーチング情報ＣＩＤを備える呼（第１の呼）を生成し、発信部１０４はこの呼を発信する（２）。発信網は、ルーチング情報ＣＩＤに従って所定の事業者に呼をルーチングする（３）。このルーチング情報ＣＩＤには、網及びサーバを識別するための情報が含まれていないので、所定の事業者は従来と同じルーチングをＤＮに従って行う（４）。しかしながら、case2においてルーチング情報ＣＩＤが陳腐化しているため呼を着信端末にルーチングすることができず、呼は発信網に切り戻される（５）。以後、集中型データベース、分散データベースなどを利用した番号解決が行われるが、前述の説明と重複するので省略する。移転先のサーバ（着信端末を収容するサーバ）は、ＤＮによって識別される着信端末に呼を着信させる。この時点で、着信端末までの現行のルーチング情報が判明するので、この現行のルーチング情報が発信端末内部においてルーチング情報の記録または更新に適宜利用される。例えば、ルーチング情報更新部１０５は、ルーチング情報記憶部１０２においてＤＮと関連付けて既に記憶されているルーチング情報ＣＩＤを現行のルーチング情報に更新（置換）する。
【００４４】
図２６は、ルーチング情報ＣＩＤを利用するルーチングのcase3における様子を示している。まず、ルーチング情報検索部１０１は、所望の電話番号（ＤＮ）に対応するルーチング情報ＣＩＤをルーチング情報記憶部１０２から検索する（１）。case3において検索は成功するので、呼生成部１０３はＤＮ及び検索されたルーチング情報ＣＩＤを備える呼（第１の呼）を生成し、発信部１０４はこの呼を発信する（２）。発信網は、ルーチング情報ＣＩＤに従って所定の事業者に呼をルーチングする（３）。このルーチング情報ＣＩＤには、網及びサーバを識別するための情報が含まれていないので、所定の事業者は従来と同じルーチングをＤＮに従って行う（４）。移転先のサーバ（着信端末を収容するサーバ）は、ＤＮによって識別される着信端末に呼を着信させる（５）。この時点で、着信端末までの現行のルーチング情報が判明するので、この現行のルーチング情報が発信端末内部においてルーチング情報の記録または更新に適宜利用される（６）。尚、case3では、ルーチング情報記憶部１０２においてＤＮに関連付けて記憶されているルーチング情報ＣＩＤが現行のルーチング情報に一致しているので、ルーチング情報更新部１０５は必ずしも記録または更新を行わない。
【００４５】
以上のように、発信端末においてルーチング情報ＣＩＤを記録及び利用すれば、case3において着信端末を収容する事業者までルーチング情報ＣＩＤに従って呼が適切にルーチングされる。また、case1及びcase2においても、結果的に現行のルーチング情報ＣＩＤが判明し、発信端末において記録され、以後利用可能となる。尚、ルーチング情報ＣＩＤの陳腐化は頻繁には起こらない（case2は例外的な事例である）ことを考慮すれば、大抵の場合はcase3に該当すると予想されるので、発信端末においてルーチング情報ＣＩＤを記録及び利用することの効果は十分に得られる。
【００４６】
図２７は、ルーチング情報ＮＩＤ．ＣＩＤを利用するルーチングのcase1における様子を示している。まず、ルーチング情報検索部１０１は、所望の電話番号（ＤＮ）に対応するルーチング情報ＮＩＤ．ＣＩＤをルーチング情報記憶部１０２から検索する（１）。case1において検索は失敗するので、呼生成部１０３がＤＮを備える呼（第２の呼）を生成し、発信部１０４はこの呼を発信する（２）。この呼には、本実施形態に係るルーチング情報ＮＩＤ．ＣＩＤが含まれていないので、従来と同じルーチングがＤＮに従って行われる（３）。尚、実際には、集中型データベース、分散データベースなどを利用した番号解決が行われるが、前述の説明と重複するので省略する。移転先のサーバ（着信端末を収容するサーバ）は、ＤＮによって識別される着信端末に呼を着信させる（４）。この時点で、着信端末までの現行のルーチング情報が判明するので、この現行のルーチング情報が発信端末内部においてルーチング情報の記録または更新に適宜利用される（５）。例えば、ルーチング情報更新部１０５は、ＤＮと関連付けて現行のルーチング情報をルーチング情報記憶部１０２に記録する。
【００４７】
図２８は、ルーチング情報ＮＩＤ．ＣＩＤを利用するルーチングのcase2における様子を示している。まず、ルーチング情報検索部１０１は、所望の電話番号（ＤＮ）に対応するルーチング情報ＮＩＤ．ＣＩＤをルーチング情報記憶部１０２から検索する（１）。case2において検索は成功するので、呼生成部１０３はＤＮ及び検索されたルーチング情報ＮＩＤ．ＣＩＤを備える呼（第１の呼）を生成し、発信部１０４はこの呼を発信する（２）。発信網は、ルーチング情報ＮＩＤ．ＣＩＤ（特に、ＣＩＤ）に従って所定の事業者に呼をルーチングする（３）。所定の事業者は、ルーチング情報ＮＩＤ．ＣＩＤ（特に、ＮＩＤ）に従って所定の網に呼をルーチングする（４）。このルーチング情報ＮＩＤ．ＣＩＤには、サーバを識別するための情報が含まれていないので、所定の網は従来と同じルーチングをＤＮに従って行う（５）。しかしながら、case2においてルーチング情報ＮＩＤ．ＣＩＤが陳腐化しているため呼を着信端末にルーチングすることができず、呼は発信網に切り戻される（６）。以後、集中型データベース、分散データベースなどを利用した番号解決が行われるが、前述の説明と重複するので省略する。移転先のサーバ（着信端末を収容するサーバ）は、ＤＮによって識別される着信端末に呼を着信させる。この時点で、着信端末までの現行のルーチング情報が判明するので、この現行のルーチング情報が発信端末内部においてルーチング情報の記録または更新に適宜利用される。例えば、ルーチング情報更新部１０５は、ルーチング情報記憶部１０２においてＤＮと関連付けて既に記憶されているルーチング情報ＮＩＤ．ＣＩＤを現行のルーチング情報に更新（置換）する。
【００４８】
図２９は、ルーチング情報ＮＩＤ．ＣＩＤを利用するルーチングのcase3における様子を示している。まず、ルーチング情報検索部１０１は、所望の電話番号（ＤＮ）に対応するルーチング情報ＮＩＤ．ＣＩＤをルーチング情報記憶部１０２から検索する（１）。case3において検索は成功するので、呼生成部１０３はＤＮ及び検索されたルーチング情報ＮＩＤ．ＣＩＤを備える呼（第１の呼）を生成し、発信部１０４はこの呼を発信する（２）。発信網は、ルーチング情報ＮＩＤ．ＣＩＤ（特に、ＣＩＤ）に従って所定の事業者に呼をルーチングする（３）。所定の事業者は、ルーチング情報ＮＩＤ．ＣＩＤ（特に、ＮＩＤ）に従って所定の網に呼をルーチングする（４）。このルーチング情報ＮＩＤ．ＣＩＤには、サーバを識別するための情報が含まれていないので、所定の網は従来と同じルーチングをＤＮに従って行う（５）。移転先のサーバ（着信端末を収容するサーバ）は、ＤＮによって識別される着信端末に呼を着信させる（６）。この時点で、着信端末までの現行のルーチング情報が判明するので、この現行のルーチング情報が発信端末内部においてルーチング情報の記録または更新に適宜利用される（７）。尚、case3では、ルーチング情報記憶部１０２においてＤＮに関連付けて記憶されているルーチング情報ＮＩＤ．ＣＩＤが現行のルーチング情報に一致しているので、ルーチング情報更新部１０５は必ずしも記録または更新を行わない。
【００４９】
以上のように、発信端末においてルーチング情報ＮＩＤ．ＣＩＤを記録及び利用すれば、case3において着信端末を収容する網までルーチング情報ＮＩＤ．ＣＩＤに従って呼が適切にルーチングされる。また、case1及びcase2においても、結果的に現行のルーチング情報ＮＩＤ．ＣＩＤが判明し、発信端末において記録され、以後利用可能となる。尚、ルーチング情報ＮＩＤ．ＣＩＤの陳腐化は頻繁には起こらない（case2は例外的な事例である）ことを考慮すれば、大抵の場合はcase3に該当すると予想されるので、発信端末においてルーチング情報ＮＩＤ．ＣＩＤを記録及び利用することの効果は十分に得られる。
【００５０】
図３０は、ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを利用するルーチングのcase1における様子を示している。まず、ルーチング情報検索部１０１は、所望の電話番号（ＤＮ）に対応するルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤをルーチング情報記憶部１０２から検索する（１）。case1において検索は失敗するので、呼生成部１０３がＤＮを備える呼（第２の呼）を生成し、発信部１０４はこの呼を発信する（２）。この呼には、本実施形態に係るルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤが含まれていないので、従来と同じルーチングがＤＮに従って行われる（３）。尚、実際には、集中型データベース、分散データベースなどを利用した番号解決が行われるが、前述の説明と重複するので省略する。移転先のサーバ（着信端末を収容するサーバ）は、ＤＮによって識別される着信端末に呼を着信させる（４）。この時点で、着信端末までの現行のルーチング情報が判明するので、この現行のルーチング情報が発信端末内部においてルーチング情報の記録または更新に適宜利用される（５）。例えば、ルーチング情報更新部１０５は、ＤＮと関連付けて現行のルーチング情報をルーチング情報記憶部１０２に記録する。
【００５１】
図３１は、ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを利用するルーチングのcase2における様子を示している。まず、ルーチング情報検索部１０１は、所望の電話番号（ＤＮ）に対応するルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤをルーチング情報記憶部１０２から検索する（１）。case2において検索は成功するので、呼生成部１０３はＤＮ及び検索されたルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを備える呼（第１の呼）を生成し、発信部１０４はこの呼を発信する（２）。発信網は、ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤ（特に、ＣＩＤ）に従って所定の事業者に呼をルーチングする（３）。所定の事業者は、ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤ（特に、ＮＩＤ）に従って所定の網に呼をルーチングする（４）。所定の網は、ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤ（特に、ＳＩＤ）に従って所定のサーバに呼をルーチングする（５）。しかしながら、case2においてルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤが陳腐化しているため呼を着信端末にルーチングすることができず、呼は発信網に切り戻される（６）。以後、集中型データベース、分散データベースなどを利用した番号解決が行われるが、前述の説明と重複するので省略する。移転先のサーバ（着信端末を収容するサーバ）は、ＤＮによって識別される着信端末に呼を着信させる。この時点で、着信端末までの現行のルーチング情報が判明するので、この現行のルーチング情報が発信端末内部においてルーチング情報の記録または更新に適宜利用される。例えば、ルーチング情報更新部１０５は、ルーチング情報記憶部１０２においてＤＮと関連付けて既に記憶されているルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを現行のルーチング情報に更新（置換）する。
【００５２】
図３２は、ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを利用するルーチングのcase3における様子を示している。まず、ルーチング情報検索部１０１は、所望の電話番号（ＤＮ）に対応するルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤをルーチング情報記憶部１０２から検索する（１）。case3において検索は成功するので、呼生成部１０３はＤＮ及び検索されたルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを備える呼（第１の呼）を生成し、発信部１０４はこの呼を発信する（２）。発信網は、ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤ（特に、ＣＩＤ）に従って所定の事業者に呼をルーチングする（３）。所定の事業者は、ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤ（特に、ＮＩＤ）に従って所定の網に呼をルーチングする（４）。所定の網は、ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤ（特に、ＳＩＤ）に従って所定のサーバに呼をルーチングする（５）。移転先のサーバ（着信端末を収容するサーバ）は、ＤＮによって識別される着信端末に呼を着信させる（６）。この時点で、着信端末までの現行のルーチング情報が判明するので、この現行のルーチング情報が発信端末内部においてルーチング情報の記録または更新に適宜利用される（７）。尚、case3では、ルーチング情報記憶部１０２においてＤＮに関連付けて記憶されているルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤが現行のルーチング情報に一致しているので、ルーチング情報更新部１０５は必ずしも記録または更新を行わない。
【００５３】
以上のように、発信端末においてルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを記録及び利用すれば、case3において着信端末を収容するサーバまでルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤに従って呼が適切にルーチングされる。また、case1及びcase2においても、結果的に現行のルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤが判明し、発信端末において記録され、以後利用可能となる。尚、ルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤの陳腐化は頻繁には起こらない（case2は例外的な事例である）ことを考慮すれば、大抵の場合はcase3に該当すると予想されるので、発信端末においてルーチング情報ＳＩＤ．ＮＩＤ．ＣＩＤを記録及び利用することの効果は十分に得られる。
【００５４】
続いて、本実施形態に係るルーチング方式と、従来の各ルーチング方式とを比較して相違点を概説する。  
本実施形態に係るルーチング方式は、case1，case2及びcase3のいずれにおいても、呼の発信の前に発信端末がルーチング情報の検索を行う点と、呼の着信後に発信端末が現行のルーチング情報の記録または更新を行う点とで、図７、図８または図９のルーチング方式と異なる。また、本実施形態に係るルーチング方式は、case2及びcase3において、ＤＮのみでなくルーチング情報にも従ってルーチング（リダイレクションを含む）が行われる（但し、case2に関しては事後的にＤＮのみに従ってルーチングが行われる）点で、図７、図８または図９のルーチング方式と異なる。
【００５５】
また、本実施形態に係るルーチング方式は、case1，case2及びcase3のいずれにおいても、呼の着信後に発信端末が現行のルーチング情報の記録または更新を行う点で、図１０のルーチング方式と異なる。
以下、図１９乃至図２３を用いて本実施形態に係るルーチング方式の効果を説明する。  
従来のルーチング方式によれば、呼を発信する時点では着信端末を収容する事業者が定まらず、ひいては料金体系が不明となりユーザにとって不便である（図１２を参照）。一方、本実施形態に係るルーチング方式によれば、case3において、発信端末は着信端末を収容する事業者をルーチング情報に基づいて確認することができるので、呼を発信する時点であっても料金体系を特定することができる（図１９を参照）。尚、case1またはcase2の場合には、従来と同様の問題が生じるおそれがある。しかしながら、発信端末は、case1及びcase2における着信後に現行のルーチング情報を記録及び利用することによって、以後の呼の発信時点において料金体系を特定することができる。
【００５６】
従来のルーチング方式によれば、ＤＮに基づいて適切なプロトコル変換装置を選択できないので、無駄な変換（例えば、図１３の変換１−１及び変換１−２は冗長である）、高コストな変換（例えば、図１３において変換２−１及び変換２−１のどちらが低コストになるかルーチング時点では不明なので）などが生じるおそれがある。一方、本実施形態に係るルーチング方式において、着信端末を収容する事業者の識別情報、着信端末を収容する網の識別情報及びこの網が使用するプロトコルの識別情報をルーチング情報に含めることが可能である。このようなルーチング情報を利用すれば、case3において、呼をルーチングする発信網は無駄のないプロトコル変換を行ったり、複数の候補のうちコストのより低いプロトコル変換を選択したりすることが可能となる（図２０を参照）。尚、case1またはcase2の場合には、従来と同様の問題が生じるおそれがある。しかしながら、発信端末はcase1及びcase2における着信後に現行のルーチング情報を記録及び利用するので、発信網は以後に発信される呼に関して無駄のないプロトコル変換を行ったり、複数の候補からよりコストの低いプロトコル変換を選択したりすることが可能となる。
【００５７】
従来のルーチング方式によれば、ルーチング時にＦＭＣなどのサービスの適用の有無を判定していないので、図１４に示すように、当初は呼に含まれるＤＮに従ってルーチング（（１）〜（６））を行い、場合により呼を切り戻して再ルーチングを行う（（７）〜（１１））ことによってサービスが実現される。即ち、サービス実現のために、着信端末を収容するサーバなどに場合分けのための判断ロジックを導入する必要がある。このような判断ロジックを導入すると、サーバの処理が複雑化し、ひいては接続遅延が増大するという問題がある。一方、本実施形態に係るルーチング情報は、着信端末がＦＭＣなどの特定のサービスを利用している場合に、このサービスの識別情報を更に含むこともできる。即ち、本実施形態において、例えば、着信端末を収容する事業者の識別情報ＣＩＤと、着信端末が利用しているサービスを示す識別情報ＦＭＣとの組み合わせであるルーチング情報ＦＭＣ．ＣＩＤを利用することができる（図２１を参照）。図２１の例において、呼は、ルーチング情報ＦＭＣ．ＣＩＤ（特に、ＣＩＤ）に従って所定の事業者にルーチングされる（（１），（２））。事業者は、ルーチング情報ＦＭＣ．ＣＩＤ（特に、ＦＭＣ）を参照してＦＭＣの適用を確認すると、ＤＮについてデータベースＤＢＦＭＣに検索を要求する（３）。データベースＤＢＦＭＣは、ＦＭＣサービスのためのデータベースであり、サービス対象の電話番号（ＤＮ）について、現在着信させるべき網のＩＤ（ＮＩＤ）を関連付けて保持している。このＮＩＤは、例えば１日に数回程度の頻度で更新され、各回の所要時間は数十秒程度である。データベースＤＢＦＭＣは、検索した網のＩＤ（ＮＩＤ）を応答として事業者に返す（４）。事業者は、検索されたＮＩＤに従って、呼を所定の網にルーチングする（５）。網内のサーバは、ＤＮによって識別される着信端末に呼を着信させる（６）。以上のように、ルーチング情報ＦＭＣ．ＣＩＤを利用すれば、case3において接続遅延が短縮化するなどの効果が期待できる。
【００５８】
従来のルーチング方式によれば、集中型データベースを利用する形態において、この集中型データベースが単一故障点となる（図１５を参照）ことに起因する諸問題が生じる。一方、本実施形態に係るルーチング方式によれば、集中型データベースを用いた番号解決が必要となるのはcase1及びcase2の場合に限られる（図２２を参照）。case1は最初の発信、case2はルーチング情報が陳腐化した後の最初の発信について夫々該当するものの、大抵の発信はcase3に該当すると考えられる。即ち、本実施形態において、集中型データベースは、例外的に使用されるバックアップ装置という位置付けとなる。従って、本実施形態によれば、集中型データベースが単一故障点となることに起因する生じる諸問題の影響は限定的であるとみなすことができる。一方、本実施形態において、（特にcase2の場合に）接続遅延が延伸するおそれがある。尚、接続遅延の延伸への対策として、人からの発呼に関して既存の音声ガイダンスの技術が有効であることが知られている。
【００５９】
従来のルーチング方式によれば、分散型データベースを利用する形態において、集中型データベースを利用する形態に比べてルーチングが複雑になりやすい（図１６を参照）ことに起因する諸問題が生じる。一方、本実施形態に係るルーチング方式によれば、分散型データベースを用いた番号解決が必要となるのはcase1及びcase2の場合に限られる（図２３を参照）。case1は最初の発信、case2はルーチング情報が陳腐化した後の最初の発信について夫々該当するものの、大抵の発信はcase3に該当すると考えられる。即ち、本実施形態において、分散型データベースは、例外的に使用されるバックアップ装置という位置付けとなる。従って、本実施形態によれば、ルーチングが複雑となることにより生じる諸問題の影響は限定的であるとみなすことができる。一方、本実施形態において、（特にcase2の場合に）接続遅延が延伸するおそれがある。尚、接続遅延の延伸への対策例は、前述の通りである。
【００６０】
また、図１０の方式では、ＲＩＳと集中型データベースとの間でデータ同期を行うときに、一度に多数のＲＮを検索するので集中型データベースに高い処理能力が要求されるという問題がある（図１７を参照）。一方、本実施形態によれば、集中型データベースが他のサーバなどとデータ同期を行う必要がないので、このような問題は生じない。
【００６１】
以上説明したように、本発明の一実施形態に係るルーチング方式において、発信端末は発呼の着信後に着信端末までの現行のルーチング情報を記録及び更新し、以後の発呼ではこのルーチング情報を利用する。従って、本実施形態に係るルーチング方式によれば、呼の適切なルーチングが行われやすくなり、ユーザ及び事業者の双方に様々なメリットが期待できる。
【００６２】
尚、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また上記実施形態に開示されている複数の構成要素を適宜組み合わせることによって種々の発明を形成できる。また例えば、実施形態に示される全構成要素からいくつかの構成要素を削除した構成も考えられる。
【００６３】
例えば、上記実施形態の処理を実現するプログラムを、コンピュータで読み取り可能な記憶媒体に格納して提供することも可能である。記憶媒体としては、磁気ディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ等）、光磁気ディスク（ＭＯ等）、半導体メモリなど、プログラムを記憶でき、かつ、コンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であってもよい。
【００６４】
また、上記実施形態の処理を実現するプログラムを、インターネットなどのネットワークに接続されたコンピュータ（サーバ）上に格納し、ネットワーク経由でコンピュータ（クライアント）にダウンロードさせてもよい。
【符号の説明】
【００６５】
１００・・・発信端末
１０１・・・ルーチング情報検索部
１０２・・・ルーチング情報記憶部
１０３・・・呼生成部
１０４・・・発信部
１０５・・・ルーチング情報検索部
【図１】
2011254399.tif 000003
【図２】
2011254399.tif 000004
【図３】
2011254399.tif 000005
【図４】
2011254399.tif 000006
【図５】
2011254399.tif 000007
【図６】
2011254399.tif 000008
【図７】
2011254399.tif 000009
【図８】
2011254399.tif 000010
【図９】
2011254399.tif 000011
【図１０】
2011254399.tif 000012
【図１１】
2011254399.tif 000013
【図１２】
2011254399.tif 000014
【図１３】
2011254399.tif 000015
【図１４】
2011254399.tif 000016
【図１５】
2011254399.tif 000017
【図１６】
2011254399.tif 000018
【図１７】
2011254399.tif 000019
【図１８】
2011254399.tif 000020
【図１９】
2011254399.tif 000021
【図２０】
2011254399.tif 000022
【図２１】
2011254399.tif 000023
【図２２】
2011254399.tif 000024
【図２３】
2011254399.tif 000025
【図２４】
2011254399.tif 000026
【図２５】
2011254399.tif 000027
【図２６】
2011254399.tif 000028
【図２７】
2011254399.tif 000029
【図２８】
2011254399.tif 000030
【図２９】
2011254399.tif 000031
【図３０】
2011254399.tif 000032
【図３１】
2011254399.tif 000033
【図３２】
2011254399.tif 000034