The present invention relates generally to the field of electronic message transmission systems, and in particular to systems and methods for downloading and viewing images attached to a displayed document.
Email messaging is widely used for communicating information over the Internet. Besides the information in its message body, an email message often includes one or more image attachments that provide additional information related to the information in the message body. A recipient of the email message can download and view each image attachment separately. However, when an email message has many image attachments, the recipient has to repeat the tedious download and view operation many times, once for each image attachment. Therefore, there is a need for systems and methods that make it easier for a user to view all images attached to an email message.
A system for displaying multiple images associated with an electronic message displays an image viewing icon in conjunction with a display of the electronic message on a client computer's monitor. In response to a single user selection of the image viewing icon, the system downloads from a document storage system a single document containing all the associated images and displays the single document on the client computer's monitor.
The aforementioned aspects of the invention as well as additional aspects will be more clearly understood as a result of the following detailed description of the various embodiments of the invention when taken in conjunction with the drawings. Like reference numerals refer to corresponding parts throughout the several views of the drawings.
A client-server based email service system 100 as shown in
In one embodiment, user A at client 102-1 writes an email message 110 addressed to user B using a client application 103, the message including multiple attachments. The email message and its attachments are delivered to the servers 130 at which user B has an email account. The servers 130 notify user B, who logs into the servers 130 from the client 102-2, of the arrival of the email message 110. If user B is interested in the email message, he may download the message from the servers 130 to the client 102-2 and read the downloaded message through a client application 104, which may or may not be the same as the client application 103.
When the email message is downloaded to the client 102-2, its attachments are not downloaded together with the email message to reduce the traffic on the network 120. Instead, a download-all-attachments icon (235,
Sometimes, one or more attachments associated with an email message are images. A recipient of the email message may be only interested in viewing these images without storing a copy of them in a local disk drive. Alternatively, the recipient may prefer to view the images first before deciding whether to download any one of them to a user-specified destination. Accordingly, the email message displayed at a client includes a view-all-images icon (236,
In some embodiments, an email message having a plurality of image attachments may be displayed at a client along with a view-all-images icon (e.g., icon 236,
In particular,
Next, the email message is displayed by a client application on a computer monitor associated with the client computer. This procedure may include displaying the message body and other relevant information (202) and checking if the email message has multiple attachments (203). If true (203—Yes), the client application displays a download-all-attachments icon (204). If more than one of the attachments are images (205—Yes), the client application also displays a view-all-images icon (206). Alternately, the client application may display a view-all-images icon if the email message has one or more image attachments. Optionally, the client application may also display a document identifier for each individual attachment (205). In some embodiments, the email message is in the form of an HTML file and the client application is a web browser software. In some embodiments, when an email has more than one attachment the HTML file representing the email message includes a download-all-attachments icon, and that icon is automatically displayed (at 202) along with the email message when the HTML file is rendered for viewing. Similarly, in some embodiments, when an email has more than one image attachment, the HTML file representing the email message includes a view-all-images icon, and that icon is automatically displayed (at 202) along with the email message when the HTML file is rendered for viewing. In alternate embodiments, the HTML file may include a view-all-images icon when the email includes one or more image attachments. Further, in some embodiments the HTML file also includes a document identifier for each attachment and may include an individual download icon for each such attachment, all of which are automatically displayed (at 202) along with the email message when the HTML file is rendered for viewing. In such embodiments, operations 203 through 207 do not occur because the display operation at 202 subsumes these operations.
For each attachment associated with the email message, the email server may optionally create a document identifier (212). In some embodiments, if the email message has multiple attachments (213—Yes), the email server creates a download-all-attachments icon for the email message (214). If more than one of the attachments are images (215—Yes), the email server creates a view-all-images icon for the email message (216). In some alternate embodiments, the email server creates a view-all-images icon for the email message if at least one of the attachments is an image. Next, the email server associates with the email message (e.g., by inserting into a representation of the email message) the download-all-attachments icon and view-all-images icon (217) and, optionally, the document identifiers (218) and conveys the email message to the requesting client computer (219). As noted above, in some embodiments the email server may insert a view-all-images icon into the representation of an email message without inserting into the message a download-all-attachments icon.
In some embodiments, the email server is associated with a web server. The client request is first interpreted by the web server before reaching the email server and the email message created by the email server is converted into an HTML file by the web server before being delivered to the client computer. In some other embodiments, the email server assumes the functions performed by the web server. Therefore, it is able to directly process the client request, generate an HTML version of the requested email message and deliver the message to the requesting client computer.
In some embodiments, each document identifier includes a document type icon, the name and size of the attachment as well as a download icon. The selection of any download icon sends to the email server a download request for that particular attachment.
Illustratively, the first two attachments are images, each having a view icon. When a user clicks the view icon associated with the image entitled “Attachment 1”, the client computer sends a request to the email server to download the image. In response to each user selection of a view icon, the email server sends back the image itself or a document containing the image to the client computer. A pop-up window then appears on the client computer, displaying the image to the user. The third attachment in this example is a non-image document, represented by a document identifier 239 that has a download icon, but no view icon. To view the content of this attachment, a user has to download it from the email server.
In addition, the displayed email message may optionally include links (e.g., HTML link tags) to several other email-supporting utilities 230, 231 and 240. In various embodiments these utilities may be located on the client, the email server, or some utilities may be located on the client while others are located on the email server.
As mentioned above, for a user interested in viewing all the images attached to an email message, a single user selection of the view-all-images icon is more efficient and convenient than repeated selections of the view icon associated with each individual image.
In some embodiments, the single document delivered by the email server is an HTML file. The HTML file includes a list of HTML image tags, each referencing one image, and other structural elements. For example, when an email message has two attached images, Image1.jpg and Image2.jpg, the HTML file comprising the single document may include the following set of HTML information:
In this example, the two image tags contain identifiers, “Image1identifier” and “Image2identifier”, that reference the image files attached to the email message. The images referenced by the image tags may be located on an email server, or on storage devices associated with the email server. A web browser on the client computer is used for rendering the HTML file. For each referenced image in the HTML file, the web browser submits a document fetching request to download the image from the email server or other server at which the image is stored. After the HTML file is rendered on the client computer's monitor by the web browser, the user may save a displayed image to a disk storage location, for example by right clicking on the image and specifying the location at which the image is to be stored.
Sometimes, the user may prefer to download all three attachments to a user-specified location in a user-specified format. Of course, the user may download the three attachments separately by clicking on each individual download icon, once for each attachment. For each download session, the user needs to specify a location in the client computer for storing the downloaded attachment. Alternatively, the user may attain the same result in a more straightforward fashion by clicking on the download-all-attachments icon associated with the displayed email message. As described in more detail below, a single user click on the download-all-attachments icon initiates the downloading of all attachments to the email message. Clicking on the download-all-attachments icon is also herein called user selection of the download-all-attachments icon.
In some embodiments, there are two download formats, “compressed” and “uncompressed”. The “compressed” format may include multiple data compression schemes, e.g., some schemes designed for text compression and some schemes designed for image compression. In some embodiments, the user is allowed to choose different compression schemes for different types of documents. An “uncompressed” format may be selected by the user for storing all the attachments into a file folder. Since compressed files are typically smaller than the “uncompressed” files, downloading email attachments as compressed files requires less time and network bandwidth than downloading the attachments as uncompressed files. On the other hand, when downloading compressed files, the user must have access to additional decompression utilities to restore the attachments to their original uncompressed format before viewing them. In some embodiments, the user does not need to specify a file download format and location, and instead the attachments are downloaded in a default or previously identified format to a default or previously identified location.
After user selection of the download-all-attachments icon, and optionally after user selection of a download location and/or a download file format, the client computer submits to the email server a document fetching request for downloading all attachments (402) and waits for the email server to deliver the downloaded attachments (403). Finally, the client computer stores the downloaded attachments at a location designated by the user (or optionally at a default or previously identified location) (404).
In some embodiments, at 401 the user specifies one or more applications or printers as destinations for the downloaded attachments. For example, if the downloaded attachments are two uncompressed documents, one in PDF format and the other in MS-WORD format, the user may directly specify that the two documents are to be opened by their respective application programs on the client computer. In some other embodiments, the user may specify that each attachment is to be directly submitted to a default printer or to a user specified printer and printed out by a respective printer driver on the printer. In these embodiments, at 404 the client computer directs each attachment to a respective application or printer driver.
In some embodiments, if the user clicks the OK button, another window 430 pops up, prompting the user to specify a location in the client computer to store the ZIP file. In the example shown in
It is apparent to one skilled in the art that the aforementioned client- and server-side operations as well as schematic screenshots are only for illustrative purposes. Some of the operations described above may be executed in a different order. Some of the operations described above are optional, and thus not included in some embodiments, and some embodiments may include additional operations.
In some embodiments, the email server engine 520 further comprises:
Each of the above identified modules or programs corresponds to a set of instructions for performing a function described above. These modules and programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures or modules, and thus various subsets of these modules may be combined or otherwise re-arranged in various embodiments. In some embodiments, memory 512 may store a subset of the modules and data structures identified above. Furthermore, memory 512 may store additional modules and data structures not described above.
Although
Each of the above identified modules and applications corresponds to a set of instructions for performing one or more functions described above. These modules (i.e., sets of instructions) need not be implemented as separate software programs, procedures or modules, and thus various subsets of these modules may be combined or otherwise re-arranged in various embodiments. In some embodiments, memory 612 may store a subset of the modules and applications identified above. Furthermore, memory 612 may store additional modules, applications and data structures not described above.
Although some of various drawings discussed above illustrate a number of logical stages in a particular order, stages which are not order-dependent may be reordered and other stages may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be obvious to one ordinary skill in the art and so do not present an exhaustive list of alternatives. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof.
The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings.
This application is a continuation of U.S. patent application Ser. No. 11/066,811, filed Feb. 25, 2005, which is incorporated herein by reference in its entirety.
Number | Name | Date | Kind |
---|---|---|---|
5208748 | Flores et al. | May 1993 | A |
5216603 | Flores et al. | Jun 1993 | A |
5613108 | Morikawa | Mar 1997 | A |
5734837 | Flores et al. | Mar 1998 | A |
5948058 | Kudoh et al. | Sep 1999 | A |
6092114 | Shaffer et al. | Jul 2000 | A |
6185551 | Birrell et al. | Feb 2001 | B1 |
6188405 | Czerwinski et al. | Feb 2001 | B1 |
6839741 | Tsai | Jan 2005 | B1 |
7028075 | Morris | Apr 2006 | B2 |
7099860 | Liu | Aug 2006 | B1 |
7693866 | Weaver et al. | Apr 2010 | B1 |
7809383 | Rybak et al. | Oct 2010 | B2 |
20020016818 | Kirani et al. | Feb 2002 | A1 |
20020059347 | Shaffer et al. | May 2002 | A1 |
20020059383 | Katsuda | May 2002 | A1 |
20020120701 | Ohba | Aug 2002 | A1 |
20030009528 | Sharif | Jan 2003 | A1 |
20030055907 | Stiers | Mar 2003 | A1 |
20030084106 | Erev et al. | May 2003 | A1 |
20030101413 | Klein et al. | May 2003 | A1 |
20030182331 | Demsky et al. | Sep 2003 | A1 |
20030208546 | DeSalvo et al. | Nov 2003 | A1 |
20030233419 | Beringer | Dec 2003 | A1 |
20030234953 | Dawson et al. | Dec 2003 | A1 |
20040066421 | Kameyama | Apr 2004 | A1 |
20040133564 | Gross et al. | Jul 2004 | A1 |
20040143564 | Gross et al. | Jul 2004 | A1 |
20040143569 | Gross et al. | Jul 2004 | A1 |
20040143650 | Wollowitz | Jul 2004 | A1 |
20040158340 | Fischer et al. | Aug 2004 | A1 |
20040158607 | Coppinger et al. | Aug 2004 | A1 |
20040172451 | Biggs et al. | Sep 2004 | A1 |
20040210845 | Paul et al. | Oct 2004 | A1 |
20040215696 | Fisher et al. | Oct 2004 | A1 |
20050144241 | Stata et al. | Jun 2005 | A1 |
20060031336 | Friedman | Feb 2006 | A1 |
20060075046 | Yozell-Epstein et al. | Apr 2006 | A1 |
20060117019 | Sylthe et al. | Jun 2006 | A1 |
20060133340 | Rybak et al. | Jun 2006 | A1 |
20060136420 | Gandhi et al. | Jun 2006 | A1 |
20060167940 | Colton et al. | Jul 2006 | A1 |
20060168543 | Zaner-Godsey | Jul 2006 | A1 |
20070061308 | Hartwell et al. | Mar 2007 | A1 |
20070091746 | Brunet et al. | Apr 2007 | A1 |
20080005247 | Khoo | Jan 2008 | A9 |
Number | Date | Country |
---|---|---|
WO 0023931 | Apr 2000 | WO |
Entry |
---|
Bellotti, V et al., (2003), “Taking Email to Task: the design and evaluation of a task management centered email tool.” In Conference Proceedings on Human Factors in Computing Systems (CHI2003), Apr. 5-10, 2003, Fort Lauderdale, Florida, pp. 345-352. |
Bellotti, V. et al., “Taskmaster: recasting email as task management,” PARC, CSCW '02 Workshop on Redesigning Email for the 21st Century, 2002, 5 pages. |
Comer, D. and Peterson, L., “Conversation-Based Mail,” ACM Transactions on Computer Systems (TOCS) vol. 4, Issue 4, Nov. 1986, pp. 299-319. |
Flores, F. et al., “Computer Systems and the design of organizational interaction,” ACM Transactions on Information Systems., (1988), pp. 153-172. |
Shepherd, A. et al., “Strudel—an extensible electronic conversation toolkit,” Proceedings of the 1990 ACM Conference on Computer-supported Cooperative Work, Los Angeles, California, United States, pp. 93-104. |
Venolia, G., et al., “Supporting Email Workflow, ”Technical Report MSR-TR-2001-88, Microsoft Corporation, Sep. 2001, 10 pages. |
Winograd, T., (1987), “A language/action perspective on the design of cooperative work,” Human-Computer Interaction, vol. 3 No. 1, pp. 3-30, (1987-1988). Earlier version presented at the Conference on Computer-supported Cooperative Work, Austin, Dec. 1986, pp. 203-220. |
Winograd, T., “Where the Action is,” Byte, Dec. 1988, pp. 256A-260A. |
Zawinski, J., “Message Threading,” http://www.jwz.org/doc/threading.html, (1997-2000), pp. 1-9. |
Number | Date | Country | |
---|---|---|---|
20140040771 A1 | Feb 2014 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11066811 | Feb 2005 | US |
Child | 14047970 | US |