JP5203919B2 - サーバシステム - Google Patents

Description

本発明は、通信ネットワークを介してＷｅｂ等によってユーザ（クライアント端末）に対してサービス（業務処理）を提供するサーバシステム（クライアントサーバシステム）に関し、特に、サービスの利用のためのログイン（セッション）の制御、及びトラフィックや負荷や性能などの制御に関する。

Ｗｅｂ等を利用してユーザにサービスを提供するサーバシステムは、一般的に、Ｗｅｂサーバ（プレゼンテーション（ＰＬ）サーバ）、アプリケーションサーバ（ビジネスロジック（ＢＬ）サーバ）、及びデータベース（ＤＢ）サーバの機能に分けて構成される、いわゆる三層構造を備えている。Ｗｅｂサーバ（ＰＬサーバ）は、ユーザの利用するクライアント端末とやり取りして、セッション管理や画面生成等に関する処理を行う。アプリケーションサーバ（ＢＬサーバ）は、提供するサービスに対応付けられる固有の業務（ＢＬ）処理を行う。ＤＢサーバは、業務処理に必要となる各種データをＤＢとして保持、管理する。

上記サーバシステムでは、サーバへの多数のアクセス（要求）の発生によるトラフィックの増大の傾向により、システムの増強が追いつかず、トラフィックの溢れ等による、輻輳、障害、システムダウン等のケースが多く発生している問題がある。そこで、例えばトラフィックの溢れ等を検知、予測すること等により、適切な対策を実行できるシステムが求められている。

上記に係わる従来技術として、特開２００４−２４６８３３号公報（特許文献１）には、サーバ負荷分散技術において、単位時間当たりの接続可能なセッション数の上限値と、単位時間当たりの確立したセッション数を管理し、エンドユーザ端末から新規のセッション確立要求を受信した際に、直近の単位時間当たりの確立したセッション数を上記上限値と比較し、上限値未満の場合は新規セッション確立要求を許可し、上限値以上の場合は新規セッション確立要求を廃棄することが記載されている。

また、特開２００７−２６５２４４号公報（特許文献２）には、Ｗｅｂシステムの性能を予測して将来の性能の溢れを予防するための技術について記載されている。

また、特開２００７−２６５２４５号公報（特許文献３）には、ネットワーク上でトラフィックを監視し、トラフィック量を推定し、リソース不足が予測されたとき、所定の対策プロセスを実行する技術について記載されている。
特開２００４−２４６８３３号公報 特開２００７−２６５２４４号公報 特開２００７−２６５２４５号公報

Ｗｅｂ等を利用したサーバシステムとして、企業のポータルサイトなどでは、各種多数のユーザ（クライアント端末）に対して複数のサービスが利用可能なように提供されていることが多い。サーバシステムの提供サービスなどに応じて、時間軸上でトラフィック量は大きく変動する。例えば、サービス（対応業務処理）として、証券システムにおける証券の売買注文のサービスや、情報閲覧サービスなどの場合、市場やニュースなどの状況に応じて、アクセス数が大きく変動する。

また、サーバシステムとして、各種多数のユーザ（クライアント端末）に対応して複数のチャネル（アクセスチャネル、サービスチャネル）で各種サービスを提供する形態の場合、それらチャネル毎にトラフィック変動特性に違いがみられる。

また、同じチャネルによるサービス提供の場合でも、ユーザ（クライアント端末）の属性に応じてサービスを提供するシステムもある。例えば、優良顧客や一般顧客といったユーザ属性の違いに応じて、異なる種類のサービスを提供するシステムがある。その場合、それらユーザ属性毎にトラフィック変動特性に違いがみられる。

上記各種多数のユーザのアクセス数の増大により、サーバシステム側では、ログイン処理やサービス処理におけるトラフィック量や負荷の増大により、各ユーザ（各チャネルや各ユーザ属性）に対して適切に応答することが困難になる。言い換えれば、システムの負荷を適切に制御できず、あるいはシステムの性能を適切に利用できず、前述の障害等を引き起こす可能性がある。また、ユーザ側にとっては、障害等により所望のサービスを利用できない不便に加え、所望のサービスに実際にアクセス（ログイン）を試みてみるまで当該サービスが利用可能な状態か否か等が不明であり、例えばサーバからの応答待ち状態が長く続くことにより、利便性もあまり高くないと感じる。

上記に係わる１つの対策としては、ユーザ（クライアント端末）からのアクセス（要求）を受けるサーバ（ＰＬサーバ）の前段に、負荷分散装置（ロードバランサ）を設け、後段の複数のサーバへの負荷分散や、アクセス（要求）の制限を行うことが挙げられる。あるいは、サービス処理（業務処理）を行うサーバ（ＢＬサーバ）の前段に、負荷分散装置を設けることが挙げられる。

また、他の対策として、アクセスを受け付ける前段のサーバ群（ＰＬサーバ）で処理するログイン（セッション）に係わる、サーバ群全体でのログイン数（ログイン状態セッション数）を所定の上限値未満に制限することが考えられる。

しかしながら、このような従来の制御の場合、各種のチャネル及びユーザ（ユーザ属性）のアクセスの特性や状況を反映した制御ではないので、適切な制限効果が得られない場合が多いという問題がある。例えば、チャネルＡで提供するサービス（あるいはユーザ属性Ａ向けのサービス）と、チャネルＢで提供するサービス（あるいはユーザ属性Ｂ向けのサービス）とがあり、Ｂのアクセスのみが急増している場合、Ａ，Ｂを含む全体に対しログイン数を所定値未満に制限する制御では、相対的にＡのアクセスが殆どつながらない状態になってしまう可能性がある。

本発明の目的は、各種多数のユーザ（クライアント）が所定のチャネルによりサーバの提供サービスにアクセスし、複数のチャネルや複数のユーザ属性などに応じて異なるサービスを提供可能であるサーバシステム等の技術に係わり、サーバシステム側にとって、アクセス数の変動（例えば突発的な増大）などに対しても、チャネルやユーザ属性などに応じてサーバの負荷や性能を調整して適切に対処、応答することができる技術を提供することである。また、ユーザ側にとって、システムやサービスの状態等がわかりやすいように応答が得られ、利便性を低下させない技術を提供することである。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下の通りである。

本形態は、ＰＬ層の複数の第１のサーバ（ＰＬサーバ）、ＢＬ層の複数の第２のサーバ（ＢＬサーバ）、及びＤＢ層の第３のサーバ（ＤＢサーバ）を有し、複数のユーザのクライアント端末からの通信ネットワークを介したアクセスに対し、前記第１のサーバを介して、前記第２及び第３のサーバによって処理されるサービスを前記クライアント端末に提供するサーバシステムである。前記第１のサーバは、例えばＷｅｂサーバ機能、セッション管理機能、画面制御機能などを備える。

前記第１のサーバは、前記ユーザのクライアント端末からの所定のチャネル（ＵＲＬ等）でのアクセス（要求）に対して、認証処理を含む、当該クライアント端末との間のセッションの確立に係わるログイン処理を行い、確立されたセッションで、当該クライアント端末からの要求に応じて、当該チャネルに応じた所定のサービスの処理を前記第２のサーバに要求して、前記第２のサーバにより前記第３のサーバのデータベースを読み書きして当該サービスを構成する業務処理を行わせ、その結果に基づき、応答画面データを生成して前記クライアント端末に送信して表示させる処理を行う。

前記第１のサーバは、前記チャネル、サービス、業務処理などの要素の対応付けの情報と、前記セッションに関するセッション管理情報と、前記複数の第１のサーバ（個別、グループ、全体など）と複数のユーザのクライアント端末との間の複数のチャネルでの複数のセッションに関する現在または直近のログイン数Ｎの情報と、前記ログイン数Ｎに関する判定用のしきい値である、前記チャネル単位での前記ログイン数Ｎの上限値Ｈの情報と、を保持する。前記しきい値としては、例えば、前記チャネル単位での前記ログイン数Ｎの上限値Ｈが設定される。

前記第１のサーバは、前記クライアント端末からのアクセスに対する前記ログイン処理の際に、前記ログイン数Ｎと前記しきい値（上限値Ｈ）とを比較し、当該ログインを制限するかの判定を行う処理と、前記判定に従い、前記ログインの制限を実行し、当該制限に対応する前記応答画面データを生成して前記クライアント端末へ送信して表示させる処理とを行う。

そして、前記第１のサーバは、前記クライアント端末からのアクセスに対する前記ログイン処理の際に、当該チャネル単位でのログイン数Ｎが当該上限値Ｈ以上の場合は、当該ログインを拒否するように制限する。

また更に、前記複数の第１のサーバに接続される制限管理部を有し、前記制限管理部は、前記複数の第１のサーバと通信して情報を授受することにより、前記複数の第１のサーバと複数のユーザのクライアント端末との間の複数のチャネルでの複数のセッションに関する現在または直近のログイン数Ｎの情報と、前記ログイン数Ｎに関する判定用のしきい値である、前記チャネル単位での前記ログイン数Ｎの上限値Ｈの情報と、を管理する処理を行う。

また更に、前記第２のサーバは、前記サービスを構成する業務処理の際に前記第３のサーバのデータベースに対して当該ユーザの属性の情報を読み書きする。前記第１のサーバは、前記ユーザのクライアント端末からのアクセスに対し、当該ユーザの属性に応じた所定のサービスを提供する。前記しきい値として、前記ユーザの属性の単位での前記ログイン数Ｎの上限値Ｈの情報を有する。前記第１のサーバは、前記クライアント端末からのアクセスに対する前記ログイン処理の際に、当該ユーザの属性の単位でのログイン数Ｎが当該上限値Ｈ以上の場合は、当該ログインを拒否するように制限する。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下の通りである。本発明の代表的な実施の形態によれば、サーバシステム側にとって、アクセス数の変動（例えば突発的な増大）などに対しても、チャネルやユーザ属性などに応じてサーバの負荷や性能を調整して適切に対処、応答することができる。また、ユーザ側にとって、システムやサービスの状態等がわかりやすいように応答が得られ、利便性を低下させない。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

図１〜図１５を用いて、本発明の一実施の形態のシステム（サーバシステムを含んで成る情報処理システム）について説明する。

＜概要＞
まず本実施の形態の概要や主な特徴については以下である。ユーザのクライアント端末から通信ネットワークを介して所定のチャネルでサーバのサービスにアクセスするサーバシステムにおいて、ログイン（セッション）管理及び画面制御等を行うＰＬサーバ（群）の層（ＰＬ層）において、チャネル単位、及びユーザ属性単位で、サービス制御（サービス提供可否判断等）を行うと共に、ログイン数（ログイン状態セッション数）Ｎを管理し、その現在値としきい値（上限値Ｈ）との比較により判定（制限判定）して当該ログイン（ログイン数）の制限を実行するように制御する。

クライアント端末からの所定のチャネルでのアクセス（要求）に対し、ＰＬサーバでは、認証を含むログイン（セッション確立）の処理を行うが、その際、ＰＬサーバ（群）における現在時のログイン数Ｎと、しきい値（上限値Ｈ）とを比較して、当該ログインを制限するか否か等を判定する。制限しない場合は通常通り応答してサービスを提供する。制限を実行する場合、その制限内容（種別）に対応した応答画面データを生成してクライアント端末に送信して表示させる。

チャネル単位は、ユーザが所定のサービスを利用する際に、クライアント端末から通信ネットワークを介してＰＬサーバへアクセスする際に通る経路の単位である。チャネルは、例えば、サービス利用環境、ユーザのクライアント端末や通信ネットワークにおける媒体の違い、例えば営業店の設置端末や、エンドユーザ（顧客）のＰＣやケータイ等の違いに対応付けられる。チャネルは、例えば、ＴＣＰ／ＩＰネットワーク、無線ネットワーク、専用線といった各種の通信手段における通信経路を利用する。また、当該サービスを提供するＷｅｂサイト（Ｗｅｂサーバ）にどのＷｅｂサイト（Ｗｅｂサーバ）からリンクしてきたか等によってもチャネルは異なり得る。また、チャネルは、ユーザが本サーバシステムにアクセスする際のＵＲＬなどによって識別することができる。なお、チャネルに対してサービス（業務処理）が対応付けられる場合には、チャネル単位とはサービス単位のことになる。また、チャネルに対してユーザ属性が対応付けられる場合には、チャネル単位とはユーザ属性単位のことになる。

ユーザ属性単位は、ユーザによる本システムのサービスの利用における属性である。例えば、あるシステムのサービスの利用の状況（履歴等）に基づいて、「優良」、「一般」といったような属性が与えられる（ユーザ属性を変動的な情報とする形態。例えば図２の例）。あるいは、予めのシステムのサービス利用契約などに基づいて、「優良」、「一般」といったような属性が与えられる（ユーザ属性を固定的な設定情報とする形態。例えば図１の例）。

サービスとは、ユーザ（クライアント端末）からの要求と当該要求に対する応答からなる一連の処理によって実現される単位を指す。サービスとして、例えば、証券システムにおける売買注文処理やポートフォリオ分析、シミュレーション等の業務、インターネットバンキングシステムにおける残高照会や振込処理、口座情報の照会など各種が該当する。また、サービスは、１つ以上の業務処理（ＢＬ処理）を組み合わせることで実現される。

本システムにおいて、ユーザ（クライアント端末）、ユーザ属性、チャネル、ＰＬサーバ、及びサービス（業務処理）等は、所定の対応付けで情報管理される。例えば、所定のユーザ（ユーザ属性）のクライアント端末が所定のチャネルを利用して所定のＰＬサーバにアクセスし所定のサービスを受ける。対応付けの例としては、同一チャネルで異なるユーザ属性を含む場合や、チャネル毎にユーザ属性を分ける場合などが考えられる。また他の例としては、同一チャネルで異なる複数のサービスを提供する場合や、チャネル毎にサービスを分ける場合などが考えられる。いずれもの形態も、システムの設計や設定によって実現可能である。

ログイン数Ｎとは、本サーバシステム（ＰＬサーバ）にユーザがログインした状態のセッションの数（ログイン状態セッション数）である。ログイン（セッション）管理処理により、各セッションはセッション管理情報として保持、管理されるので、当該情報を参照することでログイン数Ｎを把握することができる。

本ログイン制限管理のために、実装構成例としては、ＰＬサーバ（群）に接続される制限管理部（例えばサーバの形態）を設け、制限管理部では、ＰＬサーバ（全体、グループ、個別）のログイン数Ｎの情報や、そのしきい値（上限値Ｈ）の情報などを管理する。個別のＰＬサーバと制限管理部との間でそれら情報を授受する。各ＰＬサーバは、ログイン処理の際に、それら情報を用いて、ログイン制限を実行するか否か等を判定する。また、ＰＬサーバから制限管理部に対しセッション情報を集中的に管理する。

基本的な制御方法としては、ＰＬサーバ（制限管理部）でのログイン（セッション確立）処理の時に、チャネルやユーザ属性の情報を参照し、これらチャネルやユーザ属性の単位のしきい値（上限値Ｈ）を用いて比較判定することでログインの数を制限する。例えば、チャネル単位でログイン数Ｎを判定する（第１の制御方法）。あるいは、ユーザ属性単位でログイン数Ｎを判定する（第２の制御方法）。あるいは、チャネル単位とユーザ属性との両方でログイン数Ｎを判定する（第３の制御方法）。

判定方法としては、ＰＬサーバでは、ログイン処理の際、例えばチャネル単位のログイン数Ｎが上限値Ｈに達した場合、当該チャネルでのログインを制限（拒否）する（第１の制御方法）。あるいはユーザ属性単位のログイン数Ｎが上限値Ｈに達した場合、当該ユーザ属性でのログインを制限（拒否）する（第２の制御方法）。

制限実行内容に対応した応答画面としては、例えば、アクセスに対してログイン画面を表示させずに、混雑中などのメッセージ画面を表示する。あるいは、ログイン画面でのログイン情報入力に対し、ログインできない旨のメッセージを含むログイン拒否（失敗）画面を表示する。あるいは、ログイン画面でのログイン情報入力に対し、ログイン許可（成功）画面を表示するが、その時の状況に応じて当該ユーザが利用可能なサービスのメニュー項目を減少させた画面にする。

更なる機能として、上記ログイン制限のためのしきい値（上限値Ｈ）の設定を更新（変更）可能とする。例えば、管理者により手動で更新する手段や、プログラム処理により自動で更新する手段を設ける。例えば、システム監視処理により本システム（サーバ）の性能や負荷を監視し、その結果に基づき、しきい値（上限値Ｈ）の設定を更新する。例えば、時間軸上のログイン数の変動の検知や予測などに基づいて、状況に応じてしきい値（上限値Ｈ）を変化させることで、溢れなどの問題に対し効率的に対処することができる。

また、詳しい制御方法としては、１つのチャネルや１つのユーザ属性のみをみて判定するのではなく、複数のチャネルや複数のユーザ属性の存在に対し、それらの全体や複数間でのログインの数や割合を調整するように制御する。例えば、あるチャネルでのサービスの利用のためのログイン処理において、あるユーザ属性のユーザのアクセスが急増した場合、それにより別のユーザ属性のユーザのアクセスが圧迫されないように、当該急増したユーザ属性のユーザのアクセスにおけるログインを制限する。

＜システム（１）＞
図１において、本システムの概要や特徴を示している。本システム全体は、サーバシステム（サーバ側コンピュータシステム）とクライアント（クライアント端末）とが通信ネットワーク９０を介して接続される構成である。サーバシステムは、フロント（前段）側から順に、第１の負荷分散装置（ロードバランサ：ＬＢ１）４０１、ＰＬ層のＰＬサーバ（群）１００、第２の負荷分散装置（ロードバランサ：ＬＢ２）４０２、ＢＬ層のＢＬサーバ（群）２００、及びＤＢ層のＤＢ（ＤＢサーバ）３００を有する。また、これらに対して接続される、制限管理部（ログイン制限管理部）５００と、システム監視部６００とを有する。

クライアント側としては、ユーザが使用する各種、多数のクライアント端末が該当する。クライアント端末は、本サーバシステムを利用するための機能、即ち基本的な通信機能や、Ｗｅｂブラウザや他のアプリケーションプログラム等の機能を備える。クライアント端末は、例えば、ユーザ（顧客）が所有するパソコン（ＰＣ）や携帯電話機（ケータイ）、企業の営業店やコールセンタの設置端末、販売員の所持する携帯端末などを含む。尚ここでいう「ユーザ」や「クライアント」には、営業店やコールセンタ等も含める。

図１に示す例では、ユーザ（企業）として、コールセンタや営業店の設置端末を有する。これらは、例えば固定的に優先されるチャネル（Ａ，Ｂ）によって本システムにアクセスする。また、ユーザ（顧客）として、例えば、ユーザａは、媒体としてケータイを利用するユーザであり、ユーザ属性が「優良」の状態である。ユーザｂは、媒体としてＰＣを利用するユーザであり、ユーザ属性が「優良」の状態である。ユーザｃは、媒体としてケータイを利用するユーザであり、ユーザ属性が「一般」の状態である。ユーザｄは、媒体としてＰＣを利用するユーザであり、ユーザ属性が「一般」の状態である。各ユーザａ〜ｄは、それぞれ対応するチャネル（Ｃ〜Ｆ）によりアクセスする。図１の例では、予めサービス利用契約等に基づいてユーザ属性とチャネルとが対応付けられており、クライアント端末からのＰＬサーバ１００へのアクセスの際には、後段のＤＢ３１０内のユーザ属性情報などを参照せずとも、当該ユーザのユーザ属性を認識できる。

通信ネットワーク９０は、例えば、インターネットやイントラネット等、無線通信ネットワーク、専用線などを含む。各ユーザのクライアント端末は、所定のチャネルで、対応する通信ネットワーク９０を介して、本システム（本サーバシステムが提供するＷｅｂサイト等）にアクセスする。

各クライアント端末からのアクセスは、まずＬＢ１（４０１）に接続される。ＬＢ１（４０１）よりも前のネットワーク機器等については省略する。ＬＢ１（４０１）とＰＬサーバ（群）１００とが接続される。ＰＬサーバ（群）１００の各ＰＬサーバと、制限管理部５００とが接続される。ＰＬサーバ（群）１００は、ＬＢ２（４０２）と接続される。ＬＢ２（４０２）は、ＢＬサーバ（群）２００と接続される。ＢＬサーバ（群）２００は、ＤＢ（ＤＢサーバ）３００と接続される。システム監視部６００は、ＰＬサーバ１００やＢＬサーバ２００を監視する。制限管理部５００とシステム監視部６００とが接続される。また、ＰＬサーバ１００は、他のモジュール、例えば、外部システムのＢＬサーバなどと接続されてもよい。

ＰＬサーバ（群）１００及びＢＬサーバ（群）２００は、多数のアクセスを処理するために、複数の個別のＰＬサーバ、及びＢＬサーバにより冗長（多重）構成されている。なお、これらサーバ群の実装は、同一の機能を備える複数のサーバによる構成としてもよいし（即ち例えば複数のサービスを提供可能な機能を備える複数のサーバとする）、異なる機能を備えるサーバによる複数のグループに分けた構成としてもよい（即ち例えばチャネル−サービス毎に別のサーバグループとする）。図２は、上記複数のグループに分けた構成例の場合である。

ＬＢ１（４０１），ＬＢ２（４０２）は、ＰＬサーバ１００、ＢＬサーバ２００の冗長構成と対応して、これら複数のサーバへのアクセスの振り分けによる負荷分散を行う。これについては公知技術である。

各ＰＬサーバ１００は、まず、Ｗｅｂサーバ機能、認証、セッション管理、チャネル管理及びサービス管理などの基本的な処理機能を備える。その他に、各ＰＬサーバ１００は、特徴的なログイン管理を行う機能や制限管理部５００と通信する機能などを備える（図３）。

各ＢＬサーバ２００は、サービスに対応付けられる業務（ＢＬ）処理を行う基本的な処理機能を備える。ＤＢサーバ３００（ＤＢ３１０）には、サービス（業務処理）に係わるデータ情報が格納される。このデータ情報には、ユーザ属性情報も含む。

制限管理部５００は、各ＰＬサーバ１００との間で通信して情報を授受することで、内部のＤＢに、ＰＬサーバ１００のログイン数（ログイン状態セッション数）Ｎと、そのログイン数Ｎに関する判定用のしきい値である上限値Ｈとを含む情報を保持、管理する。また、制限管理部５００は、ログイン数Ｎを定期的にチェック（更新）する処理や、上限値Ｈを必要に応じて更新する処理などを行う。

制限管理部５００及びＰＬサーバ１００は、ＤＢの情報（Ｎ，Ｈ）に基づき、各チャネルでのアクセスによる本システム（提供サービス）へのログイン（セッション確立）を制限する制御を行う。制限されたユーザのクライアント端末に対しては、対応する応答画面データを送信して表示させることで適切に対処する。例えば、アクセス数が増大した時に、各チャネル単位またはユーザ属性単位のログイン数Ｎの上限値Ｈによる判定に基づき、特定のチャネル単位またはユーザ属性単位のログイン数Ｎを上限値Ｈ未満に制限する。これにより、制限された以外のチャネル単位またはユーザ属性単位では、その分、ログインの数に余裕ができる。

図１の例では、エンドユーザ（顧客）のＷｅｂのアクセスにおいて、クライアント端末におけるＰＣとケータイなどの違いに対応して別のチャネルでサービスを提供している。更に、制限実行の際、ユーザ属性が「優良」のユーザａ，ｂのチャネルＣ，Ｄでのログインはそのまま制限無しで許可し、「一般」のユーザｃ，ｄのチャネルＥ，Ｆでのログインは制限して拒否している。また例えば、ＰＣとケータイではＰＣの方が画面データ量が重いこと等を考慮して、ＰＣの「一般」のユーザのチャネルＦでのログインを強く制限することで制限効果を高くしている。

上記のようにチャネルやサービスに対して所定のユーザ属性を対応付けることができる。例えば、特定のユーザ属性（例えば「優良」）のユーザに対して特定のチャネルでのサービスを提供してもよい。

また、システム監視部６００は、システム（ＰＬサーバ１００、ＢＬサーバ２００、及びＤＢ３００やＬＢ１（４０１），ＬＢ２（４０１）等）の負荷や性能を監視する。その監視結果情報に基づき、制限管理部５００は、上限値Ｈの設定値を必要に応じて更新する。例えば、システムの負荷が高く性能が低下した状態の時、あるチャネルの上限値Ｈを高くし、別のチャネルの上限値Ｈを低くして調整するといったことが可能である。

＜システム（２）＞
図２において、本システムの構成例として、ユーザ（クライアント端末）、ユーザ属性、チャネル、ＵＲＬ（アドレス）、ＰＬサーバ、サービス等の対応付けに関する構成例を示している。図２に示す例は、所定のチャネル（ＵＲＬ）と所定のＰＬサーバグループとを対応付ける場合である。また、ＰＣやケータイ等の媒体毎の複数のチャネル、及び同一チャネル内に異なるユーザ属性（「優良」、「一般」）が混在する場合である。例えば、チャネルＡ，Ｂはコールセンタ等の固定優先用であり、チャネルＣ，ＤはＷｅｂ（顧客）のケータイ用、ＰＣ用である。各チャネルに対し特定のＰＬサーバ１００のグループが対応付けられる。例えばケータイ用のチャネルＣ（ＵＲＬ−Ｃ）のアクセスはグループＣで処理しケータイ用のサービスを提供する。ＰＣ用のチャネルＤ（ＵＲＬ−Ｄ）のアクセスはグループＤで処理しＰＣ用のサービスを提供する。

図２の例では、ユーザ属性は、サービス利用状況等（例えばＤＢ３１０の口座残高情報など）に応じて随時変動する情報である。クライアント端末からのＰＬサーバ１００へのアクセスの際には、後段のＤＢ３１０内のユーザ属性情報などを参照することで、当該ユーザのユーザ属性を認識する。また、ユーザは、自身のユーザ属性を認識している必要は無く、サーバシステム側が情報として管理及び認識する。

ＰＬサーバ（群）１００の構成例として、チャネル（例えばＡ〜Ｄ）毎にグループ（例えばＡ〜Ｄ）に分けられている。例えば、ＰＬサーバ１００のグループＡは、複数のＰＬサーバ（＃１〜＃ｍ）から成り、所定のチャネルＡ（ＵＲＬ−Ａ）に対応付けられ、所定のサービス（例えばサービスＡ，Ｂ，Ｃ）を提供する。グループＢ，Ｃ，Ｄについても同様であり、それぞれ別のチャネルＢ，Ｃ，Ｄに対応付けられる。ＬＢ１（４０１）からグループ内の複数のＰＬサーバ１００へ負荷分散が行われる。なお前述のように、各ＰＬサーバグループで同じサービスを提供する形態も、各グループで異なるサービスを対応付ける形態も可能である。

個別のＰＬサーバ１００は、それぞれ、ログイン管理処理を行うことで、自サーバ単位におけるログイン数Ｎの情報を持つ。制限管理部５００は、それら個別のＰＬサーバ単位のログイン数Ｎの情報を取得する。これにより、制限管理部５００は、ＤＢで、個別、グループ、及び全体のそれぞれの単位のログイン数Ｎを把握することができる。例えば各グループＡ〜Ｄのログイン数Ｎ（ＮＡ〜ＮＤ）、及び全体のログイン数Ｎ０が把握できる。また、個別のＰＬサーバ１００は、制限管理部５００からそれらの情報（個別、グループ、全体のログイン数Ｎ）を取得することで、自サーバ内に保持し、自サーバを含むグループや全体の状態を把握することができる。

また、制限管理部５００は、各種ログイン数Ｎに関するしきい値である上限値Ｈ（個別、グループ、全体の上限値Ｈ）を保持している。例えば、上記各グループＡ〜Ｄのログイン数Ｎ（ＮＡ〜ＮＤ）、及び全体のログイン数Ｎ０に対応した上限値｛ＨＡ〜ＨＤ，Ｈ０｝を保持している。各ＰＬサーバ１００は、制限管理部５００からそれら上限値Ｈの情報を取得して把握することができる。

ＰＬサーバ（群）１００全体のログイン数ＮをＮ０、その上限値をＨ０とする。第１のＰＬサーバグループＡのログイン数ＮをＮＡ、その上限値をＨＡとする。その他も同様である。また、上限値Ｈの情報は例えばログイン数Ｎの情報などと共に授受されてもよい。

また、ログイン数Ｎ及び上限値Ｈは、チャネル単位、ユーザ属性単位などの制御単位に応じて、それぞれの値が管理される。例えば、チャネル単位のログイン数Ｎの制限を行う第１の制御方法の場合には、それに対応した種類のチャネル単位のログイン数Ｎ及び上限値Ｈを用いて制御する。図２の例では、チャネル単位のログイン数Ｎは、グループ単位のログイン数Ｎ（ＮＡ〜ＮＤ）である。またこの例では、同一チャネル内で異なるユーザ属性（優良、一般）が混在する形態であり、ユーザ属性単位でのログイン数Ｎ及び上限値Ｈの管理は必要無い。ユーザ属性単位での制限を行う第２の制御方法の場合には、第１の制御方法と同様に、ユーザ属性単位でのログイン数Ｎ及び上限値Ｈを管理する。

制限の例として、Ｘは、チャネルＡ，Ｂについての制限、Ｙは、ケータイ用のチャネルＣについての制限、Ｚは、ＰＣ用のチャネルＤについての制限である。例えば、Ｘ，Ｙ，Ｚの順で制限が強くなる（ログイン、サービス提供に関する優先度が低くなる）。また、ユーザ属性単位で制限する場合は、例えばユーザ属性が「優良」のユーザａ，ｂに対してＹの制限を適用し、ユーザ属性が「一般」のユーザｃ，ｄに対してＺの制限を適用する、といったようになる。

＜システム（３）＞
図３において、本システムの各サーバ等の内部詳細構成例を示している。図３に示す例は、制限管理部５００主体でセッション集中管理を行い、また、個別ＰＬサーバ１００主体でログイン制限判定及び実行を行う形態である。

制限管理部５００やシステム監視部６００は、例えば特定のサーバ（制限管理サーバ、システム監視サーバ）の形態で実装される。なお、各サーバは、所定のハードウェア及びソフトウェアにより実装される。例えば、１台のサーバ装置において、プロセッサ、メモリ、通信インタフェース等を備え、プロセッサによるメモリ上のプログラムの実行や、専用回路の機能により、サーバ機能を実現する。各サーバは、物理的にそれぞれ別の機器に構築されていてもよいし、一部または全部が同一の機器に論理的に分かれて構築されていてもよい。物理的に別の機器で構築されている場合は、各サーバはＬＡＮ等によって接続される。

本システムで特徴的な処理部としては、ログイン数Ｎ更新部５２、上限値Ｈ設定部５３、制限判定部１４、及び制限実行部１５が挙げられる。ＰＬサーバ１００と制限管理部５００とにおいて、これらの処理部を少なくとも一方側に備える。あるいは、これらの処理部を主−従のモジュールとして両方側に備えてもよい。

＜ＰＬサーバ＞
ＰＬ層において、ＰＬサーバ１００は、ログイン管理部（セッション管理部）１０、画面制御部（応答制御部）２０、図示しない公知のＷｅｂサーバ機能、通信機能などを備える。ログイン管理部１０は、認証処理部１１、チャネル−サービス制御部１２、ログイン処理部（セッション処理部）１３、制限判定部１４、制限実行部１５、通信部１６、ユーザ属性制御部１７、並びに、セッション管理情報３１、制限管理情報３２、チャネル−サービス管理情報３３などを備える。

ログイン管理部１０は、ユーザのクライアント端末からのアクセスに対する本システムへのログイン（セッション確立）の処理（ログイン処理）、及びその処理を管理する処理（ログイン（セッション）管理処理）を行う。

認証処理部１１は、クライアント端末からのアクセスに際して、種々の認証の要否を識別し、所定の方式による認証処理を行う。この認証処理自体は公知技術である。ここでの認証には、例えば、デジタル証明書による認証や、ワンタイムパスワードによる認証、Ｃｏｏｋｉｅによる認証、その他チャネル固有の認証などがある。

チャネル−サービス制御部１２は、チャネル−サービス管理情報３３を管理し、チャネル、サービスなどの要素の対応付けの管理、チャネル単位の利用可否判定やサービス単位の提供可否判定などを制御する。チャネル単位でのログイン制限の制御のために、チャネル−サービス制御部１２等を用いる。チャネル−サービス制御部１２は、ＢＬサーバ２００（あるいは外部システムの機能）に対し要求を送り、応答として処理結果を受信する。

ログイン処理部１３は、認証処理部１１、チャネル−サービス制御部１２、制限判定部１４、通信部１６などを用いて、ログイン（セッション）処理を行う。ログイン処理部１３（またはセッション集中管理部５１）では、ユーザ（クライアント端末）からのアクセスによるログイン処理の際、クライアント端末とのセッションに関するセッション管理情報３１（セッション情報）を作成、または、参照、更新、削除等する。ログイン管理部１０（またはセッション集中管理部５１）では、新規のログイン時には、新規のセッション情報を作成する。また、その後の同ユーザのアクセス時には、当該セッション情報の内容を更新する。ログイン処理部１３は、セッション管理情報３１の作成、更新、削除等に伴い、自サーバにおけるログイン数Ｎを、レコード数のカウント等により把握することができる。

制限判定部１４は、ユーザ（クライアント端末）からのアクセスによるログイン処理時に、最新のログイン数Ｎと、それに対応する種類の上限値Ｈとの比較により、当該アクセスによるログインを制限するか否か等を判定する。

制限実行部１５は、制限判定部１４の判定結果に従って、対応するログイン制限を実行する。例えば、アクセス（ログイン）の拒否に対応する応答画面データを画面制御部２０により生成させ、クライアント端末へ送信して表示させる。

通信部１６は、制限管理部５００内の処理部との間で情報を授受する通信を行う。例えば、ログイン処理部１３からの指示に従い、通信部１６は、制限管理部５００内のログイン数Ｎ更新部５２と通信し、ログイン数Ｎの情報を授受する。また同様に、通信部１６は、制限管理部５００内の上限値Ｈ設定部５３と通信し、上限値Ｈの情報を授受する。ログイン処理部１３は、自サーバにおけるログイン数Ｎを更新し、また、通信部１６により制限管理部５００（ログイン数Ｎ更新部５２）と通信して当該情報を授受する。

ＰＬサーバ（群）１００における個別のＰＬサーバは、通信部１６を介して、制限管理部５００との間で情報を授受することで、自サーバ、グループ、及び全体における現在時のログイン数Ｎと、それに対応する上限値Ｈとを把握できる。この現在時のログイン数Ｎは、厳密にはリアルタイムの状況を反映した値ではないが、その近似値として把握することができ、問題無く制御に使用できる。

また更に、ユーザ属性単位で制御する形態の場合は、ユーザ属性制御部１７を用いて制御する。ユーザ属性制御部１７では、ユーザ属性とチャネルやサービス等の要素との対応付けを管理し、ユーザ属性単位でのサービス提供可否判定などを制御する。

画面制御部２０は、Ｗｅｂサーバ機能によって、クライアント端末（Ｗｅｂブラウザ等）からの要求に従って、ログイン管理部１０、ＢＬサーバ２００等を通じて処理された結果に基づいて、応答画面データを生成して、要求元のクライアント端末に送信して表示させる。応答画面データ（ログインやサービスの応答情報）は、保持している画面用ファイル等のデータ（例えばＨＴＭＬ形式）をもとに生成される。クライアント端末では、Ｗｅｂブラウザ等によって、当該応答画面データが表示装置画面に表示され、ユーザが閲覧することができる。画面制御部２０は、ログイン制限時に、対応する種類の応答画面データを生成する処理を行う。

＜制限管理部＞
制限管理部５００（制限管理サーバ）は、セッション集中管理部５１、ログイン数Ｎ更新部５２、上限値Ｈ設定部５３、並びに、セッション管理ＤＢ４１、制限管理ＤＢ４２などを備える。

セッション集中管理部５１は、ＰＬサーバ（群）１００における各セッション管理情報（３１と対応関係）をセッション管理ＤＢ４１に集中的に管理する機能である。各ＰＬサーバ１００は、自サーバにおけるセッション管理情報３１を、通信部１６及び制限管理部５００のセッション集中管理部５１を介して、セッション管理ＤＢ４１に読み書きする。または、個別ＰＬサーバ主体でセッション管理する形態の場合は、制限管理部５００が各ＰＬサーバ１００からセッション管理情報３１を取得、収集するようにしてもよい。

ログイン数Ｎ更新部５２は、セッション管理ＤＢ４１を参照したり、各ＰＬサーバ１００との間で情報を授受したりすることで、ＰＬサーバ（群）１００における全体、グループ、及び個別の各ログイン数Ｎを定期的にチェック（更新）し、またそれらのログイン数Ｎをチャネル単位やユーザ属性単位でＤＢ（４２）に管理し、把握する機能である。

上限値Ｈ設定部５３は、設定や制御に基づき、チャネル単位やユーザ属性単位でのログイン数Ｎに係わるそれぞれの上限値Ｈの情報を設定（更新）する機能である。これにより設定される情報は、制限管理ＤＢ４２に保持される。

セッション管理ＤＢ４１は、ＰＬサーバ（群）１００における各セッション管理情報（３１と対応関係）が集中的に管理されるＤＢである。制限管理ＤＢ４２は、ＰＬサーバ（群）１００における上記各ログイン数Ｎ及び上限値Ｈの情報（３２と対応関係）が総合的に管理されるＤＢである。

上限値Ｈ設定部５３は、システム監視部６００や設定部７００からの制御や設定に基づき、各上限値Ｈを更新（変更）する。設定部７００は、例えばシステム管理者による手動の設定を行う場合に使用されるインタフェースである。

セッション集中管理部５１は、ログイン管理部１０と通信することで、新規のログイン処理時にはセッション情報を作成してセッション管理ＤＢ４１に書き込み、また同ユーザのその後のアクセス時には同セッション情報の内容を更新する。また、セッション集中管理部５１は、セッション管理ＤＢ４１内のセッション情報を定期的にチェックして、所定の契機、条件で削除する。例えば、セッション集中管理部５１は、セッション管理ＤＢ４１内の複数のセッション情報のレコードのうち、保持時間（セッション作成・更新日時からの経過時間）が一定時間（例えば１０分、２０分単位など）を越えたレコードを削除する。このように定期削除しておくことで、当該セッション情報のレコード数を確認するだけで、現在時（最新）のログイン数Ｎ（近似値）を把握することができる。

ユーザが正式なログアウト手続きをせずに切断した場合などは、該当のセッション情報のレコードが存在していても当該ユーザがその時ログイン状態であるとは限らない。これについては、アクセス時の単純なカウントだけでなく、上記セッション情報の定期削除などの対処により、ログイン数Ｎ（近似値）を把握することができる。

＜ＢＬサーバ、ＤＢ＞
ＢＬ層のＢＬサーバ２００において、サービス−ＢＬ制御部２１０は、ＰＬサーバ１００側から要求された所定のサービスに対応付けられる業務（ＢＬ）処理を制御し、また必要に応じてユーザ属性情報確認処理なども行う。業務モジュール２２０は、サービス−ＢＬ制御部２１０からの制御に従って、個別の業務処理を実行する。ＢＬサーバ２００（サービス−ＢＬ制御部２１０及び業務モジュール２２０）による処理では、ＤＢサーバ３００の業務ＤＢ３１０を読み書きして処理を行い、また、業務ＤＢ３１０内に格納されるユーザ属性情報（Ｕで示す）を読み書きする。業務ＤＢ３１０は、例えば口座情報ＤＢなどである。

ＢＬサーバ２００では、要求されたサービスに対応付けられる業務（ＢＬ）処理を実現するために必要となる１つ以上の業務モジュール２２０が、順次または並列で実行される。また、複数のＢＬサーバ２００の業務モジュール２２０の連携によりサービスが実現される場合もある。提供サービスの規模にもよるが、あるサービス（例えば証券の売買注文サービス等）を処理するためには、通常、ＢＬサーバ３００において、細分化された業務処理を提供する複数のアプリケーションやその上で動作する複数の業務モジュールを、順次もしくは並列的に呼び出して連携させて一連の処理を行う。これにより、規模の大きなサービスについての処理を実現している。

また、ユーザ属性に応じて提供可能なサービスが異なる場合がある。例えば、サービス利用状況（履歴等）に応じて、ユーザ属性が「一般」や「優良」等に分けられ、ユーザ属性が「一般」の場合と「優良」の場合とで異なるサービスを提供するシステムが可能である。

＜変形例＞
上記ＰＬサーバ１００と制限管理部５００とにおける、各処理部（機能）の配置や役割分担などの変形例について以下が挙げられる。

ログイン管理部１０の中での認証処理部１１やチャネル−サービス制御部１２などの各処理部による処理の順序は、前後させることも可能である。

本例では制限管理部５００でセッション集中管理する形態としたが、個別のＰＬサーバ主体でセッションを管理する形態としてもよい（セッション集中管理部５１やセッション管理ＤＢ４１が不要）。

また、制限判定部１４について、制限管理部５００主体に備える形態も考えられる。この場合、制限管理部５００から個別ＰＬサーバ１００へ制限実行指示を行い、それに従って個別ＰＬサーバ１００が制限実行する形となる。

また、ユーザからのアクセスに対して個別ＰＬサーバ１００でログイン処理及び制限判定等を行う際に、基本的には制限管理部５００（制限管理サーバ）へ情報（セッション管理情報３１、ログイン数Ｎなど）の授受のアクセスを行うことになるが、アクセス発生の都度、当該制限管理部５００へのアクセスを行うと、その処理負荷が大きくなり過ぎることが懸念される。そのため、その効率化のための処理例としては、当該ＰＬサーバ１００から制限管理部５００へのアクセスを適宜省略する形とする。即ち、制限管理部５００へは時間的に一定間隔以上でアクセスするようにし、当該アクセス単位でまとめて情報を授受、更新することで、当該処理負荷を減らすことができる。例えば、ＰＬサーバ１００は、自サーバ内に、制限管理部５００に前回アクセスして処理した時のログイン数Ｎや上限値Ｈなどの情報を保持しておく。新規のユーザアクセスに対する制限判定の際には、この保持しておいた直近の近似値を使用する。なお、この場合、リアルタイムでの正確な数値は把握できないが、近似的な数値は把握できるので、本制御のためには十分である。

＜処理（１）：ログイン処理＞
次に、図４は、本システムにおけるログイン処理の処理シーケンスを示している（Ｓは処理ステップ等を示す）。なお、認証処理やサービス−ＢＬ処理など、公知技術による処理については省略して説明する。

ユーザのクライアント端末は、ログイン画面（後述、図７）にアクセスする。ログイン画面から、所定のサービスの利用のために、ユーザは、必要なログイン情報を入力し、ログイン動作を実行する。これに対応して、クライアント端末は、所定のチャネル（ＵＲＬ）で、ログイン要求（セッション確立要求）の情報をＰＬサーバ１００へ向けて送信する（Ｓ４０１）。ログイン要求情報には、例えば、ＵＲＬ（またはチャネルＩＤ），ユーザＩＤ（またはクライアント端末ＩＤ），パスワード（ＰＷＤ）等の情報が含まれる。このログイン要求情報は、ＬＢ１（４０１）を介して、所定のチャネルに対応付けられたアドレスのＰＬサーバ１００へ送信される。

ログイン要求情報を受信したＰＬサーバ１００では、ログイン管理部１０により、認証、チャネル−サービス制御、及びログイン制限判定・実行等を含むログイン処理を行う。当該ログイン要求情報に対して、認証処理部１１により、デジタル証明書による認証などの所定の認証処理を行う。この認証処理を含むログイン処理では、ＰＬサーバ１００からＢＬサーバ２００へ要求情報（ユーザＩＤ等を含む）を送り、ＢＬサーバ２００を経由してＤＢサーバ３００（ＤＢ３１０）内のユーザ属性情報（Ｕ）なども参照して判断する（Ｓ４０２）。ＢＬサーバ２００では、例えば、要求情報のうちのユーザＩＤをキーとして、業務ＤＢ３１０から、パスワードやユーザ属性情報（Ｕ）などを取得する。ＢＬサーバ２００からＰＬサーバ１００への応答情報には、ＵＲＬ（チャネルＩＤ），ユーザＩＤ，ＰＷＤ，ユーザ属性情報（Ｕ）などが含まれる。ＰＬサーバ１００では、クライアント端末からの受信パスワードと、ＢＬサーバ２００からの取得パスワードとを照合することによって判定する。

また、上記認証処理に伴い、チャネル-サービス制御部１２及びユーザ属性制御部１７では、ＰＬサーバ１００のＷｅｂサーバ機能によってクライアント端末から受け付けたアクセス（要求情報）のチャネル（ＵＲＬ）を識別し、当該チャネル単位のＰＬサーバ１００における当該ユーザが利用可能なサービスの提供可否などを、チャネル−サービス管理情報３３及びユーザ属性情報（Ｕ）を参照して判断する（Ｓ４０３）。

上記認証を正常に通過した場合、ログイン処理部１３及び制限判定部１４等により、特徴的なログイン制限判定等を行う。制限判定部１４では、当該最新のログイン要求に係わりカウントした、当該ＰＬサーバ１００（グループ等）のチャネル単位における現在時（直近）のログイン数Ｎを、対応する種類の上限値Ｈと比較する（Ｓ４０４）。この際、制限管理情報３２または制限管理ＤＢ４２におけるログイン数Ｎや上限値Ｎ等の情報を参照する。そして、当該上限値Ｈ未満であれば、当該ログイン（即ちセッション確立）を許可し、当該上限値Ｈ以上であれば、当該ログインを拒否する。

当該ログインを許可した場合、ログイン管理部１３により、対応するセッション管理情報３１のレコードを作成または更新等する（Ｓ４０５）。このセッション管理情報３１には、セッションＩＤ、チャネルＩＤ（ＵＲＬ）、ユーザＩＤ、セッション属性等の情報を含む。セッションＩＤは、例えばチャネル−サービス制御部１２によって付与される。また、必要に応じて、そのセッション管理情報３１を、通信部１６を通じて、制限管理部５００のセッション集中管理部５１により、セッション管理ＤＢ４１に書き込む。一方、許可の結果に基づき、画面制御部２０により、所定の応答画面データを生成して、セッションＩＤ等の情報を加えて、要求元のクライアント端末へ送信する。

当該ログインを拒否した場合、制限実行部１５により、当該チャネルやユーザ属性に応じて適用する特定の種別の制限を実行する。画面制御部２０により、制限の種別に応じた所定の応答画面データを生成して、要求元のクライアント端末へ送信する（Ｓ４０６）。応答画面の例は後述する。

上記ログイン成功以降の当該ユーザのサービス利用については、当該ＰＬサーバ１００のログイン管理部１０（チャネル−サービス制御部１２など）によって、当該セッションＩＤを用いることで、当該ユーザのサービス利用のためのセッションを特定する。

＜処理（２）：サービス処理＞
図５を用いて、上記ログイン成功以後、当該セッション（セッションＩＤ）において、ユーザがクライアント端末から本サーバシステムにアクセスして所望のサービスを利用する際のサービス処理制御の例について説明する。クライアント端末のサービス画面（後述、図８）からユーザが所望のサービスのメニュー項目を選択して、サービス要求動作を実行する。これに対応して、クライアント端末から所定のチャネルで、サービス要求情報がＰＬサーバ２００へ向けて送信される（Ｓ５０１）。

ＰＬサーバ１００は、クライアント端末からのサービス要求をＬＢ１（４０１）を介して受信する。このサービス要求には、ＵＲＬ（チャネルＩＤ）、サービス情報（サービス名またはサービスＩＤなど）、セッションＩＤなどの情報が含まれている。

サービス要求を受信したＰＬサーバ１００では、ログイン管理部１０において、チャネル−サービス制御部１２及びユーザ属性制御部１７などにより、チャネル−サービス管理情報３３、ユーザ属性情報（Ｕ）、セッション管理情報３１などの内容に従って、当該チャネルで当該ユーザが利用対象とするサービスの提供可否を判断する。例えば、チャネル−サービス制御部１２は、チャネル−サービス管理情報３３を参照して、サービス要求における当該ＵＲＬからチャネル（チャネルＩＤ）を識別し、当該ＵＲＬ（チャネルＩＤ）をキーとして、当該チャネルの利用可否を判断する。また、当該チャネルが利用可能な場合、チャネル−サービス制御部１２は、当該チャネルに関する当該ユーザが利用対象とするサービスを識別する（Ｓ５０２）。そして、セッション管理情報３１に基づき、当該セッションＩＤをキーとして、セッション属性などの情報を取得する（Ｓ５０３）。そして、当該セッション属性などの情報を用いて、当該サービスの提供可否を判断する。

当該チャネルでの当該ユーザの当該利用対象サービスの提供が可能である場合、チャネル−サービス制御部１２は、当該サービスに対応付けられる業務処理を行うＢＬサーバ２００を呼び出して当該業務処理を依頼する。また、当該利用対象サービスが外部システムによって提供される外部サービス（例えば金融サービス会社によって提供される株価情報サービス）である場合には、外部連動機能により、当該外部サービスに対して処理を依頼して連携することによって、同様にサービスを実現する。

ＰＬサーバ１００からのサービス要求が、当該サービス（業務処理）を処理するＢＬサーバ２００に送信される。サービス−ＢＬ制御部２１０では、要求されたサービス（業務処理）が実行可能な場合には、必要となる業務モジュール２２０を処理シーケンスに従って呼び出して実行する。その各業務モジュール２２０では、必要に応じてＤＢサーバ３００の業務ＤＢ３１０にアクセスしてデータを読み書きすることで、当該業務処理を実行する（Ｓ５０４）。その際、業務ＤＢ３１０内のユーザ属性情報（Ｕ）も必要に応じて参照、更新される。そして、当該セッションにおいて、当該サービス（業務処理）の処理結果を含む応答（サービス処理結果応答）を、ＢＬサーバ２００からＰＬサーバ１００に送信する（Ｓ５０５）。この応答の際には、業務ＤＢ３１０内のユーザ属性情報（Ｕ）またはそれをもとに作成した情報などを含めて送信してもよい。

ＰＬサーバ１００は、ＢＬサーバ２００からの応答情報に基づき、チャネル−サービス制御部１２により、セッション管理情報３１の該当レコードを更新する（Ｓ５０６）。該当レコードの更新日時のタイムスタンプを現在時刻で更新する。そして、画面制御部２０により、サービス処理結果などの情報を含む応答画面データを生成して、クライアント端末へ送信する（Ｓ５０７）。

上記処理中、該当チャネルが利用不可であると判定された場合や、該当サービスが提供不可であると判定された場合は、それ以降の後段のサーバ等へのアクセスは行わずに、例えば、画面制御部２０により、チャネル利用不可の旨の情報あるいはサービス提供不可の旨の情報を含む応答画面データを生成し、クライアント端末に送信する。

また例えば、サーバの不定期のメンテナンス等や、障害の時など、一時的に該当サーバでのサービスを提供不可にするような場合は、チャネル−サービス管理情報３３の該当サーバのサービスのエントリの情報を管理者やコンピュータ処理等によって変更することで対処できる。

また例えば、障害等を契機として、特定のチャネルのサービスをチャネル単位で一時的に利用不可とするような場合、チャネル−サービス管理情報３３の該当チャネルのエントリの利用可否の項目の値を「否」に変更することで対処できる。

＜応答画面＞
次に、図６は、クライアント端末に対する応答画面の表示の遷移例を示している。図７〜図９は対応する各画面の表示例を概略的に示している。クライアント端末（Ｗｅｂブラウザ等）から本サーバシステムの提供するＷｅｂサイト等へアクセスする。通常時、クライアント端末からのアクセスに対し、（Ａ）のような、標準のメイン画面またはログイン画面を表示させる。（Ａ）の画面から、ユーザによるログイン情報（ユーザＩＤ，パスワード等）の入力により、ログイン要求を受け付ける。ログイン要求に対し、ＰＬサーバ１００では、前記ログイン処理（図４）を行う。それにより、ログイン許可（成功）された後、クライアント端末に、（Ｂ）のような、標準のサービス画面（メニュー画面）を表示させる。（Ｂ）の画面から、ユーザがサービス（対応メニュー項目）を選択実行することにより、サービスを提供する。ＰＬサーバ１００及びＢＬサーバ２００を通じて前記サービス処理（図５）を行い、（Ｃ）のような、サービス応答画面をクライアント端末に表示させる。

図７に示す（Ａ）は、Ｗｅｂサイト等のメイン画面、またはログイン画面、またはメイン画面の中に含まれるログイン画面などである。

図８に示す（Ｂ）のメニュー画面１（サービス画面）は、当該チャネルで利用可能なサービスのメニュー項目が表示される。（Ｂ）のメニュー画面１の中から、ユーザが所望のサービス項目を選択して、サービス要求を実行する。サーバシステム側で判定やサービス処理が行われ、応答画面データが返されることにより、（Ｃ）のサービス応答画面へ移る。（Ｃ）のサービス応答画面では、サービス選択結果あるいはサービス処理結果などの情報が表示される。

ＰＬサーバ１００でログイン拒否した場合、ログイン制限の適用の種別に対応した所定の応答画面データを生成して、ユーザのクライアント端末へ送信する。以下の例がある。クライアント端末（Ｗｅｂブラウザ等）から、（Ａ）の画面にアクセスしようとした際、特定の種類の制限の実行（ａ：ログイン画面非表示）により、（Ｄ）のメッセージ画面に移る。

図９に示す（Ｄ）のメッセージ画面では、例えば現在混雑中のため本システムのサービスが利用できない旨のメッセージが表示され、（Ａ）のログイン画面は表示されない。よって、ユーザによるログイン情報入力操作自体が不可能である。（Ｄ）の画面は、標準的な（Ａ）の画面との差し替えである。ユーザにログイン情報入力の手間をかけさせず、ログイン要求による負荷を減らす効果がある。

また、（Ａ）のログイン画面から、ログイン情報入力によるログイン要求により、サーバシステム側のログイン処理を経て、ログイン拒否（失敗）された場合（ｂ：ログイン拒否）、（Ｅ）のログイン失敗（拒否）画面へ移る。（Ｅ）の画面では、例えば現在混雑中のためログインができなかった旨（あるいはログイン不可能である旨）のメッセージが表示される。この場合、例えば「戻る」ボタンの操作により、（Ａ）のログイン画面に戻ることができ、ユーザは再度のログイン情報入力によりログイン要求を試行することができる。しかしながら、状況に応じて同様の制限が実行された場合は再度ログイン拒否されることになる。

また、（Ａ）のログイン画面から、ログイン情報入力によるログイン要求により、サーバシステム側のログイン処理を経て、所定の制限付きでログインが許可（成功）された場合（ｃ：ログイン許可（制限付き））、（Ｆ）のメニュー画面２（サービス画面）に移る。（Ｆ）の画面では、基本的には（Ｂ）の画面と同様の表示内容になるが、（Ｂ）の画面と比べて、当該ユーザが利用可能なサービスのメニュー項目が、状況に応じた特定の項目に限定、減少される。ユーザは、（Ｆ）の画面で表示されているメニュー項目のみ選択して実行することができる。

この場合、ログイン要求に対し、ＰＬサーバ１００では、その時点で当該ユーザのユーザ属性が利用可能なサービスを判断する処理を行い、当該利用可能なサービスのメニュー項目のみを含んだ（Ｆ）の画面を表示させるように、画面制御部２０等により処理する。また例えば、（Ｆ）の画面では、サービス時間情報に基づいて、当該サービスの提供可能な時間帯毎に区分けされた形でサービス名やサービス提供時間の一覧が表示されるようにしてもよい。

この処理例としては、前記ログイン処理（図４）またはサービス処理（図５）の際などに、チャネル−サービス制御部１２などにより、チャネル−サービス管理情報３３や現在時刻などに基づいて、当該ユーザ属性に対して現時点で提供可能なサービスの一覧の情報（サービス名、サービス時間帯など）を取得する。そして、この情報に基づいて、ログインしたユーザが現在利用可能なサービス、及びその利用可能時間帯などの情報を、ログイン成功後のサービス画面に表示させるように制御する。

この場合、ユーザは、あるサービスに関して実際にサービス利用要求を実行せずとも、（Ｆ）の画面を見ることで、当該サービスが利用可能か否か等を知ることができる。

＜データ＞
以下、本サーバシステムにおいて使用、管理する各種のデータ・情報の構成例（テーブル）について説明する。なお、これらのデータ・情報の実装方法としては、データベースやファイル、メモリテーブルなど種々のものが可能である。各テーブルのデータ項目は一例であり、他のデータ項目を有してもよい。各テーブルは分割したり１つにまとめることも可能である。

＜データ：チャネル−サービス管理情報＞
図１０は、チャネル−サービス管理情報３３の構成例を示している。チャネル−サービス管理情報３３において、チャネル（ＵＲＬ）、サービス、ＰＬサーバ１００等の要素の対応付けが定義されている。チャネル−サービス管理情報３３は、チャネルＩＤ、ＵＲＬ、提供サービス情報、ＰＬサーバ情報、ＢＬ情報、チャネル属性（利用可否）、サービス属性（提供可否）、サービス時間帯などの項目を有する。

チャネルＩＤやＵＲＬは、ユーザがクライアント端末から本サーバシステムにアクセスする際に使用するチャネルやＵＲＬを示す。チャネルＩＤ及びＵＲＬは、チャネル毎に異なる値が設定される。提供サービス情報は、当該チャネルに対応付けられるサービスに関する、サービスＩＤまたはサービス名などの情報である。１つのチャネルに対して複数のサービスが対応付けられる場合は、複数のレコードが設定される。

ＰＬサーバ情報は、当該サービスを受け付けるＰＬサーバの情報であり、例えばグループの種別（グループＩＤ）や、個別ＰＬサーバＩＤなどである。ＢＬ情報は、当該サービスを構成する１つ以上の業務（ＢＬ）処理の情報（ＢＬ−ＩＤ等）や、その処理シーケンスの情報である。

チャネル属性（利用可否）の情報は、対応するチャネル（ＵＲＬ）が現在利用可能か否かの状態などを表す。例えば、障害等により、優先度の低い特定のチャネルをチャネル単位で利用不可とするような場合には、当該利用可否の値を「否」に設定する。

サービス属性（提供可否）の情報は、対応するサービスが提供可能か否かの状態などを表す。

サービス時間帯の情報は、当該サービスを提供可能とする時間帯を示す。例えば２４時間や、特定時間、一定期間の日時などである。また例えばサーバの不定期のメンテナンス等や障害等により、当該サービスの提供時間を一時的に変更、制限する場合などに、この項目の値を変更して対処できる。なお、ログイン制限を発生させる場合は、本来サービス時間帯であってもサービス提供が一時停止されることになる。

＜データ：セッション管理情報＞
図１１は、セッション管理情報３１（またはセッション管理ＤＢ４１）の構成例を示している。セッション管理情報３１は、セッションＩＤ、セッション属性、ユーザＩＤまたはクライアント端末ＩＤ、ユーザ属性、チャネルＩＤまたはＵＲＬ、及び更新日時（ログイン日時）などの項目を有する。

セッションＩＤは、セッションを識別するＩＤであり、ユーザのクライアント端末から本サーバシステムへのログインの成功により確立されたセッションを特定するために割り振られる。セッション属性は、当該セッションのユーザのユーザ属性やチャネルなどに応じて決定される、セッションの属性を表す。例えば適用される制限の種別や状態などに対応した値が設定される。

ユーザＩＤは、本サーバシステムにログインして当該セッションを確立したユーザを識別するＩＤである。クライアント端末ＩＤは、当該ユーザのクライアント端末を識別するＩＤである。ユーザ属性は、ユーザの属性を表す情報であり、例えば、サービス利用状況（履歴）などに応じて、「優良」、「一般」などの値が設定される。

チャネルＩＤ及びＵＲＬは、当該セッションが確立された際に経由してきたチャネルやＵＲＬを表す。更新日時は、本セッション管理情報３１における当該セッションのエントリ（レコード）が更新（新規作成を含む）された日時（タイムスタンプ）である。最初のログイン時にセッションのエントリが新規作成され、二度目以降のログイン時には当該セッションのエントリの内容が更新される。更新日時の情報は、セッションの活性状態（ログイン数Ｎ）を把握するために使用される。セッション管理情報の定期チェック・定期削除処理により、当該更新日時の情報が参照され、一定の経過時間などの単位で削除される。

＜データ：制限管理情報＞
制限管理情報３２（制限管理ＤＢ４２）の構成例は以下である。

図１２は、制限管理部５００の制限管理ＤＢ４２における、ＰＬサーバ（群）１００のログイン数Ｎや上限値Ｈに関する管理情報の例を示す。本テーブルにおいて、ＰＬサーバ情報、ＵＲＬ（アドレス）、提供サービス、ログイン数Ｎ、上限値Ｈなどの項目を有する。

ＰＬサーバ情報は、ＰＬサーバグループ種別や、その個別ＰＬサーバＩＤ等である。例えば、ＰＬ０１−０１は、第１グループのうちの第１ＰＬサーバである。ＵＲＬ（アドレス）は、当該ＰＬサーバ（グループ）のＵＲＬ（アドレス）である。提供サービスは、当該ＰＬサーバ（グループ）で提供するサービスのサービスＩＤ等である。ログイン数Ｎは、当該ＰＬサーバ（グループ）の単位における現在時のＮのカウント値である。上限値Ｈは、当該ログイン数Ｎに対応付けられる種類（同単位）のしきい値である。

個別ＰＬサーバ１００が保持するＮ，Ｈに関する制限管理情報３２は、上記制限管理ＤＢ４２の一部と同様の情報である。

図１３（ａ）は、図１２のＤＢ（４２）と関連付けられる、チャネル単位の制限管理情報３２の例を示す。チャネル単位の制限管理情報３２において、チャネル（チャネルＩＤ）毎に、ＰＬサーバ情報（グループ種別等）、提供サービス情報、制限属性、上限値Ｈ、等の項目を有し、所定の設定値が割り当てられる。

制限属性は、当該チャネルに対して適用される制限の種別あるいは制御方法の種別や、その時点で適用されている制限の状態などの情報が設定される。例えば、０は非適用（通常）、１（Ｘ）は、最優先である（例えば固定優先的に許可されるチャネルやユーザ属性に対応）。２（Ｙ）は、２番目に優先である（例えば「優良」ユーザ属性に対応し、２番目に制限される）。３（Ｚ）は、３番目に優先である（例えば「一般」ユーザ属性に対応し、最初に制限される）である。

上限値Ｈは、当該チャネル単位に対応付けられるＰＬサーバグループ等の単位で換算された上限値Ｈの設定値である。

図１３（ｂ）は、図１２のＤＢ（４２）と関連付けられる、ユーザ属性単位の制限管理情報３２の例を示す。図１３（ａ）のチャネル単位の制限管理情報３２と同様に、ユーザ属性毎に、制限属性、上限値Ｈ等の項目を有し、所定の設定値が割り当てられる。

上限値Ｈは、当該ユーザ属性に対応付けられるＰＬサーバグループ等の単位で換算された上限値Ｈの設定値である。

なお、本例では、ユーザ属性について、簡単に「優良」と「一般」等に分けているが、より細かく多段階に分けて制御しても構わない。

チャネルやユーザ属性等の単位で多段階的に制限制御する場合、上記上限値Ｈの項目については制御段階に応じた複数の上限値Ｈの項目を管理してもよい（例えば後述のＨ１，Ｈ２）。

なお、第３の制御方法の場合、図１３（ａ）のチャネル単位の制限管理情報３２と、図１３（ｂ）のユーザ属性単位の制限管理情報３２との両方を１つにまとめて、チャネルＩＤとユーザ属性が対応付けられた形の管理情報を用いる。

＜制御例（１）＞
本システムの基本的な制御例は以下である。状況に応じて柔軟に上限値Ｈの設定を変化させることにより、例えば突発的なアクセス数の急増などの事態に対しても対処する。上限値Ｈの設定では、例えばシステム管理者等により設定部７００を用いて手動で情報入力・設定することにより変化させる。あるいは、所定の予測プログラム等を用いたコンピュータ処理（システム監視部５００）により、自動的に上限値Ｈの設定を変化させる。

状況の例として、ある日時に、株価の変動などを起因として、あるチャネルでの情報閲覧サービス等へのアクセス数やログイン数が急増傾向にあることを、管理者（あるいは予測プログラム等）により認識、検出する。そして、管理者（あるいは予測プログラム等）は、それ以後の時間における同チャネルでのアクセス数やログイン数の更なる増大を予測する。これにより、管理者（あるいは予測プログラム等）は、例えば、当該チャネルの上限値Ｈの設定値を適切に設定または更新する。過去の経験などに基づいて、予め当該上限値Ｈを設定しておいてもよい。

例えば図１の例のように、ＰＣ利用の「一般」属性ユーザｄのログイン数Ｎを、対応上限値Ｈを小さく設定しておくことで大きく制限し、一方、「優良」属性ユーザａ，ｂのログイン数Ｎについては制限しないように制御する。

また例えば、各上限値Ｈを通常時よりも上げたり、下げたりして調整してもよい。例えば、上限値Ｈを上げた場合、その分システムの性能やリソースが必要になるので、他のチャネルのＰＬサーバ１００や、予備のＰＬサーバ等を有効状態にしたり、他のチャネルのＰＬサーバ１００の上限値Ｈを下げること等によって、性能やリソースを調整する。

＜制御例（２）＞
図１４は、単純にチャネル単位で判定する第１の制御方法の場合のログイン数Ｎの推移例である。横軸は時間、縦軸はあるチャネルＸでの所定のサービス（例えば情報閲覧サービス）の提供におけるログイン数Ｎの推移である。当該チャネルＸのユーザの中には、ユーザ属性が「優良」のユーザ２、及び「一般」のユーザ３を含むとする。第１の時間帯Ｔ１に、アクセスの急増、即ちログイン数Ｎの急増となっている。第１の時間帯Ｔ１では、制限状態としては、何ら制限無し（制限０）であり、全ユーザがログイン許可される。時刻ｔ１で、ログイン数Ｎが、上限値ＨＸ（ＨＸ＜Ｈ０）に達したとする。これにより、第２の時間帯Ｔ２では、制限状態としては、所定の制限（制限１）が実行され、ユーザのうち「優良」ユーザ２及び「一般」ユーザ３がログイン拒否され、当該チャネルＸのログイン数Ｎは、上限値ＨＸ未満に抑制される。よって、全体の複数のチャネルのうち当該チャネルＸ以外のチャネルではログイン数に余裕がある。

この制御例では、ユーザ属性単位では制限していない。当該チャネルＸのログイン数Ｎのうち、例えば「優良」ユーザ２と「一般」ユーザ３の割合の実態は様々なケースが考えられる。例えば最初は実際の割合がユーザ２−ユーザ３で５０％−５０％程度であったが、「一般」ユーザ３のアクセスの急増により、上限値ＨＸに達した時点ｔ１では、割合が例えば１０％−９０％程度に変化していたとする。この場合、「優良」ユーザ２へのサービスが圧迫されている。よって、本システムでは、例えば「優良」ユーザ２へのサービスを確保または向上したい場合は、後述のユーザ属性単位の制御を用いて、「優良」ユーザ２よりも「一般」ユーザ３への制限を強くする。

＜制御例（３）＞
また上記に追加する制御例として、以下の制限解除機能がある。これは、所定のしきい値（下限値Ｌ）を用いて、制限の解除に関する判定、及び当該解除の実行を制御するものである。上記制御例で、時刻ｔ１で上限値ＨＸに達することで当該チャネルＸのログイン制限が開始され、ログイン数Ｎが横這いまたは減少傾向となるが、例えば、Ｎの減少により、上限値ＨＸよりも小さい所定の下限値ＬＸ（ＨＸ＞ＬＸ）を下回ったとする。この時、ＰＬサーバ１００では、当該チャネルＸのログイン制限を解除、即ちログインを許可し始める。これにより、それ以降、Ｎが横這いまたは増加傾向となる。その後は同様に、上限値ＨＸ及び下限値ＬＸを用いて制限の実行を制御する。この機能を用いることで、例えば、上限値Ｈにより制限（例えば前記（Ｄ）の画面への差し替え）を開始した後、ログイン数Ｎをある程度下げてシステムの負荷を十分に下げた状態になってから、下限値Ｌにより再度サービスを提供し始めるといった制御が可能となる。

＜制御例（４）＞
本システムにおけるログイン制限の制御例（ユーザ属性単位を考慮する場合）は以下である。本制御例は、ログイン数Ｎによる制限効果の大小と、ユーザ属性の優先度の違いとを考慮する場合である。ログイン数Ｎが多いユーザほど制限した場合の効果が高いので、先に制限（強く制限）するようにする。またユーザ属性が「優良」のユーザの方を優先度を高く（即ち制限を弱く）、ユーザ属性が「一般」のユーザの方を優先度を低く（即ち制限を強く）する。

上記考え方に対応した、２段階のログイン制限の制御方法を以下に示す。これは、チャネル単位及びユーザ属性単位で判定する制御方法であり、２つのしきい値（第１上限値Ｈ１，第２上限値Ｈ２，Ｈ１＜Ｈ２）を用いて、時間軸上で異なる種類の制限を順に適用するものである。本制御例では、ユーザ属性、チャネル、ＰＬサーバグループ、サービスを所定に対応付け、例えば、ユーザ属性２（優良），３（一般）毎に別の系列でサービスを提供するものとする。相対的に、ユーザ属性２（優良）の優先度を高く、ユーザ属性３（一般）の優先度を低く扱う。

図１５は、本制御例におけるログイン数Ｎの推移例である。縦軸は、ユーザ属性２（優良）とユーザ属性３（一般）とを合わせたユーザに関する所定のチャネルでの所定のサービス（例えば情報閲覧サービス）の提供におけるログイン数Ｎである。実線の曲線におけるログイン数Ｎは、各ユーザ属性２，３毎のログイン数Ｎ２，Ｎ３を合わせたものである。破線の曲線におけるログイン数Ｎは、ユーザ属性３のログイン数Ｎ３を示す。

最初、第１の時間帯Ｔ１では、制限状態としては、何ら制限無し（制限０）であり、全ユーザがログイン許可される。そして、Ｔ１では、何らかの理由で、ＰＬサーバ１００へのアクセス、即ちログイン数Ｎが増加している状況である。例えば株価の変動により情報閲覧サービスへのアクセスが急増する場合などが考えられる。実態としては、例えば、ユーザ属性２，３ともにアクセス増加傾向であるが、特に不特定多数のユーザ属性３（一般）のアクセスが急増しているとする。

時刻ｔ１で、ログイン数Ｎ（Ｎ２＋Ｎ３）が、まず第１上限値Ｈ１に達したとする。Ｈ１は、Ｎ（Ｎ２＋Ｎ３）に対応したチャネル単位のしきい値である。これにより、第２の時間帯Ｔ２では、制限状態としては、所定の制限（制限１）が実行され、ユーザのうち、まず優先度が低く数の多いユーザ属性３（一般）から先に制限開始（ログイン拒否）される。一方、ユーザ属性２（優良）はログイン許可されるままである。

ｔ１以降の第２の時間帯Ｔ２において、制限１の状態により、例えば、ユーザ属性３（一般）のログイン数Ｎ３はＨ１未満となる。ユーザ属性３（一般）の新規のログインを拒否し続ければ、ログイン数Ｎ３は下降傾向となる。一方、ユーザ属性２（優良）は許可されているので引き続きログイン数Ｎ２が増加しているとする。

時刻ｔ２で、ログイン数Ｎ（Ｎ２＋Ｎ３）が、第２上限値Ｈ２に達したとする。Ｈ２は、Ｎ（Ｎ２＋Ｎ３）に対応したチャネル単位のしきい値である。これにより、第３の時間帯Ｔ３では、制限状態としては、所定の制限（制限２）が実行され、ユーザのうち、ユーザ属性３（一般）に加えて、優先度が高く数の少ないユーザ属性２（優良）についても制限開始（ログイン拒否）される。当該チャネルのログイン数Ｎ（Ｎ２＋Ｎ３）は、上限値Ｈ２未満に抑制される。

よって、全体のチャネルのうち当該チャネル以外のチャネルではログイン数に余裕があり、かつ、多数の「一般」ユーザのアクセスにより「優良」ユーザへのサービスが圧迫されることなくサービスの品質が確保されている。

上記しきい値（Ｈ１，Ｈ２）の大きさは、各ユーザ属性のアクセス数の予測や経験などに基づき適宜設定される。例えば、上記Ｎ（Ｎ２＋Ｎ３）に関するＨ１が４０００、Ｈ２が５０００といった具合である。

なお上記例のｔ１以降のＴ２で、ユーザ属性２（優良）のアクセスによるログイン数Ｎ２が増加しなかった場合は、Ｎ（Ｎ１＋Ｎ２）は下降するので、この場合、再度ユーザ属性３（一般）のログインを受け入れることもできる。この場合、随時、Ｈ１を用いて同様に判定及び制限が行われる。

また上記で前述の制限解除機能を用いることができる。Ｈ１，Ｈ２に対応した各下限値Ｌ１，Ｌ２を用いる。例えば、上記ｔ１でＨ１に達して制限開始された後、Ｎ（Ｎ１＋Ｎ２）が下降した場合、Ｎが下限値Ｌ１を下回った場合に制限解除され、再び、Ｎ（Ｎ１＋Ｎ２）が増加可能となる。即ち、ユーザ属性３（一般）のユーザもログイン可能になる。Ｈ２，Ｌ２でも同様である。

上記制御例については、他にも例えば、第１段階では第１チャネル（第１サービス）のログイン数Ｎを制限開始し、第２段階では加えて第２チャネル（第２サービス）のログイン数Ｎを制限開始する、といったことも同様に可能である。

上記制御例についての管理情報は、例えば制限管理ＤＢ４２で管理され、そのテーブルにおいて、各チャネル（ＰＬサーバグループ、図２）のサービスにおけるログイン数Ｎ（上限値Ｈ）の割合（数）の情報や、制限属性（ユーザ属性）、第１上限値Ｈ１、第２上限値Ｈ２などの項目を有するものとなる。例えば、Ｎ（Ｈ）の割合（数）の情報は、ＰＬサーバ１００全体が１００％（１万）、第１ＰＬサーバグループに対して２０％（２千）、等である。即ち、第１ＰＬサーバグループ対応のチャネル及びサービスに対しては、全体（最大リソース）のうち２０％（２千）までのログイン数Ｎを許容するようにリソースが確保される。

＜システム監視部、上限値Ｈ更新機能＞
次に、システム監視部６００等を用いて上限値Ｈを更新する機能について説明する。システム監視部６００を用いて、システムの状況（性能や負荷など）を監視、検知し、その結果に応じて、ログイン制限制御のしきい値である上限値Ｈの設定値を随時更新（調製）して制御するものである。

システム監視部６００は、本サーバシステムを監視し、性能や負荷などを把握する。システム監視部６００は、ＰＬサーバ（群）１００やＢＬサーバ（群）２００を監視し、例えば、ＣＰＵ利用率、ターンアラウンドタイム、重要なトランザクション（例えば株式の売買注文、約定（売買取引成立））の件数などの情報（性能や負荷を示す情報）を計算、取得等する。例えば所定のトランザクションの件数が多い場合とは、特定のチャネルのサービスの負荷が高いことと対応している。

これらの監視結果（性能や負荷の状態）を、前述したログイン制限制御の内容に反映する。システム監視部６００は、監視結果情報に基づき、制限管理部５００（上限値Ｈ設定部５３）にアクセスして、上限値Ｈの設定値を更新する。あるいは、上限値Ｈ設定部５３がシステム監視部６００にアクセスして監視結果情報を取得して上限値Ｈを更新してもよい。

システム監視部６００による自動的なしきい値の更新の制御例として以下である。例えばある時点でのシステムの性能や負荷の状態として、ある第１のチャネルのサービスでは負荷が高く性能が低下した状態であり、相対的に、ある第２のチャネルのサービスでは負荷が低く性能が上昇した状態であるとする。この場合、第１のチャネルのサービスに対するログイン数Ｎの上限値Ｈを少し下げると共に、第２のチャネルのサービスに対するログイン数Ｎの上限値Ｈを少し上げるように調整する。全体の上限値Ｈ０は同じに維持し、個別の上限値Ｈの割合を変化させる。

また他の制御例として、時間軸上で未来の時点のログイン数Ｎを予測することにより、上限値Ｈを決めて更新してもよい。例えば、実測値として、あるチャネルやユーザ属性のサービスにおけるログイン数Ｎが時間的に急増するような所定の形の曲線であった場合、他のチャネルやユーザ属性、他の時間帯などについても、類似の形の曲線で急増することが予測できる。この予測に従って、上限値Ｈを決めて更新する。

以上説明したように、本実施の形態のサーバシステムでは、特徴的な構成として、主にＰＬサーバ１００のログイン管理部１０と、制限管理部５００とによって、チャネル単位及びユーザ属性単位でのサービス制御に伴うログイン制限を制御している。これにより、システムの性能や負荷を調整し、応答画面によってユーザに対して適切な応答を行って対処することができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、Ｗｅｂによってサービスを提供するサーバシステムなどに利用可能である。

本発明の一実施の形態であるサーバシステムの構成概要を示した図である。 本実施の形態におけるチャネルやサーバの対応付けの構成例を示した図である。 本実施の形態における各サーバの内部詳細構成例を示した図である。 本実施の形態におけるログイン処理の処理シーケンスを示した図である。 本実施の形態におけるサービス処理の処理シーケンスを示した図である。 本実施の形態におけるクライアント端末への応答画面の遷移の例を示した図である。 本実施の形態における応答画面の例（Ａ）（ログイン画面）を示した図である。 本実施の形態における応答画面の例（Ｂ）（サービス画面）を示した図である。 本実施の形態における応答画面の例（Ｄ）（メッセージ画面）を示した図である。 本実施の形態におけるチャネル−サービス管理情報の構成例を示した図である。 本実施の形態におけるセッション管理情報の構成例を示した図である。 本実施の形態における制限管理ＤＢの構成例を示した図である。 本実施の形態における制限管理情報の構成例を示した図でり、（ａ）はチャネル単位の制限管理情報、（ｂ）はユーザ属性単位の制限管理情報である。 本実施の形態における制御例（その１）におけるログイン数Ｎの時間的な推移の例を示した図である。 本実施の形態における制御例（その２）におけるログイン数Ｎの時間的な推移の例を示した図である。

符号の説明

１０…ログイン管理部（セッション管理部）、１１…認証処理部、１２…チャネル−サービス制御部、１３…ログイン処理部（セッション処理部）、１４…制限判定部、１５…制限実行部、１６…通信部、１７…ユーザ属性制御部、２０…画面制御部（応答制御部）、３１…セッション管理情報、３２…制限管理情報、３３…チャネル−サービス管理情報、４１…セッション管理ＤＢ、４２…制限管理ＤＢ、５１…セッション集中管理部、５２…ログイン数Ｎ更新部、５３…上限値Ｈ設定部、９０…通信ネットワーク、１００…ＰＬサーバ、２００…ＢＬサーバ、２１０…サービス−ＢＬ制御部、３００…ＤＢサーバ、３１０…ＤＢ（業務ＤＢ）、４０１…第１の負荷分散装置（ＬＢ１）、４０２…第２の負荷分散装置（ＬＢ２）、５００…制限管理部（制限管理サーバ）、６００…システム監視部、７００…設定部、Ｎ…ログイン数、Ｈ…上限値、Ｕ…ユーザ属性情報。

Claims (9)

1. プレゼンテーションロジック層の複数の第１のサーバ、ビジネスロジック層の複数の第２のサーバ、及びデータベース層の第３のサーバを有し、複数のユーザのクライアント端末からの通信ネットワークを介したアクセスに対し、前記第１のサーバを介して、前記第２及び第３のサーバによって処理されるサービスを前記クライアント端末に提供するサーバシステムであって、
   前記第１のサーバは、前記ユーザのクライアント端末からの所定のチャネルでのアクセスに対して、認証処理を含む、当該クライアント端末との間のセッションの確立に係わるログイン処理を行い、確立されたセッションで、当該クライアント端末からの要求に応じて、当該チャネルに応じた所定のサービスの処理を前記第２のサーバに要求して、前記第２のサーバにより前記第３のサーバのデータベースを読み書きして当該サービスを構成する業務処理を行わせ、その結果に基づき、応答画面データを生成して前記クライアント端末に送信して表示させる処理を行い、
   前記ユーザのクライアント端末からの所定のチャネルでのアクセスは、Ｗｅｂ、コールセンタ、及び営業店を含む複数の種類を有し、
   前記第１のサーバは、
   前記チャネルとサービスと業務処理との対応付けの情報と、
   前記セッションに関するセッション管理情報と、
   前記複数の第１のサーバと複数のユーザのクライアント端末との間の複数のチャネルでの複数のセッションに関する現在または直近のログイン数の情報と、
   前記ログイン数に関する判定用のしきい値である、前記チャネル単位での前記ログイン数の上限値の情報と、を保持し、
   前記第１のサーバは、
   前記クライアント端末からのアクセスに対する前記ログイン処理の際に、前記チャネル単位でのログイン数と前記しきい値である当該チャネル単位でのログイン数の上限値とを比較し、当該ログインを制限するかの判定を行う第１の処理と、
   前記判定に従い、前記ログインの制限を実行し、当該制限に対応する前記応答画面データを生成して前記クライアント端末へ送信して表示させる第２の処理と、を行い、
   前記第１のサーバは、前記クライアント端末からのアクセスに対する前記ログイン処理の際に、前記第１の処理で当該チャネル単位でのログイン数が当該上限値以上の場合は、前記第２の処理で当該ログインを拒否するように制限し、
   前記第２のサーバは、前記サービスを構成する業務処理の際に前記第３のサーバのデータベースに対して当該ユーザの属性の情報を読み書きし、
   前記ユーザの属性として、優良と一般との少なくとも２種類を有し、
   前記第１のサーバは、前記チャネルと属性との対応付けの情報を保持し、
   前記第１のサーバは、前記ユーザのクライアント端末からのアクセスに対し、当該ユーザのチャネルに対応付けられる属性に応じた所定のサービスを提供し、
   前記しきい値として、前記ユーザのチャネルに対応付けられる属性の単位での前記ログイン数の上限値の情報を有し、
   前記第１のサーバは、前記クライアント端末からのアクセスに対する前記ログイン処理の際に、当該ユーザのチャネルに対応付けられる属性の単位でのログイン数が当該上限値以上の場合は、当該ログインを拒否するように制限し、
   前記第１のサーバは、前記優良のユーザに対する前記制限を弱く、前記一般のユーザに対する前記制限を強くするように制御すること、を特徴とするサーバシステム。
2. 請求項１記載のサーバシステムにおいて、
   前記複数の第１のサーバに接続される制限管理部を有し、
   前記制限管理部は、
   前記複数の第１のサーバと通信して情報を授受することにより、
   前記複数の第１のサーバと複数のユーザのクライアント端末との間の複数のチャネルでの複数のセッションに関する現在または直近のログイン数の情報と、
   前記ログイン数に関する判定用のしきい値である、前記チャネル単位での前記ログイン数の上限値の情報と、前記複数のチャネルを含む全体の単位での前記ログイン数の上限値の情報と、を管理する処理を行うこと、を特徴とするサーバシステム。
3. 請求項１記載のサーバシステムにおいて、
   前記第１のサーバは、前記クライアント端末からのアクセスに対する前記ログイン処理の際に、当該ログインを拒否するように制限する場合、前記クライアント端末への応答画面データとして、ログイン情報を入力可能なログイン画面を表示させないように制御すること、を特徴とするサーバシステム。
4. 請求項１記載のサーバシステムにおいて、
   前記第１のサーバは、前記クライアント端末からのアクセスに対する前記ログイン処理の際に、その時点で当該チャネルで当該ユーザが利用可能なサービスを判断し、前記クライアント端末への応答画面データとして、当該利用可能なサービスの一覧を含む画面を送信して表示させること、を特徴とするサーバシステム。
5. 請求項１記載のサーバシステムにおいて、
   前記しきい値として、前記ログイン数の第１の上限値と、それよりも大きい第２の上限値とが設定され、
   前記第１のサーバは、前記クライアント端末からのアクセスに対する前記ログイン処理の際に、当該チャネル単位でのログイン数が当該第１の上限値以上の場合は、第１の属性のユーザについて当該ログインを拒否するように制限を開始し、更に、当該チャネル単位でのログイン数が当該第２の上限値以上の場合は、前記第１の属性のユーザに加えて第２の属性のユーザについて当該ログインを拒否するように制限を開始すること、を特徴とするサーバシステム。
6. 請求項２記載のサーバシステムにおいて、
   前記複数の第１のサーバを含む本システムの性能または負荷を監視する処理を行うシステム監視部を有し、
   前記第１のサーバまたは前記制限管理部は、前記監視の結果情報として、本システムの負荷が高く性能が低下した状態を示す時、前記しきい値を更新する処理として、第１のチャネルのログイン数の上限値を高くし、第２のチャネルのログイン数の上限値を低くする処理を行うこと、を特徴とするサーバシステム。
7. 請求項２記載のサーバシステムにおいて、
   前記第１のサーバまたは前記制限管理部は、管理者による手動の情報入力に基づき、前記しきい値を更新する処理を行うこと、を特徴とするサーバシステム。
8. 請求項２記載のサーバシステムにおいて、
   前記第１のサーバまたは前記制限管理部は、定期的に前記セッション管理情報をチェックして、所定時間経過済みのレコードを削除する処理を行い、これにより前記ログイン数を把握すること、を特徴とするサーバシステム。
9. 請求項１記載のサーバシステムにおいて、
   前記しきい値として、前記上限値と対応して、それよりも小さい下限値が設定され、
   前記第１のサーバは、前記ログイン処理の際に、当該ログイン数が当該上限値以上の場合は、当該ログインを拒否するように制限を開始し、その後、当該ログイン数が当該下限値を下回った場合は、当該ログインを許可するように制限を解除すること、を特徴とするサーバシステム。

Images