WO2003061213A1

WO2003061213A1 - Method for electronic mail notice and download

Info

Publication number: WO2003061213A1
Application number: PCT/KR2003/000060
Authority: WO
Inventors: Tae-Joon Kim
Original assignee: Tae-Joon Kim
Priority date: 2002-01-17
Filing date: 2003-01-13
Publication date: 2003-07-24
Also published as: AU2003235658A1; KR20040074118A

Abstract

The email system based on a recipient mailbox has a structural weakness, which may cause the spam message problem and the waste of recipient mailbox space, and also require an explicit recipient notification scheme. To overcome the weakness, a new email method, called downemail, is designed. A sender mailbox at a source downemail server is introduced and the place at which an original message is stored until an intended recipient reads it is moved from the recipient mailbox at a destination downemail server to the sender mailbox. To relay a message from the email system to the downemail system, a message interworking server is also designed. The source downemail server generates a signaling message to notify the sending of a message and then transmits it to an intended recipient. After reading the signaling message, the recipient can get the original message from the sender mailbox.

Description

AN INTERNET MAIL METHOD AND SYSTEM BASED ON SENDER

MAILBOX

Technical Field

The present invention relates generally to electronic mail, and more particularly to an internet mail based on sender mailbox and a message interworking between this new mail system and a conventional internet mail system based on recipient mailbox.

Background Art

Internet mail, called email, is a very useful tool for promoting communication between people who are separated by distance, by different working hours, or both. The message delivery model of the email system is generally based on a recipient mailbox like that of the offline post office system. The email system basically consists of a sender terminal, a source email server, a destination email server and a recipient terminal. A sender prepares a message at the sender terminal, and then the terminal sends the message to the source email server using simple mail transfer protocol (SMTP) or hypertext transfer protocol (HTTP). The source email server receives an incoming message from the sender terminal and relays it to the destination email server using SMTP. The destination email server receives an incoming message from the source email server and stores it at a recipient mailbox assigned to the message's recipient. The recipient at the recipient terminal retrieves the message from his or her recipient mailbox at the destination email server using post office protocol 3 (POP3), internet mail access protocol (IMAP) or HTTP and reads it. Under this email system, a source email server has nearly no burden on message delivery since it only relays an incoming message to a destination email server while the destination email server takes over most of burden on message delivery because it has a mailbox storing the incoming message. The destination email server should basically receive any incoming message from any sender regardless of message data, even though the message's recipient does not want to read it, and store the message at the recipient's recipient mailbox until the recipient retrieves or deletes it. This structural feature may cause the spam message problem. For a message with multiple recipients, message data is broadcasted to all designated recipients, which leads to an extreme waste of mailbox space. In addition, any sender cannot access a recipient mailbox containing a message sent from the sender. This structural feature means that it is so hard for a sender to confirm without any help of recipient side whether an intended recipient has read the sender's message or not.

Disclosure of the Invention

The object of the present invention is to overcome the structural deficiencies of the email system based on recipient mailbox described above. The present invention provides a new internet email method and system based on sender mailbox, called downemail. A sender mailbox at a source downemail server is introduced and the place at which a message is stored until a recipient reads the message is moved from an intended recipient's recipient mailbox at a destination downemail server to the sender mailbox of the message's sender. In addition, a message interworking server -is also provided to relay a message from the email system to the downemail system. A source downemail server creates a signaling message to notify the sending of the message after storing an incoming message at a sender mailbox, and then sends it to an intended recipient. After reading the signaling message, the recipient can download the original message from the sender mailbox at the source downemail server.

Brief Description of the Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments, of the invention and, together with the description, serve to explain the principles of the invention:

Fig. 1 shows a message flow diagram illustrating message delivery model under a downemail method;

Fig. 2 shows a block diagram illustrating the structure of a downemail system and message interworking between the downemail and email systems;

Fig. 3 shows a block diagram illustrating the format of a message sending notification message;

Fig. 4 shows a flowchart illustrating the operation of a message transfer agent enhanced with downemail features;

Fig. 5 shows a flowchart illustrating the user message transferring of sender mailbox manager; and

Fig. 6 shows a flowchart illustrating the use message downloading of recipient terminal.

Best Mode for Carrying Out the Invention

MESSAGE DELIVERY MODEL ON A DOWNEMAIL SYSTEM

Fig.l shows the message delivery model under a downemail method. The downemail system basically consists of a sender terminal 101, a source downemail server 102, a destination downemail server 103 and a recipient terminal 104, which has a similar structure to an email system. In addition, the downemail system can have a message interworking server for message delivery between the email and downemail systems. Messages are classified into a user message and a signaling message to support the delivery of the user message.

There are two types of mailboxes. One is a sender mailbox 106 located at a source downemail server for storing user message and another is a recipient mailbox 105 at a destination downemail server for storing signaling message. All senders registered on a source downemail server have their own sender mailboxes. Differently from the email system, all user messages are stored at a sender mailbox instead of a recipient one.

A source downemail server 102 stores an incoming message from a sender at his or her sender mailbox 106, creates a message sending notification message and then sends it to a destination downemail server 103. The destination downemail server receives the sending notification message and stores at an intended recipient's recipient mailbox 105. The recipient reads the sending notification message and then requests the downloading of the original message being stored at the sender mailbox to the source downemail server if want to read it. A user identification and a password needed to access the sender mailbox and the address of the source downemail server are carried by the sending notification message to the recipient. After authentication, the source downemail server 102 transfers the original message to the recipient and removes the message at the sender mailbox 106. The sender can easily confirm with checking his or her sender mailbox whether the recipient has read the message or not.

The sending notification message acts as a soliciting request, which means "I would like to send a message to you". The recipient simply clicks on a hyperlink part in the sending notification message to retrieve the message. The clicking acts as a positive soliciting response that means "you are allowed to send your message to me".

OVERALL STRUCTURE OF A DOWNEMAIL SYSTEM

Fig. 2 shows a detailed block diagram of a downemail system. The block diagram comprises three parts of an email zone, a downemail zone and a message interworking server 200. The email zone is an email service area supported by the email system^" based on recipient mailbox. The downemail zone is a downemail service area supported by the new email system based on sender mailbox. The message interworking server is a facility supporting message delivery from an email zone to a downemail zone. This interworking server may be not needed if all user at a downemail zone does not want to receive incoming messages from any email zone or if all email zones are replaced with downemail zones.

Functional blocks defined at a downemail system are as follows:

Message transfer agent (MTA) 215 performs a message transfer function at the email zone! Enhanced message transfer agent (MTA_n) 205 is a MTA enhanced with downemail features;

User agent (UA) is to help a sender and/or recipient and it is located at sender terminals 201 211 and/or recipient terminals 204 214;

Recipient mailbox (RMB) 207 is to store an incoming message at destination downemail and destination email servers, and all recipients have their own recipient mailboxes;

Sender mailbox (SMB) 209 is to store an incoming user message at a source downemail server and all senders registered on a source downemail server have their own sender mailboxes; Recipient mailbox manager (RMM) 206 is to manage the RMB 207; and

Sender mailbox manager (SMM) 208 is to manage the SMB 209. The email zone consists of four equipments as follows: 1) a sender terminal 211 at which a sender prepares a message and sends it to a source email server; 2) a source email server 212 that receives an incoming message from the sender terminal and relays it to a destination email server; 3) a destination email server 213 that receives an incoming message from the source email server and stores it at a RMB 207; and 4) a recipient terminal 214 at which a recipient downloads a message from his or her recipient mailbox at the destination email server. The source email server 212 has only a MTA 215 while the destination email server 213 has a MTA 215, a RMM 206 and a RMB 207.

The downemail zone consists of a sender terminal 201, a source downemail server 202, a destination downemail server 203 and a recipient terminal 204. At the sender terminal a sender prepares a message and sends it to the source downemail server. The source downemail server receives an incoming message from the sender terminal, stores the message at the sender's SMB 209, creates a message sending notification message, sends it to the destination downemail server. The source downemail server also transfers a user message to a recipient when the recipient requests the downloading of the user message. The destination downemail server receives the message sending notification message from the source downemail server, stores it at an intended recipient's RMB 207. The destination downemail server also transfers the notification message to a recipient when the recipient requests it. At the recipient terminal a recipient retrieves the message notification notification message from the destination downemail server and checks it, and downloads a user message from the source downemail server if want to read it.

The message interworking server 200 consists of a MTA_n 205, a SMB 209 and a SMM 208. The SMB 209 stores a user message being transferred from a sender on the email zone to a recipient on the downemail zone, and the SMM 208 transfers the user message stored at the SMB to a recipient when the recipient requests the downloading of the user message. The downemail servers 202 203 and the message interworking server 200 have all the same MTA_n 205, SMB 209 and SMM 208.

In Fig.2, standardized protocols used in an email zone are also used as communication protocols among all equipments as follows. SMTP or HTTP is used in message transferring from a sender terminal 201 to a source downemail server 202. SMTP is also used in message transferring among downemail servers 202 203, email servers 212 213 and a message interworking server 200. IMAP, P0P3 or HTTP is used in message transferring from a source downemail server 202 to a recipient terminals 204 214, in message transferring from a destination downemail server 203 to a recipient terminal 204 and in message transferring from a message interworking server 200 to a recipient terminal 204.

MESSAGE CLASSIFICATION

Messages being transferred on the downemail zone are classified into a user message and a signaling message in the aspect of message body's size. The signaling message is used to support the delivery of the user message. There are basically two types of signaling messages; one is a message sending notification (MSN) message to notify message sending from a sender to an intended recipient and another is a message reading notification (MRN) message to notify message reading from a recipient to the message's sender. The difference between the user and signaling messages is only the size of message body. A message is called user message if the size of its body is larger than a predefined size, otherwise it is called signaling message. The predefined size is 100 bytes, which may be adjusted later. Messages are also classified into a unicasting message and a multicasting message in the aspect of the number of recipients. A message with a single recipient is called unicasting message while a message with multiple recipients is called multicasting message.

MESSAGE DELIVERY FLOW

The downemail system supports an intra-zone message delivery within the downemail zone and an inter-zone message delivery between the email and downemail zones.

The intra-zone message delivery flow is as follows: 1) a source downemail server 202 stores an incoming user ^' message from a sender using a sender terminal 201 at the sender's sender mailbox 209 and then sends a MSN message to a destination downemail server 203;

2) the destination downemail server 203 receives the MSN message and stores at an intended recipient's recipient mailbox 207; and

3) the recipient at the recipient terminal 204 reads the MSN message and downloads the user message from the source downemail server 202 if he or she wants to read it.

The inter-zone message delivery is divided into a message delivery from the downemail zone to the email zone and a message delivery from the email zone to the downemail zone. The message delivery flow from the email zone to the downemail zone is as follows:

1) a source email server 212 relays an incoming user message from a sender at a sender terminal 211 to a destination downemail server

203;

2) the destination downemail server 203 relays the user message to a message interworking server 200 because it can not handle the user message; 3) _,the message interworking server 200 stores the incoming user message at a sender mailbox 209 allocated to the message's recipient and then sends a MSN message to the destination downemail server 203; 4) the destination downemail server 203 stores the MSN message at an intended recipient's recipient mailbox 207; and 5) the recipient at the recipient terminal 204 reads the MSN message and downloads the user message from the message interworking server 200 if he or she wants to read it.

The message delivery flow from the downemail zone to the email zone s as follows:

1) a source downemail server 202 stores an incoming user message from a sender using a sender terminal 201 at the sender's sender mailbox 209 and then sends a MSN message to a destination email server 213; 2) the destination email server 213 receives the MSN message and stores at an intended recipient's recipient mailbox 207; and 3) the recipient at the recipient terminal 214 reads the MSN message and downloads the user message from the source downemail server 202 if he or she wants to read it.

SENDER MAILBOX

A SMB 209 is to store the original copy of user message. All senders registered on a source downemail server 202 have their own sender mailboxes. The SMB for unicasting messages can be implemented by the directory of "/smb/sender_id/recipient_id/message#/". Each message storage in the SMB is identified by "sender_id", "recipient_id" and "message#". The "sender_id" is to identify each sender sending message via a source downemail server 202 or a message interworking server 200. This "sender_id" can be easily made up using the user identification part and/or the domain name part of the sender's email address. The "recipient_id" is to identify each recipient receiving message from the sender, and this "recipient_id" can be made up using a string comprising the recipient's email address except special characters such as "@" and ".". The "message#" is to identify each message when the sender sends multiple messages to the same recipient.

Each message storage in a SMB, that is, the directory of "/smb/sender_id/recipient_id/message#/" has two kinds of files; one is to store a user message data itself and another is to store a password needed to authenticate a recipient accessing to the message storage.

For a multicasting message, only very small portion of message data, called individual message data, such as a recipient's email address is transferred to only a particular recipient while most portion of message data, called common message data, such as message subject and message body is broadcasted to all designated recipients. The common message data is stored at common message storage while the individual message data is stored at an individual message storage, which leads to reducing the space of the sender mailbox 209.

The common message storage can be implemented by the directory of "/smb/sender_id/m_message/". The "sender_id" is the same as that of the sender mailbox for an uncasting message described above. The individual message storage has the same directory as the sender mailbox for a unicasting message, that is "/smb/sender_id/recipient_id/message#/".

The procedure to store a multicasting message at a sender mailbox 209 can be implemented as the following steps: 1) extracts a "sender_id" from the sender's email address of the message; 2) makes a common message storage, for example, the directory of 7smb/sender_id/aaa/" ; 3) creates a file (B file) containing common message data, a file (C file) containing the number of designated recipients, a file (D file) containing the number of recipients who have read the message and a file (R file) containing the email addresses of all designated recipients, and stores those files at the common message storage; 4) creates an individual message storage; and 5) creates a file (H file) containing individual message data , a file (0 file) containing a directory path to the common message storage and a file (P file) with a password, and stores those files at the individual message storage. A sender should have a user account at a source downemail server

202 to send a message via the server. When the user account is registered, the sender's sender mailbox 209, the directory of "/smb/sender_id/" , is created.

Since a sender mailbox 209 located at a message interworking server 200 is to store messages from unknown senders at the email zone to recipients at the downemail zone, the sender mailbox is allocated to each recipient at the downemail zone. This sender mailbox can be implemented by the same directory of "/smb/sender_id/recipient_id/message#/" as the sender mailbox in a source downemail server 202 or implemented by a recipient-oriented directory of "/smb/recipient_id/sender_id/message#/".

Note that the sender mailbox 209 in a source downemail server 202 or a message interworking server can 200 be also implemented by a data base management system.

SIGNALING MESSAGES

Fig. 3 shows the format of a message sending notification (MSN) message. The MSN message 301 consists of a message head 302, and a message body. The subject of the MSN message is comprised of a prefix meaning message sending notification, for example, "No:" and the subject of an original message. The message body also consists of the mandatory field of access information 303 and optional fields comprising a message size 304, a help site 305 and cited message data 306. The access information field 303 also consists of server identification, user identification and a password. The user identification and the password are used to authenticate a recipient who wants to read a message stored at a SMB 209. In particular, the user identification is also used to search fastly the message stored at the SMB since it has information about the directory path. The server identification denotes the domain name or the internet address of a server with the SMB storing the message, that is, a source downemail server 202 or a message interwork server 200. The access information 303 can be configured with hypertext markup language (HTML) and common gateway interface (CGI) command.

The message size 304 denotes the size of message in kilobytes. The help site 305 is to help a user who wanders how to use a downemail system, and this field can be also configured with HTML. So if a user clicks on the help site field, a web page explaining the downemail system is displayed. The cited message data 306 has a string randomly cited from the message body data, and its size is limited by the condition of the MSN message's size less than or equal to the maximum size of a signaling message.

The recipient reading notification (RRN) message can be used to notify the fact that a recipient has read a sender's message. Its size is also limited by the maximum size of signaling message. The message head of a RRN message can be comprised of a prefix meaning recipient reading notification, for example "Re:" and the subject of an original message.

MESSAGE TRANSFER AGENT ENHANCED WITH DOWNEMAIL FEATURES

A MTA_n 205 in the source downemail, destination downemail and message interworking servers is that a MTA 215 in source and destination email servers is enhanced to have downemail features such as sender mailbox and message interworking. The configuration data of the MTA_n tells at which server the MTA_n locates. Differently from a destination email server, a destination downemail server can handle only signaling message such as a MSN message. When a destination downemail server 203 receives an incoming user message, the server relays the message to a message interworking server 200 if equipped, otherwise it rejects the message.

Fig. 4 shows a flowchart illustrating the MTA_n's operation. When a MTA_n 205 receives (400) an incoming message, the MTA_n checks (401) with its configuration data whether its location is a message interworking server or not. If the MTA_n is not located at a message interworking server, it also checks with its configuration data at which downemail server it locates. The MTA_n checks (402) whether the incoming message can be relayed in the case that its location is a source downemail server. If the message can be relayed, the MTA_n checks (403) the type of the message. If the message is the type of user message, it extracts a "sender_id" from the sender's email address, and then stores (404) the message data at the sender's sender mailbox as follows. The MTA_n extracts a "recipient_id" from the email address of the message's recipient and creates a message storage for the message, that is, the directory of "7smb/sender_id/recipient_id/message#/". A file with the message data and a file with a password are stored at this directory. And then the MTA_n creates (406) a MSN message and then sends (407) it to an intended recipient. In this message storing procedure, a related SMTP error code is returned (408) if the sender's sender mailbox is not registered or not enough.

For a multicasting message, the message storing procedure of the

MTA_n is as follows. The MTA_n 205 creates a common message storage and stores a C file with zero value and a D file with zero value at the common message storage. And the MTA_n generates B and R files for the message and also stores them at the common message storage. The MTA_n generates a MSN message for each recipient and then sends it to the recipient. By this time, the MTA_n creates the O, H and P files for each recipient and stores them at the individual message storage for the recipient, and increases the number of designated recipients at the C file. The MTA_n checks (402) the destination of the incoming message in the case that its location is a destination downemail server. If the destination downemail server at which the MTA_n locates is the destination of the incoming message, it handles the message as follows. If the message is the type of signaling message in checking (409) message type, the message is stored at an intended recipient's RMB 207, otherwise the message is relayed (412) to a message interworking server if the server is available (411). If a message interworking server is not available, the MTA_n returns a related SMTP error code to a source email server and sends an error message meaning the failure of message delivery to the message's sender (413).

In the case that the MTA_n 205 is located at a message interworking server in checking (401) its configuration data, it extracts a "senderjd" from the sender's email address and a "recipient_id" from the email address of the message's recipient, authenticates (415) whether the message can be handled in the server, and then stores (416) the message at a sender mailbox allocated to the message's recipient as follows. The MTA_n creates a message storage at a sender mailbox, that is, the directory of "/smb/sender_id/recipient_id/message#/" or "/smb/recipient_id/sender_id/ message#/". The message data and a password are stored at this message storage. And then the MTA_n generates (406) a MSN message and sends (407) it to the recipient. In this message storing procedure, the MTA_n sends an error message meaning the failure of message delivery to the sender if a sender mailbox allocated to the message's recipient is not available.

SENDER MAILBOX MANAGER

A SMM 208 located at a source downemail server has four kinds of functions: 1) a message downloading function that transfers a user message stored at a sender mailbox to the recipient when a recipient requests the downloading of the user message; 2) a SMB management function being operated by a sender's request, that is, a sender's SMB management function; 3) a SMB management function being operated by itself; and 4) a web mail sending function. The SMM 208 located at a message interworking server has only the message downloading function and the SMB management function being operated by itself.

The message downloading function performs a similar operation to a RMM 206 in a destination email server. This function can be implemented with two kinds of methods, a conventional downloading method using POP3 and IMAP, and a web-based downloading method using HTTP.

Fig. 5 shows a flowchart illustrating the message downloading function. The conventional downloading method for a unicasting message operates as follows. When a SMM receives (501) a recipient's request to read a user message, it searches the directory storing the user message using a user identification and authenticates (502) the recipient using a password. The user identification and the password are carried by the message request signal from the recipient. And then the SMM transfers the user message to the recipient and removes the directory in according to recipient's deleting request. By this time, the SMM writes detailed information for the message downloading such as message subject, recipient, sending time, and downloading time at a log file. And finally, the SMM sends (504) a recipient reading notification message to the sender. For a multicasting message, the conventional downloading function operates as follows. With a user identification and a password carried by a message request signal from a recipient the SMM searches the corresponding individual message storage at a sender mailbox and authenticates the recipient. The SMM reorganizes the user message with a H file in the individual message storage and a B file in a common message storage, and transfers the message to the recipient. An 0 file in the individual message storage is used to find the common message storage for the message. The SMM also writes detailed information about the message downloading such as message subject, recipient, sending time and downloading time at a log file. And then the SMM removes the individual message storage in according to the recipient's message deleting request. By this time, the SMM decreases the counter in a C file and increases the counter in a D file. If the counter in the C file reaches to zero value, which means that all designated recipients have read the user message, the SMM removes the common message storage. In the case of a source downemail server with both a SMM and a RMM, the conventional downloading function of the SMM can be implemented with two kinds of methods. One is an independent implementation method under which the SMM is configured as a separate program and a new TCP/UDP port number is assigned to the program. Another is an integrated implementation method under which the SMM is integrated into a RMM program, and it shares the TCP/UDP port number assigned to the RMM, and the characteristic of string comprising user identification is used to distinguish to which mailbox manager a user wants to access.

The web-based downloading function performs the same operation as the conventional downloading function except using the HTTP between a SMM and a recipient terminal.

The SMB management function being operated by a sender's request can be also implemented with two kinds of methods in the aspects of communication protocol between a sender terminal and a source downemail server; one is a conventional sender's SMB management function using POP3 or IMAP, and another is a web-based sender's SMB management function using HTTP.

When a sender accesses to a SMM 208 via POP3 or IMAP, the conventional sender's SMB management function begins to operate. The management service provided by this function and the operation of this function are as follows. A user agent in a sender terminal 201 provides a SMB management window with viewing and deleting menus. When the sender clicks on the viewing menu, the user agent requests detailed information about all messages being stored at the sender's sender mailbox to the SMM. The SMM extracts the information from the sender's sender mailbox and transfers to the user agent. And then the user agent displays the information at the SMB management window. When the sender clicks on the deleting menu for a particular unicasting message, the user agent relays this request to the SMM, and then the SMM removes the message at the sender mailbox. In addition, the user agent provides multicasting message deleting and individual message deleting menus for multicasting messages. When the sender clicks on the multicasting message deleting menu for a multicasting message, the user agent relays the request to the SMM, and then the SMM removes all individual message storages and common message storage for the message at the sender's sender mailbox. When the sender clicks on the individual message deleting menu for an individual message sent to a particular recipient, the user agent relays the request to the SMM, and then the SMM removes an individual message storage for the recipient. By this time, if the recipient is the last recipient that has not read the multicasting message yet, then the SMM also deletes the common message storage for the multicasting message.

When a sender accesses to a SMM in a source downemail server via HTTP, the web-based sender's SMB management function begins to operate. For a unicasting message, the management service provided by this function and the operation of this function are as follows. After authenticating the sender, the SMM provides a SMB management window with mailbox space, message management and recipient reading notification menus. If the sender clicks on the mailbox space menu, the SMM gets some information about the sender's sender mailbox itself such as allocated space, used space and available space, and then displays the information at the sender terminal. If the sender clicks on the message management menu, the SMM provides several management submenus for messages being stored at the sender's sender mailbox, which consist of overview, detailed view, message deleting based on sending time, message deleting based on recipient group and individual message deleting. The overview submenu tells simple information such as recipient, subject and sending time. The detailed view submenu displays a message itself selected on the overview submenu. The message deleting based on sending time submenu removes all messages sent at specific sending time interval defined by the sender. The message deleting based on recipient group removes all messages sent to a specific recipient group defined by the sender. The individual message deleting submenu removes a specific message defined by the sender.

If the sender clicks on the recipient reading notification menu, the SMM provides detailed information about each message that its intended ^■recipient has already read the message, such as subject, sending time, recipient, and reading time. The SMM extracts the information from a log file keeping detailed information about the transferring of the message to a recipient.

The web-based SMB management function for a multicasting message operates as follows. A SMM provides a multicasting message management window with viewing, deleting and recipient reading notification menus when a sender accesses to the SMM using HTTP. If the sender clicks on the viewing menu, the management window displays simple information such as subject, recipient, sending time, the number of designated recipients, the number of recipients that have not read yet for each multicasting message being stored at the sender's sender mailbox. If the sender clicks on a field in the result window of the viewing menu, more detailed information about the selected field is displayed. If the sender clicks on the deleting menu, submenus of message deleting based on sending time, multicasting message deleting, recipient-based message deleting and individual message deleting are also provided. If the sender clicks on the recipient reading notification submenu, the SMM provides some information for a multicasting message such as subject, sending time, recipients who have already read the message, and their message reading times. The SMM extracts the information from a log file keeping detailed information about the transferring of the multicasting message to recipients.

A SMM 209 located at a source downemail server performs a SMB management function by itself as follows. The SMM investigates used mailbox space, available mailbox space, messages being stored for too long time for each sender's sender mailbox, and notifies the investigation results to the sender. If necessary, the SMM removes messages being stored for too long time and notifies removing results to the sender. The SMM 209 located at a message interworking server also performs a SMB management function by itself as follows. The SMM investigates used mailbox space, available mailbox space, message being stored for too long time for each recipient's sender mailbox, and notifies investigation results to the recipient. If necessary, the function removes a message being stored for too long time and then sends a message with removing results to the message's sender at an email zone.

MESSAGE DOWNLOADING OF A RECIPIENT TERMINAL

Fig. 6 shows a flowchart illustrating the operation of a recipient terminal for message downloading. A recipient decides (602) whether to read a user message with checking (601) a MSN message for the user message. The procedure to read a user message is the same as that to read a MSN message except using different access information comprised of server identification, user identification and password. There are two kinds of methods in reading the user message. One is a conventional method using POP3 and IMAP and another is a web-based method using HTTP. For the conventional method, a recipient can read a user message automatically or manually. Most commercial user agent programs such as Microsoft "Outlook" requires the configuration of the SMTP server identification, user identification and password fields in their installation steps. These user agent programs can be used without any modification to read the user message at the downemail zone, but a procedure to reconfigure the SMTP server identification, user identification and password with those carried by a MSN message should be performed (605). This reconfiguration procedure may be embedded on the user agent programs by upgrading or using a plug-in module, and then a recipient can read (606) easily a user message with only clicking on a "view message" menu of user agent program. For the web-based method, a recipient can read (607) the user message on the recipient terminal with only clicking on the hyperlink part meaning access information 303 in a MSN message.

Industrial Applicability

As described above, the present invention provides not only a downemail method and system based on sender mailbox but also a message interworking server for message delivery from an email zone to a downemail zone.

The merits of the present invention may be summarized as follows: a moral hazard in sending message may be technically restrained since the burden of message storing and spam message deleting is now shifted to the sender side and also detailed information about a sender mailbox is exposed to a recipient by a message sending notification message; a sender can confirm without any help of the recipient side whether a recipient has read a message sent from the sender or not; since only very short message such as a message sending notification message is stored at a recipient mailbox, the load of a destination downemail server can be alleviated; mailbox space may be reduced because only one copy of message for multicasitng message is stored at a sender mailbox! and the volume of message traffic may be reduced because unsolicited messages never be delivered to recipient side.

Claims

1. An internet mail method and system based on sender mailbox comprising: the message delivery from a sender at a downemail zone to a recipient at a downemail zone or an email zone, including the steps of: i) a source downemail server stores an incoming user message from the sender at the sender's sender mailbox, creates a message sending notification message and then sends it to a destination downemail server or a destination email server; ii) a recipient reads the message notification message from the destination downemail server or the destination email server and then downloads the user message from the source downemail server if he or she wants to read it; and

the message delivery from a sender at an email zone to a recipient at a downemail zone, including the steps of: i) a source email server receives an incoming user message from the sender and relays it to a destination downemail server; ii) the destination downemail server relays the user message from the source email server to a message interworking server, iii) the message interworking server stores the user message at a sender mailbox allocated to the message's recipient, creates a message sending notification message and then sends it to the destination downemail server! iv) the recipient reads the message notification message from the message interworking server and then downloads the user message from the message interworking server if he or she wants to read it.

2. The method and system of claim 1, wherein: using simple mail transfer protocol or hypertext transfer protocol in message transferring from a sender terminal on a downemail zone to a source downemail server; using simple mail transfer protocol in message transferring among downemail servers, email servers and a message interworking server; and using internet mail access protocol, post office protocol 3 or hypertext transfer protocol in message transferring from a source downemail server to a recipient terminals on downemail and email zones, in message transferring from a destination downemail server to a recipient terminal on a downemail zone, and in message transferring from a message interworking server to a recipient terminal on a downemail zone.

3. The method and system of claim 1, wherein: classifying messages into a user message and a signaling message by the criterion of message body's size; two kinds of signaling messages, comprising: a message sending notification message to notify the sending of a user message from a sender to an intended recipient, wherein the notification message consists of access information, the user message's size and cited message data fields, wherein the access information field consists of domain name or internet address of a server containing sender mailbox, user identification and password; and a recipient reading notification message to notify the message reading of a recipient to the message's sender.

4. The method and system of claim 1, wherein: all senders on a downemail zone have their own sender mailboxes identified by their sender identifications to store their user messages at a source downemail server; the sender mailbox is implemented by the directory of

"/smb/sender_id/recipient_id/message#/" for a unicasting message and by two directories of "/smb/sender_id/recipient_id/message#/" and "/smb/sender_id/m_message/" for a multicasting message; the sender mailbox for a multicasting message consists of a common message storage for common message data and an individual message storage for individual message data; and a message interworking server has a sender mailbox to store user messages, and the mailbox is implemented by the directory of "/smb/recipient_id/sender_id/message#/" or by the directory of "/smb/sender_id/recipient_id/message#/" .

5. The method and system of claim 1, wherein a MTA_n including the steps of: in the case of a MTA_n located at a source downemail server, when the MTA_n receives an incoming user message that its relaying is allowed, it stores the message at the sender mailbox of the message sender, creates a message sending notification message and then sends the notification message to a destination downemail server or an destination email server! in the case of a MTA_n located at a destination downemail server, when the MTA_n receives an incoming user message, it relays the message to a message interworking server if available, otherwise it rejects the reception of the message and returns a error code; and in the case of a MTA_n located at a message interworking server, when the MTA_n receives an incoming user message, it stores the message at a sender mailbox allocated to the message's recipient, creates a message sending notification message, sends the notification message to a destination downemail server.

6. The method and system of claim 1, wherein a sender mailbox manager in a source downemail server comprising; a message downloading function that transfers a user message stored at a sender mailbox to a recipient when the recipient requests the downloading of the user message; a sender mailbox management function being operated by a sender's request; a sender mailbox management function being operated by itself; and a webmail sending function.

7. The sender mailbox manager of claim 6, wherein the message downloading function including the steps of: transferring of a user message stored at a sender mailbox to a recipient via post office protocol 3, internet message access protocol or hypertext transfer protocol after authenticating the recipient with a user identification and a password enclosed in a request signal from a recipient terminal on a downemail zone or an email zone; for a multicasting message, reconstructing of a user message with both common message data stored at a common message storage and individual message data at an individual message storage before transferring the user message to a recipient; for a unicasting message, deleting a user message stored at a sender mailbox after transferring the user message to a recipient; for a multicasting message, deleting individual message data related to a recipient stored at a sender mailbox after transferring the multicasting message to the recipient, and deleting common message data related to the multicasting message stored at a sender mailbox if all designated recipients have downloaded the multicasting message; and writing detailed information about the transferring in a log file after transferring a user message

8. The sender mailbox manager of claim 6, wherein the sender mailbox management function being operated by a sender's request comprising: a conventional management function using post office protocol 3 or internet message access protocol by which a sender can view or delete messages being stored at the sender's sender mailbox; and a web-based management function using hypertext transfer protocol by which a sender can view or delete messages being stored at the sender's sender mailbox, view detailed information about user messages that intended recipients have downloaded from the sender's sender mailbox, and also use a management service for the sender's sender mailbox;

9. The sender mailbox manager of claim 6, wherein the sender mailbox manager program is implemented by an independent program using its own TCP/UDP port number or by an integrated program sharing the TCP/UDP port number assigned to a recipient mailbox manager program, wherein, for the integrated program, the character pattern of user identification string inputted from a recipient terminal or a sender terminal is used to select to which mailbox manager program a sender or a recipient wants to access

10. The method and system of claim 1, wherein the sender mailbox manager in a message interworking server comprising; transferring a user message stored at a sender mailbox to a recipient using post office protocol 3, internet message access protocol or hypertext transfer protocol when the recipient requests the downloading of the user message; returning a recipient reading notification message to a user message's sender after transferring the user message to an intended recipient; and providing sender mailbox management function to a recipient.

11. The method and system of claim 1, wherein the recipient terminal comprising: downloading a user message via post office protocol 3 or internet mail access protocol from a source downemail server or a message interworking server with a plug-in module or a upgraded user agent when a recipient clicks on a menu "view user message"; and downloading a user message via hypertext transfer protocol from a source downemail server or a message interworking server when a recipient clicks on the access information field in a message sending notification message.