JPWO2013031068A1 - イベント通知サービス方法およびシステム - Google Patents

Abstract

イベント発行サーバと、イベントの通知をイベント発行サーバに対して依頼するユーザ端末からの通知依頼をイベント発行サーバに、あるいは、イベントをユーザ端末に、中継して転送する複数の中継サーバと、を備える。そして、中継サーバは、イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから通知依頼あるいはイベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルと、転送キーを含む通知依頼あるいはイベントの転送要求を受けて、当該転送要求にかかる通知依頼あるいはイベントに含まれた転送キーと同一の転送キーに、転送テーブル内で関連付けられた転送先アドレスの中継サーバに、通知依頼あるいはイベントを転送するメッセージ転送手段と、を備える。

Description

本発明は、イベント通知サービス方法およびシステムに関し、特に、広域ネットワーク上に分散配置された複数のサーバサイト、もしくはデータセンタを経由して、イベント通知をサービスするための方法およびシステムに関する。また、かかるサービスを提供する情報処理装置及びプログラムに関する。

（パブサブについて）
非特許文献１にあるように、publish/subscribeとよばれるメッセージング方法（略してpub/sub（パブサブ））では、ユーザが興味のあるイベント情報に一度subscribeしておくと、つまり、申し込んでおくと、その状態を解除しない場合に限り、そのイベントが生成される度に、そのイベントにsubscribeしている全てのユーザ（subscriber）にイベントが通知される。

ここで、subscribeするために転送されるメッセージをsubscription、発生したイベントのメッセージをpublication、subscriber（ユーザ）に通知されるメッセージをnotificationと呼ぶ。これは通常のウェブ（Web）コンテンツのような一つのrequestに対して一つのresponseを返すと言ったステートレスなメッセージング方法とは対照的である。

上記パブサブの対象となるものは広範に及ぶ。例えば、SNSにおけるあるメンバーのWebページの更新を、友人である他のメンバーに通知する。ある銘柄の株価が閾値を超えたらそれを通知する、等がある。

（スケーラブルなパブサブシステムについて）
非特許文献１にあるように、より多くのpublisher（イベント発行者）とsubscriber（ユーザ）の間で効率よくメッセージを転送できるようにするために、両者の間に一つもしくは複数のbroker（中継者）が入る。Broker同士は物理リンク、もしくはIP網等のアンダレイ網によって繋がっており、brokerレベルのネットワークはオーバレイ網とも呼ばれる。

brokerの間におけるメッセージnotificationの転送は、予めsubscriptionの受信により登録されているsubscription情報に照らし合わせて次に転送すべきノードもしくはsubscriberを決定する。このことをランデブー処理と呼び、それを行うbrokerは特にランデブーポイントとも言われる。

ここで、どのsubscriber（ユーザ）がどのpublisher（イベント発行者）が発生するイベントにsubscribe（申し込み）したいのかを示すトポロジーを「関心トポロジー」と呼ぶことにする。また、publicationをsubscriber（ユーザ）に分配・転送するトポロジを「分配トポロジー」とよぶことにする。「分配トポロジー」は、broker（中継者）間をつなぐ物理リンク、もしくはオーバレイネットワークが提供する論理リンクで与えられる。

ランデブーポイント間の関係を示すトポロジーを「ランデブートポロジー」とよぶ。「ランデブートポロジー」が他の２つのトポロジーとどういう関係にあるかによって、これまでの技術は分類できる。

非特許文献２：SIENAでは、ランデブートポロジーは分配トポロジーと一致している。すなわち、publisher（イベント発行者）から将来publish（発行）するpublicationを指定する情報であるアドバータイズメントが分配木等によって各ノードに転送され、その逆経路として、subscriptionを転送するためのsubscription転送テーブルが設定される。さらにこのテーブルに基づいてsubscriber（ユーザ）からのsubscriptionがランデブーポイントで順次転送されると、その逆経路として、各ランデブーポイント上でnotificationを転送するためのnotification転送テーブルが設定される。

しかし、これでは分配トポロジーを、障害迂回もしくは性能最適化のために再構成した場合に、各ランデブーポイントにおける２種類の転送テーブルを全て再構成する必要があり、これは容易ではない、という課題がある。

（ランデブートポロジーと分配トポロジーの分離）
上記の課題を解決するものとして、ランデブートポロジーを関心トポロジーと一致させることで、分配トポロジーを独立させ、その再構成をしやすくしたものとして、非特許文献３−６（Xcast+, DOM, LIPSIN, MEDYM）がある。より具体的には、notificationの宛先のbroker（中継者）を決定するランデブー処理は、publisher（イベント発行者）を収容するbrokerのみで行われる。そして決定にもとづいた情報をnotificationに埋め込み、その転送は独立な手順で状況に応じて最適に構成された分配トポロジーに基づいて行う。

非特許文献３−４（Xcast+, DOM）は、IPマルチキャストに関するものであるが、pub/subとは以下の点で類似している。すわなち、マルチキャストグループへの代表ルータの加入・離脱は関心トポロジーに対応する。そして、マルチキャストグループ内の代表ルータにむけたIPパケットのマルチキャストが、分配トポロジーによるnotificationの全subscriber（ユーザ）への分配に対応する。なお、上記文献において、マルチキャストの分配経路は、マルチキャストグループの管理とは独立な、ユニキャストルーティングに基づいて決定される。

非特許文献９のようなIPマルチキャストアーキテクチャにおいては、各ルータにおいて、ソース端末を収容する代表ルータとマルチキャストグループの組合わせ毎に転送状態を保持すると、転送テーブルサイズが大きくなってしまうのに対処するため、非特許文献３−４（Xcast+、DOM）では次のような改造がおこなわれている。すなわち、それぞれ、分配木を構成する全リンクのリスト、もしくはマルチキャストグループに加わっている代表ルータのリストをIPパケットに挿入して、マルチキャスト経路上の各ルータは、その各アドレスを経路テーブルで参照して、一つもしくは複数の次ホップのルータを決定するといういわゆるソースルーティングを行っている。ここでは各次ホップルータにおくるべきパケット内では、そのルータにユニキャスト経路テーブル上でマッチした代表ルータのアドレスリストが加えられる。

非特許文献４：DOM（Destination Oriented Multicast）では、Xcast+が宛先代表ルータのリストをIPパケットにそのまま埋め込むと、代表ルータ数に比例してオーバヘッド（もしくは帯域消費）が大きくなるという問題に対処するため、宛先代表ルータリストをBloom filter化してオーバヘッドを代表ルータ数によらず固定長化している。

非特許文献５：LIPSINも非特許文献３−４と同じように、Bloom filterをもちいたソースルーティングの仕組みをnotificationの分配に使っている。これは、非特許文献３−４（Xcast+、DOM）が宛先代表ルータのリストを使うのとは違って、publisher（イベント発行者）を収容するbroker（中継者）をルーツとし、subscriber（ユーザ）を収容しているbroker（中継者）を含む分配木を構成したときのリンクIDをBloom filter化して、それを転送すべきnotificationに埋め込んでいる。これにより、分配木が再構成されたときのみならず、subscriber（ユーザ）収容のbroker（中継者）に加入・離脱があった場合でも、それを反映した新たなBloom filterを挿入するだけで済む。

非特許文献６（MEDYM）では、非特許文献３（Xcast+）と同じく、転送すべきnotification内に宛先broker（中継者）のリストを埋め込んでいる。ここでは、次に転送すべきサイトは、上記文献がユニキャストルーティングに基づいて決定するのとは異なり、broker（中継者）がnotificationを受信するたびに、自らがルーツとなりさらに宛先リストに含まれるsubscriber（ユーザ）ノードのみを含む最適分配木を作り、それに基づいて、次ホップノードとそれにより到達できる宛先ノードを決定する。

（Brokerのスケールアウトに関する技術）
ここで、Broker（中継者）網におけるBS（Broker Server）の総数Nを単純に増やしていくと、次の問題が生じる。すなわち、分配木を動的に構成するための仮想リンク総数はO(N²)となり、分配木を最短パスツリー（SPT）を与えるダイクストラのアルゴリズムで作る際の計算量はO(N³)となる。

この問題を解決するため、非特許文献６（H-MEDYM）では以下のような階層構成化をオフラインで行っておく。すなわち、複数のノードをまとめてクラスタとする。そして、各クラスタにおいて、例えばイベントソースに付与される識別子の空間を分割してできるサブスペース毎にmatcherノードを割当て、クラスタ間では全Matcherの割当て情報を配置し、クラスタ内ではmatcher以外のノードに、サブスペース毎のmatcherの情報を配置しておく。動作として、異なるクラスタ間でのメッセージ転送はmatcherノードが行い、クラスタ内はmatcherから他のノードに転送する。

（Consistent hashing）D. Karger, E. Lehman, T. Leighton, M. Levine, D. Lewin, and R.Panigrahy, Method and apparatus for distributing request among a plurality ofresources, United States Patent 7,127,513 October 24, 2006. （Inter DC networking）特願2010-196416「データ転送システム」

P. Eugster, P. Felber, R. Guerraoui, and A.-M. Kermarrec,"The manyfaces of publish/subscribe,"ACM Computing Surveys, vol. 35, no. 2, June 2003,pp.114-131. （SIENA）A. Carzaniga, D. Rosenblum, and A. Wolf, "Design and evaluation of awide-area event notification service," ACM Transactions on Computer Systems, vol.19, no. 3, pp. 332-383, 2001. （Xcast+）M. Shin, Y. Kim, K. Park, and S. Kim,"Explicit multicast extension(Xcast+) for efficient multicast packet delivery,"ETRI Journal, vol. 23, no. 4,Dec. 2001. （DOM）X. Tian, Y. Cheng, and X. Shen, "DOM: a scalable multicast protocolfor next-generation internet," IEEE Network, July/August 2010. （LIPSIN）P. Jokela, A. Zahemszky, C. E. Rothenberg, S. Arianfar, and P.Nikander, "LIPSIN: Line speed publish/subscribe inter-networking,"SIGCOMM 2009. （MEDYM）F. Cao and J. Singh, "MEDYM: Match-early with dynamic multicast for content-basedpublish-subscribe networks,"Middleware 2005. （TRIAD）M. Gritter and D. Cheriton, "An architecture for content routing support in the internet," USENIX 2001. （NNC）V. Jacobson, D. K. Smetters, J. D. Thornton, M. Plass, N. Briggs, R.L. Braynard, "Networking named content," ACM CoNEXT 2009. （SSM）RFC 3569 - An overview of Source-Specific Multicast (SSM)http://tools.ietf.org/html/rfc3569

しかしながら、上記非特許文献４，５（DOM, LIPSIN）のようにマルチキャストでの転送先をBloom filterの形式で処理して、転送処理の高速化をはかる方法では、偽陽性（あるリンクが間違って転送先グループに入ると判断する）の性質をもち、本来転送すべきではないノードにメッセージが転送されてしまう可能性があるという問題がある。
また、上記非特許文献６（MEDYM）ではbroker（中継者）がメッセージを受信する毎に、自分と宛先brokerのみを含むbrokerの間で最適化問題を解いて転送先brokerを決定するため、転送処理が高速化できない、また、転送先が全体最適化されているとは限らないという問題がある。

このため、本発明の目的は、上述した課題である、イベント通知サービスにおけるイベント通知の転送を高速化できないことを解決する、ことにある。

本発明の一形態であるイベント通知サービスシステムは、
イベントを発行するイベント発行サーバと、
前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備え、
前記中継サーバは、
前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルと、
前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送するメッセージ転送手段と、を備えた、
という構成をとる。

また、本発明の他の形態である中継サーバは、
イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する中継サーバであって、
前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルと、
前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送するメッセージ転送手段と、を備えた、
という構成をとる。

また、本発明の他の形態であるプログラムは、
イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送すると共に、
前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルを備えた中継サーバに、
前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送するメッセージ転送手段、を実現させるためのプログラムである。

また、本発明の他の形態であるイベント通知サービス方法は、
イベントを発行するイベント発行サーバと、
前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備えたイベント通知サービスシステムにて、
前記中継サーバが、
前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルを備えると共に、
前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送する、
という構成をとる。

また、本発明の他の形態であるイベント通知サービスシステムは、
イベントを発行するイベント発行サーバと、
前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備え、
少なくとも前記中継サーバを複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されており、
前記中継サーバは、前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送するメッセージ転送手段を備えた、
という構成をとる。

また、本発明の他の形態である中継サーバは、
イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する中継サーバであって、
少なくとも前記中継サーバを複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されており、
前記中継サーバは、前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送するメッセージ転送手段を備えた、
という構成をとる。

また、本発明の他の形態であるプログラムは、
イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する中継サーバを、少なくとも複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されており、
前記中継サーバに、
前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送するメッセージ転送手段、を実現させるためのプログラムである。

また、本発明の他の形態であるイベント通知サービス方法は、
イベントを発行するイベント発行サーバと、
前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備えると共に、
少なくとも前記中継サーバを複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されたイベント通知サービスシステムにて、
前記中継サーバが、前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送する、
という構成をとる。

本発明は、以上のように構成されるため、これによると、イベント通知サービスにおけるイベント通知の転送を高速化することができる。

実施形態１におけるシステム全体の構成を示すブロック図である。 図１に開示したサイトの構成を示すブロック図である。 図２に開示したEPSの構成を示すブロック図である。 図２に開示したBSの構成を示すブロック図である。 図２に開示したNRSの構成を示すブロック図である。 図３ｂに開示したBSが記憶する転送テーブルの説明図である。 BSのメッセージ処理手段によるpublication転送処理を示す流れ図である。 BSのメッセージ処理手段によるnotification転送処理を示す流れ図である。 BSのメッセージ処理手段による親BSから受取ったsubscription転送処理を示す流れ図である。 BSのメッセージ処理手段によるユーザから受取ったsubscription転送処理を示す流れ図である。 図２に開示したNRSが記憶する経路テーブルの説明図である。 図２に開示したNRSが記憶するＢＳ割当てテーブルの説明図である。 NRSの名前解決手段の動作を示す流れ図である。 NRSの名前解決手段の動作を示す流れ図である。 本発明の実施例として、ユーザ端末からオリジンサイトまでのSubscription転送における一連の動作を示す図である。 本発明の実施例として、オリジンサイトからユーザ端末までのPublication/notificationにおける一連の動作を示す図である。

＜実施形態１＞
本発明の第１の実施形態を、図１乃至図１２を参照して説明する。

まず、図１を参照して、本発明であるイベント通知サービスシステムの全体構成について説明する。イベント通知サービスシステムは、情報ソース（１０４等）、ユーザ（ユーザ端末２０１等）、サイト（３０１等）、コア網４、アクセス網（５０１等）とからなる。

上記「情報ソース」は、イベントを生成する元となる情報を生成もしくは提供するものである。この情報ソースとそれを収容するアクセス網（５０１等）との組合わせの具体例としては、無線センサー網５０４（アクセス網）につなげて発電量を監視したい太陽光発電装置１０４（情報ソース）、同じく蓄電量を監視したい２次電池（情報ソース）、LTE/3G網５０３，５０６（アクセス網）につながってバッテリーの充電状態（state of charge、以下SOCと略す）等を監視できるEV（電気自動車）１０３，１０６（情報ソース）、インターネット（アクセス網）につながって視聴状態を監視できるTV（テレビジョンセット）１０５（情報ソース）等がある。

そして、上記「情報ソース」は、イベント通知サービスを受けたいユーザからの要求に基づいて、イベント発行サーバである「EPS」によって、対応するオリジナルURIが付与される。なお、情報ソースは、上述したものに限定されない。

上記「ユーザ」は、イベント通知サービスの利用者であり、そのユーザが使用する機器であるユーザ端末の例としては、PC（パーソナルコンピュータ）２０２，２０８、もしくはスマートフォン２０１，２０７がある。但し、ユーザ端末は、上述した機器に限定されない。

上記「コア網」４は、複数のサイト間にデータ転送機能を提供する。その例としては、自営専用網、広域イーサネットといった仮想専用網、グローバルインターネットがある。そして、上記「アクセス網」（５０１等）は、上記コア網４に接続されており、情報ソース、ユーザをサイトに収容する。

上記「サイト」は、イベント通知サービスを可能とする各種機能をソフトウェアで実現するためのサーバマシーンを複数台設置する場所であり、その例としては、ネットワークオペレータのNOC（ネットワークオオペレーションセンタ）もしくはデータセンタがある。

次に、図２を参照して、「サイト」内の構成について説明する。なお、ここでは、サイトの一例として、符号３０２に示すサイトを一例に挙げて説明するが、他のサイトも同様の構成である。

図２に示すように、サイト３０２は、NRS（名前解決サーバ（アドレス解決サーバ））６と、BS（ブローカーサーバ（中継サーバ））７と、EPS（イベント発行サーバ）８と、サイト内網９とを含む。

上記NRS６は、サイト間で、イベントの発行により通知されるメッセージである「notification」（イベント）を低遅延で転送するための分配木を動的に再構成し、また、サイト内でnotification、ユーザからのイベントの通知依頼であるsubscription（通知依頼）を転送すべきBS７を割当てるために、転送用URIからBS７のアドレスを解決して要求のあったBS７もしくは他のNRS６に応答する、という機能を果たす。

上記BS7は、ユーザもしくは他のBS７からsubscriptionを、EPS６を収容するサイトのBS７まで転送し、またEPS６からBS７およびユーザまでnotificationを配信（転送）する機能を果たす。

上記EPS８は、SGW（Service Gateway）から定期的もしくはイベントベースで間欠的に送られる実時間データを処理して、ユーザに配信すべき情報としてのイベントを発行する。ユーザからのイベント配信サービスに関する要求に基づいて監視対象を識別するためのオリジナルURIを生成して提供する。アクセス網独自のデータ転送、メッセージ転送プロトコルを終端して、EPS,BS等の間の間で使われるシステム共通のプロトコル（例えば、HTTP）に変換する機能を果たす。

また、サイト内網９は、１つのコア網４、および１つ以上のアクセス網５と繋がっている。以下、上述した各構成要素の構成と動作について詳細に説明する。

（EPS）
EPS８の構成について説明する。図３ａに示すように、EPS８は、サービスポータル手段２０、publications生成送出手段２２、イベント管理テーブル（以下「emTBL」と略す）２１、を含む。

上記サービスポータル手段２０では、ユーザ（ユーザ端末２０１等）からイベントサービスポータルにアクセスがあったら、ユーザがユーザ端末２０１等のブラウザ上等から入力したイベント通知を受けるための条件等もとづいて、「オリジナルURI」と、イベント通知を受けるための条件を記述したものである「filter」と、を生成して、ユーザに応答する。ここで、「filter」は、各監視項目の制約条件に対する論理式で与えられる。例えば、電気自動車において、監視項目の例としてはSOCと任意の電気スタンドからの距離がある。また、filterは次のように書ける。
(SOC)<10% and (distance from any stand)<2.0km

次に、サービスポータル手段２０は、EPS８が属する同一のサイト内のローカルNRS６に指示して、オリジナルURIからpublicationの送出先である出口となるBS７（出口BS）のアドレスを解決する。その後、監視項目と、filterと、NRS６に要求してオリジナルURIから解決させた出口BSのアドレスと、をemTBL２１に格納する。

emTBL２１は、オリジナルURIと、filter内に含まれるデータの内容（attribute）に対応する監視項目と、同じURIに対する各サイトからのfilter全体をカバーするfilterと、publicationを送出すべき出口BSと、のアドレスの組合わせを含む。

Publication生成・送出手段２２は、オリジナルURIに対応する各情報ソース１から、登録されている監視項目に関するデータを連続的、もしくは断続的に取得し、監視項目の組合わせの実現値、例えば
(SOC)=15% and (distance from stand8)=0.5km
がイベント管理テーブルに登録されているfilterにマッチする場合は、publicationを生成する。ここで、マッチするとは、実現値がfilter内の論理条件を満たすことを指す。

こうして、EPS８が情報ソースから連続してデータを受取っていても、その値が全サイトからのfilterをカバーするfilterを通過できる場合だけ、publicationを生成して転送するので、出口BSでは後述するマッチング処理手段にかかる負荷が削減される効果がある。

また、上記サービスポータル手段２０は、提供しているサービスドメインの到達性の広告を行い、下記のようなpublicationを生成して、転送する。
POST http://a435667.provider.net/ServAdv/EPS1/notification/
<Body>
Service name: EVmon
Origin site name： site1, site2

ここで、a135667のアノテーションaは、これがadvertisementであることを示す。35667はprovider.net/ServAdv/EPS1をハッシュして得た値であり、先頭の数字である1はサイト１でハッシュされたことを示す。HTTPメッセージ本体は、EVmonというサービス名がサイト２、サイト２から提供されることを示す。

（BS）
BS７は、図３ｂに示すように、マッチング手段１５と、サイトsubscriptionテーブル（以下ssTBLと略す）１６と、ユーザsubscriptionテーブル（以下usTBLと略す）１７と、メッセージ転送手段１８と、転送テーブル１９と、を含む。

上記ssTBL１６は、他のBS７から自BS７に送られるsubscriptionに含まれる転送用URIと、同一の転送用URIにsubscribeしているユーザが属するサイト名と、そのfilterと、を登録するものである。

上記usTBL１７は、ユーザからBS７に送られるsubscriptionに含まれるオリジナルURIと、同一のオリジナルURIにsubscribeしているユーザIDと、そのfilterと、を登録するものである。

ここで、上記「filter」とは、監視項目とその実現値との間の関係式をANDで並べたて得られる論理条件で、ユーザの関心を表すのに使われる。これは例えば、EVについて次のように記述される。
(SOC) <10% and (distance from any stand)<2km

上記マッチング手段１５は、後述するメッセージ転送手段１８から駆動され、与えられたオリジナルURIもしくは転送用URIに対して、ssTBL, usTBLを参照して、マッチするsubscriber（ユーザ（ユーザ端末））を抽出する。マッチング手段１５は、一般に処理負荷が高いので、一つのBS７内に閉じて実現する以外に、複数のサーバマシーン上で実現する場合もある。この場合、ssTBL、usTBLを分割してこれらのサーバ上に配置して、それぞれに同一のattributeを含むマッチング処理要求をマルチキャストし、分割されたTBL上でマッチするsubscriberがあったらサーバからそれを含む応答を受取る形で、マッチングの並列処理を行うことで、マッチング処理速度を向上させてもよい。

上記転送テーブル１９は、図４に示すように、イベントを発行する上記EPS８が属するサイトである「オリジンサイト名」及びそのイベントを識別するイベント識別情報である「イベントソースID」からなる「転送キー」と、自己のBS７からsubscriptionの転送先となるBS７のアドレスである「subscription転送用子BSアドレス」と、自己のBS７から到達可能なサイトを表す「宛先サイト名」と、自己のBS７からnotificationの転送先となるBS７のアドレスである「notificatoin転送用子BSアドレス」と、が関連付けられた組合わせをエントリーにもつ。このように、転送テーブル１９には、転送キー毎に、subscriptionとnotificationでそれぞれ独立に区別して、次の転送先となる次ホップの他のBS７のアドレスが登録されることで、両者はそれぞれ別々の経路を設定することが可能となる。

上記メッセージ転送手段１８は、転送用URIから次ホップのBSアドレスに解決することで、その次ホップのBSにメッセージを転送する。

ここで、PIMのような、IPルータに、マルチキャストソース毎の状態をもつのはスケーラビリティに問題があるとしていたが、それはIPルータがもつメモリサイズが一般に小さかったことに起因する。本発明では、汎用サーバマシーン上のメモリサイズが拡大傾向にあるので、上記のようにnotificationとsubscriptionの経路を独立に設定するための転送テーブルを導入しても、スケーラビリティの問題は生じない。

本発明では、こうして、監視対象となるイベントチャネルはURIで指定し、その監視項目から得られる値を条件付けるfilterはHTTPメッセージ本体に記述することで、コンテンツベースとサブジェクトベースのsubscriptionを統一的に扱えるようにしている。

次に、図５乃至図７を参照して、BS７におけるメッセージ転送手段１８の動作について説明する。図５は、publicationの転送処理の動作を示す流れ図である。BS７は、ローカルEPS８よりpublicationを受信したら（ステップＳ９）、ssTBLにマッチするsubscriptionがあるかどうか調べ（ステップＳ１０）、ない場合（ステップＳ１０でＮｏ）は終了する。ある場合（ステップＳ１０でＹｅｓ）は、マッチしたsubscriptionに後述するように登録されているsubscriberサイト名（宛先サイト情報）に自サイトがある場合に限り、マッチング手段１５を駆動してusTBL上でマッチするユーザにオリジナルURIが入ったnotificationを生成して転送する（ステップＳ１１）。次に、マッチしたsubscriptionに登録されているsubscriberサイトに自サイト以外があるかどうか調べ（ステップＳ１２）、ある場合（ステップＳ１２でＹｅｓ）は、オリジナルサイトに自サイト名を入れた「転送用URI」と、マッチしたsubscriptionに登録されているsubscriberサイトのうち自サイト以外のサイト名を含む「宛先サイトリスト」と、必要に応じて「宛先リスト変更フラグ」と、を含むnotificationを作成して、図６のステップＳ３に進む（（ステップＳ１３）。ステップＳ１２で、マッチしたsubscriptionに登録されているsubscriberサイトに自サイト以外が無い場合は終了する。

ここで、上記「宛先リスト変更フラグ」は、EPS８に対してsubscribeするユーザsubscriber（ユーザ端末２０１等）の数が変化した場合に、当該EPS８から通知を受け、BS７がnotificatoin」に設定する。また、BS７は、他のBSがシステム内に追加されるなど後述するNRS７が記憶する経路テーブル１１が変更され、その旨の通知をNRS７から受けた場合には、上記転送テーブル１９に記憶されているデータを削除する機能も有する。

なお、図５には示されていないが、publication内のURIのサービス名を示す部分にAdvsrvが入っている場合は、これはadvertisementなので、ssTBLを参照することはなく、Destinationはall sitesとする。すなわち、advertisementをnotificationで送るときのフォーマットの概要は、下記のようになる。
POST http://site1.e135667.provider.net/ServAdv/EPS1/notification/
Destination: all sites
<Body>
Service name: EVmon
Origin site: site1, site2

図６は、notificationの転送処理の動作を示す流れ図である。BS７は、親BS７よりnotificationを受信したら（ステップＳ１）、このnotificatoinに含まれる宛先サイトリストに自サイトが入っている場合に限り、マッチング手段１５を駆動してusTBL上でマッチしたユーザにオリジナルURIを含むnotificationを生成して転送する（ステップＳ２）。次に、宛先リスト変更フラグが立っている場合に限り、notificatoinに含まれる転送キーに対応するエントリーを、転送テーブルから削除する（ステップＳ３）。

次に、転送テーブル１９に転送キーがあるかどうか調べ、転送テーブル１９に転送キーがある場合は、ステップＳ５に進む。転送テーブル１９に転送キーがない場合は、NRS６に転送用URIと、ルーツサイトとしてオリジンサイトと、子孫サイトとしてnotification内の宛先サイトリスト（宛先サイト情報）と、を送って、子BS群への名前解決し、応答結果を転送テーブル１９に登録してステップＳ５に進む（ステップＳ４）。これにより、後述するように、notificatoin内に子孫サイトとして登録されている宛先サイトリスト（宛先サイト情報）の各サイトに到達可能なサイトのBS7のアドレスが、次ホップとして転送テーブル１９に、転送キーに対応して登録される。ステップＳ５では、転送テーブル１９内でマッチする転送キーに対応して登録されている各次ホップとなるＢＳのアドレス毎に、宛先サイトリストをコピーしたnotificationを複製して転送し、終了する。

図７は、subscription転送処理の動作を示す流れ図であり、図７ａは他のBSである親BSからsubscriptionを受信したときのBS７の動作を示している。親BSからsubscriptionを受信したら（ステップＳ２１）、このsubscriptionに含まれるイベント通知を依頼するEPS８が属するサイトであるオリジンサイト名が、自サイトかどうか調べる（ステップＳ２２）。オリジンサイト名が自サイトでない場合は（ステップＳ２２でＮｏ）、転送テーブル１９内に受信したsubscriptionに含まれる転送キーに対応するエントリーがない場合に限り、転送用URIとルーツサイトを自サイト名にしてNRS６に問合せて子BSアドレスへ解決し、応答結果を転送テーブルに登録する（ステップＳ２４）。次に転送テーブル１９を参照してsubscriptionを子BSへ転送する（ステップＳ２５）。

上記ステップＳ２でオリジンサイトが自サイトである場合は（ステップＳ２２でＹｅｓ）、ssTBLに同じsubscriberサイトであるsubscriptionの登録が無い場合は、subscriptionに含まれるsubscriberサイト名を宛先サイト情報として登録する（ステップＳ２３）。ssTBLに同じsubscriberサイトであるsubscriptionの登録がある場合は、受信したsubscriptionのfilterがカバーできない場合に限り、当該filterを登録する。そして、URIについて次ホップとなるEPS８のアドレスのエントリーが無い場合に限り、ローカルNRS６に要求してEPS８のアドレスへ解決し、転送テーブルに格納する。次に同じURIに対して登録されているサイトsubscriptionをカバーできるfilterが無い場合に限り、転送テーブルを参照してそのfilterをEPSに送る。

図７ｂは、ユーザからsubscriptionを受信した場合のBS７の動作を示している。ユーザからsubscriptionを受信すると（ステップＳ３１）、usTBLにオリジナルURIとユーザアドレスを登録する（ステップＳ３２）。次に、マッチング手段１５を駆動してusTBLにカバー可能なユーザsubscriptionがあるかどうか調べ（ステップＳ３３）、ある場合は（ステップＳ３３でＹｅｓ）、終了する。ない場合は（ステップＳ３３でＮｏ）、オリジンサイト名が自サイトかどうか調べ（ステップＳ３４）、そうである場合は（ステップＳ３３でＹｅｓ）、ssTBLにsubscription内にあるURIと、サイトsubscriberとして自サイトと、そしてfilterと、を登録し（ステップＳ３５）、終了する。

ステップＳ３４で、オリジンサイト名が自サイトで無い場合は（ステップＳ３４でＮｏ）、NRS６に問合せてオリジナルURIを一つもしくは複数の転送用URIに解決する。そして、個別の転送用URIについて、転送キーが転送テーブルに無い場合に限り、再度NRS６に問合せてオリジナルURIから一つもしくは複数のオリジンサイトと、転送先子BSアドレスへ解決し、転送キーと子BSアドレスの組合わせを転送テーブルに登録する（ステップＳ３６）。次にユーザから受信したsubscriptionにおいて、転送テーブルを参照してオリジナルURIを各転送用URI毎に書き換え、ルーツサイトを自サイトに書き換えたsubscriptionを、異なるオリジンサイト毎に作成し、それぞれを転送テーブルを参照して対応する子BSへ転送する（ステップＳ３７）。

以上により、新しいsubscriptionやnotificationであっても、対応する転送キーが転送テーブルで見つかる限りは、NRS６に名前解決要求することなく、直ちに次ホップとなるBS７に転送できる。これと同時に、notificationとsubscriptionとは転送テーブル上で次ホップが独立に登録され、互いに独立に最適な経路上を転送することができる。

なお、図７には記載されていないが、advertisementを示すイベントソースID、例えばアノテーションとしてaをつかってa144555としたものを含むnotificationを受取った場合は、宛先サイトに指定されたサイトに必ず加えてローカルサイトのNRS６に転送する。

（NRS）
NRS６は、図３ｃに示すように、経路テーブル作成手段１０と、名前解決手段１２と、経路テーブル１１と、BS割当てテーブル１３と、名前到達性テーブル１４とを含む。

上記経路テーブル作成手段１０は、他のサイトのNRS６との間で、ネットワーク等の状態を監視し、それにより得られた情報に基づいて、自サイトから他の全サイトにメッセージを転送するための最適な全域分配木を構成して、経路テーブル１１を作成する。

上記BS割当てテーブル１３のエントリーには、BS７が記憶する転送テーブル１９と同じく宛先サイト名のリストを含むが、当該転送テーブル１９には全ての子孫サイトが含まれる。一方で、NRS６のBS割当てテーブル１３には、notificationに挿入されている宛先サイトに対応する子孫サイトしか含まれない。このテーブルは、経路テーブルが更新されると、全エントリーがクリアされる。

この最適な全域分配木の構成法の詳細については、特許文献２に示されるような集中型と分散型の方法がある。集中型の方法で自分がルーツとなる最適な全域分配木を構成したのち、経路に変更があった場合、各サイトへバージョン情報とともに経路情報をプッシュ配信する。分散型の方法では、各NRSは、自分および他のサイトのNRS毎に、それぞれをルーツとする最適な分配木を作成して、それに基づいて経路表を作成する。

最適な分配木の構築方法の一つとして、ダイクストラのアルゴリズムで得られるような最短パスツリー（SPT）がある。ここでは、NRS間で往復遅延(RTT:round trip time）もしくは要求タイムスタンプをpinger側で、応答タイムスタンプをpingeer側で書き込むことにより、片方向遅延OWDを測定することができる。これらを分配木における各エッジ（サイト間のリンク）の距離として、ダイクストラのアルゴリズムを適用して分配木を算出する。これはOSPF, IS-IS等で用いられているリンクステートプロトコルと同じ原理である。なお、NRS６は分配木を適宜算出して経路表に変更があったら、同じサイトにある各BS７に指令して、その転送テーブル１９をクリアさせる。

図８は、経路テーブル１１の構成を示している。この経路テーブル１１は、自サイトに対する転送元となるサイトを表すルーツサイト名、ルーツサイトできまる分配木上での自サイトからみた親サイトのNRSアドレス、自サイトから到達可能なサイトを表す子孫サイト名（サイト識別情報）、子孫サイトに分配木上で到達するための子サイトのNRSアドレス（解決サーバアドレス情報）、の組合わせのエントリーを含む。親NRSのアドレスは、前提となった分配木上の妥当な親NRSから問合せを受け取ったかどうかチェックするために使う。妥当でない場合は、解決不可を応答する。

図９は、BS割当てテーブル１３の構成を示している。これはsubscriptionおよびnotificationの転送に関する名前解決に用いられる。subscriptionに関しては、各転送キーについて、子BSアドレスと、自サイトの出口BSアドレスとを保持している。同じくnotificationに関しては各転送キーについて、到達可能な子孫サイト名、それらのサイトに到達するための子サイトのBSアドレスと、自サイトの入口BSアドレスとを保持している。

出口BSアドレスは、NRS６がEPS８からの要求でオリジナルURIを割当てた際に書き込まれ、自分が出口サイトであるNRS６が、subscriptionに対する名前解決要求に対して、応答するのに用いられる。一方、入口BSアドレスは、ユーザがsubscriptionを転送する際の、名前解決要求に基づいて割当てられ、自分が入口サイトであるNRS６が、notificationに対する名前解決要求に対して、応答するのに用いられる。このために、ローカルNRSからリモートNRSへの名前解決要求には、転送用URIに加えて、転送メッセージの種類（subscriptionかもしくはnotification）を含ませる。

上記名前解決手段１２では、他のサイトのEPSから受信した名前到達性情報を名前到達性テーブル１４に格納する。また、URIからBSアドレスへの解決のために必要となる解決要求の送出、解決応答の作成と送出を含む手順を実行する。名前解決要求・応答のメッセージでは少なくとも、１つの転送用URI、１つのルーツサイト、１つもしくは複数の子孫サイトの３つの項目を含む。後２者は、経路テーブルでマッチングされ、次ホップNRSのアドレスが決定される。

次に、図１０ａ、図１０ｂの流れ図を用いて、NRS６の名前解決手段１２における動作について説明する。図１０ａにおいて、subscriptionを転送したいローカルBS７から、転送用URIと、ルーツサイトとしてsubscriberサイト名と、子孫サイトとしてオリジンサイトと、をそれぞれ含む次ホップBSへの名前解決要求があったら（ステップＳ４５）、BS割当てテーブル１３に転送キーのエントリーがない場合に限り、経路テーブル１１上で、ルーツサイト名をsubscriberサイト名で、オリジンサイトを宛先サイトで引いて得られる次ホップNRS６に対して、転送用URIを含む名前解決要求を出して、応答を受け取ったらBS割当てテーブル１３に登録する（ステップＳ４６）。次にBS割当てテーブルを参照してローカルBSへ、転送用URIと割当てた次ホップBSを返答して（ステップＳ４７）、終了する。

同様に、notificationを送りたいローカルBSから、転送用URIと解決要求サイトを含む子BSアドレス群への名前解決要求があったら、BS割当てテーブル１３を参照して、転送キーに対応するエントリーがない場合に限り、経路テーブル１１上でオリジンサイトをルーツサイトで引いて得られるすべての子NRSに、転送用URIを含む名前解決要求を出し、解決応答を受取ったらBS割当てテーブル１３に登録する。次に、BS割当てテーブル１３を参照して、１つもしくは複数のリモートBSと宛先リストの組合わせを、ローカルBSへ返答する。

図１０ｂにおいて、親NRS６からローカル（自サイトの）BS７への名前解決要求あったら（ステップＳ５１）、解決要求に含まれるルーツサイトで経路TBL１１を引いて、解決要求送信元のNRSアドレスが親NRSアドレスと一致するかどうか調べる（ステップＳ５２）。一致しない場合は（ステップＳ５２でＮｏ）、解決不可能応答を出す（（ステップＳ５６）。ステップＳ５２で一致した場合は（ステップＳ５２でＹｅｓ）、子孫サイトが自サイトであるかどうか調べ（ステップＳ５３）、そうである場合は（ステップＳ５３でＹｅｓ）、BS割当TBL１３を参照して、notification転送の場合はSubscription転送用ローカルBSアドレスを応答する。また、subscription転送の場合はNotification転送用ローカルBSアドレスを応答する（ステップＳ５５）。ステップＳ５３で子孫サイトが自サイトでない場合は（ステップＳ５３でＮｏ）、上記特許文献１で開示されているconsistent hashing等の手法によりローカルBSを割当ててBS割当TBL１３にキャッシュし、そのアドレスを応答する（ステップＳ５４）。

上記ステップＳ５２の判断を行う理由は、名前解決要求・応答が複数ホップにまたがって行われた場合に、経路表の変更がサイト間で同期しないこと等により、最終的にループが形成されることを防ぐためである。解決不能は名前解決要求を出した元のBSまで応答として戻り、その場合はメッセージを廃棄してもよい。

上記ステップＳ５５は、同じURIを含むnotification、subscriptionの転送において、入口BSおよび出口BSは一致していることを保証するためのものである。また、subscriptionの転送時に同じURIに対して割当てたBSが複数ある場合は、それをすべて応答することになる。よって、親BSは次ホップサイト内の複数のBSにnotificationをマルチキャストすることになる。

なお、図１０ａに示すように、subscriptionを送りたいユーザから転送用URIからローカルBSへの名前解決要求あったら（ステップＳ４１）、上記特許文献１で開示されているconsistent hashing等によりローカルBSを割当てBS割当TBLにローカルBSアドレスをキャッシュして応答する（ステップＳ４２）。

上記において、同一のURIをもつnotification転送等に関する負荷を同一サイト内にある複数のBSに分散するためには、ステップＳ４２において割当対象をそこから選ぶBSの集合は、加わっている負荷が予め与えられた閾値以下とするように限定してもよい。そのために、NRSは同じサイト内の各BSの死活および負荷を監視する必要がある。

また、図１０には記述されていないが、NRSは転送キー内のイベントソースIDにつけたアノテーションで識別される、advertisementを受信した場合は、名前到達性TBLに到達可能サービスドメイン名と、１つもしくは複数の提供サイト名との組合わせを登録する。

ここで、本発明におけるNRS６は、従来のDNS（ドメインネームサーバ）と同様に、名前をノードアドレスに解決するという点においては共通しているが、次に示す点で大きな差がある。すなわち、本発明におけるNRS６は、最適形成された分配木上において、メッセージ内に指定された宛先サイトが現在のNRSから到達可能な次ホップを決めている。一方、従来のDNSにおいては、次に問合せるべきDNSをURIに含まれる上位レベルのドメインのDNSサーバの指示に基づいて、次に問合せるDNSサーバを決定している。

＜実施例＞
次に本発明の実施の形態における実施例について説明する。図１１は、EV（電気自動車）の監視サービスに関するsubscriptionが生成されて監視サービスを提供するEPS８１を収容する出口BS７１まで転送される一連の動きを示している。

まず、ユーザ２１は、提供を受けたいイベント配信サービスに関する受付を行うEPS８１にアクセスして、EV１０３のイベント監視に対して、「v23406」のIDをもつEVのバッテリーのSOCが１０％未満、かつ任意の電気スタンドからの距離が２ｋｍ未満という条件を満たしたら、通知して欲しい旨を登録すると、イベント管理テーブルにオリジナルURIと監視対象を登録する（ｔ１）。EPS８１は、NRS６１にオリジナルURIで問合せして（ｔ２）、出口BS７１のアドレスの応答があると（ｔ３）、イベント管理テーブルに登録し、EPS８１では次の内容を含む応答メッセージを作成して、ユーザに返答する（ｔ４）。
入口NRSアドレス: w.x.y.z
POST http://e143359.provider.net/EVmon/v23406/sub/user
<Body>
Subscriber address: a.b.c.d
Filter: (SOC)<10%, (distance from any stand)<2km

上記において、入口NRSアドレスとは、ユーザ２１がこのオリジナルURIで指定されたサービスのメッセージを受取るためにアクセスすべきサイト４にあるNRS６４のアドレスである。これは、EPS８１がユーザのアドレス（上記ではa.b.c.d）等に基づいて例えばユーザに最も近いサイトの中から決定する。

オリジナルURIにおいて、「EVmon」はイベントサービス名、「provider.net」はサービスプロバイダ名、「v23406」は、「v」をアノテーションとして、EV１０３のIDが「23406」であることを示す。「e143359」の「143359」は、「e」がイベントソースIDであることを示すノーテーションである。そして「143359」は、EPS８１において「provider.net/EVmon/v23406/」をハッシュして「43359」が得られたとし、さらにそれが各サイトのEPS間で衝突しないように、その先頭にサイト番号「１」をつけて得られる。また、a.b.c.dはユーザのアドレスを示す。「Filter」とは、上述のようにユーザがイベントを転送して欲しい条件を示す。

次に、上記応答メッセージを「サイト１」にあるEPS６１から受取ったユーザ（ユーザ端末）２１は、上記の入口NRS６４に対して、オリジナルURI
e143359.provider.net/Evmon/v23406
から入口BSアドレスへの名前解決要求を送る（ｔ５）。入口NRS６４は、consistent hashing（特許文献１参照）等によりオリジナルURIからユーザにアクセスさせるべき入口BS７４を決定すると、そのアドレス「p.q.r.s」をオリジナルURIと共にユーザ２１に送る（ｔ６）。
e143359.provider.net/EVmon/v23406 p.q.r.s

すると、ユーザ２１は、前述の入口BS７４に、EPS８１から先に受信済みであるオリジナルURIと、ユーザ２１のアドレスと、EPS８１からフォーマットをもらったsubscriptionを、入口BS７４に送る（ｔ７）。このメッセージは次のようなフォーマットを含む
POST： http://e143359.provider.net/Evmon/v23406/sub/user
<Body>
Subscriber address: a.b.c.d
Filter: (SOC)<10%, (distance from any stand)<2km

次に、ユーザ２１からsubscriptionを受取った入口BS７４は、ローカルNRS６４にサービス名「EVmon」を送り（ｔ８）、NRS６４は名前到達性テーブルを参照して１つもしくは複数のオリジンサイト名に解決して応答を送る（ｔ９）。

次に、入口BS７４は、転送用URIを生成し、転送テーブル１９を参照して、転送用URIに対応する転送キーが無い場合は、転送URIと、ルーツサイトとして自サイト名と、子孫サイトとしてオリジンサイト名と、を含む名前解決要求を、ローカルNRS６４送る（ｔ１０）。そのフォーマットは次のようになる。
GET http://(NRS address)/NRS/ChildBS
<Body>
Transfer key: site1.e143359
Message type: notification (or subscription)
Root: subscriber site name (or origin site name in the case of
notification)
Descendent: origin site name (or DL in the case of notification)

ここで、「site1.e143359」は転送キーであり、「NRS」は名前解決サービスを示す。
次に、入口NRS６４は、自サイトをルーツサイトとし、URIのオリジンサイトを子孫サイトとして経路テーブル１１を検索して、子NRS６７のアドレスを引いたら、そこに上記の転送用URIから子BSアドレスへの名前解決要求を送る（ｔ１１）。そのメッセージは下記のURIを含む。
GET http://(NRS address)/NRS/ChildBS
<Body>
Transfer key: site1.e143359
Message type: Subscription (or notification)

その要求を受取った子NRS６７は、consistent hashing（特許文献１参照）を用いて、割当てるべきBSをBS７７に決定し、名前解決要求のあったNRS６４に返答する（ｔ１２）。これを受取ったNRS６４は、名前解決要求をしていたローカルBS７４に子BS７７のアドレスを返答する（ｔ１３）。

これを受取ったBS７４は、下記のようなサイト単位のsubscriptionを作成して、子BS７７に転送する（ｔ１４）。ここでsubscriptionは、転送制御を行う際のBS単位ではなく、経路制御を行うのと同じサイト単位で行う。ここで入口サイトは「サイト４」であるとする。
POST http://site1.e143359.provider.net/EVmon/v23406/sub/site
<BODY>
Subscriber name: site4
Filter: (SOC)<10%, (distance from any stand)<2.0km

subscriptionを受取った子サイトである「サイト７」にあるBS７７は、ローカルNRS６７、およびその子NRS６１との間で行われる上記と同様の手順を踏んで（ｔ１５〜ｔ１８）、転送用URIを出口BSであるBS７１のアドレスに解決し、subscriptionをそのまま出口BSであるBS７１に転送する（ｔ１９）。それを受取った、BS７１は、そのsubscriptionのオリジンサイトは自サイト（サイト１）なので、subscriptionに記載されたURIと、ユーザ端末が属するsubscriberのサイト名と、filterと、をssTBL１６に格納する。さらに同じsite subscriptionの URIに対する全てのサイトsubscriptionのfilterをカバーするfilterが更新された場合は、それを、ローカルNRSに名前解決させたEPS８１に送る（ｔ２０）。

なお、入口サイトのNRS６４は、上記ｔ１０の後、名前到達性TBL１４を参照して、「EVmon」のサービスが、「site１」のみならず、「site３」からも到達可能である、すなわち監視対象のEV１０３が、「site１」が収容するアクセス網のみならず、例えば「site３」が収容するアクセス網上にも現れる可能性がある場合は、経路TBL１１を検索して自サイトをルーツサイト、site３を子孫サイトとした場合の次ホップサイトのNRSを解決する。そして、そこへ下記のように作成した転送キー「site3.e143359」と、ルーツサイトとしての自サイトを、それぞれ含む名前解決要求を送って、次ホップサイトで割当てられるBSのアドレスに解決し、これも名前解決要求をしてきたBSへ応答する。それ以降は、BS７４でsubscriptionが生成され、「site１」まで転送されるのと同様の手順で、もう一つのsubscriptionがBS７４で生成され、「site３」まで転送される。

図１２は、EPS８１がpublicationを生成し、それを複数のBSがnotificationとして中継転送して、ユーザに届けるまでの一連の動きを示している。

ここで、EPS８１からのpublicationのメッセージの要旨は次のようになる。すなわち、publicationでは、オリジンサイト名を含まないオリジナルURIが含まれる。ここでは、情報ソースのEV１０３は、「v23406」のIDで識別されることを示している。またbodyは、そのバッテリーのSOCが5％であることを示している。
POST http://e13359.provider.net/EVmon/v23406/pub
<Body>
Attribute: (SOC)=5%, (distance from stand8)=0.5km

EPS８１は、オリジナルURIと監視値を含むpublicationを作成したら、イベント管理テーブルを参照して、オリジナルURIから解決されるBS７１にpublicationを送信する（ｕ１）。それを受取ったBS７１は、メッセージ転送手段１８のランデブー処理として、同一の転送用URIに対して、(SOC)=5% and (distance from stand8)=0.5km というfilterでssTBL１６を参照してマッチするsubscriptionを検索し、登録されている「site4,
site5」のsubscriptionにマッチしたので、下記のようなnotificationを作成する。
POST http://site1.e143359.provider.net/Evmon/v23406/noti
Destination: site4, site5
<Body>
Attribute: (SOC)=5%, (distance from stand8)=0.5km
ここで、destinationはnotificationのマルチキャスト転送のために新たに定義したHTTPヘッダである。

次に、出口BS７１は、ローカルNRS６１に転送キー（上の例ではsite1.e143359）と宛先サイトリスト（上の例ではsite4, site5）を送って、子BSアドレスへの解決を要求し（ｕ２）、ローカルNRS６１は、経路テーブル１１を参照して得られた２つの子NRS、すなわち「サイト７」のNRS６７，および「サイト５」のNRS６５に、転送用URIを送って、子BSアドレスへの名前解決を要求する（ｕ３）。そしてNRS６７およびNRS６５から、子BS７７および子BS７５のアドレスをそれぞれ受け取ったら（ｕ４）、転送用URIと、BS７７のアドレスと子孫サイト名としての「site4」、およびBS７５のアドレスと子孫サイト名としての「site5」を出口BS７１に返答する（ｕ５）。

これを受取った出口BS５１は、下記のように作成したnotificationを、子BS７７，７５にそれぞれ転送する（ｕ６）。
（１）
POST http://site1.e143359.provider.net/Evmon/v23406/noti
Destination: site4
<Body>
Attribute: (SOC)=5%, (distance from stand8)=0.5km
（２）
POST http://site1.e143359.provider.net/Evmon/v23406/noti
Destination: site5
<Body>
Attribute: (SOC)=5%, (distance from stand8)=0.5km

上記で（１）の内容をもつnotificationを受取ったBS７７は、ローカルNRS６７、さらに子NRS６４との間で同様の手順を行い（ｕ７からｕ１０）、「サイト４」の子BS７４にnotificationを転送する（ｕ１１）。それを受取ったBS７４は、宛先サイトが自サイトだけなので、usTBL１７を参照して、マッチするユーザがいたので、そこにnotificationを転送する（ｕ１２）。

以上のように、本発明のシステムによると、全サイトを含む経路テーブル１１から、転送すべきサイトのみを含む転送テーブル１９を構成し、メッセージの転送は転送テーブル１９に転送キーがある場合は、転送キーを転送テーブルに対してexactマッチングするだけで、転送先のBSと宛先リストが決定できるので、転送すべきメッセージに含まれる宛先に関する情報を、偽陽性の問題があるBloom filter化をしなくても、高速な転送が可能となる。これと同時に、notificationとsubscriptionとは転送テーブル上で次ホップが独立に登録され、互いに独立に最適な経路上を転送することができる。

また、URIに含まれるオリジンサイト名に基づいて、次にメッセージを転送すべき他のサイト内のBSのアドレスにURIを解決するための要求を転送する先のサイトを決定し、その要求を受けたサイトのNRSはURIのハッシングに基づいて割当てるBSを決定するので、各サイト内でのBSの増設は、サイト間で独立に行うことができる。このとき、また、notificationに含まれる宛先リストは、broker単位ではなく、サイト単位であるので、各サイト内のbroker数が増えても、宛先リストの大きさに影響を与えることは無い。また、転送テーブルにおいては、イベントソースID単位ではなく、まずオリジンサイト名でマッチングを行うので、各サイトのbroker数が増えても、転送テーブルの検索の探索オーダに直接的な影響は無い。

＜他の実施例＞
ここでは、場所がどこにあるかわからないが、ある情報発生体の状態更新を発見したいためには、次のようなワイルドカードを使ったsubscribeを行う。EVのある観測値に対するfilterを満たすものを通知して欲しい場合は、URIとして例えば次のようなものを用いる。オリジナルURIは、サイト１で生成されたとすると、
http://e134567.provider.com/EVmon/anyEVID

このEVmonというサービスを提供しているサイトがsite1,site3の場合は、以下の転送用URIが生成されて、それを含むサイトsubscriptionが各サイトに転送される。
http://site1.e134567.provider.net/EVmon/anyEVID/sub/site
http://site3.e134567.provider.net/EVmon/anyEVID/sub/site

Site3のEPSは、v89234, v45234から観測データが送られてきているときは、それをサンプリングしたデータを含み、かつ以下のオリジナルURIをそれぞれ含むpublicationを送出する。
http://e134567.provider.net/EVmon/v89234/pub
http://e134567.provider.net/EVmon/v45234/pub

これは、publication送出時に割当てられた出口BSによって、下記のようなオリジナルサイト名が付与された転送用URIに変換される。
http://site3.e134567.provider.net/EVmon/v89234/noti
http://site3.e134567.provider.net/EVmon/v89234/noti

＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるイベント通知サービスシステムの構成の概略を説明する。また、本発明における中継サーバ、プログラム、イベント通知サービス方法の構成の概略について説明する。但し、本発明は、以下の構成に限定されない。

（付記１−１）
イベントを発行するイベント発行サーバと、
前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備え、
前記中継サーバは、
前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルと、
前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送するメッセージ転送手段と、を備えた、
イベント通知サービスシステム。

（付記１−２）
付記１に記載のイベント通知サービスシステムであって、
前記中継サーバが有する前記転送テーブルは、前記転送キー毎に、前記通知依頼の転送先となる他の中継サーバの前記転送先アドレス、及び、前記イベントの転送先となる他の中継サーバの前記転送先アドレス、をそれぞれ区別して記憶し、
前記中継サーバが有する前記メッセージ転送手段は、前記転送要求に応じて、前記通知依頼あるいは前記イベントを、当該通知依頼及び当該イベント毎に区別して前記転送テーブルに記憶された前記転送先アドレスの中継サーバに転送する、
イベント通知サービスシステム。

（付記１−３）
付記１又は２に記載のイベント通知サービスシステムであって、
前記通知依頼あるいは前記イベントの前記転送要求に対して転送先となる中継サーバのアドレス解決を行うアドレス解決手段を有するアドレス解決サーバを備え、
前記中継サーバの前記メッセージ転送手段は、前記転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーが前記転送テーブル内に存在しない場合に、当該転送要求に対して転送先となる中継サーバのアドレス解決を前記アドレス解決サーバに要求して、当該アドレス解決サーバの前記アドレス解決手段によるアドレス解決結果を受け取り、このアドレス解決結果に基づいて、前記転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーとアドレス解決された中継サーバの前記転送先アドレスとを関連付けて前記転送テーブルに記憶する、
イベント通知サービスシステム。

（付記１−４）
付記３に記載のイベント通知サービスシステムであって、
前記アドレス解決サーバを少なくとも１つと前記中継サーバを複数備えたサイトを、ネットワークを介して複数接続して形成し、
前記アドレス解決サーバは、
前記サイト毎に、当該サイトから到達可能な他のサイトを識別するサイト識別情報と、当該到達可能な他のサイトに所定のデータを転送するために転送先のアドレス解決要求を行う他のアドレス解決サーバのアドレスを表す解決サーバアドレス情報と、が関連付けられて記憶された経路テーブルを備えると共に、
前記アドレス解決サーバが有する前記アドレス解決手段は、前記転送要求にかかる前記通知依頼に含まれる当該通知依頼の対象となる前記イベント発行サーバが属する前記サイトを識別する情報、あるいは、前記転送要求にかかる前記イベントに含まれる前記通知依頼を行った前記ユーザ端末が属する前記サイトを識別する情報、により識別される前記サイトが転送先となるよう、前記経路テーブルに基づいてアドレス解決を行う、
イベント通知サービスシステム。

（付記１−５）
付記３又は４に記載のイベント通知サービスシステムであって、
前記中継サーバは、前記アドレス解決サーバが記憶する前記経路テーブルが変更された場合に前記転送テーブルに記憶されたデータを削除する、
イベント通知サービスシステム。

（付記１−６）
付記１乃至５のいずれかに記載のイベント通知サービスシステムであって、
前記中継サーバの前記メッセージ転送手段は、前記イベント発行サーバに対して前記通知依頼を行った前記ユーザ端末の数が変化した場合には、前記イベントの前記転送要求に宛先変更フラグを設定すると共に、前記宛先変更フラグが設定された前記転送要求にかかる前記イベントに含まれる前記転送キーに対応するデータを前記転送テーブルから削除し、新たにアドレス解決された前記転送先アドレスデータを前記転送キーに関連付けて前記転送テーブルに記憶する、
イベント通知サービスシステム。

（付記１−７）
付記１乃至６のいずれかに記載のイベント通知サービスシステムであって、
前記転送キーは、前記イベント発行サーバを識別する発行サーバ識別情報を含む、
イベント通知サービスシステム。

（付記１−８）
イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する中継サーバであって、
前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルと、
前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送するメッセージ転送手段と、を備えた、
中継サーバ。

（付記１−９）
イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送すると共に、
前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルを備えた中継サーバに、
前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送するメッセージ転送手段、を実現させるためのプログラム。

（付記１−１０）
イベントを発行するイベント発行サーバと、
前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備えたイベント通知サービスシステムにて、
前記中継サーバが、
前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルを備えると共に、
前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送する、
イベント通知サービス方法。

（付記２−１）
イベントを発行するイベント発行サーバと、
前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備え、
少なくとも前記中継サーバを複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されており、
前記中継サーバは、前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送するメッセージ転送手段を備えた、
イベント通知サービスシステム。

（付記２−２）
付記１に記載のイベント通知サービスシステムであって、
前記通知依頼あるいは前記イベントの前記転送要求に対して当該通知依頼あるいはイベントの転送先となる中継サーバのアドレス解決を行うアドレス解決手段を有するアドレス解決サーバを、前記サイト毎に少なくとも１つ備え、
前記アドレス解決サーバが有する前記アドレス解決手段は、前記中継サーバからのアドレス解決要求を受けて、前記転送要求にかかる前記イベントに含まれた前記宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトに属する複数の前記中継サーバのうち前記イベントを転送する１つの中継サーバを選択してアドレス解決を行い、
前記中継サーバが有する前記メッセージ転送手段は、前記アドレス解決サーバの前記アドレス解決手段にてアドレス解決された中継サーバに、前記イベントを転送する、
イベント通知サービスシステム。

（付記２−３）
付記２に記載のイベント通知サービスシステムであって、
前記アドレス解決サーバは、前記サイト毎に、当該サイトから到達可能な他のサイトを識別する前記宛先サイト情報と、当該他のサイトに所定のデータを転送するためにアドレス解決要求を行う他のアドレス解決サーバのアドレスを表す解決サーバアドレス情報と、が関連付けられて記憶された経路テーブルを備えると共に、
前記アドレス解決サーバが有する前記アドレス解決手段は、前記中継サーバからのアドレス解決要求に応じて前記転送要求にかかる前記イベントに含まれる前記宛先サイト情報に対応して前記経路テーブルに記憶された前記解決サーバアドレス情報にて特定される他のアドレス解決サーバに、前記転送要求にかかる前記イベントに含まれた前記宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトに属する複数の前記中継サーバのうち前記イベントを転送する１つの中継サーバのアドレス解決を要求する、
イベント通知サービスシステム。

（付記２−４）
付記１乃至３のいずれかに記載のイベント通知サービスシステムであって、
前記中継サーバは、前記イベント発行サーバを識別する発行サーバ識別情報と当該イベント発行サーバが発行する前記イベントを識別するイベント識別情報とを含む転送キーと、自己の中継サーバから到達可能な前記イベントの転送先となる前記サイトと、自己の中継サーバから前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルを備え、
前記中継サーバが有する前記メッセージ転送手段は、前記転送キーを含む前記イベントの転送要求を受けて、当該転送要求にかかる前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに前記イベントを転送する、
イベント通知サービスシステム。

（付記２−５）
付記４に記載のイベント通知サービスシステムであって、
前記中継サーバが有する前記メッセージ転送手段は、前記転送キーに含まれた前記発行サーバ識別情報と同一の情報を有する前記転送キーを前記転送テーブル内から検索し、当該検索された前記転送キーに前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに前記イベントを転送する、
イベント通知サービスシステム。

（付記２−６）
イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する中継サーバであって、
少なくとも前記中継サーバを複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されており、
前記中継サーバは、前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送するメッセージ転送手段を備えた、
中継サーバ。

（付記２−７）
イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する中継サーバを、少なくとも複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されており、
前記中継サーバに、
前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送するメッセージ転送手段、を実現させるためのプログラム。

（付記２−８）
イベントを発行するイベント発行サーバと、
前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備えると共に、
少なくとも前記中継サーバを複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されたイベント通知サービスシステムにて、
前記中継サーバが、前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送する、
イベント通知サービス方法。

なお、上述したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。

以上、上記実施形態等を参照して本願発明を説明したが、本願発明は、上述した実施形態等に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることができる。

なお、本発明は、日本国にて２０１１年９月２日に特許出願された特願２０１１−１９１２２５の特許出願に基づく優先権主張の利益を享受するものであり、当該特許出願に記載された内容は、全て本明細書に含まれるものとする。

１０３，１０４，１０５，１０６ 情報ソース
２０１，２０７，２０８ ユーザsubscriber
３０１〜３０４ サイト
４ コア網
５０１〜５０８ アクセス網
６ NRS
１０ 経路テーブル作成手段
１１ 経路テーブル
１２ 名前解決手段
１３ BS割当てテーブル
１４ 名前到達性テーブル
７ BS
１５ マッチング手段
１６ サイトsubscriberテーブル
１７ ユーザsubscriberテーブル
１８ メッセージ転送手段
１９ 転送テーブル
８ EPS
２０ サービスポータル手段
２１ イベント管理テーブル
２２ Publication生成送出手段
９ サイト内網

Claims (10)

1. イベントを発行するイベント発行サーバと、
   前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備え、
   前記中継サーバは、
   前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルと、
   前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送するメッセージ転送手段と、を備えた、
   イベント通知サービスシステム。
2. 請求項１に記載のイベント通知サービスシステムであって、
   前記中継サーバが有する前記転送テーブルは、前記転送キー毎に、前記通知依頼の転送先となる他の中継サーバの前記転送先アドレス、及び、前記イベントの転送先となる他の中継サーバの前記転送先アドレス、をそれぞれ区別して記憶し、
   前記中継サーバが有する前記メッセージ転送手段は、前記転送要求に応じて、前記通知依頼あるいは前記イベントを、当該通知依頼及び当該イベント毎に区別して前記転送テーブルに記憶された前記転送先アドレスの中継サーバに転送する、
   イベント通知サービスシステム。
3. 請求項１又は２に記載のイベント通知サービスシステムであって、
   前記通知依頼あるいは前記イベントの前記転送要求に対して転送先となる中継サーバのアドレス解決を行うアドレス解決手段を有するアドレス解決サーバを備え、
   前記中継サーバの前記メッセージ転送手段は、前記転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーが前記転送テーブル内に存在しない場合に、当該転送要求に対して転送先となる中継サーバのアドレス解決を前記アドレス解決サーバに要求して、当該アドレス解決サーバの前記アドレス解決手段によるアドレス解決結果を受け取り、このアドレス解決結果に基づいて、前記転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーとアドレス解決された中継サーバの前記転送先アドレスとを関連付けて前記転送テーブルに記憶する、
   イベント通知サービスシステム。
4. 請求項３に記載のイベント通知サービスシステムであって、
   前記アドレス解決サーバを少なくとも１つと前記中継サーバを複数備えたサイトを、ネットワークを介して複数接続して形成し、
   前記アドレス解決サーバは、
   前記サイト毎に、当該サイトから到達可能な他のサイトを識別するサイト識別情報と、当該到達可能な他のサイトに所定のデータを転送するために転送先のアドレス解決要求を行う他のアドレス解決サーバのアドレスを表す解決サーバアドレス情報と、が関連付けられて記憶された経路テーブルを備えると共に、
   前記アドレス解決サーバが有する前記アドレス解決手段は、前記転送要求にかかる前記通知依頼に含まれる当該通知依頼の対象となる前記イベント発行サーバが属する前記サイトを識別する情報、あるいは、前記転送要求にかかる前記イベントに含まれる前記通知依頼を行った前記ユーザ端末が属する前記サイトを識別する情報、により識別される前記サイトが転送先となるよう、前記経路テーブルに基づいてアドレス解決を行う、
   イベント通知サービスシステム。
5. 請求項３又は４に記載のイベント通知サービスシステムであって、
   前記中継サーバは、前記アドレス解決サーバが記憶する前記経路テーブルが変更された場合に前記転送テーブルに記憶されたデータを削除する、
   イベント通知サービスシステム。
6. 請求項１乃至５のいずれかに記載のイベント通知サービスシステムであって、
   前記中継サーバの前記メッセージ転送手段は、前記イベント発行サーバに対して前記通知依頼を行った前記ユーザ端末の数が変化した場合には、前記イベントの前記転送要求に宛先変更フラグを設定すると共に、前記宛先変更フラグが設定された前記転送要求にかかる前記イベントに含まれる前記転送キーに対応するデータを前記転送テーブルから削除し、新たにアドレス解決された前記転送先アドレスデータを前記転送キーに関連付けて前記転送テーブルに記憶する、
   イベント通知サービスシステム。
7. 請求項１乃至６のいずれかに記載のイベント通知サービスシステムであって、
   前記転送キーは、前記イベント発行サーバを識別する発行サーバ識別情報を含む、
   イベント通知サービスシステム。
8. イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する中継サーバであって、
   前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルと、
   前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送するメッセージ転送手段と、を備えた、
   中継サーバ。
9. イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送すると共に、
   前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルを備えた中継サーバに、
   前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送するメッセージ転送手段、を実現させるためのプログラム。
10. イベントを発行するイベント発行サーバと、
    前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備えたイベント通知サービスシステムにて、
    前記中継サーバが、
    前記イベント発行サーバが発行する前記イベントを識別するイベント識別情報を含む転送キーと、自己の中継サーバから前記通知依頼あるいは前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルを備えると共に、
    前記転送キーを含む前記通知依頼あるいは前記イベントの転送要求を受けて、当該転送要求にかかる前記通知依頼あるいは前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに、前記通知依頼あるいは前記イベントを転送する、
    イベント通知サービス方法。
    

Images