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


Advertise Here
Promote your product, service and ideas.

    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.

Your Message Here

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.

In one embodiment, each of these parts of a composite email has the unique identifier of the email conversation associated therewith. This enables the various parts to be associated with the email conversation. This is noteworthy because, in one embodiment, each of these parts is treated separately, and is sent as a separate email. To illustrate this point, reference will be made to the following example.

Suppose that a participant starts an email conversation by preparing an initial email. Suppose that the participant (who is the administrator for this email conversation) includes in this initial email: (1) header information for the email conversation; (2) a text message; (3) a recipient list setting forth the participants for the email conversation; (4) a subheading specifying a first subtopic to be discussed; and (5) an attachment that includes one file. This initial email would also include a unique identifier. In one embodiment, when this initial email is sent out to the participants, it is actually sent out as five separate emails, with one email containing the header information, another email containing the text message, another email containing the recipient list, another email containing the first subheading, and another email containing the attachment. Each of these emails would have the unique identifier associated therewith. When one of the participants receives this initial email, that participant would actually receive five separate emails. When that participant opens any one of the five emails, all five of the emails are opened, and a composite email is generated. This composite email would include a header portion containing the header information for the email conversation, a text portion containing the text message from the administrator, a recipient list portion containing the recipient list, a subheading portion containing the subheading, and an attachments portion containing the attached file (or some information pertaining to the attached file). Thus, the composite email comprises information extracted from each of these individual emails.

In one embodiment, when a participant replies to an email in the email conversation, one or more emails may be sent, depending on what was added/changed by that participant. For example, suppose that a participant does not make any changes to the recipient list, does not add a subheading, and does not add any attachments, but rather simply types in a new text message. In such a case, only one text email containing the new text message would be sent to the other participants in the email conversation (this text email would have the unique identifier associated therewith). Since none of the other parts were updated, there is no need to send any other emails. When another participant (e.g. the administrator) opens this new text email, a composite email is generated. This composite email would include all of the information in the initial email (e.g. header information for the email conversation, administrator\'s text message, recipient list, subheading, and attachment). In addition, it would include an additional text portion, which would contain the text of the new email.

Suppose now that a participant adds another subheading to the email conversation (assuming that that participant has the authority to do so) and a new attachment. In such a case, another subheading email and another attachment email would be sent out to the participants of the email conversation (both of these emails would have the unique identifier associated therewith). When another participant (e.g. the administrator) opens either of these emails, a composite email is generated. This composite email would include all of the information sent thus far (e.g. header information for the email conversation, administrator\'s text message, new text message, recipient list, subheading, and attachment). In addition, it would include an additional subheading, which would contain the text of the new subheading, and the new attachment. In one embodiment, a composite email includes all of the subheadings and all of the attachments that have been added to an email conversation thus far.

Suppose further that a participant (e.g. the administrator) alters the recipient list to add a participant, remove a participant, change the authorities given to one or more participants, etc. In such a case, another recipient list email would be sent out (this email would have the unique identifier associated therewith). When another participant opens this new recipient list email, a composite email is generated. This composite email would include most of the information sent thus far (e.g. header information for the email conversation, administrator\'s text message, new text message, two subheadings, and two attachments). However, instead of the initial recipient list, the composite email would include the new recipient list. In one embodiment, only the most recent recipient list is included in a composite email.

As described above, in one embodiment, each of the parts of a composite email is handled separately, and each is augmented/updated via separate emails (exception: in one embodiment, the header portion cannot be augmented or updated). Each of these emails carries the unique identifier of the email conversation to enable them to be associated with the email conversation. In one embodiment, in addition to carrying the unique identifier, each email (other than the header email) also carries a sub-identifier. The sub-identifier contains information that can be used to uniquely identify each individual email, to distinguish the different types of emails (text, recipient list, subheading, attachment), as well as to provide other useful information.

In one embodiment, a text sub-identifier is included with each text email. In one embodiment, a text sub-identifier comprises an email identifier (e.g. an email address or user ID) for the participant who created and sent that text email, a date and time code, and a sequential counter. In the context of this sub-identifier, the sequential counter indicates how many text emails have been sent by this participant in this email conversation. Thus, if this participant has created and sent two text emails in this email conversation, then the sequential counter value for the first text email would be one, and the sequential counter value for the second text email would be two. The next text email sent by this participant would have a sequential counter value of three. In one embodiment, this sequential counter is maintained separately for each participant. Thus, if another participant has created and sent two text emails in this email conversation, then the sequential counter value for the first text email sent by that participant would be one, and the sequential counter value for the second text email would be two. The above discussion sets forth just one possible method for generating a text sub-identifier. Other methods may be used if so desired. All such methods are within the scope of the present invention.

In one embodiment, a recipient list sub-identifier is included with each recipient list email. In one embodiment, a recipient list sub-identifier comprises a text string (e.g. “recipientlist”) indicating that the sub-identifier is a recipient list sub-identifier. The sub-identifier may further include an email identifier (e.g. an email address or user ID) for the participant (presumably the administrator or a co-administrator) who created/updated the recipient list that is contained in the recipient list email. The sub-identifier may further include a date and time code and a sequential counter. In the context of this sub-identifier, the sequential counter indicates how many recipient list emails have been sent by this participant in this email conversation. Thus, if this participant has created and sent two recipient list emails in this email conversation, then the sequential counter value for the first recipient list email would be one, and the sequential counter value for the second recipient list email would be two. In one embodiment, this sequential counter is maintained separately for each participant. Thus, if another participant has created and sent two recipient list emails in this email conversation, then the sequential counter value for the first recipient list email sent by that participant would be one, and the sequential counter value for the second recipient list email would be two. The above discussion sets forth just one possible method for generating a recipient list sub-identifier. Other methods may be used if so desired. All such methods are within the scope of the present invention.

In one embodiment, a subheading sub-identifier is included with each subheading email. In one embodiment, a subheading sub-identifier comprises a text string (e.g. “subheading”) indicating that the sub-identifier is a subheading sub-identifier. The sub-identifier may further include an email identifier (e.g. an email address or user ID) for the participant who is adding/updating the subheading that is contained in the subheading email. The sub-identifier may further include a date and time code and a sequential counter. In the context of this sub-identifier, the sequential counter indicates how many subheading emails have been sent by this participant in this email conversation. Thus, if this participant has created and sent two subheading emails in this email conversation, then the sequential counter value for the first subheading email would be one, and the sequential counter value for the second subheading email would be two. In one embodiment, this sequential counter is maintained separately for each participant. Thus, if another participant has created and sent two subheading emails in this email conversation, then the sequential counter value for the first subheading email sent by that participant would be one, and the sequential counter value for the second subheading email would be two. The above discussion sets forth just one possible method for generating a subheading sub-identifier. Other methods may be used if so desired. All such methods are within the scope of the present invention.

In one embodiment, an attachment sub-identifier is included with each attachment email. In one embodiment, an attachment sub-identifier comprises a text string (e.g. “attachment”) indicating that the sub-identifier is an attachment sub-identifier. The sub-identifier may further include an email identifier (e.g. an email address or user ID) for the participant who is adding the attachment that is contained in the attachment email. The sub-identifier may further include a date and time code and a sequential counter. In the context of this sub-identifier, the sequential counter indicates how many attachment emails have been sent by this participant in this email conversation. Thus, if this participant has created and sent two attachment emails in this email conversation, then the sequential counter value for the first attachment email would be one, and the sequential counter value for the second attachment email would be two. In one embodiment, this sequential counter is maintained separately for each participant. Thus, if another participant has created and sent two attachment emails in this email conversation, then the sequential counter value for the first attachment email sent by that participant would be one, and the sequential counter value for the second attachment email would be two. The above discussion sets forth just one possible method for generating an attachment sub-identifier. Other methods may be used if so desired. All such methods are within the scope of the present invention.

As will be described in greater detail in a later section, the sequential counter values in the various sub-identifiers may be used to determine whether one or more emails in an email conversation have been lost. For example, if the text sub-identifiers for several text emails sent by the same participant indicate that only text emails having sequence numbers one and three were received, then it is known that the text email sent by that participant having the sequence number two was lost. As will be described in greater detail in a later section, once an email is discovered to have been lost, it can be resent. Thus, lost emails in an email conversation can be recovered.

In the embodiment described above, each sub-identifier includes an indication of an email type (for example, the subheading sub-identifier comprises the text string “subheading”, the recipient list sub-identifier comprises the text string “recipientlist”, etc.). The absence of any text string in the text sub-identifier implies that it is a text type of email. The sub-identifier also includes a sequential counter value that indicates how many emails of that type have been sent by this participant in this email conversation. These two sets of information are useful in an embodiment where there are different types of emails, as in the embodiment described above. In another embodiment, there may be only one type of email that is exchanged in an email conversation (e.g. the different parts of a composite email may not be separated out into separate emails but rather may be consolidated in a single email). In an embodiment where there is only one type of email, the sub-identifier need not include an indication of email type. Instead, the sub-identifier for an email may comprise just an email identifier (e.g. an email address or user ID) for the participant who sent the email, a date and time code, and a sequential counter. In this embodiment, the sequential counter would indicate how many emails have been sent by this participant in this email conversation (the sequential counter would no longer reflect how many emails of a particular type have been sent by this participant in this email conversation). This and other embodiments are within the scope of the present invention.

Administrator and Participant Authority

The participant who creates the initial email in an email conversation is the administrator of that email conversation. As an administrator, this person has certain default powers related to the email conversation, examples being:

1. Ability to generate and modify the subject subheadings; 2. Ability to change any of the authorities or restrictions set for a participant; 3. Ability to add or remove a participant; 4. Ability to re-send an email, or part of it, using the automatic re-send function (described more fully herein as an automated side mail), or re-send an attachment to a participant who may not have received it or may have difficulty opening an attachment; 5. Ability to partially archive the email conversation for all participants, described more fully herein; 6. Ability to set limits on data entry; for example, setting limits on the entry of text or on parameters of the text (such as number of words, characters or lines) permitted in certain areas such as the subject subheading portion and the text message area; 7. Ability to create fields within which recipients may enter data and send the fields out as replies, which can then be used to create a database for data processing and reporting; 8. Ability to receive data back from every participant, recording the date and time the email was opened, and the date and time the email was replied. The data may also indicate other status items, such as: email not opened and email not replied to. This returned information can be used to prepare a set of status reports, including when the recipients opened their emails and when they sent replies out. These status reports can be viewed in a display on screen, printed, emailed, and exported as an output file in a format used by other software, and are described more fully herein. 9. Ability to allow or disallow the sending of an attachment; 10. Ability to allow or disallow private side mails, described more fully herein, to be sent to any participant. According to an embodiment, automated side mails used for replacing individual emails, subheadings, or attachments not received by a recipient are always permitted; 11. Ability to restrict the reply function to permit replies only to selected users, such as the administrator and certain co-administrators.

In general, the purpose of establishing an administrator with designated powers over a particular email conversation mimics the duties, tasks, responsibilities and powers of a person chairing a meeting. In a meeting, it is the chairperson\'s responsibility to allow a free flow of ideas and views in an orderly manner, keeping to the agenda and subject on hand, and preventing chaos. Thus, the administrator of an email conversation sets an agenda, provides a focus to the discussion by modifying the subheading being discussed, prevents others from participating if their participation is uncalled for, and harnesses the exchange of views and attachments so that the purpose and agenda are achieved. This allows the administrator to provide a general direction and focus to the exchange of emails. The administrator may share some of the administrator functions and responsibilities with any of the recipients by designating them as co-administrators.

In general, the administrator of an email conversation may grant or restrict any authority to any of the participants of the email conversation. In one embodiment, however, certain administrator powers may not be delegated. For example, only the administrator may be able to nominate or designate a participant as a co-administrator, who in turn would not be allowed to nominate another co-administrator or remove himself from being a co-administrator. As another example, while a co-administrator is permitted to partially archive an email conversation, only an administrator can close an email conversation by fully archiving it, as described more fully herein.

Sample User Interface for Creating an Initial Email

FIG. 2 is a block diagram that illustrates a sample user interface provided by an EEP 104 (FIG. 1A) for enabling an administrator to create an initial email to start an email conversation. FIG. 2 shows five unpopulated panes 202-210. Pane 202 is provided to accommodate header information for the initial email and the email conversation overall. In the pane 202 illustrated in FIG. 2, the “FROM” field 212 contains the administrator\'s email identification (e.g. email address), which in one embodiment is generated and entered automatically. Pane 202 also comprises a “MAIN SUBJECT” field 214 in which the administrator may specify an overall main topic of discussion for the email conversation. Pane 202 may further comprise a “DATE & TIME SENT” field 216 reflecting the date and time the initial email is sent out. This information may be entered automatically at the time the initial email is sent.



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.91818 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.2433
Key IP Translations - Patent Translations

     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


Your Message Here(14K)



Follow us on Twitter
twitter icon@FreshPatents



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