A messaging system

[0001] The present application relates to the field of communication, in particular SMS text messages. BACKGROUND OF THE INVENTION [0002] The transmission of text messages by means of Short Message Service (SMS) is one of the most common forms of communication known to most GSM users and other telephone networks. In its simplest form of operation, an SMS is sent from one mobile user to another mobile user by the SMS Center (SMSC).

[0003] SMS messages can be forwarded within one mobile telephone network or to anyone using a roaming service.

[0004] SMS messages can be text coded, which is conventionally used by users, as well as binary. There are many varieties of ways to encode SMS messages, both for encoding "text" and "binary" messages. In general and in more detail, in the context of this application, text messages refer to messages that represent human readable SMS messages. Binary messages refer to messages that are not intended for reading by the user on the phone, i.e. messages that are illegible to humans, such as OTA (Over The Air configuration) messages, WAP PUSH messages, ringtones, etc. A normative reference is a specification 3GPP TS 23.040, currently version 8.3.0, is available on the website <a href="http://www.3gpp.org">www.3gpp.org</a>.

[0005] A similar document is GB 2 404 301 A.

[0006] The present application is directed to methods of sending, delivering and storing SMS text messages.

[0007] SMS text messages are conventionally stored by the SMSC until delivery to the user. After delivery of the message or when delivery was not possible within the specified time, the message is deleted. The message can be deleted as soon as delivery is confirmed or messages can be deleted periodically. As a result, messages are stored in the SMSC center only temporarily.

[0008] Recently, services have been developed to extend the functionality of SMSC or other devices in a mobile network so that messages received and sent by the user are intercepted. After interception, the service may provide the user with additional services. For example, you can provide a database storage service for copies of all messages received or sent by the user. The user can then access the database, for example via the website, to view any messages he has received or sent. This service is provided to clients by 02 UK and was launched on the market as BLUEBOOK ™. Similarly, you can use a SPAM filter or inappropriate content to check for intercepted SMS messages to prevent the user from delivering such messages. Note that various alternative services can also be provided with this technology.

[0009] Such services are facilitated by the use of home routing, known to experts in the field, ensuring that all messages received by the SMS user pass through his home SMSC center or associated routing device (router), regardless of the origin of the message . Without the use of home routing, the benefits are less because the SMSC \ user routing device does not have full access to all messages intended for the user.

[0010] Another advance in the mobile phone environment is the availability of multi-SIM (multi-SIM) telephone systems. In a multi-SIM configuration, a mobile user can have multiple telephones with the same effective telephone number. For telephone conversations, the implementation of such a system is relatively obvious in this respect that when a call arrives at a particular number, all phones associated with that particular number ring, and the first received phone is connected to the caller. At this point, the other phones stop ringing.

[0011] Messaging is a greater challenge. For example, a case of a user with two telephones can be considered, each associated with a common telephone number, where the first telephone could be a personal mobile telephone generally in the user's possession, while the second telephone could be a car telephone. In the first mode of operation, the SMSC center can send all messages to each phone separately. It is clear, however, that in this situation the user could receive a certain number of messages on his phone in the office and reply to them, but later in the car he would come across the same messages waiting in the car phone. Of course, this could be very troublesome for the user. Therefore, the techniques of filtering the destination of SMS messages are developed using heuristic techniques for determining the user's location.

[0012] An alternative approach is the approach of Singtel, which has a multi-SIM product that requires the user to enter / send a specific code identifying one mobile telephone as the preferred telephone for voice calls and SMS / MMS. By using these systems, the user receives messages only to one of his phones. It is worth noting, however, that this is a cumbersome system and means that the user reading messages on one phone will not have the message received on the other phone. It also requires constant updating of the service.

[0013] The present application is directed to an alternative approach to the handling of SMS text messages.

Summary of the Invention [0014] The present application is directed to a system for delivering SMS text messages to a user, the system comprising: a database for storing SMS text messages received in the system and associated with the user, an incoming interface for receiving SMS text messages intended for the user, the interface being adapted for storing received SMS text messages in the database, wherein the system is adapted to place the contents of an SMS text message in one or more binary coded SMS messages and to send the binary coded SMS message to the user. The advantage of this approach is the introduction of flexibility in the scope of possible messaging on telephones with central message storage, while maintaining the existing SMS infrastructure of mobile networks. [0015] Preferably, the interface generates a message identifier for storage together with the message in the database. The message identifier in conjunction with the sender identifier can uniquely identify the message for the user in the database. As an alternative to the generated message identifier, a message time stamp can be used as it can be seen as unique (set by SMSC - see for example chapter 6.2 - "SC Functional Requirements" of specification 23.040, which requires the SMSC center to set a message time stamp as to uniquely identify a message about a specific destination). However, this approach is less favorable for a number of reasons. First, it is conceivable that two different Service Centers can allocate the same time stamp. In addition, as subsequent messages, as will be described below, may be sent with the same unique identifier, it may be inappropriate to send messages with a specific date stamp weeks, months, or even years after a specific date. Moreover, depending on the SMSC configuration, the lower layers of the messaging stack on the phone may simply ignore the message with such an old timestamp.

[0016] The system may include an outgoing interface adapted to receive text messages

SMS sent by the user to destinations. The outgoing interface can be adapted to store a copy of each message in the database. Preferably, the outgoing interface generates a message identifier for storage with the message in the database. The message identifier in combination with the destination identifier can uniquely identify the message to the user in the database. The system may be adapted to encode a message sent by the user within at least one binary coded text message and to send this binary coded message to all user devices for storage in the "sent" folder on each device. The system may be adapted to respond to an SMS message received from the user containing a guideline for updating the status of the message stored in the database, after which the system may update the status of the message in the database based on the received guideline. In this case, the system can be adapted to send an SMS to the user informing him about a change in the status of the message in the database. The change of status may include one or more of the following: a) confirmation of reading the message, b) request to delete the message and c) request to move the message to another location.

[0017] The application also includes a mobile telephone adapted to receive SMS text messages, which telephone is adapted to examine the content of the binary coded text message in response to the receipt of the binary coded text message for the presence of an identifier identifying the content as corresponding to the text message, and after identifying this message to extract this text message from a binary coded text message and to present that text message to the user as an incoming SMS text message. Preferably, the messaging device includes a binary coded message responsive application associated with a particular port, which application performs the task of extracting text from a binary coded SMS and presenting the text message to the user as an incoming SMS text message. The messaging device may further comprise a data warehouse and may be adapted to store extracted SMS text messages in the data warehouse. The messaging device may be adapted to extract the message identifier from the binary coded message and to store that message identifier together with the extracted SMS text message in the data store.

[0018] The messaging device may respond to SMS text messages identifying the message in the data store and determining the operation for updating the status of the message in the data store.

[0019] The present application further includes the following claims.

Description of the figures [0020]

Fig. 1 is a diagram of an example system of the present application,

Fig. 2 is a flowchart of a first aspect of the present application,

Fig. 3 is a flowchart of a second aspect of the present application,

Fig. 4 is a flowchart of a third aspect of the present application,

Fig. 5a illustrates the format of the SMS text message received by the system for the user,

Fig. 5b illustrates the resulting example format used for a binary coded text message sent from the system to a user containing the text of an SMS text message,

Fig. 6 illustrates a block diagram of an example SMS repository,

Fig. 7 illustrates a block diagram of a mobile SMS device incorporating a repository application for cooperating with the message repository of Fig. 6,

Fig. 8 shows an exemplary method that the repository application of Fig. 7 may implement,

Fig. 9 shows another example method that the repository application of Fig. 7 can implement.

Description of Embodiments [0021] The present application solves the problems of the prior art by moving the main location for storing messages from the user's mobile telephone to the server associated with the network. To ensure that no significant changes to the network infrastructure are required, this application uses SMS and / or IP messages to distribute updates to one or more phones to synchronize these phones with the server and vice versa as needed. Furthermore, the system can be considered relatively transparent to the user because it appears conventional to receive and send text messages.

[0022] The system will now be described with reference to an exemplary system implemented in the SMSC center 10 which, as shown, supports two messaging devices 14, 16 (e.g. mobile phones) sharing a common telephone number. It should be noted that this system can be implemented in a device external to the SMSC, simply as a node of the messaging infrastructure of the mobile operator's telecommunications network or, as described below in another embodiment of the invention, externally to the mobile operator's telecommunications network. The SMSC may receive SMSs from these telephones or others in the same network or from another SMSC center external to the network, as is known to experts in the field. To facilitate translation, the view of the mobile network has been simplified. The SMSC is adapted to send and receive messages from connected telephones or from another SMSC center or other entity on the network using conventional transport methods and protocols such as SS7. As explained in the prior art description, the handling of telephone connections in this configuration is relatively obvious, but the handling of messages presents particular difficulties. This application is directed to ensure that both devices 14 and 16 have a common picture of the status of messages sent / received from their common number. In the current system, the SMSC center or associated device is adapted using home routing to receive all messages intended for or received from the user. The SMSC or associated device has a database 12 for storing received messages. The associated device may, for example, be a scalable IMAP server. The database can be in the form of SQL or a similar database. Similarly, each phone has a local data storage 18 and 20 for storing messages. It should be noted that the local data store will be very small, as it serves only one user, while the data store 12 can store messages of all users on the network and will therefore be significantly larger and more complex.

[0023] The operation of the system will be better understood with reference to an exemplary method that starts with the arrival of a text message for the user from the sender. The system stores the content of messages in the database structure in a data warehouse 12. Each message is uniquely identified in the database. This unambiguous identification can be accomplished with a unique identifier for each message that will be incremented for each new message. In addition to the textual content of the message, other information contained in the message will also be stored, including the sender's address and the message's time stamp.

[0024] Alternatively, each message can uniquely identify the sender of the message (OA), the message destination (Dest) and the smaller unique identifier (ID). It should be noted that in the latter case, a smaller unique identifier can be used, because although the SMSC can process millions of messages, the number of messages that one user can send to another is relatively small.

[0025] In some arrangement, a unique ID may be generated from a combination of sender's address, destination and message time stamp.

[0026] In Fig. 5 (a) the content of an example received text message is shown from which a corresponding entry in the database could be created. After saving the message, the system places the contents of the received SMS in a binary coded text message, as shown in Fig. 5 (b), and sends a shared number to phones 14 and 16 sharing. It should be noted that a conventional prior art telephone not adapted for use in the present application would not consider an incoming binary coded SMS as a text message, and how such telephones would respond to such incoming messages would depend on the configuration of individual telephones.

[0027] By contrast, telephones 14 and 16 are particularly adapted to respond to incoming binary coded messages of this type. Particular adaptation can be accomplished by adding a software application to the phone or by specifically adjusting the functionality of the phone's operating system. In the first option, the additional software application is an alternative messaging application that looks favorably to the user as if the existing messaging application on the phone was being used.

[0028] A header with user data is placed in each binary coded message, which is generally known to experts in the field, although it does not serve the purpose described herein. The presence of this header with user data indicates the setting of the header indicator with user data in an SMS-DELIVER message (see for example chapter 9.2.2.1 of the 23.040 3GPP standard). The user data header may contain 0 or more information item identifiers (IEIs) Information-Element Identifier) ​​specified in chapter 9.2.3.24 of the 23.040 standard. It is possible to enable IEI 0x04 / 0x05, which specifies the "application port" (PORT) to which the message is directed. Using this mechanism, the messaging application can be associated with one or more destination ports via configuration data, and when receiving a message addressed to that port, the phone calls the application to process the message.

[0029] An alternative approach would be to use a proprietary value for Protocol-Identifier (TP-PID), as defined in chapter 9.2.3.9 of specification 23.040) to signal to the telephone that this message is actually one of those intercepted and re-encoded messages described in this document, and that it should be handled differently, i.e. a message application should be called to process that message. Note that other techniques that invoke an alternative messaging application can also be used. [0030] The message data block preferably includes a number of other values ​​that can be interpreted and used by the messaging application. For example, binary coded text preferably includes a command value (CMD). The command value can be used to identify the purpose for which the message is being sent, i.e. whether the message is a new message, an indication of opening / reading or an indication to delete the message, which will be explained in more detail below. A time stamp (TSTAMP) is also included. Segmentation information (offset \ total length) may also be included to specify cases of such a message size that more than one message is needed to convey the entire text, and this value indicates the total length of the message and the appropriate place (offset) of the current text throughout messages. Note that these values ​​may only be required if the text, UDH (port), command, time stamp and ID do not fit into a single message. The text of the original text message is also encoded along with other elements of the message data block. Note that the message data block may not be required if the message text has previously been sent with a different command value, e.g. if the message is initially sent as a new message, then the next message with the command to delete it does not need to contain the text again, because the message will be clearly identified by reference, and the text is unnecessary.

[0031] Referring to Fig. 3, after receiving 40 binary coded SMS, an application \ function is activated that checks the binary coded message and extracts 44 from the binary coded message the corresponding text message and fields. The text contained in the data block may be encoded in an appropriate manner and may, for example, be compressed by a technique for which a suitable decompression technique is available in the telephone application. The extracted information, including text, is stored in the phone's 46 local data store. Then the application presents the 48 user with a notification, e.g. visual and / or audible alarm, to show 48 the arrival of a new message to the inbox, which is known to most phone users. The message is intended to appear to the user as if it were a conventionally received SMS text message. In the arrangement shown in Fig. 1, both telephones 14 and 16 would receive the message and generate a user alarming message. As described below, the SMS itself can simply be sent to the user's phone as a conventional SMS, with message status updates provided by binary coded messages or other transport mechanism. It should be noted that in such a situation the selected unique ID should be inseparable from the content of the message. In this regard, the message can be seen as uniquely identifiable by the combination of OA (source address, i.e. message sender), DA (destination address, i.e. message recipient) and message timestamp. Note that other elements of the message may be used in addition or in exchange for one or more of these values. However, using a combination of sender (OA), recipient (Dest.) And time stamp provides an efficient ID that typically generates a unique value.

[0032] The user can then open the message on his telephone using the application described above. When the user has read the message, the application on the phone produces a status update message, correspondingly a binary coded SMS indicating the change in the state of the message, i.e. that it has been read. This binary coded SMS properly contains message identification and status change. A status update message is sent 52 to the number associated with the SMSC. It should be noted that the phone does not necessarily make any changes to the status of the message on the phone, i.e. the phone may still show the message as unread.

[0033] After receiving a binary coded SMS about the status change, the SMSC updates the status of the message in its database 12, i.e. to indicate reading the message. Then the SMSC generates another status update message, for example in a binary coded SMS, indicating that the status of the message has changed, i.e. that it has been read. As before, the binary coded SMS preferably includes message identification and status change. The status update message is then sent 56 to the user's phone (s).

[0034] After receiving this message, the telephones update the status of the message in their local data stores to show the message as read. It should be noted that although the message was read by one of the phones, the server is the element that sent the command to update local data stores. Thanks to this, the SMSC center is the first place where messages and their status are stored. For users, the application can be configured to temporarily show on the phone the message as read for a short period of time, until the arrival of the proper "mark as read" command confirming this state. In the event that such a command does not arrive within the specified time, the application may again mark the message as unread.

[0035] The same functionality can be used for sending messages as will now be explained with reference to the flowchart of Fig. 4. It is known to save in a conventional telephone from the prior art copies of sent messages. Of course, in a situation where several phones share a number, if one phone sends a message, it can keep copies of the message it sends, but other phones will not see the message.

[0036] The present application also solves this problem. The user can create and send a 60 text message using conventional means on his phone. The telephone may then conventionally send this SMS text message to the SMSC. Unlike prior art phones \ applications, once a message has been sent, it is not necessary to save a copy of that message on the phone as a sent message (i.e. it does not appear as a message sent in the folder with sent messages).

[0037] Upon receipt of 62 messages at the SMSC, a unique identifier is generated and the message 64 is stored in the database 12. The message is then sent 66 to the destination using conventional techniques. The SMSC may then send a status update message to the user's telephone (s) indicating that the message has been sent. In particular, the SMSC may create a binary coded SMS containing the content of the sent SMS and a status indicating sending. This binary coded SMS is then sent to the user's phones 14 and 16, which in turn extract the content and store the extracted message locally in their respective data stores 18, 20 as the sent message. In this way, although the specific message may actually have been sent by the first telephone 14, both telephones may have a copy of that message.

[0038] If the user performs a function that changes the status of a message (e.g., deleting a message or moving a message to another folder), the telephone may send such a request to the SMSC as a binary coded message identifying that message and changing the status; the SMSC center updates the status of the messages in the SMSC database and then sends the corresponding binary coded status change messages to the phones to reproduce this change in the data stores on the phones. It should be noted that user messages in individual data stores on telephones may be different from those in the SMSC database, for example due to memory limitations. Thus, for example, if a message is requested to be deleted, the SMSC may simply update the status of the message in the database to show it as deleted. However, this message may still be present in the database. On the contrary, when an indication from the SMSC center is received that a message with a specific designation has been deleted, the telephone may respond by deleting the message with such designation from the local data store.

[0039] Another advantage of the system is that the content of the SMSC database can be made available to users via alternative interfaces. One of these interfaces may include an IP-connected telephone, such as a softphone, which is a software application typically running on a desktop computer. Such softphones use an IP connection to connect to the telephone network (both personal / company PBX and large PSTN), typically using a SIP-based protocol. They have all the capabilities of a normal phone, make calls, receive calls, often including a kind of client application to handle messages that behave like SMS. An example of such a device is "A1 over IP" offered by Mobilkom Austria. In such arrangements, the mobile telephone may be duplicated on the computer as a softphone, wherein the SMS sent to / from the mobile telephone may be duplicated on the softphone by SMSC sending to the softphone via the IP connection the updates described above.

[0040] Another option would be to provide a web interface similar to 02 Blue Book described above. However, unlike the Blue Book service, the web interface would be adapted to present a representation of a user's message that corresponds directly to the contents of the message boxes on the phone, instead of just a copy of all messages sent and received by the user. Moreover, it should be noted that due to the option of sending status update messages to the phone, the message can be deleted \ moved via the web interface and this change can be propagated to the user's phone (s). It should be noted that other functionalities may be used, including the ability to restore deleted messages on the phone, so that a user using the web interface could view messages marked as deleted and restore them. In turn, the SMSC center would update the database showing the restore status and would send the update via binary coded text messages to the user's phones.

[0041] It should be noted that the functionality \ message settings on telephones can also be stored centrally in the SMSC and reproduced on telephones. For example, the known option is to save \ n ie saving a copy of sent messages. If the user has chosen to change this option on their phone, an application could send a binary coded SMS to the server indicating that it was desired to change this option. This option could be updated in the database, and a binary coded SMS sent to phones to duplicate the settings in the SMSC database. Similarly, if a user created folders for their messages, information about these folders could similarly be sent as updates.

[0042] Further advantages are illustrated by the arrangement of Fig. 6, which can be seen as a repository of messages 88 for SMS messages for a number of users. As shown in Fig. 6, this repository can be adapted to intercept SMS using, for example, home routing techniques as described above.

[0043] After the SMS has been intercepted by the message repository messaging mechanism 82, the messaging mechanism may cause the SMS to be retained in the message repository data store, as described above with reference to Fig. 1. As described above, the data store may preferably be created in a conventional database structure, e.g. SQL databases. The messaging mechanism also sends an SMS to the user (or, more specifically, to his SMSC center). When the message is stored in the message server, the sender's SMSC can send delivery confirmation to the sender if it was requested.

[0044] It should be noted that the SMS may not be stored in its entirety. Instead, the required items can be extracted from the SMS. For example, the text and information from the message header is sufficient to uniquely identify each message. In this regard, the identity of the message sender and recipient of the message, and a message time stamp would be sufficient to uniquely identify the message. Of course, it is desirable to also store the text content of the message.

[0045] To increase the speed of access to the data store, a unique identifier for the message can be generated using, for example, a hash function or similar technique performed on information necessary to uniquely identify each message, which, for example, can be the sender, recipient and time stamp. It should also be noted that the hash function may not be used and the unique ID may simply contain a combination of sender, recipient and time stamp.

[0046] Unique identifiers can be stored in a data warehouse and can be associated with their messages using conventional database techniques. It should be noted that the unique identifier can be stored implicitly by storing the values ​​from which it is created, for example sender, recipient and time stamp.

[0047] It should be noted that, although the unique identifier may be used to improve the performance of the referencing data warehouse system and / or for other reasons which will become clear below, with respect to users connecting to the repository it may remain beneficial to also store some information from the message header, for example, the sender, recipient and timestamp of each message to make this information available to users.

[0048] Each SMS has a status associated with it. The status of each message is also stored in the repository's data store. In this regard, the repository may initially store the status of an "unread" message, indicating that the recipient has not read the message. Note that the unread message is not the same as the undelivered message. Because the message can be successfully delivered to the recipient's mobile phone and remain in the inbox for some time before the recipient actually opens the message and reads it.

[0049] The repository may be equipped with a web interface 88, allowing the user to access messages in the repository using a conventional web page accessible via a web browser on a computer. The web interface can be adapted to present to the user a list of his SMS folders and messages contained in each folder using internet programming techniques known to experts in the field. Security and other techniques, including customization to your preferences, can be implemented in the web interface using techniques known to experts in the field, including the use of passwords and "cookies". Similarly, to secure data privacy, the web interface can use secure communication methods, including, for example, SSL and https.

[0050] As described above, the user's mobile telephone may be adapted to respond to messages and user actions on these messages, which will now be explained with reference to Fig. 7, which is a schematic diagram of a conventional mobile telephone arrangement 14 comprising a transmitter \ receiver 90 for broadcasting \ receiving voice and data. For simplicity, the elements related to voice have been omitted. The data interface 92 receives data from the receiver circuit and determines the appropriate data application. In this regard, the data may be an SMS, MMS data or, for example, IP data. Again, for simplicity, only the data path for SMS is shown. The data interface can also provide data from the application to the transmitter.

[0051] As in a conventional mobile telephone arrangement, the data interface provides SMS data to the SMS messaging application 94. In turn, the messaging application stores the received messages in the local messaging data store 96. As known to experts in the field, the messaging application can notify the user of the arrival of messages, display messages to users, and allow users to delete messages or create messages.

[0052] However, unlike the conventional arrangement, the repository application 98 is provided on the telephone. The repository application can be installed on the phone by default or can be installed later by the user. The repository application is responsible for interacting with the message repository described above. The repository application can be separate from or contained in the messaging application and the phone's data interface. As described above, the messaging \ data application can be replaced by another messaging \ data application that includes the functionality of the repository application.

[0053] For example, the repository application can be a stand-alone application running in the background of a telephone that periodically looks for changes in the content of a message data store.

[0054] An exemplary repository application operation mode will now be described with reference to Fig. 8. It should be noted that if the repository application is integrated in the messaging application, then the detection of the arrival of an SMS is inseparable from receiving 100 SMS. As described above, the repository application can extract an SMS from a received binary coded message and store the SMS and the status of that SMS in the message data store. Note that the status of an SMS may be indicated by its location in the data warehouse. It should be noted that if an SMS is placed in a binary coded message, it must first be extracted. For example, a message can be identified as a sent message if it is placed in the sent messages folder.

[0055] Upon detection 108 of a change, e.g. a change in the local status of a message from read to unread, the repository application may cause 110 status update messages to be sent to the repository via the data interface and thus the transmitter. As described above, the status update message can be sent in a binary coded text message or using another transport mechanism available between the phone and the repository. Alternatively, the repository application may be adapted to send status update messages using an alternative transport mechanism, for example via an IP connection to the repository. Preferably, the status update message will identify the message, for example by means of a unique identifier that can be generated based on the content of the message in the same way as it is done in the repository. Preferably, the status change message also indicates the change that has occurred.

[0056] Similarly, the repository application may respond to status change messages received from the repository. As described above, a status change message can be received from the repository as a binary coded text message. Alternatively, a status change message can be received using an alternative transport mechanism, such as an IP connection between the repository application on the phone and the repository. Similarly, USSD (Unstructured Supplementary Service Data) can be used to send status change messages.

[0057], The repository application is adapted to identify the message and update the status of the message in the message data store on the phone after receiving status change messages from the repository. Updating the status of a message may include deleting the message from the data store. [0058] Although many users may only have an inbox and outbox in the local telephone database, it should be noted that certain telephones allow users to create further folders and move messages between folders in their message database. Advantageously, the repository application can also be adapted to retrieve folder information from the message data store and provide this information to the repository. The repository application can do this for all folders during the initialization process, and later when the folder changes, e.g. it is added, removed or moved. Folder information can specify the structure along with the folder names. Note that in this arrangement, status update messages sent by the repository application from a user's phone may contain "moved" status, indicating that the message has been moved. Status update messages can also indicate the folder to which the message has been moved. [0059] Similarly, the repository may be adapted to store folder information for each user received from each user's repository application. Folder information can specify structure along with folder names. In addition, status update messages sent from the user's mobile phones may contain a "moved" status, indicating that the message has been moved, along with an indication of the folder to which the message was moved.

[0060] Although the above description related primarily to the use of binary coded messages for distributing message status updates and messages, it should be noted that alternative transport mechanisms may also be used, including, e.g., the use of an IP connection or the aforementioned USSD mechanism.

[0061] In a further arrangement, the lessons learned from this application may be used in circumstances where the repository does not necessarily have access to the user's mobile network SMSC infrastructure. Note that it is not feasible to intercept the message in this case. The technique described below can be beneficial even when access is possible. For example, if a user has multiple mobile phones sharing a number (multi-SIM), if one of these phones does not allow modification of their software, it should be noted that SMS messages encoded in binary coded SMS messages will not be visible on this phone. It is advantageous when SMS messages are sent to the user conventionally from the telephone network. In this configuration, status updates indicating actions performed by the user on messages on phones can be sent by the repository application present on the phone. It should be noted that if there is no repository application on the phone, SMS messages can be received and sent from this phone anyway.

[0062] In particular, the repository application on the user's telephone is connected to the message repository, e.g. via IP or SMS support. In this arrangement, the mobile network may be adapted to conventionally deliver messages to a user's mobile device. It should also be noted that in this system the repository would not have to be part of the user's mobile network, but only accessible through the user's network. If an IP connection is used, the repository and its messaging mechanism need not even be on the mobile telephony network as such, but only be connected via the Internet or a similar network.

[0063] This further arrangement will now be explained with reference to the flowchart shown in Fig. 9. After receiving 112 SMS messages, the repository application can be adapted to generate 114 unique IDs for messages based on the message itself. As with a conventional messaging application, the repository application can store 116 copies of messages in a local message store. It can also store a unique message ID and message status. However, unlike previous applications, the repository application on the user's telephone may be advantageously adapted to send 118 copies of messages to the repository messaging mechanism. It should be noted that in this context of this mode of operation and the previously described implementation, the functionality of the message service mechanism and the status update mechanism can be implemented together. A copy of the message may be a reduced form of the message, containing only the required information, which may, for example, include the content of the text message, sender, recipient and time stamp. After receiving a copy of the repository, it stores the copy in the repository's data warehouse.

[0064] It should be noted that if the user has multiple telephones, the network may be adapted to deliver messages to only one telephone (as described above in the description of the prior art). However, in the absence of such customization, multiple copies of the same message can be received by the message repository from the repository application on different user's phones. In this layout, the repository can be adapted to check for the existence of a message before saving the message. As before, a unique identifier may be stored with each message. [0065] Once the repository has updated its data warehouse, it can publish a message to the user's other phones by means of status update messages via the IP connection of the message repository with individual phones.

[0066] In turn, when the telephone repository application 120 detects a change in the status of the telephone, e.g. a user opening an unread message, the repository application may send a status update message to the message repository as previously described. In this way, the message repository is constantly updated with the changes made in the phones. As described above, the message repository can send status updates to phones reflecting any changes in the status of messages taking place in the repository database, both direct, e.g. through user interaction with the message repository via a web browser, as well as indirect, when a message status update is sent from user's phone.

[0067] It should be noted that the methods, applications and systems described herein allow the user to effectively transfer the messaging functionality of the telephone to the repository. The messaging functionality is no longer associated with a specific phone.

[0068] It is therefore to be noted that although the present application has been described with reference to the benefits achieved for a set of a number of telephones of one user, there are numerous advantages even with only one telephone.

[0069] For example, in the event that a user loses his telephone and replaces it with a newly purchased one, the new telephone could use the synchronization function to retrieve replicas of the user's message from the data store. The download could be done by the binary coded text messages described above or by alternative means including an IP connection. Similarly, if a user accidentally deleted from the phone the message they wanted to store, they could refer to the repository website to check messages previously deleted from the phone, which could be placed, for example, in the trash folder, and then request that the message be restored. Such a message could be restored using the techniques described above by resending the message to the phone. In this case, the command could be used to identify the message as intended to be entered into the local data store, but shown as read, i.e. not a new message.

[0070] Furthermore, although the significant benefit of the present application is that the information is transmitted using the existing SMS infrastructure as described above, the control messages sent between the repository application in the telephone and the repository itself can use an alternative channel, such as an IP connection, which could be implemented in a software phone. Furthermore, as explained above, the repository does not need to be included in the network messaging infrastructure.

[0071] The above description should be regarded as exemplary and the invention should not be considered as limited by this description, it is defined by the scope of the following claims.