(57)【特許請求の範囲】
【請求項１】
変換前の電話機の識別情報に含まれる電話機情報と、電話機の属性を示す属性値と、変換後の識別情報とを関連付けて記憶する記憶部と、
呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定する属性値特定部と、
呼制御信号の発信元の識別情報を、当該識別情報と前記属性値特定部が特定した属性値とに関連付けられた変換後の識別情報に書き換える発信元書換部と、
呼制御信号の発信先の識別情報を、当該識別情報と前記属性値特定部が特定した属性値とに関連付けられた変換後の識別情報に書き換える発信先書換部と
を備え、
前記記憶部は、位置識別情報を示す前記属性値に関連付けられた前記電話機情報と、グループ識別情報を示す前記属性値に関連付けられた前記電話機情報とを記憶する
呼制御装置。
【請求項２】
前記記憶部は、位置識別情報を示す前記属性値に関連付けられた、特番種別を示す前記電話機情報と、グループ識別情報を示す前記属性値に関連付けられた、ドメイン種別を示す前記電話機情報とを記憶する
請求項１に記載の呼制御装置。
【請求項３】
前記呼制御信号の発信元の識別情報と、前記発信元の属性値とを関連づける第２記憶部をさらに備え、
前記属性値特定部が、前記第２記憶部を参照して、呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定する
請求項１または請求項２に記載の呼制御装置。
【請求項４】
変換前の電話機の識別情報に含まれる電話機情報と、電話機の属性を示す属性値と、変換後の識別情報とを関連付けて記憶する記憶部を用いて、
呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定するステップと、
呼制御信号の発信元の識別情報を、当該識別情報と特定した前記属性値とに関連付けられた変換後の識別情報に書き換えるステップと、
呼制御信号の発信先の識別情報を、当該識別情報と特定した前記属性値とに関連付けられた変換後の識別情報に書き換えるステップと
を含み、
前記記憶部は、位置識別情報を示す前記属性値に関連付けられた前記電話機情報と、グループ識別情報を示す前記属性値に関連付けられた前記電話機情報とを記憶する
呼制御方法。
【請求項５】
変換前の電話機の識別情報に含まれる電話機情報と、電話機の属性を示す属性値と、変換後の識別情報とを関連付けて記憶する記憶部を用いて、
呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定するステップと、
呼制御信号の発信元の識別情報を、当該識別情報と特定した前記属性値とに関連付けられた変換後の識別情報に書き換えるステップと、
呼制御信号の発信先の識別情報を、当該識別情報と特定した前記属性値とに関連付けられた変換後の識別情報に書き換えるステップと
をコンピュータに実行させ、
前記記憶部は、位置識別情報を示す前記属性値に関連付けられた前記電話機情報と、グループ識別情報を示す前記属性値に関連付けられた前記電話機情報とを記憶する
プログラム。
【請求項６】
呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定する属性値特定部と、
呼制御信号の発信元の識別情報を、当該識別情報と前記属性値特定部が特定した属性値とに関連付けられた変換後の識別情報に書き換える発信元書換部と、
呼制御信号の発信先の識別情報を、当該識別情報と前記属性値特定部が特定した属性値とに関連付けられた変換後の識別情報に書き換える発信先書換部と
を備える呼制御装置によって用いられ、
変換前の電話機の識別情報に含まれる電話機情報と、電話機の属性を示す属性値と、変換後の識別情報とを関連付けた呼制御用データ構造であって、
変換前の発信元の識別情報に含まれる電話機情報と、発信元の前記電話機のグループ識別情報を示す属性値と、発信元の変換後の識別情報とが関連付けられた発信元変換用レコードであって、前記属性値特定部による前記発信元の属性値の特定後に、前記発信元書換部が呼制御信号の発信元の識別情報を書き換える処理に用いられる、発信元変換用レコードと、
変換前の発信先の識別情報に含まれる電話機情報と、発信元の前記電話機の位置識別情報を示す属性値と、発信先の変換後の識別情報とが関連付けられた発信先変換用レコードであって、前記発信先書換部が前記呼制御信号の発信先の識別情報を書き換える処理に用いられる、発信先変換用レコードと
を含む呼制御用データ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、呼制御装置、呼制御方法、プログラム、及び呼制御用データ構造に関する。
【背景技術】
【０００２】
特許文献１には、ＩＰ（Internet Protocol）電話システムにおいて、発信元の電話番号の変換を行う技術の一例が記載されている。特許文献１に記載されている技術では、発信元の電話番号に基づいて発番号変換データベースを参照することで発信先の電話番号が変換される。また、特許文献２には、ＩＰ電話システムにおいて、発信元の電話番号の変換と、発信先の電話番号の変換との両方を行う技術の一例が記載されている。特許文献２に記載されている技術では、発信先の電話番号に基づいて着番号変換データベースを参照することで発信元の電話番号が変換される。また、特許文献２に記載されている技術では、発信元電話番号に基づいて発番号変換データベースを参照することで発信先の電話番号が変換される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開第９８／４１０４２号パンフレット
【特許文献２】特開２００７−１５０７１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載されている技術では、発信先の電話番号の変換をすることができない。他方、特許文献２に記載されている技術では、発信元と発信先の電話番号の変換をすることができるが、発信元の電話番号の変換に用いるデータベースと、発信先の電話番号の変換に用いるデータベースとが別々に設けられている。そのため、管理すべきデータベースの数が多くなり、リソースの消費が大きいという課題があった。
【０００５】
本発明の目的は、上記の課題を解決する呼制御装置、呼制御方法、プログラム、及び呼制御用データ構造を提供することにある。
【課題を解決するための手段】
【０００６】
上記課題を解決するため、本発明の一態様に係る呼制御装置は、変換前の電話機の識別情報に含まれる電話機情報と、電話機の属性を示す属性値と、変換後の識別情報とを関連付けて記憶する記憶部と、呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定する属性値特定部と、呼制御信号の発信元の識別情報を、当該識別情報と前記属性値特定部が特定した属性値とに関連付けられた変換後の識別情報に書き換える発信元書換部と、呼制御信号の発信先の識別情報を、当該識別情報と前記属性値特定部が特定した属性値とに関連付けられた変換後の識別情報に書き換える発信先書換部とを備え、前記記憶部は、位置識別情報を示す前記属性値に関連付けられた前記電話機情報と、グループ識別情報を示す前記属性値に関連付けられた前記電話機情報とを記憶する。
【０００７】
また、本発明の一態様に係る呼制御方法は、変換前の電話機の識別情報に含まれる電話機情報と、電話機の属性を示す属性値と、変換後の識別情報とを関連付けて記憶する記憶部を用いて、呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定するステップと、呼制御信号の発信元の識別情報を、当該識別情報と特定した前記属性値とに関連付けられた変換後の識別情報に書き換えるステップと、呼制御信号の発信先の識別情報を、当該識別情報と特定した前記属性値とに関連付けられた変換後の識別情報に書き換えるステップとを含み、前記記憶部は、位置識別情報を示す前記属性値に関連付けられた前記電話機情報と、グループ識別情報を示す前記属性値に関連付けられた前記電話機情報とを記憶する。
【０００８】
また、本発明の一態様に係るプログラムは、変換前の電話機の識別情報に含まれる電話機情報と、電話機の属性を示す属性値と、変換後の識別情報とを関連付けて記憶する記憶部を用いて、呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定するステップと、呼制御信号の発信元の識別情報を、当該識別情報と特定した前記属性値とに関連付けられた変換後の識別情報に書き換えるステップと、呼制御信号の発信先の識別情報を、当該識別情報と特定した前記属性値とに関連付けられた変換後の識別情報に書き換えるステップとをコンピュータに実行させ、前記記憶部は、位置識別情報を示す前記属性値に関連付けられた前記電話機情報と、グループ識別情報を示す前記属性値に関連付けられた前記電話機情報とを記憶する。
【００１０】
また、本発明の一態様に係る呼制御用データ構造は、呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定する属性値特定部と、呼制御信号の発信元の識別情報を、当該識別情報と前記属性値特定部が特定した属性値とに関連付けられた変換後の識別情報に書き換える発信元書換部と、呼制御信号の発信先の識別情報を、当該識別情報と前記属性値特定部が特定した属性値とに関連付けられた変換後の識別情報に書き換える発信先書換部とを備える呼制御装置によって用いられ、変換前の電話機の識別情報に含まれる電話機情報と、電話機の属性を示す属性値と、変換後の識別情報とを関連付けた呼制御用データ構造であって、変換前の発信元の識別情報に含まれる電話機情報と、発信元の前記電話機のグループ識別情報を示す属性値と、発信元の変換後の識別情報とが関連付けられた発信元変換用レコードであって、前記属性値特定部による前記発信元の属性値の特定後に、前記発信元書換部が呼制御信号の発信元の識別情報を書き換える処理に用いられる、発信元変換用レコードと、変換前の発信先の識別情報に含まれる電話機情報と、発信元の前記電話機の位置識別情報を示す属性値と、発信先の変換後の識別情報とが関連付けられた発信先変換用レコードであって、前記発信先書換部が前記呼制御信号の発信先の識別情報を書き換える処理に用いられる、発信先変換用レコードとを含む。
【発明の効果】
【００１１】
上述した少なくとも１つの態様によれば、発信元番号の変換と発信先番号の変換との両方を実現しつつ、管理すべきデータベースの数を少なくすることができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態に係る呼処理サーバ装置の構成例を説明するための構成図である。
【図２Ａ】図１に示した呼処理サーバ装置２０の動作例を図２Ｂとともに示すフローチャートである。
【図２Ｂ】図１に示した呼処理サーバ装置２０の動作例を図２Ａとともに示すフローチャートである。
【図３】図１に示した加入者管理ＤＢ（データベース）部２２の構成例を示した説明図である。
【図４】図１に示した番号変換管理ＤＢ部２３の構成例を示した説明図である。
【図５】図２Ａ及び図２Ｂに示したフローチャートにおける通信内容の具体例を示した説明図である。
【図６】図２Ａ及び図２Ｂに示したフローチャートにおける通信内容の他の具体例を示した説明図である。
【図７】本発明の一実施形態に係る呼制御装置の基本構成を示した構成図である。
【図８】本発明の一実施形態に係る記憶装置の基本構成を示した構成図である。
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明の実施形態について説明する。図１は、本発明の呼制御装置の一実施形態である呼処理サーバ装置の構成例を説明するための構成図である。
【００１４】
図１に示した呼処理サーバ装置２０は、コンピュータであり、内部にＣＰＵ（中央処理装置）、主記憶装置、補助記憶装置、通信装置、入出力装置等のハードウェアを備える。呼処理サーバ装置２０は、それらのハードウェアを用いて所定のプログラムを実行することで、呼制御に係る所定の機能を実現する。
【００１５】
呼処理サーバ装置２０は、メイン処理部２１と、加入者管理ＤＢ部２２と、番号変換管理ＤＢ部２３とを備える。呼処理サーバ装置２０は、発側の呼処理ネットワーク１１に接続されている。この場合、発側の呼処理ネットワーク１１は私設網である。この発側の呼処理ネットワーク１１には、内線電話機１０が接続されている。また、発側の呼処理ネットワーク１１には、着側の呼処理ネットワーク１２が接続されている。着側の呼処理ネットワーク１２は公衆網である。この着側の呼処理ネットワーク１２には、電話機１３が接続されている。
【００１６】
本実施形態において、呼処理サーバ装置２０は、ＳＩＰ（Session Initiation Protocol）通信プロトコルを使用して呼を確立するためのネットワーク構成の一部として機能する。また、図１は、内線電話機１０を発側の電話機、電話機１３を着側の電話機として呼を確立する場合に送受信される通信信号の一例を示す。一般に、ＳＩＰ通信プロトコルを使用して呼を確立する手順では、発側の電話機から、発側の呼処理ネットワークと着側の呼処理ネットワークを介して、着側の電話機へとＩＮＶＩＴＥリクエスト信号を送達する必要がある。もし発着の電話機のユーザが異なる通信事業者の加入者である場合、発側の呼処理ネットワークは発側の通信事業者によって運営されるものであり、着側の呼処理ネットワークは着側の通信事業者によって運営されるものである。そのため、図１は、発側の呼処理ネットワーク１１と着側の呼処理ネットワーク１２とを分けて記載している。
【００１７】
図１において、発側の呼処理ネットワーク１１は、内線網の呼処理ネットワークであり、内線番号を割り当てた内線電話機１０を収容している。また、着側の呼処理ネットワーク１２は、公衆網の呼処理ネットワークであり、電話番号を割り当てた電話機１３を収容している。
【００１８】
呼処理サーバ装置２０は、ＩＥＴＦ（Internet Engineering Task Force）  ＲＦＣ（Request For Comment）３２６１（２００２−０６）において機能要件が定義されているＳＩＰ  ｐｒｏｘｙ、ＳＩＰ  ｒｅｇｉｓｔｒａｒ、ＳＩＰ  ｒｅｄｉｒｅｃｔ  ｓｅｒｖｅｒの機能要件のすべての機能または一部の機能を実装した装置である。この場合、呼処理サーバ装置２０は、ＩＮＶＩＴＥリクエスト信号のルーティング機能、および、発側の呼処理ネットワーク１１に収容されている加入者情報管理の機能を有している。
【００１９】
呼処理サーバ装置２０は、ＩＮＶＩＴＥリクエスト信号を送受信して中継する装置であり、発側の呼処理ネットワーク１１において、ＩＮＶＩＴＥリクエスト信号を対象として、電話番号変換処理を実施する。呼処理サーバ装置２０が備えるメイン処理部２１は、呼処理サーバ装置２０の外部との間でＩＮＶＩＴＥリクエスト信号を送受信する。加入者管理ＤＢ部２２は、発側の呼処理ネットワーク１１に収容されている電話機／加入者の情報をあらかじめ保持する。番号変換管理ＤＢ部２３は、発電話番号と着電話番号の変換に必要な情報をあらかじめ保持する。
【００２０】
図３は、加入者管理ＤＢ部２２のデータベースのテーブル構成の具体例を示している。本テーブルは、「加入者のＵＲＩ（Uniform Resource Identifier）情報」によって発加入者を指定して、その指定に紐づく「加入者の位置・グループＩＤ（identifier；識別子）」を取得する用途のため存在する。すなわち、加入者管理ＤＢ部２２は、「加入者のＵＲＩ情報」を検索用キー情報とした問い合わせに対し、検索用キー情報に対応する「加入者の位置・グループＩＤ」を表すデータを返信する。
【００２１】
「加入者のＵＲＩ情報」は、加入者を一意に特定する識別子であり、電話番号とドメインの識別子とを含んで構成される。電話番号はドメインごとに一意であればよく、ドメインが異なれば、電話番号は重複してよい。例えば、内線番号は、企業毎に一意であり、企業が異なれば、内線番号は重複してよい。なお、ドメインは、ドメイン名とも呼ばれ、インターネット等のネットワーク上で、コンピュータ、端末装置、通信制御装置等のノードを特定する名前である。
【００２２】
「加入者の位置・グループＩＤ」は、電話機の地理的な位置と、内線電話機のグループとを特定する識別子である。それぞれの内線電話機は、位置ＩＤとグループＩＤを各１つ割り当てられている。ここで、位置ＩＤが位置を一意に特定する識別子である。また、グループＩＤがグループを一意に特定する識別子である。
【００２３】
図３に示した例において、例えば一番上のレコードの「加入者のＵＲＩ情報」フィールドには「ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ１．ｃｏｍ」が格納されている。この「ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ１．ｃｏｍ」が加入者を一意に特定する識別子である。また、この「ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ１．ｃｏｍ」のうち、「ｓｉｐ：」を除いた区切り記号（あるいは区切り文字）「＠」より前の「５１−１００１」が発電話番号であり、区切り記号「＠」より後の「ｃｏｍｐａｎｙ１．ｃｏｍ」がドメインである。
【００２４】
また、一番上のレコードの「加入者の位置・グループＩＤ」フィールドには「３００１；３９０１」が格納されている。この「３００１；３９０１」のうち、区切り記号「；」より前の「３００１」が位置ＩＤであり、区切り記号「；」より後の「３９０１」がグループＩＤである。
【００２５】
図４は、番号変換管理ＤＢ部２３のデータベースのテーブル構成の具体例を示している。本テーブルは２つの用途のために存在する。１点目は、特番種別と位置ＩＤを指定して、その指定に紐づく変換後のＵＲＩ情報を取得する用途である。２点目は、ドメイン種別とグループＩＤを指定して、その指定に紐づく変換後のＵＲＩ情報を取得する用途である。そのため、本実施形態の番号変換管理ＤＢ部２３は、次のようにデータベースを構成する。すなわち、番号変換管理ＤＢ部２３のデータベースは、各レコード２３１に、以下の第１フィールド２３２と、第２フィールド２３３と、第３フィールド２３４とを含むテーブルから構成される。
【００２６】
第１フィールド２３２は、「特番／ドメイン種別」のフィールドであり、特番種別又はドメイン種別のいずれか一方を格納する。特番種別は、特番を表すデータである。特番は、特殊番号とも呼ばれ、通常の電話番号とは異なる用途の電話番号である。国内の電話番号では０又は１から始まる。ただし、市外局番は特番ではない。また、接続する電話会社を選ぶための事業者識別番号も特番ではない。特番には、「１１０」の３桁特番である緊急（通報）特番、「０」の１桁特番である外線特番等がある。第１フィールド２３２に格納される特番種別は、例えば、特番を表す１から４桁の数字から構成される。また、ドメイン種別は、上述したドメインを表すデータである。ドメイン種別は、ドメインそのものであってもよいし、あるいは、ドメインのうち、ＵＲＩ情報を一意に特定するのに必要な一部のデータから構成されていてもよい。すなわち、ドメイン種別は、上述したドメインの一部又は全部から構成される。
【００２７】
第２フィールド２３３は、「位置／グループＩＤ」のフィールドであり、位置ＩＤ又はグループＩＤのいずれか一方を格納する。位置ＩＤ及びグループＩＤは、図３を参照して説明した加入者管理ＤＢ部２２のデータベースに格納されたものと同じである。例えば、同一レコード２３１において、第１フィールド２３２が特番種別を格納している場合、第２フィールド２３３は位置ＩＤを格納する。また、同一レコード２３１において、第１フィールド２３２がドメイン種別を格納している場合、第２フィールド２３３はグループＩＤを格納する。
【００２８】
第３フィールド２３４は、「変換後のＵＲＩ情報」のフィールドであり、変換後のＵＲＩ情報を格納する。第３フィールド２３４に格納される「変換後のＵＲＩ情報」には、発信先のＵＲＩ情報を表す場合と、発信元のＵＲＩ情報を表す場合との２種類がある。この第３フィールド２３４に格納される「変換後のＵＲＩ情報」の種類は、同一レコード２３１の第１フィールド２３２に格納されたデータが特番種別なのか、ドメイン種別なのかによって異なる。また、第３フィールド２３４に格納される「変換後のＵＲＩ情報」は、第１フィールドに格納されているデータと第２フィールドに格納されたデータとに対応付けられている。すなわち、同一レコード２３１の第１フィールド２３２が特番種別を格納している場合、第３フィールド２３４は、第１フィールド２３２の特番種別と第２フィールド２３３の位置ＩＤとに対応する特番の発信先の電話番号を表すＵＲＩ情報を格納する。また、同一レコード２３１の第１フィールド２３２がドメイン種別を格納している場合、第３フィールド２３４は、第１フィールド２３２のドメイン種別と第２フィールド２３３のグループＩＤとに対応する発信元の代表番号を表すＵＲＩ情報を格納する。
【００２９】
番号変換管理ＤＢ部２３は、特番種別と位置ＩＤとを検索用キー情報として、又は、ドメイン種別とグループＩＤとを検索用キー情報として、次のように変換後のＵＲＩ情報を抽出する。すなわち、呼処理サーバ装置２０は、緊急特番への発信の場合には最寄りの緊急機関に着信させるための処理を行う。このため、番号変換管理ＤＢ部２３は、メイン処理部２１からの「特番種別」と「位置ＩＤ」とを検索用キー情報とした問い合わせに対し、最寄りの緊急機関の電話番号を表す「変換後のＵＲＩ情報」を返信する。また、呼処理サーバ装置２０は、内線電話機からの発信の場合、「ドメイン種別」と「グループＩＤ」とに紐づいて、着側の電話機に対して発電話番号として代表番号を通知する処理を行う。このため、番号変換管理ＤＢ部２３は、メイン処理部２１からの「ドメイン種別」と「グループＩＤ」とを検索用キー情報とした問い合わせに対し、代表番号を表す「変換後のＵＲＩ情報」を返信する。
【００３０】
図４に示した例において、レコード２３１ａの第１フィールド２３２には「１１０」が格納されている。この「１１０」は特番種別である。レコード２３１ａの第２フィールド２３３には「３００１」が格納されている。この「３００１」は位置ＩＤである。そして、レコード２３１ａの第３フィールド２３４には「ｓｉｐ：０３−００００−０００１＠ｐｕｂｌｉｃ．ｊｐ」が格納されている。この「ｓｉｐ：０３−００００−０００１＠ｐｕｂｌｉｃ．ｊｐ」は特番種別「１１０」と位置ＩＤ「３００１」とに紐付けられたＵＲＩ情報である。この第３フィールド２３４に格納された「ｓｉｐ：０３−００００−０００１＠ｐｕｂｌｉｃ．ｊｐ」は、例えば、最寄りの緊急機関の電話番号を表すデータである。この場合、「０３−００００−０００１」が最寄りの緊急機関の電話番号である。
【００３１】
また、図４に示した例において、レコード２３１ｂの第１フィールド２３２には「ｃｏｍｐａｎｙ１．ｃｏｍ」が格納されている。この「ｃｏｍｐａｎｙ１．ｃｏｍ」はドメイン種別である。レコード２３１ｂの第２フィールド２３３には「３９０１」が格納されている。この「３９０１」はグループＩＤである。そして、レコード２３１ｂの第３フィールド２３４には「ｓｉｐ：０３−９０００−０００１＠ｐｕｂｌｉｃ．ｊｐ」が格納されている。この「ｓｉｐ：０３−９０００−０００１＠ｐｕｂｌｉｃ．ｊｐ」はドメイン種別「ｃｏｍｐａｎｙ１．ｃｏｍ」とグループＩＤ「３９０１」とに紐付けられたＵＲＩ情報である。この第３フィールド２３４に格納された「ｓｉｐ：０３−９０００−０００１＠ｐｕｂｌｉｃ．ｊｐ」は、例えば、発側における代表番号を表すデータである。この場合、「０３−９０００−０００１」が代表番号である。
【００３２】
なお、図３及び図４において、ＵＲＩ情報が含む記号「−（ハイフン）」は、可読性のための表記であり、実際の通信信号では設定されない場合もある。
【００３３】
また、番号変換管理ＤＢ部２３は、第１フィールド２３２に格納されたデータが、特番種別又はドメイン種別のどちらなのかということを、第１フィールド２３２に格納されたデータの内容あるいは形式によって判別することができる。例えば、番号変換管理ＤＢ部２３は、第１フィールド２３２に格納されたデータが、ドメインを表す文字列における区切り記号「．」（ピリオド）を含む場合に、当該データがドメイン種別であると判別することができる。あるいは、番号変換管理ＤＢ部２３は、例えば、第１フィールド２３２に格納されたデータが、「０」又は「１」から始まる１〜４桁の数字である場合に、当該データが特番種別であると判別することができる。なお、各フィールドに格納するデータは、文字列（数字列を含む）そのものであってもよいし、文字列に対して所定の変換処理、圧縮処理等を施したデータであってもよい。
【００３４】
次に、呼処理サーバ装置２０の動作について図２Ａ及び図２Ｂを参照して説明する。なお、図２Ａに示したフローチャートと図２Ｂに示したフローチャートとは結合子Ａ２１、Ａ２２及びＡ２３によってそれぞれ結合される。以下、図１に示した構成において、内線電話機１０が外線発信を行う場合について説明する。
【００３５】
内線電話機１０は、外線発信を意図して、番号変換前ＩＮＶＩＴＥリクエスト３０を送信する。番号変換前ＩＮＶＩＴＥリクエスト３０には、発信先を示す「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータと、発信元を示す「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータとが設定される。
【００３６】
なお、発信元を示す「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータを内線電話機１０で付与すると、内線電話機１０のユーザによりパラメータの値を詐称される可能性があるため、次の構成を用いることがある。すなわち、番号変換前ＩＮＶＩＴＥリクエスト３０を中継する呼処理サーバ装置（図示なし）を発側の呼処理ネットワーク１１に配置し、その呼処理サーバ装置で「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータを検証して付与する場合もある。この検証の仕組みに関する説明は割愛する。
【００３７】
呼処理サーバ装置２０は、番号変換前ＩＮＶＩＴＥリクエスト３０を受信し（Ｓ１０１）、メイン処理部２１、加入者管理ＤＢ部２１、番号変換管理ＤＢ部２３により、以下の処理を行う。
【００３８】
メイン処理部２１は、受信した「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータから、「発加入者のＵＲＩ情報」を取得し、その「発加入者のＵＲＩ情報」を加入者管理ＤＢ部２２に入力する（Ｓ１０２、ＩＮ＃３１）。ここで、「Ｓ」に続く数字はステップの番号を表す。「ＩＮ＃」あるいは後述する「ＯＵＴ＃」に続く数字は送受信される情報の番号を表す。
【００３９】
加入者管理ＤＢ部２２は、メイン処理部２１から入力された「発加入者のＵＲＩ情報」を検索用キー情報として、該当する「発加入者の位置・グループＩＤ」を特定し、メイン処理部２１に出力する（Ｓ１０３〜Ｓ１０４、ＯＵＴ＃３２）。
【００４０】
メイン処理部２１は、Ｓ１０１で受信した「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータから、外線を意図した発信であるか、否かを特定する（Ｓ１０５）。Ｓ１０５において、メイン処理部２１は、例えば、外線特番「０」がＵＲＩの冠頭プレフィックスに設定されている場合に、外線発信であることを特定する。
【００４１】
外線発信であることを特定した場合（Ｓ１０５で「Ｙｅｓ」の場合）、メイン処理部２１は、受信した「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータを、公衆網で流通する形式に加工する（Ｓ１０６）。例えば、外線特番「０」を削除することと、ＵＲＩのドメイン部を公衆網のドメインに置換する加工を行う。続けて、外線発信であることを特定した場合、メイン処理部２１は、受信した「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータから「発加入者のドメイン種別」を取得する（Ｓ１０７）。メイン処理部２１は、その「発加入者のドメイン種別」およびＳ１０４（ＯＵＴ＃３２）で取得した「発加入者のグループＩＤ」を番号変換管理ＤＢ部２３に入力する（Ｓ１０７、ＩＮ＃３３）。
【００４２】
なお、Ｓ１０７では、メイン処理部２１が、発加入者のドメイン種別を、「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータとは別のパラメータから取得する場合もある。例えば、ＩＥＴＦ  ＲＦＣ７３１６（２０１４−０７）で規定される「Ｐ−Ｐｒｉｖａｔｅ−Ｎｅｔｗｏｒｋ−Ｉｎｄｉｃａｔｉｏｎ」パラメータがＩＮＶＩＴＥリクエストに設定されていた場合、このパラメータからドメイン種別を取得することもできる。
【００４３】
続けて、番号変換管理ＤＢ部２３は、メイン処理部２１から入力された「発加入者のドメイン種別」と「発加入者のグループＩＤ」を検索用キー情報として該当する「変換後のＵＲＩ情報」を特定し、得られた該当する「変換後のＵＲＩ情報」をメイン処理部２１に出力する（Ｓ１０８〜Ｓ１０９、ＯＵＴ＃３４）。
【００４４】
続けて、外線発信であることを特定した場合（Ｓ１０５で「Ｙｅｓ」の場合）、メイン処理部２１は、Ｓ１０９（ＯＵＴ＃３４）で取得した「変換後のＵＲＩ情報」を含むように、番号変換後ＩＮＶＩＴＥリクエスト信号４０に「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータを設定する（Ｓ１１０）。なお、最終的に、この上書きによって変更された設定値が、代表番号として発信先に通知される発電話番号である。
【００４５】
次に、メイン処理部２１は、Ｓ１０１で受信した番号変換前ＩＮＶＩＴＥリクエスト３０又はＳ１１０で加工された番号変換後ＩＮＶＩＴＥリクエスト信号４０に設定された「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータから発信先が緊急特番であるか、否かを特定する（Ｓ１１１）。メイン処理部２１は、例えば、外線特番「０」を除去した後のＵＲＩが緊急特番「１１０」だった場合に、発信先が緊急特番であることを特定する。
【００４６】
発信先が緊急特番であることを特定した場合（Ｓ１１１で「Ｙｅｓ」の場合）、メイン処理部２１は、Ｓ１１１で特定した「Ｒｅｑｕｅｓｔ−ＵＲＩの特番種別」およびＳ１０４（ＯＵＴ＃３２）で取得した「発加入者の位置ＩＤ」を番号変換管理ＤＢ部２３に入力する（Ｓ１１２、ＩＮ＃３５）。
【００４７】
番号変換管理ＤＢ部２３は、メイン処理部２１から入力された「Ｒｅｑｕｅｓｔ−ＵＲＩの特番種別」と「発加入者の位置ＩＤ」を検索用キー情報として該当する「変換後のＵＲＩ情報」を特定し、得られた該当する「変換後のＵＲＩ情報」をメイン処理部２１に出力する（Ｓ１１３〜Ｓ１１４、ＯＵＴ＃３６）。
【００４８】
続けて、発信先が緊急特番であることを特定した場合（Ｓ１１１で「Ｙｅｓ」の場合）、メイン処理部２１は、Ｓ１１４（ＯＵＴ＃３６）で取得した「変換後のＵＲＩ情報」を含むように、番号変換前ＩＮＶＩＴＥリクエスト３０又は番号変換後ＩＮＶＩＴＥリクエスト信号４０に「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータを設定する（Ｓ１１５）。
【００４９】
呼処理サーバ装置２０は、メイン処理部２１、加入者管理ＤＢ部２１、番号変換管理ＤＢ部２３による、上記の処理を行った後、次の処理を行う。すなわち、呼処理サーバ装置２０は、上記の処理後、番号変換後ＩＮＶＩＴＥリクエスト信号４０を送信（あるいは番号変換前ＩＮＶＩＴＥリクエスト３０に対して変換処理を行わずに番号変換後ＩＮＶＩＴＥリクエスト信号４０として送信）する（Ｓ１１６）。
【００５０】
Ｓ１１６で送信された番号変換後ＩＮＶＩＴＥリクエスト信号４０は、着側の呼処理ネットワーク１２に配置された呼処理サーバ（図示なし）を経由し、最終的に電話機１３に到達する。電話機１３は、受信した「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータを参照して、発電話番号表示を行う。
【００５１】
次に、図５を参照して、図２Ａ及び図２Ｂに示した処理における入出力パラメータの具体例について説明する。なお、加入者管理ＤＢ部２２は図３に示したデータを記憶しているものとする。また、番号変換管理ＤＢ部２３は図４に示したデータを記憶しているものとする。なお、図５は、図２Ａ及び図２Ｂに示した処理における通信信号について、通信名と、パラメータ名と、設定値と、備考又は補足説明とを一覧にして示した図である。
【００５２】
まず、内線電話機１０は、外線発信を意図して、番号変換前ＩＮＶＩＴＥリクエスト３０を送信する（Ｓ１０１）。この例では、図５に示したように、番号変換前ＩＮＶＩＴＥリクエスト３０には、発信先を示す「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータ『ｓｉｐ：０−１１０＠ｃｏｍｐａｎｙ１．ｃｏｍ』と、発信元を示す「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータ『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ１．ｃｏｍ』とが設定される。
【００５３】
呼処理サーバ装置２０は、番号変換前ＩＮＶＩＴＥリクエスト３０を受信し（Ｓ１０１）、メイン処理部２１、加入者管理ＤＢ部２１、番号変換管理ＤＢ部２３により、以下の処理を行う。
【００５４】
メイン処理部２１は、受信した「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータ『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ１．ｃｏｍ』から、「発加入者のＵＲＩ情報」『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ１．ｃｏｍ』を取得し、その「発加入者のＵＲＩ情報」『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ１．ｃｏｍ』を加入者管理ＤＢ部２２に入力する（Ｓ１０２、ＩＮ＃３１）。
【００５５】
加入者管理ＤＢ部２２は、メイン処理部２１から入力された「発加入者のＵＲＩ情報」『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ１．ｃｏｍ』とを検索用キー情報として、該当する「発加入者の位置・グループＩＤ」『３００１；３９０１』を特定してメイン処理部２１に出力する（Ｓ１０３〜Ｓ１０４、ＯＵＴ＃３２、図３）。
【００５６】
メイン処理部２１は、受信した「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータ『ｓｉｐ：０−１１０＠ｃｏｍｐａｎｙ１．ｃｏｍ』から、外線を意図した発信であるか、否かを特定する（Ｓ１０５）。本例では、外線特番「０」がＵＲＩの冠頭プレフィックスに設定されており、メイン処理部２１は、外線発信であると特定する（Ｓ１０５で「Ｙｅｓ」）。
【００５７】
外線発信であることを特定した場合、メイン処理部２１は、受信した「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータ『ｓｉｐ：０−１１０＠ｃｏｍｐａｎｙ１．ｃｏｍ』を、公衆網で流通する形式に加工する（Ｓ１０６）。本例では、外線特番「０」を削除することと、ＵＲＩのドメイン部『ｃｏｍｐａｎｙ１．ｃｏｍ』を公衆網のドメイン『ｐｕｂｌｉｃ．ｃｏｍ』に置換する加工を行う。加工後の「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータは『ｓｉｐ：１１０＠ｐｕｂｌｉｃ．ｃｏｍ』となる。
【００５８】
続けて、外線発信であることを特定した場合、メイン処理部２１は、受信した「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータ『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ１．ｃｏｍ』から「発加入者のドメイン種別」『ｃｏｍｐａｎｙ１．ｃｏｍ』を取得する（Ｓ１０７）。メイン処理部２１は、その「発加入者のドメイン種別」『ｃｏｍｐａｎｙ１．ｃｏｍ』およびＳ１０４（ＯＵＴ＃３２）で取得した「発加入者のグループＩＤ」『３９０１』を番号変換管理ＤＢ部２３に入力する（Ｓ１０７、ＩＮ＃３３）。
【００５９】
続けて、番号変換管理ＤＢ部２３は、メイン処理部２１から入力された「発加入者のドメイン種別」『ｃｏｍｐａｎｙ１．ｃｏｍ』と「発加入者のグループＩＤ」『３９０１』とを検索用キー情報として、該当する「変換後のＵＲＩ情報」『ｓｉｐ：０３−９０００−０００１＠ｐｕｂｌｉｃ．ｃｏｍ』を特定してメイン処理部２１に出力する（Ｓ１０８〜Ｓ１０９、ＯＵＴ＃３４）。
【００６０】
続けて、外線発信であることを特定した場合、メイン処理部２１は、Ｓ１０９（ＯＵＴ＃３４）で取得した「変換後のＵＲＩ情報」『ｓｉｐ：０３−９０００−０００１＠ｐｕｂｌｉｃ．ｃｏｍ』を含むように、番号変換後ＩＮＶＩＴＥリクエスト信号４０に「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータ『ｓｉｐ：０３−９０００−０００１＠ｐｕｂｌｉｃ．ｃｏｍ』を設定する（Ｓ１１０）。なお、最終的に、この設定値が、代表番号として通知される発電話番号である。
【００６１】
次に、メイン処理部２１は、加工後の「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータ『ｓｉｐ：１１０＠ｐｕｂｌｉｃ．ｃｏｍ』から、発信先が緊急特番であるか、否かを特定する（Ｓ１１１）。本例では、外線特番「０」を除去した後のＵＲＩの電話番号が緊急特番「１１０」であるため、発信先が緊急特番であると特定する（Ｓ１１１で「Ｙｅｓ」）。なお、１１０等、緊急特番とみなす電話番号は、所定の記憶装置にあらかじめ登録しておく。
【００６２】
発信先が緊急特番であることを特定した場合、メイン処理部２１は、特定した「Ｒｅｑｕｅｓｔ−ＵＲＩの特番種別」『１１０』およびＳ１０４（ＯＵＴ＃３２）で取得した「発加入者の位置ＩＤ」『３００１』を番号変換管理ＤＢ部２３に入力する（Ｓ１１２、ＩＮ＃３５）。
【００６３】
番号変換管理ＤＢ部２３は、メイン処理部２１から入力された「Ｒｅｑｕｅｓｔ−ＵＲＩの特番種別」『１１０』と「発加入者の位置ＩＤ」『３００１』とを検索用キー情報として、該当する「変換後のＵＲＩ情報」『ｓｉｐ：０３−００００−０００１＠ｐｕｂｌｉｃ．ｃｏｍ』を特定してメイン処理部２１に出力する（Ｓ１１３〜Ｓ１１４、ＯＵＴ＃３６）。
【００６４】
続けて、発信先が緊急特番であることを特定した場合、メイン処理部２１は、Ｓ１１４（ＯＵＴ＃３６）で取得した「変換後のＵＲＩ情報」『ｓｉｐ：０３−００００−０００１＠ｐｕｂｌｉｃ．ｃｏｍ』を含むように、番号変換後ＩＮＶＩＴＥリクエスト信号４０に「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータ『ｓｉｐ：０３−００００−０００１＠ｐｕｂｌｉｃ．ｃｏｍ』を設定する（Ｓ１１５）。
【００６５】
呼処理サーバ装置２０は、メイン処理部２１、加入者管理ＤＢ部２１、番号変換管理ＤＢ部２３による、上記の処理を行った後、番号変換後ＩＮＶＩＴＥリクエスト信号４０を送信する（Ｓ１１６）。
【００６６】
送信された番号変換後ＩＮＶＩＴＥリクエスト信号４０は、着側の呼処理ネットワーク１２に配置された呼処理サーバ（図示なし）を経由し、最終的に電話機１３『ｓｉｐ：０３−００００−０００１＠ｐｕｂｌｉｃ．ｃｏｍ』に到達する。そして、電話機１３『ｓｉｐ：０３−００００−０００１＠ｐｕｂｌｉｃ．ｃｏｍ』は、受信した「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータ『ｓｉｐ：０３−９０００−０００１＠ｐｕｂｌｉｃ．ｃｏｍ』を参照して、発電話番号表示『０３−９０００−０００１』を行う。
【００６７】
次に、図６を参照して、図２Ａ及び図２Ｂに示した処理における入出力パラメータの他の具体例について説明する。なお、加入者管理ＤＢ部２２は図３に示したデータを記憶しているものとする。また、番号変換管理ＤＢ部２３は図４に示したデータを記憶しているものとする。なお、図６は、図５と同様、図２Ａ及び図２Ｂに示した処理における通信信号について、通信名と、パラメータ名と、設定値と、備考又は補足説明とを一覧にして示した図である。
【００６８】
まず、内線電話機１０は、外線発信を意図して、番号変換前ＩＮＶＩＴＥリクエスト３０を送信する（Ｓ１０１）。図６に示したように、番号変換前ＩＮＶＩＴＥリクエスト３０には、発信先を示す「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータ『ｓｉｐ：０−０９−９９９９−９９９９＠ｃｃｏｍｐａｎｙ２．ｃｏｍ』と、発信元を示す「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータ『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ２．ｃｏｍ』とが設定される。
【００６９】
呼処理サーバ装置２０は、番号変換前ＩＮＶＩＴＥリクエスト３０を受信し（Ｓ１０１）、メイン処理部２１、加入者管理ＤＢ部２１、番号変換管理ＤＢ部２３により、以下の処理を行う。
【００７０】
メイン処理部２１は、受信した「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータ『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ２．ｃｏｍ』から、「発加入者のＵＲＩ情報」『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ２．ｃｏｍ』を取得し、その「発加入者のＵＲＩ情報」『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ２．ｃｏｍ』を加入者管理ＤＢ部２２に入力する（Ｓ１０２、ＩＮ＃３１）。
【００７１】
加入者管理ＤＢ部２２は、メイン処理部２１から入力された「発加入者のＵＲＩ情報」『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ２．ｃｏｍ』を検索用キー情報として、該当する「発加入者の位置・グループＩＤ」『３００１；３９０１』を特定してメイン処理部２１に出力する（Ｓ１０３〜Ｓ１０４、：ＯＵＴ＃３２）。
【００７２】
メイン処理部２１は、受信した「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータ『ｓｉｐ：０−０９−９９９９−９９９９＠ｃｏｍｐａｎｙ２．ｃｏｍ』から、外線を意図した発信であるか、否かを特定する（Ｓ１０５）。本例では、外線特番「０」がＵＲＩの冠頭プレフィックスに設定されており、外線発信であると特定する（Ｓ１０５で「Ｙｅｓ」）。
【００７３】
外線発信であることを特定した場合、メイン処理部２１は、受信した「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータ『ｓｉｐ：０−０９−９９９９−９９９９＠ｃｏｍｐａｎｙ２．ｃｏｍ』を、公衆網で流通する形式に加工する（Ｓ１０６）。本例では、外線特番「０」を削除することと、ＵＲＩのドメイン部『ｃｏｍｐａｎｙ２．ｃｏｍ』を公衆網のドメイン『ｐｕｂｌｉｃ．ｃｏｍ』に置換する加工を行う。加工後の「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータは『ｓｉｐ：０９−９９９９−９９９９＠ｐｕｂｌｉｃ．ｃｏｍ』となる。
【００７４】
続けて、外線発信であることを特定した場合、メイン処理部２１は、受信した「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータ『ｓｉｐ：５１−１００１＠ｃｏｍｐａｎｙ２．ｃｏｍ』から「発加入者のドメイン種別」『ｃｏｍｐａｎｙ２．ｃｏｍ』を取得する。メイン処理部２１は、その「発加入者のドメイン種別」『ｃｏｍｐａｎｙ２．ｃｏｍ』およびＳ１０４（ＯＵＴ＃３２）で取得した「発加入者のグループＩＤ」『３９０１』を番号変換管理ＤＢ部２３に入力する（Ｓ１０７、ＩＮ＃３３）。
【００７５】
続けて、番号変換管理ＤＢ部２３は、メイン処理部２１から入力された「発加入者のドメイン種別」『ｃｏｍｐａｎｙ２．ｃｏｍ』と「発加入者のグループＩＤ」『３９０１』とを検索用キー情報として、該当する「変換後のＵＲＩ情報」『ｓｉｐ：０３−９００１−１１１１＠ｐｕｂｌｉｃ．ｃｏｍ』を特定してメイン処理部２１に出力するＳ１０８〜Ｓ１０９、ＯＵＴ＃３４）。
【００７６】
続けて、外線発信であることを特定した場合、メイン処理部２１は、Ｓ１０９（ＯＵＴ＃３４）で取得した「変換後のＵＲＩ情報」『ｓｉｐ：０３−９００１−１１１１＠ｐｕｂｌｉｃ．ｃｏｍ』を含むように、番号変換後ＩＮＶＩＴＥリクエスト信号４０に「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータ『ｓｉｐ：０３−９００１−１１１１＠ｐｕｂｌｉｃ．ｃｏｍ』を設定する（Ｓ１１０）。なお、最終的に、この設定値が、代表番号として通知される発電話番号である。
【００７７】
次に、メイン処理部２１は、加工後の「Ｒｅｑｕｅｓｔ−ＵＲＩ」パラメータ『ｓｉｐ：０９−９９９９−９９９９＠ｐｕｂｌｉｃ．ｃｏｍ』から、発信先が緊急特番であるか、否かを特定する。本例では、外線特番「０」を除去した後のＵＲＩの電話番号『０９−９９９９−９９９９』が緊急特番ではないため、発信先が緊急特番ではないと特定する（Ｓ１１１で「Ｎｏ」）。なお、１１０等、緊急特番とみなす電話番号は、所定の記憶装置にあらかじめ登録しておく。
【００７８】
呼処理サーバ装置２０は、メイン処理部２１、加入者管理ＤＢ部２１、番号変換管理ＤＢ部２３による、上記の処理を行った後、番号変換後ＩＮＶＩＴＥリクエスト信号４０を送信する（Ｓ１１６）。
【００７９】
送信された番号変換後ＩＮＶＩＴＥリクエスト信号４０は、着側の呼処理ネットワーク１２に配置された呼処理サーバ（図示なし）を経由し、最終的に電話機１３『ｓｉｐ：０９−９９９９−９９９９＠ｐｕｂｌｉｃ．ｃｏｍ』に到達する。そして、電話機１３『ｓｉｐ：０９−９９９９−９９９９＠ｐｕｂｌｉｃ．ｃｏｍ』は、受信した「Ｐ−Ａｓｓｅｒｔｅｄ−Ｉｄｅｎｔｉｔｙ」パラメータ『ｓｉｐ：０３−９００１−１１１１＠ｐｕｂｌｉｃ．ｃｏｍ』を参照して、発電話番号表示『０３−９００１−１１１１』を行う。
【００８０】
以上のように、本実施形態の呼処理サーバ装置２０は、「着電話番号変換」の機能と「発電話番号変換」の機能とでデータベースを共通化する。すなわち、本実施形態の呼処理サーバ装置２０は、「着電話番号変換」の機能と「発電話番号変換」の機能とを、同一のＤＢを参照して実施することができる。これにより、例えば代表番号通知サービスのＤＢのリソースを専用に用意することを不要とし、効率的な代表番号通知サービスを提供することができる。なお、「着電話番号変換」は、緊急特番を、端末の位置に応じた電話番号に変換する機能である。また、「発電話番号変換」は、内線番号を、外線の代表番号に変換する機能である。また、「代表番号通知サービス」とは次のサービスである。すなわち、内線電話機から外線発信するＩＰ電話サービスにおいて、内線電話機から外線発信する場合に、複数の内線電話機をグループ化し、同一グループの内線電話機のいずれから発信しても、共通の外線電話番号を発電話番号として着信側の電話機に通知するサービスである。
【００８１】
次に、図７及び図８を参照して、本発明に係る実施形態の基本構成について説明する。図７は、呼制御装置の基本構成を示す概略ブロック図である。上述した実施形態では、呼制御装置の一実施形態として、図１に示す構成について説明したが、呼制御装置の基本構成は、図７に示すとおりである。すなわち、呼制御装置１は、記憶部２、属性特定部３、発信元書換部４及び発信先書換部５を基本構成とする。
【００８２】
記憶部２は、変換前の電話機の識別情報に含まれる電話機情報２−１と、電話機の属性を示す属性値２−２と、変換後の識別情報２−３とを関連付けて記憶する。属性値特定部３は、呼制御信号の発信元の識別情報に基づいて、当該発信元の属性値を特定する。発信元書換部４は、呼制御信号の発信元の識別情報を、当該識別情報と属性値特定部３が特定した属性値２−２とに関連付けられた変換後の識別情報２−３に書き換える。発信先書換部５は、呼制御信号の発信先の識別情報を、当該識別情報と属性値特定部３が特定した属性値２−２とに関連付けられた変換後の識別情報２−３に書き換える。これにより、発信元番号の変換と発信先番号の変換の両方を実現しつつ、管理すべきデータベースの数を少なくすることができる。
【００８３】
図８は、記憶装置の基本構成を示す概略ブロック図である。上述した実施形態では、記憶装置の一実施形態として、図１、図３及び図４に示す構成について説明したが、記憶装置の基本構成は、図８に示すとおりである。すなわち、記憶装置８は、変換前の電話機の識別情報に含まれる電話機情報と、電話機の属性を示す属性値と、変換後の識別情報とを関連付けて格納する。また、記憶装置８は、発信元変換用レコード７と発信先変換用レコード８とを格納する。発信元変換用レコード７は、変換前の発信元の識別情報に含まれる電話機情報と、発信元の電話機の属性値と、発信元の変換後の識別情報とを関連付けて格納する。発信先変換用レコード８は、変換前の発信先の識別情報に含まれる電話機情報と、発信元の電話機の属性値と、発信先の変換後の識別情報とが関連付けて格納する。これにより、発信元番号の変換と発信先番号の変換の両方を実現しつつ、管理すべきデータベースの数を少なくすることができる。
【００８４】
なお、本発明の実施の形態は上記のものに限定されない。例えば図１に示した各構成要素を、適宜、統合したり、分割したりすることができる。また、各構成要素が有するプロセッサが実行するプログラムは、一部又は全部をコンピュータ読取可能な記録媒体や通信回線を介して頒布することができる。
【００８５】
なお、図７及び図８に示した本発明の実施形態に係る基本構成と、図１、図２Ａ、図２Ｂ、図３及び図４に示した上記実施形態の構成との対応関係は次の通りである。すなわち、図１の呼処理サーバ装置２０が、図７の呼制御装置１の一例である。図１の番号変換管理ＤＢ部２３が、図７の記憶部２の一例である。図３の「加入者のＵＲＩ情報」に含まれる「５１−１００１」等の発電話番号と「ｃｏｍｐａｎｙ１．ｃｏｍ」等のドメインとが、図７の電話機情報２−１の一例である。図３の「加入者の位置・グループＩＤ」が、図７の属性値２−２の一例である。図４の「変換後のＵＲＩ情報」が、図７の変換後の識別情報２−３の一例である。図１の番号変換前ＩＮＶＩＴＥリクエスト信号３０が、図７の呼制御信号の一例である。図２Ａのメイン処理部２１及び加入者管理ＤＢ部２２によるＳ１０２〜Ｓ１０４の処理が、図７の属性値特定部３の一例である。図２Ａのメイン処理部２１及び番号変換管理ＤＢ部２３によるＳ１０７〜Ｓ１１０の処理が、図７の発信元書換部４の一例である。図２Ｂのメイン処理部２１及び番号変換管理ＤＢ部２３によるＳ１１１〜Ｓ１１５の処理が、図７の発信先書換部５の一例である。図１の番号変換管理ＤＢ部２３が、図８の記憶装置６の一例である。図４のレコード２３１ａが、図８の発信先変換用レコード８の一例である。そして、図４のレコード２３１ｂが、図８の発信元変換用レコード７の一例である。また、図１の加入者管理ＤＢ部２２が、本発明の第２記憶部の一例である。また、図３の「加入者のＵＲＩ情報」が、本発明の変換前の電話機の識別情報の一例である。
【符号の説明】
【００８６】
１  呼制御装置
２  記憶部
２−１  電話機情報
２−２  属性値
２−３  変換後の識別情報
３  属性値特定部
４  発信元書換部
５  発信先書換部
６  記憶装置
７  発信元変換用レコード
８  発信先変換用レコード
１１  発側の呼処理ネットワーク
１２  着側の呼処理ネットワーク
２０  呼処理サーバ装置
２１  メイン処理部
２２  加入者管理ＤＢ部
２３  番号変換管理ＤＢ部
【図１】
0006565240.tif 000002
【図２Ａ】
0006565240.tif 000003
【図２Ｂ】
0006565240.tif 000004
【図３】
0006565240.tif 000005
【図４】
0006565240.tif 000006
【図５】
0006565240.tif 000007
【図６】
0006565240.tif 000008
【図７】
0006565240.tif 000009
【図８】
0006565240.tif 000010