FreshPatents.com Logo
stats FreshPatents Stats
n/a views for this patent on FreshPatents.com
Updated: November 16 2014
newTOP 200 Companies filing patents this week


    Free Services  

  • MONITOR KEYWORDS
  • Enter keywords & we'll notify you when a new patent matches your request (weekly update).

  • ORGANIZER
  • Save & organize patents so you can view them later.

  • RSS rss
  • Create custom RSS feeds. Track keywords without receiving email.

  • ARCHIVE
  • View the last few months of your Keyword emails.

  • COMPANY DIRECTORY
  • Patents sorted by company.

Follow us on Twitter
twitter icon@FreshPatents

Mechanism for indicating unread emails in a container

last patentdownload pdfdownload imgimage previewnext patent


20120331398 patent thumbnailZoom

Mechanism for indicating unread emails in a container


A mechanism is disclosed for generating a composite email for an email conversation. The composite email includes content automatically extracted from a plurality of the emails in the email conversation, and may be generated in response to a user accessing just one of the emails in the email conversation. A mechanism is also disclosed for discovering and recovering lost emails in an email conversation. A mechanism is further disclosed for automatically moving emails from one container to another after an email has been read. These and other advantageous email generating, manipulation, and organization mechanisms are disclosed herein.

Inventor: RAJKUMAR R. MADNANI
USPTO Applicaton #: #20120331398 - Class: 715752 (USPTO) - 12/27/12 - Class 715 
Data Processing: Presentation Processing Of Document, Operator Interface Processing, And Screen Saver Display Processing > Operator Interface (e.g., Graphical User Interface) >Computer Supported Collaborative Work Between Plural Users >Interactive Email

view organizer monitor keywords


The Patent Description & Claims data below is from USPTO Patent Application 20120331398, Mechanism for indicating unread emails in a container.

last patentpdficondownload pdfimage previewnext patent

PRIORITY CLAIM

This application is a Divisional of U.S. patent application Ser. No. 13/070,749, entitled “MECHANISM FOR IMPLEMENTING LABELS AND REMINDERS IN AN EMAIL SYSTEM”, filed Mar. 24, 2011, which is a Divisional of U.S. patent application Ser. No. 11/820,708, entitled “MECHANISM FOR FACILITATING ORGANIZATION AND ACCESSING OF EMAILS”, filed Jun. 19, 2007, which is a continuation of U.S. patent application Ser. No. 11/805,636, entitled “MECHANISM FOR GENERATING A COMPOSITE EMAIL”, filed May 23, 2007, which claims the benefit of U.S. Provisional Application Ser. No. 60/878,237, entitled “SYSTEM AND METHOD FOR AN EMAIL MANAGEMENT SYSTEM THAT REDUCES THE CLUTTER OF REPETITION OF EMAILS IN FOLDERS AS WELL AS IN EMAIL CONTENT, PROVIDES FEATURES THAT FACILITATE COLLABORATION BY EMAIL COMMUNICATION, AND PROVIDES FOR WAYS TO USE EMAIL CONTENT IN MEANINGFUL WAYS”, filed Jan. 3, 2007. The entire contents of the above-referenced applications are hereby incorporated by reference.

BACKGROUND

Electronic mail (hereinafter “email”) has become one of the most widely used communication tools in the world. Most people use email systems at their workplace and at home, and with the increasing number of emails sent and received, the shortcomings of existing email systems are becoming clear.

One drawback to existing email systems is that managing emails, new incoming and new outgoing, and their subsequent replies and forwards, is increasingly difficult with the growing volumes of emails, and more often than not leads to cluttered inbox, sent, and deleted folders. The inbox folder often becomes cluttered because emails, new incoming emails as well as previously read emails, are stored in the inbox folder until a user manually moves the emails out of it. Emails get cluttered in the sent folder because new emails sent out by the user are stored in the sent folder, and replies and forwards sent by the user to others are also stored in the sent folder.

Over time, the clutter keeps increasing, and it is quite common for users to have hundreds of emails sitting in the inbox, sent mail, and other named folders. It takes considerable effort to move and keep moving the emails into other named folders, to keep the clutter from growing. As the emails are moved into named folders, the named folders themselves get cluttered with repetitive emails. The user is afraid to delete any email (in inbox, sent or named folders) for fear of losing something important, and because of time constraints is unlikely to sift through these emails in order to reduce their redundancy.

While each email does contain some new data in the form of the latest email message, it likely contains a repetition of earlier emails as an appendix, which may be in the form of “quoted” text continuing after the new message or in the form of a separate file attached to the email. When the number of participants in an email increases, the potential for clutter increases very rapidly and in direct proportion to the increase in number of participants. Some users may spend the time and effort to move emails on a particular subject, or grouping, into specific named folders, reducing the amount of clutter in the inbox, sent and deleted folders, but many or even most do not.

Another drawback to current email management approaches is that identifying, extracting and using data residing in emails can get extremely cumbersome because the data may be resident in conceivably twenty, thirty, forty or more than a hundred emails on a particular subject. These emails may also reside in different folders, such as the inbox, sent and other named folders, and possibly in the deleted folder too. It can become impenetrable, if the need for data tucked away in various emails arises after several days when one\'s memory may not be as sharp, or if data is contained in emails with several subject headings. Information on a particular topic cannot be easily collated from various emails, and printing the various emails for a hard copy reference is a voluminous job with diminishing utility as the number of emails grows.

In general, current approaches provide two ways to meaningfully use the data contained in multiple emails. One way is to highlight the required text, a few words or several lines at a time, in an email that is open on the user\'s screen, and copy it into another document (word processing or email or other), and then to repeat this process over several emails. Another way is to create an exported output of the email into a file, instead of paper, and then use the output of the resulting file in another document which may be a word processing document, or an email or some other document, and then to repeat this process over several emails.

Many email management systems provide search facilities to identify the emails that may contain specified words or phrases. The search result identifies the emails that satisfy the specified search criteria. But once the emails have been identified, either by manually going through several emails, or by the quicker search routines, the problem of extracting the data and using it from the several identified emails remains. The problem can be partially addressed by going into each email, one at a time, and using one of the two ways described above, highlighting or using an export function to create an output file, to extract and use the data. As the number of emails increases, so does the effort. These limitations, combined with the clutter of large numbers of emails, make it extremely difficult to use the data from the emails in a meaningful manner.

Another drawback to current approaches is that data is repeated over and over in replies and forwards, both sent and received, using valuable disk space. Additionally, particularly at the corporate or enterprise level, backups and historical records maintenance become more cumbersome and costly. The extent of data repetitiveness in emails, and redundancy due to multiplicity of mostly identical emails, can be quite a serious problem in terms of how much storage space is used for periodic backups as a security measure and for archiving, tasks which may be statutory requirements for many companies. If multiple copies of emails are eliminated or avoided in backups, it may be possible to reduce the manpower and memory requirements of email backups and archiving.

Another drawback to current approaches is that as users keep sending and receiving emails, the subject of the emails evolves, but emails are sent using the same subject heading. Sometimes a subject heading may be changed to reflect a new evolved status of the old subject, but the content of old as well as new subjects may continue under the new subject heading. In essence, the current system of emails allows a subject heading, but does not allow any organized way of enforcing that subject heading (i.e. limiting the discussion to that subject heading).

Current email management approaches have no organized way to manage subject headings as they evolve or change into subheadings. In one case, the subject heading does not change, but the content of emails may be on revised but related subjects (evolution of the original subject), thus making data collection and analysis from emails even more difficult than already described. In another case, the subject heading changes to reflect an evolution from the original subject, but some email users may continue to send text based on the old subject but use the new subject headings, thus once again making it difficult to delete or organize the emails.

Another drawback to current approaches occurs when the subject itself does not evolve, but there is simply a natural passage of time. Current approaches do not permit a systematic way to continue emails on an old subject after a period of absence of emails on the subject. If a user receives an email on an old subject after a long break, the potential for the email containing one or more of the following is rather high: the sender may fail to append older emails exchanged on that topic (i.e. a new email instead of a reply/forward to an older email on the subject), or fail to write the same subject in the subject line, or worse, send an appendix of other irrelevant emails while sending the email on the subject. Currently, the user has to review the clutter of emails in various folders to obtain a history of that subject. This makes it very difficult for the user to ascertain the context behind the new message. Thus, the new message may be difficult to understand.

The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

SUMMARY

In accordance with one embodiment of the present invention, there is provided a mechanism for generating a composite email. As used herein, the term “composite email” refers to a set of information that includes content automatically extracted from a plurality of individual emails. With this mechanism, it is possible for a user to view content from multiple emails without having to manually open and extract content from each of those emails.

In one embodiment, when an initial email pertaining to a particular topic or subject is sent to start an email conversation, a unique identifier is associated with that email. All subsequent emails in that email conversation (e.g. responses to the initial email, response to responses to the initial email, etc.) will also carry that unique identifier. Thus, the unique identifier associates the various emails with each other so that they can be treated as being part of the overall email conversation.

In one embodiment, when any email in an email conversation is accessed by a user, the mechanism extracts the unique identifier from that email. The mechanism also extracts content from that email. Based at least partially upon the unique identifier, the mechanism accesses an email conversation data structure that is associated with the email conversation. This email conversation data structure contains information indicating which emails are part of the email conversation. The mechanism selectively accesses one or more of the emails that are indicated by the email conversation data structure as being part of the email conversation, and extracts content from those one or more accessed emails. The mechanism then automatically generates or composes a composite email. The mechanism includes in this composite email the content extracted from the email that is being accessed by the user and the content extracted from the one or more accessed emails. This composite email may then be displayed to the user. By performing the processing discussed above, the mechanism enables the user to easily view the contents from several or all of the emails in the email conversation without having to manually search for each email, manually open each email, and manually extract information from each email. Thus, viewing the contents of multiple emails in an email conversation is made quite simple. In one embodiment, none of the emails in the email conversation contain repeated text that is copied from previous emails in the email conversation (e.g. if an email is a reply to a previous email, it does not contain a copy of the text in the previous email; rather, the reply includes just the new text entered by the sender of the reply); thus, none of the emails in the email conversation contain redundant content. Because of this, the content that is extracted from the various emails and included in the composite email is inherently non-redundant.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIGS. 1A and 1B show sample systems in which one embodiment of the present invention may be implemented.

FIG. 2 shows a sample user interface that is provided by one embodiment of the present invention to enable a user to create an initial email of an email conversation.

FIG. 3 shows a sample user interface provided by one embodiment of the present invention in which a composite email may be displayed.

FIG. 4 shows a sample email conversation data structure that is used, in accordance with one embodiment of the present invention, to maintain information indicating which emails are part of an email conversation.

FIG. 5 shows a sample display of containers that a user may see when a user accesses his/her email account, wherein the containers may be used to store various emails in the email account.

FIG. 6 how reminders associated with emails may be presented to a user in accordance with one embodiment of the present invention.

FIG. 7 is a block diagram of a general purpose computer system in which one embodiment of the present invention may be implemented.

DETAILED DESCRIPTION

OF EMBODIMENT(S)

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Overview

One embodiment of the present invention enables email to be used to emulate a conversation or meeting. To start the conversation or meeting (hereinafter, just conversation for the sake of brevity), a user sends an initial email to a set of participants. This initial email sets forth a particular topic for discussion. Thereafter, the participants may provide input on the topic by sending response emails, with each response email containing a set of new content. Current email systems are capable of providing what has been described thus far. What they are missing, however, is the ability to relate the various emails in such a way that they resemble a coherent conversation. Currently, email systems treat each email as a separate entity, indicating by a “RE” or a “FWD” preceding the subject that the email is a reply or a forwarded email, and there is no way to automatically relate one email to another. Thus, in order to see all of the response to the initial email, a user has to find each of the response emails, and open each to view the content contained therein. In many instances, there is redundant information in the response (e.g. a reply may have the content from previous replies appended to it); thus, the user has to further sift through the response to find the new content.

To make the overall exchange of information more resemble a conversation, an embodiment of the present invention introduces the concept of a “composite email”. As used herein, the term composite email refers to a set of information that includes content automatically extracted from a plurality of individual emails. In the context of an email conversation, a composite email would include content extracted from multiple emails in the email conversation. Thus, a composite email may be analogized to a transcript of the email conversation. With such a transcript, it is easy for a user to see what has transpired thus far in the conversation. In one embodiment, a composite email is automatically generated whenever any one of the emails in an email conversation is accessed by a user.

In one embodiment, to make it possible for all of the emails pertaining to an email conversation to be related to one another, a unique identifier is associated with all of the emails. Specifically, in one embodiment, when an initial email is sent by a user (this email is the one that sets forth the particular topic to be discussed in the email conversation, and this user is referred to as the administrator of the email conversation), a unique identifier is generated and associated with the initial email. This unique identifier may be viewed as a conversation identifier for identifying the email conversation that is being started. All subsequent emails in the email conversation (e.g. responses to the initial email, responses to the responses to the initial email, etc.) will also carry that unique identifier. Effectively, the unique identifier relates all of the various emails so that they can be associated with each other. In a sense, the unique identifier ties the various emails together so that they can be treated as being part of the same email conversation.

In one embodiment, the unique identifier comprises a code generated from the administrator\'s user identification, such as his/her email address, a date and time code, and a sequential counter. The sequential counter may be a counter that keeps track of the number of initial emails that have been sent by this administrator. For example, if the administrator has started six email conversations, and hence, has sent six initial emails, then the sequential counter for the administrator would be six. This means that the next initial email sent by the administrator would have a sequential counter value of seven. In addition, the unique identifier may further comprise a special designation (e.g. UID) to indicate that it is a unique identifier. This is just one way of generating the unique identifier. Many other methodologies may be used. For purposes of the present invention, the unique identifier may be generated using any desired methodology and any type of information. So long as the identifier is unique, it may be used as the unique identifier for an email conversation.

In one embodiment, when any email in an email conversation is accessed by a user, the unique identifier for the email conversation is extracted from that email, and content contained in that email is also extracted. Based at least partially upon the unique identifier, an email conversation data structure that is associated with the email conversation is accessed. This email conversation data structure contains information indicating which emails are part of the email conversation. One or more of the emails that are indicated by the email conversation data structure as being part of the email conversation are accessed, and the contents of those one or more accessed emails are extracted. A composite email is then automatically generated or composed. Included in this composite email are the contents extracted from the email that is being accessed by the user and the contents extracted from the one or more accessed emails. This composite email may then be displayed to the user. By presenting the composite email to the user, it is possible for the user to view, in a single display, the contents from several or all of the emails in the email conversation without having to manually search for each email, manually open each email, and manually extract information from each email. In one embodiment, none of the emails in the email conversation contain repeated text that is copied from previous emails in the email conversation (e.g. if an email is a reply to a previous email, it does not contain a copy of the text in the previous email; rather, the reply includes just the new text entered by the sender of the reply); thus, none of the emails in the email conversation contain redundant content. Because of this, the content that is extracted from the various emails and included in the composite email is inherently non-redundant.

In addition to being used to generate a composite email, the unique identifier may also be used to organize the emails into containers, thereby making emails easier to find. The unique identifier may also be used to enable other advantageous functionalities to be realized. These and other functionalities will be described in detail in later sections.

A mechanism for realizing the functionalities described herein may take on various forms. In one embodiment, the mechanism takes the form of an enhanced email program (EEP) that is executed on one or more client computers in an overall email system. An example of such a system is shown in FIG. 1A, wherein the system comprises a plurality of client computers 102 coupled to an email server 108 via a network 106. One or more of the client computers 102 has an EEP 104 executing thereon. In this embodiment, the EEP 104 on each client computer 102 would implement the functionalities described herein. The email server 108 would simply act as the conduit for transporting emails from one client computer 102 to another. In the system of FIG. 1A, the EEP\'s 104 would send emails that conform to standard email protocols; thus, even though they have composite email capability, the EEP\'s 104 can interact with any email server 108 that implements standard email protocols.

In an alternative embodiment, such as that shown in FIG. 1B, the mechanism may take the form of an EEP 114 that is executed on a server 118. The server 118 may, for example, be a web application server and the EEP 114 may be a web application hosted on that server 118 that is capable of servicing requests from a plurality of client computers 102. To interact with the server 118, each client computer 102 may execute a program such as a browser 110. In this embodiment, the EEP 114 would implement most of the functionalities described herein. The client computers 102 would mainly be responsible for providing a user interface (UI) to users to enable the users to send commands to the EEP 114, and to enable the users to view the content (e.g. the composite email) generated by the EEP 114.

As a variation of the embodiment shown in FIG. 1B, some of the functionalities described herein might not be implemented by the EEP 114 but rather by code executed on the client computers 102. For example, the server 118 may download one or more applets to the client computers 102, and those applets, when executed on the client computers 102, may implement some of the functionalities described herein. Alternatively, the browser 110 may have one or more plugins that, when executed, may implement some of the functionalities described herein.

As a further alternative, each client computer 102 may have a client program (not shown) resident thereon that is designed to interact with the EEP 114 to implement the functionalities described herein (a client-server architecture). The EEP 114 may implement some of the functionalities while the resident program may implement the other functionalities.

Overall, the functionalities described herein may be fully implemented by an EEP 104 executing on a client computer 102, fully implemented by an EEP 114 executing on a server 118, or fully implemented by a combination of an EEP 114 executing on a server and code executing on a client computer, (where each (server and client) implements a subset of the functionalities). All such implementations are within the scope of the present invention.

In the following discussions, the implementation shown in FIG. 1A will be assumed (where the functionalities described herein are implemented by the EEP 104 executed on a client computer 102). However, it should be noted that this is done for simplicity and illustrative purposes only. The invention is not so limited. Given the teachings provided hereinafter, one of ordinary skill in the art can implement the invention in any/all of the arrangements described above with reference to FIGS. 1A and 1B.

Composite Email Description

A composite email may be thought of as a conglomeration of a plurality of individual emails. It is dynamically generated or composed when any one of the emails in an email conversation is accessed/opened. When generated, the composite email includes content/information automatically extracted from one or more of the individual emails in the email conversation. In one embodiment, a composite email is made up of a plurality of parts. These parts include a header portion, one or more text portions, a recipient list portion, a subject subheading portion, and an attachments portion.

The header portion is the part of a composite email that contains general information about the email conversation. In one embodiment, the header portion includes information indicating which participant started the email conversation and hence, is the administrator of the email conversation. This information may include, for example, an email address for the administrator, a user ID, etc. The header portion may also include a date and time at which the email conversation was started (e.g. date and time when an initial email for the email conversation was sent). The header portion may further include a subject for the email conversation. This subject sets forth the overall topic to be discussed in the email conversation. In one embodiment, once set, the information in the header portion cannot be changed.

The text portion is the part of a composite email that contains the text from a particular individual email. If an email conversation comprises a plurality of individual emails, then a composite email may have multiple text portions. For example, if an email conversation includes five individual emails, then the composite email for that email conversation may have five text portions, with each text portion showing the text from a corresponding one of the five individual emails.

The recipient list portion is the part of a composite email that sets forth the participants that are participating in the email conversation. In addition to listing the identifiers (e.g. email addresses) for the participants, the recipient list portion, in one embodiment, may also include other information, such as the authorities that have been given to each participant. For example, some participants may be granted the authority to send replies while others are only given the authority to view emails in the email conversation, some participants may be given the authority to add/amend subject subheadings, some participants may be granted the authority to be a co-administrator to enable those persons to perform some administrative tasks with regard to the email conversation, etc. In one embodiment, the administrator of an email conversation (i.e. the participant who sends out the initial email that starts the email conversation) is the person who sets these authorities. The recipient list and the authorities specified therein may be changed by the administrator and perhaps a co-administrator at a later time. Thus, the recipient list may evolve and change as the email conversation progresses.

The subject subheading (hereinafter, subheading for simplicity) portion is the part of a composite email that sets forth zero or more subheadings for an email conversation. As used herein, the term subheading refers to a sub topic under the general overall subject or topic of an email conversation. For example, if the general subject of the email conversation is “annual sales conference”, then a subheading may be “examine and compare city, hotel costs”, and another subheading may be “prepare conference agenda”. A subheading allows the discussion of the email conversation to be focused. An email conversation, as it progresses, may have multiple subheadings. As one subheading is fully discussed, another subheading may be added. For example, using the above subheadings, once a city and hotel have been selected, the email conversation can proceed to preparing a conference agenda. In one embodiment, multiple subheadings (e.g. all of the subheadings that have ever been added to the email conversation) may be included in a composite email. A subheading is optional, and can be added by a participant having the proper authority.

The attachments portion is the part of a composite email that sets forth the files that are attached to the email conversation. An email conversation may have zero or more attachments, and additional attachments may be added as the email conversation progresses.



Download full PDF for full patent description/claims.

Advertise on FreshPatents.com - Rates & Info


You can also Monitor Keywords and Search for tracking patents relating to this Mechanism for indicating unread emails in a container patent application.
###
monitor keywords



Keyword Monitor How KEYWORD MONITOR works... a FREE service from FreshPatents
1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored.
3. Each week you receive an email with patent applications related to your keywords.  
Start now! - Receive info on patent apps like Mechanism for indicating unread emails in a container or other areas of interest.
###


Previous Patent Application:
Graphical user interface display which differentiates among participants in a group conversation
Next Patent Application:
Authentication score quantifing similarity between a user's online persona versus that user's physical characteristics
Industry Class:
Data processing: presentation processing of document
Thank you for viewing the Mechanism for indicating unread emails in a container patent info.
- - - Apple patents, Boeing patents, Google patents, IBM patents, Jabil patents, Coca Cola patents, Motorola patents

Results in 0.93152 seconds


Other interesting Freshpatents.com categories:
QUALCOMM , Monsanto , Yahoo , Corning ,

###

Data source: patent applications published in the public domain by the United States Patent and Trademark Office (USPTO). Information published here is for research/educational purposes only. FreshPatents is not affiliated with the USPTO, assignee companies, inventors, law firms or other assignees. Patent applications, documents and images may contain trademarks of the respective companies/authors. FreshPatents is not responsible for the accuracy, validity or otherwise contents of these public document patent application filings. When possible a complete PDF is provided, however, in some cases the presented document/images is an abstract or sampling of the full patent application for display purposes. FreshPatents.com Terms/Support
-g2-0.3272
     SHARE
  
           


stats Patent Info
Application #
US 20120331398 A1
Publish Date
12/27/2012
Document #
13604357
File Date
09/05/2012
USPTO Class
715752
Other USPTO Classes
International Class
06F3/01
Drawings
8



Follow us on Twitter
twitter icon@FreshPatents