Browse Prior Art Database

System for Remote Message Expiry/Rendering as Applied to Existing Instant Messaging Environments Disclosure Number: IPCOM000129860D
Original Publication Date: 2005-Oct-07
Included in the Prior Art Database: 2005-Oct-07
Document File: 4 page(s) / 1M

Publishing Venue



Instant Messaging (IM) has emerged as a less formal communication mechanism than previous technologies, such as email. As a consequence of its informality it can be used as a means of conveying information that may be considered in some way dangerous or sensitive. A user would often be reluctant to send this information in a more permanent form such as email, voicemail or letter. Due to the "alert" nature of IM, messages pop up on the screen without any user control. On the other hand, an email resides in a user's inbox until they decide upon an appropriate time to read it. A user sending an IM message can never be sure that the recipient they are intending the message for is actually at the destination machine or whether there is anyone else looking at the screen at that time, etc. Thus, a message could potentially be viewable on a display screen by any other user. Similarly, as IM clients typically keep a history of the chat transcript for a given session (viewable by user scrolling) a comment could be available on the display screen for a long period of time. The longer a message is available on the display screen, the more opportunity there is for it to be viewed by someone other than the intended recipient. This article describes an IM client that can be used in an existing IM environment in which messages can be expired remotely. The same technology can be used in order to render in the destination GUI a sensitive message differently than a standard, non-sensitive message. Expiry control/rendering is defined by the application of user mark-up to a section of text.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 4

System for Remote Message Expiry /Rendering as Applied to Existing Instant Messaging Environments


IM networks provide APIs in order that custom clients can be developed to work in the IM environments. This article describes a means of enabling an IM client for remote message expiry/rendering without modification to the underlying IM infrastructure. This will allow a client implemented in such way to function over existing IM networks.

A user may wish to send an IM message which they consider to be:
a) sensitive
b) of a time dependent nature.

    The user uses markup in an IM chat window to indicate that a section of a message satisfied conditions a and/or b and should be rendered differently in the destination IM window. The markup can describe a timeout period for which the text would remain on screen or that the destination IM client should handle the section of text differently, such as using an additional privacy function (see additional uses section).


    The system is best explained through the use of the following example in which the source user (Darren) is sending the message to the target user (Jessica).

    The source user enters a message into the IM chat window and reaches a sensitive bit of text. The user wants to limit the length of time that the sensitive text will remain on the target user's screen (e.g. because he's sending a password). This is in order to limit the possible exposure of the message to other parties. To do this, the user encloses the sensitive text with the tag <sensitive> . The attribute t is used to indicate how long the message should appear on the target user's screen (as shown in below and in figure 1).

Text Entered:

    "hi jessica, can you reset my password to <sensitive t="60">j4ckson</sensitive> please?"

Page 2 of 4

figure1 figure1

The target user uses an adapted IM client capable of interpreting <sensitive> tags. The IM client removes the mark-up from the GUI but notes the time when the message was received and the t attribute associated with it (figure 2).

figure 2 figure 2

After ti...