Patent Application
20090037537
The present invention relates to computers, and deals more particularly with tracking history of e-mail messages.
Electronic mail, more commonly referred to as “e-mail”, has become pervasive as a means of communications. As is well known, e-mail systems accept electronic messages and store them for delivery; the delivery occurs when the recipient logs on to the e-mail system and receives his or her waiting messages. A sender of an e-mail message is generally unaware of when the recipient receives a particular sent message, unless the recipient takes action to notify the sender (for example, by sending a return e-mail message acknowledging the original message in some way) or unless the e-mail message is sent with a “return receipt” feature enabled. In this latter case, an acknowledgement message may be sent to the sender automatically when the recipient opens the e-mail message (although some return receipt features may allow the recipient to suppress sending of this automatic acknowledgement).
The present invention is directed to tracking history of electronic mail (“e-mail”) messages. In one embodiment, this comprises: sending, from a first e-mail client to a second e-mail client, a tracking request to request history pertaining to an e-mail message previously sent from the first e-mail client to the second e-mail client, the tracking request identifying the previously-sent e-mail message and configured to cause the second e-mail client to return the requested history to the first e-mail client. The tracking request may comprise a copy of the previously-sent e-mail message with a tracking request X-header appended thereto; in another approach, the tracking request comprises a copy of the previously-sent e-mail message with a tracking request e-mail object embedded therein. The history may be gathered, for example, from local storage accessible to the second e-mail client or from storage accessible to an e-mail server upon request from the second e-mail client, and may comprise (by way of example) how the previously-sent e-mail message was processed at the first e-mail client.
In another embodiment, the present invention comprises: receiving, at a second e-mail client from a first e-mail client, a tracking request that requests history pertaining to an e-mail message previously sent from the first e-mail client to the second e-mail client, the tracking history tracking request identifying the previously-sent e-mail message; gathering the requested history, by the second e-mail client; and returning the requested history as a reply sent from the second e-mail client to the first e-mail client. The reply may comprise a copy of the previously-sent e-mail message with a tracking reply X-header appended thereto; as one alternative, the reply comprises a copy of the previously-sent e-mail message with a tracking reply e-mail object embedded therein.
In another embodiment, the present invention comprises: forwarding a tracking request from a first e-mail client to a second e-mail client, the tracking request to request history pertaining to an e-mail message previously sent from the first e-mail client to the second e-mail client, the tracking request identifying the previously-sent e-mail message and configured to cause the second e-mail client to return the requested history to the first e-mail client; and forwarding a reply from the second e-mail client to the first e-mail client, responsive to the second e-mail client receiving the tracking request from the first e-mail client and returning the gathered history in the reply, the reply configured to cause the first e-mail client to process the gathered history.
Embodiments of these and other aspects of the present invention may also, or alternatively, be provided as systems or computer program products. It should be noted that the foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined by the appended claims, will become apparent in the non-limiting detailed description set forth below.
The present invention will be described with reference to the following drawings, in which like reference numbers denote the same element throughout.
Although e-mail messaging provides a tremendous amount of flexibility and convenience for people to communicate with each other, problems may arise in some circumstances. Suppose, for example, that an e-mail user “Bill” is a support engineer for a software company, and that Bill's responsibilities include handling second-level problem reports. That is, Bill's role includes investigating reports on problems that cannot be immediately solved by lower-level support personnel and which must be referred to more experienced personnel such as Bill.
It may be common that Bill does some initial investigation and thereby discovers that he needs to contact a software developer for more information or assistance, and Bill may send an e-mail message for this purpose. Such e-mail messages generally have no formal structure, and instead may be composed as a free-form message to the software developer. After sending the e-mail message, Bill typically relies on the software developer to respond with the requested information or assistance.
It may also be common that the software developer does not respond to Bill in a timely manner. The developer may be busy with other tasks, for example, or may choose not to give priority to Bill's request; or, Bill's request may be overlooked for other reasons. Failure to receive a response from the developer may prevent Bill from being able to complete his problem resolution task, and Bill may have to resort to other approaches such as escalating to a manager in the software development organization or finding an alternative software developer and beginning the process anew. Such approaches represent an inefficient use of resources and introduce unnecessary delay into the business process.
In the general case, Bill does not know why his e-mail message to the software developer went unanswered. It could be, for example, that the developer didn't read (or perhaps even receive) the message, or it may have been automatically transferred to a junk e-mail folder during an automated filtering operation, or it may have been accidentally deleted by the developer before it was read, and so forth. Without some type of information about what happened to his original e-mail message, Bill cannot make an informed decision about how best to proceed in the absence of a response. For example, if Bill assumes that the developer intentionally ignored the message when in fact the message was lost in transmission and didn't reach the developer, Bill might become frustrated and make remarks when escalating to management that could damage Bill's future working relationship with the software developer.
By contrast, if Bill had information about whether his message was received and/or opened by the software developer, he could react to a lack of response in a more appropriate manner. For example, if Bill knew that the message was identified as junk e-mail by an automated filter, he might decide to call the software developer instead of attempting further e-mail communications. Or, if he knew that the message arrived but was not opened by the recipient, Bill might decide to resend the message with an “urgent” flag set to thereby call the message to the developer's attention. As another possibility, it might happen that the developer received the message and forwarded it to a colleague with specialized knowledge, and that this colleague is working on Bill's request. If he had this information, Bill might send a reminder message to the colleague or perhaps contact the colleague by phone.
Current art allows an e-mail sender to request various types of information about an e-mail message before sending the message. For example, the sender might request a delivery confirmation, return receipt, and/or route tracing for the message. However, the present inventors know of no current systems that provide detail regarding what happened to the message after it was received at the recipient's system. And, a major drawback of such current systems is that the e-mail message sender must know in advance of sending the message that he wants to use the delivery confirmation, return receipt, and/or route tracing for the message and must take appropriate action before the message is sent.
While the e-mail communications problems described above are illustrated in terms of a particular business scenario, it will be obvious to the reader that these problems are representative of many other e-mail communication scenarios and that such scenarios are not limited to a business environment: similar problems may occur in e-mail communications among friends and family members as well as among business colleagues.
By contrast to the current art, embodiments of the present invention enable an e-mail message sender to initiate history tracking operations (which may also referred to herein as “tracking”) on a particular message after the message has already been sent; this may be referred to as “post-transmission tracking”. The tracking may even be initiated after the message has been received at the recipient's e-mail system; this may be referred to as “post-delivery tracking”.
History tracking details provided by an embodiment of the present invention may comprise how a particular message was managed in the recipient's e-mail system, including whether the receiving user explicitly deleted the message; whether it was automatically transferred to a junk e-mail folder by an automated filter; whether the user opened the message but did not create a response; whether the user created a response but did not yet send it; and so forth. Other types of tracking information that may be provided by an embodiment of the present invention include, by way of illustration but not of limitation, whether the message is read or unread; whether the message has been filed in a folder or forwarded to another user; whether the message has been marked as junk e-mail; and whether the user has explicitly performed actions on the message and/or whether automated actions have been performed on the message. Notably, the history tracking information for a particular e-mail message may persist for a longer period of time than that particular e-mail message itself (e.g., in cases where the history indicates that the e-mail message was deleted).
Optionally, an embodiment of the present invention may enable an e-mail recipient to control the level of reporting that his e-mail system will provide to a message sender's e-mail system. In addition or instead, an embodiment of the present invention may optionally enable an e-mail recipient to be notified that a request for tracking information is received. In either case, one manner in which such control features may be enabled or disabled is through use of configuration data. Configuration data is discussed in more detail below.
Referring now to
As shown in
Block 110 tests whether the sending user receives a response as expected. For example, if the original e-mail message includes a question for the recipient, then Block 110 corresponds to determining whether an answer to that question has been received. Preferably, a user provides the answer to the test at Block 110. For example, a dialog window or other technique may be used for querying the sending user as to whether the expected response is received. As one alternative, a programmatic process may be provided for making this determination. If the test in Block 110 has a positive result, then no further actions are deemed necessary for this e-mail message and the processing of
Otherwise, when the test in Block 110 has a negative result, the sender uses techniques disclosed herein that resend the original e-mail message with a history tracking request associated therewith (Block 130). In one approach, associating a history tracking request with an e-mail message comprises appending a new request X-header to the e-mail message that connotes a history tracking request, and this request X-header triggers the receiving e-mail system to handle the request for tracking history. Resending the original e-mail request with this new request X-header enables a recipient e-mail system to determine which e-mail message is the subject of the history tracking request. (The general concepts of X-headers and their use in e-mail messages is well known to those of skill in the art, however use of X-headers for tracking history of e-mail messages, as disclosed herein, is not). The receiver-side response to receiving the request X-header is discussed in more detail below with reference to
As one alternative approach to the logic illustrated in
After resending the e-mail message with its associated history tracking request, control may optionally transfer from Block 130 to Block 110 (as shown by a dotted line in
Referring now to
When the test in Block 210 has a positive result, on the other hand, then processing continues at Block 220. Block 220 tests whether this e-mail client supports the requested tracking. This test may have a negative result, for example, for a prior art e-mail system. If the client does not support the request X-header, processing continues at Block 270.
When control reaches Block 230, this is an indication that the receiver-side e-mail client supports processing for the history tracking request X-header described herein. Block 230 then tests whether the user of this e-mail client allows such requests to be processed. As mentioned earlier, configuration data may be used for recording the user's preferences, and such configuration data may be processed to answer the test at Block 230 in a manner transparent to the user. The configuration data may comprise, by way of example, specifying that this particular user either approves (or disapproves) of all history tracking requests, or that this user approves (or disapproves) of history tracking requests matching particular criteria (such as requests from particular senders, requests containing certain keywords, requests received at certain dates or times, and so forth).
As one alternative to using configuration data, the user at the receiving e-mail client may be queried at Block 230 to determine whether he or she approves the processing of this history tracking request. An embodiment of the present invention may optionally be adapted for presenting the incoming request message that contains the history tracking request X-header to the user, and may do so to assist the user in making a decision at Block 230 (or for other purposes).
If the test in Block 230 has a negative result, processing continues at Block 270, which has been discussed above.
If the test in Block 230 has a positive result, then processing reaches Block 240 where the requested tracking information is obtained. The processing performed at Block 240 preferably comprises collecting already-generated tracking information. Or, the tracking information may be generated responsive to reaching Block 240. In one approach, a user of an e-mail client configures the client to store gathered history tracking information for a particular period of time, after which the information may be purged (either automatically or upon confirmation by the user). The e-mail system itself preferably tracks history associated with individual e-mail messages in an on-going manner after receipt of such messages, such as whether a message was automatically handled by a filter, what time it was received and what actions were performed upon the message by the user after receipt (including, by way of example, whether it was explicitly deleted by the user) and at what time those actions were performed, and so forth.
The history tracking information may be obtained from storage that is local to the e-mail client, or it may be obtained from another location such as a centralized database accessible to a plurality of e-mail clients. Or, portions of the history tracking information may be obtained from multiple locations. For example, a portion thereof may be obtained from the local e-mail client while another portion may be obtained from an e-mail server. Refer to
Referring again to
It may happen, in some cases, that no history tracking information is available. In such cases, an embodiment of the present invention may supply a message to this effect in the reply message created at Block 250. Or, this scenario may be accommodated by transferring control from Block 240 to Block 270 (which has been discussed above). While logic pertaining to the “absence of history tracking information” scenario has not been explicitly shown in
At Block 260, the reply message is then sent to the original sending e-mail system (i.e., the e-mail client from which the request X-header was sent), after which the processing of
Referring again to
When the test in Block 140 has a positive result, then processing reaches Block 160 where the history tracking information from the incoming reply message is preferably presented to the user. As one alternative, the history tracking information might be stored in a repository, such as a log file or database, from which the user may retrieve the information at some subsequent time. Or, the history tracking information might be processed programmatically, for example by a report generator. Control may transfer from Block 160 to Block 120, thereby exiting from the processing in
While the e-mail history tracking of the present invention is described herein with reference to use of X-headers, this is by way of illustration but not of limitation, and other techniques may be used without deviating from the scope of the present invention. As one example, an embodiment of the present invention may use an e-mail object that is embedded in e-mail messages, where the e-mail object in a request message specifies a request for tracking e-mail history when sent (instead of a request X-header) at Block 130 of
As will be appreciated by one of skill in the art, embodiments of the present invention may be provided as (for example) methods, systems, and/or computer program products. The invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes (but is not limited to) firmware, resident software, microcode, etc. Furthermore, the present invention may take the form of a computer program product which is embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein, where this computer program product may be used by or in connection with a computer or any instruction execution system. For purposes of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (“RAM”), a read-only memory (“ROM”), a rigid magnetic disk, and an optical disk. Current examples of optical disks include compact disk read-only memory (“CD-ROM”), compact disk read/write (“CD-R/W”), and DVD.
Referring now to
Input/output (“I/O”) devices (including but not limited to keyboards 418, displays 424, pointing devices 420, other interface devices 422, etc.) can be coupled to the system either directly or through intervening I/O controllers or adapters (416, 426).
Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks (as shown generally at 432). Modems, cable modem attachments, wireless adapters, and Ethernet cards are just a few of the currently-available types of network adapters.
Still referring to
The gateway computer 546 may also be coupled 549 to a storage device (such as data repository 548).
Those skilled in the art will appreciate that the gateway computer 546 may be located a great geographic distance from the network 542, and similarly, the wireless devices 510 and/or workstations 511 may be located some distance from the networks 542 and 544, respectively. For example, the network 542 may be located in California, while the gateway 546 may be located in Texas, and one or more of the workstations 511 may be located in Florida. The wireless devices 510 may connect to the wireless network 542 using a networking protocol such as the Transmission Control Protocol/Internet Protocol (“TCP/IP”) over a number of alternative connection media, such as cellular phone, radio frequency networks, satellite networks, etc. The wireless network 542 preferably connects to the gateway 546 using a network connection 550a such as TCP or User Datagram Protocol (“UDP”) over IP, X.25, Frame Relay, Integrated Services Digital Network (“ISDN”), Public Switched Telephone Network (“PSTN”), etc. The workstations 511 may connect directly to the gateway 546 using dial connections 550b or 550c. Further, the wireless network 542 and network 544 may connect to one or more other networks (not shown), in an analogous manner to that depicted in
The present invention has been described with reference to flow diagrams and/or block diagrams according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flow diagram flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flow diagram flow or flows and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flow diagram flow or flows and/or block diagram block or blocks.
While embodiments of the present invention have been described, additional variations and modifications in those embodiments may occur to those skilled in the art once they learn of the basic inventive concepts. Therefore, it is intended that the appended claims shall be construed to include the described embodiments and all such variations and modifications as fall within the spirit and scope of the invention.
