WO2006010371A2

WO2006010371A2 - Method and system for providing communication between communication equipment and a sim-type module, related equipment and computer program product therefor

Info

Publication number: WO2006010371A2
Application number: PCT/EP2004/008364
Authority: WO
Inventors: Stefano Dal Lago; Alessandro Porta; Benedetto Riolfo; Luca Tessitore
Original assignee: Telecom Italia S.P.A.
Priority date: 2004-07-27
Filing date: 2004-07-27
Publication date: 2006-02-02
Also published as: WO2006010371A3

Abstract

A system for providing communication between applications running on communication equipment (1) , such as e.g. a mobile phone, and a SIM-type module (2) associated with the equipment (1). The system supports a SIM application toolkit (SAT) protocol able to convey messages including user messages between a user of the equipment (1) and the SIM-type module (1), and includes at least one SIM gateway module (4) for providing communication between the applications and the SIM-type module (2) via the user messages of the SIM application toolkit (SAT) protocol. Preferably, the SIM gateway module (4) is an emulation module for emulating the interactions of the user of the equipment (1) with the SIM application toolkit protocol.

Description

"Method and system for providing communication between communication equipment and a SIM-type module, related equipment and computer program product therefor"

* * *

Field of the invention

The present invention relates generally to communication devices. Specifically, the invention was devised by paying attention to the possible application in those contexts that involve cooperation between mobile apparatus such as e.g. a mobile phone and a Subscriber Identity Module (SIM) associated therewith. However, the invention is per se applicable also to non-mobile apparatus involving a similar type of cooperation.

Description of the related art \

Subscriber Identity Module (SIM) usage is normally involved in the provision of basic GSM (Global System for Mobile Communications) connectivity, but many other applications developed for mobile phones (handsets) involve tasks that can be advantageously executed on a SIM.

For instance, a Mobile Network Operator (MNO) may want to exploit the security and portability features of a SIM to perform user authentication or deal with sensitive data when providing value added services to mobile customers. However, the intrinsic limitations of processing and communication capabilities of current SIM platforms demand for resource-intensive functions being re-located outside a SIM in order to be implemented.

Various prior art arrangements address such problem by re-locating part of a SIM processing burden to platforms that are not part of the mobile handset.

For instance, WO-A-01/99448 discloses a method where a software program running on a remote server exchanges data with a SIM application in order to cooperate in implementing specific functionalities. Communication with the SIM application is achieved via the Short Message Service (SMS) feature.

EP-A-O 869 691 discloses a similar approach, by essentially replacing the remote server with custom circuitry that communicates with the SIM through the mobile phone serial port.

In several circumstances these prior art solutions may turn out to be largely impractical .

For instance, in connection with arrangements such as disclosed e.g. in WO-A-01/99448, a network connection may not be always available, may be expensive and/or imply unacceptable transmission latency. On the other hand, in connection with arrangements such as disclosed e.g. in EP-A-O 869 691, dedicated circuits usually come at an additional cost and are not necessarily handy.

On the other hand, moving part of the SIM computational burden straight into the handset that hosts the SIM would dramatically cut task execution time and cost. Moreover, a certain number, even if not all, of the tasks performed by a remote server can be easily carried out on a mobile phone platform and it is still possible for a SIM to request for remote server support when no alternatives are available.

Thus,, there is a case for a SIM to exchange data with software applications running on a mobile phone other than for GSM basic purposes. GSM mobile phones support standardized methods for communicating with a SIM that are specified by the European Telecommunications Standard Institute (ETSI) . These methods allow:

- the mobile phone software to read and write data from and into a SIM (e.g. a subscriber phonebook entries) ,

- the mobile phone software to have certain types of data processed by the SIM and result returned (e.g. a subscriber PIN validated) , the SIM software to have specific tasks performed by a mobile phone (e.g. send a SMS) .

The first two functions listed above are part of the basic functions of all GSM phones and SIMs, as described by the European Telecommunications Standard Institute (ETSI) in the ETSI 11.11 specification.

The last function cited is an advanced functionality supported by mobile phones and SIMs that implement the so-called SIM Applications Toolkit (SAT) protocol, as described in the ETSI 11.14 specification.

Until recently, only mobile phone manufacturers (or other subjects having access to proprietary information related to the software platform of the mobile phone) had the possibility of developing software to run on a mobile phone and communicate with an onboard SIM. Conversely, developers of SIM software, such as e.g. Mobile Network Operators (generally not having access to such proprietary information) , had to rely on mobile phones to carry out standard tasks in support to SIM communications with the outside world (e.g. communications with the mobile phone user or with an operator service center) only within the framework set by the aforementioned ETSI specifications.

As mobile phones are increasingly becoming open platforms, third parties have a chance to develop and install their own software on mobile phones to carry out (irrespective of the specific mobile phone model involved and the manufacturer thereof) non-standard tasks, namely tasks not expressly catered for by the ETSI standard, which would also require establishing custom communications with the SIM. However, on the one hand mobile phones still support only the ETSI communications protocols. On the other hand, mainly for security reasons, mobile phone platforms typically give third-party applications access only to a limited set of the ETSI features, for instance only to SIM Applications Toolkit protocol high-level commands.

The SIM Applications Toolkit (SAT) protocol is thus a normal option for third-party application developers to implement communications between mobile phone software and SIM applications. The SIM Applications Toolkit protocol provides only standard means in order that software modules running on a SIM (a SAT application) may:

- exchange textual information with a mobile phone user,

- exchange generic data with a device other than the mobile phone (for example via SMS) ,

- exchange with the mobile phone itself specific information regarding the GSM service (e.g. the mobile network signal power level received by the phone and so on) .

The SIM Applications Toolkit protocol makes no provisions for software running on a mobile phone to exchange "generic" data with a SAT application, i.e. with software running on a SIM that makes use of the SAT communication channel. For instance, no provisions exist for software running on a mobile phone to start a SAT application on a SIM, pass custom data to such application, have such data processed by the application and a result returned.

Additionally, no provisions exist for software developed by a Mobile Network Operator to access the operator subscriber data stored in the operator SIM. This result could be notionally achieved only by means of an agreement with the mobile phone manufacturer aiming at gaining access to the low-level commands of the ETSI 11.11 specification as implemented on the mobile phone. In any case, such an agreement would be specific and thus apply only for that type of mobile phone and/or that manufacturer.

For instance, one may consider the case of a software program developed by a Mobile Network Operator on a mobile phone, having to retrieve certain data (e.g. a graphic map) from a remote application server in order to display it to the mobile phone user, with such data depending on specific subscriber information stored inside the onboard operator-provided SIM (e.g. network-based location information) . Under those circumstances, the mobile phone user has to manually activate a SIM Application Toolkit application on the SIM, which sends an SMS containing subscriber information (e.g. current user location) to the application server. Then the user has to launch the Mobile Network Operator application on the mobile phone, which retrieves the requested data (e.g. a location-specific map) from the application server.

As a rule, in prior art arrangements, any custom communications between a third-party application running on a mobile phone and a SIM Application Toolkit application running on a SIM has to take place through a remote server via SMS or other facilities that are external to the mobile phone. Moreover, the user has to "close the loop" by manually starting both programs (and possibly copying parameters from one to the other) . Obviously, this is cumbersome and time consuming: direct exchange of custom data between phone applications and SIM applications would shorten the whole process and allow the operator subscriber to deal with just one user interface provided by the mobile phone software.

Object and summary of the invention

The object of the invention is thus to provide a fully satisfactory response to the needs outlined in the foregoing, that is primarily:

- enabling software running on a mobile phone to exchange generic data with software running on a SIM that makes use of the SAT communication channel,

- enabling software running on a mobile phone to start a SAT application on a SIM, pass custom data to such application, have such data processed by the application and a result returned.

According to the present invention, that object is achieved by means of a method having the features set forth in the claims that follow. The invention also relates to a corresponding system, a related equipment as well as a related computer program product, loadable in the memory of at least one computer and including software code portions for performing the steps of the method of the invention when the product is run on a computer. As used herein, reference to such a computer program product is intended to be equivalent to reference to a computer-readable medium containing instructions for controlling a computer system to coordinate the performance of the method of the invention. Reference to "at least one computer" is evidently intended to highlight the possibility for the present invention to be implemented in a distributed/ modular fashion.

A currently preferred embodiment of the invention is thus a method of providing communication between applications running on communication equipment, such as e.g. a mobile phone, and a SIM-type module associated with said equipment by using a SIM Application Toolkit (SAT) protocol. That protocol is able to convey messages including user messages between a user of the equipment and the SIM-type module. The method in question includes the step of providing communication between the applications and the SIM-type module via the user messages of the SIM Application Toolkit (SAT) protocol.

The basic idea underlying a preferred embodiment of the invention is to provide within e.g. a mobile phone a module that acts as a "bridge" or a "gateway" between the mobile phone applications and the SIM, automating exchange of custom data in a way that is transparent to the physical user. In order to achieve that goal, the module in question preferably emulates the user in its interaction with SAT applications, relieving the user of the burden of manually "closing the loop" between SAT applications and mobile phone applications. In brief such a module can be referred to as a "SIM Gateway" .

With reference to the exemplary case outlined previously, the arrangement described herein allows the mobile phone user to simply start the Mobile Network Operator application on the mobile phone and request a map pertaining to the current location. The Mobile Network Operator application then asks the SIM Applications Toolkit application on the SIM to compute current location information, gets the result and passes it to the remote application server, which provides the proper map, all without further human intervention. A preferred embodiment of the present invention permits the "SIM Gateway" to exploit a subset of the standard SIM Applications Toolkit protocol commands that are normally used by SAT applications to interact with a mobile phone user, in order to transfer custom data between the mobile phone and the SIM.

A preferred embodiment of the arrangement described herein permits, inter alia, the following operational pattern:

- starting a SAT application on an onboard SIM,

- passing on generic data to such SAT application, processing the data by means of the SAT application, and

- causing the SAT application to return the result of processing.

The above sequence of steps is just an example of a possible interaction pattern between a mobile phone and a SIM that is supported by the arrangement described herein. Alternative patterns (e.g. not including all of the above steps or including repetitions of some steps) can be conceived depending on the specific application logic that is to be implemented. The arrangement described herein is thus exemplary of a generic communications method that poses no particular limitations to the way interaction patterns can be arranged.

A particularly preferred embodiment of the arrangement described herein solves the additional problems related to the interactions between mobile phone applications and SAT applications. In particular, concurrent access to the SAT communication channel by multiple programs running on a mobile phone is permitted by means of a SAT access arbitration method that ensures consistency of all transactions occurring between the SIM and the mobile phone through the SAT protocol .

Those of skill in the art will easily understand that while an exemplary embodiment of the invention is described herein in connection with GSM mobiles, the invention applies in general to all those arrangements involving the use of a SIM-type module (e.g. a so- called USIM) . Additionally, it is once more recalled that the invention is per se applicable also to non- mobile apparatus.

Brief description of the annexed drawings

The invention will now be described, by way of example only, with reference to the enclosed figures of drawing, wherein:

Figure 1 shows the logical structure of a standard GSM mobile phone adapted to incorporate the arrangement described herein, and

- Figure 2 shows a graphical summary of a possible related workflow.

Detailed description of preferred embodiments of the invention

Figure 1 shows the logical structure of a standard GSM mobile phone, enhanced with the provisions of the arrangement described herein. GSM mobile phones are typically comprised of a Mobile Equipment or ME, indicated 1, managing resources and interfaces with the outside world and a GSM Subscriber Identity Module or SIM, indicated 2, holding user data.

As already indicated, those of skill in the art will easily understand that the arrangement described herein in connection with GSM mobiles can be easily extended to other similar arrangements involving the use of a SIM-type module (e.g. a so-called USIM) .

Software running on the Mobile Equipment 1 can be logically partitioned into two distinct layers:

- a first layer, typically provided by the Mobile Equipment manufacturer, comprises the Operating System, and a second layer, typically developed by any "third-party", comprises the software applications.

In the first layer, reference 6 indicates a Mobile Equipment Operating System, including Mobile Equipment Operating System functions, indicated 7 in Figure 1, to support the SAT framework. Additionally, Mobile Equipment Operating System functions, indicated 11 in Figure 1, provide access to Mobile Equipment resources like output devices, indicated 12, and input devices, indicated 13. In addition, a network connection 14 for the mobile network is provided.

Within the second layer, reference 3 indicates a Mobile Equipment application performing service- specific tasks.

According to present description, the term application is used, in general, as a reference to Mobile Equipment applications performing, for instance, service-specific tasks.

Reference 4 indicates a "SIM Gateway" provision according to the embodiment described herein.

Software running on the SIM 2 can be similarly partitioned into another two distinct layers:

- a first layer comprises the software provided by the SIM manufactμrer, and

- a second layer comprises the software developed by the third-party.

Within the first layer, reference 9 indicates a SIM Operating System, including SIM Operating System functions, indicated 8, to support the SAT framework. In the second layer, reference 5 indicates a SAT application performing service-specific tasks.

According to present description, the term application is further used, in general, as a reference to SAT application performing, for instance, service- specific tasks. •'

The SIM Gateway 4 provides an Application Program Interface (API) , hereinafter designated SIM Gateway API and indicated 10. This interface is made available to applications running on Mobile Equipment 1 that need to communicate with the SIM 2. An example is, for instance, the Mobile Equipment application 3. The SIM Gateway API 10 can be implemented using any specific inter-process communications methods provided by the Mobile Equipment Operating System 6.

Manufacturer software is usually pre-installed on the Mobile Equipment 1. The SAT application 5 can for instance be installed on the SIM 2 by a mobile operator owning the SIM 2 during the SIM configuration phase or installed over-the-air via the operator specific protocol. Self-installing packages for the Mobile Equipment application 3 and the SIM Gateway 4 can be downloaded over-the-air on Mobile Equipment 1 by a third-party using, for example, well-known Wireless Application Protocol (WAP) push methods. Further, third-party software may be installed afterwards.

According to a preferred embodiment of present invention the Mobile Equipment Application 3 is able to exchange any kind of data with the SAT application 5 by means of a SIM Gateway 4 providing a Application Programming Interface (API) to Mobile Equipment Application 3.

Through such API the SIM Gateway 4 provides the function of encapsulating any kind of data into SAT protocol user messages in order to send them to the SAT Application 5 on the SIM.

Moreover the SIM Gateway 4 provides the function of extracting any kind of data out of SAT protocol user messages generated on the SIM by SAT Application 5.

By implementing the above features the SIM Gateway acts as an emulation module emulating interactions of the Mobile Equipment 1 user with the SIM 2 through the SAT protocol,

Communications between a Mobile Equipment 1 and a SIM 2 are regulated by the following European Telecommunications Standard Institute (ETSI) specifications :

- ETSI 11.11: basic communications for setting up and operating a GSM session (e.g. voice call or SMS transmission) , and

- ETSI 11.14: enhanced communications involving third-party applications running on a SIM in compliance with the SAT execution framework.

In the following, a short overview of the traditional way of using the provisions of the ETSI 11.14 specification to implement Mobile Equipment-SIM interaction is given.

The SIM Applications Toolkit commands can be originated either by the Mobile Equipment or by the SIM.

A SIM Applications Toolkit command that can be sent by the Mobile Equipment to the SIM is the MENU SELECTION command: a Mobile Equipment user can request the Mobile Equipment to display a list of all SIM Applications Toolkit applications available on the onboard SIM; the MENU SELECTION command is then issued by the Mobile Equipment when the user selects one specific SIM Applications Toolkit application to be started.

The following SIM Applications Toolkit commands among others (known collectively as SIM proactive commands) , can be sent from the SIM to the Mobile Equipment :

- SET UP MENU: this command is normally issued during the mobile phone startup process to provide the Mobile Equipment with a list of the SAT applications that are available on the onboard SIM;

- SELECT ITEM: this command can be issued by a SAT application to request a Mobile Equipment user to select an item in a list of options; the Mobile Equipment presents the user with the list of options and captures the result of the selection;

- DISPLAY TEXT: this command can be issued by a SAT application to request a Mobile Equipment to display textual information to the Mobile Equipment user, and

- GET INPUT: this command can be issued by a SAT application to require a Mobile Equipment user to input textual information; the Mobile Equipment captures the user input.

To every SIM proactive command the Mobile Equipment responds with a TERMINAL RESPONSE command to deliver the results of the requested operation (for instance, textual input from the Mobile Equipment user in response to a GET INPUT proactive command) or to simply acknowledge execution of the operation requested.

All of the above commands can be issued with associated parameters as per the ETSI 11.14 specification.

A typical workflow of an ordinary interaction session (SIM proactive session) between a Mobile Equipment and a SAT application would then be as follows.

1. At phone startup, the SIM 2 issues a SET UP MENU command providing a list of available SAT applications.

2. The user requires the Mobile Equipment 1 to display such list, for instance by starting a dedicated Operator Services application, and selects a specific SAT application.

3. The Mobile Equipment 1 issues a MENU SELECTION command indicating the specific SAT application selected by the user.

4. The SIM 2 starts the selected SAT application, which issues a SELECT ITEM command to request that the user should pick up an item in a list of options, for instance a list of the various functions that the selected SAT application can perform.

5. The Mobile Equipment 1 issues a TERMINAL RESPONSE command indicating the item selected by the user.

6. The SAT application issues a GET INPUT command to request further textual information from the user.

7. The Mobile Equipment 1 issues a TERMINAL RESPONSE command carrying textual information provided by the user.

8. The SAT application issues a DISPLAY TEXT command to display further textual information resulting from user input processing.

9. The Mobile Equipment 1 issues a TERMINAL RESPONSE command to confirm that such textual information has been displayed to the user and acknowledged by the user.

10. The user selects another SAT application among those available or quits the Operator Services application.

In parallel to this well-known type of behavior, the arrangement described herein provides a different way of using the same SAT commands. A typical resulting workflow would in this case be as shown in Figure 2.

There, the reference numbers 3, 4, 7, 8, and 5 indicate the same elements designated by the corresponding numerals in Figure 1.

1. As a first step, the SIM Gateway 4 is launched as a resident service at Mobile Equipment 1 startup; the SIM Gateway 4 receives the SET UP MENU command issued by the SIM 2 and stores internally the list of available SAT applications.

2. By interacting with the Mobile Equipment 1 input/output peripherals (like the display 12 and the keyboard 13) the Mobile Equipment 1 user requests the Mobile Equipment application 3 to perform an operation, for instance downloading from a mobile network a specific map for the current location area.

3. The Mobile Equipment application 3 needs location data that are stored in the SIM 2 in order to carry out the requested operation; the Mobile Equipment application 3 knows that such data is managed in the SIM 2 by the SAT application 5; therefore, in a step 200, the Mobile Equipment application 3 calls a CONNECT method, of the SIM Gateway API 10, passing on as a parameter the name of the SAT application 5 as a text string.

4.The SIM Gateway 4 finds out in the list of available SAT applications what identifier corresponds to the SAT application 5; it then issues a MENU SELECTION command (step 202) passing such identifier as a parameter; the command is forwarded (step 204) by the SAT function 7 to the SAT function 8, which starts the SAT application 5 (step 206) .

5. The SAT application 5 issues a SELECT ITEM command, which is forwarded all the way back through the SAT function 7, and 8, to the SIM Gateway 4 (steps 208, 210, 212) in order to prompt the selection of a specific SAT application 5 function; upon receipt of such a command, (step 212) , the SIM Gateway 4 knows that the SAT application 5 has been started successfully.

6. The SIM Gateway 4 returns successfully from the CONNECT method, and informs (step 214) the Mobile Equipment application 3 that the mobile equipment application 3 is now connected to the SAT application 5; the SIM Gateway 4 ensures that no other application running on the Mobile Equipment 1 can use the SAT function 7, through the SIM Gateway 4, while the Mobile Equipment application 3 remains connected.

7. The Mobile Equipment application 3 calls an EXECUTE method of the SIM Gateway API 10, passing on the following parameters: i) an identifier of the specific function required from the SAT application 5 for instance a function returning information about the current location area; ii) an indicator of the exact piece of information (for instance, location information) requested; iii) a pointer to a callback method of Mobile Equipment application 3, named RESULT, that is thus installed into the SIM Gateway 4 as part of SIM Gateway API 10 (step 216) .

8. The SIM Gateway 4 issues a TERMINAL RESPONSE command (steps 218, 220, and 222) passing on as a parameter the location function identifier; the command is forwarded through the usual path to the SAT application 5.

9. The SAT application 5 executes the location function and issues a GET INPUT command (steps 224, 226, and 228) , to prompt for the exact piece of location information that must be provided.

10. The SIM Gateway 4 successfully returns from the EXECUTE method, and informs (step 230) the Mobile Equipment application 3 that the SAT application 5 is now processing its request.

11. The SIM Gateway 4 replies to the GET INPUT command, (step 228) , by issuing a TERMINAL RESPONSE command (steps 232, 234, and 236) by passing as a parameter a description of the exact piece of location information that is requested; before doing so, it encodes such description as text using a SAT-compatible text encoding scheme (for instance GSM 7-bit unpacked format) as specified in the ETSI 11.14 document; such encoding is needed because the GET INPUT command, requires a text-formatted response.

12. The SAT application 5 receives the description of the exact piece of location information that is requested, decodes it and retrieves the location information (step 238) ; it then issues a DISPLAY TEXT command (steps 240, 242, and 244) passing on as a parameter the retrieved location information; before doing so, it encodes the information as text using a SAT-compatible text encoding scheme (for instance GSM 7-bit unpacked format) as specified in the ETSI 11.14 document; such encoding is needed because the DISPLAY TEXT command requires a text-formatted parameter.

13. The SIM Gateway 4 decodes the location information received in the step 244 and calls (step 246) the previously installed RESULT callback method of the Mobile Equipment application 3 passing on as a parameter the related information; then it issues a TERMINAL RESPONSE command (steps 248, 250, 252) with no parameter to acknowledge receipt of the requested piece of location information.

14. Upon receipt of such TERMINAL RESPONSE (step 252) , the SAT application 5 terminates; it can then be started over to serve a new request according to the same procedure outlined in the previous steps.

15. Based on location information obtained by the SAT application 5 (step 246) , the Mobile Equipment application 3 may for instance fetch a specific map for the user location area over the mobile network by using the appropriate Mobile Equipment OS function 11, and then display such a map on the Mobile Equipment display unit 12.

16. As no further processing is needed by the SIM 2, the Mobile Equipment application 3 acknowledges the result (step 254) and calls a DISCONNECT method of the SIM Gateway API 10 (step 256) ; the SIM Gateway 4, acknowledges the message (step 258) and gets then ready to accept a new connection request from another Mobile Equipment application.

The stated example illustrates how a provision of the arrangement described herein, namely the SIM Gateway function, solves the problem of allowing whatever software program running on a mobile phone to exchange custom data with a SAT application designed to support such interaction, by making use of a well- supported and widespread communications means on mobile phones like the SAT protocol.

Specifically, the arrangement described herein can be used to implement an interaction pattern between a Mobile Equipment application and a corresponding SAT Application that emulates a Remote Procedure Call (RPC) interface. This interface involves a module running on a device invoking a service provided by an application located on a different device, passing on input data to such service and having result of the service processing returned. The SIM Gateway function provides a Mobile Equipment application with an Application Programming Interface (SIM Gateway API) by means of which the Mobile Equipment application can interact with a SAT application. This can be configured to support the API for instance in accordance with the RPC programming paradigm.

The example described shows that, by exploiting ■such API, the Mobile Equipment application can launch the SAT application, provide it with whatever amount of generic information to be processed, wait for the SAT application to process the information and receive whatever amount of new information as result of such processing.

The example described also shows that the SIM Gateway can implement the SIM Gateway API interface by using a complete set or a subset of six standard SAT protocol commands, which normally enable activation of a SAT application by a physical user and exchange of textual information with the user.

According to the preferred embodiment of present invention, in order to enable bi-directional exchange of any data between applications resident on the mobile equipment 1 and the SIM 2, the standard SAT protocol commands in question are the following:

- The SET UP MENU command, used by the SIM Gateway to acquire knowledge of the SAT applications available on a SIM.

- The MENU SELECTION command, used by the SIM Gateway to select a specific SAT application among those available on a SIM.

The SELECT ITEM command, used by a SAT application to prompt activation of a specific function performed by such SAT application.

- The GET INPUT command, used by a SAT application to request input parameters.

The DISPLAY TEXT command, used by a SAT application to provide processing output.

- The TERMINAL RESPONSE command, used by the SIM Gateway to respond to the SAT application requests, namely to: select a function performed by a SAT application in response to a SELECT ITEM command,

- send input parameters to a SAT application in response to a GET INPUT command, and

- acknowledge receipt of a SAT application processing output in response to a DISPLAY TEXT command.

As will be apparent to a skilled person, the method according to present invention could be implemented by using fewer commands, by excluding, e.g. the GET INPUT command or the DISPLAY TEXT command, in case communications has to be provided only in one direction between applications resident on the mobile equipment 1 and the SIM 2.

As a first example, in case of one direction communication from the mobile equipment to the SIM, tacking as a reference the bi-directional communication disclosed in the foregoing, the SAT application on the SIM could perform a service specific function or processing without returning any processing output to the mobile equipment application.

As a further example, in case of one direction communication from the SIM to the mobile equipment, the mobile equipment application could cause said SIM application toolkit (SAT) application to perform a service specific processing by simply activating it, without the need to provide said SAT application with input parameters.

The SAT application may return the result of said service specific processing to the mobile equipment application.

As a rule, only one SAT application at a time can be active on a SIM. The SIM Gateway 4 just described thus ensures consistency of a single interaction session between a Mobile Equipment application and a SAT application, for instance an RPC session (intended as a complete cycle including launching a SAT application, transferring parameters to the SAT application and receiving the result from the SAT application) , by being in a position to refuse to serve connection requests from other Mobile Equipment applications while a session is in progress.

Consequently, without prejudice to the underlying principles of the invention, the details and the embodiments may vary, also appreciably, with reference to what has been described by way of example only, without departing from the scope of the invention as defined by the annexed claims .

Claims

1. A method of providing communication between applications running on communication equipment (1) and a SIM-type module (2) associated with said equipment

(1) by using a SIM application toolkit (SAT) protocol able to convey messages including user messages between a user of said equipment (1) and said SIM-type module

(1) , the method including the step of providing communication between said applications and said SIM- type module (2) via said user messages of said SIM application toolkit (SAT) protocol.

2. The method of claim 1, characterised in that it includes the step of providing at least one SIM gateway module (4) configured for providing communication between said applications and said SIM-type module (2) by emulating the interactions of said user of said equipment (1) with said SIM application toolkit (SAT) protocol .

3. The method of claim 1, characterised in that it includes the steps of: i) starting a SIM application toolkit (SAT) application on said SIM-type module (2) , ii) passing on data to said application, iii) processing said data by means of said application, and iv) causing said application to return the result of said processing to said communication equipment (D •

4. The method of claim 3, characterised in that it includes the step of repeating at least one of said steps i) to iv) .

5. The method of claim 1, characterised in that it includes alternatively the steps of: i) starting a SIM application toolkit (SAT) application on said SIM-type module (2) , ii) passing on data to said application, iii) processing said data by means of said application or the steps of i) starting a SIM application toolkit (SAT) application on said SIM-type module (2) , ii) causing said SIM application toolkit (SAT) application to perform a service specific processing, and iv) causing said SIM application toolkit (SAT) application to return a result of said service specific processing to said communication equipment (1) .

6. The method of claim 1, characterised in that said SIM application toolkit (SAT) protocol is associated with a SAT communication channel, and in that it includes the steps of : permitting concurrent access to said SAT communication channel by multiple programs running on said communication equipment (1) , and arbitrating said SAT communication channel access to ensure consistency of transactions occurring between said SIM-type module (2) and said communication equipment (1) .

7. The method of claim 1, characterised in that it includes the step of providing communication between said applications and said SIM-type module (2) by means of SIM applications toolkit (SAT) protocol commands selected from the group consisting of: - the SET UP MENU, to acquire knowledge of the SAT applications available on said SIM-type module (2) ,

- the MENU SELECTION command, to select a specific SAT application among those available on said SIM-type module (2) ,

- the SELECT ITEM command, to prompt activation of a specific function performed by a respective SAT application, the GET INPUT command, to request input parameters, the DISPLAY TEXT command, to provide the processing output, and

- the TERMINAL RESPONSE command, to respond to SAT application request.

8. The method of claim 7, characterised in that it includes the step of using said TERMINAL RESPONSE command to perform at least one of the operations of: selecting a function performed by a SAT application in respect to a SELECT ITEM command,

- sending input parameters to a SAT application in response to a GET INPUT command, and acknowledging receipt of a SAT application processing output in response to a DISPLAY TEXT command.

9. A system for providing communication between applications running on communication equipment (1) and a SIM-type module (2) associated with said equipment (1) , the system_, supporting a SIM application toolkit (SAT) protocol able to convey messages including user messages between a user of said equipment (1) and said SIM-type module (1) , wherein the system includes at least one SIM gateway module (4) for providing communication between said applications and said SIM- type module (2) via said user messages of said SIM application toolkit (SAT) protocol.

10. The system of claim 9, characterised in that at least one SIM gateway module (4) is an emulation module for emulating the interactions of said user of said equipment (1) with said SIM application toolkit

(SAT) protocol.

11. The system of claim 9, characterised in that said SIM application toolkit (SAT) protocol is associated with a SAT communication channel, and in that the system is configured for: permitting concurrent access to said SAT communication channel by multiple programs running on said communication equipment (1) , and arbitrating said SAT communication channel access to ensure consistency of transactions occurring between said SIM-type module (2) and said communication equipment (1) .

12. The system of claim 9, characterised in that said at least one SIM gateway module (4) is configured for providing communication between said applications and said SIM-type module (2) by means of SIM applications toolkit (SAT) protocol commands selected from the group consisting of:

- the SET UP MENU, to acquire knowledge of the SAT applications available on said SIM-type module (2) ,

- the TERMINAL RESPONSE command, to respond to SAT application request.

13. The system of claim 12, characterised in that said at least one SIM gateway module (4) is configured for using said TERMINAL RESPONSE command to perform at least one of the operations of: selecting a function performed by a SAT application in respect to a SELECT ITEM command,

14. Communication equipment (1) including the system of any of claims 9 to 13.

15. The equipment of claim 14, in the form of mobile communication equipment (1) .

16. The equipment of claim 15, in the form of a mobile phone (1) .

17. The equipment of claim 16, characterised in that said mobile_^ phone is a GSM mobile phone.

18. A computer program product loadable in the memory of at least one computer and including software code portions for performing the method of any of claims 1 to 8.