JP2016039427A - 判定装置，端末装置，判定プログラム，端末プログラム，及び通信システム - Google Patents

Abstract

【課題】端末装置に関する情報に応じて端末装置から情報処理装置への通信可否が変化する通信システムにおける負荷を低減させる。【解決手段】端末装置２から前記端末装置２の状態変化を契機に送信される当該端末装置２の状態に関する複数の状態情報について、前記端末装置２で実行されるアプリケーション２１０が情報処理装置３と通信可能になるための条件であって前記端末装置２に関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定する判定部と、前記判定部によって前記複数の状態情報により前記条件が満たされると判定されたアプリケーション２１０の情報を、前記端末装置２に送信する送信部と、をそなえる。【選択図】図４

Description

本発明は、判定装置，端末装置，判定プログラム，端末プログラム，及び通信システムに関する。

近年、モバイル端末等の携帯型端末（端末装置）の普及やネットワークインフラの充実により、時刻や場所を問わず、端末を利用して業務を行なうことが可能になっている。例えばユーザは、端末のアプリケーション（端末アプリ）を通じて、サーバと通信（サーバにアクセス）し、サーバの提供するｗｅｂコンテンツやｗｅｂサービス等の業務に関する種々のデータや機能等のサービス（リソース）を利用することができる。

一方、このような業務形態は、ユーザや作業環境についての管理の行き届かない場所や時間で、ユーザが端末を用いてサーバにアクセス可能であることを意味する。

そこで、このような通信環境（通信システム）では、情報セキュリティの観点から、端末からサーバへのアクセスに制限が設けられることがある。アクセス制御の例として、サーバ（情報処理装置）が、端末の状態に関する情報に基づきリソースへのアクセスを許可するか否かを決定する手法が挙げられる。

なお、関連する技術として、端末の状態に関する情報に応じて端末の動作状態を切り替える技術も知られている（例えば、特許文献１参照）。このような技術では、例えば、事前に設定したルールに従い、端末の状態（例えば位置等）に応じてモニタ，ＨＤＤ（Hard Disk Drive），アプリ等の動作状態を切り替えることで、端末のバッテリ利用を最適化することができる。

特表２００４−５２６２５４号公報

アクセス制限下では、端末はサーバへのアクセス許可を得るため、端末の状態に関する情報をサーバへ送信することが考えられる。しかし、ユーザは端末がアクセス許可を得られる状態になったか否かを把握することが困難である。このため、ユーザが端末アプリによりサーバへのアクセス要求を何度も試行し、その都度サーバからアクセス拒否（利用不可）の応答を受ける場合があり、ネットワーク，端末，及びサーバ等の通信システムの負荷（通信コスト）が増加し得る。

また、端末の状態に関する情報に応じて端末の動作状態を切り替える技術は、動作状態を決定するルールが事前に端末に配備済みであることを想定している。そこで、この技術を通信システムに適用し、通信システムの端末にサーバでのアクセス可否判定に用いられる認可ポリシを配備することも考えられる。しかし、この場合、端末数が多くなると、運用管理者が認可ポリシを変更する都度、アクセスの許可条件を全端末に配備することになり、通信システムのネットワークトラフィックが増大し得る。また、端末がネットワークに未接続或いは電源ＯＦＦの状態の場合には、端末に配備された許可条件を即座に変更することが困難となり得る。

なお、上述した課題は、端末及びサーバを利用して業務を行なう場合に限られるものではなく、端末装置の状態に関する情報に応じて端末装置から情報処理装置への通信可否が変化する種々の通信システムにおいて同様に生じ得る。

１つの側面では、本発明は、端末装置の状態に関する情報に応じて端末装置から情報処理装置への通信可否が変化する通信システムにおける負荷を低減させることを目的とする。

なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。

１つの態様では、本件の判定装置は、判定部と送信部とをそなえる。前記判定部は、端末装置から前記端末装置の状態変化を契機に送信される当該端末装置の状態に関する複数の状態情報について、前記端末装置で実行されるアプリケーションが情報処理装置と通信可能になるための条件を満たすか否かを判定する。なお、前記条件は、前記端末装置に関する一以上の状態情報の組み合わせで表される条件である。また、送信部は、前記判定部によって前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を、前記端末装置に送信する。

１つの側面では、端末装置の状態に関する情報に応じて端末装置から情報処理装置への通信可否が変化する通信システムにおける負荷を低減させることができる。

端末からリソースサーバへアクセスする際のアクセス制御の一例を示す図である。 プロキシを設けた場合の端末からリソースサーバへアクセスする際のアクセス制御の一例を示す図である。 チケットの一例を示す図である。 一実施形態に係る通信システムの構成例を示す図である。 チケットの自動更新に伴う利用可能アプリの通知例を説明する図である。 図４に示す通信システムの適用例を示す図である。 図６に示す通信システムの機能構成例を示す図である。 図７に示すチケット管理テーブルの一例を示す図である。 チケット送信要求の一例を示す図である。 図７に示す認可ポリシ管理テーブルの一例を示す図である。 チケット送信応答の一例を示す図である。 一実施形態に係るチケット管理部及びアクセス制御部による利用可能アプリ判定処理の一例を説明するフローチャートである。 チケットの検索パターンの一例を説明する図である。 一実施形態の変形例に係る通信システムの機能構成を示す図である。 図１４に示す判定履歴管理テーブルの一例を示す図である。 図１４に示す絞り込み判定テーブルの一例を示す図である。 一実施形態の変形例に係るチケット管理部及びアクセス制御部による利用可能アプリ判定処理を説明するフローチャートである。 一実施形態の変形例に係るアクセス制御部による絞り込み判定テーブル生成処理を説明するフローチャートである。 図６又は図１４に示す端末及びアクセス制御サーバのハードウェア構成例を示す図である。

以下、図面を参照して本発明の実施の形態を説明する。ただし、以下に説明する実施形態は、あくまでも例示であり、以下に明示しない種々の変形や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。なお、以下の実施形態で用いる図面において、同一符号を付した部分は、特に断らない限り、同一若しくは同様の部分を表す。

〔１〕対比例について
はじめに、図１〜図３を参照しながら、一実施形態の対比例について説明する。図１に例示するように、通信システム１００Ａは、端末１１０及びリソースサーバ１２０を有し、端末１１０からのサービスアクセス要求に応じて、リソースサーバ１２０がサービス応答にてサービス（リソース）を提供する。また、端末１１０からリソースサーバ１２０へのアクセスには制限が設けられている。

端末１１０で実行されるアプリケーション（以下、端末アプリともいう）１１１は、端末１１０の状況やユーザ（端末利用者）の状況等、端末装置１１０の状態に関する情報（状態情報）を取得し、サービスアクセス要求に付加して送信する。

ここで、端末１１０の状態情報には、端末１１０又はユーザの空間的或いは時間的な属性等が含まれ得る。例えば、状態情報には、端末１１０の位置情報等によって表されるユーザの場所，ユーザの所属先や所属先における身分等のユーザ権限，ユーザが休憩中か作業中かといった就業状態等が含まれてよい。なお、端末１１０の状態情報には、端末１１０の状態，ユーザの状態，並びに端末１１０及びユーザの周辺の状態等の種々の状態（状況）を含んでもよい。

以下、簡単のため、ユーザの職業が教師であり、サーバ１２０により端末１１０のリソースへのアクセス可否の判断に用いられる情報が、ユーザ（端末１１０）の場所，ユーザ権限，及び就業状態であるものとして説明する。

例えば、ユーザは無線等で端末１１０に接続されたカードリーダ等の認証装置１１４に自身の身分証に記憶されている情報を読み取らせること等により、端末アプリ１１１に自身のユーザ権限が“教師権限”であることを通知する。

また、例えば、認証装置１１４は、身分証の情報を読み取った時刻情報及び教師ＩＤ（Identification；識別子）等をユーザの出勤スケジュールを記憶するスケジューラ装置１１３に無線等で通知する。スケジューラ装置１１３は、教師の出勤スケジュールと通知された時刻情報及び教師ＩＤとに基づいてユーザが勤務時間中であると判断した場合、端末アプリ１１１にユーザの就業状態が“就業中”であることを無線等で通知する。

さらに、例えば、端末アプリ１１１は、端末１１０に内蔵されているＧＰＳ（Global Positioning System）センサ等の場所センサ１１２が出力する位置情報を取得する。そして、端末アプリ１１１は、取得した位置情報が、施設や領域等のエリアと位置情報とが対応付けられた場所情報のうち、例えば“教室Ａ”の場所情報の範囲内に含まれる場合、ユーザの居場所を“教室Ａ”と判定する。

そして、端末アプリ１１１は、ユーザが利用したいリソースに対して予め定められた状態情報をサービスアクセス要求に付加し、リソースサーバ１２０へ送信する。

リソースサーバで１２０は、認可ポリシを参照して、端末１１０から受信した情報でリソースにアクセス可能か否か判定し、アクセス可能であれば、要求されたサービス（リソース）を含むサービス応答を端末１１０へ送信する。

例えば、端末１１０から要求されたリソースの認可ポリシが（ユーザ権限，就業状態）＝（教師権限，就業中）又は（場所）＝（自宅）である場合、リソースサーバ１２０はサービスアクセス要求に付加された状態情報が認可ポリシを充足する場合にリソースへのアクセスを許可する。図１に示す例では、サービスアクセス要求に付加された状態情報が、認可ポリシにおける認可条件（教師権限，就業中）を充足するため、リソースサーバ１２０は、教師が要求するリソースをサービス応答に付加して、サービスアクセス要求の送信元である端末１１０の端末アプリ１１１へ送信する。

以上のように、ユーザは、就業中であればリソースサーバ１２０が提供する生徒の情報管理を行なう教務用サービスへのアクセスを許可される。一方、仕事が終わり、校外にいる場合やプライベートな時間ではセキュアな環境とはいえない（認可ポリシにおける認可条件を満たさない）ため、ユーザ（端末１１０）による教務用サービスへのアクセスは禁止される。なお、ユーザが自宅に戻った場合、業務と無関係な人との接近がなくセキュアであるといえる（認可ポリシにおける認可条件（場所）＝（自宅）を満たす）ため、ユーザによる教務用サービスへのアクセスが再び許可される。

図１に例示する通信システム１００Ａによれば、上述のような端末１１０の状態情報に依存したアクセス制御が実現される。

しかし、こうしたリソースに対するアクセス権の制御手法では、端末アプリ１１１自身が状態情報を収集してリソースサーバ１２０に提示するため、状態情報の信頼性が担保されない。例えば、サービスアクセス要求に付加される状態情報が、実際の端末１１０やユーザの状況とは異なる状況を表す状態情報に改ざんされた場合、実際の端末１１０やユーザの状況が認可ポリシの認可条件を満たしていなくてもリソースが取得されてしまう場合がある。

また、通信システム１００Ａを実現するためには、状態情報の収集，状態情報のサービスアクセス要求への付加等の機能を既存の端末アプリに、認可判定等の機能を既存のリソースサーバ（のアプリケーション）に、それぞれ新たに設けることになる。従って、上述した制御手法を既存の端末アプリ及びリソースサーバに適用することは困難である。

そこで、図２に例示する通信システム１００Ｂのように、端末１３０内のアプリケーション１３１と通信ネットワークとの間にチケット付加プロキシ１３５を設け、通信ネットワークとリソースサーバ１４０との間にアクセス制御プロキシ１５０を設けることが考えられる。

チケット付加プロキシ１３５は、状態情報を収集し、端末アプリ１３１から受信したサービスアクセス要求のヘッダに状態情報を付加してアクセス制御プロキシ１５０へ中継するとともに、アクセス制御プロキシ１５０から受信した応答を端末アプリ１３１へ中継する。なお、図２の例では、チケット付加プロキシ１３５が端末１３０に設けられるものとしたが、端末１３０の外部に配置されてもよい。また、端末１３０の状態情報は、上述した端末１１０の状態情報と基本的に同様のものである。

アクセス制御プロキシ１５０は、端末１３０から受信したサービスアクセス要求のヘッダに付加された状態情報と、予め登録されている認可ポリシの認可条件とを照合し、認可条件を満たす場合にサービスアクセス要求をリソースサーバ１４０へ中継する。また、アクセス制御プロキシ１５０は、中継したサービスアクセス要求に対応するリソースサーバ１４０からの応答を、サービスアクセス要求の送信元である端末１３０のチケット付加プロキシ１３５へ中継する。

通信システム１００Ｂでは、状態情報の通知元の装置（例えば端末１３０），チケット付加プロキシ１３５，及びアクセス制御プロキシ１５０は、状態情報自体が改ざんされないよう、例えば暗号化等が施された互いに信頼できる状態情報を用いる。

なお、以下、信頼できる状態情報を“チケット”といい、特に断らない限り、単に“状況情報”という場合にはこの“状態情報”はチケットを表すものとする。また、以下の説明では、チケット付加プロキシを“端末プロキシ”といい、アクセス制御プロキシを“制御プロキシ”という場合がある。

チケットは、端末１３０の状態情報の改ざんを防ぐために、端末プロキシ１３５及び制御プロキシ１５０でのみ復号できるように暗号化されたデータである。端末プロキシ１３５は、場所センサ１３２等のセンサデータを外部のサービスや内部モジュールを利用してチケット化したり、外部のサービスから直接チケットを取得したりすることが可能である。なお、センサデータとしては、例えば場所センサ１３２が取得した位置情報が挙げられる。また、外部のサービス又は内部モジュールとしては、例えば場所情報を管理する装置やスケジューラ装置１３３，認証装置１３４等が挙げられる。

図３に示すように、暗号化前のチケットは、チケットＩＤ（識別子），チケット種別，チケット名，有効期限，及びチケット発行元情報を含んでよい。チケットＩＤはチケットを識別するための情報であり、チケット種別はチケットの属性、例えばチケットが場所，ユーザ権限，就業状態等のいずれに関する情報なのかを示す情報である。チケット名はチケット種別で示された種別に関する具体的な内容を示し、例えばチケット種別が“場所”であれば“校内”，“自宅”等が設定される。

有効期限は、当該チケットの有効期限を示すものであり、例えば１９７０年１月１日午前０時からの経過時間をミリ秒で表したものが用いられる。なお、有効期限経過後は、当該チケットは制御プロキシ１５０において無効なチケットとして扱われる。チケット発行元情報はチケットを端末プロキシ１３５へ発行（通知）した装置等を識別するための情報であり、例えばその装置のネットワーク上の所在を示すＵＲＬ（Uniform Resource Location）で表される。

暗号化前のチケットは、チケット発行元によって例えば予め定めたビット数の暗号鍵で暗号化される。そして、例えば端末アプリ１３１からのサービスアクセス要求がＨＴＴＰ（Hypertext Transfer Protocol）リクエストにより表される場合、端末プロキシ１３５は、暗号化したチケットをＢａｓｅ６４でエンコードする。さらに、端末プロキシ１３５は、エンコードしたチケットをサービスアクセス要求のヘッダに付加する。なお、端末プロキシ１３５及び制御プロキシ１５０はチケット発行元の暗号鍵に対する公開鍵を予め所有しているものとする。

以上のように、図２に例示する通信システム１００Ｂによれば、端末プロキシ１３５及び制御プロキシ１５０にリソースに対するアクセス権の制御処理が実装されるため、端末アプリ１３１及びリソースサーバ１４０を改修しなくてよい。また、端末プロキシ１３５及び制御プロキシ１５０をリソースの管理者が管理するようにすれば、各プロキシに対する悪意ある改ざんの検出が可能となる。従って、図１に示した制御手法に比べて、サービスアクセス要求に付加される状態情報の信頼性が向上する。さらに、状態情報として、暗号化等が施された互いに信頼できるチケットが用いられるため、サービスアクセス要求に付加される状態情報の信頼性が更に向上する。

ところで、チケットは、端末１３０等においてセンシングにより自動的に更新されるため、ユーザは端末アプリ１３１がリソースサーバ１４０と通信可能（利用可能）になったか否かをリアルタイムで把握することは困難である。このため、ユーザが端末アプリ１３１を実際に何度も操作し、サービスアクセス要求の発行を試行することになるが、手間がかかる上に、サービスが利用不可の場合には不要な通信コストが増加してしまう。

〔２〕一実施形態
そこで、一実施形態に係る通信システムでは、端末のチケットが変化し端末アプリが利用可能（リソースサーバと通信可能）になった場合に、自動的に端末のユーザへ通知或いは端末アプリを起動するようになっている。図４は、一実施形態に係る通信システム１の構成例を示す図である。

一例として、図４に示す通信システム１は、アプリケーション（以下、単にアプリともいう）２１０及びチケット管理部２０を有する端末２と、アクセス制御部４０を有するアクセス制御サーバ４とをそなえることができる。

チケット管理部２０は、例えば、チケットの登録，削除等、状態情報の状態変化を契機に、端末２内に保持するチケットを、チケット送信要求に含めて認可ポリシを管理するアクセス制御サーバ４に送信する。なお、端末２において、チケットは、場所センサ２１１，スケジューラ２１２，及び認証装置２１３等の外部のサービス又は内部モジュール等によって生成又は削除され得る。チケット管理部２０は、このようなチケットの生成又は削除等の情報を状態情報の状態変化として検出する。

アクセス制御部４０は、例えば、認可ポリシの各チケット条件（認可条件）を端末２から受信したチケットと照合し、いずれかのサービスと通信可能（利用可能）な端末アプリ２１０を判定して、利用可能アプリ２１０をチケット送信応答に含めて端末２に返信する。

一例として、アクセス制御部４０は、図４に示す“教室Ａチケット”，“教師チケット”，“就業中チケット”，“ＺＺＺチケット”を端末２から受信した場合、認可ポリシのチケット条件（認可条件）を参照する。そして、アクセス制御部４０は、認可ポリシから、受信したチケット（教室Ａ，教師，就業中，ＺＺＺ）によってチケット条件が満たされるアプリを検索する。図４の例では、アクセス制御部４０は、チケット条件（教師Ａ，教師）が満たされると判定し、アプリ＃１の情報をチケット送信応答に含めて端末２に通知する。

図２に示す通信システム１００Ｂでは、端末アプリ１３１が制御プロキシ１５０にサービスと通信可能なチケット条件を求めており、制御プロキシ１５０が、要求された端末アプリ１３１の認可条件と受信したチケットとを比較する順方向の検索を行なう。これに対し、一実施形態に係る利用可能アプリ判定処理では、アクセス制御サーバ４が、受信したチケットからサービスと通信可能になったアプリ２１０を検出する逆方向の検索を行なうのである。

このように、通信システム１によれば、図５に例示するように、端末２やユーザの状況が変化すると、役割チケット発行サービスや場所チケット発行サービス等によりチケットが自動更新される。そして、チケットが変化したタイミングで、端末２及びアクセス制御サーバ４による利用可能アプリ判定処理が行なわれる。従って、図５に示すように、例えば端末２の位置情報が“廊下１”から“教室Ａ”に変化したときに、アクセス制御サーバ４により授業アプリが利用可能になったと判断される。これにより、端末２は、例えば表示領域に利用可能になった授業アプリの情報を表示する等、種々の出力手法によってユーザに通知することができる。

以下、一実施形態に係る通信システムの詳細について説明する。

〔２−１〕通信システムの構成例
図６は、図４に示す通信システム１の適用例を示す図である。一実施形態に係る通信システム１は、例示的に１台以上（図６の例では１台）の端末２，リソースサーバ３，及びアクセス制御サーバ４をそなえることができる。なお、端末２−アクセス制御サーバ４間並びにアクセス制御サーバ４−リソースサーバ３間は、それぞれ例えば無線又は有線のネットワークとすることができる（図示省略）。ネットワークとしては、例えばインターネット又はイントラネットが挙げられる。

端末２は、リソースサーバ３が提供する種々のサービス（リソース）を利用する端末装置（コンピュータ）の一例である。端末装置としては、無線通信が可能な情報処理装置、例えば携帯型端末や、輸送機械等の乗物に設置された端末（一例としてカーナビ）等が挙げられる。なお、携帯型端末には、携帯電話，スマートフォン，タブレット，ノートＰＣ（Personal Computer），携帯型ゲーム機等のモバイル端末が含まれてよい。

図６に示すように、端末２は、例示的に、図４に示すチケット管理部２０をそなえるとともに、複数のアプリケーション２１０，チケット付加プロキシ（以下、端末プロキシという）２２０，及び記憶部２３をそなえることができる。

アプリケーション２１０は、例えば端末２のＯＳ（Operating System）上で動作するプログラムであり、端末プロキシ２２０及びアクセス制御サーバ４（アクセス制御プロキシ４１０）を介してリソースサーバ３へのアクセスを行なうことができる。例えばアプリケーション２１０は、リソースサーバ３が提供するサービスへのアクセスを要求するサービスアクセス要求を生成及び送信し、リソースサーバ３から受信するサービス応答に基づきサービスを利用することができる。なお、アプリケーション２１０としては既存のものを用いることができる。

端末プロキシ２２０は、状態情報（チケット）を収集し、端末アプリ２１０から受信したサービスアクセス要求のヘッダに状態情報を付加してアクセス制御サーバ４へ中継する。また、端末プロキシ２２０は、アクセス制御サーバ４から受信した応答を端末アプリ２１０へ中継する。なお、一実施形態に係る端末プロキシ２２０は、図２に示す端末プロキシ１３５の少なくとも一部の機能を含んでよい。

記憶部２３は、端末２で取得された１以上のチケットを格納する記憶領域である。チケット管理部２０は、記憶部２３にアクセスして、チケットの登録，削除等の更新処理を行なうとともに、チケット送信要求に付加するチケットを参照することができる。また、端末プロキシ２２０は、記憶部２３にアクセスして、サービスアクセス要求に付加するチケットを参照することができる。なお、記憶部２３の機能はチケット管理部２０に含まれるものとしてもよい（図７参照）。また、記憶部２３が格納するチケットは、上述した端末１３０のチケット（図３参照）と同様のものであってよい。

リソースサーバ３は、ｗｅｂコンテンツやｗｅｂサービス等の種々のデータや機能等のサービス（リソース）を端末２に提供するサービス提供装置（情報処理装置）の一例である。リソースサーバ３は、例えば教務用サービスや企業又は店舗用サービス等の業務に関するサービス（各種管理システム）を提供することができる。なお、リソースサーバ３は、会員サービス等の顧客向けサービスを提供してもよい。サービス提供装置としては、例えばＰＣやサーバ等の情報処理装置が挙げられる。

リソースサーバ３では、特定の端末２又は特定のユーザに対してサービスを提供することができ、端末２（又はユーザ）を制限するために、アクセス制御サーバ４におけるアクセス制御を用いることができる。

アクセス制御サーバ４は、端末２との間で端末２のチケットについて利用可能アプリ判定処理を行なうとともに、端末２からリソースサーバ３へのアクセスについてアプリ通信可否判定処理を行なう判定装置（コンピュータ）の一例である。判定装置としては、例えばＰＣやサーバ等の情報処理装置が挙げられる。

図６に示すように、アクセス制御サーバ４は、例示的に、図４に示すアクセス制御部４０をそなえるとともに、アクセス制御プロキシ（以下、制御プロキシという）４１０，及び記憶部４４をそなえることができる。

制御プロキシ４１０は、端末２から受信したサービスアクセス要求のヘッダに付加された状態情報（チケット）と、予め登録されている認可ポリシの認可条件とを照合し、認可条件を満たす場合にサービスアクセス要求をリソースサーバ３へ中継する。なお、制御プロキシ４１０は、認可条件を満たさない場合には通信不可（アクセス不可，利用不可）を示すサービス応答を端末プロキシ２２０へ送信する。また、制御プロキシ４１０は、中継したサービスアクセス要求に対応するリソースサーバ３からの応答を、サービスアクセス要求の送信元である端末２の端末プロキシ２２０へ中継する。なお、制御プロキシ４１０は、図２に示す制御プロキシ１５０の少なくとも一部の機能を含んでよい。

以上のように、制御プロキシ４１０は、端末アプリ２１０から送信されたリソースサーバ３宛ての通信要求から取得した端末２の複数のチケットが、通信要求を送信した端末アプリ２１０に係る条件を満たすか否かを判定し、満たす場合に通信要求をリソースサーバ３へ中継する中継部の一例であるといえる。このような制御プロキシ４１０によれば、図１に示す通信システム１００Ａのように端末アプリ１１１及びリソースサーバ１２０を改修せずに済み、また、サービスアクセス要求に付加される状態情報の信頼性が向上する。さらに、状態情報として、暗号化等が施された互いに信頼できるチケットが用いられるため、サービスアクセス要求に付加される状態情報の信頼性が更に向上する。

記憶部４４は、利用可能アプリ判定処理及びアプリ通信可否判定処理で共通に参照される認可ポリシを格納する記憶領域である。アクセス制御部４０及び制御プロキシ４１０は、記憶部４４にアクセスして認可ポリシを参照することができる。なお、記憶部４４の機能はアクセス制御サーバ４に含まれるものとしてもよい（図７参照）。

なお、チケット管理部２０及び端末プロキシ２２０の機能を統合してもよく、アクセス制御部４０及び制御プロキシ４１０の機能を統合してもよい。また、端末プロキシ２２０が端末２の外部に配置されてもよく、制御プロキシ４１０がアクセス制御サーバ４の外部に配置されてもよい。

さらに、チケット管理部２０及び端末プロキシ２２０は、それぞれ、格納内容（チケット）を互いに同期させた記憶部２３を個別にそなえてもよい。また、アクセス制御部４０及び制御プロキシ４１０は、それぞれ、格納内容（認可ポリシ）を互いに同期させた記憶部４４を個別にそなえてもよい。

図６に示す通信システム１では、チケット管理部２０及びアクセス制御部４０により通信可能アプリ判定処理が行なわれ、通信可能アプリ２１０が端末２（ユーザ）に通知される（図５参照）。また、端末アプリ２１０からサービスアクセス要求が発行されると、端末プロキシ２２０及び制御プロキシ４１０によりアプリ通信可否判定処理が行なわれ、端末アプリ２１０が利用可能であれば、当該要求がリソースサーバ３へ中継される。リソースサーバ３からのサービス応答は、制御プロキシ４１０及び端末プロキシ２２０を経由して端末アプリ２１０で受信される。

利用可能アプリ２１０からのサービスアクセス要求は、記憶部２３のチケットがチケット送信要求後に更新されていない限り、制御プロキシ４１０でアクセス許可となる可能性が高い。従って、ユーザの利便性を向上させることができるとともに、通信ネットワークにおける、利用不可となるサービスアクセス要求及び利用不可を示すサービス応答の通信量を減少させることができ、通信システムにおける不要な負荷（通信コスト）の削減を図ることができる。

〔２−２〕チケット管理部及びアクセス制御部の機能構成例
図７は、図６に示すチケット管理部２０及びアクセス制御部４０の機能構成例を示す図である。以下、図７を参照しながら、チケット管理部２０及びアクセス制御部４０の機能構成について説明する。

〔２−２−１〕チケット管理部
はじめに、チケット管理部２０の機能構成例について説明する。図７に示すように、チケット管理部２０は、例示的にチケット情報取得部２１，チケット更新部２２，記憶部２３，チケット送信部２４，判定結果受信部２５，及び判定結果出力部２６をそなえることができる。

チケット情報取得部２１は、ユーザや場所等の認証サービス（例えば外部のサービス）等を利用して発行されたチケットを取得し、チケット更新部２２に対してチケットの登録或いは削除を要求する。チケット情報取得部２１は、例えば端末プロキシ２２０の一機能と同様の機能を有するアプリケーションにより実現される。チケット情報取得部２１は、例えば端末２やユーザの状況が変化したタイミングで認証サービスへチケットの発行を要求することで、端末２の状態に即したチケットを取得することができる。

なお、ユーザの認証サービスは、例えばＩＤ及びパスワード，ＩＣ（Integrated Circuit）カード等によりユーザ本人を認証し、当該ユーザ又はユーザの権限を証明するチケットや、端末２の時刻情報に基づきユーザの就業状態を証明するチケット等を発行するサービスである。また、場所の認証サービスは、例えばＧＰＳの緯度経度情報（位置情報）やＷｉ−Ｆｉ（Wireless Fidelity）の電波強度等を建物名や部屋名等の場所情報に変換してチケット化するサービスである。

チケット更新部２２は、チケット情報取得部２１からチケットの登録或いは削除要求を受け付け、要求に応じてチケットを記憶部２３に保存或いは記憶部２３から削除するとともに、チケット送信部２４にチケットの変化（更新されたチケット群）を通知する。例えばチケット更新部２２は、記憶部２３に現在格納されている全チケットの情報をチケット送信部２４に通知することができる。

記憶部２３は、図６に示すチケットの情報を、チケット管理テーブル２３ａとして格納する。チケット管理テーブル２３ａは、図８に例示するように、チケットごとにレコードを持ち、各レコードにチケット（チケット自体）及び登録日時等が含まれてよい。チケットには例えば図３に示す暗号化＋エンコード後の形態でチケットが設定されてよい。登録日時には当該チケットが記憶部２３に登録された日時，チケット情報取得部２１によるチケットの取得日時，或いはチケットが発行された日時等が設定されてよい。

チケット更新部２２は、チケット管理テーブル２３ａにチケット及び登録日時を設定したレコードを追加することで記憶部２３へのチケットの登録（保存）を行ない、レコードを削除することでチケットの削除を行なうことができる。

チケット送信部２４は、チケット更新部２２から受け取った記憶部２３に保持されているチケット群をアクセス制御サーバ４に送信する。例えばチケット送信部２４は、図９に例示するｈｔｔｐリクエストのような、チケットを付加したチケット送信要求を生成し、アクセス制御部４０に送信することができる。なお、図９では、ｈｔｔｐリクエストに、チケットのリストとして“ＡＡＡ・・・”，“ＢＢＢ・・・”，“ＣＣＣ・・・”の３つのチケットが付加される例を示す。

以上のように、チケット送信部２４は、端末２の状態変化を契機に、端末２の状態に関するチケット群（複数のチケット）をアクセス制御サーバ４へ送信する送信部の一例であるといえる。なお、アクセス制御サーバ４は、端末アプリ２１０がリソースサーバ３と通信可能になるための条件であって、端末２に関する一以上のチケットの組み合わせで表される認可条件（チケット条件）を満たすか否かを判定する。また、条件は、端末アプリ２１０ごとに予め定められる。

判定結果受信部２５は、アクセス制御サーバ４から、アクセス制御部４０で判定された利用可能なアプリケーション（利用可能アプリ）２１０の情報を、例えばリストとして受信し、受信したリストを判定結果出力部２６に渡す。なお、利用可能アプリ２１０の情報としては、例えばアプリケーション２１０を特定する情報の一例であるアプリＩＤが挙げられる。

判定結果出力部２６は、判定結果受信部２５からの利用可能アプリ２１０の情報をユーザに通知する。例えば、判定結果出力部２６は、端末２のディスプレイ等の表示領域に利用可能アプリ２１０の情報を表示することができる。なお、利用可能アプリ２１０のユーザへの通知手法（端末２への出力手法）は、上述したものに限定されず、既知の種々の手法を用いることができる。一例として、判定結果出力部２６は、端末２において音声で通知してもよく、端末２の表示領域に利用可能アプリ２１０の選択，実行を促すランチャ画面を表示してもよい。

以上のように、判定結果出力部２６は、アクセス制御サーバ４から、複数のチケットにより条件が満たされると判定された端末アプリ２１０の情報を受信すると、端末２の出力装置へ当該端末アプリ２１０の情報を出力する出力部の一例であるといえる。これにより、端末２のユーザ等は利用可能アプリ２１０を認識することができ、利便性が高いとともに、利用可能アプリ２１０として表示されない端末アプリ２１０についてはリソースサーバ３への通信を控えさせることが可能となり、通信システム１の不要な負荷を削減することができる。

〔２−２−２〕アクセス制御部
次に、アクセス制御部４０の機能構成例について説明する。図７に示すように、アクセス制御部４０は、例示的にチケット受信部４１，アプリ判定部４２，認可判定部４３，記憶部４４，及び判定結果送信部４５をそなえることができる。

チケット受信部４１は、端末２からチケット群を受信し、正当なチケットをアプリ判定部４２に渡す。例えば、チケット受信部４１は、受信した各チケットを復号し、正当なデータか否かを確認して、正当でない（不正である）と判断したチケットについては、受信したチケット群から排除（無効化）することができる。不正なチケットとしては、例えば、受信したチケットが所定の暗号鍵で復号できない、復号できたが少なくとも一部の情報が欠落している、有効期限が切れている、認証サービスに問い合わせた結果不正と判明した、等のチケットが挙げられる。このように、チケット受信部４１は、受信したチケット群について、正当なチケットのみをアプリ判定部４２に渡すことができる。

アプリ判定部４２は、チケット受信部４１からの正当なチケットを認可判定部４３に渡す。また、アプリ判定部４２は、認可判定部４３から認可判定結果を通知されると、判定結果に基づき利用可能アプリ２１０を判定し、利用可能アプリ２１０の情報、例えばアプリＩＤをリスト化して判定結果送信部４５に通知する。

認可判定部４３は、記憶部４４が格納する認可ポリシを管理し、アプリ判定部４２からのチケットの組で、アプリケーション２１０がリソースサーバ３の提供するサービスと通信可能か（利用可能か）否かを判定する。

記憶部４４は、図６に示す認可ポリシの情報を、認可ポリシ管理テーブル４４ａとして格納する。認可ポリシ管理テーブル４４ａは、端末アプリ２１０がサービスと通信する際に必要なチケットの条件を規定するテーブルである。認可ポリシ管理テーブル４４ａには、図１０に例示するように、アプリケーション２１０の情報、例えばアプリＩＤごとにレコードを持ち、各レコードにアプリＩＤ，サービスＵＲＬ，及び認可条件、例えばチケット条件等が含まれてよい。

アプリＩＤには、例えば端末２がＡｎｄｒｏｉｄ（登録商標）端末である場合、アプリケーション２１０のパッケージ名等が設定される。サービスＵＲＬはアプリＩＤで特定される端末アプリ２１０が利用する通信先サービスの提供場所を特定する情報の一例である。サービスＵＲＬには正規表現等を用いてＵＲＬのパターン等が指定されてもよい。

チケット条件にはアプリＩＤで特定される端末アプリ２１０がサービスを利用する（サービスＵＲＬにアクセスする）際に必要なチケットの条件が設定される。換言すれば、端末アプリ２１０は、端末２がチケット条件の示すチケットを有している場合にサービスＵＲＬで提供されるサービスを利用可能となる。図１０の例では、簡単のため、端末２が指定されたチケットを全て持っている場合にサービスＵＲＬにアクセスできることを示しているが、チケット条件には一般的な論理式が指定されてもよい。

一例として、図１０には、アプリＩＤが“app#1”の端末アプリ２１０がサービスＵＲＬ“ｈｔｔｐ：／／ａ．ｂ／ｃ”にアクセスするには、“教室Ａ”及び“教師”という名称のチケットが両方必要であるという条件が設定されている。なお、チケットの名称には、図３に示すようにチケット種別（チケット種別＋チケット名）も含まれ得るが、便宜上、図１０ではチケット種別を省略して、チケット名のみでチケットの名称を表している。

認可判定部４３は、アプリ判定部４２からのチケット群が認可ポリシの各レコード（ルール）のチケット条件を満たすか否かを順に全てのアプリケーション２１０について判定する。このとき、端末２から送信されるチケットは、チケット条件に指定されたチケット以外をも含んでいる場合があり、チケット群に設定されたチケットの順番もチケット条件の通りとは限らない。従って、認可判定部４３は、チケットのあらゆる組み合わせと並び順とを考慮して、チケット群がチケット条件と一致しているか否かを検証することが好ましい。

例えば、受け取ったチケット群が“教師”，“教室Ａ”，“就業中”，“ＺＺＺ”の4個のチケットである場合、図１０の認可ポリシと照合すると、チケット群は１番目のレコードのチケット条件を満たすが２番目及び３番目のレコードのチケット条件を満たしていない。従って、利用可能な端末アプリ２１０のアプリＩＤは“app#1”となる。なお、チケット群が複数のレコードのチケット条件を満たす場合、利用可能な端末アプリ２１０も複数存在し得る。

認可判定部４３は、認可判定（検証）の結果、利用可能な端末アプリ２１０を検出すると、判定結果、例えば利用可能と判定した端末アプリ２１０の情報（アプリＩＤ）をアプリ判定部４２に返す。なお、判定結果を渡すタイミングとしては、例えば認可判定部４３が利用可能な端末アプリ２１０を１つ検出する都度、或いはチケット群についてすべての組み合わせで全てのアプリＩＤのチケット条件との照合が完了した場合、等が挙げられる。なお、このとき、認可判定部４３は通信可能なサービスＵＲＬをアプリＩＤとともにアプリ判定部４２に通知してもよい。

以上のように、アプリ判定部４２及び認可判定部４３は、端末２から端末２の状態変化を契機に送信される当該端末２の状態に関する複数のチケットについて、端末２で実行される端末アプリ２１０がリソースサーバ３と通信可能になるための条件を満たすか否かを判定する判定部の一例であるといえる。

また、判定部の一例としてのアプリ判定部４２及び認可判定部４３は、判定において、複数のチケットの一以上の組み合わせで表される全てのパターンについて、各端末アプリ２１０に係る条件と比較し一致するか否かを判定する。これにより、アクセス制御部４０では端末２が持つチケットによって利用可能となる全ての端末アプリ２１０を検出することができる。

判定結果送信部４５は、アプリ判定部４２からの利用可能アプリ２１０のリストを端末２に返却（応答）する。例えば、判定結果送信部４５は、端末２からのチケット送信要求への応答として、図１１に例示するｈｔｔｐレスポンスのような、利用可能アプリ２１０のアプリＩＤを付加したチケット送信応答を生成し、チケット管理部２０に送信することができる。なお、図１１では、ｈｔｔｐレスポンスに、利用可能アプリ２１０のアプリＩＤのリストとして“app#1”，“app#X”の２つのアプリＩＤが付加される例を示す。

以上のように、判定結果送信部４５は、判定部の一例としてのアプリ判定部４２及び認可判定部４３によって複数のチケットにより条件が満たされると判定された端末アプリ２１０の情報を、端末２に送信する送信部の一例であるといえる。

〔２−３〕通信システムの動作例
次に、上述の如く構成された通信システム１におけるチケット管理部２０及びアクセス制御部４０の動作例を、図１２を参照して説明する。

はじめに、図１２に示すように、端末２において、チケット管理部２０のチケット情報取得部２１が認証サービス等からチケット情報を受け付け（ステップＳ１）、チケット更新部２２にチケットの更新を通知する。

チケット更新部２２は、受け付けられたチケットを記憶部２３のチケット管理テーブル２３ａに登録して（ステップＳ２）、チケット送信部２４に更新したチケットを渡し、チケット送信部２４は、チケット一式をアクセス制御サーバ４へ送信する（ステップＳ３）。

アクセス制御サーバ４では、アクセス制御部４０のチケット受信部４１が端末２からチケットを受信して（ステップＳ４）、受信したチケット群から不正なチケットを排除し（ステップＳ５）、正当なチケットをアプリ判定部４２に渡す。

アプリ判定部４２は、チケット受信部４１からのチケット群を認可判定部４３に渡す。認可判定部４３は、記憶部４４の認可ポリシ管理テーブル４４ａから１レコード（ルール）ずつ取得し、取得したレコードのチケット条件と入力されたチケットとを照合して、利用可能アプリ２１０のアプリＩＤを抽出する（ステップＳ６）。なお、ステップＳ６の処理は、認可判定部４３により、レコードごとに、チケット条件と入力されたチケットの全ての組み合わせとが比較され、入力されたチケットがチケット条件を満たすか否かが判断される。

認可判定部４３は抽出したアプリＩＤをアプリ判定部４２に渡し、アプリ判定部４２はアプリＩＤをリスト化して判定結果送信部４５に渡す。判定結果送信部４５は、アプリＩＤのリストを端末２に送信する（ステップＳ７）。

端末２では、判定結果受信部２５がアクセス制御サーバ４から判定結果としてアプリＩＤのリストを受信し（ステップＳ８）、受信結果を判定結果出力部２６に渡す。判定結果出力部２６は、受信結果に利用可能アプリ２１０があるか否かを判定し（ステップＳ９）、利用可能アプリ２１０がない場合（ステップＳ９のＮｏルート）、処理がステップＳ１に移行する。一方、利用可能アプリ２１０がある場合（ステップＳ９のＹｅｓルート）、判定結果出力部２６は、端末２に利用可能アプリ２１０の情報を出力し（ステップＳ１０）、処理がステップＳ１に移行する。

以上のように、通信システム１では、リアルタイムに変化する端末２の様々な状態情報の組み合わせに応じて、リアルタイムに端末２上の利用可能アプリ２１０をユーザに通知することが可能となる。

これにより、ユーザは端末アプリ２１０がリソースサーバ（図示省略）と通信可能（利用可能）になったか否かをリアルタイムで把握することができ、ユーザの利便性を向上させることができる。

また、ユーザは、利用可能アプリ２１０として通知されたアプリ２１０についてのみ端末２からサービスアクセス要求を発行すればよいため、通信コストの削減を図ることができる。さらに、アクセス制御サーバ４側で利用可能アプリ２１０の判定を行なうため、端末２に認可ポリシを配布するためのネットワークトラフィックの発生を抑止できる。従って、通信システム１の負荷を低減させることができる。

〔３〕変形例
一実施形態では、アクセス制御サーバ４の認可判定部４３が、利用可能アプリ２１０を判定する際に、端末２から送信されたチケット群が認可ポリシ管理テーブル４４ａの各レコードのチケット条件にマッチするか否かを順に検証することを想定している。

端末２は複数の状態を持ち得るため、端末２から送信されるチケットは複数存在する場合が多い。このため、認可判定部４３がチケットを認可ポリシ管理テーブル４４ａのチケット条件と照合する際に、照合するチケットの選択や選択されたチケットの並びの組み合わせ（順列）に応じて、判定処理は煩雑になり得る。

例えば、図１３に示すように、“教師”，“教室Ａ”，“就業中”，“ＺＺＺ”の４個のチケットが端末２から送信されてきた場合を想定する。この場合、認可判定部４３は、チケット条件に、“教師”チケットのみでマッチするか、“就業中”チケットのみでマッチするか等や、“教師”，“就業中”の並びでマッチするか、“就業中”，“教師”の並びでマッチするか等、非常に沢山のマッチングパターンを検証することになる。このように、認可ポリシの規模の増大（ルールの増加），チケット条件の複雑化，端末数の増加等に伴い、アクセス制御サーバ４における処理負荷も増大し得る。

そこで、一実施形態の変形例に係る通信システム１Ａ（図１４参照）では、以下に詳述するように、アクセス制御部４０における認可判定部４３に関する処理の一部を省略することで、利用可能アプリ判定処理の処理負荷を軽減することができる。

〔３−１〕アクセス制御部の機能構成例
図１４は、一実施形態の変形例に係る通信システム１Ａの機能構成例を示す図である。一実施形態の変形例に係る通信システム１Ａは、図１４に例示するように、アクセス制御サーバ４が一実施形態に係るアクセス制御部４０とは異なるアクセス制御部４０Ａをそなえることができる。なお、アクセス制御部４０Ａ以外の構成については、通信システム１Ａは通信システム１と同様の構成をそなえることができる。

アクセス制御部４０Ａは、利用可能アプリ２１０の判定結果の履歴に基づいて、利用可能アプリ２１０の判定の際に、判定する認可ポリシ管理テーブル４４ａのレコード（ルール）を絞り込むことで、利用可能アプリ判定処理の処理負荷を軽減することができる。

すなわち、通信システム１Ａは、判定履歴から端末アプリ２１０が利用可能になるときのチケットの条件（変化パターン）、例えば変化前後のチケットの組を、利用可能になった端末アプリ２１０と対応付けて抽出する。そして、通信システム１Ａは、利用可能アプリ２１０の判定の際に、端末２のチケット群のうちの変化前後のチケット（変化前後の差分）と変化パターンとに基づいて、変化パターンが満たされる場合、当該変化パターンに対応するアプリ２１０を特定する。これにより、通信システム１Ａは、判定するレコードから、特定したアプリ２１０を除外してルールを絞り込むことができ、認可ポリシ管理テーブル４４ａの判定処理負荷を軽減することができる。

図１４に例示するように、アクセス制御部４０Ａは、図７に示すアクセス制御部４０がそなえるものとは異なるチケット受信部４１Ａ，アプリ判定部４２Ａ，認可判定部４３Ａ，及び記憶部４４Ａをそなえることができる。また、アクセス制御部４０Ａは、判定履歴管理部４６及び判定レコード選択部４７をさらにそなえることができる。なお、それ以外の構成については、アクセス制御部４０Ａは基本的に図７に示すアクセス制御部４０と同様の構成をそなえることができる。以下、アクセス制御部４０Ａの説明において、アクセス制御部４０と同様の機能，処理についての重複した説明を省略する。

チケット受信部４１Ａは、端末２からチケット一式を受信すると、チケット受信部４１と同様に各チケットを復号して不正なチケットを排除する。そして、チケット受信部４１Ａは、正当なチケットを、チケットを送信した端末２を特定する情報、例えば端末ＩＤとともにアプリ判定部４２Ａに渡す。なお、端末ＩＤとして、例えば端末２のＭＡＣ（Media Access Control）アドレスが用いられてもよい。

アプリ判定部４２Ａは、アプリ判定部４２のようにチケット受信部４１Ａからのチケット群を直ちに認可判定部４３Ａに渡すのではなく、照合を行なう端末アプリ２１０を絞り込んでから認可判定部４３Ａに認可判定を行なわせる。以下、アプリ判定部４２Ａの動作の説明は、認可判定部４３Ａ，判定履歴管理部４６，及び判定レコード選択部４７の説明の中で行なう。

記憶部４４Ａは、記憶部４４と同様に認可ポリシ管理テーブル４４ａを格納するとともに、判定履歴管理テーブル４４ｂ及び絞り込み判定テーブル４４ｃをさらに格納することができる。

判定履歴管理部４６は、各端末２から受信したチケットについて利用可能アプリ２１０を判定した判定結果を履歴データとして蓄積・管理し、履歴データを判定レコード選択部４７に提供する。例えば、判定履歴管理部４６は、記憶部４４Ａに格納された図１５に例示するような判定履歴管理テーブル４４ｂにより、端末２が送信したチケットと、当該チケットによる認可判定結果とを時系列的に管理することができる。

図１５に示すように、判定履歴管理テーブル４４ｂは、一例として、時刻，端末ＩＤ，チケット，認可されたアプリＩＤ，及び認可されたサービスＵＲＬを含んでよい。時刻には認可判定部４３Ａが認可判定を行なった時刻が設定され、端末ＩＤにはアクセス制御サーバ４にチケットを送信した端末２の識別子が設定される。チケットには端末２が送信した全チケットが設定され、認可されたアプリＩＤには端末２が送信したチケットで利用可能になった端末アプリ２１０の識別子が設定される。認可されたサービスＵＲＬには当該端末アプリ２１０のアクセス可能なサービスのＵＲＬが設定される。なお、判定履歴管理部４６は、認可判定部４３Ａによる利用可能アプリ２１０の判定結果に基づき、判定履歴管理テーブル４４ｂを更新（レコードを追加）することができる。

アプリ判定部４２Ａは、チケット受信部４１Ａからの端末ＩＤをキーとして、判定履歴管理部４６に、当該端末ＩＤの端末２が前回送信したチケット一式を要求する。判定履歴管理部４６は、アプリ判定部４２Ａから端末ＩＤを受け取ると、判定履歴管理テーブル４４ｂから、端末ＩＤが同一、且つ、時刻が最新のチケットを検索することで、前回のチケットを取得し、アプリ判定部４２Ａに渡すことができる。

そして、アプリ判定部４２Ａは、判定履歴管理部４６で取得された前回のチケット群と、今回端末２から送信されたチケット受信部４１Ａからの今回のチケット群とから、変化前後のチケットを判定する（チケットの差分を検出する）。なお、端末２は、チケットが１個変化するたびに、チケット一式をアクセス制御部４０Ａに送信するため、ここで得られるチケットの差分も１個だけとなる。

また、アプリ判定部４２Ａは、変化前後のチケット（変化したチケットの組）を判定レコード選択部４７に渡して、個別照合対象の端末アプリ２１０の情報（例えばアプリＩＤ）を要求する。

判定レコード選択部４７は、利用可能アプリ２１０の判定履歴データを参照して、端末アプリ２１０が利用可能になる場合にどのチケットがどのように変化したかを検出し、絞り込み判定テーブル４４ｃとして記憶，管理する。そして、判定レコード選択部４７は、利用可能アプリ２１０の判定の際に、チケットの変化情報から利用可能になり得る端末アプリ２１０を判定して、判定した端末アプリ２１０の情報（アプリＩＤ）を個別照合対象の端末アプリ２１０としてアプリ判定部４２Ａに渡す。

例えば、判定レコード選択部４７は、記憶部４４Ａに格納された図１６に例示するような絞り込み判定テーブル４４ｃにより、アプリＩＤと、当該アプリＩＤの端末アプリ２１０が利用可能になるためのチケットの変化条件との対応関係を管理することができる。

図１６に示すように、絞り込み判定テーブル４４ｃは、一例として、変化前チケット，変化後チケット，及びアプリＩＤを含んでよい。変化前チケット及び変化後チケットには、端末アプリ２１０が利用可能になる前後で変化したチケットの変化前のチケット及び変化後のチケットがそれぞれ設定される。アプリＩＤには実際に利用可能になったアプリの識別子が設定される。

判定レコード選択部４７は、このような絞り込み判定テーブル４４ｃを用いて、アプリ判定部４２Ａからの変化前後のチケットに基づき個別照合対象のアプリＩＤを検索することができる。なお、判定レコード選択部４７による絞り込み判定テーブル４４ｃの検索は、変化前チケット及び変化後チケットの文字列をキーにして、単純な文字列の一致を条件として行なわれる。従って、絞り込み判定テーブル４４ｃ（データベース）内にレコードが大量に格納されていても、非常に高速に検索を行なうことが可能であり、低処理負荷とすることができる。

アプリ判定部４２Ａは、判定レコード選択部４７から個別照合対象のアプリＩＤを取得すると、認可判定部４３Ａに、個別照合対象の端末アプリ２１０と、個別照合対象以外の端末アプリ２１０とについて、個別照合を要求する。

例えば、アプリ判定部４２Ａは、認可判定部４３Ａに対して、判定レコード選択部４７からの個別照合対象のアプリＩＤの端末アプリ２１０について、チケット条件と端末２のチケット群とを個別に照合させ、当該端末アプリ２１０が利用可能か否かを判定させる。

ここで、個別照合対象の端末アプリ２１０は、判定レコード選択部４７が利用可能になる可能性のあると判定した端末アプリ２１０である。認可判定部４３Ａは、個別照合対象の端末アプリ２１０については、当該端末アプリ２１０のチケット条件と端末２から受信したチケットとを順方向の検索によって比較することができる。

すなわち、認可判定部４３Ａは、個別照合対象の端末アプリ２１０の各々について、認可ポリシ管理テーブル４４ａからチケット条件を取得し、端末２から受信したチケット群がチケット条件を満たすか否かを判断することで、当該端末アプリ２１０の認可判定を行なうことができる。これにより、全アプリＩＤについて逆方向の認可判定を行なう場合と比べ、処理負荷を大幅に低減させることができる。

また、例えばアプリ判定部４２Ａは、チケット条件が未抽出の端末アプリ２１０があるか否かを判定し、認可判定部４３Ａに対して未抽出アプリ２１０のチケット条件を個別に判定させ、利用可能なアプリＩＤを検出する。なお、チケット条件が未抽出の端末アプリ２１０は、例えば認可ポリシ管理テーブル４４ａで指定されるアプリＩＤから、絞り込み判定テーブル４４ｃで指定されるアプリＩＤを除外したものが空か否かを判断することにより行なわれる。

認可判定部４３Ａは、個別照合対象以外のアプリＩＤの各々について、一実施形態の認可判定部４３と同様の逆方向の検索を実行して、チケット群とチケット条件との照合を行なう。そして、認可判定部４３Ａは、個別照合対象のアプリＩＤについての個別照合結果と、個別照合対象以外のアプリＩＤについての個別照合結果とをアプリ判定部４２Ａに渡す。なお、認可判定部４３Ａは、個別照合対象以外のアプリＩＤについても、順方向の検索によってチケット条件とチケット群との照合を行なってもよい。

アプリ判定部４２Ａは、認可判定部４３Ａからの判定結果（利用可能アプリ２１０）を、アプリ判定部４２と同様にリスト化して判定結果送信部４５に渡す。

また、アプリ判定部４２Ａ（認可判定部４３Ａ）は、認可判定部４３Ａの判定結果を判定履歴管理部４６に渡し、判定履歴を更新させる。判定履歴管理部４６では、認可判定部４３Ａによる利用可能アプリ２１０の判定結果に基づき、判定履歴管理テーブル４４ｂを更新（レコードを追加）することができる。

以上のように、判定レコード選択部４７（及び判定履歴管理部４６）は、判定部による判定結果の履歴に基づいて、端末２のチケットの変化パターンと端末アプリ２１０とを対応付けた絞り込み判定テーブル４４ｃ（判定情報）を生成する生成部の一例であるといえる。このとき、判定部の一例としてのアプリ判定部４２Ａ及び認可判定部４３Ａは、判定において、端末２のチケット群に係る変化パターンに対応する端末アプリ２１０が判定情報に含まれるか否かを判断する。含まれる場合、アプリ判定部４２Ａ及び認可判定部４３Ａは、当該端末アプリ２１０に係る条件については、チケット群の一以上の組み合わせで表される全てのパターンとの比較を抑止するのである。これにより、認可ポリシ管理テーブル４４ａの判定処理負荷を軽減することができる。

また、アプリ判定部４２Ａ及び認可判定部４３Ａは、判定において、当該端末アプリ２１０に係る条件に含まれる一以上のチケットの全てがチケット群に含まれるか否かを判定する。これにより、当該端末アプリ２１０に係る条件については、チケット群との順方向による高速な比較を行なうことができ、処理時間の短縮を図ることができる。

次に、判定レコード選択部４７による絞り込み判定テーブル４４ｃの更新処理について説明する。

判定レコード選択部４７は、一定時間ごとに判定履歴管理テーブル４４ｂを参照し、絞り込み判定テーブル４４ｃを生成（更新）する。例えば、判定レコード選択部４７は、判定履歴管理テーブル４４ｂから端末２ごとに判定結果の履歴を抽出し、抽出した履歴データを新しいものから古いものに遡り、判定結果がＯＫ、つまり利用可能になるポイント（レコード）を検出する。なお、利用可能になるポイントとしては、例えば許可されたアプリＩＤが設定されているレコードが挙げられる。

判定レコード選択部４７は、判定結果がＯＫとなるレコードのチケット群とその直前のレコードのチケット群とを比較し、変化したチケットを検出する。そして、判定レコード選択部４７は、変化したチケット（変化前及び変化後のチケット）を、そのときに利用可能になったアプリＩＤと対応付けて、絞り込み判定テーブル４４ｃに格納し、一定時間待機して、上記の処理を繰り返す。

一例として、判定レコード選択部４７は、図１５に示すように、判定履歴管理テーブル４４ｂから端末ＩＤ“term#1”及び“term#2”の各々について、判定結果がＯＫになるポイントと、そのとき及び直前のポイントにおけるチケットを検出する。

図１５の例では、判定レコード選択部４７は、端末ＩＤ“term#1”について、時刻“10:01”，チケット“廊下１，就業中，教師，ＺＺＺ”が、時刻“10:03”，チケット“教室Ａ，就業中，教師，ＺＺＺ”に変化したときにアプリＩＤ“app#1”が許可されたことを検出する。このとき変化したチケットは、変化前チケット“廊下１”→変化後チケット“教室Ａ”であるため、判定レコード選択部４７は、図１６に示すように、これらのチケットを許可されたアプリＩＤ“app#1”とともに絞り込み判定テーブル４４ｃに追加する。

また、図１５の他の例では、判定レコード選択部４７は、端末ＩＤ“term#2”について、時刻“10:07”，チケット“玄関，就業中，教師，ＸＸＸ”が、時刻“10:09”，チケット“校外，就業中，教師，ＸＸＸ”に変化したときにアプリＩＤ“app#2”が許可されたことを検出する。このとき変化したチケットは、変化前チケット“玄関”→変化後チケット“校外”であるため、判定レコード選択部４７は、図１６に示すように、これらのチケットを許可されたアプリＩＤ“app#2”とともに絞り込み判定テーブル４４ｃに追加する。

判定結果履歴が少ない場合、判定レコード選択部４７は、端末アプリ２１０が実行可能になるチケットの変化条件を完全に抽出することは難しいが、運用を続けるうちに、次第にチケットの様々な変化条件を抽出できる。このように、絞り込み判定テーブル４４ｃが更新されていくに連れて、アクセス制御部４０Ａにおいて利用可能アプリ２１０の検出を高速に行なうことが可能となる。端末２（ユーザ）の移動は連続的であるため、場所の変化は特定のパターンが存在する場合が多く、このような絞り込み判定テーブル４４ｃを用いることは特に有効である。

なお、端末アプリ２１０の認可条件が変更になった場合、判定履歴管理部４６及び判定レコード選択部４７は、各々が管理する判定履歴管理テーブル４４ｂ及び絞り込み判定テーブル４４ｃから変更のあった端末アプリ２１０のレコードを削除することが好ましい。

以上のように、生成部の一例としての判定レコード選択部４７は、判定情報の生成において、判定結果の履歴から端末２ごとに取得した履歴データについて、端末アプリ２１０が通信可能となったときのチケット群と、当該アプリ２１０が通信可能となる直前のチケット群とを比較する。そして、判定レコード選択部４７は、変化したチケットについての変化前後のチケットの組を変化パターンとして当該端末アプリ２１０と対応付ける。これにより、利用可能アプリ２１０の検出を高速に行なうための判定情報を確実に生成することができる。

〔３−２〕通信システムの動作例
次に、上述の如く構成された通信システム１Ａにおけるチケット管理部２０及びアクセス制御部４０Ａの動作例を、図１７及び図１８を参照して説明する。なお、以下、図１２と同一の符号が付された処理等について既述のものと重複した説明は省略する。

はじめに、図１７を参照して、通信システム１Ａにおける利用可能アプリ判定処理について説明する。ステップＳ５において、アクセス制御部４０Ａのチケット受信部４１Ａは、端末２から受信したチケット群を不正なチケットを排除して端末ＩＤとともにアプリ判定部４２Ａに渡す。アプリ判定部４２Ａは、判定履歴管理部４６を通じて判定履歴管理テーブル４４ｂから当該端末ＩＤについての前回のチケット情報を取得する（ステップＳ１１）。

そして、アプリ判定部４２Ａは、取得した前回のチケット群と今回端末２から受信したチケット群との差分を検出し（ステップＳ１２）、検出した差分を判定レコード選択部４７に渡す。

判定レコード選択部４７は、アプリ判定部４２Ａからの差分のチケット（変化前後のチケット）をキーに絞り込み判定テーブル４４ｃを検索し、判定する（個別照合対象の）アプリＩＤを選択して（ステップＳ１３）、アプリ判定部４２Ａに渡す。

アプリ判定部４２Ａは、判定レコード選択部４７からの個別照合対象のアプリＩＤを認可判定部４３Ａに渡す。認可判定部４３Ａは、認可ポリシ管理テーブル４４ａから個別照合対象のアプリＩＤのチケット条件と受信したチケット群とを順方向の検索によって個別に判定し、利用可能なアプリＩＤを抽出する（ステップＳ１４）。

また、アプリ判定部４２Ａは、認可ポリシ管理テーブル４４ａからレコード未抽出の端末アプリ２１０があるか否かを判定し（ステップＳ１５）、レコード未抽出の端末アプリ２１０がない場合（ステップＳ１５のＮｏルート）、処理がステップＳ１７に移行する。

一方、レコード未抽出の端末アプリ２１０がある場合（ステップＳ１５のＹｅｓルート）、アプリ判定部４２Ａは、未抽出のアプリＩＤを認可判定部４３Ａに通知する。認可判定部４３Ａは、受信したチケット群と未抽出のアプリＩＤのチケット条件とを個別に判定し、利用可能なアプリＩＤを抽出して（ステップＳ１６）、処理がステップＳ１７に移行する。

ステップＳ１７では、アプリ判定部４２Ａ（認可判定部４３Ａ）が判定結果を判定履歴管理テーブル４４ｂに登録し、処理がステップＳ７に移行する。

次に、図１８を参照して、通信システム１Ａのアクセス制御部４０Ａにおける絞り込み判定テーブル４４ｃの生成処理について説明する。

判定レコード選択部４７は、端末ごとに判定履歴管理テーブル４４ｂから判定履歴データを抽出すると（ステップＳ２１）、抽出した履歴データについて端末アプリ２１０が許可されたポイントを検出する（ステップＳ２２）。

次いで、判定レコード選択部４７は、検出ポイントのチケット群とその直前のチケット群とを比較し、チケットの変化をチケット種別ごとに検出する（ステップＳ２３）。また、判定レコード選択部４７は、検出したチケットの変化条件をアプリＩＤと対応付けて絞り込み判定テーブル４４ｃに記憶する（ステップＳ２４）。

そして、判定レコード選択部４７は、一定時間待機して（ステップＳ２５）、処理がステップＳ２１に移行する。

以上のように、本変形例に係る通信システム１Ａは、端末アプリ２１０の通信認可判定の履歴を収集し、端末２の状態変化から判定する認可条件を決定するインデクスとしての絞り込み判定テーブル４４ｃを作成する。そして、通信システム１Ａは、端末２が状態変化したときにインデクスにより判定不要な認可条件を除外した上で、判定を行なうことができる。これにより、認可ポリシ管理テーブル４４ａの判定処理負荷を軽減することができる。

〔４〕ハードウェア構成例
図１９に示すように、上述した一実施形態及び変形例に係る端末２は、ＣＰＵ２ａ，メモリ２ｂ，記憶部２ｃ，インタフェース部２ｄ，入出力部２ｅ，及び読取部２ｆをそなえることができる。同様に、上述した一実施形態及び変形例に係るアクセス制御サーバ４は、ＣＰＵ４ａ，メモリ４ｂ，記憶部４ｃ，インタフェース部４ｄ，入出力部４ｅ，及び読取部４ｆをそなえることができる。

ＣＰＵ２ａ及び４ａは、種々の制御や演算を行なう演算処理装置（プロセッサ）の一例である。ＣＰＵ２ａ及び４ａは、対応する各ブロック２ｂ〜２ｆ，４ｂ〜４ｆとそれぞれ接続され、メモリ２ｂ及び４ｂ，記憶部２ｃ及び４ｃ，記録媒体２ｇ及び４ｇ，又は図示しないＲＯＭ（Read Only Memory）等に格納されたプログラムを実行することにより、種々の機能を実現することができる。

メモリ２ｂ及び４ｂは、種々のデータやプログラムを格納する記憶装置である。ＣＰＵ２ａ及び４ａは、プログラムを実行する際に、それぞれメモリ２ｂ及び４ｂにデータやプログラムを格納し展開する。なお、メモリ２ｂ及び４ｂとしては、例えばＲＡＭ（Random Access Memory）等の揮発性メモリが挙げられる。

記憶部２ｃ及び４ｃは、種々のデータやプログラム等を格納するハードウェアである。記憶部２ｃ及び４ｃとしては、例えばＨＤＤ等の磁気ディスク装置，ＳＳＤ（Solid State Drive）等の半導体ドライブ装置，フラッシュメモリやＲＯＭ等の不揮発性メモリ等の各種装置が挙げられる。なお、図６，図７，図１４に示す記憶部２３は、メモリ２ｂ又は記憶部２ｃにより実現されてよく、図６，図７，図１４に示す記憶部４４は、メモリ４ｂ又は記憶部４ｃにより実現されてよい。

例えば、記憶部２ｃは、端末２の各種機能の全部もしくは一部を実現する端末プログラム２００，アプリケーション２１０，チケット管理テーブル２３ａ等を格納することができる。また、記憶部４ｃは、アクセス制御サーバ４の各種機能の全部もしくは一部を実現する判定プログラム４００及び認可ポリシ管理テーブル４４ａ等を格納することができ、変形例においては判定履歴管理テーブル４４ｂ及び絞り込み判定テーブル４４ｃをさらに格納することができる。

インタフェース部２ｄ及び４ｄは、有線又は無線による、ネットワークや他の情報処理装置等との間の接続及び通信の制御等を行なう通信インタフェースである。インタフェース部２ｄ及び４ｄとしては、例えば、ＬＡＮ（Local Area Network），ファイバチャネル（Fibre Channel；ＦＣ），インフィニバンド（InfiniBand）等に準拠したアダプタが挙げられる。例えば、ＣＰＵ２ａ及び４ａは、それぞれインタフェース部２ｄ及び４ｄを介してネットワークから取得した端末プログラム２００及び判定プログラム４００を記憶部２ｃ及び４ｃに格納してもよい。

入出力部２ｅ及び４ｅは、タッチパネル，音声操作のためのマイク，マウス，及びキーボード等の入力装置（操作部），並びにディスプレイ，スピーカー，及びプリンタ等の出力装置（出力部，表示部）の少なくとも一方を含むことができる。例えば、入力装置はユーザや管理者等による端末２又はアクセス制御サーバ４の各種操作やデータの入力等の作業に用いられてよく、出力装置は各種通知や処理結果等の出力に用いられてよい。

読取部２ｆ及び４ｆは、コンピュータ読取可能な記録媒体２ｇ及び４ｇに記録されたデータやプログラムを読み出す装置である。記録媒体２ｇには端末プログラム２００が格納されてもよく、記録媒体４ｇには判定プログラム４００が格納されてもよい。

例えば、ＣＰＵ２ａは、記憶部２ｃに格納された端末プログラム２００を、メモリ２ｂ等の記憶装置に展開して実行することにより、端末２のチケット管理部２０（及び端末プロキシ２２０）の機能を実現することができる。また、ＣＰＵ４ａは、記憶部４ｃに格納された判定プログラム４００又は読取部４ｆを介して記録媒体４ｇから読み出した判定プログラム４００をメモリ４ｂに展開して実行することにより、アクセス制御サーバ４のアクセス制御部４０Ａ（及び制御プロキシ４１０）の機能を実現することができる。

なお、記録媒体２ｇ及び４ｇとしては、例えばフレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク等の光ディスクや、ＵＳＢ（Universal Serial Bus）メモリやＳＤカード等のフラッシュメモリが挙げられる。なお、ＣＤとしては、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（CD-Recordable）、ＣＤ−ＲＷ（CD-Rewritable）等が挙げられる。また、ＤＶＤとしては、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等が挙げられる。

上述した各ブロック２ａ〜２ｆ間及び各ブロック４ａ〜４ｆ間はそれぞれバスで相互に通信可能に接続される。また、端末２及びアクセス制御サーバ４の上述したハードウェア構成は例示である。従って、端末２及びアクセス制御サーバ４内でのハードウェアの増減（例えば任意のブロックの追加や省略），分割，任意の組み合わせでの統合，バスの追加又は省略等は適宜行なわれてもよい。例えば、端末２のアプリケーション２１０が実行されるハードウェア構成はチケット管理部２０及び端末プロキシ２２０の少なくとも一方とは別個のハードウェア構成であってもよく、チケット管理部２０及び端末プロキシ２２０も互いに別個のハードウェア構成であってもよい。同様に、アクセス制御サーバ４のアクセス制御部４０又は４０Ａ，並びに制御プロキシ４１０は互いに別個のハードウェア構成であってもよい。

〔５〕その他
以上、本発明の好ましい実施形態及び変形例について詳述したが、本発明は、かかる特定の実施形態及び変形例に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。

例えば、図４，図６，図７，及び図１４等に示す端末２及びアクセス制御サーバ４の各機能ブロックは、任意の組み合わせで併合してもよく、分割してもよい。

また、上述した一実施形態及び変形例では、端末２がアクセス制御サーバ４へチケットのみを送信し、アクセス制御サーバ４が利用可能アプリ２１０を検出するものとして説明したが、これに限定されるものではない。例えば、端末２が端末２にインストールされているすべてのアプリケーション２１０のアプリＩＤをチケットとともにアクセス制御サーバ４に送信し、アクセス制御サーバ４が利用可能なアプリＩＤを端末２に返信してよい。

さらに、図４，図６，図７，及び図１４等では、通信システム１及び１Ａに１台の端末２がそなえられる場合について説明したが、通信システム１及び１Ａには複数の端末２が含まれてよい。通信システム１及び１Ａに複数の端末２が含まれる場合、アクセス制御サーバ４は、各端末２との間で上述した処理を実行すればよい。

〔６〕付記
以上の実施形態及び変形例に関し、更に以下の付記を開示する。

（付記１）
端末装置から前記端末装置の状態変化を契機に送信される当該端末装置の状態に関する複数の状態情報について、前記端末装置で実行されるアプリケーションが情報処理装置と通信可能になるための条件であって前記端末装置に関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定する判定部と、
前記判定部によって前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を、前記端末装置に送信する送信部と、をそなえる
ことを特徴とする、判定装置。

（付記２）
前記条件は前記端末装置で実行されるアプリケーションごとに予め定められ、
前記判定部は、前記判定において、前記複数の状態情報の一以上の組み合わせで表される全てのパターンについて、各アプリケーションに係る条件と比較し一致するか否かを判定する、
ことを特徴とする、付記１記載の判定装置。

（付記３）
前記判定部による判定結果の履歴に基づいて、前記端末装置の状態情報の変化パターンとアプリケーションとを対応付けた判定情報を生成する生成部をさらにそなえ、
前記判定部は、前記判定において、前記端末装置の複数の状態情報に係る変化パターンに対応する第１のアプリケーションが前記判定情報に含まれる場合、当該第１のアプリケーションに係る条件については、前記複数の状態情報の一以上の組み合わせで表される全てのパターンとの比較を抑止する、
ことを特徴とする、付記２記載の判定装置。

（付記４）
前記判定部は、前記判定において、前記第１のアプリケーションに係る条件に含まれる一以上の状態情報の全てが前記複数の状態情報に含まれるか否かを判定する、
ことを特徴とする、付記３記載の判定装置。

（付記５）
前記生成部は、前記判定情報の生成において、前記判定部による判定結果の履歴から端末装置ごとに取得した履歴データについて、アプリケーションが通信可能となったときの複数の状態情報と、当該アプリケーションが通信可能となる直前の複数の状態情報とから、変化した状態情報についての変化前後の状態情報の組を前記変化パターンとして当該アプリケーションと対応付ける、
ことを特徴とする、付記３又は付記４記載の判定装置。

（付記６）
前記端末装置のアプリケーションから送信された前記情報処理装置宛ての通信要求から、前記端末装置の複数の状態情報を取得し、取得した複数の状態情報が前記通信要求を送信したアプリケーションに係る条件を満たすか否かを判定し、満たす場合に前記通信要求を前記情報処理装置へ中継する中継部をさらにそなえる、
ことを特徴とする、付記１〜５のいずれか１項記載の判定装置。

（付記７）
自装置で実行されるアプリケーションにより情報処理装置と通信を行なう端末装置であって、
前記端末装置の状態変化を契機に、前記端末装置の状態に関する複数の状態情報を、前記アプリケーションが前記情報処理装置と通信可能になるための条件であって前記端末装置に関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定する判定装置へ送信する送信部と、
前記判定装置から、前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を受信すると、出力装置へ当該アプリケーションの情報を出力する出力部と、をそなえる
ことを特徴とする、端末装置。

（付記８）
コンピュータに、
端末装置から前記端末装置の状態変化を契機に送信される当該端末装置の状態に関する複数の状態情報について、前記端末装置で実行されるアプリケーションが情報処理装置と通信可能になるための条件であって前記端末装置に関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定し、
前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を、前記端末装置に送信する、
処理を実行させることを特徴とする、判定プログラム。

（付記９）
前記条件は前記端末装置で実行されるアプリケーションごとに予め定められ、
前記コンピュータに、
前記判定において、前記複数の状態情報の一以上の組み合わせで表される全てのパターンについて、各アプリケーションに係る条件と比較し一致するか否かを判定する、
処理を実行させることを特徴とする、付記８記載の判定プログラム。

（付記１０）
前記コンピュータに、
前記判定による判定結果の履歴に基づいて、前記端末装置の状態情報の変化パターンとアプリケーションとを対応付けた判定情報を生成し、
前記判定において、前記端末装置の複数の状態情報に係る変化パターンに対応する第１のアプリケーションが前記判定情報に含まれる場合、当該第１のアプリケーションに係る条件については、前記複数の状態情報の一以上の組み合わせで表される全てのパターンとの比較を抑止する、
処理を実行させることを特徴とする、付記９記載の判定プログラム。

（付記１１）
前記コンピュータに、
前記判定において、前記第１のアプリケーションに係る条件に含まれる一以上の状態情報の全てが前記複数の状態情報に含まれるか否かを判定する、
処理を実行させることを特徴とする、付記１０記載の判定プログラム。

（付記１２）
前記コンピュータに、
前記判定情報の生成において、前記判定による判定結果の履歴から端末装置ごとに取得した履歴データについて、アプリケーションが通信可能となったときの複数の状態情報と、当該アプリケーションが通信可能となる直前の複数の状態情報とから、変化した状態情報についての変化前後の状態情報の組を前記変化パターンとして当該アプリケーションと対応付ける、
処理を実行させることを特徴とする、付記１０又は付記１１記載の判定プログラム。

（付記１３）
前記コンピュータに、
前記端末装置のアプリケーションから送信された前記情報処理装置宛ての通信要求から、前記端末装置の複数の状態情報を取得し、
取得した複数の状態情報が前記通信要求を送信したアプリケーションに係る条件を満たすか否かを判定し、
前記複数の状態情報が当該アプリケーションに係る条件を満たす場合に前記通信要求を前記情報処理装置へ中継する、
処理を実行させることを特徴とする、付記８〜１２のいずれか１項記載の判定プログラム。

（付記１４）
自コンピュータで実行されるアプリケーションにより情報処理装置と通信を行なうコンピュータに、
前記コンピュータの状態変化を契機に、前記コンピュータの状態に関する複数の状態情報を、前記アプリケーションが前記情報処理装置と通信可能になるための条件であって前記コンピュータに関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定する判定装置へ送信し、
前記判定装置から、前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を受信すると、出力装置へ当該アプリケーションの情報を出力する、
処理を実行させることを特徴とする、端末プログラム。

（付記１５）
自装置で実行されるアプリケーションにより情報処理装置と通信を行なう端末装置と、判定装置とをそなえる通信システムであって、
前記端末装置が、前記端末装置の状態変化を契機に、前記端末装置の状態に関する複数の状態情報を前記判定装置に送信し、
前記判定装置が、
前記端末装置から受信した前記複数の状態情報について、前記アプリケーションが前記情報処理装置と通信可能になるための条件であって前記端末装置に関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定し、
前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を、前記端末装置に送信し、
前記端末装置が、前記判定装置から前記アプリケーションの情報を受信すると、出力装置へ当該アプリケーションの情報を出力する、
ことを特徴とする、通信システム。

（付記１６）
前記条件は前記端末装置で実行されるアプリケーションごとに予め定められ、
前記判定装置は、前記判定において、前記複数の状態情報の一以上の組み合わせで表される全てのパターンについて、各アプリケーションに係る条件と比較し一致するか否かを判定する、
ことを特徴とする、付記１５記載の通信システム。

（付記１７）
前記判定装置は、
前記判定による判定結果の履歴に基づいて、前記端末装置の状態情報の変化パターンとアプリケーションとを対応付けた判定情報を生成し、
前記判定において、前記端末装置の複数の状態情報に係る変化パターンに対応する第１のアプリケーションが前記判定情報に含まれる場合、当該第１のアプリケーションに係る条件については、前記複数の状態情報の一以上の組み合わせで表される全てのパターンとの比較を抑止する、
ことを特徴とする、付記１６記載の通信システム。

（付記１８）
前記判定装置は、前記判定において、前記第１のアプリケーションに係る条件に含まれる一以上の状態情報の全てが前記複数の状態情報に含まれるか否かを判定する、
ことを特徴とする、付記１７記載の通信システム。

（付記１９）
前記判定装置は、前記判定情報の生成において、前記判定による判定結果の履歴から端末装置ごとに取得した履歴データについて、アプリケーションが通信可能となったときの複数の状態情報と、当該アプリケーションが通信可能となる直前の複数の状態情報とから、変化した状態情報についての変化前後の状態情報の組を前記変化パターンとして当該アプリケーションと対応付ける、
ことを特徴とする、付記１７又は付記１８記載の通信システム。

（付記２０）
前記端末装置は、前記アプリケーションから送信される前記情報処理装置宛ての通信要求に前記端末装置の複数の状態情報を付加して送信し、
前記判定装置は、
前記通信要求から、前記端末装置の複数の状態情報を取得し、
取得した複数の状態情報が前記通信要求を送信したアプリケーションに係る条件を満たすか否かを判定し、
前記複数の状態情報が前記アプリケーションに係る条件を満たす場合に前記通信要求を前記情報処理装置へ中継する、
ことを特徴とする、付記１５〜１９のいずれか１項記載の通信システム。

１，１Ａ 通信システム
２ 端末
２ａ，４ａ ＣＰＵ
２ｂ，４ｂ メモリ
２ｃ，４ｃ 記憶部
２ｄ，４ｄ インタフェース部
２ｅ，４ｅ 入出力部
２ｆ，４ｆ 読取部
２ｇ，４ｇ 記録媒体
２０ チケット管理部
２１ チケット情報取得部
２２ チケット更新部
２３，４４ 記憶部
２３ａ チケット管理テーブル
２４ チケット送信部
２５ 判定結果受信部
２６ 判定結果出力部
２００ チケット管理プログラム
２１０ アプリケーション
２１１ 場所センサ
２１２ スケジューラ
２１３ 認証装置
２２０ チケット付加プロキシ（端末プロキシ）
３ リソースサーバ
４ アクセス制御サーバ
４０，４０Ａ アクセス制御部
４１，４１Ａ チケット受信部
４２，４２Ａ アプリ判定部
４３，４３Ａ 認可判定部
４４ａ 認可ポリシ管理テーブル
４４ｂ 判定履歴管理テーブル
４４ｃ 絞り込み判定テーブル
４５ 判定結果送信部
４６ 判定履歴管理部
４７ 判定レコード選択部
４００ アクセス制御プログラム
４１０ アクセス制御プロキシ（制御プロキシ）

Claims (9)

1. 端末装置から前記端末装置の状態変化を契機に送信される当該端末装置の状態に関する複数の状態情報について、前記端末装置で実行されるアプリケーションが情報処理装置と通信可能になるための条件であって前記端末装置に関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定する判定部と、
   前記判定部によって前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を、前記端末装置に送信する送信部と、をそなえる
   ことを特徴とする、判定装置。
2. 前記条件は前記端末装置で実行されるアプリケーションごとに予め定められ、
   前記判定部は、前記判定において、前記複数の状態情報の一以上の組み合わせで表される全てのパターンについて、各アプリケーションに係る条件と比較し一致するか否かを判定する、
   ことを特徴とする、請求項１記載の判定装置。
3. 前記判定部による判定結果の履歴に基づいて、前記端末装置の状態情報の変化パターンとアプリケーションとを対応付けた判定情報を生成する生成部をさらにそなえ、
   前記判定部は、前記判定において、前記端末装置の複数の状態情報に係る変化パターンに対応する第１のアプリケーションが前記判定情報に含まれる場合、当該第１のアプリケーションに係る条件については、前記複数の状態情報の一以上の組み合わせで表される全てのパターンとの比較を抑止する、
   ことを特徴とする、請求項２記載の判定装置。
4. 前記判定部は、前記判定において、前記第１のアプリケーションに係る条件に含まれる一以上の状態情報の全てが前記複数の状態情報に含まれるか否かを判定する、
   ことを特徴とする、請求項３記載の判定装置。
5. 前記生成部は、前記判定情報の生成において、前記判定部による判定結果の履歴から端末装置ごとに取得した履歴データについて、アプリケーションが通信可能となったときの複数の状態情報と、当該アプリケーションが通信可能となる直前の複数の状態情報とから、変化した状態情報についての変化前後の状態情報の組を前記変化パターンとして当該アプリケーションと対応付ける、
   ことを特徴とする、請求項３又は請求項４記載の判定装置。
6. 自装置で実行されるアプリケーションにより情報処理装置と通信を行なう端末装置であって、
   前記端末装置の状態変化を契機に、前記端末装置の状態に関する複数の状態情報を、前記アプリケーションが前記情報処理装置と通信可能になるための条件であって前記端末装置に関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定する判定装置へ送信する送信部と、
   前記判定装置から、前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を受信すると、出力装置へ当該アプリケーションの情報を出力する出力部と、をそなえる
   ことを特徴とする、端末装置。
7. コンピュータに、
   端末装置から前記端末装置の状態変化を契機に送信される当該端末装置の状態に関する複数の状態情報について、前記端末装置で実行されるアプリケーションが情報処理装置と通信可能になるための条件であって前記端末装置に関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定し、
   前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を、前記端末装置に送信する、
   処理を実行させることを特徴とする、判定プログラム。
8. 自コンピュータで実行されるアプリケーションにより情報処理装置と通信を行なうコンピュータに、
   前記コンピュータの状態変化を契機に、前記コンピュータの状態に関する複数の状態情報を、前記アプリケーションが前記情報処理装置と通信可能になるための条件であって前記コンピュータに関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定する判定装置へ送信し、
   前記判定装置から、前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を受信すると、出力装置へ当該アプリケーションの情報を出力する、
   処理を実行させることを特徴とする、端末プログラム。
9. 自装置で実行されるアプリケーションにより情報処理装置と通信を行なう端末装置と、判定装置とをそなえる通信システムであって、
   前記端末装置が、前記端末装置の状態変化を契機に、前記端末装置の状態に関する複数の状態情報を前記判定装置に送信し、
   前記判定装置が、
   前記端末装置から受信した前記複数の状態情報について、前記アプリケーションが前記情報処理装置と通信可能になるための条件であって前記端末装置に関する一以上の状態情報の組み合わせで表される前記条件を満たすか否かを判定し、
   前記複数の状態情報により前記条件が満たされると判定されたアプリケーションの情報を、前記端末装置に送信し、
   前記端末装置が、前記判定装置から前記アプリケーションの情報を受信すると、出力装置へ当該アプリケーションの情報を出力する、
   ことを特徴とする、通信システム。

Images