Title of Invention

SYSTEM AND METHOD FOR DELIVERY REPORT IN INSTANT MESSAGING

Abstract

ABSTRACT This invention in general relates to mobile communication technology and more specifically to Instant Messaging service. The first part of the invention relates to the domain of Instant Messaging over SIP/SIMPLE technology. This invention explains a method for the delivery report function in SIP/SIMPLE system for instant messages delivered via SIP MESSAGE comprising the User indicating interest for receiving delivery report via SIP PUBLISH. This invention also explains a method for the delivery report function where the delivery report information is exchanged across IMPS and SIMPLE system comprising an IMPS User requesting delivery report of a SIP/SIMPLE User.

Full Text

FIELD OF TECHNOLOGY This invention in general relates to mobile communication technology and more specifically to Instant Messaging service. The first part of the invention relates to the domain of Instant Messaging over SIP / SIMPLE technology. Currently Open Mobile Alliance (OMA), which is developing mobile applications standard for Instant Messaging supports two means for exchanging Instant Messages, one is based on legacy IMPS technology and the other is based on SIP / SIMPLE technology. Second part of the invention relates to the domain of Instant Messaging service interworking between IMPS and SIP / SIMPLE technology. More particularly, the present invention relates to a system and method for delivery report in instant messaging. DESCRIPTION OF RELATED ART IMPS Technology In IMPS, a User who sends an IM, may request a delivery report. The primitive through which a User can send IM and indicate if he wishes Delivery Report is "SendMessageRequest" and the information element that indicates the Delivery Report request is "Delivery-Report-Request", a Boolean field. The report indicating the delivery of the "SendMessageRequest" to the recipient user is sent by the IMPS to requesting User within the "DeliveryReportRequest" primitive. Figures 3 to 7 illustrate various scenarios possible when an IM is sent indicating delivery report is required by the sender. These scenarios are only the examples and the invention is not limited to these. Delivery without Notification: "NewMessage" primitive is used to deliver the IM from the IMPS Server to the recipient user and the response "MessageDelivered" primitive to the IMPS server contains the Message-ID to indicate that the IM has been successfully delivered. The delivery-report -requesting-user is then sent an appropriate delivery report within the "DeliveryReportRequest" primitive. Delivery with Notification: The User receives the notifications with "MessageNotification" primitive, if the delivery method is set to "Notify/Get" by the recipient user. The user can retrieve the IM in the "GetMessageResponse" primitive after he makes a request with "GetMessageRequest" primitive. The Client who receives the IM generates the delivery report to the server through the primitive "MessageDelivered". The delivery-report-requesting-user is then sent an appropriate delivery report within the "DeliveryReportRequest" primitive. Forward IM: The User receives the notifications with "MessageNotification" primitive, if the delivery method is "Notify/Get". The recipient user can request the server to forward the IM with "ForwardMessageRequest" primitive. The delivery-report-requesting-user is then sent an appropriate delivery report within the "DeliveryReportRequest" primitive. Reject IM: The User receives the notifications with "MessageNotification" primitive, if the delivery method is "Notify/Get". The user can request the server to reject the IM with "RejectMessageRequest" primitive. The delivery-report-requesting-user is then sent an appropriate delivery report with the "DeliveryReportRequest" primitive. IM Expires: Suppose the other User is not reachable for some reason like Out-of-network coverage etc., the server may fail to deliver the IM within the message validity. Once the validity of the IM expires, the delivery-report-requesting-user is sent an appropriate delivery report with the "DeliveryReportRequest" primitive. Others scenarios: There are many other cases possible and the delivery report can contain response code like Message queue full, Recipient user/group does not exist, Recipient user blocked the sender, etc., SIP/SIMPLE Technology In SIP/SIMPLE, a User who sends an IM doesn't explicitly request a delivery report. The response code to a SIP message contains the Delivery Report. The message through which a User can send IM is "MESSAGE". The response code to "MESSAGE" contains the Delivery Report. The Response Code can be for e.g., 200 OK - Successful 202 ACCEPTED 3xx - Redirection 4xx - Request failure 5xx - Server failure 6xx - Global failure If the Client receives a 202 Accepted response, the message has been delivered to a gateway, store and forward server, or some other service that may eventually deliver the message. In this case, the Client MUST NOT assume the message has been delivered to the final destination. If confirmation of delivery is required for a message that has been responded to with a 202 Accepted, that confirmation must be delivered via some other mechanism, which is beyond the scope of the RFC 3428 "Session Initiation Protocol (SIP) Extension for Instant Messaging". 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. SUMMARY OF THE INVENTION The primary objective of this invention is therefore to provide a mechanism to deliver the confirmation of IM delivery in cases where 202 Accepted response is received. Also the second part of the invention covers the IM delivery report interworking between the two technologies IMPS and SIP/SIMPLE supported by OMA. The response codes mapping covered for the interworking are for example and not limited to those response codes. Accordingly, this invention explains a method for the delivery report function in SIP/SIMPLE system for instant messages delivered via SIP MESSAGE comprising the User indicating interest for receiving delivery report via SIP PUBLISH. The SIP/SIMPLE system identifies the user request for sending a delivery report. The SIP/SIMPLE system sends a SIP response with "warning" with note "Delivery report awaited". The SIP/SIMPLE system generates a delivery report in a SIP MESSAGE. Accordingly, this invention further explains a method for the delivery report function where the delivery report information is exchanged across IMPS and SIMPLE system comprising an IMPS User requesting delivery report of a SIP/SIMPLE User. The delivery report information is exchanged across IMPS and SIMPLE system comprising a SIP/SIMPLE User requesting delivery report of a IMPS User. An interworking server retains the IMPS User request for delivery report in its memory till the said server receives the SIP response code from SIP/SIMPLE server. The said interworking server generates a delivery report. The interworking server retains the SIP/SIMPLE User request for delivery report in its memory till the said server receives the delivery report from IMPS server. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1 illustrates the related art for sending an IM in IMPS technology. Figure 2 illustrates the related art for receiving a delivery report in IMPS technology. Figure 3 illustrates the related art for receiving a delivery report when IM delivery method is "PUSH", in IMPS technology. Figure 4 illustrates the related art for receiving a delivery report when IM delivery method is "NOTIFY/GET", in IMPS technology. Figure 5 illustrates the related art for receiving a delivery report when IM is Forwarded, in IMPS technology. Figure 6 illustrates the related art for receiving a delivery report when IM is Rejected, in IMPS technology. Figure 7 illustrates the related art for receiving a delivery report when IM Expires, in IMPS technology. Figure 8 illustrates the related art for sending an IM in SIP/SIMPLE technology. Figure 9 illustrates the method for confirmation of IM delivery in SIP/SIMPLE technology. Figure 10 illustrates the method for IM delivery report in interworking, when IMPS user requests delivery report from a SIP/SIMPLE user. Figure 11 illustrates the method for IM delivery report in interworking, when SIP/SIMPLE user sends IM to a IMPS user. 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. Figure 1 illustrates the related art for sending an IM in IMPS technology. Figure 2 illustrates the related art for receiving a delivery report in IMPS technology. Figure 3 illustrates the related art for receiving a delivery report when IM delivery method is "PUSH", in IMPS technology. Figure 4 illustrates the related art for receiving a delivery report when IM delivery method is "NOTIFY/GET in IMPS technology. Figure 5 illustrates the related art for receiving a delivery report when IM is Forwarded, in IMPS technology. Figure 6 illustrates the related art for receiving a delivery report when IM is Rejected, in IMPS technology. Figure 7 illustrates the related art for receiving a delivery report when IM Expires, in IMPS technology. Figure 8 illustrates the related art for sending an IM in SIP/SIMPLE technology. Figure 9 illustrates the method for confirmation of IM delivery in SIP/SIMPLE technology. Figure 10 illustrates the method for IM delivery report in interworking, when IMPS user requests delivery report from a SIP/SIMPLE user. 1) Delivery Report in SIP/SIMPLE Technology If the Client receives a 202 Accepted response, the message has been delivered to a gateway, store and forward server, or some other service that may eventually deliver the message. In this case, the Client MUST NOT assume the message has been delivered to the final destination. If confirmation of delivery is required for a message that has been responded to with a 202 Accepted, that confirmation must be delivered via some other mechanism, which is beyond the scope of the RFC 3428. This invention mentions the mechanism to provide the confirmation of the delivery of IM. Confirmation via MESSAGE method: Referring to Figure 9 when a User sends an IM via MESSAGE method, the recipient may not be reachable. Since the message is not yet delivered to the recipient, the response code returned from the server could be "202 Accepted". In this invention we propose that the response must contain the appropriate "warning* (header field in the SIP response primitive) in a human readable form, for e.g., the header field "warning' could have the note "Delivery report awaited". Once the server is able to deliver the IM to the recipient, the server generates a "MESSAGE" indicating the appropriate confirmation of the delivery to the sender of earlier IM. 2) Delivery Report in Interworking between IMPS and SIP/SIMPLE Technology 2.1) In interworking scenario, when an IMPS user is sending an IM to a SIP/SIMPLE user and the IMPS user has requested Delivery Report, the interworking server needs to generate appropriate delivery report based on the response from the SIP/SIMPLE user. (Refer Figure 10) 2.2) In interworking scenario, when a SIP/SIMPLE user is sending an IM to an IMPS user, the interworking server needs to generate appropriate response code and also the final confirmation to the SIP/SIMPLE user. (Refer Figure 11) OPERATION OF THE INVENTION A) Delivery Report in SIP/SIMPLE Technology If the Client receives a 202 Accepted response, the message has been delivered to a gateway, store and forward server, or some other service that may eventually deliver the message. In this case, the Client MUST NOT assume the message has been delivered to the final destination. If confirmation of delivery is required for a message that has been responded to with a 202 Accepted, that confirmation must be delivered via some other mechanism, which is beyond the scope of the RFC 3428. This invention mentions the mechanism to provide the confirmation of the delivery of lM. Confirmation via MESSAGE method: (Refer Figure 9) When a User sends an IM via MESSAGE method, the recipient may not be reachable. Since the message is not yet delivered to the recipient, the response code returned from the server could be "202 Accepted". In this invention we propose that the response must contain the appropriate "warning (header field in the SIP response primitive) in a human readable form, for e.g., the header field "warning" could have the note "Delivery report awaited'. Once the server is able to deliver the IM to the recipient, the server generates a "MESSAGE" indicating the appropriate confirmation of the delivery to the sender of earlier IM. Below steps explain the invention in detail (Refer Figure 9): User-1 indicates his interest of receiving delivery report for the messages sent via SIP MESSAGE method may be through one of the IM Service Settings stored on the IM Server. User can request IM Service Settings may be via SIP PUBLISH method or any other means. Note that in the example below, for simplicity reasons, not all SIP headers are shown and those necessary to demonstrate this invention are shown. Step-1. User-1 sending a message to User-2 via SIP MESSAGE method Example: MESSAGE sip:[email protected] SIP/2.0 Max-Forwards: 70 From: sip:user-1 ©domain.com;tag=49583 To: sip:[email protected] Call-ID: [email protected] CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 20 Hello, Good morning. Step-2. IM Server looks up for User-2 in its database (built up through registrations), and finds that User-2 is not reachable because of some reasons. IM Server now checks if User-1 has requested for delivery report in its Service Settings. If User-1 has requested for delivery report then, IM Server has to generate a report once the message is finally delivered. Step-3. User-1 sending a message to User-2 via SIP MESSAGE method. Since User-1 has requested for delivery report, the SIP response "202 Accepted" includes 'warning1 header field. The warning code can be within 390 to 399 as specified in RFC 3261. Example: SIP/2.0 202 Accepted Max-Forwards: 70 From: sip:user-1 ©domain.com;tag=49583 To: sip:[email protected] Call-ID: [email protected] CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 0 Warning: 395 "Delivery report awaited" Step-4. When User-2 is reachable, IM Server forwards message to User-2 via SIP MESSAGE method Example: MESSAGE sip:[email protected] SIP/2.0 Max-Forwards: 69 From: sip:[email protected];tag=49394 To: sip:[email protected] Call-ID: [email protected] CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 20 Hello, Good morning. Step-5. User-2 Client generates response Example: SIP/2.0 200 OK From: sip:[email protected];tag=49394 To: sip:[email protected];tag=ab8asdasd9 Call-ID: [email protected] CSeq: 1 MESSAGE Content-Length: 0 Step-6. Since User-1 has requested for delivery report, IM Server generates delivery report as in example below Example: MESSAGE sip:[email protected] SIP/2.0 Max-Forwards: 70 From: sip:[email protected];tag=49583 To: sip:[email protected] Call-ID: [email protected] CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 27 Message delivered to User-2. Step-7. User-1 Client generates response Example: SIP/2.0 200 OK From: sip:[email protected];tag=49394 To: sip:user-1 @domain.com;tag=ab8asdasd9 Call-ID: [email protected] CSeq: 1 MESSAGE Content-Length: 0 B) Delivery Report in Interworking between IMPS and SIP/SIMPLE Technology B.1) In interworking scenario, when an IMPS user is sending an IM to a SIP/SIMPLE user and the IMPS user has requested Delivery Report, the interworking server needs to generate appropriate delivery report based on the response from the SIP/SIMPLE user. (Refer Figure 10). In order for the interworking server to be able to send delivery report to requested user, the interworking server has to retain the request in its memory till it receives the SIP response code from SIP/SIMPLE server. The various scenarios possible are, for example: 1. The SIP/SIMPLE server may return 200 OK to interworking server. In such a case, interworking server can generate a "Successful" delivery report to the IMPS user. 2. The SIP/SIMPLE server may return 202 ACCEPTED to interworking server. In such a case, interworking server can wait delivering confirmation to an IMPS user till it receives final confirmation from the SIP/SIMPLE server existing in the same domain as explained in operation for "Delivery Report in SIP/SIMPLE Technology". 3. The SIP/SIMPLE server may return u603 DECLINE" to interworking server. In such a case, interworking server can generate a "Rejected" delivery report to the IMPS user. 4. The SIP/SIMPLE server may return u408 REQUEST TIMEOUT" to interworking server. In such a case, interworking server can generate a "Expired" delivery report to the IMPS user. An IMPS user has a provision to send an IM to list of users and if requested the delivery report is expected from all the receiving users. Hence interworking server may receive multiple delivery reports, if the IM is sent to more than one SIP/SIMPLE user. In such cases, the interworking server will generate delivery reports accordingly, as and when received and provide them to the IMPS user. B.2) In interworking scenario, when a SIP/SIMPLE user is sending an IM to an IMPS user, the interworking server needs to generate appropriate response code and also the final confirmation to the SIP/SIMPLE user. (Refer Figure 11). In our proposal, the appropriate final confirmation to the SIP/SIMPLE user is delivered via "MESSAGE" method as explained in operation for "Delivery Report in SIP/SIMPLE Technology". In order for interworking server to generate appropriate final confirmation to SIP/SIMPLE user, the interworking server has to first receive the final delivery report from the IMPS user. The "MESSAGE" can contain the appropriate delivery report for example, Successfully delivered Forwarded Rejected Expired Recipient user blocked the sender etc. 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 there from. GLOSSARY OF TERMS AND THEIR DEFINITIONS OMA - Open Mobile Alliance SIP - Session Initiation Protocol SIMPLE - Session Initiation Protocol (SIP) Extension for Instant Messaging IM - Instant Message WE CLAIM 1. A method for the delivery report function in SIP/SIMPLE system for instant messages delivered via SIP MESSAGE comprising the User indicating interest for receiving delivery report via SIP PUBLISH. 2. A method as claimed in claim 1 wherein the SIP/SIMPLE system identifies the user request for sending a delivery report. 3. A method as claimed in claim 1 wherein the SIP/SIMPLE system sends a SIP response with "warning" with note "Delivery report awaited". 4. A method as claimed in claim 1 wherein the SIP/SIMPLE system generates a delivery report in a SIP MESSAGE. 5. A method for the delivery report function where the delivery report information is exchanged across IMPS and SIMPLE system comprising an IMPS User requesting delivery report of a SIP/SIMPLE User. 6. A method as claimed in claim 5 wherein the delivery report information is exchanged across IMPS and SIMPLE system comprising a SIP/SIMPLE User requesting delivery report of an IMPS User and an inter working server retains the IMPS User request for delivery report in its memory till the said server receives the SIP response code from SIP/SIMPLE server. 7. A method as claimed in claim 5 wherein the said inter working server generates a delivery report and retains the SIP/SIMPLE User request for delivery report in its memory till the said server receives the delivery report from IMPS server. 8. A system for the delivery report function in SIP/SIMPLE system for instant messages delivered via SIP MESSAGE comprising the User indicating interest for receiving delivery report via SIP PUBLISH. 9. A system for the delivery report function where the delivery report information is exchanged across IMPS and SIMPLE system comprising an IMPS User requesting delivery report of a SIP/SIMPLE User. 10. A method for the delivery report function substantially described particularly with reference to the accompanying drawings. Dated this 7th day of April 2006

Documents:

399-CHE-2005 EXAMINATION REPORT REPLY RECEIVED 18-03-2013.pdf

399-CHE-2005 FORM-1 18-03-2013.pdf

399-CHE-2005 POWER OF ATTORNEY 17-06-2013.pdf

399-CHE-2005 POWER OF ATTORNEY 18-03-2013.pdf

399-CHE-2005 AMENDED PAGES OF SPECIFICATION 18-03-2013.pdf

399-CHE-2005 AMENDED CLAIMS 18-03-2013.pdf

399-CHE-2005 CORRESPONDENCE OTHERS 17-06-2013.pdf

399-CHE-2005 CORRESPONDENCE OTHERS. 20-03-2013.pdf

399-CHE-2005 FORM-13 17-06-2013.pdf

399-CHE-2005 FORM-13 18-03-2013.pdf

399-CHE-2005 FORM-13-1 17-06-2013.pdf

399-CHE-2005 FORM-3 20-03-2013.pdf

399-CHE-2005 OTHER PATENT DOCUMENT 20-03-2013.pdf

399-CHE-2005 POWER OF ATTORNEY 20-03-2013.pdf

399-che-2005-abstract.pdf

399-che-2005-claims.pdf

399-che-2005-correspondnece-others.pdf

399-che-2005-description(complete).pdf

399-che-2005-description(provisional).pdf

399-che-2005-drawings.pdf

399-che-2005-form 1.pdf

399-che-2005-form 26.pdf

399-che-2005-form 5.pdf