JP2011123601A - イベント一致判定装置、イベント一致判定方法、および、イベント一致判定プログラム - Google Patents

Abstract

【課題】 イベントの一致判定において、不一致判定処理となるまでの処理を削減した一致判定装置を提供すること。
【解決手段】 本発明のイベント一致判定装置は、イベントの少なくとも一部を構成する属性名と属性値とを含む属性の一致判定の優先度を決めるための属性名優先情報を生成する属性名優先情報生成部と、前記属性名優先情報を基にイベントの一致判定に使用する一致判定情報を生成または更新する一致情報生成部と、前記一致判定情報と発生したイベントが一致しているかどうかを判定する一致判定部とを備えることを特徴とする。
【選択図】 図３

Description

本発明は、発生または通知を受けたイベントの判定、特に、イベントを所定のイベントパターンと一致するかどうかの判定を行うイベント一致判定装置、イベント一致判定方法、および、イベント一致判定プログラムに関する。

発生したイベント（出来事）に対応して動作を行う各種のイベント処理装置やイベント処理アプリケーションプログラムが使用されている。例えば、ＲＦＩＤが近づいたことによりＲＦＩＤからＩＤを読み出して決算を行ったり、赤外センサにより人が近づいたことを検出して扉を開けることなど行われている。

近年、このような、センサを使用したシステムが多くなり、イベントの発生量が多くなっている。

また、計算機のマシン室などのように管理された環境だけではなく、一般的な事務所や店舗などに設置されているセンサも多くなっている。そのため、不必要な検出や、誤検出などノイズとなるイベント発生も多くなっている。

そのため、発生した全てのイベントをイベント処理装置で処理するのでは、無駄な処理が多くなり、その結果、必要な処理の応答が遅くなったり、不必要な電力消費が発生していた。

そこで、センサなどから送られてくる大量のイベントから、必要とするイベントを抽出し、必要なイベントをイベント処理装置に配信する、イベント一致判定装置が用いられている。

このようなイベントの一致判定としては、ツリー（木）構造を使用してものがある。例えば、ツリー構造を使用し、イベントが発生したときに、それがどのサブスクリプション（一定条件の下の使用権）にマッチ（一致）するかを求めるシステムがある。（例えば、非特許文献１参照）図３９は、非特許文献１に記載されているイベントが、サブスクリプションにマッチするかどうかを判断するための条件を表しているツリー構造である。各ノード（節点）には、イベントの構成要素である属性名（ａｔｔｒ１−ａｔｔｒ３）が付与されている。ただし、リーフ（葉）ノードには、サブスクリプション（ｓｕｂ１−ｓｕｂ３）が関係づけられている。親ノードと子ノードを結ぶエッジ（境界）には、親ノードに付与されている属性名に対する属性値（Ｖ１−Ｖ３’など）が付与されている。

イベントが入力されると、まず、イベントを参照し、ルート（根）ノードに付与される属性名に対する属性値が求められる。求められた属性値が、ルートノードとその子ノードを接続するエッジに付与される属性値と一致する場合には、木構造を１つ進める。次に、その子ノードと孫ノードの親子関係のノードについて、前述の処理と同様に属性値の一致の判定を行う。この処理を繰り返し実施し、最終的にリーフノードに到達した場合、リーフノードに付与されるサブスクリプションが、イベントがマッチしたサブスクリプションとして決定される。

なお、図３９において、エッジ（境界）に「＊（アスタリスク）」が付与されている場合は、入力されたイベントの属性値によらず、子ノードへ処理を進めることを示している。

さらに、具体的な例を使用して動作の説明を行う。例えば、「ａｔｔｒ１＝Ｖ１、ａｔｔｒ２＝Ｖ２、ａｔｔｒ３＝Ｖ３」であるイベントが入力された場合の動作を説明する。

まず、ルートノードであるａｔｔｒ１の属性値が参照される。属性値が「Ｖ１」なので、その子ノードである左側のａｔｔｒ２に進む。次に、ａｔｔｒ２の属性値が参照される。属性値が「Ｖ２」なので、左側の孫ノードであるａｔｔｒ３に進む。次に、ａｔｔｒ３の属性値が参照される。属性値が「Ｖ３」なので、リーフ・ノードのｓｕｂ１がマッチするサブスクリプションと決定される。

なお、図３９では、対象外のイベントも決定できる。

例えば、「ａｔｔｒ１＝Ｖ１’、ａｔｔｒ２＝Ｖ２、ａｔｔｒ３＝Ｖ３’」であるイベントが入力された場合を説明する。まず、ルートノードでａｔｔｒ１の属性値が参照される。属性が「Ｖ１’」なので、その子ノードである右側のａｔｔｒ２に進む。次に、ａｔｔｒ２の属性値が参照される。属性値が「Ｖ２」なので、孫ノードであるａｔｔｒ３に進む。次に、ａｔｔｒ３の属性が参照される。属性値は「Ｖ３’」である。しかし、対象の孫ノードにおていエッジ（境界）に付与される属性は「Ｖ３」のみである。つまり、一致する属性値が無いため、孫ノードのａｔｔｒ３において処理は進まず、処理を終了する。この結果、今回のイベントは、マッチするサブスクリプションが無い、つまり対象外であることが決定できる。

また、一致判定にハッシュテーブルを使用するものもある。ハッシュテーブルの使用方法としては各種考案されているが、例えば、フィールド（領域）名とポインタ（データが格納されている場所の位置情報）を使用するものもある。（例えば、特許文献１参照）
特許文献１の発明は、図４０に示すように、オブジェクトプログラムのリンク構造について、ハッシュテーブルを各ノード（節点）とし、基本データ（整数データなど）をリーフ（葉）ノードとして表現した木構造を使用したものである。

なお、リーフノード以外は、各フィールド名に対応する基本データ、または、次のノードへのポインタを保持するノードとなっている。

図４０に示すようなこのような木構造の構成を基に、特許文献１に記載の発明は、つぎのように動作する。

まず、ハッシュテーブルに対してフィールド名をキー（識別情報）として、次のノードの先頭アドレス取得する。取得したアドレスが基本データのものであれば、取り出した先頭アドレスの記憶領域を参照し、そのフィールドの値を得る。一方、取り出したアドレスが基本データ以外のものであれば、ポインタを示すノードであるため、そのノードに対して前述と同様に参照先を確認する処理を行う。この処理を繰り返すことで、最終的に基本データに到達し、フィールド名に対する値を得ることができる。

このように構成されている特許文献１に記載のハッシュテーブルを、先に説明した非特許文献１での判定処理に適用することにより、ハッシュテーブルを使用した、イベント一致判定を実現することが出来る。

具体的には、特許文献１におけるキーとして使用されているフィールド名を、非特許文献１のエッジに付与される属性値とする。さらに、特許文献１においてキーに対するバリュー（実現値）として使用する次のノードへのアドレス部分を、非特許文献１の子ノードのキー（属性値、Ｖ１など）に対するバリュー（属性、ａｔｔｒ２など）への参照とすればよい。

さらに詳しく、ハッシュテーブルを用いてキーから、それに関連付けられるバリューを求める動作を説明する。

まず、ハッシュ値をキーとし、各キーに対応するバリューと対応を表すハッシュテーブルを用意する。そして、指定されたキー（フィールド名）にハッシュ関数にかけ、ハッシュ値を求める。次に、ハッシュ値をハッシュテーブルのサイズ（ハッシュテーブルサイズ）で割り、その余りをインデックス（索引）として、ハッシュテーブルからキーとバリューとのペアのリスト（表）を求める。続いて、求めたリストの各要素のキー（フィールド名）を参照し、指定されたキーが一致するかどうかの判定を行う。ここで、ハッシュ値の一致だけではなく、キーの一致も判定しているのは、ハッシュ値の一致だけでは、ハッシュ値の衝突の可能性があるためである。
キーが一致する要素が見つかったら、要素のバリュー（非特許文献１では、次の属性、または、サブスクリプション）を返す。

これにより、非特許文献１においても、ハッシュテーブルを使用することが出来、キーから求められるハッシュ値の衝突がない場合、計算時間を短縮することができる。

M. K. Aguilera, R. E. Strom, D. C. Sturman, M. Astley, and T. D. Chandra: "Matching events in a content-based subscription system," in Proc. 18th Annual ACM Symposium on Principles of Distributed Computing, pp. 53-61 (1999).

特開平９−１６３８１号公報

しかし、非特許文献１においては、イベントのマッチングを行う際に、マッチングを行うツリーの途中またはリーフの近くのノードで一致しないと判定された場合、その判定処理は、それまでに上位のノードで行われた処理に依存するものではない。そのため、一致しないとの判定された場合の上位のノードでの判定処理は、冗長と言える。

また、非特許文献１においては、サブスクリプションがあらかじめ全て用意されていることが前提であり、サブスクリプションの動的な追加・削除に対応することができなかった。

さらに、特許文献１において、フィールド名が文字列の場合、ハッシュ値を使用するため、キーとバリューとのペアのリストを求める操作を高速に行えるが、その後、求めたリストのフィールド名とキーとの一致判定は、文字列の一致判定であり、判定処理に時間が掛かっていた。

本発明の目的は、上述の問題点を解決し、イベントの判定を高速に行うことができるイベント一致判定装置、イベント一致判定方法、および、イベント一致判定プログラムを提供することにある。

本発明のイベント一致判定装置は、イベントの少なくとも一部を構成する属性名と属性値からなる属性の一致判定の優先度を決めるための属性名優先情報を生成する属性名優先情報生成部と、前記属性名優先情報を基にイベントの一致判定に使用する一致判定情報を生成または更新する一致情報生成部と、前記一致判定情報と発生したイベントが一致しているかどうかを判定する一致判定部とを備えることを特徴とする。

本発明のイベント一致判定方法は、イベントの少なくとも一部を構成する属性名と属性値からなる属性の一致判定の優先度を決めるための属性名優先情報を生成するステップと、前記属性名優先情報を基にイベントの一致判定に使用する一致判定情報を生成または更新するステップと、前記一致判定情報と発生したイベントが一致しているかどうかを判定するステップとを備えることを特徴とする。

本発明のコンピュータに実行させるイベント一致判定プログラムは、イベントの少なくとも一部を構成する属性名と属性値からなる属性の一致判定の優先度を決めるための属性名優先情報を生成する処理と、前記属性名優先情報を基にイベントの一致判定に使用する一致判定情報を生成または更新する処理と、前記一致判定情報と発生したイベントが一致しているかどうかを判定する処理とを備えることを特徴とする。

本発明によれば、イベント一致判定装置において、イベントパターンと一致しないイベントを、判定の早い段階で不一致との判定ができる効果が得られる。

本発明の実施形態のイベントの一例を示す図である。 本発明の実施形態のイベントパターンの一例を示す図である。 本発明の第１の実施形態を構成を示すブロック図である。 本発明の第１の実施形態の属性名の優先の一例を示す図である。 本発明の第２の実施形態の構成を示すブロック図である。 本発明の第２の実施形態の一致判定ツリーの一例を示す図である。 本発明の第２の実施形態の判定インスタンスの一例を示す図である。 本発明の第２の実施形態の通知インスタンスの一例を示す図である。 本発明の第２の実施形態の属性名の優先度設定の動作を示すフローチャートである。 本発明の第２の実施形態のイベントパターン登録の動作を示すフローチャートである。 本発明の第２の実施形態の判定インスタンスの属性登録の動作を示すフローチャートである。 本発明の第２の実施形態の属性集合の属性がある場合の属性登録の動作を示すフローチャートである。 本発明の第２の実施形態のインスタンスの追加動作を示すブロック図である。 本発明の第２の実施形態の属性集合に属性がない場合の属性登録の動作を示すフローチャートである。 本発明の第２の実施形態の通知インスタンスの属性登録の動作を示すフローチャートである。 本発明の第２の実施形態のイベントパターン削除の動作を示すフローチャートである。 本発明の第２の実施形態の判定インスタンス削除の動作を示すフローチャートである。 本発明の第２の実施形態の通知インスタンス削除の動作を示すフローチャートである。 本発明の第２の実施形態のイベントマッチングの動作を示すフローチャートである。 本発明の第２の実施形態の判定インスタンスのマッチングの動作を示すフローチャートである。 本発明の第２の実施形態の通知インスタンスのマッチングの動作を示すフローチャートである。 本発明の第３の実施形態のイベントパターンの登録処理の動作を示すフローチャートである。 本発明の第３の実施形態のイベントパターンの削除処理の動作を示すフローチャートである。 本発明の第３の実施形態のイベントのマッチング処理の動作を示すフローチャートである。 本発明の第４の実施形態の通知インスタンスの概要を示すブロック図である。 本発明の第４の実施形態の通知インスタンスの属性登録の動作を示すフローチャートである。 本発明の第４の実施形態の通知インスタンスの一致判定のフローチャートである。 本発明の第５の実施形態の構成を示すブロック図である。 本発明の第５の実施形態の被指定属性情報保持部を示すブロック図である。 本発明の第５の実施形態の属性値参照数テーブルの一例を示す図である。 本発明の第５の実施形態の属性値被指定数テーブルの一例を示す図である。 本発明の第５の実施形態のイベントパターンの登録処理の動作を示すフローチャートである。 本発明の第５の実施形態の属性値被指定数テーブルの登録の動作を示すフローチャートである。 本発明の第５の実施形態のイベントパターンの削除処理の動作を示すフローチャートである。 本発明の第５の実施形態の属性値参照数テーブルの削除の動作を示すフローチャートである。 本発明の第５の実施形態の更新タイミングデータの一例を示す図である。 本発明の第５の実施形態の属性名優先情報の更新の動作を示すフローチャートである。 本発明の第５の実施形態の優先度を更新後の属性名の一例を示す図である。 イベント判定の一例を示す図である。 ハッシュテーブルの一例を示す図である。

次に、本発明について図面を参照して詳細に説明する。
（用語の整理）
最初に本実施形態で使用する用語について整理しておく。

「イベント」とは、携帯端末、ＲＦ(Radio Frequency)タグ、各種センサ（赤外線センサや超音波センサなどの）等を備えた所定の装置がデータを発生すること、および、モジュール（ソフトウェアの処理単位）などが所定の条件一致などからデータを発生することである。

具体的に発生されるデータを使用してイベントを説明すると次のとおりとなる。イベントとは、例えば携帯電話が、図１に一例を示すような、携帯端末を識別する「端末ＩＤ(IDentification)」と、その端末が置かれている「場所」と、発生した「時刻」とから構成されるデータを、発生することである。また、そのデータを受け取ること、および、受け取ったデータの組も、受け取った装置にとってイベントと言う。なお、ここに記載のデータの組み合わせは、あくまで説明の便宜のために記載したものであり、データの数や内容はこれに限られるものではない。

イベントにより発生したデータを構成する個別のデータの名称を「属性名」と言う。

例えば、図１の例において、「端末ＩＤ」、「場所」、「時刻」などが、属性名となる。これら属性名の実際の値、つまり、イベント１の「ＩＤ１」、「東京都港区芝浦２−１１−５」、「１０：１０：１０」などを「属性値」と言う。また、属性名と属性値を合わせて「属性」と呼ぶこととする。

「イベントパターン」とは、イベントの判定条件であり、イベントを構成する一部または全体の属性、つまり一部または全体の属性名に対して属性値を指定したものである。

具体的には、図２に一例を示すように、イベントを構成する属性名（図１の端末ＩＤ，場所，時刻）の一部または全体が指定される。例えば、図２のパターン１は、属性名「端末ＩＤ」に対して属性値「ＩＤ１」が、属性名「場所」に対して属性値「東京都港区芝浦１−１−１」が指定されているイベントパターンである。

「イベントの一致判定」とは、イベントパターンで指定される全ての属性が、判定対象であるイベントの属性と一致するかどうかを判定することである。なお、イベントパターンは、必ずしもイベントの全ての属性を指定するものではない。そのため、イベントパターンで指定された属性が一致すれば一致と判定し、イベントパターンで指定されない属性の属性値の内容の判定は行わない。（以下、場合により、イベントの一致判定の処理をマッチングと言う場合もある。また、一致した場合をイベントがイベントパターンにマッチしたと言う場合もある。）
例えば、図２のパターン１は、指定されている全ての属性（端末IDと場所）が、図１のイベント１と一致するため、図１のイベント１は、図２のパターン１に一致（マッチ）する、または、マッチングしたと判定される。

なお、イベントパターンにおいて記載されていない属性名、および、属性値の「アスタリスク（＊）」は、どのような値でもよいことを意味している。図２のパターン１では、「時刻」が指定されていないためどのような値でもよく、パターン２では、時刻が１１時であれば、分秒はどのような値でもよいことを意味している。
（第１の実施形態）
まず、本発明の第１の実施形態の構成および動作について図３−図４を参照して詳細に説明する。

図３は、第１の実施形態に係る一致判定装置１の構成を示すブロック図である。

属性名優先情報生成部６は、一致判定の対象となる属性名の一致判定処理における優先を示す「属性名優先情報」を生成、または、使用者または図示しない外部装置などにより予め設定されて保持している。

一致情報生成部７は、図２に一例を示したような一致判定のためのイベントパターンと属性名優先情報生成部６に保持されている「属性名優先情報」などを基に、一致判定部８がイベントの一致判定を行うための「一致判定情報」を生成して保持する。

一致判定部８は、図示しない他の装置などで発生した「イベント」を受け、一致情報生成部７の保持されている「一致判定情報」と比較しイベントの一致判定を行う。さらに、一致判定部８は、一致判定の結果、イベントがイベントパターンと一致した場合は、図示しない他の装置または使用者などに「イベント通知」を通知する。

続いて、第１の実施形態に係る一致判定装置１の詳細な動作について説明する。

属性名優先情報生成部６は、一致情報生成部７で一致判定情報を作成する際に使用する属性名優先情報を保持している。この属性名優先情報生成部６で保持している属性名優先情報は、出来るだけ一致判定部８における一致処理において不一致判定が早くできるように決定されている。

例えば、判定方法としてツリー（木）構造を使用する場合、出来るだけツリーのルート（根）に近い部分で不一致の判定が行われるように決定される。

このような属性名の優先の決め方としては、いろいろな方法を採用することが出来るが、例えば、イベントの属性名に対する属性値の（種類の）数を基に決定する方法を採用することができる。各属性値が均等に発生する場合は、属性値の数をｎとすると、各属性値の発生確率Ｐは、
Ｐ＝１／ｎ
となる。従って、属性値の数が多い属性名ほど、個々の属性値の発生確率が小さくなる。つまり、属性値の数が多い属性値ほど、一致する可能性が低い、逆に言うと、不一致となる可能性が高いこととなる。従って、判定のおける優先の順番を、各属性名に対する属性値の数の多さの順とすることにより、不一致となる可能性の大きな属性名から判定を行うことができることとなる。

第１の実施形態の属性名優先情報生成部６も属性値の数の多い属性名を優先するように属性名優先情報を作成し保存している。

このような属性名優先情報について、図４を参照してさらに詳しく説明する。

図１に示すイベントの属性名の属性値の数として、例えば図４（Ａ）に示すようになっていたとする。図４（Ａ）では、「時刻」が属性値の数が最も多く、続いて「端末ＩＤ」、「場所」の順となっている。そのため、優先する属性名の順番も「時刻」「端末ＩＤ」「場所」の順となる。（以下、属性名の優先の順番を、優先度と言い、優先の順番が前のものを優先度が高い、後ろのものを優先度が低いと言う場合もある。）
このように作成した属性名優先情報を属性名優先情報生成部６に保存する。保存する方法としては、図４（Ｂ）に示すように単純に優先度の高い属性名から保存するようにしてもよいし、図４（Ｃ）に示すように属性名と優先度を保存するようにしてもよく、保存形式は問わない。

なお、属性名優先情報生成部６への優先情報の保存は、今までの説明のように属性名優先情報生成部６で処理を行って作成するのではなく、他の装置で作成を行い、その結果を予め属性名優先情報生成部６に登録するようにしてもよい。また、一致判定装置１の使用中に状況に合わせて、図示しない他の装置または使用者などが設定または変更できるようにしてもよい。

一致情報生成部７は、図示しない他の装置または使用者からイベントパターンを受け取り、一致判定部８での一致判定動作に使用する一致判定情報を作成、保持する。だたし、一致情報生成部７ので一致判定情報の生成は、前もってイベントパターンを受け取って保持しておき、図示しない外部装置や使用者に指定されたときに生成するようにしてもよい。

一致判定情報の生成をより詳しく説明すると、次のとおりとなる。

一致情報生成部７は、受け取るまたは保持しているイベントパターンと属性名優先情報生成部６が保持している属性名優先情報を基に、優先度の高い属性名から一致判定を行うように一致判定情報（例えば、ツリー構造をして一致判定情報ツリーなど）を生成する。

例えば、図４（Ｂ）に示すように「時刻」「端末ＩＤ」「場所」との順番に属性名優先情報が生成されていた場合、一致情報生成部７は、最初に「時刻」の判定、次に「端末ＩＤ」の判定、最後に「場所」の判定を行うような一致判定情報を生成し、保持する。

一致判定部８は、図示しないセンサなどからイベントを受け取ると、一致情報生成部７に保存されている一致判定情報を基にイベントが所定のイベントパターンと一致するかどうかの判定を行う。ここで、一致判定情報は、既に説明したとおり、不一致となる可能性高い属性から比較するようになっているため、不一致のイベントを、一致判定の処理の早い段階で判定する可能性が高くなっている。もし、一致するイベントパターンが有った場合は、図示しない他の装置へイベントが発生したことを示すイベント通知を行う。このイベント通知には、イベントまたはイベントパターンの種類などの情報も追加してもよい。一方、一致するイベントパターンが無い場合は、イベント通知の必要のないイベントが発生したと判断し、通知を行わずに判定処理を終了する。

なお、一致情報生成部７は、保持しているイベントパターンの追加、削除または変更などができるようにしてもよい。

さらに、一致情報生成部７で一致判定情報を生成するのではなく、生成は図示しない他の装置などで行い、その結果の一致判定情報を受け取って保持するようにしてもよい。

このような構成により、第１の実施形態のおける一致判定装置１は、イベントのイベントパタンとの一致判定において、不一致の判定を判定の早い段階で見つける可能性高い判定を行うことができる効果を実現している。

その理由は、一致判定部８で一致判定に使用する一致判定情報を、一致情報生成部７で不一致の可能性が高い属性からを行うように構成したためである。
（第２の実施形態）
次に、本発明の第２の実施形態の構成および動作について図５−図２１を参照して詳細に説明する。

図５は、第２の実施形態に係る一致判定装置２の構成を示すブロック図である。

第２の実施形態に係る一致判定装置２は、イベントパターンを管理しているイベントパターン管理装置８１と、イベントを送信してくるイベント通知装置８２と、イベントの通知先であるイベント受信装置８３と共に動作している。

第２の実施形態の属性名優先情報生成部６は、属性値情報保持部１１、属性名優先決定部１２、属性名情報保持部１３を含んで構成されている。

第２の実施形態の一致情報生成部７は、イベントパターン保持部２１、イベントパターン登録部２２、イベントパターン削除部２３、一致判定情報保持部２４を含んで構成されている。

属性値情報保持部１１は、属性名の優先順を決定するときに使用する属性値の情報（属性値情報）を保持している。

属性名優先決定部１２は、属性値情報保持部１１が保持している属性値情報を基に属性名の優先度を示す属性名優先情報を生成し、属性名情報保持部１３に送り出す。

属性名情報保持部１３は、属性名優先決定部１２から属性名優先情報を受け取り保持し、必要に応じて、一致情報生成部７に送付する。

イベントパターン登録部２２は、イベントパターン管理装置８１からイベントパターンを受け取り、イベントパターン保持部２１にイベントパターンを送付して保存させる。さらに、イベントパターン登録部２２は、一致判定情報保持部２４に指示を出して一致判定情報の作成・追加・変更も行う。この登録処理において、必要に応じて属性名優先情報生成部６から属性名優先情報も取得する。

イベントパターン削除部２３は、イベントパターン管理装置８１から指示を受け、イベントパターン保持部２１に保持してされているイベントパターンの削除を行う。さらに、イベントパターン削除部２３は、一致判定情報保持部２４が保持している一致判定情報から削除指定されたイベントパターンに対応する情報の削除も行う。なお、イベントパターン削除部２３も必要に応じて、属性名優先情報生成部６から属性名優先情報を取得してもよい。

イベントパターン保持部２１は、イベントパターン登録部２２から受け取ったイベントパターンを保持し、イベントパターン削除部２３からの指示によりイベントパターンを削除する。

一致判定情報保持部２４は、イベントパターン登録部２２からの指示によりイベントパターンに対応した一致判定情報（以下、一致判定ツリー２５と言う場合もある）の追加を行う。（ただし、初期状態で一致判定情報が無い場合は、一致判定情報の初期の作成も行う。）また、イベントパターン削除部２３から指示により一致判定情報からイベントパターンに対応した一致判定情報の削除を行う。一致判定情報（一致判定ツリー２５）は、一致判定部８におけるイベントの一致判定に使用されるため、一致判定情報保持部２４に保持される。なお、第２の実施形態では、一致判定情報としてツリー構造を使用して説明するが、これはあくまで説明の便宜のためであり、他の構造や、他の判定条件を排除するものではない。

一致判定部８は、第１の実施形態と同様に、イベント通知装置８２から受け取ったイベントを一致判定情報保持部２４に保持されている一致判定ツリー２５と比較し、イベントの一致判定を行い、イベントが一致した場合は、イベント受信装置８３にイベント通知を行う。

続いて、第２の実施形態の動作について図面を参照して詳細に説明する。

最初のイベントの一致判定ツリー２５について説明する。

図６に、第２の実施形態における、一致判定情報保持部２４に保持されている一致判定ツリー２５の一例を示す。一致判定ツリー２５において、各ノード（節点）はインスタンス（実体）である。さらに、インスタンスには２種類あり、リーフ（葉）ノードは通知インスタンス３３、リーフノード以外のノードは判定インスタンス３２となっている。なお、一致判定情報保持部２４の初期状態は、一致判定ツリー２５が保存されていない状態である。

図７に、第２の実施形態における判定インスタンス３２の一例を示す。

判定インスタンス３２は、属性値の一致判定を行い、一致した場合に次のインスタンスに移動を行うインスタンスである。そのため、判定インスタンス３２は、一致判定および移動先のため、いくつかのフィールド（領域）を備えている。

属性名・フィールドは、判定インスタンス３２の一致判定で参照する属性名を保持している。

一致判定テーブル・フィールドは、判定インスタンス３２の属性名・フィールドの属性名に対応する属性値をキー（判定用の鍵）とし、イベントの属性値がキーと同じ値だった場合の次に参照するインスタンスをバリュー（値）として保持している。

アスタリスク（以下、＊と省略することもある）・フィールドは、イベントとのマッチングの時に、そのイベントの属性値によらず、次に参照するインスタンス（判定インスタンス３２、または、通知インスタンス３３）への参照を保持している。このアスタリスク・フィールドは、一致判定テーブル・フィールドに一致する属性値が無い場合に参照されることとなる。そのため、判定インスタンス３２の属性名に対して、全ての属性値が指定されている場合は、つまり、属性値によらないイベントパターンが無い場合は、アスタリスク・フィールドは、次に参照するインスタンスを保持しない。

このような判定インスタンス３２の情報を基に、一致判定部８は、一致判定を行う。もし、イベントの一致判定を行う際に、判定インスタンス３２の一致判定テーブル・フィールドに一致する属性値が無く、アスタリスク・フィールドにも次に参照するインスタンスが無い場合は、一致するイベントパターンが無いと判定することとなる。

なお、判定インスタンス３２は、他のフィールドを備えていても勿論よい。

図８は、第２の実施形態における通知インスタンス３３の一例を示す。

通知インスタンス３３は、図８に示すように、イベントパターンを識別するイベントパターンＩＤのリストを保持している。一致判定装置２において、受け取ったイベントを一致判定ツリー２５とを比較し、いずれかのイベントパターンと一致すると、最終的に、イベントパターンに対応する通知インスタンス３３に達する。そして、その通知インスタンス３３に保持されているイベントパターンＩＤが、一致したイベントパターンのＩＤとなる。その結果、通知インスタンス３３に保持されたイベントパターンＩＤが、イベント受信装置８３に通知される。勿論、この通知は、イベントパターンＩＤに限定されるわけではなく、イベントパターンなどイベントに関連する他の情報を通知するようにしてもよい。

なお、通知インスタンス３３も、他のフィールドを備えていても勿論よい。

次に、属性名の優先度設定の動作について説明する。

第２の実施形態の説明に使用する優先度としては、一例として既に説明した属性名の属性値の数を使用して説明を行う。つまり、第２の実施形態においての属性値情報保持部１１に保持する属性値情報は、図４（Ａ）と同じものとして説明するが、これに限られるわけではない。

なお、第２の実施形態の説明では、この属性値情報について、図示しない手段により、予め使用者が入力することにより設定するものとし、詳細な説明は省略するが、勿論他の手段によって保存されてもよい。

属性値情報は、図４（Ａ）に示すように、各属性名に対して、属性値として取りうる値の数を表したものである。ここでは、属性名「端末ＩＤ」の属性値は１億通り、属性名「場所」の属性値は１００万通り、属性値「時刻」の属性値は（実質）無限に値が存在することを示している。

なお、イベントは、各属性名に対して１つずつ属性値が実現されることとなる。

図９を使用して、属性名の優先度の設定の動作を詳細に説明する。なお、第２の実施形態では、一例として、図４（Ｂ）のように優先度に沿って属性名を並べるものとして以下の説明を行うがこれに限られるわけではない。

第２の実施形態の一致判定装置２における属性名の優先度設定は、まず、属性名優先決定部１２が、属性値情報保持部１１から、属性値情報（ここでは図４（Ａ））を受け取る（ステップ２０１）。続いて属性名優先決定部１２が属性値の数が多い属性名から並べた属性名の一覧表（属性名優先情報、図４（Ｂ））を作成する（ステップ２０２）。そして、作成した属性名優先情報を属性名情報保持部１３に保存する（ステップ２０３）。

このような動作により、属性名情報保持部１３に属性名優先情報が保持されることとなる。

続いて、イベントパターンを基に一致判定ツリー２５の登録に関連する動作について詳細に説明する。

イベントパターン管理装置８１から送られてきた登録すべきイベントパターンは、イベントパターン登録部２２が受け取る。

イベントパターンを受け取ったイベントパターン登録部２２は、一致判定ツリー２５への登録の前準備として、受け取ったイベントパターンをイベントパターン保持部２１に保存し、属性集合の作成を行う。

ここにおける属性集合とは、イベントパターンに含まれる属性（属性名と属性値の組）のデータの集合で、後ほど詳細に説明する。

その後、イベントパターン登録部２２は、まず、一致判定情報保持部２４に保存されている一致判定ツリー２５のルートノードに相当する判定インスタンス３２の属性名・フィールドを参照する。そして、属性集合に含まれる属性名のうち、ルートノードの判定インスタンス３２の属性名と同じ属性名の属性値を基にルートノードの判定インスタンス３２のフィールドのデータを更新する。

この更新処理は、例えば、ルートノードの判定インスタンス３２の属性名と同じイベントパターンの属性名の属性値とその属性値に対応する次のインスタンス（子インスタンス）とを一致判定テーブル・フィールドに登録することにより行う。

なお、属性集合にルートノードの判定インスタンス３２の属性名と一致する属性名がない場合は、そのイベントパターンでは、そのルートノードの属性値一致インスタンスの属性名を使用しないことを意味する。このため、一致判定テーブル・フィールドに一致する属性値が無い場合は、アスタリスク・フィールドに子インスタンスを登録する。

ルートノードの判定インスタンス３２への登録が終了すると、イベントパターン登録部２２は、ルートノードの判定インスタンス３２から指定された子ノードに相当するインスタンスへの登録処理に移行する。

ここで、子ノードのインスタンスもルートノードと同じ判定インスタンス３２の場合は、ルートノードの判定インスタンス３２での処理と同じ処理を行うこととなる。そして、イベントパターン登録部２２は、この処理をイベントパターンが終了するまで繰り返すこととなる。さらに、イベントパターンが終了すると、イベントパターン登録部２２は、最後に登録した判定インスタンス３２の子インスタンスとして通知インスタンス３３を登録して、イベントパターンの登録を終了する。

一方、子ノードが通知インスタンス３３であった場合は、いままで登録されたイベントパターンに比べ、今回登録となったイベントパターンに使用されている属性の数が多いことを示している。従って、このような場合は、新たに追加されたイベントパターンを判定するための判定インスタンス３２を元々有った通知インスタンス３３と置き換える。より詳細に説明すると、対象となった通知インスタンス３３の親ノードに新たに作成した判定インスタンス３２を子ノードとして登録し、新たに作成した判定インスタンス３２のアスタリスク・フィールドの先として、元々有った通知インスタンス３３を登録する。

この一致判定ツリー２５の登録処理を図面を参照してさらに詳細に説明する。

イベントパターン登録部２２によるイベントパターンの登録のフローチャートを図１０に示す。

まず、イベントパターン登録部２２は、受け取ったイベントパターンをイベントパターン保持部２１の「イベントパターンテーブル」に登録する（ステップ３０１）。これは、後ほど動作の説明を行うイベントパターンの削除において使用するためである。イベントパターン登録部２２は、イベントパターンをイベントパターン保持部２１のイベントパターンテーブルへ登録するときに、イベントパターンを識別するためのキーとしてイベントパターンＩＤも登録する。この場合、イベントパターンテーブルのキーに対応するバリュー（値）は、受け取ったイベントパターンである。つまり、イベントパターンテーブルは、イベントパターンＩＤをキーとしてバリューであるイベントパターンを求めることが出来るテーブルとなっている。

なお、第２の実施形態では、イベントパターン登録部２２がイベントパターン管理装置８１からイベントパターンを受け取るときに、イベントパターンＩＤも受け取るとし、詳細な説明は省略する。なお、イベントパターンIDは、イベントパターン管理装置８１ではなく、一致判定装置２が設定し、イベントパターン管理装置８１に通知するようにしてもよい。

次に、イベントパターン登録部２２は、イベントパターンで指定されている全ての属性（属性名と属性値の組）のコピーを生成する（ステップ３０２）。（以下、この属性のコピーの全ておよび以下で説明する一部の属性を削除した後を含め属性集合と言う。）
ここで、属性集合を説明しておく。イベントパターン登録部２２が、一致判定ツリー２５にイベントパターンを登録する場合、必ずしも、受け取ったイベントパターンの最初の属性から登録するとは限らない。これは、既に説明した第１の実施形態と同様に、第２の実施形態において、不一致判定の可能性が高い属性から登録するためである。そのため、一致判定ツリー２５にイベントパターンを登録していく過程で、対象のイベントパターンの登録済みの属性と未登録の属性を管理することが必要である。ただし、登録済み属性は、登録以降は使用することがないため、未登録の属性を管理すればよい。そこで、第２の実施形態では、イベントパターンの登録に先駆け、イベントパターンに含まれる全ての属性による属性集合を作成し、一致判定ツリー２５に属性を登録すると、その属性を属性集合から削除するようにしている。この結果、属性集合は常に一致判定ツリー２５に未登録の属性で構成される集合となる。なお、属性集合は、最終的にイベントパターンの全ての属性が一致判定ツリー２５に登録されると、空集合、つまり保持する属性が無くなることとなる。

続いて、イベントパターン登録部２２は、一致判定情報保持部２４の一致判定ツリー２５にルートノードが存在しているか否か、つまり既に一致判定ツリー２５が登録されているかどうかの判定を行う（ステップ３０３）。

もし、一致判定ツリー２５にルートノードが存在していた場合は、ルートノードの登録処理をスキップして、イベントパターンの属性を一致判定ツリー２５に登録する処理に移動する（ステップ３０７）。

一方、一致判定ツリー２５にルートノードが存在しない、つまり一致判定ツリー２５が一致判定情報保持部２４に無い場合、そのままではイベントパターンを登録することが出来ないため、イベントパターン登録部２２は一致判定ツリー２５の登録処理を行う。この一致判定ツリー２５の登録処理としては、まずルートノードとして、判定インスタンス３２を生成する（ステップ３０４）。

なお、第２の実施形態では、イベントパターン登録部２２、イベントパターン削除部２３、および、一致判定部８は、予め一致判定ツリー２５のルートノードにアクセスするための情報（ポインタなど）を保持しているものとする。

さらに、イベントパターン登録部２２は、属性名情報保持部１３に保持されている属性名優先情報を基に、最も優先度の高い属性名の決定する（ステップ３０５）。

そして、イベントパターン登録部２２は、ステップ３０４で作成したルートノードの判定インスタンス３２の属性名・フィールドにステップ３０５で決定した属性名を設定する（ステップ３０６）。

これにより、一致判定ツリー２５のルートノードの属性値一致インスタンスが作成される。

この後は、イベントパターン登録部２２は、ルートノードの判定インスタンス３２から参照して一致判定ツリー２５に属性集合の属性登録を実行する（ステップ３０７）。

次に一致判定ツリー２５への属性登録の動作について、図面を参照してさらに詳細に説明する。

まず、以下の説明で、複数の種類のインスタンスが出てくるため、説明において各インスタンスの区別が明確になるように、次のように用語を規定しておく。

イベントパターンの登録処理で、現在の処理対象であるインスタンスには、「対象」を付けるものとする。つまり、対象判定インスタンスと、対象通知インスタンスとがあり、併せて対象インスタンスとする。処理の中で新たに作成するインスタンスには「追加」を付けるものとする。つまり、追加判定インスタンスと追加通知インスタンスとが有り、併せて追加インスタンスとする。対象判定インスタンスの子インスタンス、つまり現在の処理対象の判定インスタンスから参照されるインスタンスには、「参照」と付けるものとする。つまり、参照判定インスタンスと参照通知インスタンスが有り、併せて参照インスタンスとする。

なお、説明の便宜のため、「対象」等を付したインスタンスの符号番号は省略する。

また、場合により、インスタンス内のフィールドおよびフィールドに設定されているデータに関しても、次のとおりに省略することもある。例えば、判定インスタンス３２の属性名・フィールドに設定されている属性名は、単に判定インスタンスの属性名と言うこともある。また、一致判定テーブル・フィールドの登録されているキーとしての属性の属性値及びバリューとしてのインスタンスを、一致判定テーブルの属性値とインスタンスなどと言うこともある。

続いて、属性登録動作についての説明の戻る。

まず、判定インスタンス３２における属性登録動作について説明する。

図１１は、処理対象のインスタンスが判定インスタンス３２である場合の属性登録動作を示すフローチャートである。

まず、イベントパターン登録部２２は、属性集合の中に、対象判定インスタンスの属性名が有るかどうかを判別する（ステップ４０１）。

なお、ここで属性名が見つかり、後ほどより詳細に説明する判定インスタンス３２への登録処理が終了すると、その属性名の属性は参照済みとなり、属性集合から取り除くこととなる。

図１１に戻り、イベントパターン登録部２２は、属性名に対応する属性が属性集合に存在したかどうかにより次の動作を切替える（ステップ４０２）。

属性が存在した場合（ステップ４０２の左）、その属性を基に、イベントパターン登録部２２は、イベントパターンとして、一致判定ツリー２５における対象判定インスタンスの一致判定テーブルを更新する処理を実行する（ステップ４０３）。この更新の処理では、必要に応じて追加インスタンスの取得、または、生成も行われる。この処理については、後ほどさらに詳細に説明する。

一方、そのような属性が存在しなかった場合、イベントパターン登録部２２は、任意の属性値を対応するアスタリスク・フィールドを更新する処理を実行する（ステップ４０４）。この処理も必要に応じて追加インスタンスを取得、または、生成が行われる。この処理についても、後ほど詳細に説明する。

いずれの場合においても、フィールドの更新の処理が終了すると、追加インスタンスが有った場合は、その追加インスタンスに異動し、追加が無かった場合は参照インスタンスに異動して属性登録を行うこととなる（ステップ４０５）。

図１１における属性集合に属性が有った場合（ステップ４０３）の動作について、図１２を参照してさらに詳細に説明する。

まず、イベントパターン登録部２２は、対象判定インスタンスの一致判定テーブルに属性集合の属性名に対する属性値の登録があるかどうかを判定する（ステップ５０１）。より詳細に説明すると、次のようになる。まず、属性集合から対象判定インスタンスの属性名の組である属性値を取り出し、その属性値が対象判定インスタンスの一致判定テーブルに有るかどうかを確認する。一致判定テーブルに有る場合は、次に参照する参照インスタンスがバリューとして登録されていることになる。

バリュー（参照インスタンス）として登録されているかどうかで以降の動作が異なる（ステップ５０２）。

参照インスタンスが存在する場合には（ステップ５０２のｙｅｓ）、イベントパターン登録部２２は、参照インタスタンスのタイプを判定する（ステップ５０３）。ここでの、参照インスタンスのタイプの判定とは、参照判定インスタンスであるか、参照通知インスタンスであるかを判定することである。

参照インスタンスが参照判定インスタンスであれば、イベントパターン登録部２２は、その参照判定インスタンスの属性名と属性名優先度情報を参照し、属性集合に、参照判定インスタンスの属性名よりも優先度の高い属性名を持つ属性が存在するかどうかを判定する（ステップ５０４）。

属性集合に優先度が高い属性名を持つ属性が無ければ、一致判定テーブルで判定された参照判定インスタンスの属性名が最も優先度が高く、新たに追加判定インスタンスを取得または生成する必要が無い。そのため、対象判定インスタンスの一致判定テーブルの更新動作を終了する（ステップ５０４のｎｏ）。なお、ここでの処理の終了とは、対象インスタンスでの処理を終了し、参照インスタンス（ただし、以下で説明する、追加インスタンスを追加した場合は追加インスタンス）での登録処理が起動されることとなる。

一方、属性集合に優先度が高い属性が存在する場合（ステップ５０４のｙｅｓ）、イベントパターン登録部２２は、一致判定ツリー２５においてその属性名を持つ追加判定インスタンスを新規に生成し（ステップ５０５）、追加判定インスタンスを、対象判定インスタンスと、参照判定インスタンスの間に挿入する。

図１３は、この一致判定テーブルの変更を示すブロック図である。図１３（Ａ）は、追加前の状態で、対象判定インスタンスの子ノードとして参照判定インスタンスが登録されていることを示している。図１３（Ｂ）は、追加判定インスタンスを追加した後の状態を示している。対象判定インスタンスの子ノードとして追加判定インスタンスが登録され、追加判定インスタンスの子ノードとして参照判定インスタンスが登録されている。

なお、ここでの参照インスタンスとして、参照判定インスタンスとなっているが、参照通知インスタンスの場合も後ほど説明するが同様の処理となる。

図１２の処理の説明に戻り、イベントパターン登録部２２による追加判定インスタンスの挿入処理をより具体的に説明すると次のとおりとなる。

（１）先ほど判別した属性集合の属性の最も優先度の高い属性名を、追加判定インスタンスの属性名に登録する（ステップ５０６）。

（２）追加判定インスタンスのアスタリスク・フィールドに、参照判定インスタンス（最初に対象判定スタンスの参照あった参照判定インスタンス）への参照を登録する（ステップ５０７）。

（３）対象判定インスタンスの一致判定テーブルのキー（属性値）に対するバリュー（インスタンス）として、追加判定インスタンスを登録する（ステップ５０８）。

これにより、追加判定インスタンスの挿入が完了する。

一方、対象インスタンスが、参照通知インスタンスの場合、属性集合が空かどうかを判定する（ステップ５０９）。ここにおける空かどうかの判定は、当然であるが、現在登録処理の対象となっている属性を除いての判定、つまり、現在登録処理をしている属性が属性集合の最後の属性であるかどうかを判定することである。

属性集合が空であれば、これ以上一致判定を行う属性は存在せず、参照通知インスタンスも登録済みのため、登録処理は終了となる（ステップ５０９のｙｅｓ）。

属性集合が空でない場合には、まだ一致判定の対象となる属性が残っていることとなる。従って、残りの属性の一致判定を行うように一致判定ツリー２５を更新する必要がある。

そのため、イベントパターン登録部２２は、一致判定ツリー２５において新規に追加判定インスタンスを生成し、それを対象判定インスタンスと、参照通知インスタンスの間に挿入する。

この処理は、先ほどのステップ５０４において高い優先度の属性が有ったと判定されたときと同様の処理となる。ただし、先ほどステップ５０７において、追加判定インスタンスのアスタリスク・フィールドに登録するインスタンスとして、参照判定インスタンスとなっていたとことが、参照通知インスタンスとなる（ステップ５０６−５０８）。

ステップ５０２において、属性値に対応するインスタンスが存在しない場合は、次に、属性集合が空かどうかを判定する（ステップ５１０）。ここの判定も、既に述べたとおり、現在の処理対象の属性が最後の属性であるかどうかの判定である。

属性集合が空でない場合（ステップ５１０でｎｏ）、つまり、まだ一致判定の対象となる属性が残っている場合、イベントパターン登録部２２は、一致判定ツリー２５において一致判定を継続するために追加判定インスタンスを生成する（ステップ５１１）。さらに、イベントパターン登録部２２は、属性名優先度情報と属性集合を参照して、属性集合の中で最も優先度の高い属性を選ぶ（ステップ５１２）。ステップ５１１で生成した追加判定インスタンスの属性名に、ステップ５１２で選んだ優先度の高い属性の属性名を登録する（ステップ５１３）。その後で、対象判定インスタンスの一致判定テーブルに、優先度の高い属性の属性値と、その属性値に対するインスタンスとしての追加判定インスタンスとを登録する（ステップ５０８）。

ステップ５１０で属性集合が空の場合（ステップ５１０でｙｅｓ）は、一致判定を行う属性が残っていない場合であり、追加通知インスタンスを登録することとなる。このため、イベントパターン登録部２２は、追加通知インスタンスを生成し（ステップ５１４）、それを対象判定インスタンスの一致判定テーブルに、属性値とその属性値に対するバリューであるインスタンスとして追加通知インスタンスを登録する（ステップ５０８）。

続いて、図１１のフローチャートで一致する属性が無かった場合（ステップ４０４）の動作について、図１４を参照してさらに詳細に説明する。

最初に、イベントパターン登録部２２は、対象判定インスタンスのアスタリスク・フィールドに参照インスタンスがあるかどうかを判定する（ステップ６０１）。

以降の動作は、図１２のステップ５０２以降の動作と概ね同様の処理となる。

参照インスタンスの有無の結果により処理を分岐する（ステップ６０２）。

参照インスタンスが有る場合は、参照インスタンスの種類を判別する（ステップ６０３）。

登録されていた参照インスタンスが参照判定インスタンスの場合は、さらに優先度の高い属性が属性集合に有るかどうかを確認し（ステップ６０４）、無い場合は処理終了する。高い優先度の属性がある場合は、追加判定インスタンスを生成する（ステップ６０５）。追加判定インスタンスの属性名に優先度の高い属性の属性名を登録する（ステップ６０６）。さらに、追加判定インスタンスのアスタリスク・フィールドに参照判定インスタンスを登録する（ステップ６０７）。そして、追加判定インスタンスへの参照を、対象判定インスタンスのアスタリスク・フィールドに登録する（ステップ６０８）。

参照インスタンスが参照通知インスタンスの場合は、属性集合が空かどうかを判定し（ステップ６０９）、空なら終了し、空でなければ、参照判定インスタンスと同様の処理を行う（ステップ６０５−６０８）。

参照インスタンスが無い場合は、属性集合が空かどうかを判定する（ステップ６１０）。

属性集合が空でなければ、追加判定インスタンスを生成し（ステップ６１１）、優先度の高い属性名を求め（ステップ６１２）、追加判定インスタンスの属性名を設定する（ステップ６１３）。属性集合が空なら、追加通知インスタンスを生成する（ステップ６１４）。最後の、新規に生成した追加通知インスタンスの参照を、対象判定インスタンスのアスタリスクフィールドに記録する（ステップ６０８）。

次に、通知インスタンス３２の属性登録動作について説明する。

図１５は、通知インスタンス３２の登録処理のフローチャートである。イベントパターン登録部２２は、対象通知インスタンスのイベントパターンＩＤリストに、イベントパターンに設定されたイベントパターンＩＤを追加する（ステップ７０１）。

これらの動作により、イベントパターン登録部２２は、登録するイベントパターンを基とした一致判定情報を一致判定ツリー２５に登録することができる。

次に、一致判定ツリー２５からイベントパターンを削除する動作について図面を参照して説明する。

イベントパターン削除部２３がイベントパターン管理装置８１からイベントパターンＩＤを指定したイベントパターンの削除要求を受けると、イベントパターンの削除動作が開始される。イベントパターン削除部２３は、指定されたイベントパターンＩＤに対応するイベントパターンを一致判定ツリー２５などから削除する。このイベントパターン削除部２３による一致判定ツリー２５からイベントパターンを削除する動作は、一致判定ツリー２５のルートノードから順番にイベントパターンに対応する子ノードを再帰的に参照する。つまり、イベントパターンのリーフノードまでたどり着いてから逆方向にイベントパターンを削除していく処理となる。

図１６に、イベントパターン削除部２３によるイベントパターンを削除する動作のフローチャートを示す。

まず、イベントパターン削除部２３は、イベントパターン保持部２１のイベントパターンテーブルを参照して、イベントパターンＩＤと対応するイベントパターンを取得する（ステップ８０１）。次に、イベントパターンを取得後に、そのイベントパターンＩＤとイベントパターンのペアをイベントパターンテーブルから削除する（ステップ８０２）。ただし、この削除動作は、イベントパターンを一致判定ツリー２５から削除後に行ってもよい。

次に、イベントパターン削除部２３は、一致判定ツリー２５のルートノードに相当する判定インスタンス３２から一致判定ツリー２５を、イベントパターンを基に参照する。その後、再帰的に削除するイベントパターンの属性に対応したインスタンスの削除及び修正を行う（ステップ８０３）。

なお、イベントパターンに対応した属性を削除後、各ノードのインスタンスに登録されている残ったイベントパターンの確認も行う（ステップ８０４）。もし、既に説明した削除動作に伴い、どこかのノードのインスタンスに登録されているイベントパターンが１つも無い状態となった場合は、そのノードのインスタンスは、どのイベントパターンからも参照されないこととなる。従って、そのノードのインスタンスを削除する（ステップ８０５）。さらに、この不必要なノードのインスタンスの削除に伴い、親ノードのインスタンスの参照情報の修正も必要であるので、親ノードのインスタンスの修正も行う。

ここにおけるイベントパターンが１つも無い状態とは、具体的には各インスタンスで次の条件が成立している状態である。

・判定インスタンス３２
(a)一致判定テーブルに１つも属性値（キー）とインスタンス（バリュー）の組が登録されていない
かつ
(b)アスタリスク・フィールドが１つもインスタンスを参照していない
・通知インスタンス３３
(a)イベントパターンＩＤリストが空の状態
なお、もし、削除の結果としてルートノードの判定インスタンス３２もなくなった場合、一致判定装置２は、初期状態の戻ったこと同じになる。

処理対処のインスタンスが判定インスタンス３２の場合のイベントターンの削除動作について図１７を参照してより詳細に説明する。

イベントパターン削除部２３は、削除対象のイベントパターンから対象判定インスタンスの属性値を求める（ステップ９０１）。属性値に有無により処理が異なる（ステップ９０２）。

対象判定インスタンスに削除する属性値が存在した場合（ステップ９０２のｙｅｓ）、求めた属性値をキーとして一致判定テーブルを参照し、バリュー（参照インスタンス）を求める（ステップ９０３）。求めた参照インスタンスを参照して属性削除を再帰的に実行する（ステップ９０４）。

ここにおける再起的実行とは、次のような処理を行うことである。

例えば一例として、ルートノードから３段のイベントパターンの削除する動作について説明する。この場合は、削除対象となるイベントパターンに対する一致判定ツリー２５に登録されているインスタンスは、ルートノードの判定インスタンス３２−子ノードの判定インスタンス３２−孫ノードの通知インスタンス３３となる。イベントパターン削除部２３は、削除動作として、まず、イベントパターンに対応した判定経路、つまり、ルートノード−子ノード−孫ノードとたどる。その後、孫ノードの通知インスタンス３３に達したら、今後は逆方向に処理を進める。つまり、孫ノードの通知インスタンス３３のイベントパタンIDの削除、及び、必要に応じて子ノードの判定インスタンスとルートノードの判定インスタンスの参照の修正を行い、イベントパターンに対応する参照データの削除を行っていく。

削除動作後、イベントパターン削除部２３は、削除対象となった対象判定インスタンスに記憶されるイベントパターンが残っているかどうかの判定を行う（ステップ９０５）。もし、残っているイベントパターンに対応する属性がひとつも無い場合には、そのインスタンスにたどり着くイベントパターンが無いことを意味する。そのため、親ノードにおける対象インスタンスへのキー（属性値）とバリュー（対象判定インスタンス）の関係を一致判定ツリー２５から削除し、そのインスタンスへの経路を削除する。その後、登録属性が無くなった対象判定インスタンス自体を削除する（ステップ９０６）。

一方、対象判定インスタンスに削除する属性値が登録されていない場合（ステップ９０２の右）、アスタリスク・フィールドが参照する参照インスタンスを参照して属性削除を継続する（ステップ９０７）。

アスタリスク・フィールドを使用した場合も、削除の後、参照インスタンスに記憶されるイベントパターンが１つもないかどうかの確認を行う（ステップ９０８）。アスタリスク・フィールドで参照していた参照インスタンスに、１つも参照するイベントパターンが無くなった場合、対象判定インスタンスのアスタリスク・フィールドから参照インスタンスを削除する。そして、イベントパターンが無くなった参照インスタンス自体も削除する（ステップ９０９）。

処理対象のインスタンスが対象通知インスタンスある場合の削除動作について、図１８を参照して詳細に説明する。

イベントパターン削除部２３は、対象通知インスタンスのイベントパターンＩＤリストから指定されたイベントパターンのイベントパターンＩＤを削除する（ステップ１００１）。その後、イベントパターンＩＤリストにイベントパターンＩＤが残っているかどうかを確認し（ステップ１００２）、１つもイベントパターンＩＤが残っていない場合は、その対象通知インスタンスを削除する（ステップ１００３）。

なお、対象通知インスタンスを削除した場合も、親ノードのインスタンスからルートノードのインスタンスまでイベントパターンが残っているかどうかの確認を行い、必要な削除処理を行う。

最後に、イベントのマッチング（一致判定）の動作について詳細に説明する。一致判定装置２は、イベント通知装置８２からイベントと受け取り、イベントパターンとの一致判定を行い、イベントと一致したイベントパターンにイベントパターンＩＤを付与して、イベント受信装置８３に通知する。

イベントが一致判定部８に入力されたときの最初の処理を図１９を参照して説明する。

一致判定部８は、一致判定動作として、一致判定ツリー２５のルートノードからリーフノードに向かって参照しながら、イベントの一致判定を行う。従って、一致判定ツリー２５にルートノードが存在しない場合、つまり初期状態など、一致判定ツリー２５が無い場合は、一致判定を終了することとなる。

そのため、イベントが入力された一致判定部８は、まず、一致判定ツリー２５のルートノードの判定インスタンス３２を参照して、ルートノードが有るかどうか判定する（ステップ１１０１）。もし、ルートノードが無い場合は、そこでマッチングを終了する。ルートノードがあった場合は、属性値一致判定を行う（ステップ１１０２）。

次に、一致判定部８における属性値一致判定処理について図面を参照してより詳細に説明する。

まず、対象となるインスタンスが判定インスタンス３２である場合の処理を図２０を参照して説明する。

一致判定部８は、入力されたイベントから、一致判定の対象となっている対象判定インスタンスの属性名に対応する属性値を取得する（ステップ１２０１）。

次に、属性値をキーとして、一致判定テーブルを参照し、バリューである参照インスタンス（参照判定インスタンス、または、参照通知インスタンス）を求める（ステップ１２０２）。

一致判定テーブルに対応する参照インスタンスが有るかどうかで処理を分岐する（ステップ１２０３）。対応する参照インスタンスが有った場合は、その参照インスタンスを参照して属性値一致判定を継続する（ステップ１２０４）。

一致判定テーブルに対応する参照インスタンスが無い場合は、アスタリスク・フィールドに参照インスタンスが有るかどうかを確認する（ステップ１２０５）。

アスタリスク・フィールドのバリューとして参照インスタンスが存在する場合には、その参照インスタンスを参照して属性値一致判定を継続する（ステップ１２０６）。

一致判定テーブルに一致する属性値が無く、アスタリスク・フィールドにも登録がない場合は、一致するイベントパターンが無いこととなり、一致判定処理を終了する。

対象となるインスタンスが、通知インスタンス３３である場合の動作を図２１を参照して説明する。

対象通知インスタンスであることを認識した一致判定部８は、入力されたイベントと、通知インスタンスに登録されているイベントパターンＩＤリストのイベントパターンＩＤとの組をイベント受信装置８３に通知する。

以上に説明したような動作により、一致判定部８は、一致判定処理を行う。

このように構成された第２の実施形態は、一致判定部８において実行するイベント通知装置８２から通知されるイベントの一致処理において、イベントの不一致判定を、一致判定ツリー２５のルートノードの近くで行える可能性が高くする効果を実現している。

この理由は、第２の実施形態では、属性値情報保持部１１に保持されている属性値情報を利用して、一致判定となりにくい属性名を判別し、一致判定となりにくい属性から一致判定情報（一致判定ツリー２５）に登録するためである。

この理由を、より具体的に、第２の実施形態の説明の一例を参照して説明すると、次のとおりとなる。

「端末ＩＤ」と「場所」を指定した１つのイベントパターンが一致判定装置２に登録されているとする。また、「端末ＩＤ」が取りうる属性値が１億通りあり、「場所」が取りうる属性値が１００万通りあるとする。ここで、入力されるイベントの「端末ＩＤ」と「場所」とに対する属性値の取りうる値が、各属性値の全体集合から一様ランダムに決定されると仮定する。すると、登録されたイベントパターンの「端末ＩＤ」の値に一致する確率は、１／１億であり、「場所」の値にマッチする確率は１／１００万である。第２の実施形態の一致判定装置２は、属性名優先情報生成部６の属性名優先情報を使用することにより、一致する可能性の低い属性、つまり「端末ＩＤ」から一致判定を行う一致判定ツリー２５を作成する。その結果、一致する可能性が低い属性から一致判定を実行できる。その結果として、一致しないイベントパターンを早く検出でき、イベントの判定処理を早く終了することができるためである。

さらに、第２の実施形態では、イベントパターンの動的な追加・削除に対応できる効果を実現している。

この理由は、一致判定ツリー２５にイベントパターンを登録するイベントパターン登録部２２と削除するイベントパターン削除部２３を備え、外部装置などからの指示により一致判定ツリー２５に追加および削除が行えるようにしたためである。

この理由も、第２の実施形態の説明の一例を参照して、より具体的に説明する。

例えば、あるサービス提供事業者の所定の会員が、所定のエリア入った場合に、所定の広告などを送ることを実現しようとする場合について説明する。この場合、第２の実施形態において、「端末ＩＤ」と「場所」とを指定するイベントパターンを一致判定ツリー２５に登録することにより、イベントパターンと一致したイベント受け取った一致判定装置２が、広告を送信するサーバにイベント通知することができる。これにより、広告通知を実現できる。また、第２の実施形態では、例えば、キャンペーン期間開始時にイベントパターンを登録し、キャンペーン期間終了時に、イベントパターンを削除することにより、所定期間だけの要求にも応えることができる。
（第３の実施形態）
次に、本発明の第３の実施形態について図２２−図２４を参照して説明する。

第２の実施形態では、属性値をそのまま使用していたが、属性値は、必ずしも短いとは限らず、長い文字列となっている場合もある。

そこで、第３の実施形態では、第２の実施形態のように一致判定テーブルのキーとして属性値そのものを保存して使用するのではなく、属性値にハッシュ関数を適用して得られたハッシュ値を一致判定テーブルのキーとして保存する。ここにおいて、一致判定テーブルはハッシュ値を使用したハッシュテーブルであるため、キーにハッシュ関数を適用して得られたハッシュ値をハッシュテーブルサイズで割り、その余りを一致判定テーブルのインデックスとすることができる。しかし、一致判定テーブルのキー自体がハッシュ値であるため、一致判定テーブルではキーにハッシュ関数を適用することは行わず、キーをハッシュテーブルサイズで割り、その余りを一致判定テーブルのインデックスとすることもできる。以下の第３の実施形態の説明としては、インデックスとしてキーを割った余りを使用するものとする。このように、第３の実施形態では、一致判定において一致判定テーブルのキーであるハッシュ値を使用することにより、一致判定の対象を短くして、一致判定処理の高速化を図っている。

なお、第３の実施形態においてハッシュ値を使用する点以外は、図５に示す第２の実施形態の構成と同じである。そのため、第２の実施形態と異なるハッシュ値に関係する部分を詳細に説明し、第２の実施形態と同じ構成に関しては、説明を省略する。

また、ハッシュ関数についても一般的なハッシュ関数を使用すればよく、詳細な説明は省略する。

まず、イベントパターンの登録処理について図２２を参照して説明する。

図２２は、第３の実施形態における判定インスタンス３２の属性登録の動作を示すフローチャートである。第３の実施形態における図２２の処理は、第２の実施形態の図１２の処理に相当する。第３の実施形態における図２２の処理で図１２と異なる動作は、ステップ１４０１とステップ１４０８となっている。

第３の実施形態のステップ１４０１では、まず、イベントパターン登録部２２は、属性値にハッシュ関数を適用し、ハッシュ値を求める。そして、イベントパターン登録部２２は、一致判定テーブルを参照して、求めたハッシュ値に対応するバリューである参照されているインスタンスが有るかどうかを判定する。つまり、第２の実施形態において属性値から直接参照されるインスタンスを求めていた処理を、第３の実施形態では、属性値にハッシュ関数を適用したハッシュ値を基の求めるように変更している。

また、第３の実施形態では、最後のステップ１４０８において、一致判定テーブルに生成した追加インスタンスを登録する際に、属性値ではなく、属性値のハッシュ値に登録する点も第２の実施形態と異なる。

それ以外の動作は、第２の実施形態と同じ処理となる。

このような構成により、第３の実施形態では、ハッシュ値を使用してイベントパターンの登録を行うことが出来る。

次に、第３の実施形態のイベントパターンの削除について図２３を参照して説明する。第３の実施形態における図２３の処理は、第２の実施形態の図１７の処理に相当する。

第３の実施形態のイベントパターンの削除動作において、第２の実施形態と異なるところは、図２３のステップ１５０３とステップ１５０６である。他の動作は、第２の実施形態を同じであるため、ステップ１５０３とステップ１５０６について詳細に説明し、第２の実施形態と同等の処理については説明を省略する。

図１７における、第２の実施形態では、一致判定テーブルの属性値を参照してバリューである参照されているインスタンスを求めていたが、第３の実施形態では、属性値のハッシュ値を使用して参照されているインスタンスを求めている（ステップ１５０３）。また、一致判定テーブルから削除するデータも、「属性値とインスタンス」から「属性値のハッシュ値とインスタンス」と変更されている。

第３の実施形態では、このような構成を備えることにより、ハッシュ値を使用したイベントパターンの削除を行うことができる。

最後に、イベントのマッチング動作について、図２４を参照して説明する。第３の実施形態における図２４の処理は、第２の実施形態の図２０の処理に相当する。

第３の実施形態におけるイベントのマッチング動作で、第２の実施形態と異なる動作は、ステップ１６０２となっている。第２の実施形態の図２０のステップ１２０２では、キーとして属性値を使用していたが、第３の実施形態では、属性値のハッシュ値をキーとして使用する。それ以外の動作は、第２の実施形態と同じであるため、説明は省略する。

第３の実施形態では、このような構成を備えることにより、ハッシュ値を使用したイベントのマッチング動作を実現している。

このように構成された第３の実施形態では、一致判定テーブルの一致判定の処理をより高速化する効果を実現することができる。

その理由は、第３の実施形態では、属性値より短い属性値から生成したハッシュ値を一致判定に使用することにより、一致判定テーブルから得られたリストからキー（本実施形態ではハッシュ値）と一致する要素の検索時間を短縮することができるためである。

なお、第３の実施形態では、ハッシュ値の一致判定によりイベントが通知されたかどうかを判定しているため、属性値が一致しない場合でも、イベントがイベント受信装置８３に通知される可能性がある。

これは、異なる属性値でも同じハッシュ値となる場合あるためである。（一般に、ハッシュ値は、基となるデータより個数が少なくなるため、異なるデータでも同じハッシュ値となる場合があるからである。）
例えば、第２の実施形態で説明に使用している、あるサービス事業者の所定の会員が、所定のエリア入った場合に、所定の広告を送る場合について説明すると次のとおりとなる。

ここで、端末ＩＤ１とは異なる端末ＩＤ２が、ＩＤ１と同じハッシュ値をなるとすると、端末ＩＤ２を属性値する端末を所持した会員が、所定の場所に入ってくると、ハッシュ値が同じであるため、広告が送られてしまう。

ただし、一般的に、ハッシュ関数を適切に選択すれば、このようなハッシュ値が重なる状況は、非常にまれとすることができる。

また、例え誤った端末に送られたとしても、ここで送られたのは広告である。広告は、元々、利用者が期待したものだけが送付されるものではなく、送信側が利用者に読まれることを期待して送付するものである。つまり、広告は、希望していない利用者に送付されても、問題となることが無いまたは少ない情報である。利用者は、送られた広告から興味のあるものを取捨選択している。従って、たとえイベントパターン登録者が予定していない利用者に広告が送られたとしても、利用者がその広告に興味がなければ、その広告を無視すればよく、問題となることは少ない。このように、ハッシュ値が重複した場合にイベント処理を行っても問題が無い場合には、第３の実施形態を使用することが出来る。

ただ、イベントパターン登録者が期待していない広告の送信処理が発生するため、その分だけ送信の資源の使用量が、少しは増える可能性がある。そのため、ハッシュ値を使用した場合の、送信資源の増加分と処理の効率化による改善分を、シミュレーションなどで予測して、第２の実施形態のような構成とするか、第３の実施形態のような構成とするかの選択をおこなってもよい。

さらに、一致判定テーブルに、ハッシュ値と属性値の両方を保存するようにし、まず、ハッシュ値で一致判定を行い、一致した場合は属性値で一致判定を行うようにしてもよい。

この場合、不一致判定の高速化と一致判定の正確性の両方を実現する効果を実現することができる。

その理由は、まず、ハッシュ値により一致判定を行うことにより、不一致となる大部分のイベントの不一致を高速に実現できる。さらに、ハッシュ値の判定では一致となるハッシュ値の重複する属性値も、さらに属性値の比較することにより、確実に一致判定が行えるためである。

なお、ここまで説明の便宜上、第３の実施形態について、全ての属性について属性値のハッシュ値をキーとして一致判定テーブルを管理するように説明してきたが、必ずしも全ての属性値をハッシュ値とする必要はない。例えば、属性値が、整数を値であるなど、一致判定の計算時間が短い属性値については、第２の実施形態のように属性値をそのままキーとして一致判定テーブルに登録してもよい。このようにすることにより、ハッシュ値の計算時間を省略することが出来る。

このように、属性値のままでも一致判定の処理が短い属性値は、属性値をそのまま比較し、属性値のままでは一致判定に時間が掛かる属性値はハッシュ値を使用することにより、さらに判定時間を短くする効果を実現することが出来る。

その理由は、属性値のままで一致判定の処理が短い属性値では、ハッシュ値の計算を省略でき、属性値のままでは一致判定の処理が長い属性値では、ハッシュ値を使用することにより判定時間を短くすることができるためである。
（第４の実施形態）
次に、本発明の第４の実施形態について図２５−図２７を参照して説明する。

第２の実施形態及び第３の実施形態において、通知インスタンス３３にイベントパターンＩＤが登録されていた。これに対して、第４の実施形態では、図５の一致判定部８において通知インスタンス３４にイベントパターンが登録されている。そして、第４の実施形態では、一致判定を行ったイベントパターンと通知インスタンス３４で保持されるイベントパターンとの一致判定を行い、一致したイベントパターンのイベントパターンＩＤのリストを作成する。そして、一致判定部８は、作成したイベントパターンＩＤを付与して一致となったイベントをイベント通知としてイベント受信装置８３に出力するという構成となっている。

第４の実施形態の構成は、図６における通知インスタンス３４の構成を除いて、第２の実施形態及び第３の実施形態の構成と同じため、通知インスタンス３４に関連する部分を詳細に説明し、他の構成については説明を省略する。

第４の実施形態における通知インスタンス３４の構成を図２５を参照して説明する。図２５に示す第４の実施形態の通知インスタンス３４は、イベントパターンリストとイベントパターンＩＤリストを含んで構成されている。

続いて、第４の実施形態の通知インスタンス３４を参照した属性登録の動作について図２６を参照して説明する。

第２の実施形態及び第３の実施形態における図１４では、イベントパターンＩＤリストに追加を行っていたが、第４の実施形態では、図２６に示すように、通知インスタンス３４のイベントパターンリストにイベントパターンを追加する。

イベントパターンの削除もイベントパターンリストから削除することにより行う。

次に、第４の実施形態の通知インスタンス３４を参照したときの属性値一致判定について図２７を参照して説明する。

第２の実施形態及び第３の実施形態のイベントのマッチングの動作では、通知インスタンス３３を参照したときに、図２１に示したように、イベントとイベントパターンＩＤリストのペアをイベント受信装置８３に通知していた。

これに対して、第４の実施形態の通知インスタンス３４の処理は、図２７のフローチャートに示すように次のとおりとなっている。

まず、イベントＩＤリストを初期化する（ステップ１８０１）。通知インスタンス３４のイベントパターンリストに登録されているイベントパターンに関して次の処理を繰り返し実行する（ステップ１８０２−ステップ１８０５）。イベントパターンで指定される各属性に対して、発生したイベントの対応するイベント属性値が一致するかどうかの判定を行う（ステップ１８０３）。イベントパターンで指定される全属性が一致した場合は（ステップ１８０４でｙｅｓ）、イベントパターンＩＤリストにイベントパターンのイベントパターンＩＤを追加する（ステップ１８０５）。一方、イベントパターンで指定される全属性の一部でも一致しない場合は（ステップ１８０４でｎｏ）は、イベントパターンＩＤへの追加を行わない。全てのイベントパターンリストのイベントパターンの確認が終了したら、イベントパターンＩＤリストに登録した全てのイベントパターンＩＤとイベントとのペアをイベント受信装置８３に通知する（ステップ１８０６）。

このような構成を備えることにより、第４の実施形態は、第２の実施形態及び第３の実施形態に比べ、確実にイベントパターンにマッチするイベントをイベント受信装置８３に通知することができる効果を実現している。

その理由は、第２の実施形態及び第３の実施形態に比べて、第４の実施形態は、イベントを通知する直前で、イベントパターンとイベントとの一致判定を行っているためである。

さらに、発生したイベントが複数のイベントパターンと一致している場合も、第４の実施形態では、通知することができる効果を実現している。

この理由は、第４の実施形態は、通知インスタンス３４に登録されている全てのイベントパターンとイベントを比較するためである。その結果、複数のイベントパターンの一致したイベントが有ったとしても、全てのイベントパターンとの一致情報をイベント通知に含めることが出来るためである。

（第５の実施形態）
次に、本発明の第５の実施形態について図２８−図３８を参照して説明する。

第５の実施形態における一致判定装置３は、第２の実施形態の一致判定装置２と比べ、属性名の優先順の変化があった場合に、一致判定ツリー２５を変更できるようになっている。さらに、第５の実施形態の一致判定装置３は、第２の実施形態の一致判定装置２とは異なる属性名の優先度を処理することができるようになっている。

第５の実施形態の一致判定装置３の一例のブロック図を図２８に示す。

第５の実施形態の一致判定装置３は、第２の実施形態で説明した一致判定装置２の構成に加え、次のような構成を含んで構成されている。

被指定属性情報保持部４１は、イベントパターン登録部２２がイベントパターン保持部２１にイベントパターンを保存するときに、イベントパターンを受け取り、受け取ったイベントパターンを基に、指定された属性名に対する属性値の数と、各属性値の参照数とを保持する。

ここのおける、属性名に対する属性値の数とは、登録されているイベントパターンに含まれる属性名に対応する属性値の数のことである。また、参照数とは、各属性値がイベントパターンで参照された数のことである。つまり、登録されているイベントパターンに含まれる各属性値の数となる。例えば、図２に示すイベントパターンを全て登録した場合、属性名「端末ID」は「ＩＤ１」と「ＩＤ４」との属性値があるため属性値の数が「２」となり、属性値「ＩＤ１」の参照数は「２」、属性値「ＩＤ４」の参照数は「１」となる。

更新タイミング管理部４２は、属性名情報保持部１３に保存されている属性名優先情報の更新のタイミングを管理する。

属性名優先更新部４３は、更新タイミング管理部４２で指定されたタイミングで属性名情報保持部１３に保存されている属性名優先情報を更新する。

続いて、これらの構成についてより詳細に説明する。

図２９は、被指定属性情報保持部４１の構成を示すブロック図である。図２９は、説明の便宜のため図１に記載されたイベントと図２に記載されたイベントパターンとを使用して説明するが、これに限られるわけではない。被指定属性情報保持部４１は、イベントパターンを受け取ったときに更新する、「イベントパターンで指定された属性値」と「その属性値が登録されている属性値一致インスタンスの数（参照数）」のペアを保持する属性値参照数テーブル（５１Ａ−５１Ｃ）を備えている。さらに、被指定属性情報保持部４１は、イベントパターンで指定されている各属性名に対して指定された属性値の総数を保持する属性値被指定数テーブル５２を含んで構成されている。

図３０を参照して、属性値参照数テーブル（５１Ａ−５１Ｃ）についてより詳細に説明する。属性名「端末ＩＤ」の属性値参照数テーブル５１Ａの一例を図３０（Ａ）に示す。このテーブルの、例えば、属性値「ＩＤ１００」において参照数＝１とは、ＩＤ１００が、１つの判定インスタンス３２の一致判定テーブルに登録されていることを示している。同様に属性値「ＩＤ２０２」の参照数＝２とは、ＩＤ２０２が、２つの判定インスタンス３２の一致判定テーブルに登録されていることを示している。属性名「場所」の属性値参照数テーブル５１Ｂの一例を図３０（Ｂ）に示す。なお、図３０では見やすくするため、場所の後半の記載は省略した。図３０（Ｂ）では、「東京都港区・・・」と「東京都豊島区・・・」が１つずつ参照されていることとなる。属性名「時刻」の属性値参照数テーブル５１Ｃの一例を図３０（Ｃ）に示す。図３０（Ｃ）では、時刻がイベントパターンに１つも入っていないため、図３０（Ｃ）の属性値参照数テーブル５１Ｃは、全て空欄となっている。

属性値被指定数テーブル５２の一例を図３１に示す。図３１の一例では、属性名「端末ＩＤ」は４０００通りの属性値が、属性名「場所」は３０通りの属性値が、イベントパターンとして登録されていることを示している。なお、時刻は０通り、つまり、イベントパターンに登録されていないことを示している。

これら属性値参照数テーブル（５１Ａ−５１Ｃ）及び属性値被指定数テーブル５２は、イベントパターン登録部２２がイベントパターンを登録するときと、イベントパターン削除部２３がイベントパターンを削除するときに、それぞれ更新される。

属性値参照数テーブル（５１Ａ−５１Ｃ）のイベントパターン登録時の処理について図３２を参照して説明する。この処理は、第２の実施形態の図１２の登録処理と概ね同じ動作であるが、インスタンスを生成して、該インスタンスをキー（属性値）に対するバリューとして一致判定テーブルに登録した後に処理（ステップ１９１５）が追加されている。この追加された処理は、被指定属性情報保持部４１が、判定インスタンス３２が参照する属性名と属性値のペア登録する処理（ステップ１９１５）である。このステップ１９１５以外の処理は第２の実施形態と同様のため説明を省略する。

ステップ１９１５の属性名と属性値のペアを登録する処理を図３３を参照してさらに詳しく説明する。

まず、入力された属性名に対応する属性値参照数テーブル（５１Ａ−５１Ｃのいずれか）を選択する（ステップ２００１）。これは、属性名ごとの属性値参照数テーブル（５１Ａから５１Ｃのいずれか）を選択することである。例えば、属性名「端末ID」なら、属性値参照数テーブル５１Aを選択することである。選択した属性値参照数テーブル（５１Ａ−５１Ｃのいずれか）の対応する属性値が有るかどうか確認する（ステップ２００２）。属性値が有った場合は、入力された属性値に対する参照数を１つ増やす（ステップ２００５）。属性値が無かった場合は、入力された属性値を登録し、その参照数として１を登録し（ステップ２００３）、属性値被指定数テーブル５２の属性名に対応する属性値の数を１つ増やす（ステップ２００４）。

次に、イベントパターン削除動作について図面を参照して説明する。

図３４は、第５の実施形態におけるイベントパターンの削除動作のフローチャートである。

図３４の処理は、第２の実施形態の図１７の処理と概ね同じであるが、属性値とインスタンスの関係を削除した後の処理（ステップ２１１０）が異なる。したがってステップ２１１０の動作を説明し、他の処理の説明は省略する。

図３４の動作では、属性値とインスタンスを削除した後、被指定属性情報保持部４１から、判定インスタンス３２が参照する属性名と属性値のペアを削除する（ステップ２１１０）。

この属性名と属性値のペアを属性値参照数テーブル（５１Ａ−５１Ｃ）からの削除動作について、図３５を参照して、さらに説明する。

まず、入力された属性値に対応する属性値参照数テーブル（５１Ａ−５１Ｃのいずれか）を求める（ステップ２２０１）。入力された属性値に対する参照数を−１する（ステップ２２０２）。
参照数が０になった場合（ステップ２２０３のｙｅｓ）は、属性値参照数テーブル（５１Ａ−５１Ｃのいずれか）から属性値と参照数のペアを削除し（ステップ２２０４）、属性値被指定数テーブル５２の該属性名に対応する属性値数を−１する（ステップ２２０５)。参照数が０で無い場合（ステップ２２０３でｎｏ）は、これらの削除を行わず終了する。

更新タイミング管理部４２について、図３６を参照して説明する。図３６は、更新タイミング管理部４２が保持する更新タイミングデータの一例である。図３６（Ａ）に示すデータでは、更新タイミング管理部４２が、毎日午前２時に、属性名優先更新部４３を起動して、属性名優先情報の更新を実行することとなる。また、図３６（Ｂ）に示すデータでは、毎週月曜日と金曜日の深夜０時に更新を行うこととなる。

最後に、更新タイミング管理部４２に指示された、属性名優先更新部４３による属性名優先情報の更新動作について図３７を参照して説明する。

まず、属性名優先更新部４３は、被指定属性情報保持部４１の属性値被指定数テーブル５２と属性値情報保持部１１の属性値情報とを参照して、次の式のより各属性名についての被指定率を求める（ステップ２３０１）。
被指定率＝（属性値被指定数テーブル５２における属性値の数）
÷（属性値情報おける属性値の数）
これは、実際に属性値として取ることが出来る値の数に対して、イベントパターンで指定している属性値の数の比率である。

ここで求めている被指定率は、属性値が取ることができる全体に対する、イベントパターンで指定された範囲の比率となっている。つまり、属性値全体に対する、一致となる範囲の比率である。従って、もし、属性値がランダムに発生すると、被指定率の小さな属性ほど、一致となる可能性が小さくなる。つまり、被指定率が低い属性ほど、不一致判定となる可能性が高いこととなる。

これを、具体的な数値の例を使用して説明すると次のとおりとなる。

属性Ａの属性値の取れる値の数が１００であり、その中でイベントパターンとして５０個登録されているとする。属性Bは、属性値の取れる値の数が１０であり、その中でイベントパターンとして２個登録されている。

被指定率を考慮せず、属性値の数から判断すると、属性値の数が多い属性Ａが属性Ｂより不一致となる可能性が高いこととなる。

しかし、被指定率を計算すると、属性Ａは０．５、属性Bは０．２となる。その結果、ランダムに属性値が発生する場合、属性値Bのほうが、一致する可能性が低いこととなる。従って、属性値の数を基に決めるより、被指定率を基に優先度を決めるほうが、より有効に不一致となる可能性の高い属性名から優先度を設定することが出来ることとなる。

図３７の動作の説明に戻る。

次に、被指定率が小さい属性名順に、属性名を並べた属性名優先情報を生成し（ステップ２３０２）、属性名情報保持部１３に保持される属性名優先情報に上書きする（ステップ２３０３）。

この処理の一例を示すと次のとおりとなる。例えば、属性値情報保持部１１が、図４（Ａ）に示すような属性値の数の情報を持ち、その結果、属性名情報保持部１３が図４（Ｂ）のデータを保持していたとする。ここで、被指定属性情報保持部４１が図３１に示す情報を保持していた場合に更新処理が行われるとする。このとき、各属性名の被指定率は、属性名「端末ＩＤ」が４０００／１億、属性名「場所」が３０／１００万、属性名「時刻」が０／∞＝０となり、次の不等号が成り立つ。

「時刻」の指定率 ＜ 「場所」の指定率 ＜ 「端末ＩＤ」の指定率
この結果、属性名情報保持部１３の情報は、図３８に示す情報に変更となる。

このように、属性名の変更があった場合（ステップ２３０４でｙｅｓ）は、一致判定ツリー２５の更新を行う。

この一致判定ツリー２５の更新処理は、まず、イベントパターン保持部２１のイベントパターンテーブルを図示しない記憶部または記憶装置などに一時的に退避する（ステップ２３０５）。そして、一致判定情報保持部２４とイベントパターン保持部２１と被指定属性情報保持部４１をクリアし、初期状態とする（ステップ２３０６）。

その後、一時的な領域に退避したイベントパターンテーブルの各イベントパターンをイベントパターン登録部２２に入力し、新規に一致判定ツリー２５の生成およびイベントパターン保持部２１など各部への登録動作を行う（ステップ２３０７）。

なお、ステップ２３０４において更新が無い場合は、特に処理を行わず終了する。

以上のような構成により第５の実施形態は、一致判定時に一致判定ツリー２５のルート付近で処理を終える可能性がより高くなる効果を実現している。

その理由は第５の実施形態は、単なる属性値の数ではなく、属性値の被指定率、つまり、属性値が取り得る数に対する、イベントパターンで指定されている属性値の数の比率（被指定率）が小さい属性から、一致判定を行うようにしているためである。

また、第５の実施形態は、パフォーマンスに与える影響を最小限に抑えように一致判定情報（一致判定ツリー２５）の更新タイミングを設定できる効果も実現することができる。

その理由は、第５の実施形態は、更新タイミング管理部４２により更新の時間を設定できるためである。例えば、一致判定情報の更新を夜間など、イベントが発生しにくい時間帯に実施することが出来るためである。

なお、第１の実施形態乃至第５の実施形態は、説明の便宜上、１つの装置として説明してきたが、各構成の全部または一部を別装置として実現したシステムとして構成してもよい。

さらに、各構成の一部または全部をコンピュータのプログラムとして実現することも勿論よい。

１ 一致判定装置
２ 一致判定装置
３ 一致判定装置
６ 属性名優先情報生成部
７ 一致情報生成部
８ 一致判定部
１１ 属性値情報保持部
１２ 属性名優先決定部
１３ 属性名情報保持部
２１ イベントパターン保持部
２２ イベントパターン登録部
２３ イベントパターン削除部
２４ 一致判定情報保持部
２５ 一致判定ツリー
３２ 判定インスタンス
３３ 通知インスタンス
３４ 通知インスタンス
４１ 被指定属性情報保持部
４２ 更新タイミング管理部
４３ 属性名優先更新部
５１Ａ、５１Ｂ、５１Ｃ 属性値参照数テーブル
５２ 属性値被指定数テーブル
８１ イベントパターン管理装置
８２ イベント通知装置
８３ イベント受信装置

Claims (27)

1. イベントの少なくとも一部を構成する属性名と属性値とを含む属性の一致判定の優先度を決めるための属性名優先情報を生成する属性名優先情報生成部と、
   前記属性名優先情報を基にイベントの一致判定に使用する一致判定情報を生成または更新する一致情報生成部と、
   前記一致判定情報と発生したイベントが一致しているかどうかを判定する一致判定部とを備えることを特徴とするイベント一致判定装置。
2. 前記一致情報生成部が、
   イベントの一致判定のための１つまたは複数の属性情報で構成されているイベントパターンを受け取り、前記イベントパターンから前記一致判定情報を生成または更新するイベントパターン登録部と、
   前記イベントパターン登録部が受け取った前記イベントパターンを保持するイベントパターン保持部と、
   前記一致判定情報を保持する一致判定情報保持部と、
   前記イベントパターン登録部により生成または更新された前記一致判定情報から、所定のイベントパターンに対応する情報を削除するイベントパターン削除部とを含むことを特徴とする請求項１に記載のイベント一致判定装置。
3. 前記イベントパターン登録部は、前記優先度の高い属性名を、前記優先度の低い属性名より前で一致判定が行われるように、前記一致判定情報を生成または更新することを特徴とする請求項２に記載のイベント一致判定装置。
4. 前記属性名優先情報生成部が、
   前記優先度を決めるための属性値情報を保持する属性値情報保持部と、
   前記属性値情報を使用して前記属性名の前記優先度の決定する属性名決定部と、
   前記属性値の前記優先度を保存する属性名情報保持部とを含むことを特徴とする請求項１乃至請求項３のいずれかに記載のイベント一致判定装置。
5. 前記属性名決定部は、前記属性値情報において取りうる属性値の数が多い属性名の優先度を属性値の数が少ない属性名より高くすることを特徴とする請求項４に記載のイベント一致判定装置。
6. 前記イベントパターンで参照される属性名の参照状態を示す被指定属性情報を生成し保持する被指定属性情報保持部と、
   前記属性名情報保持部で保持している前記属性名優先情報の更新時期を管理する更新タイミング管理部と、
   前記被指定属性情報保持部の被指定属性情報を受け取り、前記更新タイミング管理部に指定されたタイミングで、前記被指定属性情報を基に前記属性値情報を更新する属性名優先更新部とを備えたことを特徴とする請求項４乃至請求項５のいずれかに記載のイベント一致判定装置。
7. 前記イベントパターン登録部は、前記イベントパターンの前記属性値から生成するハッシュ値を含む前記一致判定情報を生成または更新し、
   前記一致判定部は、前記一致判定情報に含まれる前記ハッシュ値の少なくとも一部を使用して一致判定を行うことを特徴とする請求項２乃至請求項６のいずれかに記載のイベント一致判定装置。
8. 前記イベントパターン登録部は、前記属性値が文字情報を含む場合に前記文字情報の少なくとも一部から生成したハッシュ値と、前記属性値の少なくとも一部とを含む前記一致判定情報を生成または更新することを特徴とする請求項２記載乃至請求項６のいずれかに記載のイベント一致判定装置。
9. 前記イベントパターン登録部は、ルート（根）及びリーフ（葉）を含む木（ツリー）構造の情報を含む前記一致判定情報を生成または更新し、
   前記イベントパターン削除部は、前記ルートから前記リーフに向かって参照を行った後にイベントパターンの削除を行い
   前記一致判定部は、前記ルートから前記リーフに向かって判定を行い、前記リーフに到達すると、登録されている前記イベントパターンと前記イベントとを比較することにより一致判定を行うことを特徴とする請求項２乃至請求項１０のいずれかに記載のイベント一致判定装置。
10. イベントの少なくとも一部を構成する属性名と属性値とを含む属性の一致判定の優先度を決めるための属性名優先情報を生成するステップと、
    前記属性名優先情報を基にイベントの一致判定に使用する一致判定情報を生成または更新するステップと、
    前記一致判定情報と発生したイベントが一致しているかどうかを判定するステップとを備えることを特徴とするイベント一致判定方法。
11. 前記一致判定情報を生成または更新するステップが、
    イベントの一致判定のための１つまたは複数の属性情報で構成されているイベントパターンを受け取り、前記一致判定情報を生成または更新するステップと、
    受け取った前記イベントパターンを保持するステップと、
    前記一致判定情報を保持するステップと、
    前記一致判定情報から、所定のイベントパターンに対応する情報を削除するステップとを含むことを特徴とする請求項１０に記載のイベント一致判定方法。
12. 前記一致情報を生成または更新するステップは、前記優先度の高い属性名を、前記優先度の低い属性名より前で一致判定が行われるように、前記一致判定情報を生成または更新することを特徴とする請求項１１に記載のイベント一致判定方法。
13. 前記属性名優先情報を生成するステップが、
    前記優先度を決めるための属性値情報を保持するステップと、
    前記属性値情報を使用して前記属性名の前記優先度の決定するステップと、
    前記属性値の前記優先度を保存するステップとを含むことを特徴とする請求項１０乃至請求項１２のいずれかに記載のイベント一致判定方法。
14. 前記属性名の前記優先度を決定するステップは、前記属性値情報において属性値の数が多い属性名の優先度を属性値の数が少ない属性名より高くすることを特徴とする請求項１３に記載のイベント一致判定方法。
15. 前記イベントパターンで参照される属性名の参照状態を示す被指定属性情報を生成するステップと、
    保持している前記属性名優先情報の更新時期を管理するステップと、
    前記被指定属性情報を受け取り、前記更新時期に、前記被指定属性情報を基に前記属性値情報を更新するステップとを備えたことを特徴とする請求項１３乃至請求項１４のいずれかに記載のイベント一致判定方法。
16. 前記一致判定情報を生成または更新するステップが、前記イベントパターンの少なくとも一部の前記属性値から生成するハッシュ値を含む前記一致判定情報を生成または更新するステップを含み、
    前記一致判定情報と発生したイベントが一致しているかどうかを判定するステップが、前記一致判定情報に含まれる前記ハッシュ値の少なくとも一部を使用して判定を行うステップを含むことを特徴とする請求項１１乃至請求項１５のいずれかに記載のイベント一致判定方法。
17. 前記一致判定情報を生成または更新するステップが、前記属性値が含む文字情報の少なくとも一部から生成したハッシュ値と、前記属性値の少なくとも一部とを含む前記一致判定情報を生成または更新するステップを含むことを特徴とする請求項１１記載乃至請求項１５のいずれかに記載のイベント一致判定方法。
18. 前記一致判定情報を生成または更新するステップが、ルート（根）及びリーフ（葉）を含む木（ツリー）構造の情報を含む前記一致判定情報を生成または更新し、
    前記所定のイベントパターンに対応する情報を削除するステップが、前記ルートから前記リーフに向かって参照を行った後にイベントパターンの削除を行い、
    前記一致しているかどうかを判定するステップが、前記ルートから前記リーフに向かって判定を行い、前記リーフに到達すると、登録されている前記イベントパターンと前記イベントとを比較することにより一致判定を行うことを特徴とする請求項１１乃至請求項１７のいずれかに記載のイベント一致判定方法。
19. イベントの少なくとも一部を構成する属性名と属性値とを含む属性の一致判定の優先度を決めるための属性名優先情報を生成する処理と、
    前記属性名優先情報を基にイベントの一致判定に使用する一致判定情報を生成または更新する処理と、
    前記一致判定情報と発生したイベントが一致しているかどうかを判定する処理とをコンピュータに実行させることを特徴とするイベント一致判定プログラム。
20. 前記一致判定情報を生成または更新する処理が、
    イベントの一致判定のための１つまたは複数の属性情報で構成されているイベントパターンを受け取り、前記一致判定情報を生成または更新する処理と、
    受け取った前記イベントパターンを保持する処理と、
    前記一致判定情報から、所定のイベントパターンに対応する情報を削除する処理とを含むことを特徴とする請求項１９に記載のイベント一致判定プログラム。
21. 前記一致情報を生成または更新する処理は、前記優先度の高い属性名を、前記優先度の低い属性名より前で一致判定が行われるように、前記一致判定情報を生成または更新することを特徴とする請求項２０に記載のイベント一致判定プログラム。
22. 前記属性名優先情報を生成する処理が、
    前記優先度を決めるための属性値情報を保持する処理と、
    前記属性値情報を使用して前記属性名の前記優先度の決定する処理と、
    前記属性値の前記優先度を保存する処理とを含むことを特徴とする請求項１９乃至請求項２１のいずれかに記載のイベント一致判定プログラム。
23. 前記属性名の前記優先度を決定する処理は、前記属性値情報において属性値の数が多い属性名の優先度を属性値の数が少ない属性名より高くすることを特徴とする請求項２２に記載のイベント一致判定プログラム。
24. 前記イベントパターンで参照される属性名の参照状態を示す被指定属性情報を生成する処理と、
    保持している前記属性名優先情報の更新時期を管理する処理と、
    前記被指定属性情報を受け取り、前記更新時期に、前記被指定属性情報を基に前属性名優先情報を更新する処理とを備えたことを特徴とする請求項２２乃至請求項２３のいずれかに記載のイベント一致判定プログラム。
25. 前記一致判定情報を生成または更新する処理が、前記イベントパターンの少なくとも一部の前記属性値から生成するハッシュ値を含む前記一致判定情報を生成または更新する処理を含み、
    前記一致判定情報と発生したイベントが一致しているかどうかを判定する処理が、前記一致判定情報に含まれる前記ハッシュ値の少なくとも一部を使用して判定を行う処理を含むことを特徴とする請求項２０乃至請求項２４のいずれかに記載のイベント一致判定プログラム。
26. 前記一致判定情報を生成または更新する処理が、前記属性値が含む文字情報の少なくとも一部から生成したハッシュ値と、前記属性値の少なくとも一部とを含む前記一致判定情報を生成または更新する処理を含むことを特徴とする請求項２０記載乃至請求項２４のいずれかに記載のイベント一致判定プログラム。
27. 前記一致判定情報を生成または更新する処理が、ルート（根）及びリーフ（葉）を含む木（ツリー）構造の情報を含む前記一致判定情報を生成または更新し、
    前記所定のイベントパターンに対応する情報を削除する処理が、前記ルートから前記リーフに向かって参照を行った後にイベントパターンの削除を行い、
    前記一致しているかどうかを判定する処理が、前記ルートから前記リーフに向かって判定を行い、前記リーフに到達することにより判定を終了することを特徴とする請求項２０乃至請求項２６のいずれかに記載のイベント一致判定プログラム。

Images