JP2008293445A - データ処理装置及びデータ処理方法及びプログラム - Google Patents

Abstract

【課題】イベントデータに対してルールを適用するルールエンジンの開発におけるデータ開発効率及び保守性の向上を実現する。
【解決手段】イベントデータ管理部２１は、複数のイベントデータプールを備え、イベント送信部１からのイベントデータを入力し、入力したイベントデータをイベント種別に応じていずれかのイベントデータプールにて記憶する。タイマイベント処理部２７は、対応するイベントデータプールのタイマ計時を行い、対応するイベントデータプールにおいて出力タイミングが到来した際に、対応するイベントデータプールにて記憶されているイベントデータをイベントデータ管理部２１から一括して入力するとともに、ルール実行制御部２２に出力する。ルール実行制御部２２は、タイマイベント処理部２７から一括出力されたイベントデータを入力し、入力したイベントデータに対してルールを適用する。
【選択図】図１

Description

本発明は、イベントデータ等のデータに対して所定のルールを適用してルールに記載されている処理を行うデータ処理装置等に関する。

ルール実行の処理方式に関して、ｉｆ−ｔｈｅｎ規則に従って条件にあう動作を行う事で適切な処理を行うルールエンジンの処理方式として、たとえば特許文献１のように、ある１つのルールがデータを受け取ると論理式や条件部などルール処理の過程の一部で別なルールと関連付けられているデータを変更させる事で連続的にルールを適用する事で適切な処理や推論を行う方式が提案されている。
特開平７−１２９４０２号公報

しかしながら、多くの監視対象のデータを規則により継続的に監視するような場合に、監視終了の条件が成立していない監視対象データを一括してルールに適用する必要がある。
たとえば、作業報告など発生してからある一定期間に承認や提出などの処理を実施しないといけないといった期日管理のような場合、データが発生して一定時間でまだ承認や提出が完了してないデータに対して一括してルールを適用する場合などである。
この場合、該当するデータを抽出するロジックをルールとして記述する事で実現できる。たとえば、時刻（タイマ）などのイベントを使い、まだ監視終了の条件を満たしていない監視対象データ（例えば、一定時間内に承認や提出が完了していないデータ）を抽出して、抽出したデータに対して期日管理のルールを適用する方式が考えられる。
しかし、この方式だとタイマのイベントで該当するすべての種類のデータの数分だけデータを抽出するロジックを記述する必要がある。
このため、データ抽出のためのロジックを記述しなければならないという開発効率上の課題、対象データの種類が増減した場合の保守性についての課題、タイマルールで記述するアクションがどのような条件のデータを抽出しているのかが識別しにくいという表現力についての課題などさまざまな課題があった。

本発明は、上記のような課題を解決することを主な目的の一つとしており、ルールを適用する監視対象のデータを保管し、保管されているデータに対して時刻などのイベントが発生した場合にデータの設定条件にあったデータを抽出してルールに一括適用するようにする事で上記課題を解決する事を主な目的とする。

本発明に係るデータ処理装置は、
複数のデータプールを備え、データを入力するとともに、入力したデータのデータ種別に応じて、入力したデータをいずれかのデータプールにて記憶するデータ管理部と、
前記データ管理部のデータプールごとにタイマ計時を行い、いずれかのデータプールにおいて出力タイミングが到来した際に、前記データ管理部に対して出力指示を通知して、出力タイミングが到来したデータプールにて記憶されているデータを一括して出力させるタイマ処理部と、
前記データ管理部により特定のデータプールから一括して出力されたデータを入力し、入力したデータに対してルールの適用を行うルール実行制御部とを有することを特徴とする。

本発明によれば、データプールごとにタイマ計時を行い、出力タイミングが到来したデータプールに記憶さているデータを一括して出力させ、また一括出力されたデータに対してルールを適用するため、データ種類に応じてデータ抽出のためのロジックを記述する必要がなく、対象データの種類が増減した場合もデータ抽出のためのロジックを修正する必要がなく、また、データ抽出の条件が識別しにくいという困難性を伴うことなく、データ開発効率、保守性及びデータ処理効率の向上が図れる。

実施の形態１．
図１は、本実施の形態に係るイベント送信部１及びルールエンジン２の構成例を示した図である。
イベント送信部１は、ルールエンジン２に対してイベントデータを送信する。イベント送信部１は、複数存在してもよい。
ルールエンジン２は、イベント送信部１から送信されたイベントデータを受信して、イベントデータを処理する。
なお、ルールエンジン２は、データ処理装置の例である。

ルールエンジン２において、イベントデータ管理部２１は、イベント送信部１から送信されたイベントデータを受信する。
ルール実行制御部２２は、イベントデータを受け取るとルールに記載された処理を行う。
条件部２３は、条件判定を行うためのルール上の記述である。
実行部２４は、条件に合致した場合にデータ処理を実行するためのルール上の記述である。
タイマイベント制御部２５は、時刻のイベントを発生する。
ルール情報２６には、条件部２３と実行部２４から構成されるルールが記述されている。
タイマイベント処理部２７は、タイマイベントを発生させる。
イベントデータ情報２８は、イベントデータプールの生成、イベントデータプールへのイベントデータの格納又は削除に関する情報である。

イベントデータ管理部２１は、複数のイベントデータプールを備え、イベント送信部１からのイベントデータを入力するとともに、入力したイベントデータのデータ種別に応じて、入力したイベントデータをいずれかのイベントデータプールにて記憶する。
イベントデータプールは、記憶領域における管理単位であり、同種のイベントデータをまとめて蓄積する。イベントデータプールは、イベントデータの種別ごとに分類されている。
イベントデータ管理部２１は、入力したイベントデータを、入力したイベントデータのデータ種別に対応するイベントデータプールにて記憶する。
また、イベントデータ管理部２１は、イベントデータ情報２８を保有し、イベントデータ情報２８の記述に従って、複数のイベントデータプールを生成する。
イベントデータ管理部２１は、イベントデータプールに格納されているイベントデータを、データ内容に変化が生じた際などに、個別にルール実行制御部２２に出力する。これは、従来から行われていることである。
また、イベントデータ管理部２１は、イベントデータのルール実行制御部２２への個別出力の他に、後述するように、タイマイベント制御部２５内のタイマイベント処理部２７からの出力指示により、イベントデータプールにて記憶しているイベントデータの全てを一括してタイマイベント処理部２７に出力する。
イベントデータ管理部２１は、データ管理部の例である。

タイマイベント制御部２５は、タイマイベント処理部２７を管理・制御し、ルール情報２６の記述に従って、タイマイベント処理部２７を起動する。

タイマイベント処理部２７は、イベントデータ管理部２１のイベントデータプールと同数存在し、各タイマイベント処理部２７は、いずれかのイベントデータプールに対応づけられている。
各タイマイベント処理部２７は、それぞれが対応するイベントデータプールのタイマ計時を行い、対応するイベントデータプールにおいて出力タイミングが到来した際に、イベントデータ管理部２１に対して、対応するイベントデータプールについての出力指示を通知して、出力タイミングが到来したイベントデータプールにて記憶されているイベントデータを一括して出力させる。
また、タイマイベント処理部２７は、イベントデータ管理部２１から一括出力されたイベントデータを入力するとともに、ルール実行制御部２２に出力する。
タイマイベント処理部２７は、タイマ処理部の例である。

ルール実行制御部２２は、イベントデータ管理部２１から個別に出力されたイベントデータに対してルールを適用して、イベントデータに対するデータ処理を行う。
また、ルール実行制御部２２は、タイマイベント処理部２７から一括出力されたイベントデータ（いずれかのイベントデータプールから一括出力された）を入力し、入力したイベントデータに対してルールを適用して、イベントデータに対するデータ処理を行う。

次に、イベントデータ情報２８について図７を参照して説明する。
図７は、イベントデータ情報２８の例を示す。
図７において、７０１及び７０２の破線で囲まれている記述は、イベントデータの種別を示しており、この記述に従ってイベントデータ管理部２１は、イベントデータプールを生成する。
図７の例では、イベントデータ管理部２１は、７０１及び７０２において示されているイベントＡ及びイベントＢという２つのイベントに基づいて、２つのイベントデータプールを生成する。
また、７０３及び７０４の破線で囲まれている記述は、削除条件を示しており、これについては実施の形態２で説明する。

次に、ルール情報２６について図８を参照して説明する。
図８は、ルール情報２６の例を示す。
図８において、８０１の破線で囲まれている記述は、イベントデータのデータ値が変更になった場合に、データ値が変更になったイベントデータをルール実行制御部２２に出力することを示す。
図８の例では、イベントデータ管理部２１は、イベントＡに属するイベントデータは、データ値が変更になった際に、ルール実行制御部２２に出力する。
また、８０２の破線で囲まれている記述は、タイマイベント処理部２７によるタイマ計時の対象となるイベントを示す。
また、８０３の破線で囲まれている記述は、タイマイベント処理部２７がタイマ計時を行う際の計時時間を示す。
図８の例では、タイマイベント処理部２７は、イベントＡのイベントデータプールについてのタイマ計時を行い、また、その計時時間は３００秒である。つまり、タイマイベント処理部２７は、３００秒周期で、イベントデータ管理部２１にイベントＡのイベントデータプールに蓄積されているイベントデータを一括して出力するように指示する。

次に、イベント送信部１及びルールエンジン２の動作を説明する。
図２は、イベント送信部１の動作例を示すフローチャートである。
図３は、イベントデータ管理部２１の動作例を示すフローチャートである。
図４は、ルール実行制御部２２の動作例を示すフローチャートである。
図５は、タイマイベント制御部２５の動作例を示すフローチャートである。
図６は、タイマイベント処理部２７の動作例を示すフローチャートである。
以下、図２〜図６を用いて、イベント送信部１及びルールエンジン２の動作を説明する。

先ず、図２に示すように、イベント送信部１は、イベントデータを検知すると（ＳＴ１００）、イベントデータ名とイベントデータをイベントデータ管理部２１に出力する。

ルールエンジン２では、図３に示すように、イベントデータ管理部２１によるデータ管理ステップが実施される。
イベントデータ管理部２１では、起動するとイベントデータ情報２８に設定されているイベントデータの数分、イベントデータを保管するイベントデータプールを作成する（ＳＴ３０１）。具体的には、イベントデータ管理部２１は、図７の７０１及び７０２の破線で囲まれている記述を参照して、その個数分のイベントデータプールを生成する。
次に、イベントデータ管理部２１は、ルール情報２６のｄａｔａＣｈａｎｇｅＥｖｅｎｔ項目を取得し、対象となるイベント名を記憶する（ＳＴ３０２）。つまり、ルール実行制御部２２へのイベントデータの出力の対象となるイベントを特定する。イベントデータ管理部２１は、図８の例では、８０１の破線で囲まれた記述を参照して、ｄａｔａＣｈａｎｇｅＥｖｅｎｔとして、イベントＡを記憶する。
その後、イベントデータ管理部２１は、イベント送信部１又はタイマイベント処理部２７からの入力を待つ（Ｓ３０３）。
次に、イベントデータ管理部２１は、イベント送信部１又はタイマイベント処理部２７からデータを入力し（ＳＴ３０４）、入力したデータの内容を確認する（ＳＴ３０５）。
データ変化通知の場合、すなわち、イベント送信部１からのイベントデータの入力である場合は、ＳＴ３０６に進み、データ取得要求、すなわち、タイマイベント処理部２７からのイベントデータの一括出力の出力指示である場合は、ＳＴ３１２に進む。

ＳＴ３０５において、データ変化通知である場合は、イベントデータ管理部２１は、イベントデータ情報からイベント名を取得して該当するイベントデータプールを見つけ（ＳＴ３０６）、また、イベントデータに設定されているキー情報からイベントデータプールに格納されているイベントデータを調べ、今回入力したイベントデータが新規なイベントデータか、又は既にイベントデータプールに格納済のイベントデータの更新かを判断した後（ＳＴ３０７）、イベントデータプールにイベントデータを追加あるいは更新する（ＳＴ３０８、ＳＴ３０９）。
例えば、企業において、従業員が施錠されている扉を暗号番号入力やＩＣカード（社員証）をカードリーダにかざすなどして開錠するイベントにおいて、同じ従業員が移動に伴って複数の施錠扉を開錠していくような場合、その従業員の従業員ＩＤがキー情報となり、その従業員について開錠イベントのイベントデータが順次イベントデータプールに蓄積されていく。

次に、イベントデータ管理部２１は、ＳＴ３０８又はＳＴ３０９において格納したイベントデータがＳＴ３０２において記憶したｄａｔａＣｈａｎｇｅＥｖｅｎｔに該当するかどうかを判断し（ＳＴ３１０）、該当する場合は、イベント名、適用するルール名、イベントデータをルール実行制御部２２に出力する（ＳＴ３１１）。
一方、ｄａｔａＣｈａｎｇｅＥｖｅｎｔに該当しない場合は、ＳＴ３０３に戻る。
なお、ＳＴ３１１において、ルール実行制御部２２にイベントデータを出力しても、当該イベントデータはイベントデータプールに蓄積されている。

また、ＳＴ３０５において、データ取得要求であった場合、つまり、タイマイベント処理部２７からいずれかのイベントデータプールのイベントデータの一括出力が指示された場合は、イベントデータ管理部２１は、タイマイベント処理部２７により指定されたイベントデータプールのイベントデータを一括してタイマイベント処理部２７に出力する（ＳＴ３１２）。
なお、タイマイベント処理部２７に対してイベントデータを一括して出力した後は、イベントデータ管理部２１は、一括出力したイベントデータを消去してもよいし、一括出力済のイベントデータを格納する別の記憶領域に移動させてもよい。

タイマイベント制御部２５は、図５に示すように、ルール情報２６からルールとタイマに関する情報を取得し（ＳＴ５０１）、タイマが指定されている数分だけタイマ情報と対応イベント名、実行ルール名とともにタイマイベント処理部２７を起動する（ＳＴ５０２）。
具体的には、タイマイベント制御部２５は、図８の８０１の破線で囲まれている記述の個数に従って、対応する数分のタイマイベント処理部２７を起動し、また、タイマイベント処理部２７に８０１の破線で囲まれている対応イベント名（イベントＡ）、８０３の破線で囲まれている記述に示されているタイマ計時時間（３００秒）及びルール情報２６における当該ルールのルール名を通知する。

タイマイベント処理部２７は、図６に示すように、タイマ処理ステップを実施する。
タイマイベント処理部２７は、起動後、タイマイベント制御部２５から通知された対応イベント名、タイマ計時時間、ルール名を設定した後、タイマイベント制御部２５から指定されたタイマ計時時間を待ち（ＳＴ６０１）、該当時間になると、イベントデータと関連づいている場合（ＳＴ６０２）は、該当イベントデータをイベントデータ管理部に要求する（ＳＴ６０３）。
つまり、タイマイベント処理部２７は、自身が対象としてるイベントを確認し（ＳＴ６０２）、そのイベントのイベントデータプールに蓄積されているイベントデータを一括して出力するようイベントデータ管理部２１に指示する（ＳＴ６０３）。
イベントデータ管理部２１から対象となるイベントデータプールに保管されているイベントデータが一括出力されると、一括出力されたイベントデータを入力し（ＳＴ６０４）、実行するルール名とともにルール実行制御部へ渡す（ＳＴ６０５）。

ルール実行制御部２２は、図４に示すように、ルール実行制御ステップを実施する。
ルール実行制御部２２は、入力待ち（ＳＴ４０１）の後、イベントデータ管理部２１又はタイマイベント処理部２７からデータを入力する（ＳＴ４０２）。
以降の処理は、イベントデータ管理部２１からイベントデータを個別に入力した場合も、タイマイベント処理部２７からイベントデータプールに含まれるイベントデータを一括して入力した場合も同様である。
ルール実行制御部２２は、イベントデータを渡されるとイベントデータに関係しているルールをルール情報から取得し（ＳＴ４０３）、入力したイベントデータを一つ取り出し（ＳＴ４０４）、ルールに記載されている条件部を実行し（ＳＴ４０５）、実行結果を判定し（ＳＴ４０６）、結果が真の場合は実行部を実行する（ＳＴ４０７）。
また、他のルールを実行したい場合は、条件部に他のルールに関係しているイベントデータを更新する事でルール実行を波及させルールを連続的に実行していく。
ルール実行制御部は、受け取ったイベントデータを１つずつ処理しすべてのイベントデータがなくなるまでルール処理を実行する（ＳＴ４０８）。

このように、ルールエンジン２は、通知されたイベントデータをイベントデータに定義されているキー情報で保管しておき、タイマイベントが通知されると保管されているイベントデータを一括してルールに適用する事が可能となる。
このため、データ種類に応じてデータ抽出のためのロジックを記述する必要がなく、対象データの種類が増減した場合もデータ抽出のためのロジックを修正する必要がなく、また、データ抽出の条件が識別しにくいという困難性がなく、これにより、イベントデータに対してルールを適用するルールエンジンの開発におけるデータ開発効率及び保守性を向上させることができる。
つまり、従来は、イベントごとに、監視終了条件が完了していないイベントデータを抽出するためのロジックを用意する必要があったが、本実施の形態では、イベントごとに設けているイベントデータプールにイベントデータを蓄積するとともに、タイマイベントが発生した際に、イベントデータプールごとにイベントデータを一括して出力するので、監視終了条件が完了していないイベントデータを選択して抽出する必要がなく、このため、イベントごとにデータ抽出のためのロジックを記述する必要がない。

以上のように、本実施の形態によれば、データの変更がない場合でもタイマをトリガとして保管しているイベントデータを一括してルールに適用し、イベントデータが特定の値になっていないもの（たとえば処理の状態が完了になっていないもの）を見つけ出し通知などの動作を行う事が可能となる。

なお、イベントデータプールは、データベース上に永続的に保管するようにしてもよい。

また、イベントデータ管理部２１において、保管しているイベントデータの有効／無効を設定する手段を持ち、有効となっているイベントデータのみをルール実行制御部２２に渡すようにしてもよい。
また、イベントデータ管理部２１は、イベントデータプールにて記憶されているイベントデータごとにデータの有効／無効を判断し、タイマイベント処理部２７より出力指示が通知された際に、出力が指示されたイベントデータプールで記憶されているイベントデータであって有効と判断したイベントデータのみを一括して出力するようにしてもよい。
例えば、企業におけるイベントデータの場合、例えば、平日（勤務日）のイベントデータは有効とし、休日のイベントデータは無効と判断するようにしてもよい。また、その他の判断基準によりイベントデータの有効／無効を判断してもよい。

以上、本実施の形態では、イベントデータを受信する手段と受信したイベントデータを保管する手段と時間によるタイマイベントを生成する手段とルールで記載された条件を判断する手段と条件が合致した場合にルールに記載された処理を実行する実行手段を持ち、タイマイベントが発生した時に保管しているイベントデータに対して一括してルールを適用する事を特長とするイベントデータ処理方式について主に説明した。

実施の形態２．
図９は、本実施の形態に係るイベント送信部１及びルールエンジン２の構成例を示した図である。
図９では、イベントデータ管理部２１にイベントデータ削除部３０が追加されている点以外は、図１に示す構成と同一である。
イベントデータ削除部３０は、イベントデータプールのイベントデータを自動削除する手段である。
本実施の形態では、イベントデータ管理部２１は、イベントデータ削除部３０を用いて、イベントデータごとに所定の削除条件に合致するか否かを判定し、削除条件に合致するイベントデータを削除し、タイマイベント処理部２７より出力指示が通知された際に、出力が指示されたイベントデータプールで記憶されているイベントデータであってデータ削除後のイベントデータを一括して出力する。

図１０に、本実施の形態に係るイベントデータ管理部２１のフローチャートを示す。
次に動作について説明する。
図１０において、ＳＴ３０１〜ＳＴ３１２は実施の形態１で説明したものと同じであり、図１０ではＳＴ１００１が追加されている。

本実施の形態では、イベントデータ管理部２１は、イベント送信部１からイベントデータを入力した時、ルール実行制御部２２にイベントデータを出力した後（ＳＴ３１１）、削除条件を満たしているかどうかを判定し、満たしている場合はイベントデータプールから当該イベントデータを削除する（ＳＴ１００１）。
削除条件とは、図７の７０３及び７０４の破線で囲まれた記述である。
７０３の破線で囲まれた記述はイベントＡについての削除条件であり、７０４の破線で囲まれた記述はイベントＢについての削除条件である。
イベントデータ管理部２１は、ルール実行制御部２２にイベントデータを出力した後、イベントＡに対応するイベントデータプールに格納されたイベントデータについては、図７の７０３の破線で囲まれた削除条件に合致する場合は、そのイベントデータをイベントデータプールから削除し、イベントＢに対応するイベントデータプールに格納されたイベントデータについては、図７の７０４の破線で囲まれた削除条件に合致する場合は、そのイベントデータをイベントデータプールから削除する。

以上のように、本実施の形態に係るルールエンジンでは、処理が完了したイベントデータなど不要になったイベントデータをプールから削除する事で、すべての保管しているデータに対してルールを適用する必要がなくなりルール実行の処理性能を向上させる事が可能となる。

以上、本実施の形態では、保管しているイベントデータに対してイベントデータ情報の削除条件に合致すると判断した場合にイベントデータを削除する手段を持ち、保管されているイベントデータを一括してルール実行手段に渡す事を特長とするイベントデータ処理方式について主に説明した。

実施の形態３．
図１１は、本実施の形態に係るイベント送信部１及びルールエンジン２の構成例を示した図である。
図１１では、イベントデータ管理部２１にイベントデータ複写部３１が追加されている点以外は、図９に示す構成と同一である。
イベントデータ複写部３１は、イベントデータ管理部２１に通知されたイベントデータを複写して、複数のイベントデータプールへイベントデータを格納する手段である。
本実施の形態では、イベントデータ管理部２１は、イベントデータ複写部３１を用いて、入力したイベントデータのコピーを生成し、二以上の同一のイベントデータを、二以上のイベントデータプールにて記憶する。同一のイベントデータを記憶する二以上のイベントデータプールは、それぞれに設定された削除条件が異なる二以上のイベントデータプールとしてもよい。

図１３に、本実施の形態に係るイベントデータ情報の例を示す。
図１３において、１３０１及び１３０２の破線で囲まれている記述に、イベントデータの複写条件が示されている。
１３０１及び１３０２の記述例では、イベントＡに属するイベントデータを入力した場合に、入力したイベントデータをコピーして２つのイベントデータとし、それぞれイベントＡのイベントデータプールのサブセットであるＣＯＰＹ１のイベントデータプール及びＣＯＰＹ２のイベントデータプールの２つに格納する旨が示されている。
また、例えば、イベントＡに属するイベントデータを入力した場合に、入力したイベントデータをコピーして２つのイベントデータとし、イベントＡのイベントデータプール及びイベントＢのイベントデータプールの２つに格納するように規定してもよい。
また、図１３において、１３０３及び１３０４の破線で囲まれている記述に、それぞれのイベントデータの削除条件が示されている。図１３の例では、１３０３及び１３０４の記述は、同じであり、同じ削除条件が適用されるが、それぞれのイベントデータに対して異なる削除条件を設定することも可能である。

次に、図１２に、本実施の形態に係るイベントデータ管理部のフローチャートを示す。
次に動作について説明する。
図１２において、ＳＴ３０１〜ＳＴ３１２及びＳＴ１００１は、実施の形態１及び実施の形態２で説明したものと同じであり、図１２ではＳＴ１２０１が追加されている。

本実施の形態では、イベントデータ管理部２１において、イベント送信部１からイベント名とイベントデータを受信すると、イベントデータ複写部３１が、イベント送信部１から通知されたイベント名以外にｄｕｐｉｌｉｃａｔｅ指定がされているイベント名をイベントデータ情報から取得し、イベントデータをコピーし、見つかったすべてのイベント名のイベントデータプールにイベントデータを保管する（ＳＴ１２０１）処理を該当するイベント名の数分実行する（ＳＴ１２０２）。その後は、実施の形態１及び実施の形態２に示した処理と同様である。

以上のように、本実施の形態では、１つのイベントデータを削除条件が異なる複数のデータプールに保管することが可能であり、このようにすることで、同一のイベントデータを監視期間が異なるルールに適用する事が可能となる。

以上、本実施の形態では、受信したイベントデータを複数のイベントデータの保管手段に保管する事で同一のイベントデータに対して異なる保管条件を持つ複数のルールに適用する事を特長とするイベントデータ処理方式について主に説明した。

なお、以上では、イベントデータを処理する例について説明したが、対象とするデータはイベントデータに限らず、どのようなデータであってもよい。

最後に実施の形態１〜３に示したルールエンジン２のハードウェア構成例について説明する。
図１４は、実施の形態１〜３に示すルールエンジン２のハードウェア資源の一例を示す図である。なお、図１４の構成は、あくまでもルールエンジン２のハードウェア構成の一例を示すものであり、ルールエンジン２のハードウェア構成は図１４に記載の構成に限らず、他の構成であってもよい。

図１４において、ルールエンジン２は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置あるいは記憶部の一例である。
通信ボード９１５、キーボード９０２、スキャナ装置９０７、ＦＤＤ９０４などは、入力部、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力部、出力装置の一例である。

通信ボード９１５は、ネットワークに接続されている。例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）などに接続されていても構わない。
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。

上記プログラム群９２３には、実施の形態１〜３の説明において「〜部」、「〜手段」として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、実施の形態１〜３の説明において、「〜の判断」、「〜の計算」、「〜の比較」、「〜の格納」、「〜の更新」、「〜の設定」、「〜の登録」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリになどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜３で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、実施の形態１〜３の説明において「〜部」、「〜手段」として説明しているものは、「〜回路」、「〜装置」、「〜機器」、であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」、「〜手段」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、実施の形態１〜３の「〜部」、「〜手段」としてコンピュータを機能させるものである。あるいは、実施の形態１〜３の「〜部」、「〜手段」の手順や方法をコンピュータに実行させるものである。

このように、実施の形態１〜３に示すルールエンジン２は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータであり、上記したように「〜部」、「〜手段」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。

この発明の実施の形態１に係る構成例を示す図である。 この発明の実施の形態１に係るイベントデータ送信部のフローチャートを示す図である。 この発明の実施の形態１に係るイベントデータ管理部のフローチャートを示す図である。 この発明の実施の形態１に係るルール実行制御部のフローチャートを示す図である。 この発明の実施の形態１に係るタイマイベント制御部のフローチャートを示す図である。 この発明の実施の形態１に係るタイマイベント処理部のフローチャートを示す図である。 この発明の実施の形態１に係るイベントデータ情報の例を示す図である。 この発明の実施の形態１に係るルールデータ情報の例を示す図である。 この発明の実施の形態２に係る構成例を示す図である。 この発明の実施の形態２に係るイベントデータ管理部のフローチャートを示す図である。 この発明の実施の形態３に係る構成例を示す図である。 この発明の実施の形態３に係るイベントデータ管理部のフローチャートを示す図である。 この発明の実施の形態３に係るイベントデータ情報の構成図である。 この発明の実施の形態１〜３に係るルールエンジンのハードウェア構成例を示す図である。

符号の説明

１ イベント送信部、２ ルールエンジン、２１ イベントデータ管理部、２２ ルール実行制御部、２３ 条件部、２４ 実行部、２５ タイマイベント制御部、２６ ルール情報、２７ タイマイベント処理部、２８ イベントデータ情報、３０ イベントデータ削除部、３１ イベントデータ複写部３１。

Claims (8)

1. 複数のデータプールを備え、データを入力するとともに、入力したデータのデータ種別に応じて、入力したデータをいずれかのデータプールにて記憶するデータ管理部と、
   前記データ管理部のデータプールごとにタイマ計時を行い、いずれかのデータプールにおいて出力タイミングが到来した際に、前記データ管理部に対して出力指示を通知して、出力タイミングが到来したデータプールにて記憶されているデータを一括して出力させるタイマ処理部と、
   前記データ管理部により特定のデータプールから一括して出力されたデータを入力し、入力したデータに対してルールの適用を行うルール実行制御部とを有することを特徴とするデータ処理装置。
2. 前記データ管理部は、
   データごとに所定の削除条件に合致するか否かを判定し、削除条件に合致するデータを削除し、前記タイマ処理部より出力指示が通知された際に、出力が指示されたデータプールで記憶されているデータであってデータ削除後のデータを一括して出力することを特徴とする請求項１に記載のデータ処理装置。
3. 前記データ管理部は、
   入力したデータのコピーを生成し、二以上の同一データを、それぞれに設定された削除条件が異なる二以上のデータプールにて記憶することを特徴とする請求項２に記載のデータ処理装置。
4. 前記タイマ処理部は、
   前記データ管理部により特定のデータプールから一括して出力されたデータを入力するとともに、入力したデータを前記ルール実行制御部に対して出力することを特徴とする請求項１〜３のいずれかに記載のデータ処理装置。
5. 前記データ管理部は、
   データプールにて記憶されているデータごとにデータの有効・無効を判断し、
   前記タイマ処理部より出力指示が通知された際に、出力が指示されたデータプールで記憶されているデータであって有効と判断したデータのみを一括して出力することを特徴とする請求項１に記載のデータ処理装置。
6. 前記データ管理部は、
   イベントデータを入力し、入力したイベントデータを入力したイベントデータのデータ種別に対応するデータプールにて記憶することを特徴とする請求項１〜５のいずれかに記載のデータ処理装置。
7. コンピュータが、データを入力するとともに、入力したデータのデータ種別に応じて、入力したデータを複数のデータプールのうちのいずれかのデータプールにて記憶するデータ管理ステップと、
   データプールごとにタイマ計時を行い、いずれかのデータプールにおいて出力タイミングが到来した際に、出力タイミングが到来したデータプールにて記憶されているデータを一括して出力させるタイマ処理ステップと、
   特定のデータプールから一括して出力されたデータを入力し、入力したデータに対してルールの適用を行うルール実行制御ステップとを有することを特徴とするデータ処理方法。
8. データを入力するとともに、入力したデータのデータ種別に応じて、入力したデータを複数のデータプールのうちのいずれかのデータプールにて記憶するデータ管理処理と、
   データプールごとにタイマ計時を行い、いずれかのデータプールにおいて出力タイミングが到来した際に、出力タイミングが到来したデータプールにて記憶されているデータを一括して出力させるタイマ処理と、
   特定のデータプールから一括して出力されたデータを入力し、入力したデータに対してルールの適用を行うルール実行制御処理とをコンピュータに実行させることを特徴とするプログラム。

Images