イベントを含む情報の受信登録サブスクリプションを受け取り保持するサブスクリプションテーブル保持部と、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定するイベント制御部と、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する負荷分散管理テーブル保持部と、前記イベント制御部が委譲すると判定した場合に、前記負荷分散管理テーブル保持部が保持する情報に基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第1のノードに送付し、委譲しない通知先については前記イベント制御部に前記情報の通知を依頼する負荷分散制御部とを含む情報通知ノード。前記負荷分散制御部が、第2のノードから情報の通知の代行の依頼を受け取ったとき、前記第2のノードの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、第3のノードに前記情報の通知の代行の依頼を送信することを特徴とする請求項1に記載の情報通知ノード。前記負荷分散制御部が、第2のノードから情報の通知の代行の依頼を受け取ったとき、前記第2のノードからの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、前記第2のノードに代行の依頼の拒否を送付することを特徴とする請求項1に記載の情報通知ノード。前記負荷分散制御部が、前記第1のノードに送付した前記情報の通知の代行の依頼に対して代行の依頼の拒否を受けた場合、第1のノードとは異なるノードに情報の通知の代行の依頼を送信することを特徴とする請求項1乃至請求項3のいずれかに記載の情報通知ノード。前記負荷分散制御部が、前記負荷分散管理テーブル保持部が保持する前記送信元に含まれるノードから、前記第1のノードを選択することを特徴とする請求項1乃至請求項4のいずれかに記載の情報通知ノード。前記イベント制御部、又は、前記負荷分散制御部の前記自ノードで通知するか否かの判定する条件が、前記サブスクリプションテーブル保持部が保持する前記受信登録の通知先の数、前記配信依頼及び前記配信依頼に対するイベントの発生頻度、自ノードの処理負荷、通知先までの距離ホップ数、自ノードのリソースの使用量、又は上記各条件の予想値のいずれかを含むことを特徴とする請求項1乃至請求項5のいずれかに記載の情報通知ノード。情報の受信登録を受け取り保持し、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定し、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持し、委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第1のノードに送付し、委譲しない通知先については前記情報を通知する情報通知方法。第2のノードから情報の通知の代行の依頼を受け取ったとき、前記第2のノードの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、第3のノードに前記情報の通知の代行の依頼を送信することを特徴とする請求項7に記載の情報通知方法。情報の受信登録を受け取り保持する処理と、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定する処理と、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する処理と、委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第1のノードに送付し、委譲しない通知先については前記情報を通知する処理とをコンピュータに実行させるプログラム。請求項1乃至請求項6のいずれかに記載の情報通知ノードと、情報の受信登録を登録するサブスクライバと、前記情報を発行するパブリッシャとを含む情報配信システム。しかし、特許文献3及び特許文献4に記載のシステムは、処理する装置を変更するものであり、イベントの通知の処理を引き継いだ装置での処理の負荷の量は、引き渡した装置の負荷と同様である。特許文献3及び特許文献4に記載のシステムは、イベントの通知を引き継いだ装置、つまり、イベントを通知する装置におけるイベントを通知する処理の負荷を削減できないという問題点があった。本発明の目的は、上記問題点を解決し、情報イベントを含む情報を通知notifyする装置ノードの負荷の軽減を提供することにある。本発明の情報通知ノードは、イベントを含む情報の受信登録サブスクリプションを受け取り保持するサブスクリプションテーブル保持部と、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定するイベント制御部と、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する負荷分散管理テーブル保持部と、前記イベント制御部が委譲すると判定した場合に、前記負荷分散管理テーブル保持部が保持する情報に基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第1のノードに送付し、委譲しない通知先については前記イベント制御部に前記情報の通知を依頼する負荷分散制御部とを含む。本発明の情報通知方法は、情報の受信登録を受け取り保持し、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定し、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持し、委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第1のノードに送付し、委譲しない通知先については前記情報を通知する。本発明のプログラムは、情報の受信登録を受け取り保持する処理と、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定する処理と、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する処理と、委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第1のノードに送付し、委譲しない通知先については前記情報を通知する処理とをコンピュータに実行させる。本発明の情報配信システムは、本発明の情報通知ノードは、イベントを含む情報の受信登録サブスクリプションを受け取り保持するサブスクリプションテーブル保持部と、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定するイベント制御部と、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する負荷分散管理テーブル保持部と、前記イベント制御部が委譲すると判定した場合に、前記負荷分散管理テーブル保持部が保持する情報に基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第1のノードに送付し、委譲しない通知先については前記イベント制御部に前記情報の通知を依頼する負荷分散制御部とを含む情報通知ノードと、情報の受信登録を登録するサブスクライバと、前記情報を発行するパブリッシャとを含む。本発明によれば、情報イベントを含む情報を通知notifyする装置ノードの処理の負荷を低減することができる。次に、本発明における実施の形態について図面を参照して説明する。まず、本実施の形態の説明における用語について整理する。イベントevent、出来事とは、センサの検出又は人の操作などに基づき発生する情報である。イベントは、センサの検出などイベントの基となる情報を受けた装置が、ネットワークに発信パブリッシュ、publish、登録又は入力とも称すする。ネットワークにイベントを発信する装置をパブリッシャpublisher、又は、pubと称す。パブリッシャが発信したイベントは、ネットワーク、具体的にはネットワークを構成する装置が受け取る。なお、本実施の形態に係るイベントは、イベント及びイベントに基づき生成又は発生した情報を含めてイベントと称す。イベントは、いろいろな情報を含んでも良い。本実施の形態に係るイベントイベントを含む情報とも称すは、一例としてイベントIDIdentification、識別子と、イベント情報とを含む。イベントIDは、イベントを一意に識別するための識別子である。例えば、イベントIDは、イベントの基となったセンサが検出したRFIDRadioFrequencyIDentificationにハッシュ関数を適用して求めたハッシュ値である。後ほど説明するように、このイベントIDに相当するキーkey、鍵を識別子として備える情報通知ノードが、イベントを通知notify、配信とも称すする。つまり、イベントIDは、イベントを識別すると共に、イベントを通知する情報通知ノードの判別に用いてもよい。イベント条件は、イベントに関する情報、例えば、イベントが発生した条件時間、場所、原因などを含む情報である。なお、本実施の形態に係る情報通知ノードは、イベントを用いて説明するが、本実施の形態に係る情報通知ノードが扱う情報は、イベントに限られるわけではない。本実施の形態に係る情報通知ノードが扱う情報は、例えば、データベースの情報でもよく、エキスパートシステムexpertsystemの情報でよい。サブスクリプションとは、通知配信を受けたい情報イベントを含む情報について、ネットワークに登録サブスクライブ、subscribeする情報受信登録である。サブスクリプション受信登録を登録する装置をサブスクライバsubscriber、又は、subと称す。サブスクライバがネットワークに登録したサブスクリプションは、後ほど説明するように、イベントを通知する情報通知ノードに転送される。サブスクリプションは、いくつかの情報を含んでいても良い。本実施の形態に係るサブスクリプションは、一例として、サブスクリプション条件と、サブスクライバIDと、通知先IDと、経由ノードIDとを含む。サブスクリプション条件は、サブスクリプションを通知するためのイベントに関する条件を含む情報である。なお、サブスクリプション条件が含むイベントに関する条件は、イベントの一部と一致すれば良い場合を含む。例えば、サブスクリプション条件が、イベントに関する条件として場所=東京を含む場合、場所=東京、事件=火事又は場所=東京、事件=地震などのイベントは、サブスクリプション条件と一致するイベントとしてもよい。また、サブスクリプション条件は、イベントを通知する情報通知ノードにサブスクリプションを転送するための情報、例えば、イベントIDに相当する情報を含む。サブスクライバIDは、サブスクリプションをネットワークに登録したサブスクライバを示す情報識別子である。通知先IDは、登録したサブスクリプションに基づいてイベントを通知する装置を示す情報識別子である。通知先IDで示される通知先の装置は、1つ又は複数でも良い。また、通知先の装置は、サブスクライバでもよい。つまり、サブスクリプションを登録したサブスクライバが、イベントを通知配信先となってもよい。なお、説明の便宜のため、本実施の形態に係るイベントの通知先の装置は、サブスクリプションを登録したサブスクライバとする。そのため、本実施の形態に係るサブスクリプションは、通知先IDを、サブスクライバIDで代用しても良い。経由ノードIDは、サブスクリプションを中継したノードの識別子である。各ノードは、サブスクリプションを受け取った際に、送付元のノードの識別子を経由ノードIDに設定する。ただし、経由ノードIDは、サブスクリプションを送信するときに送信元のノードが設定してもよい。また、本実施の形態に係る経由ノードIDは、経由したノードの識別子をすべて含んでいても良く、所定の範囲又は数のノードの識別子を含んでも良く、直前のノードの識別子を含むようにしても良い。pubsubネットワークとは、サブスクライバがサブスクリプションを登録し、パブリッシャがイベントを発信するネットワークである。また、pubsubネットワークを構成する装置は、イベントの通知を担当する情報通知ノードに、サブスクリプション及びイベントを転送する。さらに、pubsubネットワークは、情報通知ノードが作成するメッセージを転送する。なお、pubsubネットワークは、一般的なネットワークと同様に、情報を転送する装置の経路情報ルーティングテーブル:routingtable、経路表を含み、ルーティングテーブルを用いて情報を転送する。つまり、pubsubネットワークを構成するノードは、ルーティングテーブルに基づき、所定の装置にサブスクリプション、イベント、及び、メッセージを転送する。ノードnode、節点とは、通信路を介して相互に接続してpubsubネットワークを構成する装置である。ノードは、ルーティングテーブルに基づき情報の転送先を探索する。ノードは、この探索に、いろいろな方式を使用しても良い。ただし、本実施の形態では、説明の便宜のため、分散ハッシュテーブルDHT:DistributedHashTableを用いて説明する。そのため、各ノードは、DHTのために割り振られたキーとして識別子ノードIDを備える。既に説明しているが、本実施の形態に係るノードIDは、イベントIDに相当するキーである。つまり、本実施の形態に係るノードIDは、イベントIDのハッシュ値として説明する。なお、本実施の形態に係るノードは、キーとしてのノードIDを、1つの値に限らず、複数の値を保持しても良い。ただし、本実施の形態では、説明の便宜のため、各ノードは、1つのノードIDキーの値を持つとする。また、ノードは、既に説明した、情報の転送経路例えば、転送先及び/又は転送元を示す情報を保持するルーティングテーブルを含んでいる。なお、本実施の形態においてルーティングテーブルは、論理接続に基づくルーティンテーブルとして説明する。ただし、本実施の形態に係るノードは、物理的接続に基づくルーティングテーブルを含んでもよい。情報通知ノードは、サブスクリプション受信登録と情報イベントを含む情報とに基づき、情報イベントを含む情報を、サブスクリプションで指定された通知先通知先IDの装置に通知notify、配信するノードである。本発明の実施の形態に係るpubsubネットワークは、少なくとも一部に、情報通知ノードを含む。なお、情報通知ノードのように、サブスクリプション受信登録と情報イベントを含む情報とを用いて処理するノードをランデブーノードrendezvousnode、出会いノードと称する。本実施の形態に係る情報通知ノードは、後ほど説明するとおり、負荷の状態に応じて、情報イベントを含む情報の通知を他の情報通知ノードに委譲する。また、情報通知ノードは、他の情報通知ノードから依頼を受けて情報の通知を代行する。このような情報の通知の委譲及び代行のため、本実施の形態に係る情報通知ノードは、メッセージを送受信する。第1の実施の形態続いて、本発明における第1の実施の形態に係る情報通知ノード10について図面を参照して説明する。まず、本実施の形態に係る情報通知ノード10の構成について説明する。図1は、第1の実施の形態に係る情報通知ノード10の構成の一例を示すブロック図である。情報通知ノード10は、ネットワークを介し、図示しない情報配信システムを構成する他のノード、サブスクライバsub、及び、パブリッシャpubと情報例えば、サブスクリプション、又は、イベントを送受信する。そのため、情報通知ノード10は、情報転送部110と、ルーティング部120と、ルーティングテーブル保持部130と、イベント制御部140と、サブスクリプションテーブル保持部150と、負荷分散制御部160と、負荷分散管理テーブル保持部170とを含む。情報転送部110は、ネットワークを介し、情報通知ノード10の各部と、ネットワークに接続した他の装置他のノード、サブスクライバ、又は、パブリッシャとの情報の送受信を中継する。ルーティング部120は、ルーティングテーブル保持部130が保持するルーティングテーブル131に基づき、情報の転送先を探索ルックアップ、lookupし、情報転送部110を介して情報を転送する。ルーティングテーブル保持部130は、ルーティング部120が情報の転送先を探索するために用いるルーティングテーブル131を保持している。なお、ルーティング部120及びルーティングテーブル保持部130は、一般的なネットワークを構成する装置が用いるルーティングプロトコルroutingprotocolに基づいてルーティングテーブル131を保持及び更新すればよく、ルーティングテーブル131に関する詳細な説明は省略する。また、ルーティングテーブル131において、ノード装置の通過の数をホップhop数と称す。イベント制御部140は、受け取ったサブスクリプションに基づき、サブスクリプションテーブル保持部150が保持するサブスクリプションテーブル151を作成及び更新する。また、イベント制御部140は、サブスクリプションテーブル151に基づき、パブリッシャ又は他のノードから受け取ったイベントを、イベントの通知先本実施の形態ではサブスクライバに通知する。イベント制御部140の動作の詳細については、後ほど説明する。なお、自ノードでサブスクリプションテーブル151に保持し、イベントの通知の処理の対象となるサブスクリプションを、管理対象サブスクリプションと称す。また、管理対象サブスクリプションの対象となるイベントを管理対象イベントと称す。さらに、管理対象イベントを通知する情報通知ノード10を管理担当の情報通知ノードと称す。つまり、管理担当の情報通知ノード10が、管理対象サブスクリプションをサブスクリプションテーブル151に保持して、管理対象イベントを通知することとなる。サブスクリプションテーブル保持部150は、イベント制御部140が使用する管理対象サブスクリプションを含むサブスクリプションテーブル151を保持する。なお、本実施の形態に係るサブスクリプションテーブル151に保持される情報の組を、レコードrecordと称す。負荷分散制御部160は、負荷分散管理テーブル保持部170が保持する負荷分散管理テーブル171を作成及び更新する。さらに、負荷分散制御部160は、負荷分散管理テーブル171に基づき、情報通知ノード10の負荷分散処理を制御する。負荷分散制御部160の詳細な動作についても、後ほど説明する。負荷分散管理テーブル保持部170は、負荷分散制御部160が使用する負荷分散管理テーブル171を保持する。なお、負荷分散管理テーブル171に保持される組となった情報も、レコードと称す。次に、本実施の形態に係る情報通知ノード10を含む情報配信システム1の構成について説明する。図2は、情報通知ノード10を含む情報配信システム1の一例を示すブロック図である。情報配信システム1は、情報通知ノード10を含むpubsubネットワーク40と、サブスクライバ20と、パブリッシャ30とを含む。図2では、説明の便宜のため、サブスクライバ20とパブリッシャ30を1つとして示しているが、本実施の形態に係る情報配信システム1が含む、サブスクライバ20及びパブリッシャ30は1つに限らず、それぞれ2つ以上でも良い。なお、以下の説明において、各ノードの経路上での位置関係を明確にする場合、ランデブーノードとなる情報通知ノードを対象ノードと称す。そして、対象ノードにサブスクリプションを転送するノード、つまり、ルーティングテーブル131において前に登録されている情報通知ノードを前ノードと称す。さらに、前ノードにサブスクリプションを転送するノード、つまり、ルーティングテーブル131において前ノードの前に登録されている情報通知ノードを前々ノードと称す。なお、本実施の形態に係る、前とは、1つ前に限られず、2つ以上前でもよい。ただし、図2では、記載の便宜のため、前を1つ前として示す。そのため、図2において、情報通知ノード10が対象ノード、情報通知ノード11が前ノード、情報通知ノード12が前々ノードとなる。情報通知ノード10は、ルーティングテーブル131に基づいて前ノードを探索する。ただし、情報通知ノード10は、前ノードを、サブスクリプションに含まれる経由ノードIDを用いて探索してもよい。なお、本実施の形態に係る情報通知ノードは、同じ構成に限られないが、説明の便宜のため、以下の説明では、情報通知ノードは、同じ構成とする。そのため、各情報通知ノードの構成に付した番号は、図1の番号を参照する。また、情報通知ノードに共通する説明は、情報通知ノード10を用いて説明する。図2において、サブスクライバ20が、サブスクリプションをpubsubネットワーク40を登録subscribeする。情報通知ノード10乃至情報通知ノード12は、サブスクリプションから求めたキーを、ルーティングテーブル131で探索し、求めたキーを備える情報通知ノード例えば、図2に示す情報通知ノード10に転送する。サブスクリプションを管理する情報通知ノード例えば、図2に示す情報通知ノード10は、受け取ったサブスクリプションをサブスクリプションテーブル151に保持する。なお、既に説明しているが、サブスクリプションの経由ノードIDは、転送の際に順次追加される。次に、パブリッシャ30が、イベントをpubsubネットワーク40に入力publishする。イベントも、ルーティングテーブル131に基づき、情報通知ノード10に転送される。イベントを受け取った情報通知ノード10は、サブスクリプションで指定されている通知先本実施の形態ではサブスクライバ20に、イベントを通知notifyする。さらに、情報通知ノード10は、必要に応じ、前ノードである情報通知ノード11にイベントの通知の代行の依頼のメッセージを送信する。通知の代行の依頼のメッセージを受けた情報通知ノード11は、イベントを通知先サブスクライバに通知する。さらに、必要に応じ、情報通知ノード11は、前々ノードである情報通知ノード12にイベントの通知の代行の依頼のメッセージを送信する。次に情報通知ノード10の動作に詳細ついて図面を参照して説明する。まず、情報通知ノード10のサブスクリプションを受け取ったときの動作について説明する。図3は、情報通知ノード10がサブスクリプションを受けた場合の動作の一例を示すフロー図である。サブスクライバ20又は他のノードからサブスクリプションを受け取った情報通知ノード10の情報転送部110は、サブスクリプションをルーティング部120に送るステップ1001。サブスクリプションを受け取ったルーティング部120は、サブスクリプションの経由ノードIDに送信元の情報通知ノードの識別子IDを設定後、サブスクリプションを負荷分散制御部160に送る。サブスクリプションを受け取った負荷分散制御部160は、サブスクリプションに基づき、負荷分散管理テーブル保持部170が保持する負荷分散管理テーブル171を更新するステップ1002。なお、負荷分散制御部160にサブスクリプションを送るのはルーティング部120に限られず、情報転送部110が、負荷分散管理制御部160に送っても良い。サブスクリプションを負荷分散制御部160に送付後、ルーティング部120は、サブスクリプションが含むサブスクリプション条件に基づき、受け取ったサブスクリプションが管理対象サブスクリプションか否かを判定するステップ1003。自ノードの管理対象サブスクリプションでない場合ステップ1003でno、ルーティング部120は、ルーティングテーブル131に基づき、情報転送部110を介して、次のノードにサブスクリプションを転送するステップ1004。自ノードの管理対象サブスクリプションの場合ステップ1003でyes、ルーティング部120は、サブスクリプションをイベント制御部140に送る。サブスクリプションを受け取ったイベント制御部140は、受け取ったサブスクリプションを、サブスクリプションテーブル保持部150が保持するサブスクリプションテーブル151に追加するステップ1005。この追加として、イベント制御部140は、サブスクリプションテーブル151の一部の情報を更新してもよい。なお、情報通知ノード10は、自ノードの管理対象サブスクリプションに対し、ランデブーノードとなる。次のノードにサブスクリプションを転送する、又は、サブスクリプションをサブスクリプションテーブル151に登録し、情報通知ノード10は、サブスクリプションを受けた場合の動作を終了する。次に、pubsubネットワーク40におけるサブスクリプションの転送について図面を参照して説明する。図4は、pubsubネットワーク40におけるサブスクリプションの転送の一例を示す図である。まず、図4の構成について説明する。図4において、大円は、ルーティングテーブル131で示す情報の転送経路である。なお、図4に示す経路における転送方向は、時計回りとする。そのため、サブスクリプションは、時計回りに転送されている。情報通知ノードは、小円で示している。小円の中の数値が、分散ハッシュテーブルDHTのキーでもある各情報通知ノードのノードIDである。なお、本実施の形態に係る情報通知ノードは、図4のどのノードの位置でもよいが、本実施の形態に係る説明では、ID=1000の情報通知ノード10を用いて説明する。なお、本実施の形態に係る情報通知ノード10は、前ノードが1つとは限らない。そこで、図4は、一例として、情報通知ノード10の前ノードが2つの場合を示している。ID=0111の情報通知ノード11が、第1の前ノードであり、ID=0110の情報通知ノード13が、第2の前ノードである。また、ID=0101の情報通知ノード12は、情報通知ノード11の前ノードである。情報通知ノード11は情報通知ノード10の前ノードのため、情報通知ノード12は、情報通知ノード10に対する前々ノードである。さらに、図4において、6つのサブスクライバsub20a-sub20fが、サブスクリプションを登録している。図4では、サブスクリプションの登録を、各サブスクライバsubからの矢印で示している。説明の便宜のため、6つのサブスクリプションは、すべて、情報通知ノード10ID=1000の管理対象サブスクリプションとする。続いて、図4における情報通知ノードのサブスクリプションの転送の動作について説明する。サブスクライバ20aからサブスクリプションを受け取った情報通知ノード15ID=0001は、自ノードで保持するルーティングテーブル131に基づき、サブスクリプションを転送する。ただし、情報通知ノード15は、サブスクリプションの転送先である情報通知ノード10ID=1000に直接サブスクリプションを転送できない。そのため、情報通知ノード15は、まず、情報通知ノード12ID=0101にサブスクリプションを転送する。情報通知ノード15及びサブスクライバ20cからサブスクリプションを受け取った情報通知ノード12は、情報通知ノード10にサブスクリプションを直接転送できないため、情報通知ノード11ID=0111に2つのサブスクリプションを転送する。情報通知ノード12及びサブスクライバ20eからサブスクリプションを受け取った情報通知ノード11は、情報通知ノード10に3つのサブスクリプションを転送する。同様に、サブスクライバ20bからサブスクリプションを受け取った情報通知ノード14ID=0010は、情報通知ノード10にサブスクリプションを直接転送できないため、情報通知ノード13ID=0110にサブスクリプションを転送する。情報通知ノード14及びサブスクライバ20dからサブスクリプションを受け取った情報通知ノード13は、2つのサブスクリプションを情報通知ノード10に転送する。サブスクライバ20f、情報通知ノード13、及び、情報通知ノード11からサブスクリプションを受け取った情報通知ノード10は、受け取ったサブスクリプションが自ノードの管理対象サブスクリプションのため、サブスクリプションを転送しない。管理対象サブスクリプションを受け取った管理担当の情報通知ノード10は、図3を用いて説明した動作に基づき、負荷分散管理テーブル171及びサブスクリプションテーブル151を更新する。このように、本実施の形態に係る情報通知ノード10を含むpubsubネットワーク40は、サブスクリプションの管理担当である情報通知ノード10にサブスクリプションを転送する。次に、図4を用いて説明したサブスクリプションを登録後の情報通知ノード10が含むテーブルについて説明する。なお、既に説明したとおり、ルーティングテーブル131についての説明は、省略する。まず、負荷分散管理テーブル171について図面を参照して説明する。図5は、図4を用いて説明したサブスクリプションの転送動作に基づいて、情報通知ノード10が作成又は更新した負荷分散管理テーブル171の一例を示す図である。本実施の形態に係る負荷分散管理テーブル171は、サブスクリプション条件172と、前ノードID173と、通知先ID174と、負荷担当175と、前ノード転送176とを含む。なお、図5では、各行がレコードとなっている。サブスクリプション条件172は、サブスクリプションが含むサブスクリプション条件を保持する。つまり、サブスクリプション条件172は、サブスクリプションに基づきイベントの通知を担当する管理担当の情報通知ノード及びイベントの条件に関する情報を含む。例えば、図5の1行目1つ目のレコードは、ID=1000の情報通知ノード図4では情報通知ノード10が管理担当の情報通知ノードであり、通知するイベントは事故であることを示している。前ノードID173は、サブスクリプションを送ってきたノード、つまり、前ノードの情報を保持する。なお、前ノードを示す方式は、いろいろな方式を使用してよいが、本実施の形態では、一例として、ノードIDを用いる。例えば、図5の1行目のレコードは、ID=0111の情報通知ノード図4では、情報通知ノード11からサブスクリプションを受け取ったことを示している。ただし、情報通知ノード10がサブスクライバ20からサブスクリプションを受け取った場合、前ノードID173は、空白図5の3行目のレコードの-となる。また、既に説明したとおり、前ノードID173は、サブスクリプションの経由ノードIDに基づいて設定してもよい。通知先ID174とは、サブスクリプションに基づき指定されたイベントの通知先本実施の形態ではサブスクライバ20を示す情報である。なお、図5に示すレコードは、前ノードID173でまとめているため、通知先ID174は、複数の通知先を含む場合もある。例えば、図5の1行目のレコードは、通知先がsub20a、sub20c、及び、sub20eであることを示している。ただし、本実施の形態に係る情報通知ノード10は、これに限られず、通知先ごとのレコードとしてもよい。負荷担当175は、自ノードでイベントを通知するか否かを示している。負荷担当175は、自ノードで通知する場合をT、通知しない場合をFとして示す。前ノード転送176は、後ほど詳細に説明する負荷分散のために前ノードに処理を委譲通知の代行を依頼しているか否かを示している。前ノード転送176がTの場合、情報通知ノード10は、処理を委譲している。Fの場合、情報通知ノード10は、処理を委譲していない。図5に示す負荷担当175及び前ノード転送176は、初期状態として、すべてを解除した状態となっている。なお、図5に示す負荷分散管理テーブル171は、図4を用いて説明した動作に基づいて、情報通知ノード10が受け取った6個のサブスクリプションを、前ノードID173に基づいて、3個のレコードにまとめて保持した例を示している。図6は、図4を用いて説明したサブスクリプションの転送動作に基づいて、情報通知ノード11が作成又は更新した負荷分散管理テーブル171の一例を示す図である。各項目は、図5と同様のため、詳細な説明は、省略する。情報通知ノード11は、2つのサブスクリプションを受け取ったため、負荷分散管理テーブル171も2つのレコードを保持している。なお、図6に示す負荷担当175及び前ノード転送176は、初期状態として、すべてを解除した状態となっている。図7は、本実施の形態に係るサブスクリプションテーブル151の一例を示す図である。本実施の形態に係る情報通知ノード10のサブスクリプションテーブル151は、サブスクリプション条件152と、通知先ID153と、負荷委譲済154とを含む。なお、図7では、各行がレコードとなっている。サブスクリプション条件152は、サブスクリプションが含むサブスクリプション条件を保持する。つまり、サブスクリプション条件152は、サブスクリプションに基づき、イベントを通知する管理担当の情報通知ノードのノードIDとイベントとの条件を含む。なお、本実施の形態の情報通知ノード10は、管理対象サブスクリプションをサブスクリプションテーブル151に保持する。つまり、情報通知ノード10は、自ノードが通知するサブスクリプションをサブスクリプションテーブル151に保持する。そのため、サブスクリプション条件152のイベントを通知するノードIDは、自ノードのIDである。通知先ID153は、イベントの通知先の装置を示す識別子IDである。既に説明したとおり、本実施の形態では、サブスクライバ20と通知先は同じとして説明するため、通知先ID153は、サブスクリプションを登録したサブスクライバIDとなる。なお、本実施の形態に係るサブスクリプションテーブル151は、同じサブスクリプション条件152を備えたレコードをまとめている。そのため、図7に示す通知先ID153は、複数の通知先サブスクライブを保持している。ただし、本実施の形態に係る情報通知ノード10は、これに限られず、通知先ごとのレコードとしてもよい。なお、図7の1行目のレコードが、図4を用いて説明したサブスクリプションに相当するレコードであり、通知先とし、sub20a乃至sub20fを保持している。負荷委譲済154は、サブスクリプションで指定された管理対象イベントの通知を、別のノードに依頼済か否かを示す情報である。図7においてTは依頼済、Fは未依頼つまり自ノードで通知することを示す。情報通知ノードでの負荷分散の設定次に情報通知ノード10における負荷分散の設定動作について図面を参照して説明する。まず、イベント制御部140における負荷分散の設定動作について図面を参照して説明する。図8は、イベント制御部140の負荷分散の設定動作の一例を示すフロー図である。イベント制御部140は、所定のタイミングで例えば、定期的、又は、サブスクリプションを受信後、サブスクリプションテーブル151の各レコードに基づいて次の示す動作を開始するステップ2001。イベント制御部140は、各レコードのイベントの通知の負荷が自ノードに対して大きいか否かを判定するステップ2002。イベント制御部140は、いろいろな条件に基づいて判定できる。例えば、イベント制御部140は、判定の条件として、サブスクリプションテーブル151のレコードに登録されている通知先の数、サブスクリプション又はサブスクリプションに対するイベントの発生頻度、自ノードのCPUの処理状態又は通信回線の負荷状態、通知先までの距離ホップ数、若しくは、自ノードのメモリの使用量、又は、これらの予想値を用いることができる。なお、本実施の形態では、一例として、サブスクリプションテーブル151に登録されている通知先の数を条件とした場合について説明する。そのため、イベント制御部140は、サブスクリプションテーブル151のレコードに登録されている通知先の数本実施の形態では、サブスクライブの数を所定の閾値と比較する。例えば、図7の1行目で示すレコードの通知先の数は、6である。そのため、閾値が6未満の値の場合、通知先の数は、閾値を超え、負荷が大きいステップ2002でyesと判定される。反対に、閾値が6以上の値の場合、通知先の数は、閾値を超えず、負荷が大きくないステップ2002でnoと判定される。負荷が大きくない場合ステップ2002でno、負荷分散は、必要ない。そのため、イベント制御部140は、自ノードでの処理、つまり、サブスクリプションテーブル151の負荷委譲済154を委譲しないFに設定するステップ2006。負荷が大きい場合ステップ2002でyes、負荷分散は、必要である。そこで、イベント制御部140は、前ノードに、閾値を越えたレコードの負荷の分担を依頼するため、サブスクリプション条件152を含む負荷の分担の依頼を負荷分散制御部160に送付するステップ2003。その後、イベント制御部140は、負荷分散制御部160の処理の終了を待つステップ2004。負荷分散制御部160の処理が終了すると、イベント制御部140は、サブスクリプションテーブル151の負荷委譲済154を委譲済みTに設定する。例えば、図7の1行目のレコードは、負荷を委譲済みであり、2行目のレコードは委譲していないことを示す。このような動作に基づき、イベント制御部140は、負荷分散を設定する。次に、負荷分散制御部160の負荷分散の設定動作について図面を参照して説明する。図9は、負荷分散制御部160の負荷分散の設定動作の一例を示すフロー図である。負荷分散制御部160は、イベント制御部140から負荷分散の設定の依頼を受け取り、処理を開始するステップ2101。負荷分散制御部160は、イベント制御部140の依頼に含まれるサブスクリプション条件に一致する負荷分散管理テーブル171の各レコードについて以下の動作を繰り返すステップ2102。まず、負荷分散制御部160は、所定の条件に基づき、各レコードの処理を前ノードに依頼委譲するか否かを判定するステップ2103。この判定に用いる所定の条件とは、負荷分散制御部160が、委譲するイベントの範囲又は委譲しないイベントの範囲を決めるための条件である。例えば、負荷分散制御部160は、予め通知先数の閾値を保持しておき、閾値を越える数の通知を委譲するように判定してもよく、サブスクリプション条件が一致するレコードの通知のすべてを委譲しても良い。ただし、サブスクライバから直接受け取ったサブスクリプションは前ノードがない。そのため、サブスクライバから直接受け取ったサブスクリプションの場合、負荷分散制御部160は、自ノードで通知すると判定する。判定の結果、委譲しない場合ステップ2103でno、負荷分散制御部160は、負荷分散管理テーブル171の負荷担当175を自ノードに設定するステップ2106。具体的には、負荷分散制御部160は、負荷分散管理テーブル171の負荷担当175をT、前ノード担当をFに設定する。通知を委譲する場合ステップ2103でyes、負荷分散制御部160は、通知の委譲を依頼する代行依頼メッセージ201を作成して、前ノードID173が保持している前ノードに送付するステップ2104。なお、代行依頼メッセージ201は、いろいろな形式を採用することができるが、本実施の形態の代行依頼メッセージ201は、一例として、委譲するレコードのサブスクリプション条件172と、通知先ID174とを含むとする。代行依頼メッセージ201を送付後、負荷分散制御部160は、負荷分散管理テーブル171の前ノード転送176にT、負荷担当175にFを設定するステップ2105。ただし、レコードの一部を委譲する場合、負荷分散制御部160は、対象のレコードを委譲するレコードと委譲しないレコードとに分け、委譲しないレコードはステップ2106と同様に自ノード担当に設定し、委譲するレコードはステップ2105の同様に設定する。負荷分散制御部160は、依頼されたサブスクリプションの条件に一致する全てのレコードに対して、ここまで説明した動作を繰り返す。処理の対象となる全てのレコードの処理が終了すると、負荷分散制御部160は、処理の終了をイベント制御部140に通知するステップ2107。図10は、図9を用いて説明した動作の終了後の負荷分散管理テーブル171の一例を示す図である。図10に示す負荷分散管理テーブル171は、図5に示す負荷分散管理テーブル171の1行目のレコードを閾値に基づいて一部を委譲し、2行目のレコードをすべて委譲した場合についての一例である。一部を委譲するため、図5の1行目のレコードは、図10において、自ノードで通知する1行目のレコードと委譲する2行目のレコードとに分かれている。そして、図10に示す負荷分散管理テーブル171において1行目のレコードの通知先sub20a及び自ノードがサブスクリプションを受け取った4行目の通知先sub20fは、自ノードで通知するため、負荷担当175がT、前ノード転送176がFとなっている。また、2行目と3行目のレコードの通知先sub2b-sub2eは代行依頼メッセージ201を送付し委譲済みのため、負荷担当175は、F、前ノード転送176は、Tとなっている。前ノードでの負荷委譲の設定次に、代行依頼メッセージ201を受けた前ノード例えば、情報通知ノード11の動作について図面を参照して説明する。なお、この動作は、本実施の形態に係る情報通知ノードで同様に動作するが、ここでは、情報通知ノード11を用いて説明する。図11は、代行依頼メッセージ201を受信した情報通知ノード11の動作の一例を示すフロー図である。代行依頼メッセージ201を受信した情報通知ノード11の情報転送部110は、代行依頼メッセージ201を負荷分散制御部160に送るステップ3001。代行依頼メッセージ201を受け取った負荷分散制御部160は、代行依頼メッセージ201に含まれるサブスクリプション条件と負荷分散管理テーブル171のサブスクリプション条件とを比較し、一致したレコードに関して次に示す動作を繰り返すステップ3002。負荷分散制御部160は、自ノードで代行依頼メッセージ201の委譲を受けて通知を担当するか、さらに前のノードに委譲するかを判定するステップ3003。この判定として、負荷分散制御部160は、例えば、図9を用いて説明したステップ2103と同様に判定すればよい。負荷を前のノードに委譲する場合ステップ3003でyes、負荷分散制御部160は、さらに前のノード前々ノードに代行依頼メッセージ201を送信するステップ3004。さらに、負荷分散制御部160は、負荷分散管理テーブル171の対応するレコードの前ノード転送176をT、負荷担当175をFに設定するステップ3005。一方、自ノードで通知を担当する場合ステップ3003でno、負荷分散制御部160は、対応するレコードの負荷担当175をT、前ノード転送176をFに設定するステップ3006。このような動作に基づき、情報通知ノード11は、受け取った代行依頼メッセージ201に対して、負荷分散管理テーブル171に基づき自ノードでの対応又は委譲を設定する。図12は、代行依頼メッセージ201を受けた後の情報通知ノード11の負荷分散管理テーブル171の一例を示す図である。図12の1行目のレコードは、自ノードで担当する場合のレコードである。そのため、負荷担当175はTであり、前ノード転送176はFとなっている。また、2行目のレコードは、委譲した場合の一例である。そのため、負荷担当175はF、前ノード転送176はTである。つまり、図12に示す負荷分散管理テーブル171は、自ノードがsub20eにイベントを通知し、sub20cの通知を委譲していることを示している。対象ノードでのイベントの通知動作次に、対象ノードランデブーノードである情報通知ノード10が、イベントを受け取った場合の動作、つまり管理対象イベントを受け取った管理担当である情報通知ノード10の動作について図面を参照して説明する。図13は、管理対象イベントを受け取った情報通知ノード10の動作の一例を示すフロー図である。パブリッシャ30からpubsubネットワーク40にイベントがパブリッシュ発信、入力されると、pubsubネットワーク40は、管理担当の情報通知ノード10にイベントを転送する。イベントを受信した情報通知ノード10の情報転送部110は、イベントをイベント制御部140に送るステップ4001。イベントを受け取ったイベント制御部140は、サブスクリプションテーブル151に保持されている各レコードについて次に説明する処理を繰り返すステップ4002。イベント制御部140は、受け取ったイベントが各レコードのサブスクリプション条件152と一致するか否か、つまり対象イベントであるか否かを確認するステップ4003。対象イベントで無い場合ステップ4003でno、イベント制御部140は、特に動作せずに次のレコードの処理に移行する。対象イベントの場合ステップ4003でyes、イベント制御部140は、対象イベントに対応するサブスクリプションテーブル151のレコードの負荷委譲済154を確認するステップ4004。負荷委譲済154が負荷委譲していないFの場合ステップ4004でno、情報通知ノード10は、通知先ID153にイベントを通知notifyするステップ4005。負荷を委譲済みTの場合ステップ4004でyes、イベント制御部140は、負荷分散制御部160に通知の代行負荷分散を依頼するステップ4006。そして、イベント制御部140は、負荷分散制御部160からの結果を待つ。負荷分散制御部160からの結果を受け取ったイベント制御部140は、結果の内容を確認するステップ4007。判定の結果に負荷委譲でない、つまり自ノードでの通知が含まれる場合ステップ4007でno、イベント制御部140は、通知するとの結果となったイベントを通知するステップ4005。判定の結果がすべて負荷委譲の場合ステップ4007でyes、イベント制御部140は、処理を終了し、次のレコードの処理に移行する。図14は、図13で示すステップ4006においてイベントの負荷分散を依頼された負荷分散制御部160の動作の一例を示すフロー図である。負荷分散の依頼を受けたステップ4101負荷分散制御部160は、負荷分散管理テーブル171のサブスクリプション条件172が負荷分散の依頼のサブスクリプション条件と一致するレコードついて、次に示す動作を繰り返すステップ4102。負荷分散制御部160は、負荷を委譲済みか否か、つまり、負荷分散管理テーブル171の各レコードの負荷担当175を確認するステップ4103。自ノードで負荷を担当する場合ステップ4103でyes、負荷分散制御部160は、イベント制御部140に、そのレコードに対応するイベントについて自ノードで通知するとの結果を返すステップ4104。この結果を受けたイベント制御部140は、既に説明したとおり、イベントを通知する。負荷分散制御部160は、イベント制御部140に通知後、次のレコードの処理に移行する。自ノードで負荷を担当しない場合ステップ4103でno、負荷分散制御部160は、レコードの前ノード転送176を確認し、前ノードに委譲済みか否か、つまり、前ノードに負荷の代行を依頼しているか否かを確認するステップ4105。負荷を委譲済みの場合ステップ4105でyes、負荷分散制御部160は、情報転送部110を介して、前ノードID173に登録されている前ノードに代行して通知する依頼以下、通知notify依頼メッセージ202と称すを送信するステップ4106。通知依頼メッセージ202は、いろいろな形式及び含む情報を採用することができる。本実施の形態に係る通知依頼メッセージ202は、一例として、通知の代行を依頼するイベントに関する情報又は、サブスクリプション条件を含む。負荷を委譲済みでない場合ステップ4105でnoは、本来発生しない状態である。そのため、負荷分散制御部160は、特に動作しなくても良い。通知依頼メッセージ202を送信後、又は、負荷を委譲済みで無い場合、負荷分散制御部160は、次のレコードの動作に移行する。一致するすべてのレコードについて動作が終了すると、負荷分散制御部160は、イベント制御部140に負荷分散の終了を通知しステップ4107、処理を終了する。なお、負荷分散制御部160は、自ノードでのイベントの通知を、まとめて最後にイベント制御部140に連絡しても良い。ただし、本実施の形態の説明のように、負荷分散制御部160がレコードごとに連絡すると、イベント制御部140は、まとめて最後に連絡を受ける場合に比べ、イベントの通知を早く開始することができる。前ノードでのイベント通知動作次に、通知依頼メッセージ202を受け取った前ノードこの説明では、情報通知ノード11とするの動作について説明する。図15は、通知依頼メッセージ202を受信した前ノード情報通知ノード11の動作の一例を示すフロー図である。前ノードである情報通知ノード11の情報転送部110は、イベントの管理担当である情報通知ノード10から通知依頼メッセージ202を受けるステップ5001。通知依頼メッセージ202を受けた情報転送部110は、通知依頼メッセージ202を負荷分散制御部160に送付する。通知依頼メッセージ202を受け取った負荷分散制御部160は、通知依頼メッセージ202に含まれるサブスクリプション条件と一致するサブスクリプション条件172含むレコードを、負荷分散管理テーブル171から検索する。負荷分散制御部160は、一致したレコードに対して次に示す動作を繰り返すステップ5002。負荷分散制御部160は、各レコードの負荷担当175に基づき、自ノードが負荷の担当か否かを判定するステップ5003。負荷の担当の場合ステップ5003でyes、負荷分散制御部160は、イベント制御部140にイベントの通知を依頼する。依頼を受けたイベント制御部140は、通知依頼メッセージ202で依頼されたイベントを通知するステップ5004。負荷の担当でない場合ステップ5003でno、負荷分散制御部160は、負荷分散管理テーブル171の前ノード転送176を参照し、負荷を委譲、つまり、通知依頼メッセージ202を送信するか否かを判定するステップ5005。負荷を委譲する場合ステップ5005でyes、負荷分散制御部160は、負荷分散管理テーブル171に基づき、さらに前のノード前々ノードに通知依頼メッセージ202を送信する。負荷を委譲しない場合ステップ5006でno、負荷分散制御部160は、特に動作せずに終了する。ネットワークにおけるイベント通知の一例イベントの通知の代行について図面を参照してさらに説明する。図16は、pubsubネットワーク40におけるイベントの通知の代行の一例を示す図である。図16に示す小円は、図4と同様に情報通知ノードを示している。また、情報通知ノード10ID=1000は、図7に示すサブスクリプションテーブル151及び図10に示す負荷分散管理テーブル171を備える。さらに、情報通知ノード11ID=0111は、図12に示す負荷分散管理テーブル171を備えるとする。また、情報通知ノード12及び情報通知ノード13は、自ノードでイベントを通知するとする。図16に示すように、パブリッシャ30pub30が、図7の1行目のレコードのサブスクリプション条件152に一致するイベントが発行したとする。このイベントは、情報通知ノード16が受け、イベントの管理担当である情報通知ノード10に転送する。そこで、まず、情報通知ノード10の動作について説明する。イベントを受け取った情報通知ノード10のイベント制御部140は、イベントが図7に示すサブスクリプションテーブル151の1行目のレコードのサブスクリプション条件152と一致すると判定する図13のステップ4003。そして、イベント制御部140は、1行目のレコードの負荷委譲済154を確認し図13のステップ4004、委譲済みのため、負荷分散制御部160に負荷の分散を依頼する図13のステップ4006。依頼を受けた負荷分散制御部160は、図10に示す負荷分散管理テーブル171に基づき、1行目のレコード通知先がsub20aと4行目のレコード通知先がsub20fについては、イベント制御部140にイベントの通知を連絡する図14のステップ4104。この結果に基づき、イベント制御部140は、sub20aとsub20fにイベントを通知する図13のステップ4005。また、負荷分散制御部160は、負荷分散管理テーブル171の2行目のレコード通知先がsub20c、20eについて、前ノードID173に保持されているノード0111第1の前ノードである情報通知ノード11に通知依頼メッセージ202を送付する図14のステップ4106。同様に、負荷分散制御部160は、負荷分散管理テーブル171の3行目のレコード通知先がsub20b、20dについて、ノード0110第2の前ノードである情報通知ノード13に通知依頼メッセージ202を送付する図14のステップ4106。このように情報通知ノード10は、自ノードでのイベントを通知し、通知の代行を依頼する。次に、情報通知ノード11の動作について説明する。通知依頼メッセージ202を受け取った情報通知ノード11の負荷分散制御部160は、図12に示す負荷分散管理テーブル171に基づき、1行目のレコード通知先がsub20eについては、イベント制御部140にイベントの通知を連絡する。また、情報通知ノード11の負荷分散制御部160は、2行目のレコード通知先がsub20cについて、前ノードID173に保持されているノード0101前々ノードである情報通知ノード12に通知依頼メッセージ202を送る。情報通知ノード12及び情報通知ノード13は、通知依頼メッセージ202で委譲された通知を自ノードで通知する。つまり、情報通知ノード12は、情報通知ノード11から依頼されたsub20cにイベントを通知する。情報通知ノード13は、情報通知ノード10から依頼されたsub20b及びsab20dにイベントを通知する。各情報通知ノードと通知先のサブスクライバ20sub20a-sub20fとの対応をまとめると次のようになる。情報通知ノード10:sub20a、sub20f情報通知ノード11:sub20e情報通知ノード12:sub20c情報通知ノード13:sub20b、sub20dこのように、本実施の形態に係る情報通知ノード10は、負荷に基づき設定したサブスクリプションテーブル151及び負荷分散管理テーブル171を用いて、前ノードに情報イベントの通知、つまり負荷の代行を依頼する。また、依頼を受けた情報通知ノード11も、自ノードの負荷に基づき、自ノードがイベントを通知するか、通知の代行を依頼するかを判定し、負荷の代行を依頼できる。サブスクリプションの解除次に負荷分散を設定後、さらにサブスクリプションを受けた場合、又は、サブスクリプションの解除以下、解除通知と称すを受けた場合の情報通知ノード10に動作について図面を参照して説明する。図17は、負荷分散を設定後にサブスクリプション又は解除通知を受け取ったイベント制御部140の動作の一例を示すフロー図である。サブスクリプションを受け取ったイベント制御部140は、既にサブスクリプション条件152が登録されている場合に、以下で説明するように動作する。サブスクリプション条件152が登録されていない場合は、イベント制御部140は、既に図8を用いて説明したのと同様に動作すればよい。イベント制御部140は、登録済みのレコードについて以下に説明する動作を繰り返すステップ6001。イベント制御部140は、受け取ったサブスクリプション又は解除通知に基づきサブスクリプションテーブル151に保存しているレコードを更新する。更新後、イベント制御部140は、自ノードの負荷状況を判定するステップ6002。負荷が重くない場合ステップ6002でno、イベント制御部140は、負荷の委譲済みか否かを判定するステップ6003。負荷を委譲済みでない場合ステップ6003でno、イベント制御部140は、特に動作しないで終了する。負荷を委譲済みの場合ステップ6003でyes、イベント制御部140は、負荷分散制御部160に、負荷分散の解除を依頼するステップ6004。その後、イベント制御部140は、負荷分散制御部160の処理の終了を待つステップ6005。負荷分散制御部160の処理が終了するとイベント制御部140は、サブスクリプションテーブル151のデータを自ノードの負荷に変更ステップ6006し、処理を終了する。負荷が大きい場合ステップ5002でyes、イベント制御部140は、負荷分散制御部160に、負荷分散の再設定を依頼するステップ6007。負荷分散制御部160の再設定動作は、図9を用いて説明した動作と同様に動作すればよく、詳細な説明は、省略する。再設定の依頼後、イベント制御部140は、負荷分散制御部160の処理の終了を待つステップ6008。負荷分散制御部160の処理の終了後、イベント制御部140は、サブスクリプションテーブル151を委譲済みに設定するステップ6009。次に、負荷分散の解除の依頼を受けた、負荷分散制御部160の動作について図面を参照して説明する。図18は、負荷分散制御部160の動作の一例を示すフロー図である。負荷分散の解除の依頼を受けたステップ6101負荷分散制御部160は、依頼の対応する負荷分散管理テーブル171のレコードに関して、次に示す動作を繰り返すステップ6102。負荷分散制御部160は、負荷分散管理テーブル171の負荷担当175に基づき、負荷の委譲済みか否かを判定するステップ6103。負荷を委譲済みの場合ステップ6103でyes、負荷分散制御部160は、代行の解除を依頼する代行解除メッセージ203を作成して、委譲先のノード例えば、情報通知ノード11に送信するステップ6104。通知後、負荷分散制御部160は、負荷分散管理テーブル171の情報を更新するステップ6105。具体的に説明すると、負荷分散制御部160は、負荷担当を解除、つまり、前ノード転送176をF、負荷担当175をFと設定する。ここで、負荷分散制御部160は、まとめられるレコードをまとめるようにしてもよい。負荷を委譲済みで無い場合ステップ6103でno、負荷分散制御部160は、特に動作の必要は無い。ただし、安全のため、負荷分散制御部160は、ステップ6105と同様に負荷担当の解除を設定してもよい。負荷分散管理テーブル171の更新後、負荷分散制御部160は、解除の終了をイベント制御部140に通知しステップ6106、処理を終了する。続いて、代行解除メッセージ203を受けた委譲先例えば、情報通知ノード11の動作について図面を参照して説明する。図19は、代行解除メッセージ203を受けた情報通知ノード11の負荷分散制御部160の動作の一例を示すフロー図である。代行解除メッセージ203を受けたステップ7001情報通知ノード11の負荷分散制御部160は、依頼に対応する負荷分散管理テーブル171のレコードに関して、次に示す動作を繰り返すステップ7002。負荷分散制御部160は、負荷分散管理テーブル171の負荷担当175に基づき、負荷の委譲済みか否かを判定するステップ7003。負荷を委譲済みの場合ステップ7003でyes、負荷分散制御部160は、委譲先のノード例えば、情報通知ノード12に代行解除メッセージ203を送信するステップ7004。通知後、情報通知ノード11は、負荷担当を解除するように各テーブルの情報を更新するステップ7005。負荷を委譲済みで無い場合ステップ7003でno、負荷分散制御部160は、特に何もせず終了する。ただし、安全のため、負荷分散制御部160は、ステップ7005と同様に負荷担当の解除を設定してもよい。ここまで説明した動作に基づき、情報通知ノードは、負荷分担を解除する。なお、ここまでの説明において、代行依頼メッセージ201を受けた前ノード例えば、情報通知ノード11が負荷を担当できない場合、前ノードは、さらに前々ノードに代行依頼メッセージ201を送って負荷の代行を依頼していた。しかし、本実施の形態に係る情報通知ノードは、これに限られるわけではない。例えば、負荷を担当できない前ノードは、自ノードで代行依頼メッセージ201を送信するのではなく、依頼元のノードに委譲拒否のメッセージを送り返しても良い。この委譲拒否のメッセージを受け取った情報通知ノードは、新たに別の情報通知ノードに代行依頼メッセージ201を送っても良い。さらに、本実施の形態に係る情報通知ノード10の構成は、今まで説明した構成に限られるわけではない。本実施の形態に係る情報通知ノード10は、いくつかの構成を1つの構成、例えば、イベント制御部140と負荷分散制御部160を合わせた構成を含んでもよい。また、本実施の形態に係る情報通知ノード10の各構成は、さらに複数の構成に分けても良く、構成を別の装置に備え、ネットワークを介して接続したシステムとしてもよい。例えば、各テーブル保持部は、ネットワークを介して接続した外部の記憶装置に含まれてもよい。さらに、本実施の形態に係る情報通知ノード10は、別装置の一部を構成してもよい。別の構成図20は、本実施の形態に係る情報通知ノードの別の構成の一例を示すブロック図である。図20において図1と同じ構成は同じ番号を付して、詳細な説明は省略する。情報通知ノード18は、ブレードサーバbladeserverのように、所定の装置に組み込まれ、内部バスを用いて他の装置と接続している。情報通知ノード18の情報転送部110は、イベント制御部140及び負荷分散制御部160に含まれるため、図20において省略した。また、各テーブル保持部は、それぞれの保持部の回路が備える半導体記憶部にテーブルを保持するため、図20において各テーブルの表示を省略した。このように構成された情報通知ノード18のイベント制御部140及び負荷分散制御部160は、バスを介して他の装置サブスクライバ20などと情報を送受信し、サブスクリプション及びイベントに関して情報通知ノード10と同様に動作できる。そのため、情報通知ノード18は、情報通知ノード10と同様にイベントの通知を委譲できる。なお、情報通知ノード18は、本実施の形態に最小構成である。このように本実施の形態に係る情報通知ノードは、情報イベントを含む情報を通知する装置の負荷の軽減を得ることができる。その理由は、本実施の形態に係る情報通知ノードは、保持しているサブスクリプション受信登録に基づいて自ノードの負荷を判定し、負荷が大きい場合、他の情報通知ノード前ノードに情報の通知の代行を依頼し、自ノードの情報の通知を削減できるためである。また、代行を依頼された情報通知ノードは、依頼された情報の通知を自ノードの負荷に基づき、さらに代行を依頼することができるため、代行を依頼された情報通知ノードも、自ノードに適切な負荷を代行できるためである。第2の実施の形態第1の実施の形態に係る情報通知ノードは、各構成をコンピュータで実行するプログラムとして実現しても良い。さらに、第1の実施の形態に係る情報通知ノードの各構成は、コンピュータで実行するプログラムを記憶する記録媒体を含んでも良い。図21は、第2の実施の形態に係る情報通知ノード19の構成の一例を示す図である。情報通知ノード19は、情報処理部520と、情報記憶部530と、通信部510とを含んでいる。情報処理部520は、CPUCentralProcessUnitを含み、情報記憶部530が記憶しているプログラム540を実行する。そして、情報処理部520は、プログラム540に基づき、通信部510を介してサブスクライバ20などと通信し、第1の実施の形態に係る情報通知ノード10と同様に動作する。情報記憶部530は、図示しないハードディスク装置又はメモリ記憶装置など記憶装置を含み、情報処理部520が実行するプログラム540を記憶している。さらに、情報記憶部530は、プログラム540を保持する記憶媒体550を含んでも良い。なお、情報記憶部530は、情報処理部520が動作する場合の情報の一時保存記憶ワークエリアとして動作しても良い。通信部510は、ネットワークと接続するための回路、例えばNICNetworkInterfaceCardを含み、情報処理部520とサブスクライバ20及びパブリッシャ30などとの情報を中継する。このように第2の実施の形態に係る情報通知ノード19は、第1の実施の形態に係る情報通知ノード10と同様の効果を得ることができる。その理由は、第2の実施の形態に係る情報通知ノード19の情報処理部520が、プログラム540に基づいて、第1の実施の形態の情報通知ノード10と同様に動作することができるためである。上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。付記付記1イベントを含む情報の受信登録サブスクリプションを受け取り保持するサブスクリプションテーブル保持部と、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定するイベント制御部と、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する負荷分散管理テーブル保持部と、前記イベント制御部が委譲すると判定した場合に、前記負荷分散管理テーブル保持部が保持する情報に基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第1のノードに送付し、委譲しない通知先については前記イベント制御部に前記情報の通知を依頼する負荷分散制御部とを含む情報通知ノード。付記2前記負荷分散制御部が、第2のノードから情報の通知の代行の依頼を受け取ったとき、前記第2のノードの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、第3のノードに前記情報の通知の代行の依頼を送信することを特徴とする付記1に記載の情報通知ノード。付記3前記負荷分散制御部が、第2のノードから情報の通知の代行の依頼を受け取ったとき、前記第2のノードからの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、前記第2のノードに代行の依頼の拒否を送付することを特徴とする付記1に記載の情報通知ノード。付記4前記負荷分散制御部が、前記第1のノードに送付した前記情報の通知の代行の依頼に対して代行の依頼の拒否を受けた場合、第1のノードとは異なるノードに情報の通知の代行の依頼を送信することを特徴とする付記1乃至付記3のいずれかに記載の情報通知ノード。付記5前記負荷分散制御部が、前記負荷分散管理テーブル保持部が保持する前記送信元に含まれるノードから、前記第1のノードを選択することを特徴とする付記1乃至付記4のいずれかに記載の情報通知ノード。付記6前記イベント制御部、又は、前記負荷分散制御部の前記自ノードで通知するか否かの判定する条件が、前記サブスクリプションテーブル保持部が保持する前記受信登録の通知先の数、前記配信依頼及び前記配信依頼に対するイベントの発生頻度、自ノードの処理負荷、通知先までの距離ホップ数、自ノードのリソースの使用量、又は上記各条件の予想値のいずれかを含むことを特徴とする付記1乃至付記5のいずれかに記載の情報通知ノード。付記7情報の受信登録を受け取り保持し、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定し、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持し、委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第1のノードに送付し、委譲しない通知先については前記情報を通知する情報通知方法。付記8第2のノードから情報の通知の代行の依頼を受け取ったとき、前記第2のノードの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、第3のノードに前記情報の通知の代行の依頼を送信することを特徴とする付記7に記載の情報通知方法。付記9第2のノードから情報の通知の代行の依頼を受け取ったとき、前記第2のノードからの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、前記第2のノードに代行の依頼の拒否を送付することを特徴とする付記7に記載の情報通知方法。付記10前記第1のノードに送付した前記情報の通知の代行の依頼に対して代行の依頼の拒否を受けた場合、第1のノードとは異なるノードに情報の通知の代行の依頼を送信することを特徴とする付記7乃至付記9のいずれかに記載の情報通知方法。付記11保持する前記送信元に含まれるノードから、前記第1のノードを選択することを特徴とする付記7乃至付記10のいずれかに記載の情報通知方法。付記12前記自ノードで通知するか否かの判定する条件が、前記サブスクリプションテーブル保持部が保持する前記受信登録の通知先の数、前記配信依頼及び前記配信依頼に対するイベントの発生頻度、自ノードの処理負荷、通知先までの距離ホップ数、自ノードのリソースの使用量、又は上記各条件の予想値のいずれかを含むことを特徴とする付記7乃至付記11のいずれかに記載の情報通知方法。付記13情報の受信登録を受け取り保持する処理と、保持している前記受信登録に基づき前記情報の通知の負荷を判定し、前記負荷に基づき前記通知を委譲するか否かを判定する処理と、前記受信登録の送信元の情報と前記情報を通知する通知先とを保持する処理と、委譲すると判定した場合に、前記受信登録の送信元の情報と前記情報を通知する通知先とに基づき前記情報の通知を委譲する通知先の範囲を判定し、委譲する通知先については前記情報の通知の代行の依頼を第1のノードに送付し、委譲しない通知先については前記情報を通知する処理とをコンピュータに実行させるプログラム。付記14第2のノードから情報の通知の代行の依頼を受け取ったとき、前記第2のノードの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、第3のノードに前記情報の通知の代行の依頼を送信することを特徴とする付記13に記載のプログラム。付記15第2のノードから情報の通知の代行の依頼を受け取ったとき、前記第2のノードからの依頼に含まれる前記情報を自ノードで通知するか否かを判定し、自ノードで通知しない場合、前記第2のノードに代行の依頼の拒否を送付することを特徴とする付記13に記載のプログラム。付記16前記第1のノードに送付した前記情報の通知の代行の依頼に対して代行の依頼の拒否を受けた場合、第1のノードとは異なるノードに情報の通知の代行の依頼を送信することを特徴とする付記13乃至付記15のいずれかに記載のプログラム。付記17保持する前記送信元に含まれるノードから、前記第1のノードを選択することを特徴とする付記13乃至付記16のいずれかに記載のプログラム。付記18前記自ノードで通知するか否かの判定する条件が、前記サブスクリプションテーブル保持部が保持する前記受信登録の通知先の数、前記配信依頼及び前記配信依頼に対するイベントの発生頻度、自ノードの処理負荷、通知先までの距離ホップ数、自ノードのリソースの使用量、又は上記各条件の予想値のいずれかを含むことを特徴とする付記13乃至付記17のいずれかに記載のプログラム。付記19付記1乃至付記6のいずれかに記載の情報通知ノードと、情報の受信登録を登録するサブスクライバと、前記情報を発行するパブリッシャとを含む情報配信システム。