(57)【要約】【課題】アクセスを試みて失敗したユーザに対して、次のアクセスにおいては、そのユーザを優先的にアクセス可能とするアクセス管理サーバ、アクセス管理方法及びその顧客端末を提供する。【解決手段】  顧客端末１０とインターネットバンキングを実行するアクセス管理サーバ１００は、アクセスのあった顧客端末１０から入力された契約者ＩＤを受信し、顧客端末１０からのアクセスに応じて、当該アクセス数をカウントして、カウントしたアクセス数が所定数以上であることを判断し、アクセス数が所定数以上であると判断した場合は、契約者ＩＤに対応するアクセス優先フラグをオンにすることで、顧客端末１０からの再度のアクセスを優先的に制御する。【選択図】図２
2013206179.tif 000002
【特許請求の範囲】
【請求項１】
顧客端末と通信可能に接続され、当該顧客端末とインターネットバンキングを実行するサーバであって、
前記アクセスのあった顧客端末から入力された契約者ＩＤを受信する契約者ＩＤ受信手段と、
前記顧客端末からのアクセスに応じて、当該アクセス数をカウントして、カウントしたアクセス数が所定数以上であることを判断するアクセス数判断手段と、
前記アクセス数が所定数以上であると判断した場合は、前記契約者ＩＤに対応するアクセス優先フラグをオンにすることで、前記顧客端末からの再度のアクセスを優先的に制御するアクセス制御手段と、
を備えるアクセス管理サーバ。
【請求項２】
前記アクセス数が所定数以上であると判断した場合は、さらに、前記契約者ＩＤに対応するユーザに、当該ユーザがサーバにアクセス可能な時間に関するメッセージデータを送信する請求項１に記載のアクセス管理サーバ。
【請求項３】
請求項２に記載のアクセス管理サーバと通信可能に接続された顧客端末であって、前記顧客端末は、前記アクセス管理サーバからメッセージデータを受信したことに応じて、前記アクセス可能な時間に、前記アクセス管理サーバにアクセスするアクセス手段を備える顧客端末。
【請求項４】
請求項３に記載の顧客端末であって、
前記アクセス手段が、前記アクセス可能な時間に、前記アクセス管理サーバにアクセスしたが、アクセスが不可能であった場合は、前記顧客端末がアクセス可能な時間を、前記アクセス管理サーバに取得する顧客端末。
【請求項５】
顧客端末と通信可能に接続され、当該顧客端末とインターネットバンキングを実行するサーバが実行するアクセス管理方法であって、
前記アクセスのあった顧客端末から入力された契約者ＩＤを受信するステップと、
前記顧客端末からのアクセスに応じて、当該アクセス数をカウントして、カウントしたアクセス数が所定数以上であることを判断するステップと、
前記アクセス数が所定数以上であると判断した場合は、前記契約者ＩＤに対応するアクセス優先フラグをオンにすることで、前記顧客端末からの再度のアクセスを優先的に制御するステップと、
を備えるアクセス管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アクセス管理サーバ、アクセス管理方法及び、その顧客端末に関し、特に、サーバへのアクセスを管理するアクセス管理サーバ、アクセス管理方法及び、その顧客端末に関する。
【背景技術】
【０００２】
今日、銀行等の金融機関では、インターネットを経由して自分の口座の預金残高を閲覧可能としたり、他人の口座への振込みを可能とするインターネットバンキングのサービスを提供している。
【０００３】
一般に、インターネットバンキングの利用者は、給料日やボーナス日など、特定の日に集中してアクセスする傾向がある。したがって、インターネットバンキングのサーバは、これらの特定の日に対して、一定の負荷軽減の措置が必要である。すなわち、サーバに対して所定数を越えたアクセスを拒否することが行われるため、結果的に、サーバへアクセス出来ないユーザが発生してしまう。
【０００４】
一般に、店舗等の混雑状況の緩和については、例えば、特許文献１のように、事前に混雑状況や混雑予想日時を利用者に知らせる方法が知られている。また、特許文献２のように、店舗への予約をメール等で簡単に行うことで負荷分散が図られている。
【０００５】
一方、サーバに対する負荷分散としては、特許文献３のように、インターネットサービスプロバイダの特定のコンテンツに対するアクセスに対して、ユーザが所有するポイントの減少率を変更することで、負荷分散を促進する方法が知られている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開第２００１−３０６９３３号公報
【特許文献２】特開第２０１０−２０５０５３号公報
【特許文献３】特開第２００１−２９７２６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、上記の特許文献では、ユーザがサーバにアクセスして、混雑のためにアクセスが出来なかった際に、再度、どのようなタイミングでアクセスを行えば良いかが不明であり、次のアクセスでもアクセスができない場合が発生してしまう。
【０００８】
そこで、本発明者らは、一度、アクセスを試みて、失敗した場合には、次のアクセスにおいて、そのユーザを優先的にアクセスが可能にすべきではないかという点に着目した。
【０００９】
本発明では、アクセスを試みて失敗したユーザに対して、次のアクセスにおいては、そのユーザを優先的にアクセス可能とするアクセス管理サーバ、アクセス管理方法及びその顧客端末を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明は、以下のような解決手段を備える。
【００１１】
（１）  顧客端末と通信可能に接続され、当該顧客端末とインターネットバンキングを実行するサーバであって、
前記アクセスのあった顧客端末から入力された契約者ＩＤを受信する契約者ＩＤ受信手段と、
前記顧客端末からのアクセスに応じて、当該アクセス数をカウントして、カウントしたアクセス数が所定数以上であることを判断するアクセス数判断手段と、
前記アクセス数が所定数以上であると判断した場合は、前記契約者ＩＤに対応するアクセス優先フラグをオンにすることで、前記顧客端末からの再度のアクセスを優先的に制御するアクセス制御手段と、
を備えるアクセス管理サーバ。
【００１２】
（１）の発明によれば、アクセスのあった顧客端末から入力された契約者ＩＤを受信し、顧客端末からのアクセスに応じて、当該アクセス数をカウントして、カウントしたアクセス数が所定数以上であることを判断し、アクセス数が所定数以上であると判断した場合は、契約者ＩＤに対応するアクセス優先フラグをオンにすることで、顧客端末からの再度のアクセスを優先的に制御する。
【００１３】
したがって、一度、アクセスを試みてアクセスできずに失敗したユーザに対して、契約者ＩＤの受信まで完了しておくことで、次回のアクセスにおいては、そのユーザを優先的にアクセス可能とすることが可能となる。
【００１４】
（２）  前記アクセス数が所定数以上であると判断した場合は、さらに、前記契約者ＩＤに対応するユーザに、当該ユーザがサーバにアクセス可能な時間に関するメッセージデータを送信する（１）に記載のアクセス管理サーバ。
【００１５】
（２）の発明によれば、（１）の発明における、アクセスを優先的に制御する具体的な処理として、契約者ＩＤに対応するユーザに、当該ユーザがサーバにアクセス可能な時間に関するメッセージデータを送信することで、過去にアクセスしたユーザに優先的にアクセスを行わせることが可能となる。
【００１６】
（３）  （２）に記載のアクセス管理サーバと通信可能に接続された顧客端末であって、前記顧客端末は、前記アクセス管理サーバからメッセージデータを受信したことに応じて、前記アクセス可能な時間に、前記アクセス管理サーバにアクセスするアクセス手段を備える顧客端末。
【００１７】
（３）の発明によれば、（２）の発明におけるメッセージデータを受信した顧客端末は、メッセージデータに基づいて、アクセス可能な時間に、アクセス管理サーバに自動的にアクセスすることで、過去にアクセスしたユーザに優先的にアクセスを行わせることが可能となる。
【００１８】
（４）  （３）に記載の顧客端末であって、
前記アクセス手段が、前記アクセス可能な時間に、前記アクセス管理サーバにアクセスしたが、アクセスが不可能であった場合は、前記顧客端末がアクセス可能な時間を、前記アクセス管理サーバから取得する顧客端末。
【００１９】
（５）  顧客端末と通信可能に接続され、当該顧客端末とインターネットバンキングを実行するサーバが実行するアクセス管理方法であって、
前記アクセスのあった顧客端末から入力された契約者ＩＤを受信するステップと、
前記顧客端末からのアクセスに応じて、当該アクセス数をカウントして、カウントしたアクセス数が所定数以上であることを判断するステップと、
前記アクセス数が所定数以上であると判断した場合は、前記契約者ＩＤに対応するアクセス優先フラグをオンにすることで、前記顧客端末からの再度のアクセスを優先的に制御するステップと、
を備えるアクセス管理方法。
【発明の効果】
【００２０】
本発明によれば、アクセスを試みて失敗したユーザに対して、次のアクセスにおいては、そのユーザを優先的にアクセス可能とするアクセス管理サーバ、アクセス管理方法及びその顧客端末を提供することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の好適な実施形態であるアクセス管理システム１の全体構成を示す図である。
【図２】本発明の好適な実施形態であるアクセス管理サーバ１００、顧客端末１０、ログ管理サーバ１５０、メール生成サーバ２００の機能ブロック図である。
【図３】本発明の好適な実施形態であるアクセス制御処理（優先フラグ起動）のフローチャートである。
【図４】本発明の好適な実施形態であるアクセス履歴テーブルである。
【図５】本発明の好適な実施形態であるアクセス制御処理（優先アクセス処理）のフローチャートである。
【図６】本発明の好適な実施形態であるアクセス制御処理（自動アクセス処理）のフローチャートである。
【図７】本発明の好適な実施形態であるメッセージデータの出力イメージ図である。
【図８】本発明の好適な実施形態である優先アクセス通知の出力イメージ図である。
【図９】本発明の好適な実施形態である自動アクセス完了通知の出力イメージ図である。
【発明を実施するための形態】
【００２２】
以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。
【００２３】
［アクセス管理システムの構成］
図１は、アクセス管理システム１の全体構成図である。アクセス管理システム１は、アクセス管理サーバ１００、ログ管理サーバ１５０、メール生成サーバ２００、顧客端末１０ａ、ｂ、ｃ（以下、「顧客端末１０」とする）と、公衆回線網３とから構成される。顧客端末１０と、アクセス管理サーバ１００、ログ管理サーバ１５０、メール生成サーバ２００は、インターネット等の公衆回線網３を介して通信可能に接続されてもよいし、専用回線で通信可能に接続されてよい。
【００２４】
顧客端末１０から、アクセス管理サーバ１００、ログ管理サーバ１５０、メール生成サーバ２００へアクセスを行って、インターネットバンキングサービスを提供するが、ここに図示されていない他のサーバと顧客端末１０が通信することで、インターネットバンキングサービスを実現してもよい。
【００２５】
次に、図２を参照して、アクセス管理サーバ１００、顧客端末１０、ログ管理サーバ１５０、メール生成サーバ２００の構成について説明する。
【００２６】
アクセス管理サーバ１００は、顧客端末１０等の他の機器と通信可能なサーバ、コンピュータであって、制御部１０１、データ記憶部１０２、データ通信部１０３を備える。アクセス管理サーバ１００は、インターネットバンキングサービスを提供する機能を備えていてもよいし、インターネットバンキングサービスの機能は他のサーバが実行し、下記で説明するように、ユーザからのアクセスを管理する機能のみを備えていてもよい。すなわち、アクセス管理サーバ１００は、インターネットバンキングサービスを実現するサーバのアクセス管理を行うサーバとしてのみ機能してもよい。
【００２７】
アクセス管理サーバ１００は、インターネットバンキングサービスを実施する銀行又は、この銀行のシステムを提供する業者が運営するのが一般的である。
【００２８】
制御部１０１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）等を備え、データ通信部１０３として、有線又は無線対応通信デバイスを備え、データ記憶部１０２として、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等のいずれか又は双方を備える。
【００２９】
データ記憶部１０２には、顧客であるユーザのＩＤを管理する契約者ＩＤデータベース３１を備える。各ユーザのメールアドレスは、後述するメッセージデータや通知を行う際に利用されてもよく、契約者ＩＤに対応付けられて契約者ＩＤデータベース３１に記憶される。
【００３０】
アクセス管理サーバ１００は、制御部１０１及びデータ通信部１０３との協働により、契約者ＩＤ受信モジュール１１２と、アクセス数判断モジュール１１０と、アクセス制御モジュール１１１とを実現する。
【００３１】
ログ管理サーバ１５０は、アクセス管理サーバ１００と通信可能に接続されたサーバであって、契約者ＩＤ毎に、アクセス管理サーバ１００に対する顧客端末１０からのアクセス履歴を管理するサーバである。ログ管理サーバ１５０は、アクセス履歴データベース１５１を備え、アクセス履歴データベースには、図４で説明するアクセス履歴テーブルが記憶される。
【００３２】
メール生成サーバ２００は、アクセス管理サーバ１００と通信可能に接続されたサーバであって、顧客端末１０に送信するメールを生成するサーバである。
【００３３】
以下では、ログ管理サーバ１５０、メール生成サーバ２００をアクセス管理サーバ１００とは個別に記載するが、ログ管理サーバ１５０、メール生成サーバ２００の機能が、アクセス管理サーバ１００に含まれていてもよい。例えば、アクセス履歴データベース１５１が、アクセス管理サーバ１００のデータ記憶部１０２に備えられていてもよい。
【００３４】
顧客端末１０は、インターネットバンキングを行うためにアクセスする端末であって、図１に示すように、パソコン１０ａ、スレート端末１０ｂ、スマートフォン１０ｃや、携帯電話、電子書籍端末等の情報通信機器であってよい。顧客端末１０は、制御部１１、データ通信部１３、データ記憶部１２、入出力部１４を備える。
【００３５】
制御部１１は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）等を備え、データ通信部１３として、有線又は無線対応通信デバイスを備える。データ記憶部１２として、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等のいずれか又は双方を備える。さらに、入出力部１４として、画像を表示する液晶モニタ等の表示部を備え、ユーザからの入力を受付けるタッチパネルや音声入力等の入力部を備える。
【００３６】
顧客端末１０は、制御部１１とデータ通信部１３との協働により、アクセスモジュール２１を実現する。
【００３７】
［アクセス制御処理（優先フラグ起動処理）］
次に、図３を参照して、アクセス制御処理の優先フラグ起動処理について説明する。本処理は、アクセス要求をしても、システムにアクセス出来なかった場合に、優先アクセスフラグを起動する処理である。
【００３８】
最初に、顧客端末１０は、ユーザからインターネットバンキングに対するアクセス要求があったか否かを判断する（ステップＳ０１）。アクセス要求があった場合（ステップＳ０１：「ＹＥＳ」）は、ステップＳ０２に処理を移す。アクセス要求があるまでは（ステップＳ０１：「ＮＯ」）、処理待ちとなる。
【００３９】
このアクセス要求は、ユーザがＷｅｂブラウザに、ＵＲＬ（ＵｎｉｆｏｒｍＲｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）を入力することで行われてもよいし、所定のアプリケーションを起動することで行われてもよい。
【００４０】
次に、顧客端末１０は、利用するユーザの契約者ＩＤの入力を受付ける（ステップＳ０２）。この処理は、例えば、Ｗｅｂブラウザ内の所定のウィンドウに、ＩＤとパスワードの入力を受付けることで行われる。顧客端末１０は、入力された契約者ＩＤをアクセス管理サーバ１００に送信して、アクセス要求を行う。
【００４１】
アクセス管理サーバ１００の契約者ＩＤ受信モジュール１１２は、契約者ＩＤを受信してアクセスを受信する（ステップＳ０３）。なお、ここでのアクセスとは、契約者ＩＤの受信を受付けるアクセスである。アクセス数とは、顧客端末１０からアクセス管理サーバ１００に対してアクセス可能な数であって、アクセス数の一例が、アクセス管理サーバ１００に対するセッション数である。
【００４２】
そして、アクセス管理サーバ１００のアクセス数判断モジュール１１０は、アクセス管理サーバ１００にアクセスしている顧客端末１０のセッション数が、所定数以上であるかの判断を行う（ステップＳ０４）。セッション数の最大値は、アクセス管理サーバ１００の通信負荷の許容の度合いに応じて決定され、セッション数の最大値を現実のセッション数が超えると、システム負荷によりアクセス処理に障害を生じる。
【００４３】
顧客端末１０のセッション数が、所定数以上であると判断した場合（ステップＳ０４：「ＹＥＳ」）は、ステップＳ０５に処理を移す。顧客端末１０のセッション数が、所定数以上でないと判断した場合（ステップＳ０４：「ＮＯ」）は、通常の処理を行うことが可能であるため、図６のアクセス制御処理（自動アクセス処理）のステップＳ２７からの処理を実行する。
【００４４】
次に、アクセス管理サーバ１００のアクセス制御モジュール１１１は、ログ管理サーバ１５０に、アクセス情報を送信する（ステップＳ０５）。ここで、アクセス情報とは、アクセスのあった顧客端末１０の契約者ＩＤを少なくても含むデータである。
【００４５】
これに応じて、ログ管理サーバ１５０のアクセス履歴データベース１５１は、ログ管理サーバ１５０のアクセス履歴データベース１５１に記憶されたアクセス履歴テーブルに対して、対応する契約者ＩＤを検索する。
【００４６】
図４に示すように、アクセス履歴テーブルは、契約者ＩＤと優先アクセスフラグとが少なくとも対応付けられており、これ以外にも、契約者ＩＤと、アクセス時間や、契約者の取引種別を示す取引コード等が対応付けられていてよい。アクセス履歴テーブルは、ある契約者ＩＤを有するユーザがアクセスを複数回していて、そのアクセスの結果、アクセスが拒否された回数を記録してもよい。
【００４７】
検索した結果、ログ管理サーバ１５０は、対応する契約者ＩＤを抽出し、対応する優先アクセスフラグを、起動（「１」）する（ステップＳ０７）。
【００４８】
一方、アクセス管理サーバ１００は、アクセス情報を送信した後に、メッセージデータをメール生成サーバ２００より取得する（ステップＳ０８）。すなわち、アクセス管理サーバ１００は、アクセスが出来なかったことをアクセスしたユーザに通知してお詫びするメッセージと、このシステムにアクセスしやすい将来の日時、曜日又は時間帯を示すメッセージを、メール生成サーバ２００より取得する。
【００４９】
メール生成サーバ２００には、予めメッセージの雛形が記憶されている。また、アクセス管理サーバ１００は、経時的に変化する顧客端末１０からのアクセス数を統計的に処理していることで、このシステムにアクセスしやすい将来の日時、曜日又は時間帯を決定している。メール生成サーバ２００は、このアクセス管理サーバ１００が決定した、このシステムにアクセスしやすい将来の日時、曜日又は時間帯をアクセス管理サーバ１００から取得して、メッセージを生成する。
【００５０】
次に、アクセス管理サーバ１００は、取得したメッセージデータを顧客端末１０に送信し、顧客端末１０がメッセージデータを出力する（ステップＳ１０）。図７は、顧客端末１０に出力表示したメッセージデータ９１の表示例である。例えば、「いつも○○システムをご利用頂きまして、ありがとうございます。ただ今、混雑のため・・。お客様には優先的にログインいただけるよう、手配します」と表示され、アクセスしやすい時間帯があわせて表示される。
【００５１】
［アクセス制御処理（優先アクセス処理）］
次に、アクセス制御処理のうち、優先アクセス処理について図６を参照して説明する。本処理は、先の優先フラグ起動処理で優先フラグを起動したユーザに対して、システムにアクセス可能であることを通知する処理である。
【００５２】
最初に、アクセス管理サーバ１００のアクセス数判断モジュール１１０は、アクセス管理サーバ１００にアクセスしている顧客端末１０のセッション数が、所定数以下であるかの判断を行う（ステップＳ１２）。セッション数が所定数以下であるとは、アクセス管理サーバ１００の通信負荷の許容の度合いに応じて決定されるが、例えば、現在のセッション利用数が、利用可能なセッション数の１０％を下回った場合には、所定数以下であると判断できる。
【００５３】
顧客端末１０のセッション数が、所定数以下であると判断した場合（ステップＳ１２：「ＹＥＳ」）は、ステップＳ１３に処理を移す。顧客端末１０のセッション数が、所定数以下でないと判断した場合（ステップＳ１２：「ＮＯ」）は、本処理を終了する。
【００５４】
次に、アクセス管理サーバ１００のアクセス制御モジュール１１１は、優先アクセスさせるユーザを検索するために、ログ管理サーバ１５０に契約者ＩＤの検索要求を行う（ステップＳ１３）。これに応じて、ログ管理サーバ１５０は、契約者ＩＤの中で、優先フラグが起動している契約者ＩＤを検索する（ステップＳ１４）。
【００５５】
そして、ログ管理サーバ１５０は、契約者ＩＤを検索した結果、優先アクセス通知を行う契約者ＩＤを決定する（ステップＳ１５）。ここで、ログ管理サーバ１４０は、優先フラグを起動しているユーザが多数ある場合は、最もアクセス回数が多いユーザに対応する契約者ＩＤを、優先アクセス通知を行う契約者ＩＤと決定してもよい。ログ管理サーバ１５０は、決定した契約者ＩＤをアクセス管理サーバ１００に送信する。
【００５６】
次に、アクセス管理サーバ１００のアクセス制御モジュール１１１は、メール生成サーバ２００から優先アクセス通知の内容を取得する（ステップＳ１６）。メール生成サーバ２００には、優先アクセス通知の通知内容の雛形が予め記憶されている。そして、アクセス管理サーバ１００のアクセス制御モジュール１１１は、顧客端末ＩＤに対応する顧客端末１０に優先アクセス通知を送信する（ステップＳ１７）。
【００５７】
顧客端末ＩＤに対応する顧客端末１０は、優先アクセス通知を受信し、これを出力する（ステップＳ１８）。図８に、顧客端末１０に出力表示した優先アクセス通知９２の表示例を示す。例えば、「いつも○○システムをご利用頂きまして、ありがとうございます。先ほどは、混雑のためご迷惑をおかけしまして、申し訳ありませんでした。尚、現在は比較的、すいており、また、○○様には優先的にログインいただけますよう手配しておりますので、下記ＵＲＬをクリックして、アクセスしてください」と出力されて、アクセスを促すＵＲＬが表示される。ユーザはこれに応じて、優先的にシステムにアクセスすることが可能である。
【００５８】
［アクセス制御処理（自動アクセス処理）］
次に、顧客端末１０が自動的に、インターネットバンキングを提供するシステムにアクセスする処理について、図６に基づいて説明する。本処理は、図３の優先フラグ起動処理で、メッセージデータをアクセス管理サーバ１００から受信していることを前提として、顧客端末１０で実行される処理である。
【００５９】
最初に、顧客端末１０のアクセスモジュール２１は、受信したメッセージデータに記載されたアクセスしやすい時間帯を参照して、現在の時刻がアクセス可能時刻であるか否かを判断する（ステップＳ２０）。アクセスモジュール２１は、現在の時刻がアクセス可能時刻であると判断した場合には（ステップＳ２０：「ＹＥＳ」）、アクセス管理サーバ１００へのアクセスを開始する（ステップＳ２１）。一方、現在の時刻がアクセス可能時刻ではないと判断した場合には（ステップＳ２０：「ＮＯ」）、アクセス処理を開始せずに、アクセス可能時刻まで待つ。
【００６０】
なお、上記のように、アクセスするか否かの判断を、メッセージデータの時間帯にのみ基づかなくても、所定の時間に、アクセス管理サーバ１００に定期的にアクセスするように処理してもよい。
【００６１】
アクセス管理サーバ１００のアクセス数判断モジュール１１０は、この顧客端末１０からのアクセスを受付けて（ステップＳ２２）、現在のインターネットバンキングシステムに対するセッション数が所定数以上であるか否かを判断する（ステップＳ２３）。セッション数が所定数以上であると判断した場合（ステップＳ２３：「ＹＥＳ」）は、ステップＳ２４に処理を移す。セッション数が所定数以上ではないと判断した場合（ステップＳ２３：「ＮＯ」）は、ステップＳ２７に処理を移す。
【００６２】
アクセス管理サーバ１００のアクセス制御モジュール１１１は、セッション数が所定数以上であると判断した場合は、今回のアクセスを不許可として（ステップＳ２４）、将来のアクセスしやすい時間帯を決定する（ステップＳ２５）。そして、決定したアクセスしやすい時間帯を顧客端末１０に送信し、顧客端末１０は、先のメッセージデータに記載されたアクセスしやすい時間帯を、今回、受信したアクセスしやすい時間帯に変更する（ステップＳ２６）。
【００６３】
これにより、顧客端末１０は、再度、変更した時間帯にアクセスを試みるため、ステップＳ２０からの処理を実行する。この後の処理は、変更された時間帯でのアクセスを繰り返して、ステップＳ２０からステップＳ２６の処理を、アクセスが許可されるまでループして繰り返す。
【００６４】
一方、セッション数が所定数以上ではないと判断した場合（ステップＳ２３：「ＮＯ」）は、アクセスが許可されることで（ステップＳ２７）、顧客端末１０に、自動アクセス完了通知を出力し（ステップＳ２８）、ユーザへインターネットバンキングにアクセスが完了したことを通知する。
【００６５】
図８に、自動アクセス完了通知を行った場合の顧客端末１０に出力される画面イメージを示す。顧客端末１０には、「＜自動アクセス完了＞いつも○○システムをご利用頂きまして、ありがとうございます。現在、弊社インターネットバンキングに自動的に接続されました。」と表示されて、ユーザにアクセスが完了したことを通知する。そして、「バンキングを続ける」９４のボタンをおすことで、実際に、インターネットバンキングを開始する。
【００６６】
本実施例によれば、顧客であるユーザからのアクセスが集中した際に、お詫びのメッセージを送信するとともに、アクセスしやすい時刻に関するメール配信を行い、また、アクセスしやすい時間帯になったら、優先的にアクセスを促すことが可能となる。また、アクセスが出来なかったユーザの顧客端末１０が、自動的にシステムへアクセスすることで、ユーザが意識することなく、円滑にインターネットバンキングへのアクセスを行うことが可能となる。
【００６７】
なお、優先フラグ起動処理において、送信するメッセージデータに、インターネットバンキングサービスのサービス停止日時（メンテナンス日時）をお知らせするメッセージを含めてもよい。
【００６８】
上述した手段、機能、モジュールは、コンピュータ（ＣＰＵ、サーバ、装置、各種端末を含む）が、所定のプログラムを読み込んで、実行することによって実現される。プログラムは、例えば、フレキシブルディスク、ＣＤ（ＣＤ−ＲＯＭなど）、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭなど）等のコンピュータ読取可能な記録媒体に記録された形態で提供される。この場合、コンピュータはその記録媒体からプログラムを読み取って内部記憶装置または外部記憶装置に転送し記憶して実行する。また、そのプログラムを、例えば、磁気ディスク、光ディスク、光磁気ディスク等の記憶装置（記録媒体）に予め記録しておき、その記憶装置から通信回線を介してコンピュータに提供するようにしてもよい。
【００６９】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されないことは言うまでもない。上記実施形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。またその様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【符号の説明】
【００７０】
１      アクセス管理システム
１０    顧客端末
２０    カーステーション
１００  アクセス管理サーバ
１５０  ログ管理サーバ
２００  メール生成サーバ
【図１】
2013206179.tif 000003
【図２】
2013206179.tif 000004
【図３】
2013206179.tif 000005
【図４】
2013206179.tif 000006
【図５】
2013206179.tif 000007
【図６】
2013206179.tif 000008
【図７】
2013206179.tif 000009
【図８】
2013206179.tif 000010
【図９】
2013206179.tif 000011