(57)【要約】【課題】  基本サービスの実行サーバから付加サービスの実行サーバへのルーティング情報を効率良く管理する。【解決手段】  本発明は、ユーザ端末に基本サービスを提供する第１のサーバが、付加サービスに係るサービス要求を、付加サービスを提供する第２のサーバへ転送するＩＰ通信システムに関する。データベースは、転送の必要性や転送条件などのルーティング情報の、ユーザを問わずに適用可能な識別子で識別される複数のセットを格納し、また、各ユーザに固有のルーティング情報と、そのユーザに適用するルーティング情報セットの識別子とでなるユーザプロファイルを格納する。第１のサーバは、ルーティング情報の全てのセットをローカルに保持し、付加サービスの要求を受信すると、データベースから、該当ユーザのプロファイルを取込み、そのプロファイルの識別子部分をルーティング情報のセットに戻して、転送の必要性などを判定する。【選択図】      図１
2008131086.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ端末に対して基本サービスを提供する基本サービス実行サーバと、ユーザ端末に対して付加サービスを提供する付加サービス実行サーバとを備え、上記基本サービス実行サーバが、受信したサービス要求が付加サービスに係る要求の場合に、ルーティング情報管理データベースの格納内容に従い、転送が必要であれば、該当する付加サービス実行サーバへサービス要求を転送するＩＰ通信システムにおいて、
上記ルーティング情報管理データベースは、
ユーザを問わずに適用可能な、上記付加サービス実行サーバへサービス要求を転送しても良いか否かの情報や転送する際の条件などでなるルーティング情報の、セット識別子で識別される複数のセットと、
各ユーザ毎に、そのユーザに固有のルーティング情報と、そのユーザに適用するルーティング情報のセットに付与されているセット識別子とでなるサービスプロファイルとを少なくとも格納しており、
上記基本サービス実行サーバは、
上記ルーティング情報管理データベースから、上記ルーティング情報の全てのセットをダウンロードしてローカルに保持しておき、
受信したサービス要求が付加サービスに係る要求の場合に、上記ルーティング情報管理データベースから、受信したサービス要求に係るユーザのサービスプロファイルを取込み、そのサービスプロファイルのセット識別子の記述とローカル保持の上記ルーティング情報の全てのセットとに基づいて、セット識別子の部分をルーティング情報に戻し、ユーザに固有のルーティング情報と共に、該当する上記付加サービス実行サーバへの受信サービス要求の転送の必要性を判定する
ことを特徴とするＩＰ通信システム。
【請求項２】
上記ルーティング情報のセットに対応できない第２の基本サービス実行サーバを備え、
上記ルーティング情報管理データベースは、上記第２の基本サービス実行サーバから、特定ユーザのサービスプロファイルが要求されたときには、そのサービスプロファイルのセット識別子の記述と格納している上記ルーティング情報の全てのセットとに基づいて、セット識別子の部分をルーティング情報に戻し、ユーザに固有のルーティング情報と共に、上記第２の基本サービス実行サーバに返答し、
上記第２の基本サービス実行サーバは、上記ルーティング情報管理データベースから返答されたルーティング情報に基づき、上記付加サービス実行サーバへの受信サービス要求の転送の必要性を判定する
ことを特徴とする請求項１に記載のＩＰ通信システム。
【請求項３】
付加サービスの種類毎に、上記ルーティング情報のセットが設けられていることを特徴とする請求項１又は２に記載のＩＰ通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＩＰ通信システムに関し、例えば、ＩＭＳ（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ）ネットワークに適用し得るものである。
【背景技術】
【０００２】
ＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を利用したマルチメディア通信システムの研究、開発が進められており、Ａｌｌ−ＩＰベースの次世代の移動体通信網を検討する団体３ＧＰＰのマルチメディア通信システムはＩＭＳ（ＩＭＳネットワーク）と呼ばれている。ＩＭＳネットワークにおいては、プレゼンスサービス、会議電話等の付加サービスは、アプリケーションサーバ（以下、ＡＳと呼ぶ）で提供される。そのため、ユーザに対してサービスを提供するための中心的なＳＩＰサーバであるＳ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）では、該当呼が付加サービスを要求していると認識した場合には、受信した信号などをＡＳにルーティングし、ＡＳとのセッションを開始する必要がある。この付加サービスの認識には、Ｉｎｉｔｉａｌ  Ｆｉｌｔｅｒ  Ｃｒｉｔｅｒｉａ（以下では、「ｉＦＣ」と呼ぶ）が使用されるが、Ｓ−ＣＳＣＦは、ｉＦＣを、ユーザの認証情報やサービス情報を保持するデータベースであるＨＳＳ（Ｈｏｍｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）から取得する（非特許文献１参照）。
【０００３】
以下、従来における、Ｓ−ＣＳＣＦがｉＦＣをＨＳＳから取得する処理やｉＦＣを用いてルーティングする処理を含めたユーザ端末（ＵＥ）の一連の登録動作を、図２を参照しながら説明する。なお、図２においては、ユーザ端末（ＵＥ）からＳ−ＣＳＣＦまでの間にある装置を省略している。
【０００４】
（Ｔ１）ユーザＡのＵＥ１０が、電源投入等により、Ｓ−ＣＳＣＦ１１に対しＲＥＧＩＳＴＥＲ登録を要求する（Ｓ１０１）。Ｓ−ＣＳＣＦ１１は、最初のＲＥＧＩＳＴＥＲ信号を受信したときには、認証ベクトルを保有していないため、ＨＳＳ１２から得ると共に、ＵＥ１０に認証要求するため、４０１ｕｎａｕｔｈｏｒｉｚｅｄレスポンスを返信する（Ｓ１０２〜Ｓ１０４）。
【０００５】
（Ｔ２）ＵＥ１０は、Ｓ−ＣＳＣＦ１１から認証要求されたため、認証情報を設定したＲＥＧＩＳＴＥＲ信号をＳ−ＣＳＣＦ１１に送信し、これにより、Ｓ−ＣＳＣＦ１１は、認証を行うと共に、ＨＳＳ１２にユーザのサービスプロファイル（適宜、ユーザプロファイルとも呼ぶ）を要求して、ｉＦＣを含むユーザプロファイルを取り込む（Ｓ１０５〜Ｓ１０８）。図３には、ユーザプロファイルの一例のイメージを示している。図３において、タグ＜ＩｎｉｔｉａｌＦｉｌｔｅｒＣｒｉｔｅｒｉａ＞とタグ＜／ＩｎｉｔｉａｌＦｉｌｔｅｒＣｒｉｔｅｒｉａ＞とで挟まれた部分がｉＦＣになっている。
【０００６】
（Ｔ３）Ｓ−ＣＳＣＦ１１は、ユーザＡが登録されている間（ＲＥＧＩＳＴＥＲが有効な期間）はｉＦＣを保持し、この保持期間にリクエスト信号を受信した場合、このｉＦＣを使用し、付加サービスの有無（ＡＳへのルーティング要否）を決定する（Ｓ１０９）。
【０００７】
（Ｔ４）Ｓ−ＣＳＣＦ１１は、ユーザＡから受信したＲＥＧＩＳＴＥＲ信号（Ｓ１０５参照）の内容とユーザＡのｉＦＣを比較し（Ｓ１１０）、ＡＳ１３へのルーティングが必要な場合には、ＵＥ１０にＲＥＧＩＳＴＥＲ信号の受信応答（２００ＯＫ）を返信すると共に、ＡＳ１３にＲＥＧＩＳＴＥＲ信号をルーティングする（Ｓ１１１、Ｓ１１２）。
【０００８】
（Ｔ５）これ以降も、ユーザＡに関するリクエスト信号（ユーザＡからの送信又はユーザＡへの送信）をＳ−ＣＳＣＦが受信した場合には、上述の（Ｔ４）と同様に、信号の内容とｉＦＣとを比較し、ＡＳ１３へのルーティングの要否を決定する。
【０００９】
しかしながら、上記方式では、各ユーザのサービスプロファイルに、全付加サービスのＡＳルーティング条件をｉＦＣに記述する必要があり、下記の問題点Ｐ１〜Ｐ３が存在する。
【００１０】
Ｐ１：Ｓ−ＣＳＣＦとＨＳＳ間の通信データ量が多くなり、トラフィックに影響を与える。
【００１１】
Ｐ２：Ｓ−ＣＳＣＦで保持する情報が多くなるため、Ｓ−ＣＳＣＦのリソースを大量に消費する。
【００１２】
Ｐ３：サービス条件の変更等が発生した場合（例えば、ＡＳのＳＩＰ  ＵＲＬを変更する等）に、全てのユーザのｉＦＣを変更する必要がある。
【００１３】
これらの問題点を解決するために、Ｓｈａｒｅｄ  Ｉｎｉｔｉａｌ  Ｆｉｌｔｅｒ  Ｃｒｉｔｅｒｉａ機能（以下、ＳｉＦＣ機能と呼ぶ）が、オプション機能として定義されている。ＳｉＦＣ機能は、複数のユーザで共通のデータは事前にＳ−ＣＳＣＦで保持し（ローカルに保持し）、各ユーザのサービスプロファイルには、その共通データの識別子のみを設定するだけで、全データをユーザのｉＦＣに設定してダウンロードする場合と同様の情報をＳ−ＣＳＣＦで得ることが可能となる。
【００１４】
図４に、ＳｉＦＣ機能の詳細イメージを示す。ユーザのサービスプロファイルの中には、Ｓｈａｒｅｄ  ｉＦＣ  ｓｅｔｓ（３０１）を記述できるようになされており（図４（Ａ）の３０１）、サービスプロファイルで、Ｓｈａｒｅｄ  ｉＦＣ  ｓｅｔｓの識別子を指定することにより（図４（Ｂ）の３０２）、Ｓ−ＣＳＣＦでローカルに保持しているｉＦＣの複数のセット（図４（Ｃ）の３０３）の中から、該当の識別子のセット（図４（Ｃ）の３０４）が取り出され、このセットとユーザ単位のｉＦＣ（図４（Ｂ）の３０５）とを組み合わせて、ＡＳルーティングの情報とすることが可能である（図４（Ｄ）の３０６）。
【非特許文献１】３ＧＰＰ  ＴＳ２９．２２８  Ｖ７．０．０（ＩＰ  Ｍｕｌｔｉｍｅｄｉａ  （ＩＭ）  Ｓｕｂｓｙｓｔｅｍ  Ｃｘ  ａｎｄ  Ｄｘ  Ｉｎｔｅｒｆａｃｅｓ：  Ｓｉｇｎａｌｌｉｎｇ  ｆｌｏｗｓ  ａｎｄ  ｍｅｓｓａｇｅ  ｃｏｎｔｅｎｔｓ）
【発明の開示】
【発明が解決しようとする課題】
【００１５】
しかしながら、３ＧＰＰでは、ｉＦＣの作成方式や、Ｓ−ＣＳＣＦでの保持方式について、詳細を定めていない。そのため、アプリケーションサーバへのルーティング情報をどのようにしたら効率良く管理できるかが問題となっている。
【００１６】
本発明では、以上の点に鑑みなされたものであり、付加サービス実行サーバへのルーティング情報を効率良く管理でき、かつ、基本サービス実行サーバが迅速にルーティング情報を取得できるＩＰ通信システムを提供しようとしたものである。
【課題を解決するための手段】
【００１７】
かかる課題を解決するため、本発明は、ユーザ端末に対して基本サービスを提供する基本サービス実行サーバと、ユーザ端末に対して付加サービスを提供する付加サービス実行サーバとを備え、上記基本サービス実行サーバが、受信したサービス要求が付加サービスに係る要求の場合に、ルーティング情報管理データベースの格納内容に従い、転送が必要のときに、該当する付加サービス実行サーバへサービス要求を転送するＩＰ通信システムにおいて、（１）上記ルーティング情報管理データベースは、（１−１）ユーザを問わずに適用可能な、上記付加サービス実行サーバへサービス要求を転送しても良いか否かの情報や転送する際の条件などでなるルーティング情報の、セット識別子で識別される複数のセットと、（１−２）各ユーザ毎に、そのユーザに固有のルーティング情報と、そのユーザに適用するルーティング情報のセットに付与されているセット識別子とでなるサービスプロファイルとを少なくとも格納しており、（２）上記基本サービス実行サーバは、（２−１）上記ルーティング情報管理データベースから、上記ルーティング情報の全てのセットをダウンロードしてローカルに保持しておき、（２−２）受信したサービス要求が付加サービスに係る要求の場合に、上記ルーティング情報管理データベースから、受信したサービス要求に係るユーザのサービスプロファイルを取込み、そのサービスプロファイルのセット識別子の記述とローカル保持の上記ルーティング情報の全てのセットとに基づいて、セット識別子の部分をルーティング情報に戻し、ユーザに固有のルーティング情報と共に、該当する上記付加サービス実行サーバへの受信サービス要求の転送の必要性を判定することを特徴とする。
【発明の効果】
【００１８】
本発明によれば、ルーティング情報管理データベースがルーティング情報を一元管理するので、付加サービス実行サーバへのルーティング情報を効率良く管理でき、かつ、基本サービス実行サーバが迅速にルーティング情報を取得することができる。
【発明を実施するための最良の形態】
【００１９】
（Ａ）実施形態
以下、本発明によるＩＰ通信システムを、ＩＭＳネットワークに適用した一実施形態を、図面を参照しながら詳述する。
【００２０】
（Ａ−１）実施形態の構成
図５は、実施形態に係るＩＭＳネットワークの構成例を示すブロック図である。図５において、ＩＭＳネットワーク１は、ユーザ端末（ＵＥ）２−１、２−２、Ｐ−ＣＳＣＦ（Ｐｒｏｘｙ  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）３、Ｉ−ＣＳＣＦ（Ｉｎｔｅｒｒｏｇａｔｉｎｇ  Ｃａｌｌ  Ｓｅｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）４−１、４−２、Ｓ−ＣＳＣＦ６−１〜６−３、ＨＳＳ７及びアプリケーションサーバ（ＡＳ）８を有する。
【００２１】
ユーザ端末（ＵＥ）２−１、２−２は、無線端末及び有線端末のいずれであっても良く、網側にサービスを要求し、サービスの提供を受けるものである。なお、ユーザ端末２−１、２−２が無線端末であれば図示しないアクセスポイント装置などを介してＰ−ＣＳＣＦ３に収容される。ユーザ端末２−１、２−２には、この実施形態の特徴はないので、その詳細構成の説明は省略する。
【００２２】
Ｐ−ＣＳＣＦ３は、ユーザ端末２（２−１、２−２）が網へアクセスするための最初に接続されるＣＳＣＦである。Ｐ−ＣＳＣＦ３は、ユーザ端末２に対して、いわゆるアウトバウンドプロキシサーバの役割を担っている。ネットワークに接続するユーザ端末２は、全てのＳＩＰメッセージの送受信をそのときに割り当てられているＰ−ＣＳＣＦ３を介して行うものであり、Ｐ−ＣＳＣＦ３は、ユーザ端末２との間でメッセージの暗号化や圧縮を行うと共に、ユーザ端末２が設定するヘッダの正当性をチェックし、不正なメッセージがネットワークに対して送信されないことを保証する役割なども担っている。Ｐ−ＣＳＣＦ３には、この実施形態の特徴はないので、その詳細構成の説明は省略する。
【００２３】
Ｉ−ＣＳＣＦ４−１、４−２は、他網との間でＳＩＰメッセージを授受するためのプロキシサーバである。Ｉ−ＣＳＣＦ４−１、４−２は、主に、受信したメッセージの内容から、自網内の適切なＳ−ＣＳＣＦ３に対してメッセージを転送する役割を担っている。この実施形態の場合、Ｉ−ＣＳＣＦ４−１、４−２の詳細構成や処理は従来のものと同様であるので、その説明は省略する。
【００２４】
この実施形態においても、Ｓ−ＣＳＣＦ６（６−１〜６−３）は、基本的には、ユーザに対して各種サービスを提供するための中心的なＳＩＰサーバであり、ＨＳＳ７は、ユーザの認証情報やサービス情報（後述する図１参照）などを保持するユーザ管理データベースであり、アプリケーションサーバ８は、プレゼンスサービス、会議電話等の付加サービスを提供するものである。
【００２５】
しかしながら、この実施形態の場合、Ｓ−ＣＳＣＦ６−１〜６−３及びＨＳＳ７が、従来のものと異なっている。以下、その点を説明する。なお、Ｓ−ＣＳＣＦ６（６−１〜６−３）は、ハードウェア的には通信機能を有する１台又が複数台の情報処理装置によって構成されているが、機能的には、以下に説明する機能を実現するように構成されており、その機能は主として搭載されているアプリケーションプログラムにより実行される。同様に、ＨＳＳ７は、ハードウェア的には通信機能を有する１台又が複数台の情報処理装置によって構成されているが、機能的には、以下に説明する機能を実現するように構成されており、その機能は主として搭載されているアプリケーションプログラムにより実行される。
【００２６】
以下の説明では、Ｓ−ＣＳＣＦ６−１及び６−２がＳｉＦＣ機能に対応しているＳ−ＣＳＣＦであり、Ｓ−ＣＳＣＦ６−３がＳｉＦＣ機能に未対応のＳ−ＣＳＣＦとする。
【００２７】
これらＳ−ＣＳＣＦ６−１〜６−３が信号をアプリケーションサーバ８へルーティングするための情報については、マスタとなるデータを全て、ＨＳＳ７で設定している。また、ＳｉＦＣ機能に関し、Ｓ−ＣＳＣＦ６（６−１〜６−３）でローカルに保持されるデータについてもＨＳＳ７で管理し、必要時に、Ｓ−ＣＳＣＦ６がＨＳＳ７からデータを取得する。さらに、ユーザ単位のｉＦＣについては、各ユーザのユーザ端末２が、Ｓ−ＣＳＣＦ６に登録したときにＨＳＳ７からダウンロードされ、ユーザ端末２又は他ネットワーク５などからＳ−ＣＳＣＦ６にリクエスト信号が送信されてきた場合に、これらの情報より、Ｓ−ＣＳＣＦ６は、アプリケーションサーバ８へのルーティングを決定する。
【００２８】
図１は、ＨＳＳ７が保持している、アプリケーションサーバ８へのルーティングに関する情報ＩＮＦ１〜ＩＮＦ４を示している。
【００２９】
ＩＮＦ１：Ｓ−ＣＳＣＦのＳｉＦＣ機能対応表
図１（Ａ）に示すＳｉＦＣ機能対応表ＩＮＦ１は、各Ｓ−ＣＳＣＦ６−１〜６−３がＳｉＦＣ機能に対応しているか否かを記述しているものである。
【００３０】
ＳｉＦＣ機能は、オプション機能のため、ＳｉＦＣ対応機能を具備していないＳ−ＣＳＣＦ６−３では、ＳｉＦＣセット機能は使用されない。そのため、対応の有無によって、ＨＳＳ７からＳ−ＣＳＣＦ６に送信するユーザプロファイルの内容に差分がでるため、ＨＳＳ７で各Ｓ−ＣＳＣＦ６−１〜６−３のＳｉＦＣ機能の対応状況を把握している。
【００３１】
ＩＮＦ２：付加サービス／ＳｉＦＣセット対応表
図１（Ｂ）に示す付加サービス／ＳｉＦＣセット対応表ＩＮＦ２は、付加サービスの種類毎に、ＳｉＦＣセットの識別子を対応付けたものである。図１（Ｂ）の例では、「プレゼンスサービス」は識別子「２」に対応付けられている。
【００３２】
この実施形態の場合、付加サービス単位に、ＳｉＦＣセットを設定する。付加サービス毎に設定することにより、付加サービスの追加、変更又は削除時に、他のＳｉＦＣセットの設定に影響を与えずに設定することが可能になる。また、ユーザが付加サービスを追加契約したような場合であれば、該当のＳｉＦＣセットの識別子をそのユーザのサービスプロファイルに追加するだけで対応することができる。
【００３３】
ＩＮＦ３：ＳｉＦＣセットデータ群
図１（Ｃ）に示すように、識別子により区別される各ＳｉＦＣセットには、１又は複数のｉＦＣ（Ｉｎｉｔｉａｌ  Ｆｉｌｔｅｒ  Ｃｒｉｔｅｒｉａ）のデータが設定されている。例えば、識別子「２」のＳｉＦＣセットには、「プレゼンスサービス」に係る１又は複数のｉＦＣ（のデータ）が記述されている。
【００３４】
ＩＮＦ４：サービスプロファイル群
図１（Ｄ）に示すように、この実施形態の場合、各ユーザに係るサービスプロファイルには、そのユーザに係る固有のｉＦＣと、そのユーザに係るＳｉＦＣセットの識別子とが記述されている。
【００３５】
ユーザに固有のルーティング条件やルーティング情報が固有のｉＦＣに記述されるが、固有なルーティング条件やルーティング情報がない場合には、固有のｉＦＣは設定されない。ユーザに係るＳｉＦＣセットの識別子には、ユーザが契約している付加サービスに対応するＳｉＦＣセットの識別子が設定される。
【００３６】
ＨＳＳ７が管理、保持している、アプリケーションサーバ８へのルーティングに関する情報ＩＮＦ１〜ＩＮＦ４は、ＨＳＳ７に対する管理者などの操作や外部装置からの到来情報によって適宜更新することができる。以下では、付加サービスの追加時における情報ＩＮＦ１〜ＩＮＦ４の変動、及び、新規ユーザの追加時における情報ＩＮＦ１〜ＩＮＦ４の変動を、この順に説明する。
【００３７】
なお、ＨＳＳ７、又は、ＨＳＳ７に直接又は通信網を介して接続する図示しない保守・管理用端末は、上述したルーティングに関する情報ＩＮＦ１〜ＩＮＦ４を更新するためのプログラムを備え、管理者などが、ＨＳＳ７又は保守・管理用端末が有する表示手段に表示された更新用画面に対し、入力手段を用いて入力操作することにより、ＨＳＳ７が管理、保持している情報ＩＮＦ１〜ＩＮＦ４を更新（編集）させることができる。また、プロビジョニングシステムなどから与えられた情報に基づいて、ＨＳＳ７が管理、保持している情報ＩＮＦ１〜ＩＮＦ４を更新（編集）させることがある。
【００３８】
図６は、ＩＭＳネットワーク１で付加サービスを追加する場合におけるルーティングに関する情報ＩＮＦ１〜ＩＮＦ４の変動（設定）の様子を示す説明図である。
【００３９】
ＳｉＦＣセットデータＩＮＦ群３に対し、追加する付加サービスで用いられるＳｉＦＣセットデータ６０１を、未使用のＳｉＦＣセット識別子で設定する。その後、付加サービス／ＳｉＦＣセット対応表ＩＮＦ２に追加サービスとＳｉＦＣセット識別子とを対応付けて追加する。図６は、着信課金サービスに係る３種類のｉＦＣを、ＳｉＦＣセットデータ６０１として、未使用の識別子「１１」を付与して設定すると共に、付加サービス／ＳｉＦＣセット対応表ＩＮＦ２に対しては、「着信課金サービス」に識別子「１１」を対応付けて設定した例を示している。
【００４０】
図示は省略するが、付加サービスを中止する際には、管理者などは、付加サービス／ＳｉＦＣセット対応表ＩＮＦ２から、中止する付加サービスに係る行の情報を削除すると共に、ＳｉＦＣセットデータＩＮＦ群３からも中止する付加サービスに係るＳｉＦＣセットデータを削除する。但し、削除の場合は全てのユーザが該当サービスの契約を行っていないことが削除可能な条件とする必要がある（全てのユーザのサービスプロファイルのＳｉＦＣセットに該当のＳｉＦＣ識別子が設定されていないことを条件とする）。なお、該当サービスの契約を行っているユーザがいて中止に承認を与えた場合であれば、サービスプロファイル群ＩＮＦ４の該当ユーザのサービスプログラムファイルから、中止する付加サービスのＳｉＦＣデータセットのＳｉＦＣ識別子を削除する。
【００４１】
図７は、新規ユーザの追加時におけるルーティングに関する情報ＩＮＦ１〜ＩＮＦ４の変動（設定）の様子を示す説明図である。
【００４２】
プロビジョニングシステム等より新規ユーザの付加サービスの提供条件及びユーザ独自の動作条件がその他の必要データ（ユーザＩＤ等）と共にＨＳＳ７に送信される。例えば、定時処理（例えば１日数回の定時処理）として供給される。ＨＳＳ７では、新規ユーザの到来データの中に、付加サービスの契約がある場合には、付加サービス／ＳｉＦＣセット対応表ＩＮＦ２から、契約付加サービスに対応するＳｉＦＣセット識別子を取得し、ユーザプロファイルのＳｉＦＣセットの識別子の欄に設定する。新規ユーザに独自の条件がある場合には、そのユーザのｉＦＣを作成して設定する。
【００４３】
図示は省略するが、既存ユーザに対して、付加サービスの追加や削除を行う場合においても、付加サービスに対応するＳｉＦＣ識別子をユーザプロフファイルのＳｉＦＣセットの欄に追加したり削除したりすることで実現する。
【００４４】
（Ａ−２）実施形態の動作
次に、この実施形態のＩＭＳネットワーク１におけるＳ−ＣＳＣＦ６がアプリケーションサーバ８へのルーティング情報を取得する際の処理を説明する。
【００４５】
図８は、ＳｉＦＣ機能対応のＳ−ＣＳＣＦ６−１がＳｉＦＣセットデータを初期収集（取得）する際のシーケンス図である。なお、ＳｉＦＣ機能未対応のＳ−ＣＳＣＦ６−３は、図８に示す収集処理を実行しない。
【００４６】
（Ｔ１１）ＳｉＦＣ機能対応のＳ−ＣＳＣＦ６−１は、自己のアプリケーション起動時に、そのアプリケーションに従って、ＨＳＳ７に対し、ＳｉＦＣセットデータを要求する（Ｓ８０１）。
【００４７】
（Ｔ１２）ＨＳＳ７は、要求元のＳ−ＣＳＣＦ６−１がＳｉＦＣ機能対応のＳ−ＣＳＣＦであることを確認した上で（図１（Ａ）参照）、全てのＳｉＦＣセットのデータ（図１（Ｃ）参照）を送信する（Ｓ８０２）。
【００４８】
（Ｔ１３）Ｓ−ＣＳＣＦ６−１は、ＨＳＳ７からのデータを受信し、自身のローカルデータベースに正常に設定が完了した時点で、Ｓ−ＣＳＣＦとしての機能を開始し、ユーザからのＳＩＰ信号の受信を開始する（Ｓ８０３）。
【００４９】
図９は、ＳｉＦＣ機能対応のＳ−ＣＳＣＦ６−１に追加されたＳｉＦＣセットデータを供給する際のシーケンス図である。なお、図９では、追加されたＳｉＦＣセットデータの識別子を「Ｘ＋１」で表している。
【００５０】
（Ｔ２１）付加サービスの追加等により、ＨＳＳ７に、ＳｉＦＣセットデータが追加された場合には（Ｓ９０１）は、ＨＳＳ７は、ＳｉＦＣ機能対応の全てのＳ−ＣＳＣＦ（６−１、６−２；図９では６−１のみ示している）に対し、ＳｉＦＣセットデータ群の変更通知を行う（Ｓ９０２）。
【００５１】
（Ｔ２２）変更通知を受信した各Ｓ−ＣＳＣＦ６−１、６−２は、ＨＳＳ７に対し、ＳｉＦＣセットデータの要求を行う（Ｓ９０３）。
【００５２】
（Ｔ２３）ＨＳＳ７は、要求されたＳ−ＣＳＣＦ６−１、６−２に、ＳｉＦＣセットデータを送信し（Ｓ９０４）、Ｓ−ＣＳＣＦ６−１、６−２は、ＨＳＳ７からのデータを受信し、自身のローカルデータベースに設定する（Ｓ９０５）。全てのＳ−ＣＳＣＦ６−１、６−２に対し、送信が完了した時点で、追加された付加サービスが有効となり、各ユーザに対して付加サービスの契約を追加することが可能となる。
【００５３】
図１０は、ＳｉＦＣ機能対応のＳ−ＣＳＣＦがアプリケーションサーバへのルーティング情報をダウンロードする処理を含めた、ＵＥの登録動作を示すシーケンス図である。
【００５４】
（Ｔ３１）ユーザ端末２がアクセスし得るＳｉＦＣ機能対応のＳ−ＣＳＣＦ６−１は、上述したように、アプリケーション起動時などに、ＨＳＳ７からＳｉＦＣセットデータをロードしている。
【００５５】
（Ｔ３２）Ｓ−ＣＳＣＦ６−１は、ユーザ端末２から、ＲＥＧＩＳＴＥＲ信号を受信した場合には（Ｓ１００１）、ＨＳＳ７と協働してユーザ認証を行うと共に、この認証時に、当該ユーザのサービスプロファイルを要求する（Ｓ１００２、Ｓ１００３）。
【００５６】
（Ｔ３３）このとき、ＨＳＳ７は、要求元のＳ−ＣＳＣＦ６−１がＳｉＦＣ機能対応であることを確認し、当該ＨＳＳ７で設定しているユーザプロファイルをそのままＳ−ＣＳＣＦ６−１に返送する（Ｓ１００４）。すなわち、ＨＳＳ７は、ユーザ固有のｉＦＣと、ユーザが契約している付加サービスを示すＳｉＦＣセット識別子とを返送する。なお、要求元のＳ−ＣＳＣＦ６−１がＳｉＦＣ機能に未対応である場合には、ユーザ固有のｉＦＣだけを返送する。
【００５７】
（Ｔ３４）Ｓ−ＣＳＣＦ６−１は、ユーザ端末２にＲＥＧＩＳＴＥＲ信号の受信を応答すると共に、そのＲＥＧＩＳＴＥＲ信号の内容と、ユーザプロファイルの内容（ユーザ固有のｉＦＣと、ＳｉＦＣセット識別子に係るＳｉＦＣセットデータ）とを比較し（Ｓ１００５）、アプリケーションサーバ８へのルーティングが必要な場合には、アプリケーションサーバ８にＲＥＧＩＳＴＥＲ信号をルーティングする（Ｓ１００６）。
【００５８】
（Ｔ３５）図１０では省略しているが、これ以降も、ＳｉＦＣ機能対応のＳ−ＣＳＣＦ６−１は、ユーザに関する信号（ユーザからの送信又はユーザへの送信）があった場合には、上述の（Ｔ３２）〜（Ｔ３４）と同様に、信号の内容とユーザプロファイルの内容（ユーザ固有のｉＦＣと、ＳｉＦＣセット識別子に係るＳｉＦＣセットデータ）とを比較し、アプリケーションサーバ８へのルーティングの要否を決定する。
【００５９】
図１１は、ＳｉＦＣ機能未対応のＳ−ＣＳＣＦがアプリケーションサーバへのルーティング情報をダウンロードする処理を含めた、ＵＥの登録動作を示すシーケンス図である。
【００６０】
（Ｔ４１）ユーザ端末２がアクセスし得るＳ−ＣＳＣＦがＳｉＦＣ機能未対応のＳ−ＣＳＣＦ６−３であるとする。
【００６１】
（Ｔ４２）Ｓ−ＣＳＣＦ６−３は、ユーザ端末２から、ＲＥＧＩＳＴＥＲ信号を受信した場合には（Ｓ１１０１）、ＨＳＳ７と協働してユーザ認証を行うと共に、この認証時に、当該ユーザのサービスプロファイルを要求する（Ｓ１１０２、Ｓ１１０３）。
【００６２】
（Ｔ４３）このとき、ＨＳＳ７は、要求元のＳ−ＣＳＣＦ６−３がＳｉＦＣ機能未対応であることを確認し、当該ＨＳＳ７で該当ユーザのサービスプロファイルを確認し、サービスプロファイル内のＳｉＦＣセット識別子に対応するＳｉＦＣセットデータを収集し、この収集データと、ユーザ固有のｉＦＣとを合わせて、ユーザのサービスプロファイルの内容（ｉＦＣの全体）としてＳ−ＣＳＣＦ６−３に返送する（Ｓ１１０４）。
【００６３】
（Ｔ４４）Ｓ−ＣＳＣＦ６−３は、ユーザ端末２にＲＥＧＩＳＴＥＲ信号の受信を応答すると共に、そのＲＥＧＩＳＴＥＲ信号の内容と、ユーザプロファイルの内容（ユーザ固有のｉＦＣと、ＳｉＦＣセット識別子に係るＳｉＦＣセットデータ）とを比較し（Ｓ１１０５）、アプリケーションサーバ８へのルーティングが必要な場合には、アプリケーションサーバ８にＲＥＧＩＳＴＥＲ信号をルーティングする（Ｓ１１０６）。
【００６４】
（Ｔ４５）図１１では省略しているが、これ以降も、ＳｉＦＣ機能未対応のＳ−ＣＳＣＦ６−３は、ユーザに関する信号（ユーザからの送信又はユーザへの送信）があった場合には、上述の（Ｔ４２）〜（Ｔ４４）と同様に、信号の内容とユーザプロファイルの内容とを比較し、アプリケーションサーバ８へのルーティングの要否を決定する。
【００６５】
（Ａ−３）実施形態の効果
以上のように、上記実施形態によれば、ＳｉＦＣ機能を実施する場合においてもＨＳＳで、アプリケーションサーバへのルーティング情報を一元管理することが可能となり、情報の設定、管理の手順を減らすことができる。すなわち、付加サービスの増減や、ユーザの増減時に、管理者などが操作しなければならない情報を減らすことができる。
【００６６】
また、上記実施形態によれば、付加サービス単位にＳｉＦＣセットデータを作成することにより、付加サービスの増減等によるアプリケーションサーバへのルーティング情報の設定変更時に、該当サービスのデータを増減するのみで良く、他の付加サービスのデータに影響を与えることなく設定が可能となる。さらに、ユーザへの契約サービスを追加するような場合等でも、各ユーザプロファイルのＳｉＦＣセットデータに該当サービスのＳｉＦＣ識別子を設定するのみで可能となる。
【００６７】
以上のように、上記実施形態では、付加サービスの変更（追加、削除、変更）時のデータ設定の手順が簡素化でき、かつ、柔軟にデータ設定ができるという効果が得られる。
【００６８】
（Ｂ）他の実施形態
図５では、アプリケーションサーバが１台のものを示したが、複数台あっても良いことは勿論である。同様に、ＨＳＳも複数台あっても良い。但し、各Ｓ−ＣＳＣＦに対応するＨＳＳは１個であることを要する。
【００６９】
上記実施形態においては、この実施形態の特徴をなす情報ＩＮＦ１〜ＩＮＦ４をＨＳＳが備えるものを示したが、ＨＳＳとは異なるデータベースに格納しておくようにしても良い。
【００７０】
また、上記実施形態では、本発明によるＩＰ通信システムを、ＩＭＳネットワークに適用した場合を示したが、他のネットワークに対しても本発明を適用することができる。但し、基本サービス実行サーバ（実施形態のＳ−ＣＳＣＦに相当）と付加サービス実行サーバ（実施形態のアプリケーションサーバが相当）が存在し、基本サービス実行サーバが受信したサービス要求が付加サービスに係る要求の場合に付加サービス実行サーバへサービス要求を転送するＩＰ通信システムであることを要する。
【図面の簡単な説明】
【００７１】
【図１】実施形態のＨＳＳが保持している、アプリケーションサーバへのルーティングに関する情報を示す説明図である。
【図２】従来におけるユーザ端末（ＵＥ）の一連の登録動作を示すシーケンス図である。
【図３】従来のユーザ別のサービスプロファイルの一例のイメージを示す説明図である。
【図４】従来のＳｉＦＣ機能の詳細イメージを示す説明図である。
【図５】実施形態に係るＩＭＳネットワークの構成例を示すブロック図である。
【図６】実施形態の付加サービスを追加する場合におけるルーティングに関する情報の変動（設定）の様子を示す説明図である。
【図７】実施形態の新規ユーザの追加時におけるルーティングに関する情報の変動（設定）の様子を示す説明図である。
【図８】実施形態のＳ−ＣＳＣＦがＳｉＦＣセットデータを初期収集（取得）する際のシーケンス図である。
【図９】実施形態のＳ−ＣＳＣＦが追加されたＳｉＦＣセットデータを取得する際のシーケンス図である。
【図１０】実施形態のＳｉＦＣ機能対応のＳ−ＣＳＣＦがアプリケーションサーバへのルーティング情報をダウンロードする処理を含む、ユーザ端末（ＵＥ）の一連の登録動作を示すシーケンス図である。
【図１１】実施形態のＳｉＦＣ機能未対応のＳ−ＣＳＣＦがアプリケーションサーバへのルーティング情報をダウンロードする処理を含む、ユーザ端末（ＵＥ）の一連の登録動作を示すシーケンス図である。
【符号の説明】
【００７２】
１：ＩＭＳネットワーク、２−１、２−２：ユーザ端末（ＵＥ）、３：Ｐ−ＣＳＣＦ、４−１、４−２：Ｉ−ＣＳＣＦ、６−１〜６−３：Ｓ−ＣＳＣＦ、７：ＨＳＳ、８：アプリケーションサーバ（ＡＳ）、ＩＮＦ１：Ｓ−ＣＳＣＦのＳｉＦＣ機能対応表、ＩＮＦ２：付加サービス／ＳｉＦＣセット対応表、ＩＮＦ３：ＳｉＦＣセットデータ群、ＩＮＦ４：サービスプロファイル群。
【図１】
2008131086.tif 000003
【図２】
2008131086.tif 000004
【図３】
2008131086.tif 000005
【図４】
2008131086.tif 000006
【図５】
2008131086.tif 000007
【図６】
2008131086.tif 000008
【図７】
2008131086.tif 000009
【図８】
2008131086.tif 000010
【図９】
2008131086.tif 000011
【図１０】
2008131086.tif 000012
【図１１】
2008131086.tif 000013