Patent Application
20070143425
The present invention relates generally to handling of document attachments in electronic mail systems, and more specifically to a system and method for providing version control for documents attached to electronic mail messages.
As it is generally known, electronic mail (“email”) software systems transmit messages and associated document attachments between computer system users over a communication network. Email systems are often architected in a client-server software model, in which client software is provided in end user computer systems to enable users to compose, send and receive messages, while a server software component is provided to perform various centralized functions. In most email systems, messages can be received on behalf of a user by a server computer system for later retrieval. For example, an email client application program on a local computer system may operate by periodically querying an associated email server system to determine if one or more new messages have arrived for a local user. If so, then the email client can provide an alert to the local user indicating the arrival of the new message or messages. The local user can then download the received messages from the server system to the local client computer system. Email requires an underlying messaging system, which provides a store and forward capability, such as the Internet's Simple Mail Transfer Protocol (SMTP). Well known existing email client systems include Microsoft®'s Outlook and Eudora®. The Web browser program may also used to provide the mail client by way of an Internet email service, such as services provided by Google, Yahoo, and other Web portal providers.
Typical email applications provide a user with a graphical user interface through which messages can be composed and sent, and through which received and previously sent messages can be viewed. A number of mailbox constructs are usually maintained for the user, including an Inbox to store received messages, an Outbox into which messages are put pending being sent, and a Sent mailbox for storing messages that have previously been transmitted. An email message usually includes or is associated with one or more destination addresses or user names identifying recipients to which the message is to be delivered, sometimes known as a “To:” field. A “From:” field is also included or associated with a message, and identifies the sender of the message. A “Subject:” field for an email message includes a text string defining the subject of the message. A message body stores the content of the message, including text, images, links, or other content. A number of separate documents may also be attached to a message before it is sent, containing additional content to that contained-within the message body. After the message body, destination email addresses, and any attachments to the message are defined by the user, a “Send” graphical button or the like can be clicked on or otherwise selected in order to cause the message to be sent.
When a message is received, the email client software provides a receiving user with the ability to reply to the received message, for example by way of a “Reply” and/or “Reply All” button within the graphical user interface. Clicking on the “Reply” button sets up a new message, including the received message, for editing and sending back to the original sender of the received message. Clicking on the “Reply All” button also sets up a new message, also including the received message, for editing and sending back to the original sender and any other recipients of the original message. A reply that is sent including all previous message information is sometimes referred to as a “reply with history”. The original sender, or any other recipient of a reply message, may then similarly generate another reply.
A series of received messages that are direct or indirect replies to an original “root” message may be referred to as a message “thread”. The reply messages in a thread may be considered child messages under the original root message. In addition to the reply messages, a thread may or may not be considered to also include the original root message. In an email system, a thread may consist of a number of related received messages stored in a user's Inbox, or another mailbox structure provided by the email system.
Some existing email systems have attempted to display message threads in a user friendly way by using what are referred to as “gathered” threads views. For example, in one type of gathered threads view, received messages belonging to a thread are represented using a single message entry in the user's Inbox. However, not all email users have such a view available to them, or prefer such a view, and accordingly “non-gathered” views remain common.
A problem with existing email systems occurs when a user accesses different versions of a document attachment, as may occur when an attachment is modified within a message thread. Email threads are often used to share document attachments among multiple users, such as during a review process for a specification document. Such a process may involve several iterations in which the document being reviewed is sent back and forth with different modifications. In existing systems, when an Inbox or Folder view is used that doesn't gather a thread through a gathered threads view, it may be difficult to find the most recently sent or received message in the thread, and even more difficult to find the latest version of an attached document sent back and forth within the thread. For example, if a user simply opens an email message without knowing if that message is the last message in the thread, the user may not be able to easily determine whether the document attached to that message is the most recent version of the document with regard to modifications made within the thread. This situation relates to the fact that many existing email systems attach a document to a message by carrying the document within the message, and allow modifications to the document attachment within the message.
For these reasons and others, it would be desirable to have a new system for handling email messages that enables a user to open any message in an email message thread and conveniently obtain a most recent version of any document attached to the message. The system should be operable to provide a most recent version of an attached document regardless of which message within the tread that the user has opened, including when the opened message is not the most recent message in the thread. Moreover, the new system should enable the user to alternatively open the version of the document that was originally attached to the opened message, even if that version is not the most recent version of the document.
To address the above described and other shortcomings of previous systems, a method and system for providing version control for documents attached to electronic mail messages is disclosed. In the disclosed system, a user's personal document library is used to store documents attached to the email messages the user sends and/or receives. Each time an attached document is transmitted or received within a message thread, a different version of the document is created and stored in the personal document library. The multiple document versions created allow the disclosed system to provide the user with the options of opening the most recent version of an attached document and/or opening the version of the attached document that is associated with the specific opened message.
In one embodiment, an API (Application Programming Interface) provided by the personal document library enables the user to request the most recent version of a document, or another specific version of the document can be indicated for opening. The disclosed system may be embodied to represent an attached document within an email message by using a URL (Uniform Resource Locator) that is stored within the message, where the stored URL points to the version of the attached document stored in the personal document library for that message.
In the disclosed system, the user's client email application is provided with access to the user's personal document library. The personal document library may be stored locally within the user's client computer system, and/or replicated on a server computer system. In the case where the personal document library is replicated onto a server computer system, the user could employ an email client provided through a Web browser and still obtain the benefits of the system.
Thus there is disclosed a new system for handling email messages that enables a user to open any message in an email message thread and conveniently obtain a most recent version of any document attached to the message. The disclosed system is operable to provide a most recent version of an attached document regardless of which message within the tread that the user has opened, including when the opened message is not the most recent message in the thread. The disclosed system also enables the user to alternatively open the version of the document that was originally attached to the opened message, even if that version is not the most recent version of the document.
In order to facilitate a fuller understanding of the present invention, reference is now made to the appended drawings. These drawings should not be construed as limiting the present invention, but are intended to be exemplary only.
As shown in
The email application program 12 executing on the client computer system 10 operates to send and receive email messages on behalf of the local user 20, and provides a graphical user interface, shown as the user interface 18, to the local user 20. The email application program 12 may, for example, be a client program that uses a messaging system based on a protocol such as the Simple Mail Transfer Protocol (SMTP) to send and receive email messages 40 to and from the other client computer systems 38, through the email application servers 36.
During operation of the email application 12, interface program logic 17 operates to store and retrieve documents that are attached to email messages 13 by using the personal document library 16. In this regard, the interface program logic 17 send commands 19 to the personal document library 16, through the application programming interface 18. The personal document library 16 processes the commands 19 and generates responses 21 to the interface program logic 17. The personal document library 16 is a document database or file system associated with the user 20, and supports storing and retrieving multiple versions of a document.
In one embodiment of the disclosed system, each document and/or version of a document stored in the personal document library 16 may be stored in association with a unique identifier of an email message thread, and/or in association with an identifier of a specific email message. In the illustrative personal document library 16 of
The personal document library 16 enables the email application program 12 to store a document attachment such that it can be retrieved based on the message to which it was attached. The personal document library 16 further enables the email application program 12 to determine a most recent version of a document with regard to a given message thread. For example, in one embodiment, the version of a document with the highest version number in a message thread might be considered to be the most recent version of the document in the thread.
At step 42, the disclosed system determines whether the document attached to the message detected at step 40 has been previously stored in the user's personal document library. The determination at step 40 may be based on the file name of the attached document, and/or other metadata associated with the attached document, together with the current contents of the personal document library. For example, if an attached document having a file name of Draft_Business_Plan.txt were processed at step 42, the email application program might issue a command to the personal document library to determine whether any versions of a document having that name have previously been stored in the personal document library. The determination at step 42 may further be message thread specific, in that a document may be considered to not have been previously stored in the personal document library if a version of the document has not been previously stored in association with the message thread to which the message detected at step 40 belongs.
If the disclosed system determines at step 42 that the document attached to the message detected at step 40 has not been previously stored in the personal document library, then at step 44 the document is stored in the personal document library in association with the message detected at step 40, and in association with the message thread to which the message detected at step 40 belongs. For example, the document may be stored in the personal document library together with a message identifier that identifies the message detected at step 40, as well as with a thread identifier identifying the message thread to which that message belongs. Otherwise, if the document attached to the message detected at step 40 has been previously stored in the personal document library, then at step 46 the disclosed system determines whether the document attached to the message detected at step 40 has been modified since it was last stored in the personal document library.
The determination at step 46 may be accomplished in a variety of specific ways. For example, in one embodiment, the email application program may include additional MIME (Multipurpose Internet Mail Extensions) headers within each email message having an attachment. The additional MIME headers contain metadata for the attached document that may be useful when determining whether the document has been modified since it was last stored. Such metadata contained in email messages having attached documents may, for example, include such information as an original version number of the document when it was first created by a local user and stored in the personal document library, a creation time and date, and/or a last modified time and date, or other information. Similar metadata may be stored in association with each of the document versions stored in the personal document library, and comparison of the metadata for a document attached to a received message to the metadata associated with a stored version of the document may enable a determination of whether the document attached to the received message has been modified since it was last stored in the personal document library.
If the disclosed system determines at step 46 that the document attached to the message detected at step 40 has not been modified since it was last stored in the personal document library, then there is no need to create a new version of the document. Accordingly, at step 48 the disclosed system associates the previously stored version of the document attached to the message detected at step 40 with the message detected at step 40, and with the message thread to which the message detected at step 40 belongs. If the disclosed system determines at step 46 that the document attached to the message detected at step 40 has been modified since it was last stored in the personal document library, then at step 50 a new version of the document is created in the personal document library, and used to store the modified document as attached to the message detected at step 40. The new version of the document is associated with the message detected at step 40 and with the message thread to which the message detected at step 40 belongs.
While the association of the stored document with the message and message thread performed in steps 44, 48 and 50 is described above as being based message thread and message identifiers stored in association with the document in the personal document library, the disclosed system is not limited to such an approach. Alternatively, the associations between documents stored in the personal document library and email messages to which they were attached, and to message threads to which such messages belong, may be maintained within the email application program. For example, on one such alternative embodiment, the email application program may operate by detaching the document from the email message to which it was attached, and store an pointer or other identifier of the document in the message that allows the document to be retrieved from the personal document library. Such a pointer may, for example, include a Uniform Resource Locator (URL), or the like, that points to the document as stored within the personal document library.
The received message list element 66 includes an indication 68 that the message has one or more attachments. The list element 66 is a clickable region, in that when the user clicks on the list element 66, the disclosed system presents a message user interface presenting the contents of and other information regarding the corresponding email message. In one possible embodiment, the attachment indication 68 can also be clicked on to cause the disclosed system to provide an attached document open interface directly from the inbox interface 60. While the indication 68 in
The message interface 70 further displays the text of an original message 80, to which the received message represented by the message interface 70 of
A first button 92 enables a user to open the version of the document that was received as an attachment to the current message. For example, the current message in the example of
In general, while the above description refers to embodiments of the disclosed system having specific arrangements of specific types of user interface components, such as buttons, fields, specific layouts, formats, etc., the present invention is not so limited. Accordingly, those skilled in the art will recognize that alternative embodiments may use various other specific types of user interface components, and/or various other arrangements of such components, in order to present information to and receive information from a user. Alternative embodiments may use any appropriate types of user interlace components that may be selectable by a user with a mouse user interface device, keyboard, or other equivalent devices, including but not limited to pull down menus, check boxes, and/or other types of user interface components.
Similarly, while for purposes of concise illustration
Those skilled in the art should readily appreciate that programs defining the functions of the present invention can be delivered to a computer in many forms; including, but not limited to: (a) information permanently stored on non-writable storage media (e.g. read only memory devices within a computer such as ROM or CD-ROM disks readable by a computer I/O attachment); (b) information alterably stored on writable storage media (e.g. floppy disks and hard drives); or (c) information conveyed to a computer through communication media for example using wireless, baseband signaling or broadband signaling techniques, including carrier wave signaling techniques, such as over computer or telephone networks via a modem.
While the invention is described through the above exemplary embodiments, it will be understood by those of ordinary skill in the art that modification to and variation of the illustrated embodiments may be made without departing from the inventive concepts herein disclosed. Moreover, while the preferred embodiments are described in connection with various illustrative program command structures, one skilled in the art will recognize that they may be embodied using a variety of specific command structures.
