Patent Publication Number: US-7596594-B2

Title: System and method for displaying and acting upon email conversations across folders

Description:
RELATED APPLICATIONS 
     This application claims the benefit of U.S. Provisional Application No. 60/606,862, filed on Sep. 2, 2004, and titled “Email System and Method for Viewing, Searching, Tracking, and Indexing Email,” the contents of which are incorporated by reference as if fully disclosed herein. 
    
    
     BACKGROUND ART 
     1. Field of the Invention 
     This invention relates generally to electronic mail systems and, more specifically, to displaying and acting upon email conversations across folders. 
     2. Description of the Background Art 
     Electronic mail (“email”) has become an important means of communication. Many email users have large email mailboxes with numerous messages. Therefore, it is often convenient to group related messages together in order to enable users to automatically view related messages without having to search their mailbox. A grouping of related messages that are considered to be part of a single conversation is often referred to as a “conversation” in the art. An example of a conversation is an initial message and the subsequent replies to or forwards of such message (this is also referred to as an “email thread”). 
     In known email systems (sometimes also referred to as “collaboration suites” when they provide functionality in addition to just email, such as “calendar” and “contacts”), conversations are limited to related email messages within a single folder. In other words, known systems do not enable conversations to span folders in a user&#39;s mailbox. It is desirable to enable conversations to span folders, such as in the following example scenario: User #1 receives an email from a customer and forwards it to user #2to handle. User #1 moves the customer&#39;s email to the “trash” folder under the assumption that user #2 is handling the matter. If the customer emails user #1 again regarding the same subject matter, it is convenient for the email user #1 to see the customer&#39;s new message and original message automatically grouped together despite being in different folders (the original in “Trash” and the new one in “Inbox”). Known systems do not enable such grouping, but the present invention does. 
     Also, because known systems do not track conversations across folders, it is not possible to perform an action on a conversation across folders. For instance, if a user has some related email message in different folders, under the known art it is not possible for the user to tag all the messages in that conversation with one command. 
     It is worth noting that, in Google&#39;s current version of its email service “Gmail,” it appears that conversations span at least some folders (namely, “Inbox”, “Sent Mail” “Drafts,” and “Starred”), but this is not the case. Gmail currently has only three folders: “All Mail,” “Trash,” and “Spam,” and Google does not enable conversations to span such folders. Google presents “Inbox,” “Sent Items,” “Draft,” and “Starred” as folders, but these actually are not folders. 
     Folders are an organizational concept that partition messages in a mailbox so that every message is in one and only one folder. As stated above, in Gmail, the Inbox, Starred, Sent Mail, and Draft “folders” are not folders, Rather, the Inbox “folder” is the search results of all items in the All Mail folder with the label “Inbox”, the Starred “folder” is the search results for items in the All Mail folder flagged with a star, the Sent Mail “folder” is the search results for items in the All Mail folder sent by the user, and the Drafts “folder” is the search results for items in the All Mail folder which have not yet been sent. The consequence of that is that a single-message conversation can appear in Gmail&#39;s Inbox, Starred, Sent Mail, and Draft “folders” at the same time because such conversation is really just in the “All Mail” folder. However, Google does not enable conversations to span “Inbox” and “Trash” because “Trash” is a separate folder from “All Mail.” Similarly, in Gmail, conversations cannot span “Trash” and “Spam” or “All Mail” and “Spam” because these are all separate folders. 
     SUMMARY OF THE INVENTION 
     The present invention provides a system and method for displaying and/or acting upon email conversations across folders. In one embodiment, the method comprises: (1) grouping email messages into conversations, where such grouping is performed independent of the folders in which the messages reside, thereby enabling conversations to span multiple folders; and (2) displaying one or more conversations, where, for each message in a displayed conversation, the folder associated with such message is identified. Grouping conversations independent of folders enables a user to easily view or act upon a full email thread, even if a user has moved select messages within a thread to another folder or folders. 
     In another embodiment of the invention, the method comprises (1) grouping email messages into conversations, where such grouping is performed independent of folders in which messages reside; (2) receiving a command to perform an action on a conversation; (3) performing the action upon all messages in the conversation regardless of the folders in which the messages reside, unless it is specified that the action should apply only to messages in select folders, in which case the action will apply to only those messages in the conversation that are in such select folder, or unless it is specified that the action should apply only to messages matching a search query, in which case the action will apply only to those messages in the conversation matching the specified query. The indication as to which folders the action should apply may be a system-level indication (which may be set by the system administrator) or it may be a user indication (either a default user setting or an explicit user command). 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a method for displaying email conversations across folders. 
         FIG. 2  illustrates a method for grouping email conversations across folders. 
         FIG. 3  illustrates a method for displaying email conversations. 
         FIG. 4  illustrates a method for performing an action upon a conversation across folders. 
         FIG. 5  illustrates a further embodiment for performing an action upon a conversation across folders. 
         FIG. 6  illustrates an example of the method for performing an action upon a conversation. 
         FIG. 7  is a block diagram of an example email application of the present invention. 
         FIGS. 8-10  are screen shots illustrating example applications of the methods described herein. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     The present invention provides a system and method for displaying and/or acting upon email conversations across folders.  FIG. 1  illustrates a method for displaying email conversations across folders. Such a method may be implemented by the combination of (1) an email server application that provides email services to users (such an email application typically runs on a server often referred to as a “mail server”), and (2) an email client application (“email client”) through which a user interfaces with the email server application. 
     The method illustrated in  FIG. 1  comprises grouping email messages into conversations, where such grouping is performed independent of folders in which the messages reside, thereby enabling conversations to span multiple folders (step  110 ). The method also comprises displaying one or more of the conversations, where, for each message in a displayed conversation, the folder associated with such message is identified. In one embodiment, the display includes all messages regardless of the folder in which the message reside, and in another embodiment, messages in select folders, such as the spam folder, may be eliminated from the display. 
       FIG. 8  illustrates an example of an email client that displays conversations across folders. In this example, the user received a message, replied to it, and moved the original message to the trash. The user then received a subsequent message with the same subject line, and consequently the conversation spans the “Inbox,” “Sent,” and “Trash” folders. 
       FIG. 2  illustrates one way in which email messages may be grouped across folders. According to this method, when an email server application receives a message, it determines whether or not it is a forward, reply, or other type of follow-up message (hereinafter the term “follow-up message” means a forward, reply, and/or other similar type of message) (step  210 ). The email server application can determine if the incoming message is a follow up message from the subject field in the email message header. If the incoming message is not a follow-up message, the email server application creates an open conversation based on the subject line of the incoming message (step  220 ), and associates an incoming message with the created conversation (step  230 ). 
     In one embodiment, creating an open conversation means creating a unique identifier for the conversation. Such unique identifier is referred to as a “conversation ID” herein. One way to associate an incoming message with a conversation is to persistently store the conversation ID in a message object associated with the message, where the message object is a file that includes summary information about the email message (an example of such summary information is the unread status of the message, the received date, and excerpts from the email message headers). 
     With respect to the determination in step  210 , if the incoming message is a follow-up message, the email server application normalizes the subject line by removing the parts of the subject line that identify the message as a follow-up message (such as “Re:” and “(fwd)”) (step  235 ). The email server application then determines whether or not an open conversation already exists for the normalized subject line (step  240 ). If an open conversation does not exist for the normalized subject line, the email server application creates an open conversation for such normalized subject line and associates the incoming message with the created conversation (steps  220 ,  230 ). An example of when this scenario would arise is when user #1 emails user #2, user #2 replies to user #1 and copies user #3. The message received by user #3 would be a follow-up message that is not associated with an existing open conversation. 
     If an open conversation exists for the normalized subject line, the email server application determines how recently the last received message in the conversation was received (step  250 ). The rationale behind this is that, if the last-received messages is more than x many days old (where x can be any positive number—in one implementation it is 31), it likely corresponds to a different email conversation than the incoming message. If the last received message was received prior to a certain date, the email server application closes the existing conversation, and creates a new conversation for the incoming message (as described with respect to steps  220  and  230 ). 
     If the last-received message in the existing conversation was received after the specified date (meaning is fairly recent), then the email server application associates the incoming message with the existing open conversation (step  270 ). In an alternate embodiment, between steps  250  and  270 , the email server application compares header information (i.e., email metadata) in the incoming message with header information in the last-received message in the existing conversation. For instance, the email server application might compare the Message-ID and References headers of each message to see if they correspond. In this alternate embodiment, if a comparison of the header information indicates the messages are likely related, then the email server application associates the incoming message with the existing open conversation. Otherwise, it creates a new conversation for the incoming messages (as described with respect to steps  220  and  230 ). 
       FIG. 3  illustrates one way in which an email server application can enable display of conversations (i.e., one way in which step  120  in  FIG. 1  can implemented). The email server application fetches a message object associated with a message for which a conversation view is desired (step  310 ). As stated above, a message object includes summary information about a message, including a field for a conversation ID. The email server application then retrieves the conversation ID from the message object (step  320 ) and searches for other message objects having the same conversation ID (step  330 ). Information in the message objects is then used to enable an email client to display information about the messages in the identified conversation (step  340 ). In an alternate embodiment, information about messages in each conversation is cached by the email client, and, instead of steps  330  and  340 , the email client application retrieves the cached information and uses the cached information to display the conversation view. 
     In one embodiment of the present invention, a user may perform an action upon a conversation and have the action apply to the entire conversation or only to messages in selected folders in the conversation. As illustrated in  FIG. 4 , in this embodiment, an email server application groups email messages into conversations, where such grouping is performed independent of folders in which the messages reside, thereby enabling conversations to span multiple folders (step  410 ). In response to receiving (via an email client) a command from a user to perform an action upon a conversation (step  420 ), the email server application performs the actions upon all messages in the conversation regardless of the folders in which the messages reside, unless it is specified that the action should apply only to messages in select folders, in which case the action will apply to only those messages in the conversation that are in such select folders (step  430 ). The indication as to which folders the action should apply may be a system-level indication (which may be set by the system developer or administrator) or it may be a user indication (either a default user setting or an explicit user command). Having conversations that are independent of folders allows the system developer, system administrator, and/or user maximum flexibility to determine on a case-by-case basis whether the action will apply to the conversation across all folders or just select folders. 
       FIG. 9  illustrates the conversation in  FIG. 8  after the user has moved the conversation to the “Trash” folder. In this case, the folder column  910  indicates that all messages in the conversation are now in the “Trash” folder. 
       FIG. 5  illustrates a further embodiment in which a user may perform an action upon a conversation. The email server application groups email messages into conversations, where such grouping is performed independent of folders in which the messages reside, thereby enabling conversations to span more than multiple folders (step  510 ). The email server application receives a search query from a user (via an email client) and performs a search based on the search query (step  520 ). The email server application then provides the search results to the applicable email client, which displays the search results, where the display includes conversations associated with the search results (step  530 ). In response to the email server application receiving a request from a user to perform an action upon a conversation (step  540 ), the email server application performs the action on all messages in the conversation that satisfy the search query regardless of the folders in which the messages reside, unless it is specified that the action should apply only to messages in select folders, in which case the action will apply to only those messages in the conversation matching the search query that are in such select folders (step  550 ). As stated above, the indication as to which folders the action should apply may be a system-level indication (which may be set by the system developer or administrator) or it may be a user indication (either a default user setting or an explicit user command). 
       FIG. 6  illustrates an example of a method for performing an action on a conversation. In this example, the email server application receives a command to tag a conversation (step  610 ). The email server application then retrieves or creates a tag ID for the tag (step  620 ). The email server application retrieves the relevant message objects associated with messages in the conversation (step  630 ). The relevant message objects may be the message objects for (1) all messages in the conversation, (2) messages in the conversation in select folders, or (3) messages in the conversation satisfying a search result. The email server application saves the tag ID in the relevant message objects (step  640 ), and the applicable email client displays the tags in association with all the relevant messages in the conversation (step  650 ).  FIG. 10  illustrates an example of the result when a user tags the conversation illustrated in  FIG. 9  with a tag  1010  labeled “Personal”. 
       FIG. 7  is a block diagram of an example email server application for implementing the methods described herein. Such email server application can be implemented in various ways, and the embodiment discussed with respect to  FIG. 7  is just an example of one such implementation. The illustrated email server application executes on a server, and email users access mailbox information stored by the illustrated email server application through email client applications. 
     For ease of explanation, the email server application  710  can be thought of as divided into various functional modules, which are depicted in  FIG. 7 . These modules are a Mailbox Interface  770 , a Query Parser  730 , an Indexer  735 , a Database Management Module  740 , a Message Store Interface  745 , an MTA Interface  720 , an Email Client Interface  715 , and a Web Server Interface  725 . In one embodiment these modules are coded in Java. Those skilled in the art will appreciate that an email server application will include additional functionality not represented by the above modules (such as functionality related to security, user management, global address lists, etc.). Such functionality is well known in the art. 
     The Database Management Module  740  is a set of routines for managing, storing and retrieving information in a relational Database  755  (e.g. MySQL). The Database  755  includes information about each provisioned email user&#39;s mailbox that is used to generate a view of the user&#39;s mailbox. It contains a listing of the contents of a user&#39;s mailbox (with a reference to the actual storage location of the messages in the Message Store  760 ), and it includes mutable information about such content, such as which folder each message resides (inbox, sent items, user-created folders, etc.) or which messages have been read. In one embodiment, the Database  755  is where message objects associated with messages are stored, where each message object includes summary information (i.e., metadata) about the email message to which it correspond. 
     The Message Store Interface  745  is software for storing and retrieving email messages in a Message Store  760 . The Message Store (often referred to as the “Blob Store” in the industry) stores the actual email messages, including any attachments embedded within email messages. Techniques for storing and retrieving email messages, as well as storing and retrieving user-specific mailbox information to generate a view of a user&#39;s mailbox are well known in the art. 
     The Indexer  735  indexes email messages based on the content of the messages and on the metadata in the headers of the email messages. The Indexer also may index email attachments based on content and metadata. The Indexer  735  stores the indexes in Index  750 . The Indexer  735  also stores a copy of some of the static metadata in the Index  750 . In an alternate embodiment, the functionality of the Indexer  335  and the Database Management Module  740  are combined, and the indexes and user mailbox information are stored in one database. 
     The Web Server Interface  725  is the interface through which the email server application  710  communicates with web servers. In one embodiment, the Web Server Interface  725  provides the initial page of an email client application presented to the user. In one embodiment, such initial page provides JavaScript code, which is downloaded into a user&#39;s browser to become the email client application. 
     The Email Client Interface  715  is the interface through which the email server application  710  communicates with email client application. In one embodiment, the Email Client Interface  715  supports the industry-standard POP and IMAP protocols as well as a SOAP protocol. 
     The MTA Interface  720  receives incoming messages for provisioned users (i.e., users who have mailboxes with the email application  710 ) from a Mail Transfer Agent (MTA) (not shown). In one embodiment the MTA uses the Local Mail Transfer Protocol (LMTP) to communicate with an MTA Interface  720  that uses the Simple Mail Transfer Protocol (SMTP). The MTA forwards incoming email message to the Mailbox Interface  770 . 
     The Mailbox Interface  770  processes incoming email messages, including parsing the email message headers for metadata. The Mailbox Interface  770  sends the message and metadata to the Indexer  735 , Database Management Module  740 , and Message Store Interface  745 , as applicable. In one embodiment, the Mailbox Interface  770  performs the method described with respect to  FIG. 2  for grouping email messages. In such embodiment, the Mailbox Interface also instructs the Database Management Module to perform steps  310 - 320  in  FIG. 3 , and provides the resulting conversation information to the Email Client Interface  715  to enable email client applications to display the conversation. 
     The Mailbox Interface  770  includes a Query Parser  730 , which parses all requests that involve searching the Index  750  or the Database  755 . In response to receiving such requests, the Query Parser  730  creates appropriate query trees and sends them to the Indexer  735  and/or the Database Management Module  740 , depending on whether or not the Index  750  or the Database  755  have the appropriate information. The Query Parser  730  receives, and if necessary, assembles the responses to the query trees from the Indexer  735  and Database Management Module  740  and forwards it to the appropriate interface (such as the Email Client Interfaces  315 ) for transmittal to the requesting systems. 
     As will be understood by those familiar with the art, the invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the above disclosure of the present invention is intended to be illustrative and not limiting of the invention.