(57)【要約】【課題】端末の操作性を損なうことなく端末の負荷を低減する。【解決手段】端末装置１０は、情報管理サーバ２０で管理される情報を要求する情報要求電文を受信し、情報要求電文に、情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに対応付けられて情報管理サーバ２０で生成されたトークンを付加すると共に、少なくとも１つのチケットのうち、状況の変化に応じて状態が変化した状態変化チケットを付加し、状態変化チケットが付加された情報要求電文を情報管理サーバ２０へ送信してから状態変化チケットに基づいて更新されたトークンを情報管理サーバ２０から受信するまでの期間に新たな情報要求電文を受信した場合に、新たな情報要求電文の送信を保留し、上記期間後で、且つ、端末１０に状態変化チケットが存在しない間、保留した情報要求電文を順次情報管理サーバ２０へ中継する。【選択図】図７
2015201030.tif 000002
【特許請求の範囲】
【請求項１】
情報管理サーバで管理される情報を要求する情報要求電文を受信し、前記情報管理サーバへ中継する中継部と、
前記中継部により受信された前記情報要求電文に、前記情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに対応付けられて前記情報管理サーバで生成されたトークンを付加する付加部と、
を備え、
前記付加部は、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットを前記情報要求電文へ更に付加し、
前記中継部は、前記状態変化チケットが付加された前記情報要求電文を前記情報管理サーバへ送信してから前記状態変化チケットに基づいて更新されたトークンを前記情報管理サーバから受信するまでの期間に新たな情報要求電文を受信した場合に、前記新たな情報要求電文の送信を保留し、前記期間後で、且つ、前記端末に状態変化チケットが存在しない間、保留した情報要求電文を順次前記情報管理サーバへ中継する
端末装置。
【請求項２】
前記期間中に前記新たな情報要求電文を受信した際、前記新たな情報要求電文毎に、前記情報管理サーバへの中継を保留する必要があるか否か判定する判定部を更に備え、
前記中継部は、前記判定部により保留する必要があると判定された場合、前記新たな情報要求電文の送信を保留し、前記判定部により保留する必要がないと判定された場合、前記新たな情報要求電文を、保留することなく前記情報管理サーバへ中継する
請求項１記載の端末装置。
【請求項３】
前記判定部は、前記期間中に受信した前記新たな情報要求電文の送信元であるアプリケーションを特定すると共に、特定したアプリケーションの状況に基づいて、前記新たな情報要求電文の送信を保留する必要があるか否か判定する
請求項２記載の端末装置。
【請求項４】
前記アプリケーションの属性は前記アプリケーションから送信される情報要求電文の送信頻度であり、
前記判定部は、前記期間中に前記送信頻度が予め定めた規定頻度以上であるアプリケーションから前記新たな情報要求電文を受け付けた際、前記新たな情報要求電文を保留するよう判定する
請求項３記載の端末装置。
【請求項５】
前記判定部は、前記期間中に前記新たな情報要求電文を受信した際の前記端末における状態変化チケットの数が予め定めたチケット数を超える場合に、前記新たな情報要求電文を保留するよう判定する
請求項２〜請求項４の何れか１項に記載の端末装置。
【請求項６】
前記判定部は、前記期間中に受信した前記新たな情報要求電文により要求される情報の種別に基づいて、前記新たな情報要求電文の送信を保留する必要があるか否か判定する
請求項２〜請求項４の何れか１項に記載の端末装置。
【請求項７】
前記中継部で受信する前記情報要求電文が、ＨＴＴＰ形式に則った書式によって表される
請求項１〜請求項６の何れか１項に記載の端末装置。
【請求項８】
端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに基づいて生成したトークンと、前記少なくとも１つのチケットで表される前記端末のチケット状態と、を対応づけて管理する管理部と、
前記管理部で生成されたトークンが付加された、リソースを要求するための情報要求電文によって要求された情報が取得可能か否かを判定する認可判定部と、
前記認可判定部により前記情報が取得可能と判定された場合に、前記情報を含む応答を前記端末へ中継する中継部と、
を備え、
前記管理部は、前記情報要求電文に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットが付加されている場合に、前記チケット状態に対応したトークンを更新し、前記端末毎、且つ、チケットの種別毎に前記端末のチケット状態の変化を時系列に従って管理し、チケット種別毎に最も新しいチケット状態を組み合わせて作成した前記端末のチケット情報と、更新したトークンと、を対応づけて管理し、
前記中継部は、前記更新したトークンを前記端末へ中継する
情報管理サーバ。
【請求項９】
コンピュータに、
情報管理サーバで管理される情報を要求する情報要求電文を受信し、
受信した前記情報要求電文に、前記情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに対応付けられて前記情報管理サーバで生成されたトークンを付加すると共に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットを前記情報要求電文へ更に付加し、
前記状態変化チケットが付加された前記情報要求電文を前記情報管理サーバへ送信してから前記状態変化チケットに基づいて更新されたトークンを前記情報管理サーバから受信するまでの期間に新たな情報要求電文を受信した場合に、前記新たな情報要求電文の送信を保留し、前記期間後で、且つ、前記端末に状態変化チケットが存在しない間、保留した情報要求電文を順次前記情報管理サーバへ中継する
ことを含む処理を実行させるための端末プログラム。
【請求項１０】
コンピュータに、
情報管理サーバで管理する情報を要求するための情報要求電文に、前記情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況の変化に応じた少なくとも１つのチケットに基づいて生成したトークンと、前記少なくとも１つのチケットで表される前記端末のチケット状態と、を対応づけて管理すると共に、前記情報要求電文に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットが付加されている場合に、前記チケット状態に対応したトークンを更新し、前記端末毎、且つ、チケットの種別毎に前記端末のチケット状態の変化を時系列に従って管理し、チケット種別毎に最も新しいチケット状態を組み合わせて作成した前記端末のチケット情報と、更新したトークンと、を対応づけて管理し、
前記情報要求電文に付加されたトークンで、前記情報要求電文によって要求された情報が取得可能か否か判定し、
前記要求された情報が取得可能と判定された場合に、前記要求された情報及び前記更新したトークンを含む応答を前記端末へ中継する
ことを含む処理を実行させるための情報管理プログラム。
【請求項１１】
情報管理サーバで管理される情報を要求する情報要求電文を受信し、前記情報管理サーバへ中継する中継部と、前記中継部により受信された前記情報要求電文に、前記情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに対応付けられて前記情報管理サーバで生成されたトークンを付加すると共に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットを前記情報要求電文へ更に付加する付加部と、前記中継部により前記状態変化チケットが付加された前記情報要求電文を前記情報管理サーバへ送信してから前記状態変化チケットに基づいて更新されたトークンを前記情報管理サーバから受信するまでの期間中に新たな情報要求電文を受け付けた際、前記新たな情報要求電文毎に、前記情報管理サーバへの中継を保留する必要があるか否か判定する判定部と、を備えた端末装置と、
前記少なくとも１つのチケットに基づいて生成したトークンと、前記少なくとも１つのチケットで表される前記端末のチケット状態と、を対応づけて管理する管理部と、前記管理部で生成されたトークンが付加された、リソースを要求するための情報要求電文によって要求された情報が取得可能か否かを判定する認可判定部と、前記認可判定部により前記情報が取得可能と判定された場合に、前記情報を含む応答を前記端末へ中継する中継部と、を備えた情報管理サーバと、
を備え、
前記端末装置の前記中継部は、前記判定部により前記新たな情報要求電文を保留する必要があると判定された場合、前記新たな情報要求電文の送信を保留し、前記判定部により保留する必要がないと判定された場合、前記新たな情報要求電文を、保留することなく前記情報管理サーバへ中継し、
前記管理部は、前記情報要求電文に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットが付加されている場合に、前記チケット状態に対応したトークンを更新し、前記端末装置毎、且つ、チケットの種別毎に前記端末装置のチケット状態の変化を時系列に従って管理し、チケット種別毎に最も新しいチケット状態を組み合わせて作成した前記端末装置のチケット情報と、更新したトークンと、を対応づけて管理し、
前記情報管理サーバの前記中継部は、前記更新したトークンを前記端末装置へ中継する
情報管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
開示の技術は、端末装置、情報管理サーバ、端末プログラム、情報管理プログラム、及びシステムに関する。
【背景技術】
【０００２】
近年、携帯型の端末、いわゆるモバイル端末を用いて会社等に設置されるサーバにアクセスし、サーバからモバイル端末へデータ等のリソースをダウンロードして業務を行う機会が増加している。
【０００３】
こうしたモバイル環境では、必要に応じて端末からのアクセスを制限するアクセス制御処理がサーバで実行される。
【０００４】
アクセス制御処理の例として、例えば、端末に関する情報を収集してサーバへ送信し、サーバは端末から送信された情報に基づいてリソースへのアクセスを許可するか否か決定する手法が提案されている。端末に関する情報としては、例えば端末の位置情報が用いられる。
【０００５】
また、端末から認証サーバへ端末ユーザの認証を要求した際に認証サーバから発行される認証トークンを用いて、アプリケーションサーバが端末に提供するサービスを制限する技術が提案されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特表２００８−５１５０８４号公報
【特許文献２】特開２００７−９４５４８号公報
【特許文献３】特表２０１３−５０９７３７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来のアクセス制御処理では、端末がサーバへ情報を送信する際の端末の負荷や通信トラフィックに関する検討はなされていなかった。例えば、サーバからリソースを取得する際にリソースの取得に必要な端末の情報を送信する必要がある場合、端末が頻繁に情報を取得しようとすると、リソースを要求する電文に端末の情報を付加する処理等がその都度実行され、端末の負荷が上昇する。一方、この場合に端末における負荷の上昇を抑制するため、端末からサーバへの情報の送信に制限を加えると、サーバからリソースを取得するまでより長い時間が必要となり、例えば、端末での画像表示が遅延する等、端末の操作性が低下する。
【０００８】
そこで、開示の技術は、一つの側面として、サーバにリソースの取得に必要な端末の情報を頻繁に送信する必要がある場合でも、端末の操作性を損なうことなく端末の負荷を低減することができる、という効果を有する。
【課題を解決するための手段】
【０００９】
開示の技術の中継部は、情報管理サーバで管理される情報を要求する情報要求電文を受信し、情報管理サーバへ中継する。
【００１０】
付加部は、中継部により受信された情報要求電文に、情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに対応付けられて情報管理サーバで生成されたトークンを付加する。更に付加部は、少なくとも１つのチケットのうち、状況の変化に応じて状態が変化した状態変化チケットを情報要求電文へ付加する。
【００１１】
そして、中継部は、状態変化チケットが付加された情報要求電文を情報管理サーバへ送信してから状態変化チケットに基づいて更新されたトークンを情報管理サーバから受信するまでの期間に新たな情報要求電文を受信した場合に、新たな情報要求電文を保留する。そして、中継部は、上記期間後で、且つ、端末に状態変化チケットが存在しない間、保留した情報要求電文を順次前記情報管理サーバへ中継する。
【発明の効果】
【００１２】
開示の技術は、一つの側面として、サーバにリソースの取得に必要な端末の情報を頻繁に送信する必要がある場合でも、端末の操作性を損なうことなく端末の負荷を低減することができる、という効果を有する。
【図面の簡単な説明】
【００１３】
【図１】図１は、端末からリソースサーバへアクセスする際のアクセス制御の一例を示した図である。
【図２】図２は、プロキシを設けた場合にリソースサーバへアクセスする際のアクセス制御の一例を示した図である。
【図３】図３は、チケットの一例を示した図である。
【図４】図４は、トークンを用いたアクセス制御の一例を示した図である。
【図５】図５は、チケットの状態に変化がない場合のアクセス制御の一例を示した図である。
【図６】図６は、チケットの状態に変化が発生した場合のアクセス制御の一例を示した図である。
【図７】図７は、第１実施形態に係る端末及び情報管理サーバを含むシステムの一例を示した図である。
【図８】図８は、情報要求電文のヘッダの一例を示した図である。
【図９】図９は、情報要求電文の保留処理の一例を示した図である。
【図１０】図１０は、トークン管理テーブルの一例を示した図である。
【図１１】図１１は、認可ポリシーテーブルの一例を示した図である。
【図１２】図１２は、判定結果テーブルの一例を示した図である。
【図１３】図１３は、応答の一例を示した図である。
【図１４】図１４は、第１実施形態に係る端末として機能するコンピュータのブロック図である。
【図１５】図１５は、第１実施形態に係る情報管理サーバとして機能するコンピュータのブロック図である。
【図１６】図１６は、第１実施形態に係る端末での情報要求電文中継処理のフローチャートである。
【図１７】図１７は、第１実施形態に係る情報管理サーバでの応答処理のフローチャートである。
【図１８】図１８は、第１実施形態に係る情報管理サーバでのトークン更新処理のフローチャートである。
【図１９】図１９は、第１実施形態に係る端末での保留電文中継処理のフローチャートである。
【図２０】図２０は、第２実施形態に係る端末及び情報管理サーバを含むシステムの一例を示した図である。
【図２１】図２１は、トークンの更新状況の一例を示した図である。
【図２２】図２２は、第２実施形態に係るチケット更新管理テーブルの一例を示した図である。
【図２３】図２３は、第２実施形態に係るトークン管理テーブルの一例を示した図である。
【図２４】図２４は、第２実施形態に係る端末として機能するコンピュータのブロック図である。
【図２５】図２５は、第２実施形態に係る情報管理サーバとして機能するコンピュータのブロック図である。
【図２６】図２６は、第２実施形態に係る端末での情報要求電文中継処理のフローチャートである。
【図２７】図２７は、第２実施形態に係る情報管理サーバでのトークン更新処理のフローチャートである。
【図２８】図２８は、第３実施形態に係る端末及び情報管理サーバを含むシステムの一例を示した図である。
【図２９】図２９は、送信頻度テーブルの一例を示した図である。
【図３０】図３０は、第３実施形態に係る端末として機能するコンピュータのブロック図である。
【図３１】図３１は、第３実施形態に係る認可ポリシーテーブルの一例を示した図である。
【図３２】図３２は、第３実施形態に係る判定結果テーブルの一例を示した図である。
【発明を実施するための形態】
【００１４】
以下、図面を参照して、開示の技術の実施形態の一例を詳細に説明する。
【００１５】
（第１実施形態）
【００１６】
通信ネットワークの整備の進展と共にモバイル端末を持ち運び、様々な場所で遠隔地に設けられたサーバと情報を共有して作業を遂行する環境が整えられている。一方、こうした状況は、上司等の作業を監督する者の監視が行き届かない場所で、作業者がモバイル端末等を用いてサーバにアクセスできる状態になることを意味する。従って、サーバに対するセキュリティー管理の重要性が従来にも増して注目されている。
【００１７】
図１は、遠隔地のモバイル端末（以下、端末という）から、リソースサーバに記憶される各種情報（リソース）にアクセスする際のアクセス制御の一例を示した図である。
【００１８】
図１に示すように、端末で実行されるアプリケーションは、例えばリソースへアクセスする際、端末利用者の状況を示す情報を含む状況情報を取得する。そして、端末のアプリケーションは取得したいリソースを記載した情報要求電文に、リソースを取得するために必要となる予め定めた状況情報を付加してリソースサーバへ送信する。一方、リソースサーバでは、認可ポリシーを参照して、端末から受信した状況情報でリソースにアクセス可能か否か判定し、アクセス可能であれば、要求されたリソースを付加した応答を情報要求電文の送信元の端末へ送信する。
【００１９】
ここで、端末利用者の状況とは、例えば端末の位置情報等によって表される端末利用者の場所、端末利用者の所属先や所属先における身分等に応じた端末利用者のユーザ権限、端末利用者が休憩中か作業中かといったユーザ状態等をいう。以下では説明をわかりやすくするため、一例として端末利用者が教師である場合について説明するが、端末利用者は教師に限定されず、どのような立場の人であってもよいことはいうまでもない。また、リソースのアクセスに必要な端末利用者の状況が端末利用者の場所、ユーザ権限、及びユーザ状態に限定されることもなく、これ以外の情報を含むものであってもよい。また、状況情報としては、端末利用者の状況だけでなく、端末の状況、端末及び端末利用者周辺の状況等を含んでもよい。しかし、以下では説明をわかりやすくするため、一例として端末利用者の状況は場所、ユーザ権限、及びユーザ状態の３つの状況情報で表されるものとする。
【００２０】
例えば、教師は無線等で端末に接続されたカードリーダー等の情報読み取り装置に自分の身分証に記憶されている情報を読み取らせ、端末内のアプリケーションに自分のユーザ権限が“教師”であることを通知する。この際、情報読み取り装置は、例えば、身分証の情報を読み取った時刻情報及び教師を識別するための識別子である教師ＩＤを教師の出勤スケジュールが予め記憶されているスケジューラ装置に無線等で通知する。スケジューラ装置は、教師の出勤スケジュールを参照し、通知された時刻情報及び教師ＩＤに基づいて、教師ＩＤで表される教師が勤務時間中であると判断した場合に、端末内のアプリケーションに教師のユーザ状態が“就業中”であることを無線等で通知する。また、例えば、端末のアプリケーションは、端末に内蔵されているＧＰＳ（Global Positioning System）センサ等が出力する位置情報から教師の位置を取得し、取得した位置情報が学校の位置情報範囲内に含まれる場合、教師の居場所を“校内”と判定する。
【００２１】
そして、アプリケーションは、教師が必要とするリソースを取得する際に必要となる、リソース毎に予め定めた状況情報を情報要求電文に付加し、リソースサーバへ送信する。
【００２２】
例えば、端末から要求されたリソースの認可ポリシーが（場所、ユーザ権限、ユーザ状態）＝（校内、教師、就業中）である場合、リソースサーバは情報要求電文に付加された状況情報が認可ポリシーを充足する場合にリソースへのアクセスを許可する。図１に示す例では、情報要求電文に付加された状況情報が、認可ポリシーを充足するため、リソースサーバは、教師が要求するリソースを応答に付加して、情報要求電文の送信元である端末のアプリケーションへ送信する。
【００２３】
一方、上記の例において、教師が校内でアクセスしたリソースと同じリソースを自分の自宅に持ち帰った端末で取得しようとした場合について考える。この場合、端末のアプリケーションは、ＧＰＳセンサから取得した位置情報が予め登録されている教師の自宅を示す位置情報範囲内に含まれると判断して、教師の場所を“自宅”と判定する。従って、情報要求電文に付加される状況情報がリソースの認可ポリシーとは異なるものとなるため、教師が校内でアクセスしたリソースと同じリソースを自宅から取得することはできない。
【００２４】
しかし、こうしたリソースに対するアクセス権の制御方法では、端末のアプリケーション自身が端末で扱う状況情報を情報要求電文に付加するため、状況情報の信頼性が担保されないという問題が存在する。例えば、情報要求電文に付加する状況情報が、実際の端末利用者の状況とは異なる状況を表す状況情報に改ざんされた場合、実際の端末利用者の状況が認可ポリシー以外の状態であってもリソースが取得されてしまう場合がある。
【００２５】
また、既存のアプリケーションに対して、情報要求電文に状況情報を付加する処理を追加する改修が必要となるため、こうしたリソースに対するアクセス権の制御方法を既存のアプリケーションへ適用することが困難な場合が考えられる。リソースサーバ内のアプリケーションについても、情報要求電文から状況情報を抽出して認可ポリシーを充足するか否か判定する機能を追加する改修が必要となる。従って、この様なリソースに対するアクセス権の制御方法をリソースサーバへ適用することが困難な場合が考えられる。
【００２６】
従って、端末内のアプリケーションと通信ネットワークとの間に、状況情報付加プロキシを設けると共に、通信ネットワークとリソースサーバとの間にアクセス制御プロキシを設ける方法が提案される。
【００２７】
図２は、状況情報付加プロキシ及びアクセス制御プロキシを設けた場合のリソースに対するアクセス権の制御方法を示した図である。
【００２８】
ここで、状況情報付加プロキシとは、状況情報を収集し、アプリケーションから受信した情報要求電文に状況情報を付加してアクセス制御プロキシへ中継すると共に、アクセス制御プロキシから受信した応答を端末内のアプリケーションへ中継するプロキシである。一例として状況情報付加プロキシは端末内に設けられるものとして説明を行うが、端末の外部に状況情報付加プロキシを配置する形態であってもよい。
【００２９】
また、アクセス制御プロキシとは、端末から受信した情報要求電文に付加された状況情報と、予め登録されている認可ポリシーの認可条件と、を照合し、認可条件を満たす場合に情報要求電文をリソースサーバへ中継するプロキシである。そして、アクセス制御プロキシは、中継した情報要求電文に対応するリソースサーバからの応答を、当該情報要求電文の送信元である端末内の状況情報付加プロキシへ中継する。
【００３０】
この場合、状況情報付加プロキシ及びアクセス制御プロキシにリソースに対するアクセス権の制御処理が実装されるため、端末内のアプリケーション及びリソースサーバを改修する必要がない。また、状況情報付加プロキシ及びアクセス制御プロキシをリソースの管理者が管理するようにすれば、各プロキシに対する悪意ある改ざんの検出が可能となる。従って、図１に示したリソースアクセス制御方法に比べて、情報要求電文に付加される状況情報の信頼性が向上する。更に、状況情報の通知元の装置、状況情報付加プロキシ、及びアクセス制御プロキシは、状況情報自体が改ざんされないよう、例えば暗号化等が施された互いに信頼できる状況情報を用いるようにする。従って、情報要求電文に付加される状況情報の信頼性は更に向上する。
【００３１】
なお、以下では、信頼できる状況情報を特に“チケット”と呼び、特にことわりがない限り、単に“状況情報”と記載されている場合、この“状況情報”はチケットを表しているものとする。また、状況情報付加プロキシを“端末プロキシ”、アクセス制御プロキシを“制御プロキシ”と称す。
【００３２】
こうしたプロキシを用いたアクセス権の制御方法では、端末プロキシは、制御プロキシとの独立性を高めセキュリティー性能を向上させるため、リソースの取得に必要な認可ポリシーの情報を所有していない。従って、端末プロキシは、収集した全てのチケットを情報要求電文に付加する。すなわち、この場合、情報要求電文のデータ量は、図１に示したリソースアクセス制御方法における情報要求電文のデータ量より増加するため、端末での通信処理に係る負荷（通信負荷）が増大すると共に、端末の電力消費量も増大する場合がある。
【００３３】
ここでは、情報要求電文のデータ量に関して具体的に検証する。図３は、情報要求電文に付加されるチケットの一例を示した図である。
【００３４】
図３に示すように、暗号化前の状況情報は、チケットＩＤ（Identification：識別子）、チケット種別、チケット名、有効期限、及びチケット通知元情報を含む。チケットＩＤはチケットを識別するための項目である。チケット種別はチケットが場所に関する情報なのか、ユーザ権限に関する情報なのか、それともユーザ状態に関する情報なのかを示す項目である。チケット名は、チケット種別で示された種別に関する具体的な内容を示す項目であり、例えばチケット種別が“場所”であれば“校内”及び“自宅”等が設定される。有効期限は、当該チケットの有効期限を示したものであり、例えば１９７０年１月１日午前０時からの経過時間をミリ秒で表したものが用いられる。なお、有効期限経過後は、当該チケットは制御プロキシにおいて無効なチケットとして扱われ、無効なチケットに基づくリソースアクセスとして拒否される。チケット通知元情報は、チケットを端末プロキシへ通知した装置等を識別するための情報であり、例えばその装置のネットワーク上の所在を示すＵＲＬ（Uniform Resource Location）で表される。
【００３５】
そして、暗号化前の状況情報は、チケット通知元によって例えば予め定めたビット数の暗号鍵で暗号化される。そして、例えばアプリケーションからの情報要求電文がHTTP（Hypertext Transfer Protocol）リクエストとして表されている場合、端末プロキシは、チケットをBase64でエンコードする。そして、端末プロキシは、Base64でエンコードしたチケットを情報要求電文のヘッダへ付加する。なお、端末プロキシ及び制御プロキシはチケット通知元の暗号鍵に対する公開鍵を予め所有しているものとする。
【００３６】
この際、情報要求電文のヘッダへ付加したチケットのデータ量が、例えば１７２バイトであるとする。端末プロキシは場所、ユーザ権限、及びユーザ状態に関する３種類のチケットを収集するものとすれば、毎回５１６バイトのチケットが情報要求電文のヘッダに付加される。仮に、アプリケーションから受信する情報要求電文自体のデータ量が５００バイト近傍の範囲に収まるとした場合、端末プロキシから制御プロキシへ中継される情報要求電文のデータ量は、当初の情報要求電文の２倍前後のデータ量となる場合がある。
【００３７】
なお、当然のことながら、端末プロキシから制御プロキシへ中継される情報要求電文のデータ量は、チケット数及び１つあたりチケットのデータ量の少なくとも一方が増加するに従って増加する。また、チケットの信頼度をより向上するためチケットの暗号化に用いる暗号鍵のビット数を増加するに従って、端末プロキシから制御プロキシへ中継される情報要求電文のデータ量が増加する。すなわち、リソースへのアクセス要求に対するセキュリティー性能を向上させるに従って、情報要求電文のデータ量が増加し、それに伴って、端末プロキシにおける通信負荷がより増加することになる。
【００３８】
一方、制御プロキシが受信する情報要求電文には、端末プロキシで収集した全てのチケットが毎回付加される。従って、制御プロキシは、端末プロキシから情報要求電文を受信する度に、情報要求電文に付加された全てのチケットを復号化する必要がある。そして、制御プロキシは、端末が要求するリソースへのアクセスに必要なチケット種別のチケット名の内容及び認可ポリシーに基づいて、リソースへのアクセスを許可するか否かを判定することになる。従って、図１に示したリソースアクセス制御方法に比べて制御プロキシの負荷が増大し、端末内のアプリケーションから見た場合の情報要求電文を送信してから応答が戻ってくるまでの応答性能が低下する。すなわち、アプリケーションに対する操作性の低下につながる場合がある。
【００３９】
こうした端末プロキシ及び制御プロキシにおける負荷の増大を抑制する方法の一例として、チケットの替わりにトークンを情報要求電文に付加する方法が考えられる。
【００４０】
ここでトークンとは、端末プロキシで収集される全てのチケット種別におけるチケット名の内容と対応づけた情報であり、チケット種別の各々におけるチケット名の内容に変化がない期間に亘って有効な情報である。トークンは、端末プロキシで収集される全てのチケット種別におけるチケット名の内容を一意に示すものであればよい。従ってトークンは、全てのチケット種別におけるチケット名の内容に基づいて求めたハッシュ値や、トークンの生成時間等によって表される。本実施形態では一例として、トークンの生成時間を全てのチケット種別におけるチケット名の内容と関連付け、トークンとして利用する。
【００４１】
なお、本実施形態におけるトークンは、例えば“20140214181020300-01”といった20バイトの文字列により表される。ここで2014は年、02は月、14は日、18は時、10は分、20は秒、300はミリ秒を表している。なお、ハイフンの後の２桁の文字列は、01、02、・・・で表される連番を示している。これは、ミリ秒より短い間隔で生成したトークンの時系列を示した連番であり、２桁の文字列によって表される数が大きくなるに従って、後から生成されたトークンであることを表している。例えば、“-02”は“-01”よりも後に生成されたトークンであることを表す。
【００４２】
図４〜図６は、トークンを利用したリソースアクセス制御方法の一例を説明するための図である。
【００４３】
図４は、端末が初めて制御プロキシへ情報要求電文を送信する際のリソースアクセス制御方法の一例を示す。
【００４４】
端末プロキシは収集した全てのチケットを管理するチケット管理テーブルを含み、チケット毎にチケット種別、チケット名、及び更新フラグを管理する。ここで更新フラグとは、チケット名の内容に変化があった際に、端末プロキシによりtrueに設定され、端末プロキシによってチケット名の内容の変化に対する処理（詳細は後述）が行われた際に、端末プロキシによりfalseに設定されるバイナリ変数をいう。ここで、チケット名の内容に変化があったとは、同一のチケット種別に対して異なるチケット名の状況情報が通知されたことをいい、チケットの状態が変化したことをいう。
【００４５】
端末プロキシは更新フラグがtrueに設定されているチケット、すなわち状態が変化したチケット（状態変化チケット）を情報要求電文に付加して制御プロキシへ送信する処理を実行する。なお、端末プロキシが初めて制御プロキシへ情報要求電文を送信する際には、各チケットの更新フラグはtrueに設定される。従って、端末プロキシが初めて制御プロキシへ情報要求電文を送信する場合、端末プロキシは収集した全てのチケットを情報要求電文に付加することになる。
【００４６】
一方、制御プロキシは、情報要求電文に付加されたチケットに基づいてトークンを生成する。この際、制御プロキシは、生成したトークンの内容、具体的にはトークンの生成時間と、情報要求電文に付加されたチケットの組を表す情報（チケット情報）と、を関連付けたトークン管理テーブルを生成する。そして、制御プロキシは、生成したトークンに対応したチケットで要求されたリソースにアクセス可能か否かを認可ポリシーに基づいて判定し、アクセス可能であれば情報要求電文をリソースサーバに転送する。
【００４７】
制御プロキシは、リソースサーバから応答を受信すると、生成したトークン（図４の例ではトークン１）を応答に付加し、情報要求電文の送信元である端末の端末プロキシへ転送する。
【００４８】
端末プロキシは、受信した応答に付加されたトークンを応答から取得して保管する。また、端末プロキシは、チケットの変化が制御プロキシで確認されたものとして、情報要求電文に付加したチケットの更新フラグをfalseに戻す。そして、トークンを削除した応答をアプリケーションへ転送する。
【００４９】
図５は、チケットに変化がない場合のリソースアクセス制御方法の一例を示した図である。
【００５０】
この場合、端末プロキシはアプリケーションから情報要求電文を受信すると、チケットではなく、保管したトークン１を情報要求電文に付加して制御プロキシへ転送する。制御プロキシでは、トークン管理テーブルを参照して、受信したトークン（図５の例ではトークン１）に対応した端末のチケット情報を取得する。そして制御プロキシは、トークン管理テーブルから取得したチケット情報と認可ポリシーとに基づいて、要求されたリソースにアクセス可能か否かを判定する。すなわち、制御プロキシは、情報要求電文に付加されたトークンによって、端末におけるチケットの状態を把握することができる。
【００５１】
図６は、チケットの状態が変化した場合のリソースアクセス制御方法の一例を示した図である。
【００５２】
この場合、端末プロキシは、アプリケーションから情報要求電文を受信すると、保管しているトークン及び状態変化チケットを情報要求電文に付加して制御プロキシへ転送する。図６に示した例では、端末プロキシが収集したチケットにおいて、チケット種別がユーザ状態のチケットのチケット名が“就業中”から“就業外”に変化している。この際、端末プロキシは（ユーザ状態＝就業外）のチケットの更新フラグをtrueに設定する。従って、端末プロキシは、トークン１及びユーザ状態を示すチケットを情報要求電文に付加する。この際、端末プロキシは（ユーザ状態＝就業外）のチケットの更新フラグをfalseに設定する。
【００５３】
一方、制御プロキシはトークン管理テーブルを参照して、トークン１に関連付けられたチケット情報を取得し、取得したチケット情報のうち情報要求電文に付加されたチケットと同じチケット種別のチケットを、情報要求電文に付加されたチケットで置き換える。そして、制御プロキシは、置換後のチケット情報に基づいて新しいトークンを生成して、生成した新しいトークンと、置換後のチケット情報と、を関連付けた情報をトークン管理テーブルに追加する。
【００５４】
図６に示した例では、トークン１に関連付けられたチケット情報のうち、（ユーザ状態＝就業中）のチケットが（ユーザ状態＝就業外）に置き換えられる。そして、制御プロキシは、（場所＝校内）、（ユーザ権限＝教師）、及び（ユーザ状態＝就業外）の３つのチケットに対応したトークン２を生成する。
【００５５】
そして、要求されるリソースの認可ポリシーが、（場所、ユーザ権限、ユーザ状態）＝（校内、教師、就業中）であれば、制御プロキシはリソースへのアクセス不可を理由としたエラーを示す応答に新たに生成したトークン２を付加して、端末プロキシへ転送する。
【００５６】
そして、端末プロキシは、トークン１の替わりに制御プロキシから新たに通知されたトークン２を保管する。
【００５７】
図２に示したリソースアクセス制御方法では、チケットの変化の有無に関わらず、情報要求電文に全てのチケットを付加する必要がある。しかし、図４〜図６に示したリソースアクセス制御方法ではチケットの状態に変化がない場合、チケットに比べてデータ量の少ないトークンを情報要求電文に付加すればよい。従って、端末における通信負荷を軽減することができる。
【００５８】
しかしながら、端末のアプリケーションがブラウザ等のＷｅｂアプリケーションである場合、１つの画面を表示するために複数のリソースを必要とする場合がある。すなわち、Ｗｅｂアプリケーションに表示する画面を切り替える度に、複数の情報要求電文がアプリケーションから端末プロキシへ送信される。そして、仮にこのタイミングでチケットの状態が変化している場合、端末プロキシは、情報要求電文の各々に状態が変化したチケットを付加して制御プロキシに転送する必要があるため、端末の通信負荷が増大する場合がある。
【００５９】
このような、チケットの状態が変化した際に複数の情報要求電文を受信する場合に生ずる通信負荷を低減するため、例えば、端末プロキシが各情報要求電文に対する応答を待って、情報要求電文を１つずつ制御プロセスへ中継する方法が考えられる。しかし、こうした方法では１つの画面を表示し終えるまで時間を要してしまい、Ｗｅｂアプリケーションの操作性が劣化する。
【００６０】
そこで以下では、端末の通信負荷を低減すると共に、アプリケーションの操作性の劣化を抑制する端末及びリソース管理サーバについて説明する。
【００６１】
図７は、本実施形態に係る端末１０及び情報管理サーバ２０を含むシステム１２を示した図である。端末１０及び情報管理サーバ２０は通信回線３０を介して接続され、相互にデータの送受信が行われる。また通信回線３０にはリソースを記憶するリソースサーバ４０が接続され、情報管理サーバ２０を介して、端末１０から要求されたリソースを端末１０へ送信する。なお、リソースサーバ４０は必ずしも通信回線３０に接続される必要はなく、リソースサーバ４０の有する機能を情報管理サーバ２０に含めるようにしてもよい。また、リソースサーバ４０と情報管理サーバ２０とを、通信回線３０と異なる別の通信回線で直接接続するようにしてもよい。
【００６２】
また、複数の端末１０が通信回線３０に接続されていてもよいが、説明を簡略化するため、本実施形態では１台の端末１０が通信回線３０に接続されるものとして説明を進める。
【００６３】
また、本実施形態のおける端末１０、情報管理サーバ２０、及びリソースサーバ４０で用いられる各種電文には、http形式の電文が用いられるものとして説明するが、他のプロトコルに従った電文を用いてもよいことはいうまでもない。
【００６４】
端末プロキシ５０は、取得部５１、チケット管理部５２、トークン管理部５３、付加部５４、監視部５５、中継部５６、及び抽出部５７を含む。そして、端末１０は、端末プロキシ５０及びアプリケーション６０を含む。
【００６５】
取得部５１は、端末１０で収集するチケットを有線及び無線の少なくとも一方の手段を用いて取得する。チケットを取得する形態には、チケット通知元の装置からチケットを取得する形態や、端末１０に含まれる図示しないセンサのデータを外部の装置へ送信してデータのチケット化を依頼し、チケット化されたセンサのデータを取得する形態が含まれる。そして、取得部５１は、取得したチケットをチケット管理部５２へ通知する。
【００６６】
チケット管理部５２は、取得部５１によって取得されたチケットの内容を参照して、チケット種別毎にチケット管理テーブルの内容を更新する。この際、チケット管理部５２は、取得したチケットにおけるチケット名が前回のチケット名と異なる場合に、更新フラグをtrueに設定する。そして、チケット管理部５２は、取得部５１で取得したチケットをチケット種別毎に上書きして保管する。
【００６７】
なお、チケット管理部５２は、保管されていないチケット種別のチケットを初めて取得した際、取得したチケットに対応するチケット種別の更新フラグ欄にtrueを設定する。
【００６８】
そして、チケット管理部５２は、後述する付加部５４から状態変化チケットの要求を受け付けた際、チケット管理テーブルを参照して、更新フラグがtrueとなっているチケット、すなわち状態変化チケットを付加部５４へ提供する。そして、チケット管理部５２は、付加部５４へ提供した状態変化チケットの更新フラグをfalseに設定する。状態変化チケットが存在しない場合には、チケット管理部５２は付加部５４へ状態変化チケットがない旨の情報を通知する一方、チケットの提供は行わないようにする。
【００６９】
トークン管理部５３は、情報管理サーバ２０から送信されたトークンを保管し、後述する付加部５４からの要求に応じて保管しているトークンを提供する。また、トークン管理部５３は、付加部５４からトークンを要求された際に保管しているトークンが存在しない場合には、付加部５４へトークンがない旨の情報を通知する。
【００７０】
付加部５４は、後述する中継部５６からの指示により、アプリケーション６０から受信した情報要求電文のヘッダにトークン及び状態変化チケットを付加する。具体的には、付加部５４は、チケット管理部５２に対して状態変化チケットを要求し、チケット管理部５２から取得した状態変化チケットを情報要求電文のヘッダへ付加する。また、付加部５４は、トークン管理部５３に対してトークンを要求し、トークン管理部５３から取得したトークンを情報要求電文のヘッダへ付加する。
【００７１】
なお、付加部５４は、チケット管理部５２から状態変化チケットがない旨の情報を通知された場合、情報要求電文のヘッダにチケットを付加しない。同様に、付加部５４は、トークン管理部５３からトークンがない旨の情報を通知された場合、情報要求電文のヘッダにトークンを付加しない。
【００７２】
図８は、トークン及び状態変化チケットが付加された情報要求電文のヘッダの一例を示した図である。図８の破線で囲まれた情報が、付加部５４によって付加されたトークン及び状態変化チケットの一例である。
【００７３】
ここで、“X-Token:”に続く“20140214181020300-01”の文字列がトークンを表す。また、“X-Ticket-Num:”に続く数がヘッダに付加されるチケットの数を表す。そして、“X-Ticket-0:”、“X-Ticket-1:”、及び“X-Ticket-3:”に続く各々の文字列がチケットを表す。なお、既に説明したように、チケットは、例えば１２８ビット等の予め定めたビット数の暗号鍵で暗号化され、且つ、Base64でエンコードされた文字列である。
【００７４】
従って、トークン管理部５３からトークンがない旨の情報を通知された場合、ヘッダに“X-Token:”の項目は追加されない。また、チケット管理部５２から状態変化チケットがない旨の情報を通知された場合、ヘッダに“X-Ticket-Num:”の項目及び“X-Ticket-X:”（Ｘは０以上の整数）の項目は追加されない。
【００７５】
中継部５６は、アプリケーション６０から情報要求電文を受信した際、情報要求電文によって要求されるリソースへのアクセス権として用いられる状態変化チケット及びトークンの少なくとも一方を、情報要求電文のヘッダに付加するよう付加部５４へ指示する。そして、中継部５６は、付加部５４により状態変化チケット及びトークンの少なくとも一方が付加された情報要求電文を、情報管理サーバ２０へ中継する。
【００７６】
また、中継部５６は、情報管理サーバ２０から受信した応答を、後述する監視部５５、後述する抽出部５７、及び当該応答に対応する情報要求電文の送信元であるアプリケーション６０へ中継する。
【００７７】
監視部５５は、中継部５６により情報管理サーバ２０へ中継される情報要求電文のヘッダに、少なくとも１つの状態変化チケットが付加されているか否かを監視する。そして、監視部５５は、情報要求電文のヘッダに少なくとも１つの状態変化チケットが付加されている場合に、トークン更新中フラグをtrueに設定する。
【００７８】
一方、監視部５５は、中継部５６によりアプリケーション６０へ中継される応答のヘッダに更新されたトークンが付加されているか否かを監視する。そして、監視部５５は応答のヘッダにトークンが付加されている場合に、トークン更新中フラグをfalseに設定する。そして、監視部５５は中継部５６からの問い合わせに対して、問い合わせの際のトークン更新中フラグの設定値を通知する。
【００７９】
抽出部５７は、中継部５６によりアプリケーション６０へ中継される応答のヘッダに更新されたトークンが付加されている場合、更新されたトークンを抽出する。そして、抽出部５７は、抽出したトークンをトークン管理部５３へ提供する。トークン管理部５３は、提供されたトークンをこれまで保管してきたトークンに替わって保管する。
【００８０】
更に中継部５６は、アプリケーション６０から情報要求電文を受信した際、付加部５４へ状態変化チケット及びトークンの少なくとも一方を付加するよう指示する前に、監視部５５へトークン更新中フラグの状態を問い合わせる。そして、トークン更新中フラグがtrue、すなわち、情報管理サーバ２０に送信したトークンの更新を伴う情報要求電文に対する応答が中継部５６に戻ってきていない場合、中継部５６は受信した情報要求電文の情報管理サーバ２０への中継を保留する。具体的には、情報要求電文は中継部５６に含まれるFIFO（First In,First Out）等のキューに保留される。
【００８１】
一方、トークン更新中フラグがfalseの場合、中継部５６は受信した情報要求電文をキューに保留せず、既に説明した処理に従って情報管理サーバ２０へ中継する。
【００８２】
そして、中継部５６は、情報管理サーバ２０から応答を受信した場合に、監視部５５へトークン更新中フラグの状態を問い合わせる。そして、トークン更新中フラグがfalseであれば、中継部５６は保留されている情報要求電文をキューから取り出し、既に説明した処理に従って、キューから取り出した情報要求電文を情報管理サーバ２０へ中継する。なお、中継部５６は、キューから情報要求電文を１つ取り出す度に、監視部５５へトークン更新中フラグの状態を問い合わせる。これは、情報要求電文の保留中にチケットの状態に変化が生じている場合が考えられるからである。トークン更新中フラグがtrueであれば、中継部５６は新しいトークンが付加された応答が戻ってくるまで、情報要求電文をキューに保留する。
【００８３】
図９は、中継部５６で実行される情報要求電文の保留処理の一例を示した図である。
【００８４】
なお、図９の例では、中継部５６がアプリケーション６０から情報要求電文１を受信した際、チケット種別がユーザ状態のチケット名が“就業中”から“就業外”に変化しているものとする。また、中継部５６がアプリケーション６０から情報要求電文１を受信した際、トークン管理部５３はトークン１を保管しているものとする。
【００８５】
この場合、中継部５６はトークン１及び（ユーザ状態＝就業外）である状態変化チケットが付加された情報要求電文１を情報管理サーバ２０に中継する。この際、監視部５５によりトークン更新中フラグがtrueに設定される。
【００８６】
そして、情報要求電文１に対応する更新されたトークンであるトークン２が付加された応答が情報管理サーバ２０から中継部５６に送信される前に、中継部５６がアプリケーション６０から情報要求電文２及び情報要求電文３を受信したとする。この場合、トークン更新中フラグがtrueであるため、中継部５６は受信した情報要求電文２及び情報要求電文３をそれぞれキュー＃１、キュー＃２に保留する。
【００８７】
そして、中継部５６が応答を受信した場合、トークン管理部５３で保管されるトークンがトークン２に置き換わり、監視部５５によりトークン更新中フラグがfalseに設定される。従って中継部５６は、キュー＃１から情報要求電文２を取り出し、付加部５４によって付加されたトークン２と共に情報要求電文２を情報管理サーバ２０へ送信する。
【００８８】
更に中継部５６は、まだキューに情報要求電文が保留されている場合、監視部５５にトークン更新中フラグの状態を問い合わせる。トークン更新中フラグがfalseであれば、中継部５６は情報要求電文２に対する応答を待たずにキュー＃２から情報要求電文３を取り出し、付加部５４によって付加されたトークン２と共に情報要求電文３を情報管理サーバ２０へ送信する。
【００８９】
なお、図９の例では、情報要求電文２及び３を送信する際には、状態変化チケットは生じていないものとする。また、図７では説明を簡略化するため、アプリケーション６０を１つしか示していないが、端末１０は複数のアプリケーション６０を含んでいてもよいことはいうまでもない。
【００９０】
次に、情報管理サーバ２０について説明する。
【００９１】
情報管理サーバ２０は、中継部２１、トークン管理部２２、及びアクセス判定部２３を含む。
【００９２】
中継部２１は、端末１０から送信される情報要求電文を受信し、ヘッダをトークン管理部２２へ通知してトークンの更新を依頼する。
【００９３】
トークン管理部２２は、既に説明したトークン管理テーブル及びヘッダに基づき、受信したトークンの妥当性チェック、トークン管理テーブルの更新、及びトークンの生成を行う。
【００９４】
図１０は、トークン管理部２２が管理するトークン管理テーブルの一例を示した図である。
【００９５】
既に説明したように、トークン管理テーブルは、生成したトークンと、端末１０における各チケットの状態と、を関連付けたテーブルである。トークン管理部２２は、トークン管理テーブルを参照することで、トークンから端末１０における各チケットの状態を取得することができる。図１０の例では、例えば“20140214181020300-01”で表されるトークンを受け取った場合、トークン管理部２２は、端末１０の所在地が校内であり、端末１０を使用している人は教師であり、その教師は就業中であるとのチケット情報を取得する。
【００９６】
トークン管理部２２は、以下に説明するトークン更新ルールに従って、トークンを管理する。
【００９７】
情報要求電文のヘッダにトークンもチケットも存在しない場合、トークン管理部２２は不正なヘッダと判断し、エラー情報を生成する。そして、トークン管理部２２は生成したエラー情報を中継部２１へ通知する。
【００９８】
情報要求電文のヘッダにトークンは存在しないがチケットが存在する場合には、トークン管理部２２はヘッダのチケットに対応したトークンを生成する。そして、トークン管理部２２は、生成したトークンを中継部２１へ通知すると共に、生成したトークンと、トークンに対応したチケットと、を関連付けてトークン管理テーブルで管理する。なお、このケースは、端末１０が初めて情報管理サーバ２０へ情報要求電文を送信した場合に相当する。
【００９９】
情報要求電文のヘッダで指定されたトークンがトークン管理テーブルに存在しない場合、トークン管理部２２は、指定されたトークンは不正なトークンであると判断し、エラー情報を生成する。そして、トークン管理部２２は生成したエラー情報を中継部２１へ通知する。
【０１００】
情報要求電文のヘッダにチケットは存在しないがトークンが存在し、且つ、当該トークンがトークン管理テーブルに存在する場合、トークン管理部２２は、指定されたトークンは有効なトークンであると判断する。この場合、トークン管理部２２は新たなトークンを生成せず、受け取ったトークンをそのまま中継部２１へ通知する。なお、このケースは、状態変化チケットが存在しない状況で端末１０が情報要求電文を送信した場合に相当する。
【０１０１】
情報要求電文のヘッダにチケット及びトークンが存在し、且つ、当該トークンがトークン管理テーブルに存在する場合、トークン管理部２２は、新たなトークンを生成する。この新たなトークンは、ヘッダ内のトークンで表される端末１０におけるチケット情報を、ヘッダ内のチケットで置き換えたものに対応したトークンである。
【０１０２】
例えば、ヘッダ内のトークンが“20140214181020300-01”であり、ヘッダ内のチケットが（ユーザ状態＝就業外）である場合を例に説明する。まず、トークン管理部２２は、図１０に示すトークン管理テーブルを参照して、トークンが表すチケット情報は（場所、ユーザ権限、ユーザ状態）＝（校内、教師、就業中）であると把握する。そして、トークン管理部２２は、把握したチケット情報をヘッダ内のチケットで更新する。この場合、ヘッダ内のチケットは（ユーザ状態＝就業外）であることから、新たなチケット情報は（場所、ユーザ権限、ユーザ状態）＝（校内、教師、就業外）となる。そして、トークン管理部２２は、この新たなチケット情報に対応するトークン（例えば、“20140216181222302-02”）を生成し、生成したトークンと新たなチケット情報とを関連付けてトークン管理テーブルを更新する。
【０１０３】
なお、トークン管理部２２はトークンを生成した場合、トークンを生成したことを示すフラグ（トークン生成フラグ）をtrueに設定する。
【０１０４】
更に中継部２１は、トークン管理部２２からトークンを受け取った場合、受け取ったトークン及び情報要求電文をアクセス判定部２３へ中継する。
【０１０５】
アクセス判定部２３は、情報管理サーバ２０で管理するリソース毎に認可ポリシーを規定した認可ポリシーテーブルを有し、認可ポリシーを満たす情報要求電文のみリソースへのアクセスを許可する。
【０１０６】
図１１は、アクセス判定部２３が有する認可ポリシーテーブルの一例を示した図である。
【０１０７】
図１１に示すように、認可ポリシーテーブルは、リソースの保管場所を示すリソースＵＲＬと、対応するリソースＵＲＬへアクセスするために必要な端末１０のチケットの状態を示すチケット情報と、を含む。そして、認可ポリシーテーブルは、例えば、“http://foo.bar.com:8080/baz1”で表されるリソースにアクセスするためには、端末１０のチケット情報が（場所、ユーザ権限、ユーザ状態）＝（校内、教師、就業中）であることが必要であることを表している。なお、認可ポリシーテーブルは、情報管理サーバ２０の管理者等により予め設定されるテーブルである。
【０１０８】
また、アクセス判定部２３は、トークンとリソースＵＲＬとの組み合わせに対する、リソースＵＲＬへのアクセス許可結果の履歴が記録された判定結果テーブルを有する。図１２は判定結果テーブルの一例を示した図である。
【０１０９】
図１２の判定結果テーブルの例では、トークン“20140214181020300-01”であれば、リソースＵＲＬ“http://foo.bar.com:8080/baz1”へのアクセスを許可したが、トークン“20140216181222302-02”ではアクセスを許可しなかった履歴が記録されている。
【０１１０】
アクセス判定部２３は、中継部２１から通知された情報要求電文から、端末１０が要求するリソースのリソースＵＲＬを取得し、取得したリソースＵＲＬと、情報要求電文と共に中継部２１から通知されたトークンと、の組み合わせ（判定キー）を作成する。そして、アクセス判定部２３は、判定結果テーブルに判定キーが存在するか否かを判定し、判定キーが存在する場合には、判定結果テーブルから判定キーに対応する判定結果を取得して中継部２１へ通知する。
【０１１１】
一方、判定結果テーブルに判定キーが存在しない場合には、アクセス判定部２３はトークン管理部２２に対してトークンを通知する。アクセス判定部２３からトークンを受け取ったトークン管理部２２は、トークン管理テーブルを参照して受け取ったトークンに対応するチケット情報をアクセス判定部２３へ通知する。アクセス判定部２３は認可ポリシーテーブルを参照し、トークン管理部２２から受け取ったチケット情報で取得したリソースＵＲＬへアクセス可能か判定する。そして、アクセス判定部２３は、判定結果を中継部２１へ通知すると共に、判定キー及び判定結果を関連付けて判定結果テーブルに追加する。
【０１１２】
中継部２１は、アクセス判定部２３から通知される判定結果が“許可”である場合にのみ、情報要求電文で指定されるリソースサーバ４０へ情報要求電文を送信する。
【０１１３】
情報要求電文を転送されたリソースサーバ４０は、要求されたリソースを含んだ応答を情報管理サーバ２０へ送信する。
【０１１４】
中継部２１は、リソースサーバ４０から応答を受信した際、トークン管理部２２へトークンが更新されたか否かを問い合わせる。トークン管理部２２では、トークン生成フラグを参照し、トークン生成フラグがtrueであればトークンが更新された旨を中継部２１へ通知し、トークン生成フラグがfalseであればトークンが更新されていない旨を中継部２１へ通知する。この際、トークン管理部２２は、トークン生成フラグがtrueであれば、更新されたトークンを中継部２１へ提供すると共に、トークン生成フラグをfalseに戻す。
【０１１５】
そして、中継部２１は、トークン管理部２２から更新されたトークンを受け取った場合、更新されたトークンをリソースサーバ４０から受信した応答のヘッダに追加して、情報要求電文の送信元である端末１０の端末プロキシ５０へ中継する。
【０１１６】
図１３は、更新されたトークンが付加された応答の一例を示した図である。
【０１１７】
図１３に示すように、更新されたトークンは“X-New-Token:”に続く文字列としてヘッダに付加される。なお、<html>から</html>までの領域に、リソースサーバ４０で取得されたリソースの情報が記載される。
【０１１８】
以上に説明した端末１０は、例えば、図１４に示すコンピュータ１００で実現することができる。コンピュータ１００は、ＣＰＵ１０２、メモリ１０４、不揮発性の記憶部１０６、及び通信ＩＦ（Interface）１０８を含み、これらはバス１１０を介して互いに接続される。
【０１１９】
また、記憶部１０６はＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等によって実現できる。記憶媒体としての記憶部１０６には、コンピュータ１００を端末１０として機能させるための端末プログラム１２０及びアプリケーションプログラム１２９が記憶されている。ＣＰＵ１０２は、端末プログラム１２０を記憶部１０６から読み出してメモリ１０４に展開し、端末プログラム１２０に含まれる各種プロセスを順次実行する。また、通信ＩＦ１０８は通信回線３０と接続され、情報管理サーバ２０との間でデータの送受信を行う。また、ＣＰＵ１０２は、アプリケーションプログラム１２９を記憶部１０６から読み出してメモリ１０４に展開し、アプリケーションプログラム１２９を実行する。これにより、端末１０上で、アプリケーション６０が実行される。
【０１２０】
そして、端末プログラム１２０は、取得プロセス１２１、チケット管理プロセス１２２、トークン管理プロセス１２３、付加プロセス１２４、監視プロセス１２５、中継プロセス１２６、及び抽出プロセス１２７を含む。
【０１２１】
ＣＰＵ１０２は、取得プロセス１２１を実行することで、図７に示す取得部５１として動作する。また、ＣＰＵ１０２は、チケット管理プロセス１２２を実行することで、図７に示すチケット管理部５２として動作する。また、ＣＰＵ１０２は、トークン管理プロセス１２３を実行することで、図７に示すトークン管理部５３として動作する。また、ＣＰＵ１０２は、付加プロセス１２４を実行することで、図７に示す付加部５４として動作する。また、ＣＰＵ１０２は、監視プロセス１２５を実行することで、図７に示す監視部５５として動作する。また、ＣＰＵ１０２は、中継プロセス１２６を実行することで、図７に示す中継部５６として動作する。また、ＣＰＵ１０２は、抽出プロセス１２７を実行することで、図７に示す抽出部５７として動作する。
【０１２２】
以上により、端末プログラム１２０及びアプリケーションプログラム１２９を実行したコンピュータ１００が、端末１０として動作する。なお、端末１０は、例えば半導体集積回路、より詳しくはＡＳＩＣ（Application Specific Integrated Circuit)等で実現することも可能である。
【０１２３】
一方、情報管理サーバ２０は、例えば、図１５に示すコンピュータ２００で実現することができる。コンピュータ２００は、ＣＰＵ２０２、メモリ２０４、不揮発性の記憶部２０６、及び通信ＩＦ２０８を含み、これらはバス２１０を介して互いに接続される。
【０１２４】
また、記憶部２０６はＨＤＤ又はフラッシュメモリ等によって実現できる。記憶媒体としての記憶部２０６には、コンピュータ２００を情報管理サーバ２０として機能させるためのアクセス制御プログラム２２０が記憶されている。ＣＰＵ２０２は、アクセス制御プログラム２２０を記憶部２０６から読み出してメモリ２０４に展開し、アクセス制御プログラム２２０に含まれる各種プロセスを順次実行する。また、通信ＩＦ２０８は通信回線３０と接続され、端末１０及びリソースサーバ４０との間でデータの送受信を行う。
【０１２５】
アクセス制御プログラム２２０は、中継プロセス２２１、トークン管理プロセス２２２、及びアクセス判定プロセス２２３を含む。
【０１２６】
ＣＰＵ２０２は、中継プロセス２２１を実行することで、図７に示す中継部２１として動作する。また、ＣＰＵ２０２は、トークン管理プロセス２２２を実行することで、図７に示すトークン管理部２２として動作する。また、ＣＰＵ２０２は、アクセス判定プロセス２２３を実行することで、図７に示すアクセス判定部２３として動作する。
【０１２７】
以上により、アクセス制御プログラム２２０を実行したコンピュータ２００が、情報管理サーバ２０として動作する。
【０１２８】
なお、一例として、ＣＰＵ２０２にはリアルタイムクロックが内蔵され、アクセス制御プログラム２２０からの要求により現在の時刻情報を提供するカレンダ機能を有するものとする。また、端末１０と同様に、情報管理サーバ２０も例えば半導体集積回路、より詳しくはＡＳＩＣ等で実現することが可能である。
【０１２９】
次に、本実施形態に係る端末１０の作用及び情報管理サーバ２０の作用を説明する。
【０１３０】
本実施形態に係る端末１０は、アプリケーション６０から情報要求電文を受信した際に図１６に示す情報要求電文中継処理を実行する。
【０１３１】
まず、ステップＳ１０では、中継部５６はトークン更新中フラグの状態を監視部５５に要求し、トークン更新中フラグがtrueか否かを判定する。肯定判定の場合にはステップＳ９０へ移行し、中継部５６は受信した情報要求電文を情報管理サーバ２０へ送信せずにキューに保留して情報要求電文中継処理を終了する。一方、ステップＳ１０の処理で否定判定となった場合には、ステップＳ２０へ移行する。
【０１３２】
ステップＳ２０では、中継部５６は、付加部５４に対して情報要求電文のヘッダにチケットを付加するように要求する。この際、付加部５４は、チケット管理部５２に対してチケットを要求し、チケット管理部５２はチケット管理テーブルの更新フラグ欄がtrueとなっているチケットを付加部５４へ通知する。これにより、付加部５４は、状態変化チケットを取得する。
【０１３３】
ステップＳ３０では、チケット管理部５２は、ステップＳ２０の処理で付加部５４へ通知したチケットに対応するチケット管理テーブルの更新フラグをfalseに設定し、チケット管理テーブルの内容を更新する。
【０１３４】
ステップＳ４０では、中継部５６は、更に付加部５４に対して情報要求電文のヘッダにトークンを付加するように要求する。この際、付加部５４は、トークン管理部５３に対してトークンを要求し、トークン管理部５３は保管しているトークンを付加部５４へ通知する。これにより、付加部５４は、トークンを取得する。
【０１３５】
ステップＳ５０では、付加部５４は、ステップＳ２０の処理で取得したチケットと、ステップＳ４０の処理で取得したトークンと、を情報要求電文のヘッダへ付加する。この際、付加部５４は、チケットがチケット管理部５２から通知されなかった場合には、ヘッダへのチケットの付加を行わない。また、付加部５４は、トークンがトークン管理部５３から通知されなかった場合には、ヘッダへのトークンの付加を行わない。
【０１３６】
なお、本実施形態ではトークンが存在しない場合、各チケットに対応するチケット管理テーブルの更新フラグはtrueに設定される。また、各チケットに対応するチケット管理テーブルの更新フラグが全てfalseの場合には、各チケットの状態に対応したトークンが存在する。
【０１３７】
ステップＳ６０では、監視部５５は、情報要求電文のヘッダにチケットが付加されているか否かを判定する。具体的には、監視部５５は、ヘッダに含まれる“X-Ticket-Num:”が“０”であれば、ヘッダにチケットが付加されていないと判定し、“X-Ticket-Num:”が“１”以上であれば、ヘッダにチケットが付加されていると判定する。そして、ステップＳ６０の判定処理が肯定判定の場合にはステップＳ７０へ移行し、否定判定の場合には、ステップＳ７０の処理を省略してステップＳ８０へ移行する。
【０１３８】
ステップＳ７０では、トークンで表されるチケットの状態が実際の端末１０におけるチケットの状態と異なるため、監視部５５はメモリ１０４の予め定めた領域に記憶されるトークン更新中フラグをtrueに設定する。これにより、情報管理サーバ２０へトークンの更新を依頼中であることを記憶する。
【０１３９】
ステップＳ８０では、中継部５６は、トークン及びチケットの少なくとも一方が付加された情報要求電文を、情報管理サーバ２０へ送信して、情報要求電文中継処理を終了する。
【０１４０】
本実施形態に係る情報管理サーバ２０は、端末１０から情報要求電文を受信した際に図１７に示す応答処理を実行する。なお、認可ポリシーテーブル、トークン管理テーブル、及び判定結果テーブルは記憶部２０６に予め記憶され、ＣＰＵ２０２がアクセス制御プログラム２２０をメモリ２０４に展開する際に、メモリ２０４の予め定めた領域に展開される。
【０１４１】
まず、ステップＳ２００では、中継部２１は受信した情報要求電文をトークン管理部２２へ通知する。そして、トークン管理部２２は通知された情報要求電文のヘッダを例えばメモリ２０４の予め定めた領域に記憶する。
【０１４２】
ステップＳ２１０では、トークン管理部２２は、ステップＳ２００で取得したヘッダに含まれるトークン及びチケットの組み合わせからトークンを更新する必要があるか否かを判定し、当該判定に基づいてトークンを更新するトークン更新処理を実行する。
【０１４３】
図１８は、ステップＳ２１０で実行されるトークン更新処理のフローチャートである。
【０１４４】
まず、ステップＳ４００では、トークン管理部２２は、ヘッダに含まれる“X-Token:”の項目にトークンが存在するか否かを判定し、否定判定の場合にはステップＳ４１０へ移行する。
【０１４５】
そして、ステップＳ４１０では、トークン管理部２２は、更にヘッダに含まれる“X-Ticket-Num:”の項目を参照することにより、ヘッダにチケットが存在するか否かを判定する。そして、否定判定の場合、すなわち“X-Ticket-Num:”が“０”の場合には、ヘッダにはチケットが存在しないと判定してステップＳ４２０へ移行する。一方、肯定判定の場合、すなわち“X-Ticket-Num:”が“１”以上の場合には、ヘッダにチケットが存在すると判定してステップＳ４３０へ移行する。
【０１４６】
ステップＳ４２０では、中継部２１から通知されたヘッダがトークンもチケットも含まれない不正なヘッダであることから、トークン管理部２２はエラー情報を生成して中継部２１へ通知し、トークン更新処理を終了する。
【０１４７】
ステップＳ４３０では、トークン管理部２２は、例えばＣＰＵ２０２に時刻情報を要求して現在の時刻を取得し、取得した時刻からトークンを生成する。この際、トークン管理部２２は、メモリ２０４の予め定めた領域に記憶されるトークン生成フラグをtrueに設定する。
【０１４８】
ステップＳ４４０では、トークン管理部２２はステップＳ４３０で生成したトークンと、ヘッダ内に含まれるチケットと、の組み合わせを、メモリ２０４の予め定めた領域に展開されるトークン管理テーブルに記録する。そして、ステップＳ４５０では、トークン管理部２２は、ステップＳ４３０で生成したトークンを中継部２１へ通知して、トークン更新処理を終了する。
【０１４９】
一方、ステップＳ４００の処理で、ヘッダにトークンが含まれると判定された場合には、ステップＳ４６０へ移行する。
【０１５０】
ステップＳ４６０では、トークン管理部２２は、ヘッダに含まれる“X-Token:”の項目に記載されているトークンを取得し、トークン管理テーブルのトークン欄に、取得したトークンと一致するトークンが登録されているか否かを判定する。そして、否定判定の場合にはステップＳ４７０へ移行し、肯定判定の場合にはステップＳ４８０へ移行する。
【０１５１】
ステップＳ４７０では、端末１０からトークン管理テーブルに登録されていない不正なトークンが送信されたものとして、トークン管理部２２はエラー情報を生成して中継部２１へ通知し、トークン更新処理を終了する。
【０１５２】
ステップＳ４８０では、既に説明したステップＳ４１０と同様の処理を実行して、ヘッダにチケットが存在するか否かを判定する。そして否定判定の場合にはステップＳ４９０へ移行する。
【０１５３】
ステップＳ４９０では、トークン管理部２２は、ステップＳ４６０の処理で取得したトークンを中継部２１へ通知して、トークン更新処理を終了する。この場合、トークン管理部２２は新たにトークンを生成していないため、トークン管理テーブルの内容を更新しない。
【０１５４】
一方、ステップＳ４８０の処理でヘッダにチケットが含まれると判定された場合には、ステップＳ５００へ移行する。
【０１５５】
ステップＳ５００では、既に説明したステップＳ４３０と同様の処理を実行して新たなトークンを生成する。この際、トークン管理部２２は、メモリ２０４の予め定めた領域に記憶されるトークン生成フラグをtrueに設定する。
【０１５６】
ステップＳ５１０では、トークン管理部２２はトークン管理テーブルを参照して、ステップＳ４６０で取得したトークンに対応するチケット情報を取得する。そして、トークン管理部２２は、取得したチケット情報に含まれるチケットをヘッダ内に含まれるチケットで置き換えた新たなチケット情報と、ステップＳ５００で生成したトークンと、の組み合わせをトークン管理テーブルに追加する。そして、ステップＳ５２０では、トークン管理部２２は、ステップＳ５００で生成したトークンを中継部２１へ通知して、トークン更新処理を終了する。
【０１５７】
以上の処理により、図１７のステップＳ２１０におけるトークン更新処理が終了する。
【０１５８】
次に、ステップＳ２２０では、中継部２１は、トークン管理部２２からステップＳ２１０の処理で実行されたトークン更新処理の更新結果を取得し、更新結果がエラーか否かを判定する。ここで、更新結果がエラーとは、図１８のステップＳ４２０及びステップＳ４７０の処理によりエラー情報が通知された場合をいう。
【０１５９】
そして、ステップＳ２２０の判定が肯定判定の場合はステップＳ３１０へ移行し、ステップＳ３１０では、中継部２１は情報要求電文によって要求されるリソースへのアクセスを拒否する応答を作成する。そして、ステップＳ３２０では、中継部２１は応答を情報要求電文の送信元である端末１０へ送信する。
【０１６０】
すなわち、ステップＳ２２０でのトークン更新処理の更新結果がエラーである場合には、端末１０から受信した情報要求電文はリソースサーバ４０へ中継されることなく、端末１０へ情報管理サーバ２０で作成したエラーを示す応答が返送されることになる。
【０１６１】
一方、ステップＳ２２０での判定が否定判定の場合、すなわち、トークン更新処理の更新結果としてトークンが通知された場合には、ステップＳ２３０へ移行する。
【０１６２】
ステップＳ２３０では、中継部２１は、ステップＳ２１０での処理の更新結果として取得したトークン及び端末１０から受信した情報要求電文を、アクセス判定部２３へ通知する。アクセス判定部２３は、情報要求電文から端末１０が要求するリソースのリソースＵＲＬを取得して、中継部２１から通知されたトークン及びリソースＵＲＬの組み合わせである判定キーを作成する。そして、アクセス判定部２３は、メモリ２０４の予め定めた領域に記憶された判定結果テーブルから、判定キーと一致するトークン及びリソースＵＲＬの組み合わせを検索する。
【０１６３】
ステップＳ２４０では、アクセス判定部２３は、ステップＳ２３０での検索処理の結果に基づいて、判定キーと一致するトークン及びリソースＵＲＬの組み合わせが存在しない場合にはステップＳ２５０へ移行する。一方、判定キーと一致するトークン及びリソースＵＲＬの組み合わせが存在する場合には、アクセス判定部２３は、判定キーと一致するトークン及びリソースＵＲＬ記載行の判定結果を中継部２１へ通知する。そして、ステップＳ２５０の処理を省略してステップＳ２６０へ移行する。
【０１６４】
なお、ステップＳ２１０での処理の更新結果として取得したトークンが新たに生成されたトークンであれば、まだアクセス判定部２３で当該トークンを用いてリソースへのアクセスが可能か否か判定されたことがない。従って、この場合にはステップＳ２４０の判定処理は否定判定となる。
【０１６５】
ステップＳ２５０では、アクセス判定部２３はステップＳ２１０での処理の更新結果として取得したトークンが示すチケット情報を把握していないため、当該トークンをトークン管理部２２へ通知して、トークンが示すチケット情報を問い合わせる。トークン管理部２２はトークン管理テーブルを参照して、アクセス判定部２３から受け取ったトークンに対応するチケット情報をアクセス判定部２３へ通知する。
【０１６６】
そして、アクセス判定部２３は、認可ポリシーテーブルを参照して、トークン管理部２２から受け取ったチケット情報で、ステップＳ２３０の処理で取得したリソースＵＲＬへアクセス可能か判定する。そして、アクセス可能か否かの判定結果を中継部２１へ通知する。この際、アクセス判定部２３は、ステップＳ２１０での処理の更新結果として取得したトークン、ステップＳ２３０の処理で取得したリソースＵＲＬ、及び当該リソースＵＲＬにアクセス可能か否かを示した判定結果を対応付けて、判定結果テーブルに追加する。
【０１６７】
ステップＳ２６０では、中継部２１は、ステップＳ２４０の処理によってアクセス判定部２３から通知される判定結果、又は、ステップＳ２５０の処理によってアクセス判定部２３から通知される判定結果が「許可」であるか否かを判定する。
【０１６８】
そして、肯定判定の場合、すなわちアクセス判定部２３によりリソースＵＲＬで示されるリソースへのアクセスが許可された場合にはステップＳ２７０へ移行する。一方、否定判定の場合には、ステップＳ３１０へ移行し、中継部２１により情報要求電文によって要求されるリソースへのアクセスを拒否する応答が作成される。
【０１６９】
ステップＳ２７０では、中継部２１は、端末１０から受信した情報要求電文を、情報要求電文に含まれるリソースＵＲＬで示されるサーバ、例えばリソースサーバ４０へ送信する。
【０１７０】
ステップＳ２８０では、中継部２１は、リソースサーバ４０からの応答を受信したか否かを判定し、応答を受信するまでステップＳ２８０の処理を実行する。
【０１７１】
リソースサーバ４０から応答を受信した後、ステップＳ２９０では、中継部２１はトークン管理部２２へトークン生成フラグの値を問い合わせ、トークン生成フラグがtrueか否かを判定する。そして、否定判定の場合にはステップＳ３００へ移行し、肯定判定の場合にはステップＳ３００の処理を省略してステップＳ３２０へ移行する。
【０１７２】
ステップＳ３００では、中継部２１は、トークン生成フラグの値と共にトークン管理部２２から提供される更新されたトークンを、ステップＳ２８０の処理で受信した応答に付加する。
【０１７３】
そして、既に説明したようにステップＳ３２０では、中継部２１は応答を情報要求電文の送信元である端末１０へ送信する。
【０１７４】
以上の処理により、情報管理サーバ２０で実行される応答処理が終了する。
【０１７５】
そして、本実施形態に係る端末１０は、情報管理サーバ２０から応答を受信した際に図１９に示す保留電文中継処理を実行する。
【０１７６】
まず、ステップＳ６００では、中継部５６は受信した応答を監視部５５及び抽出部５７へ転送する。そして抽出部５７は応答にトークンが含まれているか否かを判定し、肯定判定の場合にはステップＳ６１０へ移行し、否定判定の場合はステップＳ６３０へ移行する。
【０１７７】
ステップＳ６１０では、抽出部５７はステップＳ６００の処理で受け取った応答からトークンを抽出し、抽出したトークンをトークン管理部５３へ通知する。トークン管理部５３は、抽出部５７から通知されたトークンをメモリ１０４の予め定めた領域に保管する。この際、既に保管されているトークンがメモリ１０４に存在する場合、トークン管理部５３はトークンを上書き保存する。これにより、トークン管理部５３が管理するトークンは、情報管理サーバ２０が生成した最も新しいトークンであることが担保される。
【０１７８】
次に、ステップＳ６２０では、監視部５５はステップＳ６００の処理で受け取った応答にトークンが含まれることを確認して、トークン更新中フラグをfalseに設定する。
【０１７９】
ステップＳ６３０では、中継部５６は受信した応答を、応答に対応した情報要求電文の送信元のアプリケーション６０へ送信する。
【０１８０】
ステップＳ６４０では、中継部５６は、図１６のステップＳ９０の処理によってキューに保留された情報要求電文が存在するか否かを判定する。否定判定の場合、すなわちキューに情報要求電文が保留されていない場合には保留電文中継処理を終了する。一方、肯定判定の場合にはステップＳ６５０へ移行する。
【０１８１】
ステップＳ６５０では、中継部５６はトークン更新中フラグの状態を監視部５５に要求し、トークン更新中フラグがtrueか否かを判定する。そして、肯定判定の場合には保留電文中継処理を終了する。一方、否定判定の場合にはステップＳ６６０へ移行し、中継部５６はキューから情報要求電文を１つ取り出し、取り出した情報要求電文に対して図１６を用いて説明した情報要求電文中継処理を実行する。
【０１８２】
そして、中継部５６はステップＳ６４０〜Ｓ６６０の処理を繰り返し実行することで、トークン更新中フラグがfalseの間、キーに保留される情報要求電文に対する応答を待つことなく、情報要求電文を情報管理サーバ２０へ順次送信する。
【０１８３】
このように本実施形態における端末１０は、チケットを付加した情報要求電文を情報管理サーバ２０へ送信してから当該情報要求電文に対する更新されたトークンが戻ってくるまでのトークンの更新期間中に受信した情報要求電文を、キューに保留する。従って、トークンの更新期間中にアプリケーション６０から複数の新たな情報要求電文を受信した場合であっても、トークンの更新期間中にチケットを付加した情報要求電文を送信するのは１回に抑えられる。すなわち、トークンの更新期間中であってもアプリケーション６０から情報要求電文を受信する毎に情報要求電文を情報管理サーバ２０へ送信する場合と比較して、端末１０の通信負荷を低減することができる。
【０１８４】
また、本実施形態における端末１０は、トークンの更新期間終了後、かつトークン更新フラグがfalseの間は、保留した情報要求電文を、他の情報要求電文に対する応答を待つことなく順次情報管理サーバ２０へ送信する。従って、前に送信した情報要求電文の応答を待ってから、保留した次の情報要求電文を送信する場合と比較して、アプリケーション６０におけて画面表示に必要なリソースの取得に要する時間が短縮され、アプリケーション６０の操作性が向上する。
【０１８５】
（第２実施形態）
【０１８６】
次に、開示の技術の第２実施形態について説明する。なお、第１実施形態と同一の部分には同一の符号を付して説明を省略し、第１実施形態と異なる部分を中心に説明する。
【０１８７】
第１実施形態の端末１０は、トークンの更新期間中にアプリケーション６０から新たに受信した情報要求電文を全てキューに保留するようにした。
【０１８８】
しかしながら、トークンの更新期間中に受信した情報要求電文を保留せずに情報管理サーバ２０へ送信した方が、アプリケーション６０の操作性はより向上する。従って、第２実施形態における端末は、トークンの更新期間中に受信した情報要求電文にチケットを付加して情報管理サーバ２０へ送信しても、通信負荷が予め定めた許容範囲内に収まるのであれば、情報要求電文を保留せずに情報管理サーバへ送信するようにする。
【０１８９】
図２０は、第２実施形態に係る端末１０Ａ及び情報管理サーバ２０Ａを含むシステム１４を示した図である。第１実施形態の図７の説明と同じく、複数の端末１０Ａが通信回線３０に接続されていてもよいが、説明を簡略化するため、図２０では１台の端末１０Ａを図示している。
【０１９０】
端末１０Ａが第１実施形態に係る端末１０と異なる点は、端末プロキシ５０Ａに新たに保留判定部５８が追加されると共に、中継部５６が中継部５６Ａ、チケット管理部５２がチケット管理部５２Ａにそれぞれ置き換えられた点である。
【０１９１】
保留判定部５８は、チケット管理部５２Ａ及び中継部５６Ａと接続され、トークンの更新期間中に受信したアプリケーション６０からの情報要求電文をキューに保留するか否かを判定する。具体的には、保留判定部５８は、情報要求電文に付加されるチケット数が予め定めたチケット数（規定チケット数）以下であれば、情報要求電文をキューに保留せず情報管理サーバ２０Ａへ送信するように判定する。ここで、規定チケット数とは、情報要求電文にチケットを付加したとしても、端末１０Ａの通信負荷が予め定めた許容範囲内に収まるチケット数をいう。
【０１９２】
なお、保留判定部５８は、トークンの更新期間中に受信した情報要求電文に付加されるチケット数を、チケット管理部５２Ａに問い合わせることで取得する。
【０１９３】
そして、中継部５６Ａは、トークンの更新期間中に情報要求電文を受信した際、保留判定部５８に受信した情報要求電文をキューに保留するか問い合わせ、その判定結果に従って情報要求電文の取り扱いを決定する。
【０１９４】
一方、情報管理サーバ２０Ａが第１実施形態に係る情報管理サーバ２０と異なる点は、トークン管理部２２がトークン管理部２２Ａに置き換えられた点である。
【０１９５】
以下、端末１０Ａに対して第１実施形態に係る情報管理サーバ２０を用いた場合の問題点について説明する。
【０１９６】
図２１は、端末１０Ａ及び情報管理サーバ２０を用いた場合のトークンの更新状況を示した図である。
【０１９７】
端末１０Ａは、（場所、ユーザ権限、ユーザ状態）＝（校内、教師、就業中）のチケット情報を示すトークン１を所有しているとする。この際、場所を表すチケットの状態が“校内”から“自宅”に変化した後にアプリケーション６０から情報要求電文１を受信すると、中継部５６Ａはトークン１及び（場所＝自宅）のチケットを情報要求電文１に付加して情報管理サーバ２０へ送信する。
【０１９８】
そして、情報要求電文１に対するトークンの更新期間中に、端末１０Ａにおいてユーザ状態を表すチケットの状態が“就業中”から“就業外”へ変化した後、中継部５６Ａがアプリケーション６０から情報要求電文２を受信したとする。この際、保留判定部５８において情報要求電文２を保留する必要がないと判定されると、中継部５６Ａは、更新前のトークンであるトークン１及び（ユーザ状態＝就業外）のチケットを情報要求電文２に付加して情報管理サーバ２０へ送信する。
【０１９９】
一方、情報管理サーバ２０では、情報要求電文１に対してチケット情報が（場所、ユーザ権限、ユーザ状態）＝（自宅、教師、就業中）を示すトークン２を生成して端末１０Ａへ送信する。更に、情報管理サーバ２０は、情報要求電文２に対してチケット情報が（場所、ユーザ権限、ユーザ状態）＝（校内、教師、就業外）を示すトークン３を生成して端末１０Ａへ送信する。
【０２００】
従って、トークン３が示すチケット情報の認識が端末１０Ａと情報管理サーバ２０との間で食い違うことになる。すなわち、端末１０Ａでは、トークン３は端末１０Ａの現在のチケット情報である（場所、ユーザ権限、ユーザ状態）＝（自宅、教師、就業外）を示すトークンとして利用される。しかし、情報管理サーバ２０では、トークン３は（場所、ユーザ権限、ユーザ状態）＝（校内、教師、就業外）のチケット情報を示すトークンであると認識されることになる。
【０２０１】
このようなチケット情報に関する食い違いの問題を解決するため、トークン管理部２２Ａでは、トークン管理テーブルの他、更にチケット更新管理テーブルを用いてトークンの管理を行う。
【０２０２】
図２２は、チケット更新管理テーブルの一例を示した図である。チケット更新管理テーブルは各端末におけるセッションを一意に表すセッションＩＤ、チケット更新管理テーブルの更新時刻、及びトークンの生成を伴う情報要求電文に付加されていたチケットを表す更新チケット情報を含むテーブルである。ここでセッションとは、端末１０Ａにおけるチケット情報の一連の変化を表す単位である。
【０２０３】
また、図２３は、トークン管理部２２Ａで用いられるトークン管理テーブルの一例を示した図である。図２３に示すように、第２実施形態に係るトークン管理テーブルは、図１０に示した第１実施形態に係るトークン管理テーブルにセッションＩＤ欄を追加したものである。
【０２０４】
トークン管理部２２Ａは、端末１０Ａから初めてトークンの更新を依頼された際、すなわち、トークンがなくチケットのみが付加された情報要求電文を受け付けた際、一連のセッションが発生したとみなして当該セッションを一意に示すセッションＩＤを生成する。そして、セッションＩＤ及び情報要求電文に付加されるチケットを、更新時刻と共にチケット更新管理テーブルに記録する。なお、セッションＩＤとしては各端末１０Ａにおける各セッションを一意に示す値であればどのようなものを用いてもよい。
【０２０５】
そして、トークン管理部２２Ａは、生成したトークンとトークンに対応したチケット情報とを、セッションＩＤと共にトークン管理テーブルに記録する。
【０２０６】
以降、トークン管理部２２Ａは、セッション継続中にトークン及びチケットが付加された情報要求電文を受け付ける毎に、トークン管理テーブルを参照してトークンに対応するセッションＩＤを取得する。そして、トークン管理部２２Ａはチケット更新管理テーブルに対して、取得したセッションＩＤ及び更新時刻と共に、情報要求電文に付加されるチケットのチケット名をチケット種別毎に記録する。この際、トークン管理部２２Ａは、情報要求電文に付加されていないチケットのチケット種別については、対応する欄に例えば記号“−”を記録する。
【０２０７】
そして、トークン管理部２２Ａは、チケット更新管理テーブルから取得したセッションＩＤと同じセッションＩＤを有するチケット更新記録を全て抽出し、抽出したチケット更新記録を更新時刻に基づいて時系列に配置する。そして、トークン管理部２２Ａは、時系列に配置したチケット更新記録を古いものから新しいものに順に読み込み、チケット種別毎にチケット名の変化の過程を追って端末１０Ａにおける最新のチケット情報を取得する。
【０２０８】
例えば、図２２の例では、当初、チケット種別が場所であるチケット名は“校内”であったが、その後“自宅”に変化している。また、チケット種別がユーザ状態のチケット名も“就業中”から“就業外”に変化している。従って、図２２に示すトークン更新管理テーブルの例から、更新時刻が2014/2/14 18:10:20.100における最新のチケット情報は、（場所、ユーザ権限、ユーザ状態）＝（自宅、教師、就業外）と判断される。すなわち、端末１０Ａが図２１で説明したトークンの更新期間中に情報要求電文２を送信した場合であっても、情報管理サーバ２０Ａにおいてトークンとチケット情報が正しく対応づけられる。
【０２０９】
以上に説明した端末１０Ａは、例えば、図２４に示すコンピュータ１００Ａで実現することができる。
【０２１０】
記憶媒体としての記憶部１０６には、コンピュータ１００Ａを端末１０Ａとして機能させるための端末プログラム１２０Ａ及びアプリケーションプログラム１２９が記憶されている。端末プログラム１２０Ａが第１実施形態に係る端末プログラム１２０と異なる点は、保留判定プロセス１２８を含み、チケット管理プロセス１２２がチケット管理プロセス１２２Ａ、中継プロセス１２６が中継プロセス１２６Ａに置き換えられた点である。ＣＰＵ１０２は、チケット管理プロセス１２２Ａを実行することで、図２０に示すチケット管理部５２Ａとして動作する。また、ＣＰＵ１０２は、中継プロセス１２６Ａを実行することで、図２０に示す中継部５６Ａとして動作する。また、ＣＰＵ１０２は、保留判定プロセス１２８を実行することで、図２０に示す保留判定部５８として動作する。
【０２１１】
以上により、端末プログラム１２０Ａ及びアプリケーションプログラム１２９を実行したコンピュータ１００Ａが、端末１０Ａとして動作する。
【０２１２】
一方、情報管理サーバ２０Ａは、例えば、図２５に示すコンピュータ２００Ａで実現することができる。
【０２１３】
記憶媒体としての記憶部２０６には、コンピュータ２００Ａを情報管理サーバ２０Ａとして機能させるためのアクセス制御プログラム２２０Ａが記憶されている。アクセス制御プログラム２２０Ａが第１実施形態に係るアクセス制御プログラム２２０と異なる点は、トークン管理プロセス２２２がトークン管理プロセス２２２Ａに置き換えられた点である。ＣＰＵ２０２は、トークン管理プロセス２２２Ａを実行することで、図２０に示すトークン管理部２２Ａとして動作する。
【０２１４】
以上により、アクセス制御プログラム２２０Ａを実行したコンピュータ２００Ａが、情報管理サーバ２０Ａとして動作する。
【０２１５】
なお、端末１０Ａ及び情報管理サーバ２０Ａも、例えば半導体集積回路、より詳しくはＡＳＩＣ等で実現することも可能である。
【０２１６】
次に、端末１０Ａの作用及び情報管理サーバ２０Ａの作用を説明する。端末１０Ａは、アプリケーション６０から情報要求電文を受信した際に図２６に示す情報要求電文中継処理を実行する。
【０２１７】
図２６に示す情報要求電文中継処理が図１６に示した第１実施形態に係る情報要求電文中継処理と異なる点は、ステップＳ８５が追加された点である。その他の各ステップにおける処理は第１実施形態と同様であるため、説明を省略する。
【０２１８】
ステップＳ１０で否定判定されると、ステップＳ８５へ移行し、中継部５６Ａは情報要求電文をキューに保留する必要があるか否か判定する。具体的には、中継部５６Ａは受信した情報要求電文をキューに保留すべきか保留判定部５８に問い合わせる。この問い合わせに対して、保留判定部５８はチケット管理部５２Ａへ状態変化チケットの数を問い合わせる。そして、チケット管理部５２Ａはチケット管理テーブルを参照して、更新フラグがtrueとなっているチケットの数を保留判定部５８へ通知する。
【０２１９】
保留判定部５８は状態変化チケットの数が予め定めた値Ｋ（Ｋは０以上の整数）以下であれば、情報要求電文を保留する必要はないとの判定結果を中継部５６Ａに通知する。一方、保留判定部５８は状態変化チケットの数が値Ｋを超える数であれば、情報要求電文を保留する必要があるとの判定結果を中継部５６Ａに通知する。
【０２２０】
そして、中継部５６Ａが保留判定部５８からの判定結果に基づき、情報要求電文を保留する必要があると判定した場合にはステップＳ９０へ移行し、情報要求電文をキューに保留する。一方、中継部５６Ａが保留判定部５８からの判定結果に基づき、情報要求電文を保留する必要はないと判定した場合にはステップＳ２０へ移行し、情報要求電文を情報管理サーバ２０Ａへ送信する。
【０２２１】
情報管理サーバ２０Ａは、端末１０Ａから情報要求電文を受信した際に図１７に示した応答処理を実行する。ただし、ステップＳ２１０におけるトークン更新処理が図２７に示すトークン更新処理に変更される。
【０２２２】
図２７に示すトークン更新処理が第１実施形態に係る図１８に示したトークン更新処理と異なる点は、ステップＳ４２２、Ｓ４２４、及びＳ４９５が追加された点である。その他の各ステップにおける処理は第１実施形態と同様であるため、説明を省略する。
【０２２３】
ステップＳ４１０で肯定判定されると、ステップＳ４２２へ移行し、トークン管理部２２Ａはセッションの開始にあたりセッションＩＤを生成する。なお、情報要求電文の送信元である端末１０Ａを判別するには、例えばアプリケーション６０が付加する情報要求電文の送信元情報等を用いればよい。
【０２２４】
ステップＳ４２４では、トークン管理部２２ＡはステップＳ４２２で生成したセッションＩＤと、情報要求電文に付加されるチケットと、を対応付けてチケット更新管理テーブルに更新時刻と共に追加する。
【０２２５】
なお、トークン管理部２２Ａは、ステップＳ４３０で情報要求電文に付加されるチケットを示すトークンを生成した後、ステップＳ４４０で図２３に示したトークン管理テーブルを更新する際、ステップＳ４２２で生成したセッションＩＤを併せて記録する。
【０２２６】
そして、トークン管理部２２Ａは、中継部２１からトークン及びチケットが付加された情報要求電文を受け取った場合には、ステップＳ４８０で肯定判定され、ステップＳ４９５へ移行する。
【０２２７】
ステップＳ４９５では、トークン管理部２２Ａはトークン管理テーブルを参照し、トークン管理テーブルのトークン欄に受け取ったトークンと一致するトークンが記録されている行を検索し、当該行のセッションＩＤを取得する。そして、トークン管理部２２Ａは、取得したセッションＩＤと、情報要求電文に付加されるチケットと、を対応づけてチケット更新管理テーブルに更新時間と共に追加する。
【０２２８】
そして、ステップＳ５１０では、トークン管理部２２Ａはチケット更新管理テーブルにおいてステップＳ４９５で取得したセッションＩＤを有するチケット更新記録を古い順に参照することで、端末１０Ａにおける最新のチケット情報を取得する。トークン管理部２２Ａは、本ステップで取得したチケット情報と、ステップＳ４９５で取得したセッションＩＤと、ステップＳ５００で生成したトークンと、を対応付けてトークン管理テーブルに追加する。
【０２２９】
以上の処理により、ステップＳ２１０のトークン更新処理が終了し、トークンとチケット情報が正しく対応づけられる。
【０２３０】
そして、本実施形態に係る端末１０Ａは、情報管理サーバ２０Ａから応答を受信した際に既に説明した図１９に示す保留電文中継処理を実行する。
【０２３１】
このように第２実施形態に係る情報管理サーバ２０Ａは、トークンの更新期間中に情報要求電文を受信した場合でも、端末１０Ａにおける各チケットの状態と正しく対応付けられたトークンを生成することができる。
【０２３２】
なお、保留判定部５８では、情報要求電文に付加されるチケット数に基づいてキューに保留するか否かを判定したが、端末１０Ａの通信負荷が予め定めた許容範囲内に収まるか否かを反映した、その他の保留判定基準を用いるようにしてもよい。
【０２３３】
例えば、情報要求電文に付加されるチケットのデータ量が、情報要求電文にチケットを付加しても、端末１０Ａの通信負荷が予め定めた許容範囲内に収まるようなデータ量以下であれば、情報要求電文をキューに保留せずに情報管理サーバ２０Ａへ送信してもよい。この場合、チケット管理部５２Ａは、チケット管理テーブルで各チケットのデータ量を管理するものとする。
【０２３４】
その他、保留判定部５８は、情報要求電文によって要求されるリソースの種別に応じて、情報要求電文をキューに保留するか否か判定するようにしてもよい。
【０２３５】
例えば、要求されるリソースの種別が動画であれば静止画に比べてデータ量が多いため、アプリケーション６０がリソースを要求してから実際に受信するまでの時間がかかる。従って、アプリケーション６０から要求されるリソースの種別が動画の場合には、保留判定部５８は、トークンの更新期間中であってもキューに保留せずに情報管理サーバ２０Ａへ送信する。これにより、アプリケーション６０で動画が表示されるまでの待ち時間が短縮され、アプリケーション６０の操作性が向上する。
【０２３６】
一方、要求されるリソースの種別が静止画であれば動画に比べてデータ量が少ないため、情報要求電文をキューに保留しても、動画ほどアプリケーション６０がリソースを要求してから実際に受信するまでの時間がかからないと考えられる。
【０２３７】
なお、情報要求電文により要求されるリソースの種別は、保留判定部５８が情報要求電文に含まれる当該リソースの拡張子（例えば、“.jpg”なら静止画、“.mpg”なら動画）を読み込むことで取得できる。
【０２３８】
（第３実施形態）
【０２３９】
次に、第２実施形態の変形例である第３実施形態について説明する。
【０２４０】
第３実施形態に係る端末の保留判定部は、情報要求電文の送信元であるアプリケーションを特定し、アプリケーションにおける単位時間あたりの情報要求電文の送信回数（送信頻度）に基づいて、情報要求電文をキューに保留するか否かを判定する。
【０２４１】
例えば、アプリケーションにおける情報要求電文の送信頻度が、端末の予め定めた通信負荷の許容範囲を超える負荷となる頻度（規定頻度）以上である場合を考える。この場合、アプリケーションからトークンの更新期間中に受信した情報要求電文を保留しなければ端末の通信負荷が増大する恐れがある。
【０２４２】
反対に、例えばアプリケーションにおける情報要求電文の送信頻度が規定頻度未満であるとする。この場合、アプリケーションからトークンの更新期間中に受信した情報要求電文を保留しなくても端末の通信負荷が増大する恐れは少ないと考えられる。
【０２４３】
従って、アプリケーション毎に情報要求処理の送信頻度を集計し、集計した送信頻度に基づいてトークンの更新期間中に受信した情報要求電文を保留するか否か判定することで、端末の通信負荷を低減することができる。
【０２４４】
図２８は第３実施形態に係る端末１０Ｂ及び情報管理サーバ２０Ａを含むシステム１６を示した図である。端末１０Ｂにおける端末プロキシ５０Ｂが第２実施形態の係る端末プロキシ５０Ａと異なる点は、保留判定部５８が保留判定部５８Ｂに置き換えられた点である。
【０２４５】
保留判定部５８Ｂは、アプリケーション６０毎に中継部５６Ａで受信する情報要求電文の送信頻度を集計して、送信頻度テーブルに記録する。図２９は、送信頻度テーブルの一例を示した図であり、アプリケーション名及び当該アプリケーションでの情報要求電文の送信頻度を含む。
【０２４６】
情報要求電文の送信元であるアプリケーション６０を特定するには、例えば情報要求電文がhttp形式の電文であれば、ヘッダに含まれるUser-Agentの情報を利用すればよい。User-Agentには情報要求電文を送信したプログラム名が記載されている。しかし、情報要求電文の送信元を特定する方法はこれに限られない。例えば端末１０Ｂに実装されるＯＳ（Operating System）の機能を利用して、情報要求電文を受信した通信路の送信元ポート番号から当該送信元ポート番号を使用しているプロセスを特定して、情報要求電文を送信したアプリケーション６０を特定してもよい。
【０２４７】
そして、保留判定部５８Ｂは、中継部５６Ａからアプリケーション名を伴って情報要求電文の保留可否の問い合わせを受け付けると、送信頻度テーブルを参照して指定されたアプリケーション名の送信頻度を取得する。そして、保留判定部５８Ｂは取得した送信頻度と規定頻度とを比較して、送信頻度が規定頻度以上であれば中継部５６Ａに情報要求電文を保留するように通知する。また、保留判定部５８Ｂは、送信頻度が規定頻度未満であれば中継部５６Ａに情報要求電文を保留しないように通知する。
【０２４８】
以上に説明した端末１０Ｂは、例えば、図３０に示すコンピュータ１００Ｂで実現することができる。
【０２４９】
記憶媒体としての記憶部１０６には、コンピュータ１００Ｂを端末１０Ｂとして機能させるための端末プログラム１２０Ｂ及びアプリケーションプログラム１２９が記憶されている。端末プログラム１２０Ｂが第２実施形態に係る端末プログラム１２０Ａと異なる点は、保留判定プロセス１２８が保留判定プロセス１２８Ｂに置き換えられた点である。
【０２５０】
または、ＣＰＵ１０２は、保留判定プロセス１２８Ｂを実行することで、図２８に示す保留判定部５８Ｂとして動作する。
【０２５１】
次に、端末１０Ｂの作用を説明する。端末１０Ｂは、アプリケーション６０から情報要求電文を受信した際に、第２実施形態において説明した図２６に示す情報要求電文中継処理を実行する。ただし、第３実施形態に係る端末１０Ｂの場合、ステップＳ８５の処理が異なる。
【０２５２】
ステップＳ８５では、中継部５６Ａは情報要求電文をキューに保留する必要があるか否か判定する。具体的には、中継部５６Ａは受信した情報要求電文のヘッダに含まれるUser-Agentから、情報要求電文の送信元であるアプリケーション名を取得する。そして、中継部５６Ａは、取得したアプリケーション名を伴って、受信した情報要求電文をキューに保留すべきか保留判定部５８Ｂに問い合わせる。
【０２５３】
この問い合わせに対して保留判定部５８Ｂは、送信頻度テーブルのアプリケーション名欄に中継部５６Ａから通知されたアプリケーション名が存在するか検索し、当該アプリケーション名に対応する送信頻度を取得する。
【０２５４】
更に保留判定部５８Ｂは、取得した送信頻度がメモリ１０４の予め定めた領域に予め記憶される規定頻度以上か否か判定する。取得した送信頻度が規定頻度未満であれば、保留判定部５８Ｂは情報要求電文を保留する必要はないとの判定結果を中継部５６Ａに通知する。一方、取得した送信頻度が規定頻度以上であれば、保留判定部５８Ｂは情報要求電文を保留する必要があるとの判定結果を中継部５６Ａに通知する。
【０２５５】
そして、中継部５６Ａは保留判定部５８Ｂからの判定結果に基づき、情報要求電文を保留する必要があると判定した場合にはステップＳ９０へ移行し、情報要求電文をキューに保留する。一方、中継部５６Ａが保留判定部５８Ｂからの判定結果に基づき、情報要求電文を保留する必要はないと判定した場合にはステップＳ２０へ移行し、情報要求電文を情報管理サーバ２０Ａへ送信する。
【０２５６】
このように本実施形態では、アプリケーション６０の情報要求電文の送信頻度に基づいて、アプリケーション毎にトークンの更新期間中に受信した情報要求電文の保留の可否を判定する。情報要求電文の送信頻度が規定頻度以上であるアプリケーション６０からの情報要求電文はキューに保留され、情報要求電文の送信頻度が規定頻度未満であるアプリケーション６０からの情報要求電文は保留されることなく情報管理サーバ２０Ａへ送信される。
【０２５７】
従って、トークンの更新期間中における端末１０Ｂの通信負荷の増加を抑制すると共に、アプリケーション６０の操作性を向上することができる。
【０２５８】
なお、第３実施形態に係る保留判定部５８Ｂの処理と、第２実施形態に係る保留判定部５８の処理と、を組み合わせるようにしてもよい。
【０２５９】
例えば、まず、アプリケーション６０の情報要求電文の送信頻度に基づいて、アプリケーション毎にトークンの更新期間中に受信した情報要求電文の保留の可否を判定する。そして、保留の必要がないと判定された情報要求電文に対して、更に情報要求電文に付加されるチケット数を判定し、付加されるチケット数が規定チケット数以下である場合に、情報管理サーバ２０Ａへ送信する等の様々な処理を実施してもよい。この場合、情報要求電文の送信頻度から保留の必要がないと判定された情報要求電文であっても、付加されるチケット数が規定チケット数を超えるならば、キューに保留されることになる。
【０２６０】
また、第３実施形態では、情報要求電文の保留の可否の判定にアプリケーション６０における情報要求電文の送信頻度を用いたが、アプリケーション６０に関するその他の状況を用いてもよい。
【０２６１】
例えば、端末１０Ｂの図示しない画面の最前面に表示されているアプリケーション６０（フォアグランドアプリケーション）は、端末１０Ｂのユーザが操作中であると考えられる。従って、フォアグランドアプリケーションからの情報要求電文は、トークンの更新期間中であってもキューに保留せずに情報管理サーバ２０Ａへ送信する。
【０２６２】
一方、フォアグランドアプリケーション以外のアプリケーション６０の場合、端末１０Ｂ内で稼動しているだけで、端末１０Ｂのユーザによって直接操作されているアプリケーション６０ではないと考えられる。従って、フォアグランドアプリケーション以外のアプリケーション６０からの情報要求電文は、トークンの更新期間中であればキューに保留する。
【０２６３】
このような処理を実行することで、トークンの更新期間中、フォアグランドアプリケーションの操作性を低下させることなく端末１０Ｂの通信負荷を低減することができる。
【０２６４】
そのためには、保留判定部５８Ｂでフォアグランドアプリケーションを把握する必要があるが、そのためには、例えばＯＳの機能として予め用意されるフォアグランドアプリケーションの取得関数等を用いればよい。
【０２６５】
その他、アプリケーション６０の優先順位を参照し、優先順位が予め定めた優先順位以上であるアプリケーション６０からの情報要求電文は、トークンの更新期間中であってもキューに保留せずに情報管理サーバ２０Ａへ送信する等の処理を実行してもよい。
【０２６６】
更には、情報管理サーバ２０Ａにおいて、端末１０Ｂのアプリケーション６０毎に要求されたリソースにアクセス可能か否か判定するようにしてもよい。
【０２６７】
そのためには、例えば端末１０Ｂで情報要求電文のヘッダに当該情報要求電文の送信元であるアプリケーション６０を一意に示すアプリＩＤを付加する。
【０２６８】
この場合、情報管理サーバ２０Ａでは、図１１に示した認可ポリシーテーブルの替わりに図３１に示す認可ポリシーテーブルを用いる。
【０２６９】
図３１に示す認可ポリシーテーブルは、図１１に示した認可ポリシーテーブルにアプリＩＤ欄を追加したものである。図３１に示す認可ポリシーテーブルでは、リソースＵＲＬへアクセス可能なアプリケーション６０と、リソースＵＲＬへアクセスするために必要な端末１０Ｂのチケットの状態を示すチケット情報と、が規定されている。図３１の例では、端末１０Ｂにおけるチケット情報が（場所、ユーザ権限、ユーザ状態）＝（校内、教師、就業中）の場合にアプリＩＤが“ａｐｐ＃１”のアプリケーション６０から“http://foo.bar.com:8080/baz1”にアクセスできることが規定されている。
【０２７０】
従って、端末１０Ｂにおけるチケット情報が（場所、ユーザ権限、ユーザ状態）＝（校内、教師、就業中）の場合であっても、アプリＩＤが“ａｐｐ＃２”のアプリケーション６０から“http://foo.bar.com:8080/baz1”に対するアクセス要求は拒否される。
【０２７１】
ただし、リソースＵＲＬへのアクセス条件としてアプリケーション６０のアプリＩＤが追加された場合、アクセス判定部２３はトークンだけで図１２に示した判定結果テーブルからリソースＵＲＬへアクセス可能か判定することができない。
【０２７２】
従って、この場合には図１２に示した判定結果テーブルの替わりに、図３２に示す判定結果テーブルを用いる。図３２に示す判定結果テーブルは、図１２に示した判定結果テーブルにアプリＩＤ欄を追加したものである。
【０２７３】
図３２に示す判定結果テーブルでは、トークンとアプリＩＤとの組み合わせでリソースＵＲＬへアクセス可能か否かの判定結果を取得することができるため、リソースＵＲＬへのアクセス条件にアプリケーションを追加した場合にも対応することができる。
【０２７４】
以上、開示の技術を第１実施形態〜第３実施形態を用いて説明したが、開示の技術は第１実施形態〜第３実施形態に記載の範囲には限定されない。開示の技術の要旨を逸脱しない範囲で第１実施形態〜第３実施形態に多様な変更または改良を加えることができ、当該変更または改良を加えた形態も開示の技術の技術的範囲に含まれる。例えば、開示の技術の要旨を逸脱しない範囲で処理の順序を変更してもよい。
【０２７５】
また、上記では開示の技術に係る端末プログラムの一例である端末プログラム１２０、１２０Ａ、及び１２０Ｂが記憶部１０６に予め記憶（インストール）されている態様を説明したが、これに限定されるものではない。開示の技術に係る端末プログラムは、コンピュータ読取可能な記録媒体に記録されている形態で提供することも可能である。例えば、開示の技術に係る端末プログラムは、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、及びＵＳＢメモリ等の可搬型記録媒体、並びに、フラッシュメモリ等の半導体メモリ等に記録されている形態で提供することも可能である。
【０２７６】
同様に、開示の技術に係る情報管理プログラムの一例であるアクセス制御プログラム２２０及び２２０Ａも記憶部２０６にインストールされている態様に限定されるものではない。開示の技術に係る情報管理プログラムは、コンピュータ読取可能な記録媒体に記録されている形態で提供することも可能である。
【０２７７】
以上の第１実施形態〜第３実施形態に関し、更に以下の付記を開示する。
【０２７８】
（付記１）
情報管理サーバで管理される情報を要求する情報要求電文を受信し、前記情報管理サーバへ中継する中継部と、
前記中継部により受信された前記情報要求電文に、前記情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに対応付けられて前記情報管理サーバで生成されたトークンを付加する付加部と、
を備え、
前記付加部は、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットを前記情報要求電文へ更に付加し、
前記中継部は、前記状態変化チケットが付加された前記情報要求電文を前記情報管理サーバへ送信してから前記状態変化チケットに基づいて更新されたトークンを前記情報管理サーバから受信するまでの期間に新たな情報要求電文を受信した場合に、前記新たな情報要求電文の送信を保留し、前記期間後で、且つ、前記端末に状態変化チケットが存在しない間、保留した情報要求電文を順次前記情報管理サーバへ中継する
端末装置。
【０２７９】
（付記２）
前記期間中に前記新たな情報要求電文を受信した際、前記新たな情報要求電文毎に、前記情報管理サーバへの中継を保留する必要があるか否か判定する判定部を更に備え、
前記中継部は、前記判定部により保留する必要があると判定された場合、前記新たな情報要求電文の送信を保留し、前記判定部により保留する必要がないと判定された場合、前記新たな情報要求電文を、保留することなく前記情報管理サーバへ中継する
付記１記載の端末装置。
【０２８０】
（付記３）
前記判定部は、前記期間中に受信した前記新たな情報要求電文の送信元であるアプリケーションを特定すると共に、特定したアプリケーションの状況に基づいて、前記新たな情報要求電文の送信を保留する必要があるか否か判定する
付記２記載の端末装置。
【０２８１】
（付記４）
前記アプリケーションの属性は前記アプリケーションから送信される情報要求電文の送信頻度であり、
前記判定部は、前記期間中に前記送信頻度が予め定めた規定頻度以上であるアプリケーションから前記新たな情報要求電文を受け付けた際、前記新たな情報要求電文を保留するよう判定する
付記３記載の端末装置。
【０２８２】
（付記５）
前記判定部は、前記期間中に前記新たな情報要求電文を受信した際の前記端末における状態変化チケットの数が予め定めたチケット数を超える場合に、前記新たな情報要求電文を保留するよう判定する
付記２〜付記４の何れか１項に記載の端末装置。
【０２８３】
（付記６）
前記判定部は、前記期間中に受信した前記新たな情報要求電文により要求される情報の種別に基づいて、前記新たな情報要求電文の送信を保留する必要があるか否か判定する
付記２〜付記４の何れか１項に記載の端末装置。
【０２８４】
（付記７）
前記中継部で受信する前記情報要求電文が、ＨＴＴＰ形式に則った書式によって表される
付記１〜付記６の何れか１項に記載の端末装置。
【０２８５】
（付記８）
端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに基づいて生成したトークンと、前記少なくとも１つのチケットで表される前記端末のチケット状態と、を対応づけて管理する管理部と、
前記管理部で生成されたトークンが付加された、リソースを要求するための情報要求電文によって要求された情報が取得可能か否かを判定する認可判定部と、
前記認可判定部により前記情報が取得可能と判定された場合に、前記情報を含む応答を前記端末へ中継する中継部と、
を備え、
前記管理部は、前記情報要求電文に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットが付加されている場合に、前記チケット状態に対応したトークンを更新し、前記端末毎、且つ、チケットの種別毎に前記端末のチケット状態の変化を時系列に従って管理し、チケット種別毎に最も新しいチケット状態を組み合わせて作成した前記端末のチケット情報と、更新したトークンと、を対応づけて管理し、
前記中継部は、前記更新したトークンを前記端末へ中継する
情報管理サーバ。
【０２８６】
（付記９）
コンピュータに、
情報管理サーバで管理される情報を要求する情報要求電文を受信し、
受信した前記情報要求電文に、前記情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに対応付けられて前記情報管理サーバで生成されたトークンを付加すると共に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットを前記情報要求電文へ更に付加し、
前記状態変化チケットが付加された前記情報要求電文を前記情報管理サーバへ送信してから前記状態変化チケットに基づいて更新されたトークンを前記情報管理サーバから受信するまでの期間に新たな情報要求電文を受信した場合に、前記新たな情報要求電文の送信を保留し、前記期間後で、且つ、前記端末に状態変化チケットが存在しない間、保留した情報要求電文を順次前記情報管理サーバへ中継する
ことを含む処理を実行させるための端末プログラム。
【０２８７】
（付記１０）
前記期間中に前記新たな情報要求電文を受信した際、前記新たな情報要求電文毎に、前記情報管理サーバへの中継を保留する必要があるか否か判定し、
保留する必要があると判定された場合、前記新たな情報要求電文の送信を保留し、前記判定部により保留する必要がないと判定された場合、前記新たな情報要求電文を、保留することなく前記情報管理サーバへ中継する
付記９記載の端末プログラム。
【０２８８】
（付記１１）
前記期間中に受信した前記新たな情報要求電文の送信元であるアプリケーションを特定すると共に、特定したアプリケーションの状況に基づいて、前記新たな情報要求電文の送信を保留する必要があるか否か判定する
付記１０記載の端末プログラム。
【０２８９】
（付記１２）
前記アプリケーションの属性は前記アプリケーションから送信される情報要求電文の送信頻度であり、
前記期間中に前記送信頻度が予め定めた規定頻度以上であるアプリケーションから前記新たな情報要求電文を受け付けた際、前記新たな情報要求電文を保留するよう判定する
付記１１記載の端末プログラム。
【０２９０】
（付記１３）
前記期間中に前記新たな情報要求を受け付けた際の前記端末における状態変化チケットの数が予め定めたチケット数を超える場合に、前記新たな情報要求電文を保留するよう判定する
付記１０〜付記１２の何れか１項に記載の端末プログラム。
【０２９１】
（付記１４）
前記期間中に受信した前記新たな情報要求電文により要求される情報の種別に基づいて、前記新たな情報要求電文の送信を保留する必要があるか否か判定する
付記１０〜付記１２の何れか１項に記載の端末プログラム。
【０２９２】
（付記１５）
前記情報要求電文が、ＨＴＴＰ形式に則った書式によって表される
付記９〜付記１４の何れか１項に記載の端末プログラム。
【０２９３】
（付記１６）
コンピュータに、
情報管理サーバで管理する情報を要求するための情報要求電文に、前記情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況の変化に応じた少なくとも１つのチケットに基づいて生成したトークンと、前記少なくとも１つのチケットで表される前記端末のチケット状態と、を対応づけて管理すると共に、前記情報要求電文に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットが付加されている場合に、前記チケット状態に対応したトークンを更新し、前記端末毎、且つ、チケットの種別毎に前記端末のチケット状態の変化を時系列に従って管理し、チケット種別毎に最も新しいチケット状態を組み合わせて作成した前記端末のチケット情報と、更新したトークンと、を対応づけて管理し、
前記情報要求電文に付加されたトークンで、前記情報要求電文によって要求された情報が取得可能か否か判定し、
前記要求された情報が取得可能と判定された場合に、前記要求された情報及び前記更新したトークンを含む応答を前記端末へ中継する
ことを含む処理を実行させるための情報管理プログラム。
【０２９４】
（付記１７）
コンピュータに、
情報管理サーバで管理される情報を要求する情報要求電文を受信し、
【０２９５】
受信した前記情報要求電文に、前記情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに対応付けられて前記情報管理サーバで生成されたトークンを付加すると共に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットを前記情報要求電文へ更に付加し、
前記状態変化チケットが付加された前記情報要求電文を前記情報管理サーバへ送信してから前記状態変化チケットに基づいて更新されたトークンを前記情報管理サーバから受信するまでの期間に新たな情報要求電文を受信した場合に、前記新たな情報要求電文の送信を保留し、前記期間後で、且つ、前記端末に状態変化チケットが存在しない間、保留した情報要求電文を順次前記情報管理サーバへ中継する
ことを含む処理を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【０２９６】
（付記１８）
コンピュータに、
情報管理サーバで管理する情報を要求するための情報要求電文に、前記情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況の変化に応じた少なくとも１つのチケットに基づいて生成したトークンと、前記少なくとも１つのチケットで表される前記端末のチケット状態と、を対応づけて管理すると共に、前記情報要求電文に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットが付加されている場合に、前記チケット状態に対応したトークンを更新し、前記端末毎、且つ、チケットの種別毎に前記端末のチケット状態の変化を時系列に従って管理し、チケット種別毎に最も新しいチケット状態を組み合わせて作成した前記端末のチケット情報と、更新したトークンと、を対応づけて管理し、
前記情報要求電文に付加されたトークンで、前記情報要求電文によって要求された情報が取得可能か否か判定し、
前記要求された情報が取得可能と判定された場合に、前記要求された情報及び前記更新したトークンを含む応答を前記端末へ中継する
ことを含む処理を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【０２９７】
（付記１９）
情報管理サーバで管理される情報を要求する情報要求電文を受信し、前記情報管理サーバへ中継する中継部と、前記中継部により受信された前記情報要求電文に、前記情報へのアクセス権として用いられ、端末及び該端末を使用するユーザの少なくとも一方の状況に応じた少なくとも１つのチケットに対応付けられて前記情報管理サーバで生成されたトークンを付加すると共に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットを前記情報要求電文へ更に付加する付加部と、前記中継部により前記状態変化チケットが付加された前記情報要求電文を前記情報管理サーバへ送信してから前記状態変化チケットに基づいて更新されたトークンを前記情報管理サーバから受信するまでの期間中に新たな情報要求電文を受け付けた際、前記新たな情報要求電文毎に、前記情報管理サーバへの中継を保留する必要があるか否か判定する判定部と、を備えた端末装置と、
前記少なくとも１つのチケットに基づいて生成したトークンと、前記少なくとも１つのチケットで表される前記端末のチケット状態と、を対応づけて管理する管理部と、前記管理部で生成されたトークンが付加された、リソースを要求するための情報要求電文によって要求された情報が取得可能か否かを判定する認可判定部と、前記認可判定部により前記情報が取得可能と判定された場合に、前記情報を含む応答を前記端末へ中継する中継部と、を備えた情報管理サーバと、
を備え、
前記端末装置の前記中継部は、前記判定部により前記新たな情報要求電文を保留する必要があると判定された場合、前記新たな情報要求電文の送信を保留し、前記判定部により保留する必要がないと判定された場合、前記新たな情報要求電文を、保留することなく前記情報管理サーバへ中継し、
前記管理部は、前記情報要求電文に、前記少なくとも１つのチケットのうち、前記状況の変化に応じて状態が変化した状態変化チケットが付加されている場合に、前記チケット状態に対応したトークンを更新し、前記端末装置毎、且つ、チケットの種別毎に前記端末装置のチケット状態の変化を時系列に従って管理し、チケット種別毎に最も新しいチケット状態を組み合わせて作成した前記端末装置のチケット情報と、更新したトークンと、を対応づけて管理し、
前記情報管理サーバの前記中継部は、前記更新したトークンを前記端末装置へ中継する
情報管理システム。
【符号の説明】
【０２９８】
１０、１０Ａ、１０Ｂ  端末
２０、２０Ａ  情報管理サーバ
２１  中継部
２２、２２Ａ  トークン管理部
２３  アクセス判定部
４０  リソースサーバ
５０、５０Ａ  端末プロキシ
５１  取得部
５２、５２Ａ  チケット管理部
５３  トークン管理部
５４  付加部
５５  監視部
５６、５６Ａ  中継部
５７  抽出部
５８、５８Ｂ  保留判定部
６０  アプリケーション
１００、１００Ａ、１００Ｂ  コンピュータ
１２０、１２０Ａ、１２０Ｂ  端末プログラム
２００、２００Ａ  コンピュータ
２２０、２２０Ａ  アクセス制御プログラム
【図７】
2015201030.tif 000003
【図８】
2015201030.tif 000004
【図１０】
2015201030.tif 000005
【図１１】
2015201030.tif 000006
【図１２】
2015201030.tif 000007
【図１３】
2015201030.tif 000008
【図１４】
2015201030.tif 000009
【図１５】
2015201030.tif 000010
【図１６】
2015201030.tif 000011
【図１７】
2015201030.tif 000012
【図１８】
2015201030.tif 000013
【図１９】
2015201030.tif 000014
【図２０】
2015201030.tif 000015
【図２１】
2015201030.tif 000016
【図２２】
2015201030.tif 000017
【図２３】
2015201030.tif 000018
【図２４】
2015201030.tif 000019
【図２５】
2015201030.tif 000020
【図２６】
2015201030.tif 000021
【図２７】
2015201030.tif 000022
【図２８】
2015201030.tif 000023
【図２９】
2015201030.tif 000024
【図３０】
2015201030.tif 000025
【図３１】
2015201030.tif 000026
【図３２】
2015201030.tif 000027
【図１】
2015201030.tif 000028
【図２】
2015201030.tif 000029
【図３】
2015201030.tif 000030
【図４】
2015201030.tif 000031
【図５】
2015201030.tif 000032
【図６】
2015201030.tif 000033
【図９】
2015201030.tif 000034