WO2001027828A2

WO2001027828A2 - Methods and apparatus for verifying the presence of intended email attachments

Info

Publication number: WO2001027828A2
Application number: PCT/US2000/027426
Authority: WO
Inventors: James D. Logan
Original assignee: Logan James D
Priority date: 1999-10-08
Filing date: 2000-10-02
Publication date: 2001-04-19
Also published as: AU7858000A; WO2001027828A3

Abstract

An email application program which executes on a host computer which transmits email messages includes routines for ensuring that email attachments which are intended to be transmitted with the email messages are actually attached at the time of transmission. The content of the email message is processed to determine if the character string including the letters 'attach' are imbedded within the text of the message composed by the sender. If those characters are present, but no file has been designated by the sender for attachment to the outgoing email message, a warning is issued to advise the sender that intended email messages may not have been designated.

Description

PCT Patent Specification

Title: Methods and Apparatus for Verifying Presence of Intended Email Attachments

Applicant and Inventor: Mr. James Logan

81 Castle Hill Road Windham, NH 03087

Technical Field

This invention relates to electronic mail systems and more particularly to methods and apparatus for ensuring that attachments to outgoing email messages are actually transmitted with such messages as intended by the sender.

Background Art

Under early Internet practices and standards, email transmissions were limited to character data using the ASCII character set. To make it possible to send other types of data, the MIME (Multi-purpose Internet Mail Extensions) standard, as well as other techniques, were adopted to extend the capabilities of email to transmit text in character sets other than US-ASCII, as well binary data, in multi-part messages which include "attachments." Using these techniques, files of data can be "attached" to outgoing messages, allowing the sender to send graphics files, spreadsheets, word processing documents, executable programs, and any other kind of file to a desired email destination. The software infrastructure used to send files as email attachments is largely hidden from the user. Email application programs such as Eudora, Netscape Messenger and Microsoft's Outlook Express provide menu functions which make it easy for a sender to identify one or more files which are to be attached to an outgoing message. Using such programs, a sender typically types the message body, indicates the email address of intended recipient(s) and, if desired, uses a convenient "dialog box" mechanism displayed by the application program to identify any additional files which are to be sent as attachments to the outgoing email message. All too often, however, in the course of providing destination email addresses, adding subject headings, and handling other distractions, the sender will simply forget to "attach" files which he or she intends to send along with the email message. Since the body of the message typically makes it clear that an attachment was to be sent by including a comment such as "I've attached a copy of our current business plan for your review," the recipient will typically be aware that an intended attachment was not included, but must send a reply message requesting that the attachment be provided in a new message. The failure to send intended attachments leads, at best, to undesirable delays which can have serious consequences when rapid communication of key information is important.

Summary of the Present Invention

It is an object of the present invention to help ensure that email attachments are in fact attached to the email messages they are intended to accompany.

In a principal aspect, the present invention takes the form of methods and apparatus for scanning the text of an outgoing email message to identify character strings such as "attached," "attaching," and "attachment" which tend to detect the probable intent by the user to include an attachment with the email message. If no attachment has in fact been identified for inclusion within an outgoing message that includes such text, the sender is informed by a suitable warning display or like before the email message is sent, affording the sender the opportunity to correct the deficiency by adding the intended attachment, so that the complete message and the desired attachment(s) are transmitted as intended.

The preferred embodiment of the invention takes the form of an email messaging system in which a first host computer operates as an email message source, a second host computer which operates as an email message destination, and a communications network such as the Internet provides a data pathway between said first and second computers. An email application program executes on said first host computer for transmitting email messages via said communications network to said second host computer. A first routine executable under the control of the application program accepts the text of an outgoing email message from a user. A second routine executable under the control application program before the message is sent allows the user to designate the filename of at least one file accessible to the first computer which is to be transmitted as an attachment to the text of the outgoing email message. A third routine executable under the control of the application program before the outgoing message is sent processes the message text entered by the user to identify the presence of character strings in said text, such as " attaching," "attached," or "attachment" ," which tend to indicate that said user intended to (but may have failed to) designate at least one file as an attachment. A fourth routine executable under the control of said application program before the outgoing message is sent generates a warning to the user when the third routine indicates that said user intended to designate at least one file as an attachment when said second routine has not been performed at least once to actually designate the intended attachment file. Preferably, a fifth routine which is also executable under the control of said application program prior to the transmission of the outgoing file generates a special warning to the user when said third routine indicates that two or more files were intended to be attached (by searching for the character string "attachments") and when less than two files were in fact attached by the execution of the second routine.

Brief Description of the Drawings

Fig. 1 is a flowchart illustrating the operation of a preferred embodiment of the invention.

Detailed Description

The present invention operates in a conventional Internet email environment and includes software routines that execute in combination with conventional email application programs which conform to and implement SMTP, the "Simple Mail Transfer Protocol."

SMTP is the de facto standard for electronic mail transport across the Internet. When an e-mail message is sent, SMTP packages the message in an electronic envelope and relays it to its destination. SMTP was introduced in a series of Request for Comment documents (RFCs) which are available from many sources on the Internet, notably RFC 772, 780, and 788, with the base specification appearing in RFC 821 issued in 1982. Work continued on SMTP, however, and over the years its capabilities have been significantly enhanced. Important RFCs that cover extensions or otherwise discuss SMTP include: RFC 974: Mail Routing and the Domain System; RFC 1123: Requirements for Internet Hosts ~ Application and Support; RFC 1869: SMTP Service Extensions; and RFC 1870: SMTP Service Extension for Message Size Declaration.

RFC 822 defined a message representation protocol specifying the format of message headers expressed in the US-ASCII character set, but left the message content, or message body, as flat US-ASCII text. RFCs 2045 through 2049 contain the current standards collectively called the Multipurpose Internet Mail Extensions," or MIME, which extends the format specification of email messages to allow for textual message bodies in character sets other than US-ASCII, an extensible set of different formats for non-textual message bodies, multi-part message bodies, and textual header information in character sets other than US- ASCII. MIME governs the preferred way in which attachments are represented within the content of an SMTP message body, but other attachment representations are sometimes used, including UUencode (Unix to Unix encoding) and numerous other attachment representations. For present purposes, however, MIME encoding may be taken as illustrative. MIME messages have a four part header for each part of the email: a MIME-Version header field, a Content-Type header field, a Content-Transfer-Encoding header field, and two additional header fields used to further describe the data in a body. A MIME message attachment in the body of an SMTP message is illustrated by below::

10606_E5F645E

Content-Type: image/jpeg; name="sailsBG. jpg" Content-Transfer-Encoding: base64

Content-Disposition: inline; filename="sailsBG. jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBk SEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQ kJCQwLDBgNDRgylRwh

The scrambled characters seen in at the end of the example message text quoted above are the printable character representations of the base64 encoded binary information which form the content of the attached file (in this case, a binary image file which named "salesBG.jpg"). It is important to note that, even though the attachment itself is unreadable to humans, the existence and nature of the attachment as part of the message is readily apparent from the header information which, in accordance with the MIME specification, allows the content to be decoded into its original form and saved as a persistently stored named file by the SMTP application that receives the incoming message. The present invention preferably operates in cooperation with an SMTP compliant email application program which executes on the host computer from which email transmissions are sent. Such programs typically include text entry and editing routines which permit the user to compose natural language text to be included in the body of an outgoing message, and to enter the email address(es) of intended recipients. Such email application programs also typically includes menu-activated routines which prompt the user to enter filenames, or browse the file directories of the host computer to identify the filenames, of one or more persistently-stored data files, the content of which is to be included as "attachment" data using the available mail protocol, such as those specified by the SMTP MIME extensions. The application program then combines the text of the body of the message with an encoded version of the attachment file or files in accordance with the specifications of the MIME protocol, or whatever other protocol is use for the transmission of message and attachments.

As contemplated by the invention, when the user completes the text of the message and has designated a subject for the message and the email addresses of the recipients, and has further designated all of the files to be attached to the message, the user typically issues a "send" command to the application program, typically by clicking on a "send button" displayed by the application program's graphical user interface. This command to send the message along with any designated attachments triggers the operation of the routines contemplated by the invention which are illustrated by the flow chart appearing in Fig. 1 of the drawings. In response to the depression of the send button (or some equivalent command to transmit the message) as indicated at 11 , routines are executed which issue a warning when it is likely that the user has failed to designate intended attachments. It should be understood that these routines can be executed at any time prior to transmission, but are most advantageously performed when the user has indicated, in some fashion, that the message is ready for transmission. In environments in which messages are first composed and then saved for later transmission (when, for example, the user later establishes dial-up connection with an SMTP server), the application's "send button" or the equivalent in fact indicates an instruction to save the file for later transmission. It is preferable that the routines to be described be performed as soon as the user indicates that the message is believed to be ready for transmission. It is preferable to check the presence of intended attachments as soon as message composition is completed, when the intended content of the message (and the identity of files to be attached) is fresh in the mind of the user; however, it will be understood that missing attachments can be checked at any time prior to actual message transmission.

In the illustrative embodiment depicted in Fig. 1 , before the message is transmitted a test is performed at 13 to determine if at least one attachment has been designated. When this test is implemented as part of the application program, one or more variables set during the course of designating attached files which are within the address space of and visible to the application program may be readily inspected to determine the number of filenames designated as attachments to the subject message by the user.

If no attachments have been designated, the routine at 15 is performed to scan the message text entered by the user of the application program to identify the presence of terms (character strings) which indicate an intent to include attachments with the message. Commonly, when attachments are included with a message, the nature of the attachments is explained in the body of the message using statements such as "I am attaching an Excel spreadsheet ...", "The minutes of the meeting are attached . . .", "Attachment: January business plan", "The four files included as attachments to this message are: ..." Thus, a case- insensitive search for the character string " attach" (six letters with a leading space) as indicated at 15 would successfully identify any of the phrases noted above and thus indicate the user's intent to designate attachment files as part of the outgoing message.

If the character string " attach" was not found in the search at 15, the routine branches at 17 to direct the application program to send the message (or to place the message in a queue for future transmission) as indicated at 20. If the character string " attach" was found when no files have been designated, the program branches at 17 to issue a warning at 19 informing the sender that attachment files have not yet been designated. If desired, a portion of the message text which included the string " attach" might be repeated in a warning message display to indicate to the user the basis upon which the automatic warning was being generated.

The search, test and warning at 15, 17 and 19 do not properly account for an intent to attach more than one file when only one file is attached. This situation is handled by the test at 23 in combination with the test at 13 which causes a search to be performed at 25 for the string "attachments". If that search indicates that more than one attachments may have been intended to be designated, when only one file has been designated, a branch is performed at 27 to execute a routine for issuing a warning at 29 indicating that more than one attachments may be required. It may be noted that the search at 25 may be expanded to include a search for some form of" attach" in combination with the term "files" to identify phrases like "I have attached three files" which would not be identified by a search for "attachments". It is to be understood that the embodiment of the invention which has been described is merely illustrative of one application of the principles of the invention. Numerous modifications may be made by those skilled in the art to the implementations disclosed above without departing from the true spirit and scope of the invention.

Claims

What is claimed is:

1. The method for ensuring that an attachment, which a sender intends to transmit along with the text of an outgoing email message, is actually transmitted with said outgoing message, said method comprising, in combination, the steps of: prior to the transmission of said message, determining whether the sender of said message has designated a file as an attachment to be sent with said message, prior to the transmission of said message, processing the text of said message to identify the presence within said text of a character string indicating a likelihood that said sender intended to transmit one or more files as attachments to said message, and prior to the transmission of said message, producing a warning indication perceptible by said sender when said sender has failed to designate said file when said character string is identified in said text.

2. The method set forth in claim 1 wherein said step of processing the text of said message includes performing a case-insensitive search of at least a portion of said text for a character string including the characters "attach".

3. The method set forth in claim 1 wherein said outgoing message is generated with the aid of an email application program which includes means for enabling said sender to designate said file and wherein said step of determining whether the sender of said message has designated a file includes the step of evaluating a variable set by said application program when a file is designated as an attachment to an outgoing email message.

4. The method set forth in claim 1 wherein said step of determining whether the sender of said message has designated a file consists of processing the content of said message to identify data therein which indicates the presence of at least one attachment.

5. An email messaging system comprising, in combination, a first host computer which operates an email message source, a second host computer which operates as an email message destination, a communications network which provides a data pathway between said first and second computers, an message transmitting application program which executes on said first host computer for transmitting email messages via said communications network to said second host computer, a first routine executable under the control of said application program for accepting the text of an outgoing email message from a user, a second routine executable under the control of said application program for accepting from said user a designation of the name of at least one file accessible to said first computer which is to be transmitted as an attachment to said outgoing email message, a third routine executable under the control of said application program for processing said text to identify the presence of character strings in said text tending to indicate that said user intended to designate at least one file as an attachment to said outgoing message, and a fourth routine executable under the control of said application program for generating a warning to said user when said third routine indicates that said user intended to designate at least one file as an attachment when said second routine has not been performed at least once for said outgoing message.

6. An email messaging system as set forth in claim 5 wherein one of said character strings includes the letters "attach".

7. An email messaging system as set forth in claim 5 further including a fifth routine executable under the control of said application program for generating a warning to said user when said third routine indicates that said user intended to designate more than one file as an attachment when said second routine has not been performed at least twice for said outgoing message