(57)【特許請求の範囲】
【請求項１】
受信するイベント処理対象データを所定のルールに従いイベント処理し、該イベント処理後のデータを順次出力する処理をコンピュータに実行させるデータ処理プログラムであって、
複数の種類の前記イベント処理対象データのうち、第１のイベントの種類の第１の期間毎の前記イベント処理後のデータに関する評価値を取得し、
複数の種類の前記イベント処理対象データにおける、異なる種類の前記第１のイベントと第２のイベントとについて、前記第１の期間よりも長い第２の期間での、前記第１のイベントの種類のイベント処理対象データと、前記第２のイベントの種類のイベント処理対象データとの相関係数値を算出し、
前記評価値より特定される、前記第１のイベントの種類のイベント処理対象データに関する第１のフィルタ条件、および、前記相関係数値に基づき、前記第２のイベントの種類のイベント処理対象データに関する第２のフィルタ条件を設定する、
データ処理プログラム。
【請求項２】
前記第１のフィルタ条件、および、前記第２のフィルタ条件は、前記受信する複数のイベントのデータを前記イベント処理に入力する前にフィルタするフィルタ条件である、
請求項１に記載のデータ処理プログラム。
【請求項３】
フィルタ条件の有効期限を超えた前記第１のフィルタ条件又は第２のフィルタ条件を破棄する、
請求項１又は２に記載のデータ処理プログラム。
【請求項４】
受信するイベント処理対象データを所定のルールに従いイベント処理し、該イベント処理後のデータを順次出力する処理をコンピュータが実行するデータ処理方法であって、
複数の種類の前記イベント処理対象データのうち、第１のイベントの種類の第１の期間毎の前記イベント処理後のデータに関する評価値を取得し、
複数の種類の前記イベント処理対象データにおける、異なる種類の前記第１のイベントと第２のイベントとについて、前記第１の期間よりも長い第２の期間での、前記第１のイベントの種類のイベント処理対象データと、前記第２のイベントの種類のイベント処理対象データとの相関係数値を算出し、
前記評価値より特定される、前記第１のイベントの種類のイベント処理対象データに関する第１のフィルタ条件、および、前記相関係数値に基づき、前記第２のイベントの種類のイベント処理対象データに関する第２のフィルタ条件を設定する、
データ処理方法。
【請求項５】
受信するイベント処理対象データを所定のルールに従いイベント処理し、該イベント処理後のデータを順次出力するデータ処理装置であって、
複数の種類の前記イベント処理対象データのうち、第１のイベントの種類の第１の期間毎の前記イベント処理後のデータに関する評価値を取得する取得部と、
複数の種類の前記イベント処理対象データにおける、異なる種類の前記第１のイベントと第２のイベントとについて、前記第１の期間よりも長い第２の期間での、前記第１のイベントの種類のイベント処理対象データと、前記第２のイベントの種類のイベント処理対象データとの相関係数値を算出する分析部と、
前記評価値より特定される、前記第１のイベントの種類のイベント処理対象データに関する第１のフィルタ条件、および、前記相関係数値に基づき、前記第２のイベントの種類のイベント処理対象データに関する第２のフィルタ条件を設定するフィルタ部と、
を有する、データ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理プログラム、データ処理方法及びデータ処理装置に関する。
【背景技術】
【０００２】
様々な対象から刻々と収集されるビッグデータを処理する技術としてＣＥＰ（複合イベント処理：Complex Event Processing）システムが知られている。ＣＥＰエンジンは、例えば、様々な対象から受信した複数のデータを所定のルールに従い処理（以下、「イベント処理」ともいう。）し、イベント処理した結果を順次出力先へ出力する。
【０００３】
ビッグデータの中には、イベント処理した結果、出力先へ出力すべき有効なデータを抽出できないデータが含まれる。すなわち、ビッグデータの中には、ＣＥＰシステムに必要なデータと不要なデータとがある。出力先へ出力すべき有効なデータを抽出できないデータは、イベント処理への入力が不要なデータである。
【０００４】
これに対して、管理者が手動で必要なデータと不要なデータとを選別すると、管理者の作業が増えて運用コストが高くなる。また、データの選別が、管理者のスキルに依存するため、必要なデータと不要なデータとを適切にフィルタリングできず、システムの負荷が高いままとなる場合がある。
【０００５】
そこで、受信バッファに格納された各イベントタイプのイベントに対するイベント処理を監視し、監視の結果、決定された各イベントタイプの重要度に基づき受信バッファに格納するイベント数を抑制する技術が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１２−１１８９２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、イベント処理に入力すべきデータか否かの判断は、ＣＥＰシステムの運用中に変化し、時間の経過により当初設定したルールの最適性が劣化することがある。例えば、運用当初は、「乗用車イベント」を不要データとしていたが、運用していくと、「乗用車イベント」が必要データに変化していることが一例として挙げられる。
【０００８】
これに対して、引用文献１のように受信イベントを破棄するためのルールが固定されていると、必要データをイベント処理の前に破棄してしまったり、不要データをイベント処理の前に破棄できなかったりすることが生じ得る。必要データを複合イベント処理の前に破棄してしまった場合、イベント処理の負荷を下げることができるものの、イベント処理の結果の有用性及び妥当性が低下する。また、不要データをイベント処理の前に破棄できなかった場合、システムの負荷を下げることができない。
【０００９】
例えば、受信したイベントの全データをイベント処理に入力した場合、イベント処理を行うＣＥＰエンジンの負荷が増加するため、ＣＥＰシステムの能力を増強することが必要になり、運用コストが高くなる。また、近年、急激に増加していくデータ入力量に迅速に適応する程度までＣＥＰシステムの能力を増強することは難しい。
【００１０】
そこで、一側面では、本発明は、受信する複数のイベントを所定のルールに基づきイベント処理する前にフィルタするフィルタ条件を適切に設定することを目的とする。
【課題を解決するための手段】
【００１１】
一つの案では、受信するイベント処理対象データを所定のルールに従いイベント処理し、該イベント処理後のデータを順次出力する処理をコンピュータに実行させるデータ処理プログラムであって、複数の種類の前記イベント処理対象データのうち、第１のイベントの種類の第１の期間毎の前記イベント処理後のデータに関する評価値を取得し、複数の種類の前記イベント処理対象データにおける、異なる種類の前記第１のイベントと第２のイベントとについて、前記第１の期間よりも長い第２の期間での、前記第１のイベントの種類のイベント処理対象データと、前記第２のイベントの種類のイベント処理対象データとの相関係数値を算出し、前記評価値より特定される、前記第１のイベントの種類のイベント処理対象データに関する第１のフィルタ条件、および、前記相関係数値に基づき、前記第２のイベントの種類のイベント処理対象データに関する第２のフィルタ条件を設定する、データ処理プログラムが提供される。
【発明の効果】
【００１２】
一側面によれば、受信する複数のイベントを所定のルールに基づきイベント処理する前にフィルタするフィルタ条件を適切に設定することができる。
【図面の簡単な説明】
【００１３】
【図１】ストリーミング処理の概要を示す図。
【図２】ＣＥＰシステムの一例を示す図。
【図３】ＣＥＰシステムの課題の一つを説明するための図。
【図４】ＣＥＰシステムの課題の一つを説明するための図。
【図５】一実施形態にかかるサーバ装置の機能構成の一例を示す図。
【図６】一実施形態にかかる相関関係の自動分析（フィードバック）の一例を説明するための図。
【図７】一実施形態にかかる時系列データテーブル、設定テーブル、第１相関テーブルの一例を示す図。
【図８】一実施形態にかかるイベント処理の一例を示すフローチャート。
【図９】一実施形態にかかる自動生成処理の一例を示すフローチャート。
【図１０】一実施形態にかかる相関分析処理（評価値）の一例を示すフローチャート。
【図１１】一実施形態にかかるフィルタリングルールの自動生成方法を示す図。
【図１２】一実施形態にかかるフィルタリングルールの有効期限を示す図。
【図１３】一実施形態にかかる相関分析処理（新規イベント）の一例を示すフローチャート。
【図１４】一実施形態にかかる相関関係の自動分析（新規イベント）の一例を説明するための図。
【図１５】一実施形態にかかる時系列データテーブル、第２相関テーブルの一例を示す図。
【図１６】一実施形態にかかるＣＥＰエンジン用ルールの自動生成方法を示す図。
【図１７】一実施形態にかかる時系列データテーブル、第２相関テーブルの一例を示す図。
【図１８】一実施形態にかかるＣＥＰエンジン用ルールの自動生成方法を示す図。
【図１９】一実施形態にかかるサーバ装置のハードウェア構成例を示す図。
【発明を実施するための形態】
【００１４】
以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。
【００１５】
［ストリーミング処理の概要］
本発明の一実施形態に係るＣＥＰシステムを説明する前に、ストリーミング処理の概要について、図１を参照しながら説明する。ＣＥＰシステムにおいてイベント処理を行うサーバ装置９０は、ネットワークを介して道路の交通制御を行う交通制御サーバ２０と通信可能とされている。
【００１６】
サーバ装置９０には、様々な対象から収集された複数のイベントのデータが配信される。図１には、複数のイベント処理対象データの一例として、イベント種類が異なる乗用車イベント（ＣａｒＥｖｅｎｔ）、トラックイベント（ＴｒａｃｋＥｖｅｎｔ）、天気イベント（ＳｅｎｓｏｒＥｖｅｎｔ）のデータが示されている。ただし、複数のイベントは、これに限られず、様々なタイプのイベントが含まれる。例えば、イベントの情報としては、温度センサ、光検出センサ、加速度センサ、圧力センサ等のセンサから取得したセンサ情報や、家電などの機器から収集した情報等であってもよい
【００１７】
サーバ装置９０では、ＣＥＰエンジン９１が動作する。ＣＥＰエンジン９１は、受信する複数のイベントのデータを所定のルールに基づき処理する複合イベント処理（以下では、「イベント処理」ともいう。）を実現するソフトウェアである。複合イベント処理を実現するソフトウェアとしては、例えば、Ｅｓｐｅｒが挙げられる。なお、複合イベント処理は、ＥＳＰ（Event Stream Processing）と呼ぶ場合もあるが、ここでは、ＥＳＰも包含してＣＥＰと総称する。
【００１８】
サーバ装置９０は、複数のイベントに対してイベント処理を行う際の条件を定めたイベント処理ルール９５を記憶する。図１では、サーバ装置９０は、イベント処理ルール９５の一例としてルールＡ、ルールＢを記憶する。
【００１９】
ルールＡは、乗用車イベントの平均速度が５０ｋｍ／時以下、かつ、天気が雨という条件を示す。ルールＢは、トラックイベントの平均速度が５０ｋｍ／時以下、かつ、天気が雨という条件を示す。イベント処理ルール９５は、例えば、ＣＥＰシステムの管理者により手動で設定される。
【００２０】
サーバ装置９０は、配信された複数のデータ２２，２３，２４を受信する。ＣＥＰエンジン９１は、イベント処理ルール９５（ルールＡ、Ｂ）に従い各データをイベント処理する。ＣＥＰエンジン９１は、乗用車イベントがルールＡを満たすとき又はトラックイベントがルールＢを満たすとき、「渋滞発生可能性有」のアクションを決定し、決定した「渋滞発生可能性有」をレコメンドするために交通制御サーバ２０に送信する。
【００２１】
交通制御サーバ２０は、サーバ装置９０から送信されたレコメンドを受信すると、交通状況の監視対象となる道路で渋滞の発生が予測されるものとして、渋滞を緩和させる制御を行う。例えば、交通制御サーバ２０は、監視対象の道路に設けられた信号について渋滞の発生が予測される道路側の青信号の期間を増加させる制御を行い、監視対象の道路を通行可能な乗用車の数を増加させる。また、例えば、交通制御サーバ２０は、監視対象となる道路で渋滞の発生が予測される交通情報を報知して、他の道路への迂回を促し、渋滞を回避するように制御する。
【００２２】
ビッグデータの中には、イベント処理した結果、出力先へ出力すべき有効な情報を抽出できないデータが含まれる。すなわち、ビッグデータの中には、ＣＥＰエンジン９１に必要なデータと不要なデータとがある。
【００２３】
これに対して、図２に示すように、管理者が手動でフィルタリングルール９６（フィルタ条件）を設定した場合について考える。この場合、フィルタエンジン９２は、配信された速度データ２２、２３、天気データ２４及び新規に配信されたバイクイベントの速度データ２５から、フィルタリングルール９６を満たすデータを不要なデータとして取り除き、残ったデータのみをＣＥＰエンジン９１に出力する。しかしながら、管理者が手動で必要なデータと不要なデータとを選別すると、管理者の作業が増えて運用コストが高くなる。また、データの選別が、管理者のスキルに依存するため、必要なデータと不要なデータとを適切にフィルタリングできず、システムの負荷が高いままとなる場合がある。
【００２４】
これに対して、フィルタリングを全く行わず、ＣＥＰエンジン９１が、受信したイベントの全データをイベント処理した場合、ＣＥＰエンジン９１の負荷が増加する。近年、急激に増加していくデータ入力量に迅速に適応してＣＥＰシステムを増強することは難しい。
【００２５】
また、図３に示すように、フィルタエンジン９２のフィルタ条件となる閾値を固定値とした場合について考える。この場合、フィルタエンジン９２は、トラックイベントの速度データ２３の入力数が一時間に６００イベントを超過し、かつ、ＣＥＰルールのマッチ率が７０％を超過した速度データ２３を重要度が低いイベントと判断する。その結果、かかる速度データ２３はフィルタリングされ、ＣＥＰエンジン９１には入力されない。
【００２６】
図３のイベントレートやマッチ率のように、受信イベント（トラックイベントや乗用車イベント）毎の固定的なフィルタや、適合率に対応したフィルタをＣＥＰエンジン９１の前段に設けると、ＣＥＰエンジン９１の負荷を軽減することはできる。一方、上記固定的なフィルタや適合率に対応したフィルタは、時間の経過により当初設定したルール（フィルタ条件）が適正なルールでなくなった場合に対応できず、その結果、ＣＥＰエンジン９１の出力結果の有用性及び妥当性が低下する。特に、ＣＥＰエンジン９１のフィルタ自体が受信イベントの重要度の変化に対応していない場合、フィルタが適切でなくなる。
【００２７】
例えば、トラックイベントのイベントレートは大きく変化する。時間帯や、曜日、あるいは季節によっては、常に６００イベント／時以上のイベントレートとなり、本来、ＣＥＰエンジン９１で処理される必要があるトラックイベント（重要イベント）の多くがフィルタリングされてしまうおそれがある。これにより、ＣＥＰエンジン９１の出力結果の有用性及び妥当性が著しく低下し、渋滞の予兆が検知できずに有用なレコメンドを送信できず、渋滞が発生するという結果が生じる場合がある。
【００２８】
そこで、ＣＥＰエンジン９１の出力結果の有用性及び妥当性を維持するために、フィルタエンジン９２によりＣＥＰエンジン９１に供給するデータを絞りすぎないようにすると、ＣＥＰエンジン９１の負荷を軽減することができない。
【００２９】
図４では、図３と同様に、フィルタエンジン９２は、トラックイベントの速度データ２３の入力数が６００イベント／時を超過し、かつ、ＣＥＰルールのマッチ率が７０％を超過した速度データ２３を重要度が低いイベントと判断する。その結果、かかる速度データ２３はフィルタリングされ、ＣＥＰエンジン９１には入力されない。
【００３０】
例えば、トラックイベントが、渋滞要因と無関係の非重要イベントであった場合、あるいは、運用中に非重要イベントに変化した場合、本来、フィルタリングにより除かれるべきトラックイベントの速度データ２３が除かれずにＣＥＰエンジン９１に入力される。この結果、ＣＥＰエンジン９１の負荷が高くなって、ＣＥＰエンジン９１が処理しきれなくなり、システム運用が停止する。
【００３１】
以上の課題に鑑み、本発明の一実施形態では、受信する複数のイベントを所定のルールに基づきイベント処理する前に取り除くためのフィルタ条件を適切に設定することが可能なＣＥＰシステムを提供する。以下では、サーバ装置１０の機能構成の一例を説明した後、サーバ装置を含むＣＥＰシステムの動作及びＣＥＰシステムが行う各処理について説明する。
【００３２】
［サーバ装置の機能構成］
本発明の一実施形態に係るサーバ装置の機能構成の一例について、図５を参照しながら説明する。サーバ装置１０は、受信する複数のイベントを所定のルールに従いイベント処理し、該イベント処理したイベントを順次出力するデータ処理装置の一例である。
【００３３】
サーバ装置１０は、複合イベント処理を行う物理サーバであり、例えば、データセンサや各企業に設けられたサーバコンピュータである。サーバ装置１０には、様々な対象から収集されたデータが配信される。サーバ装置１０は、様々な対象から受信した複数種類のイベントのデータを、予め設定されたフィルタ条件にてフィルタリングする。次に、サーバ装置１０は、フィルタリングにより取り除かれたデータ以外のデータをイベント処理し、処理の結果に応じたレコメンドを生成し、出力先へ出力する。
【００３４】
サーバ装置１０は、通信制御Ｉ／Ｆ（ｉｎｔｅｒｆａｃｅ）部１１、記憶部１２及び制御部１３を有する。通信制御Ｉ／Ｆ部１１は、少なくとも１つのポートを有し、ネットワークとの間の通信を制御するインタフェースである。通信制御Ｉ／Ｆ部１１は、ネットワークを介して様々な対象から配信されたイベントのデータを受信する。例えば、通信制御Ｉ／Ｆ部１１は、図６に示す乗用車イベントの速度データ２２、トラックイベントの速度データ２３およびセンサイベントの天気データ２４を受信する。また、通信制御Ｉ／Ｆ部１１は、交通制御サーバ２０と各種データを送受信する。例えば、通信制御Ｉ／Ｆ部１１は、ＣＥＰエンジン１５にてイベント処理ルールに合致すると判定された場合にレコメンドするアクションを決定し、レコメンドするデータを交通制御サーバ２０に送信する。
【００３５】
記憶部１２は、ハードディスク、光ディスクなどの記憶装置である。記憶部１２は、各種データを記憶する。例えば、記憶部１２は、制御部１３で実行されるＯＳ（Operating System）や後述するイベント処理、自動生成処理、相関分析処理など各種処理を行うプログラムを記憶する。さらに、記憶部１２は、制御部１３で実行されるプログラムの実行に要する各種データを記憶する。
【００３６】
記憶部１２は、時系列データテーブル１７、設定テーブル１８、第１相関テーブル１９及び第２相関テーブル２１９の各データを記憶する。記憶部１２は、時系列データを生成し、時系列データテーブル１７に記憶する。図７の（ａ）の時系列データテーブル１７は、乗用車イベントの１時間毎の平均速度データ１７１、乗用車イベントの１時間毎の評価値（フィードバック値）１７２、トラックイベントの１時間毎の平均速度データ１７３及びトラックイベントの１時間毎の評価値（フィードバック値）１７４が保存される。たとえば、評価値１７２は、乗用車イベント由来のＣＥＰエンジンからのレコメンドに対して信号や速度制限を制御した結果、実際に渋滞を回避できたかを示す指標である。
【００３７】
設定テーブル１８は、図７の（ｂ）に示すように、評価値の生成期間（第１の期間の一例）１８１、評価値の分析期間（第３の期間の一例）１８２、閾値１８３、有効期限１８４が保存される。評価値の分析期間は、評価値の生成期間よりも長い期間に設定される。評価値の分析期間を評価値の生成期間よりも長くすることで、分析対象となる評価値のデータ数を所定以上にし、これにより分析結果の精度を高めることができる。
【００３８】
第１相関テーブル１９は、図７の（ｃ）に示すように、フィードバックデータ（評価値）１９１、イベントデータ１９２及び相関係数値１９３を有する。相関係数値１９３は、フィードバックデータ１９１とイベントデータ１９２との相関関係を示す値である。
【００３９】
例えば、イベントが乗用車イベントの場合、図７（ａ）に示す時系列データテーブル１７に記憶された乗用車イベントの１時間毎の評価値（フィードバック値）１７２の一日分のデータと、乗用車イベントの１時間毎の平均速度データ１７１の一日分のデータとから、フィードバックデータ１９１とイベントデータ１９２との相関関係を示す相関係数値１９３が算出される。
【００４０】
相関係数値１９３の算出方法の一例としては、例えば、以下の式（１）が挙げられる。２組の数値（ｘ、ｙ）からなるデータ列が与えられたとき、その相関係数値は、式（１）により求められる。相関係数値１９３の算出では、ｘに乗用車イベントの１時間毎の平均速度が代入され、ｙに乗用車イベントの１時間毎の評価値が代入される。また、相関係数値１９３の算出では、２組の数値（ｘ、ｙ）からなるデータ列は、乗用車イベントの１時間毎の平均速度と乗用車イベントの１時間毎の評価値との組である（ｘ、ｙ）の一日分のデータ列を示す。トラックイベントについても同様である。
【００４１】
【数１】
0006668657.tif 000002
【００４２】
ただし、相関関係の算出方法は、これに限らず、公知の相関関係の算出方法のいずれも用いることができる。
【００４３】
図５に戻り、制御部１３は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１３は、受信部４、分析部５、フィルタ部６及びイベント処理部７を有する。
【００４４】
受信部４は、ネットワークを介して複数のイベントを含む各種データを受信する。受信部４は、サーバ装置１０から送信されるレコメンドに対し交通制御サーバ２０が評価した評価値を受信する。受信部４は、後述されるイベント処理ルールに基づきイベント処理したデータの、第１の期間毎の評価値を取得する取得部の一例である。第１の期間には、１時間等の所定時間が設定される。第１の期間は、管理者によって予め設定される。
【００４５】
分析部５は、複数のイベント処理対象データにおける、前記第１の期間よりも長い第３の期間での、第１のイベント種類のイベント処理対象データの評価値と、イベント種類毎のイベント処理対象データとの相関係数値１９３をイベント種類毎に算出する。算出された相関係数値１９３は、図７（ｃ）の第１相関テーブル１９に保存される。また、分析部５は、複数のイベント処理対象データにおける、前記第１の期間よりも長い第２の期間での、第１のイベント種類のイベント処理対象データと、第１のイベント種類と異なる第２のイベント種類のイベント処理対象データとの相関係数値２９３を算出する。算出された相関係数値は、図１５（ｂ）の第２相関テーブル２１９に保存される。第１のイベント種類のイベント処理対象データ及び第２のイベント種類のイベント処理対象データの一例としては、例えば乗用車イベントの速度データ及びトラックイベントの速度データが挙げられる。
【００４６】
分析部５は、相関係数値１９３又は相関係数値２９３に基づき、受信する複数のイベントの各データをフィルタするフィルタリングルール（フィルタ条件）を生成する。
【００４７】
フィルタ部６は、ＣＥＰエンジン１５によりイベント処理する前の段階で、フィルタリングルールに基づき、複数のイベントの各データをフィルタリングする。フィルタ部６は、フィルタ条件の有効期限を超えたフィルタ条件を破棄する。フィルタ部６は、評価値より特定される、第１のイベント種類のイベント処理対象データに対する第１のフィルタ条件、および、前記相関係数値に基づき、前記第２のイベント種類のイベント処理対象データに関する第２のフィルタ条件を設定する。
【００４８】
イベント処理部７は、フィルタ部６から出力されたデータ（フィルタリングされなかったイベントデータ）にイベント処理（複合イベント処理：ＣＥＰ）を実行する。イベント処理部７は、入力されたデータがイベント処理ルールに合致した場合、交通制御サーバ２０に「渋滞発生可能性有」のレコメンドを行う。「渋滞発生可能性有」のレコメンドは、サーバ装置１０が入力イベントをイベント処理した結果、出力先に出力されるレコメンドの一例である。
【００４９】
なお、次で説明される図６のＣＥＰシステムにおいて、分析エンジン１６は、第１の期間毎の評価値と、受信する複数のイベントの各データとの第１の期間よりも長い第３の期間における相関に基づき、受信する複数のイベント毎の複数の相関係数値を算出する分析部５に対応する。また、分析エンジン１６は、イベント処理したデータの、第１の期間毎の評価値を受信する受信部４に対応する。
【００５０】
また、フィルタエンジン１４は、フィルタ条件に基づき入力データをフィルタリングするフィルタ部６に対応する。
【００５１】
また、ＣＥＰエンジン３０は、フィルタ部６から出力されたデータ（フィルタリングされなかったイベントデータ）をイベント処理ルールに基づき処理するイベント処理部７に対応する。
【００５２】
［サーバ装置を含むＣＥＰシステムの動作の概要］
次に、サーバ装置を含むＣＥＰシステムの動作の概要について、図６及び図７を参照しながら説明する。以下では、ビッグデータの一例として乗用車イベント、トラックイベント及び天気予報イベントを挙げて説明する。例えば、サーバ装置１０には、乗用車イベントの一例として、交通状況の監視対象となる道路の所定の位置に設けられた速度センサにより検出された乗用車の速度を示す速度データ２２が配信される。また、サーバ装置１０には、トラックイベントの一例として、同様に交通状況の監視対象となる道路の所定の位置に設けられた速度センサにより検出されたトラックの速度を示す速度データ２３が配信される。また、サーバ装置１０には、天気予報イベントの一例として、天気予報のサービスを行う業者のサーバから監視対象の道路を含む地域の予測される天気を示す天気データ２４が配信される。
【００５３】
（イベント処理）
まず、分析エンジン１６は、乗用車イベントの速度データ２２、トラックイベントの速度データ２３、及び天気予報イベントの天気データ２４を含む複数の入力イベントを受信する。分析エンジン１６は、入力イベントから時系列データを生成し、時系列データテーブル１７に追加する。これにより、図７の（ａ）に示すように、入力イベントの種類に応じて時系列データが収集され、入力イベントの種類に応じた平均速度が算出される。
【００５４】
図６に戻り、速度データ２２，２３および天気データ２４は、ＸＭＬ（Extensible Markup Language）形式のデータ構造を有する。速度データ２２は、タグとして、データ名が「ｅｖｅｎｔＴｙｐｅＩｄ」、「ｓｐｅｅｄ」の各項目を有する。「ｅｖｅｎｔＴｙｐｅＩｄ」は、発生したイベントの種類を埋め込む際に用いるタグである。速度データ２２は、「ｅｖｅｎｔＴｙｐｅＩｄ」のタグに、発生したイベントとして、乗用車が通過したことを示す「ＣａｒＥｖｅｎｔ」が埋め込まれる。「ｓｐｅｅｄ」は、検出された速度を埋め込む際に用いるタグである。速度データ２２は、「ｓｐｅｅｄ」のタグに、検出された乗用車の速度として時速（［Ｋｍ／ｈ］）を示す値が埋め込まれる。速度データ２２では、乗用車の速度が４０［Ｋｍ／ｈ］であることを示す。
【００５５】
速度データ２３は、タグとして、データ名が「ｅｖｅｎｔＴｙｐｅＩｄ」、「ｓｐｅｅｄ」の各項目を有する。速度データ２３は、「ｅｖｅｎｔＴｙｐｅＩｄ」のタグに、発生したイベントとして、トラックが通過したことを示す「ＴｒａｃｋＥｖｅｎｔ」が埋め込まれる。「ｓｐｅｅｄ」は、検出された速度を埋め込む際に用いるタグである。速度データ２３は、「ｓｐｅｅｄ」のタグに、検出されたトラックの速度として時速（［Ｋｍ／ｈ］）を示す値が埋め込まれる。速度データ２３では、トラックの速度が４０［Ｋｍ／ｈ］であることを示す。
【００５６】
また、天気データ２４は、タグとして、データ名が「ｅｖｅｎｔＴｙｐｅＩｄ」、「Ｒａｉｎ」の各項目を有する。「ｅｖｅｎｔＴｙｐｅＩｄ」は、上述のように、発生したイベントの種類を埋め込む際に用いるタグである。天気データ２４は、「ｅｖｅｎｔＴｙｐｅＩｄ」のタグに、発生したイベントとして「ＳｅｎｓｏｒＥｖｅｎｔ」が埋め込まれる。「Ｒａｉｎ」は、雨が予測される際に用いるタグである。天気データ２４は、雨が予測された場合、「Ｒａｉｎ」のタグに、「ｔｒｕｅ」が埋め込まれる。ここでは、天気データ２４は、雨が予測されることを示す。
【００５７】
分析エンジン１６は、入力イベントをフィルタエンジン１４に出力する。フィルタエンジン１４は、入力イベントを入力し、フィルタリングルール１４ａに基づき入力イベントのフィルタリングを行う。フィルタエンジン１４は、フィルタリングされなかったデータをＣＥＰエンジン１５に出力する。なお、この時点では、図６のフィルタリングルール１４ａ（フィルタ条件）は自動生成されていないものとする。フィルタリングルール１４ａが自動生成された後のフィルタエンジン１４によるフィルタリング処理については、後述される。
【００５８】
ＣＥＰエンジン１５は、乗用車イベント、トラックイベント、天気予報イベントの各データを入力し、イベント処理ルール１５ａに従いイベント処理する。イベント処理ルール１５ａは、イベント毎に設定される。例えば、ＣＥＰエンジン１５は、乗用車イベント用のイベント処理ルール１５ａに基づき、乗用車イベントの速度データ２２をイベント処理する。同様に、ＣＥＰエンジン１５は、トラックイベント用のイベント処理ルール１５ａに基づき、トラックイベントの速度データ２２をイベント処理する。同様に、ＣＥＰエンジン１５は、天気予報イベント用のイベント処理ルール１５ａに基づき、天気予報イベントの速度データ２２をイベント処理する。このようにしてＣＥＰエンジン１５は、イベントの種類毎にイベントを処理することで、イベントの種類毎に評価を行うことができる。
【００５９】
例えば、乗用車イベント用のイベント処理ルール１５ａが、乗用車イベントの平均速度が５０ｋｍ／時以下、かつ、天気が雨という条件であるとする。ＣＥＰエンジン１５は、このルールを満たすとき、「渋滞発生可能性有」の情報を交通制御サーバ２０に送信する（レコメンド）。
【００６０】
なお、ＣＥＰシステムは、評価対象のイベントと非評価対象のイベントとを予め設定することができる。ＣＥＰエンジン１５は、入力されたイベントのうちの非評価対象のイベントはイベント処理の対象外とする。具体的には、乗用車イベントは評価対象とし、天気予報イベントは非評価対象とするというシステム運用が可能である。なお、本実施形態では、乗用車イベント、トラックイベント及び天気予報イベントはいずれも評価対象イベントとする。
【００６１】
交通制御サーバ２０は、サーバ装置１０から「渋滞発生可能性有」のレコメンドを受けた場合、交通状況の監視対象となる道路で渋滞の発生が予測されるものとして、渋滞を緩和させる制御を行う。例えば、交通制御サーバ２０は、監視対象の道路に設けられた信号について渋滞の発生が予測される道路側の青信号の期間を増加させる制御や速度制限の制御を行い、監視対象の道路を通行可能な乗用車の数を増加させる。また、例えば、交通制御サーバ２０は、監視対象となる道路で渋滞の発生が予測される交通情報を報知して、他の道路への迂回を促し、渋滞を回避するように制御する。
【００６２】
以上、ＣＥＰシステムにおいて、サーバ装置１０が入力イベントを入力し、フィルタ処理及びイベント処理を実行し、処理結果に基づき交通制御サーバ２０へレコメンドを送信する処理について説明した。
【００６３】
次に、サーバ装置１０が交通制御サーバ２０から「レコメンド」に対する評価のフィードバックを受け、フィードバックされた評価値と入力イベントとの相関関係を自動分析し、分析結果からフィルタリングルール１４ａを自動生成する処理について説明する。フィルタリングルール１４ａを自動生成することで、ＣＥＰエンジン１５においてイベント処理が必要なデータと不要なデータとを自動選別することができ、ＣＥＰエンジン１５の処理の負荷を軽減できる。
【００６４】
（フィードバック）
（１）各イベント用のイベント処理ルールの有用性をフィードバック
交通制御サーバ２０は、上記の渋滞を回避するための制御により、実際に渋滞が回避できたかを評価し、その評価値をサーバ装置１０にフィードバックする。例えば、図６に示す交通制御サーバ２０が送信する評価値データ２１は、イベント処理ルール（乗用車用、トラック用・・・）毎に生成される。本実施形態では、評価期間（第１の期間）は、図７の（ｂ）の生成期間１８１に予め設定された１時間に設定されるが、評価期間はこれに限らず一定の時間が設定されればよい。例えば、本実施形態では、交通制御サーバ２０は、乗用車イベントに対する１時間毎の評価値とトラックイベントに対する１時間毎の評価値とを算出する。
【００６５】
評価値データ２１は、タグとして、データ名が「ｅｖｅｎｔＴｙｐｅＩｄ」、「ｓｕｂｊｅｃｔ」、「ａｓｓｅｓｓｍｅｎｔ」の各項目を有する。「ｅｖｅｎｔＴｙｐｅＩｄ」は、発生したイベントの種類を埋め込む際に用いるタグである。評価値データ２１では、「ｅｖｅｎｔＴｙｐｅＩｄ」のタグに、１時間毎の評価値をサーバ装置１０に返す「フィードバックイベント」が埋め込まれる。評価値は、サーバ装置１０からのレコメンドに対して信号や速度制限を制御した結果、実際に渋滞を回避できたかを示す。「ｓｕｂｊｅｃｔ」は、「フィードバックイベント」を発生させた元のイベントを示す。ここでは、「ｓｕｂｊｅｃｔ」には、「ＣａｒＥｖｅｎｔ」が埋め込まれる。「ａｓｓｅｓｓｍｅｎｔ」には、各イベントに対する評価値（フィードバック値）が埋め込まれる。ここでは、乗用車イベントに対してフィードバックされた評価値は「１０」であることを示す。本実施形態では、評価値は１〜１０の１０段階で示される。評価値が１０のとき、最も相関が高く、最もレコメンドが有用であったことを示す。評価値が１のとき、最も相関が低く、最もレコメンドが有用でなかったことを示す。
【００６６】
（２）時系列データを生成
サーバ装置１０の分析エンジン１６は、交通制御サーバ２０からフィードバックされた評価結果である評価値を受信する。分析エンジン１６は、評価値から時系列データを生成し、時系列データテーブル１７に追加する。これにより、イベント毎にフィードバックされた評価値の時系列データが収集される。図７の（ａ）では、乗用車イベントの１時間毎の評価値１７２とトラックイベントの１時間毎の評価値１７４とが保存されている。
【００６７】
（３）相関関係を自動分析
図６に戻り、分析エンジン１６は、時系列データテーブル１７に基づき、収集された評価値と入力イベントとの相関関係を自動分析し、分析結果からフィルタリングルール１４ａを自動生成する。分析エンジン１６は、時系列データテーブル１７に基づき、１時間毎に保存された各種イベント毎の評価値から、例えば１日の分析期間（第３の期間）毎に各種イベントの評価値を算出する。なお、第３の期間は、前述した第１の期間よりも長い期間であれば、必ずしも１日である必要はない。
【００６８】
（４）フィルタリングルール自動生成
分析エンジン１６は、算出された相関係数値１９３と図７の（ｂ）に示す予め設定された閾値１８３の「±０．０５」とを比較し、相関係数値１９３が閾値１８３の範囲内であると判定した場合、フィルタリングルール１４ａを自動生成する。例えば、図７の（ｃ）に示す例では、相関係数値１９３は「０．０１」であり、閾値１８３は「±０．０５」である。よって、分析エンジン１６は、相関係数値１９３が閾値１８３の範囲内であると判定し、乗用車イベントの速度データが交通制御による渋滞の回避や緩和に不要なデータであると判断する。その結果、分析エンジン１６は、乗用車イベントを取り除くフィルタ条件を規定したフィルタリングルール１４ａを自動生成する。これにより、ＣＥＰエンジン１５におけるイベント処理が必要なデータと不要なデータとを自動選別することができる。この結果、不要なデータを取り除いた後のデータがＣＥＰエンジン１５に入力されることで、ＣＥＰエンジン１５の処理の負荷を軽減できる。
【００６９】
具体的には、乗用車イベントの速度データが交通制御による渋滞の回避や緩和に不要なデータであると判断した場合、一例として図６に示すフィルタリングルール１４ａが分析エンジン１６により自動生成される。図６のフィルタリングルール１４ａでは、乗用車イベント（ＣａｒＥｖｅｎｔ）を対象イベントとし、乗用車イベントの速度データが０より小さい値を示すとき、乗用車イベントを出力することを示す。スピードが０より小さい乗用車イベントは存在しない。よって、図６のフィルタリングルール１４ａでは、すべての乗用車イベントがフィルタリングされ、ＣＥＰエンジン１５には入力されなくなる。
【００７０】
フィルタリングルール１４ａには、有効期限を設定することができる。例えば、図７の（ｂ）に示す設定テーブル１８の有効期限１８４に「１年」が予め設定されている場合、フィルタリングルール１４ａが自動生成されたときから１年を経過したとき、分析エンジン１６は、フィルタリングルール１４ａを自動的に破棄する。
【００７１】
以上により、各種イベントのデータの重要性が変化した場合でも、変化に応じてフィルタリングルール１４ａを自動生成したり自動削除することができる。これにより、ＣＥＰエンジン１５によるイベント処理の前段階にて各種イベントのデータから不要なデータをフィルタするフィルタの条件を適切に設定することができる。
【００７２】
以上、フィルタリングルール１４ａの自動生成について説明した。本実施形態によれば、分析エンジン１６がフィルタリングルール１４ａを自動生成することで、ＣＥＰエンジン１５によりイベント処理が必要なデータと不要なデータとを自動選別できる。この結果、ＣＥＰエンジン１５に入力されるデータ量を減らし、ＣＥＰエンジン１５の処理の負荷を軽減できる。
【００７３】
また、本実施形態では、フィルタ条件の有効期限を超えたフィルタリングルール１４ａを自動的に破棄することができる。特に、交通制御サーバ２０の評価の信頼度が高い場合には、フィルタリングルール１４ａの有効期限を長く設定し、交通制御サーバ２０の評価結果が流動的で評価の信頼度が低い場合には、その有効期限を短く設定することが好ましい。これにより、時間の経過により当初設定したルールの最適性が劣化した場合においても、必要データをイベント処理の前に破棄したり、不要データをイベント処理の前に破棄しなかったことによってイベント処理の結果の有用性及び妥当性が低下することを回避できる。
【００７４】
（イベント発生契機）
イベント発生契機は、監視対象道路に車両が入ったときでもよいし、各車両で一定量の速度変化が発生したときでもよい。イベント発生契機は、センサ機器等のイベント発生元から出力される検出値の発生タイミングに依存する。なお、本実施形態にかかる各車両の入力イベントは、１００万ＴＰＳ（Transactions Per Second）等の大量イベントを想定しているが、イベント数はこれに限らない。
【００７５】
（時系列分析契機）
時系列データの生成期間１８１及び分析期間１８２は、システムの運用状況に依存する。本実施形態では、生成期間１８１を１時間、分析期間１８２を１日に設定し、１時間毎に平均速度が計算され、１日毎に相関分析が行われるが、必ずしもこの単位である必要はない。例えば、各時間帯の１週間毎の平均を時系列データとして、１週間毎に相関分析を行うこともできる。生成期間１８１は、ＳＥ等の管理者が事前に設定テーブル１８に設定することができる。ただし、生成期間は、ＣＥＰシステム全体としてフィードバックの間隔と同じにしておくことが好ましい。
【００７６】
［イベント処理］
次に、本実施形態に係るサーバ装置１０が行うイベント処理の流れを説明する。
（分析エンジンの処理）
図８のイベント処理が開始されると、まず、ステップＳ１０において、分析エンジン１６（受信部４）は、入力イベントを入力する。次に、ステップＳ１２において、分析エンジン１６（分析部５）は、入力イベントから時系列データを生成し、時系列データテーブル１７に追加する。
（フィルタエンジンの処理）
次に、ステップＳ１４において、フィルタエンジン１４（フィルタ部６）は、設定テーブル１８の有効期限１８４に基づき、フィルタリングルール１４ａが有効期限１８４を超過したかを判定する。フィルタエンジン１４は、フィルタリングルール１４ａが有効期限１８４を超過したと判定した場合、ステップＳ１６において、そのフィルタリングルール１４ａを破棄し、ステップＳ１８に進む。ステップＳ１４において、フィルタエンジン１４は、フィルタリングルール１４ａが有効期限１８４を超過していないと判定した場合、ステップＳ１８に進む。
【００７７】
次に、ステップＳ１８において、フィルタエンジン１４は、入力イベントとフィルタリングルール１４ａとが一致するかを判定する。フィルタエンジン１４は、入力イベントとフィルタリングルール１４ａとが一致すると判定した場合、ステップＳ２０において、入力イベントを破棄し、ステップＳ２２に進む。フィルタエンジン１４は、入力イベントとフィルタリングルール１４ａとが一致しないと判定した場合、ステップＳ２２に進む。図６のフィルタリングルール１４ａの例では、乗用車イベントがフィルタリングされる。
（ＣＥＰエンジンの処理）
次に、ステップＳ２２において、ＣＥＰエンジン１５（イベント処理部７）は、入力イベントとイベント処理ルール１５ａとが一致するかを判定する。ＣＥＰエンジン１５は、入力イベントとイベント処理ルール１５ａとが一致すると判定した場合、ステップＳ２４において、交通制御サーバ２０にレコメンドを送信し、本処理を終了する。ＣＥＰエンジン１５は、入力イベントとイベント処理ルール１５ａとが一致しないと判定した場合、交通制御サーバ２０にレコメンドを送信することなく、本処理を終了する。
【００７８】
［自動生成処理］
次に、本実施形態に係るサーバ装置１０が行う自動生成処理の流れを、図９を参照しながら説明する。図９のサーバ装置１０が行う自動生成処理は、図８のサーバ装置１０が行うイベント処理とは独立して実行される。図８のイベント処理は、イベントが発生する度に実行される。これに対して、図９の自動生成処理では、交通制御サーバ２０から送信された評価値が所定時間蓄積された状態で、相関分析処理（Ｓ３８，Ｓ４０）においてフィルタリングルールの自動生成が実行される。
（分析エンジンの処理）
自動生成処理が開始されると、ステップＳ３０において、分析エンジン１６は、レコメンド送信先である交通制御サーバ２０からフィードバック（評価値の受信）があったかを判定する。分析エンジン１６は、交通制御サーバ２０からフィードバックがあったと判定した場合、ステップＳ３２において、フィードバックされた評価値から時系列データを生成し、時系列データテーブル１７に保存し、ステップＳ３４に進む。ステップＳ３０において、分析エンジン１６は、交通制御サーバ２０からフィードバックがなかったと判定した場合、ステップＳ３４に進む。
【００７９】
次に、ステップＳ３４において、分析エンジン１６は、時系列データテーブル１７に保存した時系列データが一定時間（第３の期間）を超過したかを判定する。分析エンジン１６は、時系列データが一定時間として例えば一日を超過していないと判定した場合、処理を終了する。分析エンジン１６は、時系列データが一定時間を超過したと判定した場合、ステップＳ３６に進み、入力イベントが新規イベントであるかを判定する。分析エンジン１６は、入力イベントが新規イベントでないと判定した場合、ステップＳ３８の相関分析処理（評価値）に進む。一方、分析エンジン１６は、入力イベントが新規イベントであると判定した場合、ステップＳ４０の相関分析処理（新規イベント）に進む。ステップＳ４０の相関分析処理（新規イベント）が最初に実行される前にステップＳ３８の相関分析処理（評価値）が少なくとも一回は実行される。
【００８０】
図１０には、ステップＳ３８にて呼び出されるの相関分析処理（評価値）のフローチャートが示されている。図１３には、ステップＳ４０にて呼び出されるの相関分析処理（新規イベント）のフローチャートが示されている。以下では、先に図１０の相関分析処理（評価値）について説明した後、図１３の相関分析処理（新規イベント）について説明する。
【００８１】
［相関分析処理（評価値）］
図１０の相関分析処理（評価値）が開始されると、ステップＳ４８において、分析エンジン１６は、上記の式（１）に基づき、交通制御サーバ２０からフィードバックされた評価値と入力イベントとの相関係数値を算出する。次に、ステップＳ５０において、分析エンジン１６は、算出された相関係数値１９３が閾値１８３の範囲を超えているかを判定する。分析エンジン１６は、相関係数値１９３が閾値１８３の範囲を超えていると判定した場合、評価値と入力イベントとの相関関係は高いため、ＣＥＰエンジン１５によるイベント処理に必要なデータであると判断し、フィルタリングルール１４ａを生成せずに本処理を終了する。
【００８２】
ステップＳ５０において、分析エンジン１６は、相関係数値１９３が閾値１８３の範囲内であると判定した場合、ステップＳ５２において、評価値と入力イベントとの相関関係は低いと判断し、フィルタリングルール１４ａを自動生成し、本処理を終了する。これにより、ＣＥＰエンジン１５に入力されるイベントから、不要なイベントのデータを取り除くことができる。この結果、ＣＥＰエンジン１５は、交通渋滞の回避に有益なイベントのデータをイベント処理することにより、有益なレコメンドを交通制御サーバ２０に送信できるとともに、ＣＥＰエンジン１５の処理の負荷を軽減できる。
【００８３】
（フィルタリングルールの自動生成の例）
フィルタリングルールの自動生成の例を、図１１及び図１２に基づき説明する。図１１は、一実施形態にかかるフィルタリングルールの自動生成方法を示す。例えば、管理者は、予め設定テーブル１８にイベントの種類毎の「全フィルタ条件」を設定しておく。図１１に示す例では、設定テーブル１８にイベント名１８５ａと全フィルタ条件１８５ｂとが設定されている。
【００８４】
フィルタリングルールの自動生成では、分析エンジン１６は、設定テーブル１８からひな形を設定し、フィルタリングする対象イベントのイベント名およびフィルタ条件を埋め込む。図１１では、分析エンジン１６は、ひな形に乗用車イベント及びフィルタ条件を埋め込む。これにより、フィルタリングルールを自動生成することができ、管理者が手動でフィルタリングルールを生成する手間を省くことができる。
【００８５】
（フィルタリングルール毎に有効期限を設定）
また、本実施形態では、前述したように自動生成したフィルタリングルール１４ａに「有効期限」を設定することができる。例えば、図１２に示すように、フィルタリングルール１４ａのフィルタリングの対象は、乗用車イベントＡである。フィルタリングルール１４ｂのフィルタリングの対象は、乗用車イベントＢである。
【００８６】
図１２の（１）、（３）、（５）に示すように、フィルタリングルール１４ａは、交通制御サーバ２０ａからのフィードバックされた評価値と入力イベントの相関関係に基づき、乗用車イベントを排除するために自動生成されている。
【００８７】
図１２の（２）、（４）、（６）に示すように、フィルタリングルール１４ｂは、交通制御サーバ２０ｂからのフィードバックされた評価値と入力イベントの相関関係に基づき、乗用車イベントを排除するために自動生成されている。
【００８８】
交通制御サーバ２０ａは、昔からある道路を制御しており、フィードバックの評価値の信頼度が高い。一方、交通制御サーバ２０ｂは、最近できた道路を制御しており、フィードバックの評価値の信頼度が低い。よって、フィルタリングルール１４ａの有効期限は、例えば１年という長期間に設定されるのに対して、フィルタリングルール１４ｂの有効期限は、例えば１週間という短期間に設定される。このようにして、本実施形態では、交通サーバ毎にフィルタリングルール１４ａ、１４ｂの有効期限が設定できる。これにより、交通サーバによる評価値が流動的で信頼性が低い場合でも、ＣＥＰシステムの運用を継続しながら適切なデータ選別が可能となる。
【００８９】
［相関分析処理（新規イベント）］
次に、既にイベント処理されている種類のイベント（以下、「既存イベント」ともいう。）と異なる種類のイベント（以下、「新規イベント」ともいう。）が入力された場合の新規イベントと既存イベントとの相関分析処理について、図１３及び図１４を参照しながら説明する。図１３は、新規イベントと既存イベントとの相関分析処理のフローチャートを示す。図１４は、一実施形態にかかる相関関係の自動分析の一例として、既存イベントの一例である乗用車イベントの速度データ２２、トラックイベントの速度データ２３およびセンサイベントの天気データ２４とは異なる種類の新規イベントの一例であるバイクイベントの速度データ２５が入力された場合を示す。
【００９０】
図１３の相関分析処理（新規イベント）が開始されると、ステップＳ５８において、分析エンジン１６は、上記の式（１）に基づき、既存イベントと新規イベントとの相関係数値２９３を算出し、第２相関テーブル２１９に保存する。次に、ステップＳ６０において、分析エンジン１６は、第２相関テーブル２１９に基づき、相関係数値２９３が予め設定された閾値２８３の範囲を超えているかを判定する。閾値２８３は、閾値１８３と同じ値に設定されてもよいし、異なる値に設定されてもよい。
【００９１】
分析エンジン１６は、既存イベントの種類毎に既存イベントと新規イベントとの相関係数値を算出し、既存イベントと新規イベントとの相関関係の判定を行う。これにより、例えば、乗用車イベントとトラックイベントとのそれぞれについて、新規イベントとの相関関係の判定が行われる。
【００９２】
分析エンジン１６は、図１５の（ａ）に示す時系列データテーブル１７に基づき、図１５の（ｂ）に示す新規イベントデータ１９４と既存イベントデータ１９５との相関係数値２９３を算出する。
【００９３】
例えば、新規イベントがバイクイベントの場合、図１５（ａ）に示す時系列データテーブル１７に記憶された乗用車イベントの１時間毎の平均速度データ１７１の一日分のデータと、バイクイベントの１時間毎の平均速度１７５の一日分のデータから、バイクイベントデータ１９４と乗用車イベントデータ１９５との相関係数値２９３が算出される。
【００９４】
相関係数値２９３の算出方法の一例としては、例えば、上記の式（１）により算出できる。つまり、２組の数値（ｘ、ｙ）からなるデータ列が与えられたとき、その相関係数値は、式（１）により求められる。ここで、ｘは各種類のイベントの１時間毎の平均速度、ｙは１時間毎のバイクイベントの平均速度である。よって、数値（ｘ、ｙ）からなるデータ列は、（各種類のイベントの１時間毎の平均速度、バイクイベントの１時間毎の平均速度）の一日分のデータ列を示す。トラックイベントについても同様である。ただし、相関関係の算出方法は、これに限らず、公知の相関関係の算出方法のいずれも用いることができる。
【００９５】
分析エンジン１６は、分析結果からフィルタリングルール１４ａを自動生成する。分析エンジン１６は、時系列データテーブル１７に基づき、１時間毎に保存された各種イベント毎の評価値から、１日の分析期間（第２の期間の一例）毎に各種類のイベント毎の評価値を算出し、各種類の既存イベントと新規イベントとの相関分析に使用する。本実施形態では、分析期間（第２の期間の一例）は、第１の期間よりも長い期間であれば、必ずしも１日である必要はない。第２の期間と第３の期間とは、同じ期間であってもよいし異なる期間であってもよい。
【００９６】
図１３に戻り、ステップＳ６０において、分析エンジン１６は、相関係数値２９３が閾値２８３の範囲内であると判定した場合、新規イベントと既存イベントとの相関関係は低いと判断し、本処理を終了する。このように新規イベント（バイクイベント）がどの既存イベントとも高い相関関係が認められなかった場合、新規イベントに関するフィルタリングルール及びイベント処理ルールは、自動生成されない。
【００９７】
一方、ステップＳ６０において、分析エンジン１６は、相関係数値２９３が閾値２８３の範囲を超えていると判定した場合、新規イベントと既存イベントとの相関関係は高いと判断し、ステップＳ６２に進む。ステップＳ６２において、分析エンジン１６は、最も高い相関があった既存イベントのフィルタリングルールがあるかを判定する。
【００９８】
ステップＳ６２において、分析エンジン１６は、相関が最も高い既存イベントのフィルタリングルールがあると判定した場合、ステップＳ６４において相関が最も高い既存イベントのフィルタリングルールに応じて新規イベントのフィルタリングルールを自動生成する。閾値２８３の範囲を超える相関係数値２９３が一つの場合には、閾値２８３の範囲を超える相関係数値２９３に対応する既存イベントのフィルタリングルールに応じて新規イベントのフィルタリングルールが自動生成される。
【００９９】
例えば、図１５の（ｂ）に示す第２相関テーブル２１９では、相関係数値２９３から、新規イベントであるバイクイベントは乗用車イベントと最も相関が高いことがわかる。このように、例えば、相関係数値２９３の絶対値が０．９５を上回るような強い相関関係が認められる場合、乗用車の速度が上がればバイクの速度も上がり、乗用車の速度が下がればバイクの速度も下がることが予想される。この場合、交通渋滞との相関関係が低かった乗用車イベントと高い相関のあったバイクイベントは、乗用車イベントと同様に交通渋滞に関係がない又は関係が低いと予想できる。
【０１００】
上記予想について具体的に説明する。交通制御サーバ２０は、サーバ装置１０からのレコメンドに応じて渋滞を回避するための制御により実際に渋滞が回避できたかを示す評価値をイベント毎に算出し、サーバ装置１０に送信する。例えば、交通制御サーバ２０からサーバ装置１０に送信された評価値が、乗用車イベントの評価値である場合、サーバ装置１０は、式（１）に基づき乗用車イベントの評価値と乗用車イベントの速度データとから乗用車イベントの相関係数値１９３を算出する。乗用車イベントの相関係数値１９３が閾値１８３以下の場合、サーバ装置１０は、乗用車イベントの評価値と乗用車イベントの速度データとの相関が低いと判定する。この結果、サーバ装置１０は、図１０のステップＳ５２に示すように、乗用車イベントのフィルタリングルールを自動生成する。これにより、乗用車イベントのフィルタリングルールに基づき乗用車イベントの速度データは破棄される。このようにしてイベント種類毎の評価値により特定されるフィルタリングルールに基づき、不要イベントを破棄することができる。
【０１０１】
相関係数値２９３は、新規イベントと既存イベントとの相関関係を示す。サーバ装置１０は、式（１）に基づき新規イベントと既存イベントとの相関係数値２９３を算出する。相関係数値２９３に基づき新規イベント及び既存イベントに高い相関があると判定される場合、上記算出した評価値に基づき評価済みの既存イベントのフィルタリングルールを使用して、新規イベントのフィルタリングルールを自動生成する。例えば、新規イベントがバイクイベント及び既存イベントが乗用車イベントの場合であって、バイクイベントと乗用車イベントとの相関係数値２９３が閾値２８３を超える場合、サーバ装置１０は、バイクイベントと乗用車イベントとの相関が高いと判定する。この場合、交通渋滞との相関が低かった乗用車イベントと高い相関のあったバイクイベントは、乗用車イベントと同様に交通渋滞に関係がない又は関係が低いと予想できる。この結果、図１３のステップＳ６４に示すように、サーバ装置１０は、既存イベントである乗用車イベントのフィルタリングルールを使用して新規イベントであるバイクイベントのフィルタリングルールを自動生成する。図１４に示す例では、分析エンジン１６は、乗用車イベントのフィルタリングルール１４ａを使用してバイクイベントをフィルタリングするフィルタリングルール１４ｃを自動生成している。このようにして既存イベントと新規イベントとの相関係数値２９３に基づき、既存イベントと相関が高いと判定された新規イベントに対して上記算出した評価値に基づき評価済みの既存イベントのフィルタリングルールを使用して、新規イベントのフィルタリングルールを自動生成することができる。これにより、受信する複数のイベントを所定のルールに基づきイベント処理する前にフィルタするフィルタ条件を適切に設定することができる。
【０１０２】
なお、既存イベントは、第１のイベント種類のイベント処理対象データの一例であり、新規イベントは、第２のイベント種類のイベント処理対象データの一例である。既存イベントのフィルタリングルールは、第１のイベント種類に対する第１のフィルタ条件の一例である。新規イベントのフィルタリングルールは、第２のイベント種類に対する第２のフィルタ条件の一例である。生成した第１のフィルタ条件、および、第２のフィルタ条件は、サーバ装置１０が受信する複数のイベント処理対象データを図８のイベント処理に入力する前にフィルタするフィルタの条件を示す。
【０１０３】
上記の説明では、新規イベントと既存イベントとの相関係数値２９３と、既存イベントの評価値より特定される既存イベントに関する第１のフィルタ条件に基づき、新規イベントに関する第２のフィルタ条件を自動生成したが、これに限らない。例えば、第１の既存イベントと第１の既存イベントと種類が異なる第２の既存イベントとの相関係数値２９３と、第１の既存イベントの評価値より特定される第１の既存イベントに関する第１のフィルタ条件に基づき、第２の既存イベントに関する第２のフィルタ条件を自動生成してもよい。例えば、既存イベントの一例である乗用車イベントの第１のフィルタ条件と、既存イベントの他の例であるトラックイベント及び乗用車イベントの相関係数値２９３とに基づき、トラックイベントに関する第２のフィルタ条件を自動生成してもよい。これによれば、時間帯や道路の状況に応じて変化する既存イベント及び新規イベントを含む入力イベントを破棄するためのルールを適切に設定することができる。
【０１０４】
図１４に示す例では、分析エンジン１６は、乗用車用のフィルタリングルール１４ａのフィルタ条件と同じ条件のバイク用のフィルタリングルール１４ｃが自動生成されている。
【０１０５】
これにより、ＣＥＰエンジン１５に入力されるイベントから、不要なイベントのデータを取り除くことができる。この結果、ＣＥＰエンジン１５は、交通渋滞の回避に有益なイベントのデータをイベント処理することにより、有益なレコメンドを交通制御サーバ２０に送信できるとともに、ＣＥＰエンジン１５の処理の負荷を軽減できる。特に、本実施形態によれば、新規イベントの発生により入力イベントのデータ量が急増した場合においても、ＣＥＰシステムの負荷の増大を抑止できる。
【０１０６】
図１３に戻り、次に、ステップＳ６６において、分析エンジン１６は、イベント処理ルール１５ａを自動生成し、本処理を終了する。
【０１０７】
自動生成されたフィルタリングルールには有効期限があり、有効期限を経過したフィルタリングルールは自動削除される。よって、フィルタリングルールが自動的に破棄されたとき、フィルタリングされなくなった新規イベントがＣＥＰエンジン１５に入力される。そこで、フィルタリングされなくなった新規イベントをイベント処理するために、ステップＳ６６においてイベント処理ルール１５ａが予め自動生成される。これにより、ＣＥＰエンジン１５は、ＣＥＰエンジン１５に入力された新規イベントをイベント処理し、交通制御サーバ２０に対するレコメンドの対象イベントとすることができる。
【０１０８】
例えば、図１６では、分析エンジン１６は、交通渋滞に関係があったトラックイベントと高い相関のあったバイクイベントも、おそらくは交通状態に関係があるだろうと予測し、バイクイベント用のイベント処理ルール１５ｃを自動生成する。分析エンジン１６は、トラックイベントのイベント処理ルールの条件と同じ条件のバイク用のイベント処理ルールを自動生成する。これにより、バイクイベントをＣＥＰエンジン１５によりイベント処理できる。
【０１０９】
なお、新規イベント（ここでは、バイクイベント）がどの既存イベントとも高い相関が認められなかった場合には、バイクイベント用のイベント処理ルールは自動生成されない。この場合、管理者が必要に応じて新規イベントに関するイベント処理ルール１５ａを手動にて生成することが好ましい。
【０１１０】
ステップＳ６２において、分析エンジン１６は、最も高い相関があった既存イベントのフィルタリングルールがないと判定した場合、ステップＳ６６に進み、新規イベント用のイベント処理ルール１５ｃを自動生成し、本処理を終了する。
【０１１１】
これによれば、運用中に新規イベントが分析エンジン１６に入力され、かつ、フィードバックにかかる評価値が次に得られるまでに時間を要する場合であっても、自動生成された新規イベント用のイベント処理ルール１５ｃに基づき、既存イベントと新規イベントとの相関関係を自動分析できる。その結果、分析エンジン１６は、フィルタリングルール１４ｃの自動生成が可能となり、必要データと不要データとを自動で選別することができる。
【０１１２】
なお、図１４の（３）に示すフィルタリングルール１４ｃの自動生成、及び図１４の（４）に示すイベント処理ルール１５ｃの自動生成後、図１４の（５）に示すように、分析エンジン１６は、管理者にメールを送信し、各ルールの自動生成の通知を行ってもよい。各ルールの自動生成が行われなかったときや、各ルールの自動生成に失敗した場合にもその旨をメールにて管理者に通知してもよい。
【０１１３】
なお、特に新規イベントが追加され、かつ、新規イベントのイベント数が少ないなどの理由により信頼性のある評価値が得られるまでに時間を要することが考えられる。このような場合、交通制御サーバ２０が、毎日評価値をサーバ装置１０にフィードバックすることは、ＣＥＰシステムの負荷を必要以上に高める懸念がある。そこで、交通制御サーバ２０は、システムの負荷が高くならないように、状況に応じて例えば、毎月、第一月曜を、評価値をサーバ装置１０に送信する日にする等送信頻度を下げてもよい。
【０１１４】
（イベント処理ルールの自動生成の例）
イベント処理ルールの自動生成の例を、図１８に基づき説明する。図１８は、一実施形態にかかるイベント処理ルールの自動生成方法を示す。例えば、分析エンジン１６は、新規イベントのイベント処理ルールの自動生成では、分析エンジン１６は、既存イベントのイベント処理ルールを新規イベントのイベント処理ルール用にコピーし、対象イベントのイベント名を変名する。図１８では、分析エンジン１６は、トラックイベント用のイベント処理ルール１５ａをバイクイベントのイベント処理ルール１５ｃ用にコピーし、対象イベントのイベント名をトラックイベントからバイクイベントに変名する。イベント処理ルールの自動生成にはルールの構文解析ツールが使用される。これにより、新規イベントのイベント処理ルール１５ｃを自動生成することができ、手動でイベント処理ルールを生成する手間を省くことができる。
【０１１５】
［効果の例］
例えば、ＣＥＰエンジンに入力するデータを絞り込むために、必要なデータと不要なデータを抽出するフィルタ条件を管理者が手動で行う場合、システムの運用コストが高くなる。また、フィルタ条件の設定が、管理者の開発スキルに依存する。このため、ＣＥＰエンジンに入力するデータとして適切なデータが選別されないことがある。また、ＣＥＰエンジンが必要なデータと不要なデータとは運用中に変化する場合がある。その場合、フィルタ条件が固定されていると運用中の状況変化に追従できず、状況変化に対応したデータをＣＥＰエンジンに入力できなくなる。その結果、不要となったデータであっても、ＣＥＰエンジンに入力してしまい、システム負荷が軽減されない状況が生じ得る。また、運用中に新規データが急増した場合、新規データに対する選別に時間がかかるとシステム負荷が増加し、システム全体の処理性能が低下する。
【０１１６】
これに対して、本実施形態に係るＣＥＰシステムでは、以下の機能（１）〜（３）を持つことにより、上記の問題を解決し、システムの負荷軽減と、急増するビッグデータに対しての複合イベント処理を低コストで行うことを可能とする。
（１）必要なデータと不要なデータの自動分析と自動選別の機能
（２）選別した不要データのフィルタリングルールの自動生成の機能
（３）新規イベントが発生した場合の自動分析と自動選別の機能、及びイベント処理ルールの自動生成の機能
本実施形態では、レコメンドを利用する送信先（例えば、交通制御サーバ２０）からフィードバックされた評価値と入力イベントの時系列データとの相関関係の分析を自動的に行うことができる。これにより、重要イベントと非重要イベントとを自動選別し、非重要イベントを適切にフィルタリングできる。また、本実施形態では、交通制御サーバ２０からフィードバックされた評価値に基づき、フィルタ条件を動的に変化させることができる。このため、運用中の状況変化に追従し、状況変化に対応して不要となったデータをフィルタリングにより取り除き、必要なデータをＣＥＰエンジンに入力することができる。この結果、ＣＥＰシステムの負荷を軽減できる。
【０１１７】
また、本実施形態では、新規イベントと既存イベントとの相関関係の分析を自動的に行うことができる。この結果、新規イベントと既存イベントとに高い相関が認められた場合、既存イベントのフィルタリングルールと同様の条件を新規イベントに適用することにより、不要な新規イベントを自動的に排除できる。また、既存イベントのイベント処理ルールと同様の条件を新規イベントに適用することにより、新規イベントに関して有用性のあるレコメンドを交通制御サーバ２０に提供することができる。
【０１１８】
（ハードウェア構成例）
最後に、本実施形態に係るサーバ装置１０のハードウェア構成例について、図１９を参照して説明する。図１９は、本実施形態に係るサーバ装置１０のハードウェア構成例を示す。
【０１１９】
図１９に示すように、サーバ装置１０は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ(Random Access Memory)１０４、ＲＯＭ(Read Only Memory)１０５、ＣＰＵ(Central Processing Unit)１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ(Hard Disk Drive)１０８を備える。各部はバスＢで相互に接続されている。
【０１２０】
入力装置１０１は、キーボードやマウスなどを含み、サーバ装置１０に各操作信号を入力するのに用いられる。表示装置１０２は、ディスプレイなどを含み、各種の処理結果を表示する。
【０１２１】
通信Ｉ／Ｆ１０７は、サーバ装置１０をネットワークに接続するインタフェースである。これにより、サーバ装置１０は、通信Ｉ／Ｆ１０７を介して、交通制御サーバ２０とデータ通信を行うことができる。
【０１２２】
ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、装置全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、ＨＤＤ１０８には、各種のＤＢ情報やプログラム等が格納されている。
【０１２３】
外部Ｉ／Ｆ１０３は、外部装置とのインタフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、サーバ装置１０は、外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａには、ＣＤ(Compact Disk)、及びＤＶＤ(Digital Versatile Disk)、ならびに、ＳＤメモリカード(SD Memory card)やＵＳＢメモリ(Universal Serial Bus memory)などがある。
【０１２４】
ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５には、ネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＣＰＵ１０６は、上記記憶装置（例えば「ＨＤＤ１０８」や「ＲＯＭ１０５」など）から、プログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。
【０１２５】
上記ハードウェア構成により、本実施形態に係るＣＥＰシステムは、イベント処理、フィルタリングルールの自動生成処理、イベント処理ルールの自動生成処理等を行うことができる。例えば、ＣＰＵ１０６が、ＲＯＭ１０５やＨＤＤ１０８内に格納されたデータ及びプログラムを用いてイベント処理、フィルタリングルールの自動生成処理、イベント処理ルールの自動生成処理等を実行する。時系列データテーブル１７、設定テーブル１８、第１相関テーブル１９及び第２相関テーブル２１９は、ＲＡＭ１０４やＨＤＤ１０８に保存されるか、又はネットワークを介してサーバ装置１０に接続されるクラウド上のサーバー等に格納され得る。
【０１２６】
以上、データ処理プログラム、データ処理方法及びデータ処理装置を上記実施形態により説明した。しかしながら、本発明にかかるデータ処理プログラム、データ処理方法及びデータ処理装置は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記複数の実施形態に記載された事項は、矛盾しない範囲で組み合わせることができる。また、上記データ処理プログラム、データ処理方法及びデータ処理装置は、ハードウェアにより構成されてもよく、ソフトウェアにより構成されてもよく、ハードウェアとソフトウェアとを組み合わせて構成されてもよい。
【０１２７】
例えば、上記実施形態に係るＣＥＰシステムの構成は一例であり、本発明の範囲を限定するものではなく、用途や目的に応じて様々なシステム構成例があることは言うまでもない。例えば、サーバ装置１０と交通制御サーバ２０とがネットワークを介して互いに接続されているシステム形態は、本発明に係るＣＥＰシステムの一態様であり、これに限定されない。例えば、本発明に係るＣＥＰシステムに含まれサーバ装置１０の台数は、１台又は２台以上であり得る。複数のサーバ装置１０が設置される場合、イベント処理、フィルタリングルールの自動生成処理、イベント処理ルールの自動生成処理等は、複数台のサーバ装置１０で分散処理され得る。なお、用途や目的に応じて、複数台のうち１台のサーバ装置１０に選択的にそれら処理機能を集約させてもよい。また、上記実施形態に係るＣＥＰシステムでは、サーバ装置１０上でＣＥＰエンジン１５が動作する場合を例示したが、サーバ装置１０で一つまたは複数のＶＭ（Virtual Machine：仮想マシン）を動作させ、ＶＭ上でＣＥＰエンジン１５が動作してもよい。
【０１２８】
また、サーバ装置１０が行うサービスの形態は、交通渋滞を回避するためのレコメンドに限らない。サーバ装置１０が行う他のサービス形態としては、例えば家庭内に置かれた各種センサ（例えば、雨を検知するセンサ）から発生されるセンサ情報や家電製品から発せられる情報をイベントとして入力し、イベント処理することが挙げられる。その結果、サーバ装置１０は、イベント処理結果に応じたレコメンドを各家庭のディスプレイに表示するサービス等を行うことができる。レコメンドの一例としては、「近くで雨が降っています。部屋干しをお勧めします」や「天気がよくないので、外出前に部屋干しをお勧めします」や「今洗濯を開始すれば外出までに干せますよ」等が挙げられる。
【０１２９】
以上の説明に関し、更に以下の項を開示する。
（付記１）
受信するイベント処理対象データを所定のルールに従いイベント処理し、該イベント処理後のデータを順次出力する処理をコンピュータに実行させるデータ処理プログラムであって、
複数の前記イベント処理対象データのうち、第１のイベント種類の第１の期間毎の前記イベント処理後のデータに関する評価値を取得し、
前記複数のイベント処理対象データにおける、前記第１の期間よりも長い第２の期間での、前記第１のイベント種類のイベント処理対象データと、前記第１のイベント種類と異なる第２のイベント種類のイベント処理対象データとの相関係数値を算出し、
前記評価値より特定される、前記第１のイベント種類のイベント処理対象データに関する第１のフィルタ条件、および、前記相関係数値に基づき、前記第２のイベント種類のイベント処理対象データに関する第２のフィルタ条件を設定する、
データ処理プログラム。
（付記２）
前記第１のフィルタ条件、および、前記第２のフィルタ条件は、前記受信する複数のイベントのデータを前記イベント処理に入力する前にフィルタするフィルタ条件である、
付記１に記載のデータ処理プログラム。
（付記３）
フィルタ条件の有効期限を超えた前記第１のフィルタ条件又は第２のフィルタ条件を破棄する、
付記１又は２に記載のデータ処理プログラム。
（付記４）
受信するイベント処理対象データを所定のルールに従いイベント処理し、該イベント処理後のデータを順次出力する処理をコンピュータに実行させるデータ処理方法であって、
複数の前記イベント処理対象データのうち、第１のイベント種類の第１の期間毎の前記イベント処理後のデータに関する評価値を取得し、
前記複数のイベント処理対象データにおける、前記第１の期間よりも長い第２の期間での、前記第１のイベント種類のイベント処理対象データと、前記第１のイベント種類と異なる第２のイベント種類のイベント処理対象データとの相関係数値を算出し、
前記評価値より特定される、前記第１のイベント種類のイベント処理対象データに関する第１のフィルタ条件、および、前記相関係数値に基づき、前記第２のイベント種類のイベント処理対象データに関する第２のフィルタ条件を設定する、
データ処理方法。
（付記５）
前記第１のフィルタ条件、および、前記第２のフィルタ条件は、前記受信する複数のイベントのデータを前記イベント処理に入力する前にフィルタするフィルタ条件である、
付記４に記載のデータ処理方法。
（付記６）
フィルタ条件の有効期限を超えた前記第１のフィルタ条件又は第２のフィルタ条件を破棄する、
付記４又は５に記載のデータ処理方法。
（付記７）
受信するイベント処理対象データを所定のルールに従いイベント処理し、該イベント処理後のデータを順次出力するデータ処理装置であって、
複数の前記イベント処理対象データのうち、第１のイベント種類の第１の期間毎の前記イベント処理後のデータに関する評価値を取得する取得部と、
前記複数のイベント処理対象データにおける、前記第１の期間よりも長い第２の期間での、前記第１のイベント種類のイベント処理対象データと、前記第１のイベント種類と異なる第２のイベント種類のイベント処理対象データとの相関係数値を算出する分析部と、
前記評価値より特定される、前記第１のイベント種類のイベント処理対象データに関する第１のフィルタ条件、および、前記相関係数値に基づき、前記第２のイベント種類のイベント処理対象データに関する第２のフィルタ条件を設定するフィルタ部と、
を有する、データ処理装置。
（付記８）
前記第１のフィルタ条件、および、前記第２のフィルタ条件は、前記受信する複数のイベントのデータを前記イベント処理に入力する前にフィルタするフィルタ条件である、
付記７に記載のデータ処理装置。
（付記９）
フィルタ条件の有効期限を超えた前記第１のフィルタ条件又は第２のフィルタ条件を破棄する、
付記７又は８に記載のデータ処理装置。
【符号の説明】
【０１３０】
１：画像形成装置
４：受信部
５：分析部
６：フィルタ部
７：イベント処理部
１１：通信制御Ｉ／Ｆ部
１２：記憶部
１３：制御部
１４：フィルタエンジン
１４ａ、１４ｂ、１４ｃ：フィルタリングルール
１５：ＣＥＰエンジン
１５ａ、１５ｃ：イベント処理ルール
１６：分析エンジン
１７：時系列データテーブル
１８：設定テーブル
１９：第１相関テーブル
２０：交通制御サーバ
２２：速度データ（乗用車イベント）
２３：速度データ（トラックイベント）
２４：天気データ
２１９：第２相関テーブル
【図１】
0006668657.tif 000003
【図２】
0006668657.tif 000004
【図３】
0006668657.tif 000005
【図４】
0006668657.tif 000006
【図５】
0006668657.tif 000007
【図６】
0006668657.tif 000008
【図７】
0006668657.tif 000009
【図８】
0006668657.tif 000010
【図９】
0006668657.tif 000011
【図１０】
0006668657.tif 000012
【図１１】
0006668657.tif 000013
【図１２】
0006668657.tif 000014
【図１３】
0006668657.tif 000015
【図１４】
0006668657.tif 000016
【図１５】
0006668657.tif 000017
【図１６】
0006668657.tif 000018
【図１７】
0006668657.tif 000019
【図１８】
0006668657.tif 000020
【図１９】
0006668657.tif 000021