JP2012128722A

JP2012128722A - セッション管理システム及びその方法

Info

Publication number: JP2012128722A
Application number: JP2010280494A
Authority: JP
Inventors: Takashi Yoshida; 孝志吉田
Original assignee: Hitachi Systems Ltd
Current assignee: Hitachi Systems Ltd
Priority date: 2010-12-16
Filing date: 2010-12-16
Publication date: 2012-07-05
Anticipated expiration: 2030-12-16
Also published as: JP5662129B2

Abstract

【課題】クライアント／サーバ・システムの運用状況の変化に応じた優先度を設定する。
【解決手段】セッション管理システムは、ユーザがクライアント端末を用いてサーバにアクセスする時間帯における第１のアクセス回数に基づいて設定したユーザの時間帯対応の優先度を格納する優先度テープル、および、ユーザのサーバへの接続状況を格納する接続状況テーブルを有する。さらに、ユーザからのクライアント端末を用いたサーバのアプリケーションへのセッション確立要求に応答して、少なくともセッション確立要求に含まれるユーザのユーザID、セッション確立要求に含まれるクライアント端末のIPアドレス、優先度テーブルに格納される、現在時刻を含む時間帯におけるユーザの優先度、および、サーバへの接続時刻としての現在時刻を接続状況テーブルに格納し、アプリケーションへセッション確立するユーザアクセス受付処理部を有する。
【選択図】図１

Description

本発明は、業務アプリケーションにアクセスするユーザのセッション管理に関するものである。

特許文献１に、ユーザの優先度によるセッション管理システムが次のように開示されている。ＴＣＰ／ＩＰ通信プロトコルを利用したクライアント／サーバ・システムにおいて、各クライアントのＩＰアドレスに対応して、サーバへ接続する優先度を設定した優先度テーブルをサーバに設け、サーバがクライアントから接続要求を受けた場合に、優先度テーブルを参照して、優先度の高いクライアントから接続要求を受け付ける。

サーバに接続可能なクライアント数の全部に、それぞれクライアントがセッションを維持している状態において、未接続のクライアントがサーバに接続要求した際には、優先度テーブルを参照して、接続要求したクライアントのＩＰアドレスの優先度と、既に接続しているクライアントの中で最低の優先度とを比較し、接続要求したクライアントの優先度が高い場合に、最低の優先度のクライアントとサーバとのセッションを切断し、接続要求したクライアントの接続要求を受け付ける。

特開2003-16031号公報

クライアント／サーバ・システムにより実現する業務アプリケーションは、一般に多様なサービスをユーザに対して提供する。ユーザから見れば、多様な処理を実行できる。多様な処理は、複数ユーザにより、複数のクライアント端末が用いられて実行される。同じユーザが複数の担当業務に対応した複数の処理を実行することもあるし、複数のユーザが同じ業務処理を実行することもある。このような業務アプリケーションには、日次、月次などの周期性を持った処理が実行されることが多く、その周期に対応してクライアント端末からのアクセス回数が増減する傾向がある。アクセス回数の増加に伴って、高い優先度の設定が要請される。また、業務アプリケーションが提供するサービス内容が徐々に変化することもあるし、ユーザの担当業務も変化する。

特許文献１に記載のＩＰアドレス単位の優先度設定では、このようなクライアント／サーバ・システムの運用状況の変化に対応できない。運用状況に変化がなければ、クライアント端末を特定するIPアドレスに対応付けて優先度を設定してもよいが、ユーザの担当業務や時間経過に伴う変化に応じて優先度の設定内容を変化させる必要がある。

開示されるセッション管理システムは、次のような構成である。ユーザがクライアント端末を用いてサーバにアクセスする時間帯における第１のアクセス回数に基づいて設定したユーザの時間帯対応の優先度を格納する優先度テープル、および、ユーザのサーバへの接続状況を格納する接続状況テーブルを有する。さらに、ユーザからのクライアント端末を用いたサーバのアプリケーションへのセッション確立要求に応答して、少なくともセッション確立要求に含まれるユーザのユーザID、セッション確立要求に含まれるクライアント端末のIPアドレス、優先度テーブルに格納された、現在時刻を含む時間帯におけるユーザの優先度、および、サーバへの接続時刻としての現在時刻を接続状況テーブルに格納し、アプリケーションへのセッション確立するユーザアクセス受付処理部を有する。

開示されるセッション管理システムの望ましい他の態様は、ユーザアクセス受付処理部は、アプリケーションへのセッション確立後、ユーザによるクライアント端末を用いたアプリケーションへのアクセスに応答して、アプリケーションへの第２のアクセス回数と最新アクセス日時を接続状況として接続状況テーブルに格納する。

開示されるセッション管理システムの望ましいさらに他の態様は、ユーザアクセス受付処理部は、ユーザからのクライアント端末を用いたサーバのアプリケーションへのセッション確立要求に応答して、サーバへの接続可能なクライアント端末の台数に接続中の他のクライアント端末の台数が達しているとき、優先度と接続中の他のクライアント端末を用いた他のユーザの優先度との関係、及び、接続中の他のクライアント端末を用いた他のユーザが所定時間を超えてサーバのアプリケーションへアクセスしていない不使用者であるか否かの少なくとも一方に基づいて他のユーザのセッション切断の可否を決定する。

開示されるセッション管理システムの望ましいさらに他の態様は、接続状況テーブルに格納される接続状況は、アプリケーションへのセッション切断要求に応答して、接続履歴データベースに格納される。

開示されるセッション管理システムの望ましいさらに他の態様は、セッション管理システムは、接続履歴データベースに格納された接続状況を参照して、ユーザがクライアント端末を用いてサーバのアプリケーションにアクセスした時間帯における第２のアクセス回数に基づいて、ユーザの優先度を更新する優先度設定処理部をさらに有する。

開示されるセッション管理システムの望ましいさらに他の態様は、優先度テーブルは、ユーザのユーザIDとクライアント端末のIPアドレスとに対応付けて設定された特権としての優先度をユーザの優先度として含む。

本発明によれば、クライアント／サーバ・システムの運用状況の変化に応じた優先度を設定できる。

クライアント／サーバ・システムの構成例である。特権定義テーブルの構成例である。接続履歴データベースの構成例である。優先度テーブルの構成例である。接続状況テーブルの構成例である。優先度設定処理部の処理フローチャートである。ユーザアクセス受付処理部の処理フローチャートである。

図１に、サーバ１にセッション管理システム１０を含むクライアント／サーバ・システムの構成例を示す。クライアント／サーバ・システムは、サーバ１に、ユーザ３が使用するクライアント端末２がネットワーク４を介して接続する構成である。ユーザ３は、クライアント端末２からサーバ１にアクセスして、所望のアプリケーション５を実行する。

サーバ１に含まれるセッション管理システム１０は、優先度設定処理部１１及びユーザアクセス受付処理部１２を有する。また、セッション管理システム１０は、優先度設定処理部１１及びユーザアクセス受付処理部１２の実行に用いる、特権定義テーブル１３、接続履歴データベース１４、優先度テーブル１５、および、接続状況テーブル１６を有する。なお、テーブルとデータベースとの呼び分けには特に意味は無い。

図２に、特権定義テーブル１３の構成例を示す。特権定義テーブル１３は、組織の職位や職種などにより決定される特定のユーザに付与される、サーバ１への接続の特権（優先的に接続する権利）を示す。特権定義テーブル１３は、特権を持つユーザ３によるサーバ１へ接続に関する情報を有し、特権を持つユーザ３のユーザID１３０、ユーザ３がサーバ１へ接続（より具体的には、アプリケーション５に論理的にセッションを確立）するときの優先度、サーバ１へ接続する曜日や時間帯などの接続時刻１３２、サーバ１へ接続するために用いるクライアント端末２を特定するIPアドレス１３３を含む。なお、本実施形態では、優先度１を最高の優先度とし、２、３、・・・の順に優先度が低下するものとする。

たとえば、図２には、ユーザIDが004のユーザ３が、IPアドレス１３３としてIPAD４のクライアント端末２を用いてサーバ１へ接続するときと、月曜日の午後にサーバ１へ接続するときに、優先度１で接続する特権を有していることを示す。逆に、IPAD４以外のIPアドレスのクライアント端末２を用いた、月曜日の午後以外の時間帯におけるサーバ１への接続要求に対しては、ユーザIDが004のユーザ３に特権としての優先度１が付与されないことを示す。接続時間帯１３２は、クライアント端末２からサーバ１が接続要求される時刻を含む時間帯を示す。以降に説明する他のテーブル等の説明においても、接続時間帯の意味は同様である。

なお、時間帯として、分かり易くするために、午前、午後、夜間などを用いて説明するが、実際には6：00〜12：00を午前とするなどにより所定の時間帯を特定する。したがって、時間帯の設定は、３０分や１時間毎であってもよく、また日中は３０分毎、夜間は２時間毎のように、サーバ１で実行されるアプリケーション５の特性などに応じて、時間帯の単位時間を変えても良い。また、月初め、月末なども同様に、毎月１日〜５日の間を月初め、２５日〜月の末日を月末とするなどにより期間（広い意味での時間帯）を特定する。これらの時間帯の特定は、サーバ１が持っているカレンダー及び時計を基準とする。

図３に、接続履歴データベース１４の構成例を示す。接続履歴データベース１４は、ユーザ３がクライアント端末２を用いてアプリケーション５を利用するためのセッション確立からセッション切断までのセッション単位に、ユーザ３からサーバ１への接続履歴を格納する。セッション単位の接続履歴は、ユーザ３を示すユーザID１４０、サーバ１へ接続したときの優先度１４１及び接続開始日時（セッション確立日時）を示す接続日時１４２、セッションを切断した日時を示す切断日時１４３、接続中のアプリケーション５へのアクセス回数１４４、並びに、ユーザ３が用いたクライアント端末２を特定するIPアドレス１４５を含む。

たとえば、図３には、ユーザIDが001のユーザ３がIPアドレス１４５としてIPAD1のクライアント端末２を用いて、優先度１４１が２で、2010/10/01.13：00（接続日時１４２）〜2010/10/01.13：45（切断日時１４３）の45分間の接続時間(セッションを確立している時間)に、100回のアクセス回数１４４であったことを一例として示している。

セッション単位の接続履歴は、各セッションの終了時、すなわちセッション切断の処理に応じて、接続履歴データベース１４へ格納される。

図４に、優先度テーブル１５の構成例を示す。優先度テーブル１５は、ユーザ３がサーバ１へ接続要求（セッションの確立要求）してきたときに、セッション管理システム１０のユーザアクセス受付処理部１２が、ユーザ３に付与されている優先度を参照するために用いられる。優先度テーブル１５は、ユーザ３を示すユーザID１５０、サーバ１へ接続するときの優先度１５１、優先度１５１の値を付与する条件としての接続時間帯１５２及びIPアドレス１５３、および特権が付与されているか否かを示す特権１５４を含む。IPアドレス１５３は、優先度１５１の値を付与する条件としての、ユーザ３が用いるクライアント端末２を特定するIPアドレスである。

たとえば、図４には、ユーザIDが001のユーザ３に関して、３種類の優先度が設定されている。第１は、ユーザIDが001のユーザ３が月初めの日の午後にIPアドレス１５３がIPAD1のクライアント端末２を用いて、サーバ１に接続要求する場合は優先度１４１として１が付与される。第２は、月初めの日の午後以外の時間帯にIPアドレス１５３がIPAD1のクライアント端末２を用いて、サーバ１に接続要求する場合は優先度１４１として３が付与される。第３は、IPアドレス１５３がIPAD1以外のクライアント端末２を用いて、サーバ１に接続要求する場合は優先度１４１として４が付与される。さらに、ユーザIDが004のユーザ３に関しては、特権定義テーブル１３に示した内容を格納している。

図５に、接続状況テーブル１６の構成例を示す。接続状況テーブル１６は、少なくともサーバ１へ接続（セッション確立）しているユーザ３のアクセス状況を示す。接続状況テーブル１６は、ユーザ３を示すユーザID１６０、ユーザ３が用いたクライアント端末２を特定するIPアドレス１６１、現在サーバ１へ接続（セッション確立）中か否かを示す接続状況１６２、接続したときの優先度（１回のセッションの中では優先度を変更しないので、接続中のセッションの優先度）１６３、サーバ１への接続開始日時を示す接続日時１６４、接続中のアプリケーション５へのアクセス回数１６５、現在の接続(セッション)の中でアプリケーション５へ最も最近アクセスした日時を示す最新アクセス日時１６６、及び、セッションを切断した日時を示す切断日時１６７を含む。

ユーザ３の人数が少ない小規模システムでは、図５に示すように全てのユーザ３（ｎ人）対応にレコードを設けた接続状況テーブル１６としても良いが、ユーザ３の人数が多い大規模システムでは、接続していないユーザ３に関するレコードを、セッション切断時の処理の一環として削除しておくことにより、接続状況テーブル１６を小容量化できる。このような場合は、接続状況１６２および切断日時１６７は不要になる。

接続履歴データベース１４のセッション単位の接続履歴は、各セッションの終了時、すなわちセッション切断の処理に応じて、接続履歴データベース１４へ格納されると前述した。セッション単位の接続履歴は、接続状況テーブル１６の内容が元になる。全てのユーザ３対応にレコードを設けた接続状況テーブル１６の場合には、ユーザID１６０、IPアドレス１６１、優先度１６３、接続日時１６４、アクセス回数１６５、及び、切断日時１６７の各々を接続履歴データベース１４の対応する領域に格納すれば良い。一方、接続していない（未接続）ユーザ３に関するレコードを設けない接続状況テーブル１６の場合には、切断日時１６７の代わりにセッション切断時の日時として、サーバ１のカレンダー及び時計から読み取った日時（現在時刻）を用いれば良い。

たとえば、図５には、ユーザIDが001のユーザ３に関して、IPAD1のクライアント端末２を用いて、優先度１でサーバ１へ接続中であり、その接続日時１６４は2010/11/01の13:30であり、接続開始時刻から現在までのアプリケーション５へのアクセス回数１６５は100回であり、最新アクセス日時１６６は2010/11/01の13:59であることを示す。

図6に、優先度設定処理部１１の処理フローチャートを示す。優先度設定処理部１１は、毎年所定の時期などのように定期的に実行されても良いし、アプリケーション５が実行する業務内容の変化やユーザ３の担当業務の変化に応じて、接続履歴データベース１４への接続履歴の蓄積が進んだ段階で、適宜実行されても良い。

優先度設定処理部１１は、接続履歴データベース１４をユーザID１４０に基づいてソートする(ステップ６００)。接続履歴データベース１４は接続履歴をセッション切断時刻順にシーケンシャルに格納するので、同じユーザ３に関しては、（同じユーザ３が同時に複数のセッションを確立することは無いので、）接続日時１４２の順に格納される。接続履歴が接続履歴データベース１４にランダムに格納される場合は、ユーザID１４０に基づいたソートの後に、各ユーザID１４０ごとに接続日時１４２でソートする。以下の処理は、ソートした各ユーザID１４０ごとに、接続日時１４２の順に各接続履歴について繰り返す。

接続履歴データベース１４のユーザID１４０が特権定義テーブル１３のユーザID１３０にあるかを判定する(ステップ６０２)。あるならば、特権定義テーブル１３のユーザID１３０、優先度１３１、接続時間帯１３２およびIPアドレス１３３の各々を、優先度テーブル１５の対応する領域に格納し、優先度テーブル１５の特権１５４に「有り」を格納する(ステップ６０３)。なお、同じユーザID１３０に関して複数のレコードが特権定義テーブル１３に定義されている場合は、それら複数の定義内容を優先度テーブル１５に格納する。

ユーザID１４０に特権が定義されていない場合、および、特権を優先度テーブル１５に格納した場合は後述するステップ６８５を経て、接続履歴データベース１４の対象（接続履歴データベース１４のレコードを順次処理対象とするので、対象とは現在の処理対象）の接続履歴のアクセス回数１４４がＭ１回以上かを判定する(ステップ６０５)。アクセス回数１４４がＭ１回以上であるならば、その接続日時１４２を含む時間帯が優先度テーブル１５の接続時刻１５２に格納されているかを判定する(ステップ６１０)。接続時刻１５２に格納されていなければ、優先度１、接続日時１４２を含む時間帯、IPアドレス１４５を、ユーザID１５０に対応させて優先度テーブル１５の優先度１５１、接続日時１５２を含む時間帯、IPアドレス１５３に格納する(ステップ６１５)。

ステップ６１０の判定の結果、接続時刻１５２に格納されていれば、その接続時刻１５２に対応する優先度テーブル１５のIPアドレス１５３が、接続履歴データベース１４の対象のIPアドレス１４５と同じかを判定する(ステップ６２０)。同じであるならば、すでに優先度テーブル１５に登録されているので、ステップ６８５へ分岐する。IPアドレス１５３とIPアドレス１４５が異なれば、優先度テーブル１５のIPアドレス１５３を「不定」にする。IPアドレス１５３が「不定」とは、同じユーザID１５０が、異なる日の、接続時刻１５２を含む同じ時間帯に異なるクライアント端末２を用いてサーバ１に接続した接続履歴があったことを意味している。すなわち、同じユーザ３が、アクセス回数がＭ１回を超えるサーバ１への接続のために、日によって複数のクライアント端末２を選択的に使用していたことを意味している。一度、IPアドレス１５３に「不定」が格納され、さらに同じ時間帯の接続履歴があると、ステップ６２０はIPアドレス１４５を「不定」と比較することになり、IPアドレス１５３に「不定」が上書きされることになる。

ステップ６１０〜ステップ６２５を詳細に説明する。接続履歴データベース１４の接続日時１４２が、どのような時間帯に属するかは次のように判定する。アプリケーション５により実行される業務の特性から、日次処理（毎日実行する処理）、週次処理、月次処理、年次処理、場合によっては四半期毎の処理が予め想定される。また月次処理も上旬、中旬、下旬、月初め、月末などが想定される。また時間帯の最小単位は、前述したように、短時間単位に設定しても良いが、午前、午後などとする。そこで、優先度テーブル１５への新たな優先度の設定時には、接続日時１４２を含む時間帯を接続日時１５２に格納する。接続履歴データベース１４の他の接続履歴のアクセス回数１４４に基づいてステップ６１０を実行する場合、既に優先度テーブル１５の接続日時１５２に格納されている時間帯の最小単位から徐々に広い時間帯に合致するかを判定する。たとえば、午前が一致したならば、前日かを判定し、一致しているならば、たとえば、月末かを判定する。この例の場合、月末まで一致すれば、月末の午前とし、月末は不一致ならば、毎日午前とする。このように決定し、決定した時間帯を優先度テーブル１５の接続日時１５２に格納する。以上の処理を含めて、ステップ６１０〜ステップ６１５で実行する。

ステップ６２５で、複数のクライアント端末２が選択的に使用される場合、IPアドレス１５３に「不定」を格納するように説明したが、複数のIPアドレス１５３欄を設けて複数のIPアドレスを格納しても良い。実際の運用では、使用されるクライアント端末２をすべて特定した、厳密な優先度が要求されることは少ない。時間帯をたとえば、１０分や３０分のような短時間に設定した、厳密な優先度が要求されることも少ない。優先度は、接続履歴が反映され、サーバ１に同時にセッションを確立しているクライアント端末２の数が、サーバ１に接続可能な台数に達している場合の判断の基準として用いることができれば良い。

ステップ６３０〜ステップ６５０、ステップ６５５、ステップ６６０〜ステップ６８０は、アクセス回数１４４の比較対象の回数を変えたステップ６０５〜ステップ６２５の繰返しであるので、個々のステップの説明を省略する。

繰返しのステップの中の比較対象の回数Ｍ１、Ｍ２、・・・、Ｍｋは、Ｍ１＞Ｍ２＞・・・＞Ｍｋの関係を持たせる。すなわち、クライアント端末２からサーバ１への１回の接続時間あたりのアクセス回数が多い接続履歴に対応して、高い優先度を付与する。また比較対象の回数の段階をｋとすることにより、優先度として値が付与されない最も低い優先度の場合を含めて、ｋ＋１段階の優先度が付与される。たとえば、ｋ＝２ならば、優先度は１、２、値なし（最も低い優先度）の３段階になる。

同じユーザＩＤ１４０の他の接続時刻１４２の接続履歴の有無を判定し、あるならば、その接続履歴に関して、ステップ６０５から処理を繰り返す(ステップ６８５)。ないならば、他のユーザＩＤ１４０の接続履歴の有無を判定し、あるならば、そのユーザＩＤ１４０の接続履歴に関して、ステップ６０２から処理を繰り返す(ステップ６９０)。ないならば、優先度設定処理部１１の処理を終了する。

優先度設定処理部１１の処理により、図４に示すように、同じユーザに、日、週、月などの周期性を持った接続時刻１５２に対応した複数の優先度（同じ段階(レベル)の優先度になる場合もある）を付与することができる。複数の優先度を付与できることにより、同じユーザ３が複数の業務を担当し、時間帯により実行する担当業務が異なるような場合に、その担当業務対応に優先度が付与されることと等価になる。また、偶然に一回の接続履歴に多くのアクセス回数（たとえば、Ｍ１を超えるアクセス回数）が格納されていた場合、前述したようにその偶然はたとえば年に１回のある時間帯の接続であると判定され、仮に高い優先度が付与されたとしても、翌年の同じ時間帯に接続が無ければ、付与された優先度による接続が無く、実質的にクライアント端末２からサーバ１への接続管理(セッション管理)に影響を与えることは無い。

月日の経過と共に、サーバ１により実行されるアプリケーション５の内容が変化したり、ユーザ３のアプリケーション５を実行させる担当業務が変化する場合がある。そのような場合に、それらの変化に応じて優先度設定処理部１１の処理を実行して優先度テーブル１５を再作成しても良いし、接続履歴のアクセス回数に応じてステップ６１５などで登録する優先度の段階を上下させても良い。後者は、たとえば、優先度３のユーザＩＤ１５０および接続日時１５２が優先度テーブル１５にあり、同じ接続日時１５２においてアクセス回数がＭ１を超える接続履歴に応じて、優先度を１段階上げて優先度２とするように、優先度の段階を急激に変化させない方法である。この方法は、前述の偶然の接続履歴の優先度への影響の度合いを低下させる効果がある。

図７に、ユーザアクセス受付処理部１２の処理フローチャートを示す。ユーザアクセス受付処理部１２は、ユーザ３によるクライアント端末２を用いたサーバ１へのアクセス要求に応答して実行される。アクセス要求は、（１）サーバ１のアプリケーション５への接続要求（ログイン：セッション確立要求）、（２）アプリケーション５へ接続中のアプリケーション５へのアクセス要求、および、（３）サーバ１のアプリケーション５とのセッション切断要求(ログアウト)に大別される。アクセス要求には、ユーザ３のユーザIDやユーザ３が用いるクライアント端末２のIPアドレスが含まれる。

アクセス要求がセッション切断要求(ログアウト)かを判定する(ステップ７００)。セッション切断要求の場合、セッション切断要求に含まれるユーザIDに対応する、接続状況テーブル１６の切断日時１６７に（サーバ１のカレンダー及び時計から読んだ年月日を含む）現在時刻を格納し、接続状況１６２に「未接続」を格納する(ステップ７０５)。セッション切断要求に対応して接続状況１６２を「未接続」にしたレコードを接続履歴として、前述したように、接続履歴テーブル１４に格納する(ステップ７１０)。

前述したように、接続状況テーブル１６には未接続のユーザ３に関するレコードを設けない場合は、ステップ７０５で現在時刻を接続状況テーブル１６の切断日時１６７に格納せずに、ステップ７１０で現在時刻を切断日時１４３として含んだ接続履歴を接続履歴テーブル１４に格納した後に、該当するレコードを削除する。

セッション切断要求に含まれるIPアドレスのクライアント端末２とアプリケーション５との間のセッションを切断し（ステップ７１５）、ステップ７７０へ移る。

セッション切断要求ではないならば、アクセス要求に含まれるユーザIDに対応する、接続状況テーブル１６のユーザID１６０の接続状況１６２が「接続中」か否かを判定する（ステップ７２０）。この判定は、アクセス要求がセッション確立要求であるか否かを判定しても良いし、接続状況テーブル１６の接続状況１６２とセッション確立要求の双方を判定しても良い。後者の場合、双方の判定結果の矛盾に基づいたエラー処理を実行することができる。「接続中」ならば、ステップ７６５へ移る。

「接続中」でないならば、すなわちセッション確立要求であるならば、サーバ１へ接続可能なクライアント端末２の台数に未達かを判定する（ステップ７２５）。たとえば、サーバ１へ接続可能なクライアント端末２の台数が１０台のときに、現在接続中のクライアント端末２の台数が９台以下かを判定する。未達であるならば、セッション確立要求に応じられるので、ステップ７６０へ移る。

サーバ１へ接続可能なクライアント端末２の台数に達しているならば、セッション確立要求に含まれるユーザID及びIPアドレスの組が優先度テーブル１５に含まれるかを判定する（ステップ７３０）。優先度テーブル１５に、セッション確立要求に含まれるユーザIDに対応するユーザIDがあり、IPアドレスに対応するIPアドレス１５３が無く、IPアドレス１５３が「不定」の場合は含まれているとする（don’t careとする）。含まれているならば、その組に対応する優先度１５１を取得し、含まれていないならば、最も低い優先度とし、取得した優先度以下で実行中の他のユーザがいるかを接続状況テーブル１６を参照して判定する。すなわち、セッション確立要求してきたユーザIDのユーザ３に、サーバ１への接続の優先度として設定される優先度以下の優先度で接続中の他のユーザ３の有無を判定し、無いならば、ステップ７４０へ移る。

有るならば、他のユーザ３が不使用者であるかを判定する（ステップ７３５）。ユーザ３に設定される優先度以下の優先度で接続中の他のユーザが複数いる場合は、その複数の他のユーザの各々が不使用者であるかを判定する。不使用者とは、サーバ１へ接続中であるが、所定時間（たとえば、５分）を超えてサーバ１のアプリケーション５へアクセスしていないユーザ３である。アクセスしていない時間は、接続状況テーブル１６の最新アクセス日時１６６の時刻から現在時刻に至る時間である。所定時間を超えてサーバ１のアプリケーション５へアクセスしていない他のユーザ３がいないならば、ステップ７４０へ移る。

セッション確立要求してきたユーザIDのユーザ３に、サーバ１への接続の優先度として設定される優先度以下の優先度で接続中の他のユーザ３がいないとき、または、そのような他のユーザ３があり、他のユーザ３は不使用者ではないとき、セッション確立要求してきたユーザIDのユーザ３が用いているクライアント端末２に向けて「接続不可」を送信し(ステップ７４０)、ユーザアクセス受付処理部１２の処理を終了する。

不使用者がいるとき、その不使用者のセッションを切断する(ステップ７４５〜ステップ７５５)。ステップ７４５〜ステップ７５５のセッション切断の処理は、セッション切断の対象を異にするが、処理内容はステップ７０５〜ステップ７１５と同じであるので、説明を省略する。

ステップ７３０及びステップ７３５は、セッション確立要求してきたユーザの優先度以下の優先度の他のユーザが不使用者であったならば、その不使用者のセッションを切断し、セッション確立要求してきたユーザに応えようとすることを示している。この２ステップによる処理は、クライアント／サーバ・システムの運用の仕方、すなわちセッション管理に対する考え方により、次のようにしても良い。一つ目は、優先度に係らず、不使用者がいるならば、その不使用者のセッションを切断する。二つ目は、セッション確立要求してきたユーザの優先度未満の優先度の他のユーザのセッションを強制的に切断する。三つ目は、不使用者の存在をチェックする優先度の範囲を、たとえば、セッション確立要求してきたユーザの優先度の一つ上位または一つ下位（ステップ７３０の優先度以下の判定を優先度未満の判定にすることと等価）の優先度までとする。このように、セッション確立要求してきたユーザのために、他のユーザのセッション切断の可否を、優先度と不使用者の存在の有無の少なくとも一方に基づいて決定することができる。

ユーザ３のセッション確立要求に応えられる状況において、優先度テーブル１５を参照してユーザ３の優先度を取得し、ユーザ３の接続状況を接続状況テーブル１６に登録する(ステップ７６０)。優先度の取得は、セッション確立要求に含まれるユーザID及びIPアドレスの組（ペア）が優先度テーブル１５に含まれているならば、その組に対応する優先度１５１を取得する。優先度テーブル１５に、セッション確立要求に含まれるユーザIDに対応するユーザIDがあり、IPアドレスに対応するIPアドレス１５３が無く、IPアドレス１５３が「不定」の場合は含まれているとする。ユーザID及びIPアドレスの組が優先度テーブル１５に含まれていないならば、最も低い優先度である。接続状況テーブル１６への登録は、セッション確立要求に含まれるユーザIDに対応するユーザID１６０の、IPアドレス１６１にセッション確立要求に含まれるIPアドレスを、接続状況１６２に「接続中」を、優先度１６３に優先度テーブル１５を参照して取得した優先度を、接続日時１６４に現在時刻を、アクセス回数１６５に０を、最新アクセス時刻１６６に現在時刻を、それぞれ格納し、切断時刻１６７の内容を削除する。次のステップ７６５の説明から明らかなように、最新アクセス時刻１６６への現在時刻の格納を省略しても良い。

接続状況テーブル１６における、ユーザ３の接続状況を更新する(ステップ７６５)。接続状況の更新は、アクセス要求に含まれるユーザIDに対応するユーザID１６０の、アクセス回数１６５をインクリメント（＋１）し、最新アクセス時刻１６６に現在時刻を格納する。

アプリケーション５へメッセージを転送し（ステップ７７０）、ユーザアクセス受付処理部１２の処理を終了する。メッセージとは、前述のアクセス要求である。一般にアプリケーション５は、ユーザ３からのアクセス要求に応じて応答するために、アプリケーションレベルでセッションを記憶している。したがって、アプリケーション５へメッセージを転送すると、アプリケーション５は、（１）セッション確立要求の場合は、ユーザ３によるセッションを記憶し、記憶したセッションに対応してユーザ３が用いているクライアント端末２に向けて、たとえばブラウザ用の初期画面を応答として、送信する。（２）アプリケーション５へ接続中のアプリケーション５へのアクセス要求の場合は、記憶しているアプリケーションレベルのセッションを参照して、そのアクセス要求に対応する応答を送信する。（３）サーバ１のアプリケーション５とのセッション切断要求(ログアウト)の場合は、記憶してあるアプリケーションレベルのセッションを削除する。

以上説明した実施形態にによれば、クライアント／サーバ・システムの運用状況の変化に応じた優先度を設定できる。

具体的には、ユーザ対応に優先度を設定するので、ユーザが使用するクライアント端末に優先度が必ずしも依存しない。

さらに、ユーザによるアクセス時間帯に対応したアクセス履歴に基づいて優先度を設定するので、ユーザの業務の繁忙期に応じた優先度を付与することが可能となる。

１：サーバ、２：クライアント端末、３：ユーザ、４：ネットワーク、５アプリケーション、１０：セッション管理システム、１１：優先度設定処理部、１２：ユーザアクセス受付処理部、１３：特権定義テーブル、１４：接続履歴データベース、１５：優先度テーブル、１６：接続状況テーブル。

Claims

サーバが有するセッション管理システムであって、
ユーザがクライアント端末を用いて前記サーバにアクセスする時間帯における第１のアクセス回数に基づいて設定した、前記ユーザの前記時間帯における優先度を格納する優先度テープル、
前記ユーザの前記サーバへの接続状況を格納する接続状況テーブル、並びに、
前記ユーザからの前記クライアント端末を用いた前記サーバのアプリケーションへのセッション確立要求に応答して、少なくとも前記セッション確立要求に含まれる前記ユーザのユーザID、前記セッション確立要求に含まれる前記クライアント端末のIPアドレス、前記優先度テーブルに格納された、現在時刻を含む前記時間帯における前記ユーザの前記優先度、および、前記サーバへの接続時刻としての現在時刻を前記接続状況テーブルに格納し、前記アプリケーションへセッション確立するユーザアクセス受付処理部を有することを特徴とするセッション管理システム。
前記ユーザアクセス受付処理部は、前記アプリケーションへセッション確立後、前記ユーザによる前記クライアント端末を用いた前記アプリケーションへのアクセスに応答して、前記アプリケーションへの第２のアクセス回数と最新アクセス日時を前記接続状況として前記接続状況テーブルに格納することを特徴とする請求項１記載のセッション管理システム。
前記ユーザアクセス受付処理部は、前記ユーザからの前記クライアント端末を用いた前記サーバの前記アプリケーションへの前記セッション確立要求に応答して、前記サーバへの接続可能なクライアント端末の台数に接続中の他のクライアント端末の台数が達しているとき、前記ユーザの前記優先度と接続中の前記他のクライアント端末を用いた他のユーザの優先度との関係、及び、接続中の前記他のクライアント端末を用いた前記他のユーザが所定時間を超えて前記サーバの前記アプリケーションへアクセスしていない不使用者であるか否かの少なくとも一方に基づいて前記他のユーザのセッション切断の可否を決定することを特徴とする請求項２記載のセッション管理システム。
前記接続状況テーブルに格納される前記接続状況は、前記アプリケーションへのセッション切断要求に応答して、接続履歴データベースに格納されることを特徴とする請求項３記載のセッション管理システム。
前記セッション管理システムは、前記接続履歴データベースに格納された前記接続状況を参照して、前記ユーザが前記クライアント端末を用いて前記サーバの前記アプリケーションにアクセスした前記時間帯における第２のアクセス回数に基づいて、前記ユーザの前記時間帯における前記優先度を更新する優先度設定処理部をさらに有することを特徴とする請求項４記載のセッション管理システム。
前記優先度テーブルは、前記ユーザのユーザIDと前記クライアント端末のIPアドレスとに対応付けて設定された特権としての優先度を前記ユーザの前記優先度として含むことを特徴とする請求項５記載のセッション管理システム。
サーバが、ユーザがクライアント端末を用いて前記サーバにアクセスするセッションを管理するセッション管理方法であって、前記サーバは、
前記ユーザが前記クライアント端末を用いて前記サーバにアクセスする時間帯におけるアクセス回数に基づいて設定した前記ユーザの前記時間帯における優先度を格納する優先度テープル、及び、前記ユーザの前記サーバへの接続状況を格納する接続状況テーブルを有し、
前記ユーザからの前記クライアント端末を用いた前記サーバのアプリケーションへのセッション確立要求に応答して、少なくとも前記セッション確立要求に含まれる前記ユーザのユーザID、前記セッション確立要求に含まれる前記クライアント端末のIPアドレス、前記優先度テーブルに格納される、現在時刻を含む前記時間帯における前記ユーザの前記優先度、および、前記サーバへの接続時刻として現在時刻を前記接続状況テーブルに格納し、
前記アプリケーションへのセッションを確立することを特徴とするセッション管理方法。