JPWO2014034036A1 - ルール分配装置、イベント処理システム、ルール分配方法およびルール分配プログラム - Google Patents

Abstract

ネットワークにおける特定のリソースのボトルネック化を防ぎ、高いサービス品質を維持することができるルール分配装置、イベント処理システム、ルール分配方法およびルール分配プログラムを提供する。アプリケーションが要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部１１と、処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、端末と通信可能でありイベント処理を実行可能な処理装置に、配置ルールとサブルールとを送信するイベント生成部１２とを含む。

Description

本発明は、イベントをリアルタイムに処理するルール分配装置、イベント処理システム、ルール分配方法およびルール分配プログラムに関する。

センサ等の複数のデバイス（端末）から送信されるイベントをリアルタイムに処理するイベント処理システムがある。イベント処理システムでは、システム内の複数の処理サーバが、複合イベント処理（Ｃｏｍｐｌｅｘ Ｅｖｅｎｔ Ｐｒｏｃｅｓｓｉｎｇ（ＣＥＰ））により、サーバ等に具備されたアプリケーションから要求されたイベント処理を実行する。具体的には、各アプリケーションが要求するイベント処理とイベント処理を実行するためのイベント条件とを規定したルール（以下、ＣＥＰルールまたは処理ルールという。）が各処理サーバに登録され、各処理サーバがＣＥＰルールに従って並列に処理を実行する。それにより、大量イベントのリアルタイム処理が可能になる。

イベントは、端末がセンシングしたデータであって、１つ以上の属性を含む。属性とは、データの種類を表す属性名と、データの値を表す属性値とから構成される。例えば、４つの属性「ＩＤ」、「タイプ」、「緯度」、「経度」を含むイベントは、次のように表すことができる。

｛ＩＤ＝ｃａｒ１，タイプ＝位置，緯度＝ｘ１，経度＝ｙ１｝

“ｃａｒ１”、“位置”、“ｘ１”、“ｙ１”は、各属性に対する属性値を示す。

ルールは、上述の通り、イベント条件と、イベント条件が成立したときの動作を指定するイベント処理（以下、アクションという。）とから構成される。イベント条件は、１つ以上の属性条件を含む。属性条件は、属性名と属性値とから構成される。例えば、３つの属性条件を含むイベント条件から構成されるルールは、次のように表すことができる。

［イベント条件］タイプ＝位置，緯度＝ｘ１，経度＝ｙ１
［アクション］この端末にコンテンツ１を配信

この場合、端末から送信されたイベントの属性「タイプ」の属性値が“位置”であって、「緯度」の属性値が“ｘ１”であって、「経度」の属性値が“ｙ１”である場合に、アクション“この端末にコンテンツ１を配信”が実行される。

端末から大量のイベントが発せられると、端末と処理サーバとの間で頻繁に通信が行われる。それにより、端末やネットワークの負荷が増大し、端末やネットワークがボトルネックとなる場合がある。そのような場合、アプリケーションは、サービス品質を維持することができない。例えば、ユーザの状況を逐一把握する必要があるアプリケーション（以下、リアルタイムアプリケーションという。）は、データ遅延が発生するとサービス品質が劣化する。従って、ＣＥＰでは、端末やネットワークの負荷の増減に素早く対応して、動的に分散並列処理することが必要とされる。

車両に搭載された端末（車載装置）が自車両の状態を検知して、車両の状態に応じた処理条件、例えば、タスク周期、メッセージ送信周期を決定する技術がある（例えば、特許文献１参照。）。特許文献１に記載された車載装置は、最大のパフォーマンスの実現が不要となる場合には、メッセージの送信周期を長くし、メッセージが送信される頻度を低下させることができる。また、車両状態に応じたパフォーマンスを実現可能となるよう、メッセージの送信頻度を設定することができる。従って、車載装置やネットワークのリソースの浪費を防ぐことができる。

特開２０１０−２６２４４４号公報

しかし、メッセージ送信周期は、送信先、つまりアプリケーションの種類などによって決まる。従って、送信先のアプリケーションが動的に変わる場合、アプリケーションに合わせてメッセージ送信周期を変更する必要がある。特許文献１に記載された車載装置は、車両状況に対して一意に処理条件が決まるため、メッセージ送信周期を任意に変更することができない。そのため、特許文献１に記載された車載装置は、アプリケーションが動的に変更する状況に対応することができない。

また、ネットワークのボトルネックを解消する方法として、アプリケーションから処理サーバに登録されるルールのうち、端末で処理可能なルールを切り出して、切り出したルール（以下、サブルールという。）を全端末に配置する方法が考えられる。そのような方法によれば、端末が処理サーバに送信するイベントの数を低減させることができるので、端末と処理サーバとの通信量を低減させることができる。しかし、端末の数が増加した場合、各端末にサブルールを配置させるための処理負荷が増大する。また、アプリケーションから登録されるルール数が増加した場合、各端末は、サブルールを保持するためにメモリ資源を大量に消費する。従って、サブルールの配置処理およびサブルールを格納するためのメモリ資源がボトルネックとなる可能性がある。

そこで、本発明は、ネットワークにおける特定のリソースのボトルネック化を防ぎ、高いサービス品質を維持することができるルール分配装置、イベント処理システム、ルール分配方法およびルール分配プログラムを提供することを目的とする。

本発明によるルール分配装置は、アプリケーションが要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部と、処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、端末と通信可能でありイベント処理を実行可能な処理装置に、配置ルールとサブルールとを送信するルール生成部とを含むことを特徴とする。

本発明によるイベント処理システムは、ルール分配装置と、端末と通信可能でありイベント処理を実行可能な処理装置とを含み、ルール分配装置は、アプリケーションが要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部と、処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、配置ルールとサブルールとを処理装置に送信するルール生成部とを含み、処理装置は、配置ルールのイベント条件に従って端末が通知するイベントとのマッチング処理を実行し、イベントがイベント条件にマッチした場合には、当該端末にサブルールを送信する制御部とを備えることを特徴とする。

本発明によるルール分配方法は、アプリケーションが要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信し、処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、端末と通信可能でありイベント処理を実行可能な処理装置に、配置ルールとサブルールとを送信することを特徴とする。

本発明によるルール分配プログラムは、コンピュータに、アプリケーションが要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信する処理と、処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、端末と通信可能でありイベント処理を実行可能な処理装置に、配置ルールとサブルールとを送信する処理とを実行させることを特徴とする。

本発明によれば、ネットワークにおける特定のリソースのボトルネック化を防ぎ、高いサービス品質を維持することができる。

本発明によるルール分配装置を含むイベント処理システムの第１の実施形態の構成を示すブロック図である。 ルール分配装置の第１の実施形態の構成を示すブロック図である。 端末の構成の一例を示すブロック図である。 クーポン配信サービスに適用したイベント処理システムの概要を示す説明図である。 第１の実施形態におけるイベント処理システムの動作を示すシーケンス図である。 お近づき通知サービスに適用したイベント処理システムの概要を示す説明図である。 第２の実施形態におけるイベント処理システムの動作を示すシーケンス図である。 危険箇所事前通知サービスの概要を示す説明図である。 第３の実施形態におけるイベント処理システムのＣＥＰルール登録時の動作を示すシーケンス図である。 ステップＳ５０２における配置ルールおよび実行用サブルールの生成処理を示すフローチャートである。 第３の実施形態におけるイベント処理システムの危険イベント受信時の動作を示すシーケンス図である。 本発明によるルール分配装置を含むイベント処理システムの第４の実施形態の構成を示すブロック図である。 基地局を介して危険通知を行う危険箇所事前通知サービスの概要を示す説明図である。 第４の実施形態におけるイベント処理システムの危険イベント受信時の動作を示すシーケンス図である。 第４の実施形態におけるイベント処理システムの新規端末加入時の動作を示すシーケンス図である。 本発明によるルール分配装置の最小構成を示すブロック図である。 本発明によるルール分配装置の他の最小構成を示すブロック図である。 本発明によるイベント処理システムの最小構成を示すブロック図である。

実施形態１．
以下、本発明の第１の実施形態を図面を参照して説明する。

図１は、本発明によるルール分配装置を含むイベント処理システムの構成の一例を示すブロック図である。

本発明によるイベント処理システムは、ルール分配装置１００と、処理サーバ２００とを含む。また、図１に示すように、イベント処理システムは、端末３００−１〜３００−ｎと通信可能に接続される。また、イベント処理システムは、アプリケーション４００と通信可能に接続される。なお、図１には、処理サーバが１つ例示されているが、処理サーバはいくつあってもよい。また、図１には、アプリケーションが１つ例示されているが、アプリケーションはいくつあってもよい。

ルール分配装置１００は、処理サーバ２００、端末３００−１〜３００−ｎから事前情報を取得する。具体的には、ルール分配装置１００は、処理サーバ２００から処理サーバ２００の処理能力を示す情報を取得する。また、ルール分配装置１００は、端末３００−１〜３００−ｎから、各端末の処理能力、各端末が送信するイベントタイプおよび各端末の設置場所を示す情報を取得する。

ルール分配装置１００は、アプリケーション４００からＣＥＰルールを受信すると、受信したＣＥＰルールと取得した事前情報とをもとに、配置ルールおよびサブルールを生成する。配置ルールは、サブルールを、どの端末にどのタイミングで配置するかを規定するルールである。ルール分配装置１００は、配置ルールを処理サーバ２００に送信する。サブルールは、端末におけるイベント処理を規定するルールである。

処理サーバ２００は、制御部（図示せず）を備える。なお、制御部は、処理サーバ２００が備えるＣＰＵ等によって実現される。以降、処理サーバ２００の制御部が処理することを、単に処理サーバ２００が処理すると表現する。処理サーバ２００は、受信した配置ルールを自装置に登録する。処理サーバ２００は、配置ルールに対応するサブルールをルール分配装置１００から取得し、保持する。

処理サーバ２００は、配置ルールにもとづいて、サブルールを端末３００−１〜３００−ｎに登録する。具体的には、処理サーバ２００は、各端末から受信したイベントをもとに、配置ルールのイベント条件の判定を行う。そして、処理サーバ２００は、受信したイベントが配置ルールのイベント条件に合致した場合には、配置ルールのアクションを実行する。つまり、処理サーバ２００は、サブルールを端末に送信する。

端末３００−１〜３００−ｎは、受信したサブルールを自端末に登録する。端末３００−１〜３００−ｎは、サブルールに従って処理サーバ２００に対してイベント通知を行う。また、端末３００−１〜３００−ｎは、サブルールに従ってイベント処理を実行する。

図２は、ルール分配装置１００の第１の実施形態の構成を示すブロック図である。

図２に示すように、ルール分配装置１００は、ルール受信部１１０と、事前情報取得部１２０と、配置ルール生成部１３０と、サブルール生成部１４０と、事前情報記憶部１５０とを含む。

ルール受信部１１０は、アプリケーション４００からＣＥＰルールを受信する。

事前情報取得部１２０は、処理サーバ２００、端末３００−１〜３００−ｎから事前情報を取得する。事前情報取得部１２０は、取得した事前情報を事前情報記憶部１５０に格納する。

配置ルール生成部１３０は、ルール受信部１１０が受信したＣＥＰルールと、事前情報記憶部１５０に格納された事前情報とをもとに、配置ルールを生成する。配置ルール生成部１３０は、処理サーバ２００に配置ルールを送信する。

サブルール生成部１４０は、ルール受信部１１０が受信したＣＥＰルールと、事前情報記憶部１５０に格納された事前情報とをもとに、サブルールを生成する。サブルール生成部１４０は、処理サーバ２００にサブルールを送信する。

事前情報記憶部１５０は、事前情報取得部１２０から受け取った事前情報を保持する。なお、ユーザなどが予め事前情報記憶部１５０に事前情報を格納させてもよい。

なお、ルール受信部１１０、事前情報取得部１２０、配置ルール生成部１３０およびサブルール生成部１４０は、ルール分配装置１００が備えるＣＰＵ等によって実現される。例えば、コンピュータ読み取り可能な記録媒体に記憶されたルール分配プログラムを、ＣＰＵが読み込み、ＣＰＵが、そのルール分配プログラムに従って、ルール受信部１１０、事前情報取得部１２０、配置ルール生成部１３０およびサブルール生成部１４０として動作してもよい。また、事前情報記憶部１５０は、ルール分配装置１００が備えるメモリ等の記憶装置によって実現される。

図３は、端末の構成の一例を示すブロック図である。

図３に示すように、端末３００（３００−１〜３００−ｎ）は、イベント制御部３０１と、加速度イベント生成部３０２と、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）イベント生成部３０３と、表示装置３０４とを備える。

イベント制御部３０１は、自端末に登録されたサブルールをもとに、加速度イベント生成部３０２およびＧＰＳイベント生成部３０３から通知されるイベントのマッチング処理を行う。

イベント制御部３０１は、マッチング処理の結果に応じて、例えば、アラート画面を表示するための画像情報を表示装置３０４に送信する。

加速度イベント生成部３０２は、加速度センサ（図示せず）を含み、加速度センサから取得した加速度データをもとに、急ブレーキ等の危険を検出する。加速度イベント生成部３０２は、危険を検出すると、危険情報を含むイベント（以下、危険イベントという。）をイベント制御部３０１に通知する。危険情報は、例えば、危険の種類や危険の発生位置を示す情報である。

ＧＰＳイベント生成部３０３は、ＧＰＳを利用して自端末の位置情報を取得する。ＧＰＳイベント生成部３０３は、定期的または間欠的に、位置情報を含むイベント（以下、位置イベントという。）をイベント制御部３０１に通知する。位置イベントは、位置情報とともに自端末を識別可能なＩＤ情報を含む。

表示装置３０４は、例えば、ディスプレイ装置である。

なお、イベント制御部３０１、加速度イベント生成部３０２およびＧＰＳイベント生成部３０３は、端末３００が備えるＣＰＵ等によって実現される。

また、端末３００は、表示装置以外の出力装置を備えていてもよい。また、本実施形態では、端末３００は、イベント生成部として加速度イベント生成部およびＧＰＳイベント生成部を備えるが、端末３００はどちらか一方のイベント生成部のみを備えていてもよいし、それ以外のイベント生成部を備えていてもよい。

次に、本実施形態の動作を説明する。

本実施形態では、イベント処理システムがクーポン配信サービスに適用される場合を例にする。

図４は、クーポン配信サービスに適用したイベント処理システムの概要を示す説明図である。クーポン配信サービスは、端末を携帯するユーザが店舗に近づいたら、その店舗の広告情報としてクーポンをそのユーザの端末に配信するサービスである。

図４に示すように、クーポンの配信元である広告事業者等が、クラウド（クラウドコンピューティングシステム）上に設置されたルール分配装置に、店舗ごとのＣＥＰルールを登録する。

クラウド上に設置された処理サーバは、ルール分配装置から受信した配置ルールに従って、次のように、端末に位置情報を通知させるためのサブルールの登録および削除を実行する。ユーザが店舗に近づいている場合は、処理サーバはその店舗に対応するサブルールをそのユーザの端末に登録する。そして、ユーザが店舗から離れて行く場合は、処理サーバはその店舗に対応するサブルールをそのユーザの端末から削除する。

図４では、ユーザＸが店舗Ａに近づいている。従って、処理サーバは、店舗Ａに対応するサブルールをユーザＸの端末に登録する。また、ユーザＹが店舗Ａから離れ、店舗Ｂに近づいている。従って、処理サーバは、店舗Ａに対応するサブルールをユーザＹの端末から削除し、店舗Ｂに対応するサブルールをユーザＹの端末に登録する。

図５は、第１の実施形態におけるイベント処理システムの動作を示すシーケンス図である。なお、図５には端末３００が１つ例示されているが、端末はいくつあってもよい。

ルール分配装置１００は、アプリケーションからＣＥＰルールが登録されると（ステップＳ１０１）、配置ルール、サブルールおよび削除ルールを生成する（ステップＳ１０２）。本実施形態では、ルール分配装置１００は、サブルールとして通知用サブルールを生成する。通知用サブルールは、端末に、配置ルールのイベント条件の判定に必要なイベントを処理サーバ２００に通知させるためのルールである。

ステップＳ１０１において登録されたＣＥＰルールと、ＣＥＰルールから生成される配置ルール、削除ルール、通知用サブルールの一例を以下に示す。

（ａ）ＣＥＰルール
［イベント条件］位置イベント．位置が店舗Ａから３００ｍ以内
［アクション］位置イベント．ｉｄにクーポン配信

（ｂ）配置ルール
［イベント条件］位置イベント．位置が店舗Ａから１３００ｍ以内
［アクション］通知用サブルールを位置イベント．ｉｄに設定、削除ルールを処理サーバに設定

（ｃ）通知用サブルール
［イベント条件］位置イベント．位置が店舗Ａから３００ｍ以内
［アクション］処理サーバに配信

（ｄ）削除ルール
［イベント条件］位置イベント．位置が店舗Ａから１３００ｍより離れる
［アクション］位置イベント．ｉｄから削除対象の通知用サブルールを削除

（ａ）は、本実施形態において、アプリケーションから登録されるＣＥＰルールの一例である。「位置イベント．位置が店舗Ａから３００ｍ以内」は、位置イベントの属性「位置」の属性値が示す位置が店舗Ａから３００ｍ（メートル）以内であるかを判定させるための条件である。このように、範囲指定を含む属性条件を範囲指定属性条件という。なお、店舗Ａの位置を示す情報は、予め処理サーバ２００が備える記憶部（図示せず）に格納される。

（ｂ）は、（ａ）に示すＣＥＰルールから生成される配置ルールの一例である。ルール分配装置１００は、イベント条件に含まれる範囲指定属性条件の指定範囲がＣＥＰルールよりも広くなるように、配置ルールのイベント条件を設定する。ここでは、配置ルールのイベント条件における範囲指定属性条件の指定範囲を“３００ｍ以内”よりも広い“１３００ｍ以内”に設定する。

（ｃ）は、（ｂ）に示す配置ルールに対応する通知用サブルールの一例である。

（ｄ）は、削除ルールの一例である。

なお、配置ルール、通知用サブルールおよび削除ルールの構成は、ＣＥＰルールと同様の構成である。アクション「位置イベント．ｉｄから通知用サブルールを削除」は、位置イベントの属性「ｉｄ」の属性値に対応する端末、つまり、位置イベントの送信元の端末に登録された通知用サブルールを削除する処理を示す。削除対象の通知用サブルールは、通知用サブルールを識別可能なＩＤなどで指定すればよい。本実施形態では、削除対象として通知用サブルール（ｃ）が指定される。

ルール分配装置１００は、ＣＥＰルールと、配置ルールと、配置ルールに対応する通知用サブルールおよび削除ルールとを処理サーバ２００に送信する（ステップＳ１０３）。このとき、処理サーバ２００は、ＣＥＰルールと配置ルールとを自装置に登録する。これにより、処理サーバ２００は、当該ＣＥＰルールと当該配置ルールとを実行可能な状態となる。また、処理サーバ２００は、通知用サブルールと削除ルールとを保持する。

端末３００のイベント制御部３０１は、ＧＰＳイベント生成部３０３から位置イベントが送信されるたびに、位置イベントと初期動作用サブルールのイベント条件とのマッチング処理を行う（ステップＳ１０４、Ｓ１０５）。初期動作用サブルールは、第２のサブルールとして、アプリケーション起動時にアプリケーションによって予め各端末に登録される。なお、ルール分配装置１００が、ＣＥＰルールから初期動作用サブルールを生成し、生成した初期動作用サブルールを各端末に配置するようにしてもよい。ルール分配装置１００は、初期動作用サブルールを登録する端末を、例えば、事前情報記憶部１５０に格納された事前情報をもとに決定する。初期動作用サブルールの一例を以下に示す。初期動作用サブルールの構成は、ＣＥＰルールと同様の構成である。

（ｅ）初期動作用サブルール
［イベント条件］位置イベント
［アクション］５分間隔で処理サーバに配信

位置イベントが初期動作用サブルールのイベント条件にマッチした場合には、つまり、前回の位置イベント送信時から５分経過している場合には、イベント制御部３０１は、その位置イベントを処理サーバ２００へ送信する（ステップＳ１０６）。

処理サーバ２００は、受信した位置イベントに対して、配置ルールのイベント条件とのマッチング処理を行う（ステップＳ１０７）。

位置イベントが配置ルールのイベント条件にマッチした場合には、つまり、端末３００の位置が店舗Ａから１３００ｍ以内である場合には、処理サーバ２００は、位置イベントの送信元である端末３００に通知用サブルールを登録する（ステップＳ１０８）。このとき、処理サーバ２００は、配置ルールに従って削除ルールを自装置に登録する。

ステップＳ１０８の後、端末３００のイベント制御部３０１は、ＧＰＳイベント生成部３０３から位置イベントが送信されるたびに、位置イベントと通知用サブルールのイベント条件とのマッチング処理を行う（ステップＳ１０９、Ｓ１１０）。

位置イベントが通知用サブルールのイベント条件にマッチした場合には、つまり、端末３００の位置が店舗Ａから３００ｍ以内である場合には、イベント制御部３０１は、位置イベントを処理サーバ２００へ送信する（ステップＳ１１１）。

処理サーバ２００は、受信した位置イベントに対して、ＣＥＰルールのイベント条件とのマッチング処理を行う（ステップＳ１１２）。このとき、端末３００の位置は店舗Ａから３００ｍ以内であるので、処理サーバ２００は、ＣＥＰルールのアクションを実行する。これにより、位置イベントの送信元である端末３００に、処理サーバ２００から店舗Ａのクーポンが配信される（ステップＳ１１３）。

処理サーバ２００は、ステップＳ１１３の後、端末３００から受信する位置イベントに対して、削除ルールのイベント条件とのマッチング処理を行う。位置イベントが削除ルールのイベント条件とマッチした場合には、つまり、端末３００の位置が店舗Ａから１３００ｍより離れた場合には、処理サーバ２００は、削除ルールのアクションを実行する。つまり、位置イベントの送信元である端末３００に登録された通知用サブルールを削除する。

ここで、ユーザからルール分配装置１００に対して、ＣＥＰルールの削除要求があった場合の動作を説明する。

ルール分配装置１００は、ユーザからＣＥＰルールの削除要求を受け付けると、具体的には、ルール分配装置１００が備えるルール削除部（図示せず）がＣＥＰルールの削除要求を受信すると、自装置に登録されたＣＥＰルールを削除する。また、ルール分配装置１００のルール削除部は、処理サーバ２００にＣＥＰルールおよび当該ＣＥＰルールに対応する配置ルールの削除要求を送信する。

処理サーバ２００は、ルール分配装置１００の要求に応じて、自装置に登録されたＣＥＰルールおよび配置ルールを削除する。処理サーバ２００は、各ルールを削除した後、各端末に通知用サブルールの削除要求を送信する。なお、ルール分配装置１００のルール削除部が各端末に通知用サブルールの削除要求を送信してもよい。

各端末は、処理サーバ２００の要求に応じて通知用サブルールを削除する。

このように、ルール分配装置１００からＣＥＰルールが削除されると、処理サーバ２００および各端末に登録されている当該ＣＥＰルールに対応する各ルールが削除される。

以上に説明したように、本実施形態では、ルール分配装置は、アプリケーションが登録したＣＥＰルールをもとに生成した、配置ルールおよび通知用サブルールを用いて、イベント処理システムにおける処理サーバおよび端末の処理を制御する。また、ルール分配装置は、ＣＥＰルールが登録されるたびにＣＥＰルールの内容に応じた配置ルール、通知用サブルールを生成し、各ルールを処理サーバおよび端末に登録する。従って、ＣＥＰにおいて動的な分散並列処理を実現することができる。

また、処理サーバは、配置ルールに従って、ＣＥＰルールのイベント条件にマッチしそうな状況にあるユーザの端末にのみ、通知用サブルールを配置する。従って、本実施形態によれば、イベント条件にマッチしそうにない端末における不要なイベントの送信を抑えることができるので、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなくＣＥＰルールを実行することができる。

また、本実施形態によれば、処理サーバは、全端末に通知用サブルールを配置する必要がないので、処理サーバの負荷を低減することができる。また、端末の状況、例えば端末と店舗との位置関係に応じて、端末がその状況で最小限必要なサブルールのみが当該端末に登録される。それにより、端末のメモリ消費量を低減することができる。また、端末は最低限のサブルールのみを実行すればよいので、端末のＣＰＵリソース消費量を低減することができる。従って、ネットワークにおけるリソースがボトルネックとなることを回避することができ、高いサービス品質を維持することができる。

また、本実施形態では、端末と店舗との距離が一定以上になった場合には、端末からＣＥＰルールに対応する通知用サブルールを削除する。このように、端末における通知用サブルールによるマッチング処理が必要なくなったときに、端末から通知用サブルールを削除することにより、端末のメモリ消費量およびＣＰＵリソース消費量をより低減することができる。なお、本実施形態では、端末と店舗との距離にもとづいて通知用サブルールを削除する場合を例にしたが、例えば、端末にクーポンが配信されてからの経過時間にもとづいて通知用サブルールを削除するようにしてもよい。

また、本実施形態では、ルール分配装置からＣＥＰルールが削除されたときに、処理サーバ２００および各端末に登録されている当該ＣＥＰルールに対応する各ルールを削除する。従って、処理サーバおよび端末のメモリ消費量およびＣＰＵリソース消費量をより低減することができる。

また、本実施形態では、監視対象となる一方が店舗である場合を例にしたが、店舗に限定されず、店舗以外の固定エリアを監視対象としてもよい。

実施形態２．
以下、本発明の第２の実施形態を図面を参照して説明する。

イベント処理システムの第２の実施形態の構成は、第１の実施形態の構成と同様であるため、説明を省略する。

ここでは、イベント処理システムがお近づき通知サービスに適用される場合を例にする。

図６は、お近づき通知サービスに適用したイベント処理システムの概要を示す説明図である。お近づき通知サービスは、端末を携帯するユーザ同士がある一定距離以下まで近づいたら、互いの端末が近づいていることを示すお近づき通知を各ユーザの端末に送信するサービスである。図６は、ユーザＸとユーザＹとの距離が３００ｍ以内になったときに、お近づき通知が送信される様子を示す。

図６に示すように、ユーザＸ、Ｙが携帯する各端末（以下、単にユーザＸ、ユーザＹという。）は、まず、予め定められたタイミングで位置イベントを処理サーバに送信する。ここでは、ユーザＸ、Ｙは、５分間隔で位置イベントを送信する。

処理サーバは、各ユーザから受信した位置イベントをもとに、ユーザＸとユーザＹとの距離が一定以内、例えば、１３００ｍ以内になったか否かを判定する。処理サーバは、ユーザＸとユーザＹとの距離が一定以内になると、各ユーザの位置イベントの送信間隔を５分よりも短い３０秒に変更する。

処理サーバは、３０秒間隔で各ユーザから送信される位置イベントをもとに、ユーザＸとユーザＹとの距離が３００ｍ以内になったか否かを判定する。処理サーバは、ユーザＸとユーザＹとの距離が３００ｍ以内である場合には、他のユーザが近づいていることを各ユーザに通知する。これにより、ユーザＸ、Ｙは、他方が自身に近づいているか否かを認識することができる。

図７は、第２の実施形態におけるイベント処理システムの動作を示すシーケンス図である。

ここでは、端末３００−１および端末３００−２に対して、お近づき通知を送信する場合を例にする。なお、図７には２つの端末３００−１、３００−２が例示されているが、端末はいくつあってもよい。

ルール分配装置１００は、アプリケーションからＣＥＰルールが登録されると（ステップＳ２０１）、配置ルール、サブルールおよび削除ルールを生成する（ステップＳ２０２）。本実施形態では、ルール分配装置１００は、第１の実施形態と同様に、サブルールとして通知用サブルールを生成する。

ステップＳ２０１において登録されたＣＥＰルールと、ＣＥＰルールから生成される配置ルール、通知用サブルール、削除ルールの一例を以下に示す。

（ｆ）ＣＥＰルール
［イベント条件］位置イベント１．位置と位置イベント２．位置の距離が３００ｍ以内
［アクション］位置イベント１．ｉｄと位置イベント２．ｉｄに近づいたことを通知

（ｇ）配置ルール
［イベント条件］位置イベント１．位置と位置イベント２．位置の距離が１３００ｍ以内
［アクション］通知用サブルールを位置イベント．ｉｄに設定、削除ルールを処理サーバに設定

（ｈ）通知用サブルール
［イベント条件］位置イベント
［アクション］３０秒間隔で処理サーバに配信

（ｉ）削除ルール
［イベント条件］位置イベント１．位置と位置イベント２．位置の距離が１３００ｍより離れる
［アクション］位置イベント．ｉｄから削除対象の通知用サブルールを削除

ここで、各ルールにおける“位置イベント１”は、端末３００−１が送信する位置イベントを示す。“位置イベント２”は、端末３００−２が送信する位置イベントを示す。

（ｆ）は、本実施形態において、アプリケーションから登録されるＣＥＰルールの一例である。「位置イベント１．位置と位置イベント２．位置の距離が３００ｍ以内」は、端末３００−１が送信する位置イベントの属性「位置」の属性値と、端末３００−２が送信する位置イベントの属性「位置」の属性値との差が３００ｍ以内であるかを判定させるための条件である。

（ｇ）は、（ｆ）に示すＣＥＰルールから生成される配置ルールの一例である。（ｈ）は、（ｇ）に示す配置ルールに対応する通知用サブルールの一例である。

（ｉ）は、削除ルールの一例である。本実施形態では、削除対象として通知用サブルール（ｈ）が指定される。

ルール分配装置１００は、ＣＥＰルールと、配置ルールと、配置ルールに対応する通知用サブルールおよび削除ルールとを処理サーバ２００に送信する（ステップＳ２０３）。このとき、処理サーバ２００は、ＣＥＰルールと配置ルールとを自装置に登録する。また、処理サーバ２００は、通知用サブルールと削除ルールとを保持する。

端末３００−１、３００−２のイベント制御部は、ＧＰＳイベント生成部から位置イベントが送信されるたびに、位置イベントと初期動作用サブルールのイベント条件とのマッチング処理を行う（ステップＳ２０４、Ｓ２０５）。初期動作用サブルールは、アプリケーション起動時にアプリケーションによって予め各端末に登録される。ここでは、各端末に上記（ｅ）に示す初期動作用サブルールが登録されているとする。なお、ルール分配装置１００が、ＣＥＰルールから初期動作用サブルールを生成し、生成した初期動作用サブルールを各端末に配置するようにしてもよい。

位置イベントが初期動作用サブルールのイベント条件にマッチした場合には、つまり、前回の位置イベント送信時から５分経過している場合には、各端末のイベント制御部は、その位置イベントを処理サーバ２００へ送信する（ステップＳ２０６）。

処理サーバ２００は、各端末から受信した位置イベントに対して、配置ルールのイベント条件とのマッチング処理を行う（ステップＳ２０７）。

各端末から受信した位置イベントが配置ルールのイベント条件にマッチした場合には、つまり、位置イベントの送信元である端末３００−１と端末３００−２との距離が１３００ｍ以内である場合には、各位置イベントの送信元である端末３００−１、３００−２に通知用サブルールを登録する（ステップＳ２０８）。このとき、処理サーバ２００は、削除ルールを自装置に登録する。

ステップＳ２０８の後、端末３００−１、３００−２のイベント制御部は、ＧＰＳイベント生成部から位置イベントが送信されるたびに、位置イベントと通知用サブルールのイベント条件とのマッチング処理を行う（ステップＳ２０９、Ｓ２１０）。

ＧＰＳイベント生成部から通知される位置イベントが通知用サブルールのイベント条件にマッチした場合には、つまり、前回の位置イベント送信時から３０秒経過している場合には、各端末のイベント制御部は、位置イベントを処理サーバ２００へ送信する（ステップＳ２１１）。

処理サーバ２００は、各端末から受信した位置イベントに対して、ＣＥＰルールのイベント条件とのマッチング処理を行う（ステップＳ２１２）。

各端末から受信した位置イベントがＣＥＰルールのイベント条件にマッチした場合、つまり、位置イベントの送信元である端末３００−１と端末３００−２との距離が３００ｍ以内である場合には、処理サーバ２００は、ＣＥＰルールのアクションを実行する（ステップＳ２１３）。これにより、端末３００−１、３００−２にお近づき通知が送信される。

処理サーバ２００は、ステップＳ２１３の後、各端末から受信する位置イベントに対して、削除ルールのイベント条件とのマッチング処理を行う。各端末から受信した位置イベントが削除ルールのイベント条件とマッチした場合には、つまり、端末３００−１と端末３００−２とが１３００ｍより離れた場合には、処理サーバ２００は、削除ルールのアクションを実行する。つまり、位置イベントの送信元である端末３００−１、３００−２に登録された通知用サブルールを削除する。

なお、ユーザからルール分配装置１００に対して、ＣＥＰルールの削除要求があった場合のルール分配装置１００、処理サーバ２００および各端末の動作は、第１の実施形態と同様であるため、説明を省略する。

以上に説明したように、本実施形態では、処理サーバは、端末同士が一定の距離以下に近づいたときに、各端末にお近づき通知を送信する。これにより、端末を携帯するユーザは、他のユーザが自身に近づいているか否かを認識することができる。第１の実施形態におけるクーポン配信サービスでは、監視対象となる一方（店舗）の位置が固定されている。本実施形態では、監視対象となる一方の位置が固定されていないサービス、つまり、監視対象となる双方の位置が固定されていないサービスにおいても、端末、処理サーバおよびネットワークの負荷を増大させることなくＣＥＰルールを実行することができる。

実施形態３．
以下、本発明の第３の実施形態を図面を参照して説明する。

イベント処理システムの第３の実施形態の構成は、第１の実施形態の構成と同様であるため、説明を省略する。

ここでは、イベント処理システムが危険箇所事前通知サービスに適用される場合を例にする。

図８は、危険箇所事前通知サービスの概要を示す説明図である。

まず、図８を参照して、危険箇所事前通知サービスの概要を説明する。

図８に示す各車両は、それぞれ、図３に示す端末を搭載する。車両に搭載された端末（以下、単に車両という。）は、位置イベントを危険通知サーバに送信する。

各車両は、自車両が危険な状態にあるか否かを判定し、危険イベントを危険通知サーバに送信する。各車両は、例えば、運転者が急ブレーキを踏んだ場合や、車両が道路の陥没を検出した場合に、危険であると判断する。

危険通知サーバは、危険を検出した車両（以下、危険検出車両という。）から危険イベントを受信すると、危険情報の通知対象候補となる車両（以下、通知対象候補車両という。）を特定する。危険通知サーバは、例えば、危険検出車両と他の車両との距離が一定距離（以下、危険判定距離という。）以下にある車両を通知対象候補とする。処理サーバ２００は、特定した通知対象候補車両に危険通知を送信する。これにより、危険検出車両は、周辺エリアにいる他の車両に危険を知らせることができる。

危険通知を受信した通知対象候補車両は、自車両と危険検出車両との距離をもとに、自車両に危険の影響があるか否かを判断する。また、危険の影響があると判断した場合には、運転者に対して危険を通知する。例えば、通知対象候補車両は、車両に搭載されたディスプレイ等の表示装置に、危険を通知するための情報としてアラート画面を表示する。

次に、図９を参照して、危険箇所事前通知サービスに適用したイベント処理システムのＣＥＰルール登録時の動作を説明する。

図９は、第３の実施形態におけるイベント処理システムのＣＥＰルール登録時の動作を示すシーケンス図である。なお、図９には２つの端末３００−１、３００−２が例示されているが、端末はいくつあってもよい。

本実施形態では、イベント処理システムは、配置ルール、実行用サブルールおよび通知用サブルールを用いて、車両から危険通知サーバ（処理サーバ２００）へ送信される位置イベントの送信間隔を調整する。

ルール分配装置１００は、アプリケーション４００からＣＥＰルールが登録されると（ステップＳ５０１）、配置ルールおよびサブルールを生成する（ステップＳ５０２）。本実施形態では、ルール分配装置１００は、サブルールとして、実行用サブルールおよび通知用サブルールを生成する。実行用サブルールは、端末にＣＥＰルールに規定されたイベント処理を実行させるためのルールである。

ステップＳ５０１において登録されたＣＥＰルールと、ＣＥＰルールから生成される配置ルール、実行用サブルールおよび通知用サブルールの一例を以下に示す

（ｊ）ＣＥＰルール
［イベント条件］危険イベント．危険＝急ブレーキ＆＆危険イベント．位置と位置イベント．位置が３００ｍ以内
［アクション］位置イベント．ｉｄにアラーム通知

（ｋ）配置ルール
［イベント条件］危険イベント．危険=急ブレーキ＆＆危険イベント．位置と位置イベント．位置が１３００ｍ以内
［アクション］実行用サブルールに危険イベント．位置の絶対値を入力し、実行用サブルールを位置イベント．ｉｄに設定

（ｌ）実行用サブルール
［イベント条件］危険イベント．位置と位置イベント．位置が３００ｍ以内
［アクション］位置イベント．ｉｄにアラーム通知

（ｍ）通知用サブルール
［イベント条件］位置イベント．位置が前回処理サーバに位置イベントを送信してから１０００ｍ移動
［アクション］処理サーバに配信

（ｎ）通知用サブルール
［イベント条件］危険イベント．危険=急ブレーキ
［アクション］処理サーバに配信

（ｊ）は、本実施形態において、アプリケーションから登録されるＣＥＰルールの一例である。（ｊ）に示すイベント条件は、２つの属性条件「危険イベント．危険＝急ブレーキ」と「危険イベント．位置と位置イベント．位置が３００ｍ以内」とのＡＮＤ（論理積）である。

「危険イベント．危険＝急ブレーキ」は、危険イベントの属性「危険」の属性値が“急ブレーキ”であるかを判定させるための条件である。「危険イベント．位置と位置イベント．位置が３００ｍ以内」は、危険イベントの属性「位置」の属性値と位置イベントの属性「位置」の属性値との差が３００ｍ以内であるかを判定させるための条件である。

（ｋ）は、（ｊ）に示すＣＥＰルールから生成される配置ルールの一例である。（ｌ）は、（ｋ）に示す配置ルールに対応する実行用サブルールの一例である。（ｍ）、（ｎ）は、（ｋ）に示す配置ルールに対応する通知用サブルールの一例である。なお、実行用サブルールの構成は、ＣＥＰルールと同様の構成である。

ルール分配装置１００は、配置ルールと実行用サブルールとを処理サーバ２００に送信する（ステップＳ５０３）。このとき、処理サーバ２００は、配置ルールと実行用サブルールとを自装置に登録する。

また、ルール分配装置１００は、通知用サブルール（ｍ）、（ｎ）を各端末に登録する（ステップＳ５０４）。

ステップＳ５０４の後、通知用サブルールが登録された各端末は、（ｍ）に示す通知用サブルールに従って、位置イベントの通知処理を開始する。つまり、各端末は、１０００ｍ移動するごとに、処理サーバ２００に位置イベントを通知する。また、各端末は、急ブレーキ等を検出したときには、（ｎ）に示す通知用サブルールに従って、処理サーバ２００に危険イベントを通知する。

なお、ステップＳ５０４の処理は、ユーザ等が予め実行するようにしてもよい。例えば、ユーザ等が予め通知用サブルール（ｍ）、（ｎ）を生成し、第１および第２の実施形態と同様に、初期動作用サブルールとして各端末に登録するようにしてもよい。

ここで、ステップＳ５０２における配置ルールおよびサブルールの生成処理を説明する。

まず、ルール分配装置１００は、配置ルールおよびサブルールを生成する。図１０は、ステップＳ５０２における配置ルールおよび実行用サブルールの生成処理を示すフローチャートである。

ルール分配装置１００のルール受信部１１０は、アプリケーション４００からＣＥＰルールを受信すると（ステップＳ７０１）、ＣＥＰルールを配置ルール生成部１３０とサブルール生成部１４０とに渡す。

配置ルール生成部１３０は、ＣＥＰルールをもとに、配置ルールを生成する。このとき、配置ルール生成部１３０は、ＣＥＰルールのイベント条件を配置ルールのイベント条件に設定する（ステップＳ７０２）。

配置ルール生成部１３０は、配置ルールのイベント条件の各属性条件に対して、更新処理（ステップＳ７０４、Ｓ７０５の処理）を実行する（ステップＳ７０３）。

ステップＳ７０４で、配置ルール生成部１３０は、属性条件が範囲指定であるか否かを判定する。

属性条件が範囲指定であった場合には（ステップＳ７０４のｙｅｓ）、ステップＳ７０５で、配置ルール生成部１３０は当該属性条件に含まれる属性値を更新する。

ステップＳ７０５の後、サブルール生成部１４０は、ＣＥＰルールをもとに、実行用サブルールを生成する（ステップＳ７０６、Ｓ７０７）。このとき、サブルール生成部１４０は、ＣＥＰルールのイベント条件のうち、範囲指定属性条件を、実行用サブルールのイベント条件に設定する。また、サブルール生成部１４０は、ＣＥＰルールのアクションを実行用サブルールのアクションに設定する。

ステップＳ７０７の後、配置ルール生成部１３０は、配置ルールのアクションを設定する（ステップＳ７０８）。このとき、配置ルールのアクションには、配置ルールのイベント条件が成立したときに、サブルール生成部１４０が生成した実行用サブルールをどの車両に登録するかを示す処理内容が設定される。上記（ｋ）に示す例の場合、登録対象となる車両、つまり、通知対象候補車両は、配置ルールのイベント条件にマッチした位置イベントの属性「ｉｄ」の属性値に対応する車両である。処理サーバ２００は、イベント端末対応テーブルを参照して、属性「ｉｄ」の属性値に対応する車両を特定する。イベント端末対応テーブルは、属性「ｉｄ」の属性値とそれに対応する車両とを対応づけた情報である。イベント端末対応テーブルは、処理サーバ２００の記憶部（図示せず）等に格納される。

ここで、ステップＳ７０５の属性条件の更新処理を説明する。

当該更新処理実行前における配置ルールのイベント条件のうち範囲指定属性条件は、「危険イベント．位置と位置イベント．位置が３００ｍ以内」である。従って、配置ルール生成部１３０は、ステップＳ７０５において、当該属性条件に含まれる属性値「３００ｍ」を次のように更新する。

まず、配置ルール生成部１３０は、アプリケーションが登録したＣＥＰルールと、事前情報記憶部１５０に格納された事前情報とをもとに、車両の位置イベント送信間隔ｘを決定する。ここでは、位置イベント送信間隔ｘが１０００ｍに決定されたとする。

次に、配置ルール生成部１３０は、属性値「３００ｍ」に、位置イベント送信間隔ｘ（１０００ｍ）を加算する。つまり、属性値は「１３００（＝３００＋１０００）ｍ」に更新される。これにより、配置ルールのイベント条件は、上記（ｋ）に示すような条件になる。

ここで、位置イベント送信間隔ｘの算出方法を説明する。位置イベント送信間隔ｘは、イベント処理システムの総通信量ｕが最小になるように算出する。

式１は、イベント処理システムの総通信量ｕを算出するための式である。

αは、端末から処理サーバに送信される危険イベントの１秒当たりの発生率を示す。

βは、端末から処理サーバに送信される位置イベントの１秒当たりの発生率を示す。βは、式２によって算出される。

ｐは、端末の移動速度（ｍ／ｓ）を示す。

γは、実行用サブルールの発生率、つまり、処理サーバから端末に１秒あたりに登録される実行用サブルールの個数を示す。γは、式３によって算出される。

ｅは、危険通知の範囲（円）の半径を示す。つまり、危険検出車両から半径何メートル以内にいる車両にアラートを通知するかを示す値である。ｍは、端末密度、つまり、１平方メートル当たりの通知対象候補となる端末の数を示す。ｎは、全端末数を示す。

なお、α、ｐ、ｅ、ｎ、ｍは、事前情報であって、事前情報記憶部１５０に格納されている。

配置ルール生成部１３０は、式１に示す総通信量ｕを最小とする位置イベント送信間隔ｘを算出する。例えば、ｕとｘとの対応を示すグラフの凸部分のｘ、つまり、ｕの微分値が０になるときのｘと、ｘの限界値（０または∞）とのうち、ｕが最小になるｘを求めるようにしてもよい。なお、位置イベント送信間隔ｘの算出方法はその他の方法であってもよい。

ルール分配装置１００は、ステップＳ５０２において配置ルールおよび実行用サブルールを生成した後、配置ルールのイベント条件に含まれるイベントのタイプごとに、通知用サブルールを生成する。具体的には、ルール分配装置１００のサブルール生成部１４０は、ステップＳ５０２において位置イベントを通知させるための通知用サブルール（ｍ）および危険イベントを通知させるための通知用サブルール（ｎ）を生成する。

サブルール生成部１４０は、位置イベントを通知させるための通知用サブルールに、上記（ｍ）に示すように、位置イベント送信間隔ｘが１０００ｍになるようなイベント条件を設定する。

次に、図１１を参照して、危険箇所事前通知サービスに適用したイベント処理システムの危険イベント受信時の動作を説明する。

図１１は、第３の実施形態におけるイベント処理システムの危険イベント受信時の動作を示すシーケンス図である。

図１１に示すように、端末３００−１の加速度イベント生成部３０２−１は、急ブレーキなどを検出すると、イベント制御部３０１−１に危険イベントを送信する（ステップＳ８０１）。

イベント制御部３０１−１は、受信した危険イベントと、通知用サブルール（ｎ）のイベント条件とのマッチング処理を行う（ステップＳ８０２）。危険イベントが通知用サブルール（ｎ）のイベント条件にマッチした場合には、イベント制御部３０１−１は、その危険イベントを処理サーバ２００へ送信する（ステップＳ８０３）。

端末３００−２のイベント制御部３０１−２は、ＧＰＳイベント生成部３０３−２から位置イベントが送信されるたびに、位置イベントと通知用サブルール（ｍ）のイベント条件とのマッチング処理を行う（ステップＳ８０４、Ｓ８０５）。位置イベントが通知用サブルール（ｍ）のイベント条件にマッチした場合には、イベント制御部３０１−２は、その位置イベントを処理サーバ２００へ送信する（ステップＳ８０６）。

処理サーバ２００は、ステップＳ８０３において受信した危険イベントおよびステップＳ８０６において受信した位置イベントに対して、配置ルールのイベント条件とのマッチング処理を行う（ステップＳ８０７）。

ステップＳ８０７において危険イベントおよび位置イベントが、配置ルールのイベント条件とマッチした場合には、処理サーバ２００は、配置ルールのアクションを実行する。すなわち、処理サーバ２００は、位置イベントの属性「ｉｄ」の属性値に対応する端末に実行用サブルールを登録する（ステップＳ８０８）。つまり、位置イベントの送信元である端末３００−２に実行用サブルールを登録する。このとき、処理サーバ２００は、受信した危険イベントの属性「位置」の属性値の絶対値を、実行用サブルールのイベント条件に含まれる危険イベントの属性「位置」の属性値に設定する。

ステップＳ８０８の後、端末３００−２のイベント制御部３０１−２は、ＧＰＳイベント生成部３０３−２から位置イベントが送信されるたびに、位置イベントと実行用サブルールのイベント条件とのマッチング処理を行う（ステップＳ８０９、Ｓ８１０）。

位置イベントが実行用サブルールのイベント条件にマッチした場合、つまり、位置イベントの属性「位置」の属性値と危険イベントの属性「位置」の属性値との差が３００ｍ以内になった場合には、イベント制御部３０１−２は、実行用サブルールのアクションを実行する（ステップＳ８１１）。つまり、イベント制御部３０１−２は、表示装置３０４−２に危険を通知するための情報を送信する。

このように、処理サーバ２００は、各車両が１０００ｍ移動するごとに通知する位置イベントと、危険検出車両が通知する危険イベントとをもとに、危険検出車両と各車両との距離が１３００ｍ以下であるかを判定する。そして、処理サーバ２００は、車両と危険検出車両との距離が１３００ｍ以下であると判断した場合には、実行用サブルールを当該車両に登録する。これにより、実行用サブルールが登録された車両（通知対象候補車両）は、危険検出車両との距離が３００ｍ以下になったときに、自車両のディスプレイ等に危険を通知するための情報を表示する。

以上に説明したように、本実施形態では、ルール分配装置が、端末と処理サーバ間の通信回数を最小化する位置イベント送信間隔を決定する。そして、ルール分配装置は、決定した位置イベント送信間隔とアプリケーションが登録したＣＥＰルールとをもとに生成した、配置ルール、実行用サブルールおよび通知用サブルールを用いて、イベント処理システムにおける処理サーバおよび端末の処理を制御する。また、本実施形態では、端末が、実行用サブルールに従って、ＣＥＰルールのイベント処理を処理サーバに代わって実行する。従って、本実施形態によれば、ＣＥＰにおいてより動的な分散並列処理を実現することができる。

また、本実施形態では、第１および第２の実施形態と同様に、配置ルールに従って、ＣＥＰルールのイベント条件にマッチしそうな状況にあるユーザの端末にのみ、実行用サブルールを配置する。従って、本実施形態によれば、危険箇所事前通知サービスにおいてＣＥＰルールを実行する際に、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなく危険箇所事前通知サービスを提供することができる。

また、本実施形態によれば、実行用サブルールを全端末に登録する必要がない。よって、実行用サブルールを端末に配置する処理を軽減させることができる。また、端末のメモリ消費量を低減させることができるので、端末のメモリ資源がボトルネックとなることを回避することができる。

なお、本実施形態においても、第１および第２の実施形態と同様に、削除ルールを使用して実行用サブルールを削除するようにしてもよい。そのような形態によれば、端末のメモリ消費量およびＣＰＵリソース消費量をより低減することができる。

また、本実施形態では、端末が危険を検出したときに危険イベントを送信する場合を例にしたが、端末は危険イベント以外のイベントを送信してもよい。例えば、端末が危険以外の状態変化を検出するセンサを備え、当該センサが検出した情報を含むイベントを送信するようにしてもよい。

実施形態４．
以下、本発明の第４の実施形態を図面を参照して説明する。

図１２は、本発明によるルール分配装置を含むイベント処理システムの第４の実施形態の構成を示すブロック図である。なお、イベント処理システムの第４の実施形態の構成は、第１の実施形態の構成と同様であるため、説明を省略する。

ただし、図１２に示すように、本実施形態では、処理サーバ２００と端末３００−１〜３００−ｎとが、基地局５００−１〜５００−ｍを介して接続されている。なお、各基地局には端末がいくつ接続されていてもよい。図１２に示す基地局５００−１には、２台の端末３００−１、３００−２が接続されている。

また、処理サーバ２００は、各基地局の対象エリアの情報（以下、エリア情報という。）を保持する。処理サーバ２００は、危険イベントを受信した場合、エリア情報をもとに、危険イベントの発生位置を対象エリアとする基地局を特定する。そして、処理サーバ２００は、特定した基地局に対して配置ルールのアクションを実行する。なお、エリア情報は、処理サーバ２００が備える記憶部（図示せず）に予め格納される。

次に、本実施形態の動作を説明する。

図１３は、基地局を介して危険通知を行う危険箇所事前通知サービスの概要を示す説明図である。第３の実施形態では、イベント処理システムが図８に示す危険箇所事前通知サービスに適用される場合を例にした。ここでは、イベント処理システムが図１３に示す危険箇所事前通知サービスに適用される場合を例にする。図１３に示す危険通知サーバは、基地局を介して端末に危険通知を行う。

第４の実施形態におけるイベント処理システムのＣＥＰルール登録時の動作は、図９に示す第３の実施形態の動作と同様であるため、説明を省略する。

ただし、本実施形態では、ルール分配装置１００は、ステップＳ５０２において、ＣＥＰルールのイベント条件を配置ルールのイベント条件に設定するときに、範囲指定属性条件を配置ルールのイベント条件に含ませない。

また、ルール分配装置１００は、通知用サブルールとして、端末に危険イベントを通知させるためのサブルールのみを生成し、位置イベントを通知させるためのサブルールは生成しない。

また、ルール分配装置１００は、危険イベントの発生位置を対象エリアとする基地局に対して実行用サブルールのブロードキャストを依頼する処理を、配置ルールのアクションとして登録する。

従って、本実施形態において、アプリケーション４００からルール分配装置１００に対して上記（ｊ）に示すＣＥＰルールが登録された場合、ルール分配装置１００は、以下の（ｏ）〜（ｑ）に示すルールを生成する。

（ｏ）配置ルール
［イベント条件］危険イベント．危険＝急ブレーキ
［アクション］実行用サブルールに危険イベント．位置の絶対値を入力し、危険イベント．位置をカバーする基地局に対して、５秒ごとに２回実行用サブルールのブロードキャストを依頼

（ｐ）実行用サブルール
［イベント条件］危険イベント．位置と位置イベント．位置が３００ｍ以内
［アクション］位置イベント．ｉｄにアラーム通知

（ｑ）通知用サブルール
［イベント条件］危険イベント．危険=急ブレーキ
［アクション］処理サーバに配信

図１４は、第４の実施形態におけるイベント処理システムの危険イベント受信時の動作を示すシーケンス図である。

ステップＳ１２０１〜Ｓ１２０３の処理は、第３の実施形態のステップＳ８０１〜Ｓ８０３の処理と同様であるため説明を省略する。

処理サーバ２００は、ステップＳ１２０３において受信した危険イベントに対して、配置ルールのイベント条件とのマッチング処理を行う（ステップＳ１２０４）。

ステップＳ１２０４において危険イベントが配置ルールのイベント条件とマッチした場合には、処理サーバ２００は、配置ルールのアクションを実行する（ステップＳ１２０５）。

ステップＳ１２０５において、処理サーバ２００は、エリア情報をもとに、受信した危険イベントの発生位置を対象エリアとする基地局を特定する。ここでは、基地局５００−１が特定されたとする。処理サーバ２００は、基地局５００−１に実行用サブルールを送信するとともに、実行用サブルールのブロードキャストを依頼する。本実施形態では、処理サーバ２００は、上記（ｏ）に示す配置ルールに従って、実行用サブルールを５秒ごとに２回ブロードキャストするように依頼する。

基地局５００は、処理サーバ２００から受信した実行用サブルールを、自局の配下の端末３００−１、３００−２にブロードキャストする（ステップＳ１２０６）。

各端末のイベント制御部は、実行用サブルールが自端末に既に登録されているかどうかの重複チェックを行う（ステップＳ１２０７）。各端末は、重複チェックの結果、実行用サブルールが未登録の場合には、実行用サブルールを登録する（ステップＳ１２０８）。

ステップＳ１２０８の後、各端末のイベント制御部は、ＧＰＳイベント生成部から位置イベントが送信されるたびに、位置イベントと実行用サブルールとのマッチング処理を行う（ステップＳ１２０９、Ｓ１２１０）。

各端末のイベント制御部は、位置イベントが実行用サブルールにマッチした場合には、実行用サブルールのアクションを実行する（ステップＳ１２１１）。つまり、イベント制御部は、自端末の表示装置に危険を通知するための情報、例えば、アラート画面を表示するための画像情報を送信する。

ここで、端末３００−１、３００−２に実行用サブルールが登録された後に、基地局５００の配下に新たに端末が加わった場合のイベント処理システムの動作を説明する。

図１５は、第４の実施形態におけるイベント処理システムの新規端末加入時の動作を示すシーケンス図である。図１５は、基地局５００−１の配下に新たに端末３００−３が加わったときのイベント処理システムの動作を示す。

基地局５００は、端末３００−３が新規加入した後に実行用サブルールのブロードキャストを依頼された場合（ステップＳ１３０１）、端末３００−１、３００−２および３００−３に対して実行用サブルールをブロードキャストする（ステップＳ１３０２）。

各端末は、実行用サブルールが自端末に既に登録されているかどうかの重複チェックを行う（ステップＳ１３０３）。

端末３００−１、３００−２は、すでに実行用サブルールが登録されているので、実行用サブルールの登録処理は行わない。

新規加入した端末３００−３は、実行用サブルールが未登録であるため、実行用サブルールを登録する（ステップＳ１３０４）。

ステップＳ１３０４の後、端末３００−３は、図１４に示すステップＳ１２０９〜Ｓ１２１１の処理を実行する。

以上に説明したように、本実施形態では、処理サーバが危険イベントを受信した場合に、危険イベントを送信した端末を配下に接続する基地局に実行用サブルールのブロードキャストを依頼する。従って、処理サーバは、危険通知対象となる端末を特定するときに、各基地局のエリア情報を参照するだけでよい。よって、処理サーバ２００は、各端末から位置イベントを受信する必要がないので、端末、処理サーバおよびネットワークの負荷をさらに低減させることができる。

また、端末に位置イベントを通知させるための通知用サブルールを登録する必要がないので、通知用サブルールを端末に配置する処理をさらに軽減させることができる。また、端末のメモリ消費量を低減させることができるので、端末のメモリ資源がボトルネックとなることをより回避しやすい。

図１６は、本発明によるルール分配装置の最小構成を示すブロック図である。図１７は、本発明によるルール分配装置の他の最小構成を示すブロック図である。図１８は、本発明によるイベント処理システムの最小構成を示すブロック図である。

図１６に示すように、ルール分配装置１０（図２に示すルール分配装置１００に相当。）は、アプリケーション（図１に示すアプリケーション４００に相当。）が要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部１１（図２に示すルール分配装置１００におけるルール受信部１１０に相当。）と、処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末（図１に示す端末３００−１〜３００−ｎに相当。）に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、端末と通信可能でありイベント処理を実行可能な処理装置（図１に示す処理サーバ２００に相当。）に、配置ルールとサブルールとを送信するルール生成部１２（図２に示すルール分配装置１００における配置ルール生成部１３０およびサブルール生成部１４０に相当。）とを含む。

そのような構成によれば、端末、処理サーバおよびネットワークの負荷を増大させることなくＣＥＰルールを実行することができる。また、ＣＥＰにおいて動的な分散並列処理を実現することができる。また、サブルールを全端末に登録する必要がないので、サブルールを端末に配置する処理を軽減させることができる。また、端末のメモリ消費量を低減させることができる。従って、ネットワークにおけるリソースがボトルネックとなることを回避することができ、高いサービス品質を維持することができる。

上記の実施形態には、以下のようなルール分配装置も開示されている。

（１）イベント条件は、端末から受信したイベントの属性値が所定の範囲内に含まれるか否かを判定する範囲指定属性条件を含み、ルール生成部１２は、処理ルールの範囲指定属性条件の指定範囲をもとに当該指定範囲を含む新たな指定範囲を算出し、新たな指定範囲を配置ルールの範囲指定属性条件の指定範囲とするルール分配装置。

そのような構成によれば、範囲指定属性条件を含むイベント条件から構成されるＣＥＰルールを、端末、処理サーバおよびネットワークの負荷を増大させることなく実行することができる。

（２）ルール生成部１２は、ルール受信部１１が処理ルールを受信したときに、当該処理ルールをもとに、端末に初期動作をさせるための第２のサブルールを生成し、第２のサブルールを端末に送信するルール分配装置。

そのような構成によれば、ルール受信部が処理ルールを受信するまで、つまり、アプリケーションから処理ルールが登録されるまで、第２のサブルールを端末に登録しておく必要がない。従って、端末のメモリ消費量をより低減させることができる。また、第２のサブルールによる端末からのイベント送信を抑えることができるので、端末、処理サーバおよびネットワークの負荷を低減することができる。また、例えば、端末に配置ルールのイベント条件に必要なイベントの送信を初期動作として実行させることができる。

（３）ルール受信部１１は、固定エリアと端末とが指定範囲内に存在するか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部１２は、範囲指定属性条件をイベント条件とし、処理装置へ位置イベントを送信する処理をアクションとするサブルールを生成するルール分配装置。

そのような構成によれば、ＣＥＰルールのイベント条件にマッチしそうにない端末における不要なイベントの送信を抑えることができるので、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなくＣＥＰルールを実行することができる。

（４）ルール受信部１１は、端末同士が指定範囲内にいるか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部１２は、位置イベントの送信をアクションとし、イベント条件に位置イベントを送信する周期を指定したサブルールを生成するルール分配装置。

そのような構成によれば、監視対象となる一方の位置が固定されていない状態、つまり、監視対象となる双方の位置が固定されていないサービスにおいても、端末、処理サーバおよびネットワークの負荷を増大させることなくＣＥＰルールを実行することができる。

（５）ルール受信部１１は、位置イベントの送信元の端末と位置イベント以外のイベントの送信元の端末とが指定範囲内にいるか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部１２は、範囲指定属性条件をイベント条件とするサブルールを生成し、サブルールのアクションに処理ルールのアクションを設定するルール分配装置。

そのような構成によれば、ＣＥＰルールのイベント条件に位置イベント以外のイベントが含まれる場合であっても、端末、処理サーバおよびネットワークの負荷を増大させることなくＣＥＰルールを実行することができる。例えば、危険箇所事前通知サービスにおいてＣＥＰルールを実行する際に、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなく危険箇所事前通知サービスを提供することができる。

（６）ルール生成部１２は、処理装置と端末とが基地局（図１２に示す基地局５００−１〜５００−ｍに相当。）を介して接続されている場合には、基地局に対して、基地局に接続している端末にサブルールのブロードキャストを依頼するアクションを規定した配置ルールを処理装置に送信するルール分配装置。

そのような構成によれば、実行用サブルールの通知対象となる端末を特定するときに、各基地局のエリア情報を参照するだけでよい。従って、処理サーバは、各端末から位置イベントを受信する必要がないので、端末、処理サーバおよびネットワークの負荷をさらに低減させることができる。また、端末に位置イベントを通知させるための通知用サブルールを登録する必要がないので、通知用サブルールを端末に配置する処理をさらに軽減させることができる。また、端末のメモリ消費量を低減させることができるので、端末のメモリ資源がボトルネックとなることをより回避しやすい。

（７）ルール生成部１２は、サブルールが登録された端末から当該サブルールを削除するための削除ルールを生成し、当該サブルールを削除するタイミングを指定したイベント条件を削除ルールに設定し、削除ルールを処理装置に送信するルール分配装置。

そのような構成によれば、端末におけるサブルールによるマッチング処理が必要なくなったときに、端末からサブルールを削除することができる。それにより、端末のメモリ消費量およびＣＰＵリソース消費量をより低減することができる。

（８）図１７に示すように、処理装置および端末から処理能力を示す情報を受信する事前情報取得部１３（図２に示すルール分配装置１００における事前情報取得部１２０に相当。）と、事前情報取得部１３が取得した処理能力を示す情報を記憶する事前情報記憶部１４（図２に示すルール分配装置１００における事前情報記憶部１５０に相当。）とを含み、ルール生成部１２は、事前情報記憶部１４が記憶する情報をもとに、第２のサブルールを送信する端末を決定するルール分配装置。

そのような構成によれば、処理装置および端末の処理能力に応じて、配置ルールのイベント条件に必要なイベントを送信させる端末を決定することができる。

（９）図１７に示すように、処理ルールの削除要求を受信した場合に、当該処理ルールから生成した配置ルールの削除要求を当該配置ルールを登録した処理装置に送信し、当該処理ルールから生成したサブルールの削除要求を当該サブルールを登録した端末に送信するルール削除部１５（図２に示すルール分配装置１００におけるルール削除部（図示せず）に相当）を備えるルール分配装置。

そのような構成によれば、ルール分配装置、処理サーバおよび端末のメモリ消費量およびＣＰＵリソース消費量をより低減することができる。

なお、図１７に示すルール分配装置は、事前情報取得部１３、事前情報記憶部１４およびルール削除部１５を含むが、事前情報取得部１３および事前情報記憶部１４と、ルール削除部１５とのいずれかを含んでいてもよい。

また、上記の実施形態には、図１８に示すようなイベント処理システムも開示されている。

（１０）ルール分配装置１０と、端末３０−１〜３０−ｎ（図１に示す端末３００−１〜３００−ｎに相当。）と通信可能でありイベント処理を実行可能な処理装置２０（図１に示す処理サーバ２００に相当。）とを含み、ルール分配装置１０は、アプリケーションが要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部１１と、処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末３０−１〜３０−ｎに登録するタイミングを指定したイベント条件を含む配置ルールを生成し、配置ルールとサブルールとを処理装置２０に送信するルール生成部１２とを含み、処理装置２０は、配置ルールのイベント条件に従って端末が通知するイベントとのマッチング処理を実行し、イベントがイベント条件にマッチした場合には、当該端末にサブルールを送信する制御部２１（図１に示す処理サーバ２００における制御部（図示せず）に相当。）を備えるイベント処理システム。

そのような構成によれば、端末、処理サーバおよびネットワークの負荷を増大させることなくＣＥＰルールを実行することができる。また、ＣＥＰにおいて動的な分散並列処理を実現することができる。また、サブルールを全端末に登録する必要がないので、サブルールを端末に配置する処理を軽減させることができる。また、端末のメモリ消費量を低減させることができる。従って、ネットワークにおけるリソースがボトルネックとなることを回避することができ、高いサービス品質を維持することができる。

また、上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下
に限られない。

（付記１）ルール分配装置１０と、端末３０−１〜３０−ｎと通信可能でありイベント処理を実行可能な処理装置２０とを含み、ルール分配装置１０は、アプリケーションが要求するアクションとアクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部１１と、処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、サブルールをイベントを送信する端末３０−１〜３０−ｎに登録するタイミングを指定したイベント条件を含む配置ルールを生成し、配置ルールとサブルールとを処理装置２０に送信するルール生成部１２とを含み、処理装置２０は、配置ルールのイベント条件に従って端末が通知するイベントとのマッチング処理を実行し、イベントがイベント条件にマッチした場合には、当該端末にサブルールを送信する制御部２１を備えるイベント処理システム。

（付記２）イベント条件は、端末３０−１〜３０−ｎから受信したイベントの属性値が所定の範囲内に含まれるか否かを判定する範囲指定属性条件を含み、ルール生成部１２は、処理ルールの範囲指定属性条件の指定範囲をもとに当該指定範囲を含む新たな指定範囲を算出し、新たな指定範囲を配置ルールの範囲指定属性条件の指定範囲とする付記１に記載のイベント処理システム。

そのような構成によれば、範囲指定属性条件を含むイベント条件から構成されるＣＥＰルールを、端末、処理サーバおよびネットワークの負荷を増大させることなく実行することができる。

（付記３）ルール生成部１２は、ルール受信部１１が処理ルールを受信したときに、当該処理ルールをもとに、端末に初期動作をさせるための第２のサブルールを生成し、第２のサブルールを端末に送信する付記１または付記２に記載のイベント処理システム。

そのような構成によれば、ルール受信部が処理ルールを受信するまで、つまり、アプリケーションから処理ルールが登録されるまで、第２のサブルールを端末に登録しておく必要がない。従って、端末のメモリ消費量をより低減させることができる。また、第２のサブルールによる端末からのイベント送信を抑えることができるので、端末、処理サーバおよびネットワークの負荷を低減することができる。また、例えば、端末に配置ルールのイベント条件に必要なイベントの送信を初期動作として実行させることができる。

（付記４）ルール受信部１１は、固定エリアと端末とが指定範囲内に存在するか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部１２は、範囲指定属性条件をイベント条件とし、処理装置２０へ位置イベントを送信する処理をアクションとするサブルールを生成する付記１から付記３のうちのいずれか１つに記載のイベント処理システム。

そのような構成によれば、ＣＥＰルールのイベント条件にマッチしそうにない端末における不要なイベントの送信を抑えることができるので、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなくＣＥＰルールを実行することができる。

（付記５）ルール受信部１１は、端末同士が指定範囲内にいるか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部１２は、位置イベントの送信をアクションとし、イベント条件に位置イベントを送信する周期を指定したサブルールを生成する付記１から付記３のうちのいずれか１つに記載のイベント処理システム。

そのような構成によれば、監視対象となる一方の位置が固定されていない状態、つまり、監視対象となる双方の位置が固定されていないサービスにおいても、端末、処理サーバおよびネットワークの負荷を増大させることなくＣＥＰルールを実行することができる。

（付記６）ルール受信部１１は、位置イベントの送信元の端末と位置イベント以外のイベントの送信元の端末とが指定範囲内にいるか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、ルール生成部１２は、範囲指定属性条件をイベント条件とするサブルールを生成し、サブルールのアクションに処理ルールのアクションを設定する付記１から付記３のうちのいずれか１つに記載のイベント処理システム。

そのような構成によれば、ＣＥＰルールのイベント条件に位置イベント以外のイベントが含まれる場合であっても、端末、処理サーバおよびネットワークの負荷を増大させることなくＣＥＰルールを実行することができる。例えば、危険箇所事前通知サービスにおいてＣＥＰルールを実行する際に、端末と処理サーバ間の通信回数を最小限に抑えることができる。よって、端末、処理サーバおよびネットワークの負荷を増大させることなく危険箇所事前通知サービスを提供することができる。

（付記７）ルール生成部１２は、処理装置２０と端末３０−１〜３０−ｎとが基地局を介して接続されている場合には、基地局に対して、基地局に接続している端末にサブルールのブロードキャストを依頼するアクションを規定した配置ルールを処理装置２０に送信する付記６に記載のイベント処理システム。

そのような構成によれば、実行用サブルールの通知対象となる端末を特定するときに、各基地局のエリア情報を参照するだけでよい。従って、処理サーバは、各端末から位置イベントを受信する必要がないので、端末、処理サーバおよびネットワークの負荷をさらに低減させることができる。また、端末に位置イベントを通知させるための通知用サブルールを登録する必要がないので、通知用サブルールを端末に配置する処理をさらに軽減させることができる。また、端末のメモリ消費量を低減させることができるので、端末のメモリ資源がボトルネックとなることをより回避しやすい。

（付記８）ルール生成部１２は、サブルールが登録された端末３０−１〜３０−ｎから当該サブルールを削除するための削除ルールを生成し、当該サブルールを削除するタイミングを指定したイベント条件を削除ルールに設定し、削除ルールを処理装置２０に送信する付記１から付記７のうちのいずれか１つに記載のイベント処理システム。

そのような構成によれば、端末におけるサブルールによるマッチング処理が必要なくなったときに、端末からサブルールを削除することができる。それにより、端末のメモリ消費量およびＣＰＵリソース消費量をより低減することができる。

（付記９）ルール分配装置１０は、処理装置２０および端末３０−１〜３０−ｎから処理能力を示す情報を受信する事前情報取得部１３と、事前情報取得部１３が取得した処理能力を示す情報を記憶する事前情報記憶部１４とを含み、ルール生成部１２は、事前情報記憶部１４が記憶する情報をもとに、第２のサブルールを送信する端末を決定する付記３から付記８のうちのいずれか１つに記載のイベント処理システム。

そのような構成によれば、処理装置および端末の処理能力に応じて、配置ルールのイベント条件に必要なイベントを送信させる端末を決定することができる。

（付記１０）ルール分配装置１０は、処理ルールの削除要求を受信した場合に、当該処理ルールから生成した配置ルールの削除要求を当該配置ルールを登録した処理装置２０に送信し、当該処理ルールから生成したサブルールの削除要求を当該サブルールを登録した端末に送信するルール削除部１５を備える付記１から付記９のうちのいずれか１つに記載のイベント処理システム。

そのような構成によれば、ルール分配装置、処理サーバおよび端末のメモリ消費量およびＣＰＵリソース消費量をより低減することができる。

この出願は、２０１２年８月３１日に出願された日本特許出願２０１２−１９１２６０を基礎とする優先権を主張し、その開示の全てをここに取り込む。

以上、実施形態を参照して本願発明を説明したが、本願発明は上記の実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

１０、１００ ルール分配装置
１１、１１０ ルール受信部
１２ ルール生成部
１３、１２０ 事前情報取得部
１４、 １５０ 事前情報記憶部
１５ ルール削除部
２０ 処理装置
２１ 制御部
３０−１〜３０−ｎ、３００、３００−１〜３００−ｎ 端末
１３０ 配置ルール生成部
１４０ サブルール生成部
１６０ イベント端末対応テーブル
２００ 処理サーバ
４００ アプリケーション
５００−１〜５００−ｍ 基地局

Claims (13)

1. アプリケーションが要求するアクションと前記アクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部と、
   前記処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、前記サブルールをイベントを送信する端末に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、前記端末と通信可能でありイベント処理を実行可能な処理装置に、前記配置ルールと前記サブルールとを送信するルール生成部とを含む
   ことを特徴とするルール分配装置。
2. イベント条件は、端末から受信したイベントの属性値が所定の範囲内に含まれるか否かを判定する範囲指定属性条件を含み、
   ルール生成部は、処理ルールの範囲指定属性条件の指定範囲をもとに当該指定範囲を含む新たな指定範囲を算出し、前記新たな指定範囲を配置ルールの範囲指定属性条件の指定範囲とする
   請求項１に記載のルール分配装置。
3. ルール生成部は、ルール受信部が処理ルールを受信したときに、当該処理ルールをもとに、端末に初期動作をさせるための第２のサブルールを生成し、前記第２のサブルールを端末に送信する
   請求項１または請求項２に記載のルール分配装置。
4. ルール受信部は、固定エリアと端末とが指定範囲内に存在するか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、
   ルール生成部は、前記範囲指定属性条件をイベント条件とし、処理装置へ位置イベントを送信する処理をアクションとするサブルールを生成する
   請求項１から請求項３のうちのいずれか１項に記載のルール分配装置。
5. ルール受信部は、端末同士が指定範囲内にいるか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、
   ルール生成部は、位置イベントの送信をアクションとし、イベント条件に位置イベントを送信する周期を指定したサブルールを生成する
   請求項１から請求項３のうちのいずれか１項に記載のルール分配装置。
6. ルール受信部は、位置イベントの送信元の端末と位置イベント以外のイベントの送信元の端末とが指定範囲内にいるか否かを判定する範囲指定属性条件をイベント条件に含む処理ルールを受信し、
   ルール生成部は、前記範囲指定属性条件をイベント条件とするサブルールを生成し、前記サブルールのアクションに前記処理ルールのアクションを設定する
   請求項１から請求項３のうちのいずれか１項に記載のルール分配装置。
7. ルール生成部は、処理装置と端末とが基地局を介して接続されている場合には、基地局に対して、基地局に接続している端末にサブルールのブロードキャストを依頼するアクションを規定した配置ルールを前記処理装置に送信する
   請求項６に記載のルール分配装置。
8. ルール生成部は、サブルールが登録された端末から当該サブルールを削除するための削除ルールを生成し、当該サブルールを削除するタイミングを指定したイベント条件を前記削除ルールに設定し、前記削除ルールを処理装置に送信する
   請求項１から請求項７のうちのいずれか１項に記載のルール分配装置。
9. 処理装置および端末から処理能力を示す情報を受信する事前情報取得部と、前記事前情報取得部が取得した処理能力を示す情報を記憶する事前情報記憶部とを含み、
   ルール生成部は、事前情報記憶部が記憶する情報をもとに、第２のサブルールを送信する端末を決定する
   請求項３から請求項８のうちのいずれか１項に記載のルール分配装置。
10. 処理ルールの削除要求を受信した場合に、当該処理ルールから生成した配置ルールの削除要求を当該配置ルールを登録した処理装置に送信し、当該処理ルールから生成したサブルールの削除要求を当該サブルールを登録した端末に送信するルール削除部を備える
    請求項１から請求項９のうちのいずれか１項に記載のルール分配装置。
11. ルール分配装置と、端末と通信可能でありイベント処理を実行可能な処理装置とを含み、
    前記ルール分配装置は、
    アプリケーションが要求するアクションと前記アクションを実行するイベント条件とを規定した処理ルールを受信するルール受信部と、
    前記処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、前記サブルールをイベントを送信する端末に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、前記配置ルールと前記サブルールとを前記処理装置に送信するルール生成部とを含み、
    前記処理装置は、
    前記配置ルールのイベント条件に従って端末が通知するイベントとのマッチング処理を実行し、前記イベントが前記イベント条件にマッチした場合には、当該端末に前記サブルールを送信する制御部を備える
    ことを特徴とするイベント処理システム。
12. アプリケーションが要求するアクションと前記アクションを実行するイベント条件とを規定した処理ルールを受信し、
    前記処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、前記サブルールをイベントを送信する端末に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、前記端末と通信可能でありイベント処理を実行可能な処理装置に、前記配置ルールと前記サブルールとを送信する
    ことを特徴とするルール分配方法。
13. コンピュータに、
    アプリケーションが要求するアクションと前記アクションを実行するイベント条件とを規定した処理ルールを受信する処理と、
    前記処理ルールのイベント条件が含む１つ以上の属性条件の一部を判定させるまたは全部を判定させるまたはイベントを送信するタイミングを変更するサブルールを生成し、前記サブルールをイベントを送信する端末に登録するタイミングを指定したイベント条件を含む配置ルールを生成し、前記端末と通信可能でありイベント処理を実行可能な処理装置に、前記配置ルールと前記サブルールとを送信する処理とを実行させる
    ためのルール分配プログラム。

Images