JP2015201104A - 端末装置、情報管理装置、端末プログラム、情報管理プログラム、及びシステム - Google Patents

Abstract

【課題】１つの側面として、端末装置における処理の負荷を抑制する。
【解決手段】端末装置２０は、アクセス対象の情報に対するアクセス要求に、自装置の状態を示す状態情報を付加して情報管理装置へ送信し、アクセス対象の情報にアクセスする際に不足する不足状態情報の送信依頼を受信し、不足状態情報を取得し、送信依頼で示される不足状態情報が複数の取得先から取得可能な場合に、複数の取得先毎の不足状態情報を取得する際の取得負荷に基づいて、不足状態情報の取得負荷が小さい取得先から優先して送信依頼で示される不足状態情報を取得するよう制御し、取得した不足状態情報を情報管理装置へ送信するよう制御する。
【選択図】図１

Description

本発明は、端末装置、情報管理装置、端末プログラム、情報管理プログラム、及びシステムに関する。

端末装置から端末装置で用いるリソースを格納したネットワーク上のリソース装置に対してリソースの利用を要求する場合、リソースを利用するための情報を暗号化したチケットを用いる技術が知られている。チケットを用いる技術の一例として、チケットにより、リソースを利用することを許諾するアクセス認可を処理する情報処理装置が知られている。

特開２０００−２１５１６５号公報 特表２００４−５３７１０５号公報 特表２００７−５２４８７７号公報

しかしながら、端末装置で用いるリソースを利用するために、リソースを利用することを許諾するアクセス認可を得るための情報は、端末装置の状態に応じて変化する場合がある。端末装置の状態に応じて変化するアクセス認可を得るための情報を取得することは、端末装置、または情報処理装置における処理の負荷を増大させる。

１つの側面では、端末装置における処理の負荷を抑制することを目的とする。

開示の技術の端末装置は、外部に格納されたアクセス対象の情報に対するアクセス要求に、自装置の状態を示す状態情報を付加して情報管理装置へ送信し、アクセス対象の情報にアクセスする際に不足する不足状態情報の送信依頼を受信する。そして、端末装置は、送信依頼で示される不足状態情報が複数の取得先から取得可能な場合に、複数の取得先毎の不足状態情報を取得する際の取得負荷に基づいて、不足状態情報の取得負荷が小さい取得先から優先して送信依頼で示される不足状態情報を取得する。そして、端末装置は、取得した不足状態情報を情報管理装置へ送信する。

１つの側面では、端末装置における処理の負荷を抑制することができる、という効果がある。

図１は、情報処理システムの一例を示すブロック図である。 図２は、コンピュータで実現する情報処理システムの一例を示すブロック図である。 図３は、リソースアクセス部の処理の流れの一例を示すフローチャートである。 図４は、応答に含まれるヘッダの一例を示すイメージ図である。 図５は、チケット取得戦略部の処理の流れの一例を示すフローチャートである。 図６は、取得コスト表の一例を示すイメージ図である。 図７は、チケット取得部の処理の流れの一例を示すフローチャートである。 図８は、認証サーバの処理の流れの一例を示すフローチャートである。 図９は、チケット検証部の処理の流れの一例を示すフローチャートである。 図１０は、認可ポリシの一例を示すイメージ図である。 図１１は、ディレクトリの一例を示すイメージ図である。

以下、図面を参照して開示の技術の実施形態の一例を詳細に説明する。本実施形態は、端末装置の状態及び端末装置を利用するユーザの状態に応じたリソースへのアクセス制御を実現する場合に開示の技術を適用するものである。

図１に、本実施形態に係る情報処理システム１０の一例を示す。情報処理システム１０は、端末装置２０と、ゲートウェイ装置３０とがネットワーク４０により接続される。端末装置２０は、アプリケーション部５０と、端末内プロキシ部６０と、センサ７０とを含む。

なお、端末装置２０のセンサ７０は必須ではなく、逆に端末装置２０は複数のセンサ７０を含んでいてもよい。また、センサ７０は端末及び端末を利用するユーザの状態を出力する装置であればどのような種類のものであってもよい。例えば、センサ７０には、端末の位置情報を通知するＧＰＳ（Global Positioning System）センサや、ＮＦＣ（Near field communication）を用いてユーザの身分証明書を読み取り、個人情報を出力する読み取り装置等が含まれる。また、センサ７０は、端末及び端末を利用するユーザの状態を出力する際に必要となる情報を管理している場合がある。

例えば、クラス名と時刻情報を読み取り、その時刻にそのクラスで行われている授業の科目を出力する時間割センサでは、時間割センサ内部に各クラスの時間割情報が管理されている。

端末内プロキシ部６０は、リソースアクセス部８０と、チケット取得戦略部９０と、チケット取得部１００と、チケット保管部１１０とを含む。なお、以降ゲートウェイ装置３０をＧＷ（Gateway）装置３０と称す。

一方、ＧＷ装置３０は、環境プロキシ部１３０と、チケット管理部１４０とを含む。環境プロキシ部１３０は、リソース装置１９０へアクセスする際の認可ポリシを格納した認可ポリシ格納部１５０、及び認可ポリシ１５０に接続されるチケット検証部１６０を含む。また、チケット管理部１４０は、ディレクトリを格納したディレクトリ格納部１７０、及びディレクトリ格納部１７０に接続されるチケット管理処理部１８０を含む。更にＧＷ装置３０は、リソースを格納したリソース装置１９０に接続される。

次に、端末装置２０の各部の機能について説明する。

アプリケーション部５０は、リソース装置１９０に含まれるリソースを取得して必要な処理を行うアプリケーションを含む。アプリケーション部５０はリソースが必要となった場合、リソースの保存場所を示す情報であるＵＲＬ(Uniform Resource Locator)と共にリクエストパケット（以下、パケットともいう）を端末内プロキシ部６０へ送信する。また、アプリケーション部５０は、パケットで要求したリソースをリソース装置１９０から受信する。

なお、本実施形態で用いられるパケットの電文形式に制限はないが、一例としてパケットはＨＴＴＰ（Hypertext Transfer Protocol）に従った電文とする。

端末内プロキシ部６０のリソースアクセス部８０は、アプリケーション部５０からのパケットにチケットを付加してＧＷ装置３０へ送信する。ここでチケットとは端末及び端末を利用するユーザの状態を表す情報（端末状態情報）に信用情報が付加された情報である。ここで信用情報とは、端末状態情報の内容が改ざん等されず、正しい状態を示していることを担保する情報である。端末状態情報に信用情報を付加するためには、例えば端末状態情報の暗号化、及び端末状態情報への電子証明書の添付等、端末状態情報に対する改ざん及び端末状態情報の通知元の偽装等を防止する何らかの処理が実施されればよい。

また、リソースアクセス部８０は、ＧＷ装置３０からリソースを取得するのに必要なチケットが不足しているとの応答を受信した場合に、チケット取得戦略部９０へ不足チケットの取得を依頼し、取得した不足チケットをＧＷ装置３０へ送信する。

チケット取得戦略部９０は、不足チケットの取得先が複数存在する場合に、最も負荷がかからない方法でチケットを取得することができるチケットの取得先を特定する。そして、チケット取得戦略部９０は、特定したチケットの取得先から不足チケットを取得するようにチケット取得部１００へ指示する。

ここで、チケット取得の負荷を表す指標として、例えばチケットを要求してから入手するまでに必要な取得時間が用いられ、チケットの取得時間が短いほどチケット入手の負荷がかからないと判断される。

チケット取得部１００は、チケット取得戦略部９０から指示されたチケットを、チケット取得戦略部９０が特定したチケットの取得先から取得する。チケットの取得先として、例えば、チケット保管部１１０、認証サーバ１２０、及びセンサ７０が存在する。

また、チケット取得部１００は、例えば、認証サーバ１２０に内蔵又は接続されるセンサ７０（認証サーバ１２０付属のセンサ７０）がセンサ値の状態の変化を検知した場合等に自発的に送信してくるチケットを取得し、チケット保管部１１０へ保存する。

認証サーバ１２０は、チケット取得部１００からのチケット発行要求を受け付け、例えば認証サーバ１２０に内蔵又は接続されるセンサ７０により端末状態情報を取得する。そして、認証サーバ１２０は取得した端末状態情報を認証部１２５でチケット化してチケット取得部１００へ送信する。

なお、認証サーバ１２０は、チケット取得部１００からチケット発行要求を受け付けなくとも、認証サーバ１２０付属のセンサ７０の値に変化が生じた場合にチケットを発行し、チケット取得部１００へ送信する場合がある。

なお、端末２０付属のセンサ７０から出力される端末状態情報は暗号化等されていないチケット化前の情報である。従って、この場合にはチケット取得部１００は、センサ７０から取得した端末状態情報を認証サーバ１２０へ送信し、端末状態情報をチケット化して、端末状態情報の信頼性を向上させる。

チケット保管部１１０には、チケット取得部１００が取得したチケットが保存される。

次に、ＧＷ装置３０の各部の機能について説明する。

チケット検証部１６０は端末装置２０からチケットが付加されたパケットを受信し、認可ポリシ格納部１５０に格納される認可ポリシを参照して、端末装置２０が要求するリソースの取得に必要なチケットがパケットに付加されているか否かを検証する。そして、パケットにリソースの取得に必要なチケットが付加されている場合はパケットをリソース装置１９０へ送信し、要求したリソースが含まれるリソース装置１９０からの応答を端末装置２０へ送信する。

一方、パケットにリソースの取得に必要なチケットが付加されていない場合には、チケット検証部１６０はチケット管理部１４０のディレクトリ格納部１７０に含まれるディレクトリを参照して、不足チケットの取得先を取得する。

チケット管理処理部１８０は、ＧＷ装置３０のディレクトリ格納部１７０に予めディレクトリを格納したり、ディレクトリの内容を編集したりするためのインタフェースを提供する。

リソース装置１９０は、例えば読み出し可能な記録媒体に予め記録されたリソースのうち、パケットによって要求されたリソースを読み出し、読み出したリソースを付加した応答を生成して、ＧＷ装置３０のチケット検証部１６０へ送信する。

図２に、情報処理システム１０に含まれる端末装置２０及びＧＷ装置３０を、コンピュータで実現可能な一例としてのコンピュータシステム２００を示す。情報処理システム１０としての図２に示すコンピュータシステム２００は、端末装置２０としてのコンピュータ２１０、及びＧＷ装置３０としてのコンピュータ２６０を含む。また、認証サーバ１２０としてのコンピュータ２９０、及びリソース装置１９０としてのコンピュータ３１０を含む。

コンピュータ２１０はＣＰＵ２２２、メモリ２２４、端末内プロキシプログラム２３８、及びアプリケーションプログラム２４６が記録された不揮発性の記憶部２２６を備える。ＣＰＵ２２２、メモリ２２４、及び記憶部２２６は、バス２２８を介して互いに接続される。また、コンピュータ２１０は、ディスプレイ等の表示部２３２、キーボード及びマウス等の入力部２３０を備え、表示部２３２及び入力部２３０はバス２２８に接続される。また、コンピュータ２１０は、記録媒体２１２に対して読み書きするためのＩＯ２３４がバス２２８に接続される。さらに、コンピュータ２１０はネットワーク４０に接続するためのインタフェースを含む通信ＩＦ（Interface）２３６を備える。なお、記憶部２２６はＨＤＤ(Hard Disk Drive)やフラッシュメモリ等によって実現できる。

記憶部２２６には、コンピュータ２１０を図１に示す端末装置２０として機能させるためのプログラム、及び情報が記憶される。つまり、記憶部２２６には、端末内プロキシプログラム２３８、アプリケーションプログラム２４６、チケット情報２４８、及び取得コスト表２５０が記憶される。記憶部２２６に記憶された端末内プロキシプログラム２３８は、リソースアクセスプロセス２４０、チケット取得戦略プロセス２４２、及びチケット取得プロセス２４４を含む。ＣＰＵ２２２は、端末内プロキシプログラム２３８を記憶部２２６から読み出してメモリ２２４に展開し、端末内プロキシプログラム２３８が有する各プロセスを実行する。

ＣＰＵ２２２が端末内プロキシプログラム２３８を記憶部２２６から読み出してメモリ２２４に展開し、端末内プロキシプログラム２３８を実行することで、コンピュータ２１０が図１に示す端末装置２０として動作する。ＣＰＵ２２２がリソースアクセスプロセス２４０を記憶部２２６から読み出してメモリ２２４に展開し、リソースアクセスプロセス２４０を実行することで、コンピュータ２１０は図１に示すリソースアクセス部８０として動作する。また、ＣＰＵ２２２がチケット取得戦略プロセス２４２を実行することで、コンピュータ２１０は図１に示すチケット取得戦略部９０として動作する。更にまた、ＣＰＵ２２２がチケット取得プロセス２４４を実行することで、コンピュータ２１０は図１に示すチケット取得部１００として動作する。なお、ＣＰＵ２２２がアプリケーションプログラム２４６を実行することで、コンピュータ２１０は図１に示すアプリケーション部５０として動作する。

また、コンピュータ２６０はＣＰＵ２６２、メモリ２６４、ＧＷプロキシプログラム２７８が記録された不揮発性の格納部２６６を備える。ＣＰＵ２６２、メモリ２６４、及び格納部２６６は、バス２６８を介して互いに接続される。また、コンピュータ２６０は、ディスプレイ等の表示部２７２、キーボード及びマウス等の入力部２７０を備え、表示部２７２及び入力部２７０はバス２６８に接続される。また、コンピュータ２６０は、記録媒体２１２に対して読み書きするためのＩＯ２７４がバス２６８に接続される。さらに、コンピュータ２６０はネットワーク４０に接続するためのインタフェースを含む通信ＩＦ２７６を備える。なお、格納部２６６はＨＤＤやフラッシュメモリ等によって実現できる。

格納部２６６には、コンピュータ２６０を図１に示すＧＷ装置３０として機能させるためのプログラム、及び情報が記憶される。つまり、格納部２６６には、ＧＷプロキシプログラム２７８、ディレクトリ２８４、及び認可ポリシ２８６が記憶される。格納部２６６に記憶されたＧＷプロキシプログラム２７８は、チケット検証プロセス２８０及びチケット管理プロセス２８２を含む。ＣＰＵ２６２は、ＧＷプロキシプログラム２７８を格納部２６６から読み出してメモリ２６４に展開し、ＧＷプロキシプログラム２７８が有する各プロセスを実行する。

ＣＰＵ２６２がＧＷプロキシプログラム２７８を格納部２６６から読み出してメモリ２６４に展開し、ＧＷプロキシプログラム２７８を実行することで、コンピュータ２６０が図１に示すＧＷ装置３０として動作する。ＣＰＵ２６２がチケット検証プロセス２８０を格納部２６６から読み出してメモリ２６４に展開し、チケット検証プロセス２８０を実行することで、コンピュータ２６０は図１に示すチケット検証部１６０として動作する。また、ＣＰＵ２６２がチケット管理プロセス２８２を実行することで、コンピュータ２６０は図１に示すチケット管理処理部１８０として動作する。

また、コンピュータ２９０はＣＰＵ２９２、メモリ２９４、認証プログラム３０２が記録された不揮発性の記録部２９６を備える。ＣＰＵ２９２、メモリ２９４、及び記録部２９６は、バス２９８を介して互いに接続される。また、コンピュータ２９０は、端末状態情報を収集するセンサ７０を備え、センサ７０はバス２９８に接続される。また、コンピュータ２９０はネットワーク４０に接続するためのインタフェースを含む通信ＩＦ３００を備える。なお、記録部２９６はＨＤＤやフラッシュメモリ等によって実現できる。

記録部２９６には、コンピュータ２９０を図１に示す認証サーバ１２０として機能させるためのプログラムが記憶される。つまり、記録部２９６には、認証プログラム３０２が記憶される。ＣＰＵ２９２が認証プログラム３０２を記録部２９６から読み出してメモリ２９４に展開し、認証プログラム３０２を実行することで、コンピュータ２９０が図１に示す認証サーバ１２０として動作する。

また、コンピュータ３１０はＣＰＵ３１２、メモリ３１４、リソース３２２が記録された不揮発性の保管部３１６を備え、コンピュータ３１０が図１に示すリソース装置１９０として動作する。

ＣＰＵ３１２、メモリ３１４、及び保管部３１６は、バス３１８を介して互いに接続される。また、コンピュータ３１０はネットワーク４０に接続するためのインタフェースを含む通信ＩＦ３２０を備える。なお、保管部３１６はＨＤＤやフラッシュメモリ等によって実現できる。

なお、端末装置２０、ＧＷ装置３０、認証サーバ１２０、及びリソース装置１９０は、例えば半導体集積回路、より詳しくはＡＳＩＣ（Application Specific Integrated Circuit)等で実現することも可能である。

次に、本実施形態に係る端末装置２０の作用を説明する。本実施形態に係る端末装置２０のリソースアクセス部８０は、端末装置２０の起動後に図３に示すリソースアクセス処理を実行する。

なお、本実施形態に係るアプリケーション部５０は一例として数学学習用アプリケーションであり、リソース装置１９０からリソースとして数学補習教材を取得する場合について説明する。なお、アプリケーション部５０で用いられるアプリケーションの種類には制限はなく、数学学習用アプリケーションに限定されないことはいうまでもない。

まず、ステップＳ１０では、リソースアクセス部８０は、アプリケーション部５０からパケットを受信したか否かを判定する。そして否定判定の場合には再びステップＳ１０へ移行し、パケットの受信を待ち受ける。一方、肯定判定の場合にはステップＳ２０へ移行する。

端末装置２０には、パケットにより要求されるリソースにアクセスするために必要となるチケットに関する情報が記載された認可ポリシ２８６が存在しない。従ってステップＳ２０では、まずリソースアクセス部８０はチケット保管部１１０に保存されている全てのチケット、又は任意に選択したチケットをパケットのヘッダに付加する。

本実施形態に係る情報処理システム１０において、端末装置２０に認可ポリシを含めない理由は、情報処理システム１０をシステム内の変化に柔軟に対応する、より構築しやすいシステムにするためである。

仮に、端末装置２０に認可ポリシ２８６が含まれ、リソースアクセス部８０が端末装置２０内の認可ポリシ２８６を参照して、アプリケーション部５０が要求するリソースの取得に必要なチケットを付加する場合を考える。この場合、認可ポリシ２８６の変更の度に、端末装置２０とＧＷ装置３０との間で認可ポリシ２８６を一致させる必要がある。一方、本実施形態に係る情報処理システム１０のように、認可ポリシ２８６をＧＷ装置３０にのみ配置した構成では、認可ポリシ２８６に変更があっても、ＧＷ装置３０の認可ポリシ２８６を変更するだけでシステム全体の認可ポリシ２８６の変更処理が終了する。従って、本実施形態に係る端末装置２０には認可ポリシ２８６が存在しない。

なお、チケットに有効期限が設定されている場合、リソースアクセス部８０は有効期限内のチケットをパケットに付加する。そのため、例えばリソースアクセス部８０は定期的に有効期限を経過したチケットを削除する等の処理を実施してもよい。こうした処理により、チケット検証に不要であることが明らかなチケットをパケットに付加する必要がなくなり、ネットワーク４０の通信トラフィック量が抑制される効果が期待できる。ただし、有効期限が経過したチケットをパケットに付加したとしても、ＧＷ装置３０では有効期限が経過したチケットを無効として扱うため問題は生じない。

ステップＳ３０では、リソースアクセス部８０は、ステップＳ２０の処理後のパケットをメモリ２２４の予め定めた領域に記憶して一時的に保存する。

ステップＳ４０では、リソースアクセス部８０は、ＧＷ装置３０のチケット検証部１６０へチケットを付加したパケットを送信する。

ステップＳ５０では、リソースアクセス部８０は、ステップＳ４０で送信したパケットに対するチケット検証部１６０からの応答を受信したか否かを判定する。否定判定の場合には再びステップＳ５０へ移行し、応答を受信するまでステップＳ５０の処理を繰り返す。なお、所定時間経過してもチケット検証部１６０から応答を受信できない場合には、リソースアクセス部８０はアプリケーション部５０にリソース取得失敗を通知するエラー応答を送信して本処理を終了するようにしてもよい。なお、応答も一例としてＨＴＴＰに従った電文である。

一方、ステップＳ５０の処理でチケット検証部１６０からの応答を受信した場合にはステップＳ６０に移行し、ステップＳ６０では、リソースアクセス部８０は受信した応答のヘッダを参照する。

ステップＳ７０では、リソースアクセス部８０はステップＳ６０の処理で参照したヘッダの内容から、リソースを取得する際に必要となるチケットに不足が生じているか否かを判定する。

ここで、応答のヘッダの一例を図４に示す。

応答のヘッダには不足チケットがあるか否かを示すフラグが含まれる。また、不足チケットが存在する場合、応答には不足チケットの取得先情報が含まれる。更に、ヘッダには不足チケットを入手するのに別のチケットが必要であれば補足情報が含まれ、補足情報に別のチケットの取得先情報が記載される。なお、チケットの取得先情報には、チケット取得先のＵＲＬと、チケットを入手する際に必要となる入力が含まれる。

図４の例では、“X-Adn-Ticket-insufficient”が不足チケットがあるか否かを示すフラグであり、この値がtrueであれば不足チケットがあることを示し、falseであれば不足チケットがないことを示す。

また、図４の例では、“insufficient_tickets”に対応する括弧内で記載された内容が不足チケットの取得先情報を示している。この場合、数学補習チケットが不足し、その取得先は“時間割”と称されるセンサ７０及び“生徒情報”と称されるセンサ７０の２通りあることを示している。

なお、図４の例では、時間割センサ７０から数学補習チケットを発行するための入力として、３年１組チケットが必要であることが“input”に対応する括弧内に記載されている。従って、応答のヘッダに補足情報を示す“tickets_information”の項目が付加され、３年１組チケットの取得先情報が更に記載されている。この場合、３年１組チケットは、ＮＦＣサーバ又はＷｉＦｉサーバから取得可能であることが示されている。

従って、リソースアクセス部８０は、“X-Adn-Ticket-insufficient”がtrueであれば不足チケットが存在すると判定し、ステップＳ８０へ処理を移行する。一方、“X-Adn-Ticket-insufficient”がfalseであれば不足チケットは存在しない、すなわち、ステップＳ５０の処理で受信した応答にはアプリケーション部５０が要求したリソースが含まれていると判定し、ステップＳ１５０へ処理を移行する。

ステップＳ１５０では、リソースアクセス部８０は受信した応答をアプリケーション部５０へ送信する。これにより、アプリケーション部５０は受信した応答から要求したリソースを取得することができる。

そして、ステップＳ１６０では、リソースアクセス部８０は、ステップＳ３０の処理でメモリ２２４に一時的に保存していたパケットを削除して処理を終了する。

一方、ステップＳ７０の処理で不足チケットが存在すると判定された場合には、ステップＳ８０でリソースアクセス部８０は不足チケットの取得をチケット取得戦略部９０へ依頼する。この際、リソースアクセス部８０は、ステップＳ５０の処理で受信した応答のヘッダに含まれる不足チケットの取得先情報と、補足情報がある場合には補足情報と、を「チケット取得方法」としてチケット取得戦略部９０へ通知する。

ステップＳ９０では、リソースアクセス部８０はチケット取得戦略部９０から不足チケットの取得結果を受信したか否かを判定する。否定判定の場合には再びステップＳ９０へ移行し、不足チケットの取得結果を受信するまでステップＳ９０の処理を繰り返す。肯定判定の場合にはステップＳ１００へ移行する。なお、所定時間経過してもチケット取得戦略部９０から取得結果を受信できない場合には、リソースアクセス部８０は取得失敗と判断してステップＳ１００へ移行するようにしてもよい。

ステップＳ１００では、リソースアクセス部８０は、ステップＳ９０の処理で取得したチケット取得戦略部９０からの不足チケットの取得結果に基づいて、不足チケットの取得が完了したか否かを判定する。なお、ステップＳ９０の処理で、取得結果の受信に要する時間が所定時間経過したことにより取得失敗と判断した場合には、ステップＳ１００の判定においては、不足チケットの取得は完了していないものとして扱われる。そして、否定判定の場合にはステップＳ１４０へ移行し、ステップＳ１４０でリソースアクセス部８０は、アプリケーション部５０に不足チケット取得失敗を通知するエラー応答を送信して本処理を終了する。一方、ステップＳ１００の処理が肯定判定の場合にはステップＳ１２０へ移行する。

ステップＳ１２０では、リソースアクセス部８０は、ステップＳ３０の処理でメモリ２２４に一時的に保存していたパケットに、ステップＳ９０の処理で取得した不足チケットを付加してチケット検証部１６０へ送信する。そして、ステップＳ５０へ移行し、再びステップＳ５０〜Ｓ１６０の処理を繰り返すことで、要求されたリソースを取得するのに必要なチケットをパケットに付加する。以上の処理により、図３に示したリソースアクセス処理が終了する。

次に、図５は、端末装置２０のチケット取得戦略部９０によって実行される、チケット取得戦略処理を示したフローチャートである。なお、チケット取得戦略部９０は、端末装置２０の起動後に図５に示すチケット取得戦略処理を実行する。

まずステップＳ２００では、チケット取得戦略部９０は、リソースアクセス部８０から不足チケットの取得依頼があるか否かを判定する。そして否定判定の場合には再びステップＳ２００へ移行し、不足チケットの取得依頼を待ち受ける。一方、肯定判定の場合には、チケット取得戦略部９０は、不足チケットの取得依頼と共に通知されるチケット取得方法を取得して、ステップＳ２１０へ移行する。

ステップＳ２１０では、チケット取得戦略部９０はステップＳ２００で取得したチケット取得方法の内容を、チケット取得戦略部９０が把握できる形式に変換してメモリ２２４の予め定めた領域に展開する。

ステップＳ２２０では、ステップＳ２１０の処理でメモリ２２４に展開したチケット取得方法から、チケット取得戦略部９０は不足チケットを取得するためのコスト（取得コスト）を算出する。この際、チケット取得方法に同じ不足チケットに対して複数の取得先情報が示されている場合には、チケット取得戦略部９０は取得先情報毎に取得コストを算出する。

取得コストは取得コスト表２５０に基づいて算出される。

図６は取得コスト表２５０の一例を示した図である。取得コスト表２５０は、チケットの入手態様及びチケット発行に必要なセンサ７０の条件毎にチケット取得に要する負荷を示した表である。チケット取得の負荷の程度を、例えばチケットを要求してから入手するまでに必要な取得時間に応じて定め、チケットの取得時間が長くなる条件ほど、チケット取得に負荷がかかるとして、その取得コストが大きく設定される。

図６に示した取得コスト表２５０の例では、既に不足チケットを取得済みであれば、新たに不足チケットを取得する必要がないので取得コストが「０」に設定される。一方、不足チケットを取得するためには不足チケット毎に不足チケットの取得先情報によって関連付けられたセンサ７０から端末状態情報を取得する必要がある。この端末状態情報が例えば端末装置２０に付属されるセンサ７０から取得可能であれば、端末装置２０内での端末状態情報の取得が完結するため、認証サーバ１２０付属のセンサ７０から取得する場合に比べて取得の負荷が少なくなる。従って、この場合の取得コストは低く設定される。

また、不足チケットに対応したセンサから端末状態情報を取得する際に、ユーザが表示部２３２に表示される画面を見ながらマウス等で操作をする必要がある場合、端末状態情報取得に係る操作が複雑になるに従って端末状態情報の取得に要する時間が長くなる。従って、操作が複雑になるに従って取得コストが高く設定される。また、同様の理由から、不足チケットに予め関連付けられたセンサから出力される端末状態情報のデータサイズが大きいほど取得コストが高く設定される。

なお、不足チケットの取得先情報によって指定されたセンサ７０が、取得コスト表２５０に記載された何れの条件を備えたセンサであるかを予め規定したセンサ情報は、記憶部２２６に予め記憶され、メモリ２２４の予め定めた領域に展開されているものとする。

従って、チケット取得戦略部９０は、まずチケット取得方法から不足チケットの取得に必要なセンサ７０を特定する。そして、チケット取得戦略部９０はセンサ情報に基づいて特定したセンサ７０の有する条件を抽出し、取得コスト表２５０から不足チケットの取得コストを算出する。

なお、１つの不足チケットを取得するために取得コスト表２５０における複数の条件が組み合わされる場合には、各々の条件に応じて得られる取得コストの合計値を、その不足チケットの取得コストとする。例えば、チケット化前の端末状態情報が端末装置２０付属のセンサ７０で取得可能で、且つ、当該センサ７０から端末状態情報が出力されるまで例えば１００ｍｓかかる場合、各々の条件に対応した取得コストは「１」である。従って、センサ７０から端末状態情報を取得してチケット化した場合の、不足チケットの取得コストは「２」となる。また、１つの不足チケットを取得するために新たな別のチケットが必要となる場合には、不足チケットの取得コストは、この新たな別のチケットの取得に要する取得コストを合計した値となる。

なお、チケット取得戦略部９０は、不足チケットの取得コストを算出する際、まずチケット保管部１１０を参照して不足チケットが保存されているか否か参照する。チケット保管部１１０に不足チケットが保存されている場合には、新たにチケットを取得する必要がないため、最もチケットの取得コストが小さい取得先であることが確定する。従って、それ以上、他の方法による不足チケットの取得コストを算出する必要はない。

ステップＳ２３０では、チケット取得戦略部９０は同じ不足チケットに関して複数の取得先が存在する場合、ステップＳ２２０の処理で算出した不足チケットの取得コストに基づいて、不足チケットを取得する上で最も取得コストが小さくなる取得先を特定する。そして、チケット取得戦略部９０は、最も取得コストが小さくなる不足チケットの取得先から不足チケットを取得するよう、チケット取得部１００へ通知する。この際、チケット取得戦略部９０は、不足チケットに対応したチケットの取得先情報も併せてチケット取得部１００へ通知する。

そして、ステップＳ２４０では、チケット取得戦略部９０はチケット取得部１００から通知される取得結果を取得するまで待機し、取得結果に基づいて、不足チケットの取得が完了したか否かを判定する。そして、肯定判定の場合にはステップＳ２５０へ移行する。

ステップＳ２５０では、チケット取得戦略部９０は、ステップＳ２１０の処理でメモリ２２４に展開されたチケット取得方法を参照して、全ての不足チケットを取得したか否かを判定する。そして、否定判定の場合にはステップＳ２３０へ移行し、チケット取得戦略部９０は未取得の不足チケットを１つ選択し、不足チケットを取得する上で最も取得コストが小さくなる取得先を特定する。そして、チケット取得戦略部９０は、最も取得コストが小さくなる不足チケットの取得先から不足チケットを取得するよう、チケット取得部１００へ通知する処理を繰り返す。一方、肯定判定の場合にはステップＳ２６０へ移行する。

ステップＳ２６０では、チケット取得戦略部９０は、ステップＳ２４０の処理で不足チケットの取得結果と共にチケット取得部１００から通知された不足チケットを、リソースアクセス部８０へ通知する。この際、チケット取得戦略部９０は、取得したチケットをチケット保管部１１０に保存するものとする。

一方、ステップＳ２４０の処理で否定判定となった場合にはステップＳ２７０へ移行する。

ステップＳ２７０では、チケット取得戦略部９０はステップＳ２１０の処理でメモリ２２４に展開したチケット取得方法を参照し、ステップＳ２３０で特定した不足チケットの取得先以外の取得先があるか否かを判定する。そして否定判定の場合にはステップＳ２８０へ移行する。

ステップＳ２８０では、不足チケットが取得できる他の取得先がないことから、チケット取得戦略部９０は、リソースアクセス部８０へ不足チケットが取得できなかった旨の取得結果を通知する。

一方、ステップＳ２７０の処理で肯定判定となった場合には、ステップＳ２９０へ移行する。

ステップＳ２９０では、これまで不足チケットの取得を試みた不足チケットの取得先以外の取得先が存在することから、チケット取得戦略部９０は、不足チケットの取得を試みていない残りの取得先のうちで最も取得コストが小さくなる取得先を特定する。そして、チケット取得戦略部９０は、特定した不足チケットの取得先から不足チケットを取得するよう、チケット取得部１００へ依頼し、ステップＳ２４０へ処理を戻す。この際、チケット取得戦略部９０は、不足チケットに対応したチケットの取得先情報も併せてチケット取得部１００へ通知する。

以上の処理により、図５に示したチケット取得戦略処理が終了する。

このように、チケット取得戦略部９０は、取得コストが最も小さいチケットの取得先から不足チケットの取得し、チケットが取得できない場合には、次に取得コストが小さいチケットの取得先から不足チケットを取得するよう、チケット取得部１００を制御する。

次に、図７は、端末装置２０のチケット取得部１００によって実行される、チケット取得処理を示したフローチャートである。なお、チケット取得部１００は、端末装置２０の起動後に図７に示すチケット取得処理を実行する。

まず、ステップＳ３００では、チケット取得部１００は何らかの通知を受信したか否かを判定し、否定判定の場合には再びステップＳ３００へ移行し、通知の受信を待ち受ける。一方、肯定判定の場合にはステップＳ３１０へ移行する。

ステップＳ３１０では、ステップＳ３００の処理で受信した通知の送信元がチケット取得戦略部９０であるか否かを判定する。通知の送信元は、例えば通知内に含まれる通知元情報等を参照することで取得できる。そして、肯定判定の場合にはステップＳ３２０へ移行し、否定判定の場合にはステップＳ３９０へ移行する。

ステップＳ３２０では、チケット取得部１００は、チケット取得戦略部９０から通知された不足チケットの取得先が、端末装置２０に付属のセンサ７０であるか否かを判定する。そして、肯定判定の場合にはステップＳ３３０へ移行し、否定判定の場合にはステップＳ３５０へ移行する。

ステップＳ３３０では、チケット取得部１００は、チケット取得戦略部９０によって指示された端末装置２０付属のセンサ７０から端末状態情報を取得する。しかし、センサ７０から取得した端末状態情報はチケット化されていない。従って、ステップＳ３４０でチケット取得部１００は、複数の認証サーバ１２０のうち、センサ７０から取得した端末状態情報のチケット化を実行する認証サーバ１２０へ端末状態情報を送信し、認証要求を依頼する。

一方、ステップＳ３５０では、チケット取得部１００はチケット取得戦略部９０から指定された、不足チケットの取得先である認証サーバ１２０へ、チケットの取得先情報と共に認証要求を通知する。この際、チケット取得部１００はチケットの取得先情報を参照して、不足チケットを入手する際に必要となる情報があれば、認証サーバ１２０へ通知する。

そして、ステップＳ３６０では、チケット取得部１００は、ステップＳ３４０又はＳ３５０で認証要求を依頼した認証サーバ１２０からの応答を待ち受ける。そして、認証サーバ１２０からチケットを受け取った場合にはステップＳ３８０へ移行する。ステップＳ３８０では、チケット取得部１００は、認証サーバ１２０から受け取ったチケットを取得完了の取得結果と共にチケット取得戦略部９０へ送信する。

一方、ステップＳ３６０の処理において、認証サーバ１２０からチケットの発行ができなかった旨の通知や、所定時間経過しても認証サーバ１２０から何も応答がない場合には、ステップＳ３７０へ移行する。

ステップＳ３７０では、チケット取得部１００は、チケットが取得できなかった旨の取得結果をチケット取得戦略部９０へ送信する。

なお、ステップＳ３１０の処理において、ステップＳ３００の処理で受信した通知の送信元がチケット取得戦略部９０ではない、すなわち、認証サーバ１２０からのものである場合には、ステップＳ３９０の処理が実行される。例えば、認証サーバ１２０が自発的にチケット取得部１００へチケットを送信した場合に、ステップＳ３９０の処理が実行される。

ステップＳ３９０では、認証サーバ１２０から通知されたものがチケットであれば、チケット取得部１００は通知されたチケットをチケット保管部１１０へ保存する。

以上の処理により、図７に示したチケット取得処理が終了する。

次に、認証サーバ１２０によって実行される認証処理について説明する。図８は、認証サーバ１２０によって実行される認証処理を示したフローチャートである。

なお、既に説明したように、認証サーバ１２０には、端末装置２０で取得した端末状態情報をチケット化する形態、チケット取得部１００からの認証要求なしに、自発的にチケットを送信する形態がある。その他、チケット取得部１００から認証要求を受け付けてチケットを発行する形態の認証サーバ１２０も存在する。ここでは一例として、チケット取得部１００から認証要求を受け付けてチケットを発行する形態の認証サーバ１２０のフローチャートを図８に示す。

まず、ステップＳ４００では、認証サーバ１２０はチケット取得部１００から認証要求を受信したか否か判定する。否定判定の場合には再びステップＳ４００へ移行して認証要求の受信を待ち受ける。一方、肯定判定の場合にはステップＳ４１０へ移行する。

ステップＳ４１０では、認証サーバ１２０は、認証要求と共に受信したチケットの取得先情報から端末状態情報を取得するセンサを特定する。これは、認証サーバ１２０では複数のセンサ７０を扱っている場合があるからである。

ステップＳ４２０では、認証サーバ１２０は、チケットを入手する際に必要となる情報がチケット取得部１００から通知されている場合、この情報を取得する。

ステップＳ４３０では、認証サーバ１２０は、ステップＳ４１０で特定した認証サーバ１２０付属のセンサ７０にステップＳ４２０で取得した情報を入力して、特定した認証サーバ１２０付属のセンサ７０から端末状態情報を取得する。なお、チケットを入手する際に必要となる情報がなければ、特定した認証サーバ１２０付属のセンサ７０から端末状態情報を取得する際、センサ７０に情報を入力する必要はない。

ステップＳ４４０では、認証サーバ１２０は、チケット取得部１００によって求められているチケットと、認証サーバ１２０付属のセンサ７０から取得された端末状態情報と、の間に矛盾がないか確認しチケット発行要件の確認を行う。

例えば、センサ７０が授業の時間割を出力するセンサ（時間割センサ）で、チケット取得部１００によって求められているチケットが数学補習チケットであるとする。また、時間割センサは、クラス名と時刻情報を入力すると、入力された時刻の際に入力されたクラスでどの科目の授業が行われているかを端末状態情報として出力するセンサであるとする。この場合に、チケット取得部１００によって求められているチケットが数学補習チケットであるにも関わらず、時間割センサが「国語」を出力すると、科目に相違があるとして、チケットの発行要件を満たしていないと判断する。

従って、チケット発行要件を確認せずにチケットを発行する場合と比較して、認証処理における信頼度を向上することができる。すなわち、情報処理システム１０で用いられるチケットの信頼度をより向上させることができる。

認証サーバ１２０は、チケット取得部１００によって求められているチケットと、認証サーバ１２０付属のセンサ７０から出力される端末状態情報との正しい関連付けを予め規定したチケット発行要件表を参照して、チケット発行要件の確認を実行する。

そして、認証サーバ１２０は、ステップＳ４５０においてチケット発行要件を満たしていると判定した場合にはステップＳ４６０へ移行し、チケット発行要件を満たしていないと判定した場合にはステップＳ４７０へ移行する。

そして、ステップＳ４６０では、認証サーバ１２０はステップＳ４３０の処理で認証サーバ１２０付属のセンサ７０から取得した端末状態情報をチケット化して、チケット取得部１００へ送信する。

一方、ステップＳ４７０では、要求されたチケットに対するチケット発行要件が満たされていないことから、認証サーバ１２０は、チケットが発行できなかった旨の通知をチケット取得部１００へ送信する。

以上の処理により、図８に示した認証処理が終了する。

次に、本実施形態に係るＧＷ装置３０の作用を説明する。本実施形態に係るＧＷ装置３０のチケット検証部１６０は、ＧＷ装置３０の起動後に図９に示すチケット検証処理を実行する。

まず、ステップＳ５００では、チケット検証部１６０は、端末装置２０のリソースアクセス部８０からパケットを受信したか否かを判定する。そして否定判定の場合には再びステップＳ５００へ移行し、パケットの受信を待ち受ける。一方、肯定判定の場合にはステップＳ５１０へ移行する。

ステップＳ５１０では、チケット検証部１６０は、ステップＳ５００の処理で受信したパケットから、アプリケーション部５０が要求するリソースのＵＲＬを抽出する。

ステップＳ５２０では、チケット検証部１６０は認可ポリシ２８６を参照して、ステップＳ５１０で抽出したリソースのＵＲＬへアクセスするために必要なチケット（必須チケット）を特定する。

図１０は、認可ポリシ２８６の一例を示した図であり、認可ポリシ２８６には、例えばリソースのＵＲＬと、当該リソースのＵＲＬへアクセスするために必要となるチケット名と、が対応付けられた情報が含まれる。

図１０に示す認可ポリシ２８６の例では、例えば、“http://foo.bar1.com/math”で表される数学補習教材のリソースへアクセスするためには、数学補習チケットが必要であることが記載されている。

また、リソースのアクセスにはデータへのアクセスの他、接続が制限されたネットワークへのアクセスも含まれる。例えば、図１０に示す認可ポリシ２８６の例では、接続が制限された“ＡＰ＃１”で表されるネットワークへアクセスするためには、ネットワーク１チケットが必要であることが規定されている。ここで“ＡＰ”とは、“アクセスポイント”を意味する略号である。

なお、リソースのアクセスに必要な必須チケットは１枚に限られない。複数の必須チケットが必要となる場合もある。

ステップＳ５３０では、チケット検証部１６０は、ステップＳ５００の処理で受信したパケットに付加されるチケットと、ステップＳ５２０の処理で特定した必須チケットと、を比較する。

そして、ステップＳ５４０では、チケット検証部１６０は、ステップＳ５２０の処理で特定した必須チケットのうち、不足しているチケットがあるか否かを判定する。そして、肯定判定の場合にはステップＳ５５０へ移行する。

ステップＳ５５０では、チケット検証部１６０はディレクトリ２８４を参照して、ステップＳ５４０の処理で不足していると判定されたチケットの取得先情報を取得する。

図１１は、ディレクトリ２８４の一例を示した図である。ディレクトリ２８４にはチケットの名前、チケットの取得先の名前、チケットの取得先ＵＲＬ、及びチケットを取得する際に必要となる情報を表した入力情報が対応付けられた情報が含まれる。

図１１に示すディレクトリ２８４の例では、数学補習チケットを取得するためには、取得先ＵＲＬ欄のＵＲＬで示された時間割認証サーバに、３年１組チケットと日時情報を入力すればよいことが示されている。また、数学補習チケットを取得するもう一つの方法として、取得先ＵＲＬ欄のＵＲＬで示された生徒情報認証サーバにユーザ認証情報を入力してもよいことが示されている。どちらの認証サーバからでも、同じ数学補習チケットを取得することができる。

同様に、３年１組チケットは、ＮＦＣサーバ及び無線ＬＡＮの何れからも取得でき、移動中チケットは移動判定１センサ及び移動判定２センサの何れからも取得できることが示されている。

このように、ディレクトリ２８４には、同じチケットに対して複数の取得先が存在する場合には、複数の取得先に関する情報が示される。

そして、チケット検証部１６０はディレクトリ２８４から、不足チケットに対応する全てのチケット取得方法を取得する。なお、不足チケットが複数ある場合には、各々のチケットについてディレクトリ２８４に記載されている全てのチケット取得方法を取得する。

そして、ステップＳ５６０では、チケット検証部１６０は、ステップＳ５５０で取得した不足チケットのチケット取得方法に基づいて、不足チケットの取得先情報をヘッダに付加した応答を生成する。例えば、数学補習チケットが不足していると判定された場合には、チケット検証部１６０は、時間割と生徒情報による取得先情報をヘッダに付加した応答を生成する。具体的には、チケット検証部１６０は、既に説明した図４に示したヘッダを含む応答を生成する。

そして、チケット検証部１６０は、生成した応答を端末装置２０のリソースアクセス部８０へ送信する。

一方、ステップＳ５４０の処理で、パケットにより要求されたリソースにアクセスするために必要な必須チケットが全て付加されていると判定された場合には、ステップＳ５７０へ移行する。

ステップＳ５７０では、チケット検証部１６０は、ステップＳ５００の処理で受信したパケットを、ステップＳ５１０の処理で抽出したリソースのＵＲＬで示されるリソース装置１９０へ転送する。そして、チケット検証部１６０は、リソース装置１９０から受信した応答を端末装置２０のリソースアクセス部８０へ転送する。

以上の処理により、図９に示したチケット検証処理が終了する。

このように、ＧＷ装置３０は、端末装置２０からパケットを受信した際、要求されたリソースにアクセスするのに必要なチケットがパケットに付加されているか否かを、認可ポリシ２８６を参照して検出する。更に、ＧＷ装置３０は、リソースにアクセスするのに必要なチケットが不足している場合、不足チケットがどこから取得できるのかを端末装置２０へ通知する。その際、ＧＷ装置３０は、不足チケットの取得先が複数存在する場合には、全ての取得先情報を通知する。

一方、端末装置２０は、不足チケットの取得先情報から取得コスト表２５０を参照してチケットの取得コストを算出し、取得コストの小さいチケットの取得先から優先して不足チケットを取得する。

従って、チケット取得の際、取得コストの高いチケットの取得先からチケットを取得せずに済むため、端末装置２０における処理の負荷を抑制することができる。

なお、情報処理システム１０は、ＧＷ装置３０に複数の端末装置２０が接続される形態であってもよい。この場合、ＧＷ装置３０のチケット検証部１６０は、端末装置２０から受信したパケット毎にパケットの送信元情報を一時的に記憶し、パケットに対応する応答を送信する際に読み出すようにすればよい。

以上、開示の技術を実施形態を用いて説明したが、開示の技術は上記実施形態に記載の範囲には限定されない。開示の技術の要旨を逸脱しない範囲で上記実施形態に多様な変更または改良を加えることができ、当該変更または改良を加えた形態も開示の技術の技術的範囲に含まれる。例えば、開示の技術の要旨を逸脱しない範囲で処理の順序を変更してもよい。

また、上記では端末内プロキシプログラム２３８が記憶部２２６に、ＧＷプロキシプログラム２７８が格納部２６６にそれぞれ予め記憶（インストール）されている態様を説明したが、これに限定されるものではない。開示の技術に係る端末内プロキシプログラム２３８及びＧＷプロキシプログラム２７８は、コンピュータ読取可能な記録媒体に記録されている形態で提供することも可能である。例えば、開示の技術に係る端末内プロキシプログラム２３８及びＧＷプロキシプログラム２７８は、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、及びＵＳＢメモリ等の可搬型記録媒体に記録されている形態で提供することも可能である。また、開示の技術に係る端末内プロキシプログラム２３８及びＧＷプロキシプログラム２７８は、フラッシュメモリ等の半導体メモリ等に記録されている形態で提供することも可能である。

また、本実施形態では、認証サーバ１２０を、端末装置２０、ＧＷ装置３０、及びリソース装置１９０が接続されるネットワーク４０に接続する形態を説明したが、認証サーバ１２０の接続形態はこれに限られない。

例えば、認証サーバ１２０をネットワーク４０とは分離されたネットワークに接続するようにしてもよい。この場合、端末装置２０、ＧＷ装置３０、及びリソース装置１９０の管理者と異なる管理者が認証サーバ１２０を管理することができるようになる。従って、より柔軟な情報処理システムが構築できると共に、チケットに関する信頼度が向上する。また、ＧＷ装置３０の機能をクラウドサービスとして提供するようにしてもよい。

なお、本実施形態では、端末装置２０の状態をチケットとして扱ったが、チケット化される前の端末状態情報を端末装置２０の状態を表す情報として用いてもよい。この場合、

端末状態情報をチケット化する必要がないため、端末状態情報の取得に要する時間の短縮が期待され、取得コストが低くなる場合がある。しかし、一方で、端末装置２０の状態をチケットとして扱う場合に比べて、情報処理システム１０全体の信頼性が低下する恐れがある。

以上の実施形態に関し、更に以下の付記を開示する。

（付記１）
外部に格納されたアクセス対象の情報に対するアクセス要求に、自装置の状態を示す状態情報を付加して情報管理装置へ送信し、前記アクセス対象の情報にアクセスする際に不足する不足状態情報の送信依頼を受信する通信部と、
前記不足状態情報を取得する取得処理を実行する取得部と、
前記通信部が受信した送信依頼で示される不足状態情報が複数の取得先から取得可能な場合に、前記複数の取得先毎の前記不足状態情報を取得する際の取得負荷に基づいて、不足状態情報の取得負荷が小さい取得先から優先して前記取得処理を実行するように前記取得部を制御すると共に、前記取得部が取得した不足状態情報を前記情報管理装置に送信するように前記通信部を制御する制御部と、
を含む端末装置。

（付記２）
前記自装置の状態を示す状態情報及び前記取得部が取得する不足状態情報には、前記情報管理装置に対して信用関係を有することを示す信用情報が含まれる
付記１記載の端末装置。

（付記３）
前記取得部は、前記信用情報を生成する認証装置から不足状態情報を取得する
付記２記載の端末装置。

（付記４）
自装置の状態を示す状態情報を記憶する記憶部を更に備え、
前記制御部は、前記不足状態情報が前記記憶部に記憶されている場合、前記不足状態情報に対応する状態情報を前記記憶部から取得して前記情報管理装置へ送信するように前記通信部を制御する
付記１〜付記３の何れか１項に記載の端末装置。

（付記５）
前記取得負荷は、状態情報の取得開始から取得終了までの取得時間の長さに基づいて設定され、前記取得時間が短くなるほど取得負荷が小さく設定される
付記１〜付記４の何れか１項に記載の端末装置。

（付記６）
前記取得部は、前記情報管理装置が接続される通信回線とは異なる通信回線を経由して、前記認証装置から不足状態情報を取得する
付記３記載の端末装置。

（付記７）
外部に格納されたアクセス対象の情報に対するアクセス要求を受信し、前記アクセス対象の情報にアクセスする際に必要となる状態情報が前記アクセス要求に付加されていない場合に、前記アクセス対象の情報にアクセスする際に不足する不足状態情報を、前記不足状態情報の取得先と共に前記アクセス要求の送信元へ送信する通信制御部
を含む情報管理装置。

（付記８）
コンピュータに、
外部に格納されたアクセス対象の情報に対するアクセス要求に、自装置の状態を示す状態情報を付加して情報管理装置へ送信し、前記アクセス対象の情報にアクセスする際に不足する不足状態情報の送信依頼を受信し、
前記不足状態情報を取得し、
前記送信依頼で示される不足状態情報が複数の取得先から取得可能な場合に、前記複数の取得先毎の前記不足状態情報を取得する際の取得負荷に基づいて、不足状態情報の取得負荷が小さい取得先から優先して前記送信依頼で示される不足状態情報を取得するよう制御し、取得した不足状態情報を前記情報管理装置へ送信するよう制御する
ことを含む処理を実行させるための端末プログラム。

（付記９）
前記自装置の状態を示す状態情報及び取得した不足状態情報には、前記情報管理装置に対して信用関係を有することを示す信用情報が含まれる
付記８記載の端末プログラム。

（付記１０）
前記信用情報を生成する認証装置から不足状態情報を取得する
付記９記載の端末プログラム。

（付記１１）
自装置の状態を示す状態情報を記憶し、
前記不足状態情報が記憶されている場合、前記不足状態情報に対応する状態情報を取得して前記情報管理装置へ送信するように制御する
付記８〜付記１０の何れか１項に記載の端末プログラム。

（付記１２）
前記取得負荷は、状態情報の取得開始から取得終了までの取得時間の長さに基づいて設定され、前記取得時間が短くなるほど取得負荷が小さく設定される
付記８〜付記１１の何れか１項に記載の端末プログラム。

（付記１３）
前記情報管理装置が接続される通信回線とは異なる通信回線を経由して、不足状態情報を取得する
付記１０記載の端末プログラム。

（付記１４）
コンピュータに、
外部に格納されたアクセス対象の情報に対するアクセス要求を受信し、前記アクセス対象の情報にアクセスする際に必要となる状態情報が前記アクセス要求に付加されていない場合に、前記アクセス対象の情報にアクセスする際に不足する不足状態情報を、前記不足状態情報の取得先と共に前記アクセス要求の送信元へ送信する
ことを含む処理を実行させるための情報管理プログラム。

（付記１５）
コンピュータに、
外部に格納されたアクセス対象の情報に対するアクセス要求に、自装置の状態を示す状態情報を付加して情報管理装置へ送信し、前記アクセス対象の情報にアクセスする際に不足する不足状態情報の送信依頼を受信し、
前記不足状態情報を取得し、
前記送信依頼で示される不足状態情報が複数の取得先から取得可能な場合に、前記複数の取得先毎の前記不足状態情報を取得する際の取得負荷に基づいて、不足状態情報の取得負荷が小さい取得先から優先して前記送信依頼で示される不足状態情報を取得するよう制御し、取得した不足状態情報を前記情報管理装置へ送信するよう制御する
ことを含む処理を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

（付記１６）
コンピュータに、
外部に格納されたアクセス対象の情報に対するアクセス要求を受信し、前記アクセス対象の情報にアクセスする際に必要となる状態情報が前記アクセス要求に付加されていない場合に、前記アクセス対象の情報にアクセスする際に不足する不足状態情報を、前記不足状態情報の取得先と共に前記アクセス要求の送信元へ送信する
ことを含む処理を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

（付記１７）
アクセス対象の情報を記憶する記憶装置と、
前記アクセス対象の情報に対するアクセス要求に、自装置の状態を示す状態情報を付加して情報管理装置へ送信し、前記アクセス対象の情報にアクセスする際に不足する不足状態情報の送信依頼を受信する通信部と、前記不足状態情報を取得する取得処理を実行する取得部と、前記通信部が受信した送信依頼で示される不足状態情報が複数の取得先から取得可能な場合に、前記複数の取得先毎の前記不足状態情報を取得する際の取得負荷に基づいて、不足状態情報の取得負荷が小さい取得先から優先して前記取得処理を実行するように前記取得部を制御すると共に、前記取得部が取得した不足状態情報を前記情報管理装置に送信するように前記通信部を制御する制御部と、を含む端末装置と、
前記アクセス要求を受信し、前記アクセス対象の情報にアクセスする際に必要となる状態情報が前記アクセス要求に付加されていない場合に、前記アクセス対象の情報にアクセスする際に不足する不足状態情報を、前記不足状態情報の取得先と共に前記アクセス要求の送信元へ送信する通信制御部を含む情報管理装置と、
不足状態情報に信用情報を付加して前記端末装置に提供する認証装置と、
を含む情報処理システム。

１０ 情報処理システム
２０ 端末装置
３０ ゲートウェイ装置
４０ ネットワーク
７０ センサ
１２０ 認証サーバ
１９０ リソース装置
２２２、２６２、２９２、３１２ ＣＰＵ
２２４、２６４、２９４、３１４ メモリ
２２６ 記憶部
２３８ 端末内プロキシプログラム
２５０ 取得コスト表
２６６ 格納部
２７８ ＧＷプロキシプログラム
２８４ ディレクトリ
２８６ 認可ポリシ

Claims (10)

1. 外部に格納されたアクセス対象の情報に対するアクセス要求に、自装置の状態を示す状態情報を付加して情報管理装置へ送信し、前記アクセス対象の情報にアクセスする際に不足する不足状態情報の送信依頼を受信する通信部と、
   前記不足状態情報を取得する取得処理を実行する取得部と、
   前記通信部が受信した送信依頼で示される不足状態情報が複数の取得先から取得可能な場合に、前記複数の取得先毎の前記不足状態情報を取得する際の取得負荷に基づいて、不足状態情報の取得負荷が小さい取得先から優先して前記取得処理を実行するように前記取得部を制御すると共に、前記取得部が取得した不足状態情報を前記情報管理装置に送信するように前記通信部を制御する制御部と、
   を含む端末装置。
2. 前記自装置の状態を示す状態情報及び前記取得部が取得する不足状態情報には、前記情報管理装置に対して信用関係を有することを示す信用情報が含まれる
   請求項１記載の端末装置。
3. 前記取得部は、前記信用情報を生成する認証装置から不足状態情報を取得する
   請求項２記載の端末装置。
4. 自装置の状態を示す状態情報を記憶する記憶部を更に備え、
   前記制御部は、前記不足状態情報が前記記憶部に記憶されている場合、前記不足状態情報に対応する状態情報を前記記憶部から取得して前記情報管理装置へ送信するように前記通信部を制御する
   請求項１〜請求項３の何れか１項に記載の端末装置。
5. 前記取得負荷は、状態情報の取得開始から取得終了までの取得時間の長さに基づいて設定され、前記取得時間が短くなるほど取得負荷が小さく設定される
   請求項１〜請求項４の何れか１項に記載の端末装置。
6. 前記取得部は、前記情報管理装置が接続される通信回線とは異なる通信回線を経由して、前記認証装置から不足状態情報を取得する
   請求項３記載の端末装置。
7. 外部に格納されたアクセス対象の情報に対するアクセス要求を受信し、前記アクセス対象の情報にアクセスする際に必要となる状態情報が前記アクセス要求に付加されていない場合に、前記アクセス対象の情報にアクセスする際に不足する不足状態情報を、前記不足状態情報の取得先と共に前記アクセス要求の送信元へ送信する通信制御部
   を含む情報管理装置。
8. コンピュータに、
   外部に格納されたアクセス対象の情報に対するアクセス要求に、自装置の状態を示す状態情報を付加して情報管理装置へ送信し、前記アクセス対象の情報にアクセスする際に不足する不足状態情報の送信依頼を受信し、
   前記不足状態情報を取得し、
   前記送信依頼で示される不足状態情報が複数の取得先から取得可能な場合に、前記複数の取得先毎の前記不足状態情報を取得する際の取得負荷に基づいて、不足状態情報の取得負荷が小さい取得先から優先して前記送信依頼で示される不足状態情報を取得するよう制御し、取得した不足状態情報を前記情報管理装置へ送信するよう制御する
   ことを含む処理を実行させるための端末プログラム。
9. コンピュータに、
   外部に格納されたアクセス対象の情報に対するアクセス要求を受信し、前記アクセス対象の情報にアクセスする際に必要となる状態情報が前記アクセス要求に付加されていない場合に、前記アクセス対象の情報にアクセスする際に不足する不足状態情報を、前記不足状態情報の取得先と共に前記アクセス要求の送信元へ送信する
   ことを含む処理を実行させるための情報管理プログラム。
10. アクセス対象の情報を記憶する記憶装置と、
    前記アクセス対象の情報に対するアクセス要求に、自装置の状態を示す状態情報を付加して情報管理装置へ送信し、前記アクセス対象の情報にアクセスする際に不足する不足状態情報の送信依頼を受信する通信部と、前記不足状態情報を取得する取得処理を実行する取得部と、前記通信部が受信した送信依頼で示される不足状態情報が複数の取得先から取得可能な場合に、前記複数の取得先毎の前記不足状態情報を取得する際の取得負荷に基づいて、不足状態情報の取得負荷が小さい取得先から優先して前記取得処理を実行するように前記取得部を制御すると共に、前記取得部が取得した不足状態情報を前記情報管理装置に送信するように前記通信部を制御する制御部と、を含む端末装置と、
    前記アクセス要求を受信し、前記アクセス対象の情報にアクセスする際に必要となる状態情報が前記アクセス要求に付加されていない場合に、前記アクセス対象の情報にアクセスする際に不足する不足状態情報を、前記不足状態情報の取得先と共に前記アクセス要求の送信元へ送信する通信制御部を含む情報管理装置と、
    不足状態情報に信用情報を付加して前記端末装置に提供する認証装置と、
    を含む情報処理システム。

Images