Title of Invention	SYSTEM AND METHOD FOR USER PRESENCE BASED INSTANT MESSAGE DELIVERY
Abstract	The invention explains a system and a method for user presence based insiani message delivery over IMPS or SIP/SIMPLE comprising: means using an originating client where the originating client facilitates the user to deliver the message at the appropriate time and providing flexibility to the user; and/or means using an IM server where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client.

Title of Invention

SYSTEM AND METHOD FOR USER PRESENCE BASED INSTANT MESSAGE DELIVERY

Abstract

The invention explains a system and a method for user presence based insiani message delivery over IMPS or SIP/SIMPLE comprising: means using an originating client where the originating client facilitates the user to deliver the message at the appropriate time and providing flexibility to the user; and/or means using an IM server where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client.

Full Text	FIELD OF TECHNOLOGY This invention relates to the field of generic Instant Messaging and Presence services irrespective of whether the services works over IMPS or SIP/SIMPLE technology. Particularly, this invention applies to various instant messaging technologies enabled with presence service, where a sender may wish to deliver the messages based on the recipient user presence status. More particularly this invention encompasses a System and Method for User Presence based Instant Message Delivery. DESCRIPTION OF RELATED ART Figure 1 illustrates the Conventional Instant Messaging scenario. Currently if a User wants to send an IM to another User at a particular presence state, the sender has to wait for the recipient user to change his presence state as expected, before he sends the message request. After the intended presence is notified, the sender drafts and sends the message to the recipient user. The transaction flow can be described as below: 1. Originating user logs into IMPS server. 2. IMPS Server confirms back to the originating user. 3. Recipient client imparts the presence attribute to IMPS server. 4. The IMPS server replies with the status message. 5. IMPS server notifies the updated presence information to Originating client. 6. The Originating client responds with the status to IMPS server and indicates the new presence to the user. 7. Originating user decides and then composes the IMPS message, if required for the current presence state. 8. Originating client sends the compiled message to IMPS server. 9. IMPS server confirms back to the originating client. 10.The IMPS server delivers the message/notification to the Recipient client it available. 11. Recipient client responds back to IMPS server with status message. However there are following limitations to the existing technology: 1. User's time and effort are consumed to a large extent. 2. User has very less flexibility in operation and the system is not user friendly. 3. IM system usability is greatly restricted. 4. User cannot mention a presence or a communication means specific presence state in which the message needs to be delivered. 5. User cannot stop receiving messages from the server, until he comes out of a particular state or until he moves into a particular state SUMMARY OF THE INVENTION The primary object of this invention is therefore to invent a system and method for User Presence based Instant Message Delivery. It is a further object of this invention to provide a system for delivering the instant messages based on the presence of the other IM user in an automated manner which will increase the IM user's flexibility and may stimulate the IM market. User's Presence is a key in the communication circumstances as it could influence the conversation (Ex: person-person, telephone call, IM). Hence it may be necessary for the sender, to deliver the messages based on the recipient's user presence in the instant messaging technology enabled with presence service. Though the sender might decide about the appropriate recipient user's presence for delivery, it may not always be possible for the sender, to wait for the appropriate recipient user's presence state. This may consume lots of IM user's time, effort, etc. In such circumstances, the IM system could help the sender to deliver the message at the appropriate time, and thereby it provides more user flexibility. User presence based IM delivery may not be possible in any other messaging technology. The invention describes a system that can be applied to Instant Messaging technology, where the system allows the IM user to specify the user presence attribute of the other IM user, thereby allowing him to deliver the message at appropriate time. The system thus creates environment where both IM users communicate at their convenience and value each others presence. The system has two approaches, each having its unique way of achieving the objectives. They are, as mentioned below 1. Originating client - where the originating client facilitates the user to deliver the message at the appropriate time and thereby providing more flexibility to the user. 2. IM server - where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client. In the following sections the methods to accomplish the two approaches mentioned above are explained for example in IMPS and SIP/SIMPLE technology, which is feasible in various other technologies. Accordingly, this invention explains a system for user presence based instant message delivery over IMPS or SIP/SIMPLE comprising: (a) means using an originating client where the originating client facilitates the user to deliver the message at the appropriate time and providing flexibility to the user; and/or (b) means using an IM server where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client. The means using an originating client is involved the IM user compiles the message specifying the user presence information, for which the message needs to be delivered by the originating client to the other IM user. The originating IM client retains the message and delivers the instant message only after the recipient's user presence encounters as specified in the compiled message. When the means using an IM server is involved in IMPS the IM user compiles the message specifying the presence information, for which the message is delivered by the IMPS server to the other user where the IMPS server retains the message and delivers the instant message after the recipient user presence encounters as specified in the compiled message. When the means using an IM server is involved in SIP/SIMPLE the IM user compiles the message specifying the presence information, for which the message is delivered by the IM server to the other user where the IM server retains the message and delivers the instant message after the recipient user presence encounters as specified in the compiled message. When the means using an IM server is involved in SIP/SIMPLE a header field "Event-To-Deliver-IM" is involved which is adapted to identify and deliver the IM as per sender's request and contains the parameters presence-name and max-wait-time. The max-wait-time parameter of Event-To-Deliver-IM header field value indicates the duration the IM is stored by the server before delivery, when the presence condition is not met. The value of the said parameter is a number, indicated in seconds and if the parameter is not provided, the value of the Expires header field determines the duration the IM is stored. Accordingly, this invention further explains a method for user presence based instant message delivery over IMPS or SIP/SIMPLE comprising the step of: (a) using an originating client where the originating client facilitates the user to deliver the message at the appropriate time and providing flexibility to the user; and/or (b) using an IM server where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client. When using an originating client in IMPS the client allows the user to specify the recipient user presence attributes for which the messages are delivered in the SendMessageRequest. The originating user specify a MaxWaitTime along with the user presence attributes, for the tolerance of message delivery where the MaxWaitTime indicates the maximum waiting time required for the IMPS client before it sends the instant messages. The IMPS client allows the user to specify those recipients' presence information that were authorized. The originating IMPS client attempts to deliver the instant messages, when the recipient user presence is met with the message delivery requirements and if the recipient user has not updated his presence, the IMPS client attempts to deliver the messages once the MaxWaitTime has expired. If the recipient has not logged in, then the compiled messages gets lost and the same is notified to the sender where if the MaxWaitTime is not specified, then the IMPS client maintain the instant messages till the recipient user presence condition is met. If the recipient blocks the originating user from sending the instant messages the message is delivered and the same is indicated to the originating user, if the delivery report is requested. When using an originating client in IMPS the messages with user presence expire if the user presence condition is not met within the expiry period and the messages is not sent. The IMPS client allows the user to compose the message and retain it locally with the user presence and wait time. The IMPS client monitors the updated presence of the targeted recipients. When using an originating client in IMPS the IMPS client sends the message request to IMPS server for the condition met. When using an originating client in SIP/SIMPLE the client allows the user to specify the recipient user presence attributes for which the messages is delivered in the MESSAGE where the header field in MESSAGE, "Event-To-Deliver-IM" allows the originating user to specify a max-wait-time along with the user presence attributes, for the tolerance of message delivery. The max-wait-time indicates the maximum waiting time required for the IM client before it sends the instant messages to IM server when the recipient user-presence condition is not met where the IM client allows the user to specify only those recipient's presence information that were authorized. The originating IM client attempts to deliver the instant messages, when the recipient user presence is met with the recipient user presence and wait time and if the recipient user does not update his presence, the IM client attempts to deliver the messages once the max-wait-time is expired. If the recipient has not logged in, then the compiled messages is lost and the same is indicated to the sender and if the max-wait-time is not specified, then the IM client maintains the instant messages till the recipient user presence condition is met. The recipient user blocks the originating user from sending the instant messages where, the messages is not delivered and the same is indicated to the originating user in the response. The messages with user presence expires, if the user presence condition is not met within the expiry period and the messages is not sent. The IM client allows the user to compose the message and retains it locally with the user presence and wait time. The IM client monitors the updated presence of the targeted recipients. The IM client sends the message request to IM server for the condition met. When using an IM server in IMPS the IMPS server confirm back to the IM client on receiving the message request with user presence and if the IMPS server does not support this, then it returns back a service error indicating the non-support. When using an IM server in IMPS, if the specified user presence in the message request is not authorized by the recipient user, the originating user receive a service error indicating the requirement for authorization by the recipient user for the presence attributes. The IMPS server attempts to deliver the instant messages, when the recipient user presence and wait time are met and while delivering the instant messages / notifications, the conditional attributes user presence and MaxWaitTime are not known to the recipient client. If the recipient user has not updated his presence, the IMPS server attempts to deliver the messages once the MaxWaitTime has expired and if the recipient has not logged in, then the delivered messages is kept as offline. If the offline messages are not supported by the IMPS server, the messages are lost and the same is indicated back to the originating user, if the delivery report is requested where if the MaxWaitTime is not specified, then the IMPS server maintains the instant messages till the recipient user presence condition is not met. In IMPS the recipient user blocks the originating user from sending the instant messages and the messages with user presence attributes are not delivered and the same is indicated to the originating user, if the delivery report is requested. In IMPS the messages with user presence expire, if the user presence condition is not met and the messages is lost where the same is indicated back to the originating user, if the delivery report is requested. The recipient user over-rides the user presence and MaxWaitTime set by the sender and retrieves the messages. The originating client and IMPS server supports user presence based IM delivery. The originating IMPS Client specifies the presence state and MaxWaitTime in the send or forward message request if it is supported. The information elements, presence state and MaxWaitTime are optional to the message request. The originating user specify the MaxWaitTime along with the user presence, as the instant messages / notifications is delivered for either the user presence attributes or MaxWaitTime expiry, which ever occurs first where the MaxWaitTime is lesser than the message expiry-time and the MaxWaitTime is not specified without specifying the user presence. The originating user is allowed to specify those presence attributes that are authorized by the recipient user, in the message request. In IMPS the IMPS server confirms back the service errors. When using an IM server in IMPS the originating IMPS Client does not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline. When using an IM server in IMPS the IMPS server return a service error, when the message is delivered for a user presence, which is not authorized for the originating user and if the message is accepted by IMPS server and the user presence is un-authorized before IM delivery, the same is indicated back to the originating user, if the delivery report is requested. When using an IM server in IMPS the IMPS server consider the messages with user presence, as offline messages, when the recipient client is not logged in and the same is indicated back to the originating user, if the delivery report is requested where if the offline messaging is not supported, then the messages is lost. When using an IM server in IMPS the IMPS server delivers the instant messages with the user presence, when the recipient user attempts to block the originating user and any outstanding messages sent by the originating user is not delivered, if the originating user is blocked where the same is indicated back to the originating user, if the delivery report is requested. The IMPS server does not deliver those instant messages with the user presence that are expired and the same is indicated back to the originating user, if the delivery report is requested. The recipient user is allowed to view any outstanding messages / notifications that are not appropriate to the current user presence. When using an IM server in SIP/SIMPLE the server receives the request and the IM is delivered only after the condition is met and the server stores the message and monitors the presence change of the recipient user where the server delivers the instant messages, when the message delivery requirements, recipient user presence and maximum wait time are met. While delivering the instant messages / notifications, the conditional attributes, user presence and max-wait-time are not known to the recipient client and if the recipient user has not updated his presence, the IM server attempts to deliver the messages once the max-wait-time has expired. If the recipient has not logged in, then the delivered messages is kept as offline and if the offline messages are not supported by the IM server, then the messages are lost and the same is indicated back to the originating user in the response. If the max-wait-time is not specified, then the IM server maintains the instant messages till the recipient user presence condition is not met. The recipient user blocks the originating user from sending the instant messages and the messages with user presence attributes are not delivered and the same is indicated to the originating user in the response. The messages with user presence expires if the user presence condition is not met and the messages are lost and the same is indicated back to the originating user in the response. The originating Client and IM Server supports the user presence based IM delivery. The originating IM Client specifies the presence state and max-wait-time in MESSAGE. When using an IM server in SIP/SIMPLE the header field "Event-To-Deliver-IM" is optional in the MESSAGE request. The originating user specify the max-wait-time along with the user presence, for delivering the instant messages for either the user presence attributes or max-wait-time expiry, which ever occurs first where the max-wait-time is always lesser than the message expiry-time and the max-wait-time is not specified without specifying the user presence. The originating user is allowed to specify those presence attributes that are authorized currently by the recipient user, in the message request. The originating IM Client does not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline. When using an IM server in SIP/SIMPLE the IM Server does not deliver the instant messages with the user presence, when the recipient user blocks the originating user any outstanding messages sent by the originating user is not delivered, if the originating user is blocked where the same is indicated back to the originating user in the response. When using an IM server in SIP/SIMPLE the IM Server does not deliver those instant messages that are expired and the same is indicated back to the originating user in the response. The other objects, features and advantages of the present invention will be more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS Figure 1 illustrates the Conventional Instant Messaging scenario Figure 2 illustrates a User presence based IM delivery - Originating Client based solution in IMPS technology Figure 3 illustrates a User presence based IM delivery - Originating Client based solution in SIP/SIMPLE technology Figure 4 illustrates a User presence based IM delivery -Server based solution in IMPS technology Figure 5 illustrates a User presence based IM delivery -Server based solution in SIP/SIMPLE technology DETAILED DESCRIPTION OF THE INVENTION A preferred embodiment of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiment is merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. Structure of the Invention User presence based IM delivery - Originating Client based solution in IMPS and SIP/SIMPLE technologies The IM user compiles the message specifying the user presence information, for which the message needs to be delivered by the originating client to the other IM user. The originating IM client retains the message and attempts to deliver the instant message only after the recipient's user presence encounters as specified in the compiled message. This invention applies to generic instant messaging, feasible in systems like IMPS and SIP/SIMPLE. User presence based IM delivery - Server based solution in IMPS technology The IM user compiles the message specifying the presence information, for which the message needs to be delivered by the IMPS server to the other user. The IMPS server retains the message and attempts to deliver the instant message only after the recipient user presence encounters as specified in the compiled message. Primitive and Information Elements User presence based IM delivery - Server based solution in SIP/SIMPLE technology The IM user compiles the message specifying the presence information, for which the message needs to be delivered by the IM server to the other user. The IM server retains the message and attempts to deliver the instant message only after the recipient user presence encounters as specified in the compiled message. The invention involves adding a new header field "Event-To-Deliver-IM" to the MESSAGE method, which is detailed in IETF RFC 3428. It is defined as an optional field. Event-To-Deliver-IM: The Event-To-Deliver-IM header field serves as a way to identify and deliver the IM as per sender's request. It consists of parameters presence-name and max-wait-time. The max-wait-time parameter of Event-To-Deliver-IM header field value indicates how long the IM needs to be stored by the server before delivery, if the presence condition is not met. The value of the parameter is a number, indicated in seconds. If this parameter is not provided, the value of the Expires header field determines how long the IM is stored. Example: Event-To-Deliver-IM: presence; presence-name=value;max-wait-time=seconds Example Message The message flow shows an initial IM sent from User 1 to User 2, both users in the same domain, "domain", through a single proxy. Message F1 looks like: MESSAGE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP user1pc.domain.com;branch=29hG4bK776sgdkse Max-Fon/vards: 70 From: sip:user1 ©domain.Gom;tag=49583 To: sip:[email protected] CalMD: [email protected] CSeq: 1 MESSAGE Event-To-Deliver-IM: presence; presence-name=value;max-wait-time=seconds Content-Type: text/plain Content-Length: 18 Watson, come here. Message F2 looks like: MESSAGE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP proxy.domain.coni;branch=z9hG4bK123dsghds Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse; received=1.2.3.4 Max-FonA/ards: 69 From: sip:[email protected];tag=49394 To: sip:[email protected] Call-ID: [email protected] CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Watson, come here. Message F3 looks like: SIP/2.0 200 OK Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds; received=192.0.2.1 Via: S1P/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse; received=1.2.3.4 From: sip:[email protected];tag=49394 To: sip:[email protected];tag=ab8asdasd9 CaIND: [email protected] CSeq: 1 MESSAGE Content-Length: 0 Message F4 looks like: SIP/2.0 200 OK Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse; received=1.2.3.4 From: sip:user1 ©domain.com;;tag=49394 To: sip:[email protected];tag=ab8asdasd9 Call-ID: [email protected] CSeq: 1 MESSAGE Content-Length: 0 Operation of the invention The invention applies to generic instant messaging system. Below the operation is explained for systems like IMPS and SIP/SIMPLE. User presence based IM delivery - Originating Client based solution in IMPS technology Figure 2: User presence based IM delivery - Originating Client based solution in IMPS technology 1. John logs in to the IMPS server. 2. Service Provider confirms John's login request. 3. John drafts & stores the instant messages request with the user presence state for the delivery to Peter. 4. Later Peter changes his presence state to available & Peter's IMPS client notifies the presence state to IMPS server. 5. IMPS server confirms back to Peter's IMPS Client about this change in presence state. 6. IMPS server notifies Peter's availability to John (IMPS Client). 7. John's IMPS client confirms the presence notification. 8. John's IMPS Client initiates the send / forward message request to IMPS server, for those messages stored in the IMPS client, once the presence condition is met. 9. IMPS server confirms back with Status primitive. 10. IMPS server pushes / notifies the message to recipient's IMPS client. 11. Recipient's IMPS client confirms back to IMPS server with status primitive. User Presence based IM delivery should be supported by the IMPS client. If supported by the IMPS client, the client must allow the user to specify the recipient user presence attributes for which the messages need to be delivered in the SendMessageRequest method. The originating user may also specify a MaxWaitTime along with the user presence attributes, for the tolerance of message delivery. The MaxWaitTime indicates the maximum waiting time required for the IMPS client before it sends the instant messages to IMPS server, if the recipient user-presence condition does not meet. The IMPS client should allow the user to specify only those recipients' presence information that were authorized before. The originating IMPS client must attempt to deliver the instant messages, when the recipient user presence is met with the message delivery requirements (recipient user presence, wait time). If the recipient user has not updated his presence, the IMPS client should attempt to deliver the messages once the MaxWaitTime has expired. If the recipient has not logged in, then the compiled messages may be lost and the same is notified to the sender. If the MaxWaitTime is not specified, then the IMPS client should maintain the instant messages till the recipient user presence condition is met. The recipient user may have blocked the originating user from sending the instant messages. In such conditions, the messages would not be delivered and the same may be indicated to the originating user, if the delivery report is requested. The messages with user presence could expire, if the user presence'condition is not met within the expiry period. In such cases, the messages would not be sent. In order to achieve the user presence based IM delivery, the originating IMPS client has the following requirements: 1. IMPS client allows the user to compose the message and retain it locally with the conditions (user presence and wait time) mentioned. 2. IMPS client monitors the updated presence of the targeted recipients. 3. IMPS client attempts to the send the message request to IMPS server for the condition met. User presence based IM delivery - Originating Client based solution in SIP/SIMPLE technology Figure 3: User presence based IM delivery - Originating Client based solution in SIP/SIMPLE technology 1. John drafts & stores the instant messages request with the user presence state for the delivery to Peter. 2. Later Peter changes his presence state to available & Peter's IM client notifies the presence state to Server. 3. Server confirms back to Peter's Client about this change in presence state. 4. Server notifies Peter's availability to John (IM Client). 5. John's client confirms the presence notification. 6. John's IM Client initiates the MESSAGE request to server, for those messages stored in the IM client, once the presence condition is met. 7. Server forwards the MESSAGE request to recipient's IM client. 8. MESSAGE is received by the Peter's client and acknowledged. 9. The response is then forwarded to John's client. User Presence based IM delivery should be supported by the IM client. If supported by the IM client, the client must allow the user to specify the recipient user presence attributes for which the messages need to be delivered in the MESSAGE method. New header field in MESSAGE method "Event-To-Deliver-IM" allows the originating user to specify a max-wait-time along with the user presence attributes, for the tolerance of message delivery. The max-wait-time indicates the maximum waiting time required for the IM client before it sends the instant messages to IM server, if the recipient user-presence condition does not meet. The IM client should allow the user to specify only those recipients' presence information that were authorized before. The originating IM client must attempt to deliver the instant messages, when the recipient user presence is met with the message delivery requirements (recipient user presence, wait time). If the recipient user has not updated his presence, the IM client should attempt to deliver the messages once the max-wait-time has expired. If the recipient has not logged in, then the compiled messages may be lost and the same is indicated to the sender. If the max-wait-time is not specified, then the IM client should maintain the instant messages till the recipient user presence condition is met. The recipient user may have blocked the originating user from sending the instant messages. In such conditions, the messages would not be delivered and the same may be indicated to the originating user in the response. The messages with user presence could expire, if the user presence condition is not met within the expiry period. In such cases, the messages would not be sent. In order to achieve the user presence based IM delivery, the originating IM client has the following requirements: 1. IM client allows the user to compose the message and retains it locally with the conditions (user presence and wait time) mentioned. 2. IM client monitors the updated presence of the targeted recipients. 3, IM client attempts to the send the message request to IM server for the condition met. User presence based IM delivery - IM Server based solution in IMPS technology Figure 4: User presence based IM delivery - Server based solution in IMPS technology 1. John logs in to the IMPS server. 2. Service Provider confirms the John's login request. 3. John sends instant messages with the presence state for the delivery to Peter. 4. Service Provider confirms back to John with the status primitive. 5. John logs out from the IMPS server. 6. Service Provider confirms back to log out request. 7. Peter changes his presence state and the recipient's client notifies the change to IMPS server. 8. Service Provider confirms back to Peter about this change in presence state. 9. IMPS server delivers the message(s)/notification(s) available for this presence state to Peter. 10. Peter's IMPS Client confirms back to this delivery of message(s) / notification(s). User Presence based IM delivery should be supported both by the IM client and IMPS server. If supported by the IM client, the originating client must allow the user to specify the recipient user presence attributes for which the messages need to be delivered through SendMessageRequest. The originating user may also specify a MaxWaitTime along with the user presence attributes, for the tolerance of message delivery. The MaxWaitTime indicates the maximum waiting time required for the IMPS server before it delivers the instant messages, if the recipient user-presence condition does not meet. However the originating client should not allow the user to specify the user presence or wait time, if the recipient user has not logged in. The IMPS client should allow the user to specify only those recipient's presence information that were authorized before. On receiving the message request with user presence, the IMPS server is expected to confirm back to the IM client. If the IMPS server does not support this method, then it must return back a service error indicating the non-support of this method. If the specified user presence in the message request is not authorized by the recipient user, then the originating user would receive a service error indicating that the user presence attributes need to be authorized by the recipient user. The IMPS server must attempt to deliver the instant messages, when the message delivery requirements (recipient user presence, wait time) are met. While delivering the instant messages / notifications, the conditional attributes (user presence, MaxWaitTime) should not be known to the recipient client. If the recipient user has not updated his presence, the IMPS server should attempt to deliver the messages once the MaxWaitTime has expired. If the recipient has not logged in, then the delivered messages should be kept as offline. If the offline messages are not supported by the IMPS server, then the messages would have been lost. The same (recipient has not logged in) has to be indicated back to the originating user, if the delivery report is requested. If the MaxWaitTime is not specified, then the IMPS server should maintain the instant messages till the recipient user presence condition is not met. The recipient user may have blocked the originating user from sending the instant messages. In such conditions, the messages with user presence attributes would not be delivered and the same needs to be indicated to the originating user, if the delivery report is requested. The messages with user presence could expire, if the user presence condition is not met. In such cases, the messages would have been lost. The same (message has expired) has to be indicated back to the originating user, if the delivery report is requested. The recipient user may also over-ride the condition (user presence, MaxWaitTime) set by the sender, and may decide to retrieve the messages. In order to achieve the user presence based IM delivery, the originating IMPS client and IMPS server has the following requirements: 1. Originating Client and IMPS server should support this user presence based IM delivery method. 2. Originating IMPS Client must be able to specify the presence state and MaxWaitTime in the send or fonrt/ard message request, if the method is supported. 3. The information elements i.e., presence state and MaxWaitTime are optional to the message request. In case the information element Presence-To-Deliver-IM is not present then the message request will be treated as mentioned in the related art above. Originating user may also specify the MaxWaitTime along with the user presence, so that the instant messages / notifications can be delivered for either the user presence attributes or MaxWaitTime expiry, which ever occurs first. However it is necessary that the MaxWaitTime should always be lesser than the message expiry-time. The MaxWaitTime cannot be specified without specifying the user presence. 4. Originating user should be allowed to specify only those presence attributes that are authorized currently by the recipient user, in the message request. 5. IMPS server must confirm back the service errors, if the IMPS server does not support this method. 6. Originating IMPS Client should not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline. 7. IMPS server should return a service error, when the message is requested to be delivered for a user presence, which was not authorized for the originating user. If the message is accepted by IMPS server and the user presence is un-authorized before IM delivery then the same should be indicated back to the originating user, if the delivery report is requested. 8. IMPS server may consider the messages with user presence, as offline messages, when the recipient client has not logged in. The same should be indicated back to the originating user, if the delivery report is requested. If the offline messaging is not supported, then the messages would be lost. 9. IMPS server should not deliver the instant messages with the user presence, when the recipient user attempts to block the originating user. Recipient user may be warned of the fact that, any outstanding messages sent by the originating user would not be delivered, if the originating user is blocked. The same should be indicated back to the originating user, if the delivery report is requested. 10JMPS server should not deliver those instant messages (with the user presence) that were expired. The same should be indicated back to the originating user, if the delivery report is requested. 11 The recipient user may be allowed to view any outstanding messages / notifications that are not appropriate to the current user presence. User presence based IM delivery - IM Server based solution in SIP/SIMPLE technology Figure 5: User presence based IM delivery - Server based solution in SIP/SIMPLE technology 1. John drafts and forwards the MESSAGE request with the user presence state for the delivery to Peter. 2. Server stores the IM for the condition to be met or the maximum wait time to expire. 3. Server returns response to John's request as "202 Accepted". 4. Later Peter changes his presence state to available & Peter's IM client notifies the presence state to Server. 5. Server confirms back to Peter's Client about this change in presence state. 6. Server fonA/ards the MESSAGE request to Peter, for those messages stored on the server, once the presence condition is met. 11. MESSAGE is received by the Peter's client and acknowledged. User Presence based IM delivery should be supported both by the IM client and IM server. If supported by the IM client, the originating client must allow the user to specify the recipient user presence attributes for which the messages need to be delivered, in the MESSAGE method. The originating user may also specify a max-wait-time along with the user presence attribute, for the tolerance of message delivery. The max-wait-time indicates the maximum waiting time required for the IM server before it delivers the instant messages, if the recipient user-presence condition does not meet. The IM client should allow the user to specify only those recipient's presence information that were authorized before. Sender fonA^ards the message to the server. The server receives this request and recognizes that the IM needs to be delivered only after a condition is met. The server stores the message and monitors the presence change of the recipient user. The server must attempt to deliver the instant messages, when the message delivery requirements (recipient user presence, maximum wait time) are met. While delivering the instant messages / notifications, the conditional attributes (user presence, max-wait-time) should not be known to the recipient client. If the recipient user has not updated his presence, the IM server should attempt to deliver the messages once the max-wait-time has expired. If the recipient has not logged in, then the delivered messages should be kept as offline. If the offline messages are not supported by the IM server, then the messages would have been lost. The same (recipient has not logged in) has to be indicated back to the originating user in the response. If the max-wait-time is not specified, then the IM server should maintain the instant messages till the recipient user presence condition is not met. The recipient user may have blocked the originating user from sending the instant messages. In such conditions, the messages with user presence attributes would not be delivered and the same may be indicated to the originating user in the response. The messages with user presence could expire, if the user presence condition is not met. In such cases, the messages would have been lost. The same (message has expired) has to be indicated back to the originating user in the response. In order to achieve the user presence based IM delivery, the originating IM client and IM server has the following requirements: 1. Originating Client and IM Server should support this user presence based IM delivery method. 2. Originating IM Client must be able to specify the presence state and max-wait-time in MESSAGE method. 3. The header field "Event-To-Deliver-IM" is optional in the MESSAGE request. In case the header field "Event-To-Deliver-IM" is not present then message request will be treated as mentioned in the related art above. Originating user may also specify the max-wait-time along with the user presence, so that the instant messages can be delivered for either the user presence attributes or max-wait-time expiry, which ever occurs first. However it is necessary that the max-wait-time should always be lesser than the message expiry-time. The max-wait-time cannot be specified without specifying the user presence. 4. Originating user should be allowed to specify only those presence attributes that are authorized currently by the recipient user, in the message request. 5. Originating IM Client should not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline. 6. IM Server should not deliver the instant messages with the user presence, when the recipient user attempts to block the originating user. Recipient user may be warned of the fact that, any outstanding messages sent by the originating user would not be delivered, if the originating user is blocked. The same should be indicated back to the originating user in the response. 7. IM Server should not deliver those instant messages (with the user presence) that were expired. The same should be indicated back to the originating user in the response. The following are some of the advantages of practicing the present invention. 1. Saves user's time, effort. 2. More user flexibility / friendly. 3. Stimulates IM system usability. 4. Increases the revenue opportunity. 5. Automates the user presence based IM delivery. Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be affected therein by one skilled in the art without departing from the scope or spirit of the invention. Alternative In order to provide presence based IM delivery from the recipient's perception, it is possible that the recipient User specifies the presence state during which he is not ready to accept the messages. On receiving the message at the client side, the client checks if such a condition is present before presenting the message to the User. If the condition is present the client will delay the message until the recipient changes the presence state. This alternative is applicable in both IMPS and SIP/SIMPLE technology. The above-presented description is of the best mode contemplated for carrying out the present invention. The manner and process of making and using it is in such a full, clear, concise and exact terms as to enable to any person skilled in the art to which it pertains to make and use this invention. New embodiments in particular, which also lie within the scope of the invention can be created, in which different details of the different examples can in a purposeful way be combined with one another. This invention is however, susceptible to modifications and alternate constructions from that disclosed above which are fully equivalent. Consequently, it is not the intention to limit this invention to the particular embodiment disclosed. On the contrary, the intention is to cover all modifications and alternate constructions coming within the spirit and scope of the invention as generally expressed by the following claims which particularly point out and distinctly claim the subject matter of the invention. GLOSSARY OF TERMS AND THEIR DEFINITIONS IM - Instant Message IMPS - Instant Messaging and Presence Service IETF - Internet Engineering Task Force RFC - Request for Comments SIP - Session Initiation Protocol SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions WE CLAIM 1. A system for user presence based instant message delivery over IMPS or SIP/SIMPLE comprising: (a) means using an originating client where the originating client facilitates the user to deliver the message at the appropriate time and providing flexibility to the user; and/or (b) means using an IM server where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client. 2. A system as claimed in claimed 1 wherein when the means using an originating client is involved the IM user compiles the message specifying the user presence information, for which the message needs to be delivered by the originating client to the other IM user. 3. A system as claimed in claim 1 wherein the originating IM client retains the message and deliver the instant message only after the recipient's user presence encounters as specified in the compiled message. 4. A system as claimed in claim 1 wherein when the means using an IM server is involved in IMPS the IM user compiles the message specifying the presence information, for which the message is delivered by the IMPS server to the other user where the IMPS server retains the message and delivers the instant message after the recipient user presence encounters as specified in the compiled message. 5. A system as claimed in claim 1 wherein when the means using an IM server is involved in SIP/SIMPLE the IM user compiles the message specifying the presence information, for which the message is delivered by the IM server to the other user where the IM server retains the message and delivers the instant message after the recipient user presence encounters as specified in the compiled message. A system as claimed in claim 1 wherein when the means using an IM server is involved in SIP/SIMPLE a header field "Event-To-Deliver-IM" is involved which is adapted to identify and deliver the IM as per sender's request and contains the parameters presence-name and max-wait-time. A system as claimed in claim 1 wherein when the means using an IM server is involved in SIP/SIMPLE the max-wait-time parameter of Event-To-Deliver-IM header field value indicates the duration the IM is stored by the server before delivery, when the presence condition is not met. A system as claimed in claim 1 wherein when the means using an IM server is involved in SIP/SIMPLE the value of the max-wait-time parameter is a number, indicated in seconds and if the parameter is not provided, the value of the Expires header field determines the duration the IM is stored. A method for user presence based instant message delivery over IMPS or SIP/SIMPLE comprising the step of: (a) using an originating client where the originafing client facilitates the user to deliver the message at the appropriate time and providing flexibility to the user; and/or (b) using an IM server where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client. 3. A method as claimed in claim 9 wherein when using an originating client in IMPS the client allows the user to specify the recipient user presence attributes for which the messages is delivered in the SendMessageRequest. 1. A method as claimed in claim 9 wherein when using an originating client in IMPS the originating user specify a MaxWaitTime along with the user presehce attributes, for the tolerance of message delivery where the MaxWaitTime indicates the maximum waiting time required for the IMPS client before it sends the instant messages. A method as claimed in claim 9 wherein when using an originating client in IMPS the IMPS client allow the user to specify those recipient's presence information that were authorized. A method as claimed in claim 9 wherein when using an originating client in IMPS the originating IMPS client attempts to deliver the instant messages, when the recipient user presence is met with the message delivery requirements and if the recipient user has not updated his presence, the IMPS client attempts to deliver the messages once the MaxWaitTime has expired. A method as claimed in claim 9 wherein when using an originating client in IMPS and if the recipient has not logged in, then the compiled messages gets lost and the same is notified to the sender where if the MaxWaitTime is not specified, then the IMPS client maintain the instant messages till the recipient user presence condition is met A method as claimed in claim 9 wherein when using an originating client in IMPS the IMPS client allows the user to compose the message and retain it locally with the user presence and wait time. A method as claimed in claim 9 wherein when using an originating client in SIP/SIMPLE the client allows the user to specify the recipient user presence attributes for which the messages is delivered in the MESSAGE where the header field in MESSAGE, "Event-To-Deliver-IM" allows the originating user to specify a max-wait-time along with the user presence attributes, for the tolerance of message delivery. .A method as claimed in claim 9 wherein when using an originating client in SIP/SIMPLE the max-wait-time indicates the maximum waiting time required for the IM client before it sends the instant messages to IM server when the recipient user-presence condition is not met where the IM client allows the user to specify only those recipient's presence information that were authorized. .A method as claimed in claim 9 wherein when using an originating client in SIP/SIMPLE the originating IM client attempts to deliver the instant messages, when the recipient user presence is met with the recipient user presence and wait time and if the recipient user does not updated his presence, the IM client attempts to deliver the messages once the max-wait-time is expired. ? A method as claimed in claim 9 wherein when using an originating client in SIP/SIMPLE the IM client allows the user to compose the message and retains it locally with the user presence and wait time. ? A method as claimed in claim 9 wherein when using an originating client in SIP/SIMPLE the IM client sends the message request to IM server for the condition met. .A method as claimed in claim 9 wherein when using an IM server in IMPS, the IMPS server attempts to deliver the instant messages, when the recipient user presence and wait time are met and while delivering the instant messages / notifications, the conditional attributes user presence and MaxWaitTime are not known to the recipient client. -A method as claimed in claim 9 wherein when using an IM server in IMPS, if the recipient user has not updated his presence, the IMPS server attempts to deliver the messages once the MaxWaitTime has expired and if the recipient has not logged in, then the delivered messages is kept as offline. .A method as claimed in claim 9 wherein when using an IM server in IMPS the recipient user over-rides the user presence and MaxWaitTime set by the sender and retrieves the messages. LA method as claimed in claim 9 wherein when using an IM server in IMPS the originating IMPS Client specify the presence state and MaxWaitTime in the send or fonward message request if it is supported. >.A method as claimed in claim 9 wherein when using an IM server in IMPS the information elements, presence state and MaxWaitTime are optional to the message request. ).A method as claimed in claim 9 wherein when using an IM server in IMPS originating user specify the MaxWaitTime along with the user presence, as the instant messages / notifications is delivered for either the user presence attributes or MaxWaitTime expiry, which ever occurs first where the MaxWaitTime is lesser than the message expiry-time and the MaxWaitTime is not specified without specifying the user presence. ^ A method as claimed in claim 9 wherein when using an IM server in IMPS the originating IMPS Client does not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline. }.A method as claimed in claim 9 wherein when using an IM server in IMPS the recipient user is allowed to view any outstanding messages / notifications that are not appropriate to the current user presence. J. A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE the server receives the request and the IM is delivered only after the condition is met and the server stores the message and monitors the presence change of the recipient user where the server delivers the instant messages, when the message delivery requirements, recipient user presence and maximum wait time are met. . A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE while delivering the instant messages / notifications, the conditional attributes, user presence and max-wait-time are not known to the recipient client and if the recipient user has not updated his presence, the IM server attempts to deliver the messages once the max-wait-time has expired. . A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE if the max-wait-time is not specified, then the IM server maintains the instant messages till the recipient user presence condition is not met. . A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE the originating IM Client specify the presence state and max-wait-time in MESSAGE . . A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE the header field "Event-To-Deliver-IM" is optional in the MESSAGE request. . A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE the originating user specify the max-wait-time along with the user presence, for delivering the instant messages for either the user presence attributes or max-wait-time expiry, which ever occurs first where the max-wait-time is always lesser than the message expiry-time and the max-wait-time is not specified without specifying the user presence. . A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE the originating IM Client does not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline. .A system for user presence based instant message delivery over IMPS or SIP/SIMPLE substantially as herein described particularly with reference to the drawings. 37. A method for user presence based instant message delivery over IMPS or SIP/SIMPLE substantially as herein described particularly with reference to the drawings.

Full Text

FIELD OF TECHNOLOGY
This invention relates to the field of generic Instant Messaging and Presence services irrespective of whether the services works over IMPS or SIP/SIMPLE technology. Particularly, this invention applies to various instant messaging technologies enabled with presence service, where a sender may wish to deliver the messages based on the recipient user presence status. More particularly this invention encompasses a System and Method for User Presence based Instant Message Delivery.
DESCRIPTION OF RELATED ART
Figure 1 illustrates the Conventional Instant Messaging scenario. Currently if a User wants to send an IM to another User at a particular presence state, the sender has to wait for the recipient user to change his presence state as expected, before he sends the message request. After the intended presence is notified, the sender drafts and sends the message to the recipient user.
The transaction flow can be described as below:
1. Originating user logs into IMPS server.
2. IMPS Server confirms back to the originating user.
3. Recipient client imparts the presence attribute to IMPS server.
4. The IMPS server replies with the status message.
5. IMPS server notifies the updated presence information to Originating client.
6. The Originating client responds with the status to IMPS server and indicates the new presence to the user.
7. Originating user decides and then composes the IMPS message, if required for the current presence state.
8. Originating client sends the compiled message to IMPS server.
9. IMPS server confirms back to the originating client.

10.The IMPS server delivers the message/notification to the Recipient client it
available. 11. Recipient client responds back to IMPS server with status message.
However there are following limitations to the existing technology:
1. User's time and effort are consumed to a large extent.
2. User has very less flexibility in operation and the system is not user friendly.
3. IM system usability is greatly restricted.
4. User cannot mention a presence or a communication means specific presence state in which the message needs to be delivered.
5. User cannot stop receiving messages from the server, until he comes out of a particular state or until he moves into a particular state
SUMMARY OF THE INVENTION
The primary object of this invention is therefore to invent a system and method for User Presence based Instant Message Delivery.
It is a further object of this invention to provide a system for delivering the instant messages based on the presence of the other IM user in an automated manner which will increase the IM user's flexibility and may stimulate the IM market.
User's Presence is a key in the communication circumstances as it could influence the conversation (Ex: person-person, telephone call, IM). Hence it may be necessary for the sender, to deliver the messages based on the recipient's user presence in the instant messaging technology enabled with presence service. Though the sender might decide about the appropriate recipient user's presence for delivery, it may not always be possible for the sender, to wait for the appropriate recipient user's presence state. This may consume lots of IM user's time, effort, etc. In such circumstances, the IM system could help the sender to deliver the message at the appropriate time, and thereby it provides more user flexibility. User presence

based IM delivery may not be possible in any other messaging technology.
The invention describes a system that can be applied to Instant Messaging technology, where the system allows the IM user to specify the user presence attribute of the other IM user, thereby allowing him to deliver the message at appropriate time. The system thus creates environment where both IM users communicate at their convenience and value each others presence.
The system has two approaches, each having its unique way of achieving the objectives. They are, as mentioned below
1. Originating client - where the originating client facilitates the user to deliver the message at the appropriate time and thereby providing more flexibility to the user.
2. IM server - where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client.
In the following sections the methods to accomplish the two approaches mentioned above are explained for example in IMPS and SIP/SIMPLE technology, which is feasible in various other technologies.
Accordingly, this invention explains a system for user presence based instant message delivery over IMPS or SIP/SIMPLE comprising:
(a) means using an originating client where the originating client facilitates the user to deliver the message at the appropriate time and providing flexibility to the user; and/or
(b) means using an IM server where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client.
The means using an originating client is involved the IM user compiles the message specifying the user presence information, for which the message needs to be delivered by the originating client to the other IM user. The originating IM client

retains the message and delivers the instant message only after the recipient's user presence encounters as specified in the compiled message. When the means using an IM server is involved in IMPS the IM user compiles the message specifying the presence information, for which the message is delivered by the IMPS server to the other user where the IMPS server retains the message and delivers the instant message after the recipient user presence encounters as specified in the compiled message. When the means using an IM server is involved in SIP/SIMPLE the IM user compiles the message specifying the presence information, for which the message is delivered by the IM server to the other user where the IM server retains the message and delivers the instant message after the recipient user presence encounters as specified in the compiled message. When the means using an IM server is involved in SIP/SIMPLE a header field "Event-To-Deliver-IM" is involved which is adapted to identify and deliver the IM as per sender's request and contains the parameters presence-name and max-wait-time. The max-wait-time parameter of Event-To-Deliver-IM header field value indicates the duration the IM is stored by the server before delivery, when the presence condition is not met. The value of the said parameter is a number, indicated in seconds and if the parameter is not provided, the value of the Expires header field determines the duration the IM is stored.
Accordingly, this invention further explains a method for user presence based instant message delivery over IMPS or SIP/SIMPLE comprising the step of:
(a) using an originating client where the originating client facilitates the user to deliver the message at the appropriate time and providing flexibility to the user; and/or
(b) using an IM server where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client.
When using an originating client in IMPS the client allows the user to specify the recipient user presence attributes for which the messages are delivered in the SendMessageRequest. The originating user specify a MaxWaitTime along with the

user presence attributes, for the tolerance of message delivery where the MaxWaitTime indicates the maximum waiting time required for the IMPS client before it sends the instant messages. The IMPS client allows the user to specify those recipients' presence information that were authorized. The originating IMPS client attempts to deliver the instant messages, when the recipient user presence is met with the message delivery requirements and if the recipient user has not updated his presence, the IMPS client attempts to deliver the messages once the MaxWaitTime has expired. If the recipient has not logged in, then the compiled messages gets lost and the same is notified to the sender where if the MaxWaitTime is not specified, then the IMPS client maintain the instant messages till the recipient user presence condition is met. If the recipient blocks the originating user from sending the instant messages the message is delivered and the same is indicated to the originating user, if the delivery report is requested. When using an originating client in IMPS the messages with user presence expire if the user presence condition is not met within the expiry period and the messages is not sent. The IMPS client allows the user to compose the message and retain it locally with the user presence and wait time. The IMPS client monitors the updated presence of the targeted recipients. When using an originating client in IMPS the IMPS client sends the message request to IMPS server for the condition met.
When using an originating client in SIP/SIMPLE the client allows the user to specify the recipient user presence attributes for which the messages is delivered in the MESSAGE where the header field in MESSAGE, "Event-To-Deliver-IM" allows the originating user to specify a max-wait-time along with the user presence attributes, for the tolerance of message delivery. The max-wait-time indicates the maximum waiting time required for the IM client before it sends the instant messages to IM server when the recipient user-presence condition is not met where the IM client allows the user to specify only those recipient's presence information that were authorized. The originating IM client attempts to deliver the instant messages, when the recipient user presence is met with the recipient user presence and wait time and if the recipient user does not update his presence, the IM client attempts to deliver the messages once the max-wait-time is expired. If the recipient has not

logged in, then the compiled messages is lost and the same is indicated to the sender and if the max-wait-time is not specified, then the IM client maintains the instant messages till the recipient user presence condition is met. The recipient user blocks the originating user from sending the instant messages where, the messages is not delivered and the same is indicated to the originating user in the response. The messages with user presence expires, if the user presence condition is not met within the expiry period and the messages is not sent. The IM client allows the user to compose the message and retains it locally with the user presence and wait time. The IM client monitors the updated presence of the targeted recipients. The IM client sends the message request to IM server for the condition met.
When using an IM server in IMPS the IMPS server confirm back to the IM client on receiving the message request with user presence and if the IMPS server does not support this, then it returns back a service error indicating the non-support. When using an IM server in IMPS, if the specified user presence in the message request is not authorized by the recipient user, the originating user receive a service error indicating the requirement for authorization by the recipient user for the presence attributes. The IMPS server attempts to deliver the instant messages, when the recipient user presence and wait time are met and while delivering the instant messages / notifications, the conditional attributes user presence and MaxWaitTime are not known to the recipient client. If the recipient user has not updated his presence, the IMPS server attempts to deliver the messages once the MaxWaitTime has expired and if the recipient has not logged in, then the delivered messages is kept as offline. If the offline messages are not supported by the IMPS server, the messages are lost and the same is indicated back to the originating user, if the delivery report is requested where if the MaxWaitTime is not specified, then the IMPS server maintains the instant messages till the recipient user presence condition is not met. In IMPS the recipient user blocks the originating user from sending the instant messages and the messages with user presence attributes are not delivered and the same is indicated to the originating user, if the delivery report is requested. In IMPS the messages with user presence expire, if the user presence

condition is not met and the messages is lost where the same is indicated back to the originating user, if the delivery report is requested. The recipient user over-rides the user presence and MaxWaitTime set by the sender and retrieves the messages. The originating client and IMPS server supports user presence based IM delivery. The originating IMPS Client specifies the presence state and MaxWaitTime in the send or forward message request if it is supported. The information elements, presence state and MaxWaitTime are optional to the message request. The originating user specify the MaxWaitTime along with the user presence, as the instant messages / notifications is delivered for either the user presence attributes or MaxWaitTime expiry, which ever occurs first where the MaxWaitTime is lesser than the message expiry-time and the MaxWaitTime is not specified without specifying the user presence. The originating user is allowed to specify those presence attributes that are authorized by the recipient user, in the message request. In IMPS the IMPS server confirms back the service errors. When using an IM server in IMPS the originating IMPS Client does not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline.
When using an IM server in IMPS the IMPS server return a service error, when the message is delivered for a user presence, which is not authorized for the originating user and if the message is accepted by IMPS server and the user presence is un-authorized before IM delivery, the same is indicated back to the originating user, if the delivery report is requested. When using an IM server in IMPS the IMPS server consider the messages with user presence, as offline messages, when the recipient client is not logged in and the same is indicated back to the originating user, if the delivery report is requested where if the offline messaging is not supported, then the messages is lost. When using an IM server in IMPS the IMPS server delivers the instant messages with the user presence, when the recipient user attempts to block the originating user and any outstanding messages sent by the originating user is not delivered, if the originating user is blocked where the same is indicated back to the originating user, if the delivery report is requested. The IMPS server does not deliver those instant messages with the user presence that are expired and the same is indicated back to the originating user, if the

delivery report is requested. The recipient user is allowed to view any outstanding messages / notifications that are not appropriate to the current user presence.
When using an IM server in SIP/SIMPLE the server receives the request and the IM is delivered only after the condition is met and the server stores the message and monitors the presence change of the recipient user where the server delivers the instant messages, when the message delivery requirements, recipient user presence and maximum wait time are met. While delivering the instant messages / notifications, the conditional attributes, user presence and max-wait-time are not known to the recipient client and if the recipient user has not updated his presence, the IM server attempts to deliver the messages once the max-wait-time has expired.
If the recipient has not logged in, then the delivered messages is kept as offline and if the offline messages are not supported by the IM server, then the messages are lost and the same is indicated back to the originating user in the response. If the max-wait-time is not specified, then the IM server maintains the instant messages till the recipient user presence condition is not met. The recipient user blocks the originating user from sending the instant messages and the messages with user presence attributes are not delivered and the same is indicated to the originating user in the response. The messages with user presence expires if the user presence condition is not met and the messages are lost and the same is indicated back to the originating user in the response. The originating Client and IM Server supports the user presence based IM delivery. The originating IM Client specifies the presence state and max-wait-time in MESSAGE. When using an IM server in SIP/SIMPLE the header field "Event-To-Deliver-IM" is optional in the MESSAGE request. The originating user specify the max-wait-time along with the user presence, for delivering the instant messages for either the user presence attributes or max-wait-time expiry, which ever occurs first where the max-wait-time is always lesser than the message expiry-time and the max-wait-time is not specified without specifying the user presence. The originating user is allowed to specify those presence attributes that are authorized currently by the recipient user, in the

message request. The originating IM Client does not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline. When using an IM server in SIP/SIMPLE the IM Server does not deliver the instant messages with the user presence, when the recipient user blocks the originating user any outstanding messages sent by the originating user is not delivered, if the originating user is blocked where the same is indicated back to the originating user in the response. When using an IM server in SIP/SIMPLE the IM Server does not deliver those instant messages that are expired and the same is indicated back to the originating user in the response.
The other objects, features and advantages of the present invention will be more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS
Figure 1 illustrates the Conventional Instant Messaging scenario
Figure 2 illustrates a User presence based IM delivery - Originating Client based solution in IMPS technology
Figure 3 illustrates a User presence based IM delivery - Originating Client based solution in SIP/SIMPLE technology
Figure 4 illustrates a User presence based IM delivery -Server based solution in IMPS technology
Figure 5 illustrates a User presence based IM delivery -Server based solution in SIP/SIMPLE technology

DETAILED DESCRIPTION OF THE INVENTION
A preferred embodiment of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiment is merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail.
Structure of the Invention
User presence based IM delivery - Originating Client based solution in IMPS and SIP/SIMPLE technologies
The IM user compiles the message specifying the user presence information, for which the message needs to be delivered by the originating client to the other IM user. The originating IM client retains the message and attempts to deliver the instant message only after the recipient's user presence encounters as specified in the compiled message.
This invention applies to generic instant messaging, feasible in systems like IMPS and SIP/SIMPLE.
User presence based IM delivery - Server based solution in IMPS technology
The IM user compiles the message specifying the presence information, for which the message needs to be delivered by the IMPS server to the other user. The IMPS server retains the message and attempts to deliver the instant message only after the recipient user presence encounters as specified in the compiled message.

Primitive and Information Elements

User presence based IM delivery - Server based solution in SIP/SIMPLE technology
The IM user compiles the message specifying the presence information, for which the message needs to be delivered by the IM server to the other user. The IM server retains the message and attempts to deliver the instant message only after the recipient user presence encounters as specified in the compiled message.
The invention involves adding a new header field "Event-To-Deliver-IM" to the MESSAGE method, which is detailed in IETF RFC 3428. It is defined as an optional field.
Event-To-Deliver-IM:
The Event-To-Deliver-IM header field serves as a way to identify and deliver the IM as per sender's request. It consists of parameters presence-name and max-wait-time.
The max-wait-time parameter of Event-To-Deliver-IM header field value indicates how long the IM needs to be stored by the server before delivery, if the presence condition is not met. The value of the parameter is a number, indicated in seconds. If this parameter is not provided, the value of the Expires header field determines how long the IM is stored.
Example:
Event-To-Deliver-IM: presence; presence-name=value;max-wait-time=seconds

Example Message
The message flow shows an initial IM sent from User 1 to User 2, both users in the
same domain, "domain", through a single proxy.

Message F1 looks like:
MESSAGE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com;branch=29hG4bK776sgdkse
Max-Fon/vards: 70
From: sip:user1 ©domain.Gom;tag=49583
To: sip:[email protected]
CalMD: [email protected]
CSeq: 1 MESSAGE
Event-To-Deliver-IM: presence;
presence-name=value;max-wait-time=seconds
Content-Type: text/plain

Content-Length: 18
Watson, come here.
Message F2 looks like:
MESSAGE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP proxy.domain.coni;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4 Max-FonA/ards: 69
From: sip:[email protected];tag=49394 To: sip:[email protected] Call-ID: [email protected] CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18
Watson, come here.
Message F3 looks like:
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
received=192.0.2.1 Via: S1P/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;
received=1.2.3.4 From: sip:[email protected];tag=49394 To: sip:[email protected];tag=ab8asdasd9 CaIND: [email protected] CSeq: 1 MESSAGE Content-Length: 0

Message F4 looks like:
SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4 From: sip:user1 ©domain.com;;tag=49394 To: sip:[email protected];tag=ab8asdasd9 Call-ID: [email protected] CSeq: 1 MESSAGE Content-Length: 0
Operation of the invention
The invention applies to generic instant messaging system. Below the operation is explained for systems like IMPS and SIP/SIMPLE.
User presence based IM delivery - Originating Client based solution in IMPS
technology
Figure 2: User presence based IM delivery - Originating Client based solution
in IMPS technology
1. John logs in to the IMPS server.
2. Service Provider confirms John's login request.
3. John drafts & stores the instant messages request with the user presence state for the delivery to Peter.
4. Later Peter changes his presence state to available & Peter's IMPS client notifies the presence state to IMPS server.
5. IMPS server confirms back to Peter's IMPS Client about this change in presence state.
6. IMPS server notifies Peter's availability to John (IMPS Client).
7. John's IMPS client confirms the presence notification.

8. John's IMPS Client initiates the send / forward message request to IMPS server, for those messages stored in the IMPS client, once the presence condition is met.
9. IMPS server confirms back with Status primitive.
10. IMPS server pushes / notifies the message to recipient's IMPS client.
11. Recipient's IMPS client confirms back to IMPS server with status primitive.
User Presence based IM delivery should be supported by the IMPS client. If supported by the IMPS client, the client must allow the user to specify the recipient user presence attributes for which the messages need to be delivered in the SendMessageRequest method. The originating user may also specify a MaxWaitTime along with the user presence attributes, for the tolerance of message delivery. The MaxWaitTime indicates the maximum waiting time required for the IMPS client before it sends the instant messages to IMPS server, if the recipient user-presence condition does not meet. The IMPS client should allow the user to specify only those recipients' presence information that were authorized before.
The originating IMPS client must attempt to deliver the instant messages, when the recipient user presence is met with the message delivery requirements (recipient user presence, wait time). If the recipient user has not updated his presence, the IMPS client should attempt to deliver the messages once the MaxWaitTime has expired. If the recipient has not logged in, then the compiled messages may be lost and the same is notified to the sender. If the MaxWaitTime is not specified, then the IMPS client should maintain the instant messages till the recipient user presence condition is met.
The recipient user may have blocked the originating user from sending the instant messages. In such conditions, the messages would not be delivered and the same may be indicated to the originating user, if the delivery report is requested.

The messages with user presence could expire, if the user presence'condition is not met within the expiry period. In such cases, the messages would not be sent.
In order to achieve the user presence based IM delivery, the originating IMPS client has the following requirements:
1. IMPS client allows the user to compose the message and retain it locally with the conditions (user presence and wait time) mentioned.
2. IMPS client monitors the updated presence of the targeted recipients.
3. IMPS client attempts to the send the message request to IMPS server for the condition met.
User presence based IM delivery - Originating Client based solution in SIP/SIMPLE technology
Figure 3: User presence based IM delivery - Originating Client based
solution in SIP/SIMPLE technology
1. John drafts & stores the instant messages request with the user presence state for the delivery to Peter.
2. Later Peter changes his presence state to available & Peter's IM client notifies the presence state to Server.
3. Server confirms back to Peter's Client about this change in presence state.
4. Server notifies Peter's availability to John (IM Client).
5. John's client confirms the presence notification.
6. John's IM Client initiates the MESSAGE request to server, for those messages stored in the IM client, once the presence condition is met.
7. Server forwards the MESSAGE request to recipient's IM client.
8. MESSAGE is received by the Peter's client and acknowledged.
9. The response is then forwarded to John's client.

User Presence based IM delivery should be supported by the IM client. If supported by the IM client, the client must allow the user to specify the recipient user presence attributes for which the messages need to be delivered in the MESSAGE method. New header field in MESSAGE method "Event-To-Deliver-IM" allows the originating user to specify a max-wait-time along with the user presence attributes, for the tolerance of message delivery. The max-wait-time indicates the maximum waiting time required for the IM client before it sends the instant messages to IM server, if the recipient user-presence condition does not meet. The IM client should allow the user to specify only those recipients' presence information that were authorized before.
The originating IM client must attempt to deliver the instant messages, when the recipient user presence is met with the message delivery requirements (recipient user presence, wait time). If the recipient user has not updated his presence, the IM client should attempt to deliver the messages once the max-wait-time has expired. If the recipient has not logged in, then the compiled messages may be lost and the same is indicated to the sender. If the max-wait-time is not specified, then the IM client should maintain the instant messages till the recipient user presence condition is met.
The recipient user may have blocked the originating user from sending the instant messages. In such conditions, the messages would not be delivered and the same may be indicated to the originating user in the response.
The messages with user presence could expire, if the user presence condition is not met within the expiry period. In such cases, the messages would not be sent.
In order to achieve the user presence based IM delivery, the originating IM client has the following requirements:
1. IM client allows the user to compose the message and retains it locally with the conditions (user presence and wait time) mentioned.

2. IM client monitors the updated presence of the targeted recipients.
3, IM client attempts to the send the message request to IM server for the
condition met.
User presence based IM delivery - IM Server based solution in IMPS technology
Figure 4: User presence based IM delivery - Server based solution in
IMPS technology
1. John logs in to the IMPS server.
2. Service Provider confirms the John's login request.
3. John sends instant messages with the presence state for the delivery to Peter.
4. Service Provider confirms back to John with the status primitive.
5. John logs out from the IMPS server.
6. Service Provider confirms back to log out request.
7. Peter changes his presence state and the recipient's client notifies the change to IMPS server.
8. Service Provider confirms back to Peter about this change in presence state.
9. IMPS server delivers the message(s)/notification(s) available for this presence state to Peter.
10. Peter's IMPS Client confirms back to this delivery of message(s) / notification(s).
User Presence based IM delivery should be supported both by the IM client and IMPS server. If supported by the IM client, the originating client must allow the user to specify the recipient user presence attributes for which the messages need to be delivered through SendMessageRequest. The originating user may also specify a MaxWaitTime along with the user presence attributes, for the tolerance of message

delivery. The MaxWaitTime indicates the maximum waiting time required for the IMPS server before it delivers the instant messages, if the recipient user-presence condition does not meet. However the originating client should not allow the user to specify the user presence or wait time, if the recipient user has not logged in. The IMPS client should allow the user to specify only those recipient's presence information that were authorized before.
On receiving the message request with user presence, the IMPS server is expected to confirm back to the IM client. If the IMPS server does not support this method, then it must return back a service error indicating the non-support of this method. If the specified user presence in the message request is not authorized by the recipient user, then the originating user would receive a service error indicating that the user presence attributes need to be authorized by the recipient user.
The IMPS server must attempt to deliver the instant messages, when the message delivery requirements (recipient user presence, wait time) are met. While delivering the instant messages / notifications, the conditional attributes (user presence, MaxWaitTime) should not be known to the recipient client. If the recipient user has not updated his presence, the IMPS server should attempt to deliver the messages once the MaxWaitTime has expired. If the recipient has not logged in, then the delivered messages should be kept as offline. If the offline messages are not supported by the IMPS server, then the messages would have been lost. The same (recipient has not logged in) has to be indicated back to the originating user, if the delivery report is requested. If the MaxWaitTime is not specified, then the IMPS server should maintain the instant messages till the recipient user presence condition is not met.
The recipient user may have blocked the originating user from sending the instant messages. In such conditions, the messages with user presence attributes would not be delivered and the same needs to be indicated to the originating user, if the delivery report is requested.

The messages with user presence could expire, if the user presence condition is not met. In such cases, the messages would have been lost. The same (message has expired) has to be indicated back to the originating user, if the delivery report is requested.
The recipient user may also over-ride the condition (user presence, MaxWaitTime) set by the sender, and may decide to retrieve the messages.
In order to achieve the user presence based IM delivery, the originating IMPS client and IMPS server has the following requirements:
1. Originating Client and IMPS server should support this user presence based IM delivery method.
2. Originating IMPS Client must be able to specify the presence state and MaxWaitTime in the send or fonrt/ard message request, if the method is supported.
3. The information elements i.e., presence state and MaxWaitTime are optional to the message request. In case the information element Presence-To-Deliver-IM is not present then the message request will be treated as mentioned in the related art above.
Originating user may also specify the MaxWaitTime along with the user presence, so that the instant messages / notifications can be delivered for either the user presence attributes or MaxWaitTime expiry, which ever occurs first. However it is necessary that the MaxWaitTime should always be lesser than the message expiry-time. The MaxWaitTime cannot be specified without specifying the user presence.
4. Originating user should be allowed to specify only those presence attributes that are authorized currently by the recipient user, in the message request.
5. IMPS server must confirm back the service errors, if the IMPS server

does not support this method.
6. Originating IMPS Client should not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline.
7. IMPS server should return a service error, when the message is requested to be delivered for a user presence, which was not authorized for the originating user. If the message is accepted by IMPS server and the user presence is un-authorized before IM delivery then the same should be indicated back to the originating user, if the delivery report is requested.
8. IMPS server may consider the messages with user presence, as offline messages, when the recipient client has not logged in. The same should be indicated back to the originating user, if the delivery report is requested. If the offline messaging is not supported, then the messages would be lost.
9. IMPS server should not deliver the instant messages with the user presence, when the recipient user attempts to block the originating user. Recipient user may be warned of the fact that, any outstanding messages sent by the originating user would not be delivered, if the originating user is blocked. The same should be indicated back to the originating user, if the delivery report is requested.
10JMPS server should not deliver those instant messages (with the user presence) that were expired. The same should be indicated back to the originating user, if the delivery report is requested.
11 The recipient user may be allowed to view any outstanding messages / notifications that are not appropriate to the current user presence.
User presence based IM delivery - IM Server based solution in SIP/SIMPLE technology
Figure 5: User presence based IM delivery - Server based solution in
SIP/SIMPLE technology

1. John drafts and forwards the MESSAGE request with the user presence state for the delivery to Peter.
2. Server stores the IM for the condition to be met or the maximum wait time to expire.
3. Server returns response to John's request as "202 Accepted".
4. Later Peter changes his presence state to available & Peter's IM client notifies the presence state to Server.
5. Server confirms back to Peter's Client about this change in presence state.
6. Server fonA/ards the MESSAGE request to Peter, for those messages stored on the server, once the presence condition is met.
11. MESSAGE is received by the Peter's client and acknowledged.
User Presence based IM delivery should be supported both by the IM client and IM server. If supported by the IM client, the originating client must allow the user to specify the recipient user presence attributes for which the messages need to be delivered, in the MESSAGE method. The originating user may also specify a max-wait-time along with the user presence attribute, for the tolerance of message delivery. The max-wait-time indicates the maximum waiting time required for the IM server before it delivers the instant messages, if the recipient user-presence condition does not meet. The IM client should allow the user to specify only those recipient's presence information that were authorized before. Sender fonA^ards the message to the server.
The server receives this request and recognizes that the IM needs to be delivered only after a condition is met. The server stores the message and monitors the presence change of the recipient user. The server must attempt to deliver the instant messages, when the message delivery requirements (recipient user presence, maximum wait time) are met. While delivering the instant messages / notifications, the conditional attributes (user presence, max-wait-time) should not be known to the recipient client. If the recipient user has not updated his presence, the IM server should attempt to deliver the messages once the max-wait-time has

expired. If the recipient has not logged in, then the delivered messages should be kept as offline. If the offline messages are not supported by the IM server, then the messages would have been lost. The same (recipient has not logged in) has to be indicated back to the originating user in the response. If the max-wait-time is not specified, then the IM server should maintain the instant messages till the recipient user presence condition is not met.
The recipient user may have blocked the originating user from sending the instant messages. In such conditions, the messages with user presence attributes would not be delivered and the same may be indicated to the originating user in the response.
The messages with user presence could expire, if the user presence condition is not met. In such cases, the messages would have been lost. The same (message has expired) has to be indicated back to the originating user in the response.
In order to achieve the user presence based IM delivery, the originating IM client and IM server has the following requirements:
1. Originating Client and IM Server should support this user presence based IM delivery method.
2. Originating IM Client must be able to specify the presence state and max-wait-time in MESSAGE method.
3. The header field "Event-To-Deliver-IM" is optional in the MESSAGE request. In case the header field "Event-To-Deliver-IM" is not present then message request will be treated as mentioned in the related art above.
Originating user may also specify the max-wait-time along with the user presence, so that the instant messages can be delivered for either the user presence attributes or max-wait-time expiry, which ever occurs first. However it is necessary that the max-wait-time should always be lesser

than the message expiry-time. The max-wait-time cannot be specified without specifying the user presence.
4. Originating user should be allowed to specify only those presence attributes that are authorized currently by the recipient user, in the message request.
5. Originating IM Client should not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline.
6. IM Server should not deliver the instant messages with the user presence, when the recipient user attempts to block the originating user. Recipient user may be warned of the fact that, any outstanding messages sent by the originating user would not be delivered, if the originating user is blocked. The same should be indicated back to the originating user in the response.
7. IM Server should not deliver those instant messages (with the user presence) that were expired. The same should be indicated back to the originating user in the response.
The following are some of the advantages of practicing the present invention.
1. Saves user's time, effort.
2. More user flexibility / friendly.
3. Stimulates IM system usability.
4. Increases the revenue opportunity.
5. Automates the user presence based IM delivery.
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be affected therein by one skilled in the art without departing from the scope or spirit of the invention.

Alternative
In order to provide presence based IM delivery from the recipient's perception, it is possible that the recipient User specifies the presence state during which he is not ready to accept the messages. On receiving the message at the client side, the client checks if such a condition is present before presenting the message to the User. If the condition is present the client will delay the message until the recipient changes the presence state. This alternative is applicable in both IMPS and SIP/SIMPLE technology.
The above-presented description is of the best mode contemplated for carrying out the present invention. The manner and process of making and using it is in such a full, clear, concise and exact terms as to enable to any person skilled in the art to which it pertains to make and use this invention. New embodiments in particular, which also lie within the scope of the invention can be created, in which different details of the different examples can in a purposeful way be combined with one another.
This invention is however, susceptible to modifications and alternate constructions from that disclosed above which are fully equivalent. Consequently, it is not the intention to limit this invention to the particular embodiment disclosed. On the contrary, the intention is to cover all modifications and alternate constructions coming within the spirit and scope of the invention as generally expressed by the following claims which particularly point out and distinctly claim the subject matter of the invention.

GLOSSARY OF TERMS AND THEIR DEFINITIONS
IM - Instant Message
IMPS - Instant Messaging and Presence Service
IETF - Internet Engineering Task Force
RFC - Request for Comments
SIP - Session Initiation Protocol
SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions

WE CLAIM
1. A system for user presence based instant message delivery over IMPS or
SIP/SIMPLE comprising:
(a) means using an originating client where the originating client facilitates the user to deliver the message at the appropriate time and providing flexibility to the user; and/or
(b) means using an IM server where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client.

2. A system as claimed in claimed 1 wherein when the means using an originating client is involved the IM user compiles the message specifying the user presence information, for which the message needs to be delivered by the originating client to the other IM user.
3. A system as claimed in claim 1 wherein the originating IM client retains the message and deliver the instant message only after the recipient's user presence encounters as specified in the compiled message.
4. A system as claimed in claim 1 wherein when the means using an IM server is involved in IMPS the IM user compiles the message specifying the presence information, for which the message is delivered by the IMPS server to the other user where the IMPS server retains the message and delivers the instant message after the recipient user presence encounters as specified in the compiled message.
5. A system as claimed in claim 1 wherein when the means using an IM server is involved in SIP/SIMPLE the IM user compiles the message specifying the presence information, for which the message is delivered by the IM server to the other user where the IM server retains the message and delivers the instant

message after the recipient user presence encounters as specified in the compiled message.
A system as claimed in claim 1 wherein when the means using an IM server is involved in SIP/SIMPLE a header field "Event-To-Deliver-IM" is involved which is adapted to identify and deliver the IM as per sender's request and contains the parameters presence-name and max-wait-time.
A system as claimed in claim 1 wherein when the means using an IM server is involved in SIP/SIMPLE the max-wait-time parameter of Event-To-Deliver-IM header field value indicates the duration the IM is stored by the server before delivery, when the presence condition is not met.
A system as claimed in claim 1 wherein when the means using an IM server is involved in SIP/SIMPLE the value of the max-wait-time parameter is a number, indicated in seconds and if the parameter is not provided, the value of the Expires header field determines the duration the IM is stored.
A method for user presence based instant message delivery over IMPS or SIP/SIMPLE comprising the step of:
(a) using an originating client where the originafing client facilitates the user to deliver the message at the appropriate time and providing flexibility to the user; and/or
(b) using an IM server where the IM server facilitates the user to deliver the message at the appropriate time as directed by the originating IM client.
3. A method as claimed in claim 9 wherein when using an originating client in IMPS the client allows the user to specify the recipient user presence attributes for which the messages is delivered in the SendMessageRequest.
1. A method as claimed in claim 9 wherein when using an originating client in

IMPS the originating user specify a MaxWaitTime along with the user presehce attributes, for the tolerance of message delivery where the MaxWaitTime indicates the maximum waiting time required for the IMPS client before it sends the instant messages.
A method as claimed in claim 9 wherein when using an originating client in IMPS the IMPS client allow the user to specify those recipient's presence information that were authorized.
A method as claimed in claim 9 wherein when using an originating client in IMPS the originating IMPS client attempts to deliver the instant messages, when the recipient user presence is met with the message delivery requirements and if the recipient user has not updated his presence, the IMPS client attempts to deliver the messages once the MaxWaitTime has expired.
A method as claimed in claim 9 wherein when using an originating client in IMPS and if the recipient has not logged in, then the compiled messages gets lost and the same is notified to the sender where if the MaxWaitTime is not specified, then the IMPS client maintain the instant messages till the recipient user presence condition is met
A method as claimed in claim 9 wherein when using an originating client in IMPS the IMPS client allows the user to compose the message and retain it locally with the user presence and wait time.
A method as claimed in claim 9 wherein when using an originating client in SIP/SIMPLE the client allows the user to specify the recipient user presence attributes for which the messages is delivered in the MESSAGE where the header field in MESSAGE, "Event-To-Deliver-IM" allows the originating user to specify a max-wait-time along with the user presence attributes, for the tolerance of message delivery.

.A method as claimed in claim 9 wherein when using an originating client in SIP/SIMPLE the max-wait-time indicates the maximum waiting time required for the IM client before it sends the instant messages to IM server when the recipient user-presence condition is not met where the IM client allows the user to specify only those recipient's presence information that were authorized.
.A method as claimed in claim 9 wherein when using an originating client in SIP/SIMPLE the originating IM client attempts to deliver the instant messages, when the recipient user presence is met with the recipient user presence and wait time and if the recipient user does not updated his presence, the IM client attempts to deliver the messages once the max-wait-time is expired.
? A method as claimed in claim 9 wherein when using an originating client in SIP/SIMPLE the IM client allows the user to compose the message and retains it locally with the user presence and wait time.
? A method as claimed in claim 9 wherein when using an originating client in SIP/SIMPLE the IM client sends the message request to IM server for the condition met.
.A method as claimed in claim 9 wherein when using an IM server in IMPS, the IMPS server attempts to deliver the instant messages, when the recipient user presence and wait time are met and while delivering the instant messages / notifications, the conditional attributes user presence and MaxWaitTime are not known to the recipient client.
-A method as claimed in claim 9 wherein when using an IM server in IMPS, if the recipient user has not updated his presence, the IMPS server attempts to deliver the messages once the MaxWaitTime has expired and if the recipient has not logged in, then the delivered messages is kept as offline.
.A method as claimed in claim 9 wherein when using an IM server in IMPS the

recipient user over-rides the user presence and MaxWaitTime set by the sender and retrieves the messages.
LA method as claimed in claim 9 wherein when using an IM server in IMPS the originating IMPS Client specify the presence state and MaxWaitTime in the send or fonward message request if it is supported.
>.A method as claimed in claim 9 wherein when using an IM server in IMPS the information elements, presence state and MaxWaitTime are optional to the message request.
).A method as claimed in claim 9 wherein when using an IM server in IMPS originating user specify the MaxWaitTime along with the user presence, as the instant messages / notifications is delivered for either the user presence attributes or MaxWaitTime expiry, which ever occurs first where the MaxWaitTime is lesser than the message expiry-time and the MaxWaitTime is not specified without specifying the user presence.
^ A method as claimed in claim 9 wherein when using an IM server in IMPS the originating IMPS Client does not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline.
}.A method as claimed in claim 9 wherein when using an IM server in IMPS the recipient user is allowed to view any outstanding messages / notifications that are not appropriate to the current user presence.
J. A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE the server receives the request and the IM is delivered only after the condition is met and the server stores the message and monitors the presence change of the recipient user where the server delivers the instant messages, when the message delivery requirements, recipient user presence and maximum wait time are met.

. A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE while delivering the instant messages / notifications, the conditional attributes, user presence and max-wait-time are not known to the recipient client and if the recipient user has not updated his presence, the IM server attempts to deliver the messages once the max-wait-time has expired.
. A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE if the max-wait-time is not specified, then the IM server maintains the instant messages till the recipient user presence condition is not met.
. A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE the originating IM Client specify the presence state and max-wait-time in MESSAGE .
. A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE the header field "Event-To-Deliver-IM" is optional in the MESSAGE request.
. A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE the originating user specify the max-wait-time along with the user presence, for delivering the instant messages for either the user presence attributes or max-wait-time expiry, which ever occurs first where the max-wait-time is always lesser than the message expiry-time and the max-wait-time is not specified without specifying the user presence.
. A method as claimed in claim 9 wherein when using an IM server in SIP/SIMPLE the originating IM Client does not allow the user to specify the recipient user's presence in the message request, when the recipient user is offline.
.A system for user presence based instant message delivery over IMPS or SIP/SIMPLE substantially as herein described particularly with reference to the drawings.

37. A method for user presence based instant message delivery over IMPS or SIP/SIMPLE substantially as herein described particularly with reference to the drawings.

Documents:

0534-che-2004 abstract duplicate.pdf

0534-che-2004 claims duplicate.pdf

0534-che-2004 description (complete) duplicate.pdf

0534-che-2004 drawings duplicate.pdf

534-che-2004-abstract.pdf

534-che-2004-claims.pdf

534-che-2004-correspondnece-others.pdf

534-che-2004-correspondnece-po.pdf

534-che-2004-description(complete).pdf

534-che-2004-description(provisional).pdf

534-che-2004-drawings.pdf

534-che-2004-form 1.pdf

534-che-2004-form 13.pdf

534-che-2004-form 5.pdf

« Previous Patent

Next Patent »

Patent Number

229604

Indian Patent Application Number

534/CHE/2004

PG Journal Number

13/2009

Publication Date

27-Mar-2009

Grant Date

18-Feb-2009

Date of Filing

09-Jun-2004

Name of Patentee

SAMSUNG INDIA SOFTWARE OPERATIONS PRIVATE LIMITED

Applicant Address

BAGMANE LAKEVIEW, BLOCK 'B', NO. 66/1, BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA, BANGALORE 560 093,

Inventors:

#	Inventor's Name	Inventor's Address
1	NILKANTH LANDGE, MANISH	BAGMANE LAKEVIEW, BLOCK 'B', NO. 66/1, BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA, BANGALORE 560 093,
2	THIRUMALAI ECHAMPADI SESHADRI	BAGMANE LAKEVIEW, BLOCK 'B', NO. 66/1, BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA, BANGALORE 560 093,
3	JAYAWANT PATTAN, BASAVARAJ	BAGMANE LAKEVIEW, BLOCK 'B', NO. 66/1, BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA, BANGALORE 560 093,

PCT International Classification Number

H04L12/02

PCT International Application Number

N/A

PCT International Filing date

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1			NA