(57)【要約】  ネットワークの負荷および処理サーバの負荷を低減しつつ、大量のイベントをリアルタイムに処理することができるルール分配装置、イベント処理システム、ルール分配方法およびルール分配プログラムを提供する。アプリケーションが要求するイベント処理とイベント処理を実行するためのイベント条件とを規定した処理ルールを入力するルール受信部１１と、処理ルールのイベント条件に含まれる属性の中からキー属性を決定するキー属性決定部１４と、キー属性に対応付けられた処理装置の中から選択した処理装置に処理ルールを配置するルール分配先算出部１３と、デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、デバイスと処理装置との間に設置されたイベント振り分け装置に当該イベント振り分けルールを配置する振り分けルール生成部１５とを備える。
2014034037.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションが要求するイベント処理と前記イベント処理を実行するためのイベント条件とを規定した処理ルールを入力するルール受信部と、
前記処理ルールのイベント条件に含まれる属性の中からキー属性を決定するキー属性決定部と、
当該キー属性に対応付けられた処理装置の中から選択した処理装置に前記処理ルールを配置するルール分配先算出部と、
デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、前記デバイスと処理装置との間に設置されたイベント振り分け装置に当該イベント振り分けルールを配置する振り分けルール生成部とを備えた
ことを特徴とするルール分配装置。
【請求項２】
キー属性決定部は、処理ルールのイベント条件に含まれるイベントについて、前記イベントに含まれる各属性の属性値の和集合を算出し、和集合のサイズが最も小さい属性を当該処理ルールのキー属性とする
請求項１に記載のルール分配装置。
【請求項３】
ルール分配先算出部は、処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性をキー属性としたときの当該処理ルールの分配先を算出し、当該処理ルールの配置前と配置後の分配先の全処理ルールについて当該属性の属性値の和集合を算出し、
キー属性決定部は、算出結果をもとに、属性値の和集合の要素の増加数が最も小さい属性を特定し、特定した属性を当該処理ルールのキー属性とする
請求項１または請求項２に記載のルール分配装置。
【請求項４】
入力した処理ルールを保持し、保持する処理ルールの並び替えを実行するルール並び替え部を備え、
ルール並び替え部は、保持する処理ルールごとに、キー属性の属性値の和集合を求め、前記和集合のサイズが大きい順に処理ルールを並び替え、
ルール分配先算出部は、前記ルール並び替え部が並び替えた順番にもとづいて、処理ルールを各処理装置に配置する
請求項１から請求項３のうちのいずれか１項に記載のルール分配装置。
【請求項５】
属性値と当該属性値を含むイベントを処理する処理装置とを対応付けた属性値担当サーバ情報を保持する属性値担当サーバ解決部を備え、
キー属性決定部は、ルール受信部が入力した処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性に指定されている属性値に対応づけられた処理装置の一覧を示すサーバＩＤ集合を前記属性値担当サーバ解決部から取得し、取得したサーバＩＤ集合をもとにキー属性を決定する
請求項１から請求項４のうちのいずれか１項に記載のルール分配装置。
【請求項６】
ルール分配先算出部は、サーバＩＤ集合をもとに、ルール受信部が入力した処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性に指定されている属性値に対応づけられた各処理装置について、前記処理ルールの配置前と配置後の当該処理装置の全処理ルールについて当該属性の属性値の和集合を算出し、算出した和集合の要素の増加数が最も小さい処理装置を当該属性の分配先として選択し、
キー属性決定部は、各属性の中から、分配先における前記和集合の要素の増加数が最も小さい属性をキー属性に決定する
請求項５に記載のルール分配装置。
【請求項７】
ルール受信部が受信した処理ルールのイベント条件に含まれるイベントの各属性の属性値が限定できない場合、いずれかの属性を分割対象属性とし、前記分割対象属性を限定するための属性値を生成し、生成した属性値をもとに複数のイベント条件を生成し、前記複数のイベント条件の各々を前記処理ルールに付加して新たな複数の処理ルールに分割するルール分割部を備える
請求項１から請求項６のうちのいずれか１項に記載のルール分配装置。
【請求項８】
ルール分割部は、処理ルールのイベント条件に含まれるイベントの各属性を分割対象属性とした場合に、当該属性に対する属性値の数が分割後に最も小さくなる属性、または、分割後に新たに生成される処理ルールの数が最も小さくなる属性を分割対象属性として選択する
請求項７に記載のルール分配装置。
【請求項９】
キー属性決定部は、ルール受信部が入力した処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性が候補キー属性であるか否かを判定し、候補キー属性であると判断した属性の中からキー属性を決定する
請求項１から請求項８のうちのいずれか１項に記載のルール分配装置。
【請求項１０】
処理ルールに従ってイベント処理を実行する処理装置と、
前記処理装置に処理ルールを配置するルール分配装置と、
デバイスが発したイベントを前記処理装置に振り分けるイベント振り分け装置とを備え、
前記ルール分配装置は、
アプリケーションが要求するイベント処理と前記イベント処理を実行するためのイベント条件とを規定した処理ルールを入力するルール受信部と、
前記処理ルールのイベント条件に含まれる属性の中からキー属性を決定するキー属性決定部と、
当該キー属性に対応付けられた処理装置の中から選択した処理装置に前記処理ルールを配置するルール分配先算出部と、
デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、前記イベント振り分け装置に配置する振り分けルール生成部とを備えた
ことを特徴とするイベント処理システム。
【請求項１１】
アプリケーションが要求するイベント処理と前記イベント処理を実行するためのイベント条件とを規定した処理ルールを入力し、
前記処理ルールのイベント条件に含まれる属性の中からキー属性を決定し、
当該キー属性に対応付けられた処理装置の中から選択した処理装置に前記処理ルールを配置し、
デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、前記デバイスと処理装置との間に設置されたイベント振り分け装置に当該イベント振り分けルールを配置する
ことを特徴とするルール分配方法。
【請求項１２】
コンピュータに、
アプリケーションが要求するイベント処理と前記イベント処理を実行するためのイベント条件とを規定した処理ルールを入力する処理と、
前記処理ルールのイベント条件に含まれる属性の中からキー属性を決定する処理と、
当該キー属性に対応付けられた処理装置の中から選択した処理装置に前記処理ルールを配置する処理と、
デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、前記デバイスと処理装置との間に設置されたイベント振り分け装置に当該イベント振り分けルールを配置する処理とを実行させる
ためのルール分配プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、大量のイベントをリアルタイムに処理するルール分配装置、イベント処理システム、ルール分配方法およびルール分配プログラムに関する。
【背景技術】
【０００２】
センサ等の複数のデバイス（端末）から送信されるイベントをリアルタイムに処理するイベント処理システムがある。イベント処理システムでは、システム内の複数の処理サーバが、複合イベント処理（Ｃｏｍｐｌｅｘ  Ｅｖｅｎｔ  Ｐｒｏｃｅｓｓｉｎｇ（ＣＥＰ）により、サーバ等に具備されたアプリケーションから要求されたイベント処理を実行する。具体的には、各アプリケーションが要求するイベント処理とイベント処理を実行するためのイベント条件とを規定したルール（以下、ＣＥＰルールまたは処理ルールという。）が各処理サーバに登録され、各処理サーバが処理ルールに従って並列に処理を実行する。それにより、大量イベントのリアルタイム処理が可能になる。【０００３】
イベントは、端末がセンシングしたデータであって、１つ以上の属性を含む。属性とは、データの種類を表す属性名と、データの値を表す属性値とから構成される。例えば、２つの属性「ユーザＩＤ」、「エリアＩＤ」を含むイベントは、次のように表すことができる。【０００４】
ＥＶＥＮＴ（１，＊）【０００５】
“１”は、属性「ユーザＩＤ」に対する属性値である。“＊”は、属性「エリアＩＤ」に対する属性値である。なお、“＊”は、任意の値を示す。【０００６】
端末の数が増大した場合、各端末から発生するイベントの量は膨大になる。このように、端末から大量のイベントが発せられると、端末と処理サーバとの間で頻繁に通信が行われる。それにより、処理サーバやネットワークの負荷が増大し、処理サーバやネットワークがイベント処理のボトルネックとなる場合がある。そのような場合、アプリケーションは、サービス品質を維持することができない。従って、イベント処理システムにおいては、処理ルールを細粒度化して、端末が発する時系列データ（イベント）の負荷増減に対応して、サーバ間で動的かつ高速にイベント処理を分散等することが必要とされる。【０００７】
各処理サーバの処理負荷を分散させるシステムとして、特許文献１に記載されたシステムがある。特許文献１に記載されたシステムは、アプリケーションから新しく処理ルールを受信した際に、それぞれの処理サーバが設定された処理ルールを実行するために必要なイベントが適切に分配されるように、処理ルールの分配先を決める制御をする。具体的には、イベントのマルチキャストが発生しないように、つまり、複数の処理サーバが同じイベントを必要とすることがないように、各処理サーバに処理ルールを配置する。それにより、それぞれの処理サーバが異なったイベント処理を行い、処理サーバの負荷分散を実現することができる。【０００８】
図２６は、特許文献１に記載されたシステムにおけるルール配置の様子を示す説明図である。特許文献１に記載されたシステムは、予め指定された特定の属性（以下、キー属性という。）の値をもとにルール分配を行う。図２６は、アプリケーションからＲｕｌｅ１〜Ｒｕｌｅ３が登録されたときのルール配置を示す。Ｒｕｌｅ１〜Ｒｕｌｅ３の構成を以下に示す。【０００９】
Ｒｕｌｅ１（Ｅｖｅｎｔ（１，＊）＆Ｅｖｅｎｔ（２，＊），ａｃｔｉｏｎ−ｘ）
Ｒｕｌｅ２（Ｅｖｅｎｔ（２，＊）＆Ｅｖｅｎｔ（３，＊），ａｃｔｉｏｎ−ｙ）
Ｒｕｌｅ３（Ｅｖｅｎｔ（４，＊）＆Ｅｖｅｎｔ（５，＊），ａｃｔｉｏｎ−ｚ）【００１０】
Ｒｕｌｅ１，Ｒｕｌｅ２はともに、キー属性「ユーザＩＤ」の属性値が“２”であるイベントをイベント条件に含む。従って、特許文献１に記載されたシステムは、Ｒｕｌｅ１，Ｒｕｌｅ２を、同一のサーバ（処理サーバ９００−１）に配置する。このように関連性が高いルールを極力同一サーバ上に割り当てることにより、例えば、Ｅｖｅｎｔ（２，Ｂ）のマルチキャストを回避することができる。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特許第４１６１９９８号
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかし、特許文献１に記載されたシステムでは、キー属性の値のみを元に、処理ルールを配置する処理サーバを決定する。また、特許文献１に記載されたシステムは、イベントが複数の属性を含む場合であっても、１つのキー属性のみにもとづいてルール分配を行う。従って、キー属性の値を限定しない処理ルールがアプリケーションから登録された場合、マルチキャストが発生する可能性がある。例えば、キー属性の属性値に“＊”が設定された処理ルールがアプリケーションから登録された場合、イベントのマルチキャストが発生する可能性がある。また、キー属性の属性値が大量に指定されるルールがアプリケーションから登録された場合、同様に、マルチキャストが発生する可能性がある。【００１３】
図２７は、特許文献１に記載されたシステムがキー属性の値を限定しないルールを受信したときのルール配置の様子を示す説明図である。図２７は、アプリケーションからＲｕｌｅ４、Ｒｕｌｅ５が新たに登録されたときのルール配置を示す。Ｒｕｌｅ４、Ｒｕｌｅ５の構成を以下に示す。【００１４】
Ｒｕｌｅ４（Ｅｖｅｎｔ（＊，Ａ）＆Ｅｖｅｎｔ（＊，Ｂ），ａｃｔｉｏｎ−ａ）
Ｒｕｌｅ５（Ｅｖｅｎｔ（１，Ａ）＆Ｅｖｅｎｔ（２，Ａ）＆Ｅｖｅｎｔ（３，Ａ）＆Ｅｖｅｎｔ（４，Ａ）＆Ｅｖｅｎｔ（５，Ａ），ａｃｔｉｏｎ−ｂ）【００１５】
ルール配置が図２６に示す状態であるときに、キー属性の値が“＊”である処理ルール（Ｒｕｌｅ４）と、キー属性値が大量に指定される処理ルール（Ｒｕｌｅ５）とがアプリケーションから登録された場合、Ｒｕｌｅ４、Ｒｕｌｅ５は、例えば、図２７に示すように配置される。この場合、例えばＥｖｅｎｔ（１，Ａ）は、処理サーバ９００−１、９００−２、９００−ｎの３つの処理サーバに対してマルチキャストされる。【００１６】
従って、特許文献１に記載されたシステムでは、キー属性の値を限定しない処理ルールがアプリケーションから登録された場合、イベントのマルチキャストが発生し、ネットワークの負荷が増大する可能性がある。また、イベントのマルチキャストが発生することによりイベントの増加に対してスケールアウトすることができず、処理サーバの負荷が増大する可能性がある。【００１７】
そこで、本発明は、ネットワークの負荷および処理サーバの負荷を低減しつつ、大量のイベントをリアルタイムに処理することができるルール分配装置、イベント処理システム、ルール分配方法およびルール分配プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明によるルール分配装置は、アプリケーションが要求するイベント処理とイベント処理を実行するためのイベント条件とを規定した処理ルールを入力するルール受信部と、処理ルールのイベント条件に含まれる属性の中からキー属性を決定するキー属性決定部と、当該キー属性に対応付けられた処理装置の中から選択した処理装置に処理ルールを配置するルール分配先算出部と、デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、デバイスと処理装置との間に設置されたイベント振り分け装置に当該イベント振り分けルールを配置する振り分けルール生成部とを備えたことを特徴とする。【００１９】
本発明によるイベント処理システムは、処理ルールに従ってイベント処理を実行する処理装置と、処理装置に処理ルールを配置するルール分配装置と、デバイスが発したイベントを処理装置に振り分けるイベント振り分け装置とを備え、ルール分配装置は、アプリケーションが要求するイベント処理とイベント処理を実行するためのイベント条件とを規定した処理ルールを入力するルール受信部と、処理ルールのイベント条件に含まれる属性の中からキー属性を決定するキー属性決定部と、当該キー属性に対応付けられた処理装置の中から選択した処理装置に処理ルールを配置するルール分配先算出部と、デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、イベント振り分け装置に配置する振り分けルール生成部とを備えたことを特徴とする。【００２０】
本発明によるルール分配方法は、アプリケーションが要求するイベント処理とイベント処理を実行するためのイベント条件とを規定した処理ルールを入力し、処理ルールのイベント条件に含まれる属性の中からキー属性を決定し、当該キー属性に対応付けられた処理装置の中から選択した処理装置に処理ルールを配置し、デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、デバイスと処理装置との間に設置されたイベント振り分け装置に当該イベント振り分けルールを配置することを特徴とする。【００２１】
本発明によるルール分配プログラムは、コンピュータに、アプリケーションが要求するイベント処理とイベント処理を実行するためのイベント条件とを規定した処理ルールを入力する処理と、処理ルールのイベント条件に含まれる属性の中からキー属性を決定する処理と、当該キー属性に対応付けられた処理装置の中から選択した処理装置に処理ルールを配置する処理と、デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、デバイスと処理装置との間に設置されたイベント振り分け装置に当該イベント振り分けルールを配置する処理とを実行させることを特徴とする。
【発明の効果】
【００２２】
本発明によれば、ネットワークの負荷および処理サーバの負荷を低減しつつ、大量のイベントをリアルタイムに処理することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明によるルール分配装置を含むイベント処理システムの構成の一例を示すブロック図である。
【図２】ルール分配装置の第１の実施形態の構成を示すブロック図である。
【図３】イベント処理システムの第１の実施形態の動作を示すシーケンス図である。
【図４】ルール分配装置の第１の実施形態の動作を示すシーケンス図である。
【図５】キー属性決定部がキー属性を決定する処理を示すフローチャートである。
【図６】イベント処理システムがキー属性の値を限定しない処理ルールを受信したときのルール配置の様子を示す説明図である。
【図７】第２の実施形態におけるルール分配装置がキー属性を決定する処理を示すフローチャートである。
【図８】ルール分配装置の第３の実施形態における構成を示すブロック図である。
【図９】ルール並び替え部による処理ルールの並び替え処理を示すフローチャートである。
【図１０】ルール分配装置の第４の実施形態の構成を示すブロック図である。
【図１１】属性値担当サーバ情報の一例を示す説明図である。
【図１２】第４の実施形態におけるキー属性決定部の動作を示すフローチャートである。
【図１３】ルール分配装置の第５の実施形態の構成を示すブロック図である。
【図１４】エリアＩＤにもとづくルール分割処理を示すフローチャートである。
【図１５】複数のメッシュに分割されたエリアの一例を示す説明図である。
【図１６】距離条件を満たすメッシュの組み合わせの一覧を示す説明図である。
【図１７】イベント数が３つである処理ルールに対するエリアＩＤにもとづくルール分割処理を示すフローチャートである。
【図１８】各距離条件に対応するメッシュの組み合わせの一覧を結合した結果を示す説明図である。
【図１９】イベントａ、ｂに対応するユーザの組み合わせの一覧を示す説明図である。
【図２０】候補キー属性に対する値の数をもとに分割対象キー属性を決定する処理を示すフローチャートである。
【図２１】ルール数をもとに分割対象キー属性を決定する処理を示すフローチャートである。
【図２２】本発明によるルール分配装置の最小構成を示すブロック図である。
【図２３】本発明によるルール分配装置の他の最小構成を示すブロック図である。
【図２４】本発明によるルール分配装置の他の最小構成を示すブロック図である。
【図２５】本発明によるイベント処理システムの最小構成を示すブロック図である。
【図２６】特許文献１に記載されたシステムにおけるルール配置の様子を示す説明図である。
【図２７】特許文献１に記載されたシステムがキー属性の値を限定しないルールを受信したときのルール配置の様子を示す説明図である。
【発明を実施するための形態】
【００２４】
実施形態１．
以下、本発明の第１の実施形態を図面を参照して説明する。
【００２５】
図１は、本発明によるルール分配装置を含むイベント処理システムの構成の一例を示すブロック図である。
【００２６】
図１に示すイベント処理システムは、ルール分配装置１００と、処理サーバ２００−１〜２００−ｎと、ディスパッチャ３００−１〜３００−ｎとを備える。また、ルール分配装置１００および各処理サーバは、サーバ等に具備されたアプリケーション４００−１〜４００−ｎと通信可能に接続されている。また、イベント振り分け装置（以下、ディスパッチャという。）３００−１〜３００−ｎは、デバイス５００−１〜５００−ｎと通信可能に接続されている。
【００２７】
ルール分配装置１００は、アプリケーション４００−１〜４００−ｎから受信した処理ルールを各処理サーバに配置する。
【００２８】
ルール分配装置１００は、デバイス５００−１〜５００−ｎから受信したイベントを各処理サーバに分配するためのイベント振り分けルールを、各ディスパッチャに登録する。
【００２９】
処理サーバ２００−１〜２００−ｎは、各ディスパッチャから受信したイベントと、ルール分配装置１００が登録した処理ルールとをもとに、イベント処理を実行する。
【００３０】
処理サーバ２００−１〜２００−ｎは、キー属性ごとに分類される。つまり、各キー属性に対して処理サーバが割り当てられる。各処理サーバには、キー属性に対応する処理ルールが配置される。図１に示す処理サーバ２００−１〜２００−ｍは、キー属性「ユーザＩＤ」に割り当てられている。従って、処理サーバ２００−１〜２００−ｍには、キー属性「ユーザＩＤ」に対応する処理ルールが配置される。処理サーバ２００−（ｍ＋１）〜２００−ｎは、キー属性「エリアＩＤ」に割り当てられている。ただし、１＜ｍ＜ｎである。
【００３１】
なお、キー属性「ユーザＩＤ」、「エリアＩＤ」に限られず、その他の属性をキー属性としてもよい。また、キー属性は、いくつあってもよい。
【００３２】
また、キー属性に対する処理サーバの割り当ては、ユーザ等が処理サーバ等の負荷を予測して予め設定してもよい。また、キー属性に対する処理サーバの割り当ては、外部のパソコン（パーソナルコンピュータ）等から通信により動的に変更できるようにしてもよい。
【００３３】
ディスパッチャ３００−１〜３００−ｎは、デバイス５００−１〜５００−ｎから受信したイベントを、ディスパッチャルールに従って、各処理サーバに振り分ける。
【００３４】
デバイス５００−１〜５００−ｎは、例えば、センサである。デバイス５００−１〜５００−ｎは、センシングしたデータをイベントとして送信する。
【００３５】
図２は、ルール分配装置の第１の実施形態の構成を示すブロック図である。
【００３６】
図２に示すルール分配装置１００は、ルール受信部１１０と、サーバ割り当て部１２０と、ルール分配先算出部１３０と、キー属性決定部１４０と、振り分けルール生成部１５０とを備える。
【００３７】
ルール受信部１１０は、アプリケーション４００−１〜４００−ｎから処理ルールを受信する。
【００３８】
サーバ割り当て部１２０は、キー属性ごとに、キー属性とキー属性に対応する処理サーバとの対応を示す情報を保持する。
【００３９】
ルール分配先算出部１３０は、サーバ割り当て部１２０による割り当て結果と、キー属性決定部１４０が決定したキー属性とをもとに、どの処理サーバに処理ルールを配置するかを決定する。つまり、処理ルールの分配先を決定する。
【００４０】
キー属性決定部１４０は、アプリケーションから処理ルールが登録されたときに、処理ルールのイベント条件のイベントに含まれる属性のうち、どの属性をキー属性とするかを算出する。
【００４１】
振り分けルール生成部１５０は、イベントを各処理サーバに振り分けるためのイベント振り分けルールを生成し、生成したイベント振り分けルールをディスパッチャ３００−１〜３００−ｎに送信（登録）する。
【００４２】
なお、ルール受信部１１０、サーバ割り当て部１２０、ルール分配先算出部１３０、キー属性決定部１４０および振り分けルール生成部１５０は、ルール分配装置１００が備えるＣＰＵ等によって実現される。例えば、コンピュータ読み取り可能な記録媒体に記憶されたルール分配プログラムを、ＣＰＵが読み込み、ＣＰＵが、そのルール分配プログラムに従って、ルール受信部１１０、サーバ割り当て部１２０、ルール分配先算出部１３０、キー属性決定部１４０および振り分けルール生成部１５０として動作してもよい。
【００４３】
次に、本実施形態の動作を説明する。
【００４４】
図３は、イベント処理システムの第１の実施形態の動作を示すシーケンス図である。
【００４５】
ルール分配装置１００は、新規処理ルールが登録されると、つまり、アプリケーション４００（４００−１〜４００−ｎ）から新規に処理ルールを受信すると（ステップＳ３０１）、処理ルール分配先を算出する（ステップＳ３０２）。ここでは、処理ルール分配先として処理サーバ２００−２が算出されたとする。
【００４６】
ルール分配装置１００は、ステップＳ３０２で算出した処理ルール分配先（処理サーバ２００−２）に、新規処理ルールを送信する（ステップＳ３０３）。
【００４７】
処理サーバ２００−２は、受信した処理ルールを登録する。つまり、処理サーバ２００−２は、処理サーバ２００−２が備える記憶部（図示せず）等に処理ルールを格納する。
【００４８】
ルール分配装置１００は、イベント振り分けルールを生成する（ステップＳ３０４）。
【００４９】
ルール分配装置１００は、各ディスパッチャにイベント振り分けルールを送信する（ステップＳ３０５）。
【００５０】
各ディスパッチャは、受信したイベント振り分けルールを登録する。つまり、各ディスパッチャは、自装置が備える記憶部（図示せず）等にイベント振り分けルールを格納する。
【００５１】
ここで、ルール分配装置１００の動作の詳細を説明する。
【００５２】
図４は、ルール分配装置１００の第１の実施形態の動作を示すシーケンス図である。
【００５３】
キー属性決定部１４０は、ルール受信部１１０を介してアプリケーション４００（４００−１〜４００−ｎ）から新規処理ルールが登録されると（ステップＳ４０１）、新規処理ルールのキー属性を決定する（ステップＳ４０２）。
【００５４】
キー属性決定部１４０は、決定したキー属性を示す情報（以下、単にキー属性という。）を送信する（ステップＳ４０３）。
【００５５】
ルール分配先算出部１３０は、サーバＩＤを要求する（ステップＳ４０４）。具体的には、キー属性決定部１４０から受信したキー属性を、サーバ割り当て部１２０に送信する。サーバ割り当て部１２０は、当該キー属性に割り当てられた処理サーバのサーバＩＤをルール分配先算出部１３０に返す。例えば、受信したキー属性が「ユーザＩＤ」である場合には、キー属性「ユーザＩＤ」に割り当てられている処理サーバ２００（２００−１〜２００−ｍ）に対応するサーバＩＤを返す。
【００５６】
ルール分配先算出部１３０は、受信したサーバＩＤに対応する処理サーバの中から、処理ルールの分配先を算出する（ステップＳ４０５）。
【００５７】
ルール分配先算出部１３０は、算出した分配先に処理ルールを配置する（ステップＳ４０６）。
【００５８】
ステップＳ４０６の処理が実行された後、ルール分配先算出部１３０は、振り分けルール生成部１５０に振り分けルールの生成および配置を依頼する（ステップＳ４０７）。振り分けルール生成部１５０は、イベント振り分けルールを生成する（ステップＳ４０８）。振り分けルール生成部１５０は、イベント振り分けルールを各ディスパッチャに配置する（ステップＳ４０９）。
【００５９】
なお、ステップＳ４０５、Ｓ４０８の処理については、既知の手法を用いる。例えば、特許文献１に記載されている手法を用いる。
【００６０】
ここで、図５を参照して、ステップＳ４０２におけるキー属性決定部１２０の処理を説明する。
【００６１】
図５は、キー属性決定部１２０がキー属性を決定する処理を示すフローチャートである。ここでは、ルール受信部１１０が受信した３つの処理ルール（Ｒｕｌｅ１１、Ｒｕｌｅ１２、Ｒｕｌｅ１３）のキー属性が決定される場合を例にする。各処理ルールのイベント条件は、属性「ユーザＩＤ」、「エリアＩＤ」を含むイベントで構成されているとする。Ｒｕｌｅ１１、Ｒｕｌｅ１２、Ｒｕｌｅ１３の構成を以下に示す。
【００６２】
Ｒｕｌｅ１１（Ｅｖｅｎｔ（１０，＊）＆Ｅｖｅｎｔ（１１，＊））
Ｒｕｌｅ１２（Ｅｖｅｎｔ（１２，Ａ）＆Ｅｖｅｎｔ（１３，Ａ））
Ｒｕｌｅ１３（Ｅｖｅｎｔ（＊，Ｂ）＆Ｅｖｅｎｔ（＊，Ｃ））
【００６３】
キー属性決定部１２０は、新規処理ルールが登録されると（ステップＳ５０１）、処理ルールのイベント条件のイベントに含まれる各属性の和集合を算出する（ステップＳ５０２）。
【００６４】
属性の和集合は、属性に指定されている属性値の集合である。例えば、Ｒｕｌｅ１１（Ｅｖｅｎｔ（１０，＊）＆Ｅｖｅｎｔ（１１，＊））の場合、属性「ユーザＩＤ」の和集合は｛１０，１１｝となる。また、属性「エリアＩＤ」の和集合は｛Ａ，Ｂ，…｝となる。
【００６５】
キー属性決定部１２０は、各処理ルールについて、和集合のサイズ（以下、属性値数という。）が最も小さい属性をキー属性として選択する（ステップＳ５０３）。
【００６６】
例えば、Ｒｕｌｅ１１の場合は、属性「ユーザＩＤ」の和集合｛１０，１１｝のサイズは２である。また、属性「エリアＩＤ」の和集合｛Ａ，Ｂ，…｝のサイズは総エリア数である。従って、キー属性決定部１２０は、Ｒｕｌｅ１１のキー属性として「ユーザＩＤ」を選択する。Ｒｕｌｅ１２の場合は、属性「ユーザＩＤ」の和集合｛１２，１３｝のサイズは２である。また、属性「エリアＩＤ」の和集合｛Ａ｝のサイズは１である。従って、キー属性決定部１２０は、Ｒｕｌｅ１２のキー属性として「エリアＩＤ」を選択する。キー属性決定部１２０は、同様に、Ｒｕｌｅ１３のキー属性として「エリアＩＤ」を選択する。
【００６７】
図２７に示すＲｕｌｅ１〜５の場合は、Ｒｕｌｅ１〜３のキー属性として「ユーザＩＤ」が選択され、Ｒｕｌｅ４、５のキー属性として「エリアＩＤ」が選択される。この場合、Ｒｕｌｅ１〜３の分配先は、「ユーザＩＤ」に割り当てられた処理サーバの中から算出される。Ｒｕｌｅ４、５の分配先は、「エリアＩＤ」に割り当てられた処理サーバの中から算出される。
【００６８】
図２７に示す処理サーバ９００−１、９００−２が「ユーザＩＤ」に割り当てられ、９００−ｎが「エリアＩＤ」に割り当てられているとする。すると、アプリケーションからＲｕｌｅ１〜５が登録された場合には、図６に示すように各ルールが配置される。図６は、イベント処理システムがキー属性の値を限定しない処理ルールを受信したときのルール配置の様子を示す説明図である。
【００６９】
図６に示すように、Ｅｖｅｎｔ（１，Ａ）は、処理サーバ９００−１、９００−ｎの２つの処理サーバに対してマルキャストされる。つまり、Ｅｖｅｎｔ（１，Ａ）は処理サーバ９００−２には送信されない。従って、処理サーバ９００−２は、Ｅｖｅｎｔ（１，Ａ）を処理する必要がない。つまり、Ｅｖｅｎｔ（１，Ａ）をマルチキャストする処理サーバを１つ少なくすることができる。
【００７０】
以上に説明したように、本実施形態では、新規処理ルールのキー属性を決定し、決定したキー属性に割り当てられた処理サーバに、当該新規処理ルールを登録する。それにより、イベントのマルチキャストの発生を低減することができる。従って、本実施形態によれば、ディスパッチャおよび処理サーバの処理負荷、例えば、イベント処理や通信処理によるＣＰＵ負荷を低減することができるとともに、ネットワークの負荷を低減することができる。
【００７１】
なお、本実施形態では、イベント振り分けルールの生成をルール分配装置１００が行う場合について説明したが、各ディスパッチャがイベント振り分けルールを生成するようにしてもよい。そのような形態を実現するには、例えば、ルール分配装置１００に新規に処理ルールが登録されたときに、各ディスパッチャが、その処理ルールのイベント条件をルール分配装置１００から取得すればよい。そして、各ディスパッチャが、イベント条件と既に保持しているイベント条件とのＯＲ（論理和）を取ることにより、イベント振り分けルールを生成すればよい。
【００７２】
また、本実施形態では、サーバ割り当て部１２０が、各キー属性に対して、処理サーバ２００−１〜２００−ｎを割り当てる場合について説明したが、処理サーバ上で動作する仮想処理サーバに割り当てるようにしてもよい。そのような形態によれば、特定の処理サーバに負荷が集中することを回避することができる。例えば、イベントの発生が均一でないとき、つまり、特定のイベントの発生が増大したときなど、特定の処理サーバに負荷が集中する場合がある。そのような場合に、ルール分配先算出部１３０が仮想処理サーバを他の処理サーバに移動させることにより、特定の処理サーバに集中している負荷を分散させることができ、ロードバランスが可能となる。
【００７３】
実施形態２．
以下、本発明の第２の実施形態を図面を参照して説明する。
【００７４】
イベント処理システムおよびルール分配装置の第２の実施形態の構成は、第１の実施形態と同様であるため説明を省略する。
【００７５】
ただし、ルール分配先算出部１３０は、ルール受信部１１０が新規処理ルールを受信すると、処理サーバごとに、既に登録されている全処理ルールのキー属性の値の和集合を算出する。
【００７６】
次に、本実施形態の動作を説明する。
【００７７】
図７は、第２の実施形態におけるルール分配装置１００がキー属性を決定する処理を示すフローチャートである。ここで、ルール受信部１１０が受信した処理ルール（Ｒｕｌｅ１５）の分配先が算出される場合を例にする。本実施形態では、ルール分配装置１００に４つの処理サーバ２００−１〜２００−４が接続されているとする。そして、処理サーバ２００−１にＲｕｌｅ１１、処理サーバ２００−２にＲｕｌｅ１４、処理サーバ２００−３にＲｕｌｅ１２、処理サーバ２００−４にＲｕｌｅ１３が、それぞれ登録されているとする。また、処理サーバ２００−１、２００−２は、キー属性「ユーザＩＤ」に割り当てられているとする。処理サーバ２００−３、２００−４は、キー属性「エリアＩＤ」に割り当てられているとする。Ｒｕｌｅ１４、Ｒｕｌｅ１５の構成を以下に示す。
【００７８】
Ｒｕｌｅ１４（Ｅｖｅｎｔ（１２，Ｄ）＆Ｅｖｅｎｔ（１３，Ｅ））
Ｒｕｌｅ１５（Ｅｖｅｎｔ（１１，Ｂ）＆Ｅｖｅｎｔ（１２，Ｃ））
【００７９】
ルール分配先算出部１３０は、新規処理ルール（Ｒｕｌｅ１５）が登録されると（ステップＳ７０１）、処理サーバごとに、既に登録されている全処理ルールのキー属性の値の和集合を算出する（ステップＳ７０２）。
【００８０】
このとき、処理サーバ２００−１、処理サーバ２００−２、処理サーバ２００−３、処理サーバ２００−４における処理ルールのキー属性の値の和集合は、それぞれ、｛１０，１１｝、｛１２，１３｝、｛Ａ｝、｛Ｂ，Ｃ｝となる。
【００８１】
ルール分配先算出部１３０は、キー属性ごとに、ルール分配先の候補を算出する。つまり、ルール分配先算出部１３０は、「ユーザＩＤ」に割り当てられた処理サーバ２００−１、２００−２の中からＲｕｌｅ１５の分配先を算出する。また、「エリアＩＤ」に割り当てられた処理サーバ２００−３、２００−４の中からＲｕｌｅ１５の分配先を算出する（ステップＳ７０３）。ここでは、Ｒｕｌｅ１５の分配先の候補として、処理サーバ２００−１、２００−４が算出されたとする。
【００８２】
ルール分配先算出部１３０は、Ｒｕｌｅ１５を配置した場合の処理サーバ２００−１、２００−４について、全処理ルールのキー属性の値の和集合を算出する（ステップＳ７０４）。
【００８３】
Ｒｕｌｅ１５を処理サーバ２００−１に配置したと仮定した場合、処理サーバ２００−１に配置されている全処理ルール（Ｒｕｌｅ１１、Ｒｕｌｅ１５）のキー属性の値の和集合は、｛１０，１１，１２｝となる。また、Ｒｕｌｅ１５を処理サーバ２００−４に配置したと仮定した場合、処理サーバ２００−４に配置されている全処理ルール（Ｒｕｌｅ１３、Ｒｕｌｅ１５）のキー属性の値の和集合は、｛Ｂ，Ｃ｝となる。
【００８４】
キー属性決定部１２０は、処理サーバ２００−１、２００−４について、ステップＳ７０２で算出したキー属性の値の和集合とステップＳ７０４で算出したキー属性の値の和集合とを比較して、和集合の要素の増加数が小さい方の処理サーバに割り当てられているキー属性を選択する（ステップＳ７０５）。この場合、処理サーバ２００−１における処理ルールのキー属性の値の和集合は、要素数が２から３へ１増加している。また、処理サーバ２００−４における処理ルールのキー属性の値の和集合は、要素数が２のままであり、増加数は０である。従って、キー属性決定部１２０は、Ｒｕｌｅ１５についてキー属性「エリアＩＤ」を選択する。
【００８５】
以上に説明したように、本実施形態では、キー属性ごとに分類された処理サーバ群の中から分配先候補となる処理サーバをそれぞれ決定する。そして、処理サーバ群ごとに決定した分配先候補の各処理サーバについて、既に登録されている全処理ルールのキー属性の値の和集合を算出し、各処理サーバのうち、和集合の要素の増加数が最も小さい処理サーバを分配先として選択する。それにより、イベントのマルチキャストが少なくて済む処理サーバを分配先として選択することができる。
【００８６】
従って、本実施形態によれば、イベントのマルチキャストをより少なくすることができる。例えば、Ｒｕｌｅ１５のように、各属性の和集合の数が等しい場合、第１の実施形態のキー属性決定方法では、キー属性を正しく選択することができない場合がある。しかし、本実施形態では、各属性の和集合の数が等しい処理ルールが新規登録された場合であっても、マルチキャストがより少なくなるように、新規登録された処理ルールのキー属性を選択することができる。それにより、ネットワークの負荷をさらに低減することができる。
【００８７】
実施形態３．
以下、本発明の第３の実施形態を図面を参照して説明する。
【００８８】
イベント処理システムの第３の実施形態の構成は、第１の実施形態と同様であるため説明を省略する。
【００８９】
図８は、ルール分配装置の第３の実施形態における構成を示すブロック図である。
【００９０】
図８に示すルール分配装置６００は、ルール並び替え部１６０を備える。
【００９１】
ルール並び替え部１６０は、アプリケーション４００−１〜４００−ｎから登録された処理ルールを保持する。ルール並び替え部１６０は、例えば、予め定められたタイミング（以下、ルール並び替えタイミングという。）で定期的にまたは間欠的に、既に登録されている処理ルールの並び替えを行う。
【００９２】
なお、ルール並び替え部１６０は、ルール分配装置６００が備えるＣＰＵ等によって実現される。例えば、ＣＰＵが、ルール分配プログラムに従って、ルール並び替え部１６０として動作してもよい。
【００９３】
ルール分配装置６００のその他の構成は、第１の実施形態のルール分配装置１００と同様であるため説明を省略する。
【００９４】
図９は、ルール並び替え部１６０による処理ルールの並び替え処理を示すフローチャートである。
【００９５】
ルール並び替え部１６０は、ルール並び替えタイミングか否かを判定する（ステップＳ９０１）。ルール並び替え部１６０は、例えば、保持する処理ルールの数が予め定められた閾値を超えた場合にルール並び替えタイミングであると判断する。
【００９６】
ルール並び替え部１６０は、ルール並び替えタイミングであった場合には、ルール分配装置６００に既に登録されている処理ルール（以下、処理ルール群という。）の各属性の値の和集合を求める（ステップＳ９０２）。ここでは、Ｒｕｌｅ１１、Ｒｕｌｅ１２、Ｒｕｌｅ１３が既に登録されているとする。
【００９７】
ルール並び替え部１６０は、処理ルールごとに、各属性の属性値数を求め、属性値数の最小値を算出する（ステップＳ９０３）。すなわち、ルール並び替え部１６０は、処理ルールごとに、キー属性の属性値数を求める。
【００９８】
ルール並び替え部１６０は、キー属性ごとに、処理ルールの並び替えを行う（ステップＳ９０４）。つまり、キー属性が「ユーザＩＤ」であるＲｕｌｅ１１について並び替えを行う。また、キー属性が「エリアＩＤ」であるＲｕｌｅ１２、Ｒｕｌｅ１３について並び替えを行う。
【００９９】
このとき、キー属性の属性値数が大きい順に処理ルールを並び替える。Ｒｕｌｅ１２、Ｒｕｌｅ１３のキー属性の属性値数は、それぞれ、１、２である。従って、Ｒｕｌｅ１３、Ｒｕｌｅ１２の順に並び替えられる。キー属性が「ユーザＩＤ」である処理ルールはＲｕｌｅ１１のみのため、並び替えは行われない。
【０１００】
ルール並び替え部１６０は、各処理ルールを並び変えた順番にキー属性決定部１４０に送信する。以降のルール分配装置６００の処理は、第１の実施形態のルール分配装置１００のステップＳ４０２〜Ｓ４０７の処理と同様であるため、説明を省略する。
【０１０１】
次のように、本実施形態では、ルール並び替えタイミングに応じて、ルール分配の再実行を行う。ルール分配の再実行を行うことにより、イベントのマルチキャストを低減することができる。
【０１０２】
キー属性が「ユーザＩＤ」であるＲｕｌｅ２１、Ｒｕｌｅ２２、Ｒｕｌｅ２３、Ｒｕｌｅ２４、Ｒｕｌｅ２５が順に登録され、処理サーバ２００−１にＲｕｌｅ２１、Ｒｕｌｅ２３、Ｒｕｌｅ２５が、処理サーバ２００−２にＲｕｌｅ２２、Ｒｕｌｅ２４が配置されたとする。Ｒｕｌｅ２１、Ｒｕｌｅ２２、Ｒｕｌｅ２３、Ｒｕｌｅ２４、Ｒｕｌｅ２５の構成を以下に示す。
【０１０３】
Ｒｕｌｅ２１（Ｅｖｅｎｔ（９，＊））
Ｒｕｌｅ２２（Ｅｖｅｎｔ（１１，＊））
Ｒｕｌｅ２３（Ｅｖｅｎｔ（１０，＊））
Ｒｕｌｅ２４（Ｅｖｅｎｔ（１２，＊））
Ｒｕｌｅ２５（Ｅｖｅｎｔ（１０，＊）＆Ｅｖｅｎｔ（１１，＊））
【０１０４】
そのとき、処理サーバ２００−１に配置されている全処理ルールのキー属性の値の和集合は、｛９，１０，１１｝となる。また、処理サーバ２００−２に配置されている全処理ルールのキー属性の値の和集合は、｛１１，１２｝となる。従って、属性値が“１１”である属性「ユーザＩＤ」を含むイベントが発生した場合には、処理サーバ２００−１と処理サーバ２００−２にマルチキャストされる。
【０１０５】
そこで、ルール分配の再実行を行う。Ｒｕｌｅ２５のキー属性の属性値数は２であり、その他のルールのキー属性の属性値数は１である。従って、各ルールは、ルール並び替え部１６０により、Ｒｕｌｅ２５、Ｒｕｌｅ２１、Ｒｕｌｅ２２、Ｒｕｌｅ２３、Ｒｕｌｅ２４の順に並び替えられる。その結果、Ｒｕｌｅ２２、Ｒｕｌｅ２３、Ｒｕｌｅ２５は処理サーバ２００−１に、Ｒｕｌｅ２１、Ｒｕｌｅ２４は処理サーバ２００−２に再配置される。それにより、処理サーバ２００−１に配置されている全処理ルールのキー属性の値の和集合は｛１０，１１｝となる。また、処理サーバ２００−２に配置されている全処理ルールのキー属性の値の和集合は｛９，１２｝となる。従って、属性値が“１１”である属性「ユーザＩＤ」を含むイベントのマルチキャストを回避することができる。
【０１０６】
以上に説明したように、本実施形態では、ルール並び替え部が、ルール分配装置に既に登録されている処理ルールをキー属性の属性値数が大きい順に並び替えて、ルールの再配置を実行する。それにより、イベントのマルチキャストを少なくすることができる。従って、本実施形態によれば、ネットワークの負荷をさらに低減することができる。
【０１０７】
実施形態４．
以下、本発明の第４の実施形態を図面を参照して説明する。
【０１０８】
図１０は、ルール分配装置の第４の実施形態の構成を示すブロック図である。
【０１０９】
図１０に示すルール分配装置７００は、第１の実施形態のルール分配装置１００の構成に加えて、属性値担当サーバ解決部１７０と、候補キー属性集合保持部１８０とを備える。
【０１１０】
属性値担当サーバ解決部１７０は、処理ルールのイベント条件のイベントに含まれる属性の属性値をもとに、処理ルールの分配先の処理サーバを決定する処理（以下、属性値担当サーバ解決という。）を実行する。
【０１１１】
属性値担当サーバ解決部１７０は、各属性の属性値と、その属性値を担当する処理サーバ（以下、属性値担当サーバという。）との対応を示す属性値担当サーバ情報を保持する。図１１は、属性値担当サーバ情報の一例を示す説明図である。
【０１１２】
候補キー属性集合保持部１８０は、候補キー属性の一覧を示す情報を保持する。候補キー属性は、キー属性の候補となる属性である。本実施形態では、候補キー属性は、属性値担当サーバ解決の処理対象となる属性である。候補キー属性は、予めユーザによって指定される。なお、候補キー属性集合保持部１８０が、処理サーバとデバイスとの間に設置された基地局等から運用データを取得し、取得した運用データをもとに候補キー属性を決定するようにしてもよい。
【０１１３】
なお、属性値担当サーバ解決部１７０は、ルール分配装置６００が備えるＣＰＵ等によって実現される。例えば、ＣＰＵが、ルール分配プログラムに従って、属性値担当サーバ解決部１７０として動作してもよい。また、候補キー属性集合保持部１８０は、ルール分配装置６００が備えるメモリ等の記憶装置によって実現される。
【０１１４】
ルール分配装置７００のその他の構成は、第１の実施形態のルール分配装置１００と同様であるため説明を省略する。
【０１１５】
ただし、キー属性決定部１４０は、新規処理ルールに含まれる各属性が、候補キー属性に該当するか否かを判定する。キー属性決定部１４０は、新規処理ルールに候補キー属性が含まれる場合には、属性値担当サーバ解決部１７０に候補キー属性を入力するとともに、属性値担当サーバ解決部１７０に属性値担当サーバ解決を依頼する。
【０１１６】
次に、本実施形態の動作を説明する。
【０１１７】
図１２は、第４の実施形態におけるキー属性決定部１４０の動作を示すフローチャートである。
【０１１８】
キー属性決定部１４０は、ルール受信部１１０から新規処理ルールが入力されると（ステップＳ１２０１）、新規処理ルールに含まれる各属性について、ステップＳ１２０３、Ｓ１２０４の処理を行う（ステップＳ１２０２）。ここでは、新規処理ルールとして、以下に示すＲｕｌｅ３１が入力されたとする。
【０１１９】
Ｒｕｌｅ３１（Ｅｖｅｎｔ（ＵｓｅｒＩＤ＝Ｕｓｅｒ１，ＡｒｅａＩＤ＝ＡｒｅａＡ，Ｍｏｄｅ＝Ｗａｌｋｉｎｇ）＆Ｅｖｅｎｔ（ＵｓｅｒＩＤ＝Ｕｓｅｒ２，ＡｒｅａＩＤ＝ＡｒｅａＢ，Ｍｏｄｅ＝Ｗａｌｋｉｎｇ）)
【０１２０】
ステップＳ１２０３において、キー属性決定部１４０は、候補キー属性集合保持部１８０から候補キー属性の一覧を示す情報を取得し、新規処理ルールに含まれる各属性が候補キー属性であるか否かを確認する。ここでは、属性「ＵｓｅｒＩＤ」、「ＡｒｅａＩＤ」が候補キー属性であるとする。
【０１２１】
ステップＳ１２０４において、キー属性決定部１４０は、属性値担当サーバ解決部１７０に、候補キー属性とそれに対応する属性値の集合または範囲を入力し、属性値担当サーバ解決部１７０に属性値担当サーバ解決を依頼する。キー属性決定部１４０は、属性値担当サーバ解決部１７０からサーバＩＤの集合（以下、サーバＩＤ集合という。）を取得する。このとき、属性値担当サーバ解決部１７０は、図１１に示す属性値担当サーバ情報をもとに、サーバＩＤ集合をキー属性決定部１４０に出力する。
【０１２２】
Ｒｕｌｅ３１の属性「ＵｓｅｒＩＤ」の属性値は、“Ｕｓｅｒ１”、“Ｕｓｅｒ２”である。従って、キー属性決定部１４０は、属性値の集合｛Ｕｓｅｒ１，Ｕｓｅｒ２｝を属性値担当サーバ解決部１７０に入力する。そして、キー属性決定部１４０は、属性値担当サーバ解決部１７０からサーバＩＤ集合｛Ｓｅｒｖｅｒ１，Ｓｅｒｖｅｒ２｝を取得する。
【０１２３】
また、属性「ＡｒｅａＩＤ」の属性値は、“ＡｒｅａＡ”、“ＡｒｅａＢ”である。従って、キー属性決定部１４０は、属性値の集合｛ＡｒｅａＡ，ＡｒｅａＢ｝を属性値担当サーバ解決部１７０に入力する。そして、キー属性決定部１４０は、属性値担当サーバ解決部１７０からサーバＩＤ集合｛Ｓｅｒｖｅｒ１｝を取得する。
【０１２４】
なお、属性「Ｍｏｄｅ」については、図１１に示す属性値担当サーバ情報に含まれていないので、キー属性決定部１４０は、サーバＩＤ集合は取得しない。
【０１２５】
全ての属性についてステップＳ１２０３、Ｓ１２０４の処理を実行した後、キー属性決定部１４０は、ステップＳ１２０４で取得したサーバＩＤ集合のうち、サイズが最も小さいサーバＩＤ集合の属性をキー属性とする（ステップＳ１２０５）。属性「ＵｓｅｒＩＤ」のサーバＩＤ集合｛Ｓｅｒｖｅｒ１，Ｓｅｒｖｅｒ２｝のサイズは２である。属性「ＡｒｅａＩＤ」のサーバＩＤ集合｛Ｓｅｒｖｅｒ１｝のサイズは１である。従って、キー属性決定部１４０は、サーバＩＤ集合のサイズが小さい属性「ＡｒｅａＩＤ」を、新規処理ルールのキー属性とする。
【０１２６】
ルール分配先算出部１３０は、キー属性「ＡｒｅａＩＤ」のサーバＩＤ集合｛Ｓｅｒｖｅｒ１｝から“Ｓｅｒｖｅｒ１”を選択し、そのサーバに処理ルールを配置する（ステップＳ１２０６）。
【０１２７】
ステップＳ１２０５において、例えば、属性「ＡｒｅａＩＤ」のサーバＩＤ集合のサイズが２であった場合には、キー属性を決定することができない。その場合には、まず、ルール分配先算出部１３０は、属性ごとに、サーバＩＤ集合に含まれる処理サーバの中から分配先を算出する。具体的には、ルール分配先算出部１３０は、属性ごとに、サーバＩＤ集合に含まれる各処理サーバについて、Ｒｕｌｅ３１の配置前と配置後における当該処理サーバに登録された全処理ルールについて当該属性の属性値の和集合を算出する。そして、ルール分配先算出部１３０は、算出した和集合の要素の増加数が最も小さい処理サーバを当該属性の分配先として算出する。次に、キー属性決定部１４０は、各属性の中から、分配先における和集合の要素の増加数が最も小さい属性をキー属性に決定する。
【０１２８】
また、ステップＳ１２０６において、キー属性に対するサーバＩＤが複数ある場合には、ルール分配先算出部１３０は、各サーバＩＤに対応する処理サーバの中から分配先を選択する。例えば、各処理サーバに新規処理ルールを配置した場合に、配置後のイベントのマルチキャストが少なくて済む処理サーバを分配先として選択する。なお、第１の実施形態のステップＳ４０５の処理により、処理ルールの分配先を算出してもよい。
【０１２９】
ルール分配装置７００における以降の処理は、第１の実施形態のステップＳ４０７〜Ｓ４０８の処理と同様であるため、説明を省略する。
【０１３０】
以上に説明したように、本実施形態では、各候補キー属性に対応するサーバＩＤ集合を取得し、取得したサーバＩＤ集合のうち、サイズが最も小さいサーバＩＤ集合の属性をキー属性とする。従って、例えば、処理サーバおよびディスパッチャが地域ごとに分散して配置されている場合に、サイズが最も小さいサーバＩＤ集合の属性をキー属性とすることにより、他地域の処理サーバへのイベントの転送を最小限に抑えることができる。よって、ディスパッチャやネットワークの負荷を低減させることができる。
【０１３１】
なお、本実施形態と他の実施形態とを組み合わせるようにしてもよい。例えば、ステップＳ１２０５において、属性「ＵｓｅｒＩＤ」のサーバＩＤ集合のサイズと、属性「ＡｒｅａＩＤ」のサーバＩＤ集合のサイズとが同じであった場合には、キー属性を決定することができない。その場合、処理ルールの分配先を算出することができないので、サーバ割り当て部１２０を用いて第１の実施形態のステップＳ４０１〜Ｓ４０５の処理を実行して、処理ルールの分配先を決定するようにしてもよい。
【０１３２】
また、他の実施形態におけるルール分配装置が候補キー属性集合保持部１８０を備えていてもよい。その場合には、例えば、第１の実施形態におけるルール分配装置１００は、候補キー属性集合保持部１８０から取得した候補キー属性の中からキー属性を決定する。そのような構成によれば、ルール分配装置１００おけるキー属性決定部１４０は、アプリケーションから処理ルールが登録されたときに、処理ルールのイベント条件のイベントに含まれる属性のうち、候補キー属性に該当する属性に対してキー属性の算出処理を行うだけでよい。従って、ルール分配装置１００の処理負荷をより低減することができる。
【０１３３】
実施形態５．
以下、本発明の第５の実施形態を図面を参照して説明する。
【０１３４】
図１３は、ルール分配装置の第５の実施形態の構成を示すブロック図である。
【０１３５】
図１３に示すルール分配装置８００は、第４の実施形態のルール分配装置７００の構成に加えて、ルール分割部１９０を備える。
【０１３６】
ルール分割部１９０は、ルール受信部１１０が受信した処理ルールを分割する。
【０１３７】
以下に示すＲｕｌｅ４１は、イベントａ、ｂを送信するある二人が１００ｍ以内にいる場合にマッチングが成立するルールである。この場合、候補キー属性を「ユーザＩＤ」、「エリアＩＤ」としても、各候補キー属性に対する値を限定することができない。従って、Ｒｕｌｅ４１が配置された処理サーバに対して、あらゆるユーザＩＤ、エリアＩＤのイベントが送信される可能性がある。そこで、ルール分割部１９０は、候補キー属性にもとづいて処理ルールを分割する。
【０１３８】
Ｒｕｌｅ４１（Ｅｖｅｎｔ（）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，  ｂ．Ｃｏｏｒｄ）＜１００ｍ  ）
【０１３９】
サーバ割り当て部１２０、ルール分配先算出部１３０、キー属性決定部１４０、振り分けルール生成部１５０、属性値担当サーバ解決部１７０および候補キー属性集合保持部１８０は、ルール分割部１９０が分割した処理ルールに対して、通常の処理ルールに対する処理と同様の処理を行う。
【０１４０】
なお、ルール分割部１９０は、ルール分配装置８００が備えるＣＰＵ等によって実現される。例えば、ＣＰＵが、ルール分配プログラムに従って、ルール分割部１９０として動作してもよい。
【０１４１】
次に、本実施形態の動作を説明する。
【０１４２】
まず、どの候補キー属性でルール分割するかが予め指定されている場合の動作を説明する。
【０１４３】
図１４は、エリアＩＤにもとづくルール分割処理を示すフローチャートである。
【０１４４】
ここで、ルール受信部１１０が受信した処理ルール（Ｒｕｌｅ４２）を分割する場合を例にする。Ｒｕｌｅ４２の構成を以下に示す。
【０１４５】
Ｒｕｌｅ４２（Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ１）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ２）  ａｓ  ｂ  ｗｈｅｒｅ  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ）
【０１４６】
Ｒｕｌｅ４２は、ユーザＩＤが“ｕｓｅｒ１”であるイベントａを送信するユーザと、ユーザＩＤが“ｕｓｅｒ２”であるイベントｂを送信するユーザとが、１００ｍ（メートル）以内にいる場合にマッチングが成立するルールである。
【０１４７】
ルール分割部１９０は、２つのイベントａ、ｂの関係を示す条件を算出する。ここでは、イベントａ、ｂの距離Ｄ（ａ、ｂ）を示す条件を算出する（ステップＳ１４０１）。ここで、距離条件として「Ｄ（ａ、ｂ）＝＜１００ｍ」が算出される。
【０１４８】
ルール分割部１９０は、ユーザＩＤが“ｕｓｅｒ１”であるイベントａを送信するユーザと、ユーザＩＤが“ｕｓｅｒ２”であるイベントｂを送信するユーザがいるエリアを、複数のメッシュに分割する。図１５は、複数のメッシュに分割されたエリアの一例を示す説明図である。ルール分割部１９０は、例えば、図１５に示すように１辺が３００ｍである複数の正方形に分割する。ここでは、エリアを９つのメッシュに分割する。図１５に示す各正方形の中の数字はメッシュのＮｏを表す。なお、メッシュは正方形に限定されず、エリアをその他の形で分割してもよい。
【０１４９】
次に、ルール分割部１９０は、２つのイベントａ、ｂが距離条件「Ｄ（ａ、ｂ）＝＜１００ｍ」を満たす２つのメッシュを算出する（ステップＳ１４０２）。図１６は、距離条件を満たすメッシュの組み合わせの一覧を示す説明図である。ここでは、４９組のメッシュの組み合わせが算出される。
【０１５０】
ルール分割部１９０は、図１６に示す一覧をもとにＲｕｌｅ４２をエリアＩＤで分割して、新たな処理ルール（Ｒｕｌｅ４２−１〜Ｒｕｌｅ４２−４９）を生成する（ステップＳ１４０３）。具体的には、ルール分割部１９０は、メッシュに対応する属性値（ｍｅｓｈ１〜ｍｅｓｈ９）を生成し、生成した各属性値をもとにイベント条件を生成する。ここでは、イベントａ、ｂを送信するユーザがどのメッシュにいるかを示すイベント条件を生成する。イベント条件は、距離条件を満たすメッシュの組み合わせごとに生成される。ルール分割部１９０は、生成したイベント条件をそれぞれＲｕｌｅ４２に付加して、新たな処理ルールＲｕｌｅ４２−１〜Ｒｕｌｅ４２−４９を生成する。
【０１５１】
Ｒｕｌｅ４２−１（Ｅｖｅｎｔ（）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  Ｉｎ（ａ．Ｃｏｏｒｄ，  ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ）
Ｒｕｌｅ４２−２（Ｅｖｅｎｔ（）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  Ｉｎ（ａ．Ｃｏｏｒｄ，  ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ２）  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ）
Ｒｕｌｅ４２−３（Ｅｖｅｎｔ（）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  Ｉｎ（ａ．Ｃｏｏｒｄ，  ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ４）  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ）
・・・
Ｒｕｌｅ４２−４９（Ｅｖｅｎｔ（）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  Ｉｎ（ａ．Ｃｏｏｒｄ，  ｍｅｓｈ９）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ９）  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ）
【０１５２】
ここで、「Ｉｎ（ａ．Ｃｏｏｒｄ，  ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ１）」は、イベントａを送信するユーザ（ｕｓｅｒ１）がｍｅｓｈ１にいて、且つイベントｂを送信するユーザ（ｕｓｅｒ２）がｍｅｓｈ２にいるか否かを判定するためのイベント条件である。
【０１５３】
このように、ユーザ同士の相対的な位置しか認識できない場合であっても、ユーザがいるエリアを複数のメッシュに分割することにより、ユーザの絶対的な位置で距離条件を表現することができる。絶対的な距離条件を処理ルールに付加することにより、属性「エリアＩＤ」に対する値を限定することができる。
【０１５４】
図１４に示す処理は、イベント数が２つである場合を前提としたが、イベント数が２つ以上である場合も、同様にルール分割をすることができる。
【０１５５】
図１７は、イベント数が３つである処理ルールに対するエリアＩＤにもとづくルール分割処理を示すフローチャートである。
【０１５６】
ここで、ルール受信部１１０が受信した処理ルール（Ｒｕｌｅ４３）を分割する場合を例にする。Ｒｕｌｅ４３の構成を以下に示す。
【０１５７】
Ｒｕｌｅ４３（Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ１）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ２）  ａｓ  ｂ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ３）  ａｓ  ｃ  ｗｈｅｒｅ  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ  ＆＆  Ｄｉｓｔａｎｃｅ（ｂ．Ｃｏｏｒｄ，ｃ．Ｃｏｏｒｄ）＜１５０ｍ）
【０１５８】
Ｒｕｌｅ４３は、ユーザＩＤが“ｕｓｅｒ１”であるイベントａを送信するユーザと、ユーザＩＤが“ｕｓｅｒ２”であるイベントｂを送信するユーザとが１００ｍ以内にいて、かつ、ユーザＩＤが“ｕｓｅｒ２”であるイベントｂを送信するユーザと、ユーザＩＤが“ｕｓｅｒ３”であるイベントｃを送信するユーザとが１５０ｍ（メートル）以内にいる場合にマッチングが成立するルールである。
【０１５９】
ルール分割部１９０は、３つのイベントａ、ｂ、ｃの距離条件を算出する（ステップＳ１７０１、Ｓ１７０２）。ルール分割部１９０は、イベントａ、ｂ、ｃの中から選択した２つのイベントの組み合わせに対して、距離条件を算出する。従って、ここでは、距離条件として「Ｄ（ａ、ｂ）＝＜１００ｍ」、「Ｄ（ｂ、ｃ）＝＜１５０ｍ」、「Ｄ（ａ、ｃ）＝＜２５０ｍ」が算出される。
【０１６０】
ルール分割部１９０は、イベント数が２つの場合と同様に、各ユーザがいるエリアを９つのメッシュに分割する。
【０１６１】
ルール分割部１９０は、距離Ｄ（ａ、ｂ）、Ｄ（ｂ、ｃ）、Ｄ（ａ、ｃ）ごとに、イベント数が２つの場合と同様に、距離条件を満たすメッシュの組み合わせの一覧を生成する（ステップＳ１７０３）。
【０１６２】
ステップＳ１７０３の後、ルール分割部１９０は、各距離条件に対応するメッシュの組み合わせを結合する（ステップＳ１７０４）。図１８は、各距離条件に対応するメッシュの組み合わせの一覧を結合した結果を示す説明図である。
【０１６３】
ルール分割部１９０は、図１８に示す結果をもとにＲｕｌｅ４３をエリアＩＤで分割して、新たな処理ルール（Ｒｕｌｅ４３−１〜）を生成する（ステップＳ１７０５）。
【０１６４】
Ｒｕｌｅ４３−１（Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ１）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ２）  ａｓ  ｂ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ３）  ａｓ  ｃ  ｗｈｅｒｅ  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｃ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ  ＆  Ｄｉｓｔａｎｃｅ（ｂ．Ｃｏｏｒｄ，ｃ．Ｃｏｏｒｄ）＜１５０ｍ）
Ｒｕｌｅ４３−２（Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ１）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ２）  ａｓ  ｂ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ３）  ａｓ  ｃ  ｗｈｅｒｅ  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｃ．Ｃｏｏｒｄ，ｍｅｓｈ２）  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ  ＆  Ｄｉｓｔａｎｃｅ（ｂ．Ｃｏｏｒｄ，ｃ．Ｃｏｏｒｄ）＜１５０ｍ）
Ｒｕｌｅ４３−３（Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ１）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ２）  ａｓ  ｂ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ３）  ａｓ  ｃ  ｗｈｅｒｅ  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｃ．Ｃｏｏｒｄ，ｍｅｓｈ４）  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ  ＆  Ｄｉｓｔａｎｃｅ（ｂ．Ｃｏｏｒｄ，ｃ．Ｃｏｏｒｄ）＜１５０ｍ）
Ｒｕｌｅ４３−４（Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ１）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ２）  ａｓ  ｂ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ３）  ａｓ  ｃ  ｗｈｅｒｅ  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｃ．Ｃｏｏｒｄ，ｍｅｓｈ５）  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ  ＆  Ｄｉｓｔａｎｃｅ（ｂ．Ｃｏｏｒｄ，ｃ．Ｃｏｏｒｄ）＜１５０ｍ）
Ｒｕｌｅ４３−５（Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ１）  ａｓ  ａ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ２）  ａｓ  ｂ  ＆  Ｅｖｅｎｔ（ＩＤ＝ｕｓｅｒ３）  ａｓ  ｃ  ｗｈｅｒｅ  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ２）  ＆  Ｉｎ（ｃ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ  ＆  Ｄｉｓｔａｎｃｅ（ｂ．Ｃｏｏｒｄ，ｃ．Ｃｏｏｒｄ）＜１５０ｍ）
・・・
【０１６５】
図１４および図１７に示す処理は、各ユーザがいるエリアを分割することにより、処理ルールを分割したが、他の属性にもとづいてルール分割を行ってもよい。また、イベント間の関係を示す条件として距離条件を用いているが、その他の関係を示す条件を用いてもよい。
【０１６６】
ここでは、ルール受信部１１０が受信した処理ルール（Ｒｕｌｅ４４）を、属性「ユーザＩＤ」にもとづいて分割する場合を例にする。Ｒｕｌｅ４４の構成を以下に示す。
【０１６７】
Ｒｕｌｅ４４（Ｅｖｅｎｔ（）  ａｓ  ａ，  Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  ａ．ＩＤ＝ｂ．ＩＤ  ＆  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ２）  ＆  ａ．ｔｉｍｅ＜ｂ．ｔｉｍｅ
【０１６８】
Ｒｕｌｅ４４は、あるユーザが“ｍｅｓｈ１”にいて、その後当該ユーザが“ｍｅｓｈ２”にいる場合にマッチングが成立するルールである。
【０１６９】
ここで、イベントａ、ｂを送信するユーザとして、“ｕｓｅｒ１”、“ｕｓｅｒ２”、“ｕｓｅｒ３”、“ｕｓｅｒ４”、“ｕｓｅｒ５”の５人がいるとする。
【０１７０】
ルール分割部１９０は、Ｒｕｌｅ４４で指定されるイベント群、つまり、イベントａ、ｂについて、イベントを送信するユーザの組み合わせを算出する。なお、この場合、結合する対象がないため、ステップＳ１７０４に示す処理は実行されない。図１９は、イベントａ、ｂに対応するユーザの組み合わせの一覧を示す説明図である。
【０１７１】
ルール分割部１９０は、図１９に示す一覧をもとにＲｕｌｅ４４をユーザＩＤで分割して、新たな処理ルール（Ｒｕｌｅ４４−１〜Ｒｕｌｅ４４−５）を生成する。具体的には、ルール分割部１９０は、イベントａ、ｂを送信する５人のユーザに対応する属性値（ｕｓｅｒ１〜ｕｓｅｒ５）を生成し、生成した各属性値をもとにイベント条件を生成する。ルール分割部１９０は、生成したイベント条件をそれぞれＲｕｌｅ４４に付加して、新たな処理ルールＲｕｌｅ４４−１〜Ｒｕｌｅ４４−５を生成する。
【０１７２】
Ｒｕｌｅ４４−１（Ｅｖｅｎｔ（）  ａｓ  ａ，Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  ａ．ＩＤ＝ｂ．ＩＤ  ＆  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ２）  ＆  ａ．ｔｉｍｅ＜ｂ．ｔｉｍｅ  ＆  ａ．ＩＤ＝ｕｓｅｒ１  ＆  ｂ．ＩＤ＝ｕｓｅｒ１
Ｒｕｌｅ４４−２（Ｅｖｅｎｔ（）  ａｓ  ａ，Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  ａ．ＩＤ＝ｂ．ＩＤ  ＆  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ２）  ＆  ａ．ｔｉｍｅ＜ｂ．ｔｉｍｅ  ＆  ａ．ＩＤ＝ｕｓｅｒ２  ＆  ｂ．ＩＤ＝ｕｓｅｒ２
Ｒｕｌｅ４４−３（Ｅｖｅｎｔ（）  ａｓ  ａ，Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  ａ．ＩＤ＝ｂ．ＩＤ  ＆  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ２）  ＆  ａ．ｔｉｍｅ＜ｂ．ｔｉｍｅ  ＆  ａ．ＩＤ＝ｕｓｅｒ３  ＆  ｂ．ＩＤ＝ｕｓｅｒ３
Ｒｕｌｅ４４−４（Ｅｖｅｎｔ（）  ａｓ  ａ，Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  ａ．ＩＤ＝ｂ．ＩＤ  ＆  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ２）  ＆  ａ．ｔｉｍｅ＜ｂ．ｔｉｍｅ  ＆  ａ．ＩＤ＝ｕｓｅｒ４  ＆  ｂ．ＩＤ＝ｕｓｅｒ４
Ｒｕｌｅ４４−５（Ｅｖｅｎｔ（）  ａｓ  ａ，Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  ａ．ＩＤ＝ｂ．ＩＤ  ＆  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ２）  ＆  ａ．ｔｉｍｅ＜ｂ．ｔｉｍｅ  ＆  ａ．ＩＤ＝ｕｓｅｒ５  ＆  ｂ．ＩＤ＝ｕｓｅｒ５
【０１７３】
なお、この場合、Ｒｕｌｅ４４−１〜Ｒｕｌｅ４４−５中のｗｈｅｒｅ句「ｗｈｅｒｅ  ａ．ＩＤ＝ｂ．ＩＤ」は不要であるため、削除してもよい。
【０１７４】
次に、ルール分割部１９０がどの候補キー属性でルール分割するかを決定する場合の動作を説明する。
【０１７５】
ルール分割部１９０は、ルール受信部１１０が受信した処理ルールを分割する前に、候補キー属性集合からどの候補キー属性を分割対象キー属性とするかを決定する。ルール分割部１９０は、分割対象キー属性にもとづいてルール分割を実行する。
【０１７６】
図２０は、候補キー属性に対する値の数をもとに分割対象キー属性を決定する処理を示すフローチャートである。
【０１７７】
ルール分割部１９０は、候補キー属性集合から候補キー属性を一つ選択する。ルール分割部１９０は、その候補キー属性を基に処理ルールを分割した場合に、分割後の処理ルールについてその候補キー属性に対する値の数を算出する（ステップＳ２００１）。
【０１７８】
ルール分割部１９０は、ステップＳ２００１を候補キー属性集合のすべての候補キー属性に対して実行する。
【０１７９】
ルール分割部１９０は、候補キー属性集合の中から、ステップＳ２００１で算出した値の数が最も少ない候補キー属性を分割対象キー属性に決定する（ステップＳ２００２）。
【０１８０】
ここで、ルール受信部１１０に処理ルール（Ｒｕｌｅ４５）が入力されたときの、ステップＳ２００１〜Ｓ２００２の処理を説明する。なお、候補キー属性集合には、「ユーザＩＤ」、「エリアＩＤ」の２つの候補キー属性が含まれているとする。Ｒｕｌｅ４５の構成を以下に示す。
【０１８１】
Ｒｕｌｅ４５（Ｅｖｅｎｔ（）  ａｓ  ａ，  Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  ａ．ＩＤ＝ｂ．ＩＤ  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ  ＆  ｂ．ｔｉｍｅ−ａ．ｔｉｍｅ＜１０ｍｉｎ
【０１８２】
Ｒｕｌｅ４５は、あるユーザが１０分の間に１００ｍ進んでいない場合にマッチングが成立するルールである。
【０１８３】
Ｒｕｌｅ４５−１は、Ｒｕｌｅ４５をユーザＩＤで分割した場合の一例ある。
【０１８４】
Ｒｕｌｅ４５−１（Ｅｖｅｎｔ（）  ａｓ  ａ，  Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  ａ．ＩＤ≠ｂ．ＩＤ  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ  ＆  ａ．ＩＤ＝ｕｓｅｒ１  ＆  ｂ．ＩＤ＝ｕｓｅｒ１
【０１８５】
Ｒｕｌｅ４５−１における属性「ユーザＩＤ」に対する値は、“ｕｓｅｒ１”のみである。従って、候補キー属性「ユーザＩＤ」を基に処理ルールを分割した場合、その候補キー属性に対する値の数は１となる。
【０１８６】
Ｒｕｌｅ４５−２は、Ｒｕｌｅ４５をエリアＩＤで分割した場合の一例ある。
【０１８７】
Ｒｕｌｅ４５−２（Ｅｖｅｎｔ（）  ａｓ  ａ，  Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  ａ．ＩＤ≠ｂ．ＩＤ  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ  ＆  Ｉｎ（ａ．Ｃｏｏｒｄ，ｍｅｓｈ１）  ＆  Ｉｎ（ｂ．Ｃｏｏｒｄ，ｍｅｓｈ２）
【０１８８】
Ｒｕｌｅ４５−２における属性「エリアＩＤ」に対する値は、“ｍｅｓｈ１”、“ｍｅｓｈ２”である。従って、候補キー属性「エリアＩＤ」を基に処理ルールを分割した場合、その候補キー属性に対する値の数は２となる。
【０１８９】
従って、この場合、ルール分割部１９０は、値の数が少ない候補キー属性「ユーザＩＤ」を分割対象キー属性に決定する。
【０１９０】
図２１は、ルール数をもとに分割対象キー属性を決定する処理を示すフローチャートである。
【０１９１】
ルール分割部１９０は、候補キー属性集合から候補キー属性を一つ選択し、その候補キー属性を基に処理ルールを分割した場合に、分割後のルール数を算出する（ステップＳ２１０１）。
【０１９２】
ルール分割部１９０は、ステップＳ２１０１を候補キー属性集合のすべての候補キー属性に対して実行する。
【０１９３】
ルール分割部１９０は、候補キー属性集合の中から、ステップＳ２１０１で算出したルール数が最も少ない候補キー属性を分割対象キー属性に決定する（ステップＳ２１０２）。
【０１９４】
ここで、ルール受信部１１０に処理ルール（Ｒｕｌｅ４６）が入力されたときの、ステップＳ２１０１〜Ｓ２１０２の処理を説明する。なお、候補キー属性集合には、「ユーザＩＤ」、「エリアＩＤ」の２つの候補キー属性が含まれているとする。Ｒｕｌｅ４６の構成を以下に示す。
【０１９５】
Ｒｕｌｅ４６（Ｅｖｅｎｔ（）  ａｓ  ａ，Ｅｖｅｎｔ（）  ａｓ  ｂ  ｗｈｅｒｅ  ａ．ＩＤ≠ｂ．ＩＤ  ＆  Ｄｉｓｔａｎｃｅ（ａ．Ｃｏｏｒｄ，ｂ．Ｃｏｏｒｄ）＜１００ｍ
【０１９６】
Ｒｕｌｅ４６は、イベントａを送信するユーザと、イベントｂを送信する他のユーザとが１００ｍ以内にいる場合にマッチングが成立するルールである。
【０１９７】
ここで、ユーザが５人いるとする。すると、イベントａを送信するユーザとイベントｂを送信する他のユーザとの組み合わせは、５Ｃ２（＝１０）通りである。また、ユーザがいるエリアが、図１５に示すように９つのメッシュに分割されているとする。すると、上述のとおり、距離条件を満たすメッシュの組み合わせは４９通りになる。
【０１９８】
従って、この場合、ルール分割部１９０は、分割後のルール数が少なくなる候補キー属性「ユーザＩＤ」を分割対象キー属性に決定する。
【０１９９】
以上に説明したように、本実施形態では、候補キー属性のいずれかをキー属性としても、各候補キー属性に対する値を限定することができない処理ルールに対して、ルール分割部が、いずれかの候補キー属性をもとに当該処理ルールを分割する。これにより、当該候補キー属性に対する値が少数になるような処理ルールが生成される。そして、ルール分配装置は、ルール分割部が分割した処理ルールを複数のサーバに分配する。これにより、ルール分配装置は、各候補キー属性に対する値を限定することができない処理ルールであっても、デバイスから発生するイベントが複数のサーバに分散されるように、ルール分配することができる。
【０２００】
また、分割後に値の数がより少なくなる候補キー属性、または、分割後にルール数がより少なくなる候補キー属性を分割対象属性として選択することにより、分割後のルール数を必要以上に増加させることがない。従って、ディスパッチャおよび処理サーバの負荷を必要以上に増大させることがない。
【０２０１】
従って、本実施形態を第４の実施形態と組み合わせることにより、第４の実施形態におけるルール分配をより効率的に実行することが可能となる。なお、本実施形態では、第４の実施形態のルール分配装置７００の構成に加えて、ルール分割部１９０を備えるルール分配装置８００を例にしたが、ルール分配装置８００は、他の実施形態のルール分配装置の構成を備えていてもよい。つまり、本実施形態を他の実施形態と組み合わせてもよい。
【０２０２】
図２２は、本発明によるルール分配装置の最小構成を示すブロック図である。図２３は、本発明によるルール分配装置の他の最小構成を示すブロック図である。図２４は、本発明によるルール分配装置の他の最小構成を示すブロック図である。図２５は、本発明によるイベント処理システムの最小構成を示すブロック図である。
【０２０３】
図２２に示すように、ルール分配装置（図１または図２に示すルール分配装置１００に相当。）は、アプリケーションが要求するイベント処理とイベント処理を実行するためのイベント条件とを規定した処理ルールを入力するルール受信部１１（図２に示すルール分配装置１００におけるルール受信部１１０に相当。）と、処理ルールのイベント条件に含まれる属性の中からキー属性を決定するキー属性決定部１４（図２に示すルール分配装置１００におけるキー属性決定部１４０に相当。）と、当該キー属性に対応付けられた処理装置の中から選択した処理装置に処理ルールを配置するルール分配先算出部１３（図２に示すルール分配装置１００におけるルール分配先算出部１３０に相当。）と、デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、デバイスと処理装置との間に設置されたイベント振り分け装置に当該イベント振り分けルールを配置する振り分けルール生成部１５（図２に示すルール分配装置１００における振り分けルール生成部１５０に相当。）とを備える。
【０２０４】
そのような構成によれば、イベントのマルチキャストの発生を低減することができる。従って、ディスパッチャおよび処理サーバの処理負荷を低減することができるとともに、ネットワークの負荷を低減することができる。
【０２０５】
上記の実施形態には、以下のようなルール分配装置も開示されている。
【０２０６】
（１）キー属性決定部１４は、処理ルールのイベント条件に含まれるイベントについて、イベントに含まれる各属性の属性値の和集合を算出し、和集合のサイズが小さい属性を当該処理ルールのキー属性とするルール分配装置。
【０２０７】
そのような構成によれば、イベントのマルチキャストの発生をより低減することができる。
【０２０８】
（２）ルール分配先算出部１３は、処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性をキー属性としたときの当該処理ルールの分配先を算出し、当該処理ルールの配置前と配置後の分配先の全処理ルールについて当該属性の属性値の和集合を算出し、キー属性決定部１４は、算出結果をもとに、属性値の和集合の要素の増加数が最も小さい属性を特定し、特定した属性を当該処理ルールのキー属性とするルール分配装置。
【０２０９】
そのような構成によれば、処理サーバ群ごとに決定した分配先候補の処理サーバのうち、イベントのマルチキャストが少なくて済む処理サーバを分配先として選択することができる。従って、イベントのマルチキャストをより少なくすることができる。
【０２１０】
（３）図２３に示すように、入力した処理ルールを保持し、保持する処理ルールの並び替えを実行するルール並び替え部１６（図８に示すルール分配装置６００におけるルール並び替え部１６０に相当。）を備え、ルール並び替え部１６は、保持する処理ルールごとに、キー属性の属性値の和集合を求め、和集合のサイズが大きい順に処理ルールを並び替え、ルール分配先算出部１３は、ルール並び替え部１６が並び替えた順番にもとづいて、処理ルールを各処理装置に配置するルール分配装置。
【０２１１】
そのような構成によれば、各処理装置に配置されている処理ルールを、イベントのマルチキャストが少なくなるように再配置することができる。
【０２１２】
（４）図２４に示すように、属性値と当該属性値を含むイベントを処理する処理装置とを対応付けた属性値担当サーバ情報を保持する属性値担当サーバ解決部１７（図１０に示すルール分配装置７００における属性値担当サーバ解決部１７０に相当。）を備え、キー属性決定部１４は、ルール受信部１１が入力した処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性に指定されている属性値に対応づけられた処理装置の一覧を示すサーバＩＤ集合を属性値担当サーバ解決部１７から取得し、取得したサーバＩＤ集合をもとにキー属性を決定するルール分配装置。
【０２１３】
そのような構成によれば、例えば、処理サーバおよびディスパッチャが地域ごとに分散して配置されている場合に、他地域の処理サーバへのイベントの転送を最小限に抑えることができる。よって、ディスパッチャやネットワークの負荷を低減させることができる。
【０２１４】
（５）ルール分配先算出部１３は、サーバＩＤ集合をもとに、ルール受信部１１が入力した処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性に指定されている属性値に対応づけられた各処理装置について、処理ルールの配置前と配置後の当該処理装置の全処理ルールについて当該属性の属性値の和集合を算出し、算出した和集合の要素の増加数が最も小さい処理装置を当該属性の分配先として選択し、キー属性決定部１４は、各属性の中から、分配先における和集合の要素の増加数が最も小さい属性をキー属性に決定するルール分配装置。
【０２１５】
そのような構成によれば、新規処理ルールのイベント条件に含まれるイベントの各属性のサーバＩＤ集合のサイズが２以上である場合でも、キー属性を決定することができる。従って、例えば、多数の処理サーバおよびディスパッチャが地域ごとに分散して配置されている場合であっても、他地域の処理サーバへのイベントの転送を最小限に抑えることができる。
【０２１６】
（６）ルール受信部１１が受信した処理ルールのイベント条件に含まれるイベントの各属性の属性値が限定できない場合、いずれかの属性を分割対象属性とし、分割対象属性を限定するための属性値を生成し、生成した属性値をもとに複数のイベント条件を生成し、複数のイベント条件の各々を処理ルールに付加して新たな複数の処理ルールに分割するルール分割部１９（図１３に示すルール分配装置８００におけるルール分割部１９０に相当。）を備えるルール分配装置。
【０２１７】
そのような構成によれば、各候補キー属性に対する値を限定することができない処理ルールであっても、デバイスから発生するイベントが複数のサーバに分散されるように、ルール分配することができる。
【０２１８】
（７）ルール分割部１９は、処理ルールのイベント条件に含まれるイベントの各属性を分割対象属性とした場合に、当該属性に対する属性値の数が分割後に最も小さくなる属性、または、分割後に新たに生成される処理ルールの数が最も小さくなる属性を分割対象属性として選択するルール分配装置。
【０２１９】
そのような構成によれば、分割後に値の数がより少なくなる候補キー属性、または、分割後にルール数がより少なくなる候補キー属性を分割対象属性として選択することができる。従って、ルール数を必要以上に増加させることがないので、ディスパッチャおよび処理サーバの負荷を必要以上に増大させることがない。
【０２２０】
（８）キー属性決定部１４は、ルール受信部１１が入力した処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性が候補キー属性であるか否かを判定し、候補キー属性であると判断した属性の中からキー属性を決定するルール分配装置。
【０２２１】
そのような構成によれば、ルール分配装置におけるキー属性決定部は、アプリケーションから処理ルールが登録されたときに、処理ルールのイベント条件のイベントに含まれる属性のうち、候補キー属性に該当する属性に対してキー属性の算出処理を行えばよい。よって、ルール分配装置の処理負荷をより低減することができる。
【０２２２】
上記の実施形態には、図２５に示すようなイベント処理システムも開示されている。
【０２２３】
（９）処理ルールに従ってイベント処理を実行する処理装置２０−１〜２０−ｎ（図１に示す処理サーバ２００−１〜２００−ｎに相当。）と、処理装置２０−１〜２０−ｎに処理ルールを配置するルール分配装置１０（図１に示すルール分配装置１００に相当。）と、デバイスが発したイベントを処理装置２０−１〜２０−ｎに振り分けるイベント振り分け装置３０−１〜３０−ｎ（図１に示すディスパッチャ３００−１〜３００−ｎに相当。）とを備え、ルール分配装置１０は、アプリケーションが要求するイベント処理とイベント処理を実行するためのイベント条件とを規定した処理ルールを入力するルール受信部１１と、処理ルールのイベント条件に含まれる属性の中からキー属性を決定するキー属性決定部１４と、当該キー属性に対応付けられた処理装置の中から選択した処理装置に処理ルールを配置するルール分配先算出部１３と、デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、イベント振り分け装置３０−１〜３０−ｎに配置する振り分けルール生成部１５とを備えたことを特徴とするイベント処理システム。
【０２２４】
そのような構成によれば、イベントのマルチキャストの発生を低減することができる。従って、ディスパッチャおよび処理サーバの処理負荷を低減することができるとともに、ネットワークの負荷を低減することができる。従って、システム全体の処理負荷を低減することができる。
【０２２５】
また、上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下
に限られない。
【０２２６】
（付記１）処理ルールに従ってイベント処理を実行する処理装置２０−１〜２０−ｎと、処理装置２０−１〜２０−ｎに処理ルールを配置するルール分配装置１０と、デバイスが発したイベントを処理装置２０−１〜２０−ｎに振り分けるイベント振り分け装置３０−１〜３０−ｎとを備え、ルール分配装置１０は、アプリケーションが要求するイベント処理とイベント処理を実行するためのイベント条件とを規定した処理ルールを入力するルール受信部１１と、処理ルールのイベント条件に含まれる属性の中からキー属性を決定するキー属性決定部１４と、当該キー属性に対応付けられた処理装置の中から選択した処理装置に処理ルールを配置するルール分配先算出部１３と、デバイスが発したイベントを処理対象とする処理ルールが配置された処理装置に当該イベントを振り分けるためのイベント振り分けルールを生成し、イベント振り分け装置３０−１〜３０−ｎに配置する振り分けルール生成部１５とを備えたことを特徴とするイベント処理システム。
【０２２７】
（付記２）キー属性決定部１４は、処理ルールのイベント条件に含まれるイベントについて、イベントに含まれる各属性の属性値の和集合を算出し、和集合のサイズが最も小さい属性を当該処理ルールのキー属性とする付記１に記載のイベント処理システム。
【０２２８】
そのような構成によれば、イベントのマルチキャストの発生をより低減することができる。
【０２２９】
（付記３）ルール分配先算出部１３は、処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性をキー属性としたときの当該処理ルールの分配先を算出し、当該処理ルールの配置前と配置後の分配先の全処理ルールについて当該属性の属性値の和集合を算出し、キー属性決定部１４は、算出結果をもとに、属性値の和集合の要素の増加数が最も小さい属性を特定し、特定した属性を当該処理ルールのキー属性とする付記１または付記２に記載のイベント処理システム。
【０２３０】
そのような構成によれば、処理サーバ群ごとに決定した分配先候補の処理サーバのうち、イベントのマルチキャストが少なくて済む処理サーバを分配先として選択することができる。従って、イベントのマルチキャストをより少なくすることができる。
【０２３１】
（付記４）ルール分配装置１０が、入力した処理ルールを保持し、保持する処理ルールの並び替えを実行するルール並び替え部１６を備え、ルール並び替え部１６は、保持する処理ルールごとに、キー属性の属性値の和集合を求め、和集合のサイズが大きい順に処理ルールを並び替え、ルール分配先算出部１３は、ルール並び替え部１６が並び替えた順番にもとづいて、処理ルールを各処理装置に配置する付記１から付記３のうちのいずれか１つに記載のイベント処理システム。
【０２３２】
そのような構成によれば、各処理装置に配置されている処理ルールを、イベントのマルチキャストが少なくなるように再配置することができる。
【０２３３】
（付記５）ルール分配装置１０が、属性値と当該属性値を含むイベントを処理する処理装置とを対応付けた属性値担当サーバ情報を保持する属性値担当サーバ解決部１７を備え、キー属性決定部１４は、ルール受信部１１が入力した処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性に指定されている属性値に対応づけられた処理装置の一覧を示すサーバＩＤ集合を属性値担当サーバ解決部１７から取得し、取得したサーバＩＤ集合をもとにキー属性を決定する付記１から付記４のうちのいずれか１つに記載のイベント処理システム。
【０２３４】
そのような構成によれば、例えば、処理サーバおよびディスパッチャが地域ごとに分散して配置されている場合に、他地域の処理サーバへのイベントの転送を最小限に抑えることができる。よって、ディスパッチャやネットワークの負荷を低減させることができる。
【０２３５】
（付記６）ルール分配先算出部１３は、サーバＩＤ集合をもとに、ルール受信部１１が入力した処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性に指定されている属性値に対応づけられた各処理装置について、処理ルールの配置前と配置後の当該処理装置の全処理ルールについて当該属性の属性値の和集合を算出し、算出した和集合の要素の増加数が最も小さい処理装置を当該属性の分配先として選択し、キー属性決定部１４は、各属性の中から、分配先における和集合の要素の増加数が最も小さい属性をキー属性に決定する付記５に記載のイベント処理システム。
【０２３６】
そのような構成によれば、新規処理ルールのイベント条件に含まれるイベントの各属性のサーバＩＤ集合のサイズが２以上である場合でも、キー属性を決定することができる。従って、例えば、多数の処理サーバおよびディスパッチャが地域ごとに分散して配置されている場合であっても、他地域の処理サーバへのイベントの転送を最小限に抑えることができる。
【０２３７】
（付記７）ルール分配装置１０が、ルール受信部１１が受信した処理ルールのイベント条件に含まれるイベントの各属性の属性値が限定できない場合、いずれかの属性を分割対象属性とし、分割対象属性を限定するための属性値を生成し、生成した属性値をもとに複数のイベント条件を生成し、複数のイベント条件の各々を処理ルールに付加して新たな複数の処理ルールに分割するルール分割部１９を備える付記１から付記６のうちのいずれか１つに記載のイベント処理システム。
【０２３８】
そのような構成によれば、各候補キー属性に対する値を限定することができない処理ルールであっても、デバイスから発生するイベントが複数のサーバに分散されるように、ルール分配することができる。
【０２３９】
（付記８）ルール分割部１９は、処理ルールのイベント条件に含まれるイベントの各属性を分割対象属性とした場合に、当該属性に対する属性値の数が分割後に最も小さくなる属性、または、分割後に新たに生成される処理ルールの数が最も小さくなる属性を分割対象属性として選択する付記７に記載のイベント処理システム。
【０２４０】
そのような構成によれば、分割後に値の数がより少なくなる候補キー属性、または、分割後にルール数がより少なくなる候補キー属性を分割対象属性として選択することができる。従って、ルール数を必要以上に増加させることがないので、ディスパッチャおよび処理サーバの負荷を必要以上に増大させることがない。
【０２４１】
（付記９）キー属性決定部１４は、ルール受信部１１が入力した処理ルールのイベント条件に含まれるイベントの属性ごとに、当該属性が候補キー属性であるか否かを判定し、候補キー属性であると判断した属性の中からキー属性を決定する付記１から付記８のうちのいずれか１つに記載のイベント処理システム。
【０２４２】
そのような構成によれば、ルール分配装置におけるキー属性決定部は、アプリケーションから処理ルールが登録されたときに、処理ルールのイベント条件のイベントに含まれる属性のうち、候補キー属性に該当する属性に対してキー属性の算出処理を行えばよい。よって、ルール分配装置の処理負荷をより低減することができる。
【０２４３】
この出願は、２０１２年８月３１日に出願された日本特許出願２０１２−１９１２６１を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【０２４４】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記の実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【符号の説明】
【０２４５】
１０、１００、６００、７００、８００  ルール分配装置
１１、１１０  ルール受信部
１３、１３０  ルール分配先算出部
１４、１４０  キー属性決定部
１５、１５０  振り分けルール生成部
１６、１６０  ルール並び替え部
１７、１７０  属性値担当サーバ解決部
１９、１９０  ルール分割部
２０−１〜２０−ｎ  処理装置
３０−１〜３０−ｎ  イベント振り分け装置
１２０  サーバ割り当て部
１８０  候補キー属性集合保持部
２００、２００−１〜２００−ｎ、９００−１〜９００−ｎ  処理サーバ
３００−１〜３００−ｎ  ディスパッチャ
４００、４００−１〜４００−ｎ  アプリケーション
５００−１〜５００−ｎ  デバイス
【図１】
2014034037.tif 000003
【図２】
2014034037.tif 000004
【図３】
2014034037.tif 000005
【図４】
2014034037.tif 000006
【図５】
2014034037.tif 000007
【図６】
2014034037.tif 000008
【図７】
2014034037.tif 000009
【図８】
2014034037.tif 000010
【図９】
2014034037.tif 000011
【図１０】
2014034037.tif 000012
【図１１】
2014034037.tif 000013
【図１２】
2014034037.tif 000014
【図１３】
2014034037.tif 000015
【図１４】
2014034037.tif 000016
【図１５】
2014034037.tif 000017
【図１６】
2014034037.tif 000018
【図１７】
2014034037.tif 000019
【図１８】
2014034037.tif 000020
【図１９】
2014034037.tif 000021
【図２０】
2014034037.tif 000022
【図２１】
2014034037.tif 000023
【図２２】
2014034037.tif 000024
【図２３】
2014034037.tif 000025
【図２４】
2014034037.tif 000026
【図２５】
2014034037.tif 000027
【図２６】
2014034037.tif 000028
【図２７】
2014034037.tif 000029
【国際調査報告】
2014034037.tif 000030
2014034037.tif 000031