ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れかを含むユーザ情報を取得するユーザ情報取得手段と、前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定手段と、前記判定手段によって、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御手段と、を備える情報処理装置。前記所定のユーザ集合の状態は、他のユーザに係る、前記属性情報および前記位置情報の少なくとも何れかに基づいて得られる状態である、請求項1に記載の情報処理装置。前記所定のユーザ集合の状態は、前記属性情報または前記位置情報が所定の条件を満たすユーザの数、および所定のユーザの前記位置情報が所定の条件を満たすこと、の少なくとも何れかである、請求項1または2に記載の情報処理装置。前記判定手段は、ユーザ毎またはユーザの組み合わせ毎に設定された場所条件をもって、前記位置情報を判定する、請求項1から3の何れか一項に記載の情報処理装置。前記ユーザ情報取得手段は、更に現在時刻およびユーザの認証情報の少なくとも何れかを取得し、前記判定手段は、前記属性情報、前記位置情報および前記所定のユーザ集合の状態に加えて、前記現在時刻および前記認証情報の少なくとも何れかが前記条件を満たすか否かを判定する、請求項1から4の何れか一項に記載の情報処理装置。前記所定のイベントの内容は暗号化されており、前記イベント制御手段は、暗号化された前記所定のイベントの内容を復号するための復号鍵を発行することで、前記所定のイベントの発生を許可または指示する、請求項1から5の何れか一項に記載の情報処理装置。コンピュータが、ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れかを含むユーザ情報を取得するユーザ情報取得ステップと、前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定ステップと、前記判定ステップにおいて、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御ステップと、を実行するイベント制御方法。コンピュータを、ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れかを含むユーザ情報を取得するユーザ情報取得手段と、前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定手段と、前記判定手段によって、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御手段と、として機能させるためのイベント制御用プログラム。従来、位置情報を用いて人や物体を関連付けるための技術が種々提案されている。また、位置情報を参照してアクセスの許可/不許可を判定する等、位置情報を用いてセキュリティを高める技術が種々提案されている。しかし、セキュリティの高さとシステムの柔軟性は一般にトレードオフの関係にある。このため、位置情報等を用いてセキュリティを高めようとすると、システムの柔軟性が失われ、反対に、システムの柔軟性を高めようとすると、セキュリティが不十分となるという問題があった。本開示は、上記した問題に鑑み、位置情報を用いてイベントの制御を行うシステムにおいて、安全性を確保しつつ柔軟性を向上させることを課題とする。上記課題を解決するために、本開示に示された情報処理装置、イベント制御方法およびイベント制御用プログラムでは、イベントに設定された属性条件を満たす複数のユーザが場所条件を満たし、且つ集合状態条件を満たした場合に、イベントの発生を許可または指示することとした。より詳細には、本開示に係る情報処理装置は、ユーザの属性情報、該ユーザの現在位置を示す位置情報、および該ユーザが属する所定のユーザ集合の状態、の少なくとも何れかを含むユーザ情報を取得するユーザ情報取得手段と、前記属性情報、前記位置情報および前記所定のユーザ集合の状態が、所定のイベントに関連付けられた条件を満たすか否かを判定する判定手段と、前記判定手段によって、前記条件が満たされたと判定された場合に、前記所定のイベントの発生を許可または指示するイベント制御手段と、を備える情報処理装置である。また、本開示は、コンピュータによって実行される方法、またはコンピュータに実行させるプログラムとしても把握することが可能である。また、本開示は、そのようなプログラムをコンピュータその他の装置、機械等が読み取り可能な記録媒体に記録したものとしても把握できる。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。本開示に係る情報処理装置、イベント制御方法およびイベント制御用プログラムによれば、位置情報を用いてイベントの制御を行うシステムにおいて、安全性を確保しつつ柔軟性を向上させることが可能となる。以下、本開示に係る情報処理装置、イベント制御方法およびイベント制御用プログラムの実施の形態について、図面に基づいて説明する。なお、以下に説明する実施の形態は、実施形態を例示するものであって、本開示に係る情報処理装置、イベント制御方法およびイベント制御用プログラムを以下に説明する具体的構成に限定するものではない。実施にあたっては、実施の形態に応じた具体的構成が適宜採用されてよい。本実施形態において、本開示に係る情報処理装置は、イベント制御モジュール1として実施される。但し、本開示の適用対象は、位置情報を用いてイベントの制御を行うシステムであればよく、本実施形態において説明するシステムに限定されない。たとえば、情報処理装置は、ユーザ端末5によってイベントの制御が行われるシステムとして実施されてもよい。本実施形態において、イベントとは、特定の条件の下で発生するものであり、イベント情報9によって定義される。イベント情報9には、事前に設定された、イベント発生のために課される条件であるイベント発生条件93と、イベント内容91の格納先を示すイベント内容格納先情報92と、イベントとして発生させたい処理等を示すイベント内容91と、が含まれる図7等を参照。ここで、イベント内容91は、発生させられるイベントの内容が記述された情報であり、記述のフォーマットは実施形態によって様々であり、限定されない。イベント内容91は、例えば、イベント発生のために実行されるソフトウェア自体であってもよいし、イベントを実行する機能に対して与えられる指示コマンドであってもよい。また、イベント内容格納先情報92は、イベント内容91が格納されるストレージ2へのポインタである。イベント発生条件93およびイベント内容格納先情報92についても、記述のフォーマットは実施形態によって適宜採用可能であり、限定されない。<システムの構成>図1は、本実施形態に係るシステムの構成の概略を示す図である。本実施形態に係るシステムは、イベント制御モジュール1と、ストレージ2と、SNSSocialNetworkingService3と、イベント登録端末4と、ユーザ端末5と、がインターネット等のネットワークを介して互いに接続されたシステムである。なお、イベント制御モジュール1とストレージ2とは、別個のサーバとして構成されてもよいし、単一のサーバとして構成されてもよい。また、イベント登録端末4はユーザ端末5と同一の端末であってもよい。例えば、あるユーザが会議の参加メンバーでもあり主催者でもある場合、当該ユーザの端末は、イベント登録端末4とユーザ端末5とを兼ねる。図2は、本実施形態に係るイベント制御モジュール1のハードウェア構成の概略を示す図である。イベント制御モジュール1は、CPUCentralProcessingUnit11と、RAMRandomAccessMemory12と、ROMReadOnlyMemory13と、補助記憶装置19と、ネットワークを介した外部との通信を行うためのネットワークインターフェース16と、が電気的に接続された情報処理装置である。なお、情報処理装置の具体的なハードウェア構成に関しては、実施の形態に応じて適宜構成要素の省略や置換、追加が行われてよい。CPU11は、中央処理装置であり、RAM12およびROM13等に展開された命令及びデータを処理することで、RAM12、補助記憶装置19等の、イベント制御モジュール1に備えられた各構成を制御する。また、RAM12は、主記憶装置であり、CPU11によって制御され、各種命令やデータが書き込まれ、読み出される。即ち、CPU11、RAM12、およびROM13は、イベント制御モジュール1の制御部を構成する。補助記憶装置19は、不揮発性の記憶装置であり、主にイベント制御モジュール1の電源を落としても保持したい情報、例えば、RAM12にロードされるイベント制御モジュール1のOSOperatingSystemや、後述する処理を実行するための各種プログラムの他、イベント制御モジュール1によって使用される各種データが書き込まれ、読み出される。補助記憶装置19としては、例えば、EEPROMElectricallyErasableProgrammableROMやHDDHardDiskDrive等を用いることが出来る。なお、ストレージ2、SNS3、イベント登録端末4およびユーザ端末5は、イベント制御モジュール1と同じく、一般的なコンピュータとしての構成であるCPU、RAM、ROM、補助記憶装置、ネットワークインターフェース等を備えるコンピュータシステムである図示は省略する。また、イベント制御モジュール1、ストレージ2、およびSNS3等の各種サーバは、ネットワーク上にクラウドサービスとして実装されてもよい。この場合、各サーバによる処理の主体は、ネットワーク上に分散した複数のマシンとなるが、本実施形態では、サーバとしての機能を果たすための複数のマシンをまとめてサーバと称する。ユーザ端末5は、上記説明した一般的なコンピュータとしての構成に加えて、当該ユーザ端末5の現在位置を示す位置情報8bを取得するための構成を更に備える。位置情報8bを取得するための構成としては、例えば、GPSによってユーザ端末5の位置情報8bを取得するモジュール、または、通信可能な無線LANWi-Fiアクセスポイントの位置情報8bから、ユーザ端末5の位置情報8bを取得するモジュールが採用されてもよい。無線LANアクセスポイントの位置情報8bを用いる手段によれば、緯度経度に加えて、建物内の階数等、より詳細な位置情報8bを得ることも可能である。更に、位置情報8bを取得するための構成には、その他の手段が採用されてもよいし、GPSを用いる手段および無線LANアクセスポイントの位置情報8bを用いる手段を含む様々な手段から、複数の手段が組み合わされて用いられてもよい。次に、本システムを構成する各端末が備える機能について説明する。図3Aから図3Cは、本実施形態に係るシステムの機能構成の概略を示す図である。図3Aは、本実施形態に係るイベント登録端末4の機能構成の概略を示す図である。イベント登録端末4は、システムにイベント情報9を登録するための端末であり、イベント発生条件93、イベント内容格納先情報92およびイベント内容91を含むイベント情報9を生成するイベント生成部41と、生成されたイベント情報9をイベント制御モジュール1やストレージ2等に登録するイベント登録部42と、を備える。より具体的には、イベント登録部42は、イベント発生条件93およびイベント内容格納先情報92をイベント制御モジュール1に登録し、イベント内容91を、イベント内容格納先情報92に示されたストレージ2に格納させる。例えば、PCPersonalComputer、携帯電話、スマートフォン、タブレット端末、携帯ゲーム機等を、イベント登録端末4として用いることが出来る。ストレージ2は、イベント内容91を受け取り、格納するイベント内容格納部を備える図示は省略する。例えば、クラウドストレージ、サーバ等を、ストレージ2として用いることが出来る。図3Bは、本実施形態に係るユーザ端末5の機能構成の概略を示す図である。ユーザ端末5は、ユーザがイベント情報9を受け取るための端末であり、ユーザの情報を取得し、イベント制御モジュール1へ送信するユーザ情報取得機能、およびイベントを発生させるイベント発生機能を備える。より具体的には、ユーザ端末5は、SNS3上のユーザに係る情報を取得するSNS情報取得部51と、ユーザ端末5の現在位置の位置情報8bを取得する位置情報取得部52と、認証情報8eを取得する認証情報取得部53と、取得した情報をイベント制御モジュール1へ送信するユーザ情報送信部54と、ストレージ2からイベント内容91を受け取るイベント内容受取部55と、イベント制御モジュール1からイベント発生トリガを受け取るイベント発生トリガ受取部56と、イベント発生トリガを受けて、イベント内容91に従ったイベントを実行するイベント実行部57と、を備える。このうち、SNS情報取得部51、位置情報取得部52、認証情報取得部53およびユーザ情報送信部54によってユーザ情報取得機能が実現され、イベント内容受取部55、イベント発生トリガ受取部56およびイベント実行部57によってイベント発生機能が実現される図3Bを参照。例えば、PC、携帯電話、スマートフォン、タブレット端末、携帯ゲーム機等を、ユーザ端末5として用いることが出来る。なお、イベントの発生主体はユーザ端末5でなくてもよい。ユーザ端末5以外においてイベントを発生させる場合の構成および処理については、後述する。また、ユーザ端末5をイベント登録端末4としても用いる場合、ユーザ端末5は、上記説明したユーザ端末5の機能と、イベント登録端末4の機能とを兼ね備える。図3Cは、本実施形態に係るイベント制御モジュール1の機能構成の概略を示す図である。イベント制御モジュール1は、イベント登録機能、ユーザ情報受取機能、イベント発生条件判定機能およびイベント発生機能を有し、イベント発生条件93およびユーザ情報8から、各ユーザがイベント発生条件93を満たすか否かを判定する。より具体的には、本実施形態に係るイベント制御モジュール1は、CPU11が、RAM12に展開された各種プログラムを解釈および実行することで、イベント発生条件受取部21と、ユーザ情報受取部22と、時刻取得部23と、イベント発生条件判定部24と、イベント発生トリガ送信部25と、イベント内容格納先情報送信部26と、を備える情報処理装置として機能する図3Cを参照。また、本実施形態では、これらの機能がいずれも汎用のCPU11によって実行される例について説明しているが、これらの機能は、その一部または全部が、1または複数の専用のプロセッサによって実現されてもよい。なお、イベント制御モジュール1は、例えば、クラウド上、サーバ上、ユーザ端末5上等に実装されてよい。イベント発生条件受取部21は、イベント発生条件93およびイベント内容格納先情報92を、イベント登録端末4から受け取る。ユーザ情報受取部22は、ユーザ端末5からユーザ情報8を受け取る。ここで、ユーザ情報8には、ユーザ属性8a、ユーザの現在位置を示す位置情報8b、ユーザが属する所定のユーザ集合の状態以下、集合状態と称する8c、現在時刻8dおよびユーザの認証情報8eの少なくとも何れかを含む。なお、集合状態8cは、例えば、他のユーザを含むユーザの集合において、ユーザ属性8aまたは位置情報8bが所定の条件を満たすユーザの数や、所定のユーザの位置情報8bが所定の条件を満たしているか否か、等を示す情報であり、他のユーザのユーザ属性8aや位置情報8b等に基づいて得ることが出来る。時刻取得部23は、現在時刻8dを取得する。なお、現在時刻8dは、ユーザ端末5によって取得させ、イベント制御モジュール1に対して送信させることとしてもよいが、本実施形態では、イベント制御モジュール1の時刻取得部23によって取得した現在時刻8dを、ユーザ情報8として用いることとしている。これによって、ユーザがユーザ端末5の時刻設定を変更する等して不正にイベントを発生させることを防止することが出来る。イベント発生条件判定部24は、イベント発生条件93およびユーザ情報8に基づいて各ユーザがイベント発生条件93を満たすか否かを判定する。より具体的には、イベント発生条件判定部24は、ユーザ情報8に含まれるユーザ属性8a、位置情報8b、集合状態8c、現在時刻8dおよび認証情報8eが、イベントに関連付けられたイベント発生条件93に含まれる属性条件93a、場所条件93b、集合状態条件93c、時間条件93dおよび認証条件93eを満たすか否かを判定する。ここで、各条件には、ユーザ毎またはユーザの組み合わせ毎に異なるものが設定されてもよい。例えば、場所条件93bには、ユーザ毎またはユーザの組み合わせ毎に異なる場所を設定することが出来る。図4は、本実施形態において用いられるイベント発生条件93の構成を示す図である。図4に示されたイベント発生条件93には、属性条件93a、場所条件93bおよび集合状態条件93cが設定されている。また、イベント発生条件93には、更に、時間条件93dおよび認証条件93eが設定されてもよい。ここで、属性条件93aとは、イベントを発生させたいユーザまたはユーザ端末5の属性を判定するための条件であり、例えば、ユーザのSNS3参加状態が判定される。より具体的には、ユーザが所属するSNS3上のグループコミュニティ等の参加状態や、ユーザがSNS3上のプロフィールで表明している趣味や趣向等のステイタス等が判定される。ここで、グループの例としては、所属会社、所属部門、所属サークル、在籍または卒業した学校、等が挙げられ、ステイタスの例としては、出身地、居住地、在籍または卒業した学校、勤務先、趣味、等が挙げられる。場所条件93bとは、イベントを発生させたい場所を判定するための条件であり、グループ単位個人単位で設定可能である。場所条件93bは、例えば、緯度経度の範囲指定によって設定されてもよいし、地図上にマッピングされたエリアを指定することによって設定されてもよい。場所条件93bを緯度経度の範囲指定によって設定する場合、例えば、中心点の緯度経度と中心点からの距離とを用いて円形の範囲を指定することによって設定することが出来る。場所条件93bの設定方法は実施の形態に応じて適宜選択可能であり、本開示において説明した方法に限定されない。また、場所条件93bには、複数地点が設定されてもよいし、固定位置以外が設定されてもよい。集合状態条件93cとは、イベントを発生させたいユーザ端末5の集合状態8cを判定するための条件であり、例えば、場所条件93bを満たしているユーザの数場所条件を満たしたユーザがn人以上等、場所条件93bを満たさなければならない特定ユーザの存在キーパーソン、ユーザが更に満たさなければならない絞り込み条件、等が設定されてよい。また、時間条件93dとは、現在時刻8dが、イベントが発生する時間であるか否かを判定するための条件であり、例えば、特定の月日時刻曜日期間等によって設定可能である。認証条件93eとは、ユーザ端末5のユーザを認証したい場合に利用される条件であり、主にセキュリティ強化や、ユーザまたはキーパーソンの本人確認に利用される。認証に用いられる具体的な手法としては、一般的なユーザ識別子社員番号等とパスワードを用いた認証の他、合言葉パスワード会員番号等を音声で入力して行う音声認証、合言葉パスワード会員番号等を文字で入力して行う文字認証、ユーザのポーズや動き等を入力装置において検出して行うジェスチャー認証、会員証QRコードバーコード景色を撮影し解析して行う画像帳票認証、音声による話者認証顔認証指紋、掌紋認証虹彩、網膜パターン静脈パターン筆跡鑑定による生体認証、ニーモニック認証、等が挙げられる。イベント発生トリガ送信部25は、イベント発生条件93を満たすユーザ端末5にイベント発生トリガを送信することで、イベント内容91に示されたイベントの発生を許可または指示する。即ち、イベント発生トリガ送信部25は、イベント発生条件93が満たされたと判定された場合に、イベントの発生を許可または指示する。イベント内容格納先情報送信部26は、イベント発生条件93を満たすユーザ端末5にイベント内容格納先情報92を送信する。<処理の流れ>以下、図5から図17を用いて、本実施形態に係る処理の詳細を説明する。なお、本実施形態において説明される処理の具体的な内容および順序等は、実施する上での一例である。具体的な処理内容および順序等は、実施の形態に応じて適宜選択されてよい。図5は、本実施形態に係るシステムにおける処理のフェーズを示す図である。本実施形態に係るシステムによって実行される処理は、大きく分けて事前設定フェーズと運用フェーズに分けられる。事前設定フェーズは、イベント情報9の生成およびイベント情報9の登録からなるフェーズであり、イベント登録端末4にてイベント情報9が生成され、生成されたイベント情報9がイベント制御モジュール1およびストレージ2に登録される、いわば準備段階に相当するフェーズである。一方、運用フェーズは、ユーザ情報8の取得、イベント発生要否の判定およびイベントの発生からなるフェーズであり、事前設定フェーズにおいて設定された条件等に基づいて、システムが運用されるフェーズである。初めに、事前設定フェーズにおける処理について説明する。図6は、本実施形態に係るイベント生成処理の概要を示す図である。管理者であるユーザは、イベント登録端末4に対して、イベント内容91、イベント発生条件93およびイベント内容格納先情報92を入力する。入力を受けたイベント登録端末4のイベント生成部41は、ユーザの入力に従って、イベント内容91、イベント発生条件93およびイベント内容格納先情報92を含むイベント情報9を生成する。図7は、本実施形態において生成されるイベント情報9の例を示す図である。この例において、イベント情報9を作成する管理者は会議主催者であり、情報漏洩の防止の観点から、事前のメールによる資料配布や印刷物の配布を行うことなく、機密資料の情報を、会議中にのみ会議参加者と共有したいと考えている。また、この会議で閲覧される資料は、所属部の管理職の承認が必要な資料であることとする。上記のような要求を満たすイベント情報9を作成するため、管理者は、イベント登録端末4に対して、イベント内容91として機密資料の閲覧機密資料が格納されたストレージ2へのアクセス許可、および機密資料の暗号解除を、イベント発生条件93のうち場所条件93bとして東京本社営業グループ企画グループ対象および大阪支店開発グループ対象を、イベント発生条件93のうち属性条件93aとして営業グループOR企画グループOR開発グループを、集合状態条件93cとして各場所において当該ユーザの管理職が同行していることを、時間条件93dとして会議中の時間帯8月17日13:00-18:00を、認証条件93eとして社員番号とパスワードの入力を、入力する。イベント内容格納先情報92には、例えば、○○クラウドストレージの△△フォルダ等のように、会議の開催地からアクセス可能なストレージ2が適宜設定される。入力を受けたイベント登録端末4のイベント生成部41は、上記入力内容に従って、イベント内容91、イベント発生条件93およびイベント内容格納先情報92を含むイベント情報9を生成する図7を参照。イベント情報9の生成が完了すると、その後、処理はイベント登録処理に進む。図8は、本実施形態に係るイベント登録処理の概要を示す図である。イベント情報9が生成されると、イベント登録端末4のイベント登録部42は、生成されたイベント情報9を登録する。具体的には、イベント登録端末4のイベント登録部42は、イベント発生条件93およびイベント内容格納先情報92をイベント制御モジュール1に対して送信し、イベント内容91を、イベント内容格納先情報92に示されているストレージ2に対して送信する。イベント発生条件93およびイベント内容格納先情報92を受信したイベント制御モジュール1のイベント発生条件受取部21は、補助記憶装置19にイベント発生条件93およびイベント内容格納先情報92を登録する。また、イベント内容91を受信したストレージ2は、イベント内容91を格納する。次に、運用フェーズにおける処理について説明する。図9は、本実施形態に係るユーザ情報取得処理の概要を示す図である。図9に示された処理は、イベント情報9が登録されると、定期的に実行される。ユーザ端末5は、ユーザ情報8を取得し、イベント制御モジュール1へ送信する。ユーザ情報8には、ユーザ属性8a、位置情報8bおよび認証情報8e等が含まれる。図10は、本実施形態においてユーザ端末5のSNS情報取得部51によって取得される、ユーザ属性8aの例を示す図である。図10に示す例では、ユーザ端末5のSNS情報取得部51は、SNS3のAPIApplicationProgramInterfaceから、ユーザA~Fのユーザ属性8aとして、会社においてユーザの所属するグループ、およびユーザのステイタス役職等等を取得する。図11は、本実施形態において複数のユーザ端末5によってユーザ情報8が取得され、イベント制御モジュール1に対して送信される様子を例示する図である。ユーザ端末5のSNS情報取得部51は、SNS3のAPIを呼び出す等の方法で、インターネットを介して、ユーザ属性8aを取得し、位置情報取得部52は、位置情報取得用のAPI等を介して、GPS等を用いて得られたユーザ端末5の位置情報8bを取得する。また、ユーザ端末5の認証情報取得部53は、認証情報API等を介して、ユーザによって入力された社員番号従業員番号とパスワードとの組み合わせを認証サーバに送信する。社員番号とパスワードとの組み合わせを受信した認証サーバは、社員番号とパスワードとの組み合わせが、判定対象となっているユーザ端末5のユーザの社員番号およびパスワードと一致するか否かを判定する。なお、ユーザ毎の社員番号とパスワードとの組み合わせは、認証サーバによって予め保持されている。認証サーバは、ユーザの認証本人確認が完了すると、本人確認結果として、ユーザ端末5に対して認証情報8eを送信する。ユーザ属性8a、位置情報8bおよび認証情報8e等のユーザ情報8が取得されると、ユーザ端末5のユーザ情報送信部54は、取得されたユーザ情報8を、イベント制御モジュール1に対して送信する。そして、イベント制御モジュール1のユーザ情報受取部22は、ユーザ端末5より送信されたユーザ情報8を受信する。また、イベント制御モジュール1の時刻取得部23は、現在時刻8dを取得し、取得された時刻を、ユーザ情報8が取得された時刻として、ユーザ情報8に組み込む。図12は、本実施形態においてイベント制御モジュール1によって取得された、ユーザ情報8の例を示す図である。ユーザ情報8が取得されると、処理はイベント発生判定処理に進む。図13は、本実施形態に係るイベント発生判定処理の概要を示す図である。イベント発生判定処理では、ユーザ情報8とイベント発生条件93の判定が行われ、条件を満たすユーザ端末5に、イベント発生トリガとイベント内容格納先情報92が送信される。以下、イベント発生判定処理の詳細を説明する。イベント発生条件判定部24は、事前設定フェーズのイベント登録処理において予め登録されていたイベント発生条件93を、補助記憶装置19から読み出し、ユーザ情報取得処理において取得されたユーザ情報8と比較することで、イベント発生条件判定を行う。図14は、本実施形態に係るイベント発生条件判定処理の流れを示すフローチャートである。本フローチャートに示された処理は、ユーザ情報受取部22によってユーザ情報8が取得されたことを契機として実行される。ステップS101では、ユーザ端末5の使用ユーザの属性が属性条件93aを満たしているか否かが判定される。イベント発生条件判定部24は、取得されたユーザ情報8に含まれるユーザ属性8aが、イベント発生条件93に設定されている属性条件93aを満たしているか否かを判定する。即ち、ステップS101では、ユーザ端末を使用するユーザ自身が所定の属性を有しているか否かの判定が行われる。図7に示されたイベント情報9の例では、属性条件93aとして営業グループOR企画グループOR開発グループが設定されている。このため、イベント発生条件判定部24は、ユーザ属性8aが営業グループ、企画グループおよび開発グループの少なくとも何れかに該当するか否かを判定する。図12に示した例では、ユーザA~Eは属性条件93aを満たすが、ユーザFは事務グループ所属であり、属性条件93aを満たさない。ユーザの属性が属性条件93aを満たしていないと判定された場合、処理はステップS107へ進む。一方、ユーザの属性が属性条件93aを満たしていると判定された場合、処理はステップS102へ進む。ステップS102では、ユーザ端末5の現在位置が場所条件93bを満たしているか否かが判定される。イベント発生条件判定部24は、取得されたユーザ情報8に含まれる位置情報8bが示す現在位置が、イベント発生条件93に設定されている場所条件93bを満たしているか否かを判定する。例えば、位置情報8bが緯度経度で示される場合、イベント発生条件判定部24は、位置情報8bが示す緯度経度が、場所条件93bに示された緯度経度の範囲内であるか否かを判定することで、ユーザ情報8に含まれる位置情報8bが示す現在位置が場所条件93bを満たしているか否かを判定する。図7に示されたイベント情報9の例では、場所条件93bとして東京本社営業グループ企画グループ対象および大阪支店開発グループ対象が設定されている。このため、イベント発生条件判定部24は、営業グループ企画グループに属するユーザ図12に示した例では、ユーザA、B、およびEについては、位置情報8bが示す現在位置が東京本社の範囲内であるか否かを判定し、開発グループに属するユーザ図12に示した例では、ユーザCおよびDについては、位置情報8bが示す現在位置が大阪支店の範囲内であるか否かを判定する。図12に示した例では、ユーザA~C、EおよびFは場所条件93bを満たすが、ユーザDの位置情報8bはユーザDの現在地が富士山であることを示しており、場所条件93bを満たさない。ユーザ端末5の位置情報8bが場所条件93bを満たしていないと判定された場合、処理はステップS107へ進む。一方、ユーザ端末5の位置情報8bが場所条件93bを満たしていると判定された場合、処理はステップS103へ進む。ステップS103では、ユーザ端末5の集合の状態が集合状態条件93cを満たしているか否かが判定される。イベント発生条件判定部24は、他のユーザ端末5を含む所定のユーザ端末5の集合の状態集合状態が、イベント発生条件93に設定されている集合状態条件93cを満たしているか否かを判定する。集合状態条件93cとしては、例えば、場所条件93bを満たしているユーザの数場所条件を満たしたユーザがn人以上等、特定ユーザが場所条件93bを満たしていることキーパーソンが所定場所に居ること、ユーザが更に満たさなければならない絞り込み条件、等が判定されてよい。集合状態条件93cを用いた判定に用いる集合状態8cの情報は、図12に示した、イベント制御モジュール1によって蓄積されている他のユーザ端末5のユーザ情報8を含むユーザ情報の集合を参照し、集合状態条件に応じた分析処理を行うことで、集合状態を取得することが出来る。例えば、集合状態条件93cが属性条件を満たしたユーザのうち、場所条件を満たしたユーザがn人以上である場合、イベント発生条件判定部24は、属性条件を満たした他のユーザ端末5のユーザ情報8を含むユーザ情報の集合を参照し、場所条件を満たしたユーザの数をカウントすることで、集合状態を取得することが出来る。また、例えば、集合状態条件93cが特定ユーザが場所条件93bを満たしていることである場合、イベント発生条件判定部24は、他のユーザ端末5のユーザ情報8を含むユーザ情報の集合を参照し、特定ユーザが場所条件93bを満たしているか否かを判定することで、集合状態を取得することが出来る。図7に示されたイベント情報9の例では、集合状態条件93cとして各場所において当該ユーザの管理職が同行していることが設定されている。このため、イベント発生条件判定部24は、営業グループ企画グループに属するユーザ図12に示した例では、ユーザA、B、およびEについては、東京本社の範囲内に管理職であるユーザが居るか否かを判定し、開発グループに属するユーザ図12に示した例では、ユーザCおよびDについては、大阪支店の範囲内に管理職であるユーザがいるか否かを判定する。図12に示した例では、ユーザAおよびBについては、営業グループの管理職部長であるユーザAが東京本社にいるため集合状態条件93cを満たし、ユーザCおよびDについては、開発グループの管理職部長であるユーザCが大阪支店にいるため集合状態条件93cを満たすが、ユーザEについては、企画グループの管理職が東京本社に居ないため、集合状態条件93cを満たさない。ユーザ端末5の集合の状態が集合状態条件93cを満たしていないと判定された場合、処理はステップS107へ進む。一方、ユーザ端末5の集合の状態が集合状態条件93cを満たしていると判定された場合、処理はステップS104へ進む。ステップS104では、現在時刻8dが時間条件93dを満たしているか否かが判定される。イベント発生条件判定部24は、取得されたユーザ情報8に含まれる現在時刻8dが、イベント発生条件93に設定されている時間条件93dを満たしているか否かを判定する。より具体的には、イベント発生条件判定部24は、現在時刻8dが、時間条件93dに示された開始時刻以降であり且つ終了時刻以前であるか否かを判定することで、現在時刻8dが時間条件93dを満たしているか否かを判定する。但し、時間条件93dには、開始時刻および終了時刻の何れか一方のみが設定されていてもよい。図7に示されたイベント情報9の例では、時間条件93dとして会議中の時間帯8月17日13:00-18:00が設定されている。このため、イベント発生条件判定部24は、現在時刻8dが8月17日の13:00以降且つ18:00以前であるか否かを判定する。図12に示した例では、イベント発生条件判定処理は会議中の時間帯に実行されており、ユーザA~Fは何れも時間条件93dを満たす。現在時刻8dが時間条件93dを満たしていないと判定された場合、処理はステップS107へ進む。一方、現在時刻8dが時間条件93dを満たしていると判定された場合、処理はステップS105へ進む。ステップS105では、ユーザ端末5の認証情報8eが認証条件93eを満たしているか否かが判定される。イベント発生条件判定部24は、取得されたユーザ情報8に含まれる認証情報8eが、イベント発生条件93に設定されている認証条件93eを満たしているか否かを判定する。図7に示されたイベント情報9の例では、認証条件93eとして社員番号とパスワードの入力が設定されている。このため、イベント発生条件判定部24は、ユーザ情報8に、社員番号とパスワードが入力されて認証サーバによる本人確認が為されたことを示す認証情報8eが含まれているか否かを参照することで判定する。図12に示した例では、ユーザA~Fは何れも認証条件93eを満たす。なお、本実施形態では、ユーザ情報8に認証情報8eとして認証サーバによる本人確認結果が含まれ、これを参照して判定を行うこととしているが、このような方法に代えて、ユーザ情報8に社員番号とパスワードが含まれ、イベント制御モジュール1によって社員番号とパスワードの正当性が判定されることで、認証条件93eが満たされているか否かを判定することとしてもよい。認証情報8eが認証条件93eを満たしていないと判定された場合、処理はステップS107へ進む。一方、認証情報8eが認証条件93eを満たしていると判定された場合、処理はステップS106へ進む。ステップS106では、イベント発生トリガが送信される。イベント発生トリガ送信部25は、ステップS101からステップS105までの全ての判定において条件が満たされていた場合、イベント発生条件93が満たされたと判断して、ユーザ端末5に対してイベント発生トリガを送信する。図15は、本実施形態に係るイベント発生条件判定結果の例を示す図である。図15に示された例では、ユーザA~Cについては、イベント発生条件93が満たされているため、イベント発生トリガ送信部25によってイベント発生トリガが送信される。一方、ユーザD~Fについては、イベント発生条件93が満たされていないため、イベント発生トリガは送信されない。その後、本フローチャートに示された処理は終了し、処理はイベント発生処理へ進む。ステップS107では、エラーメッセージが出力される。イベント制御モジュール1は、ステップS101からステップS105までの何れかの判定において条件が満たされなかった場合、イベント発生条件93が満たされなかったと判断して、ユーザ端末5に対してエラーメッセージを送信する。図15に示された例では、ユーザD~Fについては、イベント発生条件93が満たされていないため、エラーメッセージが送信される。その後、本フローチャートに示された処理は終了する。但し、ステップS107におけるエラーメッセージの送信は行われなくてもよい。例えば、定期的にイベント発生条件判定処理を実行し、イベント発生条件93が満たされた時点で自動的に発生するようなイベント等、エラーメッセージを出力することが好ましくないイベントについては、エラーメッセージは送信されなくてもよい。一方、ユーザによるイベントのリクエストを受けてイベント発生条件判定処理を実行するようなイベント等、ユーザにイベントが発生しないことを通知することが好ましいイベントについては、エラーメッセージが送信されてよい。再び図13を参照し、図14のフローチャートに示されたイベント発生条件判定処理においてイベント発生条件93が満たされたと判定された場合の処理の流れを説明する。上述の通り図14のステップS106を参照、イベント発生トリガ送信部25は、イベント発生条件93が満たされた場合、ユーザ端末5に対してイベント発生トリガを送信する。送信されたイベント発生トリガは、ユーザ端末5のイベント発生トリガ受取部56によって受信される。また、イベント制御モジュール1のイベント内容格納先情報送信部26は、補助記憶装置19から、満たされたイベント発生条件93に対応するイベント内容格納先情報92を読み出し、ユーザ端末5に対して送信する。ユーザ端末5のイベント内容受取部55は、イベント内容格納先情報92を受信すると、このイベント内容格納先情報92を参照して、イベント内容格納先情報92に示されたストレージ2にアクセスし、当該ストレージ2から、満たされたイベント発生条件93に対応するイベント内容91を取得する。その後、処理はイベント発生処理に進む。なお、本実施形態では、イベント内容格納先情報92およびイベント内容91は、イベント発生条件93を満たした場合に、ユーザ端末5によって取得されるが、イベント内容格納先情報92およびイベント内容91は、ユーザ端末5によって予めイベント発生条件93が満たされる前に取得されていてもよい。このようにすることで、イベント発生条件93を満たした場合に、イベント発生トリガを発行するのみで、イベントを発生させることが出来る。図16は、本実施形態に係るイベント発生処理の概要を示す図である。ユーザ端末5のイベント実行部57は、イベント発生トリガ受取部56によってイベント発生トリガが受信されると、イベント内容91に従ってイベントを発生させる。先述の通り、イベントの発生とは、所定のイベント用ソフトウェアの実行であってもよいし、所定の機能に対する指示コマンドの発行であってもよい。図17は、本実施形態におけるユーザ端末5毎のイベント発生状況の例を示す図である。図15に示した例では、ユーザABCはすべてのイベント発生条件93を満たしているため、それぞれの端末でイベント発生トリガおよびイベント内容格納先情報92を受け取り、イベント内容91機密文書の閲覧を取得し、イベントを発生させることが出来る図17を参照。これに対して、ユーザDは場所条件93bを満たしていないため、ユーザEは集合条件状態を満たしていないため、ユーザFは属性条件93aを満たしていないため、イベント発生トリガおよびイベント内容格納先情報92を受け取ることができず、イベント内容91を取得することができない図17を参照。また、ユーザD~Fは、後日、イベント内容91を受け取ろうとしても、時間条件93dを満たすことが出来ないため、イベント発生トリガおよびイベント内容格納先情報92を受け取ることができず、イベント内容91を取得することができない。また、イベント内容91またはイベント内容格納先情報92を暗号化しておき、イベント発生トリガ送信部25は、暗号化されたイベント内容91またはイベント内容格納先情報92を復号するための復号鍵としてのイベント発生トリガを発行することで、イベントの発生を許可または指示することとしてもよい。このようにすることで、イベント発生条件93が満たされていない状態でユーザ端末5がイベントを発生させようとしても、イベント内容91またはイベント内容格納先情報92を復号することが出来ない。即ち、このような仕組みによれば、ユーザによってイベントが不正に発生させられることを防止することが出来る。<バリエーション>次に、本開示に係るシステムを実施する場合の実施形態のバリエーションを説明する。上記説明した実施形態では、イベント情報9に含まれる情報のうち、イベント発生条件93およびイベント内容格納先情報92は、イベント登録端末4からイベント制御モジュール1へ登録され、イベント内容91は、イベント登録端末4から直接ストレージ2に格納される例について説明したが、イベント情報9の登録ルートは様々であってよい。図18は、イベント登録のバリエーションを示す図である。また、図19は、図18に示されたバリエーションにおける、イベント制御モジュール1の機能構成の概略を示す図である。図18に示した例では、イベント情報9に含まれるイベント内容91、イベント発生条件93およびイベント内容格納先情報92は、イベント登録端末4からイベント制御モジュール1へ一旦送信される。そして、イベント制御モジュール1は、このうちイベント発生条件93およびイベント内容格納先情報92を登録し、イベント内容91をストレージ2に転送してストレージ2に格納する。このため、本バリエーションに係るイベント制御モジュール1は、図3Cを用いて上述した機能に加えて、イベント内容経由部27によるイベント内容経由機能を更に備える図19を参照。また、上記説明した実施形態では、イベント発生条件93が満たされた場合のイベント発生の仕組みとして、イベント発生トリガおよびイベント内容格納先情報92が、イベント制御モジュール1によってユーザ端末5宛に送信され、これを受信したユーザ端末5が、イベント内容格納先情報92を参照して、ストレージ2にイベント内容91を取りに行き、ユーザ端末5においてイベントを発生させる仕組みが採用されているが、このような仕組みに代えて、他のイベント発生の仕組みが採用されてもよい。図20は、ストレージ2においてイベントを発生させる場合のイベント発生の仕組みを示す図である。また、図21は、図20に示されたバリエーションにおける、イベント制御モジュール1の機能構成の概略を示す図である。図20に示された例では、イベント発生条件93が満たされると、はじめに、イベント制御モジュール1が、イベント内容格納先情報92を参照して、ストレージ2へイベント発生トリガを送信する。そして、ストレージ2内でイベント発生トリガとイベント内容91が揃うことで、イベントが発生する。このため、本バリエーションに係るイベント制御モジュール1は、図3Cを用いて上述したイベント内容格納先情報送信部26を備えなくてもよい。また、イベント制御モジュール1のイベント発生トリガ送信部25は、ストレージ2に対してイベント発生トリガを送信する図21を参照。図22は、ユーザ端末5においてイベントを発生させる場合のイベント発生の仕組みを示す図である。また、図23は、図22に示されたバリエーションにおける、イベント制御モジュール1の機能構成の概略を示す図である。図22に示された例では、イベント発生条件93が満たされると、はじめに、イベント制御モジュール1が、イベント内容格納先情報92を参照して、ストレージ2にイベント内容91を取りに行く。そして、イベント制御モジュール1が、イベント内容91とイベント発生トリガをユーザ端末5に送信することで、ユーザ端末5においてイベント発生トリガとイベント内容91が揃い、イベントが発生する。このため、本バリエーションに係るイベント制御モジュール1は、図3Cを用いて上述したイベント発生トリガ送信部25およびイベント内容格納先情報送信部26に代えて、イベント内容格納先情報92を参照してストレージ2からイベント内容91を取得するイベント内容取得部28と、イベント内容91をユーザ端末5に送信するイベント内容送信部29と、を備える図23を参照。図24は、イベント制御モジュール1においてイベントを発生させる場合のイベント発生の仕組みを示す図である。また、図25は、図24に示されたバリエーションにおける、イベント制御モジュール1の機能構成の概略を示す図である。図24に示された例では、イベント発生条件93が満たされると、はじめに、イベント制御モジュール1が、イベント内容格納先情報92を参照して、ストレージ2にイベント内容91を取りに行く。そして、イベント制御モジュール1内でイベント発生トリガとイベント内容91が揃うことで、イベントが発生する。このため、本バリエーションに係るイベント制御モジュール1は、図3Cを用いて上述したイベント発生トリガ送信部25およびイベント内容格納先情報送信部26に代えて、イベント内容格納先情報92を参照してストレージ2からイベント内容91を取得するイベント内容取得部28と、イベント発生トリガとイベント内容91とが揃った場合にイベントを発生させるイベント実行部30と、を備える図25を参照。<システムの使用例>次に、本開示を適用可能なシステムの具体例を説明する。ゲームシステム図26は、本実施形態に係るシステムを、複数ユーザが、夫々のユーザ端末5を用いてネットワークを介して相互に接続し、同時にプレイするゲームシステムに適用する例を示す図である。本実施例では、ユーザ端末5は、上記説明した機能の他、ゲーム機能を備える。このゲームは、例えば、複数のユーザが協力してモンスターを倒し、ゲーム中で用いることのできる特典やアイテムを入手することを目的とするゲームである。図27Aから図27Dは、本実施形態に係るシステムを、ゲームシステムに適用する場合に登録されるイベント情報9の例を示す図である。このうち、図27Aから図27Cに示した例では、図26に示されたチームαは、キャンペーン期間8月中に、チームの2人以上が、東京タワー、東京スカイツリーまたは秋葉原に居る場合に、イベントを発生させることが出来る。ここで発生させるイベントは、限定モンスターの出現や、ゲーム中の特殊装備の取得、ゲーム中のレアアイテムの取得をするためのくじ引き等である。また、図27Bに示されたイベント情報9によれば、認証条件93eとして、図27Aに示されたイベント情報9に係るイベントで出現した限定モンスターを倒していることが設定されている。このようにして、複数のイベントに関連性を持たせることとしてもよい。このような例によれば、ゲームの提供者は、場所条件93bに設定された観光地等と協力して宣伝効果を高めることが出来、場所条件93bに設定された観光地等は、ゲームを利用して集客することが出来る。また、ユーザも、他のユーザと交流しながらゲームをプレイしたり、特典を得たりすることが出来る。また、図27Dに示した例では、集合状態条件93cとして同じグループに属していないプレイヤーユーザが3人以上集まることが設定されており、また、イベント内容91は、3~4人のグループを自動結成である。このようにすることで、普段チームを組んでいないユーザ同士が集まって新たなチームを組み、ゲームをプレイすることが出来る。即ち、このようなイベント情報9を設定することで、ユーザが会場ゲーム会社とコラボレーションした店舗等に到着すると、自動的にチームが結成され、そのチームでゲームを行うこととなる。自動的に組まれたチームによるプレイの終了後は、このチームを解消してもよいし、そのまま継続してもよい。地域社会連携システム図28は、本実施形態に係るシステムを、地域社会連携システムに適用する場合に登録されるイベント情報9の例を示す図である。従来、学校地域PTA等の地域社会では、子供が通学時に交通事故や犯罪に巻き込まれないよう、対策を取っている。具体的には、通学時間帯に、スクールバスのバス停や横断歩道等に2~3人の大人が立って、子供達を見守ること等である。この役割は当番制である。また、警察や学校から、学区内の不審者情報が提供されるが、個人情報保護や関係者の身の安全のため、取り扱いには注意が必要である。多数複製して配布を行うには注意が必要であるため、通常は限定された数の複製を回覧する等するが、会合に参加していないと見ることが出来ない、時間が限られておりゆっくり閲覧できない、紙に印刷されたものであるため、必要な情報を探すのが面倒である、最新の情報を得ることが出来ない、等の問題があった。そこで、図28に示すようなイベント情報9を設定し、ユーザ端末5を用いてイベント条件を満たした場合にのみ閲覧させるようにすることで、情報閲覧の利便性を高めることが出来る。図29は、図28に示したイベント情報9をもって本実施形態に係るシステムを運用した場合のイベント発生状況を示す図である。ユーザAおよびBが平日8:00以降且つ9:30以前の通学時間帯に、一緒に学区1の交差点に立っている場合、イベント情報9に示されたイベント発生条件93が満たされるため、ユーザAおよびBは、学区1の不審者情報を閲覧することが出来る。ユーザCおよびDも同様に、平日8:00以降且つ9:30以前の通学時間帯に、一緒に学区2の交差点に立っている場合、イベント情報9に示されたイベント発生条件93が満たされるため、学区2の不審者情報を閲覧することが出来る。しかし、通学時間帯ではない時間帯では、ユーザAおよびB、またはユーザCおよびDが一緒に所定の交差点に立っても、不審者情報を閲覧することは出来ない。また、ユーザEおよびFは、平日8:00以降且つ9:30以前の通学時間帯に、一緒に学区2の交差点に立っているが、ユーザFはグループ→PTA会員グループとの属性条件93aを満たさず、ユーザEはPTA会員が二人以上いるとの集合状態条件93cを満たさないため、ユーザEおよびFは、不審者情報を閲覧出来ない。また、ユーザGおよびHは、平日8:00以降且つ9:30以前の通学時間帯に、一緒の場所に居るが、いずれも、学区内との場所条件93bを満たさないため、不審者情報を閲覧出来ない。オリエンテーリングシステム図30は、本実施形態に係るシステムを、オリエンテーリングシステムに適用する場合に登録されるイベント情報9の例を示す図である。従来、オリエンテーリングのチーム活動において、全員で行動せず、各々でポイントを回り、ゴールのみチームで行う等の不正行為をしたチームがあっても、これを運営側が把握するのは難しかった。そこで、図30に示したようなイベント情報9において、チームメンバが全員そろっているとの集合状態条件93cを設定し、イベント内容91を運営者へ、チームのポイント通過状況を通知とすることで、運営側が不正行為を把握することが可能となる。図31は、図30に示したイベント情報9をもって本実施形態に係るシステムを運用した場合のイベント発生状況を示す図である。運営者は、チームが指令ポイントを通過すると、チームメンバが全員揃っているチームについて通過状況を受けることが出来る。また、イベント内容91として、更にARAugmentedRealityタグによる指令の閲覧が設定されていることで、オリエンテーリングの参加者に、チームが全員揃っていることの特典を与えることが出来る。ARタグは、図31に示すように、ユーザ端末5のディスプレイにおいて、ユーザ端末5のカメラをもって撮像された画像に重ねて表示される画像であり、オリエンテーリングの進行に必要な情報を提供することが出来る。会議管理システム図32Aおよび図32Bは、本実施形態に係るシステムを、会議管理システムに適用する場合に登録されるイベント情報9の例を示す図である。この会議が秘密の情報を扱う会議である場合、会議において閲覧される資料のセキュリティを確保することが重要である。図32Aに示されたイベント情報9に設定されたイベント発生条件93によれば、会議の時間帯に、役員会グループからの、本人確認済みの参加者全員が会議の開催場所に揃わないと資料を閲覧することが出来ない。但し、図32Aに示された場所条件93b本部OR支部のうち支部は、図32Bに示されたイベント情報9に係るイベント新規支部開設を発生させることで、追加することが出来る。即ち、この実施例によれば、予め設定されていた支部に全員が揃っていなくても、会議の時間帯に、役員会グループに所属する本人確認済みのユーザ2人以上が、新たに支部を開設したい場所に居ることで、その場所を新たに支部とし、続いて図32Aに示されたイベントを発生させて、資料を閲覧することが出来る。共有手帳システム図33Aから図33Cは、本実施形態に係るシステムを、共有手帳システムに適用する場合に登録されるイベント情報9の例を示す図である。なお、共有手帳システムは、複数のユーザ共有者に対して共有のオンライン手帳サービスを提供するシステムであり、共有手帳は、例えば、恋人、夫婦、家族、等によって共有することが出来る。この実施例によれば、ユーザ属性8aにおいて共有者例えば、恋人同士であるユーザが、図33Aのイベント情報9に係るイベントを発生させることで、複数の共有者恋人であれば、2人で同時に訪れた場所を、図33Bおよび図33Cに係るイベント条件の場所条件93bとして登録することが出来る。そして、登録された場所で図33Bのイベント情報9に係るイベントを発生させることで、思い出の場所で、写真アノテーション、コメント、ARタグ、SNS投稿等の思い出登録図33Bのイベント内容91をすることが出来る。また、登録された場所を再度複数の共有者で同時に訪れた際に、図33Cのイベント情報9に係るイベントを発生させることで、アラート通知をし、以前に来た時に思い出登録した写真やSNS投稿等を見る思い出再現図33Cのイベント内容91をすることができる。なお、図33Bのイベント内容91思い出登録は、登録された場所を再度複数の共有者で訪れた際に発生させ、写真アノテーション、コメント、ARタグ、SNS投稿等の思い出登録を追加することができる。情報配信システム図34は、本実施形態に係るシステムを、情報配信システムに適用する場合に登録されるイベント情報9の例を示す図である。この実施例では、はじめに、場所条件93bに設定された店舗レストラン等を訪れた際に、ユーザに、当該店舗を一緒に訪れた複数のユーザが属するグループを登録させる。ユーザは、ユーザ端末5を用いてグループに所属するユーザのSNS3における識別情報を指定し、SNS3に送信する等の方法で、SNS3のグループを作成することが出来る。このようにしておくことで、再度そのグループメンバーのうち2人以上全員でなくてもよいでレストラン周辺を訪れた際に、図34のイベント情報9に係るイベントが発生し、当該グループに向けた、今日のオススメ情報クーポン配信が行われる。なお、図34のイベント情報9では、時間条件93dが複数設定されており、何れの時間条件93dを満たしたかによって、配信されるクーポンが異なる。図14を用いて説明したイベント発生条件判定処理では、イベントに関連付けられたイベント発生条件93に含まれる属性条件93a、場所条件93b、集合状態条件93c、時間条件93dおよび認証条件93eを満たすか否かが判定されるが、夫々の条件内で複数の分岐が設定され、分岐の結果によって発生するイベントにバリエーションを持たせることとしてもよい。例えば、図34に示された例では、時間条件93dを満たすか否かのほかに、3つある時間条件93d10:00~13:00、16:00~20:00および21:00~22:00の何れを満たしたかによって、配信されるクーポンの内容が変化する。<効果>本実施形態に係るシステムによれば、位置情報を用いてイベントの制御を行うシステムにおいて、安全性を確保しつつ柔軟性を向上させることが可能となる。