JP5884901B2 - プログラム、情報処理装置およびイベント処理方法 - Google Patents

Description

本発明はプログラム、情報処理装置およびイベント処理方法に関する。

現在、種々の装置がネットワークを介して情報処理装置に接続された情報処理システムが利用されている。情報処理システムには、他の装置から受信したイベントデータに応じた処理を情報処理装置が実行するものがある。イベントデータを発行する装置には、例えば他の情報処理装置、センサ装置および家電機器などのあらゆる装置が含まれ得る。

イベントデータに対しある処理を実行するか否かを情報処理装置が判断するための条件の内容や当該処理の内容を定義したルールは、例えば利用者によって予め作成される。情報処理装置は、受信したイベントデータによりルール内の条件が満たされたと判断すると、対応する処理を実行する。情報処理装置は、種々の装置から順次受信する複数のイベントデータに基づいて１または複数の処理を実行することもある。このような処理の実行方法は、複合イベント処理（ＣＥＰ：Complex Event Processing）と呼ばれることがある。

ＣＥＰを行う情報処理装置には、大量のイベントデータが入力され得る。単位時間当たりのイベントデータの受信数が増大すると、処理待ちが生じてイベントに対する処理の実行までに遅延が生じ得る。そこで、コプロセッサ（Coprocessor）を用いてイベントストリームを高速に処理する提案がある。この提案では、例えば、到着したイベントストリームのフィルタによる絞り込み、および、ルール条件とのマッチングをコプロセッサ内で並列に行うことで高速化を図る。

なお、ルール内の記述に“ＲＥＴＡＩＮ”の文字列で示される節の使用を許容し、“ＲＥＴＡＩＮ”節で指定されたイベント数や時間に達するまでに到着した複数のイベントデータに関する処理を実行可能にする処理記述言語の提案もある。また、フィルタ処理されたストリーミングイベントに対するパターン検出の結果と、過去イベントに対する履歴パターンの検出の結果と、に基づいたイベント処理を可能とするようにイベント処理言語を拡張する提案もある。

国際公開第２００９／１４０３６３号 国際公開第２００８／１５０６７５号 特開２０１１−８６２８８号公報

入力されたイベントデータに対しルールで記述された手順に従って処理を行うと、情報処理装置が処理を無駄に実行してしまうことがあるという問題がある。
例えば、あるイベントデータに基づく第１の処理の結果を第２の処理で利用することがある。更に、例えば、第１の処理の結果によらない条件判定の結果に応じて第２の処理を実行するか否かを決定することがある。このとき、当該条件判定の前に第１の処理が実行されるようにルールが記述されていることがある。しかし、この場合、第１の処理の実行後に、当該条件判定によって第２の処理を実行しないと決定されると、第１の処理の結果を余計に取得したことなる。すなわち、第１の処理が無駄に実行されたことになり非効率的となる。ルールで記述された手順に従って処理を実行する限り、このように無駄な処理の実行を抑止することは困難である。

一側面によれば、本発明は、イベントに対して効率的に処理を実行することができるプログラム、情報処理装置およびイベント処理方法を提供することを目的とする。

一実施態様によれば、コンピュータにより実行されるプログラムが提供される。このプログラムは、イベントデータに含まれるイベントの種別に応じて起動される複数の処理を示す情報が記載されたルール情報を参照して、第１の種別のイベントデータを用いる第１の処理を示す情報と、第１の処理の結果によらずに当該イベントデータを用いて実行可能であり、後続して記載された処理を実行するか否かを決定する条件判定の処理を示す情報と、条件判定に後続して記載され第１の処理の結果を用いる第２の処理を示す情報と、を検索し、ルール情報において条件判定が第１の処理に後続して記載されている場合、当該条件判定の結果に応じて第１の処理を起動するか否かが決定されるように、条件判定の処理と第１の処理の実行順を入れ替え、第１の処理が実行された場合に第２の処理が起動されるように制御するための制御情報を第１の種別に対して生成し、第１の種別のイベントデータが入力されると、制御情報に基づいて、入力されたイベントデータに応じた処理を実行する、処理をコンピュータに実行させる。

また、一実施態様によれば、情報処理装置が提供される。情報処理装置は、記憶部と演算部とを有する。記憶部は、イベントデータに含まれるイベントの種別に応じて起動される複数の処理を示す情報が記載されたルール情報を記憶する。演算部は、ルール情報を参照して、第１の種別のイベントデータを用いる第１の処理を示す情報と、第１の処理の結果によらずに当該イベントデータを用いて実行可能であり、後続して記載された処理を実行する否かを決定する条件判定の処理を示す情報と、条件判定に後続して記載され第１の処理の結果を用いる第２の処理を示す情報と、を検索し、ルール情報において条件判定が第１の処理に後続して記載されている場合、当該条件判定の結果に応じて第１の処理を起動するか否かが決定されるように、条件判定の処理と第１の処理の実行順を入れ替え、第１の処理が実行された場合に第２の処理が起動されるように制御するための制御情報を第１の種別に対して生成し、第１の種別のイベントデータが入力されると、制御情報に基づいて、入力されたイベントデータに応じた処理を実行する。

また、一実施態様によれば、情報処理装置によって実行されるイベント処理方法が提供される。イベント処理方法では、イベントデータに含まれるイベントの種別に応じて起動される複数の処理を示す情報が記載されたルール情報を参照して、第１の種別のイベントデータを用いる第１の処理を示す情報と、第１の処理の結果によらずに当該イベントデータを用いて実行可能であり、後続して記載された処理を実行するか否かを決定する条件判定の処理を示す情報と、条件判定に後続して記載され第１の処理の結果を用いる第２の処理を示す情報と、を検索し、ルール情報において条件判定が第１の処理に後続して記載されている場合、当該条件判定の結果に応じて第１の処理を起動するか否かが決定されるように、条件判定の処理と第１の処理の実行順を入れ替え、第１の処理が実行された場合に第２の処理が起動されるように制御するための制御情報を第１の種別に対して生成する。第１の種別のイベントデータが入力されると、制御情報に基づいて、入力されたイベントデータに応じた処理を実行する。

一実施態様によれば、イベントに対して効率的に処理を実行することができる。
本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。

第１の実施の形態の情報処理装置を示す図である。 第２の実施の形態の情報処理システムを示す図である。 第２の実施の形態のサーバのハードウェア例を示す図である。 第２の実施の形態のサーバのソフトウェア例を示す図である。 第２の実施の形態の入力されるイベントデータの例を示す図である。 第２の実施の形態の出力されるイベントデータの例を示す図である。 第２の実施の形態の処理部の例を示す図である。 第２の実施の形態のホームテーブルの例を示す図である。 第２の実施の形態のルールセットの例を示す図である。 第２の実施の形態の定義ルールの例を示す図である。 第２の実施の形態の処理ルールの例を示す図である。 第２の実施の形態の定義ルール管理テーブルの例を示す図である。 第２の実施の形態の制御テーブルの例を示す図である。 第２の実施の形態の最適化後の制御テーブルの例を示す図である。 第２の実施の形態の処理例を示すフローチャートである。 第２の実施の形態のルール振分の例を示すフローチャートである。 第２の実施の形態のルール組替えの例を示す図である。 第２の実施の形態のルール分解の例を示す図である。 第２の実施の形態のイベント処理の例を示すフローチャートである。 第２の実施の形態のイベント処理の例を示す図である。 ルールセットの比較例（その１）を示す図である。 ルールセットの比較例（その２）を示す図である。 第２の実施の形態の件数集計表の例を示す図である。 第３の実施の形態のルール構造体の例を示す図である。 第３の実施の形態のバリュー構造体の例を示す図である。 第３の実施の形態の制御テーブルの展開例を示す図である。 第３の実施の形態のルール展開の例を示すフローチャートである。 第３の実施の形態のイベント種別の展開例を示すフローチャートである。 第３の実施の形態の前段フィルタの展開例を示すフローチャートである。 第３の実施の形態のＪＯＩＮキーの展開例を示すフローチャートである。 第３の実施の形態の後段フィルタの展開例を示すフローチャートである。 第３の実施の形態の主処理の展開例を示すフローチャートである。 第３の実施の形態のイベント処理の例を示すフローチャートである。 第３の実施の形態のイベント処理の例を示す図である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報処理装置を示す図である。情報処理装置１は、ＣＰＵ（Central Processing Unit）などのプロセッサとＲＡＭ（Random Access Memory）などのメモリとを備えてもよく、メモリに記憶されたプログラムをプロセッサが実行するコンピュータであってもよい。また、情報処理装置１は、ＦＰＧＡ（Field Programmable Gate Array）やＡＳＩＣ（Application Specific Integrated Circuit）などの電子回路を備えてもよく、当該電子回路により情報処理装置１の機能が実現されてもよい。

情報処理装置１は、記憶部１ａおよび演算部１ｂを有する。
記憶部１ａは、イベントデータに基づく複数の処理を示す情報を含むルール情報２を記憶する。ここで、イベントデータは、例えば、ネットワークを介して情報処理装置１に接続されたイベントの発生元の装置（図示を省略）から情報処理装置１へ入力される。ルール情報２は利用者によって予め作成される。ルール情報２は、入力されるイベントデータに対して情報処理装置１にどのような処理を実行させるかを示すルールを記述した情報である。

複数の処理を示す情報には、例えば、入力されたイベントデータを直接的または間接的に用いる処理が含まれ得る。例えば、入力されたイベントデータを直接的に用いる処理は、入力されたイベントデータに対する条件判定の処理である。また、入力されたイベントデータを直接的に用いる処理は、当該イベントデータと記憶部１ａまたは不図示の記憶装置に格納された外部テーブルとを結合する処理（ＪＯＩＮ）でもよい。イベントデータを直接的に用いる処理は、イベントデータに対して所定の計算や他の装置の制御を行う処理などでもよい。例えば、入力されたイベントデータを間接的に用いる処理は、当該結合の結果などを用いて他の装置の制御や、情報処理装置１が保持する制御用の情報の更新などを行う処理である。入力されたイベントデータを間接的に用いる処理は、当該結合の結果などを用いた条件判定の処理などでもよい。

演算部１ｂは、ルール情報２を参照して、第１の処理Ａ１を示す情報と第１の処理Ａ１の結果によらずに実行可能な条件判定Ｂの処理を示す情報と当該条件判定Ｂに関連付けられており第１の処理Ａ１の結果を用いる第２の処理Ａ２を示す情報とを検索する。例えば、第１の処理Ａ１は、イベントデータと外部テーブルとを結合する処理である。第１の処理Ａ１は、イベントデータを用いて所定の計算を行う処理などでもよい。例えば、第２の処理Ａ２は、当該結合の結果に基づいてイベントの発生元の装置または他の装置を制御するための処理である。第２の処理Ａ２は、当該結合の結果などを用いた条件判定の処理などでもよい。

また、第１の処理Ａ１の結果によらずに実行可能な条件判定Ｂとは、第１の処理Ａ１の結果が条件判定Ｂの結果に影響を及ぼさない条件判定である。条件判定Ｂは、第１の処理Ａ１の結果を用いない条件判定であるということもできる。例えば、条件判定Ｂは、入力されたイベントデータを直接判定することで結果を得られる条件判定である。

更に、条件判定Ｂと第２の処理Ａ２とが関連付けられている場合とは、条件判定Ｂの結果に応じて第２の処理Ａ２を実行するか否かを判断するようにルールが記述されている場合が該当する。また、条件判定Ｂと並列に第２の処理Ａ２の結果を取得するようにルールが記述されている場合も該当する。後者について、より具体的には、第２の処理Ａ２が第１の処理Ａ１の結果を用いた他の条件判定の処理であり、条件判定Ｂの結果と当該他の条件判定の結果とに基づいて、後続の他の処理を実行するようにルールが記述されている場合が考えられる。

演算部１ｂは、条件判定Ｂの結果に応じて第１の処理Ａ１が実行され第１の処理Ａ１の後に第２の処理Ａ２が実行されるように処理の実行順を制御するための制御情報３を生成する。演算部１ｂは、生成した制御情報３を記憶部１ａに格納する。演算部１ｂは、イベントデータが入力されると、記憶部１ａに記憶された制御情報３に基づいて、入力されたイベントデータに応じた処理を実行する。

情報処理装置１によれば、演算部１ｂにより、ルール情報２が参照され、第１の処理Ａ１を示す情報と第１の処理Ａ１の結果によらずに実行可能な条件判定Ｂの処理を示す情報と条件判定Ｂに関連付けられており第１の処理Ａ１の結果を用いる第２の処理Ａ２を示す情報とが検索される。演算部１ｂにより、条件判定Ｂの結果に応じて第１の処理Ａ１が実行され第１の処理Ａ１の後に第２の処理Ａ２が実行されるように処理の実行順を制御するための制御情報３が生成される。イベントデータが入力されると、演算部１ｂにより、制御情報３に基づいて、入力されたイベントデータに応じた処理が実行される。

これにより、イベントに対して効率的に処理を実行することができる。具体的には次の通りである。例えば、ルール情報２に含まれる第２の処理Ａ２を実行するためには、第１の処理Ａ１の結果が得られていることが前提である。一方、第２の処理Ａ２は、条件判定Ｂと関連付けられている。このとき、ルールの記述のしかたによっては第１の処理Ａ１が条件判定Ｂの前に実行され得る。

また、ルールを記述する言語によっては、条件判定の処理と、それ以外の処理とを明確に分け、条件判定後にそれ以外の処理を実行するように処理順序を定めることで、処理の高速化を図るものもある。条件判定のみであれば、レジスタなどを用いて高速に処理可能だからである。そのため、当該言語では、例えば結合の処理を条件判定の処理に含めて記述することを許していないことがある。当該言語を用いる場合、第２の処理Ａ２が第１の処理Ａ１の結果を用いる処理であると、条件判定Ｂの前に第１の処理Ａ１を実行しておくことになる。

ところが、条件判定Ｂの前に第１の処理Ａ１を実行するようにルールが定められている場合、第１の処理Ａ１が無駄に実行され非効率的となるおそれがある。条件判定Ｂの結果によっては第２の処理Ａ２を実行しなくてもよい場合があるからである。しかし、ルールの記述のしかたによって、処理順序を規定できる場合でも、利用者に対して常に処理の順序を意識してルールを作成するように強いることは難しい。また、上述のように記述言語によっては、条件判定Ｂの前に第１の処理Ａ１を実行するような処理順序でしかルールを実行できないものも存在する。

そこで、情報処理装置１は、ルール情報２に基づいて制御情報３を生成する。情報処理装置１は、制御情報３に基づいて、入力されたイベントデータに応じた処理を実行する。例えば、条件判定Ｂは入力されたイベントデータを用いて結果を得られる（第１の処理Ａ１の結果を用いない）条件判定であるとする。ルール情報２では、条件判定Ｂの結果が真の場合に第２の処理Ａ２を実行し、条件判定Ｂの結果が偽の場合に第２の処理Ａ２を実行しないように記述されているとする。

この場合、条件判定Ｂの結果が真であれば第１の処理Ａ１を実行し、条件判定Ｂの結果が偽であれば第１の処理Ａ１を実行しないように制御するための制御情報３が生成される。すると、あるイベントデータが入力されたとき、条件判定Ｂの結果が真であれば、第１の処理Ａ１および第２の処理Ａ２がこの順で実行される。別のイベントデータが入力されたとき、条件判定Ｂの結果が偽であれば、第１の処理Ａ１および第２の処理Ａ２は実行されない。第２の処理Ａ２を実行しなくてよいのであれば、当該第２の処理Ａ２の前提となる第１の処理Ａ１も実行しなくてよいからである。

このように、条件判定Ｂの結果に応じて第１の処理Ａ１を実行するか否かを制御することで、第１の処理Ａ１が無駄に実行されることの防止を図れる。その結果、イベントに対して実行される処理の数が軽減され、所定時間当たりに処理できるイベントの数が向上する。また、無駄な処理の発生による他のイベントの処理待ちが改善されるので、イベントの発生に対して処理が実行されるまでの遅延を軽減できる。また、条件判定Ｂをフィルタ条件として抽出することで、例えばレジスタを用いて当該条件判定Ｂを高速に処理するように条件判定機能をモジュール化することも可能となる。

更に、ルール情報２に基づいて制御情報３を生成し、制御情報３に基づいてイベント処理を行う。このため、利用者が条件判定Ｂの前に第１の処理Ａ１が実行されるようにルールを記述したとしても、第１の処理Ａ１が無駄に実行されないように処理順序を制御することができる。また、利用者の処理順序を考慮したルール記述の負担を軽減でき、利用者によるルール記述の作業を省力化することができる。

［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、種々の装置がネットワーク１０および中継装置２０，３０を介して接続され、各装置で発生したイベントに応じて、イベントの発生元の装置や他の装置の制御を行うシステムである。第２の実施の形態の情報処理システムは、携帯端末装置４０、消費電力計測器５０、空調機６０、携帯電話機７０、宅内電力管理装置８０およびサーバ１００を含む。

携帯端末装置４０、消費電力計測器５０および空調機６０は、中継装置２０およびネットワーク１０を介してサーバ１００と接続される。携帯電話機７０および宅内電力管理装置８０は、中継装置３０およびネットワーク１０を介してサーバ１００と接続される。ネットワーク１０は、ＬＡＮ（Local Area Network）でもよいし、インターネットなどの広域ネットワークＷＡＮ（Wide Area Network）でもよい。中継装置２０，３０は、無線または有線の通信を中継するルータ装置やスイッチ装置などでもよい。中継装置２０，３０は、無線基地局でもよい。

携帯端末装置４０は、ユーザによる入力を受け付け、当該入力に応じたイベントデータをサーバ１００に送信する電子装置である。携帯端末装置４０は、情報処理システムで発生したイベントに応じたメッセージなどをサーバ１００から受信して、ユーザに提供することもできる。

消費電力計測器５０は、ある宅内で消費される消費電力量を計測する計測器である。消費電力計測器５０は、スマートメータと呼ばれることもある。消費電力計測器５０は、計測した消費電力量をイベントデータに含めてサーバ１００に送信する。

空調機６０は、消費電力計測器５０と同じ宅内に設置された電気機器である。空調機６０は、現在の設定温度（建物室内の目標とする温度）をイベントデータに含めてサーバ１００に送信する。空調機６０は、情報処理システムで発生したイベントに応じてサーバ１００から温度調整の指示を受信すると、当該指示に応じて設定温度を変更する。例えば、節電のためである。また、空調機６０は、情報処理システムで発生したイベントに応じたメッセージなどをサーバ１００から受信してユーザに提供することもできる。以下の説明において、空調機６０では暖房機能が利用されているものとする。

携帯電話機７０は、ユーザによる入力を受け付け、当該入力に応じたイベントデータをサーバ１００に送信する電子装置である。携帯電話機７０は、情報処理システムで発生したイベントに応じたメッセージなどをサーバ１００から受信して、ユーザに提供することもできる。

宅内電力管理装置８０は、太陽光発電などによる発電電力量を管理するための装置である。宅内電力管理装置８０は、売電状態や買電状態などを切り替えの指示をサーバ１００から受信すると、当該指示に応じて売電／買電状態などの切り替えを行う。

サーバ１００は、各装置から随時受信するイベントデータに応じて、各装置を制御するための処理を実行するサーバコンピュータである。各装置から受信する複数のイベントデータをイベントストリームと呼ぶことがある。サーバ１００は、ＣＥＰの技術を用いてイベントストリームに応じた処理を実行する。

図３は、第２の実施の形態のサーバのハードウェア例を示す図である。サーバ１００は、ＣＰＵ１０１、ＲＡＭ１０２、ＨＤＤ（Hard Disk Drive）１０３、画像信号処理部１０４、入力信号処理部１０５、ディスクドライブ１０６および通信部１０７を有する。各ユニットがサーバ１００のバスに接続されている。

ＣＰＵ１０１は、サーバ１００の情報処理を制御するプロセッサである。ＣＰＵ１０１は、ＨＤＤ１０３に記憶されているプログラムやデータの少なくとも一部を読み出し、ＲＡＭ１０２に展開してプログラムを実行する。サーバ１００は複数のプロセッサを備えてもよく、複数のプロセッサを用いて処理を分散して実行してもよい。

ＲＡＭ１０２は、ＣＰＵ１０１が実行するプログラムや処理に用いるデータを一時的に記憶する揮発性メモリである。サーバ１００は、複数のメモリを備えてもよい。
ＨＤＤ１０３は、ＯＳ（Operating System）プログラムやアプリケーションプログラムなどのプログラムおよびデータを記憶する不揮発性の記憶装置である。ＨＤＤ１０３は、ＣＰＵ１０１の命令に従って、内蔵の磁気ディスクに対してデータの読み書きを行う。サーバ１００は、ＨＤＤ１０３に代えて、または、ＨＤＤ１０３と併せて、ＳＳＤ（Solid State Drive）などの他の記憶装置を備えてもよい。

画像信号処理部１０４は、ＣＰＵ１０１の命令に従って、サーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、例えば、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。

入力信号処理部１０５は、サーバ１００に接続された入力デバイス１２から入力信号を取得し、ＣＰＵ１０１に出力する。入力デバイス１２としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。

ディスクドライブ１０６は、記録媒体１３に記録されたプログラムやデータを読み取る駆動装置である。記録媒体１３としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリを使用できる。磁気記録装置には、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−Ｒ／ＲＷ／ＲＡＭなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。半導体メモリには、ＵＳＢ（Universal Serial Bus）メモリなどのフラッシュメモリがある。ディスクドライブ１０６は、例えば、ＣＰＵ１０１の命令に従って、記録媒体１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。

通信部１０７は、ネットワーク１０および中継装置２０，３０を介して他の装置と通信を行う有線または無線の通信インタフェースである。
図４は、第２の実施の形態のサーバのソフトウェア例を示す図である。図４に示すユニットの一部または全部は、サーバ１００が実行するプログラムのモジュールであってもよい。また、図４に示すユニットの一部または全部は、ＦＰＧＡやＡＳＩＣなどの電子回路であってもよい。

サーバ１００は、記憶部１１０、振分部１２０および処理部１３０を有する。
記憶部１１０は、振分部１２０や処理部１３０の処理に用いるデータを記憶する。具体的には、記憶部１１０は、作成者などが作成したルール情報を記憶する。ルール情報は、イベントに応じて実行すべき複数の処理を示す情報を含む。ルール情報は、サーバ１００に予め入力される。また、記憶部１１０は、ルール情報内の処理の実行順を制御するために処理部１３０が用いる制御情報を記憶する。当該制御情報は、振分部１２０によって生成され記憶部１１０に格納される。記憶部１１０は、ＲＡＭ１０２やＨＤＤ１０３を用いて実装することができる。

振分部１２０は、記憶部１１０に記憶されたルール情報に基づいて制御情報を生成し、記憶部１１０に格納する。振分部１２０は、ルール情報に含まれる各処理を示す情報について、所定の関係性をもった処理を検索し、検索された処理の実行順を組替えることで制御情報を生成する。

処理部１３０は、他の装置からイベントデータを受信すると、記憶部１１０に記憶された制御情報に基づいて、イベントデータに応じた処理を実行する。以下の説明では、一例として、サーバ１００が消費電力計測器５０および空調機６０から受信するイベントデータに基づいて、空調機６０を制御する場合を説明する。

図５は、第２の実施の形態の入力されるイベントデータの例を示す図である。イベントデータ２００は、各装置からサーバ１００に送信されるデータである。イベントデータ２００は、イベント種別、ｉｄ（identifier）およびデータのフィールドを含む。

イベント種別のフィールドには、発生したイベントの種別を示す情報が設定される。ｉｄのフィールドには、イベントの発行元の装置を識別するための識別情報が設定される。データの項目には、イベントの内容を示す情報が設定される。データの項目には、イベントの発行元の装置によって、異なる種類の情報が設定され得る。例えば、消費電力計測器５０によりデータの項目に設定される情報は、計測した消費電力量を示す情報である。例えば、空調機６０によりデータの項目に設定される情報は、現在の設定温度を示す情報である。図５ではイベントデータ２１０，２２０も示されている。

イベントデータ２１０は、消費電力計測器５０により生成されサーバ１００に送信されるイベントデータである。イベントデータ２１０の各フィールドの設定内容は次の通りである。イベント種別には、消費電力計測器に関係するイベントであることを示す“Ｐ”が設定されている。ｉｄには、消費電力計測器５０の識別情報である“００１１”が設定されている。データには、計測された消費電力量である“１５１０（Ｗｈ）”が設定されている。イベントデータ２１０は、例えば、所定のタイミングで消費電力計測器５０からサーバ１００に送信される。周期的に送信してもよいし、計測した消費電力量が閾値を超過したタイミングなどに送信してもよい。

イベントデータ２２０は、空調機６０により生成されサーバ１００に送信されるイベントデータである。イベントデータ２２０の各フィールドの設定内容は次の通りである。イベント種別には、空調機に関係するイベントであることを示す“Ａ”が設定されている。ｉｄには、空調機６０の識別情報である“００２１”が設定されている。データには、空調機６０の現在の設定温度である“２２（℃）”が設定されている。イベントデータ２２０は、例えば、所定のタイミングで空調機６０からサーバ１００に送信される。周期的に送信してもよいし、設定温度が変更されたタイミングなどに送信してもよい。

図６は、第２の実施の形態の出力されるイベントデータの例を示す図である。イベントデータ３００は、処理部１３０により生成され、各装置に送信されるデータである。例えば、イベントデータ３００は各装置を制御するためのデータである。イベントデータ３００は、イベント種別、ｉｄおよびデータのフィールドを含む。各フィールドの設定内容は、イベントデータ２００における同名のフィールドと同様である。図６ではイベントデータ３１０も示されている。

イベントデータ３１０は、イベントデータ２１０，２２０に応じて処理部１３０により生成され、空調機６０に送信されるイベントデータである。イベントデータ３１０の各フィールドの設定内容は次の通りである。イベント種別には、空調機に関係するイベントであることを示す“Ａ”が設定されている。ｉｄには、空調機６０の識別情報である“００２１”が設定されている。データには、空調機６０に対する設定温度である“２０（℃）”が設定されている。

次に、イベントデータ２００を処理する処理部１３０のモジュール例を説明する。
図７は、第２の実施の形態の処理部の例を示す図である。図７に示すユニットの一部または全部は、サーバ１００が実行するプログラムのモジュールであってもよい。また、図７に示すユニットの一部または全部は、ＦＰＧＡやＡＳＩＣなどの電子回路であってもよい。

処理部１３０は、前段フィルタ部１３１、ＪＯＩＮ部１３２、後段フィルタ部１３３および主処理部１３４を有する。
前段フィルタ部１３１は、イベントデータ２１０またはイベントデータ２２０を用いて次段の処理を実行するか否かを判定する。次段の処理とは、ＪＯＩＮ部１３２または主処理部１３４における処理である。次段の処理は、ルール情報に記述されたルールによって決まる。

ＪＯＩＮ部１３２は、イベントデータ２１０，２２０と外部データとを結合する（ＪＯＩＮ）。外部データは、例えば、記憶部１１０に記憶されている。外部データは、サーバ１００からアクセス可能な外部記憶装置に記憶されているものでもよい。ここで、記憶部１１０には、外部データとして、ホームテーブル１１１が記憶されているものとする。ホームテーブル１１１は、消費電力計測器５０および空調機６０が設置された家（建物）に関する情報を含む。ルール情報に記述されたルールの内容によっては、ＪＯＩＮ部１３２の処理がスキップされることもある。

後段フィルタ部１３３は、ＪＯＩＮ部１３２によるＪＯＩＮ結果を用いて次段の主処理部１３４における処理を実行するか否かを判定する。ルール情報に記述されたルールの内容によっては、後段フィルタ部１３３の処理がスキップされることもある。

主処理部１３４は、イベントデータ２１０，２２０に応じて主処理部１３４で管理している情報の更新等の主要な処理を実行したり、必要に応じて出口処理を呼び出し、イベントデータ３１０を生成する。ルール情報に記述されたルールの内容によっては、主処理部１３４がＪＯＩＮ部１３２のＪＯＩＮ結果を用いることがある。

このように、処理部１３０は、前段フィルタ部１３１、ＪＯＩＮ部１３２、後段フィルタ部１３３および主処理部１３４に、条件判定、ＪＯＩＮ処理、主処理を委譲して実行させることができる。フィルタ処理を行う前段フィルタ部１３１および後段フィルタ部１３３、ＪＯＩＮ処理を行うＪＯＩＮ部１３２、主処理を行う主処理部１３４というように明確に分けてモジュール化することで、各処理に適した実装を容易に行えるようになる。例えば、前段フィルタ部１３１や後段フィルタ部１３３ではフィルタ処理のみを専用で行うため、レジスタを用いた高速な処理を行うように実装することもできる。

図８は、第２の実施の形態のホームテーブルの例を示す図である。ホームテーブル１１１は、記憶部１１０に格納される。ホームテーブル１１１は、ｉｄ、ｐｏｗｅｒ、ａｉｒｃｏｎ、ｍａｘｐｏｗ、ｎａｍｅおよびａｒｅａの項目を含む。

ｉｄの項目には、家（建物）を識別するための識別情報が登録される。ｐｏｗｅｒの項目には、当該家に設置された消費電力計測器の識別情報が登録される。ａｉｒｃｏｎの項目には、当該家に設置された空調機の識別情報が登録される。ｍａｘｐｏｗの項目には、当該家における消費電力量（Ｗｈ）の閾値が登録される。この閾値は、イベントの判定に用いられる。ｎａｍｅの項目には、ユーザの名称が登録される。ａｒｅａの項目には、当該家の存在する地域を示す情報が登録される。

例えば、ホームテーブル１１１には、ｉｄが“０００１”、ｐｏｗｅｒが“００１１”、ａｉｒｃｏｎが“００２１”、ｍａｘｐｏｗが“１５００”、ｎａｍｅが“ｕｓｅｒ１”、ａｒｅａが“Ｔｏｋｙｏ”という情報が登録されている。これは、識別情報“０００１”で示される家に、識別情報“００１１”の消費電力計測器５０および識別情報“００２１”の空調機６０が設置されていることを示す。また、イベントの判定に用いられる消費電力量の閾値が“１５００”（Ｗｈ）であること、ユーザの名称が“ｕｓｅｒ１”であること、当該家が東京に区分される地域に存在することを示す。

なお、ホームテーブル１１１では、ｉｄが“０００２”で示されるレコードも登録されている。これは、他のユーザの家に関する情報である。当該レコードでは、例えば、ｐｏｗｅｒが“００１２”の消費電力計測器およびａｉｒｃｏｎが“００２２”の空調機が登録されている。このように、ホームテーブル１１１は、複数の項目が定義された複数のレコードを含む関係データである。

図９は、第２の実施の形態のルールセットの例を示す図である。ルールセット１１２は、記憶部１１０に格納される。ルールセット１１２は、情報処理システムの管理者などによって予め作成されるルール情報である。ルールセット１１２は、定義ルール１１２ａおよび処理ルール１１２ｂを含む。

定義ルール１１２ａは、イベントに関する一般的なルールを記述したデータである。
処理ルール１１２ｂは、定義ルール１１２ａで定義されたイベントに対する具体的な処理内容を記述したデータである。

サーバ１００は、定義ルール１１２ａおよび処理ルール１１２ｂの個別の入力を許容する。振分部１２０または処理部１３０が定義ルール１１２ａおよび処理ルール１１２ｂの個別の入力を受け付けて記憶部１１０に格納してもよい。定義ルール１１２ａおよび処理ルール１１２ｂそれぞれは、異なるイベントに関する定義を記述するために複数作成されて記憶部１１０に格納されてもよい。

また、ルールセットも、イベントの組み合わせの別などに応じて複数作成されてもよい。例えば、第１のルールセットに第１のイベントの集合に関する定義ルールおよび処理ルールを登録し、第２のルールセットに第１のイベントの集合と重複しない第２のイベントの集合に関する定義ルールおよび処理ルールを登録することも考えられる。

図１０は、第２の実施の形態の定義ルールの例を示す図である。定義ルール１１２ａは、消費電力計測器に関係するイベント（イベント種別“Ｐ”）と空調機に関係するイベント（イベント種別“Ａ”）に対する一般的なルールを記述したデータである。以下、定義ルール１１２ａに便宜的に付した行番号を用いて各ルールを説明する。ここで、行番号はルールの符号に対応している。例えば、行番号ｄ１のルールをルールｄ１と表す。例えば、ルールｄ１に対応する記述は“Ｐ（ｉｄ，ｐｏｗ）；”である。１つの行番号に対応する記述が１つのルールである。

ルールｄ１，ｄ２は、イベント定義である。ルールｄ１では、イベント種別“Ｐ”で示されるイベントに対して、消費電力計測器の識別情報用の変数“ｉｄ”と、消費電力量用の変数“ｐｏｗ”とが定義されている。イベントデータ２１０の例でいえば、ｉｄ＝“００１１”である。ｐｏｗ＝“１５１０”である。ルールｄ２では、イベント種別“Ａ”で示されるイベントに対して、空調機の識別情報用の変数“ｉｄ”と、温度用の変数“ｔｅｍｐ”とが定義されている。イベントデータ２２０の例でいえば、ｉｄ＝“００２１”である。ｔｅｍｐ＝“２２”である。

ルールｄ３は、外部データおよび含まれる項目の定義である。ルールｄ３では、ホームテーブル１１１（テーブル名“Ｈｏｍｅ”）について、“ｉｄ”、“ｐｏｗｅｒ”、“ａｉｒｃｏｎ”、“ｍａｘｐｏｗ”，“ｎａｍｅ”、“ａｒｅａ”の項目が定義されている。

ルールｄ４は、イベントに応じた状況を管理するためのウィンドウの定義である。ウィンドウを用いることでＲＡＭ１０２上に状況を示すデータを保持できる。ルールｄ４では、“Ｈｏｍｅ．ｐｏｗ”という名前のウィンドウを用いて、ホームテーブル１１１の“ｉｄ”の項目で示される各家の使用電力量（ｐｏｗ）を保持することが定義されている。例えば、ｉｄ＝“０００１”で示される家の情報についてｐｏｗ＝“１５１０”を保持する場合、“Ｈｏｍｅ（０００１）．ｐｏｗ＝１５１０”のように、家の識別情報と消費電力量とを対応付けてＲＡＭ１０２上に格納する。なお、以下では“Ｈｏｍｅ（ｉｄ）．ｐｏｗ”を“Ｈｏｍｅ．ｐｏｗ”と“ｉｄ”の指定部分を省略して表記することがある。

ルールｄ５，ｄ６は、イベントデータと外部テーブルとのＪＯＩＮ処理の定義である。ルールｄ５では、イベント種別“Ｐ”のイベントデータに含まれる“ｉｄ”の値とホームテーブル１１１に含まれる“ｐｏｗｅｒ”の値とが一致するレコードを抽出し、両データの全項目を組み合わせたレコードを得ることが定義されている。ルールｄ６では、イベント種別“Ａ”のイベントデータに含まれる“ｉｄ”の値とホームテーブル１１１に含まれる“ａｉｒｃｏｎ”の値とが一致するレコードを抽出し、両データの全項目を組み合わせたレコードを得ることが定義されている。

ルールｄ５は、条件判定の処理を示す情報を含んでいない。このため、ルールｄ５は１つの処理を示す情報と考えることができる。ルールｄ６も同様である。更に、ルールｄ５，ｄ６の先頭がＪＯＩＮを実行するための定型句“Ｓｅｌｅｃｔ”であり、ＪＯＩＮ条件を示す“ｗｈｅｒｅ”を含んでおり、当該定型句に基づいて、ＪＯＩＮ処理を行うルールであると判断することができる。

図１１は、第２の実施の形態の処理ルールの例を示す図である。処理ルール１１２ｂは、消費電力計測器に関係するイベントおよび空調機に関係するイベントに対する具体的な処理内容を記述したデータである。以下、処理ルール１１２ｂに便宜的に付した行番号を用いて各ルールを説明する。図１０と同様に、行番号はルールの符号に対応している。例えば、行番号ｒ１のルールをルールｒ１と表す。例えば、ルールｒ１に対応する記述は“ＩＦ Ｐ．ｐｏｗ＞５００ ＴＨＥＮ Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ；”である。１つの行番号に対応する記述が１つのルールである。

ルールｒ１，ｒ２，ｒ３はイベントに対する処理内容を規定するルールである。
ルールｒ１では、消費電力計測器から送信されるイベントデータ（イベント種別“Ｐ”）に含まれる消費電力量（ｐｏｗ）が５００（Ｗｈ）よりも大きい場合に、その家の消費電力量として、Ｈｏｍｅ．ｐｏｗに設定することが定義されている。ここで、ルールｒ１は、Ｈｏｍｅ．ｐｏｗに消費電力量を設定するが、Ｈｏｍｅ．ｐｏｗウィンドウでは、ホームテーブル１１１のｉｄに対応付けて消費電力量を保持する。このため、ルールｒ１では、ルールｄ５で示されるＪＯＩＮ処理の結果を用いる。すなわち、ルールｒ１の実行時においてイベントデータの消費電力計測器の識別情報に対応する家の識別情報（ホームテーブル１１１のｉｄ）を得られることが前提となる。

ここで、ルールｒ１において、“Ｐ．ｐｏｗ＞５００”は条件判定を示す情報である。定型句である“ＩＦ”の文字列によって、当該条件判定を示す情報を識別できる。また、“Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”は、“Ｐ．ｐｏｗ＞５００”に関連付けられた処理を示す情報である。定型句である“ＴＨＥＮ”により、“ＩＦ”内の条件判定を示す情報と“ＴＨＥＮ”の後の処理を示す情報が関連付けられていることが分かる。そして、“Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”は上述のようにルールｄ５で示されるＪＯＩＮ処理の結果を用いる処理である。

ルールｒ２では、空調機から送信されるイベントデータ（イベント種別“Ａ”）に含まれる温度（ｔｅｍｐ）が２５（℃）よりも大きい場合に、当該空調機にレコメンドメッセージ“設定温度を下げると省エネルギーになります”を送信することが定義されている。

ここで、ルールｒ２において、“Ａ．ｔｅｍｐ＞２５”は条件判定を示す情報である。また、“Ｓｅｎｄ Ａ．ｍｓｇ＝“設定温度を下げると省エネルギーになります””は、当該条件判定を示す情報に関連付けられた処理を示す情報である。ルールｒ１と同様に、“ＩＦ”や“ＴＨＥＮ”の文字列によって、これらを識別することができる。

ルールｒ３では、空調機から送信されるイベントデータ（イベント種別“Ａ”）に含まれる温度（Ａ．ｔｅｍｐ）が２０（℃）よりも大きく２５（℃）以下であり、かつ、その家の消費電力量（Ｈｏｍｅ．ｐｏｗ）がその家の消費電力量の閾値（Ｈｏｍｅ．ｍａｘｐｏｗ）よりも大きい場合に、当該空調機の設定温度を２℃下げるように制御することが定義されている。ここで、ルールｒ３は、Ｈｏｍｅ．ｐｏｗから消費電力量を取得して、Ｈｏｍｅ．ｍａｘｐｏｗと比較するが、この場合にもルールｒ１と同様に、該当する家のｉｄを用いる。すなわち、ルールｒ３の実行時においてイベントデータの空調機の識別情報に対応する家の識別情報（ホームテーブル１１１のｉｄ）と当該家の消費電力量閾値（ホームテーブル１１１のｍａｘｐｏｗ）を得られることが前提となる。

ここで、ルールｒ３において、“Ａ．ｔｅｍｐ＞２０”、“Ａ．ｔｅｍｐ＜＝２５”および“Ａ．Ｈｏｍｅ．ｐｏｗ＞Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ”は、条件判定を示す情報である。定型句である“ＩＦ”の文字列によって、当該各条件判定を示す情報を識別できる。また、各条件判定は定型句である“ＡＮＤ”の文字列によって関連付けられている。更に、“Ａ．Ｈｏｍｅ．ｐｏｗ＞Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ”は上述のようにルールｄ６で示されるＪＯＩＮ処理の結果を用いる処理である。また、“Ｃｏｎｔ Ａ．ｔｅｍｐ−＝２”は、上記各条件判定の処理を示す情報に関連付けられた処理を示す情報である。定型句である“ＴＨＥＮ”により、“ＩＦ”内の（“ＡＮＤ”で結ばれた）各条件判定を示す情報と“ＴＨＥＮ”の後の処理を示す情報が関連付けられていることが分かる。

図１２は、第２の実施の形態の定義ルール管理テーブルの例を示す図である。定義ルール管理テーブル１１３は、振分部１２０によって生成され、記憶部１１０に格納される。定義ルール管理テーブル１１３は、Ｎｏ．、種別、名称および含まれる項目の項目を含む。

Ｎｏ．の項目には、定義ルール１１２ａ内で各ルールを識別するための情報が登録される。ここで、定義ルール１１２ａ内の１行を１つのルールとして管理している。したがって、定義ルール１１２ａ内の行番号がＮｏ．の項目の設定値に対応する。種別の項目には、当該ルールの種別を示す情報が登録される。名称の項目には、当該ルールの種別に対する名称を示す情報が登録される。含まれる項目の項目には、ルール内に含まれる項目を示す情報が登録される。ただし、含まれる項目の項目には、種別がＪＯＩＮ結果である場合、ＪＯＩＮ処理の結果によって得られる項目名が登録される。

例えば、定義ルール管理テーブル１１３には、Ｎｏ．が“ｄ１”、種別が“イベント”、名称が“Ｐ”、含まれる項目が“Ｐ．ｉｄ，Ｐ．ｐｏｗ”という情報が登録されている。これは、ルールｄ１の定義“Ｐ（ｉｄ，ｐｏｗ）”に相当するものである。Ｎｏ．“ｄ２”のレコードも同様にルールｄ２の定義に相当するものである。

また、例えば、定義ルール管理テーブル１１３には、Ｎｏ．が“ｄ３”、種別が“外部表”、名称が“Ｈｏｍｅ”、含まれる項目が“Ｈｏｍｅ．ｉｄ，Ｈｏｍｅ．ｐｏｗｅｒ，Ｈｏｍｅ．ａｉｒｃｏｎ，Ｈｏｍｅ．ｍａｘｐｏｗ，Ｈｏｍｅ．ｎａｍｅ，Ｈｏｍｅ．ａｒｅａ”という情報が登録されている。これは、ルールｄ３に相当するものである。

また、例えば、定義ルール管理テーブル１１３には、Ｎｏ．が“ｄ４”、種別が“ウィンドウ”、名称が“Ｈｏｍｅ．ｐｏｗ”、含まれる項目が“Ｈｏｍｅ．ｐｏｗ”という情報が登録されている。これは、ルールｄ４の“Ｈｏｍｅ．ｐｏｗ”のウィンドウの定義に相当するものである。

また、例えば、定義ルール管理テーブル１１３には、Ｎｏ．が“ｄ５”、種別が“ＪＯＩＮ結果”、名称が“Ｐ．Ｈｏｍｅ”、含まれる項目が“Ｐ．ｉｄ，Ｐ．ｐｏｗ，Ｐ．Ｈｏｍｅ．ｉｄ，Ｐ．Ｈｏｍｅ．ａｉｒｃｏｎ，Ｐ．Ｈｏｍｅ．ｍａｘｐｏｗ，Ｐ．Ｈｏｍｅ．ｎａｍｅ，Ｐ．Ｈｏｍｅ．ａｒｅａ”という情報が登録されている。これは、ルールｄ５のＪＯＩＮ処理の結果として得られる全項目に相当する。ルールｄ５では“Ｓｅｌｅｃｔ ＊ ・・・”と指定されているからである。ここで、ホームテーブル１１１に存在していた項目には、当該項目名の頭に“Ｐ．Ｈｏｍｅ”の文字列を付して表す。これは、処理ルール１１２ｂ内の表記と整合させ、イベント“Ｐ”に関連する家“Ｈｏｍｅ”の項目であることを示したものである。

また、例えば、定義ルール管理テーブル１１３には、Ｎｏ．が“ｄ６”、種別が“ＪＯＩＮ結果”、名称が“Ａ．Ｈｏｍｅ”、含まれる項目が“Ａ．ｉｄ，Ａ．ｔｅｍｐ，Ａ．Ｈｏｍｅ．ｉｄ，Ａ．Ｈｏｍｅ．ｐｏｗｅｒ，Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ，Ａ．Ｈｏｍｅ．ｎａｍｅ，Ａ．Ｈｏｍｅ．ａｒｅａ”という情報が登録されている。これは、ルールｄ６のＪＯＩＮ処理の結果として得られる全項目に相当する。ルールｄ６では“Ｓｅｌｅｃｔ ＊ ・・・”と指定されているからである。ここで、ホームテーブル１１１に存在していた項目には、当該項目名の頭に“Ａ．Ｈｏｍｅ”の文字列を付して表す。これは、処理ルール１１２ｂ内の表記と整合させ、イベント“Ａ”に関連する家“Ｈｏｍｅ”の項目であることを示したものである。

図１３は、第２の実施の形態の制御テーブルの例を示す図である。制御テーブル１１４は、振分部１２０により生成され、記憶部１１０に格納される。制御テーブル１１４には、Ｎｏ．、前段フィルタ、ＪＯＩＮ、後段フィルタ、状況（ウィンドウ）および主処理の項目が含まれる。

Ｎｏ．の項目には、処理ルール１１２ｂ内で各ルールを識別するための情報が登録される。ここで、処理ルール１１２ｂ内の１行を１つのルールとして管理している。したがって、処理ルール１１２ｂ内の行番号がＮｏ．の項目の設定値に対応する。前段フィルタの項目には、当該ルールにおいて前段フィルタ部１３１で実行される条件判定の処理を示す情報が登録される。ＪＯＩＮの項目には、当該ルールにおいてＪＯＩＮ部１３２で実行されるＪＯＩＮ処理を示す情報が登録される。後段フィルタの項目には、当該ルールにおいて後段フィルタ部１３３で実行される条件判定の処理を示す情報が登録される。状況（ウィンドウ）の項目には、当該ルールで使用するウィンドウを示す情報が登録される。主処理の項目には、当該ルールにおいて主処理部１３４で実行される主処理を示す情報が登録される。

例えば、制御テーブル１１４には、Ｎｏ．が“ｒ１”のレコードについて次のような情報が登録されている。
（１）前段フィルタ：“Ｐ．ｐｏｗ＞５００”
（２）ＪＯＩＮ：“Ｓｅｌｅｃｔ ＊ Ｆｒｏｍ Ｐ，Ｈｏｍｅ Ｗｈｅｒｅ Ｐ．ｉｄ＝Ｈｏｍｅ．ｐｏｗｅｒ；”
（３）後段フィルタ：設定なし（これを、ハイフン“−”で示している。以下同様）
（４）状況（ウィンドウ）：“Ｈｏｍｅ．ｐｏｗ”
（５）主処理：“Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”
これは、処理ルール１１２ｂのルールｒ１が、振分部１２０により前段フィルタ部１３１、ＪＯＩＮ部１３２、後段フィルタ部１３３および主処理部１３４に振り分けられた結果である。ただし、後段フィルタ部１３３に該当する処理がない。このため、ルールｒ１では後段フィルタ部１３３の処理はスキップされることになる。

また、例えば、制御テーブル１１４には、Ｎｏ．が“ｒ２”のレコードについて次のような情報が登録されている。
（１）前段フィルタ：“Ａ．ｔｅｍｐ＞２５”
（２）ＪＯＩＮ：設定なし
（３）後段フィルタ：設定なし
（４）状況（ウィンドウ）：設定なし
（５）主処理：“Ｓｅｎｄ Ａ．ｍｓｇ ＝ “・・・””
なお、主処理においてレコメンドメッセージの内容を“・・・”と略記している（以下、同様）。

これは、処理ルール１１２ｂのルールｒ２が、振分部１２０により前段フィルタ部１３１、ＪＯＩＮ部１３２、後段フィルタ部１３３および主処理部１３４に振り分けられた結果である。ただし、ＪＯＩＮ部１３２および後段フィルタ部１３３に該当する処理がない。このため、ルールｒ２ではＪＯＩＮ部１３２および後段フィルタ部１３３の処理はスキップされることになる。

また、例えば、制御テーブル１１４には、Ｎｏ．が“ｒ３”のレコードについて次のような情報が登録されている。
（１）前段フィルタ：“Ａ．ｔｅｍｐ＞２０ Ａ．ｔｅｍｐ＜＝２５”
（２）ＪＯＩＮ：“Ｓｅｌｅｃｔ ＊ Ｆｒｏｍ Ａ，Ｈｏｍｅ Ｗｈｅｒｅ Ａ．ｉｄ＝Ｈｏｍｅ．ａｉｒｃｏｎ；”
（３）後段フィルタ：“Ａ．Ｈｏｍｅ．ｐｏｗ＞Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ”
（４）状況（ウィンドウ）：“Ｈｏｍｅ．ｐｏｗ”
（５）主処理：“Ｃｏｎｔ Ａ．ｔｅｍｐ−＝２”
なお、前段フィルタにおけるＡ．ｔｅｍｐについての２つの条件はＡＮＤ条件である。

これは、処理ルール１１２ｂのルールｒ３が、振分部１２０により前段フィルタ部１３１、ＪＯＩＮ部１３２、後段フィルタ部１３３および主処理部１３４に振り分けられた結果である。

図１４は、第２の実施の形態の最適化後の制御テーブルの例を示す図である。制御テーブル１１４ａは、振分部１２０により生成され、記憶部１１０に格納される。ここで、制御テーブル１１４ａは、振分部１２０により制御テーブル１１４に所定の最適化処理を適用した後の情報である。制御テーブル１１４ａには、Ｎｏ．、前段フィルタ、ＪＯＩＮ、後段フィルタ、状況（ウィンドウ）および主処理の項目が含まれる。各項目の設定内容は、制御テーブル１１４における同名の項目の設定内容と同様である。ただし、制御テーブル１１４，１１４ａでは、ＪＯＩＮ以降の項目の設定内容が一部異なる。

具体的には、Ｎｏ．“ｒ１”のレコードのＪＯＩＮ項目について次のように異なる。
（１）制御テーブル１１４のＪＯＩＮ： “Ｓｅｌｅｃｔ ＊ ・・・”
（２）制御テーブル１１４ａのＪＯＩＮ：“Ｓｅｌｅｃｔ Ｈｏｍｅ．ｉｄ ・・・”
これは、後続の主処理“Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”で使用する項目が、ルールｄ５のＪＯＩＮ結果により得られる項目のうちの“Ｐ．Ｈｏｍｅ．ｉｄ”のみだからである。具体的には、当該主処理では“Ｐ．Ｈｏｍｅ．ｉｄ”に基づいて、Ｈｏｍｅ．ｐｏｗウィンドウ中から該当の家に関するウィンドウを特定している。

また、Ｎｏ．“ｒ３”のレコードのＪＯＩＮ項目について次のように異なる。
（１）制御テーブル１１４のＪＯＩＮ： “Ｓｅｌｅｃｔ ＊ ・・・”
（２）制御テーブル１１４ａのＪＯＩＮ：“Ｓｅｌｅｃｔ Ｈｏｍｅ．ｉｄ Ｈｏｍｅ．ｍａｘｐｏｗ ・・・”
これは、後続の後段フィルタで使用する項目がルールｄ６のＪＯＩＮ結果により得られる項目のうちの“Ａ．Ｈｏｍｅ．ｉｄ”および“Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ”のみであり、主処理ではＪＯＩＮ結果を用いていないからである。すなわち、後続の処理のためには、ＪＯＩＮ結果として“Ａ．Ｈｏｍｅ．ｉｄ”および“Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ”のみを取得しておけばよいからである。具体的には、当該後段フィルタでは、“Ａ．Ｈｏｍｅ．ｉｄ”に基づいて、Ｈｏｍｅ．ｐｏｗウィンドウ中から該当の家に関するウィンドウを特定している。また、当該後段フィルタでは、“Ａ．Ｈｏｍｅ．ｐｏｗ”に対する比較値として“Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ”を使用している。

また、Ｎｏ．“ｒ１”のレコードの主処理項目について次のように異なる。
（１）制御テーブル１１４の主処理：“Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”
（２）制御テーブル１１４ａの主処理：“Ｓｅｔ Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”
これは、前段のＪＯＩＮ部で“Ｈｏｍｅ．ｉｄ”が取得されており、主処理部では取得済の“Ｈｏｍｅ．ｉｄ”を使用して、”Ｈｏｍｅ．ｐｏｗ”を直接処理できるからである。

また、Ｎｏ．“ｒ３”のレコードの後段フィルタ項目について次のように異なる。
（１）制御テーブル１１４の後段フィルタ：“Ａ．Ｈｏｍｅ．ｐｏｗ＞Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ”
（２）制御テーブル１１４ａの後段フィルタ：“Ｈｏｍｅ．ｐｏｗ＞Ｈｏｍｅ．ｍａｘｐｏｗ”
これは、前段のＪＯＩＮ部で“Ｈｏｍｅ．ｉｄ”が取得されており、後段フィルタ部では取得済の“Ｈｏｍｅ．ｉｄ”を使用して、”Ｈｏｍｅ．ｐｏｗ”と”Ｈｏｍｅ．ｍａｘｐｏｗ”を直接処理できるからである。

図１５は、第２の実施の形態の処理例を示すフローチャートである。以下、図１５に示す処理をステップ番号に沿って説明する。
（ステップＳ１１）振分部１２０は、ルールの振分を行う。具体的には、振分部１２０は、記憶部１１０に記憶されたルールセット１１２の定義ルール１１２ａおよび処理ルール１１２ｂに含まれる各ルールに基づいて、制御テーブル１１４，１１４ａを生成する。より具体的には、振分部１２０は当該各ルールに含まれる各処理を示す情報を検索し、各処理を示す情報を前段フィルタ、ＪＯＩＮ、後段フィルタおよび主処理に振り分ける。

（ステップＳ１２）処理部１３０は、ルールと外部データとをメモリ上に展開する。具体的には、処理部１３０は、制御テーブル１１４ａおよびホームテーブル１１１をＲＡＭ１０２上に読み込んでおく。これにより、処理部１３０においてイベントを受け付ける準備が整う。

（ステップＳ１３）処理部１３０は、イベントデータを受信する。
（ステップＳ１４）処理部１３０は、受信したイベントデータが終了イベントを示すか否かを判定する。終了イベントである場合、処理部１３０は制御テーブル１１４ａやホームテーブル１１１を配置したＲＡＭ１０２上の領域を解放して、処理を終了する。終了イベントでない場合、処理をステップＳ１５に進める。ここで、終了イベントとは、処理部１３０にイベント処理を終了させるためのイベントである。イベントデータが終了イベントであるとは、イベントデータに含まれるイベント種別に、終了イベントを示す情報が含まれることをいう。

（ステップＳ１５）処理部１３０は、制御テーブル１１４ａに基づいて、イベントデータに応じた処理を実行する。そして、処理をステップＳ１３に進める。
このようにして、処理部１３０は、振分部１２０によって生成された制御テーブル１１４ａに基づいて、イベント処理を行う。次に、ステップＳ１１の処理を詳細に説明する。

図１６は、第２の実施の形態のルール振分の例を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。
（ステップＳ２１）振分部１２０は、記憶部１１０に記憶された定義ルール１１２ａに基づいて、定義ルール管理テーブル１１３を作成し記憶部１１０に格納する。定義ルール管理テーブル１１３は、上述したように定義ルール１１２ａ内の各ルール内に含まれる項目を分割することで作成することができる。例えば、ルールｄ１について“Ｐ（ｉｄ，ｐｏｗ）；”をカンマ“，”記号で分割して、含まれる項目として“Ｐ．ｉｄ”および“Ｐ．ｐｏｗ”を得る。ルールｄ２，ｄ３も同様である。また、ルールｄ４について、“Ｗｉｎｄｏｗ Ｈｏｍｅ．ｐｏｗ；”から、ウィンドウの名称“Ｈｏｍｅ．ｐｏｗ”を得る。更に、ルールｄ５については、“Ｓｅｌｅｃｔ”句と“Ｗｈｅｒｅ Ｐ．ｉｄ＝Ｈｏｍｅ．ｐｏｗｅｒ”から、イベント種別“Ｐ”のイベントデータとホームテーブル１１１との結合を得ることが分かる。更に、“Ｓｅｌｅｃｔ ＊”から結合結果の全項目を取得することが分かるので、“Ｐ”のイベントデータとホームテーブル１１１との上記結合結果の全項目“Ｐ．ｉｄ，Ｐ．ｐｏｗ，Ｐ．Ｈｏｍｅ．ｉｄ，Ｐ．Ｈｏｍｅ．ａｉｒｃｏｎ，Ｐ．Ｈｏｍｅ．ｍａｘｐｏｗ，Ｐ．Ｈｏｍｅ．ｎａｍｅ，Ｐ．Ｈｏｍｅ．ａｒｅａ”を得る。ルールｄ６も同様である。ただし、この段階では実際のテーブルのＪＯＩＮ処理は実行されていない。ＪＯＩＮ結果の項目が抽出されるのみである。振分部１２０は、このようにして定義ルール１１２ａから得られた各項目を、ルールの番号（“ｄ１”など）、種別および名称に対応付けて、定義ルール管理テーブル１１３に登録する。

（ステップＳ２２）振分部１２０は、処理ルール１１２ｂに含まれる各ルールを“ＡＮＤ”条件を用いて組替える。ここで、“ＡＮＤ”条件を用いて組替えるとは、“ＯＲ”で結ばれた条件を含む１つのルールを“ＡＮＤ”のみを含む複数のルールに書き換えることを意味する。これによって、“ＯＲ”を含んで記述されたルールについても、組替え後のルールを用いて以降のステップを適用し得る。本ステップＳ２２の具体的な処理の内容は後述する。

（ステップＳ２３）振分部１２０は、ステップＳ２２による組替え後の処理ルールからルール（処理ルール１１２ｂの１行分の記述に相当）を１つ抽出する。以降のステップにおいて、本ステップＳ２３で抽出されたルールを単に“抽出されたルール”という。

（ステップＳ２４）振分部１２０は、定義ルール管理テーブル１１３に基づいて、抽出されたルールがＪＯＩＮ処理を含むか否かを判定する。ＪＯＩＮ処理を含む場合、処理をステップＳ２５に進める。ＪＯＩＮ処理を含まない場合、処理をステップＳ２６に進める。振分部１２０は、定義ルール管理テーブル１１３の種別“ＪＯＩＮ結果”に対応する“含まれる項目”内の何れかの項目を用いる処理が、抽出されたルール内に存在するか否かによって、ＪＯＩＮ処理を含むか否かを判定できる。例えば、ルールｒ１であれば、“Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”の処理において、消費電力計測器が設けられた家のウィンドウ“Ｈｏｍｅ”を特定するためにルールｄ５のＪＯＩＮ処理の結果に含まれる“Ｐ．Ｈｏｍｅ．ｉｄ”を用いる。よって、振分部１２０は、ルールｒ１についてＪＯＩＮ処理を含むと判断する。同様にして、ルールｒ２についてはＪＯＩＮ処理を含まないと判定される。ルールｒ３についてはＪＯＩＮ処理を含むと判定される。

（ステップＳ２５）振分部１２０は、抽出されたルールについて、制御テーブル１１４のＪＯＩＮの項目に、ＪＯＩＮ処理を登録する。具体的には、ルールｒ１であれば、ステップＳ２４で説明したようにルールｄ５で示されるＪＯＩＮ処理を含む。よって、振分部１２０は、制御テーブル１１４においてルールｒ１（Ｎｏ．“ｒ１”のレコード）のＪＯＩＮの項目にルールｄ５のＪＯＩＮを示す情報を登録する。

（ステップＳ２６）振分部１２０は、抽出されたルールを最小項に分解する。最小項とは、ルール内に含まれる情報を条件判定部分（条件判定の処理を示す情報）を条件の最小単位に分割したものや主処理部分（条件判定の結果に応じて実行される処理を示す情報）に分割したものである。具体的な処理の内容は後述する。１つのルールに対して最小項は１つ以上含まれ得る。

（ステップＳ２７）振分部１２０は、ステップＳ２６で分割して得た最小項のうち、以降のステップＳ２８〜Ｓ３４で示す処理を行っていない未処理の最小項があるか否かを判定する。未処理の最小項がある場合、処理をステップＳ２８に進める。未処理の最小項がない、すなわち、全ての最小項を処理済である場合、処理をステップＳ３５に進める。

（ステップＳ２８）振分部１２０は、未処理の最小項のうちから１つの最小項を抽出する。以降のステップにおいて、本ステップＳ２８で抽出された最小項を単に“抽出された最小項”という。

（ステップＳ２９）振分部１２０は、抽出された最小項がフィルタで処理可能であるか否かを判定する。抽出された最小項がフィルタで処理可能である場合、処理をステップＳ３０に進める。抽出された最小項がフィルタで処理可能でない場合、処理をステップＳ３２に進める。ここで、フィルタで処理可能であるとは、抽出された最小項が条件判定の処理を示す情報であって、かつ、当該最小項に含まれる項目が定義ルール管理テーブル１１３の該当のイベントに対応する“含まれる項目”に存在する項目のみで処理可能なことを示す。例えば、ルールｒ１からは後述するように“Ｐ．ｐｏｗ＞５００”という条件判定の処理を示す情報が最小項として抽出され得る。この最小項は、イベント種別“Ｐ”についてのものである。定義ルール管理テーブル１１３によれば、この最小項は、ルールｄ１に登録された“Ｐ．ｐｏｗ”のみを得ることで処理可能である。よって、振分部１２０は“Ｐ．ｐｏｗ＞５００”をフィルタで処理可能な最小項と判定する。また、例えば、ルールｒ１からは後述するように“Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”という処理を示す情報が最小項として抽出され得る。この場合、振分部１２０は、当該最小項が条件判定の処理ではないため、当該最小項がフィルタで処理可能ではないと判定する。

（ステップＳ３０）振分部１２０は、抽出された最小項が入力されたイベントデータ内の項目に関する条件のみであるか否かを判定する。入力されたイベントデータ内の項目に関する条件のみである場合、処理をステップＳ３１に進める。入力されたイベントデータ内の項目に関する条件のみではない場合、処理をステップＳ３３に進める。例えば、前述したルールｒ１から抽出され得る最小項“Ｐ．ｐｏｗ＞５００”は、入力されるイベントデータに含まれる“Ｐ．ｐｏｗ”のみを用いて処理可能である。よって、振分部１２０は、当該最小項について入力されたイベントデータ内の項目に関する条件のみであると判定する。一方、例えば、ルールｒ３から抽出され得る最小項“Ａ．Ｈｏｍｅ．ｐｏｗ＞Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ”はルールｄ６で示されるＪＯＩＮ処理の結果得られる項目を含む。よって、振分部１２０は、当該最小項については入力されたイベントデータ内の項目に関する条件のみではないと判定する。

（ステップＳ３１）振分部１２０は、抽出されたルールについて、制御テーブル１１４の前段フィルタの項目に、抽出された最小項を登録する。例えば、振分部１２０は、ルールｒ１について抽出された最小項“Ｐ．ｐｏｗ＞５００”を、制御テーブル１１４におけるＮｏ．“ｒ１”の前段フィルタの項目に登録する。そして、処理をステップＳ２７に進める。

（ステップＳ３２）振分部１２０は、抽出されたルールについて、制御テーブル１１４の主処理の項目に、抽出された最小項を登録する。例えば、振分部１２０は、ルールｒ１について抽出された最小項“Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”を制御テーブル１１４におけるＮｏ．“ｒ１”の主処理の項目に登録する。そして、処理をステップＳ３４に進める。

（ステップＳ３３）振分部１２０は、抽出されたルールについて、制御テーブル１１４の後段フィルタの項目に、抽出された最小項を登録する。例えば、振分部１２０は、ルールｒ３について抽出された最小項“Ａ．Ｈｏｍｅ．ｐｏｗ＞Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ”を、制御テーブル１１４におけるＮｏ．“ｒ３”の後段フィルタの項目に登録する。そして、処理をステップＳ３４に進める。

（ステップＳ３４）振分部１２０は、抽出されたルールについて、後段フィルタまたは主処理で使用されるウィンドウがある場合、当該ウィンドウを示す情報を制御テーブル１１４の状況（ウィンドウ）の項目に登録する。そして、処理をステップＳ２７に進める。例えば、ステップＳ３２で例示した最小項“Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”では、ルールｄ４で定義されるウィンドウ“Ｈｏｍｅ．ｐｏｗ”を使用している。よって、振分部１２０は、ルールｒ１について“Ｈｏｍｅ．ｐｏｗ”を、制御テーブル１１４におけるＮｏ．“ｒ１”の状況（ウィンドウ）の項目に登録する。なお、振分部１２０は、抽出されたルールについて、後段フィルタまたは主処理で使用されるウィンドウがない場合、状況（ウィンドウ）への登録は行わない。

（ステップＳ３５）振分部１２０は、ステップＳ２２による組替え後の処理ルールに含まれる全てのルールについて、ステップＳ２３以降のステップを実行したか否かを判定する。全てのルールについて処理済である場合、処理をステップＳ３６に進める。未処理のルールがある場合、処理をステップＳ２３に進める。

（ステップＳ３６）振分部１２０は、制御テーブル１１４を最適化して、制御テーブル１１４ａを作成する。具体的な方法は、図１４で示した通りである。最適化により、ＪＯＩＮ結果として取得する項目を最小限に絞り込み、ＪＯＩＮ以降の処理を簡素化する。

このようにして、振分部１２０は、ルールセット１１２に基づいて制御テーブル１１４を作成する。また、振分部１２０は、制御テーブル１１４に基づいて制御テーブル１１４ａを作成する。

なお、ステップＳ２９において、抽出された最小項がフィルタで処理可能でない場合としては、例えば、当該最小項が主処理内の特殊な関数を用いた条件判定を示す情報である場合も考えられる。この場合、当該関数の結果により得られる項目を事前に把握することの難しいことがあり、当該関数により得られる項目を定義ルール管理テーブル１１３で管理することが難しいことがあるからである。ただし、当該関数により得られる結果を事前に把握できる場合には、定義ルール管理テーブル１１３で管理してもよい。

次に、ステップＳ２２のＡＮＤを用いたルール組替えの例を説明する。
図１７は、第２の実施の形態のルール組替えの例を示す図である。処理ルール１１２ｂには、“ＯＲ”を含むルールが記述されていないため、図１７では新たにルールｒ４を例示している。ルールｒ４は本例を説明するために新たに図示したものであり、ルールセット１１２との関連はない。ここで、ルールｒ４では、“ＩＦ Ｘ＝Ａ ＡＮＤ （Ｙ＝Ｂ ＯＲ Ｚ＝Ｃ） ＴＨＥＮ ＳＥＴ Ｗ＝Ａ；”と記述されている。

まず、振分部１２０は、ルールｒ４を、ＡＮＤ条件でまとめた条件をＯＲで結合する形の論理式を用いた等価な１つのルールｒ５となるように書き換える。ルールｒ５は、“ＩＦ （Ｘ＝Ａ ＡＮＤ Ｙ＝Ｂ） ＯＲ （Ｘ＝Ａ ＡＮＤ Ｚ＝Ｃ） ＴＨＥＮ ＳＥＴ Ｗ＝Ａ；”である。

更に、振分部１２０は、ルールｒ５にＯＲ条件が含まれるため、ルールｒ５と等価な（すなわち、ルールｒ４と等価な）ＡＮＤ条件のみからなる複数のルールｒ６，ｒ７となるようにルールｒ５を書き換える。ルールｒ６は、“ＩＦ Ｘ＝Ａ ＡＮＤ Ｙ＝Ｂ ＴＨＥＮ ＳＥＴ Ｗ＝Ａ；”である。ルールｒ７は、“ＩＦ Ｘ＝Ａ ＡＮＤ Ｚ＝Ｃ ＴＨＥＮ ＳＥＴ Ｗ＝Ａ；”である。

このように、振分部１２０は、“ＯＲ”を含んで記述されたルールｒ４を、“ＯＲ”を含まないように記述されたルールｒ６，ｒ７に組替える。これにより、“ＯＲ”を含んで記述されたルールｒ４があったとしても、前段フィルタ、ＪＯＩＮ処理、後段フィルタおよび主処理への振分処理を適切に行える。このような組替えを行わないとすると、“ＯＲ”で結ばれた条件判定部分の振分が容易でない。“ＯＲ”で結ばれた２つの条件判定の結果に応じて“ＩＦ”で示される全体の条件判定の結果が変わることになり、“ＩＦ”で示される全体の条件判定の結果の導出が複雑化するからである。

次に、図１６のステップＳ２６におけるルール分解の例を説明する。
図１８は、第２の実施の形態のルール分解の例を示す図である。図１８（Ａ）はルールｒ１のルール分解を例示している。ルールｒ１には、“ＩＦ”および“ＴＨＥＮ”の定型句を用いて、条件判定部分ｒ１１（条件判定の処理を示す情報）と主処理部分ｒ１ａ（主処理を示す情報）とが含まれている。条件判定部分ｒ１１および主処理部分ｒ１ａは、それぞれ１つの判定または処理を示しており、これ以上分解できないので、ルールｒ１における２つの最小項である。

振分部１２０は、“ＩＦ”の直後に続く“Ｐ．ｐｏｗ＞５００”を条件判定部分ｒ１１と判断する。振分部１２０は、“ＴＨＥＮ”の直後に続く“Ｓｅｔ Ｐ．Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”を主処理部分ｒ１ａと判断する。振分部１２０は、このようにしてルールｒ１を条件判定部分ｒ１１および主処理部分ｒ１ａの２つの最小項に分解する。

図１６で説明した手順によれば、振分部１２０は、条件判定部分ｒ１１を前段フィルタに振り分ける。条件判定部分ｒ１１は、イベントデータに含まれる項目のみを用いて処理可能だからである。振分部１２０は、主処理部分ｒ１ａを主処理に振り分ける。主処理部分ｒ１ａは、条件判定以外の処理を含んでおりフィルタ処理可能ではないからである。

図１８（Ｂ）はルールｒ２のルール分解を例示している。ルールｒ２には、“ＩＦ”および“ＴＨＥＮ”の定型句を用いて、条件判定部分ｒ２１と主処理部分ｒ２ａとが含まれている。条件判定部分ｒ２１および主処理部分ｒ２ａは、それぞれ１つの判定または処理を示しており、これ以上分解できないので、ルールｒ２における２つの最小項である。

振分部１２０は、“ＩＦ”の直後に続く“Ａ．ｔｅｍｐ＞２５”を条件判定部分ｒ２１と判断する。振分部１２０は、“ＴＨＥＮ”の直後に続く“Ｓｅｎｄ Ａ．ｍｓｇ＝“・・・””を主処理部分ｒ２ａと判断する。振分部１２０は、このようにしてルールｒ２を条件判定部分ｒ２１および主処理部分ｒ２ａの２つの最小項に分解する。

図１６で説明した手順によれば、振分部１２０は、条件判定部分ｒ２１を前段フィルタに振り分ける。条件判定部分ｒ２１は、イベントデータに含まれる項目のみを用いて処理可能だからである。振分部１２０は、主処理部分ｒ２ａを主処理に振り分ける。主処理部分ｒ２ａは、条件判定以外の処理を含んでおりフィルタ処理可能ではないからである。

図１８（Ｃ）はルールｒ３のルール分解を例示している。ルールｒ３には、“ＩＦ”、“ＡＮＤ”および“ＴＨＥＮ”の定型句を用いて、条件判定部分ｒ３１，ｒ３２，ｒ３３および主処理部分ｒ３ａが含まれている。条件判定部分ｒ３１，ｒ３２，ｒ３３および主処理部分ｒ３ａは、ルールｒ３における４つの最小項である。

振分部１２０は、“ＩＦ”の直後に続く“Ａ．ｔｅｍｐ＞２０”を条件判定部分ｒ３１と判断する。振分部１２０は、条件判定部分ｒ３１の次の“ＡＮＤ”の直後に続く“Ａ．ｔｅｍｐ＜＝２５”を条件判定部分ｒ３２と判断する。振分部１２０は、条件判定部分ｒ３２の次の“ＡＮＤ”の直後に続く“Ａ．Ｈｏｍｅ．ｐｏｗ＞Ａ．Ｈｏｍｅ．ｍａｘｐｏｗ”を条件判定部分ｒ３３と判断する。振分部１２０は、“ＴＨＥＮ”の直後に続く“Ｃｏｎｔ Ａ．ｔｅｍｐ−＝２”を主処理部分ｒ３ａと判断する。振分部１２０は、このようにしてルールｒ３を条件判定部分ｒ３１，ｒ３２，ｒ３３および主処理部分ｒ３ａの４つの最小項に分解する。

図１６で説明した手順によれば、振分部１２０は、条件判定部分ｒ３１，ｒ３２を前段フィルタに振り分ける。条件判定部分ｒ３１，ｒ３２は、イベントデータに含まれる項目のみを用いて処理可能だからである。振分部１２０は、条件判定部分ｒ３３を後段フィルタに振り分ける。条件判定部分ｒ３３は、ルールｄ５のＪＯＩＮ結果を用いるからである。振分部１２０は、主処理部分ｒ３ａを主処理に振り分ける。主処理部分ｒ３ａは、条件判定以外の処理を含んでおりフィルタ処理可能でなないからである。

なお、以上のような定型句および分解判断のための情報は振分部１２０に予め与えられる。
次に、図１５のステップＳ１５の処理を詳細に説明する。

図１９は、第２の実施の形態のイベント処理の例を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。
（ステップＳ４１）処理部１３０は、制御テーブル１１４ａに基づいて、受信したイベントデータのイベント種別に対応するルールについて、前段フィルタがあるか否かを判定する。前段フィルタがある場合、処理をステップＳ４２に進める。前段フィルタがない場合、処理をステップＳ４３に進める。例えば、イベントデータ２１０のイベント種別は“Ｐ”である。制御テーブル１１４ａにおいて、イベント種別“Ｐ”に対応するルールはルールｒ１（Ｎｏ．“ｒ１”）である。ルールｒ１に対し、制御テーブル１１４ａの前段フィルタの項目には条件判定を示す情報の登録がある。よって、処理部１３０はイベントデータ２１０に対して前段フィルタがあると判定する。また、例えば、イベントデータ２２０のイベント種別は“Ａ”である。制御テーブル１１４ａにおいて、イベント種別“Ａ”に対応するルールはルールｒ２，ｒ３（Ｎｏ．“ｒ２”，“ｒ３”）である。当該ルールｒ２，ｒ３に対し、制御テーブル１１４ａの前段フィルタの項目には条件判定を示す情報の少なくとも１つの登録がある（この場合は２つともである）。よって、処理部１３０はイベントデータ２２０に対して前段フィルタがあると判定する。

（ステップＳ４２）前段フィルタ部１３１は、ステップＳ４１で前段フィルタがあると判定されたルールについて、制御テーブル１１４ａ内の前段フィルタの条件判定を実行する。前段フィルタ部１３１は、当該条件判定の結果が真であるか否かを判定する。条件判定の結果が真である場合、処理をステップＳ４３に進める。条件判定の結果が偽である場合、処理を終了する。なお、前段フィルタ部１３１は、ルールごとに前段フィルタの判定を行う。例えば、イベントデータ２２０に対して、ルールｒ２，ｒ３で前段フィルタが存在している。前段フィルタ部１３１は、ルールｒ２，ｒ３のそれぞれについて前段フィルタを評価する。この場合、ルールｒ２，ｒ３の何れについても条件判定の結果が偽であれば処理を終了する。少なくとも１つの条件判定の結果が真であれば、処理をステップＳ４３に進める。処理部１３０は、ステップＳ４２で条件判定の結果が偽であったルールに関しては、ステップＳ４３以降の処理は行わない。イベントデータ２２０の例では“ｔｅｍｐ＝２２”である。したがって、ルールｒ２の前段フィルタの結果は偽であり、ルールｒ３の前段フィルタの結果は真である。よって、ルールｒ２，ｒ３のうちルールｒ３のみが以降のステップの処理対象となる。

（ステップＳ４３）処理部１３０は、制御テーブル１１４ａに基づいて、受信したイベントデータのイベント種別に対応するルールについて、ＪＯＩＮ処理があるか否かを判定する。ＪＯＩＮ処理がある場合、処理をステップＳ４４に進める。ＪＯＩＮ処理がない場合、処理をステップＳ４７に進める。例えば、イベントデータ２１０に対応するルールは前述したようにルールｒ１である。ルールｒ１に対し、制御テーブル１１４ａのＪＯＩＮの項目には、ＪＯＩＮ処理を示す情報の登録がある。よって、処理部１３０はイベントデータ２１０に対してＪＯＩＮ処理があると判定する。なお、ステップＳ４２で前段フィルタの条件判定を行っている場合、前述したように本ステップＳ４３の判定の対象となるのは前段フィルタの判定結果が真であったルールに限られる。

（ステップＳ４４）ＪＯＩＮ部１３２は、ステップＳ４３でＪＯＩＮ処理があると判定されたルールについて、制御テーブル１１４ａ内のＪＯＩＮ処理を実行する。ＪＯＩＮ処理の実行結果は、受信したイベントデータに対するイベント処理が終了するまでＲＡＭ１０２上に保持される。

（ステップＳ４５）処理部１３０は、制御テーブル１１４ａに基づいて、ステップＳ４４のＪＯＩＮ処理を行ったルールについて後段フィルタがあるか否かを判定する。後段フィルタがある場合、処理をステップＳ４６に進める。後段フィルタがない場合、処理をステップＳ４７に進める。例えば、イベントデータ２１０について、ステップＳ４４でルールｒ１に対応するＪＯＩＮ処理が実行された場合を考える。この場合、ルールｒ１に対し、制御テーブル１１４ａの後段フィルタの項目は設定なしである。よって、処理部１３０はイベントデータ２１０に対しては後段フィルタがないと判定する。また、例えば、イベントデータ２２０について、ステップＳ４４でルールｒ３に対応するＪＯＩＮ処理が実行された場合を考える。この場合、ルールｒ３に対し、制御テーブル１１４ａの後段フィルタの項目には、条件判定の処理を示す情報の登録がある。よって、処理部１３０は、イベントデータ２２０に対しては後段フィルタがあると判定する。

（ステップＳ４６）後段フィルタ部１３３は、ステップＳ４５で後段フィルタがあると判定されたルールについて、制御テーブル１１４ａ内の後段フィルタの条件判定を実行する。後段フィルタ部１３３は、当該条件判定の結果が真であるか否かを判定する。条件判定の結果が真である場合、処理をステップＳ４７に進める。条件判定の結果が偽である場合、処理を終了する。

（ステップＳ４７）処理部１３０は、制御テーブル１１４ａに基づいて、受信したイベントデータのイベント種別に対応するルールについて、主処理があるか否かを判定する。主処理がある場合、処理をステップＳ４８に進める。主処理がない場合、処理を終了する。なお、ステップＳ４２で前段フィルタの条件判定を行っている場合、前述したように本ステップＳ４７の判定の対象となるのは前段フィルタの判定結果が真であったルールに限られる。

（ステップＳ４８）主処理部１３４は、ステップＳ４７で主処理があると判定されたルールについて、当該主処理内に条件判定があるか否かを判定する。当該主処理内に条件判定がある場合、処理をステップＳ４９に進める。当該主処理内に条件判定がない場合、処理をステップＳ５０に進める。

（ステップＳ４９）主処理部１３４は、主処理内の条件判定を評価し、評価結果が真であるか否かを判定する。評価結果が真である場合、処理をステップＳ５０に進める。評価結果が偽である場合、処理を終了する。

（ステップＳ５０）主処理部１３４は、主処理内の後続処理を実行する。主処理内の後続処理とは、例えば、出口処理を呼び出してイベントデータ３１０を生成する処理である。また、当該イベントデータ３１０を制御対象の空調機６０に送信する処理も含まれ得る。別の例として、ｒ１に対する主処理部１３４の動作は、イベントに含まれる値“Ｐ．ｐｏｗ”を該当する家の消費電力としてウィンドウ“Ｈｏｍｅ．ｐｏｗ”に設定する。

このようにして、処理部１３０は、イベントデータを受信すると、制御テーブル１１４ａに登録された手順に従って、イベントデータに応じた処理を実行する。
図２０は、第２の実施の形態のイベント処理の例を示す図である。図２０では、ルールセット１１２に対して作成された制御テーブル１１４ａに基づいて、ルールｒ１，ｒ２，ｒ３を前段フィルタ、ＪＯＩＮ、後段フィルタおよび主処理に振り分けて処理する際の処理順序を示している。ただし、図２０では各処理を示す情報に対して“ＩＦ”および“ＴＨＥＮ”の文字列を付加して示している。また、ＪＯＩＮおよび後段フィルタの登録がない箇所については“ＮＯＮＥ”と表記している。

例えば、消費電力計測器５０からイベントデータ２１０がサーバ１００に入力された場合を考える。イベントデータ２１０のイベント種別は“Ｐ”なので、イベント種別“Ｐ”に対応するルールｒ１が実行される。このとき、ルールｒ１の最小項で示される各処理は、制御テーブル１１４ａに基づいて次の順序で実行される。

（１）前段フィルタ部１３１は、条件判定部分ｒ１１に対応する条件判定を実行する。イベントデータ２１０では、“Ｐ．ｐｏｗ＝１５１０”なので、条件判定部分ｒ１１の処理結果は真である。したがって、次のＪＯＩＮ部１３２の処理が実行される。

（２）ＪＯＩＮ部１３２は、ルールｄ５ａを実行する。ルールｄ５ａは、ルールｄ５を最適化した後のＪＯＩＮ処理を記述したルールである。ルールｄ５ａの実行結果として“Ｈｏｍｅ．ｉｄ＝０００１”が得られる。ルールｒ１に対して後段フィルタは存在しない。このため、後段フィルタ部１３３の処理はスキップされ、次に主処理部１３４の処理が実行される。

（３）主処理部１３４は、主処理部分ｒ１ａに対応する処理を実行する。具体的には、主処理部１３４は、ＪＯＩＮ部１３２によるＪＯＩＮ結果によって得られた“Ｈｏｍｅ．ｉｄ”を用いて、“Ｓｅｔ Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”を実行する。その結果、当該“Ｈｏｍｅ．ｉｄ＝０００１”で指定されるウィンドウ“Ｈｏｍｅ（０００１）．ｐｏｗ”に“Ｐ．ｐｏｗ＝１５１０”が設定される。

イベントデータ２１０に続いて、空調機６０からイベントデータ２２０がサーバ１００に入力された場合を考える。イベントデータ２２０のイベント種別は“Ａ”なので、イベント種別“Ａ”に対応するルールｒ２，ｒ３が実行される。このとき、ルールｒ２，ｒ３の最小項で示される各処理は、制御テーブル１１４ａに基づいて次の順序で実行される。

まず、ルールｒ２について説明する。
（１）前段フィルタ部１３１は、条件判定部分ｒ２１に対応する条件判定の処理を実行する。イベントデータ３１０では、“Ａ．ｔｅｍｐ＝２２”なので、条件判定部分ｒ２１の処理結果は偽である。したがって、イベントデータ２２０に対するルールｒ２の処理は前段フィルタ部１３１で終了する。

次に、ルールｒ３について説明する。
（１）前段フィルタ部１３１は、条件判定部分ｒ３１ａに対応する条件判定の処理を実行する。ここで、条件判定部分ｒ３１ａで記述される“Ａ．ｔｅｍｐ＞２０ ＡＮＤ Ａ．ｔｅｍｐ＜＝２５”は、ルールｒ３の条件判定部分ｒ３１，ｒ３２を前段フィルタ用にマージしたものである。イベントデータ２２０では、“Ａ．ｔｅｍｐ＝２２”なので、条件判定部分ｒ３１ａの処理結果は真である。したがって、次のＪＯＩＮ部１３２の処理が実行される。

（２）ＪＯＩＮ部１３２は、ルールｄ６ａを実行する。ルールｄ６ａは、ルールｄ６を最適化した後のＪＯＩＮ処理を記述したルールである。ルールｄ６ａの実行結果として“Ｈｏｍｅ．ｉｄ＝０００１”および“Ｈｏｍｅ．ｍａｘｐｏｗ＝１５００”が得られる。

（３）後段フィルタ部１３３は、ＪＯＩＮ部１３２によるＪＯＩＮ結果によって得られた“Ｈｏｍｅ．ｉｄ”および“Ｈｏｍｅ．ｍａｘｐｏｗ”を用いて、“Ｈｏｍｅ．ｐｏｗ＞Ｈｏｍｅ．ｍａｘｐｏｗ”の条件判定部分ｒ３３を実行する。イベントデータ２１０の入力によって、“Ｈｏｍｅ．ｉｄ＝０００１”で指定されるウィンドウ“Ｈｏｍｅ（０００１）．ｐｏｗ”の値は“１５１０”に設定されている。したがって、条件判定部分ｒ３３の処理結果は真である。よって、次の主処理部１３４の処理が実行される。

（４）主処理部１３４は、主処理部分ｒ３ａに対応する処理を実行する。具体的には、主処理部１３４は、空調機６０の設定温度を２℃下げるように制御するためのイベントデータ３１０を生成する。サーバ１００は、生成されたイベントデータ３１０を空調機６０に送信する。

このように、定義ルール１１２ａおよび処理ルール１１２ｂに含まれる各ルールを前段フィルタ、ＪＯＩＮ、後段フィルタおよび主処理に振り分けることで、ＪＯＩＮや主処理が無駄に実行されないようにイベントデータに対する処理の順序を制御することができる。

図２１は、ルールセットの比較例（その１）を示す図である。ルールセット１１５は、ルールセット１１２と等価な処理を記述したものである。ルールセット１１５は、ルールｒ１０１，ｒ１０２，ｒ１０３，ｒ１０４，ｒ１０５を含む。

ルールｒ１０１は、イベント種別“Ｐ”のイベントデータを受信した時に、ルールｄ５に相当するＪＯＩＮ処理を実行するように記述されたルールである。ルールｒ１０２は、イベント種別“Ａ”のイベントデータを受信した時に、ルールｄ６に相当するＪＯＩＮ処理を実行するように記述されたルールである。

ルールｒ１０３は、ルールｒ１と同じ処理を記述したルールである。ルールｒ１０４は、ルールｒ２と同じ処理を記述したルールである。ルールｒ１０５は、ルールｒ３と同じ処理を記述したルールである。

ルールの記述方法として、ルールセット１１５のように、ある条件（ＩＦ節）が満たされた場合に、後続する処理（ＴＨＥＮ節）を実行するようにルールを記述することが考えられる。ところが、第２の実施の形態のルール振分を行わずに、ルールセット１１５に基づいてイベント処理を行おうとすると、ＪＯＩＮ処理が無駄に実行され得る。具体的には次の通りである。

例えば、イベント種別“Ｐ”のイベントデータを受信した場合、ルールｒ１０１を実行した後に、ルールｒ１０３を実行することになる。このとき、ルールｒ１０３の条件判定部分が偽であれば、ルールｒ１０３の（ルールｒ１０１のＪＯＩＮ結果を用いる）後続の処理は実行されない。また、ルールｒ１０３よりも後の処理でイベント種別“Ｐ”に関するルールはない。すると、この場合、ルールｒ１０３ではＪＯＩＮ処理が無駄に実行されたことになる。また、ｒ１０１のＪＯＩＮ処理は“Ｓｅｌｅｃｔ ＊”になっているので、後段の処理で不要な値も取得してしまい、処理時間を要するだけでなく、メモリも余計に消費する。これらの課題は、イベント種別“Ａ”のイベントデータを受信した場合も同様である。

特に、ＪＯＩＮ処理は処理自体の負荷が高く、ＪＯＩＮ処理を余計に実行してしまうことは各イベントに対する応答遅延に大きく影響し得る。
図２２は、ルールセットの比較例（その２）を示す図である。ルールセット１１６は、ルールセット１１２と等価な処理を記述したものである。ルールセット１１６は、ＣＥＰ用のツールであるＥＳＰＥＲにおいて、所定のイベント処理言語（ＥＰＬ：Event Processing Language）を用いてルールを記述したものである。ルールセット１１６は、ルールｒ１１１，ｒ１１２，ｒ１１３，ｒ１１４，ｒ１１５，ｒ１１６を含む。

ルールｒ１１１は、ルールｄ１と同じ定義を記述したルールである。ルールｒ１１２は、ルールｄ２と同じ定義を記述したルールである。ルールｒ１１３は、ルールｄ４と同じ定義を記述したルールである。

ルールｒ１１４は、ルールｄ５，ｒ１に相当する処理を１つにまとめて記述したルールである。ルールｒ１１４では２行目の“ｆｒｏｍ”で指定される節が最初に評価される。具体的には、イベント種別“Ｐ”というイベントに対し、ルールｄ５に相当するＪＯＩＮ処理を実行した後に、ルールｒ１に相当する処理を実行する。

ルールｒ１１５は、ルールｒ２と同じ処理を記述したルールである。
ルールｒ１１６は、ルールｄ６，ｒ３に相当する処理を１つにまとめて記述したルールである。具体的には、イベント種別“Ａ”というイベントに対し、ルールｄ６に相当するＪＯＩＮ処理を実行した後に、ルールｒ３に相当する処理を実行する。

ルールの記述方法として、ルールセット１１６のような手法も考えられる。ところが、第２の実施の形態のルール振分を行わずに、ルールセット１１６に基づいてイベント処理を行おうとすると、ＪＯＩＮ処理が無駄に実行され得る。具体的には次の通りである。

例えば、ルールｒ１１４のような記述だと、イベント種別“Ｐ”に対してルールｄ５に相当するＪＯＩＮが必ず実行される。しかし、その後の条件判定部分ｒ１１に相当する判定“Ｐ（ｐｏｗ＞５００） ａｓ ｐ”が偽であれば、後続する主処理部分ｒ１ａに相当する処理“ｉｎｓｅｒｔ ｉｎｔｏ ＨｏｍｅＰｏｗｅｒＷｉｎｄｏｗ ｓｅｌｅｃｔ ｈ．Ｈｏｍｅ ａｓ ｈｏｍｅＩｄ， ｐ．ｐｏｗ ａｓ ｐｏｗ”は実行されない。すると、この場合、ルールｒ１１４ではＪＯＩＮ処理が無駄に実行されたことになる。

また、例えば、ルールｒ１１６のような記述だと、イベント種別“Ａ”に対してルールｄ６に相当するＪＯＩＮが必ず先に実行される。しかし、その後の条件判定部分ｒ３１ａに相当する判定“ａ．ｔｅｍｐ＞２０ ａｎｄ ａ．ｔｅｍｐ＜＝２５”が偽であれば、後続する主処理部分ｒ３ａに相当する処理“ｓｅｌｅｃｔ ａ．ｉｄ， ａ．ｔｅｍｐ−２ ａｓ ｔｅｍｐ”は実行されない。すると、この場合、ルールｒ１１６ではＪＯＩＮ処理が無駄に実行されたことになる。

ルールセット１１６のように、記述方法によっては無駄なＪＯＩＮが生じ得るＥＰＬも存在する。このようなＥＰＬでは、イベント処理時に無駄なＪＯＩＮが発生するか否かは、ルールを作成する者の配慮に委ねられてしまう。また、このようなＥＰＬを用いる場合、ルール内に記述された手続を逐次実行するためのＣＥＰエンジンによる処理負荷が高くなる可能性もある。

図２３は、第２の実施の形態の件数集計表の例を示す図である。件数集計表４００は、入力されるイベントデータに対し、第２の実施の形態のイベント処理方法を適用した場合の前段フィルタ、ＪＯＩＮ、後段フィルタおよび主処理における入力に対する出力件数を例示したものである。件数集計表４００は、ルールセット１１５，１１６の何れかを用いて第２の実施の形態のルール振分を行わずにイベント処理を行った場合のイベントの処理件数も比較例として例示している。件数集計表４００には、イベント、分布、％、入力、前段フィルタ、ＪＯＩＮ、後段フィルタ、主処理および出口処理の項目が示されている。

イベントの項目には、イベントの種別が表記されている。ここで例示するイベントの種別は、“Ｐ”、“Ａ”の２つである。何れのイベントに係るイベントデータも１００万件／秒の頻度で受信するものとする。なお、Ａイベントの直下の行は、ＰイベントとＡイベントとの合計についての処理件数を示す行である。ＰイベントとＡイベントとは共に１００万件／秒の頻度なので、両イベントを合計すると２００万件／秒の頻度である。更に、当該合計を示す行の直下の行は、比較例（第２の実施の形態のルール振分を行わない場合）の処理件数を示す行である。

分布の項目には、各イベントについての値の分布が表記されている。Ｐイベントでは、消費電力量の分布を次のように区分している。すなわち、ｐｏｗ＞１５００（Ｗｈ）の範囲、５００（Ｗｈ）＜ｐｏｗ≦１５００（Ｗｈ）の範囲およびｐｏｗ≦５００（Ｗｈ）の範囲である。Ａイベントでは、温度の分布を次のように区分している。すなわち、ｔｅｍｐ＞２５（℃）の範囲、２０（℃）＜ｔｅｍｐ≦２５（℃）の範囲およびｔｅｍｐ≦２０（℃）の範囲である。

％の項目には、受信するイベントデータのうち、各分布に属するものの割合を百分率で示した値が表記されている。入力の項目には、各イベントの件数に対して分布ごとに入力される件数が１秒間当たり何件であるかを示す値が表記されている。

具体的には、Ｐイベントでは、ｐｏｗ＞１５００（Ｗｈ）に属するイベントデータが１０％であり、入力件数が１００万件×０．１＝１０万件／秒である。５００（Ｗｈ）＜ｐｏｗ≦１５００（Ｗｈ）に属するイベントデータが２０％であり、入力件数が１００万件×０．２＝２０万件／秒である。ｐｏｗ≦５００（Ｗｈ）に属するイベントデータが７０％であり、入力件数が１００万件×０．７＝７０万件／秒である。

Ａイベントでは、ｔｅｍｐ＞２５（℃）に属するイベントデータが１０％であり、入力件数が１００万件×０．１＝１０万件／秒である。２０（℃）＜ｔｅｍｐ≦２５（℃）に属するイベントデータが２０％であり、入力件数が１００万件×０．２＝２０万件／秒である。ｔｅｍｐ≦２０（℃）に属するイベントデータが７０％であり、入力件数が１００万件×０．７＝７０万件／秒である。

なお、比較例については、ＰイベントおよびＡイベントの両方が上記と同じ頻度で入力されるものとする。比較例についての入力件数は２００万件／秒である。また、合計の行については、分布、および％の項目は“−”（ハイフン）を表記している。

前段フィルタ、ＪＯＩＮ、後段フィルタ、主処理および出口処理の項目には、各段階で処理の対象となり、処理結果として残るイベントの件数を示している。該当の処理が存在しない場合や、前段の処理によって後段の処理が実行されない箇所については、“−”（ハイフン）を表記している。

例えば、Ｐイベントに着目すると、各分布に対してルールｒ１の処理が次のように実行される。
（１）ｐｏｗ＞１５００（Ｗｈ）に属するイベントデータ１０万件／秒に対し、前段フィルタで１０万件／秒が処理されて１０万件／秒について真となる。次にＪＯＩＮで１０万件／秒が処理されて１０万件／秒についてＪＯＩＮ結果を得る。次に主処理で１０万件／秒が処理されて１０万件／秒の主処理結果を得る。

（２）５００（Ｗｈ）＜ｐｏｗ≦１５００（Ｗｈ）に属するイベントデータ２０万件／秒に対し、前段フィルタで２０万件／秒が処理されて２０万件／秒について真となる。次にＪＯＩＮで２０万件／秒が処理されて２０万件／秒についてＪＯＩＮ結果を得る。次に主処理で２０万件／秒が処理されて２０万件／秒の主処理結果を得る。

（３）ｐｏｗ≦５００（Ｗｈ）に属するイベントデータ７０万件／秒に対し、前段フィルタで７０万件／秒が処理されて０件／秒が真となる。すなわち、前段フィルタを通過するイベントデータは存在しない。このため、これらのイベントデータに対しては以降の処理は実行されない。

また、Ａイベントに着目すると、各分布に対してルールｒ２，ｒ３の処理が次のように実行される。
（１）ｔｅｍｐ＞２５（℃）に属するイベントデータ１０万件／秒に対し、前段フィルタで１０万件／秒が処理されて、ルールｒ２の条件判定部分ｒ２１に対し１０万件／秒が真となる。次に主処理では主処理部分ｒ２ａにつき１０万件／秒が処理されて１０万件／秒の主処理結果を得る。出口処理として、主処理の結果に応じて１０万件／秒の空調機の制御（レコメンドメッセージの表示）が行われる。

（２）２０（℃）＜ｔｅｍｐ≦２５（℃）に属するイベントデータ２０万件／秒に対し、前段フィルタでは２０万件／秒が処理されて、ルールｒ３の条件判定部分ｒ３１ａに対し２０万件／秒が真となる。次にＪＯＩＮで２０万件／秒が処理されて２０万件／秒についてＪＯＩＮ結果を得る。次に後段フィルタでは２０万件／秒が処理されて条件判定部分ｒ３３に対し２万件／秒が真となる。次に主処理では主処理部分ｒ３ａにつき２万件／秒が処理されて２万件／秒の主処理結果を得る。出口処理として、主処理の結果に応じて２万件／秒の空調機の制御（設定温度の２℃低下）が行われる。

（３）ｔｅｍｐ≦２０（℃）に属するイベントデータ７０万件／秒に対し、前段フィルタで７０万件／秒が処理されて条件判定部分ｒ２１および条件判定部分ｒ３１ａについて０件が真となる。すなわち、前段フィルタを通過するイベントデータは存在しない。このため、これらのイベントデータに対しては以降の処理は実行されない。

以上の件数をイベント頻度の合計に対してまとめると、前段フィルタによって、入力される２００万件／秒のイベントが６０万件／秒に絞り込まれる。その６０万件／秒のうち、ＪＯＩＮを実行するものは５０万件／秒である。更に、後段フィルタによって、ルールｒ３に関するＪＯＩＮ件数２０万件／秒に対して主処理を実行すべき件数が、２万件／秒に絞り込まれる。その結果、主処理を実行すべき件数の合計が４２万件／秒にまで絞り込まれる。そのうち、ルールｒ２，ｒ３に基づいて出口処理を行うものは１２万件／秒である。

これに対し、比較例では、入力件数２００万件／秒に対して、実行されるＪＯＩＮの件数は、２００万件／秒である。ルールセット１１５，１１６で説明したように、１つのＰイベントに対して必ずＪＯＩＮが１回実行されるし、１つのＡイベントに対しても必ずＪＯＩＮが１回実行されるからである。そして、各ＪＯＩＮに対して、各ルールで示される主処理を１回実行する。例えば、ルールセット１１５でいえば、当該主処理はルールｒ１０３（Ｐイベント）やルールｒ１０５（Ａイベント）に相当する。

また、ルールセット１１６でいえば、Ｐイベントに対する当該主処理は、ルールｒ１１４の“Ｐ（ｐｏｗ＞５００） ａｓ ｐ；”および“ｉｎｓｅｒｔ ｉｎｔｏ ＨｏｍｅＰｏｗｅｒＷｉｎｄｏｗ ｓｅｌｅｃｔ ｈ．Ｈｏｍｅ ａｓ ｈｏｍｅＩｄ， ｐ．ｐｏｗ ａｓ ｐｏｗ”に相当する。また、ルールセット１１６でいえば、Ａイベントに対する当該主処理は、ルールｒ１１６の“ｗｈｅｒｅ ｈｐｗ．ｈｏｍｅＩｄ＝ｈ．Ｈｏｍｅ ａｎｄ ａ．ｔｅｍｐ＞２０ ａｎｄ ａ．ｔｅｍｐ＜＝２５ ａｎｄ ｈｐｗ．ｐｏｗ＞ｈ．Ｍａｘｐｏｗ”および“ｓｅｌｅｃｔ ａ．ｉｄ， ａ．ｔｅｍｐ−２ ａｓ ｔｅｍｐ”に相当する。

更にルールが増えた場合に、ルールセット１１６のケースではルールごとに必要なＪＯＩＮ処理を記述するため、１つのイベントに対して複数回のＪＯＩＮを実行してしまうケースも生じる。

比較例においても、当該主処理の結果、最終的な出口処理は１２万件／秒となる。
第２の実施の形態のルール振分を行うことで、ルール振分を行わない場合に比べて、ＪＯＩＮ処理を２００万件／秒から５０万件／秒に削減している。これは、前段フィルタによって、ＪＯＩＮ処理を実行すべきイベントを事前に絞り込むからである。また、主処理を実行するイベントを４２万件／秒に削減している。これは、後段フィルタによって、主処理を実行すべきイベントを事前に絞り込むからである。

このようにして、サーバ１００は、ルールセット１１２に対して実行する処理を効率的に削減することができる。その結果、イベントに対して実行される処理の数が軽減され、所定時間当たりに処理できるイベントの数が向上する。また、無駄な処理の発生による他のイベントの処理待ちが改善されるので、イベントの発生に対して処理が実行されるまでの遅延を軽減できる。特に、ＪＯＩＮのような負荷の高い処理を削減できるため、高速化への寄与は大きい。このようにして、ＣＥＰにおける応答速度の高速化を図れる。

また、ルール振分を行うことで、フィルタ処理とそれ以外の処理とを明確に分けた実装が可能となる。フィルタ処理部分を分けられるため、当該フィルタ処理部分（前段フィルタ部１３１および後段フィルタ部１３３）について、レジスタを用いて高速に処理するような専用のモジュール（条件判定手段）を用いて実装することも可能である。このため、イベントに対して高速な条件判断が可能なＣＥＰエンジンを容易に実現し得る。

また、振分部１２０によって、ルールセット１１２に基づき自動的に制御テーブル１１４ａ（あるいは制御テーブル１１４）を作成する。このため、ルールセット１１５，１１６で例示したようにルールの作成者が処理効率の悪い（無駄にＪＯＩＮを実行してしまうような）処理手順を記述したとしても、制御テーブル１１４ａ（あるいは制御テーブル１１４）に基づいてイベント処理を効率的に行うことができる。その結果、ルールの作成者に処理手順を意識したルールの記述を強いずに済む。よって、ルールの作成に伴う作成者の作業の省力化を図れる。

また、振分部１２０は、ルールセット１１２で示したように定義ルール１１２ａおよび処理ルール１１２ｂの個別の入力を許容する。このため、ルールの作成者は、定義部分と処理部分とを明確に分類した記述が可能である。これによって、ルールの作成者は、一層効率的な記述が可能である。処理ルール１１２ｂで汎用的に用いられる内容を定義ルール１１２ａに一括して記述できるからである。これにより、処理ルール１１２ｂ内でのＪＯＩＮ処理の定義なしに、ＪＯＩＮ処理の結果を用いた条件判定を処理ルール１１２ｂに記述することが可能となる。このため、記述するルールを低減でき、ルールの作成に伴う作成の作業の省力化を図れる。

また、処理ルール１１２ｂでは、１つのルールを“ＩＦ”および“ＴＨＥＮ”などを用いて、条件部＋処理部のように短冊状に記述することを許容する。このため、記述し易く、また、メンテナンスも行い易い処理ルールの記述が可能となる。

なお、ルールセット１１２だけでなく、ルールセット１１５，１１６についても振分部１２０への入力を許容する。振分部１２０は、ルールセット１１５，１１６に対しても、ルールセット１１２と同様にして、制御テーブル１１４ａを作成することができる。例えば、ルールセット１１５であれば、ルールセット１１２と同様に“ＩＦ”や“ＴＨＥＮ”などの定型句に基づいて条件判定部分、主処理部分およびＪＯＩＮ処理などを判別できる。ルールセット１１６でも“ｆｒｏｍ”や“ｉｎｓｅｒｔ”、“ｓｅｌｅｃｔ”、“ｓｑｌ”、“ｗｈｅｒｅ”などの定型句に基づいて条件判定部分、主処理部分およびＪＯＩＮ処理などを判別できる。

更に、例え主処理の負荷が高かったとしても、処理数の削減によって、全体の処理性能は確保されるため、サーバの処理能力が比較的低くても、求める処理性能を達成できる可能性が高まる。したがって、サーバに求められる処理能力を抑えることができ、コスト面でも有利である。

また、第２の実施の形態の説明では、消費電力計測器５０および空調機６０からのイベントに対して空調機６０の動作を制御する例を説明したが、携帯端末装置４０、携帯電話機７０および宅内電力管理装置８０に対しても同様にしてイベント処理を実行できる。また、第２の実施の形態では、家電機器関連の制御を行う場合を例示したが、第２の実施の形態のイベント処理の方法は他の情報処理システムに適用することもできる。例えば、病院内で医療機器が発行するイベントに応じた処理を実行する情報処理システムが考えられる。また、例えば、工場などで業務用機器が発行するイベントに応じた処理を実行する情報処理システムが考えられる。

以上のように、第２の実施の形態のサーバ１００によれば、イベントに対して効率的に処理を実行することができる。また、そのようなイベント処理を効率的に支援することができる。

［第３の実施の形態］
以下、第３の実施の形態を説明する。前述の第２の実施の形態との相違点を主に説明し、共通の事項の説明を省略する。

第２の実施の形態では、受信したイベントデータに対して、制御テーブル１１４ａを参照しながら、処理順を制御し、各処理を実行していく場合を例示した。一方、イベント処理の高速化を図るために、制御テーブル１１４ａの内容あるいは外部データをＲＡＭ１０２上に構造体（または、オブジェクト）および構造体間のリンクとして予め展開しておき、これを制御情報として参照しながらイベント処理を行うことが考えられる。第３の実施の形態では、そのための方法を説明する。

ここで、第３の実施の形態の情報処理システムおよび各装置は、図２で説明した第２の実施の形態の情報処理システムと同様である。また、第３の実施の形態のサーバのハードウェア例およびソフトウェア例は、図３，４，７で説明した第２の実施の形態のサーバ１００のハードウェア例およびソフトウェア例と同様である。このため、第３の実施の形態の各装置を第２の実施の形態と同一の名称・符号を付して示す。

ただし、振分部１２０が制御テーブル１１４ａの内容あるいは外部データを事前にＲＡＭ１０２上の構造体および構造体間のリンクとして展開しておく点が第２の実施の形態と異なる。また、処理部１３０が当該展開された構造体および構造体間のリンクに基づいて、イベント処理を行う点が第２の実施の形態と異なる。

図２４は、第３の実施の形態のルール構造体の例を示す図である。ルール構造体５００は、制御テーブル１１４ａをＲＡＭ１０２上に展開する際に用いる構造体である。以下、ルール構造体５００の各行に便宜的に付した行番号を用いて内容を説明する。

行番号“１”は、構造体“ｒｕｌｅ”の定義であることを示している。行番号“１”から行番号“７”までの間が、構造体“ｒｕｌｅ”の定義内容である。
行番号“２”の“ｃｈａｒ ＊ｒｕｌｅ；”は、ルール番号の定義である。ＲＡＭ１０２上に展開された各ルール構造体が何れのルールに関するものであるかを管理し易いように便宜的に付されるものである。

行番号“３”の“ｃｈａｒ ＊ｔｙｐｅ；”は、ルールのタイプの定義である。タイプは、前段フィルタ、ＪＯＩＮ、後段フィルタおよび主処理などを識別するための情報が登録される。

行番号“４”の“ｃｈａｒ ＊ｉｔｅｍ；”は、ルール本体の定義である。ルール本体として、条件判定の処理を示す情報や、主処理を示す情報などが登録される。
行番号“５”の“ＲＵＬＥ ＊ｔｏ；”は、次に参照すべきルール構造体へのリンクを示すポインタである。

行番号“６”の“ＶＡＬＵＥ ｖａｌｕｅ［］；”は、“ｉｔｅｍ”内の処理に用いる補助情報を格納したバリュー構造体の定義である。
行番号“７”の“ＲＵＬＥ”は、構造体“ｒｕｌｅ”を示す別名定義である。

図２５は、第３の実施の形態のバリュー構造体の例を示す図である。バリュー構造体５０１は、ルール構造体５００の補助情報をＲＡＭ１０２上に展開する際に用いる構造体である。以下、バリュー構造体５０１の各行に便宜的に付した行番番号を用いて内容を説明する。

行番号“１”は、構造体“ｖａｌｕｅ”の定義であることを示している。行番号“１”から行番号“４”までの間が、構造体“ｖａｌｕｅ”の定義内容である。
行番号“２”の“ｃｈａｒ ＊ｖ；”は、補助情報の値である。

行番号“３”の“ｖｏｉｄ ＊ｐ；”は、当該補助情報の値に対応するルール構造体等へのリンクを示すポインタである。
行番号“４”の“ＶＡＬＵＥ”は、構造体“ｖａｌｕｅ”を示す別名定義である。

図２６は、第３の実施の形態の制御テーブルの展開例を示す図である。図２６では、ルール構造体５００およびバリュー構造体５０１を用いて、制御テーブル１１４ａおよび外部データをＲＡＭ１０２上に展開した場合のデータ構造を例示している。

ルール構造体５１１，５１２は、イベント種別の情報を格納した構造体である。ルール構造体５１１は、ルールｒ１に対応するイベント種別“Ｐ”を示している。ルール構造体５１２は、ルールｒ２，ｒ３に対応するイベント種別“Ａ”を示している。

例えば、ルール構造体５１１には、次の各値が格納されている。ｒｕｌｅ値は“０”である。複数の処理ルールで使用される可能性があるからである。ｔｙｐｅ値は“Ｅｖｅｎｔ”である。当該ｔｙｐｅ値はイベント種別の構造体であることを示す。ｉｔｅｍ値は“Ｐ”である。イベント種別“Ｐ”の構造体だからである。ｔｏ値は、“１００４：００００”である。これは、次に参照するルール構造体５２１の先頭アドレスを示すものであり、ルール構造体５２１へのリンクＬ１である。

ルール構造体５１２についても同様に、ｒｕｌｅ値は“０”である。ｔｙｐｅ値は“Ｅｖｅｎｔ”である。ｉｔｅｍ値は“Ａ”である。イベント種別“Ａ”の構造体だからである。ｔｏ値は“１００５：００００”である。これは、次のルール構造体５２２へのリンクＬ１０である。

ルール構造体５２１，５２２は、前段フィルタの情報を格納した構造体である。ルール構造体５２１は、制御テーブル１１４ａにおけるルールｒ１（Ｎｏ．“ｒ１”）の前段フィルタの情報を格納した構造体である。ルール構造体５２２は、制御テーブル１１４ａにおけるルールｒ２，ｒ３（Ｎｏ．“ｒ２”，“ｒ３”）の前段フィルタの情報を格納した構造体である。

例えば、ルール構造体５２１には、次の各値が格納されている。ｒｕｌｅ値は“ｒ１”である。ルールｒ１のみに対応する前段フィルタだからである。ｔｙｐｅ値は“ＰｒｅＦｉｌｔｅｒ”である。当該ｔｙｐｅ値は前段フィルタの構造体であることを示す。ｉｔｅｍ値は“．ｐｏｗ［１］”である。イベント種別“Ｐ”のイベントデータに含まれる“ｐｏｗ”値に対する１種類の条件判定を含むからである。ｔｏ値は“ＮＵＬＬ”である。次のルール構造体へのリンクはバリュー構造体に格納されるからである。

ルール構造体５２１に対応するバリュー構造体（ｖａｌｕｅ［０］）のｖ値は“＞５００”である。これは、上記“ｐｏｗ”値に対する具体的な比較値および比較方法を定義したものであり、ルールｒ１の条件判定部分ｒ１１に相当する。ｐ値は“１００６：００００”である。これは、ｖ値による条件判定の結果が真の場合に参照する、次のルール構造体５３１へのリンクＬ２である。

また、ルール構造体５２２には、次の各値が格納されている。ｒｕｌｅ値は“０”である。ルールｒ２，ｒ３の何れかで使用される可能性があるからである。ｔｙｐｅ値は“ＰｒｅＦｉｌｔｅｒ”である。ｉｔｅｍ値は“．ｔｅｍｐ［２］”である。イベント種別“Ａ”のイベントデータに含まれる“ｔｅｍｐ”値に対する２種類の条件判定を含むからである。ｔｏ値は“ＮＵＬＬ”である。次のルール構造体へのリンクはバリュー構造体に格納されるからである。

ルール構造体５２２に対応するバリュー構造体（ｖａｌｕｅ［０］）の第１のｖ値は“＞２０＆＜＝２５”である。これは、ルールｒ３の条件判定部分ｒ３１ａに相当する。第１のｖ値に対応する第１のｐ値は“１００７：００００”である。これは、第１のｖ値による条件判定の結果が真の場合に参照する、次のルール構造体５３２へのリンクＬ３０である。また、ルール構造体５２２に対応するバリュー構造体（ｖａｌｕｅ［１］）の第２のｖ値は“＞２５”である。これは、ルールｒ２の条件判定部分ｒ２１に相当する。第２のｖ値に対応する第２のｐ値は“１０１１：００００”である。これは、第２のｖ値による条件判定の結果が真の場合に参照する、次のルール構造体５５３へのリンクＬ２０である。

ルール構造体５３１，５３２は、ＪＯＩＮの情報（ＪＯＩＮキーと呼ぶ）を格納した構造体である。ルール構造体５３１は、制御テーブル１１４ａにおけるルールｒ１のＪＯＩＮキーを格納した構造体である。ルール構造体５３２は、制御テーブル１１４ａにおけるルールｒ３のＪＯＩＮキーを格納した構造体である。

例えば、ルール構造体５３１には、次の各値が格納されている。ｒｕｌｅ値は、“ｒ１”である。ｔｙｐｅ値は“ＪｏｉｎＫｅｙ”である。当該ｔｙｐｅ値はＪＯＩＮキーの構造体であることを示す。ｉｔｅｍ値は“．ｉｄ［２］”である。ホームテーブル１１１上には消費電力計測器のｉｄ（ｐｏｗｅｒの項目に相当）として２種類のｉｄが登録されており、消費電力計測器からのイベントデータに当該２種類のｉｄが含まれ得るからである。ｔｏ値は“１００８：００００”である。これは、次のルール構造体５５１へのリンクＬ５である。

ルール構造体５３１に対応するバリュー構造体の第１のｖ値は“００１１”である。これは、消費電力計測器５０のｉｄである。第１のｖ値に対応する第１のｐ値は“１００１：００００”である。これは、当該第１のｖ値を含むイベントデータを受信した場合に参照する、外部データオブジェクト６０１へのリンクＬ３である。また、ルール構造体５３１に対応するバリュー構造体の第２のｖ値は“００１２”である。第２のｖ値に対応する第２のｐ値は“１００２：００００”である。これは、当該第２のｖ値を含むイベントデータを受信した場合に参照する、外部データオブジェクト６０２へのリンクＬ４である。

また、ルール構造体５３２には、次の各値が格納されている。ｒｕｌｅ値は“ｒ３”である。ルールｒ３のみに対応するＪＯＩＮキーだからである。ｔｙｐｅ値は“ＪｏｉｎＫｅｙ”である。ｉｔｅｍ値は“．ｉｄ［２］”である。ホームテーブル１１１上には空調機のｉｄ（ａｉｒｃｏｎの項目に相当）として２種類のｉｄが登録されており、空調機からのイベントデータに当該２種類のｉｄが含まれ得るからである。ｔｏ値は“１００９：００００”である。これは、次のルール構造体５４１へのリンクＬ３１である。

ルール構造体５３２に対応するバリュー構造体の第１のｖ値は“００２１”である。これは、空調機６０のｉｄである。第１のｖ値に対応する第１のｐ値は“１００１：００００”である。これは、当該第１のｖ値を含むイベントデータを受信した場合に参照する、外部データオブジェクト６０１へのリンクＬ３２である。また、ルール構造体５３２に対応する第２のｖ値は“００２２”である。第２のｖ値に対応する第２のｐ値は“１００２：００００”である。これは、当該第２のｖ値を含むイベントデータを受信した場合に参照する、外部データオブジェクト６０２へのリンクＬ３３である。

外部データオブジェクト６０１，６０２は、ホームテーブル１１１の各レコードをＲＡＭ１０２上に展開したオブジェクトである。外部データオブジェクト６０１，６０２のそれぞれがホームテーブル１１１の各項目に対応する変数Ｈｏｍｅ．ｉｄ、Ｈｏｍｅ．ｐｏｗｅｒ、Ｈｏｍｅ．ａｉｒｃｏｎ、Ｈｏｍｅ．ｍａｘｐｏｗを含み、各レコードの登録値を保持する。更に、外部データオブジェクト６０１，６０２は、ウィンドウに対応する項目（Ｈｏｍｅ．ｐｏｗ）を含み、ウィンドウの登録値を保持する。外部データオブジェクト６０１は、ホームテーブル１１１のｉｄ“０００１”のレコードに対応する。外部データオブジェクト６０２は、ホームテーブル１１１のｉｄ“０００２”のレコードに対応する。

ルール構造体５４１は、ルールｒ３の後段フィルタの情報を格納した構造体である。例えば、ルール構造体５４１について、次の各値が格納されている。ｒｕｌｅ値は“ｒ３”である。ｔｙｐｅ値は“ＡｆｔＦｉｌｔｅｒ”である。当該ｔｙｐｅ値は後段フィルタの構造体であることを示す。ｉｔｅｍ値は“Ｈｏｍｅ．ｐｏｗ＞Ｈｏｍｅ．ｍａｘｐｏｗ”である。これは、ルールｒ３の条件判定部分ｒ３３に相当する。ｔｏ値は“１０１０：００００”である。これは、ｉｔｅｍ値の条件判定の結果が真の場合に参照する、次のルール構造体５５２へのリンクＬ３４である。

ルール構造体５５１，５５２，５５３は、主処理の情報を格納した構造体である。ルール構造体５５１は、制御テーブル１１４ａにおけるルールｒ１の主処理の情報を格納した構造体である。ルール構造体５５２は、制御テーブル１１４ａにおけるルールｒ３の主処理の情報を格納した構造体である。ルール構造体５５３は、制御テーブル１１４ａにおけるルールｒ２の主処理の情報を格納した構造体である。

例えば、ルール構造体５５１には、次の各値が格納されている。ｒｕｌｅ値は“ｒ１”である。ｔｙｐｅ値は“Ｍａｉｎ”である。当該ｔｙｐｅ値は主処理の構造体であることを示す。ｉｔｅｍ値は“Ｓｅｔ Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”である。これは、ルールｒ１の主処理部分ｒ１ａに相当する。ｔｏ値は“ＮＵＬＬ”である。次の参照先はないからである。

また、ルール構造体５５２には、次の各値が格納されている。ｒｕｌｅ値は“ｒ３”である。ｔｙｐｅ値は“Ｍａｉｎ”である。ｉｔｅｍ値は“Ｃｏｎｔ Ａ．ｔｅｍｐ−＝２”である。これは、ルールｒ３の主処理部分ｒ３ａに相当する。ｔｏ値は“ＮＵＬＬ”である。

また、ルール構造体５５３には、次の各値が格納されている。ｒｕｌｅ値は“ｒ２”である。ルールｒ２のみに対応する主処理だからである。ｔｙｐｅ値は“Ｍａｉｎ”である。ｉｔｅｍ値は“Ｓｅｎｄ Ａ．ｍｓｇ＝“・・・””である。これは、ルールｒ２の主処理部分ｒ２ａに相当する。ｔｏ値は“ＮＵＬＬ”である。

このように、振分部１２０は、前段フィルタ、ＪＯＩＮ処理、後段フィルタおよび主処理を、各処理の内容と当該処理の結果に応じた次の処理を示す情報を示すポインタとを含む上記のデータ構造を用いて、ＲＡＭ１０２上に展開する。

次に、第３の実施の形態の処理手順を説明する。ここで、第３の実施の形態の全体の処理の手順は、図１５で説明した第２の実施の形態の処理の手順と同様である。ただし、ステップＳ１２におけるルールおよび外部データのＲＡＭ１０２への展開の手順が第２の実施の形態と異なる。また、ステップＳ１５におけるイベント処理の手順が第２の実施の形態と異なる。そこで、以下では、これらの各処理について詳細に説明する。

図２７は、第３の実施の形態のルール展開の例を示すフローチャートである。以下、図２７に示す処理をステップ番号に沿って説明する。
（ステップＳ１０１）振分部１２０は、記憶部１１０を参照してＲＡＭ１０２上に未展開の外部データがあるか否かを判定する。例えば、振分部１２０は、テーブル単位に未展開であるか否かを判定する。未展開の外部データがある場合、処理をステップＳ１０２に進める。未展開の外部データがない、すなわち、全ての外部データを展開済の場合、処理をステップＳ１０７に進める。

（ステップＳ１０２）振分部１２０は、記憶部１１０に記憶された制御テーブル１１４ａに基づいて展開する項目を決定する。例えば、未展開の外部データとしてホームテーブル１１１が選択されているとする。この場合、制御テーブル１１４ａのＪＯＩＮの項目を参照すると、ホームテーブル１１１で用いられる項目は“Ｈｏｍｅ．ｉｄ”、“Ｈｏｍｅ．ｍａｘｐｏｗ”、“Ｈｏｍｅ．ａｉｒｃｏｎ”、“Ｈｏｍｅ．ｐｏｗｅｒ”である。したがって、振分部１２０は、これらの項目を外部データオブジェクトに追加する。

（ステップＳ１０３）振分部１２０は、制御テーブル１１４ａを参照して、外部データに対応するウィンドウの登録がある否かを判定する。ウィンドウがある場合、処理をステップＳ１０４に進める。ウィンドウがない場合、処理をステップＳ１０５に進める。具体的には、制御テーブル１１４ａの状況（ウィンドウ）の項目を参照すると、ウィンドウ“Ｈｏｍｅ．ｐｏｗ”が登録されている。この場合、振分部１２０は、ホームテーブル１１１に対応するウィンドウ“Ｈｏｍｅ．ｐｏｗ”があると判定する。

（ステップＳ１０４）振分部１２０は、外部データオブジェクトの項目に関連するウィンドウの項目を追加する。例えば、ホームテーブル１１１の外部データオブジェクトに対して、ウィンドウ“Ｈｏｍｅ．ｐｏｗ”に関する項目を追加する。

（ステップＳ１０５）振分部１２０は、外部データを参照して、未展開のレコードがあるか否かを判定する。未展開のレコードがある場合、処理をステップＳ１０６に進める。未展開のレコードがない場合、処理をステップＳ１０１に進める。

（ステップＳ１０６）振分部１２０は、外部データ内の未展開の１レコードを、ステップＳ１０２で決定した項目と、ステップＳ１０４で決定したウィンドウを有する１つの外部データオブジェクトとしてＲＡＭ１０２上に展開する。そして、処理をステップＳ１０５に進める。

（ステップＳ１０７）振分部１２０は、制御テーブル１１４ａを参照して、未展開のルールがあるか否かを判定する。未展開のルールがある場合、処理をステップＳ１０８に進める。未展開のルールがない場合、すなわち、制御テーブル１１４ａに含まれる全てのルールを展開済の場合、処理を終了する。

（ステップＳ１０８）振分部１２０は、未展開のルールを１つ抽出する。以降の説明において、本ステップＳ１０８で抽出された未展開のルールを単に“抽出されたルール”と称する。

（ステップＳ１０９）振分部１２０は、抽出されたルールに対応するイベント種別をルール構造体へ展開する。
（ステップＳ１１０）振分部１２０は、抽出されたルールに含まれる前段フィルタをルール構造体へ展開する。

（ステップＳ１１１）振分部１２０は、抽出されたルールに含まれるＪＯＩＮをルール構造体へ展開する。
（ステップＳ１１２）振分部１２０は、抽出されたルールに含まれる後段フィルタをルール構造体へ展開する。

（ステップＳ１１３）振分部１２０は、抽出されたルールに含まれる主処理をルール構造体へ展開する。
このようにして、振分部１２０は、外部データの外部データオブジェクトへの展開を行う。また、振分部１２０は、制御テーブル１１４ａの各ルールのルール構造体への展開を行う。次に、ステップＳ１０９〜Ｓ１１３におけるルール構造体への展開方法を詳細に説明する。まず、ステップＳ１０９におけるイベント種別のルール構造体への展開方法を説明する。

図２８は、第３の実施の形態のイベント種別の展開例を示すフローチャートである。以下、図２８に示す処理をステップ番号に沿って説明する。
（ステップＳ１２１）振分部１２０は、抽出されたルールに対応するイベント種別がルール構造体へ未展開のイベント種別であるか否かを判定する。未展開のイベント種別である場合、処理をステップＳ１２２に進める。展開済のイベント種別である場合、処理を終了する。

（ステップＳ１２２）振分部１２０は、ルール構造体の領域をＲＡＭ１０２上から獲得して当該領域の設定を初期化（例えば、ｒｕｌｅを“０”に設定）する。
（ステップＳ１２３）振分部１２０は、ルール構造体のｔｙｐｅに“Ｅｖｅｎｔ”を、ｉｔｅｍにイベント名（イベント種別）を設定する。

このようにして、振分部１２０は、イベント種別のルール構造体５１１，５１２を作成する。なお、ステップＳ１２１の判定を行う理由は次の通りである。
例えば、ルールｒ２をルール構造体に展開した後に、ルールｒ３をルール構造体に展開しようとする場合、ルールｒ３の展開時にはイベント種別“Ａ”についてのルール構造体５１２は作成済である。この場合に、振分部１２０は、ルール構造体５１２を２重に作成しないようにしている。

次に、図２７のステップＳ１１０における前段フィルタのルール構造体への展開方法を説明する。
図２９は、第３の実施の形態の前段フィルタの展開例を示すフローチャートである。以下、図２９に示す処理をステップ番号に沿って説明する。

（ステップＳ１３１）振分部１２０は、記憶部１１０に記憶された制御テーブル１１４ａを参照して、抽出されたルールに前段フィルタを示す情報の設定があるか否かを判定する。前段フィルタを示す情報の設定がある場合、処理をステップＳ１３２に進める。前段フィルタを示す情報がない場合、処理を終了する。

（ステップＳ１３２）振分部１２０は、当該前段フィルタが既存の前段フィルタであるか否かを判定する。既存の前段フィルタであるとは、当該前段フィルタをルール構造体に展開済であることを意味する。既存の前段フィルタでない場合、処理をステップＳ１３３に進める。既存の前段フィルタである場合、処理をステップＳ１３６に進める。振分部１２０は、既存の前段フィルタであるか否かを、展開済のイベント種別のルール構造体に設定されたｉｔｅｍと、当該イベント種別のルール構造体がリンクする展開済の前段フィルタのルール構造体に設定されたｉｔｅｍの値と、から判定する。例えば、ルールｒ２について展開済である場合、ルール構造体５２２を作成済である。この場合、ルール構造体５１２とルール構造体５２２とのリンクも形成済である。この状態で、ルールｒ３を展開しようとするとき、ルールｒ３と同一のイベント種別“Ａ”のルール構造体５１２に対し、ルールｒ３の前段フィルタと同一のチェック項目“．ｔｅｍｐ”につきルール構造体５２２が作成済の状態である。したがって、この場合、振分部１２０は、ルールｒ３に含まれる前段フィルタが既存の前段フィルタであると判定する。

（ステップＳ１３３）振分部１２０は、ルール構造体の領域をＲＡＭ１０２上から獲得して当該領域の設定を初期化する。例えば、抽出されたルールの番号をｒｕｌｅに設定する。また、ｔｏを“ＮＵＬＬ”に設定する。前段フィルタのルール構造体では、バリュー構造体でリンクを定義するからである。

（ステップＳ１３４）振分部１２０は、関連するイベント種別のｔｏに当該前段フィルタのルール構造体へのリンクを設定する。例えば、ルールｒ１であれば関連するイベント種別は“Ｐ”であるので、ルール構造体５１１のｔｏにルール構造体５２１へのリンクを設定する。また、例えば、ルールｒ２（または、ルールｒ３）であれば、関連するイベント種別は“Ａ”であるので、ルール構造体５１２のｔｏにルール構造体５２２へのリンクを設定する。

（ステップＳ１３５）振分部１２０は、当該前段フィルタのルール構造体のｔｙｐｅに“ＰｒｅＦｉｌｔｅｒ”を設定する。また、ｉｔｅｍにチェック項目を設定する。
（ステップＳ１３６）振分部１２０は、バリュー構造体に前段フィルタの条件判定の内容を設定する。ここで、ステップＳ１３２で既存の前段フィルタであると判定されてステップＳ１３６を実行する場合、振分部１２０は該当するルール構造体のｒｕｌｅを“０”に設定する。当該ルール構造体は、複数のルールで使用され得るからである。なお、バリュー構造体に新たな条件判定の内容を設定する場合には、ＲＡＭ１０２から当該バリュー構造体用の領域を獲得して初期化した上で、条件判定の内容を設定する。

このようにして、振分部１２０は、前段フィルタのルール構造体５２１，５２２を作成する。なお、ステップＳ１３２の判定を行うことで、同じイベント種別の同じチェック項目について２つのルール構造体を作成することがなくなる。したがって、ＲＡＭ１０２の領域を節約することができる。

また、ステップＳ１３６では、新たに条件判定の内容を設定する場合、既にバリュー構造体に設定されている他の条件判定の内容を考慮する。例えば、ルールｒ２について、先にルール構造体５２２が作成されている場合、既に前段フィルタの条件判定“．ｔｅｍｐ＞２５”が設定済である。この状態でルールｒ３について、前段フィルタの条件判定“．ｔｅｍｐ＞２０＆ｔｅｍｐ＜＝２５”を設定するとき、当該前段フィルタはルールｒ２の条件判定と重複しない。したがって、振分部１２０は、ルールｒ３の前段フィルタ用に新たにバリュー構造体の領域をＲＡＭ１０２から獲得して初期化を行い、条件“．ｔｅｍｐ＞２０＆ｔｅｍｐ＜＝２５”を設定する。

次に、図２７のステップＳ１１１におけるＪＯＩＮキーのルール構造体への展開方法を説明する。
図３０は、第３の実施の形態のＪＯＩＮキーの展開例を示すフローチャートである。以下、図３０に示す処理をステップ番号に沿って説明する。

（ステップＳ１４１）振分部１２０は、記憶部１１０に記憶された制御テーブル１１４ａを参照して、抽出されたルールにＪＯＩＮ処理を示す情報の設定があるか否かを判定する。ＪＯＩＮ処理を示す情報の設定がある場合、処理をステップＳ１４２に進める。ＪＯＩＮ処理を示す情報の設定がない場合、処理を終了する。

（ステップＳ１４２）振分部１２０は、ルール構造体の領域をＲＡＭ１０２上から獲得して当該領域の設定を初期化する。例えば、抽出されたルールの番号をｒｕｌｅに設定する。

（ステップＳ１４３）振分部１２０は、抽出されたルールに前段フィルタがあるか否かを判定する。前段フィルタがある場合、処理をステップＳ１４４に進める。前段フィルタがない場合、処理をステップＳ１４５に進める。

（ステップＳ１４４）振分部１２０は、該当する前段フィルタのバリュー構造体のｐ値にステップＳ１４２で作成したルール構造体（ＪＯＩＮキー）へのリンクを設定する。例えば、ＪＯＩＮキーのルール構造体５３１でいえば、前段フィルタのルール構造体５２１に対応するバリュー構造体のｐ値に“１００６：００００”を設定する。当該ｐ値は、ルール構造体５３１へのリンクＬ２である。

（ステップＳ１４５）振分部１２０は、抽出されたルールに対応するイベント種別のルール構造体のｔｏにステップＳ１４２で作成したルール構造体（ＪＯＩＮキー）へのリンクを設定する。

（ステップＳ１４６）振分部１２０は、ステップＳ１４２で作成したルール構造体のｔｙｐｅに“ＪｏｉｎＫｅｙ”を、ｉｔｅｍにＪＯＩＮ対象の項目を設定する。例えば、ルールｒ１では、イベントデータに含まれるＪＯＩＮ対象の項目は“Ｐ．ｉｄ”である。したがって、ｉｔｅｍに“．ｉｄ”を登録する。

（ステップＳ１４７）振分部１２０は、以下に示すステップＳ１４８の処理を行っていない、未処理の外部データオブジェクトがあるか否かを判定する。未処理の外部データオブジェクトがある場合、処理をステップＳ１４８に進める。未処理の外部データオブジェクトがない場合、処理を終了する。

（ステップＳ１４８）振分部１２０は、新たに作成したルール構造体に対応するバリュー構造体の領域をＲＡＭ１０２上から獲得して初期化し、ｖ値にＪＯＩＮ対象の項目の取り得る値を設定する。また、ｐ値に対応する外部データオブジェクトへのリンクを設定する。例えば、ルールｒ１でいえば、ＪＯＩＮ対象の項目である“Ｐ．ｉｄ”の取り得る値は、“００１１”および“００１２”である。よって、振分部１２０は、ルール構造体５３１に対応するバリュー構造体のｖ値にこの２種類の値を設定する。そして、“Ｐ．ｉｄ”に対応する“Ｈｏｍｅ．ｐｏｗｅｒ”に“００１１”を含む外部データオブジェクトは外部データオブジェクト６０１である。よって、振分部１２０は、ｖ値“００１１”に対応するｐ値に“１００１：００００”を設定する。これは、外部データオブジェクト６０１へのリンクＬ３である。同様に、ｖ値“００１２”に対応するｐ値に“１００２：００００”を設定する。これは、外部データオブジェクト６０２へのリンクＬ４である。そして、処理をステップＳ１４７に進める。

このようにして、振分部１２０は、ＪＯＩＮキーのルール構造体５３１，５３２を作成する。
次に、図２７のステップＳ１１２における後段フィルタのルール構造体への展開方法を説明する。

図３１は、第３の実施の形態の後段フィルタの展開例を示すフローチャートである。以下、図３１に示す処理をステップ番号に沿って説明する。
（ステップＳ１５１）振分部１２０は、記憶部１１０に記憶された制御テーブル１１４ａを参照して、抽出されたルールに後段フィルタを示す情報の設定があるか否かを判定する。後段フィルタを示す情報の設定がある場合、処理をステップＳ１５２に進める。後段フィルタを示す情報の設定がない場合、処理を終了する。

（ステップＳ１５２）振分部１２０は、ルール構造体の領域をＲＡＭ１０２上から獲得して当該領域の設定を初期化する。例えば、抽出されたルールの番号をｒｕｌｅに設定する。

（ステップＳ１５３）振分部１２０は、関連するＪＯＩＮキーのルール構造体のｔｏにステップＳ１５２で作成した後段フィルタのルール構造体へのリンクを設定する。例えば、後段フィルタのルール構造体５４１でいえば、ＪＯＩＮキーのルール構造体５３２のｔｏに“１００９：００００”を設定する。当該ｔｏの値は、ルール構造体５４１へのリンクＬ３１である。

（ステップＳ１５４）振分部１２０は、ステップＳ１５２で作成したルール構造体のｔｙｐｅに“ＡｆｔＦｉｌｔｅｒ”を、ｉｔｅｍに後段フィルタの条件判定の内容を設定する。

このようにして、振分部１２０は、後段フィルタのルール構造体５４１を作成する。
次に、図２７のステップＳ１１３における主処理のルール構造体への展開方法を説明する。

図３２は、第３の実施の形態の主処理の展開例を示すフローチャートである。以下、図３２に示す処理をステップ番号に沿って説明する。
（ステップＳ１６１）振分部１２０は、記憶部１１０に記憶された制御テーブル１１４ａを参照して、抽出されたルールに主処理を示す情報の設定があるか否かを判定する。主処理を示す情報の設定がある場合、処理をステップＳ１６２に進める。主処理を示す情報の設定がない場合、処理を終了する。

（ステップＳ１６２）振分部１２０は、ルール構造体の領域をＲＡＭ１０２上から獲得して当該領域の設定を初期化する。例えば、抽出されたルールの番号をｒｕｌｅに設定する。また、例えば、ｔｏに“ＮＵＬＬ”を設定する。

（ステップＳ１６３）振分部１２０は、抽出されたルールに後段フィルタがあるか否かを判定する。後段フィルタがある場合、処理をステップＳ１６４に進める。後段フィルタがない場合、処理をステップＳ１６５に進める。

（ステップＳ１６４）振分部１２０は、該当する後段フィルタのｔｏにステップＳ１６２で作成したルール構造体（主処理）へのリンクを設定する。例えば、主処理のルール構造体５５２であれば、後段フィルタのルール構造体５４１のｔｏに“１０１０：００００”を設定する。これは、ルール構造体５５２へのリンクＬ３４である。そして、処理をステップＳ１７１に進める。

（ステップＳ１６５）振分部１２０は、抽出されたルールにＪＯＩＮキーがあるか否かを判定する。ＪＯＩＮキーがある場合、処理をステップＳ１６６に進める。ＪＯＩＮキーがない場合、処理をステップＳ１６７に進める。

（ステップＳ１６６）振分部１２０は、該当するＪＯＩＮキーのｔｏにステップＳ１６２で作成したルール構造体（主処理）へのリンクを設定する。例えば、主処理のルール構造体５５１であれば、ＪＯＩＮキーのルール構造体５３１のｔｏに“１００８：００００”を設定する。これは、ルール構造体５５１へのリンクＬ５である。そして、処理をステップＳ１７１に進める。

（ステップＳ１６７）振分部１２０は、抽出されたルールに前段フィルタがあるか否かを判定する。前段フィルタがある場合、処理をステップＳ１６８に進める。前段フィルタがない場合、処理をステップＳ１６９に進める。

（ステップＳ１６８）振分部１２０は、該当する前段フィルタのバリュー構造体のｐ値にステップＳ１６２で作成したルール構造体（主処理）へのリンクを設定する。例えば、主処理のルール構造体５５３であれば、前段フィルタのルール構造体５２２に対応するバリュー構造体の第２のｐ値に“１０１１：００００”を設定する。これは、ルール構造体５５３へのリンクＬ２０である。そして、処理をステップＳ１７１に進める。

（ステップＳ１６９）振分部１２０は、抽出されたルールに関連するイベント種別があるか否かを判定する。関連するイベント種別がある場合、処理をステップＳ１７０に進める。関連するイベント種別がない場合、処理をステップＳ１７１に進める。

（ステップＳ１７０）振分部１２０は、関連するイベント種別のルール構造体のｔｏにステップＳ１６２で作成したルール構造体（主処理）へのリンクを設定する。
（ステップＳ１７１）振分部１２０は、ステップＳ１６２で作成したルール構造体のｔｙｐｅに“ｍａｉｎ”を、ｉｔｅｍに主処理の内容を設定する。

このようにして、振分部１２０は、主処理のルール構造体５５１，５５２，５５３を作成する。
次に、第３の実施の形態のイベント処理の手順を説明する。第３の実施の形態のイベント処理では、リンクを辿りながら各ルール構造体を参照してイベント処理を実行する点が、第２の実施の形態のイベント処理と異なる。サーバ１００は、図１５のステップＳ１５に代えて以下の処理を行う。

図３３は、第３の実施の形態のイベント処理の例を示すフローチャートである。以下、図３３に示す処理をステップ番号に沿って説明する。
（ステップＳ１８１）処理部１３０は、受信したイベントデータのイベント種別を取得する。処理部１３０は、当該イベント種別のルール構造体におけるｔｏからポインタを取得する。処理部１３０は、当該ポインタで示される次のルール構造体を参照する。

（ステップＳ１８２）処理部１３０は、参照先のルール構造体のｔｙｐｅを判定する。ｔｙｐｅが“ＰｒｅＦｉｌｔｅｒ”の場合、処理をステップＳ１８３に進める。ｔｙｐｅが“ＪｏｉｎＫｅｙ”の場合、処理をステップＳ１８５に進める。ｔｙｐｅが“ＡｆｔＦｉｌｔｅｒ”の場合、処理をステップＳ１８７に進める。ｔｙｐｅが“Ｍａｉｎ”の場合、処理をステップＳ１８９に進める。

（ステップＳ１８３）処理部１３０は、ルール構造体（前段フィルタ）のｉｔｅｍで指定されている項目についてイベントデータの値（イベント値）を取得し、イベント値に対応するバリュー構造体（ｖａｌｕｅ）があるか否かを判定する。ｉｔｅｍで指定されたイベント値に対応するバリュー構造体がある場合、処理をステップＳ１８４に進める（前段フィルタを通過したイベント）。ｉｔｅｍで指定されたイベント値に対応するバリュー構造体がない場合、当該イベントデータに対する処理を終了する（前段フィルタで除外されたイベント）。処理部１３０は、イベント値と当該ルール構造体に対応するバリュー構造体のｖ値とを対比することで、イベント値に対応するバリュー構造体があるか否かを判定できる。例えば、イベントデータ２１０を受信した場合を考える。ルール構造体５２１のｉｔｅｍで指定されている項目は“．ｐｏｗ”である。ルール構造体５２１に対応するバリュー構造体のｖ値は“＞５００”である。イベントデータ２１０の“ｐｏｗ”値は“１５１０”であり、“１５１０＞５００”を満たす。この場合、処理部１３０は、ｉｔｅｍで指定されたイベント値に対応するバリュー構造体があると判定する。一方、イベント値がｖ値で示される条件判定の内容を満たさない場合は、ｉｔｅｍで指定されたイベント値に対応するバリュー構造体がないと判定する。

（ステップＳ１８４）処理部１３０は、当該ルール構造体（前段フィルタ）のｉｔｅｍの値に対応するバリュー構造体のｐ値からポインタを取得する。処理部１３０は、当該ポインタで示される次のルール構造体を参照する。例えば、ルール構造体５２１であれば、イベント値がｖ値“＞５００”を満たすならば、当該ｖ値に対応するｐ値（ポインタ）“１００６：００００”を取得する。これは、ルール構造体５３１へのリンクＬ２である。処理部１３０は、リンクＬ２を辿ってルール構造体５３１を参照する。そして、処理をステップＳ１８２に進める。

（ステップＳ１８５）処理部１３０は、ルール構造体（ＪＯＩＮキー）のｉｔｅｍで指定されている項目について、イベント値を取得し、イベント値に対応するバリュー構造体があるか否かを判定する。ｉｔｅｍで指定されたイベント値に対応するバリュー構造体がある場合、処理をステップＳ１８６に進める（ＪＯＩＮ対象が存在する有効なイベント）。ｉｔｅｍで指定されたイベント値に対応するバリュー構造体がない場合、当該イベントデータに対する処理を終了する（ＪＯＩＮ対象が存在しない無効なイベント）。例えば、イベントデータ２１０を受信した場合を考える。ルール構造体５３１のｉｔｅｍで指定されている項目は“．ｉｄ［２］”である。ルール構造体５３１に対応するバリュー構造体のｖ値は“００１１”および“００１２”である。イベントデータ２１０の“ｉｄ”値は“００１１”であり、ｖ値の“００１１”と一致する。この場合、処理部１３０は、ｉｔｅｍで指定されたイベント値に対応するバリュー構造体があると判定する。一方、イベント値が何れのｖ値にも一致しない場合は、ｉｔｅｍで指定されたイベント値に対応するバリュー構造体がないと判定する（ＪＯＩＮ対象が存在しない無効なイベントである）。

（ステップＳ１８６）処理部１３０は、当該ルール構造体（ＪＯＩＮキー）のｉｔｅｍの値に対応するバリュー構造体のｐ値から外部データオブジェクトへのポインタを取得する。処理部１３０は、当該ルール構造体のｔｏからポインタを取得する。処理部１３０は、外部データオブジェクトへのポインタを保持しながら、ｔｏから取得したポインタで示される次のルール構造体を参照する。例えば、ルール構造体５３１でイベント値（Ｐ．ｉｄ）＝ｖ値＝“００１１”であれば、当該ｖ値に対応するｐ値（ポインタ）“１００１：００００”を取得する。これは、外部データオブジェクト６０１へのリンクＬ３である。また、処理部１３０は、ルール構造体５３１のｔｏ（ポインタ）“１００８：００００”を取得する。これは、ルール構造体５５１へのリンクＬ５である。処理部１３０は、外部データオブジェクト６０１へのポインタを保持しながら、リンクＬ５を辿って、ルール構造体５５１を参照する。そして、処理をステップＳ１８２に進める。

（ステップＳ１８７）処理部１３０は、ルール構造体（後段フィルタ）のｉｔｅｍで指定されている条件判定の評価結果が真であるか否かを判定する。真である場合、処理をステップＳ１８８に進める（後段フィルタを通過したイベント）。偽である場合、処理を終了する（後段フィルタで除外されたイベント）。例えば、ルール構造体５４１であれば、ｉｔｅｍに設定されている条件判定は“Ｈｏｍｅ．ｐｏｗ＞Ｈｏｍｅ．ｍａｘｐｏｗ”である。この場合、ルール構造体５４１はルール構造体５３１（ＪＯＩＮキー）から参照されるものであり、外部データオブジェクトへのリンクが保持されている。例えば、イベントデータ３１０を受信した場合には、外部データオブジェクト６０１へのリンクが保持されている。そして、外部データオブジェクト６０１には、“Ｈｏｍｅ．ｐｏｗ”および“Ｈｏｍｅ．ｍａｘｐｏｗ”の各値が設定されている。よって、処理部１３０は、外部データオブジェクト６０１から各値を読み出して、当該条件判定を行うことができる。外部データオブジェクト６０１の例でいえば、“Ｈｏｍｅ．ｐｏｗ＝１５１０”＞“Ｈｏｍｅ．ｍａｘｐｏｗ＝１５００”であり、当該条件判定の評価結果は真である。

（ステップＳ１８８）処理部１３０は、当該ルール構造体（後段フィルタ）のｔｏからポインタを取得する。処理部１３０は、当該ポインタで示される次のルール構造体を参照する。そして、処理をステップＳ１８２に進める。

（ステップＳ１８９）処理部１３０は、ルール構造体（主処理）のｉｔｅｍに設定されている処理を実行する。例えば、ルール構造体５５１であれば、ｉｔｅｍに設定されている処理の内容は“Ｓｅｔ Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”である。この場合、ルール構造体５５１はルール構造体５３１（ＪＯＩＮキー）から参照されるものであり、外部データオブジェクトへのリンクが保持されている。例えば、イベントデータ２１０を受信した場合には、外部データオブジェクト６０１へのリンクが保持されている。そして、外部データオブジェクト６０１には、“Ｈｏｍｅ．ｐｏｗ”の項目が設けられている。よって、処理部１３０は、外部データオブジェクトの“Ｈｏｍｅ．ｐｏｗ”にイベントデータ２１０に格納された“ｐｏｗ＝１５１０”を設定することができる。処理部１３０は、ルール構造体５５２，５５３の場合も同様にｉｔｅｍに設定された処理の内容を実行する。ただし、ルール構造体５５２，５５３は、外部データオブジェクトを参照せずに実行可能である。

このようにして、処理部１３０は、ＲＡＭ１０２上に展開されたルール構造体を順番に辿ることで、イベント処理を行う。
図３４は、第３の実施の形態のイベント処理の例を示す図である。ここで、図３４では、図２６で例示した各ルール構造体についてｉｔｅｍの値を示している。例えば、ｉｔｅｍ５１１ａは、ルール構造体５１１のｉｔｅｍの値“Ｐ”である。ｉｔｅｍ５１２ａは、ルール構造体５１２のｉｔｅｍの値“Ａ”である。ｉｔｅｍ５４１ａは、ルール構造体５４１のｉｔｅｍの値“Ｈｏｍｅ．ｐｏｗ＞Ｈｏｍｅ．ｍａｘｐｏｗ”である。ｉｔｅｍ５５１ａは、ルール構造体５５１のｉｔｅｍの値“Ｓｅｔ Ｈｏｍｅ．ｐｏｗ＝Ｐ．ｐｏｗ”である。ｉｔｅｍ５５２ａは、ルール構造体５５２のｉｔｅｍの値“Ｃｏｎｔ Ａ．ｔｅｍｐ−＝２”である。ｉｔｅｍ５５３ａは、ルール構造体５５３のｉｔｅｍの値“Ｓｅｎｄ Ａ．ｍｓｇ＝“・・・””である。

また、ｉｔｅｍの値に対して、バリュー構造体のｖ値が存在する場合には、ｉｔｅｍの値とｖ値とを組み合わせて（この組み合わせもｉｔｅｍと称している）図示している。例えば、ｉｔｅｍ５２１ａは、ルール構造体５２１のｉｔｅｍの値とｖ値との組み合わせ“．ｐｏｗ＞５００”である。

更に、１つのルール構造体のｉｔｅｍの値に対して、２つのｖ値が存在する場合には、ｉｔｅｍの値とそれぞれのｖ値との組を図示している。
例えば、ｉｔｅｍ５２２ａは、ルール構造体５２２のｉｔｅｍの値と第１のｖ値との組み合わせ“．ｔｅｍｐ＞２０＆．ｔｅｍｐ＜＝２５”である。例えば、ｉｔｅｍ５２２ｂは、ルール構造体５２２のｉｔｅｍの値と第２のｖ値との組み合わせ“．ｔｅｍｐ＞２５”である。

ｉｔｅｍ５３１ａは、ルール構造体５３１のｉｔｅｍの値と第１のｖ値との組み合わせ“．ｉｄ＝００１１”である。ｉｔｅｍ５３１ｂは、ルール構造体５３１のｉｔｅｍの値と第２のｖ値との組み合わせ“．ｉｄ＝００１２”である。

ｉｔｅｍ５３２ａは、ルール構造体５３２のｉｔｅｍの値と第１のｖ値との組み合わせ“．ｉｄ＝００２１”である。ｉｔｅｍ５３２ｂは、ルール構造体５３２のｉｔｅｍの値と第２のｖ値との組み合わせ“．ｉｄ＝００２２”である。

処理部１３０は、ルール構造体間のリンクを辿り、各ｉｔｅｍを処理することでイベント処理を行う。例えば、消費電力計測器５０からイベントデータ２１０を受信したとする。この場合、処理部１３０は、次のようにしてルールｒ１に対応する処理を実行する。

（１）イベントデータ２１０のイベント種別は“Ｐ”であり、ルール構造体５１１のｉｔｅｍ５１１ａに該当する。したがって、処理部１３０は、次のルール構造体５２１を参照する。

（２）イベントデータ２１０では、“Ｐ．ｐｏｗ＝１５１０“＞“５００”であり、ルール構造体５２１において該当するｉｔｅｍ５２１ａが存在する。したがって、処理部１３０は、次のルール構造体５３１を参照する。

（３）イベントデータ２１０では、“Ｐ．ｉｄ＝００１１”であり、ルール構造体５３１において該当するｉｔｅｍ５３１ａが存在する。したがって、処理部１３０は、外部データオブジェクト６０１へのリンクを保持し、次のルール構造体５５１を参照する。

（４）処理部１３０は、ルール構造体５５１のｉｔｅｍ５５１ａの処理を実行する。このとき、外部データオブジェクト６０１へのリンクは保持されている。また、イベントデータ２１０では、“Ｐ．ｐｏｗ＝１５１０”である。したがって、処理部１３０は、外部データオブジェクト６０１のウィンドウに対応する項目“．ｐｏｗ”に“１５１０”を設定する（図３４では設定する操作を点線矢印で示している）。

これによって、イベントデータ２１０に対するルールｒ１の処理が完了する。なお、図３４では、イベント種別“Ｐ”、“Ｐ．ｉｄ＝００１２”、“Ｐ．ｐｏｗ＝１８００”であるイベントデータを受信した場合について、上記と同様の手順によって関連付けられるｉｔｅｍ間の関連線も図示されている。

続いて、空調機６０からイベントデータ３１０を受信したとする。この場合、処理部１３０は、次のようにしてルールｒ２，ｒ３に対応する処理を実行する。
（１）イベントデータ３１０のイベント種別は“Ａ”であり、ルール構造体５１２のｉｔｅｍ５１２ａに該当する。したがって、処理部１３０は、次のルール構造体５２２を参照する。

（２）イベントデータ３１０では、“Ａ．ｔｅｍｐ＝２２”であり、ルール構造体５２２において該当するｉｔｅｍ５２２ａが存在する。したがって、処理部１３０は、次のルール構造体５３２を参照する。なお、ｉｔｅｍ５２２ｂは、“Ａ．ｔｅｍｐ＝２２”には対応しないため、処理部１３０はルール構造体５５３の参照は行わない。すなわち、ルールｒ２に関しては前段フィルタで終了となる。

（３）イベントデータ３１０では、“Ａ．ｉｄ＝００２１”であり、ルール構造体５３２において該当するｉｔｅｍ５３２ａが存在する。したがって、処理部１３０は、外部データオブジェクト６０１へのリンクを保持し、次のルール構造体５４１を参照する。

（４）処理部１３０は、ルール構造体５４１のｉｔｅｍ５４１ａの条件判定を評価する。このとき、外部データオブジェクト６０１へのリンクは保持されている。したがって、処理部１３０は、外部データオブジェクト６０１から“Ｈｏｍｅ．ｐｏｗ＝１５１０”および“Ｈｏｍｅ．ｍａｘｐｏｗ＝１５００”を取得して、ｉｔｅｍ５４１ａを評価する。この場合、ｉｔｅｍ５４１ａの評価結果は真である。したがって、処理部１３０は、次のルール構造体５５２を参照する。

（５）処理部１３０は、ルール構造体５５２のｉｔｅｍ５５２ａの処理を実行する。当該処理の実行により、処理部１３０はイベントデータ３１０を生成し、空調機６０に送信する。空調機６０はイベントデータ３１０を受信すると、当該イベントデータ３１０の指示に基づいて、設定温度を２℃低減する。

これによって、イベントデータ３１０に対するルールｒ３の処理が完了する。なお、図３４では、イベント種別“Ａ”、“Ａ．ｉｄ＝００２２”であるイベントデータを受信した場合について、上記と同様の手順によって関連付けられるｉｔｅｍ間の関連線も図示されている。

このように、第３の実施の形態では、外部データおよび制御テーブル１１４ａをＲＡＭ１０２にルール構造体として展開し、当該ルール構造体に基づいてイベント処理を行う。このようにすれば、イベント処理を行う際に、ＪＯＩＮ処理の結果に相当する情報をルール構造体の参照によって得ることができる。すなわち、イベント処理の際にＪＯＩＮ処理を行わなくてもよくなる。これにより、イベント処理をより高速化することができる。

このとき、制御テーブル１１４を最適化した後の制御テーブル１１４ａをルール構造体として展開することで、余計な情報をＲＡＭ１０２上に保持しなくてよい。したがって、ＲＡＭ１０２上の領域を節約することができるだけでなく、ルール構造体のリンクたどる手間も省けるため、処理部１３０も高速化できる。更に、同一のイベント種別に対する同一のチェック項目を同じルール構造体で管理し、具体的な値などの相違点のみをバリュー構造体で管理する。これにより、ルール構造体の数を抑えることができ、ＲＡＭ１０２上の領域を節約することができるだけでなく、複数のルールを同時にチェック効果もあるため、処理部１３０も高速化できる。

更に、第３の実施の形態では、ＲＡＭ１０２上に展開した外部データと併せて外部データに対応するウィンドウ（変数）を保持して、ルールおよび外部データと同時に（共通のポインタで）ルールから使用できるため、主処理の前段（フィルタ）で複数のイベントの相互作用に基いた判断を効率よく実行できる。これにより、従来は主処理部で実行していた複合イベント処理の一部（外部データと対応するウィンドウ処理）をフィルタ部で高速に実行可能とする効果がある。

なお、上述の機能は、コンピュータに所定のプログラムを実行させることで実現することもできる。当該プログラムは、コンピュータ読み取り可能な可搬型の記録媒体１３に記録しておくことができる。当該プログラムを流通させるには、例えば、そのプログラムが記録された記録媒体１３を配布する。または、そのプログラムをサーバコンピュータに格納しておき、ネットワーク経由でコンピュータに転送してもよい。コンピュータは、例えば、記録媒体１３に記録されたプログラムまたはネットワークから取得したプログラムを、自装置の不揮発性の記憶媒体に格納する。そして、当該不揮発性の記憶媒体からプログラムを読み取り実行する。ただし、コンピュータは、取得したプログラムを、不揮発性の記憶媒体に格納せずに逐次、ＲＡＭに展開して実行することも可能である。本発明のプログラムは、コンピュータが備えるＣＰＵなどのプロセッサによって実行される。

上記については単に本発明の原理を示すものである。更に、多数の変形や変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応する全ての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。

１ 情報処理装置
１ａ 記憶部
１ｂ 演算部
２ ルール情報
３ 制御情報
Ａ１ 第１の処理
Ａ２ 第２の処理
Ｂ 条件判定

Claims (13)

1. イベントデータに含まれるイベントの種別に応じて起動される複数の処理を示す情報が記載されたルール情報を参照して、第１の種別のイベントデータを用いる第１の処理を示す情報と、前記第１の処理の結果によらずに当該イベントデータを用いて実行可能であり、後続して記載された処理を実行するか否かを決定する条件判定の処理を示す情報と、前記条件判定に後続して記載され前記第１の処理の結果を用いる第２の処理を示す情報と、を検索し、
   前記ルール情報において前記条件判定が前記第１の処理に後続して記載されている場合、前記条件判定の結果に応じて前記第１の処理を起動するか否かが決定されるように、前記条件判定の処理と前記第１の処理の実行順を入れ替え、前記第１の処理が実行された場合に前記第２の処理が起動されるように制御するための制御情報を前記第１の種別に対して生成し、
   前記第１の種別のイベントデータが入力されると、前記制御情報に基づいて、入力されたイベントデータに応じた処理を実行する、
   処理をコンピュータに実行させるプログラム。
2. 前記第１の処理は、入力された前記第１の種別のイベントデータに基づいて、複数の項目が定義された複数のレコードを含む関係データからレコードを取得する処理である、請求項１記載のプログラム。
3. イベントデータは、複数の項目が定義されたレコードを含み、
   前記関係データからレコードを取得する処理は、入力された前記第１の種別のイベントデータの何れかの項目と前記関係データの何れかの項目とを用いて、当該イベントデータと前記関係データとを結合する処理である、
   請求項２記載のプログラム。
4. 前記第２の処理は、前記第１の処理の結果を用いる他の条件判定の処理である、請求項１乃至３の何れか１項に記載のプログラム。
5. 前記条件判定の結果および前記他の条件判定の結果に応じて実行される第３の処理を示す情報を前記ルール情報から検索し、前記他の条件判定の結果に応じて前記第３の処理が実行されるように処理の実行順を制御するための情報を前記制御情報に登録する、請求項４記載のプログラム。
6. 前記ルール情報は、前記第１の処理を示す情報を含む第１のルール情報と、前記条件判定の処理を示す情報および前記第２の処理を示す情報を含む第２のルール情報とを含み、
   前記第１のルール情報および前記第２のルール情報の個別の入力を許容する、
   請求項１乃至５の何れか１項に記載のプログラム。
7. 処理の内容と当該処理の結果に応じた次の処理を示す情報を示すポインタとを含むデータ構造を用いて前記条件判定の処理を示す情報と前記第１の処理を示す情報と前記第２の処理を示す情報とを記憶手段に設定することで前記制御情報を生成し、前記制御情報に含まれるポインタに基づいて、入力された前記第１の種別のイベントデータに応じた処理の実行順を制御する、請求項１乃至６の何れか１項に記載のプログラム。
8. 前記第１の処理は、複数の項目が定義された複数のレコードを含む関係データから、前記第１の種別のイベントデータに含まれる値に応じたレコードを取得する処理であり、
   前記制御情報を生成する前に、前記第１の処理により前記第１の種別のイベントデータに含まれ得る値に応じて取得されるレコードを前記記憶手段に予め設定し、
   前記第１の処理を示す情報を前記データ構造を用いて前記記憶手段に設定するとき、前記処理の内容として、前記第１の種別のイベントデータに含まれ得る値に対応する前記記憶手段に設定されたレコードを示すポインタを取得するための処理を設定し、
   前記第１の処理の結果として、入力された前記第１の種別のイベントデータに含まれる値に対応するレコードを示すポインタを取得し、前記第２の処理に入力する、
   請求項７記載のプログラム。
9. 前記関係データに含まれる前記複数の項目のうち前記第２の処理で用いられる項目に基づいて、前記記憶手段に予め設定するレコードの項目を決定する、請求項８記載のプログラム。
10. 前記関係データのレコードに含まれる項目と併せて、前記第２の処理で用いられる当該レコードに対応する変数を前記記憶手段に設定し、第１のイベントデータに応じた前記第２の処理で当該変数に値を登録し、第２のイベントデータに応じた処理で当該変数に登録された値を用いる、請求項８または９記載のプログラム。
11. 条件判定の処理専用の条件判定手段を用いて、入力された前記第１の種別のイベントデータに応じた前記条件判定の処理を実行する、請求項１乃至６の何れか１項に記載のプログラム。
12. イベントデータに含まれるイベントの種別に応じて起動される複数の処理を示す情報が記載されたルール情報を記憶する記憶部と、
    前記ルール情報を参照して、第１の種別のイベントデータを用いる第１の処理を示す情報と、前記第１の処理の結果によらずに当該イベントデータを用いて実行可能であり、後続して記載された処理を実行するか否かを決定する条件判定の処理を示す情報と、前記条件判定に後続して記載され前記第１の処理の結果を用いる第２の処理を示す情報と、を検索し、前記ルール情報において前記条件判定が前記第１の処理に後続して記載されている場合、前記条件判定の結果に応じて前記第１の処理を起動するか否かが決定されるように、前記条件判定の処理と前記第１の処理の実行順を入れ替え、前記第１の処理が実行された場合に前記第２の処理が起動されるように制御するための制御情報を前記第１の種別に対して生成し、前記第１の種別のイベントデータが入力されると、前記制御情報に基づいて、入力されたイベントデータに応じた処理を実行する演算部と、
    を有する情報処理装置。
13. 情報処理装置によって実行されるイベント処理方法であって、
    イベントデータに含まれるイベントの種別に応じて起動される複数の処理を示す情報が記載されたルール情報を参照して、第１の種別のイベントデータを用いる第１の処理を示す情報と、前記第１の処理の結果によらずに当該イベントデータを用いて実行可能であり、後続して記載された処理を実行するか否かを決定する条件判定の処理を示す情報と、前記条件判定に後続して記載され前記第１の処理の結果を用いる第２の処理を示す情報と、を検索し、
    前記ルール情報において前記条件判定が前記第１の処理に後続して記載されている場合、前記条件判定の結果に応じて前記第１の処理を起動するか否かが決定されるように、前記条件判定の処理と前記第１の処理の実行順を入れ替え、前記第１の処理が実行された場合に前記第２の処理が起動されるように制御するための制御情報を前記第１の種別に対して生成し、
    前記第１の種別のイベントデータが入力されると、前記制御情報に基づいて、入力されたイベントデータに応じた処理を実行する、
    イベント処理方法。
    

Images