Title of Invention

METHOD FOR DETERMINING PRESENCE STATUS OF AN USER

Abstract The present invention pertains to automatic updating the presence information of the user requesting service. It explains a system and a method for enabling the presence client and presence server to update the user presence automatically on behalf of user, upon receiving appropriate indication from the associated services where the user is registered. The method allows the user to configure such a decision on presence update at the client. The system also facilitates defining of pre-programmed messages, which are automatically sent for those users who have not subscribed the presence attributes, upon user's discretion.
Full Text FIELD OF TECHNOLOGY
This invention relates, in general, to the field of mobile communication. Further, this invention relates to various services, which utilize 'Presence' service. More particularly, this invention encompasses a system and method for automatically updating the presence information of the user requesting service of a mobile communication device engaged in communication.
DESCRIPTION OF RELATED ART
User's Presence is a key in the communication circumstances as it could influence the conversation whether it is person-person, telephone call, IM (Instant Message) etc. Hence it would be necessary for either of the communicating users, to know the latest and legitimate presence of the other user as early as possible. Though the user might want to update his legitimate presence at the earliest, it may not be possible for the user to update some of the presence attributes every time manually, especially during time critical situation. If the user attempts to update the presence, he may miss the service, if not attended immediately. For example, while on IM conversation a user may have to attend a voice call and if not attended immediately, he may miss the call. In such circumstances, the presence service could help the user by informing latest presence (Ex: user on a call) to the other user, thereby providing good user experience and hence averting sudden break in conversation over IM. Similar scenario can happen on various presence technologies like OMA based IMPS (Instant Messaging and Presence Service), IETF (Internet Engineering Task Force) based SIP SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) presence technology etc. SIP SIMPLE is governed by Session Initiation Protocol (SIP).
Now consider a scenario where Instant Messaging is the one, which utilizes presence service. A typical transaction flow according to such a situation is detailed below with reference to Figure 1.

1. Harry requests for Sara's presence information.
2. Server returns the requested presence information. E.g. "Available"
3. Harry feels comfortable to start conversation and sends message
4. Server acknowledges.
5. Sara is delivered with new message.
6. Sara's client acknowledges.
7. Sara's replies with a message.
8. Server acknowledges.
9. Harry is delivered with new message.
10. Harry's client acknowledges.
11. Sara receives a voice call. She is unable to tell Harry and other members in the contact list about the same while talking to third person.
12. Harry continues conversation and sends message.
13. Server acknowledges.
14. Sara is delivered with new message.
15. Sara's client acknowledges.
16. Harry waits anticipating response.
17. Harry does not know what is happening on other end and decides to send another message
18. Server acknowledges.
19. Sara is delivered with another new message.
20. Sara's client acknowledges.
21. Harry is still waiting for response from Sara
It is evident form the above that the user who prefers to attend the one service is left handicapped as he/she opts to reply at the cost of loosing the other service. This, in turn, results in the disappointment to one of the users. Currently, there are no means to ascertain the reason for lack of response from other user when conversing on instant message even while the situation is that the said user is actually attending another service. The following are the major drawbacks of the existing art.
1. Non availability of auto updating of presence or inability to continue the

current session
2. Less user flexibility / friendly.
3. Restricts system usability.
With a view to remedy the above flaws in the prior art, the present invention proposes a system wherein it automatically updates presence, on user's behalf, to allow the user to utilize various applications simultaneously.
SUMMARY OF THE INVENTION
The primary object of the invention is, therefore, to provide a system and method for automatically updating the presence while user is unable to update his presence on his own.
It is another object of the invention to provide a method, which enables the presence client and presence server to update the user presence automatically on behalf of user, upon receiving appropriate indication from the associated services where the user is registered.
It is yet another object of the invention to provide a method to define the pre-programmed messages, which are automatically sent on user's discretion for those users who have not subscribed the presence attributes.
It is a further object of the invention to confer a system that can be applied to various services like Instant Messaging, PoC (Push To Talk Over Cellular) etc utilizing presence service, where the system automatically updates presence, on user's behalf
It is again an object of the invention to allow the user to configure the decision on presence update at the client side.

It is also an object of the invention to provide a system that increases the usability of the service and also the user's flexibility & experience.
Accordingly, the invention provides a method for automatically updating the presence information for the other user occupied in conversation and requesting service when the user/mobile phone gets engaged by another communication application, where presence status being monitored by presence client and the automatic updating is enabled by the user, the said method comprising:
(a) sending a pre-programmed message informing other user about the user
attending another communication application;
OR
(b) automatically triggering a presence update message indicating the status of the user from "Available" to "Busy" or vice versa, when the presence client becomes aware that a simultaneous application is in operation; and
(c) notifying the presence update to the said other user after due acknowledgement from server.
Alternately, the invention provides a method for automatically updating the presence information for the other user occupied in conversation and requesting service when the user/mobile phone gets engaged by another communication application, wherein it detects whether any call is in progress by utilizing the telephony events provided by the Operating system and the automatic updating is enabled by the user, the said method comprising:
a) sending a pre-programmed message informing other user about the user
attending another communication application;
OR
b) automatically triggering a presence update message indicating the status of the user from "Available" to "Busy" or vice versa, when the presence client becomes aware that a simultaneous application is in operation; and
c) notifying the presence update to the said other user after due acknowledgement from server.

According to another embodiment of the invention which proposes a method for automatically updating the presence information for the other user occupied in conversation and requesting service when the user/mobile phone gets engaged by another communication application, where presence status being monitored by presence server in which the user request is stored as a rule, and the automatic updating is enabled by the user, the method comprising:
a) sending a pre-programmed message informing other user about the user
attending another communication application;
OR
b) automatically triggering a presence update message indicating the status of the user from "Available" to "Busy" or vice versa, when the presence client becomes aware that a simultaneous application is in operation; and
c) notifying the presence update to the said other user after due acknowledgement from server.
The invention also provides a system for automatically updating the presence information for the other user occupied in conversation and requesting service when the user/mobile phone gets engaged by another communication application.
The other features, objects and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the accompanying drawings.
BRIED DESCRIPTION OF THE ACCOMPANYING DRAWINGS
Figure 1 shows flow for implementing the existing technology.
Figure 2 shows the present invention where client initiates auto update of presence.
Figure 3 shows the present invention where server initiates auto update of presence.

DETAILED DESCRIPTION OF THE INVENTION
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.
According to the invention, monitoring the presence status is performed either by the Presence Server or the Presence Client. User requests for the automatic updating of his presence when he/she is unable to update on his own. This setting needs to be stored in the client for client based solution and on server in case of server based solution.
In the example of Instant Messaging application utilizing the presence service, upon request from the user, the presence client monitors if the user is attending any other application while there is an IM communication open with another user. The presence client then updates the presence appropriately and informs the other user that the user is busy, thus providing good user experience to both the parties. Figure 2 shows the signaling flow when client initiates auto update of presence.
A session between two users, Harry and Sara is illustrated here for SIMPLE based system:
1. Harry requests for Sara's presence information with SUBSCRIBE method to know if Sara is available for conversation like IM or PoC.
2. Server returns the requested presence information in the NOTIFY method about the requested presence attribute. E.g. Sara's availability for

conversation like IM or PoC as "Available".
3. Harry feels comfortable to start conversation and sends message. Harry can use MESSAGE method for pager mode messaging or sends MSRP SEND after the session is established for session mode messaging.
4. There is no acknowledgement in the SIMPLE based system originating from the server.
5. Sara is delivered with new messages in the MESSAGE method or MSRP SEND depending on the mode used by Harry to send messages.
6. Sara's client acknowledges for the messages sent either in pager-mode or in session mode.
7. Sara replies with a message using MESSAGE method for pager mode messaging or MSRP SEND for session mode messaging.
8. There is no acknowledgement in the SIMPLE based system originating from the server.
9. Harry is delivered with the new messages in the MESSAGE method or MSRP SEND.
10. Harry's client acknowledges for the messages sent either in pager-mode or in session mode.
11. Sara receives a voice call/PoC call etc. She is unable to tell Harry the same over MESSAGE or MSRP SEND method while attending the third person.
12. Presence client is aware of simultaneous use of application by the same user from the presence updates by other applications.
13. Presence is updated to 'Busy' by Sara's client in the PUBLISH method, only if requested by Sara earlier.
14. Server acknowledges the update of presence.
15. Harry is notified the latest presence 'Busy' from Sara in the NOTIFY method.
16. Harry's client acknowledges the receipt of presence notification.
17. Harry is aware of Sara's latest presence and can decide on further action.
Similarly the flow of messages for IMPS based system is explained below with reference to Figure 2.
1. Harry requests for Sara's presence information with GetPresenceRequest

method to know if Sara is available for conversation like IM or PoC.
2. Server returns the requested presence information in the PresenceNotificationRequest method about the requested presence attribute. E.g. Sara's availability for conversation like IM as "Available".
3. Harry feels comfortable to start conversation and sends message. Harry can use SendMessageRequest method for sending messages to Sara.
4. Server acknowledges the SendMessageRequest from Harry.
5. Sara is delivered with new messages in the NewMessage method.
6. Sara's client acknowledges for the messages received.
7. Sara replies with a message using SendMessageRequest method.
8. Server acknowledges the SendMessageRequest from Sara.
9. Harry is delivered with the new messages in the NewMessage method.
10. Harry's client acknowledges for the messages received.
11. Sara receives a voice call/PoC call etc. She is unable to tell Harry the same over SendMessageRequest method while attending to the third person.
12. Presence client is aware of simultaneous use of application by the same user from the presence updates by other applications.
13. Presence is updated to 'Busy' by Sara's client in the UpdatePresenceRequest method.
14. Server acknowledges the update of presence.
15. Harry is notified the latest presence 'Busy' from Sara in the PresenceNotificationRequest method.
16. Harry's client acknowledges the receipt of presence notification.
17. Harry is aware of Sara's latest presence and can decide on further action.
The above signal flow has been achieved by pre-programmed messages at the presence client. The presence client sends a request for update presence or sends a pre-programmed message informing about the presence, when the user has occupied in IM conversation with other users and then he attends another communication application. The presence client allows the user to request for automatic updating of presence. [This feature can be canceled by the requested user at any point of time]

The Presence client plays a major role in order to achieve the objectives. There are two methods by which the client can know when to update the presence on behalf of a user. According to the first method, applications like PoC, SIP based call etc act as presence source. So anytime there is publish of presence from the presence source using PUBLISH method in case of SIMPLE based presence applications and UpdatePresenceRequest in case of IMPS based presence system the presence client will be aware of such change in presence. Hence the presence client will come to know if an application is being simultaneously used by the user. As soon as the presence client is aware of simultaneous application in operation, the presence client shall automatically trigger a presence update message say, moving the status of the User Availability from "Available" to "Busy". This update of presence can be done with PUBLISH in SIMPLE based system and UpdatePresenceRequest in IMPS based system. The presence update will trigger presence notifications to be sent to other subscribed users with NOTIFY in SIMPLE based system and PresenceNotificationRequest in IMPS based systems.
In the second method the presence client utilizes the telephony events provided by the OS, to detect whether any call is in progress. Upon detecting the call using the telephony events, the presence client would automatically trigger a presence update message say, moving the status of the User Availability from "Available" to "Busy". This update of presence can be done with PUBLISH in SIMPLE based system and UpdatePresenceRequest in IMPS based system. The presence update will trigger presence notifications to be sent to other subscribed users with NOTIFY in SIMPLE based system and PresenceNotificationRequest in IMPS based systems.
It is to be noted her,e that the telephony events may be available as different APIs on various mobile OS platforms. In both the solufions above, there can be an reverse update of presence say from "Busy" to "Available" again using the method PUBLISH in case of SIMPLE based systems and UpdatePresenceRequest in IMPS system, once the presence client is aware that previously occupied simultaneous

application is released by the user. This update of presence will trigger new notifications to be sent to user in NOTIFY method on SIMPLE based system and PresenceNotificationRequest in IMPS system.
In an alternate solution, upon request from the user, the presence server monitors if the user is attending any other application while there is a communication like IM already open with another user. The presence server then updates the presence appropriately which informs the other user that the user is busy, thus providing good user experience to both the parties.
Now referring to Figure 3. the scenario where server initiates auto update of presence is described.
The flow of messages for SIMPLE based system is explained below with reference to Figure 3, which depicts a session between Harry and Sara
1. Harry requests for Sara's presence information with SUBSCRIBE method to know if Sara is available for conversation like IM or PoC.
2. Server returns the requested presence information in the NOTIFY method about the requested presence attribute. E.g. Sara's availability for conversation like IM or PoC as "Available".
3. Harry feels comfortable to start conversation and sends message. Harry can either use MESSAGE method for pager mode messaging or send MSRP SEND after the session is established for session mode messaging.
4. There is no acknowledgement in the SIMPLE based system originating from the server.
5. Sara is delivered with new messages in the MESSAGE method or MSRP SEND depending on the mode used by Harry to send messages.
6. Sara's client acknowledges for the messages sent either in pager-mode or in session mode.
7. Sara replies with a message using MESSAGE method for pager mode messaging or MSRP SEND for session mode messaging.
8. There is no acknowledgement in the SIMPLE based system originating from

the server.
9. Harry is delivered with the new messages in the MESSAGE method or MSRP SEND.
10. Harry's client acknowledges for the messages sent either in pager-mode or in session mode.
11. Sara receives a voice call/PoC call etc. She is unable to tell Harry the same over MESSAGE or MSRP SEND method while attending the third person.
12. Presence server is aware of simultaneous use of application by the same user from the presence updates by other applications.
13. Presence server updates the presence to 'Busy', only if requested by Sara earlier.
14. Harry is notified the latest presence 'Busy' from Sara in the NOTIFY method.
15. Harry's client acknowledges the receipt of presence notification.
16. Harry is aware of Sara's latest presence and can decide on further action.
Alternately the flow of messages for the IMPS based system is detailed hereunder.
1. Harry requests for Sara's presence information with GetPresenceRequest method to know if Sara is available for conversation like IM or PoC.
2. Server returns the requested presence information in the PresenceNotificationRequest method about the requested presence attribute. E.g. Sara's availability for conversation like IM as "Available".
3. Harry feels comfortable to start conversation and sends message. Harry can use SendMessageRequest method for sending messages to Sara.
4. Server acknowledges the SendMessageRequest from Harry.
5. Sara is delivered with new messages in the NewMessage method.
6. Sara's client acknowledges for the messages received.
7. Sara replies with a message using SendMessageRequest method.
8. Server acknowledges the SendMessageRequest from Sara.
9. Harry is delivered with the new messages in the NewMessage method.
10. Harry's client acknowledges for the messages received.
11. Sara receives a voice call/PoC call etc. She is unable to tell Harry the same over SendMessageRequest method while attending to the third person.

12. Presence server is aware of simultaneous use of application by the same user from the presence updates by other applications.
13. Presence is updated to 'Busy' by the presence server
14. Harry is notified the latest presence 'Busy' from Sara in the PresenceNotificationRequest method.
15. Harry's client acknowledges the receipt of presence notification.
16. Harry is aware of Sara's latest presence and can decide on further action.
Here the auto update of the presence is performed by the presence server, when it receives the trigger from the appropriate service (Ex: SIP Call, PoC Service) about the update of presence attributes (only if the user has requested to do so). In this case the user request is stored as a rule on the presence server.
The Presence Rules are described from the element of the Presence Authorization Rules document as defined by IETF. The child element of any element may include a new child element , which tells whether the presence has to be automatically updated by the presence server.
The data semantics for the child element may be defined as
instructs the Presence Server not to update presence on user behalf
when user accepts simultaneous application.
instructs the Presence Server to update presence on user behalf
when user accepts simultaneous application.
The method to update the value of the element is using the XCAP PUT request. The example below shows how the value of element is updated.

PUT
http://xcap.example.eom/services/pres-rules/users/sip:ronald.underwood@exampl e.com/presrules HTTP/1.1
Content-Length: (...)

true
Note element has to be included in the schema defined for Presence Authorization Rules document.
Other services such as SIP Call, PoC Service etc will act as presence source for the presence server. In such case, the presence server is expected to update the presence attributes and indicates those presence updates for those users who have subscribed for it. In case of voice call the presence server is expected to update this presence attribute with the help of mobile network support.
For example, when the user is currently on an IM conversation where his presence is set as "Available", the presence server may monitor to know about the presence change in PoC specific presence attribute "Currently in at least one PoC Session". Then the presence server is expected to update the IM specific presence attribute to "Busy", whenever the same user is engaged in a simultaneous PoC call. In such a case, the presence update triggers the notifications to the appropriate users who have subscribed for it. These notifications are delivered to the users in the NOTIFY method in case of SIMPLE based presence system and PresenceNotificationRequest in case of IMPS based system.
On presence being automatically updated by the presence server, the client may send a pre-programmed message informing about the presence, when the user has

occupied in IM conversation with other users and then he attends another communication application. This pre-programmed message is sent in the existing methods like MESSAGE method or by MSRP SEND (incase the user is in a session mode conversation) in a SIMPLE based system. In IMPS based system the pre-programmed message can be sent using the existing method SendMessageRequest.
In this method mentioned above, there can be an reverse update of presence say from "Busy" to "Available" again using the method PUBLISH in case of SIMPLE based systems and UpdatePresenceRequest in IMPS system, once the presence client is aware that previously occupied simultaneous application is released by the user. This update of presence will trigger new notifications to be sent to user in NOTIFY method on SIMPLE based system and PresenceNotificationRequest in IMPS system. The presence server thus shows the latest presence to the other users especially who are anticipating the reply, thereby enhances the user experience of both users and allows the users to attend other communication applications on the same device simultaneously.
In summary, the system calls for the following requirements in order to achieve auto update of the presence,
1. The client allows the user to request for automatic updating of presence.
2. The client allows canceling any previous request to automatic updating of presence.
3. The service monitors for the user accepting simultaneous applications.
4. On identifying user accepting simultaneous applications, the service updates the User Availability presence to say, Busy.
5. The client allows storing a pre-programmed short message.
6. On identifying user accepting simultaneous applications, the client sends the pre-programmed message to other users.
It will also be obvious to those skilled in the art that other control methods and apparatuses can be derived from the combinations of the various methods and

apparatuses of the present invention as taught by the description and the accompanying drawings and these shall also be considered within the scope of the present invention. Further, description of such combinations and variations is therefore omitted above. It should also be noted that the host for storing the applications include but not limited to a microchip, microprocessor, handheld communication device, computer, rendering device or a multi function device.
Although the present invention has been fully described in connection with the preferred embodiments thereof with reference to the accompanying drawings, it is to be noted that various changes and modifications are possible and are apparent to those skilled in the art. Such changes and modifications are to be understood as included within the scope of the present invention as defined by the appended claims unless they depart therefrom.






WE CLAIM
1. A method for automatically updating the presence information for the other user
occupied in conversation and requesting service when the user/mobile phone
gets engaged by another communication application, where presence status
being monitored by presence client and the automatic updating is enabled by
the user, the method comprising:
a) sending a pre-programmed message informing other user about the user
attending another communication application;
OR
b) automatically triggering a presence update message indicating the status of the user from "Available" to "Busy" or vice versa, when the presence client becomes aware that a simultaneous application is in operation; and
c) notifying the presence update to the said other user after due acknowledgement from server.
2. A method for automatically updating the presence information for the other user
occupied in conversation and requesting service when the user/mobile phone
gets engaged by another communication application, wherein it detects whether
any call is in progress by utilizing the telephony events provided by the
Operating system and the automatic updating is enabled by the user, the said
method comprising:
a) sending a pre-programmed message informing other user about the user
attending another communication application;
OR
b) automatically triggering a presence update message indicating the status of the user from "Available" to "Busy" or vice versa, when the presence client becomes aware that a simultaneous application is in operation; and
c) notifying the presence update to the said other user after due

acknowledgement from server.
A method as claimed in claims 1 and 2 wherein the conversation / communication service is IM or PoC.
A method as claimed in claims 1 and 2 wherein it applies to the scenarios where the user is unable to update presence on his own in the presence systems based on SIMPLE.
A method as claimed in claims 1 and 2 wherein it applies to the scenarios where the user is unable to update presence on his own in the presence systems based on IMPS.
The method as claimed in claims 1 and 2 wherein the request stored on the client is implementation specific for presenting the feature and allowing user to update the value.
A method as claimed in claims 1 and 2, wherein the presence client allows programming a short message that will be sent to the subscribed users with the existing methods like MESSAGE in pager-mode and MSRP SEND in session mode.
A method for automatically updating the presence information for the other user occupied in conversation and requesting service when the user/mobile phone gets engaged by another communication application, where presence status being monitored by presence server in which the user request is stored as a rule, and the automatic updating is enabled by the user, the said method comprising:
a) sending a pre-programmed message informing other user about the user
attending another communication application; OR

b) automatically triggering a presence update message indicating the status of the user from "Available" to "Busy" or vice versa, when the presence client becomes aware that a simultaneous application is in operation; and
c) notifying the presence update to the said other user after due acknowledgement from server.
The method as claimed in claim 8 wherein the presence source is SIP Call or PoC Service.
.A method as claimed in claim 8, wherein the presence client allows the user to request for automatic updating of presence where the request is stored on the server as a rule in the presence authorization rule document defined by IETF and which can be updated by the user with an XCAP PUT operation.
. A method as claimed in claim 8. wherein the presence client allows canceling any previous request to automatic updating of presence where the request is stored on the server as a rule in the presence authorization rule document defined by IETF and which can be updated by the user with an XCAP PUT operation.
.A method as claimed in claim 8, wherein it applies to the scenarios where the user is unable to update presence on his own in the presence systems based on SIMPLE.
.A method as claimed in claim 8 wherein it applies to the scenarios where the user is unable to update presence on his own in the presence systems based on IMPS.
.A method as claimed in claim 8, wherein the presence client automatically updates the presence with PUBLISH method for example from presence as 'Available' to 'Busy' upon identifying the user accepting simultaneous applications.

The method as claimed in claim 8, wherein the request stored on the client is implementation specific for presenting the feature and allowing user to update the value.
A system for automatically updating the presence information for the other user occupied in conversation and requesting service when the user/mobile phone gets engaged by another communication application, where presence status being monitored by presence client and the automatic updating is enabled by the user.
A system for automatically updating the presence information for the other user occupied in conversation and requesting service when the user/mobile phone gets engaged by another communication application, where presence status being monitored by presence server in which the user request is stored as a rule, and the automatic updating is enabled by the user.
A method for automatically updating the presence information for the other user occupied in conversation and requesting service when the user/mobile phone gets engaged by another communication application, where presence status being monitored by presence client and the automatic updating is enabled by the user, substantially as herein described with reference to the accompanying drawings.
A method for automatically updating the presence information for the other user occupied in conversation and requesting service when the user/mobile phone gets engaged by another communication application, where presence status being monitored by presence server in which the user request is stored as a rule, and the automatic updating is enabled by the user, substantially as herein described with reference to the accompanying drawings.

20. A system for automatically updating the presence information for the other user occupied in conversation and requesting service when the user/mobile phone gets engaged by another communication application, substantially as herein described with reference to the accompanying drawings.

Documents:

1436-CHE-2004 AMENDED CLAIMS 20-06-2013.pdf

1436-CHE-2004 POWER OF ATTORNEY 20-06-2013.pdf

1436-CHE-2004 EXAMINATION REPORT REPLY RECEIVED 20-06-2013.pdf

1436-CHE-2004 EXAMINATION REPORT REPLY RECEIVED 06-05-2013.pdf

1436-CHE-2004 FORM-1 06-05-2013.pdf

1436-CHE-2004 FORM-13 06-05-2013.pdf

1436-CHE-2004 FORM-13 19-06-2006.pdf

1436-CHE-2004 FORM-5 06-05-2013.pdf

1436-CHE-2004 FORM-6 06-05-2013.pdf

1436-CHE-2004 OTHER PATENT DOCUMENT 06-05-2013.pdf

1436-CHE-2004 POWER OF ATTORNEY 06-05-2013.pdf

1436-CHE-2004 AMENDED CLAIMS 06-05-2013.pdf

1436-CHE-2004 AMENDED PAGES OF SPECIFICATION 06-05-2013.pdf

1436-che-2004-abstract.pdf

1436-che-2004-claims.pdf

1436-che-2004-correspondnece-others.pdf

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

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

1436-che-2004-drawings.pdf

1436-che-2004-form 1.pdf

1436-che-2004-form 13.pdf

1436-che-2004-form 5.pdf


Patent Number 258138
Indian Patent Application Number 1436/CHE/2004
PG Journal Number 50/2013
Publication Date 13-Dec-2013
Grant Date 09-Dec-2013
Date of Filing 24-Dec-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 DR.MANOJ CHOUDARY BAGMANE LAKEVIEW, BLOCK 'B' NO.66/1, BAGMANE TECH PARK. C.V.RAMAN NAGAR, BYRASANDRA, BANGALORE-560 093
2 SESHADRI THIRUMALAI ECHAMPADI BAGMANE LAKEVIEW, BLOCK 'B' NO.66/1, BAGMANE TECH PARK. C.V.RAMAN NAGAR, BYRASANDRA, BANGALORE-560 093
3 PATTAN BASAVARAJ JAYAWANT BAGMANE LAKEVIEW, BLOCK 'B' NO.66/1, BAGMANE TECH PARK. C.V.RAMAN NAGAR, BYRASANDRA, BANGALORE-560 093
4 PADMALAYAM NARAYANA KURUP AJITH KUMAR BAGMANE LAKEVIEW, BLOCK 'B' NO.66/1, BAGMANE TECH PARK. C.V.RAMAN NAGAR, BYRASANDRA, BANGALORE-560 093
5 JEEDIGUNTA VENKATAESWAR BAGMANE LAKEVIEW, BLOCK 'B' NO.66/1, BAGMANE TECH PARK. C.V.RAMAN NAGAR, BYRASANDRA, BANGALORE-560 093
6 BALAJI SRINIVAS HOLUR BAGMANE LAKEVIEW, BLOCK 'B' NO.66/1, BAGMANE TECH PARK. C.V.RAMAN NAGAR, BYRASANDRA, BANGALORE-560 093
PCT International Classification Number H04L 12/00
PCT International Application Number N/A
PCT International Filing date
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 NA