System and method for response management in multiple email recipients

[0001] The present invention is related to the subject matter of U.S. patent application Ser. No. 10/880,729, incorporated herein by reference.

[0002] This invention is related to the field of electrical computers and digital processing systems to transfer data via one or more communications media, in general, and specifically, to a means for coordinating multiple responses to a single message in a demand based messaging system.

[0003] A demand-based messaging system is any communication system that enables a person to exchange electronic messages with another person over a communications media. Demand-based messaging systems typically comprise a network of data processing machines and a messaging program operable on at least one machine to transfer electronic messages over the network to one or more of the other machines. Electronic messages typically are composed of a variety of information, including message data and transmission data. As those terms are used here, “message data” generally refers to the substance of the message, such as text or images, while “transmission data” generally refers to the information required to deliver or respond to the message, such as the correspondents' electronic addresses. Electronic messages also may include status information, such as the time and date that the message was composed, sent, or received.

[0004] LOTUS NOTES, MOZILLA, and MICROSOFT OUTLOOK are exemplary messaging programs that enable users to exchange electronic mail messages through networked computers. Instant messaging (“IM”) programs such as MSN MESSENGER and YAHOO! MESSENGER, which have gained popularity in recent years, exemplify another embodiment of messaging programs that enable users to exchange electronic messages in real-time through networked computers.

[0005] A person often addresses a message to multiple recipients, and expects a response from one or more of the recipients. A team supervisor, for example, may send a question to the team without knowing who will be able to answer the question. Several team members may reply with the answer. Other team members may reply with information that is helpful, but not dispositive. Some team members may even reply with information on topics unrelated to the original question.

[0006] Responses from multiple message recipients, though, can cause problems for both the message originator and the message recipients, including duplicative effort, unnecessary delays, and general confusion. For example, a reply from one recipient may substantially repeat a reply from another recipient, which generally is considered a waste of time and resources. Conversely, uncoordinated replies may conflict with each other, thereby creating confusion among the originator and recipients. Replies from multiple recipients also can create multiple message threads (i.e. discussions about a specific topic), which one person (often the originator) must manage and reconcile. Generally, the frequency of these types of problems increases proportionally with number of recipients.

[0007] Many, if not all, of these problems may be attributed to a larger problem that is common in all prior art messaging systems—the lack of an effective means for coordinating responses from multiple recipients. Recipients often do not know who should reply, or even if a reply is necessary. Nor does a recipient have any way to know if another recipient intends to reply. Of course, correspondents can adopt rules to coordinate responses, but all correspondents must know these rules in advance, which makes it more difficult to introduce new correspondents (from a different team, for example). Another alternative is to designate the appropriate respondents within each message, but the message originator may not know this information in advance.

[0008] U.S. Pat. No. 5,878,230 (the '230 patent) discloses a method for an originator of an email to specify one or more recipients in a reply address field as the destination whenever the recipient replies to the note, but does not provide the originator with a method to specify which third parties are to receive the reply, nor does the '230 patent provide identification of parties as they respond to an email.

[0009] Thus, there is a need in the art for an integrated means to coordinate responses from multiple message recipients.

[0010] The disclosed invention is an improvement to a demand-based messaging system that enables multiple message recipients to coordinate responses to the message. The improved messaging system comprises a messaging program that provides an interface through which a recipient can indicate an intent to reply to the message. The messaging program then transmits this intent to other messaging programs so that other recipients receive the intent as status information when they open the message.

[0011] These and other objects of the invention will be apparent to those skilled in the art from the following detailed description of a preferred embodiment of the invention.

[0018] A person of ordinary skill in the art will appreciate that the present invention may be implemented in a variety of software and hardware configurations. It is believed, however, that the invention is described best as a computer program that configures and enables one or more general-purpose computers to implement the novel aspects of the invention.

[0019] As used herein, “computer” means a machine having a processor, a memory, and an operating system, capable of interaction with a user or other computer, and shall include without limitation desktop computers, notebook computers, tablet computers, personal digital assistants (PDAs), servers, handheld computers, and similar devices.

[0020] As used herein, “message” means an electronic mail message transmitted between user terminals over a computer network.

[0021] As used herein, “electronic mail” or “email” means direct user-to-user transmission of messages between user computers over a network.

[0022] FIG. 1 illustrates a common prior art architecture for connecting various hardware devices to create a network for transferring data. Computer network 100 comprises local workstation 101 electrically coupled to network connection 102. In FIG. 1, local workstation 101 is coupled electrically to remote workstation 103 via network connection 102. Local workstation 101 also is coupled electrically to server 104 and persistent storage 106 via network connection 102. Network connection 102 may be a simple local area network (LAN) or may be a larger wide area network (WAN), such as the Internet. While computer network 100 depicted in FIG. 1 is intended to represent a possible network architecture, it is not intended to represent an architectural limitation.

[0023] The internal configuration of a computer, including connection and orientation of the processor, memory, and input/output devices, is well known in the art. FIG. 2 represents the internal configuration of a computer having the computer program of the present invention loaded into memory 200. The computer program of the present invention is depicted as Response Management Program (RMP) 230. Memory 200 also has messaging program 220 and reply history file 240. Memory 200 is only illustrative of memory within a computer and is not meant as a limitation.

[0024] In alternative embodiments, RMP 230 and reply history file 240 can be stored in the memory of other computers. Storing RMP 230 and reply history file 240, in the memory of other computers allows the processor workload to be distributed across a plurality of processors instead of a single processor. Further configurations of RMP 230 and reply history file 240 across various multiple memories and processors are known by persons skilled in the art.

[0025] FIG. 3 depicts a representative email 300 with header 310 and message area 320. Header 310 has icon 330, reply summary 332, reply options icon 340, and get info button 360. Icon 330 is a visual depiction that a recipient has “called” the email and intends to reply. In the example, icon 330 shows a human hand pointing upward representing the gesture that a baseball player may use to indicate that he has called the ball and intends to catch the ball. Reply summary 332 is a short text message informing the user that a recipient, in this case “Joe Smith” intends to reply. Get info button 360 provides the user with a means to display reply status and history window 380. Upon clicking (or otherwise activating) get info button 360, reply status and history window 380 opens and displays the activity in regard to reply messages from the date and time that the originator sent the original email.

[0026] FIG. 4 depicts email 300 where the user clicked reply options icon 340 (see FIG. 3) to bring up reply option window 370. The user may then select from the options displayed in reply option window 370. By way of example, and not by way of limitation, reply option window 370 contains selections to indicate reply to a particular addressee or to reply to all addressees. Additionally, the reply may be with history and attachments or with history and without attachments.

[0027] FIG. 5 depicts a flow chart of the RMP 230 process. RMP 230 starts (502) and determines whether there is an email with multiple recipients (505). If so, the email is opened (510). If not, RMP 230 goes to step 590. RMP 230 displays a summary of the reply status (520) (see reply summary 332 in FIG. 3). If one or more recipients of the same email have indicated that they will reply to the email, then RMP 230 displays the identity of those recipients indicating intent to respond. RMP 230 determines whether detailed reply information is needed (530). In other words, does the user want more information about the message recipients who has indicated that they will respond to the email? If so, RMP 230 gets detailed reply information from reply history file 240 (540). If not, RMP 230 determines whether the user wants to reply to the message (550). If the user wants to reply to the message, then the user “calls” reply to the email (560). By “call” is meant that the user indicates to RMP 230 his or her intention to reply to the email. When the user “calls” the reply, he or she does not lock out other persons who may also want to reply to the email. RMP 230 then updates the reply status for the email on the server (570), and updates the display of the reply status for other users who may have the email open (580). For example, if a reply is already open and another user then opens the email and begins a response, a message to the central server or to the peer client may update the email. RMP 230 cannot update offline users. If the user did not want to reply at step 550, or after RMP 230 updates the email of other recipients (580), RMP 230 determines whether there is another email (590). If so, RMP 230 goes to step 510. If not, RMP 230 stops (592).

[0028] In an additional embodiment, RMP 230 automatically handles emails that are forwarded to other recipients who are not on the original email, or who are not directly involved in RMP 230, or who are later left out of the message chain. In order to automatically handle such emails, RMP 230 would be configured so that the addition of an addressee to a subsequent message in a chain of messages would be added to the reply history file. Moreover, the deletion of an addressee from a subsequent message in a chain of messages would be noted in the reply history file.

[0029] In an additional embodiment, RMP 230 may be integrated with an Instant Messaging program.

[0030] A preferred form of the invention has been shown in the drawings and described above, but variations in the preferred form will be apparent to those skilled in the art. The preceding description is for illustration purposes only, and the invention should not be construed as limited to the specific form shown and described. The scope of the invention should be limited only by the language of the following claims.