Title of Invention | METHOD OF SENDING REMINDER ABOUT A DEFERRED MESSAGE IN A SIP BASED MESSAGING APPLICATION |
---|---|
Abstract | The invention relates to the field of messaging applications over SIP. More specifically, the invention describes a method for sending a reminder to a user about a deferred message in a SIP based messaging application. A message sent to an offline user is stored in a server. Each message stored on the server has a specified expiry period. The server sends reminder for the stored messages when the offline user comes online. The invention describes a method for sending reminder to the user about the stored message before expiry of the message. The notification is sent by updating metadata or by sending IP notify message. Further, the invention also describes a method for sending repeated reminders to the user according the user preferences. The repeated reminder is sent by using user preference or by SIP Subscribe method. |
Full Text | FIELD OF THE INVENTION The present invention relates to the field of mobile communications. The invention relates to various OMA developed applications over SIP like Instant Messaging, Push to talk over Cellular and any other future applications like Converged IP Messaging (CPM). This invention relates to those applications where the messages arriving for a User, who is offline (not registered currently), are stored temporarily by the Service Provider. More particularly, the present invention relates to system and method for deferred message expiry reminder. DESCRIPTION OF RELATED ART US Patent titled "a method for holding a message for a recipient" relates to the field of mobile based message delivery. The patent application describes a method for holding a MMS message for a user. A reminder message is sent to the user about the held MMS message indicating the time of expiry for the MMS message. However, the patent application does not describe a method for holding a SIP based message and sending reminder for the same. Existing art for deferred messages: As an example, Figure-1 depicts OMA developed solution for Deferred Messages in SIMPLE IM. Similar solutions exist for other applications like PoC. OMA defined Deferred Message Metadata has the following format: The root element of the Deferred Messages Metadata XML document is include any other attributes from any other namespaces for the purposes of extensibility. Each 1. SHALL include a 2. MAY include an 3. MAY include a 4. SHALL include a a) a mandatory b) a mandatory c) a mandatory 5. SHALL include a "date" attribute representing the date when the message was sent. This attribute SHALL not exceed the precision of the day of the month; 6. SHALL include a "history-reference" attribute representing the complete path and unique identifier of the actual content of the message; The flow diagram in Figure-1 can be briefly explained in the following way: Consider that an offline user (Charlie) gets back on line and receives the following notification indicating that there are two text messages waiting to be retrieved: While a user (Charlie) is offline: Step 1- Step 2. Alice sends an IM with SIP MESSAGE method, the Message is accepted by Charlie's Message Server and stored with a unique Identifier Step 2- Step 9. Joe sends an IM using SIP INVITE, the Message is accepted by Charlie's Message Server (Message Store), and stored with a unique identifier While Charlie gets back online: Step 10- Step 13. Charlie gets notification via SIP SUBSCRIBE/NOTIFY of the summary of the stored messages waiting to be retrieved. Message headers such as To, From, Date, Subject, and Message-ID included for each message. From: Date: Mon, 10 Jul 2000 04:28:53 GMT Contact: Call-ID: adsf0923jsdjw CSeq: 31 NOTIFY Subscription-State: active;expires=600000 Event: ua-profile Content-Type: application/vnd.oma.deferred+xml Content-Length: (...) 2. Let us assume that Charlie does not want to retrieve immediately and hence defers further. 3. Some of the messages waiting for retrieval are expired and hence Server deletes those messages. Let us assume message from Alice is expired and deleted. 16-17, Charlie gets updated notification via SIP NOTIFY of the deleted messages. Message headers such as To, From, Date, Subject, and Message-ID included for each message, see below: To: From: Date: Mon, 10 Jul 2000 04:28:53 GMT Contact: Call-ID: adsf0923jsdjw CSeq: 31 NOTIFY Subscription-State: active;expires=600000 Event: ua-profile Content-Type: application/xcap-diff+xml Content-Length: (...) However the technology has following limitations: (.Existing mechanism does not allow User to set reminders II. Existing mechanism does not encourage User to retrieve deferred messages III. User may lose deferred messages when Service Provider deletes deferred messages IV. Poor user experience SUMMARY OF THE INVENTION This invention describes a mechanism for reminding a user about a deferred message before its deletion in the context of SIP based messaging applications like IM, PoC, CPM. When a User is not registered to the Service there can be messages arriving from other Users but cannot be delivered to the User immediately. Such messages are temporarily stored by the Server for later delivery and called as Deferred Messages. When the User registers to the Service, depending on User Preferences, User may either get pushed Deferred Messages directly or receive Notification about the Metadata of Deferred Message. In the latter case, User may either retrieve the Deferred Messages immediately or can defer it further. Depending on the Service Provider policy, Deferred Messages that are temporarily stored on the Server may be deleted by the Server after some period if not retrieved before the Service Provider set temporary storage duration. Also the messages may be deleted by the Server without delivering to the User when the Deferred Messages are Expired before the User retrieves. Hence User may lose some Deferred Messages without being delivered to him. Accordingly the invention explains a method for sending a reminder to a user about a deferred message in a SIP based messaging application where a notification is sent by updating metadata or by sending SIP NOTIFY message and further comprising sending repeated reminder to a user where the repeated reminder is sent by using user preference or by SIP Subscribe method. Accordingly the invention also explains a system for sending a reminder to a user about a deferred message in a SIP based messaging application comprising a means for sending a notification by updating metadata or by sending IP notify message and further comprising means for sending repeated reminder to a user where the repeated reminder is sent by using user preference or by SIP Subscribe method. This invention describes a mechanism for the user to be reminded about deferred messages currently stored on Server or waiting for retrieval, before the message is deleted due to Service Provider policy or its associated expiration time. This invention proposes the method to increase the chances of User retrieving the Deferred Messages and minimize User losing messages either because of Service Provider policy or associated expiration. Reminders can be sent by the Server a. at the time before Service Provider decides to delete them and/or b. after lapse of User set duration for reminders. These and other objects, features and advantages of the present invention will become more apparent from the ensuing detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 depicts OMA developed solution for Deferred Messages in SIMPLE Architecture Figure 2 depicts Server Updating Metadata for the messages that are pending to be deleted and Notifying of such updated Metadata Figure 3 depicts Server Notifying about soon to be deleted messages through SIP MESSAGE Figure 4 depicts User requesting Server to repeat reminder notifications by using SIP SUBSCRIBE Figure 5 depicts User requesting Server to repeat reminder notifications by publishing User Preferences to Server DETAILED DESCRIPTION OF THE PREFRRED EMBODIMENTS The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are 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. This invention describes a mechanism for the user to be reminded about deferred messages currently stored on Server or waiting for retrieval, before the message is deleted due to Service Provider policy or its associated expiration time. This invention proposes the method to increase the chances of User retrieving the Deferred Messages and minimize User losing messages either because of Service Provider policy or associated expiration. Reminders can be sent by the Server a. at the time before Service Provider decides to delete them and/or b. after elapse of User set duration for reminders. Methods for Server sending the warning message before the deletion of the deferred messages in accordance with the present invention include: Method 1. Server Updating Metadata for the messages that are pending to be deleted and Notifying of such updated Metadata Method 2. Server Notifying about soon to be deleted messages through SIP MESSAGE Methods for User requesting for repeat reminder notifications: Method 3. User requesting Server to repeat reminder notifications by using SIP SUBSCRIBE Method 4. User requesting Server to repeat reminder notifications by publishing User Preferences to Server Method 1. Server Updating Metadata for the messages that are pending to be deleted and Notifying of such updated Metadata The invention proposes to add an attribute "status" to the "no-pending-deletion" - default value, meaning there is more time before Server deletes the Deferred Message "pending-deletion" - meaning time is approaching to delete the Deferred Message Service Provider policy will decide on when to change the value of "status" attribute from "no-pending-deletion" to "pending-deletion". When the Deferred Message metadata is created by the Server, the default value for "status" attribute will be "no-pending-deletion". When the time is approaching for deletion of certain Deferred Message, the Server changes the value of "status" attribute from "no-pending-deletion" to "pending-deletion". As this corresponds to the changes in metadata the Server is triggered to send SIP NOTIFY to the User containing the warning about the soon to be deleted Deferred Messages in the "status" attribute. Such new "status" attribute can be defined for various applications like IM, PoC, CPM, etc. As an example, Figure-2 shows the method for Server Updating Deferred Message Metadata for the messages that are pending to be deleted and then sending Notifications. A brief explanation of the flow diagram in Figure-2 is as follows: Consider that an offline user (Charlie), gets back on line and receives the following notification indicating that there are two text messages waiting to be retrieved: While a user (Charlie) is offline: Step 1. Alice sends an IM with SIP MESSAGE method, the Message is accepted by Charlie's Message Server and stored with a unique Identifier Step 2. Joe sends an IM using SIP INVITE, the Message is accepted by Charlie's Message Server (Message Store), and stored with a unique identifier While Charlie gets back online: Step 3- Step 6. Charlie gets notification via SIP SUBSCRIBE/NOTIFY of the summary of the stored messages waiting to be retrieved. Message headers such as To, From, Date, Subject, and Message-ID included for each message. NOTIFY sip:[email protected] SIP/2.0 To: From: Date: Mon, 10 Jul 2000 04:28:53 GMT Contact: Call-ID: adsf0923jsdjw CSeq: 31 NOTIFY Subscription-State: active;expires=600000 Event: ua-profile Content-Type: application/vnd.oma.deferred+xml Content-Length: (...) reference="32098d@mailserver. example. com"> deletion" Step 7. Let us assume that Charlie does not want to retrieve immediately and hence defers further. Some of the messages waiting for retrieval are nearing to expire and hence Server updates the metadata of those messages i.e., "status" attribute value is changed from "no-pending-deletion" to "pending-deletion". In this example say, "status" attribute value of message from Alice is changed from uno- pending-deletion" to "pending-deletion". Step 8. Charlie gets updated notification via SIP SUBSCRIBE/NOTIFY for the messages that are pending to deletion. Message headers such as To, From, Date, Subject, and Message-ID included for each message. On receiving such notification, the User is prompted to can take immediate action to retrieve the Deferred Message or else he may lose that particular Deferred message. Server deletes the Deferred Message even if not retrieved by the User. Method 2. Server Notifying about soon to be deleted messages through SIP MESSAGE The invention proposes to define new XML element structure for carrying the warning about the Deferred messages to be deleted soon. This new XML element is carried as a body in the SIP MESSAGE method. Below is the proposal for new XML structure: Along with Warning carried in the SIP MESSAGE method is sent, allowing reasonable time for the User to retrieve Deferred Messages. It is up to Service Provider policy discretion to decide what time is to be considered as reasonable time frame. Such warning can be sent irrespective of applications like IM, PoC, CPM etc. As an example, Figure 3 shows the method for Server Notifying about soon to be deleted messages through SIP MESSAGE. The warning carried in SIP MESSAGE can be sent by the Server outside the existing dialog. A brief explanation of the flow diagram in Figure 3 is as follows: Consider that an offline user (Charlie), gets back on line and receives the following notification indicating that there are two text messages waiting to be retrieved: While a user (Charlie) is offline: Step 1. Alice sends an IM with SIP MESSAGE method, the Message is accepted by Charlie's Message Server and stored with a unique Identifier Step 2. Joe sends an IM using SIP INVITE, the Message is accepted by Charlie's Message Server (Message Store), and stored with a unique identifier While Charlie gets back online: Step 3- Step 6. Charlie gets notification via SIP SUBSCRIBE/NOTIFY of the summary of the stored messages waiting to be retrieved. Message headers such as To, From, Date, Subject, and Message-ID included for each message. To: From: Date: Mon, 10 Jul 2000 04:28:53 GMT Contact: Call-ID: adsf0923jsdjw CSeq: 31 NOTIFY Subscription-State: active;expires=600000 Event: ua-profile Content-Type: application/vnd.oma.deferred+xml Content-Length: (...) Step 7. Let us assume that Charlie does not want to retrieve immediately and hence defers further. Some of the messages waiting for retrieval are nearing to expire and hence Server decides to send warning message that some of the Deferred Messages will be deleted soon. Step 8. Charlie gets updated notification via SIP SUBSCRIBE/NOTIFY (IETF RFC 3842) for the messages that are pending to deletion. Deferred Message headers such as To, From, Date, Subject, and Message-ID may also be included for each message in the new XML Content-Type: On receiving such notification, the User is prompted to can take immediate action to retrieve the Deferred Message or else he may lose that particular Deferred message. Server deletes the Deferred Message even if not retrieved by the User. Method 3. User requesting Server to repeat reminder notifications bv using SIP SUBSCRIBE The invention proposes to add new XML element for allowing User to request the reminder duration. This new XML element is carried in the body of SIP SUBSCRIBE when the Client is requesting for Deferred Message Metadata. Below is the proposal for new XML structure: The duration element contains the amount of time, in seconds, to send notifications since the SIP SUBSCRIBE request received by the Server. "repeat" attribute tells the Server whether to send repeat notification or not Server sends the repeat SIP NOTIFY after the duration requested by the User elapses. The new XML structure is defined as new Content-Type "application/deferred-message-reminder+xml". Alternately, the reminder request can also be carried as a new event state parameter. E g., Event: ua-profile; deferred-message-reminder=14400 The above specified reminder request can be sent in various applications like IM, PoC, CPM etc. As an example, Figure-4 shows the method for User requesting Server to repeat reminder notifications by using SIP SUBSCRIBE. A brief explanation of the flow diagram in Figure-4 is as follows: Consider that an offline user (Charlie), gets back on line and receives the following notification indicating that there are two text messages waiting to be retrieved: While a user (Charlie) is offline: Step 1. Alice sends an IM with SIP MESSAGE method, the Message is accepted by Charlie's Message Server and stored with a unique Identifier Step 2. Joe sends an IM using SIP INVITE, the Message is accepted by Charlie's Message Server (Message Store), and stored with a unique identifier While Charlie gets back online: Step 3. Charlie chooses to receive the reminder after every 4 hours Step 4- Step 5. Charlie's Client requests subscription to Deferred Message Metadata via SIP SUBSCRIBE with deferred message reminder request in content format defined by "application/deferred-message-deletion-warning+xmr. The new content type is carried as a multipart body in the SIP SUBSCRIBE request. See below: Alternately, Step 4 - Step 5. When the Deferred Message Reminder is carried as a new event state parameter, Charlie's Client requests subscription to Deferred Message Metadata via SIP SUBSCRIBE with deferred message reminder request in Event header. See below: Step 6 - Step 7. Charlie gets notification via SIP NOTIFY of the summary of the stored messages waiting to be retrieved. Message headers such as To, From, Date, Subject, and Message-ID included for each message, see below: Step 8. Let us assume that Charlie does not want to retrieve immediately and hence defers further. After the User requested duration has elapsed from the time the previous SIP NOTIFY was sent, the Server decides to send the repeat notification. Note that if the User has retrieved all the Deferred Messages, the Server will not send the repeat notification. Step 9- Step 10. Same as Step 6, Step 70n receiving such repeat notifications, the User is prompted to take an immediate action to retrieve the Deferred Message or else he may lose that particular Deferred message. Method 4. User requesting Server to repeat reminder notifications by publishing User Preferences to Server The invention proposes to add new XML element for allowing User to request the reminder duration. This new XML element is carried in the body of SIP PUBLISH when the Client is publishing Service Settings or User Preferences to the Server. Below is the proposal for new XML structure: The duration element contains the amount of time, in seconds, to send notifications since the SIP SUBSCRIBE request received by the Server. "repeat" attribute tells the Server whether to repeat notification every reminder duration or not. Server sends the repeat SIP NOTIFY after the duration for reminder elapses. Note that the new element The new element The proposed new XML element will be part of OMA defined Structure of OMA defined As an example, Figure-5 shows the method for User requesting to repeat reminder notifications by using User Preferences. A brief explanation of the flow diagram in Figure-5 is as follows: Consider that an offline user (Charlie), gets back on line and receives the following notification indicating that there are two text messages waiting to be retrieved: While a user (Charlie) is offline: Step 1. Alice sends an IM with SIP MESSAGE method, the Message is accepted by Charlie's Message Server and stored with a unique Identifier Step 2. Joe sends an IM using SIP INVITE, the Message is accepted by Charlie's Message Server (Message Store), and stored with a unique identifier While Charlie gets back online: Step 3. Charlie chooses to receive the reminder after every 4 hours Step 4- Step 5. Charlie's Client publishes Service Settings or User Preferences via SIP PUBLISH. See below: Step 6- Step 7. Charlie subscribes for deferred message metadata via SIP SUBSCRIBE Step 8- Step 9. Charlie gets notification via SIP NOTIFY of the summary of the stored messages waiting to be retrieved. Message headers such as To, From, Date, Subject, and Message-ID included for each message, see below: Event: ua-profile Content-Type: application/ vnd.oma.deferred+xml Content-Length: (...) Step 10. Let us assume that Charlie does not want to retrieve immediately and hence defers further. After the User requested duration has elapsed from the time the previous SIP NOTIFY was sent, the Server decides to send the repeat notification. If the User has retrieved all the Deferred Messages, the Server will not send the repeat notification. Step 11- Step 12. Repeat Step8, Step 9. On receiving such repeat notifications, the User is prompted to can take an immediate action to retrieve the Deferred Message or else he may lose that particular Deferred message. ADVANTAGES 1. Invention allows the User to set reminders 2. Encourages User to retrieve Deferred Messages - thus giving more revenue to Service Provider 3. Reduces the chances of User losing some important messages (without warning) 4. Good user experience 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. GLOSSARY OF TERMS AND DEFINITIONS THEREOF OMA - Open Mobile Alliance SIP - Session Initiation Protocol IM - Instant Messaging PoC - Push to Talk Over Cellular XML - Extended Markup Language XDM - XML Document Management XCAP - XML Configuration Access Protocol SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions. MMS - Multimedia Messaging Service CPM - Converged IP Messaging IETF - The Internet Engineering Task Force RFC - Request For Comments We Claim: 1. A method for sending a reminder to a user about a deferred message in a SIP based messaging application where a notification is sent by updating metadata through SIP NOTIFY message and further comprising sending repeated reminder to a user where the repeated reminder is sent by using user preference or by SIP Subscribe method. 2. The method as claimed in claim 1 further comprising the steps of the server Updating Metadata for messages that are pending to be deleted and Notifying of such updated Metadata. 3. The method as claimed in claim 2 wherein an attribute "status" is added in the Deferred Message metadata where "status" attribute can have value "no- pending-deletion", meaning there is more time before Server deletes the Deferred Message or "pending-deletion" , meaning time is approaching to delete the Deferred Message. 4. The method as claimed in claim 1 further comprising the server Notifying about soon to be deleted messages through SIP MESSAGE where new XML element structure is defined for carrying the warning about the Deferred messages to be deleted soon wherein the new XML element is carried as a body in the SIP MESSAGE method. 5. The method as claimed in claim 4 wherein warning carried in the SIP MESSAGE method is sent, allowing reasonable time for the User to retrieve Deferred Messages. 6. The method as claimed in claim 1 further comprising the User requesting Server to repeat reminder notifications by using SIP SUBSCRIBE. 7. The method as claimed in claim 6 wherein a new XML element is added for allowing User to request the reminder duration where the new XML element is carried in the body of SIP SUBSCRIBE when a Client is requesting for Deferred Message Metadata. 8. The method according to claim 7 wherein the duration element contains the amount of time, to send notifications since the SIP SUBSCRIBE request received by the Server and wherein a "repeat" attribute tells the Server whether to send repeat notification or not. 9. The method as claimed in claim 1 further comprising the User requesting Server to repeat reminder notifications by publishing User Preferences to Server. 10. The method as claimed in claim 9 wherein a new XML element is added for allowing User to request the reminder duration where the new XML element is carried in the body of SIP PUBLISH when the Client is publishing Service Settings or User Preferences to the Server. 11. A system for sending a reminder to a user about a deferred message in a SIP based messaging application comprising a means for sending a notification by updating metadata or by sending SIP NOTIFY message and further comprising means for sending repeated reminder to a user where the repeated reminder is sent by using user preference or by SIP Subscribe method. 12. A method for sending a reminder to a user about a deferred message in a SIP based messaging application substantially described particularly with reference to the accompanying drawings. 13. A system for sending a reminder to a user about a deferred message in a SIP based messaging application substantially described particularly with reference to the accompanying drawings. |
---|
2493-CHE-2006 AMENDED PAGES OF SPECIFICATION 26-07-2013.pdf
2493-CHE-2006 AMENDED CLAIMS 26-07-2013.pdf
2493-CHE-2006 EXAMINATION REPORT REPLY RECEIVED 26-07-2013.pdf
2493-CHE-2006 FORM-1 26-07-2013.pdf
2493-CHE-2006 FORM-13 26-07-2013.pdf
2493-CHE-2006 FORM-3 26-07-2013.pdf
2493-CHE-2006 OTHER PATENT DOCUMENT 26-07-2013.pdf
2493-CHE-2006 POWER OF ATTORNEY 26-07-2013.pdf
2493-CHE-2006 FORM-13 25-06-2007.pdf
2493-che-2006-correspondnece-others.pdf
2493-che-2006-description(provisional).pdf
2495-CHE-2006 CORRESPONDENCE OTHERS.pdf
2495-CHE-2006 DESCRIPTION (COMPLETE).pdf
Patent Number | 256892 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Indian Patent Application Number | 2493/CHE/2006 | ||||||||||||
PG Journal Number | 33/2013 | ||||||||||||
Publication Date | 16-Aug-2013 | ||||||||||||
Grant Date | 07-Aug-2013 | ||||||||||||
Date of Filing | 29-Dec-2006 | ||||||||||||
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-560093, KARNATAKA, INDIA | ||||||||||||
Inventors:
|
|||||||||||||
PCT International Classification Number | H04L1/16 | ||||||||||||
PCT International Application Number | N/A | ||||||||||||
PCT International Filing date | |||||||||||||
PCT Conventions:
|