JP2015095125A - 負荷軽減プログラム、情報処理装置および負荷軽減方法 - Google Patents

Abstract

【課題】設定されているルールを適切なルールに変更することを可能にする。【解決手段】負荷軽減プログラムは、所定の情報を提供するために用いられるルールに関係するイベントをイベント元の入力源から入力し（Ｓ１１）、一定期間内に入力されたイベントの単位期間当たりの入力量に、ルールに合致すると予想される変化があるか否かを判定し（Ｓ１１）、変化がないと判定された場合に、入力中のイベントのイベント元から他のイベント元へ前記入力源を変更する（Ｓ１２）処理をコンピュータに実行させる。【選択図】図６

Description

本発明は、負荷軽減プログラムなどに関する。

近年、様々な対象から刻々と収集されるイベントを処理する技術として、複合イベント処理（ＣＥＰ：Complex Event Processing）が知られている。この複合イベント処理では、大量のイベントを受け付けて、予め設定された条件（ルール）に基づいてイベントを抽出し、抽出されたイベントに基づき分析が行われる。

特開２００２−０２３８２３号公報 特開２００７−２８７０４０号公報 特開２０１１−０７６１５３号公報

しかしながら、従来技術では、複合イベント処理に負荷がかかるという問題がある。すなわち、大量に受け付けるイベント量は、年々加速的に増加しつつあるので、複合イベント処理に負荷がかかってしまう。

１つの側面では、複合イベント処理の負荷を軽減することを目的とする。

本願の開示する負荷軽減プログラムは、所定の情報を提供するために用いられるルールに関係するイベントをイベント元の入力源から入力し、一定期間内に入力されたイベントの単位期間当たりの入力量に、前記ルールに合致すると予想される変化があるか否かを判定し、変化がないと判定された場合に、入力中のイベントのイベント元から他のイベント元へ前記入力源を変更する処理をコンピュータに実行させる処理をコンピュータに実行させる。

本願の開示する負荷軽減プログラムの１つの態様によれば、複合イベント処理の負荷を軽減することができる。

図１は、実施例１に係る情報処理装置を含むＣＥＰシステムの全体構成を示す図である。 図２は、ルールテーブルのデータ構造の一例を示す図である。 図３は、変化パターンテーブルのデータ構造の一例を示す図である。 図４は、不一致動作テーブルのデータ構造の一例を示す図である。 図５は、実施例１に係るＣＥＰシステムの具体的な処理の一例を示す図である。 図６は、実施例１に係る負荷軽減処理のフローチャートを示す図である。 図７は、実施例２に係る情報処理装置を含むＣＥＰシステムの全体構成を示す図である。 図８は、パターン一致回数テーブルのデータ構造の一例を示す図である。 図９は、実施例２に係るＣＥＰシステムの具体的な処理の一例を示す図である。 図１０は、実施例２に係る負荷軽減処理のフローチャートを示す図である。 図１１は、実施例３に係る情報処理装置を含むＣＥＰシステムの全体構成を示す図である。 図１２は、変化パターンテーブルのデータ構造の一例を示す図である。 図１３は、実施例３に係るＣＥＰシステムの具体的な処理の一例を示す図である。 図１４Ａは、実施例３に係る負荷軽減処理のフローチャートを示す図である。 図１４Ｂは、実施例３に係る負荷軽減処理のフローチャートを示す図である。 図１５は、実施例４に係る情報処理装置を含むＣＥＰシステムの全体構成を示す図である。 図１６は、実施例４に係るＣＥＰシステムの具体的な処理の一例を示す図である。 図１７Ａは、実施例４に係る負荷軽減処理のフローチャートを示す図である。 図１７Ｂは、実施例４に係る負荷軽減処理のフローチャートを示す図である。 図１７Ｃは、実施例４に係る負荷軽減処理のフローチャートを示す図である。 図１８は、負荷軽減プログラムを実行するコンピュータの一例を示す図である。

以下に、本願の開示する負荷軽減プログラム、情報処理装置および負荷軽減方法の実施例を図面に基づいて詳細に説明する。なお、以下では、本願の開示する情報処理装置をＣＥＰシステムに適用する場合を説明する。また、ＣＥＰシステムを自動車の渋滞発生の予測に用いる場合を説明する。しかしながら、本願の開示する情報処理装置はこれに限定されるものではない。

［実施例１に係るＣＥＰシステムの構成］
図１は、実施例１に係る情報処理装置を含むＣＥＰシステムの全体構成を示す図である。図１に示すように、ＣＥＰシステム９は、情報処理装置１と制御サーバ２とを有する。情報処理装置１は、複合イベント処理を行う物理サーバであり、例えば、データセンサや各企業に設けられたサーバコンピュータである。情報処理装置１には、イベントの入力源であるイベント元から複数の種類のイベントが配信（入力）される。イベントの入力源は、複数存在する。したがって、情報処理装置１には、全ての入力源から全てのイベントが入力されると、大量のイベントが入力されることになる。そこで、情報処理装置１は、入力されるイベントの単位時間当たりの入力量の変化を自動評価する。すなわち、情報処理装置１は、入力源から入力されるイベントを、所定の情報を提供するために用いられるルールに従ってフィルタリング（抽出）し、抽出に成功した場合に、ルールに対応した情報を、制御サーバ２に提供する。このような情報処理装置１は、入力されるイベントの単位時間当たりの入力量に、ルールに合致すると予想される変化があるか否かを判定する。情報処理装置１は、単位時間当たりの入力量に、ルールに合致すると予想される変化がないと判定した場合に、入力中のイベントのイベント元から他のイベント元へ、入力されるイベントの入力源を変更する。

情報処理装置１は、通信制御Ｉ／Ｆ部１１，１２と、記憶部１３と、制御部１４とを有する。通信制御Ｉ／Ｆ部１１，１２は、ネットワークとの間の通信を制御するインタフェースである。通信制御Ｉ／Ｆ部１１は、様々な入力源から配信されたイベントを受信する。例えば、通信制御Ｉ／Ｆ部１１は、所定領域から配信された走行中の自動車の位置および速度などの状況や、当該領域の天気の情報を受信する。ここでいう所定領域は、例えば情報処理装置１によって予め区別され、区別されたそれぞれの領域は、各入力源に対応する。一例として、１つの入力源としてルートＡが存在し、他の入力源としてルートＢが存在する。すなわち、通信制御Ｉ／Ｆ部１１は、１つの入力源としてのルートＡを走行中の自動車の状況や天気の情報を受信し、１つの入力源としてのルートＢを走行中の自動車の状況や天気の情報を受信する。通信制御Ｉ／Ｆ部１２は、入力されたイベントをルールに従って抽出した結果、抽出に成功した場合に、ルールに対応した情報を制御サーバ２へ提供する。

記憶部１３は、ハードディスク、光ディスクなどの記憶装置である。なお、記憶部１３は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＮＶＳＲＡＭ（Non Volatile Static Random Access Memory）などのデータを書き換え可能な半導体メモリであっても良い。

記憶部１３は、各種情報を記憶する。例えば、記憶部１３は、制御部１４で実行されるＯＳ（Operating System）や後述する入力処理、判定処理および変更処理など各種処理を行うプログラムを記憶する。さらに、記憶部１３は、制御部１４で実行されるプログラムの実行に要する各種データを記憶する。例えば、記憶部１３は、ルールテーブル１３１と、変化パターンテーブル１３２と、不一致動作テーブル１３３とを記憶する。

ルールテーブル１３１は、フィルタリングのルールを記憶したテーブルである。一例として、ルールテーブル１３１には、自動車の渋滞発生の予測を行うため、複数の条件からなるルールがユーザによって格納される。ここで、ルールテーブル１３１のデータ構造の一例を、図２を参照して説明する。図２は、ルールテーブルのデータ構造の一例を示す図である。図２に示すように、ルールテーブル１３１は、ルールＮｏ１３１ａ、平均速度１３１ｂ、天気予報１３１ｃおよび提供情報１３１ｄを対応付けて記憶する。ルールＮｏ１３１ａは、ルールを一意に識別する識別番号である。平均速度１３１ｂは、ルールを適用する、自動車の平均速度に関わる条件を示す。天気予報１３１ｃは、自動車が位置する領域の天気に関わる条件を示す。提供情報１３１ｄは、全ての条件に合致した場合に制御サーバ２に提供される情報である。一例として、ルールＮｏ１３１ａが「１」である場合、平均速度１３１ｂとして「５０ｋｍ／時以下」、天気予報１３１ｃとして「雨」、提供情報１３１ｄとして、「渋滞発生の可能性有り」と記憶している。

変化パターンテーブル１３２は、ルールに合致する場合に予想される、イベントの入力における変化パターンを記憶する。例えば、変化パターンテーブル１３２には、自動車の渋滞発生の予測を行うため、渋滞発生時の入力イベントの予想される変化パターンがユーザによって格納される。変化パターンは、一例として、一定時間内に入力されるイベントの単位時間当たりの入力量が閾値を超えることや上下の閾値の範囲内であることなどで表される。なお、変化パターンは、状況に応じて、ユーザによって動的に変更されることが可能である。なお、変化パターンテーブル１３２のデータ構成については、後述する。

不一致動作テーブル１３３は、変化パターンと不一致であった時の動作を記憶する。すなわち、不一致動作テーブル１３３は、特定の入力源から入力されたイベントの入力量が変化パターンと不一致であった時の動作を記憶する。一例として、不一致動作テーブル１３３は、予め、ユーザによって格納される。なお、不一致動作テーブル１３３のデータ構成については、後述する。

制御部１４は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。そして、制御部１４は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路の電子回路に対応する。また、制御部１４は、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路に対応する。さらに、制御部１４は、入力部１４１と、第１の判定部１４２と、変更部１４３とを有する。

入力部１４１は、所定の情報を提供するために用いられるルールに関係するイベントをイベント元の入力源から入力する。例えば、ルールが、自動車の渋滞発生の予測情報を提供するために用いられる場合、渋滞が発生すると予測される入力源をイベント元のデフォルトの入力源として設定される。すなわち、入力部１４１は、複数存在する入力源からイベントを入力するのではなく、設定される入力源からイベントを入力する。一例として、入力されるイベントは、ＸＭＬ（Extensible Markup Language）形式のデータ構造である。

第１の判定部１４２は、一定時間内に入力されたイベントの単位時間当たりの入力量に、ルールに合致すると予想される変化があるか否かを判定する。例えば、第１の判定部１４２は、一定時間内に入力されたイベントの単位時間当たりの入力量が、変化パターンテーブル１３２に記憶された予想変化の変化パターンと一致するか否かを判定する。なお、一定時間内で一度でも予想変化の変化パターンと一致すれば、変化パターンと一致すると判定される。

ここで、変化パターンテーブル１３２のデータ構造について、図３を参照して説明する。図３は、変化パターンテーブルのデータ構造の一例を示す図である。図３に示すように、変化パターンテーブル１３２は、ルールに合致すると予想される予想変化が記憶される。図３の例では、予想変化として、２つの要素１３２ａ，１３２ｂを有する変化パターンが設定されている。１つの要素１３２ａには、「１６：００〜１７：００に、自動車のデータ量が１０００件／秒超過」が設定されている。他の要素１３２ｂには、「１７：００〜１８：００に、自動車のデータ量が２０００件／秒超過」が設定されている。すなわち、第１の判定部１４２は、１６：００〜１７：００内で、入力された自動車のイベントの１秒当たりの入力量が１０００件を超過したか否かを判定する。加えて、第１の判定部１４２は、１７：００〜１８：００内で、入力された自動車のイベントの１秒当たりの入力量が２０００件を超過したか否かを判定する。

図１に戻って、変更部１４３は、単位時間当たりの入力量に、ルールに合致すると予想される変化がない場合に、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。例えば、変更部１４３は、第１の判定部１４２によって予想変化の変化パターンと一致しないと判定された場合に、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。入力源は、一例として、不一致動作テーブル１３３に記憶された不一致時の動作１３３ｂに基づいて、変更される。

ここで、不一致動作テーブル１３３のデータ構造について、図４を参照して説明する。図４は、不一致動作テーブルのデータ構造の一例を示す図である。図４に示すように、不一致動作テーブル１３３は、デフォルトルート１３３ａおよび不一致時の動作１３３ｂを対応付けて記憶する。デフォルトルート１３３ａには、入力されるイベントのイベント元であるルートが設定される。すなわち、ルールが自動車の渋滞発生の予測情報を提供するために用いられる場合、デフォルトルート１３３ａには、渋滞が発生すると予測されるイベント元である入力源がデフォルトのルートとして設定される。不一致時の動作１３３ｂには、イベントの入力量が変化パターンと不一致である時の動作が設定される。つまり、不一致時の動作１３３ｂには、第１の判定部１４２によってイベントの単位時間当たりの入力量が変化パターンと一致しないと判定された場合の動作が設定される。一例として、デフォルトルート１３３ａが「ルートＡ」である場合に、不一致時の動作１３３ｂとして「入力源をルートＡ→ルートＢに変更。かつ、デフォルトルートをＢに変更。（または、その逆）」と記憶している。すなわち、ルートＡの入力源からイベントが入力されていると、入力されたイベントの入力量が変化パターンと不一致であった場合、変更部１４３が、入力源をルートＡからルートＢに変更するとともに、デフォルトルート１３３ａをルートＢに変更する。一方、ルートＢの入力源からイベントが入力されていると、入力されたイベントの入力量が変化パターンと不一致であった場合、変更部１４３が、入力源をルートＢからルートＡに変更するとともに、デフォルトルート１３３ａをルートＡに変更する。

［ＣＥＰシステムの具体的な処理の一例］
図５は、実施例１に係るＣＥＰシステムの具体的な処理の一例を示す図である。図５に示すように、情報処理装置１は、ＣＥＰエンジン３０が動作する。ＣＥＰエンジン３０は、制御部１４に含まれ、複合イベント処理を実現するソフトウェアである。複合イベント処理を実現するソフトウェアとしては、例えば、Ｅｓｐｅｒが挙げられる。

ここで、情報処理装置１には、予めユーザが設定したルールとして、「平均速度が５０ｋｍ／時以下、かつ、天気予報が雨」が設定されている。このルールに合致した場合のアクションとして、「渋滞発生可能性有」をレコメンド（提供）することが設定されている。

また、変化パターンテーブル１３２には、ルールに合致すると予想される予想変化の変化パターンとして、１６：００〜１７：００に自動車のデータ量が１０００件／秒を超過することが設定されている。加えて、１７：００〜１８：００に自動車のデータ量が２０００件／秒を超過することが設定されている。つまり、情報処理装置１は、この変化パターンと一致すれば、「自動車の平均速度が５０ｋｍ／時以下、かつ、天気予報が雨」というルールに合致すると予想される。そして、情報処理装置１は、ルールに合致すれば、制御サーバ２に「渋滞発生可能性有」をレコメンドする。この結果、制御サーバ２は、渋滞を回避すべく、渋滞が発生しているルートの例えば信号機を制御することができる。一方、情報処理装置１は、この変化パターンと不一致になった時に、ルールに合致しないと予想されるので、現在の入力源を他の入力源に変更させるのである。

不一致動作テーブル１３３には、デフォルトルート１３３ａとしてルートＡが設定され、不一致時の動作１３３ｂとして入力源をルートＡからルートＢに変更することが設定されている。

このような情報処理装置１では、入力部１４１が、現在のイベントを配信する入力源がルートＡであるので、ルートＡを走行中の自動車から自動車の状況のイベントおよび天気予報サイトからルートＡの局地天気のイベントを入力する。一方、情報処理装置１では、入力部１４１は、ルートＢを走行中の自動車から自動車の状況のイベントおよび天気予報サイトからルートＢの局地天気のイベントを入力しない。

そして、情報処理装置１では、第１の判定部１４２が、一定時間内に入力されたイベントの単位時間当たりの入力量が、変化パターンテーブル１３２に記憶された予想変化の変化パターンと一致するか否かを判定する。すなわち、第１の判定部１４２は、自動車の状況におけるイベントの１秒当たりの入力量が、１６：００〜１７：００に１０００件／秒を超過し、かつ、１７：００〜１８：００に２０００件／秒を超過したか否かを判定する。ここでは、自動車の状況におけるイベントの１秒当たりの入力量は、１６：００〜１７：００に１０００件／秒を超過するという予想変化と一致したが、１７：００〜１８：００に２０００件／秒を超過するという予想変化と一致しなかったとする。

そこで、情報処理装置１では、変更部１４３が、予想変化の変化パターンと一致しないと判定された場合に、不一致動作テーブル１３３に記憶された不一致時の動作１３３ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。加えて、変更部１４３は、デフォルトルート１３３ａを変更する。ここでは、不一致動作テーブル１３３に記憶された不一致時の動作１３３ｂに基づいて、ルートＡからルートＢへ入力源が変更される。加えて、デフォルトルート１３３ａがルートＢに変更される。

なお、デフォルトルート１３３ａがルートＢに変更されると、入力部１４１は、ルートＢを走行中の自動車から自動車の状況のイベントおよび天気予報サイトからルートＢの局地天気のイベントを入力する。一方、入力部１４１は、ルートＡを走行中の自動車から自動車の状況のイベントおよび天気予報サイトからルートＡの局地天気のイベントを入力しない。そして、第１の判定部１４２が、一定時間内に入力されたイベントの単位時間当たりの入力量が、変化パターンテーブル１３２に記憶された予想変化の変化パターンと一致するか否かを判定する。そして、変更部１４３は、予想変化の変化パターンと一致しないと判定された場合に、不一致動作テーブル１３３に記憶された不一致時の動作１３３ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更するとともに、デフォルトルート１３３ａを変更する。ここでは、ルートＢからルートＡへ入力源が変更されるとともに、デフォルトルート１３３ａがルートＡに変更される。

このようにして、情報処理装置１は、ルールに合致すると予想される予想変化の変化パターンを用いて、ルールに合致すると予想されるイベントが配信されるように、入力源を変更し、変更した入力源からイベントを入力する。したがって、情報処理装置１は、全ての入力源からのイベントの入力を回避でき、複合イベント処理の負荷を軽減できる。

［負荷軽減処理の手順］
次に、図６を参照して、負荷軽減処理の手順を説明する。図６は、実施例１に係る負荷軽減処理のフローチャートを示す図である。なお、不一致動作テーブル１３３には、デフォルトルート１３３ａとしてルートＡが設定され、不一致時の動作１３３ｂとして入力源をルートＡからルートＢに変更することが設定されている。変化パターンテーブル１３２には、予想変化として変化パターンが設定されている。そして、入力部１４１は、デフォルトルート１３３ａに設定されたルートＡの入力源からイベントを入力している。

まず、入力部１４１は、デフォルトルート１３３ａに設定されたルートＡの入力源からイベントを入力している。すると、第１の判定部１４２は、イベントの入力に関し、予想変化の変化パターンと不一致であるか否かを判定する（ステップＳ１１）。例えば、第１の判定部１４２は、一定時間内に入力されたイベントの単位時間当たりの入力量が、変化パターンテーブル１３２に記憶された予想変化の変化パターンと一致するか否かを判定する。

イベントの入力に関し、予想変化の変化パターンと不一致であると判定した場合（ステップＳ１１；Ｙｅｓ）、変更部１４３は、不一致時の動作１３３ｂに基づき、変更するルートを入力源に設定する（ステップＳ１２）。例えば、変更部１４３は、不一致動作テーブル１３３に記憶された不一致時の動作１３３ｂに基づき、現在のデフォルトルートであるルートＡからルートＢへ入力源を変更する。そして、変更部１４３は、デフォルトルート１３３ａにルートＢを設定する。そして、負荷軽減処理は、ステップＳ１１に移行する。その後、入力部１４１は、変更された入力源であるルートＢからイベントを入力する。

一方、イベントの入力に関し、予想変化の変化パターンと不一致でないと判定した場合（ステップＳ１１；Ｎｏ）、変更部１４３は、何も処理をしない。そして、負荷軽減処理は、ステップＳ１１に移行する。すなわち、入力部１４１は、引き続き、現在の入力源であるルートＡからイベントを入力する。

［実施例１の効果］
上記実施例１によれば、情報処理装置１は、所定の情報を提供するために用いられるルールに関係するイベントをイベント元の入力源から入力する。そして、情報処理装置１は、一定時間内に入力されたイベントの１秒当たりの入力量に、ルールに合致すると予想される変化があるか否かを判定する。そして、情報処理装置１は、判定する処理によって１秒当たりの入力量に、ルールに合致すると予想される変化がないと判定した場合に、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。かかる構成によれば、情報処理装置１は、入力源から入力されたイベントについて、ルールに合致すると予想される変化がない場合に、入力されるイベントの入力源を変更する。この結果、情報処理装置１は、全ての入力源からのイベントの入力を回避でき、複合イベント処理の負荷を軽減できる。

また、上記実施例１によれば、情報処理装置１は、一定期間内に入力されたイベントの１秒当たりの入力量が、変化として閾値を超えることを示す予想変化と一致するか否かを判定する。そして、情報処理装置１は、判定する処理によって予想変化と一致しないと判定された場合に、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。かかる構成によれば、情報処理装置１は、入力源から入力されたイベントについて、変化として閾値を超えることを示す予想変化と一致しない場合に、入力されるイベントの入力源を変更する。この結果、情報処理装置１は、全ての入力源からのイベントの入力を回避でき、複合イベント処理の負荷を軽減できる。

ところで、実施例１では、情報処理装置１は、イベントの１秒当たりの入力量に、ルールに合致すると予想される変化がない場合に、予め設定された不一致時の動作１３３ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。しかしながら、情報処理装置１は、これに限定されず、所定期間の中で、複数のイベント元毎に変化があった回数をカウントしておく。そして、情報処理装置１は、所定期間経過後、回数の大きいものから順番に自動的に変更先のイベント元を決定し、入力中のイベントのイベント元から決定したイベント元へ入力源を変更するようにしても良い。

そこで、実施例２では、情報処理装置１は、所定期間の中で、複数のイベント元毎に変化があった回数をカウントしておき、回数の大きいものから順番に自動的に変更先のイベント元を決定し、決定したイベント元へ入力源を変更する場合について説明する。

［実施例２に係るＣＥＰシステムの構成］
図７は、実施例２に係る情報処理装置を含むＣＥＰシステムの全体構成を示す図である。なお、図１に示すＣＥＰシステム９と同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例１と実施例２とが異なるところは、制御部１４にパターン一致回数計数部１４４を追加した点にある。実施例１と実施例２とが異なるところは、制御部１４の変更部１４３を変更部１４３Ａに変更した点にある。また、実施例１と実施例２とが異なるところは、記憶部１３にパターン一致回数テーブル１３４を追加した点にある。

パターン一致回数テーブル１３４は、入力源毎に、変化パターンに一致した回数を記憶する。ここで、パターン一致回数テーブル１３４のデータ構造について、図８を参照して説明する。図８は、パターン一致回数テーブルのデータ構造の一例を示す図である。図８に示すように、パターン一致回数テーブル１３４は、ルート１３４ａおよび一致回数（日）１３４ｂを対応付けて記憶する。ルート１３４ａには、全てのイベント元（入力源）であるルートが設定される。一致回数（日）１３４ｂは、変化パターンに一致した回数を示す。なお、一致回数（日）１３４ｂは、後述するパターン一致回数計数部１４４によってカウントされ、一致した場合１日当たり１回としてカウントされる。一例として、ルート１３４ａが「Ａ」である場合、一致回数（日）１３４ｂとして「５」と記憶している。

パターン一致回数計数部１４４は、所定期間の中で、複数のイベント元毎に、変化があった回数をカウントする。例えば、パターン一致回数計数部１４４は、第１の判定部１４２によって変化パターンと一致すると判定された場合に、パターン一致回数テーブル１３４の入力中のイベントの入力源に対応する一致回数１３４ｂを１加算する。なお、所定期間は、予めユーザによって定められた期間であれば良く、１ヶ月であっても２ヶ月であっても、６月であっても良い。所定期間は、ある程度長期間の方が複数のイベント元毎の一致回数を平準化できる。

変更部１４３Ａは、所定期間内では、第１の判定部１４２によって予想変化の変化パターンと一致しないと判定された場合に、不一致動作テーブル１３３に記憶された不一致時の動作１３３ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。すなわち、変更部１４３Ａは、所定期間内では、予め設定された不一致時の動作１３３ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。

また、変更部１４３Ａは、所定期間経過後では、第１の判定部１４２によって予想変化の変化パターンと一致しないと判定された場合に、カウントされた一致回数１３４ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。すなわち、変更部１４３Ａは、パターン一致回数テーブル１３４に記憶された一致回数１３４ｂの大きい数から順番に自動的に変更先のイベント元を決定する。そして、変更部１４３Ａは、入力中のイベントのイベント元から決定したイベント元へ入力源を変更する。

つまり、実施例２では、例えばルートＣについて、所定期間前まで渋滞未発生であったが、何らかの理由により渋滞が発生する場合があることを想定する。すなわち、時間の経過とともに、変化パターンと一致するイベント量のイベントを配信するルート（入力源）の最適性は変化する。したがって、実施例２では、パターン一致回数計数部１４４が、所定期間の中で、複数のイベント元毎に変化があった回数をカウントしておく。そして、変更部１４３Ａは、所定期間経過後では、回数の大きい数から順番に自動的に変更先のイベント元を決定し、決定したイベント元へ入力源を変更する。

［ＣＥＰシステムの具体的な処理の一例］
図９は、実施例２に係るＣＥＰシステムの具体的な処理の一例を示す図である。図９に示すように、情報処理装置１は、ＣＥＰエンジン３０が動作する。ＣＥＰエンジン３０は、制御部１４に含まれ、複合イベント処理を実現するソフトウェアである。複合イベント処理を実現するソフトウェアとしては、例えば、Ｅｓｐｅｒが挙げられる。

ここで、情報処理装置１には、予めユーザが設定したルールとして、「平均速度が５０ｋｍ／時以下、かつ、天気予報が雨」が設定されている。このルールに合致した場合のアクションとして、「渋滞発生可能性有」をレコメンド（提供）することが設定されている。

また、変化パターンテーブル１３２には、ルールに合致すると予想される予想変化の変化パターンとして、１６：００〜１７：００に自動車のデータ量が１０００件／秒を超過することが設定されている。加えて、１７：００〜１８：００に自動車のデータ量が２０００件／秒を超過することが設定されている。つまり、自動車の１秒当たりのイベントの入力量が時間に応じて所定件数を超過すれば、「自動車の平均速度が５０ｋｍ／時以下、かつ、天気予報が雨」というルールに合致する可能性が高くなる。そして、情報処理装置１は、ルールに合致すれば、「渋滞発生可能性有」をレコメンドする。

また、不一致動作テーブル１３３には、デフォルトルート１３３ａとしてルートＡが設定され、不一致時の動作１３３ｂとして入力源をルートＡからルートＢに変更することが設定されている。さらに、不一致時の動作１３３ｂとして３ヶ月後から自動選定に移行することが設定されている。また、パターン一致回数テーブル１３４には、最近１ヶ月の変化パターンに一致した回数が、ルート（入力源）毎に設定されている。なお、ここでは、パターン一致回数計数部１４４によって一致回数がカウントされる所定期間を３ヶ月とし、既に１ヶ月経過したとする。

このような情報処理装置１では、入力部１４１が、現在のイベントを配信する入力源がルートＡであるので、ルートＡを走行中の自動車から自動車の状況のイベントおよび天気予報サイトからルートＡの局地天気のイベントを入力する。一方、情報処理装置１では、入力部１４１は、ルートＢを走行中の自動車から自動車の状況のイベントおよび天気予報サイトからルートＢの局地天気のイベントを入力しない。

そして、情報処理装置１では、第１の判定部１４２が、一定時間内に入力されたイベントの１秒当たりの入力量が、変化パターンテーブル１３２に記憶された予想変化の変化パターンと一致するか否かを判定する。すなわち、第１の判定部１４２は、自動車の状況におけるイベントの１秒当たりの入力量が、１６：００〜１７：００に１０００件／秒を超過し、かつ、１７：００〜１８：００に２０００件／秒を超過したか否かを判定する。

そして、パターン一致回数計数部１４４は、所定期間の３ヶ月以内であるので、複数のルート毎に、予想変化の変化パターンと一致すると判定された場合に、パターン一致回数テーブル１３４の入力中のイベントのルートに対応する一致回数１３４ｂを１加算する。

ここで、自動車の状況におけるイベントの１秒当たりの入力量は、１６：００〜１７：００に１０００件／秒を超過するという予想変化と一致したが、１７：００〜１８：００に２０００件／秒を超過するという予想変化と一致しなかったとする。

すると、所定期間の３ヶ月以内であるので、変更部１４３Ａは、予想変化の変化パターンと一致しないと判定されると、不一致動作テーブル１３３の不一致時の動作１３３ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。加えて、変更部１４３Ａは、デフォルトルート１３３ａを変更する。ここでは、不一致動作テーブル１３３に記憶された不一致時の動作１３３ｂに基づいて、ルートＡからルートＢへ入力源が変更される。加えて、デフォルトルート１３３ａがルートＢに変更される。

一方、所定期間の３ヶ月経過後である場合、変更部１４３Ａは、予想変化の変化パターンと一致しないと判定されると、カウントされた一致回数１３４ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。加えて、変更部１４３Ａは、デフォルトルート１３３ａを変更する。すなわち、変更部１４３Ａは、パターン一致回数テーブル１３４に記憶された一致回数１３４ｂの大きい数から順番に自動的に変更先のイベント元を決定し、入力中のイベントのイベント元から、決定されたイベント元へ入力源を変更する。ここでは、パターン一致回数テーブル１３４に記憶された一致回数１３４ｂに基づいて、ルートＣに対応する一致回数が最大数であるので、ルートＡからルートＣへ入力源が変更される。加えてデフォルトルート１３３ａがルートＣに変更される。

このようにして、情報処理装置１は、ルールに合致すると予想される予想変化の変化パターンを用いて、所定期間分変化パターンと一致する回数を入力源毎にカウントする。したがって、情報処理装置１は、変化パターンと一致するイベント量のイベントを配信する入力源の最適性を保つことが可能となる。

［負荷軽減処理の手順］
次に、図１０を参照して、負荷軽減処理の手順を説明する。図１０は、実施例２に係る負荷軽減処理のフローチャートを示す図である。なお、不一致動作テーブル１３３には、デフォルトルート１３３ａとしてルートＡが設定され、不一致時の動作１３３ｂとして入力源をルートＡからルートＢに変更することが設定されている。変化パターンテーブル１３２には、予想変化の変化パターンが設定されている。そして、入力部１４１は、デフォルトルート１３３ａに設定されたルートＡの入力源からイベントを入力している。さらに、図６に示す負荷軽減処理の手順と同一の処理については同一符号を示すことで、その重複する処理の説明については簡略する。

まず、入力部１４１は、デフォルトルート１３３ａに設定されたルートＡの入力源からイベントを入力している。すると、第１の判定部１４２は、イベントの入力に関し、予想変化の変化パターンと不一致であるか否かを判定する（ステップＳ１１）。

イベントの入力に関し、予想変化の変化パターンと不一致でない、すなわち一致していると判定した場合（ステップＳ１１；Ｎｏ）、第１の判定部１４２は、一致回数をカウントすべく、ステップＳ１３に移行する。

一方、イベントの入力に関し、予想変化の変化パターンと不一致であると判定した場合（ステップＳ１１；Ｙｅｓ）、変更部１４３Ａは、ルートの自動選定に移行したか否かを判定する（ステップＳ１２Ａ）。ルートの自動選定に移行していないと判定した場合（ステップＳ１２Ａ；Ｎｏ）、変更部１４３Ａは、不一致時の動作１３３ｂに基づき、変更するルートを入力源に設定する（ステップＳ１２Ｃ）。例えば、変更部１４３は、不一致動作テーブル１３３に記憶された不一致時の動作１３３ｂに基づき、現在のデフォルトルートであるルートＡからルートＢへ入力源を変更する。そして、変更部１４３は、デフォルトルート１３３ａにルートＢを設定する。そして、負荷軽減処理は、ステップＳ１３に移行する。その後、入力部１４１は、変更された入力源であるルートＢからイベントを入力する。

一方、ルートの自動選定に移行したと判定した場合（ステップＳ１２Ａ；Ｙｅｓ）、変更部１４３Ａは、変化パターンの一致回数の多いルート順に、ルートを入力源に設定する（ステップＳ１２Ｂ）。例えば、変更部１４３Ａは、パターン一致回数テーブル１３４に記憶された一致回数１３４ｂの大きい数から順番に変更先のルートを決定する。そして、変更部１４３Ａは、現在のデフォルトルートであるルートＡから、決定されたルートへ入力源を変更する。そして、負荷軽減処理は、ステップＳ１３に移行する。その後、入力部１４１は、変更された入力源であるルートＢからイベントを入力する。

ステップＳ１３では、パターン一致回数計数部１４４は、現在のルートの変化パターンの一致回数をカウントする（ステップＳ１３）。例えば、パターン一致回数計数部１４４は、パターン一致回数テーブル１３４の入力中のイベントのルートに対応する一致回数１３４ｂを１加算する。そして、負荷軽減処理は、ステップＳ１１に移行する。

［実施例２の効果］
上記実施例２によれば、情報処理装置１は、複数のイベント元毎に、所定期間の中で、変化があった回数をカウントする。そして、情報処理装置１は、カウントする処理によってカウントされた回数の大きい数に対応するイベント元から小さい数に対応するイベント元へ順番に変更先のイベント元を決定する。そして、情報処理装置１は、入力中のイベントのイベント元から決定したイベント元へ入力源を変更する。かかる構成によれば、情報処理装置１は、複数のイベント元毎に、所定期間の中で変化パターンと一致する回数をカウントし、一致する回数の大きい順にイベント元を決定することで、時間の経過と共に遷移する最適なイベント元へ入力源を変更することができる。

ところで、実施例１では、情報処理装置１は、入力されたイベントの１秒当たりの入力量が予想変化の変化パターンと一致しない場合に、予め設定された不一致時の動作１３３ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。実施例２では、情報処理装置１は、所定期間の中で、複数のイベント元毎に予想変化の変化パターンと一致した回数をカウントしておく。そして、情報処理装置１は、所定期間経過後、回数の大きいものから順番に自動的に変更先のイベント元を決定し、入力中のイベントのイベント元から決定したイベント元へ入力源を変更する。しかしながら、実施例３では、情報処理装置１は、これに限定されず、入力量が予想変化の変化パターンと一致しなくても、別の変化パターンに一致し、且つルールに合致した回数が所定の条件を満たせば、予想変化の変化パターンを別の変化パターンに置き換えるようにしても良い。

そこで、実施例３では、情報処理装置１は、入力量が予想変化の変化パターンと一致しなくても、別の変化パターンに一致し、且つルールに合致した回数が所定の条件を満たせば、予想変化の変化パターンを別の変化パターンに置き換える場合について説明する。

［実施例３に係るＣＥＰシステムの構成］
図１１は、実施例３に係る情報処理装置を含むＣＥＰシステムの全体構成を示す図である。なお、図１および図７に示すＣＥＰシステム９と同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例１，２と実施例３とが異なるところは、制御部１４に第２の判定部１４５およびルールヒット回数計数部１４６を追加した点にある。実施例１，２と実施例３とが異なるところは、記憶部１３の変化パターンテーブル１３２を変化パターンテーブル２００に変更した点にある。

ここで、変化パターンテーブル２００のデータ構造について、図１２を参照して説明する。図１２は、変化パターンテーブルのデータ構造の一例を示す図である。図１２に示すように、変化パターンテーブル２００は、２つの要素２００ａ，２００ｂを含む変化パターンと、ルールヒット回数２００ｃと、予想変化への採用条件２００ｄとを記憶する。変化パターンの１つの要素２００ａは、「１６：００〜１７：００」に関する条件である。変化パターンの他の要素２００ｂは、「１７：００〜１８：００」に関する条件である。複数の変化パターンのうち１つの変化パターンが、ルールに合致すると予想される予想変化となる。ルールヒット回数２００ｃは、変化パターンと一致した場合に、ルールにヒットした回数を示す。予想変化への採用条件２００ｄは、予想変化としての変化パターンに採用される条件を示す。すなわち、ある変化パターンに対応するルールヒット回数２００ｃが予想変化への採用条件２００ｄを満たす場合に、ルールヒット回数計数部１４６は、当該変化パターンを予想変化としての変化パターンに採用する。

一例として、予想変化の変化パターンとして「１６：００〜１７：００に、自動車のデータ量が１０００件／秒を超過」、「１７：００〜１８：００に、自動車のデータ量が２０００件／秒を超過」を記憶している。ルールヒット回数２００ｃとして「５回ヒット」、予想変化への採用条件２００ｄとして「」と記憶している。また、別の変化パターンとして「１６：００〜１７：００に、自動車のデータ量が１０００件／秒を超過」、「１７：００〜１８：００に、予想変化と不一致 自動車のデータ量が１５００件／秒を超過」を記憶している。ルールヒット回数２００ｃとして「２５回ヒット」、予想変化への採用条件２００ｄとして「ルールヒット回数が２５回以上、かつ、予想変化のルールヒット回数以上」と記憶している。また、別の変化パターンとして「１６：００〜１７：００に、自動車のデータ量が１０００件／秒超過」、「１７：００〜１８：００に、予想変化と不一致 自動車のデータ量が１０００件／秒超過 かつ、１５００件／秒以下」を記憶している。ルールヒット回数２００ｃとして「０回ヒット」、予想変化への採用条件２００ｄとして「ルールにヒットした回数が２５回以上、かつ、予想変化のヒット回数以上」と記憶している。

第１の判定部１４２は、一定時間内に入力されたイベントの１秒当たりの入力量が変化パターンテーブル２００に記憶された予想変化の変化パターンと一致するか否かを判定する。なお、一定時間内で一度でも予想変化の変化パターンと一致すれば、変化パターンと一致すると判定される。

第２の判定部１４５は、一定時間内に入力されたイベントの１秒当たりの入力量が変化パターンテーブル２００に記憶された予想変化の変化パターンと一致しないと判定した場合、以下の処理を行う。第２の判定部１４５は、当該入力量が変化パターンテーブル２００に記憶された予想変化と異なる変化パターンと一致するか否かを判定する。なお、一定時間内で一度でも予想変化と異なる変化パターンと一致すれば、変化パターンと一致すると判定される。

ルールヒット回数計数部１４６は、一定時間内に入力されたイベントの１秒当たりの入力量が変化パターンと一致すると判定した場合、以下の処理を行う。ルールヒット回数計数部１４６は、入力されたいずれかのイベントがルールに合致すれば、一致した変化パターンに対応する回数を１加算する。例えば、ルールヒット回数計数部１４６は、入力されたいずれかのイベントがルールテーブル１３１に記憶されたルールに合致するか否かを判定する。そして、ルールヒット回数計数部１４６は、入力されたいずれかのイベントがルールテーブル１３１に記憶されたルールに合致すると判定した場合、変化パターンテーブル２００の一致した変化パターンに対応するルールヒット回数２００ｃを１加算する。

また、ルールヒット回数計数部１４６は、一致した変化パターンに対応するルールヒット回数が所定の条件を満たす場合に、予想変化の変化パターンを、一致した変化パターンに置き換える。例えば、ルールヒット回数計数部１４６は、変化パターンテーブル２００に記憶された、一致した変化パターンに対応するルールヒット回数２００ｃおよび予想変化への採用条件２００ｄに基づいて、以下の処理を行う。ルールヒット回数計数部１４６は、ルールヒット回数２００ｃが予想変化への採用条件２００ｄを満たすか否かを判定する。そして、ルールヒット回数計数部１４６は、ルールヒット回数２００ｃが予想変化への採用条件２００ｄを満たすと判定した場合、予想変化の変化パターンを、一致した変化パターンに置き換える。すなわち、ルールヒット回数計数部１４６は、イベントの入力量が予想変化の変化パターンと一致しないが、別の変化パターンと一致し、かつ別の変化パターンに対応するルールヒット回数が十分多ければ、別の変化パターンを予想変化の変化パターンに繰り上げる。

［ＣＥＰシステムの具体的な処理の一例］
図１３は、実施例３に係るＣＥＰシステムの具体的な処理の一例を示す図である。図１３に示すように、情報処理装置１は、ＣＥＰエンジン３０が動作する。ＣＥＰエンジン３０は、制御部１４に含まれ、複合イベント処理を実現するソフトウェアである。複合イベント処理を実現するソフトウェアとしては、例えば、Ｅｓｐｅｒが挙げられる。

ここで、情報処理装置１には、予めユーザが設定したルールとして、「平均速度が５０ｋｍ／時以下、かつ、天気予報が雨」が設定されている。このルールに合致した場合のアクションとして、「渋滞発生可能性有」をレコメンド（提供）することが設定されている。

また、変化パターンテーブル２００は、ルールに合致すると予想される予想変化の変化パターンとして、１６：００〜１７：００に「自動車のデータ量が１０００件／秒を超過」が設定されている。加えて、１７：００〜１８：００に「自動車のデータ量が２０００件／秒超過」が設定されている。また、別の変化パターンとして、１６：００〜１７：００は予想変化と同様の内容であり、１７：００〜１８：００に「予想変化と不一致 自動車のデータ量が１５００件／秒超過」が設定されている。また、さらに別の変化パターンとして、１６：００〜１７：００は予想変化と同様の内容であり、１７：００〜１８：００に「予想変化と不一致 自動車のデータ量が１０００件／秒超過 かつ、１５００件／秒以下」が設定されている。

このような情報処理装置１では、入力部１４１が、現在のイベントを配信する入力源がルートＡである場合、ルートＡを走行中の自動車から自動車の状況のイベントおよび天気予報サイトからルートＡの局地天気のイベントを入力する。一方、情報処理装置１では、入力部１４１は、ルートＢを走行中の自動車から自動車の状況のイベントおよび天気予報サイトからルートＢの局地天気のイベントを入力しない。

そして、情報処理装置１では、第１の判定部１４２が、一定時間内に入力されたイベントの１秒当たりの入力量が、変化パターンテーブル２００に記憶された予想変化の変化パターンと一致するか否かを判定する。すなわち、第１の判定部１４２は、自動車の状況におけるイベントの１秒当たりの入力量が、１６：００〜１７：００に１０００件／秒を超過し、かつ、１７：００〜１８：００に２０００件／秒を超過したか否かを判定する。

そして、第２の判定部１４５は、第１の判定部１４２によって一定時間内に入力されたイベントの１秒当たりの入力量が予想変化の変化パターンと一致しないと判定された場合、以下の処理を行う。第２の判定部１４５は、当該入力量が変化パターンテーブル２００に記憶された別の変化パターンａ１、ａ２と一致するか否かを判定する。ここでは、第２の判定部１４５は、変化パターンａ１と一致したと判定する。すなわち、第２の判定部１４５は、自動車の状況におけるイベントの１秒当たりの入力量が、１６：００〜１７：００に１０００件／秒を超過し、かつ、１７：００〜１８：００に１５００件／秒を超過したと判定する。

そして、ルールヒット回数計数部１４６は、ルートＡから入力されたいずれかのイベントがルールに合致するか否かを判定し、合致すると判定した場合、変化パターンテーブル２００の一致した変化パターンに対応するルールヒット回数２００ｃを１加算する。ここでは、一致した変化パターンａ１に対応するルールヒット回数２００ｃが１加算され、２５回ヒット（ｂ１）が設定されている。

そして、ルールヒット回数計数部１４６は、一致した変化パターンａ１に対応するルールヒット回数２００ｃが予想変化への採用条件２００ｄを満たすか否かを判定し、満たすと判定した場合、予想変化の変化パターンを、一致した変化パターンに置き換える。ここでは、変化パターンａ１に対応するルールヒット回数２００が「２５回ヒット」であり、予想変化への採用条件２００ｄが「ルールヒット回数が２５回以上、かつ、予想変化のルールヒット回数以上」である。したがって、変化パターンａ１に対応するルールヒット回数２００が２５回以上を満たしている。また、予想変化のルールヒット回数２００ｃは「５回ヒット」であるので、変化パターンａ１に対応するルールヒット回数２００は予想変化のルールヒット回数以上を満たしている。よって、ルールヒット回数計数部１４６は、予想変化の変化パターンを、一致した変化パターンａ１に置き換える（ｃ１）。

このようにして、情報処理装置１は、予想変化の変化パターンと一致しなくても、別の変化パターンと一致し、さらに、ルールの合致回数が条件を満たせば、予想変化を別の変化パターンに置き換える。したがって、情報処理装置１は、ルールに合致すると予想される予想変化を動的に切り替えることができる。

［負荷軽減処理の手順］
次に、図１４Ａ，Ｂを参照して、負荷軽減処理の手順を説明する。図１４は、実施例３に係る負荷軽減処理のフローチャートを示す図である。なお、不一致動作テーブル１３３には、デフォルトルート１３３ａとしてルートＡが設定され、不一致時の動作１３３ｂとして入力源をルートＡからルートＢに変更することが設定されている。変化パターンテーブル２００には、予想変化の変化パターンが設定されている。また、変化パターンテーブル２００には、別の変化パターンが設定され、予想変化への採用条件２００ｄが「ルールにヒットした回数が２５回以上、かつ、予想変化のヒット回数以上」と設定されている。そして、入力部１４１は、デフォルトルート１３３ａに設定されたルートＡの入力源からイベントを入力している。さらに、図１０に示す負荷軽減処理の手順と同一の処理については同一符号を示すことで、その重複する処理の説明については簡略する。

まず、入力部１４１は、デフォルトルート１３３ａに設定されたルートＡの入力源からイベントを入力している。すると、第１の判定部１４２は、イベントの入力に関し、予想変化の変化パターンと不一致であるか否かを判定する（ステップＳ１１）。

イベントの入力に関し、予想変化の変化パターンと不一致でない、すなわち一致していると判定した場合（ステップＳ１１；Ｎｏ）、第１の判定部１４２は、一致回数をカウントすべく、ステップＳ１３に移行する。

一方、イベントの入力に関し、予想変化の変化パターンと不一致であると判定した場合（ステップＳ１１；Ｙｅｓ）、変更部１４３Ａは、ルートの自動選定に移行したか否かを判定する（ステップＳ１２Ａ）。ルートの自動選定に移行していないと判定した場合（ステップＳ１２Ａ；Ｎｏ）、変更部１４３Ａは、不一致時の動作１３３ｂに基づき、変更するルートを入力源に設定する（ステップＳ１２Ｃ）。そして、負荷軽減処理は、ステップＳ１３に移行する。その後、入力部１４１は、変更された入力源であるルートＢからイベントを入力する。

一方、ルートの自動選定に移行したと判定した場合（ステップＳ１２Ａ；Ｙｅｓ）、変更部１４３Ａは、変化パターンの一致回数の多いルート順に、ルートを入力源に設定する（ステップＳ１２Ｂ）。そして、変更部１４３Ａは、現在のデフォルトルートであるルートＡから、決定されたルートへ入力源を変更する。そして、負荷軽減処理は、ステップＳ１３に移行する。その後、入力部１４１は、変更された入力源であるルートＢからイベントを入力する。

ステップＳ１３では、パターン一致回数計数部１４４は、現在のルートの変化パターンの一致回数をカウントする（ステップＳ１３）。

続いて、ルールヒット回数計数部１４６は、ルールにヒット（合致）したか否かを判定する（ステップＳ２１）。ルールにヒットしたと判定した場合（ステップＳ２１；Ｙｅｓ）、ルールヒット回数計数部１４６は、ルールにヒットした変化パターンのルールヒット回数２００ｃに１だけ加算する（ステップＳ２２）。例えば、ルールヒット回数計数部１４６は、入力されたいずれかのイベントがルールテーブル１３１に記憶されたルールにヒットするか否かを判定する。そして、ルールヒット回数計数部１４６は、入力されたいずれかのイベントがルールテーブル１３１に記憶されたルールにヒットすると判定した場合、変化パターンテーブル２００の一致した変化パターンに対応するルールヒット回数２００ｃを１加算する。そして、ルールヒット回数計数部１４６は、ステップＳ２３に移行する。

一方、ルールにヒットしなかったと判定した場合（ステップＳ２１；Ｎｏ）、ルールヒット回数計数部１４６は、ステップＳ２３に移行する。

そして、ルールヒット回数計数部１４６は、予想変化への採用条件２００ｄを満たしている変化パターンが存在するか否かを判定する（ステップＳ２３）。予想変化への採用条件２００ｄを満たしている変化パターンが存在すると判定した場合（ステップＳ２３；Ｙｅｓ）、ルールヒット回数計数部１４６は、当該変化パターンを予想変化として採用する（ステップＳ２４）。そして、負荷軽減処理は、ステップＳ１１に移行する。

予想変化への採用条件２００ｄを満たしている変化パターンが存在しないと判定した場合（ステップＳ２３；Ｎｏ）、予想変化への採用条件２００ｄを満たしている変化パターンが存在すると判定した場合（ステップＳ２３；Ｙｅｓ）、ルールヒット回数計数部１４６は、何も処理しない。そして、負荷軽減処理は、ステップＳ１１に移行する。

［実施例３の効果］
上記実施例３によれば、情報処理装置１は、予想変化の変化パターンと一致しないと判定された場合に、変化パターンの閾値を変更した別の変化パターンと一致するか否かを判定する。そして、情報処理装置１は、別の変化パターンと一致すると判定された場合に、ルールに合致すれば、別の変化パターンに対応するルールヒット回数を１加算する。そして、情報処理装置１は、ルールヒット回数が所定の条件を満たす場合に、別の変化パターンを予想変化の変化パターンに置き換える。かかる構成によれば、情報処理装置１は、予想変化の変化パターンと一致しなくても、別の変化パターンと一致し、さらに、ルールの合致回数が条件を満たせば、予想変化を別の変化パターンに置き換える。したがって、情報処理装置１は、ルールに合致すると予想される予想変化を動的に切り替えることができる。

ところで、実施例１では、情報処理装置１は、入力されたイベントの１秒当たりの入力量が予想変化の変化パターンと一致しない場合に、予め設定された不一致時の動作１３３ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。実施例２では、情報処理装置１は、所定期間の中で、複数のイベント元毎に予想変化の変化パターンと一致した回数をカウントしておく。そして、情報処理装置１は、所定期間経過後、回数の大きいものから順番に自動的に変更先のイベント元を決定し、入力中のイベントのイベント元から決定したイベント元へ入力源を変更する。実施例３では、情報処理装置１は、入力量が予想変化の変化パターンと一致しなくても、別の変化パターンに一致し、且つルールに合致した回数が所定の条件を満たせば、予想変化の変化パターンを別の変化パターンに置き換える。しかしながら、情報処理装置１は、これに限定されず、さらに、ルールの合致に関与しないイベントの入力を抑止するようにしても良い。

そこで、実施例４では、情報処理装置１は、さらに、ルールの合致に関与しないイベントの入力を抑止する場合について説明する。

［実施例４に係るＣＥＰシステムの構成］
図１５は、実施例４に係る情報処理装置を含むＣＥＰシステムの全体構成を示す図である。なお、図１、図７および図１１に示すＣＥＰシステム９と同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例１〜３と実施例４とが異なるところは、制御部１４に基準イベント決定部１４７およびイベント入力抑止部１４８を追加した点にある。実施例１〜３と実施例４とが異なるところは、記憶部１３に基準イベント情報１３５を追加した点にある。

基準イベント情報１３５は、イベントの入力を抑止するか否かを選択するために用いられる基準となるイベント（「基準イベント」という）の情報である。例えば、基準イベントとして、入力量が少ないイベントの情報源が決定される。一例として、イベントの情報源として自動車の状況や天気予報が存在する場合、イベントの入力量が少ない天気予報の情報源が基準イベントとして決定される。なお、基準イベントは、基準イベント決定部１４７によって自動で決定されても良いし、予めユーザによって決定されても良い。

入力部１４１は、所定の情報を提供するために用いられるルールに関係する複数のイベントをイベント元の入力源から入力する。

基準イベント決定部１４７は、基準イベントを自動で判定する場合、イベントの入力量が最小のイベントの情報源を基準イベントとして決定する。例えば、基準イベント決定部１４７は、一定期間、各種情報源からイベントを入力し、それぞれイベントの入力量を算出する。そして、基準イベント決定部１４７は、入力量の最小のイベントの情報源を基準イベントとして決定する。一例として、天気予報の情報源からのイベントの入力量が１件／秒であり、自動車の情報源からのイベントの入力量が１５００件／秒であるとする。すると、基準イベント決定部１４７は、天気予報の入力量が自動車の入力量より小さいので、天気予報の情報源を基準イベントとして決定する。

イベント入力抑止部１４８は、基準イベントの内容がルールに合致しない内容である場合に、他のイベントの入力を抑止する。例えば、イベント入力抑止部１４８は、入力されるイベントの中の基準イベントがルールにアンヒットするか否かを判定する。そして、イベント入力抑止部１４８は、入力されるイベントの中の基準イベントがルールにアンヒットすると判定した場合、基準イベントと異なる他のイベントの入力を抑止する。

［ＣＥＰシステムの具体的な処理の一例］
図１６は、実施例４に係るＣＥＰシステムの具体的な処理の一例を示す図である。図１６に示すように、情報処理装置１は、ＣＥＰエンジン３０が動作する。ＣＥＰエンジン３０は、制御部１４に含まれ、複合イベント処理を実現するソフトウェアである。複合イベント処理を実現するソフトウェアとしては、例えば、Ｅｓｐｅｒが挙げられる。

ここで、情報処理装置１には、予めユーザが設定したルールとして、「平均速度が５０ｋｍ／時以下、かつ、天気予報が雨」が設定されている。このルールに合致した場合のアクションとして、「渋滞発生可能性有」をレコメンド（提供）することが設定されている。

また、基準イベント情報１３５には、基準イベントとして「天気予報」が設定されている。

このような情報処理装置１では、入力部１４１が、現在のイベントを配信する入力源がルートＡである場合、ルートＡを走行中の自動車（情報源）から自動車の状況のイベントおよび天気予報の情報源からルートＡの天気予報のイベントを入力する。一方、情報処理装置１では、入力部１４１は、ルートＢを走行中の自動車から自動車の状況のイベントおよびルートＢの天気予報のイベントを入力しない。

そして、イベント入力抑止部１４８が、入力されるイベントの中の基準イベントがルールにアンヒットするか否かを判定する。ここでは、入力される基準イベントである天気予報の内容が「晴れ」であるとする。すると、イベント入力抑止部１４８は、ルールの一部である「天気予報が雨」にヒットしないので、アンヒットすると判定する。

そして、イベント入力抑止部１４８は、基準イベントがルールにアンヒットすると判定した場合、基準イベントと異なる他のイベントの入力を抑止する。ここでは、イベント入力抑止部１４８は、自動車の状況のイベントの入力を抑止する。

このようにして、情報処理装置１は、予めルールに合致しないイベントがあることがわかった段階で、イベントの入力を抑止するので、さらに、複合イベント処理の負荷を軽減することができる。

［負荷軽減処理の手順］
次に、図１７Ａ〜Ｃを参照して、負荷軽減処理の手順を説明する。図１７Ａ〜Ｃは、実施例４に係る負荷軽減処理のフローチャートを示す図である。なお、不一致動作テーブル１３３には、デフォルトルート１３３ａとしてルートＡが設定され、不一致時の動作１３３ｂとして入力源をルートＡからルートＢに変更することが設定されている。変化パターンテーブル２００には、予想変化の変化パターンが設定されている。また、変化パターンテーブル２００には、別の変化パターンが設定され、予想変化への採用条件２００ｄが「ルールにヒットした回数が２５回以上、かつ、予想変化のヒット回数以上」と設定されている。そして、入力部１４１は、デフォルトルート１３３ａに設定されたルートＡの入力源からイベントを入力している。また、基準イベント情報１３５には、基準イベントとして「天気予報」が設定されている。さらに、なお、Ｓ１１からＳ２４までは、実施例３に係る負荷軽減処理と同一の処理であるので、その処理の説明を簡略する。

まず、基準イベント決定部１４７は、基準イベントが「自動判定」かついずれかのイベントの入力が停止（抑止）されていないか否かを判定する（ステップＳ３１）。基準イベントが「自動判定」でない、またはいずれかのイベントの入力が停止になっていると判定した場合（ステップＳ３１；Ｎｏ）、基準イベント決定部１４７は、ステップＳ３３に移行する。

一方、基準イベントが「自動判定」かついずれかのイベントの入力が停止（抑止）されていると判定した場合（ステップＳ３１；Ｙｅｓ）、基準イベント決定部１４７は、イベントの入力量が最小の情報源を基準イベントに決定する（ステップＳ３２）。そして、基準イベント決定部１４７は、決定した基準イベントを基準イベント情報１３５に設定する。そして、基準イベント決定部１４７は、ステップＳ３３に移行する。

そして、イベント入力抑止部１４８は、基準イベントがルールにアンヒットするか否かを判定する（ステップＳ３３）。基準イベントがルールにアンヒットすると判定した場合（ステップＳ３３；Ｙｅｓ）、イベント入力抑止部１４８は、情報源ルートからのイベントの入力を停止する（ステップＳ３４）。例えば、イベント入力抑止部１４８は、ルートＡから入力されているイベントについて、基準イベントと異なる他のイベントの入力を停止する。そして、イベント入力抑止部１４８は、ルートの変更を判定しないで、ステップＳ３１に移行する。

一方、基準イベントがルールにヒットすると判定した場合（ステップＳ３３；Ｎｏ）、イベント入力抑止部１４８は、情報源ルートからのイベントの入力を開始する（ステップＳ３５）。例えば、イベント入力抑止部１４８は、ルートＡから入力されているイベントについて、基準イベントと異なる他のイベントの入力を開始する。そして、イベント入力抑止部１４８は、ルートの変更を判定すべく、ステップＳ１１に移行する。

続いて、入力部１４１は、デフォルトルート１３３ａに設定されたルートＡの入力源からイベントを入力している。すると、第１の判定部１４２は、イベントの入力に関し、予想変化の変化パターンと不一致であるか否かを判定する（ステップＳ１１）。

イベントの入力に関し、予想変化の変化パターンと不一致でない、すなわち一致していると判定した場合（ステップＳ１１；Ｎｏ）、第１の判定部１４２は、一致回数をカウントすべく、ステップＳ１３に移行する。

一方、イベントの入力に関し、予想変化の変化パターンと不一致であると判定した場合（ステップＳ１１；Ｙｅｓ）、変更部１４３Ａは、ルートの自動選定に移行したか否かを判定する（ステップＳ１２Ａ）。ルートの自動選定に移行していないと判定した場合（ステップＳ１２Ａ；Ｎｏ）、変更部１４３Ａは、不一致時の動作１３３ｂに基づき、変更するルートを入力源に設定する（ステップＳ１２Ｃ）。そして、負荷軽減処理は、ステップＳ１３に移行する。その後、入力部１４１は、変更された入力源であるルートＢからイベントを入力する。

一方、ルートの自動選定に移行したと判定した場合（ステップＳ１２Ａ；Ｙｅｓ）、変更部１４３Ａは、変化パターンの一致回数の多いルート順に、ルートを入力源に設定する（ステップＳ１２Ｂ）。そして、変更部１４３Ａは、現在のデフォルトルートであるルートＡから、決定されたルートへ入力源を変更する。そして、負荷軽減処理は、ステップＳ１３に移行する。その後、入力部１４１は、変更された入力源であるルートＢからイベントを入力する。

ステップＳ１３では、パターン一致回数計数部１４４は、現在のルートの変化パターンの一致回数をカウントする（ステップＳ１３）。

続いて、ルールヒット回数計数部１４６は、ルールにヒット（合致）したか否かを判定する（ステップＳ２１）。ルールにヒットしたと判定した場合（ステップＳ２１；Ｙｅｓ）、ルールヒット回数計数部１４６は、ルールにヒットした変化パターンのルールヒット回数２００ｃに１だけ加算する（ステップＳ２２）。そして、ルールヒット回数計数部１４６は、ステップＳ２３に移行する。

一方、ルールにヒットしなかったと判定した場合（ステップＳ２１；Ｎｏ）、ルールヒット回数計数部１４６は、ステップＳ２３に移行する。

そして、ルールヒット回数計数部１４６は、予想変化への採用条件２００ｄを満たしている変化パターンが存在するか否かを判定する（ステップＳ２３）。予想変化への採用条件２００ｄを満たしている変化パターンが存在すると判定した場合（ステップＳ２３；Ｙｅｓ）、ルールヒット回数計数部１４６は、当該変化パターンを予想変化として採用する（ステップＳ２４）。そして、負荷軽減処理は、ステップＳ３１に移行する。

予想変化への採用条件２００ｄを満たしている変化パターンが存在しないと判定した場合（ステップＳ２３；Ｎｏ）、予想変化への採用条件２００ｄを満たしている変化パターンが存在すると判定した場合（ステップＳ２３；Ｙｅｓ）、ルールヒット回数計数部１４６は、何も処理しない。そして、負荷軽減処理は、ステップＳ３１に移行する。

［実施例４の効果］
上記実施例４によれば、情報処理装置１は、ルールに関係する複数のイベントをイベント元の入力源から入力する。そして、情報処理装置１は、複数のイベントのうちいずれか１つのイベントである基準イベントの内容がルールに合致しない内容である場合に、他のイベントの入力を抑止する。かかる構成によれば、情報処理装置１は、基準イベントがルールに合致しないことがわかった段階で、他のイベントの入力を抑止するので、さらに、複合イベント処理の負荷を軽減することができる。

［プログラムなど］
なお、上記実施例では、ＣＥＰシステム９を自動車の渋滞発生の予測に用いる場合について説明した。しかしながら、ＣＥＰシステム９は、これに限定されず、別の用途に用いる場合であっても良い。例えば、ＣＥＰシステム９をレンタル割引クーポンのサービス提示に用いる場合であっても良い。かかる場合に、ＣＥＰシステム９のルールが「コンビニエンスストアで「ａ」と「ｂ」を購入し、かつ、レンタルストアでレンタル割引キャンペーンを行っている場合」であり、提供情報が「レンタルストアのレンタルクーポン」であるとする。すると、入力部１４１は、所定の情報を提供するために用いられるルールに関係するイベントをイベント元の入力源から入力する。ここでは、入力部１４１は、デフォルトルートがＡ地域である場合、Ａ地域のコンビニエンスストアからの買物情報のイベント、レンタルストアからのレンタル割引キャンペーン情報のイベントを入力すれば良い。そして、第１の判定部１４２は、一定時間内に入力されたイベントの１秒当たりの入力量が、予想変化の変化パターンと一致するか否かを判定する。変更部１４３は、第１の判定部１４２によって予想変化の変化パターンと一致しないと判定された場合に、不一致時の動作１３３ｂに基づいて、入力中のイベントのイベント元から他のイベント元へ入力源を変更する。ここでは、不一致時の動作１３３ｂが「Ａ地域からＢ地域に変更」であるとする。すると、変更部１４３は、Ａ地域のコンビニエンスストアからの買物情報のイベントの入力量が予想変化の変化パターンと一致しなければ、不一致時の動作１３３ｂに基づいて、Ａ地域からＢ地域へ入力源を変更すれば良い。また、レンタルストアからのレンタル割引キャンペーン情報のイベントを、基準イベント情報とすれば良い。かかる場合であっても、ＣＥＰシステム９は、全ての入力源からのイベントの入力を回避でき、複合イベント処理の負荷を軽減できる。

また、情報処理装置１は、既知のパーソナルコンピュータ、ワークステーションなどの情報処理装置に、上記した制御部１４および記憶部１３などの各機能を搭載することによって実現することができる。

また、図示した装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、第１の判定部１４２と第２の判定部１４５とを１個の判定部として統合しても良い。一方、変更部１４３Ａを、不一致時の動作１３３ｂに基づいて入力源を変更する第１の変更部と、一致回数に基づいて入力源を変更する第２の変更部とに分散しても良い。また、ルールテーブル１３１、変化パターンテーブル１３２などを情報処理装置１の外部装置としてネットワーク経由で接続するようにしても良い。

また、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１、７、１１、１５に示した情報処理装置１と同様の機能を実現する負荷軽減プログラムを実行するコンピュータの一例を説明する。図１８は、負荷軽減プログラムを実行するコンピュータの一例を示す図である。

図１８に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ２０３と、ユーザからのデータの入力を受け付ける入力装置２１５と、表示装置２０９を制御する表示制御部２０７とを有する。また、コンピュータ２００は、記憶媒体からプログラムなどを読取るドライブ装置２１３と、ネットワークを介して他のコンピュータとの間でデータの授受を行う通信制御部２１７とを有する。また、コンピュータ２００は、各種情報を一時記憶するメモリ２０１と、ＨＤＤ２０５を有する。そして、メモリ２０１、ＣＰＵ２０３、ＨＤＤ２０５、表示制御部２０７、ドライブ装置２１３、入力装置２１５、通信制御部２１７は、バス２１９で接続されている。

ドライブ装置２１３は、例えばリムーバブルディスク２１１用の装置である。ＨＤＤ２０５は、負荷軽減プログラム２０５ａおよび負荷軽減処理関連情報２０５ｂを記憶する。

ＣＰＵ２０３は、負荷軽減プログラム２０５ａを読み出して、メモリ２０１に展開し、プロセスとして実行する。かかるプロセスは、情報処理装置１の各機能部に対応する。負荷軽減処理関連情報２０５ｂは、ルールテーブル１３１、変化パターンテーブル１３２、不一致動作テーブル１３３、パターン一致回数テーブル１３４および基準イベント情報１３５に対応する。そして、例えばリムーバブルディスク２１１が、負荷軽減プログラム２０５ａなどの各情報を記憶する。

なお、負荷軽減プログラム２０５ａについては、必ずしも最初からＨＤＤ２０５に記憶させておかなくても良い。例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に当該プログラムを記憶させておく。そして、コンピュータ２００がこれらから負荷軽減プログラム２０５ａを読み出して実行するようにしても良い。

１ 情報処理装置
２ 制御サーバ
９ ＣＥＰシステム
１１，１２ 通信制御Ｉ／Ｆ部
１３ 記憶部
１３１ ルールテーブル
１３２ 変化パターンテーブル
１３３ 不一致動作テーブル
１３４ パターン一致回数テーブル
１３５ 基準イベント情報
１４ 制御部
１４１ 入力部
１４２ 第１の判定部
１４３，１４３Ａ 変更部
１４４ パターン一致回数計数部
１４５ 第２の判定部
１４６ ルールヒット回数計数部
１４７ 基準イベント決定部
１４８ イベント入力抑止部

Claims (7)

1. 所定の情報を提供するために用いられるルールに関係するイベントをイベント元の入力源から入力し、
   一定期間内に入力されたイベントの単位期間当たりの入力量に、前記ルールに合致すると予想される変化があるか否かを判定し、
   変化がないと判定された場合に、入力中のイベントのイベント元から他のイベント元へ前記入力源を変更する
   処理をコンピュータに実行させることを特徴とする負荷軽減プログラム。
2. 前記判定する処理は、一定期間内に入力されたイベントの単位期間当たりの入力量が所定の閾値を超えることを示す予想変化と一致するか否かを判定し、
   一致しないと判定された場合に、入力中のイベントのイベント元から他のイベント元へ前記入力源を変更する
   処理を実行させることを特徴とする請求項１に記載の負荷軽減プログラム。
3. 複数のイベント元毎に、所定期間の中で、前記変化があった回数をカウントし、
   前記入力源を変更する処理は、カウントされた回数の大きい数に対応するイベント元から小さい数に対応するイベント元へ順番に変更先のイベント元を決定し、入力中のイベントのイベント元から決定したイベント元へ前記入力源を変更する
   処理を実行させることを特徴とする請求項２に記載の負荷軽減プログラム。
4. 前記予想変化と一致しないと判定された場合に、前記予想変化の閾値を変更した変化パターンと一致するか否かを判定し、
   前記変化パターンと一致すると判定された場合に、前記ルールに合致すれば、前記変化パターンに対応する回数を１加算し、
   前記回数が所定の条件を満たす場合に、前記変化パターンを前記予想変化として設定する
   処理を実行させることを特徴とする請求項２または請求項３に記載の負荷軽減プログラム。
5. 前記入力する処理は、前記ルールに関係する複数のイベントをイベント元の入力源から入力し、
   前記複数のイベントのうちいずれか１つのイベントである基準イベントの内容が前記ルールに合致しない内容である場合に、他のイベントの入力を抑止する
   処理を実行させることを特徴とする請求項１から請求項４のいずれか１つに記載の負荷軽減プログラム。
6. 所定の情報を提供するために用いられるルールに関係するイベントをイベント元の入力源から入力する入力部と、
   前記入力部によって一定期間内に入力されたイベントの単位期間当たりの入力量に、前記ルールに合致すると予想される変化があるか否かを判定する判定部と、
   変化がないと判定された場合に、入力中のイベントのイベント元から他のイベント元へ前記入力源を変更する変更部と、
   を有することを特徴とする情報処理装置。
7. コンピュータが、
   所定の情報を提供するために用いられるルールに関係するイベントをイベント元の入力源から入力し、
   一定期間内に入力されたイベントの単位期間当たりの入力量に、前記ルールに合致すると予想される変化があるか否かを判定し、
   変化がないと判定された場合に、入力中のイベントのイベント元から他のイベント元へ前記入力源を変更する
   各処理を実行することを特徴とする負荷軽減方法。

Images