Invention for Automatic conversation techniques

Invented by Michael Affronti, Andrew Brauninger, Robert Emmett Mccann, James Edelen, Jorge Pereira, Microsoft Technology Licensing LLC

The Microsoft Technology Licensing LLC invention works as follows

Automatic conversation techniques are described. A computing device may include an incoming messaging module that receives an incoming e-mail, a communication identification module that is communicatively connected to the message module and is operative for determining the message is part a thread of conversation, associating the message with the thread by setting the conversation identifier of the message to the conversation identifier of the thread and a discussion manager module which is communicatively linked to the module of conversation identification and is operative for determining a rule of conversation is associated Other embodiments are described, and claims.

Background for Automatic conversation techniques

Electronic mail applications allow users to organize messages into logical folders similar to those found in many file systems. Email applications may also allow users to group messages into logical “conversations.” Each conversation is made up of a number of messages, including the original message and any replies. Messages are displayed as a list in the user interface of an e-mail program when arranged by conversations. These conversations can be grouped according to message subject or thread. Conversations can be sorted according to date and messages within each conversation can be sorted according to who replied.

Some email applications, despite the convenience of conversation groups, limit the operation for a discussion to the individual conversation items. A user might not want to participate in a thread of conversation about lunch options. To keep the inbox clean, a user might need to delete each conversation item as it arrives. These operations can be time-consuming and tedious for users, especially when they receive a large number of emails each day. To solve these problems, and improve the user experience in different scenarios, it is necessary to improve item management and display techniques.

This Summary is intended to present a number of concepts that are described in more detail in the Detailed description. This Summary does not aim to identify the key features or essential elements of the claimed object matter. Nor is it meant to be used as a tool to limit the scope.

Various embodiments” are directed at automatic conversation techniques in a message application. Some embodiments are directed at automatic conversation actions which can be applied to an entire conversation thread or group for a message app, like an email application.

One embodiment may, for instance, comprise an apparatus, such as a computer device, having a messaging application program. The message program may include, among other components, an incoming messaging module that is operative to receive a message. The message application module may also include a communication identification module communicatively connected to the incoming messages module. This module is operative to determine that the incoming messages are part of a thread of conversation and to associate the message with the thread of conversation by setting the conversation identifier of the message to the conversation identifier of the thread of conversation. The message application module may also include a communication manager module communicatively connected to the discussion identification module. The conversation manager module is operative to determine that a rule of conversation is associated with the thread and to apply the rule to the message. “Other embodiments are described, and claims.

The following detailed description, along with the accompanying drawings will make it clear that these and other features and benefits are present. Both the general description above and the detailed description below are only intended to explain and not to restrict the aspects claimed.

Various embodiments” include physical or logical structure arranged to perform specific operations, functions, or services. Structures can be physical, logical or a mixture of both. Hardware elements, software components, or a mixture of both can be used to implement the physical or logical structure. The descriptions of embodiments that refer to specific hardware or software components are examples, and not intended as limitations. The decision to use software or hardware elements in order to implement an embodiment is based on several external factors. These include desired computational rates, power levels and heat tolerances, budget for processing cycles, memory resources, bus speeds and other performance or design constraints. The physical or logical structure may also have corresponding connections that allow information to be communicated between the structures via electronic signals or messages. These connections can be wired or wireless, depending on the structure and/or information. Any reference to “one embodiment” or “an embodiment” is misleading. or ?an embodiment? At least one embodiment includes a certain feature, structure or characteristic that is described in conjunction with the embodiment. The phrase “in one embodiment” appears in several places. The phrase “in one embodiment” may appear in different places within the specification. This does not mean that they all refer to the same embodiment.

Various embodiments can be directed towards automatic conversation techniques in a message application. These automatic conversation techniques can be used for any type of message application. Examples of message apps include, but are not limited to, e-mail, text, MMS, SMS, voice, video, etc. In one embodiment, automatic conversation techniques can be described by reference to an email application as an example. Specific implementations can implement the automatic communication techniques with other messaging apps, but still fall under the scope of the “embodiments.

Various embodiments can be directed at automatic conversation techniques in a message application, such as an email application. A general e-mail program allows users to send and receive messages via electronic communication systems. In some embodiments the described techniques can be implemented by a single or multiple elements of a server/client e-mail messaging systems. In these embodiments, a server can support multiple messaging clients and accept data and requests from the clients. The server will then process the data and requests, and send the results back to the clients. In this way, the item aggregation techniques can be implemented in client-based email applications, server based email applications (including web-based applications that provide access to e mail services via a browser), and/or other applications, programs or services which interact with e -mail.

In certain embodiments, the web server can support various Web Services including mobile access and synchronization, Internet Information Services and Internet Server Application Programming Interface applications that provide SMTP and NNTP services, IMAP4 and POP3 to allow Internet users access to messaging data via a variety Internet access protocols, HTTP-based protocols, including remote procedure calls (RPC) using HTTP communication. Data may be formatted in Wireless Binary XML data (WbXML), which is compressed to save bandwidth on mobile clients. The server may also support proprietary or nonstandard protocols in addition to the standard Internet protocol when it is used by an organization or company.

The e-mail program may allow users to organize messages into logical folders in the interface, similar to what is provided by most file systems. The term folder can refer to a collection of items, regardless of how they are stored or represented in an interface. “While some operating systems and applications may not refer to a folder as a collection, these scenarios are intended be covered by embodiments which describe and illustrate folders.

The e-mail program may also allow users or logic to group messages into logical conversation groups to form a discussion group or thread. Each conversation can consist of a collection of messages, such as a message that is the main message, and any replies. When a message is arranged by conversation by the user, the list of conversations displayed on the user interface of an email application can be grouped according to the subject of the message or the thread. Conversations can be sorted according to date and messages within each conversation can be sorted in accordance with who replied to whom.

In some cases, messages from a conversation can be stored in multiple folders. Users can manually sort messages into different folders. Users can also set up one or more filters to automatically separate e-mails into folders according to sender, subject or other criteria. A reply message that is sent by the user can also be saved in the sent items folder.

Some email applications restrict the operation of a conversation, despite the convenience provided by conversation threads. A user might not want to participate in a thread of conversation about lunch options. To keep their inbox clean, the user may have to delete each conversation item as it arrives. These operations can be time-consuming and tedious for users, especially given the volume of emails they receive each day.

To solve these problems and others, different embodiments can implement automatic conversation techniques in a message application. Some embodiments are aimed at automatic conversation techniques which can be applied to an entire conversation group, or conversation thread, in a message application such as e-mail.

One embodiment may, for instance, comprise a device such as a computer having a message program such as an email program. The message program may include, among other components, an incoming messages module that is operative to receive a message. The message application module may also include a communication identification module communicatively connected to the incoming messages module. This module is operative to determine that the incoming messages are part of a thread of conversation and to associate the message with the thread of conversation by setting the conversation identifier of the message to the conversation identifier of the thread of conversation. The message application module may also include a communication manager module, which is communicatively connected to the conversation identification component. This module is operative to determine that a particular conversation rule has been associated with the thread and to apply it to the incoming messages. A user only needs to set up a single conversation rule, which is then automatically applied to the messages stored in the conversation thread as well as any new messages received that are part the conversation thread. The user can enjoy a better messaging experience.

The conversation manager module is a powerful tool that implements automatic conversations techniques. These are implemented in the form conversation level actions, which can be applied to an entire conversation group. Conversation level actions usually affect all or some messages in the conversation thread. Item level actions, on the other hand, typically affect only one message. Conversation rules can include, but are not limited to: “always delete” Conversation rules can include an ‘always delete? Conversation rules include: “always move”; “always categorize”; and more. Conversation, for example. This is just a small sample of the many possible actions that can be taken at a conversational level. In this context, the embodiments aren’t limited.

FIG. The block diagram of FIG. 1 shows an operating environment 100 that is suitable for implementing the various embodiments. The operating environment 100 can include elements that are designed to be implemented by either a single entity or multiple entity distributed environments. The elements may be implemented in hardware, software, or a combination of both, depending on the desired design parameters or performance requirements. Hardware elements include semiconductor devices, chips, microchips and chip sets. Examples may also include processors, integrated circuits and microprocessors. Software elements include software components, applications, computer software, application software, system software, machine software, operating system software (OS), middleware, firmware and software modules. They may also include routines, subroutines or functions.

The terms “system” and “subsystem” are used in this context. ?subsystem,? ?component,? The terms?component,? The terms?module’ and?computer-related entity’ are meant to refer to an entity that is computer-related, which can be either a combination or hardware and software (or both), software, or software currently in execution. Components can, for example, be implemented by a process that runs on a CPU, a hard drive, multiple storage devices (of optical or magnetic storage medium), a program, an executable thread, an object, etc. As an example, both the application running on a client and the server could be components. One or more components may reside in a thread or process. A component can also be localized to one computer or distributed across two computers, depending on the implementation. In this context, the embodiments are not restricted.

Click here to view the patent on Google Patents.