Sender managed transient messages.
Original Publication Date: 2009-Mar-23
Included in the Prior Art Database: 2009-Mar-23
When messages are exchanged between a sender and a receiver, right now there is no way for the sender to mark some of the messages as short lived. For example, consider the following scenarios : - automated messages indicating for example server up and down times which are not valid beyond the specified times. - FYI messages which have no action points for the receiver generally when mailed to a group. - exchanging sensitive information like passwords over instant messaging sessions. These scenarios are applicable to a variety of business usecases like e-mail, instant messaging, SMS , voice messages to name a few. The following are the claims of the disclosure : 1. Sender can mark any message being sent out as transient so that it can be destroyed at the receiver's end automatically. 2. This marking could be as simple as a checkbox in the UI, a right click menu option or a rule. 3. The actual life span of the transient message at the receiver's end could be based on several criteria. Some of them are : - time bound where the message is deleted after 'n' time units. - trigger based like reading the message 'n' times. - action based like clicking on a particular part of the message or forwarding or printing the message - masking parts of the message and not deleteing it so that it can be revoked if required by the receiver on consent by the sender. This ensures that parts of communication can still be kept confidential. The business use case for masking could be to preserve the message as a proof of evidence while securing sensitive data. Advantges: 1. Information control at the receiver end by the originator of the message. 2. Deletion of unwanted messages automatically means savings on available space for the receiver. 3. Better handling of sensitive information.
Sender managed transient messages .
Bhavan Kumar, Ananth Chakravarthy, Amudha Bhavankumar
The following flow chart describes the main flow and the implentation of the disclosure. The left
pane describes the working on the senders side and the the right pane describes the working on
the receivers client.
The internals of the masking part are described in the following flowchart.
1. The sender of the message chooses to mask certain parts of the message. This selection could be text, image, URLs or any other content which can be embedded into messaging client.s
2. The messaging client on the senders side provides a UI gesture to collect the passphrase that is to be used for generating the masked content from the given content.
3. The mail client then embeds custom tags that can be interpreted by the mail client on the recievers side.
4. The custom mask tag could minimally have the following information .
The original content and
The masked content that has to be shown in case the triggers for masking are to be activated in the receivers mailbox.
It may be noted that from the above example that the masked content should preferbaly be generated by using a symmetric key approach as that would involve less maintenance in case
of revocation request from the reciever at a later point of time.
6. If the sender chooses to enable revocation of the masked content at a later point of time, ( for example legal proof verification that the sender has indeed sent the content previously ), then a header is set by the senders mail client to mark the message as a revocable message.
7. The sender is also provided with UI gestures to specify the triggers for masking . The triggers could be one or more of the following
a. 'n' reads
b. time based
c. Action based (
specific parts of the message)
The sender selects the part of the message that needs to be masked/deleted , chooses from a set of options that pop-up on a right click. Some of the options that could be provided by the user are "mask" or "delete" the message part. Other options that could be provided are the salt phrase that could be used by the transient message framework on the messaging client to mask the selected message. The sender can also specify the action that could be used to trigger the mask/delete of the message part.
Basing on the options set by the sender of the message, the transient message framework
proposed in this disclosure shall execute the masking part by using the data sent as control
headers along with the mail. The sender might optionally specify whether the reader of the message can send a unlock request to unscramble/unmask the message that was masked a...