System for transmitting/receiving short messages (sms) between mobile terminals and remote servers

TRANSMISSION SYSTEM / RECEIPT OF SHORT MESSAGES (SMS)

BETWEEN MOBILE TERMINALS AND REMOTE SERVERS

OBJECT OF THE INVENTION

The invention in question, aims to provide a two-way communication system of short messages between mobile terminals and remote servers, and all this so that users of mobile terminals do not have to enter short messages to send directly, rather, they are introduced from a direct interpretation format, which is translated into the format of short messages, and conversely, that is, the short messages received are translated into direct interpretation format; all this in such a way that the introduction of short messages is carried out in a simple way and the interpretation of the short messages received is carried out immediately.

The invention is preferably applicable in those cases in which it is required to establish a bidirectional communication by means of short messages between a remote server, such as, for example, a server of a company or corporate entity, with its staff or contract displaced outside the facilities of the company. the company, in a way that facilitates the communication between the staff or contracts displaced with the remote server. BACKGROUND OF THE INVENTION

The sending of short messages among mobile phone users is very much used nowadays, for which they communicate with a short message server center (SMSC) through a GSM mobile network (Global Mobile System), UMTS (Universal Mobile Telecommunications System), GPRS (General Radio Packet Service), etc.

Regarding mobile terminals, these basically consist of the user terminal itself that includes the keyboard, screen, antenna, etc; and in addition, the mobile terminals include a mobile phone SIM card (Subscriber Identity Module) that is used when the network is GSM, or a USIM smart card (Mobile Phone Card for the UMTS communication network).

Given the importance of the added value of short messages, they are being progressively introduced to a greater extent, but their direct use requires that the user write the information as it should be received by the recipient (person or machine) with criteria that can be be very strict in the case that the message is directed to a machine such as a remote server. This produces frequent errors in the communications made, which lead to inefficiencies and extensive economic losses, having to manually perform a composition of complex messages, by people who may lack in most cases of computer skills, as is the case in which a corporate entity needs to communicate with its staff or contracts out of the facilities of the corporate entity.

This problem is accentuated when the information transmitted is bidirectional, that is, when the person carrying the mobile terminal receives information from a remote server, to which it must respond with a very specific confirmation, and vice versa.

On the other hand, the use of short messages directly requires that the servers to which the communication is directed must implement new software to recognize the reduced format of short messages.

For all these reasons, there is no system in which bidirectional communication can be made between a mobile terminal and a remote server by means of short messages.

To achieve this bidirectional communication, there are currently known management systems for companies based on web pages accessible via the Internet or an Extranet that allow their employees or contractors to update afterwards the status of the entrusted works when they occur outside of the installations of the own company, not having of this form of the necessary information of management in real time for not arranging or being very complex the adequate means of communication for this type of personnel.

DESCRIPTION OF THE INVENTION In order to solve and achieve the aforementioned objectives, the invention has developed a new system that makes it possible to send short messages between a remote server, such as a company or corporate entity, and a mobile terminal, for example. so that the staff or contracted displaced outside the facilities of the company can carry out bidirectional communication with the remote server through a mobile terminal, and all this without the need to enter the short messages directly in the mobile terminal, simplifying its use and avoiding errors in the communications made.

The system of the invention starts from the conventionally known mobile terminals that basically comprise a user terminal and a mobile phone smart card (SIM, TJSIM), and communicate with a short message server center (SMSC) through a network of mobile telephony (GSM, UMTS, GPRS), which in turn communicates with remote servers such as a company or corporate entity.

For this purpose, the invention is characterized in that the mobile terminals comprise means for translating short messages (SMS) received into a direct interpretation format, and with means for presenting the direct interpretation format for the user to immediately interpret the received SMS . In addition, the mobile terminals are provided with means for presenting at least one message in a direct interpretation format, means for selecting at least the presented message and means for translating the at least selected message of direct format to an SMS message, so that These features allow the user of the terminal to enter and send short messages in an affordable and immediate way without having to enter the short messages manually directly avoiding communication errors.

The means of translating short messages into a direct interpretation format are constituted by an analysis module that is equipped with means of detecting the validity and nature of the message (it may be a message of acceptance or rejection of some transaction previously sent to the remote server of the corporate system, or a new transaction received from the corresponding corporate system).

In addition, the means of translating short messages into a direct interpretation format comprise a transaction management module that receives the result of the analysis carried out, processes it and accesses the database from which it performs the translation into the format of direct interpretation. In order to communicate with the user, a user interface module of the mobile terminal has been provided, from which the format of direct interpretation to the user of the mobile terminal is shown. The means for presenting the direct interpretation format as well as the means for presenting at least one message of direct interpretation are determined by the screen of the mobile terminal, which is connected to the transaction management module through the user interface.

The means of selecting the at least message in direct interpretation format are determined by the mobile terminal's keyboard, the user interface, and by the transaction management module.

Regarding the means of translating messages in direct interpretation format to SMS, these are constituted by the transaction management module itself that accesses the database and delivers the different data to an SMS composition module from which they are transmitted to the SMSC.

Under normal operating conditions, a plurality of messages of direct interpretation format are provided, among which at least one is selected, by means of the keyboard, so that from this the SMS is composed, and sent to the SMSC. Evidently this plurality of direct interpretation format messages have been previously established and stored in the database. It is possible that at least two messages of direct interpretation format are sequentially selected, in order to compose the SMS and send it to the SMSC.

In an embodiment of the invention the means described above, are provided in the user terminal, but obviously, and according to another embodiment of the invention, these means can be included in the smart card of the mobile phone (SIM, USIM) . In order to establish communication between the SMSC and the remote servers, a transaction server is provided that communicates with the remote server and with the SMSC, through a communication line. In the preferred embodiment of the invention, the communication line is Internet, but obviously it can be any other type of line, such as a cable.

There is also the possibility that the transaction server is provided in the SMSC itself and therefore no communication line is required.

Evidently, the transaction server has a particular architecture, which comprises means for converting SMS messages, provided by the SMSC, to a format according to the communication protocol established in the communication line, also comprising means of converting the format according to the protocol of communications, established on the line, to SMS messages. Both means of conversion indicated above, are constituted by a message analysis module that is equipped with means of detecting the validity and nature of the message (determines whether its content is an acceptance or rejection of a transaction made previously or is treated of a new transaction), a transaction management module that accesses a database from which it performs the translation to the SMS format by means of a message composition module. In addition, the transaction server has a communications management module to allow communication with each remote server.

It is possible that different communication management modules are included to allow communication with different remote servers. Therefore, it could be the case that there is a communication management module for each remote server.

In addition, the transaction server has different means of transmitters / receivers for communication with remote servers. It could also be the case that it includes a single sender / receiver medium for communication with remote servers. On the other hand, the remote servers comprise means of receiving / issuing the SMS equivalent in the communications protocol established in the communication line of each server.

Each communication management module is connected to a database to verify previously established security parameters and reject or accept the communication based on the result of the verification.

Therefore, human errors are avoided by the system of the invention described, since the user of the mobile terminal only has to select, through an interface, the information (person-machine) that you want to send, obtaining an optimum degree of reliability. Based on the description made, it is easily understood that the system of the invention is adaptable to any corporate system, and it is also applicable on any mobile telephony communication network. Below to facilitate a better understanding of this specification and forming an integral part thereof, a series of figures are attached in which the object of the invention has been represented with an illustrative and non-limiting character. BRIEF DESCRIPTION OF THE FIGURES Figure 1.- Shows a functional block diagram of the general structure of the system of the invention. Figure 2

Figure 3 shows a functional block diagram explaining the case in which the user of the mobile terminal is the one that sends a short message to the remote server.

Figure 4 shows a functional block diagram of a possible embodiment of the mobile terminal.

Figure 5.- Shows a functional block diagram of a possible example of realization of the transaction server that is part of the system of the invention to allow establishing bidirectional communication of short messages between users of mobile terminals and remote servers.

DESCRIPTION OF A PREFERRED FORM OF EMBODIMENT

Next, a description of the invention is made based on the figures previously commented.

The described example of the invention refers to the case in which a remote server, belonging to a company or corporate entity, establishes bidirectional communication by means of short messages with a mobile terminal belonging to a worker of the company or of a contract, and that is displaced outside the company's facilities.

For this the remote server or corporate server 1 is connected to a transaction server 2 through a communication line 3. In turn, the transaction server links to a short message service center (SMSC) 4 which communicates through the mobile telephone network 6 with a mobile terminal 5. The transaction server 2, like the SMSC 4 belong to the mobile operator 7, so that the transaction server 2 adapts to the communications protocol established by the corporate server 1, as will be explained later, so it is not necessary to make modifications to the structure of the corporate server 1.

Figure 2 shows the different steps that are followed to send a message from the corporate server 1 to the mobile terminal 5. First the corporate server 1 will obtain the necessary data to be able to compose a message to be sent to the mobile terminal 5, and establishes a session with the transaction server to which it makes a transaction request 8. Next, the transaction server 2 validates the received request and composes all the data for its delivery 9 in SMS format to the SMSC through the protocol that has been established between both elements. The transaction server 2 can be included in, or separated from, the SMSC 4 itself, in which case it is connected by means of a communication line, such as Internet, cable, etc.

When the short message is received at the mobile terminal, it processes it and generates a new reception confirmation message in which the received transaction is accepted or rejected, and 11 is sent via the mobile telephone network 6 to the SMSC which delivers the short message originated in the mobile terminal to the server of ^• transactions 2 in the communication protocol and connection method established between both.

The transaction server 2 recognizes the received message as confirmation of reception of a specific prior transaction, and analyzes whether the transaction has been accepted or rejected, and adapts the response 13 to the corporate server in question, closing the session established between them.

With the aid of FIG. 3, the different steps that occur when the short message occurs in the mobile terminal 5 and is sent to the corporate server 1 are described.

In this case, the necessary data is obtained in the mobile terminal 5 in order to be able to compose the desired message, as will be explained later, guided by menus, and proceeds to send the short message (SMSC) 14 through the network of mobile telephony 6.

The SMSC then sends 15 the short message by means of the protocol and the connection established with the transaction server 2, which analyzes the received message and, depending on its destination, establishes a connection 16 with the corporate server 1 according to the protocol and connection method established between both.

Next, the corporate server 1 confirms receipt of the transaction by accepting it or rejecting it by means of a response 17 to the request 16.

Then the transaction server generates a new short message to the SMSC and sends it to it 18. This message tells you the result of the transaction. Finally, the SMC delivers 19 by sending a short message, through the mobile telephone network 6, confirming the acceptance or rejection of the transaction.

Once the communication process is described generically in both directions, the operation of the mobile terminal whose block diagram is shown in Figure 4 is described below.

First, the process followed when the short message transaction is made from the corporate server 1 to the remote terminal 5 is described.

In this case, when the remote terminal 5 receives a new short message through the SMSC, it sends it to an SMS reception module 23 resident in the smart card (SIM or USIM). It could also reside in the user terminal 20 of the mobile terminal 5.

The SMS message receiving module 23 delivers the received signals to a message analysis module 24 by means of which it is verified whether the received SMS message contains valid information for the system or not, so that in case it does not contain valid information , the message will be ignored.

If, on the contrary, the received message contains valid information for the system, it is analyzed what type of messages it is; This may be an acceptance or rejection of a transaction previously sent to the corresponding corporate server, or of a new transaction received from the corresponding corporate server, as explained above.

Once the message analysis module 24 has determined the consistency of the message received, as well as the type of message in question, it delivers this information to a transaction management module 26 that is responsible for processing the information received, so that if the received message is of acceptance of a previous transaction sent to the corporate server, the transaction management module 26 communicates with a database 28, and more specifically with a transaction database 28a in which changes the state of the transaction to the same state as that indicated in the received acceptance message. The transaction database 28a includes the different transactions that can be received or sent by the user of the mobile terminal, for which these must have been previously stored.

If the received message is a rejection of a previous transaction sent to the corresponding corporate server, the transaction management module communicates with the transaction database 28a to change the state of the transaction to the last valid previous state it had stored before. of the shipment of the transaction. In the case in which the received message contains a transaction, the process to be followed in the transaction manager module 26 is the following: a) If the received transaction is registered in the transaction database 28a, the data characterizing the the new transaction is not stored in the transaction database 28a, and the user is informed through an interface module 27, and more specifically through an event notification interface module 27a, and then a short rejection message is sent to the received transaction. For this, the transaction management module 26 communicates with a message composition module 25 providing the necessary data, which are in the database 28, and more specifically in the transaction database 28a and on a database of configuration data 28b, so that the message composition module 25 can compose a rejection message. Subsequently said message is provided to an SMS 29 transmission module from which it is transmitted to the SMSC. b) If the mobile terminal 5 has the capacity to process a new transaction, the data characterizing the new transaction is stored in the transaction database 28a, whereupon the user is informed through the event notification interface 27a. A short acceptance message is then sent to the received transaction. For this purpose, the transaction management module 26 communicates with the message composition module 25 to which it provides the necessary data from the database 28 so that it can compose an acceptance message. Subsequently said message is sent through the SMS 29 transmission module. C) If the transaction manager module 26 does not have the capacity to process a new transaction, the data characterizing the new transaction is not stored in the database of the transaction. transactions 28a, after which the user is informed through the event notification interface module 27a.

Next, the process followed by the mobile terminal for the case in which the short message transaction is made from the mobile terminal 5 to the corporate server 1 is described.

In this case, the user, through the keyboard 22 and the screen 21 of the user terminal 20, accesses the interface 27, and more specifically, a transaction sending interface 27b. The transaction sending interface 27b requests the transaction management module 26 to obtain the internal identifiers of each of the possible operations that can be carried out on any existing transaction and previously stored in the transaction database 28a. These identifiers are presented to the user through the screen 21 in the form of a menu, and through the transaction sending interface 27b. The user then selects one of said menu identifiers through the keyboard 22 and the transaction sending interface 27b notifies the transaction management module 26 to obtain the internal identifiers of each of the existing transactions in the database of transactions for the selected operation type. These identifiers are also presented on the screen 21 through a menu and through the transaction sending interface, for the user to select one of them through the keyboard 22, point from which the transaction sending interface 27b notifies it to the transaction management module 26 and depending on the type of operation and transaction selected, the transaction sending interface will request, on the one hand,

Therefore, the different possibilities of messages to be sent are displayed on the screen to the user and this is selecting the different possibilities, so that after having selected and / or introduced the user all the necessary information, the transaction management module 26 sends to the message composition module 25 the data selected and / or entered by the user, as well as some others existing in the configuration database 28b, so that the corresponding message can be generated. This message is delivered to the SMS message transmission module 29 which sends the SMS message obtained to the SMSC 4.

Evidently, the user of the terminal can consult the transactions that can be made and that were previously stored in the transaction database 28a, as already explained above.

For this the user accesses the interface 27, and more specifically to a transaction inquiry interface 27c through the keyboard 22 and the screen 21, so that this interface 27c provides the user with specific menus that depend on the needs and functions required by the user. corporate server 1. Therefore, the data stored in the database 28a and 28b, depend on the needs of the company or corporate server as already indicated. To perform the query, once the transaction inquiry interface 27c has been accessed, it requests the transaction management module 27 to obtain the internal identifiers of each of the transactions existing in the transaction database 28a. These identifiers are presented to the user through screen 21, through the transaction inquiry interface 27c. From this moment the user selects one of these indicators (presented by means of a menu, as was mentioned in the previous cases) through the keyboard 22, and the transaction inquiry interface 27c notifies the management module of transactions so that, depending on the selected transaction, it will provide all the information related to said transaction in order to be presented on the screen. It is also possible to configure transactions, so that the user has the possibility to modify certain existing information in the configuration database 28b, according to the needs of its corporate server 1. To do this the user, through the keyboard and the terminal screen accesses interface 27, and more specifically to a configuration interface 27d, which requests the transaction management module 26 to obtain the internal identifiers of each of the possible configuration operations that can be carried out on the configuration data base 28b. These identifiers will be presented to the user through the configuration interface 27d, and when the user selects one of them, the interface notifies the transaction management module 26.

Depending on the type of operation selected, the configuration interface 27d requests, on the one hand, the transaction management module 26 to obtain the internal identifiers of any other information necessary for the type of modification that is desired to be made and that requires some selection by the user, and on the other hand asks the terminal screen any other additional information. After the user has selected and / or entered all the necessary information, the transaction management module 26 stores all the information in the configuration database 28b. Therefore, through the configuration interface, the user is provided with the means to configure the way to communicate with their corresponding corporate server.

The corporate server 1, is not described, because it can present any configuration in the way that is considered most optimal and effective according to the needs of each company. Regarding the transaction server 2, its block diagram is shown in Figure 5, and its operation is described below according to the different possibilities offered by the system and that were described above.

First, the case is described in which the corporate server sends a message to the mobile terminal; in which case said corporate server 1 establishes a session, in the protocol and through the communication network 3 that is determined, with a communications management module 31 through an emitter / receiver 30.

In the embodiment of FIG. 5, the possibility of connecting a plurality of corporate servers 1 to the transaction server 2 is contemplated, for which it has an emitter / receiver module

30 and with a communications management module 31 for each of the corporate servers 1 to which it is connected.

At this point it is important to note that this structure is necessary in the case that corporate servers 1 use different networks and communication protocols. Therefore, it is obvious that corporate servers 1 that use the same communication line and the same protocol, will be connected to the same sender / receiver 30 and to the same communication management module 31.

Accordingly, the communications management module 31, as well as the sender / receiver 30, can be specific to each company, or on the contrary, they could be generic. When the communications management module

31 receives a session establishment request, as described at the beginning of this section, queries in a database 33, and more specifically in a configuration database of security parameters 33a, the security parameters established for each type of connection, so that depending on the query made, it rejects or accepts the session establishment request.

Once the session is accepted, the corporate server 1 sends the transaction that you want the mobile terminal to receive. This transaction is delivered by the communications management module 31 to a transaction management module 32 which verifies the format of the transaction according to the information available in the configuration database 33a, and if the format is not the appropriate returns an error to the corporate server. In addition, it obtains from the configuration database 33a the analysis and transformation rules that it must apply to the received transaction in order to adapt them to the requirements of the applications of the mobile terminal to which the message is destined, and then it makes a record of the data of the transaction in the database 33, and more specifically a database of transactions 33b.

Next, the transaction management module 32 sends to a message composition module 34 all the data necessary for the composition of the short message to be transmitted.

Next, the message composition module takes all the data provided by the transaction management module and composes the short message that is to be transmitted and sends it to a message transmission module 35 through which it is sent to the SMSC 4 .

The message transmission module 35 is responsible for maintaining a connection with the SMSC, in the protocol that is adopted and by direct connection (in the case in which the transaction server is part of the SMSC 4 itself) or by means of a line of communication. communications (in the case in which the transaction server 2 is remote from the SMSC). In addition, the message transmission module is responsible for managing the delivery of the short message to the SMSC, guaranteeing delivery of the message by means of a retry algorithm that is established, or else it will return an error if delivery is not possible.

The process continues with the awaiting confirmation by the application of the mobile terminal 5 of the acceptance of the transaction. For this purpose, a message reception module 36 is provided, which is responsible for being permanently connected in the protocol adopted by direct connection or a communication line, to the SMSC 4, so that it will receive all the messages addressed to any of the corporate servers, and it is provided to a message analysis module 37.

The message analysis module 37 determines in each message whether its content is an acceptance or rejection by the mobile terminal, or it is a new transaction, and it is sent to the transaction management module 32. In the event that the received message is an acceptance or rejection of a previous transaction, the transaction management module 32 analyzes the data of the acceptance or rejection message and obtains from the transaction database 33b the stored data relating to the transaction, and furthermore obtains from the configuration database 33a the transformation rules that you must apply to respond to the corporate server with the result of the transaction.It then sends the response of the transaction to the communications management module 31, which returns the result of the transaction to the corporate server and closes the session established with it, provided that the establishment of a permanent session is not contemplated.

In the event that no acceptance or rejection message is received in the message reception module 36, after a time established in the configuration database 33a, an error message indicating the situation is returned to the corporate server.

The following describes the case in which it is the mobile terminal 5 that sends a transaction to the corporate server 1. In this case the message reception module is permanently connected, in the adopted protocol and by direct connection or through a line of communications, with the SMSC, so that it receives all messages addressed to any of the corporate servers, providing these messages to the message analysis module 37 that determines whether its content is an acceptance or rejection of a transaction by the application of the mobile terminal, or it is a new transaction. The acceptance or rejection has already been described above, and in the case of a transaction, it is sent to the transaction management module 32 from the message analysis module 37, so that it verifies the destination of the transaction and the format of the transaction according to the information available in the configuration database 33a. If the format is not appropriate, it returns an error of rejection of the transaction.

The transaction management module 32 obtains from the configuration database 33a the analysis and transformation rules that it must apply to the received transaction in order to adapt them to the requirements of the corporate server.

Next, it records the transaction data in the transaction database 33b. Among the data that is recorded, a unique reference to the transaction that is being managed is included to allow subsequent processes such as the confirmation of the delivery of the transaction. Next, the transaction management module 32 sends the communication management module 31, belonging to the corresponding corporate server 1, the data necessary for the establishment of a session with the corporate server 1, in case this is not permanent.

Once the session is established, the communications management module 31 sends the transaction, through the corresponding sender / receiver 30, to the corporate server, according to the method that is established therein, so that the entry of the transaction is being emulated. data in the same way that data entry is made by a regular user of the corporate server.

Next, the communications management module awaits the response of the corporate system and sends the transaction manager module the result of the transaction (acceptance of rejection of the transaction). In the case of a non-response occurring, once a configurable time has elapsed, an error message is sent. The transaction manager module analyzes the response of the corporate server, and according to the rules established in the configuration database 33a for the particular corporate server, it sends the necessary data for the transmission of the result of the transaction to the composition module of messages, which builds, according to the data obtained, the short message that must be sent as confirmation of the transaction, and delivers it to the message transmission module,