Patent Application
20080143548
The present invention relates to notification services and more particularly to on-demand, subscription-based alerting service that manages one- and two-way communication in time-critical situations.
It is an object of the present invention to enable senders immediately upon occurrence of an event to simultaneously alert multiple contacts over various means of communication.
It is another object of the present invention to enable senders to receive status information of delivery of alert messages to the contacts.
It is yet another object of the present invention to utilize partner services to provide event notification for automatically triggering sending of alert messages.
Provided is a method of enabling one or more senders to simultaneously alert one or more contacts located anywhere around the world over one or more communication networks, each contact having at least one communication device for receiving alert data. The method including the steps of generating and maintaining one or more scenarios each including a set of destination contacts selected from the one or more contacts, a composition of alert data, and delivery rules; initiating execution of at least one of the scenarios to send the alert data to each contact in the set of destination contacts; and managing sending of the alert data by applying the delivery rules.
Also provided is system for enabling one or more senders to simultaneously alert one or more contacts located anywhere around the world, each contact having at least one communication device serviced by one or more service providers. The system including a service complex including at least one computing device, a database, and one or more communication networks connected to the service complex for communicating alert messages, the service complex further including a user interface for administering scenarios and initiating sending of the alert messages; an alert generation service for communicating with external information sources to receive notification to send the alert; and a messaging engine for sending the alert messages to the contacts' designated communication devices managed by available service providers.
Other features and advantages of the present invention will become apparent from the following description of the invention that refers to the accompanying drawings.
For the purpose of illustrating the invention, there is shown in the drawings a form which is presently preferred, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown. The features and advantages of the present invention will become apparent from the following description of the invention that refers to the accompanying drawings, in which:
a-8e are diagrams of steps performed by the software processes to achieve the object of the present invention; and
As shown in
Optionally, each of the contacts 14 may chose to respond to the senders 10 directly via the communication networks 12 or by joining the sender in a pre-arranged conference bridge 16. A conference bridge connects multiple participants over a phone line or broadband Internet connection for a conference call. Connection of the contacts 14 to the conference bridge may be initiated as part of the delivery of the sent message. Responses are typically made by the contacts 14 in reply to a request or prompt from the sender that the response be made. Such request or prompts may be contained in the sent message. The contacts' 14 responses may be received using the same medium and form as sent, e.g., an e-mail message sent in response to an e-mail message, or any other medium selected form that listed above, e.g., an e-mail message sent in response to a voice cell phone message. It is understood that for proper response reception, the response medium is available to both the sender and the contact.
The sending and receiving of the messages or alerts is enabled by the service complex 8, which is described below. The service complex 8 may include one or more network-connected distributed computing devices. These devices perform real time verification and recording of delivery and status of the sent and received messages as well as enable presentation or display of voice and text contact's 14 responses as they are generated. Tasks performed by the service complex 8 further include generation and maintenance of scenarios.
The scenarios are sets of commands instructing the service complex when the pre-stored alert data or messages are to be sent. The scenarios enable sending of the alert data without prompting by the senders and may be formulated or initiated by the senders when needed or in advance of sending. Alternatively, a scenario may be partially prepared in advance of sending while the remaining details may be filled-in just prior to initiation of the scenario. Initiation of the scenarios can be achieved manually, automatically at the time of preparation or automatically based on at least one predetermined event.
As illustrated in
A direct interaction may be achieved by the sender accessing a management system 24 on the service complex 22, to perform account maintenance and/or manage the scenarios. The management system 24 provides tools with which the sender can configure and manage their accounts on the service complex 22 and create, initiate, track, and manage message delivery scenarios. The management system 24 may also monitor external events, e.g., the weather, the stock market, the news, etc., which may be used as triggers to automatically initiate the scenarios based on the sender-specified rules.
The directories of contacts, included in the senders' scenarios may be maintained directly by each sender, or senders' appointed administrators 26, or by the contacts themselves. Further, the directories of contacts may be imported from external sources by the administrators 26, or held on sender servers 20 and referenced at the time of the scenario execution. Similarly, a corporate personnel directory contained on each sender's own server 20 may be referred or linked to as the directories of contacts in the scenario.
The scenario may be executed or initiated manually, at a preset time, or based on one or more external events. Once the scenario has been initiated, it is managed by a messaging engine 28 which handles such functions as application of rules contained within a scenario; prioritizing messages to meet service level agreements (SLAs) and other contractual commitments while minimizing costs; routing messages to specific messaging networks; tracking the status of the execution of a scenario and of the messages contained within the scenario; creating message detail records for billing; and monitoring the status and performance of the transaction engine. The messaging engine 28 manages the execution of message delivery scenarios defined using the management system 24 and contains two principal subcomponents—scenario execution and usage recording. The scenario execution subcomponent includes the sub-functions of message prioritization, message routing, scenario and message tracking, and status and performance monitoring.
When the scenario is initiated, the messages are “formatted” for the specific delivery medium selected by the sender and by adaptors 30 specific to each delivery media and/or service provider. The adaptors 30 link the messaging engine 28 with partner messaging networks 42 or directly to the sender servers 20. The individual adaptors 30 format messages for delivery using a specific delivery medium and the service complex 22, listen for confirmations of success or failure of the message delivery attempts and, where possible, track on-line presence of a particular contact's 38 device and its availability to receive the message.
An example of the presence of the contact's 38 device is a list of on-line buddies provided by most instant messaging (IM) clients in conjunction with the associated IM service. The presence can be monitored continually, i.e., outside of the scenarios being executed, or within the active scenarios. In the later case, depending on the above-discussed rules contained within the scenario definition, the presence of a particular contact's 38 device would be checked prior to the actual dispatching of the message to that device. If the device is not present, no message is sent to it. Instead, an alternate contact's 38 device is used or no message is sent at that time.
The status and performance of the functions of the service complex 22 are monitored in real-time through a monitoring and management console 32. The monitoring and management console 32 also functions as a control interface and is configurable to monitor external events and sender servers 20 directly connected to the service complex 22 and containing contact directories. The monitoring and management functions are made available only to those with authorized access privileges. In general, access privileges may be role-based. The monitoring and management console 32 may also be customized to generate automated alerts based on abnormal conditions such as system overload or message delivery delays. Further, the monitoring and management console 32 enables an operations manager 36 to manage the service complex 22.
The service complex 22 further includes a customer support platform 34 for providing customer support, either directly to the contacts 38, administrators 26, and the sender servers 20, or through a customer support representative 40. The customer support platform 34 provides the customer support representatives 40 with tools that enable efficient support of the senders and includes self-help features for senders, including documentation, answers to frequently asked questions (FAQs), and mechanisms, such as real-time chat, for additional support. In addition, the customer support platform 34 enables customer support representatives to view senders' data and directly address their issues. For example, if appropriate, the customer support representative 40 may be enabled to review a sender's account and reset a password.
A partner messaging networks or partner services 42 provide a mechanism for delivery of the messages through the service complex 22 by providing a rich and robust set of delivery paths to a wide variety of customer's devices. Adding support of a new device is as simple as creating a new adaptor and establishing a business arrangement with the appropriate service provider 42. Where messaging costs are charged to the message recipient, no business relationship is typically required between the service complex 22 and the service provider 42.
Depending on an agreement with the partners, the “ports” of the partner messaging networks 42 may be dedicated to the service complex 22 or shared with the partners' other customers. If the ports are dedicated, they may be either shared among all senders or dedicated to a specific sender. The dedicated ports may be reserved for use by a specific sender. When not needed by the sender for whom reserved, these ports may be made available to other senders.
The service complexes 22 and 22B are high-availability processing nodes which include redundant instantiations of the management system 24, the messaging engine 28, adaptors 30, the monitoring and management console 32, and the customer platform 34. Each service complex 22 and 22B is designed to be highly available and to have no single point of failure. In addition, the service complex 22 and 22B utilizes multiple geographically distributed, redundant complexes which provide an additional layer of redundancy. Each complex may be located in a secure telephone-company-operated Tier 1 hosting facility providing redundant, highly available infrastructure, including power; heating ventilation, and air conditioning; fire suppression; physical security; and data connectivity.
The operations centers 46 and 46B are nodes that “run” operations mangers' 36 day-to-day tasks of monitoring and managing the service complexes 22. They include redundant Internet connectivity and redundant connectivity to the Public Switched Telephone Network (PSTN) and connectivity to a Headquarters node, discussed below, by a dedicated 10 Mb/s Ethernet private line connection circuit; may include a conditioned and uninterruptible power supply with battery backup. The battery backup provides, e.g., 60 minutes of power for all essential systems, sixty minutes is approximately twice the interval needed to relocate personnel from the operations centers to a nearby dedicated backup site. The disaster recovery site 48 is provided as a dedicated site and serves as an emergency location for the operations mangers 36 and customer support representatives 40.
The service complex 22 has no single point of failure, as there is no single point of failure in the management or operations of the service complex 22, which is managed from a principal operations center. In addition, personnel in backup locations are cross-trained so that in an emergency they could step in and operate the service should the personnel in the principal operations center be unable to do so. Should both facilities be unavailable, service complex 22 personnel would be able to perform their service operations functions over any available Internet connection using remote access to the operations Virtual Private Network (VPN). Further, offsite backups of all key data at multiple locations and backup systems can be brought online quickly should its redundant primary operations sites fail. The principal and backup service facilities have redundant Internet and PSTN connectivity. In addition the two locations are connected by a dedicated T1 private line circuit.
The service complex 22 has a dedicated disaster recovery site 48 that serves as an emergency location for the service complex 22, operations mangers 36, and customer support representatives 34. In addition to serving as a backup location for the operations center and customer support, the disaster recovery site 48 is equipped with a service complex 22 which can be activated as needed. The disaster recovery site is equipped for stand-alone operations. However, if connectivity between the disaster recovery site and the operations center and/or the Headquarters 46B is available, all of the resources at these facilities, including the Internet and PSTN connectivity, will be available to the disaster recovery site.
The disaster recovery site 48 includes redundant commercial power feeds, redundant uninterruptible power supplies (UPS), redundant power distribution units (PDU), and a backup generator. The batteries attached to the UPS may support full load for at least 48 hours of operations and the generator has enough fuel on site for at least 48 hours of operation. The power controls and backup generators are tested and maintained on regular basis. The disaster recovery site 48 further includes redundant Internet connectivity and redundant connectivity to the PSTN and is connected to the headquarters 46B by a dedicated T1 private line circuit and to the operations center by a dedicated 10 Mb/s Ethernet connection.
The outsourced IVR provider 50 and 50B contain XML-PSTN adaptors. All of the sites are connected via the Internet and the XML-PSTN adaptors connect both to the Internet and to the PSTN. These sites link the service complexes 22 to the PSTN. Similarly, each of the partner services 42 operates multiple redundant sites and each such site has redundant lines to the PSTN. For security reasons, connections among the internal sites, i.e., the complexes 22, the operations centers 46, and the disaster recovery sites 48 may be encrypted using, for example, the Cisco VPN technology. The traffic between the complexes 22 and the XML-PSTN adaptor sites 50 may be protected, e.g., using 128-bit Secure Sockets Layer (SSL) encryption.
The features and benefits provided by the hosting facilities may include dual, redundant Internet connections. The hosting facility connects to the larger Internet through the hosting provider's own IP backbone and, potentially, the IP networks of other service providers. Within each hosting facility, the hosting provider connects to its IP backbone via redundant routers 51. Should one router 51 fail, other redundant routers 51, automatically take over and carry the traffic. The hosting provider provides its hosting customers, including Ethernet-based Internet connectivity through redundant switches. Should one switch fail, the other, redundant switches, automatically carries the traffic. The complex 22 is connected to the hosting provider's Ethernet switches through a pair of redundant Cisco PIX 515E firewalls with automatic failover between them. These firewalls provide a variety of protection against intrusion attempts, both accidental and intentional.
As shown in
The service complex 22 is architected, designed, and implemented to be highly secure. It utilizes a “defense in depth” strategy which provides, where feasible, multiple levels of defense. The service complex 22 is a highly distributed, networked service that utilizes IP networking to move information among information sources, information processing nodes, and information sinks. Firewalls are used to restrict the flow of information based on a “need to know” basis.
Sender passwords may be required to log on to the service complex 22 to protect sender accounts, sender administrator account, service complex administrator accounts, and the network elements, servers, and various applications. Sender accounts and passwords may be established by a sender's administrator 26 (
Administrator passwords may be required for use of administration privileges on the service complex 22 and to log on to various system resources. The administrator accounts and passwords may be established and reset by the customer support representative 40 and changed by administrators. The administrator passwords may be case-sensitive and be between seven and fifteen characters in length. To log on, the administrator will have to enter a user name and a corresponding password. In some instances only a password may be required. The administrator accounts and passwords may be established by authorized operations personnel and changed only by them. The administrator passwords are randomly generated, case-sensitive, and may be, for example, ten characters in length.
All traffic to and from the web interfaces to the service complex 22 is encrypted using 128 bit SSL encryption. SSL, first establishes a private session key using an asymmetric public-key cryptographic algorithm and then encrypts the data exchanged in the session using a symmetric private key cryptographic algorithm. To minimize the possibility of success of brute force attacks, in which an attacker uses trial and error with multiple private keys to decrypt the session data, 128 bit private keys are used. Use of 128 bit keys provides 2128 or more than 1030 unique key values. Even if an attacker could try a trillion keys a second, discovering a 128 bit private key by brute force would take, on average, over 5×1016 centuries. All SSL encryption occurs to and from the service complex 22 is performed by dedicated hardware SSL accelerators in the load balancers 52.
All web applications 56 within the service complex 22 are hardened to eliminate known classes of vulnerabilities to malicious attacks. The classes of attack against which the web applications 56 are hardened include the following: backdoors and debug options; buffer overflows; cookie poisoning; cross-site scripting; hidden field manipulation; null parameter exploitation; parameter tampering; stealth commanding; and third-party misconfigurations. Updates to web applications are hardened and evaluated in a test environment prior to deployment into production.
Basic intrusion detection protection is provided by the firewalls 60 which cut off suspicious traffic and provide real-time alerts of intrusion attempts to the operations personnel. VPNs are utilized among the service complexes 22, operations centers 46, disaster recovery site 48, and corporate headquarters 46B. These VPNs encrypt traffic among these sites and may be based on hardware and software from suppliers like Cisco.
The service complex 22 may be further protected against DoS attacks through a variety of techniques. Such techniques may include SYN Flooding and Authorization Request Flooding. The firewalls 60 in front of each service complex 22, operations site 46, disaster recovery site 48, and headquarters 46B are configured to prevent SYN-flood DoS attacks by limiting the rate at which TCP SYN requests are handled as well as Authorization-Request-flood DoS attacks by reclaiming firewall resources if the firewall authentication subsystem runs out of resources.
The database 62 includes all the data and information required to send the alert data or messages discussed above. This information may include: account information for each sender; contact directories with lists of contacts, as well as other information about the contacts including contacts' contact points, e-mail addresses, telephone numbers, etc; preferred and backup modes of contact, e.g., e-mail first and, if there is no response to the e-mail, then a phone call; predefined contact “groups” that the contacts may be assigned to, etc.; message histories indicating when a message went out and to whom; status of the message to each contact, e.g., was the message successfully delivered; reply status in the case where the sender sending the message invoked the “get word back” feature, which requests that the contact reply to the sent message; and other information that would be apparent to those skilled in the art as being necessary to provide the functionalities described herein.
A user interface 74 enables at least three types of users and user applications, including senders 72, local administrators 70, and sender administrators 68. The senders define alerts and initiate sending of the alert data messages. The local administrators 70 perform system configuration, maintenance, and etc. And sender administrators 68 administer senders' accounts including contact directories for communication with the database 62. Similarly, a web service interface 76 enables interaction between sender applications 66 and the database 62 either completely automatically or in response to senders' interactions with those applications. The sender applications 66 provide the same kinds of information to the service complex 22 that an individual user may provide through the user interface 74.
The user interface 74 includes scripts, screens and other software enabling various users, e.g., administrators 68, 70, and senders 72 to interact with the service complex 22 and its database 62 over the Internet and thereby effectuate desired functions. To this end, the user interface 74 accesses the database 62 to retrieve information for display to the users as well as to store new and/or updated information supplied by the users. It is thus via the user interface 74 that individual senders 72 can do the following:
The user interface 74 further allows the sender's administrative users 70 to define the manner in which the various services are to be provided to those working on behalf of the sender, e.g., sender's employees, as well as specifying a list of those authorized to use the sender's account, manage passwords, and so forth.
An alert generation service 78 communicates with external information sources 64, e.g., financial data services, news services, and various monitoring services that may, in one example, provide notification that particular Internet service provider systems have terminated and are unavailable for use. Storing such information, in the database 62 lets the service complex 22 know not to deliver messages to e-mail accounts managed by the unavailable Internet service provider, but instead to a pre-specified alternative service provider or alternative message medium, e.g., the telephone. Thus if the principal manner of alert data delivery to a contact specifies an America On Line (AOL) e-mail address but an external information source 64 reports that AOL e-mail service is currently unavailable, an alternative specified notification method will be automatically used.
A messaging engine 88 interfaces with the message delivery networks 87. On the outgoing side, the messaging engine 88 picks up alert data messages that have been created and placed in the database 62 for transmission by the message composition service 86. The message composition service 86 receive information about the alert data messages to be sent-including message content, the contacts, and selected message delivery options or rules and queues up that information in a standardized form for pick-up and transmission by the messaging engine 88. The message composition service 86 receives the information about the messages to be sent both from the user interface 74 and the web service interface 76, depending on whether message delivery was requested by the sender 72 or from a sender application 66.
The sender applications 66 are of two basic types, administrative and/or configurative in nature to carry out a number of functions, including updating entries of a contacts directory and authorized user lists and changing the content of canned messages, etc. The second type interacts with the service complex 22 so as to cause messages to be sent and can vary widely in the extent to which the sender wishes to rely on the information already having been provided to the service complex 22. At one extreme, the sender may have already supplied the content for a particular message and associated a particular contact group with that message as well as options that the customer may wish to invoke such as “get word back” feature to request a response or “bridge to conference” feature to request that the contact join a conference call. The sender application 66 thus needs only trigger the service complex 22 to send the message.
At the other extreme, the sender applications 66 may rely on nothing more than the fact that the sender has an account set up. In this case, all the information necessary to send out the message is communicated to the service complex 22 at the time it is desired to send the message. This would then include the message content; the contacts and their contact points, i.e., e-mail addresses, phone numbers, etc.; and any service complex 22 options that the customer may wish to invoke.
An example of the sender applications 66 is shown in
The power company may routinely send messages to all the individuals assigned to a workgroup to indicate work-reporting locations or for other purposes. Alternatively, it may only chose to send messages on an emergency basis when repair personnel, including those who may be off-duty at a particular time, are needed to be rapidly deployed to a disaster scene or other emergency location. Such messages might thus be directed to repair people individually as well as by group. For example, it may be desired to notify all the members of workgroups A and B to leave the locations where they might be carrying out minor repairs and to report to a location where a major accident requires the presence of all the individuals comprising the two workgroups.
Effective use of the service complex 22 for this purpose is advantageously achieved by ensuring that a contacts directory 94 within the service complex 22 has all the latest information about who the repair personnel are; what their contact points are, e.g., cell phone number, pager number, instant messaging address, etc.; the composition of each of the workgroups, and etc. In this way, the power company can simply instruct the service complex 22 to send a particular message to all members of workgroups A and B or perhaps to all repair personnel on the payroll.
To this end, the power company computer system may run a replication application 96 to interface with a particular web service interface 76, for example, a contact management web service interface. The replication application 96 is triggered by the scheduling application whenever there is any kind of scheduling change including, for example, addition or deletion of repair personnel to any workgroup. The replication application 96, thereupon, invokes contacts directory update functions of the service complex 22 through the contact management web service interface 76, thereby, updating the composition of contact groups within the service complex 22's contacts directory 94 maintained for the power company. When it is time to send a message to all the personnel in workgroup A corresponding to a like-named group within the contacts directory—the service complex 22 includes the up-to-date information and the message is thus sent to everyone who should get it.
Another example of this concept may be that the sender's proprietary employee database keeps track of the country in which employees, such as traveling executives, are deployed on an ongoing or temporary basis and notifies the service complex 22 as to those country locations. The service complex 22 updates the profile information that it maintains for each contact in the contacts directory 94 to indicate the country where that contact is located. The customer can then define an alert in which messages are to be sent to all the employees located in a specific country if a dangerous situation, e.g., riots, arises in that country. The service complex 22 can then send the desired message upon learning from one of its external information sources of the occurrence of a dangerous situation in that country.
Returning to
The partner service 42 initially supplies the service complex 22 with a profile catalog specifying such information as kinds of events that can be monitored and the criteria that the partner service 42 is able to report about those events, such as geographic range of distances, e.g., 10-20 miles, of a particular type of weather event, such as a tornado, from a particular location, for example, Topeka, Kans. The profile catalog is stored in the service complex 22 database 62.
A sender may wish to send a unique message in a specific way when a particular event occurs. The present invention achieves this using alerts received from partner services 42. The sender 72 first accesses the service complex 22 via the user interface 74 and defines the alert in question. As shown in
The sender 72 also specifies the alert event with reference to a stored profile catalog data. This is referred to as a publication definition 114. The publication definition 114 includes a location 112 and profile 110 of the event. The profile 110, i.e., the “why” of the publication 114 defines, for example, the weather condition that the sender cares about, e.g., tornado with 10 miles. The location 112, or the “where” of the publication 114, identifies what geographic location is to be monitored for the condition in question, i.e., Topeka, Kans. The “why” of the publication 114 is so named because it defines why the alert might be generated, e.g., because there's a tornado, but might also be thought of as a “what”, namely what weather condition is of concern to the sender.
The subscription definition 108 and the publication definition 114 are given a subscription identifier and a publication identifier, respectively, by the service complex 22's alert service 84 (
This division of labor is analogous to a newspaper operation. Those who create the content and print the physical newspaper do not need to know who the subscribers are or their addresses nor do they need to deliver the newspaper. Those functions are carried out by the subscription and delivery departments.
The partner service 42 carries out ongoing observations 118, e.g., of weather and, in particular, its alert generation service 79 monitors data from partner external information sources 69 to determine if and when the criteria for any given publication definition are met. Once that happens, the partner alert generation service 79 provides an alert 120 to the service complex 22's alert service 84, specifying the nature of the event, e.g., a tornado between 10-20 miles of Topeka, Kans., and the publication identifier of the event. The alert may be in multiple forms, as discussed below. The service complex 22's alert service 84 uses the publication identifier to retrieve the subscription definition 108 and thereupon assembles message parameters 122 based on the contents of the identified publication and the associated subscription. Those parameters are supplied to the message composition service and the messages are delivered to the contacts 125 specified by the sender 72.
A particular advantageous feature of the alerting scenario is that when the partner service specifies the nature of the event, it provides this nature of the event in a number of forms each indicating the occurred event. For example, a message indicating that a tornado occurred 10-20 miles away from Topeka Kans. can be delivered from the partner service 42 to the service complex 22 in the form of (a) a text message to be delivered to those contacts whose specified contact point is text-based, such as e-mails or instant messages; (b) a voice message to be deliver to those contacts whose specified contact point is voice-based, such as a telephone; and (c) a code identifying the event, e.g., a tornado, a lightening strike, etc.
The service complex 22, upon receiving the code, is able to control the way in which the messaging is carried out or configured and/or to provide various kinds of value-added features. For example, when the code indicates that the weather event is 10-20 miles away, the service complex 22 may, pursuant to the pre-specified options, append a warning such as “be prepared to act” whereas if the code indicates that a weather event is less than 10 miles away, the service complex 22 may append a more urgent warning such as “take cover”. Or the service complex 22 may allow the user to specify that if the weather event is close at hand, e.g., less than 10 miles away, the service complex 22 should invoke the “get word back” and/or “bridge to conference” features, but not otherwise.
A two-entity model is inherent in the above-described scenario. A first entity, the service complex 22, allows senders to send messages based on alerts that are to be reported by a second entity, the partner service 42, e.g., weather monitoring and reporting service. The first entity offers up choices for to the sender to define alert conditions based on the types of alerts the second entity is able to provide. The first entity then puts in an order to the second entity with an identifier that enables the second entity to identify when the alert occurred. The first entity can then alert the contacts based on current user preferences. Advantageously, each entity does a portion of the overall task, each doing what it does best and without the need for all information about a transaction to be known or maintained by both entities. In this particular case, for example, the weather reporting partner has no need to know anything about the messaging aspects of the alert. It only needs to report the weather event in question if and when such event should occur.
Another advantageous aspect of the disclosed invention is that the service complex 22 customizes message notification based on how a particular event manifests itself. Thus it allows users to specify that “get word back” feature should be invoked when a tornado is particularly close-thereby allowing users to confirm that everybody got the message but that “get word back” feature should not be invoked if the tornado is further out and the chances of the tornado coming this way are relatively small.
Although weather related scenario is used to illustrate several advantageous aspects of the disclosed invention, a wide variety of applications beyond weather alerting may be used as partner services 42.
A user provisioning service 80 sets up accounts with new senders, it interacts with sender administrative users 70 through the user interface 74 to set up new accounts and to add users to existing accounts. In another aspect, the sender provisioning service 80 interacts with a partner service's 42 provisioning service 81, wherein the partner service 42 may have “signed up” a sender who, for example, wishes to receive alert messages based on data that the partner generates. For example, if the partner service 42 is the weather monitoring and reporting service, the sender may wish to be availed of weather alert messaging.
An alert generation service 78 monitors the external information sources to determine if alert conditions specified by senders 72 or sender applications 70 have occurred. Alerts can also include time-of-day criteria as well as criteria of various other sorts.
Alert service 84 receives alerts from the alert generation service 78 and accesses information in the database 62 as to what is supposed to happen when that alert occurs, who is supposed to be informed, with what message content, with what options, etc. The alert service 84 thereupon assembles information necessary to send the messages based on what was specified by the sender, including the content of the message, i.e., delivered, for example, as text or synthesized voice, the contacts and their contact points, i.e., e-mail addresses, telephone numbers, etc., and other options that may have been selected by the customer for this particular alert, such as whether “get word back” or “bridge to conference” feature is desired. As with messages composed via the user interface 74 and web service interface 76, the alert messages are put in a queue within the database 62 for pick-up and transmission by the messaging engine 88.
In another aspect, the alert service 84 also triggers the sending of messages upon the occurrence of conditions being monitored in whole or in part by the partner service 42 as requested by a sender. For example, where the partner service 42 is the weather monitoring and reporting service and a user may have defined as an alert the occurrence of a tornado within 20 miles of Topeka, Kans. If such condition occurs, a partner alert generation service 79 alerts the alert service 84 to the condition. The alert service 84 thereupon matches up that alert with the particular senders who defined it, and appropriate messages are generated and sent out as described above.
A configuration service 82 interacts with a partner configuration service 83 by receiving from the partner configuration service 83 information referred to as the profile catalog. In the case of the weather monitoring and reporting service, the profile catalog illustratively includes the type of weather conditions that the partner service 42 is able to report, e.g., temperatures, high winds, hurricanes, tornadoes, as well as the kinds of details that the partner service 42 is able to supply relative to those weather conditions, e.g., that a hurricane or other storm is, say, 0 to 10, 10 to 20, 20 to 30 or greater than 30 miles away from a given specified geographical location. Such information enables defining of alerts.
Further interaction between the respective configuration services 82 and 83 involves the service complex 22 informing the partner service 42 of the conditions and/or criteria that, if met, should be reported by the partner service 42. For example, if, as suggested above, the customer wishes a message to be triggered if a tornado appears within 20 miles of the center of Topeka, Kans., the configuration service 82 must tell the partner service 42 that that is a condition that the service complex 22 needs to know about. If that condition does occur, the partner service's alert generation service 79 will provide an indication to the service complex 22's alert service 84, leading to the sending of messages as described.
a-8e show a number of individual process iterations of provisioning 80 (
In
Alternatively, as shown in
c illustrates configuration process. In step S21, the sender administrative user 70 configures the service through the user interface 74. The configuration information includes publication definitions, subscription definitions, and the association between publications and subscriptions. The publication definitions include locations, information profiles, and the associations between locations and information profiles. The subscription definitions include recipients, recipient contact mode and addresses/numbers, and notification rules and options. In step S22, the user interface 74 stores the configuration information in the database 62 and, in step S23 marks appropriate portions as unprocessed.
In step S24, the sender application 66 configures the service through the web services interface 76. In step S25 the web services interface 76 stores the configuration information in the database 62 and, in step S26, marks appropriate portions as unprocessed.
In step S27, the configuration service 82 finds the configuration information items that have been marked as unprocessed and, in step S28 passes the unprocessed configuration information items to the partner configuration service 83, typically through a web service. In step S29 the configuration service 82 receives confirmation from the partner configuration service 83 that the information has been received and, in step S30 marks the items as processed. The partner configuration service 83 may optionally, in step S28a, store the unprocessed configuration information items in the partner database.
d illustrates the alert process. In step S31, the partner alert generation service 79 monitors the partner external information sources 69 for conditions that match one or more publication definitions. For each such match, in step S32, an alert is passed to the alert service 84, typically through a web service. The passed alert includes an identifier (publication ID) that identifies the publication definition, one or more versions of the alert body, and an XML representation of the alert. In step S33, the alert service 84 stores the received alerts in the database 62 and, in step S34, marks it as unprocessed.
Similarly, in step S35, the alert generation service 78 monitors the external information sources 64 for conditions that match one or more publication definitions. For each such match, in step S36, an alert is passed to the alert service 84. The alert includes an identifier that identifies the publication definition, one or more versions of the alert body, and an XML representation of the alert. In step S37, the alert generation service 78 stores the received alerts in the database 62 and, in step S38, marks it as unprocessed.
Alert messages are composed in step S39 by the message composition service 86, which finds each alert item that is marked as unprocessed in the database 62 and picks it up for processing. Using the publication ID of the alert and the associations between publications and subscriptions, this process next determines the subscriptions to which this alert is to be sent. Individual messages are assembled using the recipients, recipient contact modes and addresses/numbers and the appropriate alert body taking into account the appropriate associations between alert body types and contact modes. Rules and/or options specified in the subscription definitions, e.g., “silence periods” during which no messages are to be sent, soliciting responses, and connecting voice calls to conference bridges, are applied. In step S40, the messages that result from this process are stored in the database 62 and, in step S41, are marked as unprocessed. Among the attributes of each message is its delivery time, the time until which the message should hold prior to its being sent.
Message delivery is illustrated in
In step S45, the selected network of the message delivery networks 87 to which the message was passed, delivers the message to the designated message recipient device 89 using the message address or number. If a response to the message has been requested and the message recipient provides one in step S46 to the message delivery network 87, the message delivery network 87 provides the response to the message engine 88 in step S47. In addition, the message delivery network 87 provides the status of message deliveries, e.g., delivered, mailbox full, reached an answering machine, busy to the message engine 88 in step S48. In step S49, the message engine 88 stores the message status and the responses, if any, in the database 62.
In step S50, the sender administrative user 70 may requests the message status and the responses from the user interface 74. In response, in step S51, the user interface 74 may retrieve the message status and the responses, if any, from the database 62 and provide them to the sender administrative user 70 in step S52.
Similarly, in step S53, the sender application 66 may requests the message status and the responses from the web services interface 76. In response, in step S54, the web services interface 76 may retrieve the message status and the responses, if any, from the database 62 and provide them to the sender application 66 in step S55.
When messages, e.g., e-mails, are transmitted to contacts, they are sometimes not received. It is desirable to report to the senders the status of sent messages, including indications and the reasons the e-mail wasn't received. To some extent the reason for non-delivery can be learned from so-called RFC reply codes that are returned to e-mail senders, i.e., the messaging engine 88 (
Providing better information to the senders is extended to media other than e-mail. For example, for voice messages it is sometimes possible to recognize telephone call progress signals, such as busy, fast-busy, in order to provide a status report for a voice call. In addition, voice recognition may be applied to recorded messages received from the telephone company, such as “the number you have reached is not in service at this time” in order to be able to report to the sender why a message sent by telephone did not go through.
The service complex 22 aggregates the statuses of all instantiations of a particular sent message, thereby providing a readily reviewable report to the sender as to what happened with respect to the message in question-how many deliveries were successful, how many attempted deliveries were unsuccessful for reason X or Y or Z, etc.
Further, the service complex 22 can flag a mode of communication about to be used in sending a message to a particular contact based on an external event. For example, if the message is to be sent via e-mail and a particular contact's e-mail provider is America on Line, and the notification system has learned from one of its external information sources that America On Line is down, the system can prompt the user with a message such as “AOL is down; suggest selecting an alternative form of message delivery to this contact.”
Although the present invention has been described in relation to particular embodiments thereof, many other variations and modifications and other uses will become apparent to those skilled in the art. It is preferred, therefore, that the present invention not be limited by the specific disclosure herein.
This application is based on and claims priority to U.S. Provisional Patent Application Ser. No. 60/875,621, filed on Dec. 19, 2006 and entitled “ALERTING AND RESPONSE SERVICE”, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60875621 | Dec 2006 | US |
