JP5961519B2 - 呼制御装置、呼制御方法、呼制御プログラム - Google Patents

Description

本発明は呼制御装置、呼制御方法、呼制御プログラムに関し、特に呼に付与可能な付加サービスを提供するアプリケーションサーバへ、サービスの提供を要求する呼制御装置、呼制御方法、呼制御プログラムに関する。

移動体通信システムの標準化プロジェクトである３ＧＰＰ（３rd Generation Partnership Project）のマルチメディア通信システムとして、ＩＭＳ（IP Multimedia Subsystem）ネットワークが知られている。このＩＭＳネットワークでは、呼に対する付加サービスは、アプリケーションサーバ（以下、適宜、ＡＳと呼ぶ）によって提供される。そのため、ユーザに対してサービスを提供するためのＳＩＰ（Session Initiation Protocol）サーバであるＳ−ＣＳＣＦ（Serving Call Session Control Function）は、呼が付加サービスを要求していると認識した場合には、受信した信号をＡＳにルーティングし、ＡＳとのセッションを開始する。この付加サービスの認識には、ユーザプロファイルのＩＦＣ（Initial Filter Criteria）が使用される。

Ｓ−ＣＳＣＦは、ＩＦＣを、ユーザの認証情報やサービス情報を保持するデータベースであるＨＳＳ（Home Subscriber Server）から取得する。なお、Ｓ−ＣＳＣＦがユーザプロファイルのＩＦＣを使用してＡＳ選択制御を実施することについては、標準規格（３ＧＰＰ ＴＳ２９．２２８）に規定されている。
また、特許文献１には、フィルタクライテリア（filter criteria）を用い、Ｓ−ＣＳＣＦが、いずれかのＡＳを利用する必要があるか否かを判定し、ＡＳがＱｏＳ制御や鍵生成などの付加的なサービスを行うことが記載されている。
さらに、特許文献２には、ＡＳのサービス処理の起動をＳ−ＣＳＣＦが行う点が記載されている。
なお、音声通話についての付加サービスには、例えば、通話録音サービス、通訳電話サービス、がある（例えば、非特許文献１参照）。

特開２００９−６５５７６号公報 特開２０１１−２０５１８８号公報

ビスワス シュブラト、外４名、"ネットワーククラウドを構成するサービスイネーブラネットワーク（ＳＥＮ）基盤の導入"、［ｏｎｌｉｎｅ］、平成２４年６月２８日、NTT DOCOMO テクニカルジャーナル（Vol20 No.2 Jul.2012）、［平成２４年１０月２日検索］、インターネット＜ＵＲＬ：http://www.nttdocomo.co.jp/binary/pdf/corporate/technology/rd/technical_journal/new/vol20_2_006jp.pdf＞

ところで、Ｓ−ＣＳＣＦが、受信した信号をＡＳにルーティングしても、ＡＳからエラー応答が返信される場合や所定時間経過してもＡＳから応答が無い（無応答）場合がある。このような場合、上述した標準規格に従うと、呼の確立が中断されてしまう。この場合の動作について、図９および図１０を参照して説明する。図９および図１０は、いずれも、図示せぬ発信元装置から呼の接続が要求された場合の動作例を示している。ただし、図９は正常動作の場合、図１０はＡＳからエラー応答が返信された場合、の動作例を示している。

まず、図９（Ａ）のように、ＨＳＳ３からＳ−ＣＳＣＦ１０へ、アプリケーションサーバ識別情報１００がダウンロードされる（Ｓ０）。このアプリケーションサーバ識別情報１００は、発信元装置と、その発信元装置によって利用可能でありかつ呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報である。本例では、図示せぬ発信元装置についての、アプリケーションサーバ識別情報の内容は、「ＳｅｔＩＤ：０１」および「ＳｅｔＩＤ：０２」である。本例では、「ＳｅｔＩＤ：０１」はＡＳ２１を、「ＳｅｔＩＤ：０２」はＡＳ２２を、それぞれ示している。

次に、図９（Ｂ）のように、図示せぬ発信元装置から呼の接続が要求されると、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦ１０に入力される（Ｓ１）。すると、Ｓ−ＣＳＣＦ１０は、アプリケーションサーバ識別情報１００の内容に基づいて、まずＡＳ２１へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ２）。
その後、ＡＳ２１から、正常応答であるＩＮＶＩＴＥが返信されると（Ｓ３）、Ｓ−ＣＳＣＦ１０は、図９（Ｃ）のように、アプリケーションサーバ識別情報１００の内容に基づいて、次にＡＳ２２へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ４）。

その後、ＡＳ２２から、正常応答であるＩＮＶＩＴＥが返信されると（Ｓ５）、Ｓ−ＣＳＣＦ１０は、接続先対地５０すなわち図示せぬ着信先装置へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ６）。
以上の処理により、図示せぬ発信元装置は、ＡＳ２１およびＡＳ２２それぞれにより、呼に付与可能な付加サービスの提供を受けることができる。

一方、図１０（Ａ）のように、ＨＳＳ３からＳ−ＣＳＣＦ１０へ、アプリケーションサーバ識別情報１００がダウンロードされる（Ｓ０）。本例においても、図示せぬ発信元装置についての、アプリケーションサーバ識別情報の内容は、「ＳｅｔＩＤ：０１」および「ＳｅｔＩＤ：０２」である。本例では、「ＳｅｔＩＤ：０１」はＡＳ２１を、「ＳｅｔＩＤ：０２」はＡＳ２２を、それぞれ示している。

次に、図１０（Ｂ）のように、図示せぬ発信元装置から呼の接続が要求されると、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦ１０に入力される（Ｓ１）。すると、Ｓ−ＣＳＣＦ１０は、アプリケーションサーバ識別情報１００の内容に基づいて、まずＡＳ２１へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ２）。
ここで、ＡＳ２１においてエラーが発生すると（Ｓ２ａ）、図１０（Ｃ）のように、ＡＳ２１から、エラー応答が返信される（Ｓ３ａ）。エラー応答は、例えば、ＳＩＰ信号の「４××」または「５××」（×は自然数）である。エラー応答を受信すると、Ｓ−ＣＳＣＦ１０は、呼を確立する処理を継続せず、エラー応答を図示せぬ発信元装置へ返信する（Ｓ４ａ）。なお、上記は、ＡＳからエラー応答が返信される場合について説明したが、所定時間経過してもＡＳから応答が無い（無応答）場合も同様に、Ｓ−ＣＳＣＦ１０は、呼を確立する処理を継続せず、エラー応答を図示せぬ発信元装置へ返信する。

以上のように、上述した標準規格に従うと、呼の確立が中断されてしまう。ここで、災害発生時の安否確認のための通話や、通話録音サービスや通訳サービスなどの付加サービスの適用が不可の場合でも、とにかく呼の確立を継続して通話を実現したい、というユーザの要望があると考えられる。しかしながら、上述した標準規格に従うと、その要望に応えることができない。また、災害発生時以外において、ユーザによっては、付加サービスの適用が不可であれば、呼を確立したくない、と考えることも予想される。
本発明は上述した従来技術の問題点を解決するためになされたものであり、その目的はアプリケーションサーバからエラー応答が返信される場合や無応答の場合に、呼の確立を継続するか否かを適切に処理することのできる、呼制御装置、呼制御方法、呼制御プログラムを提供することである。

本発明のある態様による呼制御装置は、発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記呼に付与可能な付加サービスを提供するアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する呼制御装置であって、前記呼確立要求を受信した場合に、前記発信元装置と該発信元装置によって利用可能でありかつ前記呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報であるアプリケーションサーバ識別情報を記憶するアプリケーションサーバ識別情報記憶部と、前記呼確立要求を受信した場合に、前記アプリケーションサーバ識別情報記憶部に記憶されているアプリケーションサーバ識別情報を参照し、前記付加サービスを提供可能なアプリケーションサーバを選択するアプリケーションサーバ選択部と、前記アプリケーションサーバ選択部が選択したアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する付加サービス提供要求部と、前記付加サービス提供要求部がサービスの提供を要求したアプリケーションサーバから、前記付加サービスを提供できないことを示すエラー応答を受信した場合または前記アプリケーションサーバから応答が無かった場合、該アプリケーションサーバごとに設定された呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する呼継続判定部と、前記呼継続判定部が呼を確立するための処理を継続すると判定した場合に、該付加サービスを付与せずに呼を確立するための呼確立要求を着信先装置へ向けて送信する呼確立要求部と、を備えることを特徴とする。この構成によれば、アプリケーションサーバからエラー応答が返信される場合や無応答の場合に、ユーザの意思を考慮しつつ呼の確立を継続するか否かを適切に処理することができる。

ここで、前記アプリケーションサーバが複数である場合において、前記呼継続情報は、前記付加サービスを提供できないことを示すエラー応答を受信した場合または前記アプリケーションサーバから応答が無かった場合に、呼を確立するための処理を継続するか否かを、アプリケーションサーバごとに定めた情報であり、前記呼継続判定部が、前記呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定するようにしてもよい。この呼継続情報に基づいて判定を行うことにより、呼の確立を継続するか否かを適切に処理することができる。

また、前記アプリケーションサーバ選択部が、複数の前記アプリケーションサーバのうちの１つから前記エラー応答を受信した場合または複数の前記アプリケーションサーバのうちの１つから応答が無かった場合に、複数の前記アプリケーションサーバのうちの他のアプリケーションサーバを選択し、前記付加サービス提供要求部が、前記アプリケーションサーバ選択部が選択した、前記他のアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求するようにしてもよい。こうすることにより、アプリケーションサーバからエラー応答が返信される場合や無応答の場合に、互いに矛盾する処理を行うことを回避し、呼の確立を継続するか否かを適切に処理することができる。

前記呼継続情報は、複数の前記アプリケーションサーバのうち、あるアプリケーションサーバから応答が無かった場合に呼を確立するための処理を継続すると判定され、かつ、他のアプリケーションサーバから応答が無かった場合に呼を確立するための処理を継続しないと判定された場合に、いずれの判定を優先するかを示す優先情報に基づいて生成されるものであり、前記呼継続判定部が、複数の前記アプリケーションサーバから、前記エラー応答を受信した場合または応答が無かった場合に、前記呼継続情報に基づいて、呼を確立するための処理を継続するか否かを判定し、前記呼確立要求部が、前記呼継続判定部が呼を確立するための処理を継続すると判定した場合には前記呼確立要求を着信先装置へ向けて送信するようにしてもよい。このようにすれば、複数の付加サービスのいずれかを適用できない場合であっても、他の付加サービスを適用した呼を確立することができる。

前記呼継続情報は、前記発信元装置のユーザごとに設定された情報であり、前記呼継続判定部が、呼を確立するための処理を継続するか否かを、前記発信元装置のユーザごとに判定するようにしてもよい。このように構成すれば、呼を確立するための処理を継続するか否かをユーザの意思に従って判定することができる。
前記発信元装置に対応する加入者情報を管理する加入者情報管理装置から、前記呼継続情報を取得する呼継続情報取得部と、前記呼継続情報取得部によって取得された呼継続情報を記憶する呼継続情報記憶部と、をさらに備え、前記呼継続判定部が、前記呼継続情報記憶部に記憶されている呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定することが望ましい。このように構成すれば、加入者情報管理装置において作成した呼継続情報を呼制御装置にダウンロードすることができるので、付加サービスが追加された場合でも呼制御装置ではサービスを意識せずに呼制御を行うことができる。

前記呼継続判定部は、災害が発生したことを示す情報が自装置に入力された場合には、呼を確立するための処理を継続すると判定するようにしてもよい。このようにすれば、災害発生時などにおいて、付加サービスを利用できない場合でも呼を確立することができ、安否確認のための通話を行うことができる。

本発明のある態様による呼制御方法は、発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記呼に付与可能な付加サービスを提供するアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する呼制御方法であって、前記呼確立要求を受信した場合に、前記発信元装置と該発信元装置によって利用可能でありかつ前記呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報であるアプリケーションサーバ識別情報を記憶するアプリケーションサーバ識別情報記憶ステップと、前記呼確立要求を受信した場合に、前記アプリケーションサーバ識別情報記憶ステップにおいて記憶されたアプリケーションサーバ識別情報を参照し、前記付加サービスを提供可能なアプリケーションサーバを選択するアプリケーションサーバ選択ステップと、前記アプリケーションサーバ選択ステップにおいて選択されたアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する付加サービス提供要求ステップと、前記付加サービス提供要求ステップにおいてサービスの提供を要求したアプリケーションサーバから、前記付加サービスを提供できないことを示すエラー応答を受信した場合または前記アプリケーションサーバから応答が無かった場合、該アプリケーションサーバごとに設定された呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する呼継続判定ステップと、前記呼継続判定ステップにおいて呼を確立するための処理を継続すると判定した場合に、該付加サービスを付与せずに呼を確立するための呼確立要求を着信先装置へ向けて送信する呼確立要求ステップと、
を含むことを特徴とする。この方法によれば、アプリケーションサーバからエラー応答が返信される場合や無応答の場合に、ユーザの意思を考慮しつつ呼の確立を継続するか否かを適切に処理することができる。

本発明のある態様による呼制御プログラムは、発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記呼に付与可能な付加サービスを提供するアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求するための呼制御プログラムであって、コンピュータに、前記発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記発信元装置と該発信元装置によって利用可能でありかつ前記呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報であるアプリケーションサーバ識別情報を記憶するアプリケーションサーバ識別情報記憶ステップと、前記発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記アプリケーションサーバ識別情報記憶ステップにおいて記憶されたアプリケーションサーバ識別情報を参照し、前記付加サービスを提供可能なアプリケーションサーバを選択するアプリケーションサーバ選択ステップと、前記アプリケーションサーバ選択ステップにおいて選択されたアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する付加サービス提供要求ステップと、前記付加サービス提供要求ステップにおいてサービスの提供を要求したアプリケーションサーバから、前記付加サービスを提供できないことを示すエラー応答を受信した場合または前記アプリケーションサーバから応答が無かった場合、該アプリケーションサーバごとに設定された呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する呼継続判定ステップと、前記呼継続判定ステップにおいて呼を確立するための処理を継続すると判定した場合に、該付加サービスを付与せずに呼を確立するための呼確立要求を着信先装置へ向けて送信する呼確立要求ステップと、を実行させることを特徴とする。このプログラムを採用すれば、アプリケーションサーバからエラー応答が返信される場合や無応答の場合に、ユーザの意思を考慮しつつ呼の確立を継続するか否かを適切に処理することができる。

本発明によれば、アプリケーションサーバからエラー応答が返信される場合や無応答の場合に、呼の確立を継続するか否かを適切に処理することができる。

本発明の実施の形態による呼制御装置の構成を示す機能ブロック図である。 付加サービスを提供できないことを示すエラー応答を受信した場合における、呼制御装置の動作例を説明する図である。 ＨＳＳに記憶されている付加サービス情報テーブルの例を示す図である。 付加サービスを提供できないことを示すエラー応答を受信した場合において、呼を確立するための処理を行わないことを優先する場合の、呼制御装置の動作例を説明する図である。 複数のＡＳの少なくとも１つからエラー応答が返信された場合の、呼制御装置の動作例を説明する図である。 ＨＳＳの動作例を示すフローチャートである。 本発明の実施の形態による呼制御装置の動作例を示すフローチャートである。 本発明の実施の形態による呼制御装置と他の装置との間の信号授受を示すシーケンス図である。 従来の呼制御装置の動作例を示す図である。 従来の呼制御装置の他の動作例を示す図である。

以下、本発明の実施の形態を、図面を参照して説明する。なお、以下の説明において参照する各図では、他の図と同等部分は同一符号によって示されている。
（呼制御装置の構成例）
図１は、本発明の実施形態による呼制御装置１の構成例を示すブロック図である。呼制御装置１は、Ｓ−ＣＳＣＦとしての機能を有しており、ＨＳＳからＩＦＣを取得し、着信先装置へのルーティングやＡＳへのＳＩＰ信号の転送を行う。ここでは、発信元装置から、呼を確立するための呼確立要求を受信した場合に、その呼に付与可能な付加サービスを提供するアプリケーションサーバへ、サービスの提供を要求する機能について主に説明する。

なお、以下の説明では、移動通信網において一般的に設けられる無線基地局や交換機などについては、その図示およびその説明を省略する。また、以下の説明では、ＩＭＳネットワークの構成要素についても、呼制御装置やＡＳ以外の装置について、その図示およびその説明を省略する。
図１を参照すると、本実施形態による呼制御装置１は、アプリケーションサーバ識別情報記憶部１１と、アプリケーションサーバ選択部１２と、付加サービス提供要求部１３と、呼継続情報記憶部１４と、呼継続判定部１５と、呼確立要求部１６と、を備えている。

アプリケーションサーバ識別情報記憶部１１は、アプリケーションサーバ識別情報を記憶する機能を有している。アプリケーションサーバ識別情報は、呼確立要求を受信した場合に、前記発信元装置と該発信元装置によって利用可能でありかつ前記呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報である。
アプリケーションサーバ選択部１２は、呼確立要求を受信した場合に、アプリケーションサーバ識別情報記憶部１１に記憶されているアプリケーションサーバ識別情報を参照し、付加サービスを提供可能なアプリケーションサーバを選択する機能を有している。

付加サービス提供要求部１３は、アプリケーションサーバ選択部１２が選択したアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する機能を有している。
アプリケーションサーバ選択部１２は、複数の前記アプリケーションサーバのうちの１つから前記エラー応答を受信した場合または複数のアプリケーションサーバのうちの１つから応答が無かった場合に、複数のアプリケーションサーバのうちの他のアプリケーションサーバを選択することもある。その場合、付加サービス提供要求部１３は、アプリケーションサーバ選択部１２が選択した、他のアプリケーションサーバへ、そのアプリケーションサーバが提供するサービスの提供を要求する。

呼継続情報記憶部１４は、呼継続情報を記憶する機能を有している。呼継続情報は、付加サービスを提供できないことを示すエラー応答を受信した場合またはアプリケーションサーバから応答が無かった場合に、呼を確立するための処理を継続するか否かを、アプリケーションサーバごとに定めた情報である。
呼継続判定部１５は、付加サービス提供要求部１３がサービスの提供を要求したアプリケーションサーバから、付加サービスを提供できないことを示すエラー応答を受信した場合またはアプリケーションサーバから応答が無かった場合、アプリケーションサーバについて設定された呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する機能を有している。なお、呼継続情報は、発信元装置のユーザごとに設定された情報であってもよい。その場合、呼継続判定部１５は、呼を確立するための処理を継続するか否かを、発信元装置のユーザごとに判定することになる。

呼確立要求部１６は、呼継続判定部１５が呼を確立するための処理を継続すると判定した場合に、付加サービスを付与せずに呼を確立するための呼確立要求を着信先装置へ向けて送信する機能を有している。
また、本実施形態による呼制御装置１は、アプリケーションサーバ識別情報取得部１７と、呼継続情報取得部１８と、を備えている。
アプリケーションサーバ識別情報取得部１７は、発信元装置に対応する加入者情報を管理する加入者情報管理装置であるＨＳＳ３からアプリケーションサーバ識別情報を取得する機能を有する。
アプリケーションサーバ識別情報取得部１７が取得したアプリケーションサーバ識別情報は、アプリケーションサーバ識別情報記憶部１１に記憶され、アプリケーションサーバ選択部１２によって参照される。

呼継続情報取得部１８は、ＨＳＳ３から呼継続情報を取得する機能を有する。呼継続情報取得部１８が取得した呼継続情報は、呼継続情報記憶部１４に記憶される。上記の呼継続判定部１５は、呼継続情報記憶部１４に記憶されている呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する。
なお、呼制御装置１を構成する各部の機能は、図示せぬＣＰＵが図示せぬ記憶装置に記憶されているプログラムを実行することによって実現することができる。

ＨＳＳ３は、各ユーザに関する、プロファイル情報を記憶している。ＨＳＳ３に記憶されているプロファイル情報は、例えば、ユーザの認証情報、利用可能なサービスを示すサービス情報、である。
発信元装置４は、通話する機能を有する装置（例えば周知の携帯電話端末）から呼が発信されたことに応答してＳＩＰ信号を呼制御装置に入力する装置である。着信先装置５は、呼制御装置からのＳＩＰ信号を中継し、通話する機能を有する装置（例えば周知の携帯電話端末）へＳＩＰ信号を送信する装置である。発信元装置４、着信先装置５は、共に、例えば、Ｐ−ＣＳＣＦ（Proxy Call Session Control Function）である。

（呼制御装置の動作例）
次に、以上の構成からなる呼制御装置の動作例について説明する。
まず、ＡＳから正常応答（ＩＮＶＩＴＥ）が返信された場合は、図９を参照して説明した動作と同様になり、付加サービスを適用して通話を行うことができる。
一方、付加サービスを提供できないことを示すエラー応答を受信した場合またはＡＳから応答が無かった場合に、ＡＳごとに設定された呼継続情報に基づいて、呼を確立するための処理を継続するか否かを判定する。以下、呼制御装置が、付加サービスを提供できないことを示すエラー応答を受信した場合の動作例について説明する。

まず、図２（Ａ）のように、ＨＳＳ３からＳ−ＣＳＣＦ１へ、アプリケーションサーバ識別情報１００および呼継続情報２００がダウンロードされる（Ｓ００）。
アプリケーションサーバ識別情報１００は、発信元装置と、その発信元装置によって利用可能でありかつ呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報である。

また、呼継続情報２００は、アプリケーションサーバごとに設定された情報であり、複数の前記アプリケーションサーバのうち、あるアプリケーションサーバから応答が無かった場合に呼を確立するための処理を継続すると判定され、かつ、他のアプリケーションサーバから応答が無かった場合に呼を確立するための処理を継続しないと判定された場合に、いずれの判定を優先するかを示す優先情報に基づいて生成される。

なお、各ユーザについて、通話に伴って付加可能なサービスを示す付加サービス情報は、付加サービスの契約または契約の解除（解約）が行われた時、「お客様情報」として専用端末から入力される。この専用端末は、一般に、携帯電話販売店の店舗などに設置されている。例えば、ユーザＡについて、「ＡＡサービス」、「ＢＢサービス」、「ＣＣサービス」という付加サービスの契約が行われると、それらを示す付加サービス情報が専用端末から入力される。入力された付加サービス情報は、ＨＳＳ３に記憶される。なお、専用端末の代わりに、ユーザが、特番発信して付加サービス情報を設定したり、カスタマーコントローラによって付加サービス情報を設定したりしてもよい。

図２（Ｂ）のように、発信元装置から呼の接続が要求されると、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦ１に入力される（Ｓ１１）。すると、Ｓ−ＣＳＣＦ１は、アプリケーションサーバ識別情報１００の内容に基づいて、まずＡＳ２１へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ１２）。
ここで、ＡＳ２１においてエラーが発生すると（Ｓ１２ａ）、図２（Ｃ）のように、ＡＳ２１から、エラー応答が返信される（Ｓ１３）。エラー応答は、例えば、ＳＩＰ信号の「４××」または「５××」（×は自然数）である。エラー応答を受信すると、Ｓ−ＣＳＣＦ１の呼継続判定部１５は、呼継続情報２００に基づき、呼を確立する処理を継続するか否かを判定する（Ｓ１４）。この判定の結果、呼継続情報２００が、呼を確立する処理を継続する内容に設定されていれば、Ｓ−ＣＳＣＦ１は、接続先対地５０すなわち着信先装置へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ１５）。

（付加サービス情報の例）
図３（Ａ）、図３（Ｂ）は、ＨＳＳ３に記憶されている付加サービス情報テーブルの例を示す図である。本例において、付加サービス情報テーブルＴは、サービスの内容を示す「サービス情報」、各付加サービス同士の優先順位を示す「優先順位」、「サービス情報」が示すサービスが提供できない場合に、呼の確立処理を継続するか否かを示す「動作指示」、を項目としている。

図３（Ａ）の付加サービス情報テーブルＴを参照すると、サービス情報「ＡＡサービス」については、優先順位が「１」でサービス適用不可の場合の動作指示が「呼継続」、サービス情報「ＢＢサービス」については、優先順位が「２」でサービス適用不可の場合の動作指示が「呼継続」、である。本例では、優先順位を示す番号の数字が若いほど優先度が高いものとする。

この呼継続情報は、該当するサービス情報に対応するＡＳからエラー応答が返信された場合またはそのＡＳから応答が無かった場合に、どの動作指示を行うかを示す。呼継続情報が「呼継続」の場合は呼の確立処理を継続し、呼継続情報が「呼切断」の場合は呼の確立処理を終了する。ある付加サービスについて「呼継続」、他のサービスについて「呼切断」、である場合は、互いに矛盾する処理を行うことになりかねないため、いずれの処理を優先するかを定めた優先順位が設定されている。この優先順位は、付加サービス適用不可の場合の「呼継続」と、他の付加サービス適用不可の場合の「呼切断」とのどちらを優先するかを示す情報である。

つまり、呼継続情報は、複数のアプリケーションサーバのうち、あるアプリケーションサーバから応答が無かった場合に呼を確立するための処理を継続すると判定され、かつ、他のアプリケーションサーバから応答が無かった場合に呼を確立するための処理を継続しないと判定された場合に、いずれの判定を優先するかを示す優先情報に基づいて生成されるものである。

ここで、新たに「新規○○サービス」が加わり、優先順位が変更された場合、付加サービス情報テーブルＴは、例えば図３（Ｂ）のようになる。すなわち、「新規○○サービス」については、優先順位が「１」でサービス適用不可の場合の動作指示が「呼切断」であり、この結果、サービス情報「ＡＡサービス」については、優先順位が「２」で動作指示が「呼継続」、サービス情報「ＢＢサービス」については、優先順位が「３」で動作指示が「呼継続」、である。

したがって、図３（Ｂ）の付加サービス情報テーブルＴの場合、「新規○○サービス」に対応するアプリケーションサーバからエラー応答が返信されて「呼切断」（呼を確立するための処理を継続しない）と判定され、かつ、「ＢＢサービス」に対応するアプリケーションサーバからエラー応答が返信されて「呼継続」（呼を確立するための処理を継続する）と判定された場合、前者の優先順位が「１」で後者の優先順位が「３」であるため、優先順位が「１」である「新規○○サービス」に対応する「呼切断」の処理が行われることになる。

なお、この呼継続情報は、複数のユーザに共通に設定された情報であってもよいし、発信元装置のユーザごとに設定された情報であってもよい。後者の場合、付加サービスが提供されない場合、ユーザによっては呼の確立するための処理の継続を望まないであろうし、ユーザによってはその処理の継続を望むであろうし、ユーザの意思に従って呼継続情報を設定することができる。

前者の場合、どの付加サービスを契約するかについては、ユーザによって異なるため、ユーザが複数の付加サービスを契約した場合に、それら付加サービス同士について動作指示の優先順位に従って、呼継続情報が「呼継続」または「呼切断」に設定される。
なお、上記は、ＨＳＳに記憶されている付加サービス情報テーブルに基づいて呼継続情報を作成する場合について説明したが、テーブルをＳ−ＣＳＣＦに記憶しておき、そのテーブルを参照して制御を行うようにしてもよい。

（呼継続情報の例）
ここで、図３（Ｃ）のように、ユーザＡが契約しているサービスが「ＡＡサービス」であれば、図３（Ｂ）によるとサービス適用不可の場合の動作指示は「呼継続」となる。このユーザＡの発信元装置から呼の接続が要求されると、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦ１に入力される。すると、Ｓ−ＣＳＣＦ１は、アプリケーションサーバ識別情報１００の内容に基づいて、ＡＡサービスを提供するアプリケーションサーバへ、ＳＩＰ信号のＩＮＶＩＴＥを送信する。その後、付加サービスを提供できないことを示すエラー応答をアプリケーションサーバから受信した場合またはアプリケーションサーバから応答が無かった場合、動作指示が「呼継続」であるため、呼を確立するための処理が継続される。つまり、従来の呼制御処理とは異なり、エラー発生などによって付加サービスを利用できない場合であっても呼を確立する処理は継続して行われる。

次に、図３（Ｄ）のように、ユーザＢが契約しているサービスが「ＡＡサービス」および「ＢＢサービス」であれば、図３（Ｂ）によると前者の動作指示の優先順位が高いので、サービス適用不可の場合の動作指示は「呼継続」となる。このユーザＢの発信元装置から呼の接続が要求されると、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦ１に入力される。すると、Ｓ−ＣＳＣＦ１は、アプリケーションサーバ識別情報１００の内容に基づいて、ＡＡサービスを提供するアプリケーションサーバ、ＢＢサービスを提供するアプリケーションサーバへ、順に、ＳＩＰ信号のＩＮＶＩＴＥを送信する。その後、付加サービスを提供できないことを示すエラー応答をいずれかのアプリケーションサーバから受信した場合またはいずれかのアプリケーションサーバから応答が無かった場合、動作指示が「呼継続」であるため、呼を確立するための処理が継続される。つまり、従来の呼制御処理とは異なり、エラー発生などによって付加サービスを利用できない場合であっても呼を確立する処理は継続して行われる。

また、図３（Ｅ）のように、ユーザＣが契約しているサービスが「新規○○サービス」であれば、図３（Ｂ）によると、サービス適用不可の場合の動作指示は「呼切断」となる。このユーザＣの発信元装置から呼の接続が要求されると、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦ１に入力される。すると、Ｓ−ＣＳＣＦ１は、アプリケーションサーバ識別情報１００の内容に基づいて、新規○○サービスを提供するアプリケーションサーバへ、ＳＩＰ信号のＩＮＶＩＴＥを送信する。その後、付加サービスを提供できないことを示すエラー応答をアプリケーションサーバから受信した場合またはアプリケーションサーバから応答が無かった場合、動作指示が「呼切断」であるため、呼を確立するための処理は終了となる。つまり、エラー発生などによって付加サービスを利用できない場合に、一律に、呼を確立する処理を継続するのではなく、ユーザの意思にしたがって、呼を確立する処理を継続するか否かが判定される。

さらに、図３（Ｆ）のように、ユーザＤが契約しているサービスが「新規○○サービス」および「ＡＡサービス」であれば、図３（Ｂ）によると前者の動作指示の優先順位が高いので、サービス適用不可の場合の動作指示は「呼切断」となる。このユーザＤの発信元装置から呼の接続が要求されると、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦ１に入力される。すると、Ｓ−ＣＳＣＦ１は、アプリケーションサーバ識別情報１００の内容に基づいて、新規○○サービスを提供するアプリケーションサーバ、ＡＡサービスを提供するアプリケーションサーバへ、順に、ＳＩＰ信号のＩＮＶＩＴＥを送信する。その後、付加サービスを提供できないことを示すエラー応答をいずれかのアプリケーションサーバから受信した場合またはいずれかのアプリケーションサーバから応答が無かった場合、動作指示が「呼切断」であるため、呼を確立するための処理は終了となる。つまり、エラー発生などによって付加サービスを利用できない場合に、一律に、呼を確立する処理を継続するのではなく、ユーザの意思にしたがって、呼を確立する処理を継続するか否かが判定される。

（災害発生との関係）
地震、津波、洪水、台風などの災害発生時などにおいて、図示せぬ自然災害検知システムなどから、災害が発生したことを示す情報が呼制御装置に入力された場合、呼継続判定部１５は、呼を確立するための処理を継続すると判定することが望ましい。この処理を実現するためには、例えば、すべての付加サービスについて「呼継続」として設定した災害用呼継続情報を用意しておき、災害が発生したことを示す情報が呼制御装置に入力された場合に、その災害用呼継続情報を用いるようにすればよい。
このように制御すれば、災害発生時などにおいて、付加サービスを利用できない場合でも呼を確立することができ、安否確認のための通話を行うことができる。

（呼切断が優先される場合）
次に、ＨＳＳ３からＳ−ＣＳＣＦ１にダウンロードされた呼継続情報が、呼を確立するための処理を行わない「呼切断」として設定されている場合、つまり呼切断が優先される場合について説明する。
図４（Ａ）のように、ＨＳＳ３からＳ−ＣＳＣＦ１へ、アプリケーションサーバ識別情報１００および呼継続情報２００がダウンロードされる（Ｓ００）。本例においても、図示せぬ発信元装置についての、アプリケーションサーバ識別情報１００の内容は、「ＳｅｔＩＤ：０１」および「ＳｅｔＩＤ：０２」である。本例では、「ＳｅｔＩＤ：０１」はＡＳ２１を、「ＳｅｔＩＤ：０２」はＡＳ２２を、それぞれ示している。呼継続情報２００は、「呼切断」とする。

次に、図４（Ｂ）のように、図示せぬ発信元装置から呼の接続が要求されると、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦ１に入力される（Ｓ１１）。すると、Ｓ−ＣＳＣＦ１は、アプリケーションサーバ識別情報１００の内容に基づいて、まずＡＳ２１へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ１２）。

ここで、ＡＳ２１においてエラーが発生すると（Ｓ１２ａ）、図４（Ｃ）のように、ＡＳ２１から、エラー応答が返信される（Ｓ１３）。エラー応答は、例えば、ＳＩＰ信号の「４××」または「５××」（×は自然数）である。エラー応答を受信すると、Ｓ−ＣＳＣＦ１の呼継続判定部１５は、呼継続情報２００に基づき、呼を確立する処理を継続するか否かを判定する（Ｓ１４）。本例では、上記したように呼継続情報２００が「呼切断」であるため、ＡＳ２１に対応する付加サービスの優先順位が「１」であれば、呼継続判定部１５は、呼を確立する処理は行わないと判定する。すると、Ｓ−ＣＳＣＦ１は、呼を確立する処理を継続せず、エラー応答を発信元装置へ返信する（Ｓ１５）。なお、上記は、ＡＳからエラー応答が返信される場合について説明したが、所定時間経過してもＡＳから応答が無い（無応答）場合も同様に、Ｓ−ＣＳＣＦ１は、呼を確立する処理を継続せず、エラー応答を発信元装置へ返信する。

以上のように、ＡＳからのエラー応答が返信された場合または無応答の場合には付加サービスの提供を受けることができず、その場合には呼の確立を望まないのであれば、ユーザの意思によって呼継続情報２００を「呼切断」に設定しておくことにより、呼が確立されることはなく、課金が生じることはない。

（複数のＡＳのうちの１つからエラー応答が返信された場合）
ところで、呼継続情報２００が「呼継続」に設定されており、複数のＡＳの少なくとも１つからエラー応答が返信された場合は、以下の動作が行われてもよい。
図５（Ａ）のように、ＨＳＳ３からＳ−ＣＳＣＦ１へ、アプリケーションサーバ識別情報１００および呼継続情報２００がダウンロードされる（Ｓ００）。本例においても、図示せぬ発信元装置についての、アプリケーションサーバ識別情報１００の内容は、「ＳｅｔＩＤ：０１」および「ＳｅｔＩＤ：０２」である。本例では、「ＳｅｔＩＤ：０１」はＡＳ２１を、「ＳｅｔＩＤ：０２」はＡＳ２２を、それぞれ示している。呼継続情報２００は、「呼継続」とする。

次に、図５（Ｂ）のように、図示せぬ発信元装置から呼の接続が要求されると、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦ１に入力される（Ｓ１１）。すると、Ｓ−ＣＳＣＦ１は、アプリケーションサーバ識別情報１００の内容に基づいて、まずＡＳ２１へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ１２）。
ここで、ＡＳ２１においてエラーが発生すると（Ｓ１２ａ）、図５（Ｃ）のように、ＡＳ２１から、エラー応答が返信される（Ｓ１３）。エラー応答は、例えば、ＳＩＰ信号の「４××」または「５××」（×は自然数）である。エラー応答を受信すると、Ｓ−ＣＳＣＦ１の呼継続判定部１５は、呼継続情報２００に基づき、呼を確立する処理を継続するか否かを判定する（Ｓ１４）。本例では、上記したように呼継続情報２００が「呼継続」であるため、Ｓ−ＣＳＣＦ１は、次に、他のＡＳ２２へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ１４ａ）。

ここで、ＡＳ２２においてエラーが発生せず、正常応答であるＩＮＶＩＴＥが返信されると（Ｓ１４ｂ）、Ｓ−ＣＳＣＦ１は、接続先対地５０すなわち図示せぬ着信先装置へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ１５）。
ところで、ＡＳ２２においてエラーが発生した場合、本例では、上記したように呼継続情報２００が「呼継続」であるため、Ｓ−ＣＳＣＦ１は、上記と同様に、接続先対地５０すなわち図示せぬ着信先装置へ、ＳＩＰ信号のＩＮＶＩＴＥを送信する。以上のようにＡＳからエラー応答が返信された場合でも、呼継続情報２００が「呼継続」である限り、呼を確立する処理が継続される。

なお、上記は、ＡＳからエラー応答が返信される場合について説明したが、所定時間経過してもＡＳから応答が無い（無応答）場合も同様に、呼を確立する処理が継続される。
以上のように、アプリケーションサーバが複数である場合において、呼継続情報は、付加サービスを提供できないことを示すエラー応答を受信した場合またはアプリケーションサーバから応答が無かった場合に、呼を確立するための処理を継続するか否かを、アプリケーションサーバごとに定めた情報であり、呼継続判定部１５は、呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する。

（ＨＳＳの動作フロー）
ここで、図６を参照して、加入者情報管理装置であるＨＳＳ３の動作フローについて説明する。
図６において、プロファイル情報のダウンロード契機が発生すると（ステップＳ６００）、ＨＳＳによって以下の処理が行われる。ダウンロード契機は、例えば、発信元装置が移動電話装置である場合に、装置電源を投入したタイミングや、位置登録を行ったタイミングである。
ＨＳＳは、発信元装置のユーザが、付加サービスを契約しているユーザか否か判断する（ステップＳ６０１）。この判断は、ＨＳＳに記憶されている、加入者情報を参照することによって行うことができる。ステップＳ６０１の判断の結果、付加サービスを契約しているユーザではない場合、付加サービスを適用せずに既存処理に移行する（ステップＳ６０１→Ｓ６０２）。

ステップＳ６０１の判断の結果、付加サービスを契約しているユーザである場合、ＨＳＳ内部に記憶されている付加サービス情報テーブルＴを参照し、優先順位の高い順に、そのユーザが契約している付加サービスであるか確認する（ステップＳ６０１→Ｓ６０３）。そのユーザが契約している付加サービスについては、付加サービス情報テーブルＴの動作指示の内容を呼継続情報としてプロファイル情報に含める（ステップＳ６０４→Ｓ６０５）。

ＨＳＳは、以上の処理を、付加サービス情報テーブルＴのサービスすべてについて確認するまで繰返す（ステップＳ６０６→Ｓ６０３）。そして、付加サービス情報テーブルＴのサービスすべてについて確認が終了したら、プロファイル情報をＳ−ＣＳＣＦに送る（ステップＳ６０６→Ｓ６０７）。
以上の処理がＨＳＳにおいて行われることにより、Ｓ−ＣＳＣＦはＨＳＳから呼継続情報をダウンロードすることができる。

（呼制御装置の動作フロー）
次に、図７を参照して、呼制御装置であるＳ−ＣＳＣＦの動作フローについて説明する。
図７において、呼の接続契機が発生すると（ステップＳ７００）、Ｓ−ＣＳＣＦによって以下の処理が行われる。呼の接続契機は、発信元装置から呼の接続が要求され、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦに入力されたタイミングである。

Ｓ−ＣＳＣＦのアプリケーションサーバ選択部１２は、ＩＦＣを参照し、アプリケーションサーバの選択を行う（ステップＳ７０１）。ここで、選択されたアプリケーションサーバ、すなわち接続先のアプリケーションサーバが正常か否か（ルーティング可能か否か）判断される（ステップＳ７０２）。接続先のアプリケーションサーバが正常でない場合、呼継続判定部１５は、呼接続情報を参照し、呼接続情報の内容に基づき、呼を確立するための処理を継続するか否かを判定する（ステップＳ７０２→Ｓ７０３）。呼を確立するための処理を継続しない場合、その処理を終了する（ステップＳ７０３）。接続先のアプリケーションサーバが正常である場合、付加サービス提供要求部１３は、そのアプリケーションサーバへ接続要求を送信する（ステップＳ７０２→Ｓ７０４）。

付加サービス提供要求部１３がサービスの提供を要求したアプリケーションサーバから、付加サービスを提供できないことを示すエラー応答を受信した場合または所定時間内にアプリケーションサーバから応答が無かった場合（つまり応答タイムアウト）、呼継続判定部１５は、アプリケーションサーバについて設定された呼継続情報の内容に基づき、呼を確立するための処理を継続するか否かを判定する（ステップＳ７０５→Ｓ７０６）。呼を確立するための処理を継続しない場合、その処理を終了する（ステップＳ７０６）。
以上の処理がＳ−ＣＳＣＦにおいて行われることにより、付加サービスを提供できないことを示すエラー応答を受信した場合またはＡＳから応答が無かった場合に、ＡＳごとに設定された呼継続情報に基づいて、呼を確立するための処理を継続するか否かを判定できる。

（呼制御装置と他の装置との間の信号授受）
図８は、本実施形態による呼制御装置と他の装置との間の信号授受の例を示すシーケンス図である。図８は、呼制御装置であるＳ−ＣＳＣＦ１と、他の装置である、発信元装置４、ＨＳＳ３、ＡＳ２１および２２、着信先装置５との間の信号授受を、Ｓ−ＣＳＣＦ１内部の処理と共に示している。本例では、ＡＳ２１および２２によって提供される付加サービスを適用する場合について説明する。

図８において、発信元装置４の位置登録が行われると（Ｓ８０１）、ＨＳＳ３からＳ−ＣＳＣＦ１へ、プロファイル情報がダウンロードされる（Ｓ８０２）。このプロファイル情報には、呼継続情報やＡＳ識別情報が含まれている。
その後、発信元装置４から呼の接続が要求されると、ＳＩＰ信号のＩＮＶＩＴＥがＳ−ＣＳＣＦ１に入力される（Ｓ８０３）。すると、Ｓ−ＣＳＣＦ１は、ＡＳ識別情報に基づいて、ＡＳ２１を選択し（Ｓ８０４）、選択したＡＳ２１へ接続要求であるＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ８０５、Ｓ８０６）。

ＡＳ２１から付加サービスを提供できないことを示すエラー応答を受信した場合またはＡＳ２１から応答が無かった場合、Ｓ−ＣＳＣＦ１は、呼継続情報を参照し、呼を確立するための処理を継続するか否か判定する（Ｓ８０７、Ｓ８０８）。呼を確立するための処理を継続しない場合、Ｓ−ＣＳＣＦ１は呼を確立するための処理を終了し、エラー応答を発信元装置４へ送信する（Ｓ８１３、Ｓ８１４）。

ＡＳ２１から正常応答が返信された場合、Ｓ−ＣＳＣＦ１はＡＳ２２を選択して、ＡＳ２２へ接続要求であるＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ８０９）。
ＡＳ２２から付加サービスを提供できないことを示すエラー応答を受信した場合またはＡＳ２２から応答が無かった場合、Ｓ−ＣＳＣＦ１は、呼継続情報を参照し、呼を確立するための処理を継続するか否か判定する（Ｓ８１０、Ｓ８１１）。呼を確立するための処理を継続しない場合、Ｓ−ＣＳＣＦ１は呼を確立するための処理を終了し、エラー応答を発信元装置４へ送信する（Ｓ８１３、Ｓ８１４）。

ＡＳ２２から正常応答が返信された場合、Ｓ−ＣＳＣＦ１は着信先装置５へ接続要求であるＳＩＰ信号のＩＮＶＩＴＥを送信する（Ｓ８１２）。これにより、発信元装置４と着信先装置５との間に、呼が確立され、かつ、ＡＳ２１および２２によって提供される付加サービスをその呼に適用することができる。

（呼制御方法）
上述した呼制御装置においては、以下のような呼制御方法が実現されている。すなわち、発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記呼に付与可能な付加サービスを提供するアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する呼制御方法であり、前記呼確立要求を受信した場合に、前記発信元装置と該発信元装置によって利用可能でありかつ前記呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報であるアプリケーションサーバ識別情報を記憶するアプリケーションサーバ識別情報記憶ステップと、前記呼確立要求を受信した場合に、前記アプリケーションサーバ識別情報記憶ステップにおいて記憶されたアプリケーションサーバ識別情報を参照し、前記付加サービスを提供可能なアプリケーションサーバを選択するアプリケーションサーバ選択ステップと、前記アプリケーションサーバ選択ステップにおいて選択されたアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する付加サービス提供要求ステップと、前記付加サービス提供要求ステップにおいてサービスの提供を要求したアプリケーションサーバから、前記付加サービスを提供できないことを示すエラー応答を受信した場合または前記アプリケーションサーバから応答が無かった場合、該アプリケーションサーバごとに設定された呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する呼継続判定ステップと、前記呼継続判定ステップにおいて呼を確立するための処理を継続すると判定した場合に、該付加サービスを付与せずに呼を確立するための呼確立要求を着信先装置へ向けて送信する呼確立要求ステップと、を含むことを特徴とする呼制御方法が実現されている。この方法によれば、アプリケーションサーバからエラー応答が返信される場合や無応答の場合に、ユーザの意思を考慮しつつ呼の確立を継続するか否かを適切に処理することができる。

（呼制御プログラム）
上述した呼制御装置においては、以下のような呼制御プログラムが用いられている。すなわち、発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記呼に付与可能な付加サービスを提供するアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求するための呼制御プログラムであり、コンピュータに、前記発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記発信元装置と該発信元装置によって利用可能でありかつ前記呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報であるアプリケーションサーバ識別情報を記憶するアプリケーションサーバ識別情報記憶ステップと、前記発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記アプリケーションサーバ識別情報記憶ステップにおいて記憶されたアプリケーションサーバ識別情報を参照し、前記付加サービスを提供可能なアプリケーションサーバを選択するアプリケーションサーバ選択ステップと、前記アプリケーションサーバ選択ステップにおいて選択されたアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する付加サービス提供要求ステップと、前記付加サービス提供要求ステップにおいてサービスの提供を要求したアプリケーションサーバから、前記付加サービスを提供できないことを示すエラー応答を受信した場合または前記アプリケーションサーバから応答が無かった場合、該アプリケーションサーバごとに設定された呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する呼継続判定ステップと、前記呼継続判定ステップにおいて呼を確立するための処理を継続すると判定した場合に、該付加サービスを付与せずに呼を確立するための呼確立要求を着信先装置へ向けて送信する呼確立要求ステップと、を実行させることを特徴とする呼制御プログラムが用いられている。このプログラムを採用すれば、アプリケーションサーバからエラー応答が返信される場合や無応答の場合に、ユーザの意思を考慮しつつ呼の確立を継続するか否かを適切に処理することができる。

（まとめ）
以上説明したように、サービスの提供を要求したアプリケーションサーバから、エラー応答を受信した場合または応答が無かった場合、アプリケーションサーバごとに設定された呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定することによって、呼の確立を継続するか否かを適切に処理することができる。サービスによっては呼の継続を行わせたくないサービスが存在する可能性があるため、本実施形態によれば、ユーザに適用するサービス毎に呼の確立処理を継続するか、処理を終了するか、適切に判定することができる。

アプリケーションサーバの障害・輻輳時に付加サービスの適用ができない場合でも、ユーザが希望する場合には、その意思にしたがって呼の確立処理を継続できる。また、ユーザに適用するサービス毎に、呼の確立処理を継続する、または呼の確立処理を終了する判定を行うことにより、ユーザの契約サービスに基づく制御が可能になる。さらに、今後、付加サービスが追加された場合、ＨＳＳがサービス契約情報を記憶し、ＨＳＳでユーザに適用されるサービス毎に呼継続情報を生成するため、Ｓ−ＣＳＣＦでサービスを意識せずに呼制御を行うことができる。

そして、上述した呼制御装置を用いることにより、地震、津波、洪水、台風などの災害発生時などにおいて、付加サービスを利用できない場合でも呼を確立することができ、安否確認のための通話を行うことができる。
なお、本発明の範囲は、図示され記載された例示的な実施形態に限定されるものではなく、本発明が目的とするものと均等な効果をもたらすすべての実施形態をも含む。さらに、本発明の範囲は、請求項により画される発明の特徴の組み合わせに限定されるものではなく、すべての開示されたそれぞれの特徴のうち特定の特徴のあらゆる所望する組み合わせによって画されうる。

本発明は、呼に付与可能な付加サービスを提供するアプリケーションサーバへ、サービスの提供を要求する呼制御装置を実現する場合に利用することができる。

１、１０ 呼制御装置（Ｓ−ＣＳＣＦ）
３ ＨＳＳ
４ 発信元装置
５ 着信先装置
１１ アプリケーションサーバ識別情報記憶部
１２ アプリケーションサーバ選択部
１３ 付加サービス提供要求部
１４ 呼継続情報記憶部
１５ 呼継続判定部
１６ 呼確立要求部
１７ アプリケーションサーバ識別情報取得部
１８ 呼継続情報取得部
２１、２２ アプリケーションサーバ
５０ 接続先対地
１００ アプリケーションサーバ識別情報
２００ 呼継続情報
Ｔ 付加サービス情報テーブル

Claims (9)

1. 発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記呼に付与可能な付加サービスを提供するアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する呼制御装置であって、
   前記呼確立要求を受信した場合に、前記発信元装置と該発信元装置によって利用可能でありかつ前記呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報であるアプリケーションサーバ識別情報を記憶するアプリケーションサーバ識別情報記憶部と、
   前記呼確立要求を受信した場合に、前記アプリケーションサーバ識別情報記憶部に記憶されているアプリケーションサーバ識別情報を参照し、前記付加サービスを提供可能なアプリケーションサーバを選択するアプリケーションサーバ選択部と、
   前記アプリケーションサーバ選択部が選択したアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する付加サービス提供要求部と、
   前記付加サービス提供要求部がサービスの提供を要求したアプリケーションサーバから、前記付加サービスを提供できないことを示すエラー応答を受信した場合または前記アプリケーションサーバから応答が無かった場合、該アプリケーションサーバごとに設定された呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する呼継続判定部と、
   前記呼継続判定部が呼を確立するための処理を継続すると判定した場合に、該付加サービスを付与せずに呼を確立するための呼確立要求を着信先装置へ向けて送信する呼確立要求部と、
   を備えることを特徴とする呼制御装置。
2. 前記アプリケーションサーバが複数である場合において、
   前記呼継続情報は、前記付加サービスを提供できないことを示すエラー応答を受信した場合または前記アプリケーションサーバから応答が無かった場合に、呼を確立するための処理を継続するか否かを、アプリケーションサーバごとに定めた情報であり、
   前記呼継続判定部は、前記呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定することを特徴とする請求項１に記載の呼制御装置。
3. 前記アプリケーションサーバ選択部は、複数の前記アプリケーションサーバのうちの１つから前記エラー応答を受信した場合または複数の前記アプリケーションサーバのうちの１つから応答が無かった場合に、複数の前記アプリケーションサーバのうちの他のアプリケーションサーバを選択し、
   前記付加サービス提供要求部は、前記アプリケーションサーバ選択部が選択した、前記他のアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求することを特徴とする請求項１又は２に記載の呼制御装置。
4. 前記呼継続情報は、複数の前記アプリケーションサーバのうち、あるアプリケーションサーバから応答が無かった場合に呼を確立するための処理を継続すると判定され、かつ、他のアプリケーションサーバから応答が無かった場合に呼を確立するための処理を継続しないと判定された場合に、いずれの判定を優先するかを示す優先情報に基づいて生成されるものであり、
   前記呼継続判定部は、複数の前記アプリケーションサーバから、前記エラー応答を受信した場合または応答が無かった場合に、前記呼継続情報に基づいて、呼を確立するための処理を継続するか否かを判定し、
   前記呼確立要求部は、前記呼継続判定部が呼を確立するための処理を継続すると判定した場合には前記呼確立要求を着信先装置へ向けて送信することを特徴とする請求項２又は３に記載の呼制御装置。
5. 前記呼継続情報は、前記発信元装置のユーザごとに設定された情報であり、前記呼継続判定部は、呼を確立するための処理を継続するか否かを、前記発信元装置のユーザごとに判定することを特徴とする請求項１から請求項４までのいずれか１項に記載の呼制御装置。
6. 前記発信元装置に対応する加入者情報を管理する加入者情報管理装置から、前記呼継続情報を取得する呼継続情報取得部と、
   前記呼継続情報取得部によって取得された呼継続情報を記憶する呼継続情報記憶部と、をさらに備え、
   前記呼継続判定部は、前記呼継続情報記憶部に記憶されている呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定することを特徴とする請求項１から請求項５までのいずれか１項に記載の呼制御装置。
7. 前記呼継続判定部は、災害が発生したことを示す情報が自装置に入力された場合には、呼を確立するための処理を継続すると判定することを特徴とする請求項１から請求項６までのいずれか１項に記載の呼制御装置。
8. 発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記呼に付与可能な付加サービスを提供するアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する呼制御方法であって、
   前記呼確立要求を受信した場合に、前記発信元装置と該発信元装置によって利用可能でありかつ前記呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報であるアプリケーションサーバ識別情報を記憶するアプリケーションサーバ識別情報記憶ステップと、
   前記呼確立要求を受信した場合に、前記アプリケーションサーバ識別情報記憶ステップにおいて記憶されたアプリケーションサーバ識別情報を参照し、前記付加サービスを提供可能なアプリケーションサーバを選択するアプリケーションサーバ選択ステップと、
   前記アプリケーションサーバ選択ステップにおいて選択されたアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する付加サービス提供要求ステップと、
   前記付加サービス提供要求ステップにおいてサービスの提供を要求したアプリケーションサーバから、前記付加サービスを提供できないことを示すエラー応答を受信した場合または前記アプリケーションサーバから応答が無かった場合、該アプリケーションサーバごとに設定された呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する呼継続判定ステップと、
   前記呼継続判定ステップにおいて呼を確立するための処理を継続すると判定した場合に、該付加サービスを付与せずに呼を確立するための呼確立要求を着信先装置へ向けて送信する呼確立要求ステップと、
   を含むことを特徴とする呼制御方法。
9. 発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記呼に付与可能な付加サービスを提供するアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求するための呼制御プログラムであって、
   コンピュータに、
   前記発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記発信元装置と該発信元装置によって利用可能でありかつ前記呼に付与可能な付加サービスを提供するアプリケーションサーバとの対応を示す情報であるアプリケーションサーバ識別情報を記憶するアプリケーションサーバ識別情報記憶ステップと、
   前記発信元装置から、呼を確立するための呼確立要求を受信した場合に、前記アプリケーションサーバ識別情報記憶ステップにおいて記憶されたアプリケーションサーバ識別情報を参照し、前記付加サービスを提供可能なアプリケーションサーバを選択するアプリケーションサーバ選択ステップと、
   前記アプリケーションサーバ選択ステップにおいて選択されたアプリケーションサーバへ、該アプリケーションサーバが提供するサービスの提供を要求する付加サービス提供要求ステップと、
   前記付加サービス提供要求ステップにおいてサービスの提供を要求したアプリケーションサーバから、前記付加サービスを提供できないことを示すエラー応答を受信した場合または前記アプリケーションサーバから応答が無かった場合、該アプリケーションサーバごとに設定された呼継続情報に基づき、呼を確立するための処理を継続するか否かを判定する呼継続判定ステップと、
   前記呼継続判定ステップにおいて呼を確立するための処理を継続すると判定した場合に、該付加サービスを付与せずに呼を確立するための呼確立要求を着信先装置へ向けて送信する呼確立要求ステップと、
   を実行させることを特徴とする呼制御プログラム。

Images