Field

[001 ] This patent application relates generally to an apparatus for communication with an apparatus, more specifically to facilitate communication between two devices, one of which comprising a client application for allowing a user to access messages. This patent application also relates to a corresponding method of communication and a computer readable medium having stored thereon computer-readable instructions for executing one or more of the methods.

Background

[002] There are currently two versions of internet protocol in use: the existing Internet Protocol version 4 ("IPv4") and a newer Internet Protocol version 6 ("IPv6"). IPv6 is expected to gradually replace IPv4, but the two versions have coexisted for a number of years due to slow take up of IPv6.

[003] Network Address Translation (NAT) was introduced to extend the lifetime for the use of IPv4.

The use of NAT gateways forces many clients (with private IPv4 addresses), each hiding behind one of the NAT gateways, to make outgoing connections to centralized servers in order to communicate with other clients behind other NAT gateways in their private networks. This leads to a client/server architecture, where the act of sending information to a centralized server to be decrypted on the server results in the loss of privacy in the secure communications in these NAT based network communications. Furthermore, implementation of IPv4 with NAT does not allow incoming connections to the client computers.

[004] The IPv6 Internet differs from the current IPv4 Internet in many ways, but the most prominent being the address size. Since IPv6 address size is 128 bits which Is a lot more than the IPv4 address size of 32 bits, it is possible that every device could have its own public address (instead of private address).

List of Drawings

[005] Embodiments of the invention will be better understood and readily apparent to one skilled in the art from the following written description, by way of example only and in conjunction with the drawings, in which:

[006] Figure 1 shows a backward compatible workflow involving a Simple Mail Transfer Protocol

(SMTP) and operation in IPv4 according to an example of the present invention.

[007] Figure 2 shows a work flow involving a Simple Mail Transfer Protocol (SMTP) and operation in IPv6 according to an example of the present invention.

[008] Figure 3 shows a work flow involving a Simple Mail Transfer Protocol (SMTP) and operation in IPv4/IPv6 according to an example of the present invention.

[009] Figure 4 shows a work flow involving File Transfer protocol / Secure File Transfer Protocol

(FTP/SFTP) according to an example of the present invention.

[010] Figure 5 shows a work flow involving Extensible Messaging and Presence Protocol (XMPP) according to an example of the present invention.

[011] Figure 6 shows a work flow involving Voice over Internet Protocol (VoIP) according to an example of the present invention.

[012] Figure 7 shows a schematic diagram of a computing device according to an example of the present invention.

[013] Figure 8 shows a flow chart of a method of communication according to an example of the present invention

Summary

[014] The invention is defined in the independent claims. Some of the optional features of the invention are defined in the dependent claims.

[015] According to an aspect of an example of the present disclosure, there is provided an apparatus for communication with a second apparatus, the apparatus being an end user device comprising a client application for allowing a user to send a message at the end user device, the apparatus comprising: a processor configured to execute one or more applications to operate the apparatus for: receiving domain information of a first server, the first server being configured to receive messages for the second apparatus; sending a request for the address of the first server directly to a Domain Name Server without routing through another server based on the domain information; receiving the address of the first server directly from the Domain Name Server without routing through another server; and sending a message to the second apparatus based on the address of the first server.

[016] According to an aspect of another example of the present disclosure, there is provided a method for communication between a sender and a recipient the sender being an end user device comprising a client application for allowing a user to send a message at the end user device, the method comprising: receiving at the sender domain information of a first server, the first server being configured to receive messages for the recipient; sending at the sender a request for the address of the first server directly to a Domain Name Server without routing through another server based on the domain information; receiving at the sender the address of the first server directly from the Domain Name Server without routing through another server; and sending from the sender a message to the recipient based on the address of the first server.

[017] According to an aspect of an example of the present disclosure, there is provided a non- transitory computer readable medium storing one or more applications executable by a processor to perform a method for communication between a sender and a recipient, the sender being an end user device comprising a client application for allowing a user to a send message at the end user device, the method comprising: receiving at the sender domain information of a first server, the first server being configured to receive messages for the recipient; sending at the sender a request for the address of the first server directly to a Domain Name Server without routing through another server based on the domain information; receiving at the sender the address of the first server directly from the Domain Name Server without routing through another server; and sending from the sender a message to the recipient based on the address of the first server.

Pataited D^pffp^on

[018] Implementation of the techniques and examples disclosed herein may be particularly advantageous by providing decentralization from a server-client based infrastructure to end- user devices and by extending the messaging infrastructure to the arena of portable computing device. Thus, each end user may be provided with a personal server realised in the end-user devices that employs industry protocols, such as Simple Mail Transfer Protocol (SMTP) applicable when messages exchanged are emails, Extensible Messaging and Presence Protocol (XMPP) applicable when messages exchanged are chat messages, File Transfer Protocol/Secure File Transfer Protocol (FTP/SFTP) applicable when the messages exchanged are files (any type of files such as video files, audio files, text files, data files etc.), and/or Voice over Internet Protocol (VoIP) applicable when the messages exchanged comprises voice data and configured to receive messages for the end user directly at the personal server. In at least some implementations, an end-to-end communication between a sender and a recipient can be achieved, thus enhancing privacy of the message.

[019] Personal servers typically serve one (or a few) users, which greatly simplifies its design and implementation. In one configuration, it may only require a lightweight database (like SQLIte), which can handle the storage requirements. Optionally, the personal servers may not require server-based storage.

[020] As used herein, the term "end user device" may be considered to be a device that can provide for connectivity to the internet. Thus, an end user device can be a Personal Computer (PC), laptop, netbook, mobile phone, smart phone, tabled PC and other equivalent devices any of these can be used to access the internet for sending and accessing messages (e.g. emails, chat messages), making calls using VoIP, sharing files and the like. Typically, an end user device uses Local Area Network (LAN), router, Wireless Local Area Network (WLAiilJ, Digital Subscriber Line (DSL), cable, 2 ^nd to 4™ Generation TetecOTmuriicjation networks and the like for data communication required to access the messages. The end user may comprise a client application for allowing a user to access messages at the end user device.

[021] "Domain Name Server (DNS) address" in the present disclosure refers to address (e.g. IP address) of an authoritative DNS configured to connect with a sender device, a recipient device, an intermediary server receiving a message for the recipient device, or an intermediary server transmitting a message for the sender device.

[022] A data communication system 100 according to an exemplary example of the present disclosure between an end user device 110 (also known as sender 110) owned by a first user, Alice, to an end user device 120 (also known as recipient 120) owned by another user, Bob, is illustrated in Figure 1. The sender 110 is in a DOMAIN A and the recipient 120 is in a DOMAIN B. The data communication system 100 supports Internet Protocol version 6 (IPv6) and Internet Protocol version 4 (IPv4) on the sender side. Figure 1 illustrates backward compatibility of the data communication system 100 to the use of Internet Protocol version 4 (IPv4) infrastructure by the sender 110 and the recipient 120. It is appreciated that it is beneficial to be backward compatible to IPv4. Details illustrating how the data communication system 100 can support IPv6 are described in other example data communication systems described later with reference to Figures 2 to 6.

A client application 114 resides in the sender 110. The client application 114 is configured for obtaining identification information 130 of the recipient 120 (Step 13). The identification information 130 of the recipient 120 may comprise an email address (Bob's email address), a hostname of the recipient 120 and/or user account information of a messaging application (e.g. Skype, Whatsapp, Jabber, Wechat and the like) (Bob's messaging account). The identification information 130 of the recipient 120 may also comprise other information for identifying the recipient 120, e.g. telephone number (Bob's telephone number). Separately, for secure communications, a digital certificate comprising a public key of the recipient 120 (a public key of a digital certificate of the recipient 120 previously stored in a server accessible to the sender 110) has to be obtained as well.

The identification information 130 of the recipient 120 may be inputted via an input/output module (e.g. a keypad, keyboard and the like) of the end user device 110. Alternatively, the identification information or part of the identification information 130 may be retrieved from a local address book of the end user device 110, an address book stored in a hosting server accessible through the end user device 110, or from a server 128 (or another server). For secure communications, a digital certificate comprising a public key of the recipient 120 is also obtained from the server 128, which is associated with the domain of the recipient 120 and being posted by a client application 124 with the digital certificate comprising a public key of the recipient 120 (Step 12). The digital certificate may also be signed and delivered securely by a trusted third party entity, also known as Certificate Authority (CA) operating the server 128. Although secure communications utilising digital certificates is described, it is appreciated that it is an optional feature.

The server 128 may be a central directory configured for allowing the sender 110 and recipient 120 to publish their own digital certificates. The server 128 may be configured for allowing one to use it as an address book to provide digital certificates and/or identification information 130 at the time a message (e.g. message 132 described below) is composed. In one example, the digital certificates of the sender 110 and/or recipient 120 may be stored in a Lightweight Directory Access Protocol (LDAP) server (e.g. 108 and 128 can be LDAP servers). Alternatively, different servers 108 and 128 may be associated with the domains of the sender 110 and the recipient 120 respectively and are posted with respective digital certificates comprising a public key of the sender 110 and recipient 120 by the client applications 114 and 124 (or any software module residing in the sender 110 and recipient 120) respectively (Steps 11 and 12) so as to enable secure communications between the sender 110 and the recipient 120.

For Alice to communicate with Bob through Bob's end user device 120, Alice has to compose a message 132 to Bob on her end user device 110. The composed message 132 may be encrypted, for instance, using public-key encryption, to protect the content from being read by entities other than the intended recipients, in this case, the recipient 120. Public-key encryption uses an asymmetric-key pair, i.e. a public key and a private key for encryption and decryption. The public key is made public and is distributed widely and freely. In contrast, the private key is not distributed and must be kept secret In the public-key cryptographic mechanism, data encrypted with public-key can only be decrypted with its private key and vice versa. This characteristic is used to implement encryption and digital signatures. Other known cryptographic mechanisms (symmetric-key algorithms) maybe used. Optionally, encryption may also include authentication.

Optionally, in the case that the encrypted message 132 is an email, the message may be composed using Secure/Multipurpose Internet Mail -Extensions (S/MIME). In the present example, the message 132 may be composed and encrypted (or signed) at the sender 110 using the public key in a digital certificate of the recipient 120 and signing the message with a private key of the sender 110 (Step 14). A valid digital signature allows a recipient, in this case, the recipient 120 to identify that the encrypted (or secured) message 132 was created by a known sender, in this case, sender 110, and that the sender 110 cannot deny having sent the message, and that the message 132 was not altered in transit. [028] In Figure 1 , the composed message 132 is being sent to an intermediary server 104 from the sender 110 (Step 15). This intermediary server 104 requests resource information 138 of the recipient 120 from an Domain Name Server (DNS) 102 (Step 16a). The resource information 138 in the present example is in the form of a resource record of the recipient 120, wherein the resource record indicates domain information (e.g. server address in hostname format) of a first server where the message 132 is to be received on behalf of the recipient 120. Once obtained, the domain information in the resource information 138 can be used to query for the corresponding IPv4 or IPv6 addresses (in this example, it is IPv4 address) of the recipient 120 or the mail server receiving messages for the recipient 120 so as to enable the sender 110 to reach the recipient 120 for communication (Step 16b).

[029] In the present example, the DNS server 102 is pre-determined at the sender 110 and configured to communicate with the intermediary server 104. In other examples, the sender 110 may be configured to let the intermediary server 104 determine which DNS server to communicate with or the sender 110 directly communicates with the DNS server 102. The resource information request from the intermediary server 104 or sender 110 contains the identification information 130 (e.g. email address) or part of the identification information 130 (e.g. domain name "123" from an email address: xxx@123.com) of the recipient 120. Upon receiving the resource information request from the intermediary server 104, the DNS server 102 carries out a recursion/iteration process to obtain the resource information 138. Such recursion/iteration process is a known technique. Specifically, a DNS query (e.g. for a Name Server record) using the identification information 130 is first sent from the sender 110 to the intermediary server 104, which forwards the DNS query to the DNS server 102. If the DNS server 102 does not already have the resource information 138, it forwards the DNS query to one or more DNS servers (not shown in the figures). If the one or more DNS servers do not have the resource information 138 of the domain of the recipient 120 or a mail server that can receive messages for the recipient 120, which in the present example, is an intermediary server 134, the one or more DNS servers will forward the DNS query to other DNS servers (not shown in the figures) that may have the resource information 138. The contacted DNS servers (not shown in the figures) may also return referral answers that could lead to a DNS server that can provide the resource information 138. The DNS server that can finally provide the requested information or address in the DNS query is known as authoritative DNS server. In the present example, the authoritative DNS server would be the authoritative DNS server of the intermediary server 134. As the authoritative DNS server of the intermediary server 134, it means that this authoritative DNS server is preconfigured to be contacted by the intermediary server 134 periodically or upon changes to update information and/or address of the intermediary server 134 recorded at this authoritative DNS server. This recursion/iteration process and the definition of the authoritative DNS server will also be applicable to the DNS query sent by the respective senders and the respective authoritative DNS servers of the respective first servers and recipients in other examples of the present disclosure described with reference to the other Figures 2 to 6, and 8.

[030] The resource information 138 may be used to obtain an address (in this case, public IPv4 address) of the first server, which in the present example is an intermediary server 134, configured to receive messages for the recipient 120. For instance, domain information (e.g. server address in hostname format) of the first server 134 retrieved from resource information 138 is used to query the DNS Server 102 for the IPv4 address of the first server 134.

[031] In the example illustrated in Figure 1, the message from the sender 110 is sent from the intermediary server 104 to the intermediary server 134 before delivering to the recipient 120 because the received resource information 138 indicates an intermediary server 134 being configured to receive messages for the recipient 120 (step 17). Upon request of the recipient 120, a client application 124 residing in the recipient 120 makes a connection to the intermediary server 134 and commands transmission of any messages to the local message store 122 of the recipient 120 (Step 18). In this example, the message is in the form of an email, and the email is retrieved from a message store 126 of the intermediary server 134, into the local message store 122 of the recipient 120 using Internal Messaging Access Protocol (IMAP). It should be appreciated that a message store 112 and 122 can be local on the sender 110 and recipient 120 respectively. In this example where the message is an email, the intermediary servers 104 and 134 are mail servers comprising the message stores 106 and 126 respectively for storing the emails received from the sender 110 and the emails to be retrieved by the recipient 120. In the present example, the message stores 106 and 126 are used to store the incoming messages for Alice and Bob respectively, so that the message 132 can be retrieved by Alice's end user device 110 and [Job's end user device 120 respectively.

[032] The digital signature of the message 132 may be validated at the recipient 120 using an obtained public key of the sender 110. The public key of the sender 110 may be retrieved from a digital certificate sent along with the encrypted message 132 or digital certificates previously used and/or stored in the local address book of the recipient 120. Alternatively, the public key may be obtained from a digital certificate retrieved from the Certificate Authority on behalf of the sender 110 or a server 108, the server 108 being associated with the domain of the sender 110 and being posted by the client application 114 (and/or other software modules residing in the sender 110) with the digital certificate of the sender 110. The encrypted message 132 may also be decrypted at the recipient 120 with a private key associated with the recipient 120 at the time the encrypted message 132 stored in the local message store 122 is being viewed by the recipient 120. The encrypted message 132 remains encrypted in the local message store 122, even after viewing by the recipient 120.

[033] It should be appreciated that the sender 110 and recipient 120 may each has a non-static address, in the case of Figure 1 , IPv4 address, and the address of the respective sender 110 or recipient 120 can be updated to a central depository (not shown in the Figures) for connecting to the DNS Server 102 accessible by the sender 110 or recipient 120 respectively and modifying therein the contents of the resource information 138 of the identified user device. For instance, the central depository can be an Identity Registration Protocol (IRP) server as disclosed in International Patent Application No. PCT/SG2016/050015.

[034] In the arrangement as disclosed in Figure 1 , which uses IPv4 infrastructure, the message flow is centralised. If the sender 110 and recipient 120 want to exchange information, they must both make outgoing connections to each of their own local servers 104 and 134 respectively. The intermediary servers 104 and 134 (having a public IPv4 address respectively) typically serve a great number of users, and each has to handle traffic for these users. Thus, these intermediary servers 104 and 134 require massive hardware and bandwidth and are usually run in data centers by trained professionals who are proficient in multiple complex server applications (like Microsoft Exchange, or the open source Postfix mail server) and/or client-server database systems (e.g. SQL server or PostgreSQL).

[035] The communication between a sender 110 and a recipient 120 may be secured using Transport Layer Security (TLS) or Secured Sockets Layer (SSL). TLS Security offers enhanced security of the message in transit by protecting the typically exposed message headers). However, TLS security is done independently for each link in the chain of communication, and so it may be difficult to ensure that all links in the chain of communication use TLS. Moreover, the servers in the chain of communication must be aware of and configured for TLS security. As a result, there is only limited client to server authentication, primarily only to determine if the sender's server 104 can relay the messages outside of the domain of the sender 104. Thus, even if the encrypted message 132 in the form of an email (with S/MIME security) is sent through the system 100, the encrypted message 132 will pass through the intermediary servers 104 and 134 transparently. That is, whether the message is S/MIME protected or non-protected (at the application layer) has no semantics at the TLS layer (i.e. a slightly lower layer below application layer and closer to the transport layer). In other words, when TLS security is not enabled at the respective (intermediate) link, the transport layer is not aware of the specifics in the message content (at the application layer), and hence the transport layer delivery is not affected in any way, be it the message is S/MIME protected or non-protected. The message has semantics (i.e. makes sense or has meanings) only at the application layer when the appropriate client application 124 of the recipient 120 is launched and it attempts to decode the message (i.e. decrypt if it is S/MIME encrypted) for viewing. As a result, this S/MIME protected message will be transported via TLS as if it is not S/MIME protected (i.e. in plaintext, not encrypted, not signed). However, there will be end-to-end security for the message because the message is secured with S/MIME security.

[036] Optionally, the address of the intermediary server 134 may be dynamic (i.e. may change and not remain the same). In this case, the resource information 138 and/or domain information (e.g. an 'A' or 'ΑΑΑΑ' record) and/or address (e.g. IP address) of the recipient 120 may be updated, for instance through a server or source (e.g. Identity Registration Protocol (IRP) based server) (not shown in Figure 1), to publish updated resource information 138 and/or domain information and/or address of the intermediary server 134. The server or source (e.g. IRP-based server) can be configured to provide the updated resource information 138 and/or domain information and/or address (e.g. IP address) of the intermediary server 134 to an authoritative DNS server (not shown in Figure 1) of the recipient 120, an authoritative DNS server of the intermediary server 134 (not shown in Figure 1) or the DNS server 102 contactable by the sender 110. In one example, if the server or source (e.g. IRP-based server) provides the updated resource information 138 and/or domain information and/or address of the intermediary server 134 to the authoritative DNS server of the intermediary server 134 or the authoritative DNS server of the recipient 120 and not to the DNS server 102, the DNS server 102 may be able to obtain the updated resource information 138 and/or domain information and/or address of the intermediary server 134 for the intermediary server 104 from the authoritative DNS server of the intermediary server 134 or the authoritative DNS server of the recipient 220 after going through the recursive/iterative process to contact the authoritative DNS server of the intermediary server 134 or the authoritative DNS server of the recipient 220. Once the address is obtained by the sender 110, sending of the message 132 to the local message store 126 of the intermediary server 134 can commence.

[037] More specifically, there could be a software application residing in the intermediary server 134 or at the recipient 120 (which can be the client application 124) configured to connect to the server or source (e.g. IRP-based server) to update the current IP address of the intermediary server 134 at the server or source (e.g. IRP-based server) when there is a change in the current IP address. The server or source (e.g. IRP-based server) could be responsible for updating the current IP address with an authoritative DNS server of the recipient 120, an authoritative DNS server of the intermediary server 134 or the DNS server 102 contactable by the sender 110 when there is a change in the current IP address. In this manner, the sender 110 is able to readily obtain, for instance, the updated current IP address of the intermediary server 134 from the server or source (e.g. IRP-based server), from the authoritative DNS server of the recipient 120 (after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 120), from the authoritative DNS server of the intermediary server 134 (after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 134) or from the DNS server 102 contactable by the sender 110. As an example, records of the IP address of the recipient 120 or the intermediary server 134 in the server or source (e.g. IRP-based server) may be listed according to the host name (which can be based on domain information) of the recipient 120 or the intermediary server 134 p re-registered with the server or source (e.g. IRP-based server).

[038] In another example as shown in Figure 2, there is provided a data communication system 200 between a first user, Alice, and a second user, Bob. In this communication system 200, the first user owns a first apparatus 210 (also known as sender 210) and the second user owns a second apparatus 220 (also known as recipient 220). The sender 210 is in a DOMAIN A and the recipient 220 is in a DOMAIN B. The first apparatus 210 and the second apparatus 220 may be an end user device as previously described comprising a client application (client application 212 for the first apparatus 210 and client application 224 for the second apparatus 220) for allowing a user (the first user or the second user respectively) to access messages at the end user device. A key feature of the example of Figure 2 is that both the sender 210 and the recipient 220 employ IPv6 infrastructure in that each of them has an IPv6 address. For convenience, some of the reference numerals of similar elements in the examples of Figure 1 and Figure 2 are given the same reference numerals, such as identification information 130, message 132, and resource information 138, which incorporates domain information (e.g. server address in hostname format) of a first server configured to receive messages for the recipient 220. In the example of Figure 2, there is present a personal server 226, which is an application executed at the second apparatus 220 and works with the client application 224, for enabling the recipient 220 to function as a personal server. Alternatively, the personal server 226 and the client application 224 may be software modules of one application, for example, a mobile application or application installed in an end user device.

[039] The first apparatus 210 is configured to receive identification information 130 of the second apparatus (Step 23). The identification information 130 of the recipient 220, in this example, the email address (also referred to as the email address 130) of the recipient 220, may be inputted via an input/output module (e.g. a keypad, keyboard and the like) of the first apparatus 210 by the first user, Alice. Alternatively, the identification information or part of the identification information 130 may be retrieved from a local address book of the sender 210, an address book stored in a hosting server, or from a server 228 (or another server). For secure communications, a digital certificate comprising a public key of the recipient 220 may also be obtained from a Certificate Authority on behalf of the recipient 220 or the server 226, which is associated with a domain of the recipient 220 and being posted by the client application 224 with the digital certificate comprising the public key of the recipient 220 (Step 22). A secured message for the recipient 220 can be composed at the first apparatus 210 using the identification information 130 of the recipient 220 and a private key of the sender 210 (Step 24). The digital signature of the secured message 132 may be validated at the recipient 220 using an obtained public key In a digital certificate of the sender 210. The public key of the sender 210 may be retrieved from the digital certificate sent along with the secured message 132 or digital certificates previously used and/or stored in the local address book of the recipient 220. Alternatively, the public key of the sender may be obtained from a digital certificate retrieved from the Certificate Authority on behalf of the sender 110 or a server 204, the server 204 being associated with the domain of the sender 210 and being posted by the client application 212 (and/or other software modules residing in the sender 210) with the digital certificate of the sender 210. The encrypted message 132 may also be decrypted at the recipient 220 with a private key associated with the recipient 220 at the time the encrypted message 132 stored in the local message store 222 is being viewed by recipient 220. The encrypted message 132 remains encrypted in the local message store 222, even after viewing. Although secure communications utilising digital certificates is described, it is appreciated that it is an optional feature.

[040] The server 228 may be a central directory configured for allowing the sender 210 and recipient 220 to publish their own digital certificates. The server 228 may be configured for allowing one to use it as an address book to provide digital certificates and/or identification information 130 at the time the message 132 is composed. In one example, the digital certificates of the sender 210 and/or recipient 220 may be stored in a Lightweight Directory Access Protocol (LDAP) server (e.g. 204 and 228 can be LDAP servers). Alternatively, different servers 204 and 228 may be associated with the domains of the sender 210 and the recipient 220 respectively and are posted with respective digital certificates comprising a public key of the sender 210 and the recipient 220 respectively (Steps 21 and 22).

[041] The received identification information 130 of the second apparatus 220 is then used to send from the first apparatus 210 directly to a DNS server 202 without routing through another server for the DNS server 202 to search for resource information 138 of the second apparatus 220. The client application 212 is responsible for querying the DNS server 202 directly without routing through any intermediary servers to obtain resource information 138 or address of the first server configured to receive messages for the recipient 220. In this example, the first server is the second apparatus 220. In the present example, the DNS Server 202 is identified from data of the DNS Server 202 pre-stored in a data storage of the sender 210. The sender 210 needs the address of the first server to communicate with the recipient 220. A DNS query for resource information 138 of the recipient 220 using identification information 130 (or part of it) of the second apparatus is sent from the sender 210 to the DNS Server 202 directly without routing through another server. In return, the sender 210 receives resource information 138 of the recipient 220 directly from the DNS Server 202 without routing through another server (Step 25a). The resource information 138 indicates the first server configured to receive messages for the second apparatus 220. The resource information 138 of the second apparatus 220 contains domain information (e.g. server address in hostname format) of the first server. The domain information (e.g. server address in hostname format) is then used to identify the address of the first server configured for receiving the composed messages for the second apparatus 220. In the example of Figure 2, the address of the first server is an IPv6 address.

[042] In the present example, for Alice to communicate with Bob through Bob's end user device 220, Alice has to compose a message 132 to Bob on her end user device 210. The composed message 132 is sent to the recipient 220 directly via a communication link 230 (Step 26). That is, the resource information 138 (which can be an 'MX' record described later with reference to Figure 3) indicates the recipient 220 as the first server being configured to receive the messages for the second apparatus 220. Once obtained, the resource information 138 can be used to query for the corresponding IPv4 or IPv6 addresses (in this example, it is IPv6 address) of the recipient 220 so as to enable the sender 210 to reach the recipient 220 for communication (Step 25b). [043] As an example, based on the infrastructure of the example of Figure 2, the email address ("bob@domain2.com") 130 of the recipient 220 may be obtained from a local address book. The client application 212 (and/or a software module residing in the sender 210) sends a DNS query of an MX record type with "domaln2.com" (part of the email address 130) to the DNS server 202 to obtain the resource information 138 from the DNS server 202 accessible to the sender 210 using the email address 130 or just the domain information part of the email address 130 of the recipient 220. The DNS server 202 obtains the resource information 138 through the recursion/iteration process (similar to the recursion/ iteration process for locating the resource information 138 in Figure 1). When the resource information 138 in the form of a resource record, or specifically an MX record in the present example, is obtained, the DNS Server 202 replies to the sender 210 with the domain information of the first server (e.g. server address in hostname format). Another DNS query is then made by the sender 210 directly without routing through another server to the DNS Server 202 with the domain information of the first server (e.g. "smtp.domain2.com") so as to resolve the corresponding IP address of the first server (which is the recipient 220 in the present example). Thereafter, the DNS Server 202 looks for the IP address through the recursive/iterative process and replies to the sender 210 directly without routing through another server with the IPv6 address of the recipient 220. The sender 210 can then send messages to the recipient 220 based on the IPv6 address.

[044] The system 200 illustrated in Figure 2 is different from the system 100 in Figure 1 in that the first apparatus 210 retrieves the resource information 138 directly from the DNS Server 202 without routing through another intermediary server (e.g. 104 in Figure 1). The message 132 is also configured to send to the recipient 220 without another intermediary server (e.g. 134 in Figure 1) and receive directly at a local message store 222 of the second apparatus 220 without transmission from any intermediary server (e.g. 134 in Figure 1) (Step 27). Step 27 can be carried out by the personal server 226. Additionally, the client application 224 does not require a retrieval protocol to receive the messages, such as IMAP, if the message is in the form of email.

[045] In simpler terms, the traffic goes over the shortest network path between the two users, Alice and Bob. Thus, if the sender 210 and the recipient 220 are on the same local area network (LAN), the traffic goes at LAN speeds (typically 1 Gbit/s), regardless of Internet Service Provider (ISP) bandwidth, and the ISP connection needs not be up and running. Advantageously, the overall system capacity by having personal servers disclosed herein may be higher, with fewer "single point of failures" nodes.

[046] In this example, it should be appreciated that the number of links in the chain of communication decreases and the implementation of TLS security, if desired, can be enforced easily. It is clear from Figure 2 that there is only one link involved in the chain of communication. The encrypted message 132 will also remain secured and unseen except at the time the recipient 220 views the message (Step 28). The encrypted message 132 remains encrypted in the local message store 222, even after viewing by the recipient 220. The digital signature of the message 132 is validated using the public key of digital certificate of the sender 210 and decrypted using the private key of the recipient 220. The digital certificate of the sender 210 may be obtained from the received message 132 or retrieved from a server 204 or a Certificate Authority on behalf of the recipient 220. The server 204 can be associated with a domain of the sender 210 and being posted by the client application 212 with the digital certificate comprising the public key of the sender 210 (Step 21). An optimised end-to-end communication between the sender 210 and the recipient 220 is achieved in this example.

[047] In the example of Figure 2, the first apparatus 210 or second apparatus 220 may be configured to use Simple Mail Transfer Protocol (SMTP), understood to include SMTP secure (SMTP/S; an extension of SMTP), applicable when the message is an email, [Extensible Messaging and Presence Protocol (XMPP) applicable when the message is a chat message, File Transfer Protocol or Secure File Transfer Protocol (FTP or SFTP) applicable when the message comprises a file, and/or Voice over Internet Protocol (VoIP) applicable when the message comprises voice data. That is, the first apparatus 210 and second apparatus 220 may be configured to use various standard protocols for the purpose of message sending and retrieval.

[048] Optionally, the communication between the first apparatus 210 and the second apparatus 220 may be secured using Transport Layer Security (TLS) or Secured Sockets Layer (SSL). Optionally, for a better system, a backup server (not shown in Figures) may be provided (e.g. a list of prioritized servers is provided, wherein each server in the list is configured to receive messages for the recipient 220) to store messages for the recipient 220 when the personal server application 226 is inactive. The messages can be retrieved from the backup server by the personal server application 226 when the personal server application 226 is active again.

[049} Optionally, the address of the recipient 220 may be dynamic like an IPv6 address. In this case, the resource information 138 (e.g. an MX record) and/or domain information (e.g. an Ά' or 'AAAA' record) and/or address (e.g. IP address) of the recipient 220 may be updated, for instance through a server or source (e.g. IRP-based server) (not shown in Figure 2) to publish updated resource information 138 and/or domain information and/or address of the recipient 220. The server or source (e.g. IRP-based server) can be configured to provide the updated resource information 138 and/or domain information and/or address of the recipient 220 to the DNS Server 202 or an authoritative DNS server (not shown in Figure 2) of the recipient 220. In one example, if the server or source (e.g. IRP-based server) provides the updated resource information 138 and/or domain information and/or address of the recipient 220 to the authoritative DNS server of the recipient 220 and not to the DNS server 202, the DNS server 202 may be able to obtain the updated resource information 138 and/or domain information and/or address of the recipient 220 for the sender 210 from the authoritative DNS server of the recipient 220 after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 220. Once the address is obtained by the sender 210, sending of the message 132 to the local message store 222 of the recipient 220 can commence.

[050] More specifically, there could be a software application (e.g. 224 in Figure 2) residing in the recipient 220 configured to connect to the server or source (e.g. IRP-based server) to update the current IP address of the recipient 220 at the server or source (e.g. IRP-based server) when there is a change in the current IP address. The server or source (e.g. IRP-based server) could be responsible for connecting with the authoritative DNS server of the recipient 220 or the DNS server 202 contestable by the sender 210. In this manner, the sender 210 is able to readily obtain, for instance, the updated address of the recipient 220 from the server or source (e.g. IRP-based server), from the authoritative DNS server of the recipient 220 (after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 220) or from the DNS server 202. As an example, records of the recipient's IP address in the server or source (e.g. IRP-based server) may be listed according to the recipient's host name (which can be based on domain information) pre-registered with the server or source (e.g. IRP-based server).

[051] In yet another example shown in Figure 3, there is provided a data communication system 300 between a first end user device 310 (also known as sender 310) owned by a first user, Alice, and a second end user device 320 (also known as recipient 320) owned by a second user, Bob. The sender 310 is in a DOMAIN A and the recipient 320 is in a DOMAIN B. A key feature of the example of Figure 3 is that the side of the sender 310 is based on IPv6 and the side of the recipient 320 is based on IPv4 or IPv6. For convenience, some of the reference numerals of similar elements in the examples of Figure 1 , Figure 2 and Figure 3 are given the same reference numerals, such as identification information 130, message 132, and resource information 138, which incorporates domain information (e.g. server address in hostname format) of the first server configured to receive messages for the recipient 320. The first server is the mail server 306 in the present example. In this example, the format of the message 132 is in the form of an email. It should be appreciated that for emails, a typical IETF standard-based Client/Server architecture is adopted. Each of the sender 310 and the recipient 320 comprises a client application (client application 312 for the sender 310 and client application 322 for the recipient 320) for allowing the first user or the second user respectively to access messages at the sender 310 or the recipient 320 respectively. In the example of Figure 3, there is present a personal server 326, which is an application executed at the recipient 320 and works with the client application 322, for enabling the recipient 320 to function as a personal server. Alternatively, the personal server 326 and the client application 322 may be software modules of one application, for example, a mobile application or application installed in an end user device.

[052] Upon activation by Alice, the sender 310 can retrieve identification information 130, which is in the present example in the form of an email address (also referred to as the email address 130) from a server 328 (or another server), and a digital certificate comprising a public key of the recipient 320 from the server 328 or a Certificate Authority on behalf of the recipient 320 (Step 33). The server 328 can be associated with the domain of the recipient 320 and being posted by the client application 322 with the digital certificate of the recipient 320 (Step 32).The email address 130 may be also be obtained by an input/output module (e.g. a keypad, keyboard and the like) of the sender 310 or retrieved from a local address book stored in the sender 310.

The server 328 may be a central directory configured for allowing the sender 310 and recipient 320 to publish their own digital certificates. The server 328 may be configured for allowing one to use it as an address book to provide digital certificates and/or identification information 130 at the time the message 132 is composed. In one example, the digital certificates of the sender 310 and/or recipient 320 may be stored in a Lightweight Directory Access Protocol (LDAP) server (e.g. 304 and 328 can be LDAP servers). Alternatively, different servers 304 and 328 may be associated with the domains of the sender 310 and the recipient 320 respectively and are posted by the client applications 312 and 322 with respective digital certificates comprising a public key of the sender 310 and the recipient 320 respectively (Steps 31 and 32). Although secure communications utilising digital certificates is described, it is appreciated that it is an optional feature. If the message 132 is encrypted, it may be decrypted at the recipient 320 with a private key associated with the recipient 320 at the time the encrypted message 132 stored in the local message store 324 is being viewed by recipient 320. The encrypted message 132 remains encrypted in the local message store 324, even after viewing.

The email address 130 provides two pieces of data: mailbox ID and the domain name separated by "@\ In order for the sender 310 to deliver a message to the recipient 320, the sender 310 needs to know the domain of the recipient 320. The domain of the recipient 320 may be retrieved by providing the domain portion within the email address 130 from the sender 310 to a DNS Server 302 to retrieve the resource information 138 in the form of an MX record, a type of resource record. The DNS Server 302 may use the recursive/iterative process (similar to the recursion/ iteration process described with reference to the examples of Figure 1 or Figure 2) to get replies for requests by the sender 310. Data of the DNS Server 302 may be pre-stored in a data storage of the sender 310. For instance, a DNS query for a Name Server record is issued by the sender 310 to the DNS server 302 accessible to the sender 310 to resolve a domain of the recipient 320 through the recursive/Iterative process using the identification information 130 of the recipient 320.

The client application 312 may be responsible for querying with the DNS Server 302 directly without routing through any intermediary servers using the domain portion within the email address 130 (or sending the full email address 130) for obtaining the resource information 138 or address of a first server configured for receiving messages for the second apparatus 320. Once obtained, the resource information 138 can be processed to resolve corresponding IPv4 or IPv6 addresses (in this example, It is IPv4 address) of the first server configured to receive messages for the recipient 320 so as to enable the sender 310 to reach the recipient 320 for communication. The address of the first server may be resolved by way of sending another DNS query by the sender 310 to the DNS Server 302 directly without routing through any server and receiving in return the address of the first server from the DNS Server 302 directly without routing through any server. MX records are a specific type of DNS record used to locate the mail exchanger (in this case, the mail server 306) for the domain specified in the domain name side of the email address 130. The mail exchanger can be any computer configured to accept delivery of email for that domain. In this example, the first server is the mail server 306.

For Alice to communicate with Bob through Bob's end user device 320, Alice has to compose a message 132 to Bob on her end user device 310. The message 132 may be composed at the sender 310 using the email address 130 of the recipient 320, the public key of the recipient 320 and the private key of the sender 310 (Step 34). When the composed e-mail message 132 is sent through the Internet, the client application 312 of the sender 310 queries the Domain Name Server 302 for resource information 138 of each recipient's domain name (In this case, the domain name of the recipient 320). This query may return a server or a list of servers accepting incoming mail for the domain of the recipient 320 and their preferences. Query is done by sending the domain portion within the email address 130 (i.e. using part of the identification information 130) of the recipient 320 directly to the DNS server 302 without routing through another server (e.g. the intermediary server 104 in Figure 1) for the DNS server 302 to search for resource information 138 of the recipient 320. The resource information 138 in this example is one or more 'MX' records. In the present example, the resource information 138 of the recipient 320 indicate domain information comprising a server address of the first server (e.g. server address in hostname format) configured to receive messages for the recipient 320 or a list of server addresses of servers (e.g. server address in hostname format) configured to receive messages for the recipient 320. The first server refers to the mail server 306 in the present example. The list of servers may be recorded with different priority in the MX record, and a priority parameter in the MX record determines an order in which the servers in the list of server addresses of servers are supposed to be contacted (if several servers with different priorities are present). The server or servers with the highest priority (and the lowest preference number) will be tried first. That is, the message 132 will be attempted to be sent to the server with higher priority first.

[057] A typical set of resource information 138, in the form of MX records is illustrated in table 1 as follows:

Table 1

Each line is a single MX record comprising domain information (e.g. server address in hostname format) and each domain can have several MX records. This allows an owner of a domain to specify more than one server that will accept delivery of messages for end user devices (e.g. the recipient 320) in that domain. Multiple servers may be desirable in situations where several servers share the load for one domain, as backup servers or both.

[058] In this example, the MX record for the domain of the recipient 320 is retrieved from an DNS Server 302 (Step 35a) without routing through another server using information in the email address 130 of the recipient 320. Before any sending of the message 132 is done, the IP address of each server (also known as mail exchanger or mail server 306 in the present example) to be attempted by the sender 310 to send the message 132 according to the priority has to be resolved through the DNS Server 302. The MX record can be used to obtain the IP address of the mail exchanger, in other words, the mail server 306 of the recipient 320 (Step 35b). A DNS query is then made to the DNS Server 302 (directly without routing through another server) by the client application 312 using a selected domain information (e.g. server address in hostname format) in the resource information 138 to resolve a corresponding IPv4/IPv6 address of the selected domain information in the resource information 138. In the present example, a returned reply from the DNS Server 302 to the sender 310 directly without routing through another server would specify an IP address (IPv4) for the mail server 306 of the recipient 320. In other examples, the returned reply (directly to the sender without routing through another server) may specify the IPv6 address of the recipient (such as the example of Figure 2) or of an IPv6 supported mail server receiving messages on behalf of the recipient 320. With the IP address known, the sender 310 may then start the attempt to send messages to the recipient 320 based on the IP address and according to the priority provided in the resource information 138.

[059] The resource information 138 may indicate the recipient 320 as the server configured to receive the messages for the recipient 320 without routing through any servers like the example of Figure 2. Alternatively, the MX record may indicate the intermediary SMTP mail server 306 as the server configured to receive the messages (e.g. the message 132) for the recipient 320. In such a case, the client application 322 of the recipient 320 is configured to connect to the intermediary server 306 and periodically or on demand command transmission of any messages residing in a message store 308 of the intermediary server 306 to a local message store 324 of the recipient 320.

[060] In this example, the message 132 is sent to the intermediary SMTP server 306 in the domain of the recipient 320 using SMTP/S. The intermediary SMTP server 306 is configured to receive the message 132 for the recipient 320 (Step 36). The message store 308 may store emails temporarily until the recipient 320 requests for the emails to be retrieved at the second user device 320 (Step 37). Upon request by the recipient 320, in this case using SMTP and ETRN ([Extended Turn), which is an extension to SMTP, the recipient 320 is connected to the intermediary server 306. Thereafter, transmission of the queued message(s) at the intermediary server 306 directly to the local message store 324 of the recipient 320 is initiated (Step 38). Step 38 can be carried out by the personal server 326.

In another arrangement, the recipient 320 may be recorded as top priority in the resource information 138, in the form of MX records, for receiving messages for the recipient 320 wherein any attempt to send a message (e.g. message 132) to the recipient 320 tries sending to the recipient 320 first The resource information 138 may also indicate that a message is sent to the intermediary SMTP server 306 (second priority in the MX records) if a message fails to reach the recipient 320. In the situation that a message fails to be received by the recipient 320 when it is indicated as top priority, any queued messages at the intermediary SMTP server 306 indicated as second priority that is receiving on behalf of the recipient 320 can be retrieved when the recipient 320 is available again. That is, intermediary SMTP server 306 serves as a back-up server for receiving messages for the recipient 320.

Optionally, the communication between the sender 310 and the recipient 320 may be secured using Transport Layer Security (TLS) or Secured Sockets Layer (SSL). Optionally, the first end user device 310 and second end user device 320 may be configured to use various standard protocols (e.g. SMTP, XMPP, SFTP, VoIP) for the purpose of message sending and retrieval.

Optionally, the address of the intermediary SMTP server 306 may be dynamic like an IPv6 address. The resource information 138 and/or domain information (e.g. can be 'A' or 'AAAA' record) and/or address (e.g. IP address) of the intermediary SMTP server 306 may be updated, for instance through a server or source (e.g. IRP-based server) (not shown in Figure 3) to publish updated resource information 138 (e.g. an MX record) and/or domain information and/or address of the recipient 320. The server or source (e.g. IRP-based server) can be configured to provide the updated resource information 138 and/or domain information and/or address of intermediary SMTP server 306 to the DNS Server 302, to an authoritative DNS server (not shown in Figure 3) of the server 306, or to an authoritative DNS server (not shown in Figure 3) of the recipient 320. In one example, if the server or source (e.g. IRP-based server) provides the updated resource information 138 and/or domain information and/or address of the intermediary SMTP server 306 to the authoritative DNS server of the intermediary SMTP server 306 or the authoritative DNS server of the recipient 320 and not to the DNS server 302, the DNS server 302 may be able to obtain the updated resource information 138 and/or domain information and/or address of the intermediary SMTP server 306 for the sender 310 from the authoritative DNS server of intermediary SMTP server 306 or the authoritative DNS server of the recipient 220 after going through the recursive/iterative process to contact the authoritative DNS server of the intermediary SMTP server 306 or the authoritative DNS server of the recipient 220. Once the address is obtained by the sender 310, sending of the message 132 to the local message store 324 of the recipient 320 can commence.

More specifically, there could be a software application (e.g. 322 in Figure 3) residing in the recipient 320 or in the intermediary SMTP server 306 configured to connect to the server or source (e.g. IRP-based server) to update the current IP address of the intermediary SMTP server 306 at the server or source (e.g. IRP-based server) when there is a change in the current IP address. The server or source (e.g. IRP-based server) could be responsible for connecting with the authoritative DNS server of the intermediary SMTP server 306, the authoritative DNS server of the recipient 320 or the DNS server 302 contactable by the sender 310. In this manner, the sender 310 is able to readily obtain, for instance, the updated address of the intermediary SMTP server 306 from the server or source (e.g. IRP-based server), from the authoritative DNS server of the recipient 320 (after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 320), from the authoritative DNS server of the intermediary SMTP server 306 (after going through the recursive/iterative process to contact the authoritative DNS server of the intermediary SMTP server 306), or from the DNS server 302. As an example, records of the IP address of the recipient 320 or the intermediary SMTP server 306 in the server or source (e.g. IRP-based server) may be listed according to the host name (which can be based on domain information) of the recipient 320 or the intermediary SMTP server 306 pre-registered with the server or source (e.g. IRP-based server). [065] In another example shown in Figure 4, there is provided a file transfer communication system 400 between a first end user device 410 (also known as sender 410 or source file server 410) owned by a first user, Alice, and a second end user device 420 (also known as recipient 420 or destination file server 420) owned by a second user, Bob. The sender 410 is in a DOMAIN A and the recipient 420 is in a DOMAIN B. For the example in Figure 4, the side of the sender 410 can be based on IPv6 and the side of the recipient 420 can be based on IPv4 or IPv6. For convenience, some of the reference numerals of similar elements in the examples of Figures 1 to 4 are given the same reference numerals, such as identification information 130, and message 132. Each of the sender 410 and the recipient 420 comprises a client application (FTP/SFTP client application 412 for the sender 410 and FTP/SFTP client application 422 for the recipient 420) for allowing the first user or the second user respectively to access messages at the sender 410 or the recipient 420 respectively. In the example of Figure 4, there is present a personal server 426, which is an application executed at the recipient 320 and works with the client application 422, for enabling the recipient 420 to function as a personal server. Alternatively, the personal server 426 and the client application 422 may be software modules of one application, for example, a mobile application or application installed in an end user device.

[066] In this example, the format of the message 132 is a file (e.g. any type of files such as video files, audio files, text files, data files etc.) or may just comprise the file. To send the file to the recipient 420, the sender 410 has to first obtain identification information 130 of the recipient 420, which in this case is domain information (e.g. server address in hostname format) of the recipient 420, from a server 404 (or another server). For secure communications, a digital certificate containing public key of the recipient 420 may also be obtained by the sender 410 from the server 404 (Step 43).

[067] The server 404 may be a central directory configured for allowing the sender 410 and recipient 420 to publish their own digital certificates. The server 404 may be configured for allowing one to use it as an address book to provide digital certificates and/or identification information at the time the message 132 is composed. In one example, the digital certificates of the sender 410 and/or recipient 420 may be stored in a Lightweight Directory Access Protocol (LDAP) server (e.g. 404 can be a LDAP server). The server 404 may be in domains outside that of the domains of the sender 410 and the recipient 420 respectively. The server 404 may be posted by the FTP/SFTP client application 412 and FTP/SFTP client application 422 or a Certificate Authority on behalf of the sender 410 and the recipient 420 with respective digital certificates comprising a public key of the sender 410 and the recipient 320 respectively (Steps 41 and 42). Although secure communications utilising digital certificates is described, it is appreciated that it is an optional feature.

[068] In the present example, the sender 410 queries a DNS server 402, which uses the recursive/iterative process (similar to the recursion/ iteration process described with reference to the examples of Figure 1 , Figure 2 or Figure 3) to obtain an address of a first server configured to receive the message for the recipient 420. The data of the DNS server 402 to be contacted may be pre-stored in a data storage of the sender 410. In the present example, the first server is actually the recipient 420. The sender 410 will communicate with the DNS server 402 directly without routing through another server. Connection with the first server can commence after the sender 410 obtains the address of the first server from the DNS server 102. Data of the identification information 130, which in this example is the domain information (e.g. server address in hostname format) of the recipient 420, may be included in the query to the DNS server 402. The identification information 130 may be inputted by the first user via an input/output module (e.g. a keypad, keyboard and the like) of the sender 410. .

[069] The client application 412 of the sender 410 may be responsible for sending the query to the Domain Name Server 402 to resolve the address of the first server. The client application 412 queries the DNS Server 402 directly without routing through any intermediary servers for obtaining, in this case, the IP address of the recipient 420. Once obtained, the corresponding IPv4 or IPv6 address (in this example, it is IPv6 address) of the recipient 420 is used so as to enable the sender 410 to reach the recipient 420 for communication.

[070] Specifically, in the present example, the sender 410 sends a DNS query for the address of the recipient 420 using the identification information 130, which is the domain information (e.g. server address in hostname format) of the recipient 420 (e.g. "ftp.domain2.com"), to the DNS Server 402 directly without routing through another server. In return, the DNS Server 402 sends the address of the recipient 420 to the sender 410 directly without routing through another server (Step 44). Querying for the address of the recipient 420 is done by sending a DNS request for the address to the DNS Server 402. After the address of the recipient 420 is known, the sender 410 connects to (Sob's node, which is the recipient 420, based on the address of the recipient 420. After connection, the first user, Alice, may navigate a directory or folder of the recipient 420 made available for transferring or uploading one or more files directly from a local storage medium 414 of the sender 410 to a local storage medium 424 of the recipient 420 or for downloading files directly from the local storage medium 424 to the local storage medium 414 of the sender 410 (step 45).

In another example, resource information (similar to 138 in the earlier figures) of the recipient 420 may be published as an SRV record (e.g. FTP:_ftp._tcp.domain2.com) in the Internet. The 'SRV record is similar but is of a different type from the 'MX' record described in the earlier examples. An 'SRV or Service resource record specifies the location, i.e. hostname and port number, of servers for specified services. In this case, the sender 410 has to first send a request for the SRV record of the recipient 420 to the DNS server 402 directly without routing through another server. The request for the SRV record can be generated at the sender 410 based on user account details that may be in a format similar to an email, which contains details of a domain of the recipient 420 or a domain of a server that can receive messages for the recipient 420. Once the user account details are provided in the request for the SRV record to the DNS server 402, the DNS server 402 will conduct the recursive/iterative process to get the SRV record for the sender 410. The SRV record will contain domain information (e.g. server address in hostname format) of the first server or other servers configured to receive messages for the recipient 410. The first server and other servers may be prioritised in the SRV record to indicate which server is to be contacted first to send messages to the recipient 410. It is possible that the SRV record only shows the first server to be the recipient 420 or lists the recipient 420 as top priority. After the SRV record is received, the sender 410 can then send a request to the DNS server 402 directly without routing through another server to resolve one or more addresses (in this case, IP address) of a server listed in the SRV record to get the address of that server in the SRV record. Once the address is obtained from the DNS server 402, the sender 410 can connect to the server listed in the SRV record. Thereafter, sending of messages (in this case files) to the recipient 420 may commence. For the sender 410 to download files from the recipient 420, the sender 410 should connect directly to the recipient 420. However, it is possible that the recipient 420 upload files to a server that is not the recipient and listed in the SRV record to enable the sender 410 to download those files from the server.

Optionally, the communication between the sender 410 and the recipient 420 may be secured using Transport Layer Security (TLS) or Secured Sockets Layer (SSL). Optionally, the first end user device 410 and second end user device 420 may be configured to use various standard protocols (e.g. SMTP, XMPP, SFTP, VoIP) for the purpose of message sending and retrieval. Optionally, secure communications utilising digital certificates may be implemented. Optionally, the address of the recipient 420 may be dynamic like an IPv6 address. The resource information 138 (e.g. an SRV record; if applicable) and/or domain information (e.g. can be 'A' or 'AAAA' record) and/or address (e.g. IP address) of the recipient 420 may be updated, for instance through a server or source (e.g. IRP-based server) (not shown in Figure 4) to publish updated resource information 138 and/or domain information and/or address of the recipient 420. The server or source (e.g. IRP-based server) can be configured to provide the updated resource information 138 and/or domain information and/or address of the recipient 420 to the DNS Server 402 or an authoritative DNS server (not shown in Figure 4) of the recipient 420. In one example, if the server or source (e.g. IRP-based server) provides the updated resource information 138 and/or domain information and/or address of the recipient 420 to the authoritative DNS server of the recipient 420 and not to the DNS server 402, the DNS server 402 may be able to obtain the updated resource information 138 and/or domain information and/or address of the recipient 420 for the sender 410 from the authoritative DNS server of the recipient 420 after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 420. Once the address is obtained by the sender 410, exchange of messages with the recipient 420 can commence.

More specifically, there could be a software application (e.g. 422 in Figure 4) residing in the recipient 420 configured to connect to the server or source (e.g. IRP-based server) to update the current IP address of the recipient 420 at the server or source (e.g. IRP-based server) when there is a change in the current IP address. The server or source (e.g. IRP-based server) could be responsible for connecting with the authoritative DNS server of the recipient 420 or the DNS server 402 contactable by the sender 410. In this manner, the sender 410 is able to readily obtain, for instance, the updated address of the recipient 420 from the server or source (e.g. IRP-based server), from the authoritative DNS server of the recipient 420 (after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 420) or from the DNS server 402. As an example, records of the recipient's IP address in the server or source (e.g. IRP-based server) may be listed according to the recipient's host name (which can be based on domain information) pre-registered with the server or source (e.g. IRP-based server).

[075] Optionally, for a better system, a backup server (not shown in Figures) may be provided (e.g. a list of prioritized servers is provided, wherein each server in the list is configured to receive messages for the recipient 420) to store messages for the recipient 420 when the personal server application 426 is inactive. The messages can be retrieved from the backup server by the personal server application 426 when the personal server application 426 is active again.

[076] Optionally, the message 132 in the form of a file may be downloaded partially and stored in the local storage medium 414 of the sender 410 if the connection between the sender 410 and the recipient 420 has to be closed before the file can be fully downloaded. The download may resume in the next instance connection is established again between the sender 410 and the recipient 420.

[077] In another example shown in Figure 5, there is provided a chat message communication system 500 between a first end user device 510 (also known as sender 510) owned by a first user, Alice, and a second end user device 520 (also known as recipient 520) owned by a second user, Bob. The sender 510 is in a DOMAIN A and the recipient 520 is in a DOMAIN B. For the example in Figure 5, the side of the sender 510 can be based on IPv6 and the side of the recipient 520 can be based on IPv4 or IPv6. For convenience, some of the reference numerals of similar elements in the examples of Figures 1 to 4 are given the same reference numerals, such as identification information 130, message 132 and resource information 138, which incorporates domain information (e.g. server address in hostname format) of a first server configured to received messages for the recipient 520. Each of the sender 510 and the recipient 520 comprises a client application (XMPP client application 512 for the sender 510 and XMPP client application 522 for the recipient 520) for allowing the first user or the second user respectively to access messages at the sender 510 or the recipient 520 respectively. In the example of Figure 5, there is present a personal server 524, which is an application executed at the recipient 520 and works with the client application 522, for enabling the recipient 520 to function as a personal server. Alternatively, the personal server 524 and the client application 522 may be software modules of one application, for example, a mobile application or application installed in an end user device.

In this example, the format of the message 132 Is a chat message, including text data and may also include picture files, video files, or audio flies. To send the message 132 to the recipient 520, the sender 510 has to first obtain identification Information 130 of the recipient 520, which in this case is a user account identifier (UID) of the recipient 520, from a server 504 (or another server). In the present example, the UID is a Jabber Identifier (ID) (Jabber is the original name of XMPP), which is an address in the form 'usemame@domain'. For secure communications, a digital certificate containing public key of the recipient 520 may also be obtained by the sender 510 from the server 504 (Step 53) or from a Certificate Authority on behalf of the recipient 520.

The server 504 may be a central directory configured for allowing the sender 510 and recipient 520 to publish their own digital certificates. The server 504 may be configured for allowing one to use it as an address book to provide digital certificates and/or identification information 130 at the time the message 132 Is composed. In one example, the digital certificates of the sender 510 and/or recipient 520 may be stored in a Lightweight Directory Access Protocol (LDAP) server (e.g. 504 can be a LDAP server). The server 504 may be in domains outside that of the domains of the sender 510 and the recipient 520 respectively. The server 504 may be posted with respective digital certificates comprising a public key of the sender 510 and the recipient 520 respectively (Steps 51 and 52). Although secure communications utilising digital certificates is described, it is appreciated that it is an optional feature.

In the present example, the sender 510 queries a DNS server 502, which uses the recursive/iterative process (similar to the recursion/ iteration process described with reference to the examples of Figure 1 , Figure 2, Figure 3 or Figure 4) to obtain resource information 138 of the recipient 520, which can include a first server configured to receive the message for the recipient 520. The data of the DNS server 502 to be contacted may be pre- stored in a data storage of the sender 510. In the present example, the first server is actually the recipient 520. The sender 510 will communicate with the DNS server 502 directly without routing through another server. Data of the identification information 130, which in this example is the Jabber ID of the recipient 520 (e.g. domain portion 'domain2.com' within the Jabber ID: usemame@domain2.com), is included in the query to the DNS server 502. The identification information 130 may be inputted by the first user via an input/output module (e.g. a keypad, keyboard and the like) of the sender 510.

[081] The client application 512 of the sender 510 may be responsible for sending the query to the Domain Name Server 502 to obtain the resource information 138 of the recipient 520. The client application 512 queries the DNS Server 502 directly without routing through any intermediary servers for obtaining the resource information 138. Once obtained, the resource information 138 can be used to resolve or obtain, in this example, corresponding IPv4 or IPv6 address (in this example, it is IPv6 address) of the first server so as to enable the sender 510 to reach the recipient 520 for communication. The IP address of the first server may be resolved by way of sending another query by the sender 510 to the DNS server 502 directly without routing through any server and receiving in return the address of the recipient 520 from the DNS server 502 directly without routing through any server. The IP address of the first server is required in order for the sender 510 to connect and communicate with the recipient 520.

[082] Specifically, in the present example, the sender 510 sends a DNS query of SRV record type using the identification information 130 or, more specifically, a portion of the identification information 130 (e.g. "_xmpp._tcp.domain2.com", where 'top' stands for Transmission Control Protocol) to the DNS server 502 directly without routing through another server. In return, the DNS server 502 sends the resource information 138 of the recipient 520 to the sender 510 directly without routing through another server (Step 54a). The resource information 138 in the present example is in the form of an SRV record containing domain information (e.g. server address in hostname format) of the first server configured to receive messages (chats) for the recipient 520 or to connect to the recipient 520 for exchange of messages (chats) with the sender 410. The first server in the present example is actually the recipient 520 itself. In other examples, the first server may be an intermediary server configured to receive messages for the recipient 520 and the recipient 520 retrieves messages from the intermediary server upon request or periodically. The first server may also be one that can facilitate connection to the recipient 520. The resource information 138 may also indicate a list of prioritised servers like in the example of Figure 3, wherein each server in the list is configured to receive messages for the recipient 520 or for connecting to the recipient 520 for exchange of messages with the sender 520. As mentioned before, the 'SRV record is similar but is of a different type from the 'MX' record described in the earlier examples. An 'SRV or Service resource record specifies the location, i.e. hostname and port number, of servers for specified services.

[083] Upon obtaining the resource information 138, the sender 510 queries for the address of the first server by sending a request for the address (e.g. xmpp.domain2.com) to the DNS Server 502 (Step 54b). After the address of the first server is known, the sender 510 receives the address directly from the DNS Server 502 without routing through another server. In this example, the address is an IPv6 address of the recipient 520. The sender 510 connects to Bob's XMPP server, which is the recipient 520, based on the address of the recipient 520 (Step 55). After connection, the first user, Alice, may now chat via chat messages with the second user, Bob, through their respective connected first end user device 510 and second end user device 520 (Step 56). The chat messages exchanged between them are directly saved Into respective local storage mediums (not shown in Figure 5) of the sender 510 and recipient 520. It should be appreciated the second user (i.e. Bob) 520 can be offline (if he had closed his client application 522) at the time the first user (i.e. Alice) sends the message 132 to the second end user. However, in such arrangement, as long as the personal server application 524 is still active, the incoming chat messages can still be stored directly at the local storage medium of the recipient 520. These chat messages can be received at the recipient 520 when the second end user launches the client application 522 again. For a better system, a backup server (not shown in Figures) may be provided to store messages for the recipient 520 when the personal server application 524 is inactive. The messages can be retrieved from the backup server by the personal server application 524 when the personal server application 524 is active again.

[084] Optionally, the communication between the sender 510 and the recipient 520 may be secured using Transport Layer Security (TLS) or Secured Sockets Layer (SSL). Optionally, the first end user device 510 and second end user device 520 may be configured to use various standard protocols (e.g. SMTP, XMPP, SFTP, VoIP) for the purpose of message sending and retrieval. Optionally, secure communications utilising digital certificates may be implemented.

[085] Optionally, the address of recipient 520 may be dynamic like an IPv6 address. The resource information 138 and/or domain information (e.g. can be 'A' or 'AAAA' record) and/or address (e.g. IP address) of the recipient 520 may be updated, for instance through a server or source (e.g. IRP-based server) (not shown in Figure 5) to publish updated resource information 138 (e.g. an SRV record) and/or domain information and/or address of the recipient 520. The server or source (e.g. IRP-based server) can be configured to provide the updated resource information 138 and/or domain information and/or address of the recipient 520 to the DNS Server 502 or an authoritative DNS server (not shown in Figure 5) of the recipient 520. In one example, if the server or source (e.g. IRP-based server) provides the updated resource information 138 and/or domain information and/or address of the recipient 520 to the authoritative DNS server of the recipient 520 and not to the DNS server 502, the DNS server 502 may be able to obtain the updated resource information 138 and/or domain information and/or address of the recipient 520 for the sender 510 from the authoritative DNS server of the recipient 520 after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 520. Once the address is obtained by the sender 510, sending of the message 132 to the local message store (not shown in Figure 5) of the recipient 520 can commence.

[086] More specifically, there could be a software application (e.g. 522 in Figure 5) residing in the recipient 520 configured to connect to the server or source (e.g. IRP-based server) to update the current IP address of the recipient 520 at the server or source (e.g. IRP-based server) when there is a change in the current IP address. The server or source (e.g. IRP-based server) could be responsible for connecting with the authoritative DNS server of the recipient 520 or the DNS server 502 contactable by the sender 510. In this manner, the sender 510 is able to readily obtain, for instance, the updated address of the recipient 320 from the server or source (e.g. IRP-based server), from the authoritative DNS server of the recipient 520 (after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 520) or from the DNS server 502. As an example, records of the recipient's IP address in the server or source (e.g. IRP-based server) may be listed according to the recipient's host name (which can be based on domain information) pre-registered with the server or source (e.g. IRP-based server).

Optionally, for a better system, a backup server (not shown in Figures) may be provided (e.g. a list of prioritized servers is provided, wherein each server in the list is configured to receive messages for the recipient 520) to store messages for the recipient 520 when the personal server application 524 is inactive. The messages can be retrieved from the backup server by the personal server application 524 when the personal server application 524 is active again. In another example shown in Figure 6, there is provided a VoIP communication system 550 between a first end user device 560 (also known as sender 560) owned by a first user, Alice, and a second end user device 570 (also known as recipient 570) owned by a second user, Bob. The sender 560 is in a DOMAIN A and the recipient 570 is in a DOMAIN B. For the example in Figure 6, the side of the sender 560 can be based on IPv6 and the side of the recipient 570 can be based on IPv4 or IPv6. For convenience, some of the reference numerals of similar elements in the examples of Figures 1 to 5 are given the same reference numerals, such as identification information 130, message 132, and resource information 138, which contains domain information (e.g. server address in hostname format) of a first server configured to receive messages for the recipient 570. The first server in the present example is actually the recipient 570 itself. Each of the sender 510 and the recipient 520 comprises a client application (VoIP client application 562 for the sender 560 and VoIP client application 572 for the recipient 570) for allowing the first user or the second user respectively to access messages at the sender 560 or the recipient 570 respectively. In the example of Figure 6, there is present a personal server 574, which is an application executed at the recipient 570 and works with the client application 572, for enabling the recipient 570 to function as a personal server. Alternatively, the personal server 574 and the client application 572 may be software modules of one application, for example, a mobile application or application installed in an end user device.

In this example, the format of the message 132 is audio data, which may be in the form of audio streams and/or video streams. To send the message 132 to the recipient 570, the sender 560 has to first obtain identification information 130 of the recipient 570, which in this case can be a user account identifier (UID) or a hostname of the recipient 570, from a server 554. In the present example, the identification information 130 is the user account identifier of the recipient 570. For secure communications, a digital certificate containing public key of the recipient 570 may also be obtained by the sender 560 from the server 554 or a Certificate Authority on behalf of the recipient 570 (Step 63).

The server 554 may be a central directory configured for allowing the sender 560 and recipient 570 to publish their own digital certificates. The server 554 may be configured for allowing one to use it as an address book to provide digital certificates and/or identification information 130 at the time the message 132 is composed. In one example, the digital certificates of the sender 560 and/or recipient 570 may be stored in a Lightweight Directory Access Protocol (LDAP) server (e.g. the server 554 can be a LDAP server). The server 554 may be in domains outside that of the domains of the sender 510 and the recipient 520 respectively. The server 554 may be posted with respective digital certificates comprising a public key of the sender 560 and the recipient 570 respectively (Steps 61 and 62). Although secure communications utilising digital certificates is described, it is appreciated that it is an optional feature.

In the present example, the sender 560 queries a DNS server 552, which uses the recursive/iterative process (similar to the recursion/ iteration process described with reference to the examples of Figure 1, Figure 2, Figure 3, Figure 4 and Figure 5) to obtain resource information 138 of the recipient 570, which can include a first server configured to receive the message for the recipient 570. The data of the DNS server 552 to be contacted may be pre-stored in a data storage of the sender 510. In the present example, the first server is actually the recipient 570. The sender 560 will communicate with the DNS server 552 directly without routing through another server. Data of the identification information 130, which in this example is the UID of the recipient 570 (e.g. domain portion 'domain3.com' within the UID: username@domain3.com), is included in the query to the DNS server 552. The identification information 130 may be inputted by the first user via an input/output module (e.g. a keypad, keyboard and the like) of the sender 560.

The client application 562 of the sender 510 may be responsible for sending the query to the Domain Name Server 502 to obtain the resource information 138 of the recipient 520. The client application 562 queries the DNS Server 552 directly without routing through any intermediary servers for obtaining the resource information 138. Once obtained, the resource information 138 can be used to resolve or obtain, in this example, corresponding IPv4 or IPv6 address (in this example, it is IPv6 address) of the first server so as to enable the sender 560 to reach the recipient 570 for communication. The IP address of the recipient 570 may be resolved by way of sending another query by the sender 560 to the DNS server 552 directly without routing through any server and receiving in return the address of the recipient 570 from the DNS Server 552 directly without routing through any server. The IP address of the recipient 520 is required in order for the sender 560 to connect and communicate with the recipient 520.

Specifically, in the present example, the sender 560 sends a DNS query of SRV record type using the identification information 130 or, more specifically, a portion of the identification information 130 (e.g. "_sip._tcp.domain2.com" or "_sip._udp.domain2.com", where 'sip' stands for Session Initiation Protocol, 'top' stands for Transmission Control Protocol and 'udp' stands for User Datagram Protocol) to the DNS server 552 directly without routing through another server. In return, the DNS server 552 sends the resource information 138 of the recipient 570 to the sender 560 directly without routing through another server (Step 64a). The resource information 138 in the present example is in the form of an SRV record containing domain information (e.g. server address in hostname format) of the first server configured to receive messages (audio streams) for the recipient 570 or to connect to the recipient 570 for exchange of messages (audio streams) with the sender 560. The first server in the present example is actually the recipient 570 itself. In other examples, the first server may be an intermediary server configured to facilitate connection to the recipient 570. The resource information 138 may also indicate a list of prioritised servers like in the example of Figure 3, wherein each server in the list is configured for connecting to the recipient 570. As mentioned earlier, the 'SRV record is similar but is of a different type from the ' X' record described in the earlier examples. An 'SRV or Service resource record specifies the location, i.e. hostname and port number, of servers for specified services.

[094] Upon obtaining the resource information 138, the sender 560 queries for the address of the first server by sending a DNS request for the address (e.g. sip.domain2.com) to the DNS server 552 (Step 64b). After the address of the first server is known, the sender 560 receives the address directly from the DNS server 552 without routing through another server. In this example, the address is an IPv6 address of the recipient 570. The sender 560 connects to Bob's VoIP server, which is the recipient 520, based on the address of the recipient 520 (Step 65). After connection, the sender 560 connects to Bob's VoIP server, which is the recipient 570, based on the address of the recipient 570 (step 65). After connection, the first user, Alice, may now talk (in other words, exchange audio streams 132) with the second user, Bob, through their respective connected first end user device 560 and second end user device 570 (Step 66). The audio streams 132 exchanged between them can be directly saved into respective local storage mediums (not shown in Figure 5) of the sender 560 and recipient 570.

[095] Optionally, the communication between the sender 560 and the recipient 570 may be secured using Transport Layer Security (TLS) or Secured Sockets Layer (SSL). Optionally, the first end user device 560 and second end user device 570 may be configured to use various standard protocols (e.g. SMTP, XMPP, SFTP, VoIP) for the purpose of message sending and retrieval. Optionally, secure communications utilising digital certificates may be implemented.

[096] Optionally, the address of the recipient 570 may be dynamic like an IPv6 address. T e resource information 138 (e.g. an SRV record) and/or domain information (e.g. can be 'A' or 'ΑΑΑΑ' record) and or address (e.g. IP address) of the recipient 570 may be updated, for instance through a server or source (e.g. IRP-based server) (not shown in Figure 6) to publish updated resource information 138 and/or domain information and/or address of the recipient 570. The server or source (e.g. IRP-based server) can be configured to provide the updated resource information 138 and/or domain information and/or address of the recipient 570 to the DNS Server 552 or an authoritative DNS server (not shown in Figure 6) of the recipient 570. In one example, if the server or source (e.g. IRP-based server) provides the updated resource information 138 and/or domain information and/or address of the recipient 570 to the authoritative DNS server of the recipient 570 and not to the DNS server 552, the DNS server 552 may be able to obtain the updated resource information 138 and/or domain information and/or address of the recipient 570 for the sender 560 from the authoritative DNS server of the recipient 570 after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 570. Once the address is obtained by the sender 560, exchange of messages with the recipient 570 can commence.

More specifically, there could be a software application (e.g. 572 in Figure 6) residing in the recipient 570 configured to connect to the server or source (e.g. IRP-based server) to update the current IP address of the recipient 570 at the server or source (e.g. IRP-based server) when there is a change in the current IP address. The server or source (e.g. IRP-based server) could be responsible for connecting with the authoritative DNS server of the recipient 570 or the DNS server 552 contactable by the sender 560. In this manner, the sender 560 is able to readily obtain, for instance, the updated address of the recipient 570 from the server or source (e.g. IRP-based server), from the authoritative DNS server of the recipient 570 (after going through the recursive/iterative process to contact the authoritative DNS server of the recipient 570) or from the DNS server 552. As an example, records of the recipient's IP address in the server or source (e.g. IRP-based server) may be listed according to the recipient's host name (which can be based on domain information) pre-registered with the server or source (e.g. IRP-based server).

Optionally, for a better system, a backup server (not shown in Figures) may be provided (e.g. a list of prioritized servers is provided, wherein each server in the list is configured to receive messages for the recipient 570) to store messages for the recipient 570 when the personal server application 574 is inactive. The messages can be retrieved from the backup server by the personal server application 574 when the personal server application 574 is active again. Figure 8 shows a flow chart 700 of a method for communication between a sender and a recipient. The sender being an end user device comprising a client application for allowing a user to access messages at the end user device. The method comprising the steps as follows. [0100] At a step 702, receiving at the sender domain information (e.g. server address in hostname format) of a first server, the first server being configured to receive messages for the recipient. In some examples, the domain information is obtained by querying resource information of the recipient from a Domain Name Server using identification information of the recipient. The Domain Name Server may get the resource information using a recursion/iteration process. The resource information may be In the form of a resource record of the recipient, wherein the resource record indicates a first server configured to receive messages for the recipient The resource information may also indicate a list of prioritised servers like in the example of Figure 3, wherein each server in the list is configured to receive messages for the recipient or for connecting to the recipient for exchange of messages with the sender. The first server may be the recipient itself. Once obtained, the resource information can be used to query for the corresponding IPv4 or IPv6 addresses of the first server so as to be able to reach the recipient for communication (e.g. step 704).

[0101] At a step 704, sending at the sender a request for address (e.g. IPv6 address or IPv4 address) of the first server directly to a Domain Name Server without routing through another server based on the domain information. The Domain Name Server may get the address using a recursion/Iteration process..

[0102] At a step 706, receiving at the sender the address (e.g. IPv6 address or IPv4 address) of the first server directly from the Domain Name Server without routing through another server.

[0103] At a step 708, sending from the sender a message to the recipient based on the address (e.g.

IPv6 address or IPv4 address) of the first server.

[0104] Optionally, the communication between the sender and the recipient may be secured using Transport Layer Security (TLS) or Secured Sockets Layer (SSL). Optionally, the end user device may be configured to use various standard protocols (e.g. SMTP, XMPP, SFTP, VoIP) for the purpose of message sending and retrieval. Optionally, secure communications utilising digital certificates may be implemented.

[0105] Optionally, the address of the first server may be dynamic like an IPv6 address. The resource information (e.g. an SRV record) and/or domain information (e.g. can be Ά' or 'AAAA' record) and/or address (e.g. IP address) of the first server may be updated, for instance through a server or source (e.g. IRP-based server) to publish updated resource information and/or domain information and/or address of the first server. The server or source (e.g. IRP-based server) can be configured to provide the updated resource information and/or domain information and/or address of the recipient to the Domain Name Server or an authoritative DNS server of the first server. In one example, if the server or source (e.g. IRP-based server) provides the updated resource information and/or domain information and/or address of the first server to the authoritative DNS server of the first server and not to the Domain Name Server, the Doman Name Server may be able to obtain the updated resource information and/or domain information and/or address of the first server for the sender from the authoritative DNS server of the first server after going through the recursive/iterative process to contact the authoritative DNS server of the first server. Once the address is obtained by the sender, sending of a message to the first server or exchange of messages with the first server can commence.

[0106] More specifically, there could be a software application residing in the first server configured to connect to the server or source (e.g. IRP-based server) to update the current IP address of the first server at the server or source (e.g. IRP-based server) when there is a change in the current IP address. The server or source (e.g. IRP-based server) could be responsible for connecting with the authoritative DNS server of the first server or the Domain Name Server contactable by the sender. In this manner, the sender is able to readily obtain, for instance, the updated address of the first server from the server or source (e.g. IRP-based server), from the authoritative DNS server of the first server (after going through the recursive/iterative process to contact the authoritative DNS server of the first server) or from the Domain Name Server. As an example, records of the recipient's IP address in the server or source (e.g. IRP- based server) may be listed according to the recipient's host name (which can be based on domain information) pre-registered with the server or source (e.g. IRP-based server).

[0107] In summary, examples of the present disclosure may have the following features.

[0108] An apparatus (e.g. 110, 210, 310, 410, 510, and 560 in Figures 1 to 6) for communication with a second apparatus (e.g. 120, 220, 320, 420, 520, and 570 in Figures 1 to 6), the apparatus being an end user device comprising a client application (e.g. 112, 212, 312, 412, 512 and 562 in Figures 1 to 6) for allowing a user to send a message at the end user device, the apparatus comprising: a processor (e.g. 618 and 676 in Figure 7) configured to execute one or more applications to operate the apparatus for receiving domain information of a first server (e.g. 120, 220, 320, 420, 520, and 570 in Figures 1 to 6, 134 in Figure 1 or 306 in Figure 3), the first server being configured to receive messages for the second apparatus; sending a request for an address of the first server directly to a Domain Name Server (e.g. 102, 202, 302, 402, 502, and 552 in Figures 1 to 6) without routing through another server based on the domain information; receiving the address of the first server directly from the Domain Name Server without routing through another server; sending a message to the second apparatus based on the address of the first server.

[0109] The first server may be the second apparatus and the second apparatus may be an end user device comprising a client application (e.g. 122, 224, 322, 422, 522 and 572 in Figures 1 to 6) for allowing a user to access the sent message at the second apparatus.

[0110] If the first server is not the second apparatus and the second apparatus is an end user device comprising a client application (e.g. 122, 224, 322, 422, 522 and 572 in Figures 1 to 6) for allowing a user to access messages at the second apparatus, the client application of the second apparatus may be configured to connect to the first server and command transmission of any message on the first server to the second apparatus.

[0111] The message may be stored in a local message store (e.g. 222, 324, and 424 of Figures 2 to 4) of the second apparatus.

[0112] The apparatus may be further operated for receiving identification information (e.g. 130 in Figures 1 to 6) of the second apparatus; sending a request for resource information (e.g. 138 in Figures 1 to 6) of the second apparatus using identification information of the second apparatus to the Domain Name Server without routing through another server; and receiving the resource information of the second apparatus directly from the Domain Name Server without routing through another server, wherein the resource information indicates the first server is configured to receive messages for the second apparatus and the resource information comprises the domain information of the first server.

[0113] The first server may be recorded as top priority in the resource information for receiving messages for the second apparatus wherein any attempt to send a message to the second apparatus tries sending to the first server first.

[0114] If the first server is the second apparatus and a message fails to reach the second apparatus, the apparatus may be further operated for sending the message to a second server (e.g. 134 and 306 in Figures 1 and 3 respectively) indicated in the resource information to receive the message.

[0115] The apparatus may be further operated for: obtaining a digital certificate of the second apparatus from a third server (128, 228, 328, 404, 504, and 554 in Figures 1 to 6); and composing at the apparatus an encrypted message directed to the identification information of the second apparatus using the obtained digital certificate of the second apparatus and signing the encrypted message with a private key of the apparatus. The encrypted message may also be decrypted at the recipient with a private key associated with the recipient at the time the encrypted message stored in the local message store is being viewed by the recipient (as described in Figures 1 to 3). The encrypted message remains encrypted in the local message store, even after viewing.

[0116] The apparatus may be further operated for validating at the second apparatus a digital signature of the encrypted message using a public key in a digital certificate of the apparatus; and decrypting at the second apparatus the received encrypted message with a private key of the second apparatus.

[0117] The apparatus or second apparatus may be configured to use Simple Mail Transfer Protocol (SMTP) applicable when the message is an email, Extensible Messaging and Presence Protocol (XMPP) applicable when the message is a chat message, File Transfer Protocol or Secure File Transfer Protocol (FTP or SFTP) applicable when the message comprises a file, and/or Voice over Internet Protocol (VoIP) applicable when the message comprises voice data.

[0118] Communication between the apparatus and the second apparatus may be secured using Transport Layer Security (TLS) or Secured Sockets Layer (SSL).

[0119] The address of the first server may be recorded at a fourth server (e.g. IRP based server), the first server is configured for connecting to the fourth server to update the recorded address of the first server when there is a change in the address of the first server, and the fourth server is configured for providing the updated address to an authoritative Domain Name Server of the first server so that the apparatus is able to readily obtain the updated address of the first server from the authoritative Domain Name Server of the first server through the Domain Name Server.

[0120] Furthermore, the address of the first server may be recorded at a fourth server (e.g. IRP based server), however, the first server is configured for connecting to the fourth server to update the recorded address of the first server when there is a change in the address of the first server, and the fourth server is configured for providing the updated address of the first server to the apparatus. It is appreciated that the fourth server may be configured for both providing the updated address to the authoritative Domain Name Server of the first server so that the apparatus is able to readily obtain the updated address of the first server from the authoritative Domain Name Server of the first server through the Domain Name Server and providing the updated address of the first server to the apparatus.

[0121] The domain information of the first server or the resource information of the second apparatus may be published at a source (e.g. IRP based server) capable of providing updated domain information of the first server or resource information of the second apparatus to an authoritative Domain Name Server of the first server so that the apparatus is able to readily obtain the updated domain information of the first server or the updated resource information of the second apparatus from the authoritative Domain Name Server of the first server through the Domain Name Server (E.g. using the recursive/iterative process).

[0122] There may be provided an apparatus for receiving the message sent from the apparatus (e.g. 110, 210, 310, 410, 510, and 560 in Figures 1 to 6) for communication with the second apparatus (e.g. 120, 220, 320, 420, 520, and 570 in Figures 1 to 6). The apparatus may be the recipient (e.g. 120, 220, 320, 420, 520, and 570 in Figures 1 to 6) or the first server configured to receive messages for the apparatus or a server in a list of prioritized servers stored in the resource information (e.g. 138 in Figures 1 to 3, 5 to 6) of the apparatus, wherein each server in the list is configured to receive messages for the apparatus.

[0123] A method (700 In Figure 8) for communication between a sender (e.g. 110, 210, 310, 410, 510, and 560 in Figures 1 to 6) and a recipient (e.g. 120, 220, 320, 420, 520, and 570 in Figures 1 to 6), the sender being an end user device comprising a client application (e.g. 114, 212, 312, 412, 512 and 562 in Figures 1 to 6) for allowing a user to send a message at the end user device, the method comprising: receiving at the sender domain information of a first server, the first server being configured to receive messages for the recipient (step 702 of Figure 8); sending at the sender a request for an address of the first server directly to a Domain Name Server (e.g. 102, 202, 302, 402, 502, and 552 in Figures 1 to 6) without routing through another server based on the domain information (step 704 of Figure 8); receiving at the sender the address of the first server directly from the Domain Name Server without routing through another server (step 706 of Figure 8); and sending from the sender a message to the recipient based on the address of the first server (step 708 of Figure 8).

[0124] A non-transitory computer readable medium storing one or more applications executable by a processor (e.g. 618 and 676 in Figure 7) to perform a method for communication between a sender (e.g. 110, 210, 310, 410, 510, and 560 in Figures 1 to 6) and a recipient (e.g. 120, 220, 320, 420, 520, and 570 in Figures 1 to 6), the sender being an end user device comprising a client application (e.g. 114, 212, 312, 412, 512 and 562 in Figures 1 to 6) for allowing a user to send a message at the end user device, the method comprising: receiving at the sender domain information of a first server, the first server being configured to receive messages for the recipient; sending at the sender a request for an address of the first server directly to a Domain Name Server (e.g. 102, 202, 302, 402, 502, and 552 in Figures 1 to 6) without routing through another server based on the domain information; receiving at the sender the address of the first server directly from the Domain Name Server without routing through another server; and sending from the sender a message to the recipient based on the address of the first server.

[0125] In the examples described with reference to Figures 1 to 6, the queries sent from the sender (e.g. 110, 210, 310, 410, 510, and 560 in Figures 1 to 6) to the DNS server (e.g. 102, 202, 302, 402, 502, and 552 in Figures 1 to 6) may be in form of a User Datagram Protocol (UDP) datagram (packet).

[0126] Each of the first user device 110 in Figure 1, first user device 210 in Figure 2, first user device 310 in Figure 3, first user device 410 In Figure 4, first user device 510 in Figure 5, and first user device 560 in Figure 6 may be a computing or mobile device 600 schematically shown in Figure 7. There may be provided software, such as one or more computer programs being executed within the computing device 600, and instructing the computing device 600 to connect and communicate with a second computing or mobile device 634 according to the operations described with reference to the earlier figures. The system architecture of the second computing or mobile device 634 can be the same as that of the computing device 600 and vice versa and not limited to what is described herein. The second user device 120 in Figure 1, second user device 220 in Figure 2, second user device 320 in Figure 3, second user device 420 in Figure 4, second user device 520 in Figure 5, and second user device 570 in Figure 6 can be the second computing or mobile device 634. There may be provided software, such as one or more computer programs being executed within the second computing or mobile device 634, and instructing the second computing or mobile device 634 to connect and communicate with the computing or mobile device 600 according to the operations described with reference to the earlier figures.

[0127] The intermediary servers (104 and 134 in Figure 1, and 306 in Figure 3), DNS servers (102, 202, 302, 402, 502, and 552 in the respective Figures), and other servers (108, 128, 204, 228, 304, 328, 404, 504, 554 in the respective Figures) as disclosed herein may also be a server apparatus 650 shown in Figure 7. There may be provided software, such as one or more computer programs being executed within the server apparatus 650 to carry out the operations of the respective servers as well.

[0128] The server apparatus 650 may be a single server as illustrated schematically in Figure 7, or have functionality performed by the server apparatus 650 distributed across multiple server components. In the example of Figure 7, the server apparatus 650 may comprise a number of individual components Including, but not limited to, microprocessor 656, a memory 658 (e.g. a volatile memory such as a Random Access Memory (RAM)) for the loading of executable instructions 660, the executable instructions defining the functionality the server apparatus 650 carries out under control of the processor 656. The server apparatus 650 also comprises a network module 652 allowing the server to communicate over the communications network 612 (for example the internet). User interface 662 is provided for user interaction and may comprise, for example, conventional computing peripheral devices such as display monitors, computer keyboards and the like. The server apparatus 650 may also comprises a database 654. It should also be appreciated that the database 654 may not be local to the server apparatus 650. The database 654 may be a cloud database.

[0129] The computing device 600 can comprise a processing unit 602 for processing the one or more computer programs. The processing unit 602 is connected to input/output devices such as a computer mouse 636, keyboard/keypad 604, a display 608, headphones or microphones 626 (required for VoIP application of Figure 6), a video camera 640 and the like via Input/Output (I/O) interfaces 624. The processing unit 602 may include a processor 618, a Random Access Memory (RAM) 620 and a Read Only Memory (ROM) 622. The components of the processing unit 602 typically communicate via an interconnected bus 628 and in a manner known to the person skilled in the relevant art.

[0130] The processing unit 602 may be connected to the network 612, for instance, the Internet, via a suitable transceiver device 614 (i.e. a network interface) or a suitable wireless transceiver 632, to enable access to e.g. the Internet or other network systems such as a wired Local Area Network (LAN) or Wide Area Network (WAN). The processing unit 602 of the computing device 600 may also be connected to one or more external wireless communication enabled electronic devices 634 or the server 650 through the respective communication links 680, 682, 684 via the suitable wireless transceiver device 632 e.g. a WiFi transceiver, Bluetooth module, Mobile telecommunication transceiver suitable for Global System for Mobile Communication (GSM), 3G, 3.5G, 4G telecommunication systems, or the like.

[0131] The second computing or mobile device 634 may be, for example, smart phones, tablet devices, and other handheld devices. The one or more second computing or mobile device 634 may be able to communicate through other communications network, such as, wired network, mobile telecommunication networks, but these are omitted from Figure 7 for the sake of clarity. Instead of the system architecture described above for the computing or mobile device 600, the computing or mobile device 600 may have the system architecture of the second computing or mobile device 634.

[0132] The second computing or mobile device 634 may comprise a number of individual components including, but not limited to, microprocessor 676, a memory 648 (e.g. a volatile memory such as a RAM) for the loading of executable instructions 670, the executable instructions defining the functionality the second computing or mobile device 634 carries out under control of the processor 676. The second computing or mobile device 634 also comprises a network module 672 allowing the second computing or mobile device 634 to communicate over the communications network 612. User interface 692 is provided for user interaction and control that may be in the form of a touch panel display and presence of a keypad as is prevalent in many smart phone and other handheld devices. The second computing or mobile device 634 may also comprise a database 674. It should also be appreciated that the database 674 may not be local to the second computing or mobile device 634. The database 674 may be a cloud database. The second computing or mobile device 634 may include a number of other Input/Output (I/O) interfaces as well but they may be for connection with headphones or microphones 694 (required for VoIP application of Figure 6), Subscriber identity module (SIM) card 696, flash memory card 698, USB based device 699, and the like, which are more for mobile device usage.

[0133] The software and one or more computer programs may include, for example, the client applications 114, 124, 212, 224, 312, 322, 412, 422, 510, 522, 562, and 572 of the respective figures and the personal server applications 226, 326, 426, 524, and 574, and may further include one or more software applications for e.g. instant messaging platform, audio/video playback, internet accessibility, operating the computing or mobile device 600 (i.e. operating system) or the second computing or mobile device 634, network security, file accessibility, database management, which are applications typically equipped on a desktop or portable (mobile) device. The software and one or more computer programs may be supplied to the user of the computing or mobile device 600 or the second computing or mobile device 634 encoded on a data storage medium such as a CD-ROM, on a flash memory carrier or a Hard Disk Drive, and are to be read using a corresponding data storage medium drive of for instance, a data storage device 630 in Figure 7. Such application programs may also be downloaded from the network 612. The application programs are read and controlled in its execution by the processor 618 or microprocessor 676. Intermediate storage of program data may be accomplished using RAM 620 or 648.

[0134} Furthermore, one or more of the steps of the computer programs or software may be performed in parallel rather than sequentially. One or more of the computer programs may be stored on any machine or computer readable medium that may be non-transitory in nature. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer or mobile device. The machine or computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the Wireless LAN (WLAN) system. The computer program when loaded and executed on such a general-purpose computer effectively results in an apparatus (e.g. 110,120, 210, 220, 310, 320, 410, 420, 510, 520, 560, 570 in the respective Figures) that implements the steps of the computing methods in examples herein described.

[0135] Many modifications and other examples can be made to the apparatus and method for communication with a second apparatus by those skilled in the art having the understanding of the above described disclosure together with the drawings. Therefore, it is to be understood that the apparatus and method for communication with the second apparatus is not to be limited to the above description contained herein only, and that possible modifications are to be included in the claims of the disclosure. Any features found in any one of the examples in the Figures can also be applied to the example in another Figure if deemed suitable to a skilled person.