Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Improved message delivery system for multiply connected messaging systems

IP.com Disclosure Number: IPCOM000145156D
Original Publication Date: 2007-Jan-09
Included in the Prior Art Database: 2007-Jan-09
Document File: 2 page(s) / 61K

Publishing Venue



This article details a system for improved message delivery with a system that allows a user to be connected from multiple locations. By monitoring the activity of a user, the system is able to identify where a message should be sent, rather than sending it to all potential locations. This reduces the bandwidth required and can be the basis for an improved user experience.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Improved message delivery system for multiply connected messaging systems

Some messaging systems/protocols allow a single user to be signed into the system from multiple locations. For example, the XMPP protocol which backs both GTalk and Jabber uses the convention of 'user@domain/resource'. In this case 'user@domain' identifies the 'who' and 'resource' identifies the 'where'.

    The problem with a system that allows multiple sign-on is how the system determines where to route messages for a particular user.

    Section 11.1 of the XMPP Instant Messaging and Presence specification ( http://www.xmpp.org/specs/rfc3921.html#rules) describes how XMPP does it:

# For message stanzas, the server SHOULD deliver the stanza to the highest-priority available resource (if the resource did not provide a value for the <priority/> element, the server SHOULD consider it to have provided a value of zero).

If two or more available resources have the same priority, the server MAY use some other rule (e.g., most recent connect time, most recent activity time, or highest availability as determined by some hierarchy of <show/> values) to choose between them or MAY deliver the message to all such resources.

However, the server MUST NOT deliver the stanza to an available resource with a negative priority; if the only available resource has a negative priority, the server SHOULD handle the message as if there were no available resources (defined below). In addition, the server MUST NOT rewrite the 'to' attribute (i.e., it MUST leave it as <user@domain> rather than change it to <user@domain/resource>).

    This highlights a problem with the XMPP solution. It does not know for sure where a user is at any one time. A user may be active at one location so messages are routed there, but if they move to another location, any messages sent in the meantime will be routed to the first location so the user will not receive them until they return.

    A naive view would be to send messages to a user at all of the locations they are connected from. However this has the serious drawbacks of:
1) increasing the bandwidth usage of the messaging system,
2) cluttering up each location so a user has to 'clean-up' the messages they have already dealt with elsewhere. XMPP suffers from this when messages are sent to all locations.
(As an aside, whilst bandwidth is getting cheaper so isn't considered the same bottleneck it was, there are some applications where bandwidth is still costly - such as on mobile phones)

    This invention is for a improved method of sending messages to a user signed-on from multiple locations.

By keeping track of the messages sent to and received by a user, as well as the locati...