"予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を含むイベント配信装置。予め登録されている代理要求条件を基に、ネットワークを介して受信した代理要求に含まれるイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御部を含むことを特徴と請求項1に記載のイベント配信装置。前記通知制御部が、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする請求項2に記載のイベント配信装置。前記代理要求制御部が、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする請求項2又は請求項3に記載のイベント配信装置。前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベント配信装置の負荷情報を含み、前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むことを特徴とする請求項2乃至請求項4のいずれかに記載のイベント配信装置。前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存する経路制御部と、前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理する購読要求制御部と、前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送するイベント受信転送部と、前記イベントと前記サブスクリプションとの一致を判定する一致判定部と、前記イベントをアプリケーションに通知するイベント通知部とを含むことを特徴とする請求項2乃至請求項5のいずれかに記載のイベント配信装置。前記通知条件又は前記代理要求条件の少なくともいずれかが、自装置の資源に関する情報、自装置で通知するイベントの量に関する情報、又は、自装置で通知するイベントの滞留時間に関する情報の少なくとも1つを含むことを特徴とする請求項2乃至請求項6のいずれかに記載のイベント配信装置。前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を2以上の前記他の装置に送信することを特徴とする請求項2乃至請求項7のいずれかに記載のイベント配信装置。前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする請求項2乃至請求項8のいずれかに記載のイベント配信装置。前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の前記代理要求の受け付けの可否を確認することを特徴とする請求項2乃至請求項9のいずれかに記載のイベント配信装置。前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の負荷情報を受け取り、受け取った負荷情報を基に前記代理要求を送信するか否かを判定することを特徴とする請求項2乃至10のいずれかに記載のイベント配信装置。予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を備えるイベント配信装置と、前記イベント配信装置に前記ネットワークを介して前記イベントをパブリッシュするパブリッシャと、前記イベント配信装置に前記サブスクリプションを送信するサブスクライバと、前記イベント配信装置から前記イベントの通知を受けるアプリケーションとを含むことを特徴とするイベント配信システム。前記イベント配信装置が、予め登録されている代理要求条件を基に、ネットワークを介して受信した代理要求に含まれるイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御部を含むことを特徴とする請求項12に記載のイベント配信システム。前記通知制御部が、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする請求項13に記載のイベント配信システム。前記代理要求制御部が、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする請求項13又は請求項14に記載のイベント配信システム。前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベント配信装置の負荷情報を含み、前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むことを特徴とする請求項13乃至請求項15のいずれかに記載のイベント配信システム。前記イベント配信装置が、前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存する経路制御部と、前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理する購読要求制御部と、前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送するイベント受信転送部と、前記イベントと前記サブスクリプションとの一致を判定する一致判定部と、前記イベントを前記アプリケーションに通知するイベント通知部とを含むことを特徴とする請求項13乃至請求項16のいずれかに記載のイベント配信システム。前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を2以上の装置に送信することを特徴とする請求項13乃至請求項17のいずれかに記載のイベント配信システム。前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする請求項13乃至請求項18のいずれかに記載のイベント配信システム。ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定するイベント配信方法。ネットワークを介して代理要求を受信した場合、予め登録されている代理要求条件を基に、前記受信した代理要求に含まれるイベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定することを特徴とする請求項20に記載のイベント配信方法。ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御処理をコンピュータに実行させるイベント配信プログラムを格納する記憶媒体。ネットワークを介して代理要求を受信した場合、予め登録されている代理要求条件を基に、前記受信した代理要求に含まれるイベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御処理を含むこと特徴とする請求項22に記載のイベント配信プログラムを格納する記憶媒体。イベント配信装置は、例えば、栽培情報や特売情報などのイベント通知などに使用される。これらのイベント通知は、イベントの発生から通知までの時間に制限が必要である。つまり、イベント配信装置は、イベント発生からイベント通知までに所定の時間制限が必要となる場合がある。また、イベントとしては、例えば、大地震の発生、著名人のスキャンダルの発生など、イベントの発生時期は予測できないが、通知までの時間の制限だけではなく、発生すると大量のイベントの通知が必要となるイベントも想定される。このような突発的に大量発生するイベントを受信したイベント配信装置は、イベント処理、例えば、イベントを複数のアプリケーションに通知する処理、及び、他のイベント配信装置へのイベントを転送する処置などの負荷が重くなる。その結果、大量のイベントの配信を依頼されたイベント配信装置は、適正な時間内でのアプリケーションへのイベントの通知が難しいという問題点があった。この対策として、予め、このような大量発生の恐れのあるイベントのタイプに割り当てられているクラスタに属するイベント配信装置の数を増やし、さらに各イベント配信装置が担当するイベントの通知先であるアプリケーションの数を減らしておく対応が考えられる。しかし、このようなイベントは、突発的に発生し、所定の時間当たりにどれくらい発生するかを予測することが困難である。そのため、そのタイプのクラスタにどの程度のイベント配信装置を割り当てておけば良いかを、事前に正確に決めることができないという問題点があった。また、イベント配信装置のクラスタの構成も大きくなり、クラスタ内のイベント配信装置の数が多くなると、このクラスタ内のイベント配信装置間でのイベントの転送処理も増えるとの問題があった。本発明の目的は、上記問題点を解決し、イベントが大量に発生し、イベントをアプリケーションに通知する処理負荷が重くなっても、適切にアプリケーションにイベントを通知するイベント配信装置、イベント配信システム、及び、イベント配信方法を提供することにある。本発明のイベント配信装置は、予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を含む。本発明のイベント配信システムは、予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を備えるイベント配信装置と、前記イベント配信装置にネットワークを介して前記イベントをパブリッシュするパブリッシャと、前記イベント配信装置にサブスクリプションを登録するサブスクライバと、前記イベント配信装置から前記イベントの通知を受けるアプリケーションとを含む。本発明のイベント配信方法は、ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する。本発明の記憶媒体は、ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御処理をコンピュータに実行させるイベント配信プログラムを格納する。本発明は、イベントが大量に発生し、イベントをアプリケーションに通知するイベント配信装置の処理負荷が重くなっても、適切にアプリケーションにイベントを通知することが出来る。次に、本発明について図面を参照して詳細に説明する。関連用語まず、本発明の実施形態の説明における用語を整理しておく。イベントeventとは、何かの現象を契機として発生するデータのことである。例えば、イベントとは、携帯端末などの操作、RFRadioFrequencyタグ又はセンサを用いた信号の検出などに基づいて発生するデータのことである。これらのイベントは、後ほど説明するパブリッシャが、イベント配信NWにパブリッシュする。イベントは、1つのデータに限られず、複数のデータを含んでもよい。イベントを構成する複数のデータは、特段区別をつける必要はないが、本発明の実施形態の説明においては、説明の便宜のため、イベントの種別を表すデータを特にタイプと呼び、その他のデータを属性と呼ぶこととする。図1は、複数のデータから構成されたイベントの一例を示す図である。図1に示すイベントは、イベントの種別を表すタイプ例えば、物がぶつかる衝撃、扉の開閉、温度センサの温度などとその他のデータである属性から構成されている。さらに、属性は、イベント検出した装置やセンサなどを示すデータ図1の装置ID、その装置やセンサが取得したデータ図1では、データ、データの取得場所や取得時刻図1では、場所時刻などを含む。また、装置ID、データ、場所、時刻などの各属性の名称を属性名とし、属性名に対する各データ値ID1、開、東京都港区、14:10:25などを属性値と言うこととする。つまり、属性は、属性名と属性値とから構成されているものとして説明する。なお、以下の本発明の実施形態の説明において、1個以上のタイプと0個以上の属性から構成されるイベントについて説明するが、これはあくまで説明の便宜のためである。本発明の実施形態は、タイプを指定せずに1個以上の属性から構成されるイベントにも適用出来る。また、既に説明したパブリッシャがパブリッシュする場合だけではなく、後ほど説明する、イベント配信装置の間で転送される転送要求、及び、代理要求に含まれる場合にもイベントと言う。イベントパターンeventpatternとは、アプリケーションに通知する対象となるイベントを指定する条件である。なお、本発明の実施形態の説明で使用するイベントパターンは、既に説明したイベントに合わせ、1個以上のタイプと0個以上の属性属性名と属性値を指定したものとして説明する。ただし、イベントパターンもこれに限られるわけではない。本発明の実施形態は、例えば、イベントパターンとして、タイプを指定せずに1個以上の属性から構成されるイベントパターンにも適用出来る。図2は、イベントパターンの一例を示す図である。図2において、例えば、1つ目のイベントパターンは、タイプが衝撃、属性名場所に対する属性値が東京都港区と指定されている。イベント一致判定処理とは、イベント配信装置において、イベントとイベントパターンが一致以下、マッチmatchと言う場合もあるするか否かを判定することである。イベントがイベントパターンに一致マッチするか否かの判定とは、イベントパターンで指定されているタイプがイベントのタイプと一致し、イベントパターン指定された属性とイベントの属性が一致することである。ここでの属性の一致とは、イベントパターンの属性名に対する属性値が、イベントの同じ属性名に対する属性値と一致することである。イベントパターンのタイプとイベントのタイプが一致し、イベントパターンの属性がイベントの属性と一致した場合に、判定結果は、一致マッチとなる。例えば、図1に示すEvent1と図2に示すEventPattern1を使用して説明すると、次のようになる。まず、EventPattern1で指定されているタイプ衝撃が、Event1のタイプ衝撃が同じである。さらに、EventPattern1で指定されている属性名場所に対する属性値東京都港区が、Event1の属性名場所に対する属性値東京都港区と一致している。従って、図1のEvent1は、図2のEventPattern1に一致するとの判定の結果となる。なお、図2に示すEventPattern1では、図1に示すEvent1に記述される属性のうち、属性名装置ID、データ、時刻に対する属性値は指定されていない。このように属性値が指定されていない場合は、指定されていない属性値この場合、属性名装置ID、データ、時刻などが、どのような値でもよいことを意味している。なお、本発明の実施形態は、イベントパターンの属性値を、イベントの属性値の一部と一致する場合も一致と判定しても良い。例えば、本発明の実施形態は、イベントパターンの属性値=東京都を、イベントの属性値=東京都港区と一致すると判定しても良い。また、本発明の実施形態は、一致判定を、完全に一致する場合を一致と判定しても良い。さらに、本発明の実施形態は、一致判定に使用する属性値を、1つの値ではなく、範囲を指定してもよい。後ほど詳細に説明するが、本発明の実施形態に係るイベント配信装置は、パブリッシャがパブリッシュしたイベントと、サブスクライバがサブスクライブしたサブスクリプションに含まれるイベントパターンとの一致を判定する。パブリッシャpublisherとは、検出したイベントを、イベント配信NWにパブリッシュする装置、システム、プログラムなどである。パブリッシャは、起きた事象そのものを検出する装置など例えば、携帯端末、RFタグ、センサなどでもよく、そのような装置からイベントに関する情報を受け取って、イベント配信NWにイベントをパブリッシュする装置例えばサーバなどなどでもよい。パブリッシュpublishとは、パブリッシャがイベント配信NWなどにイベント送り出すことである。パブリッシャがイベントをイベント配信NWにパブリッシュするなどと言うこととする。サブスクライバsubscriberとは、イベント配信NWにイベントの通知に関する情報例えば、どのような通知先にイベントを通知するかなどを指定する装置、システム、プログラムなどである。さらに具体的に説明すると、サブスクライバは、イベント配信NWに次に説明するサブスクリプションをサブスクライブする。サブスクリプションsubscriptionとは、サブスクライバがイベントの通知を要求するときにイベント配信NWにサブスクライブするデータのことである。サブスクリプション以下、購読要求と言うこともある。は、サブスクリプションを識別するサブスクリプションIDと、既に説明したイベントパターンと、イベントパターンに一致したイベントの通知先である1つ以上の通知先を含む。なお、通知先は、後ほど説明するアプリケーションであり、例えば通知先のデータ構成をリスト構成とするなどして、複数のアプリケーションを指定することができてもよい。図3は、サブスクリプションの一例を示した図である。図3に示す1つ目のサブスクリプションSubscription1の一例は、次のように構成されている。例えば、サブスクリプションIDがsub1、イベントパターンがEvent_Patternタイプ=衝撃、場所=東京都港区、イベントパターンにマッチしたイベントの通知先がapp1,app2,...,app1000と指定されている。このサブスクリプションのイベントパターンとイベントとの一致判定もイベント一致判定と言う。このような一致マッチの場合には、例えば、イベントがサブスクリプションのイベントパターンにマッチする、イベントがサブスクリプションに一致するなどとも言うこととする。サブスクライブsubscribeとは、サブスクライバがサブスクリプションをイベント配信NWなどに登録するために送り出すことである。サブスクライバは、サブスクリプションをイベント配信NWにサブスクライブするなどと言うこととする。アプリケーションapplicationとは、イベント配信NWがイベントを通知する通知先である装置、システム、プログラムなどのことである。続いて、発明を実施するための最良の形態について図面を参照して詳細に説明する。なお、以下の本発明の実施形態に係る説明では、説明の便宜のため、イベント配信装置のイベントの転送は、イベント配信NWの一部のイベント配信装置に転送する場合について説明する。ただし、イベント配信装置は、イベント配信NWに含まれる全てイベント配信装置にイベントを転送例えば、ブロードキャストしてもよく、他の技術例えば既に説明した非特許文献3などを用いてイベントを転送してもよい。第1の実施形態本発明の第1の実施形態に係るイベント配信装置10の構成及び動作について、さらに図4-図29を参照して詳細に説明する。図4は、第1の実施形態に係るイベント配信装置10が含まれるイベント配信システム1の構成の一例を示すブロック図である。なお、特に断らない限り、イベント配信装置10などは、複数の場合も含まれるものとする。イベント配信システム1は、イベント配信装置10と、パブリッシャ20と、サブスクライバ30と、アプリケーション40と、イベント配信ネットワーク以下、イベント配信NW50とするとを含む。なお、図4において、イベント配信NW50を1つとして図示しているのは、説明の便宜のためであり、イベント配信システム1は、論理的又は物理的に2つ以上のイベント配信NW50が含んでも良い。イベント配信装置10は、受け取ったイベントを所定の他のイベント配信装置10への転送forward、及び、所定のアプリケーション40へ通知notifyする装置、システム、又は、プログラムに基づいて動作するコンピュータである。なお、プログラムは、図示しない記憶媒体に格納される。以下、イベント配信装置10を、ノードをいう場合もあり、各ノードを区別するために、ノードA,ノードB,...などと言う場合もある。なお、イベント配信装置10は、単独で、又は、他のイベント配信装置10と接続してイベント配信NW50の一部を構成している。なお、イベント配信装置10については、後ほど詳細に説明する。パブリッシャ20は、イベント配信NW50に接続して、イベントをパブリッシュする装置、システム、又は、コンピュータ上で動作するプログラムなどであり、単独の装置でもよく、複数の装置でもよい。パブリッシャ20は、既に説明したとおり、例えば、センサや、監視装置などもよく、他の装置で検出した現象を基にイベントをイベント配信NW50にパブリッシュするサーバなどでもよい。なお、イベント配信NW50に接続するパブリッシャ20もイベント配信NW50の一部を構成してもよい。サブスクライバ30は、イベント配信NW50に接続し、イベント配信NW50にパブリッシュされたイベントの一致判定の条件及び通知先などを要求するサブスクリプションをサブスクライブする装置、システム、又は、コンピュータ上で動作するプログラムなどである。サブスクライバ30も単独でも複数でもよく、イベント配信NW50の一部を構成してもよい。アプリケーション40は、イベント配信NW50に接続し、パブリッシャ20がパブリッシュしたイベントのうち、サブスクライバ30がサブスクライブしたサブスクリプションに一致したイベントの通知を受け取る装置、システム、又は、プログラムなどである。例えば、アプリケーション40は、近接センサの検出イベントの通知を受けてドアを開けるような装置、又は、RFIDの検出の通知を基に料金を決済する装置などである。アプリケーション40も単独でも複数でもよく、イベント配信NW50の一部を構成してもよい。イベント配信NW50は、パブリッシャ20に基づくイベントのパブリッシュや、アプリケーション40へのイベントの通知を実現するために、イベント配信装置10などを含む。なお、イベント配信NW50は、既に説明した装置以外の装置、例えば、ネットワークを構成する装置であるルータやブリッジなどを含んでもよい。次に、第1の実施形態の係るイベント配信システム1の動作について説明する。イベントに先立ち、サブスクライバ30は、アプリケーション40に通知するイベントのイベントパターンと通知先のアプリケーション40に関する情報を含むサブスクリプションをイベント配信NW50にサブスクライブする。具体的には、サブスクライバ30は、イベント配信NW50のイベント配信装置10に、サブスクリプションをサブスクライブする。このサブスクライブされたサブスクリプションの登録後に、イベント配信装置10を用いたイベントの通知が可能となる。その後、イベントを検出したパブリッシャ20は、イベント配信NW50、具体的には、イベント配信NW50のイベント配信装置10に、イベントをパブリッシュする。イベントのパブリッシュを受けたイベント配信NW50のイベント配信装置10は、登録済みのサブスクリプションと受け取ったイベントとの一致を判定し、一致した場合は、そのサブスクリプションの通知先であるアプリケーション40にイベントを通知する。本実施形態の説明では、サブスクライバ30がイベントに先立ちサブスクリプションをサブスクライブする例を説明したが、この説明は本発明の動作順序を限定するものではない。サブスクライバ30とパブリッシャ20とは、相互に独立に、又は、並行して動作してもよい。なお、本実施形態におけるイベント配信NW50を含めた各装置イベント配信装置10、パブリッシャ20、サブスクライバ30、アプリケーション40、など間のデータの授受及び接続確保などは、一般的なネットワークのプロトコルを使用すればよい。そのため、本実施形態の説明において、各装置は相手先が分かっているものとし、相手先の検出やデータのやり取りの詳細な説明は省略する。次に、第1の実施形態に係るイベント配信装置10ノードについて詳細に説明する。まず、イベント配信装置10の構成について説明する。図5は、第1の実施形態に係るイベント配信装置10ノードの構成の一例を示すブロック図である。第1の実施形態に係るイベント配信装置10は、メッセージ転送部101と、経路制御部102と、経路情報保持部103と、購読要求制御部104と、購読要求保持部105と、イベント受信転送部106と、一致判定部107と、通知制御部108と、イベント通知部109と、代理要求制御部110と、代理要求条件保持部111とを含む。メッセージ転送部101は、外部の装置パブリッシャ20、サブスクライバ30、他のイベント配信装置10などと、以下で説明するイベント配信装置10内部の各部とでやり取りされる、各種メッセージなどを仲介する。経路制御部102は、経路情報保持部103が保持しているイベント配信装置10が接続しているイベント配信NW50におけるイベント配信装置10の接続に関連する情報を制御する。例えば、後ほど詳細に説明するように、イベント配信装置10が受け取ったサブスクリプションを基に、経路制御部102は、イベントを転送するための経路に関する転送経路情報を修正及び構築する。経路情報保持部103は、イベント配信NW50におけるイベント配信装置10の接続に関する情報である網構成装置情報と、所定のイベントのタイプの配信に関するイベント配信装置10の装置群クラスタの情報である転送経路情報などを保持している。この転送経路情報は、例えば、経路として木構造を使用した場合における、自装置と子関係となるイベント配信装置10の情報などを保持している。なお、本実施形態の説明では、転送経路情報を木構造として使用して説明するが、これは説明の便宜のためである。本発明の実施形態のイベント配信装置10は、後ほど説明するように、転送経路情報として木構造に限らず他の構造も適用することが出来る。また、本発明の実施形態のイベント配信装置10に適用する木構造としては、各種の構造、例えば、マルチキャストツリーや、スパニングツリーなどを適用することが可能である。この、網構成装置情報及び転送経路情報について、図6-図10を参照してさらに説明する。図6は、第1の実施形態に係るイベント配信システム1のネットワークの構成の一例を示す図である。イベント配信装置10である各ノードノードA,ノードB,...,ノードFが、イベント配信NW50を構成する。さらに、イベント配信NW50は、パブリッシャ20pub1,...とアプリケーション40App1,...,App1000,...が接続されている。なお、サブスクライバ30は、説明の便宜のため、省略した。また、サブスクリプションは、イベント配信NW50に登録済みとする。図7は、図6における網構成装置情報の一例を示す図である。図7Aは、図6のノードAの網構成装置情報を示し、図7Bは、図6のノードCの網構成装置情報を示している。図6の構成において、ノードAは、ノードBとノードCとノードEと接続しているため、ノードAの網構成装置情報は、図7Aに示すように、ノードB,ノードC,ノードEに関する情報を保持している。なお、図7Aは、ノードに関する情報としてノードIDを保存する例を示している。また、ノードCは、ノードA,ノードD,ノードEに接続しているため、図7Bに示すように、ノードCの網構成装置情報は、ノードA,ノードD,ノードEに関する情報図7BではノードIDを保持している。なお、網構成装置情報の登録は、ネットワークの管理者が予め設定しておいてもよく、また、例えばDHCPDynamicHostConfigurationProtocolなど一般的なネットワークのプロトコルを使用して登録すればよく、詳細な説明は省略する。なお、図6を含め、各図におけるネットワークでの各装置の接続は、論理的な接続を示している。従って、各装置などは、適宜、一般的なネットワークのプロトコルなどを使用して、図示しない論理的な接続を設けることが可能である。図8は、図6に示す第1の実施形態に係るイベント配信システム1のイベントの転送経路の一例を示す図である。イベントの転送経路の構造も、既に説明しているように、いろいろな構造を使用できるが、図8では、一例として、木構造を使用した場合を示している。図8において、所定のイベントのタイプ例えば、タイプ=衝撃に対するイベントの転送経路は、ノードAが最も上位アクセスポイントに位置し、その下にノードCとノードEとが、ノードEの下にノードFが接続する経路となっている。図9は、図8における転送経路情報の一例を示す図である。図8においてイベントの転送経路として木構造を使用しているため、接続しているノードの情報だけでなく、接続先ノードが経路上の下位子に関する情報も保持している。図8においてノードAは、ノードCとノードEに接続し、両方の親、つまりノードCとノードEとはノードAの子ノードであるため、図9に示すノードAの転送経路情報は、ノードCとノードEとの情報図9ではノードIDを保持している。なお、この転送経路情報は、後ほどさらに詳細に説明するが、イベント配信装置10に登録又は削除されるサブスクリプションを受けた場合、購読要求制御部104から指示を受けた経路制御部102が変更する。さらに、図10を参照して、イベントの配信について説明する。図10は、第1の実施形態に係るイベントの配信の一例を示す図である。ここで、一例として、パブリッシャ20pub1がイベントをパブリッシュする場合について説明する。パブリッシャ20pub1は、イベントをパブリッシュするためには、イベントの転送経路の最上位アクセスポイントにイベントをパブリッシュすることが必要である。そこでパブリッシャ20pub1は、例えば、接続されているノードCにアクセスポイントのノードを問い合わせ、アクセスポイントであるノードAの情報例えばノードIDなどを受け取る図10の経路1。その受け取った情報を基に、パブリッシャ20pub1は、アクセスポイントであるノードAにイベントをパブリッシュする図10の経路2。なお、パブリッシャ20pub1が、ノードAと論理的な接続がない場合もある。しかし、既に説明したとおり、本実施形態では、ネットワーク接続されている装置間に新たに論理的な接続を構築できる。そのため、パブリッシャ20pub1は、必要に応じてノードAと接続を構築し、その接続を使用して、ノードAにイベントをパブリッシュすることが出来る。イベントを受け取ったノードAは、イベントの転送経路の情報に沿ってイベントを転送する図10の経路3。イベントを受け取った各ノードノードA,ノードC,ノードFは、アプリケーション40app1,...,app3000にイベントを通知する図10の経路4。なお、ノードEは、アプリケーション40が接続されていないため、アプリケーション40に通知しない。図5を参照したイベント配信装置10の構成の説明に戻る。購読要求制御部104は、メッセージ転送部101を介して、サブスクライバ30からサブスクリプションの登録又は削除の指示を受け取り、購読要求保持部105が保存しているサブスクリプションを登録又は削除する。なお、本実施形態では、購読要求制御部104が受信したサブスクリプションが、サブスクリプションの登録の指示であるとして説明するが、これに限られるわけではない。例えば、本実施形態は、予めサブスクリプション登録しておき、その後、サブスクリプションIDなどを別途登録指示として受信しても良い。また、本実施形態の説明では、サブスクリプションの削除の指示は、サブスクリプションのIDを含むものとして説明する。なお、イベント配信装置10が受け取る削除の指示も、これに限られるわけではない。イベント配信装置10は、削除指示として、サブスクリプションのIDではなく、サブスクリプション自体を受け取ってもよい。また、削除指示を受けた場合でも、サブスクリプション自体は削除せず保持したままとし、削除後の登録動作でサブスクリプションIDに基づく登録指示を受け付けても良い。購読要求保持部105は、購読要求制御部104に制御されて、サブスクリプションを保持又は削除する。図11は、図3に示すサブスクリプションが購読要求保持部105に保持された場合の一例を示す図である。図11に示すサブスクリプションは、サブスクリプションを区別するサブスクリプションIDと、一致判定に使用するイベントパターンと、イベントの通知先であるアプリケーション40などを含む。イベント受信転送部106は、メッセージ転送部101を介してパブリッシャ20又は他のイベント配信装置10などからイベントを受け取る。続いて、イベント受信転送部106は、受け取ったイベントを一致判定処理のため、一致判定部107に渡す。また、イベント受信転送部106は、経路情報保持部103が保持している転送経路情報に沿って、イベントを転送forwardする。以下、この転送経路情報に沿って他のイベント配信装置10に転送するイベントを転送要求と言う。言い換えると、イベント受信転送部106は、経路情報保持部103が保持している転送経路情報を基に、イベントを転送するイベント配信装置10を取得し、メッセージ転送部101を介してイベントを他のイベント配信装置10に転送する。例えば、図8のノードAのイベント受信転送部106は、図9の転送経路情報を基に、受け取ったイベントをノードCとノードEに転送する。一致判定部107は、イベント受信転送部106から受け取ったイベントと購読要求保持部105に保持されているサブスクリプションとの一致を判定する。詳細に説明すると、一致判定部107は、受け取ったイベントと購読要求保持部105が保持しているサブスクリプションのイベントパターンとの一致を判定する。イベントとサブスクリプションのイベントパターンが一致した場合、一致判定部107は、受け取ったイベントをアプリケーション40に通知するイベントと判定し、一致したイベントと通知先とを通知制御部108に渡す。なお、この一致判定の結果として一致と判定されるサブスクリプションは、1つとは限らず、複数の場合もある。通知制御部108は、所定の条件以下、この条件を通知条件と言う。例えば、自装置の負荷状況などを基に、一致判定部107から受け取ったイベントを、自装置で通知するか、他のイベント配信装置10に通知を依頼するかを判定する。この他のイベント配信装置10にイベントの通知を依頼するメッセージ等を以下、代理要求と言う。この代理要求は、例えば、通知するイベントと、通知先などを含む。自装置でイベントを通知する場合、通知制御部108は、イベント通知部109に、一致判定部107から受け取ったイベントと通知先とを渡し、イベントを通知する。一方、他のイベント配信装置10に代理要求を送信する場合、通知制御部108は、イベントなどを基に代理要求を作成し、メッセージ転送部101を介して、他のイベント配信装置10に代理要求を送信する。なお、本実施形態の通知制御部108における自装置で通知するか否かの通知条件は、予め通知制御部108に保存されているものとする。ただし、これは、説明の便宜のためであり、通知制御部108とは別に図示しない保持部などに通知条件を保持してもよい。イベント通知部109は、通知制御部108、又は、後ほど説明する代理要求制御部110から受け取ったイベントと通知先とを基に、通知先のアプリケーション40にイベントを通知する。代理要求制御部110は、メッセージ転送部101を介して他のイベント配信装置10からの代理要求を受け取る。さらに代理要求制御部110は、代理要求条件保持部111が保持している代理要求に含まれるイベントを通知するか否かの条件以下、代理要求条件と言うを基に、代理要求に含まれるイベントを自装置で通知するか、他のイベント配信装置10にさらに代理を依頼するかを判定する。そして、代理要求制御部110は、自装置でイベントを通知すると判定した場合、受け取った代理要求に含まれるイベントと通知先とをイベント通知部109に渡し、イベントを通知する。また、他のイベント配信装置10に依頼すると判定した場合、代理要求制御部110は、代理要求をそのまま、又は、必要に応じて修正し例えば、後ほど詳細に説明するTTLの修正など、メッセージ転送部101を介して他のイベント配信装置10に送信する。代理要求条件保持部111は、予め他の装置又は管理者などに設定された、代理要求制御部110で使用する代理要求条件を保持している。図12は、第1の実施形態に係る代理要求条件の一例を示す図である。図12に示す代理要求条件は、代理要求を転送可能な残り回数であるTTLTimeToLiveと、代理要求に含まれるイベントを通知するか否かの判定に使用する装置の負荷条件の一例であるCPU利用率などを含む。なお、図12に示す代理要求条件のCPU使用率は、代理要求を依頼する場合のCPU使用率の最小値を示している。つまり、例えば1行目の50は、CPU使用率が50以上の場合、代理要求を依頼することを示している。また、図12の代理要求条件の最後の行のTTL=0、転送不可とは、TTL=0、つまり転送してはいけない代理要求の場合、どのようなCPU使用率でも、代理要求制御部110は、自装置でのイベントを通知することを示している。なお、図12ではCPU使用率を使用しているが、他の負荷条件を使用しても勿論良い。また、代理要求条件は、判定の方式などに基づき、保持するデータが当然異なってくる。例えば、代理要求条件は、処理負荷の条件として、上限値を保持してもよく、逆に、下限値を保持してもよい。また、代理要求条件は、範囲を示すデータを保持してもよい。なお、第1の実施形態に係るイベント配信装置10において、外部と接続する構成として、メッセージ転送部101とイベント通知部109を別構成としているが、これはあくまで説明の便宜のためである。本実施形態に係るイベント配信装置10は、メッセージ転送部101とイベント通知部109とを別構成とせず、ひとつの構成としてもよい。また、イベント通知部109も、通知制御部108などと同様に、メッセージ転送部101を介してイベントを通知してもよい。さらに、本実施形態に係るイベント配信装置10は、メッセージ転送部101を、2つ以上の構成、例えば、イベントとイベント以外のメッセージとを送受信するように分けてもよい。さらに、イベント配信装置10は、経路制御部102、購読要求制御部104、イベント受信転送部106、通知制御部108、代理要求制御部110ごとにメッセージ転送部101を備えてよい。さらに、各部がメッセージ転送部101の機能を取り込んでもよい。また、本実施形態に係るイベント配信装置10のイベント通知部109も、1つである必要はない。例えば、通知制御部108と代理要求制御部110とが、それぞれイベント通知部109を備えていてもよく、それぞれがイベント通知部109の機能を取り込んでもよい。次に、イベント配信装置10の動作について図面を参照して詳細に説明する。まず、メッセージ転送部101の動作を図13-図14を参照して説明する。図13及び図14は、第1の実施形態に係るメッセージ転送部101の動作の一例を示すフローチャート図である。図13と図14とは、共にメッセージ転送部101の一連の動作を示しているが、図13は、メッセージ転送部101の動作のうち、主として、自装置から他の装置にメッセージを送り出す動作に関連するフローチャート図となっている。まず、メッセージ転送部101は、メッセージを受け取るステップ1300。このメッセージは、以下で説明するように自装置内の各部及び外部の各装置などからメッセージ転送部101に送られてくる。続いて、メッセージ転送部101は、受け取ったメッセージの種類などを判定し、メッセージの種類などに基づいて処理を選択し、メッセージを送信する。なお、以下で説明する図13-14に示しているメッセージの判定の順番は、説明の便宜のためであり、順番が入れ替わってもよい。まず、メッセージ転送部101は、メッセージが他のイベント配信装置10に転送する転送要求か否かを判定するステップ1301。なお、既に説明しているが、他のイベント配信装置10への転送要求とは、イベントを転送経路情報に沿って他のイベント配信装置10に転送するためのメッセージである。そのため、転送要求は、イベント受信転送部106からメッセージ転送部101に渡される。転送要求と判定したメッセージ転送部101は、他のイベント配信装置10に転送要求を転送するステップ1321。転送要求ではないと判定したメッセージ転送部101は、他のイベント配信装置10への代理要求のメッセージか否かを判定するステップ1302。代理要求は、既に説明したとおり、他のイベント配信装置10にイベント通知を依頼するメッセージであり、通知制御部108、又は、代理要求制御部110からメッセージ転送部101に渡される。代理要求と判定したメッセージ転送部101は、他のイベント配信装置10に代理要求を送信するステップ1322。代理要求でもないと判定したメッセージ転送部101は、他の装置への登録要求又は離脱要求か否かを判定するステップ1303。後ほど、さらに説明するが、登録要求及び離脱要求は、イベント配信装置10の転送経路への参加又は離脱を要求するメッセージであり、経路制御部102からメッセージ転送部101に渡される。他のイベント配信装置10への登録要求又は離脱要求と判定したメッセージ転送部101は、他のイベント配信装置10に登録要求又は離脱要求を送信するステップ1323。さらに図14を参照して、メッセージ転送部101の動作の説明を続ける。図14は、図13の処理に続く処理である。ただし、図13とは異なり、主として他の装置から受け取るメッセージの処理に関するフローチャート図である。他のイベント配信装置10への登録要求又は離脱要求でないと判定したメッセージ転送部101は、サブスクライバ30から受け取ったサブスクリプションの関するメッセージか否かを判定するステップ1304。なお、ここでのサブスクリプションに関するメッセージとは、サブスクリプションの登録要求サブスクリプションを含む、サブスクリプションの削除要求削除要求のためのサブスクリプションIDを含むなどのどれか一部を含むメッセージのことである。サブスクリプションに関するメッセージと判定したメッセージ転送部101は、サブスクリプションに関するメッセージを購読要求制御部104に渡すステップ1324。サブスクリプションではないと判定したメッセージ転送部101は、パブリッシャ20からのイベントか否かを判定するステップ1305。イベントと判定したメッセージ転送部101は、受け取ったイベントをイベント受信転送部106に渡すステップ1325。イベントではないと判定したメッセージ転送部101は、他のイベント配信装置10から受け取った転送要求か否かを判定するステップ1306。転送要求と判定したメッセージ転送部101は、転送要求をイベント受信転送部106に渡すステップ1326。他のイベント配信装置10からの転送要求でもないと判定したメッセージ転送部101は、他のイベント配信装置10からの代理要求か否かを判定するステップ1307。他のイベント配信装置10からの代理要求と判定したメッセージ転送部101は、代理要求を代理要求制御部110に渡すステップ1327。他のイベント配信装置10からの代理要求でもないと判定したメッセージ転送部101は、他のイベント配信装置10からの登録要求又は離脱要求か否かを判定するステップ1308。他のイベント配信装置10からの登録要求又は離脱要求と判定したメッセージ転送部101は、登録要求又は離脱要求を経路制御部102に渡すステップ1328。他のイベント配信装置10からの登録要求又は離脱要求でもないと判定したメッセージ転送部101は、本実施形態の説明では処理を終了する。なお、本実施形態では、説明しないが、メッセージ転送部101は、ステップ1308でnoと判定した後、他の動作を処理しても良い。さらにメッセージ転送部101は、他のメッセージか否かを判定し、他のメッセージの沿った処理、例えば、網構成情報の変更を処理してもよく、さらに、判定不能な不正なメッセージとしてエラー処理を開始してもよい。なお、ここまでの図13-図14を用いた動作の説明において、メッセージ転送部101は、メッセージを基にメッセージの種類を判定するように説明したが、メッセージの送信元など別の情報を基に判定してもよい。次に、サブスクリプションに登録又は削除の動作について図15-図16を参照して説明する。最初に、サブスクリプションの登録動作について説明する。図15は、購読要求制御部104におけるサブスクリプションの登録動作の一例を示すフローチャート図である。メッセージ転送部101から受け取ったメッセージがサブスクリプションの登録要求に関するメッセージの場合、購読要求制御部104は、サブスクリプションを登録する。なお、ここでサブスクリプションの登録要求に関するメッセージは、例えば、図3に示したようなサブスクリプション登録指示としてのサブスクリプションなどを含む。サブスクリプションの登録に関するメッセージを受けた購読要求制御部104ステップ1501は、受け取ったサブスクリプションに含まれるイベントパターンに含まれるタイプを取得するステップ1502。続いて、購読要求制御部104は、そのタイプが購読要求保持部105に格納されているサブスクリプションの中に存在するか否かを確認するステップ1503。そのタイプが、購読要求保持部105に格納されているサブスクリプションの中に存在しない場合、イベント配信装置10は、そのタイプの転送経路に登録されていない。そのため、その場合、購読要求制御部104は、そのタイプの転送経路に自装置を参加させるために、経路制御部102に、受け取ったサブスクリプションのタイプを渡して、転送経路への登録要求を依頼するステップ1504。経路制御部102から経路参加の完了を受け取った購読要求制御部104は、受け取ったサブスクリプションを購読要求保持部105に登録するステップ1505。受け取ったサブスクリプションのタイプが既に購読要求保持部105に登録済みの場合、すなわち、自装置が既にそのタイプの転送経路を構成する装置である場合、購読要求制御部104は、経路制御部102に依頼しないで、サブスクリプションを購読要求保持部105に登録するステップ1505。なお、経路制御部102の動作については、後ほど詳細に説明する。次に、サブスクリプションの削除動作について説明する。図16は、購読要求制御部104における、サブスクリプションの削除の動作の一例を示すフローチャート図である。メッセージ転送部101から受け取ったメッセージがサブスクリプションの削除要求に関するメッセージであった場合、購読要求制御部104は、サブスクリプションを削除する。なお、ここでのサブスクリプションの削除要求に関するメッセージは、例えば、削除対象のサブスクリプションのサブスクリプションIDなどを含む。サブスクリプションの削除に関するメッセージを受けた購読要求制御部104ステップ1601は、受け取ったサブスクリプションIDに対応するサブスクリプションのイベントパターンのタイプを取得するステップ1602。なお、購読要求制御部104は、購読要求保持部105が保持しているサブスクリプションのサブスクリプションIDと受け取ったサブスクリプションIDを比較に基づき、指定されたサブスクリプションを取得する。さらに、購読要求制御部104は、購読要求保持部105に、そのタイプを持つ他のサブスクリプションがあるか否かを確認するステップ1603。そのタイプを持つ他のサブスクリプションがなかった場合、イベント配信装置10は、要求されたサブスクリプションを削除することにともない、自装置がそのタイプの転送経路に所属している必要がなくなる。そのため、購読要求制御部104は、そのタイプの転送経路から自装置を離脱させるために、経路制御部102に、そのタイプの転送経路からの離脱要求を依頼するステップ1604。経路制御部102における離脱の完了を受けて、購読要求制御部104は、購読要求保持部105から削除要求の対象となるサブスクリプションを削除するステップ1605。この場合の経路制御部102の動作についても後ほど説明する。そのタイプの他のサブスクリプションがある場合、イベント配信装置10は、削除対象のサブスクリプションを削除しても、そのタイプの転送経路を構成している。この場合、購読要求制御部104は、経路制御部102に依頼せず、削除要求されているサブスクリプションを購読要求保持部105から削除するステップ1605。次に、イベントの転送経路への参加動作及び離脱動作について図17-図20を参照して説明する。なお、参加動作などは、自装置が参加する動作と、他の装置から依頼を受けて参加させる動作との2種類がある。従って、それぞれについて順番に説明する。また、自装置が参加する場合の説明では、既に説明した購読要求制御部104からの依頼ステップ1504を契機とした動作について説明するが、転送経路のへの登録動作及び離脱動作は、それに限らず、例えば、システム管理者などの指示に基づき登録する場合もある。まず、転送経路への自装置を参加させる動作について説明する。図17は、経路制御部102における転送経路へ自装置を参加させるための動作の一例を示すフローチャート図である。購読要求制御部104から転送経路への参加を依頼された経路制御部102ステップ1701は、依頼を受けたタイプの転送経路に自装置を参加させる。この転送経路への参加動作は、一般的なネットワークへの参加動作と同様の動作でよい。その他、ここでは、例えば、非特許文献2に記載のPastryを使用する場合について説明する。まず、経路制御部102は、参加を依頼された転送経路のタイプにおけるアクセスポイントアクセスポイントがない場合はアクセスポイントに最も近いノードイベント配信装置10を選択するステップ1702。経路制御部102は、その選択したノードに、参加要求例えば、対象のタイプと、自装置を示す情報例えば装置IDなどと、参加要求であるメッセージなどを送信するステップ1703。経路制御部102は、参加を依頼後、必要に応じて実際に参加できたか否かを確認してもよい。また、購読要求制御部104から依頼されている場合は、経路制御部102は、購読要求制御部104に参加完了などを連絡する。次に、転送経路からの自装置を離脱する動作について説明する。図18は、経路制御部102における自装置を転送経路から離脱する動作の一例を示すフローチャート図である。離脱要求を受けた場合のステップ1801、経路制御部102は、一般的なネットワークからの離脱動作と同様に動作すればよい。例えば、経路制御部102は、経路情報保持部103の転送経路情報を用いて、指定されたタイプからの離脱要求を送信するノード例えば他のイベント配信装置10を1つ選択するステップ1802。選択後、経路制御部102は、メッセージ転送部101を介して選択したノードに離脱要求を送信するステップ1803。この離脱要求は、対象となるタイプと、自装置の情報装置IDなどとを含む。また、経路制御部102は、参加要求と同様に、離脱依頼後、必要に応じて実際に離脱できたか否かを確認してもよい。また、購読要求制御部104から依頼されている場合は、経路制御部102は、購読要求制御部104に離脱完了を連絡する。次に、他の装置から参加要求を受けた場合の動作について説明する。図19は、他のイベント配信装置10から、転送経路に参加する要求を受けた場合の経路制御部102の動作の一例を示すフローチャート図である。経路制御部102は、他イベント配信装置10から転送経路への参加要求を受信した場合ステップ1901、自装置の経路情報保持部103の転送経路情報に、受信した参加要求のタイプの転送経路があるか否かを確認するステップ1902。受信した参加要求のタイプの転送経路が転送経路情報にない場合、経路制御部102は、さらに、購読要求保持部105にそのタイプを持つサブスクリプションが登録されているか否かを確認するステップ1903。購読要求保持部105にそのタイプを持つサブスクリプションが登録されていない場合、経路制御部102は、網構成装置情報から、そのタイプの転送経路への参加要求を送信するためのイベント配信装置10を所定の処理を用いて1つ選択するステップ1904。選択後、経路制御部102は、選択したイベント配信装置10にメッセージ転送部101を介して参加要求を送信するステップ1905。なお、参加要求は、参加対象のイベントのタイプ、自装置を示す情報例えば装置IDなどを含む。送信後、経路制御部102は、経路情報保持部103に、対象となっているタイプの転送経路情報を作成するステップ1906。さらに、経路制御部102は、参加要求を送信してきたイベント配信装置10を示す情報例えば装置IDを転送経路情報に追加するステップ1907。購読要求保持部105にそのタイプを持つサブスクリプションが登録されている場合、すなわち、例えば、イベントの転送経路が木構造なら、自装置が転送経路情報に基づいて構築されるイベントの転送の木構造の葉となる場合、経路制御部102は、経路情報保持部103にそのタイプの転送経路情報を作成するステップ1906。そして、経路制御部102は、経路情報保持部103の転送経路情報に、転送経路情報に参加要求を送信してきたイベント配信装置10を示す情報例えば装置IDを追加するステップ1907。また、受信したタイプの転送経路情報がある場合、経路制御部102は、転送経路情報に、参加要求を送信してきたイベント配信装置10を示す情報例えば装置IDを追加するステップ1907。続いて、他のイベント配信装置10から離脱要求を受けた場合の動作について説明する。図20は、離脱要求を受け取った経路制御部102の動作の一例を示すフローチャート図である。他のイベント配信装置10から離脱要求を受信した場合ステップ2001、経路制御部102は、経路情報保持部103に保持されている転送経路情報に、依頼元以外のイベント配信装置10が登録されているか否かを確認するステップ2002。そのタイプの転送経路情報に受信したイベント配信装置10の装置以外の装置の登録がない場合、経路制御部102は、購読要求保持部105に対象のタイプを持つサブスクリプションが登録されているか否かを確認するステップ2003。購読要求保持部105にそのタイプを持つサブスクリプションが登録されていない場合、経路制御部102は、経路情報保持部103の網構成装置情報から、そのタイプの転送経路からの離脱要求を送信するイベント配信装置10を所定の処理を用いて1つ選択するステップ2004。選択後、経路制御部102は、メッセージ転送部101を介して、選択したイベント配信装置10に離脱要求を送信するステップ2005。メッセージ転送部101を介して離脱要求を送信後、経路制御部102は、そのタイプの転送経路情報を削除するステップ2006。購読要求保持部105にそのタイプを持つサブスクリプションが登録されている場合、経路制御部102は、そのタイプの転送経路情報を削除するステップ2006。経路情報保持部103が保持している受信したタイプの転送経路情報に、受信したイベント配信装置10の装置以外の装置が登録されている場合、経路制御部102は、そのタイプの転送経路情報から受信したイベント配信装置10の装置情報を削除するステップ2007。続いて、イベントを受けた場合の動作について図21-24などを参照して詳細に説明する。まず、パブリッシャ20からイベント受け取ったイベント受信転送部106の動作について図面を参照して説明する。図21は、イベント受信転送部106がイベントを受けたときの処理の一例を示すフローチャート図である。パブリッシャ20からメッセージ転送部101を介してイベントを受け取ったイベント受信転送部106はステップ2101、一致判定部107にイベントを渡すステップ2102。次に、イベント受信転送部106は、イベントのタイプを取得するステップ2103。イベント受信転送部106は、そのタイプの転送経路情報が経路情報保持部103にあるか否かを確認するステップ2104。そのタイプの転送経路情報が存在する場合、イベント受信転送部106は、転送経路情報を参照して、イベントを転送する装置を判定する。例えば、転送経路情報が木構造の場合、この判定は、自装置に対して子となるイベント配信装置10を求めることである。そして、イベント受信転送部106は、メッセージ転送部101を介して、転送先のイベント配信装置10に、受け取ったイベントの転送要求を転送するステップ2106。なお、転送する転送要求には、例えば、イベントと、転送先イベント配信装置10の装置情報例えば装置IDなどとを含んでもよい。イベント受信転送部106は、転送経路情報に子として登録されている全てのイベント配信装置10に対して転送要求を転送するステップ2105。一方、そのタイプの転送経路情報が存在しない、又は、転送経路情報に転送する装置の登録がない場合、イベント受信転送部106は、処理を終了する。この動作をさらに具体的に図8を参照して動作を説明する。例えば、図8のノードAのイベント受信転送部106が、図1に示すEvent1タイプ=衝撃、センサID=ID1、衝撃データ=50、場所=東京都港区、時刻=10:10:25を受信したとするステップ2101。イベント受信転送部106は、そのイベントEvent1を一致判定部107に渡すステップ2102。次に、イベント受信転送部106は、そのイベントからイベントのタイプ衝撃を取得しステップ2103、ノードAの経路情報保持部103に保持されているタイプ衝撃の転送経路情報が存在するか否かを判定する。ここで図9がタイプ衝撃の転送経路情報とする。ノードAの転送経路情報にタイプ衝撃に転送先の子となるノードが存在するので、イベント受信転送部106は、そのタイプの転送経路情報の各ノード図9のノードCとノードEに対して、メッセージ転送部101を介してイベントの転送要求を転送するステップ2106。次に、一致判定部107の動作について図面を参照して説明する。図22は、一致判定部107における一致判定処理の一例を示すフローチャート図である。イベントを受け取った一致判定部107はステップ2201、イベントと購読要求保持部105に保持されているサブスクリプションのイベントパターンとの一致を判定するステップ2203。一致判定の結果、イベントがサブスクリプションに一致した場合、一致判定部107は、一致したサブスクリプションの通知先とイベントとを通知制御部108に渡すステップ2204。なお、一致判定部107が、イベントとサブスクリプションとを通知制御部108に渡し、通知制御部108が通知先を取り出してもよい。イベントがサブスクリプションと一致しない場合、一致判定部107は、次のサブスクリプションとの一致を判定する。一致判定部107は、全てのサブスクリプションについてこの動作を繰り返すステップ2202。さらに具体的に説明すると、例えば、図10のノードAの一致判定部107が、図1に示すEvet1タイプ=衝撃、センサID=ID1、衝撃データ=50、場所=東京都港区、時刻=10:10:25を受信したとするステップ2201。このとき、一致判定部107は、購読要求保持部105に保持されているサブスクリプションとイベントとの一致を判定するステップ2203。ここで、図11に示すサブスクリプションが購読要求保持部105に保持されていたとする。図11の1行目のサブスクリプションが、イベントEvent1と一致するので、一致判定部107は、サブスクリプションの通知先app1などと、イベントタイプ=衝撃、センサID=ID1などを通知制御部108に渡すステップ2204。一致判定部107は、この処理を全てのサブスクリプションに対して実施するステップ2202。続いて、通知制御部108の動作について図面を参照して説明する。図23は、通知制御部108における、イベントの通知処理の一例を示すフローチャート図である。一致判定部107からイベントと通知先とを受け取った通知制御部108はステップ2301、自装置の負荷状態を取得する。この動作は、例えば、通知制御部108が、図示しないモニタ部などから自装置の負荷の一例であるCPU使用率などを取得する動作である。次に、通知制御部108は、現在の装置の負荷と、通知制御部108などに予め設定されている通知条件、例えば負荷の閾値とを比較するステップ2302。自装置の負荷が通知条件である閾値より大きい、つまり負荷が重い場合ステップ2302でyes、イベント配信装置10は、自装置では所定の時間内でイベントを通知することができない。そのため、通知制御部108は、他のイベント配信装置10にそのイベントの通知の代理要求を送信する。そこで、通知制御部108は、経路情報保持部103に保持されている網構成装置情報から代理要求を送信するイベント配信装置10を後ほど説明する処理を用いて1つ選択するステップ2303。選択後、通知制御部108は、選択したイベント配信装置10に送る代理要求を作成し、メッセージ転送部101を介して選択したイベント配信装置10に代理要求を送信するステップ2304。なお、この代理要求は、一致判定部107から受け取ったイベントと通知先とに加え、さらに予め通知制御部108に設定されている又はイベントのタイプなどから通知制御部108が決めるTTLTimetoLifeを含む。なお、通知制御部108におけるイベント配信装置10の選択としては、いろいろな処理や方式を採用することが出来る。第1の実施形態に係る通知制御部108は、網構成装置情報から自装置以外のイベント配信装置10をランダム無作為に選択している。しかし、これは、あくまで本実施の形態の選択の一例であり、通知制御部108は、他の処理を採用してもよい。例えば、通知制御部108は、経路情報保持部103に保持されている網構成装置情報に登録されているイベント配信装置10を順番に選択してもよい。一方、自装置の負荷が通知条件である閾値より小さい、つまり負荷が軽い場合、イベント配信装置10は、自装置で所定の時間内にイベントを通知できる。そのため、通知制御部108は、自装置のイベント通知部109を用いてイベントを通知すると判定し、一致判定部107から受信したイベントと通知先とをイベント通知部109に渡すステップ2305。なお、ここまで、第1の実施形態に係る通知制御部108は、自装置の負荷状態を判定するための通知条件を、予め通知制御部108に設定されているとして説明した。しかし、後ほど詳細に説明する代理要求制御部110のように、通知制御部108は、通知条件を通知制御部108の外部に保持してもよい。通知制御部108の動作について、具体的にデータの一例を使用して説明する。説明の便宜のため、イベント配信装置10を図10のノードAとして説明する。また、説明の便宜のため、通知条件の装置負荷として、CPU使用率を使うこととし、閾値のCPU使用率を70とする。また、現在のノードAのCPU使用率を80とする。また、TTLの初期値を2とする。ノードAの通知制御部108が、一致判定部107から、イベント例えば図1のEvent1とその通知先app1,app2,app3,...,app1000とを受信したとするステップ2301。通知制御部108は、CPU使用率の閾値70と、自装置のCPU使用率を比較するステップ2302。今、自装置のCPU使用率を80としているので、通知制御部108は、負荷が重いとして、代理要求を送信すると判定するステップ2302のyes。続いて、通知制御部108は、代理要求を送信するイベント配信装置10を選択する。そのため、通知制御部108は、経路情報保持部103の網構成装置情報例えば図7Aからイベント配信装置10ノードを1つランダムに選択するステップ2303。ここでは、ノードCが選ばれたとする。次に、通知制御部108は、メッセージ転送部101を介して、選択したノードCに代理要求を送信するステップ2304。なお、ここでの代理要求は、例えば、Event=タイプ=衝撃、センサID=ID1、衝撃データ=50、場所=東京都港区、時刻=10:10:25、送付先=app1,app2,app3,...,app1000、TTL=2となる。次に、イベント通知部109の動作について図面を参照して説明する。図24は、イベント通知部109におけるイベント通知処理の一例を示すフローチャート図である。通知制御部108からイベントと通知先とを受け取ったイベント通知部109はステップ2401、通知先に登録されているすべてのアプリケーション40に対してステップ2402、受信したイベントを通知するステップ2403。なお、他のイベント配信装置10から転送要求としてイベントを受け取ったときの処理は、既に説明したパブリッシャ20からイベントの受け取ったときの処理において、イベントを転送要求に変更すれば同様の処理となるため、動作の詳細な説明を省略する。また、転送要求を受け取った転送先であるイベント配信装置10も、イベントを転送要求に変更することで同様に動作できる。続いて、代理要求を受けた場合の動作について図面を参照して説明する。図25は、代理要求制御部110の代理要求の処理の一例を示すフローチャート図である。メッセージ転送部101を介してイベントの代理要求を受信した代理要求制御部110はステップ2501、受け取った代理要求のTTLに対応する代理要求条件保持部111に保持されている代理要求条件のTTLに基づき装置負荷の条件を取得するステップ2502。次に、代理要求制御部110は、図示しないモニタ部などから自装置の負荷状態を取得し、先ほど取得した代理要求条件の負荷条件と比較するステップ2503。もし、自装置のそのときの負荷が、代理要求条件の負荷条件より重い場合、代理要求制御部110は、他のイベント配信装置10にイベントの通知の代理を依頼すると判定する。そして、代理要求制御部110は、代理要求を送信する装置を所定の方式で選択するステップ2504。この選択は、例えば、代理要求制御部110が、経路情報保持部103の網構成装置情報からランダムにイベント配信装置10を1つ選択する。選択後、代理要求制御部110は、メッセージ転送部101を介して、選択したイベント配信装置10に代理要求を送信するステップ2505。なお、第1の実施形態では、代理要求が転送の可能回数を示すTTLを備えている。そのため、代理要求制御部110は、受け取った代理要求のTTLを修正し、その修正後のTTLを含む代理要求を送信する。ここでの代理要求制御部110の修正は、例えば、代理要求が1台の装置を経由するため、単純にTTLの回数を1回分減らすことが想定される。また、イベントのタイプ、又は、イベント配信装置10が代理要求処理に必要とした処理時間に従って、TTLの値を2以上削減するなど、代理要求制御部110は、代理要求を受け付けた装置でTTLを使用して判断する場合に適切な値にTTLを修正してもよい。一方、代理要求制御部110の処理に掛かった時間が通知までの時間に影響が少ない例えば無条件で代理要求を転送した場合など特段の条件がある場合、代理要求制御部110は、TTLを変更しなくてもよい。一方、自装置の負荷が代理要求条件より軽い場合、代理要求制御部110は、自装置でイベントを通知すると判定する。そして、代理要求制御部110は、代理要求で指定されたイベントと通知先とをイベント通知部109に渡しステップ2506、イベントを通知する。代理要求制御部110からイベントと通知先とを受け取ったイベント通知部109の動作は、通知制御部108からイベントと通知先とを受けたときと同様のため、詳細な説明は省略する。この代理要求を受けた場合の動作について、具体的に説明すると次のようなる。例えば、図10のノードCの代理要求制御部110が、メッセージ転送部101を介し、ノードAから代理要求を受信したとするステップ2501。この場合の代理要求として、先に説明したノードAが送信した代理要求とする。つまり、代理要求は、Event=タイプ=衝撃、センサID=ID1、衝撃データ=50、場所=東京都港区、時刻=10:10:25、送付先=app1,app2,app3,...,app1000、TTL=2を用いて説明する。ノードCの代理要求制御部110は、代理要求のTTLを取得する。この場合、TTL=2となる。次に、ノードCの代理要求制御部110は、代理要求条件保持部111の代理要求条件これは図12とするのTTL=2のCPU使用率を取得するステップ2502。この場合、CPU使用率は60である。つまり、自装置のCPU使用率が60以上の場合は、自装置の負荷が重いとして代理要求を通知する。次に、ノードCの代理要求制御部110は、自装置の負荷状態と代理要求条件とを比較するステップ2503。いま、仮にノードCのCPUの使用率が70とする。ノードCの代理要求制御部110は、自装置の負荷が代理要求条件より重いため、代理要求を送信すると判定する。次に、ノードCの代理要求制御部110は、転送先として経路情報保持部103の網構成装置情報から、例えば、ランダムにイベント配信装置10を選択するステップ2504。ここでは、ノードDを選択したとして説明を続ける。ノードCの代理要求制御部110は、ノードAから受信した代理要求のTTLの値2を1つ減らしたデクリメントした代理要求を作成し、メッセージ転送部101を介し、ノードDに送信するステップ2505。この場合の代理要求は、Event=タイプ=衝撃、センサID=ID1、衝撃データ=50、場所=東京都港区、時刻=10:10:25、通知先=app1,app2,app3,...,app1000、TTL=1となる。ノードCから代理要求を受け取ったノードDの代理要求制御部110はステップ2501、代理要求のTTLを取得する。ここで受け取る代理要求は、既に説明したEvent=タイプ=衝撃、センサID=ID1、衝撃データ=50、場所=東京都港区、時刻=10:10:25、通知先=app1,app2,app3,...,app1000、TTL=1である。次に、代理要求制御部110は、TTL=1に対応する代理要求条件のCPU使用率を取得する図12の場合、CPU使用率=80。代理要求制御部110は、このCPU使用率と自装置CPU使用率を比較するステップ2503。ここで、例えば、ノードDのCPU使用率が70であったとする。ノードDの代理要求制御部110は、自装置CPU使用率70が代理要求条件のCPU使用率80より軽いため、自装置でイベントを通知すると判定する。そして、ノードDの代理要求制御部110は、代理要求のイベントと通知先とをイベント通知部109に渡しステップ2506、イベントを通知する。なお、図10では、ノードDからアプリケーション40app1,app2,...,app1000への接続経路が図示されていない。しかし、既に説明したとおり、ノードは、接続経路を新たに接続することが出来る。そのため、ノードDから通知先のアプリケーション40へのイベント通知においても、ノードDは、アプリケーション40と新たに接続を構築してイベントを通知する。このような動作に基づき、あるイベント配信装置10上の説明ではノードAの負荷が重く、自装置では所定の時間でイベントを通知できない場合でも、他の通知化可能な負荷状態のイベント配信装置10上の説明ではノードDまで、順次イベントの代理要求が転送される。そして、イベント通知の条件を満たすイベント配信装置10上の説明ではノードDが、イベントを通知先のアプリケーション40に通知する。なお、本実施形態の説明では、まずTTLを比較する処理としているが、本実施形態の係るイベント配信装置10は、CPU使用率など負荷状態から比較しても勿論良い。また、本実施形態に説明において、イベント配信装置10の処理の負荷の要因としては、アプリケーション40にイベントを通知する処理及び他のイベント配信装置10にイベントを転送する処理などが想定される。本実施形態は、そのどちらか、又は、両方から発生する負荷に対して適用出来る。さらに、本実施形態のイベント配信装置10は、そのような要因だけでなく、他の要因から発生する負荷に対しても対応することが出来る。ここまで説明してきた、図8などのイベント配信装置10のイベントの転送経路は、サブスクリプションを基に構築した木構造の転送経路である。しかし、本発明が適用出来るイベントの転送経路は、これに限られるわけではなく、他の転送経路でもよい。図26は、イベント配信NW60の別のイベントの転送経路の一例を示す図である。図26の転送経路において、イベント配信装置10である各ノードノードA,...,ノードFは、各イベントの通知を担当するように構成されている。例えば、ノードAは、イベントのタイプ衝撃を担当し、タイプ衝撃のイベントを通知し、ノードBは、イベントのタイプ開閉を担当し、タイプ開閉のイベントを通知する。なお、異なるタイプでも、通知先のアプリケーション40が同じ場合もあるため、異なるノードが同じアプリケーション40に接続する場合もあるが、図26では説明の便宜のため、各ノードは、それぞれ別のアプリケーション40に接続する例を示している。このように構成された図26の示すイベント配信NW60の動作についてさらに説明する。なお、サブスクリプションの登録、イベントの転送、代理要求の送信などは、既に説明したイベント配信NW50の動作と同様のため、詳細な説明は省略し、図26に示すイベント配信NW60において、イベント配信NW50と異なる動作について詳細に説明する。イベント配信NW60における転送経路情報は、各イベントの担当となるノードの情報を保持している。図27は、イベント配信NW60における転送経路情報の一例を示す図である。図27において、例えば、イベントのタイプ衝撃は、ノードAが担当となっていることを示している。また、イベント配信装置10ノードは、自装置が通知を担当するイベントを判定する情報として、図27の転送経路情報を使用することも出来る。つまり、イベントのタイプのノードIDが自ノードの場合、自装置がイベントの通知を担当していると判定することが出来る。以下では、図27に示すノードAがイベントのタイプ衝撃を担当している場合について説明する。図26に示すノードAに接続しているパブリッシャ20pub1が、タイプ衝撃のイベントをパブリッシュした場合、ノードAがそのイベントを受け取り、イベントのタイプから担当するノードを判定する。今の場合、ノードAは、自装置が担当するイベントと判定する。ノードAは、自装置担当のイベントのため、自装置でアプリケーション40app1,...,app100にイベントを通知する。次に、ノードA以外のノードに接続しているパブリッシャ20例えばノードEに接続しているpub101が、タイプ衝撃のイベントをパブリッシュした場合について説明する。イベントを受けたノードEは、転送経路情報を基にイベントのタイプからイベントの担当のノードを判定する。この場合、ノードEは、自装置の担当でないと判定する。さらに、自ノードの担当のイベントでないと判定したノードEは、転送経路情報を基にイベントを担当するノードを判定し、そのノード今の場合はノードAにイベントを転送する。イベントの転送を受けたノードAは、自装置が担当するイベントのため、アプリケーション40app1,...,app100にイベントを通知する。ここで、イベントの大量発生などで、イベントの通知を担当するイベント配信装置10例えばノードAの負荷が重くなった場合、イベント配信装置10の通知制御部108は、既に説明したように代理要求を送信する。この代理要求を用いてイベント配信装置10は、他のイベント配信装置10にアプリケーション40への通知の代理を依頼する。このように動作する図26に示したイベント配信NW60におけるイベントの転送処理は、最大でも1回しか発生しない。つまり、イベント配信NW60において、イベントの通知を担当しているノードノードAがイベントを受け取った場合は、イベントの転送処理の必要が無い。また、その他のノード例えばノードEがイベントを受け取った場合は、イベントを受け取ったノードがイベントの通知担当のノードノードAにイベントを転送する。そして、そのイベントを受け取ったイベントの通知担当のノードは、イベントを通知することが出来る。一方、図8に示すイベント配信NW50では、イベント毎に、転送経路情報に登録された全てのノードにイベントを転送する。前に説明した例では、イベント配信NW50のイベントの転送は、ノードC,ノードE,ノードFへと転送を3回必要とした。このように、イベント配信NW60は、イベント発生時の転送処理が、イベント配信NW50と比べ、少なくすることが出来る。ただし、イベント配信NW50では、通常状態でも既に説明した木構造など複数イベント配信装置10がイベントを通知している。そのため、イベントが大量発生しても、ある程度まではイベントの通知処理の負荷が複数のイベント配信装置10の間で分散される。一方、図26に示すようなイベント配信NW60は、通常、イベントを1つのイベント配信装置10が通知するため、イベントの大量発生に基づくイベント配信装置10での負荷の増大を引き起こしやすい。従って、図26に示すイベント配信NW60のように構成されたイベント配信装置10は、本発明の効果を、さらに有効に享受することが出来る。なお、第1の実施形態に係るイベント配信装置10において、各構成を別構成として説明したが、これは説明の便宜のためである。これらの一部又は全体をまとめた構成としてもよい。例えば、本実施形態に係るイベント配信装置10は、各保持部を1つの記憶装置で実現してもよく、2つ以上の制御部をまとめた制御部としてもよい。また、本実施形態に係るイベント配信装置10は、プログラムに基づいて動作する1つ又は2つ以上のコンピュータとして実現してもよい。なお、プログラムは、図示しない1つ又は2つ以上の記憶媒体に格納される。一方、第1の実施形態に係るイベント配信装置10の各構成部を別装置として構成してもよい。図28は、第1の実施形態に係るイベント配信システム2の別の構成の一例を示すブロック図である。図28のイベント配信システム2において、図5と同じ構成には、同じ番号を付し、詳細な説明は省略し、図5と異なる構成について詳細に説明する。図28に示すイベント配信システム2は、図5のイベント配信装置10と同様に、ネットワークなどで接続されたメッセージ転送装置71と、経路制御装置72と、購読要求制御装置73と、通知制御装置74と、代理要求制御装置75と、イベント通知装置76とを含む。メッセージ転送装置71は、図5に示すメッセージ転送部101と同様に動作し、イベント通知装置76は、図5に示すイベント通知部109と同様に動作する。また、経路制御装置72は、図5の経路制御部102と経路情報保持部103とを含む。購読要求制御装置73は、図5の購読要求制御部104と購読要求保持部105とを含む。通知制御装置74は、図5のイベント受信転送部106と一致判定部107と通知制御部108とを含む。代理要求制御装置75は、図5の代理要求制御部110と代理要求条件保持部111とを含む。なお、図28に示すイベント配信システム2は、各装置をそれぞれ1つ含むが、それぞれの装置を2台以上の含んでもよい。このような構成に基づき、通知制御装置74又は代理要求制御装置75は、自装置の負荷が重く所定の時間でイベントを通知できない場合、図5に示したイベント配信装置10と同様に他の装置などにイベントの通知の代理を依頼することが出来る。また、本実施形態は、イベントの配信と代理要求の処理とをまとめた装置をイベント配信装置とすることも出来る。図29は、第1の実施形態に係るイベント配信装置の別の構成の一例を示すブロック図である。図29において、図5と同じ構成は同じ番号を付してある。イベント配信装置11は、購読要求保持部105と通知制御部108と代理要求制御部110と代理要求条件保持部111と通知条件保持部112とを含む。通知制御部108は、接続しているネットワークからイベントを受信し、購読要求保持部105が保持しているサブスクリプションと比較し、一致した場合に、イベントを通知する。ただし、通知制御部108は、通知条件保持部112が保持している通知条件を基に、自装置でイベントを通知するか、代理要求をネットワーク経由で他のイベント配信装置11既に説明したイベント配信装置10などでもよい。などに送信するかを判定して、イベントを通知又は代理要求を送信する。代理要求制御部110は、既に説明したイベント配信装置10の代理要求制御部110と同様に、代理要求を受けた場合、代理要求条件を基に、自装置で受け取った代理要求のイベントを通知するか、さらに他の装置に代理要求と送るかを判定して、イベントを通知又は代理要求を送信する。このような、イベント配信装置11は、自装置でイベントを通知するか、他の装置に代理要求を送信するかを自装置の負荷等に基づき切り替えることが出来る。また、イベント配信装置11を1つの装置ではなく、複数の装置として構成してもよい。図30は、イベント配信装置11の通知制御部108を中心としたイベント配信装置12の一例を示すブロック図である。イベント配信装置12は、購読要求保持部105と、通知制御部108と、通知条件保持部112とを含む。イベント配信装置12の各部の構成及び動作は、図29に示すイベント配信装置11の各部の構成及び動作と同様のため、それぞれ同じ番号を付し、詳細な説明は省略する。図31は、同様に、イベント配信装置11の代理要求制御部110を中心としたイベント配信装置13の一例を示すブロック図である。イベント配信装置13は、代理要求制御部110と代理要求保持部111とを含む。イベント配信装置13の各部の構成及び動作は、図29に示すイベント配信装置11の各部の構成及び動作と同様のため、同じ番号を付し、詳細な説明は省略する。第1の実施形態に係るイベント配信装置10以下、イベント配信装置11及びイベント配信システム2なども含むは、自装置の負荷が重くなったときでも、所定の時間でアプリケーション40にイベントを通知することが出来る効果を有する。その理由は、イベントを通知するイベント配信装置10の処理負荷が所定の閾値より重くなった場合、他のイベント配信装置10にイベントの通知を代理要求として依頼し、負荷の軽い他のイベント配信装置10にイベントの通知を依頼することが出来るためである。さらに、第1の実施形態に係るイベント配信装置10は、代理要求を受け取ったイベント配信装置10の装置負荷が重い場合でも、所定の時間でアプリケーション40にイベントを通知することが出来る効果を有する。また、第1の実施形態に係るイベント配信装置10は、イベントが突然大量に発生した場合でも、イベント発生からイベント通知までの時間を確保してイベントを通知することが出来る効果を有する。その理由は、代理要求を受けた他のイベント配信装置10においても、自装置の負荷と代理要求と代理要求条件とを基に、自装置の負荷が重い場合には、さらに他のイベント配信装置10にイベント通知の代理を代理要求として送信することが出来るためである。第2の実施形態第1の実施形態に係るイベント配信装置10の説明では、代理要求条件の一例として、イベント配信装置10の負荷条件、具体的にはCPU使用率とTTLとを用いた場合について説明した。しかし、既に説明したとおり、代理要求条件は、これに限られるわけではない。例えば、アプリケーション40とイベント配信装置10とのネットワークの混雑状態、アプリケーション40側の状態、又は、イベント通知部109の通信障害などに応じて、イベントがイベント通知部109に溜まる場合もある。つまり、イベント配信装置10のCPU使用率などのイベント配信装置10の負荷とは無関係に、イベントを所定の時間で通知できないことが発生する場合もある。第2の実施形態に係るイベント配信装置10は、代理要求条件として、イベント通知部109において蓄えられているイベントの量、すなわち、イベント通知部109がアプリケーション40に通知するイベント数に相当する条件で判定する。なお、本実施形態の説明は、イベント数に相当する量の一例として、イベント通知部109のイベント保存用のバッファに蓄えられているデータ量を使用して説明する。また、第2の実施形態に係るイベント配信装置10の構成及び動作は、通知制御部108と、代理要求制御部110と、代理要求条件保持部111とを除き、第1の実施形態に係るイベント配信装置10と同じである。そのため、同じ構成と動作に関する詳細な説明は省略し、第2の実施形態に係るイベント配信装置10に特有の部分を中心に詳細に説明する。第2の実施形態に係る通知制御部108は、通知条件として、予めイベント通知部109のバッファ量に対するバッファ閾値を保存している。また、第2の実施形態に係る代理要求条件保持部111も、同様に、保存されている条件としてバッファ量とTTLとなっている。そのため、代理要求制御部110も、同様に、イベント通知部109のバッファ量を使用して判定する。このように構成されているイベント配信装置10の動作をついてさらに説明する。第2の実施形態に係る通知制御部108は、第1の実施形態に係る通知制御部108におけるCPU使用率を使用した判定図23のステップ2302に相当をイベント通知部109のバッファ量を使用して判定する。さらに詳細に説明すると、通知制御部108は、第1の実施形態において図示しないモニタ部などから自装置のCPU使用率を取得する代わりに、イベント通知部109から使用中のバッファ量を受け取る。そして、通知制御部108は、受け取ったバッファ量と通知条件として保持しているバッファ量の閾値とを比較し、閾値より使用中のバッファ量が多い場合は、自装置の負荷が重いと判定して、受け取ったイベントを代理要求として、他のイベント配信装置10に送る。それ以外の処理は、第1の実施形態に係る通知制御部108と同様である。第2の実施形態に係る代理要求制御部110も、第1の実施形態に係る代理要求制御部110におけるCPU使用率を使用した判定図25のステップ2503に相当の代わりに、イベント通知部109のバッファ量を使用して判定する。さらに詳細に説明すると、代理要求を受け取った代理要求制御部110は、代理要求条件保持部111から、代理要求条件を取得する。そして、代理要求制御部110は、代理要求のTTLに対応する代理要求条件のバッファ量を取得する。さらに、代理要求制御部110は、イベント通知部109から現在のバッファ量を取得する。代理要求制御部110は、イベント通知部109のバッファ量と代理要求条件のバッファ量の閾値とを比較する。イベント通知部109のバッファ量が少ない場合は、代理要求制御部110は、自装置でイベントを通知すると判定する。以降のイベントの通知処理は、第1の実施形態と同じため、詳細な説明は省略する。一方、バッファ量が閾値より多い場合は、代理要求制御部110は、自装置負荷が重いため代理要求を送信すると判定する。この判定後の動作も第1の実施形態と同様のため、詳細な説明は省略する。第2の実施形態に係るイベント配信装置10は、第1の実施形態に係るイベント配信装置10の効果に加え、イベント通知部109におけるバッファのオーバーフローを防ぐ効果を有する。その理由は、第2の実施形態に係るイベント配信装置10は、イベント通知部109のバッファ量を基に、代理転送を送信するか否かを判定しているため、イベント通知部109のバッファがオーバーフローする前に代理要求を送信することが出来るためである。第3の実施形態第2の実施形態に係るイベント配信装置10では、代理要求条件として、イベント通知部109のバッファに蓄えられているデータ量を使用したが、イベント配信装置10は、代理要求条件として、イベント通知部109のバッファに蓄えられているイベントのイベント発生時刻とすることも出来る。第3の実施形態のイベント配信装置10は、代理要求条件として、イベント通知部109に蓄えられているイベントのイベント発生時刻条件で判定する。なお、第3の実施形態に係るイベント配信装置10の構成及び動作は、第2の実施形態と同様に、通知制御部108と、代理要求制御部110と、代理要求条件保持部111とを除き、第1の実施形態に係るイベント配信装置10と同じである。そのため、同じ構成と動作に関する詳細な説明は省略し、第3の実施形態に係るイベント配信装置10に特有の部分を詳細に説明する。第3の実施形態における通知制御部108は、受け取ったイベントを自装置で通知するか代理転送を要求するかの判定を、イベント通知部109に蓄えられている最も古いイベントの発生時刻を基に判定する。通知制御部108は、例えば図示しない計時装置などから取得した現在時刻と、最も古いイベントと登録時間との差、つまりイベントの滞留時間に基づき判定する。そのため、第3の実施形態に係る通知制御部108は、通知条件として滞留時間を閾値として保存している。この滞留時間の閾値と、イベント通知部109に残っているイベントの滞留時間とを比較し、通知制御部108は、自装置でイベントを通知するか、他のイベント配信装置10に代理要求を送信するかを判定している。つまり、滞留時間が閾値を超えている場合、所定の時間ではイベント通知ができないとして、通知制御部108は、代理要求を送信する。その他の動作は、第1及び第2の実施形態の同様のため詳細な説明は省略する。なお、第3の実施形態の通知制御部108は、イベント通知部109からイベントを引き上げてもよい。このような構成に基づき、例えば、通知制御部108が、イベント通知部109に保存されているイベントのうち、所定の滞留時間を経過しても通知できないイベントを引き上げる。そして、通知制御部108は、引き上げたイベントの通知を代理要求として、他のイベント配信装置10に送信し、イベント通知の代理を依頼する。このような動作に基づき、第3の実施形態に係るイベント配信装置10は、滞留しているイベントの通知を解消ことも出来るようになる。第3の実施形態に係る代理要求条件保持部111に保持する条件も、CPU使用率の代わりに滞留時間を保持している。そして、通知制御部108と同様に、代理要求制御部110は、自装置でイベントを通知するか否かを判定するため、イベント通知部109から滞留時間を取得し、代理要求条件と比較する。その他の動作は、第1の実施形態などと同様のため、詳細な説明は省略する。なお、第3の実施形態の代理要求制御部110も、イベント通知部109からイベントを引き上げてもよい。この場合、代理要求制御部110は、通知制御部108と同様に、滞留しているイベントを代理要求として他のイベント配信装置10に転送することが出来る。これまでの説明では、イベント通知部109からの滞留イベントを、通知制御部108又は代理要求制御部110が、イベント、転送要求、又は、代理要求を受けたときに引き上げる場合について説明した。しかし、イベントなどを受け取ったときに確認するだけでは、例えば、イベントの発生などが途絶えると、通知制御部108などは、滞留時間の長いイベントの代理要求が送信できないことも発生する。そのため、本実施形態に係る通知制御部108又は代理要求制御部110は、定期的にイベント通知部109に残っているイベントの滞留時間を確認しても良い。このようにすると、イベントなどの受信が途絶えている場合でも、通知制御部108は、適宜、滞留時間の長いイベントの代理要求を送信することが出来る。第3の実施形態に係るイベント配信装置10は、第1の実施形態の効果に加え、アプリケーション40との間の障害などに基づくイベントの滞留に対応したイベント配信を実現する効果を得ることが出来る。その理由は、通知制御部108又は代理要求制御部110が、イベントのイベント通知部109に滞留しているイベントの滞留時間を基に、自装置でイベントを配信通知するか、他のイベント配信装置10に配信通知を依頼するかを判定しているためである。さらに、第3の実施形態に係るイベント配信装置10は、滞留しているイベントを解消する効果を得ることも出来る。その理由は、通知制御部108又は代理要求制御部110が、所定の時間より長く滞留しているイベントをイベント通知部109から引き上げ、代理要求として他のイベント配信装置10に依頼することが出来るためである。第4の実施形態第1の実施形態に係るイベント配信装置10では、イベント通知の代理要求を受信したときに、自装置で送信するか又は代理要求を送信するかの二者選択であった。しかし、自装置の負荷に応じて、代理要求のイベント通知の全てを代理するのは無理でも、一部のイベントを通知できる場合もある。第4の実施形態に係るイベント配信装置10は、自装置と他の装置との二者選択ではなく、自装置の負荷に応じて、代理要求の一部のイベントを通知する。第4の実施形態に係るイベント配信装置10の構成は、第1の実施形態に係るイベント配信装置10と同じため、第1の実施形態の同じ構成及び動作に関しての詳細な説明は省略し、第1の実施形態とは異なる動作について詳細に説明する。代理要求制御部110の動作について図面を参照して説明する。図32は、第4の実施形態に係る代理要求条件保持部111に保持されている、代理要求条件の一例を示す図である。この、代理要求条件は、代理要求条件保持部111に予め設定されていてもよく、装置の状態などを基に、自装置、又は、他の装置から設定変更されても良い。第4の実施形態に係る代理要求条件は、第1の実施形態に係る代理要求条件に含まれるTTLとCPU使用率とに加えイベント通知先数とを含む。ここにおけるイベント通知先数とは、イベントを通知する通知先の数を示している。例えば、図30の4行目をデータTTL=2,CPU使用率=<30、イベント通知先数=600とは、TTLが2の代理要求を受けた場合に、CPUの使用率が30以下ならば、イベント通知先として600個まで代理要求を受け付けることを示している。さらに第4の実施形態の代理要求制御部110の動作について図面を参照して詳細に説明する。図33は、第4の実施形態に係る代理要求制御部110の動作の一例を示すフローチャート図である。代理要求制御部110は、代理要求を受信したときステップ3301、代理要求のTTLを取得する。次に、代理要求制御部110は、自装置の負荷状態を取得し、代理要求のTTLと自装置の負荷から、代理要求条件の通知先数を取得するステップ3302。そして、代理要求制御部110は、代理要求条件から求めた通知先数が有るか否か通知先数が0でないことを判定するステップ3303。もし、代理要求条件から求めた通知先数が有る場合、さらに、代理要求制御部110は、代理要求条件から求めた通知先数と、代理要求の通知先数とを比較するステップ3304。代理要求の通知先数が代理要求条件の通知先数と同じか少ない場合、つまり、自装置で代理要求の通知先数に通知出来る場合、代理要求制御部110は、代理要求のイベントと通知先とをイベント通知部109に渡して、自装置でイベントを通知するステップ3305。自装置で通知する通知先数が有るが、代理要求の通知先数より少ない場合、代理要求制御部110は、代理要求条件の通知先の数だけ、代理要求の通知先を取り出すステップ3306。そして、代理要求制御部110は、取り出した通知先とイベントとをイベント通知部109に渡してイベントを通知するステップ3307。さらに、代理要求制御部110は、イベントを通知した通知先を代理要求から削除し、新しい代理要求を作成するステップ3308。この新しい代理要求は、勿論TTLも1つ減らしている。新しい代理要求を作成した代理要求制御部110は、代理要求を送信するイベント配信装置10を選択しステップ3309、選択したイベント配信装置10に新しい代理要求を送信するステップ3310。代理要求条件に通知先数がない場合、つまり、自装置の負荷が重いなど代理要求がまったくできない場合、代理要求制御部110は、第1の実施形態において負荷が重い場合と同様に、代理要求を送信するイベント配信装置10を選択するステップ3309。そして、代理要求制御部110は、選択したイベント配信装置10に代理要求を送信するステップ3310。このときの代理要求は、通知先などは変更しないが、TTLは1つ減らしている。さらに、代理要求制御部110の詳細な動作の説明として、図30に示す具体的な数値を使用して説明する。例えば、イベント配信装置10のCPU使用率が20の場合に、代理要求TTL=2、通知先数=1000を受けたとするステップ3301。このとき、代理要求制御部110は、代理要求条件保持部111から、代理要求で受信したTTLの2と自装置のCPU使用率20に対応する通知先数の値である600を取得するステップ3302。次に、代理要求制御部110は、取得した通知先数600が、0か否かを判定するステップ3303。600は、0でないためステップ3303でyes、次に、代理要求制御部110は、代理要求の通知先数1000と代理要求条件の通知先数600とを比較するステップ3304。代理要求の送信先数が代理要求条件の通知先の数より多いためステップ3304でno、代理要求制御部110は、代理要求から代理要求条件の通知先数600だけ通知先を取り出すステップ3306。そして、代理要求制御部110は、その通知先とイベントとをイベント通知部109に渡すステップ3307。さらに、代理要求制御部110は、代理要求から通知済みの通知先を削除しこの結果、通知先は400となる。、TTLを一つ減らした新しい代理要求を作成するステップ3308。続いて、代理要求制御部110は、網構成装置情報からイベント配信装置10を1つ選びステップ3309、そのイベント配信装置10に代理要求を送信するステップ3310。なお、第4の実施形態のイベント配信装置10の通知制御部108においても、同様に、装置の負荷に基づき、代理要求として送信する送信先の数を変更しても良い。通知制御部108における代理要求を送信するか否か、通知先の数をどのように決めるかなどの動作は、既に説明した代理要求制御部110と同じため、詳細な説明は省略する。また、代理要求を送信するか否かの条件である通知条件も代理要求条件と同様にしておけばよく、詳細な説明は省略する。第4の実施形態に係るイベント配信装置10は、第1などの実施形態に係るイベント配信装置10の効果に加え、代理要求の負荷を分散させる効果を得ることが出来る。その理由は、第4の実施形態に係るイベント配信装置10は、代理要求を受信した各イベント配信装置10が、自装置の負荷を考慮して、所定の負荷までは、可能な範囲の通知先についてのイベントを通知するためである。その結果、イベントを通知するイベント配信装置10が、増えることとなり、イベント転送の負荷が分散される。さらに、そのイベント配信装置10から送信される代理要求に含まれるイベントの通知先の数も少なくなるため、代理要求を受けた次のイベント配信装置10における処理の負荷を軽くすることも出来るためである。第5の実施形態第1の実施形態に係るイベント配信装置10は、代理要求を1つのイベント配信装置10に送信した。しかし、イベント配信装置10が代理要求を依頼する装置は、1つである必要はなく、複数でもよい。第5の実施形態に係るイベント配信装置10は、代理要求を複数送信する。なお、第5の実施形態に係るイベント配信装置10は、通知制御部108及び代理要求制御部110における代理要求を送信するイベント配信装置10の選択処理と、代理要求を複数作成する点とを除いて、第1の実施形態などと同じである。そのため、第1の実施形態と同じ構成及び動作などについての詳細な説明は省略し、第1の実施形態とは異なる第5の実施形態に係るイベント配信装置10に特有の動作について詳細に説明する。第5の実施形態に係る通知制御部108は、代理要求を送信すると判定した場合における、網構成装置情報から送信先の装置を選択する処理図23のステップ2303に相当において、所定の数の複数の装置を選択する。そして、通知制御部108は、受け取ったイベントから複数の代理要求例えば、通知先を送信の装置の数で均等に分けるなどを作成し、選択した複数のイベント配信装置10に代理要求を送信する図23のステップ2304に相当。また、第5の実施形態に係る代理要求制御部110は、代理要求を送信すると判定した場合における、網構成装置情報から送信先の装置を選択する処理図25のステップ2504に相当において、所定の数の複数の装置を選択する。そして、代理要求制御部110は、受け取った代理要求を複数の代理要求に分割し、さらに代理要求の必要な内容例えばTTLの変更などを修正し、選択した複数のイベント配信装置10に代理要求を送信する図25のステップ2505に相当。第5の実施形態に係るイベント配信装置10は、第1などの実施形態の効果に加え、代理要求を受け付けたイベント配信装置10における代理要求に対応するイベントの通知の処理の負荷を軽くする効果を得ることが出来る。その理由は、第5の実施形態に係るイベント配信装置10は、代理要求を複数に分けるため、代理要求を受け取ったイベント配信装置10で通知すべき通知先の数が少なくなるためである。さらに、第5の実施形態に係るイベント配信装置10は、第1などの実施形態の効果に加え、代理要求が送信されたイベント通知の最大遅延を平均的に低くする効果を得ることが出来る。その理由は、第5の実施形態に係るイベント配信装置10は、複数のイベント配信装置10に代理要求を送信するため、代理要求を受け取った各イベント配信装置10で通知する通知先の数が、第1の実施形態に係るイベント配信装置10と比較して少なくなるためである。さらに、第5の実施形態に係るイベント配信装置10は、複数のイベント配信装置10に代理要求を送信している。そのため、送信先のイベント配信装置10に負荷の軽いイベント配信装置10が含まれている可能性が高くなる。また、たとえ一部の代理要求が負荷の重いイベント配信装置10に送信され、再度代理要求となった場合でも、さらに分割した後の代理要求となるため、再度代理要求が送信される通知先の数がさらに少なくなるためである。第6の実施形態第1の実施形態などに係るイベント配信装置10は、イベントの代理要求を送るイベント配信装置10を選択するときに、経路情報保持部103の網構成装置情報から自装置以外のイベント配信装置10をランダムに選択した。しかし、負荷が重くなっている自装置が受け取ったイベントの転送に関係している他のイベント配信装置10は、負荷が重くなっていると推定出来る。そのため、第6の実施形態に係るイベント配信装置10は、同じイベントの通知に関係しているイベント配信装置10を代理要求の送信先として選択しない。なお、第6の実施形態に係るイベント配信装置10は、通知制御部108又は代理要求制御部110における代理要求を送信するイベント配信装置10の選択処理以外は、第1の実施形態などと同じである。そのため、同じ構成及び動作などについての詳細な説明は省略し、第1の実施形態などと異なる第6の実施形態に係るイベント配信装置10に特有の動作について詳細に説明する。図34は、第6の実施形態に係る通知制御部108、又は、代理要求制御部110の動作の一例を示すフローチャート図である。なお、以下の説明において、通知制御部108がイベントを受け取ったときの処理と転送要求を受け取ったときの動作は同じため、通知制御部108がイベントを受け取った処理について説明する。通知制御部108が転送要求を受け取った場合は、イベントを転送要求に変更すれば同様の動作となる。また、代理要求制御部110が代理要求を受け取った場合の動作も同様である。つまり、代理要求を受け取った代理要求制御部110は、説明中の通知制御部108を代理要求制御部110に置き換え、イベントを代理要求に置き換えれば同様の動作を実現することが出来る。まず、通知制御部108は、選択対象となるイベント配信装置10の情報を保存する一覧表以下、装置リストと言うを用意する。なお、この装置リストは、少なくとも網構成装置情報に保存されている装置が全て保存出来る大きさは備えているものとする。そして、通知制御部108は、経路情報保持部103の網構成装置情報から自装置を除いた他の全てのイベント配信装置10の装置情報例えば装置IDなどを取得して、装置リストに格納するステップ3401。次に通知制御部108は、経路情報保持部103において、受信したイベントのタイプの転送経路情報が存在するか否かを判定するステップ3402。イベントのタイプに関する転送経路情報が有る場合、通知制御部108は、そのタイプに対応する転送経路情報に登録されている全てのイベント配信装置10について次の動作を繰り返すステップ3403。まず、通知制御部108は、そのタイプの転送経路情報の装置情報装置IDなどが装置リストに有るか否かを確認するステップ3404。装置リストにある場合、通知制御部108は、装置リストからその装置の情報装置IDなどを削除するステップ3405。そして、通知制御部108は、装置リストが空になったか否かを判定するステップ3406。装置リストが空でなければ、通知制御部108は、そのタイプの転送経路情報の次の装置について同じように処理する。そのタイプの転送経路情報の装置が装置リストに無い場合ステップ3404でno、通知制御部108は、特に何も処理せず、そのタイプの転送経路情報の次の装置について同じように処理する。そのタイプの転送経路情報の全ての装置について処理が終了した場合、装置リストに残ったイベント配信装置10は、イベントのタイプの転送経路に入っていないイベント配信装置10である。つまり、装置リストに残ったイベント配信装置10は、少なくとも、対象となっているイベントに転送には関係しないイベント配信装置10となっている。そこで、通知制御部108は、残った装置リストから、代理要求を送信するイベント配信装置10を1つ選択するステップ3408。そのタイプの転送経路情報の装置での処理が終わる前に装置リストが空になった場合ステップ3406でyes、そのイベントのタイプに関連しないイベント配信装置10がないことを示している。この場合、イベントの転送に関係しない装置が自装置の保持している網構成装置情報にないため、通知制御部108は、第1の実施形態に係る通知制御部108と同様に網構成装置情報からイベント配信装置10を1つ選択する。なお、この処理を第1の実施形態と同様に処理してもよいが、第6の実施形態の通知制御部108は、いままでの動作と合わせている。そのため、通知制御部108は、網構成装置情報から自装置を除いた装置リストを再構成しステップ3407、その装置リストから代理要求を送信するイベント配信装置10を1つ選択しているステップ3408。また、受信したイベントのタイプの転送経路情報が存在しない場合ステップ3402のno、そのタイプに関連するイベント配信装置10の登録は、ない。そのため、通知制御部108は、第1の実施形態に係る通知制御部108と同様に網構成装置情報からイベント配信装置10を1つ選択する。なお、この処理も第1の実施形態と同様に処理してもよいが、第6の実施形態の通知制御部108は、イベント配信装置10の一覧表となっている装置リストから代理要求を送信するイベント配信装置10を1つ選択しているステップ3408。第6の実施形態に係るイベント配信装置10は、第1の実施形態に係るイベント配信装置10の効果に加え、イベントの代理要求を負荷の軽いイベント配信装置10に代理要求を送信する効果を得ることが出来る。その理由は、第6の実施形態に係るイベント配信装置10は、代理要求を送信するイベント配信装置10を選択するときに、通知するイベントの転送に関連しないイベント配信装置10を選択するためである。第7の実施形態第1の実施形態に係るイベント配信装置10は、代理要求の送信先であるイベント配信装置10を選択するとき、経路情報保持部103の網構成装置情報からランダムにイベント配信装置10を選択した。しかし、網構成装置情報には、代理要求の要求元であるイベント配信装置10も含まれている。そのため、第1の実施形態などのイベント配信装置10は、ある確率で、代理要求を送った要求元であるイベント配信装置10を、代理要求の送信先として選択する可能性があった。もし、代理要求の要求元であるイベント配信装置10を代理要求の送信先として選択すると、送信先も当然再度代理要求を送信するため、無駄な代理要求の転送処理が発生する。さらに、2つのイベント配信装置10で代理要求の往復や、3つ以上のイベント配信装置10の間での代理要求のループが発生する可能性もある。また、このような無駄な代理要求のやりとりでTTLの値が0となってしまうと、負荷が重いイベント配信装置10においてイベントを通知する処理が発生してしまう。第7の実施形態に係るイベント配信装置10は、代理要求に、第1の実施形態などで説明したデータに加え、代理要求を送信したイベント配信装置10の情報以下このデータを送信元装置リストと言うの一部又は全てを含ませている。この送信元装置リストのデータは、例えば、代理要求を送信したイベント配信装置10の装置IDの一覧を格納したデータなどである。このような代理要求を送信した装置IDを格納した送信元装置リストに基づき、例えば、代理要求制御部110は、受信した代理要求を再送信するイベント配信装置10を選択するときに、送信元装置リストに格納されているイベント配信装置10を選択先から外すようにする。このような動作に基づき、第7の実施形態に係るイベント配信装置10は、代理要求の送信元に代理要求を戻すことを回避している。第7の実施形態に係るイベント配信装置10について、図面を参照してさらに詳細に説明する。なお、第7の実施形態に係るイベント配信装置10において、通知制御部108が代理要求に自装置の情報を含ませることと、代理要求制御部110における代理要求を送信するイベント配信装置10の選択処理及び代理要求の作成処理と以外は、第1の実施形態などと同様である。そのため、同じ構成及び動作についての詳細な説明は省略し、第1の実施形態などと異なる第7の実施形態に係るイベント配信装置10に特有の動作について詳細に説明する。第7の実施形態に係る通知制御部108又は代理要求制御部110は、代理要求を送信するとき、代理要求の送信元装置リストに自装置の情報例えば、装置IDを追加する。さらに、第7の実施形態に係る代理要求制御部110の動作について図面を参照して説明する。図35は、第7の実施形態に係る代理要求制御部110の動作の一例を示すフローチャート図である。代理要求制御部110は、他のイベント配信装置10に代理要求を転送するために他のイベント配信装置10を選択するとき、まず、選択対象となるイベント配信装置10の情報を保存する一覧表を用意する。なお、この一覧表は、第6の実施形態に係る装置リストと同様のため、第7の実施形態の説明のおいても装置リストと言う。また、この装置リストは、少なくとも網構成装置情報に保存されている装置が全て保存出来る大きさは備えているものとする。代理要求制御部110は、経路情報保持部103の網構成装置情報から自装置を除いたすべての装置情報例えば、装置IDを取得して装置リストに格納するステップ3501。次に、代理要求制御部110は、代理要求で受信した送信元装置リストの各装置に対して、次の処理を繰り返すステップ3502。代理要求制御部110は、装置リストに代理要求の送信元の装置があるか否かを確認するステップ3503。送信元の装置が装置リストにある場合、代理要求制御部110は、装置リストから送信元の装置の情報を削除するステップ3504。削除後、代理要求制御部110は、装置リストが空になったか否かを確認するステップ3505。もし、装置リストが空でなければ、代理要求制御部110は、代理要求の送信元装置リストの次の装置の処理に移る。これを、代理要求制御部110は、代理要求の送信元装置リストに含まれる全ての装置に対して繰り返す。なお、代理要求に含まれる送信元装置が装置リストにない場合は、特に必要な処理はないため、代理要求制御部110は、次の送信元装置について処理する。代理要求の送信元装置リストの全ての装置を削除しても装置リストに装置が残った場合、装置リストに残った装置は、代理要求の送信元装置ではない装置となる。従って、代理要求制御部110は、残った装置リストから代理要求の送信先となるイベント配信装置10を選択するステップ3507。もし、送信元装置リストの途中で、装置リストが空となった場合は、全ての装置がそのイベントの代理要求を出していることを示す。この場合、送信元となっていない装置がないこととなり、代理要求制御部110は、第1の実施形態と同様に網構成装置情報からランダムなど所定の処理でイベント配信装置10を選択して、代理要求を送信する。なお、この選択は第1の実施形態と同様でも良いが、第7の実施形態に係る代理要求制御部110は、動作の統一などのため装置リストから選択することとしている。そのため代理要求制御部110は、再度、網構成装置情報から装置リストを作成しステップ3506、その装置リストからイベント配信装置10を選択するステップ3507。さらに具体的なデータを使用して詳細な説明する。例えば、図8に示すノードAの通知制御部108がノードCに代理要求を送信するとき、代理要求に自装置の情報例えば、ノードAのノードIDを含む送信元装置リストを加える。このときの代理要求を、模式的に説明すると、代理要求=イベント、通知先、TTL=例えば3、送信元装置リストノードAとなる。次に、ノードCがノードAから代理要求イベント、通知先、TTL=3、通知先装置リストノードAを受信し、自装置の負荷が重く、他装置に代理要求を転送するためにイベント配信装置10を選択するとき場合の動作を説明する。ノードCの代理要求制御部110は、まず、経路情報保持部103の網構成装置情報から自装置を除いたすべての装置情報を取得し、装置リストに格納するステップ3501。図8のノードCの場合の装置リストは、ノードA,ノードD,ノードEとなる。次に、代理要求制御部110は、代理要求で受信した送信元装置リストこの場合は、ノードAとなる。の装置が有るか否かを確認するステップ3503。送信元装置リストのノードAが、装置リストにあるため、代理要求制御部110は、装置リストからノードAの装置情報を削除するステップ3504。この結果、装置リストは、ノードD,ノードEとなる。さらに、代理要求制御部110は、装置リストが空か否かを確認するステップ3505。まだ空でないため、代理要求制御部110は、次の装置の確認に移る。いま説明している例では、既に送信元装置リストの装置が終わっているため、代理要求制御部110は、残った装置リストノードD,ノードEから、代理要求を転送するイベント配信装置10ノードD又はノードEを1つ選択するステップ3507。このような動作に基づき、第7の実施形態に係るイベント配信装置10は、送信元であるイベント配信装置10説明ではノードAを代理要求の送信先から外した選択ができる。第7の実施形態に係るイベント配信装置10は、第1のなどの実施形態に係る効果に加え、さらに既に代理要求を送信したイベント配信装置10に代理要求を再送信することを避けるという効果を得ることが出来る。その理由は、第7の実施形態に係るイベント配信装置10は、代理要求に、代理要求を送信したイベント配信装置10の装置の情報を代理要求に含める。そして、第7の実施形態に係るイベント配信装置10は、その送信元の情報を使用して、代理要求を送信するイベント配信装置10の選択先から、代理要求を送信したイベント配信装置10を外して選択するためである。第8の実施形態第1の実施形態などに係るイベント配信装置10は、代理要求を送信する送信先のイベント配信装置10に装置状態の問い合わせず、代理要求を送信した。そのため、同じイベントを通知するなど負荷の重いイベント配信装置10を選択する場合が有った。そこで、第6の実施形態などに係るイベント配信装置10は、同様のイベントを配信していて負荷が重いと推定されるイベント配信装置10を除いて送信先を選択した。しかし、イベント配信装置10は、他の処理など、別要因で負荷が重くなる場合も有る。第8の実施形態に係るイベント配信装置14は、代理要求を送信するために選択したイベント配信装置14への代理要求の送信に先立ち、送信先として選択したイベント配信装置14に代理要求を受け付けることが出来るか否かを確認している。第8の実施形態に係るイベント配信装置14について、図36-図39を参照して説明する。図36は、第8の実施形態に係るイベント配信装置14の構成の一例を示すブロック図である。図34において、図5のイベント配信装置10と同じ構成は、同じ番号を付し、詳細な説明は省略する。第8の実施形態に係るイベント配信装置14は、通知制御部113と、代理要求制御部114と、イベント通知部115と、メッセージ転送部116とにおける代理要求を送信又は受信した場合の動作が、第1などの実施形態に係るイベント配信装置10と異なる。通知制御部113は、代理要求を送信する前に送信先の装置の状態を確認、具体的には、代理要求を受け付けることが出来るか否かを確認する。この動作については、後ほど詳細に説明する。代理要求制御部114は、他のイベント配信装置14から、代理要求を受け付けることが出来るか否かの問い合わせに対して、自装置の状態を基に応答する。この動作についても後ほど詳細に説明する。イベント配信装置14は、代理要求を受け付け可能な場合だけ代理要求を受け付けるため、第1の実施形態に係るイベント配信装置10のように、受け付けた代理要求について受け付け可能か否かを判定する必要がない。そのため、イベント配信装置14は、代理要求を直接イベント通知部115が受け取り、イベントを通知する。この処理に関しても後ほど詳細に説明する。メッセージ転送部116は、通知制御部113から受け取った問い合わせと代理要求制御部114から受け取った回答を他のイベント配信装置14に送信する。また、他のイベント配信装置14から受け取った問い合わせを代理要求制御部114に渡し、代理要求をイベント通知部115に渡す。メッセージ転送部116のその他の動作は、第1の実施形態などと同様のため詳細な説明は省略する。続いて、第8の実施形態に係るイベント配信装置14に動作について説明する。なお、代理要求の処理を除いて、イベント配信装置14の動作は、イベント配信装置10の動作と同様のため、第1などの実施形態と同様の動作についての説明は省略し、第8の実施形態に特有の動作について詳細に説明する。まず、通知制御部113の動作について図面を参照して説明する。図37は、通知制御部113の動作の一例を示すフローチャート図である。パブリッシャ20からメッセージ転送部116を介してイベントを受信した通知制御部113はステップ3701、自装置の負荷を通知制御部113が保持している通知条件と比較するステップ3702。自装置の負荷が重い場合、通知制御部113は、代理要求を送信する。この動作として、まず、通知制御部113は、網構成装置情報から通知先として所定の方式を用いてイベント配信装置14を選択するステップ3703。続いて、通知制御部113は、選択したイベント配信装置14にメッセージ転送部116を介して、代理要求を受け付けることが出来るか否かの問い合わせを送信するステップ3703。本実施形態のこの問い合わせは、TTLを含む。イベント配信装置14から問い合わせの回答として、受け付けが不可否だった場合ステップ3704のno、通知制御部113は、他の送信先を探す。通知制御部113は、TTLを1つ少なくしステップ3705、TTLが0となっているか否かを判定するステップ3706。まだ、TTLが0でない場合は、次の送信先を選択するステップ3703。もし、TTLが0の場合は、送信先への選択ができないため、通知制御部113は、イベントと通知先とをイベント通知部115に渡して、自装置でイベントを通知する。なお、第8の実施形態に係る通知制御部113は、実際に代用要求を送信した回数としてTTLを使用し、送信先の選択の回数の制限として他の値を備えてもよい。また、他のイベント配信装置14との確認時間は、ネットワークを経由するため時間を予想できない。そこで、通知制御部113は、送信先の選択の処理全体の時間を監視し、装置の選択の動作を制限してもよい。さらに、他のイベント配信装置14から回答に関しても、所定の監視時間を設定し、監視時間内に回答がない場合、通知制御部113は、代理要求不可として、他の装置を確認しても良い。一方、問い合わせ先のイベント配信装置14から代理要求の受け付け可の回答を受けた場合ステップ3704のyes、通知制御部113は代理要求を選択したイベント配信装置14に送信するステップ3707。また、自装置の負荷が通知条件より軽い場合、通知制御部113は、イベントと通知先とをイベント通知部115に渡し、イベントを通知するステップ3708。次に、代理要求制御部114の動作について説明する。図38は、代理要求制御部114の動作の一例を示すフローチャート図である。メッセージ転送部116を介して代理要求の問い合わせを受け付けた代理要求制御部114はステップ3801、受け付けた代理要求のTTLを基に代理要求条件の負荷条件を取得するステップ3802。次に、代理要求制御部114は、自装置の負荷を取得し代理要求条件の負荷と比較するステップ3803。自装置の負荷が重い場合ステップ3803のyes、代理要求制御部114は、代理要求を受け付けることができないため、代理要求の受け付け不可を回答するステップ3804。一方、自装置の負荷が軽い場合ステップ3803のno、代理要求制御部114は、自装置で代理要求を処理出来るため、代理要求の受け付け可能の回答を返すステップ3805。続いて、イベント通知部115の動作について説明する。図39は、イベント通知部115の動作の一例を示すフローチャート図である。メッセージ転送部116を介して代理要求を受け取ったイベント通知部115はステップ3901、代理要求に含まれる通知先となっているアプリケーション40全てにステップ3902、代理要求に含まれるイベントを通知するステップ3903。なお、第8の実施形態に係るイベント配信装置14において、代理要求の問い合わせに関して、受け付けの可否の回答ではなく、受け付け可能な通知先数を回答してもよい。この場合、回答を受けたイベント配信装置14は、受け付け可能な通知先の数、又は、その数以下の通知先を含む代理要求を送信し、残りの通知先については、別のイベント配信装置14に代理要求を送信する。また、イベント配信装置14は、イベント配信装置14への問い合わせとして、TTLと通知先数とを送信してもよい。この場合に、問い合わせを受けたイベント配信装置14は、TTLと通知先数に基づき代理要求を受け付けるか否かを判定し、受け付け可否を回答する。さらに、この場合においても、イベント配信装置14は、回答として受け付け可能な通知先数を回答してもよい。なお、第8の実施形態に係る代理要求は、受け付け可能なイベント配信装置14に送信されるため、TTLを含まなくてもよい。第8の実施形態に係るイベント配信装置14は、第1の実施形態に係るイベント配信装置10の効果に加え、イベント配信NW50などに流れるデータの量を減らす効果を得ることが出来る。その理由は、イベント配信装置14が、代理要求が受け付け可能か否かの問い合わせに基づき、イベント配信装置14が、代理要求を受け付け可能なイベント配信装置14に代理要求を送信するため、代理要求の再送信を防ぐことが出来るためである。第9の実施形態第8の実施形態に係るイベント配信装置14は、代理要求を受け付けるか否かの可否を回答した。しかし、例えば、ロードバランスを考慮した代理要求を送信する場合、受け付けの可否だけではなく、各装置の負荷状態も必要となる。第9の実施形態に係るイベント配信装置15は、代理要求の問い合わせに対して自装置の負荷状態を含んで回答する。第9の実施形態のイベント配信装置15について、図40-図41を参照して説明する。図40は、第9の実施形態に係るイベント配信装置15の構成の一例を示すブロック図である。図40において、図34のイベント配信装置14と同じ構成は、同じ番号を付し、詳細な説明は省略する。第9の実施形態に係るイベント配信装置15は、通知制御部117と、代理要求条件保持部118と、代理要求制御部119との動作が、第8の実施形態のイベント配信装置14と異なる。通知制御部117は、代理要求の回答として送信先の装置の負荷状態を受け取り、受け取った負荷状態を基に、代理要求を送信するか否かを判定する。この動作については、後ほど詳細に説明する。代理要求条件保持部118は、代理要求を送信する場合の装置の負荷などの条件を保持している。代理要求制御部119は、代理要求の受け付けに関する問い合わせに対して、自装置の負荷状態を含む情報を回答する。続いて、第9の実施形態に係るイベント配信装置15に動作について説明する。なお、イベント配信装置15の動作は、代理要求の問い合わせに対する回答に関する動作を除いてイベント配信装置14の動作と同様の動作のため、第8の実施形態と同様の動作についての説明は省略し、第9の実施形態に特有の動作について詳細に説明する。図41は、通知制御部117の動作の一例を示すフローチャート図である。メッセージ転送部116を介してイベントを受信した通知制御部117ステップ4101は、通知制御部117の保持している通知条件と自装置の負荷とを比較するステップ4102。自装置の負荷が重い場合ステップ4102のyes、通知制御部117は、代理要求を送信する。この処理として、まず、通知制御部117は、網構成装置情報から通知先のイベント配信装置15を1つ選択するステップ4103。通知制御部117は、選択したイベント配信装置15に代理要求の受け付けが可能か否かの負荷状態の問い合わせ、装置負荷の情報を含む回答を受け取るステップ4104。ここでの問い合わせは、代理要求に対する問い合わせでなく、負荷状態を問い合わせでもよい。続いて通知制御部117は、現在のTTLを基に、代理要求条件保持部118が保持している代理要求条件を取得するステップ4105。通知制御部117は、受け取った負荷状態と代理要求条件の負荷とを比較するステップ4106。問い合わせを受けた装置の負荷が重い場合、代理要求の送信先にはできないため、通知制御部117は、次の送信先を選択する。そのため、通知制御部117は、まずTTLを1つ減らしステップ4107、TTLが0でないかを判定するステップ4108。もし、TTLが0でない場合、代理要求を通知できるため、通知制御部117は、次の送信先のイベント配信装置15を選択するステップ4103。TTLが0の場合ステップ4108でyes、代理要求を送信できないため、通知制御部117は、イベント通知部115にイベントと通知先とを渡して、自装置で通知するステップ4110。一方、問い合わせ先の装置の負荷が軽い場合、通知制御部117は、代理要求を選択したイベント配信装置15に送信するステップ3809。自装置の負荷が軽い場合ステップ4102でno、通知制御部117は、イベント通知部115に受け取ったイベント等を渡して、自装置でイベントを通知するステップ4110。なお、通知制御部117が装置の負荷を確認する場合、確認先の装置は、1つに限る必要はない。例えば、ステップ4103において通知制御部117が複数のイベント配信装置15を選択し、その選択した複数のイベント配信装置15から負荷状態を受け取ってもよい。この場合、通知制御部117は、代理要求の送信先として、負荷状態が軽い装置から順番に選択してもよい。また、通知制御部117は、複数のイベント配信装置15の負荷状態から複数の装置の負荷分散を考慮し、例えば、負荷の重い装置には通知先の数が少ない代理要求を、負荷の軽い装置には通知先の数が多い代理要求を送信しても良い。第9の実施形態に係るイベント配信装置15は、第1の実施形態に係るイベント配信装置10の効果に加え、イベント配信NW50などに流れるデータの量を減らす効果を得ることが出来る。その理由は、イベント配信装置15が、代理要求の送信先のイベント配信装置15の負荷を考慮して、代理要求を受け付け可能なイベント配信装置15に送信するためである。また、第9の実施形態に係るイベント配信装置15は、さらに、イベントの通知の負荷分散を実現する効果を得ることも出来る。その理由は、第9の実施形態に係るイベント配信装置15は、複数のイベント配信装置15の負荷を考慮し、負荷の軽いイベント配信装置15に代理要求を送信、又は、負荷分散を考慮した代理要求を送信することが出来るためである。なお、各実施形態について、単独で説明してきたが、実施形態を組み合わせて使用することも可能である。例えば、第6の実施形態と第7の実施形態とを合わせ、代理要求を送信するイベント配信装置10の選択から、イベントの転送に関係する装置及び代理要求の送信元の両方の装置を外してもよい。このように組み合わせた実施形態に係るイベント配信装置10は、第6の実施形態及び第7の実施形態に係るイベント配信装置10と比較し、負荷の軽いイベント配信装置10を選択出来る可能性を高くすることが出来る。上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。付記付記1予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を含むイベント配信装置。付記2予め登録されている代理要求条件を基に、ネットワークを介して受信した代理要求に含まれるイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御部を含むことを特徴とする付記1に記載のイベント配信装置。付記3前記通知制御部が、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記2に記載のイベント配信装置。付記4前記代理要求制御部が、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記2又は付記3に記載のイベント配信装置。付記5前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベント配信装置の負荷情報を含み、前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むことを特徴とする付記2乃至付記4のいずれかに記載のイベント配信装置。付記6前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存する経路制御部と、前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理する購読要求制御部と、前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送するイベント受信転送部と、前記イベントと前記サブスクリプションとの一致を判定する一致判定部と、前記イベントをアプリケーションに通知するイベント通知部とを含むことを特徴とする付記2乃至付記5のいずれかに記載のイベント配信装置。付記7前記経路制御部が、前記購読要求制御部の前記サブスクリプションの登録又は削除に伴い、前記イベントを転送する装置に関する情報を変更することを特徴とする付記6に記載のイベント配信装置。付記8前記通知条件又は前記代理要求条件の少なくともいずれかが、自装置の資源に関する情報、自装置で通知するイベントの量に関する情報、又は、自装置で通知するイベントの滞留時間に関する情報の少なくとも1つを含むことを特徴とする付記2乃至付記7のいずれかに記載のイベント配信装置。付記9前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を2以上の前記他の装置に送信することを特徴とする付記2乃至付記8のいずれかに記載のイベント配信装置。付記10前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする付記2乃至付記9のいずれかに記載のイベント配信装置。付記11前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの代理要求を送信した装置を除くことを特徴とする付記2乃至付記10のいずれかに記載のイベント配信装置。付記12前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の前記代理要求の受け付けの可否を確認することを特徴とする付記2乃至付記11のいずれかに記載のイベント配信装置。付記13前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の負荷情報を受け取り、受け取った負荷情報を基に前記代理要求を送信するか否かを判定することを特徴とする付記2乃至12のいずれかに記載のイベント配信装置。付記14予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を含むイベント配信装置と、前記イベント配信装置に前記ネットワークを介して前記イベントをパブリッシュするパブリッシャと、前記イベント配信装置に前記サブスクリプションを送信するサブスクライバと、前記イベント配信装置から前記イベントの通知を受けるアプリケーションとを含むイベント配信システム。付記15前記イベント配信装置が、予め登録されている代理要求条件を基に、ネットワークを介して受信した代理要求に含まれるイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御部を含むことを特徴とする付記14に記載のイベント配信システム。付記16前記通知制御部が、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記15に記載のイベント配信システム。付記17前記代理要求制御部が、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記15又は付記16に記載のイベント配信システム。付記18前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベント配信装置の負荷情報を含み、前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むことを特徴とする付記15乃至付記17のいずれかに記載のイベント配信システム。付記19前記イベント配信装置が、前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存する経路制御部と、前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理する購読要求制御部と、前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送するイベント受信転送部と、前記イベントと前記サブスクリプションとの一致を判定する一致判定部と、前記イベントを前記アプリケーションに通知するイベント通知部とを含むことを特徴とする付記15乃至付記18のいずれかに記載のイベント配信システム。付記20前記経路制御部が、前購読要求制御部の前記サブスクリプションの登録又は配信削除に伴い前記イベントを転送する装置に関する情報を変更することを特徴とする付記19に記載のイベント配信システム。付記21前記通知条件又は前記代理要求条件の少なくともいずれかが、少なくとも1つ以上の装置の資源の関する情報、通知するイベントの量に関する情報、又は、通知するイベントの滞留時間に関する情報の少なくとも1つを含むことを特徴とする付記15乃至付記20のいずれかに記載のイベント配信システム。付記22前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を2以上の装置に送信することを特徴とする付記15乃至付記21のいずれかに記載のイベント配信システム。付記23前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする付記15乃至付記22のいずれかに記載のイベント配信システム。付記24前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの代理要求を送信した装置を除くことを特徴とする付記15乃至付記23のいずれかに記載のイベント配信システム。付記25前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の前記代理要求の受け付けの可否を確認することを特徴とする付記15乃至付記24のいずれかに記載のイベント配信システム。付記26前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の負荷情報を受け取り、受け取った負荷情報を基に前記代理要求を送信するか否かを判定することを特徴とする付記15乃至付記25のいずれかに記載のイベント配信システム。付記27ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定するイベント配信方法。付記28ネットワークを介して代理要求を受信した場合、予め登録されている代理要求条件を基に、前記受信した代理要求に含まれるイベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定することを特徴とする付記27に記載のイベント配信方法。付記29前記イベントを受信した場合、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記28に記載のイベント配信方法。付記30前記代理要求を受けた場合、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記28又は付記29に記載のイベント配信方法。付記31前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベントの処理の負荷情報を含み、前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むことを特徴とする付記28乃至付記30のいずれかに記載のイベント配信方法。付記32前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存し、前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理し、前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送し、前記イベントと前記サブスクリプションとの一致を判定し、前記イベントをアプリケーションに通知することを特徴とする付記28乃至付記31のいずれかに記載のイベント配信方法。付記33前記サブスクリプションの登録又は配信削除の処理に伴い前記イベントを転送する装置に関する情報を変更することを特徴とする付記32に記載のイベント配信方法。付記34前記通知条件又は前記代理要求条件の少なくともいずれかが、処理に使用される資源に関する情報、通知するイベントの量に関する情報、又は、通知するイベントの滞留時間に関する情報の少なくとも1つを含むことを特徴とする付記28乃至付記33のいずれかに記載のイベント配信方法。付記35前記代理要求を2以上の装置に送信することを特徴とする付記28乃至付記34のいずれかに記載のイベント配信方法。付記36前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする付記28乃至付記35のいずれかに記載のイベント配信方法。付記37前記代理要求を送信する前記他の装置として、前記イベントの代理要求を送信した装置を除くことを特徴とする付記28乃至付記36のいずれかに記載のイベント配信方法。付記38前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の前記代理要求を受け付けの可否を確認することを特徴とする付記28乃至付記37のいずれかに記載のイベント配信方法。付記39前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の負荷情報を受け取り、受け取った負荷情報を基に前記代理要求を送信するか否かを判定することを特徴とする付記28乃至付記38のいずれかに記載のイベント配信方法。付記40ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御処理をコンピュータに実行させるイベント配信プログラムを格納する記憶媒体。付記41ネットワークを介して代理要求を受信した場合、予め登録されている代理要求条件を基に、前記受信した代理要求に含まれるイベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御処理を含むことを特徴とする付記40に記載のイベント配信プログラムを格納する記憶媒体。付記42前記通知制御処理が、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記41に記載のイベント配信プログラムを格納する記憶媒体。付記43前記代理要求処理が、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記41又は付記42に記載のイベント配信プログラムを格納する記憶媒体。付記44前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベントの処理の負荷情報を含み、前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むことを特徴とする付記41乃至付記43のいずれかに記載のイベント配信プログラムを格納する記憶媒体。付記45前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存する経路制御処理と、前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理する購読要求制御処理と、前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送するイベント受信転送処理と、前記イベントと前記サブスクリプションとの一致を判定する一致判定処理と、前記イベントをアプリケーションに通知するイベント通知処理とを含むことを特徴とする付記41乃至付記44のいずれかに記載のイベント配信プログラムを格納する記憶媒体。付記46前記経路制御処理が、前購読要求制御処理における前記サブスクリプションの登録又は配信削除の処理に伴い前記イベントを転送する装置に関する情報を変更することを特徴とする付記45に記載のイベント配信プログラムを格納する記憶媒体。付記47前記通知条件又は前記代理要求条件の少なくともいずれかが、処理に使用される資源に関する情報、通知するイベントの量に関する情報、又は、通知するイベントの滞留時間に関する情報の少なくとも1つを含むことを特徴とする付記41乃至付記46のいずれかに記載のイベント配信プログラムを格納する記憶媒体。付記48前記通知制御処理又は前記代理要求制御処理の少なくともいずれかが、前記代理要求を2以上の装置に送信することを特徴とする付記41乃至付記47のいずれかに記載のイベント配信プログラムを格納する記憶媒体。付記49前記通知制御処理又は前記代理要求制御処理の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする付記41乃至付記48のいずれかに記載のイベント配信プログラムを格納する記憶媒体。付記50前記通知制御処理又は前記代理要求制御処理の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの代理要求を送信した装置を除くことを特徴とする付記41乃至付記49のいずれかに記載のイベント配信プログラムを格納する記憶媒体。付記51前記通知制御処理又は前記代理要求制御処理の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の前記代理要求の受け付け可否を確認する処理を行うことを特徴とする付記41乃至付記50のいずれかに記載のイベント配信プログラムを格納する記憶媒体。付記52前記通知制御処理又は前記代理要求制御処理の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の負荷情報を受けとり、受け取った負荷情報を基に前記代理要求を送信するか否かを判定する処理を含むことを特徴とする付記41乃至付記51のいずれかに記載のイベント配信プログラムを格納する記憶媒体。以上、実施の形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。この出願は、2010年2月15日に出願された日本出願特願2010-00624を基礎とする優先権を主張し、その開示の全てをここに取り込む。"