イベントを処理するためのルールが格納された記憶部を備えたコンピュータが、前記記憶部に格納されたルールに基いて、情報源から到着したイベントを到着順に処理すると共に、所定時間蓄積したイベントを発生順に処理し、前記到着順にイベントを処理した結果を送信し、前記送信した結果を前記記憶部に記憶し、前記記憶した結果と前記発生順にイベントを処理した結果とが異なっている場合に、前記発生順にイベントを処理した結果を送信する、イベント処理方法。前記ルールは、所定の条件が成立した場合にアラートを通知するものであって、前記コンピュータは、前記到着順にイベントを処理した結果と前記発生順にイベントを処理した結果との比較結果に基いて、前記到着順にイベントを処理した結果が正しかった確率を演算し、前記アラートに前記確率を含ませる、請求項1に記載のイベント処理方法。前記コンピュータは、前記確率が所定値より大きい場合に、前記アラートを通知する、請求項2に記載のイベント処理方法。前記記憶部は、前記到着順に処理したイベントの情報を更に格納し、前記コンピュータは、前記記憶部に格納されているイベントについて、前記到着順にイベントを処理した結果と前記発生順にイベントを処理した結果とを比較する一方、前記記憶部に格納されていないイベントについて、前記ルールに基いて処理する、請求項1~請求項3のいずれか1つに記載のイベント処理方法。前記コンピュータは、前記記憶した結果と前記発生順にイベントを処理した結果とが異なっている場合に、前記到着順にイベントを処理した結果の訂正通知を送信する、請求項1~請求項4のいずれか1つに記載のイベント処理方法。イベントを処理するためのルールが格納された記憶部と、前記記憶部に格納されたルールに基いて、情報源から到着したイベントを到着順に処理する第1の処理手段と、前記情報源から到着したイベントを所定時間格納し、前記記憶部に格納されたルールに基いて、発生順にイベントを処理する第2の処理手段と、前記第1の処理手段による処理結果を前記記憶部に記憶し、前記記憶した処理結果と前記第2の処理手段による処理結果とが異なっている場合に、前記第2の処理手段による処理結果を送信する送信手段と、を有するイベント処理装置。イベントを処理するためのルールが格納された記憶部を備えたコンピュータのプロセッサに、前記記憶部に格納されたルールに基いて、情報源から到着したイベントを到着順に処理し、前記情報源から到着したイベントを所定時間格納し、前記記憶部に格納されたルールに基いて、発生順にイベントを処理し、前記到着順にイベントを処理した結果を送信し、前記送信した結果を前記記憶部に記憶し、前記記憶した結果と前記発生順にイベントを処理した結果とが異なっている場合に、前記発生順にイベントを処理した結果を送信する、処理を実行させるためのイベント処理プログラム。従来技術においては、イベントを発生順に処理することが可能となるが、イベントを待ち時間の間蓄積するためにリアルタイムにイベントが処理されなくなってしまう、という問題点がある。リアルタイムにイベントが処理されなくなってしまうと、例えば、ユーザの外出中に、人感センサが人間の所在を感知して警備会社に通報しても、警備会社がユーザ宅に駆けつける時間が遅くなるなどの不具合が発生してしまう。そこで、本発明は従来技術の問題点に鑑み、情報源から到着したイベントを到着順に処理した結果を必要に応じて訂正できるようにした、イベント処理方法、イベント処理装置及びイベント処理プログラムを提供することを目的とする。コンピュータが、イベントを処理するためのルールが格納された記憶部を参照し、情報源から到着したイベントを到着順に処理すると共に、所定時間蓄積したイベントを発生順に処理する。そして、コンピュータが、到着順にイベントを処理した結果を送信して記憶部に記憶し、記憶した結果と発生順にイベントを処理した結果とが異なっている場合に、発生順にイベントを処理した結果を送信する。情報源から到着したイベントを到着順に処理した結果を必要に応じて訂正することができる。以下、添付された図面を参照し、本発明を実施するための実施形態について詳細に説明する。[第1実施形態]図1は、第1実施形態に係る情報システムの一例を示す。各種情報源としてのイベント発生源100は、インターネットなどのネットワーク200を介して、各種サービスを提供するサービス業者のサーバ300に接続される。ここで、イベント発生源100としては、例えば、人間の所在を感知する人感センサ、人間の位置情報を測位するGPSGlobalPositioningSystemレシーバ、住宅の施錠状態を検知する施錠センサなどがある。各種サービスを提供するサービス業者としては、例えば、ユーザの住宅を警備する警備会社などがある。また、ネットワーク200には、サーバ300から各種通知を受信するためのデバイスの一例として、例えば、ユーザの携帯電話400が接続される。サーバ300は、図2に示すように、メモリ300A、CPUCentralProcessingUnitなどのプロセッサ300B、ハードディスク300C、ドライブ装置300D及び通信装置300Eを含んだコンピュータである。メモリ300A、プロセッサ300B、ハードディスク300C、ドライブ装置300D及び通信装置300Eは、シリアルATAATAttachmentなどのバス300Fにより相互に接続される。ハードディスク300Cは、記憶部として機能する。ドライブ装置300Dは、例えば、CD-ROMCompactDiskReadOnlyMemory、DVD-ROMDigitalVersatileDiskReadOnlyMemoryなどのリムーバブルディスク300Gからデータを読み込む。リムーバブルディスク300Gに代えて、フラッシュメモリを内蔵したUSBUniversalSerialBusメモリなどを使用することもできる。通信装置300Eは、バス300Fとネットワーク200とを接続する、例えば、NICNetworkInterfaceCardなどである。サーバ300のハードディスク300Cは、図3に示すように、ルールテーブル310と、アラートテーブル320と、を夫々格納する。ルールテーブル310は、イベント発生源100からサーバ300に到着したイベントに適用するルールを規定するためのテーブルであって、図4に示すように、ルールを識別するルールIDIdentifierと、具体的なルールと、を関連付けたルール情報を保持する。ここで、ルールは、例えば、SQLStructuredQueryLanguageなどの専用の言語で記述される。なお、図4において、ルールIDがrule001のルールでは、ユーザの外出中にlocationhome、人感センサが人間の所在を感知するとmotionsensoreventtrue、idの情報を警備会社とidにより特定されるユーザに通知するというイベントが規定されている。アラートテーブル320は、サーバ300から携帯電話400に通知されたアラートを記憶するテーブルであって、図5に示すように、イベントを識別するイベントIDと、ルールを識別するルールIDと、処理したイベントの順番を示すイベント列と、を関連付けたアラート情報を保持する。サーバ300のプロセッサ300Bは、メモリ300Aに展開されたイベント処理プログラムを実行することで、図3に示すように、イベント受信部330と、リアルタイム判定部340と、イベント整列部350と、バッチ判定部360と、正誤判定部370と、通知部380と、を具現化する。イベント受信部330は、イベント発生源100からイベントが到着したことを契機として、到着したイベントをリアルタイム判定部340とイベント整列部350とに夫々転送する。リアルタイム判定部340は、イベント受信部330からイベントが転送されたことを契機として、ハードディスク300Cに格納されたルールテーブル310を参照し、イベントがルールに適合しているか否かを判定する。また、リアルタイム判定部340は、イベントがルールに適合していると判定すれば、正誤判定部370にアラート情報の登録を依頼すると共に、通知部380にアラートの通知を依頼する。なお、リアルタイム判定部340は、処理速度を向上させるために、起動時などに、ハードディスク300Cからルールテーブル310をメモリ300Aに読み込むようにしてもよい以下同様。この場合、メモリ300Aが記憶部の一例として挙げられる。イベント整列部350は、イベント受信部330からイベントが転送されたことを契機として、イベントをメモリ300Aに所定時間蓄積バッファリングした後、このイベントを発生順に整列する。そして、イベント整列部350は、発生順に整列したイベントをバッチ判定部360に順次転送する。ここで、イベントを蓄積する所定時間は、例えば、背景技術で引用した特開平9-244984号公報で提案された技術など、公知の技術を用いて適宜決定すればよい。バッチ判定部360は、イベント整列部350からイベントが転送されたことを契機として、ハードディスク300Cに格納されたルールテーブル310を参照し、イベントがルールに適合しているか否かを判定する。また、バッチ判定部360は、正誤判定部370に判定結果を通知する。正誤判定部370は、リアルタイム判定部340からアラート情報の登録依頼があったことを契機として、ハードディスク300Cに格納されたアラートテーブル320にアラート情報を登録する。また、正誤判定部370は、バッチ判定部370から判定結果の通知があったことを契機として、アラートテーブル320からアラート情報の削除、又は、通知部380へアラート通知若しくは誤報訂正通知を依頼する。なお、リアルタイム判定部340は、第1の処理手段に該当する。また、イベント整列部350及びバッチ判定部360は、第2の処理手段に該当する。さらに、正誤判定部370及び通知部380は、送信手段に該当する。図6は、イベント発生源100からサーバ300にイベントが到着したことを契機として、サーバ300のイベント受信部330が実行するイベント受信処理の一例を示す。ここで、イベントは、図7に示すように、メッセージタイプ、イベントID、イベントタイプ及びデータを含む。メッセージタイプは、メッセージの種別を識別するための情報を格納する。イベントタイプは、データに格納される情報のタイプを格納する。データは、イベントタイプに対応した情報を格納する。ステップ1図ではS1と略記する。以下同様。では、イベント受信部330が、リアルタイム判定部340にイベントを転送する。ステップ2では、イベント受信部330が、イベント整列部350にイベントを転送する。かかるイベント受信処理によれば、サーバ300のイベント受信部330は、イベント発生源100から到着したイベントをリアルタイム判定部340及びイベント整列部350に夫々転送する。図8は、イベント受信部330からイベントが転送されたことを契機として、サーバ300のリアルタイム判定部340が実行するリアルタイム判定処理の一例を示す。ステップ11では、リアルタイム判定部340が、ハードディスク300Cに格納されたルールテーブル310を参照して、イベントがルールに適合しているか否かを判定する。そして、リアルタイム判定部340は、イベントがルールに適合していると判定すれば処理をステップ12へと進める一方Yes、イベントがルールに適合していないと判定すれば処理を終了させるNo。ステップ12では、リアルタイム判定部340が、ユーザの携帯電話400にアラートを送信するために、通知部380にアラート通知を依頼する。ここで、アラート通知依頼は、図9に示すように、メッセージタイプ、通知先、通知方法及び通知内容を含む。なお、通知先及び通知方法は、例えば、ユーザによって前もって指定される以下同様。ステップ13では、リアルタイム判定部340が、ハードディスク300Cに格納されたアラートテーブル320を更新するために、正誤判定部370にアラート情報の登録を依頼する。ここで、アラート情報登録依頼は、図10に示すように、メッセージタイプ、イベントのイベントID、適合したルールのルールID及び適合したイベントの順序を示すイベント列を含む。かかるリアルタイム判定処理によれば、サーバ300のリアルタイム判定部340は、イベントがルールに適合していれば、通知部380にアラート通知を依頼すると共に、正誤判定部370にアラート情報の登録を依頼する。図11は、イベント受信部330からイベントが転送されたことを契機として、サーバ300のイベント整列部350が実行するイベント整列処理の一例を示す。ステップ21では、イベント整列部350が、イベントをメモリ300Aに蓄積する。ステップ22では、イベント整列部350が、例えば、タイマー機能を利用して、タイマーがスタートしているか否かを判定する。そして、イベント整列部350は、タイマーがスタートしていると判定すれば処理を終了させる一方Yes、タイマーがスタートしていないと判定すれば処理をステップ23へと進めるNo。ステップ23では、イベント整列部350が、タイマーをスタートさせる。図12は、イベント受信部330からイベントが転送されたことを契機として、図11に示すイベント整列処理と並行して、サーバ300のイベント整列部350が実行するイベント整列処理の一例を示す。ステップ31では、イベント整列部350が、イベントの蓄積を開始してから所定時間が経過したか否かを判定する。そして、イベント整列部350は、イベントの蓄積を開始してから所定時間経過したと判定すれば処理をステップ32へと進める一方Yes、イベントの蓄積を開始してから所定時間経過していないと判定すれば処理を終了させるNo。ステップ32では、イベント整列部350が、メモリ300Aに蓄積したイベントを発生順に整列する。ステップ33では、イベント整列部350が、整列したイベントをバッチ判定部360に順次転送、即ち、イベントを発生順にバッチ判定部360に順次転送する。ステップ34では、イベント整列部350が、メモリ300Aからすべてのイベントを削除する。ステップ35では、イベント整列部350が、タイマーをストップし、リセットする。かかるイベント整列処理によれば、サーバ300のイベント整列部350は、イベント発生源100から到着したイベントを所定時間蓄積し、イベントを発生順にバッチ判定部360に順次転送する。このため、バッチ判定部360は、発生順に整列されたイベントを受け取ることができる。図13は、イベント整列部350からイベントが転送されたことを契機として、サーバ300のバッチ判定部360が実行するバッチ判定処理の一例を示す。ステップ41では、バッチ判定部360が、ハードディスク300Cに格納されたルールテーブル310を参照して、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部360は、イベントがルールに適合していると判定すれば処理をステップ42へと進める一方Yes、イベントがルールに適合していないと判定すれば処理をステップ43へと進めるNo。ステップ42では、バッチ判定部360が、正誤判定部370にイベントがルールに適合することを知らせる判定結果を通知する。ここで、判定結果通知は、図14に示すように、メッセージタイプ、通知先、通知方法、判定結果、イベントID、ルールID、イベント列及び通知内容を含む。判定結果は、ステップ41における判定結果、具体的には、ルールに適合するか、ルールに適合しないかを格納する。通知内容は、ユーザなどに通知する内容を格納する通知する必要がない場合には空欄とする。ステップ43では、バッチ判定部360が、正誤判定部370にイベントがルールに適合しないことを知らせる判定結果を通知する。なお、判定結果通知は、図14に示すメッセージと同様であるので、その説明は省略する。かかるバッチ判定処理によれば、サーバ300のバッチ判定部360は、発生順に整列された各イベントについて、リアルタイム判定処理と同一のルールテーブル310に基いて、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部360は、正誤判定部370に判定結果を通知する。図15は、リアルタイム判定部340からアラート情報の登録依頼、又は、バッチ判定部360から判定結果の通知があったことを契機として、サーバ300の正誤判定部370が実行する正誤判定処理の一例を示す。ステップ51では、正誤判定部370が、例えば、登録依頼又は判定結果通知のメッセージタイプを参照することで、アラート情報の登録依頼であるか否かを判定する。そして、正誤判定部370は、アラート情報の登録依頼であると判定すれば処理をステップ52へと進める一方Yes、アラート情報の登録依頼でないと判定すれば処理をステップ53へと進めるNo。ステップ52では、正誤判定部370が、アラート情報の登録依頼に含まれるイベントID、ルールID及びイベント列を関連付けたアラート情報を生成し、このアラート情報をハードディスク300Cに格納されたアラートテーブル320に登録する。なお、イベントID及びルールIDにより特定されるアラート情報がアラートテーブル320に登録されている場合には、そのイベント列にイベントを追加すればよい以下同様。ステップ53では、正誤判定部370が、判定結果通知に含まれる判定結果を参照することで、判定結果通知に係るイベントがルールに適合しているか否かを判定する。そして、正誤判定部370は、イベントがルールに適合していると判定すれば処理をステップ54へと進める一方Yes、イベントがルールに適合していないと判定すれば処理をステップ57へと進めるNo。ステップ54では、正誤判定部370が、ハードディスク300Cに格納されたアラートテーブル320を参照し、判定結果通知に含まれるイベントID及びルールIDにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部370は、アラート情報が登録されていると判定すれば処理をステップ55へと進める一方Yes、アラート情報が登録されていないと判定すれば処理をステップ56へと進めるNo。ステップ55では、正誤判定部370が、ハードディスク300Cに格納されたアラートテーブル320から、判定結果通知に含まれるイベントID及びルールIDにより特定されるアラート情報を削除する。ステップ56では、正誤判定部370が、通知部380にアラート通知を依頼する。ステップ57では、正誤判定部370が、ハードディスク300Cに格納されたアラートテーブル320を参照し、判定結果通知に含まれるイベントID及びルールIDにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部370は、アラート情報が登録されていると判定すれば処理をステップ58へと進める一方Yes、アラート情報が登録されていないと判定すれば処理を終了させるNo。ステップ58では、正誤判定部370が、送信済みのアラート通知は間違いであったことを訂正する誤報訂正通知を通知部380に依頼する。かかる正誤判定処理によれば、サーバ300の正誤判定部370は、アラート情報の登録依頼があると、アラートテーブル320にアラート情報を登録する。また、正誤判定部370は、判定結果通知に係るイベントがルールに適合し、かつ、イベントのアラート情報がアラートテーブル320に登録されていれば、リアルタイム判定部340による判定は正しかったと判断して、アラートテーブル320からアラート情報を削除する。正誤判定部370は、判定結果通知に係るイベントがルールに適合し、かつ、イベントのアラート情報がアラートテーブル320に登録されていなければ、アラート通知がなされていないと判断して、通知部380にアラート通知を依頼する。正誤判定部370は、判定結果通知に係るイベントがルールに適合しておらず、かつ、イベントのアラート情報がアラートテーブル320に登録されていれば、リアルタイム判定部340による判定は間違っていたと判断して、通知部380に誤報訂正通知を依頼する。図16は、リアルタイム判定部340からアラート通知の依頼、又は、正誤判定部370からアラート通知若しくは誤報訂正通知の依頼があったことを契機として、サーバ300の通知部380が実行する通知処理の一例を示す。ステップ61では、通知部380が、アラート通知依頼又は誤報訂正通知依頼に含まれる通知先、通知方法及び通知内容に対応した、図17に示すようなメッセージを生成する。ここで、メッセージは、図17に示すように、送信先To、送信元From、時刻Date及び本体Bodyを含む。ステップ62では、通知部380が、通知依頼に含まれる通知方法に応じた手段を使用して、ステップ61で生成したメッセージをユーザの携帯電話400に送信する。かかる通知処理によれば、サーバ300の通知部380は、アラート通知又は誤報訂正通知の依頼に応じたメッセージをユーザの携帯電話400に送信する。従って、かかるイベント処理装置によれば、イベント発生源100からサーバ300に到着したイベントは、リアルタイム到着順に処理されると共に、所定時間蓄積される。また、所定時間蓄積されたイベントは、発生順に整列され、正しい順序で処理される。そして、リアルタイムに処理された結果と発生順に処理された結果とが比較され、これらが異なる場合には、リアルタイムに処理された結果が間違っていたことを訂正する誤報訂正通知が送信される。このため、例えば、リアルタイム処理において警備会社に誤って通報されても、その後に誤報訂正通知が送信されるので、ユーザが通報は間違いであることを連絡する必要がなく、また、警備会社がユーザ宅に駆けつける必要がなくなる。[第2実施形態]第2実施形態では、第1実施形態に係る情報システムにおいて、ユーザの携帯電話400に送信されるメッセージアラート通知に、過去の実績から求められたアラート通知の確度アラート通知が正しい確率が付加される。なお、第2実施形態に係る情報システムは、先の第1実施形態に係る情報システムと大部分共通しているので、第1実施形態と異なる部分についてのみ説明する以下同様。ここでは、正誤判定部370が、アラート通知が正しい確率を演算し、リアルタイム判定部340が、その確率を参照してアラート通知を依頼する。サーバ300のハードディスク300Cに格納されるアラートテーブル320は、図18に示すように、イベントID、ルールID及びイベント列に加え、アラート通知が正しい確率と、通知フラグと、を関連付けたアラート情報を保持する。通知フラグには、アラート通知が送信された場合1が格納され、アラート通知が送信されない場合0が格納される。図19は、イベント受信部330からイベントが転送されたことを契機として、サーバ300のリアルタイム判定部340が実行するリアルタイム判定処理の他の例を示す。ステップ71では、リアルタイム判定部340が、ハードディスク300Cに格納されたルールテーブル310を参照して、イベントがルールに適合しているか否かを判定する。そして、リアルタイム判定部340は、イベントがルールに適合していると判定すれば処理をステップ72へと進める一方Yes、イベントがルールに適合していないと判定すれば処理を終了させるNo。ステップ72では、リアルタイム判定部340が、ハードディスク300Cに格納されたアラートテーブル340を参照し、イベントに含まれるイベントID及び適合したルールのルールIDにより特定されるアラート情報から確率を抽出する。なお、アラート情報の確率が演算されていないときには、この確率を100とすればよい。ステップ73では、リアルタイム判定部340が、通知部380にアラート通知を依頼する。ここで、アラート通知依頼は、図20に示すように、メッセージタイプ、通知先、通知方法、通知内容及び確率を含む。ステップ74では、リアルタイム処理部340が、正誤判定部370にアラート情報の登録を依頼する。かかるリアルタイム判定処理によれば、先の第1実施形態の作用に加え、サーバ300のリアルタイム判定部340は、イベントがルールに適合していれば、通知部380に依頼するアラート通知に確率を付加することができる。図21は、リアルタイム判定部340からアラート情報の登録依頼、又は、バッチ判定部360から判定結果の通知があったことを契機として、サーバ300の正誤判定部370が実行する正誤判定処理の他の例を示す。ステップ81では、正誤判定部370が、アラート情報の登録依頼であるか否かを判定する。そして、正誤判定部370は、アラート情報の登録依頼であると判定すれば処理をステップ82へと進める一方Yes、アラート情報の登録依頼でないと判定すれば処理をステップ83へと進めるNo。ステップ82では、正誤判定部370が、アラート情報の登録依頼に含まれるイベントID、ルールID、確率、イベント列及び通知フラグを関連付けたアラート情報を生成し、このアラート情報をハードディスク300Cに格納されたアラートテーブル320に登録する。ここで、アラート情報において、確率は空欄、通知フラグは0とする。ステップ83では、正誤判定部370が、判定結果通知に含まれる判定結果を参照することで、判定結果通知に係るイベントがルールに適合しているか否かを判定する。そして、正誤判定部370は、イベントがルールに適合していると判定すれば処理をステップ84へと進める一方Yes、イベントがルールに適合していないと判定すれば処理をステップ88へと進めるNo。ステップ84では、正誤判定部370が、ハードディスク300Cに格納されたアラートテーブル320を参照し、判定結果通知に含まれるイベントID及びルールIDにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部370は、アラート情報が登録されていると判定すれば処理をステップ86へと進める一方Yes、アラート情報が登録されていないと判定すれば処理をステップ85へと進めるNo。ステップ85では、正誤判定部370が、通知部380にアラート通知を依頼する。ステップ86では、正誤判定部370が、判定結果通知に係るイベントについて、次に示す演算式から、アラート通知が正しかった確率を演算する。確率=正誤判定部370で誤報訂正通知が通知されなかった回数/リアルタイム判定部340でアラート通知が通知された回数×100ステップ87では、正誤判定部370が、判定結果通知に係るイベントのアラート情報について、ハードディスク300Cに格納されたアラートテーブル320の確率を更新する。ステップ88では、正誤判定部370が、ハードディスク300Cに格納されたアラートテーブル320を参照し、判定結果通知に含まれるイベントID及びルールIDにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部370は、イベントのアラート情報が登録されていると判定すれば処理をステップ89へと進める一方Yes、イベントのアラート情報が登録されていないと判定すれば処理を終了させるNo。ステップ89では、正誤判定部370が、通知部380に誤報訂正通知を依頼し、その後処理をステップ86へと戻す。かかる正誤判定処理によれば、サーバ300の正誤判定部370は、アラート情報の登録依頼があると、アラートテーブル320にアラート情報を登録する。また、正誤判定部370は、判定結果通知に係るイベントがルールに適合し、かつ、イベントのアラート情報がアラートテーブル320に登録されていなければ、アラート通知がなされていないと判断して、通知部380にアラート通知を依頼する。正誤判定部370は、判定結果に係るイベントがルールに適合しておらず、かつ、イベントのアラート情報がアラートテーブル320に登録されていれば、リアルタイム判定部340による判定は間違っていたと判断して、通知部380に誤報訂正通知を依頼する。さらに、正誤判定部370は、判定結果通知に係るイベントのアラート情報について、アラート通知が正しい確率を演算し、アラートテーブル320の確率を更新する。従って、かかるイベント処理装置によれば、過去の実績に応じて、アラート通知が正しい確率が演算され、これがユーザへのアラート通知に付加される。このため、ユーザは、図22に示すような、アラート通知に付加された確率を参照することで、そのアラート通知がどの位正しいものかを把握することができる。なお、リアルタイム判定部340は、ハードディスク300Cに格納されたアラートテーブル320を参照し、イベントに係るアラート情報の確率が所定の閾値以下であるとき、通知部380にアラート通知を依頼しないようにしてもよい。このようにすれば、確度が低いアラート通知がユーザに通知されることを抑制できる。[第3実施形態]第3実施形態では、第1実施形態又は第2実施形態に係る情報システムにおいて、イベント発生源100からサーバ300に到着したイベントを所定時間蓄積した後、発生順に整列させてルールに適合するか否かを判定する効率を向上させる。なお、以下の説明では、第1実施形態に係る情報システムを前提とするが、第2実施形態に係る情報システムを前提としてもよい。ここでは、バッチ判定部360は、正誤判定部370からのID登録依頼又はID削除依頼に応答してメモリ300AにID情報を登録又は削除する。ID登録依頼及びID削除依頼は、図23及び図24に示すように、メッセージタイプ、イベントID及びルールIDを含む。また、バッチ判定部360は、イベントのID情報がメモリ300Aに登録されているときのみ、正誤判定部370に判定結果を通知する。一方、正誤判定部370は、バッチ判定部360にID情報の登録又は削除を依頼する。図25は、イベント整列部350からイベントが転送され、又は、正誤判定部370からID登録若しくはID削除の依頼があったことを契機として、サーバ300のバッチ判定部360が実行するバッチ判定処理の他の例を示す。ステップ91では、バッチ判定部360が、例えば、イベント又はID登録依頼若しくはID削除依頼のメッセージタイプを参照することで、ID登録依頼であるか否かを判定する。そして、バッチ判定部360は、ID登録依頼であると判定すれば処理をステップ92へと進める一方Yes、ID登録依頼でないと判定すれば処理をステップ93へと進めるNo。ステップ92では、バッチ判定部360が、ステップ91と同様な方法で、ID登録依頼に含まれるイベントID及びルールIDを関連付けたID情報を生成し、このID情報をメモリ300Aに登録させる。ステップ93では、バッチ判定部360が、例えば、メッセージを解析することで、ID削除依頼であるか否かを判定する。そして、バッチ判定部360は、ID削除依頼であると判定すれば処理をステップ94へと進める一方Yes、ID削除依頼でないと判定すれば処理をステップ95へと進めるNo。ステップ94では、バッチ判定部360が、ID削除依頼からイベントID及びルールIDを抽出し、このイベントID及びルールIDにより特定されるID情報をメモリ300から削除する。ステップ95では、バッチ判定部360が、ハードディスク300Cに格納されたルールテーブル310を参照して、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部360は、イベントがルールに適合していると判定すれば処理をステップ96へと進める一方Yes、イベントがルールに適合していないと判定すれば処理をステップ99へと進めるNo。ステップ96では、バッチ判定部360が、イベントに含まれるイベントID及び適合したルールのルールIDにより特定されるID情報がメモリ300Aに登録されているか否かを判定する。そして、バッチ判定部360は、ID情報がメモリ300Aに登録されていると判定すれば処理をステップ97へと進める一方Yes、ID情報がメモリ300Aに登録されていないと判定すれば処理をステップ98へと進めるNo。ステップ97では、バッチ判定部360が、正誤判定部370にイベントがルールに適合することを知らせる判定結果を通知する。ステップ98では、バッチ判定部360が、通知部380にアラート通知を依頼する。ステップ99では、バッチ判定部360が、イベントに含まれるイベントID及びアラート通知に係るルールIDにより特定されるID情報がメモリ300Aに登録されているか否かを判定する。そして、バッチ判定部360は、ID情報がメモリ300Aに登録されていると判定すれば処理をステップ100へと進める一方Yes、ID情報がメモリ300Aに登録されていないと判定すれば処理を終了させるNo。ステップ100では、バッチ判定部360が、正誤判定部370にイベントがルールに適合しないことを知らせる判定結果を通知する。かかるバッチ判定処理によれば、サーバ300のバッチ判定部360は、正誤判定部370からID登録依頼又はID削除依頼があると、メモリ300AにID情報を登録又は削除する。また、バッチ判定部360は、発生順に整列された各イベントについて、リアルタイム判定処理と同一のルールテーブル310に基いて、イベントがルールに適合しているか否かを判定する。そして、バッチ判定部360は、イベントがルールに適合しているか否かにかかわらず、正誤判定部370に判定結果を通知すると共に、イベントがルールに適合し、かつ、ID情報がメモリ300Aに登録されていれば、通知部380に誤報訂正通知を依頼する。図26は、リアルタイム判定部340からアラート情報の登録依頼、又は、バッチ判定部360から判定結果の通知があったことを契機として、サーバ300の正誤判定部370が実行する正誤判定処理の他の例を示す。ステップ101では、正誤判定部370が、例えば、登録依頼又は判定結果通知のメッセージタイプを参照することで、アラート情報の登録依頼であるか否かを判定する。そして、正誤判定部370は、アラート情報の登録依頼であると判定すれば処理をステップ102へと進める一方Yes、アラート情報の登録依頼でないと判定すれば処理をステップ104へと進めるNo。ステップ102では、正誤判定部370が、アラート情報の登録依頼に含まれるイベントID、ルールID及びイベント列を関連付けたアラート情報を生成し、このアラート情報をハードディスク300Cに格納されたアラートテーブル320に登録する。ステップ103では、正誤判定部370が、アラート情報の登録依頼に含まれるイベントID及びルールIDについて、バッチ判定部360にID情報の登録を依頼する。ステップ104では、正誤判定部370が、判定結果通知に含まれる判定結果を参照することで、判定結果通知に係るイベントがルールに適合しているか否かを判定する。そして、正誤判定部370は、イベントがルールに適合していると判定すれば処理をステップ105へと進める一方Yes、イベントがルールに適合していないと判定すれば処理をステップ109へと進めるNo。ステップ105では、正誤判定部370が、ハードディスク300Cに格納されたアラートテーブル320を参照し、判定結果通知に含まれるイベントID及びルールIDにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部370は、アラート情報が登録されていると判定すれば処理をステップ106へと進める一方Yes、アラート情報が登録されていないと判定すれば処理をステップ108へと進めるNo。ステップ106では、正誤判定部370が、ハードディスク300Cに格納されたアラートテーブル320から、判定結果通知に係るイベントのアラート情報を削除する。ステップ107では、正誤判定部370が、判定結果通知に含まれるイベントID及びルールIDについて、バッチ判定部360にID情報の削除を依頼する。ステップ108では、正誤判定部370が、通知部380にアラート通知を依頼する。ステップ109では、正誤判定部370が、ハードディスク300Cに格納されたアラートテーブル320を参照し、判定結果通知に含まれるイベントID及びルールIDにより特定されるアラート情報が登録されているか否かを判定する。そして、正誤判定部370は、アラート情報が登録されていると判定すれば処理をステップ110へと進める一方Yes、アラート情報が登録されていないと判定すれば処理を終了させるNo。ステップ110では、正誤判定部370が、通知部380に誤報訂正通知を依頼する。ステップ111では、正誤判定部370が、判定結果通知に含まれるイベントID及びルールIDについて、バッチ判定部360にID情報の削除を依頼する。かかる正誤判定処理によれば、サーバ300の正誤判定部370は、アラート情報の登録依頼があると、アラートテーブル320にアラート情報を登録すると共に、バッチ判定部360にID情報の登録を依頼する。また、正誤判定部370は、判定結果通知に係るイベントがルールに適合し、かつ、アラート情報がアラートテーブル320に登録されていれば、アラートテーブル320からアラート情報を削除すると共に、バッチ判定部360にID情報の削除を依頼する。正誤判定部370は、判定結果通知に係るイベントがルールに適合し、かつ、アラート情報がアラートテーブル320に登録されていなければ、通知部380にアラート通知を依頼する。正誤判定部370は、判定結果通知に係るイベントがルールに適合しておらず、かつ、アラート情報がアラートテーブル320に登録されていれば、通知部380に誤報訂正通知を依頼すると共に、バッチ判定部360にID情報の削除を依頼する。従って、バッチ判定部360は、ID情報がメモリ300Aに登録されているときに、正誤判定部370に判定結果を通知することとなる。このため、正誤判定部370は、リアルタイム判定処理における判定結果をすべて再確認する必要がなく、判定効率を向上させることができる。ここで、イベント処理装置の作用効果の理解を容易ならしめるために、具体的な事例を想定した実施例について説明する。実施例の前提として、次のような条件を想定する。1イベントに適用するルールは、ユーザの外出中に人感センサが人間の所在を感知すると、警備会社に不審者侵入を通報するとする。2人感センサは、人間の所在を感知すると同時に、イベントをサーバ300に通知する。3GPSレシーバを内蔵した携帯電話400は、定期的例えば1分ごとにユーザの位置情報をサーバ300に通知する。ユーザが外出から帰宅したとき、携帯電話400から位置情報が通知される前に、人感センサによりユーザの所在が感知されたことを考える。この場合、図27に示すように、人感センサからサーバ300にイベントが通知されると手順1、イベント受信部330は、このイベントをリアルタイム判定部340及びイベント整列部350に夫々転送する手順2、3。イベントが転送されたリアルタイム判定部340は、ハードディスク300Cのルールテーブル310を参照し、ユーザの外出中に人感センサが人間の所在を感知したというルールに適合すると判定する。そして、リアルタイム判定部340は、通知部380にアラート通知を依頼すると共に手順4、正誤判定部370にアラート情報の登録を依頼する手順5。また、イベントが転送されたイベント整列部350は、メモリ300Aにイベントを蓄積する。アラート通知の依頼を受けた通知部380は、警備会社にアラート不審者侵入を通知する手順6。また、アラート情報の登録依頼を受けた正誤判定部370は、ハードディスク300Cのアラートテーブル320にアラート情報を登録する。この状態において、ユーザの携帯電話400からサーバ300にイベントが通知されると手順7、イベント受信部330は、このイベントをリアルタイム判定部340及びイベント整列部350に夫々転送する手順8、9。イベントが転送されたイベント整列部350は、イベントの蓄積を開始してから所定時間経過したとき、発生順にイベントを整列してバッチ判定部360に順次転送する手順10。イベントが転送されたバッチ判定部360は、ハードディスク300Cのルールテーブル310を参照し、ユーザの外出中に人感センサが人間の所在を感知したというルールに適合しないと判定する。そして、バッチ判定部360は、正誤判定部370に判定結果を通知する手順11。判定結果を受けた正誤判定部370は、イベントがルールに適合しておらず、かつ、アラートテーブル320にアラート情報が登録されているため、先程通知したアラートは間違いであったと判断し、通知部380に誤報訂正通知を依頼する手順12。誤報訂正通知を受けた通知部380は、警備会社に誤報訂正を通知する手順13。従って、サーバ300から警備会社に誤ってアラートが通知されても、このアラートが間違いであったことを示す誤報訂正通知が通知されるので、警備会社はユーザ宅に駆けつける必要がなくなる。また、ユーザは、警備会社にアラート通知が間違いであったことを連絡する必要がなく、手間を軽減することができる。