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.
This invention relates to a messaging system and method, particularly but not exclusively for use in a peer-to-peer communication system.
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.
When an email is sent from a sender to a receiver, it is first transmitted from the sender'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'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's terminal must then contact the incoming mail server to download the message in order for it to be viewed by the recipient.
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.
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.
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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
Reference is first made to
The operation of the system shown in
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.
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”).
Referring to
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 S204, 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.
The message is then transmitted from the terminal 116 of the partner 118 to the backend domain 112 of the P2P system in step S206. 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.
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 S208.
In step S210, 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 S212. 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 S214.
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
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.
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 S214) over the P2P network 110, and accesses some information on the waiting message (S216). In particular, in step S218, 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
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 S234). This is described in more detail hereinafter.
As mentioned above, the status of the message also in the event DB 128 is reported to the partner 118 (e.g. in step S222 and S232). The status of the message is reported to the partner 118 by a delivery report node 130 (shown in
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's preferences were set such that he had chosen not to receive messages from this partner (discussed in more detail with reference to
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.
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.
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
Reference is now made to
The options in region 308 of
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 S218, but the user then subsequently deselects the partner from the list 310 in the intervening period between the check in step S218 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.
Reference is now made to
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
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
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
Referring first to
The message window 600 shown in
The second button is an “action” button 614. In the example shown in
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
Reference is now made to
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
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
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.
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.
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
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.
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.
Number | Date | Country | Kind |
---|---|---|---|
0702763.4 | Feb 2007 | GB | national |