CN102609831B - Search message in e-mail system based on dialogue - Google Patents

Abstract

Methods and server systems performed on a server system having one or more processors and memory are disclosed. The method includes: in response to a single search query from a respective user: searching a message repository to identify a plurality of conversations associated with the respective user, wherein each of the plurality of conversations includes at least one querying for related messages, and each of the plurality of identified dialogs includes one or more messages sharing a set of common characteristics satisfying predefined criteria; sending a list of dialogs representing at least a subset of the identified dialogs , wherein at least one conversation in the list includes a plurality of messages; and content of the selected conversation from the list of conversations is provided including formatted information that visually distinguishes one or more of the selected conversations. a first message and one or more second messages of the selected conversation, wherein the one or more first messages are related to the search query and the one or more second messages are related to the search query irrelevant.

Description

Search for messages in a conversation-based email system

This application is a branch of an invention patent application whose filing date is March 25, 2005, application number is 200580016413.8 (international application number is PCT/US2005/010137), and the title of the invention is "Displaying dialog in a dialog-based email system". case application.

technical field

The present invention relates generally to the field of client-server computer network systems, and more particularly, the present invention relates to a system and method that allow a user to manage large volumes of messages in an efficient and user-friendly manner.

Background technique

For work and leisure, every day, people send and receive millions of electronic mails (also written as "E-mail") on computer networks. In many cases, e-mail has become an extremely popular communication channel for people to exchange information due to its convenience, ease of use, and near-instantaneous completion.

Traditionally, e-mail messages arriving at a user's e-mail account are displayed in chronological order by a dedicated e-mail client or individually in a Web browser window, e.g., the most recent message appears at the top of the browser window and the oldest Appears at the bottom of the browser window. However, it is common that multiple messages sent by two or more people may cover the same header at different times. Viewing messages together will help users understand each message in its proper context.

It would be particularly desirable to have a system and method for organizing and displaying a plurality of messages, including messages received by a user and messages sent by a user, according to their respective topics. It is also particularly desirable that all messages related to the same title and forming part of the same conversation be visualized so that the user can efficiently identify a specific message submitted by a specific sender, as well as enable the user to identify in relation to other messages in the conversation. These messages in that conversation are known in context.

Contents of the invention

In one embodiment, a method of processing messages receives a plurality of messages directed to a user, wherein each message has a unique message identifier. Each message of the plurality of messages is associated with a respective conversation, wherein each conversation has a respective conversation identifier. Also, each dialog includes a set of one or more messages that share a set of common characteristics satisfying a first predefined criterion. A list of conversations is displayed as a set of rows in an order determined by a second predefined criterion, where each row corresponds to one of the listed conversations and includes at least a list of senders, a conversation title, and a date/time value. When the user selects a conversation from the displayed conversation list, the content of the conversation is displayed.

According to one aspect of the present invention, there is provided a method performed at a server system having one or more processors and memory, the method comprising: in response to a single search query from a respective user: searching a message repository to identify a plurality of conversations associated with the user, wherein each of the plurality of conversations includes at least one message related to the search query, and each of the plurality of identified conversations includes sharing information that satisfies predefined criteria one or more messages of the set of common characteristics of the identified dialogs; sending a list of dialogs representing at least a subset of the identified dialogs, wherein at least one dialog in the list includes multiple messages; and providing formatted information from content of a selected conversation of a list of conversations, the formatted information visually distinguishes one or more first messages of the selected conversation from one or more second messages of the selected conversation, wherein the one or more A first message is relevant to the search query, and the one or more second messages are not relevant to the search query.

According to another aspect of the present invention, there is provided a server system comprising: means for searching a message repository to identify a plurality of conversations associated with a respective user in response to a single search query from a respective user, wherein the each of the plurality of dialogs includes at least one message related to the search query, and each of the plurality of identified dialogs includes one or more messages sharing a set of common characteristics satisfying predefined criteria; with means for sending a list of dialogs representing at least a subset of identified dialogs, wherein at least one dialog in the list includes a plurality of messages; and for providing a selected selection from the list of dialogs including formatted information Content of the dialog, the formatted information visually distinguishes one or more first messages of the selected dialog from one or more second messages of the selected dialog, wherein the one or more first messages are different from the selected The one or more second messages are not relevant to the search query.

Description of drawings

For a better understanding of the nature and embodiments of the present invention, reference should be made to the following description of various embodiments taken in conjunction with the following drawings, wherein like reference numerals refer to like parts throughout.

FIG. 1 schematically illustrates an embodiment of a client-server based network system according to the present invention.

Figure 2 is a general flowchart illustrating how the dialog assistant generates various forms for displaying dialogs provided by the dialog management system.

Figure 3A is a flowchart illustrating how the dialog assistant generates a table containing a list of dialogs.

FIG. 3B is a schematic screenshot of a conversation list in the "Inbox" category according to one embodiment of the present invention.

FIG. 4A is a flowchart illustrating the operation of the "More Actions" drop-down list.

Figure 4B is a screenshot of how a user can use the "More Actions" drop-down list to move a conversation from one category to another.

FIG. 5A is a flow chart illustrating the operation of the "add label" drop-down list.

Figure 5B is a screenshot of how a user can add a tag to a conversation using the "Add Tag" drop-down list.

FIG. 6A is a flow chart describing how the dialog assistant generates a dialog view in response to a display command from the dialog management system.

Figure 6B is a screenshot of a conversation view showing all messages in a compressed mode, according to one embodiment of the present invention.

Figure 6C is a screenshot of a conversation view with some messages displayed in compressed mode and some messages displayed in expanded mode, according to one embodiment of the present invention.

Figure 6D is a screenshot of a conversation view showing all messages in expanded mode, according to one embodiment of the present invention.

Figure 6E is a screenshot of a conversation view in which messages are displayed according to various embodiments of the invention.

FIG. 7A is a flowchart illustrating how the dialog assistant generates various forms for displaying dialogs matching a user's search request.

Figure 7B is a screen shot including 3 dialogs matching the query term "Tahoe" according to one embodiment of the present invention.

Figure 7C is a screenshot of messages in a dialog that match or do not match a query term, and where the messages are displayed in different modes, according to one embodiment of the present invention.

Figure 8 is a flowchart illustrating how the dialog assistant interacts with the user to correct all possible misspelled words.

Figure 9A is a screenshot of a dialog containing a reply message composed by a user.

Figure 9B depicts screenshots of 3 separate browser windows at different stages of the spell checking process.

Figure 10 depicts an embodiment of a dialog server.

Fig. 11 is a flowchart showing a method of processing a received message.

Fig. 12 is a flowchart showing a method of matching messages to dialogs.

Fig. 13 is a flowchart showing a method of assigning attributes to messages.

Fig. 14 is a flowchart showing a method of assigning attributes to dialogs.

FIG. 15 is a flow diagram illustrating a method for searching for conversations and generating representations of identified conversations.

Figure 16 depicts the message database.

Figure 17 depicts the user database and indexes for specific users.

Figure 18 depicts a set of data structures for identifying a dialog corresponding to a received message and for determining attributes associated with the received message.

Figure 19 depicts an embodiment of a dialog server.

detailed description

The invention relates to a client-server system and corresponding method for organizing and displaying messages sent to and by users.

Figure 1 schematically illustrates one embodiment of a client-server system. The system includes a session management system 102 , a communication network 106 and a plurality of clients 104 . A conversation includes one or more related messages overlaying the conversation title. As described below, in addition to conversation titles, additional criteria may be used to determine which messages are part of each different conversation. The sender and receiver of the message are the participants in the conversation. All messages directed to a user of the dialog management system 102 are grouped into multiple dialogs and presented to the user individually or collectively in a dialog-based format. In the following, a more detailed discussion regarding the implementation of the dialog management system 102 will be given.

Client 104 includes browser 108 and dialog assistant 110 . Browser 108 may be a general-purpose Internet browser (also sometimes referred to as a web browser) with a browser window for displaying conversations, or it may be a specialized browser application with a window for displaying conversations. Browser 108 translates the conversation and messages in the conversation using hypertext markup language (HTML) or any other suitable translation method. After the user submits a request to the session management system 102 via the browser 108 to access messages stored in his personal account, the session management system 102 identifies a number of sessions in the user's personal account according to the user's request, and These are transmitted back to the client machine 104 along with a set of display instructions. In response, dialog assistant 110 generates one or more tables following the display instructions, each table including information for certain dialogs. The form is then submitted to and translated by the browser 108 . In another embodiment, as an option, the dialog assistant 110 may also exist in the dialog management system 102 and operate in the dialog management system 102 .

FIG. 2 is a general flowchart illustrating how dialog assistant 110 generates various forms for displaying dialogs provided by dialog management system 102 . In step 202, after receiving multiple dialogs and related display instructions, in step 204, the dialog assistant 110 determines whether the user requests multiple dialogs or a single dialog. If the user requires multiple conversations, then at step 206 the conversation assistant 110 generates a table containing a list of conversations, each conversation occupying a row in the table. For each row in the table, at step 208, the dialog assistant 110 also generates a set of columns and related properties to be displayed according to the display instruction. Below, more details on how to translate the information in these columns and the associated properties will be given in conjunction with Figures 3A and 3B.

If the user requests a single conversation, the conversation assistant 110 generates at step 210 a different table for accommodating a series of messages related to the conversation. In step 212 , dialog assistant 110 generates a subtable and a set of related properties to be displayed for each message followed by a corresponding display instruction. Below, more details on how the dialog assistant translates such subtables and related properties will be given in connection with 6A-6D.

After generating a table to hold a list of conversations or a single conversation, at step 214 , dialog assistant 110 generates a table to hold a set of system-defined categories. Each system-defined category can be associated with zero or more dialogs. In one embodiment, a system-defined category is an attribute by which a dialog is selected by the dialog management system 102 in response to a user action or when predefined criteria are met. For example, the system associates a "trash" attribute with a conversation when the user marks it for deletion, but has not taken the steps required to permanently remove the conversation from the user's mail account. More specifically, the dialog management system 102 attaches the attribute "Trash" to a dialog, and removes an existing attribute, such as "Inbox," from the dialog, if desired. Note that some system-defined categories may be mutually exclusive. In another example, the system can automatically associate an "inbox" attribute and an "not read" attribute with newly received incoming messages. A more detailed discussion of the categories defined by the system is given below, in conjunction with Figures 4A and 4B.

Next, at step 216, dialog assistant 110 generates another form that houses a set of user-defined tags. Figure 3B depicts group box 347 in which this form is displayed. Each user-defined tag can be associated with zero or more conversations. In one embodiment, a user-defined tag is an attribute that can be associated with a specified session. Those conversations to which user-defined tags are assigned may be determined by specific user actions or by manipulation of filters or similar mechanisms. Unlike system-defined categories, these tags are defined arbitrarily by the user, and they are not mutually exclusive. In other words, it is possible to associate a conversation with multiple tags at the same time. For example, in a user's personal account, there may be two tags "Shopping List" and "Thanksgiving". The tag "shopping list" may be assigned to conversations related to shopping by the user or a filter created by the user, and the tag "Thanksgiving" may be assigned to conversations related to Thanksgiving activities, including Thanksgiving shopping. Since the user defines a label, the user can also delete this label. A more detailed discussion of user-defined tags is given below, in conjunction with Figures 5A and 5B. For group box 347, when a user selects (eg, clicks) a user-defined tag in group box 347, dialog assistant 110 submits a query to the dialog management system for locating dialogs associated with the user-selected tag. This query is then performed and a list of such conversations is submitted to the user, ie if there is a list of such conversations, this list is submitted to the user.

The dialog management system 102 and the dialog assistant 110 work together to allow the user to search for messages in the user's mail account and to submit the search results in a very intuitive manner. The dialog management system 102 extracts information from the user's email account, or processes messages composed by the user, while the dialog assistant 110 translates messages prepared by the dialog management system 102 . In other embodiments, a different division of tasks between dialog management system 102 and dialog assistant 110 may be used. Because many tasks performed by the system can be realized through the dialogue management system 102 or the dialogue assistant 110, or through the cooperative operation of the two, these two components are sometimes collectively referred to as "dialog system" herein.

At step 218, the dialog system (102 and/or 110) may generate a table to hold a set of searches submitted by the user, such that the user can revisit (or, more precisely, regenerate) recent search results. A more detailed description of search-based conversation list generation is given below in conjunction with FIGS. 7A-7C . Additionally, at step 220, the dialog system may also generate a table (eg, the table shown in group box 349 of FIG. 3B) for holding a set of dialogs recently accessed by the user. This feature is similar to a web browser's back button. At step 222, dialog assistant 110 submits the forms to browser 108 for display.

In addition to the order shown in FIG. 2, steps 214-220 may be performed in various possible orders. In some embodiments, some of these table generation steps may be omitted.

Generate conversation list

Referring now to FIG. 3A, the dialog management system 102 generates a dialog list (step 302), for example, in response to a user or client request for the user's mail account's inbox window. As will be explained in more detail below, the list of conversations is generated by performing a search of the user's mail account. To generate a list of conversations for the inbox window, the user's mail account is searched for conversations associated with the "inbox" attribute (sometimes referred to as a label). Then, at step 304, the dialog management system 102 prepares information about these dialogs for display, as will be described in more detail below. Additionally, at step 305, the dialog management system also generates a list of user-selectable actions and a list of user-selectable labels. The use of these user-selectable lists is illustrated below in conjunction with the discussion of FIGS. 4 and 5 . Then, at step 306, the resulting message is sent to the dialog assistant for translation.

At step 304, the dialog management system 102 iterates through a series of steps (from step 306 to step 324) to generate a set of fields for each dialog in the dialog list. In some embodiments, these fields may be translated by the dialog assistant 110 in columns to enable the user to easily scan the dialog list.

For each dialog and a group of related messages, the dialog management system 102 first generates a list of senders at step 307 . The sender list includes a plurality of sender identifiers, each identifier corresponding to a sender who has authored at least one message. The sender may be identified by their given name, last name, full name, e-mail address, photograph or unique icon, or a combination thereof. In some embodiments, if at least two senders have the same given name, a sufficient portion of each sender's last name is included in the corresponding sender identifier to distinguish the senders from one another. For example, if two senders both have the given name Paul and a surname with a different first letter, the concatenation of Paul and the first letter of the surname (eg, PaulB and PaulK) can be used to distinguish the two senders. Those of ordinary skill in the art will recognize other ways of identifying two senders with the same Christian name. In other embodiments, the sender's identifier may be based on information associated with the particular sender residing in the user's contact list. In yet other embodiments, a user may create a nickname for a particular sender that appears in the sender list. If the sender has authored multiple messages in the conversation, its identifier still appears only once in the sender list. In one embodiment, the sender identifiers in the list may be ordered according to the time of arrival of the sender identifier's corresponding message to the system 102 . In another embodiment, the sender identifiers in the table are sorted alphabetically according to their corresponding names. Next, at step 308, the dialog management system 102 formats the sender list to highlight one or more sender identifiers in the list according to the display instructions. Here, the use of the term "highlighting" means displaying in a visually distinct manner, such as bolding, underlining, changing background color, changing font color, changing font, etc. Also, in this context, the term "highlighting" means generating formatted information for displaying something (eg, a designated portion of text) in a differentiated manner. For example, in some embodiments, the sender's name is formatted to appear in bold characters if the user has not viewed his message or marked his message as read.

In some embodiments, the conversation assistant receives and has access to pictures of one or more people listed in the conversation's sender list and/or recipient list. When the user views a list of conversations or a single conversation and positions the cursor over a name or identifier in the list of senders, a photo of the sender is displayed. In some embodiments, the same functionality is provided for the listed message recipients when viewing a conversation. This feature may be particularly useful for e-mail systems used by large organizations.

In some embodiments, if the user himself has authored at least one message in the conversation, then at step 310, the conversation management system 102 uses a unique string for the user as his identifier in the sender list, or an icon , or other output prompt, to replace the user's name or other identifier in the sender list. One option for unique strings is a self-referential identifier in a particular language. For example, the pronoun "me" in English can be used to refer to the user in the sender list. Since many people share the same given name, this feature is more useful than identifying a sender by their first name in a sender list (which, of course, could be done in alternative embodiments). Representing a user by a unique identifier also helps the user to easily identify those conversations in which the user has actively participated by contributing at least one message.

If many people have contributed messages to the conversation, the list of senders may become too long to fit in the limited space in the browser window. This is especially the case if one or more senders in the sender list are identified by their email addresses. If this is the case, then at step 312 the dialog management system 102 prioritizes the senders in the sender list based on various information to identify a subset of the senders displayed in the browser window. In one embodiment, the subset includes at least the sender of the last message in the conversation and, where applicable, senders of messages that have not yet been viewed or marked as read by the user. In another embodiment, the subset includes the sender of the first received message in the conversation, the sender of the last received message in the conversation, and zero or more further senders selected according to a prioritization or scoring method . In some embodiments, higher priority is given to senders of messages that arrive later in time. This type of prioritization tends to increase the likelihood that senders of unread messages will be revealed. Other types of prioritization schemes may also be used. In some embodiments, when the sender list identifies only a subset of message senders in the conversation, the sender list includes an ellipsis "..." or other symbol indicating that the sender list is not full. In some embodiments, where there is more than one whose message has not been viewed by the user or has not been marked as read by the user, the subset is identified as may be as many senders as the available space allows many.

At step 314, the dialog management system 102 creates a message count indicator for the dialog that indicates the number of messages in the dialog, excluding messages that are permanently deleted or that are identified for deletion. The message number indicator may be a number in a pair of brackets, for example, "(3)" indicates that there are 3 messages in the conversation. In some embodiments, when a dialog includes only one message, no message count is generated for the dialog. The message number indicator can also be an icon. Icons may be color coded to provide additional information, for example, to indicate how many messages in the conversation remain unread (ie have not been viewed or marked as read). Next, at step 316, the session management system 102 generates a session title for the session being processed. Typically, the conversation title is the subject of the first message in the conversation, or a truncated version of the subject if it exceeds a predefined length. In another embodiment, the conversation title is determined by heuristically examining the content of the first message, or alternatively, not only the first message. In one embodiment, if the conversation includes at least one message with an "unread" attribute, both the message number identifier and the conversation title are highlighted in the browser window to draw the user's attention. In another embodiment, only the conversation title is highlighted to indicate one or more unread messages.

According to established email standards, messages can be sent to at least 3 types of recipients, a primary type of recipient whose address is listed in the "To:" field; two secondary type of recipients, listed in the "To:" field Cc:" field or their addresses are listed in the "Bcc:" field. Accordingly, the dialog management system 102 creates a recipient status indicator for the user at step 318, which is another indicator of the user's participation in the dialog. In one embodiment, a first distinguishing indicator, such as ">>", is used to mark conversations where the user is the primary recipient of any messages, and a second distinguishing indicator, such as ">", is used to mark conversations where Conversations in which the user is a secondary recipient of at least one message and is not the primary recipient of any messages, and in which the user is not explicitly listed as a recipient of any messages (for example, because the message was sent to a group or mailing list) are not Receive special marks. In other embodiments, conversations in which the user is the primary recipient of at least one message and conversations in which the user is only a secondary Receiver's dialogue. In another embodiment, conversations in which the user is the sole primary recipient of at least one message are marked using a first distinguishing indicator, such as ">>", and a second distinguishing indicator, such as ">" , to mark conversations in which at least one message was sent directly to the user's email address rather than a mailing list, and conversations in which the user was not explicitly listed as a recipient of any messages (for example, because the message was sent to a group or mailing list ) does not accept special tokens.

In some embodiments, the dialog management system 102 creates an excerpt of the dialog at step 320 . This excerpt provides the user with a preview of the content of the conversation without the user having to open the conversation. In one embodiment, snippets are generated based on recent messages in the conversation. In another embodiment, the excerpt is extracted from the first message in the conversation (ie, the oldest message). In yet another embodiment, excerpts are extracted from all messages in the conversation according to predefined heuristic rules, such as listing a set of keywords that appear most frequently in the conversation. If the dialog management system 102 is preparing a dialog listing in response to a user-submitted search, it creates a snippet at step 322 that includes a highlighted portion that matches the user-submitted query term. In one or more aspects, This is similar to including excerpts of search results returned by a search engine such as the Google search engine.

Finally, at step 324, the dialog management system 102 identifies a date/time value for the dialog. This date/time value generally dictates the display order of the list of conversations in the browser window. In some embodiments, each conversation in the list of conversations is assigned a date/time equal to the date/time of the most recent message matching the search criteria used to generate the list of conversations. For example, if a user-specified search query (e.g., "Tahoe Lake") is used, then for each matching conversation in the list of conversations, the assigned date/time is the latest news that matches the user-specified search query. date/time. In another example, if the search criteria is "Inbox" (i.e., conversations with at least one message assigned the Inbox label), then the date/time assigned to each conversation in the conversation list is the same as the Inbox The date/time of the latest news related to the box label. In some embodiments, the conversations in the conversation list are listed in reverse chronological order of their assigned date/time values (ie, most recent conversations are listed first). As used herein, a "date/time" value refers to a date value and/or time value associated with a particular message. Dates and/or times may be associated with messages based on the date and/or time of creation, transmission, receipt, or other event of the message.

In other embodiments, other methods or criteria may be used to assign a date/time to each conversation in the conversation list, and other methods may be used to sort the conversations according to their date/time values. For example, in some embodiments, when using the advanced search query facility, a user is given a dialog to review those dates/times that fall within a specified time window (and, if any, satisfy other user-specified search requirements). Search options. The resulting list of conversations is listed according to the length of time between the user-specified target date or target date/time and the date/time of each conversation in the list. Thus, conversations can be inserted into the resulting list of conversations before and after the target date or date/time.

FIG. 3B is a schematic screenshot of a conversation list in the "Inbox" category according to one embodiment of the present invention. In the upper left corner of this screenshot, there is a "Compose Mail" link 340 . The user clicks on this link and starts writing a new message. Adjacent to link 340 there is a text box 341 and a "Search Mail" button 342 . After the user submits one or more query terms via text box 341 and then clicks "Search Mail" button 342, the system generates a new display list dialog matching the query terms. In some embodiments, a match may occur due to the existence of one or more synonyms for the corresponding query term. In some embodiments, a match may occur based on the root of the corresponding query term. For example, a search for "book" might match the words "book," "books," and "booking." For details, refer to Figs. 7A and 7B. Adjacent to button 342 are two drop-down lists: a "More Actions" list 344 and an "Add Tag" list 345 . For more details about these two drop-down lists, please refer to Figures 4 and 5, respectively. Just below the "Compose Mail" link 340, there is a series of group boxes, each corresponding to the form generated by one of steps 214-220 in FIG. For example, group box 346 displays system-defined categories including "Inbox," "Starred," "Sent Mail," "Drafts," "All Mail," "Spam," and "Trash," among others. . In other embodiments, the system-defined set of categories may vary, including a subset of these categories and/or additional categories. In some embodiments, the "starred" category includes conversations in which the user plans to actively engage (eg, by sending messages to other participants), similar to a "To Do" list. Thus, in one embodiment, messages may be marked with a star so that a user may, for example, search for starred messages. In one embodiment, the "All Mail" category includes all conversations that are not in the "Spam" or "Trash" categories. Note that the corresponding link in group box 346 is highlighted since the current screenshot only shows conversations that fall under the "Inbox" category.

The main area of the schematic screenshot in FIG. 3B is a table that includes a list 360 of conversations, each conversation occupying a row in the table. Each row also includes a check box 362 , a list of senders 364 , a recipient status indicator 366 , a conversation title and excerpt 368 , and a date/time value 369 . In other embodiments, the set of fields for each dialog line may differ, including a subset of these fields and/or additional fields. In some embodiments, when displaying a list of conversations, all rows have a uniform height. In other embodiments, the height may be variable to accommodate different excerpt lengths. If the user decides to move the corresponding dialog from one system-defined category (for example, "Inbox") to another system-defined category (for example, "Trash"), or if the user decides to attach the corresponding dialog to User-defined tags are checked by the user in check box 362 . The definitions of other columns or fields in the table have been given above in conjunction with FIG. 3A . Note that there are two messages in the first dialog, and the sender S2 has been highlighted in the first line, which means that the message sent by S2 has not been read or marked as read. In contrast, the second conversation includes 4 messages that have all been read or have been marked as read, so nothing is highlighted in the second line. In some embodiments, a visual indicator for starred status is provided. If any messages in the conversation have a starred status, Inbox will provide a visual indicator that the conversation contains at least one starred message.

In one embodiment, although not yet depicted, the browser window represented by Figure 3B also includes a persistently displayed message composing area, associated addressing and subject fields, and other options typically associated with forms that allow composing and sending messages and fields. For example, such an area is displayed under the list 360 of conversations. Thus, in one embodiment, within a single user interface (e.g., a browser window), a user may have the option to view a list of conversations, and also compose a new message, without requiring a new window to open (e.g., a message composition window) , without removing the list of conversations from the current browser window.

FIG. 4A is a flowchart illustrating the operation of the "More Actions" drop-down list 344. As shown in FIG. After the user clicks on the drop-down list, at step 402, the browser displays a list of system-defined actions. In step 404, the user selects a specific action and at least one dialog in the dialog list in the drop-down list. Then, at step 406, the browser associates the user-selected dialog with the user-selected action, and returns them to the dialog management system at step 408 for further processing. In step 410, if the user-selected action results in the user-selected dialog being removed from the previously displayed list of dialogs, the dialog assistant receives a list of new dialogs from the dialog management system, and the dialog assistant displays the dialog's new list in the browser. list.

Referring to FIG. 4B, FIG. 4B depicts a schematic screenshot from FIG. 3B that is generated when the user checks the checkbox 413 of the second dialog, clicks on the "More Actions" drop-down list, and selects the item "Spam" 415 The change. As a result, the second conversation will be removed from the "Inbox" category, and the "Spam" category will have a new member. Note that some actions in the drop-down list, such as "ignore" and "snooze" do not have corresponding categories. "Ignore" and "Snooze" both correspond to the "All Mail" category. Specifically, when the user checks the dialog's checkbox and then clicks the "ignore" item, the dialog will be sent to the "All Mail" category. If any new message arrives related to the "ignored" conversation, the system still associates this new message with the conversation, but does not automatically bring the conversation back to the user's attention. However, a user can stop ignoring a conversation and turn it off by visiting the "All Mail" category, checking the checkbox for the dismissed conversation, and then selecting the "Inbox" item in the corresponding "More Actions" drop-down list. Brought back to the "inbox" category. As this example shows, drop-down lists of different categories can have different sets of action items. The "snooze" action item allows the user to temporarily ignore the conversation by setting a trigger, which can be time-driven, e.g., the conversation should disappear from the "Inbox" category for a period of time (e.g., an hour, a day, a week, etc. ), then automatically, or event-driven, for example, the conversation should not return to the "Inbox" category until the number of unchecked messages has reached a predetermined limit, or a specific person has contributed a message to the conversation , a message is received designating the user as the primary recipient, or the received message contains a specific word or phrase. One of ordinary skill in the art will recognize other trigger conditions that may also be used.

categorization dialogue

FIG. 5A is a flowchart illustrating the operation of the "Add Tag" drop-down list 345. As shown in FIG. After the user clicks the drop-down list, at step 502, the browser displays a list of user-defined tags for the user to select. In step 504, the user selects a specific label in the drop-down list and at least one conversation in the conversation list. Then, at step 506, the browser associates the user-selected dialog with the user-selected label, and sends them back to the dialog management system at step 508 for further processing. As a result, the list of conversations associated with the user-selected tag will include conversations associated with that tag in step 506 . As described in more detail below, when a tag or attribute is associated with a conversation, one or more entries are added to the index 1710 (FIGS. 17, 18) to enable searches of conversations bearing that tag to be located. In some embodiments, the tag or attribute is also added to one or more entries in dialog database 1808 (FIG. 18). In some embodiments, when a user views a conversation, tags associated with the conversation are displayed. In some embodiments, a label associated with each conversation in the list of conversations is displayed in a row of information provided for each conversation in the list.

FIG. 5B is a schematic screenshot depicting the browser window that results when the user checks the check box 512 of the second dialog, then clicks the "Add Tab" drop-down list, and selects the item "Tag 2" 514 . (Note that "Label 2" represents the user-specified label name). This will result in associating "Label 2" with the checked dialog. Accordingly, the examined conversation may be included in the search results generated in response to a query for messages related to "tag 2." In some embodiments, the tab associated with each dialog in the list of dialogs is displayed in the corresponding row of the table, so "Tag 2" will be displayed in the line of the relevant dialog. Of course, those of ordinary skill in the art will appreciate that the user can enter customized tag names and/or the system can provide pre-defined tags.

view conversation

FIG. 6A is a flow chart illustrating how the dialog assistant generates a dialog view in response to a display command from the dialog management system. In some embodiments, some of the actions shown in FIG. 6A are performed by the dialog management system before the dialog information is sent to the dialog assistant in the client, e.g., for formatting the dialog information for display. action.

In step 602, the dialog assistant first receives a series of messages belonging to a specific dialog, and a set of related display instructions. At step 604, the dialog assistant identifies the title of the dialog, as well as any system-defined categories and user-defined tags associated with the dialog. From these categories and tags, the dialog generates a list of user-selectable actions and a list of user-selectable tags, respectively. These two lists are similar to the two drop-down lists 344 and 345 shown in Figure 3B. In one embodiment, the list of user-selectable actions includes only actions applicable to a specific dialog (ie, the dialog to be displayed). Therefore, it is not possible to associate a dialog already in the "Trash" category with the "Trash" category again. For the same reason, the list of user-selectable tags only includes tags that have not been associated with a specific conversation.

Starting from step 608, the dialog assistant generates a subtable for each message in the dialog, and the subtable includes at least a detailed message header and a message body. As used herein, a message body refers to a user-created message, including subject references, excluding any system information added to the message by message processing software. Each detail message header includes the sender's name and/or address and all primary and secondary recipients, the subject of the message, a set of message-level actions, and a date/time value. One of the actions at the message level includes an option to view the message in its original format, which includes routing information and other information provided by the messaging system, such as "My Version:", "Content Type", etc. At step 610, the dialog assistant also creates a brief message header from the detailed message header. The brief message header includes sender and receiver identifiers. In some embodiments, recipients are excluded from the brief message header. If the user is in the recipient list, then at step 610 the dialog assistant uses a unique character string or icon as the user's identifier, similar to the user's identifier in the sender list. For example, the pronoun "me" in English can be used to refer to a user in a brief message header. If the message is the first message that identifies a specific recipient in this conversation (i.e., in the primary or secondary recipient field of the message header), the dialog assistant will highlight the recipient's name in the brief message header at step 614. identifier. On the other hand, in some embodiments, when a recipient previously included in the list of recipients is no longer included, the dialog assistant will display the recipient in a visually distinct manner, such as in a "ghost" font. the identifier of the recipient. In other embodiments, the brief message header includes a sender identifier, message parts, and a date/time representation of the message.

Next, at step 616, the dialog agent decides how to display the subform. If the message associated with the subform has not been viewed by the user or has not been marked as read by the user, the subform is displayed in an expanded mode at step 618, i.e. both the brief message header and the complete message are displayed body. If the message has been viewed or marked as read, then at step 620, the subtable is displayed by default in a compressed mode, including only a brief message header and a portion of the message body (eg, the first few lines of the message). Next, the user can expand the compressed subtable by clicking on it. Similarly, the subtable does not describe the detailed message header, but includes an option for the user to select, ie, if the user wishes to view the detailed message header, this option is selected at step 622 . Finally, at step 624, the dialog assistant creates a set of answer options at the bottom of the subform, such as "Answer," "Answer All," and "Forward." In some embodiments, a subset of the actions described above are performed for each message in the conversation. In some embodiments, one or more additional formatting actions are performed.

Figure 6B is a schematic screenshot of the second dialog in Figure 3B, according to one embodiment of the present invention. The top and left of this screenshot are the same as the top and left of Figure 3B. But the list 360 of conversations has been replaced by the list 640 of messages. At the top of the list of messages is the title of the conversation "Title 2" 630 , all user-defined tags 632 related to the conversation, and an "Expand All Messages" button 634 . Since the user has viewed these 4 messages and marked them as read, the first 3 messages in the list are displayed in compressed mode, and the last (and newest) message is displayed in expanded mode. In some embodiments, messages that have been marked as read may also be displayed in an expanded mode when there are no unread messages (i.e., not yet viewed or marked by the user as read). Messages in starred conversations. This provides a visual that brings together all the messages in the conversation. Each compressed subtable shows a brief message header 641 and an excerpt 643 such as the first few words of the message body. In some embodiments, the senders in the brief message header are color-coded so that each sender's textual representation can be presented in a different color. This helps to distinguish senders in the displayed dialog. In some embodiments, colors are generated by the system until the system runs out of colors associated with the sender. In some embodiments, a color is associated with each conversation, such that the same sender may have different colors associated with it, depending on the conversation being displayed. Note that all recipients are highlighted in the brief message header 641 since this is the first message of the conversation. In contrast, only one identifier "S1" is highlighted in the second compressed subtable because this is the first message where S1 is a participant in the conversation. The expanded subtable includes the full message body 645 , a "more options" link 647 which when selected will cause the detailed message headers to be displayed, and a list of answer options 649 . Since S4 sent the last message, one of the answer options is "Answer S4", which reminds the user that there will be an answer to S4.

In some embodiments, when the number of messages in a conversation exceeds a threshold (e.g., 8 or 10 messages), and multiple consecutive messages in the conversation will be displayed in a compressed subtable (e.g., received from the conversation When messages marked as read in the conversation selected by the inbox list are displayed), these messages are displayed in a second compressed subtable that does not include text, so that there is no list of senders and no excerpts. Instead, the second compressed subtable represents each of these messages as a small line. The visual effect is that these subtables appear like the edges of the cards in a stack. In some embodiments, the first and last messages in the conversation are never displayed in the second compressed subtable, and more generally certain messages, such as those with " Starred" tagged messages. The use of a second compressed subtable facilitates viewing of conversations with a large number of messages. The method can be used to represent messages in a conversation that match a user-specified search query, where the conversation has more than a threshold number of messages. In this case, the messages represented by the second compressed sub-table are consecutive groups of messages that do not match the search query.

FIG. 6C is a schematic screenshot similar to the schematic screenshot in FIG. 6B, except that (1) after the user clicks on the first subtable 650, the subtable is displayed in expanded mode, and (2) the last subtable The form includes a detailed message header 660, and (3) a message answer form 670 is attached to the final subform after the user clicks on the "Answer S4" link. In one embodiment, while the user is viewing the content of the conversation, a text box for answering a certain message (eg, the last message) may be continuously displayed, ie, displayed in association with the message. In other words, the message answer form 670 is displayed and its associated answer text box is accessible to the user without requiring the user to click on the "Answer S4" link. In other embodiments, the message answer form may be persistently displayed for all messages in the conversation, or for all messages displayed in expanded mode.

Structurally, the first extended subtable 650 is the same as the last subtable shown in FIG. 6B. It includes a brief message header, a "more options" link, a message body, and a set of answer options at the bottom of the subtable. In addition to the email addresses or other identifiers of the message sender and recipient, the detailed message header 660 also includes a list of actions that the user can take. For example, "Trash this message" action 661 allows the user to remove the message from the conversation. As a default, the message reply form 670 includes only S4's address in the "To:" field, since the sender of the message to which the user is replying is S4. However, the message answer form also provides the user with additional options (eg, "Add Cc", "Add Bcc") if the user wishes to send the reply message to more recipients. The message reply form 670 also allows the user to edit the subject of the original message and attach documents to the reply message.

FIG. 6D is a schematic screenshot of the dialog shown in FIG. 6B after the user has clicked the "Expand All Messages" button 634 . As a result, all 4 messages 608 are displayed in expanded mode. Note that the text in button 634 changes to "Compress All Messages". After the user clicks button 634 again, the display of the dialog returns to the format shown in FIG. 6B.

Figure 6E is a schematic screenshot of a dialog illustrating some of the features previously described. In particular, FIG. 6E illustrates an example of the second compression subtable used at 682 when the number of messages in a conversation exceeds a threshold. Although the user cannot see any header information for these messages, the user can still see how many messages are in this second compressed sub-table. In some embodiments, in the compressed subtable describing the brief message header as illustrated in brief message headers 684 and 686, messages on both ends of the message in the second compressed subtable are described. In some embodiments, and as shown in Figure 6E, the brief message header includes the sender, message parts, and date/time values of the message, without describing other recipients of the message. An example of the "starred" property can be seen at message 688 . The asterisk in message 688 differs from other messages in that its asterisk is filled in, which indicates that this message has a starred status, while other messages do not have such a status. Of course, any visual indicator that provides a differentiated status can be used, and the concept is not limited to "stars" and whether they are "filled in". As described above, in one embodiment, when a dialog is displayed and there are no unread messages (as shown in Figure 6E), messages with a starred status are displayed in expanded mode. In another embodiment, if there are messages that have not been read or have not been viewed, the starred messages 688, such as those at 682, will be displayed in the compressed subtable but not in the second compressed subtable information. Other embodiments contemplate different permutations, such as always seeing starred messages in extended mode, regardless of whether there are any messages that have not been read or viewed.

Use queries to locate, list, and display conversations

As mentioned above, a user can search for conversations that match a user-specified query. The dialog management system 102 and the dialog assistant 110 work cooperatively to generate search results corresponding to the query and present the results to the user in a very intuitive manner. FIG. 7A is a flowchart illustrating how the dialog assistant 110 generates various forms for displaying dialogs matching the user's search request. In some embodiments, certain actions shown in Figure 7A are performed by the dialog management system prior to sending the dialog information to the dialog assistant in the client, such as actions for formatting the dialog information to be displayed.

At step 702 , dialog assistant 110 receives from dialog management system 102 information representing a plurality of dialogs matching a search query (which may include one or more query terms) and related display instructions. At step 704, dialog assistant 110 generates a table for holding a list of dialogs, each dialog occupying a row in the table. For each row in the table, at step 706 the dialog assistant 110 also generates a snippet containing matching query terms. In some embodiments, dialog assistant 110 also highlights snippet items that match any of the query items in the search query. At step 710, a list of conversations is displayed. Fig. 7B is a schematic screenshot of a list of dialogs generated according to these steps. In some embodiments, a user may specify user preferences that cause generation and/or display of snippets to be suppressed. In some embodiments, when text matching a search query is placed in a header or other information of a message, the excerpt is provided as the first part of the message.

In some embodiments, if the user selects (e.g., clicks) a row representing a dialog in the dialog list (e.g., the row in the dialog list shown in FIG. 7B) (step 712), then in step 714, the dialog assistant 110 Display the selected dialog. To do this, the dialog helper generates a series of subtables containing a list of messages related to the selected dialog. Specifically, if a selected conversation is selected from a list of conversations generated in response to a user-specified search query, those subtables whose associated messages do not contain any query items in the search query are displayed in compressed mode, while pressing Extended mode displays those subtables whose associated messages include at least one query item. The dialog assistant 110 also highlights matching query terms in the message body. A display example of a selected dialog matching a specified query is depicted as a schematic screenshot in Figure 7C. If the selected conversation is selected from the conversation's category list, eg, from the conversation's inbox list, messages are initially displayed as described above for FIG. 6C.

FIG. 7B is a schematic screenshot of a browser window listing three dialogs 730 that match the query term "Tahoe" 720 . Above the three dialogs 730 is a "Search Options" link 732 . Users can click on this link to modify the options for conducting a search. For example, a user may specify whether to limit the search to conversations in one category, or to conversations in all categories. When the listed dialogs belong to two or more different categories, none of the categories in group box 346 are highlighted. In each matching conversation, the excerpt containing the item "Tahoe" is identified and displayed with the word "Tahoe" highlighted. These excerpts state: 3 conversations covering 3 different titles, namely the first conversation is about a ski trip at Lake Tahoe, the second conversation is about a Tahoe model SUV, and the third conversation is about a camping location in the Tahoe National Forest . Thus, the user can use the information in the snippet to decide which specific conversation they wish to open.

Fig. 7C is an exemplary screenshot showing all messages in the third dialog after the user clicks on it. Note that the "All Mail" category has been highlighted in this screen shot (in group box 346), indicating that the third dialog is currently positioned in the "All Mail" category. Since the second message includes the query term "Tahoe," the second subtable is displayed in expanded mode, with the word "Tahoe" highlighted.

Spell Check

Figure 8 is a flowchart illustrating how the dialog assistant interacts with the user to correct possible misspelled words in a message composed by the user. After composing the message and before sending it out, the user can click on the "More Actions" drop-down list and select the "Spell Check" item. Note that this item is not shown in Figure 4B because the drop-down list therein only includes dialog-level actions. "Spell Check" is a message-level action that only appears in the drop-down action list when a form is being written with a message. In response to user selection of the "spell check" action, the dialog assistant sends the composed message to the dialog management system, and then receives a spell-checked copy of the composed message and display instructions at step 802 . In alternative embodiments, the actions performed by the dialog management system described herein in relation to the spell checker are performed by a dialog assistant or by a local client application using a local dictionary. According to the display instruction, the dialog assistant highlights each possible misspelled word in the message at step 804, associates each highlighted word with a list of candidate words generated by the system at step 806, and at step 808, independently A reformatted message is displayed in the browser window of the . When the user selects a specific highlighted word in the browse window, the dialog assistant locates the user-selected word in the spelling correction window, and at step 810, attaches a list of candidate replacements near the window (it should be noted Note that replacement items can consist of one or more words). The dialog assistant then modifies the misspelled word in the spelling correction window at step 812 using the user-specified replacement item in the candidate list. The dialog assistant can also expand the spelling correction window in a direction specified by the user at step 814, so that the user can correct more than one word in the spelling correction window at step 816.

Figure 9A is a screenshot illustrating the same dialog as that shown in Figure 6C, except that the user has composed a reply message 817 to S4. Before sending the message, the user decides to spell check it. Therefore, the user clicks on the "More Actions" drop-down list and then selects the "Spell Check" item 818 . In response, the dialog assistant sends the composed message to the dialog management system, and then displays the spell check results in a separate browser window. In some embodiments, the spell check results are displayed in the same window as the window in which the user is composing the message. In fact, the display remains largely the same, except for the toggling of certain spell-checker-related features, and the highlighting of possible misspelled words. This embodiment has the added benefit that when composing a message, the user can perform spell checking in the equivalent visual context provided to the user, rather than presenting the user with a separate new window that does not have such a context.

Figure 9B depicts a screen shot including 3 separate browser windows at different stages of the spell checking process. The first window 820 includes a spell-checked copy of the message. Specifically, 3 potentially misspelled words 821, 823 and 825 have been highlighted in this window. After the user clicks on the second word 823, the word "delying" is next incorporated into a spelling correction window 832 as shown in the second browsing window 830. Additionally, a list 834 of candidate words generated by the system is displayed below or adjacent to the spelling correction window. Then, the user selects a third replacement item "delaying" to replace the misspelled item "delaying". If the user wishes to add the word "temporarily" before the corrected word "delaying", then the user can click on the left arrow 841 as shown in the third window 840, and the browser window pointer is positioned at before the misspelling item "delaying". location, and then enter the word "temporarily". Finally, after correcting all misspelled words, the user clicks on the "Done" button 845, which will result in the message being sent at S4.

dialog server

10-19 help describe the previously described embodiment of the dialog server 102 . FIG. 10 illustrates one embodiment of a dialog server 102. As shown in FIG. Dialog server 102 includes dialog engine 1002 , modifier engine 1004 , message index 1006 , query engine 1008 , message database 1010 , one or more auxiliary service servers 1012 , spell checker 1014 , and SMTP 1016 .

Dialog engine 1002 processes requests from and replies to dialog assistant 110 via its connection to communication network 106 . Communication network 106 may include the Internet, one or more local area networks (LANs), one or more wide area networks (WANs), other types of networks, or a combination of such networks. The dialog engine is also connected to various auxiliary services, such as auxiliary services server 1012 and spell checker 1014 . Query engine 1008 is connected to dialog engine 1002 , message index 1006 and message database 1010 . Modifier engine 1004 is connected between dialog engine 1002 and message index 1006 and message database 1010 . An SMTP gateway 1016 is connected between the dialogue engine 1002 and the communication network 106 . Although Figure 10 depicts the dialog server 102 as a plurality of discrete projects, this figure is more intended to be a functional description of the various features that can be delivered in the dialog server 102 than to the embodiments described herein. Structural hints. In fact, independently described items may be combined and certain items may be separated, as will be appreciated by those of ordinary skill in the art. For example, some items independently described in the figure may be implemented on a single server, or a single item may be implemented on one or more servers. The actual number of servers in session server 102, and how features are distributed among them, will vary from implementation to implementation, and may depend in part on the e-mail throughput the system must handle during peak usage as well as during average usage.

As mentioned briefly above, dialog engine 1002 may respond to various requests from dialog assistant 110 related to messages and return dialog-based replies via its connection to communication network 106 . Although the SMTP gateway 1016 can also be connected to the communication network 106, the SMTP gateway 1016 can also be more directly involved in the receiving and sending of messages. For example, in some embodiments, SMTP gateway 1016 transmits and receives messages using the Simple Mail Transfer Protocol (SMIP). SMTP gateway 1016 can receive new messages from communication network 106 and send the messages to dialog engine 1002 for additional processing. In addition, SMTP gateway 1016 receives messages from session server 1002 and then transmits these messages (via communication network 106) to the recipient address specified in the message.

Dialogue engine 1002 may also handle requests to spell check messages that may be being composed. Dialogue engine 1002 sends portions of text to be checked to spell checker 1014 for spell checking. Spell checker 1014 returns corresponding information, including identification of text identified as potentially incorrectly spelled. In some embodiments, spell checker 1014 provides information about making suggestions for text identified as potentially incorrectly spelled. In some embodiments, this information is sent to dialog assistant 110 for subsequent processing.

One or more auxiliary service servers 1012 provide additional services to the dialog engine 1002 . In some embodiments, auxiliary services server 1012 includes a spam detection module. In the following, the operation of the spam detection module is discussed with reference to FIG. 11 . In some embodiments, auxiliary services server 1012 includes an attachment management module that manages the efficient storage and retrieval of files attached to email messages.

Figure 11 describes an embodiment for processing received messages. A message is received, assigned to a dialog, indexed, assigned one or more attributes, and stored. For example, the message may initially be received by the SMTP gateway 1016, where certain processing and manipulation may take place, and then may be passed on to the dialog engine 1002 (stage 1102). Dialogue engine 1002 can generate a message identifier for the message. Message identifiers can be used to distinguish messages from each other. In an embodiment, the identifier is an N-bit number consisting of one or more parts. For example, in an embodiment, the message identifier may be a 64-bit number consisting of a hash of Y bits (e.g., 32 bits or 48 bits) of the timestamp and 64-Y bits of the message content ( hash) composition. A hash is a mathematical function that maps values from a large domain to a smaller domain. Those of ordinary skill in the art will appreciate that there are many different methods of creating message identifiers that provide sufficient information to distinguish messages from one another.

Dialogue engine 1002 may then parse the message into its constituent components (stage 1104). These components may include the sender's address, one or more recipient addresses, the subject of the message, a "Reference:" field, as previously described in RFC 2822 (April 2001), RFC 2822 also The "In-Reply-To:" field describing, the content of the message, or any other information that may be included in the message. After receiving the message, before or after parsing the message, the message is passed to the spam checking module (stage 1105) to determine whether the message matches the spam criteria. In some embodiments, each spam checking module runs asynchronously and in parallel with other processing of messages. In some embodiments, spam criteria are designed to determine whether a message is likely to be an unsolicited message that a user may not wish to read.

The parsed message is added to the message database (stage 1106). In one embodiment, the message is added to the message database without subsequent modification, except possibly for deletion.

Some or all of the components of the message extracted during message parsing are used to aid in the determination of the conversation (if such a conversation exists) to which the received message belongs (stage 1108). For example, the subject of a message can be compared to other messages with the same subject, since it is likely that the messages in the conversation will have the same, or nearly the same subject. If no matching conversation has been found, the message is associated with a new conversation.

After conversation correlation has been made, the messages are indexed for searching (stage 1110). In one embodiment, the entire text of the message and portions of the header information are indexed. In some embodiments, "noise words" (such as "the", "a", and "or") in the message body are not indexed, but the message's All other text in the relevant section is indexed. Those of ordinary skill in the art will recognize that those portions of the message that are searchable should be indexed. As mentioned below, in some embodiments, information related to attributes associated with the message is added to the index at a later stage of message processing.

Next, an initial set of attributes is assigned to the message (stage 1112). For example, these types of attributes may include tagging a received message as "unread" (which generally means that the message has not been viewed, or marked as read), to indicate that the message is new. In addition to messages sent by users, another attribute originally assigned to messages is the "inbox" attribute. Another set of attributes initially assigned to each message are user-defined attributes related to other messages (if any) in the same conversation. User-defined attributes related to other messages in the conversation are determined by searching the conversation database described below with reference to FIG. 18 . Initially other attributes may also be assigned to the message. Attributes associated with a message can be used to search the message database for messages with similar attributes. For example, a search may be performed to search for all messages marked as "unread". In addition, the attributes of the dialog may also be added to the message, since, in one embodiment, the message inherits the attributes of its dialog.

In some embodiments, message-related attributes may include attributes associated with individual messages in a conversation, but not necessarily with all messages. For example, a "mark for deletion" attribute (also sometimes referred to as a "trash" attribute) may be associated with a single message in a conversation, but not with other messages in the same conversation. Messages marked for deletion are also stored by the system and are also associated with a conversation, but they are usually not displayed when the corresponding conversation is displayed. Use one or more specific views to enable the user to view messages with the attribute "marked for deletion". Such a view provides the user with the opportunity to "don't delete" the message. On the other hand, in some embodiments, when associating a user-defined tag with a conversation, the tag is associated with all messages in the conversation. In certain other embodiments, when associating a user-defined label with a conversation, the label is associated with all messages in the conversation that satisfy predefined criteria (e.g., messages other than those marked for deletion) Associated.

Next, the user-defined filters that the user has established are applied to the message (stage 1114). Each user-defined filter consists of a set of filter conditions and a set of actions. Filter conditions define which messages match the filter, and actions include actions that specify tags to be added to or removed from messages. Filter criteria may include criteria related to sender, recipient, text in message subject, text in message, and the like. In some embodiments, actions may include "remove from inbox" (i.e., remove the inbox label from the message, if present), add a system label (sometimes called a category) to the message, and add a User-defined tags. For example, a filter could specify that all messages with a particular item or combination of items should be marked with the "Trash" label. Another filter may specify that if the item "Lake Tahoe" occurs anywhere in the message, then add a "holiday" tag to the message.

Note that in some embodiments, stages 1112 and 1114 involve assigning labels to messages being processed. While executing or preparing to execute stages 1112 and 1114, the results from the spam checking module are retrieved (stage 1105). If the spam checking module classifies the message as spam, the "spam" label is assigned to the message, and any conflicting labels (eg, "inbox" or "trash") are removed from the message.

After the set of labels assigned to the message has been established, the indexes and certain tables in the dialog engine 1002 are modified (stage 1116) to reflect the set of labels assigned to the message. The index is modified by adding information indicating which message to assign the label to. As a result, an indexed search on each of these tags will produce a list of messages including the current message being processed. Additionally, at least one table or database in the dialog engine is modified to represent the set of tags assigned to the current message being processed. Hereinafter, this point will be described with reference to FIG. 18 .

Finally, an acknowledgment may be sent to the sender of the message (stage 1118). In some embodiments, an acknowledgment may be sent, while in other embodiments, no acknowledgment may be sent.

Although FIG. 11 depicts these stages in a particular order, it is not intended to unduly limit the order of these stages. In other embodiments, the stages may be ordered differently. For example, stage 1114 may be followed by stage 1110 by adding messages to the message database before indexing them. Those of ordinary skill in the art will recognize various ways of reordering these stages.

Associate each message with a conversation

Referring to Figure 12, the following is a more detailed description of how messages can be matched to dialogs (stage 1106). After the message has been parsed (stage 1104 of Figure 11), the parts of the constituents can be used to formulate search queries for candidate conversations (step 1202). For example, conversations may be correlated based on time information, sender information, subject information, other information in headers, or system-provided information, or any combination thereof. One embodiment formulates search queries using topics of messages with "Reference:" and/or "In-Reply-To:" fields. Other embodiments include searching for senders or recipients of messages in a query. Those of ordinary skill in the art will recognize many different search queries for generating messages that may be related to the current message.

A search query is applied against previously stored messages, and candidate messages are received (stage 1204). Messages or information about messages are checked to determine which messages, if any, best match the current message (stage 1206). The conversation the message belongs to is most likely the conversation the current message belongs to. A number of different schemes can be used to determine which conversation the current message belongs to. One scheme could use the subject of the current message. Messages with the same subject are likely to belong to the same conversation. Therefore, queries that use the topic of the current message can be planned. For example, if an incoming message has the subject "Where should we go for lunch today?", it is possible that the conversation to which the current message belongs (if one exists) includes one or more messages with the same subject. When comparing subjects, it may be desirable to regularize the subjects before making the comparison. In some embodiments, normalizing the subject includes removing prefixes, such as "Re:" and "Fwd:", which are typically added to the subject by some systems.

However, it may be that one wishes to examine more than just topics. If two messages have the same subject, but one of them is received long before the other, they are probably not part of the same conversation. For example, if two messages with the subject "Where should we go for lunch today?" are received a month apart, they are unlikely to be part of the same conversation. Therefore, in one embodiment of the invention, it may be desirable to check the date/time value of the current message and the message from the candidate dialog if the normalized subject of the message matches.

Other factors may be considered when matching messages to conversations, such as recipients, portions of message content, sender's domain address, or other factors. Those of ordinary skill in the art will appreciate that there are many different ways to determine the conversation to which a new message belongs. Once the current message is matched with a satisfactory matching message, the conversation related to the matching message can be associated with the current message (stage 1206). On the other hand, if no satisfactory matching message is found (thus, no dialog), then a new dialog identifier is associated with the message (stage 1206).

In some embodiments, a conversation identifier may be created from an initial message received in a conversation. For example, the message identifier of the original message provided by the system (provided by the transmitting or receiving system) may be used as the session identifier. Successive messages are then associated with the message identifier currently used as the conversation identifier. Those of ordinary skill in the art will recognize the various characteristics of the initial message that may be used to provide the dialog identifier. In some embodiments, these properties should provide good support that the value is unique to the initial message so that multiple conversations will not be assigned the same conversation identifier.

As previously mentioned, after associating the current message with a dialog (pre-existing or newly created) (stage 1106), initial attributes are added (stage 1108). One embodiment for adding these initial attributes (stage 1108 ) can be better understood with reference to FIG. 13 . Initially, the sender of the message can be checked. If the sender of the current message is not the user for whom this message processing is being performed, it is likely that the current message has already been sent to the user by someone else. Thus, if it is determined at stage 1302 that the sender of the current message is not the user, an initial attribute of "inbox" (also called an inbox label) may be associated with the current message (stage 1304). The "Inbox" attribute can be used to identify those messages that have been sent to this user. For example, in some embodiments, a search for messages with an "inbox" attribute is used in the generation of the user's inbox view.

In this document, the terms "attribute" and "tag" are used interchangeably. Additionally, "assocating" a specific attribute with a message, and "marking" a message with a specific attribute or tag are considered to be the same or equivalent operations.

Since the current message is likely new, it is also likely that the user has not viewed this message before. Accordingly, the "not read" attribute so indicated may be associated with the current message (stage 1306). Those of ordinary skill in the art will appreciate that message attributes can be implemented in a variety of ways that achieve the same result. For example, a predefined value could represent "Inbox". It is sufficient that a message having a desired attribute can be searched based on these attributes. Other attributes may also be associated with the message. Attributes can be considered in many forms, although the ability to search for specific attributes is more important than distinctions. Attributes can include system-defined attributes such as Inbox, Trash, Junk, All Documents, and Not Read. In some embodiments, certain system properties may be mutually exclusive (eg, Inbox, Trash, and Junk). Attributes can also include user-defined attributes, which are sometimes referred to here as categories.

If the user is the sender of the message being processed (as determined at stage 1302), or after adding any applicable system attributes to the message, for example, after adding "not read" (stage 1306) Afterwards, additional attributes belonging to the dialog are added to the message (stage 1307).

Certain filter conditions may be checked and applied against incoming messages (stage 1308). In an embodiment, a user may establish a filter that applies attributes to received messages when predetermined conditions are met. In another embodiment, the system may apply one or more predefined filters to received messages.

If the current message matches the filter criteria, attributes may next be applied to the message according to the filter (stage 1310). In one embodiment, the system provides a tool that enables the user to create filters so that certain messages are not placed in the "Inbox". In other words, the filter will cause the "inbox" attribute to be removed from the message. In another embodiment, the current message may be associated with a particular user-defined attribute, such as a tag indicating an area of interest to that user to which one or more conversations may be associated. For example, an incoming message could be associated with a conversation with the tag "food," which would then associate the "food" tag with the current message. In general, messages inherit the tags of the conversation that the message is associated with. Since multiple filters can be applied to received messages, newly received messages and their associated conversations can be associated with more than one user-defined tag.

In another embodiment, a user can associate a doze condition with a conversation. In some embodiments, the doze condition is only associated with a dialog when the user specifically commands the system to do so. In some embodiments, a doze condition is associated with a conversation when a filter matches a message in the conversation. A doze condition specifies certain actions to be performed when a new message is received in a dialog to which a doze condition has been applied. For example, a snooze condition can prevent the system from associating an inbox label with a new message in a conversation. More specifically, a user can associate a snooze condition with a conversation (either directly, or through the action of a filter), thereby preventing new messages in the conversation from being placed in the user's inbox unless certain Triggering conditions. One such trigger could be an incoming message directed directly to the user (as the only primary recipient). Another such trigger condition may be the lapse of a period of time selected by the user or the system. Still other triggers may be received messages containing specified words or phrases. In this case, when a message is received that satisfies the snooze condition, the snooze condition is removed from the conversation, and the incoming message is marked with an "inbox" label. In some embodiments, additional actions are taken, such as adding an "Inbox" label to other messages in the conversation. In another embodiment, all messages in the conversation with the "Unread" label are marked with the "Inbox" label. So a search of "Inbox" will return that conversation. In some embodiments, a snooze condition is associated with a conversation by generating a snooze filter, thereby exempting new messages associated with the conversation from being tagged with an "inbox" label until a predefined event or condition, after which, delete or modify the doze filter.

Another type of filter that can be applied to incoming messages is the "spam" filter, which identifies unwanted messages and marks them with the "spam" tag (i.e., combining the "spam" attribute with the Such messages are associated).

Figure 14 illustrates one embodiment for modifying attributes of a dialog. Attributes of a dialog may be modified when the dialog, or incoming messages associated with the dialog, match filter criteria. Attributes of a dialog can also be modified when the user indicates that the dialog should have specific user-defined attributes. For example, a user may specify that a particular conversation should be associated with the "food" category. In this case, the conversation (and its respective message) is tagged with the "food" attribute for association with the "food" attribute. Users can also designate conversations to mark for deletion.

In some ways, user-defined attributes are conceptually comparable to folders. However, embodiments of the invention allow for associating a dialog with a number of user-defined attributes. In some embodiments, when a new attribute is associated with a conversation, all messages in the conversation are marked with the new attribute.

Referring to Figure 14, when a given attribute of a dialog is to be modified, a search is planned (stage 1402) to locate the dialog (stage 1404). After the dialog is discovered (stage 1404), the properties of the dialog can be modified (stage 1406). The specific mechanism for completing stages 1402, 1404, and 1406 depends on the mechanism used to associate attributes with dialogs. In some embodiments, attributes are associated with conversations on a conversation basis. For example, a dialog engine may maintain a list of attributes associated with each particular dialog. Alternatively, or in addition, the dialog engine may maintain an index that maps each defined attribute to all dialogs tagged with that attribute. Alternatively, in some embodiments, attributes associated with a dialog are associated with each message in the dialog. In such an embodiment, the dialog engine may maintain an index mapping each defined attribute to all messages tagged with that attribute, and may also maintain a table mapping each message to the dialog associated with that message or other institutions.

In contrast to messages, many features of the invention use dialogs as the basic unit of information. For example, Inbox submits a list of conversations to the user. Certain features of the invention use search to identify conversations listed in multiple different conversation views in a user's email account. In the following, searching for conversations and generating representations of identified conversations will be described with reference to FIG. 15 . Initially, a search query is received (stage 1502). The search query can be user-specified, or system-generated (eg, in response to the user clicking the "inbox" icon). Search queries can be based on a variety of factors. Search terms in a search query can come from the user in terms of words or combinations of words. For example, a user can search for messages that contain the words "bagel" and "cheap," and if a related conversation exists, it will be returned. The system may generate search queries in response to certain user actions. For example, if the user desires an inbox view, the system-generated search query may search for conversations with the attribute "inbox".

Any combination of searchable items can be used in a search query. As mentioned above, searchable items may include: the text of the message; any attributes related to the message, conversation; or header information associated with the message. In one embodiment, applying a search query to the database of messages will return a set of messages (stage 1504). Referring briefly to FIG. 10 , this can be accomplished by sending a search query to query engine 1008 , for example. A query engine 1008 can apply a search query to the message index 1006, which can return a list of messages. This list of messages may be received at stage 1 504 . Other embodiments may return the list of messages in a number of different ways, including returning a set of message identifiers, document identifiers, all or part of the messages, or any combination thereof, if desired.

In some embodiments, the search is performed on the conversation as a whole, rather than on individual messages. Thus, when a query contains first and second query items, one of which is found in the first message and the other is found in the second message of the same conversation, the conversation will be considered as related to the The query is associated and thus included in the search results. For example, consider a conversation in which the first message requests ideas for lunch places and a follow-up message, specifying a specific restaurant, does not include the text of the original message. If the user is interested in finding conversations in which a particular restaurant and lunch are discussed, the search is more likely to yield the desired results if this search is applied against the text of the entire conversation as if there were no message boundaries in the conversation.

The dialog is associated with the set of messages returned at stage 1504. Related conversations can be identified in a number of ways. When a message is selected from the set of messages returned at step 1504 (stage 1506), the dialog to which the message belongs is identified (step 1508). In one embodiment, a data structure can be maintained that matches each message to a conversation. If such a data structure is maintained, inspection of data structure entries associated with specific message identifiers can identify the conversation to which the message belongs. As a result set, the number of dialogs returned can be limited to a predefined number. If this restriction is made, processing of the group of messages continues until a sufficient number of conversations are identified, and a result is returned. On the other hand, all conversations associated with the returned group of messages may be identified, but only a subset returned.

Once the list of dialogs is created by identifying the dialogs to which all or part of the returned results belong (stage 1510), the dialog information is formatted for return to the requester (stage 1512). Formatting stage 1512 may format a number of different types of information associated with the identified dialog, the details of which will vary from embodiment to embodiment. In some embodiments, the formatting information is of a type recognizable by the dialog assistant 110 for submitting the dialog information to the user.

In some embodiments, the conversations in the conversation list generated at stage 1510 are sorted according to a date/time value assigned to each conversation according to a predefined rule or set of rules. As explained above, in some embodiments, each conversation in the conversation list is assigned a date/time equal to the date/time of the most recent message matching the search criteria used to generate the conversation list, and based on these Date/time value assigned to sort the conversations in the conversation list (eg, in reverse chronological order). Those of ordinary skill in the art will appreciate that there are various other methods of ordering and presenting conversations in the conversation list.

In some embodiments, the formatted conversation data representing the list of conversations (generated at stage 1512) includes statistics on the number of messages contained in each conversation in the conversation list. In some embodiments, message statistics for each conversation are displayed by conversation assistant 110 to indicate to the user how many messages are included in the conversation.

In one embodiment, for each conversation in the list of conversations, a brief conversation header is created (eg, during stage 1512 ), which may identify the list of senders of the messages in the conversation. This list may include all senders or a subset of senders in the conversation. In some embodiments, the list of senders is formatted to visually distinguish those senders who have sent messages (in conversation) that are currently marked as "unread" by the user. In another embodiment, dialog assistant 110 submits these senders in a different format than other senders. For example, you can use bold or highlighted text to identify the sender of an "unread" message.

In another embodiment, the list of senders of the message (in the Brief Conversation header) may be processed by replacing the user's name or address with a self-referential identifier. As a result, a self-referential identifier (eg, "me") is displayed when displaying a list of senders of a conversation rather than displaying the names or other identifying information of users similar to the senders who are not the user. Other types of self-referential identifiers may also be used to distinguish the viewing user from other users.

In another embodiment, the brief conversation header of each message in the list of conversations may include information indicating how the user received the message. In other words, this information can specifically identify how to send messages to users. For example, a message may be sent directly to a user, a user may be copied for a message, a user may be blind copied for a message, or the user may be made part of a distribution list to which the message is sent. One or more of these different ways in which the user may receive messages may be indicated to the user. For example, if you are sending a message directly to the user, you can use a figurative representation (such as ">") to indicate when the conversation is presented to the user.

In some embodiments, the Brief Information header of each message in the list of conversations includes an excerpt of the conversation's content, which includes information for displaying text matching the search term in bold, and also includes text in normal font. Formatted text surrounding the matched text. When generating a list of conversations for an inbox or other system domain, the snippet includes text from conversations selected according to predefined criteria. In some embodiments, the snippet includes text from the beginning of the most recent message in the conversation, while in another embodiment, the snippet includes automatically selected text indicating the content of the conversation.

In another embodiment, when a user chooses to view a specific conversation from among conversations that match a search query, the conversation engine may generate a message indicating which messages in the conversation match the query and which messages do not match the query. conversation information. Conversation information may also include a portion of the text of messages that match the search query. This dialog information can be formatted for display to the user. The dialog information may include formatted matching messages for display in expanded mode and formatted non-matching messages for display in compressed mode. Various types of information may be presented to the user in an expanded mode, including any combination of all or some of the following: header information, content information, text matching a search query, and text surrounding the search query. In some embodiments, when one or more messages matching a search query are displayed in condensed mode (e.g., in response to user selection of a "compress all messages" button or option), targeting such messages in condensed mode The displayed information includes an excerpt of the message content that includes information to display text matching the query term in bold, and also includes text surrounding the matching text formatted in normal font.

In yet another embodiment, the conversation information may indicate when certain users have been added to or removed from the conversation. For example, if messages that have included a user in a conversation reach a certain point in time and are then no longer included, the information for one or more subsequent messages may indicate that the user is no longer part of the conversation. For example, the conversation assistant can do this by displaying the user's name in a font different from that used to display the names of those users still participating in the conversation. For this purpose, the dialog assistant can use a "ghost" font.

Conversation information can also provide information about the entry of new participants to the conversation. For example, information relating to a first message involving a new participant may include formatting information for displaying the new participant's name in a distinctive manner. This information can be displayed to the user by the dialog assistant, so that the newly added sender's name or other identifying information can be presented in bold or some other visually distinct submission format.

Dialogue information may also include information about spell checking. This information may include indications of which words were identified by the spell checker 1014 as potentially incorrectly spelled, as well as information related to suggestions for correct spelling.

Figure 16 provides an illustration of the format used to store messages according to one embodiment of the invention. When a message is stored in the message database (stage 1114 of FIG. 11 ), it may be stored as illustrated in FIG. 16 . Message database 1602 may store information about messages, such as information about message 1 (1604) through message x (1606), where x represents the number of messages corresponding to a particular user. In one embodiment, each user's messages are stored in a message database 1602 unique to that user. In another embodiment, messages belonging to more than one user may be stored in the same message database 1602 . Those of ordinary skill in the art will recognize many ways to prevent a message from one user from being displayed as belonging to another user. In yet another embodiment, messages from more than one user can be stored in the message database 1602, and each message has only one stored entry, so that multiple users can refer to a single copy of the message.

In one embodiment, a message (eg, message 1608 ) may include header information 1612 , content 1614 , and attachments 1616 . Header information 1614 may include header information for the message containing information such as identifying the sender and recipient, a time/date value of the message, and the subject. Other information may also be included in the header information, such as other information described in RFC 2822. Content 1614 may include the content of the message. Content 1614 may include text and/or other types of content (eg, images or photos). Attachments 1616 may be any informational content attached to a specific message. For example, documents attached to the message may be placed in this portion of the message 1610 . Those of ordinary skill in the art will recognize other ways of storing message information. For example, attachments may be stored in another storage structure and references thereto placed in attachments1616.

In an alternative embodiment, all messages for each conversation are stored in a message database as a single record, document or data structure.

Data structures for users, messages, and conversations

Figure 17 illustrates a user database and message index according to an embodiment of the present invention. User database 1702 may store information about users. The stored information may include user information 1704 . User information 1704 may include various types of user information related to user preferences, security information, or any other information that may be used by different embodiments of the invention. The user database may include user identification information for identifying a user, such as user ID(1) (1706) through user ID(m) (1708), user ID(1) (1706) through user ID(m) (1708) where m may represent the number of users of the system. The specific user ID (m) (1708) may be a unique identifier for each user, such as an n-bit binary number. Other types of user identification can also be used.

In some embodiments, the user's user ID is used to identify a collection of data structures 1720 for storing information about filters, queries and tags related to the user's mail account. In some embodiments, these data structures include a query cache 1722 for storing information representing the last few queries submitted by a user; a set of filter caches for storing user-defined filters, if any; and a tag data structure 1726 for storing information representing user-defined tags. Recent queries represented by information stored in query cache 1722 may be submitted to the user, such as in group box 348 (FIG. 3B), so that the user can easily resubmit these queries in the session management system. The dialog management system uses user-defined filters during its processing when each new message is added to the user's mail account. Stored information related to user-defined tags may be presented to the user, such as in group box 347 (FIG. 3B), to enable the user to easily request a list of dialogs carrying user-selected tags.

A user's user ID may be used to identify the full text and attribute index 1710 corresponding to that user. The full-text and attribute index 1710 can be associated with a particular user such that different users cannot search the index for messages related to that particular user. The full text and attribute index 1710 stores information about messages in the user's mail account, so that a query applied against the full text and attribute index 1710 can return a list of matching messages, if any. This list can be returned as a list of message identifiers.

The information contained in the full-text and attribute index 1710 for a particular message may include the message ID 1712 of the message, the content 1714 of the message 1714, and information about the attributes 1716 of the message. Message ID 1712 is a unique identifier for the message (ie, unique with respect to all other messages stored for the same user). Message ID 1712 may be an n-bit number used to reference a specific message stored in message database 1702 . In one embodiment, the message ID 1712 may be a 64-bit number. Message ID 1712 may consist of time stamp information and information related to the content of the message to which Message ID 1712 refers. The time stamp information may be a Y bit (eg, 32 bits or 48 bits) time stamp provided by the system, eg, indicating when the SMTP gateway 1018 received the message. The information related to the content of the message may be a hash of 64-Y bits of the message content.

Put the content of the message in the index as a fully indexed and searchable item. When the index 1710 is searched for an item or combination of items, the index returns a message list (eg, message ID) of messages matching the item or combination of items. Certain predefined conditions may dictate that fewer than all matching messages be returned. In another embodiment, the index 1710 returns a list of conversations (eg, conversation IDs) that match an item or combination of items in the query.

In one embodiment, the entries for the search term in the full-text and attribute index 1710 are sorted according to the timestamp information contained in the message ID 1712 of each indexed message, so that the entries matching the search term are preferentially returned. latest news. For example, the list of message IDs of the messages corresponding to each entry in index 1710 may be ordered such that message IDs with the latest time stamps may be listed in the list before message IDs with older time stamps. In other embodiments, date/time information associated with each message indicates the date and/or time each message was received, but this date/time information is not embedded in the message ID. However, in such an embodiment, the entries in index 1710 are arranged such that the message IDs of messages with the newest date/time values may be listed in the list before message IDs with older date/time values.

Any attributes associated with the message are also indexed 1716 (ie, included in index 1710). Attributes 1716 are added to the full-text and attribute index 1710 so that queries for a particular attribute can return those messages that match that particular attribute. As tags or attributes are added to or removed from the dialog, the index 1710 is modified accordingly. The index includes entries or data that map each defined tag or attribute to all messages (or in other embodiments, dialogs) that carry that tag or attribute. Thus, when a tag is added to a conversation, data is also added to the index 1710 to map that tag to all messages in the conversation. When a tag is removed from a dialog, the data in the index mapping the tag to messages in the dialog is also removed, or the index is invalidated. In some embodiments, each dialog-associated tag or attribute is also added to one or more entries in the dialog database 1808 (FIG. 18).

While the full text and attribute index 1710 can be configured to map query terms to individual message IDs 1712, other data structures can be provided to map message IDs to session identifiers. Figure 18 depicts a logical diagram of one such collection of data structures. Those of ordinary skill in the art will recognize that many different data structures can be used to map search query terms to conversations or conversation identifiers.

As previously described, the user database 1702 may include a user ID 1708 referencing a full-text and attribute index 1710 associated with a particular user. Referring to FIG. 18 , a specific message ID 1712 can be associated with a specific conversation ID 1802 in a message-to-conversation map 1804 . Each entry in message-to-conversation map 1804 associates (ie maps) a message ID 1712 with a conversation ID 1802. In some embodiments, session ID 1804 is a number of n bits. This number uniquely identifies the specific conversation to which the message identified by Message ID 1712 belongs. In these embodiments, each conversation in the user's mail account has a different conversation ID.

To identify other messages associated with a particular conversation, user conversation database 1808 may be used. Such a database may be used, for example, when identifying the remaining messages included in a conversation in which one or more messages have matched a particular search query. The user conversation database includes a plurality of conversation entries 1810 . Each conversation entry 1810 stores a list of messages (or other data structures representing messages) associated with that conversation. For example, conversation entry 1812 may include a linked list of message entries 1816, each message entry corresponding to a specific message in the conversation. For example, sort a list of links based on date/time values associated with messages in a conversation. Exemplary message entry 1816 includes message ID 1712 , header 1818 , and tag 1820 for the particular message. Header 1818 may include all or a portion of header information 1612 previously described. Tag 1820 may include information identifying certain attributes associated with the message. Message ID (4) 1712 of specific entry 1822 may be associated with a specific message in message database 1602 . In some embodiments, the message entry 1816 does not include the content of the corresponding message body.

In some embodiments, the information in index 1708 and in conversation entry 1812 facilitate associating new messages with specific conversations, which can be done in stage 1106 of FIG. 11 without having to access a message database 1602. When a message is identified as being as closely matched as possible to a newly arriving message (stage 1204 of FIG. 12), the header 1818 of the matching message may be used to enable the determination of the best matching message and thus the best matching dialog. For example, headers 1818 may include topic information for messages that enable them to be compared (in normalized form) to the normalized topics of newly arriving messages. Other information in header 1818 may also be compared to the header information of the incoming message being processed. Once the dialog has been identified as matching, the attributes identified in the tag 1820 of the message entry for the identified dialog can be applied to the incoming message (stage 1307 of Figure 13) without having to retrieve any messages from the message database.

When a message is deleted from a conversation, the conversation entry 1812 can be modified without affecting other messages in the conversation. In this case, the message entry 1816 (in conversation entry 1812) corresponding to the message to be deleted may be deleted from the linked list of message entries. Then, the message will no longer be associated with the conversation. In some embodiments, the message-to-conversation map 1804 may also be modified to account for delete operations.

As previously described, in some cases, for example, one may wish to mark a message for deletion with a certain attribute, but not remove the message from the conversation. When conditions are such that the message can be removed from the dialog, it can be done as described above. Conditions that may allow messages to be removed from message-to-conversation map 1802 and conversation entry 1812 may include the elapse of a certain amount of time since the message was marked for deletion, user action, or other triggering events.

The conversation may also be marked as deleted, but not yet removed from the user's mail account. When a conversation is permanently removed from the user's mail account, then the message to conversation map 1802 entry for the conversation may be removed. Additionally, the corresponding conversation entry 1812 can also be removed from the conversation database 1808 , and the index entries for messages in the conversation can also be removed from the index 1708 .

As noted above, in another embodiment, the full text message index 1708 returns a list of conversation identifiers in response to a query. In this embodiment, messages to dialog map 1802 may be omitted. Instead, the dialog database provides the primary images needed to complete the processing of the dialog corresponding to the query.

Referring to FIG. 19, an embodiment of a dialog server 102 implementing the methods described above includes one or more processing units (CPUs) 1902, one or more network or other communication interfaces 1904, memory 1006, and one or more devices for interconnecting these components. communication bus 1908. Dialogue server 102 may optionally include a user interface including a display device and a keyboard. Memory 1906 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic or optical storage disks. Memory 1906 may include mass storage located remotely from CPU 1902 . Memory 1906 may store:

Operating system 1916, which includes procedures for handling various basic system services and for performing hardware-dependent tasks;

A network communication module (or instruction) 1918, which is used to connect the dialog server 102 to other computers via one or more network communication interfaces 1904 (wired or wireless) such as the Internet, other wide area networks, local area networks, metropolitan area networks, etc.; as well as

Dialogue engine 1002 module for responding to requests from dialog assistant 110, and providing responses to dialog assistant 110, as previously described, and may include:

processing new message module 1920 for processing new messages as previously described;

Search module 1922, which is used to search the user's messages, as previously described, the search module 1922 includes modules for processing search requests from input provided by the user 1922, and for processing messages initiated by the dialog assistant 110 A module 1926 for the system to generate a search;

Dialog Assistant Loader 1928 for providing dialog assistant 110 with information that allows the dialog assistant to process information provided to it from dialog server 102 . In some embodiments, the dialog assistant loader 1928 is invoked to load the dialog assistant 110 on the client computer when the client computer is first connected to the dialog server 102 to process an email message. In some embodiments, the dialog helper loader 1928 loads the dialog helper 110 on the client computer each time an email session is started, while in other embodiments the client computer loads the dialog helper 110 from an email session. The session is held until another email session;

Answer formatting module 1930 for providing formatted information to be provided to dialog assistant 110, as previously described, including dialog ordering module 1932 for ordering dialogs according to predefined criteria, as previously described the selection dialogue module 1034, which is used to select a predetermined number of dialogues to be returned to the dialogue assistant 110 from the total number that can be returned; the identification sender 1936 of an unread/unviewed message, which is used For identifying messages that are marked as "unread" (i.e., messages that have not been viewed or marked as read), as previously described; a self-referencing module 1938 for providing information on using self-referencing The information supersedes the information of the user identification, as previously described; the new recipient module 1940, which is used to identify and provide information about newly adding recipients to the dialog, as previously described; the remove recipient module 1942, which is used to identifying and providing information about recipients who are no longer part of the conversation, as previously described; an excerpt module 1944 for obtaining and providing information about certain text of a matching message, as previously described; and the full text This module 1946, which is used to retrieve the full text of the message transmitted to the dialog assistant 110, as previously described; and a format spell check module 1948, which is used to format the information returned from the spell checker 1014;

Modify Attributes module 1950 for modifying attributes of dialogs and messages, as previously described;

Delete/Remove Module 1095 for marking messages or conversations for deletion and subsequently removing them, as previously described;

Filtering module 1954, which is used to create, monitor, and perform filtering, as previously described; and

Compose/Send module 1956 , which allows users to compose messages and submit the resulting messages to SMTP gateway 1016 .

It should be appreciated that the various features described above, such as the exemplary embodiments of the spell checking process, and display methods, are not limited to electronic messaging or email. For example, in other embodiments, the above-mentioned spell checking method or user interface can be applied to various types of documents (eg, word processing documents), or implemented in combination with various types of documents.

The foregoing description has been made illustratively with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Numerous modifications and variations of the present invention are possible in light of the above teachings. The embodiment was chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to enable others skilled in the art to understand the invention with various modifications as are suited to the particular application considered. Take full advantage of the invention and its various embodiments.

Claims (14)

1. A method performed on a server system having one or more processors and memory, the method comprising: In response to a single search query from a respective user: searching the library of email messages to identify a plurality of conversations associated with respective users, wherein each of the plurality of conversations includes at least one email message related to the search query, and the plurality of identified Each of the conversations includes one or more email messages sharing the same normalized subject; sending a list of conversations representing at least a subset of the identified conversations, wherein at least one conversation in the list comprises a plurality of email messages; and Content of the selected conversation from the list of conversations is provided including formatted information that visually distinguishes one or more first email messages of the selected conversation from one or more second email messages of the selected conversation. email messages, wherein the one or more first email messages include at least one query term of the search query and the one or more second email messages do not include any query terms of the search query . 2. The method of claim 1, wherein the formatting information includes information for displaying text in a distinctive manner. 3. The method of claim 1, wherein the formatting information includes highlighted text matching the search query in the one or more first email messages. 4. The method of claim 1, wherein the formatting information includes a format for displaying the one or more first email messages in an expanded mode and displaying the one or more second email messages in a compressed mode. Formatting information for the mail message. 5. The method of claim 4, wherein: Email messages displayed in expanded mode include the full email message body; and Email messages displayed in compressed mode do not include the complete email message body. 6. The method of claim 1 , wherein the list of conversations includes formatted for presentation in a single line including a portion of content from a respective conversation that includes one or more terms matching the search query their respective dialogues. 7. The method of claim 6, wherein the portion of the content from the dialog including one or more terms matching the search query is formatted to display one or more items matching the search query in a distinctive manner. multiple items. 8. A server system comprising: means for searching a library of email messages in response to a single search query from a respective user to identify a plurality of conversations associated with the respective user, wherein each of the plurality of conversations includes at least one querying for related email messages, and each of the plurality of identified conversations includes one or more email messages of the same normalized subject; means for sending a list of conversations representing at least a subset of the identified conversations, wherein at least one conversation in the list comprises a plurality of email messages; and Content for providing a selected conversation from a list of conversations including formatting information that visually distinguishes one or more first email messages of the selected conversation from one or more of the selected conversations second email messages, wherein the one or more first email messages include at least one query term of the search query and the one or more second email messages do not include any of the search query Query item. 9. The server system according to claim 8, wherein the formatting information includes information for displaying text in a distinctive manner. 10. The server system of claim 8, wherein the formatting information includes highlighted text matching the search query in the one or more first email messages. 11. The server system of claim 8 , wherein the formatting information includes information for displaying the one or more first e-mail messages in an expanded mode and displaying the one or more second e-mail messages in a compressed mode. Formatting information for email messages. 12. The server system of claim 11, wherein: Email messages displayed in expanded mode include the full email message body; and Email messages displayed in compressed mode do not include the complete email message body. 13. The server system of claim 8 , wherein the list of conversations includes a format for presenting a portion of content from a respective conversation including one or more terms matching the search query in a single line. of their respective dialogues. 14. The server system of claim 13 , wherein the portion of content from the dialog including one or more terms matching the search query is formatted to display in a distinctive manner an item matching the search query. or multiple items.