イベント処理方法、イベント処理装置及びイベント処理プログラム
【課題】リアルタイムにイベントを処理した結果を必要に応じて訂正できるようにする。
【解決手段】イベント受信部３３０は、情報源から到着したイベントをリアルタイム判定部３４０及びイベント整列部３５０に夫々転送する。リアルタイム判定部３４０は、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照し、イベントがルールに適合する場合、通知部３８０にアラート通知の送信を依頼する。イベント整列部３５０は、イベントを所定時間蓄積し、イベントを発生順にバッチ判定部３６０に転送する。バッチ判定部３６０は、ルールテーブル３１０を参照し、イベントがルールに適合するか否かの判定結果を正誤判定部３７０に通知する。正誤判定部３７０は、リアルタイム判定部３４０による判定結果とバッチ判定部３６０による判定結果とが異なるときに、通知部３８０に誤報訂正通知の送信を依頼する。
【解決手段】イベント受信部３３０は、情報源から到着したイベントをリアルタイム判定部３４０及びイベント整列部３５０に夫々転送する。リアルタイム判定部３４０は、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照し、イベントがルールに適合する場合、通知部３８０にアラート通知の送信を依頼する。イベント整列部３５０は、イベントを所定時間蓄積し、イベントを発生順にバッチ判定部３６０に転送する。バッチ判定部３６０は、ルールテーブル３１０を参照し、イベントがルールに適合するか否かの判定結果を正誤判定部３７０に通知する。正誤判定部３７０は、リアルタイム判定部３４０による判定結果とバッチ判定部３６０による判定結果とが異なるときに、通知部３８０に誤報訂正通知の送信を依頼する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、各種情報源から発生するイベントにルールを適用し、予め指定された処理を実行するイベント処理技術に関する。
【背景技術】
【０００２】
近年、各種の機器やセンサなどの情報源から発生するイベントにルールを適用し、リアルタイムに所定の処理を実行するイベント処理技術が考えられている。イベント処理技術を応用したサービスの一例として、例えば、ユーザの外出中に、人感センサが人間の所在を感知すると、警備会社に通報する警報システムなどが挙げられる。
【０００３】
しかし、イベントを発生する情報源とイベントを処理するサーバとの間で通信に時間がかかると、時系列で発生する複数のイベントの間でサーバへの到着順序が逆転してしまい、間違った処理が実行されてしまう可能性がある。間違った処理の一例として、例えば、ユーザが帰宅したときに、外出中であるか否かを判定するための位置情報がサーバに到着する前に、人感センサがユーザの所在を感知して警備会社に通報するなどが想定される。
【０００４】
このため、イベントがサーバに到着する遅延時間を計測し、最大の遅延時間と最小の遅延時間との差を待ち時間として、その間イベントを蓄積して整列（ソート）することで、イベントの発生順にイベントを処理する技術が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平９−２４４９８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来技術においては、イベントを発生順に処理することが可能となるが、イベントを待ち時間の間蓄積するためにリアルタイムにイベントが処理されなくなってしまう、という問題点がある。リアルタイムにイベントが処理されなくなってしまうと、例えば、ユーザの外出中に、人感センサが人間の所在を感知して警備会社に通報しても、警備会社がユーザ宅に駆けつける時間が遅くなるなどの不具合が発生してしまう。
【０００７】
そこで、本発明は従来技術の問題点に鑑み、情報源から到着したイベントを到着順に処理した結果を必要に応じて訂正できるようにした、イベント処理方法、イベント処理装置及びイベント処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
コンピュータが、イベントを処理するためのルールが格納された記憶部を参照し、情報源から到着したイベントを到着順に処理すると共に、所定時間蓄積したイベントを発生順に処理する。そして、コンピュータが、到着順にイベントを処理した結果を送信して記憶部に記憶し、記憶した結果と発生順にイベントを処理した結果とが異なっている場合に、発生順にイベントを処理した結果を送信する。
【発明の効果】
【０００９】
情報源から到着したイベントを到着順に処理した結果を必要に応じて訂正することができる。
【図面の簡単な説明】
【００１０】
【図１】情報システムの一例を示す概要図である。
【図２】サーバの内部構造の一例を示す構造図である。
【図３】サーバの一例を示す機能ブロック図である。
【図４】ルールテーブルの一例を示すデータ構造図である。
【図５】アラートテーブルの一例を示すデータ構造図である。
【図６】イベント受信処理の一例を示すフローチャートである。
【図７】イベントの一例を示す説明図である。
【図８】リアルタイム判定処理の一例を示すフローチャートである。
【図９】アラート通知依頼の一例を示す説明図である。
【図１０】アラート情報登録依頼の一例を示す説明図である。
【図１１】イベント整列処理の一例を示すフローチャートである。
【図１２】イベント整列処理の一例を示すフローチャートである。
【図１３】バッチ判定処理の一例を示すフローチャートである。
【図１４】判定結果通知の一例を示す説明図である。
【図１５】正誤判定処理の一例を示すフローチャートである。
【図１６】通知処理の一例を示すフローチャートである。
【図１７】ユーザに送信するアラート通知の一例を示す説明図である。
【図１８】アラートテーブルの他の例を示すデータ構造図である。
【図１９】リアルタイム判定処理の他の例を示すフローチャートである。
【図２０】アラート通知依頼の他の例を示す説明図である。
【図２１】正誤判定処理の他の例を示すフローチャートである。
【図２２】ユーザに送信するアラート通知の他の例を示す説明図である。
【図２３】ＩＤ情報登録依頼の一例を示す説明図である。
【図２４】ＩＤ情報削除依頼の一例を示す説明図である。
【図２５】バッチ判定処理の他の例を示すフローチャートである。
【図２６】正誤判定処理の他の例を示すフローチャートである。
【図２７】実施形態の作用を説明するための処理シーケンス図である。
【発明を実施するための形態】
【００１１】
以下、添付された図面を参照し、本発明を実施するための実施形態について詳細に説明する。
［第１実施形態］
図１は、第１実施形態に係る情報システムの一例を示す。
【００１２】
各種情報源としてのイベント発生源１００は、インターネットなどのネットワーク２００を介して、各種サービスを提供するサービス業者のサーバ３００に接続される。ここで、イベント発生源１００としては、例えば、人間の所在を感知する人感センサ、人間の位置情報を測位するＧＰＳ（Global Positioning System）レシーバ、住宅の施錠状態を検
知する施錠センサなどがある。各種サービスを提供するサービス業者としては、例えば、ユーザの住宅を警備する警備会社などがある。また、ネットワーク２００には、サーバ３００から各種通知を受信するためのデバイスの一例として、例えば、ユーザの携帯電話４００が接続される。
【００１３】
サーバ３００は、図２に示すように、メモリ３００Ａ、ＣＰＵ（Central Processing Unit）などのプロセッサ３００Ｂ、ハードディスク３００Ｃ、ドライブ装置３００Ｄ及び
通信装置３００Ｅを含んだコンピュータである。メモリ３００Ａ、プロセッサ３００Ｂ、ハードディスク３００Ｃ、ドライブ装置３００Ｄ及び通信装置３００Ｅは、シリアルＡＴＡ（AT Attachment）などのバス３００Ｆにより相互に接続される。ハードディスク３０
０Ｃは、記憶部として機能する。ドライブ装置３００Ｄは、例えば、ＣＤ−ＲＯＭ（Comp
act Disk Read Only Memory）、ＤＶＤ−ＲＯＭ（Digital Versatile Disk Read Only Memory）などのリムーバブルディスク３００Ｇからデータを読み込む。リムーバブルディスク３００Ｇに代えて、フラッシュメモリを内蔵したＵＳＢ（Universal Serial Bus）メモリなどを使用することもできる。通信装置３００Ｅは、バス３００Ｆとネットワーク２００とを接続する、例えば、ＮＩＣ（Network Interface Card）などである。
【００１４】
サーバ３００のハードディスク３００Ｃは、図３に示すように、ルールテーブル３１０と、アラートテーブル３２０と、を夫々格納する。ルールテーブル３１０は、イベント発生源１００からサーバ３００に到着したイベントに適用するルールを規定するためのテーブルであって、図４に示すように、ルールを識別するルールＩＤ（Identifier）と、具体的なルールと、を関連付けたルール情報を保持する。ここで、ルールは、例えば、ＳＱＬ（Structured Query Language）などの専用の言語で記述される。なお、図４において、
ルールＩＤが“rule001”のルールでは、ユーザの外出中に（location!=home）、人感セ
ンサが人間の所在を感知すると（motionsensor.event=true）、“id”の情報を警備会社
と“id”により特定されるユーザに通知するというイベントが規定されている。アラートテーブル３２０は、サーバ３００から携帯電話４００に通知されたアラートを記憶するテーブルであって、図５に示すように、イベントを識別するイベントＩＤと、ルールを識別するルールＩＤと、処理したイベントの順番を示すイベント列と、を関連付けたアラート情報を保持する。
【００１５】
サーバ３００のプロセッサ３００Ｂは、メモリ３００Ａに展開されたイベント処理プログラムを実行することで、図３に示すように、イベント受信部３３０と、リアルタイム判定部３４０と、イベント整列部３５０と、バッチ判定部３６０と、正誤判定部３７０と、通知部３８０と、を具現化する。
【００１６】
イベント受信部３３０は、イベント発生源１００からイベントが到着したことを契機として、到着したイベントをリアルタイム判定部３４０とイベント整列部３５０とに夫々転送する。
【００１７】
リアルタイム判定部３４０は、イベント受信部３３０からイベントが転送されたことを契機として、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照し、イベントがルールに適合しているか否かを判定する。また、リアルタイム判定部３４０は、イベントがルールに適合していると判定すれば、正誤判定部３７０にアラート情報の登録を依頼すると共に、通知部３８０にアラートの通知を依頼する。なお、リアルタイム判定部３４０は、処理速度を向上させるために、起動時などに、ハードディスク３００Ｃからルールテーブル３１０をメモリ３００Ａに読み込むようにしてもよい（以下同様）。この場合、メモリ３００Ａが記憶部の一例として挙げられる。
【００１８】
イベント整列部３５０は、イベント受信部３３０からイベントが転送されたことを契機として、イベントをメモリ３００Ａに所定時間蓄積（バッファリング）した後、このイベントを発生順に整列する。そして、イベント整列部３５０は、発生順に整列したイベントをバッチ判定部３６０に順次転送する。ここで、イベントを蓄積する所定時間は、例えば、背景技術で引用した特開平９−２４４９８４号公報で提案された技術など、公知の技術を用いて適宜決定すればよい。
【００１９】
バッチ判定部３６０は、イベント整列部３５０からイベントが転送されたことを契機として、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照し、イベントがルールに適合しているか否かを判定する。また、バッチ判定部３６０は、正誤判定部３７０に判定結果を通知する。
【００２０】
正誤判定部３７０は、リアルタイム判定部３４０からアラート情報の登録依頼があったことを契機として、ハードディスク３００Ｃに格納されたアラートテーブル３２０にアラート情報を登録する。また、正誤判定部３７０は、バッチ判定部３７０から判定結果の通知があったことを契機として、アラートテーブル３２０からアラート情報の削除、又は、通知部３８０へアラート通知若しくは誤報訂正通知を依頼する。
【００２１】
なお、リアルタイム判定部３４０は、第１の処理手段に該当する。また、イベント整列部３５０及びバッチ判定部３６０は、第２の処理手段に該当する。さらに、正誤判定部３７０及び通知部３８０は、送信手段に該当する。
【００２２】
図６は、イベント発生源１００からサーバ３００にイベントが到着したことを契機として、サーバ３００のイベント受信部３３０が実行するイベント受信処理の一例を示す。ここで、イベントは、図７に示すように、メッセージタイプ、イベントＩＤ、イベントタイプ及びデータを含む。メッセージタイプは、メッセージの種別を識別するための情報を格納する。イベントタイプは、データに格納される情報のタイプを格納する。データは、イベントタイプに対応した情報を格納する。
【００２３】
ステップ１（図では「Ｓ１」と略記する。以下同様。）では、イベント受信部３３０が、リアルタイム判定部３４０にイベントを転送する。
ステップ２では、イベント受信部３３０が、イベント整列部３５０にイベントを転送する。
【００２４】
かかるイベント受信処理によれば、サーバ３００のイベント受信部３３０は、イベント発生源１００から到着したイベントをリアルタイム判定部３４０及びイベント整列部３５０に夫々転送する。
【００２５】
図８は、イベント受信部３３０からイベントが転送されたことを契機として、サーバ３００のリアルタイム判定部３４０が実行するリアルタイム判定処理の一例を示す。
ステップ１１では、リアルタイム判定部３４０が、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照して、イベントがルールに適合しているか否かを判定する。そして、リアルタイム判定部３４０は、イベントがルールに適合していると判定すれば処理をステップ１２へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理を終了させる（Ｎｏ）。
【００２６】
ステップ１２では、リアルタイム判定部３４０が、ユーザの携帯電話４００にアラートを送信するために、通知部３８０にアラート通知を依頼する。ここで、アラート通知依頼は、図９に示すように、メッセージタイプ、通知先、通知方法及び通知内容を含む。なお、通知先及び通知方法は、例えば、ユーザによって前もって指定される（以下同様）。
【００２７】
ステップ１３では、リアルタイム判定部３４０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を更新するために、正誤判定部３７０にアラート情報の登録を依頼する。ここで、アラート情報登録依頼は、図１０に示すように、メッセージタイプ、イベントのイベントＩＤ、適合したルールのルールＩＤ及び適合したイベントの順序を示すイベント列を含む。
【００２８】
かかるリアルタイム判定処理によれば、サーバ３００のリアルタイム判定部３４０は、イベントがルールに適合していれば、通知部３８０にアラート通知を依頼すると共に、正誤判定部３７０にアラート情報の登録を依頼する。
【００２９】
図１１は、イベント受信部３３０からイベントが転送されたことを契機として、サーバ
３００のイベント整列部３５０が実行するイベント整列処理の一例を示す。
ステップ２１では、イベント整列部３５０が、イベントをメモリ３００Ａに蓄積する。
【００３０】
ステップ２２では、イベント整列部３５０が、例えば、タイマー機能を利用して、タイマーがスタートしているか否かを判定する。そして、イベント整列部３５０は、タイマーがスタートしていると判定すれば処理を終了させる一方（Ｙｅｓ）、タイマーがスタートしていないと判定すれば処理をステップ２３へと進める（Ｎｏ）。
【００３１】
ステップ２３では、イベント整列部３５０が、タイマーをスタートさせる。
図１２は、イベント受信部３３０からイベントが転送されたことを契機として、図１１に示すイベント整列処理と並行して、サーバ３００のイベント整列部３５０が実行するイベント整列処理の一例を示す。
【００３２】
ステップ３１では、イベント整列部３５０が、イベントの蓄積を開始してから所定時間が経過したか否かを判定する。そして、イベント整列部３５０は、イベントの蓄積を開始してから所定時間経過したと判定すれば処理をステップ３２へと進める一方（Ｙｅｓ）、イベントの蓄積を開始してから所定時間経過していないと判定すれば処理を終了させる（Ｎｏ）。
【００３３】
ステップ３２では、イベント整列部３５０が、メモリ３００Ａに蓄積したイベントを発生順に整列する。
ステップ３３では、イベント整列部３５０が、整列したイベントをバッチ判定部３６０に順次転送、即ち、イベントを発生順にバッチ判定部３６０に順次転送する。
【００３４】
ステップ３４では、イベント整列部３５０が、メモリ３００Ａからすべてのイベントを削除する。
ステップ３５では、イベント整列部３５０が、タイマーをストップし、リセットする。
【００３５】
かかるイベント整列処理によれば、サーバ３００のイベント整列部３５０は、イベント発生源１００から到着したイベントを所定時間蓄積し、イベントを発生順にバッチ判定部３６０に順次転送する。このため、バッチ判定部３６０は、発生順に整列されたイベントを受け取ることができる。
【００３６】
図１３は、イベント整列部３５０からイベントが転送されたことを契機として、サーバ３００のバッチ判定部３６０が実行するバッチ判定処理の一例を示す。
ステップ４１では、バッチ判定部３６０が、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照して、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部３６０は、イベントがルールに適合していると判定すれば処理をステップ４２へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理をステップ４３へと進める（Ｎｏ）。
【００３７】
ステップ４２では、バッチ判定部３６０が、正誤判定部３７０にイベントがルールに適合することを知らせる判定結果を通知する。ここで、判定結果通知は、図１４に示すように、メッセージタイプ、通知先、通知方法、判定結果、イベントＩＤ、ルールＩＤ、イベント列及び通知内容を含む。判定結果は、ステップ４１における判定結果、具体的には、ルールに適合するか、ルールに適合しないかを格納する。通知内容は、ユーザなどに通知する内容を格納する（通知する必要がない場合には空欄とする）。
【００３８】
ステップ４３では、バッチ判定部３６０が、正誤判定部３７０にイベントがルールに適合しないことを知らせる判定結果を通知する。なお、判定結果通知は、図１４に示すメッ
セージと同様であるので、その説明は省略する。
【００３９】
かかるバッチ判定処理によれば、サーバ３００のバッチ判定部３６０は、発生順に整列された各イベントについて、リアルタイム判定処理と同一のルールテーブル３１０に基いて、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部３６０は、正誤判定部３７０に判定結果を通知する。
【００４０】
図１５は、リアルタイム判定部３４０からアラート情報の登録依頼、又は、バッチ判定部３６０から判定結果の通知があったことを契機として、サーバ３００の正誤判定部３７０が実行する正誤判定処理の一例を示す。
【００４１】
ステップ５１では、正誤判定部３７０が、例えば、登録依頼又は判定結果通知のメッセージタイプを参照することで、アラート情報の登録依頼であるか否かを判定する。そして、正誤判定部３７０は、アラート情報の登録依頼であると判定すれば処理をステップ５２へと進める一方（Ｙｅｓ）、アラート情報の登録依頼でないと判定すれば処理をステップ５３へと進める（Ｎｏ）。
【００４２】
ステップ５２では、正誤判定部３７０が、アラート情報の登録依頼に含まれるイベントＩＤ、ルールＩＤ及びイベント列を関連付けたアラート情報を生成し、このアラート情報をハードディスク３００Ｃに格納されたアラートテーブル３２０に登録する。なお、イベントＩＤ及びルールＩＤにより特定されるアラート情報がアラートテーブル３２０に登録されている場合には、そのイベント列にイベントを追加すればよい（以下同様）。
【００４３】
ステップ５３では、正誤判定部３７０が、判定結果通知に含まれる判定結果を参照することで、判定結果通知に係るイベントがルールに適合しているか否かを判定する。そして、正誤判定部３７０は、イベントがルールに適合していると判定すれば処理をステップ５４へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理をステップ５７へと進める（Ｎｏ）。
【００４４】
ステップ５４では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、アラート情報が登録されていると判定すれば処理をステップ５５へと進める一方（Ｙｅｓ）、アラート情報が登録されていないと判定すれば処理をステップ５６へと進める（Ｎｏ）。
【００４５】
ステップ５５では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０から、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報を削除する。
【００４６】
ステップ５６では、正誤判定部３７０が、通知部３８０にアラート通知を依頼する。
ステップ５７では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、アラート情報が登録されていると判定すれば処理をステップ５８へと進める一方（Ｙｅｓ）、アラート情報が登録されていないと判定すれば処理を終了させる（Ｎｏ）。
【００４７】
ステップ５８では、正誤判定部３７０が、送信済みのアラート通知は間違いであったことを訂正する誤報訂正通知を通知部３８０に依頼する。
かかる正誤判定処理によれば、サーバ３００の正誤判定部３７０は、アラート情報の登
録依頼があると、アラートテーブル３２０にアラート情報を登録する。また、正誤判定部３７０は、判定結果通知に係るイベントがルールに適合し、かつ、イベントのアラート情報がアラートテーブル３２０に登録されていれば、リアルタイム判定部３４０による判定は正しかったと判断して、アラートテーブル３２０からアラート情報を削除する。正誤判定部３７０は、判定結果通知に係るイベントがルールに適合し、かつ、イベントのアラート情報がアラートテーブル３２０に登録されていなければ、アラート通知がなされていないと判断して、通知部３８０にアラート通知を依頼する。正誤判定部３７０は、判定結果通知に係るイベントがルールに適合しておらず、かつ、イベントのアラート情報がアラートテーブル３２０に登録されていれば、リアルタイム判定部３４０による判定は間違っていたと判断して、通知部３８０に誤報訂正通知を依頼する。
【００４８】
図１６は、リアルタイム判定部３４０からアラート通知の依頼、又は、正誤判定部３７０からアラート通知若しくは誤報訂正通知の依頼があったことを契機として、サーバ３００の通知部３８０が実行する通知処理の一例を示す。
【００４９】
ステップ６１では、通知部３８０が、アラート通知依頼又は誤報訂正通知依頼に含まれる通知先、通知方法及び通知内容に対応した、図１７に示すようなメッセージを生成する。ここで、メッセージは、図１７に示すように、送信先（Ｔｏ）、送信元（Ｆｒｏｍ）、時刻（Ｄａｔｅ）及び本体（Ｂｏｄｙ）を含む。
【００５０】
ステップ６２では、通知部３８０が、通知依頼に含まれる通知方法に応じた手段を使用して、ステップ６１で生成したメッセージをユーザの携帯電話４００に送信する。
かかる通知処理によれば、サーバ３００の通知部３８０は、アラート通知又は誤報訂正通知の依頼に応じたメッセージをユーザの携帯電話４００に送信する。
【００５１】
従って、かかるイベント処理装置によれば、イベント発生源１００からサーバ３００に到着したイベントは、リアルタイム（到着順）に処理されると共に、所定時間蓄積される。また、所定時間蓄積されたイベントは、発生順に整列され、正しい順序で処理される。そして、リアルタイムに処理された結果と発生順に処理された結果とが比較され、これらが異なる場合には、リアルタイムに処理された結果が間違っていたことを訂正する誤報訂正通知が送信される。このため、例えば、リアルタイム処理において警備会社に誤って通報されても、その後に誤報訂正通知が送信されるので、ユーザが通報は間違いであることを連絡する必要がなく、また、警備会社がユーザ宅に駆けつける必要がなくなる。
【００５２】
［第２実施形態］
第２実施形態では、第１実施形態に係る情報システムにおいて、ユーザの携帯電話４００に送信されるメッセージ（アラート通知）に、過去の実績から求められたアラート通知の確度（アラート通知が正しい確率）が付加される。なお、第２実施形態に係る情報システムは、先の第１実施形態に係る情報システムと大部分共通しているので、第１実施形態と異なる部分についてのみ説明する（以下同様）。
【００５３】
ここでは、正誤判定部３７０が、アラート通知が正しい確率を演算し、リアルタイム判定部３４０が、その確率を参照してアラート通知を依頼する。
サーバ３００のハードディスク３００Ｃに格納されるアラートテーブル３２０は、図１８に示すように、イベントＩＤ、ルールＩＤ及びイベント列に加え、アラート通知が正しい確率と、通知フラグと、を関連付けたアラート情報を保持する。通知フラグには、アラート通知が送信された場合“１”が格納され、アラート通知が送信されない場合“０”が格納される。
【００５４】
図１９は、イベント受信部３３０からイベントが転送されたことを契機として、サーバ３００のリアルタイム判定部３４０が実行するリアルタイム判定処理の他の例を示す。
ステップ７１では、リアルタイム判定部３４０が、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照して、イベントがルールに適合しているか否かを判定する。そして、リアルタイム判定部３４０は、イベントがルールに適合していると判定すれば処理をステップ７２へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理を終了させる（Ｎｏ）。
【００５５】
ステップ７２では、リアルタイム判定部３４０が、ハードディスク３００Ｃに格納されたアラートテーブル３４０を参照し、イベントに含まれるイベントＩＤ及び適合したルールのルールＩＤにより特定されるアラート情報から確率を抽出する。なお、アラート情報の確率が演算されていないときには、この確率を１００％とすればよい。
【００５６】
ステップ７３では、リアルタイム判定部３４０が、通知部３８０にアラート通知を依頼する。ここで、アラート通知依頼は、図２０に示すように、メッセージタイプ、通知先、通知方法、通知内容及び確率を含む。
【００５７】
ステップ７４では、リアルタイム処理部３４０が、正誤判定部３７０にアラート情報の登録を依頼する。
かかるリアルタイム判定処理によれば、先の第１実施形態の作用に加え、サーバ３００のリアルタイム判定部３４０は、イベントがルールに適合していれば、通知部３８０に依頼するアラート通知に確率を付加することができる。
【００５８】
図２１は、リアルタイム判定部３４０からアラート情報の登録依頼、又は、バッチ判定部３６０から判定結果の通知があったことを契機として、サーバ３００の正誤判定部３７０が実行する正誤判定処理の他の例を示す。
【００５９】
ステップ８１では、正誤判定部３７０が、アラート情報の登録依頼であるか否かを判定する。そして、正誤判定部３７０は、アラート情報の登録依頼であると判定すれば処理をステップ８２へと進める一方（Ｙｅｓ）、アラート情報の登録依頼でないと判定すれば処理をステップ８３へと進める（Ｎｏ）。
【００６０】
ステップ８２では、正誤判定部３７０が、アラート情報の登録依頼に含まれるイベントＩＤ、ルールＩＤ、確率、イベント列及び通知フラグを関連付けたアラート情報を生成し、このアラート情報をハードディスク３００Ｃに格納されたアラートテーブル３２０に登録する。ここで、アラート情報において、確率は空欄、通知フラグは“０”とする。
【００６１】
ステップ８３では、正誤判定部３７０が、判定結果通知に含まれる判定結果を参照することで、判定結果通知に係るイベントがルールに適合しているか否かを判定する。そして、正誤判定部３７０は、イベントがルールに適合していると判定すれば処理をステップ８４へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理をステップ８８へと進める（Ｎｏ）。
【００６２】
ステップ８４では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、アラート情報が登録されていると判定すれば処理をステップ８６へと進める一方（Ｙｅｓ）、アラート情報が登録されていないと判定すれば処理をステップ８５へと進める（Ｎｏ）。
【００６３】
ステップ８５では、正誤判定部３７０が、通知部３８０にアラート通知を依頼する。
ステップ８６では、正誤判定部３７０が、判定結果通知に係るイベントについて、次に
示す演算式から、アラート通知が正しかった確率を演算する。
【００６４】
確率＝（正誤判定部３７０で誤報訂正通知が通知されなかった回数）／
（リアルタイム判定部３４０でアラート通知が通知された回数）×１００
ステップ８７では、正誤判定部３７０が、判定結果通知に係るイベントのアラート情報について、ハードディスク３００Ｃに格納されたアラートテーブル３２０の確率を更新する。
【００６５】
ステップ８８では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、イベントのアラート情報が登録されていると判定すれば処理をステップ８９へと進める一方（Ｙｅｓ）、イベントのアラート情報が登録されていないと判定すれば処理を終了させる（Ｎｏ）。
【００６６】
ステップ８９では、正誤判定部３７０が、通知部３８０に誤報訂正通知を依頼し、その後処理をステップ８６へと戻す。
かかる正誤判定処理によれば、サーバ３００の正誤判定部３７０は、アラート情報の登録依頼があると、アラートテーブル３２０にアラート情報を登録する。また、正誤判定部３７０は、判定結果通知に係るイベントがルールに適合し、かつ、イベントのアラート情報がアラートテーブル３２０に登録されていなければ、アラート通知がなされていないと判断して、通知部３８０にアラート通知を依頼する。正誤判定部３７０は、判定結果に係るイベントがルールに適合しておらず、かつ、イベントのアラート情報がアラートテーブル３２０に登録されていれば、リアルタイム判定部３４０による判定は間違っていたと判断して、通知部３８０に誤報訂正通知を依頼する。さらに、正誤判定部３７０は、判定結果通知に係るイベントのアラート情報について、アラート通知が正しい確率を演算し、アラートテーブル３２０の確率を更新する。
【００６７】
従って、かかるイベント処理装置によれば、過去の実績に応じて、アラート通知が正しい確率が演算され、これがユーザへのアラート通知に付加される。このため、ユーザは、図２２に示すような、アラート通知に付加された確率を参照することで、そのアラート通知がどの位正しいものかを把握することができる。
【００６８】
なお、リアルタイム判定部３４０は、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、イベントに係るアラート情報の確率が所定の閾値以下であるとき、通知部３８０にアラート通知を依頼しないようにしてもよい。このようにすれば、確度が低いアラート通知がユーザに通知されることを抑制できる。
【００６９】
［第３実施形態］
第３実施形態では、第１実施形態又は第２実施形態に係る情報システムにおいて、イベント発生源１００からサーバ３００に到着したイベントを所定時間蓄積した後、発生順に整列させてルールに適合するか否かを判定する効率を向上させる。なお、以下の説明では、第１実施形態に係る情報システムを前提とするが、第２実施形態に係る情報システムを前提としてもよい。
【００７０】
ここでは、バッチ判定部３６０は、正誤判定部３７０からのＩＤ登録依頼又はＩＤ削除依頼に応答してメモリ３００ＡにＩＤ情報を登録又は削除する。ＩＤ登録依頼及びＩＤ削除依頼は、図２３及び図２４に示すように、メッセージタイプ、イベントＩＤ及びルールＩＤを含む。また、バッチ判定部３６０は、イベントのＩＤ情報がメモリ３００Ａに登録されているときのみ、正誤判定部３７０に判定結果を通知する。一方、正誤判定部３７０は、バッチ判定部３６０にＩＤ情報の登録又は削除を依頼する。
【００７１】
図２５は、イベント整列部３５０からイベントが転送され、又は、正誤判定部３７０からＩＤ登録若しくはＩＤ削除の依頼があったことを契機として、サーバ３００のバッチ判定部３６０が実行するバッチ判定処理の他の例を示す。
【００７２】
ステップ９１では、バッチ判定部３６０が、例えば、イベント又はＩＤ登録依頼若しくはＩＤ削除依頼のメッセージタイプを参照することで、ＩＤ登録依頼であるか否かを判定する。そして、バッチ判定部３６０は、ＩＤ登録依頼であると判定すれば処理をステップ９２へと進める一方（Ｙｅｓ）、ＩＤ登録依頼でないと判定すれば処理をステップ９３へと進める（Ｎｏ）。
【００７３】
ステップ９２では、バッチ判定部３６０が、ステップ９１と同様な方法で、ＩＤ登録依頼に含まれるイベントＩＤ及びルールＩＤを関連付けたＩＤ情報を生成し、このＩＤ情報をメモリ３００Ａに登録させる。
【００７４】
ステップ９３では、バッチ判定部３６０が、例えば、メッセージを解析することで、ＩＤ削除依頼であるか否かを判定する。そして、バッチ判定部３６０は、ＩＤ削除依頼であると判定すれば処理をステップ９４へと進める一方（Ｙｅｓ）、ＩＤ削除依頼でないと判定すれば処理をステップ９５へと進める（Ｎｏ）。
【００７５】
ステップ９４では、バッチ判定部３６０が、ＩＤ削除依頼からイベントＩＤ及びルールＩＤを抽出し、このイベントＩＤ及びルールＩＤにより特定されるＩＤ情報をメモリ３００から削除する。
【００７６】
ステップ９５では、バッチ判定部３６０が、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照して、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部３６０は、イベントがルールに適合していると判定すれば処理をステップ９６へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理をステップ９９へと進める（Ｎｏ）。
【００７７】
ステップ９６では、バッチ判定部３６０が、イベントに含まれるイベントＩＤ及び適合したルールのルールＩＤにより特定されるＩＤ情報がメモリ３００Ａに登録されているか否かを判定する。そして、バッチ判定部３６０は、ＩＤ情報がメモリ３００Ａに登録されていると判定すれば処理をステップ９７へと進める一方（Ｙｅｓ）、ＩＤ情報がメモリ３００Ａに登録されていないと判定すれば処理をステップ９８へと進める（Ｎｏ）。
【００７８】
ステップ９７では、バッチ判定部３６０が、正誤判定部３７０にイベントがルールに適合することを知らせる判定結果を通知する。
ステップ９８では、バッチ判定部３６０が、通知部３８０にアラート通知を依頼する。
【００７９】
ステップ９９では、バッチ判定部３６０が、イベントに含まれるイベントＩＤ及びアラート通知に係るルールＩＤにより特定されるＩＤ情報がメモリ３００Ａに登録されているか否かを判定する。そして、バッチ判定部３６０は、ＩＤ情報がメモリ３００Ａに登録されていると判定すれば処理をステップ１００へと進める一方（Ｙｅｓ）、ＩＤ情報がメモリ３００Ａに登録されていないと判定すれば処理を終了させる（Ｎｏ）。
【００８０】
ステップ１００では、バッチ判定部３６０が、正誤判定部３７０にイベントがルールに適合しないことを知らせる判定結果を通知する。
かかるバッチ判定処理によれば、サーバ３００のバッチ判定部３６０は、正誤判定部３７０からＩＤ登録依頼又はＩＤ削除依頼があると、メモリ３００ＡにＩＤ情報を登録又は
削除する。また、バッチ判定部３６０は、発生順に整列された各イベントについて、リアルタイム判定処理と同一のルールテーブル３１０に基いて、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部３６０は、イベントがルールに適合しているか否かにかかわらず、正誤判定部３７０に判定結果を通知すると共に、イベントがルールに適合し、かつ、ＩＤ情報がメモリ３００Ａに登録されていれば、通知部３８０に誤報訂正通知を依頼する。
【００８１】
図２６は、リアルタイム判定部３４０からアラート情報の登録依頼、又は、バッチ判定部３６０から判定結果の通知があったことを契機として、サーバ３００の正誤判定部３７０が実行する正誤判定処理の他の例を示す。
【００８２】
ステップ１０１では、正誤判定部３７０が、例えば、登録依頼又は判定結果通知のメッセージタイプを参照することで、アラート情報の登録依頼であるか否かを判定する。そして、正誤判定部３７０は、アラート情報の登録依頼であると判定すれば処理をステップ１０２へと進める一方（Ｙｅｓ）、アラート情報の登録依頼でないと判定すれば処理をステップ１０４へと進める（Ｎｏ）。
【００８３】
ステップ１０２では、正誤判定部３７０が、アラート情報の登録依頼に含まれるイベントＩＤ、ルールＩＤ及びイベント列を関連付けたアラート情報を生成し、このアラート情報をハードディスク３００Ｃに格納されたアラートテーブル３２０に登録する。
【００８４】
ステップ１０３では、正誤判定部３７０が、アラート情報の登録依頼に含まれるイベントＩＤ及びルールＩＤについて、バッチ判定部３６０にＩＤ情報の登録を依頼する。
ステップ１０４では、正誤判定部３７０が、判定結果通知に含まれる判定結果を参照することで、判定結果通知に係るイベントがルールに適合しているか否かを判定する。そして、正誤判定部３７０は、イベントがルールに適合していると判定すれば処理をステップ１０５へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理をステップ１０９へと進める（Ｎｏ）。
【００８５】
ステップ１０５では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、アラート情報が登録されていると判定すれば処理をステップ１０６へと進める一方（Ｙｅｓ）、アラート情報が登録されていないと判定すれば処理をステップ１０８へと進める（Ｎｏ）。
【００８６】
ステップ１０６では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０から、判定結果通知に係るイベントのアラート情報を削除する。
ステップ１０７では、正誤判定部３７０が、判定結果通知に含まれるイベントＩＤ及びルールＩＤについて、バッチ判定部３６０にＩＤ情報の削除を依頼する。
【００８７】
ステップ１０８では、正誤判定部３７０が、通知部３８０にアラート通知を依頼する。
ステップ１０９では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、アラート情報が登録されていると判定すれば処理をステップ１１０へと進める一方（Ｙｅｓ）、アラート情報が登録されていないと判定すれば処理を終了させる（Ｎｏ）。
【００８８】
ステップ１１０では、正誤判定部３７０が、通知部３８０に誤報訂正通知を依頼する。
ステップ１１１では、正誤判定部３７０が、判定結果通知に含まれるイベントＩＤ及び
ルールＩＤについて、バッチ判定部３６０にＩＤ情報の削除を依頼する。
【００８９】
かかる正誤判定処理によれば、サーバ３００の正誤判定部３７０は、アラート情報の登録依頼があると、アラートテーブル３２０にアラート情報を登録すると共に、バッチ判定部３６０にＩＤ情報の登録を依頼する。また、正誤判定部３７０は、判定結果通知に係るイベントがルールに適合し、かつ、アラート情報がアラートテーブル３２０に登録されていれば、アラートテーブル３２０からアラート情報を削除すると共に、バッチ判定部３６０にＩＤ情報の削除を依頼する。正誤判定部３７０は、判定結果通知に係るイベントがルールに適合し、かつ、アラート情報がアラートテーブル３２０に登録されていなければ、通知部３８０にアラート通知を依頼する。正誤判定部３７０は、判定結果通知に係るイベントがルールに適合しておらず、かつ、アラート情報がアラートテーブル３２０に登録されていれば、通知部３８０に誤報訂正通知を依頼すると共に、バッチ判定部３６０にＩＤ情報の削除を依頼する。
【００９０】
従って、バッチ判定部３６０は、ＩＤ情報がメモリ３００Ａに登録されているときに、正誤判定部３７０に判定結果を通知することとなる。このため、正誤判定部３７０は、リアルタイム判定処理における判定結果をすべて再確認する必要がなく、判定効率を向上させることができる。
【００９１】
ここで、イベント処理装置の作用・効果の理解を容易ならしめるために、具体的な事例を想定した実施例について説明する。
実施例の前提として、次のような条件を想定する。
【００９２】
（１）イベントに適用するルールは、「ユーザの外出中に人感センサが人間の所在を感知すると、警備会社に不審者侵入を通報する」とする。
（２）人感センサは、人間の所在を感知すると同時に、イベントをサーバ３００に通知する。
（３）ＧＰＳレシーバを内蔵した携帯電話４００は、定期的（例えば１分ごと）にユーザの位置情報をサーバ３００に通知する。
ユーザが外出から帰宅したとき、携帯電話４００から位置情報が通知される前に、人感センサによりユーザの所在が感知されたことを考える。この場合、図２７に示すように、人感センサからサーバ３００にイベントが通知されると（手順１）、イベント受信部３３０は、このイベントをリアルタイム判定部３４０及びイベント整列部３５０に夫々転送する（手順２、３）。イベントが転送されたリアルタイム判定部３４０は、ハードディスク３００Ｃのルールテーブル３１０を参照し、ユーザの外出中に人感センサが人間の所在を感知したというルールに適合すると判定する。そして、リアルタイム判定部３４０は、通知部３８０にアラート通知を依頼すると共に（手順４）、正誤判定部３７０にアラート情報の登録を依頼する（手順５）。また、イベントが転送されたイベント整列部３５０は、メモリ３００Ａにイベントを蓄積する。アラート通知の依頼を受けた通知部３８０は、警備会社にアラート（不審者侵入）を通知する（手順６）。また、アラート情報の登録依頼を受けた正誤判定部３７０は、ハードディスク３００Ｃのアラートテーブル３２０にアラート情報を登録する。
【００９３】
この状態において、ユーザの携帯電話４００からサーバ３００にイベントが通知されると（手順７）、イベント受信部３３０は、このイベントをリアルタイム判定部３４０及びイベント整列部３５０に夫々転送する（手順８、９）。イベントが転送されたイベント整列部３５０は、イベントの蓄積を開始してから所定時間経過したとき、発生順にイベントを整列してバッチ判定部３６０に順次転送する（手順１０）。イベントが転送されたバッチ判定部３６０は、ハードディスク３００Ｃのルールテーブル３１０を参照し、ユーザの
外出中に人感センサが人間の所在を感知したというルールに適合しないと判定する。そして、バッチ判定部３６０は、正誤判定部３７０に判定結果を通知する（手順１１）。判定結果を受けた正誤判定部３７０は、イベントがルールに適合しておらず、かつ、アラートテーブル３２０にアラート情報が登録されているため、先程通知したアラートは間違いであったと判断し、通知部３８０に誤報訂正通知を依頼する（手順１２）。誤報訂正通知を受けた通知部３８０は、警備会社に誤報訂正を通知する（手順１３）。
【００９４】
従って、サーバ３００から警備会社に誤ってアラートが通知されても、このアラートが間違いであったことを示す誤報訂正通知が通知されるので、警備会社はユーザ宅に駆けつける必要がなくなる。また、ユーザは、警備会社にアラート通知が間違いであったことを連絡する必要がなく、手間を軽減することができる。
【符号の説明】
【００９５】
１００ イベント発生源
３００ サーバ
３００Ａ メモリ
３００Ｂ プロセッサ
３００Ｃ ハードディスク
３１０ ルールテーブル
３４０ リアルタイム判定部
３５０ イベント整列部
３６０ バッチ判定部
３７０ 正誤判定部
３８０ 通知部
【技術分野】
【０００１】
本発明は、各種情報源から発生するイベントにルールを適用し、予め指定された処理を実行するイベント処理技術に関する。
【背景技術】
【０００２】
近年、各種の機器やセンサなどの情報源から発生するイベントにルールを適用し、リアルタイムに所定の処理を実行するイベント処理技術が考えられている。イベント処理技術を応用したサービスの一例として、例えば、ユーザの外出中に、人感センサが人間の所在を感知すると、警備会社に通報する警報システムなどが挙げられる。
【０００３】
しかし、イベントを発生する情報源とイベントを処理するサーバとの間で通信に時間がかかると、時系列で発生する複数のイベントの間でサーバへの到着順序が逆転してしまい、間違った処理が実行されてしまう可能性がある。間違った処理の一例として、例えば、ユーザが帰宅したときに、外出中であるか否かを判定するための位置情報がサーバに到着する前に、人感センサがユーザの所在を感知して警備会社に通報するなどが想定される。
【０００４】
このため、イベントがサーバに到着する遅延時間を計測し、最大の遅延時間と最小の遅延時間との差を待ち時間として、その間イベントを蓄積して整列（ソート）することで、イベントの発生順にイベントを処理する技術が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平９−２４４９８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来技術においては、イベントを発生順に処理することが可能となるが、イベントを待ち時間の間蓄積するためにリアルタイムにイベントが処理されなくなってしまう、という問題点がある。リアルタイムにイベントが処理されなくなってしまうと、例えば、ユーザの外出中に、人感センサが人間の所在を感知して警備会社に通報しても、警備会社がユーザ宅に駆けつける時間が遅くなるなどの不具合が発生してしまう。
【０００７】
そこで、本発明は従来技術の問題点に鑑み、情報源から到着したイベントを到着順に処理した結果を必要に応じて訂正できるようにした、イベント処理方法、イベント処理装置及びイベント処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
コンピュータが、イベントを処理するためのルールが格納された記憶部を参照し、情報源から到着したイベントを到着順に処理すると共に、所定時間蓄積したイベントを発生順に処理する。そして、コンピュータが、到着順にイベントを処理した結果を送信して記憶部に記憶し、記憶した結果と発生順にイベントを処理した結果とが異なっている場合に、発生順にイベントを処理した結果を送信する。
【発明の効果】
【０００９】
情報源から到着したイベントを到着順に処理した結果を必要に応じて訂正することができる。
【図面の簡単な説明】
【００１０】
【図１】情報システムの一例を示す概要図である。
【図２】サーバの内部構造の一例を示す構造図である。
【図３】サーバの一例を示す機能ブロック図である。
【図４】ルールテーブルの一例を示すデータ構造図である。
【図５】アラートテーブルの一例を示すデータ構造図である。
【図６】イベント受信処理の一例を示すフローチャートである。
【図７】イベントの一例を示す説明図である。
【図８】リアルタイム判定処理の一例を示すフローチャートである。
【図９】アラート通知依頼の一例を示す説明図である。
【図１０】アラート情報登録依頼の一例を示す説明図である。
【図１１】イベント整列処理の一例を示すフローチャートである。
【図１２】イベント整列処理の一例を示すフローチャートである。
【図１３】バッチ判定処理の一例を示すフローチャートである。
【図１４】判定結果通知の一例を示す説明図である。
【図１５】正誤判定処理の一例を示すフローチャートである。
【図１６】通知処理の一例を示すフローチャートである。
【図１７】ユーザに送信するアラート通知の一例を示す説明図である。
【図１８】アラートテーブルの他の例を示すデータ構造図である。
【図１９】リアルタイム判定処理の他の例を示すフローチャートである。
【図２０】アラート通知依頼の他の例を示す説明図である。
【図２１】正誤判定処理の他の例を示すフローチャートである。
【図２２】ユーザに送信するアラート通知の他の例を示す説明図である。
【図２３】ＩＤ情報登録依頼の一例を示す説明図である。
【図２４】ＩＤ情報削除依頼の一例を示す説明図である。
【図２５】バッチ判定処理の他の例を示すフローチャートである。
【図２６】正誤判定処理の他の例を示すフローチャートである。
【図２７】実施形態の作用を説明するための処理シーケンス図である。
【発明を実施するための形態】
【００１１】
以下、添付された図面を参照し、本発明を実施するための実施形態について詳細に説明する。
［第１実施形態］
図１は、第１実施形態に係る情報システムの一例を示す。
【００１２】
各種情報源としてのイベント発生源１００は、インターネットなどのネットワーク２００を介して、各種サービスを提供するサービス業者のサーバ３００に接続される。ここで、イベント発生源１００としては、例えば、人間の所在を感知する人感センサ、人間の位置情報を測位するＧＰＳ（Global Positioning System）レシーバ、住宅の施錠状態を検
知する施錠センサなどがある。各種サービスを提供するサービス業者としては、例えば、ユーザの住宅を警備する警備会社などがある。また、ネットワーク２００には、サーバ３００から各種通知を受信するためのデバイスの一例として、例えば、ユーザの携帯電話４００が接続される。
【００１３】
サーバ３００は、図２に示すように、メモリ３００Ａ、ＣＰＵ（Central Processing Unit）などのプロセッサ３００Ｂ、ハードディスク３００Ｃ、ドライブ装置３００Ｄ及び
通信装置３００Ｅを含んだコンピュータである。メモリ３００Ａ、プロセッサ３００Ｂ、ハードディスク３００Ｃ、ドライブ装置３００Ｄ及び通信装置３００Ｅは、シリアルＡＴＡ（AT Attachment）などのバス３００Ｆにより相互に接続される。ハードディスク３０
０Ｃは、記憶部として機能する。ドライブ装置３００Ｄは、例えば、ＣＤ−ＲＯＭ（Comp
act Disk Read Only Memory）、ＤＶＤ−ＲＯＭ（Digital Versatile Disk Read Only Memory）などのリムーバブルディスク３００Ｇからデータを読み込む。リムーバブルディスク３００Ｇに代えて、フラッシュメモリを内蔵したＵＳＢ（Universal Serial Bus）メモリなどを使用することもできる。通信装置３００Ｅは、バス３００Ｆとネットワーク２００とを接続する、例えば、ＮＩＣ（Network Interface Card）などである。
【００１４】
サーバ３００のハードディスク３００Ｃは、図３に示すように、ルールテーブル３１０と、アラートテーブル３２０と、を夫々格納する。ルールテーブル３１０は、イベント発生源１００からサーバ３００に到着したイベントに適用するルールを規定するためのテーブルであって、図４に示すように、ルールを識別するルールＩＤ（Identifier）と、具体的なルールと、を関連付けたルール情報を保持する。ここで、ルールは、例えば、ＳＱＬ（Structured Query Language）などの専用の言語で記述される。なお、図４において、
ルールＩＤが“rule001”のルールでは、ユーザの外出中に（location!=home）、人感セ
ンサが人間の所在を感知すると（motionsensor.event=true）、“id”の情報を警備会社
と“id”により特定されるユーザに通知するというイベントが規定されている。アラートテーブル３２０は、サーバ３００から携帯電話４００に通知されたアラートを記憶するテーブルであって、図５に示すように、イベントを識別するイベントＩＤと、ルールを識別するルールＩＤと、処理したイベントの順番を示すイベント列と、を関連付けたアラート情報を保持する。
【００１５】
サーバ３００のプロセッサ３００Ｂは、メモリ３００Ａに展開されたイベント処理プログラムを実行することで、図３に示すように、イベント受信部３３０と、リアルタイム判定部３４０と、イベント整列部３５０と、バッチ判定部３６０と、正誤判定部３７０と、通知部３８０と、を具現化する。
【００１６】
イベント受信部３３０は、イベント発生源１００からイベントが到着したことを契機として、到着したイベントをリアルタイム判定部３４０とイベント整列部３５０とに夫々転送する。
【００１７】
リアルタイム判定部３４０は、イベント受信部３３０からイベントが転送されたことを契機として、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照し、イベントがルールに適合しているか否かを判定する。また、リアルタイム判定部３４０は、イベントがルールに適合していると判定すれば、正誤判定部３７０にアラート情報の登録を依頼すると共に、通知部３８０にアラートの通知を依頼する。なお、リアルタイム判定部３４０は、処理速度を向上させるために、起動時などに、ハードディスク３００Ｃからルールテーブル３１０をメモリ３００Ａに読み込むようにしてもよい（以下同様）。この場合、メモリ３００Ａが記憶部の一例として挙げられる。
【００１８】
イベント整列部３５０は、イベント受信部３３０からイベントが転送されたことを契機として、イベントをメモリ３００Ａに所定時間蓄積（バッファリング）した後、このイベントを発生順に整列する。そして、イベント整列部３５０は、発生順に整列したイベントをバッチ判定部３６０に順次転送する。ここで、イベントを蓄積する所定時間は、例えば、背景技術で引用した特開平９−２４４９８４号公報で提案された技術など、公知の技術を用いて適宜決定すればよい。
【００１９】
バッチ判定部３６０は、イベント整列部３５０からイベントが転送されたことを契機として、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照し、イベントがルールに適合しているか否かを判定する。また、バッチ判定部３６０は、正誤判定部３７０に判定結果を通知する。
【００２０】
正誤判定部３７０は、リアルタイム判定部３４０からアラート情報の登録依頼があったことを契機として、ハードディスク３００Ｃに格納されたアラートテーブル３２０にアラート情報を登録する。また、正誤判定部３７０は、バッチ判定部３７０から判定結果の通知があったことを契機として、アラートテーブル３２０からアラート情報の削除、又は、通知部３８０へアラート通知若しくは誤報訂正通知を依頼する。
【００２１】
なお、リアルタイム判定部３４０は、第１の処理手段に該当する。また、イベント整列部３５０及びバッチ判定部３６０は、第２の処理手段に該当する。さらに、正誤判定部３７０及び通知部３８０は、送信手段に該当する。
【００２２】
図６は、イベント発生源１００からサーバ３００にイベントが到着したことを契機として、サーバ３００のイベント受信部３３０が実行するイベント受信処理の一例を示す。ここで、イベントは、図７に示すように、メッセージタイプ、イベントＩＤ、イベントタイプ及びデータを含む。メッセージタイプは、メッセージの種別を識別するための情報を格納する。イベントタイプは、データに格納される情報のタイプを格納する。データは、イベントタイプに対応した情報を格納する。
【００２３】
ステップ１（図では「Ｓ１」と略記する。以下同様。）では、イベント受信部３３０が、リアルタイム判定部３４０にイベントを転送する。
ステップ２では、イベント受信部３３０が、イベント整列部３５０にイベントを転送する。
【００２４】
かかるイベント受信処理によれば、サーバ３００のイベント受信部３３０は、イベント発生源１００から到着したイベントをリアルタイム判定部３４０及びイベント整列部３５０に夫々転送する。
【００２５】
図８は、イベント受信部３３０からイベントが転送されたことを契機として、サーバ３００のリアルタイム判定部３４０が実行するリアルタイム判定処理の一例を示す。
ステップ１１では、リアルタイム判定部３４０が、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照して、イベントがルールに適合しているか否かを判定する。そして、リアルタイム判定部３４０は、イベントがルールに適合していると判定すれば処理をステップ１２へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理を終了させる（Ｎｏ）。
【００２６】
ステップ１２では、リアルタイム判定部３４０が、ユーザの携帯電話４００にアラートを送信するために、通知部３８０にアラート通知を依頼する。ここで、アラート通知依頼は、図９に示すように、メッセージタイプ、通知先、通知方法及び通知内容を含む。なお、通知先及び通知方法は、例えば、ユーザによって前もって指定される（以下同様）。
【００２７】
ステップ１３では、リアルタイム判定部３４０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を更新するために、正誤判定部３７０にアラート情報の登録を依頼する。ここで、アラート情報登録依頼は、図１０に示すように、メッセージタイプ、イベントのイベントＩＤ、適合したルールのルールＩＤ及び適合したイベントの順序を示すイベント列を含む。
【００２８】
かかるリアルタイム判定処理によれば、サーバ３００のリアルタイム判定部３４０は、イベントがルールに適合していれば、通知部３８０にアラート通知を依頼すると共に、正誤判定部３７０にアラート情報の登録を依頼する。
【００２９】
図１１は、イベント受信部３３０からイベントが転送されたことを契機として、サーバ
３００のイベント整列部３５０が実行するイベント整列処理の一例を示す。
ステップ２１では、イベント整列部３５０が、イベントをメモリ３００Ａに蓄積する。
【００３０】
ステップ２２では、イベント整列部３５０が、例えば、タイマー機能を利用して、タイマーがスタートしているか否かを判定する。そして、イベント整列部３５０は、タイマーがスタートしていると判定すれば処理を終了させる一方（Ｙｅｓ）、タイマーがスタートしていないと判定すれば処理をステップ２３へと進める（Ｎｏ）。
【００３１】
ステップ２３では、イベント整列部３５０が、タイマーをスタートさせる。
図１２は、イベント受信部３３０からイベントが転送されたことを契機として、図１１に示すイベント整列処理と並行して、サーバ３００のイベント整列部３５０が実行するイベント整列処理の一例を示す。
【００３２】
ステップ３１では、イベント整列部３５０が、イベントの蓄積を開始してから所定時間が経過したか否かを判定する。そして、イベント整列部３５０は、イベントの蓄積を開始してから所定時間経過したと判定すれば処理をステップ３２へと進める一方（Ｙｅｓ）、イベントの蓄積を開始してから所定時間経過していないと判定すれば処理を終了させる（Ｎｏ）。
【００３３】
ステップ３２では、イベント整列部３５０が、メモリ３００Ａに蓄積したイベントを発生順に整列する。
ステップ３３では、イベント整列部３５０が、整列したイベントをバッチ判定部３６０に順次転送、即ち、イベントを発生順にバッチ判定部３６０に順次転送する。
【００３４】
ステップ３４では、イベント整列部３５０が、メモリ３００Ａからすべてのイベントを削除する。
ステップ３５では、イベント整列部３５０が、タイマーをストップし、リセットする。
【００３５】
かかるイベント整列処理によれば、サーバ３００のイベント整列部３５０は、イベント発生源１００から到着したイベントを所定時間蓄積し、イベントを発生順にバッチ判定部３６０に順次転送する。このため、バッチ判定部３６０は、発生順に整列されたイベントを受け取ることができる。
【００３６】
図１３は、イベント整列部３５０からイベントが転送されたことを契機として、サーバ３００のバッチ判定部３６０が実行するバッチ判定処理の一例を示す。
ステップ４１では、バッチ判定部３６０が、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照して、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部３６０は、イベントがルールに適合していると判定すれば処理をステップ４２へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理をステップ４３へと進める（Ｎｏ）。
【００３７】
ステップ４２では、バッチ判定部３６０が、正誤判定部３７０にイベントがルールに適合することを知らせる判定結果を通知する。ここで、判定結果通知は、図１４に示すように、メッセージタイプ、通知先、通知方法、判定結果、イベントＩＤ、ルールＩＤ、イベント列及び通知内容を含む。判定結果は、ステップ４１における判定結果、具体的には、ルールに適合するか、ルールに適合しないかを格納する。通知内容は、ユーザなどに通知する内容を格納する（通知する必要がない場合には空欄とする）。
【００３８】
ステップ４３では、バッチ判定部３６０が、正誤判定部３７０にイベントがルールに適合しないことを知らせる判定結果を通知する。なお、判定結果通知は、図１４に示すメッ
セージと同様であるので、その説明は省略する。
【００３９】
かかるバッチ判定処理によれば、サーバ３００のバッチ判定部３６０は、発生順に整列された各イベントについて、リアルタイム判定処理と同一のルールテーブル３１０に基いて、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部３６０は、正誤判定部３７０に判定結果を通知する。
【００４０】
図１５は、リアルタイム判定部３４０からアラート情報の登録依頼、又は、バッチ判定部３６０から判定結果の通知があったことを契機として、サーバ３００の正誤判定部３７０が実行する正誤判定処理の一例を示す。
【００４１】
ステップ５１では、正誤判定部３７０が、例えば、登録依頼又は判定結果通知のメッセージタイプを参照することで、アラート情報の登録依頼であるか否かを判定する。そして、正誤判定部３７０は、アラート情報の登録依頼であると判定すれば処理をステップ５２へと進める一方（Ｙｅｓ）、アラート情報の登録依頼でないと判定すれば処理をステップ５３へと進める（Ｎｏ）。
【００４２】
ステップ５２では、正誤判定部３７０が、アラート情報の登録依頼に含まれるイベントＩＤ、ルールＩＤ及びイベント列を関連付けたアラート情報を生成し、このアラート情報をハードディスク３００Ｃに格納されたアラートテーブル３２０に登録する。なお、イベントＩＤ及びルールＩＤにより特定されるアラート情報がアラートテーブル３２０に登録されている場合には、そのイベント列にイベントを追加すればよい（以下同様）。
【００４３】
ステップ５３では、正誤判定部３７０が、判定結果通知に含まれる判定結果を参照することで、判定結果通知に係るイベントがルールに適合しているか否かを判定する。そして、正誤判定部３７０は、イベントがルールに適合していると判定すれば処理をステップ５４へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理をステップ５７へと進める（Ｎｏ）。
【００４４】
ステップ５４では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、アラート情報が登録されていると判定すれば処理をステップ５５へと進める一方（Ｙｅｓ）、アラート情報が登録されていないと判定すれば処理をステップ５６へと進める（Ｎｏ）。
【００４５】
ステップ５５では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０から、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報を削除する。
【００４６】
ステップ５６では、正誤判定部３７０が、通知部３８０にアラート通知を依頼する。
ステップ５７では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、アラート情報が登録されていると判定すれば処理をステップ５８へと進める一方（Ｙｅｓ）、アラート情報が登録されていないと判定すれば処理を終了させる（Ｎｏ）。
【００４７】
ステップ５８では、正誤判定部３７０が、送信済みのアラート通知は間違いであったことを訂正する誤報訂正通知を通知部３８０に依頼する。
かかる正誤判定処理によれば、サーバ３００の正誤判定部３７０は、アラート情報の登
録依頼があると、アラートテーブル３２０にアラート情報を登録する。また、正誤判定部３７０は、判定結果通知に係るイベントがルールに適合し、かつ、イベントのアラート情報がアラートテーブル３２０に登録されていれば、リアルタイム判定部３４０による判定は正しかったと判断して、アラートテーブル３２０からアラート情報を削除する。正誤判定部３７０は、判定結果通知に係るイベントがルールに適合し、かつ、イベントのアラート情報がアラートテーブル３２０に登録されていなければ、アラート通知がなされていないと判断して、通知部３８０にアラート通知を依頼する。正誤判定部３７０は、判定結果通知に係るイベントがルールに適合しておらず、かつ、イベントのアラート情報がアラートテーブル３２０に登録されていれば、リアルタイム判定部３４０による判定は間違っていたと判断して、通知部３８０に誤報訂正通知を依頼する。
【００４８】
図１６は、リアルタイム判定部３４０からアラート通知の依頼、又は、正誤判定部３７０からアラート通知若しくは誤報訂正通知の依頼があったことを契機として、サーバ３００の通知部３８０が実行する通知処理の一例を示す。
【００４９】
ステップ６１では、通知部３８０が、アラート通知依頼又は誤報訂正通知依頼に含まれる通知先、通知方法及び通知内容に対応した、図１７に示すようなメッセージを生成する。ここで、メッセージは、図１７に示すように、送信先（Ｔｏ）、送信元（Ｆｒｏｍ）、時刻（Ｄａｔｅ）及び本体（Ｂｏｄｙ）を含む。
【００５０】
ステップ６２では、通知部３８０が、通知依頼に含まれる通知方法に応じた手段を使用して、ステップ６１で生成したメッセージをユーザの携帯電話４００に送信する。
かかる通知処理によれば、サーバ３００の通知部３８０は、アラート通知又は誤報訂正通知の依頼に応じたメッセージをユーザの携帯電話４００に送信する。
【００５１】
従って、かかるイベント処理装置によれば、イベント発生源１００からサーバ３００に到着したイベントは、リアルタイム（到着順）に処理されると共に、所定時間蓄積される。また、所定時間蓄積されたイベントは、発生順に整列され、正しい順序で処理される。そして、リアルタイムに処理された結果と発生順に処理された結果とが比較され、これらが異なる場合には、リアルタイムに処理された結果が間違っていたことを訂正する誤報訂正通知が送信される。このため、例えば、リアルタイム処理において警備会社に誤って通報されても、その後に誤報訂正通知が送信されるので、ユーザが通報は間違いであることを連絡する必要がなく、また、警備会社がユーザ宅に駆けつける必要がなくなる。
【００５２】
［第２実施形態］
第２実施形態では、第１実施形態に係る情報システムにおいて、ユーザの携帯電話４００に送信されるメッセージ（アラート通知）に、過去の実績から求められたアラート通知の確度（アラート通知が正しい確率）が付加される。なお、第２実施形態に係る情報システムは、先の第１実施形態に係る情報システムと大部分共通しているので、第１実施形態と異なる部分についてのみ説明する（以下同様）。
【００５３】
ここでは、正誤判定部３７０が、アラート通知が正しい確率を演算し、リアルタイム判定部３４０が、その確率を参照してアラート通知を依頼する。
サーバ３００のハードディスク３００Ｃに格納されるアラートテーブル３２０は、図１８に示すように、イベントＩＤ、ルールＩＤ及びイベント列に加え、アラート通知が正しい確率と、通知フラグと、を関連付けたアラート情報を保持する。通知フラグには、アラート通知が送信された場合“１”が格納され、アラート通知が送信されない場合“０”が格納される。
【００５４】
図１９は、イベント受信部３３０からイベントが転送されたことを契機として、サーバ３００のリアルタイム判定部３４０が実行するリアルタイム判定処理の他の例を示す。
ステップ７１では、リアルタイム判定部３４０が、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照して、イベントがルールに適合しているか否かを判定する。そして、リアルタイム判定部３４０は、イベントがルールに適合していると判定すれば処理をステップ７２へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理を終了させる（Ｎｏ）。
【００５５】
ステップ７２では、リアルタイム判定部３４０が、ハードディスク３００Ｃに格納されたアラートテーブル３４０を参照し、イベントに含まれるイベントＩＤ及び適合したルールのルールＩＤにより特定されるアラート情報から確率を抽出する。なお、アラート情報の確率が演算されていないときには、この確率を１００％とすればよい。
【００５６】
ステップ７３では、リアルタイム判定部３４０が、通知部３８０にアラート通知を依頼する。ここで、アラート通知依頼は、図２０に示すように、メッセージタイプ、通知先、通知方法、通知内容及び確率を含む。
【００５７】
ステップ７４では、リアルタイム処理部３４０が、正誤判定部３７０にアラート情報の登録を依頼する。
かかるリアルタイム判定処理によれば、先の第１実施形態の作用に加え、サーバ３００のリアルタイム判定部３４０は、イベントがルールに適合していれば、通知部３８０に依頼するアラート通知に確率を付加することができる。
【００５８】
図２１は、リアルタイム判定部３４０からアラート情報の登録依頼、又は、バッチ判定部３６０から判定結果の通知があったことを契機として、サーバ３００の正誤判定部３７０が実行する正誤判定処理の他の例を示す。
【００５９】
ステップ８１では、正誤判定部３７０が、アラート情報の登録依頼であるか否かを判定する。そして、正誤判定部３７０は、アラート情報の登録依頼であると判定すれば処理をステップ８２へと進める一方（Ｙｅｓ）、アラート情報の登録依頼でないと判定すれば処理をステップ８３へと進める（Ｎｏ）。
【００６０】
ステップ８２では、正誤判定部３７０が、アラート情報の登録依頼に含まれるイベントＩＤ、ルールＩＤ、確率、イベント列及び通知フラグを関連付けたアラート情報を生成し、このアラート情報をハードディスク３００Ｃに格納されたアラートテーブル３２０に登録する。ここで、アラート情報において、確率は空欄、通知フラグは“０”とする。
【００６１】
ステップ８３では、正誤判定部３７０が、判定結果通知に含まれる判定結果を参照することで、判定結果通知に係るイベントがルールに適合しているか否かを判定する。そして、正誤判定部３７０は、イベントがルールに適合していると判定すれば処理をステップ８４へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理をステップ８８へと進める（Ｎｏ）。
【００６２】
ステップ８４では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、アラート情報が登録されていると判定すれば処理をステップ８６へと進める一方（Ｙｅｓ）、アラート情報が登録されていないと判定すれば処理をステップ８５へと進める（Ｎｏ）。
【００６３】
ステップ８５では、正誤判定部３７０が、通知部３８０にアラート通知を依頼する。
ステップ８６では、正誤判定部３７０が、判定結果通知に係るイベントについて、次に
示す演算式から、アラート通知が正しかった確率を演算する。
【００６４】
確率＝（正誤判定部３７０で誤報訂正通知が通知されなかった回数）／
（リアルタイム判定部３４０でアラート通知が通知された回数）×１００
ステップ８７では、正誤判定部３７０が、判定結果通知に係るイベントのアラート情報について、ハードディスク３００Ｃに格納されたアラートテーブル３２０の確率を更新する。
【００６５】
ステップ８８では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、イベントのアラート情報が登録されていると判定すれば処理をステップ８９へと進める一方（Ｙｅｓ）、イベントのアラート情報が登録されていないと判定すれば処理を終了させる（Ｎｏ）。
【００６６】
ステップ８９では、正誤判定部３７０が、通知部３８０に誤報訂正通知を依頼し、その後処理をステップ８６へと戻す。
かかる正誤判定処理によれば、サーバ３００の正誤判定部３７０は、アラート情報の登録依頼があると、アラートテーブル３２０にアラート情報を登録する。また、正誤判定部３７０は、判定結果通知に係るイベントがルールに適合し、かつ、イベントのアラート情報がアラートテーブル３２０に登録されていなければ、アラート通知がなされていないと判断して、通知部３８０にアラート通知を依頼する。正誤判定部３７０は、判定結果に係るイベントがルールに適合しておらず、かつ、イベントのアラート情報がアラートテーブル３２０に登録されていれば、リアルタイム判定部３４０による判定は間違っていたと判断して、通知部３８０に誤報訂正通知を依頼する。さらに、正誤判定部３７０は、判定結果通知に係るイベントのアラート情報について、アラート通知が正しい確率を演算し、アラートテーブル３２０の確率を更新する。
【００６７】
従って、かかるイベント処理装置によれば、過去の実績に応じて、アラート通知が正しい確率が演算され、これがユーザへのアラート通知に付加される。このため、ユーザは、図２２に示すような、アラート通知に付加された確率を参照することで、そのアラート通知がどの位正しいものかを把握することができる。
【００６８】
なお、リアルタイム判定部３４０は、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、イベントに係るアラート情報の確率が所定の閾値以下であるとき、通知部３８０にアラート通知を依頼しないようにしてもよい。このようにすれば、確度が低いアラート通知がユーザに通知されることを抑制できる。
【００６９】
［第３実施形態］
第３実施形態では、第１実施形態又は第２実施形態に係る情報システムにおいて、イベント発生源１００からサーバ３００に到着したイベントを所定時間蓄積した後、発生順に整列させてルールに適合するか否かを判定する効率を向上させる。なお、以下の説明では、第１実施形態に係る情報システムを前提とするが、第２実施形態に係る情報システムを前提としてもよい。
【００７０】
ここでは、バッチ判定部３６０は、正誤判定部３７０からのＩＤ登録依頼又はＩＤ削除依頼に応答してメモリ３００ＡにＩＤ情報を登録又は削除する。ＩＤ登録依頼及びＩＤ削除依頼は、図２３及び図２４に示すように、メッセージタイプ、イベントＩＤ及びルールＩＤを含む。また、バッチ判定部３６０は、イベントのＩＤ情報がメモリ３００Ａに登録されているときのみ、正誤判定部３７０に判定結果を通知する。一方、正誤判定部３７０は、バッチ判定部３６０にＩＤ情報の登録又は削除を依頼する。
【００７１】
図２５は、イベント整列部３５０からイベントが転送され、又は、正誤判定部３７０からＩＤ登録若しくはＩＤ削除の依頼があったことを契機として、サーバ３００のバッチ判定部３６０が実行するバッチ判定処理の他の例を示す。
【００７２】
ステップ９１では、バッチ判定部３６０が、例えば、イベント又はＩＤ登録依頼若しくはＩＤ削除依頼のメッセージタイプを参照することで、ＩＤ登録依頼であるか否かを判定する。そして、バッチ判定部３６０は、ＩＤ登録依頼であると判定すれば処理をステップ９２へと進める一方（Ｙｅｓ）、ＩＤ登録依頼でないと判定すれば処理をステップ９３へと進める（Ｎｏ）。
【００７３】
ステップ９２では、バッチ判定部３６０が、ステップ９１と同様な方法で、ＩＤ登録依頼に含まれるイベントＩＤ及びルールＩＤを関連付けたＩＤ情報を生成し、このＩＤ情報をメモリ３００Ａに登録させる。
【００７４】
ステップ９３では、バッチ判定部３６０が、例えば、メッセージを解析することで、ＩＤ削除依頼であるか否かを判定する。そして、バッチ判定部３６０は、ＩＤ削除依頼であると判定すれば処理をステップ９４へと進める一方（Ｙｅｓ）、ＩＤ削除依頼でないと判定すれば処理をステップ９５へと進める（Ｎｏ）。
【００７５】
ステップ９４では、バッチ判定部３６０が、ＩＤ削除依頼からイベントＩＤ及びルールＩＤを抽出し、このイベントＩＤ及びルールＩＤにより特定されるＩＤ情報をメモリ３００から削除する。
【００７６】
ステップ９５では、バッチ判定部３６０が、ハードディスク３００Ｃに格納されたルールテーブル３１０を参照して、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部３６０は、イベントがルールに適合していると判定すれば処理をステップ９６へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理をステップ９９へと進める（Ｎｏ）。
【００７７】
ステップ９６では、バッチ判定部３６０が、イベントに含まれるイベントＩＤ及び適合したルールのルールＩＤにより特定されるＩＤ情報がメモリ３００Ａに登録されているか否かを判定する。そして、バッチ判定部３６０は、ＩＤ情報がメモリ３００Ａに登録されていると判定すれば処理をステップ９７へと進める一方（Ｙｅｓ）、ＩＤ情報がメモリ３００Ａに登録されていないと判定すれば処理をステップ９８へと進める（Ｎｏ）。
【００７８】
ステップ９７では、バッチ判定部３６０が、正誤判定部３７０にイベントがルールに適合することを知らせる判定結果を通知する。
ステップ９８では、バッチ判定部３６０が、通知部３８０にアラート通知を依頼する。
【００７９】
ステップ９９では、バッチ判定部３６０が、イベントに含まれるイベントＩＤ及びアラート通知に係るルールＩＤにより特定されるＩＤ情報がメモリ３００Ａに登録されているか否かを判定する。そして、バッチ判定部３６０は、ＩＤ情報がメモリ３００Ａに登録されていると判定すれば処理をステップ１００へと進める一方（Ｙｅｓ）、ＩＤ情報がメモリ３００Ａに登録されていないと判定すれば処理を終了させる（Ｎｏ）。
【００８０】
ステップ１００では、バッチ判定部３６０が、正誤判定部３７０にイベントがルールに適合しないことを知らせる判定結果を通知する。
かかるバッチ判定処理によれば、サーバ３００のバッチ判定部３６０は、正誤判定部３７０からＩＤ登録依頼又はＩＤ削除依頼があると、メモリ３００ＡにＩＤ情報を登録又は
削除する。また、バッチ判定部３６０は、発生順に整列された各イベントについて、リアルタイム判定処理と同一のルールテーブル３１０に基いて、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部３６０は、イベントがルールに適合しているか否かにかかわらず、正誤判定部３７０に判定結果を通知すると共に、イベントがルールに適合し、かつ、ＩＤ情報がメモリ３００Ａに登録されていれば、通知部３８０に誤報訂正通知を依頼する。
【００８１】
図２６は、リアルタイム判定部３４０からアラート情報の登録依頼、又は、バッチ判定部３６０から判定結果の通知があったことを契機として、サーバ３００の正誤判定部３７０が実行する正誤判定処理の他の例を示す。
【００８２】
ステップ１０１では、正誤判定部３７０が、例えば、登録依頼又は判定結果通知のメッセージタイプを参照することで、アラート情報の登録依頼であるか否かを判定する。そして、正誤判定部３７０は、アラート情報の登録依頼であると判定すれば処理をステップ１０２へと進める一方（Ｙｅｓ）、アラート情報の登録依頼でないと判定すれば処理をステップ１０４へと進める（Ｎｏ）。
【００８３】
ステップ１０２では、正誤判定部３７０が、アラート情報の登録依頼に含まれるイベントＩＤ、ルールＩＤ及びイベント列を関連付けたアラート情報を生成し、このアラート情報をハードディスク３００Ｃに格納されたアラートテーブル３２０に登録する。
【００８４】
ステップ１０３では、正誤判定部３７０が、アラート情報の登録依頼に含まれるイベントＩＤ及びルールＩＤについて、バッチ判定部３６０にＩＤ情報の登録を依頼する。
ステップ１０４では、正誤判定部３７０が、判定結果通知に含まれる判定結果を参照することで、判定結果通知に係るイベントがルールに適合しているか否かを判定する。そして、正誤判定部３７０は、イベントがルールに適合していると判定すれば処理をステップ１０５へと進める一方（Ｙｅｓ）、イベントがルールに適合していないと判定すれば処理をステップ１０９へと進める（Ｎｏ）。
【００８５】
ステップ１０５では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、アラート情報が登録されていると判定すれば処理をステップ１０６へと進める一方（Ｙｅｓ）、アラート情報が登録されていないと判定すれば処理をステップ１０８へと進める（Ｎｏ）。
【００８６】
ステップ１０６では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０から、判定結果通知に係るイベントのアラート情報を削除する。
ステップ１０７では、正誤判定部３７０が、判定結果通知に含まれるイベントＩＤ及びルールＩＤについて、バッチ判定部３６０にＩＤ情報の削除を依頼する。
【００８７】
ステップ１０８では、正誤判定部３７０が、通知部３８０にアラート通知を依頼する。
ステップ１０９では、正誤判定部３７０が、ハードディスク３００Ｃに格納されたアラートテーブル３２０を参照し、判定結果通知に含まれるイベントＩＤ及びルールＩＤにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部３７０は、アラート情報が登録されていると判定すれば処理をステップ１１０へと進める一方（Ｙｅｓ）、アラート情報が登録されていないと判定すれば処理を終了させる（Ｎｏ）。
【００８８】
ステップ１１０では、正誤判定部３７０が、通知部３８０に誤報訂正通知を依頼する。
ステップ１１１では、正誤判定部３７０が、判定結果通知に含まれるイベントＩＤ及び
ルールＩＤについて、バッチ判定部３６０にＩＤ情報の削除を依頼する。
【００８９】
かかる正誤判定処理によれば、サーバ３００の正誤判定部３７０は、アラート情報の登録依頼があると、アラートテーブル３２０にアラート情報を登録すると共に、バッチ判定部３６０にＩＤ情報の登録を依頼する。また、正誤判定部３７０は、判定結果通知に係るイベントがルールに適合し、かつ、アラート情報がアラートテーブル３２０に登録されていれば、アラートテーブル３２０からアラート情報を削除すると共に、バッチ判定部３６０にＩＤ情報の削除を依頼する。正誤判定部３７０は、判定結果通知に係るイベントがルールに適合し、かつ、アラート情報がアラートテーブル３２０に登録されていなければ、通知部３８０にアラート通知を依頼する。正誤判定部３７０は、判定結果通知に係るイベントがルールに適合しておらず、かつ、アラート情報がアラートテーブル３２０に登録されていれば、通知部３８０に誤報訂正通知を依頼すると共に、バッチ判定部３６０にＩＤ情報の削除を依頼する。
【００９０】
従って、バッチ判定部３６０は、ＩＤ情報がメモリ３００Ａに登録されているときに、正誤判定部３７０に判定結果を通知することとなる。このため、正誤判定部３７０は、リアルタイム判定処理における判定結果をすべて再確認する必要がなく、判定効率を向上させることができる。
【００９１】
ここで、イベント処理装置の作用・効果の理解を容易ならしめるために、具体的な事例を想定した実施例について説明する。
実施例の前提として、次のような条件を想定する。
【００９２】
（１）イベントに適用するルールは、「ユーザの外出中に人感センサが人間の所在を感知すると、警備会社に不審者侵入を通報する」とする。
（２）人感センサは、人間の所在を感知すると同時に、イベントをサーバ３００に通知する。
（３）ＧＰＳレシーバを内蔵した携帯電話４００は、定期的（例えば１分ごと）にユーザの位置情報をサーバ３００に通知する。
ユーザが外出から帰宅したとき、携帯電話４００から位置情報が通知される前に、人感センサによりユーザの所在が感知されたことを考える。この場合、図２７に示すように、人感センサからサーバ３００にイベントが通知されると（手順１）、イベント受信部３３０は、このイベントをリアルタイム判定部３４０及びイベント整列部３５０に夫々転送する（手順２、３）。イベントが転送されたリアルタイム判定部３４０は、ハードディスク３００Ｃのルールテーブル３１０を参照し、ユーザの外出中に人感センサが人間の所在を感知したというルールに適合すると判定する。そして、リアルタイム判定部３４０は、通知部３８０にアラート通知を依頼すると共に（手順４）、正誤判定部３７０にアラート情報の登録を依頼する（手順５）。また、イベントが転送されたイベント整列部３５０は、メモリ３００Ａにイベントを蓄積する。アラート通知の依頼を受けた通知部３８０は、警備会社にアラート（不審者侵入）を通知する（手順６）。また、アラート情報の登録依頼を受けた正誤判定部３７０は、ハードディスク３００Ｃのアラートテーブル３２０にアラート情報を登録する。
【００９３】
この状態において、ユーザの携帯電話４００からサーバ３００にイベントが通知されると（手順７）、イベント受信部３３０は、このイベントをリアルタイム判定部３４０及びイベント整列部３５０に夫々転送する（手順８、９）。イベントが転送されたイベント整列部３５０は、イベントの蓄積を開始してから所定時間経過したとき、発生順にイベントを整列してバッチ判定部３６０に順次転送する（手順１０）。イベントが転送されたバッチ判定部３６０は、ハードディスク３００Ｃのルールテーブル３１０を参照し、ユーザの
外出中に人感センサが人間の所在を感知したというルールに適合しないと判定する。そして、バッチ判定部３６０は、正誤判定部３７０に判定結果を通知する（手順１１）。判定結果を受けた正誤判定部３７０は、イベントがルールに適合しておらず、かつ、アラートテーブル３２０にアラート情報が登録されているため、先程通知したアラートは間違いであったと判断し、通知部３８０に誤報訂正通知を依頼する（手順１２）。誤報訂正通知を受けた通知部３８０は、警備会社に誤報訂正を通知する（手順１３）。
【００９４】
従って、サーバ３００から警備会社に誤ってアラートが通知されても、このアラートが間違いであったことを示す誤報訂正通知が通知されるので、警備会社はユーザ宅に駆けつける必要がなくなる。また、ユーザは、警備会社にアラート通知が間違いであったことを連絡する必要がなく、手間を軽減することができる。
【符号の説明】
【００９５】
１００ イベント発生源
３００ サーバ
３００Ａ メモリ
３００Ｂ プロセッサ
３００Ｃ ハードディスク
３１０ ルールテーブル
３４０ リアルタイム判定部
３５０ イベント整列部
３６０ バッチ判定部
３７０ 正誤判定部
３８０ 通知部
【特許請求の範囲】
【請求項１】
イベントを処理するためのルールが格納された記憶部を備えたコンピュータが、
前記記憶部に格納されたルールに基いて、情報源から到着したイベントを到着順に処理すると共に、所定時間蓄積したイベントを発生順に処理し、
前記到着順にイベントを処理した結果を送信し、
前記送信した結果を前記記憶部に記憶し、
前記記憶した結果と前記発生順にイベントを処理した結果とが異なっている場合に、前記発生順にイベントを処理した結果を送信する、
イベント処理方法。
【請求項２】
前記ルールは、所定の条件が成立した場合にアラートを通知するものであって、
前記コンピュータは、前記到着順にイベントを処理した結果と前記発生順にイベントを処理した結果との比較結果に基いて、前記到着順にイベントを処理した結果が正しかった確率を演算し、前記アラートに前記確率を含ませる、
請求項１に記載のイベント処理方法。
【請求項３】
前記コンピュータは、前記確率が所定値より大きい場合に、前記アラートを通知する、
請求項２に記載のイベント処理方法。
【請求項４】
前記記憶部は、前記到着順に処理したイベントの情報を更に格納し、
前記コンピュータは、前記記憶部に格納されているイベントについて、前記到着順にイベントを処理した結果と前記発生順にイベントを処理した結果とを比較する一方、前記記憶部に格納されていないイベントについて、前記ルールに基いて処理する、
請求項１〜請求項３のいずれか１つに記載のイベント処理方法。
【請求項５】
前記コンピュータは、前記記憶した結果と前記発生順にイベントを処理した結果とが異なっている場合に、前記到着順にイベントを処理した結果の訂正通知を送信する、
請求項１〜請求項４のいずれか１つに記載のイベント処理方法。
【請求項６】
イベントを処理するためのルールが格納された記憶部と、
前記記憶部に格納されたルールに基いて、情報源から到着したイベントを到着順に処理する第１の処理手段と、
前記情報源から到着したイベントを所定時間格納し、前記記憶部に格納されたルールに基いて、発生順にイベントを処理する第２の処理手段と、
前記第１の処理手段による処理結果を前記記憶部に記憶し、前記記憶した処理結果と前記第２の処理手段による処理結果とが異なっている場合に、前記第２の処理手段による処理結果を送信する送信手段と、
を有するイベント処理装置。
【請求項７】
イベントを処理するためのルールが格納された記憶部を備えたコンピュータのプロセッサに、
前記記憶部に格納されたルールに基いて、情報源から到着したイベントを到着順に処理し、
前記情報源から到着したイベントを所定時間格納し、前記記憶部に格納されたルールに基いて、発生順にイベントを処理し、
前記到着順にイベントを処理した結果を送信し、
前記送信した結果を前記記憶部に記憶し、
前記記憶した結果と前記発生順にイベントを処理した結果とが異なっている場合に、前記発生順にイベントを処理した結果を送信する、
処理を実行させるためのイベント処理プログラム。
【請求項１】
イベントを処理するためのルールが格納された記憶部を備えたコンピュータが、
前記記憶部に格納されたルールに基いて、情報源から到着したイベントを到着順に処理すると共に、所定時間蓄積したイベントを発生順に処理し、
前記到着順にイベントを処理した結果を送信し、
前記送信した結果を前記記憶部に記憶し、
前記記憶した結果と前記発生順にイベントを処理した結果とが異なっている場合に、前記発生順にイベントを処理した結果を送信する、
イベント処理方法。
【請求項２】
前記ルールは、所定の条件が成立した場合にアラートを通知するものであって、
前記コンピュータは、前記到着順にイベントを処理した結果と前記発生順にイベントを処理した結果との比較結果に基いて、前記到着順にイベントを処理した結果が正しかった確率を演算し、前記アラートに前記確率を含ませる、
請求項１に記載のイベント処理方法。
【請求項３】
前記コンピュータは、前記確率が所定値より大きい場合に、前記アラートを通知する、
請求項２に記載のイベント処理方法。
【請求項４】
前記記憶部は、前記到着順に処理したイベントの情報を更に格納し、
前記コンピュータは、前記記憶部に格納されているイベントについて、前記到着順にイベントを処理した結果と前記発生順にイベントを処理した結果とを比較する一方、前記記憶部に格納されていないイベントについて、前記ルールに基いて処理する、
請求項１〜請求項３のいずれか１つに記載のイベント処理方法。
【請求項５】
前記コンピュータは、前記記憶した結果と前記発生順にイベントを処理した結果とが異なっている場合に、前記到着順にイベントを処理した結果の訂正通知を送信する、
請求項１〜請求項４のいずれか１つに記載のイベント処理方法。
【請求項６】
イベントを処理するためのルールが格納された記憶部と、
前記記憶部に格納されたルールに基いて、情報源から到着したイベントを到着順に処理する第１の処理手段と、
前記情報源から到着したイベントを所定時間格納し、前記記憶部に格納されたルールに基いて、発生順にイベントを処理する第２の処理手段と、
前記第１の処理手段による処理結果を前記記憶部に記憶し、前記記憶した処理結果と前記第２の処理手段による処理結果とが異なっている場合に、前記第２の処理手段による処理結果を送信する送信手段と、
を有するイベント処理装置。
【請求項７】
イベントを処理するためのルールが格納された記憶部を備えたコンピュータのプロセッサに、
前記記憶部に格納されたルールに基いて、情報源から到着したイベントを到着順に処理し、
前記情報源から到着したイベントを所定時間格納し、前記記憶部に格納されたルールに基いて、発生順にイベントを処理し、
前記到着順にイベントを処理した結果を送信し、
前記送信した結果を前記記憶部に記憶し、
前記記憶した結果と前記発生順にイベントを処理した結果とが異なっている場合に、前記発生順にイベントを処理した結果を送信する、
処理を実行させるためのイベント処理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【公開番号】特開２０１２−１９４８０６（Ｐ２０１２−１９４８０６Ａ）
【公開日】平成２４年１０月１１日（２０１２．１０．１１）
【国際特許分類】
【出願番号】特願２０１１−５８４５９（Ｐ２０１１−５８４５９）
【出願日】平成２３年３月１６日（２０１１．３．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２４年１０月１１日（２０１２．１０．１１）
【国際特許分類】
【出願日】平成２３年３月１６日（２０１１．３．１６）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]