JP2005515519A - Method and apparatus for automatic notification and response - Google Patents

Abstract

  Using the disclosed notification and response system, communication between the application and the recipient is possible using various types of media. The notification and response system (i) sends a request to one or more recipients using the media specified by each individual recipient, (ii) collects and processes the responses, and (iii) finals Forward the response to the final destination using the media specified by the destination. The application frames the request in at least one supported human language and media format and delivers the request to the appropriate recipients according to their preferences. In the communication flow equation, the designated request recipients and each recipient specify when, where and how the request is received. The request is updated dynamically and the communication flow parameters are not evaluated until the request is delivered. The communication flow rules specify the communication environment settings of the receiver, and the communication flow is revised according to the sender's characteristics, topics, or scheduling constraints. The communication flow expression is evaluated using a ternary logic of notification failure (maybe), response failure (false), and response success (true). Primitives specify simultaneous or sequential communication, and specify when subexpression execution should end by defining logical combinations of success check results.

Description

  The present invention relates generally to a method and apparatus for communicating with one or more recipients, and more specifically, one or more applications and applications that use one or more different types of media. The present invention relates to a method and apparatus for automatic notification and response with a recipient.

  This application claims the privilege of US Provisional Application No. 60 / 291,087, filed May 15, 2001.

  Enterprise applications require contact with people, and there are requirements on how to get in touch and what responses are collected when there is a response. For example, an application may have to contact all people of a certain interest, or people on a particular list or one person. You may also need to contact someone who is in a critical state right now, or you may want to be reminded and reminded of a task at an appropriate time. Enterprise applications also set requirements for what to do if the contact is unsuccessful where what is successful is defined by the company.

  On the other hand, the receiver side has their own preferences regarding how to contact and when to contact. For example, the recipient wants to be more free in real time to contact specific people, such as bosses and family members, or representatives of specific interests, such as company executives on a Fortune 500 list. I believe. In addition, recipients may routinely want to delay communication about known tasks such as weekly situations or spending updates until a convenient time or place is established. In many cases, recipient-side preferences are contrary to enterprise-side preferences or specific application implementations. In such cases, the recipient manages to address the application constraints to ensure that the recipient's preferences are met, but otherwise it feels frustrated by the corporate process, and even It becomes annoying.

  Many notification systems have been proposed or developed that allow applications to communicate with one or more recipients. However, existing notification systems are usually limited in terms of media and functionality. For example, a notification system may only be able to send an email message to a cell phone or pager. Furthermore, existing notification systems do not support the flexible use of different communication infrastructure platforms. For example, wireless services such as the WAP Forum, “Wireless Access Protocol 1.2.1”, and the services using the Wireless Access Protocol (WAP) described in June 2000 have grown and contacted only one device, As a result, many notification and response services have been developed that push and receive responses to web forms on mobile phones.

  For example, M.M. Handley et al. Session Initiation Protocol (SIP), as described in "SIP: Session Initiation Protocol" RFC 2543, March 1999, associates a user with a specific device by registering the device's SIP Uniform Resource Locator (URL). Provide a registry that can. There are a number of SIP proxies that can be contacted using a list of URLs recorded in the registry for a given user in parallel or sequentially with establishing communication with the user. For example, J.A. Lennox and H.M. Schulzrin "CPL: A Language for User Control of Internet Telephony Services" Draft RFC draft-ietf-iptel-cpl-05. Call Processing Language (CPL), as described in txt, November 2001, is a proposed language for SIP proxies.

  In CPL, a user is pre-added with the characteristics of a SIP INVITE message (used to establish contact with the user according to the SIP protocol), such as interpretation of the sender and destination addresses or strings in the subject of the INVITE. A method for selecting a specific URL can be designated. In addition, the CPL allows the user to specify a timeout so that a sequence of INVITE message sequences can be sent to a particular device when attempting to establish communication with the recipient. In addition, in SIP, each SIP device or endpoint can specify user preferences as a weighted list of media types and human languages. The sender is asked to provide the highest weighted media type and human language from the media types and human languages that are made available. SIP and CPL do not support interpretation of communication results and performing various actions depending on the results. For example, after receiving a call and successfully responding, SIP and CPL do not detect whether the user hung up or actually responded to the request.

  Although sufficient techniques exist to specify data flow or program flow within the system, the techniques available for specifying communication flows are usually rudimentary. The communication flow is a request path from the requester side to the receiver side. These existing communication flow technologies specify a recipient for the request, some predefined contact method, such as sending an email message to a mailbox or sending a message to a pager. Are identified. The communication flow path is often considered as a simple connection between two parties, but various communication flows are possible due to modern communication functions. For example, a given communication flow may either (i) contact the receiver or the device used by the receiver in parallel or sequentially, or (ii) all the recipients or only some of the recipients Wait for a response or (iii) another direction can be selected when a communication error occurs.

Therefore, it is common to specify conveniently and accurately the parameters of the communication flow, such as the recipients for the request, and how and when each recipient receives the request and how to proceed further in response to it. Techniques are required. There is also a need for a method for specifying communication parameters in such a way as to capture and combine application requirements and recipient preferences.
US Provisional Application No. 60 / 291,087 WAP Forum, “Wireless Access Protocol 1.2.1”, June 2000 M.M. Handley et al. "SIP: Session Initiation Protocol" RFC 2543, March 1999 J. et al. Lennox and H.M. Schulzrin "CPL: A Language for User Control of Internet Telephony Services" Draft RFC draft-ietf-iptel-cpl-05. txt, November 2001 M.M. Wahl et al. “Lightweight Directory Access Protocol (v3)”, RFC 2251 (December 1997) M.M. Handley et al. "SIP: Session Initiation Protocol", RFC 2543, March 1999

  In general, notifications and responses that allow one or more applications to communicate with one or more recipients using a variety of multiple media such as email, phone, web page, pager, or fax. A system is disclosed. In general, the notification and response system (i) sends a request to one or more recipients using media specified by each individual recipient, (ii) collects and processes the responses, and (iii) ) Forward the response to the final destination using the media specified by the final destination.

  Applications can frame requests in one of many supported human languages and media formats, depending on the environment settings for each recipient's media and human language, Automatically delivered to appropriate recipients. Thus, the recipient receives messages from different applications and / or systems depending on the specified environment settings and end point capabilities. The response is returned to each application in a format convenient for the corresponding application. The application can send the message to one or more designated recipients or according to a predetermined recipient list or role. The recipient preferences and role database can centrally manage recipient lists, roles, and recipient preferences. The recipient preferences and role database records not only role, person, and device information, but also associated communication flow information.

  The application uses a communication flow formula to identify the contact ("Bob"), contact conditions ("Ann answers" yes "only"), and contact date and time ("9am to 5pm on weekends") Specify how long the recipient will use the device, that is, the rules that refine the communication flow expression using details about which device to use and when to contact. The recipient can also automatically delegate some requests to other recipients.According to one aspect of the invention, the request is dynamically updated with new information until the request is delivered. Therefore, the recipient receives recent business information, and the communication flow parameters (who, what, and when) are evaluated when the request is delivered, and the request is Latest recipient It is delivered in accordance with the boundary set.

  An application may disclose a request to send a specific notification message to one or more recipients and collect a response to that notification and return it to the requestor or forward it to another application. Send to response system. The request consists of (i) a notification message, (ii) request parameters, (iii) a communication flow expression, and (iv) a response. Communication messages can be framed in one of a number of supported human languages and media formats, and the request is applicable depending on the respective recipient's media and human language preferences. Automatically delivered to recipients. Request parameters specify information that must be made available to the notification and response system that controls the behavior of the request and / or appropriately defines the request type (or both).

  The communication flow method captures and combines application requirements and recipient preferences. The communication flow part of the request specifies not only the recipient ("Who") associated with the request, but also how, when and where such a recipient issues the request. The recipient can be a role (eg, “customer service”), a person (eg, “Jerry”, advice (eg, “800-555-1234”), or other communication flow expression to be evaluated. Each recipient is active, but it is a communication flow rule that allows the recipient to specify its communication preferences and to tailor the communication flow to the sender's characteristics, request topic, or schedule requirements. In general, the rules of communication flow detail the details of when, where, and how to contact the name of the recipient in the communication flow, depending on the recipient's preferences. The communication flow expression further specifies the action to be taken if a particular recipient fails to respond normally to the request.

  In the notification and response system, a success test can be used in the communication flow to evaluate the response specified by the responsive side to determine whether a particular contact has succeeded or failed. The responder is a person who receives the request and returns a response. When a response is received, the notification and response system forwards each individual response attribute value pair or, after the request is completed, the matched result to the final destination specified in the initial request.

  The communication flow can fail for two reasons. One is simply a case where the recipient could not be contacted or the recipient could not respond to the notification at all, and is referred to as a notification failure (the opposite is a notification success). The other is the case where the recipient can be contacted and then accept or reject the request, with a successful response (indicating “true” or “yes”) or a failed response (“false”). Or “no”).

  In another aspect of the invention, communication flow equations are evaluated using ternary logic. The three possible values of this logic are a notification failure, a response failure, and a response success. Notification success is an identified temporary state that occurs before a response success or response failure. If a large number of devices are used, all that can be known when receiving a response from the recipient is that a notification has been received. Therefore, a ternary logical expression for a variable that can be included in a response received from a recipient can be specified with a successful expression associated with the request. In the success formula, check the logical combination of values in the response, if there is a response success, the contact evaluates to "true", if there is a response failure, the contact evaluates to "false", otherwise If there is not enough time for the response, there is a notification failure and the communication is evaluated as “maybe”.

  Each communication flow expression has one or more primitives that specify whether the recipient should be contacted simultaneously or sequentially and when execution of the subexpression should be terminated by defining a logical combination of success check results. Including. Specifically, the primitive combines with the evaluation of how the direction of parallel or sequential communication and the status of communication with the recipient affect the communication flow. Other primitives control how the communication flow is constructed from the list of objects found by searching the directory or searching the directory.

The primitives employed by the disclosed notification and response system can of course be grouped into parallel / sequential pairs such as and / then, or / else, races / delegates, and votes / pols. There are different operand evaluation methods for concurrent primitives and sequential primitives. Concurrent primitives contact each recipient in parallel. An outstanding request is canceled when it is no longer needed to determine the primitive's true value. With sequential primitives, requests are sent to each recipient in the order in which they appear. When the recipient responds, the request is sent to the next recipient and, if necessary, determines the primitive's true value. Each primitive evaluates to “true”, “false”, or “maybe” depending on whether the communication with the recipient is successful.
Details of the present invention and other features and advantages of the present invention can be obtained with reference to the following description and drawings.

  The present invention may include one or more applications 110-1 to 110-N (hereinafter referred to) shown in FIG. 1 by various types of media such as email, telephone, web page, pager, or fax. A communication and response system 100 is implemented to enable communication between an application 110 (collectively referred to as application 110) and one or more recipients 120--120-N (hereinafter collectively referred to as recipient 120). In general, the notification and response system 100 (i) sends a request to one or more recipients 120 using the media specified by each individual recipient 120, and (ii) collects and processes the responses. , (Iii) Forward the response to the final destination using the media specified by the final destination.

  FIG. 2 is a detailed diagram of the notification and response system 100. As shown in FIG. 2 and described below, application 110 provides an application interface 220 that provides services for sending or canceling requests, checking the status of requests, and returning results to application 110. Is used to send the request to the request manager 1200. The application may send notification requests and pending notification cancellation requests to the appropriate application interface 220, for example, via HTTP POST.

  The application interface 220 is, for example, Simple Object Access Protocol (SOAP) or IBM Corp. MQSeries (TM) interface sold by Sun Microsystems, Inc. It can be realized as various commercially available Enterprise Application Integration (EAI) interfaces such as the J2EE (trademark) interface sold by the company. The application interface 220 performs a mapping between the external request representation and the internal representation of the notification and response system 100 for each request. Similarly, the application interface 220 performs a mapping between the internal representation of the notification and response system 100 and the external request representation for each response.

  Request manager 1200, described below with respect to FIG. 11, keeps track of all requests sent. As will be described later with respect to FIG. 3, the request manager 1200 maintains a request database 300 that stores information about each request and indicates the status of each request, such as pending, canceled, or completed. Request database 300 can be maintained in memory or a persistent database, where requests and their current state (including responses) can be stored. In particular, the request manager 1200 assigns a unique identifier to each request that can be used to identify the request received by the recipient 120 and the request to which the response applies. Further, the request manager 1200 modifies the request as necessary to ensure that a response is returned to the notification and response system 100.

  As already indicated, application 110 uses communication flow equations to specify parameters for a given request. The request manager 1200 follows the direction of the communication flow when performing each medium specific communication with the recipient. The request manager 1200 uses the communication flow type service of the communication flow manager 1300 described later with reference to FIG. The interaction between request manager 1200 and communication flow manager 1300 is described below with respect to FIG.

  In general, the communication flow manager 1300 interprets the target communication flow defined in the request and converts it into a more efficient internal representation of the tree structure. Further, the communication flow manager 1300 iterates through the tree representation and, during its execution, expands non-device recipients to instantiate devices. At each iteration, the communication flow manager 1300 inputs the success check results that were available and decides whether to cancel the pending contact or start a new contact. The communication flow manager 1300 then interprets and executes the communication flow equation to determine how to deliver the request to the appropriate recipient 120 and how to respond to the success or failure of each communication attempt. Determine whether to respond to.

  Directory interface 250 provides a mapping between the internal representations of roles, people, and devices used in notification and response system 100 and the representations in recipient preferences and role database 500. In addition, directory interface 250 handles searches and other requests. The communication flow manager 1300 is shown generally as a communication flow that communicates roles and recipient names that need to be resolved to devices for which the notification and response system 100 knows how to contact. By mapping the directory schema and the internal representation of the notification and response system 100 into a single class, other types of databases can be used, and the internal representation can be independent of the specific directory schema being used. it can. This class also provides a set of specific search and retrieval methods.

  The media-specific contact 270 handles notification and possibly actual delivery of response collection results. If a contact over a particular medium cannot be made after a specifiable duration or number of attempts, a notification failure message is returned to request manager 1200. The medium-specific interface 270 will be described in the item entitled “Media-Specific Interface” below. For each notification message, the media-specific interface 270 maps between the internal request document representation and the external representation of the notification and response system 100. Similarly, the media specific interface 270 provides a mapping between the external request representation and the notification and response system 100 internal representation for each response.

  Web portal 280 provides data to recipient 120 via various media and collects responses. Web portal 280 is a collection of servlets that allow recipients to access pending, completed, and canceled notifications. This includes servlets that display a list of pending notifications and allow recipients to read or hear from them, and servlets that display notifications and other servlets that collect responses. The web portal 280 is structured in this way so that all notifications are delivered directly by the notification and response system 100 and all responses are collected by the notification and response system 100. A centralized implementation allows you to control the content of notifications, personalize notifications, and incorporate previous responses into notifications. Personalization data from the recipient configuration and role database 500 is processed by the same rewrite mechanism that modifies the form action tag to point to the appropriate servlet.

  The notification and response system 100 mediates all requests to the recipient 120 specified in the communication flow formula. Thereby, the notification and response system 100 records responses and communicates those responses to the communication flow manager 1300. The communication flow manager 1300 takes different paths through the communication flow based on the contents of these responses. For example, in the web application program interface (API) example, all requests are represented as web pages, and those requiring a response include a form to accept the response. The request is rewritten to send a response to the specified URL, and the completion status is recorded before making a route to the final destination specified in the original request made to the notification and response system 100 Can do. The routing and return processing of the notification and response system 100 can be adapted to various ways of specifying requests and responses, such as those of a unified messaging system or an XML-based API.

  Thus, the present invention implements personalized message delivery (recipients receive messages when and how they want). Notification and response system 100 delivers requests and collects responses in one of a variety of supported human languages and media formats, such as email, phone, web page, pager, or fax. Can do. Further, the notification and response system 100 performs centralized request management of requesters and recipients, response verification, and transparent routing of requests from existing applications (and responses to existing applications).

Request application 110 sends a specific notification message to one or more recipients and collects a response to that notification and either returns the request to the requestor or notifies and responds to a request to forward to another application To system 100. As used herein, a request consists of (i) a notification message, (ii) a request parameter, (iii) a communication flow, and (iv) a response.

Notification message application 110 can create one or more versions of the request to support delivery in different human languages over different media. That is, the application 110 creates a data file that is converted by the servlet into the type of document that the recipient prefers to receive, and then passes the servlet URL to the notification and response system 100. For example, an application 110 that wishes to send a meeting notice to one or more recipients may create an HTML document that includes a message along with a form for processing such a response, if any. it can. The HTML document is then stored on the Web server and the URL is passed to the notification and response system 100.

  One of the advantages of the present invention is shown in the method of generating a message in a specific media format using a servlet. By updating the message medium at the time of delivery according to the needs and environment settings of the recipient and generating the message contents at the time of delivery, the latest information can always be included. For example, many of the media contacts used in the present invention first include a page or a notification page that indicates that the recipient must call a specified telephone number to retrieve the notification message. Information indicating that the recipient is ready to use the notification message, such as an e-mail message containing a hyperlink pointing to the recipient. Thereafter, when the recipient accesses the notification message, the latest version of the notification message is displayed at the time of access. In this way, the requester can update the notification message until the recipient actually accesses the notification message.

Request parameters A request has a set of related parameters. These parameters specify the information that must be available from the notification and response system 100 that controls the behavior of the request and / or appropriately defines the request format (or both). As already indicated, the request manager 1200 keeps track of all notification requests sent using the request database 300 that stores information about each request, such as pending, canceled, or completed. Indicates the current status of the request.

  FIG. 3 is a sample table from the example request database 300. As shown in FIG. 3, the example request database 300 comprises a plurality of records 305-315, each record associated with a different request. For each request identified in field 330, the parameters recorded in request database 300 are: (i) requester identifier in field 335 (ie, the name of the person or application that generated the request), (ii) field. A response destination in 340 (eg, a URL to which the response is forwarded or a communication flow expression that indicates how to select the route of the response, and the matched response is sent at the end of the request, or each response is forwarded as it is received (Iii), (iii) subject in field 345 (ie a brief description of the request that can be used, for example, in the subject line of an email), (iv) maximum lifetime in field 350 (ie all pending requests) Notification and response system 100 delivers the notification until the response is canceled and the collected response is sent to the final destination And the length of time to keep trying to collect responses), (v) the language in field 355 (ie, the language of a valid notification message), (vi) HTML, VXML, and plain text in field 360, etc. The content type for which the message is available, the communication flow expression in field 365, (vii) a public / private flag that indicates whether the received response is visible or available to other designated recipients, and (viii) a field Contains the current status of the request in 375.

  The content of each notification message, including the subject heading, can be supplied by a given application 110 in one or more supported human languages, or automatically in the desired supported human language. Note that it can be translated. In other variations, the language parameters in field 355 can be replaced with rules that specify how and when language translations are obtained, and the content type parameter specifies how and when content types are generated. Can be replaced with a rule.

Communication Flow As described below, in the section titled “Communication Flow”, the notification and response system 100 specifies who, how, when, and where to communicate using communication flow expressions. To do. The recipient of the request is specified by the communication flow expression. The recipient can be a role (eg, “customer service”), a person (eg, “Jerry”), an advice (eg, “800-555-1234”), a software application or an agent (eg, “calendar agent”). Or other communication flow type. Furthermore, in the communication flow formula, the recipient specifies when, how, and where the request is received. The communication flow expression further specifies an action to be performed if a particular recipient fails to respond normally to the request.

  The communication flow method captures and combines application requirements and recipient preferences. The communication flow formula is an active recipient list. Each recipient is active because it provides a communication flow rule that replaces the name in the communication flow with details about where and how to contact, depending on the recipient's preferences. These communication flow rules allow the recipient to incorporate the personal communication flow into the requested communication flow formula. Recipients use these rules to specify communication preferences and tailor the communication flow to the sender's characteristics, request topics, or schedule requirements.

Response As described below, in the section entitled “Communication Flow”, the notification and response system 100 uses a success test in the communication flow to evaluate the correspondence specified by the responsive side and to contact a specific contact. It can be determined whether it succeeded or failed. The responder is a person who receives the request and returns a response. When a response is received, the notification and response system 100 forwards each individual response attribute value pair or, after the request is completed, the verified result to the final destination specified in the initial request. In one embodiment, the notification and response system 100 waits until the entire communication flow is executed and then returns a result, but it is self-evident to modify it to return the respective response when received. .

Communication flow A communication flow is characterized by a communication flow expression, a success specification, a communication flow rule, and parameters. The communication flow formula incorporates the communication requirements of the application into the user's communication environment settings. A communication flow expression specifies the recipient for the request (either directly or using a defined recipient list or role). Furthermore, in the communication flow formula, the recipient specifies when, how, and where the request is received. The communication flow expression further specifies an action to be performed if a particular recipient fails to respond normally to the request.

Specification of success / failure of communication flow In success specification of communication flow, conditions for success and failure of response at each step in the communication flow are described. In this embodiment, the communication flow success designation supports both a system-wide default success designation and a requester-defined default success designation for a particular communication flow. Alternatively, the requester can specify a success designation for each recipient in the communication flow using the test response status primitive described below.

  The communication flow can fail for two reasons. One is simply a case where the recipient could not be contacted or the recipient could not respond to the notification at all and is referred to as a notification failure (the opposite is a notification success). The other is when the recipient can be contacted and then rejects the request or responds negatively, with a response failure (indicating “no”) or response success (“yes”). Is called). “No” and “yes” have semantic elements, which determine whether the recipient responded positively to the request (eg, “yes”) for the purpose of continuing the communication flow. Because it is the only application that can. For example, a successful response may occur when the recipient reviews the document and rejects it. The recipient responds “Yes, the review is complete” and the communication flow continues to the next reviewer. On the other hand, if the recipient reviews and rejects the software revision request, a response failure occurs. The receiver responds “No, we will not be revising this software” and the communication flow ends or proceeds to error handling.

  In one aspect of the invention, the communication flow equation is evaluated using the ternary logic evaluator 400 shown in FIG. The three possible values of this logic are a notification failure at step 420, a response failure at step 450, and a response success at step 440. As shown in FIG. 4, successful notification is a temporary state identified in step 410 that is performed before a response success or response failure, and is not directly represented. If a large number of devices are used, all that can be known when receiving a response from the recipient is that a notification has been received.

  The success formula specifies a ternary logical formula for variables that can be included in the response received from the recipient 120. That is, in general, the notification includes an HTML form, a VXML dialog, or a corresponding object. For example, the form associates a name with the value specified by the responder. In the success formula, check the logical combination of values in the response, if there is a response success, the contact evaluates to "true", if there is a response failure, the contact evaluates to "false", otherwise If there is not enough time for the response, there is a notification failure and the communication is evaluated as “maybe”.

  For example, consider an HTML page containing a notification that contains a form with a single button named “Submit” whose button value is set to “true” when clicked. The success formula for this page is “Submit = true”. The stock price change notification includes a radio button named “Action” that can take the value “buy” or “sell” and another pair of fields named “Quantity” that can take a numeric value. Can be included. The success formula for this page is “Action = buy & Quantity> 1000”. For example, “A? Submit =“ true ”? ”Means to contact A, but if the success check is specified for this, when the response is received, if the value“ true ”is assigned to the parameter“ Submit ”when the response is received, the communication is set to“ true ”. Define. If the value of “Submit” is other than true, the contact is “false”, and if there is no more time to receive a response, the contact evaluates to “maybe”.

  The example shows the advantages of ternary logic used in communication flow formulas for binary logic. Suppose that he wants to contact Tom when the contact with Joann succeeds, and contact Priya when the contact with Joann fails. Using the conventional binary logic primitives then and else, this relationship can be expressed as:

(Joann the Tom) or (Joann else Priya)
So, furthermore, Joann prefers to use the same logic to contact if he fails on his mobile phone or via the office phone, or fails to delegate his request to Jerry. Shall be specified.

cell else office else Jerry
There is an inherent problem with this formula, which is that the requester definitely wants to contact Tom or Priya based on the results of the actual response from Joann, and Joann is the one who fails to respond This is because only Jerry wants to contact Jerry (that is, if he responds with “no”, he / she does not contact). It is impossible to get all of these results from conventional binary logic. In the ternary logic of the present invention, as described in the following section, Tom is contacted only when Joann says “yes”, and Priya is only when Joann does not respond with “yes”. A contact is made and Jerry is contacted only when Joann fails to respond at all.

Communication Flow Recipients As already shown, communication flow expressions provide a flexible and general way to specify how to determine the direction of communication in the receiver for a request and in response to a reply received from the receiver. To do. In one embodiment, as shown in FIG. 5, the recipient configuration and role database 500 can be implemented as a Lightweight Directory Access Protocol (LDAP) directory, for example by reference. M. which is incorporated herein. Wahl et al. “Lightweight Directory Access Protocol (v3)”, RFC 2251 (December 1997). The recipient configuration and role database 500 holds objects that describe recipients that may appear in the communication flow expression. As shown in FIG. 5, the recipient configuration and role database example 500 includes a plurality of records 505-520, each record associated with a different recipient.

  For each recipient identified in field 530, the recipient and preferences and role database 500 identifies the recipient type in field 540 and the personal communication flow defined for reception in field 550. The type of recipient that appears in field 540 is a person, role, application, device, named communication flow, or method for contacting an individual recipient. A person, role, or named communication flow object can specify a communication flow expression for contacting the recipient, but a method for contacting an individual recipient or application (or media contact object) Is the terminal object in recipient name translation (that is, the object is not further translated in the directory). The object contains attributes that are important for contacting an individual or application that can act as an agent for the individual, in particular the address, protocol, timeout, and retry interval to contact.

  In another aspect of the present invention, called dynamic communication flow expression substitution, the operation of binding the recipient name to the recipient configuration and information in the role database 500 is delayed until contact time comes. Thus, in the late binding aspect of the present invention, a recipient described as a role such as a company CEO is changed until the system 100 begins an attempt to notify the CEO. Furthermore, the personal communication flow of the recipient, such as an office telephone number, can be switched to a telephone for a business trip destination, and can be normally used as it is according to a request transmitted before the business trip starts.

  When contacting a recipient via media contact, the recipient can request that a different communication flow expression be used instead of his own expression in the communication flow. Thus, the recipient can dynamically delegate the task to more appropriate recipients. In addition, the recipient substitutes a communication flow expression including a delay clause in the communication flow, for example, “Joann after +04: 00” that generates a notification for prompting to process the request after a delay of 4 hours. Execution can be delayed.

  FIG. 5 shows a number of example objects in the recipient configuration and role database 500 that illustrate various types of recipients. Examples of primitives employed in the recipient and environment settings and role database 500 are described in the section entitled “Primitives” below. For example, as shown in record 505, recipient “Joann” specifies the following personal communication flow for all requests with the following formula:

(Cell races email) delegates Jerry
Therefore, when contacting Joann, he must call Joann's cell phone and at the same time send an email to Joann. If Joann does not respond, contact Jerry to receive the request on behalf of Joann (according to Jerry's personal communication flow). If Joann responds to the request himself, he will not be contacted at all.

In the example shown in record 510, role SysAdmin specifies a personal communication flow that sets the path of the request for the current turn to the administrator.
(Sam between 08: 0-16: 59 or Sue between 17: 00-00: 59 or Greg between 01: 00-07: 59) delegates SysAdmin
The role in record 510 routes the request to the system administrator working at a specific time on weekdays starting at 8 am. If no administrator is contacted on the first working day of request processing, the section in parentheses fails and the contact attempt is repeated the next day with a recursive SysAdmin reference.

  Note that recursive references to recipients, eg, recursive references in the SysAdmin role, are allowed to follow sequential primitives in the communication flow only if other exit conditions exist. In the SysAdmin example, the request is completed with true or false when a response is received, and is completed with a notification failure (maybe) when a requester setting timeout occurs.

  Even with this precaution, it is possible to loop circular name references in the directory. For example, “Tom” can be said in the Jonn communication flow equation, and “Joann” can be said in the Tom communication flow equation. Again, by distinguishing between parallel recursive references and sequential recursive references, loops that consume large amounts of uncontrolled resources are avoided. All parallel and sequential circular references without any other termination conditions are prevented through the name translation history. The previous example for Joann and Tom would be an error, but Joann's communication flow expression would try to contact via email, delegate to Tom in case of failure, and Tom's communication flow expression would simply return to Joann ( (Since Tom is on vacation) is accepted. As a final precaution against requests that loop quickly or loop over the same recipient, the communication flow formula can return an error when a specified maximum number of attempts to contact the recipient is exceeded.

To continue the example of FIG. 5, the named communication flow of record 415 specifies a list of recipients that must be contacted in parallel for review.
Chris and Jerry and Benji and Jenny
If all reviewers respond successfully, the request for reviewers is successful. The “votes” primitive can be used to change the success criteria for this list, as described in the section entitled “Communication Flow Primitives” below.
For example,
Reviewers votes 2
Completes successfully when the two reviewers respond normally.

Note that the recipient preferences and media contact objects in role database 500 may also be agents. For example, a calendar agent can provide three media contacts combined in the following communication flow.
HoldCal then (Cell then ScheduleCal cancel CancerCal)
Once the request data available on HoldCal is found, the user is contacted with the mobile phone to obtain approval for the meeting purpose. If the user approves the purpose of the meeting, the meeting time schedule is determined, otherwise the meeting is canceled.

LDAP Directory Tree FIG. 6 shows a portion of an LDAP directory tree 600 that shows the personal naming context of multiple recipients. The LDAP directory tree 600 is a representation of recipient preferences and user preferences recorded in the role database 500. For example, the LDAP directory tree 600 shown in FIG. 6 includes a personal naming context 610 for recipient Joann and a personal naming context 620 for recipient Tom. Recipient Joann's personal naming context 610 defines rules, communication flow expressions, and media contacts. Recipient Tom uses default rules, communication flow formulas, and media contact.

Communication Flow Rules and Parameters Communication flow rules specify when a recipient name is converted to a specific personal communication flow expression. The recipient can specify conditions on the request parameters that control which personal communication flow expression is used for a particular request, such as title and requester parameters. For example, a recipient can select a specific topic or a requester for immediate attention via a mobile phone when represented by a title. Certain requests can be selected for later attention via email or Web.

  Unlike other environment-based systems, the communication flow manager 1300 environment setting process is a general mechanism that is built into handling the delivery of requests. The recipient 120 rules and personal communication flow equations establish a personal naming context 610 for that recipient 120. The name of the recipient and the name the recipient is in the rule or communication flow expression are translated according to the recipient's context. Unlike other context-based naming systems, this rule-based configuration process does not hide the global meaning of names. Global names are always visible and can be used by everyone. For this reason, recipients can easily use global names to specify that they want to delegate a particular type of request to someone else. The personal naming context 610 performs transformations that are important and appropriate for the recipient's context, but supports meaningful global names.

  Thus, as shown in FIG. 6, Joann's personal naming context 610 includes nodes corresponding to three communication flow rules: manager rules 630, family rules 640, and paperwork rules 650. Each recipient's personal naming context, such as the recipient's personal naming context 610, is established as a partial tree rooted at the InetOrgPerson {RFC2798} or InetOrgRole object in the LDAP directory tree 600. The InetOrgPerson object in LDAP is an LDAP standard object that describes contact information about people, and the InetOrgRole object is a partial class of the LDAP standard object class OrgRole {RFC2256}. For example, in FIG. 6, Joann's personal naming context 610 is rooted at an InetOrgPerson node labeled “UID = joinn”.

  Each personal naming context 610 can comprise three types of objects related to communication flow expressions, named communication flow expressions, and communication flow expressions that process media contact objects. In FIG. 6, the top three entries 630, 640, 650 of the personal naming context 610 represent three communication flow expressions with names MgrRule, FamilyRule, and PaperwrK. Nodes 660, 670, and 680 correspond to three media contact objects named web, cell, and email, respectively. Nodes 690 and 695 correspond to two named communication flow expressions, UrgentCF and RelaxedCF.

  Manager rules 630, family rules 640, and paperwork rules 650 specified by Joann are defined in the recipient configuration and role database 500. The corresponding objects from the recipient configuration and role database 500 that define the manager rules 630, family rules 640, and paperwork rules 650 are shown in FIG. In particular, recipient preference and role database 500 includes a record 710 that defines manager rules 630, a record 720 that defines family rules 640, and a record 730 that defines business rules 650.

  Each communication flow rule, as shown in FIG. 7, includes four attributes: active, order, condition, and communication flow expression. Active is set to “yes” or “no”. Rules that are inactive, ie, rules set to “no” are not considered when converting a recipient's name to a personal communication flow. The order attribute is used to specify the order of all active rules within the naming context 610 being evaluated. The condition of each rule in order is then examined. The condition is a logical expression composed of attribute value comparisons such as equality, inequality, range, and regular expression matching. If the condition is met, the recipient's name is converted to an accompanying communication flow formula for request delivery. In the condition of MgrRule, a specific requester is inspected with a user name or uid. In the FamilyRule condition, a title starting with “Family” is inspected. The Paperwrk condition is always satisfied. PaperwrkR is a default rule that is applied when other rules are not satisfied. Therefore, the sequence number is the highest number.

  As shown in FIG. 7, the example rules of records 710, 720, and 730 each reference at least one named communication flow expression (urgentCF 690 or relaxedCF 695). The urgentCF or relaxedCF communication flow expression can be defined as a named communication flow expression in the recipient configuration and role database 500 as follows.

UrgentCF: cell races officephone races homephone
RelaxedCF: email races web
In this way, the named communication flow formula allows recipient Joann to establish various rules for contact based on the conditions specified in the rules.

  When constructing rules, it is often convenient to create a named communication flow expression for a common method of contact. In this way, the recipient can update a particular environment setting in the named communication flow expression once and all communication flow expressions that reference the changed named communication flow expression are automatically updated. . You can then refer to the named flow in a rule, sometimes using the same named communication flow for various purposes. The rule PaperwrR simply uses a named communication flow (relaxed CF 695). The rule MgrRule uses a relaxed contact communication flow at any time, adding time constraints to when the recipient can be contacted urgently. The rule FamilyRule uses all available media contacts.

Using communication flow rules, further, corporate employees can make urgent responses in stages. For example, a company must immediately respond to a request from a customer, and the request is received from the customer with a title that includes the keyword “urgent business”. Further assume that at least one employee of the company has specified the following communication flow rules:
Title = “* Urgent Business *”;
Communication flow: (cellphone races pager) before +0: 05 delegates manager

  “Manager” is the default named communication flow that uses the manager link in the recipient's directory entry to find the correct manager. A grading rule is triggered when a request is received with a title that includes the keyword “urgent business”. If the employee does not appear on his mobile phone or pager within 5 minutes, the request is communicated to a higher level “manager”.

  Typically, a communication flow that performs step processing uses a delegates primitive when the request is canceled before it is routed to the next higher level. In other variations, the communication flow can perform staged processing without canceling outstanding requests to people earlier in the chain. For example, the following communication flow example performs staged processing without canceling outstanding requests to people in the front of the chain.

(Tom else Manager) races (Manager after +04: 00)
This communication flow first contacts only Tom, and immediately contacts a defined Manager if the initial response fails. Further, after 4 hours have passed, the request is transmitted to the manager one level higher, and only the first response from Tom or Manager is accepted. Communication and response system 100 may optionally maintain information regarding why a specified request was canceled and provide such information to a recipient associated with the canceled request.

  In this communication flow equation, optimization is used to contact the Manager once, regardless of the fact that the recipient designated Manager may be active twice in the communication flow at the same time. Each instance of the recipient name is owned by the entity that contributed to the request, i.e., the requestor, or the role involved in the personal communication flow. If the recipient name identifies the same object / recipient and the recipient name has the same owner, the recipient is contacted only once for their names. If the owners are different, assume that the recipient wants to act differently on behalf of the owner, so the recipient is contacted multiple times with records about who has delegated the request to the recipient.

Recipient preferences and user preferences recorded in the role database 500 and LDAP directory tree 600 may be modified with presence and availability information as described above with respect to FIGS. it can. For example, recipients can specify their preferences as follows:
(Present (cell) then cell) delegates (present (email) then email)

  The present function contacts a presence server with recipient and device information that can be used for mobile phone media contact. If the presence server indicates that the mobile phone is turned on, the present function returns “true”. Otherwise, “maybe” is returned. Similarly, if the recipient is on the network for email media contact, the present function returns “true”. Otherwise, “maybe” is returned. If the recipient is ready to use the mobile phone, the mobile phone is contacted. If the recipient is not ready to use the cell phone or the contact fails, the network is checked and an e-mail is sent if the recipient is there. The present function is more or less advanced, depending on the function provided by the presence server. It should also be noted that communication flow rules may allow the recipient to limit the requesters or types of requests that can be accessed through the presence server.

  In other applications of presence and availability information, media contact can be done by skipping communication attempts (eg, phone calls) where presence information indicates failure (eg, mobile phone is switched off). Its operation can be optimized. The media contact can proceed as if it just failed to make a call.

  User preferences can also be determined by the company. For example, a company can send a notification to a highly invasive customer based on the customer's payment history. For example, as detailed in the “delegats” primitive section below, a customer with poor payment history will receive a first arrears notice via an automated telephone call and a second arrears notice through a collection agent. it can. Customers with average payment history can receive a first overdue notification by mail, receive a second overdue notification by automated telephone call, and receive a third overdue notification through a collection agent.

Directory Defaults and Heuristics The communication flow manager 1300, detailed below with respect to FIG. 13, employs the default directory of the LDAP directory tree 600 (FIG. 6) because it is quick to install and easy to use. . The communication flow manager 1300 also improves usability by employing heuristics when searching the directory. When the communication flow manager 1300 is first installed on the company side, the communication flow manager 1300 is removed from the existing company LDAP directory 500. In addition to information about the configuration of the enterprise LDAP directory 500, the communication flow manager 1300 provides object classes for application specific objects (ie, communication flows, communication flow rules, media communication, enhanced roles and configuration objects). Need to create.

  The communication flow manager 1300 also needs to create a directory subtree 600 that can store its configuration and default instances of other objects. Use the default directory to provide communication flow services for people and roles that already exist in the corporate directory. These people and roles can be enhanced with personalized communication flows and rules at the discretion of the recipient and the company.

  The default instance of the media contact object uses a substitution function that is also available to users who specify their media contact object. In the address field in the media contact object, square brackets can be used to specify the name of the attribute in the target recipient's LDAP directory entry. The value of the attribute, if present, replaces the attribute name enclosed in square brackets in the address field after retrieving the object. For example, <mobile> allows for a more advanced substitution technique that fills the address field of the media contact object with the value of mobile in the inetOrgPerson object that describes the intended recipient Joann, and is within the scope of the present invention. is there.

  Along with the default instance of the media contact object, the communication flow manager 1300 creates a default named communication flow expression and a default communication flow rule. In the notification and response system 100 example, by default, all requests are sent to the recipient's email account and web portal (email race web). All defaults can be changed by the enterprise to suit their needs, and default objects are available to users who configure personal communication flow formulas and communication flow rules.

  The full distinguished name of the entry is cumbersome and not intuitive. Therefore, the communication flow manager 1300 uses a short name heuristic search to identify the necessary objects. The complete identification name of an object can be obtained by enclosing the identification name in square brackets in a communication flow expression, for example, <uid = joinn, ou = people, o = research. avaya. com>. In the examples herein, only short names have been used.

  Upon encountering a name, the communication flow manager 1300 searches a directory sub-tree, eg, 610, 620, used to store people, roles, named communication flows, or personal naming contexts as appropriate. The communication flow manager 1300 searches by comparing the short name with the relative distinguished name of the entry in the subtree. If no match is found, communication flow manager 1300 then searches the default directory and returns an error.

Even if the external organization does not have a communication flow manager installed, it can communicate with other parts of the company or other companies through the local communication flow manager 1300. If there is an LDAP directory 500 in the external organization, it can be incorporated into the communication flow manager 1300 namespace in two ways. First, the external directory is incorporated into the local directory using a “smart referral” or other mechanism chained to the external directory for response. In this case, whenever the default or personal communication flow information is not available there, the default communication flow for the local directory is applied to the external directory. Next, contact information of the external directory can be described by the adv_search primitive and used on the requester side. In all cases where a default is required, the local default will be used unless the name of the directory subtree that stores the communication flow manager 1300 default and configuration in an external directory matches the proposed convention of the communication flow manager 1300. used. For this reason, it is recommended to support the recommended partial tree name of the communication flow manager 1300 in the LDAP directory. In the example of the notification and response system 100, the names are:
<Ou = Xui Server, o = domain-name-of-server>

  The requester sometimes has an address book of the contact person who is not in the directory but wants to contact. From time to time, the requester may be highly fond of contacting certain individuals with certain media types, such as telephone calls. In these cases, the requester can create a personal naming context for those individuals within the requester's personal naming context in the directory. Each other person's personal naming context includes that person's inetOrgPerson entry, and further includes communication flow rules, media contacts, and named communication flows in the subtree rooted at the inetOrgPerson entry. The requester then specifies the full distinguished name of each recipient in the communication flow for his request.

  The communication flow manager 1300 uses the communication flow designated by the requester 110 for the recipient. System enhancements explore the default, first look for short names in the requester's tree, then look in the directory's people and role subtrees, and finally in the directory's default subtree To extend the algorithm. Such an approach is contrary to designations for recipient preferences, and is used only for recipients that are not listed in the directory or for applications that are not relevant or do not need to be followed.

Communication Flow Primitives As already mentioned, a communication flow expression specifies the recipients who will receive the request, and how, when and where the recipient will receive the request. Primitives included in the communication flow expression specify when the sub-expression execution should be terminated by defining the logical combination of success check results, and contacting the recipients simultaneously or sequentially. FIG. 8 is a sample table showing an example of a set of communication flow type primitives. 9A-9E are diagrams of truth tables for the various primitives shown in FIG. 9A to 9E, “F” indicates a false response, “T” indicates a true response, and “X” indicates a maybe response. Each left column of FIGS. 9A-9E indicates the first operand that responds, and the top row indicates that the second operand responds (for all primitives other than the single operand “not” primitive). . The “b” subscript of T, X, or F indicates that both operands must be evaluated to obtain the indicated value. Primitives direct the request flow to the recipient. Specifically, the primitive combines with the evaluation of how the direction of parallel or sequential communication and the state of communication with the recipient affect the communication flow. Other primitives control when to contact or how to build a communication flow from a list of objects in the directory.

  Primitives can of course be grouped into parallel / sequential pairs such as and / then, or / else, races / deletes, and votes / pols. There are different operand evaluation methods for concurrent primitives and sequential primitives. Concurrent primitives contact each recipient in parallel. A processing request is canceled if it is no longer needed to determine the primitive's true value. With sequential primitives, requests are sent to each recipient in the order in which they appear. When the recipient responds, the request is sent to the next recipient and, if necessary, determines the primitive's true value. Each primitive evaluates to true, false, or maybe depending on whether the communication with the recipient is successful.

And / Then
The “and” primitive specifies that two recipients are contacted in parallel and that the communication flow is successful (evaluates to true) if both recipients respond with success. . If a request to one of the recipients fails, the “and” primitive evaluates to false and the request to the other recipient is canceled if possible. In all other cases, the “and” primitive evaluates to maybe. The truth table for “and” is shown in FIG. 9A, where the value to which the first operand responds is along the left of each row, and the value to which the second operand responds is along the top of each column.

  The “then” primitive is a sequential form of “and”. That is, the recipients are contacted one at a time in the order in which they appear, and the second recipient is contacted only if the second recipient responds successfully. The truth table for “then” shown in FIG. 9B is different from the truth table for the “and” primitive when the first operand returns maybe and the second operand returns false. In the case of a “then” primitive, the second operand is not evaluated, and the truth value of the “then” primitive remains maybe, but in the case of the “and” primitive, the second operand is evaluated and the primitive returns false. return. This selection is made on the “then” primitive, which allows a more natural semantic interpretation.

Or / Else
In the “or” primitive, to contact two recipients in parallel and that the communication flow is successful (evaluates to true) if at least one of the recipients responds successfully. specify. If both recipients respond negatively, the primitive evaluates to false. In all other cases, the primitive evaluates to maybe. The truth table for the “or” primitive is shown in FIG. 9C.

  The “else” primitive is a sequential form of the “or” primitive, and the second recipient is contacted only if the first response is not successful. The truth table for the “else” primitive is the same as the “or” primitive shown in FIG. 9C. For the “else” primitive, the second operand is evaluated only if the first operand evaluates to maybe or false. An “else” operator is provided to deal with scenarios where the first recipient contacts the second recipient only if the first recipient responds with “no” or if the response fails.

Races / Delegates
The and / then, or / else primitives are all focused on contacting enough recipients to determine the success or failure of the communication flow expression. Sometimes it may be better to accept the first of many possible responses. This is not possible with existing primitives because it counts votes until it is successful or impossible. The concurrent primitive “races” succeeds or fails depending on the status of the first of the responding operands. If the first responder succeeds, the “races” primitive succeeds. If the first responder fails, the “races” primitive fails. The request for the second responder is canceled if possible. For example,
Cell races Office races Email races Web
Succeeds or fails in response to a first response received from the recipient via either a mobile phone, office phone, email, or web portal media contact.

  Unlike the other primitives described herein, the “races” primitive gives equal weight to success or failure responses from one operand. The and / then primitive responds immediately to operand failures, but waits for results from both operands, and then returns success. The or / else primitive responds immediately to the success of the operand, but waits for results from both operands, and then returns a failure. The “races” primitive responds immediately to the first response from the operand and returns the result of that operand. This is especially the case, as shown in the example above, contacting an individual via multiple devices and responding to the request with success or failure via only one of those devices It is useful because it can. The “races” primitive cannot be specified from other primitives. The truth table for “races” is shown in FIG. 9D.

  The “deletes” primitive is a sequential form of the “races” primitive. The truth table for the “deletes” primitive is the same as the “races” primitive. The “deletes” primitive evaluates the right operand only if the left operand returns a notification failure. As with the “races” primitive, the “deletes” primitive cannot be specified from other primitives.

Returning to the above example, Joann can specify his environment settings as follows.
cell delegates office delegates Jerry
On the other hand, the request generation side specifies as follows.
(Joann the Tom) or (Joann else Priya)
Jerry responds only when Joann fails to respond. Tom can be contacted only if Joann or Jerry responds with “yes” in the absence of Joann. If neither Joann nor Jerry responds, or both reply “No”, contact Priya.

  The “races” primitive was created because it needs to contact one person via multiple simultaneous devices. For example, the recipient may be able to specify that notifications are sent to both mobile phones and office phones. If the recipient responds with his office phone, the response should be applied to the pending call to the mobile phone, regardless of success or failure. The “and” and “or” primitives did not meet this requirement. For example, the “deletes” primitive can handle a scenario in which the second recipient is contacted only if the first recipient does not respond, or a series of device searches are continued until the recipient can be contacted. go.

As already mentioned, using the delegates primitive allows companies to phase out personalized request delivery. For example, a company involved in a price collection business can prepare a personal communication flow for each customer based on the relationship history with the customer as follows.
good credit customers: web delegates email delegates sms delegates homephone
poor credit customers: homephone delegates cell
Thus, if the customer fails to respond to each request, the request is upgraded to the next contact method.
votes / pols

  It is possible to generalize sequential and concurrent communication flow primitives to a list of recipients. The parallel and sequential form of the and / or primitive is a special case of two more common primitives that allow parallel or sequential voting by a list of recipients. For example, the success of the “and” primitive is a vote by two recipients when 100% voted yes, and the success of the “or” primitive is the success of two people when at least 50% voted yes. Vote by recipient.

The “votes” primitive contacts the list of recipients of the number c in parallel when the success response count m or percentage n% is reached, and returns success (true). Therefore, a failure occurs when there is a cm-m + 1 false response. Each recipient can be represented by a communication flow equation, where the count or percentage represents the number of successes that must be received for a successful “votes” primitive. For example,
{TOM, Joann, Jerry} votes 50%
Will contact Tom, Joann, and Jerry in parallel. If at least two respond with success, the “votes” primitive is successful. The “votes” primitive fails (returns false) if enough recipients return a false response that prevents the specified count or percentage from being reached. In other cases, if the success cannot be reached, the “votes” primitive is maybe. In the above example, if at least two of Tom, Joann, and Jerry respond with a failure, the “votes” primitive fails. On the other hand, true, false, and maybe become the truth value of maybe.

  Note that it is possible to calculate the number of true votes that need to return a true directly from a primitive count or percentage. From now on, the number of false votes that need to return false (total + 1-true) and the number of non-true votes that return maybe (false or maybe if at least one is maybe) (total + 1-true) It is easy to calculate. The “pols” primitive is a sequential form of the “votes” primitive.

The votes primitive is useful, for example, when selling or distributing a limited number of items. For example, a company with 500 units of specified items and 5000 prospective customers can specify the following communication flow:
{Customer1, customer2,. . . , Customer5000} votes 500
The request is completed when the customer orders 500 units (assuming each customer orders only one unit). See the following description of the test response status primitive for an example where each customer can order multiple units.

The polls primitive is convenient to use when, for example, it is necessary to replenish personnel urgently. For example, a school trying to find five substitute teachers from the order list by tomorrow morning can specify the communication flow as follows.
{Teacher1, tearer2,. . . , Tearer N} polls 5
As already indicated, this request is completed when five substitute teachers agree to take charge of the lesson.

Since the communication flow expression is not a list, it is convenient to convert the expression to the required list with the “votes” and “pols” primitives. In particular, the recipient configuration and named communication flows in the role database 500 often have a list structure, which is, of course, natural. Automatic conversion is supported for “votes” and “pols” primitives when a communication flow expression appears as the first operand, rather than a list enclosed in brackets. Automatic conversion is performed on communication flow expressions that contain only joins or only adjustments. If the expression contains only “and” and “then” primitives, this is converted to a list of joins. If the expression contains only “or” and “else” primitives, the expression is converted to a list of separations. Considering the example above again,
Reviewers votes 2
Is actually the following equation:
(Chris and Jerry and Benji and Jenny) votes 2
The join is automatically converted to the list {Chris, Jerry, Benji, Jenny}. Although it is possible to specify the details of the operation that converts an expression to a list, it is not clear that such a conversion is necessary, obvious, or desirable. A search primitive described below converts a list into an expression.

Generating “races” and “deletegates” primitives It is possible to generalize the races and delegates primitives to a list of recipients. A generalization of races, called gen_races, accepts a list of recipients, the number of responses to collect, and a decision algorithm that determines the success or failure of a primitive from the received responses. For example, if gen_races is used once, the value of the Nth received response is accepted. This corresponds to a radio talk show model that accepts a response from the 100th caller. In another example, gen_races collects three of the five responses and returns the majority of the three responses. The result is
{A, B, C, D, E} votes 2
Unlike this, it waits for two successes. gen_deletegates is a generalization of the delegates primitive. gen_deletegates is similar to gen_races, except that it sequentially contacts the recipient until the primitive conditions are met.

Sequential / Concurrent Primitive Implementation Sequential and concurrent primitives are implemented in an embodiment that uses a simple counting algorithm. Each primitive is described by the number of true responses that need to return true and the number of false responses that need to return false. Furthermore, it is described by the minimum number of maybe responses that need to return a maybe and the total number of responses that must be received before the maybe is returned. FIG. 10 summarizes the count of each primitive where C is the count of all recipients listed in votes / pols and X is the number of true responses required by the votes / pols percentage or count. It is a thing. Parallel and sequential primitives count the number of responses received within each class. If the requirements for one of the returned statuses are met, these primitives cancel even the outstanding request and return the appropriate status.

Status Interpretation and Temporal Primitives As described above with respect to FIG. 4, a successful request to recipient 120 is accompanied by a successful notification and a successful response. Notification success occurs when the recipient has been successfully contacted. By default, a successful response occurs when the recipient responds in a manner that satisfies the definition of success of the request and response system API. As for the Web API of the notification and response system 100, the default response success is a reply to a Web form that does not include the submit button value “false” or “no”. “False” or “no” for the submit button is the default response for response failure.

  Some applications may require an application-specific definition of successful response. For example, if an expenditure report is approved in turn by multiple managers, success can be defined as responding to the request with report_status = “approved”.

  Using the Test Response Status primitive, an application can supply a successful response designation as a logical expression for comparison of attribute-value pairs from the response. This logical expression is specified between the question marks after the recipient whose response is to be examined. The comparison can include integration, inequality, range, and regular expression matching. If the success specification is the same for all recipients in the communication flow but is different from the system default, a default across the request can be specified.

In the following example, the response success status is specified without using the default function.
Department Head? report_status = “approved”? then Director? report_status = “approved”? then VP? report_status = “approved”?
If the Test Response Status primitive is applied to an expression that includes multiple recipients, this applies to each recipient in the more complex expression. For example, the previous equation can be written as:
(DepartmentHead the Director theen VP)? report_status = “approved”?
With success designation, aggregation and other advanced processing can be performed on response attributes across all responses so far, and the results can be checked for success or failure.

As indicated above, it is assumed that a limited number of items can be sold or distributed using the votes primitive, but each customer purchases exactly one unit. In the following success formula, each customer orders multiple units and terminates the notification when at least 100 units have been sold.
(Sue or Fred or ... or Sam)? sum (number_sold) ≧ 100?
After selling 100, outstanding requests to other recipients are cancelled. If the notification offer is personalized with data available from the notification and response system, the result of the previous response can be used to provide an item that is still being sold to the recipient (100-sum (number_sold)) If the recipient attempts to purchase the remaining items, the first one is successful and the second one is canceled due to completion by another request (ie the offer has been withdrawn) Receive.

between / before / after
In addition to primitives that check response status, the “between”, “before”, and “after” primitives specify time constraints for delivering notifications and collecting responses from recipients. Depending on the time constraint, the disclosure time can be specified as in the “after” primitive, or the end time can be specified as in the “before” primitive or both, and the “between” primitive. “Between xy” can also be represented by “after x before y”. When applying multiple time constraints to the same recipient, the time constraints are evaluated from left to right. The actual start time and end time are set according to the first time constraint. Thereafter, these times can be finely adjusted according to time constraints. With relative time constraints, the time can be adjusted forward or backward. Other constraints, such as those involving finding the beginning or end of a section, can advance the start time and reverse the end time. That is, when an absolute start time or a different absolute end time is set by a plurality of primitives, the constrained sections are actually crossed using the delayed start time and the earlier end time. If the temporal constraint primitive is applied to an expression that includes multiple recipients, this applies to each recipient in the more complex expression.

  Use time expressions and time domain expressions to specify time constraints. A time expression represents a specific point in time, and a time domain expression represents a time domain. First, we define time domain expressions, which are used when writing time expressions. The time domain is one or more time intervals designated by (start time, end time), the start time is included in the interval, and the end time is not included in the interval. The basic time domain is conceptually “Eternity” that is one section from the start (Creation) to the end time (Armeddon). Creation is taken as an arbitrary start time (00: 00.00 UTC on January 1, 1970, etc. in the time expression of Unix (registered trademark)), and Armeddon is handled in the same manner. Currently, time is specified with a resolution in seconds since Creation. All other time domains are a set of unconnected time intervals (start, end), where the beginning of the interval is closed and the end of the interval is open.

  The time domain is closed under union, intersection, and complement operations, that is, whenever these operations are performed on a region, another valid region is obtained. A time domain expression is created from the primitive time domain (defined below) and the union, intersection, and complement operations. Just as communication flow expressions can be named and used in other communication flow expressions, time domains can be named and used in other time domain expressions.

The primitive time domain includes:
From 9: 00.00, 13 May 2002 unit 17: 00.00, 13 May 2002, etc. The section with the specified start time and end time.
A specified date, such as 13 May 2002.
Specified week, such as Sunday, 12 May 2002 through Saturday, 18 May 2002.
A specified month, such as May 2002.
A specified year, such as 2002.
The specified day of the week, such as Monday (that means the union of all Mondays between Creation and Armeddon).
A specified month such as May (that is, the union of all Mays between Creation and Armeddon).
A specified day of the year, such as July 4 (ie, the union of all July 4 between Creation and Armeddon).
A specified time range such as 9: 00.00-17: 00.00 (ie, meaning the union of all such intervals for all days between Creation and Armeddon).

  For example, weekdays can be defined as the union of Monday, Tuesday, Wednesday, Thursday, and Friday. A holiday can be defined as the union of January 1, July 4, and December 25. Business hours can be defined as common parts with weekdays and a time range of 9: 00.00 to 17: 00.00. Further, the business hours can be refined by obtaining the common part between the business hours and the complementary set of holidays.

  In a time expression, you can specify an absolute time, you can specify a time that is calculated with respect to the start time (such as 4 hours from now), or you can specify a time that is calculated from the time domain and the start time Can be specified (meaning the beginning of the next business day, or 4 business hours from now, ie 4 hours from now counting only within the business hours time domain).

The time expression can take one of the following forms:
17: 00.00 13 Absolute time such as May 2002.
A relative time, such as +4: 00.00, which means 4 hours after the current time, or -3: 00.00, and 3 hours before the current time.

  The start or end of the next section in the time domain, for example, the next completion of the business can be designated as the next end of the section in business hours after the current time. More generally, a start or end, for example, a second business completion can be counted.

  If the elapsed time in the designated time region, for example, 16: 00.00 on 13 May 2002 is present, 12: 00.00 on 14 May 2002 is output when 4 business hours have elapsed. It can also be reset from the current time, but this is particularly useful after moving forward. For example, define a time domain for the next vacation and then reference 4 business hours before the next vacation begins.

More complex time expressions can be defined for these.
For example, an (empty) time interval that lasts from 12: 00.00 to 12: 00.00 every day can be defined. By taking the next start (or end) of such a section, the next day's noon is specified. By using the common part with the weekday, the noon of the next business day can be similarly calculated. By combining this with an operator that counts the end of the section, it is possible to calculate the completion of the business from noon to the next business day for two days.

  As another example, business hours in Spain can be specified as the union of the ranges 9: 00.00 to 12: 00.00 and 14: 00.00 to 19: 00.00. To find the completion of the day's work, find the intersection of business hours in Spain and the day and find the end of the interval in the resulting time domain.

In an enterprise, a default time domain object can be defined for the communication flow manager, or each recipient can define his own personal time domain object. As an example of using such an object, there is an example of defining business hours for a company. Objects include the following:
Common name (cn) of time domain object: businessness
Directory filter for recipients that use the area. This can be used to associate this business hours region with people within a particular company, time zone, or geographic region.
The time zone used to calculate the effective time.
A time domain expression for a section within a region. This time domain expression can refer to other basic or named time domains.

This time domain is used in conjunction with the time expression operators “end of”, “start of”, “n end of”, “n start of”, where n is the count or keyword last, “+” is the relative time within the domain , “-” Is the relative time within the region of the “before”, “after”, and “between” primitives, for example:
AFTER end of business
BEFORE 2 start of business
BETWEEN start of business-end of business
BEFORE business + 4: 00.00
AFTER end of business
AFTER business-01: 00.00
AFTER last end of (Spanish Business Houses Intersect Today)

  Various simplifications can be made to make the syntax more natural. For example, if the name of the time domain comes after “after”, the next end of the section in that time domain can be considered as the specified time. Similarly, before, the next start of the section in the area can be regarded as the designated time. By doing so, “AFTER end of business” is simplified to “AFTER BUSINESS”, and “BEFORE start of Monday” is simplified to “BEFORE Monday”. Furthermore, “BETWEEN end of 08: 00.00-start of 17: 00.00” is simplified to “BETWEEN 08: 00.00-17: 00.00”. A complete time domain expression that uses union, intersection, and complement operations can also be used where time domain names are used.

  The standard default processing of the communication flow manager is that the common name of the time domain object starts from the name specified in the communication flow, but other qualified character strings after the dollar sign “$” like business $ west-coast. Can be inserted and the recipient must match the filter in the time domain object. If more than one matching object is found, select one of those objects, but if possible, select the logically most specific filter (a filter that includes all other matching filters) Or, if it is not possible, select an arbitrarily selected object among the matching objects. The communication flow manager first looks for a time domain with the name specified by the matching filter in the context of the inetOrgPerson or inetRole object. If nothing is found, the communication flow manager searches for an area in its default directory.

Short Name and Directory Search Primitives The example described herein shows that requester 110 can specify recipient 120 using a short name. These short names are converted by heuristic searching of the recipient configuration and role database 500, as described in the section "Directory defaults and heuristics" below. The requester 110 further includes the safety identifier of the recipient 120 enclosed in square brackets, eg, <uid = join, ou = people, o = research. avaya. com> can also be specified. Specifying the distinguished name of the recipient 120 can be difficult for the user because it needs to know the structure of the LDAP name tree 600 (FIG. 6). The communication flow formula also supports search operations, allowing the user to describe the recipient environment settings and attributes of one or more recipient objects in the role database 500. The user need not know the distinguished name of the directory object when using the search operation. In examples of search primitives of the form “search (filter, pattern, op)”, etc., the recipient preference and role database 500 is searched to find a person, role, or named communication flow that matches the specified filter. Search for objects. An example of an advanced search primitive is a format such as “adv_search (directory-server, directory-port, base, scope, filter, pattern, op)”. Advanced search primitive filters, patterns, and op parameter operations are the same as search primitives. The directory-server parameter specifies the recipient environment settings to search and the domain name of the role database 500 host. The directory-port parameter specifies the recipient environment settings on the host and the port number of the role database 500 server. To do. A directory tree rooted at the base identification name is searched on the server. Search range is base (for objects identified only by base), one-level (search only for children of objects identified by base), or subtree (search entire subtree of objects identified by base) One). Directory-server, directory-port, base, or scope may be NULL, in which case the default is applied.

In general, a communication flow type search primitive has a macro function for processing a search result. Each returned object is substituted into the pattern given by the pattern parameter of the search primitive for the token “<dn>”. This object's result string is then connected to the result string of the other object using a user-specified primitive, given by the search primitive's op parameter, eg, “and” or “races”. As an example, the following pattern (<dn> between 5/01 / 01-05 / 08/01) delegates (<dn> between 5/08 / 08-01-05 / 10/01)
Creates a character string to be notified to each recipient of the request once again after May 1, 2001, and once again after May 8, 2001 if no response is received. If responses from all recipients are required before the request is completed, connect the result string with an “and” primitive to create a communication flow expression. The user can further constrain the search to return only one recipient, as will be apparent to those skilled in the art. By specifying a method for processing a plurality of matches to the search result, it is possible to prevent a confidential request from being transmitted to a large group without knowing the user even though it can be transmitted only to individuals.

The search primitive can be used, for example, when seeking expert assistance. For example, when the requester needs information on a specified topic such as J2EE from an expert, the requester may specify the following communication flow.
search (“& ((objectclass = inetOrgPerson) (expertise = J2EE))”, “<dn>”, OR)
In addition, the communication flow can be specified as follows.

expert1 or expert2. . . or expertN
In yet another example, a network alarm occurs and must be resolved by an expert. The requester can specify the following communication flow.
search ("& ((objectclass = inetOrgPerson) (expertise = netmgr))", "<dn>", OR)
These requests are completed when the expert responds perfectly to the request.

  The following table summarizes examples of operator priority (operator order) from high to low. Operators at the same level are in order from left to right. In general, parentheses are used to change the order of priority.

Interaction between Request Manager 1200 and Communication Flow Manager 1300 FIGS. 11-13 illustrate the interaction between request manager 1200 and communication flow manager 1300. FIG. 11 is a schematic block diagram illustrating the flow of information between various entities associated with a request. 12A and 12B are flowcharts illustrating in detail the operation of the request manager of FIG. FIG. 13 is a flowchart illustrating in detail the operation of the communication flow manager of FIG. In an embodiment, request manager process 1200 and communication flow manager process 1300 process various predefined asynchronous events detected at steps 1205 (FIG. 12) and 1305 (FIG. 13), respectively.

  As shown in FIG. 12A, request manager 1200 detects a new request received from application 110 through application interface 220 at step 1210. Next, the request manager 1200 creates a request entry in the request database 300 (FIG. 3) at step 1215, and supplies the communication flow expression part of the request together with the request identifier to the communication flow manager 1300 which parses at step 1220. To do.

  As shown in FIG. 13, communication flow manager 1300 detects a new communication flow expression to process at step 1310. The communication flow manager 1300 processes the communication flow expression at step 1315, as necessary, to reach a set of executable terminal nodes in the tree 600 and determine the media contact object to employ for the specified recipient. Continue to work to resolve each name in the communication flow expression using the recipient preferences and role database 500 until shown. It should be noted that the recipient 120 can use the communication flow management GUI 1110 to enter and update recipient preferences and preferences to the role database 500.

  In step 1325, the communication flow manager 1300 generates a list of devices to contact and returns the list to the request manager 1200 as part of the contact scheduling information. In general, contact scheduling information includes only contacts that can be scheduled immediately by request manager 1200. For example, if a specified recipient's preferences indicate that the recipient can only be contacted by phone between 8 am and 5 pm, the communication flow manager 1300 will display that time frame. Do not schedule telephone media contact until it is enabled.

  More specifically, the communication flow manager 1300 parses the received communication flow expression into a tree and initiates recursive processing of the nodes in the tree, using a vertical search approach, Follow the tree until you reach the terminal node. Each time a terminal (leaf) node is encountered in the tree, the media contacts stored therein are processed. If the specified node contains concurrent primitives, all nodes associated with concurrent primitive operands are processed. If the specified node contains sequential primitives, the right operand is not processed until the left operand is complete.

  Further, before returning the media contact to the request manager 1200, the communication flow manager 1300 determines whether the time constraints associated with the media contact (terminal node) are met. For example, the communication flow manager 1300 determines whether the start time has come. If all temporal constraints are met, the media contact is included in the list returned to request manager 1200. If all the time constraints are not met, the media contact is not yet included in the list returned to the request manager 1200 and the communication flow manager 1300 may be informed by the communication flow manager 1300 at the appropriate time. Set a timer to add media contacts to the list. Note that media contact objects are not retrieved until all time constraints are met.

  It should be noted that the tree representation of the communication flow expression can include an inverse pointer to the root node in a known manner, thus making it easier to identify the associated temporal constraints. If a named node for a person or role is found in the tree, determine if the name has already been contacted with the same owner (same specified communication flow). If the name is already contacted with the same owner, a second contact is not attempted. Rather, status information is propagated from previous contacts.

  As shown in FIG. 12A, request manager 1200 detects the contact scheduling information received at step 1225 and at step 1230 as described in the section entitled “Media Specific Interface” below. Attempts to contact each recipient indicated in the information in the contact scheduling using the indicated media contact type.

  If the request manager 1200 detects one or more responses or message expiration events at step 1240 (FIG. 12B), a response or expiration record with the corresponding request identifier is optionally archived, eg, at step 1245. Alternatively, it is created in the response database 1150 for the purpose of recording. In embodiments where each individual response is provided to the requesting application 110, the response received at step 1248 is forwarded to the corresponding application 110. The response or expiration status is forwarded to the communication flow manager 1300 for further processing at step 1250.

  The communication flow manager 1300 detects a received response or expiration status with a request identifier at step 1330 and uses the request identifier to retrieve an appropriate communication flow expression at step 1335. If a response or an expired status is detected at step 1330, the communication flow manager further updates the communication flow expression tree representation at step 1335 to reflect the status of the media contact. Communication flow manager 1300 then propagates the status up to the root of the tree by determining the status of the currently determined upper operand, so that the operand is To complete. When the operand is complete, the outstanding media contact for that operand is placed in the list of contacts to be canceled. This list is returned to the request manager 1200 after step 1350 or 1320, as appropriate. If the status propagation does not complete the communication flow as a whole, this occurs when the completion status is set to the highest priority operator in the tree, but processing continues at step 1315. If the entire communication flow is complete, processing continues to step 1350.

  The communication flow manager 1300 uses the communication flow equation to determine whether additional communication is required or whether communication is complete. If it is determined at step 1340 that additional communication is required, control of the program returns to step 1315 to generate contact scheduling information and further send contact scheduling information to the request manager 1200. However, if it is determined at step 1340 that the communication flow equation is complete, the communication flow manager 1300 forwards the completion status indication to the request manager 1200 at step 1350.

  In one embodiment where a matched response is provided to the requesting application 110, the request manager 1200 verifies the response, and when the request manager 1200 receives a completion status indication from the communication flow manager 1300 at step 1260, at step 1265. It is returned to the final destination address indicated by the requesting application 110. At step 1270, a completion status message is sent to the corresponding application.

Media-specific interface In one embodiment, the media-specific interface is the same for all subclasses of a single MediaContact abstract class that need to implement two methods: a method that initiates a contact and a method that cancels it. It is a subclass. However, only two methods are required, depending on the degree of information distribution between the notification and response system 100 and the endpoints, ranging from very simple to very complex subclasses. In general, for each media communication, the request is transcoated by one of the media-specific transcoders described below to output an encoding suitable for the particular communication being attempted. The protocol specific communication interface handles the actual delivery of the encoded request to each recipient.

  This collection of classes can be thought of as a device abstraction layer. Such a device abstraction layer hides all the complexity of various devices from other notification and response system 100 classes and exposes only a few simple methods to instantiate, initiate, and cancel notifications. In addition, it exposes several parameter settings and reference methods that are uniform across all devices. In the following, a number of MediaContact subclass examples will be described.

WebContact
In the WebContact class, the recipient can log in to the web portal and display a list of pending, completed, and canceled requests. The WebContact class simply inserts into the pending list an item that includes the requester's name, request time, subject, and hyperlink to the request URL. Canceling only moves items from the pending list to the canceled list. “Recipient” responds by clicking on the desired notification and completing the displayed form.

PhoneContact
In the PhoneContact class, a telephone call must be initiated, rather than waiting for the recipient to make a call or contact. In addition, the PhoneContact class can employ a Voice extensible Markup Language (VoiceXML) system that outputs an audio representation (or other text representation) of a VXML script. In the PhoneContact class, a message specifying the request identifier, the media contact identifier, the telephone number to be dialed, and the URL of the servlet that returns the VXML script of the target recipient is transmitted to the telephone auto dialer via TCP. In the case of a cancellation, PhoneContact simply sends a message instructing to cancel the call if it has not yet been placed.

  The autodialer control program queues the phone call request and executes it in FIFO order as soon as resources become available.

EmailContact
The notification and response system 100 example can support three types of email: plain text, HTML, and embedded dynamic HTML. In the first case, many recipients sometimes use text-only email clients. This includes text editors emacs and some web-based clients, but also includes wireless email clients such as those commercially available from Blackberry (TM) and Palm (TM). In this case, it must be provided in the directory by indicating that it must be a text-only email, but the notification and response system 100 typically provides the requester's name, request subject, and notification message. Create a simple e-mail message containing a URL pointing to In one embodiment, the requesting application created the text message itself and inserted a voice portal phone number that could be called for audio access.

  On behalf of an HTML-enabled email client that cannot process embedded frames or layers, EmailContact also creates an HTML page that describes the notification, but now includes a hyperlink to the notification message. . For email clients that can handle embedded frames and layers, EmailContact creates a message with embedded notifications so that the content is embedded when the client represents the message.

  The final complexity of EmailContact is the need to interpret undeliverable email messages. This is further implemented in the form of supplying a main method specified as a program for processing messages sent to the notification and response system 100. The method then interprets the returned mail and tries to determine whether the delivery attempt has failed or something else. If so, the notification and response system 100 is notified that the contact failed. Notification and response system 100 can optionally receive and interpret the request. As a result, there is a possibility that it is determined that the notification is successful even if a reply is not transmitted, and there is a case where this is a function necessary for some application.

SMSContact
In SMSContact, notifications are handled through Short Messaging Service provided by various mobile phone providers including Sprint ™, Verizon ™, and AT & T ™. The SMSContact object performs a provider specific HTTP POST or GET on the Web site and sends a message. Almost the same thing. Although e-mail can be performed by sending e-mail to a service provider, POST has a little control function. POST carries expenditures for software changes as the provider's web interface evolves. The notification and response system 100 can optionally interpret the confirmation email that most service providers send out after delivery of the message. In addition to identifying that the SMS message was sent successfully, this email allows the system to revert to using the SMS delivery of the email until the service provider's web interface is modified and the SMSContact software is upgraded. It can be determined whether or not.

Fax Contact
The notification and response system 100 can provide a class for sending notifications to a fax machine, for example, using the FAX function of Avadia's AUDIX system. This class converts a HTML or text page to a TIFF image file and generates a request to send the image to the destination via FAX. This class also provides information about pending faxes and includes a simple status and management servlet that provides some control of pending faxes.

AudixVoiceContact
The AudixVoiceContact object is designed to deliver a text version of the notification to the recipient's voice mailbox. In one example implementation, IBM Corp. Using the VoiceVoice (TM) product, dropping messages into audio files and then sending them to the AUDIX server using essentially the same mechanism as FaxContacts.

SIP Contact
The SIP Contact class connects the notification and response system 100 to a SIP (Session Initiation Protocol) compatible end point. Session Initiation Protocol (SIP) is, for example, M.I. Handley et al. “SIP: Session Initiation Protocol”, RFC 2543, March 1999. SIP is a relatively new protocol defined by the Internet Engineering Task Force (IETF) for the setup and control of various communication sessions.

  To this end, the SIPContact class relies on a component called SIP Execution Environment (SEE) that receives messages from the notification and response system 100. The message includes the recipient's SIP address, media contact identifier, request identifier, and a list of available media types and human languages for this request. The SEE then receives the SIP address and performs an “invite” on the address according to the SIP protocol to establish contact with the recipient. In addition, the SEE receives an OK message from the recipient device indicating the recipient's preferred medium and human language. The SEE performs the XFS request described below and supplies the media contact identifier, the request identifier, and the preferred media type and human language for this request from an already prepared list of available ones. The XFS request returns appropriately formatted content to notify the recipient according to the recipient's SIP environment settings. This approach supports devices that prefer to receive multiple formats by allowing SEE to call XFS once for each of the target formats (some devices have screens and audio).

  In one embodiment, in SEE, sending an instant message or making a call to Microsoft XP ™ softphone, the call control protocol has been changed to SIP (instead of H.323) SIP-enabled Avaya 4624 (TM) IP phone, digital and analog phone calls (via support-enhanced version of MultiVantage (TM) call processing software), instant text messaging with infrared capabilities, call control protocol Changed to SIP (instead of H.323) making SIP-enabled Avaya 4624 ™ IP phone calls, the call control protocol was replaced with SIP (instead of H.323) Experimental SIP-enabled Avaya 46 A web page can be popped with a 30 (trademark) IP videophone.

  SIP complements the notification and response system 100 of the present invention in various ways. In particular, SIP provides a mechanism that allows recipients to set their contact preferences on a single server and apply those preferences to their contacts. While SIP-enabled recipients can represent their preferences via SIP, conventional recipients can still define individual communication flows within the notification and response system 100. The recipient uses the SIP mechanism to control how and when the notification is received, while notifying the non-SIP end points and preferred SIP designated end points via the communication flow within the notification and response system 100 Is expected to determine how and when to send. That is, just as SIP and integrated messaging allow you to control how messages are received, the notification and response system 100 controls how the enterprise sends messages. It should be noted that SIP control over the method of receiving messages can be enhanced by the functions of communication flow formulas and communication flow rules in accordance with the disclosure herein.

  The SIP Contact class further illustrates several advantages of the architecture of the notification and response system 100. In particular, the content of the notification message in the notification and response system 100 includes two forms that identify the recipient and device that are contacted with the request by a web browser or telephone browser, or a form servlet called XFS, as follows: By calling with an argument, it can be taken out with MediaContact.

http: // xui / XFS? Rid = xui-1234-1 & Cid = 1
However, Rid is a request ID and cid is a medium contact ID. Together, the two are sufficient to identify the recipient. In XFS, the request manager 1200 is simply used to retrieve the appropriate request, which is also used to obtain the URL of the notification message. This message is then retrieved, redirected to a response, rewritten to personalize the message, and forwarded to a browser or other destination.

To support multiple languages and media types, the XFS servlet can be modified to accept two additional parameters that specify the desired language and MIME type. For example, in a more general version of XFS, a specific language and format type can be retrieved as follows:
http: // xui / XFS? Rid = xui-1234-1 & Cid = 1 & Ctype = text / plain & Language = ENU
This specifies that an English plain text version request "xui-1234-1" is required.

In the example of the notification and response system 100, the notification is delivered to the SIP-enabled Avaya videophone simultaneously in two ways, as a voice message over the phone and a web page pop on the screen. This was done by letting SEE specify on the video phone that it can handle both Web pop and audio connections. SEE then calls XFS twice as follows, but first retrieves the HTML page and the second retrieves the VXML page.
http: // xui / XFS? Rid = xui-1234-1 & Cid = 1 & Ctype = text / html & Language = ENU,
http: // xui / XFS? Rid = xui-1234-1 & Cid = 1 & Ctype = text / vxml & Language = ENU

  As already mentioned, when using the notification and response system 100, the application 110 (requester) asks questions, specifies the type of response desired, and receives collated responses from the recipient via email. Can do. FIG. 14 illustrates a web form 1400 that allows the application 110 to specify parameters for a team meeting request. In the example of FIG. 14, Joann sends a request to schedule a meeting to “YangQian” and “Petsche”. If these recipients agree on the meeting time and location, the request is forwarded to the manager (cmk) for confirmation of attendance. The generated request is sent to the indicated recipient via different media contacts as appropriate. The request has a yes button and a no button, and responds to the request. FIG. 15 shows the result of compiling the request. As shown in FIG. 15, Petsche could attend the meeting, but YangQian was unable to attend the meeting and the manager was not contacted.

  In another example shown in FIG. 16, the requester provides shares in a new company IPO block allocation to be assigned to a preferred customer within four hours. Temporal constraints are applied to the named communication flow PreferredCustomers. PreferredCustomers are converted into a parallel combination of recipients. The requester gives his best customer a set of options in the request. The request for email version received by each recipient defined by the named communication flow PreferredCustomers specifying email preferences is shown in FIG. The matched response is returned as soon as all recipients have responded or as soon as the 4 hour subscription period is over. If the recipient cannot respond within 4 hours and then attempts to display or respond to the request, an appropriate message is displayed and no reply is required or accepted.

  In another embodiment of the present invention, referred to as “Reverse 911”, the notification and response system 100 can send an emergency 911 response. For example, communication flow formulas and rules can be defined to notify parents when an urgent problem occurs at school. In such cases, it is difficult to organize the necessary resources in case of an emergency that requires the school to contact the parent or guardian of each child at school. The Reverse 911 system of the present invention provides an automated approach to contact parents and takes important preventive measures to prevent improper or unauthorized use and to minimize false alarms. You can also. In the Reverse 911 system, the parent needs to register his / her preferences for contacting the service provider in an emergency. At school, once activated, contact with all parents can be initiated in parallel using a web interface or email. The notification can optionally include a button for the parent to notify receipt of the message. In addition, the school may specify an approval process request using the techniques described herein that must be met before the notification is sent to the parent, and utilize other security features to Functionality can be enhanced (eg, login and access control where measures are taken to verify the requester). In this way, the present invention can achieve security “putting people in the loop”.

  The same Reverse 911 system can be used in other variations, such as helping the Red Cross and government agencies find and schedule blood donors during a crisis, or resident nearby for specific disasters such as chemical spills But will be apparent to those skilled in the art based on the disclosure herein.

  In yet another embodiment of the present invention, referred to as “adaptive scheduling”, the notification and response system 100 can notify a designated recipient of a schedule change. For example, if mass transit means such as trains or airplanes are delayed, or if commuters get involved in a traffic jam on the way to a meeting, inform the parties of the schedule change and make sure that the participant's schedule is appropriate. Notification and response system 100 can be configured to coordinate revisions. For example, the calendar agent approach described herein can automatically revise such a schedule. The passenger can specify a communication flow rule that is initiated when, for example, an e-mail message titled = “Flight Information *” is received. Communication flow rules may provide information about contact information in case of delays, such as limousine services, colleagues, or spouses. Notifications can provide information specific to affected recipients. For example, limousine service notifications require an alternative pick-up time, and co-worker notifications involve a co-worker rescheduling the meeting (for example, using a calendar agent) or a meeting in the absence of a late passenger (Using the delegates function).

  As is known in the art, the methods and apparatus described herein can be distributed as an article of manufacture comprising a computer readable medium on which computer readable code means are implemented. The computer readable program code means operates in conjunction with the computer system to perform all or part of the steps, perform the methods described herein, or are described herein. Can be manufactured. The computer readable medium can be a recordable medium (eg, floppy disk, hard drive, compact disk, or memory card) or a transmission medium (eg, optical fiber, World Wide Web, cable). Or a network including radio channels using time division multiple access, code division multiple access, or other radio frequency channels). If a medium capable of storing information suitable for use with a computer system is known or developed, it can also be used. Computer readable code means is a mechanism for a computer to read instructions and data, such as magnetic variations on a magnetic medium or height variations on the surface of a compact disk.

  The computer system and server described herein each comprise a memory that configures an associated processor to implement the methods, steps, and functions disclosed herein. The memory can be distributed or local memory, and the processors can be distributed or single. The memory can also be implemented as electrical memory, magnetic memory, optical memory, or a combination of these or other types of storage devices. Further, the term “memory” can be interpreted broadly as encompassing information that can be read from and written to addresses in the addressable space accessed by the associated processor. With this definition, the associated processor can retrieve information from the network, so the information about the network remains in memory.

  The embodiments and variations shown and described herein are merely illustrative of the principles of the invention and various modifications can be made by those skilled in the art without departing from the spirit and scope of the invention. It will be understood that they can be added.

FIG. 2 is a notification and response system incorporating features of the present invention. FIG. 2 is a detailed diagram of the notification and response system of FIG. 3 is a sample table from the example request database used by the request manager of FIG. 3 is a flow diagram illustrating a ternary logic evaluator incorporating features of the present invention. 3 is a sample table from the recipient configuration and role database example of FIG. FIG. 6 is a diagram of a portion of the LDAP configuration tree from the recipient configuration and role database of FIG. 5 showing the personal naming context of multiple recipients. 6 is a sample table from another part of the recipient configuration and role database of FIG. 6 is a sample table illustrating an example of a set of primitives for a communication flow expression according to the present invention. FIG. 9 is a diagram of a truth table for the various primitives shown in FIG. FIG. 9 is a diagram of a truth table for the various primitives shown in FIG. FIG. 9 is a diagram of a truth table for the various primitives shown in FIG. FIG. 9 is a diagram of a truth table for the various primitives shown in FIG. FIG. 9 is a diagram of a truth table for the various primitives shown in FIG. FIG. 9 is a sample table in which the counts of the respective primitives shown in FIG. 8 are aggregated. FIG. 3 illustrates the interaction between the request manager and the communication flow manager shown in FIG. 12 is a flowchart illustrating in detail the operation of the request manager of FIG. 12 is a flowchart illustrating in detail the operation of the request manager of FIG. 11. 12 is a flowchart for explaining in detail the operation of the communication flow manager of FIG. 11. It is a figure of the example of Web forms which can specify the parameter of the request of a team meeting by an application. It is a figure which shows the result of having compiled the request | requirement of FIG. It is a figure which shows the example in case a request | requirement side provides a stock with the block allocation of the new company initial public offering (IPO) allocated to a preferable customer within 4 hours. FIG. 17 is a diagram of an example email message sent to a particular recipient in response to the request of FIG.

Claims (70)

A method for sending a message from a sender to at least one recipient via a communication flow having multiple potential paths, comprising:
Receiving a response from the at least one recipient;
Selecting at least one path in the communication flow based on the response.   The method of claim 1, further comprising modifying a reply-to address in the message to ensure that the response reaches the intended destination.   3. The method of claim 2, wherein the modified reply-to address allows an intermediary to be used as the sender's agent.   The method of claim 2, wherein the modified reply-to address allows an intermediary to provide a response processing service to the sender.   The method of claim 1, wherein the selecting comprises determining subsequent communications to one or more recipients.   The method of claim 1, wherein, in the selecting step, the received responses are aggregated to evaluate whether a predefined message completion condition is met.   The method of claim 1, wherein the selecting comprises determining a completion status for returning response information to the sender.   The method of claim 7, wherein the response information is provided to the sender in a format specified by the sender.   The method of claim 1, wherein the message is provided to the at least one recipient according to configuration information specified by the corresponding at least one recipient.   The method of claim 1, wherein the content of the message is obtained almost immediately after the message is sent to the at least one recipient.   Further comprising evaluating the communication flow, wherein the communication flow refers to at least one communication flow rule defined by the at least one recipient, the communication flow rule comprising at least one environment of the recipient. The method of claim 1 including the step of specifying settings.   The method of claim 1, wherein the communication flow references at least one configuration of the at least one recipient as specified by a company associated with the at least one recipient.   The method of claim 11, wherein the communication flow rule includes at least one time condition.   The method of claim 11, wherein the communication flow rule includes at least one media configuration.   The method of claim 11, wherein the communication flow rule includes an environment setting of at least one human language type.   The method of claim 11, wherein the communication flow rule is evaluated almost as soon as the message is sent to the at least one recipient.   12. The method of claim 11, wherein the communication flow references at least one media configuration of the at least one recipient to receive the message and stores the at least one media configuration at a central location.   The method of claim 11, wherein the communication flow controls call processing with a SIP proxy.   The method of claim 18, wherein the SIP proxy evaluates an incoming SIP INVITE message and selects an appropriate call routing rule for the at least one recipient. A method for sending a message from a sender to at least one recipient via a communication flow, comprising:
Receiving the message from the sender;
Evaluating the communication flow and specifying at least one environment setting of the sender for delivering the message by the communication flow;
Processing the message based on the preferences of the sender.   21. The method of claim 20, further comprising providing response information to the sender in a format specified by the sender.   21. The method of claim 20, wherein the content of the message is obtained almost immediately after the message is sent to the at least one recipient.   Further comprising evaluating the communication flow, wherein the communication flow refers to at least one communication flow rule defined by the at least one recipient, the communication flow rule comprising at least one environment of the recipient. 21. The method of claim 20, including the step of specifying settings.   21. The method of claim 20, wherein the communication flow refers to at least one configuration of the at least one recipient as specified by a company associated with the at least one recipient.   24. The method of claim 23, wherein the communication flow rule includes at least one time condition.   24. The method of claim 23, wherein the communication flow rule includes at least one media configuration.   24. The method of claim 23, wherein the communication flow rule includes an environment setting of at least one human language type.   24. The method of claim 23, wherein the communication flow rules are evaluated almost as soon as the message is sent to the at least one recipient.   24. The communication flow of claim 23, wherein the communication flow references at least one media configuration of the at least one recipient to receive the message and stores the at least one media configuration centrally in a central location. Method. A method for sending a message from a sender to at least one recipient via a communication flow having multiple potential paths, comprising:
Receiving the message from the sender;
Controlling the communication flow with a communication flow expression including at least one primitive keyword that evaluates the communication flow and indicates how to process the message;
Processing the message based on the communication flow equation.   The primitive keyword must contact two specified operands A and B at the same time, and the communication flow expression is successful if and only if both A and B respond normally. The method of claim 30 shown.   The primitive keyword is that for the two specified operands A and B, only if A responds normally must contact B, and the communication flow expression indicates that both A and B responded normally 32. The method of claim 30, wherein the method is successful if and only if so.   31. The primitive keyword indicates that two specified operands A and B must be contacted simultaneously, and the communication flow expression indicates that either A or B will succeed as long as it responds normally. The method described in 1.   The primitive keyword must only contact B for two specified operands A and B if it fails to contact A, and the communication flow expression is either A or B normal 32. The method of claim 30, indicating success when responding to.   31. The method of claim 30, wherein the primitive keyword indicates that two specified operands A and B must be contacted simultaneously, and the communication flow expression has a first contact value to respond to. .   The primitive keyword must contact B for two specified operands A and B only if it fails to contact A, and the communication flow expression is the first non-maybe response 32. The method of claim 30, wherein the method is indicated to have a value.   31. The method of claim 30, wherein the primitive keyword indicates that multiple recipients must be contacted at the same time, and that the communication flow expression is successful if a particular threshold of success response is received. .   31. The method of claim 30, wherein the primitive keyword indicates that multiple recipients must be contacted sequentially, and the communication flow expression is successful if a particular threshold of success response is received. .   The method of claim 30, wherein the primitive keyword indicates that multiple recipients must be contacted in parallel.   40. The method of claim 39, further comprising the step of canceling the outstanding request when the outstanding request is complete.   The method of claim 30, wherein the primitive keyword indicates that multiple recipients must be contacted sequentially.   32. The method of claim 30, wherein the primitive keyword indicates that one or more potential operand values must be inverted.   32. The method of claim 30, wherein the communication flow expression is evaluated using ternary logic.   44. The method of claim 43, wherein the three possible logical values are a notification failure, a response failure, and a response success.   31. The method of claim 30, wherein the communication flow formula includes a success check that indicates when the communication flow formula should end.   46. The method of claim 45, wherein the success check specifies a ternary formula for variables that can be included in a response received from the at least one recipient.   46. The method of claim 45, wherein the success check performs an aggregation on all received responses and processes the responses.   31. The method of claim 30, wherein the communication flow formula can step up content to the next level and cancel pending messages associated with the current level prior to the step up.   31. The method of claim 30, wherein the communication flow formula allows content to be stepped up to the next level and holds a pending message associated with the current level prior to the step up.   The method of claim 30, wherein the communication flow expression defines an environment setting for the sender and the at least one recipient.   32. The method of claim 30, wherein the communication flow expression is evaluated upon delivery to the at least one recipient.   The communication flow expression refers to a communication flow rule defined by the at least one receiver, and the communication flow rule can adjust the communication flow according to the characteristics of the sender. The method described in 1.   The communication flow expression refers to a communication flow rule defined by the at least one recipient, and the communication flow rule can adjust the communication flow according to characteristics of the message. The method described.   32. The method of claim 30, wherein the communication flow expression indicates one or more actions to perform if the at least one recipient does not respond to the message.   31. The method of claim 30, wherein the communication flow equation allows the at least one recipient to delegate the message to another recipient.   31. The method of claim 30, wherein the at least one recipient can delegate the message to another recipient after reading the message according to the communication flow equation.   32. The method of claim 30, wherein the communication flow equation uses a time constraint 58 to indicate an environment setting for the at least one recipient.   The method of claim 30, wherein the communication flow expression uses a time domain to indicate an environment setting for the at least one recipient. A method for sending a message from a sender to at least one recipient via a communication flow, comprising:
Receiving the message from the sender;
Evaluating the communication flow, the communication flow being evaluated almost in time with the message being sent to the at least one recipient;
Processing the message based on the preferences of the sender.   60. The method of claim 59, further comprising obtaining the content of the message almost in time with the message being sent to the at least one recipient. A method for sending a message from a sender to at least one recipient via a communication flow having multiple potential paths, comprising:
Receiving the message from the sender;
Controlling the communication flow with a communication flow expression including a communication flow expression that evaluates the communication flow and indicates a method of processing the message, the communication flow expression being evaluated using ternary logic;
Processing the message based on the communication flow equation. A system for sending a message from a sender to at least one recipient via a communication flow having multiple potential paths, comprising:
A memory for storing computer readable code;
A processor coupled to the memory and operable, wherein the processor is configured to execute the computer-readable code, the computer-readable code comprising:
Receiving a response from the at least one recipient;
A system comprising: selecting at least one path in the communication flow based on the response. A system for sending a message from a sender to at least one recipient via a communication flow, comprising:
A memory for storing computer readable code;
A processor coupled to the memory and operable, wherein the processor is configured to execute the computer-readable code, the computer-readable code comprising:
Receiving the message from the sender;
Evaluating the communication flow and specifying at least one environment setting of the sender for delivering the message by the communication flow;
A system configured to process the message based on the environment setting of the sender. A system for sending a message from a sender to at least one recipient via a communication flow having multiple potential paths, comprising:
A memory for storing computer readable code;
A processor coupled to the memory and operable, wherein the processor is configured to execute the computer-readable code, the computer-readable code comprising:
Receiving the message from the sender;
Controlling the communication flow with a communication flow expression that includes at least one primitive keyword that evaluates the communication flow and indicates how to process the message;
A system configured to process the message based on the communication flow equation. A system for sending a message from a sender to at least one recipient via a communication flow, comprising:
A memory for storing computer readable code;
A processor coupled to the memory and operable, wherein the processor is configured to execute the computer-readable code, the computer-readable code comprising:
Receiving the message from the sender;
Evaluating the communication flow, the communication flow being evaluated almost as soon as the message is sent to the at least one recipient;
A system configured to process the message based on the environment setting of the sender. A system for sending a message from a sender to at least one recipient via a communication flow having multiple potential paths, comprising:
A memory for storing computer readable code;
A processor coupled to the memory and operable, wherein the processor is configured to execute the computer-readable code, the computer-readable code comprising:
Receiving the message from the sender;
Controlling the communication flow with a communication flow expression that evaluates the communication flow and indicates how to process the message, the communication flow expression is evaluated using ternary logic;
A system configured to process the message based on the communication flow equation. A system for sending a message from a sender to at least one recipient via a communication flow having multiple potential paths, comprising:
Means for receiving a response from the at least one recipient;
A system comprising means for selecting at least one path in the communication flow based on the response. A system for sending a message from a sender to at least one recipient via a communication flow having multiple potential paths, comprising:
Means for receiving the message from the sender;
Means for controlling the communication flow by a communication flow expression including at least one primitive keyword that evaluates the communication flow and indicates how to process the message;
A system comprising means for processing the message based on the communication flow equation. An article of manufacture for sending a message from a sender to at least one recipient via a communication flow having multiple potential paths,
A computer readable medium having computer readable code means mounted thereon, wherein the computer readable program code means comprises:
Receiving a response from the at least one recipient;
A product comprising selecting at least one path in the communication flow based on the response. An article of manufacture for sending a message from a sender to at least one recipient via a communication flow having multiple potential paths,
A computer readable medium having computer readable code means mounted thereon, wherein the computer readable program code means comprises:
Receiving the message from the sender;
Evaluating the communication flow, wherein the communication flow is controlled by a communication flow expression that includes at least one primitive keyword that indicates how to process the message;
A product comprising the step of processing the message based on the communication flow equation.

Images