(57)【特許請求の範囲】
【請求項１】
ネットワークで相互に接続された、少なくとも１つの第１のノードと少なくとも１つの第２のノードとを含み、
前記第１のノードは、イベント配信を受信し、受信した前記イベント配信を前記第２のノードへ転送する経路制御部と、
代理通知要求を受信し、受信した前記代理通知要求に基づいてイベント通知を送信するイベント通知部と、
前記イベント配信の一定時間毎の転送数を前記第２のノード毎に保持するノード毎イベント転送数保持部と、を含み、
前記経路制御部は、前記転送数に基づいて、転送する前記イベント配信に前記第１のノード自身の識別子及び対応する負荷情報を付加し、
前記第２のノードは、前記第１のノードの識別子及び対応する負荷情報の組を１つ以上保持する他ノード負荷情報保持部と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、当該第２のノード自身の負荷情報に基づいて、前記他ノード負荷情報保持部の内容に基づいて決定した前記第１のノードへ前記イベントの前記代理通知要求を送信するイベント制御部と、を含む、
ことを特徴とするイベント配信システム。
【請求項２】
前記第１のノードは、前記他ノード負荷情報保持部を更に含み、
前記経路制御部は、当該経路制御部に対応する前記第１のノードの前記負荷情報と前記他ノード負荷情報保持部の保持する前記負荷情報との内の、相対的に低い前記負荷情報を有する前記第１のノードの内の１以上を選択し、選択した前記第１のノードの前記識別子及び前記負荷情報を前記転送数に基づいて前記イベント配信に付加する
ことを特徴とする請求項１記載のイベント配信システム。
【請求項３】
前記第２のノードは、前記経路制御部と前記ノード毎イベント転送数保持部とを更に含むことを特徴とする請求項１または２記載のイベント配信システム。
【請求項４】
前記第２のノードは、負荷範囲情報とイベント通知数とを保持する代理通知条件保持部を更に含み、
前記イベント通知部は、前記第２のノード自身の前記負荷情報と前記代理通知条件保持部に保持されている前記負荷範囲情報及び前記イベント通知数とに基づいて、前記イベントそれぞれについて、前記イベント通知を送信するか否かを判定し、
前記代理通知要求部は、前記第２のノード自身の前記負荷情報と前記代理通知条件保持部に保持されている前記負荷範囲情報及び前記イベント通知数とに基づいて、前記イベントそれぞれについて、代理通知を要求するか否かを判定する、
ことを特徴とする請求項１乃至３のいずれかに記載のイベント配信システム。
【請求項５】
前記経路制御部は、前記負荷情報を、ＣＰＵ使用率、保留しているイベント通知メッセージ数、及び前記イベント通知メッセージに含まれる内の前記イベントの内容の任意の組合せに基づいて生成ことを特徴とする、
請求項１乃至４のいずれかに記載のイベント配信システム。
【請求項６】
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送する経路制御部と、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部と
前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するイベント制御部と、を含み、
前記経路制御部は、前記転送数に基づいて、転送する前記イベント配信に自身に対応する前記識別子及び対応する前記負荷情報を付加する
ことを特徴とするイベント配信装置。
【請求項７】
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送する経路制御部と、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部と
前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するイベント制御部と、を含み、
前記経路制御部は、前記転送数に基づいて、前記イベント配信に前記自身に対応する前記負荷情報及び前記他ノード負荷情報保持部の保持する前記負荷情報の内の相対的に低い前記負荷情報を有する前記自身に対応する前記イベント配信装置及び前記他イベント配信装置の内の１以上を選択し、選択した自身に対応する前記イベント配信装置及び前記他イベント配信装置の前記識別子及び対応する前記負荷情報を付加する
ことを特徴とするイベント配信装置。
【請求項８】
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送するステップと、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するステップと、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部に保持された前記転送数に基づいて、転送する前記イベント配信に自身に対応する前記識別子及び対応する前記負荷情報を付加するステップと、を有する
ことを特徴とするイベント配信方法。
【請求項９】
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送するステップと、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するステップと、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部に保持された前記転送数に基づいて、前記イベント配信に前記自身に対応する前記負荷情報及び前記他ノード負荷情報保持部の保持する前記負荷情報の内の相対的に低い前記負荷情報を有する前記自身に対応する前記イベント配信装置及び前記他イベント配信装置の内の１以上を選択し、選択した自身に対応する前記イベント配信装置及び前記他イベント配信装置の前記識別子及び対応する前記負荷情報を付加するステップと、を有する
ことを特徴とするイベント配信方法。
【請求項１０】
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送する処理と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信する処理と、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部に保持された前記転送数に基づいて、前記イベント配信に前記自身に対応する前記負荷情報及び前記他ノード負荷情報保持部の保持する前記負荷情報の内の相対的に低い前記負荷情報を有する前記自身に対応する前記イベント配信装置及び前記他イベント配信装置の内の１以上を選択し、選択した自身に対応する前記イベント配信装置及び前記他イベント配信装置の前記識別子及び対応する前記負荷情報を付加する処理と、
をコンピュータに実行させることを特徴とするイベント配信用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、イベント配信システム、イベント配信装置、イベント配信方法及びイベント配信用プログラムに関し、特に、アプリケーションが要求するイベントを抽出、配信するイベント配信システム、イベント配信装置、イベント配信方法、及びイベント配信プログラムに関する。
【背景技術】
【０００２】
イベント配信に関して、さまざまな関連技術が知られている。
【０００３】
パブリッシャ（publisher、以下pubと呼ぶ場合もある）は、イベントをパブリッシュ（publish）する。イベントは、例えば、ＲＦＩＤ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ  ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）或いはセンサ等のデバイスによる周辺情報の検出、ユーザによる周辺情報、自身の気分或いはその他情報の書き込みなどである。
【０００４】
パブリッシュされたイベントは、予め定められた条件に基づいて抽出され、抽出されたイベントは、予め定められた通知先であるアプリケーション（application、以下appと呼ぶ場合もある）に通知（notify）される。アプリケーションに通知されるイベントは、イベントを通知する条件であるサブスクリプション（subscription）に基づいて抽出される。
【０００５】
パブリッシャがパブリッシュしたイベントをアプリケーションに通知する機能を実現するために、ネットワークを構成する場合がある。例えば、図２に示すようなイベント配信ネットワーク（以下、イベント配信ＮＷ（ＮｅｔＷｏｒｋ））は、イベントの転送や通知を行う複数のイベント配信装置（ノード（node）と呼ぶ場合もある）を含む。更に、イベント配信ＮＷは、アプリケーションとパブリッシャとサブスクリプションを登録するサブスクライバ（subscriber）とに接続している。サブスクリプションは、例えば、イベント配信ＮＷを構成するノードに分散登録される。
【０００６】
イベント処理システムの一例が、特許文献１に記載されている。特許文献１に記載された負荷分散振り分けシステムは、以下のように動作する。まず、複数のデバイスが個々のイベントを検出する。そして、コンテキスト依存振り分け器は、予め設定されたルール（サブスクリプションの一種）に基づいて、検出されたイベントを、それぞれの処理サーバに転送する。
【０００７】
処理サーバは、予め設定されたルール（サブスクリプションの一種）に基づく特定の条件が転送されたイベントにより満足されたか否かを判定し、満足された場合に、アプリケーションに対してイベント通知を行う。 
また、関連技術であるサブスクリプションの分散登録方式が、非特許文献１及び非特許文献２に記載されている。非特許文献１には、サブスクリプションを管理するノードを、サブスクリプションを構成するデータに基づいて決める「Mercury」が、記載されている。特許文献２には、サブスクライバからサブスクリプションを受信したノードが、これを登録し、管理する「SIENA」が記載されている。
【０００８】
具体例の１つとして、Mercuryについて詳細に説明する。Mercuryは、複数のノードをリンクにした複数のＨＵＢから構成されている。ＨＵＢは、サブスクリプションを構成する属性毎に存在する。ＨＵＢを構成する各ノードは、当該属性の取りうる属性値が割り当てられていて、当該属性の属性値を持つサブスクリプションが登録される。
【０００９】
例えば、属性はXとYであり、各属性の取りうる属性値は属性X及び属性Y共に０〜３２０であるとする。この場合、Mercuryでは、図４３のように、各属性に対応してＨＵＢ「Ｈｘ」と「Ｈｙ」とが、存在する。この例において、ＨＵＢ「Ｈｘ」はノードａ、ｂ、ｃ及びｄから構成され、ＨＵＢ「Ｈｙ」はノードｅ、ｆ及びｇから構成されている。図２４に示すように、例えば、ノードａが管理する属性値は、[160,240］であり、ノードａは、属性Xの属性値[160, 240）を含むサブスクリプションを管理する。
【００１０】
Mercuryにおけるサブスクリプションの登録は、次のように行われる。まずサブスクライバが、Mercuryを構成するノードの１つにサブスクリプションを送信する。サブスクリプションを受信したノードは、サブスクリプションを構成する属性の１つを選択し、選択した属性の属性値を管理するノードにサブスクリプションを転送する。サブスクリプションを転送されたノードは、このサブスクリプションを管理する。各ノードは、サブスクリプションの転送先を、それぞれのノードに登録されているルーティングテーブルを用いて決定する。
【００１１】
例えば、図４３に示すように、ノードｄがサブスクリプション「50≦x≦150、150≦y≦250」をクエリ（ｑｕｅｒｙ）として受信したとする。このとき、ノードｄは、サブスクリプションを構成する属性（ｘ、ｙ）からｘを選択し、属性ｘの属性値(50≦x≦150)を管理するノード（ここではノードｂとノードｃ）にサブスクリプションを転送する。サブスクリプションを受信したノードｂとノードｃとは、転送されたサブスクリプションを管理する。即ち、この時点で、ノードｂとノードｃとは、サブスクリプションを登録する。
【００１２】
Mercuryにおけるイベントの配信、一致判定は、次のように行われる。まずパブリッシャが、Mercuryを構成するノードの内、のいずれか１つにイベントを送信する。パブリッシャが送信したイベントを受信したノードは、そのイベントを構成する各属性を管理するＨＵＢにイベントを送信する。そのノードが送信したイベントを受信した１または複数のノード（ノードαと呼ぶ）は、ノードαが属するＨＵＢで管理される属性の属性値を、この受信したイベントから取得する。そして、ノードαは、取得した属性値を管理するノード(ノードβと呼ぶ)に、その受信したイベントを転送する。ノードαは、サブスクリプションの転送と同様に、それぞれに登録されているルーティングテーブルを用いて、イベントの転送先を決定する。そのイベントを受信したノードβは、自身が管理しているサブスクリプションとイベントとの一致処理を行う。
【００１３】
例えば、図４３に示すように、各ＨＵＢのノードｂとノードｅとがイベント「x=100, y=200」を受信したとする。このときノードｂは、ノードｂが属するＨＵＢで管理される属性ｘの属性値「１００」をイベントから取得する。そしてノードｂは、属性ｘに対応するサブスクリプションを管理しているので、イベント「x=100, y=200」との一致判定を行う。ノードｂは、サブスクリプション「50≦x≦150、150≦y≦250」を管理しているので、イベント「x=100, y=200」を、当該サブスクリプションに一致すると判定する。ノードｅは、ノードｅが属するＨＵＢの管理する属性ｙの属性値「２００」をイベントから取得し、属性ｙに対応するサブスクリプションを管理しているので、イベント「x=100, y=200」との一致判定を行う。ノードｅは、サブスクリプションを管理していないため、何も行わない。
【先行技術文献】
【特許文献】
【００１４】
【特許文献１】特開２００６−３０９７０１号公報
【非特許文献】
【００１５】
【非特許文献１】Ashwin R. Bharambe, Mukesh Agrawal, Srinivasan Seshan, "Mercury: Supporting Scalable Multi-Attribute Range Queries", In SIGCOMM, p353-366, 2004
【非特許文献２】Antonio Carzaniga, David S. Rosenblum, Alexander L. Wolf, "Design of a Scalable Event Notification Service: Interface and Architecture", University of Colorado Department of Computer Science Technical Report CU-CS-863-98, 1998
【発明の概要】
【発明が解決しようとする課題】
【００１６】
しかしながら、上述した先行技術文献に記載された技術においては、アプリケーションへのイベントの通知が遅れる場合があるという問題点がある。
【００１７】
その理由は、通知先が多いイベントが大量に発生した場合、これらのイベントを処理する１または複数のノードにおいてイベント通知処理の負荷が高くなり、イベントを受信してからアプリケーションに通知するまでの処理に時間が掛かる場合がある為である。
【００１８】
上述の課題を具体的に説明する。
【００１９】
イベント配信ＮＷに接続するアプリケーションは、ユーザにサービスを提供する。そのサービスは、イベント発生から一定時間以内にユーザに提供することを、求められる。例えば、ユーザの位置情報に応じた広告をユーザの携帯端末に配信するサービスにおいて、ユーザの位置情報を示すイベントをイベント配信ＮＷが受信してから、ユーザの携帯端末に広告が配信されるまでの時間は、1秒程度であることを求められる。
【００２０】
しかし、大地震の発生や著名人のスキャンダルの発生など、多くの人が興味を持つイベントが大量に発生した場合、これらのイベントを処理するノードにおいてイベント通知処理の負荷が高くなる。このため、それらのノードがイベントを受信してからアプリケーションに通知するまでの処理の時間が長くなってしまう場合がある。
【００２１】
例えば、非特許文献１の４．４節には、各ノードの過去の負荷情報から、高負荷が掛かっている範囲の管理を行う、ノードの密度を大きくするロードバランシングの技術が開示されている。
【００２２】
しかし、ロードバランシングを行った場合、ノードが管理する属性値の範囲が変化するため、それらのノードが管理するサブスクリプションと受信するイベントとが変化する。そのため、ロードバランシングにおいては、サブスクリプションの登録ノードの変更と、イベントまたはサブスクリプションが正しいノードに転送されるように各ノードのルーティングテーブルの更新と、を行う必要がある。ここで、上述の「正しいノード」とは、イベントまたはサブスクリプション内のある属性の属性値を管理しているノードを示す。
【００２３】
ロードバランシングはイベント配信遅延の解決手法の一つである、と考えることはできる。しかしながら、上述の通り、イベント配信ＮＷ全体に変更が必要なため、頻繁に行うことはできない。従って、イベント配信の遅延を常時解決された状態にすることはできない。また、同様の理由から、ロードバランシングの処理には時間が掛かる。そのため、もしあるノードの負荷が高くなった直後にロードバランシングが行われたとしても、そのノードの負荷が軽減されるまでには時間が掛かり、イベント配信が遅延する。
【００２４】
本発明の目的は、上述した問題点を解決できるイベント配信システム、イベント配信装置、イベント配信方法及びイベント配信用プログラムを提供することにある。
【課題を解決するための手段】
【００２５】
本発明のイベント配信システムは、ネットワークで相互に接続された、少なくとも１つの第１のノードと少なくとも１つの第２のノードとを含み、
前記第１のノードは、イベント配信を受信し、受信した前記イベント配信を前記第２のノードへ転送する経路制御部と、
代理通知要求を受信し、受信した前記代理通知要求に基づいてイベント通知を送信するイベント通知部と、
前記イベント配信の一定時間毎の転送数を前記第２のノード毎に保持するノード毎イベント転送数保持部と、を含み、
前記経路制御部は、前記転送数に基づいて、転送する前記イベント配信に前記第１のノード自身の識別子及び対応する負荷情報を付加し、
前記第２のノードは、前記第１のノードの識別子及び対応する負荷情報の組を１つ以上保持する他ノード負荷情報保持部と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、当該第２のノード自身の負荷情報に基づいて、前記他ノード負荷情報保持部の内容に基づいて決定した前記第１のノードへ前記イベントの前記代理通知要求を送信するイベント制御部と、を含む。
【００２６】
本発明のイベント配信装置は、イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送する経路制御部と、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部と
前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するイベント制御部と、を含み、
前記経路制御部は、前記転送数に基づいて、転送する前記イベント配信に自身に対応する前記識別子及び対応する前記負荷情報を付加する。
【００２７】
本発明のイベント配信装置は、イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送する経路制御部と、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部と
前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するイベント制御部と、を含み、
前記経路制御部は、前記転送数に基づいて、前記イベント配信に前記自身に対応する前記負荷情報及び前記他ノード負荷情報保持部の保持する前記負荷情報の内の相対的に低い前記負荷情報を有する前記自身に対応する前記イベント配信装置及び前記他イベント配信装置の内の１以上を選択し、選択した自身に対応する前記イベント配信装置及び前記他イベント配信装置の前記識別子及び対応する前記負荷情報を付加する。
【００２８】
本発明のイベント配信方法は、イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送するステップと、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するステップと、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部に保持された前記転送数に基づいて、転送する前記イベント配信に自身に対応する前記識別子及び対応する前記負荷情報を付加するステップと、を有する。
【００２９】
本発明のイベント配信方法は、イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送するステップと、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するステップと、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部に保持された前記転送数に基づいて、前記イベント配信に前記自身に対応する前記負荷情報及び前記他ノード負荷情報保持部の保持する前記負荷情報の内の相対的に低い前記負荷情報を有する前記自身に対応する前記イベント配信装置及び前記他イベント配信装置の内の１以上を選択し、選択した自身に対応する前記イベント配信装置及び前記他イベント配信装置の前記識別子及び対応する前記負荷情報を付加するステップと、を有する。
【００３０】
本発明のイベント配信用プログラムは、イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送する処理と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信する処理と、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部に保持された前記転送数に基づいて、前記イベント配信に前記自身に対応する前記負荷情報及び前記他ノード負荷情報保持部の保持する前記負荷情報の内の相対的に低い前記負荷情報を有する前記自身に対応する前記イベント配信装置及び前記他イベント配信装置の内の１以上を選択し、選択した自身に対応する前記イベント配信装置及び前記他イベント配信装置の前記識別子及び対応する前記負荷情報を付加する処理と、
をコンピュータに実行させる。
【発明の効果】
【００３１】
本発明は、通知先が多いイベントの大量発生などに起因する、イベント配信の遅滞を防止することができるという効果がある。
【図面の簡単な説明】
【００３２】
【図１】本発明の第１の実施形態の構成を示すブロック図である。
【図２】本発明の第１乃至第３の実施形態に係る、イベント配信システムの構成を示すブロック図である。
【図３】本発明の第１乃至第３の実施形態におけるイベントの一例を示す図である。
【図４】本発明の第１乃至第３の実施形態におけるイベントパターンの一例を示す図である。
【図５】本発明の第１乃至第３の実施形態におけるサブスクリプションの一例を示す図である。
【図６】本発明の第１乃至第３の実施形態におけるサブスクリプション登録メッセージのデータフォーマットを示す図である。
【図７】本発明の第１乃至第３の実施形態におけるサブスクリプション削除メッセージのデータフォーマットを示す図である。
【図８】本発明の第１乃至第３の実施形態におけるイベント配信メッセージのデータフォーマットを示す図である。
【図９】本発明の第１乃至第３の実施形態におけるイベント通知メッセージのデータフォーマットを示す図である。
【図１０】本発明の第１乃至第３の実施形態における代理通知メッセージのデータフォーマットを示す図である。
【図１１】本発明の第１乃至第３の実施形態における経路情報保持部が保持する経路情報テーブルの構造を示す図である。
【図１２】本発明の第１乃至第３の実施形態におけるノード毎イベント転送数保持部１２０が保持するイベント転送数テーブルの構造を示す図である。
【図１３】本発明の第１の実施形態における経路制御部がサブスクライバからサブスクリプション登録メッセージまたはサブスクリプション削除メッセージを受信したときの動作を示すフローチャートである。
【図１４】本発明の第１の実施形態における経路制御部が他ノードからサブスクリプション登録メッセージまたはサブスクリプション削除メッセージを受信したときの動作を示すフローチャートである。
【図１５】本発明の第１の実施形態における経路制御部がパブリッシャからイベント配信メッセージを受信したときの動作を示すフローチャートである。
【図１６】本発明の第１の実施形態における経路制御部が他ノードからイベント配信メッセージを受信したときの動作を示すフローチャートである。
【図１７】本発明の第１の実施形態におけるサブスクリプション制御部がサブスクリプション登録メッセージを受信したときの動作を示すフローチャートである。
【図１８】本発明の第１の実施形態におけるサブスクリプション制御部がサブスクリプション削除メッセージを受信したときの動作を示すフローチャートである。
【図１９】本発明の第１の実施形態におけるイベント制御部がイベント配信メッセージを受信したときの動作を示すフローチャートである。
【図２０】本発明の第１の実施形態におけるイベント制御部がイベント配信メッセージを受信したときの動作を示すフローチャートである。
【図２１】本発明の第１の実施形態における他ノード負荷情報保持部が保持する他ノード負荷情報テーブルの構造を示す図である。
【図２２】本発明の第１の実施形態における代理通知要求制御部が代理通知要求を受信したときの動作を示すフローチャートである。
【図２３】本発明の第１の実施形態におけるメッセージ転送部がメッセージを受信したときの動作を示すフローチャートである。
【図２４】本発明の第１の実施形態における(実施形態1)イベント配信ＮＷの構成の一例を示す図である。
【図２５】本発明の第１の実施形態における経路情報保持部が保持する経路情報テーブルの一例を示す図である。
【図２６】本発明の第１の実施形態における経路情報保持部が保持する経路情報テーブルの一例を示す図である。
【図２７】本発明の第１の実施形態における経路情報保持部が保持する経路情報テーブルの一例を示す図である。
【図２８】本発明の第１の実施形態における経路情報保持部が保持する経路情報テーブルの一例を示す図である。
【図２９】本発明の第１の実施形態における経路情報保持部が保持する経路情報テーブルの一例を示す図である。
【図３０】本発明の第１の実施形態における経路情報保持部が保持する経路情報テーブルの一例を示す図である。
【図３１】本発明の第１の実施形態におけるノード毎イベント転送数保持部が保持するイベント転送数レコードのテーブルの一例を示す図である。
【図３２】本発明の第１の実施形態におけるノード毎イベント転送数保持部が保持するイベント転送数レコードのテーブルの一例を示す図である。
【図３３】本発明の第１の実施形態におけるノード毎イベント転送数保持部が保持するイベント転送数レコードのテーブルの一例を示す図である。
【図３４】本発明の第１の実施形態におけるノード毎イベント転送数保持部が保持するイベント転送数レコードのテーブルの一例を示す図である。
【図３５】本発明の第１の実施形態におけるノード毎イベント転送数保持部が保持するイベント転送数レコードのテーブルの一例を示す図である。
【図３６】本発明の第１の実施形態におけるノード毎イベント転送数保持部が保持するイベント転送数レコードのテーブルの一例を示す図である。
【図３７】本発明の第２の実施形態の構造を示すブロック図である。
【図３８】本発明の第２の実施形態における経路制御部がパブリッシャからイベント配信メッセージを受信したときの動作を示すフローチャートである。
【図３９】本発明の第３の実施形態の構成を示すブロック図である。
【図４０】本発明の第３の実施形態における代理通知条件保持部が保持する代理通知条件テーブルの一例を示す図である。
【図４１】本発明の第３の実施形態におけるイベント制御部がイベントを受信したときの動作を示すフローチャートである。
【図４２】本発明の第４の実施形態の構成を示すブロック図である。
【図４３】関連技術のMercuryの概要を示す図である。
【発明を実施するための形態】
【００３３】
次に、本発明の実施形態について図面を参照して詳細に説明する。
【００３４】
［用語の説明］
最初に、本明細書で使用する用語の意味を説明する。
【００３５】
「イベント(event)」とは、何らかの現象を契機として発生するデータのことである。例えば、イベントは、携帯端末などの操作、及びＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）タグやセンサを用いた信号の検出などに基づいて発生するデータのことである。パブリッシャ（後述）は、これらのイベントを、イベント配信ＮＷ（後述）にパブリッシュ（後述）する。
【００３６】
イベントは、１つのデータに限られず、複数のデータを含んでいてもよい。イベントを構成する１つまたは複数のデータを、それぞれ「属性４０２」と呼ぶ。
【００３７】
図３は、イベントの一例を示す図である。図３に示すように、イベント４０１は、１つ以上の属性４０２を含む。属性４０２は、イベント４０１を検出した装置やセンサなどを示すデータ（例えば、図３に示す「装置ID」）、その装置やセンサが取得したデータ（例えば、図３に示す「温度」）、データの取得場所や取得時刻（例えば、図３に示す「場所」「時刻」）などである。また、「装置ID」、「温度」、「場所」、「時刻」などの各属性４０２における名称を属性名４０３と呼び、属性名４０３に対する各データ値（「ID1」、「30℃」、「東京都港区」、「10:10:25」など）を属性値４０４と呼ぶ。つまり、属性４０２は、属性名４０３と属性値４０４とを含む。尚、上述のイベント４０１のデータフォーマットは、一例であり、例えば属性４０２以外の情報を含んでいてもよい。
【００３８】
また、イベント４０１は、上述のパブリッシャがパブリッシュする場合だけではなく、後述する、複数のイベント配信装置の間で転送される転送要求、及び、代理要求にも含まれる場合がある。
【００３９】
「イベントパターン(event pattern)」とは、アプリケーション（後述）への通知の対象となる、イベントを指定する条件である。
【００４０】
図４は、イベントパターンの一例を示す図である。図４に示すように、イベントパターン３１１は、１つ以上の属性３１２を含む。属性３１２は、属性名３１３と属性値３１４とを含む。属性名３１３及び属性値３１４は、それぞれイベント４０１の属性名４０３及び属性値４０４と同等のものである。尚、上述のイベントパターン３１１のデータフォーマットは、一例であり、例えば属性３１２以外の情報を含んでいてもよい。
【００４１】
例えば、図４に示す例において、イベントパターン３１１は、属性名３１３「装置ID」及びその属性値３１４「ID1」を含む属性３１２と、属性名３１３「温度」及びその属性値３１４「30℃」を含む属性３１２と、の２つの属性３１２を含んでいる。
【００４２】
「イベント一致判定（処理）」とは、イベント配信装置において、イベント４０１とイベントパターン３１１とが一致（以下、マッチ(match)と言う場合もある）するかどうかを判定すること（処理）である。
【００４３】
イベント４０１がイベントパターン３１１に一致（マッチ）するかどうかを判定することとは、イベントパターン３１１で指定された属性３１２とイベント４０１の属性４０２とが一致するかどうかを判定することである。属性３１２と属性４０２との一致とは、イベントパターン３１１の属性名３１３に対する属性値３１４と、イベント４０１の同じ属性名４０３に対する属性値４０４とが一致する（属性値４０４が属性値３１４で示される範囲の値に含まれる場合も一致するという）ことである。即ち、イベントパターン３１１の属性３１２がイベント４０１の属性４０２に一致する或いは含まれる場合に、判定結果は、一致（マッチ）となる。
【００４４】
例えば、図３に示すイベント４０１の内容と図４に示すイベントパターン３１１の内容とを例にして説明する。
【００４５】
まず、イベントパターン３１１で指定されている属性名３１３「装置ID」に対する属性値３１４「ID1」は、イベント４０１の属性名４０３「装置ID」に対する属性値４０４「ID1」と一致している。また、イベントパターン３１１で指定されている属性名３１３「温度」に対する属性値３１４「30℃」は、イベント４０１の属性名４０３「温度」に対する属性値４０４「30℃」と一致している。従って、図３に示すイベント４０１と、図４に示すイベントパターン３１１と、のイベント一致判定の判定結果は、一致となる。尚、図４に示すイベントパターン３１１では、図３に示すイベント４０１に記述されている属性４０２のうち、属性名４０３「場所」及び属性名４０３「時刻」に対する属性３１２は指定されていない。このようにある属性４０２に対応するイベントパターン３１１の属性３１２が指定されていない場合、その属性４０２（本例の場合、属性名４０３が「場所」、「時刻」である属性４０２）の属性値４０４は、どのような値でもよい。
【００４６】
なお、イベントパターン３１１の属性値３１４と、イベント４０１の属性値４０４の一部とが一致する場合も、一致と判定するようにしても良い。例えば、イベントパターン３１１の属性値３１４「東京都」と、イベント４０１の属性値４０４「東京都港区」とを、一致すると判定するようにしても良い。また、属性名３１３及び属性値３１４と属性名４０３及び属性値４０４とが完全に一致する場合を、一致と判定するようにしても良い。更に、一致判定に使用する属性値３１４は、１つの値ではなく、範囲を指定するものであってもよい。
【００４７】
本発明の第１の実施形態に係るイベント配信装置は、パブリッシャがパブリッシュしたイベント４０１と、サブスクライバがサブスクライブしたサブスクリプションに含まれるイベントパターン３１１との一致判定を行う。
【００４８】
「パブリッシャ(publisher)」とは、検出したイベント４０１を、イベント配信ＮＷにパブリッシュする装置、システム、プログラムなどである。パブリッシャは、起きた事象そのものを検出する装置など（例えば、携帯端末、ＲＦタグ、センサなど）でもよく、そのような装置からイベント４０１に関する情報を受け取って、イベント配信ＮＷにイベント４０１をパブリッシュする装置（例えばサーバなど）などでもよい。
【００４９】
「パブリッシュ(publish)」とは、パブリッシャがイベント配信ＮＷなどにイベント４０１を送信することである。「パブリッシャがイベント４０１をイベント配信ＮＷにパブリッシュする」などと言う。
【００５０】
「サブスクライバ(subscriber)」とは、イベント配信ＮＷにイベント４０１の通知に関する情報（例えば、どのような通知先にイベント４０１を通知するかなど）を指定する装置、システム、プログラムなどである。より具体的に説明すると、サブスクライバは、イベント配信ＮＷに、次に説明するサブスクリプション３０１をサブスクライブする。
【００５１】
「サブスクリプション(subscription)」とは、サブスクライバがアプリケーションへのイベントの通知を要求するときに、イベント配信ＮＷにサブスクライブするデータのことである。
【００５２】
図５は、サブスクリプションの一例を示す図である。図５に示すようにサブスクリプション３０１は、サブスクリプションＩＤ３０２とイベントパターン３１１と通知先３０３とを含む。サブスクリプションＩＤ３０２は、各サブスクリプション３０１を一意に識別する。
【００５３】
通知先３０３は、イベントパターン３１１に一致したイベント４０１の配信先である、1つ以上のアプリケーション（後述）の識別子リストである。例えば、図５に示すサブスクリプション３０１の場合、サブスクリプションＩＤ３０２は「sub1」、イベントパターン３１１は「Event_Pattern(“場所”＝“東京都港区”）」、通知先３０３は“app1,app2,…,app1000”である。
【００５４】
サブスクリプション３０１のイベントパターン３１１とイベント４０１との一致判定も、イベント一致判定と呼ぶ。このような一致（マッチ）の場合、例えば、「イベント４０１がサブスクリプション３０１のイベントパターン３１１にマッチする」或いは「イベント４０１がサブスクリプション３０１に一致する」などとも言う。
【００５５】
「サブスクライブ(subscribe)」とは、サブスクライバがサブスクリプション３０１をイベント配信ＮＷなどに登録するために送信することである。「サブスクライバは、サブスクリプション３０１をイベント配信ＮＷにサブスクライブする」などと言う。
【００５６】
「アプリケーション(application)」とは、イベント配信ＮＷからイベント４０１を通知される通知先３０３である装置、システム、プログラムなどのことである。
【００５７】
なお、後述する実施形態では、イベント配信ＮＷにおけるサブスクリプション３０１及びイベント４０１の転送方法は、非特許文献１に示された「Mercury」と同じであるものとして説明するが、非特許文献２に示された「SIENA」で使用されている転送方法或いは他の転送方法であってもよい。
【００５８】
また、イベント配信ＮＷ中でやり取りされるメッセージは、図６に示すようなサブスクリプション登録メッセージ６１０、図７に示すようなサブスクリプション削除メッセージ６２０、図８に示すようなイベント配信メッセージ（イベント配信ともよばれる）６３０、図９に示すようなイベント通知メッセージ（イベント通知とも呼ばれる）６４０及び図１０に示すような代理通知メッセージ（代理通知要求とも呼ばれる）６５０」である。
【００５９】
図６はサブスクリプション登録メッセージ６１０のデータフォーマットを示す図である。図６に示すようにサブスクリプション登録メッセージ６１０は、送信元と送信先とメッセージ識別子（メッセージの種別を示す識別子）とサブスクリプション３０１とを含む。
【００６０】
図７はサブスクリプション削除メッセージ６２０のデータフォーマットを示す図である。図７に示すようにサブスクリプション削除メッセージ６２０は送信元と送信先とメッセージ識別子とサブスクリプションＩＤ３０２とイベントパターン３１１とを含む。
【００６１】
図８はイベント配信メッセージ６３０のデータフォーマットを示す図である。図８に示すように、イベント配信メッセージ６３０は、送信元と送信先とイベント４０１と送信元のノード識別子１３５と送信元の負荷情報１７３とを含む。また、イベント配信メッセージ６３０は、送信元のノード識別子１３５と送信元の負荷情報１７３とを、含まなくても良い。
【００６２】
図９はイベント通知メッセージ６４０のデータフォーマットを示す図である。図９に示すように、送信元と送信先とイベント４０１とサブスクリプション３０１とを含む。また、イベント通知メッセージ６４０は、サブスクリプション３０１を含まなくても良い。
【００６３】
図１０は代理通知メッセージ６５０のデータフォーマットを示す図である。図１０に示すように、代理通知メッセージ６５０は送信元と送信先とメッセージ識別子とイベント４０１とこのイベント４０１が一致するサブスクリプション３０１の集合とを含む。
【００６４】
なお、代理通知メッセージ６５０は、イベント４０１とイベント４０１が合致するサブスクリプション３０１の集合を含むが、イベント４０１とイベント４０１が合致するサブスクリプション３０１に格納されている通知先３０３の集合を含んでもよい。こうした場合、代理通知メッセージ６５０のサイズを小さくすることができる。
【００６５】
上述の各メッセージは、図示したように各メッセージの送信元と送信先とメッセージ識別子とを含むが、以下の説明ではこれらを省略する。また、上述の各メッセージのデータフォーマットは一例であり、他の情報を含んでいてもよい。
【００６６】
［第１の実施の形態］
次に、本発明の第１の実施形態について図面を参照して詳細に説明する。
【００６７】
図２は、本発明の第１の実施形態に係る、イベント配信システム１０の構成を示すブロック図である。図２を参照すると、本発明の第1の実施形態に係るイベント配信システム１０は、イベント配信ＮＷ２００と、１つ以上のサブスクライバ３００と、１つ以上のパブリッシャ４００と、１つ以上のアプリケーション５００とを含む。
【００６８】
イベント配信ＮＷ２００は、ノード（イベント配信装置とも呼ぶ）１００を２つ以上含む。尚、ノード１００は、第１のノード及び第２のノードとも呼ばれる。ノード１００は、第１のノードまたは第２のノードのいずれかとして固定されてもよいし、動作状態によって第１のノード及び第２のノードのいずれかとなってもよい。
【００６９】
ノード１００は、サブスクライバ３００から、サブスクリプション登録メッセージ６１０及びサブスクリプション削除メッセージ６２０を、パブリッシャ４００からイベント配信メッセージ６３０を、受信する。また、ノード１００は、アプリケーション５００にイベント通知メッセージ６４０を送信する。
【００７０】
サブスクライバ３００は、イベント配信ＮＷ２００に含まれるノード１００にサブスクリプション登録メッセージ６１０及びサブスクリプション削除メッセージ６２０を送信する。
【００７１】
パブリッシャ４００は、イベント配信ＮＷ２００に含まれるノード１００にイベント配信メッセージ６３０を送信する。
【００７２】
アプリケーション５００は、イベント配信ＮＷ２００に含まれるノード１００から、イベント通知メッセージ６４０を受信する。
【００７３】
図１は、本発明の第１の実施形態のイベント配信ＮＷ２００に含まれるノード１００の構成を示すブロック図である。
【００７４】
ノード１００は、図１に示すように、経路制御部１１０、ノード毎イベント転送数保持部１２０、経路情報保持部１３０、サブスクリプション制御部１４０、サブスクリプション保持部１５０、イベント制御部１６０、他ノード負荷情報保持部１７０、代理通知要求制御部１８０及びメッセージ転送部１９０を含む。
【００７５】
これらの各部は、例えば、プログラムにより所定の処理を図示しないコンピュータに実行させて以下に説明する動作を行うものであってもよい。また、所定の処理を実行するプログラムは図示しない記憶媒体に記憶されてもよい。
【００７６】
ノード１００の経路制御部１１０及びノード毎イベント転送数保持部１２０を含む部分は、第１のノードと呼ばれることもある。ノード１００のノードイベント制御部１６０及び他ノード負荷情報保持部１７０を含む部分は、第２のノードと呼ばれる場合もある。
上述の各部は、それぞれ次のように動作する。
【００７７】
ノード（第１のノード）１００の経路制御部１１０は、サブスクライバ３００、または、パブリッシャ４００、または、イベント配信ＮＷ２００中の他ノード１００から、イベント４０１またはサブスクリプション３０１を受信する。そして、経路制御部１１０は、経路情報保持部１３０に格納されている情報に基づいてイベント４０１またはサブスクリプション３０１の転送先を決定し、後述するメッセージ転送部１９０を介してイベント４０１またはサブスクリプション３０１を転送先に転送する。
【００７８】
尚、例えば、「経路制御部１１０がイベント４０１を受信する」という記載は、「経路制御部１１０がイベント配信メッセージ６３０を受信して、これに含まれるイベント４０１を受信する」ということを意味する。このような記載は、冗長な説明を避けるためのものであり、「サブスクリプション３０１を受信する」、「イベント４０１またはサブスクリプション３０１を転送先に転送する」という記載についても同様である。また、以後も同様に記載する場合がある。
【００７９】
また、経路制御部１１０は、イベント４０１を他ノード（第２のノード）１００に転送するときに、この他ノード１００のノード識別子１３５に対応するイベント転送数レコード１２１（後述の図１２）のイベント転送数（転送数とも呼ばれる）１２３を更新する。そして、経路制御部１１０は、このイベント転送数１２３が予め定められた値以上の場合、転送するイベント配信メッセージ６３０に、自ノード１００のノード識別子１３５と負荷情報１７３とを付加する。
【００８０】
ノード毎イベント転送数保持部１２０は、ある一定時間内に自ノード１００が他ノード１００に転送したイベント配信メッセージ６３０の数を、転送先のノード１００（他ノード１００）毎に格納する。
【００８１】
図１２は、ノード毎イベント転送数保持部１２０が保持するイベント転送数テーブル１２９の構造を示す図である。イベント転送数テーブル１２９は、図１２に示すように、ノード識別子１３５とイベント転送数１２３とをカラムとして持つイベント転送数レコード１２１からなる。イベント転送数レコード１２１に含まれるノード識別子１３５は、経路情報保持部１３０に登録されているノード１００のノード識別子１３５であり、予め格納されている。ノード毎イベント転送数保持部１２０は、イベント転送数１２３を予め定められた一定の時間毎に０にする。
【００８２】
経路情報保持部１３０は、経路制御部１１０がイベント４０１またはサブスクリプション３０１のルーティングを行うために必要な情報を保持する。尚、ルーティングは、さまざまな既知の手段によって実現される。本実施形態では、非特許文献１に記載されている既知の方式を利用するものとしているが、他の既知の手段を使用してもよい。
【００８３】
図１１は、経路情報保持部１３０が保持する経路情報テーブル１３９の構造を示す図である。図１１に示すように、経路情報保持部１３０は、１以上の経路情報レコード１３１からなる経路情報テーブル１３９を保持する。同じく図１１に示すように、経路情報レコード１３１は、属性名１３３と、属性値１３４と、この属性名１３３の属性値１３４を管理するノード１００のノード識別子１３５と、をカラムとして持つ。経路情報保持部１３０は、他ノード１００が管理する属性名１３３と属性値１３４とを含む経路情報レコード１３１、及び自ノード１００で管理する属性名１３３と属性値１３４とを含む経路情報レコード１３１を、保持する。
【００８４】
経路制御部１１０がサブスクライバ３００から、サブスクリプション登録メッセージ６１０またはサブスクリプション削除メッセージ６２０を受信したときの動作を、図１３を参照して説明する。図１３は、この動作を示すフローチャートである。
【００８５】
サブスクリプション登録メッセージ６１０を受信したときと、サブスクリプション削除メッセージ６２０を受信したときと、の経路制御部１１０における動作は同じであるため、図１３の説明では、「サブスクリプション登録メッセージ６１０またはサブスクリプション削除メッセージ６２０」の記載を省略して、「サブスクリプション登録メッセージ６１０」とのみ記載する。
【００８６】
経路制御部１１０は、サブスクライバ３００からサブスクリプション登録メッセージ６１０を受信する（ステップＦ１０）。
【００８７】
このとき、経路制御部１１０は、サブスクリプション登録メッセージ６１０内のサブスクリプション３０１に含まれるイベントパターン３１１を構成する属性３１２の内の１つを選択する（ステップＦ１１）。尚、経路制御部１１０は、例えば、その属性３１２をランダムに選択する。或いは、経路制御部１１０は、その属性３１２を他の所定の方法で選択してもよい。
【００８８】
続けて、経路制御部１１０は、経路情報保持部１３０を参照し、ステップＦ１１で選択した属性３１２の属性名３１３と、自ノード（第１のノード）１００で管理している属性名１３３のいずれかとが一致するか否かを確認する（ステップＦ１２）。属性名１３３を自ノード１００で管理しているということは、経路情報保持部１３０において、その属性名１３３を含む経路情報レコード１３１に含まれるノード識別子１３５が自ノード１００のノード識別子１３５と一致しているということである。一致しない場合（ステップＦ１２でｎｏ）、すなわち、ステップＦ１１で選択した属性３１２の属性名３１３を、自ノード１００が属するＨＵＢが管理していない場合、処理は、ステップＦ１７へ進む。
【００８９】
一致する場合（ステップＦ１２でｙｅｓ）、経路制御部１１０は、経路情報保持部１３０を参照し、ステップＦ１１で選択した属性３１２の属性名３１３及び属性値３１４と、経路情報レコード１３１の内のいずれかの自ノード１００で管理している属性名１３３及び属性値１３４と、が一致するか否かを確認する（ステップＦ１３）。
【００９０】
一致しない場合（ステップＦ１３でｎｏ）、すなわち、ステップＦ１１で選択した属性３１２の属性値３１４を自ノード１００と同じＨＵＢに属するいずれかの他ノード（第２のノード）１００が管理している場合、処理はステップＦ１５へ進む。
【００９１】
一致する場合（、ステップＦ１３でｙｅｓ）、経路制御部１１０は、サブスクリプション制御部１４０に該サブスクリプション登録メッセージ６１０を転送する（ステップＦ１４）。
【００９２】
ステップＦ１５において、経路制御部１１０は、経路情報保持部１３０からノード１００を選択する（ステップＦ１５）。続けて、経路制御部１１０は、選択したノード１００に後述するメッセージ転送部１９０を介してサブスクリプション登録メッセージ６１０を転送する（ステップＦ１６）。具体的には、例えば、経路制御部１１０は、自ノード１００が属するＨＵＢのリンク上において、時計回りで自ノード１００より後ろに出てくるノード１００のうち、最も自ノード１００に近いノード１００を、経路情報保持部１３０から選択する。
【００９３】
ステップＦ１７において、経路制御部１１０は、ステップＦ１１で選択した属性３１２の属性名３１３を管理するノード１００を、経路情報保持部１３０から選択する（ステップＦ１７）。続けて、経路制御部１１０は、選択したノード１００に、後述するメッセージ転送部１９０を介してサブスクリプション登録メッセージ６１０を転送する（ステップＦ１８）。
【００９４】
次に、ノード（第１のノード）１００の経路制御部１１０が他ノード１００からサブスクリプション登録メッセージ６１０またはサブスクリプション削除メッセージ６２０を受信したときの動作を、図１４を参照して説明する。図１４は、この動作を示すフローチャートである。尚、サブスクリプション登録メッセージ６１０を受信したときと、サブスクリプション削除メッセージ６２０を受信したときと、の経路制御部１１０の動作は同じであるため、図１４の説明では、「サブスクリプション登録メッセージ６１０またはサブスクリプション削除メッセージ６２０」を省略して、サブスクリプション登録メッセージ６１０とのみ記載する。
【００９５】
経路制御部１１０は、他ノード１００からサブスクリプション登録メッセージ６１０を受信したとき（ステップＦ２０）、受信したサブスクリプション３０１に含まれるイベントパターン３１１から属性３１２の内の１つを選択する（ステップＦ２１）。
【００９６】
続けて、経路制御部１１０は、経路情報保持部１３０を参照し、選択した属性３１２の属性名３１３及び属性値３１４と、経路情報レコード１３１の内のいずれかの自ノード（第１のノード）１００で管理する属性名１３３及び属性値１３４と、が一致するか否かを確認する（ステップＦ２２）。一致する場合（ステップＦ２２でｙｅｓ）、経路制御部１１０は、サブスクリプション制御部１４０に該サブスクリプション登録メッセージ６１０を転送する（ステップＦ２３）。
【００９７】
一致しない場合（ステップＦ２２でｎｏ）、経路制御部１１０は、その属性値３１４に一致する属性値１３４を含む経路情報レコード１３１、に含まれるノード識別子１３５を抽出し、抽出したノード識別子１３５に対応する他ノード（第２のノード）１００を選択する（ステップＦ２４）。
【００９８】
続けて、経路制御部１１０は、選択した他ノード１００に、後述するメッセージ転送部１９０を介してサブスクリプション登録メッセージ６１０を転送する（ステップＦ２５）。具体的な動作は、サブスクライバ３００からサブスクリプション登録メッセージ６１０またはサブスクリプション削除メッセージ６２０を受信したとき動作（図１３のステップF１５及びステップＦ１６）と同じであるため、説明を省略する。
【００９９】
次に、経路制御部１１０がパブリッシャ４００からイベント配信メッセージ６３０を受信したときの動作を、図１５を用いて説明する。図１５は、この動作を示すフローチャートである。
【０１００】
経路制御部１１０は、パブリッシャ４００からイベント配信メッセージ６３０を受信する（ステップＦ３０）。このとき、経路制御部１１０は、受信したイベント配信メッセージ６３０に含まれるイベント４０１を構成する属性４０２毎に、このイベント４０１の転送先（自ノード（第１のノード）１００のイベント制御部１６０または他ノード（第２のノード）１００）を決定し、決定した転送先にこのイベント４０１を転送する（ステップＦ３ＡとステップＦ３Ｂとの間に示す処理）。ステップＦ３Ａ及びステップＦ３Ｂの間の処理は、イベント４０１を構成する属性４０２毎に繰り返される。
【０１０１】
続けて、ステップＦ３ＡとステップＦ３Ｂとの間の、ステップＦ３１からステップＦ３９に示す処理の詳細を説明する。
【０１０２】
まず、経路制御部１１０は、経路情報保持部１３０を参照して、受信したイベント配信メッセージ６３０に含まれる属性名４０３と、自ノード（第１のノード）１００において管理する属性名１３３のいずれかとが一致するか否かを確認する（ステップＦ３１）。ここで、属性名４０３は、イベント配信メッセージ６３０に含まれるイベント４０１を構成する属性４０２の内から選択した属性４０２の属性名である。一致しない場合（ステップＦ３１でｎｏ）、処理は、ステップＦ３４へ進む。
【０１０３】
一致する場合（ステップＦ３１でｙｅｓ）、経路制御部１１０は、ステップＦ３１で選択した属性４０２の属性名４０３及び属性値４０４と、経路情報レコード１３１の内のいずれかの自ノード（第１のノード）１００において管理する属性名１３３及び属性値１３４と、が一致するか否かを確認する（ステップＦ３２）。一致しない場合（ステップＦ３２でｎｏ）、処理はＦ３９へ進む。
【０１０４】
一致する場合（ステップＦ３２でｙｅｓ）、経路制御部１１０は、イベント制御部１６０にステップＦ３０で受信したイベント配信メッセージ６３０を転送する（ステップＦ３３）。
【０１０５】
ステップＦ３４において、経路制御部１１０は、経路情報保持部１３０から、ステップＦ３１で選択した属性名４０３と同じ値の属性名１３３を含む経路情報レコード１３１、に含まれるノード識別子１３５を抽出し、そのノード識別子１３５に対応するノード（第２のノード）１００を選択する（ステップＦ３４）。
【０１０６】
次に、経路制御部１１０は、ノード毎イベント転送数保持部１２０を更新する（ステップＦ３５）。具体的な更新方法は、例えば、経路制御部１１０は、予め定められた個数（例えば、６０）の、単位時間転送数カウンタ（図示しない）を、をノード１００毎に備える。この単位時間転送数カウンタは、予め定められた単位時間（例えば、１秒）毎に、現用となる単位時間転送数カウンタが切り換わる。本ステップＦ３５において、選択したノード１００に対応する現用の単位時間転送数カウンタをカウントアップ（１加算）する。続けて、経路制御部１１０は、選択したノード１００に対応する全ての単位時間転送数カウンタのカウント値を積算する。経路制御部１１０が積算した結果の値は、即ち６０秒（６０×１秒）間の＝６０秒に転送したイベント配信メッセージ６３０の数である。そして、経路制御部１１０は、その積算した結果の値を、ノード毎イベント転送数保持部１２０に保持されているイベント転送数レコード１２１に、イベント転送数１２３として格納して、更新する。この場合、イベント転送数レコード１２１は、ステップＦ３４で選択したノード１００のノード識別子１３５を含むイベント転送数レコード１２１に、イベント転送数１２３として格納して、更新する。
【０１０７】
次に経路制御部１１０は、更新したイベント転送数１２３が一定値以上か否かを確認する（ステップＦ３６）。一定値以上である場合（ステップＦ３６でｙｅｓ）、経路制御部１１０は、ステップＦ３０で受信したイベント配信メッセージ６３０に自ノード１００のノード識別子１３５及び負荷情報１７３を付加し、該イベント配信メッセージ６３０を、ステップＦ３４または後述のステップＦ３９で選択したノード（第２のノード）１００に、後述するメッセージ転送部１９０を介して転送する（ステップＦ３７）。一定値以上でない場合（ステップＦ３６でｎｏ）、経路制御部１１０は、ステップＦ３０で受信したイベント配信メッセージ６３０を、ステップＦ３４で選択したノード１００に、後述するメッセージ転送部１９０を介して転送する（ステップＦ３８）。
【０１０８】
ステップＦ３９において、経路制御部１１０は、経路情報保持部１３０からノード１００を選択する（ステップＦ３９）（具体的な動作は、図１３のステップＦ１５と同じ）。続けて、経路制御部１１０は、ステップＦ３５からステップＦ３８までに示す処理を行う。
【０１０９】
次に、経路制御部１１０が他ノード１００からイベント配信メッセージ６３０を受信したときの動作を、図１６を参照して説明する。図１６は、この動作を示すフローチャートである。
【０１１０】
経路制御部１１０は、他ノード１００からイベント配信メッセージ６３０を受信したとき（ステップＦ４０）、受信したイベント４０１に属性４０２を取得する（ステップＦ４１）。
【０１１１】
続けて、経路制御部１１０は、経路情報保持部１３０を参照し、取得した属性４０２の属性名４０３及び属性値４０４と、経路情報レコード１３１の内のいずれかの自ノード（第１のノード）１００が管理する属性名１３３及び属性値１３４とが一致するか否かを確認する（ステップＦ４２）。一致する場合（ステップＦ４２でｙｅｓ）、経路制御部１１０は、イベント制御部１６０にステップＦ４０で受信したイベント配信メッセージ６３０を転送する（ステップＦ４３）。
【０１１２】
一致しない場合（ステップＦ４２でｎｏ）、経路制御部１１０は、その属性値４０４と一致する属性値１３４を含む、経路情報レコード１３１に含まれるノード識別子１３５を抽出して、そのノード識別子１３５に対応する他ノード（第２のノード）１００を選択する（ステップＦ４４）。
【０１１３】
次に、経路制御部１１０は、図１５のステップＦ３５からＦ３８と同様の、ステップＦ４５からＦ４８の動作を実行する。
【０１１４】
サブスクリプション制御部１４０は、サブスクリプション登録メッセージ６１０またはサブスクリプション削除メッセージ６２０を、経路制御部１１０からメッセージ転送部１９０を介して受信し、サブスクリプション保持部１５０を更新する。
【０１１５】
サブスクリプション制御部１４０が経路制御部１１０からサブスクリプション登録メッセージ６１０を受信したときの動作を、図１７を参照して説明する。図１７は、この動作を示すフローチャートである。
【０１１６】
サブスクリプション制御部１４０はサブスクリプション登録メッセージ６１０を受信したとき（Ｆ５０）、該サブスクリプション登録メッセージ６１０のサブスクリプション３０１をサブスクリプション保持部１５０に登録する（Ｆ５１）。
【０１１７】
サブスクリプション制御部１４０が、経路制御部１１０からサブスクリプション削除メッセージ６２０を受信したときの動作を、図１８を参照して説明する。図１８は、この動作を示すフローチャートである。
【０１１８】
サブスクリプション制御部１４０はサブスクリプション削除メッセージ６２０を受信したとき（Ｆ６０）、該サブスクリプション削除メッセージ６２０のサブスクリプションＩＤ３０２を持つサブスクリプション３０１を、サブスクリプション保持部１５０から削除する（Ｆ６１）。
【０１１９】
サブスクリプション保持部１５０は、サブスクリプション３０１を保持する。
【０１２０】
イベント制御部１６０は、経路制御部１１０からイベント配信メッセージ６３０を受信し、イベント４０１の一致判定を行い、サブスクリプション３０１に一致したイベント４０１を通知先３０３に基づいて、アプリケーション５００に通知する。尚、上述のイベント制御部１６０のイベント４０１を通知する部分は、イベント通知部と呼ばれることもある。
【０１２１】
また、イベント制御部１６０は、受信したイベント配信メッセージ６３０に負荷情報１７３が登録されている場合、この負荷情報１７３を他ノード負荷情報保持部１７０（後述）に格納する。
【０１２２】
他ノード負荷情報保持部１７０は、図２１に示すような他ノード負荷情報テーブル１７９を保持する。図２１は、他ノード負荷情報保持部１７０が保持する他ノード負荷情報テーブル１７９の構造を示す図である。
【０１２３】
他ノード負荷情報テーブル１７９は、図２１に示すように、ノード識別子１３５とこのノード識別子１３５で特定される他ノード（第１のノード或いは自身以外の第２のノード）１００の負荷情報１７３とをカラムとして持つノード負荷情報レコード１７１からなる。
【０１２４】
更に、イベント制御部１６０は、サブスクリプション３０１に一致したイベント４０１をアプリケーション５００に通知するときに、自ノード１００の負荷が一定値以上の場合、他ノード負荷情報保持部１７０を参照して負荷が低い他ノード１００を選択する。続けて、イベント制御部１６０は、そのイベント４０１とそのイベント４０１の通知先３０３を含むサブスクリプション３０１の集合とを含む代理通知メッセージ６５０を、選択した他ノード１００にメッセージ転送部１９０を介して送信する。尚、上述のイベント制御部１６０の代理通知メッセージ６５０を送信する部分は、代理通知要求部と呼ばれることもある。
【０１２５】
イベント制御部１６０がイベント配信メッセージ６３０を受信したときの動作を、図１９及び図２０を参照して説明する。図１９及び図２０は、この動作を示すフローチャートである。
【０１２６】
イベント制御部１６０は、経路制御部１１０からイベント配信メッセージ６３０を受信したとき（ステップＦ７０）、該イベント配信メッセージ６３０にノード識別子１３５と負荷情報１７３が付加されているか否かを確認する（ステップＦ７１）。  ノード識別子１３５と負荷情報１７３が付加されていない場合（ステップＦ７１でｎｏ）、処理は、ステップＦ７３へ進む。
【０１２７】
ノード識別子１３５と負荷情報１７３が付加されている場合（ステップＦ７１でｙｅｓ）、イベント制御部１６０は、他ノード負荷情報保持部１７０を更新する（ステップＦ７２）。具体的には、他ノード負荷情報保持部１７０において、受信したノード識別子１３５がある場合、イベント制御部１６０は、他ノード負荷情報保持部１７０における該ノードＩＤに対応する負荷情報１７３を受信した負荷情報１７３に更新する。他ノード負荷情報保持部１７０において、受信した負荷情報１７３のノード識別子１３５がない場合、イベント制御部１６０は、他ノード負荷情報保持部１７０に受信したノード識別子１３５とその負荷情報１７３を新規登録する。
【０１２８】
次に、イベント制御部１６０は、イベント４０１の一致判定を行い、イベント４０１が合致したサブスクリプション３０１の集合をリストmatched_subに格納する（ステップＦ７３）。
【０１２９】
次に、イベント制御部１６０は、イベント４０１が一致するサブスクリプション３０１が存在する（即ち、リストmatched_subが空でない）か否かを確認する（ステップＦ８０）。存在しない（即ち、リストmatched_subが空である）場合（ステップＦ８０でｎｏ）、処理は終了する。
【０１３０】
イベント４０１が一致するサブスクリプション３０１が存在する（即ち、リストmatched_subが空でない）場合（ステップＦ８０でｙｅｓ）、イベント制御部１６０は、自ノード１００の負荷が予め定められた閾値以下か否かを確認する（ステップＦ８１）。閾値以下の場合（ステップＦ８１でｙｅｓ）、イベント制御部１６０は、該イベント４０１が一致する各サブスクリプション３０１に対して（ステップＦ８Ａ及びステップＦ８Ｂ）、更にそのサブスクリプション３０１の通知先３０３に含まれる各識別子のアプリケーション５００に対して（ステップＦ８Ｃ及びステップＦ８Ｄ）、イベント４０１を通知する（ステップＦ８２）。
【０１３１】
自ノードの１００負荷が閾値より大きい場合（ステップＦ８１でｎｏ）、イベント制御部１６０は、他ノード負荷情報保持部１７０を参照してノード１００を１つ選択する（ステップＦ８３）。続けて、イベント制御部１６０は、ステップＦ７０で受信したイベント４０１とこのイベント４０１が一致するサブスクリプション３０１の集合とを含む代理通知メッセージ６５０を、選択したノード１００にメッセージ転送部１９０を介して転送する（ステップＦ８４）。
【０１３２】
ステップＦ８３において、イベント制御部１６０は、負荷が最も低いノード１００を選択するものとするが、他の基準で選択してもよい。
【０１３３】
例えば、イベント制御部１６０は、負荷情報１７３及び負荷情報１７３の取得時刻を考慮してノード１００を選択してもよい。
【０１３４】
「取得時刻を考慮」について、具体的な実現方法を以下に説明する。まず、他ノード負荷情報保持部１７０は、ノード識別子１３５と負荷情報１７３と負荷情報１７３の取得時刻との３つをカラムとして持つノード負荷情報レコード１７１からなるノード付加情報テーブル１７９を保持する。
【０１３５】
また、イベント制御部１６０は、イベント配信メッセージ６３０を受信したときに、これに負荷情報１７３が付加されている場合、他ノード負荷情報保持部１７０にノード識別子１３５と負荷情報１７３と現在時刻（取得時刻）とからなるノード付加情報レコードを格納する（ステップＦ７２に対応）。更に、イベント制御部１６０は、イベント代理通知メッセージ６５０を送信する先のノード１００を他ノード負荷情報保持部１７０から１つ選択するときに（ステップＦ８３に対応）、負荷情報１７３とその取得時刻に重みづけをした情報に基づいて、ノード１００を１つ選択する。
【０１３６】
以上により、より正確な負荷の状態を考慮して代理通知メッセージ６５０を送信するノード１００を選択することができる。
【０１３７】
代理通知要求制御部１８０は、他ノード１００からメッセージ転送部１９０を介して代理通知メッセージ６５０を受信したときに、代理通知メッセージ６５０に格納されているイベント４０１を、同じく代理通知メッセージ６５０に格納されているイベント４０１の通知先３０３に基づいてアプリケーション５００に通知する。
【０１３８】
代理通知要求制御部１８０が、他ノード１００から代理通知メッセージ６５０を受信したときの動作を、図２２を用いて説明する。図２２は、この動作を示すフローチャートである。
【０１３９】
代理通知要求制御部１８０は、他ノード１００から代理通知メッセージ６５０を受信する（ステップＦ９０）。このとき、代理通知要求制御部１８０は、この代理通知メッセージ６５０内の各サブスクリプション３０１に対して（ステップＦ９Ａ及びステップＦ９Ｂ）、更にこのサブスクリプション３０１の通知先３０３に含まれる各識別子のアプリケーション５００に対して（ステップＦ９Ｃ及びステップＦ９Ｄ）、イベント４０１を通知する（ステップＦ９１）。
【０１４０】
メッセージ転送部１９０は、イベント配信ＮＷ２００中の他ノード１００、サブスクライバ３００またはパブリッシャ４００からサブスクリプション登録メッセージ６１０、サブスクリプション削除メッセージ６２０、イベント配信メッセージ６３０または代理通知メッセージ６５０（以後、これらを総称して被転送メッセージと呼ぶ）を受信したとき、自ノード１００内の経路制御部１１０または代理通知要求制御部１８０にその被転送メッセージを転送する。また、メッセージ転送部１９０は、自ノード１００内の経路制御部１１０、イベント制御部１６０または代理通知要求制御部１８０から被転送メッセージを受信したとき、適切なノード１００にその被転送メッセージを転送する。
【０１４１】
メッセージ転送部１９０が被転送メッセージを受信したときの動作を、図２３を用いて説明する。図２３は、この動作を示すフローチャートである。
【０１４２】
メッセージ転送部１９０は、被転送メッセージを受信したときに（ステップＦ１００）、被転送メッセージの送信元が自ノード１００であるか否かを確認する（ステップＦ１００）。自ノード１００である場合（ステップＦ１０１でｙｅｓ）、メッセージ転送部１９０は、受信した被転送メッセージをその被転送メッセージに含まれる送信先に転送する（ステップＦ１０２）。
【０１４３】
被転送メッセージの送信元が他ノード１００のとき（ステップＦ１０１でｎｏ）、メッセージ転送部１９０は、受信した被転送メッセージがサブスクリプション登録メッセージ６１０、サブスクリプション削除メッセージ６２０またはイベント配信メッセージ６３０のいずれかであるか否かを確認する（ステップＦ１０３）。この被転送メッセージがこれら内のいずれかである場合（ステップＦ１０３でｙｅｓ）、メッセージ転送部１９０は、その被転送メッセージを経路制御部１１０に転送する（ステップＦ１０４）。
【０１４４】
この被転送メッセージがサブスクリプション登録メッセージ６１０、サブスクリプション削除メッセージ６２０及びイベント配信メッセージ６３０のいずれでもない場合（ステップＦ１０３でｎｏ）、メッセージ転送部１９０は、その被転送メッセージが代理通知メッセージ６５０か否かを確認する（ステップＦ１０５）。その被転送メッセージが代理通知メッセージ６５０である場合、（ステップＦ１０５でｙｅｓ）、その代理通知メッセージ６５０を代理通知要求制御部１８０に転送する。また、その被転送メッセージが代理通知メッセージ６５０でない場合、（ステップＦ１０５でｎｏ）、処理は終了する。
【０１４５】
なお、以降の説明において、メッセージ転送部１９０を介して被転送メッセージのやり取りをする場合、メッセージ転送部１９０を介することの記述を省略する場合がある。
【０１４６】
次に、具体例を用いて、本実施形態の動作を説明する。
【０１４７】
例えば、サブスクリプション３０１に含まれる属性３１２の属性名３１３は、「主体識別子」、「緯度」、「経度」の３種類とする。また、各属性値３１４の取りうる範囲は、属性名３１３「主体識別子」に対応する属性値３１４が[0, 6000]、属性名３１３に対応する属性値３１４「緯度」が[-90.0, 90.0]、属性名３１３に対応する属性値３１４「経度」が[-180.0, 180.0]とする。属性３１２が３種類のため、イベント配信ＮＷ２００は、図２４に示すように３つのＨＵＢから構成されるものとする。図２４は、イベント配信ＮＷ２００の構成の一例を示す図である。
【０１４８】
また、イベント４０１に含まれる属性４０２の属性名４０３及び属性値４０４についても、それぞれ属性名３１３及び属性値３１４と同様であるとする。同じく、経路情報レコード１３１に含まれる属性名１３３及び属性値１３４についても、それぞれ属性名３１３及び属性値３１４と同様であるとする。
【０１４９】
図２４を参照すると、例えば、「主体識別子」のＨＵＢ「HUB_ID」は、「ID-1」「ID-2」「ID-3」「ID-4」をノード識別子１３５として持つ４つのノード１００から構成されている。そして、ノード１００「ID-1」（ノード識別子１３５が「ID-1」であるノード１００を示す。以下同様）は属性値１３４[0, 1000]（0≦属性値１３４の値≦1000であることを示す。以下同様）、ノード１００「ID-2」は属性値１３４[1001, 3000]、ノード１００「ID-3」は属性値１３４[3001, 4000]及びノード１００「ID-4」は属性値１３４[4001, 6000]を管理することを示している。他のＨＵＢも同様とする。
【０１５０】
経路制御部１１０がイベント４０１を他ノード１００に転送するときに自ノード１００の負荷情報１７３を付加するか否かを判断するしきい値（図１５のステップＦ３６、図１６のステップＦ４６で使用）を「5000」とする。イベント制御部１６０が代理通知要求を行うときに使用する負荷情報１７３を自ノード１００のＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）使用率とし、代理通知を行うか否かを判断するしきい値（図２０のステップＦ８１で使用）を「70%」とする。本実施形態において、LNG-2のＣＰＵ使用率を「40%」、LNG-3のＣＰＵ使用率を「80%」とする。
【０１５１】
尚、負荷情報１７３は、イベント制御部１６０の図示しないバッファに格納されているイベント通知メッセージ６４０の数や、そのイベント通知メッセージ６４０に含まれる属性４０２「発生時刻」などであってもよい。また、経路制御部１１０は、ＣＰＵ使用率、そのバッファに格納されているイベント通知メッセージ６４０の数、そのイベント通知メッセージ６４０に含まれる属性４０２「発生時刻」の内の複数を選択し、それらに重みづけをして、負荷情報１７３を生成してもよい。
【０１５２】
図２５、図２６、図２７、図２８、図２９及び図３０は、ノード１００「ID-1」、「ID-2」、「LAT-2」、「LNG-2」、「LNG-3」及び「LNG-5」のそれぞれの各経路情報保持部１３０が保持する経路情報テーブル１３９の一例を示す図である。
【０１５３】
図３１、図３２、図３３、図３４、図３５及び図３６は、ノード１００「ID-1」、「ID-2」、「LAT-2」、「LNG-2」、「LNG-3」及び「LNG-5」のそれぞれの各ノード毎イベント転送数保持部１２０が保持するイベント転送数テーブル１２９の一例を示す図である。尚、図中の「・・・」には、何らかの値が入っているが、本実施形態の説明では使用しないため、記述を省略している。
ノード１００「LNG-2」「LNG-3」のサブスクリプション保持部１５０に「Subscription1(sub1, Event_Pattern(緯度=“-30.0”, 経度=“[-45.0, 0]”)、“app1, app2, ・・・, app1000”)」が登録されているものとする。またノード１００「LNG-2」「LNG-3」以外のノード１００のサブスクリプション保持部１５０にはサブスクリプション３０１が保持されてないものとする。尚、イベント配信ＮＷ２００内の各ノード１００のサブスクリプション保持部１５０は、任意の数のサブスクリプション３０１を登録されてよいが、以下の説明では、理解を容易にするために、登録されているサブスクリプション３０１の数を０または１としている。
【０１５４】
この状態で、ノード１００「LAT-2」がパブリッシャ４００からイベント配信メッセージ６３０「Event1(“主体識別子”“=100”, “緯度”=“-30.0”, “経度”=“-30.0”)」を受信したものとする。
【０１５５】
ノード１００「LAT-2」の経路制御部１１０がパブリッシャ４００からイベント配信メッセージ６３０「event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”)」を受信したとき、これに含まれるイベント４０１に含まれる属性名４０３「主体識別子」、「緯度」及び「経度」とその属性値４０４とを管理するノード１００に、イベント４０１を転送する。
【０１５６】
まずノード１００「LAT-2」の経路制御部１１０における、属性名１３３「主体識別子」に対するイベント処理を、具体的に説明する。
【０１５７】
経路制御部１１０は、属性名４０３「主体識別子」と、経路情報保持部１３０を参照して得た自ノード１００が管理する属性名１３３「緯度」とは同じ値でないため（図１５のステップＦ３１でｎｏ）、この属性名４０３「主体識別子」を管理するノード１００「ID-2」を経路情報保持部１３０から選択する（図１５のステップＦ３４）。
【０１５８】
次に、経路制御部１１０は、ノード毎イベント転送数保持部１２０のノード１００「ID-2」に対応するイベント転送数１２３「3000」を「3001」に更新する（図１５のステップＦ３６）。更新した値はしきい値「5000」より小さいため（図１５のステップＦ３６でｎｏ）、経路制御部１１０は、このイベント配信メッセージ６３０をノード１００「ID-2」に転送する（図１５のステップＦ３８）。
【０１５９】
次に、ノード１００「ID-2」の経路制御部１１０は、ノード１００「LAT-2」からイベント配信メッセージ６３０「event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”)」を受信したとき（図１６のステップＦ４０）、イベント配信メッセージ６３０に含まれるイベント４０１から自ノード１００が管理する属性名１３３「主体識別子」に対応する属性値４０４「100」を取得する（図１６のステップＦ４１）。続けて、ノード１００「ID2」の経路制御部１１０は、この属性値４０４「100」と自ノード１００が管理する属性値１３４[1001, 3000]とは一致しないため（図１６のステップＦ４２でｎｏ）、経路情報保持部１３０からノード１００「ID-1」を選択する（図１６のステップＦ４４）。
【０１６０】
次に、ノード１００「ID2」の経路制御部１１０は、ノード毎イベント転送数保持部１２０のノード１００「ID-1」に対応するイベント転送数１２３「3000」を「3001」に更新する（図１６のステップＦ４５）。更新した値はしきい値「5000」より小さいため（ステップＦ４６でｎｏ）、経路制御部１１０は、該イベント４０１を含むイベント配信メッセージ６３０をノード１００「ID1」に転送する（図１６のステップＦ４８）。
【０１６１】
次に、ノード１００「ID1」の経路制御部１１０は、ノード１００「ID-2」からイベント配信メッセージ６３０「event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”)」を受信したとき（図１６のステップＦ４０）、イベント配信メッセージ６３０内のイベント４０１から自ノード１００が管理する属性名１３３「主体識別子」に対応する属性値４０４「100」を取得する（図１６のステップＦ４１）。続けて、ノード１００「ID1」の経路制御部１１０は、この属性値４０４「100」と自ノード１００が管理する属性値１３４[0, 1000]とが一致するため（図１６のステップＦ４１でｙｅｓ）、イベント制御部１６０に受信したイベント４０１を転送する（図１６のステップＦ４３）。
【０１６２】
次に、ノード１００「ID-1」のイベント制御部１６０は、イベント配信メッセージ６３０「event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”)」を受信する（図１９のステップＦ７０）。このとき、ノード１００「ID-1」のイベント制御部１６０は、受信したイベント配信メッセージ６３０に負荷情報１７３が付加されていないので（図１９のステップＦ７１でｎｏ）、このイベント配信メッセージ６３０内のイベント４０１の一致判定を行う（図１９のステップＦ７３）。ノード１００「ID-1」のサブスクリプション保持部１５０にサブスクリプション３０１は保持されていないため、イベント４０１が一致するサブスクリプション３０１は存在せず（図２０のステップＦ８０でｎｏ）、動作を終了する。
【０１６３】
次にノード１００「LAT-2」の経路制御部１１０における、属性名１３３「緯度」に対するイベント処理を説明する。
【０１６４】
属性名４０３「緯度」及びその値４０４「-30.0」と、自ノード１００が管理する属性名１３３及び属性値１３４とが一致するため（図１５のステップＦ３１でｙｅｓ、ステップＦ３２でｙｅｓ）、経路制御部１１０は、該イベント配信メッセージ６３０をイベント制御部１６０に転送する（図１５のステップＦ３３）。
【０１６５】
ノード１００「LAT-2」のイベント制御部１６０は、イベント配信メッセージ６３０を受信する（図１９のステップＦ７０）。このとき、ノード１００「LAT-2」のイベント制御部１６０は、受信したイベント配信メッセージ６３０に負荷情報１７３が付加されていないので（図１９のステップＦ７１でｎｏ）、このイベント配信メッセージ６３０内のイベント４０１の一致判定を行う（図１９のステップＦ７３）。ノード１００「LAT-2」のサブスクリプション保持部１５０にサブスクリプション３０１は保持されていないため、該イベント４０１が一致するサブスクリプション３０１は存在せず（図２０のステップＦ８０でｎｏ）、動作を終了する。
【０１６６】
最後にノード１００「LAT-2」の経路制御部１１０における、属性名１３３「経度」に対するイベント処理を説明する。
【０１６７】
属性名４０３「経度」と、自ノード１００が管理する属性名１３３とが一致しないため（図１５のステップＦ３１でｎｏ）、経路制御部１１０は、この属性名４０３「経度」を管理するノード１００「LNG-5」を経路情報保持部１３０から選択する（図１５のステップＦ３４)。
【０１６８】
次に、経路制御部１１０は、ノード毎イベント転送数保持部１２０のノード１００「LNG-5」に対応するイベント転送数１２３「4500」を「4501」に更新する（図１５のステップＦ３６）。更新した値はしきい値「5000」より小さいため（図１５のステップＦ３６でｎｏ）、経路制御部１１０は、このイベント配信メッセージ６３０をノード１００「LNG-2」に転送する（図１５のステップＦ３８）。
【０１６９】
次に、ノード１００「LNG-5」の経路制御部１１０は、ノード１００「LAT-2」からイベント配信メッセージ６３０「event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”)」を受信したとき（図１６のステップＦ４０）、イベント配信メッセージ６３０に含まれるイベント４０１から自ノード１００が管理する属性名１３３「主体識別子」に対応する属性値４０４「-30.0」を取得する（図１６のステップＦ４１）。続けて、ノード１００「LNG-5」の経路制御部１１０は、この属性名４０４「-30.0」と自ノード１００が管理する属性値１３４「100.0,180.0」とが一致しないため（図１６のステップＦ４２でｎｏ）、経路情報保持部１３０からノード１００「LNG-2」を選択する（ステップＦ４４）。
【０１７０】
次に、経路制御部１１０は、ノード毎イベント転送数保持部１２０のノード１００「LNG-2」に対応するイベント転送数１２３「2000」を「2001」に更新する（図１６のステップＦ４５）。更新した値はしきい値「5000」より小さいため（図１６のステップＦ４６でｎｏ）、経路制御部１１０は、このイベント配信メッセージ６３０をノード１００「LNG-2」に転送する（図１６のステップＦ４８）。
【０１７１】
次に、ノード１００「LNG-2」の経路制御部１１０は、ノード１００「LNG-5」からイベント配信メッセージ６３０「event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”)」を受信したとき（図１６のステップＦ４０）、イベント配信メッセージ６３０内のイベント４０１から自ノード１００が管理する属性名１３３「経度」に対応する属性値４０４「-30.0」を取得する（図１６のステップＦ４１）。続けて、ノード１００「LNG-2」の経路制御部１１０は、この属性値４０４「-30.0」と自ノード１００が管理する属性値１３４「[-110.0,-40.0]」に含まれる値とが一致しないため（図１６のステップＦ４２でｎｏ）、経路情報保持部１３０からノード１００「LNG-3」を選択する（図１６のステップＦ４４）。
【０１７２】
次に、ノード１００「LNG-2」の経路制御部１１０は、ノード毎イベント転送数保持部１２０のノード１００「LNG-3」に対応するイベント転送数１２３「5200」を「5201」に更新する（図１６のステップＦ４５）。更新した値はしきい値「5000」以上であるため（図１６のステップＦ４６でｙｅｓ）、経路制御部１１０は、該イベント４０１と負荷情報１７３とを含むイベント配信メッセージ６３０「(event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”), LNG-2, 40%)」を、ノード１００「LNG-3」に転送する（図１６のステップＦ４７）。
【０１７３】
次に、ノード１００「LNG-3」の経路制御部１１０は、ノード１００「LNG-2」からイベント配信メッセージ６３０「(event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”), LNG-2, 40%)」を受信する（ステップＦ４０）。このとき、ノード１００「LNG-3」の経路制御部１１０は、イベント４０１「event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”)」から自ノード１００が管理する属性名１３３「主体識別子」に対応する属性値４０４「-30.0」を取得する（図１６のステップＦ４１）。続けて、ノード１００「LNG-3」の経路制御部１１０は、この属性値４０４「-30.0」と自ノード１００が管理する属性値１３４[-40.0,30.0]とが一致するため（図１６のステップＦ４２でｙｅｓ）、該イベント配信メッセージ６３０をイベント制御部１６０に転送する（図１６のステップＦ４３）。
【０１７４】
次に、ノード１００「LNG-3」のイベント制御部１６０は、該イベント配信メッセージ６３０「(event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”), LNG-2, 40%)」を受信する（図１９のステップＦ７０）。このとき、ノード１００「LNG-3」のイベント制御部１６０は、受信したイベント配信メッセージ６３０に負荷情報１７３「(LNG-2, 40%)」が付加されているため（図１９のF７１でｙｅｓ）、他ノード負荷情報保持部１７０のノード識別子１３５「LNG-2」に対応する負荷情報１７３を「４０％」に更新し（図１９のステップＦ７２）、イベント４０１の一致判定を行い、一致したサブスクリプション３０１「Subscription1(sub1, Event_Pattern(“緯度”=“-30.0”, “経度”＝“-45.0, 0]”、“app1, app2, ・・・, app1000”)」をリストmatched_subに格納する。（図１９のステップＦ７３）。
【０１７５】
次に、ノード１００「LNG-3」のイベント制御部１６０は、リストmatched_subが空でなく（図２０のステップＦ８０でｙｅｓ）、ノード１００「LNG-3」の負荷「80%」はしきい値「70%」より高いため（図２０のステップＦ８１でｎｏ）、他ノード負荷情報保持部１７０を参照してノード１００を１つ選択する（図２０のステップＦ８３）。ここでは、ノード１００「LNG-2」を選択したとする。
【０１７６】
次に、イベント制御部１６０は、ノード１００「LNG-2」に代理通知メッセージ６５０「event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”), Subscription1(sub1, Event_Pattern(“緯度”=“-30.0”, “経度”＝“[-45.0, 0]”), “app1, app2, ・・・, app1000”」を送信する（図２０のステップＦ８４）。
【０１７７】
次に、ノード１００「LNG-2」の代理通知要求制御部１８０は、ノード１００「LNG-3」から代理通知メッセージ６５０を受信したとき（図２２のステップＦ９０）、代理通知メッセージ６５０内の各サブスクリプション３０１に含まれる、各通知先３０３に含まれる各識別子のアプリケーション５００に対して、受信した代理通知メッセージ６５０に含まれる、イベント４０１を含むイベント通知メッセージ６４０を送信する（図２２のステップＦ９１）。本具体例では、通知先３０３「app1, app2,・・・, app1000」にイベント４０１「event1(“主体識別子”＝“100”, “緯度”=“-30.0”, “経度”=“-30.0”)」を通知する。
【０１７８】
上述した本実施形態における第１の効果は、通知先３０３が多いイベント４０１の大量発生などに起因する、イベント配信（通知）の遅滞を防止することを可能にできる点である。
【０１７９】
その理由は、イベント制御部１６０が、自ノード１００の負荷が閾値より大きい場合に、他ノード負荷情報保持部１７０を参照して選択したノード１００に代理通知メッセージ６５０を送信するようにしたからである。
【０１８０】
上述した本実施形態における第２の効果は、他ノード負荷情報保持部１７０の内容を効率よく更新することを可能にできる点である。
【０１８１】
その理由は、経路制御部１１０が、ノード毎イベント転送数保持部１２０の内容を参照して、イベント配信メッセージ６３０の転送数の多いノード１００に対して、自ノード１００の負荷情報１７３を送信するようにしたからである。
【０１８２】
［第２の実施形態］
次に、本発明の第２の実施形態について図面を参照して詳細に説明する。以下、本実施形態の説明が不明確にならない範囲で、前述の説明と重複する内容については省略する。
【０１８３】
第１の実施形態において、経路制御部１１０は、イベント４０１を他ノード１００（ノードｂとする）に転送するときに、ノードｂへのイベント転送数１２３が閾値以上の場合、イベント４０１に自ノード１００(ノードａとする）の負荷情報１７３を付加する。従って、ノードａの負荷がイベント配信ＮＷ２００中の他のノード１００と比べて高い場合、負荷の低いノード１００があるにもかかわらず、負荷の高いノード１００がイベント代理通知メッセージ６５０の処理を行うことになる。この課題を解決するために、本実施形態は、経路制御部７１０は、他ノード７００に転送するイベント４０１に負荷情報１７３を付加するときに、自ノード７００が保持する複数の負荷情報１７３を参照して相対的に負荷が低いノード７００を選択し、イベント４０１に選択したノード７００の負荷情報１７３を付加する。
【０１８４】
図３７は、本実施形態に係るノード７００の構造を示すブロック図である。第１の実施形態と比べて、本実施形態の異なる点は、経路制御部７１０が他ノード負荷情報保持部１７０を参照する点である。
【０１８５】
ノード７００の経路制御部１１０及びノード毎イベント転送数保持部１２０を含む部分は、第１のノードと呼ばれることもある。ノード７００のノードイベント制御部１６０及び他ノード負荷情報保持部１７０を含む部分は、第２のノードと呼ばれる場合もある。ノード７００の第１のノードの部分とイベント制御部１６０と他ノード負荷情報保持部１７０とを更に含む部分、第２のノードの部分、または、第２のノードの部分と経路制御部１１０とノード毎イベント転送数保持部１２０とを更に含む部分は、第１のノードあるいは第２のノードと呼ばれることもある。従って、ノード７００は、第１のノードまたは第２のノードのいずれかとして固定されてもよいし、動作状態によって第１のノード及び第２のノードのいずれかとなってもよい。
【０１８６】
第１の実施形態１において、ノード（第１のノード）１００の経路制御部１１０は、イベント４０１を他ノード（第２のノード）７００に転送するときに、この他ノード７００へのイベント転送数１２３が閾値以上の場合、イベント配信メッセージ６３０に自ノード７００のノード識別子１３５と負荷情報１７３とを付加する。本実施形態において、ノード（第１のノード）７００の経路制御部７１０は、イベント４０１を他ノード（第２のノード）７００に転送するときに、この他ノード７００へのイベント転送数１２３が閾値以上の場合、他ノード負荷情報保持部１７０と自ノード７００の負荷情報１７３とを参照し、負荷が最も低いノード７００を選択し、イベント配信メッセージ６３０に選択したノード７００のノード識別子１３５とその負荷情報１７３とを付加する。
【０１８７】
次に、本実施形態の動作について図面を参照して詳細に説明する。以下の説明においても、第１の実施形態と異なる動作について説明する。
【０１８８】
本実施形態において、経路制御部７１０がパブリッシャ４００からイベント配信メッセージ６３０を受信したときの動作は、第１の実施形態の動作を示す図１５のステップＦ３７を図３８のステップＦ１１１及びＦ１１２に置き換えられた動作となる。図３８は、この置き換えられた部分の動作を示すフローチャートである。尚、図１５を本実施形態の動作のフローチャートとして参照する場合、フローチャート中のノード１００は、ノード７００を示す。
【０１８９】
経路制御部７１０は、他ノード負荷情報保持部１７０と自ノード７００の負荷情報１７３とを参照し、負荷が最も低いノード（第２のノード）７００を選択する（ステップＦ１１１)。
【０１９０】
次に、経路制御部７１０は、イベント４０１とステップＦ１１１で選択したノード７００のノード識別子１３５及び負荷情報１７３とを含むイベント配信メッセージ６３０を、図１５のステップＦ３４またはステップＦ３９で選択したノード（第２のノード）７００に転送する（ステップＦ１１２)。
【０１９１】
経路制御部７１０が他ノード７００からイベント配信メッセージ６３０を受信したときのステップＦ４７における動作も同様であるため、説明を省略する。
【０１９２】
尚、経路制御部７１０は、上述の例では負荷が最も低いノード７００を１つ選択しているが、負荷が低い順に複数のノード７００を選択し、イベント４０１と選択した複数のノード７００それぞれのノード識別子１３５及びその負荷情報１７３とをイベント配信メッセージ６３０に含めてもよい。
【０１９３】
上述した本実施形態における効果は、第１の実施形態の効果に加えて、より負荷の低いノード７００にイベント代理通知要求を行うことを可能にできる点である。
【０１９４】
その理由は、経路制御部７１０が、イベント配信メッセージ６３０に付加するノード識別子１３５及びその負荷情報１７３を、自ノード７００が保持する負荷情報１７３（自ノード７００の負荷情報１７３及び他ノード負荷情報保持部１７０が保持している負荷情報１７３）の内の相対的に負荷の低いノード７００を選択し、選択したノード７００のノード識別子１３５及びその負荷情報１７３とをイベント配信メッセージ６３０に付加するようにしたからである。
【０１９５】
［第３の実施形態］
次に、本発明の第３の実施形態について図面を参照して詳細に説明する。以下、本実施形態の説明が不明確にならない範囲で、前述の説明と重複する内容については省略する。
【０１９６】
ノード８００の経路制御部１１０及びノード毎イベント転送数保持部１２０を含む部分は、第１のノードと呼ばれることもある。ノード８００のノードイベント制御部１６０及び他ノード負荷情報保持部１７０を含む部分は、第２のノードと呼ばれる場合もある。ノード８００の第１のノードの部分とイベント制御部１６０と他ノード負荷情報保持部１７０とを更に含む部分、第２のノードの部分、または、第２のノードの部分と経路制御部１１０とノード毎イベント転送数保持部１２０とを更に含む部分は、第１のノード或いは第２のノードと呼ばれることもある。従って、ノード８００は、第１のノードまたは第２のノードのいずれかとして固定されてもよいし、動作状態によって第１のノード及び第２のノードのいずれかとなってもよい。
【０１９７】
第1の実施形態において、イベント制御部１６０は、イベント４０１を通知するときに自ノード（第２のノード）１００の負荷が閾値より大きい場合、他ノード（第１のノード）１００に代理通知メッセージ６５０を送信する。従って、イベント４０１の通知先数（各通知先３０３に含まれる識別子の数の合計）が多い場合、代理通知メッセージ６５０を処理する他ノード１００の負荷が高くなる。この課題を解決するために、本実施形態において、イベント制御部１６０は、自ノード８００の負荷に応じて一部のイベント通知を自ノード８００で行い、残りのイベント通知を他ノード８００に依頼する。
【０１９８】
図３９は、本実施形態の構成を示すブロック図である。図３９を参照すると、本実施形態におけるノード８００の構成は、実施形態１におけるノード１００の構成に、代理通知条件保持部８９０を追加された構成である。
【０１９９】
図４０は、代理通知条件保持部８９０が保持する代理通知条件テーブル８９９の一例を示す図である。代理通知条件テーブル８９９は、図４０に示すように、負荷範囲情報８９２と、負荷情報１７３がその負荷範囲情報８９２に含まれる値のときに自ノード８００で通知するイベント通知数８９３と、をカラムとして持つ代理通知条件レコード８９１のからなる。
【０２００】
代理通知条件保持部８９０に格納される情報は、ノード８００の管理者或いはノード８００の外部の装置やシステムなどから、図示しない手段によって登録される。
【０２０１】
次に、本実施形態の動作について図面を参照して詳細に説明する。以下の説明においても、第１の実施形態と異なる動作について説明する。図４１は、イベント制御部１６０がイベント配信メッセージ６３０を受信したときの動作を示すフローチャートである。
【０２０２】
イベント制御部１６０は、イベント４０１が合致するサブスクリプション３０１が１つ以上あるとき（ステップＦ１２１でｙｅｓ）、代理通知条件保持部８９０から自ノード８００の負荷範囲情報８９２に対応するイベント通知数８９３を取得し、通知するイベント数を格納する変数notify_numに格納する（ステップＦ１２２）。
【０２０３】
次にイベント制御部１６０は、自ノード８００がアプリケーション５００に通知したイベント数を格納する変数notified_num を０にする（ステップＦ１２３）。
【０２０４】
次に、イベント制御部１６０は、matched_subの各サブスクリプション３０１に対して、ステップＦ１２４〜ステップＦ１２Ｂの処理を行う。
【０２０５】
まずイベント制御部１６０は、notified_numに該サブスクリプション３０１の通知先数を加える（ステップＦ１２４）。
【０２０６】
次に、イベント制御部１６０は、notified_numとnotify_numとを比較する（ステップＦ１２５）。
【０２０７】
notified_numがnotify_num以下の場合、即ち、このサブスクリプション３０１の通知先３０３に自ノード８００がイベント４０１通知を行っても、自ノード８００のnotify_numを超えない場合、（ステップＦ１２５でｙｅｓ）、イベント制御部１６０は、このサブスクリプション３０１の通知先３０３に対して（ステップＦ１２Ａ及びＦ１２Ｂ）イベント４０１を通知する（ステップＦ１２６）。
【０２０８】
次に、イベント制御部１６０は、matched_numからこのサブスクリプション３０１を削除する（ステップＦ１２７）。
【０２０９】
次に処理は、ステップＦ１２４へ戻る。
【０２１０】
notified_numがnotify_numより大きい時（ステップＦ１２５でｎｏ）、イベント制御部１６０は、他ノード負荷情報保持部１７０を参照してノード８００を１つ選択する（選択方法は実施形態１と同じ）（ステップＦ１２８）。
【０２１１】
次に、イベント制御部１６０は、選択したノード８００にイベント４０１とmatched_numに格納されているサブスクリプション３０１の集合とを含む代理通知メッセージ６５０を送信する（ステップＦ１２９）。
【０２１２】
具体例を用いて説明する。
【０２１３】
ノード８００「LNG-3」のＣＰＵ使用率が７５％とする。また、ノード８００「LNG-3」のイベント制御部１６０がイベント配信メッセージ６３０「event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”), LNG-2, 40%」に対する合致判定を行い、matched_subに「 (sub1, Event_Pattern(“緯度”=“-30.0”, “経度”＝“[-45.0, 0]”)、“app1, app2, ・・・, app1000”), (sub2, Event_Pattern(“緯度”=“-30.0”, “経度”＝“[-45.0, 0]”)、“app1001, app1002, ・・・, app2000”」が格納されるとする（図１９のステップＦ７３）。尚、通知先３０３「“app1, app2, ・・・, app1000”」及び通知先３０３「“app1001, app1002, ・・・, app2000”」は、それぞれ、app1からapp1000までの１０００個の識別子を及びapp1001からapp2000までの１０００個の識別子を、含むことを示している。
【０２１４】
このとき、図４１のフローチャートにおいて、イベント制御部１６０は次のように動作する。
【０２１５】
matched_subが空ではないので（ステップＦ１２１でｙｅｓ）、イベント制御部１６０は、代理通知条件保持部８９０から自ノード８００のＣＰＵ使用率「75%」に対応するイベント通知数８９３「1000」を取得し、これをnotify_numに格納し（ステップＦ１２２）、notified_numに「0」を格納する（ステップＦ１２３）。
【０２１６】
次に、イベント制御部１６０はmatched_subの各サブスクリプション３０１に対して以下の処理を行う。
【０２１７】
まず、イベント制御部１６０はmatched_subの１つ目のサブスクリプション３０１「sub1, EventPattern(“緯度”=“-30.0”, “経度”＝“[-45.0, 0]”)、通知先“app1, app2, ・・・, app1000”」に基づいて、notified_numに該サブスクリプション３０１の通知先数「1000」を加える（notified_num=1000になる）（ステップＦ１２４）。
【０２１８】
次に、イベント制御部１６０はnotified_num≦notify_numなので(ステップＦ１２５でｙｅｓ)、該サブスクリプション３０１の通知先３０３の各識別子app1,・・・,app1000で指定されるアプリケーション５００に、このイベント配信メッセージ６３０中のイベント４０１「event1(“主体識別子”=“100”, “緯度”=“-30.0”, “経度”=“-30.0”)」を通知する（ステップＦ１２６）。
【０２１９】
次に、イベント制御部１６０は、matched_numからこのサブスクリプション３０１を削除する（matched_sub = (sub2, Event_Pattern(“緯度”=“-30.0”, “経度”＝“[-45.0, 0]”)、通知先“app1001, app1002, ・・・, app2000”)となる）（ステップＦ１２７）。
【０２２０】
次に、イベント制御部１６０は、matched_subの１つ目のサブスクリプション３０１「sub2, Event_Pattern(“緯度”=“-30.0”, “経度”＝“[-45.0, 0]”)、“app1001, app1002, ・・・, app2000”」に基づいて、notified_numにこのサブスクリプション３０１の通知先数「1000」を加える（notified_num=2000になる）（ステップＦ１２４）。
【０２２１】
次に、イベント制御部１６０は、notified_num＞notify_numなので(ステップＦ１２５でｎｏ)、他ノード負荷情報保持部１７０からノード８００を１つ選択する(ステップＦ１２８)
次に、イベント制御部１６０は、このイベント４０１とmatched_numとを含む代理通知メッセージ６５０「event1(“主体識別子”＝100”, “緯度”=-30.0”, “経度”=-30.0”), Subscription2 (sub2, Event_Pattern(“緯度”=“-30.0”, “経度”＝“[-45.0, 0]”)、“app1001, app1002, ・・・, app2000”」を、選択したノード８００へ転送する（ステップＦ１２９）。
【０２２２】
上述した本実施形態における効果は、第１の実施形態の効果に加えて、イベント４０１が発生してからアプリケーション５００に通知されるまでの時間をより短くすることが可能になる点である。なる。
【０２２３】
その理由は、イベント制御部１６０が、自ノード８００の負荷情報１７３に応じて、可能な範囲で一部の通知先３０３にイベント通知を行い、残りのイベント通知については他ノード８００に代理通知を要求するようにしたためである。即ち、結果的にイベント通知を行うノード８００が増えることにより、イベント通知の処理が複数のノード８００に分散できるということである。
【０２２４】
［第４の実施の形態］
次に、本発明の第４の実施形態について図面を参照して詳細に説明する。本実施形態は、本発明の基本的な要素からのみなる実施形態である。以下、本実施形態の説明が不明確にならない範囲で、前述の説明と重複する内容については省略する。
【０２２５】
図４２は、本発明の第４の実施形態の構成を示すブロック図である。図４２を参照すると、本発明の第４の実施形態は、図示しないネットワークで相互に接続された、第１のノード９１０と第２のノード９２０とを含む。
【０２２６】
ノード９１０は、第１のノードと呼ばれることもある。ノード９２０は、第２のノードと呼ばれる場合もある。
【０２２７】
第１のノード９１０は、経路制御部１１０と転送数保持部１２０と代理通知要求制御部１８０とを含む。
【０２２８】
経路制御部１１０は、イベント配信メッセージ６３０を受信し、受信したイベント配信メッセージ６３０を第２のノード９２０へ転送する。
【０２２９】
ノード毎イベント転送数保持部１２０は、イベント配信メッセージ６３０の転送数を第２のノード９２０毎に保持する。
【０２３０】
経路制御部１１０は、前記転送数が予め定められた閾値以上の前記転送先へ前記イベント配信メッセージ６３０を転送する場合に、このイベント配信メッセージ６３０に第１のノード自身の識別子１３５及びその負荷情報１７３を付加して転送する。
【０２３１】
代理通知要求制御部１８０は、代理通知メッセージ６５０を受信し、この受信した代理通知メッセージ６５０に基いてイベント通知メッセージ６４０を送信する。
【０２３２】
第２のノード９２０は、他ノード負荷情報保持部１７０とイベント制御部１６０とを含む。
【０２３３】
他ノード負荷情報保持部１７０は、第１のノード９１０の識別子１３５と対応する負荷情報１７３との組を１つ以上保持する。
【０２３４】
イベント制御部１６０は、イベント配信メッセージ６３０を受信し、この受信したイベント配信メッセージ６３０に基づいてイベント通知メッセージ６４０を送信する。また、イベント制御部１６０は、第２のノード９２０自身の負荷情報１７３と予め定められた閾値との比較結果に基づいて、他ノード負荷情報保持部１７０の内容に基づいて決定した第１のノードへ、イベント配信メッセージ６３０に含まれるイベント４０１の代理通知を要求する代理通知メッセージ６５０を送信する。
【０２３５】
上述した、経路制御部１１０がこのイベント配信メッセージ６３０に付加する第１のノードの識別子１３５及びその負荷情報１７３は、即ち、イベント制御部１６０が代理通知を要求する第１のノード９１０を決定するための情報である。
【０２３６】
上述した本実施形態における第１の効果は、通知先が多いイベント４０１の大量発生などに起因する、イベント配信（通知）の遅滞を防止することを可能にできる点である。
【０２３７】
その理由は、イベント制御部１６０が、自ノード９２０の負荷が閾値より大きい場合に、他ノード負荷情報保持部１７０を参照して選択したノード９１０に代理通知メッセージ６５０を送信するようにしたからである。
【０２３８】
上述した本実施形態における第２の効果は、他ノード負荷情報保持部１７０の内容を効率よく更新することを可能にできる点である。
【０２３９】
その理由は、経路制御部１１０が、ノード毎イベント転送数保持部１２０の内容を参照して、大きな値のイベント転送数１２３に対応するノード識別子１３５の、ノード９２０に対して、自ノード９１０の負荷情報１７３を送信するようにしたからである。
【０２４０】
上述した各実施形態のノード１００、６００、７００、９１０及び９２０は、コンピュータ装置によって構成されてもよい。この場合、コンピュータ装置は、制御プログラムを記憶する記憶媒体と、制御プログラムを実行するＣＰＵ（中央処理装置）とを含んで構成されてもよい。
【０２４１】
以上の各実施形態で説明した各構成要素は、必ずしも個々に独立した存在である必要はない。例えば、各構成要素は、複数の構成要素が１個のモジュールとして実現されたり、一つの構成要素が複数のモジュールで実現されたりしてもよい。また、各構成要素は、ある構成要素が他の構成要素の一部であったり、ある構成要素の一部と他の構成要素の一部とが重複していたり、といったような構成であってもよい。
【０２４２】
また、以上説明した各実施形態では、複数の動作をフローチャートの形式で順番に記載してあるが、その記載の順番は複数の動作を実行する順番を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の順番は内容的に支障しない範囲で変更することができる。
【０２４３】
更に、以上説明した各実施形態では、複数の動作は個々に相違するタイミングで実行されることに限定されない。例えば、ある動作の実行中に他の動作が発生したり、ある動作と他の動作との実行タイミングが部分的に乃至全部において重複していたりしていてもよい。
【０２４４】
更に、以上説明した各実施形態では、ある動作が他の動作の契機になるように記載しているが、その記載はある動作と他の動作の全ての関係を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の関係は内容的に支障のない範囲で変更することができる。また各構成要素の各動作の具体的な記載は、各構成要素の各動作を限定するものではない。このため、各構成要素の具体的な各動作は、各実施形態を実施する上で機能的、性能的、その他の特性に対して支障をきたさない範囲内で変更されて良い。
【０２４５】
なお、以上説明した各実施形態における各構成要素は、必要に応じ可能であれば、ハードウェアで実現されても良いし、ソフトウェアで実現されても良いし、ハードウェアとソフトウェアの混在により実現されても良い。
【０２４６】
また、各構成要素の物理的な構成は、以上の実施形態の記載に限定されることはなく、独立して存在しても良いし、組み合わされて存在しても良いしまたは分離して構成されても良い。
【０２４７】
上記の実施形態の一部または全部は、以下の付記のようにも記載されうるが、以下には限られない。
【０２４８】
（付記１）
ネットワークで相互に接続された、少なくとも１つの第１のノードと少なくとも１つの第２のノードとを含み、
前記第１のノードは、イベント配信を受信し、受信した前記イベント配信を前記第２のノードへ転送する経路制御部と、
代理通知要求を受信し、受信した前記代理通知要求に基づいてイベント通知を送信するイベント通知部と、
前記イベント配信の一定時間毎の転送数を前記第２のノード毎に保持するノード毎イベント転送数保持部と、を含み、
前記経路制御部は、前記転送数に基づいて、転送する前記イベント配信に前記第１のノード自身の識別子及び対応する負荷情報を付加し、
前記第２のノードは、前記第１のノードの識別子及び対応する負荷情報の組を１つ以上保持する他ノード負荷情報保持部と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、当該第２のノード自身の負荷情報に基づいて、前記他ノード負荷情報保持部の内容に基づいて決定した前記第１のノードへ前記イベントの前記代理通知要求を送信するイベント制御部と、を含む、
ことを特徴とするイベント配信システム。
【０２４９】
（付記２）
前記第１のノードは、前記他ノード負荷情報保持部を更に含み、
前記経路制御部は、当該経路制御部に対応する前記第１のノードの前記負荷情報と前記他ノード負荷情報保持部の保持する前記負荷情報との内の、相対的に低い前記負荷情報を有する前記第１のノードの内の１以上を選択し、選択した前記第１のノードの前記識別子及び前記負荷情報を前記転送数に基づいて前記イベント配信に付加する
ことを特徴とする付記１記載のイベント配信システム。
【０２５０】
（付記３）
前記第２のノードは、前記経路制御部と前記ノード毎イベント転送数保持部とを更に含むことを特徴とする付記１または２記載のイベント配信システム。
【０２５１】
（付記４）
前記第２のノードは、負荷範囲情報とイベント通知数とを保持する代理通知条件保持部を更に含み、
前記イベント通知部は、前記第２のノード自身の前記負荷情報と前記代理通知条件保持部に保持されている前記負荷範囲情報及び前記イベント通知数とに基づいて、前記イベントそれぞれについて、前記イベント通知を送信するか否かを判定し、
前記代理通知要求部は、前記第２のノード自身の前記負荷情報と前記代理通知条件保持部に保持されている前記負荷範囲情報及び前記イベント通知数とに基づいて、前記イベントそれぞれについて、代理通知を要求するか否かを判定する、
ことを特徴とする付記１乃至３のいずれかに記載のイベント配信システム。
【０２５２】
（付記５）
前記経路制御部は、前記負荷情報を、ＣＰＵ使用率、保留しているイベント通知メッセージ数、及び前記イベント通知メッセージに含まれる内の前記イベントの内容の任意の組合せに基づいて生成ことを特徴とする、
付記１乃至４のいずれかに記載のイベント配信システム。
【０２５３】
（付記６）
前記第１のノードは、属性名と属性値とノード識別子とを含む経路情報レコード保持する経路制御情報保持部を更に含む
ことを特徴とする付記１乃至５のいずれかに記載のイベント配信システム。
【０２５４】
（付記７）
サブスクリプションを保持するサブスクリプション保持部と、
前記サブスクリプション保持部に対して前記サブスクリプションの登録・削除を行うサブスクリプション制御部と、を更に含むことを特徴とする、付記１乃至６記載のイベント配信システム。
【０２５５】
（付記８）
前記代理通知要求を受信し、受信した前記代理通知要求に基づいて、前記イベント通知を送信する代理通知要求制御部を更に含むことを特徴とする、
付記１乃至７のいずれかに記載のイベント配信システム。
【０２５６】
（付記９）
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送する経路制御部と、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部と
前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するイベント制御部と、を含み、
前記経路制御部は、前記転送数に基づいて、転送する前記イベント配信に自身に対応する前記識別子及び対応する前記負荷情報を付加する
ことを特徴とするイベント配信装置。
【０２５７】
（付記１０）
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送する経路制御部と、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部と
前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するイベント制御部と、を含み、
前記経路制御部は、前記転送数に基づいて、前記イベント配信に前記自身に対応する前記負荷情報及び前記他ノード負荷情報保持部の保持する前記負荷情報の内の相対的に低い前記負荷情報を有する前記自身に対応する前記イベント配信装置及び前記他イベント配信装置の内の１以上を選択し、選択した自身に対応する前記イベント配信装置及び前記他イベント配信装置の前記識別子及び対応する前記負荷情報を付加する
ことを特徴とするイベント配信装置。
【０２５８】
（付記１１）
負荷範囲情報とイベント通知数とを保持する代理通知条件保持部を更に含み、
前記イベント制御部は、前記自身の前記負荷情報と前記代理通知条件保持部に保持されている前記負荷範囲情報及び前記イベント通知数とに基づいて、前記イベントそれぞれについて、前記イベント通知の対象または前記代理通知を要求の対象のいずれにするかを判定することを特徴とする、
付記９または１０記載のイベント配信装置。
【０２５９】
（付記１２）
前記経路制御部は、前記負荷情報を、ＣＰＵ使用率、保留しているイベント通知メッセージ数、及び前記イベント通知メッセージに含まれる内の前記イベントの内容の任意の組合せに基づいて生成ことを特徴とする、
付記９乃至１１のいずれかに記載のイベント配信装置。
【０２６０】
（付記１３）
属性名と属性値とノード識別子とを含む経路情報レコード保持する経路制御情報保持部を更に含む
ことを特徴とする付記９乃至１２のいずれかに記載のイベント配信装置。
【０２６１】
（付記１４）
サブスクリプションを保持するサブスクリプション保持部と、
前記サブスクリプション保持部に対して前記サブスクリプションの登録・削除を行うサブスクリプション制御部と、を更に含むことを特徴とする、付記９乃至１３記載のイベント配信装置。
【０２６２】
（付記１５）
前記代理通知要求を受信し、受信した前記代理通知要求に基づいて、前記イベント通知を送信する代理通知要求制御部を更に含むことを特徴とする、
付記９乃至１４のいずれかに記載のイベント配信装置。
【０２６３】
（付記１６）
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送するステップと、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するステップと、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部に保持された前記転送数に基づいて、転送する前記イベント配信に自身に対応する前記識別子及び対応する前記負荷情報を付加するステップと、を有する
ことを特徴とするイベント配信方法。
【０２６４】
（付記１７）
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送するステップと、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信するステップと、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部に保持された前記転送数に基づいて、前記イベント配信に前記自身に対応する前記負荷情報及び前記他ノード負荷情報保持部の保持する前記負荷情報の内の相対的に低い前記負荷情報を有する前記自身に対応する前記イベント配信装置及び前記他イベント配信装置の内の１以上を選択し、選択した自身に対応する前記イベント配信装置及び前記他イベント配信装置の前記識別子及び対応する前記負荷情報を付加するステップと、を有する
ことを特徴とするイベント配信方法。
【０２６５】
（付記１８）
代理通知条件保持部を更に含み、
前記イベント制御部は、前記自身の前記負荷情報と代理通知条件保持部に保持されている前記負荷範囲情報及び前記イベント通知数とに基づいて、前記イベントそれぞれについて、前記イベント通知の対象または前記代理通知を要求の対象のいずれにするかを判定するステップを有する
ことを特徴とする付記１６または１７記載のイベント配信方法。
【０２６６】
（付記１９）
前記負荷情報を、ＣＰＵ使用率、保留しているイベント通知メッセージ数、及び前記イベント通知メッセージに含まれる内の前記イベントの内容の任意の組合せに基づいて生成ステップを有する
ことを特徴とする付記１６乃至１８のいずれかに記載のイベント配信方法。
【０２６７】
（付記２０）
前記代理通知要求を受信し、受信した前記代理通知要求に基づいて、前記イベント通知を送信するステップを更に含むことを特徴とする、
付記１６乃至１９のいずれかに記載のイベント配信方法。
【０２６８】
（付記２１）
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送する処理と、
イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身に対応する前記負荷情報に基づいて、前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信する処理と、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部に保持された前記転送数に基づいて、前記イベント配信に前記自身に対応する前記負荷情報及び前記他ノード負荷情報保持部の保持する前記負荷情報の内の相対的に低い前記負荷情報を有する前記自身に対応する前記イベント配信装置及び前記他イベント配信装置の内の１以上を選択し、選択した自身に対応する前記イベント配信装置及び前記他イベント配信装置の前記識別子及び対応する前記負荷情報を付加する処理と、
をコンピュータに実行させることを特徴とするイベント配信用プログラム。
【０２６９】
（付記２２）
イベント配信を受信し、受信した前記イベント配信を自身以外のイベント配信装置である他イベント配信装置へ転送する処理と、
前記イベント配信を受信し、前記受信した前記イベント配信に基づいてイベント通知を送信し、自身の負荷情報に基づいて、前記他イベント配信装置の識別子と当該他イベント配信装置の負荷情報との組を１つ以上保持する他ノード負荷情報保持部の内容に基づいて決定した前記他イベント配信装置へ前記イベント配信の代理通知要求を送信する処理と、
前記イベント配信の一定時間毎の転送数を前記他イベント配信装置毎に保持するノード毎イベント転送数保持部に保持された前記転送数に基づいて、前記イベント配信に前記自身の前記負荷情報及び前記他ノード負荷情報保持部の保持する前記負荷情報の内の相対的に低い前記負荷情報を有する前記自身及び前記他イベント配信装置の内の１以上を選択し、選択した自身及び前記他イベント配信装置の前記識別子及び前記負荷情報を付加する処理と、
をコンピュータに実行させることを特徴とするイベント配信用プログラム。
【０２７０】
（付記２３）
代理通知条件保持部を更に含み、
前記イベント制御部は、前記自身の前記負荷情報と代理通知条件保持部に保持されている前記負荷範囲情報及び前記イベント通知数とに基づいて、前記イベントそれぞれについて、前記イベント通知の対象または前記代理通知を要求の対象のいずれにするかを判定する処理
をコンピュータに実行させることを特徴とする付記２１または２２記載のプログラム。
【０２７１】
（付記２４）
前記負荷情報を、ＣＰＵ使用率、保留しているイベント通知メッセージ数、及び前記イベント通知メッセージに含まれる内の前記イベントの内容の任意の組合せに基づいて生成処理
をコンピュータに実行させることを特徴とする付記２１乃至２３記載のイベント配信用プログラム。
【０２７２】
（付記２５）
前記代理通知要求を受信し、受信した前記代理通知要求に基づいて、前記イベント通知を送信する処理を更に含むことを特徴とする、
付記２１乃至２４記載のイベント配信用プログラム。
【符号の説明】
【０２７３】
１００    ノード
１１０    経路制御部
１２０    ノード毎イベント転送数保持部
１２１    イベント転送数レコード
１２３    イベント転送数
１２９    イベント転送数テーブル
１３０    経路情報保持部
１３１    経路情報レコード
１３３    属性名
１３４    属性値
１３５    ノード識別子
１３９    経路情報テーブル
１４０    サブスクリプション制御部
１５０    サブスクリプション保持部
１６０    イベント制御部
１７０    他ノード負荷情報保持部
１７１    ノード負荷情報レコード
１７３    負荷情報
１７９    他ノード負荷情報テーブル
１８０    代理通知要求制御部
１９０    メッセージ転送部
２００    イベント配信ＮＷ
３００    サブスクライバ
３０１    サブスクリプション
３０３    通知先
３１１    イベントパターン
３１２    属性
３１３    属性名
３１４    属性値
４００    パブリッシャ
４０１    イベント
４０２    属性
４０３    属性名
４０４    属性値
５００    アプリケーション
６１０    サブスクリプション登録メッセージ
６２０    サブスクリプション削除メッセージ
６３０    イベント配信メッセージ
６４０    イベント通知メッセージ
６５０    代理通知メッセージ
７００    ノード
７１０    経路制御部
８００    ノード
８９０    代理通知条件保持部
８９１    代理通知条件レコード
８９２    負荷範囲情報
８９３    イベント通知数
９１０    ノード
９２０    ノード
【図１】
0005505163.tif 000002
【図２】
0005505163.tif 000003
【図３】
0005505163.tif 000004
【図４】
0005505163.tif 000005
【図５】
0005505163.tif 000006
【図６】
0005505163.tif 000007
【図７】
0005505163.tif 000008
【図８】
0005505163.tif 000009
【図９】
0005505163.tif 000010
【図１０】
0005505163.tif 000011
【図１１】
0005505163.tif 000012
【図１２】
0005505163.tif 000013
【図１３】
0005505163.tif 000014
【図１４】
0005505163.tif 000015
【図１５】
0005505163.tif 000016
【図１６】
0005505163.tif 000017
【図１７】
0005505163.tif 000018
【図１８】
0005505163.tif 000019
【図１９】
0005505163.tif 000020
【図２０】
0005505163.tif 000021
【図２１】
0005505163.tif 000022
【図２２】
0005505163.tif 000023
【図２３】
0005505163.tif 000024
【図２４】
0005505163.tif 000025
【図２５】
0005505163.tif 000026
【図２６】
0005505163.tif 000027
【図２７】
0005505163.tif 000028
【図２８】
0005505163.tif 000029
【図２９】
0005505163.tif 000030
【図３０】
0005505163.tif 000031
【図３１】
0005505163.tif 000032
【図３２】
0005505163.tif 000033
【図３３】
0005505163.tif 000034
【図３４】
0005505163.tif 000035
【図３５】
0005505163.tif 000036
【図３６】
0005505163.tif 000037
【図３７】
0005505163.tif 000038
【図３８】
0005505163.tif 000039
【図３９】
0005505163.tif 000040
【図４０】
0005505163.tif 000041
【図４１】
0005505163.tif 000042
【図４２】
0005505163.tif 000043
【図４３】
0005505163.tif 000044