(57)【要約】【課題】ＩＰネットワークシステムにおいて、Ｓ−ＣＳＣＦがシステムダウンした場合であっても、確立されているクライアント端末とＡＳとの間の通信が中断されずサービスの提供が継続され、また、Ｓ−ＣＳＣＦがシステムダウンした際においてもクライアント端末とＡＳとの通信状態が維持され、Ｓ−ＣＳＣＦの回復後においてもクライアント端末が再度ＡＳに対してサービス要求メッセージを送信し接続を再確立することが必要ないネットワークシステム、仲介呼処理制御サーバー装置およびその呼処理方法を提供する。【解決手段】Ｉ−ＣＳＣＦが、Ｓ−ＣＳＣＦの運転状態を定期的に監視し、Ｓ−ＣＳＣＦの運転状態のシステムダウンを検出した場合には、Ｉ−ＣＳＣＦが、確立した通信におけるクライアント端末からＡＳへのメッセージを、メッセージに基づいてＡＳへ転送する。【選択図】図１
2007318629.tif 000002
【特許請求の範囲】
【請求項１】
プロキシ呼処理制御サーバー手段、仲介呼処理制御サーバー手段およびサービス制御用呼処理制御サーバー手段を有し、端末からの呼を受信し前記仲介呼処理制御サーバー手段へ転送する第１の転送手段を前記プロキシ呼処理制御サーバー手段が有し、前記プロキシ呼処理制御サーバーから受信した呼を前記サービス制御用呼処理制御サーバー手段へ転送する第２の転送手段を前記仲介呼処理制御サーバー手段が有し、前記仲介呼処理制御サーバー手段から受信した呼を前記呼の内容に基づき適切なアプリケーションサーバーヘ転送する第３の転送手段を前記サービス制御用呼処理制御サーバー手段が有する、前記端末と前記アプリケーションサーバーとの間の通信を確立するネットワークシステムであり、
前記仲介呼処理制御サーバー手段が、
前記サービス制御用呼処理制御サーバー手段の運転状態を予め定められた一定時間毎に監視する監視手段を有し、
前記仲介呼処理制御サーバー手段の前記第２の転送手段が、
前記サービス制御用呼処理制御サーバー手段がシステムダウンしたことを前記監視手段が検出した場合には、前記確立した通信における前記端末から前記アプリケーションサーバーへの呼を前記呼に基づいて前記アプリケーションサーバーへ転送する、
ことを特徴とするネットワークシステム。
【請求項２】
前記仲介呼処理制御サーバー手段が、
前記サービス制御用呼処理制御サーバー手段が回復したことを示す回復通知信号を前記サービス制御用呼処理制御サーバー手段から受信する回復通知信号受信手段を有し、
前記第２の転送手段が、前記回復通知信号受信手段が前記回復通知信号を受信した後は、前記確立した通信における前記端末から前記アプリケーションサーバーへの呼を、前記サービス制御用呼処理制御サーバー手段へ転送する、
ことを特徴とする請求項１に記載のネットワークシステム。
【請求項３】
前記ネットワークシステムが更に、前記仲介呼処理制御サーバー手段および前記サービス制御用呼処理制御サーバー手段から参照可能なデータベース手段を有しており、
前記サービス制御用呼処理制御サーバー手段が、
前記端末とアプリケーションサーバーとの間の通信状態を前記データベース手段に記録する第１の記録手段と、
前記記録した通信状態を前記データベース手段から参照する第１の参照手段と、
を有することを特徴とする請求項１から請求項２に記載のネットワークシステム。
【請求項４】
前記仲介呼処理制御サーバー手段が
前記端末とアプリケーションサーバーとの間の通信状態を前記データベース手段に記録する第２の記録手段と、
前記記録した通信状態を前記データベース手段から参照する第２の参照手段と、
を有することを特徴とする請求項３に記載のネットワークシステム。
【請求項５】
前記仲介呼処理制御サーバー手段の監視手段が、
監視信号を前記サービス制御用呼処理制御サーバー手段へ定期的に送信し、前記監視信号の応答である状態情報を前記サービス制御用呼処理制御サーバー手段から受信することにより、前記サービス制御用呼処理制御サーバー手段の運転状態を定期的に監視し、
前記監視信号を送信し、予め定められた一定の時間以内に前記状態情報を受信しない場合に、前記サービス制御用呼処理制御サーバー手段がシステムダウンしたとして検出し、
前記サービス制御用呼処理制御サーバー手段が、
前記仲介呼処理制御サーバー手段からの前記監視信号の受信に応じて、前記状態情報を前記仲介呼処理制御サーバー手段へ送信する状態情報送信手段を有する、
ことを特徴とする請求項１から請求項４に記載のネットワークシステム。
【請求項６】
端末からの呼をプロキシ呼処理制御サーバー装置を介して受信し、前記受信した呼をサービス制御用呼処理制御サーバー装置を介してアプリケーションサーバーへ送信し、前記端末と前記アプリケーションサーバーとの間の通信を確立するネットワークシステムにおいて用いられる仲介呼処理制御サーバー装置であり、
前記サービス制御用呼処理制御サーバー装置の運転状態を定期的に監視する監視手段と、
前記サービス制御用呼処理制御サーバー装置がシステムダウンしたことを前記監視手段が検出した場合には、前記確立した通信における前記端末から前記アプリケーションサーバーへの呼を、前記呼に基づいて前記アプリケーションサーバーへ転送する転送手段と、
を有することを特徴とする仲介呼処理制御サーバー装置。
【請求項７】
ＩＰネットワークシステムにおいて複数の信号制御サーバーが存在し、さらに信号制御サーバーの機能が複数のサーバー機能に分割されている通信ネットワークシステムであって、
前記通信ネットワークシステムに対してクライアント端末から送信されたメッセージを受信し前記通信ネットワークシステムの内部へ転送するためのプロキシ呼処理制御サーバー機能、前記プロキシ呼処理制御サーバーから受信したメッセージを中継する仲介呼処理制御サーバー機能、前記仲介呼処理制御サーバー機能から受信したメッセージに基づきアプリケーションサーバーヘ前記メッセージを転送するサービス制御用呼処理制御サーバー機能を有する通信ネットワークシステムにおいて用いられる呼処理方法であり、
前記仲介呼処理制御サーバー機能が
予め決められた一定時間的にサービス制御用呼処理制御サーバー機能の運転状態を監視し、
前記サービス制御用呼処理制御サーバー機能のシステムダウンを前記監視により検出した場合には、前記サービス制御用呼処理制御サーバー機能の転送処理を代行することにより通信ネットワークシステムの機能を維持し、
前記サービス制御用呼処理制御サーバー機能のシステムダウンから回復したことを検出した場合には、前記アプリケーションサーバーヘのメッセージを前記サービス制御用呼処理制御サーバー機能へ転送する、
ことを特徴とする呼処理方法。
【請求項８】
前記仲介呼処理制御サーバー機能が、更に、
前記サービス制御用呼処理制御サーバー機能のシステムダウンを前記監視により検出した場合には、通信状態を保持し、
前記サービス制御用呼処理制御サーバー機能がシステムダウンから回復したことを検出した場合には、前記保持した通信状態を前記サービス制御用呼処理制御サーバー機能へ引き継ぐ、
ことを特徴とする請求項７に記載の呼処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰネットワークシステムにおいて複数の信号制御サーバーが存在し、さらに信号制御サーバーの機能が複数のサーバー機能に分割されている通信ネットワークシステムに関する。
【背景技術】
【０００２】
以下では３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ（以下、３ＧＰＰ）において標準化が行われているＩＰ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍ（以下、ＩＭＳ）標準のネットワークアーキテクチャを例として説明を行う。
ＩＭＳ標準のネットワークアーキテクチャでは、Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｅ  Ｐｒｏｔｏｃｏｌ（以下、ＳＩＰ）に基づき信号制御サーバーが中心となってユーザーに対してサービス提供を実施する（非特許文献１および特許文献１参照）。
【０００３】
サービス要求のためのメッセージは、まずクライアント端末からＩＰコアネットワーク上のＳＩＰ信号制御サーバー（以下、ＳＩＰサーバー）に送信され、ＳＩＰサーバーにてサービス要求メッセージの内容が解析され、その後サービスの内容に応じてＡｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ（以下、ＡＳ）へ転送される。
【０００４】
ＳＩＰサーバーの機能は以下に示す３種類のサーバー機能部から構成され、クライアント端末からのサービス要求メッセージは以下に示す手順によりＡＳへ転送される。
ユーザーがサービスを受けるためには、まずクライアント端末とプロキシ呼処理制御サーバー機能部（以下、Ｐ−ＣＳＣＦ）との間で、ネットワークポリシーに関するネゴシエーションを行い、通信を確立する必要がある。通信の確立後、クライアント端末は、Ｐ−ＣＳＣＦに対してサービスを受けるための登録処理（以下、ＲＥＧＩＳＴＥＲ処理）を行うためのＲＥＧＩＳＴＥＲメッセージをＰ−ＣＳＣＦへ送信する。
【０００５】
クライアント端末からのＲＥＧＩＳＴＥＲメッセージを受信したＰ−ＣＳＣＦは、受信したＲＥＧＩＳＴＥＲメッセージを仲介呼処理制御サーバー機能部（以下、Ｉ−ＣＳＣＦ）へ転送する。ＩＭＳ標準のネットワークアーキテクチャにおいては、負荷分散のためにＩ−ＣＳＣＦが複数用意されており、どのＩ−ＣＳＣＦに転送するかは任意となっている。
【０００６】
Ｐ−ＣＳＣＦからのＲＥＧＩＳＴＥＲメッセージを受信したＩ−ＣＳＣＦは、受信したＲＥＧＩＳＴＥＲメッセージの内容を解析し、転送先のサービス制御用呼処理制御サーバー機能部（以下、Ｓ−ＣＳＣＦ）を決定し転送する。
ＩＭＳ標準のネットワークアーキテクチャにおいては、サービス種別に応じてどのＳ−ＣＳＣＦへ転送するかが異なるため、Ｉ−ＣＳＣＦはデータベース（以下、ＨＳＳ）に登録されたネットワーク情報およびユーザー情報を、Ｄｉａｍｅｔｅｒプロトコルを用いて参照することにより、適切な転送先（Ｓ−ＣＳＣＦ）を決定する。
【０００７】
Ｉ−ＣＳＣＦからのＲＥＧＩＳＴＥＲメッセージを受信したＳ−ＣＳＣＦでは、当該クライアント端末が認証されたものであるか否かを検出する。通常１度目（始めて）のＲＥＧＩＳＴＥＲ処理においてはクライアント端末の認証がされていないため、Ｓ−ＣＳＣＦは認証に必要なデータを添付した認証要求メッセージをクライアント端末へ、Ｉ−ＣＳＣＦとＰ−ＣＳＣＦを介して、送信する（送り返す）。
【０００８】
Ｓ−ＣＳＣＦからの認証要求メッセージを受信したクライアント端末は、クライアント端末にて受信した認証要求メッセージに応じた認証処理を実行し、再度、認証要求メッセージを送信したＳ−ＣＳＣＦに対して、認証処理を実行した認証結果を添付したＲＥＧＩＳＴＥＲメッセージを送信する。
Ｓ−ＣＳＣＦは、受信したＲＥＧＩＳＴＥＲメッセージに添付された認証結果に基づき、認証されたメッセージであることを確認し、ＲＥＧＩＳＴＥＲ処理を完了する。
【０００９】
クライアント端末は、ＲＥＧＩＳＴＥＲ処理が終了した後に、ＡＳに対してサービス要求メッセージを送信することで、ＡＳからのサービスを受ける。
ここで、クライアント端末からのサービス要求メッセージは、上記のＲＥＧＩＳＴＥＲ処理と同様の手順でＳ−ＣＳＣＦまで送信され、Ｓ−ＣＳＣＦによる転送先ＡＳの選択は、上記Ｉ−ＣＳＣＦによる適切なＳ−ＣＳＣＦの選択手順と同様に、ＨＳＳを参照することにより実行する。
【００１０】
次に、クライアント端末からのサービス要求メッセージを受信したＡＳは、受信したサービス要求メッセージの内容を解析し、クライアント端末に対してサービス提供を開始する。
クライアント端末とＡＳとの間の通信は、すべてＳＩＰサーバーを経由してやり取りされ、通信状態はＳ−ＣＳＣＦに保持される。
【００１１】
しかしながら、このようなＩＰネットワークシステムにおいて、Ｓ−ＣＳＣＦがシステムダウンした場合、確立されたはずのクライアント端末とＡＳとの間の通信が中断されることによりサービス停止状態となる問題があった。
さらに、Ｓ−ＣＳＣＦがシステムダウンした際に、クライアント端末とＡＳとの間の通信状態が消去されてしまうという問題があり、そのため、Ｓ−ＣＳＣＦの回復後にクライアント端末は再度ＡＳに対してサービス要求メッセージを送信し、接続を再確立することが必要となるという問題があった。
【非特許文献１】Ｍｉｉｋｋａ  Ｐｏｉｋｓｅｌｋａ，Ｇｅｏｒｇ  Ｍａｙｅｒ，Ｈｉｓｈａｍ  ｋｈａｒｔａｂｉｌ，Ａｋｉ  Ｎｉｅｍｉ，“ＴＨＥ  ＩＭＳ”，Ｊｏｈｎ  Ｗｉｌｅｙ＆Ｓｏｎｓ  Ｉｎｃ，ｐ．１１−２６，ｐ．１２３−２５７，Ａｐｒｉｌ，２００４
【特許文献１】特開２００４ー３６４１５４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明は、このような事情に鑑みてなされたもので、その目的は、ＩＰネットワークシステムにおいて、Ｓ−ＣＳＣＦがシステムダウンした場合であっても、確立されているクライアント端末とＡＳとの間の通信が中断されずサービスの提供が継続され、また、Ｓ−ＣＳＣＦがシステムダウンした際においてもクライアント端末とＡＳとの通信状態が維持され、Ｓ−ＣＳＣＦの回復後においてもクライアント端末が再度ＡＳに対してサービス要求メッセージを送信し接続を再確立することが必要ないネットワークシステム、仲介呼処理制御サーバー装置およびその呼処理方法を提供することにある。
【課題を解決するための手段】
【００１３】
この発明は上述した課題を解決するためになされたもので、請求項１に記載の発明は、プロキシ呼処理制御サーバー手段、仲介呼処理制御サーバー手段およびサービス制御用呼処理制御サーバー手段を有し、端末からの呼を受信し前記仲介呼処理制御サーバー手段へ転送する第１の転送手段を前記プロキシ呼処理制御サーバー手段が有し、前記プロキシ呼処理制御サーバーから受信した呼を前記サービス制御用呼処理制御サーバー手段へ転送する第２の転送手段を前記仲介呼処理制御サーバー手段が有し、前記仲介呼処理制御サーバー手段から受信した呼を前記呼の内容に基づき適切なアプリケーションサーバーヘ転送する第３の転送手段を前記サービス制御用呼処理制御サーバー手段が有する、前記端末と前記アプリケーションサーバーとの間の通信を確立するネットワークシステムであり、前記仲介呼処理制御サーバー手段が、前記サービス制御用呼処理制御サーバー手段の運転状態を定期的に監視する監視手段を有し、前記仲介呼処理制御サーバー手段の前記第２の転送手段が、前記サービス制御用呼処理制御サーバー手段がシステムダウンしたことを前記監視手段が検出した場合には、前記確立した通信における前記端末から前記アプリケーションサーバーへの呼を前記呼に基づいて前記アプリケーションサーバーへ転送する、ことを特徴とするネットワークシステムである。
【００１４】
請求項２に記載の発明は、前記仲介呼処理制御サーバー手段が、前記サービス制御用呼処理制御サーバー手段が回復したことを示す回復通知信号を前記サービス制御用呼処理制御サーバー手段から受信する回復通知信号受信手段を有し、前記第２の転送手段が、前記回復通知信号受信手段が前記回復通知信号を受信した後は、前記確立した通信における前記端末から前記アプリケーションサーバーへの呼を、前記サービス制御用呼処理制御サーバー手段へ転送する、ことを特徴とする請求項１に記載のネットワークシステムである。
【００１５】
請求項３に記載の発明は、前記ネットワークシステムが更に、前記仲介呼処理制御サーバー手段および前記サービス制御用呼処理制御サーバー手段から参照可能なデータベース手段を有しており、前記サービス制御用呼処理制御サーバー手段が、前記端末とアプリケーションサーバーとの間の通信状態を前記データベース手段に記録する第１の記録手段と、前記記録した通信状態を前記データベース手段から参照する第１の参照手段と、を有することを特徴とする請求項１から請求項２に記載のネットワークシステムである。
【００１６】
請求項４に記載の発明は、前記仲介呼処理制御サーバー手段が前記端末とアプリケーションサーバーとの間の通信状態を前記データベース手段に記録する第２の記録手段と、前記記録した通信状態を前記データベース手段から参照する第２の参照手段と、を有することを特徴とする請求項３に記載のネットワークシステムである。
【００１７】
請求項５に記載の発明は、前記仲介呼処理制御サーバー手段の監視手段が、監視信号を前記サービス制御用呼処理制御サーバー手段へ定期的に送信し、前記監視信号の応答である状態情報を前記サービス制御用呼処理制御サーバー手段から受信することにより、前記サービス制御用呼処理制御サーバー手段の運転状態を定期的に監視し、前記監視信号を送信し、予め定められた一定の時間以内に前記状態情報を受信しない場合に、前記サービス制御用呼処理制御サーバー手段がシステムダウンしたとして検出し、前記サービス制御用呼処理制御サーバー手段が、前記仲介呼処理制御サーバー手段からの前記監視信号の受信に応じて、前記状態情報を前記仲介呼処理制御サーバー手段へ送信する状態情報送信手段を有する、ことを特徴とする請求項１から請求項４に記載のネットワークシステムである。
【００１８】
請求項６に記載の発明は、端末からの呼をプロキシ呼処理制御サーバー装置を介して受信し、前記受信した呼をサービス制御用呼処理制御サーバー装置を介してアプリケーションサーバーへ送信し、前記端末と前記アプリケーションサーバーとの間の通信を確立するネットワークシステムにおいて用いられる仲介呼処理制御サーバー装置であり、前記サービス制御用呼処理制御サーバー装置の運転状態を定期的に監視する監視手段と、
前記サービス制御用呼処理制御サーバー装置がシステムダウンしたことを前記監視手段が検出した場合には、前記確立した通信における前記端末から前記アプリケーションサーバーへの呼を、前記呼に基づいて前記アプリケーションサーバーへ転送する転送手段と、
を有することを特徴とする仲介呼処理制御サーバー装置である。
【００１９】
請求項７に記載の発明は、ＩＰネットワークシステムにおいて複数の信号制御サーバーが存在し、さらに信号制御サーバーの機能が複数のサーバー機能に分割されている通信ネットワークシステムであって、前記通信ネットワークシステムに対してクライアント端末から送信されたメッセージを受信し前記通信ネットワークシステムの内部へ転送するためのプロキシ呼処理制御サーバー機能、前記プロキシ呼処理制御サーバーから受信したメッセージを中継する仲介呼処理制御サーバー機能、前記仲介呼処理制御サーバー機能から受信したメッセージに基づきアプリケーションサーバーヘ前記メッセージを転送するサービス制御用呼処理制御サーバー機能を有する通信ネットワークシステムにおいて用いられる呼処理方法であり、前記仲介呼処理制御サーバー機能が予め決められた一定時間的にサービス制御用呼処理制御サーバー機能の運転状態を監視し、前記サービス制御用呼処理制御サーバー機能のシステムダウンを前記監視により検出した場合には、前記サービス制御用呼処理制御サーバー機能の転送処理を代行することにより通信ネットワークシステムの機能を維持し、前記サービス制御用呼処理制御サーバー機能のシステムダウンから回復したことを検出した場合には、前記アプリケーションサーバーヘのメッセージを前記サービス制御用呼処理制御サーバー機能へ転送する、ことを特徴とする呼処理方法である。
【００２０】
請求項８に記載の発明は、前記仲介呼処理制御サーバー機能が、更に、前記サービス制御用呼処理制御サーバー機能のシステムダウンを前記監視により検出した場合には、通信状態を保持し、前記サービス制御用呼処理制御サーバー機能がシステムダウンから回復したことを検出した場合には、前記保持した通信状態を前記サービス制御用呼処理制御サーバー機能へ引き継ぐ、ことを特徴とする請求項７に記載の呼処理方法である。
【００２１】
Ｉ−ＣＳＣＦは、Ｓ−ＣＳＣＦのシステムダウンを検出する機能を有し、Ｉ−ＣＳＣＦがＳ−ＣＳＣＦに対して定期的に生存確認信号（監視信号）を送信し、Ｓ−ＣＳＣＦの運転状態を検出する。
ＨＳＳは、クライアント端末とＳＩＰサーバーとの通信状態を記録する機能を有し、Ｓ−ＣＳＣＦごとの通信状態を記録する領域を持ち、Ｓ−ＣＳＣＦのＩＤによりそれぞれのＳ−ＣＳＣＦの通信状態を識別できる。
【発明の効果】
【００２２】
この本発明によれば、Ｓ−ＣＳＣＦのシステムダウンによりサービス停止となった場合に、Ｉ−ＣＳＣＦがＳ−ＣＳＣＦのシステムダウンを検出し、Ｓ−ＣＳＣＦが回復するまでのあいだＩ−ＣＳＣＦがＳ−ＣＳＣＦの役割を代行することで、確立されているクライアント端末とＡＳとの間の通信を中断せずサービスの提供を継続することが出来、サービス停止の状態を回避することが出来るという効果を奏する。
【００２３】
また、本発明によれば、Ｉ−ＣＳＣＦがＳ−ＣＳＣＦの役割を代行することで、システムダウンから回復する際のＳ−ＣＳＣＦの通信状態クリアにともなう通信の再確立をしなくてよいという効果を奏する。
【発明を実施するための最良の形態】
【００２４】
以下、図面を参照して、本発明の実施形態について説明する。図１は、この発明の一実施形態によるネットワークシステムの構成を示す概略ブロック図である。
図１に示すように、実施形態のおけるネットワークシステムは、クライアント端末１０、Ｐ−ＣＳＣＦ２０、Ｉ−ＣＳＣＦ３０、運用系Ｓ−ＣＳＣＦ４０１、待機系Ｓ−ＣＳＣＦ４０２、ＨＳＳ５０、ＡＳ６０を有する。
【００２５】
図１の実施形態ではＳ−ＣＳＣＦを、通常時にＡＳへのメッセージ転送を行う運用系Ｓ−ＣＳＣＦ４０１と、運用系Ｓ−ＣＳＣＦ４０１がシステムダウンしたときに運用系Ｓ−ＣＳＣＦ４０１に代わって転送処理を行う待機系Ｓ−ＣＳＣＦ４０２との、２台のＳ−ＣＳＣＦを用意しているが、この形態に限定されるものではない。
【００２６】
ＨＳＳ５０は、ネットワークにおけるＩ−ＣＳＣＦ３０、運用系Ｓ−ＣＳＣＦ４０１、ＡＳ６０についてのネットワーク情報およびユーザー情報を蓄積する機能を有する。
また、ＨＳＳ５０は、Ｉ−ＣＳＣＦ３０からの参照に基づいて、適切な運用系Ｓ−ＣＳＣＦ４０１についての情報を返信する機能を有する。
また、ＨＳＳ５０は、運用系Ｓ−ＣＳＣＦ４０１からの参照に基づいて、適切なＡＳ６０についての情報を返信する機能を有する。
【００２７】
また、ＨＳＳ５０は、後述するＩ−ＣＳＣＦ３０の通信状態レコード（図２参照）を蓄積する機能を有し、Ｉ−ＣＳＣＦ３０、運用系Ｓ−ＣＳＣＦ４０１または待機系Ｓ−ＣＳＣＦ４０２から、Ｉ−ＣＳＣＦ３０の通信状態レコードへの登録および参照の要求を受信し、登録要求に応じた登録処理や参照に応じた応答処理を行う。
【００２８】
クライアント端末１０は、ユーザーが用いる端末である。ユーザーはクライアント端末１０を用いてＡＳ６０ヘサービス要求を行い、ＡＳ６０からのアプリケーションサービスを、クライアント端末１０を介して受ける。
クライアント端末１０は、例えば、通信機能を有するＰＣ（パーソナルコンピュータ）、携帯電話、通信機能を有する携帯情報端末（ＰＤＡ）などである。
【００２９】
Ｐ−ＣＳＣＦ２０はクライアント端末１０と通信暗号方式や通信帯域のためのネゴシエーションを行う機能を有する。
また、Ｐ−ＣＳＣＦ２０は、クライアント端末１０からメッセージを受信し、受信したメッセージをＩ−ＣＳＣＦ３０へ転送する機能を有する。
【００３０】
Ｉ−ＣＳＣＦ３０はＰ−ＣＳＣＦ２０から受信したメッセージの内容を解析し、ＨＳＳ５０を参照し、適切な運用系Ｓ−ＣＳＣＦ４０１へ転送する機能を有する。
【００３１】
また、Ｉ−ＣＳＣＦ３０は、転送先である運用系Ｓ−ＣＳＣＦ４０１に一定時間毎に監視信号を送信することで、運用系Ｓ−ＣＳＣＦ４０１の運転状態を検出する機能を有する。
例えば、Ｉ−ＣＳＣＦ３０は、運用系Ｓ−ＣＳＣＦ４０１へ監視信号を送信し、送信した監視信号の応答である状態情報を運用系Ｓ−ＣＳＣＦ４０１から、予め決められた一定時間内に受信する場合に、運用系Ｓ−ＣＳＣＦ４０１の運転状態が正常であると検出し、予め決められた一定時間内に受信しない場合に、運用系Ｓ−ＣＳＣＦ４０１の運転状態が異常（システムダウン）であると検出する。
【００３２】
また、Ｉ−ＣＳＣＦ３０は、運用系Ｓ−ＣＳＣＦ４０１の運転状態が異常（システムダウン）であると検出した場合には、クライアント端末１０からＡＳ６０へのサービス要求メッセージを、運用系Ｓ−ＣＳＣＦ４０１を介さずに、直接ＡＳ６０へ転送する機能を有する。
これにより、運用系Ｓ−ＣＳＣＦ４０１の運転状態が異常（システムダウン）となった場合においても、クライアント端末１０とＡＳ６０との間の通信が維持される。
ここで、Ｉ−ＣＳＣＦ３０が、クライアント端末１０からＡＳ６０へのサービス要求メッセージを直接ＡＳ６０へ転送する方法は、クライアント端末１０からのサービス要求メッセージのヘッダー情報より宛先がＡＳ６０であることを検出し、検出したＡＳ６０へサービス要求メッセージを転送することにより行う。
【００３３】
また、Ｉ−ＣＳＣＦ３０は、運用系Ｓ−ＣＳＣＦ４０１が異常（システムダウン）であると検出した後において、待機系Ｓ−ＣＳＣＦ４０２から引継ぎ可能信号を受信した場合には、その後、クライアント端末１０からＡＳ６０へのサービス要求メッセージを、待機系Ｓ−ＣＳＣＦ４０２へ転送する機能を有する。
【００３４】
また、Ｉ−ＣＳＣＦ３０は、運用系Ｓ−ＣＳＣＦ４０１の異常（システムダウン）となった後において、運用系Ｓ−ＣＳＣＦ４０１が回復したことを検出した場合には、クライアント端末１０からＡＳ６０へのサービス要求メッセージを、運用系Ｓ−ＣＳＣＦ４０１へ転送する機能を有する。
これにより、運用系Ｓ−ＣＳＣＦ４０１の回復時には、運用系Ｓ−ＣＳＣＦ４０１が異常（システムダウン）の前と同じ状態により、クライアント端末１０とＡＳ６０との間の通信が維持することが可能となる。
ここで、Ｉ−ＣＳＣＦ３０が、運用系Ｓ−ＣＳＣＦ４０１が異常（システムダウン）から回復したことを検出する方法は、運用系Ｓ−ＣＳＣＦ４０１からの回復通知信号を受信することにより行う。
【００３５】
また、Ｉ−ＣＳＣＦ３０は、運用系Ｓ−ＣＳＣＦ４０１からの回復通知信号を受信してから運用系Ｓ−ＣＳＣＦ４０１からの引継ぎ完了応答信号を受信するまでは、クライアント端末１０からのサービス要求メッセージを受信した場合、受信したサービス要求メッセージを転送せずに保持しておく機能を有する。
また、Ｉ−ＣＳＣＦ３０は、運用系Ｓ−ＣＳＣＦ４０１からの引継ぎ完了通知信号を受信した場合は、引継ぎ完了応答信号を運用系Ｓ−ＣＳＣＦ４０１へ送信し、保持していたサービス要求メッセージを運用系Ｓ−ＣＳＣＦ４０１へ転送する機能を有する。
【００３６】
また、Ｉ−ＣＳＣＦ３０は、ＨＳＳ５０が有する後述の通信状態レコード（図２参照）に対して、通信状態を登録および参照する機能を有する。
【００３７】
運用系Ｓ−ＣＳＣＦ４０１はＩ−ＣＳＣＦ３０から受信したメッセージの内容を解析し、ＨＳＳ５０を参照し、サービス要求の送信元であるユーザーが認証されているかどうかを確認し、認証されていた場合には、適切なＡＳ６０へ転送する機能を有する。
また、運用系Ｓ−ＣＳＣＦ４０１は、前記確認において認証されていない場合には、認証要求メッセージをクライアント端末１０に対して送信する機能を有する。
【００３８】
また、運用系Ｓ−ＣＳＣＦ４０１は、Ｉ−ＣＳＣＦ３０からの監視信号を受信し、受信した監視信号に応答する状態情報を、Ｉ−ＣＳＣＦ３０へ送信する機能を有する。
また、運用系Ｓ−ＣＳＣＦ４０１は、待機系Ｓ−ＣＳＣＦ４０２からの運転状態確認信号を受信し、受信した運転状態確認信号に応答する運転状態応答信号を、待機系Ｓ−ＣＳＣＦ４０２へ送信する機能を有する。
【００３９】
また、運用系Ｓ−ＣＳＣＦ４０１は、運用系Ｓ−ＣＳＣＦ４０１が回復した場合には、Ｉ−ＣＳＣＦ３０および待機系Ｓ−ＣＳＣＦ４０２へ、回復通知信号を送信する機能を有する。
【００４０】
また、運用系Ｓ−ＣＳＣＦ４０１は、回復後において、ＨＳＳ５０から通信状態を取得し待機系Ｓ−ＣＳＣＦ４０２の処理を引継ぎ、引継ぎが完了した後、Ｉ−ＣＳＣＦ３０へ引継ぎ完了通知信号を送信する機能を有する。
【００４１】
また、運用系Ｓ−ＣＳＣＦ４０１は、ＨＳＳ５０が有する後述の通信状態レコード（図２参照）に対して、通信状態を登録および参照する機能を有する。
【００４２】
待機系Ｓ−ＣＳＣＦ４０２は、運用系Ｓ−ＣＳＣＦ４０１の動作を監視しており、監視において運用系Ｓ−ＣＳＣＦ４０１のシステムダウンを検出した場合には、ＨＳＳ５０に記録されたユーザーの通信情報を取得し、運用系Ｓ−ＣＳＣＦ４０１に代わって転送処理を実行する機能を有する。
【００４３】
例えば、待機系Ｓ−ＣＳＣＦ４０２は、運用系Ｓ−ＣＳＣＦ４０１に対して、運転状態確認信号を送信し、運用系Ｓ−ＣＳＣＦ４０１から運転状態確認信号の応答である運転状態応答信号を、予め決められた一定の時間内に受信することにより、運用系Ｓ−ＣＳＣＦ４０１が正常状態であることを検出し、予め決められた一定の時間内に受信しないことにより、運用系Ｓ−ＣＳＣＦ４０１が異常状態（システムダウン）であることを検出する。
【００４４】
また、待機系Ｓ−ＣＳＣＦ４０２は、回復通知信号を運用系Ｓ−ＣＳＣＦ４０１から受信し、受信した回復通知信号に応答して回復通知応答信号を運用系Ｓ−ＣＳＣＦ４０１へ送信する機能を有する。
【００４５】
また、待機系Ｓ−ＣＳＣＦ４０２は、ＨＳＳ５０が有する後述の通信状態レコード（図２参照）に対して、通信状態を登録および参照する機能を有する。
【００４６】
ＡＳ６０は、クライアント端末１０からのサービス要求メッセージを受信し、受信したサービス要求メッセージを解析し、その内容に応じたアプリケーションサービスをクライアント端末１０に提供する機能を有する。
【００４７】
なお、Ｐ−ＣＳＣＦ２０、Ｉ−ＣＳＣＦ３０、運用系Ｓ−ＣＳＣＦ４０１および待機系Ｓ−ＣＳＣＦ４０２はＳＩＰサーバーの機能の一部である。
なお、図１のネットワークシステムにおいては、クライアント端末１０、Ｐ−ＣＳＣＦ２０、Ｉ−ＣＳＣＦ３０、運用系Ｓ−ＣＳＣＦ４０１、待機系Ｓ−ＣＳＣＦ４０２およびＡＳ６０を１つずつ記載しているが、実際には、ネットワークシステムは、複数のＰ−ＣＳＣＦ２０、Ｉ−ＣＳＣＦ３０、運用系Ｓ−ＣＳＣＦ４０１、待機系Ｓ−ＣＳＣＦ４０２およびＡＳ６０からなる。
【００４８】
また、それぞれの、クライアント端末１０、Ｐ−ＣＳＣＦ２０、Ｉ−ＣＳＣＦ３０、運用系Ｓ−ＣＳＣＦ４０１、待機系Ｓ−ＣＳＣＦ４０２およびＡＳ６０は、固有のＩＤまたは識別子を有しており、固有のＩＤまたは識別子によりクライアント端末１０、Ｐ−ＣＳＣＦ２０、Ｉ−ＣＳＣＦ３０、運用系Ｓ−ＣＳＣＦ４０１、待機系Ｓ−ＣＳＣＦ４０２およびＡＳ６０のそれぞれが識別されるものである。
【００４９】
図２のテーブル１は、本実施形態における、ＨＳＳ５０に記録保持される、Ｓ−ＣＳＣＦの通信状態レコードの一例である。
本実施形態においては、Ｓ−ＣＳＣＦの通信状態レコードは、図２のテーブル１に示すように、Ｓ−ＣＳＣＦのＩＤ７０１、クライアント認証状態７０２、Ｓ−ＣＳＣＦの運転状態７０３、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５、宛先ＡＳアドレス７０６から構成される。
【００５０】
Ｓ−ＣＳＣＦのＩＤ７０１は、Ｓ−ＣＳＣＦを識別するための識別子である。
クライアント認証状態７０２は、クライアント端末１０が認証済みであるか否かの状態を示す情報である。本実施形態では、「０」を末認証状態とし、「１」を認証済み状態として説明する。
【００５１】
Ｓ−ＣＳＣＦの運転状態７０３は、Ｓ−ＣＳＣＦが正常に運転しているかどうかを示す情報である。本実施形態では、Ｓ−ＣＳＣＦが正常に運転している場合を「１」、Ｓ−ＣＳＣＦがシステムダウンしておりＩ−ＣＳＣＦが処理を代行している場合を「０」として説明する。
【００５２】
Ｃａｌｌ−ＩＤ７０４は、運用系Ｓ−ＣＳＣＦ４０１が通信を行っているクライアント端末１０を識別するために一時的に使用される識別子である。クライアント端末１０とＡＳ６０との間の通信が終了した場合、Ｃａｌｌ−ＩＤ７０４はクリアされる。
【００５３】
シーケンス番号７０５は、運用系Ｓ−ＣＳＣＦ４０１とクライアント端末１０との間でやり取りされたメッセージの履歴を表すデータ（情報）である。本実施形態ではシーケンス番号７０５はメッセージ種別およびやり取りされたメッセージの総量から構成される。
宛先ＡＳアドレス７０６は、クライアント端末１０に対してサービスを提供しているＡＳ６０のアドレスを示す情報である。
【００５４】
この実施形態のおいては、例えば、ＨＳＳ５０のＳ−ＣＳＣＦの通信状態レコード（図２のテーブル１）に対しての通信状態の登録とは、Ｓ−ＣＳＣＦのＩＤ７０１をキーとして、クライアント認証状態７０２、Ｓ−ＣＳＣＦの運転状態７０３、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５を登録することである。
また、ＨＳＳ５０のＳ−ＣＳＣＦの通信状態レコード（図２のテーブル１）に対しての通信状態の参照または取得とは、Ｓ−ＣＳＣＦのＩＤ７０１をキーとして、クライアント認証状態７０２、Ｓ−ＣＳＣＦの運転状態７０３、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５を参照または取得することである。
【００５５】
なお、ＨＳＳ５０には、周辺機器として入力装置および表示装置等が接続されており、ネットワークの管理者は、入力装置および表示装置を介して、ＨＳＳ５０にアクセスし、通信状態レコードを参照することにより、通信状態または通信状態のログを見たり確認したりすることができる。
ここで、入力装置とはキーボード、マウス等の入力デバイスのことをいい、表示装置とはＣＲＴ（Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ）や液晶表示装置等のことをいう。
【００５６】
次に、図３のシーケンス図を用いて、本実施形態におけるネットワークシステムにおいて、サービス要求のためのＲＥＧＩＳＴＥＲ処理における動作を説明する。
【００５７】
まず、クライアント端末１０がＰ−ＣＳＣＦ２０に対してＲＥＧＩＳＴＥＲメッセージを送信する。Ｐ−ＣＳＣＦ２０はＩ−ＣＳＣＦ３０に対してＲＥＧＩＳＴＥＲを転送する（ステップＳ３００１）。
次に、Ｉ−ＣＳＣＦ３０はＤｉａｍｅｔｅｒプロトコル（ＤｉａｍｅｔｅｒＵＡＲとＤｉａｍｅｔｅｒＵＡＡ）を用いてＨＳＳ５０を参照し、転送先のアドレスを取得する（ステップＳ３００２）。
【００５８】
次に、Ｉ−ＣＳＣＦ３０は、転送先である運用系Ｓ−ＣＳＣＦ４０１に監視信号を送信し、運用系Ｓ−ＣＳＣＦ４０１から状態情報を受信することで、運用系Ｓ−ＣＳＣＦ４０１の運転状態を検出する（ステップＳ３００３）。本シーケンスでは、運用系Ｓ−ＣＳＣＦ４０１の運転状態が正常であるため、Ｉ−ＣＳＣＦ３０は運用系Ｓ−ＣＳＣＦ４０１の運転状態が正常であることを確認し、運用系Ｓ−ＣＳＣＦ４０１へＲＥＧＩＳＴＥＲメッセージを転送する。
【００５９】
次に、運用系Ｓ−ＣＳＣＦ４０１はＤｉａｍｅｔｅｒプロトコル（ＤｉａｍｅｔｅｒＭＡＲとＤｉａｍｅｔｅｒＭＡＡ）を用いてＨＳＳ５０を参照し、クライアント端末１０が認証されているか否かを検出する（ステップＳ３００４）。
この場合、１度目（始めて）のＲＥＧＩＳＴＥＲ処理であり、クライアント端末の認証がされていないため、運用系Ｓ−ＣＳＣＦ４０１はＨＳＳ５０から、クライアント端末１０が認証されていない通知を受信する。
【００６０】
次に、運用系Ｓ−ＣＳＣＦ４０１がＨＳＳ５０に対して、通信状態登録通知信号を送信し通信状態登録応答信号を受信することにより、Ｓ−ＣＳＣＦのＩＤ７０１、クライアント認証状態７０２、Ｓ−ＣＳＣＦの運転状態７０３、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５を登録する（ステップＳ３００５）。
例えば、運用系Ｓ−ＣＳＣＦ４０１がＨＳＳ５０に対して、クライアント認証状態７０２として末認証状態「０」とし、Ｓ−ＣＳＣＦの運転状態７０３として正常運転状態「１」として登録する。また、運用系Ｓ−ＣＳＣＦ４０１がＨＳＳ５０に対して、Ｓ−ＣＳＣＦのＩＤ７０１、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５のそれぞれの値を登録する。
【００６１】
次に、運用系Ｓ−ＣＳＣＦ４０１はクライアント端末１０が認証されていないことを確認し、クライアント端末１０に対して、認証に必要なデータを添付した認証要求メッセージをクライアント端末１０へ返送する（ステップＳ３００６）。
【００６２】
次に、クライアント端末１０は認証処理を行い、認証結果を添付したＲＥＧＩＳＴＥＲメッセージを再度運用系Ｓ−ＣＳＣＦ４０１に対して送信する。ＲＥＧＩＳＴＥＲメッセージは、上記のステップＳ３００１から３００３と同様の処理が行われ、運用系Ｓ−ＣＳＣＦ４０１まで送信される（ステップＳ３００７）。
【００６３】
次に、運用系Ｓ−ＣＳＣＦ４０１はＤｉａｍｅｔｅｒプロトコル（ＤｉａｍｅｔｅｒＳＡＲとＳＡＡ）を用いてＨＳＳ５０を参照し、クライアント端末１０が認証されたものであることを検出する（ステップＳ３００８）。
【００６４】
また、運用系Ｓ−ＣＳＣＦ４０１がＨＳＳ５０に対して、クライアント認証状態７０２、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５を更新する（ステップＳ３００９）。
例えば、運用系Ｓ−ＣＳＣＦ４０１がＨＳＳ５０に対して、クライアント認証状態７０２として認証済み状態の「１」として登録する。また、運用系Ｓ−ＣＳＣＦ４０１がＨＳＳ５０に対して、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５のそれぞれの値を登録する。
【００６５】
次に、運用系Ｓ−ＣＳＣＦ４０１はクライアント端末１０に対してＲＥＧＩＳＴＥＲが正常終了した信号（２００ＯＫ）を通知する（ステップＳ３０１０）。その後、クライアント端末１０は、ＡＳ６０に対してサービス要求メッセージを送信し、ＡＳ６０からのサービスの提供を受ける。
【００６６】
以降において、Ｉ−ＣＳＣＦ３０は運用系Ｓ−ＣＳＣＦ４０１の運転状態を定期的に監視する（ステップＳ３０１１）。
また、待機系Ｓ−ＣＳＣＦ４０２は、運用系Ｓ−ＣＳＣＦ４０１が正常に運転しているかどうかを定期的に監視するために、運用系Ｓ−ＣＳＣＦ４０１へ運転状態確認信号を送信する。ここでは運用系Ｓ−ＣＳＣＦ４０１が正常運転しているため、運用系Ｓ−ＣＳＣＦ４０１は待機系Ｓ−ＣＳＣＦ４０２に対して運転状態応答信号を返送する（ステップＳ３０１２）。
【００６７】
次に、図４のシーケンス図を用いて、本実施形態におけるネットワークシステムにおいて、Ｓ−ＣＳＣＦシステムダウン時の処理引継ぎの動作を説明する。図４の示すシーケンスは、図３に示したＲＥＧＩＳＴＥＲ処理後のシーケンスである。
図４においては、図３において示した処理により、クライアント端末１０のＲＥＧＩＳＴＥＲ処理が終了しており、クライアント端末１０がＡＳ６０に対してサービス要求メッセージを送信しており、ＡＳ６０がクライアント端末１０に対してサービスを提供中の状態であるとする。
【００６８】
まず、Ｉ−ＣＳＣＦ３０は運用系Ｓ−ＣＳＣＦ４０１の運転状態を定期的に検出している（ステップＳ４００１）。
次に、運用系Ｓ−ＣＳＣＦ４０１がシステムダウンによりサービス継続不可能となる（ステップＳ４００２）と、システムダウンをした運用系Ｓ−ＣＳＣＦ４０１は、システム回復処理を開始する（ステップＳ４００３）。
ここで、システム回復処理は、例えば、運用系Ｓ−ＣＳＣＦ４０１がシステムダウンを検出し、システム回復処理を開始してもよいし、または、人の手により運用系Ｓ−ＣＳＣＦ４０１の回復処理がなされてもよい。
【００６９】
また、Ｉ−ＣＳＣＦ３０は運用系Ｓ−ＣＳＣＦ４０１の運転を定期的に確認し、運用系Ｓ−ＣＳＣＦ４０１からの応答が無いことよりシステムダウンを検出する（ステップＳ４００４）。
【００７０】
次に、クライアント端末１０が、ＡＳ６０宛てに任意のサービス要求メッセージを、Ｉ−ＣＳＣＦ３０を介して送信する。クライアント端末１０からのサービス要求メッセージを受信したＩ−ＣＳＣＦ３０は、運用系Ｓ−ＣＳＣＦ４０１がシステムダウンしていることを検出しているため、運用系Ｓ−ＣＳＣＦ４０１を介さずＡＳ６０へ直接に、サービス要求メッセージを転送する（ステップＳ４００５）。
【００７１】
また、クライアント端末１０とＡＳ６０との通信状態が更新されたため、Ｉ−ＣＳＣＦ３０は、ＨＳＳ５０に記録されたＳ−ＣＳＣＦの運転状態７０３、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５を更新する（ステップＳ４００６）。
例えば、運用系Ｓ−ＣＳＣＦ４０１がＨＳＳ５０に対して、Ｓ−ＣＳＣＦの運転状態７０３を「０」として更新する。また、運用系Ｓ−ＣＳＣＦ４０１がＨＳＳ５０に対して、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５のそれぞれの値を更新する。
【００７２】
その後、運用系Ｓ−ＣＳＣＦ４０１の運転状態を定期的に監視している待機系Ｓ−ＣＳＣＦ４０２が、運用系Ｓ−ＣＳＣＦ４０１のシステムダウンを検出する。待機系Ｓ−ＣＳＣＦ４０２は運用系Ｓ−ＣＳＣＦ４０１の処理を引継ぐために、ＨＳＳ５０から通信状態を取得する（ステップＳ４００７）。
【００７３】
次に、待機系Ｓ−ＣＳＣＦ４０２は、取得した通信状態に基づき処理引継ぎを完了し、Ｉ−ＣＳＣＦ３０に対して引継ぎ完了通知信号を送信する。Ｉ−ＣＳＣＦ３０は、待機系Ｓ−ＣＳＣＦ４０２からの引継ぎ完了通知信号を受信すると、待機系Ｓ−ＣＳＣＦ４０２が運転していることを検知し、引継ぎ完了応答信号を待機系Ｓ−ＣＳＣＦ４０２に送信する（ステップＳ４００８）。
【００７４】
次に、クライアント端末１０が、ＡＳ６０宛てに任意のサービス要求メッセージを、Ｉ−ＣＳＣＦ３０を介して送信する。
クライアント端末１０からのサービス要求メッセージを受信したＩ−ＣＳＣＦ３０は、待機系Ｓ−ＣＳＣＦ４０２が運転していることを検知しているため、待機系Ｓ−ＣＳＣＦ４０２に対してサービス要求メッセージを転送する。
待機系Ｓ−ＣＳＣＦ４０２は、Ｉ−ＣＳＣＦ３０から受信したクライアント端末１０からＡＳ６０宛てのサービス要求メッセージを、ＡＳ６０に転送する
（ステップＳ４００９）。
【００７５】
また、クライアント端末１０とＡＳ６０との通信状態が更新されたため、待機系Ｓ−ＣＳＣＦ４０２は、ＨＳＳ５０に記録されたＳ−ＣＳＣＦのＩＤ７０１、Ｓ−ＣＳＣＦの運転状態７０３、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５を更新する（ステップＳ４０１０）。
【００７６】
次に、図５のシーケンス図を用いて、本実施形態におけるネットワークシステムにおいて、Ｓ−ＣＳＣＦ回復時の処理引継ぎの動作を説明する。図５の示すシーケンスは、図４に示した処理引継ぎ後の回復シーケンスである。
【００７７】
まず、運用系Ｓ−ＣＳＣＦ４０１が回復し、待機系Ｓ−ＣＳＣＦ４０２へ回復通知信号を送信する。運用系Ｓ−ＣＳＣＦ４０１からの回復通知信号を受信した待機系Ｓ−ＣＳＣＦ４０２は、運用系Ｓ−ＣＳＣＦ４０１へ回復通知応答信号を送信する（ステップＳ５００１）。
【００７８】
運用系Ｓ−ＣＳＣＦ４０１はＩ−ＣＳＣＦ３０へも同様に回復通知信号を送信する。運用系Ｓ−ＣＳＣＦ４０１からの回復通知信号を受信したＩ−ＣＳＣＦ３０は、運用系Ｓ−ＣＳＣＦ４０１へ回復通知応答信号を送信する（ステップＳ５００２）。
次に、運用系Ｓ−ＣＳＣＦ４０１が、ＨＳＳ５０に記録されたＳ−ＣＳＣＦの運転状態７０３、Ｃａｌｌ−ＩＤ７０４、シーケンス番号７０５を更新する（ステップＳ５００３）。
【００７９】
次に、運用系Ｓ−ＣＳＣＦ４０１は、待機系Ｓ−ＣＳＣＦ４０２の処理を引継ぐために、ＨＳＳ５０から通信状態を取得する（ステップＳ５００４）。
Ｉ−ＣＳＣＦ３０は、運用系Ｓ−ＣＳＣＦ４０１からの回復通知信号を受信してから運用系Ｓ−ＣＳＣＦ４０１からの引継ぎ完了応答信号を受信するまでは、クライアント端末１０からのサービス要求メッセージを受信した場合、受信したサービス要求メッセージを転送せずに保持しておく（ステップＳ５００５）。
【００８０】
その後、引継ぎを完了した運用系Ｓ−ＣＳＣＦ４０１が、Ｉ−ＣＳＣＦ３０に対して引継ぎ完了通知信号を送信する（ステップＳ５００６）。
運用系Ｓ−ＣＳＣＦ４０１からの引継ぎ完了通知信号を受信したＩ−ＣＳＣＦ３０は引継ぎ完了応答信号を運用系Ｓ−ＣＳＣＦ４０１へ送信し、保持していたサービス要求メッセージを運用系Ｓ−ＣＳＣＦ４０１へ転送する（ステップＳ５００７）。
以降、通常通りの（運用系Ｓ−ＣＳＣＦ４０１のシステムダウン前と同じ）処理がなされる。
【００８１】
なお、Ｐ−ＣＳＣＦ２０、Ｉ−ＣＳＣＦ３０、運用系Ｓ−ＣＳＣＦ４０１および待機系Ｓ−ＣＳＣＦ４０２は、同一の装置における機能部として構成してもよいし、任意の組み合わせで同一の装置における機能部として構成してもよいし、また、異なる装置における機能部として構成してもよい。
または、Ｐ−ＣＳＣＦ２０、Ｉ−ＣＳＣＦ３０、運用系Ｓ−ＣＳＣＦ４０１および待機系Ｓ−ＣＳＣＦ４０２を、それぞれ装置としてもよい。
【００８２】
以上、この発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【産業上の利用可能性】
【００８３】
本発明は、ＩＰネットワーク網に適応して好適である。
【図面の簡単な説明】
【００８４】
【図１】この発明の一実施形態によるネットワークシステムの構成を示すブロック図である。
【図２】認証情報テーブルのデータ構成を示すテーブル図である。
【図３】サービス要求のためのＲＥＧＩＳＴＥＲ処理手順の動作を示すシーケンス図である。
【図４】Ｓ−ＣＳＣＦシステムダウン時の処理引継ぎの動作を示すシーケンス図である。
【図５】Ｓ−ＣＳＣＦ回復時の処理引継ぎの動作を示すシーケンス図である。
【符号の説明】
【００８５】
１０  クライアント端末
２０  Ｐ−ＣＳＣＦ
３０  Ｉ−ＣＳＣＦ
４０１  運用系Ｓ−ＣＳＣＦ
４０２  待機系Ｓ−ＣＳＣＦ
５０  ＨＳＳ
６０  ＡＳ
７０１  Ｓ−ＣＳＣＦのＩＤ
７０２  クライアント認証状態
７０３  Ｓ−ＣＳＣＦの運転状態
７０４  Ｃａｌｌ−ＩＤ
７０５  シーケンス番号
７０６  宛先ＡＳアドレス
【図１】
2007318629.tif 000003
【図２】
2007318629.tif 000004
【図３】
2007318629.tif 000005
【図４】
2007318629.tif 000006
【図５】
2007318629.tif 000007