情報処理装置、イベント制御方法およびイベント制御用プログラム
【課題】位置情報を用いてイベントの制御を行うシステムにおいて、安全性を確保しつつ柔軟性を向上させる情報処理装置、イベント制御方法およびイベント制御用プログラムを提供する。
【解決手段】イベント制御モジュールが、ユーザ属性、ユーザの位置情報およびユーザ集合の状態、の何れかを含むユーザ情報を取得し、ユーザ属性、位置情報および集合の状態が、イベント発生条件を満たすか否かを判定し、イベント発生条件が満たされたと判定された場合に、イベントの発生を許可または指示する。
【解決手段】イベント制御モジュールが、ユーザ属性、ユーザの位置情報およびユーザ集合の状態、の何れかを含むユーザ情報を取得し、ユーザ属性、位置情報および集合の状態が、イベント発生条件を満たすか否かを判定し、イベント発生条件が満たされたと判定された場合に、イベントの発生を許可または指示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、イベント制御のための技術に関する。
【背景技術】
【０００２】
従来、人、物体、または一群の人々／物体が、目的位置に到達し、あるいはその近くに来たときに、対話要求が実行される、近接性駆動式または位置駆動式の活動を実施するシステムが提案されている（特許文献１を参照）。
【０００３】
また、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）により取得した現在の地理的位置が許可された地理的位置である場合に限り、ユーザの格納情報へのアクセスを許可するアクセス制御方法（特許文献２を参照）や、ファイルにアクセスすることのできる地域をファイル自身に設定する位置情報付き暗号化システム（特許文献３を参照）等が提案されている。
【０００４】
更に、同じまたは略同じ位置で見つけられたソーシャルネットワークのメンバーについて関連付けられたＧＰＳ識別子とステイタスとを含むコンタクトコンテンツが、ＧＰＳ対応装置上に現れるシステムが提案されている（特許文献４を参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２００５−５０９１９８号公報
【特許文献２】特開２０００−１６３３７９号公報
【特許文献３】特開２００７−２４１９０７号公報
【特許文献４】特表２０１０−５２０５４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来、位置情報を用いて人や物体を関連付けるための技術が種々提案されている。また、位置情報を参照してアクセスの許可／不許可を判定する等、位置情報を用いてセキュリティを高める技術が種々提案されている。
【０００７】
しかし、セキュリティの高さとシステムの柔軟性は一般にトレードオフの関係にある。このため、位置情報等を用いてセキュリティを高めようとすると、システムの柔軟性が失われ、反対に、システムの柔軟性を高めようとすると、セキュリティが不十分となるという問題があった。
【０００８】
本開示は、上記した問題に鑑み、位置情報を用いてイベントの制御を行うシステムにおいて、安全性を確保しつつ柔軟性を向上させることを課題とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本開示に示された情報処理装置、イベント制御方法およびイベント制御用プログラムでは、イベントに設定された属性条件を満たす複数のユーザが場所条件を満たし、且つ集合状態条件を満たした場合に、イベントの発生を許可または指示することとした。
【００１０】
より詳細には、本開示に係る情報処理装置は、ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れか
を含むユーザ情報を取得するユーザ情報取得手段と、前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定手段と、前記判定手段によって、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御手段と、を備える情報処理装置である。
【００１１】
また、本開示は、コンピュータによって実行される方法、またはコンピュータに実行させるプログラムとしても把握することが可能である。また、本開示は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。
【発明の効果】
【００１２】
本開示に係る情報処理装置、イベント制御方法およびイベント制御用プログラムによれば、位置情報を用いてイベントの制御を行うシステムにおいて、安全性を確保しつつ柔軟性を向上させることが可能となる。
【図面の簡単な説明】
【００１３】
【図１】実施形態に係るシステムの構成の概略を示す図である。
【図２】実施形態に係るイベント制御モジュールのハードウェア構成の概略を示す図である。
【図３Ａ】実施形態に係るイベント登録端末の機能構成の概略を示す図である。
【図３Ｂ】実施形態に係るユーザ端末の機能構成の概略を示す図である。
【図３Ｃ】実施形態に係るイベント制御モジュールの機能構成の概略を示す図である。
【図４】実施形態において用いられるイベント発生条件の構成を示す図である。
【図５】実施形態に係るシステムにおける処理のフェーズを示す図である。
【図６】実施形態に係るイベント生成処理の概要を示す図である。
【図７】実施形態において生成されるイベント情報の例を示す図である。
【図８】実施形態に係るイベント登録処理の概要を示す図である。
【図９】実施形態に係るユーザ情報取得処理の概要を示す図である。
【図１０】実施形態においてユーザ端末のＳＮＳ情報取得部によって取得される、ユーザ属性の例を示す図である。
【図１１】実施形態において複数のユーザ端末によってユーザ情報が取得され、イベント制御モジュールに対して送信される様子を例示する図である。
【図１２】実施形態においてイベント制御モジュールによって取得された、ユーザ情報の例を示す図である。
【図１３】実施形態に係るイベント発生判定処理の概要を示す図である。
【図１４】実施形態に係るイベント発生条件判定処理の流れを示すフローチャートである。
【図１５】実施形態に係るイベント発生条件判定結果の例を示す図である。
【図１６】実施形態に係るイベント発生処理の概要を示す図である。
【図１７】実施形態におけるユーザ端末毎のイベント発生状況の例を示す図である。
【図１８】イベント登録のバリエーションを示す図である。
【図１９】バリエーションにおける、イベント制御モジュールの機能構成の概略を示す図である。
【図２０】ストレージにおいてイベントを発生させる場合のイベント発生の仕組みを示す図である。
【図２１】バリエーションにおける、イベント制御モジュールの機能構成の概略を示す図である。
【図２２】ユーザ端末においてイベントを発生させる場合のイベント発生の仕組みを示す図である。
【図２３】バリエーションにおける、イベント制御モジュールの機能構成の概略を示す図である。
【図２４】イベント制御モジュールにおいてイベントを発生させる場合のイベント発生の仕組みを示す図である。
【図２５】バリエーションにおける、イベント制御モジュールの機能構成の概略を示す図である。
【図２６】実施形態に係るシステムを、複数ユーザが、夫々のユーザ端末を用いてネットワークを介して相互に接続し、同時にプレイするゲームシステムに適用する例を示す図である。
【図２７Ａ】実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報の例を示す図である。
【図２７Ｂ】実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報の例を示す図である。
【図２７Ｃ】実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報の例を示す図である。
【図２７Ｄ】実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報の例を示す図である。
【図２８】実施形態に係るシステムを、地域社会連携システムに適用する場合に登録されるイベント情報の例を示す図である。
【図２９】実施形態に係るシステムを運用した場合のイベント発生状況を示す図である。
【図３０】実施形態に係るシステムを、オリエンテーリングシステムに適用する場合に登録されるイベント情報の例を示す図である。
【図３１】実施形態に係るシステムを運用した場合のイベント発生状況を示す図である。
【図３２Ａ】実施形態に係るシステムを、会議管理システムに適用する場合に登録されるイベント情報の例を示す図である。
【図３２Ｂ】実施形態に係るシステムを、会議管理システムに適用する場合に登録されるイベント情報の例を示す図である。
【図３３Ａ】実施形態に係るシステムを、共有手帳システムに適用する場合に登録されるイベント情報の例を示す図である。
【図３３Ｂ】実施形態に係るシステムを、共有手帳システムに適用する場合に登録されるイベント情報の例を示す図である。
【図３３Ｃ】実施形態に係るシステムを、共有手帳システムに適用する場合に登録されるイベント情報の例を示す図である。
【図３４】実施形態に係るシステムを、情報配信システムに適用する場合に登録されるイベント情報の例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本開示に係る情報処理装置、イベント制御方法およびイベント制御用プログラムの実施の形態について、図面に基づいて説明する。なお、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理装置、イベント制御方法およびイベント制御用プログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の形態に応じた具体的構成が適宜採用されてよい。
【００１５】
本実施形態において、本開示に係る情報処理装置は、イベント制御モジュール１として実施される。但し、本開示の適用対象は、位置情報を用いてイベントの制御を行うシステ
ムであればよく、本実施形態において説明するシステムに限定されない。たとえば、情報処理装置は、ユーザ端末５によってイベントの制御が行われるシステムとして実施されてもよい。
【００１６】
本実施形態において、イベントとは、特定の条件の下で発生するものであり、イベント情報９によって定義される。イベント情報９には、事前に設定された、イベント発生のために課される条件であるイベント発生条件９３と、イベント内容９１の格納先を示すイベント内容格納先情報９２と、イベントとして発生させたい処理等を示すイベント内容９１と、が含まれる（図７等を参照）。
【００１７】
ここで、イベント内容９１は、発生させられるイベントの内容が記述された情報であり、記述のフォーマットは実施形態によって様々であり、限定されない。イベント内容９１は、例えば、イベント発生のために実行されるソフトウェア自体であってもよいし、イベントを実行する機能に対して与えられる指示（コマンド）であってもよい。また、イベント内容格納先情報９２は、イベント内容９１が格納されるストレージ２へのポインタである。イベント発生条件９３およびイベント内容格納先情報９２についても、記述のフォーマットは実施形態によって適宜採用可能であり、限定されない。
【００１８】
＜システムの構成＞
図１は、本実施形態に係るシステムの構成の概略を示す図である。本実施形態に係るシステムは、イベント制御モジュール１と、ストレージ２と、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）３と、イベント登録端末４と、ユーザ端末５と、がインターネット等のネットワークを介して互いに接続されたシステムである。なお、イベント制御モジュール１とストレージ２とは、別個のサーバとして構成されてもよいし、単一のサーバとして構成されてもよい。また、イベント登録端末４はユーザ端末５と同一の端末であってもよい。例えば、あるユーザが会議の参加メンバーでもあり主催者でもある場合、当該ユーザの端末は、イベント登録端末４とユーザ端末５とを兼ねる。
【００１９】
図２は、本実施形態に係るイベント制御モジュール１のハードウェア構成の概略を示す図である。イベント制御モジュール１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１２と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１３と、補助記憶装置１９と、ネットワークを介した外部との通信を行うためのネットワークインターフェース１６と、が電気的に接続された情報処理装置である。なお、情報処理装置の具体的なハードウェア構成に関しては、実施の形態に応じて適宜構成要素の省略や置換、追加が行われてよい。
【００２０】
ＣＰＵ１１は、中央処理装置であり、ＲＡＭ１２およびＲＯＭ１３等に展開された命令及びデータを処理することで、ＲＡＭ１２、補助記憶装置１９等の、イベント制御モジュール１に備えられた各構成を制御する。また、ＲＡＭ１２は、主記憶装置であり、ＣＰＵ１１によって制御され、各種命令やデータが書き込まれ、読み出される。即ち、ＣＰＵ１１、ＲＡＭ１２、およびＲＯＭ１３は、イベント制御モジュール１の制御部を構成する。
【００２１】
補助記憶装置１９は、不揮発性の記憶装置であり、主にイベント制御モジュール１の電源を落としても保持したい情報、例えば、ＲＡＭ１２にロードされるイベント制御モジュール１のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や、後述する処理を実行するための各種プログラムの他、イベント制御モジュール１によって使用される各種データが書き込まれ、読み出される。補助記憶装置１９としては、例えば、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等を用いることが出来る。
【００２２】
なお、ストレージ２、ＳＮＳ３、イベント登録端末４およびユーザ端末５は、イベント制御モジュール１と同じく、一般的なコンピュータとしての構成であるＣＰＵ、ＲＡＭ、ＲＯＭ、補助記憶装置、ネットワークインターフェース等を備えるコンピュータシステムである（図示は省略する）。
【００２３】
また、イベント制御モジュール１、ストレージ２、およびＳＮＳ３等の各種サーバは、ネットワーク上にクラウドサービスとして実装されてもよい。この場合、各サーバによる処理の主体は、ネットワーク上に分散した複数のマシンとなるが、本実施形態では、サーバとしての機能を果たすための複数のマシンをまとめて「サーバ」と称する。
【００２４】
ユーザ端末５は、上記説明した一般的なコンピュータとしての構成に加えて、当該ユーザ端末５の現在位置を示す位置情報８ｂを取得するための構成を更に備える。位置情報８ｂを取得するための構成としては、例えば、ＧＰＳによってユーザ端末５の位置情報８ｂを取得するモジュール、または、通信可能な無線ＬＡＮ（Ｗｉ−Ｆｉ）アクセスポイントの位置情報８ｂから、ユーザ端末５の位置情報８ｂを取得するモジュールが採用されてもよい。無線ＬＡＮアクセスポイントの位置情報８ｂを用いる手段によれば、緯度経度に加えて、建物内の階数等、より詳細な位置情報８ｂを得ることも可能である。更に、位置情報８ｂを取得するための構成には、その他の手段が採用されてもよいし、ＧＰＳを用いる手段および無線ＬＡＮアクセスポイントの位置情報８ｂを用いる手段を含む様々な手段から、複数の手段が組み合わされて用いられてもよい。
【００２５】
次に、本システムを構成する各端末が備える機能について説明する。図３Ａから図３Ｃは、本実施形態に係るシステムの機能構成の概略を示す図である。
【００２６】
図３Ａは、本実施形態に係るイベント登録端末４の機能構成の概略を示す図である。イベント登録端末４は、システムにイベント情報９を登録するための端末であり、イベント発生条件９３、イベント内容格納先情報９２およびイベント内容９１を含むイベント情報９を生成するイベント生成部４１と、生成されたイベント情報９をイベント制御モジュール１やストレージ２等に登録するイベント登録部４２と、を備える。より具体的には、イベント登録部４２は、イベント発生条件９３およびイベント内容格納先情報９２をイベント制御モジュール１に登録し、イベント内容９１を、イベント内容格納先情報９２に示されたストレージ２に格納させる。例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、携帯電話、スマートフォン、タブレット端末、携帯ゲーム機等を、イベント登録端末４として用いることが出来る。
【００２７】
ストレージ２は、イベント内容９１を受け取り、格納するイベント内容格納部を備える（図示は省略する）。例えば、クラウドストレージ、サーバ等を、ストレージ２として用いることが出来る。
【００２８】
図３Ｂは、本実施形態に係るユーザ端末５の機能構成の概略を示す図である。ユーザ端末５は、ユーザがイベント情報９を受け取るための端末であり、ユーザの情報を取得し、イベント制御モジュール１へ送信するユーザ情報取得機能、およびイベントを発生させるイベント発生機能を備える。より具体的には、ユーザ端末５は、ＳＮＳ３上のユーザに係る情報を取得するＳＮＳ情報取得部５１と、ユーザ端末５の現在位置の位置情報８ｂを取得する位置情報取得部５２と、認証情報８ｅを取得する認証情報取得部５３と、取得した情報をイベント制御モジュール１へ送信するユーザ情報送信部５４と、ストレージ２からイベント内容９１を受け取るイベント内容受取部５５と、イベント制御モジュール１からイベント発生トリガを受け取るイベント発生トリガ受取部５６と、イベント発生トリガを受けて、イベント内容９１に従ったイベントを実行するイベント実行部５７と、を備える。このうち、ＳＮＳ情報取得部５１、位置情報取得部５２、認証情報取得部５３およびユ
ーザ情報送信部５４によってユーザ情報取得機能が実現され、イベント内容受取部５５、イベント発生トリガ受取部５６およびイベント実行部５７によってイベント発生機能が実現される（図３Ｂを参照）。例えば、ＰＣ、携帯電話、スマートフォン、タブレット端末、携帯ゲーム機等を、ユーザ端末５として用いることが出来る。
【００２９】
なお、イベントの発生主体はユーザ端末５でなくてもよい。ユーザ端末５以外においてイベントを発生させる場合の構成および処理については、後述する。また、ユーザ端末５をイベント登録端末４としても用いる場合、ユーザ端末５は、上記説明したユーザ端末５の機能と、イベント登録端末４の機能とを兼ね備える。
【００３０】
図３Ｃは、本実施形態に係るイベント制御モジュール１の機能構成の概略を示す図である。イベント制御モジュール１は、イベント登録機能、ユーザ情報受取機能、イベント発生条件判定機能およびイベント発生機能を有し、イベント発生条件９３およびユーザ情報８から、各ユーザがイベント発生条件９３を満たすか否かを判定する。より具体的には、本実施形態に係るイベント制御モジュール１は、ＣＰＵ１１が、ＲＡＭ１２に展開された各種プログラムを解釈および実行することで、イベント発生条件受取部２１と、ユーザ情報受取部２２と、時刻取得部２３と、イベント発生条件判定部２４と、イベント発生トリガ送信部２５と、イベント内容格納先情報送信部２６と、を備える情報処理装置として機能する（図３Ｃを参照）。また、本実施形態では、これらの機能がいずれも汎用のＣＰＵ１１によって実行される例について説明しているが、これらの機能は、その一部または全部が、１または複数の専用のプロセッサによって実現されてもよい。なお、イベント制御モジュール１は、例えば、クラウド上、サーバ上、ユーザ端末５上等に実装されてよい。
【００３１】
イベント発生条件受取部２１は、イベント発生条件９３およびイベント内容格納先情報９２を、イベント登録端末４から受け取る。
【００３２】
ユーザ情報受取部２２は、ユーザ端末５からユーザ情報８を受け取る。ここで、ユーザ情報８には、ユーザ属性８ａ、ユーザの現在位置を示す位置情報８ｂ、ユーザが属する所定のユーザ集合の状態（以下、「集合状態」と称する）８ｃ、現在時刻８ｄおよびユーザの認証情報８ｅの少なくとも何れかを含む。なお、集合状態８ｃは、例えば、他のユーザを含むユーザの集合において、ユーザ属性８ａまたは位置情報８ｂが所定の条件を満たすユーザの数や、所定のユーザの位置情報８ｂが所定の条件を満たしているか否か、等を示す情報であり、他のユーザのユーザ属性８ａや位置情報８ｂ等に基づいて得ることが出来る。
【００３３】
時刻取得部２３は、現在時刻８ｄを取得する。なお、現在時刻８ｄは、ユーザ端末５によって取得させ、イベント制御モジュール１に対して送信させることとしてもよいが、本実施形態では、イベント制御モジュール１の時刻取得部２３によって取得した現在時刻８ｄを、ユーザ情報８として用いることとしている。これによって、ユーザがユーザ端末５の時刻設定を変更する等して不正にイベントを発生させることを防止することが出来る。
【００３４】
イベント発生条件判定部２４は、イベント発生条件９３およびユーザ情報８に基づいて各ユーザがイベント発生条件９３を満たすか否かを判定する。より具体的には、イベント発生条件判定部２４は、ユーザ情報８に含まれるユーザ属性８ａ、位置情報８ｂ、集合状態８ｃ、現在時刻８ｄおよび認証情報８ｅが、イベントに関連付けられたイベント発生条件９３に含まれる属性条件９３ａ、場所条件９３ｂ、集合状態条件９３ｃ、時間条件９３ｄおよび認証条件９３ｅを満たすか否かを判定する。ここで、各条件には、ユーザ毎またはユーザの組み合わせ毎に異なるものが設定されてもよい。例えば、場所条件９３ｂには、ユーザ毎またはユーザの組み合わせ毎に異なる場所を設定することが出来る。
【００３５】
図４は、本実施形態において用いられるイベント発生条件９３の構成を示す図である。図４に示されたイベント発生条件９３には、属性条件９３ａ、場所条件９３ｂおよび集合状態条件９３ｃが設定されている。また、イベント発生条件９３には、更に、時間条件９３ｄおよび認証条件９３ｅが設定されてもよい。
【００３６】
ここで、属性条件９３ａとは、イベントを発生させたいユーザまたはユーザ端末５の属性を判定するための条件であり、例えば、ユーザのＳＮＳ３参加状態が判定される。より具体的には、ユーザが所属するＳＮＳ３上のグループ・コミュニティ等の参加状態や、ユーザがＳＮＳ３上のプロフィールで表明している趣味や趣向等のステイタス等が判定される。ここで、グループの例としては、所属会社、所属部門、所属サークル、在籍または卒業した学校、等が挙げられ、ステイタスの例としては、出身地、居住地、在籍または卒業した学校、勤務先、趣味、等が挙げられる。
【００３７】
場所条件９３ｂとは、イベントを発生させたい場所を判定するための条件であり、グループ単位・個人単位で設定可能である。場所条件９３ｂは、例えば、緯度経度の範囲指定によって設定されてもよいし、地図上にマッピングされたエリアを指定することによって設定されてもよい。場所条件９３ｂを緯度経度の範囲指定によって設定する場合、例えば、中心点の緯度経度と中心点からの距離とを用いて円形の範囲を指定することによって設定することが出来る。場所条件９３ｂの設定方法は実施の形態に応じて適宜選択可能であり、本開示において説明した方法に限定されない。また、場所条件９３ｂには、複数地点が設定されてもよいし、固定位置以外が設定されてもよい。
【００３８】
集合状態条件９３ｃとは、イベントを発生させたいユーザ端末５の集合状態８ｃを判定するための条件であり、例えば、場所条件９３ｂを満たしているユーザの数（「場所条件を満たしたユーザがｎ人以上」等）、場所条件９３ｂを満たさなければならない特定ユーザの存在（キーパーソン）、ユーザが更に満たさなければならない絞り込み条件、等が設定されてよい。
【００３９】
また、時間条件９３ｄとは、現在時刻８ｄが、イベントが発生する時間であるか否かを判定するための条件であり、例えば、特定の月日・時刻・曜日・期間等によって設定可能である。
【００４０】
認証条件９３ｅとは、ユーザ端末５のユーザを認証したい場合に利用される条件であり、主にセキュリティ強化や、ユーザまたはキーパーソンの本人確認に利用される。認証に用いられる具体的な手法としては、一般的なユーザ識別子（社員番号等）とパスワードを用いた認証の他、合言葉・パスワード・会員番号等を音声で入力して行う音声認証、合言葉・パスワード・会員番号等を文字で入力して行う文字認証、ユーザのポーズや動き等を入力装置において検出して行うジェスチャー認証、会員証・ＱＲコード・バーコード・景色を撮影し解析して行う画像・帳票認証、音声による話者認証・顔認証・指紋、掌紋認証・虹彩、網膜パターン・静脈パターン・筆跡鑑定による生体認証、ニーモニック認証、等が挙げられる。
【００４１】
イベント発生トリガ送信部２５は、イベント発生条件９３を満たすユーザ端末５にイベント発生トリガを送信することで、イベント内容９１に示されたイベントの発生を許可または指示する。即ち、イベント発生トリガ送信部２５は、イベント発生条件９３が満たされたと判定された場合に、イベントの発生を許可または指示する。
【００４２】
イベント内容格納先情報送信部２６は、イベント発生条件９３を満たすユーザ端末５にイベント内容格納先情報９２を送信する。
【００４３】
＜処理の流れ＞
以下、図５から図１７を用いて、本実施形態に係る処理の詳細を説明する。なお、本実施形態において説明される処理の具体的な内容および順序等は、実施する上での一例である。具体的な処理内容および順序等は、実施の形態に応じて適宜選択されてよい。
【００４４】
図５は、本実施形態に係るシステムにおける処理のフェーズを示す図である。本実施形態に係るシステムによって実行される処理は、大きく分けて事前設定フェーズと運用フェーズに分けられる。事前設定フェーズは、イベント情報９の生成およびイベント情報９の登録からなるフェーズであり、イベント登録端末４にてイベント情報９が生成され、生成されたイベント情報９がイベント制御モジュール１およびストレージ２に登録される、いわば準備段階に相当するフェーズである。一方、運用フェーズは、ユーザ情報８の取得、イベント発生要否の判定およびイベントの発生からなるフェーズであり、事前設定フェーズにおいて設定された条件等に基づいて、システムが運用されるフェーズである。
【００４５】
初めに、事前設定フェーズにおける処理について説明する。
【００４６】
図６は、本実施形態に係るイベント生成処理の概要を示す図である。管理者であるユーザは、イベント登録端末４に対して、イベント内容９１、イベント発生条件９３およびイベント内容格納先情報９２を入力する。入力を受けたイベント登録端末４のイベント生成部４１は、ユーザの入力に従って、イベント内容９１、イベント発生条件９３およびイベント内容格納先情報９２を含むイベント情報９を生成する。
【００４７】
図７は、本実施形態において生成されるイベント情報９の例を示す図である。この例において、イベント情報９を作成する管理者は会議主催者であり、情報漏洩の防止の観点から、事前のメールによる資料配布や印刷物の配布を行うことなく、機密資料の情報を、会議中にのみ会議参加者と共有したいと考えている。また、この会議で閲覧される資料は、所属部の管理職の承認が必要な資料であることとする。
【００４８】
上記のような要求を満たすイベント情報９を作成するため、管理者は、イベント登録端末４に対して、イベント内容９１として「機密資料の閲覧（機密資料が格納されたストレージ２へのアクセス許可、および機密資料の暗号解除）」を、イベント発生条件９３のうち場所条件９３ｂとして「東京本社（営業グループ・企画グループ対象）」および「大阪支店（開発グループ対象）」を、イベント発生条件９３のうち属性条件９３ａとして「営業グループ ＯＲ 企画グループ ＯＲ 開発グループ」を、集合状態条件９３ｃとして「各場所において当該ユーザの管理職が同行していること」を、時間条件９３ｄとして「会議中の時間帯（８月１７日 １３：００−１８：００）」を、認証条件９３ｅとして「社員番号とパスワードの入力」を、入力する。イベント内容格納先情報９２には、例えば、「○○クラウドストレージの△△フォルダ」等のように、会議の開催地からアクセス可能なストレージ２が適宜設定される。入力を受けたイベント登録端末４のイベント生成部４１は、上記入力内容に従って、イベント内容９１、イベント発生条件９３およびイベント内容格納先情報９２を含むイベント情報９を生成する（図７を参照）。イベント情報９の生成が完了すると、その後、処理はイベント登録処理に進む。
【００４９】
図８は、本実施形態に係るイベント登録処理の概要を示す図である。イベント情報９が生成されると、イベント登録端末４のイベント登録部４２は、生成されたイベント情報９を登録する。具体的には、イベント登録端末４のイベント登録部４２は、イベント発生条件９３およびイベント内容格納先情報９２をイベント制御モジュール１に対して送信し、イベント内容９１を、イベント内容格納先情報９２に示されているストレージ２に対して送信する。イベント発生条件９３およびイベント内容格納先情報９２を受信したイベント制御モジュール１のイベント発生条件受取部２１は、補助記憶装置１９にイベント発生条
件９３およびイベント内容格納先情報９２を登録する。また、イベント内容９１を受信したストレージ２は、イベント内容９１を格納する。
【００５０】
次に、運用フェーズにおける処理について説明する。
【００５１】
図９は、本実施形態に係るユーザ情報取得処理の概要を示す図である。図９に示された処理は、イベント情報９が登録されると、定期的に実行される。ユーザ端末５は、ユーザ情報８を取得し、イベント制御モジュール１へ送信する。ユーザ情報８には、ユーザ属性８ａ、位置情報８ｂおよび認証情報８ｅ等が含まれる。
【００５２】
図１０は、本実施形態においてユーザ端末５のＳＮＳ情報取得部５１によって取得される、ユーザ属性８ａの例を示す図である。図１０に示す例では、ユーザ端末５のＳＮＳ情報取得部５１は、ＳＮＳ３のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）から、ユーザＡ〜Ｆのユーザ属性８ａとして、会社においてユーザの所属するグループ、およびユーザのステイタス（役職等）等を取得する。
【００５３】
図１１は、本実施形態において複数のユーザ端末５によってユーザ情報８が取得され、イベント制御モジュール１に対して送信される様子を例示する図である。ユーザ端末５のＳＮＳ情報取得部５１は、ＳＮＳ３のＡＰＩを呼び出す等の方法で、インターネットを介して、ユーザ属性８ａを取得し、位置情報取得部５２は、位置情報取得用のＡＰＩ等を介して、ＧＰＳ等を用いて得られたユーザ端末５の位置情報８ｂを取得する。また、ユーザ端末５の認証情報取得部５３は、認証情報ＡＰＩ等を介して、ユーザによって入力された社員番号（従業員番号）とパスワードとの組み合わせを認証サーバに送信する。社員番号とパスワードとの組み合わせを受信した認証サーバは、社員番号とパスワードとの組み合わせが、判定対象となっているユーザ端末５のユーザの社員番号およびパスワードと一致するか否かを判定する。なお、ユーザ毎の社員番号とパスワードとの組み合わせは、認証サーバによって予め保持されている。認証サーバは、ユーザの認証（本人確認）が完了すると、本人確認結果として、ユーザ端末５に対して認証情報８ｅを送信する。
【００５４】
ユーザ属性８ａ、位置情報８ｂおよび認証情報８ｅ等のユーザ情報８が取得されると、ユーザ端末５のユーザ情報送信部５４は、取得されたユーザ情報８を、イベント制御モジュール１に対して送信する。そして、イベント制御モジュール１のユーザ情報受取部２２は、ユーザ端末５より送信されたユーザ情報８を受信する。また、イベント制御モジュール１の時刻取得部２３は、現在時刻８ｄを取得し、取得された時刻を、ユーザ情報８が取得された時刻として、ユーザ情報８に組み込む。
【００５５】
図１２は、本実施形態においてイベント制御モジュール１によって取得された、ユーザ情報８の例を示す図である。ユーザ情報８が取得されると、処理はイベント発生判定処理に進む。
【００５６】
図１３は、本実施形態に係るイベント発生判定処理の概要を示す図である。イベント発生判定処理では、ユーザ情報８とイベント発生条件９３の判定が行われ、条件を満たすユーザ端末５に、イベント発生トリガとイベント内容格納先情報９２が送信される。以下、イベント発生判定処理の詳細を説明する。
【００５７】
イベント発生条件判定部２４は、事前設定フェーズのイベント登録処理において予め登録されていたイベント発生条件９３を、補助記憶装置１９から読み出し、ユーザ情報取得処理において取得されたユーザ情報８と比較することで、イベント発生条件判定を行う。
【００５８】
図１４は、本実施形態に係るイベント発生条件判定処理の流れを示すフローチャートで
ある。本フローチャートに示された処理は、ユーザ情報受取部２２によってユーザ情報８が取得されたことを契機として実行される。
【００５９】
ステップＳ１０１では、ユーザ端末５の使用ユーザの属性が属性条件９３ａを満たしているか否かが判定される。イベント発生条件判定部２４は、取得されたユーザ情報８に含まれるユーザ属性８ａが、イベント発生条件９３に設定されている属性条件９３ａを満たしているか否かを判定する。即ち、ステップＳ１０１では、ユーザ端末を使用するユーザ自身が所定の属性を有しているか否かの判定が行われる。
【００６０】
図７に示されたイベント情報９の例では、属性条件９３ａとして「営業グループ ＯＲ
企画グループ ＯＲ 開発グループ」が設定されている。このため、イベント発生条件判定部２４は、ユーザ属性８ａが営業グループ、企画グループおよび開発グループの少なくとも何れかに該当するか否かを判定する。図１２に示した例では、ユーザＡ〜Ｅは属性条件９３ａを満たすが、ユーザＦは事務グループ所属であり、属性条件９３ａを満たさない。
【００６１】
ユーザの属性が属性条件９３ａを満たしていないと判定された場合、処理はステップＳ１０７へ進む。一方、ユーザの属性が属性条件９３ａを満たしていると判定された場合、処理はステップＳ１０２へ進む。
【００６２】
ステップＳ１０２では、ユーザ端末５の現在位置が場所条件９３ｂを満たしているか否かが判定される。イベント発生条件判定部２４は、取得されたユーザ情報８に含まれる位置情報８ｂが示す現在位置が、イベント発生条件９３に設定されている場所条件９３ｂを満たしているか否かを判定する。例えば、位置情報８ｂが緯度経度で示される場合、イベント発生条件判定部２４は、位置情報８ｂが示す緯度経度が、場所条件９３ｂに示された緯度経度の範囲内であるか否かを判定することで、ユーザ情報８に含まれる位置情報８ｂが示す現在位置が場所条件９３ｂを満たしているか否かを判定する。
【００６３】
図７に示されたイベント情報９の例では、場所条件９３ｂとして「東京本社（営業グループ・企画グループ対象）」および「大阪支店（開発グループ対象）」が設定されている。このため、イベント発生条件判定部２４は、営業グループ・企画グループに属するユーザ（図１２に示した例では、ユーザＡ、Ｂ、およびＥ）については、位置情報８ｂが示す現在位置が東京本社の範囲内であるか否かを判定し、開発グループに属するユーザ（図１２に示した例では、ユーザＣおよびＤ）については、位置情報８ｂが示す現在位置が大阪支店の範囲内であるか否かを判定する。図１２に示した例では、ユーザＡ〜Ｃ、ＥおよびＦは場所条件９３ｂを満たすが、ユーザＤの位置情報８ｂはユーザＤの現在地が富士山であることを示しており、場所条件９３ｂを満たさない。
【００６４】
ユーザ端末５の位置情報８ｂが場所条件９３ｂを満たしていないと判定された場合、処理はステップＳ１０７へ進む。一方、ユーザ端末５の位置情報８ｂが場所条件９３ｂを満たしていると判定された場合、処理はステップＳ１０３へ進む。
【００６５】
ステップＳ１０３では、ユーザ端末５の集合の状態が集合状態条件９３ｃを満たしているか否かが判定される。イベント発生条件判定部２４は、他のユーザ端末５を含む所定のユーザ端末５の集合の状態（集合状態）が、イベント発生条件９３に設定されている集合状態条件９３ｃを満たしているか否かを判定する。集合状態条件９３ｃとしては、例えば、場所条件９３ｂを満たしているユーザの数（「場所条件を満たしたユーザがｎ人以上」等）、特定ユーザが場所条件９３ｂを満たしていること（キーパーソンが所定場所に居ること）、ユーザが更に満たさなければならない絞り込み条件、等が判定されてよい。
【００６６】
集合状態条件９３ｃを用いた判定に用いる集合状態８ｃの情報は、図１２に示した、イベント制御モジュール１によって蓄積されている他のユーザ端末５のユーザ情報８を含むユーザ情報の集合を参照し、集合状態条件に応じた分析処理を行うことで、集合状態を取得することが出来る。例えば、集合状態条件９３ｃが「属性条件を満たしたユーザのうち、場所条件を満たしたユーザがｎ人以上」である場合、イベント発生条件判定部２４は、属性条件を満たした他のユーザ端末５のユーザ情報８を含むユーザ情報の集合を参照し、場所条件を満たしたユーザの数をカウントすることで、集合状態を取得することが出来る。また、例えば、集合状態条件９３ｃが「特定ユーザが場所条件９３ｂを満たしていること」である場合、イベント発生条件判定部２４は、他のユーザ端末５のユーザ情報８を含むユーザ情報の集合を参照し、特定ユーザが場所条件９３ｂを満たしているか否かを判定することで、集合状態を取得することが出来る。
【００６７】
図７に示されたイベント情報９の例では、集合状態条件９３ｃとして「各場所において当該ユーザの管理職が同行していること」が設定されている。このため、イベント発生条件判定部２４は、営業グループ・企画グループに属するユーザ（図１２に示した例では、ユーザＡ、Ｂ、およびＥ）については、東京本社の範囲内に管理職であるユーザが居るか否かを判定し、開発グループに属するユーザ（図１２に示した例では、ユーザＣおよびＤ）については、大阪支店の範囲内に管理職であるユーザがいるか否かを判定する。図１２に示した例では、ユーザＡおよびＢについては、営業グループの管理職（部長）であるユーザＡが東京本社にいるため集合状態条件９３ｃを満たし、ユーザＣおよびＤについては、開発グループの管理職（部長）であるユーザＣが大阪支店にいるため集合状態条件９３ｃを満たすが、ユーザＥについては、企画グループの管理職が東京本社に居ないため、集合状態条件９３ｃを満たさない。
【００６８】
ユーザ端末５の集合の状態が集合状態条件９３ｃを満たしていないと判定された場合、処理はステップＳ１０７へ進む。一方、ユーザ端末５の集合の状態が集合状態条件９３ｃを満たしていると判定された場合、処理はステップＳ１０４へ進む。
【００６９】
ステップＳ１０４では、現在時刻８ｄが時間条件９３ｄを満たしているか否かが判定される。イベント発生条件判定部２４は、取得されたユーザ情報８に含まれる現在時刻８ｄが、イベント発生条件９３に設定されている時間条件９３ｄを満たしているか否かを判定する。より具体的には、イベント発生条件判定部２４は、現在時刻８ｄが、時間条件９３ｄに示された開始時刻以降であり且つ終了時刻以前であるか否かを判定することで、現在時刻８ｄが時間条件９３ｄを満たしているか否かを判定する。但し、時間条件９３ｄには、開始時刻および終了時刻の何れか一方のみが設定されていてもよい。
【００７０】
図７に示されたイベント情報９の例では、時間条件９３ｄとして「会議中の時間帯（８月１７日 １３：００−１８：００）」が設定されている。このため、イベント発生条件判定部２４は、現在時刻８ｄが８月１７日の１３：００以降且つ１８：００以前であるか否かを判定する。図１２に示した例では、イベント発生条件判定処理は会議中の時間帯に実行されており、ユーザＡ〜Ｆは何れも時間条件９３ｄを満たす。
【００７１】
現在時刻８ｄが時間条件９３ｄを満たしていないと判定された場合、処理はステップＳ１０７へ進む。一方、現在時刻８ｄが時間条件９３ｄを満たしていると判定された場合、処理はステップＳ１０５へ進む。
【００７２】
ステップＳ１０５では、ユーザ端末５の認証情報８ｅが認証条件９３ｅを満たしているか否かが判定される。イベント発生条件判定部２４は、取得されたユーザ情報８に含まれる認証情報８ｅが、イベント発生条件９３に設定されている認証条件９３ｅを満たしているか否かを判定する。
【００７３】
図７に示されたイベント情報９の例では、認証条件９３ｅとして「社員番号とパスワードの入力」が設定されている。このため、イベント発生条件判定部２４は、ユーザ情報８に、社員番号とパスワードが入力されて認証サーバによる本人確認が為されたことを示す認証情報８ｅが含まれているか否かを参照することで判定する。図１２に示した例では、ユーザＡ〜Ｆは何れも認証条件９３ｅを満たす。なお、本実施形態では、ユーザ情報８に認証情報８ｅとして認証サーバによる本人確認結果が含まれ、これを参照して判定を行うこととしているが、このような方法に代えて、ユーザ情報８に社員番号とパスワードが含まれ、イベント制御モジュール１によって社員番号とパスワードの正当性が判定されることで、認証条件９３ｅが満たされているか否かを判定することとしてもよい。
【００７４】
認証情報８ｅが認証条件９３ｅを満たしていないと判定された場合、処理はステップＳ１０７へ進む。一方、認証情報８ｅが認証条件９３ｅを満たしていると判定された場合、処理はステップＳ１０６へ進む。
【００７５】
ステップＳ１０６では、イベント発生トリガが送信される。イベント発生トリガ送信部２５は、ステップＳ１０１からステップＳ１０５までの全ての判定において条件が満たされていた場合、イベント発生条件９３が満たされたと判断して、ユーザ端末５に対してイベント発生トリガを送信する。
【００７６】
図１５は、本実施形態に係るイベント発生条件判定結果の例を示す図である。図１５に示された例では、ユーザＡ〜Ｃについては、イベント発生条件９３が満たされているため、イベント発生トリガ送信部２５によってイベント発生トリガが送信される。一方、ユーザＤ〜Ｆについては、イベント発生条件９３が満たされていないため、イベント発生トリガは送信されない。その後、本フローチャートに示された処理は終了し、処理はイベント発生処理へ進む。
【００７７】
ステップＳ１０７では、エラーメッセージが出力される。イベント制御モジュール１は、ステップＳ１０１からステップＳ１０５までの何れかの判定において条件が満たされなかった場合、イベント発生条件９３が満たされなかったと判断して、ユーザ端末５に対してエラーメッセージを送信する。図１５に示された例では、ユーザＤ〜Ｆについては、イベント発生条件９３が満たされていないため、エラーメッセージが送信される。その後、本フローチャートに示された処理は終了する。
【００７８】
但し、ステップＳ１０７におけるエラーメッセージの送信は行われなくてもよい。例えば、定期的にイベント発生条件判定処理を実行し、イベント発生条件９３が満たされた時点で自動的に発生するようなイベント等、エラーメッセージを出力することが好ましくないイベントについては、エラーメッセージは送信されなくてもよい。一方、ユーザによるイベントのリクエストを受けてイベント発生条件判定処理を実行するようなイベント等、ユーザにイベントが発生しないことを通知することが好ましいイベントについては、エラーメッセージが送信されてよい。
【００７９】
再び図１３を参照し、図１４のフローチャートに示されたイベント発生条件判定処理においてイベント発生条件９３が満たされたと判定された場合の処理の流れを説明する。上述の通り（図１４のステップＳ１０６を参照）、イベント発生トリガ送信部２５は、イベント発生条件９３が満たされた場合、ユーザ端末５に対してイベント発生トリガを送信する。送信されたイベント発生トリガは、ユーザ端末５のイベント発生トリガ受取部５６によって受信される。
【００８０】
また、イベント制御モジュール１のイベント内容格納先情報送信部２６は、補助記憶装
置１９から、満たされたイベント発生条件９３に対応するイベント内容格納先情報９２を読み出し、ユーザ端末５に対して送信する。ユーザ端末５のイベント内容受取部５５は、イベント内容格納先情報９２を受信すると、このイベント内容格納先情報９２を参照して、イベント内容格納先情報９２に示されたストレージ２にアクセスし、当該ストレージ２から、満たされたイベント発生条件９３に対応するイベント内容９１を取得する。その後、処理はイベント発生処理に進む。
【００８１】
なお、本実施形態では、イベント内容格納先情報９２およびイベント内容９１は、イベント発生条件９３を満たした場合に、ユーザ端末５によって取得されるが、イベント内容格納先情報９２およびイベント内容９１は、ユーザ端末５によって予め（イベント発生条件９３が満たされる前に）取得されていてもよい。このようにすることで、イベント発生条件９３を満たした場合に、イベント発生トリガを発行するのみで、イベントを発生させることが出来る。
【００８２】
図１６は、本実施形態に係るイベント発生処理の概要を示す図である。ユーザ端末５のイベント実行部５７は、イベント発生トリガ受取部５６によってイベント発生トリガが受信されると、イベント内容９１に従ってイベントを発生させる。先述の通り、イベントの発生とは、所定のイベント用ソフトウェアの実行であってもよいし、所定の機能に対する指示（コマンド）の発行であってもよい。
【００８３】
図１７は、本実施形態におけるユーザ端末５毎のイベント発生状況の例を示す図である。図１５に示した例では、ユーザＡ・Ｂ・Ｃはすべてのイベント発生条件９３を満たしているため、それぞれの端末でイベント発生トリガおよびイベント内容格納先情報９２を受け取り、イベント内容９１「機密文書の閲覧」を取得し、イベントを発生させることが出来る（図１７を参照）。これに対して、ユーザＤは場所条件９３ｂを満たしていないため、ユーザＥは集合条件状態を満たしていないため、ユーザＦは属性条件９３ａを満たしていないため、イベント発生トリガおよびイベント内容格納先情報９２を受け取ることができず、イベント内容９１を取得することができない（図１７を参照）。また、ユーザＤ〜Ｆは、後日、イベント内容９１を受け取ろうとしても、時間条件９３ｄを満たすことが出来ないため、イベント発生トリガおよびイベント内容格納先情報９２を受け取ることができず、イベント内容９１を取得することができない。
【００８４】
また、イベント内容９１またはイベント内容格納先情報９２を暗号化しておき、イベント発生トリガ送信部２５は、暗号化されたイベント内容９１またはイベント内容格納先情報９２を復号するための復号鍵としてのイベント発生トリガを発行することで、イベントの発生を許可または指示することとしてもよい。このようにすることで、イベント発生条件９３が満たされていない状態でユーザ端末５がイベントを発生させようとしても、イベント内容９１またはイベント内容格納先情報９２を復号することが出来ない。即ち、このような仕組みによれば、ユーザによってイベントが不正に発生させられることを防止することが出来る。
【００８５】
＜バリエーション＞
次に、本開示に係るシステムを実施する場合の実施形態のバリエーションを説明する。
【００８６】
上記説明した実施形態では、イベント情報９に含まれる情報のうち、イベント発生条件９３およびイベント内容格納先情報９２は、イベント登録端末４からイベント制御モジュール１へ登録され、イベント内容９１は、イベント登録端末４から直接ストレージ２に格納される例について説明したが、イベント情報９の登録ルートは様々であってよい。
【００８７】
図１８は、イベント登録のバリエーションを示す図である。また、図１９は、図１８に
示されたバリエーションにおける、イベント制御モジュール１の機能構成の概略を示す図である。図１８に示した例では、イベント情報９に含まれるイベント内容９１、イベント発生条件９３およびイベント内容格納先情報９２は、イベント登録端末４からイベント制御モジュール１へ一旦送信される。そして、イベント制御モジュール１は、このうちイベント発生条件９３およびイベント内容格納先情報９２を登録し、イベント内容９１をストレージ２に転送してストレージ２に格納する。このため、本バリエーションに係るイベント制御モジュール１は、図３Ｃを用いて上述した機能に加えて、イベント内容経由部２７によるイベント内容経由機能を更に備える（図１９を参照）。
【００８８】
また、上記説明した実施形態では、イベント発生条件９３が満たされた場合のイベント発生の仕組みとして、イベント発生トリガおよびイベント内容格納先情報９２が、イベント制御モジュール１によってユーザ端末５宛に送信され、これを受信したユーザ端末５が、イベント内容格納先情報９２を参照して、ストレージ２にイベント内容９１を取りに行き、ユーザ端末５においてイベントを発生させる仕組みが採用されているが、このような仕組みに代えて、他のイベント発生の仕組みが採用されてもよい。
【００８９】
図２０は、ストレージ２においてイベントを発生させる場合のイベント発生の仕組みを示す図である。また、図２１は、図２０に示されたバリエーションにおける、イベント制御モジュール１の機能構成の概略を示す図である。図２０に示された例では、イベント発生条件９３が満たされると、はじめに、イベント制御モジュール１が、イベント内容格納先情報９２を参照して、ストレージ２へイベント発生トリガを送信する。そして、ストレージ２内でイベント発生トリガとイベント内容９１が揃うことで、イベントが発生する。このため、本バリエーションに係るイベント制御モジュール１は、図３Ｃを用いて上述したイベント内容格納先情報送信部２６を備えなくてもよい。また、イベント制御モジュール１のイベント発生トリガ送信部２５は、ストレージ２に対してイベント発生トリガを送信する（図２１を参照）。
【００９０】
図２２は、ユーザ端末５においてイベントを発生させる場合のイベント発生の仕組みを示す図である。また、図２３は、図２２に示されたバリエーションにおける、イベント制御モジュール１の機能構成の概略を示す図である。図２２に示された例では、イベント発生条件９３が満たされると、はじめに、イベント制御モジュール１が、イベント内容格納先情報９２を参照して、ストレージ２にイベント内容９１を取りに行く。そして、イベント制御モジュール１が、イベント内容９１とイベント発生トリガをユーザ端末５に送信することで、ユーザ端末５においてイベント発生トリガとイベント内容９１が揃い、イベントが発生する。このため、本バリエーションに係るイベント制御モジュール１は、図３Ｃを用いて上述したイベント発生トリガ送信部２５およびイベント内容格納先情報送信部２６に代えて、イベント内容格納先情報９２を参照してストレージ２からイベント内容９１を取得するイベント内容取得部２８と、イベント内容９１をユーザ端末５に送信するイベント内容送信部２９と、を備える（図２３を参照）。
【００９１】
図２４は、イベント制御モジュール１においてイベントを発生させる場合のイベント発生の仕組みを示す図である。また、図２５は、図２４に示されたバリエーションにおける、イベント制御モジュール１の機能構成の概略を示す図である。図２４に示された例では、イベント発生条件９３が満たされると、はじめに、イベント制御モジュール１が、イベント内容格納先情報９２を参照して、ストレージ２にイベント内容９１を取りに行く。そして、イベント制御モジュール１内でイベント発生トリガとイベント内容９１が揃うことで、イベントが発生する。このため、本バリエーションに係るイベント制御モジュール１は、図３Ｃを用いて上述したイベント発生トリガ送信部２５およびイベント内容格納先情報送信部２６に代えて、イベント内容格納先情報９２を参照してストレージ２からイベント内容９１を取得するイベント内容取得部２８と、イベント発生トリガとイベント内容９
１とが揃った場合にイベントを発生させるイベント実行部３０と、を備える（図２５を参照）。
【００９２】
＜システムの使用例＞
次に、本開示を適用可能なシステムの具体例を説明する。
【００９３】
（ゲームシステム）
図２６は、本実施形態に係るシステムを、複数ユーザが、夫々のユーザ端末５を用いてネットワークを介して相互に接続し、同時にプレイするゲームシステムに適用する例を示す図である。本実施例では、ユーザ端末５は、上記説明した機能の他、ゲーム機能を備える。このゲームは、例えば、複数のユーザが協力してモンスターを倒し、ゲーム中で用いることのできる特典やアイテムを入手することを目的とするゲームである。
【００９４】
図２７Ａから図２７Ｄは、本実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報９の例を示す図である。このうち、図２７Ａから図２７Ｃに示した例では、図２６に示されたチームαは、キャンペーン期間（８月）中に、チームの２人以上が、東京タワー、東京スカイツリーまたは秋葉原に居る場合に、イベントを発生させることが出来る。ここで発生させるイベントは、限定モンスターの出現や、ゲーム中の特殊装備の取得、ゲーム中のレアアイテムの取得をするためのくじ引き等である。また、図２７Ｂに示されたイベント情報９によれば、認証条件９３ｅとして、図２７Ａに示されたイベント情報９に係るイベントで出現した限定モンスターを倒していることが設定されている。このようにして、複数のイベントに関連性を持たせることとしてもよい。
【００９５】
このような例によれば、ゲームの提供者は、場所条件９３ｂに設定された観光地等と協力して宣伝効果を高めることが出来、場所条件９３ｂに設定された観光地等は、ゲームを利用して集客することが出来る。また、ユーザも、他のユーザと交流しながらゲームをプレイしたり、特典を得たりすることが出来る。
【００９６】
また、図２７Ｄに示した例では、集合状態条件９３ｃとして「同じグループに属していないプレイヤー（ユーザ）が３人以上集まる」ことが設定されており、また、イベント内容９１は、「３〜４人のグループを自動結成」である。このようにすることで、普段チームを組んでいないユーザ同士が集まって新たなチームを組み、ゲームをプレイすることが出来る。即ち、このようなイベント情報９を設定することで、ユーザが会場（ゲーム会社とコラボレーションした店舗等）に到着すると、自動的にチームが結成され、そのチームでゲームを行うこととなる。自動的に組まれたチームによるプレイの終了後は、このチームを解消してもよいし、そのまま継続してもよい。
【００９７】
（地域社会連携システム）
図２８は、本実施形態に係るシステムを、地域社会連携システムに適用する場合に登録されるイベント情報９の例を示す図である。従来、学校・地域・ＰＴＡ等の地域社会では、子供が通学時に交通事故や犯罪に巻き込まれないよう、対策を取っている。具体的には、通学時間帯に、スクールバスのバス停や横断歩道等に２〜３人の大人が立って、子供達を見守ること等である。この役割は当番制である。
【００９８】
また、警察や学校から、学区内の不審者情報が提供されるが、個人情報保護や関係者の身の安全のため、取り扱いには注意が必要である。多数複製して配布を行うには注意が必要であるため、通常は限定された数の複製を回覧する等するが、会合に参加していないと見ることが出来ない、時間が限られておりゆっくり閲覧できない、紙に印刷されたものであるため、必要な情報を探すのが面倒である、最新の情報を得ることが出来ない、等の問題があった。
【００９９】
そこで、図２８に示すようなイベント情報９を設定し、ユーザ端末５を用いてイベント条件を満たした場合にのみ閲覧させるようにすることで、情報閲覧の利便性を高めることが出来る。
【０１００】
図２９は、図２８に示したイベント情報９をもって本実施形態に係るシステムを運用した場合のイベント発生状況を示す図である。ユーザＡおよびＢが平日８：００以降且つ９：３０以前の通学時間帯に、一緒に学区１の交差点に立っている場合、イベント情報９に示されたイベント発生条件９３が満たされるため、ユーザＡおよびＢは、学区１の不審者情報を閲覧することが出来る。ユーザＣおよびＤも同様に、平日８：００以降且つ９：３０以前の通学時間帯に、一緒に学区２の交差点に立っている場合、イベント情報９に示されたイベント発生条件９３が満たされるため、学区２の不審者情報を閲覧することが出来る。しかし、通学時間帯ではない時間帯では、ユーザＡおよびＢ、またはユーザＣおよびＤが一緒に所定の交差点に立っても、不審者情報を閲覧することは出来ない。
【０１０１】
また、ユーザＥおよびＦは、平日８：００以降且つ９：３０以前の通学時間帯に、一緒に学区２の交差点に立っているが、ユーザＦは「グループ→ＰＴＡ会員グループ」との属性条件９３ａを満たさず、ユーザＥは「ＰＴＡ会員が二人以上いる」との集合状態条件９３ｃを満たさないため、ユーザＥおよびＦは、不審者情報を閲覧出来ない。また、ユーザＧおよびＨは、平日８：００以降且つ９：３０以前の通学時間帯に、一緒の場所に居るが、いずれも、「学区内」との場所条件９３ｂを満たさないため、不審者情報を閲覧出来ない。
【０１０２】
（オリエンテーリングシステム）
図３０は、本実施形態に係るシステムを、オリエンテーリングシステムに適用する場合に登録されるイベント情報９の例を示す図である。従来、オリエンテーリングのチーム活動において、全員で行動せず、各々でポイントを回り、ゴールのみチームで行う等の不正行為をしたチームがあっても、これを運営側が把握するのは難しかった。
【０１０３】
そこで、図３０に示したようなイベント情報９において、「チームメンバが全員そろっている」との集合状態条件９３ｃを設定し、イベント内容９１を「運営者へ、チームのポイント通過状況を通知」とすることで、運営側が不正行為を把握することが可能となる。
【０１０４】
図３１は、図３０に示したイベント情報９をもって本実施形態に係るシステムを運用した場合のイベント発生状況を示す図である。運営者は、チームが指令ポイントを通過すると、チームメンバが全員揃っているチームについて通過状況を受けることが出来る。
【０１０５】
また、イベント内容９１として、更に「ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）タグによる指令の閲覧」が設定されていることで、オリエンテーリングの参加者に、チームが全員揃っていることの特典を与えることが出来る。ＡＲタグは、図３１に示すように、ユーザ端末５のディスプレイにおいて、ユーザ端末５のカメラをもって撮像された画像に重ねて表示される画像であり、オリエンテーリングの進行に必要な情報を提供することが出来る。
【０１０６】
（会議管理システム）
図３２Ａおよび図３２Ｂは、本実施形態に係るシステムを、会議管理システムに適用する場合に登録されるイベント情報９の例を示す図である。この会議が秘密の情報を扱う会議である場合、会議において閲覧される資料のセキュリティを確保することが重要である。
【０１０７】
図３２Ａに示されたイベント情報９に設定されたイベント発生条件９３によれば、会議の時間帯に、役員会グループからの、本人確認済みの参加者全員が会議の開催場所に揃わないと資料を閲覧することが出来ない。但し、図３２Ａに示された場所条件９３ｂ「本部
ＯＲ 支部」のうち「支部」は、図３２Ｂに示されたイベント情報９に係るイベント「新規支部開設」を発生させることで、追加することが出来る。即ち、この実施例によれば、予め設定されていた支部に全員が揃っていなくても、会議の時間帯に、役員会グループに所属する本人確認済みのユーザ２人以上が、新たに支部を開設したい場所に居ることで、その場所を新たに支部とし、続いて図３２Ａに示されたイベントを発生させて、資料を閲覧することが出来る。
【０１０８】
（共有手帳システム）
図３３Ａから図３３Ｃは、本実施形態に係るシステムを、共有手帳システムに適用する場合に登録されるイベント情報９の例を示す図である。なお、共有手帳システムは、複数のユーザ（共有者）に対して共有のオンライン手帳サービスを提供するシステムであり、共有手帳は、例えば、恋人、夫婦、家族、等によって共有することが出来る。
【０１０９】
この実施例によれば、ユーザ属性８ａにおいて共有者（例えば、恋人同士）であるユーザが、図３３Ａのイベント情報９に係るイベントを発生させることで、複数の共有者（恋人であれば、２人）で同時に訪れた場所を、図３３Ｂおよび図３３Ｃに係るイベント条件の場所条件９３ｂとして登録することが出来る。そして、登録された場所で図３３Ｂのイベント情報９に係るイベントを発生させることで、思い出の場所で、写真＋アノテーション、コメント、ＡＲタグ、ＳＮＳ投稿等の「思い出登録」（図３３Ｂのイベント内容９１）をすることが出来る。また、登録された場所を再度複数の共有者で同時に訪れた際に、図３３Ｃのイベント情報９に係るイベントを発生させることで、アラート（通知）をし、以前に来た時に「思い出登録」した写真やＳＮＳ投稿等を見る「思い出再現」（図３３Ｃのイベント内容９１）をすることができる。なお、図３３Ｂのイベント内容９１「思い出登録」は、登録された場所を再度複数の共有者で訪れた際に発生させ、写真＋アノテーション、コメント、ＡＲタグ、ＳＮＳ投稿等の「思い出登録」を追加することができる。
【０１１０】
（情報配信システム）
図３４は、本実施形態に係るシステムを、情報配信システムに適用する場合に登録されるイベント情報９の例を示す図である。
【０１１１】
この実施例では、はじめに、場所条件９３ｂに設定された店舗（レストラン等）を訪れた際に、ユーザに、当該店舗を一緒に訪れた複数のユーザが属するグループを登録させる。ユーザは、ユーザ端末５を用いてグループに所属するユーザのＳＮＳ３における識別情報を指定し、ＳＮＳ３に送信する等の方法で、ＳＮＳ３のグループを作成することが出来る。このようにしておくことで、再度そのグループメンバーのうち２人以上（全員でなくてもよい）でレストラン周辺を訪れた際に、図３４のイベント情報９に係るイベントが発生し、当該グループに向けた、「今日のオススメ情報・クーポン配信」が行われる。
【０１１２】
なお、図３４のイベント情報９では、時間条件９３ｄが複数設定されており、何れの時間条件９３ｄを満たしたかによって、配信されるクーポンが異なる。図１４を用いて説明したイベント発生条件判定処理では、イベントに関連付けられたイベント発生条件９３に含まれる属性条件９３ａ、場所条件９３ｂ、集合状態条件９３ｃ、時間条件９３ｄおよび認証条件９３ｅを満たすか否かが判定されるが、夫々の条件内で複数の分岐が設定され、分岐の結果によって発生するイベントにバリエーションを持たせることとしてもよい。例えば、図３４に示された例では、時間条件９３ｄを満たすか否かのほかに、３つある時間条件９３ｄ（１０：００〜１３：００、１６：００〜２０：００および２１：００〜２２：００）の何れを満たしたかによって、配信されるクーポンの内容が変化する。
【０１１３】
＜効果＞
本実施形態に係るシステムによれば、位置情報を用いてイベントの制御を行うシステムにおいて、安全性を確保しつつ柔軟性を向上させることが可能となる。
【符号の説明】
【０１１４】
１ イベント制御モジュール
２１ イベント発生条件受取部
２２ ユーザ情報受取部
２３ 時刻取得部
２４ イベント発生条件判定部
２５ イベント発生トリガ送信部
２６ イベント内容格納先情報送信部
【技術分野】
【０００１】
本開示は、イベント制御のための技術に関する。
【背景技術】
【０００２】
従来、人、物体、または一群の人々／物体が、目的位置に到達し、あるいはその近くに来たときに、対話要求が実行される、近接性駆動式または位置駆動式の活動を実施するシステムが提案されている（特許文献１を参照）。
【０００３】
また、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）により取得した現在の地理的位置が許可された地理的位置である場合に限り、ユーザの格納情報へのアクセスを許可するアクセス制御方法（特許文献２を参照）や、ファイルにアクセスすることのできる地域をファイル自身に設定する位置情報付き暗号化システム（特許文献３を参照）等が提案されている。
【０００４】
更に、同じまたは略同じ位置で見つけられたソーシャルネットワークのメンバーについて関連付けられたＧＰＳ識別子とステイタスとを含むコンタクトコンテンツが、ＧＰＳ対応装置上に現れるシステムが提案されている（特許文献４を参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特表２００５−５０９１９８号公報
【特許文献２】特開２０００−１６３３７９号公報
【特許文献３】特開２００７−２４１９０７号公報
【特許文献４】特表２０１０−５２０５４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来、位置情報を用いて人や物体を関連付けるための技術が種々提案されている。また、位置情報を参照してアクセスの許可／不許可を判定する等、位置情報を用いてセキュリティを高める技術が種々提案されている。
【０００７】
しかし、セキュリティの高さとシステムの柔軟性は一般にトレードオフの関係にある。このため、位置情報等を用いてセキュリティを高めようとすると、システムの柔軟性が失われ、反対に、システムの柔軟性を高めようとすると、セキュリティが不十分となるという問題があった。
【０００８】
本開示は、上記した問題に鑑み、位置情報を用いてイベントの制御を行うシステムにおいて、安全性を確保しつつ柔軟性を向上させることを課題とする。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本開示に示された情報処理装置、イベント制御方法およびイベント制御用プログラムでは、イベントに設定された属性条件を満たす複数のユーザが場所条件を満たし、且つ集合状態条件を満たした場合に、イベントの発生を許可または指示することとした。
【００１０】
より詳細には、本開示に係る情報処理装置は、ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れか
を含むユーザ情報を取得するユーザ情報取得手段と、前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定手段と、前記判定手段によって、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御手段と、を備える情報処理装置である。
【００１１】
また、本開示は、コンピュータによって実行される方法、またはコンピュータに実行させるプログラムとしても把握することが可能である。また、本開示は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。
【発明の効果】
【００１２】
本開示に係る情報処理装置、イベント制御方法およびイベント制御用プログラムによれば、位置情報を用いてイベントの制御を行うシステムにおいて、安全性を確保しつつ柔軟性を向上させることが可能となる。
【図面の簡単な説明】
【００１３】
【図１】実施形態に係るシステムの構成の概略を示す図である。
【図２】実施形態に係るイベント制御モジュールのハードウェア構成の概略を示す図である。
【図３Ａ】実施形態に係るイベント登録端末の機能構成の概略を示す図である。
【図３Ｂ】実施形態に係るユーザ端末の機能構成の概略を示す図である。
【図３Ｃ】実施形態に係るイベント制御モジュールの機能構成の概略を示す図である。
【図４】実施形態において用いられるイベント発生条件の構成を示す図である。
【図５】実施形態に係るシステムにおける処理のフェーズを示す図である。
【図６】実施形態に係るイベント生成処理の概要を示す図である。
【図７】実施形態において生成されるイベント情報の例を示す図である。
【図８】実施形態に係るイベント登録処理の概要を示す図である。
【図９】実施形態に係るユーザ情報取得処理の概要を示す図である。
【図１０】実施形態においてユーザ端末のＳＮＳ情報取得部によって取得される、ユーザ属性の例を示す図である。
【図１１】実施形態において複数のユーザ端末によってユーザ情報が取得され、イベント制御モジュールに対して送信される様子を例示する図である。
【図１２】実施形態においてイベント制御モジュールによって取得された、ユーザ情報の例を示す図である。
【図１３】実施形態に係るイベント発生判定処理の概要を示す図である。
【図１４】実施形態に係るイベント発生条件判定処理の流れを示すフローチャートである。
【図１５】実施形態に係るイベント発生条件判定結果の例を示す図である。
【図１６】実施形態に係るイベント発生処理の概要を示す図である。
【図１７】実施形態におけるユーザ端末毎のイベント発生状況の例を示す図である。
【図１８】イベント登録のバリエーションを示す図である。
【図１９】バリエーションにおける、イベント制御モジュールの機能構成の概略を示す図である。
【図２０】ストレージにおいてイベントを発生させる場合のイベント発生の仕組みを示す図である。
【図２１】バリエーションにおける、イベント制御モジュールの機能構成の概略を示す図である。
【図２２】ユーザ端末においてイベントを発生させる場合のイベント発生の仕組みを示す図である。
【図２３】バリエーションにおける、イベント制御モジュールの機能構成の概略を示す図である。
【図２４】イベント制御モジュールにおいてイベントを発生させる場合のイベント発生の仕組みを示す図である。
【図２５】バリエーションにおける、イベント制御モジュールの機能構成の概略を示す図である。
【図２６】実施形態に係るシステムを、複数ユーザが、夫々のユーザ端末を用いてネットワークを介して相互に接続し、同時にプレイするゲームシステムに適用する例を示す図である。
【図２７Ａ】実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報の例を示す図である。
【図２７Ｂ】実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報の例を示す図である。
【図２７Ｃ】実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報の例を示す図である。
【図２７Ｄ】実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報の例を示す図である。
【図２８】実施形態に係るシステムを、地域社会連携システムに適用する場合に登録されるイベント情報の例を示す図である。
【図２９】実施形態に係るシステムを運用した場合のイベント発生状況を示す図である。
【図３０】実施形態に係るシステムを、オリエンテーリングシステムに適用する場合に登録されるイベント情報の例を示す図である。
【図３１】実施形態に係るシステムを運用した場合のイベント発生状況を示す図である。
【図３２Ａ】実施形態に係るシステムを、会議管理システムに適用する場合に登録されるイベント情報の例を示す図である。
【図３２Ｂ】実施形態に係るシステムを、会議管理システムに適用する場合に登録されるイベント情報の例を示す図である。
【図３３Ａ】実施形態に係るシステムを、共有手帳システムに適用する場合に登録されるイベント情報の例を示す図である。
【図３３Ｂ】実施形態に係るシステムを、共有手帳システムに適用する場合に登録されるイベント情報の例を示す図である。
【図３３Ｃ】実施形態に係るシステムを、共有手帳システムに適用する場合に登録されるイベント情報の例を示す図である。
【図３４】実施形態に係るシステムを、情報配信システムに適用する場合に登録されるイベント情報の例を示す図である。
【発明を実施するための形態】
【００１４】
以下、本開示に係る情報処理装置、イベント制御方法およびイベント制御用プログラムの実施の形態について、図面に基づいて説明する。なお、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理装置、イベント制御方法およびイベント制御用プログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の形態に応じた具体的構成が適宜採用されてよい。
【００１５】
本実施形態において、本開示に係る情報処理装置は、イベント制御モジュール１として実施される。但し、本開示の適用対象は、位置情報を用いてイベントの制御を行うシステ
ムであればよく、本実施形態において説明するシステムに限定されない。たとえば、情報処理装置は、ユーザ端末５によってイベントの制御が行われるシステムとして実施されてもよい。
【００１６】
本実施形態において、イベントとは、特定の条件の下で発生するものであり、イベント情報９によって定義される。イベント情報９には、事前に設定された、イベント発生のために課される条件であるイベント発生条件９３と、イベント内容９１の格納先を示すイベント内容格納先情報９２と、イベントとして発生させたい処理等を示すイベント内容９１と、が含まれる（図７等を参照）。
【００１７】
ここで、イベント内容９１は、発生させられるイベントの内容が記述された情報であり、記述のフォーマットは実施形態によって様々であり、限定されない。イベント内容９１は、例えば、イベント発生のために実行されるソフトウェア自体であってもよいし、イベントを実行する機能に対して与えられる指示（コマンド）であってもよい。また、イベント内容格納先情報９２は、イベント内容９１が格納されるストレージ２へのポインタである。イベント発生条件９３およびイベント内容格納先情報９２についても、記述のフォーマットは実施形態によって適宜採用可能であり、限定されない。
【００１８】
＜システムの構成＞
図１は、本実施形態に係るシステムの構成の概略を示す図である。本実施形態に係るシステムは、イベント制御モジュール１と、ストレージ２と、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）３と、イベント登録端末４と、ユーザ端末５と、がインターネット等のネットワークを介して互いに接続されたシステムである。なお、イベント制御モジュール１とストレージ２とは、別個のサーバとして構成されてもよいし、単一のサーバとして構成されてもよい。また、イベント登録端末４はユーザ端末５と同一の端末であってもよい。例えば、あるユーザが会議の参加メンバーでもあり主催者でもある場合、当該ユーザの端末は、イベント登録端末４とユーザ端末５とを兼ねる。
【００１９】
図２は、本実施形態に係るイベント制御モジュール１のハードウェア構成の概略を示す図である。イベント制御モジュール１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１２と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１３と、補助記憶装置１９と、ネットワークを介した外部との通信を行うためのネットワークインターフェース１６と、が電気的に接続された情報処理装置である。なお、情報処理装置の具体的なハードウェア構成に関しては、実施の形態に応じて適宜構成要素の省略や置換、追加が行われてよい。
【００２０】
ＣＰＵ１１は、中央処理装置であり、ＲＡＭ１２およびＲＯＭ１３等に展開された命令及びデータを処理することで、ＲＡＭ１２、補助記憶装置１９等の、イベント制御モジュール１に備えられた各構成を制御する。また、ＲＡＭ１２は、主記憶装置であり、ＣＰＵ１１によって制御され、各種命令やデータが書き込まれ、読み出される。即ち、ＣＰＵ１１、ＲＡＭ１２、およびＲＯＭ１３は、イベント制御モジュール１の制御部を構成する。
【００２１】
補助記憶装置１９は、不揮発性の記憶装置であり、主にイベント制御モジュール１の電源を落としても保持したい情報、例えば、ＲＡＭ１２にロードされるイベント制御モジュール１のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や、後述する処理を実行するための各種プログラムの他、イベント制御モジュール１によって使用される各種データが書き込まれ、読み出される。補助記憶装置１９としては、例えば、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）やＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等を用いることが出来る。
【００２２】
なお、ストレージ２、ＳＮＳ３、イベント登録端末４およびユーザ端末５は、イベント制御モジュール１と同じく、一般的なコンピュータとしての構成であるＣＰＵ、ＲＡＭ、ＲＯＭ、補助記憶装置、ネットワークインターフェース等を備えるコンピュータシステムである（図示は省略する）。
【００２３】
また、イベント制御モジュール１、ストレージ２、およびＳＮＳ３等の各種サーバは、ネットワーク上にクラウドサービスとして実装されてもよい。この場合、各サーバによる処理の主体は、ネットワーク上に分散した複数のマシンとなるが、本実施形態では、サーバとしての機能を果たすための複数のマシンをまとめて「サーバ」と称する。
【００２４】
ユーザ端末５は、上記説明した一般的なコンピュータとしての構成に加えて、当該ユーザ端末５の現在位置を示す位置情報８ｂを取得するための構成を更に備える。位置情報８ｂを取得するための構成としては、例えば、ＧＰＳによってユーザ端末５の位置情報８ｂを取得するモジュール、または、通信可能な無線ＬＡＮ（Ｗｉ−Ｆｉ）アクセスポイントの位置情報８ｂから、ユーザ端末５の位置情報８ｂを取得するモジュールが採用されてもよい。無線ＬＡＮアクセスポイントの位置情報８ｂを用いる手段によれば、緯度経度に加えて、建物内の階数等、より詳細な位置情報８ｂを得ることも可能である。更に、位置情報８ｂを取得するための構成には、その他の手段が採用されてもよいし、ＧＰＳを用いる手段および無線ＬＡＮアクセスポイントの位置情報８ｂを用いる手段を含む様々な手段から、複数の手段が組み合わされて用いられてもよい。
【００２５】
次に、本システムを構成する各端末が備える機能について説明する。図３Ａから図３Ｃは、本実施形態に係るシステムの機能構成の概略を示す図である。
【００２６】
図３Ａは、本実施形態に係るイベント登録端末４の機能構成の概略を示す図である。イベント登録端末４は、システムにイベント情報９を登録するための端末であり、イベント発生条件９３、イベント内容格納先情報９２およびイベント内容９１を含むイベント情報９を生成するイベント生成部４１と、生成されたイベント情報９をイベント制御モジュール１やストレージ２等に登録するイベント登録部４２と、を備える。より具体的には、イベント登録部４２は、イベント発生条件９３およびイベント内容格納先情報９２をイベント制御モジュール１に登録し、イベント内容９１を、イベント内容格納先情報９２に示されたストレージ２に格納させる。例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、携帯電話、スマートフォン、タブレット端末、携帯ゲーム機等を、イベント登録端末４として用いることが出来る。
【００２７】
ストレージ２は、イベント内容９１を受け取り、格納するイベント内容格納部を備える（図示は省略する）。例えば、クラウドストレージ、サーバ等を、ストレージ２として用いることが出来る。
【００２８】
図３Ｂは、本実施形態に係るユーザ端末５の機能構成の概略を示す図である。ユーザ端末５は、ユーザがイベント情報９を受け取るための端末であり、ユーザの情報を取得し、イベント制御モジュール１へ送信するユーザ情報取得機能、およびイベントを発生させるイベント発生機能を備える。より具体的には、ユーザ端末５は、ＳＮＳ３上のユーザに係る情報を取得するＳＮＳ情報取得部５１と、ユーザ端末５の現在位置の位置情報８ｂを取得する位置情報取得部５２と、認証情報８ｅを取得する認証情報取得部５３と、取得した情報をイベント制御モジュール１へ送信するユーザ情報送信部５４と、ストレージ２からイベント内容９１を受け取るイベント内容受取部５５と、イベント制御モジュール１からイベント発生トリガを受け取るイベント発生トリガ受取部５６と、イベント発生トリガを受けて、イベント内容９１に従ったイベントを実行するイベント実行部５７と、を備える。このうち、ＳＮＳ情報取得部５１、位置情報取得部５２、認証情報取得部５３およびユ
ーザ情報送信部５４によってユーザ情報取得機能が実現され、イベント内容受取部５５、イベント発生トリガ受取部５６およびイベント実行部５７によってイベント発生機能が実現される（図３Ｂを参照）。例えば、ＰＣ、携帯電話、スマートフォン、タブレット端末、携帯ゲーム機等を、ユーザ端末５として用いることが出来る。
【００２９】
なお、イベントの発生主体はユーザ端末５でなくてもよい。ユーザ端末５以外においてイベントを発生させる場合の構成および処理については、後述する。また、ユーザ端末５をイベント登録端末４としても用いる場合、ユーザ端末５は、上記説明したユーザ端末５の機能と、イベント登録端末４の機能とを兼ね備える。
【００３０】
図３Ｃは、本実施形態に係るイベント制御モジュール１の機能構成の概略を示す図である。イベント制御モジュール１は、イベント登録機能、ユーザ情報受取機能、イベント発生条件判定機能およびイベント発生機能を有し、イベント発生条件９３およびユーザ情報８から、各ユーザがイベント発生条件９３を満たすか否かを判定する。より具体的には、本実施形態に係るイベント制御モジュール１は、ＣＰＵ１１が、ＲＡＭ１２に展開された各種プログラムを解釈および実行することで、イベント発生条件受取部２１と、ユーザ情報受取部２２と、時刻取得部２３と、イベント発生条件判定部２４と、イベント発生トリガ送信部２５と、イベント内容格納先情報送信部２６と、を備える情報処理装置として機能する（図３Ｃを参照）。また、本実施形態では、これらの機能がいずれも汎用のＣＰＵ１１によって実行される例について説明しているが、これらの機能は、その一部または全部が、１または複数の専用のプロセッサによって実現されてもよい。なお、イベント制御モジュール１は、例えば、クラウド上、サーバ上、ユーザ端末５上等に実装されてよい。
【００３１】
イベント発生条件受取部２１は、イベント発生条件９３およびイベント内容格納先情報９２を、イベント登録端末４から受け取る。
【００３２】
ユーザ情報受取部２２は、ユーザ端末５からユーザ情報８を受け取る。ここで、ユーザ情報８には、ユーザ属性８ａ、ユーザの現在位置を示す位置情報８ｂ、ユーザが属する所定のユーザ集合の状態（以下、「集合状態」と称する）８ｃ、現在時刻８ｄおよびユーザの認証情報８ｅの少なくとも何れかを含む。なお、集合状態８ｃは、例えば、他のユーザを含むユーザの集合において、ユーザ属性８ａまたは位置情報８ｂが所定の条件を満たすユーザの数や、所定のユーザの位置情報８ｂが所定の条件を満たしているか否か、等を示す情報であり、他のユーザのユーザ属性８ａや位置情報８ｂ等に基づいて得ることが出来る。
【００３３】
時刻取得部２３は、現在時刻８ｄを取得する。なお、現在時刻８ｄは、ユーザ端末５によって取得させ、イベント制御モジュール１に対して送信させることとしてもよいが、本実施形態では、イベント制御モジュール１の時刻取得部２３によって取得した現在時刻８ｄを、ユーザ情報８として用いることとしている。これによって、ユーザがユーザ端末５の時刻設定を変更する等して不正にイベントを発生させることを防止することが出来る。
【００３４】
イベント発生条件判定部２４は、イベント発生条件９３およびユーザ情報８に基づいて各ユーザがイベント発生条件９３を満たすか否かを判定する。より具体的には、イベント発生条件判定部２４は、ユーザ情報８に含まれるユーザ属性８ａ、位置情報８ｂ、集合状態８ｃ、現在時刻８ｄおよび認証情報８ｅが、イベントに関連付けられたイベント発生条件９３に含まれる属性条件９３ａ、場所条件９３ｂ、集合状態条件９３ｃ、時間条件９３ｄおよび認証条件９３ｅを満たすか否かを判定する。ここで、各条件には、ユーザ毎またはユーザの組み合わせ毎に異なるものが設定されてもよい。例えば、場所条件９３ｂには、ユーザ毎またはユーザの組み合わせ毎に異なる場所を設定することが出来る。
【００３５】
図４は、本実施形態において用いられるイベント発生条件９３の構成を示す図である。図４に示されたイベント発生条件９３には、属性条件９３ａ、場所条件９３ｂおよび集合状態条件９３ｃが設定されている。また、イベント発生条件９３には、更に、時間条件９３ｄおよび認証条件９３ｅが設定されてもよい。
【００３６】
ここで、属性条件９３ａとは、イベントを発生させたいユーザまたはユーザ端末５の属性を判定するための条件であり、例えば、ユーザのＳＮＳ３参加状態が判定される。より具体的には、ユーザが所属するＳＮＳ３上のグループ・コミュニティ等の参加状態や、ユーザがＳＮＳ３上のプロフィールで表明している趣味や趣向等のステイタス等が判定される。ここで、グループの例としては、所属会社、所属部門、所属サークル、在籍または卒業した学校、等が挙げられ、ステイタスの例としては、出身地、居住地、在籍または卒業した学校、勤務先、趣味、等が挙げられる。
【００３７】
場所条件９３ｂとは、イベントを発生させたい場所を判定するための条件であり、グループ単位・個人単位で設定可能である。場所条件９３ｂは、例えば、緯度経度の範囲指定によって設定されてもよいし、地図上にマッピングされたエリアを指定することによって設定されてもよい。場所条件９３ｂを緯度経度の範囲指定によって設定する場合、例えば、中心点の緯度経度と中心点からの距離とを用いて円形の範囲を指定することによって設定することが出来る。場所条件９３ｂの設定方法は実施の形態に応じて適宜選択可能であり、本開示において説明した方法に限定されない。また、場所条件９３ｂには、複数地点が設定されてもよいし、固定位置以外が設定されてもよい。
【００３８】
集合状態条件９３ｃとは、イベントを発生させたいユーザ端末５の集合状態８ｃを判定するための条件であり、例えば、場所条件９３ｂを満たしているユーザの数（「場所条件を満たしたユーザがｎ人以上」等）、場所条件９３ｂを満たさなければならない特定ユーザの存在（キーパーソン）、ユーザが更に満たさなければならない絞り込み条件、等が設定されてよい。
【００３９】
また、時間条件９３ｄとは、現在時刻８ｄが、イベントが発生する時間であるか否かを判定するための条件であり、例えば、特定の月日・時刻・曜日・期間等によって設定可能である。
【００４０】
認証条件９３ｅとは、ユーザ端末５のユーザを認証したい場合に利用される条件であり、主にセキュリティ強化や、ユーザまたはキーパーソンの本人確認に利用される。認証に用いられる具体的な手法としては、一般的なユーザ識別子（社員番号等）とパスワードを用いた認証の他、合言葉・パスワード・会員番号等を音声で入力して行う音声認証、合言葉・パスワード・会員番号等を文字で入力して行う文字認証、ユーザのポーズや動き等を入力装置において検出して行うジェスチャー認証、会員証・ＱＲコード・バーコード・景色を撮影し解析して行う画像・帳票認証、音声による話者認証・顔認証・指紋、掌紋認証・虹彩、網膜パターン・静脈パターン・筆跡鑑定による生体認証、ニーモニック認証、等が挙げられる。
【００４１】
イベント発生トリガ送信部２５は、イベント発生条件９３を満たすユーザ端末５にイベント発生トリガを送信することで、イベント内容９１に示されたイベントの発生を許可または指示する。即ち、イベント発生トリガ送信部２５は、イベント発生条件９３が満たされたと判定された場合に、イベントの発生を許可または指示する。
【００４２】
イベント内容格納先情報送信部２６は、イベント発生条件９３を満たすユーザ端末５にイベント内容格納先情報９２を送信する。
【００４３】
＜処理の流れ＞
以下、図５から図１７を用いて、本実施形態に係る処理の詳細を説明する。なお、本実施形態において説明される処理の具体的な内容および順序等は、実施する上での一例である。具体的な処理内容および順序等は、実施の形態に応じて適宜選択されてよい。
【００４４】
図５は、本実施形態に係るシステムにおける処理のフェーズを示す図である。本実施形態に係るシステムによって実行される処理は、大きく分けて事前設定フェーズと運用フェーズに分けられる。事前設定フェーズは、イベント情報９の生成およびイベント情報９の登録からなるフェーズであり、イベント登録端末４にてイベント情報９が生成され、生成されたイベント情報９がイベント制御モジュール１およびストレージ２に登録される、いわば準備段階に相当するフェーズである。一方、運用フェーズは、ユーザ情報８の取得、イベント発生要否の判定およびイベントの発生からなるフェーズであり、事前設定フェーズにおいて設定された条件等に基づいて、システムが運用されるフェーズである。
【００４５】
初めに、事前設定フェーズにおける処理について説明する。
【００４６】
図６は、本実施形態に係るイベント生成処理の概要を示す図である。管理者であるユーザは、イベント登録端末４に対して、イベント内容９１、イベント発生条件９３およびイベント内容格納先情報９２を入力する。入力を受けたイベント登録端末４のイベント生成部４１は、ユーザの入力に従って、イベント内容９１、イベント発生条件９３およびイベント内容格納先情報９２を含むイベント情報９を生成する。
【００４７】
図７は、本実施形態において生成されるイベント情報９の例を示す図である。この例において、イベント情報９を作成する管理者は会議主催者であり、情報漏洩の防止の観点から、事前のメールによる資料配布や印刷物の配布を行うことなく、機密資料の情報を、会議中にのみ会議参加者と共有したいと考えている。また、この会議で閲覧される資料は、所属部の管理職の承認が必要な資料であることとする。
【００４８】
上記のような要求を満たすイベント情報９を作成するため、管理者は、イベント登録端末４に対して、イベント内容９１として「機密資料の閲覧（機密資料が格納されたストレージ２へのアクセス許可、および機密資料の暗号解除）」を、イベント発生条件９３のうち場所条件９３ｂとして「東京本社（営業グループ・企画グループ対象）」および「大阪支店（開発グループ対象）」を、イベント発生条件９３のうち属性条件９３ａとして「営業グループ ＯＲ 企画グループ ＯＲ 開発グループ」を、集合状態条件９３ｃとして「各場所において当該ユーザの管理職が同行していること」を、時間条件９３ｄとして「会議中の時間帯（８月１７日 １３：００−１８：００）」を、認証条件９３ｅとして「社員番号とパスワードの入力」を、入力する。イベント内容格納先情報９２には、例えば、「○○クラウドストレージの△△フォルダ」等のように、会議の開催地からアクセス可能なストレージ２が適宜設定される。入力を受けたイベント登録端末４のイベント生成部４１は、上記入力内容に従って、イベント内容９１、イベント発生条件９３およびイベント内容格納先情報９２を含むイベント情報９を生成する（図７を参照）。イベント情報９の生成が完了すると、その後、処理はイベント登録処理に進む。
【００４９】
図８は、本実施形態に係るイベント登録処理の概要を示す図である。イベント情報９が生成されると、イベント登録端末４のイベント登録部４２は、生成されたイベント情報９を登録する。具体的には、イベント登録端末４のイベント登録部４２は、イベント発生条件９３およびイベント内容格納先情報９２をイベント制御モジュール１に対して送信し、イベント内容９１を、イベント内容格納先情報９２に示されているストレージ２に対して送信する。イベント発生条件９３およびイベント内容格納先情報９２を受信したイベント制御モジュール１のイベント発生条件受取部２１は、補助記憶装置１９にイベント発生条
件９３およびイベント内容格納先情報９２を登録する。また、イベント内容９１を受信したストレージ２は、イベント内容９１を格納する。
【００５０】
次に、運用フェーズにおける処理について説明する。
【００５１】
図９は、本実施形態に係るユーザ情報取得処理の概要を示す図である。図９に示された処理は、イベント情報９が登録されると、定期的に実行される。ユーザ端末５は、ユーザ情報８を取得し、イベント制御モジュール１へ送信する。ユーザ情報８には、ユーザ属性８ａ、位置情報８ｂおよび認証情報８ｅ等が含まれる。
【００５２】
図１０は、本実施形態においてユーザ端末５のＳＮＳ情報取得部５１によって取得される、ユーザ属性８ａの例を示す図である。図１０に示す例では、ユーザ端末５のＳＮＳ情報取得部５１は、ＳＮＳ３のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）から、ユーザＡ〜Ｆのユーザ属性８ａとして、会社においてユーザの所属するグループ、およびユーザのステイタス（役職等）等を取得する。
【００５３】
図１１は、本実施形態において複数のユーザ端末５によってユーザ情報８が取得され、イベント制御モジュール１に対して送信される様子を例示する図である。ユーザ端末５のＳＮＳ情報取得部５１は、ＳＮＳ３のＡＰＩを呼び出す等の方法で、インターネットを介して、ユーザ属性８ａを取得し、位置情報取得部５２は、位置情報取得用のＡＰＩ等を介して、ＧＰＳ等を用いて得られたユーザ端末５の位置情報８ｂを取得する。また、ユーザ端末５の認証情報取得部５３は、認証情報ＡＰＩ等を介して、ユーザによって入力された社員番号（従業員番号）とパスワードとの組み合わせを認証サーバに送信する。社員番号とパスワードとの組み合わせを受信した認証サーバは、社員番号とパスワードとの組み合わせが、判定対象となっているユーザ端末５のユーザの社員番号およびパスワードと一致するか否かを判定する。なお、ユーザ毎の社員番号とパスワードとの組み合わせは、認証サーバによって予め保持されている。認証サーバは、ユーザの認証（本人確認）が完了すると、本人確認結果として、ユーザ端末５に対して認証情報８ｅを送信する。
【００５４】
ユーザ属性８ａ、位置情報８ｂおよび認証情報８ｅ等のユーザ情報８が取得されると、ユーザ端末５のユーザ情報送信部５４は、取得されたユーザ情報８を、イベント制御モジュール１に対して送信する。そして、イベント制御モジュール１のユーザ情報受取部２２は、ユーザ端末５より送信されたユーザ情報８を受信する。また、イベント制御モジュール１の時刻取得部２３は、現在時刻８ｄを取得し、取得された時刻を、ユーザ情報８が取得された時刻として、ユーザ情報８に組み込む。
【００５５】
図１２は、本実施形態においてイベント制御モジュール１によって取得された、ユーザ情報８の例を示す図である。ユーザ情報８が取得されると、処理はイベント発生判定処理に進む。
【００５６】
図１３は、本実施形態に係るイベント発生判定処理の概要を示す図である。イベント発生判定処理では、ユーザ情報８とイベント発生条件９３の判定が行われ、条件を満たすユーザ端末５に、イベント発生トリガとイベント内容格納先情報９２が送信される。以下、イベント発生判定処理の詳細を説明する。
【００５７】
イベント発生条件判定部２４は、事前設定フェーズのイベント登録処理において予め登録されていたイベント発生条件９３を、補助記憶装置１９から読み出し、ユーザ情報取得処理において取得されたユーザ情報８と比較することで、イベント発生条件判定を行う。
【００５８】
図１４は、本実施形態に係るイベント発生条件判定処理の流れを示すフローチャートで
ある。本フローチャートに示された処理は、ユーザ情報受取部２２によってユーザ情報８が取得されたことを契機として実行される。
【００５９】
ステップＳ１０１では、ユーザ端末５の使用ユーザの属性が属性条件９３ａを満たしているか否かが判定される。イベント発生条件判定部２４は、取得されたユーザ情報８に含まれるユーザ属性８ａが、イベント発生条件９３に設定されている属性条件９３ａを満たしているか否かを判定する。即ち、ステップＳ１０１では、ユーザ端末を使用するユーザ自身が所定の属性を有しているか否かの判定が行われる。
【００６０】
図７に示されたイベント情報９の例では、属性条件９３ａとして「営業グループ ＯＲ
企画グループ ＯＲ 開発グループ」が設定されている。このため、イベント発生条件判定部２４は、ユーザ属性８ａが営業グループ、企画グループおよび開発グループの少なくとも何れかに該当するか否かを判定する。図１２に示した例では、ユーザＡ〜Ｅは属性条件９３ａを満たすが、ユーザＦは事務グループ所属であり、属性条件９３ａを満たさない。
【００６１】
ユーザの属性が属性条件９３ａを満たしていないと判定された場合、処理はステップＳ１０７へ進む。一方、ユーザの属性が属性条件９３ａを満たしていると判定された場合、処理はステップＳ１０２へ進む。
【００６２】
ステップＳ１０２では、ユーザ端末５の現在位置が場所条件９３ｂを満たしているか否かが判定される。イベント発生条件判定部２４は、取得されたユーザ情報８に含まれる位置情報８ｂが示す現在位置が、イベント発生条件９３に設定されている場所条件９３ｂを満たしているか否かを判定する。例えば、位置情報８ｂが緯度経度で示される場合、イベント発生条件判定部２４は、位置情報８ｂが示す緯度経度が、場所条件９３ｂに示された緯度経度の範囲内であるか否かを判定することで、ユーザ情報８に含まれる位置情報８ｂが示す現在位置が場所条件９３ｂを満たしているか否かを判定する。
【００６３】
図７に示されたイベント情報９の例では、場所条件９３ｂとして「東京本社（営業グループ・企画グループ対象）」および「大阪支店（開発グループ対象）」が設定されている。このため、イベント発生条件判定部２４は、営業グループ・企画グループに属するユーザ（図１２に示した例では、ユーザＡ、Ｂ、およびＥ）については、位置情報８ｂが示す現在位置が東京本社の範囲内であるか否かを判定し、開発グループに属するユーザ（図１２に示した例では、ユーザＣおよびＤ）については、位置情報８ｂが示す現在位置が大阪支店の範囲内であるか否かを判定する。図１２に示した例では、ユーザＡ〜Ｃ、ＥおよびＦは場所条件９３ｂを満たすが、ユーザＤの位置情報８ｂはユーザＤの現在地が富士山であることを示しており、場所条件９３ｂを満たさない。
【００６４】
ユーザ端末５の位置情報８ｂが場所条件９３ｂを満たしていないと判定された場合、処理はステップＳ１０７へ進む。一方、ユーザ端末５の位置情報８ｂが場所条件９３ｂを満たしていると判定された場合、処理はステップＳ１０３へ進む。
【００６５】
ステップＳ１０３では、ユーザ端末５の集合の状態が集合状態条件９３ｃを満たしているか否かが判定される。イベント発生条件判定部２４は、他のユーザ端末５を含む所定のユーザ端末５の集合の状態（集合状態）が、イベント発生条件９３に設定されている集合状態条件９３ｃを満たしているか否かを判定する。集合状態条件９３ｃとしては、例えば、場所条件９３ｂを満たしているユーザの数（「場所条件を満たしたユーザがｎ人以上」等）、特定ユーザが場所条件９３ｂを満たしていること（キーパーソンが所定場所に居ること）、ユーザが更に満たさなければならない絞り込み条件、等が判定されてよい。
【００６６】
集合状態条件９３ｃを用いた判定に用いる集合状態８ｃの情報は、図１２に示した、イベント制御モジュール１によって蓄積されている他のユーザ端末５のユーザ情報８を含むユーザ情報の集合を参照し、集合状態条件に応じた分析処理を行うことで、集合状態を取得することが出来る。例えば、集合状態条件９３ｃが「属性条件を満たしたユーザのうち、場所条件を満たしたユーザがｎ人以上」である場合、イベント発生条件判定部２４は、属性条件を満たした他のユーザ端末５のユーザ情報８を含むユーザ情報の集合を参照し、場所条件を満たしたユーザの数をカウントすることで、集合状態を取得することが出来る。また、例えば、集合状態条件９３ｃが「特定ユーザが場所条件９３ｂを満たしていること」である場合、イベント発生条件判定部２４は、他のユーザ端末５のユーザ情報８を含むユーザ情報の集合を参照し、特定ユーザが場所条件９３ｂを満たしているか否かを判定することで、集合状態を取得することが出来る。
【００６７】
図７に示されたイベント情報９の例では、集合状態条件９３ｃとして「各場所において当該ユーザの管理職が同行していること」が設定されている。このため、イベント発生条件判定部２４は、営業グループ・企画グループに属するユーザ（図１２に示した例では、ユーザＡ、Ｂ、およびＥ）については、東京本社の範囲内に管理職であるユーザが居るか否かを判定し、開発グループに属するユーザ（図１２に示した例では、ユーザＣおよびＤ）については、大阪支店の範囲内に管理職であるユーザがいるか否かを判定する。図１２に示した例では、ユーザＡおよびＢについては、営業グループの管理職（部長）であるユーザＡが東京本社にいるため集合状態条件９３ｃを満たし、ユーザＣおよびＤについては、開発グループの管理職（部長）であるユーザＣが大阪支店にいるため集合状態条件９３ｃを満たすが、ユーザＥについては、企画グループの管理職が東京本社に居ないため、集合状態条件９３ｃを満たさない。
【００６８】
ユーザ端末５の集合の状態が集合状態条件９３ｃを満たしていないと判定された場合、処理はステップＳ１０７へ進む。一方、ユーザ端末５の集合の状態が集合状態条件９３ｃを満たしていると判定された場合、処理はステップＳ１０４へ進む。
【００６９】
ステップＳ１０４では、現在時刻８ｄが時間条件９３ｄを満たしているか否かが判定される。イベント発生条件判定部２４は、取得されたユーザ情報８に含まれる現在時刻８ｄが、イベント発生条件９３に設定されている時間条件９３ｄを満たしているか否かを判定する。より具体的には、イベント発生条件判定部２４は、現在時刻８ｄが、時間条件９３ｄに示された開始時刻以降であり且つ終了時刻以前であるか否かを判定することで、現在時刻８ｄが時間条件９３ｄを満たしているか否かを判定する。但し、時間条件９３ｄには、開始時刻および終了時刻の何れか一方のみが設定されていてもよい。
【００７０】
図７に示されたイベント情報９の例では、時間条件９３ｄとして「会議中の時間帯（８月１７日 １３：００−１８：００）」が設定されている。このため、イベント発生条件判定部２４は、現在時刻８ｄが８月１７日の１３：００以降且つ１８：００以前であるか否かを判定する。図１２に示した例では、イベント発生条件判定処理は会議中の時間帯に実行されており、ユーザＡ〜Ｆは何れも時間条件９３ｄを満たす。
【００７１】
現在時刻８ｄが時間条件９３ｄを満たしていないと判定された場合、処理はステップＳ１０７へ進む。一方、現在時刻８ｄが時間条件９３ｄを満たしていると判定された場合、処理はステップＳ１０５へ進む。
【００７２】
ステップＳ１０５では、ユーザ端末５の認証情報８ｅが認証条件９３ｅを満たしているか否かが判定される。イベント発生条件判定部２４は、取得されたユーザ情報８に含まれる認証情報８ｅが、イベント発生条件９３に設定されている認証条件９３ｅを満たしているか否かを判定する。
【００７３】
図７に示されたイベント情報９の例では、認証条件９３ｅとして「社員番号とパスワードの入力」が設定されている。このため、イベント発生条件判定部２４は、ユーザ情報８に、社員番号とパスワードが入力されて認証サーバによる本人確認が為されたことを示す認証情報８ｅが含まれているか否かを参照することで判定する。図１２に示した例では、ユーザＡ〜Ｆは何れも認証条件９３ｅを満たす。なお、本実施形態では、ユーザ情報８に認証情報８ｅとして認証サーバによる本人確認結果が含まれ、これを参照して判定を行うこととしているが、このような方法に代えて、ユーザ情報８に社員番号とパスワードが含まれ、イベント制御モジュール１によって社員番号とパスワードの正当性が判定されることで、認証条件９３ｅが満たされているか否かを判定することとしてもよい。
【００７４】
認証情報８ｅが認証条件９３ｅを満たしていないと判定された場合、処理はステップＳ１０７へ進む。一方、認証情報８ｅが認証条件９３ｅを満たしていると判定された場合、処理はステップＳ１０６へ進む。
【００７５】
ステップＳ１０６では、イベント発生トリガが送信される。イベント発生トリガ送信部２５は、ステップＳ１０１からステップＳ１０５までの全ての判定において条件が満たされていた場合、イベント発生条件９３が満たされたと判断して、ユーザ端末５に対してイベント発生トリガを送信する。
【００７６】
図１５は、本実施形態に係るイベント発生条件判定結果の例を示す図である。図１５に示された例では、ユーザＡ〜Ｃについては、イベント発生条件９３が満たされているため、イベント発生トリガ送信部２５によってイベント発生トリガが送信される。一方、ユーザＤ〜Ｆについては、イベント発生条件９３が満たされていないため、イベント発生トリガは送信されない。その後、本フローチャートに示された処理は終了し、処理はイベント発生処理へ進む。
【００７７】
ステップＳ１０７では、エラーメッセージが出力される。イベント制御モジュール１は、ステップＳ１０１からステップＳ１０５までの何れかの判定において条件が満たされなかった場合、イベント発生条件９３が満たされなかったと判断して、ユーザ端末５に対してエラーメッセージを送信する。図１５に示された例では、ユーザＤ〜Ｆについては、イベント発生条件９３が満たされていないため、エラーメッセージが送信される。その後、本フローチャートに示された処理は終了する。
【００７８】
但し、ステップＳ１０７におけるエラーメッセージの送信は行われなくてもよい。例えば、定期的にイベント発生条件判定処理を実行し、イベント発生条件９３が満たされた時点で自動的に発生するようなイベント等、エラーメッセージを出力することが好ましくないイベントについては、エラーメッセージは送信されなくてもよい。一方、ユーザによるイベントのリクエストを受けてイベント発生条件判定処理を実行するようなイベント等、ユーザにイベントが発生しないことを通知することが好ましいイベントについては、エラーメッセージが送信されてよい。
【００７９】
再び図１３を参照し、図１４のフローチャートに示されたイベント発生条件判定処理においてイベント発生条件９３が満たされたと判定された場合の処理の流れを説明する。上述の通り（図１４のステップＳ１０６を参照）、イベント発生トリガ送信部２５は、イベント発生条件９３が満たされた場合、ユーザ端末５に対してイベント発生トリガを送信する。送信されたイベント発生トリガは、ユーザ端末５のイベント発生トリガ受取部５６によって受信される。
【００８０】
また、イベント制御モジュール１のイベント内容格納先情報送信部２６は、補助記憶装
置１９から、満たされたイベント発生条件９３に対応するイベント内容格納先情報９２を読み出し、ユーザ端末５に対して送信する。ユーザ端末５のイベント内容受取部５５は、イベント内容格納先情報９２を受信すると、このイベント内容格納先情報９２を参照して、イベント内容格納先情報９２に示されたストレージ２にアクセスし、当該ストレージ２から、満たされたイベント発生条件９３に対応するイベント内容９１を取得する。その後、処理はイベント発生処理に進む。
【００８１】
なお、本実施形態では、イベント内容格納先情報９２およびイベント内容９１は、イベント発生条件９３を満たした場合に、ユーザ端末５によって取得されるが、イベント内容格納先情報９２およびイベント内容９１は、ユーザ端末５によって予め（イベント発生条件９３が満たされる前に）取得されていてもよい。このようにすることで、イベント発生条件９３を満たした場合に、イベント発生トリガを発行するのみで、イベントを発生させることが出来る。
【００８２】
図１６は、本実施形態に係るイベント発生処理の概要を示す図である。ユーザ端末５のイベント実行部５７は、イベント発生トリガ受取部５６によってイベント発生トリガが受信されると、イベント内容９１に従ってイベントを発生させる。先述の通り、イベントの発生とは、所定のイベント用ソフトウェアの実行であってもよいし、所定の機能に対する指示（コマンド）の発行であってもよい。
【００８３】
図１７は、本実施形態におけるユーザ端末５毎のイベント発生状況の例を示す図である。図１５に示した例では、ユーザＡ・Ｂ・Ｃはすべてのイベント発生条件９３を満たしているため、それぞれの端末でイベント発生トリガおよびイベント内容格納先情報９２を受け取り、イベント内容９１「機密文書の閲覧」を取得し、イベントを発生させることが出来る（図１７を参照）。これに対して、ユーザＤは場所条件９３ｂを満たしていないため、ユーザＥは集合条件状態を満たしていないため、ユーザＦは属性条件９３ａを満たしていないため、イベント発生トリガおよびイベント内容格納先情報９２を受け取ることができず、イベント内容９１を取得することができない（図１７を参照）。また、ユーザＤ〜Ｆは、後日、イベント内容９１を受け取ろうとしても、時間条件９３ｄを満たすことが出来ないため、イベント発生トリガおよびイベント内容格納先情報９２を受け取ることができず、イベント内容９１を取得することができない。
【００８４】
また、イベント内容９１またはイベント内容格納先情報９２を暗号化しておき、イベント発生トリガ送信部２５は、暗号化されたイベント内容９１またはイベント内容格納先情報９２を復号するための復号鍵としてのイベント発生トリガを発行することで、イベントの発生を許可または指示することとしてもよい。このようにすることで、イベント発生条件９３が満たされていない状態でユーザ端末５がイベントを発生させようとしても、イベント内容９１またはイベント内容格納先情報９２を復号することが出来ない。即ち、このような仕組みによれば、ユーザによってイベントが不正に発生させられることを防止することが出来る。
【００８５】
＜バリエーション＞
次に、本開示に係るシステムを実施する場合の実施形態のバリエーションを説明する。
【００８６】
上記説明した実施形態では、イベント情報９に含まれる情報のうち、イベント発生条件９３およびイベント内容格納先情報９２は、イベント登録端末４からイベント制御モジュール１へ登録され、イベント内容９１は、イベント登録端末４から直接ストレージ２に格納される例について説明したが、イベント情報９の登録ルートは様々であってよい。
【００８７】
図１８は、イベント登録のバリエーションを示す図である。また、図１９は、図１８に
示されたバリエーションにおける、イベント制御モジュール１の機能構成の概略を示す図である。図１８に示した例では、イベント情報９に含まれるイベント内容９１、イベント発生条件９３およびイベント内容格納先情報９２は、イベント登録端末４からイベント制御モジュール１へ一旦送信される。そして、イベント制御モジュール１は、このうちイベント発生条件９３およびイベント内容格納先情報９２を登録し、イベント内容９１をストレージ２に転送してストレージ２に格納する。このため、本バリエーションに係るイベント制御モジュール１は、図３Ｃを用いて上述した機能に加えて、イベント内容経由部２７によるイベント内容経由機能を更に備える（図１９を参照）。
【００８８】
また、上記説明した実施形態では、イベント発生条件９３が満たされた場合のイベント発生の仕組みとして、イベント発生トリガおよびイベント内容格納先情報９２が、イベント制御モジュール１によってユーザ端末５宛に送信され、これを受信したユーザ端末５が、イベント内容格納先情報９２を参照して、ストレージ２にイベント内容９１を取りに行き、ユーザ端末５においてイベントを発生させる仕組みが採用されているが、このような仕組みに代えて、他のイベント発生の仕組みが採用されてもよい。
【００８９】
図２０は、ストレージ２においてイベントを発生させる場合のイベント発生の仕組みを示す図である。また、図２１は、図２０に示されたバリエーションにおける、イベント制御モジュール１の機能構成の概略を示す図である。図２０に示された例では、イベント発生条件９３が満たされると、はじめに、イベント制御モジュール１が、イベント内容格納先情報９２を参照して、ストレージ２へイベント発生トリガを送信する。そして、ストレージ２内でイベント発生トリガとイベント内容９１が揃うことで、イベントが発生する。このため、本バリエーションに係るイベント制御モジュール１は、図３Ｃを用いて上述したイベント内容格納先情報送信部２６を備えなくてもよい。また、イベント制御モジュール１のイベント発生トリガ送信部２５は、ストレージ２に対してイベント発生トリガを送信する（図２１を参照）。
【００９０】
図２２は、ユーザ端末５においてイベントを発生させる場合のイベント発生の仕組みを示す図である。また、図２３は、図２２に示されたバリエーションにおける、イベント制御モジュール１の機能構成の概略を示す図である。図２２に示された例では、イベント発生条件９３が満たされると、はじめに、イベント制御モジュール１が、イベント内容格納先情報９２を参照して、ストレージ２にイベント内容９１を取りに行く。そして、イベント制御モジュール１が、イベント内容９１とイベント発生トリガをユーザ端末５に送信することで、ユーザ端末５においてイベント発生トリガとイベント内容９１が揃い、イベントが発生する。このため、本バリエーションに係るイベント制御モジュール１は、図３Ｃを用いて上述したイベント発生トリガ送信部２５およびイベント内容格納先情報送信部２６に代えて、イベント内容格納先情報９２を参照してストレージ２からイベント内容９１を取得するイベント内容取得部２８と、イベント内容９１をユーザ端末５に送信するイベント内容送信部２９と、を備える（図２３を参照）。
【００９１】
図２４は、イベント制御モジュール１においてイベントを発生させる場合のイベント発生の仕組みを示す図である。また、図２５は、図２４に示されたバリエーションにおける、イベント制御モジュール１の機能構成の概略を示す図である。図２４に示された例では、イベント発生条件９３が満たされると、はじめに、イベント制御モジュール１が、イベント内容格納先情報９２を参照して、ストレージ２にイベント内容９１を取りに行く。そして、イベント制御モジュール１内でイベント発生トリガとイベント内容９１が揃うことで、イベントが発生する。このため、本バリエーションに係るイベント制御モジュール１は、図３Ｃを用いて上述したイベント発生トリガ送信部２５およびイベント内容格納先情報送信部２６に代えて、イベント内容格納先情報９２を参照してストレージ２からイベント内容９１を取得するイベント内容取得部２８と、イベント発生トリガとイベント内容９
１とが揃った場合にイベントを発生させるイベント実行部３０と、を備える（図２５を参照）。
【００９２】
＜システムの使用例＞
次に、本開示を適用可能なシステムの具体例を説明する。
【００９３】
（ゲームシステム）
図２６は、本実施形態に係るシステムを、複数ユーザが、夫々のユーザ端末５を用いてネットワークを介して相互に接続し、同時にプレイするゲームシステムに適用する例を示す図である。本実施例では、ユーザ端末５は、上記説明した機能の他、ゲーム機能を備える。このゲームは、例えば、複数のユーザが協力してモンスターを倒し、ゲーム中で用いることのできる特典やアイテムを入手することを目的とするゲームである。
【００９４】
図２７Ａから図２７Ｄは、本実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報９の例を示す図である。このうち、図２７Ａから図２７Ｃに示した例では、図２６に示されたチームαは、キャンペーン期間（８月）中に、チームの２人以上が、東京タワー、東京スカイツリーまたは秋葉原に居る場合に、イベントを発生させることが出来る。ここで発生させるイベントは、限定モンスターの出現や、ゲーム中の特殊装備の取得、ゲーム中のレアアイテムの取得をするためのくじ引き等である。また、図２７Ｂに示されたイベント情報９によれば、認証条件９３ｅとして、図２７Ａに示されたイベント情報９に係るイベントで出現した限定モンスターを倒していることが設定されている。このようにして、複数のイベントに関連性を持たせることとしてもよい。
【００９５】
このような例によれば、ゲームの提供者は、場所条件９３ｂに設定された観光地等と協力して宣伝効果を高めることが出来、場所条件９３ｂに設定された観光地等は、ゲームを利用して集客することが出来る。また、ユーザも、他のユーザと交流しながらゲームをプレイしたり、特典を得たりすることが出来る。
【００９６】
また、図２７Ｄに示した例では、集合状態条件９３ｃとして「同じグループに属していないプレイヤー（ユーザ）が３人以上集まる」ことが設定されており、また、イベント内容９１は、「３〜４人のグループを自動結成」である。このようにすることで、普段チームを組んでいないユーザ同士が集まって新たなチームを組み、ゲームをプレイすることが出来る。即ち、このようなイベント情報９を設定することで、ユーザが会場（ゲーム会社とコラボレーションした店舗等）に到着すると、自動的にチームが結成され、そのチームでゲームを行うこととなる。自動的に組まれたチームによるプレイの終了後は、このチームを解消してもよいし、そのまま継続してもよい。
【００９７】
（地域社会連携システム）
図２８は、本実施形態に係るシステムを、地域社会連携システムに適用する場合に登録されるイベント情報９の例を示す図である。従来、学校・地域・ＰＴＡ等の地域社会では、子供が通学時に交通事故や犯罪に巻き込まれないよう、対策を取っている。具体的には、通学時間帯に、スクールバスのバス停や横断歩道等に２〜３人の大人が立って、子供達を見守ること等である。この役割は当番制である。
【００９８】
また、警察や学校から、学区内の不審者情報が提供されるが、個人情報保護や関係者の身の安全のため、取り扱いには注意が必要である。多数複製して配布を行うには注意が必要であるため、通常は限定された数の複製を回覧する等するが、会合に参加していないと見ることが出来ない、時間が限られておりゆっくり閲覧できない、紙に印刷されたものであるため、必要な情報を探すのが面倒である、最新の情報を得ることが出来ない、等の問題があった。
【００９９】
そこで、図２８に示すようなイベント情報９を設定し、ユーザ端末５を用いてイベント条件を満たした場合にのみ閲覧させるようにすることで、情報閲覧の利便性を高めることが出来る。
【０１００】
図２９は、図２８に示したイベント情報９をもって本実施形態に係るシステムを運用した場合のイベント発生状況を示す図である。ユーザＡおよびＢが平日８：００以降且つ９：３０以前の通学時間帯に、一緒に学区１の交差点に立っている場合、イベント情報９に示されたイベント発生条件９３が満たされるため、ユーザＡおよびＢは、学区１の不審者情報を閲覧することが出来る。ユーザＣおよびＤも同様に、平日８：００以降且つ９：３０以前の通学時間帯に、一緒に学区２の交差点に立っている場合、イベント情報９に示されたイベント発生条件９３が満たされるため、学区２の不審者情報を閲覧することが出来る。しかし、通学時間帯ではない時間帯では、ユーザＡおよびＢ、またはユーザＣおよびＤが一緒に所定の交差点に立っても、不審者情報を閲覧することは出来ない。
【０１０１】
また、ユーザＥおよびＦは、平日８：００以降且つ９：３０以前の通学時間帯に、一緒に学区２の交差点に立っているが、ユーザＦは「グループ→ＰＴＡ会員グループ」との属性条件９３ａを満たさず、ユーザＥは「ＰＴＡ会員が二人以上いる」との集合状態条件９３ｃを満たさないため、ユーザＥおよびＦは、不審者情報を閲覧出来ない。また、ユーザＧおよびＨは、平日８：００以降且つ９：３０以前の通学時間帯に、一緒の場所に居るが、いずれも、「学区内」との場所条件９３ｂを満たさないため、不審者情報を閲覧出来ない。
【０１０２】
（オリエンテーリングシステム）
図３０は、本実施形態に係るシステムを、オリエンテーリングシステムに適用する場合に登録されるイベント情報９の例を示す図である。従来、オリエンテーリングのチーム活動において、全員で行動せず、各々でポイントを回り、ゴールのみチームで行う等の不正行為をしたチームがあっても、これを運営側が把握するのは難しかった。
【０１０３】
そこで、図３０に示したようなイベント情報９において、「チームメンバが全員そろっている」との集合状態条件９３ｃを設定し、イベント内容９１を「運営者へ、チームのポイント通過状況を通知」とすることで、運営側が不正行為を把握することが可能となる。
【０１０４】
図３１は、図３０に示したイベント情報９をもって本実施形態に係るシステムを運用した場合のイベント発生状況を示す図である。運営者は、チームが指令ポイントを通過すると、チームメンバが全員揃っているチームについて通過状況を受けることが出来る。
【０１０５】
また、イベント内容９１として、更に「ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）タグによる指令の閲覧」が設定されていることで、オリエンテーリングの参加者に、チームが全員揃っていることの特典を与えることが出来る。ＡＲタグは、図３１に示すように、ユーザ端末５のディスプレイにおいて、ユーザ端末５のカメラをもって撮像された画像に重ねて表示される画像であり、オリエンテーリングの進行に必要な情報を提供することが出来る。
【０１０６】
（会議管理システム）
図３２Ａおよび図３２Ｂは、本実施形態に係るシステムを、会議管理システムに適用する場合に登録されるイベント情報９の例を示す図である。この会議が秘密の情報を扱う会議である場合、会議において閲覧される資料のセキュリティを確保することが重要である。
【０１０７】
図３２Ａに示されたイベント情報９に設定されたイベント発生条件９３によれば、会議の時間帯に、役員会グループからの、本人確認済みの参加者全員が会議の開催場所に揃わないと資料を閲覧することが出来ない。但し、図３２Ａに示された場所条件９３ｂ「本部
ＯＲ 支部」のうち「支部」は、図３２Ｂに示されたイベント情報９に係るイベント「新規支部開設」を発生させることで、追加することが出来る。即ち、この実施例によれば、予め設定されていた支部に全員が揃っていなくても、会議の時間帯に、役員会グループに所属する本人確認済みのユーザ２人以上が、新たに支部を開設したい場所に居ることで、その場所を新たに支部とし、続いて図３２Ａに示されたイベントを発生させて、資料を閲覧することが出来る。
【０１０８】
（共有手帳システム）
図３３Ａから図３３Ｃは、本実施形態に係るシステムを、共有手帳システムに適用する場合に登録されるイベント情報９の例を示す図である。なお、共有手帳システムは、複数のユーザ（共有者）に対して共有のオンライン手帳サービスを提供するシステムであり、共有手帳は、例えば、恋人、夫婦、家族、等によって共有することが出来る。
【０１０９】
この実施例によれば、ユーザ属性８ａにおいて共有者（例えば、恋人同士）であるユーザが、図３３Ａのイベント情報９に係るイベントを発生させることで、複数の共有者（恋人であれば、２人）で同時に訪れた場所を、図３３Ｂおよび図３３Ｃに係るイベント条件の場所条件９３ｂとして登録することが出来る。そして、登録された場所で図３３Ｂのイベント情報９に係るイベントを発生させることで、思い出の場所で、写真＋アノテーション、コメント、ＡＲタグ、ＳＮＳ投稿等の「思い出登録」（図３３Ｂのイベント内容９１）をすることが出来る。また、登録された場所を再度複数の共有者で同時に訪れた際に、図３３Ｃのイベント情報９に係るイベントを発生させることで、アラート（通知）をし、以前に来た時に「思い出登録」した写真やＳＮＳ投稿等を見る「思い出再現」（図３３Ｃのイベント内容９１）をすることができる。なお、図３３Ｂのイベント内容９１「思い出登録」は、登録された場所を再度複数の共有者で訪れた際に発生させ、写真＋アノテーション、コメント、ＡＲタグ、ＳＮＳ投稿等の「思い出登録」を追加することができる。
【０１１０】
（情報配信システム）
図３４は、本実施形態に係るシステムを、情報配信システムに適用する場合に登録されるイベント情報９の例を示す図である。
【０１１１】
この実施例では、はじめに、場所条件９３ｂに設定された店舗（レストラン等）を訪れた際に、ユーザに、当該店舗を一緒に訪れた複数のユーザが属するグループを登録させる。ユーザは、ユーザ端末５を用いてグループに所属するユーザのＳＮＳ３における識別情報を指定し、ＳＮＳ３に送信する等の方法で、ＳＮＳ３のグループを作成することが出来る。このようにしておくことで、再度そのグループメンバーのうち２人以上（全員でなくてもよい）でレストラン周辺を訪れた際に、図３４のイベント情報９に係るイベントが発生し、当該グループに向けた、「今日のオススメ情報・クーポン配信」が行われる。
【０１１２】
なお、図３４のイベント情報９では、時間条件９３ｄが複数設定されており、何れの時間条件９３ｄを満たしたかによって、配信されるクーポンが異なる。図１４を用いて説明したイベント発生条件判定処理では、イベントに関連付けられたイベント発生条件９３に含まれる属性条件９３ａ、場所条件９３ｂ、集合状態条件９３ｃ、時間条件９３ｄおよび認証条件９３ｅを満たすか否かが判定されるが、夫々の条件内で複数の分岐が設定され、分岐の結果によって発生するイベントにバリエーションを持たせることとしてもよい。例えば、図３４に示された例では、時間条件９３ｄを満たすか否かのほかに、３つある時間条件９３ｄ（１０：００〜１３：００、１６：００〜２０：００および２１：００〜２２：００）の何れを満たしたかによって、配信されるクーポンの内容が変化する。
【０１１３】
＜効果＞
本実施形態に係るシステムによれば、位置情報を用いてイベントの制御を行うシステムにおいて、安全性を確保しつつ柔軟性を向上させることが可能となる。
【符号の説明】
【０１１４】
１ イベント制御モジュール
２１ イベント発生条件受取部
２２ ユーザ情報受取部
２３ 時刻取得部
２４ イベント発生条件判定部
２５ イベント発生トリガ送信部
２６ イベント内容格納先情報送信部
【特許請求の範囲】
【請求項１】
ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れかを含むユーザ情報を取得するユーザ情報取得手段と、
前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定手段と、
前記判定手段によって、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御手段と、
を備える情報処理装置。
【請求項２】
前記所定のユーザ集合の状態は、他のユーザに係る、前記属性情報および前記位置情報の少なくとも何れかに基づいて得られる状態である、
請求項１に記載の情報処理装置。
【請求項３】
前記所定のユーザ集合の状態は、前記属性情報または前記位置情報が所定の条件を満たすユーザの数、および所定のユーザの前記位置情報が所定の条件を満たすこと、の少なくとも何れかである、
請求項１または２に記載の情報処理装置。
【請求項４】
前記判定手段は、ユーザ毎またはユーザの組み合わせ毎に設定された場所条件をもって、前記位置情報を判定する、
請求項１から３の何れか一項に記載の情報処理装置。
【請求項５】
前記ユーザ情報取得手段は、更に現在時刻およびユーザの認証情報の少なくとも何れかを取得し、
前記判定手段は、前記属性情報、前記位置情報および前記所定のユーザ集合の状態に加えて、前記現在時刻および前記認証情報の少なくとも何れかが前記条件を満たすか否かを判定する、
請求項１から４の何れか一項に記載の情報処理装置。
【請求項６】
前記所定のイベントの内容は暗号化されており、
前記イベント制御手段は、暗号化された前記所定のイベントの内容を復号するための復号鍵を発行することで、前記所定のイベントの発生を許可または指示する、
請求項１から５の何れか一項に記載の情報処理装置。
【請求項７】
コンピュータが、
ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れかを含むユーザ情報を取得するユーザ情報取得ステップと、
前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定ステップと、
前記判定ステップにおいて、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御ステップと、
を実行するイベント制御方法。
【請求項８】
コンピュータを、
ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れかを含むユーザ情報を取得するユーザ情報取得手段と、
前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定手段と、
前記判定手段によって、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御手段と、
として機能させるためのイベント制御用プログラム。
【請求項１】
ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れかを含むユーザ情報を取得するユーザ情報取得手段と、
前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定手段と、
前記判定手段によって、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御手段と、
を備える情報処理装置。
【請求項２】
前記所定のユーザ集合の状態は、他のユーザに係る、前記属性情報および前記位置情報の少なくとも何れかに基づいて得られる状態である、
請求項１に記載の情報処理装置。
【請求項３】
前記所定のユーザ集合の状態は、前記属性情報または前記位置情報が所定の条件を満たすユーザの数、および所定のユーザの前記位置情報が所定の条件を満たすこと、の少なくとも何れかである、
請求項１または２に記載の情報処理装置。
【請求項４】
前記判定手段は、ユーザ毎またはユーザの組み合わせ毎に設定された場所条件をもって、前記位置情報を判定する、
請求項１から３の何れか一項に記載の情報処理装置。
【請求項５】
前記ユーザ情報取得手段は、更に現在時刻およびユーザの認証情報の少なくとも何れかを取得し、
前記判定手段は、前記属性情報、前記位置情報および前記所定のユーザ集合の状態に加えて、前記現在時刻および前記認証情報の少なくとも何れかが前記条件を満たすか否かを判定する、
請求項１から４の何れか一項に記載の情報処理装置。
【請求項６】
前記所定のイベントの内容は暗号化されており、
前記イベント制御手段は、暗号化された前記所定のイベントの内容を復号するための復号鍵を発行することで、前記所定のイベントの発生を許可または指示する、
請求項１から５の何れか一項に記載の情報処理装置。
【請求項７】
コンピュータが、
ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れかを含むユーザ情報を取得するユーザ情報取得ステップと、
前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定ステップと、
前記判定ステップにおいて、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御ステップと、
を実行するイベント制御方法。
【請求項８】
コンピュータを、
ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れかを含むユーザ情報を取得するユーザ情報取得手段と、
前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定手段と、
前記判定手段によって、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御手段と、
として機能させるためのイベント制御用プログラム。
【図１】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７Ａ】
【図２７Ｂ】
【図２７Ｃ】
【図２７Ｄ】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２Ａ】
【図３２Ｂ】
【図３３Ａ】
【図３３Ｂ】
【図３３Ｃ】
【図３４】
【図２】
【図３Ａ】
【図３Ｂ】
【図３Ｃ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７Ａ】
【図２７Ｂ】
【図２７Ｃ】
【図２７Ｄ】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２Ａ】
【図３２Ｂ】
【図３３Ａ】
【図３３Ｂ】
【図３３Ｃ】
【図３４】
【公開番号】特開２０１３−６５２５５（Ｐ２０１３−６５２５５Ａ）
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願番号】特願２０１１−２０４６８５（Ｐ２０１１−２０４６８５）
【出願日】平成２３年９月２０日（２０１１．９．２０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＱＲコード
【出願人】（０００１３６１３６）株式会社ＰＦＵ (354)
【Ｆターム（参考）】
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願日】平成２３年９月２０日（２０１１．９．２０）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＱＲコード
【出願人】（０００１３６１３６）株式会社ＰＦＵ (354)
【Ｆターム（参考）】
[ Back to top ]