JP2014528126A - Distributing multi-source push notifications to multiple targets - Google Patents

Abstract

Deliver events to consumers. The method includes accessing ownership data. The method further includes normalizing the ownership data to create a normalized event. Based on the subscription, a plurality of end consumers that are to receive the event are determined. Data from the normalization event is formatted into a number of different formats suitable for all determined end consumers. Data from the normalized event is delivered to each of the plurality of end consumers in a format suitable for the end consumer.

Description

  One embodiment of the present invention relates to the distribution of multi-source push notifications to multiple targets, for example.

  [0001] Computers and computing systems have affected almost every aspect of modern life. Computers are generally associated with work, entertainment, healthcare, transportation, entertainment, home management, and the like.

  [0002] Furthermore, computing system functionality can be enhanced by computing system capabilities that are interconnected to other computing systems via network connections. A network connection can include, but is not limited to, a connection via a computer to a wired or wireless Ethernet, mobile connection, or computer connection to a serial, parallel, USB, or other connection. The connection allows the computing system to access services at other computing systems and receive application data from other computing systems quickly and efficiently.

  [0003] Developers focused on general public news, information and facts about events around the world or for soccer, football, hockey, or baseball league or team sports fans to keep up to date, iOS, Android Mobile applications in Windows® phones, Windows®, etc. can be built. In any of these applications (and a wide range of other applications), notifications popping warnings or congratulations as favorite team scores of fans around the world or the cancellation of certain types of news events are a major differentiator It is. This differentiator builds and operates a server infrastructure to push these events to the operating system platform, or device vendor-supplied notification channel, which many mobiles focused on the optimized user experience. Beyond application developer technology combinations. And if this application is very successful, it is extremely difficult to distribute events to tens of thousands, hundreds of thousands, or millions of devices in a timely manner, so simple server-based The solution immediately hits the scalability barrier.

  [0004] In addition, many modern mobile applications have been described as simple experiences with existing Internet resources. For example, the news application can instantly display the latest headlines from an important news provider's RSS feed, since the user can open the application without having to navigate to a website. Individual software developers and small individual software vendors build many such applications and sell them at very low prices. These applications also benefit greatly from push notifications, but present difficulties not only in event distribution but also in event data acquisition. This is because acquisition, as well, requires building and operating an important server infrastructure.

  [0005] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is provided only to illustrate one example technology area where some embodiments described herein may be implemented.

  One embodiment of the present invention relates to the distribution of multi-source push notifications to multiple targets, for example.

  [0006] One embodiment illustrated herein includes a method of delivering events to consumers. The method includes accessing ownership data. The method further includes normalizing the ownership data to create a normalized event. It is determined that multiple end consumers should receive the event based on the subscription. Data from the normalization event is formatted into a number of different formats that are individually appropriate for each end consumer determined. Data from the normalization event is conveyed to each end consumer in a format that is appropriate for each end consumer and consistent with the protocol rules defined by the target infrastructure through which the consumer reaches.

  [0007] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential characteristics of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

  [0008] Additional features and advantages are set forth in the description that follows, and in part are obvious from the description, or can be learned by practice of the teachings herein. The features and advantages of the invention may be realized and obtained by means of the instruments or combinations particularly pointed out in the appended claims. The features of the invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.

  [0009] To illustrate the manner in which the above and other advantages and characteristics can be obtained, a more specific description of the subject matter briefly described above is given by way of example in the specific embodiments illustrated in the accompanying drawings. Shown with reference to With the understanding that these drawings depict only typical embodiments and are therefore not to be considered limiting in scope, the embodiments will be described with additional features and details through the use of the accompanying drawings. Described and explained.

[0010] FIG. 1 illustrates an overview of a system that collects event data, maps the event data to an overall event, and distributes the event data to various target consumers. [0011] FIG. 1 illustrates an event data acquisition and distribution system. [0012] FIG. 1 illustrates an example of an event data acquisition system. [0013] FIG. 1 illustrates an example of an event data distribution system. [0014] FIG. 1 illustrates an event data acquisition and distribution system. [0015] FIG. 5 illustrates an implementation of a badge counter function. [0016] FIG. 6 illustrates a method for delivering an event to a consumer.

  [0017] Embodiments can combine an event acquisition system with a notification distribution system and a mapping model that maps events to notifications. Embodiments can also filter notifications based on subscription provision criteria. Further, embodiments can have depth capabilities such as tracking delivery counts for individual targets in an efficient manner.

  [0018] One such example is shown in FIG. FIG. 1 shows an example where information from a number of different sources 116 is conveyed to a number of different targets 102. In some examples, information from a single source or information aggregated from multiple sources 116 can be used to create a single event that is carried to multiple targets 102. Note that the indicator 102 can be used to refer collectively to all targets, or generally individual targets. A particular individual target is specified by another discriminator.

  [0019] FIG. Note that the indicator 116 can be used to refer collectively to all sources, or generally individual sources. A particular individual source is specified by another discriminator. Sources 116 include, for example, a wide range of public and private network services, including, but not limited to, RSS, Atom, and OData feeds, email mailboxes including such support for IMAP and POP3 protocols, and Twitter. Social network information sources 116, such as timelines or Facebook walls, and subscriptions for external public / subscription infrastructure, such as the Windows Azure ™ service bus or Amazon's simple queue service.

  [0020] The source 116 can be used to obtain event data. As described in more detail below, source 116 can be organized into acquisition topics, such as acquisition topic 140-1. Event data can be mapped to a normalized event generally indicated at 104. The normalized event 104 can be mapped to notifications for a particular target 102 by one or more mapping modules 130. The notification 132 represents a notification for the specific target 102. A single event 104 can be mapped to many different notifications, where it will be appreciated that the different notifications are in different formats suitable for distribution to many disparate targets 102. For example, FIG. Target 102 supports many different message formats depending on the target characteristics. For example, some targets 102 may support notifications in a relay format, while other targets 102 notify in an MPNS (Microsoft® Push Notification Service) format for Windows® 7 phones. Other targets 102 can support notifications in APN (Apple Push Notification) format for iOS devices, and other targets 102 can support C2DM (Cloud to Device Messaging) format for Android devices. Other targets 102 can support notifications in the JSON (Javascript Object Notation) format for browsers on the device, and other targets 1 2, you are possible to support the notification, such as HTTP (hypertext transfer protocol).

  Accordingly, mapping by the mapping module 130 can map a single event 104 created from information from one or more data sources 116 to many different notifications for different targets 102. Different notifications 132 can then be carried to various targets 102.

  [0022] This may be achieved in some embodiments using a fan-out topology as shown in FIG. FIG. 2 shows the source 116. As discussed herein below, embodiments may utilize acquisition partition 140. Each acquisition partition 140 can include a number of sources 116. Potentially there can be many and diverse sources 116. Source 116 provides information. Examples of such information include, but are not limited to, e-mails, text messages, real-time stock prices, real-time sports scores, and news updates.

  [0023] FIG. 2 shows that each partition includes an acquisition engine, such as the exemplary acquisition engine 118. Acquisition engine 118 collects information from source 116 and generates an event based on the information. In the example shown in FIG. 2, many events are shown to be generated by the acquisition engine using various sources. Event 104-1 is used as an example. In some embodiments, the event 104-1 can be normalized as further described herein. Acquisition engine 118 may be a service on a network, such as the Internet, that collects information from source 116 on the network.

  FIG. 2 shows that event 104-1 is sent to distribution topic 144. Distribution topic 144 causes the event to fan out to many distribution partitions. Distribution partition 120-1 is used as an analog for all of the distribution partitions. Each distribution partition serves a number of end users or devices indicated by subscriptions. The number of subscriptions served by the distribution partition may be different from the number of other distribution partitions. In some embodiments, the number of subscriptions served by the partition may depend on the capacity of the distribution partition. Alternatively, or in addition, a distribution partition can be selected to provide services to users based on logical or geographical proximity to the end user. This allows alerts to be conveyed to end users in a more timely manner.

  [0025] In the illustrated example, distribution partition 120-1 includes distribution engine 122-1. The distribution engine 122-1 refers to the database 124-1. Database 124-1 includes information regarding subscriptions with details regarding the associated delivery target 102. In particular, the database may include information such as information describing a platform for the target 102, an application used by the target 102, a network address for the target 102, a user preference of an end user using the target 102, and the like. Using information in database 124-1, distribution engine 122-1 builds bundle 126-1 where bundle 126-1 is event 104 (or at least information from event 104) and event 104. -1 includes a routing slip 128-1 that identifies a plurality of targets 102 among the targets 102 to which information from -1 is transmitted as a notification. The bundle 126-1 is then placed in the queue 130-1.

  [0026] Distribution partition 120-1 may include a number of distribution engines. The delivery engine removes the bundle from the queue 103-1, and carries the notification to the target 102. For example, the distribution engine 108-1 may remove the bundle 126-1 from the queue 13-1 and send event 104 information to the target 102 identified in the routing slip 128-1. Thus, notifications 134 that include event 104-1 information can be sent to the target 102 from various distribution partitions in a number of different formats that are appropriate for different targets 102 and specific to individual targets 102. This allows individualized notifications 134 that are individualized to individual targets 102 to be created from the common event 104-1 at the edge of the distribution system, rather than carrying multiple individualized notifications through the distribution system.

[0027] The following illustrates an alternative description of an information collection and event distribution system that can be used in some embodiments.
[0028] As a basis, the system of one embodiment uses a public / subscribe infrastructure such as that provided by the Windows (R) Azur Service Bus commercially available from Microsoft Corporation of Redmond, Washington, and various It exists in a similar way in other messaging systems. The infrastructure provides two capabilities, topics and queues that facilitate the described implementation of the presented method.

  [0029] Queues store messages for messages that allow messages to be added (added to the queue) in a sequential order and removed (removed from the queue) in the same order that they were added. Structure. Messages can be added and removed by any number of parallel clients, allowing leveling of the load on the side that adds to the queue and parallelization of the processing load across the receivers that remove it from the queue. The queue also allows an entity to obtain a lock on the message when it is removed from the queue, so that when the message is actually removed from the queue or processing of the retrieved message fails Allows explicit control of the consuming client as to whether it can be recovered in the queue.

  [0030] A topic has all the characteristics of a queue, but allows multiple concurrent "subscriptions", each allowing a quarantined and filtered view of the sequence of messages added to the queue. Structure. Each subscription on the topic creates a copy of each message added to the queue, provided that the associated filter state (s) of the subscription (s) reliably match the message. As a result, messages queued in a topic with 10 subscriptions, each with a simple “pass-through” state that matches all messages, produces a total of 10 messages for each subscription. A subscription, like a queue, can have multiple parallel consumers that provide parallel processing load across the receivers.

  [0031] Another fundamental concept is that of "events", which are simply messages in the sense of the underlying public / subscribe infrastructure. In one embodiment, events are subject to a set of simple constraints that govern the use of message bodies and message characteristics. The message body of the event generally flows as an opaque data block, and any event data considered by one embodiment is typically a message that is a set of key / value pairs that are part of the message indicating the event. Flows within the characteristics.

  [0032] Referring now to FIG. 3, the architectural goal of one embodiment is to obtain event data from a wide variety of different sources 116 on a large scale and place these events in the public / subscribe infrastructure for further processing. Is to transfer. Processing can include several forms of event analysis, real-time investigation, or redistribution to interested subscribers through a pull or push notification mechanism.

  [0033] The architecture of one embodiment includes an acquisition engine 118, an acquisition adapter and model for event normalization, a partitioned store 138 that holds metadata about the acquisition source 116, a common partitioning and scheduling model, and further database searches. Define a model for how user-initiated changes in the state of the acquisition source 116 flow through the system at runtime without need.

  [0034] In a specific implementation, retrieval is a wide range of public and private network services, including, but not limited to, RSS, Atom, and OData feeds, including email support including such support for IMAP and POP3 protocols Specific acquisition of source events from subscriptions on social network information sources 116 such as Box, Twitter Timeline or Facebook Wall, and external public / subscribing infrastructure such as Windows Azur ™ Service Bus or Amazon Simple Queue Service Can support adapters.

[0035]
Event normalization Event data is normalized to make the event actually consumable by subscribers on the public / subscribe infrastructure being handed over. Normalization means that in this context, events are mapped on top of a common event model with a consistent display of information items that may be of interest to a wide range of subscribers with varying content. To do. The selected model is here a simple representation of events in the form of a uniform list of key / value pairs that can accompany a single opaque binary quantity of data that is not further interpreted by the system. Such a display of events can be easily displayed on many public / subscribe infrastructures and maps very well to common Internet protocols such as HTTP.

  [0036] To illustrate event normalization, consider the mapping of RSS or Atom feed entries into event 104 (see FIGS. 1 and 2). RSS and Atom are very widely used to publish news and other current information, often in chronological order, helping to make that information available for processing within a computer program in a structured manner. Internet standards. RSS and Atom are very similar structures and have different names but share a collection of semantically identical data elements. Thus, the first normalization step defines a common name as a key for such semantically identical elements defined in both standards, such as name or summary. Second, data that only occurs in one but other standards is usually mapped with their “native” names. Moreover, these types of feeds often carry “extensions”, which are data items that are not defined in the core standard, but use extensibility in each standard to add additional data.

  [0037] Some of these extensions, including but not limited to GeoRSS for geolocation or OData for embedding structured data in an Atom feed, are shared across different event sources 116 The subscribers on the public / subscribing infrastructure that are mapped in such a way that the event is fired can be located in a uniform manner regardless of whether the data is obtained from RSS or Atom, or Twitter timeline. Can be interpreted. Following the GeoRSS example, a simple GeoRSS expression that indicates a geography “point” can thus be mapped to a pair of numeric “latitude” / “longitude” properties indicating WGS84 coordinates.

  [0038] Extensions that carry complex structured data, such as OData, can implement complex type structures and mapping models that store data without complicating the underlying event model. Some embodiments normalize to canonical and compact composite data representations such as JSON, eg, map the OData property “tenant” of the composite data type “person” to a key / value pair, where the key is the property name “tenant” The value is composite data describing a person with name, background information, and address information shown in JSON serialized form. If the data source is an XML document, as with RSS or Atom, the value transcribes the XML data to a JSON that stores the structure provided by XML, but flattens XML specialities such as attributes and elements Both XML attributes of the same XML element node and XML attributes and elements that are subordinate concepts of the element are mapped to JSON properties as “siblings” with no distinction.

[0039]
Sources and Partitioning The architecture of one embodiment stores metadata about the data source 116 in a “source description” record that can be stored in the source database 138. A “source description” can have a set of common elements and a set of elements specific to a data source. Common elements may include the name of the source, the time interval during which the source 116 is considered valid, a human readable description, and a differentiating type source 116. Source specific elements depend on the type of source 116 and provide data in a specific way, such as providing a network address, authentication information, or a resource indicated by the address, and a time interval to check the RSS feed. If it is an end-to-end experience that is to be acquired or built, at least 60 seconds away from the current event news feed so that the notification recipient has an opportunity to see each breaking news item on the constrained screen surface May include any security key material to gain access to metadata that instructs the source acquisition adapter to do any specific way of forwarding events, such as spacing the acquired events it can.

  [0040] The source description is maintained in one or more stores, such as source database 138. The source description can be split among them across these stores along two different axes.

  [0041] The first axis is differentiation by system tenant. A system tenant, or “namespace”, is a mechanism for creating an isolated range for entities within a system. Shows the specific case where “Fred” is a user of a system implementing an embodiment, and Fred maintains a source description and configuration and state that is completely independent of other sources 116 in the system. It is possible to create a tenant range that provides Fred with an isolated virtual environment. This axis is also particularly relevant when tenants require the isolation of stored metadata (which may contain highly sensitive data such as passwords) or for technical, regulatory or business reasons. Can act as a differentiator to spread source descriptions across. The system tenant can also indicate an affinity to a particular data center from which the source description data is retained and from which data acquisition is performed.

  [0042] The second axis can be a distinction by a numeric partition identifier selected from a predefined identifier range. The partition identifier can be derived from invariant conditions included in the source description, such as, for example, the source name and tenant identifier. The partition identifier is a hash function (one of many candidates is Jenkins hash, see http://www.burtleburtle.net/bob/hash/dobs.html). The resulting hash value is computed into the partition identifier range, possibly using a modulo function on the hash value. The identifier range is chosen to be larger than the most storage partitions expected to be needed to store all the source descriptions that are always kept in the system (which can be substantially larger).

  [0043] Introducing storage partitions is a capacity limitation that is immediately related to storage capacity allocation for the underlying data store, or that affects the acquisition engine 118, such as bandwidth constraints for a given data center or data center portion. In an embodiment that creates an acquisition partition 140 that is normally motivated by capacity limitations, and thus utilizing capacity across different data centers or data center segments, to meet intrusion bandwidth requirements. There is a possibility of connection. The storage partition owns a subset of the overall identifier range, and the relevance of the source description record with the storage partition (and the resources needed to access it) can therefore be inferred directly from its partition identifier. it can.

  [0044] Beyond providing a storage partition axis, partition identifiers are also used in scheduling or acquisition jobs to acquire partition 140 for a given source description (potentially different from its relationship to storage partitions). Clearly defines the ownership relationship.

[0045]
Owning and Acquisition Partition Each source technology in the system can be owned by a specific acquisition partition 140. Clear and proprietary ownership is used because the system does not get events from the exact same source 116 in parallel at multiple locations when there is a possibility of emitting duplicate events. To make this more specific, one RSS feed defined within the tenant is owned by exactly one acquisition partition 140 in the system, and within the partition any given time in time There is one scheduled acquisition run on a particular feed at a point.

  [0046] The acquisition partition 140 obtains ownership of the source description in a manner that obtains ownership of the partition identifier range. The identifier range can have failover capability, using an external dedicated partitioning system that can be assigned a master / backup owner, or across many individual calculations where the partition identifier range assumes an acquisition engine role A simpler mechanism that spreads evenly can be used to assign to the acquisition partition 140. In a more sophisticated implementation with an external split system, the chosen master owner of the partition is responsible for seeding the job scheduling when the system starts from a “cooled” state, which means that the partition It means that he did not have a previous owner. In a simpler scenario, a calculation example that owns a partition owns seeding scheduling.

[0047]
Scheduling Scheduling demand for an acquisition job depends on the nature of the specific source, but there are generally two types of acquisition models implemented in some of the described embodiments.

  [0048] In the first model, the owner initiates some form of connection or long-term network request on the source network service and allows data to be returned on the connection in the form of a datagram or stream. wait. In the case of long-term requests, also commonly referred to as long-term polling, the source network service keeps the request until a timeout occurs or data becomes available, after which the capture adapter has or does not have a payload result Wait for the request to complete, then reissue the request. As a result, this acquisition scheduling model is used when the owner of the source 116 learns about the source and when a new request or connection is started as soon as the current connection or request is completed or temporarily suspended. It is in the form of a “tight” loop that begins. When the owner is in immediate control of the tight loop, the loop can be reliably kept alive while the owner is executing. When the owner stops and resumes, the loop resumes. When ownership changes, the loop stops and the new owner starts the loop.

  [0049] In the second model, the source network service does not support long-term request or connection creation data when it becomes available, but is a normal request / response service that returns as soon as queried. is there. For such a service, this is true for many web resources, requesting data in a continuous tight loop, causing a huge amount of load on source 116 and that source 116 did not change. , Or in the worst case, cause any significant network traffic that carries the same data over and over again. In order to parallelize the demand for timely event acquisition and not overload the source 116 with useless query traffic, the acquisition engine 118 therefore executes the request within a “timing” loop, and the request on the source 116 These considerations are executed in parallel, and periodically based on intervals that consider the hints from the source 116. The “timing” loop begins when the owner of the source 116 learns about the source.

  [0050] There are two noteworthy implementation variant types for timed loops. The first variant is a low-scale best effort scenario, which uses a local in-memory timer object for scheduling, which makes the size, control and restart features similar to those of tight loops . A loop is started and a timer callback is scheduled immediately to execute the first iteration of the acquisition job. If it is determined that the job is complete (even if there is an error) and the loop is to continue executing, another timer callback is scheduled at the next time the job is executed.

  [0051] The second variant uses a "scheduling message", which is a characteristic of several public / subscription systems, including the Windows Azure ™ service bus. The variant type provides a much higher acquisition scale at the expense of some higher complexity. The scheduling loop is initiated by the owner and the message is placed in the acquisition partition's scheduling queue. The message includes a source description. It is later picked up by workers who perform an acquisition job and then add the resulting event to the query in the target public / subscription system. Finally, a new “scheduling” message is also added to the scheduling queue. The message is called “scheduled”. This is because it is marked at the moment it becomes available for search by any consumer on the scheduling queue.

  [0052] In this model, the acquisition partition 140 is a single "owner" that can be paired with any number of "worker" roles that primarily seed scheduling and perform actual acquisition jobs. It is possible to scale out by having the role of

[0053]
When the source update system is in operation, the acquisition partition 140 needs to be able to learn about new sources 116 to be observed and which sources 116 should no longer be observed. This decision typically depends on the user, except in the case of blacklisting the source 116 (as described below) due to an unrecoverable or transient error detected, and the management service 142 Is the result of the interaction. In order to communicate such changes, the acquisition system maintains a “source update” topic within the underlying public / subscription infrastructure. Each acquisition partition 140 has a dedicated subscription for the topic with a filter condition that constrains messages that are eligible for those that carry the partition identifier within the owned range of the acquisition partition. This allows the management service 142 to set up updates for new or retired resources 116 and send them to the correct partition 140 without requiring knowledge of partition ownership distribution.

  [0054] The management service 142 presents an update command in a topic that includes a source description, a partition identifier (for the above filtering purposes), and an action identifier that indicates whether the source 116 should be added or removed from the system. To do.

  [0055] When the owner of the acquisition partition 140 retrieves the command message, it schedules a new acquisition loop for the new source 116, or interrupts or even leaves the existing acquisition loop.

[0056]
Blacklisting Sources 116 that failed to acquire data can be blacklisted temporarily or permanently. Temporary blacklisting occurs when the source 116 network resource is not available or returns an error that is not immediately related to the reissued acquisition request. The period of temporary blacklisting depends on the nature of the error. Temporary blacklisting interrupts the normal scheduling loop (tight or timing) and follows the loop (by callback or scheduling message) for the moment when the error condition is expected to be resolved by others. This is done by scheduling iterations.

  [0057] Permanent blacklisting is performed when the error is determined to be an immediate result of an acquisition request, the request has caused an authentication or authorization error, or the remote source 116 has some other Indicates a request error. If the resource is permanently blacklisted, the source 116 is marked as blacklisted in the partition store and the acquisition loop is immediately aborted. To permanently revert the blacklisted source 116, presumably remove the blacklist marker in the store along with the configuration change that causes a change in behavior to the request and restart the acquisition loop via the source update topic. There is a need.

[0058]
Notification Distributing Embodiments to distribute a copy of information from a given input event to each of a number of “targets 102” associated with a particular range, and to do so with a minimum amount of time for each target 102. Can be configured. Target 102 is the address of a device or application coupled to the identifier of some third party notification system or adapter to some network accessible external infrastructure and auxiliary data to access that notification system or infrastructure Can be included.

  [0059] Some embodiments may include an architecture that is divided into three separate processing roles, which are described in detail below and can be understood with reference to FIG. As noted with “1” in FIG. 4, each processing role ellipse and “n” may have one or more examples of processing roles. The use of “n” in each case should be considered distinct from each other case as applied to a processing role, meaning that each processing role need not have the same number of examples. Please note that. The role of the “distribution engine” 112 allows events and bundles them together with routing slips that include groups of targets 102 (see, for example, routing slip 128-1 in FIG. 2). A “distribution engine” 108 authorizes these bundles and handles routing slips for distribution to the network location indicated by the target 102. The “management role” indicated by the management service 142 provides an external API to manage the target 102 and is responsible for accepting statistical and error data from the delivery engine 108 and processing / storing that data. .

  [0060] The data flow is anchored on a "distribution topic 114" in which events are presented for distribution. The presented events are labeled with relevant ranges, which may be one of the above constraints that distinguish between events and raw messages using message properties.

  [0061] Distribution topic 144 has one pass-through (unfiltered) subscription per "distribution partition 120" in the illustrated example. A “distribution partition” is an isolated set of resources that are responsible for distributing and delivering notifications to a subset of targets 102 in a given range. A copy of each event sent within a distribution topic is available to distribution partitions configured all at the same time, effectively through these associated subscriptions, allowing for parallel distribution operations.

  [0062] Parallelization by partitioning helps to achieve timely distribution. To understand this, consider the range with 10 million targets 102. If the target data is kept in a non-partitioned store, the system must examine each single large database result set in turn or using a partitioning query on the same result set If acquired, the throughput to acquire the target data must be adjusted at least by the throughput ceiling of the given store's pre-network gateway infrastructure, so that the descriptive record is within the given result set. The delivery waiting time for delivery of notifications to the target 102, which occurs very late, may not be satisfactory.

  [0063] Instead, 10 million targets 102 are distributed across 1,000 stores, each holding 10,000 target records, and these stores execute the queries, as described herein When paired with a dedicated computing infrastructure ("distribution engine 122" and "distribution engine 108" as described herein) that processes the results in a form, target description retrieval can span a broad set of computational and network resources. It can be parallelized and the time difference for the distribution of all events measured from the first event distributed to the last event can be significantly reduced.

[0064] The actual number of distribution partitions is not technically limited. It can range from a single partition to any number of partitions greater than one.
[0065] In the example shown, when the "distribution engine 122" for the distribution partition 120 gets the event 104, it first calculates the size of the event data and then calculates the size of the routing slip 128, which It can be calculated based on the difference between the size and the lesser of the maximum allowed message size and absolute size ceiling of the underlying messaging system. Events are limited in dimensions such that there is some minimal headroom for “routing slip” data.

  [0066] The routing slip 128 is a list that includes a description of the target 102. The routing slip performs a search query that matches the event range against the target 102 held in the partition store 124, and reduces the selection based on the event range and filtering conditions on the event data to another set of conditions. Created by the distribution engine 122 by returning all matching targets 102. Embodiments can include a time window condition that limits the results to those targets 102 that are considered valid at the current moment among these filter conditions, where the current UTC time is the target description It means that it is within the start / end validity time window included in the record. This capability is used for blacklisting as described later in this document. When the search results are examined in detail, the engine creates a copy of the event 104, fills the routing slip 128 to the maximum size with the target description retrieved from the store 124, and then partitions the resulting bundle of events and routing slip. To the “delivery queue 130”.

  [0067] Routing slip technology ensures that the event flow rate of events from the distribution engine 122 to the distribution engine (s) is higher than the actual message flow on the underlying infrastructure, for example , Where 30 target descriptions can be packed into the routing slip 128 by the event data, the flow rate of the event / target pair is 30 times higher than if the event / target pair was immediately grouped into a message It means that.

  [0068] Distribution engine 108 is a consumer of event / routing slip bundle 126 from distribution queue 130. The role of the delivery engine 108 is to remove these bundles from the queue and deliver the event 104 to all destinations listed in the routing slip 128. Delivery usually occurs through adapters that formalize event messages into notification messages understood by the respective target infrastructure. For example, notification messages include MPNS format for Windows 7 phones, APN (Apple Push Notification) format for iOS devices, C2DM (Cloud to Device Messaging) format for Android devices, JSON for browsers on devices (Java script object notation) format, HTTP (hypertext transfer protocol), etc. can be distributed.

  [0069] Distribution engine 108 typically parallelizes distribution across independent targets 102 and serializes distribution to targets 102 that share the scope implemented by the target infrastructure. An example of the latter is that a specific adapter in the delivery engine can choose to send all events targeted by a specific target application on a specific notification platform through a single network connection. It is.

  [0070] The distribution and distribution engines 122 and 108 are decoupled using the distribution queue 130, allowing the distribution engine 108 to scale its own, preventing slowing of distribution and the distribution query / packaging stage. To block.

  [0071] Each distribution partition 120 may have any number of distribution engine instances observing the distribution queue 130 simultaneously. The length of the delivery queue 130 can be used to determine how many delivery engines are active at the same time. If the queue length crosses a certain threshold, a new distribution engine example can be added to partition 120 to increase transmission throughput.

  [0072] Distribution partition 120, and associated distribution and distribution engine examples, can be scaled up in a substantially unlimited manner to achieve optimal parallelism at high scale. If the target infrastructure is capable of receiving and forwarding 1 million event requests to devices in a parallel manner, the described system can potentially distribute events across its distribution infrastructure, The target infrastructure is loaded with event presentations for delivery to all desired targets 102 in a timely manner that allows the target infrastructure to be loaded and given any allowed delivery quotas. It is possible to utilize network infrastructure and bandwidth across the data center in a manner that can be saturated.

  [0073] As messages are delivered to the target 102 via their respective infrastructure adapters, in some embodiments, the system notes the range of statistical information items. Among these, the duration between receipt of the delivery bundle and delivery of every individual message, and the duration for the duration of the actual transmission operation is measured. A part of the statistical information is an index relating to whether the distribution has succeeded or failed. This information is collected within the distribution engine 108 and rounded to an average value for each range and for each target application. A “target application” is a grouping identifier introduced for a specific purpose of a statistics rollup. The calculated average value is transmitted to the delivery statistics queue 146 at a specified interval. This queue is drained by (a set of) workers in the management service 142 that present event data to the data warehouse for a range of purposes. These objectives may include, in addition to operational monitoring, billing of the tenant to which the event is delivered and / or disclosure of statistics to the tenant for a third party's own billing.

  [0074] When delivery errors are detected, these errors are classified as temporary and permanent error conditions. Temporary error conditions can include, for example, a network failure that prevents the system from reaching a target infrastructure distribution point, or a target infrastructure that reports that a distribution allocation has been temporarily reached. Permanent error conditions include, for example, authentication / authorization errors on the target infrastructure, or no human intervention and error conditions that the target infrastructure reports that the target is no longer available or wants to permanently receive messages List other errors that cannot be fixed with. Once classified, an error report is presented to the delivery failure queue 148. In transient error conditions, the error can also include an absolute UTC timestamp until the error condition is expected to be resolved. At the same time, the target is blacklisted locally by the target adapter for any further local distribution by this example distribution engine. The blacklist can also include a time stamp.

  [0075] The delivery failure queue 148 is drained by (a set of) workers in a management role. Permanent errors can cause each target to be immediately deleted from each distribution partition store 124 to which the management role has access. “Delete” means that the record is actually removed, or otherwise moved simply invisible to the search query by the rule setting the “end” timestamp of its validity period to the error timestamp. It may mean that A temporary error condition may cause the target to stop for the period indicated by the error. The outage can be done by moving the target validity period to the time stamp indicated in the error where the error condition is expected to be corrected.

FIG. 5 shows a schematic diagram of a system where acquisition partition 140 is coupled to distribution partition 120 through distribution topic 144.
[0077] As noted above, in some embodiments, the overall event 104 may be created from information from the source 116. The overall event can be in an overall format that can later identify the data and place it in a platform specific format. The following are many examples of expressions that can map the overall event properties implemented in one embodiment to a specific platform notification.

  [0078] $ (name) or. (Name) or> (name) A reference to an event property with a given name. Property names are not case sensitive. A property name can be a “dot” expression (eg, a property item) if the value of the referenced property includes complex type data in the form of a JSON string string expression. This expression breaks down into the text value of the property, or an empty string if the property doesn't exist. The value may be clipped by the target size constraint for the target field.

  [0079] $ (name, n), as above, but the text is clearly clipped with n characters. For example, $ (title, 20) clips the contents of the title property with 20 characters.

  [0080]. (Name, n), as above, but since the text is clipped, it is suffixed with 3 dots. The total size of the clipped string and suffix does not exceed n characters. Has the input property "This is a title line". (Title, 20) results in "This is the title".

[0081] Similar to% (name) and $ (name), except that the output is an encoded URI.
[0082] $ body refers to the entity body of the event. The entity body can contain any data including binary data and is not clippable because it can be passed through the system as is. When $ body is mapped to a text property on the target, in some embodiments, the mapping only succeeds if the body contains the text content. If the entity body is empty, the expression is decomposed into an empty string.

  [0083] $ count refers to the count per target of events delivered from a given source. This equation breaks down into a number calculated by the system that indicates how many messages each target has received from this source 116 since the last request to reset this counter. In some exemplary embodiments, this number has a range of 0 to 99. When the counter reaches 99, the value does not increase further. This value is typically used for badges and tile counters.

  [0084] '[. . text. . . ] 'Or "[..text ...]" is a literal. A literal contains any text enclosed in single or double quotes. The text can include special characters in the form of escapes according to the JavaScript escape rules (see ECMA-262, 7.8.4). expr1 + expr2 is a concatenation operator that combines two expressions into a single character string. The formula may be any of the above.

  [0085] expr1? ? expr2 is a conditional operator that determines the value of expr1 if it is not zero or a zero-length character string, and determines the value of expr2 otherwise. ? ? The operator has a higher priority than the + operator, i.e. the expression 'p' + $ (a)? ? $ (B) yields the value of a or b prefixed with the literal 'p'.

  [0086] Embodiments may use a mapping language to take properties from the event 104 and map them to the correct location for notification on the target 102.

  [0087] Tile notifications for Windows Phone can also make use of the $ count property, which automatically records the count.

  [0088] In the iPad app, embodiments can map this to a warning as shown below.

  [0089] Or just a badge (counter) on the app icon.

  [0090] In some embodiments, the default for these mappings is that each target property is mapped to an input property with the same name. Embodiments can therefore specify targets for Windows phones as simply as this.

Also, Text1, Text2, and Param are automatically mapped from message properties having the same name on the input event and are empty (not sent) if there is no such property. This allows complete source side control of the properties when source 116 is under development control, as is the case with Windows Azure ™ service bus queues and topic subscriptions.

  [0091] In Google Android, the C2DM service does not define a fixed format for notifications and there is no immediate relationship into the Android user interface shell, so the mapping is somewhat different, so that the mapping is based on the target property, It takes the form of a free-form property bag with expressions as values. If the property map is omitted, all input properties are mapped straight to the C2DM endpoint.

[0092]
Selection Notification Distribution The embodiments described herein enable notification targets 102 in a broadcast system to distribute events from an event stream to targets based on geographic, demographic, or other criteria. A function can be implemented that allows to subscribe to an event stream that provides criteria to enable.

  [0093] In particular, event data may have various categorization data. For example, events can be geotagged. Alternatively, events can be categorized by source, such as by including an event category string.

  [0094] Referring again to FIG. 1, as described above with reference to various figures, the event 104 can include various types of categorization data. For example, the event can include a geotag whose geographic coordinates are included in the alert. Distribution engine 122-1 can examine events to find geotagged data. The distribution engine 122-1 can also consult the database 124-1 to determine targets 102 that are interested in data having a geotag. For example, the user can specify the location or the overall location. The user can specify that any alerts associated with that location or within 5.045 kilometers (5 miles) of that location should be conveyed to the user. Distribution engine 122-1 can determine whether a geotag in the data is included in this specification. If so, then distribution engine 122-1 may include that particular user in routing slip 128-1 for event 104. Otherwise, the user can be excluded from the routing slip and no notification with warning 104 is received.

  [0095] For geotagged events, the user (or other entity control notifications and event delivery to the user) can identify any of a number of different boundaries. For example, by identifying every location within 5.045 kilometers (5 miles) of a given location, we basically identify a point and a circle around that point. However, other embodiments may include geopolitical boundary specifications such as a city, state, country, or continent, a shape of a building or complex, and the like. SQL Server® from Microsoft Corporation of Redmond, Washington has a geospatial capability that can be used as part of distribution partition 120-1 to determine target 102 for delivering events. Have.

  [0096] Generally, event data may include categorization information. For example, a character string included in an event can categorize event data. Including a target in routing slip 128-1 may be based on a user choosing or not choosing from within a category. For example, target 102-1 can select a category and compare categorized strings on event 104-1. If event 104-1 includes a string indicating the selected category, then target 102-1 may be bundled 126-1 such that a notification with data from event 104-1 is carried to target 102-1. Are included in the routing slip 128-1.

[0097]
Badge Counters The described embodiments allow individual counters to be tracked within an event broadcast system without requiring separate tracking of the counter for each end user. This can be accomplished by a server receiving a series of events, where each event in the series is associated with a list of timestamps. The list of time stamps for each event includes a time stamp for the event and a time stamp for all previous events in the series.

  [0098] The user sends a time stamp to the server. The time stamp is an indication of when the user has performed some user interaction with the user device. For example, the time stamp may be an indication of when the user opened an application on the user device. The server compares the timestamp sent by the user with a list of timestamps for the event that is about to be sent to the user. The server counts the number of time stamps in the list of time stamps for events that are about to be sent to the user that occurs after the user has sent a time stamp, and sends this count as a badge counter.

  [0099] An example is shown in FIG. 6 attached hereto. FIG. 6 shows the target 102-1. Target 102-1 receives event 104 and badge counter 106 from distribution engine 108-1. The target 102-1 transmits the time stamp 110 to the distribution engine 108-1. The timestamp 110 sent by the target 102-1 to the distribution engine 108-1 may be based on a number of actions at the target 102-1. For example, the user can open an application associated with the event 104 and badge counter 106 sent by the distribution engine 108-1 to the target 102-1. By opening the application, the time stamp 110 can be emitted from the target 102-1 to the distribution engine 108-1 indicating when the application is opened.

  [00100] The delivery engine 108-1 receives a series of events 112 (shown as 104-1, 104-2, 104-3, and 104-n). Each event in the sequence of events 112 is associated with a list of time stamps 114-1, 114-2, 114-3, or 114-n, respectively. Each list of timestamps includes a timestamp for the current event and a timestamp for each event in the series prior to the current event. In the example shown, event 104-1 is the first event sent to distribution engine 108-1 for distribution to target 102. Accordingly, list 114-1 associated with event 104-1 includes a single entry T1 corresponding to the time at which event 104-1 was sent to distribution engine 108-1. Event 104-2 is transmitted to distribution engine 108-1 after event 104-1, and thus the time stamp T1 and the corresponding time stamp when event 104-1 and 104-2 are transmitted to distribution engine 108-1, respectively. Associated with list 114-2 that includes T2. Event 104-3 is sent to distribution engine 108-1 after event 104-2, and thus corresponds to when events 104-1, 104-2 and 104-3 are each sent to distribution engine 108-1. Associated with list 114-3 including time stamps T1, T2 and T3. Event 104-n is sent to distribution engine 108-1 after event 104-3 (and many other events, presumably as indicated by the ellipses in list 114-n), and therefore event 104-1 , 104-2, 104-3 through 104-n are associated with a list 114-n that includes time stamps T1, T2, T3 through Tn, respectively, corresponding when transmitted to distribution engine 108-1.

  [00101] Assume that the target 102-1 has not sent any timestamp 110 to the distribution engine 108-1. When the distribution engine transmits the event 104-1, a badge counter having a value of 1 corresponding to T1 is also transmitted. When the delivery engine sends event 104-2, it also sends a badge counter having a value of 2, corresponding to the counts of time stamps T1 and T2. When the delivery engine sends event 104-3, it also sends a badge counter having a value of 3, corresponding to time stamps T1, T2 and T3. When the delivery engine sends event 104-n, it also sends a badge counter with a value of n corresponding to n time stamps T1 to Tn.

  [00102] Next, assume that the target transmits a time stamp 110 having an absolute time that occurs between times T2 and T3. Presumably at this point, events 104-1 and 104-2 have already been carried to target 102-1. When event 104-3 is sent to the target, distribution engine 108-1 only counts the time stamp that occurs after time stamp 110 when determining the value of the badge counter. Thus, in this scenario, the distribution engine 108-1 sends one badge counter corresponding to T3 (when events T1 and T2 occur before time stamp 110) along with event 104-3. This process can be repeated with the latest time stamp 110 received from the target 102-1 being used to determine the badge counter value.

  [00103] The following discussion will then refer to a number of methods and method activities that can be performed. Method activities can be illustrated in flowcharts that are discussed in a specific order or occur in a specific order, but unless otherwise noted, a specific order is not required or an activity is a Not necessary as it depends on other activities completed previously.

  [00104] Referring now to FIG. 7, a method 700 is illustrated. The method includes an activity of delivering events to consumers. Method 700 includes accessing ownership data (act 702). For example, each source 116 may provide data in an ownership format that is specific to a different source 116.

  [00105] The method 700 further includes the step of normalizing the ownership data to create a normalized event (act 704). For example, as illustrated above, event 104 can be normalized by normalizing ownership data from different sources 116.

  [00106] The method 700 further includes determining, based on the subscription, a plurality of end consumers that should receive the event (act 706). For example, as shown in FIG. 2, the distribution engine 122-1 can consult the database 124-1 to determine how the user has subscribed at the target 102.

  [00107] The method 700 further includes formatting the data from the normalized event into a plurality of different formats appropriate for all determined end consumers (act 708). For example, as shown in FIG. 1, normalization events can be specifically formalized in a format suitable for various targets 102.

[00108] The method 700 further includes delivering data from the normalized event to each of the plurality of end consumers in an appropriate format for the end consumer (act 710).
[00109] Further, the method can be implemented by a computer system including one or more processors and a computer readable medium such as a computer memory. In particular, the computer memory may store computer-executable instructions that perform various functions when executed by one or more processors, such as the activities mentioned in the embodiments.

  [00110] Embodiments of the present invention may comprise or utilize a dedicated or general purpose computer including computer hardware, as discussed in more detail below. Embodiments within the scope of the present invention also include physical or other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions are physical storage media. Computer readable media carrying computer-executable instructions are transmission media. Thus, by way of example and not limitation, embodiments of the invention may comprise at least two separate and distinct types of computer readable media, physical computer readable storage media, and transmission computer readable media.

  [00111] Physical computer readable storage media include RAM, ROM, EEPROM, CD-ROM or other optical disk storage device (CD, DVD, etc.), magnetic disk storage device or other magnetic storage device, or computer-implemented Any other medium that can be used to store the desired program code means in the form of possible instructions or data structures and that can be accessed by a general purpose or special purpose computer.

  [00112] A "network" is defined as one or more data links that allow the transfer of electronic data between computer systems and / or modules and / or other electronic devices. When information is communicated or provided to a computer over a network or another communication connection (either wired, wireless, or a combination of wired or wireless), the computer appropriately views the connection as a transmission medium. The transmission medium includes a network and / or data link that can be used to carry the desired program code means in the form of computer-executable instructions or data structures and that can be accessed by a general purpose or special purpose computer. Can do. Combinations of the above are also included within the scope of computer-readable media.

  [00113] Further, in reaching various computer system components, program code means in the form of computer-executable instructions or data structures may be transmitted from a transmission computer-readable medium to a physical computer-readable storage medium. Yes (or vice versa). For example, computer-executable instructions or data structures received over a network or data link are buffered in RAM within a network interface module (eg, “NIC”) and then computer system RAM and / or volatile in the computer system. It can be gradually transmitted to a computer-readable physical storage medium having low reliability. Accordingly, a computer readable physical storage medium may also be included in a computer system component that utilizes a transmission medium (or even primarily).

  [00114] Computer-executable instructions include, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer executable instructions may be, for example, assembly language or even binary, intermediate format instructions such as source code. Although the subject matter has been described in a language specific to structural features and / or methodological activities, the subject matter defined in the appended claims is not necessarily limited to the features or activities described above. I want you to understand. Rather, the described features and acts are disclosed as exemplary forms of implementing the claims.

  [00115] Those skilled in the art will recognize the present invention as a personal computer, desktop computer, notebook computer, message processor, handheld device, multiprocessor system, microprocessor-based or programmable consumer electronics, network PC, minicomputer, mainframe. It will be appreciated that it can be implemented in a network computing environment with many types of computer system configurations, including computers, cell phones, PDAs, pagers, routers, switches, and the like. The present invention also provides a distributed system environment in which both local and remote computer systems perform tasks, linked through a network (either by wired data link, wireless data link, or a combination of wired and wireless data links). Can be implemented. In a distributed system environment, program modules can be located in both local and remote memory storage devices.

  [00116] The present invention may be embodied in other specific forms without departing from its spirit and characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (7)

A method of delivering an event to consumers,
Accessing ownership data;
Normalizing the ownership data to create a normalized event;
Determining a plurality of end consumers that are to receive the event based on a subscription; and
Formatting the data from the normalization event into a plurality of different formats that are appropriate for all the determined end consumers;
Delivering the data from the normalized event to each of the plurality of end consumers in a format suitable for the end consumer;
Including methods.   The method of claim 1, wherein accessing ownership data comprises accessing data from a plurality of sources.   Distributing the data from the normalized event to each of the plurality of end consumers in a format suitable for the end consumer first fanouts the data from the event in the normalized format ( The method of claim 1 including a fanning out) step.   Distributing the data from the normalized event to each of the plurality of end consumers in a format suitable for the end consumer includes packaging the event into a plurality of bundles. Each of the bundles includes the normalization format of the event and a routing slip, wherein the routing slip identifies a plurality of end consumers, and the identification is identified within the routing slip. The method of claim 1, comprising identifying the end-use consumer format that was recorded.   The step of packaging the event into multiple bundles examines the database to determine which end consumers are included in the routing slip by referring to end consumer preferences in the database. The method of claim 4, comprising steps.   The step of normalizing the proprietary data to create a normalized event is a key associated with a single opaque binary chunk of data that is not further interpreted by the event normalization system. The method of claim 1 including indicating the data as key value pairs.   Formalizing data from the normalized event into a plurality of different formats appropriate for all the determined end consumers includes mapping one message property having the same name to one from the normalized event. The method of claim 1, comprising mapping a plurality of properties to a format.

Images