(57)【要約】【課題】ログイン後に処理を行うオンラインシステムにおいてリソースを効率よく稼動させる。【解決手段】オンラインシステム１において、認証サーバ３は、ネットワーク９経由の同時ログイン数の調整によって顧客アクセスの流量制御を行う。そのために、ボトルネックになるＤＢサーバ６から、ＣＰＵ利用率等のリソース情報を通信線により直接取得し、そのリソース情報に応じてログイン閾値（同時ログイン数の閾値）を変更する。ＡＰサーバ５は、顧客の要求に応じた金融サービスを提供するが、必要に応じてＤＢサーバ６にアクセスし、ＤＢの参照、更新を行う一方、ホスト７からのＤＢサーバ６へのアクセスを支援する。ＤＢサーバ６は、顧客情報や取引履歴情報を格納し、ＡＰサーバ５からの指示に従ってデータの書き込み、読み出しを行うが、ネットワーク９経由の取引が行われると、その取引に係る処理としてＤＢの書き込みや読み出しが頻繁に行われるようになる。【選択図】図１
2010044633.tif 000002
【特許請求の範囲】
【請求項１】
利用者端末からのログインを受け付けて、そのログインを許可した後に前記利用者端末からの要求に応じた処理を実行するオンラインシステムであって、
最大ログイン許可数を示すログイン閾値を記憶する記憶部と、
ログイン要求を受け付けた際に、既存のログイン数と当該ログイン要求に係るログイン数の合計値が前記ログイン閾値以下であれば前記ログイン要求を許可し、前記合計値が前記ログイン閾値より大きければ前記ログイン要求を拒否するログイン制御部と、
前記処理の実行に必要なリソースの稼働状況に応じて前記ログイン閾値を変更し、前記記憶部に再設定するログイン管理部と、
を備えることを特徴とするオンラインシステム。
【請求項２】
請求項１に記載のオンラインシステムであって、
前記記憶部は、
前記リソースの稼働状況を示すリソース情報の適正範囲の上限値を示す上限側閾値と、
前記リソース情報の適正範囲の下限値を示す下限側閾値と、
をさらに記憶し、
前記リソース情報を取得する負荷監視部をさらに備え、
前記ログイン管理部は、
前記リソース情報が前記上限側閾値より大きければ、前記ログイン閾値を減少し、前記リソース情報が前記下限側閾値より小さければ、前記ログイン閾値を増加する
ことを特徴とするオンラインシステム。
【請求項３】
請求項２に記載のオンラインシステムであって、
前記リソース情報は、前記処理を実行するコンピュータのＣＰＵ利用率である
ことを特徴とするオンラインシステム。
【請求項４】
請求項２に記載のオンラインシステムであって、
前記ログイン管理部は、
前記ログイン閾値を減少する場合に、前記記憶部の前記ログイン閾値として現在のログイン数を設定する
ことを特徴とするオンラインシステム。
【請求項５】
利用者端末からのログインを受け付けて、そのログインを許可した後に前記利用者端末からの要求に応じた処理を実行するオンラインシステムにおいて、コンピュータが前記ログインを制限するアクセス制御方法であって、
前記コンピュータは、
ログイン要求を受け付けた際に、既存のログイン数と当該ログイン要求に係るログイン数の合計値が、予め記憶部に記憶された最大ログイン許可数を示すログイン閾値以下であれば前記ログイン要求を許可し、前記合計値が前記ログイン閾値より大きければ前記ログイン要求を拒否するステップと、
前記処理の実行に必要なリソースの稼働状況に応じて前記ログイン閾値を変更し、前記記憶部に再設定するステップと、
を実行することを特徴とするアクセス制御方法。
【請求項６】
請求項５に記載のアクセス制御方法であって、
前記コンピュータは、
前記リソースの稼働状況を示すリソース情報を取得するステップと、
前記リソース情報が、予め前記記憶部に記憶された前記リソース情報の適正範囲の上限値を示す上限側閾値より大きければ、前記ログイン閾値を減少するステップと、
前記リソース情報が、予め前記記憶部に記憶された前記リソース情報の適正範囲の下限値を示す下限側閾値より小さければ、前記ログイン閾値を増加するステップと、
をさらに実行することを特徴とするアクセス制御方法。
【請求項７】
請求項６に記載のアクセス制御方法であって、
前記リソース情報は、前記コンピュータのＣＰＵ利用率である
ことを特徴とするアクセス制御方法。
【請求項８】
請求項６に記載のアクセス制御方法であって、
前記コンピュータは、
前記ログイン閾値を減少する場合に、前記記憶部の前記ログイン閾値として現在のログイン数を設定する
ことを特徴とするアクセス制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オンラインシステムにおけるアクセス制御に関する。
【背景技術】
【０００２】
顧客に金融サービスを提供するダイレクトシステム（オンラインシステム）において、インターネット取引を行う上でバースト取引（取引の集中）を回避することはできないが、そのバースト取引によるシステムリソース（例えば、サーバのＣＰＵ（Central Processing Unit）やメモリ等）の逼迫を防ぐために、同時ログイン数を制限することによって顧客アクセスの流量制御を実施している。
【特許文献１】特開２００４−１２７１７２号公報
【特許文献２】特開２００６−１７１８２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
顧客はダイレクトシステムにログインした後に必ず取引を行うわけではないので、同時ログイン数と、実際にシステムリソースを使用する処理に係る取引件数との関係は、必ずしも線形にはならず、顧客の取引状況に応じて変化する。すなわち、ログイン数と対比して、取引件数が多い場合もあれば、少ない場合もある。例えば、ログイン数に対して取引件数が多い場合には、同時ログイン数の上限値に達する前にシステムリソースが逼迫してしまう。一方、ログイン数に対して取引件数が少ない場合には、同時ログイン数の上限値に達したときに、システムリソースに余裕があるにもかかわらず新たなログインを許可できないため、システムリソースが十分に稼働せず非効率的な状態になるという問題がある。
【０００４】
図６は、ダイレクトシステムのピーク時間帯における取引頻度係数の推移を示す図である。取引頻度係数は、取引件数をその時の同時ログイン数で除した値であり、この値が一定であれば、同時ログイン数と、取引件数とが線形の関係にあるので、システムリソースを確保するための計画を容易に立てられる。ところが、取引頻度係数は、実際には大きく変動する。図６によれば、取引頻度係数は、ダイレクトシステムのサービス開始の９：００をピークとして、時間の経過ともに小さくなっている。これは、サービス開始の時点においては、ログインした顧客が実際に取引を行う割合が最も高いが、時間とともに徐々に減っていき、換言すれば、ログインしても取引を行わない顧客の割合が増えてくるという傾向を示すものである。
【０００５】
なお、特許文献１には、ユーザ毎に、コンテンツに対する同時アクセス数（同時セッション数）を制限することができるコンテンツ閲覧制限装置について開示されているが、セッション数だけでアクセス制御すると、過負荷を回避することはできるが、システムリソースが十分に稼働するとは言えない。また、特許文献２には、コンピュータシステムで過負荷となることを予測し、事前に利用制限を行うアクセス制御装置について開示されているが、過負荷の予測がはずれると、正しく動作しないことが考えられる。
【０００６】
本発明は、上記課題を鑑みてなされたものであり、その主たる目的は、ログイン後に処理を行うオンラインシステムにおいてリソースを効率よく稼動させることにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明は、利用者端末からのログインを受け付けて、そのログインを許可した後に前記利用者端末からの要求に応じた処理を実行するオンラインシステムであって、最大ログイン許可数を示すログイン閾値を記憶する記憶部と、ログイン要求を受け付けた際に、既存のログイン数と当該ログイン要求に係るログイン数の合計値が前記ログイン閾値以下であれば前記ログイン要求を許可し、前記合計値が前記ログイン閾値より大きければ前記ログイン要求を拒否するログイン制御部と、前記処理の実行に必要なリソースの稼働状況に応じて前記ログイン閾値を変更し、前記記憶部に再設定するログイン管理部とを備えることを特徴とする。
【０００８】
この構成によれば、オンラインシステムにおいて、リソースの稼働状況に応じてログイン閾値を更新し、その閾値に基づいて外部からのログインを制限する。これは、リソースの稼働状況をそのままログイン制御に用いることはできないが、媒介項としてログイン閾値を設定し、そのログイン閾値をリソースの稼働状況に応じて変更可能とするものである。これによれば、ログイン数と、ログイン後の処理量との関係が随時変化するため、ログイン閾値を一定にしただけではリソースの稼働状況が変動する場合に、その稼働状況に連動してログイン閾値を変更するので、オンラインシステムのリソースを効率よく稼働させることができる。これによれば、突発的なログイン要求を受け付けて、その処理を実行した場合でも、リソースの安定的な稼働を確保することができる。
【０００９】
また、本発明は、オンラインシステムであって、前記記憶部が、前記リソースの稼働状況を示すリソース情報の適正範囲の上限値を示す上限側閾値と、前記リソース情報の適正範囲の下限値を示す下限側閾値とをさらに記憶し、前記リソース情報を取得する負荷監視部をさらに備え、前記ログイン管理部が、前記リソース情報が前記上限側閾値より大きければ、前記ログイン閾値を減少し、前記リソース情報が前記下限側閾値より小さければ、前記ログイン閾値を増加することを特徴とする。
【００１０】
この構成によれば、リソースの稼働状況のデータが上限側閾値より大きい場合は、リソースが逼迫している、又は、そのおそれがあることを示し、ログイン閾値を減少することによって、新たなログインを制限することができるので、さらなる高負荷を抑止し、システム稼働の安定化を図ることができる。一方、当該データが低負荷閾値より小さい場合は、リソースに余裕があることを示し、ログイン閾値を増加することによって、今まで以上にログインを許可することができるので、リソースを極力有効に稼働させることができる。
【００１１】
また、本発明は、オンラインシステムであって、前記リソース情報が、前記処理を実行するコンピュータのＣＰＵ利用率であることを特徴とする。
【００１２】
また、本発明は、オンラインシステムであって、前記ログイン管理部が、前記ログイン閾値を減少する場合に、前記記憶部の前記ログイン閾値として現在のログイン数を設定することを特徴とする。
【００１３】
この構成によれば、ログイン閾値を現在のログイン数にするため、実際のログイン数が現在のログイン数より増えることはないので、リソースがさらに高負荷になるのを防ぐことができる。さらに加えて、現在のログイン状態を中断することなく、現在確立されたログイン状態を保障することができる。
【００１４】
なお、本発明は、アクセス制御方法を含む。その他、本願が開示する課題及びその解決方法は、発明を実施するための最良の形態の欄、及び図面により明らかにされる。
【発明の効果】
【００１５】
本発明によれば、ログイン後に処理を行うオンラインシステムにおいてリソースを効率よく稼動させることができる。これによれば、インターネット取引において突発し、予測が困難なバースト取引からリソースを保護し、その安定的な稼働を保障することができる。
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照しながら、本発明を実施するための最良の形態を説明する。本発明の実施の形態に係るオンラインシステムは、ネットワークを通じて顧客へ金融サービスを提供するに際して、顧客のシステムログイン及びその後の取引の状況、すなわち、端末からの現在のログイン数及びシステムリソースの稼働率に基づいて、同時ログイン数を制限するものである。同時ログイン数制御は、ＣＰＵ利用率を適度に抑えるために、オンラインシステムにおいてＣＰＵボトルネックとなるサーバのリソースを監視し、例えば、そのサーバのＣＰＵ利用率が適正範囲の上限側閾値に達した時には、同時ログイン数の上限値、すなわち、最大ログイン許可数（以下、ログイン閾値）を動的に小さく再設定する。
【００１７】
≪システムの構成と概要≫
図１は、オンラインシステムとその周辺の構成を示す図である。オンラインシステム１は、ファイアウオール２、認証サーバ３、ファイアウオール４、ＡＰサーバ５及びＤＢサーバ６を備えるとともに、ホスト７に接続され、一方、ネットワーク９を経由して端末８と通信可能である。
【００１８】
ファイアウオール２は、ネットワーク９を通じた外部からのアクセスを直接的に受け付けて、帯域制御を行ったり、同時コネクション数を調整したりする。帯域制御とは、ネットワークトラフィックやパケットの測定・制御を行うことである。コネクションとは、通信回線を介したコンピュータ間における接続関係のことである。認証サーバ３は、ネットワーク９を介したアクセスのうち、同時ログイン数の調整によって顧客アクセスの流量制御を行う。そのために、取引処理においてＤＢを参照、更新する経路（ファイアウオール４及びＡＰサーバ５経由）ではなく、通信線により直接ＤＢサーバ６からＣＰＵ利用率等のリソース情報を取得し、そのリソース情報が示す稼働状況に応じてログイン閾値を変更する。
【００１９】
ファイアウオール４は、認証サーバ３だけでなく、図示しない電話システムや金融機関内の共通認証システムにも接続され、金融機関の外部、内部を含めた全ての同時コネクション数を調整する。ＡＰサーバ５は、顧客の要求に応じた金融サービスを提供する業務サーバであり、端末８からの要求メッセージに応じた取引処理を行いながら、ＤＢサーバ６に随時アクセスし、ＤＢの参照、更新を行う。また、ホスト７に接続され、ホスト７からのＤＢサーバ６へのアクセスを支援する。ＤＢサーバ６は、顧客情報や取引履歴情報を格納するデータベースサーバであり、ＡＰサーバ５からの指示に従ってデータの書き込み、読み出しを行うが、ネットワーク９経由の取引が行われると、その取引に係る処理としてＤＢの書き込みや読み出しが頻繁に行われるようになり、オンラインシステム１におけるボトルネックになりうる。
【００２０】
ホスト７は、ＡＴＭ（Automatic Teller Machine）端末等（図示せず）からのアクセスを受け付けて、顧客の要求に応じたサービスを提供する汎用コンピュータであり、必要に応じてＡＰサーバ５経由でＤＢサーバ６にアクセスする。
【００２１】
端末８は、ネットワーク９経由で金融サービスを受ける顧客が所持するＰＣ（Personal Computer）や携帯端末であり、例えば、当該金融機関のＨＰ（Home Page）を表示することによって、顧客が金融サービスを享受することを可能にする。ネットワーク９は、オンラインシステム１と、端末８との間を通信可能にするネットワークであり、例えば、インターネット等によって実現される。なお、オンラインシステム１へのアクセスは、直接のユーザである顧客の端末８からだけではなく、他のシステム（例えば、ログイン用のアプリケーションプログラムがインストールされたコンピュータ等）からの問い合わせによることもある。
【００２２】
≪認証サーバの構成≫
図２は、認証サーバ３のハードウェア構成を示す図である。認証サーバ３は、通信部３１、表示部３２、入力部３３、処理部３４及び記憶部３５を備える。通信部３１は、通信線を介してファイアウオール２、４及びＤＢサーバ６と通信を行う部分であり、例えば、ＮＩＣ（Network Interface Card）等によって実現される。表示部３２は、処理部３４からの指示によりデータを表示する部分であり、例えば、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）等によって実現される。入力部３３は、オペレータがデータ（例えば、記憶部３５の設定情報の初期値等）を入力する部分であり、例えば、キーボードやマウス等によって実現される。処理部３４は、各部間のデータの受け渡しを行うととともに、認証サーバ３全体の制御を行うものであり、ＣＰＵが所定のメモリに格納されたプログラムを実行することによって実現される。記憶部３５は、処理部３４からデータを記憶したり、記憶したデータを読み出したりするものであり、例えば、フラッシュメモリやハードディスク装置等の不揮発性記憶装置によって実現される。
【００２３】
図３は、認証サーバ３の処理部３４の機能構成を示す図である。処理部３４は、機能として、全体制御部３４Ａ、ログイン制御部３４Ｂ、ログイン管理部３４Ｃ及び負荷監視部３４Ｄを備える。全体制御部３４Ａは、発生したイベント（例えば、通信部３１によるログイン要求メッセージの受信、負荷監視部３４Ｄによるログイン数増減の指示等）に応じて、処理部３４内の他の各部を起動することによって、処理部３４全体の処理の流れを制御する。また、通信部３１及び記憶部３５と、処理部３４内の他の各部との間のインタフェースを制御することによって、メッセージやデータの受け渡しを行う。全体制御部３４Ａは、いわゆるカーネル又はスケジューラと呼ばれるプログラムモジュールである。
【００２４】
ログイン制御部３４Ｂ、ログイン管理部３４Ｃ及び負荷監視部３４Ｄの各部は、全体制御部３４Ａによる制御の下で動作することによって、認証サーバ３の具体的な機能を実現するプログラムモジュールである。ログイン制御部３４Ｂは、ログイン閾値を用いて新たなログインを制限することで、顧客アクセスの流量を制御する。なお、流量制御の方法は、ログイン数による制限に限定しない。ログイン管理部３４Ｃは、負荷監視部３４Ｄからの指示により、ログイン閾値を算出し、記憶部３５に再設定する。負荷監視部３４Ｄは、定期的にシステムリソースの稼働状況（例えば、ＤＢサーバ６のＣＰＵ利用率等）を監視し、閾値との比較結果に応じたログイン数増減の指示をログイン管理部３４Ｃに対して行う。そして、各部の連携により、システムリソースの高負荷時にはログイン数を減少し、低負荷時にはログイン数を増加する。
【００２５】
≪データの構成≫
図４は、認証サーバ３の記憶部３５に記憶されるデータの構成を示す図である。記憶部３５には、ログイン情報３５Ａ、ログイン閾値情報３５Ｂ、リソース情報３５Ｃ及びリソース閾値情報３５Ｄが記憶される。ログイン情報３５Ａは、端末８からのオンラインシステム１へのログイン数の現在値である。ログイン閾値情報３５Ｂは、同時ログイン数の上限値、すなわち、ログイン閾値である。リソース情報３５Ｃは、現在のシステムリソースの稼働状況を示す情報であり、例えば、オンラインシステム１のボトルネックとなるＤＢサーバ６におけるＣＰＵ利用率、メモリやＪａｖａ（登録商標）のヒープ領域の使用状況、それらの組合せ等であるが、ここでは、ＣＰＵ利用率を用いる。リソース閾値情報３５Ｄは、システムリソースの稼働状況に関する閾値であり、その稼働状況に応じてログイン閾値を変更するために設定される値である。例えば、ＤＢサーバ６におけるＣＰＵ利用率の適正範囲の上限側閾値及び下限側閾値であり、ＣＰＵ利用率が上限側閾値を上回った（高負荷になった）場合にログイン数を減少し、下限側閾値を下回った（低負荷になった）場合にログイン数を増加するような制御が行われる。なお、各データは、認証サーバ３の処理部３４によって随時更新される。特に、ログイン情報３５Ａ及びリソース情報３５Ｃは、現在の稼働状況を示すものであるので、ログイン制御の精度を上げるために定期的に更新される。
【００２６】
≪システムの処理≫
図５は、オンラインシステム１のログイン制御に関する処理を示すフローチャートである。このフローチャートでは、オンラインシステム１のうち、特にログイン制御に関与する認証サーバ３の処理部３４の処理を中心に説明する。
【００２７】
まず、端末８は、例えば、ディスプレイに表示されたＨＰに対する顧客の操作を受けて、オンラインシステム１へのアクセス要求を行う（Ｓ５０１）。そのアクセス要求は、一例として、システムへのログイン要求であり、オンラインシステム１のファイアウオール２を通過し、認証サーバ３に受け付けられる。
【００２８】
認証サーバ３の処理部３４では、端末８からのアクセス要求を受けて、ログイン制御部３４Ｂが、記憶部３５から現在のログイン数及びログイン閾値を取得し、それらの値の大小比較を行う（Ｓ５０３）。現在のログイン数がログイン閾値より大きくない場合には（Ｓ５０３のＮ）、さらなるログインが可能なので、端末８に対してアクセスの許可を通知する（Ｓ５０４）。現在のログイン数がログイン閾値より大きい場合には（Ｓ５０３のＹ）、さらなるログインができないので、端末８に対してアクセスの拒否を通知する（Ｓ５０５）。なお、現在のログイン数は、既存のログイン数と当該アクセス要求（ログイン要求）に係るログイン数の合計値に置き換えてもよい。
【００２９】
一方、認証サーバ３の処理部３４では、端末８からのアクセス要求に同期することなく、負荷監視部３４Ｄが、定期的に記憶部３５からリソース情報（ＤＢサーバ６のＣＰＵ利用率）の現在値及び閾値を取得する（Ｓ５１１）。閾値には、既に説明したように、ＣＰＵ利用率の適正範囲の上限側閾値及び下限側閾値があり、上限側閾値＞下限側閾値の大小関係が成立する。そして、現在値と上限側閾値との大小比較を行う（Ｓ５１２）。現在値が上限側閾値を超えた場合には（Ｓ５１２のＹ）、システムリソースが逼迫していることを意味するので、ログイン管理部３４Ｃに対してログイン数減少の指示を行う（Ｓ５１３）。現在値が上限側閾値を超えていない場合には（Ｓ５１２のＮ）、現在値と下限側閾値との大小比較を行う（Ｓ５１４）。現在値が下限側閾値より小さい場合には（Ｓ５１４のＹ）、システムリソースに余裕があることを意味するので、ログイン管理部３４Ｃに対してログイン数増加の指示を行う（Ｓ５１５）。現在値が下限側閾値より小さくない場合には（Ｓ５１４のＮ）、現在値が下限側閾値と上限側閾値との間にあり、システムリソースが適度に稼働していることを意味するので、ログイン管理部３４Ｃに対するログイン数変更の指示は行わない。
【００３０】
ログイン管理部３４Ｃは、負荷監視部３４Ｄからログイン数の減少又は増加の指示を受けて、まず、記憶部３５から現在のログイン数を取得する（Ｓ５１６）。そして、ログイン数の減少又は増加の指示と現在のログイン数に基づいて、ログイン閾値を算出し、記憶部３５に再設定する（Ｓ５１７）。ログイン閾値の算出は、事前に決められた論理に従って行われる。
【００３１】
例えば、ＤＢサーバ６のＣＰＵ利用率が上限側閾値を超えたために、負荷監視部３４Ｄからログイン数減少の指示を受けた場合には、ログイン閾値をその時点における実際のログイン数に引き下げる。すなわち、記憶部３５において、ログイン情報３５Ａの値をログイン閾値情報３５Ｂに書き込む。これによれば、ログイン制御部３４Ｂが新たなログインを拒否することによって、システムリソースの逼迫を防ぐことができる。換言すれば、リソースの逼迫と同時に、顧客のログインを制限するものである。
【００３２】
別の例として、ＤＢサーバ６のＣＰＵ利用率が下限側閾値を下回ったために、負荷監視部３４Ｄからログイン数増加の指示を受けた場合には、ログイン情報３５Ａである現在のログイン数が、ログイン閾値情報３５Ｂであるログイン閾値の所定割合（例えば、８０％）以上のときに、ログイン閾値を所定割合（例えば、１０％）だけ引き上げる。現在のログイン数がログイン閾値の所定割合（例えば、８０％）未満のときには、ログイン閾値を変更しない。なお、ログイン閾値の所定割合は、整数値である。これによれば、ログイン閾値を引き上げることによって、余裕のあるシステムリソースを有効に稼働させることができる。換言すれば、リソースの許す限り、顧客のログインを許可して取引を促すものである。
【００３３】
オンラインシステム１においては、ＤＢサーバ６のＣＰＵ利用率を継続して監視し、低負荷の状態が所定時間以上続いていると判断すればログイン閾値を上げ、高負荷の状態が所定時間以上続いていると判断すればログイン閾値を下げる。この処理を繰り返すことによって、システムリソースを効率的かつ安定的に稼働させることができる。
【００３４】
以上本発明の実施の形態について説明したが、図１に示すオンラインシステム１内の各装置を機能させるために、各装置に内蔵されるＣＰＵで実行されるプログラムをコンピュータにより読み取り可能な記録媒体に記録し、その記録したプログラムをコンピュータに読み込ませ、実行させることにより、本発明の実施の形態に係るオンラインシステムが実現されるものとする。なお、プログラムをインターネット等のネットワーク経由でコンピュータに提供してもよいし、プログラムが書き込まれた半導体チップ等をコンピュータに組み込んでもよい。
【００３５】
以上説明した本発明の実施の形態によれば、オンラインシステム１において、認証サーバ３が、ボトルネックとなるリソースの稼働状況（ＤＢサーバ６のＣＰＵ利用率等）に応じてログイン閾値情報３５Ｂ（ログイン閾値）を更新し、その閾値に基づいて外部（端末８等）からのログインを制限する。これによれば、ログイン数と、ログイン後の処理量（取引件数）との関係が随時変化するため、ログイン閾値を一定にしただけではリソースの稼働状況が変動する場合に、その稼働状況に連動してログイン閾値を変更するので、オンラインシステム１のリソース（ＤＢサーバ６のＣＰＵやメモリ等）を効率よく（つまり、逼迫させることなく、かつ、無駄に余裕を持たせることなく）稼働させることができる。
【００３６】
≪その他の実施の形態≫
以上、本発明を実施するための最良の形態について説明したが、上記実施の形態は本発明の理解を容易にするためのものであり、本発明を限定して解釈するためのものではない。本発明はその趣旨を逸脱することなく変更、改良され得るとともに、本発明にはその等価物も含まれる。例えば、以下のような実施の形態が考えられる。
【００３７】
（１）上記実施の形態では、オンラインシステム１におけるログイン制御に関する処理全般を、認証サーバ３が行うように記載したが、認証サーバ３、ＡＰサーバ５及びＤＢサーバ６が分担して行うようにしてもよい。
【００３８】
（２）上記実施の形態では、オンラインシステム１がネットワークを通じて顧客へ金融サービスを提供するものであるように記載したが、ログイン後に処理を行うシステムであれば、金融機関以外のシステムであってもよい。例えば、ログイン後にオンラインショッピングを行うことができるような会員制のシステムであってもよい。
【００３９】
（３）上記実施の形態では、負荷監視部３４Ｄがリソース情報を取得し、リソース情報と閾値との大小関係に応じて、ログイン管理部３４Ｃにログイン数の増減指示を行うように記載したが、ログイン管理部３４Ｃが負荷監視部３４Ｄからリソース情報を取得し、リソース情報と閾値との大小関係に応じて、ログイン閾値を再設定するようにしてもよい。
【図面の簡単な説明】
【００４０】
【図１】オンラインシステム１とその周辺の構成を示す図である。
【図２】認証サーバ３のハードウェア構成を示す図である。
【図３】認証サーバ３の処理部３４の機能構成を示す図である。
【図４】認証サーバ３の記憶部３５に記憶されるデータの構成を示す図である。
【図５】オンラインシステム１のログイン制御に関する処理を示すフローチャートである。
【図６】ダイレクトシステムのピーク時間帯における取引頻度係数の推移を示す図である。
【符号の説明】
【００４１】
１      オンラインシステム
３      認証サーバ
３４    処理部
３５    記憶部
３５Ａ  ログイン情報（実際のログイン数）
３５Ｂ  ログイン閾値情報（ログイン閾値）
３５Ｃ  リソース情報（ＣＰＵ利用率）
３５Ｄ  リソース閾値情報（上限側閾値、下限側閾値）
５      ＡＰサーバ
６      ＤＢサーバ
【図１】
2010044633.tif 000003
【図２】
2010044633.tif 000004
【図３】
2010044633.tif 000005
【図４】
2010044633.tif 000006
【図５】
2010044633.tif 000007
【図６】
2010044633.tif 000008