WO2011045009A1

WO2011045009A1 - Status sms acknowledgement mechanism

Info

Publication number: WO2011045009A1
Application number: PCT/EP2010/006182
Authority: WO
Inventors: Petr Dvorak
Original assignee: T-Mobile Czech Republic A.S.
Priority date: 2009-10-14
Filing date: 2010-10-11
Publication date: 2011-04-21

Abstract

The invention relates to a method, a client, a system, a program and a computer program product for communication using a short message system (SMS) in a mobile radio network between a client (104) and a network instance (102), wherein synchronization comprises the transmission of a status message (200) between the client (104) and the network instance and the transmission of an acknowledgement message (201) between the client (104) and the network instance (102).

Description

Status SMS acknowledgement mechanism

BACKGROUND

[0001] The present invention relates to a method, a client, a system, a program and a computer program product for a status SMS acknowledgement mechanism if the SMS message exchange is used for communication between a client and a network instance, especially if the SMS message exchange is used for

synchronization between the client and the network instance.

[0002] Methods using the short message system for communication are described e.g. in United States Patent Application US 2008/0085728 A1.

[0003] Synchronization is a procedure in a mobile radio network.

Synchronization comprises e.g. the data adjustment between a first dataset stored in a first device and a second dataset stored in a second device.

[0004] Synchronization e.g. between a network instance and a client is realized by exchanging messages using the Short Message System (SMS) via a user interface (Ul). The SMS message exchange (in the following also called message exchange) allows the introduction of the client to the network instance. If e.g. a subscriber of a service (in the following also called provisioned subscriber) inserts an adequate subscriber identity module (SIM) card into a terminal, the subscriber installs the client in this terminal. After installation, the client and the server must be synchronized. This synchronization is initiated by transmission of a status message (in the following also called STATE SMS or STATUS SMS) from the client to the server. As an answer the server transmits a synchronization message (in the following also called SYNC SMS) comprising the data according to the service (e.g. addresses, phone numbers etc).

[0005] Important for the SMS message exchange is the awareness of the installed software version of the client. Different service implementations, i.e. different software versions, (in the following also called client types) use different SMS message formats. Furthermore Internet Message Access Protocol (IMAP) 4 commands and parameters (sent via secondary Ul communication channel) also differ in dependence of the client type. As a result the client must have the adequate client type (software version i.e. SMS message format) installed to read the synchronization message from the server. If the client has the wrong version (leading to the wrong SMS message format) installed the synchronization message must be rejected and the synchronization has failed.

[0006] If the status message from the client is not correctly interpreted by the network instance, the network instance possibly loses the awareness about the client type. Such loss results in a client malfunction and the synchronization has failed (synchronization failure).

SUMMARY

[0007] An object of the present invention is to provide a method, a client, a system, a program and a computer program product for communication between a client (in the following also called WM client) and a network instance (in the following also called Visual Voicemail (WM) network instance, WM server or server) by using a Status short message system (SMS) acknowledgement mechanism to assure the communication, especially the synchronization, between the client and the network instance using an SMS message exchange.

[0008] The object of the present invention is achieved by a method for communication between a client and a network instance wherein the client uses a short message system (SMS) in a mobile radio network, wherein the method comprises a first step and a second step, wherein the first step comprises the transmission of a status message between the client and the network instance and wherein the second step comprises the transmission of an acknowledgement message between the client and the network instance. If the status message is sent by the client the status message is in the following also called first client status message, mobile originated (MO) Status SMS or MO State SMS. If the status message is sent by the network instance the status message is also called first network instance status message, mobile terminated (MT) Status SMS or MT State SMS. If the acknowledgement message is sent by the network instance the acknowledgement message is also called network instance acknowledgement message or MT acknowledgement SMS. If the acknowledgement message is sent by the client the acknowledgement message is also called client acknowledgement message or MO acknowledgement SMS.

[0009] It is preferred that the status message comprises at least one of a first format information or a first data information, and wherein the second step comprises the transmission of an acknowledgement message between the client and the network instance, wherein the acknowledgement message comprises at least one of a second format information referring to the first format information or a second data information referring to the first data information.

[0010] It is preferred that the second format information comprises an acceptance information referring to the acceptance of the first format information and/or the second data information comprises a usability information referring to the usability of the first data information.

[0011] The standardized SMS acknowledgement (using the SMS-SUBMIT- REPORT on lower layer) is not sufficient for WM synchronization purposes.

Standard SMS acknowledge provides only the confirmation of the SMS message delivery. It does not say anything about understanding of the content of the SMS message (e.g. content format acceptance, correctness of transferred information). According to the present invention it is advantageously possible that standard SMS acknowledgement (on lower layer) is extended by the acknowledgement provided directly by the WM client/server (on application layer). The SMS acknowledgement is handled on the application layer and does not directly relate to already existing SMS protocol acknowledgement mechanism designed for SMS protocol layer (lower layer). The acknowledgement message according to the present invention works in combination with SMS protocol layer acknowledgement (SMS-SUBMIT-REPORT), i.e. the combination of both acknowledgements (on SMS protocol layer and on WM application layer) provides the advantage of the method according to the present invention. [0012] According to the present invention it is advantageously possible to assure the communication, especially the synchronization, between client and network instance using SMS communication even if an error in the communication between client and network instance during the synchronization process occurs e.g. if the status message is not correctly transmitted or the content of the status message is not correctly interpreted or the status message is generated using a wrong client type and therefore rejected. The content of the status message is e.g. the request for synchronization between the client and the network instance or e.g. the information about the software version installed in a terminal by a provisioned subscriber or e.g. a message format used in the status message. Two exemplary error cases that are avoidable by the present invention are described in the following.

[0013] In the following two examples of possible error cases that are avoidable by the present invention are explained. In the first example the subscriber with WM version 1 service (client type 1 ) provisioned inserts a Subscriber Identity Module (SIM) card into a terminal equipped with a WM version 2 client (client type 2). If in this case the initial mobile originated (MO) STATE SMS is lost because of a mistake (this error case is called an initial MO STATE SMS failure), the WM network instance keeps trying to synchronize the WM client using the WM version 1 (client type 1 ) SMS message format by sending a mobile terminated (MT) SYNC SMS client type 1 message to the WM client. As this MT SYNC SMS is not in client type 2 message format, the MT SYNC SMS message is rejected so that the synchronization between WM client and WM network instance has failed.

[0014] In the second example a regular voicemail subscriber (i.e. a subscriber that has yet neither client type 1 nor client type 2 provisioned) inserts a SIM card into a terminal and installs the WM version 1 client (client type 1 ). The MO STATE SMS message is delivered but rejected by the network instance because the WM service is not provisioned yet. After this rejection the regular voicemail subscriber requests by error provisioning of a client type 2 WM version which is the wrong WM version because client type 1 is installed. The WM network instance sends a MT STATE SMS message using client type 2 to the WM client using client type 1. Because of the different client types the WM client rejects the MT STATE SMS message so that the synchronization between WM client and WM network instance has failed (this error case is called delayed provisioning with wrong WM client type).

[0015] If in these two exemplary error cases the content of the

acknowledgement message is not correctly interpreted both the client and the network instance dispose of predefined error case procedures. By these error case procedures it is possible to assure the exchange of the necessary information for the SMS message exchange (e.g. user interface attributes) between the client and the network instance. Furthermore it is advantageously possible to transmit the acknowledgement message using the application layer. By using the application layer it is possible to use the method according to the present invention in

applications like MMS, FTP or HTTP.

[0016] According to the present invention it is preferred that the

acknowledgement message comprises an information identifying the related status message.

[0017] According to the present invention it is thereby advantageously possible to differentiate between the acknowledgment message and the status message so that errors are avoidable. For example it is possible that the acknowledgment message comprises at least a part of the text of the related status message so that it is definitely clear that the acknowledgement message relates to the related status message. Such a part of the text comprises preferably 10 characters, more preferably 50 characters, more preferably 100 characters. Furthermore the

acknowledgment e.g. comprises the information that the status message was interpreted as a status message that requests the synchronization between the client and the server.

[0018] According to the present invention it is preferred that the client comprises a user interface (Ul) and the acknowledgement message comprises Ul attributes.

[0019] According to the present invention it is thereby advantageously possible that e.g. the MO acknowledgement SMS comprises Ul specific attributes in order to find out the WM client type. The acknowledgement message comprises e.g. information about the client type version especially the software version that is installed e.g. in the client by the subscriber or the software version that is provisioned and installed in the network instance. Furthermore it is possible that the customer relationship management (CRM) adapts the Ul attributes after the network instance status message is replied by the client acknowledgement message.

[0020] According to the present invention it is preferred that a third step comprises the transmission of a further status message between the client and the network instance in case that the acknowledgement message was not received.

[0021] According to the present invention it is thereby advantageously possible that the client or the network instance is able to send the status message again in case that the first status message was not or not adequately delivered or in case that the content of the status message was not correctly interpreted. By this resending of the status message it is avoidable that synchronization fails because of a message delivery problem or because or a misinterpretation of the content of the status message.

[0022] According to the present invention it is preferred that the method comprises a fourth step wherein the fourth step comprises that the client sends a request for reconfiguration to the network instance in case that the acknowledgement message was not received.

[0023] According to the present invention it is thereby advantageously possible that the client requests the reconfiguration of the Ul according to the information brought by the request for reconfiguration. This reconfiguration means e.g. that the network instance changes the message format or the software version for the status message and sends the status message again to the client. This possibility allows to save time and makes the synchronization process fast compared to the prior art.

[0024] According to the present invention it is preferred that the client comprises a Visual Voicemail (WM) client. [0025] According to the present invention it is thereby advantageously possible that the present invention is usable with known services such as WM. To ensue e.g. that any subscriber of the WM service is informed if a new message is available the WM client must be synchronized with the WM network instance so that the present invention with the method for synchronization assures the efficiency of services such as WM.

[0026] The invention further relates to a client using a short message system (SMS) in a mobile radio network, wherein communication between the client and a network instance comprises the transmission of a status message between the client and the network instance and the transmission of an acknowledgement message between the client and the network instance.

[0027] According to the present invention it is thereby advantageously possible to assure synchronization between client and network instance using SMS

communication even if an error in the SMS communication between client and network instance during the synchronization process occurs e.g. if the status message is not correctly interpreted or the status message is delivered using a wrong client type. If the acknowledgement message is not correctly interpreted the client disposes of predefined error case procedures. By these error case procedures it is possible to exchange the necessary information for the SMS message exchange (e.g. user interface attributes) between client and network instance. Furthermore it is advantageously possible to transmit the acknowledgement message using the application layer. By using the application layer it is possible to use the client according to the present invention in applications like MMS, FTP or HTTP.

[0028] According to the present invention it is preferred that the client comprises a synchronization function, wherein the client comprises a user interface, wherein the synchronization function is usable to manually request the

reconfiguration of the user interface.

[0029] According to the present invention it is thereby advantageously possible that the client requests the reconfiguration of the Ul according to the information brought by the request for reconfiguration. The subscriber is able to request reconfiguration of the Ul to assure that synchronization is possible. So it is avoidable that the subscriber must wait until the reconfiguration is executed by the network instance. Furthermore it is advantageously possible that the subscriber is able to initiate the synchronization process which is especially advantageous for example if the subscriber puts the SIM card out of a terminal and back into the terminal.

[0030] The invention further relates to a system using a short message system in a mobile radio network, wherein the system comprises a client and a network instance, wherein communication between the client and the network instance comprises a status message between the client and the network instance and an acknowledgement message between the client and the network instance.

[0031] According to the present invention it is thereby advantageously possible to assure synchronization between client and network instance using SMS

communication even if an error in the SMS communication between client and network instance during the synchronization process occurs. Furthermore it is advantageously possible to transmit the acknowledgement message using the application layer. By using the application layer it is possible to use the system according to the present invention in applications like MMS, FTP or HTTP.

[0032] The invention further relates to a program comprising a computer readable program code and a computer program product comprising a computer readable program code for controlling a client using a short message system in a mobile radio network, wherein communication between the client and a network instance comprises a status message between the client and the network instance and an acknowledgement message between the client and the network instance.

[0033] According to the present invention it is thereby advantageously possible to assure synchronization between client and network instance using SMS

communication even if an error in the SMS communication between client and network instance during the synchronization process occurs. Furthermore it is advantageously possible to transmit the acknowledgement message using the application layer. By using the application layer it is possible to use the program or the computer program product according to the present invention in applications like MMS, FTP or HTTP.

BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 shows schematically a cell of a mobile radio network.

[0035] Figure 2 shows schematically an exchange of information between a network instance and a client according to a first embodiment of the present invention.

[0036] Figure 3 shows schematically an exchange of information between a network instance and a client according to a second embodiment of the present invention.

[0037] Figure 4 shows schematically an exchange of information between a network instance and a client according to a third embodiment of the present invention.

[0038] Figure 5 shows schematically a block diagram of a client algorithm.

[0039] Figure 6 shows schematically a block diagram of a network instance algorithm.

[0040] Figure 7 shows schematically a block diagram of a network instance algorithm.

DETAILED DESCRIPTION

[0041] The present invention will be described with respect to particular embodiments and with reference to certain drawings but the invention is not limited thereto but only by the claims. The drawings described are only schematic and are non-limiting. In the drawings, the size of some of the elements may be exaggerated and not drawn on scale for illustrative purposes. [0042] Where an indefinite or definite article is used when referring to a singular noun, e.g. "a", "an", "the", this includes a plural of that noun unless something else is specifically stated.

[0043] Furthermore, the terms first, second, third and the like in the description and in the claims are used for distinguishing between similar elements and not necessarily for describing a sequential or chronological order. It is to be understood that the terms so used are interchangeable under appropriate circumstances and that the embodiments of the invention described herein are capable of operation in other sequences than described of illustrated herein.

[0044] Figure 1 shows schematically a cell 100 of a mobile radio network. The mobile radio network comprises a core network 101 with a network instance 102 (in the following also called server) and a multitude of base stations, one thereof, a base station 103 is connected to a client 104. It is possible that the client 104 is a WM client and the network instance 102 is a WM network instance. Visual Voicemail is the process of adding a visual aspect to phone voicemail such as allowing

subscribers to view a list of audio voicemail entries or even read transcripts of these voicemails as text. These voicemails are converted to text by use of advanced speech recognition software. These voicemails are sent e.g. via SMS to the WM client so it allows better management of voicemail messages and saves time filtering spam.

[0045] Figure 2 shows schematically an exchange of information between the network instance 102 and the client 104 according to a first embodiment of the present invention. This synchronization process occurs if for example a subscriber of a WM service inserts a SIM card into a terminal. For synchronization the client 104 sends a first client status message 200 (in the following also called status message) to the network instance 02. In this first client status message 200 the client 104 sends information that are necessary for the synchronization process i.e. user interface attributes for the communication via SMS messages. As an answer the network instance 102 sends a network instance acknowledgement message (in the following also called acknowledgement message) 201 to the client 104. The network instance acknowledgement message 201 comprises the information for the client 104 about the user interface attributes for the communication via SMS messages. If the client 104 accepts this information then the synchronization process is successful. This synchronization process by an acknowledgement message is generic and is usable in any cases when the synchronization of the client 104 is assured by using the SMS message exchange. As a security feature it is possible that the network instance acknowledgement message 201 comprises a second keyword 202 to differentiate between the network instance acknowledgment message 201 and a status message so that errors are avoidable.

[0046] This first embodiment is the basic principle of the present invention. The synchronization according to the present invention is assured by sending the acknowledgement message from the server to the client. This acknowledgement message is related to the status message so that the client realizes that the status message has not only reached the server but furthermore that the content of the status message was correctly interpreted by the network instance. This interpretation comprises that the network instance understands the status message as a

synchronization request and that the network instance realizes the software version or the required message format that is necessary for the synchronization procedure itself. Likewise for the opposite direction of a message exchange (i.e. the status message is sent by the network instance and the acknowledgement message is sent by the client to the network instance) the present invention allows the network instance to realize that the status message has not only reached the client but furthermore that the content of the status message was correctly interpreted by the client.

[0047] Figure 3 shows schematically an exchange of information between the network instance 102 and the client 104 according to a second embodiment of the present invention. This synchronization process occurs for example if the following error case occurs. If for example a non WM subscriber (also called not provisioned for client type 1 or type 2) inserts a SIM card into a terminal and installs a WM client type 1 on the terminal. As a result the WM client type 1 sends a first client status message 200 to the network instance 102. But the WM network instance rejects the first client status message 200 because the WM client type 1 is not provisioned yet. After this rejection the non WM subscriber requests as an error a provisioning of a WM client type 2, the network instance 102 sends a first network instance status message 300 (in the following also called status message) using WM client type 2 to the client 104 using client type 1. As a result the first network instance status message 300 is rejected by the client 104 and no client acknowledgement message (in the following also called acknowledgement message) is sent back from the client 104 to the network instance 102. Because of the lack of the client acknowledgement message the network instance 102 sends a second network instance status message (in the fllowing also called further status message) 301 using client type 1 to the client 104. As the client 104 uses client type 1 the client 104 sends the client

acknowledgement message 302 to the network instance and the synchronization of the client 104 is successful. In order to differentiate between the client

acknowledgement message 302 and a status message the client acknowledgement message 302 comprises for example a first keyword 303. The client

acknowledgement message 302 also comprises the User Interface attributes for the communication via SMS messages.

[0048] Figure 4 shows schematically an exchange of information between the network instance 102 and the client 104 according to a third embodiment of the present invention. If the first client status message 200 is lost and does not reach the network instance 102 (also called an initial MO STATE SMS failure) and therefore the client 104 does not receive the network instance acknowledgement message 201 from the network instance 102 the client 104 sends a second client status message (in the following also called status message) 400 to the network instance 102. As an answer the network instance 102 sends the network instance acknowledgement message 201 to the client 104. The network instance acknowledgement message 201 comprises the information for the client 104 about the User Interface attributes for the communication via SMS messages. If the client 104 accepts this information then the synchronization process is successful.

[0049] Figure 5 shows schematically a block diagram of a client algorithm that is possible to use if a method according to the present invention is implemented into the client 104. In block 500 the first client status message 200 is generated. In block 501 after the first client status message 200 is delivered an acknowledgement SMS timer is reset. The acknowledgement SMS timer is necessary because the client 104 should not wait longer than a predetermined waiting time for the network instance acknowledgement message 201. In block 502 a SMS generation retry counter is updated. The SMS generation retry counter is necessary because the client 104 should not send more than a predetermined amount of client status messages. In block 503 the client 104 is waiting for the network instance acknowledgement message 201. In block 504 the client 104 decides if the client 104 received the network instance acknowledgement message 201 or not. If the client 104 received the network instance acknowledgement message 201 the client algorithm comes to the end 507. In this case the synchronization procedure is successful. If the client 104 did not receive the network instance acknowledgement message 201 and the acknowledgement SMS timer has exceeded the predetermined waiting time then in block 505 the client 104 decides if the SMS generation retry counter has exceeded the predetermined amount of status messages or not. If the SMS generation retry counter has exceeded then in block 506 the client 104 is set into the synchronization failure status and the algorithm comes to the end 507. In this case the

synchronization is not successful. If the SMS generation retry counter has not exceeded in block 500 a second client status message 400 is generated and the client algorithm is repeated. The client algorithm is repeated until either the client 104 is synchronized or the client 104 is set into the synchronization failure status.

[0050] Figure 6 shows schematically a block diagram of a network instance algorithm that is possible to use if a method according to the present invention is implemented into the network instance 102. In block 600 the first network instance status message 300 is generated. In block 601 after the first network instance status message 300 is delivered a network instance acknowledgement SMS timer is reset. The network instance acknowledgement SMS timer is implemented because the network instance 102 should not wait longer than a network instance predetermined waiting time for the client acknowledgement message 302. In block 602 a network instance SMS generation retry counter is updated. The network instance SMS generation retry counter is necessary because the network instance 102 should not send more than a predetermined amount of network instance status messages. In block 603 the network instance 102 is waiting for the client acknowledgement message 302. In block 604 the network instance 102 decides if the network instance 102 received the client acknowledgement message 302 or not. If the network instance 102 received the client acknowledgement message 302 the network instance algorithm comes to the end 607. In this case the synchronization procedure is successful. If the network instance 102 did not receive the client acknowledgement message 302 and the network instance acknowledgement SMS timer has exceeded the network instance predetermined waiting time then in block 605 the network instance 02 decides if the network instance SMS generation retry counter has exceeded the predetermined amount of network instance status messages or not. If the network instance SMS generation retry counter has exceeded then in block 606 the network instance 102 starts a Ul version reconfiguration process (also called client type reconfiguration process). In this case the synchronization is not

successful. If the network instance SMS generation retry counter has not exceeded then in block 600 a second network instance status message 301 is generated and the network instance algorithm is repeated. The network instance algorithm is repeated until either the network instance 102 is synchronized or the Ul version reconfiguration process is started.

[0051] Figure 7 shows schematically a block diagram of a network instance algorithm in the case that the Ul version reconfiguration process is started (also called client type reconfiguration process). In block 700 the Ul version reconfiguration process is started. In block 701 the Ul version is set to the next Ul version. In block

702 the first network instance status message 300 is sent to the client 104. In block

703 is decided if the client acknowledgement message 302 is received or not. If the client acknowledgement message 302 is received then the Ul version reconfiguration process comes to the end 706. If the client acknowledgement message 302 is not received then in block 704 is decided if all Ul versions are checked out. If all Ul versions are checked out then in block 705 the client 104 is set into the version- failure status and the Ul version reconfiguration process comes to the end 706. In this case the synchronization has failed. If not all Ul versions are checked out then in block 701 the Ul version is set to the next Ul version and the version reconfiguration process is started again. The version reconfiguration process is repeated until either the client 104 is synchronized or the client 104 is set into the version-failure status. If the client 104 is set into the version-failure status the subscriber is able to manually initiate the transmission of the first client status message 200 to the network instance 102. This is possible by using a synchronization function that is implemented in the client 104. If this synchronization function is used the synchronization procedure begins. The synchronization function is realizable as a button to manually press by the subscriber or as a software button implemented in the client software. This leads to the advantage that the subscriber is able to initiate the synchronization procedure and it is not necessary that the subscriber waits until the customer relationship management (CRM) initiates the synchronization procedure.

Claims

Patent Claims

1. Method for communication between a client (104) and a network instance (102), wherein the client (104) uses a short message system (SMS) in a mobile radio network, wherein the method comprises a first step and a second step, wherein the first step comprises the transmission of a status message between the client (104) and the network instance (102), wherein the status message comprises at least one of a first format information or a first data information, and wherein the second step comprises the transmission of an acknowledgement message between the client (104) and the network instance (102), wherein the

acknowledgement message comprises at least one of a second format

information referring to the first format information or a second data information referring to the first data information.

2. Method according to claim 1 , wherein the second format information comprises an acceptance information referring to the acceptance of the first format information and/or the second data information comprises a usability information referring to the usability of the first data information.

3. Method according to claim 1 , wherein the acknowledgement message comprises an information identifying the related status message.

4. Method according to claim 1 , wherein the client (104) comprises a user interface and the acknowledgement message comprises user interface attributes.

5. Method according to claim 1 , wherein a third step comprises the transmission of a further status message between the client (104) and the network instance (102) in case that the acknowledgement message was not received.

6. Method according to claim 1 , wherein the method comprises a fourth step wherein the fourth step comprises that the client (104) sends a request for reconfiguration to the network instance (102) in case that the acknowledgement message was not received.

7. Method according to claim 1 , wherein the client (104) comprises a Visual

Voicemail (WM) client.

8. Client (104) using a short message system (SMS) in a mobile radio network, wherein communication between the client (104) and a network instance (102) comprises the transmission of a status message between the client (104) and the network instance (102) and the transmission of an acknowledgement message between the client (104) and the network instance (102).

9. Client according to claim 7, wherein the client (104) comprises a synchronization function, wherein the client (104) comprises a user interface, wherein the synchronization function is usable to manually request the reconfiguration of the user interface.

10. System using a short message system (SMS) in a mobile radio network, wherein the system comprises a client (104) and a network instance (102), wherein communication between the client (104) and the network instance (102) comprises a status message between the client (104) and the network instance (102) and an acknowledgement message between the client (104) and the network instance (102).

11. Program comprising a computer readable program code for controlling a client (104) using a short message system (SMS) in a mobile radio network, wherein communication between the client (104) and a network instance (102) comprises a status message between the client (104) and the network instance (102) and an acknowledgement message between the client (104) and the network instance (102).

12. Computer program product comprising a computer readable program code

according to claim 10 for controlling a client (104).