Electrical computers and digital processing systems: multicomput – Computer conferencing – Demand based messaging
Reexamination Certificate
2000-06-27
2003-04-08
Meky, Moustafa M. (Department: 2153)
Electrical computers and digital processing systems: multicomput
Computer conferencing
Demand based messaging
C345S215000
Reexamination Certificate
active
06546417
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to an electronic mail program. More particularly, the invention relates to an electronic mail program having a mailbox browser display which displays different icons for different types of mail item MIME types.
2. State of the Art
In recent years electronic mail (“email”) has become widely used in business, education, and in personal communications. One of the features of electronic mail which is most convenient, particularly in business and in education, is the ability to attach a binary computer file to an email message. This feature enables email correspondents to rapidly share word processing documents, database documents, spreadsheet documents, multimedia documents, or virtually any kind of binary file created by a computer. There are, however, some serious limitations and inconveniences associated with attaching a binary file to an email message.
The original Internet mail system as defined in 1982 with RFC (Request for Comments) 821 and 822 had a number of important limitations. In particular, the system was not designed to carry large quantities of arbitrary data in an email message. In fact, the 1982 SMTP (Simple Mail Transport Protocol) standard required that an email message consist of a single message containing only ASCII characters in lines of 1000 characters (blocks of 32 k) or less.
The ability to send binary data through the Internet electronic mail system was made possible with the MIME (Multipurpose Internet Mail Extensions) standard for Internet messages. The original MIME standard was published as an Internet Request For Comments document (RFC 1341) and approved in June of 1992. (See Internet RFCs 2045,2046, and 2047 for the latest MIME standards documents.) The MIME standard describes how an email message should be formatted in order to be considered MIME compliant. MIME defines a set of message header fields and a set of message encoding standards that are designed to overcome the limitations of RFC 822 message formats and still be transportable through any of the numerous legacy mail transport systems in use on the Internet. (See specifically, N. Freed and N. Borenstein,
Multipurpose Internet Mail Extensions
(
MIME
)
Part
1:
Format of Message Bodies,
Network Working Group, Request For Comments (RFC 2045) November 1996.) MIME message header fields extend those defined in RFC 822 and describe the content and encoding type of the email message. Encoding schemes allowed in the MIME standard include “quoted-printable”, and “base64”. In addition, three unencoded data types are allowed. These are labeled “8 bit”, “7 bit”, or “binary”. It should be noted that legacy gateways still do not handle binary data and nearly all MIME compliant messages encode binary data as “7 bit”, the default encoding for MIME.
Today MIME is implemented in all of the major electronic mail clients or “User Agents”, e.g. Microsoft Outlook and Outlook Express, Netscape Communicator, and Qualcomm Eudora. However, only a few MIME types including “text/plain”, “text/html”, “multipart/alternative”, and “multipart/mixed” can be handled by these programs. Probably the most important feature of the MIME standard that was that it allowed any binary data to be appropriately encoded and sent through the older SMTP system of mail gateways and exchanges. Mail client programs such as those listed above were modified to allow users to attach any type of file to a mail message. This was done by (a) including an appropriate encoding module to translate the binary data of an arbitrary file to an acceptable MIME encoding such as “7 bit” or “base64”, (b) expanding the Mail client's ability to handle messages with a MIME type set to “multipart”, and (c) including the file specified by a user as a part of the “multipart” message. For many years, mail client programs offered users only the two choices; they could send a simple text message (sent with “content-type=text/plain”) or they could attach any file to a simple text message (sent with “content-type=multipart/mixed”).
More recently the programs listed above have been extended to allow authors to use basic types of text formatting such as alternative fonts and styles by including these features in the mail client text editor and sending the message with a MIME type set to “text/html”. Today Microsoft's Outlook even allows a person to use Word, a full featured text editor, to author electronic mail messages by converting the Word file format to HTML before manually inserting it into the body of the mail message for sending. Nevertheless, mail client programs still rely exclusively on file attachments with message MIME types set to “multipart” for any other type of file format.
If the sender and the receiver of the email message with the attached binary file are using the same brand and version of email program and both programs are configured in substantially the same way, the receiver's email program should automatically apply the appropriate decoding to the attached binary file and produce a file which is identical to the file which was attached to the email by the sender. However, if the sender and receiver are using different email programs, the recipient may receive a file which must be decoded by the recipient using a separate decoding program.
Even after the file is properly received and decoded, it is often difficult for the receiver of the file to open the file. The receiver of the file might expect that “clicking” on the file icon will open the file. However, clicking on the file icon will often not open the file. It may result in an error message like “application not found” or, worse, it may result in the file being opened by an inappropriate application thereby displaying “gibberish”. The receiver of the file must have a program capable of reading (opening) the file. For example, if one attaches a spreadsheet file to an email message, the receiver of the file must have a spreadsheet program in order to open the file. Technically, it is not necessary that the receiver of the file have the same brand program as that which created the file. However, opening a file with a program which did not create it, though possible, can be very inconvenient. The receiver of the file must know what kind of file is attached to the email message, must know what program on their computer is capable of reading that type of file, must launch the program, must open the file from within the program, and wait while the program translates the file.
The limitations of Internet electronic mail can become even more frustrating if the sender and recipient are not using the same operating system (OS). Some mail attachment encoding schemes (and file compression schemes) are OS-dependent and it is possible that an email recipient could receive a file which is impossible to decode (or decompress).
These limitations in electronic mail have discouraged many people, particularly non-sophisticated computer users, from attaching files to electronic mail messages. In fact, for some novice users, the task of launching one application to create a document, saving the document, launching a separate email application to create an email message, and then locating the saved document for attachment to an email message is daunting enough to discourage them. In addition, novice users often complain that after “downloading” a file attached to an email message they cannot find the file on their hard disk.
Most email client software allows the user to sort items in the inbox by sender, subject, or date in order to locate more easily a particular mail item. In addition, most email client software indicates whether a particular message includes an attached file. This is indicated by an icon such as a paper clip icon or a generic document icon or a floppy disk icon, for example. However, the same icon is used regardless of the nature of the attachment and there is no way of knowing the nature of the attachment until the message is opened. Prior art
FIG. 1
shows an example of a typica
Gallagher Thomas A.
Gordon David P.
Intellinet, Inc.
Jacobson David S.
Meky Moustafa M.
LandOfFree
Enhanced electronic mail system including methods and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Enhanced electronic mail system including methods and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Enhanced electronic mail system including methods and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3093107