Patent Application
20080147804
In the business environment and in the personal environment, there is an increasing drive to improve efficiency and accuracy while handling an ever-increasing volume of communication and flow of information. One example of this is messaging systems such as e-mail, instant messaging, and text messaging. Specifically, when a message system user needs information from someone else, they typically send a message (such as by e-mail) to another message system user requesting the desired information.
Shortly after sending the requesting message, the user who sent the message will be intently looking for the response to his/her request for information. However, as time passes and additional tasks are performed the user who has sent the request for information may lose track of the messages that he/she sent for which he/she is awaiting a response.
Currently e-mail messaging system users can mark their e-mail messages with a follow-up tag to make sure that they follow up on those messages for which they have requested a response. However, present e-mail systems do not do much to help the system user when responses are actually received. Instead, it is up to the system user, who tagged the message to correlate the response to the request, take the information request off of his/her to-do list and remove the tag from the message or delete the tagged message from his/her e-mail file.
Moreover, present e-mail systems do not manage messages that request a response. Nor do present systems evaluate messages against a message policy and perform policy actions when the policy is violated.
The invention provides a method, program product, and system for managing messages for which a response has been requested (i.e., response requested messages). In an exemplary embodiment of the invention, a method for managing response requested messages enables a user to mark a message as a response requested message. The response requested message is presented at a user interface. A response message is linked to the response requested message, and presented at a user interface. The user is queried for response satisfaction. The user interface is updated to reflect the status of the response requested message.
The features and advantages of the invention will be more clearly understood from the following detailed description of the preferred embodiments when read in connection with the accompanying drawing. Included in the drawing are the following figures:
The invention provides a system for managing messages for which a response has been requested (i.e., response requested messages). In an exemplary embodiment, a message for which a response is desired is marked or tagged as RESPONSE REQUESTED. Potential responses to the RESPONSE REQUESTED message are associated with it by the system. The system behavior is based on threading technology. Threading technology correlates related messages into a single thread (i.e., an original sent or received message, sent and received responses to the original message, sent and received responses to the responses, etc.). For example a thread of e-mail messages are grouped together, including all sent and received e-mail replies (children) responding to a particular thread (parent). The focus of current threading technology is to group response messages with the sent message to which they respond. It should be understood, however, that not all messages that are sent are meant to create a thread for which a response is awaited. Thus, in this exemplary embodiment, only messages marked as RESPONSE REQUESTED are managed by the system.
When a response is received to a RESPONSE REQUESTED message, the response is associated with the previously sent RESPONSE REQUESTED message using threading technology. Threading technology can operate in a variety of ways. For example, a new message (which is not a reply to a previous message—i.e., parent message) is assigned a global unique identifier (GUID) in the header block of the message. When a reply is created to the original message, such as by using a reply or forward function in e-mail, the GUID of the parent message is applied to the header block of the reply message, which is a child of the original message. Thus, a string of messages or a conversation can be threaded or grouped together using the common GUID. Alternatively, threading may be accomplished by associating messages using user and/or thread information or by filtering messages using common context and characteristics of the messages.
The response message and the RESPONSE REQUESTED message are then presented to the system user for evaluation of the response. If the user indicates that the response is satisfactory the RESPONSE REQUESTED tag is removed and the user interface is updated for this change in status.
The client device 110 is enabled for sending and receiving messages through the network, 120, such through an e-mail client program that is stored in memory 112 and loaded in whole or in part into RAM to be executed by the processing unit 111. The processing unit 111 also executes reply requested program code 20 stored in the memory unit (and loaded as necessary into RAM) and allows a user to mark a message as a response requested message through the input device 113. When a response message is received, the response requested program 20 is executed by the processing unit 111 linking the response message to the response requested message and querying the user for response satisfaction at the user interface 114. The processing unit 111 also updates message data in the memory unit 112 and displays message data at the user interface 114.
It should be understood that the response requested program 20 is stored in memory 112 and may be integral with an e-mail client application or the like. Moreover, the response requested message is transferred in whole or in part into RAM (not numbered) during operation. Also, the memory 112 in the illustrated example may be resident on the client device 110 and may take the form of an internal or external drive. Alternatively, the memory may be external the client device 110.
In an exemplary embodiment of the invention, the message is presented to a second system user at a user interface presentation as RESPONSE REQUESTED (step 210). The second user in this example is the system user from whom a response is requested. In an exemplary case the particular user interface presentation is the message recipient's e-mail inbox. This presentation may be embodied in a variety of ways, as will be discussed with reference to
The recipient of the RESPONSE REQUESTED message, in the normal course of events, replies to the RESPONSE REQUESTED message, providing a response message, containing a response such as requested information. The system user who marked the RESPONSE REQUESTED message receives this subsequent message (step 250), which may or may not satisfy the previously requested response.
Using threading technology, the subsequent message is linked to the RESPONSE REQUESTED message (step 260), if it is in the same thread (e.g., has a common GUID, matches user or thread information, meets filtering criteria, or the like). Thus, the response requested program 20 automatically associates potential responses to the RESPONSE REQUESTED message with the RESPONSE REQUESTED message.
The response requested program 20 presents the associated response message and RESPOSE REQUESTED messages to the system user who marked the RESPONSE REQUESTED message (step 270). This presentation is performed at a user interface using one of a variety of interface presentations. For example, the response message and the RESPONSE REQUESTED message may be presented together in a single e-mail presentation showing each e-mail thread in which the system user has been a sender or a recipient. Alternatively, the response message may be presented in an inbox interface presentation with a RESPONSE REQUESTED tag. Then, by selecting the response message, such as by highlighting it, an interface presentation showing the thread to which the response message belongs can be presented.
When the system user opens the response message, the response requested program 20 queries the system user whether or not the response satisfies the RESPONSE REQUESTED message (step 275). The response requested program 20 may perform this step in a user interface presentation by presenting a checkbox for selection, by providing a dialog box for the system user to open, or any other method for enabling a system user to indicate a choice at a user interface.
If the system user determines that the response message satisfies the RESPONSE REQUESTED message, he/she selects the appropriate checkbox or indicates satisfaction through the dialog box or other method. The response requested program 20 then unmarks the satisfied RESPONSE REQUESTED message (step 280) and updates the message status at the user interface (step 290).
If the system user determines that the response message does not satisfy the RESPONSE REQUESTED message, he/she does not select the appropriate checkbox or otherwise indicate satisfaction. Thus, a RESPONSE REQUESTED message that has not been satisfied continues to be marked as RESPONSE REQUESTED at the user interface.
In an exemplary embodiment of the invention, a message that is marked as RESPONSE REQUESTED (step 200) is evaluated against message policies (step 220). This step can be performed, for example, by an operation or code sequence in the response requested program 20 that automatically runs at periodic intervals. An exemplary message policy that RESPONSE REQUESTED messages are evaluated against is notification of response date or time. The response date or response time may be a default value programmed into the policy or may be selected by the system user who sets the RESPONSE REQUESTED status. The policy defines the action that is taken when the policy is violated. Essentially, the policy defines a time limit for an action and the response taken for violating the time limit.
The response requested program 20 determines whether or not the RESPONSE REQUESTED message violates the message policy (step 225). If the RESPONSE REQUESTED message violates the message policy, then the response requested program 20 initiates a policy action (step 230) and presents the policy violation at a user interface (step 240). The response requested program 20 continues to receive and evaluate response messages and to evaluate the message policy. If the RESPONSE REQUESTED message does not violate the message policy, then the response requested program 20 continues to receive and evaluate response messages and to evaluate the RESPONSE REQUESTED message for violations of the message policy.
In the example where the message policy is a response date or time, the response requested program 20 compares the requested date or time for a response to the RESPONSE REQUESTED message to the actual date or time. If the requested date or time is later than the actual date or time the policy is not violated. If the requested date or time is earlier than the actual date or time the policy is violated.
In an example where the policy is a requested response date or time, the policy action upon violation of the policy is to change the status of the RESPONSE REQUESTED message to PAST DUE RESPONSE REQUESTED message. A further violation action may be, for example, a message to the entity from which the response is requested, reminding that entity of the RESPONSE REQUESTED message and the expiration of the date or time of the request. Another further policy action might be a reminder note to the entity that marked the RESPONSE REQUESTED message.
When a policy violation occurs, the response requested program 20 presents the policy violation at a user interface (step 240). In the forgoing example, the policy violation may be presented, for example, by highlighting the past due RESPONSE REQUESTED message in a requestor's user interface presentation and/or a user interface presentation of the entity from whom the response is requested. Alternatively, another form of communication may be driven (e.g., sending a page to a pager, placing a pre-defined phone call, contacting the receiver's manager via a note, etc.)
Another example of a message policy is a time limit for sending any e-mail message. One might assume that if a person has not sent any e-mail messages for a period of time, then they are probably out of the office. The response requested program 20 could be cognizant of the fact that a person has not sent any e-mail correspondence in a prescribed period of time, which would indicate an absence, and the policy could have a defined escalation path for such an occurrence.
The RESPONSE REQUESTED option 320, allows the system user to mark a message as RESONSE REQUESTED. In the illustrated example, the RESPONSE REQUESTED option 320 is a checkbox 321 provided on a tool bar in the e-mail system user interface. It should be understood, however, that the RESPONSE REQUESTED option might be realized in a variety of ways. For example, it could be provided in a dialog box that can be opened from the addressing presentation or another user interface presentation. Alternatively, the system user sending the RESPONSE REQUESTED message might right click a name in any of the addressing fields, and select from a pop-up box the choice of response requested.
In the illustrated exemplary embodiment, a system user has selected the RESPONSE REQUESTED checkbox 321. As shown, selecting the RESPONSE REQUESTED checkbox 321 has caused the response requested program 20 to include the words Response Requested in the subject 340 of the message in the illustrated embodiment. In this embodiment, selecting the RESPONSE REQUESTED checkbox 321 also causes the response requested program 30 to display an expiration date/time 325 and to open a RESPONSE REQUESTED user interface presentation 410 (shown in
The expiration date/time 325 may be a default generated by the response requested program 20 or selected by the system user based on when the RESPONSE REQUESTED status is invoked. In an exemplary embodiment, the default expiration date/time 325 may be modified to create a custom expiration date/time by which the response is requested.
The system user marking a message as RESPONSE REQUESTED may select another system user from whom he/she would like a response. This may be accomplished in various ways. For example, the response requested program 20 might enable the system user to select one or more addresses from the addressing interface presentation 310, such as by highlighting and selecting addresses. Alternatively, the response requested program 20 may automatically open a separate RESPONSE REQUESTED presentation 410 as shown in
As shown in
To enhance efficiency, headers 513-516 for received RESPONSE REQUESTED messages may be segregated from message headers for other received messages under a RESPONSE REQUESTED heading 550. Moreover, the headers 513-516 for RESPONSE REQUESTED messages may be displayed before the headers for normal messages. Thus, a system user may easily be provided with a visual reminder of messages for which a response is requested, enhancing a system user's ability to identify, manage, and satisfy requests for responses using a messaging system.
In the exemplary embodiment illustrated in
In an exemplary embodiment, the headers for all messages in a particular thread may be displayed in a message thread user interface presentation 710, as illustrated in
In an exemplary embodiment, as shown in
For each message 721, 722, 723, the author of the message 731, 732, 733 respectively is displayed, and the date and time when each message was sent 741, 742, 743 respectively are displayed. The sender 770 of the current message and the subject 780 and last update 790 for the thread are also displayed.
In the illustrated example, the first response 722 is highlighted. The response text for the highlighted message, in this example the first response text 760 is also presented in the thread user interface presentation 710. An icon 773 adjacent to a message author indicates that the message is from the entity from which a response is requested (in this case the third author 733). Thus, a system user can view a listing of the messages 721, 722, 723 in a message thread, identify messages from the response requestee, and view the text 770 for one of these messages all in a single user interface presentation 710.
To enhance the effectiveness of the response requested program 20, the response requested program 20 presents an evaluation icon 750 in the message thread user interface presentation 710 in an exemplary embodiment of the invention. By selecting the evaluation icon 750, a system user is presented with an evaluation user interface presentation 810, as shown in
Although illustrated and described above with reference to certain specific embodiments, the present invention is nevertheless not intended to be limited to the details shown. Rather, various modifications may be made in details within the scope and range of equivalents of the claims and without departing from the spirit of the invention. For example the term RESPONSE REQUESTED is used for ease of description, however any other term or symbol may be used in the various user interface presentations to indicate a status where a response is expected. Also, the response requested program 20 could be more basic in the sense of whether there was a response (meaning any response) to a RESPONSE REQUESTED message, or there was no response. For example, one might want the opposite of a response requested, meaning he/she only wants a response if the recipient no longer needs access to a particular database, and if no response is received the lack of a response will be considered as an affirmative answer.
