METHOD AND ARRANGEMENT FOR DELIVERING ELECTRONIC MESSAGES

Method for delivering electronic messages to a user including: receiving an electronic message from a sending party, said message containing a destination identity associated with said user, retrieving an IP address currently assigned to a terminal used by said user, based on said destination identity associated with said user, and delivering the electronic message to said terminal with the retrieved IP address as the destination address. A corresponding arrangement is also described.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
TECHNICAL FIELD

The present invention relates to a method of, and an arrangement for, delivering electronic messages.

BACKGROUND

Today, electronic messages (e.g. e-mails) sent from a sending party to a receiving terminal in a communication network, e.g. Internet, are commonly delivered to their recipients by means of a dedicated protocol, e.g. the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP). A common characteristic of this approach is that electronic messages directed to a receiving terminal or a recipient first arrive at a server (herein called messaging server) associated with the receiving terminal. The messaging server may for example be an e-mail server.

The electronic messages are then stored on the messaging server on the recipient's behalf. The receiving terminal polls the messaging server periodically using said protocols to fetch electronic messages from the messaging server. At the time of the development of this technique an important reason for choosing this approach was to allow a user to retrieve her/his messages from any terminal, thus allowing the user a certain degree of roaming.

FIG. 1 illustrates this technique where a sending party A sends an electronic message D to a receiving terminal C, e.g. a mobile terminal such as a mobile or cellular phone or a portable computer, associated with a recipient. The electronic message D is stored at the messaging server B and since the terminal C polls the messaging server B for messages the electronic message D is sent to the receiving terminal C at the first polling occasion occurring after that the electronic message D has arrived at the messaging server B.

Transmission of an electronic message from the sending party to the messaging server is normally done using the Short Message Transfer Protocol (SMTP). This provides an expedient delivery of the message to the recipient's messaging server with an end-to-end delay (for messages of small size) of, typically, a few seconds. When the electronic message arrives at the messaging server, the electronic message will be saved there until it is fetched by the user, i.e. until the user's terminal polls the messaging server for new electronic messages according to the protocol used. Polling normally occurs at regular intervals, time of the interval=d, causing an added average delay in the delivery of the electronic message of d/2.

Polling for messages is generally deemed acceptable in wired networks. However, in wireless networks, repeated network traffic (to poll the messaging server) causes a large drain on the battery of the wireless device, e.g. a mobile terminal. Moreover, the typically scarce radio resources are unnecessarily loaded or burdened by this repeated polling when there are no electronic messages to fetch.

These problems have been observed in various so called “push e-mail” solutions where the messaging server is polled very often by the terminal to create the impression that the e-mail is pushed to the terminal by the messaging server. That is, to create the impression that the messaging server initiates the delivery of the e-mail from the messaging server to the terminal as the e-mail arrives at the messaging server. Frequently, different ways of limiting the frequency of the probes or polling occasions, based on e.g. battery status, have been chosen in order to reduce or mitigate these problems. However, it must be noted that each addition to the time period between probes or polling occasions counteracts the overall ambition to give the user the impression that the user's terminal is always connected or “online” and is able to receive messages without delay.

One solution to the problem described above which has been proposed is called the IMAP IDLE extension. The IMAP IDLE extension allows, once an IMAP session is established, the messaging server to notify the terminal that new electronic messages have arrived at the messaging server practically at the same time as the electronic messages arrive at the messaging server. However, one substantial disadvantage with this solution is the requirement to maintain a Transmission Control Protocol (TCP) session from the terminal to the messaging server for the entire time period or duration it should be possible to deliver electronic messages from the messaging server to the terminal.

That is, the TCP session must be maintained all the time. To solve the problem of battery drainage, the TCP session must not send anything whenever there are no notifications or electronic messages to send. While this is indeed within the possibilities of the TCP, it is not compatible with Network Address Translation nodes (NAT nodes) which may be present in the path between the messaging server and the receiving terminal. NAT nodes are considered to be transparent and the only way to ensure that a state kept or present in any occurring intermediate NAT node is maintained is to send refresh or update messages (either on TCP level or on higher levels) in order to maintain the TCP session “alive”. This obviously counteracts the battery saving objective.

SUMMARY

It is an object of the present invention to address the problems outlined above. These objects and others may be obtained by providing methods and arrangements according to the independent claims attached below.

According to one aspect, there is provided a method of delivering electronic messages directed to a user, the method being executed in a messaging server. The messaging server is adapted to handle electronic messages for said user. The method comprises the following steps:

  • i) receiving an electronic message from a sending party, whereby said electronic message contains a destination identity associated with said user.
  • ii) retrieving an Internet Protocol address currently assigned to a terminal used by said user, wherein the retrieving is based on said destination identity associated with said user.
  • iii) delivering the electronic message to said terminal with the retrieved IP address as the destination address.

The method described herein may optionally have the following further characteristics.

According to another aspect the step of receiving an electronic message is preceded by the step of registering the Internet Protocol address of the terminal in a Domain Name System server connected to the messaging server.

According to yet another aspect the step of registering the Internet Protocol address of the terminal in the Domain Name System server is done by issuing a Dynamic Domain Name System update to the Domain Name System server.

According to one aspect the step of retrieving an Internet Protocol address includes the following steps:

  • i) looking up the destination identity associated with the user in a directory connected to the messaging server. This is done to retrieve the terminal identity of the terminal used by the user.
  • ii) looking up the terminal identity of the terminal used by the user in the Domain Name System server. This is done to retrieve the Internet Protocol address currently assigned to the terminal used by the user.

According to a further aspect one of the protocols SMTP, LMTP or HTTP is used during the step of delivering the electronic message to the terminal.

According to another aspect the electronic message is delivered to the terminal via at least one NAT node whereby a second messaging server is connected to said NAT node.

According to yet another aspect the electronic message is delivered to the terminal via the second messaging server.

According to a further aspect the terminal is a mobile terminal.

According to another aspect there is provided an arrangement in a messaging server for delivering electronic messages directed to a user. The messaging server is adapted to handle electronic messages for said user. The arrangement includes the following:

  • i) means for receiving an electronic message from a sending party, said electronic message containing a destination identity associated with said user.
  • ii) means for retrieving an Internet Protocol address currently assigned to a terminal used by said user, wherein the retrieving is based on said destination identity associated with said user.
  • iii) means for delivering the electronic message to said terminal, with the retrieved Internet Protocol address as the destination address.

The arrangement described herein may optionally have the following further characteristics.

According to a further aspect there is provided means for registering the Internet Protocol address of the terminal in a Domain Name System server connected to the messaging server.

According to another aspect there is provided means for registering the Internet Protocol address of the terminal in the Domain Name System server, by issuing a Dynamic Domain Name System update to the Domain Name System server

According to yet a further aspect there is provided means for looking up the destination identity associated with the user in a directory connected to the messaging server. The means enables the retrieval of the terminal identity of the terminal used by the user.

Further there is provided means for looking up the terminal identity of the terminal used by the user in the Domain Name System server to retrieve the Internet Protocol address currently assigned to the terminal used by the user.

According to another aspect there is provided means for using one of the protocols SMTP, LMTP or HTTP during said step of delivering the electronic message to the terminal.

According to yet another aspect there is provided means for delivering the electronic message to said terminal via at least one NAT (Network Address Translation) node whereby a second messaging server is connected to said NAT node.

According to a further aspect there is provided means for delivering the electronic message to said terminal via said second messaging server.

According to yet a further aspect the terminal is a mobile terminal.

The method and arrangement described herein may also be described in the following manner.

According to a further aspect there is provided a method of delivering electronic messages directed to a user. The method comprises the following steps:

  • i) receiving an electronic message at a mail server, said message containing a mail address associated with said user.
  • ii) retrieving an Internet Protocol address currently assigned to a terminal used by said user, based on said mail address associated with said user.
  • iii) delivering the electronic message to said terminal using the retrieved Internet Protocol address of the terminal.

According to another aspect there is provided an arrangement for delivering electronic messages directed to a user, wherein the arrangement comprises:

  • i) means for receiving an electronic message at a mail server, said message containing a mail address associated with said user.
  • ii) means for retrieving an Internet Protocol address currently assigned to a terminal used by said user, based on said mail address associated with said user.
  • iii means for delivering the electronic message to said terminal, using the retrieved Internet Protocol address of the terminal.

Further possible features and benefits of the present invention will be explained in the detailed description below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating the technique of polling, known from the background art,

FIG. 2 is a block diagram illustrating one example of a network topology where the method and arrangement described herein may be employed, according to one embodiment,

FIG. 3 is a block diagram illustrating another example of a network topology where the method and arrangement described herein may be employed, according to another embodiment.

DETAILED DESCRIPTION

Before describing various embodiments in detail, it is to be understood that this invention is not limited to the particular component parts of the devices described or process steps of the methods described as such devices and methods may vary. It is also to be understood that the terminology used herein is for purposes of describing particular embodiments only, and is not intended to be limiting. It must be noted that, as used in the specification and the appended claims, the singular forms “a,” “an” and “the” may also encompass plural referents unless the context clearly dictates otherwise. Thus, for example, the term “a terminal” may refer to one or more terminals, and the like.

Briefly described, a method and an arrangement are provided for delivering an electronic message from a sending party to a receiving terminal by means of a messaging server. The term terminal used herein may mean a mobile terminal, e.g. a mobile or cellular phone or a portable computer, but it may also mean some other type of terminal possible to connect to a communication network.

Instead of using a client-server protocol (such as POP or IMAP) for delivering electronic messages from the messaging server to the terminal, the method and arrangement described herein uses other protocols, for example the SMTP, the Local Mail Transfer Protocol (LMTP) or the Hyper Text Transfer Protocol (HTTP), for the communication from the messaging server to the terminal. Hence, for the very last hop or part in the delivery chain of the electronic message. By doing so, the terminal do not have to send anything to the messaging server whenever there are no messages to be received, thus saving battery capacity. To achieve this, and at the same time retain the ability for the user to roam or move between different terminals and/or accesses, the user needs to register its terminal, as the one the user wants to receive her/his electronic messages, with the messaging server. One way of implementing this registration is to use Dynamic DNS server procedures (Domain Name System Server, DNS Server). By using a DNS server, a connecting layer between the destination identity or address associated with the user (e.g. the e-mail address of the user), and the IP address currently used by the terminal of the user, is achieved. This facilitates the implementation of the method and arrangement described herein in the messaging server and enables the use of existing terminal protocols for the registration of the terminal IP address with or at the messaging server. The destination identity or address associated with the user is also the destination identity of the electronic message.

Referring to FIGS. 2 and 3 the principle of the method and arrangement described herein will now be described.

FIG. 2 illustrates a messaging server 200 adapted to deliver electronic messages to a terminal 202 (e.g. a mobile terminal),

FIG. 3 illustrates a messaging server 300 adapted to deliver electronic messages to a terminal 302 (e.g. a mobile terminal) via at least one NAT node 318 and one second messaging server 314.

In steps 2:1 and 3:1 the terminal 202 and 302 respectively, receives an IP address from an Access network 204 respectively 304, for example a Mobile access network. When the terminal 202, 302 has received an IP address it is online.

Registration:

The terminal 202, 302 needs to register with/at the messaging server 200, 300. To do that the terminal 202, 302 may issue a message called DynamicDNS update to the DNS server 212, 312 (steps 2:2, 3:2) indicating the terminal IP address of the terminal 202, 302, on which the terminal can receive electronic messages, and the terminal address or identity (e.g. the terminal domain name). One way of creating the terminal identity for a mobile terminal is to use Telephone Number Mapping (tElephone NUmber Mapping, ENUM) using the Mobile Subscriber ISDN Number (MSISDN). The MSISDN refers to the telephone number of a mobile subscriber. In this way a terminal identity in the form of a domain name can be created from the telephone number of the terminal. Also for other terminals that do not have a telephone number ENUM may be used. There merely has to be defined a set of numerals as starting point for the ENUM. Hence, in the DNS server 212, 312 the terminal IP address and the terminal address or terminal identity (e.g. terminal domain name) of the terminal 202, 302 are stored and linked to each other. This link between terminal IP address and terminal address or identity is illustrated in FIGS. 2 and 3 by the entries 212a and 312a and the records 212b and 312b in the DNS servers 212 and 312 respectively. That is, one entry 212a is linked to a record 212b and one entry 312a is linked to a record 312b. The references 212b, 312b represent a number of records (in the figures 3 lines are shown, each line representing one record) and the references 212a and 312a represent entries of terminal addresses or terminal identities (in the figures 3 lines are shown, each line representing one entry).

The link in the DNS server 212, 312 between terminal IP address and the terminal address or terminal identity may be implemented by associating the entry of the terminal address or terminal identity with a record containing the terminal IP address. One may e.g. use records of the types Mail Exchange Resource Record (MX RR), Address Resource Record (A RR), Service Record (SRV) or Naming Authority Pointer (NAPTR).

The link between the destination identity of the electronic message (e.g. an email address associated with a user) and terminal address or identity (e.g. a terminal domain name) is achieved by using a directory 210, 310 connected to the messaging server 200, 300. Messaging servers 200, 300 (e.g. email servers) commonly have a directory that enables this functionality. This link between destination identity and terminal address or terminal identity is illustrated in FIGS. 2 and 3 by the objects 210b and 310b and the attributes 210a and 310a in the directories 210 and 310. That is, one object 210b is linked to an attribute 210a and one object 310b is linked to an attribute 310a. The references 210a, 310a represent a number of attributes (in the figures 3 lines are shown, each line representing one attribute) and the references 210b and 310b represent objects comprising destination identities (in the figures 3 lines are shown, each line representing one object).

When a user subscribes (with a service provider) to the service of having electronic messages (e.g. e-mails) delivered as described herein, the provider enters (in the directory 210, 310) the destination identity of the user (e.g. an e-mail address associated with the user) and the terminal address or identity (e.g. a terminal domain name) of the terminal that the user want to be able receive messages on or with.

It is also possible to register several terminals 202, 302 for receiving electronic messages as described herein. In this case the terminal address or identity in the directory 210, 310 does not represent one terminal but a group of terminals. In the DNS server 212, 312 this group terminal address or identity is then associated with several records where each record contains the terminal IP address of one terminal in the group. In this multi terminal case the user may e.g. select that all electronic messages should be delivered to all terminals.

Message Delivery when the Terminal 202, 302 is Registered and Online:

In a step 2:3, 3:3 the messaging server 200, 300 receives an electronic message coming from a sending party 206, 306 via a transport network 208, 308. The electronic message is directed to a destination identity, for example an email address, associated with a user of the terminal 202, 302.

In a next step 2:4, 3:4 the messaging server 200, 300 looks up the destination identity in the Directory 210, 310, to find the corresponding terminal address or terminal identity.

The messaging server 200, 300 tries to forward the electronic message to the terminal address or terminal identity. To do that, the messaging server 200, 300 checks the DNS server 212, 312 for which IP address to use for sending to the terminal address or terminal identity previously retrieved. In step 2:5 respectively 3:5 the messaging server 200 respectively 300 retrieves the IP address registered by the terminal 202 respectively 302, then initiates a connection to the terminal 202 respectively 302, and sends the message using the retrieved IP address in steps 2:6 respectively 3:6.

A copy of the electronic message may well be saved at the messaging server 200, 300 for multi-client/multi-user or multi-terminal 202, 302 support.

Message Delivery when the Terminal 202, 302 is Registered and Offline:

Steps 2:3, 3:3 and 2:4, 3:4 are performed as above but the messaging server 200, 300 fails to connect to the terminal 202, 302 as the messaging server 200, 300 tries to initiate a connection to the terminal 202, 302. Because of this the messaging server 200, 300 spooles or queues the electronic message in the messaging server 200, 300 for later delivery.

Updating the DNS Server 212, 312

When the terminal 202, 302 reconnects to an access network (e.g. a mobile access network), e.g. when the terminal is switched on after having been switched off, or after having lost contact with the access network, the DNS server 212, 312 needs to be updated with the IP address currently assigned to the terminal. This may be done in several ways. One possibility is that the terminal issues a DynamicDNS update to the DNS server 212, 312 so that the DNS server 212, 312 contains the presently valid IP address of the terminal. Another possibility is that a node (e.g. a Gateway GPRS Support Node, GGSN) in the access network issues an update command to the DNS server 212, 312. These two possibilities are of course also possible to use for the deregistration of the terminal.

Forwarding of Electronic Messages Queued or Spooled in the Messaging Server 200, 300:

When the terminal 202, 302 reconnects to an access network 204, 304 after the terminal 202, 302 has been disconnected, messages that have been queued or spooled on the messaging server 200, 300 need to be forwarded to the terminal 202, 302. This may be done in several ways, one possibility is that the terminal 202, 302 contacts the messaging server 200, 300 for the purpose of initiating message forwarding from the messaging server 200, 300 to the terminal 202, 302. The terminal 202, 302 may contact the messaging server 200, 300 either using the TURN protocol (Traversal Using Relay NAT), ODMR (On Demand Mail Relay), ODMR is also called ATRN (Authenticated Turn), or LMTP. One may also use the fact that the DNS server 212, 312 is updated when the terminal 202, 302 reconnects to an access network 204, 304. One possibility is that the messaging server 200, 300 polls or asks the DNS server 212, 312 to check if the terminal's record in the DNS server 212, 312 has been updated. Another possibility is that the DNS server 212, 312 sends an update message to the messaging server 200, 300 when the terminal's record in the DNS server 212, 312 has been updated. When the messaging server 200, 300 has been updated in either of these ways, the messaging server 200, 300 initiates forwarding of messages from the messaging server 200, 300 to the terminal 202, 302.

Deregistration:

When the terminal 202, 302 deregisters from the messaging server 200, 300 it issues a DynamicDNS update (2:2, 3:2) to the DNS server 212, 312 indicating the terminal IP address and terminal address or terminal identity of the terminal that should be removed from the DNS server 212, 312. As mentioned before, deregistration may also be conducted by a node in the access network, e.g. a Gateway GPRS Support Node (GGSN).

Protocols Used

Regarding the protocol to be used for the delivery of electronic messages from the messaging server 200, 300 to the terminal 202, 302 it is in some circumstances advantageous to use SMTP. One such case is when there is a NAT node 318 in the path between a first messaging server 300 and the terminal 302 (FIG. 3).

In the topology shown in FIG. 3 the second messaging server 314 is used to circumvent a NAT node 318. This is a common measure in networks, for example the Internet. With the use of SMTP it is possible to send a message from the first messaging server 300 to the terminal 302 via the second messaging server 314. With other protocols this is not ncessarily possible. If for example HTTP is used to send an electronic message from the first messaging server 300 to the terminal 302 there must be a direct connection between the first messaging server 300 and the terminal, as shown in FIG. 2.

Because the terminal IP address is linked to the terminal address or terminal identity (as registered in the DNS server 212, 312) the electronic message can be sent from a first network 320 to a second network 322 (see FIG. 3) in spite of the fact that the IP address of the terminal 302 may be used for some other purpose in the first network 320.

Although particular embodiments have been disclosed herein in detail, this has been done by way of example for purposes of illustration only, and is not intended to be limiting with respect to the scope of the appended claims that follow. In particular, it is contemplated by the inventor that various substitutions, alterations, and modifications may be made to the invention without departing from the spirit and scope of the invention as defined by the claims.

Claims

1. A method, executed in a messaging server for handling electronic messages for a user and delivering electronic messages directed to said user, comprising the following steps:

receiving an electronic message from a sending party, said electronic message containing a destination identity associated with said user,
retrieving an Internet Protocol address currently assigned to a terminal used by said user, based on said destination identity associated with said user, and
delivering the electronic message to said terminal with the retrieved IP address as the destination address.

2. A method according to claim 1, wherein:

the step of receiving an electronic message is preceded by the step of registering the Internet Protocol address of the terminal in a Domain Name System Server connected to the messaging server.

3. A method according to claim 2, wherein:

registering the Internet Protocol address of the terminal in the Domain Name System server is done by issuing a Dynamic Domain Name System update to the Domain Name System server.

4. A method according to claim 1, wherein said step of retrieving an Internet Protocol address includes:

looking up the destination identity associated with the user in a directory connected to the messaging server to retrieve the terminal identity of the terminal used by the user, and
looking up the terminal identity of the terminal used by the user in the Domain Name System server to retrieve the Internet Protocol address currently assigned to the terminal used by the user.

5. A method according to claim 1, wherein:

one of the protocols SMTP, LMTP or HTTP is used during said step of delivering the electronic message to the terminal.

6. A method according to claim 1, wherein:

the electronic message is delivered to said terminal via at least one NAT node whereby a second messaging server is connected to said NAT node.

7. A method according to claim 6, wherein:

the electronic message is delivered to said terminal via said second messaging server.

8. A method according to claim 1, wherein the terminal is a mobile terminal.

9. A messaging server for handling electronic messages for a user and delivering electronic messages directed to said user, comprising:

means for receiving an electronic message from a sending party, said message containing a destination identity associated with said user,
means for retrieving an Internet Protocol address currently assigned to a terminal used by said user, based on said destination identity associated with said user, and
means for delivering the electronic message to said terminal with the retrieved IP address as the destination address.

10. The messaging server of claim 9, comprising:

means for registering the Internet Protocol address of the terminal in a Domain Name System server, connected to the messaging server.

11. The messaging server of claim 10, comprising:

means for registering the Internet Protocol address of the terminal in the Domain Name System server by issuing a Dynamic Domain Name System update to the Domain Name System server.

12. The messaging server of claim 9, comprising:

means for looking up the destination identity associated with the user in a directory connected to the messaging server to retrieve the terminal identity of the terminal used by the user, and
means for looking up the terminal identity of the terminal used by the user in the Domain Name System server to retrieve the Internet Protocol address currently assigned to the terminal used by the user.

13. The messaging server of claim 9, comprising:

means for using one of the protocols SMTP, LMTP or HTTP during said step of delivering the electronic message to the terminal.

14. The messaging server of claim 9, comprising:

means for delivering the electronic message to said terminal via at least one NAT node whereby a second messaging server is connected to said NAT node.

15. The messaging server of claim 14, comprising:

means for delivering the electronic message to said terminal via said second messaging server.

16. The messaging server of claim 9, wherein the terminal is a mobile terminal.

17. A method of delivering electronic messages directed to a user, comprising the following steps:

receiving an electronic message at a mail server, said message containing a mail address associated with said user,
retrieving an Internet Protocol address currently assigned to a terminal used by said user, based on said mail address associated with said user, and
delivering the electronic message to said terminal using the retrieved IP address of the terminal.

18. A mail server for delivering electronic messages directed to a user, comprising:

means for receiving an electronic message at the mail server, said message containing a mail address associated with said user,
means for retrieving an Internet Protocol address currently assigned to a terminal used by said user, based on said mail address associated with said user, and
means for delivering the electronic message to said terminal using the retrieved Internet Protocol address of the terminal.
Patent History
Publication number: 20100042693
Type: Application
Filed: Jun 29, 2007
Publication Date: Feb 18, 2010
Inventors: Anders Eriksson (Linkoping), Åke Gustafsson (Huddinge)
Application Number: 12/515,206
Classifications
Current U.S. Class: Demand Based Messaging (709/206); Computer-to-computer Data Addressing (709/245)
International Classification: G06F 15/16 (20060101);