Browse Prior Art Database

Method and system for protecting email address in public IM/presence sessions Disclosure Number: IPCOM000191362D
Original Publication Date: 2009-Dec-31
Included in the Prior Art Database: 2009-Dec-31
Document File: 4 page(s) / 233K

Publishing Venue



Almost every organization today has a collaboration network – used for communicating through instant messaging, VoIP, video chats, web conferences and more. The growing need for collaboration can come into a conflict with the essential need for protecting and securing the information. The main identifier of a user for collaboration purposes can be in the form of its email address (in many cases, organizations decide to use this form for simplicity reasons). If someone wants to exchange instant messages with a user (chat), it has to know its email address. This means the email address is exposed and the user can be attacked by malicious messages (SPAM/SPIM)

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 41% of the total text.

Page 1 of 4

Consider the following use case: Bob from company A submits a support request to

Bob uses a public IM provider for communication.

wants to communicate with Bob through instant messaging.

contact list using his public IM (email) address.

                                  email address in now public (outside her organization) and exposed to SPAM/SPIM attacks.

A possible solution to this issue can be to separate the email address from

the unique IM identifier. In this case, the organization will have to keep in its directory two identifiers - one for email purposes, and the other for IM, both in the format of email address. That will prevent the use of IM address for sending SPAM, but not SPIM. This solution is only partial and seldom implemented due to the need to maintain two identifiers.

    The Real Time Collaboration (RTC) Sametime Gateway is a collaboration gateway between the internal community of one or several Sametime servers and the public IM communities. The Gateway supports conversion between the proprietary Sametime protocol (


                       and public protocols such as SIP and XMPP. This disclosure offers a mechanism for protecting email addresses when used to communicate with public IM providers.

For each internal user, the Gateway will provide a temporary faked email address, alternative to the real internal address. When an internal user adds a public user to its contact list in order to chat with him/her, the faked email will be used. The public user will not be aware what the real email address of the internal user is. Furthermore, the alternative address will be temporary and defined for a predefine time (for example in the support use case mentioned above, it will be active for 24 hours). Meaning, next time the internal user would like to chat with a public user - a different faked address will be used.

    This way the real email address remains hidden and thus protected. The internal user can chat with the public user fearlessly. Its email address is secured from SPAM/SPIM attacks.

    In addition, most of the "one time" solutions today require the user to be active and create the faked email account. While our solution is server side, thus - can offer enforcement of company policy and prevent human errors.

    The RTC Sametime Gateway allows internal (Sametime) communities to interact (share presence and instant messaging)

with various public

                           (internal user; subscriber) can add a user from the external community (external user; subscribe) to its contact list (this operation is called subscribe). Internal user can also send instant messages to external user.

The subscribe operation generates the following events (IM flow is very similar):

A subscribe request is sent to the external server

- The subscribe request contains the ID of the subscriber which is its email address
- The subscribe request also contains the routing information to be used for re...