(57)【要約】【課題】    イベントを通知する装置（ノード）の処理の負荷を低減する。【解決手段】    本発明の情報通知ノードは、情報の受信登録を受け取り保持するサブスクリプションテーブル保持部と、受信登録に基づき通知の負荷を判定し、負荷に基づき通知を委譲するか否かを判定するイベント制御部と、受信登録の送信元の情報と情報を通知する通知先とを保持する負荷分散管理テーブル保持部と、イベント制御部が委譲すると判定した場合に、負荷分散管理テーブル保持部の情報に基づき通知を委譲する通知先の範囲を判定し、委譲する通知先については情報の通知の代行の依頼を他ノードに送付する。【選択図】      図１
2012146113.tif 000002
【特許請求の範囲】
【請求項１】
イベントを含む情報の受信登録（サブスクリプション）を受け取り保持するサブスクリプションテーブル保持部と、
保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定するイベント制御部と、
前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する負荷分散管理テーブル保持部と、
前記イベント制御部が委譲すると判定した場合に、前記負荷分散管理テーブル保持部が保持する情報に基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第１のノードに送付し、委譲しない通知先については前記イベント制御部に前記情報の通知を依頼する負荷分散制御部とを含む情報通知ノード。
【請求項２】
前記負荷分散制御部が、
第２のノードから情報の通知の代行の依頼を受け取ったとき、
前記第２のノードの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、第３のノードに前記情報の通知の代行の依頼を送信することを特徴とする請求項１に記載の情報通知ノード。
【請求項３】
前記負荷分散制御部が、
第２のノードから情報の通知の代行の依頼を受け取ったとき、
前記第２のノードからの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、前記第２のノードに代行の依頼の拒否を送付することを特徴とする請求項１に記載の情報通知ノード。
【請求項４】
前記負荷分散制御部が、
前記第１のノードに送付した前記情報の通知の代行の依頼に対して代行の依頼の拒否を受けた場合、第１のノードとは異なるノードに情報の通知の代行の依頼を送信することを特徴とする請求項１乃至請求項３のいずれかに記載の情報通知ノード。
【請求項５】
前記負荷分散制御部が、
前記負荷分散管理テーブル保持部が保持する前記送信元に含まれるノードから、前記第１のノードを選択することを特徴とする請求項１乃至請求項４のいずれかに記載の情報通知ノード。
【請求項６】
前記イベント制御部、又は、前記負荷分散制御部の前記自ノードで通知するか否かの判定する条件が、
前記サブスクリプションテーブル保持部が保持する前記受信登録の通知先の数、
前記配信依頼及び前記配信依頼に対するイベントの発生頻度、
自ノードの処理負荷、
通知先までの距離（ホップ数）、
自ノードのリソースの使用量、
又は
上記各条件の予想値
のいずれかを含むことを特徴とする請求項１乃至請求項５のいずれかに記載の情報通知ノード。
【請求項７】
情報の受信登録を受け取り保持し、
保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定し、
前記受信登録の送信元の情報と前記情報を通知する通知先とを保持し、
委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第１のノードに送付し、委譲しない通知先については前記情報を通知する情報通知方法。
【請求項８】
第２のノードから情報の通知の代行の依頼を受け取ったとき、
前記第２のノードの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、第３のノードに前記情報の通知の代行の依頼を送信することを特徴とする請求項７に記載の情報通知方法。
【請求項９】
情報の受信登録を受け取り保持する処理と、
保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定する処理と、
前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する処理と、
委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第１のノードに送付し、委譲しない通知先については前記情報を通知する処理とをコンピュータに実行させるプログラム。
【請求項１０】
請求項１乃至請求項６のいずれかに記載の情報通知ノードと、
情報の受信登録を登録するサブスクライバと、
前記情報を発行するパブリッシャと
を含む情報配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報の配信又は通知に関し、特に情報の配信又は通知の負荷に関する。
【背景技術】
【０００２】
ネットワークに接続した情報処理装置は、ネットワークを介して、情報を送信又は受信する。このようなネットワークを介して情報を送受信する情報処理装置のシステムの１つに、情報配信システムがある。
【０００３】
情報配信システムには、イベントを含む情報を１つ又は複数の通知先に配信（通知）するシステムがある。このような情報配信システムが配信する情報は、例えば、ＲＦＩＤ（Radio Frequency IDentification）読み取り機が物品に付されたＲＦＩＤを検出するイベント（event、出来事）、又は、近接センサが物品の接近を検出するイベントを含む。
【０００４】
情報配信システムを構成する情報処理装置（以下、ノード（node、節点）と称す）は、いろいろな接続形態のネットワークを構成することができる。そのような情報配信システムを構成するネットワークの接続形態の１つに、pub/sub（publisher/subscriber）ネットワークがある（例えば、非特許文献１を参照）。
【０００５】
一般的なpub/subネットワークを用いた情報配信システムについて図面を参照して説明する。
【０００６】
図２２は、pub/subネットワーク９０を含む情報配信システム９の一例を示す図である。
【０００７】
情報配信システム９は、サブスクライバ（subscriber）２０と、パブリッシャ（publisher）３０と、pub/subネットワーク９０とを含んでいる。
【０００８】
サブスクライバ（subscriber、以下、ｓｕｂと称すこともある）２０は、イベントを受け取りたい者（利用者など）又は装置からの指示を基に、配信（通知）を受けたいイベントの条件を、サブスクリプション（subscription、受信登録）としてpub/subネットワーク９０に登録（サブスクライブ：subscribe）する。このようにサブスクリプションは、pub/subネットワーク９０が、サブスクライバ２０にイベントを通知（notify）するために必要な情報を含んでいる。
【０００９】
パブリッシャ（publisher、以下、ｐｕｂと称すこともある）３０は、図示しないセンサなどからイベントを受け取り、イベント又はイベントを示すような情報（まとめて、イベントと称す）をpub/subネットワーク９０に入力（パブリッシュ、publish、登録とも称す）する。
【００１０】
pub/subネットワーク９０は、パブリッシャ３０から受け取ったイベントと、登録済みのサブスクリプションに含まれるイベントの条件とを比較する。イベントと登録済みサブスクリプションのイベントの条件が一致した場合、pub/subネットワーク９０は、一致したサブスクリプションを登録したサブスクライバ２０に、イベントを通知（notify、配信）する。
【００１１】
このように動作する一般的なpub/subネットワーク９０は、サーバのような情報処理装置（ノード）が相互に接続したネットワークであり、所定の方式に基づき情報（サブスクリプション及びイベント）を転送する。この転送において、ノードは、情報の転送先を探索（ルックアップ、lookup）する。そのため、一般的なpub/subネットワークは、ネットワークが大きく又は複雑になると、情報の転送先の探索に時間が掛かるという問題点があった。
【００１２】
そこで、探索を改善したネットワークとして、分散ハッシュテーブル（DHT：Distributed Hash Table）を用いたネットワークがある（例えば、非特許文献２を参照）。
【００１３】
分散ハッシュテーブルとは、情報にハッシュ関数を適用して求めたハッシュ値に対応するノードが情報を管理又は処理する管理方式である。ハッシュ値は固定長のため、分散ハッシュテーブルは、ネットワークが大きくなっても探索の負荷が増大しない。
【００１４】
分散ハッシュテーブルを用いたpub/subネットワーク９０の情報の転送について図面を参照して説明する。
【００１５】
図２３は、分散ハッシュテーブルを用いたpub/subネットワーク９０のサブスクリプションの登録における転送の一例を示す図である。
【００１６】
図２３において、pub/subネットワーク９０を構成するノードは、小円で示している。各ノードは、ネットワークを介して接続している。説明の便宜のため、図２３では、模式的に円形の接続として示している。
【００１７】
分散ハッシュテーブルを用いたネットワークを構成する各ノードは、ノードを管理するためのキー（鍵）を備える。キーは、ノードの識別子（ＩＤ、identification）の値としてもよい。そのため、図２３において、各ノードのキーは、ノードの識別子の値として、ノードを示す小円の中に２進数を用いて示している。なお、図２３において、説明の便宜のため、各ノードのキーの値は、１つとして示しているが、分散ハッシュテーブルを用いたノードは、複数のキーの値を備えても良い。
【００１８】
サブスクライバ（ｓｕｂ）２０が、サブスクリプションをpub/subネットワーク９０に登録すると、サブスクリプションを受け取ったノードは、受け取ったサブスクリプションに含まれ条件にハッシュ関数を適用してキーを求める。そして、サブスクリプションを受け取ったノードは、キーに基づいて、キーに対応するノードにサブスクリプションを転送する。ここで、ハッシュ関数を適用する条件とは、例えば、サブスクリプションで通知を依頼したイベントである。
【００１９】
図２３は、一例として、サブスクライバが登録した５つのサブスクリプションの転送先のキーが、すべてＩＤ＝１０００のノードの場合の転送を示している。サブスクリプションを受け取った各ノードは、サブスクリプションから求めたキーに基づき、ＩＤ＝１０００のノードにサブスクリプションを転送する。ただし、一般的なpub/subネットワークは、複数のネットワークが接続したネットワークである。そのため、pub/subネットワークを構成するノードは、転送先のノードと同じネットワークに接続していない場合もある。そのような場合、ノードは、転送する情報を、pub/subネットワークを構成する複数のノードを経由して、転送先のノードに転送する。ノードは、情報を転送するために経由するノードの情報、つまり経路情報を、ルーティングテーブル（routing table）として備え、ルーティングテーブルを参照して、転送先のノードに届くように、所定のノードに情報を送信する。
【００２０】
例えば、図２３において、ＩＤ＝０００１のノードは、直接ＩＤ＝１０００のノードにサブスクリプションを転送できない。そのため、ＩＤ＝０００１のノードは、ＩＤ＝０１０１のノードに、サブスクリプションを転送する。ＩＤ＝０１０１のノードも、直接ＩＤ＝１０００のノードに転送できないため、ＩＤ＝０１１１のノードにサブスクリプションを転送する。ＩＤ＝０１１１のノードは、ＩＤ＝１０００のノードに転送できるため、ＩＤ＝１０００のノードにサブスクリプションを転送する。このように、pub/subネットワークを構成するノードは、ルーティングテーブルを用いて、情報を転送する。
【００２１】
サブスクリプションを受けたＩＤ＝１０００のノードは、受け取ったサブスクリプションを保持する。なお、ＩＤ＝１０００のノードは、サブスクリプションの条件にハッシュ関数を適用し、求めたハッシュ値が自分のキー（ＩＤ）となることに基づいて、自ノードで管理するサブスクリプションであることを判定できる。
【００２２】
図２４は、分散ハッシュテーブルを用いたpub/subネットワーク９０のイベントの配信（通知）の一例を示す図である。
【００２３】
図２４は、イベントから求めたキー（ノードＩＤ）が、ＩＤ＝１０００である場合の一例である。パブリッシャ（ｐｕｂ）からイベントを受けたＩＤ＝０１０１のノードは、イベントにハッシュ関数を適用して求めたハッシュ値から、イベントの転送先ノードがＩＤ＝１０００のノードであることを判定し、イベントを転送する。なお、ＩＤ＝０１０１のノードは、既に説明したとおり、ＩＤ＝１０００のノードに直接情報を転送できないため、ＩＤ＝０１１１のノードを介して、ＩＤ＝１０００のノードにイベントを転送する。
【００２４】
イベントを受け取ったＩＤ＝１０００のノードは、図２３を用いて説明した登録したサブスクリプションに基づき、サブスクライバ（ｓｕｂ）２０にイベントを通知（notify、配信）する。
【００２５】
なお、図２３及び図２４に示すＩＤ＝１０００のノードのように、サブスクライバとイベントが出会う（集まる）ノードは、ランデブー（rendezvous）ノードと呼ばれる。
【００２６】
このように、分散ハッシュテーブルに基づき、ネットワークが増大しても、各ノードは、探索するテーブルを所定の範囲とすることができる。
【００２７】
ただし、特別なイベント、例えば、著名人に関するイベント、株式市場で注目されている株式会社の株価の変動のイベント、災害のイベントは、通知を受けたいサブスクライバが多い。そのため、そのようなイベントのランデブーノードは、イベントの通知の処理が大きな負荷となる。その結果、ランデブーノードは、分散ハッシュテーブルを採用していても、通知先の多いイベント、つまり負荷が大きなイベントの通知に時間が掛かり、通知が遅れるという問題点があった。
【００２８】
このような負荷の増大に対し、一般的なネットワークを使用したシステムは、装置の負荷軽減として、負荷分散を用いる。
【００２９】
例えば、トンネリングを使用するシステムは、装置（ノード）の稼動状態を基に、トンネリングした通信経路の割り振りを変更する（例えば、特許文献１を参照）。しかし、特許文献１に記載のシステムは、通信経路を変更するものであり、負荷が増大したノードにおける通信路以外の負荷を軽減することができない問題点があった。
【００３０】
また、複数の送信先に情報を通知するシステムとして、通知先に時間を設定し、時間を分けて情報を通知するシステムがある。（例えば、特許文献２を参照）。しかし、株価の変動又は災害などのイベントは、通知先に時間差を設定できないため、特許文献２に記載のシステムは、このようなイベントには使用できない問題点があった。
【００３１】
そこで、装置での処理を軽減するため、処理するプログラムを別の装置に移動するシステムがある（例えば、特許文献３を参照）。また、引継ぎの処理の時間を削減するため、処理に必要なデータは、元の装置の残し、処理だけ移動するシステムもある（例えば、特許文献４を参照）。
【先行技術文献】
【特許文献】
【００３２】
【特許文献１】特開２００５−２２８０３６
【特許文献２】特開２００８−１９８０４７
【特許文献３】特開２００５−００４６７４
【特許文献４】特開２００３−２４８６６９
【非特許文献】
【００３３】
【非特許文献１】F Cao, 他, “Efficient Event Routing in Content-based Publish-Subscribe Service Networks”, IEEE INFOCOM, 2004
【非特許文献２】Ion Stoica, 他, “Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications” ACM SIGCOMM, 2001
【発明の概要】
【発明が解決しようとする課題】
【００３４】
しかし、特許文献３及び特許文献４に記載のシステムは、処理する装置を変更するものであり、イベントの通知の処理を引き継いだ装置での処理の負荷の量は、引き渡した装置の負荷と同様である。特許文献３及び特許文献４に記載のシステムは、イベントの通知を引き継いだ装置、つまり、イベントを通知する装置におけるイベントを通知する処理の負荷を削減できないという問題点があった。
【００３５】
本発明の目的は、上記問題点を解決し、情報（イベントを含む情報）を通知（notify）する装置（ノード）の負荷の軽減を提供することにある。
【課題を解決するための手段】
【００３６】
本発明の情報通知ノードは、イベントを含む情報の受信登録（サブスクリプション）を受け取り保持するサブスクリプションテーブル保持部と、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定するイベント制御部と、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する負荷分散管理テーブル保持部と、前記イベント制御部が委譲すると判定した場合に、前記負荷分散管理テーブル保持部が保持する情報に基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第１のノードに送付し、委譲しない通知先については前記イベント制御部に前記情報の通知を依頼する負荷分散制御部とを含む。
【００３７】
本発明の情報通知方法は、情報の受信登録を受け取り保持し、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定し、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持し、委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第１のノードに送付し、委譲しない通知先については前記情報を通知する。
【００３８】
本発明のプログラムは、情報の受信登録を受け取り保持する処理と、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定する処理と、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する処理と、委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第１のノードに送付し、委譲しない通知先については前記情報を通知する処理とをコンピュータに実行させる。
【００３９】
本発明の情報配信システムは、本発明の情報通知ノードは、イベントを含む情報の受信登録（サブスクリプション）を受け取り保持するサブスクリプションテーブル保持部と、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定するイベント制御部と、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する負荷分散管理テーブル保持部と、前記イベント制御部が委譲すると判定した場合に、前記負荷分散管理テーブル保持部が保持する情報に基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第１のノードに送付し、委譲しない通知先については前記イベント制御部に前記情報の通知を依頼する負荷分散制御部とを含む情報通知ノードと、情報の受信登録を登録するサブスクライバと、前記情報を発行するパブリッシャとを含む。
【発明の効果】
【００４０】
本発明によれば、情報（イベントを含む情報）を通知（notify）する装置（ノード）の処理の負荷を低減することができる。
【図面の簡単な説明】
【００４１】
【図１】本発明のおける第１の実施の形態に係る情報通知ノードの構成の一例を示すブロック図である。
【図２】第１の実施の形態に係る情報配信システムの構成の一例を示すブロック図である。
【図３】第１の実施の形態に係る情報通知ノードのサブスクリプションの受信動作の一例を示すフロー図である。
【図４】第１の実施の形態に係る情報配信システムのサブスクリプションの転送の一例を示す図である。
【図５】第１の実施の形態に係る負荷分散管理テーブルの一例を示す図である。
【図６】第１の実施の形態に係る負荷分散管理テーブルの別の一例を示す図である。
【図７】第１の実施の形態に係るサブスクリプションテーブルの一例を示す図である。
【図８】第１の実施の形態に係るイベント制御部の動作の一例を示すフロー図である。
【図９】第１の実施の形態に係る負荷分散制御部の動作の一例を示すフロー図である。
【図１０】第１の実施の形態に係る負荷分散管理テーブルの一例を示す図である。
【図１１】第１の実施の形態に係る情報通知ノードの動作の一例を示すフロー図である。
【図１２】第１の実施の形態に係る負荷分散管理テーブルの一例を示す図である。
【００４２】
【図１３】第１の実施の形態に係る情報通知ノードの動作の一例を示すフロー図である。
【図１４】第１の実施の形態に係る負荷分散制御部の動作の一例を示すフロー図である。
【図１５】第１の実施の形態に係る情報通知ノードの動作の一例を示すフロー図である。
【図１６】第１の実施の形態に係るpub/subネットワークのイベントの通知の一例を示す図である。
【図１７】第１の実施の形態に係るイベント制御部の動作の一例を示すフロー図である。
【図１８】第１の実施の形態に係る負荷分散制御部の動作の一例を示すフロー図である。
【図１９】第１の実施の形態に係る負荷分散制御部の動作の一例を示すフロー図である。
【図２０】第１の実施の形態に係る情報通知ノードの別の構成の一例を示すブロック図である。
【図２１】第２の実施の形態に係る情報通知ノードの構成の一例を示す図である。
【図２２】一般的な情報配信システムの一例を示す図である。
【図２３】一般的なpub/subネットワークにおけるサブスクリプションの転送の一例を示す図である。
【図２４】一般的なpub/subネットワークにおけるイベントの通知の一例を示す図である。
【発明を実施するための形態】
【００４３】
次に、本発明における実施の形態について図面を参照して説明する。
【００４４】
まず、本実施の形態の説明における用語について整理する。
【００４５】
「イベント（event、出来事）」とは、センサの検出又は人の操作などに基づき発生する情報である。イベントは、センサの検出などイベントの基となる情報を受けた装置が、ネットワークに発信（パブリッシュ、publish、登録又は入力とも称す）する。ネットワークにイベントを発信する装置をパブリッシャ（publisher）、又は、ｐｕｂと称す。パブリッシャが発信したイベントは、ネットワーク、具体的にはネットワークを構成する装置が受け取る。なお、本実施の形態に係るイベントは、イベント及びイベントに基づき生成又は発生した情報を含めてイベントと称す。
【００４６】
イベントは、いろいろな情報を含んでも良い。本実施の形態に係るイベント（イベントを含む情報とも称す）は、一例としてイベントＩＤ（Identification、識別子）と、イベント情報とを含む。
【００４７】
イベントＩＤは、イベントを一意に識別するための識別子である。例えば、イベントＩＤは、イベントの基となったセンサが検出したＲＦＩＤ（Radio Frequency IDentification）にハッシュ関数を適用して求めたハッシュ値である。後ほど説明するように、このイベントＩＤに相当するキー（key、鍵）を識別子として備える情報通知ノードが、イベントを通知（notify、配信とも称す）する。つまり、イベントＩＤは、イベントを識別すると共に、イベントを通知する情報通知ノードの判別に用いてもよい。
【００４８】
イベント条件は、イベントに関する情報、例えば、イベントが発生した条件（時間、場所、原因など）を含む情報である。
【００４９】
なお、本実施の形態に係る情報通知ノードは、イベントを用いて説明するが、本実施の形態に係る情報通知ノードが扱う情報は、イベントに限られるわけではない。本実施の形態に係る情報通知ノードが扱う情報は、例えば、データベースの情報でもよく、エキスパートシステム（expert system）の情報でよい。
【００５０】
「サブスクリプション(subscription)」とは、通知（配信）を受けたい情報（イベントを含む情報）について、ネットワークに登録（サブスクライブ、subscribe）する情報（受信登録）である。サブスクリプション（受信登録）を登録する装置をサブスクライバ（subscriber）、又は、ｓｕｂと称す。サブスクライバがネットワークに登録したサブスクリプションは、後ほど説明するように、イベントを通知する情報通知ノードに転送される。
【００５１】
サブスクリプションは、いくつかの情報を含んでいても良い。本実施の形態に係るサブスクリプションは、一例として、サブスクリプション条件と、サブスクライバＩＤと、通知先ＩＤと、経由ノードＩＤとを含む。
【００５２】
サブスクリプション条件は、サブスクリプションを通知するためのイベントに関する条件を含む情報である。なお、サブスクリプション条件が含むイベントに関する条件は、イベントの一部と一致すれば良い場合を含む。例えば、サブスクリプション条件が、イベントに関する条件として「場所＝東京」を含む場合、「場所＝東京、事件＝火事」又は「場所＝東京、事件＝地震」などのイベントは、サブスクリプション条件と一致するイベントとしてもよい。また、サブスクリプション条件は、イベントを通知する情報通知ノードにサブスクリプションを転送するための情報、例えば、イベントＩＤに相当する情報を含む。
【００５３】
サブスクライバＩＤは、サブスクリプションをネットワークに登録したサブスクライバを示す情報（識別子）である。
【００５４】
通知先ＩＤは、登録したサブスクリプションに基づいてイベントを通知する装置を示す情報（識別子）である。通知先ＩＤで示される通知先の装置は、１つ又は複数でも良い。また、通知先の装置は、サブスクライバでもよい。つまり、サブスクリプションを登録したサブスクライバが、イベントを通知（配信）先となってもよい。なお、説明の便宜のため、本実施の形態に係るイベントの通知先の装置は、サブスクリプションを登録したサブスクライバとする。そのため、本実施の形態に係るサブスクリプションは、通知先ＩＤを、サブスクライバＩＤで代用しても良い。
【００５５】
経由ノードＩＤは、サブスクリプションを中継したノードの識別子である。各ノードは、サブスクリプションを受け取った際に、送付元のノードの識別子を経由ノードＩＤに設定する。ただし、経由ノードＩＤは、サブスクリプションを送信するときに送信元のノードが設定してもよい。また、本実施の形態に係る経由ノードＩＤは、経由したノードの識別子をすべて含んでいても良く、所定の範囲又は数のノードの識別子を含んでも良く、直前のノードの識別子を含むようにしても良い。
【００５６】
「pub/subネットワーク」とは、サブスクライバがサブスクリプションを登録し、パブリッシャがイベントを発信するネットワークである。また、pub/subネットワークを構成する装置は、イベントの通知を担当する情報通知ノードに、サブスクリプション及びイベントを転送する。さらに、pub/subネットワークは、情報通知ノードが作成するメッセージを転送する。なお、pub/subネットワークは、一般的なネットワークと同様に、情報を転送する装置の経路情報（ルーティングテーブル：routing table、経路表）を含み、ルーティングテーブルを用いて情報を転送する。つまり、pub/subネットワークを構成するノードは、ルーティングテーブルに基づき、所定の装置にサブスクリプション、イベント、及び、メッセージを転送する。
【００５７】
「ノード（node、節点）」とは、通信路を介して相互に接続してpub/subネットワークを構成する装置である。ノードは、ルーティングテーブルに基づき情報の転送先を探索する。ノードは、この探索に、いろいろな方式を使用しても良い。ただし、本実施の形態では、説明の便宜のため、分散ハッシュテーブル（ＤＨＴ：Distributed Hash Table）を用いて説明する。そのため、各ノードは、ＤＨＴのために割り振られたキーとして識別子（ノードＩＤ）を備える。既に説明しているが、本実施の形態に係るノードＩＤは、イベントＩＤに相当するキーである。つまり、本実施の形態に係るノードＩＤは、イベントＩＤのハッシュ値として説明する。
【００５８】
なお、本実施の形態に係るノードは、キーとしてのノードＩＤを、１つの値に限らず、複数の値を保持しても良い。ただし、本実施の形態では、説明の便宜のため、各ノードは、１つのノードＩＤ（キー）の値を持つとする。
【００５９】
また、ノードは、既に説明した、情報の転送経路（例えば、転送先及び／又は転送元）を示す情報を保持するルーティングテーブルを含んでいる。なお、本実施の形態においてルーティングテーブルは、論理接続に基づくルーティンテーブルとして説明する。ただし、本実施の形態に係るノードは、物理的接続に基づくルーティングテーブルを含んでもよい。
【００６０】
「情報通知ノード」は、サブスクリプション（受信登録）と情報（イベントを含む情報）とに基づき、情報（イベントを含む情報）を、サブスクリプションで指定された通知先（通知先ＩＤ）の装置に通知（notify、配信）するノードである。本発明の実施の形態に係るpub/subネットワークは、少なくとも一部に、情報通知ノードを含む。なお、情報通知ノードのように、サブスクリプション（受信登録）と情報（イベントを含む情報）とを用いて処理するノードをランデブーノード（rendezvous node、出会いノード）と称する。
【００６１】
本実施の形態に係る情報通知ノードは、後ほど説明するとおり、負荷の状態に応じて、情報（イベントを含む情報）の通知を他の情報通知ノードに委譲する。また、情報通知ノードは、他の情報通知ノードから依頼を受けて情報の通知を代行する。このような情報の通知の委譲及び代行のため、本実施の形態に係る情報通知ノードは、メッセージを送受信する。
【００６２】
（第１の実施の形態）
続いて、本発明における第１の実施の形態に係る情報通知ノード１０について図面を参照して説明する。
【００６３】
まず、本実施の形態に係る情報通知ノード１０の構成について説明する。
【００６４】
図１は、第１の実施の形態に係る情報通知ノード１０の構成の一例を示すブロック図である。
【００６５】
情報通知ノード１０は、ネットワークを介し、図示しない情報配信システムを構成する他のノード、サブスクライバ（ｓｕｂ）、及び、パブリッシャ（ｐｕｂ）と情報（例えば、サブスクリプション、又は、イベント）を送受信する。
【００６６】
そのため、情報通知ノード１０は、情報転送部１１０と、ルーティング部１２０と、ルーティングテーブル保持部１３０と、イベント制御部１４０と、サブスクリプションテーブル保持部１５０と、負荷分散制御部１６０と、負荷分散管理テーブル保持部１７０とを含む。
【００６７】
情報転送部１１０は、ネットワークを介し、情報通知ノード１０の各部と、ネットワークに接続した他の装置（他のノード、サブスクライバ、又は、パブリッシャ）との情報の送受信を中継する。
【００６８】
ルーティング部１２０は、ルーティングテーブル保持部１３０が保持するルーティングテーブル１３１に基づき、情報の転送先を探索（ルックアップ、look-up）し、情報転送部１１０を介して情報を転送する。
【００６９】
ルーティングテーブル保持部１３０は、ルーティング部１２０が情報の転送先を探索するために用いるルーティングテーブル１３１を保持している。
【００７０】
なお、ルーティング部１２０及びルーティングテーブル保持部１３０は、一般的なネットワークを構成する装置が用いるルーティングプロトコル（routing protocol）に基づいてルーティングテーブル１３１を保持及び更新すればよく、ルーティングテーブル１３１に関する詳細な説明は省略する。また、ルーティングテーブル１３１において、ノード（装置）の通過の数をホップ（hop）数と称す。
【００７１】
イベント制御部１４０は、受け取ったサブスクリプションに基づき、サブスクリプションテーブル保持部１５０が保持するサブスクリプションテーブル１５１を作成及び更新する。また、イベント制御部１４０は、サブスクリプションテーブル１５１に基づき、パブリッシャ又は他のノードから受け取ったイベントを、イベントの通知先（本実施の形態ではサブスクライバ）に通知する。イベント制御部１４０の動作の詳細については、後ほど説明する。なお、自ノードでサブスクリプションテーブル１５１に保持し、イベントの通知の処理の対象となるサブスクリプションを、「管理対象サブスクリプション」と称す。また、管理対象サブスクリプションの対象となるイベントを「管理対象イベント」と称す。さらに、管理対象イベントを通知する情報通知ノード１０を「管理担当」の情報通知ノードと称す。つまり、管理担当の情報通知ノード１０が、管理対象サブスクリプションをサブスクリプションテーブル１５１に保持して、管理対象イベントを通知することとなる。
【００７２】
サブスクリプションテーブル保持部１５０は、イベント制御部１４０が使用する管理対象サブスクリプションを含むサブスクリプションテーブル１５１を保持する。なお、本実施の形態に係るサブスクリプションテーブル１５１に保持される情報の組を、レコード（record）と称す。
【００７３】
負荷分散制御部１６０は、負荷分散管理テーブル保持部１７０が保持する負荷分散管理テーブル１７１を作成及び更新する。さらに、負荷分散制御部１６０は、負荷分散管理テーブル１７１に基づき、情報通知ノード１０の負荷分散処理を制御する。負荷分散制御部１６０の詳細な動作についても、後ほど説明する。
【００７４】
負荷分散管理テーブル保持部１７０は、負荷分散制御部１６０が使用する負荷分散管理テーブル１７１を保持する。なお、負荷分散管理テーブル１７１に保持される組となった情報も、レコードと称す。
【００７５】
次に、本実施の形態に係る情報通知ノード１０を含む情報配信システム１の構成について説明する。
【００７６】
図２は、情報通知ノード１０を含む情報配信システム１の一例を示すブロック図である。
【００７７】
情報配信システム１は、情報通知ノード１０を含むpub/subネットワーク４０と、サブスクライバ２０と、パブリッシャ３０とを含む。図２では、説明の便宜のため、サブスクライバ２０とパブリッシャ３０を１つとして示しているが、本実施の形態に係る情報配信システム１が含む、サブスクライバ２０及びパブリッシャ３０は１つに限らず、それぞれ２つ以上でも良い。
【００７８】
なお、以下の説明において、各ノードの経路上での位置関係を明確にする場合、ランデブーノードとなる情報通知ノードを「対象ノード」と称す。そして、対象ノードにサブスクリプションを転送するノード、つまり、ルーティングテーブル１３１において前に登録されている情報通知ノードを「前ノード」と称す。さらに、前ノードにサブスクリプションを転送するノード、つまり、ルーティングテーブル１３１において前ノードの前に登録されている情報通知ノードを「前々ノード」と称す。なお、本実施の形態に係る、「前」とは、１つ前に限られず、２つ以上前でもよい。ただし、図２では、記載の便宜のため、「前」を１つ前として示す。そのため、図２において、情報通知ノード１０が対象ノード、情報通知ノード１１が前ノード、情報通知ノード１２が前々ノードとなる。
【００７９】
情報通知ノード１０は、ルーティングテーブル１３１に基づいて前ノードを探索する。ただし、情報通知ノード１０は、「前ノード」を、サブスクリプションに含まれる経由ノードＩＤを用いて探索してもよい。
【００８０】
なお、本実施の形態に係る情報通知ノードは、同じ構成に限られないが、説明の便宜のため、以下の説明では、情報通知ノードは、同じ構成とする。そのため、各情報通知ノードの構成に付した番号は、図１の番号を参照する。また、情報通知ノードに共通する説明は、情報通知ノード１０を用いて説明する。
【００８１】
図２において、サブスクライバ２０が、サブスクリプションをpub/subネットワーク４０を登録（subscribe）する。情報通知ノード１０乃至情報通知ノード１２は、サブスクリプションから求めたキーを、ルーティングテーブル１３１で探索し、求めたキーを備える情報通知ノード（例えば、図２に示す情報通知ノード１０）に転送する。サブスクリプションを管理する情報通知ノード（例えば、図２に示す情報通知ノード１０）は、受け取ったサブスクリプションをサブスクリプションテーブル１５１に保持する。なお、既に説明しているが、サブスクリプションの経由ノードＩＤは、転送の際に順次追加される。
【００８２】
次に、パブリッシャ３０が、イベントをpub/subネットワーク４０に入力（publish）する。イベントも、ルーティングテーブル１３１に基づき、情報通知ノード１０に転送される。
【００８３】
イベントを受け取った情報通知ノード１０は、サブスクリプションで指定されている通知先（本実施の形態ではサブスクライバ２０）に、イベントを通知（notify）する。
【００８４】
さらに、情報通知ノード１０は、必要に応じ、前ノードである情報通知ノード１１にイベントの通知の代行の依頼のメッセージを送信する。
【００８５】
通知の代行の依頼のメッセージを受けた情報通知ノード１１は、イベントを通知先（サブスクライバ）に通知する。さらに、必要に応じ、情報通知ノード１１は、前々ノードである情報通知ノード１２にイベントの通知の代行の依頼のメッセージを送信する。
【００８６】
次に情報通知ノード１０の動作に詳細ついて図面を参照して説明する。
【００８７】
まず、情報通知ノード１０のサブスクリプションを受け取ったときの動作について説明する。
【００８８】
図３は、情報通知ノード１０がサブスクリプションを受けた場合の動作の一例を示すフロー図である。
【００８９】
サブスクライバ２０又は他のノードからサブスクリプションを受け取った情報通知ノード１０の情報転送部１１０は、サブスクリプションをルーティング部１２０に送る（ステップ１００１）。
【００９０】
サブスクリプションを受け取ったルーティング部１２０は、サブスクリプションの経由ノードＩＤに送信元の情報通知ノードの識別子（ＩＤ）を設定後、サブスクリプションを負荷分散制御部１６０に送る。サブスクリプションを受け取った負荷分散制御部１６０は、サブスクリプションに基づき、負荷分散管理テーブル保持部１７０が保持する負荷分散管理テーブル１７１を更新する（ステップ１００２）。
【００９１】
なお、負荷分散制御部１６０にサブスクリプションを送るのはルーティング部１２０に限られず、情報転送部１１０が、負荷分散管理制御部１６０に送っても良い。
【００９２】
サブスクリプションを負荷分散制御部１６０に送付後、ルーティング部１２０は、サブスクリプションが含むサブスクリプション条件に基づき、受け取ったサブスクリプションが管理対象サブスクリプションか否かを判定する（ステップ１００３）。
【００９３】
自ノードの管理対象サブスクリプションでない場合（ステップ１００３でno）、ルーティング部１２０は、ルーティングテーブル１３１に基づき、情報転送部１１０を介して、次のノードにサブスクリプションを転送する（ステップ１００４）。
【００９４】
自ノードの管理対象サブスクリプションの場合（ステップ１００３でyes）、ルーティング部１２０は、サブスクリプションをイベント制御部１４０に送る。サブスクリプションを受け取ったイベント制御部１４０は、受け取ったサブスクリプションを、サブスクリプションテーブル保持部１５０が保持するサブスクリプションテーブル１５１に追加する（ステップ１００５）。この追加として、イベント制御部１４０は、サブスクリプションテーブル１５１の一部の情報を更新してもよい。なお、情報通知ノード１０は、自ノードの管理対象サブスクリプションに対し、ランデブーノードとなる。
【００９５】
次のノードにサブスクリプションを転送する、又は、サブスクリプションをサブスクリプションテーブル１５１に登録し、情報通知ノード１０は、サブスクリプションを受けた場合の動作を終了する。
【００９６】
次に、pub/subネットワーク４０におけるサブスクリプションの転送について図面を参照して説明する。
【００９７】
図４は、pub/subネットワーク４０におけるサブスクリプションの転送の一例を示す図である。
【００９８】
まず、図４の構成について説明する。
【００９９】
図４において、大円は、ルーティングテーブル１３１で示す情報の転送経路である。なお、図４に示す経路における転送方向は、時計回りとする。そのため、サブスクリプションは、時計回りに転送されている。
【０１００】
情報通知ノードは、小円で示している。小円の中の数値が、分散ハッシュテーブル（ＤＨＴ）のキーでもある各情報通知ノードのノードＩＤである。
【０１０１】
なお、本実施の形態に係る情報通知ノードは、図４のどのノードの位置でもよいが、本実施の形態に係る説明では、ＩＤ＝１０００の情報通知ノード１０を用いて説明する。
【０１０２】
なお、本実施の形態に係る情報通知ノード１０は、前ノードが１つとは限らない。そこで、図４は、一例として、情報通知ノード１０の前ノードが２つの場合を示している。ＩＤ＝０１１１の情報通知ノード１１が、第１の前ノードであり、ＩＤ＝０１１０の情報通知ノード１３が、第２の前ノードである。また、ＩＤ＝０１０１の情報通知ノード１２は、情報通知ノード１１の前ノードである。情報通知ノード１１は情報通知ノード１０の前ノードのため、情報通知ノード１２は、情報通知ノード１０に対する前々ノードである。
【０１０３】
さらに、図４において、６つのサブスクライバ（ｓｕｂ２０ａ−ｓｕｂ２０ｆ）が、サブスクリプションを登録している。図４では、サブスクリプションの登録を、各サブスクライバ（ｓｕｂ）からの矢印で示している。説明の便宜のため、６つのサブスクリプションは、すべて、情報通知ノード１０（ＩＤ＝１０００）の管理対象サブスクリプションとする。
【０１０４】
続いて、図４における情報通知ノードのサブスクリプションの転送の動作について説明する。
【０１０５】
サブスクライバ２０ａからサブスクリプションを受け取った情報通知ノード１５（ＩＤ＝０００１）は、自ノードで保持するルーティングテーブル１３１に基づき、サブスクリプションを転送する。ただし、情報通知ノード１５は、サブスクリプションの転送先である情報通知ノード１０（ＩＤ＝１０００）に直接サブスクリプションを転送できない。そのため、情報通知ノード１５は、まず、情報通知ノード１２（ＩＤ＝０１０１）にサブスクリプションを転送する。
【０１０６】
情報通知ノード１５及びサブスクライバ２０ｃからサブスクリプションを受け取った情報通知ノード１２は、情報通知ノード１０にサブスクリプションを直接転送できないため、情報通知ノード１１（ＩＤ＝０１１１）に２つのサブスクリプションを転送する。
【０１０７】
情報通知ノード１２及びサブスクライバ２０ｅからサブスクリプションを受け取った情報通知ノード１１は、情報通知ノード１０に３つのサブスクリプションを転送する。
【０１０８】
同様に、サブスクライバ２０ｂからサブスクリプションを受け取った情報通知ノード１４（ＩＤ＝００１０）は、情報通知ノード１０にサブスクリプションを直接転送できないため、情報通知ノード１３（ＩＤ＝０１１０）にサブスクリプションを転送する。
【０１０９】
情報通知ノード１４及びサブスクライバ２０ｄからサブスクリプションを受け取った情報通知ノード１３は、２つのサブスクリプションを情報通知ノード１０に転送する。
【０１１０】
サブスクライバ２０ｆ、情報通知ノード１３、及び、情報通知ノード１１からサブスクリプションを受け取った情報通知ノード１０は、受け取ったサブスクリプションが自ノードの管理対象サブスクリプションのため、サブスクリプションを転送しない。
【０１１１】
管理対象サブスクリプションを受け取った管理担当の情報通知ノード１０は、図３を用いて説明した動作に基づき、負荷分散管理テーブル１７１及びサブスクリプションテーブル１５１を更新する。
【０１１２】
このように、本実施の形態に係る情報通知ノード１０を含むpub/subネットワーク４０は、サブスクリプションの管理担当である情報通知ノード１０にサブスクリプションを転送する。
【０１１３】
次に、図４を用いて説明したサブスクリプションを登録後の情報通知ノード１０が含むテーブルについて説明する。なお、既に説明したとおり、ルーティングテーブル１３１についての説明は、省略する。
【０１１４】
まず、負荷分散管理テーブル１７１について図面を参照して説明する。
【０１１５】
図５は、図４を用いて説明したサブスクリプションの転送動作に基づいて、情報通知ノード１０が作成又は更新した負荷分散管理テーブル１７１の一例を示す図である。
【０１１６】
本実施の形態に係る負荷分散管理テーブル１７１は、サブスクリプション条件１７２と、前ノードＩＤ１７３と、通知先ＩＤ１７４と、負荷担当１７５と、前ノード転送１７６とを含む。なお、図５では、各行がレコードとなっている。
【０１１７】
サブスクリプション条件１７２は、サブスクリプションが含むサブスクリプション条件を保持する。つまり、サブスクリプション条件１７２は、サブスクリプションに基づきイベントの通知を担当する管理担当の情報通知ノード及びイベントの条件に関する情報を含む。例えば、図５の１行目（１つ目）のレコードは、ＩＤ＝１０００の情報通知ノード（図４では情報通知ノード１０）が管理担当の情報通知ノードであり、通知するイベントは「事故」であることを示している。
【０１１８】
前ノードＩＤ１７３は、サブスクリプションを送ってきたノード、つまり、前ノードの情報を保持する。なお、前ノードを示す方式は、いろいろな方式を使用してよいが、本実施の形態では、一例として、ノードＩＤを用いる。例えば、図５の１行目のレコードは、ＩＤ＝０１１１の情報通知ノード（図４では、情報通知ノード１１）からサブスクリプションを受け取ったことを示している。ただし、情報通知ノード１０がサブスクライバ２０からサブスクリプションを受け取った場合、前ノードＩＤ１７３は、空白（図５の３行目のレコードの「−」）となる。また、既に説明したとおり、前ノードＩＤ１７３は、サブスクリプションの経由ノードＩＤに基づいて設定してもよい。
【０１１９】
通知先ＩＤ１７４とは、サブスクリプションに基づき指定されたイベントの通知先（本実施の形態ではサブスクライバ２０）を示す情報である。なお、図５に示すレコードは、前ノードＩＤ１７３でまとめているため、通知先ＩＤ１７４は、複数の通知先を含む場合もある。例えば、図５の１行目のレコードは、通知先がｓｕｂ２０ａ、ｓｕｂ２０ｃ、及び、ｓｕｂ２０ｅであることを示している。ただし、本実施の形態に係る情報通知ノード１０は、これに限られず、通知先ごとのレコードとしてもよい。
【０１２０】
負荷担当１７５は、自ノードでイベントを通知するか否かを示している。負荷担当１７５は、自ノードで通知する場合を「Ｔ」、通知しない場合を「Ｆ」として示す。
【０１２１】
前ノード転送１７６は、後ほど詳細に説明する負荷分散のために前ノードに処理を委譲（通知の代行を依頼）しているか否かを示している。前ノード転送１７６が「Ｔ」の場合、情報通知ノード１０は、処理を委譲している。「Ｆ」の場合、情報通知ノード１０は、処理を委譲していない。
【０１２２】
図５に示す負荷担当１７５及び前ノード転送１７６は、初期状態として、すべてを解除した状態となっている。
【０１２３】
なお、図５に示す負荷分散管理テーブル１７１は、図４を用いて説明した動作に基づいて、情報通知ノード１０が受け取った６個のサブスクリプションを、前ノードＩＤ１７３に基づいて、３個のレコードにまとめて保持した例を示している。
【０１２４】
図６は、図４を用いて説明したサブスクリプションの転送動作に基づいて、情報通知ノード１１が作成又は更新した負荷分散管理テーブル１７１の一例を示す図である。
【０１２５】
各項目は、図５と同様のため、詳細な説明は、省略する。
【０１２６】
情報通知ノード１１は、２つのサブスクリプションを受け取ったため、負荷分散管理テーブル１７１も２つのレコードを保持している。
【０１２７】
なお、図６に示す負荷担当１７５及び前ノード転送１７６は、初期状態として、すべてを解除した状態となっている。
【０１２８】
図７は、本実施の形態に係るサブスクリプションテーブル１５１の一例を示す図である。
【０１２９】
本実施の形態に係る情報通知ノード１０のサブスクリプションテーブル１５１は、サブスクリプション条件１５２と、通知先ＩＤ１５３と、負荷委譲済１５４とを含む。なお、図７では、各行がレコードとなっている。
【０１３０】
サブスクリプション条件１５２は、サブスクリプションが含むサブスクリプション条件を保持する。つまり、サブスクリプション条件１５２は、サブスクリプションに基づき、イベントを通知する管理担当の情報通知ノードのノードＩＤとイベントとの条件を含む。なお、本実施の形態の情報通知ノード１０は、管理対象サブスクリプションをサブスクリプションテーブル１５１に保持する。つまり、情報通知ノード１０は、自ノードが通知するサブスクリプションをサブスクリプションテーブル１５１に保持する。そのため、サブスクリプション条件１５２のイベントを通知するノードＩＤは、自ノードのＩＤである。
【０１３１】
通知先ＩＤ１５３は、イベントの通知先の装置を示す識別子（ＩＤ）である。既に説明したとおり、本実施の形態では、サブスクライバ２０と通知先は同じとして説明するため、通知先ＩＤ１５３は、サブスクリプションを登録したサブスクライバＩＤとなる。なお、本実施の形態に係るサブスクリプションテーブル１５１は、同じサブスクリプション条件１５２を備えたレコードをまとめている。そのため、図７に示す通知先ＩＤ１５３は、複数の通知先（サブスクライブ）を保持している。ただし、本実施の形態に係る情報通知ノード１０は、これに限られず、通知先ごとのレコードとしてもよい。
【０１３２】
なお、図７の１行目のレコードが、図４を用いて説明したサブスクリプションに相当するレコードであり、通知先とし、ｓｕｂ２０ａ乃至ｓｕｂ２０ｆを保持している。
【０１３３】
負荷委譲済１５４は、サブスクリプションで指定された管理対象イベントの通知を、別のノードに依頼済か否かを示す情報である。図７において「Ｔ」は依頼済、「Ｆ」は未依頼つまり自ノードで通知することを示す。
【０１３４】
（情報通知ノードでの負荷分散の設定）
次に情報通知ノード１０における負荷分散の設定動作について図面を参照して説明する。
【０１３５】
まず、イベント制御部１４０における負荷分散の設定動作について図面を参照して説明する。
【０１３６】
図８は、イベント制御部１４０の負荷分散の設定動作の一例を示すフロー図である。
【０１３７】
イベント制御部１４０は、所定のタイミングで（例えば、定期的、又は、サブスクリプションを受信後）、サブスクリプションテーブル１５１の各レコードに基づいて次の示す動作を開始する（ステップ２００１)。
【０１３８】
イベント制御部１４０は、各レコードのイベントの通知の負荷が自ノードに対して大きいか否かを判定する（ステップ２００２）。イベント制御部１４０は、いろいろな条件に基づいて判定できる。例えば、イベント制御部１４０は、判定の条件として、サブスクリプションテーブル１５１のレコードに登録されている通知先の数、サブスクリプション又はサブスクリプションに対するイベントの発生頻度、自ノードのＣＰＵ(central process unit)の処理状態又は通信回線の負荷状態、通知先までの距離（ホップ数）、若しくは、自ノードのメモリの使用量、又は、これらの予想値を用いることができる。なお、本実施の形態では、一例として、サブスクリプションテーブル１５１に登録されている通知先の数を条件とした場合について説明する。そのため、イベント制御部１４０は、サブスクリプションテーブル１５１のレコードに登録されている通知先の数（本実施の形態では、サブスクライブの数）を所定の閾値と比較する。例えば、図７の１行目で示すレコードの通知先の数は、「６」である。そのため、閾値が「６」未満の値の場合、通知先の数は、閾値を超え、負荷が大きい（ステップ２００２でyes）と判定される。反対に、閾値が「６」以上の値の場合、通知先の数は、閾値を超えず、負荷が大きくない（ステップ２００２でno）と判定される。
【０１３９】
負荷が大きくない場合（ステップ２００２でno）、負荷分散は、必要ない。そのため、イベント制御部１４０は、自ノードでの処理、つまり、サブスクリプションテーブル１５１の負荷委譲済１５４を委譲しない（Ｆ）に設定する（ステップ２００６）。
【０１４０】
負荷が大きい場合（ステップ２００２でyes）、負荷分散は、必要である。
【０１４１】
そこで、イベント制御部１４０は、前ノードに、閾値を越えたレコードの負荷の分担を依頼するため、サブスクリプション条件１５２を含む負荷の分担の依頼を負荷分散制御部１６０に送付する（ステップ２００３）。
【０１４２】
その後、イベント制御部１４０は、負荷分散制御部１６０の処理の終了を待つ（ステップ２００４）。
【０１４３】
負荷分散制御部１６０の処理が終了すると、イベント制御部１４０は、サブスクリプションテーブル１５１の負荷委譲済１５４を委譲済み（Ｔ）に設定する。
【０１４４】
例えば、図７の１行目のレコードは、負荷を委譲済みであり、２行目のレコードは委譲していないことを示す。
【０１４５】
このような動作に基づき、イベント制御部１４０は、負荷分散を設定する。
【０１４６】
次に、負荷分散制御部１６０の負荷分散の設定動作について図面を参照して説明する。
【０１４７】
図９は、負荷分散制御部１６０の負荷分散の設定動作の一例を示すフロー図である。
【０１４８】
負荷分散制御部１６０は、イベント制御部１４０から負荷分散の設定の依頼を受け取り、処理を開始する（ステップ２１０１）。
【０１４９】
負荷分散制御部１６０は、イベント制御部１４０の依頼に含まれるサブスクリプション条件に一致する負荷分散管理テーブル１７１の各レコードについて以下の動作を繰り返す（ステップ２１０２）。
【０１５０】
まず、負荷分散制御部１６０は、所定の条件に基づき、各レコードの処理を前ノードに依頼（委譲）するか否かを判定する（ステップ２１０３）。この判定に用いる所定の条件とは、負荷分散制御部１６０が、委譲するイベントの範囲又は委譲しないイベントの範囲を決めるための条件である。例えば、負荷分散制御部１６０は、予め通知先数の閾値を保持しておき、閾値を越える数の通知を委譲するように判定してもよく、サブスクリプション条件が一致するレコードの通知のすべてを委譲しても良い。ただし、サブスクライバから直接受け取ったサブスクリプションは前ノードがない。そのため、サブスクライバから直接受け取ったサブスクリプションの場合、負荷分散制御部１６０は、自ノードで通知すると判定する。
【０１５１】
判定の結果、委譲しない場合（ステップ２１０３でno）、負荷分散制御部１６０は、負荷分散管理テーブル１７１の負荷担当１７５を自ノードに設定する（ステップ２１０６）。具体的には、負荷分散制御部１６０は、負荷分散管理テーブル１７１の負荷担当１７５を「Ｔ」、前ノード担当を「Ｆ」に設定する。
【０１５２】
通知を委譲する場合（ステップ２１０３でyes）、負荷分散制御部１６０は、通知の委譲を依頼する代行依頼メッセージ２０１を作成して、前ノードＩＤ１７３が保持している前ノードに送付する（ステップ２１０４）。なお、代行依頼メッセージ２０１は、いろいろな形式を採用することができるが、本実施の形態の代行依頼メッセージ２０１は、一例として、委譲するレコードのサブスクリプション条件１７２と、通知先ＩＤ１７４とを含むとする。
【０１５３】
代行依頼メッセージ２０１を送付後、負荷分散制御部１６０は、負荷分散管理テーブル１７１の前ノード転送１７６に「Ｔ」、負荷担当１７５に「Ｆ」を設定する（ステップ２１０５）。ただし、レコードの一部を委譲する場合、負荷分散制御部１６０は、対象のレコードを委譲するレコードと委譲しないレコードとに分け、委譲しないレコードはステップ２１０６と同様に自ノード担当に設定し、委譲するレコードはステップ２１０５の同様に設定する。
【０１５４】
負荷分散制御部１６０は、依頼されたサブスクリプションの条件に一致する全てのレコードに対して、ここまで説明した動作を繰り返す。
【０１５５】
処理の対象となる全てのレコードの処理が終了すると、負荷分散制御部１６０は、処理の終了をイベント制御部１４０に通知する（ステップ２１０７）。
【０１５６】
図１０は、図９を用いて説明した動作の終了後の負荷分散管理テーブル１７１の一例を示す図である。図１０に示す負荷分散管理テーブル１７１は、図５に示す負荷分散管理テーブル１７１の１行目のレコードを閾値に基づいて一部を委譲し、２行目のレコードをすべて委譲した場合についての一例である。一部を委譲するため、図５の１行目のレコードは、図１０において、自ノードで通知する１行目のレコードと委譲する２行目のレコードとに分かれている。そして、図１０に示す負荷分散管理テーブル１７１において１行目のレコードの通知先（ｓｕｂ２０ａ）及び自ノードがサブスクリプションを受け取った４行目の通知先（ｓｕｂ２０ｆ）は、自ノードで通知するため、負荷担当１７５が「Ｔ」、前ノード転送１７６が「Ｆ」となっている。また、２行目と３行目のレコードの通知先（ｓｕｂ２ｂ−ｓｕｂ２ｅ）は代行依頼メッセージ２０１を送付し委譲済みのため、負荷担当１７５は、「Ｆ」、前ノード転送１７６は、「Ｔ」となっている。
【０１５７】
（前ノードでの負荷委譲の設定）
次に、代行依頼メッセージ２０１を受けた前ノード（例えば、情報通知ノード１１）の動作について図面を参照して説明する。なお、この動作は、本実施の形態に係る情報通知ノードで同様に動作するが、ここでは、情報通知ノード１１を用いて説明する。
【０１５８】
図１１は、代行依頼メッセージ２０１を受信した情報通知ノード１１の動作の一例を示すフロー図である。
【０１５９】
代行依頼メッセージ２０１を受信した情報通知ノード１１の情報転送部１１０は、代行依頼メッセージ２０１を負荷分散制御部１６０に送る（ステップ３００１）。
【０１６０】
代行依頼メッセージ２０１を受け取った負荷分散制御部１６０は、代行依頼メッセージ２０１に含まれるサブスクリプション条件と負荷分散管理テーブル１７１のサブスクリプション条件とを比較し、一致したレコードに関して次に示す動作を繰り返す（ステップ３００２）。
【０１６１】
負荷分散制御部１６０は、自ノードで代行依頼メッセージ２０１の委譲を受けて通知を担当するか、さらに前のノードに委譲するかを判定する（ステップ３００３）。この判定として、負荷分散制御部１６０は、例えば、図９を用いて説明したステップ２１０３と同様に判定すればよい。
【０１６２】
負荷を前のノードに委譲する場合（ステップ３００３でyes）、負荷分散制御部１６０は、さらに前のノード（前々ノード）に代行依頼メッセージ２０１を送信する（ステップ３００４）。
【０１６３】
さらに、負荷分散制御部１６０は、負荷分散管理テーブル１７１の対応するレコードの前ノード転送１７６を「Ｔ」、負荷担当１７５を「Ｆ」に設定する（ステップ３００５）。
【０１６４】
一方、自ノードで通知を担当する場合（ステップ３００３でno）、負荷分散制御部１６０は、対応するレコードの負荷担当１７５を「Ｔ」、前ノード転送１７６を「Ｆ」に設定する（ステップ３００６）。
【０１６５】
このような動作に基づき、情報通知ノード１１は、受け取った代行依頼メッセージ２０１に対して、負荷分散管理テーブル１７１に基づき自ノードでの対応又は委譲を設定する。
【０１６６】
図１２は、代行依頼メッセージ２０１を受けた後の情報通知ノード１１の負荷分散管理テーブル１７１の一例を示す図である。図１２の１行目のレコードは、自ノードで担当する場合のレコードである。そのため、負荷担当１７５は「Ｔ」であり、前ノード転送１７６は「Ｆ」となっている。また、２行目のレコードは、委譲した場合の一例である。そのため、負荷担当１７５は「Ｆ」、前ノード転送１７６は「Ｔ」である。つまり、図１２に示す負荷分散管理テーブル１７１は、自ノードがｓｕｂ２０ｅにイベントを通知し、ｓｕｂ２０ｃの通知を委譲していることを示している。
【０１６７】
（対象ノードでのイベントの通知動作）
次に、対象ノード（ランデブーノード）である情報通知ノード１０が、イベントを受け取った場合の動作、つまり管理対象イベントを受け取った管理担当である情報通知ノード１０の動作について図面を参照して説明する。
【０１６８】
図１３は、管理対象イベントを受け取った情報通知ノード１０の動作の一例を示すフロー図である。
【０１６９】
パブリッシャ３０からpub/subネットワーク４０にイベントがパブリッシュ（発信、入力）されると、pub/subネットワーク４０は、管理担当の情報通知ノード１０にイベントを転送する。
【０１７０】
イベントを受信した情報通知ノード１０の情報転送部１１０は、イベントをイベント制御部１４０に送る（ステップ４００１）。
【０１７１】
イベントを受け取ったイベント制御部１４０は、サブスクリプションテーブル１５１に保持されている各レコードについて次に説明する処理を繰り返す（ステップ４００２）。
【０１７２】
イベント制御部１４０は、受け取ったイベントが各レコードのサブスクリプション条件１５２と一致するか否か、つまり対象イベントであるか否かを確認する（ステップ４００３）。
【０１７３】
対象イベントで無い場合（ステップ４００３でno）、イベント制御部１４０は、特に動作せずに次のレコードの処理に移行する。
【０１７４】
対象イベントの場合（ステップ４００３でyes）、イベント制御部１４０は、対象イベントに対応するサブスクリプションテーブル１５１のレコードの負荷委譲済１５４を確認する（ステップ４００４）。
【０１７５】
負荷委譲済１５４が負荷委譲していない（Ｆ）の場合（ステップ４００４でno）、情報通知ノード１０は、通知先ＩＤ１５３にイベントを通知（notify）する（ステップ４００５）。
【０１７６】
負荷を委譲済み（Ｔ）の場合（ステップ４００４でyes）、イベント制御部１４０は、負荷分散制御部１６０に通知の代行（負荷分散）を依頼する（ステップ４００６）。
【０１７７】
そして、イベント制御部１４０は、負荷分散制御部１６０からの結果を待つ。負荷分散制御部１６０からの結果を受け取ったイベント制御部１４０は、結果の内容を確認する（ステップ４００７）。
【０１７８】
判定の結果に負荷委譲でない、つまり自ノードでの通知が含まれる場合（ステップ４００７でno）、イベント制御部１４０は、通知するとの結果となったイベントを通知する（ステップ４００５）。
【０１７９】
判定の結果がすべて負荷委譲の場合（ステップ４００７でyes）、イベント制御部１４０は、処理を終了し、次のレコードの処理に移行する。
【０１８０】
図１４は、図１３で示すステップ４００６においてイベントの負荷分散を依頼された負荷分散制御部１６０の動作の一例を示すフロー図である。
【０１８１】
負荷分散の依頼を受けた（ステップ４１０１）負荷分散制御部１６０は、負荷分散管理テーブル１７１のサブスクリプション条件１７２が負荷分散の依頼のサブスクリプション条件と一致するレコードついて、次に示す動作を繰り返す（ステップ４１０２）。
【０１８２】
負荷分散制御部１６０は、負荷を委譲済みか否か、つまり、負荷分散管理テーブル１７１の各レコードの負荷担当１７５を確認する（ステップ４１０３）。
【０１８３】
自ノードで負荷を担当する場合（ステップ４１０３でyes）、負荷分散制御部１６０は、イベント制御部１４０に、そのレコードに対応するイベントについて自ノードで通知するとの結果を返す（ステップ４１０４）。この結果を受けたイベント制御部１４０は、既に説明したとおり、イベントを通知する。負荷分散制御部１６０は、イベント制御部１４０に通知後、次のレコードの処理に移行する。
【０１８４】
自ノードで負荷を担当しない場合（ステップ４１０３でno）、負荷分散制御部１６０は、レコードの前ノード転送１７６を確認し、前ノードに委譲済みか否か、つまり、前ノードに負荷の代行を依頼しているか否かを確認する（ステップ４１０５）。
【０１８５】
負荷を委譲済みの場合（ステップ４１０５でyes）、負荷分散制御部１６０は、情報転送部１１０を介して、前ノードＩＤ１７３に登録されている前ノードに代行して通知する依頼（以下、通知（notify）依頼メッセージ２０２と称す）を送信する（ステップ４１０６）。通知依頼メッセージ２０２は、いろいろな形式及び含む情報を採用することができる。本実施の形態に係る通知依頼メッセージ２０２は、一例として、通知の代行を依頼するイベントに関する情報（又は、サブスクリプション条件）を含む。
【０１８６】
負荷を委譲済みでない場合（ステップ４１０５でno）は、本来発生しない状態である。そのため、負荷分散制御部１６０は、特に動作しなくても良い。
【０１８７】
通知依頼メッセージ２０２を送信後、又は、負荷を委譲済みで無い場合、負荷分散制御部１６０は、次のレコードの動作に移行する。
【０１８８】
一致するすべてのレコードについて動作が終了すると、負荷分散制御部１６０は、イベント制御部１４０に負荷分散の終了を通知し（ステップ４１０７）、処理を終了する。
【０１８９】
なお、負荷分散制御部１６０は、自ノードでのイベントの通知を、まとめて最後にイベント制御部１４０に連絡しても良い。ただし、本実施の形態の説明のように、負荷分散制御部１６０がレコードごとに連絡すると、イベント制御部１４０は、まとめて最後に連絡を受ける場合に比べ、イベントの通知を早く開始することができる。
【０１９０】
（前ノードでのイベント通知動作）
次に、通知依頼メッセージ２０２を受け取った前ノード（この説明では、情報通知ノード１１とする）の動作について説明する。
【０１９１】
図１５は、通知依頼メッセージ２０２を受信した前ノード（情報通知ノード１１）の動作の一例を示すフロー図である。
【０１９２】
前ノードである情報通知ノード１１の情報転送部１１０は、イベントの管理担当である情報通知ノード１０から通知依頼メッセージ２０２を受ける（ステップ５００１）。
【０１９３】
通知依頼メッセージ２０２を受けた情報転送部１１０は、通知依頼メッセージ２０２を負荷分散制御部１６０に送付する。
【０１９４】
通知依頼メッセージ２０２を受け取った負荷分散制御部１６０は、通知依頼メッセージ２０２に含まれるサブスクリプション条件と一致するサブスクリプション条件１７２含むレコードを、負荷分散管理テーブル１７１から検索する。負荷分散制御部１６０は、一致したレコードに対して次に示す動作を繰り返す（ステップ５００２）。
【０１９５】
負荷分散制御部１６０は、各レコードの負荷担当１７５に基づき、自ノードが負荷の担当か否かを判定する（ステップ５００３）。
【０１９６】
負荷の担当の場合（ステップ５００３でyes）、負荷分散制御部１６０は、イベント制御部１４０にイベントの通知を依頼する。依頼を受けたイベント制御部１４０は、通知依頼メッセージ２０２で依頼されたイベントを通知する（ステップ５００４）。
【０１９７】
負荷の担当でない場合（ステップ５００３でno）、負荷分散制御部１６０は、負荷分散管理テーブル１７１の前ノード転送１７６を参照し、負荷を委譲、つまり、通知依頼メッセージ２０２を送信するか否かを判定する（ステップ５００５）。
【０１９８】
負荷を委譲する場合（ステップ５００５でyes）、負荷分散制御部１６０は、負荷分散管理テーブル１７１に基づき、さらに前のノード（前々ノード）に通知依頼メッセージ２０２を送信する。
【０１９９】
負荷を委譲しない場合（ステップ５００６でno）、負荷分散制御部１６０は、特に動作せずに終了する。
【０２００】
（ネットワークにおけるイベント通知の一例）
イベントの通知の代行について図面を参照してさらに説明する。
【０２０１】
図１６は、pub/subネットワーク４０におけるイベントの通知の代行の一例を示す図である。
【０２０２】
図１６に示す小円は、図４と同様に情報通知ノードを示している。また、情報通知ノード１０（ＩＤ＝１０００）は、図７に示すサブスクリプションテーブル１５１及び図１０に示す負荷分散管理テーブル１７１を備える。さらに、情報通知ノード１１（ＩＤ＝０１１１）は、図１２に示す負荷分散管理テーブル１７１を備えるとする。また、情報通知ノード１２及び情報通知ノード１３は、自ノードでイベントを通知するとする。
【０２０３】
図１６に示すように、パブリッシャ３０（ｐｕｂ３０）が、図７の１行目のレコードのサブスクリプション条件１５２に一致するイベントが発行したとする。
【０２０４】
このイベントは、情報通知ノード１６が受け、イベントの管理担当である情報通知ノード１０に転送する。
【０２０５】
そこで、まず、情報通知ノード１０の動作について説明する。
【０２０６】
イベントを受け取った情報通知ノード１０のイベント制御部１４０は、イベントが図７に示すサブスクリプションテーブル１５１の１行目のレコードのサブスクリプション条件１５２と一致すると判定する（図１３のステップ４００３）。そして、イベント制御部１４０は、１行目のレコードの負荷委譲済１５４を確認し（図１３のステップ４００４）、委譲済みのため、負荷分散制御部１６０に負荷の分散を依頼する（図１３のステップ４００６）。
【０２０７】
依頼を受けた負荷分散制御部１６０は、図１０に示す負荷分散管理テーブル１７１に基づき、１行目のレコード（通知先がｓｕｂ２０ａ）と４行目のレコード（通知先がｓｕｂ２０ｆ）については、イベント制御部１４０にイベントの通知を連絡する（図１４のステップ４１０４）。
【０２０８】
この結果に基づき、イベント制御部１４０は、ｓｕｂ２０ａとｓｕｂ２０ｆにイベントを通知する（図１３のステップ４００５）。
【０２０９】
また、負荷分散制御部１６０は、負荷分散管理テーブル１７１の２行目のレコード（通知先がｓｕｂ２０ｃ、２０ｅ）について、前ノードＩＤ１７３に保持されているノード０１１１（第１の前ノードである情報通知ノード１１）に通知依頼メッセージ２０２を送付する（図１４のステップ４１０６）。
【０２１０】
同様に、負荷分散制御部１６０は、負荷分散管理テーブル１７１の３行目のレコード（通知先がｓｕｂ２０ｂ、２０ｄ）について、ノード０１１０（第２の前ノードである情報通知ノード１３）に通知依頼メッセージ２０２を送付する（図１４のステップ４１０６）。
【０２１１】
このように情報通知ノード１０は、自ノードでのイベントを通知し、通知の代行を依頼する。
【０２１２】
次に、情報通知ノード１１の動作について説明する。
【０２１３】
通知依頼メッセージ２０２を受け取った情報通知ノード１１の負荷分散制御部１６０は、図１２に示す負荷分散管理テーブル１７１に基づき、１行目のレコード（通知先がｓｕｂ２０ｅ）については、イベント制御部１４０にイベントの通知を連絡する。また、情報通知ノード１１の負荷分散制御部１６０は、２行目のレコード（通知先がｓｕｂ２０ｃ）について、前ノードＩＤ１７３に保持されているノード０１０１（前々ノードである情報通知ノード１２）に通知依頼メッセージ２０２を送る。
【０２１４】
情報通知ノード１２及び情報通知ノード１３は、通知依頼メッセージ２０２で委譲された通知を自ノードで通知する。つまり、情報通知ノード１２は、情報通知ノード１１から依頼されたｓｕｂ２０ｃにイベントを通知する。情報通知ノード１３は、情報通知ノード１０から依頼されたｓｕｂ２０ｂ及びｓａｂ２０ｄにイベントを通知する。
【０２１５】
各情報通知ノードと通知先のサブスクライバ２０（ｓｕｂ２０ａ−ｓｕｂ２０ｆ）との対応をまとめると次のようになる。
【０２１６】
情報通知ノード１０：ｓｕｂ２０ａ、ｓｕｂ２０ｆ
情報通知ノード１１：ｓｕｂ２０ｅ
情報通知ノード１２：ｓｕｂ２０ｃ
情報通知ノード１３：ｓｕｂ２０ｂ、ｓｕｂ２０ｄ
このように、本実施の形態に係る情報通知ノード１０は、負荷に基づき設定したサブスクリプションテーブル１５１及び負荷分散管理テーブル１７１を用いて、前ノードに情報（イベント）の通知、つまり負荷の代行を依頼する。また、依頼を受けた情報通知ノード１１も、自ノードの負荷に基づき、自ノードがイベントを通知するか、通知の代行を依頼するかを判定し、負荷の代行を依頼できる。
【０２１７】
（サブスクリプションの解除）
次に負荷分散を設定後、さらにサブスクリプションを受けた場合、又は、サブスクリプションの解除（以下、解除通知と称す）を受けた場合の情報通知ノード１０に動作について図面を参照して説明する。
【０２１８】
図１７は、負荷分散を設定後にサブスクリプション又は解除通知を受け取ったイベント制御部１４０の動作の一例を示すフロー図である。
【０２１９】
サブスクリプションを受け取ったイベント制御部１４０は、既にサブスクリプション条件１５２が登録されている場合に、以下で説明するように動作する。サブスクリプション条件１５２が登録されていない場合は、イベント制御部１４０は、既に図８を用いて説明したのと同様に動作すればよい。
【０２２０】
イベント制御部１４０は、登録済みのレコードについて以下に説明する動作を繰り返す（ステップ６００１）。
【０２２１】
イベント制御部１４０は、受け取ったサブスクリプション又は解除通知に基づきサブスクリプションテーブル１５１に保存しているレコードを更新する。更新後、イベント制御部１４０は、自ノードの負荷状況を判定する（ステップ６００２）。
【０２２２】
負荷が重くない場合（ステップ６００２でno）、イベント制御部１４０は、負荷の委譲済みか否かを判定する（ステップ６００３）。
【０２２３】
負荷を委譲済みでない場合（ステップ６００３でno）、イベント制御部１４０は、特に動作しないで終了する。
【０２２４】
負荷を委譲済みの場合（ステップ６００３でyes）、イベント制御部１４０は、負荷分散制御部１６０に、負荷分散の解除を依頼する（ステップ６００４）。
【０２２５】
その後、イベント制御部１４０は、負荷分散制御部１６０の処理の終了を待つ（ステップ６００５）。
【０２２６】
負荷分散制御部１６０の処理が終了するとイベント制御部１４０は、サブスクリプションテーブル１５１のデータを自ノードの負荷に変更（ステップ６００６）し、処理を終了する。
【０２２７】
負荷が大きい場合（ステップ５００２でyes）、イベント制御部１４０は、負荷分散制御部１６０に、負荷分散の再設定を依頼する（ステップ６００７）。負荷分散制御部１６０の再設定動作は、図９を用いて説明した動作と同様に動作すればよく、詳細な説明は、省略する。
【０２２８】
再設定の依頼後、イベント制御部１４０は、負荷分散制御部１６０の処理の終了を待つ（ステップ６００８）。
【０２２９】
負荷分散制御部１６０の処理の終了後、イベント制御部１４０は、サブスクリプションテーブル１５１を委譲済みに設定する（ステップ６００９）。
【０２３０】
次に、負荷分散の解除の依頼を受けた、負荷分散制御部１６０の動作について図面を参照して説明する。
【０２３１】
図１８は、負荷分散制御部１６０の動作の一例を示すフロー図である。
【０２３２】
負荷分散の解除の依頼を受けた（ステップ６１０１）負荷分散制御部１６０は、依頼の対応する負荷分散管理テーブル１７１のレコードに関して、次に示す動作を繰り返す（ステップ６１０２）。
【０２３３】
負荷分散制御部１６０は、負荷分散管理テーブル１７１の負荷担当１７５に基づき、負荷の委譲済みか否かを判定する（ステップ６１０３）。
【０２３４】
負荷を委譲済みの場合（ステップ６１０３でyes）、負荷分散制御部１６０は、代行の解除を依頼する代行解除メッセージ２０３を作成して、委譲先のノード（例えば、情報通知ノード１１）に送信する（ステップ６１０４）。通知後、負荷分散制御部１６０は、負荷分散管理テーブル１７１の情報を更新する（ステップ６１０５）。具体的に説明すると、負荷分散制御部１６０は、負荷担当を解除、つまり、前ノード転送１７６を「Ｆ」、負荷担当１７５を「Ｆ」と設定する。ここで、負荷分散制御部１６０は、まとめられるレコードをまとめるようにしてもよい。
【０２３５】
負荷を委譲済みで無い場合（ステップ６１０３でno）、負荷分散制御部１６０は、特に動作の必要は無い。ただし、安全のため、負荷分散制御部１６０は、ステップ６１０５と同様に負荷担当の解除を設定してもよい。
【０２３６】
負荷分散管理テーブル１７１の更新後、負荷分散制御部１６０は、解除の終了をイベント制御部１４０に通知し（ステップ６１０６）、処理を終了する。
【０２３７】
続いて、代行解除メッセージ２０３を受けた委譲先（例えば、情報通知ノード１１）の動作について図面を参照して説明する。
【０２３８】
図１９は、代行解除メッセージ２０３を受けた情報通知ノード１１の負荷分散制御部１６０の動作の一例を示すフロー図である。
【０２３９】
代行解除メッセージ２０３を受けた（ステップ７００１）情報通知ノード１１の負荷分散制御部１６０は、依頼に対応する負荷分散管理テーブル１７１のレコードに関して、次に示す動作を繰り返す（ステップ７００２）。
【０２４０】
負荷分散制御部１６０は、負荷分散管理テーブル１７１の負荷担当１７５に基づき、負荷の委譲済みか否かを判定する（ステップ７００３）。
【０２４１】
負荷を委譲済みの場合（ステップ７００３でyes）、負荷分散制御部１６０は、委譲先のノード（例えば、情報通知ノード１２）に代行解除メッセージ２０３を送信する（ステップ７００４）。通知後、情報通知ノード１１は、負荷担当を解除するように各テーブルの情報を更新する（ステップ７００５）。
【０２４２】
負荷を委譲済みで無い場合（ステップ７００３でno）、負荷分散制御部１６０は、特に何もせず終了する。ただし、安全のため、負荷分散制御部１６０は、ステップ７００５と同様に負荷担当の解除を設定してもよい。
【０２４３】
ここまで説明した動作に基づき、情報通知ノードは、負荷分担を解除する。
【０２４４】
なお、ここまでの説明において、代行依頼メッセージ２０１を受けた前ノード（例えば、情報通知ノード１１）が負荷を担当できない場合、前ノードは、さらに前々ノードに代行依頼メッセージ２０１を送って負荷の代行を依頼していた。しかし、本実施の形態に係る情報通知ノードは、これに限られるわけではない。
【０２４５】
例えば、負荷を担当できない前ノードは、自ノードで代行依頼メッセージ２０１を送信するのではなく、依頼元のノードに委譲拒否のメッセージを送り返しても良い。
【０２４６】
この委譲拒否のメッセージを受け取った情報通知ノードは、新たに別の情報通知ノードに代行依頼メッセージ２０１を送っても良い。
【０２４７】
さらに、本実施の形態に係る情報通知ノード１０の構成は、今まで説明した構成に限られるわけではない。本実施の形態に係る情報通知ノード１０は、いくつかの構成を１つの構成、例えば、イベント制御部１４０と負荷分散制御部１６０を合わせた構成を含んでもよい。
【０２４８】
また、本実施の形態に係る情報通知ノード１０の各構成は、さらに複数の構成に分けても良く、構成を別の装置に備え、ネットワークを介して接続したシステムとしてもよい。例えば、各テーブル保持部は、ネットワークを介して接続した外部の記憶装置に含まれてもよい。さらに、本実施の形態に係る情報通知ノード１０は、別装置の一部を構成してもよい。
【０２４９】
（別の構成）
図２０は、本実施の形態に係る情報通知ノードの別の構成の一例を示すブロック図である。
【０２５０】
図２０において図１と同じ構成は同じ番号を付して、詳細な説明は省略する。
【０２５１】
情報通知ノード１８は、ブレードサーバ（blade server）のように、所定の装置に組み込まれ、内部バスを用いて他の装置と接続している。情報通知ノード１８の情報転送部１１０は、イベント制御部１４０及び負荷分散制御部１６０に含まれるため、図２０において省略した。また、各テーブル保持部は、それぞれの保持部の回路が備える半導体記憶部にテーブルを保持するため、図２０において各テーブルの表示を省略した。
【０２５２】
このように構成された情報通知ノード１８のイベント制御部１４０及び負荷分散制御部１６０は、バスを介して他の装置（サブスクライバ２０など）と情報を送受信し、サブスクリプション及びイベントに関して情報通知ノード１０と同様に動作できる。そのため、情報通知ノード１８は、情報通知ノード１０と同様にイベントの通知を委譲できる。
【０２５３】
なお、情報通知ノード１８は、本実施の形態に最小構成である。
【０２５４】
このように本実施の形態に係る情報通知ノードは、情報（イベントを含む情報）を通知する装置の負荷の軽減を得ることができる。
【０２５５】
その理由は、本実施の形態に係る情報通知ノードは、保持しているサブスクリプション（受信登録）に基づいて自ノードの負荷を判定し、負荷が大きい場合、他の情報通知ノード（前ノード）に情報の通知の代行を依頼し、自ノードの情報の通知を削減できるためである。また、代行を依頼された情報通知ノードは、依頼された情報の通知を自ノードの負荷に基づき、さらに代行を依頼することができるため、代行を依頼された情報通知ノードも、自ノードに適切な負荷を代行できるためである。
【０２５６】
（第２の実施の形態）
第１の実施の形態に係る情報通知ノードは、各構成をコンピュータで実行するプログラムとして実現しても良い。
【０２５７】
さらに、第１の実施の形態に係る情報通知ノードの各構成は、コンピュータで実行するプログラムを記憶する記録媒体を含んでも良い。
【０２５８】
図２１は、第２の実施の形態に係る情報通知ノード１９の構成の一例を示す図である。
【０２５９】
情報通知ノード１９は、情報処理部５２０と、情報記憶部５３０と、通信部５１０とを含んでいる。
【０２６０】
情報処理部５２０は、ＣＰＵ（Central Process Unit）を含み、情報記憶部５３０が記憶しているプログラム５４０を実行する。そして、情報処理部５２０は、プログラム５４０に基づき、通信部５１０を介してサブスクライバ２０などと通信し、第１の実施の形態に係る情報通知ノード１０と同様に動作する。
【０２６１】
情報記憶部５３０は、図示しないハードディスク装置又はメモリ記憶装置など記憶装置を含み、情報処理部５２０が実行するプログラム５４０を記憶している。さらに、情報記憶部５３０は、プログラム５４０を保持する記憶媒体５５０を含んでも良い。なお、情報記憶部５３０は、情報処理部５２０が動作する場合の情報の一時保存記憶（ワークエリア）として動作しても良い。
【０２６２】
通信部５１０は、ネットワークと接続するための回路、例えばＮＩＣ（Network Interface Card）を含み、情報処理部５２０とサブスクライバ２０及びパブリッシャ３０などとの情報を中継する。
【０２６３】
このように第２の実施の形態に係る情報通知ノード１９は、第１の実施の形態に係る情報通知ノード１０と同様の効果を得ることができる。
【０２６４】
その理由は、第２の実施の形態に係る情報通知ノード１９の情報処理部５２０が、プログラム５４０に基づいて、第１の実施の形態の情報通知ノード１０と同様に動作することができるためである。
【０２６５】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【０２６６】
（付記）
（付記１）
イベントを含む情報の受信登録（サブスクリプション）を受け取り保持するサブスクリプションテーブル保持部と、
保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定するイベント制御部と、
前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する負荷分散管理テーブル保持部と、
前記イベント制御部が委譲すると判定した場合に、前記負荷分散管理テーブル保持部が保持する情報に基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第１のノードに送付し、委譲しない通知先については前記イベント制御部に前記情報の通知を依頼する負荷分散制御部とを含む情報通知ノード。
（付記２）
前記負荷分散制御部が、
第２のノードから情報の通知の代行の依頼を受け取ったとき、
前記第２のノードの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、第３のノードに前記情報の通知の代行の依頼を送信することを特徴とする付記１に記載の情報通知ノード。
（付記３）
前記負荷分散制御部が、
第２のノードから情報の通知の代行の依頼を受け取ったとき、
前記第２のノードからの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、前記第２のノードに代行の依頼の拒否を送付することを特徴とする付記１に記載の情報通知ノード。
（付記４）
前記負荷分散制御部が、
前記第１のノードに送付した前記情報の通知の代行の依頼に対して代行の依頼の拒否を受けた場合、第１のノードとは異なるノードに情報の通知の代行の依頼を送信することを特徴とする付記１乃至付記３のいずれかに記載の情報通知ノード。
（付記５）
前記負荷分散制御部が、
前記負荷分散管理テーブル保持部が保持する前記送信元に含まれるノードから、前記第１のノードを選択することを特徴とする付記１乃至付記４のいずれかに記載の情報通知ノード。
（付記６）
前記イベント制御部、又は、前記負荷分散制御部の前記自ノードで通知するか否かの判定する条件が、
前記サブスクリプションテーブル保持部が保持する前記受信登録の通知先の数、
前記配信依頼及び前記配信依頼に対するイベントの発生頻度、
自ノードの処理負荷、
通知先までの距離（ホップ数）、
自ノードのリソースの使用量、
又は
上記各条件の予想値
のいずれかを含むことを特徴とする付記１乃至付記５のいずれかに記載の情報通知ノード。
（付記７）
情報の受信登録を受け取り保持し、
保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定し、
前記受信登録の送信元の情報と前記情報を通知する通知先とを保持し、
委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第１のノードに送付し、委譲しない通知先については前記情報を通知する情報通知方法。
（付記８）
第２のノードから情報の通知の代行の依頼を受け取ったとき、
前記第２のノードの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、第３のノードに前記情報の通知の代行の依頼を送信することを特徴とする付記７に記載の情報通知方法。
（付記９）
第２のノードから情報の通知の代行の依頼を受け取ったとき、
前記第２のノードからの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、前記第２のノードに代行の依頼の拒否を送付することを特徴とする付記７に記載の情報通知方法。
（付記１０）
前記第１のノードに送付した前記情報の通知の代行の依頼に対して代行の依頼の拒否を受けた場合、第１のノードとは異なるノードに情報の通知の代行の依頼を送信することを特徴とする付記７乃至付記９のいずれかに記載の情報通知方法。
（付記１１）
保持する前記送信元に含まれるノードから、前記第１のノードを選択することを特徴とする付記７乃至付記１０のいずれかに記載の情報通知方法。
（付記１２）
前記自ノードで通知するか否かの判定する条件が、
前記サブスクリプションテーブル保持部が保持する前記受信登録の通知先の数、
前記配信依頼及び前記配信依頼に対するイベントの発生頻度、
自ノードの処理負荷、
通知先までの距離（ホップ数）、
自ノードのリソースの使用量、
又は
上記各条件の予想値
のいずれかを含むことを特徴とする付記７乃至付記１１のいずれかに記載の情報通知方法。
（付記１３）
情報の受信登録を受け取り保持する処理と、
保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定する処理と、
前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する処理と、
委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第１のノードに送付し、委譲しない通知先については前記情報を通知する処理とをコンピュータに実行させるプログラム。
（付記１４）
第２のノードから情報の通知の代行の依頼を受け取ったとき、
前記第２のノードの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、第３のノードに前記情報の通知の代行の依頼を送信すること
を特徴とする付記１３に記載のプログラム。
（付記１５）
第２のノードから情報の通知の代行の依頼を受け取ったとき、
前記第２のノードからの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、前記第２のノードに代行の依頼の拒否を送付すること
を特徴とする付記１３に記載のプログラム。
（付記１６）
前記第１のノードに送付した前記情報の通知の代行の依頼に対して代行の依頼の拒否を受けた場合、第１のノードとは異なるノードに情報の通知の代行の依頼を送信することを特徴とする付記１３乃至付記１５のいずれかに記載のプログラム。
（付記１７）
保持する前記送信元に含まれるノードから、前記第１のノードを選択することを特徴とする付記１３乃至付記１６のいずれかに記載のプログラム。
（付記１８）
前記自ノードで通知するか否かの判定する条件が、
前記サブスクリプションテーブル保持部が保持する前記受信登録の通知先の数、
前記配信依頼及び前記配信依頼に対するイベントの発生頻度、
自ノードの処理負荷、
通知先までの距離（ホップ数）、
自ノードのリソースの使用量、
又は
上記各条件の予想値
のいずれかを含むことを特徴とする付記１３乃至付記１７のいずれかに記載のプログラム。
（付記１９）
付記１乃至付記６のいずれかに記載の情報通知ノードと、
情報の受信登録を登録するサブスクライバと、
前記情報を発行するパブリッシャと
を含む情報配信システム。
【符号の説明】
【０２６７】
１    情報配信システム
９    情報配信システム
１０    情報通知ノード
１１    情報通知ノード
１２    情報通知ノード
１３    情報通知ノード
１４    情報通知ノード
１５    情報通知ノード
１６    情報通知ノード
１８    情報通知ノード
１９    情報通知ノード
２０    サブスクライバ
３０    パブリッシャ
４０    pub/subネットワーク
９０    pub/subネットワーク
１１０    情報転送部
１２０    ルーティング部
１３０    ルーティングテーブル保持部
１４０    イベント制御部
１５０    サブスクリプションテーブル保持部
１５１    サブスクリプションテーブル
１５２    サブスクリプション条件
１５３    通知先ＩＤ
１５４    負荷委譲済
１６０    負荷分散制御部
１７０    負荷分散管理テーブル保持部
１７１    負荷分散管理テーブル
１７２    サブスクリプション条件
１７３    前ノードＩＤ
１７４    通知先ＩＤ
１７５    負荷担当
１７６    前ノード転送
２０１    代行依頼メッセージ
２０２    通知依頼メッセージ
２０３    代行解除メッセージ
５１０    通信部
５２０    情報処理部
５３０    記憶部
５４０    プログラム
５５０    記憶媒体
【図１】
2012146113.tif 000003
【図２】
2012146113.tif 000004
【図３】
2012146113.tif 000005
【図４】
2012146113.tif 000006
【図５】
2012146113.tif 000007
【図６】
2012146113.tif 000008
【図７】
2012146113.tif 000009
【図８】
2012146113.tif 000010
【図９】
2012146113.tif 000011
【図１０】
2012146113.tif 000012
【図１１】
2012146113.tif 000013
【図１２】
2012146113.tif 000014
【図１３】
2012146113.tif 000015
【図１４】
2012146113.tif 000016
【図１５】
2012146113.tif 000017
【図１６】
2012146113.tif 000018
【図１７】
2012146113.tif 000019
【図１８】
2012146113.tif 000020
【図１９】
2012146113.tif 000021
【図２０】
2012146113.tif 000022
【図２１】
2012146113.tif 000023
【図２２】
2012146113.tif 000024
【図２３】
2012146113.tif 000025
【図２４】
2012146113.tif 000026