(57)【要約】【課題】  ＳＩＰセッションを伴うアプリケーションサービスシステムにおいて、ＳＩＰセッション確立に失敗した場合、ＡＰサーバ状態回復後のセッション確立を効率化する。【解決手段】  サーバシステム２００のセッション管理部２１０は、クライアント１００からのＳＩＰセッション確立要求を受信時にＡＰサーバ２２０がサービス受付不可能な状態の場合、ＡＰサーバ２２０がサービス受付可能な状態になったことを検出後、クライアント１００へＳＩＰセッション確立要求を送信し、クライアント１００との間でＳＩＰセッションを確立する。ＡＰサーバ２２０は、ＳＩＰセッションが確立された場合、クライアント１００からのサービスセッション確立要求を受信した際、クライアント１００との間でサービスセッションを確立する。【選択図】      図１
2009116786.tif 000002
【特許請求の範囲】
【請求項１】
クライアントから第一のＳＩＰセッション確立要求を受信時にＡＰサーバがサービス受付不可能な状態の場合、前記ＡＰサーバがサービス受付可能な状態になったことを検出後、前記クライアントへ第二のＳＩＰセッション確立要求を送信し、前記クライアントとの間でＳＩＰセッションを確立するセッション管理手段と、
前記ＳＩＰセッションが確立された場合、前記クライアントからのサービスセッション確立要求を受信した際、前記クライアントとの間でサービスセッションを確立する前記ＡＰサーバと
を備えたことを特徴とするサーバシステム。
【請求項２】
前記サーバシステムは、更に、前記第一のＳＩＰセッション確立要求の情報を記憶するコールバック管理テーブルを備え、
前記セッション管理手段は、前記クライアントから前記第一のＳＩＰセッション確立要求を受信時に前記ＡＰサーバによるサービス受付不可能な状態の場合、前記第一のＳＩＰセッション確立要求の情報を前記コールバック管理テーブルに保存し、前記ＡＰサーバによるサービス受付可能な状態になったことを検出した場合、前記コールバック管理テーブルを参照し、コールバック対象の前記第一のＳＩＰセッション確立要求を決定し、前記コールバック対象の前記第一のＳＩＰセッション確立要求の送信元の前記クライアントへ前記第二のＳＩＰセッション確立要求を送信することを特徴とする請求項１記載のサーバシステム。
【請求項３】
前記セッション管理手段は、更に、前記第一のＳＩＰセッション確立要求をもとにサービスセッションを識別するためのサービスセッション情報の生成と、前記ＳＩＰ認証情報に対応するサービス認証情報の取得を行い、前記第二のＳＩＰセッション確立要求による前記ＳＩＰセッション確立時に、前記サービスセッション情報と前記サービス認証情報を前記ＡＰサーバに通知し、
前記ＡＰサーバは、前記クライアントからの前記サービスセッション確立要求を受信した際、前記サービスセッション情報と前記サービス認証情報を用いてユーザ認証を行い、前記ユーザ認証に成功した場合、前記クライアントとの間で前記サービスセッションを確立することを特徴とする請求項１または２に記載のサーバシステム。
【請求項４】
前記セッション管理手段は、前記ＡＰサーバのサービスセッション数を監視し、前記サービスセッション数と所定の最大許容セッション数との比較にもとづいて、前記ＡＰサーバがサービス受付可能かどうかを判定することを特徴とする請求項１乃至３のいずれかに記載のサーバシステム。
【請求項５】
前記セッション管理手段は、前記ＡＰサーバの負荷状態を監視し、前記負荷状態と所定の最大許容負荷との比較にもとづいて、前記ＡＰサーバがサービス受付可能かどうかを判定することを特徴とする請求項１乃至４のいずれかに記載のサーバシステム。
【請求項６】
前記サーバシステムは、更に、前記サービスセッションのパケットについて、前記第一のＳＩＰセッション確立要求により要求された帯域を確保するように制御する帯域制御手段を備え、
前記セッション管理手段は、前記サービスセッションの使用帯域と所定の最大許容帯域との比較にもとづいて、前記ＡＰサーバがサービス受付可能かどうかを判定することを特徴とする請求項１乃至５のいずれかに記載のサーバシステム。
【請求項７】
第一のＳＩＰセッション確立要求をサーバシステムに送信する手段と、
前記サーバシステムから第二のセッション確立要求を受信した際、前記サーバシステムとの間でＳＩＰセッションを確立する手段と、
前記ＳＩＰセッション確立後、前記サーバシステムにサービスセッション確立要求を送信する手段と
を有するクライアントと、
前記クライアントから前記第一のＳＩＰセッション確立要求を受信時にＡＰサーバがサービス受付不可能な状態の場合、前記ＡＰサーバがサービス受付可能な状態になったことを検出後、前記クライアントへ前記第二のＳＩＰセッション確立要求を送信し、前記クライアントとの間で前記ＳＩＰセッションを確立するセッション管理手段と、
前記ＳＩＰセッションが確立された場合、前記クライアントからの前記サービスセッション確立要求を受信した際、前記クライアントとの間で前記サービスセッションを確立する前記ＡＰサーバと
を有する前記サーバシステムと
を備えたことを特徴とするアプリケーションサービスシステム。
【請求項８】
前記サーバシステムは、更に、前記第一のＳＩＰセッション確立要求の情報を記憶するコールバック管理テーブルを有し、
前記セッション管理手段は、前記クライアントから前記第一のＳＩＰセッション確立要求を受信時に前記ＡＰサーバがサービス受付不可能な状態の場合、前記第一のＳＩＰセッション確立要求の情報を前記コールバック管理テーブルに保存し、前記ＡＰサーバがサービス受付可能な状態になったことを検出した場合、前記コールバック管理テーブルを参照し、コールバック対象の前記第一のＳＩＰセッション確立要求を決定し、前記コールバック対象の前記第一のＳＩＰセッション確立要求の送信元の前記クライアントへ前記第二のＳＩＰセッション確立要求を送信することを特徴とする請求項７記載のアプリケーションサービスシステム。
【請求項９】
前記セッション管理手段は、前記第一のＳＩＰセッション確立要求をもとにサービスセッションを識別するためのサービスセッション情報の生成と、前記ＳＩＰ認証情報に対応するサービス認証情報の取得を行い、前記第二のＳＩＰセッション確立要求による前記ＳＩＰセッション確立時に、前記サービスセッション情報と前記サービス認証情報を前記ＡＰサーバに通知し、
前記ＡＰサーバは、前記クライアントからの前記サービスセッション確立要求を受信した際、前記サービスセッション情報と前記サービス認証情報を用いてユーザ認証を行い、前記ユーザ認証に成功した場合、前記クライアントとの間で前記サービスセッションを確立することを特徴とする請求項７または８に記載のアプリケーションサービスシステム。
【請求項１０】
前記セッション管理手段は、前記ＡＰサーバのサービスセッション数を監視し、前記サービスセッション数と所定の最大許容セッション数との比較にもとづいて、前記ＡＰサーバがサービス受付可能かどうかを判定することを特徴とする請求項７乃至９のいずれかに記載のアプリケーションサービスシステム。
【請求項１１】
前記セッション管理手段は、前記ＡＰサーバの負荷状態を監視し、前記負荷状態と所定の最大許容負荷との比較にもとづいて、前記ＡＰサーバがサービス受付可能かどうかを判定することを特徴とする請求項７乃至１０のいずれかに記載のアプリケーションサービスシステム。
【請求項１２】
前記サーバシステムは、更に、前記サービスセッションのパケットについて、前記第一のＳＩＰセッション確立要求により要求された帯域を確保するように制御する帯域制御手段を有し、
前記セッション管理手段は、前記サービスセッションの使用帯域と所定の最大許容帯域との比較にもとづいて、前記ＡＰサーバがサービス受付可能かどうかを判定することを特徴とする請求項７乃至１１のいずれかに記載のアプリケーションサービスシステム。
【請求項１３】
クライアントが、
第一のＳＩＰセッション確立要求をセッション管理手段に送信する第一のＳＩＰセッション確立要求送信ステップと、
前記セッション管理手段が、
前記クライアントから前記第一のＳＩＰセッション確立要求を受信時にＡＰサーバがサービス受付不可能な状態の場合、前記ＡＰサーバがサービス受付可能な状態になったことを検出後、前記クライアントへ前記第二のＳＩＰセッション確立要求を送信し、前記クライアントとの間でＳＩＰセッションを確立するＳＩＰセッション確立ステップと、
前記クライアントが、
前記ＳＩＰセッション確立後、ＡＰサーバにサービスセッション確立要求を送信するサービスセッション確立要求送信ステップと
前記ＡＰサーバが、
前記ＳＩＰセッションが確立された場合、前記クライアントからの前記サービスセッション確立要求を受信した際、前記クライアントとの間で前記サービスセッションを確立するサービスセッション確立ステップと
を含むことを特徴とするセッション管理方法。
【請求項１４】
前記ＳＩＰセッション確立ステップは、前記クライアントから前記第一のＳＩＰセッション確立要求を受信時に前記ＡＰサーバがサービス受付不可能な状態の場合、前記第一のＳＩＰセッション確立要求の情報をコールバック管理テーブルに保存し、前記ＡＰサーバがサービス受付可能な状態になったことを検出した場合、前記コールバック管理テーブルを参照し、コールバック対象の前記第一のＳＩＰセッション確立要求を決定し、前記コールバック対象の前記第一のＳＩＰセッション確立要求の送信元の前記クライアントへ前記第二のＳＩＰセッション確立要求を送信することを特徴とする請求項１３記載のセッション管理方法。
【請求項１５】
更に、前記セッション管理手段が、前記第一のＳＩＰセッション確立要求をもとにサービスセッションを識別するためのサービスセッション情報の生成を行うセッション情報生成ステップと、
前記ＳＩＰ認証情報に対応するサービス認証情報の取得を行うサービス認証情報取得ステップと、
前記第二のＳＩＰセッション確立要求による前記ＳＩＰセッション確立時に、前記サービスセッション情報と前記サービス認証情報を前記ＡＰサーバに通知する、トランザクション許可ステップとを含み、
前記サービスセッション確立ステップは、前記クライアントからの前記サービスセッション確立要求を受信した際、前記サービスセッション情報と前記サービス認証情報を用いてユーザ認証を行い、前記ユーザ認証に成功した場合、前記クライアントとの間で前記サービスセッションを確立することを特徴とする請求項１３または１４に記載のセッション管理方法。
【請求項１６】
前記ＳＩＰセッション確立ステップは、前記ＡＰサーバのサービスセッション数と所定の最大許容セッション数との比較にもとづいて、前記ＡＰサーバがサービス受付可能かどうかを判定することを特徴とする請求項１３乃至１５のいずれかに記載のセッション管理方法。
【請求項１７】
前記ＳＩＰセッション確立ステップは、前記ＡＰサーバの負荷状態と所定の最大許容負荷との比較にもとづいて、前記ＡＰサーバがサービス受付可能かどうかを判定することを特徴とする請求項１３乃至１６のいずれかに記載のセッション管理方法。
【請求項１８】
前記ＳＩＰセッション確立ステップは、前記サービスセッションの使用帯域と所定の最大許容帯域との比較にもとづいて、前記ＡＰサーバがサービス受付可能かどうかを判定することを特徴とする請求項１３乃至１７のいずれかに記載のセッション管理方法。
【請求項１９】
コンピュータを、
クライアントから第一のＳＩＰセッション確立要求を受信時にＡＰサーバがサービス受付不可能な状態の場合、前記ＡＰサーバがサービス受付可能な状態になったことを検出後、前記クライアントへ第二のＳＩＰセッション確立要求を送信し、前記クライアントとの間でＳＩＰセッションを確立するセッション管理手段として機能させるためのプログラム。
【請求項２０】
前記セッション管理手段は、前記クライアントから前記第一のＳＩＰセッション確立要求を受信時に前記ＡＰサーバによるサービス受付不可能な状態の場合、前記第一のＳＩＰセッション確立要求の情報をコールバック管理テーブルに保存し、前記ＡＰサーバによるサービス受付可能な状態になったことを検出した場合、前記コールバック管理テーブルを参照し、コールバック対象の前記第一のＳＩＰセッション確立要求を決定し、前記コールバック対象の前記第一のＳＩＰセッション確立要求の送信元の前記クライアントへ前記第二のＳＩＰセッション確立要求を送信することを特徴とする請求項１９記載のプログラム。
【請求項２１】
前記セッション管理手段は、更に、前記第一のＳＩＰセッション確立要求をもとにサービスセッションを識別するためのサービスセッション情報の生成と、前記ＳＩＰ認証情報に対応するサービス認証情報の取得を行い、前記第二のＳＩＰセッション確立要求による前記ＳＩＰセッション確立時に、前記サービスセッション情報と前記サービス認証情報を前記ＡＰサーバに通知することを特徴とする請求項１９乃至２０のいずれかに記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はアプリケーションサーバによりサービスを提供する、アプリケーションサービスシステム、サーバシステム、セッション管理方法、及びプログラムに関する。
【背景技術】
【０００２】
アプリケーションサーバ（以後ＡＰサーバとする）がクライアントにサービスを提供するシステムにおいて、クライアントとＡＰサーバ間でＳＩＰ（Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）を使い、ＳＩＰセッションを事前に確立することにより、ＡＰサーバ利用時の認証を行う方法がある。
【０００３】
例えば、特許文献１には、クライアントとＡＰサーバ間に中継サーバを設置し、クライアント−中継サーバ間、中継サーバ−ＡＰサーバ間にＳＩＰセッションを確立し、中継サーバにおいてユーザ認証を行う方法が開示されている。
【０００４】
また、関連技術として、コンテンツ配信システムにおいて、端末装置がＳＩＰによりセッション制御サブシステムに帯域確保を依頼し、帯域予約を行う方法が特許文献２に開示されている。また、他の関連技術として、コンテンツ提供サービスにおいて、端末の現在接続数と最大同時接続数により、接続可否を判断する方法が特許文献３に開示されている。
【０００５】
【特許文献１】特開２００５−７３２３６号公報
【特許文献２】特開２００５−１２６５５号公報
【特許文献３】特開２００４−２４０６４１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述した特許文献１においては、ＡＰサーバが同時に提供できるサービス数の制限等によりＳＩＰセッションの確立に失敗した場合、クライアントが、ＳＩＰセッション確立要求の送信をＡＰサーバの状態が回復するまで繰り返す必要があった。
【０００７】
（発明の目的）
本発明の目的は、上述した課題を解決した、アプリケーションサービスシステム、サーバシステム、セッション管理方法、及びプログラムを提供することにある。
【課題を解決するための手段】
【０００８】
本発明のサーバシステムは、クライアントから第一のＳＩＰセッション確立要求を受信時にＡＰサーバがサービス受付不可能な状態の場合、前記ＡＰサーバがサービス受付可能な状態になったことを検出後、前記クライアントへ第二のＳＩＰセッション確立要求を送信し、前記クライアントとの間でＳＩＰセッションを確立するセッション管理手段と、前記ＳＩＰセッションが確立された場合、前記クライアントからのサービスセッション確立要求を受信した際、前記クライアントとの間でサービスセッションを確立する前記ＡＰサーバとを備えたことを特徴とする。
【０００９】
本発明のアプリケーションサービスシステムは、第一のＳＩＰセッション確立要求をサーバシステムに送信する手段と、前記サーバシステムから第二のセッション確立要求を受信した際、前記サーバシステムとの間でＳＩＰセッションを確立する手段と、
前記ＳＩＰセッション確立後、前記サーバシステムにサービスセッション確立要求を送信する手段とを有するクライアントと、前記クライアントから前記第一のＳＩＰセッション確立要求を受信時にＡＰサーバがサービス受付不可能な状態の場合、前記ＡＰサーバがサービス受付可能な状態になったことを検出後、前記クライアントへ前記第二のＳＩＰセッション確立要求を送信し、前記クライアントとの間で前記ＳＩＰセッションを確立するセッション管理手段と、前記ＳＩＰセッションが確立された場合、前記クライアントからの前記サービスセッション確立要求を受信した際、前記クライアントとの間で前記サービスセッションを確立する前記ＡＰサーバとを有する前記サーバシステムとを備えたことを特徴とする。
【００１０】
本発明のセッション管理方法は、クライアントが、第一のＳＩＰセッション確立要求をセッション管理手段に送信する第一のＳＩＰセッション確立要求送信ステップと、前記セッション管理手段が、前記クライアントから前記第一のＳＩＰセッション確立要求を受信時にＡＰサーバがサービス受付不可能な状態の場合、前記ＡＰサーバがサービス受付可能な状態になったことを検出後、前記クライアントへ前記第二のＳＩＰセッション確立要求を送信し、前記クライアントとの間でＳＩＰセッションを確立するＳＩＰセッション確立ステップと、前記クライアントが、前記ＳＩＰセッション確立後、ＡＰサーバにサービスセッション確立要求を送信するサービスセッション確立要求送信ステップと前記ＡＰサーバが、前記ＳＩＰセッションが確立された場合、前記クライアントからの前記サービスセッション確立要求を受信した際、前記クライアントとの間で前記サービスセッションを確立するサービスセッション確立ステップとを含むことを特徴とする。
【００１１】
本発明のプログラムは、コンピュータを、クライアントから第一のＳＩＰセッション確立要求を受信時にＡＰサーバがサービス受付不可能な状態の場合、前記ＡＰサーバがサービス受付可能な状態になったことを検出後、前記クライアントへ第二のＳＩＰセッション確立要求を送信し、前記クライアントとの間でＳＩＰセッションを確立するセッション管理手段として機能させることを特徴とする。
【発明の効果】
【００１２】
本発明の効果は、アプリケーションサービスシステムにおいて、ＳＩＰセッションの確立に失敗した際、クライアントがＳＩＰセッション確立要求の送信を繰り返す必要が無く、ＡＰサーバ状態回復後のセッション確立が効率化できることである。
【発明を実施するための最良の形態】
【００１３】
（第一の実施の形態）
次に、本発明の第一の実施の形態について図面を参照して詳細に説明する。
【００１４】
本発明の第一の実施の形態においては、ＳＩＰセッションの制御、アプリケーションサービスの提供は、ＩＰプロトコルを用いた通信により行われるものとする。また、ＳＩＰ認証情報として、ユーザ側クライアントが付与する送信元ＳＩＰ−ＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）が用いられるものとする。また、アプリケーションサービスのセッション（以下、サービスセッションとする）は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いたＨＴＴＰセッションであるものとする。また、ＡＰサーバが同時に提供できるサービスセッションの数には上限（最大許容セッション数）が予め決められており、ＡＰサーバのサービス受付可否の判定はサービスセッション数により行われるものとする。
【００１５】
図１は、本発明の第一の実施の形態の構成図である。図１を参照すると、本発明の第一の実施の形態におけるアプリケーションサービスシステム３００は、クライアント１００及びサーバシステム２００により構成される。サーバシステム２００は、セッション管理部２１０（セッション管理手段）及びＡＰサーバ２２０より構成される。クライアント１００とサーバシステム２００はネットワーク（図示せず）により接続される。
【００１６】
クライアント１００は、プログラム制御によって動作する情報処理装置であり、Ｗｅｂブラウザ等のアプリケーションにより、ＡＰサーバ２２０を利用する。クライアント１００は、ＡＰサーバ２２０の利用に先立ち、セッション管理部２１０との間でＳＩＰセッションを確立する。ＳＩＰセッションを確立すると、クライアント１００は、ＡＰサーバ２２０との間でサービスセッションを確立し、ＡＰサーバ２２０のアプリケーションに関する一連のトランザクションを実行する。
【００１７】
サーバシステム２００において、セッション管理部２１０は、ＳＩＰセッション確立要求の受付制御を行う。セッション管理部２１０は、また、ＡＰサーバ２２０がサービス受付不可能な状態のためにＳＩＰセッション確立ができない場合、ＡＰサーバ２２０の状態回復後に、クライアント１００に対して、ＳＩＰセッション確立のためのコールバックを行う。ＡＰサーバ２２０は、ＷｅｂサイトやＷｅｂアプリケーションによるサービスを提供する。セッション管理部２１０とＡＰサーバ２２０は、プログラム制御によって動作する情報処理装置であり、それぞれが独立した装置であってもよいし、１つの装置として構成されていてもよい。
【００１８】
図２は、サーバシステム２００をより詳細に示した構成図である。セッション管理部２１０は、メンバー管理ＤＢ２１１、セッション管理テーブル２１２、コールバック管理テーブル２１３、及びセッション数管理情報２１４を備える。メンバー管理ＤＢ２１１は、図１０に示すように、ユーザのＳＩＰ−ＵＲＩと、当該ユーザがＡＰサーバ２２０へアクセスする場合に使用するサービス認証情報（アカウントとパスワード）を記憶管理する。セッション管理テーブル２１２は、確立したセッションの情報として、図１１に示すように、セッション確立時刻、サービスセッション情報、メンバーＩＤ、ＳＩＰ−ＵＲＩ、及び要求内容（プロトコル種別）を記憶管理する。コールバック管理テーブル２１３は、クライアント１００からのＳＩＰセッション確立要求（第一のＳＩＰセッション確立要求）に対して、セッション確立ができない場合、当該ＳＩＰセッション確立要求に関する情報（ＳＩＰセッション確立要求情報）を記憶管理する。すなわち、コールバック管理テーブル２１３は、ＳＩＰセッション確立要求情として、図１２に示すように、ＳＩＰセッション確立要求の受付時刻、サービスセッション情報、メンバーＩＤ、ＳＩＰ−ＵＲＩ、要求内容（プロトコル種別）、及びサービス認証情報を記憶管理する。セッション数管理情報２１４は、図１３に示すように、確立しているサービスセッション数と最大許容セッション数を記憶管理する。なお、メンバー管理ＤＢ２１１の内容とセッション数管理情報２１４の最大許容セッション数は、予め設定されているものとする。ＡＰサーバ２２０は、サービス認証情報テーブル２２１を備える。サービス認証情報テーブル２２１は、図１４に示すように、メンバーＩＤ、サービスセッション情報、及びサービス認証情報を記憶管理する。
【００１９】
次に、本発明の第一の実施の形態の動作について図面を参照して説明する。
【００２０】
（ＳＩＰセッション確立成功時のサービスセッション確立）
はじめに、ＡＰサーバ２２０がサービス受付可能な状態にあり、クライアント１００からのＳＩＰセッション確立に成功し、クライアント１００からサービスセッションを確立する場合の動作について、図３及び図５を参照して説明する。
【００２１】
図３は、ＳＩＰセッション確立成功時のサービスセッション確立の動作を示すシーケンス図である。また、図５は、セッション管理部２１０における、ＳＩＰセッション確立要求受信時の処理フローである。
【００２２】
クライアント１００は、Ｗｅｂブラウザ等のアプリケーションにおいて、ＡＰサーバ２２０へのアクセス要求が発生すると、サーバシステム２００に、ＳＩＰセッション確立要求（第一のＳＩＰセッション確立要求）を送信する（ステップＳ１０１）。当該ＳＩＰセッション確立要求には、送信元であるクライアント１００のＳＩＰ−ＵＲＩ、サービスセッションのプロトコル種別（例えば、ＨＴＴＰ）が含まれている。
【００２３】
サーバシステム２００は、ＳＩＰセッション確立要求を受信すると（ステップＡ１０１）、セッション管理部２１０が、当該ＳＩＰセッション確立要求から送信元（クライアント１００）のＩＰアドレス、プロトコル種別、及び送信元ＳＩＰ−ＵＲＩを抽出する（ステップＳ１０２、Ａ１０２）。セッション管理部２１０は、当該ＳＩＰ−ＵＲＩがメンバー管理ＤＢ２１１に存在するかどうかを検索する（ステップＡ１０３）。セッション管理部２１０は、当該ＳＩＰ−ＵＲＩがメンバー管理ＤＢ２１１に存在しない場合（ステップＡ１０４／Ｎ）、ＳＩＰ−ＵＲＩによる認証失敗とし、クライアント１００にアクセス拒否応答を送信する（ステップＡ１１３）。セッション管理部２１０は、メンバー管理ＤＢ２１１に当該ＳＩＰ−ＵＲＩが存在する場合（ステップＡ１０４／Ｙ）、ＳＩＰ−ＵＲＩによる認証成功とし、当該ＳＩＰ−ＵＲＩに対するメンバーＩＤ、サービス認証情報を取得する（ステップＳ１０３、Ａ１０５）。セッション管理部２１０は、ＳＩＰセッション確立要求の送信元ＩＰアドレスとポート番号（ＳＩＰセッション確立要求から抽出されたプロトコル種別に対応するポート番号）の組み合わせを、サービスセッションを識別するためのサービスセッション情報とする（ステップＡ１０６）。セッション管理部２１０は、セッション数管理情報２１４を参照し、サービスセッション数が最大許容セッション数未満かどうかを確認する（ステップＳ１０４、Ａ１０７）。セッション管理部２１０は、サービスセッション数が最大許容セッション数未満であれば（ステップＡ１０７／Ｙ）、ＡＰサーバ２２０に、メンバーＩＤ、サービスセッション情報（ＩＰアドレス、ポート番号）、及びサービス認証情報（アカウント、パスワード）を含むトランザクション許可通知を送信する（ステップＳ１０５、Ａ１０８）。
【００２４】
ＡＰサーバ２２０は、トランザクション許可通知により受信したメンバーＩＤ、サービスセッション情報、及びサービス認証情報をサービス認証情報テーブル２２１に保存する（ステップＳ１０６）。
【００２５】
セッション管理部２１０は、クライアント１００にサービスセッションの開始の許可として、ＳＩＰセッション確立応答（ＯＫ応答）を送信する（ステップＳ１０７、Ａ１０９）。
【００２６】
クライアント１００は、ＯＫ応答を受信した場合、受信確認のＡＣＫ応答をサーバシステム２００に送信する（ステップＳ１０８）。これによりクライアント１００−セッション管理部２１０間でＳＩＰセッションが確立する。
【００２７】
セッション管理部２１０は、クライアント１００からＡＣＫ応答を受信すると（ステップＡ１１０）、セッション数管理情報２１４のサービスセッション数に１を加算し、更新する（ステップＳ１０９、Ａ１１１）。セッション管理部２１０は、セッション確立時刻、サービスセッション情報、メンバーＩＤ、ＳＩＰ−ＵＲＩ、及び要求内容（プロトコル種別）をセッション管理テーブル２１２に保存する（ステップＳ１１０、Ａ１１２）。
【００２８】
次に、クライアント１００は、ＳＩＰセッションの確立により、サービスセッションの開始（トランザクションの実行）が許可されたものとして、ＨＴＴＰセッション確立要求をサーバシステム２００に送信する（ステップＳ１１１）。当該ＨＴＴＰセッション確立要求には、サービスセッションのプロトコル種別（例えば、ＨＴＴＰ）に対応する宛先ポート番号が含まれている。
【００２９】
サーバシステム２００のＡＰサーバ２２０は、ＨＴＴＰセッション確立要求を受信すると、当該ＨＴＴＰセッション確立要求から、送信元（クライアント１００）のＩＰアドレスと宛先ポート番号を抽出する。ＡＰサーバ２２０は、サービス認証情報テーブル２２１を参照し、当該送信元ＩＰアドレス、宛先ポート番号の組み合わせと同じサービスセッション情報を検索し、サービス認証情報（アカウント、パスワード）を取得する（ステップＳ１１２）。ＡＰサーバ２２０は、取得したアカウント、パスワードによりアプリケーションサービスのユーザ認証を行い（ステップＳ１１３）、認証結果が正常であった場合、クライアント１００にＨＴＴＰセッション確立応答を送信する（ステップＳ１１４）。
【００３０】
クライアント１００とＡＰサーバ２２０は、要求されたＨＴＴＰセッションの通信を開始する（ステップＳ１１５）。
【００３１】
（ＳＩＰセッション確立失敗）
次に、ＡＰサーバ２２０がサービス受付不可能な状態のために、クライアント１００からのＳＩＰセッション確立が失敗する場合の動作について、図４及び図５を参照して説明する。
【００３２】
図４は、ＳＩＰセッション確立失敗時の動作を示すシーケンス図である。
【００３３】
クライアント１００がＳＩＰセッション確立要求を送信してから、サーバシステム２００のセッション管理部２１０が、サービスセッション情報を生成するまでの動作（ステップＳ１０１からＳ１０３、Ａ１０１からＡ１０６）については、「ＳＩＰセッション確立成功時」の動作と同様となる。
【００３４】
セッション管理部２１０は、セッション数管理情報２１４を参照し、サービスセッション数が最大許容セッション数未満かどうかを確認する（ステップＳ１０４、Ａ１０７）。セッション管理部２１０は、セッション数管理情報２１４を参照し、サービスセッション数が最大許容セッション数未満ではない場合（ステップＡ１０７／Ｎ）、クライアント１００に受付応答を送信する（ステップＳ１５１、Ａ１５１）。受付応答は、ＳＩＰセッションの確立要求を受け付けたが、ＡＰサーバ２２０がサービス受付不可能な状態にあるため、ＳＩＰセッションは確立せず、ＡＰサーバ２２０の状態が回復した際にクライアント１００にコールバックを行うことを示す。
【００３５】
クライアント１００は、受付応答を受信した場合、受信確認のＡＣＫ応答をサーバシステム２００に送信する（ステップＳ１５２）。
【００３６】
セッション管理部２１０は、クライアント１００からＡＣＫ応答を受信する（ステップＡ１５２）。セッション管理部２１０は、ステップＡ１０１にて受信したＳＩＰセッション確立要求の内容をもとにＳＩＰセッション確立要求情報を生成し、コールバック管理テーブル２１３に保存する（ステップＡ１５３）。すなわち、セッション管理部２１０は、受付時刻、サービスセッション情報、メンバーＩＤ、ＳＩＰ−ＵＲＩ、要求内容（プロトコル種別）、及びサービス認証情報をコールバック管理テーブル２１３に保存する（ステップＡ１５３）。
【００３７】
（サービスセッション切断）
次に、クライアント１００−サーバシステム２００間で、サービスセッションを確立している状態から、サービスセッション、ＳＩＰセッションを切断する動作について、図６及び図７を参照して説明する。
【００３８】
図６は、サービスセッション切断の動作を示すシーケンス図である。また、図７は、セッション管理部２１０における、サービスセッション切断時の処理フローである。
【００３９】
クライアント１００−ＡＰサーバ２２０間でデータ通信中（ステップＳ２０１）、サービス終了またはログアウト等が行われた場合（ステップＳ２０２）、ＡＰサーバ２２０は、クライアント１００にＨＴＴＰセッション終了要求を送信する（ステップＳ２０３）。
【００４０】
クライアント１００は、ＡＰサーバ２２０に、ＨＴＴＰ  ＡＣＫを送信し、ＨＴＴＰセッションを終了する（ステップＳ２０４）。
【００４１】
ＡＰサーバ２２０は、ＨＴＴＰセッションの終了後、サービス認証情報テーブル２２１から当該サービスセッションに関する情報を削除する（ステップＳ２０５）。ＡＰサーバ２２０は、サービスセッション情報を含むセッショントランザクション終了通知をセッション管理部２１０に送信する（ステップＳ２０６）。セッション管理部２１０は、トランザクション終了通知を受信すると（ステップＡ２０１）、クライアント１００にＳＩＰセッション切断要求を送信する（ステップＳ２０７、Ａ２０２）。ここで、ＳＩＰセッション切断要求は、セッション管理テーブル２１２から取得したサービスセッション情報内のＩＰアドレス、ＳＩＰ−ＵＲＩをそれぞれ送信先ＩＰアドレス、送信先ＳＩＰ−ＵＲＩとして送信される。
【００４２】
クライアント１００は、ＳＩＰセッション切断要求を受信すると、サーバシステム２００へＡＣＫ応答を送信する（ステップＳ２０８）。
【００４３】
セッション管理部２１０は、ＡＣＫ応答を受信すると（ステップＡ２０３）、セッション数管理情報２１４のサービスセッション数から１を減算し、更新する （ステップＳ２０９、Ａ２０４）。セッション管理部２１０は、セッション管理テーブル２１２から、当該ＳＩＰセッションに関する情報を削除する（ステップＳ２１０、Ａ２０５）。
【００４４】
（コールバックによるサービスセッション確立）
次に、ＡＰサーバ２２０の状態が回復し、サーバシステム２００からコールバックによりＳＩＰセッションを確立し、クライアント１００からサービスセッションを確立する動作について、図８及び図９を参照して説明する。
【００４５】
図８は、コールバックによるサービスセッション確立時の動作を示すシーケンス図である。また、図９は、セッション管理部２１０における、コールバック時の処理フローである。
【００４６】
サーバシステム２００のセッション管理部２１０は、ＡＰサーバ２２０に関する状態変化として、サービスセッションの切断によるサービスセッション数の減少を検出する（ステップＳ３０１、Ａ３０１）。セッション管理部２１０は、コールバック管理テーブル２１３を検索し、コールバック対象のＳＩＰセッション確立要求情報を取得する（ステップＳ３０２、Ａ３０２）。すなわち、セッション管理部２１０は、サービスセッション情報と、対応するメンバーＩＤ、ＳＩＰ−ＵＲＩ、要求内容（プロトコル種別）、及びサービス認証情報を取得する（ステップＳ３０２、Ａ３０２）。ここでは、コールバック対象として、受付時刻が最も古いＳＩＰセッション確立要求情報を選択するものとする。
【００４７】
セッション管理部２１０は、コールバック管理テーブル２１３にコールバック対象のＳＩＰセッション確立要求情報が存在しない場合（ステップＡ３０３／Ｎ）、ＡＰサーバ２２０の状態変化の検出（ステップＡ３０１）に戻る。
【００４８】
セッション管理部２１０は、コールバック管理テーブル２１３にコールバック対象のＳＩＰセッション確立要求情報が存在する場合（ステップＡ３０３／Ｙ）、クライアント１００にＳＩＰセッション確立要求（第二のＳＩＰセッション確立要求）を送信する（ステップＳ３０３、Ａ３０４）。ここで、ＳＩＰセッション確立要求は、コールバック管理テーブル２１３から取得したＳＩＰセッション確立要求情報におけるサービスセッション情報内のＩＰアドレス、ＳＩＰ−ＵＲＩをそれぞれ送信先ＩＰアドレス、送信先ＳＩＰ−ＵＲＩとして送信される。
【００４９】
クライアント１００は、ＳＩＰセッション確立要求を受信した場合、ＯＫ応答をサーバシステム２００に送信する（ステップＳ３０４）。ここで、クライアント１００は、ＳＩＰセッション確立要求を受け付けてよいかどうかをユーザに確認するようにしてもよい。
【００５０】
セッション管理部２１０は、クライアント１００からＯＫ応答を受信すると（ステップＡ３０５）、ＡＰサーバ２２０に、メンバーＩＤ、サービスセッション情報（ＩＰアドレス、ポート番号）、及びサービス認証情報（アカウント、パスワード）を含むトランザクション許可通知を送信する（ステップＳ３０５、Ａ３０６）。
【００５１】
ＡＰサーバ２２０は、トランザクション許可通知により受信したメンバーＩＤ、サービスセッション情報、及びサービス認証情報をサービス認証情報テーブル２２１に保存する（ステップＳ３０６）。
【００５２】
セッション管理部２１０は、クライアント１００にサービスセッションの開始の許可として、ＡＣＫ応答を送信する（ステップＳ３０７、Ａ３０７）。これによりクライアント１００−セッション管理部２１０間でＳＩＰセッションが確立する。セッション管理部２１０は、セッション数管理情報２１４のサービスセッション数に１を加算し、更新する（ステップＳ３０８、Ａ３０８）。セッション管理部２１０は、セッション確立時刻、サービスセッション情報、メンバーＩＤ、ＳＩＰ−ＵＲＩ、及び要求内容（プロトコル種別）をセッション管理テーブル２１２に保存する（ステップＳ３０９、Ａ３０９）。セッション管理部２１０は、当該ＳＩＰセッションに関するＳＩＰセッション確立要求情報をコールバック管理テーブル２１３から削除し、更新する（ステップＳ３１０、Ａ３１０）。
【００５３】
次に、クライアント１００は、ＳＩＰセッションの確立により、サービスセッションの開始（トランザクションの実行）が許可されたものとして、ＨＴＴＰセッション確立要求をサーバシステム２００に送信する（ステップＳ３１１）。
【００５４】
以降、ＨＴＴＰセッションを確立し、ＨＴＴＰセッションの通信を行うまでの動作（ステップＳ３１１からＳ３１５）は、「ＳＩＰセッション確立成功時」の動作（ステップＳ１１１からＳ１１５）と同様となる。
【００５５】
以上により、本発明の第一の実施の形態における動作が完了する。
【００５６】
本発明の第一の実施の形態によれば、アプリケーションサービスシステムにおいて、ＳＩＰセッションの確立に失敗した際、クライアントがＳＩＰセッション確立要求の送信を繰り返す必要が無く、ＡＰサーバ状態回復後のセッション確立が効率化できる。その理由は、セッション管理部２１０が、確立に失敗したＳＩＰセッションに関する情報を保持し、ＡＰサーバ２２０の状態変化を検出した際、当該ＳＩＰセッションの情報を基に、クライアント１００にＳＩＰセッション確立のコールバックを行うためである。
【００５７】
また、本発明の第一の実施の形態によれば、アプリケーションサービスシステムにおいて、ＡＰサーバのサービスセッション数に制限がある場合に、ＡＰサーバの利用効率を向上できる。その理由は、セッション管理部２１０が、当該サービスセッション数が許容値を超える場合、クライアント１００から要求されたＳＩＰセッション確立を失敗とし、当該サービスセッション数が減少した際、クライアント１００にコールバックを行うためである。
【００５８】
（第二の実施の形態）
次に、本発明の第二の実施の形態について図面を参照して詳細に説明する。
【００５９】
本発明の第二の実施の形態においては、サーバシステム２００において、サービスセッションに対するアクセス制御と帯域制御を行う点において、本発明の第一の実施の形態と異なる。なお、本発明の第二の実施の形態において、第一の実施の形態と同一の符号を有する構成要素については、特に説明の無い限り、第一の実施の形態と同一であるものとする。
【００６０】
図１５は、本発明の第二の実施の形態の構成図である。図１５を参照すると、本発明の第二の実施の形態におけるアプリケーションサービスシステム３００は、クライアント１００及びサーバシステム２００により構成される。クライアント１００とサーバシステム２００はネットワーク５００により接続される。
【００６１】
クライアント１００は、Ｗｅｂブラウザ等のクライアントアプリケーション（以下、クライアントＡＰとする）１１０、及びＳＩＰ終端部１２０より構成される。
【００６２】
サーバシステム２００は、セッション管理部２１０、ＡＰサーバ２２０、及びアプリケーションスイッチ（以下、ＡＰスイッチとする）２３０より構成される。
【００６３】
セッション管理部２１０は、メンバー管理ＤＢ２１１、セッション管理テーブル２１２、コールバック管理テーブル２１３、セッション数管理情報２１４、セッション制御部２１５、ＳＩＰ終端部２１６、帯域管理情報２１７、及びサーバ負荷管理情報２１８より構成される。
【００６４】
ここで、セッション制御部２１５は、サーバシステム２００内のセッション状態、ＡＰサーバ２２０の状態を監視制御する。また、セッション制御部２１５は、ＳＩＰセッション確立要求の受付制御、コールバック制御を行う。
【００６５】
セッション管理テーブル２１２は、確立したセッションの情報として、図２３に示すように、セッション確立時刻、サービスセッション情報、メンバーＩＤ、ＳＩＰ−ＵＲＩ、及び要求内容（プロトコル種別、帯域（上り／下り））を記憶管理する。なお、ここでは、サーバシステム２００がネットワーク５００からの受信する方向を上り方向、サーバシステム２００がネットワーク５００へ送信する方向を下り方向とする。コールバック管理テーブル２１３は、コールバック待ちのセッションの情報として、図２４に示すように、受付時刻、サービスセッション情報、メンバーＩＤ、ＳＩＰ−ＵＲＩ、要求内容（プロトコル種別、帯域（上り／下り））、サービス認証情報、コールバック回数、及び前回のコールバック時刻を記憶管理する。帯域管理情報２１７は、図２５に示すように、使用帯域（現在確立している各サービスセッションに確保されている帯域の総和）と最大許容帯域を、パケットの方向（上り／下り）別に記憶管理する。サーバ負荷管理情報２１８は、図２６に示すように、現在のＷｅｂサーバ２２２のサーバ負荷と最大許容負荷を記憶管理する。ここでは、例として、Ｗｅｂサーバ２２２の負荷として、ＣＰＵ使用利用率を用いているが、メモリ使用率等、他の負荷指標を用いてもよい。
【００６６】
なお、セッション制御部２１５は、定期的に、ＡＰサーバ２２０のサーバ負荷監視部２２４から、サーバの負荷状態（ＣＰＵ使用利用率）を取得し、サーバ負荷管理情報２１８内の”サーバ負荷”を更新しているものとする。
【００６７】
ＡＰサーバ２２０は、サービス認証情報テーブル２２１、Ｗｅｂサーバ２２２、プロセス管理部２２３、及びサーバ負荷監視部２２４より構成される。ここで、Ｗｅｂサーバ２２２は、ＷｅｂサイトやＷｅｂアプリケーションを提供する。プロセス管理部２２３は、Ｗｅｂサーバ２２２上でのトランザクションの状態を管理する。サーバ負荷監視部２２４は、Ｗｅｂサーバ２２２の負荷状態を監視する。
【００６８】
ＡＰスイッチ２３０は、スイッチ管理部２３１、アクセス制御部２３２、及び帯域制御部２３３より構成される。ここで、スイッチ管理部２３１は、アクセス制御部２３２と帯域制御部２３３の制御管理を行う。アクセス制御部２３２は、ネットワーク５００側からのパケットのフィルタリングを行う。帯域制御部２３３は、サービスセッションのパケットについて、帯域制御を行う。
【００６９】
ＡＰスイッチ２３０はプログラム制御によって動作する情報処理装置でもよい。また、セッション管理部２１０、ＡＰサーバ２２０、及びＡＰスイッチ２３０は、それぞれが独立した装置であってもよいし、いくつかを１つの装置として構成してもよい。
【００７０】
次に、本発明の第二の実施の形態の動作について図面を参照して説明する。
【００７１】
（ＳＩＰセッション確立成功時のサービスセッション確立）
はじめに、ＡＰサーバ２２０がサービス受付可能な状態にあり、クライアント１００からのＳＩＰセッション確立に成功し、クライアント１００からサービスセッションを確立する場合の動作について、図１６及び図１８を参照して説明する。
【００７２】
図１６は、ＳＩＰセッション確立成功時のサービスセッション確立の動作を示すシーケンス図である。また、図１８は、セッション管理部２１０における、ＳＩＰセッション確立要求受信時の処理フローである。
【００７３】
クライアント１００のクライアントＡＰ１１０は、ＡＰサーバ２２０へのアクセス要求が発生すると、ＳＩＰ終端部１２０に対し、アクセス要求を送信する（ステップＳ４０１）。ＳＩＰ終端部１２０は、サーバシステム２００に、ＳＩＰセッション確立要求（第一のＳＩＰセッション確立要求）を送信する（ステップＳ４０２）。当該ＳＩＰセッション確立要求には、送信元であるクライアント１００のＳＩＰ−ＵＲＩ、要求するサービスセッションのプロトコル種別、及び要求する帯域（上り／下り）が含まれている。
【００７４】
サーバシステム２００のＳＩＰ終端部２１６は、ＳＩＰセッション確立要求を受信すると、当該ＳＩＰセッション確立要求をセッション制御部２１５に転送する（ステップＳ４０３）。セッション制御部２１５は、当該ＳＩＰセッション確立要求から送信元（クライアント１００）のＩＰアドレス、プロトコル種別、帯域、及び送信元ＳＩＰ−ＵＲＩを抽出する（ステップＳ４０４、Ａ４０２）。セッション制御部２１５は、当該ＳＩＰ−ＵＲＩがメンバー管理ＤＢ２１１に存在するかどうかを検索する（ステップＡ４０３）。セッション制御部２１５は、当該ＳＩＰ−ＵＲＩがメンバー管理ＤＢ２１１に存在しない場合（ステップＡ４０４／Ｎ）、ＳＩＰ−ＵＲＩによる認証失敗とし、クライアント１００にアクセス拒否応答を送信する（ステップＡ４１７）。セッション制御部２１５は、メンバー管理ＤＢ２１１に当該ＳＩＰ−ＵＲＩが存在する場合（ステップＡ４０４／Ｙ）、ＳＩＰ−ＵＲＩによる認証成功とし、当該ＳＩＰ−ＵＲＩに対するメンバーＩＤ、サービス認証情報を取得する（ステップＳ４０５、Ａ４０５）。セッション制御部２１５は、ＳＩＰセッション確立要求の送信元ＩＰアドレスとポート番号（ＳＩＰセッション確立要求から抽出されたプロトコル種別に対応するポート番号）の組み合わせを、サービスセッションを識別するためのサービスセッション情報とする（ステップＡ４０６）。
【００７５】
セッション制御部２１５は、セッション数管理情報２１４を参照し、サービスセッション数が最大許容セッション数未満かどうかを確認する（ステップＡ４０７）。セッション制御部２１５は、サービスセッション数が最大許容セッション数未満であれば（ステップＡ４０７／Ｙ）、サーバ負荷管理情報２１８を参照し、サーバ負荷が最大許容負荷以下かどうかを確認する（ステップＡ４０８）。セッション制御部２１５は、サーバ負荷が最大許容負荷以下である場合（ステップＡ４０８／Ｙ）、帯域管理情報２１７を参照し、当該ＳＩＰセッション確立要求で要求された帯域を確保可能かどうかを、上り／下りの両方向について確認する（ステップＡ４０９）。すなわち、セッション制御部２１５は、要求された帯域を使用帯域に加算しても、最大許容帯域を越えないかどうかを上り／下りの両方向について確認する。セッション制御部２１５は、要求された帯域を確保可能な場合（ステップＡ４０９／Ｙ）、ＡＰサーバ２２０に、メンバーＩＤ、サービスセッション情報、及びサービス認証情報（アカウント、パスワード）を含むトランザクション許可通知を送信する（ステップＳ４０７、Ａ４１０）。
【００７６】
ＡＰサーバ２２０のプロセス管理部２２３は、トランザクション許可通知により受信したメンバーＩＤ、サービスセッション情報、及びサービス認証情報を、サービス認証情報テーブル２２１に保存する（ステップＳ４０８）。
【００７７】
セッション制御部２１５は、ＡＰスイッチ２３０に、サービスセッション情報（ＩＰアドレス、ポート番号）、及び帯域（上り／下り）を含むセッション制御開始要求を送信する（ステップＳ４０９、Ａ４１１）。
【００７８】
ＡＰスイッチ２３０のスイッチ管理部２３１は、セッション制御開始要求を受信すると、アクセス制御部２３２に、サービスセッション情報（ＩＰアドレス、ポート番号）を含むアクセス要求を送信する（ステップＳ４１０）。また、スイッチ管理部２３１は、帯域制御部２３３に対し、サービスセッション情報（ＩＰアドレス、ポート番号）と帯域（上り／下り）を含む帯域制御要求を送信する（ステップＳ４１２）。
【００７９】
アクセス制御部２３２は、アクセス要求を受信すると、サービスセッション情報にもとづき、ネットワーク５００側からのＩＰパケットをフィルタリングする。すなわち、アクセス制御部２３２は、サービスセッション情報で指定されたＩＰアドレスとポート番号を送信元ＩＰアドレス、宛先ポート番号に持つＩＰパケットのみを転送し、それ以外のＩＰパケットは廃棄し、サーバシステム２００内に流入させない。
【００８０】
帯域制御部２３３は、帯域制御要求を受信すると、サービスセッション情報と帯域にもとづき帯域制御を開始する。すなわち、帯域制御部２３３は、サービスセッション情報で指定されたＩＰアドレスとポート番号を送信元ＩＰアドレス、宛先ポート番号に持つＩＰパケットに対して、要求された帯域（上り）が確保されるように帯域制御を行う。同様に、帯域制御部２３３は、サービスセッション情報で指定されたＩＰアドレスとポート番号を宛先ＩＰアドレス、宛先ポート番号に持つＩＰパケットに対して、要求された帯域（下り）が確保されるように帯域制御を行う。スイッチ管理部２３１は、アクセス制御部２３２と帯域制御部２３３からの応答を受信した場合（ステップＳ４１１、Ｓ４１３）、セッション管理部２１０に対し、セッション制御開始応答を送信する（ステップＳ４１４）。
【００８１】
セッション制御部２１５は、セッション制御開始応答を受信すると（ステップＡ４１２）、ＳＩＰ終端部２１６を介し、クライアント１００に、サービスセッションの開始の許可として、ＳＩＰセッション確立応答（ＯＫ応答）を送信する（ステップＳ４１５、Ａ４１３）。
【００８２】
クライアント１００のクライアントＡＰ１１０は、ＳＩＰ終端部１２０を介し、ＯＫ応答を受信する。クライアントＡＰ１１０は、ＳＩＰ終端部１２０を介し、受信確認のＡＣＫ応答をサーバシステム２００に送信する（ステップＳ４１６）。これによりクライアント１００−セッション管理部２１０間でＳＩＰセッションが確立する。
【００８３】
セッション管理部２１０のセッション制御部２１５は、クライアント１００からＡＣＫ応答を受信すると（ステップＡ４１４）、セッション数管理情報２１４のサービスセッション数に１を加算、帯域管理情報２１７の使用帯域に要求された帯域を加算し、更新する（ステップＳ４１７、Ａ４１５）。セッション制御部２１５は、セッション確立時刻、サービスセッション情報、メンバーＩＤ、ＳＩＰ−ＵＲＩ、及びＳＩＰセッション確立要求時の要求内容（プロトコル種別、帯域）をセッション管理テーブル２１２に保存する（ステップＳ４１８、Ａ４１６）。
【００８４】
クライアント１００のクライアントＡＰ１１０は、ＳＩＰセッションの確立により、サービスセッションの開始（トランザクションの実行）が許可されたものとして、ＨＴＴＰセッション確立要求をサーバシステム２００に送信する（ステップＳ４１９）。当該ＨＴＴＰセッション確立要求には、サービスセッションのプロトコル種別（例えば、ＨＴＴＰ）に対応する宛先ポート番号が含まれている。
【００８５】
クライアント１００−サーバシステム２００間では、既にＳＩＰセッションが確立し、ＡＰスイッチ２３０には、送信元がクライアント１００で、クライアント１００により要求されたプロトコル種別のパケットが通過するように設定されている。従って、ＡＰスイッチ２３０は、クライアント１００から受信したＨＴＴＰセッション確立要求をＡＰサーバ２２０に転送する（ステップＳ４２０）。
【００８６】
ＡＰサーバ２２０のＷｅｂサーバ２２２は、ＨＴＴＰセッション確立要求を受信すると、当該ＨＴＴＰセッション確立要求から、送信元（クライアント１００）のＩＰアドレスと宛先ポート番号を抽出する。Ｗｅｂサーバ２２２は、当該ＩＰアドレスとポート番号を含むセッション認証情報要求を、プロセス管理部２２３に送信する（ステップＳ４２１）。プロセス管理部２２３は、サービス認証情報テーブル２２１を参照し、当該ＩＰアドレス、ポート番号の組み合わせと同じサービスセッション情報を検索し、サービス認証情報（アカウント、パスワード）を取得する（ステップＳ４２２）。プロセス管理部２２３は、取得したサービス認証情報をセッション認証情報応答として、Ｗｅｂサーバ２２２に送信する（ステップＳ４２３）。Ｗｅｂサーバ２２２は、セッション認証情報応答により取得したアカウント、パスワードにより、アプリケーションサービスのユーザ認証処理を行う（ステップＳ４２４）。Ｗｅｂサーバ２２２は、認証結果が正常の場合、クライアント１００にＨＴＴＰセッション確立応答を送信する（ステップＳ４２５）。
【００８７】
クライアント１００とＡＰサーバ２２０は、要求されたＨＴＴＰセッションの通信を開始する（ステップＳ４２７）。以降、サーバシステム２００のアクセス制御部２３２及び帯域制御部２３３は、スイッチ管理部２３１により設定されたサービスセッション情報、帯域にもとづいて、上り方向のパケットに対するフィルタリング、上り／下り方向の帯域制御を行う。
【００８８】
（ＳＩＰセッション確立失敗）
次に、ＡＰサーバ２２０がサービス受付不可能な状態のために、クライアント１００からのＳＩＰセッション確立が失敗する場合の動作について、図１７及び図１８を参照して説明する。
【００８９】
図１７は、ＳＩＰセッション確立失敗時の動作を示すシーケンス図である。
【００９０】
クライアント１００がＳＩＰセッション確立要求を送信してから、サーバシステム２００のセッション管理部２１０が、サービスセッション情報を生成するまでの動作（ステップＳ４０１からＳ４０５、Ａ４０１からＡ４０６）については、「ＳＩＰセッション確立成功時」の動作と同様となる。
【００９１】
セッション制御部２１５は、サービスセッション数が最大許容セッション数未満、サーバ負荷が最大許容負荷以下、帯域を確保可能のいずれかを満たせない場合（ステップＡ４０７／Ｎ、Ａ４０８／Ｎ、Ａ４０９／Ｎ）、クライアント１００に受付応答を送信する（ステップＳ４５１、Ａ４５１）。
【００９２】
クライアント１００は、受付応答を受信した場合、受信確認のＡＣＫ応答をサーバシステム２００に送信する（ステップＳ４５２）。
【００９３】
セッション制御部２１５は、クライアント１００からＡＣＫ応答を受信する（ステップＡ４５２）。セッション管理部２１０は、ＳＩＰセッション確立要求情報を生成し、コールバック管理テーブル２１３に保存する（ステップＡ４５３）。すなわち、セッション制御部２１５は、受付時刻、サービスセッション情報、メンバーＩＤ、ＳＩＰ−ＵＲＩ、要求内容（プロトコル種別、帯域）、及びサービス認証情報をコールバック管理テーブル２１３に保存する。
【００９４】
（サービスセッション切断）
次に、クライアント１００−サーバシステム２００間で、サービスセッションを確立している状態から、サービスセッション、ＳＩＰセッションを切断する動作について、図１９及び図２０を参照して説明する。
【００９５】
図１９は、サービスセッション切断の動作を示すシーケンス図である。また、図２０は、セッション管理部２１０における、サービスセッション切断時の処理フローである。
【００９６】
クライアント１００と、ＡＰサーバ２２０間でサービスセッション上のデータ通信中に（ステップＳ５０１）、サービス終了もしくはログアウトが行われた場合（ステップＳ５０２、Ｓ５０３）、ＡＰサーバ２２０のＷｅｂサーバ２２２は、クライアント１００にＨＴＴＰセッション終了要求を送信する（ステップＳ５０４）。
【００９７】
クライアント１００のクライアントＡＰ１１０は、ＡＰサーバ２２０に、ＨＴＴＰ  ＡＣＫを送信し、ＨＴＴＰセッションを終了する（ステップＳ５０６）。
【００９８】
Ｗｅｂサーバ２２２は、ＨＴＴＰセッションの終了後、プロセス管理部２２３に、サービスセッション情報を含んだトランザクション終了通知を送信する（ステップＳ５０８）。プロセス管理部２２３は、サービス認証情報テーブル２２１から、当該サービスセッションに関する情報を削除する（ステップＳ５０９）。プロセス管理部２２３はセッション管理部２１０に、サービスセッション情報を含んだトランザクション終了通知を送信する（ステップＳ５１０）。
【００９９】
セッション管理部２１０のセッション制御部２１５は、トランザクション終了通知を受信すると（ステップＡ５０１）、ＡＰスイッチ２３０に、セッション制御終了要求を送信する（ステップＳ５１１、Ａ５０２）。
【０１００】
ＡＰスイッチ２３０のスイッチ管理部２３１は、セッション制御終了要求を受信すると、アクセス制御部２３２に、サービスセッション情報を含むポート閉鎖要求を送信する（ステップＳ５１２）。また、スイッチ管理部２３１は、帯域制御部２３３に、サービスセッション情報を含む帯域開放要求を送信する（ステップＳ５１４）。
【０１０１】
アクセス制御部２３２は、ポート閉鎖要求を受信すると、サービスセッション情報で指定されたＩＰパケットの転送を停止する。
【０１０２】
帯域制御部２３３は、帯域開放要求を受信すると、サービスセッション情報で指定されたＩＰパケットに対して確保していた帯域を開放する。
【０１０３】
スイッチ管理部２３１は、アクセス制御部２３２と帯域制御部２３３からの応答を受信すると（ステップＳ５１３、Ｓ５１５）、セッション管理部２１０に対し、セッション制御終了応答を送信する（ステップＳ５１６）。
【０１０４】
セッション管理部２１０のセッション制御部２１５は、セッション制御終了応答を受信すると（ステップＡ５０３）、セッション制御部２１５は、ＳＩＰ終端部２１６を介し、ＳＩＰセッション切断要求をクライアント１００に送信する（ステップＳ５１７、Ａ５０４）。ここで、ＳＩＰセッション切断要求は、セッション管理テーブル２１２から取得したサービスセッション情報内のＩＰアドレス、ＳＩＰ−ＵＲＩをそれぞれ送信先ＩＰアドレス、送信先ＳＩＰ−ＵＲＩとして送信される。
【０１０５】
クライアント１００のクライアントＡＰ１１０は、ＳＩＰ終端部１２０を介し、切断要求を受信する。クライアントＡＰ１１０は、ＳＩＰ終端部１２０を介し、サーバシステム２００へＡＣＫ応答を送信し（ステップＳ５１８）、ＳＩＰセッションを終了する。
【０１０６】
セッション管理部２１０のセッション制御部２１５は、クライアント１００からＡＣＫ応答を受信する（ステップＡ５０５）。セッション制御部２１５は、セッション数管理情報２１４のサービスセッション数から１を減算、帯域管理情報２１７の使用帯域から、当該サービスセッションの要求帯域を減算し、更新する（ステップＳ５１９、Ａ５０６）。セッション制御部２１５は、セッション管理テーブル２１２から、当該ＳＩＰセッションに関する情報を削除する（ステップＳ５２０、Ａ５０７）。
【０１０７】
（コールバックによるサービスセッション確立）
次に、ＡＰサーバ２２０の状態が回復し、サーバシステム２００からコールバックによりＳＩＰセッションを確立し、クライアント１００からサービスセッションを確立する動作について、図２１及び図２２を参照して説明する。
【０１０８】
図２１は、コールバックによるサービスセッション確立時の動作を示すシーケンス図である。また、図２２は、セッション管理部２１０における、コールバック時の処理フローである。
【０１０９】
セッション管理部２１０のセッション制御部２１５は、ＡＰサーバ２２０の状態変化として、サービスセッションの切断によるサービスセッション数の減少、または、ＡＰサーバ２２０から取得したサーバ負荷状態の減少を検出する（ステップＳ６０１、Ａ６０１）。セッション制御部２１５は、コールバック管理テーブル２１３を検索し、コールバック対象のＳＩＰセッション確立要求情報を取得する（ステップＳ６０２、Ａ６０２）。すなわち、セッション制御部２１５は、サービスセッション情報と、対応するメンバーＩＤ、ＳＩＰ−ＵＲＩ、要求内容（プロトコル種別、帯域）、及びサービス認証情報を検索、取得する。ここでは、コールバック対象として、前回のコールバック時刻から（コールバック回数が０回の場合は、受付時刻から）予め決められたコールバック時間以上経過した、最も古いＳＩＰセッション確立要求情報を選択するものとする。
【０１１０】
セッション制御部２１５は、コールバック管理テーブル２１３にコールバック対象のＳＩＰセッション確立要求情報が存在しない場合（ステップＡ６０３／Ｎ）、ＡＰサーバ２２０の状態変化の検出（ステップＡ６０１）に戻る。
【０１１１】
セッション制御部２１５は、コールバック管理テーブル２１３にコールバック対象のＳＩＰセッション確立要求情報が存在する場合（ステップＡ６０３／Ｙ）、セッション数管理情報２１４を参照し、サービスセッション数が最大許容セッション数未満かどうかを確認する（ステップＡ６０４）。セッション制御部２１５は、サービスセッション数が最大許容セッション数未満であれば（ステップＡ６０４／Ｙ）、サーバ負荷管理情報２１８を参照し、サーバ負荷が最大許容負荷以下かどうかを確認する（ステップＡ６０５）。セッション制御部２１５は、サーバ負荷が最大許容負荷以下である場合（ステップＡ６０５／Ｙ）、帯域管理情報２１７を参照し、当該ＳＩＰセッション確立要求で要求された帯域を確保可能かどうかを、上り／下りの両方向について確認する（ステップＡ６０６）。セッション制御部２１５は、要求された帯域を確保可能な場合（ステップＡ６０６／Ｙ）、ＳＩＰ終端部２１６を介し、クライアント１００にＳＩＰセッション確立要求（第二のＳＩＰセッション確立要求）を送信する（ステップＳ６０４、Ａ６０７）。ここで、ＳＩＰセッション確立要求は、コールバック管理テーブル２１３から取得したＳＩＰセッション確立要求情報におけるサービスセッション情報内のＩＰアドレス、ＳＩＰ−ＵＲＩをそれぞれ送信先ＩＰアドレス、送信先ＳＩＰ−ＵＲＩとして送信される。
【０１１２】
セッション制御部２１５は、サービスセッション数が最大許容セッション数未満、サーバ負荷が最大許容負荷以下、帯域を確保可能のいずれかを満たさない場合（ステップＡ６０４／Ｎ、Ａ６０５／Ｎ、Ａ６０６／Ｎ）、ＡＰサーバ２２０の状態変化の検出（ステップＡ６０１）に戻る。
【０１１３】
クライアント１００のＳＩＰ終端部１２０は、ＳＩＰセッション確立要求を受信すると、クライアントＡＰ１１０に対し、アクセス要求を送信する（ステップＳ６０５）。クライアントＡＰ１１０は、アクセス要求を受信すると、ＳＩＰ終端部１２０を介し、ＯＫ応答をサーバシステム２００に送信する（ステップＳ６０６）。ここで、クライアントＡＰ１１０は、アクセス要求を受け付けてよいかどうかをユーザに確認するようにしてもよい。
【０１１４】
サーバシステム２００のセッション制御部２１５は、予め決められたタイムアウト時間以内に、クライアント１００からＯＫ応答を受信すると（ステップＡ６０８／Ｙ）、ＡＰサーバ２２０に、メンバーＩＤ、サービスセッション情報（ＩＰアドレス、ポート番号）、及びサービス認証情報（アカウント、パスワード）を含むトランザクション許可通知を送信する（ステップＳ６０７、Ａ６０９）。
【０１１５】
一方、セッション制御部２１５は、予め決められたタイムアウト時間以内に、クライアント１００からＯＫ応答を受信できない場合（ステップＡ６０８／Ｎ）、コールバック管理テーブル２１３を更新する（ステップＡ６１６）。このとき、セッション制御部２１５は、コールバック管理テーブル２１３における当該ＳＩＰセッション確立要求情報のコールバック回数に１を加算し、コールバック時刻を最新のコールバック時刻に更新する。更に、セッション制御部２１５は、コールバック対象のＳＩＰセッション確立要求情報の検索、取得（ステップＡ６０２）に戻り、次のコールバック対象についての処理を行う。なお、ステップＡ６１６において、コールバック回数の閾値を超えた場合、セッション制御部２１５は、当該ＳＩＰセッション確立要求情報を、コールバック管理テーブル２１３から削除するようにしてもよい。
【０１１６】
ＡＰサーバ２２０のプロセス管理部２２３は、トランザクション許可通知を受信すると、トランザクション許可通知に含まれるメンバーＩＤ、サービスセッション情報、及びサービス認証情報を、サービス認証情報テーブル２２１に保存する（ステップＳ６０８）。
【０１１７】
セッション制御部２１５は、ＡＰスイッチ２３０に、サービスセッション情報（ＩＰアドレス、ポート番号）、及び帯域（上り／下り）を含むセッション制御開始要求を送信する（ステップＳ６０９、Ａ６１０）。
【０１１８】
ＡＰスイッチ２３０のスイッチ管理部２３１は、セッション制御開始要求を受信すると、アクセス制御部２３２に、サービスセッション情報（ＩＰアドレス、ポート番号）を含むアクセス要求を送信する（ステップＳ６１０）。また、スイッチ管理部２３１は、帯域制御部２３３に対し、サービスセッション情報（ＩＰアドレス、ポート番号）と帯域（上り／下り）を含む帯域制御要求を送信する（ステップＳ６１２）。スイッチ管理部２３１は、アクセス制御部２３２と帯域制御部２３３からの応答を受信し（ステップＳ６１１、Ｓ６１３）、セッション管理部２１０に対し、セッション制御開始応答を送信する（ステップＳ６１４）。これによりクライアント１００−セッション管理部２１０間でＳＩＰセッションが確立する。
【０１１９】
セッション制御部２１５は、セッション制御開始応答を受信すると（ステップＡ６１１）、ＳＩＰ終端部２１６を介し、クライアント１００に、サービスセッションの開始の許可として、ＡＣＫ応答を送信する（ステップＳ６１５、Ａ６１２）。セッション制御部２１５は、セッション数管理情報２１４のサービスセッション数に１を加算、帯域管理情報２１７の使用帯域に要求された帯域を加算し、更新する（ステップＳ６１６、Ａ６１３）。セッション制御部２１５は、セッション確立時刻、サービスセッション情報、メンバーＩＤ、ＳＩＰ−ＵＲＩ、及びＳＩＰセッション確立要求時の要求内容（プロトコル種別、帯域）をセッション管理テーブル２１２に保存する（ステップＳ６１７、Ａ６１４）。セッション制御部２１５は、当該ＳＩＰセッションに関するＳＩＰセッション確立要求情報をコールバック管理テーブル２１３から削除し、更新する（ステップＳ６１８、Ａ６１５）。セッション制御部２１５は、コールバック対象のＳＩＰセッション確立要求情報の検索、取得（ステップＡ６０２）に戻り、次のコールバック対象についての処理を行う。
【０１２０】
次に、クライアント１００のクライアントＡＰ１１０は、ＳＩＰセッションの確立により、サービスセッションの開始（トランザクションの実行）が許可されたものとして、ＨＴＴＰセッション確立要求をサーバシステム２００に送信する（ステップＳ６１９）。
【０１２１】
以降、ＨＴＴＰセッションを確立し、ＨＴＴＰセッションの通信を行うまでの動作（ステップＳ６１９からＳ６２７）は、「ＳＩＰセッション確立成功時」の動作（ステップＳ４１９からＳ４２７）と同様となる。
【０１２２】
以上により、本発明の第二の実施の形態における動作が完了する。
【０１２３】
本発明の第二の実施の形態によれば、アプリケーションサービスシステムにおいて、ＡＰサーバの処理負荷によりサービスセッションを制限する場合に、ＡＰサーバの利用効率を向上できる。その理由は、セッション管理部２１０は、ＡＰサーバ２２０の処理負荷が許容値を超える場合、クライアント１００から要求されたＳＩＰセッション確立を失敗とし、当該処理負荷が許容値以下となった際、クライアント１００にコールバックを行うためである。
【０１２４】
また、本発明の第二の実施の形態によれば、アプリケーションサービスシステムにおいて、サービスセッション毎に帯域制御を行い、セッション毎の帯域の総和（使用帯域）によりサービスセッションを制限する場合に、ＡＰサーバの利用効率を向上できる。その理由は、セッション管理部２１０は、使用帯域が許容値を超える場合、クライアント１００から要求されたＳＩＰセッション確立を失敗とし、当該使用帯域が許容値以下となった際、クライアント１００にコールバックを行うためである。
【図面の簡単な説明】
【０１２５】
【図１】本発明の第一の実施の形態の構成を示す図である。
【図２】本発明の第一の実施の形態の構成を示す図において、サーバシステム２２０をより詳細に示した図である。
【図３】本発明の第一の実施の形態における、ＳＩＰセッション確立成功時の動作を示すシーケンス図である。
【図４】本発明の第一の実施の形態における、ＳＩＰセッション確立失敗時の動作を示すシーケンス図である。
【図５】本発明の第一の実施の形態における、セッション管理部２１０のＳＩＰセッション確立要求受信時の動作を示すフローチャートである。
【図６】本発明の第一の実施の形態における、サービスセッション切断時の動作を示すシーケンス図である。
【図７】本発明の第一の実施の形態における、セッション管理部２１０のサービスセッション切断時の動作を示すフローチャートである。
【図８】本発明の第一の実施の形態における、コールバックによるサービスセッション確立時の動作を示すシーケンス図である。
【図９】本発明の第一の実施の形態における、セッション管理部２１０のコールバック時の動作を示すフローチャートである。
【図１０】本発明の第一の実施の形態における、メンバー管理ＤＢ２１１の内容を示す図である。
【図１１】本発明の第一の実施の形態における、セッション管理テーブル２１２の内容を示す図である。
【図１２】本発明の第一の実施の形態における、コールバック管理テーブル２１３の内容を示す図である。
【図１３】本発明の第一の実施の形態における、セッション数管理情報２１４の内容を示す図である。
【図１４】本発明の第一の実施の形態における、サービス認証情報テーブル２２１の内容を示す図である。
【図１５】本発明の第二の実施の形態の構成を示す図である。
【図１６】本発明の第二の実施の形態における、ＳＩＰセッション確立成功時の動作を示すシーケンス図である。
【図１７】本発明の第二の実施の形態における、ＳＩＰセッション確立失敗時の動作を示すシーケンス図である。
【図１８】本発明の第二の実施の形態における、セッション管理部２１０のＳＩＰセッション確立要求受信時の動作を示すフローチャートである。
【図１９】本発明の第二の実施の形態における、サービスセッション切断時の動作を示すシーケンス図である。
【図２０】本発明の第二の実施の形態における、セッション管理部２１０のサービスセッション切断時の動作を示すフローチャートである。
【図２１】本発明の第二の実施の形態における、コールバックによるサービスセッション確立時の動作を示すシーケンス図である。
【図２２】本発明の第二の実施の形態における、セッション管理部２１０のコールバック時の動作を示すフローチャートである。
【図２３】本発明の第二の実施の形態における、セッション管理テーブル２１２の内容を示す図である。
【図２４】本発明の第二の実施の形態における、コールバック管理テーブル２１３の内容を示す図である。
【図２５】本発明の第二の実施の形態における、帯域管理情報２１７の内容を示す図である。
【図２６】本発明の第二の実施の形態における、サーバ負荷管理情報２１８の内容を示す図である。
【符号の説明】
【０１２６】
１００    クライアント
１１０    クライアントＡＰ
１２０    ＳＩＰ終端部
２００    サーバシステム
２１０    セッション管理部
２１１    メンバー管理ＤＢ
２１２    セッション管理テーブル
２１３    コールバック管理テーブル
２１４    セッション数管理情報
２１５    セッション制御部
２１６    ＳＩＰ終端部
２１７    帯域管理情報
２１８    サーバ負荷管理情報
２２０    ＡＰサーバ
２２１    サービス認証情報テーブル
２２２    Ｗｅｂサーバ
２２３    プロセス管理部
２２４    サーバ負荷監視部
２３０    ＡＰスイッチ
２３１    スイッチ管理部
２３２    アクセス制御部
２３３    帯域制御部
３００    アプリケーションサービスシステム
５００    ネットワーク
【図１】
2009116786.tif 000003
【図２】
2009116786.tif 000004
【図３】
2009116786.tif 000005
【図４】
2009116786.tif 000006
【図５】
2009116786.tif 000007
【図６】
2009116786.tif 000008
【図７】
2009116786.tif 000009
【図８】
2009116786.tif 000010
【図９】
2009116786.tif 000011
【図１０】
2009116786.tif 000012
【図１１】
2009116786.tif 000013
【図１２】
2009116786.tif 000014
【図１３】
2009116786.tif 000015
【図１４】
2009116786.tif 000016
【図１５】
2009116786.tif 000017
【図１６】
2009116786.tif 000018
【図１７】
2009116786.tif 000019
【図１８】
2009116786.tif 000020
【図１９】
2009116786.tif 000021
【図２０】
2009116786.tif 000022
【図２１】
2009116786.tif 000023
【図２２】
2009116786.tif 000024
【図２３】
2009116786.tif 000025
【図２４】
2009116786.tif 000026
【図２５】
2009116786.tif 000027
【図２６】
2009116786.tif 000028