WO2001050691A2

WO2001050691A2 - Sender-controlled post delivery handling of digitally delivered documents in a computer network

Info

Publication number: WO2001050691A2
Application number: PCT/US2000/035406
Authority: WO
Inventors: Jean-Christophe Bandini; Dmitry Dolinsky
Original assignee: Tumbleweed Communications Corp.
Priority date: 1999-12-30
Filing date: 2000-12-27
Publication date: 2001-07-12
Also published as: AU2293601A; WO2001050691A3

Abstract

The sender of a message (502) and any attached data files (614) through a computer network (108) can provide the recipient of such a message with a convenient mechanism for replying to the message. For the recipients's convenience, even if the recipient is not a registered user of the message delivery system of the server computer system (104), the sender can permit the recipient to use the same level of security (618) available to the sender and can allow the recipient to reply free of charge. IN addition, the sender can limit the service provided to the recipient with respect to number, addressing, size, formats, security (618) and priority (616) to thereby limit the charges which can accrue to the sender by the recipient's reply. The sender can also restrict post-delivery handling by selectively enabling local saving, printing, forwarding, and replying to the sender's message by any of the recipients of the message.

Description

SENDER-CONTROLLED POST DELIVERY HANDLING OF DIGITALLY DELIVERED DOCUMENTS

SPECIFICATION

FIELD OF THE INVENTION

The present invention relates to systems for controlling delivery of digital data through a computer network and, in particular, to a mechanism for allowing a sender of such digital data to specify ways in which such digital data is processed after such delivery.

BACKGROUND OF THE INVENTION

Electronic mail (e-mail) and electronic document delivery through computer networks such as the Internet are now widely used and have become somewhat ubiquitous. As e-mail grows from a primarily personal medium of communication to one that is used widely in business, security of electronic communications becomes increasingly important.

Ordinary e-mail, e.g., e-mail according to the SMTP protocol (Simple Mail Transfer Protocol) and Post Office Protocol (POP), lacks sufficient security for business communication through public networks. In essence, any information sent through SMTP is exposed and can be read by others monitoring SMTP traffic through a public network. One solution is to encrypt information to be sent by SMTP through a public network. However, such requires coordination between the sender and the recipient regarding the type of encryption to be used and the keys by which the information can be decrypted by the recipient. The added steps of encrypting before sending and decrypting after receipt are a significant inconvenience to both the sender and the recipient. In fact, many people simply forego encryption and risk a breach of security by sending sensitive documents and/or information through a public network in cleartext form.

Systems for sending information electronically through computer networks according to the HTTP (HyperText Transfer Protocol) protocol of the World Wide Web. While HTTP is similarly insufficiently secure, similar systems have used the more secure HTTPS (HyperText Transfer Protocol Secure) protocol. Systems using HTTPS for information transfer from person to person have the advantage that security is built into the network protocol and few, if any, additional steps by either the sender or recipient are required. In addition, the network protocol, i.e., HTTPS, is widely supported by commonly available web browsers. Some systems which use HTTPS for electronic, person-to-person communication require that both the sender and recipient are registered users of the same system for complete, end-to-end security. Registration typically requires at least that both the sender and the recipient have established a mechanism by which each can be authenticated. As a result, such systems can only be used to communicate with a limited class of people since the registered users of any such system represent a limited class of people.

Other systems transferring information using HTTPS require only that the sender be a registered user. As a result, the sender can register with the system and send information securely to any person who can receive a notification by SMTP/POP e-mail which provides instructions for the retrieval of the information through secure channels, e.g., HTTPS. This combination of HTTPS person-to-person data transfer coupled with SMTP/POP e-mail notification represents the most complete solution to business-ready, person-to-person secure communication through public networks. However, such a system suffers from the disadvantage that a recipient who is not also a registered user of such a system cannot send a reply message back to the sender. As a result, messages and/or electronic documents received by the recipient are frequently sent back to the original sender (as a reply) or to others (as a forwarded message) through less secure channels such as SMTP/POP e-mail.

What is needed is a mechanism by which a sender of information through a computer network can exercise significant control regarding post-delivery handling of the information by the recipient.

SUMMARY OF THE INVENTION

In accordance with the present invention, a sender of a message, which can include one or more attached data files, can specify limits on the types of action which can be take by a recipient of the message. For example, the sender can selectively enable local saving, printing, forwarding, and/or replying to the message. The sender specifies which, if any, of these types of actions are permissible. In delivering the message, a user interface is constructed in accordance with the types of permissible actions specified by the sender. For example, if a message is printable as specified by the sender, a user interface mechanism, such as a "Print" GUI button, is included with the representation of the message. Inclusion of the user interface mechanism enables the type of action specified by the sender. Exclusion of such a user interface disables the type of action specified by the sender.

The sender can also specify that the recipient can reply to the message at the original sender's expense. Such is somewhat analogous to enclosing a self-addressed, stamped envelope in paper correspondence. However, a number of parameters of a message, including a reply message, affect the cost associated with the message. The sender of the original, parent message is provided with the opportunity to limit such parameters. For example, the sender can specify (i) a level of security for the reply message, (ii) a priority with which the reply message is delivered, (iii) a number of times the parent message can be responded to at the sender's expense, (iv) a maximum permissible size of the reply message including any attached data files, (v) permissible formats of the attached data files, and/or (vi) a format of the reply message itself. The format of the reply message itself can be specified by form data, e.g., HTML or XML form data, specifying a user interface and can also provide data entry constraints and validation.

Some parameters are enforced by representing such parameters in a prepaid reply structure within a data structure representing the parent message and not within a prepaid reply message structure. As a result, parameters such as priority and security are defined within a data structure authored by the sender of the parent message and generally not accessible by the recipient in composing the prepaid reply message. Other parameters such as size limits, attachment formats, and number of prepaid replies are enforced by a message composer by which the recipient composes the prepaid reply message.

By allowing the sender the control post-delivery handling of a message, the sender can exercise greater control over the security of the message. For example, the sender can specify that the message is not stored in local persistent storage of the recipient. Accordingly, transfer of the message to a less secure communications medium, e.g., SMTP/POP e-mail, is more difficult.

In addition to limiting what can be done with the message, by allowing the sender to grant the recipient a prepaid reply, the sender can better utilize two-way, person-to- person, secure communication through a public network such as the Internet. In addition, allowing the sender to set limits on the prepaid reply makes such a prepaid reply a practical and useable feature.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram of a computer system that includes a server computer system coupled to sender and recipient client computer systems through a wide-area computer network in accordance with the present invention.

Figure 2 is a block diagram of the sender computer system of Figure 1 in greater detail.

Figure 3 is a block diagram of the server computer system of Figure 1 in greater detail.

Figure 4 is a block diagram of the recipient computer system of Figure 1 in greater detail.

Figure 5 is a block diagram of a message database of the server computer system of Figure 3 in greater detail.

Figure 6 is a block diagram of a message of the message database of Figure 5 is greater detail. The message includes data specifying post-delivery handling parameters in accordance with the present invention.

Figure 7 is a block diagram of prepaid reply parameters of the message of Figure 6 in greater detail.

Figure 8 is a block diagram of a prepaid reply in accordance with the present invention.

Figure 9 is a logic flow diagram of the delivery of a message with post-delivery handling parameters specified in accordance with the present invention.

Figure 10 is a logic flow diagram of the implementation of post-delivery handling parameters of an electronic message in accordance with the present invention. Figure 11 is a logic flow diagram of the user-interface implementation of post- delivery handling parameters of an electronic message in accordance with the present invention.

Figure 12 is a logic flow diagram of the building of a prepaid reply message in accordance with the present invention.

Figure 13 is a logic flow diagram of the enforcement of limitations regarding the size and format of attached data files in accordance with the present invention.

Figure 14 is a logic flow diagram of the saving of a draft prepaid reply message to local persistent storage.

Figure 15 is a logic flow diagram of the sending of a prepaid reply message in accordance with the present invention.

DETAILED DESCRIPTION

In accordance with the present invention, the sender of a message can exercise substantial control of post-delivery handling of the message and can provide a recipient of the message with a convenient mechanism for replying to the message. For the recipient's convenience, even if the recipient is not a registered user of the message delivery system of server computer system 104, the sender can permit the recipient to use the same level of security provided by server computer system 104 available to the sender and can allow the recipient to reply free of charge. In addition, the sender can limit the service provided to the recipient with respect to number, addressing, size, formats, security and priority to thereby limit the charges which can accrue to the sender by the recipient's reply.

A server computer system 104 facilitates secure communication between a sender computer system 102 and a recipient computer system 106 through a wide area computer network 108. In one illustrative embodiment, wide area computer network 108 is the Internet. While a wide area network 108 is shown and described, it is appreciated that the following description is also applicable to local area networks.

The operation of message delivery system 100 is briefly described while the details are described more completely below. A sender, e.g., a human user of sender computer system 102, specifies a message to send to a recipient, e.g., a human user of recipient computer system 106. While human users are described in this illustrative example, it is appreciated that the sender and/or the recipient can be all or part of one or more computer processes executing within sender computer system 102 and/or recipient computer system 106, respectively. In addition, computer system 102 is referred to as sender computer system 102 and computer system 106 is referred to as recipient computer system 106 in the context of the illustrative example of a message 502 (Figure 5) sent from computer system 102 to computer system 106. Computer systems 102 and 106 are analogous to one another; sender computer system 102 is capable of receiving messages in the manner described with respect to recipient computer system 106. and recipient computer system 106 is capable of sending messages in the manner described with respect to sender computer system 102.

The message can include generally any data capable of being transferred through wide area network 108 and of being stored within server computer system 104. Server computer system 104 receives and stores the message and notifies the recipient using ordinary SMTP/POP e-mail. The recipient requests transfer of the message from server computer system 104 through wide area network 108.

In response to the request, server computer system 104 sends the message and controls post-delivery handling of the message by the recipient in accordance with post- delivery handling parameters specified by the sender. For example, server computer sy^em 104 can enable or disable post-delivery activities such as printing, locally saving, forwarding, and/or replying to the message. In addition, any charges for processing a reply message can be charged to the sender even though the reply is sent by the recipient.

To compose the original message, the sender uses a message composer 204 (Figure 2) of a message client 202 of sender computer system 102. Message client 202 is all or part of one or more computer processes executing within sender computer system 102. Message client 202 can be either a thick client or a thin client. If message client 202 is a thick client, the computer instructions and data which define the behavior of message client system 102 are stored locally within sender computer system 102 and the one or more computer processes which collectively define message client 202 are dedicated to that task. If message client 202 is a thin client, message client 202 is defined by computer instructions and/or data stored in server computer system 104 which are retrieved through wide area network 108 and executed by one or more general purpose computer processes such as a web browser or a JAVA™ virtual machine from Sun Microsystems, Inc. of Palo Alto, California. Thin client computer instructions stored on server computer system 104 can include, for example, (i) HTML (HyperText Markup Language) pages which are static and/or dynamically created by CGI (Common Gateway Interface) scripts, (ii) Java™ scripts embedded in HTML pages, and (iii) Java™ applets.

Message client 202 also includes a message tracker 206 and a message reader 208. Message tracker 206 implements a user interface by which the sender can request status information regarding delivery status of various messages sent by sender computer system 102. Message reader 208 is directly analogous to message reader 408 (Figure 4) which is described more completely below.

Whether message client 202 is a thin or thick client, message composer 204 provides a user interface by which the sender specifies various parameters of the message to be sent. Such parameters include one or more recipient network addresses to which to send the message, a subject of the message, the body of the message, one or more data files (e.g., data file 210) to attach to the message, and one or more post-delivery handling parameters. These and other parameters of a message are described in greater detail below. In this illustrative example, at least one of the recipient network addresses specifies recipient computer system 106 as a recipient of the message. While the network address is described, for simplicity, to specify a computer system such as recipient computer system 106, it is contemplated that the network address is an e-mail address accessible through SMTP/POP and is not coupled to any particular computer system but is instead coupled to a user who can access mail to that address using various computer systems.

Once the various parameters which specify a message are entered by the sender and the sender issues a command to send the message, message composer 204 sends a record containing the sender-specified parameters to server computer system 104 through wide area network according to the secure HTTPS protocol.

Server computer system 104 processes the message record as shown in logic flow diagram 900 (Figure 9). In step 902, message receiver 304 (Figure 3) of server computer system 104 receives the record from sender computer system 102. In step 904 (Figure 9), message receiver 304 (Figure 3) forms a local message record, e.g., message 502 (Figure 5), and stores the message record in encrypted form in message database 302. Message receiver 304 (Figure 3) also receives any attached data files, encrypts the attached data files, and stores the encrypted attached files as attached data files 504 (Figure 5), for example.

Message 502 stores the various parameters of the message specified by the sender and is shown in greater detail in Figure 6. Message 502 includes fields 602-642 which collectively specify a message and its manner of delivery.

From: field 602 specifies the sender as the entity sending the message. In this illustrative embodiment, from: field 602 specifies the POP e-mail address of the sender. From: field 602 is not specified by the sender but is automatically set according to the user identification used by the sender for authentication with server computer system 104 (Figure 1).

To: field 604 (Figure 6) specifies one or more recipients of message 502. CC: field 606 also specifies one or more recipients of message 502 as does BCC: field 608. Recipients specified in fields 604-608 all receive message 502. Recipients specified in BCC: field 608 are not disclosed to other recipients of message 502. In this illustrative embodiment, all recipients are specified in fields 604-608 by POP e-mail addresses. Message composer 204 (Figure 2) can include an address book in which the sender equates POP e-mail addresses with aliases; however, server computer system 104 processes POP e-mail addresses and message composer 204 substitutes the equated POP e- mail addresses for the aliases specified by the sender prior to sending the message record to server computer system 104 through wide area network 108.

A subject field 610 specifies a summary description of the subject of message 502 and is included for the convenience of the sender and the recipients.

A body field 612 includes the data which is the substantive content of message 502. Body field 612 can be generally any format but is typically a textual format such as ASCII text, rich text format (RTF), and/or HTML.

Attachment field 614 can include references to one or more attached data files such as attached data files 504 (Figure 5). Such data files are specified by the sender and transferred to server computer system 104 for storage in message database 302. Such attached data files are sometimes referred to herein as documents although such attached data files can include — in addition to electronic documents and textual data — generally any type of data including, for example, digitized audio, graphical images, motion video, computer software, databases, and spreadsheets.

Priority field 616 (Figure 6) specifies a level of priority for handling of message 502 by server computer system 104. Server computer system 104 uses priority field 616 in scheduling delivery of message 502 relative to other messages handled by server computer system 104. When handling large numbers of messages, server computer system 104 processes those with higher priorities more quickly than those with low priorities. In addition, an indication of the priority of a message can be represented to the recipient as an indication of the urgency of the matter to which the message pertains. In this illustrative embodiment, the sender can specify low, medium, or high priority and is charged accordingly.

Security field 618 specifies a type of security by which message 502 is delivered. In this illustrative embodiment, the sender selects from four (4) types of security: low, standard, package, and account. In low security, message 502 is stored within message database 302 in a cleartext, i.e., unencrypted, form and message 502 can travel through wide area network 108 through insecure channels, i.e., using HTTP rather than HTTPS.

In standard security, message 502 must travel through wide area network 108 (both from the sender to server computer system 104 and from server computer system 104 to all recipients) through secure channels — using HTTPS rather than HTTP. In addition, message 502 is stored in an encrypted form within message database 302 in standard security.

In package security, a package-specific password is associated with message 502 and the recipient must provide the password to retrieve message 502. Password is used herein to describe any data supplied by an entity for authentication purposes and can include (i) non-textual data, (ii) data which is not a word in any spoken language, and (iii) data which can include spaces, tabs, and punctuation to delimit multiple words, i.e., a passphrase. The sender has the option of providing a hint phrase such that the recipient can be reminded of the password without disclosing the password itself. If package security is selected by the sender, the password or a hash thereof and the hint phrase are included in security field 616.

In account security, all recipients must be registered users of the message delivery system of server computer 104 and must authenticate themselves accordingly. For example, the recipient must have established an authentication protocol by which the recipient is authenticated for access to services provided by server computer system 104. The sender is authenticated in the same manner prior to being permitted to compose and send message 502.

The sender can specify any of a number of ways to proceed if one or more recipients of message 502 are not registered users of the message delivery system of server computer system 104. First, the sender can specify that message 502 is not sent at all if any of the recipients are not registered users. Second, the sender can specify that, if any recipient is not a registered user, package security is used. If the second option is selected, security field 618 includes a password and hint phrase in the manner described above. Third, the sender can specify that, if any recipient is not a registered user, that an account is created for any and all non-registered recipients. If the third option is selected, the sender specifies an initial password for authentication of the recipients and an associated hint phrase. The initial password or a hash thereof and the hint phrase are included in security field 618. Once a recipient has used the initial password for authentication, the recipient can use the same password for authentication for subsequent messages which use account security or can change the password of the recipient. In one embodiment, the recipient is required to select a new password immediately upon authentication using an initial password specified by the sender.

Notification parameters 620 specify the manner in which the recipient is to be notified regarding message 502. By default, notification through SMTP/POP specifies only the subject and a private universal resource locator (PURL) by which message 502 and any attached data files 504 can be retrieved. Such a PURL is described in U.S. Patent Application 08/832,784 by Jeffrey C. Smith and Jean-Christophe Bandini entitled "Private, Trackable URLs for Directed Document Delivery" and that description is incoφorated herein by reference. Other information not specific to message 502 can be included in the notification e-mail message, such as message retrieval instructions. As a result, only the subject specified in subject field 610 is exposed in cleartext form during transit through a public network.

The sender can specify that the notification e-mail includes the substantive content of the message as represented in body field 612. Since the notification message is not secure, the security of the body of the message is compromised if the body is included in the notification message. However, it is possible that the sender is not concerned with the security of the message body.

The sender can also specify that the attached data files specified by attachment field 614 are attached to the notification e-mail message. Since the notification message is not secure, the security of the attached data files is compromised if the data files are attached to the notification message. However, it is possible that the sender is not concerned with the security of the attached data files themselves.

Third, the sender can specify that the notification e-mail include an HTML page for retrieving message 502. Such an HTML page is described in U.S. Patent Application 09/386,643 by Jeffrey C. Smith and Jean-Christophe Bandini entitled "Electronic Document Delivery System In Which Notification of Said Electronic Document Is Sent To a Recipient Thereof and that description is incoφorated herein by reference.

The sender can specify any of the above three notification options individually or in combination.

As described briefly above, fields 622-630 specify post-delivery processing and can be set by the sender to limit the manner in which message 502 can be used after delivery to the recipient. Save enable field 622 indicates whether the recipient is permitted to save message 502 and/or any data files attached thereto to local persistent storage within recipient computer system 106. If the recipient is permitted to save the message in local persistent storage which can include, for example, a magnetic or optical disk, the recipient can then include the saved message in less secure communications channels, such as SMTP/POP e-mail. Preventing saving of message 502 to local persistent storage reduces the likelihood that message 502 will be communicated through such less secure channels.

Print enable field 624 indicates whether the recipient is permitted to print message 502, i.e., to make a hardcopy of message 502. A printed copy of message 502 can be left on a desk and seen by someone other than the recipient and can be scanned to form a soft copy of message 502 which can then be sent through less secure channels. Preventing printing of message 502 reduces the likelihood that such breaches in security will occur.

Forward enable field 626 indicates whether the recipient is permitted to forward message 502 to someone other than the sender or other recipients of message 502. Forwarding message 502 expands the audience beyond that originally specified by the sender and such can be prevented by the sender by disabling forwarding of message 502. Reply enable field 628 indicates whether the recipient is permitted to reply to message 502 by sending a message to the sender and/or other recipients of message 502. Disabling a reply can be particularly useful if the sender is not a human user but rather all or part of one or more computer processes executing within sender computer system 102. It is possible that such an automated sender is incapable of processing received messages. Reply enable field 628 can also specify that reply messages are addressed only to the sender and not to other recipients of message 502.

Prepaid reply parameters 630 specify whether the recipient is permitted to reply to message 502 at the expense of the sender. In addition, prepaid reply parameters 630 specify limits on such a prepaid reply to thereby limit expense to the sender for such a reply. Prepaid reply parameters 630 are shown in greater detail in Figure 7.

Number of replies field 702 specifies the number of times the recipient can reply to message 502 at the sender's expense. A value of zero indicates that prepaid replies to message 502 are not permitted.

Reply to: field 704 specifies limits as to whom the prepaid reply can be addressed. In this illustrative example, the sender selects one of four (4) limitations. First, the sender can specify that only the sender will receive the prepaid reply message. Second, the sender can specify that all recipients of message 502 as specified in fields 604-608 (Figure 6) can receive the prepaid reply message. Third, the sender can specify that only selected recipients specified in fields 604-608 can receive the prepaid reply message. The selected recipients can be specified by specifying only one or two of fields 604-608 or by specifying individual addresses selected from those specified within fields 604-608. Fourth, the sender can specify that the prepaid reply can be sent to anybody. In effect, the fourth option allows a prepaid forward message or a prepaid message of any kind.

Size limit field 706 specifies a limit as to the total size of any prepaid reply message including attached data files. In this illustrative embodiment, the size of a message such as message 502, including attached data files, affects the amount charged to the sender. Similarly, the size of a prepaid reply message sent by the recipient and authorized by the sender affects the amount charged to the sender. Therefore, the sender is provided with the ability to limit the size of the prepaid reply message to thereby also limit the amount charged for the prepaid reply message.

Security field 708 specifies a level of security for the prepaid reply message. The levels of security available for the prepaid reply message are the same as those available for message 502. The security level for the prepaid reply message as indicated by security field 708 is specified by the sender.

Priority field 710 specifies a degree of priority with which the prepaid reply message is handled and delivered by server computer system 104. Since the degree of priority affects the amount charged to the sender for authorizing the prepaid reply, the sender is permitted to control the degree of priority of the prepaid reply message.

Attachment formats field 712 can specify one or more data formats of attached data files the sender is willing to receive. For example, if the sender uses Corel® WordPerfect® for word processing or if the user is concerned with security risks associated with active macros, the sender can specify that the Corel® WordPerfect® format is acceptable while the Microsoft® Word format is not. In addition, the sender can permit widely used graphics formats such as JPEG and GIF and generic text formats such as ASCII text, RTF, and Adobe® Acrobat® Portable Document Format (PDF). The sender can also specify that any format is acceptable.

User interface field 714 can specify a user interface to limit the substantive content of a prepaid reply message. By default, user interface field 714 does not limit the substantive content of the prepaid reply message such that any message can be sent by the recipient, subject to the limitations of fields 702-712. However, the sender can provide data specifying a user interface, e.g., an HTML form in a thin client or XML (extended Markup Language) form in a thick client or in a Java™ applet or plug-in of a thin client. An HTML form includes GUI (graphical user interface) buttons, text boxes, and similar user interface tools to limit the form of the recipient's reply message. An XML form can also specific a user interface and can contain logic for ensuring that data entered by the recipient is valid. For example, the recipient can be required to enter a date and user interface field 714 can include logic, as part of an XML form or as Java™ script embedded in an HTML form, which ensures that data supplied by the recipient represents a valid date.

As an example of the use of user interface field 714, user interface field 714 can specify an HTML form which includes a survey question, "yes" and "no" radio buttons, and a submit button such that the recipient can only response "yes" or "no" to the posed question. Such a prepaid reply message can be readily processed automatically since the "yes" or "no" response is made unambiguous by the HTML form. Similarly, user interface field 714 can include an HTML form with a fixed statement that the document — including listed contents — has been received and read and understood by the recipient and a "confirm" GUI button. In this way, the sender can provide a kind of acknowledgment not otherwise provided by the message delivery system of server computer system 104.

Thus, prepaid reply parameters 630 specify whether a prepaid reply is authorized and, if so, specifies limits on the prepaid reply.

Returning to message 502 (Figure 6), language field 632 specifies a language in which message 502 is to be presented to the recipient. While language field 632 does not affect presentation of the substantive content of body field 612, supporting text in the picsentation of message 502 such as box labels "To:," "From:," and "Subject:" and instructions regarding retrieving attached data files are presented in the language specified in language field 632.

Status notification field 634 specifies the manner in which the sender is notified regarding processing of message 502. In this illustrative embodiment, two options are provided and the sender can select either, both, or neither of the options. In the first option, the sender is notified by SMTP/POP e-mail when delivery of message 502 to any recipient fails. In the second option, the sender is notified by SMTP/POP e-mail when message 502 is successfully retrieved and viewed by any of the recipients. Both options are implemented independently for each of the recipients specified in fields 604-608.

Delivery schedule field 636 specifies a time at which message 502 is to be delivered. The sender can specify that message 502 is to be delivered immediately or at some later date and time.

Expiration field 638 specifies a time when message 502 expires and is to be deleted from message database 302 (Figure 4). By specifying an expiration time, the sender can control access to message 502. For example, if the sender believes that all recipients can retrieve message 502 in relatively short time and wishes to prevent storage of message 502 in message database 302 longer than necessary, the sender can specify a shorter expiration for message 502. Conversely, if the sender perceives that one or more recipients will need additional time to properly respond to message 502, the sender can specify a later expiration for message 502. Such is particularly important if the sender has disabled saving and printing of message 502 in the manner described above with respect to fields 622-624 because the recipient cannot save or print message 502 for later reference in responding. The sender can specify expiration as a number of days from the day message 502 is composed, as a specific date and time, or specify that the message does not expire ever. Delayed expiration is typically charged to the sender since such uses storage resources of message database 302 for a longer period of time than other messages.

Copy expiration field 640 specifies a time when a copy of message 502, which is retained for the sender's benefit, expires and is to be deleted from message database 302 (Figure 4).

Billing code 642 specifies an account within server computer system 104 for which message 502 is to be billed. Billing code 642 specifies the account of the sender and charges associated with storing and delivering message 502 and any attached data files and any authorized prepaid reply are billed to the account specified by billing code 642.

Returning to logic flow diagram 900 (Figure 9), once message receiver 304 has received the message record from sender computer system 102 and has constructed message 502 (Figure 5) therefrom, recipient notifier 306 (Figure 3) initiates delivery of message 502 in step 906 (Figure 9).

In step 906, recipient notifier 306 (Figure 3) sends a notification message to the recipients specified in fields 604-608 of message 502 at the delivery time specified in field 636. The notification message is a SMTP/POP e-mail message in this embodiment.

Loop step 908 and next step 918 define a loop in which each recipient of message 502 is processed according to steps 910-916. During each separate performance of steps 910-916, the particular recipient processed is referred to as the subject recipient.

In step 910, message retriever 308 (Figure 3) of server computer system 104 asynchronously receives a request to view message 502 from the subject recipient. The request is received asynchronously in that each recipient receives the notification message independently and independently submits the PURL contained in the notification message to request message 502 for viewing. Since the PURLs are submitted independently, the requests are received by message retriever 308 at various times which are independent of one another.

As described above, the PURL specifies message 502 as the requested message and identifies the subject recipient.

In step 912 (Figure 9), message retriever 308 (Figure 3) conveys the received request to message formatter 310. Message formatter 310 retrieves message 502 from message database 302 and formats message database 302 for display to the subject recipient using message reader 408 (Figure 4) of message client 402. If message client 402 is a thin client, message formatter 310 (Figure 3) builds an HTML document to represent message 502. For example, message formatter 310 includes text in the HTML document representing the sender specified in from: field 602 (Figure 6), text representing various recipients specified in fields 604-608, text representing the subject specified in subject field 610, and the substantive content specified in body field 612. If the content represented in body field 612 is a format other than HTML, message formatter 310 converts the format to HTML, preserving as much as the look and feel of the substantive content represented in body field 612 as possible in the HTML representation of message 502. In addition, message formatter 310 includes hypertext links to any attached data files 504 (Figure 5) specified in attachment field 614 (Figure 6). If, on the other hand, message client 402 (Figure 4) is a thick client, message formatter 310 can format message 502 in any manner or format recognized by message client 402 (Figure 4). If message client 402 is a thick client, message client 402 can be configured to recognize practically any format.

In step 914 (Figure 9), message formatter 310 (Figure 3) includes data specifying a user interface according to post-delivery handling parameters of fields 622-630 (Figure 6). Such is described more completely below in the context of presentation of message to the recipient by message reader 408. A brief example is helpful to understand step 914 more completely. If save enable field 622 indicates that message 502 can be saved to local persistent storage by the subject recipient, message formatter 310 (Figure 3) includes a user interface mechanism by which the subject recipient can, through message reader 408 (Figure 4), effect such saving of message 502. If message client 402 (Figure 4) is a thin client, message formatter 310 (Figure 3) includes HTML form components implementing the post-delivery handling limitations specified by the sender through fields 622-630 — specifically, a HTML form GUI button labeled "Save Message" which, when actuated by the subject recipient using conventional user interface techniques, saves message 502 to local persistent storage within recipient computer system 106. If message client 402 (Figure 4) is a thick client, message formatter 310 (Figure 3) includes data in message 502 specifying that message reader 408 (Figure 4) is to disable a "Save" option within a "File" pull-down menu, perhaps leaving the "Save" option in the pull-down menu but represented in grey to indicate that the option is disabled. Similar user interface mechanisms are specified by message formatter 310 (Figure 3) in step 914 (Figure 9) to implement post-delivery handling as specified by the sender in fields 622-630 (Figure 6).

It is appreciated that limitation of post-delivery handling is particularly difficult when message client 402 ((4) is a thin client such as a web browser. In particular, web browsers have functionality which is not directly controllable by an HTML document. For example, most currently available web browsers have a "Save As" option under a "File" pull-down menu which can be used to save the HTML presentation of message 502 to local persistent storage. However, by excluding a "Save" GUI button from the HTML representation of message, saving the message to local persistent storage is made less convenient to the recipient and the recipient is cued to the fact that the sender prefers that no local persistent copy of the message is maintained. In addition, an explicit request to refrain from making a local persistent copy of the message can be included in the HTML representation of message 502 to further discourage use of extraneous mechanisms such as built-in web browser functionality to store message 502 in local persistent storage. Other built-in functionality of web browser thin clients which are beyond the control of HTML documents includes, for example, printing and editing capabilities such as cut, copy, and paste.

In step 916 (Figure 9), message retriever 308 (Figure 3) sends the message as formatted by message formatter 310, including user interface components which implement post-delivery handling as specified by the sender, to message client 402 (Figure 4) of recipient computer system 106.

After all recipients have been processed by the loop of steps 908-918, delivery processing of message 502 by server computer system 104 according to logic flow diagram 900 completes.

Processing of message client 402 (Figure 4) of the formatted message received from message retriever 308 (Figure 3) is shown as logic flow diagram 1000 (Figure 10). Message client 402 (Figure 4) is directly analogous to message client 202 (Figure 2) and description of either herein is equally applicable to both except where otherwise noted. In step 1002 (Figure 10), message reader 408 (Figure 4) of message client 402 enables printing of the received formatted message only if the message as formatted specifies that printing is enabled. If message client 402 is a thin client, the formatted message includes HTML form GUI components, such as a "Print" GUI button, which enable or disable specific types of post-delivery actions. For example, if printing is enabled, the formatted message includes the "Print" GUI button, activation of which causes the formatted message to be sent to a printer locally attached to recipient computer system 106. If printing is disabled, the formatted message includes no such GUI button.

If, on the other hand, message client 402 is a thick client, message reader 408 determines that the formatted message specifies that printing is enabled and enables a "Print" option of a "File" pull-down menu and/or a "Print" GUI button of a tool bar displayed by message reader 408. Alternatively, if message reader 408 determines that printing is disabled as specified within the formatted message, message reader 408 disables the "Print" option and/or the "Print" GUI button. The "Print" option and/or GUI button can be shown to be disabled by representing the "Print" option and/or GUI button in grey.

In step 1004 (Figure 10), message reader 408 (Figure 4) enables saving of the formatted message to local persistent storage only if the formatted message includes user- interface components to effect saving of the formatted message. Step 1004 is generally analogous to step 1002. If message client 402 is a thin client, the formatted message includes a "Save" GUI button only if message formatter 310 (Figure 3) determined that save enable field 622 indicates that local saving of message 502 is permitted. Whatever GUI components included in the formatted message are presented to the recipient by message reader 408 (Figure 4) in a thin message client 402. Inclusion or omission of the "Save" GUI button from the formatted message indicates enabling or disabling, respectively, of saving the formatted message to local persistent storage.

If, on the other hand, message client 402 is a thick client, the formatted message includes data specifying whether local saving is enabled and selectively enables or disables a "Save" option in the "File" pull-down menu and/or a "Save" GUI button on the toolbar accordingly in a manner analogous to that described above with respect to step 1002.

In step 1006 (Figure 10), message reader 408 (Figure 4) enables forwarding of the formatted message to other people only if the formatted message includes user-interface components to effect forwarding of the formatted message. Step 1006 is generally analogous to steps 1002-1004. If message client 402 is a thin client, the formatted message includes a "Forward" GUI button only if message formatter 310 (Figure 3) determined that forward enable field 626 indicates that forwarding of message 502 is permitted. Whatever GUI components included in the formatted message are presented to the recipient by message reader 408 (Figure 4) in a thin message client 402. Inclusion or omission of the "Forward" GUI button from the formatted message indicates enabling or disabling, respectively, of forwarding the formatted message to other people.

If, on the other hand, message client 402 is a thick client, the formatted message includes data specifying whether forwarding is enabled and selectively enables or disables a "Forward" option in the "File" pull-down menu and/or a "Forward" GUI button on the toolbar accordingly in a manner analogous to that described above with respect to steps 1002-1004.

In step 1008 (Figure 10), message reader 408 (Figure 4) enables replying to the formatted message, i.e., sending a reply message to the sender, only if the formatted message includes user-interface components to effect replying to the formatted message. Step 1008 is generally analogous to steps 1002-1006. If message client 402 is a thin client, the formatted message includes a "Reply" GUI button only if message formatter 310 (Figure 3) determined that reply enable field 626 indicates that replying to message 502 is permitted. Whatever GUI components included in the formatted message are presented to the recipient by message reader 408 (Figure 4) in a thin message client 402. Inclusion or omission of the "Reply" GUI button from the formatted message indicates enabling or disabling, respectively, of replying to the formatted message.

If, on the other hand, message client 402 is a thick client, the formatted message includes data specifying whether replying is enabled and selectively enables or disables a "Reply" option in the "File" pull-down menu and/or a "Reply" GUI button on the toolbar accordingly in a manner analogous to that described above with respect to steps 1002- 1006.

In step 1010 (Figure 10), message reader 408 (Figure 4) enables prepaid replying to the formatted message, i.e., sending a reply message to the sender at the sender's expense, only if the formatted message includes user-interface components to effect prepaid replying to the formatted message. Step 1010 is generally analogous to steps 1002-1008. If message client 402 is a thin client, the formatted message includes a "Prepaid Reply" GUI button only if message formatter 310 (Figure 3) determined that prepaid reply parameters 630 indicate that one or more prepaid replies to message 502 is permitted. Whatever GUI components included in the formatted message are presented to the recipient by message reader 408 (Figure 4) in a thin message client 402. Inclusion or omission of the "Prepaid Reply" GUI button from the formatted message indicates enabling or disabling, respectively, of prepaid replies to the formatted message.

If, on the other hand, message client 402 is a thick client, the formatted message includes data specifying whether one or more prepaid replies are enabled and selectively enables or disables a "Prepaid Reply" option in the "File" pull-down menu and/or a "Prepaid Reply" GUI button on the toolbar accordingly in a manner analogous to that described above with respect to steps 1002-1008.

In step 1012, message reader 408 (Figure 4) displays the formatted message along with the user interface implementation of post-delivery handling effected in accordance with steps 1002-1010 (Figure 10). In step 1014, message reader 408 (Figure 4) processes the user interface as configured in steps 1002-1010.

Step 1014 is shown in greater detail as logic flow diagram 1014 (Figure 11). In logic flow diagram 1014, the recipient has actuated a GUI component such as a pull-down menu option or a GUI button. In the context of logic flow diagram 1014, a GUI button is described as having been pressed by the recipient using conventional user interface techniques. However, it is appreciated that the user interface action can be a different one, e.g., selection of an option from a pull-down menu. In step 1102, message reader 408 (Figure 4) determines whether the recipient pressed a "Print" GUI button. If printing is not enabled, the "Print" GUI button is not active or is not present and the recipient cannot have pressed the "Print" GUI button. If the recipient pressed the "Print" GUI button, message reader 408 (Figure 4) prints the displayed message in step 1104 by converting the displayed message to a format appropriate for a printer attached locally to recipient computer system 106 and processing according to logic flow diagram 1014 completes.

If, however, the user interface action is other than pressing the "Print" button, processing transfers to test step 1106 in which message reader 408 (Figure 4) determines whether the user interface action is pressing of the "Save" GUI button. If saving to local persistent storage is not enabled, the "Save" GUI button is not active or is not present and the recipient cannot have pressed the "Save" GUI button. If the recipient pressed the "Save" GUI button, message reader 408 (Figure 4) saves the displayed message to local persistent storage in step 1108 (Figure 11). Message reader 408 (Figure 4) can convert the displayed message to a standard format such as HTML, PDF, RTF, or ASCII text. After step 1108 (Figure 11), processing according to logic flow diagram 1014 completes.

If, however, the user interface action is other than pressing the "Save" button, processing transfers to test step 1110 in which message reader 408 (Figure 4) determines whether the user interface action is pressing of the "Forward" GUI button. If forwarding of the message is not enabled, the "Forward" GUI button is not active or is not present and the recipient cannot have pressed the "Forward" GUI button. If the recipient pressed the "Forward" GUI button, message reader 408 (Figure 4) builds a forward message in step 1108 (Figure 11) and sends the forward message in step 1114. It should be noted that the forward message is sent by, and charged to, the recipient. Accordingly, the recipient must be a registered user of the message delivery system of server computer system 104 to compose and send a forward message in steps 1112-1 114. In one embodiment, message reader 408 (Figure 4) determines whether the recipient is a registered user and automatically disables forwarding and replying (of steps 1118-1120 — Figure 11) is the recipient is not a registered user. In an alternative embodiment, message reader 408 (Figure 4) determines that the recipient is not a registered member and, when about to forward or reply to a message, offers to register the recipient such that the recipient can be appropriately charged for the forward or reply message.

In step 1112, the recipient uses message composer 404 (Figure 4) to compose the forward message in the manner that the original message is composed by the sender. Message composer 404 pre-populates fields of the forward message from the original message. For example, the subject specified in subject field 610 (Figure 6) is preserved in the forward message and prefixed with a forwarded message indication such as "FW:". In addition, the substantive content of body field 612 of the original message is preserved within the forward message but prefixed with a quotation indication such as ">". Attached data files specified by attachment field 614 are similarly attached to the forward message. Fields 616-634 are copied from the original message to the forward message except that prepaid reply parameters 630 are reset to a default value in which prepaid replies are not authorized. Fields 636-640 of the forward message are reset to default values and billing code 642 of the forward message indicates that the recipient is to be charged for the forward message. The recipient is provided an opportunity to modify any and all of fields 604-640 using conventional user interface techniques prior to sending the forward message. In step 1114 (Figure 11), the forward message is sent by server computer system 104 in the manner described above with respect to the original message. After step 1114, processing according to logic flow diagram 1014 completes.

If, in test step 1110, the user interface action is other than pressing the "Forward" button, processing transfers to test step 1116 in which message reader 408 (Figure 4) determines whether the user interface action is pressing of the "Reply" GUI button. If reply to the message is not enabled, the "Reply" GUI button is not active or is not present and the recipient cannot have pressed the "Reply" GUI button. If the recipient pressed the "Reply" GUI button, message reader 408 (Figure 4) builds a reply message in step 1118 (Figure 11) and sends the reply message in step 1120. It should be noted that the reply message is sent by, and charged to, the recipient. Accordingly, the recipient must be a registered user of the message delivery system of server computer system 104 to compose and send a reply message in steps 1118-1120.

In step 1118, the recipient uses message composer 404 (Figure 4) to compose the reply message in the manner described above with respect to composing a forward message in step 1112. However, in step 1118, fields 604-608 are pre-populated with data specifying the sender and other recipients of the original message. Since the reply message is charged to the recipient composing the reply message, the recipient is permitted to modify the contents of fields 604-608 using conventional user interface techniques prior to sending the reply message. In step 1120 (Figure 11), the reply message is sent by server computer system 104 in the manner described above with respect to the original message. After step 1120, processing according to logic flow diagram 1014 completes.

If, in test step 1116, the user interface action is other than pressing the "Reply" button, processing transfers to test step 1122 in which message reader 408 (Figure 4) determines whether the user interface action is pressing of the "Prepaid Reply" GUI button. If reply to the message at the sender's expense is not enabled, the "Prepaid Reply" GUI button is not active or is not present and the recipient cannot have pressed the "Prepaid Reply" GUI button. In addition, message client 402 (Figure 4) determines whether the number of prepaid reply messages specified in number of replies field 702 (Figure 7) of the received formatted message have been exceeded. To make such a determination, message client 402 associates an identifier of the prepaid reply message with data representing the number of times a prepaid reply has been made to the received message. If the maximum permissible number of prepaid replies have been made, message reader 408 disables the "Prepaid Reply" GUI button or, alternatively, reports an error if the recipient actuates the "Prepaid Reply" GUI button after the maximum number of prepaid replies have been made.

If the recipient pressed the "Prepaid Reply" GUI button, message reader 408 (Figure 4) builds a prepaid reply message in step 1124 (Figure 11) and sends the reply message in step 1126. It should be noted that the prepaid reply message is sent by the recipient but charged to the sender of the original message. Accordingly, the recipient need not be a registered user of the message delivery system of server computer system 104 to compose and send a prepaid reply message in steps 1124-1126.

Step 1124 is shown in greater detail as logic flow diagram 1124 (Figure 12). In step 1202, message composer 404 (Figure 4) pre-populates fields 806 (Figure 8), 808, and 810 of a prepaid reply message 802 according to reply to: field 704 (Figure 4). Fields 806 (Figure 8), 808, and 810 are analogous to fields 604 (Figure 6), 606, and 608, respectively, of message 502. If reply to: field 704 specifies that the prepaid reply message can only be sent to the sender of the message to which prepaid reply message replies, message composer 404 stores data identifying the sender in field 806 and stores no addresses in fields 808-810. For convenience, the message to which prepaid reply message replies is sometimes referred to herein as the parent message. If reply to: field 704 specifies that the prepaid reply message can only be sent to the sender and all recipients of the parent message, message composer 404 stores data identifying the sender in field 806 and copies recipient addresses from fields 604-606 of the parent message into field 808 (Figure 8) of prepaid reply message 802 and copies the recipient addresses from field 608 to field 810. If reply to: field 704 specifies that the prepaid reply message can only be sent to the sender and selected recipients of the parent message, message composer 404 stores data identifying the sender in field 806 and copies the selected recipient addresses from fields 604-606 of the parent message into field 808 (Figure 8) of prepaid reply message 802 and copies the selected recipient addresses from field 608 to field 810. In any of the preceding three cases, message composer 404 does not permit the recipient to modify fields 806-810 in composing prepaid reply message 802. However, if reply to: field 704 specifies that the recipient can send the prepaid reply to anyone, fields 806-810 are pre-populated in one of the manners described above and message composer 404 permits the user to modify the contents of fields 806-810.

In step 1204 (Figure 12), message composer 404 pre-populates subject field 812 and body field 818. Subject field 812 is analogous to subject field 610, and body field 818 is analogous to body field 612. If user interface 714 (Figure 7) doesn't specify a particular user interface for the substantive content of the recipient's prepaid reply message, message composer 404 pre-populates subject field 812 with the contents of subject field 610 (Figure 6) but prefixed with a reply indication such as "RE:". In addition, message composer 404 pre-populates body field 818 with the contents of body field 612 but prefixed with a quotation indication such as ">". Message composer 404 permits the recipient to modify the contents of subject field 812 and body field 818. However, if user interface 714 (Figure 7) specifies a particular user interface, e.g., an HTML form, for the recipient's reply, message composer 404 (Figure 4) presents the specified user interface to the recipient such that the specified user interface controls the manner in which the recipient is permitted to modify the substantive content of prepaid reply message 802 as represented in body field 818.

In step 1206 (Figure 12), message composer 404 (Figure 4) provides a user interface for attaching data files to the prepaid reply message. Such a user interface includes, for example, a mechanism for specifying one or more of data files 410 and a GUI button for attaching the specified data file(s) to prepaid reply message 802. Use of the provided user interface by the recipient to attach one or more of data files 410 is described more completely below.

In step 1208 (Figure 12), message composer 404 (Figure 4) provides a user interface for specifying a preferred type of notification to the recipient, who is sending the prepaid reply message, regarding delivery of the prepaid reply message. The types of notification that are available to the recipient are the same as those available to the sender of the original message as described above with respect to status notification field 634 (Figure 6). The type of status notification selected by the recipient in composing prepaid reply message 802 (Figure 8) is stored in status notification field 816, which is analogous to status notification 634 (Figure 6).

After step 1208 (Figure 12) processing according to logic flow diagram 1124 completes. However, processing does not proceed to step 1126 (Figure 11) until step 1502 (Figure 14) which is described below. Instead, message composer 404 (Figure 4) allows the recipient to modify selected fields of prepaid reply message 802 (Figure 8). In particular, the prepaid reply message as presented to the recipient includes user interface mechanisms to attach data files to the prepaid reply message, to save a draft of the prepaid reply message, and to send the prepaid reply message.

If the recipient actuates the user interface to attach a data file to the prepaid reply message, message composer 404 processes the user interface action according to logic flow diagram 1300. In step 1302, message composer 404 identifies the one of data files 410 specified by the recipient. In step 1304, message composer 404 determines the size of the selected data file. If message client 402 is a thin client, message composer 404 may have limited resources for determining the size of attached data files. Accordingly, server computer system 104 independently verifies that size limitations specified in size limit field 706 (Figure 7) is met by any prepaid reply message. Any violation is reported to the recipient and the message is discarded at no cost to the sender.

In test step 1306, message composer 404 determines whether attaching the selected data file to prepaid reply message 802 would exceed any size limitation specified in size limit field 706 (Figure 7) of the original message, e.g., message 502. If so, message composer 404 reports an error to the recipient and does not attach the selected data file to prepaid reply message 802 (Figure 8).

Conversely, if attaching the selected data file would not exceed the specified size limitation, processing transfers to step 1308 (Figure 13) in which message composer 404 (Figure 4) determines the format of the selected data file. If message client 402 is a thin client, message composer 404 may have limited resources for determining the format of attached data files. Accordingly, server computer system 104 independently verifies that file format limitations specified in attachment formats field 712 (Figure 7) are met by any data files attached to any prepaid reply message. Server computer system 104 makes such a determination by examination of the data contents of such data files. However, even a thin client can check some indications regarding file format such as three-letter file name extensions which indicate file format. However, since a three-letter extension can be changed by a user, server computer system 104 performs an independent check of the file formats of attached data files. Any violation is reported to the recipient and the message is discarded at no cost to the sender.

In test step 1310 (Figure 13), message composer 404 determines whether the format of the selected data file is permitted by the sender of message 502 by reference to attachment formats field 712. If the format of the selected data file is not permitted, message composer 404 reports an error to the recipient and does not attach the selected data file to prepaid reply message 802 (Figure 8). Conversely, if the format of the selected data file is permitted, message composer 404 stores a reference to the selected data file in attachment field 814 to attach the selected data file to prepaid reply message 802 and processing according to logic flow diagram 1300 completes. Thus, message composer 404 enforces size limitations and format limitations with respect to attached files as specified in the original message by the sender.

If the recipient actuates the user interface for saving a draft of prepaid reply message 802, message composer 404 saves prepaid reply message 802 to local persistent storage for subsequent retrieval and sending in step 1402 (Figure 14).

If the recipient actuates the user interface for sending prepaid reply message 802, message composer 404 sends prepaid reply message 802 to server computer system 104. In addition, message client 402 increments the number of prepaid replies made to the original message and processing transfers to step 1126 (Figure 11) in which prepaid reply message is delivered.

In step 1126 (Figure 11), server computer system 104 delivers prepaid reply message 802 (Figure 8) in the manner described above with respect to message 502 (Figure 5) and logic flow diagram 900 (Figure 9) with the following exceptions.

If no user interface is specified in user interface field 714 (Figure 7) of the parent message as identified by regarding field 820 (Figure 8), the body of prepaid reply message 802 is sent unchanged. However, if a user interface is specified in user interface field 714 (Figure 7) of the parent message, message receiver 304 (Figure 3) of server computer system 104 receives form data which can be cryptic and difficult to inteφret by the sender, particularly if the sender is a human user of sender computer system 102. Accordingly, message receiver 304 reformats such form data to be more readable. In this embodiment, message receiver 304 represents form data as textual data in which each field of the form is represented on a separate line of text and in which the name of each field of the form data is juxtaposed with the associated value of the field.

Rather than determining the priority with which to process the message from data within the message itself (e.g., priority field 616 — Figure 6 — of message 502), recipient notifier 306 (Figure 3) processes prepaid reply message 802 (Figure 8) in accordance with a priority specified by the parent message, e.g., by priority field 710 (Figure 7) of message 502. The parent message is identified by regarding field 820 (Figure 8). In this example, regarding field 820 identifies message 502 as the parent message, i.e., as the message to which prepaid reply message 802 responds.

Rather than determining the level of security to be used when processing the message from data within the message itself (e.g., security field 618 — Figure 6 — of message 502), server computer system (Figure 3) processes prepaid reply message 802 (Figure 8) in accordance with a level of security specified by the parent message, e.g., by security field 708 (Figure 7) of message 502.

Prepaid reply message 802 (Figure 8) responds to the parent message which was originally sent by the sender and both the prepaid reply message and the parent message are charged to the sender. The sender of the parent message is therefore treated as the owner of the information contained in both messages. Accordingly, local saving, printing, forwarding, and replying to prepaid reply message 802 by sender of the parent message are all permitted. In one embodiment, local saving, printing, forwarding, and replying to prepaid reply message 802 by any other recipient of prepaid reply message 802 are all prohibited. In an alternative embodiment, local saving, printing, forwarding, and replying to prepaid reply message 802 by any other recipient of prepaid reply message 802 are all controlled by respective fields of the parent message — e.g., save enable field 622, print enable field 624, forward enable field 626, and reply enable field 628, respectively, of message 502. In this alternative embodiment, a third-party recipient of a prepaid reply message had the same handling options with respect to prepaid reply message 802 as with respect to message 502.

Rather than determining the language of the message from data within the message itself (e.g., language field 632 — Figure 6 — of message 502), server computer system (Figure 3) presents prepaid reply message 802 (Figure 8) using the language specified by the parent message, e.g., by language 632 (Figure 6) of message 502.

Lastly, instead of billing the recipient for sending prepaid reply message 802, server computer system 104 bills the account specified in the parent message, e.g., the account specified in billing code 642 (Figure 6) of message 502.

Thus, in accordance with the present invention, the sender can provide the recipient with a convenient mechanism for replying to a message from the sender. For the recipient's convenience, even if the recipient is not a registered user of the message delivery system of server computer system 104, the sender can permit the recipient to use the same level of security provided by server computer system 104 available to the sender and can allow the recipient to reply free of charge. In addition, the sender can limit the service provided to the recipient with respect to number, addressing, size, formats, security and priority to thereby limit the charges which can accrue to the sender by the recipient's reply. The above description is illustrative only and is not limiting. The present invention d only by the claims which follow.

Claims

What is claimed is:

1. A method for controlling processing of a message from a sender to a recipient, the method comprising: receiving, from the sender, data specifying a type of action with respect to the message which is permissible for the recipient; and associating control data representing the type of action with the message such that representation of the message to the recipient enables the type of action for the recipient with respect to the message.

2. The method of Claim 1 wherein the type of action is saving the message to persistent storage.

3. The method of Claim 1 wherein the type of action is printing the message.

4. The method of Claim 1 wherein the type of action is forwarding the message to one or more other recipients.

5. The method of Claim 1 wherein the type of action is replying to the message by sending a second message, which is different from the first-mentioned message, to the sender.

6. The method of Claim 5 wherein any costs associated with the second message are charged to the sender.

7. The method of Claim 6 further comprising: receiving, from the sender, limitation data specifying a limitation on the type of action; and associating the limitation with the message such that the limitation enforced.

8. The method of Claim 7 wherein the limitation data specifies that the second message can only be addressed to the sender.

9. The method of Claim 7 wherein the limitation data specifies that the second message can only be addressed to one or more other recipients of the first message.

10. The method of Claim 7 wherein the limitation data specifies a level of security with which to process the second message.

11. The method of Claim 7 wherein the limitation data specifies a priority with which to deliver the second message.

12. The method of Claim 7 wherein the limitation data specifies, as a maximum permissible size, a maximum permissible amount of data that can be used to represent the second message.

13. The method of Claim 12 wherein the maximum permissible amount of data applies to the second message and any data files attached to the second message by the recipient.

14. The method of Claim 7 wherein the limitation data specifies one or more permissible data formats of any attached data files of the second message.

15. The method of Claim 7 wherein the limitation data specifies a maximum number of times the recipient can reply to the first message such that costs associated with such replies are charged to the sender.

16. The method of Claim 7 wherein the limitation data limits the format of the second message.

17. The method of Claim 16 wherein the limitation data specifies data entry constraints.

18. The method of Claim 16 wherein the limitation data include logic for validating entered data.

19. The method of Claim 7 wherein the limitation data specifies an HTML form.

20. The method of Claim 7 wherein the limitation data specifies data in an XML format.

21. The method of Claim 1 wherein the type of action is enabled for the recipient by including with the message data which specifies a user interface by which the recipient can invoke the type of action.

22. The method of Claim 1 wherein the type of action is enabled for the recipient by including data which specifies a user interface by which the recipient can modify a parameter of the type of action.

23. A method for controlling processing of a message from a sender to a recipient, the method comprising: receiving, from the sender, data specifying a type of action with respect to the message which is prohibited for the recipient; and associating control data representing the type of action with the message such that representation of the message to the recipient disables the type of action for the recipient with respect to the message.

24. The method of Claim 23 wherein the type of action is saving the message to persistent storage.

25. The method of Claim 23 wherein the type of action is printing the message.

26. The method of Claim 23 wherein the type of action is forwarding the message to a second recipient, which is different from the first-mentioned recipient.

27. The method of Claim 23 wherein the type of action is replying to the message by sending a second message, which is different from the first-mentioned message, to the sender.

28. The method of Claim 23 wherein the type of action is disabled for the recipient by excluding from the message a user interface by which the recipient can invoke the type of action.

29. The method of Claim 23 wherein the type of action is disabled for the recipient by specifying a parameter of the type of action and excluding a user interface by which the recipient could modify the parameter.

30. A computer readable medium useful in association with a computer which includes a processor and a memory, the computer readable medium including computer instructions which are configured to cause the computer to control processing of a message from a sender to a recipient by: receiving, from the sender, data specifying a type of action with respect to the message which is permissible for the recipient; and associating control data representing the type of action with the message such that representation of the message to the recipient enables the type of action for the recipient with respect to the message.

31. The computer readable medium of Claim 30 wherein the type of action is saving the message to persistent storage.

32. The computer readable medium of Claim 30 wherein the type of action is printing the message.

33. The computer readable medium of Claim 30 wherein the type of action is forwarding the message to one or more other recipients.

34. The computer readable medium of Claim 30 wherein the type of action is replying to the message by sending a second message, which is different from the first- mentioned message, to the sender.

35. The computer readable medium of Claim 34 wherein any costs associated with the second message are charged to the sender.

36. The computer readable medium of Claim 35 wherein the computer instructions are configured to cause the computer to control processing of a message from a sender to a recipient by also: receiving, from the sender, limitation data specifying a limitation on the type of action; and associating the limitation with the message such that the limitation enforced.

37. The computer readable medium of Claim 36 wherein the limitation data specifies that the second message can only be addressed to the sender.

38. The computer readable medium of Claim 36 wherein the limitation data specifies that the second message can only be addressed to one or more other recipients of the first message.

39. The computer readable medium of Claim 36 wherein the limitation data specifies a level of security with which to process the second message.

40. The computer readable medium of Claim 36 wherein the limitation data specifies a priority with which to deliver the second message.

41. The computer readable medium of Claim 36 wherein the limitation data specifies, as a maximum permissible size, a maximum permissible amount of data that can be used to represent the second message.

42. The computer readable medium of Claim 41 wherein the maximum permissible amount of data applies to the second message and any data files attached to the second message by the recipient.

43. The computer readable medium of Claim 36 wherein the limitation data specifies one or more permissible data formats of any attached data files of the second message.

44. The computer readable medium of Claim 36 wherein the limitation data specifies a maximum number of times the recipient can reply to the first message such that costs associated with such replies are charged to the sender.

45. The computer readable medium of Claim 36 wherein the limitation data limits the format of the second message.

46. The computer readable medium of Claim 45 wherein the limitation data specifies data entry constraints.

47. The computer readable medium of Claim 45 wherein the limitation data include logic for validating entered data.

48. The computer readable medium of Claim 36 wherein the limitation data specifies an HTML form.

49. The computer readable medium of Claim 36 wherein the limitation data specifies data in an XML format.

50. The computer readable medium of Claim 30 wherein the type of action is enabled for the recipient by including with the message data which specifies a user interface by which the recipient can invoke the type of action.

51. The computer readable medium of Claim 30 wherein the type of action is enabled for the recipient by including data which specifies a user interface by which the recipient can modify a parameter of the type of action.

52. A computer readable medium useful in association with a computer which includes a processor and a memory, the computer readable medium including computer instructions which are configured to cause the computer to control processing of a message from a sender to a recipient by: receiving, from the sender, data specifying a type of action with respect to the message which is prohibited for the recipient; and associating control data representing the type of action with the message such that representation of the message to the recipient disables the type of action for the recipient with respect to the message.

53. The computer readable medium of Claim 52 wherein the type of action is saving the message to persistent storage.

54. The computer readable medium of Claim 52 wherein the type of action is printing the message.

55. The computer readable medium of Claim 52 wherein the type of action is forwarding the message to a second recipient, which is different from the first-mentioned recipient.

56. The computer readable medium of Claim 52 wherein the type of action is replying to the message by sending a second message, which is different from the first- mentioned message, to the sender.

57 The computer readable medium of Claim 52 wherein the type of action is disabled for the recipient by excluding from the message a user interface by which the recipient can invoke the type of action.

58. The computer readable medium of Claim 52 wherein the type of action is disabled for the recipient by specifying a parameter of the type of action and excluding a user interface by which the recipient could modify the parameter.

59. A computer system comprising: a processor; a memory operatively coupled to the processor; and a message delivery module (i) which executes in the processor from the memory and (ii) which, when executed by the processor, causes the computer to control processing of a message from a sender to a recipient by: receiving, from the sender, data specifying a type of action with respect to the message which is permissible for the recipient; and associating control data representing the type of action with the message such that representation of the message to the recipient enables the type of action for the recipient with respect to the message.

60. The computer system of Claim 59 wherein the type of action is saving the message to persistent storage.

61. The computer system of Claim 59 wherein the type of action is printing the message.

62. The computer system of Claim 59 wherein the type of action is forwarding the message to one or more other recipients.

63. The computer system of Claim 59 wherein the type of action is replying to the message by sending a second message, which is different from the first-mentioned message, to the sender.

64. The computer system of Claim 63 wherein any costs associated with the second message are charged to the sender.

65. The computer system of Claim 64 wherein the message delivery module is configured to cause the computer to control processing of a message from a sender to a recipient by also:: receiving, from the sender, limitation data specifying a limitation on the type of action; and associating the limitation with the message such that the limitation enforced.

66. The computer system of Claim 65 wherein the limitation data specifies that the second message can only be addressed to the sender.

67. The computer system of Claim 65 wherein the limitation data specifies that the second message can only be addressed to one or more other recipients of the first message.

68. The computer system of Claim 65 wherein the limitation data specifies a level of security with which to process the second message.

69. The computer system of Claim 65 wherein the limitation data specifies a priority with which to deliver the second message.

70. The computer system of Claim 65 wherein the limitation data specifies, as a maximum permissible size, a maximum permissible amount of data that can be used to represent the second message.

71. The computer system of Claim 70 wherein the maximum permissible amount of data applies to the second message and any data files attached to the second message by the recipient.

72. The computer system of Claim 65 wherein the limitation data specifies one or more permissible data formats of any attached data files of the second message.

73. The computer system of Claim 65 wherein the limitation data specifies a maximum number of times the recipient can reply to the first message such that costs associated with such replies are charged to the sender.

74. The computer system of Claim 65 wherein the limitation data limits the format of the second message.

75. The computer system of Claim 16 wherein the limitation data specifies data entry constraints.

76. The computer system of Claim 16 wherein the limitation data include logic for validating entered data.

77. The computer system of Claim 65 wherein the limitation data specifies an HTML form.

78. The computer system of Claim 65 wherein the limitation data specifies data in an XML format.

79. The computer system of Claim 59 wherein the type of action is enabled for the recipient by including with the message data which specifies a user interface by which the recipient can invoke the type of action.

80. The computer system of Claim 59 wherein the type of action is enabled for the recipient by including data which specifies a user interface by which the recipient can modify a parameter of the type of action.

81. A computer system comprising: a processor; a memory operatively coupled to the processor; and a message delivery module (i) which executes in the processor from the memory and (ii) which, when executed by the processor, causes the computer to control processing of a message from a sender to a recipient by: receiving, from the sender, data specifying a type of action with respect to the message which is prohibited for the recipient; and associating control data representing the type of action with the message such that representation of the message to the recipient disables the type of action for the recipient with respect to the message.

82. The computer system of Claim 81 wherein the type of action is saving the message to persistent storage.

83. The computer system of Claim 81 wherein the type of action is printing the message.

84. The computer system of Claim 81 wherein the type of action is forwarding the message to a second recipient, which is different from the first-mentioned recipient.

85. The computer system of Claim 81 wherein the type of action is replying to the message by sending a second message, which is different from the first-mentioned message, to the sender.

86. The computer system of Claim 81 wherein the type of action is disabled for the recipient by excluding from the message a user interface by which the recipient can invoke the type of action.

87. The computer system of Claim 81 wherein the type of action is disabled for the recipient by specifying a parameter of the type of action and excluding a user interface by which the recipient could modify the parameter.