Title of Invention

METHOD AND APPARATUS TO ACCOMPLISH SESSION INITIATION PROTOCOL (SIP) MESSAGES IN A SIP FRAMEWORK

Abstract

This invention in general relates to SI P technology. More particularly this invention relates to sending the System Messages to various SIP based service subscribers like Instant Messaging (1M), Push-to- Talk Over Cellular (PoC), Multimedia Messaging (MMS) and any other SIP based services hosted by the Service Provider. System Message is a special type of message sent by the System for different purposes (e.g. advice of charge, service notifications, warnings, instructions, etc). System Messages may contain a list of possible options and require a response from the user. This invention explains a system and method to accomplish system messaging in SIP by introducing a new content in the form of MIME body and a new feature tag to the existing SIP framework, for sending service specific information and receiving the user response.

Full Text

FIELD OF THE INVENTION This invention in general relates to SIP technology. More particularly this invention relates to sending the System Messages to various SIP based service subscribers like Instant Messaging (IM), Push-to-Talk Over Cellular (PoC), Multimedia Messaging (MMS) and any other SIP based services hosted by the Service Provider. System Message is a special type of message sent by the System for different purposes (e.g. advice of charge, service notifications, warnings, instructions, etc). System Messages may contain a list of possible options and require a response from the user. DESCRIPTION OF RELATED ART MESSAGE Method - SIP Extension RFC 3428: RFC 3428 proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. The Message Session Relay Protocol (draft-ietf-simple-message-sessions-11 .txt): Message Session Relay Protocol is a protocol for transmitting a series of related instant messages in the context of a session. MSRP is a text-based, connection-oriented protocol for exchanging arbitrary (binary) MIME content, especially instant messages. SIP INFO Method - RFC 2976: The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. Currently there is no method identified to comprehend the System Message requirements as listed in the prior art above. 1. MESSAGE method as exists in IETF RFC 3428, does not support a technique a. to get response from Client and associate it with the request from the Server b. to differentiate normal messages from the System Message c. to identify type of response expected by the Server from the Client d. to wait for a specified duration in case Server is expecting a response from the Client e. to give user friendly service level access control which is requisite from the Server 2. MSRP SEND method exists in IETF draft "The Message Session Relay Protocol", does not support a technique a. to differentiate normal messages from the System Message b. to identify type of response expected by the Server from the Client c. to wait for a specified duration in case Server is expecting a response from the Client d. to give user friendly service level access control which is requisite from the Server 3. SIP INFO method exists in IETF RFC 2976, does not support a technique a. to differentiate normal messages from the System Message b. to identify type of response expected by the Server from the Client c. to wait for a specified duration in case Server is expecting a response from the Client d. to give user friendly service level access control which is requisite from the Server SUMMARY OF THE INVENTION System Message is a special type of message sent by the System for different purposes (e.g. advice of charge, service notifications, warnings, instructions, etc). System Messages may contain a list of possible options and require a response from the user. This invention proposes a solution to comprehend various System Message requirements by introducing a new content in the form of MIME body, a new feature tag to the existing SIP framework, for sending information and receiving the user response. The method which carries the new content in the form of MIME body could be for example MESSAGE, MSRP SEND, SIP INFO etc. With this invention the Server will be able to send System Messages to its Subscribers, receive response from the Subscribers and decide further action based on the Service Provider policies. Various methods identified to comprehend the System Message requirements: A new feature tag which identifies the support of System Message, carried in a SIP header (for example Accept-Contact) in various SIP methods like MESSAGE, MSRP SEND, SIP INFO etc. A new MIME type which defines the structure of a System Message, carried in a SIP header Content-type in various SIP methods like MESSAGE, MSRP SEND, SIP INFO etc. New XML schema for System Message to be sent as body of the various SIP methods like MESSAGE, MSRP SEND, SIP INFO etc. Various elements in the new schema defined in this invention include smsg-type, smsg, smsg-text, smsg-response-type, answer-options, answer-option-id, answer-option-text, verification, verification-text, verification-uri, time-out, restrict-access, answer, answer-id, answer-text etc Accordingly, this invention explains a method to accomplish system messaging in SIP by introducing a new content in the form of MIME body and a new feature tag to the existing SIP framework, for sending service specific information and receiving the user response. The system messages feature is supported by both Client and Server where the system messages are uniquely identified by the Client and Server, distinguishing the said system messages from other normal messages. The system message is applicable to various SIP based services like IM, PoC, MMS and any other SIP based service. The SIP method which carries the new content type is a MESSAGE, MSRP SEND, INFO or any other appropriate SIP method. A new feature tag "+g.application.smsg" is carried in the SIP header field which is the Accept-Contact header .A new MIME type "vnd.example.system-message+xmt' is carried in the SIP header field which is the Content-type header. The system message request is carried as a body in various SIP methods like MESSAGE, INFO and MSRP SEND. The system message request document begins with the root element consists of element which indicates that system message is of the type "request", which is from server to client. The root element consists of element which contains a unique number in order to associate the response to a system message request. The element enables the system to send more than one system messages at the same time and reduces messaging and signaling overhead and associates the response at server end, which is received at a later time from the client. The root element consists of element which gives information to the client to be rendered to the user. The root element consists of element which indicates user the type of response expected from the user whether it is a "no-answer" or "only-one-answer" or "multiple-answer". When the System Messages sent by the Server is only for the User's information and no response is expected from the User element is a "no-answer". When the System Messages sent by the Server need to know the User's response with only Accept/Refuse element is a "only-one-answer". When the System Messages sent by the Server need to the User's response with multiple answers element is a "multiple-answer". The Server decides on the value in element based on the kind of response required from the User and the Client responds accordingly with the type of response as requested by the Server. The root element consists of an element which gives the User to select the response from a list where each element contains a child element that contains a unique number to identify an answer option and a child element which gives free text answer option. The root element consists of a element to confirm that the User has read the System Message and contains child element either or . The element is used where system provides an alphanumeric code which the user has re-enter in the System Message response. The value of element is URI of the location of code from which user has insert the code in the System Message response. The root element consists of element to indicate the user, duration within which the user response is expected. The root element consists of element, which allows the Server to insist the client to block further access to the service until user responds to a System Message. The system message response is carried as a body in various SIP methods like MESSAGE, INFO and MSRP SEND. The root element consists of element indicating that System Message is of the type "response". The root element consists of element which contains the value contained in the "id" attribute of the element of the System Message Request. The root element consists of element which indicates the User selection from a list of answer options where each element contains child elements and . Multiple are there if the value in element in the System Message request is "multiple-answer" which allows the user to send multiple answers to a request using the same message. The root element consists of element which is defined to confirm that the User has read the System Message where the said element has a child element . Accordingly, this invention explains a system to accomplish system messaging in SIP by introducing a new content in the form of MIME body and a new feature tag to the existing SIP framework, for sending service specific information and receiving the user response. 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 ACCOMPANYING DRAWINGS Figure 1 illustrates System Messages over SIP MESSAGE method. Figure 2 illustrates System Messages over MSRP SEND method. Figure 3 illustrates System Messages over SIP INFO method. Figure 4 illustrates the manner of client X receiving a system message from server X. Figure 5 illustrates the manner of client X sending response system message to server x. DETAILED DESCRIPTION OF THE INVENTION A preferred embodiment of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiment is merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. System Message is a special type of message sent by the System for different purposes (e.g. advice of charge, service notifications, warnings, instructions, etc). System Messages may contain a list of possible options and require a response from the user. The timing to send such messages is up to the service provider policy. The end-user response may be used to influence the service negotiation. This invention proposes a solution to comprehend various System Message requirements by introducing a new content in the form of MIME body, a new feature tag to the existing SIP framework, for sending information and receiving the user response. The method which carries the new content in the form of MIME body could be for example MESSAGE, MSRP SEND, SIP INFO etc. The details of the invention are as described below: Figure 1 illustrates System Messages over SIP MESSAGE method. Figure 2 illustrates System Messages over MSRP SEND method. Figure 3 illustrates System Messages over SIP INFO method. Proposal to SIP method Header field: 1. System Messages feature has to be supported by both Client and Server. Also System Messages have to be uniquely identified by the Client and Server, distinguishing System Messages from the other normal messages. Introducing a new feature tag can help the Server to know if Client supports System Messages or not and also for both the sending and receiving system to uniquely identify a System Message. The new feature tag can be called as say "+g.application.smsg". NOTE: The new feature tag is applicable to any service for eg. IM service, PoC service, MMS service. Media feature-tag name: +g.application.smsg. ASN.1 Identifier: New assignment by IANA. Summary of the media feature indicated by this tag: This feature-tag indicates that the device supports System Messages. Values appropriate for use with this feature-tag: Boolean. The feature-tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: • This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA. Examples of typical use: Routing a System Message to a mobile phone that can support System Messages. The new feature tag has to be registered by the Client during the SIP REGISTER. SIP header field is used to indicate the support of System Messages, for example Accept-Contact header can be used to carry the new feature tag along with 'require' and 'explicit' parameters according to rules and procedures of RFC 3841 "Caller Preferences for the Session Initiation Protocol". The new feature tag has to be used in various SIP methods for System Messages. Irrespective of whether the System Message is sent within a Session or not, SIP MESSAGE method may be used for sending and receiving System Messages. Also SIP INFO and MSRP SEND may be used for sending System Messages during the session. This SIP method carries the new feature tag in the header field, say in the Accept-Contact header along with 'require' and 'explicit' parameters according to rules and procedures of IETF RFC 3841 "Caller Preferences for the Session Initiation Protocol". 2. According to this invention a new MIME type has to be defined for System Messages. The new MIME type for System Messages is uniquely identified, for example with "vnd.example.system-message+xml "content type. This MIME type is used to identify that the SIP method body contains a System Message confirming to a particular schema. NOTE: The new MIME type is applicable to any service for e.g. IM service, PoC service, MMS service. The new MIME type has to be indicated in various SIP methods for System Messages. Irrespective of whether the System Message is sent within a Session or not, SIP MESSAGE method may be used for sending and receiving System Messages. Also SIP INFO and MSRP SEND may be used for sending System Messages during the session. This SIP method carries the new MIME type in the header field, say in the Content-type header. Proposal to SIP method Body: The new MIME type is carried in the body of the various SIP methods during sending and receiving System Messages. The body has to conform to the new schema defined by the new MIME type. Irrespective of whether the System Message is sent within a Session or not, SIP MESSAGE method may be used for sending and receiving System Messages. Also SIP INFO and MSRP SEND may be used for sending System Messages during the session. System Messages are sent to the Subscribers, only when it is necessary, usually first time use etc. So Server maintains a state from which Service Provider will be aware of whom the System Message is already sent and to whom it is yet to send. The new schema is defined to carry System Messages that can be used by the Server to send System Messages and another schema that is used by the Client to respond back to the Server. It is possible to have a single schema which can accomplish both System Message request and System Message response. Structure of the System Message Request document: A System Message Request is an XML document that must be well-formed and has to be valid. System Message Request document is based on XML 1.0 and uses UTF-8 encoding. This invention makes use of XML namespaces for identifying System Message Request documents and document fragments. The namespace URI for elements defined by this specification is a URN, using the namespace identifier 'example'. This URN is: urn:example:params:xml:ns:application:system-message A System Message Request document begins with the root element. It consists of: 1. element indicates that System Message is of the type "request", which means it is from Server to Client; 2. element that contains a unique number in order to associate the response to a System Message request. This element enables the system to send more than one System Messages at the same time and reduces messaging and signaling overhead. Also it helps in associating the response at Server end, which may be received at a later time from the Client; 3. element that gives some information to be rendered to the User; 4. element that indicates user the type of response expected from the User whether it is "no-answer" or "only-one-answer" or "multiple-answer"; "no-answer" - where the System Messages sent by the Server is only for the User's information and no response is expected from the User, "only-one-answer" - where the System Messages sent by the Server need to know the User's response with only Accept/Refuse or Yes/No kind of response, multiple-answer - where the System Messages sent by the Server need to the User's response with multiple answers. The Server decides on the value in element based on the kind of response required from the User. The Client has to respond back accordingly with the type of response as requested by the Server. 5. a number of element that gives the User to select the response from a list; When this element is present, it means the Server is expecting a response from the User. This element is not present in case value is "no-answer". This element will allow the Client to display the answer options from which the User can select. In case of one or multiple answers, each answer-options pair consists of a unique ID and a text message indicating the meaning of the option. Unique ID helps the Server to identify the choice made by the User in the response to the System Message. Each element contains a child element which is a unique number to identify an answer option. The child element gives free text answer option. If this child element is not present then it means the Client will give option to the user to fill in the answer. 6. element to confirm that the User has read the System Message. If this field is present then it indicates that the Server requires an acknowledgement to state that the user has read the message. This field is optional and decided by the Server. This element contains one of the following two child elements - where system can provide an alpha numeric code which the user has re-enter in the System Message response. - where the value of this element is URI of the location of code from which user has insert the code in the System Message response; 7. element to indicate the user, duration within which the user response is expected. This element takes care of the condition where the Server expects the user response to System Message within a certain time / duration; else the Server can decide the future course of action based on the local policy. This field is optional and decided by the Server; and 8. element, if present, allows the Server to insist the client to block further access to the service until user responds to a System Message. This element is optional and decided by the Server. Client should not allow the User for further access to the service, if requested by the Server. So in the case where Server wants to restrict the service access till client responds, the Server maintains a state and wait for the response till the timeout and decide further action based on the Service Provider policy. Server may resend the System Message but again depending on the Service Provider policy. A System Message Request document shall be identified with the MIME content type" vnd.example.system-message+xml". Example of a System Message Request document: xmlns="urn:example:params:xml:ns:application:system-message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:example:params:xml:ns:application:system-message request This is first system message no-answer eryu463jdfh Do you wish to continue with the service? only-one-answer 1Agree 2Disagree http://mysite.mydomain.com60 This is third system message multiple-answer 1 first option to user 2second option to user 3 4dfjk9067fh 90 XML schema for System Message Request: targetNamespace="urn:oma:params:xml:ns:im:system-message" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:oma:params:xml:ns:im:system-message" elementFormDefault="qualified" attributeFormDefault="unqualified"> /> Definitions: smsg-type indicates whether "request" or "response" smsg unique number to associate the response smsg-text System Message text smsg-response-type expected response type "no-answer" or "only-one-answer" or "multiple-answer" answer-options list of answer options answer-option-id a unique number to identify an answer option answer-option-text free text answer option verification to confirm that the User has read the System Message verification-text verification code that user has to re-enter in the response verification-uri URI of the location from where user has to enter the code in the response time-out duration within which the user response is expected restrict-access insists the client to block further access to the service until user responds to a System Message Structure of the System Message Response document: A System Message Response is an XML document that must be well-formed and has to be valid. System Message Response document is based on XML 1.0 and uses UTF-8 encoding. This invention makes use of XML namespaces for identifying System Message Response documents and document fragments. The namespace URI for elements defined by this specification is a URN, using the namespace identifier 'example'. This URN is: urn:example:params:xml:ns:application:system-message A System Message Response document begins with the root element. It consists of 1. element indicates that System Message is of the type "response" which means it is from Client to Server; 2. element that contains a value contained in "id" attribute of element of the System Message Request. This element helps to find a match between request and response on the Server. Also this element helps to correlate the responses in cases where there are more than one System Messages sent in a single message to reduce messaging and signaling overhead; 3. a number of element that indicates the User selection from a list of answer options. This element is a choice among a set of answer options defined in the request. Each element contains child element .There can be multiple answer-id if the value in element in the System Message request is "multiple-answer". This allows the user to send multiple answers to a request using the same message. Using only ID serves to reduce the message payload. Also each element may contain child element along with where the user entered free text answer is present. The answer response can facilitate the Service Provider to decide on the level of the service to be granted to the User and other factors like reset password, new registration, charging, features etc; 4. element to confirm that the User has read the System Message. For example, the User types the code which appears in the System Message request and thus confirms the Server that User has read the message. Or it may be the code that present at the URI (as mentioned in the System Message request). If the verification fails from the response provided by the User, the Server policy will decide on the further action for example it could be that the Server will not allow further access to the Service and Server may resend the System Message. A System Message Response document shall be identified with the MIME content type" vnd.example.system-message+xml". Example of a System Message Response document: xmlns="urn:example:params:xml:ns:application:system-message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:example:params:xml:ns:application:system-message response eryu463jdfh 1 3 tom 4dfjk9067fh XML schema for System Message Response: targetNamespace="urn:oma:params:xml:ns:im:system-message" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:oma:params:xml:ns:im:system-message" elementFormDefault="qualified" attributeFormDefault="unqualified"> /> Definitions: smsg-type indicates whether "request" or "response"; smsg unique number to associate the response; Answer list of answer options; answer-id to identify User selected answer option answer-text optional free text answer verification to confirm that the User has read the System Message System Message Request Signaling Flow: This subclause shows the message flow example of how a Server can send a System Message Request to User. The steps of the flows for the Figure-4 are as follows: 1. The Server X determines that System Message needs to be sent to User X. The Server X sends the SIP MESSAGE request to the SIP/IP Core. sip:[email protected] "Server X" *;+g.application.smsg; require;explicit application/vnd.example.system-message+xml Request-URI SIP HEADERS P-Asserted-lde ntity: Accept-Contac t: Content-Type: XML MIME BODY xsi:schemaLocation="urn:example:params:xml:ns:application:system- message "> request Do you wish to continue with the service? only-one-answer 1 Agree 2 Disagree 2. The SIP IP/Core X sends the SIP MESSAGE to the Client X based on information stored during registration. Request-URI sip: [email protected] SIP HEADERS P-Asserted-ldentity: "Server X" Accept-Contact: *;+g.application.smsg; require;explicit Content-Type: application/vnd.example.system-message+xml XML MIME BODY xsi:schemaLocation="urn:example:params:xml:ns:application:system-message M> req uest Do you wish to continue with the service? only-one-answer 1Agree 2Disagree 3. The System Message is displayed to User X 4. The Client X sends a SIP 200 "OK" response to the SIP/IP Core X in order to acknowledge that the System Message was received. The SIP 200 "OK" response is sent along the signalling path to the Server X. SIP HEADERS P-Asserted-ldentity: "UserX" 5. SIP/IP Core X forwards the SIP 200 "OK" response to Server X. SIP HEADERS P-Asserted-ldentity: "UserX" 6. The Server X receives the acknowledgment from the Client X about the reception of the System Message. System Message Response Signaling Flow: This subclause shows the message flow example of how a Client response to a System Message is sent to Server. The steps of the flows for the Figure-5 are as follows: 1. The Client X sends a SIP MESSAGE request to SIP/IP Core X. The Request-URI includes the Server X Address. The Accept-Contact header includes the feature-tag '+g.application.smsg'. Request-URI sip:[email protected] SIP HEADERS xmlns="urn:example:params:xml:ns:application:system-message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:example:params:xml:ns:application:system-message response 1 P-Preferred-ldentity: "User X" Accept-Contact: *;+g.application.smsg; require;explicit Content-Type: application/vnd.example.system-message+xml XML MIME BODY 354agr67h Request-URI 2. The SIP/IP Core X forwards the SIP MESSAGE request to the Server X based on the feature-tag '+g.application.smsg ' in the Accept-Contact header. sip:[email protected] SIP HEADERS P-Preferred-ldentity: "User X" Accept-Contact: *;+g.application.smsg; require;explicit Content-Type: application/vnd.example.system-message+xml XML MIME BODY xmlns="urn:example:params:xnnl:ns:application:system-message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:example:params:xml:ns:application:system-message M> response 1 354agr67h 3. The Server X receives the response form the User X for the System Message. 4. A SIP 200 "OK" response is sent by Server X to SIP/IP Core X. SIP HEADERS P-Asserted-ldentity: 5. SIP/IP Core X forwards the SIP 200 "Ok" response to Client X. SIP HEADERS P-Asserted-ldentity: 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 computer, mobile communication device, mobile server 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 there from. GLOSSARY OF TERMS AND DEFINITIONS THEREOF OMA - Open Mobile Alliance RFC - Request For Comments IETF - Internet Engineering Task Force IANA - Internet Assigned Numbers Authority ASN.1 - Abstract Syntax Notation number One MSRP - Message Session Relay Protocol PAD - Personal Digital Assistant PoC - Push to Talk Over Cellular IM - Instant Messaging XML - Extended Markup Language URN - Uniform Resource Names URI - Uniform Resource Indicator MIME - Multipurpose Internet Mail Extensions UTF - Unicode Transformation Format SIP - Session Initiation Protocol WE CLAIM 1. A method to accomplish system messaging in SIP by introducing a new content in the form of MIME body and a new feature tag to the existing SIP framework, for sending service specific information and receiving the user response. 2. A method as claimed in claim 1 wherein system messages feature is supported by both Client and Server where the system messages are uniquely identified by the Client and Server, distinguishing the said system messages from other normal messages. 3. A method as claimed in Claim 1 wherein the system message is applicable to various SIP based services like IM, PoC, MMS and any other SIP based service. 4. A method as claimed in Claim 1 wherein the SIP method which carry the new content type is a MESSAGE, MSRP SEND, INFO or any other appropriate SIP method. 5. A method as claimed in Claim 1 wherein a new feature tag "+g.application.smsg" is carried in the SIP header field which is the Accept-Contact header. 6. A method as claimed in Claim 1 wherein a new MIME type "vnd.example.system-message+xmf is carried in the SIP header field which is the Content-type header. 7. A method as claimed in Claim 1 wherein the new schema for system message request is carried as a body in various SIP methods like MESSAGE, INFO and MSRP SEND. 8. A method as claimed in Claim 7 wherein system message request document begins with the root element consists of element which indicates that system message is of the type "request", which is from server to client. 9. A method as claimed in Claim 7 wherein the root element consists of element which contains a unique number in order to associate the response to a system message request. 10. A method as claimed in Claim 9 wherein the element enables the system to send more than one system messages at the same time and reduces messaging and signaling overhead and associates the response at server end, which is received at a later time from the client. 11. A method as claimed in Claim 7 wherein the root element consists of element which gives information to the client to be rendered to the user. 12. A method as claimed in claim 7 wherein the root element consists of element which indicates user the type of response expected from the user whether it is a "no-answer" or "only-one-answer" or "multiple-answer". 13. A method as claimed in claim 12 wherein when the System Messages sent by the Server is only for the User's information and no response is expected from the User, the value in element is a "no-answer". 14. A method as claimed in claim 12 wherein when the System Messages sent by the Server need to know the User's response with only Accept/Refuse, the value in element is "only-one-answer". 15. A method as claimed in claim 12 wherein when the System Messages sent by the Server need to the User's response with multiple answers, the value in element is "multiple-answer". 16. A method as claimed in claim 12 wherein the Server decides on the value in element based on the kind of response required from the User and the Client respond back accordingly with the type of response as requested by the Server. 17. A method as claimed in claim 7 wherein the root element consists of an element which gives the User to select the response from a list where each element contains a child element that contains a unique number to identify an answer option and a child element which gives free text answer option. 18. A method as claimed in Claim 7 wherein the root element consists of a element to confirm that the User has read the System Message and contains child element either or . 19. A method as claimed in Claim 18 wherein element is used where system provides an alpha numeric code which the user has re-enter in the System Message response. 20. A method as claimed in Claim 18 wherein value of element is URI of the location of code from which user has insert the code in the System Message response. 21. A method as claimed in Claim 7 wherein the root element consists of element to indicate the user, duration within which the user response is expected. 22. A method as claimed in Claim 7 wherein the root element consists of element, which allows the Server to insist the client to block further access to the service until user responds to a System Message. 23. A method as claimed in Claim 1 wherein system message response is carried as a body in various SIP methods like MESSAGE, INFO and MSRP SEND. 24. A method as claimed in Claim 23 wherein the root element consists of element indicating that System Message is of the type "response". 25. A method as claimed in Claim 23 wherein the root element consists of element which contains the value contained in the "id" attribute of the element of the System Message Request. 26. A method as claimed in Claim 23 wherein the root element consists of element which indicates the User selection from a list of answer options where each element contains only child element or both child elements and . 27. A method as claimed in Claim 26 wherein multiple are there if the value in element in the System Message request is "multiple-answer" which allows the user to send multiple answers to a request using the same message. 28. A method as claimed in Claim 23 wherein the root element consists of element which is defined to confirm that the User has read the System Message where the said element has a child element . 29. A method to accomplish system messaging in SIP substantially described particularly with reference to the accompanying drawings. 30.A system to accomplish system messaging in SIP substantially describe) particularly with reference to the accompanying drawings.

Documents:

1124-CHE-2005 AMENDED PAGES OF SPECIFICATION 23-11-2012.pdf

1124-CHE-2005 AMENDED CLAIMS 06-12-2012.pdf

1124-CHE-2005 AMENDED CLAIMS 23-11-2012.pdf

1124-CHE-2005 AMENDED PAGES OF SPECIFICATION 06-12-2012.pdf

1124-CHE-2005 EXAMINATION REPORT REPLY RECEIVED 23-11-2012.pdf

1124-CHE-2005 EXAMINATION REPORT REPLY RECEIVED. 06-12-2012.pdf

1124-CHE-2005 FORM-1 23-11-2012.pdf

1124-CHE-2005 FORM-1 06-12-2012.pdf

1124-CHE-2005 FORM-13 23-11-2012.pdf

1124-CHE-2005 OTHER PATENT DOCUMENT 23-11-2012.pdf

1124-CHE-2005 POWER OF ATTORNEY 23-11-2012.pdf

1124-CHE-2005 POWER OF ATTORNEY 06-12-2012.pdf

1124-CHE-2005 CLAIMS.pdf

1124-CHE-2005 CORRESPONDENCE OTHERS.pdf

1124-CHE-2005 DESCRIPTION (COMPLETE).pdf

1124-CHE-2005 DRAWINGS.pdf

1124-CHE-2005 FORM 1.pdf

1124-CHE-2005 FORM 13 19-06-2006.pdf

1124-CHE-2005 FORM 18 19-12-2007.pdf

1124-CHE-2005 POWER OF ATTORNEY.pdf