Browse Prior Art Database

System and Method of Message Thread Compression in a Client-Server Environment

IP.com Disclosure Number: IPCOM000130504D
Publication Date: 2005-Oct-25
Document File: 1 page(s) / 26K

Publishing Venue

The IP.com Prior Art Database

Abstract

Currently, if a user is participating in a long message thread, there is much duplicate information sent between the device and the server. For each message in the thread, there is the potential for the entire thread up to that point to be sent. Sending only the first part of the message reduces the amount of data that typically gets sent, because once the user has some context, there is no need to request more of the message. However, the first chunk of a message sent to the user often includes part of a previous message that is already stored on the user's device, so bandwidth is wasted. Similarly, if the user requests more of the message to obtain more context, data that is already on the device will be sent to the device again. It would be nice to eliminate this duplication in the data that is sent over the air. The server already has a good idea of what messages are stored on the device, thanks to the over-the-air email reconciliation functionality. When the server receives a message for a user, it can heuristically determine if this message is a reply to a previous message by scanning the current message for "-----Original Message-----" or a similar string. If the server determines that the current message is a reply to a previous message, it can extract the text of the previous message from the current message, and then enumerate through the messages in the user's message store, looking for a message that matches the previous message. If it locates the previous message, it can determine whether the user already has the previous message on the device, and if so, remove the previous message data and replace it with a unique identifier known to both the server and the device. The data sent to the device will then include the text of the current message (not including the original message to which the current message is a reply) and this unique identifier. When the message reaches the device, it can look up the corresponding original message based on the provided unique identifier and then render the complete current message. If the server is unable to locate the previous message, it can proceed as it currently does and send the complete current message to the device. If the device is unable to locate the previous message corresponding to the provided unique ID, it can provide the user with the option to request more of the current message, at which point the server will not re-attempt the optimization, i.e, the replacing of the previous message with its unique identifier.

This text was extracted from a Microsoft Word document.
This is the abbreviated version, containing approximately 57% of the total text.

MESSAGE THREA COMPRESSION ON THE SERVER

System and Method of Message Thread Compression in a Client-Server Environment

Disclosed Anonymously

Currently, if a user is participating in a long message thread, there is much duplicate information sent between the device and the server. For each message in the thread, there is the potential for the entire thread up to that point to be sent. Sending only the first part of the message reduces the amount of data that typically gets sent, because once the user has some context, there is no need to request more of the message. However, the first chunk of a message sent to the user often includes part of a previous message that is already stored on the user's device, so bandwidth is wasted.  Similarly, if the user requests more of the message to obtain more context, data that is already on the device will be sent to the device again. It would be nice to eliminate this duplication in the data that is sent over the air.

The server already has a good idea of what messages are stored on the device, thanks to the over-the-air email reconciliation functionality. When the server receives a message for a user, it can heuristically determine if this message is a reply to a previous message by scanning the current message for "-----Original Message-----" or a similar string.  If the server determines that the current message is a reply to a previous message, it can extract the text of the previous message from the current message, and then enume...