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 list> which contains one or more elements. The MAY
include any other attributes from any other namespaces for the purposes of
extensibility.
Each element contains supplementary descriptive information regarding the Deferred Message in question. The element:
1. SHALL include a element representing the size of the stored content;
2. MAY include an element representing the date at which the message expires;
3. MAY include a element representing the Subject header field of the SIP request;
4. SHALL include a element containing:
a) a mandatory element representing the creation time of the message;
b) a mandatory element taken from the "From" header field of the SIP request;
c) a mandatory element taken from the "To" header field of the SIP request always filled if the message is sent to one IM user;
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: ;tag=4442
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="[email protected]>
10
2000-07-15T21:13:00.0Z
carpool tomorrow?

2000-07-09T21:13:00.0Z
[email protected]
[email protected]


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: ;tag=78923
From: ;tag=4442
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: (...)





[email protected]">

10
2000-07-15T21:13:OO.OZ
carpool tomorrow?

2000-07-09T21:13:00.0Z

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 element in the Deferred Message metadata, "status" attribute can have value
"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: ;tag=78923
From: ;tag=4442
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">
10
2000-07-15T21:13:00.0Z; status^ "no-pending-
deletion"

carpool tomorrow?

2000-07-09T21:13:00.0Z

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:


You may lose the messages if not retrieved before tomorrow.

Along with the Server may include other Deferred Message headers like To, From, Date, Subject etc. The new XML structure is defined as new Content-Type "application/deferred-message-deletion-warning+xml".
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: ;tag=78923
From: ;tag=4442
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">
10
2000-07-15T21:13:00.0Z
carpool tomorrow?

2000-07-09T21:13:00.0Z
[email protected]
chariie@example. com

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:
14400 Deferred-message-reminder>
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:

[email protected]">

10
2000-07-15T21:13:00.0Z
carpoo! tomorrow?

2000-07-09T21:13:00.0Z
[email protected]
char)ie@examp!e. com


reference="[email protected]">

18
2000-07-17T21:25:12.0Z
HELP! at home ill, present for me please

2000-07-09T21:25:12. OZ
[email protected]
[email protected]



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:
14400
.
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 is present only in the case where the User has indicated Deferred Messages delivery method as "notify before delivering" and not "Push".
The new element can be used by various applications like IM, PoC, CPM etc.
The proposed new XML element will be part of OMA defined which is used for controlling the delivery of deferred messages.
Structure of OMA defined is shown as below: The XML element contains zero or one element that contains a Boolean type of "active" XML attribute. The "active" attribute indicates whether the messages stored during the offline period of the client are pushed to the client when the client gets on-line. When the user prefers to get the messages pushed the value of the "active" attribute is set to 'true'. The default value of the "active" attribute is 'false' unless other local policies exit. Other elements and attributes from other namespaces MAY be present for the purposes of extensibility; elements and attributes from unknown namespaces MUST be ignored. The element must contain at least one child XML element.
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: (...)


reference="[email protected]!e.com">
10
2000-07-15T21:13:OO.OZ
carpool tomorrow?

2000-07-09T21:13:00.0Z
[email protected]
charlie@example. com


reference-,[email protected]">

18
2000-07-17T21:25:12.0Z
HELP! at home ill, present for me please


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.

Documents:

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

2493-che-2006-drawings.pdf

2493-che-2006-form 1.pdf

2493-che-2006-form 26.pdf

2495-CHE-2006 ABSTRACT.pdf

2495-CHE-2006 CLAIMS.pdf

2495-CHE-2006 CORRESPONDENCE OTHERS.pdf

2495-CHE-2006 DESCRIPTION (COMPLETE).pdf

2495-CHE-2006 FORM 18.pdf

2495-CHE-2006 FORM 5.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:
# Inventor's Name Inventor's Address
1 PATTAN BASAVARAJ JAYAWANT EMPLOYED AT SAMSUNG INDIA SOFTWARE OPERATIONS PVT LTD., HAVING ITS OFFICE AT, BAGMANE LAKEVIEW, BLOCK B' NO.66/1, BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA, BANGALORE-560093, KARNATAKA, INDIA
2 JEEDIGUNTA VENKATESWAR EMPLOYED AT SAMSUNG INDIA SOFTWARE OPERATIONS PVT LTD., HAVING ITS OFFICE AT, BAGMANE LAKEVIEW, BLOCK B' NO.66/1, BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA, BANGALORE-560093, KARNATAKA, INDIA
3 JAE KWON OH EMPLOYED AT SAMSUNG INDIA SOFTWARE OPERATIONS PVT LTD., HAVING ITS OFFICE AT, BAGMANE LAKEVIEW, BLOCK B' NO.66/1, BAGMANE TECH PARK, C V RAMAN NAGAR, BYRASANDRA, BANGALORE-560093, KARNATAKA, INDIA
PCT International Classification Number H04L1/16
PCT International Application Number N/A
PCT International Filing date
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 NA