(57)【要約】ルール分配サーバは、イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドＮＷのＩＤを算出し、アプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドＮＷで発生する場合、該ルールを該フロントエンドＮＷの処理サーバに登録し、発生しない場合、該ルールをバックエンド処理サーバに登録すると決定し、バックエンド処理サーバに登録するルールについてイベント条件毎に該イベント条件に合致するイベントが発生するフロントエンド処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送するルールを生成し、アプリルールと転送ルールを処理サーバに登録する。
2014065115.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションサーバからイベント処理に関するルールの登録を受けて、イベント発生源が接続されるフロントエンドネットワークに接続されたフロントエンド処理サーバとバックエンドネットワークに接続されたバックエンド処理サーバにルールを配置するルール分配サーバであって、
イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出するイベント発生元ネットワーク解決部と、
アプリケーションから登録されたアプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに接続される処理サーバに登録し、発生しない場合、該アプリルールをバックエンド処理サーバに登録すると決定するアプリルール配置先決定部と、
前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンド処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成するルール生成部と、
アプリルールとルール生成部で生成した転送ルールをそれぞれ対応する処理サーバに登録するルール登録部と
を備えるルール分配サーバ。
【請求項２】
アプリルールの内容から処理ルールがフロントエンド処理サーバに登録可能かどうかを判定するルール登録可否判定部をさらに備え、
前記ルール生成部は、前記ルール登録可否判定部で、アプリルールが登録可能と判定され、かつ、各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合には、該アプリルールを該フロントエンドネットワークに登録する
請求項１に記載のルール分配サーバ。
【請求項３】
前記ルール生成部は、
アプリルールに、時間幅ｔの間に発生するイベントを処理対象とするような時間幅ｔが指定されるときに、該時間幅が所定値以下であれば、該アプリルールをフロントエンド処理サーバに登録可とし、
該時間幅が所定値以下でなければ、該アプリルールが複数のイベントの統計値を算出する処理かどうかを判定し、統計値を算出する処理でなければ、該アプリルールを登録不可とし、
統計値を算出する処理であれば、該アプリルールで指定される処理が、デバイスから発生する各イベントに対して、該イベントが発生した時刻から過去時間幅ｔの間に発生したイベントに対して処理を行うスライディングウィンドウ処理か、イベントの発生時刻によらず、所定の時刻から時間幅ｔの間に発生したイベントに対して処理を行う固定ウィンドウ処理かを判定し、固定ウィンドウ処理であれば、該アプリルールを登録可とし、スライディングウィンドウ処理であれば、該アプリルールを登録不可とする
請求項２のルール分配サーバ。
【請求項４】
バックエンド処理サーバが受信したイベントの情報を取得し、イベント発生元ネットワーク解決表を生成するイベント発生元ネットワーク検出部をさらに備え、
前記イベント発生元ネットワーク検出部は、属性の集合のべき集合の各要素にあたる属性値と、受信したイベントが、その要素の全ての属性値と一致した場合に、該要素と、該イベントの発生元ネットワークのＩＤとで特定される計数値に１を加算し、所定値以上の前記要素と前記イベントの発生元ネットワークのＩＤとで特定される計数値について、当該要素と当該発生元ネットワークのＩＤ以外のネットワークのＩＤとで特定される計数値のいずれもが０である場合、属性値条件を該要素とし、それ以外の属性値条件を任意の値とするイベント条件を生成し、生成したイベント条件と、前記発生元ネットワークＩＤとのペアをイベント発生元ネットワーク解決表に追加する
請求項１から３のいずれかに記載のルール分配サーバ。
【請求項５】
前記ルール生成部は、アプリルールをフロントエンド処理サーバに登録するときに、該アプリルールの処理に必要なイベントを該フロントエンド処理サーバに転送する転送ルールを生成し、該フロンエンド処理サーバ以外のフロントエンド処理サーバに登録する
請求項１から４のいずれかに記載のルール分配サーバ。
【請求項６】
イベント発生元ネットワーク解決表の変更を基にルールの再配置を行うルール再配置部をさらに備え、
前記ルール再配置部は、イベント発生元ネットワーク解決表が変更されると、バックエンド処理サーバをターゲット処理サーバとし、該変更が既存のイベント条件に対応するイベント発生元ネットワークＩＤの変更である場合、さらに、変更前のイベント発生元ネットワークＩＤに対応する処理サーバをターゲット処理サーバとし、
前記アプリルール配置先決定部とルール生成部は、ターゲット処理サーバが保持するアプリルールに対して、転送ルールの生成と、該アプリルールと生成した転送ルールの配置先の算出を行い、
前記ルール再配置部は、前記算出結果が、イベント発生元ネットワーク解決表の更新前の内容と異なる場合、該アプリルールが登録されている処理サーバから該アプリルールに対するステートを取得し、該アプリルールとそれに対するステートと転送ルールとを、それを保持している処理サーバから削除し、新たに生成したルール配置表のルールを、対応するネットワークの処理サーバに配置し、アプリルールの配置においては取得したステートを共に配置する
請求項５に記載のルール分配サーバ。
【請求項７】
イベント発生源が接続するフロントエンドネットワークに接続されるフロントエンド処理サーバと、各フロントエンドネットワークの処理サーバから収集したイベントを処理するバックエンド処理サーバと、アプリケーションから登録されるアプリルールから各処理サーバに登録する転送ルールを生成し、該アプリルールと生成した転送ルールを処理サーバに配置するルール分配サーバと、を備え、
前記ルール分配サーバは、
イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出するイベント発生元ネットワーク解決部と、
アプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに登録し、そうでない場合、該アプリルールをバックエンド処理サーバに登録すると決定するアプリルール配置先決定部と、
前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンドネットワークに接続された処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成するルール生成部と、
アプリルールとルール生成部で生成した転送ルールを処理サーバに登録するルール登録部と
を備えるイベント処理システム。
【請求項８】
アプリケーションサーバからイベント処理に関するルールの登録を受けて、イベント発生源が接続されるフロントエンドネットワークに接続されたフロントエンド処理サーバとバックエンドネットワークに接続されたバックエンド処理サーバにルールを配置するルール分配方法であって、
イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出し、
アプリケーションから登録されたアプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに接続される処理サーバに登録し、発生しない場合、該アプリルールをバックエンド処理サーバに登録すると決定し、
前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンド処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成し、
前記生成した転送ルールをそれぞれ対応する処理サーバに登録する
ルール分配方法。
【請求項９】
イベント発生源が接続されるフロントエンドネットワークに接続されたフロントエンド処理サーバとバックエンドネットワークに接続されたバックエンド処理サーバに接続されたコンピュータに、
イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出する処理、
アプリケーションから登録されたアプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに接続される処理サーバに登録し、発生しない場合、該アプリルールをバックエンド処理サーバに登録すると決定するアプリルール配置先決定処理、
前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンド処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成するルール生成処理、
前記生成した転送ルールをそれぞれ対応する処理サーバに登録するルール登録処理
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多数のデバイスから発生する大量のデータ（イベント）を処理するイベント処理システムに関する。
【背景技術】
【０００２】
アプリケーションサーバから登録されたイベントの処理条件（処理ルール）に従ってイベントを処理するイベント処理システムが考案されている。例えば特許文献１のイベント処理システムでは、処理ルールに従って処理するために、ローカルシステムへ転送すべきイベントの条件（外部ディスパッチルール）を全ての外部ディスパッチャに登録する。これにより、どのようなイベントがどのイベント発生源から発生しても、そのイベントを処理対象とするローカルシステムへ、外部ディスパッチャを介して転送される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開第２０１０／１０７１０７号
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、特許文献１のシステムでは、イベント発生源の数が膨大となり、各イベント発生源から発生するイベント数が多くなると、外部ディスパッチャとローカルシステムの間のネットワークを流れるデータ量が多くなる。それによって、流れるデータ量がネットワークの収容能力を超え、ローカルシステムへ転送されるべきイベントを全て送信することができなくなってしまう。【０００５】
本発明は、上記問題点に鑑みてなされたもので、各イベント発生源から発生するイベント数が多くなっても、ネットワークを流れるデータ量の増大を抑制することができるルール分配サーバ、イベント処理システム、方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、アプリケーションサーバからイベント処理に関するルールの登録を受けて、イベント発生源が接続されるフロントエンドネットワークに接続されたフロントエンド処理サーバとバックエンドネットワークに接続されたバックエンド処理サーバにルールを配置するルール分配サーバであって、イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出するイベント発生元ネットワーク解決部と、アプリケーションから登録されたアプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに接続される処理サーバに登録し、発生しない場合、該アプリルールをバックエンド処理サーバに登録すると決定するアプリルール配置先決定部と、前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンド処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成するルール生成部と、アプリルールとルール生成部で生成した転送ルールをそれぞれ対応する処理サーバに登録するルール登録部とを備えるルール分配サーバである。【０００７】
本発明は、イベント発生源が接続するフロントエンドネットワークに接続されるフロントエンド処理サーバと、各フロントエンドネットワークの処理サーバから収集したイベントを処理するバックエンド処理サーバと、アプリケーションから登録されるアプリルールから各処理サーバに登録する転送ルールを生成し、該アプリルールと生成した転送ルールを処理サーバに配置するルール分配サーバと、を備え、前記ルール分配サーバは、イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出するイベント発生元ネットワーク解決部と、アプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに登録し、そうでない場合、該アプリルールをバックエンド処理サーバに登録すると決定するアプリルール配置先決定部と、前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンドネットワークに接続された処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成するルール生成部と、アプリルールとルール生成部で生成した転送ルールを処理サーバに登録するルール登録部とを備えるイベント処理システムである。【０００８】
本発明は、アプリケーションサーバからイベント処理に関するルールの登録を受けて、イベント発生源が接続されるフロントエンドネットワークに接続されたフロントエンド処理サーバとバックエンドネットワークに接続されたバックエンド処理サーバにルールを配置するルール分配方法であって、イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出し、アプリケーションから登録されたアプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに接続される処理サーバに登録し、発生しない場合、該アプリルールをバックエンド処理サーバに登録すると決定し、前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンド処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成し、前記生成した転送ルールをそれぞれ対応する処理サーバに登録するルール分配方法である。【０００９】
本発明は、イベント発生源が接続されるフロントエンドネットワークに接続されたフロントエンド処理サーバとバックエンドネットワークに接続されたバックエンド処理サーバに接続されたコンピュータに、イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出する処理、アプリケーションから登録されたアプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに接続される処理サーバに登録し、発生しない場合、該アプリルールをバックエンド処理サーバに登録すると決定するアプリルール配置先決定処理、前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンド処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成するルール生成処理、前記生成した転送ルールをそれぞれ対応する処理サーバに登録するルール登録処理を実行させるプログラムである。
【発明の効果】
【００１０】
本発明によれば、各イベント発生源から発生するイベント数が多くなっても、ネットワークを流れるデータ量の増大を抑制することができる。
【図面の簡単な説明】
【００１１】
【図１】図１は本発明の第１の実施形態に係るイベント処理システムの構成を例示する図である。
【図２】図２は第１の実施形態に係るイベント処理システムにおける処理の流れを示す図である。
【図３】図３は第１の実施形態のルール分配サーバの構成を示す図である。
【図４】図４は第１の実施形態のアプリルール配置先決定部の動作を説明するためのフローチャートである。
【図５】図５は第１の実施形態のルール生成部の動作を説明するためのフローチャートである。
【図６】図６は第１の実施形態のルール登録部の動作を説明するためのフローチャートである。
【図７】図７は第１の実施形態に係るイベント処理システムの動作を具体例を用いて説明するための図である。
【図８】図８は店舗Ａ在庫管理サーバから発生するイベントを例示する図である。
【図９】図９は従業員００１携帯端末から発生するイベントを例示する図である。
【図１０】図１０はＤＣ１在庫管理サーバから発生するイベントを例示する図である。
【図１１】図１１はルールを例示する図である。
【図１２】図１２はルールを例示する図である。
【図１３】図１３はイベント発生元ＮＷ解決表を例示する図である。
【図１４】図１４はイベント条件−ＮＷＩＤ表を例示する図である。
【図１５】図１５はルール配置表を例示する図である。
【図１６】図１６はイベント条件−ＮＷＩＤ表を例示する図である。
【図１７】図１７はルール配置表を例示する図である。
【図１８】図１８は第２の実施形態におけるルール分配サーバの構成を示す図である。
【図１９】図１９は第２の実施形態のルール生成部の動作を説明するためのフローチャートである。
【図２０】図２０は第２の実施形態のルール登録可否判定部の動作を説明するためのフローチャートである。
【図２１】図２１は第３の実施形態におけるルール分配サーバの構成を示す図である。
【図２２】図２２は第３の実施形態におけるイベント発生元ＮＷ検出部の構成を示す図である。
【図２３】図２３は出現回数表を例示する図である。
【図２４】図２４はイベント発生元ＮＷ解決表を例示する図である。
【図２５】図２５は第４の実施形態におけるルール分配サーバの構成を示す図である。
【図２６】図２６は第４の実施形態におけるルール生成部の動作を説明するためのフローチャートである。
【図２７】図２７は第４の実施形態におけるルール再配置部の動作を説明するためのフローチャートである。
【図２８】図２８は第４の実施形態に係るイベント処理システムの動作を具体例を用いて説明するための図である。
【図２９】図２９は出現回数表を例示する図である。
【図３０】図３０はルール配置表を例示する図である。
【図３１】図３１はイベント発生元ＮＷ解決表を例示する図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態について図面を参照して説明する。
【００１３】
（第１の実施形態）
本発明の第１の実施形態に係るイベント処理システムの構成を図１に示す。本実施形態に係るのイベント処理システムは、フロントエンド処理サーバ１０と、バックエンド処理サーバ２０と、ルール分配サーバ３０を備え、これらはネットワーク（ＮＷ）を介して接続される。各処理サーバ（フロントエンド処理サーバ１０、バックエンド処理サーバ２０）が接続されているネットワークはネットワークＩＤ（ＮＷＩＤ）により識別できる。
【００１４】
フロントエンド処理サーバ１０は、イベント発生源である各デバイスが接続するネットワーク（フロントエンドＮＷ）に接続される処理サーバである。バックエンド処理サーバ２０は、各フロントエンド処理サーバ１０から収集したイベントを処理する処理サーバである。ルール分配サーバ３０は、ネットワークを介して接続されるアプリケーションサーバのアプリケーションにより、イベントの処理ルール（アプリルール）の登録を受ける。ルール分配サーバ３０は、アプリケーションから登録されたイベントの処理ルール（アプリルール）から、各処理サーバに登録する処理ルール（転送ルール）を生成し、該アプリルールと生成した転送ルールを対応する各処理サーバに配置する。
【００１５】
本イベント処理システムでは、図２に示すように、アプリケーションからアプリルールが登録されると、ルール分配サーバ３０が各フロントエンド処理サーバ１０へ登録する転送ルールを生成し、各フロントエンド処理サーバ１０と各バックエンド処理サーバ２０へ、アプリルールと生成した転送ルールを登録する。
【００１６】
ルール分配サーバ３０の構成を図３に示す。ルール分配サーバ３０は、イベント発生元ＮＷ解決部３１と、アプリルール配置先決定部３２と、ルール生成部３３と、ルール登録部３４を備える。
【００１７】
イベント発生元ＮＷ解決部３１は、イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出する。この算出は、例えば、イベント条件と、該イベント条件に合致するイベントが発生するフロントエンドＮＷのＩＤとのペアが格納されたイベント発生元ＮＷ解決表を参照して行う。イベント発生元ＮＷ解決表はルール分配サーバ３０が保持してもよく、ネットワークに接続された他のサーバが保持してもよい。アプリルール配置先決定部３２は、アプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドＮＷで発生するかを判別し、発生する場合、そのアプリルールをそのフロントエンドＮＷのフロントエンド処理サーバ１０に登録し、そうでない場合、該アプリルールをバックエンド処理サーバ２０に登録すると決定する。ルール生成部３３は、バックエンド処理サーバ２０に登録すると決定したルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンドＮＷに接続されたフロントエンド処理サーバ１０を登録先として、イベント条件に合致するイベントをバックエンド処理サーバ２０に転送する処理ルールを生成する。ルール登録部３４は、アプリルールとルール生成部３３で生成した転送ルールをそれぞれ対応するバックエンド処理サーバ２０とフロントエンド処理サーバ１０に登録する。
【００１８】
アプリルール配置先決定部３２の動作を図４のフローチャートを参照して説明する。
【００１９】
アプリルール配置先決定部３２は、アプリルールを受信すると（Ｓ４−１）、まずイベント条件と該イベント条件に合致するイベントが発生するネットワークのＩＤとのペアを保持するための空のイベント条件−ＮＷＩＤ表を生成する（Ｓ４−２）。該アプリルールで指定されるイベント条件Ｃごとに、イベント発生元ＮＷ解決表を参照し、イベント条件Ｃを包含しているイベント条件を検索する（Ｓ４−３、４−４）。該当するイベント条件がイベント発生元ＮＷ解決表にある場合（Ｓ４−５）、検索したイベント条件に対応するフロントエンドＮＷＩＤをイベント条件Ｃと対応付けてイベント条件−ＮＷＩＤ表に追加する（Ｓ４−６）。該当するイベント条件がない場合、バックエンド処理サーバ２０が接続されているバックエンドネットワーク（バックエンドＮＷ）のＩＤ（バックエンドＮＷＩＤ）をイベント条件Ｃと対応づけてイベント条件−ＮＷＩＤ表に追加する（Ｓ４−７）。
【００２０】
アプリルール配置先決定部３２は、全てのイベント条件について上記処理を実施後、ルールと該ルールの登録先のネットワークのＩＤとのペアを保持するための空のルール配置表を生成する（Ｓ４−８）。イベント条件−ＮＷＩＤ表のＮＷＩＤが全て同じ場合（Ｓ４−９）、該ＮＷＩＤを該アプリルールの登録先として該ルール配置表に追加する（Ｓ４−１０）。それ以外の場合、バックエンドＮＷＩＤを該アプリルールの登録先として該ルール配置表に追加する（Ｓ４−１１）。
【００２１】
次に、ルール生成部３３の動作を図５のフローチャートを参照して説明する。
【００２２】
ルール生成部３３は、アプリルール配置先決定部３２で生成したイベント条件−ＮＷＩＤ表のＮＷＩＤが全て同じでない場合（Ｓ５−１）、各イベント条件に対して、そのイベント条件に合致するイベントをバックエンドＮＷに接続される処理サーバへ転送する転送ルールを生成し（Ｓ５−２）、各イベント条件に対応して生成した転送ルールとそのイベント条件に対応するＮＷＩＤのペアをルール配置表に追加する（Ｓ５−３）。
【００２３】
次に、ルール登録部３４の動作を図６のフローチャートを参照して説明する。
【００２４】
ルール登録部３４は、ルール配置表の各ルールをそれに対応するＮＷＩＤで特定されるネットワークに配置されるサーバに登録する（Ｓ６−１）。ＮＷＩＤから処理サーバのアドレスを解決することは、例えば、バックエンドＮＷＩＤとそのバックエンドＮＷに配置されている処理サーバのＩＤを対応づける表（図示せず）を保持しておき、それを参照することでできる。
【００２５】
ルールを削除する場合の処理について説明する。例えばルール生成部３３は、ルール登録時に生成したルール配置表を保持部（図示せず）に保持する。ルールの削除要求があった場合、アプリケーションから指定されたルールＩＤのルールが記述されるルール配置表を特定し、該ルール配置表に記述される各ルールを、該ルールを保持している処理サーバから削除する。
【００２６】
次に、第１の実施形態に係るイベント処理システムの動作を具体例を用いて説明する。この例では、図７に示すように、フロントエンドＮＷ「店舗Ａ-ＮＷ」に、フロントエンド処理サーバ１０「店舗Ａ処理サーバ」と、デバイスとして「店舗Ａ在庫管理サーバ」及び「従業員００１携帯端末」が接続される。また、フロントエンドＮＷ「ＤＣ１―ＮＷ（DC:Distribution Center）」にフロントエンド処理サーバ１０「ＤＣ１処理サーバ」が接続され、デバイスとして「ＤＣ１在庫管理サーバ」が接続される。バックエンドネットワークには、バックエンド処理サーバ２０、ルール分配サーバ３０、アプリケーションサーバが接続される。
【００２７】
店舗Ａ在庫管理サーバから発生するイベントの例としてイベントＤ１とイベントＤ２を図８に示す。イベントは属性と属性値のペアのリストから構成される。本例では、属性名「イベント種別」はイベントがどの属性名から構成されるかを特定する値とする。
【００２８】
従業員００１携帯端末から発生するイベントは、図９に示す属性名から構成される。図９に示す属性値は例である。ＤＣ１在庫管理サーバから発生するイベントは、図１０に示す属性名から構成される。図１０に示す属性値は例である。
【００２９】
ルールは、そのルールのＩＤ（ルールＩＤ）と、処理対象のイベントの条件（複合イベント条件）と、複合イベント条件に合致するイベントに対する処理内容（アクション）とから構成される。図１１に例示するルールの複合イベント条件は、イベント条件１１に合致するイベントと、イベント条件１２に合致するイベントが１分以内に発生することを表す。ここでは、１分以内で発生するイベントを処理対象とすることをwithinで表記する。そのような条件に合致するイベントを検出するとアクションを実行する。
【００３０】
イベント条件は、０以上の属性名と、各属性名に対する属性値条件から構成される。イベントを構成する各属性値が、対応する属性値条件に合致する場合、該イベントはイベント条件に合致する。図１１のイベント条件１１に対しては、イベント種別が「店舗在庫イベント」で、拠点名が「店舗Ａ」であり、商品種別が「ＬＬＬ」であり、更新時刻はいつでもよく、店頭商品数が1以下であり、バックヤード商品数が０より大きいイベントが合致する。よって、例えば、図８のイベントＤ１はイベント条件１１に合致する。
【００３１】
アプリケーションから図１１に示すアプリルールが登録された場合のイベント処理システムの動作を説明する。アプリルールはまず、アプリルール配置先決定部３２に入力される。例えば図１３に示すイベント発生元ＮＷ解決表がルール分配サーバ３０又は他のサーバに保持されているとすると、イベント条件１１はイベント発生元ＮＷ解決表の１行目のイベント条件に包含され、イベント条件１２は３行目のイベント条件に包含されるため、図１４に示すイベント条件−ＮＷＩＤ表が生成される。次に、ルール生成部３３では、図１４に示すイベント条件−ＮＷＩＤ表の全てのＮＷＩＤが同じフロントエンドＮＷのＩＤであるため、図１５に示すルール配置表を生成する。
【００３２】
最後に、ルール登録部３４は、図１５に示すルール配置表より、ルール１を店舗Ａ―ＮＷに配置される処理サーバに登録する。
【００３３】
次に、ルール１が登録された後にイベントが発生した場合の処理の流れを説明する。
【００３４】
まず、ある日の１２時３０分００秒に、従業員００１携帯端末が図９に示す従業員位置イベントを生成し、店舗Ａ処理サーバへ送信したとする。該イベントを受信した店舗Ａ処理サーバは、受信したイベントがルール１を構成するイベント条件１２に合致すると判定する。
【００３５】
その後、同日の１２時３０分２５秒に、店舗Ａ在庫管理サーバが図８に示す店舗在庫イベントＤ１を生成し、店舗Ａ処理サーバへ送信したとする。該イベントを受信した店舗Ａ処理サーバは、受信したイベントがルール１を構成するイベント条件１２に合致すると判定すると共に、１分以内にイベント条件１２に合致する従業員位置イベントが発生しているため、複合イベント条件に合致すると判定する。店舗Ａ処理サーバは、イベントがルール１の複合イベント条件に合致したと判定すると、次に、ルール１のアクションを実行する。ルール１のアクションでは、従業員ＩＤ“０１１”の従業員の携帯端末に補充指示メッセージを送信する。
【００３６】
次に、アプリケーションから図１２に示すアプリルールが登録された場合のイベント処理システムの動作を説明する。アプリルールはまず、アプリルール配置先決定部３２に入力される。例えば図１３に示すイベント発生元ＮＷ解決表がルール分配サーバ３０又は他のサーバに保持されているとすると、イベント条件２１はイベント発生元ＮＷ解決表の１行目のイベント条件に包含され、イベント条件２２は２行目のイベント条件に包含されるため、図１６に示すイベント条件−ＮＷＩＤ表が生成される。
【００３７】
次に、ルール生成部３３では、図１６に示すイベント条件−ＮＷＩＤ表のＮＷＩＤが同じフロントエンドＮＷのＩＤでないため、図１７に示すルール配置表を生成する。
【００３８】
最後に、ルール登録部３４は、図１７に示すルール配置表の各ルールを、それに対応するＮＷＩＤに配置される処理サーバに登録する。
【００３９】
次に、ルール２が登録された後にイベントが発生した場合の処理の流れを説明する。
【００４０】
まず、ある日の１６時２５分００秒に、ＤＣ１在庫管理サーバが図１０に示すＤＣ在庫イベントを生成し、ＤＣ１処理サーバへ送信したとする。該イベントを受信したＤＣ１処理サーバは、受信したイベントがルール２−２の複合イベント条件に合致すると判定し、受信したイベントをバックエンド処理サーバに通知する。該イベントを受信したバックエンド処理サーバは、ルール２を構成するイベント条件２２に合致すると判定する。
【００４１】
その後、同日の１６時３０分００秒に、店舗Ａ在庫管理サーバが図８に示す店舗在庫イベントＤ２を生成し、店舗Ａ処理サーバへ送信したとする。該イベントを受信した店舗Ａ処理サーバは、受信したイベントがルール２−１の複合イベント条件に合致すると判定し、受信したイベントをバックエンド処理サーバに通知する。該イベントを受信したバックエンド処理サーバは、ルール２を構成するイベント条件２１に合致すると判定すると共に、１０分以内にイベント条件２２に合致するＤＣ在庫イベントが発生しているため、ルール２の複合イベント条件に合致すると判定する。バックエンド処理サーバは、イベントがルール２の複合イベント条件に合致したと判定すると、該判定後に、バックエンド処理サーバはＮＷ−ＤＣ１のＤＣ１在庫管理サーバに配送依頼メッセージを送信する。
【００４２】
以上説明したように本実施形態によれば、アプリルールに基づいた処理をバックエンド処理サーバでなく、フロントエンド処理サーバですることで、フロントエンドＮＷからバックエンドＮＷに流れるイベント数を低減できる。例えば、図１１に示すアプリルール１は店舗Ａ−ＮＷに登録されるため、ルール１を実行するために監視しなければならないイベントが、バックエンドＮＷに通知されることはない。よって、フロントエンドＮＷからバックエンドＮＷに流れるイベント数を低減できる。
【００４３】
（第２の実施形態）
第２の実施形態では、バックエンド処理サーバ２０の性能よりもフロントエンド処理サーバ１０の性能が低い場合、特にメモリ容量が少ない場合に好適なイベント処理システムについて説明する。
【００４４】
第２の実施形態に係るイベント処理システムの構成は、ルール分配サーバ３０がルール登録可否判定部３５をさらに備える点以外は第１の実施形態とほぼ同様である。本実施形態におけるルール分配サーバ３０の構成を図１８に示す。ルール登録可否判定部３５は、アプリルールをフロントエンド処理サーバに登録可能かどうかを判定する。
【００４５】
第２の実施形態に係るイベント処理システムの動作について第１の実施形態との相違点を中心に説明する。
【００４６】
ルール分配サーバ３０のルール生成部３３は、アプリルールのイベント条件に合致するイベントが全て同じフロントエンドＮＷで発生する場合でも、ルール登録可否判定部３５が該アプリルールのフロントエンドＮＷへの登録を不可と判定した場合には、該アプリルールをバックエンド処理サーバに登録するようにルール配置表を生成する。
【００４７】
具体的には、第１の実施形態では図５のステップＳ５−１の処理でＹＥＳとなると処理を終了するが、第２の実施形態では、図１９のフローチャートに示すように、ステップＳ１９−４を実行する。ステップＳ１９−４では、ルール登録可否判定部３５によって算出された登録可否判定結果により次の処理を決定する。フロントエンドＮＷにアプリルールを登録可能であれば処理を終了し、そうでなければステップＳ１９−２を実行する。
【００４８】
ルール登録可否判定部３５の説明に先立ち、時間ウィンドウについて説明する。時間ウィンドウとは、処理対象のイベントの時間制約を表すものであり、時間ウィンドウが１分であれば、１分以内に発生するイベントが処理の対象となる。時間ウィンドウの表記について、ここでは、例えば時間ウィンドウが１分であれば”within 1min”と表記する。
【００４９】
時間ウィンドウは、スライディングウィンドウと固定ウィンドウとの２つのウィンドウタイプに分類される。スライディングウィンドウとは、イベントを受信した時刻から過去within時間内に発生したイベントに対して処理を実行するような時間ウィンドウのことである（イベントが発生する度に時間幅がスライドすることからスライディング）。固定ウィンドウとは、固定の期間（例えば、２０１２年３月中）に発生したイベントに対して処理を実行するような時間ウィンドウのことである。
【００５０】
ルールの記述性によって、スライディングウィンドウか固定ウィンドウかが曖昧な場合もある。例えば、ｔ１時間ごとに過去ｔ２時間に発生したイベントに対して統計処理をするような条件“aggregation within t2 every t1”が複合イベント条件に記述できるとする。これは、複数の固定ウィンドウがあると見なすことも、スライディングウィンドウであると見なすこともできる。この場合、例えばt2/t1が所定値以上であればスライディングウィンドウと見なし、そうでなければ固定ウィンドウと見なすことができる。
【００５１】
図２０のフローチャートに示すように、ルール登録可否判定部３５は、アプリルールを受信すると（Ｓ２０−１）、それがフロントエンド処理サーバ１０に登録可能かどうかを判定する。まず、受信したアプリルールのwithinの値があらかじめ与えられているwithin許容値以下かどうかを判定する（Ｓ２０−２）。許容値以下ならアプリルールを登録可とする（Ｓ２０−３）。within許容値以下でない場合、アクションタイプがアグリゲーションかどうかを検証する（Ｓ２０−４）。アグリゲーションとは、所定のイベント条件に合致するイベントの発生回数のカウントや、特定の属性値の合計値の算出、平均値の算出などの統計処理のことである。アクションタイプがアグリゲーションである場合で、かつウィンドウタイプが固定である場合（Ｓ２０−５）、アプリルールを登録可とする（Ｓ２０−３）。アクションタイプがアグリゲーションでない場合、アプリルールを登録不可とする（Ｓ２０−６）。アクションタイプがアグリゲーションである場合で（Ｓ２０−４）、かつウィンドウタイプがスライディングである場合（Ｓ２０−５）、アプリルールを登録不可とする（Ｓ２０−６）。
【００５２】
前記登録可否の判定プロセスで、アプリルールで指定されるwithinの値が小さい場合に、フロントエンド処理サーバ１０への登録を許可するのは、withinの値が小さいと該アプリルールに対して保持するステートのサイズが小さくなるためである。ステートとは、アプリルールを実行する上で過去に受信したイベントがどのイベント条件に合致しているかの状態を表す情報である。withinが大きくなると、処理対象のイベントが多くなり、よって、ステートのサイズも大きくなる。
【００５３】
また、上記では、アプリルールをフロントエンド処理サーバ１０に登録可能かどうかを、該アプリルールのみに基づいて決定していたが、すでに登録されているアプリルールとの関係によって決定してもよい。例えば、アプリルールから、そのアプリルールの処理負荷と優先度を算出し、登録するアプリルールの処理負荷の合計値が、フロントエンド処理サーバ１０の許容負荷以下になるように、優先度の高いアプリルールを選択してもよい。
【００５４】
アプリルールの処理負荷は、アプリルールで指定されるイベント条件に合致するイベントの発生レートに依存する。そこで、発生レートに応じて、アプリルールに対する負荷値を再計算してもよい。再計算によりアプリルールの負荷値の合計がフロントエンド処理サーバ１０の許容負荷を超える場合には、優先度の低いアプリルールをフロントエンド処理サーバ１０からバックエンド処理サーバ２０へ移動してもよい。
【００５５】
以上説明したように第２の実施形態によれば、フロントエンド処理サーバ１０の性能が低い場合に、負荷の大きい処理ルールをバックエンド処理サーバ２０に配置することで、フロントエンド処理サーバ１０がボトルネックにならないようにしつつ、フロントエンドＮＷからバックエンドＮＷに流れるイベント数を低減できる。
【００５６】
（第３の実施形態）
第３の実施形態では、イベント発生元ＮＷ解決表を生成する手段について説明する。第３の実施形態に係るイベント処理システムの構成は、ルール分配サーバ３０がイベント発生元ＮＷ検出部３６をさらに備える点以外は第１の実施形態とほぼ同様である。本実施形態におけるルール分配サーバ３０の構成を図２１に示す。イベント発生元ＮＷ検出部３６は、バックエンド処理サーバ２０が受信するイベントからイベント発生元ＮＷ解決表を生成する。
【００５７】
第３の実施形態に係るイベント処理システムの動作について第１の実施形態との相違点を中心に説明する。
【００５８】
ルール分配サーバ３０のイベント発生元ＮＷ検出部３６は、バックエンド処理サーバ２０が受信するイベントの情報を受信し、どのようなイベント条件に合致するイベントが、どのフロントエンドＮＷで発生するかを算出する。算出したイベント条件とフロントエンドＮＷＩＤとのペアをイベント発生元ＮＷ解決表に追加する。
【００５９】
具体的には、図２２のフローチャートに示すように、イベント発生元ＮＷ検出部３６は、イベントを受信すると、イベントを構成する各属性（属性名attrと属性値valueのペア）に対して以下の処理を実施する。ただし、イベント種別はイベントがどの属性名から成るかを特定するための属性であるため、処理対象から外す。次に、受信したイベントのイベント種別typeと属性名attrのペアに対応する出現回数表を取得する。出現回数表とは、図２３に例示するように、各属性値が各フロントエンドＮＷで何回発生したかを表す表である。次に、取得した出現回数表の出現回数[value][nwid]を＋１する。ここで、nwidは該イベントの発生元ＮＷのＩＤであり、出現回数[value][nwid]は出現回数表内のvalueで特定される行とnwidで特定される列により決まる値である。次に、出現回数[value][nwid]が所定回数以上で、出現回数[value][nwid以外の任意のＮＷＩＤ]が０であるかどうかを判定する。その場合、イベント種別の属性値条件をtypeとし、属性名attrの属性値条件をvalueとし、そのほかの属性値条件を＊（任意の値）とするイベント条件を生成し、該イベント条件とnwidとのペアをイベント発生元ＮＷ解決表に追加する。
【００６０】
上記では、１属性名に対して１つの出現回数表としているが、２つ以上の属性名の組み合わせに対して１つの出現回数表を生成してもよい。イベントを構成する属性名の集合に対するべき集合を生成して、該べき集合の要素ごとに出現回数表を生成してもよい。その場合、行を特定するための値は、該べき集合の要素である属性値のタプルとなる。生成するイベント条件は、該タプルを構成する各属性値を、対応する属性名に対する属性値条件となる。
【００６１】
例えば図２３に示す例で、イベント種別が「従業員位置」で属性名「従業員ＩＤ」の出現回数表がイベント条件を生成するかどうかの閾値が５の場合、１行目から図２４の１行目が生成され、２行目から図２４の２行目が生成される。
【００６２】
以上説明したように第３の実施形態により、イベント発生元ＮＷ解決表が、発生するイベントから自動で生成されるため、イベント発生元ＮＷ解決表を手動で作成する手間を削減できる。
【００６３】
（第４の実施形態）
第４のの実施形態では、デバイスが移動する場合に、ルールの配置を更新する手段を備える。以下、第４の実施形態について説明する。
【００６４】
第４の実施形態に係るイベント処理システムの構成は、ルール分配サーバ３０がルール再配置部をさらに備える点以外は第３の実施形態とほぼ同様である。本実施形態におけるルール分配サーバ３０の構成を図２５に示す。ルール再配置部は、イベント発生元ＮＷ解決表の変更を基にルールの再配置を行う。
【００６５】
第４の実施形態に係るイベント処理システムの動作について第３の実施形態との相違点を中心に説明する。
【００６６】
ルール分配サーバ３０のルール生成部３３は、アプリルールをフロントエンド処理サーバ１０に登録するときに、該アプリルールの処理に必要なイベントを該フロントエンド処理サーバに転送する転送ルールを、該フロンエンド処理サーバ以外のフロントエンド処理サーバに登録するために生成する。これにより、該アプリルールの処理に必要なイベントがどのフロントエンドＮＷで発生しても、該イベントは該アプリルールが登録されるフロントエンド処理サーバに到達する。
【００６７】
具体的には、図２６のフローチャートに示すように、ステップＳ２６−３（アプリルールとフロントエンドＮＷＩＤのペアをルール配置表に追加する）の後に、ステップＳ２６−４（前記アプリルールの処理に必要なイベントを前記フロントエンド処理サーバに転送する転送ルールを生成する）とステップＳ２６−５とステップＳ２６−６（生成した各転送ルールに対して、転送ルールと前記フロントエンド処理サーバ以外の各フロントエンド処理サーバとのペアをルール配置表に追加する）を実行する。
【００６８】
ルール分配サーバ３０のルール再配置部３７は、図２７のフローチャートに示すように、イベント発生元ＮＷ解決表が変更されると（Ｓ２７−１）、バックエンド処理サーバ１０が保持するアプリルールを再配置対象とする。以降、再配置対象のルールを保持する処理サーバをターゲット処理サーバと呼ぶ（Ｓ２７−２）。該変更が既存のイベント条件に対応するイベント発生元ＮＷＩＤの変更である場合（Ｓ２７−３）、さらに、変更前のイベント発生元ＮＷＩＤに対応する処理サーバをターゲット処理サーバとする（Ｓ２７−４）。
【００６９】
イベント発生元ＮＷ解決表の変更は、新たなイベント条件が追加されたものか、既存のイベント条件に対応するイベント発生元ＮＷＩＤの変更かに分類される。ルール再配置部３７は、いずれの変更であるか判別し、新たなイベント条件が追加されたものである場合、新たに追加されたイベント条件に包含されるイベント条件が指定されるアプリルールはバックエンド処理サーバ以外に登録されることはないため、バックエンド処理サーバに登録されているアプリルールを再配置の候補とする。一方、既存のイベント条件に対応するイベント発生元ＮＷＩＤの変更である場合には、該イベント条件に包含されるイベント条件が指定されるアプリルールは変更前のイベント発生元ＮＷＩＤに対応するフロントエンド処理サーバかバックエンド処理サーバかのいずれかに登録されているため、該フロントエンド処理サーバとバックエンド処理サーバに登録されているアプリルールを再配置の候補とする（Ｓ２７−４）。
【００７０】
アプリルール配置先決定部３２とルール生成部３３は、ターゲット処理サーバが保持するアプリルールに対してルール配置表を生成する（Ｓ２７−５）。それが、イベント発生元ＮＷ解決表更新前のものと異なる場合（Ｓ２７−７）、ルール再配置部３７は、ルールの再配置を行う。
【００７１】
ルールの再配置では、ルール再配置部３７は、まず、アプリルールに対応するステートのデータを取得する（Ｓ２７−８）。次に、該アプリルールとそれに対するステートと転送ルールを、それを保持している処理サーバから削除する（Ｓ２７−９）。その後、新たに生成したルール配置表の各ルールを対応するＮＷの処理サーバに配置する（Ｓ２７−１０）。アプリルールを配置するときには、取得したステートを共に配置する。ステートを共に配置することで、処理ルールの削除時点における処理状況を引き継いでイベント処理を実行するため、複合イベント条件に対するイベント合致の漏れを防ぐことができる。
【００７２】
ここで、イベント発生元ＮＷ検出部３６は出現回数表を生成するが、過去所定時間内に発生したイベントを対象として生成する。これは、デバイスが移動する場合、移動前のイベント発生元ＮＷはイベント発生元ＮＷ解決表の生成に有効でないためである。
【００７３】
また、イベント発生元ＮＷ検出部３６は、図２２のステップＳ２２−７で、イベント条件とＮＷＩＤのペアを追加するときに、追加する該イベント条件と同じものがすでにイベント発生元ＮＷ解決表に登録されている場合には、その行のＮＷＩＤを新たなＮＷＩＤで上書きする。
【００７４】
次に、本実施形態に係るイベント処理システムの動作を具体例を用いて説明する。例えば、図２８に示すように従業員００１携帯端末が店舗Ａ―ＮＷから店舗Ｂ―ＮＷへ移動したとする。すると、従業員ＩＤが００１であるイベントが店舗Ｂ―ＮＷから発生するようになり、例えば、図２３のような値を持っていた出現回数表が、図２９のような値を持つようになる。それに伴い、イベント発生元ＮＷ解決表は、図２４の１行目に示すものが、図３１に示すものに書き換えられる。そして、このイベント発生元ＮＷ解決表に変更に基づいて、図３０に示すようなルール配置表が生成され、各処理サーバに配置される。
【００７５】
以上説明したように第４の実施形態によれば、フロントエンド処理サーバにアプリルールが登録される場合、どのフロントエンドＮＷでイベントが発生しても、該アプリルールの処理に必要なイベントがバックエンド処理サーバに流れることはないため、デバイスが接続するネットワークが変わった場合にも、フロントエンドＮＷからバックエンドＮＷに流れるイベント数を低減した状態を維持できる。また、デバイスが接続するネットワークが変わった場合に、アプリルールを再配置することで、フロントエンドＮＷ間を流れるイベント数を低減できる。
【００７６】
上述した本発明の実施形態に係る通信ルール分配サーバ、フロントエンド処理サーバ、バックエンド処理サーバは、ＣＰＵ（Central Processing Unit）が記憶部に格納された動作プログラム等を読み出して実行することにより実現されてもよく、また、ハードウェアで構成されてもよい。上述した実施の形態の一部の機能のみをコンピュータプログラムにより実現することもできる。
【００７７】
以上、好ましい実施の形態をあげて本発明を説明したが、本発明は必ずしも上記実施の形態に限定されるものではなく、その技術的思想の範囲内において様々に変形し実施することが出来る。
【００７８】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【００７９】
（付記１）
アプリケーションサーバからイベント処理に関するルールの登録を受けて、イベント発生源が接続されるフロントエンドネットワークに接続されたフロントエンド処理サーバとバックエンドネットワークに接続されたバックエンド処理サーバにルールを配置するルール分配サーバであって、
イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出するイベント発生元ネットワーク解決部と、
アプリケーションから登録されたアプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに接続される処理サーバに登録し、発生しない場合、該アプリルールをバックエンド処理サーバに登録すると決定するアプリルール配置先決定部と、
前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンド処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成するルール生成部と、
アプリルールとルール生成部で生成した転送ルールをそれぞれ対応する処理サーバに登録するルール登録部と
を備えるルール分配サーバ。
【００８０】
（付記２）
アプリルールの内容から処理ルールがフロントエンド処理サーバに登録可能かどうかを判定するルール登録可否判定部をさらに備え、
前記ルール生成部は、前記ルール登録可否判定部で、アプリルールが登録可能と判定され、かつ、各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合には、該アプリルールを該フロントエンドネットワークに登録する
付記１に記載のルール分配サーバ。
【００８１】
（付記３）
前記ルール生成部は、
アプリルールに、時間幅ｔの間に発生するイベントを処理対象とするような時間幅ｔが指定されるときに、該時間幅が所定値以下であれば、該アプリルールをフロントエンド処理サーバに登録可とし、
該時間幅が所定値以下でなければ、該アプリルールが複数のイベントの統計値を算出する処理かどうかを判定し、統計値を算出する処理でなければ、該アプリルールを登録不可とし、
統計値を算出する処理であれば、該アプリルールで指定される処理が、デバイスから発生する各イベントに対して、該イベントが発生した時刻から過去時間幅ｔの間に発生したイベントに対して処理を行うスライディングウィンドウ処理か、イベントの発生時刻によらず、所定の時刻から時間幅ｔの間に発生したイベントに対して処理を行う固定ウィンドウ処理かを判定し、固定ウィンドウ処理であれば、該アプリルールを登録可とし、スライディングウィンドウ処理であれば、該アプリルールを登録不可とする
付記２のルール分配サーバ。
【００８２】
（付記４）
バックエンド処理サーバが受信したイベントの情報を取得し、イベント発生元ネットワーク解決表を生成するイベント発生元ネットワーク検出部をさらに備え、
前記イベント発生元ネットワーク検出部は、属性の集合のべき集合の各要素にあたる属性値と、受信したイベントが、その要素の全ての属性値と一致した場合に、該要素と、該イベントの発生元ネットワークのＩＤとで特定される計数値に１を加算し、所定値以上の前記要素と前記イベントの発生元ネットワークのＩＤとで特定される計数値について、当該要素と当該発生元ネットワークのＩＤ以外のネットワークのＩＤとで特定される計数値のいずれもが０である場合、属性値条件を該要素とし、それ以外の属性値条件を任意の値とするイベント条件を生成し、生成したイベント条件と、前記発生元ネットワークＩＤとのペアをイベント発生元ネットワーク解決表に追加する
付記１から３のいずれかに記載のルール分配サーバ。
【００８３】
（付記５）
前記ルール生成部は、アプリルールをフロントエンド処理サーバに登録するときに、該アプリルールの処理に必要なイベントを該フロントエンド処理サーバに転送する転送ルールを生成し、該フロンエンド処理サーバ以外のフロントエンド処理サーバに登録する
付記１から４のいずれかに記載のルール分配サーバ。
【００８４】
（付記６）
イベント発生元ネットワーク解決表の変更を基にルールの再配置を行うルール再配置部をさらに備え、
前記ルール再配置部は、イベント発生元ネットワーク解決表が変更されると、バックエンド処理サーバをターゲット処理サーバとし、該変更が既存のイベント条件に対応するイベント発生元ネットワークＩＤの変更である場合、さらに、変更前のイベント発生元ネットワークＩＤに対応する処理サーバをターゲット処理サーバとし、
前記アプリルール配置先決定部とルール生成部は、ターゲット処理サーバが保持するアプリルールに対して、転送ルールの生成と、該アプリルールと生成した転送ルールの配置先の算出を行い、
前記ルール再配置部は、前記算出結果が、イベント発生元ネットワーク解決表の更新前の内容と異なる場合、該アプリルールが登録されている処理サーバから該アプリルールに対するステートを取得し、該アプリルールとそれに対するステートと転送ルールとを、それを保持している処理サーバから削除し、新たに生成したルール配置表のルールを、対応するネットワークの処理サーバに配置し、アプリルールの配置においては取得したステートを共に配置する
付記５に記載のルール分配サーバ。
【００８５】
（付記７）
イベント発生源が接続するフロントエンドネットワークに接続されるフロントエンド処理サーバと、各フロントエンドネットワークの処理サーバから収集したイベントを処理するバックエンド処理サーバと、アプリケーションから登録されるアプリルールから各処理サーバに登録する転送ルールを生成し、該アプリルールと生成した転送ルールを処理サーバに配置するルール分配サーバと、を備え、
前記ルール分配サーバは、
イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出するイベント発生元ネットワーク解決部と、
アプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに登録し、そうでない場合、該アプリルールをバックエンド処理サーバに登録すると決定するアプリルール配置先決定部と、
前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンドネットワークに接続された処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成するルール生成部と、
アプリルールとルール生成部で生成した転送ルールを処理サーバに登録するルール登録部と
を備えるイベント処理システム。
【００８６】
（付記８）
アプリケーションサーバからイベント処理に関するルールの登録を受けて、イベント発生源が接続されるフロントエンドネットワークに接続されたフロントエンド処理サーバとバックエンドネットワークに接続されたバックエンド処理サーバにルールを配置するルール分配方法であって、
イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出し、
アプリケーションから登録されたアプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに接続される処理サーバに登録し、発生しない場合、該アプリルールをバックエンド処理サーバに登録すると決定し、
前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンド処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成し、
前記生成した転送ルールをそれぞれ対応する処理サーバに登録する
ルール分配方法。
【００８７】
（付記９）
アプリルールの内容から処理ルールがフロントエンド処理サーバに登録可能かどうかを判定し、
アプリルールが登録可能と判定され、かつ、各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合には、該アプリルールを該フロントエンドネットワークに登録する
付記８に記載のルール分配方法。
【００８８】
（付記１０）
アプリルールに、時間幅ｔの間に発生するイベントを処理対象とするような時間幅ｔが指定されるときに、該時間幅が所定値以下であれば、該アプリルールをフロントエンド処理サーバに登録可とし、
該時間幅が所定値以下でなければ、該アプリルールが複数のイベントの統計値を算出する処理かどうかを判定し、統計値を算出する処理でなければ、該アプリルールを登録不可とし、
統計値を算出する処理であれば、該アプリルールで指定される処理が、デバイスから発生する各イベントに対して、該イベントが発生した時刻から過去時間幅ｔの間に発生したイベントに対して処理を行うスライディングウィンドウ処理か、イベントの発生時刻によらず、所定の時刻から時間幅ｔの間に発生したイベントに対して処理を行う固定ウィンドウ処理かを判定し、固定ウィンドウ処理であれば、該アプリルールを登録可とし、スライディングウィンドウ処理であれば、該アプリルールを登録不可とする
付記９のルール分配方法。
【００８９】
（付記１１）
バックエンド処理サーバが受信したイベントの情報を取得し、イベント発生元ネットワーク解決表を生成するときに、属性の集合のべき集合の各要素にあたる属性値と、受信したイベントが、その要素の全ての属性値と一致した場合に、該要素と、該イベントの発生元ネットワークのＩＤとで特定される計数値に１を加算し、所定値以上の前記要素と前記イベントの発生元ネットワークのＩＤとで特定される計数値について、当該要素と当該発生元ネットワークのＩＤ以外のネットワークのＩＤとで特定される計数値のいずれもが０である場合、属性値条件を該要素とし、それ以外の属性値条件を任意の値とするイベント条件を生成し、生成したイベント条件と、前記発生元ネットワークＩＤとのペアをイベント発生元ネットワーク解決表に追加する
付記８から１０のいずれかに記載のルール分配方法。
【００９０】
（付記１２）
アプリルールをフロントエンド処理サーバに登録するときに、該アプリルールの処理に必要なイベントを該フロントエンド処理サーバに転送する転送ルールを生成し、該フロンエンド処理サーバ以外のフロントエンド処理サーバに登録する
付記８から１１のいずれかに記載のルール分配方法。
【００９１】
（付記１３）
イベント発生元ネットワーク解決表の変更を基にルールの再配置を行うときに、イベント発生元ネットワーク解決表が変更されると、バックエンド処理サーバをターゲット処理サーバとし、該変更が既存のイベント条件に対応するイベント発生元ネットワークＩＤの変更である場合、さらに、変更前のイベント発生元ネットワークＩＤに対応する処理サーバをターゲット処理サーバとし、
ターゲット処理サーバが保持するアプリルールに対して、転送ルールの生成と、該アプリルールと生成した転送ルールの配置先の算出を行い、
前記算出結果が、イベント発生元ネットワーク解決表の更新前の内容と異なる場合、該アプリルールが登録されている処理サーバから該アプリルールに対するステートを取得し、該アプリルールとそれに対するステートと転送ルールとを、それを保持している処理サーバから削除し、新たに生成したルール配置表のルールを、対応するネットワークの処理サーバに配置し、アプリルールの配置においては取得したステートを共に配置する
付記１２に記載のルール分配方法。
【００９２】
（付記１４）
イベント発生源が接続されるフロントエンドネットワークに接続されたフロントエンド処理サーバとバックエンドネットワークに接続されたバックエンド処理サーバに接続されたコンピュータに、
イベント条件から、該イベント条件に合致するイベントが発生するフロントエンドネットワークのＩＤを算出する処理、
アプリケーションから登録されたアプリルールで指定される各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合、該アプリルールを該フロントエンドネットワークに接続される処理サーバに登録し、発生しない場合、該アプリルールをバックエンド処理サーバに登録すると決定するアプリルール配置先決定処理、
前記バックエンド処理サーバに登録すると決定されたアプリルールについて、イベント条件ごとに、該イベント条件に合致するイベントが発生するフロントエンド処理サーバを登録先として、イベント条件に合致するイベントをバックエンド処理サーバに転送する処理ルールを生成するルール生成処理、
アプリルールとルール生成部で生成した転送ルールをそれぞれ対応する処理サーバに登録するルール登録処理
を実行させるプログラム。
【００９３】
（付記１５）
アプリルールの内容から処理ルールがフロントエンド処理サーバに登録可能かどうかを判定するルール登録可否処理をさらに実行させ、
前記ルール登録可否処理では、前記ルール登録可否判定処理で、アプリルールが登録可能と判定され、かつ、各イベント条件に合致するイベントが全て同じフロントエンドネットワークで発生する場合には、該アプリルールを該フロントエンドネットワークに登録する
付記１４に記載のプログラム。
【００９４】
（付記１６）
前記ルール生成処理では、
アプリルールに、時間幅ｔの間に発生するイベントを処理対象とするような時間幅ｔが指定されるときに、該時間幅が所定値以下であれば、該アプリルールをフロントエンド処理サーバに登録可とし、
該時間幅が所定値以下でなければ、該アプリルールが複数のイベントの統計値を算出する処理かどうかを判定し、統計値を算出する処理でなければ、該アプリルールを登録不可とし、
統計値を算出する処理であれば、該アプリルールで指定される処理が、デバイスから発生する各イベントに対して、該イベントが発生した時刻から過去時間幅ｔの間に発生したイベントに対して処理を行うスライディングウィンドウ処理か、イベントの発生時刻によらず、所定の時刻から時間幅ｔの間に発生したイベントに対して処理を行う固定ウィンドウ処理かを判定し、固定ウィンドウ処理であれば、該アプリルールを登録可とし、スライディングウィンドウ処理であれば、該アプリルールを登録不可とする
付記１５のプログラム。
【００９５】
（付記１７）
バックエンド処理サーバが受信したイベントの情報を取得し、イベント発生元ネットワーク解決表を生成するイベント発生元ネットワーク検出処理をさらに実行させ、
前記イベント発生元ネットワーク検出処理では、属性の集合のべき集合の各要素にあたる属性値と、受信したイベントが、その要素の全ての属性値と一致した場合に、該要素と、該イベントの発生元ネットワークのＩＤとで特定される計数値に１を加算し、所定値以上の前記要素と前記イベントの発生元ネットワークのＩＤとで特定される計数値について、当該要素と当該発生元ネットワークのＩＤ以外のネットワークのＩＤとで特定される計数値のいずれもが０である場合、属性値条件を該要素とし、それ以外の属性値条件を任意の値とするイベント条件を生成し、生成したイベント条件と、前記発生元ネットワークＩＤとのペアをイベント発生元ネットワーク解決表に追加する
付記１４から１６のいずれかに記載のプログラム。
【００９６】
（付記１８）
前記ルール生成処理では、アプリルールをフロントエンド処理サーバに登録するときに、該アプリルールの処理に必要なイベントを該フロントエンド処理サーバに転送する転送ルールを生成し、該フロンエンド処理サーバ以外のフロントエンド処理サーバに登録する
付記１４から１７のいずれかに記載のプログラム。
【００９７】
（付記１９）
イベント発生元ネットワーク解決表の変更を基にルールの再配置を行うルール再配置処理をさらに実行させ、
前記ルール再配置処理では、イベント発生元ネットワーク解決表が変更されると、バックエンド処理サーバをターゲット処理サーバとし、該変更が既存のイベント条件に対応するイベント発生元ネットワークＩＤの変更である場合、さらに、変更前のイベント発生元ネットワークＩＤに対応する処理サーバをターゲット処理サーバとし、
前記アプリルール配置先決定処理とルール生成処理は、ターゲット処理サーバが保持するアプリルールに対して、転送ルールの生成と、該アプリルールと生成した転送ルールの配置先の算出を行い、
前記ルール再配置部は、前記算出結果が、イベント発生元ネットワーク解決表の更新前の内容と異なる場合、該アプリルールが登録されている処理サーバから該アプリルールに対するステートを取得し、該アプリルールとそれに対するステートと転送ルールとを、それを保持している処理サーバから削除し、新たに生成したルール配置表のルールを、対応するネットワークの処理サーバに配置し、アプリルールの配置においては取得したステートを共に配置する
付記１８に記載のプログラム。
【００９８】
以上好ましい実施の形態をあげて本発明を説明したが、本発明は必ずしも上記実施の形態に限定されるものではなく、その技術的思想の範囲内において様々に変形し実施することが出来る。
この出願は、２０１２年１０月２３日に出願された日本出願特願２０１２−２３３３７３を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【００９９】
１０    フロントエンド処理サーバ
２０    バックエンド処理サーバ
３０    ルール分配サーバ
３１    イベント発生元ＮＷ解決部
３２    アプリルール配置先決定部
３３    ルール生成部
３４    ルール登録部
３５    ルール登録可否判定部
３６    イベント発生元ＮＷ検出部
３７    ルール再配置部
【図１】
2014065115.tif 000003
【図２】
2014065115.tif 000004
【図３】
2014065115.tif 000005
【図４】
2014065115.tif 000006
【図５】
2014065115.tif 000007
【図６】
2014065115.tif 000008
【図７】
2014065115.tif 000009
【図８】
2014065115.tif 000010
【図９】
2014065115.tif 000011
【図１０】
2014065115.tif 000012
【図１１】
2014065115.tif 000013
【図１２】
2014065115.tif 000014
【図１３】
2014065115.tif 000015
【図１４】
2014065115.tif 000016
【図１５】
2014065115.tif 000017
【図１６】
2014065115.tif 000018
【図１７】
2014065115.tif 000019
【図１８】
2014065115.tif 000020
【図１９】
2014065115.tif 000021
【図２０】
2014065115.tif 000022
【図２１】
2014065115.tif 000023
【図２２】
2014065115.tif 000024
【図２３】
2014065115.tif 000025
【図２４】
2014065115.tif 000026
【図２５】
2014065115.tif 000027
【図２６】
2014065115.tif 000028
【図２７】
2014065115.tif 000029
【図２８】
2014065115.tif 000030
【図２９】
2014065115.tif 000031
【図３０】
2014065115.tif 000032
【図３１】
2014065115.tif 000033
【国際調査報告】
2014065115.tif 000034
2014065115.tif 000035