| Method and apparatus for automatic notification and response -> Monitor Keywords |
|
|
 
Method and apparatus for automatic notification and responseRelated Patent Categories: Data Processing: Financial, Business Practice, Management, Or Cost/price Determination, Automated Electrical Financial Or Business Practice Or Management ArrangementMethod and apparatus for automatic notification and response description/claimsThe Patent Description & Claims data below is from USPTO Patent Application 20070203741, Method and apparatus for automatic notification and response. Brief Patent Description - Full Patent Description - Patent Application Claims
CROSS REFERENCE TO RELATED APPLICATIONS [0001] This application is a continuation application of U.S. patent application Ser. No. 10/184,236, filed on Jun. 26, 2002 which claims the benefit of U.S. Provisional Application No. 60/291,087, filed May 15, 2001, and claims priority to PCT Application Serial Number PCT/US02/15513, filed May 14, 2002 TECHNICAL FIELD [0002] The present invention relates generally to methods and apparatus for communicating with one or more recipients, and more particularly, to methods and apparatus for automatic notification and response between an application and one or more recipients using one or more different media types BACKGROUND ART [0003] Enterprise applications need to contact people and have requirements for how the contact is done and what responses, if any, are collected. For example, applications may need to contact all people who have certain interests, or a particular list of people or a single person Applications may need to contact someone immediately in a crisis or they may want to remind someone of a task at an appropriate time. Enterprise applications also have requirements about what to do when the contact is unsuccessful, where success is something defined by the enterprise. [0004] Recipients, on the other hand, have their own preferences about how and when they are contacted. For example, recipients may want particular people, such as a boss or family member, or people who represent particular interests, such as an executive from a Fortune 500 Company, to be given more flexibility in establishing real-time contact. In addition, recipients may routinely delay contact about known tasks, such as weekly status or expense updates, until a convenient time or place. Oftentimes, the preferences of recipients are at odds with the preferences of an enterprise or the implementation of a specific application. In those cases, recipients find creative ways to work around the application constraints, in order to satisfy their preferences, or find the enterprise's processes frustrating or even annoying. [0005] A number of notification systems have been proposed or developed to enable applications to communicate with one or more recipients. Existing notification systems, however, are typically limited in media and function. For example, a notification system may only send an electronic mail message to a cellular telephone or pager. In addition, existing notification systems do not support flexible use of different communication infrastructures. The growth of wireless services, for example, such as those using the Wireless Access Protocol (WAP), described in WAP Forum, "Wireless Access Protocol 1.2.1," June 2000, has led to the development of a number of notification and response services that contact only one device and thereby push and receive responses to web forms on cellular telephones. [0006] The Session Initiation Protocol (SIP), as described, for example, in M. Handley et al, "SIP: Session Initiation Protocol," RFC 2543, March 1999, provides a registry where users can be associated with particular devices by registering a SIP Uniform Resource Locator (URL) for the device. A number of SIP proxies exist that support the ability to contact the list of URLs recorded in the registry for a given user in parallel or sequentially to establish communication with the user. Call Processing Language (CPL), as described, for example, in J. Lennox and H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services," Draft REC draft-ietf-iptel-cpl-05.txt, November 2001, is a language that is proposed for SIP proxies. [0007] CPL allows users to specify in advance how to select a specific URL given characteristics of a SIP INVITE message (that is used in accordance with the SIP protocol to establish contact with the user), such as interpretations of the strings in the sender and target addresses or the subject of the INVITE. CPL also allows users to specify a timeout, so a sequential series of INVITE messages to specific devices can be tried when attempting to establish communication with the recipient Moreover, SIP allows each SIP device or endpoint to specify the preferences of its user as a weighted list of media types and human languages. Senders are asked to provide, from the media types and human languages that they have available, the most highly weighted media type and human language. SIP and CPL do not provide support for interpreting the result of a communication, and taking different actions depending on that result. For example, once a telephone call is successfully answered, SIP and CPL do not discover if the user hung up the telephone or actually answered the request. [0008] While sufficient techniques exist for specifying data flow or program flow through a system, the techniques that are available for specifying communication flow axe typically rudimentary. A communication flow is the path of a request from requester to recipients. These existing communication flow techniques typically equate specifying a recipient for a request with some predefined method of contact such as sending an electronic mail message to a mailbox or a message to a pager. While a communication flow path is often thought of as a simple connection between two patties, model communication capabilities enable a variety of communication flows. For example, a given communication flow can (i) contact recipients or devices used by a recipient in parallel or sequentially; (ii) wait for all recipients or just some of the recipients to respond to a request; or (iii) take a different direction when a communication error occurs. [0009] A need therefore exists for a general technique fox conveniently and accurately specifying the parameters of a communication flow, such as the recipients for a request, and how, when and where each recipient shall receive the request and how the responses direct further communication. A further need exists for a technique for specifying the parameters of a communication in a manner that captures and combines the requirements of applications and the preferences of recipients. DISCLOSURE OF INVENTION [0010] Generally, a notification and response system is disclosed that enables one or more applications to communicate with one or more recipients using a number of different media, such as electronic mail, telephone, web page, pager or facsimile. Generally, the notification and response system (i) sends requests to one or more recipients, using the medium specified by each individual recipient; (ii) collects and processes responses; and (iii) forwards the responses to their final destination by means of the medium specified by the final destination. [0011] Applications can flame requests in any one of a number of supported human languages and media formats, and the request is automatically delivered to the appropriate recipient(s), in accordance with the media and human language preferences of each recipient. Thus, recipients receive messages from different applications or systems (or both) in accordance with their specified preferences and endpoint capabilities. The responses awe returned to each application in a format convenient to the corresponding application. An application can send messages to one or more named recipients or in accordance with predefined recipient lists or roles. A recipient preference and role database provides centralized management of the recipient lists, roles and recipient preferences. The recipient preference and role database records the role, people and device information, as well as related communication flow information [0012] Applications use communication flow expressions to specify who to contact ("Bob"), under what conditions to contact ("only if Ann said yes") and when to contact ("between 9 a.m. and 5 p.m. weekdays"). Recipients specify rules for refining communication flow expressions with details of how, i.e., which devices to use, and when to contact them. Recipients may also automatically delegate some requests to other recipients. According to one feature of the invention, the requests can be dynamically updated with new information until the request is delivered, so recipients receive the most current business information. In addition, the parameters of a communication flow expression (the who, what and when) are evaluated at the time the request is delivered, so that the request is delivered in accordance with the most up-to-date recipient preferences [0013] An application sends a request to the disclosed notification and response system asking that a particular notification message be sent to one or more recipients and responses to that notification be collected and returned to the requester or forwarded to another application. The request consists of (i) a notification message, (ii) request parameters, (iii) a communications flow expression, and (iv) responses. The notification message can be flamed in any one of a number of supported human languages and media formats, and the request is automatically delivered to the appropriate recipient(s), in accordance with the media and human language preferences of each recipient. The request parameters specify information that must be available to the notification and response system to control the behavior of the request or to properly format the request (or both). [0014] Communication flow expressions capture and combine the requirements of applications and preferences of recipients. The communication flow expression portion of a request specifies the recipient(s) associated with a request (the "who"), as well as how, when and where such recipients shall receive the request. A recipient can be a role (e.g., "customer service"), a person (e.g., "Jerry"), a device (e.g., "800-555-1234") or a further communication flow expression to be evaluated. Each recipient is active, because recipients can provide communication flow rules that specify their communication preferences and to tailor their communication flow to characteristics of the sender, the topic of the request or the demands of their schedule. Generally, the communication flow rules replace the recipient's name in the communication flow with further details about when, where and how to contact the recipient, according to the recipient's preferences. Communication flow expressions also specify what action to take when a particular recipient fails to respond successfully to a request. [0015] The notification and response system can employ success tests in a communication flow to evaluate the values specified by a respondent to determine whether a particular contact has succeeded or not. A respondent is a person who has received a request and who has returned a response. As responses are received, the notification and response system will forward the attribute value pairs of each individual response or, after the request completes, collated results to the final destination specified in the initial request [0016] A communication flow failure can occur for two reasons. First, there may simply be a failure to contact a recipient or a recipient may never respond to a notification, referred to as notification failure (the inverse is referred to as notification success). Second, the recipient may be contacted and subsequently accept or reject the request, referred to as response success (saying "true" or "yes") or response failure (saying "false" or "no"), respectively. [0017] According to another feature of the invention, communication flow expressions are evaluated using a three-valued logic. The three possible values of the logic are notification failure (maybe), response failure (false) and response success (true). Notification success is a transitory state identified that occurs before response success or response failure With many devices, it is only possible to know that a notification has been received when a response from the recipient is received. Thus, the success expression associated with a request can specify a three-valued logical expression on the variables that may be included in the response received from the recipient. The success expression tests logical combinations of values in a response and, if there is response success then the contact evaluates to "true," if there is response failure then the contact evaluates to "false," and otherwise, if no more time is allowed for a response, there is notification failure and the contact evaluates to "maybe." [0018] Each communication flow expression includes one or more primitives to specify whether to contact the recipients simultaneously or sequentially, and when execution of the sub-expression should terminate by defining a logical combination of success test results. More specifically, primitives combine directions for parallel or sequential communication with an evaluation of how the status of communication with a recipient affects the communication flow. Other primitives control when contact is made or how to construct a communication flow from lists of objects found by searching the directory. [0019] The primitives employed by the disclosed notification and response system can naturally be grouped into parallel/sequential pairs, as follows: and/then, or/else, races/delegates, and votes/polls. Parallel and sequential primitives differ in how the operands are evaluated. In parallel primitives, each recipient is contacted in parallel. Outstanding requests are canceled when they are no longer necessary to determine the truth value of the primitive. In sequential primitives, requests are made to each recipient in the order that they appear. When that recipient responds, a request is sent to the next recipient, if necessary, to determine the truth value of the primitive. Each primitive evaluates to true, false or maybe depending on the success of the communication with the recipients. [0020] A more complete understanding of the present invention, as well as further features and advantages of the present invention, will be obtained by reference to the following detailed description and drawings. Continue reading about Method and apparatus for automatic notification and response... Full patent description for Method and apparatus for automatic notification and response Brief Patent Description - Full Patent Description - Patent Application Claims Click on the above for other options relating to this Method and apparatus for automatic notification and response patent application. ###  How KEYWORD MONITOR works... a FREE service from FreshPatents1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored. 3. Each week you receive an email with patent applications related to your keywords. Start now! - Receive info on patent apps like Method and apparatus for automatic notification and response or other areas of interest. ### Previous Patent Application: Method and apparatus for a merchant profile builder Next Patent Application: Method and means for registering a debit card Industry Class: Data processing: financial, business practice, management, or cost/price determination ### FreshPatents.com Support Thank you for viewing the Method and apparatus for automatic notification and response patent info. IP-related news and info Results in 0.18001 seconds Other interesting Feshpatents.com categories: Novartis , Pfizer , Philips , Polaroid , Procter & Gamble , 174 |
 * Protect your Inventions * US Patent Office filing 
PATENT INFO |
|
