(57)【要約】 【目的】  簡単な構成によりＩＰ電話端末に関する十分な保守サービス機能を一般加入者に提供できることを、課題とする。【構成】  ＩＰ電話端末が自ドメイン内のＳＩＰプロシキサーバを介して呼を接続するＩＰ電話網における通信サービス方式であって、自局に収容するＩＰ電話端末の加入者状態の情報をシステム運用に伴う呼制御の下で更新・管理するＳＩＰプロキシサーバと、加入者からのＩＰ電話端末を特定した加入者状態の問い合わせに従い、該ＩＰ電話端末を収容しているＳＩＰプロキシサーバから当該ＩＰ電話端末の加入者状態の情報を取得し、前記加入者に通知するアプリケーションサーバとを備える。【選択図】  図１
2006165919.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰ電話端末が自ドメイン内のＳＩＰプロシキサーバを介して呼を接続するＩＰ電話網における通信サービス方式であって、
自局に収容するＩＰ電話端末の加入者状態の情報をシステム運用に伴う呼制御の下で更新・管理するＳＩＰプロキシサーバと、
加入者からのＩＰ電話端末を特定した加入者状態の問い合わせに従い、該ＩＰ電話端末を収容しているＳＩＰプロキシサーバから当該ＩＰ電話端末の加入者状態の情報を取得し、前記加入者に通知するアプリケーションサーバとを備えることを特徴とするＩＰ電話網における通信サービス方式。
【請求項２】
アプリケーションサーバからのＩＰ電話端末を特定した収容位置の問い合わせに従い、該ＩＰ電話端末を収容するＳＩＰプロキシサーバのアドレス情報を返送するロケーションサーバを備えることを特徴とする請求項１記載の通信サービス方式。
【請求項３】
加入者状態は、ＩＰ電話端末の空き状態、使用中、ロックアウト状態、故障中及び電源ＯＦＦ状態の内の何れか１又は２以上の状態からなることを特徴とする請求項１又は２記載のＩＰ電話網における通信サービス方式。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＩＰ電話網における通信サービス方式に関し、更に詳しくは、ＩＰ電話端末が自ドメイン内のＳＩＰプロシキサーバを介して呼を接続するＩＰ電話網における通信サービス方式に関する。
【０００２】
近年ＩＰ電話サービスの急速な普及に伴い、加入者向け保守サービス機能の拡充が必要不可欠となっている。
【背景技術】
【０００３】
現状のＩＰ電話網では、相手と接続して通話する以外の仕組がほとんど組み込まれていないため、従来の固定電話サービスで提供しているような１１３番(電話故障調べ)や１１４番(話中調べ)等の保守サービス機能は実現されていない。同等のサービスを受ける場合ためには、別途にサービスオペレータや保守部門の介在が必要である。
【０００４】
係る状況の下、従来は、ある電話機１６に着信がある時を利用して、その電話機１６（即ち、加入者変換装置１７）から着呼指示応答信号が返送されるようにしておき、もし着呼指示応答信号が返送されない場合は、該電話機１６に対する異常診断を行う通信システムが知られている（特許文献１）。従って、診断信号以外は通信に通常使用される信号なのでネットワークの負担を軽減できる。
【特許文献１】特開２００２−３３５３２７（要約、図）
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、上記従来方法では電話機１６（加入者変換装置１７）の故障有無を調べることしかできす、一般加入者向けに十分な加入者状態の情報を提供することはできない。
【０００６】
本発明は上記従来技術の問題点に鑑みなされたものであり、その目的とする所は、簡単な構成によりＩＰ電話端末の加入者状態を容易に提供可能なＩＰ電話網における通信サービス方式を提供することにある。
【課題を解決するための手段】
【０００７】
上記の課題は例えば図１の構成により解決される。即ち、本発明（１）の通信サービス方式は、ＩＰ電話端末が自ドメイン内のＳＩＰプロシキサーバを介して呼を接続するＩＰ電話網における通信サービス方式であって、自局に収容するＩＰ電話端末の加入者状態の情報をシステム運用に伴う呼制御の下で更新・管理するＳＩＰプロキシサーバと、
加入者からのＩＰ電話端末を特定した加入者状態の問い合わせに従い、該ＩＰ電話端末を収容しているＳＩＰプロキシサーバから当該ＩＰ電話端末の加入者状態の情報を取得し、前記加入者に通知するアプリケーションサーバとを備えるものである。
【０００８】
本発明（１）では、ＳＩＰプロキシサーバでＩＰ電話端末の加入者状態の情報をシステム運用に伴う呼制御の下で更新・管理すると共に、これをアプリケーションサーバからの要求に従って提供するため、ＩＰ電話端末に別段の保守機能を付加しなくても、加入者に対するＩＰ電話端末の保守サービス機能を効率良く実現できる。
【０００９】
本発明（２）では、上記本発明（１）において、アプリケーションサーバからのＩＰ電話端末を特定した収容位置の問い合わせに従い、該ＩＰ電話端末を収容するＳＩＰプロキ
シサーバのアドレス情報を返送するロケーションサーバを更に備えるものである。
【００１０】
本発明（３）では、上記本発明（１）又は（２）において、加入者状態は、ＩＰ電話端末の空き状態、使用中、ロックアウト状態、故障中及び電源ＯＦＦ状態の内の何れか１又は２以上の状態からなるものである。従って、簡単な構成により一般加入者に十分な保守サービス機能を提供できる。
【発明の効果】
【００１１】
以上述べた如く本発明によれば、ＩＰ電話端末に別段の保守サービス機能を付加しなくても、既存の機能を最大限活用した簡単な構成により一般加入者に十分な保守サービス機能を提供でき、よってＩＰ電話網の普及・拡大に寄与するところが極めて大きい。
【発明を実施するための最良の形態】
【００１２】
以下、添付図面に従って本発明に好適なる実施の形態を詳細に説明する。なお、全図を通して同一符号は同一又は相当部分を示すものとする。図１は実施の形態による通信システムの構成を示す図であり、図において、５０Ａ，５０ＢはＩＰ電話端末（ハードフォン等）、４０Ａ，４０ＢはＩＰ電話端末５０Ａ，５０Ｂをそれぞれ収容すると共に、自局に収容するＩＰ電話端末の加入者状態の情報をシステム運用に伴う呼制御の下で更新・管理するＳＩＰ(Session Initiation Protocol)プロキシサーバ、１００はＩＰパケット等を伝送するネットワーク、１０はＩＰ電話端末の加入者状態問い合わせサービスを実現するアプリケーションサーバ、１１はシステムデータとしてロケーションサーバ３０のアドレス情報を保持しているデータベース（ＤＢ）、１２は外部からの問い合わせに応じて問い合わせ対象ＩＰ電話端末の加入者状態（ＩＤＬＥ、ＢＵＳＹ，ＬＯＣＫＯＵＴ，ＦＡＵＬＴ，ＰＯＷＥＲＯＦＦ等）の問い合わせ処理を行い、応答する加入者状態問い合わせ部、１３は、ＵＡ(user agent)機能を有し、ＳＩＰの下で問い合わせ加入者(又は保守者)と音声応答部１４との間でＲＴＰ(Real-time Transport Protocol)セッションを確立する呼制御部、１４は呼制御部１３により確立されたＲＴＰセッションを使用し、問い合わせ加入者に対して音声ガイダンスを送出し、また該加入者からのＰＢ音信号を分析する音声応答部、１５はＴＣＰやＵＤＰに従う通信制御部、２０は保守者が操作をする保守コンソール、３０はＩＰ電話端末が収容されているＳＩＰプロキシサーバのアドレス情報を保持しているロケーションサーバである。
【００１３】
次に、このような構成による加入者状態問い合わせ処理の概要を説明する。図２は実施の形態による加入者状態問い合わせ処理のシーケンズ図で、加入者Ａが加入者端末Ｂの加入者状態を問い合わせる場合を示している。加入者Ａが、例えば状態問い合わせ特番（１１４）をダイヤルすると、加入者端末５０Ａは自ドメイン内のＳＩＰプロキシサーバ４０Ａに「ＩＮＶＩＴＥ」リクエストを発行し、アプリケーションサーバ１０との間のセッション確立を促す。
【００１４】
ＳＩＰプロキシサーバ４０Ａは、加入者Ａからの「ＩＮＶＩＴＥ」リクエストを受けたことにより、リクエスト転送中を表すステータス１００（Trying）を返送すると共に、アプリケーションサーバ１０に「ＩＮＶＩＴＥ」リクエストを中継する。
【００１５】
アプリケーションサーバ１０の呼制御部１３は、ＳＩＰプロキシサーバ４０Ａからの「ＩＮＶＩＴＥ」リクエストを受けたことにより、呼び出し中を表すステータス１８０（Ringing）を返送する。更に、音声応答部１４のリソースを生成すると共に、ＳＩＰプロキシサーバにステータス２００（ＯＫ）を返送し、こうして加入者Ａと音声応答部１４との間で音声通話路ＲＴＰセッションが確立される。
【００１６】
加入者Ａは、音声応答部１４からのガイダンス指示に従い、問い合わせ対象である加入
者Ｂの電話番号をＰＢ（プッシュボタン）音信号により入力する。音声応答部１４は、ＰＢ音信号を解析して加入者Ｂの電話(Ｅ１６４)番号に変換すると共に、該電話番号をパラメータとして加入者状態問い合わせ部１２に加入者Ｂの状態を問い合わせ要求を行う。
【００１７】
この要求を受けた加入者状態問い合わせ部１２は、「ＨＴＴＰ」リクエストのパラメータに加入者Ｂの電話番号を搭載し、これをシステムデータ１１に登録されているロケーションサーバ３０に送信する。これを受けたロケーションサーバ３０は、加入者Ｂの電話番号で加入者端末５０Ｂの収容ＳＩＰプロキシサーバ４０Ｂのアドレス情報を抽出し、これを加入者状態問い合わせ部１２に返送する。これを受けた加入者状態問い合わせ部１２は、「ＨＴＴＰ」リクエストのパラメータに加入者Ｂの電話番号を搭載し、加入者状態の情報を要求する。
【００１８】
これを受けたＳＩＰプロキシサーバ４０Ｂは、リクエストパラメータ上の電話番号をキー情報として、加入者端末４０Ｂについての自局で更新・管理している状態情報を収集し、加入者状態問い合わせ部１２に返送する。加入者状態問い合わせ部１２は、受信した加入者状態情報に基づき該当するガイダンス番号を抽出し、音声応答部１４に問い合わせ結果の通知を要求をする。音声応答部は、状態マトリックスよりガイダンス番号に合致したガイダンストーキを抽出して加入者Ａに送信する。 
【００１９】
図３は音声ガイダンス生成処理のイメージ図で、図３（Ａ）は加入者状態に対応付けたガイダンス番号のマトリックスを示している。加入者端末が本システムに登録されており、且つ、空き「ＩＤＬＥ」状態の時はガイダンス番号１が抽出され、また使用中「ＢＵＳＹ」状態の場合はガイダンス番号２が抽出される。他の状態についても同様である。
【００２０】
図３（Ｂ）にガイダンス番号に対応する音声ガイダンスの内容を示す。ガイダンス番号１は「空き」状態の音声ガイダンスに対応し、ガイダンス番号２は「使用中」状態の音声ガイダンスに対応する。またガイダンス番号３は「電源ＯＦＦ」状態の音声ガイダンスに対応し、ガイダンス番号４は「故障中」状態の音声ガイダンスに対応する。
【００２１】
図４は実施の形態による問い合わせ対象加入者収容サーバ抽出処理を具体的に説明する図である。ロケーションサーバ３０は加入者を収容しているＳＩＰプロキシサーバの位置情報を登録・管理する。図４の挿入図（ａ）にロケーションサーバ３０で管理するデータ構成を示す。例えば、加入者の「電話番号」、「ＳＩＰ−ＵＲＬ」、「位置情報」、収容ＳＩＰプロキシサーバの「ＩＰアドレス」、収容ＳＩＰプロキシサーバの「完全修飾ドメイン名 （ＦＱＤＮ：Fully Qualified Domain Name)」が記録されている。加入者収容サーバの検索キーとしては加入者の「電話番号」又は「ＳＩＰ−ＵＲＬ」を使用できる。
【００２２】
図４において、加入者状態問い合わせ部１２は、加入者Ａからの入力ＰＢ信号を変換した加入者Ｂの電話番号（又はＳＩＰ−ＵＲＬ）と、システムデータ１１より読み出したロケーションサーバ３０のアドレス情報とを使用して加入者収容ＳＩＰプロキシサーバ問い合わせのＨＴＴＰリクエストパケットを生成し、ロケーションサーバ３０に送信する。
【００２３】
ロケーションサーバ３０は、加入者Ｂの電話番号（又はＳＩＰ−ＵＲＬ）をキー情報にして、ＤＢから加入者Ｂが収容されているＳＩＰプロキシサーバ４０ＢのＩＰアドレス及びＦＱＤＮを取得し、アプリケーションサーバ１０に返送する。
【００２４】
図５は実施の形態による加入者収容ＳＩＰサーバが管理する加入者情報の収集処理を説明する図である。加入者状態問い合わせ部１２は、加入者Ｂの電話番号（又はＳＩＰ−ＵＲＬ）と、ロケーションサーバ３０より取得したＳＩＰプロキシサーバ４０Ｂのアドレス情報とを使用して加入者情報問い合わせのＨＴＴＰリクエストパケットを生成し、ＳＩＰ
プロキシサーバ４０Ｂに送信する。ＳＩＰプロキシサーバ４０Ｂは、加入者Ｂの電話番号（又はＳＩＰ−ＵＲＬ）をキー情報にして、ＤＢから加入者端末４０Ｂについての状態情報を取得し、アプリケーションサーバ１０に返送する。
【００２５】
図５（Ｂ）はＳＩＰプロキシサーバにおける加入者状態のデータ構成を示す。各加入者の電話番号の対応に加入者端末の状態情報と登録状態が記録されている。検索キーは電話番号である。図５（Ｃ）に加入者状態の定義を示す。加入者状態には使用中「ＢＵＳＹ」、ロックアウト「ＬＯＣＫＯＵＴ」、故障中「ＦＡＵＬＴ」及び電源ＯＦＦ「ＰＯＷＥＲＯＦＦ」がある。図５（Ｄ）に加入者登録状態の定義を示す。登録状態には非登録（レジスタ無し）と登録（レジスタ有り）がある。
【００２６】
以上のようなサービスを受ける為には、加入者は予め自ドメイン内のＳＩＰプロキシサーバに加入者情報の登録／削除を行う。図６（Ａ）に加入者情報登録処理のシーケンス図を示す。加入者はドメイン内のＳＩＰプロキシサーバ（加入者収容サーバとも呼ぶ）に「REGISTER」メッセージを送信する。ＳＩＰプロキシサーバは、自局の加入者状態管理テーブルに加入者情報の登録を行うと共に、自局の加入者登録状態を「レジスタ有り」に設定する。またロケーションサーバへの「HTTP Request」のパラメータとして加入者収容ＳＩＰプロキシサーバ（自局）のアドレス情報及び加入者の電話番号を搭載し、ロケーションサーバに送信する。
【００２７】
図６（Ｂ）に情報登録時の「HTTP Request」パラメータ形式を示す。ロケーションサーバは、上記受信したパラメータ情報を加入者情報ＤＢ上の加入者収容サーバ情報管理テーブルに追加・登録する。
【００２８】
図６（Ｃ）に加入者収容サーバ情報管理テーブルのデータ登録例を示す。例えば加入者の「電話番号」、「ＳＩＰ−ＵＲＬ」、「位置情報」、「収容サーバＩＰアドレス」、「収容サーバＦＱＤＮ」が登録される。
【００２９】
図６（Ｄ）に加入者情報削除処理のシーケンス図を示す。加入者はドメイン内のＳＩＰプロキシサーバに「UNREGISTER」メッセージを送信する。ＳＩＰプロキシサーバは、自局の加入者状態管理テーブルの加入者情報の削除を行うと共に、自局の加入者登録状態を「レジスタ無し」に設定する。またロケーションサーバへの「HTTP Request」のパラメータとして加入者の電話番号を設定し、ロケーションサーバに削除の要求を行う。ロケーションサーバは、自局の加入者収容サーバ情報管理テーブルから加入者の電話番号に一致する加入者収容サーバ情報を削除する。
【００３０】
ＳＩＰプロキシサーバにおける加入者状態の情報はＳＩＰプロトコルに従って様々に状態遷移する。次にこれを説明する。図７〜図１２はＳＩＰプロキシサーバにおける加入者状態管理処理のシーケンス図（１）〜（６）であり、図７は「ＲＥＧＩＳＴＥＲ」／「ＵＮＲＥＧＩＳＴＥＲ」メッセージによる「ＩＤＬＥ」／「ＰＯＷＥＲＯＦＦ」の状態遷移を示している。なお、図は加入者ＡとＳＩＰプロキシサーバ４０Ａとの関係を示すが、加入者ＢとＳＩＰプロキシサーバ４０Ｂとの関係についても同様である。
【００３１】
図７（Ａ）において、加入者Ａが「ＰＯＷＥＲＯＦＦ」の状態で「ＲＥＧＩＳＴＥＲ」（登録情報）のメッセージを送信すると、ＳＩＰプロキシサーバＡで認証情報の確認が行われ、ＯＫであるとステータス２００（ＯＫ）が返送される。この時点でＳＩＰプロキシサーバＡが管理する加入者Ａの状態は「ＩＤＬＥ」の状態に遷移する。その後は、加入者Ａより定期的に「ＲＥＧＩＳＴＥＲ」メッセージの送信が行われ、これによって「ＩＤＬＥ」状態は更新・維持される。
【００３２】
図７（Ｂ）において、「ＩＤＬＥ」の状態で「ＵＮＲＥＧＩＳＴＥＲ」のメッセージが正常に受け付けられると、「ＰＯＷＥＲＯＦＦ」の状態に遷移する。
【００３３】
図８は呼制御に基づく「ＩＤＬＥ」／「ＢＵＳＹ」の状態遷移を示している。図において、加入者Ａからの「ＩＮＶＩＴＥ」リクエストにＳＩＰプロキシサーバ４０Ａがステータス１００（Tring）を返送すると、加入者Ａの状態は「ＩＤＬＥ」から「ＢＵＳＹ」に遷移する。この「ＩＮＶＩＴＥ」リクエストは最終的にＳＩＰプロキシサーバ４０Ｂを介して加入者Ｂに中継され、ここで加入者Ｂは、自身が呼ばれていることを表すステータス１８０（Ringing）をＳＩＰプロキシサーバ４０Ｂに返送する。この時、加入者Ｂの状態は「ＩＤＬＥ」から「ＢＵＳＹ」に遷移する。そして、加入者Ｂのオフフックに従いステータス２００（ＯＫ）を返送すると、加入者Ａと間で通話路（ＲＴＰ）が形成され、両者は通話状態となる。こうして、やがて、加入者Ａがオンフックすると、呼切断を表す「ＢＹＥ」を送信する。これにより加入者Ａの状態は「ＢＵＳＹ」から「ＩＤＬＥ」に遷移する。更に該「ＢＹＥ」が加入者Ｂに中継されてステータス２００を返送すると、加入者Ｂの状態も「ＢＵＳＹ」から「ＩＤＬＥ」に遷移する。
【００３４】
図９は有効期限経過「Expire」による「ＩＤＬＥ」から「ＦＡＵＬＴ」状態への遷移を示している。図９（Ａ）において、「ＩＤＬＥ」状態で、加入者Ａが定期的に「ＲＥＧＩＳＴＥＲ」を送らないでいると、やがて有効期間が切れて「Expire」タイマがタイムアウトし、加入者Ａの状態は「ＩＤＬＥ」から「ＦＡＵＬＴ」に遷移する。この状態は加入者Ａからの新たな「ＲＥＧＩＳＴＥＲ」によって解除され、加入者状態は「ＩＤＬＥ」に遷移する。
【００３５】
図９（Ｂ）において、ＳＩＰプロキシサーバＡは、レイヤ３の制御下で定期的に「ping」を送信し、これに対して加入者Ａは同じくレイヤ３の制御かで応答を返送する。しかし、この応答が所定回数行われないと、加入者Ａの状態は「ＩＤＬＥ」から「ＦＡＵＬＴ」に遷移する。この状態は加入者Ａからの新たな「ＲＥＧＩＳＴＥＲ」によって解除され、状態は「ＩＤＬＥ」に遷移する。
【００３６】
図１０は認証不一致（ＮＧ）による「ＬＯＣＫＯＵＴ」状態への遷移を示している。図１０（Ａ）において、「ＰＯＷＥＲＯＦＦ」状態における加入者Ａからの「ＲＥＧＩＳＴＥＲ」に対する認証が正しくないと、加入者Ａの状態は「ＬＯＣＫＯＵＴ」に遷移する。この「ＬＯＣＫＯＵＴ」状態は保守者の閉塞解除処理によって解除され、「ＰＯＷＥＲＯＦＦ」状態に遷移する。その後、新たに正しい「ＲＥＧＩＳＴＥＲ」処理が行われると、「ＩＤＬＥ」状態に遷移する。
【００３７】
図１０（Ｂ）において、「ＩＤＬＥ」状態における、加入者Ａからの「ＩＮＶＩＴＥ」の認証が正しくないと、「ＬＯＣＫＯＵＴ」状態に遷移する。おの「ＬＯＣＫＯＵＴ」状態は保守者の閉塞解除処理によって解除され、「ＰＯＷＥＲＯＦＦ」状態に遷移する。そして、新たに正しい「ＲＥＧＩＳＴＥＲ」が行われると、「ＩＤＬＥ」状態に遷移する。
【００３８】
図１１は悪意呼による「ＬＯＣＫＯＵＴ」状態への遷移を示している。図１１（Ａ）において、加入者Ａからの「ＲＥＧＩＳＴＥＲ」処理が正しくないと、加入者Ａの状態は「ＰＯＷＥＲＯＦＦ」から「ＬＯＣＫＯＵＴ」（ＤＯＳ閉塞状態）に遷移する。この「ＬＯＣＫＯＵＴ」状態は保守者の閉塞解除によって解除され、「ＰＯＷＥＲＯＦＦ」状態に遷移する。その後、新たに正しい「ＲＥＧＩＳＴＥＲ」処理が行われると、「ＩＤＬＥ」状態に遷移する。
【００３９】
図１１（Ｂ）において、「ＩＤＬＥ」状態における「ＩＮＶＩＴＥ」処理が正しくない（悪意呼が入力される）と、「ＬＯＣＫＯＵＴ」（ＤＯＳ閉塞状態）の状態に遷移する。
この「ＬＯＣＫＯＵＴ」状態は保守者の閉塞解除によって解除され、「ＰＯＷＥＲＯＦＦ」の状態に遷移する。その後、新たに正しい「ＲＥＧＩＳＴＥＲ」処理が行われると、「ＩＤＬＥ」状態に遷移する。
【００４０】
図１２は保守者による「ＬＯＣＫＯＵＴ」を示している。図において、任意状態で保守者が閉塞処理を行うと、加入者Ａは「ＬＯＣＫＯＵＴ」の状態に遷移する。この「ＬＯＣＫＯＵＴ」の状態は保守者の閉塞解除によって解除され、「ＰＯＷＥＲＯＦＦ」状態に遷移する。その後、新たに正しい「ＲＥＧＩＳＴＥＲ」処理が行われると、「ＩＤＬＥ」の状態に遷移する。
【００４１】
以上述べた如く本実施の形態によれば、ＩＰ加入者端末の「ＩＤＬＥ」、「ＢＵＳＹ」、「ＬＯＣＫＯＵＴ」、「ＦＡＵＬＴ」、「ＰＯＷＥＲＯＦＦ」の各状態を、加入者端末にアクセスすることなく、収容ＳＩＰプロキシサーバ４０において適正に更新・管理でき、よって他の加入者向けに、ＩＰ電話端末に対する話中状態、故障状態、電源断状態等の情報をリアルタイムに提供可能となる。
【００４２】
なお、上記実施の形態では、アプリケーションサーバ１０がＳＩＰの下で動作するＵＡ(user agent)機能部を介してＩＰ電話端末５０と接続する場合を主に述べたが、これに限らない。図１に示す如く、アプリケーションサーバ１０がＷＥＢアクセスインタフェース機能部１６を備えることで、外部のパーソナルコンピュータ６０等からのＷＥＢ（ＨＴＴＰ）を介した加入者状態の問い合わせに対してＷＥＢ上でサービスを提供することも可能である。
【００４３】
また、上記アプリケーションサーバ１０とロケーションサーバ３０、ＳＩＰプロキシサーバ４０間で使用しているＨＴＴＰについては一例であり、他のプロトコルでも実現可能である。
【００４４】
また、上記本発明に好適なる実施の形態を述べたが、本発明思想を逸脱しない範囲内で各部の構成、処理及びこれらの組合せの様々な変更が行えることは言うまでも無い。
【図面の簡単な説明】
【００４５】
【図１】実施の形態による通信システムの構成を示す図である。
【図２】実施の形態による加入者状態問い合わせ処理のシーケンス図である。
【図３】実施の形態による音声ガイダンス生成処理のイメージ図である。
【図４】実施の形態による問い合わせ対象加入者収容サーバ抽出処理のイメージ図である。
【図５】実施の形態による加入者収容サーバが管理する加入者情報の収集処理を説明する図である。
【図６】実施の形態による加入者収容サーバ情報の登録／削除処理を説明する図である。
【図７】実施の形態によるＳＩＰプロキシサーバにおける加入者状態管理処理のシーケンス図（１）である。
【図８】実施の形態によるＳＩＰプロキシサーバにおける加入者状態管理処理のシーケンス図（２）である。
【図９】実施の形態によるＳＩＰプロキシサーバにおける加入者状態管理処理のシーケンス図（３）である。
【図１０】実施の形態によるＳＩＰプロキシサーバにおける加入者状態管理処理のシーケンス図（４）である。
【図１１】実施の形態によるＳＩＰプロキシサーバにおける加入者状態管理処理のシーケンス図（５）である。
【図１２】実施の形態によるＳＩＰプロキシサーバにおける加入者状態管理処理のシーケンス図（６）である。
【符号の説明】
【００４６】
１０  アプリケーションサーバ
１１  データベース（ＤＢ）
１２  加入者状態問い合わせ部
１３  呼制御部
１４  音声応答部
１５  通信制御部
２０  保守コンソール
３０  ロケーションサーバ
４０Ａ，４０Ｂ  ＳＩＰ(Session Initiation Protocol)プロキシサーバ
５０Ａ，５０Ｂ  ＩＰ電話端末（ハードフォン等）
１００  ネットワーク
【図１】
2006165919.tif 000003
【図２】
2006165919.tif 000004
【図３】
2006165919.tif 000005
【図４】
2006165919.tif 000006
【図５】
2006165919.tif 000007
【図６】
2006165919.tif 000008
【図７】
2006165919.tif 000009
【図８】
2006165919.tif 000010
【図９】
2006165919.tif 000011
【図１０】
2006165919.tif 000012
【図１１】
2006165919.tif 000013
【図１２】
2006165919.tif 000014