Abstract:
A method of transmitting a message from a first entity to a terminal of a user over a communication system operated by a second entity. The method comprises: the second entity authorizing the first entity to access a message transmission means connected to the communication system; the first entity transmitting the message to the message transmission means; the message transmission means generating a notification message from the message and storing the message in a storage means; transmitting the notification message to a client executed on the terminal over the communication system; responsive to receiving the notification message, the client communicating with the storage means to ascertain the identity of the first entity that transmitted the message, and determining whether the user has selected to receive messages from the first entity; and in the case that the user has selected to receive messages from the first entity, the client retrieving the message from the storage means over the communication system and displaying the message to the user on a display means of the terminal.

Description:
RELATED APPLICATION 
       [0001]    This application claims priority under 35 U.S.C. §119 or 365 to Great Britain, Application No. 0702763.4, filed Feb. 13, 2007. The entire teachings of the above application are incorporated herein by reference. 
       TECHNICAL FIELD 
       [0002]    This invention relates to a messaging system and method, particularly but not exclusively for use in a peer-to-peer communication system. 
       BACKGROUND 
       [0003]    The dominant method for communicating a text-based message to a user at the current time is by email. Email is extremely widely used for the transmission of messages between individuals, and it is also used for sending messages from companies and organisations to individuals. Many of the messages sent from companies to individuals are of high importance or contain sensitive information. 
         [0004]    When an email is sent from a sender to a receiver, it is first transmitted from the sender&#39;s terminal to a simple mail transfer protocol (“SMTP”) server. The SMTP server resolves the domain name of the email address to an internet protocol (“IP”) address by contacting a domain name server (“DNS”). The message is then queued for delivery to the IP address, which corresponds to the SMTP server of the recipient. The message is eventually delivered to the SMTP server of the recipient and passed to the recipient&#39;s incoming mail server (usually a Post Office Protocol  3  (“POP3”) or Internet Message Access Protocol (“IMAP”) server) and stored. An email client executed on the recipient&#39;s terminal must then contact the incoming mail server to download the message in order for it to be viewed by the recipient. 
         [0005]    However, there are a number of significant problems with the use of email, particularly in the case of time-critical or sensitive information being sent from a company to an individual. 
         [0006]    The first of these problems is the increasing number of “phishing” attacks. Phishing is the act of attempting to acquire sensitive information (for example credit card or bank details, passwords, etc.) by transmitting seemingly official emails purporting to be from a trustworthy person or business with a real need for such information. This can lure the recipient into replying to these emails and providing the sensitive information to the hoaxer. 
         [0007]    Therefore, phishing attempts to spoof emails from trustworthy sources. More complex forms of spoofing are also possible, whereby spoofers access SMTP servers and send emails that appear to be from an address of a reputable source, but in fact are not. Phishing and spoofing can therefore lead to a lack of trust in the emails that are received from companies, as the user is unsure if they are genuine. 
         [0008]    Another problem with email is spam. Spam is unsolicited emails that are often sent in bulk to a very large number of email addresses. Currently, a very large proportion of email traffic sent over the Internet is spam, and this is increasing all the time. It is very hard to control the spam that is received at a user&#39;s account, and this can lead to considerable dissatisfaction on the part of the user. Spam filters can be used, but these can sometimes result in genuine messages being rejected. There is therefore a problem with email in that it is hard for the users to control what messages are received and from whom. 
         [0009]    Email is also not an end-to-end secure message delivery system. Email messages are generally not encrypted, and are therefore relatively straightforward to intercept and read. Specific software can be used to encrypt email messages, but this is generally inconvenient to the user. This is a particular problem if the email contains sensitive or personal information. Furthermore, the time it takes to deliver a message using email can be very variable. This is because the messages often need to be queued for delivery (particularly in busy email systems), and the email client needs to actively fetch the message from the server. Therefore, when an email is sent, there is no guarantee of how long it will take to reach the recipient. This can be a particular problem when a service needs to notify a user of an event that requires a rapid response. The sheer volume of spam sent over email exacerbates this problem further, as the overloading and consequent queuing of messages is mostly caused by the processing of spam messages rather than genuine messages. 
         [0010]    The sender of an email, such as a company or organisation, may have very little knowledge about the recipient of an email that it is sending. For example, the sender may only be able to deduce some information on the country of the user from the domain of the email address (e.g. the email address “user@example.co.uk” may indicate that the user is based in the United Kingdom). However, many email addresses, such as those with “.com” domains, do not provide the sender with any specific information. This can cause a problem if, for example, the recipient needs to receive the information in a specific language or the information should relate to a particular currency. 
       SUMMARY 
       [0011]    There is therefore a need for a technique to address the aforementioned problems with email and provide a secure, faster and more controllable way of providing text-based messages to a user from trusted sources. 
         [0012]    According to one aspect of the present invention there is provided a method of transmitting a message from a first entity to a terminal of a user over a communication system operated by a second entity, comprising: said second entity authorizing said first entity to access a message transmission means connected to said communication system; said first entity transmitting said message to said message transmission means; said message transmission means generating a notification message from said message and storing said message in a storage means; transmitting said notification message to a client executed on said terminal over said communication system; responsive to receiving said notification message, said client communicating with said storage means to ascertain the identity of the first entity that transmitted the message, and determining whether the user has selected to receive messages from the first entity; and in the case that the user has selected to receive messages from the first entity, said client retrieving said message from said storage means over said communication system and displaying said message to said user on a display means of said terminal. 
         [0013]    According to another aspect of the present invention there is provided a method of transmitting a message from a first entity to a terminal of a user over a communication system operated by a second entity, comprising: said second entity authorizing said first entity to access a message transmission means connected to said communication system; said first entity transmitting said message to said message transmission means; said message transmission means generating a notification message from said message and storing said message in a storage means; transmitting said notification message to a client executed on said terminal over said communication system; responsive to receiving said notification message, said client retrieves said message from said storage means over said communication system; and displaying said message to said user on a display means of said terminal, wherein said message comprises an actuator that causes the terminal to perform an action in response to actuation by the user. 
         [0014]    According to another aspect of the present invention there is provided a system for transmitting a message from a first entity to a terminal of a user over a communication system operated by a second entity, wherein: said second entity comprises means for authorizing said first entity to access a message transmission means connected to said communication system; said first entity comprises means for transmitting said message to said message transmission means; said message transmission means comprises means for generating a notification message from said message, storage means for storing said message, and means for transmitting said notification message to a client executed on said terminal over said communication system; and said client comprises means for communicating with said storage means to ascertain the identity of the first entity that transmitted the message, means for determining whether the user has selected to receive messages from the first entity, means for retrieving said message from said storage means over said communication system in the case that the user has selected to receive messages from the first entity, and means for displaying said message to said user on a display means of said terminal. 
         [0015]    According to another aspect of the present invention there is provided a user terminal connected to a communication system and arranged to receive a message transmitted from a first entity over the communication system, comprising: a display means; and a client executed on said terminal, comprising means for receiving a notification message transmitted by a message transmission means connected to said communication system, means for communicating with a storage means storing said message to ascertain the identity of the first entity that transmitted the message, means for determining whether a user of the user terminal has selected to receive messages from the first entity, means for retrieving said message from a storage means over said communication system in the case that the user has selected to receive messages from the first entity, and means for displaying said message to said user on the display means of said terminal. 
         [0016]    According to another aspect of the present invention there is provided a system for transmitting a message from a first entity to a terminal of a user over a communication system operated by a second entity, wherein: said second entity comprises means for authorizing said first entity to access a message transmission means connected to said communication system; said first entity comprises means for transmitting said message to said message transmission means; said message transmission means comprises means for generating a notification message from said message, storage means for storing said message, and means for transmitting said notification message to a client executed on said terminal over said communication system; and said client comprises means for retrieving said message from said storage means over said communication system responsive to receiving said notification message, and means for displaying said message to said user on a display means of said terminal, wherein said message comprises an actuator that causes the terminal to perform an action in response to actuation by the user. 
         [0017]    According to another aspect of the present invention there is provided a user terminal connected to a communication system and arranged to receive a message transmitted from a first entity over the communication system, comprising: a client executed on said terminal, comprising means for receiving a notification message transmitted by a message transmission means connected to said communication system, and means for retrieving said message from a storage means over said communication system responsive to receiving said notification message; and display means for displaying said message to said user, wherein said message comprises an actuator that causes the terminal to perform an action in response to actuation by the user. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0018]    For a better understanding of the present invention and to show how the same may be put into effect, reference will now be made, by way of example, to the following drawings in which: 
           [0019]      FIG. 1  shows a system for providing messages to a user over a peer-to-peer network; 
           [0020]      FIG. 2  shows a flowchart for the operation of the system in  FIG. 1 ; 
           [0021]      FIG. 3  shows user options for the operation of a peer-to-peer client; 
           [0022]      FIG. 4  shows a pop-up alert window for a message from an auction website; 
           [0023]      FIG. 5  shows a message from an auction website listed in an event panel of the user interface of a peer-to-peer client; 
           [0024]      FIG. 6  shows a large message window for a message from an auction website; 
           [0025]      FIG. 7  shows a small message window for a message from an auction website; 
           [0026]      FIG. 8  shows a message from an auction website listed in a history tab of the user interface of a peer-to-peer client; 
           [0027]      FIG. 9  shows a pop-up alert window for a message from an account system; 
           [0028]      FIG. 10  shows a message from an account system listed in an event panel of the user interface of a peer-to-peer client; 
           [0029]      FIG. 11  shows a message window for a message from an account system; 
           [0030]      FIG. 12  shows a message from an account system listed in a history tab of the user interface of a peer-to-peer client. 
       
    
    
     DETAILED DESCRIPTION 
       [0031]    Reference is first made to  FIG. 1 , which illustrates a system for providing messages to a recipient user from a sender. The system operates using a peer-to-peer (“P2P”) network topology built on proprietary protocols. In particular, the system shares infrastructure with a P2P communication system. An example of this type of communication system is the Skype™ system. To use a peer-to-peer service, the user must install and execute client software on their user terminal. The client software is provided with a digital certificate from a central server. Once the client software has been provided with the certificate communication can subsequently be set up and routed between users of the P2P without the further use of a central server. In particular, the users can establish their own communication routes through the P2P system based on exchange of one or more digital certificates (or user identity certificates, “UIC”) to acquire access to the P2P system. The exchange of the digital certificates between users provides proof of the user&#39;s identities and that they are suitably authorised and authenticated in the P2P system. Therefore, the presentation of digital certificates provides “trust” in the identity of the user. The client software provides voice over IP (“VoIP”) and instant messaging (“IM”) connections. It is therefore a characteristic of peer-to-peer communication that the communication is not routed using the central server but directly from end-user to end-user. Further details on such a P2P system are disclosed in WO 2005/009019. 
         [0032]      FIG. 1  illustrates three “domains” in the system. The first is the user domain  102  comprising the user  104  and a user terminal  106  operated by the user  104 . The user terminal  106  executes client software  108  provided by the operator of the P2P network. The client  108  is used to provide VoIP calls and IM communication, and also for the delivery of messages. The user terminal  106  is connected to the P2P network  110 . Note that a large number of users may be present in the system, but only one is shown in  FIG. 1  for clarity. The second domain is the P2P backend domain  112 . The P2P backend domain  112  comprises servers and nodes, operated by the operator of the P2P network, that enable the message delivery system, as described hereinafter. The P2P backend domain  112  may therefore be referred to as the message transmission system. The third domain is the partner domain  114 . This domain comprises a terminal  116  operated by the sender of a message destined for the user  104 . The sender of the message is known to the operator of the P2P system and trusted, and hence is referred to hereinafter as a partner  118 . Note that several partners may be present that can transmit messages to users, but only one is shown in  FIG. 1  for clarity. 
         [0033]    The operation of the system shown in  FIG. 1  is illustrated with reference to the flowchart of  FIG. 2 . To begin the process of transmitting a message to user  104 , the partner  118  uses terminal  116  to access profile data for the user in question. This is achieved by the partner accessing the data via a profile data application programming interface (“API”)  120  provided by the P2P network operator. Access to this API is via a secure interface. The secure interface ensures that only authorised partners can gain access to this information. The interface can be secured, for example, by the P2P network operator providing an authentication certificate to the trusted partner, which must be presented to the API when access is required. Access to the API may also only be permitted from terminals with specific IP addresses, which the partner has provided to the P2P network operator in advance. 
         [0034]    The profile data can comprise information about the recipient that permits the partner to provide a greater degree of personalization to the message than would otherwise be possible. For example, the profile data may include the preferred language of the user  104  or the appropriate currency for the country of the user  104 . The profile data may also indicate whether or not the user has chosen to receive messages from this particular partner. Furthermore, the profile data may provide information on the version of the client software  108  executed on the user terminal  106 , and in particular whether this version is able to receive the message. Profile data may further include information on the current presence state of the user  104 , for example whether the use is online, offline, busy or unavailable. 
         [0035]    In a preferred embodiment, the profile data API  120  is accessed using the simple object access protocol (“SOAP”), which is a standard for exchanging messages over the World Wide Web. The profile data API  120  obtains the profile data information from a P2P SOAP gateway (“GW”)  121 , which provides an interface between the profile data API  120  and the P2P network  110 , where the data is held distributed among the peers that make up the P2P network. The profile data is “live” in the sense that it corresponds to the state of the user at the time the information is accessed. This provides an important advantage over other messaging systems, as the information about the user is never out of date. In alternative embodiments, a different protocol to SOAP can be used, such as the lightweight directory access protocol (“LDAP”). 
         [0036]    Referring to  FIG. 2 , the step of obtaining the profile data from the P2P network is shown in S 202 . Note that, for some applications, the accessing of profile data may not be required. For example, some partners may not require any information about the preferences of the user or his current state in order to prepare the message. This may depend on the content of the message being sent. 
         [0037]    If the profile information indicates that the user can receive the message (e.g. the user terminal  106  is executing the correct version of the client software  108  and has not declined to receive messages from this partner  118 ) then, in step S 204 , the partner  118  prepares the content of the message. The content can be tailored according to the profile data, for example it can be in a particular language or display a particular currency. 
         [0038]    The message is then transmitted from the terminal  116  of the partner  118  to the backend domain  112  of the P2P system in step S 206 . This is achieved by transmitting the message using an alerts API  122 . The alerts API  122  is a SOAP API (like the profile data API  120 ) and provides an interface for the message to be provided to the backend domain. As with the profile data, the interface is a secure interface protected by, for example, authentication certificates and fixed IP addresses. This prevents messages being sent from sources that are not trusted by the operator of the P2P network. 
         [0039]    From the alerts API  124 , the message is sent to a queue database (“DB”)  124 . The queue DB  124  stores the message until it is ready to be processed. In preferred embodiments, the queue DB is a first in, first out (“FIFO”) queue, wherein the messages from multiple partners are outputted from the queue in the order in which they arrive. In alternative embodiments, priorities may be allocated to the messages, such that those with higher priorities are outputted from the queue first. The queuing of messages is shown in step S 208 . 
         [0040]    In step S 210 , the message from the queue DB  124  is processed. The processing is performed by a processing node  126 . The processing node  126  performs several functions with the message. The processing node  126  generates a notification message, and this is transmitted (i.e. “pushed”) to the client  108  executed on the user terminal  106  over the P2P network  110 , as shown in step S 212 . In parallel with this, the message is also transmitted from the processing node  126  to an event DB  128  (where it is stored until it is to be delivered to the user  104 ) as shown in step S 214 . 
         [0041]    The notification message pushed to the client  108  notifies the client that a message is waiting to be delivered. If the user  104  is not online, then the notification message cannot be provided to the client  108 . In this instance, the notification message is stored, and delivered to the client  108  when the user  104  reconnects to the P2P network  110  and comes online. The notification message is stored in a P2P database (not shown in  FIG. 1 ) which is located within the P2P network  110 , such that the data stored in the database is distributed amongst the peers that make up the P2P network  110 . However, a time limit may be set for the message by the partner, such that if the notification message is not delivered to the client  108  within a fixed time period, the message stored in the event DB  128  is not delivered to the user. This is achieved by the client  108  performing a check before downloading the message from the event DB  128  (described in more detail below) in case the user has been delivered the notification message from the P2P database, but the time limit has already expired by the time the process to fetch the message is started. The use of a time limit allows time-critical messages to be sent, which need to be reacted to within a particular time-frame to be relevant, such that the user will not be exposed to out-of-date messages that have already passed the relevant time-frame. 
         [0042]    In addition to the notification message being pushed to the client  108 , the client may also actively check with the processing node  126  whether there are any notification messages. In particular, this may occur immediately after the client  108  is executed on the terminal  106 , or when the user  104  logs in to the P2P network  110 . 
         [0043]    Upon receiving a notification message, the client  108  knows that there is a message waiting to be delivered for the user. The client  108  then connects to the event DB  128  (where the message was stored in step S 214 ) over the P2P network  110 , and accesses some information on the waiting message (S 216 ). In particular, in step S 218 , the client  108  checks the identity of the partner that has sent the message and compares this to a list of partners that the user has indicated that he is willing to accept messages from (discussed in more detail with reference to  FIG. 3 , below). If the partner is not in this list, then the message is rejected. This is recorded as a “rejected” status in the event DB (in step S 220 ), which is reported to the partner in step S 222  (described in more detail below). The message is not downloaded to the user terminal, and the message delivery process ceases in step S 224 . If the user is accepting messages from this partner, then the client also checks (in step S 226 ) whether the message in the event DB  128  has a time limit set which has expired. If a time limit has expired the message is not downloaded and the process terminates. However, if the above checks both indicate to the client  108  that the message is from an approved partner and has not expired (or there is no time limit), then in step S 228  the client  108  downloads the message to the user terminal  106 . The event DB  128  logs the updated information on the status of the message. In particular, in step S 230 , the status is updated to “delivered” when the message is fetched, and it can store information such as the time that it was fetched by the client  108 . The updated status is reported to the partner in step S 232  as described in more detail below. 
         [0044]    Once the message has been downloaded to the user terminal  106 , the message can be displayed to the user  104  using the client  108  (shown in step S 234 ). This is described in more detail hereinafter. 
         [0045]    As mentioned above, the status of the message also in the event DB  128  is reported to the partner  118  (e.g. in step S 222  and S 232 ). The status of the message is reported to the partner  118  by a delivery report node  130  (shown in  FIG. 1 ). The delivery report node periodically queries the event DB  128  in order to determine the status of a message. Upon detecting a change in the status of the message the delivery report node  130  transmits a reporting message to terminal  116  to notify the partner of the updated status. For example, the reporting message can notify the partner that a particular message has been delivered to the client  108  at a particular time. In alternative embodiments, the delivery report node  130  can provide a status report to the partner  118  every time it checks the status at the event DB  128 , instead of only reporting when there is a change in status. 
         [0046]    Several possible status states exist for a message, and these are maintained and stored at the event DB  128 . In preferred embodiments, a delivery report sent to the partner  118  will give a status for a message of either “delivered”, “expired”, “error” or “rejected”. A “delivered” status indicates that the message has been fetched by the client  108  and delivered. This may also be stored with a timestamp of the delivery time. An “expired” status indicates that a message had a time-limit associated with it, and the message was not delivered within this time. This status therefore indicates to the partner  118  that the message was not delivered to the user  104  due to the expiry of the time-limit. An “error” status indicates that the message was not delivered due to an error or failure in the system. A “rejected” status indicates to the partner  118  that the user did not download the message because the user&#39;s preferences were set such that he had chosen not to receive messages from this partner (discussed in more detail with reference to  FIG. 3 , below). 
         [0047]    The above-described system has several advantageous features. The message sent to the user  104  is delivered very quickly to the user, if the user is online when the message is sent. This is due to the controllable nature of the messaging system, whereby only specific partners can send messages. This permits control over the load of the system, and allows the nodes such as the queue DB  124  and processing node  126  to be managed such that they are not overloaded, which reduces transmission delay. In particular, the controllable nature of the messaging system ensures that spam is not being sent, thereby eliminating this source of message congestion. Furthermore, the part of the system that uses the P2P network  110  scales reliably, regardless of the number of users in the system, which means that the delivery of messages over the P2P network  110  does not become a bottleneck in the system. Specifically, the absence of central servers required to send the messages across the P2P network  110  means that the messages sent from the backend domain  112  to the user domain  102  over the P2P network  110  can be rapidly delivered even if a large number of users are present. 
         [0048]    The above-described system is also end-to-end secure. The messages sent between the partner and the alerts API  122  and profile data API  120  are encrypted with public/private key encryption. Every message transmitted over the P2P network  110  is also fully encrypted. The messages also cannot be spoofed, as only trusted partners have access to the secure interface to the profile data API  120  and alerts API  122 . The users can therefore trust the messages they receive, as they cannot be phishing attacks. 
         [0049]    The messaging system also provides reliable delivery information back to the partner. Delivery information in a known email system is unreliable, as delivery notifications are often either not sent back to the sender by the email client (as they can be overridden by the user), or an email server may indicate that a message has been received even though the email client of the end user has not received the message, thereby giving a false indication of delivery. The message delivery system of  FIG. 1  does not have this problem, as the delivery notification cannot be overridden by the user, as it is determined though querying the event DB  128 , and the status is not updated until the client  108  actually fetches the message. 
         [0050]    Reference is now made to  FIG. 3 , which shows a screenshot of user options for the operation of the client  108 . Region  302  shows several categories of user options, of which the category “notifications”  304  has been selected. Region  306  shows several notification options that are unrelated to the messaging system in question and are not considered further here. Region  308  of the screenshot of  FIG. 3  shows the options related to the message delivery. In particular, list box  310  shows a list of partners that have been authorised by the operator of the P2P network to send messages to users. For example, two example partners of “Skype account manager”  312  and “eBay”  314  are shown illustrated in  FIG. 3 . The user  104  of the client  108  can use check boxes  315  next to the names of the partners to select or deselect the receipt of messages from the listed partners. More than two partners may be listed in box  310 , and these can be viewed using the scrollbar  316 . 
         [0051]    The options in region  308  of  FIG. 3  are important as they provide control to the end user  104  of the messages that are received. Therefore, the user  104  can readily prevent messages from being received from certain partners, whilst allowing messages to be received from others. This is in contrast to the case of email, where the user has little control over who messages are received from. If a user has deselected a partner from the list  310 , then this is reflected in the user&#39;s profile data, and is therefore communicated to the partner (in step S 202  of  FIG. 2 ). This indicates to the partner that a message should not be sent to this user. Even if a message is sent to this user from this partner (for example by the partner ignoring or not accessing the profile data, or the user changing his preferences to deselect a partner in the intervening period between a message being sent by the partner and the notification being received at the user terminal), the client  108  would detect (in step S 218 ) that the user did not wish to receive messages from this partner, and would reject the message before the message is downloaded to the user terminal. The status associated with the message in the event DB  128  is then set to “rejected”, as mentioned above. This ensures that the user  104  never receives messages from a partner he has deselected in list  310 . 
         [0052]    In further embodiments, an additional check of the list of partners  310  is also made by the client  108  after the message has been downloaded to the user terminal, but before the message is actually shown to the user  104  on a display of the user terminal  106 . This extra check is useful in the case that a user has selected to receive messages from a particular partner that has sent a message, and the client has already performed the check in step S 218 , but the user then subsequently deselects the partner from the list  310  in the intervening period between the check in step S 218  and the message being displayed to the user. If the client did not perform the extra check, then the user would be displayed the message, even though he had deselected the partner. The extra check after the message has been downloaded ensures that this cannot occur. 
         [0053]    Reference is now made to  FIGS. 4 to 12 , which illustrate the user interfaces of the client  108  that are shown to the user  104  when a message is delivered.  FIGS. 4 to 8  show an exemplary application of the messaging system wherein the partner is the operator of an auction website in which the user  104  is bidding for an item. Specifically, the auction website partner transmits a message to the user when the user has been outbid on an item. This type of application leverages the advantageous features of the messaging system, particularly the rapid delivery of the message, as the message needs to be reacted to within a certain period of time due to the real-time nature of the auction. Furthermore, the secure nature of the system ensures that third parties cannot intercept the messages and determine what the user is purchasing. The user  104  has trust in the messages received, as he is aware that they cannot be spoofed, and only trusted partners of the P2P network operator are allowed to transmit messages. 
         [0054]      FIG. 4  shows the user interface presented to the user  104  on the terminal  106  when a message is downloaded by the client  108  (step S 228  in  FIG. 2 ). The user interface in  FIG. 4  is a pop-up alert  402  that appears from the system tray  404  of the operating system of terminal  106  (this is also known as a “toast” window). The pop-up alert  402  comprises a main window  406  in which is shown a caption  408  for the message and also some more detailed information on the message, such as a title  410  and subject  412 . The pop-up alert also has a header bar  414  comprising a logo for the partner  416  and the P2P network operator  418 , which allows the user to rapidly identify the source of the message. 
         [0055]    If the user  104  has used the client  108  to log in to the P2P network  110 , but has set his presence state (in the client  108 ) to “busy” or “do not disturb” (as opposed to “online” or “available”), then the pop-alert is not displayed to the user when a message is fetched. Instead, the message is simply shown as an event in the client window, as will be described below with reference to  FIG. 5 . 
         [0056]      FIG. 5  shows a portion of the user interface of the client  108 , after a message has been fetched. The P2P network username  502  of the user  104  is shown in the client, and the current presence state of the user  104  is indicated by icon  504 . The client  108  displays a list of contacts  506  that the user has stored in the client, and VoIP or IM communication can be established with these contacts by selecting them. The presence state for each of the contacts is shown as an icon next to their name, for example as shown in icon  508 . 
         [0057]    When certain communication events occur, the client displays an event panel  510  to alert the user to these events. Example communication events include missed calls, voicemail messages and missed IM chats. An example of two IM chat events is shown at  512 . The event panel is also used to indicate to the user that there is a message from a partner waiting to be read. The entry in the event panel for the message displays similar information to the pop-up alert in  FIG. 4 , i.e. a caption  514 , a subject  516  and a partner icon  518 . The message is shown in the event panel following the display of the pop-up alert (as shown in  FIG. 4 ) if the user is online, or, if the user has his presence set to “do not disturb”, the message is shown in the event panel immediately, without displaying a pop-up alert. 
         [0058]    The subject  516  of the message shown in the events panel  510  is a hyperlink that can be clicked by the user, and when this is done the full message is displayed to the user, as illustrated in  FIGS. 6 and 7 .  FIG. 6  illustrates a first embodiment of the full message window, and  FIG. 7  illustrates an alternative embodiment of the full message window. 
         [0059]    Referring first to  FIG. 6 , this shows a large version of the full message window  600  that is displayed to the user  104  when he clicks on the link in the event panel. The large message window  600  comprises a caption  602 , a title  604 , a subject  606 , a text portion  608  containing the main body of the message, and a footer  610 . The contents of all of these sections are determined by the partner  118  when preparing the message, and various aspects of the content (e.g. the language used) is determined by the profile data obtained as the first step in the message sending process. 
         [0060]    The message window  600  shown in  FIG. 6  also comprises three buttons. The first button is a “decide later” button  612 . If this button is activated by the user, then the message window is closed, but the message notification remains in the events panel shown in  FIG. 5 . Therefore, this button allows the user to close the message window without taking any action in response to it, and it will still be clearly visible to the user in the events panel for when the user does decide to act upon the message. The inclusion of this button in the message is optional, and whether or not the partner chooses to include it depends on the content and type of the message. 
         [0061]    The second button is an “action” button  614 . In the example shown in  FIG. 6 , the action button  614  is labelled “go to online auction”. In this example, when the user activates the button a web-browser program is executed, which displays to the user the relevant webpage of the auction website to which the message relates. This is achieved by associating the action button  614  with a hyperlink comprising the webpage address (e.g. a uniform resource identifier, “URI”) in the message. This allows the user to take action in response to the message, for example placing a higher bid in the auction in response to being outbid. After the action button  614  is activated, the message window  600  is closed, and the message notification in the events panel in  FIG. 5  is removed. The message is not deleted however, but is stored and remains accessible from the client, as discussed with reference to  FIG. 8 . The function (and label) of the action button  614  is determined by the partner creating the message, and the action taken is related to the content of the message. Apart from being taken to a webpage, other actions are also possible, such as initiating a call over the VoIP network or making a call to a public switched telephone network (“PSTN”) number. These alternative actions are considered hereinafter in more detail with reference to other applications of the messaging system. 
         [0062]    The third button is a “cancel” button  616 . If this button is activated by the user, the message window  600  is closed without any further actions being taken, and the message notification in the events panel in  FIG. 5  is removed. The message is not deleted however, but is stored and remains accessible from the client, as discussed with reference to  FIG. 8 . 
         [0063]      FIG. 7  illustrates an alternative, more compact form of the full message window  700 , which can be used by partner instead of the message window in  FIG. 6  if there is a smaller amount of information to be sent in the message. The small message window  700  comprises a caption  702 , title  704 , subject  706  and text  708 , in common with the larger message window shown in  FIG. 6 . The small message window  700  also comprises the same three buttons ( 710 ,  712 ,  714 ) as in the larger message window shown in  FIG. 6 . 
         [0064]    Reference is now made to  FIG. 8 , which illustrates a portion of the user interface of the client  108 , after either the action button ( 614  or  712 ) or cancel button ( 616  or  714 ) has been activated. The event panel  510  is still present, and this still shows the two example chat events  512 . However, the message notification is now longer shown in the events panel  510 , as the user has viewed and acted on (or cancelled) the message. The message can still be viewed however by the user accessing a “history” tab  802  in the client  108 . The history tab  802  displays previous events such as past calls and IM conversations that were made using the client. The message from the auction website partner can seen listed in the history tab  802  with a subject  804  and a timestamp of its delivery  806 . This allows the user to access and re-read the message even after it has been acted on or cancelled. 
         [0065]      FIGS. 9 to 12  show a second exemplary application of the messaging system, wherein the messages relate to the management of the user&#39;s account in the P2P communication system. The partner in this example is therefore the same as the P2P network operator. Specifically, in this example, the user has completed a payment into his account, but due to a problem (e.g. the payment was rejected by the credit card provider) the payment has been cancelled, and a message is sent to notify the user. The messaging system is advantageous in this application because it is secure and not spoofable, and the message relates to sensitive information (i.e. payments). Therefore, the user can trust the messages as being genuine. Furthermore, the rapid delivery of the message allows the user to quickly rectify the problem without significant delay. 
         [0066]      FIG. 9  shows a pop-up alert  902  similar to that shown in  FIG. 4 , except in this instance the caption  904  and title  906  relate to payments, and the icon  908  indicates that the partner is the payment system of the P2P network operator. The operation is otherwise identical to that described above with reference to  FIG. 4 . 
         [0067]      FIG. 10  shows a portion of the client  108  user interface, similar to that shown in  FIG. 5 . As with  FIG. 5 , the message notification is shown in the event panel  510 , with a caption  1002 , hyperlinked title  1004  and icon  1006 . When the user clicks on the title  1004 , he is displayed the message window  1100  shown in  FIG. 11 . As with the message window  600  shown in  FIG. 6 , this comprises a caption  1102 , title  1104  and message text  1106 . In this example the partner has chosen not to include other optional items such as a subject line and footer. The message window  1100  also comprises an action button  1108  labelled “get more details”, and when this is activated by the user he is displayed a webpage that outlines the reasons for the payment refusal and suggestions for how to correct this or make alternate purchases. The webpage may be displayed in a web-browser executed on the user terminal in response to the activation of the action button  1108 , or alternatively in a window of the client  108 . In alternative embodiments, activation of the action button  1108  can cause the client to make a voice call to an operator. This is achieved by associating the action button with a hyperlink that is recognised by the client (e.g. a URI of the type “callto:// . . . ”), and causes the client to initiate voice communication with a calling identifier (such as a P2P network identity or a PSTN number) embedded in the hyperlink. A cancel button  1110  is also present, which operates in the same way as described above with reference to  FIG. 6 . Note that in this example the partner has chosen not to include a “decide later” button. 
         [0068]    After the action button  1108  or cancel button  1110  has been activated, the message notification is removed from the event panel  510 , as shown in  FIG. 12 , and is now shown in the history tab  802 . The title of the message  1202  is shown, along with a timestamp  1204  of its delivery time. 
         [0069]    A further application of the messaging system is for the delivery of reminders of an event to a user. A specific example of this is a reminder for the user to join a Skypecast. A Skypecast is a large-scale VoIP voice conference that is hosted over the P2P network. More details on Skypecasts can be found in GB0608595.5. A user can browse a list of up-coming Skypecasts, and request to be reminded when a particular Skypecast is about to begin. At the start time of the Skypecast the P2P operator sends a message to the user using the message delivery system, and similar messages are displayed as described above with reference to  FIGS. 4 to 12 . The action button displayed in the main message window comprises a hyperlink containing the calling identifier for the Skypecast, and will cause the client to connect to the Skypecast in question, thereby starting a VoIP call with the other participants of the Skypecast. 
         [0070]    The sending of reminders is particularly suited to this type of messaging system as the messages are sent very rapidly to the user. This is useful as the messages relate to an event (e.g. the beginning of a Skypecast) that is happening in real-time, and must therefore be acted upon within a certain timeframe. Furthermore, it is also advantageous that the messaging system can associate a lifespan with a message, after which it is discarded if the user is not online and has not received the message. This is useful for reminders if they relate to time-limited events, as there is no point delivering a reminder relating to an event that has already finished. 
         [0071]    Another further application of the messaging system is for the delivery of information in response to a request from a user. A specific example of this is a telephone directory enquiry service. A user may wish to find out the telephone number of a company or organisation (e.g. the telephone number of a restaurant), and to do this he uses the client  108  to call a directory service using the VoIP P2P network. The user speaks to an operator and requests the number. In known systems, the operator would simply read the number to the user, and the user would need to write down the number separately, or alternatively the operator would redirect the call directly to the requested number. This has the disadvantages that the user must have means for writing the number down immediately to hand, or if the call is redirected the user does not have a record of the number for the next time he wishes to call it. 
         [0072]    These disadvantages can be avoided by the operator of the directory service sending the information directly to the user in a message using the messaging system described above. The user is displayed similar messages as described above with reference to  FIGS. 4 to 12 . In particular, the text portion of the main message window (as in  FIGS. 6 and 11 ) contains the telephone number requested by the user, and the action button causes the client  108  to call the telephone number in question directly (i.e. the action button has an embedded “callto:” hyperlink containing the telephone number), without the user needing to type in any information. As the message is stored in the history tab  802 , the user can gain access to the information again at a later date. Alternatively, the action button in the message window can cause the telephone number requested to be added as a contact in the contact list  506  of the client  108 . The messaging system described herein is also useful for supplying information in response to a request from a user as the messages are delivered very rapidly to the user, which is important as the user would expect an immediate response to their query. 
         [0073]    Note that the information sent to the user from the directory service is not limited to a telephone number. The information can be a P2P network identity (in which case the action button can initiate a call to the P2P ID using VoIP or initiate an IM conversation), an email address (in which case the action button causes the execution of an email client with the address pre-entered in an email), a short message service (“SMS”) number (in which case the action button opens a window in the client for the sending of an SMS), or any other type of contact information. 
         [0074]    While this invention has been particularly shown and described with reference to preferred embodiments, it will be understood to those skilled in the art that various changes in form and detail may be made without departing from the scope of the invention as defined by the appendant claims.