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

イベント通知サービス方法およびシステム Download PDF

Info

Publication number
WO2013031069A1
WO2013031069A1 PCT/JP2012/003808 JP2012003808W WO2013031069A1 WO 2013031069 A1 WO2013031069 A1 WO 2013031069A1 JP 2012003808 W JP2012003808 W JP 2012003808W WO 2013031069 A1 WO2013031069 A1 WO 2013031069A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
site
transfer
server
destination
Prior art date
Application number
PCT/JP2012/003808
Other languages
English (en)
French (fr)
Inventor
泰寛 宮尾
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to JP2013531011A priority Critical patent/JP5942994B2/ja
Publication of WO2013031069A1 publication Critical patent/WO2013031069A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]

Definitions

  • the present invention relates to an event notification service method and system, and more particularly to a method and system for providing event notification via a plurality of server sites or data centers distributed on a wide area network.
  • the present invention also relates to an information processing apparatus and a program that provide such a service.
  • the message forwarded to subscribe is called subscription
  • the message of the event that occurred is called publication
  • the message notified to the subscriber (user) is called notification.
  • This is in contrast to stateless messaging methods that return a single response to a single request, such as normal web content.
  • the subject of the above pub sub is extensive. For example, an update of a web page of a member on SNS is notified to another member who is a friend. For example, when a stock price of a brand exceeds a threshold, it is notified.
  • the node or subscriber to be transferred next is determined in accordance with the subscription information registered in advance by receiving the subscription. This is called rendezvous processing, and the broker that performs it is also called the rendezvous point.
  • the topology indicating which subscriber (user) wants to subscribe to an event generated by which publisher (event issuer) is referred to as “interested topology”.
  • the topology for distributing and transferring publication to subscribers (users) is called “distributed topology”.
  • the “distribution topology” is given by a physical link connecting brokers or a logical link provided by an overlay network.
  • the topology showing the relationship between rendezvous points is called “Rendezvous topology”.
  • the technologies so far can be classified according to the relationship between the “Rendezvous Topology” and the other two topologies.
  • Non-patent document 2 In SIENA, the rendezvous topology matches the distribution topology.
  • the advertisement that is information specifying the publication to be published in the future from the publisher (event issuer) is transferred to each node by a distribution tree etc., and the subscription transfer for transferring the subscription as its reverse path A table is set up. Further, when subscriptions from subscribers (users) are sequentially transferred at rendezvous points based on this table, a notification transfer table for transferring notifications on each rendezvous point is set as the reverse path.
  • Non-Patent Documents 3-6 (Separation of rendezvous topology and distribution topology) can be used to solve the above problems by making the rendezvous topology consistent with the topology of interest to make the distribution topology independent and facilitate its reconfiguration. ) More specifically, the rendezvous process for determining the destination broker (relayer) of the notification is performed only by the broker accommodating the publisher (event issuer). Information based on the decision is embedded in the notification, and the transfer is performed based on a distribution topology that is optimally configured according to the situation in an independent procedure.
  • Non-Patent Document 3-4 (Xcast +, DOM) relates to IP multicast, but is similar to pub / sub in the following points. In other words, joining / leaving a representative router to / from a multicast group corresponds to the topology of interest. Then, the multicast of the IP packet toward the representative router in the multicast group corresponds to the distribution of the notification by the distribution topology to all the subscribers (users). In the above document, the multicast distribution route is determined based on unicast routing independent of the management of the multicast group.
  • Non-Patent Document 3-4 (Xcast +, DOM) has been modified as follows.
  • a list of all links constituting the distribution tree or a list of representative routers participating in the multicast group is inserted into the IP packet, and each router on the multicast route refers to each address in the route table.
  • source routing is performed in which one or a plurality of next-hop routers are determined.
  • the address list of the representative router matched on the unicast route table is added to the router.
  • Non-Patent Document 4 In DOM (Destination Oriented) Multicast), in order to address the problem that overhead (or bandwidth consumption) increases in proportion to the number of designated routers when Xcast + directly embeds the list of destination designated routers in IP packets.
  • the destination representative router list is made a Bloom filter, and the overhead is fixed regardless of the number of representative routers.
  • Non-Patent Document 5 LIPSIN uses the same source routing mechanism using Bloom filter for distribution of notifications as in Non-Patent Document 3-4.
  • the root is the broker (relayer) that houses the publisher (event issuer), and the subscriber (user)
  • the link ID when the distribution tree including the broker (relayer) that contains the server is configured as a Bloom filter and embedded in the notification to be transferred.
  • Non-Patent Document 6 (MEDYM), as in Non-Patent Document 3 (Xcast +), a list of destination brokers (relayers) is embedded in the notification to be transferred.
  • the site to be transferred next is determined based on unicast routing according to the above document, and becomes a root each time a broker (relayer) receives a notification, and is included in the destination list.
  • An optimum distribution tree including only subscriber nodes is created, and a next hop node and a destination node reachable thereby are determined based on the optimum distribution tree.
  • Non-Patent Document 6 performs the following hierarchical configuration offline. That is, a plurality of nodes are collected into a cluster. In each cluster, for example, a matcher node is assigned to each subspace that can be created by dividing the identifier space given to the event source, allocation information of all matchers is arranged between the clusters, and nodes other than the matcher are allocated to the cluster. The matcher information for each subspace is arranged. As an operation, a message transfer between different clusters is performed by a matcher node, and the transfer is performed from the matcher to another node in the cluster.
  • Non-Patent Document 6 H-MEDYM
  • scale-out is attempted by clustering a plurality of brokers (relayers).
  • relayers since it is necessary to assign a matcher node that performs forwarding for each event subspace in advance in each cluster, it is possible to dynamically increase or decrease the broker according to the number of users and the load for each cluster. The problem arises that it is not easy to execute independently.
  • an object of the present invention is to solve the above-described problem that it is difficult to realize scale-out in the event notification service system.
  • An event notification service system includes: An event issuing server for issuing events; A notification request from a user terminal that requests notification of the event issued from the event issuing server to the event issuing server is sent to the event issuing server, or the event issued by the event issuing server is A plurality of relay servers that relay and transfer to the user terminal;
  • the relay server is A transfer key including event identification information for identifying the event issued by the event issuing server, and a transfer destination address indicating an address of the other relay server to which the notification request or the event is transferred from its own relay server
  • a forwarding table associated with Upon receiving the notification request or the event transfer request including the transfer key, the transfer request is associated with the same transfer key as the transfer key included in the notification request or the event related to the transfer request in the transfer table.
  • the relay server which is the other form of this invention is A notification request from a user terminal that requests the event issuing server to notify the event issuing server of an event issued from an event issuing server that issues an event is issued to the event issuing server or the event issuing server A relay server for relaying and transferring an event to the user terminal; A transfer key including event identification information for identifying the event issued by the event issuing server, and a transfer destination address indicating an address of the other relay server to which the notification request or the event is transferred from its own relay server And a forwarding table associated with Upon receiving the notification request or the event transfer request including the transfer key, the transfer request is associated with the same transfer key as the transfer key included in the notification request or the event related to the transfer request in the transfer table.
  • the program which is the other form of this invention is: A notification request from a user terminal that requests the event issuing server to notify the event issuing server of an event issued from an event issuing server that issues an event is issued to the event issuing server or the event issuing server Relay the event to the user terminal, and A transfer key including event identification information for identifying the event issued by the event issuing server, and a transfer destination address indicating an address of the other relay server to which the notification request or the event is transferred from its own relay server And a relay server provided with a forwarding table in which Upon receiving the notification request or the event transfer request including the transfer key, the transfer request is associated with the same transfer key as the transfer key included in the notification request or the event related to the transfer request in the transfer table. And a message transfer means for transferring the notification request or the event to the relay server of the transfer destination address.
  • An event notification service method includes: An event issuing server for issuing events; A notification request from a user terminal that requests notification of the event issued from the event issuing server to the event issuing server is sent to the event issuing server, or the event issued by the event issuing server is In an event notification service system comprising a plurality of relay servers that relay and transfer to a user terminal,
  • the relay server is A transfer key including event identification information for identifying the event issued by the event issuing server, and a transfer destination address indicating an address of the other relay server to which the notification request or the event is transferred from its own relay server
  • a transfer table that associates
  • the transfer request is associated with the same transfer key as the transfer key included in the notification request or the event related to the transfer request in the transfer table.
  • the notification request or the event is transferred to the relay server of the transfer destination address.
  • the configuration is as follows.
  • an event notification service system includes: An event issuing server for issuing events; A notification request from a user terminal that requests notification of the event issued from the event issuing server to the event issuing server is sent to the event issuing server, or the event issued by the event issuing server is A plurality of relay servers that relay and transfer to the user terminal; A site formed by a server group including at least a plurality of the relay servers is formed by being connected via a plurality of networks, The relay server transfers the notification request from the user terminal including destination site information for identifying the site to which the user terminal belongs to the notification request, and relays the notification request to the site to which the event issuing server belongs.
  • the destination site information included in the notification request is registered as the event notification destination, the event transfer request is received, the registered destination site information is included in the event, and the destination A message transfer means for transferring the event with the site corresponding to the site information or the site reachable to the site as the transfer destination of the event;
  • the relay server which is the other form of this invention is A notification request from a user terminal that requests the event issuing server to notify the event issuing server of an event issued from an event issuing server that issues an event is issued to the event issuing server or the event issuing server
  • a relay server for relaying and transferring an event to the user terminal A site formed by a server group including at least a plurality of the relay servers is formed by being connected via a plurality of networks, The relay server transfers the notification request from the user terminal including destination site information for identifying the site to which the user terminal belongs to the notification request, and relays the notification request to the site to which the event issuing server belongs.
  • the destination site information included in the notification request is registered as the event notification destination, the event transfer request is received, the registered destination site information is included in the event, and the destination A message transfer means for transferring the event with the site corresponding to the site information or the site reachable to the site as the transfer destination of the event;
  • the program which is the other form of this invention is: A notification request from a user terminal that requests the event issuing server to notify the event issuing server of an event issued from an event issuing server that issues an event is issued to the event issuing server or the event issuing server
  • a site formed by a server group including at least a plurality of relay servers for relaying and transferring an event to the user terminal is connected via a plurality of networks.
  • the relay server When the notification request from the user terminal is transferred to the notification request including destination site information for identifying the site to which the user terminal belongs, and the relay server belongs to the site to which the event issuing server belongs.
  • An event notification service method includes: An event issuing server for issuing events; A notification request from a user terminal that requests notification of the event issued from the event issuing server to the event issuing server is sent to the event issuing server, or the event issued by the event issuing server is A plurality of relay servers that relay and transfer to the user terminal, and In an event notification service system formed by connecting a site formed by a server group including at least a plurality of the relay servers via a plurality of networks, The relay server forwards the notification request from the user terminal including destination site information identifying the site to which the user terminal belongs to the notification request, and the relay server transmits the notification request to the site to which the event issuing server belongs.
  • the destination site information included in the notification request is registered as the event notification destination, the event transfer request is received, the registered destination site information is included in the event, and the destination Forward the event with the site corresponding to the site information or the site reachable to the site as the forwarding destination of the event,
  • the configuration is as follows.
  • FIG. 1 is a block diagram showing a configuration of the entire system in Embodiment 1.
  • FIG. It is a block diagram which shows the structure of the site disclosed in FIG. It is a block diagram which shows the structure of EPS disclosed in FIG. It is a block diagram which shows the structure of BS disclosed in FIG. It is a block diagram which shows the structure of NRS disclosed in FIG. It is explanatory drawing of the transfer table which BS disclosed in FIG. 3b memorize
  • the event notification service system includes an information source (104, etc.), a user (user terminal 201, etc.), a site (301, etc.), a core network 4, and an access network (501, etc.).
  • the above “information source” is for generating or providing information that is a source of generating an event.
  • a solar power generation device 104 (information source) that is connected to the wireless sensor network 504 (access network) and wants to monitor the power generation amount
  • EV electric vehicle
  • SOC state of charge
  • LTE / 3G network 503,506 access network
  • the “information source” is given a corresponding original URI by “EPS” which is an event issuing server based on a request from a user who wants to receive the event notification service.
  • EPS event issuing server based on a request from a user who wants to receive the event notification service.
  • the information sources are not limited to those described above.
  • the “user” is a user of the event notification service, and examples of user terminals that are devices used by the user include PCs (personal computers) 202 and 208, and smartphones 201 and 207.
  • the user terminal is not limited to the device described above.
  • the “core network” 4 provides a data transfer function between a plurality of sites. Examples include private networks, virtual private networks such as wide area Ethernet, and the global Internet.
  • the “access network” (501, etc.) is connected to the core network 4 and accommodates information sources and users in the site.
  • the above “site” is a place where multiple server machines are installed to implement various functions that enable event notification services with software. Examples of such sites are the network operator's NOC (network operation center) or data. There is a center.
  • NOC network operation center
  • NOC network operation center
  • the site 302 includes an NRS (name resolution server (address resolution server)) 6, a BS (broker server (relay server)) 7, an EPS (event issuing server) 8, and an intra-site network 9. Including.
  • NRS name resolution server (address resolution server)
  • BS broker server (relay server)
  • EPS event issuing server
  • the NRS 6 dynamically reconfigures a distribution tree for transferring “notification” (event), which is a message notified by issuing an event between sites, with low delay.
  • event a message notified by issuing an event between sites.
  • the BS7 functions to transfer a subscription from the user or another BS7 to the BS7 of the site accommodating the EPS6, and to deliver (transfer) the notification from the EPS6 to the BS7 and the user.
  • the above-mentioned EPS8 processes real-time data sent periodically from SGW (Service Gateway) or intermittently on an event basis, and issues an event as information to be distributed to the user. Generate and provide an original URI to identify the monitoring target based on a request from the user regarding the event delivery service. It terminates the data transfer and message transfer protocol unique to the access network, and converts it into a system common protocol (for example, HTTP) used between EPS and BS.
  • SGW Service Gateway
  • HTTP HyperText Transfer Protocol
  • the intra-site network 9 is connected to one core network 4 and one or more access networks 5.
  • the intra-site network 9 is connected to one core network 4 and one or more access networks 5.
  • the EPS 8 includes service portal means 20, publications generation / transmission means 22, and an event management table (hereinafter abbreviated as “emTBL”) 21.
  • emTBL event management table
  • filter is given as a logical expression for the constraint condition of each monitoring item.
  • examples of monitoring items include a distance from the SOC and an arbitrary desk lamp.
  • filter can be written as follows. (SOC) ⁇ 10% and (distance from any stand) ⁇ 2.0km
  • the service portal means 20 instructs the local NRS 6 in the same site to which the EPS 8 belongs to resolve the address of the BS 7 (exit BS) that is the exit to which the publication is sent from the original URI. Thereafter, the monitoring items, the filter, and the address of the exit BS requested from the NRS 6 and resolved from the original URI are stored in the emTBL 21.
  • the emTBL 21 includes an original URI, a monitoring item corresponding to the content (attribute) of data included in the filter, a filter that covers the entire filter from each site for the same URI, and an exit BS that should send publication. Contains a combination of addresses.
  • matching means that the realization value satisfies the logical condition in the filter.
  • the service portal means 20 advertises the reachability of the provided service domain, generates the following publication, and transfers it.
  • the annotation a135667 indicates that this is advertisement.
  • 35667 is a value obtained by hashing provider.net/ServAdv/EPS1, and the leading number 1 indicates that it has been hashed at site 1.
  • the HTTP message body indicates that the service name EVmon is provided from site 2 and site 2.
  • the BS 7 includes a matching unit 15, a site subscription table (hereinafter abbreviated as ssTBL) 16, a user subscription table (hereinafter abbreviated as usTBL) 17, a message transfer unit 18, a transfer table 19, including.
  • ssTBL site subscription table
  • usTBL user subscription table
  • transfer table 19 including.
  • the ssTBL 16 registers a transfer URI included in a subscription sent from another BS 7 to the own BS 7, a site name to which a user subscribed to the same transfer URI, and its filter are registered.
  • the above usTBL 17 registers the original URI included in the subscription sent from the user to the BS 7, the user ID subscribed to the same original URI, and the filter.
  • the “filter” is a logical condition obtained by arranging the relational expressions between the monitoring items and their actual values by AND, and is used to represent the user's interest. This is described, for example, for EV as follows. (SOC) ⁇ 10% and (distance from any stand) ⁇ 2km
  • the matching unit 15 is driven by a message transfer unit 18 to be described later, and extracts a matching subscriber (user (user terminal)) by referring to ssTBL and usTBL for a given original URI or transfer URI. . Since the matching unit 15 generally has a high processing load, the matching unit 15 may be realized on a plurality of server machines in addition to being realized by being closed in one BS 7. In this case, ssTBL and usTBL are divided and placed on these servers, matching processing requests containing the same attribute are multicast to each, and if there is a subscriber that matches on the divided TBL, it is included from the server Matching processing speed may be improved by performing matching parallel processing in the form of receiving a response.
  • the transfer table 19 includes a “transfer key” composed of an “origin site name” that is a site to which the EPS 8 that issues an event belongs and an “event source ID” that is event identification information for identifying the event. ”,“ Subscription transfer child BS address ”which is the address of the BS 7 that is the transfer destination of the subscription from the own BS 7,“ destination site name ”indicating the site reachable from the own BS 7, and notification from the own BS 7
  • the entry has a combination in which “notificatoin transfer child BS address”, which is the address of BS7 as the transfer destination, is associated. In this way, in the transfer table 19, for each transfer key, the address of the other BS 7 of the next hop that becomes the next transfer destination is registered separately and separately for each transfer key. It is possible to set the route.
  • the message transfer means 18 transfers the message to the BS of the next hop by resolving from the transfer URI to the BS address of the next hop.
  • the event channel to be monitored is specified by URI, and the filter that conditions the value obtained from the monitoring item is described in the HTTP message body, so that the content-based and subject-based subscriptions are unified. It can be handled.
  • FIG. 5 is a flowchart showing the operation of the publication transfer process.
  • the BS 7 receives publication from the local EPS 8 (step S9), the BS 7 checks whether there is a subscription that matches ssTBL (step S10). If there is no subscription (No in step S10), the process ends. If there is one (Yes in step S10), the matching means 15 is driven to match on usTBL only if the subscriber site name (destination site information) registered in the matched subscription has its own site. A notification including the original URI is generated and transferred to the user who performs the process (step S11).
  • step S12 it is checked whether or not there is a subscriber site registered in the matched subscription other than the own site. If there is (Yes in step S12), the name of the site is entered in the original site “Transfer URI” ”And a“ destination site list ”that includes a site name other than the own site among subscriber sites registered in the matched subscription, and a“ destination list change flag ”as necessary, The process proceeds to step S3 in Fig. 6 ((step S13). If there is no subscriber site other than the own site in the registered subscription in step S12, the process ends.
  • the “destination list change flag” is notified from the EPS 8 when the number of user subscribers (such as the user terminal 201) that subscribe to the EPS 8 changes, and the BS 7 sets “notificatoin”. Also, when the BS 7 changes the route table 11 stored in the NRS 7 to be described later, such as when another BS is added to the system, and receives a notification to that effect from the NRS 7, it is stored in the transfer table 19 described above. It also has a function to delete existing data.
  • FIG. 6 is a flowchart showing the operation of notification transfer processing.
  • the BS 7 receives the notification from the parent BS 7 (step S1)
  • the original URI is sent to the user who matched the usTBL by driving the matching means 15 only when the own site is included in the destination site list included in this notificatoin. Is generated and transferred (step S2).
  • the destination list change flag is set, the entry corresponding to the transfer key included in notificatoin is deleted from the transfer table (step S3).
  • step S5 it is checked whether or not there is a transfer key in the transfer table 19, and if there is a transfer key in the transfer table 19, the process proceeds to step S5. If there is no transfer key in the transfer table 19, the transfer URI, the origin site as the root site, and the destination site list (destination site information) in the notification as the descendant site are sent to the child BS group. The name is resolved, the response result is registered in the transfer table 19, and the process proceeds to step S5 (step S4). As a result, as will be described later, the BS7 address of the site that can reach each site in the destination site list (destination site information) registered as a descendant site in notificatoin is transferred to the transfer table 19 as the next hop. It is registered corresponding to. In step S5, for each BS address corresponding to the next hop registered corresponding to the transfer key that matches in the transfer table 19, the notification copied from the destination site list is copied and transferred, and the process ends.
  • FIG. 7 is a flowchart showing the operation of the subscription transfer process
  • FIG. 7a shows the operation of the BS 7 when a subscription is received from the parent BS which is another BS.
  • the subscription is received from the parent BS (step S21)
  • it is checked whether the origin site name to which the EPS8 requesting the event notification included in this subscription belongs is the local site (step S22). If the origin site name is not the own site (No in step S22), the transfer URI and the root site are set to the own site name only when there is no entry corresponding to the transfer key included in the received subscription in the transfer table 19.
  • the NRS 6 is queried to resolve the child BS address, and the response result is registered in the transfer table (step S24).
  • the subscription is transferred to the child BS with reference to the transfer table 19 (step S25).
  • Step S23 If the origin site is the local site in step S2 (Yes in step S22), if there is no registration of the same subscriber site in ssTBL, the subscriber site name included in the subscription is registered as destination site information ( Step S23). If there is a subscription for the same subscriber site in ssTBL, the filter is registered only when the filter of the received subscription cannot be covered. Only when there is no entry for the next hop EPS8 address for the URI, the request is made to the local NRS 6 to resolve to the EPS8 address and stored in the forwarding table. Next, only when there is no filter that can cover the site subscription registered for the same URI, refer to the forwarding table and send the filter to EPS.
  • FIG. 7 b shows the operation of BS 7 when a subscription is received from the user.
  • the original URI and user address are registered in usTBL (step S32).
  • the matching unit 15 is driven to check whether there is a user subscription that can be covered in the usTBL (step S33). If there is a user subscription (Yes in step S33), the process ends. If not (No in step S33), it is checked whether the origin site name is the local site (step S34). If so (Yes in step S33), the URI in the subscription in ssTBL and the local site as the site subscriber And filter are registered (step S35), and the process ends.
  • step S34 if the origin site name is not the local site (No in step S34), NRS 6 is queried to resolve the original URI into one or more transfer URIs. For each individual transfer URI, only when the transfer key is not in the transfer table, the NRS 6 is again queried to resolve one or more origin sites and the transfer destination child BS address from the original URI. The combination of BS addresses is registered in the transfer table (step S36).
  • step S36 Next, in the subscription received from the user, refer to the forwarding table, rewrite the original URI for each forwarding URI, create a subscription with the root site rewritten to its own site for each different origin site, and create a forwarding table for each. Refer to and transfer to the corresponding child BS (step S37).
  • the notification and the subscription are registered with the next hop independently on the forwarding table, and can be forwarded on the optimum route independently of each other.
  • a notification including an event source ID indicating advertisement for example, using a as an annotation and a144555 is received, be sure to add it to the site designated as the destination site. Transfer to NRS6 at the local site.
  • the NRS 6 includes a route table creation unit 10, a name resolution unit 12, a route table 11, a BS allocation table 13, and a name reachability table 14.
  • the route table creation means 10 monitors the state of the network and the like with the NRS 6 of another site, and transfers a message from the own site to all other sites based on the information obtained thereby. An optimum global distribution tree is constructed and the route table 11 is created.
  • the entry of the BS allocation table 13 includes a list of destination site names as in the transfer table 19 stored in the BS 7, but the transfer table 19 includes all descendant sites.
  • the BS allocation table 13 of NRS 6 includes only descendant sites corresponding to the destination site inserted in the notification. All entries in this table are cleared when the route table is updated.
  • each NRS creates an optimum distribution tree having roots for each NRS of itself and other sites, and creates a routing table based on the distribution tree.
  • One of the optimal distribution tree construction methods is the shortest path tree (SPT) obtained by Dijkstra's algorithm.
  • SPT shortest path tree
  • a one-way delay OWD can be measured by writing a round trip delay (RTT: round-trip time) or a request time stamp between the NRSs on the piner side and a response time stamp on the pineer side.
  • the distribution tree is calculated by applying Dijkstra's algorithm using these as the distance of each edge (link between sites) in the distribution tree. This is the same principle as the link state protocol used in OSPF, IS-IS, etc.
  • the NRS 6 appropriately calculates the distribution tree and if there is a change in the routing table, instructs the BS 7 in the same site to clear the forwarding table 19.
  • FIG. 8 shows the configuration of the route table 11.
  • the route table 11 includes a root site name representing a transfer source site for the local site, an NRS address of the parent site viewed from the local site on the distribution tree formed by the root site, and a descendant site indicating a site reachable from the local site. It includes an entry for a combination of name (site identification information) and child site NRS address (resolution server address information) for reaching the descendant site on the distribution tree.
  • the address of the parent NRS is used to check whether a query has been received from a valid parent NRS on the assumed distribution tree. If it is not valid, reply “unresolvable”.
  • FIG. 9 shows the configuration of the BS allocation table 13. This is used for name resolution for subscription and notification transfers.
  • subscription for each transfer key, the child BS address and the exit BS address of the own site are held.
  • notification for each transfer key, the reachable descendant site name, the BS address of the child site for reaching those sites, and the entrance BS address of the own site are held.
  • the egress BS address is written when the NRS 6 assigns the original URI in the request from the EPS 8, and is used by the NRS 6 as its egress site to respond to the name resolution request for the subscription.
  • the entrance BS address is assigned based on the name resolution request when the user transfers the subscription, and is used by the NRS 6 that is the entrance site to respond to the name resolution request for notification. For this reason, the name resolution request from the local NRS to the remote NRS includes the type (subscription or notification) of the transfer message in addition to the transfer URI.
  • the name resolution means 12 stores the name reachability information received from the EPS of another site in the name reachability table 14. It also executes procedures including sending a resolution request and creating and sending a resolution response necessary for resolution from URI to BS address.
  • the name resolution request / response message includes at least three items: one transfer URI, one root site, and one or more descendant sites. The latter two are matched in the routing table and the address of the next hop NRS is determined.
  • step S45 if there is a name resolution request from the local BS 7 to which the subscription is to be transferred to the next hop BS including the transfer URI, the subscriber site name as the root site, and the origin site as the descendant site.
  • step S45 For the next hop NRS 6 obtained by subtracting the root site name by the subscriber site name and the origin site by the destination site on the route table 11 only when there is no transfer key entry in the BS allocation table 13
  • step S46 When a name resolution request including a URI is issued and a response is received, it is registered in the BS allocation table 13 (step S46).
  • step S47 referring to the BS allocation table, the transfer URI and the allocated next hop BS are returned to the local BS (step S47), and the process is terminated.
  • a name resolution request including a transfer URI is issued to all child NRSs obtained by pulling the origin site on the route table 11 at the root site, and when a resolution response is received, it is registered in the BS allocation table 13.
  • a combination of one or more remote BSs and a destination list is returned to the local BS.
  • step S51 if there is a name resolution request from the parent NRS 6 to the local (local site) BS 7 (step S51), the route TBL11 is drawn at the root site included in the resolution request, and the NRS address of the resolution request transmission source is the parent NRS. It is checked whether it matches the address (step S52). If they do not match (No in step S52), an unresolvable response is issued ((step S56). If they match in step S52 (Yes in step S52), it is checked whether the descendant site is the local site (step S53).
  • Step S53 If so (Yes in step S53), the BS allocation TBL13 is referred to, and in the case of notification transfer, the local BS address for Subscription transfer is returned, and in the case of subscription transfer, the local BS address for Notification transfer.
  • Step S55 If the descendant site is not its own site in Step S53 (No in Step S53), the local BS is allocated by the technique such as consistent hashing disclosed in Patent Document 1 and assigned to the BS allocation TBL13. Cache and respond with the address (step S54).
  • step S52 The reason for the determination in the above step S52 is that when a name resolution request / response is made across multiple hops, a loop is finally formed because the routing table changes are not synchronized between sites. Is to prevent. Inability to resolve returns to the original BS that issued the name resolution request as a response, in which case the message may be discarded.
  • the above step S55 is for ensuring that the entrance BS and the exit BS match in the transfer of the notification and subscription including the same URI. If there are multiple BSs assigned to the same URI when the subscription is transferred, all of them will be responded. Therefore, the parent BS multicasts the notification to a plurality of BSs in the next hop site.
  • the local BS is allocated by consistent hashing disclosed in Patent Document 1 above.
  • the local BS address is cached and responded to the BS allocation TBL (step S42).
  • the set of BSs from which the allocation target is selected in step S42 is given the added load in advance. You may limit so that it may be below the set threshold value. Therefore, NRS needs to monitor the life and death of each BS in the same site.
  • the NRS is identified by an annotation attached to the event source ID in the transfer key.
  • the NRS can reach the name reachability TBL and one service domain name. Or, register a combination of multiple site names.
  • the NRS 6 in the present invention is common in that the name is resolved to the node address, but there is a big difference in the following points. That is, the NRS 6 in the present invention determines the next hop that the destination site specified in the message can reach from the current NRS on the optimally formed distribution tree.
  • the DNS server to be inquired next is determined based on the instruction of the DNS server of the upper level domain included in the URI for the DNS to be inquired next.
  • FIG. 11 shows a series of movements in which a subscription related to an EV (electric vehicle) monitoring service is generated and transferred to an exit BS 71 that accommodates EPS 81 that provides the monitoring service.
  • EV electric vehicle
  • the user 21 accesses the EPS 81 that accepts an event distribution service to be provided, and the EV battery with an ID of “v23406” has an SOC of less than 10% for the event monitoring of the EV 103, and is optional.
  • the event management table t1
  • the EPS 81 inquires to the NRS 61 with the original URI (t2), and when there is a response of the address of the exit BS 71 (t3), it is registered in the event management table.
  • the EPS 81 creates a response message including the following contents, and the user (T4).
  • Entrance NRS address wxyz POST http://e143359.provider.net/EVmon/v23406/sub/user ⁇ Body> Subscriber address: abcd Filter: (SOC) ⁇ 10%, (distance from any stand) ⁇ 2km
  • the entrance NRS address is the address of the NRS 64 in the site 4 to which the user 21 should access in order to receive the message of the service specified by this original URI.
  • the EPS 81 is determined from the sites closest to the user based on the user's address (a.b.c.d in the above example).
  • “EVmon” is the event service name
  • “provider.net” is the service provider name
  • “v23406” is “v”
  • the EV 103 ID is “23406”.
  • “143359” of “e143359” is a notation indicating that “e” is an event source ID. Then, “143359” has hashed “provider.net/EVmon/v23406/” in EPS81 to obtain “43359”, and the site number at the head of the site so that it does not collide between EPS of each site. Obtained by adding "1". Further, a.b.c.d indicates a user address. “Filter” indicates a condition that the user wants to transfer an event as described above.
  • the user (user terminal) 21 receiving the response message from the EPS 61 at “Site 1” sends an original URI to the entrance NRS 64.
  • e143359.provider.net/Evmon/v23406 Sends a name resolution request to the ingress BS address (t5).
  • the entrance NRS 64 determines the entrance BS 74 to be accessed from the original URI by consistent hashing (see Patent Document 1) or the like, the entrance NRS 64 sends the address “pqrs” to the user 21 together with the original URI (t6).
  • e143359.provider.net/EVmon/v23406 pqrs
  • the user 21 sends to the entrance BS 74 the original URI that has been received from the EPS 81, the address of the user 21, and the subscription obtained from the EPS 81 to the entrance BS 74 (t7).
  • This message contains the following format POST: http://e143359.provider.net/Evmon/v23406/sub/user ⁇ Body> Subscriber address: abcd Filter: (SOC) ⁇ 10%, (distance from any stand) ⁇ 2km
  • the entrance BS 74 that received the subscription from the user 21 sends the service name “EVmon” to the local NRS 64 (t8), and the NRS 64 refers to the name reachability table and resolves it to one or more origin site names.
  • a response is sent (t9).
  • the entrance BS 74 generates a transfer URI, refers to the transfer table 19, and when there is no transfer key corresponding to the transfer URI, the transfer URI, the root site, its own site name, and the descendant site A name resolution request including the origin site name is sent to the local NRS 64 (t10).
  • the format is as follows. 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 is a transfer key
  • “NRS” indicates a name resolution service.
  • the entrance NRS 64 searches the route table 11 with its own site as the root site and the origin site of the URI as a descendant site, and subtracts the address of the child NRS 67. From the forwarding URI to the child BS address there The name resolution request is sent (t11).
  • the message contains the following URI: GET http: // (NRS address) / NRS / ChildBS ⁇ Body> Transfer key: site1.e143359 Message type: Subscription (or notification)
  • the child NRS 67 that has received the request determines the BS to be allocated to the BS 77 using consistent hashing (see Patent Document 1), and replies to the NRS 64 that requested the name resolution (t12). Receiving this, the NRS 64 returns the address of the child BS 77 to the local BS 74 that has made the name resolution request (t13).
  • the BS 74 that has received this creates a subscription for each site as shown below and transfers it to the child BS 77 (t14).
  • the subscription is not performed in units of BS when performing transfer control, but is performed in units of the same site that performs path control.
  • the entrance site is “site 4”.
  • the BS 77 in the “site 7” which is the child site that has received the subscription follows the same procedure as described above between the local NRS 67 and its child NRS 61 (t15 to t18), and transfers the transfer URI at the exit BS.
  • the address is resolved to the address of a certain BS 71, and the subscription is transferred as it is to the BS 71 which is the exit BS (t19).
  • the BS 71 that received it stores the URI described in the subscription, the site name of the subscriber to which the user terminal belongs, and the filter in the ssTBL 16 because the origin site of the subscription is its own site (site 1). Further, when the filter covering all site subscription filters for the same site subscription URI is updated, it is sent to the EPS 81 whose name is resolved by the local NRS (t20).
  • the NRS 64 at the entrance site refers to the name reachability TBL 14 after t10, and the service of “EVmon” can be reached not only from “site1” but also from “site3”.
  • the route TBL11 is searched and its own site is the root site and site3 is the descendant Resolve the NRS of the next hop site for the site.
  • send a name resolution request including the transfer key “site3.e143359” created as follows and the local site as the root site to resolve to the BS address assigned at the next hop site.
  • another subscription is generated in BS 74 and transferred to “site 3” in the same procedure as that for generating a subscription in BS 74 and transferring it to “site 1”.
  • FIG. 12 shows a series of movements until EPS81 generates a publication, a plurality of BSs relay and transfer it as a notification, and deliver it to the user.
  • the gist of the publication message from the EPS 81 is as follows. That is, in the publication, the original URI that does not include the origin site name is included.
  • the information source EV 103 is identified by an ID of “v23406”.
  • the body indicates that the SOC of the battery is 5%.
  • the EPS 81 After creating the publication including the original URI and the monitoring value, the EPS 81 refers to the event management table and sends the publication to the BS 71 resolved from the original URI (u1).
  • the exit BS 71 sends a transfer key (site1.e143359 in the above example) and a destination site list (site4, site5 in the above example) to the local NRS 61 to request a resolution to the child BS address (u2)
  • the local NRS 61 sends the transfer URI to the two child NRSs obtained by referring to the routing table 11, that is, the NRS 67 of “Site 7” and the NRS 65 of “Site 5”, and names the child BS addresses.
  • a solution is requested (u3).
  • the transfer URI, the address of the BS 77 and the “site4” as the descendant site name, and the address of the BS 75 and the descendant site name “ "site5" is returned to the exit BS 71 (u5).
  • the exit BS 51 transfers the notification created as described below to the child BSs 77 and 75 (u6).
  • the BS 77 that has received the notification having the content (1) performs the same procedure with the local NRS 67 and the child NRS 64 (from u7 to u10), and transfers the notification to the child BS 74 of “Site 4” ( u11).
  • the BS 74 that has received it refers to the usTBL 17 because the destination site is only its own site, and since there is a matching user, the notification is transferred there (u12).
  • the transfer table 19 including only the sites to be transferred is configured from the route table 11 including all sites, and the message transfer is performed when the transfer table 19 has a transfer key.
  • the BS and destination list of the transfer destination can be determined, so the information about the destination included in the message to be transferred is not converted into a Bloom filter that has a false positive problem.
  • high-speed transfer is possible.
  • the notification and the subscription are registered with the next hop independently on the forwarding table, and can be forwarded on the optimum route independently of each other.
  • the site to which the request for resolving the URI to the address of the BS in the other site to which the message is to be transferred next is determined, and the request is received. Since the NRS of each site determines the BS to be allocated based on URI hashing, the addition of BSs within each site can be performed independently between sites. At this time, since the destination list included in the notification is not a broker unit but a site unit, even if the number of brokers in each site increases, the size of the destination list is not affected. In the forwarding table, matching is performed by the origin site name, not the event source ID unit. Therefore, even if the number of brokers at each site increases, there is no direct influence on the search order of the forwarding table search.
  • the EPS of Site3 sends a publication that includes the sampled data and each of the following original URIs. http://e134567.provider.net/EVmon/v89234/pub http://e134567.provider.net/EVmon/v45234/pub
  • An event issuing server for issuing events A notification request from a user terminal that requests notification of the event issued from the event issuing server to the event issuing server is sent to the event issuing server, or the event issued by the event issuing server is A plurality of relay servers that relay and transfer to the user terminal;
  • the relay server is A transfer key including event identification information for identifying the event issued by the event issuing server, and a transfer destination address indicating an address of the other relay server to which the notification request or the event is transferred from its own relay server
  • the event notification service system according to attachment 1, wherein
  • the transfer table of the relay server includes, for each transfer key, the transfer destination address of another relay server that is a transfer destination of the notification request and the transfer of another relay server that is a transfer destination of the event. Store the destination address separately,
  • the message transfer means included in the relay server is configured to relay the notification request or the event according to the transfer request to the notification address and the transfer destination address stored in the transfer table for each event. Forward to Event notification service system.
  • appendix 1-3 The event notification service system according to appendix 1 or 2, An address resolution server having address resolution means for performing address resolution of a relay server as a transfer destination for the notification request or the transfer request of the event;
  • the message transfer means of the relay server is a relay that becomes a transfer destination for the transfer request when the transfer request included in the transfer request is not present in the transfer table.
  • Requests address resolution of the server to the address resolution server receives an address resolution result by the address resolution means of the address resolution server, and based on the address resolution result, notifies the notification request or event related to the transfer request Storing the transfer key included in the transfer table in association with the transfer destination address of the relay server whose address has been resolved, Event notification service system.
  • the event notification service system Forming a plurality of sites each including at least one address resolution server and a plurality of relay servers via a network;
  • the address resolution server For each site, site identification information that identifies other sites that can be reached from the site, and other address resolutions that perform a destination address resolution request to transfer predetermined data to the other reachable sites
  • a resolution server address information indicating a server address is provided in association with a route table stored therein, and
  • the address resolution means included in the address resolution server includes information for identifying the site to which the event issuing server that is the target of the notification request included in the notification request related to the transfer request belongs, or the transfer request Performing address resolution based on the routing table so that the site identified by the information to which the user terminal that has made the notification request included in the event belongs is the transfer destination.
  • Event notification service system For each site, site identification information that identifies other sites that can be reached from the site, and other address resolutions that perform a destination address resolution request to transfer predetermined data to the other reachable sites
  • the event notification service system according to any one of appendices 1 to 5,
  • the message transfer means of the relay server sets a destination change flag in the transfer request of the event when the number of the user terminals that have made the notification request to the event issuing server has changed,
  • the data corresponding to the transfer key included in the event related to the transfer request in which the destination change flag is set is deleted from the transfer table, and the newly-resolved transfer destination address data is associated with the transfer key.
  • Event notification service system To store in the transfer table, Event notification service system.
  • the event notification service system according to any one of appendices 1 to 6,
  • the transfer key includes issue server identification information for identifying the event issue server. Event notification service system.
  • a notification request from a user terminal that requests the event issuing server to notify the event issuing server of an event issued from an event issuing server that issues an event is issued to the event issuing server or the event issuing server
  • a relay server for relaying and transferring an event to the user terminal A transfer key including event identification information for identifying the event issued by the event issuing server, and a transfer destination address indicating an address of the other relay server to which the notification request or the event is transferred from its own relay server
  • a notification request from a user terminal that requests the event issuing server to notify the event issuing server of an event issued from an event issuing server that issues an event is issued to the event issuing server or the event issuing server Relay the event to the user terminal, and A transfer key including event identification information for identifying the event issued by the event issuing server, and a transfer destination address indicating an address of the other relay server to which the notification request or the event is transferred from its own relay server And a relay server provided with a forwarding table in which Upon receiving the notification request or the event transfer request including the transfer key, the transfer request is associated with the same transfer key as the transfer key included in the notification request or the event related to the transfer request in the transfer table.
  • An event issuing server for issuing events A notification request from a user terminal that requests notification of the event issued from the event issuing server to the event issuing server is sent to the event issuing server, or the event issued by the event issuing server is In an event notification service system comprising a plurality of relay servers that relay and transfer to a user terminal,
  • the relay server is A transfer key including event identification information for identifying the event issued by the event issuing server, and a transfer destination address indicating an address of the other relay server to which the notification request or the event is transferred from its own relay server
  • a transfer table that associates Upon receiving the notification request or the event transfer request including the transfer key, the transfer request is associated with the same transfer key as the transfer key included in the notification request or the event related to the transfer request in the transfer table.
  • the notification request or the event is transferred to the relay server of the transfer destination address.
  • Event notification service method A notification request from a user terminal that requests notification of the event issued from the event issuing server to the event issuing server is sent to the event issuing
  • An event issuing server for issuing events;
  • a notification request from a user terminal that requests notification of the event issued from the event issuing server to the event issuing server is sent to the event issuing server, or the event issued by the event issuing server is A plurality of relay servers that relay and transfer to the user terminal;
  • a site formed by a server group including at least a plurality of the relay servers is formed by being connected via a plurality of networks, The relay server transfers the notification request from the user terminal including destination site information for identifying the site to which the user terminal belongs to the notification request, and relays the notification request to the site to which the event issuing server belongs.
  • the destination site information included in the notification request is registered as the event notification destination, the event transfer request is received, the registered destination site information is included in the event, and the destination A message transfer means for transferring the event with the site corresponding to the site information or the site reachable to the site as the transfer destination of the event; Event notification service system.
  • (Appendix 2-2) The event notification service system according to attachment 1, wherein For each site, at least one address resolution server having address resolution means for performing address resolution of a relay server that is a transfer destination of the notification request or event in response to the notification request or the event transfer request,
  • the address resolution unit included in the address resolution server can receive the address resolution request from the relay server and reach the site corresponding to the destination site information included in the event related to the transfer request or the site. Selecting one relay server that forwards the event from among the plurality of relay servers belonging to a certain site, performing address resolution,
  • the message transfer means included in the relay server transfers the event to the relay server whose address is resolved by the address resolution means of the address resolution server.
  • Event notification service system For each site, at least one address resolution server having address resolution means for performing address resolution of a relay server that is a transfer destination of the notification request or event in response to the notification request or the event transfer request,
  • the address resolution unit included in the address resolution server can receive the address resolution request from the relay server and reach the site
  • the event notification service system according to attachment 2, wherein The address resolution server, for each site, the destination site information for identifying another site that can be reached from the site, and another address that performs an address resolution request to transfer predetermined data to the other site. And a routing table stored in association with the resolution server address information indicating the address of the resolution server, The address resolution means included in the address resolution server includes the resolution stored in the route table corresponding to the destination site information included in the event related to the transfer request in response to an address resolution request from the relay server. A plurality of relay servers belonging to the site corresponding to the destination site information included in the event related to the transfer request or a site reachable to the site, to another address resolution server specified by server address information Request address resolution of one relay server that forwards the event Event notification service system.
  • the relay server includes a transfer key including issue server identification information for identifying the event issue server and event identification information for identifying the event issued by the event issue server, and the event reachable from its own relay server.
  • a transfer table that associates in advance the site that is a transfer destination and a transfer destination address that represents an address of another relay server that is a transfer destination that transfers the event from its own relay server;
  • the message transfer means included in the relay server receives a transfer request for the event including the transfer key, and sets the transfer key in the transfer table to the same transfer key as the transfer key included in the event related to the transfer request. Forwarding the event to the relay server of the forwarding address associated with Event notification service system.
  • a notification request from a user terminal that requests the event issuing server to notify the event issuing server of an event issued from an event issuing server that issues an event is issued to the event issuing server or the event issuing server
  • a site formed by a server group including at least a plurality of the relay servers is formed by being connected via a plurality of networks, The relay server transfers the notification request from the user terminal including destination site information for identifying the site to which the user terminal belongs to the notification request, and relays the notification request to the site to which the event issuing server belongs.
  • the destination site information included in the notification request is registered as the event notification destination, the event transfer request is received, the registered destination site information is included in the event, and the destination A message transfer means for transferring the event with the site corresponding to the site information or the site reachable to the site as the transfer destination of the event; Relay server.
  • a notification request from a user terminal that requests the event issuing server to notify the event issuing server of an event issued from an event issuing server that issues an event is issued to the event issuing server or the event issuing server
  • a site formed by a server group including at least a plurality of relay servers for relaying and transferring an event to the user terminal is connected via a plurality of networks.
  • the notification request from the user terminal is transferred to the notification request including destination site information for identifying the site to which the user terminal belongs, and the relay server belongs to the site to which the event issuing server belongs.
  • An event issuing server for issuing events A notification request from a user terminal that requests notification of the event issued from the event issuing server to the event issuing server is sent to the event issuing server, or the event issued by the event issuing server is A plurality of relay servers that relay and transfer to the user terminal, and In an event notification service system formed by connecting a site formed by a server group including at least a plurality of the relay servers via a plurality of networks, The relay server forwards the notification request from the user terminal including destination site information identifying the site to which the user terminal belongs to the notification request, and the relay server transmits the notification request to the site to which the event issuing server belongs.
  • the destination site information included in the notification request is registered as the event notification destination, the event transfer request is received, the registered destination site information is included in the event, and the destination Forward the event with the site corresponding to the site information or the site reachable to the site as the forwarding destination of the event, Event notification service method.
  • the above-described program is stored in a storage device or recorded on a computer-readable recording medium.
  • the recording medium is a portable medium such as a flexible disk, an optical disk, a magneto-optical disk, and a semiconductor memory.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

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(N2)となり、分配木を最短パスツリー（SPT）を与えるダイクストラのアルゴリズムで作る際の計算量はO(N3)となる。
　この問題を解決するため、非特許文献６（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
　ここで、上記非特許文献６（H-MEDYM）では、複数のbroker（中継者）をクラスタ化するによりスケールアウトを実現しようとしている。しかし、あらかじめ、各クラスタで、イベントサブスペース毎に転送を行うmatcherノードを割当てておく必要があるので、ユーザ数や負荷に応じて動的に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 (8)

  1. 　イベントを発行するイベント発行サーバと、
    　前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備え、
    　少なくとも前記中継サーバを複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されており、
    　前記中継サーバは、前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送するメッセージ転送手段を備えた、
    イベント通知サービスシステム。
  2. 　請求項１に記載のイベント通知サービスシステムであって、
    　前記通知依頼あるいは前記イベントの前記転送要求に対して当該通知依頼あるいはイベントの転送先となる中継サーバのアドレス解決を行うアドレス解決手段を有するアドレス解決サーバを、前記サイト毎に少なくとも１つ備え、
    　前記アドレス解決サーバが有する前記アドレス解決手段は、前記中継サーバからのアドレス解決要求を受けて、前記転送要求にかかる前記イベントに含まれた前記宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトに属する複数の前記中継サーバのうち前記イベントを転送する１つの中継サーバを選択してアドレス解決を行い、
    　前記中継サーバが有する前記メッセージ転送手段は、前記アドレス解決サーバの前記アドレス解決手段にてアドレス解決された中継サーバに、前記イベントを転送する、
    イベント通知サービスシステム。
  3. 　請求項２に記載のイベント通知サービスシステムであって、
    　前記アドレス解決サーバは、前記サイト毎に、当該サイトから到達可能な他のサイトを識別する前記宛先サイト情報と、当該他のサイトに所定のデータを転送するためにアドレス解決要求を行う他のアドレス解決サーバのアドレスを表す解決サーバアドレス情報と、が関連付けられて記憶された経路テーブルを備えると共に、
    　前記アドレス解決サーバが有する前記アドレス解決手段は、前記中継サーバからのアドレス解決要求に応じて前記転送要求にかかる前記イベントに含まれる前記宛先サイト情報に対応して前記経路テーブルに記憶された前記解決サーバアドレス情報にて特定される他のアドレス解決サーバに、前記転送要求にかかる前記イベントに含まれた前記宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトに属する複数の前記中継サーバのうち前記イベントを転送する１つの中継サーバのアドレス解決を要求する、
    イベント通知サービスシステム。
  4. 　請求項１乃至３のいずれかに記載のイベント通知サービスシステムであって、
    　前記中継サーバは、前記イベント発行サーバを識別する発行サーバ識別情報と当該イベント発行サーバが発行する前記イベントを識別するイベント識別情報とを含む転送キーと、自己の中継サーバから到達可能な前記イベントの転送先となる前記サイトと、自己の中継サーバから前記イベントを転送する転送先となる他の中継サーバのアドレスを表す転送先アドレスと、を予め関連付けた転送テーブルを備え、
    　前記中継サーバが有する前記メッセージ転送手段は、前記転送キーを含む前記イベントの転送要求を受けて、当該転送要求にかかる前記イベントに含まれた前記転送キーと同一の転送キーに、前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに前記イベントを転送する、
    イベント通知サービスシステム。
  5. 　請求項４に記載のイベント通知サービスシステムであって、
    　前記中継サーバが有する前記メッセージ転送手段は、前記転送キーに含まれた前記発行サーバ識別情報と同一の情報を有する前記転送キーを前記転送テーブル内から検索し、当該検索された前記転送キーに前記転送テーブル内で関連付けられた前記転送先アドレスの中継サーバに前記イベントを転送する、
    イベント通知サービスシステム。
  6. 　イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する中継サーバであって、
    　少なくとも前記中継サーバを複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されており、
    　前記中継サーバは、前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送するメッセージ転送手段を備えた、
    中継サーバ。
  7. 　イベントを発行するイベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する中継サーバを、少なくとも複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されており、
    　前記中継サーバに、
    　前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送するメッセージ転送手段、を実現させるためのプログラム。
  8. 　イベントを発行するイベント発行サーバと、
    　前記イベント発行サーバから発行された前記イベントの通知を当該イベント発行サーバに対して依頼するユーザ端末からの通知依頼を前記イベント発行サーバに、あるいは、前記イベント発行サーバにて発行された前記イベントを前記ユーザ端末に、中継して転送する複数の中継サーバと、を備えると共に、
    　少なくとも前記中継サーバを複数含むサーバ群で形成されたサイトが複数ネットワークを介して接続されて形成されたイベント通知サービスシステムにて、
    　前記中継サーバが、前記ユーザ端末からの前記通知依頼を、当該通知依頼に前記ユーザ端末が属する前記サイトを識別する宛先サイト情報を含めて転送すると共に、前記イベント発行サーバが属する前記サイトに前記中継サーバが属する場合に、前記通知依頼に含まれる前記宛先サイト情報を前記イベントの通知先として登録し、前記イベントの転送要求を受けて、登録された前記宛先サイト情報を前記イベントに含めると共に当該宛先サイト情報に対応する前記サイトあるいは当該サイトに到達可能なサイトを前記イベントの転送先として当該イベントを転送する、
    イベント通知サービス方法。
     
PCT/JP2012/003808 2011-09-02 2012-06-12 イベント通知サービス方法およびシステム WO2013031069A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013531011A JP5942994B2 (ja) 2011-09-02 2012-06-12 イベント通知サービス方法およびシステム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2011-191226 2011-09-02
JP2011191226 2011-09-02

Publications (1)

Publication Number Publication Date
WO2013031069A1 true WO2013031069A1 (ja) 2013-03-07

Family

ID=47755604

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/003808 WO2013031069A1 (ja) 2011-09-02 2012-06-12 イベント通知サービス方法およびシステム

Country Status (2)

Country Link
JP (1) JP5942994B2 (ja)
WO (1) WO2013031069A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016092652A (ja) * 2014-11-06 2016-05-23 日本電信電話株式会社 非同期メッセージングサーバ連携方式の評価装置及び評価方法
CN115460303A (zh) * 2021-06-09 2022-12-09 中移(苏州)软件技术有限公司 一种数据处理方法、装置、终端及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005500741A (ja) * 2001-08-15 2005-01-06 プリキャッシュ・インコーポレーテッド ペイロード検査を介したパケット・ルート付け、及び発行−申し込みネットワークにおける申し込み処理

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005500741A (ja) * 2001-08-15 2005-01-06 プリキャッシュ・インコーポレーテッド ペイロード検査を介したパケット・ルート付け、及び発行−申し込みネットワークにおける申し込み処理

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KARI VISALA: "LANES: an inter-domain data-oriented routing architecture", REARCH '09 PROCEEDINGS OF THE 2009 WORKSHOP ON RE-ARCHITECTING THE INTERNET, 1 December 2009 (2009-12-01) *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016092652A (ja) * 2014-11-06 2016-05-23 日本電信電話株式会社 非同期メッセージングサーバ連携方式の評価装置及び評価方法
CN115460303A (zh) * 2021-06-09 2022-12-09 中移(苏州)软件技术有限公司 一种数据处理方法、装置、终端及存储介质

Also Published As

Publication number Publication date
JPWO2013031069A1 (ja) 2015-03-23
JP5942994B2 (ja) 2016-06-29

Similar Documents

Publication Publication Date Title
EP3046294B1 (en) System and method for efficient name-based content routing using link-state information in information-centric networks
Fang et al. A survey of energy-efficient caching in information-centric networking
Liu et al. A multi-level DHT routing framework with aggregation
EP2495940B1 (en) Method and computer program for collaboration between an internet service provider (ISP) and a content distribution system as well as among plural ISP
US10091012B2 (en) System and method for multi-source multicasting in content-centric networks
US10554555B2 (en) Hash-based overlay routing architecture for information centric networks
CN116915697A (zh) 基于源的路由
CN105162900A (zh) 一种多节点协作的域名解析和缓存方法及系统
JP5942994B2 (ja) イベント通知サービス方法およびシステム
Shinde et al. Content centric networks (CCN): A survey
JP5954330B2 (ja) イベント通知サービス方法およびシステム
CN113315704B (zh) 报文转发方法、sdn控制器、交换机及系统
KR102437289B1 (ko) 정보 중심 네트워크에서 프로듀서 이동성 지원을 위한 패킷 경로 설정 방법 및 장치
Do et al. Information-centric wireless sensor and actor network in the industrial network
Alduán et al. Architectures for future media Internet
Hassan et al. A taxonomy of information-centric networking architectures based on data routing and name resolution approaches
Banerjee et al. The survey, research challenges, and opportunities in ICN
Kassim et al. A flexible hybrid architecture for management of distributed web service registries
Guan et al. Name-based routing with on-path name lookup in information-centric network
AL-Naday et al. Service-based fog architecture without dns redirection
Kondo et al. ZINK: An efficient information centric networking utilizing layered network architecture
Bosunia et al. Efficient data delivery based on content-centric networking
Azgin et al. Hash-based overlay routing architecture for information centric networks
Aiash et al. Supporting communication in information centric networks using the location/ID split protocol and time released caching
Li et al. One-hop dht resolution of locator/id mapping

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12828850

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013531011

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12828850

Country of ref document: EP

Kind code of ref document: A1