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

SWEDEN (dz) PATENT (13) C2 tu) 525 328

<img file="SE525328C2_D0001.tif" />

(19) SE (si)

International class ⁷

H04Q 7/22

PATENT AND REGISTRATION (45) (41) (22) (24) (62) (86) (86) (83)

Patent issued 2005-02-01

Application generally available 2003-10-27 The patent application was filed on 13/08/2003

Running day 2002-02-26

Tribal application number

International filing date 2002-02-26 Filing date for European patent application Deposit of microorganism (21) Patent application number 0302210-0

Application received as:

Swedish patent application completed international patent application with number PCT / ES02 / 00081 converted European patent application with number (30)

2001-02-27 ES 0100468 (73) (72) (74) (54) (56) (57)

PATENT OWNER Vodafone Group PLC, The Courtyard 2-4 London Road Newbury

INVENTOR

AGENT

NAME

Berkshire RG14 1JX GB

Francisco Contreras Alvarez, Madrid ES Jaime Bustillo Velasco, Madrid ES Santiago Borrero Ortiz, Madrid ES Zacco Sweden AB (publ)

System for transferring short messages (SMS) between mobile terminals and remote servers

CALLED PUBLICATIONS: - SUMMARY

System for sending / receiving short messages (SMS) between mobile terminals and remote servers. The system allows bidirectional transmission of short messages (SMS) between a remote server and a user of a mobile terminal (5) communicating with a short message service center (SMSC) (4) via a mobile telephone network (6). The mobile terminals (5) include first translating means for translating received SMS into a direct interpretation format, and have first reproducing means for reproducing the direct interpretation format in such a way that the user immediately interprets the received SMS messages, and also includes second reproducing means. means for reproducing at least one message, in a previously established direct interpretation format, selection means for selecting at least the message presented; and other translating means for translating at least the selected message in direct format into an SMS message in such a way that the user of the mobile terminal (5) can introduce and send the short message in an accessible and immediate manner. The remote server (1) communicates with the SMSC (4) via a transaction server (2), which includes means for converting SMS messages into a format in accordance with the communication protocol established with the remote server, and means for converting the format in accordance with the established communication protocol to SMS.

<img file="SE525328C2_D0002.tif" />

The numbers in parentheses indicate the INID code.

Summary

System for sending / receiving short messages (SMS) between mobile terminals and remote servers. The system allows bidirectional transmission of short messages (SMS) between a remote server and a user of a mobile terminal (5) communicating with a short message service center (SMSC) (4) via a mobile telephone network (6). The mobile terminals (5) include first translating means for translating received SMS into a direct interpretation format, and have first reproducing means for displaying the direct interpretation format in such a way that the user immediately interprets the received SMS messages, and also includes second reproducing means. means for reproducing at least one message, in a previously established direct interpretation format, selection means for selecting at least the message presented; and other translating means for translating at least the selected message in direct format to an SMS message in such a way that the user of the mobile terminal (5) can introduce and send short messages in an accessible and immediate manner. The remote server (1) communicates with the SMSC (4) via a transaction server (2), which includes means for converting SMS messages into a format in accordance with the communication protocol established with the remote server, and means for converting the format in accordance with the established communication protocol to SMS.

K: \ Patent \ 110- \ 110102800SE \ Ans0kan-SE.doc

Object of the invention

The object of the present invention is to provide a system for bidirectional communication of short messages between mobile terminals and remote servers, so that users of the mobile terminals do not need to introduce the short messages for transmission in a direct way; instead, they are introduced starting with a direct interpretation format, which is translated into short message format, and inverted, that is, the received short messages are translated into direct interpretation format; all this in order for the introduction of short messages to be carried out in a simple manner and interpretation of received short messages must be carried out in an immediate manner.

The invention is preferably applicable in those cases in which it is required to set up bidirectional communication through short messages between a remote server, which may be, for example, a server of a company or a legal person, and own or hired staff located outside the company premises, so that communication between the deployed or hired staff and the remote server is facilitated.

Background of the invention

The transmission of short messages between mobile phone users, where said users communicate with a mobile phone operator's short message service center (SMSC) via a GSM (Global System for Mobile) mobile phone network, Universal Mobile Telecommunications System (UMTS), GPRS (General Packet Radio Service) or the like, is very much today usual.

Concerning the mobile terminals, these mainly consist of the user terminal itself, which includes the keyboard, screen, antenna, etc .; the mobile terminals also include an intelligent card for mobile phones according to SIM standard (Subscriber Identity Module) which is used when the network is a GSM network, or an intelligent card according to US1M standard (mobile phone card for UMTS communication network).

Because of the importance of the added value of short messages, these are increasingly being introduced, but their direct use requires the user to write the information exactly as the addressee (person or machine) must receive it, with certain criteria that can be very strict in the event that the message is directed to a machine, which may be a remote server. This often generates errors in communication, leading to inefficiencies and serious financial losses, because the creation of complex messages must be done manually by people who in most cases

K: \ Patent \ 110- \ 110102800SE \ Ans0kan-SE.doc

<img file="SE525328C2_D0003.tif" />

·· ·«·· • · ···· ·

<img file="SE525328C2_D0004.tif" />

lacks computer experience, such as when a legal person needs to communicate with their own or hired staff who are located outside the legal person's premises.

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

In addition, the use of short messages in a direct way requires that the servers to which the communication is addressed implement new software in order for the reduced format of the short messages to be recognized.

For all these reasons, there is no system in which bidirectional communication through short messages can take place between a mobile terminal and a remote server.

To achieve this bi-directional communication, company management systems based on websites with access via the Internet or an Extranet are used today, which allow the employee or hired staff to update a posteriori the status of the work performed when they take place outside the company premises itself, as the necessary administrative information for this is not available in real time through appropriate means of communication for this type of staff; alternatively is very complex.

Description of the invention

In order to overcome the aforementioned disadvantages, the invention has developed a new system which allows the transfer of short messages to be performed between a remote server, which may be, for example, a company or a legal person, and a mobile terminal, so that the company or hired staff located outside the company's premises can conduct bidirectional communication with the remote server via a mobile terminal, and all this without having to introduce the short messages directly into the mobile terminal, thereby facilitating use and avoiding communication errors.

The system according to the invention is based on the well-known mobile terminals which basically consist of a user terminal and an intelligent card for mobile phone (SIM, USIM) and communicates with a short message service center (SMSC) via a mobile telephone network (GSM, UMTS, GPRS) which in turn communicates with remote servers, which may be a company or a legal entity.

For this purpose, the invention is characterized in that the mobile terminals comprise first translating means for translating received short messages (SMS) into a direct interpretation format, and reproducing means for reproducing the direct interpretation format in such a way that the user can immediately interpret the received SMS. .

The mobile terminals are also equipped with reproducing means for displaying at least one message in a direct interpretation format, selecting means for selecting at least the

K: \ Patent \ 110-1110102800SE \ Ans0kan-SE.doc · ♦ ♦ ··· · ·· · · ·· · · · · ··· • · · · · ·

<img file="SE525328C2_D0005.tif" />

<img file="SE525328C2_D0006.tif" />

rendered message, and other translation means for translating at least the selected message in direct format into an SMS message, in such a way that these features allow the user of the terminal to introduce and send short messages in an accessible and immediate way without having to manually introduce the short messages. in a direct way, which means that communication errors are avoided.

The direct interpretation formats have previously been defined and stored in a database.

The first translating means for translating the short messages into a direct interpretation format include an analysis module equipped with means for detecting validity and type of message (this may be a message about accepting or rejecting a transaction that was previously sent to the enterprise system at a distance server, or a new transaction received from the corresponding enterprise system).

The first translating means for translating short messages into a direct interpretation format further comprises a transaction management module which receives the result of the analysis performed, processes it and calls the database from which the transaction is executed into direct interpretation format. To communicate with the user, a user interface module in the mobile terminal has been provided, from which the direct interpretation format is displayed for the user of the mobile terminal.

The first display means for displaying the direct interpretation format, as well as the second display means for displaying at least one message in direct interpretation, are determined by the screen of the mobile terminal, which is connected to the transaction management module via the user interface.

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

With regard to the other translation means for translating the messages in direct interpretation format to SMS, these are the transaction management module itself, which calls the database and delivers different data to an SMS-creating module, from which they are transmitted to the SMSC.

Under normal operating conditions, a number of messages in direct interpretation format have been predicted by which at least one is selected, using the keyboard, so that the SMS is created initially from this, and sent to the SMSC. Of course, this number of messages in direct interpretation format has previously been defined and stored in the database.

It is possible to sequentially select at least two messages in direct interpretation format, to create the SMS from them and send the SMS to the SMSC.

In one embodiment of the invention, the previously described means are envisaged in the user terminal, but of course, and in accordance with another embodiment of the invention, these means may be included in the smart card of the mobile phone (SIM, USIM).

K \ Patent \ 11O- \ 11010? FlnnSF \ Ans «k9n.RF dnr

To allow connection of communication between the SMSC and the remote servers, a transaction server has been provided, which communicates with the remote server and with the SMSC over a communication line.

In the preferred embodiment of the invention, the communication line is

The Internet, but it can of course be any kind of cable, such as a cable.

It is also possible that the transaction server is foreseen in the SMSC itself, whereby communication management is not necessary.

Of course, the transaction server has a special architecture which includes means for converting SMS messages, provided by the SMSC, into a format in accordance with the communication protocol established on the communication line, which also includes means for conversion from the format according to the communication protocol which has been established on the communication line for SMS messages.

Both of the previously commented conversion means consist of a message analysis module, which is equipped with means for detecting validity and type of message (it determines if their content is an acceptance or rejection of a previously executed transaction or if it is a new transaction), and a transaction management module, which calls a database from which it performs the translation into SMS format using a message creation module.

The transaction server also includes a communication management module to allow communication with each of the remote servers.

It is possible to include different communication management modules to allow communication with different remote servers. Therefore, there may be instances where there is a communication management module for each remote server.

The transaction server also includes various sending / receiving means for communication with the remote server frames. This may also occur where a single transmitting / receiving means is included for communication with the remote server frames.

The remote server frames also include sending / receiving means for the SMS equivalent in the communication protocol established on each server's communication line.

Each communication management module is connected to a database for verification of some previously determined security parameters and to reject or accept the communication as a function of the result of the verification.

Therefore, the described system according to the invention avoids human error, since the user of the mobile terminal only needs to select, via an interface, the information (person-machine) that it is desirable to send, which provides an optimal level of reliability.

K \ Pat «nt \ 110- \ 110102800SE \ Ans0kan-SE.doc ·· ····

<img file="SE525328C2_D0007.tif" />

Based on this description, it can be readily understood that the system of the invention can be adapted to any corporate system, and is also applicable to any cellular telephone communication network.

In order to facilitate a better understanding of this description and to form an integral part thereof, a series of figures are attached to the description by which the object of the invention is illustrated and in a non-limiting manner.

Brief description of the drawings

Figure 1 shows a functional block diagram of the general structure of the system according to the invention.

Figure 2 shows an explanatory functional block diagram of the case in which it is the remote server (company or legal person) that sends a short message to the mobile phone user.

Figure 3 shows an explanatory functional block diagram of the case in which the mobile phone user 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 embodiment of the transaction server which is part of the system according to the invention to allow the connection of bidirectional communication of short messages between users of mobile terminals and remote servers.

Description of a preferred embodiment ²⁵

A description of the invention based on the above figures is provided below.

The example provided by the invention relates to the case in which a remote server, belonging to a company or legal entity, establishes bidirectional communication through short messages with a mobile terminal belonging to an employee of the company or a hired person, and which is located outside the company's premises.

For this purpose, the remote server or enterprise server 1 is connected to a transaction server 2 via a communication line 3.

The transaction server is in turn connected to a short message service center 35 (SMSC) 4 which communicates via the mobile telephone network 6 with a mobile terminal 5.

The transaction server 2, as well as the SMSC 4, belongs to the mobile operator 7, in that the transaction server 2 is adapted to the communication protocol established by the enterprise server 1, as will be explained later, whereby it is not necessary to modify the structure of the enterprise server 1.

K: \ Patent \ 110- \ 110102800SE \ Ans0kan-SE.doc ···· ·· • ·

Figure 2 shows the various stages followed for performing a transmission of a message from the enterprise server 1 to the mobile terminal 5.

First of all, the enterprise server 1 receives the data necessary to be able to create a message that it is desirable to send to the mobile terminal 5, and establishes a session with the transaction server to which a transaction request 8 is made.

Thereafter, transaction server 2 validates the request and creates all the data for its delivery 9 in SMS format to the SMSC through the protocol established between the two elements. The transaction server 2 may be included in the SMSC 4 itself, or separated from the latter, in which case it is connected via a communication line, such as the Internet, cable, etc. Thus, the transaction server 2 maintains an open session with both the corporate server 1 and the SMSC 4th

Then, the SMSC performs the transmission 10 of the SMS message in a conventional manner, via the public mobile communication network 6, to the mobile terminal 5 belonging to the deployed staff.

When the short message is received in the mobile terminal, this message processes and generates a new receiving confirmation message in which the received transaction is accepted or rejected, and this is sent 11 via the mobile telephone network 6 to the SMSC, which delivers the short message originating in the mobile terminal to the transaction server 2. in the communication protocol and the connection method set up between the two.

The transaction server 2 recognizes the received message as confirmation of receipt of a specific previous transaction, and analyzes whether the transaction has been accepted or rejected, and adjusts the response 13 to the present enterprise server, ending the session connected between the two.

Figure 3 describes the various stages that take place when the short message is produced in the mobile terminal 5 and sent to the corporate server 1.

In this case, in the mobile terminal 5, the data needed to create the desired message is obtained, as will be explained later, guided by menus, and the transmission 14 of the short message (SMS) continues through the mobile telephone network 6.

Next, the SMSC performs the transmission of the short message via the protocol and connection connected to the transaction server 2, which analyzes the received message and as a function of its destination, connects a connection 16 to the corporate server 1 in accordance with the protocol and the connection method between the two. .

Then, the enterprise server 1 confirms receipt of the transaction and accepts or rejects it by responding 17 to request 16.

After that, the transaction server generates a new card message to the SMSC and sends it 18. This message indicates the transaction's result.

K: \ Patent \ 110- \ 110102800SE \ Ans0kan-SE.doc • · · • · · »· · __ J ····«

I · '· ·

Finally, by sending a short message via the mobile phone network 6, 19 SMSC.t deliver confirmation of acceptance or rejection of the transaction.

Having now generically described the communication process in both directions, a detailed explanation of the operation of the mobile terminal will be given below, with reference to the block diagram shown in Figure 4.

First of all, the process followed when the short message transaction is performed from the enterprise server 1 to the remote terminal 5 is described.

In this case, when the remote terminal 5 receives a new card message via the SMSC, the terminal sends the message to an SMS receiving module 23 resident in the smart card (SIM or USIM). It may 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 through which it is verified whether the received SMS message contains valid information for the system, so that the message is discarded in the event that it does not contain valid information.

On the other hand, if the received message contains valid information for the system, it is analyzed to examine what kind of message it is; possibly it is a matter of accepting or rejecting any transaction that was previously sent to the corresponding company server, or whether a new transaction received from the corresponding company server, as previously explained.

Once the message analysis module 24 has determined the coherence of the received message, as well as what type of message it is, it delivers this information to a transaction management module 26, which has the task of processing the received information in such a way that if the received message refers to the acceptance of a previous transaction sent to the enterprise server communicates the transaction management module 26 with a database 28, more specifically, with a transaction database 28a, in which the transaction status is changed to the same status as that indicated in the received acceptance message. The transaction database 28a includes the various transactions that can be received or sent by the user of the mobile terminal, so they should be stored in advance. These transactions depend on the requirements of the enterprise server 1.

In the event that the received message is a rejection of a transaction previously sent to the corresponding enterprise server, the transaction management module communicates with transaction database 28a to change the transaction status to the last valid previous status it had stored before the transaction was sent.

In the case in which the received message contains a transaction, the process followed in the transaction management module 26 is as follows:

<img file="SE525328C2_D0008.tif" />

• · ·· ·· ··· ·· ···· ·

a) In the event that the received transaction is recorded in the transaction database 28a, the data characterizing the new transaction is not stored in the transaction database 28a, the user being informed via an interface module 27, more specifically via an event-notifying interface module 27a, whereupon a short message regarding received rejection the transaction is sent. For this purpose, the transaction management module 26 communicates with a message creation module 25 which provides the necessary data contained in the database 28, more specifically in the transaction database 28a, and in a configuration database 28b, so that the message creating module 25 can create a rejection message. Thereafter, this message is delivered to an SMS transmission module 29 from which it is sent to the SMSC.

b) In case the mobile terminal 5 has the capacity to process a new transaction, the data characterizing the new transaction is stored in transaction database 28a, the user being informed via the event-notifying interface 27a. Then, a short message regarding acceptance of the received transaction is sent. For this purpose, the transaction management module 26 communicates with the message creation module 25, to which it supplies the necessary data from the database 28 so that it can create an acceptance message. Then this message is sent using the SMS transmitting module 29.

c) In the event that the transaction management module 26 does not have the capacity to process a new transaction, the data characterizing the new transaction is not stored in the transaction database 28a, the user being informed via the event notifying interface module 27a. Subsequently, a short message rejecting the received transaction is sent, in the same way as explained in the previous cases.

The following is the process followed by the mobile terminal for the case in which the short message transaction is performed from the mobile terminal 5 to the corporate server 1.

In this case, the user, via the keyboard 22 and the screen 21 of the user terminal 20, calls the interface 27, more specifically, a transaction transfer interface 27b.

The transaction transfer interface 27b makes a request to the transaction management module 26 to obtain the internal identifiers for each of the possible operations that can be performed on any current transaction previously stored in transaction database 28a. These identifiers are presented to the user via the screen 21 in menu form, as well as via the transaction-transmitting interface 27b. Thereafter, the user selects one of said identifiers from the menu via the keyboard 22, and the transaction transferring interface 27b informs the transaction management module 26 of this to obtain the internal identifiers for each of the transactions stored in the transaction database for the selected type of operation. These identifiers

K \ Patani \ 1 m. \ 1 inmspnnP \ Ane «lfan.KF rtnr is presented in the same way on screen 21 through a menu, and through the transaction transfer interface, in such a way that the user selects one of them via the keyboard 22, after which it the transaction transfer interface 27b informs the transaction management module 26 thereof, depending on the type of operation and transaction selected; the transaction transfer interface, on the one hand, makes a request to the transaction management module 26 to obtain the internal identifiers for any other information necessary for the type of transaction transfer it is desirable to perform and which requires a certain choice on the part of the user; the other side makes a request to the terminal screen for any other additional information.

Therefore, the various possible messages that can be sent on the screen of the user are displayed and he selects the different options, so that when the user has selected and / or introduced all the necessary information, the transaction management module 26 sends the message creating module 25 the selected data and / or introduced by the user, as well as other data contained in the configuration database 28b, so that the corresponding message can be generated. This message is delivered to the message transfer module SMS 29, which sends the received SMS message to the SMSC 4.

The terminal user can, of course, make a request as to which transactions can be performed and which are previously stored in transaction database 28a, as already explained above.

For this purpose, the user calls interface 27, more specifically a transaction request interface 27c, via the keyboard 22 and screen 21, so that this interface 27c provides specific menus, which depend on the needs and functions required by the enterprise server 1, to the user. The data stored in the databases 28a and 28b therefore depends on the requirements of the enterprise or enterprise server, as previously pointed out.

To execute the request after calling the transaction request interface 27c, it makes a request to the transaction management module 27 to obtain the internal identifiers for each of the transactions contained in transaction database 28a. These identifiers are presented to the user by means of the screen 21, via the transaction request interface 27c. From this point on, the user selects one of these indicators (presented by means of a menu, as commented in the previous cases) via the keyboard 22, and the transaction request interface 27c informs the transaction management module of this so that the latter, depending on the selected transaction, provides all information related to said transaction, for on-screen presentation.

It is also possible to configure transactions so that the user has the ability to modify certain information that exists in the configuration database 28b, in accordance with the requirements of his / her corporate server 1. For this purpose, the user calls, via

Λ \ 4 4 Λ4 ΛΠηηηΟΓλ A__UI.

J kJ .7 • ··· · · · · · ··· · · · · · ··· ··· · · · · ·· · · · · · ··· ·· · «· · ·· ·· · · • · ·· ·· ··· ·· ··· · terminal keyboard and screen, interface 27, more specifically a configuration interface 27d, which makes request to transaction management module 26 to obtain the internal identifiers for each and one of the possible configuration operations that can be performed on the configuration database 28b. These identifiers will be presented to the user via the configuration interface 27d, and when the user selects one of them, the interface informs the transaction management module 26 thereof.

Depending on the type of operation selected, the configuration interface 27d, on the one hand, makes a request to the transaction management module 26 to obtain the internal identifiers for any other information necessary for the type of modification it is desirable to perform and which requires some form of choice from the user's side, and on the other hand a request to the terminal screen for any other additional information.

After the user has selected and / or introduced all the necessary information, the transaction management module 26 stores all information in the configuration database 28b. Therefore, using the configuration interface, it is easier for the user to configure how he / she should communicate with their corresponding company server.

Company server 1 is not described, as it can assume any configuration that is judged to be optimal and most effective with respect to the specific requirements of each company.

With respect to transaction server 2, its block diagram is shown in Figure 5, and its operation is described below in accordance with the various capabilities offered by the system and described previously.

In the first case, the case is described in which the corporate server sends a message to the mobile terminal. In this case, the business server 1 establishes a session, in the protocol and via the communication network 3 established, with a communication management module 31 via a transmitter / receiver 30.

In the embodiment of Figure 5, the possibility of connecting a plurality of enterprise servers 1 to the transaction server 2 is considered, for the purpose of which the latter includes a communication management module 31 for each of the enterprise servers 1 to which it is connected.

At this point, it is important to point out that this structure is necessary in the event that the enterprise servers 1 use different communication protocols and networks. It is therefore obvious that enterprise servers 1 using the same communication line 7 and the same protocol will be connected to the same transmitter / receiver 30 and the same communication management module 31.

K: \ Patent \ 110- \ 110102800SE \ Ansftkan-RF no

<img file="SE525328C2_D0009.tif" />

Accordingly, the communication management module 31, as well as the transmitter / receiver 30, can be specific to each company or, on the contrary, generic.

When the communication management module 31 receives a session connection request, as described at the beginning of this section, it requests a database 33, and more specifically a security parameter configuring database 33a, about the security parameters established for each type of connection. , so that it rejects or accepts the session connection request as a function of the query performed.

When the session is accepted, the enterprise server 1 sends the transaction it wishes the mobile terminal to receive. This transaction is delivered by the communication management module 31 to a transaction management module 32 which verifies the transaction format in accordance with the available information in the configuration database 33a, and if this format is not appropriate it returns an error message to the enterprise server. It also obtains rules for analysis and transformation from the configuration database 33a, which it must apply to received transaction to adapt them to the requirements of the mobile terminal's applications to which the message is addressed, and then inserts a record of the transaction's data into the database 33 , more specifically, in a transaction database 33b. Among the data recorded in this database is a clear reference to the transaction being handled to allow subsequent processes such as confirmation of delivery of said transaction.

After that, the transaction management module 32 sends to a message creation module 34 all the data needed to create the short message that it is desirable to transmit.

Thereafter, the message creation module takes all the data facilitated by the transaction management module and creates the short message to be sent and sends it to a message transmitting module 35 through which it is forwarded to the SMSC 4.

The purpose of the message transfer module 35 is to maintain a connection with the SMSC, in the protocol adopted and by means of a direct connection (in the case in which the transaction server forms part of the SMSC.t 4 itself) or by means of a communication line (in case the transaction server 2 is located at a distance from the SMSC). The message creation module also aims to administer the delivery of the short message to the SMSC, whereby the delivery of the message is guaranteed by an algorithm of new attempts being established, or otherwise returns an error message in case delivery is not possible.

The process continues with a period of waiting for confirmation of acceptance of the transaction from the mobile terminal application side. For this purpose, a message receiving module 36 has been provided which is intended to be permanent

K: \ Patent \ 1 W- \ 1 ir&gt; in9 «nnSF \ An« Alran.SP Hnr ··· «

<img file="SE525328C2_D0010.tif" />

• ·

B · ·· ·· ··· ·· ···· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · any of the enterprise servers, and apply them to a message analysis module 37.

The message analysis module 37 determines for each message whether its content is an acceptance or rejection from the mobile terminal, or refers to a new transaction, and sends to the transaction management module 32. In case the received message is an acceptance or rejection of a previous transaction, the transaction management module 32 analyzes the data of the accepting or rejecting message and receives stored data related to the transaction from the transaction database 33b, and also receives the transformation rules that it must apply. to respond to the enterprise server with the transaction result from the configuration database 33a. It then sends the transaction's response to the communication management module 31, which returns the transaction's results to the enterprise server and disconnects the session connected to it, provided that a standing session connection is not imagined.

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

The case is described below in which it is the mobile terminal 5 that sends a transaction to the corporate server 1. In this case, the message receiving module is permanently plugged into the protocol adopted, either via direct connection or via a communications line, with the SMSC, so that it receives all the messages addressed to one of the enterprise servers and applies these messages to the message analysis module 37, which determines whether their content is an acceptance or rejection of a transaction from the mobile terminal application side; or if it's a new transaction. The acceptance or rejection has already been described previously. In case it is a transaction, it is sent to the transaction management module 32 from the message analysis module 37 so that the former verifies the destination and format of the transaction in accordance with the information available in the configuration database 33a. If the format is not appropriate, it returns an error rejecting transaction.

The transaction management module 32 receives from the configuration database 33a the rules for analysis and transformation that it must apply to the received transaction, to adapt these to the requirements of the enterprise server.

r

<img file="SE525328C2_D0011.tif" />

It then records transaction data in transaction database 33b. Among the data recorded is a clear reference to the transaction being handled to allow subsequent processes such as confirmation of delivery of said transaction.

Then, the transaction management module 32 sends the data needed to set up a session with the enterprise server 1 to the communication management module 31, which belongs to the corresponding enterprise server 1, in the event that this session is not permanent.

When the session is set up, the communication management module 31 sends the transaction, using the corresponding transmitter / receiver 30, to the enterprise server, in accordance with the method established therein, in such a way that data entry is mimicked in a form identical to that used. for data entry by a used corporate server user.

The communication management module then waits for the response from the enterprise system, and sends the result (acceptance or rejection of the transaction) to the transaction management module. In the event that no response is received after a configurable time period has passed, an error message is sent.

The transaction management module analyzes the response from the enterprise server and sends, in accordance with the rules established in the configuration database 33a for the specific enterprise server, the data necessary to transmit the transaction result to the message creation module which, in accordance with the data obtained, formulates the short message which must be sent as confirmation of the transaction, and deliver this to the message transfer module, which aims to maintain a connection to the SMSC in the manner already commented on.

K: \ Patent \ 110- \ 110102800SE \ Ans0kan-SE.doc

<img file="SE525328C2_D0012.tif" />

• · ·· ·· ··· ·· ···· ·