(57)【要約】【課題】柔軟なログイン制限を行うことができるウェブログイン制限システムを提供する。【解決手段】複数の利用者端末と、該複数の利用者端末とネットワークを介して接続されたサーバとから構成されるウェブログイン制限システムであって、前記複数の利用者端末の何れかから前記ネットワークを介してログインを受け付けるログイン受付手段と、現在のログイン数を算出するログイン数算出手段と、前記ログイン数算出手段により算出されたログイン数と、予め記憶手段に記憶されているログイン上限値に基づいて、前記利用者端末からのログインの受付の可否を判定する受付可否判定手段と、を備えたことを特徴とする。【選択図】図２
2008242676.tif 000002
【特許請求の範囲】
【請求項１】
複数の利用者端末と、該複数の利用者端末とネットワークを介して接続されたサーバとから構成されるウェブログイン制限システムであって、
前記複数の利用者端末の何れかから前記ネットワークを介してログインを受け付けるログイン受付手段と、
現在のログイン数を算出するログイン数算出手段と、
前記ログイン数算出手段により算出されたログイン数と、予め記憶手段に記憶されているログイン上限値に基づいて、前記利用者端末からのログインの受付の可否を判定する受付可否判定手段と、
を備えたことを特徴とするウェブログイン制限システム。
【請求項２】
前記記憶手段に記憶されている前記ログイン上限値は、曜日毎に管理されていることを特徴とする請求項１に記載のウェブログイン制限システム。
【請求項３】
前記記憶手段に記憶されている前記ログイン上限値は、期間毎に管理されていることを特徴とする請求項１に記載のウェブログイン制限システム。
【請求項４】
前記記憶手段に記憶されている前記ログイン上限値は、季節毎に管理されていることを特徴とする請求項１に記載のウェブログイン制限システム。
【請求項５】
前記受付可否判定手段は、前記ログイン数算出手段により算出されたログイン数が前記ログイン上限値以下の場合、所定の警告メッセージを前記ネットワークを介して前記端末に送信することを特徴とする請求項１乃至４に記載のウェブログイン制限システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は教育機関などのポータルシステムにおいて使用するウェブログイン制限システムに関する。
【背景技術】
【０００２】
大学等の教育機関に適用する場合、履修登録時期や入試時期、就職時期など、学年暦による繁忙時期と閑散期が顕著であり、昨今の全入学時代において、収入源が限られている中、ピーク利用に合わせたインフラ設備への投資がままならない状況にある。また、大学にて取り扱う情報（個人情報、成績情報等）の性格上、外部機関のインフラ設備を使用することができず、そのため限られた予算の中、インフラ設備を大学として維持・管理しているのが実態である。
【０００３】
学生のシステム利用形態も、昨今のネットワークのブロードバンド化に伴い、変化しており、学内からの利用はもちろんのこと、学外、自宅、携帯電話等から自分の生活リズムに合わせてアクセスして利用する形態となってきている。また、企業と異なり、クライアントPCの設定や使用OSを学生(家庭)に強制することができない背景がある。
【０００４】
この限られたピーク利用時期を前述の利用形態の変化や環境も踏まえ、利用者のフラストレーションを極力ためずに、システム設備のポテンシャルを効率的に発揮して、柔軟に安定運用させたいというニーズがある。
【０００５】
この問題を解決するシステムとして、ウェブアクセスをセッションIDで識別し同時セッション数によってアクセス制限を行うシステムが提案されている。例えば特許文献１に示すようなシステムでは、Coockieを用いてセッションIDを取得し、セッション数を管理することができる。
【０００６】
【特許文献１】特開２００４−１２７１７２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来のログイン数制限システムにおいて利用されるCoockieは利用しているブラウザ上でファイルとしてクライアント側に保存される。Coockieには値や有効ドメインなどが格納され、改ざんやプライバシーの問題が発生する。
【０００８】
また、従来のログイン数制限方式はリクエスト数によるものであるため、ブラウザの閉じるボタンでセッションを終了した利用者がいた場合に、正確なログイン数を維持することが困難であった。
【０００９】
本発明の目的は、ユーザ認証を伴うウェブシステムにおける、認証が許可されたログイン数とその情報を保持し、一定数以上のログイン依頼があった場合、認証が成功してもログインさせないようにして、既ログイン者への継続的なウェブサービスの提供環境を実現することにある。ウェブシステムは当然、曜日や時間帯に応じて利用者数が変化するシステムであるため、当該パターン情報を保持し、柔軟な運用を可能とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明のウェブログイン制限システムは利用者端末からアクセスされるサーバを備える。上記サーバには、ウェブサービスを備えたソフトウェア、認証機能を備えたプログラム、ログイン情報、ログイン制限を格納するデータベース、ログイン数を集計するプログラム、定期的にログイン情報をリセットするプログラムを備える。ここで集計処理はログイン数をカウントするもので良い。
【００１１】
本発明のウェブログイン制限システムの通常の処理方法では、利用者は利用者の使用する端末からサーバのログイン画面へアクセスする。サーバではログイン画面へアクセスされる度にログイン制限を格納するデータベースを参照する。この時、ログイン制限はファイルなどの記憶媒体でもよい。ログイン制限には上限数の有効フラグ、曜日、時間帯、ログイン上限数、クリア経過時間、制限除外IPアドレス、利用可能エリアを格納する。またそれに加えて、メンテナンスフラグを格納してもよい。曜日項目には、日付をもとにした期間、季節を格納してもよい。サーバは上記制限情報と集計処理結果を照らし合わせ、制限条件をクリアしたアクセスのログイン情報を記憶媒体に格納する。アクセス元（インターネット、携帯、イントラ）の判断にはリモートIPアドレス、referer、FQDNを利用する。ログイン情報には、利用者本人を識別するIDや指名、IPアドレス、HTTPヘッダ情報、ログイン日時、最終リクエスト日時を格納する。ログイン後は利用者からウェブシステムにアクセスがある度に最終リクエスト日時を更新する。
また一方上記サーバは定期的にログイン情報リセットプログラムを通して各ユーザの利用状況を確認し、最終リクエスト時間からクリア経過時間を経過しているユーザの情報をログイン情報から削除する。
【００１２】
また、利用者がシステムにアクセスする度にログイン情報データベースを参照し、利用者の情報がない場合はログアウトと扱う。メンテナンスフラグがあれば強制ログアウトと扱ってもよい。
【００１３】
サービスを再起動した場合には、ログイン情報データベースの全レコードをクリアする。
【発明の効果】
【００１４】
以上本発明のウェブシステムログイン制限システムにより、ウェブサーバに対するリクエスト数ではなくログイン数で利用制限を課し、負荷を操作することができる。さらに制限除外IPアドレスを設け、緊急性のあるログインにも対応できる。また、メンテナンスフラグを用いることで、現在ログイン中のユーザ処理は継続しつつ、新規ログインを抑止することができる。
【発明を実施するための最良の形態】
【００１５】
図１は本発明のウェブログイン制限システムに係る構成例である。利用者は一時的に情報を記憶するメモリ101、ネットワーク上の他の装置との情報の送受信を行う通信手段102、演算処理装置であるCPU103、情報を保持する主記憶装置104、キーボードなど入力インターフェース105、ディスプレイなど出力インターフェース106、ウェブページを閲覧するウェブブラウズソフトウェア107を備えた機器100を利用する。利用者はウェブブラウズソフトウェア107を使用し通信手段102からイントラ、インターネットを通じてサーバ200へアクセスする。イントラに設置したサーバ200は、一時的に情報を記憶するメモリ201、ネットワークＮ上の他の装置との情報の送受信を行う通信手段202、演算処理装置であるCPU203、情報を保持する主記憶装置204、キーボードなど入力インターフェース205、ディスプレイなどの出力インターフェース206、ROMなど読取専用記憶装置から情報を取得する記憶媒体読込装置207、プログラムと連携するウェブサービスソフトウエア208、ログイン制限DB300、ログイン情報DB400を備える。
【００１６】
図９は本発明のウェブログイン制限システムで使用するログイン制限データベース300とログイン情報データベース400の例である。
【００１７】
ログイン制限データベース300の各項目について説明する。アクティブフラグ301は無効、有効フラグを格納する。無効フラグが格納されている場合はログイン制限を行わない。曜日302には曜日、日付、期間、季節を格納する。システムにアクセスした際の日付とのマッチングを行う。時間帯（From）303、時間帯（To）304にはログイン制限を行う時間帯を格納する。システムにアクセスした際の時間帯とのマッチングを行う。ログイン上限数305にはシステムに同時接続可能な上限数を格納する。ログイン数が上限数に達していた場合にはログイン制限を行う。クリア経過時間306には利用者がシステムに最後にアクセスしてからクリアされるまでの時間を格納する。利用可能エリア307にはシステムに接続可能なエリアを格納する。制限除外IP308にはIPアドレスを格納し、ログイン制限を受けないIPアドレスを格納し、緊急時のアクセス要望に対応する。メンテフラグ309は無効、有効フラグを格納する。アクセス時に有効であった場合はログインを制限する。システム利用者がいる場合に、メンテフラグを切り替えることで、以降のログインを制限できる。
【００１８】
ログイン情報データベース400の各項目について説明する。ユーザID401にはログインが成功した利用者のシステム利用IDを格納する。IP402には利用者端末のIPアドレスを格納する。HTTPヘッダ403には利用者端末のブラウザから送信されたHTTPヘッダ情報を格納する。ログイン日時404にはログイン成功日時を格納する。最終リクエスト日時405にはユーザが最後にシステムにアクセスした日時を格納する。
【００１９】
次に図２により利用者がサーバにアクセスした際の認証を含む作業全体の流れを説明する。利用者は利用者端末100を用いてサーバ200にTOPページへのリクエストを送信する（ステップS201）。サーバ200は利用者端末100のIPアドレスを取得する（ステップS202）。サーバ200はログイン制限データベース300を読み込み、システム日付からログイン制限データベース300の曜日302に該当する制限情報を取得する（ステップS203）。該当する制限情報のメンテナンスフラグ309が有効であるか確認する（ステップS204）。
【００２０】
例えば利用者端末100のIPアドレスが192.168.1.100であり、月曜日の10:00:00にアクセスした場合は、サーバはリクエストを受信し（ステップS201）、利用者端末のIPアドレスを取得し（ステップS202）、システム日付からログイン制限データベース300の項番1の制限情報を取得する（ステップS203）。
【００２１】
メンテナンスフラグ309が有効であった場合にはエラーメッセージを決定する（ステップS214）。エラー画面の表示を行い（ステップS215）、処理を終了する（ステップS216）。
【００２２】
例えばアクセス日付が春の期間であった場合はログイン制限データベースの項番3のレコードが取得され、メンテナンスフラグ309は有効であるためエラーメッセージを決定する（ステップS214）。エラー画面の表示を行い（ステップS215）、処理を終了する（ステップS216）。
【００２３】
メンテナンスフラグが309無効であった場合にはアクティブフラグ301が有効であるかを確認する（ステップS205）。
【００２４】
アクティブフラグ301が無効であった場合は認証画面を表示する（ステップS211）。
【００２５】
アクティブフラグ301が有効であった場合（ステップS205）は制限除外IPアドレス308を確認する（ステップS206）。
【００２６】
制限解除IPアドレス308に含まれている場合は認証画面を表示する（ステップS211）。
【００２７】
制限解除IPアドレス308に含まれていない場合、システム日付の時間が時間帯（From）303、時間帯（To）304に含まれるアクセスか確認する（ステップS207）。
【００２８】
システム日付の時間が時間帯（From）303、時間帯（To）304に含まれるアクセスでない場合は認証画面を表示する（ステップS211）。
【００２９】
システム日付の時間が時間帯（From）303、時間帯（To）304に含まれるアクセスであった場合は利用可能エリア307からのアクセスか確認する（ステップS208）。
【００３０】
利用可能エリア307以外からのアクセスであった場合、エラーメッセージを決定する（ステップS214）。エラー画面の表示を行い（ステップS215）、処理を終了する（ステップS216）。
【００３１】
利用可能エリア307に含まれるアクセスであった場合は、ログイン情報データベース400からレコードの集計を行い、ログイン数を取得する（ステップS209）。
【００３２】
ログイン数がログイン上限数305に達していた場合、エラーメッセージを決定する（ステップS214）。エラー画面の表示を行い（ステップS215）、処理を終了する（ステップS216）。
【００３３】
ログイン数がログイン上限数305に達していない場合は認証画面を表示する（ステップS211）。認証を行い（ステップS212）、失敗した場合は処理を終了する（ステップS216）。認証に成功した場合は、ログイン情報データベース400にユーザID401、IP402、HTTPヘッダ403、ログイン日時404、最終リクエスト日時405を書込み（ステップS213）、処理を終了する（ステップS216）。
【００３４】
図３にサーバで定期的に実行するログイン情報リセット処理の流れを説明する。一定の期間毎にログイン情報リセットプログラムを実行する（ステップS301）。ログイン制限データベース300を読み込み（ステップS302）、サーバのシステム日付から曜日302、時間帯（From）303、時間帯（To）304を検索し、該当する制限情報のクリア経過時間306を取得する（ステップS303）。ログイン情報データベース400のレコードのうち、サーバのシステム日付と最新リクエスト日時405の差がクリア経過時間306を超過しているレコードを削除し（ステップS304）、処理を終了する（ステップS305）。
【００３５】
例えばシステム日付が2007/03/02 15:50:40であった場合、ログイン制限データベースの項番2の曜日302、時間帯（From）303、時間帯（To）304に条件があてはまり、クリア経過時間306、50minを取得する（ステップS303）。ログイン情報データベース400のレコードのうち、クリア経過時間306を超過している項番1のレコードを削除し、（ステップS304）、処理を終了する（ステップS305）。
【００３６】
図４に利用者がシステムにアクセスする毎に実行するアクセス情報登録処理の流れを説明する。利用者がシステム内のウェブページにアクセスする毎にアクセス情報登録プログラムを実行する（ステップS401）。ログイン情報データベース400を読込み（ステップS402）、ユーザID401、利用者の端末のIP402が存在するか検索する（ステップS403）。レコードが存在する場合は、ログイン情報データベース400の最終リクエスト日時405を現在の日時に更新する（ステップS404）。レコードが存在しない場合はエラーメッセージを表示し（ステップS405）、TOP画面を表示し（ステップS406）、処理を終了する（ステップS407）。
【図面の簡単な説明】
【００３７】
【図１】本発明のウェブログイン制限システムに係る構成図である。
【図２】本発明のサーバアクセス時における処理フローである。
【図３】本発明におけるログイン情報データベースリセットの処理フローである。
【図４】本発明におけるアクセス情報登録の処理フローである。
【図５】本発明における認証画面の例である。
【図６】本発明における利用可能エリア外からアクセスした場合のエラー画面の例である。
【図７】本発明におけるログイン上限に達した場合のエラー画面の例である。
【図８】本発明におけるクリア時間経過後にアクセスした場合のエラー画面の例である。
【図９】本発明におけるサーバが持つDBのテーブル構成例である。
【図１０】本発明におけるメンテナンス中の画面例である。
【符号の説明】
【００３８】
１００・・・利用者端末、２００・・・サーバ。
【図１】
2008242676.tif 000003
【図２】
2008242676.tif 000004
【図３】
2008242676.tif 000005
【図４】
2008242676.tif 000006
【図５】
2008242676.tif 000007
【図６】
2008242676.tif 000008
【図７】
2008242676.tif 000009
【図８】
2008242676.tif 000010
【図９】
2008242676.tif 000011
【図１０】
2008242676.tif 000012