(57)【要約】本発明は、大量発生するイベントの配信をイベント配信装置の処理能力を変更せずに所定の時間内で配信するイベント配信装置を提供する。  本発明のイベント配信装置は、予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を含む。
2011099649.tif 000002
【特許請求の範囲】
【請求項１】
予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を含むイベント配信装置。
【請求項２】
予め登録されている代理要求条件を基に、ネットワークを介して受信した代理要求に含まれるイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御部を含むことを特徴と請求項１に記載のイベント配信装置。
【請求項３】
前記通知制御部が、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする請求項２に記載のイベント配信装置。
【請求項４】
前記代理要求制御部が、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする請求項２又は請求項３に記載のイベント配信装置。
【請求項５】
前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベント配信装置の負荷情報を含み、
前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むこと
を特徴とする請求項２乃至請求項４のいずれかに記載のイベント配信装置。
【請求項６】
前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存する経路制御部と、
前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理する購読要求制御部と、
前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送するイベント受信転送部と、
前記イベントと前記サブスクリプションとの一致を判定する一致判定部と、
前記イベントをアプリケーションに通知するイベント通知部と
を含むことを特徴とする請求項２乃至請求項５のいずれかに記載のイベント配信装置。
【請求項７】
前記通知条件又は前記代理要求条件の少なくともいずれかが、自装置の資源に関する情報、自装置で通知するイベントの量に関する情報、又は、自装置で通知するイベントの滞留時間に関する情報の少なくとも１つを含むことを特徴とする請求項２乃至請求項６のいずれかに記載のイベント配信装置。
【請求項８】
前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を２以上の前記他の装置に送信することを特徴とする請求項２乃至請求項７のいずれかに記載のイベント配信装置。
【請求項９】
前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする請求項２乃至請求項８のいずれかに記載のイベント配信装置。
【請求項１０】
前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の前記代理要求の受け付けの可否を確認することを特徴とする請求項２乃至請求項９のいずれかに記載のイベント配信装置。
【請求項１１】
前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の負荷情報を受け取り、受け取った負荷情報を基に前記代理要求を送信するか否かを判定することを特徴とする請求項２乃至１０のいずれかに記載のイベント配信装置。
【請求項１２】
予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を備えるイベント配信装置と、
前記イベント配信装置に前記ネットワークを介して前記イベントをパブリッシュするパブリッシャと、
前記イベント配信装置に前記サブスクリプションを送信するサブスクライバと、
前記イベント配信装置から前記イベントの通知を受けるアプリケーションと
を含むことを特徴とするイベント配信システム。
【請求項１３】
前記イベント配信装置が、予め登録されている代理要求条件を基に、ネットワークを介して受信した代理要求に含まれるイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御部を含むことを特徴とする請求項１２に記載のイベント配信システム。
【請求項１４】
前記通知制御部が、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする請求項１３に記載のイベント配信システム。
【請求項１５】
前記代理要求制御部が、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする請求項１３又は請求項１４に記載のイベント配信システム。
【請求項１６】
前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベント配信装置の負荷情報を含み、
前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むこと
を特徴とする請求項１３乃至請求項１５のいずれかに記載のイベント配信システム。
【請求項１７】
前記イベント配信装置が、
前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存する経路制御部と、
前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理する購読要求制御部と、
前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送するイベント受信転送部と、
前記イベントと前記サブスクリプションとの一致を判定する一致判定部と、
前記イベントを前記アプリケーションに通知するイベント通知部と
を含むことを特徴とする請求項１３乃至請求項１６のいずれかに記載のイベント配信システム。
【請求項１８】
前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を２以上の装置に送信することを特徴とする請求項１３乃至請求項１７のいずれかに記載のイベント配信システム。
【請求項１９】
前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする請求項１３乃至請求項１８のいずれかに記載のイベント配信システム。
【請求項２０】
ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定するイベント配信方法。
【請求項２１】
ネットワークを介して代理要求を受信した場合、予め登録されている代理要求条件を基に、前記受信した代理要求に含まれるイベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定することを特徴とする請求項２０に記載のイベント配信方法。
【請求項２２】
ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御処理をコンピュータに実行させるイベント配信プログラムを格納する記憶媒体。
【請求項２３】
ネットワークを介して代理要求を受信した場合、予め登録されている代理要求条件を基に、前記受信した代理要求に含まれるイベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御処理を含むこと特徴とする請求項２２に記載のイベント配信プログラムを格納する記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、イベント配信装置に関し、特にイベントを配信するイベント配信装置、イベント配信システム、及び、イベント配信方法に関する。
【背景技術】
【０００２】
イベントをパブリッシュ（ｐｕｂｌｉｓｈ）するパブリッシャ（（ｐｕｂｌｉｓｈｅｒ）以下、ｐｕｂなどと言うこともある）がパブリッシュしたイベントは、このイベントの通知先であるアプリケーション（ａｐｐｌｉｃａｔｉｏｎ、以下、ａｐｐと言うこともある）に通知（ｎｏｔｉｆｙ）される。このようなイベントを通知するために、ネットワークを構成する場合がある。例えば、図６は、このようなアプリケーションにイベントを通知するためのネットワーク（以下、このイベントを配信するネットワークをイベント配信ＮＷ（ｎｅｔｗｏｒｋ））と言うこともある。）の概念を示す一例である。このようなイベント配信ＮＷは、イベントを転送又は通知する複数のイベント配信装置（以下、ノード（ｎｏｄｅ）と言うこともある）から構成され、さらにアプリケーションとパブリッシャが接続されている。また、イベント配信ＮＷには、イベントを通知する条件であるサブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎ）などが登録される。登録されたサブスクリプションに沿ってイベントが、パブリッシャからアプリケーションに配信される。このサブスクリプションは、例えば、イベント配信ＮＷを構成するノードに分散登録されている。
このようなイベント配信ＮＷとして、例えば、アプリケーション層マルチキャスト（Ａｐｐｌｉｃａｔｉｏｎ  Ｌｅｖｅｌ（Ｌａｙｅｒ）Ｍｕｌｔｉｃａｓｔ、以下、ＡＬＭと言う）が使われている。ＡＬＭは、同じイベントを要求するサブスクリプションをイベント配信ＮＷ上の複数のノード群に分散配置し、同じイベントを要求するサブスクリプションが登録されたノード群をクラスタリング（ｃｌｕｓｔｅｒｉｎｇ、クラスタ構成）する。このようにクラスタリングされたノード群を備えるＡＬＭは、パブリッシャがイベント配信ＮＷにイベントをパブリッシュしたときに、クラスタ内のノード群が連携して、イベントを効率的に転送及び通知する手法である。図８は、ノード群の一例を示す概念図である。図８において、ノードＡ，ノードＣ，ノードＥ，ノードＦが、１つのクラスタ、つまりノード群を構成している。そして、ＡＬＭは、パブリッシャ（ｐｕｂ２）がパブリッシュしたイベントをクラスタ内のノード（ノードＡ，ノードＣ，ノードＥ，ノードＦ）に配信し、各ノードが複数のアプリケーション（ａｐｐ１，ａｐｐ２，…，ａｐｐ３０００）にイベントを通知する。
また、ＡＬＭの１つであるＳｃｒｉｂｅ（ａ  ｓｃａｌａｂｌｅ  ａｐｐｌｉｃａｔｉｏｎ−ｌｅｖｅｌ  ｍｕｌｔｉｃａｓｔ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）は、分散ハッシュの１つであるＰａｓｔｒｙのルーティングアルゴリズムを利用してクラスタ（マルチキャストツリー）を生成する。このクラスタが、イベントを転送及び通知する。（例えば、非特許文献１、２を参照）
このＳｃｒｉｂｅは、イベントのタイプごとにクラスタを生成する。このイベントのタイプに対するクラスタが生成されるとき、そのクラスタを識別する識別子（クラスタＩＤ）に最も近いノード識別子（ノードＩＤ）を持つノードが、アクセスポイントとなる。なお、ここにおける「近い」とは、クラスタＩＤもノードＩＤも同じＩＤ空間上に存在し、そのＩＤ空間上で近いことを意味している。そして、そのアクセスポイントをルートとし、そのタイプを持つサブスクリプションが登録されている全てのノードをそのルートの下位の要素として構成されたマルチキャストツリーが生成される。
このようなイベント配信ＮＷのクラスタの構成の動作について、図８を参照してさらに説明する。
図８に示すノード群（ノードＡ，ノードＣ，…，ノードＦ）は、イベントのタイプ、例えば「衝撃」を持つサブスクリプションが登録されているとする。また、そのタイプ「衝撃」のクラスタのためのクラスタＩＤに、ノードＡのノードＩＤが一番近いとする。その結果として、図８に示すように、ノードＡが、アクセスポイントとしてルートとなる。そして、ノードＡをルートとした転送経路（図８の矢印で示すマルチキャストツリー）が生成される。
そして、そのマルチキャストを使用して、図１０において矢印で示すように、ノードＡが、ａｐｐ１，ａｐｐ２，…，ａｐｐ１０００に、ノードＣがａｐｐ１００１，ａｐｐ１００２，…，ａｐｐ２０００に、ノードＦがａｐｐ２００１，ａｐｐ２００２，…，ａｐｐ３０００にイベントを通知する。
なお、アクセスポイント（図８ではノードＡ）は、ノードが受信するイベント数や登録されているサブスクリプションの数に基づいて、イベント配信ＮＷ中の各ノードのロードバランス（ｌｏａｄ  ｂａｌａｎｃｅ：負荷を分散）する場合もある（例えば、非特許文献３参照）。
非特許文献３以外でも、イベント発生やノードに登録されるサブスクリプション数の特性を活用して、イベント配信ＮＷのノードのロードバランスすることが提案されている。（例えば、特許文献１、２参照）
このようなロードバランス（負荷分散）は、各ノードの負荷状態を確認し、最も負荷が軽いノードを候補として選ぶ。（例えば、特許文献３参照）
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００９−１１０１６５
【特許文献２】特開２００６−３０９７０１
【特許文献３】特開２００５−１４９４２３
【非特許文献】
【０００４】
【非特許文献１】Ｃａｓｔｒｏ，Ｍ．Ｄｒｕｓｃｈｅｌ，Ｐ．Ｋｅｒｍａｒｒｅｃ，Ａ．−Ｍ．Ｒｏｗｓｔｒｏｎ，Ａ．Ｉ．Ｔ．″ＳＣＲＩＢＥ：Ａ  ｌａｒｇｅ−ｓｃａｌｅ  ａｎｄ  ｄｅｃｅｎｔｒａｌｉｚｅｄ  ａｐｐｌｉｃａｔｉｏｎ−ｌｅｖｅｌ  ｍｕｌｔｉｃａｓｔ  ｉｎｆｒａｓｔｒｕｃｔｕｒｅ″，ＩＥＥＥ  ＪＯＵＲＮＡＬ  ＯＮ  ＳＥＬＥＣＴＥＤ  ＡＲＥＡＳ  ＩＮ  ＣＯＭＭＵＮＩＣＡＴＩＯＮＳ，ＶＯＬ．２０，ＮＯ．８，ＯＣＴＯＢＥＲ  ｐ１００−１１０，２００２
【非特許文献２】Ａ．Ｒｏｗｓｔｒｏｎ  ａｎｄ  Ｐ．Ｄｒｕｓｃｈｅｌ，″Ｐａｓｔｒｙ：Ｓｃａｌａｂｌｅ，ｄｅｃｅｎｔｒａｌｉｚｅｄ  ｏｂｊｅｃｔ  ｌｏｃａｔｉｏｎ  ａｎｄ  ｒｏｕｔｉｎｇ  ｆｏｒ  ｌａｒｇｅ−ｓｃａｌｅ  ｐｅｅｒ−ｔｏ−ｐｅｅｒ  ｓｙｓｔｅｍｓ″．ＩＦＩＰ／ＡＣＭ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｓｙｓｔｅｍｓ  Ｐｌａｔｆｏｒｍｓ（Ｍｉｄｄｌｅｗａｒｅ），Ｈｅｉｄｅｌｂｅｒｇ，Ｇｅｒｍａｎｙ，ｐ３２９−３５０，Ｎｏｖｅｍｂｅｒ，２００１
【非特許文献３】Ａｓｈｗｉｎ  Ｒ．Ｂｈａｒａｍｂｅ，Ｍｕｋｅｓｈ  Ａｇｒａｗａｌ，Ｓｒｉｎｉｖａｓａｎ  Ｓｅｓｈａｎ，″Ｍｅｒｃｕｒｙ：ｓｕｐｐｏｒｔｉｎｇ  ｓｃａｌａｂｌｅ  ｍｕｌｔｉ−ａｔｔｒｉｂｕｔｅ  ｒａｎｇｅ  ｑｕｅｒｉｅｓ″，Ｉｎ  ＳＩＧＣＯＭＭ，ｐ３５３−３６６，２００４
【発明の概要】
【発明が解決しようとする課題】
【０００５】
イベント配信装置は、例えば、栽培情報や特売情報などのイベント通知などに使用される。これらのイベント通知は、イベントの発生から通知までの時間に制限が必要である。つまり、イベント配信装置は、イベント発生からイベント通知までに所定の時間制限が必要となる場合がある。
また、イベントとしては、例えば、大地震の発生、著名人のスキャンダルの発生など、イベントの発生時期は予測できないが、通知までの時間の制限だけではなく、発生すると大量のイベントの通知が必要となるイベントも想定される。このような突発的に大量発生するイベントを受信したイベント配信装置は、イベント処理、例えば、イベントを複数のアプリケーションに通知する処理、及び、他のイベント配信装置へのイベントを転送する処置などの負荷が重くなる。その結果、大量のイベントの配信を依頼されたイベント配信装置は、適正な時間内でのアプリケーションへのイベントの通知が難しいという問題点があった。
この対策として、予め、このような大量発生の恐れのあるイベントのタイプに割り当てられているクラスタに属するイベント配信装置の数を増やし、さらに各イベント配信装置が担当するイベントの通知先であるアプリケーションの数を減らしておく対応が考えられる。しかし、このようなイベントは、突発的に発生し、所定の時間当たりにどれくらい発生するかを予測することが困難である。そのため、そのタイプのクラスタにどの程度のイベント配信装置を割り当てておけば良いかを、事前に正確に決めることができないという問題点があった。
また、イベント配信装置のクラスタの構成も大きくなり、クラスタ内のイベント配信装置の数が多くなると、このクラスタ内のイベント配信装置間でのイベントの転送処理も増えるとの問題があった。
本発明の目的は、上記問題点を解決し、イベントが大量に発生し、イベントをアプリケーションに通知する処理負荷が重くなっても、適切にアプリケーションにイベントを通知するイベント配信装置、イベント配信システム、及び、イベント配信方法を提供することにある。
【課題を解決するための手段】
【０００６】
本発明のイベント配信装置は、予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を含む。
本発明のイベント配信システムは、予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を備えるイベント配信装置と、前記イベント配信装置にネットワークを介して前記イベントをパブリッシュするパブリッシャと、前記イベント配信装置にサブスクリプションを登録するサブスクライバと、前記イベント配信装置から前記イベントの通知を受けるアプリケーションとを含む。
本発明のイベント配信方法は、ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する。
本発明の記憶媒体は、ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御処理をコンピュータに実行させるイベント配信プログラムを格納する。
【発明の効果】
【０００７】
本発明は、イベントが大量に発生し、イベントをアプリケーションに通知するイベント配信装置の処理負荷が重くなっても、適切にアプリケーションにイベントを通知することが出来る。
【図面の簡単な説明】
【０００８】
【図１】本発明における第１の実施形態に係るイベントの一例を示す図である。
【図２】第１の実施形態に係るイベントパターンの一例を示す図である。
【図３】第１の実施形態に係るサブスクリプションの一例を示す図である。
【図４】第１の実施形態に係るイベント配信システムの構成の一例を示すブロック図である。
【図５】第１の実施形態に係るイベント配信装置の構成の一例を示すブロック図である。
【図６】第１の実施形態に係るイベント配信ＮＷの構成の一例を示す図である。
【図７Ａ】第１の実施形態に係る網構成装置情報の一例を示す図である。
【図７Ｂ】第１の実施形態に係る網構成装置情報の一例を示す図である。
【図８】第１の実施形態に係る転送経路の一例を示す図である。
【図９】第１の実施形態に係る転送経路情報の一例を示す図である。
【図１０】第１の実施形態に係るイベントの配信の一例を示す図である。
【図１１】第１の実施形態に係るサブスクリプションの保持の一例を示す図である。
【図１２】第１の実施形態に係る代理要求条件の一例を示す図である。
【図１３】第１の実施形態に係るメッセージ転送部における処理の一例を示す第１のフローチャート図である。
【図１４】第１の実施形態に係るメッセージ転送部における処理の一例を示す第２のフローチャート図である。
【図１５】第１の実施形態に係るサブスクリプションの登録処理の一例を示すフローチャート図である。
【図１６】第１の実施形態に係るサブスクリプションの削除処理の一例を示すフローチャート図である。
【図１７】第１の実施形態に係る転送経路への参加要求を依頼する処理の一例を示すフローチャート図である。
【図１８】第１の実施形態に係る転送経路からの離脱要求を依頼する処理の一例を示すフローチャート図である。
【図１９】第１の実施形態に係る転送経路へ他の装置を参加させる処理の一例を示すフローチャート図である。
【図２０】第１の実施形態に係る転送経路から他の装置を離脱させる処理の一例を示すフローチャート図である。
【図２１】第１の実施形態に係るイベント受信転送部の処理の一例を示すフローチャート図である。
【図２２】第１の実施形態に係る一致判定部の処理の一例を示すフローチャート図である。
【図２３】第１の実施形態に係る通知制御部の処理の一例を示すフローチャート図である。
【図２４】第１の実施形態に係るイベント通知部の処理の一例を示すフローチャート図である。
【図２５】第１の実施形態に係る代理要求制御部の処理の一例を示すフローチャート図である。
【図２６】第１の実施形態に係る別のイベント配信ＮＷの一例を示す図である。
【図２７】第１の実施形態に係る別のイベントの転送経路情報の一例を示す図である。
【図２８】第１の実施形態に係るイベント配信システムの別の構成を示すブロック図である。
【図２９】第１の実施形態に係るイベント配信装置の別の構成を示すブロック図である。
【図３０】第１の実施形態に係るイベント配信装置の別の構成を示すブロック図である。
【図３１】第１の実施形態に係るイベント配信装置の別の構成を示すブロック図である。
【図３２】第４の実施形態に係る代理要求条件の一例を示す図である。
【図３３】第４の実施形態に係る代理要求制御部の処理の一例を示すフローチャート図である。
【図３４】第６の実施形態の通知制御部の処理の一例を示すフローチャート図である。
【図３５】第７の実施形態に係る代理要求制御部の処理の一例を示すフローチャート図である。
【図３６】第８の実施形態に係るイベント配信装置の構成の一例を示すブロック図である。
【図３７】第８の実施形態に係る通知制御部の処理の一例を示すフローチャート図である。
【図３８】第８の実施形態に係る代理要求制御部の処理の一例を示すフローチャート図である。
【図３９】第８の実施形態に係るイベント通知部の処理の一例を示すフローチャート図である。
【図４０】第９の実施形態に係るイベント配信装置の構成の一例を示すブロック図である。
【図４１】第９の実施形態に係る通知制御部の処理の一例を示すフローチャート図である。
【発明を実施するための形態】
【０００９】
次に、本発明について図面を参照して詳細に説明する。
（関連用語）
まず、本発明の実施形態の説明における用語を整理しておく。
「イベント（ｅｖｅｎｔ）」とは、何かの現象を契機として発生するデータのことである。例えば、イベントとは、携帯端末などの操作、ＲＦ（Ｒａｄｉｏ  Ｆｒｅｑｕｅｎｃｙ）タグ又はセンサを用いた信号の検出などに基づいて発生するデータのことである。これらのイベントは、後ほど説明するパブリッシャが、イベント配信ＮＷにパブリッシュする。
イベントは、１つのデータに限られず、複数のデータを含んでもよい。イベントを構成する複数のデータは、特段区別をつける必要はないが、本発明の実施形態の説明においては、説明の便宜のため、イベントの種別を表すデータを特に「タイプ」と呼び、その他のデータを「属性」と呼ぶこととする。
図１は、複数のデータから構成されたイベントの一例を示す図である。図１に示すイベントは、イベントの種別を表すタイプ（例えば、物がぶつかる「衝撃」、扉の「開閉」、温度センサの「温度」など）とその他のデータである属性から構成されている。さらに、属性は、イベント検出した装置やセンサなどを示すデータ（図１の「装置ＩＤ」）、その装置やセンサが取得したデータ（図１では、「データ」）、データの取得場所や取得時刻（図１では、「場所」「時刻」）などを含む。また、「装置ＩＤ」、「データ」、「場所」、「時刻」などの各属性の名称を「属性名」とし、属性名に対する各データ値（「ＩＤ１」、「開」、「東京都港区」、「１４：１０：２５」など）を「属性値」と言うこととする。つまり、属性は、属性名と属性値とから構成されているものとして説明する。なお、以下の本発明の実施形態の説明において、１個以上のタイプと０個以上の属性から構成されるイベントについて説明するが、これはあくまで説明の便宜のためである。本発明の実施形態は、タイプを指定せずに１個以上の属性から構成されるイベントにも適用出来る。
また、既に説明したパブリッシャがパブリッシュする場合だけではなく、後ほど説明する、イベント配信装置の間で転送される転送要求、及び、代理要求に含まれる場合にもイベントと言う。
「イベントパターン（ｅｖｅｎｔ  ｐａｔｔｅｒｎ）」とは、アプリケーションに通知する対象となるイベントを指定する条件である。なお、本発明の実施形態の説明で使用するイベントパターンは、既に説明したイベントに合わせ、１個以上のタイプと０個以上の属性（属性名と属性値）を指定したものとして説明する。ただし、イベントパターンもこれに限られるわけではない。本発明の実施形態は、例えば、イベントパターンとして、タイプを指定せずに１個以上の属性から構成されるイベントパターンにも適用出来る。
図２は、イベントパターンの一例を示す図である。
図２において、例えば、１つ目のイベントパターンは、タイプが「衝撃」、属性名「場所」に対する属性値が「東京都港区」と指定されている。
「イベント一致判定（処理）」とは、イベント配信装置において、イベントとイベントパターンが一致（以下、マッチ（ｍａｔｃｈ）と言う場合もある）するか否かを判定することである。
イベントがイベントパターンに一致（マッチ）するか否かの判定とは、イベントパターンで指定されているタイプがイベントのタイプと一致し、イベントパターン指定された属性とイベントの属性が一致することである。ここでの属性の一致とは、イベントパターンの属性名に対する属性値が、イベントの同じ属性名に対する属性値と一致することである。イベントパターンのタイプとイベントのタイプが一致し、イベントパターンの属性がイベントの属性と一致した場合に、判定結果は、一致（マッチ）となる。
例えば、図１に示す「Ｅｖｅｎｔ１」と図２に示す「Ｅｖｅｎｔ  Ｐａｔｔｅｒｎ１」を使用して説明すると、次のようになる。
まず、Ｅｖｅｎｔ  Ｐａｔｔｅｒｎ１で指定されているタイプ「衝撃」が、Ｅｖｅｎｔ１のタイプ「衝撃」が同じである。さらに、Ｅｖｅｎｔ  Ｐａｔｔｅｒｎ１で指定されている属性名「場所」に対する属性値「東京都港区」が、Ｅｖｅｎｔ１の属性名「場所」に対する属性値「東京都港区」と一致している。従って、図１のＥｖｅｎｔ１は、図２のＥｖｅｎｔ  Ｐａｔｔｅｒｎ１に一致するとの判定の結果となる。なお、図２に示すＥｖｅｎｔ  Ｐａｔｔｅｒｎ１では、図１に示すＥｖｅｎｔ１に記述される属性のうち、属性名「装置ＩＤ」、「データ」、「時刻」に対する属性値は指定されていない。このように属性値が指定されていない場合は、指定されていない属性値（この場合、属性名「装置ＩＤ」、「データ」、「時刻」など）が、どのような値でもよいことを意味している。
なお、本発明の実施形態は、イベントパターンの属性値を、イベントの属性値の一部と一致する場合も一致と判定しても良い。例えば、本発明の実施形態は、イベントパターンの属性値＝「東京都」を、イベントの属性値＝「東京都港区」と一致すると判定しても良い。また、本発明の実施形態は、一致判定を、完全に一致する場合を一致と判定しても良い。さらに、本発明の実施形態は、一致判定に使用する属性値を、１つの値ではなく、範囲を指定してもよい。
後ほど詳細に説明するが、本発明の実施形態に係るイベント配信装置は、パブリッシャがパブリッシュしたイベントと、サブスクライバがサブスクライブしたサブスクリプションに含まれるイベントパターンとの一致を判定する。
「パブリッシャ（ｐｕｂｌｉｓｈｅｒ）」とは、検出したイベントを、イベント配信ＮＷにパブリッシュする装置、システム、プログラムなどである。パブリッシャは、起きた事象そのものを検出する装置など（例えば、携帯端末、ＲＦタグ、センサなど）でもよく、そのような装置からイベントに関する情報を受け取って、イベント配信ＮＷにイベントをパブリッシュする装置（例えばサーバなど）などでもよい。
「パブリッシュ（ｐｕｂｌｉｓｈ）」とは、パブリッシャがイベント配信ＮＷなどにイベント送り出すことである。「パブリッシャがイベントをイベント配信ＮＷにパブリッシュする」などと言うこととする。
「サブスクライバ（ｓｕｂｓｃｒｉｂｅｒ）」とは、イベント配信ＮＷにイベントの通知に関する情報（例えば、どのような通知先にイベントを通知するかなど）を指定する装置、システム、プログラムなどである。さらに具体的に説明すると、サブスクライバは、イベント配信ＮＷに次に説明するサブスクリプションをサブスクライブする。
「サブスクリプション（ｓｕｂｓｃｒｉｐｔｉｏｎ）」とは、サブスクライバがイベントの通知を要求するときにイベント配信ＮＷにサブスクライブするデータのことである。サブスクリプション（以下、「購読要求」と言うこともある。）は、サブスクリプションを識別する「サブスクリプションＩＤ」と、既に説明した「イベントパターン」と、イベントパターンに一致したイベントの通知先である１つ以上の「通知先」を含む。なお、通知先は、後ほど説明するアプリケーションであり、例えば通知先のデータ構成をリスト構成とするなどして、複数のアプリケーションを指定することができてもよい。
図３は、サブスクリプションの一例を示した図である。
図３に示す１つ目のサブスクリプション（Ｓｕｂｓｃｒｉｐｔｉｏｎ１）の一例は、次のように構成されている。例えば、サブスクリプションＩＤが「ｓｕｂ１」、イベントパターンが「Ｅｖｅｎｔ＿Ｐａｔｔｅｒｎ（タイプ＝「衝撃」、場所＝「東京都港区」）」、イベントパターンにマッチしたイベントの通知先が「ａｐｐ１，ａｐｐ２，…，ａｐｐ１０００」と指定されている。
このサブスクリプションのイベントパターンとイベントとの一致判定もイベント一致判定と言う。このような一致（マッチ）の場合には、例えば、「イベントがサブスクリプションのイベントパターンにマッチする」、「イベントがサブスクリプションに一致する」などとも言うこととする。
「サブスクライブ（ｓｕｂｓｃｒｉｂｅ）」とは、サブスクライバがサブスクリプションをイベント配信ＮＷなどに登録するために送り出すことである。「サブスクライバは、サブスクリプションをイベント配信ＮＷにサブスクライブする」などと言うこととする。
「アプリケーション（ａｐｐｌｉｃａｔｉｏｎ）」とは、イベント配信ＮＷがイベントを通知する通知先である装置、システム、プログラムなどのことである。
続いて、発明を実施するための最良の形態について図面を参照して詳細に説明する。
なお、以下の本発明の実施形態に係る説明では、説明の便宜のため、イベント配信装置のイベントの転送は、イベント配信ＮＷの一部のイベント配信装置に転送する場合について説明する。ただし、イベント配信装置は、イベント配信ＮＷに含まれる全てイベント配信装置にイベントを転送（例えば、ブロードキャスト）してもよく、他の技術（例えば既に説明した非特許文献３など）を用いてイベントを転送してもよい。
（第１の実施形態）
本発明の第１の実施形態に係るイベント配信装置１０の構成及び動作について、さらに図４−図２９を参照して詳細に説明する。
図４は、第１の実施形態に係るイベント配信装置１０が含まれるイベント配信システム１の構成の一例を示すブロック図である。
なお、特に断らない限り、イベント配信装置１０などは、複数の場合も含まれるものとする。
イベント配信システム１は、イベント配信装置１０と、パブリッシャ２０と、サブスクライバ３０と、アプリケーション４０と、イベント配信ネットワーク（以下、イベント配信ＮＷ５０とする）とを含む。
なお、図４において、イベント配信ＮＷ５０を１つとして図示しているのは、説明の便宜のためであり、イベント配信システム１は、論理的又は物理的に２つ以上のイベント配信ＮＷ５０が含んでも良い。
イベント配信装置１０は、受け取ったイベントを所定の他のイベント配信装置１０への転送（ｆｏｒｗａｒｄ）、及び、所定のアプリケーション４０へ通知（ｎｏｔｉｆｙ）する装置、システム、又は、プログラムに基づいて動作するコンピュータである。なお、プログラムは、図示しない記憶媒体に格納される。以下、イベント配信装置１０を、ノードをいう場合もあり、各ノードを区別するために、ノードＡ，ノードＢ，…などと言う場合もある。なお、イベント配信装置１０は、単独で、又は、他のイベント配信装置１０と接続してイベント配信ＮＷ５０の一部を構成している。
なお、イベント配信装置１０については、後ほど詳細に説明する。
パブリッシャ２０は、イベント配信ＮＷ５０に接続して、イベントをパブリッシュする装置、システム、又は、コンピュータ上で動作するプログラムなどであり、単独の装置でもよく、複数の装置でもよい。パブリッシャ２０は、既に説明したとおり、例えば、センサや、監視装置などもよく、他の装置で検出した現象を基にイベントをイベント配信ＮＷ５０にパブリッシュするサーバなどでもよい。なお、イベント配信ＮＷ５０に接続するパブリッシャ２０もイベント配信ＮＷ５０の一部を構成してもよい。
サブスクライバ３０は、イベント配信ＮＷ５０に接続し、イベント配信ＮＷ５０にパブリッシュされたイベントの一致判定の条件及び通知先などを要求するサブスクリプションをサブスクライブする装置、システム、又は、コンピュータ上で動作するプログラムなどである。サブスクライバ３０も単独でも複数でもよく、イベント配信ＮＷ５０の一部を構成してもよい。
アプリケーション４０は、イベント配信ＮＷ５０に接続し、パブリッシャ２０がパブリッシュしたイベントのうち、サブスクライバ３０がサブスクライブしたサブスクリプションに一致したイベントの通知を受け取る装置、システム、又は、プログラムなどである。例えば、アプリケーション４０は、近接センサの検出イベントの通知を受けてドアを開けるような装置、又は、ＲＦＩＤの検出の通知を基に料金を決済する装置などである。アプリケーション４０も単独でも複数でもよく、イベント配信ＮＷ５０の一部を構成してもよい。
イベント配信ＮＷ５０は、パブリッシャ２０に基づくイベントのパブリッシュや、アプリケーション４０へのイベントの通知を実現するために、イベント配信装置１０などを含む。なお、イベント配信ＮＷ５０は、既に説明した装置以外の装置、例えば、ネットワークを構成する装置であるルータやブリッジなどを含んでもよい。
次に、第１の実施形態の係るイベント配信システム１の動作について説明する。
イベントに先立ち、サブスクライバ３０は、アプリケーション４０に通知するイベントのイベントパターンと通知先のアプリケーション４０に関する情報を含むサブスクリプションをイベント配信ＮＷ５０にサブスクライブする。具体的には、サブスクライバ３０は、イベント配信ＮＷ５０のイベント配信装置１０に、サブスクリプションをサブスクライブする。このサブスクライブされたサブスクリプションの登録後に、イベント配信装置１０を用いたイベントの通知が可能となる。
その後、イベントを検出したパブリッシャ２０は、イベント配信ＮＷ５０、具体的には、イベント配信ＮＷ５０のイベント配信装置１０に、イベントをパブリッシュする。
イベントのパブリッシュを受けたイベント配信ＮＷ５０のイベント配信装置１０は、登録済みのサブスクリプションと受け取ったイベントとの一致を判定し、一致した場合は、そのサブスクリプションの通知先であるアプリケーション４０にイベントを通知する。
本実施形態の説明では、サブスクライバ３０がイベントに先立ちサブスクリプションをサブスクライブする例を説明したが、この説明は本発明の動作順序を限定するものではない。サブスクライバ３０とパブリッシャ２０とは、相互に独立に、又は、並行して動作してもよい。
なお、本実施形態におけるイベント配信ＮＷ５０を含めた各装置（イベント配信装置１０、パブリッシャ２０、サブスクライバ３０、アプリケーション４０、など）間のデータの授受及び接続確保などは、一般的なネットワークのプロトコルを使用すればよい。そのため、本実施形態の説明において、各装置は相手先が分かっているものとし、相手先の検出やデータのやり取りの詳細な説明は省略する。
次に、第１の実施形態に係るイベント配信装置１０（ノード）について詳細に説明する。
まず、イベント配信装置１０の構成について説明する。
図５は、第１の実施形態に係るイベント配信装置１０（ノード）の構成の一例を示すブロック図である。
第１の実施形態に係るイベント配信装置１０は、メッセージ転送部１０１と、経路制御部１０２と、経路情報保持部１０３と、購読要求制御部１０４と、購読要求保持部１０５と、イベント受信転送部１０６と、一致判定部１０７と、通知制御部１０８と、イベント通知部１０９と、代理要求制御部１１０と、代理要求条件保持部１１１とを含む。
メッセージ転送部１０１は、外部の装置（パブリッシャ２０、サブスクライバ３０、他のイベント配信装置１０）などと、以下で説明するイベント配信装置１０内部の各部とでやり取りされる、各種メッセージなどを仲介する。
経路制御部１０２は、経路情報保持部１０３が保持しているイベント配信装置１０が接続しているイベント配信ＮＷ５０におけるイベント配信装置１０の接続に関連する情報を制御する。例えば、後ほど詳細に説明するように、イベント配信装置１０が受け取ったサブスクリプションを基に、経路制御部１０２は、イベントを転送するための経路に関する転送経路情報を修正及び構築する。
経路情報保持部１０３は、イベント配信ＮＷ５０におけるイベント配信装置１０の接続に関する情報である「網構成装置情報」と、所定のイベントのタイプの配信に関するイベント配信装置１０の装置群（クラスタ）の情報である「転送経路情報」などを保持している。この転送経路情報は、例えば、経路として木構造を使用した場合における、自装置と子関係となるイベント配信装置１０の情報などを保持している。なお、本実施形態の説明では、転送経路情報を木構造として使用して説明するが、これは説明の便宜のためである。本発明の実施形態のイベント配信装置１０は、後ほど説明するように、転送経路情報として木構造に限らず他の構造も適用することが出来る。また、本発明の実施形態のイベント配信装置１０に適用する木構造としては、各種の構造、例えば、マルチキャストツリーや、スパニングツリーなどを適用することが可能である。
この、網構成装置情報及び転送経路情報について、図６−図１０を参照してさらに説明する。
図６は、第１の実施形態に係るイベント配信システム１のネットワークの構成の一例を示す図である。
イベント配信装置１０である各ノード（ノードＡ，ノードＢ，…，ノードＦ）が、イベント配信ＮＷ５０を構成する。さらに、イベント配信ＮＷ５０は、パブリッシャ２０（ｐｕｂ１，…）とアプリケーション４０（Ａｐｐ１，…，Ａｐｐ１０００，…）が接続されている。なお、サブスクライバ３０は、説明の便宜のため、省略した。また、サブスクリプションは、イベント配信ＮＷ５０に登録済みとする。
図７は、図６における網構成装置情報の一例を示す図である。図７Ａは、図６のノードＡの網構成装置情報を示し、図７Ｂは、図６のノードＣの網構成装置情報を示している。
図６の構成において、ノードＡは、ノードＢとノードＣとノードＥと接続しているため、ノードＡの網構成装置情報は、図７Ａに示すように、ノードＢ，ノードＣ，ノードＥに関する情報を保持している。なお、図７Ａは、ノードに関する情報としてノードＩＤを保存する例を示している。また、ノードＣは、ノードＡ，ノードＤ，ノードＥに接続しているため、図７Ｂに示すように、ノードＣの網構成装置情報は、ノードＡ，ノードＤ，ノードＥに関する情報（図７ＢではノードＩＤ）を保持している。
なお、網構成装置情報の登録は、ネットワークの管理者が予め設定しておいてもよく、また、例えばＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）など一般的なネットワークのプロトコルを使用して登録すればよく、詳細な説明は省略する。
なお、図６を含め、各図におけるネットワークでの各装置の接続は、論理的な接続を示している。従って、各装置などは、適宜、一般的なネットワークのプロトコルなどを使用して、図示しない論理的な接続を設けることが可能である。
図８は、図６に示す第１の実施形態に係るイベント配信システム１のイベントの転送経路の一例を示す図である。イベントの転送経路の構造も、既に説明しているように、いろいろな構造を使用できるが、図８では、一例として、木構造を使用した場合を示している。図８において、所定のイベントのタイプ（例えば、タイプ＝「衝撃」）に対するイベントの転送経路は、ノードＡが最も上位（アクセスポイント）に位置し、その下にノードＣとノードＥとが、ノードＥの下にノードＦが接続する経路となっている。
図９は、図８における転送経路情報の一例を示す図である。図８においてイベントの転送経路として木構造を使用しているため、接続しているノードの情報だけでなく、接続先ノードが経路上の下位（子）に関する情報も保持している。図８においてノードＡは、ノードＣとノードＥに接続し、両方の親、つまりノードＣとノードＥとはノードＡの子ノードであるため、図９に示すノードＡの転送経路情報は、ノードＣとノードＥとの情報（図９ではノードＩＤ）を保持している。
なお、この転送経路情報は、後ほどさらに詳細に説明するが、イベント配信装置１０に登録又は削除されるサブスクリプションを受けた場合、購読要求制御部１０４から指示を受けた経路制御部１０２が変更する。
さらに、図１０を参照して、イベントの配信について説明する。
図１０は、第１の実施形態に係るイベントの配信の一例を示す図である。
ここで、一例として、パブリッシャ２０（ｐｕｂ１）がイベントをパブリッシュする場合について説明する。パブリッシャ２０（ｐｕｂ１）は、イベントをパブリッシュするためには、イベントの転送経路の最上位（アクセスポイント）にイベントをパブリッシュすることが必要である。そこでパブリッシャ２０（ｐｕｂ１）は、例えば、接続されているノードＣにアクセスポイントのノードを問い合わせ、アクセスポイントであるノードＡの情報（例えばノードＩＤなど）を受け取る（図１０の経路（１））。その受け取った情報を基に、パブリッシャ２０（ｐｕｂ１）は、アクセスポイントであるノードＡにイベントをパブリッシュする（図１０の経路（２））。なお、パブリッシャ２０（ｐｕｂ１）が、ノードＡと論理的な接続がない場合もある。しかし、既に説明したとおり、本実施形態では、ネットワーク接続されている装置間に新たに論理的な接続を構築できる。そのため、パブリッシャ２０（ｐｕｂ１）は、必要に応じてノードＡと接続を構築し、その接続を使用して、ノードＡにイベントをパブリッシュすることが出来る。イベントを受け取ったノードＡは、イベントの転送経路の情報に沿ってイベントを転送する（図１０の経路（３））。イベントを受け取った各ノード（ノードＡ，ノードＣ，ノードＦ）は、アプリケーション４０（ａｐｐ１，…，ａｐｐ３０００）にイベントを通知する（図１０の経路（４））。なお、ノードＥは、アプリケーション４０が接続されていないため、アプリケーション４０に通知しない。
図５を参照したイベント配信装置１０の構成の説明に戻る。
購読要求制御部１０４は、メッセージ転送部１０１を介して、サブスクライバ３０からサブスクリプションの登録又は削除の指示を受け取り、購読要求保持部１０５が保存しているサブスクリプションを登録又は削除する。
なお、本実施形態では、購読要求制御部１０４が受信したサブスクリプションが、サブスクリプションの登録の指示であるとして説明するが、これに限られるわけではない。例えば、本実施形態は、予めサブスクリプション登録しておき、その後、サブスクリプションＩＤなどを別途登録指示として受信しても良い。また、本実施形態の説明では、サブスクリプションの削除の指示は、サブスクリプションのＩＤを含むものとして説明する。なお、イベント配信装置１０が受け取る削除の指示も、これに限られるわけではない。イベント配信装置１０は、削除指示として、サブスクリプションのＩＤではなく、サブスクリプション自体を受け取ってもよい。また、削除指示を受けた場合でも、サブスクリプション自体は削除せず保持したままとし、削除後の登録動作でサブスクリプションＩＤに基づく登録指示を受け付けても良い。
購読要求保持部１０５は、購読要求制御部１０４に制御されて、サブスクリプションを保持又は削除する。
図１１は、図３に示すサブスクリプションが購読要求保持部１０５に保持された場合の一例を示す図である。図１１に示すサブスクリプションは、サブスクリプションを区別するサブスクリプションＩＤと、一致判定に使用するイベントパターンと、イベントの通知先であるアプリケーション４０などを含む。
イベント受信転送部１０６は、メッセージ転送部１０１を介してパブリッシャ２０又は他のイベント配信装置１０などからイベントを受け取る。続いて、イベント受信転送部１０６は、受け取ったイベントを一致判定処理のため、一致判定部１０７に渡す。また、イベント受信転送部１０６は、経路情報保持部１０３が保持している転送経路情報に沿って、イベントを転送（ｆｏｒｗａｒｄ）する。（以下、この転送経路情報に沿って他のイベント配信装置１０に転送するイベントを「転送要求」と言う。）言い換えると、イベント受信転送部１０６は、経路情報保持部１０３が保持している転送経路情報を基に、イベントを転送するイベント配信装置１０を取得し、メッセージ転送部１０１を介してイベントを他のイベント配信装置１０に転送する。例えば、図８のノードＡのイベント受信転送部１０６は、図９の転送経路情報を基に、受け取ったイベントをノードＣとノードＥに転送する。
一致判定部１０７は、イベント受信転送部１０６から受け取ったイベントと購読要求保持部１０５に保持されているサブスクリプションとの一致を判定する。詳細に説明すると、一致判定部１０７は、受け取ったイベントと購読要求保持部１０５が保持しているサブスクリプションのイベントパターンとの一致を判定する。イベントとサブスクリプションのイベントパターンが一致した場合、一致判定部１０７は、受け取ったイベントをアプリケーション４０に通知するイベントと判定し、一致したイベントと通知先とを通知制御部１０８に渡す。
なお、この一致判定の結果として一致と判定されるサブスクリプションは、１つとは限らず、複数の場合もある。
通知制御部１０８は、所定の条件（以下、この条件を「通知条件」と言う。例えば、自装置の負荷状況など）を基に、一致判定部１０７から受け取ったイベントを、自装置で通知するか、他のイベント配信装置１０に通知を依頼するかを判定する。（この他のイベント配信装置１０にイベントの通知を依頼するメッセージ等を以下、「代理要求」と言う。この代理要求は、例えば、通知するイベントと、通知先などを含む。）自装置でイベントを通知する場合、通知制御部１０８は、イベント通知部１０９に、一致判定部１０７から受け取ったイベントと通知先とを渡し、イベントを通知する。
一方、他のイベント配信装置１０に代理要求を送信する場合、通知制御部１０８は、イベントなどを基に代理要求を作成し、メッセージ転送部１０１を介して、他のイベント配信装置１０に代理要求を送信する。
なお、本実施形態の通知制御部１０８における自装置で通知するか否かの通知条件は、予め通知制御部１０８に保存されているものとする。ただし、これは、説明の便宜のためであり、通知制御部１０８とは別に図示しない保持部などに通知条件を保持してもよい。
イベント通知部１０９は、通知制御部１０８、又は、後ほど説明する代理要求制御部１１０から受け取ったイベントと通知先とを基に、通知先のアプリケーション４０にイベントを通知する。
代理要求制御部１１０は、メッセージ転送部１０１を介して他のイベント配信装置１０からの「代理要求」を受け取る。さらに代理要求制御部１１０は、代理要求条件保持部１１１が保持している代理要求に含まれるイベントを通知するか否かの条件（以下、代理要求条件と言う）を基に、代理要求に含まれるイベントを自装置で通知するか、他のイベント配信装置１０にさらに代理を依頼するかを判定する。そして、代理要求制御部１１０は、自装置でイベントを通知すると判定した場合、受け取った代理要求に含まれるイベントと通知先とをイベント通知部１０９に渡し、イベントを通知する。また、他のイベント配信装置１０に依頼すると判定した場合、代理要求制御部１１０は、代理要求をそのまま、又は、必要に応じて修正し（例えば、後ほど詳細に説明するＴＴＬの修正など）、メッセージ転送部１０１を介して他のイベント配信装置１０に送信する。
代理要求条件保持部１１１は、予め他の装置又は管理者などに設定された、代理要求制御部１１０で使用する代理要求条件を保持している。
図１２は、第１の実施形態に係る代理要求条件の一例を示す図である。
図１２に示す代理要求条件は、代理要求を転送可能な残り回数であるＴＴＬ（Ｔｉｍｅ  Ｔｏ  Ｌｉｖｅ）と、代理要求に含まれるイベントを通知するか否かの判定に使用する装置の負荷条件の一例であるＣＰＵ利用率などを含む。なお、図１２に示す代理要求条件のＣＰＵ使用率は、代理要求を依頼する場合のＣＰＵ使用率の最小値を示している。つまり、例えば１行目の５０％は、ＣＰＵ使用率が５０％以上の場合、代理要求を依頼することを示している。また、図１２の代理要求条件の最後の行の「ＴＴＬ＝０、（転送不可）」とは、ＴＴＬ＝０、つまり転送してはいけない代理要求の場合、どのようなＣＰＵ使用率でも、代理要求制御部１１０は、自装置でのイベントを通知することを示している。
なお、図１２ではＣＰＵ使用率を使用しているが、他の負荷条件を使用しても勿論良い。また、代理要求条件は、判定の方式などに基づき、保持するデータが当然異なってくる。例えば、代理要求条件は、処理負荷の条件として、上限値を保持してもよく、逆に、下限値を保持してもよい。また、代理要求条件は、範囲を示すデータを保持してもよい。
なお、第１の実施形態に係るイベント配信装置１０において、外部と接続する構成として、メッセージ転送部１０１とイベント通知部１０９を別構成としているが、これはあくまで説明の便宜のためである。本実施形態に係るイベント配信装置１０は、メッセージ転送部１０１とイベント通知部１０９とを別構成とせず、ひとつの構成としてもよい。また、イベント通知部１０９も、通知制御部１０８などと同様に、メッセージ転送部１０１を介してイベントを通知してもよい。さらに、本実施形態に係るイベント配信装置１０は、メッセージ転送部１０１を、２つ以上の構成、例えば、イベントとイベント以外のメッセージとを送受信するように分けてもよい。さらに、イベント配信装置１０は、経路制御部１０２、購読要求制御部１０４、イベント受信転送部１０６、通知制御部１０８、代理要求制御部１１０ごとにメッセージ転送部１０１を備えてよい。さらに、各部がメッセージ転送部１０１の機能を取り込んでもよい。
また、本実施形態に係るイベント配信装置１０のイベント通知部１０９も、１つである必要はない。例えば、通知制御部１０８と代理要求制御部１１０とが、それぞれイベント通知部１０９を備えていてもよく、それぞれがイベント通知部１０９の機能を取り込んでもよい。
次に、イベント配信装置１０の動作について図面を参照して詳細に説明する。
まず、メッセージ転送部１０１の動作を図１３−図１４を参照して説明する。
図１３及び図１４は、第１の実施形態に係るメッセージ転送部１０１の動作の一例を示すフローチャート図である。
図１３と図１４とは、共にメッセージ転送部１０１の一連の動作を示しているが、図１３は、メッセージ転送部１０１の動作のうち、主として、自装置から他の装置にメッセージを送り出す動作に関連するフローチャート図となっている。
まず、メッセージ転送部１０１は、メッセージを受け取る（ステップ１３００）。このメッセージは、以下で説明するように自装置内の各部及び外部の各装置などからメッセージ転送部１０１に送られてくる。
続いて、メッセージ転送部１０１は、受け取ったメッセージの種類などを判定し、メッセージの種類などに基づいて処理を選択し、メッセージを送信する。なお、以下で説明する図１３−１４に示しているメッセージの判定の順番は、説明の便宜のためであり、順番が入れ替わってもよい。
まず、メッセージ転送部１０１は、メッセージが他のイベント配信装置１０に転送する転送要求か否かを判定する（ステップ１３０１）。なお、既に説明しているが、他のイベント配信装置１０への転送要求とは、イベントを転送経路情報に沿って他のイベント配信装置１０に転送するためのメッセージである。そのため、転送要求は、イベント受信転送部１０６からメッセージ転送部１０１に渡される。転送要求と判定したメッセージ転送部１０１は、他のイベント配信装置１０に転送要求を転送する（ステップ１３２１）。
転送要求ではないと判定したメッセージ転送部１０１は、他のイベント配信装置１０への代理要求のメッセージか否かを判定する（ステップ１３０２）。代理要求は、既に説明したとおり、他のイベント配信装置１０にイベント通知を依頼するメッセージであり、通知制御部１０８、又は、代理要求制御部１１０からメッセージ転送部１０１に渡される。代理要求と判定したメッセージ転送部１０１は、他のイベント配信装置１０に代理要求を送信する（ステップ１３２２）。
代理要求でもないと判定したメッセージ転送部１０１は、他の装置への登録要求又は離脱要求か否かを判定する（ステップ１３０３）。後ほど、さらに説明するが、登録要求及び離脱要求は、イベント配信装置１０の転送経路への参加又は離脱を要求するメッセージであり、経路制御部１０２からメッセージ転送部１０１に渡される。他のイベント配信装置１０への登録要求又は離脱要求と判定したメッセージ転送部１０１は、他のイベント配信装置１０に登録要求又は離脱要求を送信する（ステップ１３２３）。
さらに図１４を参照して、メッセージ転送部１０１の動作の説明を続ける。図１４は、図１３の処理に続く処理である。ただし、図１３とは異なり、主として他の装置から受け取るメッセージの処理に関するフローチャート図である。
他のイベント配信装置１０への登録要求又は離脱要求でないと判定したメッセージ転送部１０１は、サブスクライバ３０から受け取ったサブスクリプションの関するメッセージか否かを判定する（ステップ１３０４）。なお、ここでのサブスクリプションに関するメッセージとは、サブスクリプションの登録要求（サブスクリプションを含む）、サブスクリプションの削除要求（削除要求のためのサブスクリプションＩＤを含む）などのどれか一部を含むメッセージのことである。サブスクリプションに関するメッセージと判定したメッセージ転送部１０１は、サブスクリプションに関するメッセージを購読要求制御部１０４に渡す（ステップ１３２４）。
サブスクリプションではないと判定したメッセージ転送部１０１は、パブリッシャ２０からのイベントか否かを判定する（ステップ１３０５）。イベントと判定したメッセージ転送部１０１は、受け取ったイベントをイベント受信転送部１０６に渡す（ステップ１３２５）。
イベントではないと判定したメッセージ転送部１０１は、他のイベント配信装置１０から受け取った転送要求か否かを判定する（ステップ１３０６）。転送要求と判定したメッセージ転送部１０１は、転送要求をイベント受信転送部１０６に渡す（ステップ１３２６）。
他のイベント配信装置１０からの転送要求でもないと判定したメッセージ転送部１０１は、他のイベント配信装置１０からの代理要求か否かを判定する（ステップ１３０７）。他のイベント配信装置１０からの代理要求と判定したメッセージ転送部１０１は、代理要求を代理要求制御部１１０に渡す（ステップ１３２７）。
他のイベント配信装置１０からの代理要求でもないと判定したメッセージ転送部１０１は、他のイベント配信装置１０からの登録要求又は離脱要求か否かを判定する（ステップ１３０８）。他のイベント配信装置１０からの登録要求又は離脱要求と判定したメッセージ転送部１０１は、登録要求又は離脱要求を経路制御部１０２に渡す（ステップ１３２８）。
他のイベント配信装置１０からの登録要求又は離脱要求でもないと判定したメッセージ転送部１０１は、本実施形態の説明では処理を終了する。なお、本実施形態では、説明しないが、メッセージ転送部１０１は、ステップ１３０８でｎｏと判定した後、他の動作を処理しても良い。さらにメッセージ転送部１０１は、他のメッセージか否かを判定し、他のメッセージの沿った処理、例えば、網構成情報の変更を処理してもよく、さらに、判定不能な不正なメッセージとしてエラー処理を開始してもよい。
なお、ここまでの図１３−図１４を用いた動作の説明において、メッセージ転送部１０１は、メッセージを基にメッセージの種類を判定するように説明したが、メッセージの送信元など別の情報を基に判定してもよい。
次に、サブスクリプションに登録又は削除の動作について図１５−図１６を参照して説明する。
最初に、サブスクリプションの登録動作について説明する。
図１５は、購読要求制御部１０４におけるサブスクリプションの登録動作の一例を示すフローチャート図である。
メッセージ転送部１０１から受け取ったメッセージがサブスクリプションの登録要求に関するメッセージの場合、購読要求制御部１０４は、サブスクリプションを登録する。なお、ここでサブスクリプションの登録要求に関するメッセージは、例えば、図３に示したようなサブスクリプション登録指示としてのサブスクリプションなどを含む。
サブスクリプションの登録に関するメッセージを受けた購読要求制御部１０４（ステップ１５０１）は、受け取ったサブスクリプションに含まれるイベントパターンに含まれる「タイプ」を取得する（ステップ１５０２）。続いて、購読要求制御部１０４は、そのタイプが購読要求保持部１０５に格納されているサブスクリプションの中に存在するか否かを確認する（ステップ１５０３）。
そのタイプが、購読要求保持部１０５に格納されているサブスクリプションの中に存在しない場合、イベント配信装置１０は、そのタイプの転送経路に登録されていない。そのため、その場合、購読要求制御部１０４は、そのタイプの転送経路に自装置を参加させるために、経路制御部１０２に、受け取ったサブスクリプションのタイプを渡して、転送経路への登録要求を依頼する（ステップ１５０４）。経路制御部１０２から経路参加の完了を受け取った購読要求制御部１０４は、受け取ったサブスクリプションを購読要求保持部１０５に登録する（ステップ１５０５）。
受け取ったサブスクリプションのタイプが既に購読要求保持部１０５に登録済みの場合、すなわち、自装置が既にそのタイプの転送経路を構成する装置である場合、購読要求制御部１０４は、経路制御部１０２に依頼しないで、サブスクリプションを購読要求保持部１０５に登録する（ステップ１５０５）。
なお、経路制御部１０２の動作については、後ほど詳細に説明する。
次に、サブスクリプションの削除動作について説明する。
図１６は、購読要求制御部１０４における、サブスクリプションの削除の動作の一例を示すフローチャート図である。
メッセージ転送部１０１から受け取ったメッセージがサブスクリプションの削除要求に関するメッセージであった場合、購読要求制御部１０４は、サブスクリプションを削除する。なお、ここでのサブスクリプションの削除要求に関するメッセージは、例えば、削除対象のサブスクリプションのサブスクリプションＩＤなどを含む。
サブスクリプションの削除に関するメッセージを受けた購読要求制御部１０４（ステップ１６０１）は、受け取ったサブスクリプションＩＤに対応するサブスクリプションのイベントパターンのタイプを取得する（ステップ１６０２）。なお、購読要求制御部１０４は、購読要求保持部１０５が保持しているサブスクリプションのサブスクリプションＩＤと受け取ったサブスクリプションＩＤを比較に基づき、指定されたサブスクリプションを取得する。さらに、購読要求制御部１０４は、購読要求保持部１０５に、そのタイプを持つ他のサブスクリプションがあるか否かを確認する（ステップ１６０３）。
そのタイプを持つ他のサブスクリプションがなかった場合、イベント配信装置１０は、要求されたサブスクリプションを削除することにともない、自装置がそのタイプの転送経路に所属している必要がなくなる。そのため、購読要求制御部１０４は、そのタイプの転送経路から自装置を離脱させるために、経路制御部１０２に、そのタイプの転送経路からの離脱要求を依頼する（ステップ１６０４）。経路制御部１０２における離脱の完了を受けて、購読要求制御部１０４は、購読要求保持部１０５から削除要求の対象となるサブスクリプションを削除する（ステップ１６０５）。
この場合の経路制御部１０２の動作についても後ほど説明する。
そのタイプの他のサブスクリプションがある場合、イベント配信装置１０は、削除対象のサブスクリプションを削除しても、そのタイプの転送経路を構成している。この場合、購読要求制御部１０４は、経路制御部１０２に依頼せず、削除要求されているサブスクリプションを購読要求保持部１０５から削除する（ステップ１６０５）。
次に、イベントの転送経路への参加動作及び離脱動作について図１７−図２０を参照して説明する。
なお、参加動作などは、自装置が参加する動作と、他の装置から依頼を受けて参加させる動作との２種類がある。従って、それぞれについて順番に説明する。
また、自装置が参加する場合の説明では、既に説明した購読要求制御部１０４からの依頼（ステップ１５０４）を契機とした動作について説明するが、転送経路のへの登録動作及び離脱動作は、それに限らず、例えば、システム管理者などの指示に基づき登録する場合もある。
まず、転送経路への自装置を参加させる動作について説明する。
図１７は、経路制御部１０２における転送経路へ自装置を参加させるための動作の一例を示すフローチャート図である。
購読要求制御部１０４から転送経路への参加を依頼された経路制御部１０２（ステップ１７０１）は、依頼を受けたタイプの転送経路に自装置を参加させる。この転送経路への参加動作は、一般的なネットワークへの参加動作と同様の動作でよい。その他、ここでは、例えば、非特許文献２に記載のＰａｓｔｒｙを使用する場合について説明する。まず、経路制御部１０２は、参加を依頼された転送経路のタイプにおけるアクセスポイント（アクセスポイントがない場合はアクセスポイントに最も近いノード（イベント配信装置１０））を選択する（ステップ１７０２）。経路制御部１０２は、その選択したノードに、参加要求（例えば、対象のタイプと、自装置を示す情報（例えば装置ＩＤ）などと、参加要求であるメッセージなど）を送信する（ステップ１７０３）。
経路制御部１０２は、参加を依頼後、必要に応じて実際に参加できたか否かを確認してもよい。また、購読要求制御部１０４から依頼されている場合は、経路制御部１０２は、購読要求制御部１０４に参加完了などを連絡する。
次に、転送経路からの自装置を離脱する動作について説明する。
図１８は、経路制御部１０２における自装置を転送経路から離脱する動作の一例を示すフローチャート図である。
離脱要求を受けた場合の（ステップ１８０１）、経路制御部１０２は、一般的なネットワークからの離脱動作と同様に動作すればよい。例えば、経路制御部１０２は、経路情報保持部１０３の転送経路情報を用いて、指定されたタイプからの離脱要求を送信するノード（例えば他のイベント配信装置１０）を１つ選択する（ステップ１８０２）。選択後、経路制御部１０２は、メッセージ転送部１０１を介して選択したノードに離脱要求を送信する（ステップ１８０３）。この離脱要求は、対象となるタイプと、自装置の情報（装置ＩＤなど）とを含む。
また、経路制御部１０２は、参加要求と同様に、離脱依頼後、必要に応じて実際に離脱できたか否かを確認してもよい。また、購読要求制御部１０４から依頼されている場合は、経路制御部１０２は、購読要求制御部１０４に離脱完了を連絡する。
次に、他の装置から参加要求を受けた場合の動作について説明する。
図１９は、他のイベント配信装置１０から、転送経路に参加する要求を受けた場合の経路制御部１０２の動作の一例を示すフローチャート図である。
経路制御部１０２は、他イベント配信装置１０から転送経路への参加要求を受信した場合（ステップ１９０１）、自装置の経路情報保持部１０３の転送経路情報に、受信した参加要求のタイプの転送経路があるか否かを確認する（ステップ１９０２）。
受信した参加要求のタイプの転送経路が転送経路情報にない場合、経路制御部１０２は、さらに、購読要求保持部１０５にそのタイプを持つサブスクリプションが登録されているか否かを確認する（ステップ１９０３）。
購読要求保持部１０５にそのタイプを持つサブスクリプションが登録されていない場合、経路制御部１０２は、網構成装置情報から、そのタイプの転送経路への参加要求を送信するためのイベント配信装置１０を所定の処理を用いて１つ選択する（ステップ１９０４）。選択後、経路制御部１０２は、選択したイベント配信装置１０にメッセージ転送部１０１を介して参加要求を送信する（ステップ１９０５）。なお、参加要求は、参加対象のイベントのタイプ、自装置を示す情報（例えば装置ＩＤ）などを含む。送信後、経路制御部１０２は、経路情報保持部１０３に、対象となっているタイプの転送経路情報を作成する（ステップ１９０６）。さらに、経路制御部１０２は、参加要求を送信してきたイベント配信装置１０を示す情報（例えば装置ＩＤ）を転送経路情報に追加する（ステップ１９０７）。
購読要求保持部１０５にそのタイプを持つサブスクリプションが登録されている場合、（すなわち、例えば、イベントの転送経路が木構造なら、自装置が転送経路情報に基づいて構築されるイベントの転送の木構造の葉となる場合）、経路制御部１０２は、経路情報保持部１０３にそのタイプの転送経路情報を作成する（ステップ１９０６）。そして、経路制御部１０２は、経路情報保持部１０３の転送経路情報に、転送経路情報に参加要求を送信してきたイベント配信装置１０を示す情報（例えば装置ＩＤ）を追加する（ステップ１９０７）。
また、受信したタイプの転送経路情報がある場合、経路制御部１０２は、転送経路情報に、参加要求を送信してきたイベント配信装置１０を示す情報（例えば装置ＩＤ）を追加する（ステップ１９０７）。
続いて、他のイベント配信装置１０から離脱要求を受けた場合の動作について説明する。
図２０は、離脱要求を受け取った経路制御部１０２の動作の一例を示すフローチャート図である。
他のイベント配信装置１０から離脱要求を受信した場合（ステップ２００１）、経路制御部１０２は、経路情報保持部１０３に保持されている転送経路情報に、依頼元以外のイベント配信装置１０が登録されているか否かを確認する（ステップ２００２）。
そのタイプの転送経路情報に受信したイベント配信装置１０の装置以外の装置の登録がない場合、経路制御部１０２は、購読要求保持部１０５に対象のタイプを持つサブスクリプションが登録されているか否かを確認する（ステップ２００３）。
購読要求保持部１０５にそのタイプを持つサブスクリプションが登録されていない場合、経路制御部１０２は、経路情報保持部１０３の網構成装置情報から、そのタイプの転送経路からの離脱要求を送信するイベント配信装置１０を所定の処理を用いて１つ選択する（ステップ２００４）。選択後、経路制御部１０２は、メッセージ転送部１０１を介して、選択したイベント配信装置１０に離脱要求を送信する（ステップ２００５）。メッセージ転送部１０１を介して離脱要求を送信後、経路制御部１０２は、そのタイプの転送経路情報を削除する（ステップ２００６）。
購読要求保持部１０５にそのタイプを持つサブスクリプションが登録されている場合、経路制御部１０２は、そのタイプの転送経路情報を削除する（ステップ２００６）。
経路情報保持部１０３が保持している受信したタイプの転送経路情報に、受信したイベント配信装置１０の装置以外の装置が登録されている場合、経路制御部１０２は、そのタイプの転送経路情報から受信したイベント配信装置１０の装置情報を削除する（ステップ２００７）。
続いて、イベントを受けた場合の動作について図２１−２４などを参照して詳細に説明する。
まず、パブリッシャ２０からイベント受け取ったイベント受信転送部１０６の動作について図面を参照して説明する。
図２１は、イベント受信転送部１０６がイベントを受けたときの処理の一例を示すフローチャート図である。
パブリッシャ２０からメッセージ転送部１０１を介してイベントを受け取ったイベント受信転送部１０６は（ステップ２１０１）、一致判定部１０７にイベントを渡す（ステップ２１０２）。
次に、イベント受信転送部１０６は、イベントのタイプを取得する（ステップ２１０３）。イベント受信転送部１０６は、そのタイプの転送経路情報が経路情報保持部１０３にあるか否かを確認する（ステップ２１０４）。そのタイプの転送経路情報が存在する場合、イベント受信転送部１０６は、転送経路情報を参照して、イベントを転送する装置を判定する。例えば、転送経路情報が木構造の場合、この判定は、自装置に対して子となるイベント配信装置１０を求めることである。そして、イベント受信転送部１０６は、メッセージ転送部１０１を介して、転送先のイベント配信装置１０に、受け取ったイベントの「転送要求」を転送する（ステップ２１０６）。なお、転送する転送要求には、例えば、イベントと、転送先イベント配信装置１０の装置情報（例えば装置ＩＤなど）とを含んでもよい。イベント受信転送部１０６は、転送経路情報に子として登録されている全てのイベント配信装置１０に対して転送要求を転送する（ステップ２１０５）。
一方、そのタイプの転送経路情報が存在しない、又は、転送経路情報に転送する装置の登録がない場合、イベント受信転送部１０６は、処理を終了する。
この動作をさらに具体的に図８を参照して動作を説明する。
例えば、図８のノードＡのイベント受信転送部１０６が、図１に示すＥｖｅｎｔ１（タイプ＝“衝撃”、センサＩＤ＝“ＩＤ１”、衝撃データ＝“５０”、場所＝“東京都港区”、時刻＝“１０：１０：２５”）を受信したとする（ステップ２１０１）。イベント受信転送部１０６は、そのイベント（Ｅｖｅｎｔ１）を一致判定部１０７に渡す（ステップ２１０２）。次に、イベント受信転送部１０６は、そのイベントからイベントのタイプ「衝撃」を取得し（ステップ２１０３）、ノードＡの経路情報保持部１０３に保持されているタイプ「衝撃」の転送経路情報が存在するか否かを判定する。ここで図９がタイプ「衝撃」の転送経路情報とする。ノードＡの転送経路情報にタイプ「衝撃」に転送先の子となるノードが存在するので、イベント受信転送部１０６は、そのタイプの転送経路情報の各ノード（図９のノードＣとノードＥ）に対して、メッセージ転送部１０１を介してイベントの転送要求を転送する（ステップ２１０６）。
次に、一致判定部１０７の動作について図面を参照して説明する。
図２２は、一致判定部１０７における一致判定処理の一例を示すフローチャート図である。
イベントを受け取った一致判定部１０７は（ステップ２２０１）、イベントと購読要求保持部１０５に保持されているサブスクリプションのイベントパターンとの一致を判定する（ステップ２２０３）。一致判定の結果、イベントがサブスクリプションに一致した場合、一致判定部１０７は、一致したサブスクリプションの通知先とイベントとを通知制御部１０８に渡す（ステップ２２０４）。（なお、一致判定部１０７が、イベントとサブスクリプションとを通知制御部１０８に渡し、通知制御部１０８が通知先を取り出してもよい。）イベントがサブスクリプションと一致しない場合、一致判定部１０７は、次のサブスクリプションとの一致を判定する。一致判定部１０７は、全てのサブスクリプションについてこの動作を繰り返す（ステップ２２０２）。
さらに具体的に説明すると、例えば、図１０のノードＡの一致判定部１０７が、図１に示すＥｖｅｔ１（タイプ＝“衝撃”、センサＩＤ＝“ＩＤ１”、衝撃データ＝“５０”、場所＝“東京都港区”、時刻＝“１０：１０：２５”）を受信したとする（ステップ２２０１）。このとき、一致判定部１０７は、購読要求保持部１０５に保持されているサブスクリプションとイベントとの一致を判定する（ステップ２２０３）。ここで、図１１に示すサブスクリプションが購読要求保持部１０５に保持されていたとする。図１１の１行目のサブスクリプションが、イベント（Ｅｖｅｎｔ１）と一致するので、一致判定部１０７は、サブスクリプションの通知先（ａｐｐ１など）と、イベント（タイプ＝“衝撃”、センサＩＤ＝“ＩＤ１”など）を通知制御部１０８に渡す（ステップ２２０４）。一致判定部１０７は、この処理を全てのサブスクリプションに対して実施する（ステップ２２０２）。
続いて、通知制御部１０８の動作について図面を参照して説明する。
図２３は、通知制御部１０８における、イベントの通知処理の一例を示すフローチャート図である。
一致判定部１０７からイベントと通知先とを受け取った通知制御部１０８は（ステップ２３０１）、自装置の負荷状態を取得する。この動作は、例えば、通知制御部１０８が、図示しないモニタ部などから自装置の負荷の一例であるＣＰＵ使用率などを取得する動作である。次に、通知制御部１０８は、現在の装置の負荷と、通知制御部１０８などに予め設定されている通知条件、例えば負荷の閾値とを比較する（ステップ２３０２）。
自装置の負荷が通知条件である閾値より大きい、つまり負荷が重い場合（ステップ２３０２でｙｅｓ）、イベント配信装置１０は、自装置では所定の時間内でイベントを通知することができない。そのため、通知制御部１０８は、他のイベント配信装置１０にそのイベントの通知の代理要求を送信する。そこで、通知制御部１０８は、経路情報保持部１０３に保持されている網構成装置情報から代理要求を送信するイベント配信装置１０を後ほど説明する処理を用いて１つ選択する（ステップ２３０３）。選択後、通知制御部１０８は、選択したイベント配信装置１０に送る代理要求を作成し、メッセージ転送部１０１を介して選択したイベント配信装置１０に代理要求を送信する（ステップ２３０４）。なお、この代理要求は、一致判定部１０７から受け取ったイベントと通知先とに加え、さらに予め通知制御部１０８に設定されている又はイベントのタイプなどから通知制御部１０８が決めるＴＴＬ（Ｔｉｍｅ  ｔｏ  Ｌｉｆｅ）を含む。
なお、通知制御部１０８におけるイベント配信装置１０の選択としては、いろいろな処理や方式を採用することが出来る。第１の実施形態に係る通知制御部１０８は、網構成装置情報から自装置以外のイベント配信装置１０をランダム（無作為）に選択している。しかし、これは、あくまで本実施の形態の選択の一例であり、通知制御部１０８は、他の処理を採用してもよい。例えば、通知制御部１０８は、経路情報保持部１０３に保持されている網構成装置情報に登録されているイベント配信装置１０を順番に選択してもよい。
一方、自装置の負荷が通知条件である閾値より小さい、つまり負荷が軽い場合、イベント配信装置１０は、自装置で所定の時間内にイベントを通知できる。そのため、通知制御部１０８は、自装置のイベント通知部１０９を用いてイベントを通知すると判定し、一致判定部１０７から受信したイベントと通知先とをイベント通知部１０９に渡す（ステップ２３０５）。
なお、ここまで、第１の実施形態に係る通知制御部１０８は、自装置の負荷状態を判定するための通知条件を、予め通知制御部１０８に設定されているとして説明した。しかし、後ほど詳細に説明する代理要求制御部１１０のように、通知制御部１０８は、通知条件を通知制御部１０８の外部に保持してもよい。
通知制御部１０８の動作について、具体的にデータの一例を使用して説明する。
説明の便宜のため、イベント配信装置１０を図１０のノードＡとして説明する。また、説明の便宜のため、通知条件の装置負荷として、ＣＰＵ使用率を使うこととし、閾値のＣＰＵ使用率を７０％とする。また、現在のノードＡのＣＰＵ使用率を８０％とする。また、ＴＴＬの初期値を「２」とする。
ノードＡの通知制御部１０８が、一致判定部１０７から、イベント（例えば図１のＥｖｅｎｔ１）とその通知先（ａｐｐ１，ａｐｐ２，ａｐｐ３，…，ａｐｐ１０００）とを受信したとする（ステップ２３０１）。通知制御部１０８は、ＣＰＵ使用率の閾値７０％と、自装置のＣＰＵ使用率を比較する（ステップ２３０２）。今、自装置のＣＰＵ使用率を８０％としているので、通知制御部１０８は、負荷が重いとして、代理要求を送信すると判定する（ステップ２３０２のｙｅｓ）。続いて、通知制御部１０８は、代理要求を送信するイベント配信装置１０を選択する。そのため、通知制御部１０８は、経路情報保持部１０３の網構成装置情報（例えば図７Ａ）からイベント配信装置１０（ノード）を１つランダムに選択する（ステップ２３０３）。ここでは、ノードＣが選ばれたとする。次に、通知制御部１０８は、メッセージ転送部１０１を介して、選択したノードＣに代理要求を送信する（ステップ２３０４）。なお、ここでの代理要求は、例えば、「Ｅｖｅｎｔ＝（タイプ＝“衝撃”、センサＩＤ＝“ＩＤ１”、衝撃データ＝“５０”、場所＝“東京都港区”、時刻＝“１０：１０：２５”）、送付先＝（ａｐｐ１，ａｐｐ２，ａｐｐ３，…，ａｐｐ１０００）、ＴＴＬ＝２」となる。
次に、イベント通知部１０９の動作について図面を参照して説明する。
図２４は、イベント通知部１０９におけるイベント通知処理の一例を示すフローチャート図である。
通知制御部１０８からイベントと通知先とを受け取ったイベント通知部１０９は（ステップ２４０１）、通知先に登録されているすべてのアプリケーション４０に対して（ステップ２４０２）、受信したイベントを通知する（ステップ２４０３）。
なお、他のイベント配信装置１０から転送要求としてイベントを受け取ったときの処理は、既に説明したパブリッシャ２０からイベントの受け取ったときの処理において、「イベント」を「転送要求」に変更すれば同様の処理となるため、動作の詳細な説明を省略する。
また、転送要求を受け取った転送先であるイベント配信装置１０も、「イベント」を「転送要求」に変更することで同様に動作できる。
続いて、代理要求を受けた場合の動作について図面を参照して説明する。
図２５は、代理要求制御部１１０の代理要求の処理の一例を示すフローチャート図である。
メッセージ転送部１０１を介してイベントの代理要求を受信した代理要求制御部１１０は（ステップ２５０１）、受け取った代理要求のＴＴＬに対応する代理要求条件保持部１１１に保持されている代理要求条件のＴＴＬに基づき装置負荷の条件を取得する（ステップ２５０２）。次に、代理要求制御部１１０は、図示しないモニタ部などから自装置の負荷状態を取得し、先ほど取得した代理要求条件の負荷条件と比較する（ステップ２５０３）。
もし、自装置のそのときの負荷が、代理要求条件の負荷条件より重い場合、代理要求制御部１１０は、他のイベント配信装置１０にイベントの通知の代理を依頼すると判定する。そして、代理要求制御部１１０は、代理要求を送信する装置を所定の方式で選択する（ステップ２５０４）。この選択は、例えば、代理要求制御部１１０が、経路情報保持部１０３の網構成装置情報からランダムにイベント配信装置１０を１つ選択する。選択後、代理要求制御部１１０は、メッセージ転送部１０１を介して、選択したイベント配信装置１０に代理要求を送信する（ステップ２５０５）。なお、第１の実施形態では、代理要求が転送の可能回数を示すＴＴＬを備えている。そのため、代理要求制御部１１０は、受け取った代理要求のＴＴＬを修正し、その修正後のＴＴＬを含む代理要求を送信する。ここでの代理要求制御部１１０の修正は、例えば、代理要求が１台の装置を経由するため、単純にＴＴＬの回数を１回分減らすことが想定される。また、イベントのタイプ、又は、イベント配信装置１０が代理要求処理に必要とした処理時間に従って、ＴＴＬの値を２以上削減するなど、代理要求制御部１１０は、代理要求を受け付けた装置でＴＴＬを使用して判断する場合に適切な値にＴＴＬを修正してもよい。一方、代理要求制御部１１０の処理に掛かった時間が通知までの時間に影響が少ない（例えば無条件で代理要求を転送した場合）など特段の条件がある場合、代理要求制御部１１０は、ＴＴＬを変更しなくてもよい。
一方、自装置の負荷が代理要求条件より軽い場合、代理要求制御部１１０は、自装置でイベントを通知すると判定する。そして、代理要求制御部１１０は、代理要求で指定されたイベントと通知先とをイベント通知部１０９に渡し（ステップ２５０６）、イベントを通知する。
代理要求制御部１１０からイベントと通知先とを受け取ったイベント通知部１０９の動作は、通知制御部１０８からイベントと通知先とを受けたときと同様のため、詳細な説明は省略する。
この代理要求を受けた場合の動作について、具体的に説明すると次のようなる。
例えば、図１０のノードＣの代理要求制御部１１０が、メッセージ転送部１０１を介し、ノードＡから代理要求を受信したとする（ステップ２５０１）。この場合の代理要求として、先に説明したノードＡが送信した代理要求とする。つまり、代理要求は、「Ｅｖｅｎｔ＝（タイプ＝“衝撃”、センサＩＤ＝“ＩＤ１”、衝撃データ＝“５０”、場所＝“東京都港区”、時刻＝“１０：１０：２５”）、送付先＝（ａｐｐ１，ａｐｐ２，ａｐｐ３，…，ａｐｐ１０００）、ＴＴＬ＝２」を用いて説明する。ノードＣの代理要求制御部１１０は、代理要求のＴＴＬを取得する。（この場合、ＴＴＬ＝２となる。）次に、ノードＣの代理要求制御部１１０は、代理要求条件保持部１１１の代理要求条件（これは図１２とする）のＴＴＬ＝２のＣＰＵ使用率を取得する（ステップ２５０２）。この場合、ＣＰＵ使用率は６０％である。つまり、自装置のＣＰＵ使用率が６０％以上の場合は、自装置の負荷が重いとして代理要求を通知する。次に、ノードＣの代理要求制御部１１０は、自装置の負荷状態と代理要求条件とを比較する（ステップ２５０３）。いま、仮にノードＣのＣＰＵの使用率が７０％とする。ノードＣの代理要求制御部１１０は、自装置の負荷が代理要求条件より重いため、代理要求を送信すると判定する。次に、ノードＣの代理要求制御部１１０は、転送先として経路情報保持部１０３の網構成装置情報から、例えば、ランダムにイベント配信装置１０を選択する（ステップ２５０４）。ここでは、ノードＤを選択したとして説明を続ける。ノードＣの代理要求制御部１１０は、ノードＡから受信した代理要求のＴＴＬの値「２」を１つ減らした（デクリメントした）代理要求を作成し、メッセージ転送部１０１を介し、ノードＤに送信する（ステップ２５０５）。この場合の代理要求は、「Ｅｖｅｎｔ＝（タイプ＝“衝撃”、センサＩＤ＝“ＩＤ１”、衝撃データ＝“５０”、場所＝“東京都港区”、時刻＝“１０：１０：２５”）、通知先＝（ａｐｐ１，ａｐｐ２，ａｐｐ３，…，ａｐｐ１０００）、ＴＴＬ＝１」となる。
ノードＣから代理要求を受け取ったノードＤの代理要求制御部１１０は（ステップ２５０１）、代理要求のＴＴＬを取得する。ここで受け取る代理要求は、既に説明した「Ｅｖｅｎｔ＝（タイプ＝“衝撃”、センサＩＤ＝“ＩＤ１”、衝撃データ＝“５０”、場所＝“東京都港区”、時刻＝“１０：１０：２５”）、通知先＝（ａｐｐ１，ａｐｐ２，ａｐｐ３，…，ａｐｐ１０００）、ＴＴＬ＝１」である。次に、代理要求制御部１１０は、ＴＴＬ＝１に対応する代理要求条件のＣＰＵ使用率を取得する（図１２の場合、ＣＰＵ使用率＝８０％）。代理要求制御部１１０は、このＣＰＵ使用率と自装置ＣＰＵ使用率を比較する（ステップ２５０３）。ここで、例えば、ノードＤのＣＰＵ使用率が７０％であったとする。ノードＤの代理要求制御部１１０は、自装置ＣＰＵ使用率（７０％）が代理要求条件のＣＰＵ使用率（８０％）より軽いため、自装置でイベントを通知すると判定する。そして、ノードＤの代理要求制御部１１０は、代理要求のイベントと通知先とをイベント通知部１０９に渡し（ステップ２５０６）、イベントを通知する。
なお、図１０では、ノードＤからアプリケーション４０（ａｐｐ１，ａｐｐ２，…，ａｐｐ１０００）への接続経路が図示されていない。しかし、既に説明したとおり、ノードは、接続経路を新たに接続することが出来る。そのため、ノードＤから通知先のアプリケーション４０へのイベント通知においても、ノードＤは、アプリケーション４０と新たに接続を構築してイベントを通知する。
このような動作に基づき、あるイベント配信装置１０（上の説明ではノードＡ）の負荷が重く、自装置では所定の時間でイベントを通知できない場合でも、他の通知化可能な負荷状態のイベント配信装置１０（上の説明ではノードＤ）まで、順次イベントの代理要求が転送される。そして、イベント通知の条件を満たすイベント配信装置１０（上の説明ではノードＤ）が、イベントを通知先のアプリケーション４０に通知する。
なお、本実施形態の説明では、まずＴＴＬを比較する処理としているが、本実施形態の係るイベント配信装置１０は、ＣＰＵ使用率など負荷状態から比較しても勿論良い。
また、本実施形態に説明において、イベント配信装置１０の処理の負荷の要因としては、アプリケーション４０にイベントを通知する処理及び他のイベント配信装置１０にイベントを転送する処理などが想定される。本実施形態は、そのどちらか、又は、両方から発生する負荷に対して適用出来る。さらに、本実施形態のイベント配信装置１０は、そのような要因だけでなく、他の要因から発生する負荷に対しても対応することが出来る。
ここまで説明してきた、図８などのイベント配信装置１０のイベントの転送経路は、サブスクリプションを基に構築した木構造の転送経路である。しかし、本発明が適用出来るイベントの転送経路は、これに限られるわけではなく、他の転送経路でもよい。
図２６は、イベント配信ＮＷ６０の別のイベントの転送経路の一例を示す図である。
図２６の転送経路において、イベント配信装置１０である各ノード（ノードＡ，…，ノードＦ）は、各イベントの通知を担当するように構成されている。例えば、ノードＡは、イベントのタイプ「衝撃」を担当し、タイプ「衝撃」のイベントを通知し、ノードＢは、イベントのタイプ「開閉」を担当し、タイプ「開閉」のイベントを通知する。なお、異なるタイプでも、通知先のアプリケーション４０が同じ場合もあるため、異なるノードが同じアプリケーション４０に接続する場合もあるが、図２６では説明の便宜のため、各ノードは、それぞれ別のアプリケーション４０に接続する例を示している。
このように構成された図２６の示すイベント配信ＮＷ６０の動作についてさらに説明する。
なお、サブスクリプションの登録、イベントの転送、代理要求の送信などは、既に説明したイベント配信ＮＷ５０の動作と同様のため、詳細な説明は省略し、図２６に示すイベント配信ＮＷ６０において、イベント配信ＮＷ５０と異なる動作について詳細に説明する。
イベント配信ＮＷ６０における転送経路情報は、各イベントの担当となるノードの情報を保持している。
図２７は、イベント配信ＮＷ６０における転送経路情報の一例を示す図である。図２７において、例えば、イベントのタイプ「衝撃」は、ノードＡが担当となっていることを示している。
また、イベント配信装置１０（ノード）は、自装置が通知を担当するイベントを判定する情報として、図２７の転送経路情報を使用することも出来る。つまり、イベントのタイプのノードＩＤが自ノードの場合、自装置がイベントの通知を担当していると判定することが出来る。
以下では、図２７に示すノードＡがイベントのタイプ「衝撃」を担当している場合について説明する。
図２６に示すノードＡに接続しているパブリッシャ２０（ｐｕｂ１）が、タイプ「衝撃」のイベントをパブリッシュした場合、ノードＡがそのイベントを受け取り、イベントのタイプから担当するノードを判定する。今の場合、ノードＡは、自装置が担当するイベントと判定する。ノードＡは、自装置担当のイベントのため、自装置でアプリケーション４０（ａｐｐ１，…，ａｐｐ１００）にイベントを通知する。
次に、ノードＡ以外のノードに接続しているパブリッシャ２０（例えばノードＥに接続しているｐｕｂ１０１）が、タイプ「衝撃」のイベントをパブリッシュした場合について説明する。イベントを受けたノードＥは、転送経路情報を基にイベントのタイプからイベントの担当のノードを判定する。この場合、ノードＥは、自装置の担当でないと判定する。さらに、自ノードの担当のイベントでないと判定したノードＥは、転送経路情報を基にイベントを担当するノードを判定し、そのノード（今の場合はノードＡ）にイベントを転送する。イベントの転送を受けたノードＡは、自装置が担当するイベントのため、アプリケーション４０（ａｐｐ１，…，ａｐｐ１００）にイベントを通知する。
ここで、イベントの大量発生などで、イベントの通知を担当するイベント配信装置１０（例えばノードＡ）の負荷が重くなった場合、イベント配信装置１０の通知制御部１０８は、既に説明したように代理要求を送信する。この代理要求を用いてイベント配信装置１０は、他のイベント配信装置１０にアプリケーション４０への通知の代理を依頼する。
このように動作する図２６に示したイベント配信ＮＷ６０におけるイベントの転送処理は、最大でも１回しか発生しない。つまり、イベント配信ＮＷ６０において、イベントの通知を担当しているノード（ノードＡ）がイベントを受け取った場合は、イベントの転送処理の必要が無い。また、その他のノード（例えばノードＥ）がイベントを受け取った場合は、イベントを受け取ったノードがイベントの通知担当のノード（ノードＡ）にイベントを転送する。そして、そのイベントを受け取ったイベントの通知担当のノードは、イベントを通知することが出来る。
一方、図８に示すイベント配信ＮＷ５０では、イベント毎に、転送経路情報に登録された全てのノードにイベントを転送する。（前に説明した例では、イベント配信ＮＷ５０のイベントの転送は、ノードＣ，ノードＥ，ノードＦへと転送を３回必要とした。）
このように、イベント配信ＮＷ６０は、イベント発生時の転送処理が、イベント配信ＮＷ５０と比べ、少なくすることが出来る。
ただし、イベント配信ＮＷ５０では、通常状態でも既に説明した木構造など複数イベント配信装置１０がイベントを通知している。そのため、イベントが大量発生しても、ある程度まではイベントの通知処理の負荷が複数のイベント配信装置１０の間で分散される。
一方、図２６に示すようなイベント配信ＮＷ６０は、通常、イベントを１つのイベント配信装置１０が通知するため、イベントの大量発生に基づくイベント配信装置１０での負荷の増大を引き起こしやすい。従って、図２６に示すイベント配信ＮＷ６０のように構成されたイベント配信装置１０は、本発明の効果を、さらに有効に享受することが出来る。
なお、第１の実施形態に係るイベント配信装置１０において、各構成を別構成として説明したが、これは説明の便宜のためである。これらの一部又は全体をまとめた構成としてもよい。例えば、本実施形態に係るイベント配信装置１０は、各保持部を１つの記憶装置で実現してもよく、２つ以上の制御部をまとめた制御部としてもよい。また、本実施形態に係るイベント配信装置１０は、プログラムに基づいて動作する１つ又は２つ以上のコンピュータとして実現してもよい。なお、プログラムは、図示しない１つ又は２つ以上の記憶媒体に格納される。
一方、第１の実施形態に係るイベント配信装置１０の各構成部を別装置として構成してもよい。
図２８は、第１の実施形態に係るイベント配信システム２の別の構成の一例を示すブロック図である。
図２８のイベント配信システム２において、図５と同じ構成には、同じ番号を付し、詳細な説明は省略し、図５と異なる構成について詳細に説明する。
図２８に示すイベント配信システム２は、図５のイベント配信装置１０と同様に、ネットワークなどで接続されたメッセージ転送装置７１と、経路制御装置７２と、購読要求制御装置７３と、通知制御装置７４と、代理要求制御装置７５と、イベント通知装置７６とを含む。
メッセージ転送装置７１は、図５に示すメッセージ転送部１０１と同様に動作し、イベント通知装置７６は、図５に示すイベント通知部１０９と同様に動作する。また、経路制御装置７２は、図５の経路制御部１０２と経路情報保持部１０３とを含む。購読要求制御装置７３は、図５の購読要求制御部１０４と購読要求保持部１０５とを含む。通知制御装置７４は、図５のイベント受信転送部１０６と一致判定部１０７と通知制御部１０８とを含む。代理要求制御装置７５は、図５の代理要求制御部１１０と代理要求条件保持部１１１とを含む。なお、図２８に示すイベント配信システム２は、各装置をそれぞれ１つ含むが、それぞれの装置を２台以上の含んでもよい。
このような構成に基づき、通知制御装置７４又は代理要求制御装置７５は、自装置の負荷が重く所定の時間でイベントを通知できない場合、図５に示したイベント配信装置１０と同様に他の装置などにイベントの通知の代理を依頼することが出来る。
また、本実施形態は、イベントの配信と代理要求の処理とをまとめた装置をイベント配信装置とすることも出来る。
図２９は、第１の実施形態に係るイベント配信装置の別の構成の一例を示すブロック図である。図２９において、図５と同じ構成は同じ番号を付してある。
イベント配信装置１１は、購読要求保持部１０５と通知制御部１０８と代理要求制御部１１０と代理要求条件保持部１１１と通知条件保持部１１２とを含む。
通知制御部１０８は、接続しているネットワークからイベントを受信し、購読要求保持部１０５が保持しているサブスクリプションと比較し、一致した場合に、イベントを通知する。ただし、通知制御部１０８は、通知条件保持部１１２が保持している通知条件を基に、自装置でイベントを通知するか、代理要求をネットワーク経由で他のイベント配信装置１１（既に説明したイベント配信装置１０などでもよい。）などに送信するかを判定して、イベントを通知又は代理要求を送信する。
代理要求制御部１１０は、既に説明したイベント配信装置１０の代理要求制御部１１０と同様に、代理要求を受けた場合、代理要求条件を基に、自装置で受け取った代理要求のイベントを通知するか、さらに他の装置に代理要求と送るかを判定して、イベントを通知又は代理要求を送信する。
このような、イベント配信装置１１は、自装置でイベントを通知するか、他の装置に代理要求を送信するかを自装置の負荷等に基づき切り替えることが出来る。
また、イベント配信装置１１を１つの装置ではなく、複数の装置として構成してもよい。
図３０は、イベント配信装置１１の通知制御部１０８を中心としたイベント配信装置１２の一例を示すブロック図である。イベント配信装置１２は、購読要求保持部１０５と、通知制御部１０８と、通知条件保持部１１２とを含む。イベント配信装置１２の各部の構成及び動作は、図２９に示すイベント配信装置１１の各部の構成及び動作と同様のため、それぞれ同じ番号を付し、詳細な説明は省略する。
図３１は、同様に、イベント配信装置１１の代理要求制御部１１０を中心としたイベント配信装置１３の一例を示すブロック図である。イベント配信装置１３は、代理要求制御部１１０と代理要求保持部１１１とを含む。イベント配信装置１３の各部の構成及び動作は、図２９に示すイベント配信装置１１の各部の構成及び動作と同様のため、同じ番号を付し、詳細な説明は省略する。
第１の実施形態に係るイベント配信装置１０（以下、イベント配信装置１１及びイベント配信システム２なども含む）は、自装置の負荷が重くなったときでも、所定の時間でアプリケーション４０にイベントを通知することが出来る効果を有する。
その理由は、イベントを通知するイベント配信装置１０の処理負荷が所定の閾値より重くなった場合、他のイベント配信装置１０にイベントの通知を代理要求として依頼し、負荷の軽い他のイベント配信装置１０にイベントの通知を依頼することが出来るためである。
さらに、第１の実施形態に係るイベント配信装置１０は、代理要求を受け取ったイベント配信装置１０の装置負荷が重い場合でも、所定の時間でアプリケーション４０にイベントを通知することが出来る効果を有する。
また、第１の実施形態に係るイベント配信装置１０は、イベントが突然大量に発生した場合でも、イベント発生からイベント通知までの時間を確保してイベントを通知することが出来る効果を有する。
その理由は、代理要求を受けた他のイベント配信装置１０においても、自装置の負荷と代理要求と代理要求条件とを基に、自装置の負荷が重い場合には、さらに他のイベント配信装置１０にイベント通知の代理を代理要求として送信することが出来るためである。
（第２の実施形態）
第１の実施形態に係るイベント配信装置１０の説明では、代理要求条件の一例として、イベント配信装置１０の負荷条件、具体的にはＣＰＵ使用率とＴＴＬとを用いた場合について説明した。しかし、既に説明したとおり、代理要求条件は、これに限られるわけではない。
例えば、アプリケーション４０とイベント配信装置１０とのネットワークの混雑状態、アプリケーション４０側の状態、又は、イベント通知部１０９の通信障害などに応じて、イベントがイベント通知部１０９に溜まる場合もある。つまり、イベント配信装置１０のＣＰＵ使用率などのイベント配信装置１０の負荷とは無関係に、イベントを所定の時間で通知できないことが発生する場合もある。
第２の実施形態に係るイベント配信装置１０は、代理要求条件として、イベント通知部１０９において蓄えられているイベントの量、すなわち、イベント通知部１０９がアプリケーション４０に通知するイベント数に相当する条件で判定する。なお、本実施形態の説明は、イベント数に相当する量の一例として、イベント通知部１０９のイベント保存用のバッファに蓄えられているデータ量を使用して説明する。
また、第２の実施形態に係るイベント配信装置１０の構成及び動作は、通知制御部１０８と、代理要求制御部１１０と、代理要求条件保持部１１１とを除き、第１の実施形態に係るイベント配信装置１０と同じである。そのため、同じ構成と動作に関する詳細な説明は省略し、第２の実施形態に係るイベント配信装置１０に特有の部分を中心に詳細に説明する。
第２の実施形態に係る通知制御部１０８は、通知条件として、予めイベント通知部１０９のバッファ量に対する「バッファ閾値」を保存している。また、第２の実施形態に係る代理要求条件保持部１１１も、同様に、保存されている条件としてバッファ量とＴＴＬとなっている。そのため、代理要求制御部１１０も、同様に、イベント通知部１０９のバッファ量を使用して判定する。
このように構成されているイベント配信装置１０の動作をついてさらに説明する。
第２の実施形態に係る通知制御部１０８は、第１の実施形態に係る通知制御部１０８におけるＣＰＵ使用率を使用した判定（図２３のステップ２３０２に相当）をイベント通知部１０９のバッファ量を使用して判定する。さらに詳細に説明すると、通知制御部１０８は、第１の実施形態において図示しないモニタ部などから自装置のＣＰＵ使用率を取得する代わりに、イベント通知部１０９から使用中のバッファ量を受け取る。そして、通知制御部１０８は、受け取ったバッファ量と通知条件として保持しているバッファ量の閾値とを比較し、閾値より使用中のバッファ量が多い場合は、自装置の負荷が重いと判定して、受け取ったイベントを代理要求として、他のイベント配信装置１０に送る。それ以外の処理は、第１の実施形態に係る通知制御部１０８と同様である。
第２の実施形態に係る代理要求制御部１１０も、第１の実施形態に係る代理要求制御部１１０におけるＣＰＵ使用率を使用した判定（図２５のステップ２５０３に相当）の代わりに、イベント通知部１０９のバッファ量を使用して判定する。さらに詳細に説明すると、代理要求を受け取った代理要求制御部１１０は、代理要求条件保持部１１１から、代理要求条件を取得する。そして、代理要求制御部１１０は、代理要求のＴＴＬに対応する代理要求条件のバッファ量を取得する。さらに、代理要求制御部１１０は、イベント通知部１０９から現在のバッファ量を取得する。代理要求制御部１１０は、イベント通知部１０９のバッファ量と代理要求条件のバッファ量の閾値とを比較する。イベント通知部１０９のバッファ量が少ない場合は、代理要求制御部１１０は、自装置でイベントを通知すると判定する。以降のイベントの通知処理は、第１の実施形態と同じため、詳細な説明は省略する。一方、バッファ量が閾値より多い場合は、代理要求制御部１１０は、自装置負荷が重いため代理要求を送信すると判定する。この判定後の動作も第１の実施形態と同様のため、詳細な説明は省略する。
第２の実施形態に係るイベント配信装置１０は、第１の実施形態に係るイベント配信装置１０の効果に加え、イベント通知部１０９におけるバッファのオーバーフローを防ぐ効果を有する。
その理由は、第２の実施形態に係るイベント配信装置１０は、イベント通知部１０９のバッファ量を基に、代理転送を送信するか否かを判定しているため、イベント通知部１０９のバッファがオーバーフローする前に代理要求を送信することが出来るためである。
（第３の実施形態）
第２の実施形態に係るイベント配信装置１０では、代理要求条件として、イベント通知部１０９のバッファに蓄えられているデータ量を使用したが、イベント配信装置１０は、代理要求条件として、イベント通知部１０９のバッファに蓄えられているイベントのイベント発生時刻とすることも出来る。
第３の実施形態のイベント配信装置１０は、代理要求条件として、イベント通知部１０９に蓄えられているイベントのイベント発生時刻条件で判定する。なお、第３の実施形態に係るイベント配信装置１０の構成及び動作は、第２の実施形態と同様に、通知制御部１０８と、代理要求制御部１１０と、代理要求条件保持部１１１とを除き、第１の実施形態に係るイベント配信装置１０と同じである。そのため、同じ構成と動作に関する詳細な説明は省略し、第３の実施形態に係るイベント配信装置１０に特有の部分を詳細に説明する。
第３の実施形態における通知制御部１０８は、受け取ったイベントを自装置で通知するか代理転送を要求するかの判定を、イベント通知部１０９に蓄えられている最も古いイベントの発生時刻を基に判定する。通知制御部１０８は、例えば図示しない計時装置などから取得した現在時刻と、最も古いイベントと登録時間との差、つまりイベントの滞留時間に基づき判定する。そのため、第３の実施形態に係る通知制御部１０８は、通知条件として滞留時間を閾値として保存している。この滞留時間の閾値と、イベント通知部１０９に残っているイベントの滞留時間とを比較し、通知制御部１０８は、自装置でイベントを通知するか、他のイベント配信装置１０に代理要求を送信するかを判定している。つまり、滞留時間が閾値を超えている場合、所定の時間ではイベント通知ができないとして、通知制御部１０８は、代理要求を送信する。その他の動作は、第１及び第２の実施形態の同様のため詳細な説明は省略する。
なお、第３の実施形態の通知制御部１０８は、イベント通知部１０９からイベントを引き上げてもよい。このような構成に基づき、例えば、通知制御部１０８が、イベント通知部１０９に保存されているイベントのうち、所定の滞留時間を経過しても通知できないイベントを引き上げる。そして、通知制御部１０８は、引き上げたイベントの通知を代理要求として、他のイベント配信装置１０に送信し、イベント通知の代理を依頼する。このような動作に基づき、第３の実施形態に係るイベント配信装置１０は、滞留しているイベントの通知を解消ことも出来るようになる。
第３の実施形態に係る代理要求条件保持部１１１に保持する条件も、ＣＰＵ使用率の代わりに滞留時間を保持している。そして、通知制御部１０８と同様に、代理要求制御部１１０は、自装置でイベントを通知するか否かを判定するため、イベント通知部１０９から滞留時間を取得し、代理要求条件と比較する。その他の動作は、第１の実施形態などと同様のため、詳細な説明は省略する。
なお、第３の実施形態の代理要求制御部１１０も、イベント通知部１０９からイベントを引き上げてもよい。この場合、代理要求制御部１１０は、通知制御部１０８と同様に、滞留しているイベントを代理要求として他のイベント配信装置１０に転送することが出来る。
これまでの説明では、イベント通知部１０９からの滞留イベントを、通知制御部１０８又は代理要求制御部１１０が、イベント、転送要求、又は、代理要求を受けたときに引き上げる場合について説明した。しかし、イベントなどを受け取ったときに確認するだけでは、例えば、イベントの発生などが途絶えると、通知制御部１０８などは、滞留時間の長いイベントの代理要求が送信できないことも発生する。そのため、本実施形態に係る通知制御部１０８又は代理要求制御部１１０は、定期的にイベント通知部１０９に残っているイベントの滞留時間を確認しても良い。このようにすると、イベントなどの受信が途絶えている場合でも、通知制御部１０８は、適宜、滞留時間の長いイベントの代理要求を送信することが出来る。
第３の実施形態に係るイベント配信装置１０は、第１の実施形態の効果に加え、アプリケーション４０との間の障害などに基づくイベントの滞留に対応したイベント配信を実現する効果を得ることが出来る。
その理由は、通知制御部１０８又は代理要求制御部１１０が、イベントのイベント通知部１０９に滞留しているイベントの滞留時間を基に、自装置でイベントを配信（通知）するか、他のイベント配信装置１０に配信（通知）を依頼するかを判定しているためである。
さらに、第３の実施形態に係るイベント配信装置１０は、滞留しているイベントを解消する効果を得ることも出来る。
その理由は、通知制御部１０８又は代理要求制御部１１０が、所定の時間より長く滞留しているイベントをイベント通知部１０９から引き上げ、代理要求として他のイベント配信装置１０に依頼することが出来るためである。
（第４の実施形態）
第１の実施形態に係るイベント配信装置１０では、イベント通知の代理要求を受信したときに、自装置で送信するか又は代理要求を送信するかの二者選択であった。しかし、自装置の負荷に応じて、代理要求のイベント通知の全てを代理するのは無理でも、一部のイベントを通知できる場合もある。
第４の実施形態に係るイベント配信装置１０は、自装置と他の装置との二者選択ではなく、自装置の負荷に応じて、代理要求の一部のイベントを通知する。
第４の実施形態に係るイベント配信装置１０の構成は、第１の実施形態に係るイベント配信装置１０と同じため、第１の実施形態の同じ構成及び動作に関しての詳細な説明は省略し、第１の実施形態とは異なる動作について詳細に説明する。
代理要求制御部１１０の動作について図面を参照して説明する。
図３２は、第４の実施形態に係る代理要求条件保持部１１１に保持されている、代理要求条件の一例を示す図である。この、代理要求条件は、代理要求条件保持部１１１に予め設定されていてもよく、装置の状態などを基に、自装置、又は、他の装置から設定・変更されても良い。
第４の実施形態に係る代理要求条件は、第１の実施形態に係る代理要求条件に含まれる「ＴＴＬ」と「ＣＰＵ使用率」とに加え「イベント通知先数」とを含む。
ここにおける「イベント通知先数」とは、イベントを通知する通知先の数を示している。例えば、図３０の４行目をデータ「ＴＴＬ＝２，ＣＰＵ使用率＝＜３０、イベント通知先数＝６００」とは、ＴＴＬが２の代理要求を受けた場合に、ＣＰＵの使用率が３０％以下ならば、イベント通知先として６００個まで代理要求を受け付けることを示している。
さらに第４の実施形態の代理要求制御部１１０の動作について図面を参照して詳細に説明する。
図３３は、第４の実施形態に係る代理要求制御部１１０の動作の一例を示すフローチャート図である。
代理要求制御部１１０は、代理要求を受信したとき（ステップ３３０１）、代理要求のＴＴＬを取得する。次に、代理要求制御部１１０は、自装置の負荷状態を取得し、代理要求のＴＴＬと自装置の負荷から、代理要求条件の通知先数を取得する（ステップ３３０２）。
そして、代理要求制御部１１０は、代理要求条件から求めた通知先数が有るか否か（通知先数が０でないこと）を判定する（ステップ３３０３）。
もし、代理要求条件から求めた通知先数が有る場合、さらに、代理要求制御部１１０は、代理要求条件から求めた通知先数と、代理要求の通知先数とを比較する（ステップ３３０４）。代理要求の通知先数が代理要求条件の通知先数と同じか少ない場合、つまり、自装置で代理要求の通知先数に通知出来る場合、代理要求制御部１１０は、代理要求のイベントと通知先とをイベント通知部１０９に渡して、自装置でイベントを通知する（ステップ３３０５）。
自装置で通知する通知先数が有るが、代理要求の通知先数より少ない場合、代理要求制御部１１０は、代理要求条件の通知先の数だけ、代理要求の通知先を取り出す（ステップ３３０６）。そして、代理要求制御部１１０は、取り出した通知先とイベントとをイベント通知部１０９に渡してイベントを通知する（ステップ３３０７）。さらに、代理要求制御部１１０は、イベントを通知した通知先を代理要求から削除し、新しい代理要求を作成する（ステップ３３０８）。この新しい代理要求は、勿論ＴＴＬも１つ減らしている。新しい代理要求を作成した代理要求制御部１１０は、代理要求を送信するイベント配信装置１０を選択し（ステップ３３０９）、選択したイベント配信装置１０に新しい代理要求を送信する（ステップ３３１０）。
代理要求条件に通知先数がない場合、つまり、自装置の負荷が重いなど代理要求がまったくできない場合、代理要求制御部１１０は、第１の実施形態において負荷が重い場合と同様に、代理要求を送信するイベント配信装置１０を選択する（ステップ３３０９）。そして、代理要求制御部１１０は、選択したイベント配信装置１０に代理要求を送信する（ステップ３３１０）。このときの代理要求は、通知先などは変更しないが、ＴＴＬは１つ減らしている。
さらに、代理要求制御部１１０の詳細な動作の説明として、図３０に示す具体的な数値を使用して説明する。
例えば、イベント配信装置１０のＣＰＵ使用率が２０％の場合に、代理要求（ＴＴＬ＝２、通知先数＝１０００）を受けたとする（ステップ３３０１）。このとき、代理要求制御部１１０は、代理要求条件保持部１１１から、代理要求で受信したＴＴＬの「２」と自装置のＣＰＵ使用率「２０％」に対応する通知先数の値である「６００」を取得する（ステップ３３０２）。次に、代理要求制御部１１０は、取得した通知先数（６００）が、０か否かを判定する（ステップ３３０３）。「６００」は、「０」でないため（ステップ３３０３でｙｅｓ）、次に、代理要求制御部１１０は、代理要求の通知先数（１０００）と代理要求条件の通知先数（６００）とを比較する（ステップ３３０４）。代理要求の送信先数が代理要求条件の通知先の数より多いため（ステップ３３０４でｎｏ）、代理要求制御部１１０は、代理要求から代理要求条件の通知先数（６００）だけ通知先を取り出す（ステップ３３０６）。そして、代理要求制御部１１０は、その通知先とイベントとをイベント通知部１０９に渡す（ステップ３３０７）。さらに、代理要求制御部１１０は、代理要求から通知済みの通知先を削除し（この結果、通知先は４００となる。）、ＴＴＬを一つ減らした新しい代理要求を作成する（ステップ３３０８）。続いて、代理要求制御部１１０は、網構成装置情報からイベント配信装置１０を１つ選び（ステップ３３０９）、そのイベント配信装置１０に代理要求を送信する（ステップ３３１０）。
なお、第４の実施形態のイベント配信装置１０の通知制御部１０８においても、同様に、装置の負荷に基づき、代理要求として送信する送信先の数を変更しても良い。通知制御部１０８における代理要求を送信するか否か、通知先の数をどのように決めるかなどの動作は、既に説明した代理要求制御部１１０と同じため、詳細な説明は省略する。また、代理要求を送信するか否かの条件である通知条件も代理要求条件と同様にしておけばよく、詳細な説明は省略する。
第４の実施形態に係るイベント配信装置１０は、第１などの実施形態に係るイベント配信装置１０の効果に加え、代理要求の負荷を分散させる効果を得ることが出来る。
その理由は、第４の実施形態に係るイベント配信装置１０は、代理要求を受信した各イベント配信装置１０が、自装置の負荷を考慮して、所定の負荷までは、可能な範囲の通知先についてのイベントを通知するためである。その結果、イベントを通知するイベント配信装置１０が、増えることとなり、イベント転送の負荷が分散される。さらに、そのイベント配信装置１０から送信される代理要求に含まれるイベントの通知先の数も少なくなるため、代理要求を受けた次のイベント配信装置１０における処理の負荷を軽くすることも出来るためである。
（第５の実施形態）
第１の実施形態に係るイベント配信装置１０は、代理要求を１つのイベント配信装置１０に送信した。しかし、イベント配信装置１０が代理要求を依頼する装置は、１つである必要はなく、複数でもよい。
第５の実施形態に係るイベント配信装置１０は、代理要求を複数送信する。
なお、第５の実施形態に係るイベント配信装置１０は、通知制御部１０８及び代理要求制御部１１０における代理要求を送信するイベント配信装置１０の選択処理と、代理要求を複数作成する点とを除いて、第１の実施形態などと同じである。そのため、第１の実施形態と同じ構成及び動作などについての詳細な説明は省略し、第１の実施形態とは異なる第５の実施形態に係るイベント配信装置１０に特有の動作について詳細に説明する。
第５の実施形態に係る通知制御部１０８は、代理要求を送信すると判定した場合における、網構成装置情報から送信先の装置を選択する処理（図２３のステップ２３０３に相当）において、所定の数の複数の装置を選択する。そして、通知制御部１０８は、受け取ったイベントから複数の代理要求（例えば、通知先を送信の装置の数で均等に分けるなど）を作成し、選択した複数のイベント配信装置１０に代理要求を送信する（図２３のステップ２３０４に相当）。
また、第５の実施形態に係る代理要求制御部１１０は、代理要求を送信すると判定した場合における、網構成装置情報から送信先の装置を選択する処理（図２５のステップ２５０４に相当）において、所定の数の複数の装置を選択する。そして、代理要求制御部１１０は、受け取った代理要求を複数の代理要求に分割し、さらに代理要求の必要な内容（例えばＴＴＬの変更など）を修正し、選択した複数のイベント配信装置１０に代理要求を送信する（図２５のステップ２５０５に相当）。
第５の実施形態に係るイベント配信装置１０は、第１などの実施形態の効果に加え、代理要求を受け付けたイベント配信装置１０における代理要求に対応するイベントの通知の処理の負荷を軽くする効果を得ることが出来る。
その理由は、第５の実施形態に係るイベント配信装置１０は、代理要求を複数に分けるため、代理要求を受け取ったイベント配信装置１０で通知すべき通知先の数が少なくなるためである。
さらに、第５の実施形態に係るイベント配信装置１０は、第１などの実施形態の効果に加え、代理要求が送信されたイベント通知の最大遅延を平均的に低くする効果を得ることが出来る。
その理由は、第５の実施形態に係るイベント配信装置１０は、複数のイベント配信装置１０に代理要求を送信するため、代理要求を受け取った各イベント配信装置１０で通知する通知先の数が、第１の実施形態に係るイベント配信装置１０と比較して少なくなるためである。
さらに、第５の実施形態に係るイベント配信装置１０は、複数のイベント配信装置１０に代理要求を送信している。そのため、送信先のイベント配信装置１０に負荷の軽いイベント配信装置１０が含まれている可能性が高くなる。また、たとえ一部の代理要求が負荷の重いイベント配信装置１０に送信され、再度代理要求となった場合でも、さらに分割した後の代理要求となるため、再度代理要求が送信される通知先の数がさらに少なくなるためである。
（第６の実施形態）
第１の実施形態などに係るイベント配信装置１０は、イベントの代理要求を送るイベント配信装置１０を選択するときに、経路情報保持部１０３の網構成装置情報から自装置以外のイベント配信装置１０をランダムに選択した。
しかし、負荷が重くなっている自装置が受け取ったイベントの転送に関係している他のイベント配信装置１０は、負荷が重くなっていると推定出来る。
そのため、第６の実施形態に係るイベント配信装置１０は、同じイベントの通知に関係しているイベント配信装置１０を代理要求の送信先として選択しない。
なお、第６の実施形態に係るイベント配信装置１０は、通知制御部１０８又は代理要求制御部１１０における代理要求を送信するイベント配信装置１０の選択処理以外は、第１の実施形態などと同じである。そのため、同じ構成及び動作などについての詳細な説明は省略し、第１の実施形態などと異なる第６の実施形態に係るイベント配信装置１０に特有の動作について詳細に説明する。
図３４は、第６の実施形態に係る通知制御部１０８、又は、代理要求制御部１１０の動作の一例を示すフローチャート図である。
なお、以下の説明において、通知制御部１０８がイベントを受け取ったときの処理と転送要求を受け取ったときの動作は同じため、通知制御部１０８がイベントを受け取った処理について説明する。通知制御部１０８が転送要求を受け取った場合は、イベントを転送要求に変更すれば同様の動作となる。また、代理要求制御部１１０が代理要求を受け取った場合の動作も同様である。つまり、代理要求を受け取った代理要求制御部１１０は、説明中の通知制御部１０８を代理要求制御部１１０に置き換え、イベントを代理要求に置き換えれば同様の動作を実現することが出来る。
まず、通知制御部１０８は、選択対象となるイベント配信装置１０の情報を保存する一覧表（以下、「装置リスト」と言う）を用意する。なお、この装置リストは、少なくとも網構成装置情報に保存されている装置が全て保存出来る大きさは備えているものとする。そして、通知制御部１０８は、経路情報保持部１０３の網構成装置情報から自装置を除いた他の全てのイベント配信装置１０の装置情報（例えば装置ＩＤなど）を取得して、装置リストに格納する（ステップ３４０１）。
次に通知制御部１０８は、経路情報保持部１０３において、受信したイベントのタイプの転送経路情報が存在するか否かを判定する（ステップ３４０２）。
イベントのタイプに関する転送経路情報が有る場合、通知制御部１０８は、そのタイプに対応する転送経路情報に登録されている全てのイベント配信装置１０について次の動作を繰り返す（ステップ３４０３）。
まず、通知制御部１０８は、そのタイプの転送経路情報の装置情報（装置ＩＤなど）が装置リストに有るか否かを確認する（ステップ３４０４）。装置リストにある場合、通知制御部１０８は、装置リストからその装置の情報（装置ＩＤなど）を削除する（ステップ３４０５）。そして、通知制御部１０８は、装置リストが空になったか否かを判定する（ステップ３４０６）。装置リストが空でなければ、通知制御部１０８は、そのタイプの転送経路情報の次の装置について同じように処理する。
そのタイプの転送経路情報の装置が装置リストに無い場合（ステップ３４０４でｎｏ）、通知制御部１０８は、特に何も処理せず、そのタイプの転送経路情報の次の装置について同じように処理する。
そのタイプの転送経路情報の全ての装置について処理が終了した場合、装置リストに残ったイベント配信装置１０は、イベントのタイプの転送経路に入っていないイベント配信装置１０である。つまり、装置リストに残ったイベント配信装置１０は、少なくとも、対象となっているイベントに転送には関係しないイベント配信装置１０となっている。そこで、通知制御部１０８は、残った装置リストから、代理要求を送信するイベント配信装置１０を１つ選択する（ステップ３４０８）。
そのタイプの転送経路情報の装置での処理が終わる前に装置リストが空になった場合（ステップ３４０６でｙｅｓ）、そのイベントのタイプに関連しないイベント配信装置１０がないことを示している。この場合、イベントの転送に関係しない装置が自装置の保持している網構成装置情報にないため、通知制御部１０８は、第１の実施形態に係る通知制御部１０８と同様に網構成装置情報からイベント配信装置１０を１つ選択する。なお、この処理を第１の実施形態と同様に処理してもよいが、第６の実施形態の通知制御部１０８は、いままでの動作と合わせている。そのため、通知制御部１０８は、網構成装置情報から自装置を除いた装置リストを再構成し（ステップ３４０７）、その装置リストから代理要求を送信するイベント配信装置１０を１つ選択している（ステップ３４０８）。
また、受信したイベントのタイプの転送経路情報が存在しない場合（ステップ３４０２のｎｏ）、そのタイプに関連するイベント配信装置１０の登録は、ない。そのため、通知制御部１０８は、第１の実施形態に係る通知制御部１０８と同様に網構成装置情報からイベント配信装置１０を１つ選択する。なお、この処理も第１の実施形態と同様に処理してもよいが、第６の実施形態の通知制御部１０８は、イベント配信装置１０の一覧表となっている装置リストから代理要求を送信するイベント配信装置１０を１つ選択している（ステップ３４０８）。
第６の実施形態に係るイベント配信装置１０は、第１の実施形態に係るイベント配信装置１０の効果に加え、イベントの代理要求を負荷の軽いイベント配信装置１０に代理要求を送信する効果を得ることが出来る。
その理由は、第６の実施形態に係るイベント配信装置１０は、代理要求を送信するイベント配信装置１０を選択するときに、通知するイベントの転送に関連しないイベント配信装置１０を選択するためである。
（第７の実施形態）
第１の実施形態に係るイベント配信装置１０は、代理要求の送信先であるイベント配信装置１０を選択するとき、経路情報保持部１０３の網構成装置情報からランダムにイベント配信装置１０を選択した。しかし、網構成装置情報には、代理要求の要求元であるイベント配信装置１０も含まれている。そのため、第１の実施形態などのイベント配信装置１０は、ある確率で、代理要求を送った要求元であるイベント配信装置１０を、代理要求の送信先として選択する可能性があった。もし、代理要求の要求元であるイベント配信装置１０を代理要求の送信先として選択すると、送信先も当然再度代理要求を送信するため、無駄な代理要求の転送処理が発生する。さらに、２つのイベント配信装置１０で代理要求の往復や、３つ以上のイベント配信装置１０の間での代理要求のループが発生する可能性もある。また、このような無駄な代理要求のやりとりでＴＴＬの値が０となってしまうと、負荷が重いイベント配信装置１０においてイベントを通知する処理が発生してしまう。
第７の実施形態に係るイベント配信装置１０は、代理要求に、第１の実施形態などで説明したデータに加え、代理要求を送信したイベント配信装置１０の情報（以下このデータを「送信元装置リスト」と言う）の一部又は全てを含ませている。この送信元装置リストのデータは、例えば、代理要求を送信したイベント配信装置１０の装置ＩＤの一覧を格納したデータなどである。このような代理要求を送信した装置ＩＤを格納した送信元装置リストに基づき、例えば、代理要求制御部１１０は、受信した代理要求を再送信するイベント配信装置１０を選択するときに、送信元装置リストに格納されているイベント配信装置１０を選択先から外すようにする。このような動作に基づき、第７の実施形態に係るイベント配信装置１０は、代理要求の送信元に代理要求を戻すことを回避している。
第７の実施形態に係るイベント配信装置１０について、図面を参照してさらに詳細に説明する。なお、第７の実施形態に係るイベント配信装置１０において、通知制御部１０８が代理要求に自装置の情報を含ませることと、代理要求制御部１１０における代理要求を送信するイベント配信装置１０の選択処理及び代理要求の作成処理と以外は、第１の実施形態などと同様である。そのため、同じ構成及び動作についての詳細な説明は省略し、第１の実施形態などと異なる第７の実施形態に係るイベント配信装置１０に特有の動作について詳細に説明する。
第７の実施形態に係る通知制御部１０８又は代理要求制御部１１０は、代理要求を送信するとき、代理要求の送信元装置リストに自装置の情報（例えば、装置ＩＤ）を追加する。
さらに、第７の実施形態に係る代理要求制御部１１０の動作について図面を参照して説明する。
図３５は、第７の実施形態に係る代理要求制御部１１０の動作の一例を示すフローチャート図である。
代理要求制御部１１０は、他のイベント配信装置１０に代理要求を転送するために他のイベント配信装置１０を選択するとき、まず、選択対象となるイベント配信装置１０の情報を保存する一覧表を用意する。なお、この一覧表は、第６の実施形態に係る「装置リスト」と同様のため、第７の実施形態の説明のおいても「装置リスト」と言う。また、この装置リストは、少なくとも網構成装置情報に保存されている装置が全て保存出来る大きさは備えているものとする。代理要求制御部１１０は、経路情報保持部１０３の網構成装置情報から自装置を除いたすべての装置情報（例えば、装置ＩＤ）を取得して「装置リスト」に格納する（ステップ３５０１）。次に、代理要求制御部１１０は、代理要求で受信した送信元装置リストの各装置に対して、次の処理を繰り返す（ステップ３５０２）。代理要求制御部１１０は、装置リストに代理要求の送信元の装置があるか否かを確認する（ステップ３５０３）。送信元の装置が装置リストにある場合、代理要求制御部１１０は、装置リストから送信元の装置の情報を削除する（ステップ３５０４）。削除後、代理要求制御部１１０は、装置リストが空になったか否かを確認する（ステップ３５０５）。
もし、装置リストが空でなければ、代理要求制御部１１０は、代理要求の送信元装置リストの次の装置の処理に移る。これを、代理要求制御部１１０は、代理要求の送信元装置リストに含まれる全ての装置に対して繰り返す。
なお、代理要求に含まれる送信元装置が装置リストにない場合は、特に必要な処理はないため、代理要求制御部１１０は、次の送信元装置について処理する。
代理要求の送信元装置リストの全ての装置を削除しても装置リストに装置が残った場合、装置リストに残った装置は、代理要求の送信元装置ではない装置となる。従って、代理要求制御部１１０は、残った装置リストから代理要求の送信先となるイベント配信装置１０を選択する（ステップ３５０７）。
もし、送信元装置リストの途中で、装置リストが空となった場合は、全ての装置がそのイベントの代理要求を出していることを示す。この場合、送信元となっていない装置がないこととなり、代理要求制御部１１０は、第１の実施形態と同様に網構成装置情報からランダムなど所定の処理でイベント配信装置１０を選択して、代理要求を送信する。なお、この選択は第１の実施形態と同様でも良いが、第７の実施形態に係る代理要求制御部１１０は、動作の統一などのため装置リストから選択することとしている。そのため代理要求制御部１１０は、再度、網構成装置情報から装置リストを作成し（ステップ３５０６）、その装置リストからイベント配信装置１０を選択する（ステップ３５０７）。
さらに具体的なデータを使用して詳細な説明する。
例えば、図８に示すノードＡの通知制御部１０８がノードＣに代理要求を送信するとき、代理要求に自装置の情報（例えば、ノードＡのノードＩＤ）を含む送信元装置リストを加える。このときの代理要求を、模式的に説明すると、代理要求＝「イベント、通知先、ＴＴＬ（＝例えば３）、送信元装置リスト（ノードＡ）」となる。
次に、ノードＣがノードＡから代理要求（イベント、通知先、ＴＴＬ＝３、通知先装置リスト（ノードＡ））を受信し、自装置の負荷が重く、他装置に代理要求を転送するためにイベント配信装置１０を選択するとき場合の動作を説明する。ノードＣの代理要求制御部１１０は、まず、経路情報保持部１０３の網構成装置情報から自装置を除いたすべての装置情報を取得し、装置リストに格納する（ステップ３５０１）。図８のノードＣの場合の装置リストは、「ノードＡ，ノードＤ，ノードＥ」となる。次に、代理要求制御部１１０は、代理要求で受信した送信元装置リスト（この場合は、「ノードＡ」となる。）の装置が有るか否かを確認する（ステップ３５０３）。送信元装置リストのノードＡが、装置リストにあるため、代理要求制御部１１０は、装置リストからノードＡの装置情報を削除する（ステップ３５０４）。この結果、装置リストは、「ノードＤ，ノードＥ」となる。さらに、代理要求制御部１１０は、装置リストが空か否かを確認する（ステップ３５０５）。まだ空でないため、代理要求制御部１１０は、次の装置の確認に移る。いま説明している例では、既に送信元装置リストの装置が終わっているため、代理要求制御部１１０は、残った装置リスト（「ノードＤ，ノードＥ」）から、代理要求を転送するイベント配信装置１０（ノードＤ又はノードＥ）を１つ選択する（ステップ３５０７）。
このような動作に基づき、第７の実施形態に係るイベント配信装置１０は、送信元であるイベント配信装置１０（説明ではノードＡ）を代理要求の送信先から外した選択ができる。
第７の実施形態に係るイベント配信装置１０は、第１のなどの実施形態に係る効果に加え、さらに既に代理要求を送信したイベント配信装置１０に代理要求を再送信することを避けるという効果を得ることが出来る。
その理由は、第７の実施形態に係るイベント配信装置１０は、代理要求に、代理要求を送信したイベント配信装置１０の装置の情報を代理要求に含める。そして、第７の実施形態に係るイベント配信装置１０は、その送信元の情報を使用して、代理要求を送信するイベント配信装置１０の選択先から、代理要求を送信したイベント配信装置１０を外して選択するためである。
（第８の実施形態）
第１の実施形態などに係るイベント配信装置１０は、代理要求を送信する送信先のイベント配信装置１０に装置状態の問い合わせず、代理要求を送信した。そのため、同じイベントを通知するなど負荷の重いイベント配信装置１０を選択する場合が有った。そこで、第６の実施形態などに係るイベント配信装置１０は、同様のイベントを配信していて負荷が重いと推定されるイベント配信装置１０を除いて送信先を選択した。しかし、イベント配信装置１０は、他の処理など、別要因で負荷が重くなる場合も有る。
第８の実施形態に係るイベント配信装置１４は、代理要求を送信するために選択したイベント配信装置１４への代理要求の送信に先立ち、送信先として選択したイベント配信装置１４に代理要求を受け付けることが出来るか否かを確認している。
第８の実施形態に係るイベント配信装置１４について、図３６−図３９を参照して説明する。
図３６は、第８の実施形態に係るイベント配信装置１４の構成の一例を示すブロック図である。図３４において、図５のイベント配信装置１０と同じ構成は、同じ番号を付し、詳細な説明は省略する。
第８の実施形態に係るイベント配信装置１４は、通知制御部１１３と、代理要求制御部１１４と、イベント通知部１１５と、メッセージ転送部１１６とにおける代理要求を送信又は受信した場合の動作が、第１などの実施形態に係るイベント配信装置１０と異なる。
通知制御部１１３は、代理要求を送信する前に送信先の装置の状態を確認、具体的には、代理要求を受け付けることが出来るか否かを確認する。この動作については、後ほど詳細に説明する。
代理要求制御部１１４は、他のイベント配信装置１４から、代理要求を受け付けることが出来るか否かの問い合わせに対して、自装置の状態を基に応答する。この動作についても後ほど詳細に説明する。
イベント配信装置１４は、代理要求を受け付け可能な場合だけ代理要求を受け付けるため、第１の実施形態に係るイベント配信装置１０のように、受け付けた代理要求について受け付け可能か否かを判定する必要がない。そのため、イベント配信装置１４は、代理要求を直接イベント通知部１１５が受け取り、イベントを通知する。この処理に関しても後ほど詳細に説明する。
メッセージ転送部１１６は、通知制御部１１３から受け取った問い合わせと代理要求制御部１１４から受け取った回答を他のイベント配信装置１４に送信する。また、他のイベント配信装置１４から受け取った問い合わせを代理要求制御部１１４に渡し、代理要求をイベント通知部１１５に渡す。メッセージ転送部１１６のその他の動作は、第１の実施形態などと同様のため詳細な説明は省略する。
続いて、第８の実施形態に係るイベント配信装置１４に動作について説明する。
なお、代理要求の処理を除いて、イベント配信装置１４の動作は、イベント配信装置１０の動作と同様のため、第１などの実施形態と同様の動作についての説明は省略し、第８の実施形態に特有の動作について詳細に説明する。
まず、通知制御部１１３の動作について図面を参照して説明する。
図３７は、通知制御部１１３の動作の一例を示すフローチャート図である。
パブリッシャ２０からメッセージ転送部１１６を介してイベントを受信した通知制御部１１３は（ステップ３７０１）、自装置の負荷を通知制御部１１３が保持している通知条件と比較する（ステップ３７０２）。自装置の負荷が重い場合、通知制御部１１３は、代理要求を送信する。この動作として、まず、通知制御部１１３は、網構成装置情報から通知先として所定の方式を用いてイベント配信装置１４を選択する（ステップ３７０３）。続いて、通知制御部１１３は、選択したイベント配信装置１４にメッセージ転送部１１６を介して、代理要求を受け付けることが出来るか否かの問い合わせを送信する（ステップ３７０３）。本実施形態のこの問い合わせは、ＴＴＬを含む。イベント配信装置１４から問い合わせの回答として、受け付けが不可（否）だった場合（ステップ３７０４のｎｏ）、通知制御部１１３は、他の送信先を探す。通知制御部１１３は、ＴＴＬを１つ少なくし（ステップ３７０５）、ＴＴＬが０となっているか否かを判定する（ステップ３７０６）。まだ、ＴＴＬが０でない場合は、次の送信先を選択する（ステップ３７０３）。もし、ＴＴＬが０の場合は、送信先への選択ができないため、通知制御部１１３は、イベントと通知先とをイベント通知部１１５に渡して、自装置でイベントを通知する。
なお、第８の実施形態に係る通知制御部１１３は、実際に代用要求を送信した回数としてＴＴＬを使用し、送信先の選択の回数の制限として他の値を備えてもよい。また、他のイベント配信装置１４との確認時間は、ネットワークを経由するため時間を予想できない。そこで、通知制御部１１３は、送信先の選択の処理全体の時間を監視し、装置の選択の動作を制限してもよい。さらに、他のイベント配信装置１４から回答に関しても、所定の監視時間を設定し、監視時間内に回答がない場合、通知制御部１１３は、代理要求不可として、他の装置を確認しても良い。
一方、問い合わせ先のイベント配信装置１４から代理要求の受け付け可の回答を受けた場合（ステップ３７０４のｙｅｓ）、通知制御部１１３は代理要求を選択したイベント配信装置１４に送信する（ステップ３７０７）。
また、自装置の負荷が通知条件より軽い場合、通知制御部１１３は、イベントと通知先とをイベント通知部１１５に渡し、イベントを通知する（ステップ３７０８）。
次に、代理要求制御部１１４の動作について説明する。
図３８は、代理要求制御部１１４の動作の一例を示すフローチャート図である。
メッセージ転送部１１６を介して代理要求の問い合わせを受け付けた代理要求制御部１１４は（ステップ３８０１）、受け付けた代理要求のＴＴＬを基に代理要求条件の負荷条件を取得する（ステップ３８０２）。次に、代理要求制御部１１４は、自装置の負荷を取得し代理要求条件の負荷と比較する（ステップ３８０３）。自装置の負荷が重い場合（ステップ３８０３のｙｅｓ）、代理要求制御部１１４は、代理要求を受け付けることができないため、代理要求の受け付け不可を回答する（ステップ３８０４）。一方、自装置の負荷が軽い場合（ステップ３８０３のｎｏ）、代理要求制御部１１４は、自装置で代理要求を処理出来るため、代理要求の受け付け可能の回答を返す（ステップ３８０５）。
続いて、イベント通知部１１５の動作について説明する。
図３９は、イベント通知部１１５の動作の一例を示すフローチャート図である。
メッセージ転送部１１６を介して代理要求を受け取ったイベント通知部１１５は（ステップ３９０１）、代理要求に含まれる通知先となっているアプリケーション４０全てに（ステップ３９０２）、代理要求に含まれるイベントを通知する（ステップ３９０３）。
なお、第８の実施形態に係るイベント配信装置１４において、代理要求の問い合わせに関して、受け付けの可否の回答ではなく、受け付け可能な通知先数を回答してもよい。この場合、回答を受けたイベント配信装置１４は、受け付け可能な通知先の数、又は、その数以下の通知先を含む代理要求を送信し、残りの通知先については、別のイベント配信装置１４に代理要求を送信する。
また、イベント配信装置１４は、イベント配信装置１４への問い合わせとして、ＴＴＬと通知先数とを送信してもよい。この場合に、問い合わせを受けたイベント配信装置１４は、ＴＴＬと通知先数に基づき代理要求を受け付けるか否かを判定し、受け付け可否を回答する。さらに、この場合においても、イベント配信装置１４は、回答として受け付け可能な通知先数を回答してもよい。
なお、第８の実施形態に係る代理要求は、受け付け可能なイベント配信装置１４に送信されるため、ＴＴＬを含まなくてもよい。
第８の実施形態に係るイベント配信装置１４は、第１の実施形態に係るイベント配信装置１０の効果に加え、イベント配信ＮＷ５０などに流れるデータの量を減らす効果を得ることが出来る。
その理由は、イベント配信装置１４が、代理要求が受け付け可能か否かの問い合わせに基づき、イベント配信装置１４が、代理要求を受け付け可能なイベント配信装置１４に代理要求を送信するため、代理要求の再送信を防ぐことが出来るためである。
（第９の実施形態）
第８の実施形態に係るイベント配信装置１４は、代理要求を受け付けるか否かの可否を回答した。しかし、例えば、ロードバランスを考慮した代理要求を送信する場合、受け付けの可否だけではなく、各装置の負荷状態も必要となる。
第９の実施形態に係るイベント配信装置１５は、代理要求の問い合わせに対して自装置の負荷状態を含んで回答する。
第９の実施形態のイベント配信装置１５について、図４０−図４１を参照して説明する。
図４０は、第９の実施形態に係るイベント配信装置１５の構成の一例を示すブロック図である。図４０において、図３４のイベント配信装置１４と同じ構成は、同じ番号を付し、詳細な説明は省略する。
第９の実施形態に係るイベント配信装置１５は、通知制御部１１７と、代理要求条件保持部１１８と、代理要求制御部１１９との動作が、第８の実施形態のイベント配信装置１４と異なる。
通知制御部１１７は、代理要求の回答として送信先の装置の負荷状態を受け取り、受け取った負荷状態を基に、代理要求を送信するか否かを判定する。この動作については、後ほど詳細に説明する。
代理要求条件保持部１１８は、代理要求を送信する場合の装置の負荷などの条件を保持している。
代理要求制御部１１９は、代理要求の受け付けに関する問い合わせに対して、自装置の負荷状態を含む情報を回答する。
続いて、第９の実施形態に係るイベント配信装置１５に動作について説明する。
なお、イベント配信装置１５の動作は、代理要求の問い合わせに対する回答に関する動作を除いてイベント配信装置１４の動作と同様の動作のため、第８の実施形態と同様の動作についての説明は省略し、第９の実施形態に特有の動作について詳細に説明する。
図４１は、通知制御部１１７の動作の一例を示すフローチャート図である。
メッセージ転送部１１６を介してイベントを受信した通知制御部１１７（ステップ４１０１）は、通知制御部１１７の保持している通知条件と自装置の負荷とを比較する（ステップ４１０２）。自装置の負荷が重い場合（ステップ４１０２のｙｅｓ）、通知制御部１１７は、代理要求を送信する。この処理として、まず、通知制御部１１７は、網構成装置情報から通知先のイベント配信装置１５を１つ選択する（ステップ４１０３）。通知制御部１１７は、選択したイベント配信装置１５に代理要求の受け付けが可能か否かの負荷状態の問い合わせ、装置負荷の情報を含む回答を受け取る（ステップ４１０４）。ここでの問い合わせは、代理要求に対する問い合わせでなく、負荷状態を問い合わせでもよい。続いて通知制御部１１７は、現在のＴＴＬを基に、代理要求条件保持部１１８が保持している代理要求条件を取得する（ステップ４１０５）。通知制御部１１７は、受け取った負荷状態と代理要求条件の負荷とを比較する（ステップ４１０６）。
問い合わせを受けた装置の負荷が重い場合、代理要求の送信先にはできないため、通知制御部１１７は、次の送信先を選択する。そのため、通知制御部１１７は、まずＴＴＬを１つ減らし（ステップ４１０７）、ＴＴＬが０でないかを判定する（ステップ４１０８）。もし、ＴＴＬが０でない場合、代理要求を通知できるため、通知制御部１１７は、次の送信先のイベント配信装置１５を選択する（ステップ４１０３）。ＴＴＬが０の場合（ステップ４１０８でｙｅｓ）、代理要求を送信できないため、通知制御部１１７は、イベント通知部１１５にイベントと通知先とを渡して、自装置で通知する（ステップ４１１０）。
一方、問い合わせ先の装置の負荷が軽い場合、通知制御部１１７は、代理要求を選択したイベント配信装置１５に送信する（ステップ３８０９）。
自装置の負荷が軽い場合（ステップ４１０２でｎｏ）、通知制御部１１７は、イベント通知部１１５に受け取ったイベント等を渡して、自装置でイベントを通知する（ステップ４１１０）。
なお、通知制御部１１７が装置の負荷を確認する場合、確認先の装置は、１つに限る必要はない。例えば、ステップ４１０３において通知制御部１１７が複数のイベント配信装置１５を選択し、その選択した複数のイベント配信装置１５から負荷状態を受け取ってもよい。この場合、通知制御部１１７は、代理要求の送信先として、負荷状態が軽い装置から順番に選択してもよい。また、通知制御部１１７は、複数のイベント配信装置１５の負荷状態から複数の装置の負荷分散を考慮し、例えば、負荷の重い装置には通知先の数が少ない代理要求を、負荷の軽い装置には通知先の数が多い代理要求を送信しても良い。
第９の実施形態に係るイベント配信装置１５は、第１の実施形態に係るイベント配信装置１０の効果に加え、イベント配信ＮＷ５０などに流れるデータの量を減らす効果を得ることが出来る。
その理由は、イベント配信装置１５が、代理要求の送信先のイベント配信装置１５の負荷を考慮して、代理要求を受け付け可能なイベント配信装置１５に送信するためである。
また、第９の実施形態に係るイベント配信装置１５は、さらに、イベントの通知の負荷分散を実現する効果を得ることも出来る。
その理由は、第９の実施形態に係るイベント配信装置１５は、複数のイベント配信装置１５の負荷を考慮し、負荷の軽いイベント配信装置１５に代理要求を送信、又は、負荷分散を考慮した代理要求を送信することが出来るためである。
なお、各実施形態について、単独で説明してきたが、実施形態を組み合わせて使用することも可能である。例えば、第６の実施形態と第７の実施形態とを合わせ、代理要求を送信するイベント配信装置１０の選択から、イベントの転送に関係する装置及び代理要求の送信元の両方の装置を外してもよい。このように組み合わせた実施形態に係るイベント配信装置１０は、第６の実施形態及び第７の実施形態に係るイベント配信装置１０と比較し、負荷の軽いイベント配信装置１０を選択出来る可能性を高くすることが出来る。
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
（付記）
（付記１）予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を含むイベント配信装置。
（付記２）予め登録されている代理要求条件を基に、ネットワークを介して受信した代理要求に含まれるイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御部を含むことを特徴とする付記１に記載のイベント配信装置。
（付記３）  前記通知制御部が、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記２に記載のイベント配信装置。
（付記４）前記代理要求制御部が、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記２又は付記３に記載のイベント配信装置。
（付記５）前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベント配信装置の負荷情報を含み、
前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むこと
を特徴とする付記２乃至付記４のいずれかに記載のイベント配信装置。
（付記６）前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存する経路制御部と、
前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理する購読要求制御部と、
前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送するイベント受信転送部と、
前記イベントと前記サブスクリプションとの一致を判定する一致判定部と、
前記イベントをアプリケーションに通知するイベント通知部と
を含むことを特徴とする付記２乃至付記５のいずれかに記載のイベント配信装置。
（付記７）前記経路制御部が、前記購読要求制御部の前記サブスクリプションの登録又は削除に伴い、前記イベントを転送する装置に関する情報を変更することを特徴とする付記６に記載のイベント配信装置。
（付記８）前記通知条件又は前記代理要求条件の少なくともいずれかが、自装置の資源に関する情報、自装置で通知するイベントの量に関する情報、又は、自装置で通知するイベントの滞留時間に関する情報の少なくとも１つを含むことを特徴とする付記２乃至付記７のいずれかに記載のイベント配信装置。
（付記９）前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を２以上の前記他の装置に送信することを特徴とする付記２乃至付記８のいずれかに記載のイベント配信装置。
（付記１０）前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする付記２乃至付記９のいずれかに記載のイベント配信装置。
（付記１１）前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの代理要求を送信した装置を除くことを特徴とする付記２乃至付記１０のいずれかに記載のイベント配信装置。
（付記１２）前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の前記代理要求の受け付けの可否を確認することを特徴とする付記２乃至付記１１のいずれかに記載のイベント配信装置。
（付記１３）前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の負荷情報を受け取り、受け取った負荷情報を基に前記代理要求を送信するか否かを判定することを特徴とする付記２乃至１２のいずれかに記載のイベント配信装置。
（付記１４）予め登録されている通知条件を基に、ネットワークを介して受信したイベントのうち、予め登録されているサブスクリプションと一致したイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御部を含むイベント配信装置と、
前記イベント配信装置に前記ネットワークを介して前記イベントをパブリッシュするパブリッシャと、
前記イベント配信装置に前記サブスクリプションを送信するサブスクライバと、
前記イベント配信装置から前記イベントの通知を受けるアプリケーションと
を含むイベント配信システム。
（付記１５）前記イベント配信装置が、予め登録されている代理要求条件を基に、ネットワークを介して受信した代理要求に含まれるイベントを、自装置で通知するか、前記ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御部を含むことを特徴とする付記１４に記載のイベント配信システム。
（付記１６）前記通知制御部が、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記１５に記載のイベント配信システム。
（付記１７）前記代理要求制御部が、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記１５又は付記１６に記載のイベント配信システム。
（付記１８）前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベント配信装置の負荷情報を含み、
前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むこと
を特徴とする付記１５乃至付記１７のいずれかに記載のイベント配信システム。
（付記１９）前記イベント配信装置が、
前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存する経路制御部と、
前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理する購読要求制御部と、
前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送するイベント受信転送部と、
前記イベントと前記サブスクリプションとの一致を判定する一致判定部と、
前記イベントを前記アプリケーションに通知するイベント通知部と
を含むことを特徴とする付記１５乃至付記１８のいずれかに記載のイベント配信システム。
（付記２０）前記経路制御部が、前購読要求制御部の前記サブスクリプションの登録又は配信削除に伴い前記イベントを転送する装置に関する情報を変更することを特徴とする付記１９に記載のイベント配信システム。
（付記２１）前記通知条件又は前記代理要求条件の少なくともいずれかが、少なくとも１つ以上の装置の資源の関する情報、通知するイベントの量に関する情報、又は、通知するイベントの滞留時間に関する情報の少なくとも１つを含むことを特徴とする付記１５乃至付記２０のいずれかに記載のイベント配信システム。
（付記２２）前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を２以上の装置に送信することを特徴とする付記１５乃至付記２１のいずれかに記載のイベント配信システム。
（付記２３）前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする付記１５乃至付記２２のいずれかに記載のイベント配信システム。
（付記２４）前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの代理要求を送信した装置を除くことを特徴とする付記１５乃至付記２３のいずれかに記載のイベント配信システム。
（付記２５）前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の前記代理要求の受け付けの可否を確認することを特徴とする付記１５乃至付記２４のいずれかに記載のイベント配信システム。
（付記２６）前記通知制御部又は前記代理要求制御部の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の負荷情報を受け取り、受け取った負荷情報を基に前記代理要求を送信するか否かを判定することを特徴とする付記１５乃至付記２５のいずれかに記載のイベント配信システム。
（付記２７）ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定するイベント配信方法。
（付記２８）ネットワークを介して代理要求を受信した場合、予め登録されている代理要求条件を基に、前記受信した代理要求に含まれるイベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定することを特徴とする付記２７に記載のイベント配信方法。
（付記２９）前記イベントを受信した場合、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記２８に記載のイベント配信方法。
（付記３０）前記代理要求を受けた場合、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記２８又は付記２９に記載のイベント配信方法。
（付記３１）前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベントの処理の負荷情報を含み、
前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むこと
を特徴とする付記２８乃至付記３０のいずれかに記載のイベント配信方法。
（付記３２）前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存し、
前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理し、
前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送し、
前記イベントと前記サブスクリプションとの一致を判定し、
前記イベントをアプリケーションに通知する
ことを特徴とする付記２８乃至付記３１のいずれかに記載のイベント配信方法。
（付記３３）前記サブスクリプションの登録又は配信削除の処理に伴い前記イベントを転送する装置に関する情報を変更することを特徴とする付記３２に記載のイベント配信方法。
（付記３４）前記通知条件又は前記代理要求条件の少なくともいずれかが、処理に使用される資源に関する情報、通知するイベントの量に関する情報、又は、通知するイベントの滞留時間に関する情報の少なくとも１つを含むことを特徴とする付記２８乃至付記３３のいずれかに記載のイベント配信方法。
（付記３５）前記代理要求を２以上の装置に送信することを特徴とする付記２８乃至付記３４のいずれかに記載のイベント配信方法。
（付記３６）前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする付記２８乃至付記３５のいずれかに記載のイベント配信方法。
（付記３７）前記代理要求を送信する前記他の装置として、前記イベントの代理要求を送信した装置を除くことを特徴とする付記２８乃至付記３６のいずれかに記載のイベント配信方法。
（付記３８）前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の前記代理要求を受け付けの可否を確認することを特徴とする付記２８乃至付記３７のいずれかに記載のイベント配信方法。
（付記３９）前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の負荷情報を受け取り、受け取った負荷情報を基に前記代理要求を送信するか否かを判定することを特徴とする付記２８乃至付記３８のいずれかに記載のイベント配信方法。
（付記４０）ネットワークを介してイベントを受信した場合、予め登録されている通知条件を基に、予め登録されているサブスクリプションと一致した前記イベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する通知制御処理をコンピュータに実行させるイベント配信プログラムを格納する記憶媒体。
（付記４１）ネットワークを介して代理要求を受信した場合、予め登録されている代理要求条件を基に、前記受信した代理要求に含まれるイベントを、自装置で通知するか、ネットワークに接続した他の装置に代理要求を送信して依頼するかを判定する代理要求制御処理を含むことを特徴とする付記４０に記載のイベント配信プログラムを格納する記憶媒体。
（付記４２）前記通知制御処理が、前記通知条件を基に前記イベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記４１に記載のイベント配信プログラムを格納する記憶媒体。
（付記４３）前記代理要求処理が、前記代理要求条件を基に前記受信した代理要求に含まれるイベントの一部を自装置で通知し、残りのイベントの通知を前記他の装置に代理要求を送信して依頼することを特徴とする付記４１又は付記４２に記載のイベント配信プログラムを格納する記憶媒体。
（付記４４）前記通知条件又は前記代理要求条件の少なくともいずれかが、前記イベントの処理の負荷情報を含み、
前記代理要求条件は、さらに代理要求の再送信が可能か否かに関する情報を含むこと
を特徴とする付記４１乃至付記４３のいずれかに記載のイベント配信プログラムを格納する記憶媒体。
（付記４５）前記ネットワークを構成する全て又は一部の装置に関する情報と前記イベントを転送する全て又は一部の装置に関する情報とを管理保存する経路制御処理と、
前記サブスクリプションの登録指示又は削除指示を受信し前記サブスクリプションの登録又は削除を管理する購読要求制御処理と、
前記イベントを受け取り、前記イベントを転送する装置に関する情報を基に他の装置にイベントを転送するイベント受信転送処理と、
前記イベントと前記サブスクリプションとの一致を判定する一致判定処理と、
前記イベントをアプリケーションに通知するイベント通知処理と
を含むことを特徴とする付記４１乃至付記４４のいずれかに記載のイベント配信プログラムを格納する記憶媒体。
（付記４６）前記経路制御処理が、前購読要求制御処理における前記サブスクリプションの登録又は配信削除の処理に伴い前記イベントを転送する装置に関する情報を変更することを特徴とする付記４５に記載のイベント配信プログラムを格納する記憶媒体。
（付記４７）前記通知条件又は前記代理要求条件の少なくともいずれかが、処理に使用される資源に関する情報、通知するイベントの量に関する情報、又は、通知するイベントの滞留時間に関する情報の少なくとも１つを含むことを特徴とする付記４１乃至付記４６のいずれかに記載のイベント配信プログラムを格納する記憶媒体。
（付記４８）前記通知制御処理又は前記代理要求制御処理の少なくともいずれかが、前記代理要求を２以上の装置に送信することを特徴とする付記４１乃至付記４７のいずれかに記載のイベント配信プログラムを格納する記憶媒体。
（付記４９）前記通知制御処理又は前記代理要求制御処理の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの転送に関係する装置を除くことを特徴とする付記４１乃至付記４８のいずれかに記載のイベント配信プログラムを格納する記憶媒体。
（付記５０）前記通知制御処理又は前記代理要求制御処理の少なくともいずれかが、前記代理要求を送信する前記他の装置として、前記イベントの代理要求を送信した装置を除くことを特徴とする付記４１乃至付記４９のいずれかに記載のイベント配信プログラムを格納する記憶媒体。
（付記５１）前記通知制御処理又は前記代理要求制御処理の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の前記代理要求の受け付け可否を確認する処理を行うことを特徴とする付記４１乃至付記５０のいずれかに記載のイベント配信プログラムを格納する記憶媒体。
（付記５２）前記通知制御処理又は前記代理要求制御処理の少なくともいずれかが、前記代理要求を送信する前に、前記代理要求を送信しようとしている前記他の装置の負荷情報を受けとり、受け取った負荷情報を基に前記代理要求を送信するか否かを判定する処理を含むことを特徴とする付記４１乃至付記５１のいずれかに記載のイベント配信プログラムを格納する記憶媒体。
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
この出願は、２０１０年２月１５日に出願された日本出願特願２０１０−００６２４を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【００１０】
１    イベント配信システム
２    イベント配信システム
１０    イベント配信装置
１１    イベント配信装置
１２    イベント配信装置
１３    イベント配信装置
１４    イベント配信装置
１５    イベント配信装置
２０    パブリッシャ
３０    サブスクライバ
４０    アプリケーション
５０    イベント配信ＮＷ
６０    イベント配信ＮＷ
７１    メッセージ転送装置
７２    経路制御装置
７３    購読要求制御装置
７４    通知制御装置
７５    代理要求制御装置
７６    イベント通知装置
１０１  メッセージ転送部
１０２  経路制御部
１０３  経路情報保持部
１０４  購読要求制御部
１０５  購読要求保持部
１０６  イベント受信転送部
１０７  一致判定部
１０８  通知制御部
１０９  イベント通知部
１１０  代理要求制御部
１１１  代理要求条件保持部
１１２  通知条件保持部
１１３  通知制御部
１１４  代理要求制御部
１１５  イベント通知部
１１６  メッセージ転送部
１１７  通知制御部
１１８  代理要求条件保持部
１１９  代理要求制御部
【図１】
2011099649.tif 000003
【図２】
2011099649.tif 000004
【図３】
2011099649.tif 000005
【図４】
2011099649.tif 000006
【図５】
2011099649.tif 000007
【図６】
2011099649.tif 000008
【図７Ａ】
2011099649.tif 000009
【図７Ｂ】
2011099649.tif 000010
【図８】
2011099649.tif 000011
【図９】
2011099649.tif 000012
【図１０】
2011099649.tif 000013
【図１１】
2011099649.tif 000014
【図１２】
2011099649.tif 000015
【図１３】
2011099649.tif 000016
【図１４】
2011099649.tif 000017
【図１５】
2011099649.tif 000018
【図１６】
2011099649.tif 000019
【図１７】
2011099649.tif 000020
【図１８】
2011099649.tif 000021
【図１９】
2011099649.tif 000022
【図２０】
2011099649.tif 000023
【図２１】
2011099649.tif 000024
【図２２】
2011099649.tif 000025
【図２３】
2011099649.tif 000026
【図２４】
2011099649.tif 000027
【図２５】
2011099649.tif 000028
【図２６】
2011099649.tif 000029
【図２７】
2011099649.tif 000030
【図２８】
2011099649.tif 000031
【図２９】
2011099649.tif 000032
【図３０】
2011099649.tif 000033
【図３１】
2011099649.tif 000034
【図３２】
2011099649.tif 000035
【図３３】
2011099649.tif 000036
【図３４】
2011099649.tif 000037
【図３５】
2011099649.tif 000038
【図３６】
2011099649.tif 000039
【図３７】
2011099649.tif 000040
【図３８】
2011099649.tif 000041
【図３９】
2011099649.tif 000042
【図４０】
2011099649.tif 000043
【図４１】
2011099649.tif 000044
【国際調査報告】
2011099649.tif 000045
2011099649.tif 000046
2011099649.tif 000047