WO2005015930A1 - Method enabling an access point to communicate by using a mobile terminal - Google Patents

Method enabling an access point to communicate by using a mobile terminal Download PDF

Info

Publication number
WO2005015930A1
WO2005015930A1 PCT/FR2004/001559 FR2004001559W WO2005015930A1 WO 2005015930 A1 WO2005015930 A1 WO 2005015930A1 FR 2004001559 W FR2004001559 W FR 2004001559W WO 2005015930 A1 WO2005015930 A1 WO 2005015930A1
Authority
WO
WIPO (PCT)
Prior art keywords
security module
mobile terminal
memory
data
logical process
Prior art date
Application number
PCT/FR2004/001559
Other languages
French (fr)
Inventor
David Picquenot
Pierre Lemoine
Etienne Annic
Original Assignee
Orange France
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange France filed Critical Orange France
Priority to EP04767415A priority Critical patent/EP1649713A1/en
Publication of WO2005015930A1 publication Critical patent/WO2005015930A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data
    • H04W8/205—Transfer to or from user equipment or user record carrier

Definitions

  • the present invention relates to a method allowing a local access point to communicate with an application hosted by a security module of a mobile terminal.
  • the invention applies more particularly to communication from a communicating entity, present near a mobile terminal, to a security module of said mobile terminal.
  • Said communicating entity is for example a personal computer or
  • PC Personal Computer
  • communicating automaton a communicating terminal
  • communicating cash register a communicating cash register
  • mobile terminal etc. or any terminal including telecommunications means, data processing and storage means.
  • the security module of the mobile terminal is currently a card
  • SIM Subscriber Identity Module
  • USIM UMTS Subscriber Identity Module
  • WIM Wireless Fidelity Module
  • any other subscriber identification card of a mobile terminal any other subscriber identification card of a mobile terminal.
  • microprocessor card with storage means, coupled with said mobile terminal and allowing data exchange in accordance with the UICC standard (Universal Integrated Circuit).
  • SIM or USIM or WIM card, etc. is the element that makes it possible to provide security to mobile telephone networks, such as the GSM network ("Global System for Mobile communications", a global system for communications with mobile) or the GPRS network ("General
  • Packet Radio Service ", general radio service in packet mode).
  • said card allows subscriber authentication on the mobile network, encryption of voice or data exchanges, as well as terminal personalization It also allows other value-added services, notably services implemented in the form of "JavaCard” applets using the standard.
  • SIM Toolkit standard currently present on all SIM cards.
  • Said applets are logical processes typically programmed in JAVA language and specific for smart cards, in particular a SIM card or a USIM card, etc.
  • said cards communicate with a remote application server either by short message from SMS type ("Short Message Service”), either by transmission of USSD type ("Unstructured Supplementary Service Date", or by voice call.
  • SMS Short Message Service
  • USSD Unstructured Supplementary Service Date
  • Said local link can for example be an IrDA type link ("Infrared Data Association", infrared wireless link), a “Bluetooth” type link (short distance radio link), an NFC type link ("Near Field Communication” , very short distance communication and contactless) or a wired link in serial mode.
  • IrDA type link Infrared Data Association
  • Bluetooth Bluetooth
  • NFC Near Field Communication
  • GSM 11.14 and ETSI 31.111 European Telecommunications Standards Institute
  • the object of the invention which would make it possible to remedy the drawbacks of existing systems, is to allow a local access point, close to a mobile terminal, to exploit local links and this with the more general aim of developing secure proximity services with high added value, using the security provided by a security module of said mobile terminal.
  • the object is achieved by a method of exchanging data between at least a first logical process hosted on a local entity and at least a second logical process hosted on a security module of a mobile terminal, characterized in that said method, using the use of at least one transit memory located on said security module, is capable of responding to said first logical process by said second logical process by means of at least one message in said transit memory for managing at least one software application implemented by said local entity.
  • a local entity present near a mobile terminal, establishes communication with a security module of the mobile terminal.
  • Said local entity hosts a first logical process, which is requested by a software application implemented by said local entity.
  • Said first logical process of the local entity writes a message in a transit memory located on the security module of the mobile terminal.
  • Said security module of the mobile terminal hosts a second logical process, which responds to said first logical process of the local entity using the transit memory.
  • Said response is read by the first logical process which transmits it to said software application, which is the source of the request.
  • Said transit memory located on the security module of the mobile terminal is used to remotely manage a software application implemented by said local entity.
  • the resources of the security module allow for example the securing or the personalization of numerous services.
  • said method includes a step of establishing a communication link between the two logical processes.
  • the user of said mobile terminal must position it so as to establish communication with a local entity close to said mobile terminal.
  • Said communication is established via a communication link with, for example, wired cable transmission in serial mode or infrared wireless communication IrDA or radio wireless communication of Bluetooth type or communication of NFC type. Then, after the establishment of the call, it continues without any intervention from the user of the mobile terminal.
  • the exchange of data between the two logical processes is carried out by sending a request by said first logical process followed by at least one response from said second logical process.
  • the first logical process is requested by the software application and launches a request to the second logical process of the mobile terminal.
  • said second logical process accesses the request.
  • said first logical process will read the response to the request from said second logical process.
  • the exchange of request-response type between the two logical processes allows a simple implementation on the standard security module of a mobile terminal. The invention can therefore be implemented on current equipment without waiting for local communication standards.
  • FIG. 1 represents an assembly composed of a mobile terminal, a security module and a local entity, in accordance with the invention.
  • the local communicating device 10 or access point PA
  • the local communicating device 10 is represented by a personal computer of PC type, but it can be of different nature, for example a public terminal for communication with a messaging service, a communicating distributor of drinks with an electronic payment application, etc.
  • the invention is described with the names used in the terminology of GSM-type mobile telephone systems (mobile terminal, SIM card, etc.) .).
  • the invention applies to all types of security modules of a mobile terminal, such as a SIM card (Subscriber Identity Module), a USIM card (UMTS SIM), a WIM card (WAP Identity Module) or any other microprocessor card, with storage means, in accordance with UICC standard (Universal Integrated Circuit Card).
  • SIM Subscriber Identity Module
  • USIM USIM
  • WAP Identity Module WAP Identity Module
  • UICC Universal Integrated Circuit Card
  • the invention applies to networks and terminals connected to the UMTS mobile network (Universal Mobile Telecommunications System, or universal telecommunications system with mobiles), as well as to a USIM card (UMTS Subscriber Identity Module, or module UMTS subscriber identity).
  • the invention also applies to all communication systems using identical techniques for sending a request, followed by a response, via a command script.
  • the equipment concerned is at least one local communicating device 10 called access point or PA (Point Access) for example a PC, at least one mobile terminal 30 called MT (Mobile Terminal) equipped with a security module 20 (such as a SIM card) in said mobile terminal 30.
  • PA Point Access
  • MT Mobile Terminal
  • Several local entities 10 can enter into communication with said mobile terminal MT 30 according to the applications desired by the user, for example a PC, a beverage dispenser, etc., and momentarily present near said mobile terminal 30.
  • At least one first logical process 11, called SIM Trigger is hosted on said local entity 10 (or PA access point) in the form of an API (Application Program Interface).
  • said first logical process 11 (or SIM Trigger) is requested by at least one software application 12, called AppSoftware.
  • AppSoftware software application
  • the SIM Tooikit standard in the form of "JavaCard" applets is implemented on said security module 20 (for example a SIM card) by at least one second logic process 21, called AppCardIet, and allows the implementation of a service.
  • Said AppCardIet applet 21 is compatible with triggering by an external event, here to be triggered by said SIM Trigger 1 process 1.
  • Several logical processes 21 can be hosted by the security module 20 of a mobile terminal MT 30 allowing the implementation of different applications, such as data signing, management of access rights to digital content, electronic payment using an electronic wallet, transaction authentication, etc.
  • local communication link 1 is implemented via two communication interfaces 13, 23, located respectively on one side on the local entity 10 (or access point PA) and on the other side on said MT 30 mobile terminal.
  • a link is called a local communication link 1, if it is established between two devices close to each other and, in particular, over a distance significantly shorter than that separating a telephone from its server. closer in a regular cellular network. Said local communication link 1 typically takes place over a distance varying from a few centimeters to a few meters, or even a few tens of meters for local radio type links.
  • link signifies the existence of a time interval during which each of the two processes is in a particular configuration corresponding to the implementation of a data exchange with the other process.
  • This link is established by the appearance of the logical configuration of exchange on both sides, and ends with the closure of the link, namely the disappearance of the configuration of exchange, on both sides.
  • the two logical processes 1 1, 21 can both be located on the same mobile terminal MT 30, when said terminal is biprocessor, composed of an application processor and a modem processor, such as for example a communicating PDA terminal (Personal Digital Assistant) or a "Smartphone" type terminal.
  • the access point PA 10 is located on the processor of applications which support the open operating system (or OS, Operating System) of the terminal 30, so as to allow access to applications such as securing or personalizing services accessible by said terminal 30.
  • the communication between the two logical processes 11, 21 are carried out by means of a command script.
  • the commands exchanged in the script must be known by the two logical processes 11, 21, ie said SIM Trigger process 11 in the access point PA 10 and said AppCardIet applets 21 on the security module 20 (ie a SIM card).
  • the command script is exchanged via at least one transit memory 22, which is located on the security module 20.
  • Said transit memory 22, called SIM Buffer is used by said second logic process 21, or AppCardIet, of the security module 20 (such as a SIM card) for localized communication.
  • This allows the storage of data (or arguments) sent to said AppCardIet 21 applet and the storage of the result produced by said AppCardIet 21 applet.
  • said access point PA 10 enters into communication with said AppCardIet 21 applet hosted on the security module 20 of said mobile terminal MT 30.
  • the request-response type communication between the two processes SIM Trigger 11 and AppCardIet 21 is that listed below.
  • the procedure for using said SIM Buffer memory 22 by said first SIM Trigger process 11, hosted on said access point PA 10, is as follows.
  • the AppSoftware 12 software application implemented by said access point PA 10, calls the first SIM Trigger 11 process.
  • Said AppSoftware 12 software application sends a message in the form TriggerApplet (AppCardlet.ld, Arg, LINK_IRDA, CardletResponse) , with the identifier of the AppCardIet applet 21 as parameters to be triggered on the security module 20 (SIM card) of said MT mobile terminal 30, ie "AppCardlet.ld", as well as data (or arguments) "Arg” and the type of communication link 1 to be used for sending said data (IrDA infrared communication).
  • TriggerApplet AppCardlet.ld, Arg, LINK_IRDA, CardletResponse
  • the variable "CardletResponse” will contain the data of response of the AppCardIet 21 applet after the execution of said "TriggerApplet” function.
  • the SIM Trigger 11 process constitutes a first short message "m1" of SMS (Short Message Service) type, represented by a character string of 140 bytes in general, containing a header byte (0x01) followed by the identifier of the 'AppCardIet 21 applet to be triggered, as well as "Arg" data (or arguments), accompanied if necessary by padding bytes (OxFF).
  • SMS Short Message Service
  • the exchange of data between the two logical processes 11, 21 is carried out by the sending of a request by said SIM Trigger process 11, said short message "m1", followed by a response from said AppCardIet applet 21.
  • the user must position said mobile terminal MT 30 so as to establish communication with the access point PA 10, using the local communication link 1 (infrared communication IrDA).
  • the establishment of said local communication link 1 allows the exchange between the two logical processes
  • the SIM Buffer memory 22 can be at least constituted by an EFSMS file from the security module 20 (the SIM card) , as specified in the ETSI GSM 11.11 standard. Said EFSMS file is also dedicated to the storage of messaging texts, for example of SMS messages type
  • SIM Buffer 22 memory (Short Message Service).
  • the use of the SIM Buffer 22 memory by the SIM Trigger 11 process is preferably, but not exclusively, carried out by AT commands, the implementation of which is very widespread and which are specified in the ETSI GSM standards 07.05 and 07.07.
  • the SIM Trigger process 11 searches for a free location "IdSIot" in said EFSMS file of the security module 20 (SIM card) of the mobile terminal MT 30. It writes said first short SMS message "m1" in said file
  • AT + CMGW gives access to the message file
  • SMS from a SIM card via an IrDA, Bluetooth or serial port of a mobile terminal for example by a PC to use said terminal as a gateway with the mobile phone network.
  • the advantage of this command is that it works on all mobile terminals to write an SMS message to the EFSMS file on the SIM card or the USIM card.
  • other commands such as the AT + CRSM command can also be used to perform an update (or UpdateRecord) of the EFSMS file.
  • the SIM Trigger 11 process can read an SMS message written in said EFSMS file at record 0, then save it so as to rewrite it at the end of the procedure.
  • the SIM Trigger 11 process performs a periodic reading of the IdSIot record of the EFSMS file, checking whether the value of the first header byte is modified.
  • Said SIM Trigger process 11 is provided for repeatedly re-reading said SIM Buffer memory 22 in order to read a data item entered by said second logic process 21 or AppCardIet between two consecutive readings. Consequently, said first logical process 11 (ie the SIM Trigger process) of the local entity 10 writes and reads into said transit memory 22 (or the SIM Buffer transit memory) of the security module 20 of the mobile terminal 30 via the local communication link.
  • Said local communicating device 10 hosts said first logic process 11 programmed to use said transit memory 22 of said security module 20 of the mobile terminal 30.
  • Said SIM trigger process 11 (ie the first logic process) is provided for monitoring the appearance on said SIM Buffer 22 transit memory of at least one item of data written by the AppCardIet applet 21 (ie the second logical process).
  • the SIM Trigger 11 process periodically scans, for example every second, the content of the EFSMS file awaiting the response of the AppCardIet 21 applet. This reading is done by the command AT + CMGR sent by said SIM Trigger 11 process.
  • GSM 03.19 standards provide that JavaCard applets on the SIM card can detect and be triggered by external events, in particular by the event "EVENT_UNFORMATED_SMS_PP_UPD", which corresponds to the updating of the EFSMS file by a third-party application.
  • the AppCardIet 21 applet reacts to the event "EVENT_UNFORMATED_SMS_PP_UPD” and reads the first short SMS message "m1" written in said SIM Buffer 22 memory by the SIM Trigger 11 process. Said AppCardIet 21 applet reads the data (or arguments ) stored in the first short SMS message "m1". If the applet identifier corresponds to its own identifier, the AppCardIet 21 applet continues processing. Otherwise, the applet ends the processing and the operating system of the security module 20 (SIM card) sends the event to the other logical processes 21 (or applets) hosted by said security module 20 (SIM card).
  • SIM card operating system of the security module 20
  • the AppCardIet applet 21 performs the function, for which it is intended, on the Arg data read in the first short SMS message "m1", for example a data signature function, ie Signature (Arg, certificate).
  • the AppCardIet 21 applet writes to the EFSMS file the result of said function executed.
  • the AppCardIet 21 applet writes the signature on at least 8 bytes, generally 16 bytes, preceded by a header byte (0x01), in the form of a second message short SMS "m2" at the IdSIot location.
  • the SIM Trigger process 11 which was waiting for a response, reads said data entered by said second logical process 21 or AppCardIet.
  • Said SIM Trigger 11 process reads said response from the AppCardIet applet 21 and sends said response to the software application AppSoftware 12.
  • the software application for which it is intended, on the Arg data read in the first short SMS message "m1"
  • the software application for example a data signature function
  • AppSoftware 12 requested the SIM Trigger 11 process to obtain the said certificate from the AppCardIet 21 applet. The response from the applet
  • AppCardIet 21 allows the management of the software application 12 implemented by said access point PA 10. It is also possible to define a more elaborate data transport protocol, based on the use of several SMS messages. In this case, a header, indicating the number and the number of SMS messages used, will be introduced by the SIM Trigger 11 process.
  • the equipment concerned is a personal computer (or PC) as access point PA 10, hosting a software application 12 such as a MailApp messaging service, a terminal mobile MT 30 and a security module 20 (SIM card) hosting a data signing applet, ie SigCardlet 21.
  • Said MT mobile terminal 30 and said personal computer (or access point PA) 10 are suitably paired at a local communication link 1 of the Bluetooth short distance radio type.
  • said MT 30 mobile terminal is equipped with a Bluetooth port of the "Serial Port Profile" type.
  • the MailApp 12 software application calls the first SIM Trigger 11 process.
  • Said MailApp 12 software application sends a message in the form TriggerApplet (SigCardlet.ld, s, LINK_BluetoothSerialPort, CardletResponse), with parameters the identifier of the SigCardlet applet 21 to be triggered on the SIM card 20 of said MT mobile terminal 30, ie "SigCardIet.ld", as well as data "s" to be signed and the type of communication link 1 to be used for the 'sending of said data (BluetoothSerialPort communication).
  • the data "s” can be a summary of the electronic message (or mail) to be signed.
  • the "CardletResponse" variable will contain the response of the SigCardlet 21 applet, ie the signature produced, after execution of said "TriggerApplet” function.
  • the procedure, of request-response type continues as described above using the SIM Buffer 22 memory.
  • the exchange of data between the two logical processes (11, 21) is carried out by sending the request by the SIM process Trigger 11 followed by the response of said SigCardlet applet 21. Said procedure continues until the response from the SigCardlet 21 applet is read by the SIM Trigger 11 process and the sending of said response to the software application MailApp 12.
  • the MailApp software application 12 requested the SIM Trigger 11 process to obtain said signature of the data coming from the SigCardlet applet 21.
  • the response of the SigCardlet applet 21 allows the management of the MailApp 12 software application implemented by said access point PA 10.
  • the invention allows a logical process 21, hosted on a standard security module 20 of a mobile terminal without the need to add specific functions , to dialogue with an external access point PA 10 by means of a simplified request-response type data exchange, using a local communication link 1.
  • the implementation of the method is done via a SIM Buffer memory 22 located on said security module 20 (ie a SIM card).
  • the dialogue between the logical processes 11, 21 of the security module 20 and of the access point PA 10 is preferably, but not exclusively, carried out by a command script which is written and read in said SIM Buffer memory 22.
  • the second logical process 21 responds to the first logical process 11 to manage a software application 12 implemented by said access point PA 10.
  • the services that can be applied to this process are very numerous and allow authentication, control as well access, ticket issuance, data security, personalization of messages, etc.

Abstract

The invention relates to a method for data exchange between at least one first logic process (11) arranged on a local entity (10) and at least one second logic process (21) arranged on the safety module (20) of a mobile terminal (30). The inventive method uses at least one in-transit storage (22) arranged on said safety module, thereby making it possible to answer to said first logic process (11) by the second logic process (21) by means of at least one message in said in-transit storage (22) in order to manage at least one software application (12) used by said local entity. Said invention can be used for communicating from an entity (10) located near the mobile terminal (30) to the safety module (20) thereof.

Description

PROCEDE PERMETTANT A UN POINT D'ACCES DE COMMUNIQUER AVEC UNE APPLICATION D'UN TERMINAL MOBILE METHOD FOR PROVIDING AN ACCESS POINT TO COMMUNICATE WITH AN APPLICATION OF A MOBILE TERMINAL
La présente invention concerne un procédé permettant à un point d'accès local de communiquer avec une application hébergée par un module de sécurité d'un terminal mobile. L'invention s'applique plus particulièrement à la communication à partir d'une entité communicante, présente à proximité d'un terminal mobile, vers un module de sécurité dudit terminal mobile. Ladite entité communicante est par exemple un ordinateur personnel ouThe present invention relates to a method allowing a local access point to communicate with an application hosted by a security module of a mobile terminal. The invention applies more particularly to communication from a communicating entity, present near a mobile terminal, to a security module of said mobile terminal. Said communicating entity is for example a personal computer or
PC (Personal Computer), un automate communicant, une borne communicante, une caisse communicante, un terminal mobile, etc .. ou bien tout terminal incluant des moyens de télécommunications, des moyens de traitement et de mémorisation de données. Ledit module de sécurité du terminal mobile est actuellement une cartePC (Personal Computer), a communicating automaton, a communicating terminal, a communicating cash register, a mobile terminal, etc. or any terminal including telecommunications means, data processing and storage means. The security module of the mobile terminal is currently a card
SIM ("Subscriber Identity Module", module d'identité abonné) ou une carteSIM ("Subscriber Identity Module") or a card
USIM (UMTS Subscriber Identity Module) ou une carte WIM (WAP Identity Module) ou tout autre carte d'identification d'abonné d'un terminal mobile.USIM (UMTS Subscriber Identity Module) or a WIM card (WAP Identity Module) or any other subscriber identification card of a mobile terminal.
Mais elle peut également être une autre carte à microprocesseur, avec un moyen de mémorisation, couplée avec ledit terminal mobile et permettant un échange de données conforme à la norme UICC (Universal Integrated CircuitBut it can also be another microprocessor card, with storage means, coupled with said mobile terminal and allowing data exchange in accordance with the UICC standard (Universal Integrated Circuit).
Card, soit carte universelle à circuit intégré). Actuellement, la carte SIM ou USIM ou WIM, etc .. est l'élément permettant d'apporter la sécurité aux réseaux de téléphonie mobile, tels que le réseau GSM ("Global System for Mobile communications", système global pour les communications avec les mobiles) ou bien le réseau GPRS ("GeneralCard, or universal card with integrated circuit). Currently, the SIM or USIM or WIM card, etc. is the element that makes it possible to provide security to mobile telephone networks, such as the GSM network ("Global System for Mobile communications", a global system for communications with mobile) or the GPRS network ("General
Packet Radio Service", service général de radiocommunication en mode paquet). Entre autres fonctions, ladite carte permet l'authentification de l'abonné sur le réseau mobile, le chiffrement des échanges vocaux ou des échanges de données, ainsi que la personnalisation du terminal mobile. Elle permet également d'autres services à valeur ajoutée, notamment des services implémentés sous forme d'applets "JavaCard" utilisant la normePacket Radio Service ", general radio service in packet mode). Among other functions, said card allows subscriber authentication on the mobile network, encryption of voice or data exchanges, as well as terminal personalization It also allows other value-added services, notably services implemented in the form of "JavaCard" applets using the standard.
SIM Toolkit, norme actuellement présente sur l'ensemble des cartes SIM. Lesdites applets sont des processus logiques typiquement programmés en langage JAVA et spécifiques pour les cartes à puce, en particulier une carte SIM ou une carte USIM, etc .. Actuellement, en général, lesdites cartes communiquent avec un serveur applicatif distant soit par message court de type SMS ("Short Message Service", service des messages courts), soit par transmission de type USSD ("Unstructured Supplementary Service Date", données pour services supplémentaires non structurés), soit par appel vocal. Dans de nombreuses situations, il est souhaitable de faire communiquer les applets SIM avec un point d'accès local (PC, borne publique...) grâce à un lien local de communication. Ledit lien local peut être par exemple une liaison de type IrDA ("Infrared Data Association", liaison sans fil infrarouge), une liaison de type "Bluetooth" (liaison radio courte distance), une liaison de type NFC ("Near Field Communication", communication très courte distance et sans contact) ou bien une liaison filaire en mode série. Les normes GSM 11.14 et ETSI 31.111 (European Télécommunications Standards Institute, soit institut européen de normalisation des télécommunications), qui décrivent les fonctions SIM Tooikit pour la carte SIM (réseaux mobiles de seconde génération, par exemple réseau GSM) ou pour la carte USIM (pour réseaux mobiles de troisième génération, par exemple réseau UMTS), présentent une solution théorique en définissant des fonctions de communication indépendantes du lien local ("bearer indépendant protocol"). Ces fonctions permettent à la carte SIM ou la carte USIM d'ouvrir un canal de communication sur un lien local à préciser, d'envoyer ou de recevoir des données sur ce lien, de fermer le lien, etc... Cependant, la définition des couches "transport" d'un lien local de type IrDA (sans fil infrarouge) ou de type "Bluetooth" (sans fil radio) est à produire dans cette norme. De plus, pour utiliser les possibilités de cette norme, celle-ci devra être implémentée non seulement par les encarteurs, mais aussi par les fabricants de terminaux, ce qui la rend encore difficile à mettre en oeuvre de nos jours. Par ailleurs, les processus de communication avec une applet "JavaCard" sont décrits dans les normes ETSI GSM 11.11. Lesdits processus présentés dans cette norme sont réalisés uniquement par déclenchement "Over The Air" ("par les airs", soit par mode radio), par exemple déclenchement par un message SMS. Le déclenchement d'une applet "JavaCard" grâce à un lien local de communication ne fait l'objet d'aucune description. Enfin, dans le document FR 02 15521 , a été proposé un mode de communication, grâce à un lien local de communication, entre un module de sécurité (telle qu'une carte SIM) d'un terminal mobile et un point d'accès situé à proximité dudit terminal mobile. Dans ce document, ledit lien local de communication, par exemple une liaison de type IrDA (liaison infrarouge), doit être activé par l'utilisateur sur le terminal mobile et ledit utilisateur doit positionner son terminal mobile devant le port IrDA (infrarouge) dudit point d'accès local. Dans ce document, l'applet de la carte SIM doit être déclenchée par l'utilisateur et le processus logique du point d'accès local est également activé lors de l'établissement de la connexion vers ledit terminal mobile. L'échange des données étant bidirectionnel, celui-ci doit être synchronisé entre la carteSIM Toolkit, standard currently present on all SIM cards. Said applets are logical processes typically programmed in JAVA language and specific for smart cards, in particular a SIM card or a USIM card, etc. Currently, in general, said cards communicate with a remote application server either by short message from SMS type ("Short Message Service"), either by transmission of USSD type ("Unstructured Supplementary Service Date", or by voice call. In many situations, it is desirable to have SIM applets communicate with a local access point (PC, public terminal, etc.) using a local communication link. Said local link can for example be an IrDA type link ("Infrared Data Association", infrared wireless link), a "Bluetooth" type link (short distance radio link), an NFC type link ("Near Field Communication" , very short distance communication and contactless) or a wired link in serial mode. GSM 11.14 and ETSI 31.111 (European Telecommunications Standards Institute), which describe the SIM Tooikit functions for the SIM card (second generation mobile networks, for example GSM network) or for the USIM card ( for third generation mobile networks, for example UMTS network), present a theoretical solution by defining communication functions independent of the local link ("bearer independent protocol"). These functions allow the SIM card or the USIM card to open a communication channel on a local link to be specified, to send or receive data on this link, to close the link, etc. However, the definition "transport" layers of a local IrDA type link (infrared wireless) or "Bluetooth" type (radio wireless) is to be produced in this standard. In addition, to use the possibilities of this standard, it will have to be implemented not only by inserters, but also by terminal manufacturers, which still makes it difficult to implement today. In addition, the communication processes with a "JavaCard" applet are described in the ETSI GSM 11.11 standards. Said processes presented in this standard are carried out only by triggering "Over The Air"("byair", ie by radio mode), for example triggered by an SMS message. The triggering of a "JavaCard" applet through a local communication link is not described. Finally, in document FR 02 15521, a mode of communication has been proposed, thanks to a local communication link, between a security module (such as a SIM card) of a mobile terminal and an access point located near said mobile terminal. In this document, said local communication link, for example an IrDA type link (infrared link), must be activated by the user on the mobile terminal and said user must position his mobile terminal in front of the IrDA (infrared) port of said point. local access. In this document, the SIM card applet must be triggered by the user and the logical process of the local access point is also activated when establishing the connection to said mobile terminal. The data exchange being bidirectional, it must be synchronized between the card
SIM et le point d'accès local. Par conséquent, une applet spécifique est prévue dans la carte SIM standard du terminal mobile, entre autre, pour permettre la réalisation de la communication bidirectionnelle et ladite synchronisation des échanges entre la carte SIM et le point d'accès local. Les deux processus respectifs sont donc prévus pour surveiller l'apparition d'une donnée en provenance de l'autre processus. De ce fait, les processus mis en œuvre pour ce mode bidirectionnel de communication sont complexes, de manière à rendre possible de nombreuses fonctionnalités décrites dans ledit document cité. Le but de l'invention, qui permettrait de remédier aux inconvénients des systèmes existants, est de permettre à un point d'accès local, proche d'un terminal mobile, d'exploiter des liens locaux et ceci dans le but plus général de développer des services de proximité sécurisés à haute valeur ajoutée, en utilisant la sécurité apportée par un module de sécurité dudit terminal mobile. Le résultat technique obtenu, tel qu'implémenté préférentiellement dans le point d'accès et dans le module de sécurité du terminal mobile, vise à offrir des services de communication locale grâce à des liens de type câble filaire en mode série, de type sans fil infrarouge IrDA ou de type sans fil radio Bluetooth. Selon l'invention, le but est atteint grâce à un procédé d'échange de données entre au moins un premier processus logique hébergé sur une entité locale et au moins un deuxième processus logique hébergé sur un module de sécurité d'un terminal mobile, caractérisé en ce que ledit procédé, faisant appel à l'utilisation d'au moins une mémoire de transit située sur ledit module de sécurité, est apte à répondre audit premier processus logique par ledit deuxième processus logique par l'intermédiaire d'au moins un message dans ladite mémoire de transit pour gérer au moins une application logicielle mise en œuvre par ladite entité locale. Une entité locale, présente à proximité d'un terminal mobile, établit une communication avec un module de sécurité du terminal mobile. Ladite entité locale héberge un premier processus logique, qui est sollicité par une application logicielle mise en œuvre par ladite entité locale. Ledit premier processus logique de l'entité locale écrit un message dans une mémoire de transit située sur le module de sécurité du terminal mobile. Ledit module de sécurité du terminal mobile héberge un deuxième processus logique, qui répond audit premier processus logique de l'entité locale en utilisant la mémoire de transit. Ladite réponse est lue par le premier processus logique qui la transmet vers ladite application logicielle, qui est à l'origine de la sollicitation. Ladite mémoire de transit située sur le module de sécurité du terminal mobile est utilisée pour gérer à distance une application logicielle mise en œuvre par ladite entité locale. Les ressources du module de sécurité, soit un ou plusieurs processus logiques, permettent par exemple la sécurisation ou la personnalisation de nombreux services. Conformément à l'invention, ledit procédé inclut une étape d'établissement d'un lien de communication entre les deux processus logiques. L'utilisateur dudit terminal mobile doit le positionner de façon à établir la communication avec une entité locale proche dudit terminal mobile. Ladite communication s'établit par l'intermédiaire d'un lien de communication avec par exemple transmission par câble filaire en mode série ou communication sans fil infrarouge IrDA ou communication sans fil radio de type Bluetooth ou communication de type NFC. Ensuite, après l'établissement de la communication, celle-ci se poursuit sans aucune intervention de l'utilisateur du terminal mobile. Conformément à l'invention, l'échange de données entre les deux processus logiques est réalisé par l'envoi d'une requête par ledit premier processus logique suivi d'au moins une réponse dudit deuxième processus logique. Sur l'entité locale, le premier processus logique est sollicité par l'application logicielle et lance une requête vers le deuxième processus logique du terminal mobile. Une fois que l'utilisateur dudit terminal mobile a établi la communication, ledit deuxième processus logique accède à la requête. Puis, ledit premier processus logique va lire la réponse à la requête en provenance dudit deuxième processus logique. L'échange de type requête-réponse entre les deux processus logiques permet une implémentation simple sur le module de sécurité standard d'un terminal mobile. L'invention peut donc être mise en œuvre sur les équipements actuels sans attendre les normes de communication locales. La description qui va suivre en regard du dessin annexé, donné à titre d'exemple non limitatif, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. La figure 1 représente un ensemble composé d'un terminal mobile, d'un module de sécurité et d'une entité locale, conforme à l'invention. Pour simplifier la description, le dispositif local communicant 10 (ou point d'accès PA) est représentée par un ordinateur personnel de type PC, mais elle peut être de différente nature, par exemple une borne publique de communication avec un service de messagerie, un distributeur communicant de boissons avec une application de paiement électronique, etc.... Pour faciliter la compréhension, l'invention est décrite avec les appellations utilisées dans la terminologie des systèmes de téléphonie mobile de type GSM (terminal mobile, carte SIM, ...). Toutefois, l'invention s'applique à tous les types de modules de sécurité d'un terminal mobile, tel qu'une carte SIM (Subscriber Identity Module), une carte USIM (UMTS SIM), une carte WIM (WAP Identity Module) ou tout autre carte à microprocesseur, avec un moyen de mémorisation, conforme à la norme UICC (Universal Integrated Circuit Card, soit carte universelle à circuit intégré). En particulier, l'invention s'applique aux réseaux et aux terminaux connectés au réseau mobile UMTS (Universal Mobile Télécommunications System, soit système universel de télécommunications avec les mobiles), ainsi qu'à une carte USIM (UMTS Subscriber Identity Module, soit module d'identité abonné UMTS). L'invention s'applique également à tous les systèmes de communication utilisant des techniques identiques d'envoi d'une requête, suivie d'une réponse, par l'intermédiaire d'un script de commandes. L'exemple privilégié de mise en œuvre de l'invention, tel qu'il est décrit ci-dessous, concerne le cas d'une implémentation de type SIM Tooikit sur un module de sécurité 20 d'un terminal mobile 30 avec utilisation d'un lien 1 de communication de type sans fil infrarouge IrDA (lien infrarouge connu en soi). Sur la figure 1 qui représente un ensemble mettant en œuvre l'invention, les équipements concernés sont au moins un dispositif local communicant 10 appelée point d'accès ou PA (Point Access) par exemple un PC, au moins un terminal mobile 30 appelé MT (Mobile Terminal) équipé d'un module de sécurité 20 (telle qu'une carte SIM) dans ledit terminal mobile 30. Plusieurs entités locales 10 (ou point d'accès PA) peuvent entrer en communication avec ledit terminal mobile MT 30 selon les applications souhaitées par l'utilisateur, par exemple un PC, un distributeur de boissons, etc .. , et momentanément présentes à proximité dudit terminal mobile 30. Au moins un premier processus logique 1 1 , appelé SIM Trigger, est hébergé sur ladite entité locale 10 (ou point d'accès PA) sous la forme d'une API (Application Program Interface, soit interface de programme d'application). Sur ladite entité locale 10 (ou point d'accès PA), ledit premier processus logique 1 1 (ou SIM Trigger) est sollicité par au moins une application logicielle 12, appelée AppSoftware. La norme SIM Tooikit sous forme d'applets "JavaCard", est implémentée sur ledit module de sécurité 20 (par exemple une carte SIM) par au moins un deuxième processus logique 21 , appelé AppCardIet, et permet la mise en œuvre d'un service de proximité, tels que le chiffrement de données, la certification de données ou une authentification. Ladite applet AppCardIet 21 est compatible avec le déclenchement par un événement extérieur, ici pour être déclenchée par ledit processus SIM Trigger 1 1. Plusieurs processus logiques 21 (sous la forme d'applets) peuvent être hébergés par le module de sécurité 20 d'un terminal mobile MT 30 permettant la mise en œuvre de différentes applications, telles que la signature de données, la gestion de droits d'accès à des contenus numériques, le paiement électronique grâce à un porte-monnaie électronique, l'authentification de transaction, etc .. Ledit lien local 1 de communication est mis en œuvre par l'intermédiaire de deux interfaces 13, 23 de communication, situés respectivement d'un côté sur l'entité locale 10 (ou point d'accès PA) et de l'autre côté sur ledit terminal mobile MT 30. Ce sont par exemple des interfaces 13, 23 pour communication avec transmission par câble filaire en mode série, communication sans fil infrarouge IrDA (communication optique), communication sans fil radio de type Bluetooth, communication de type NFC (radiocommunication de proximité). De façon générale, un lien est appelé lien local 1 de communication, s'il est établi entre deux équipements proches l'un de l'autre et, en particulier, sur une distance nettement plus faible que celle séparant un téléphone de son serveur le plus proche dans un réseau cellulaire habituel. Ledit lien local 1 de communication prend typiquement place sur une distance variant de quelques centimètres à quelques mètres, voire sur quelques dizaines de mètre pour les liens locaux de type radio. Le terme lien, tel qu'appliqué à deux processus logiques, signifie l'existence d'un intervalle de temps pendant lequel chacun des deux processus est dans une configuration particulière correspondant à la mise en œuvre d'un échange de données avec l'autre processus. Ce lien s'établit par l'apparition de la configuration logique d'échange de part et d'autre, et se termine par la clôture du lien, à savoir la disparition de la configuration d'échange, de part et d'autre. Les deux processus logiques 1 1 , 21 peuvent être situés, tous les deux, sur un même terminal mobile MT 30, lorsque que ledit terminal est biprocesseur, composé d'un processeur d'applications et d'un processeur modem, tel que par exemple un terminal PDA communicant (Personal Digital Assistant, soit assistant personnel numérique) ou bien un terminal de type "Smartphone". Dans ce cas, le point d'accès PA 10 est situé sur le processeur d'applications qui supporte le système d'exploitation ouvert (ou OS, Operating System) du terminal 30, de manière à permettre l'accès à des applications telles que la sécurisation ou la personnalisation de services accessibles par ledit terminal 30. La communication entre les deux processus logiques 11 , 21 s'effectue par l'intermédiaire d'un script de commandes. Les commandes échangées dans le script doivent être connues par les deux processus logiques 11 , 21 , soit ledit processus SIM Trigger 11 dans le point d'accès PA 10 et ladite applets AppCardIet 21 sur le module de sécurité 20 (soit une carte SIM). Comme la description le montrera par la suite, le script de commandes est échangé par l'intermédiaire d'au moins une mémoire de transit 22, qui est située sur le module de sécurité 20. Ladite mémoire de transit 22, appelée SIM Buffer, est utilisée par ledit deuxième processus logique 21 , ou AppCardIet, du module de sécurité 20 (telle qu'une carte SIM) pour la communication localisée. Celle-ci permet le stockage de données (ou arguments) envoyées vers ladite applet AppCardIet 21 et le stockage du résultat produit par ladite applet AppCardIet 21. Selon l'invention, ledit point d'accès PA 10 entre en communication avec ladite applet AppCardIet 21 hébergée sur le module de sécurité 20 dudit terminal mobile MT 30. Dans le présent exemple, la communication de type requête-réponse entre les deux processus SIM Trigger 11 et AppCardIet 21 est celle énumérée ci-après. Pour ce faire, la procédure d'utilisation de ladite mémoire SIM Buffer 22 par ledit premier processus SIM Trigger 11 , hébergé sur ledit point d'accès PA 10, est la suivante. L'application logicielle AppSoftware 12, mise en œuvre par ledit point d'accès PA 10, appelle le premier processus SIM Trigger 11. Ladite application logicielle AppSoftware 12 émet un message sous la forme TriggerApplet(AppCardlet.ld,Arg,LINK_IRDA,CardletResponse), avec pour paramètres l'identifiant de l'applet AppCardIet 21 à déclencher sur le module de sécurité 20 (carte SIM) dudit terminal mobile MT 30, soit "AppCardlet.ld", ainsi que des données (ou arguments) "Arg" et le type de lien 1 de communication à utiliser pour l'envoi desdites données (communication infrarouge IrDA). La variable "CardletResponse" contiendra les données de réponse de l'applet AppCardIet 21 après l'exécution de ladite fonction "TriggerApplet". Le processus SIM Trigger 11 constitue un premier message court "m1" de type SMS (Short Message Service), représenté par une chaîne de caractères de 140 octets en général, contenant un octet d'entêté (0x01 ) suivi de l'identifiant de l'applet AppCardIet 21 à déclencher, ainsi que des données (ou arguments) "Arg", accompagnées si besoin par des octets de bourrage (OxFF). L'échange de données entre les deux processus logiques 11 , 21 est réalisé par l'envoi d'une requête par ledit processus SIM Trigger 11 , ledit message court "m1", suivi d'une réponse de ladite applet AppCardIet 21. L'utilisateur doit positionner ledit terminal mobile MT 30 de façon à établir la communication avec le point d'accès PA 10, grâce au lien local 1 de communication (communication infrarouge IrDA). L'établissement dudit lien local 1 de communication permet l'échange entre les deux processus logiquesSIM and local access point. Consequently, a specific applet is provided in the standard SIM card of the mobile terminal, among other things, to allow the realization of bidirectional communication and said synchronization of exchanges between the SIM card and the local access point. The two respective processes are therefore provided for monitoring the appearance of data coming from the other process. As a result, the processes implemented for this bidirectional mode of communication are complex, so as to make possible many of the functionalities described in said cited document. The object of the invention, which would make it possible to remedy the drawbacks of existing systems, is to allow a local access point, close to a mobile terminal, to exploit local links and this with the more general aim of developing secure proximity services with high added value, using the security provided by a security module of said mobile terminal. The technical result obtained, as preferably implemented in the access point and in the security module of the mobile terminal, aims to offer local communication services using wired cable type links in serial mode, wireless type infrared IrDA or wireless type Bluetooth radio. According to the invention, the object is achieved by a method of exchanging data between at least a first logical process hosted on a local entity and at least a second logical process hosted on a security module of a mobile terminal, characterized in that said method, using the use of at least one transit memory located on said security module, is capable of responding to said first logical process by said second logical process by means of at least one message in said transit memory for managing at least one software application implemented by said local entity. A local entity, present near a mobile terminal, establishes communication with a security module of the mobile terminal. Said local entity hosts a first logical process, which is requested by a software application implemented by said local entity. Said first logical process of the local entity writes a message in a transit memory located on the security module of the mobile terminal. Said security module of the mobile terminal hosts a second logical process, which responds to said first logical process of the local entity using the transit memory. Said response is read by the first logical process which transmits it to said software application, which is the source of the request. Said transit memory located on the security module of the mobile terminal is used to remotely manage a software application implemented by said local entity. The resources of the security module, that is to say one or more logical processes, allow for example the securing or the personalization of numerous services. According to the invention, said method includes a step of establishing a communication link between the two logical processes. The user of said mobile terminal must position it so as to establish communication with a local entity close to said mobile terminal. Said communication is established via a communication link with, for example, wired cable transmission in serial mode or infrared wireless communication IrDA or radio wireless communication of Bluetooth type or communication of NFC type. Then, after the establishment of the call, it continues without any intervention from the user of the mobile terminal. According to the invention, the exchange of data between the two logical processes is carried out by sending a request by said first logical process followed by at least one response from said second logical process. On the local entity, the first logical process is requested by the software application and launches a request to the second logical process of the mobile terminal. Once the user of said mobile terminal has established communication, said second logical process accesses the request. Then, said first logical process will read the response to the request from said second logical process. The exchange of request-response type between the two logical processes allows a simple implementation on the standard security module of a mobile terminal. The invention can therefore be implemented on current equipment without waiting for local communication standards. The description which follows with reference to the appended drawing, given by way of nonlimiting example, will make it clear what the invention consists of and how it can be implemented. FIG. 1 represents an assembly composed of a mobile terminal, a security module and a local entity, in accordance with the invention. To simplify the description, the local communicating device 10 (or access point PA) is represented by a personal computer of PC type, but it can be of different nature, for example a public terminal for communication with a messaging service, a communicating distributor of drinks with an electronic payment application, etc. To facilitate understanding, the invention is described with the names used in the terminology of GSM-type mobile telephone systems (mobile terminal, SIM card, etc.) .). However, the invention applies to all types of security modules of a mobile terminal, such as a SIM card (Subscriber Identity Module), a USIM card (UMTS SIM), a WIM card (WAP Identity Module) or any other microprocessor card, with storage means, in accordance with UICC standard (Universal Integrated Circuit Card). In particular, the invention applies to networks and terminals connected to the UMTS mobile network (Universal Mobile Telecommunications System, or universal telecommunications system with mobiles), as well as to a USIM card (UMTS Subscriber Identity Module, or module UMTS subscriber identity). The invention also applies to all communication systems using identical techniques for sending a request, followed by a response, via a command script. The preferred example of implementation of the invention, as described below, relates to the case of an implementation of the SIM Tooikit type on a security module 20 of a mobile terminal 30 with the use of a communication link 1 of the IrDA infrared wireless type (infrared link known per se). In FIG. 1 which represents an assembly implementing the invention, the equipment concerned is at least one local communicating device 10 called access point or PA (Point Access) for example a PC, at least one mobile terminal 30 called MT (Mobile Terminal) equipped with a security module 20 (such as a SIM card) in said mobile terminal 30. Several local entities 10 (or access point PA) can enter into communication with said mobile terminal MT 30 according to the applications desired by the user, for example a PC, a beverage dispenser, etc., and momentarily present near said mobile terminal 30. At least one first logical process 11, called SIM Trigger, is hosted on said local entity 10 (or PA access point) in the form of an API (Application Program Interface). On said local entity 10 (or access point PA), said first logical process 11 (or SIM Trigger) is requested by at least one software application 12, called AppSoftware. The SIM Tooikit standard in the form of "JavaCard" applets, is implemented on said security module 20 (for example a SIM card) by at least one second logic process 21, called AppCardIet, and allows the implementation of a service. proximity, such as data encryption, data certification or authentication. Said AppCardIet applet 21 is compatible with triggering by an external event, here to be triggered by said SIM Trigger 1 process 1. Several logical processes 21 (in the form of applets) can be hosted by the security module 20 of a mobile terminal MT 30 allowing the implementation of different applications, such as data signing, management of access rights to digital content, electronic payment using an electronic wallet, transaction authentication, etc. local communication link 1 is implemented via two communication interfaces 13, 23, located respectively on one side on the local entity 10 (or access point PA) and on the other side on said MT 30 mobile terminal. These are for example interfaces 13, 23 for communication with wired cable transmission in serial mode, infrared wireless communication IrDA (optical communication), wireless communication r Bluetooth type adio, NFC type communication (proximity radio). In general, a link is called a local communication link 1, if it is established between two devices close to each other and, in particular, over a distance significantly shorter than that separating a telephone from its server. closer in a regular cellular network. Said local communication link 1 typically takes place over a distance varying from a few centimeters to a few meters, or even a few tens of meters for local radio type links. The term link, as applied to two logical processes, signifies the existence of a time interval during which each of the two processes is in a particular configuration corresponding to the implementation of a data exchange with the other process. This link is established by the appearance of the logical configuration of exchange on both sides, and ends with the closure of the link, namely the disappearance of the configuration of exchange, on both sides. The two logical processes 1 1, 21 can both be located on the same mobile terminal MT 30, when said terminal is biprocessor, composed of an application processor and a modem processor, such as for example a communicating PDA terminal (Personal Digital Assistant) or a "Smartphone" type terminal. In this case, the access point PA 10 is located on the processor of applications which support the open operating system (or OS, Operating System) of the terminal 30, so as to allow access to applications such as securing or personalizing services accessible by said terminal 30. The communication between the two logical processes 11, 21 are carried out by means of a command script. The commands exchanged in the script must be known by the two logical processes 11, 21, ie said SIM Trigger process 11 in the access point PA 10 and said AppCardIet applets 21 on the security module 20 (ie a SIM card). As the description will show below, the command script is exchanged via at least one transit memory 22, which is located on the security module 20. Said transit memory 22, called SIM Buffer, is used by said second logic process 21, or AppCardIet, of the security module 20 (such as a SIM card) for localized communication. This allows the storage of data (or arguments) sent to said AppCardIet 21 applet and the storage of the result produced by said AppCardIet 21 applet. According to the invention, said access point PA 10 enters into communication with said AppCardIet 21 applet hosted on the security module 20 of said mobile terminal MT 30. In the present example, the request-response type communication between the two processes SIM Trigger 11 and AppCardIet 21 is that listed below. To do this, the procedure for using said SIM Buffer memory 22 by said first SIM Trigger process 11, hosted on said access point PA 10, is as follows. The AppSoftware 12 software application, implemented by said access point PA 10, calls the first SIM Trigger 11 process. Said AppSoftware 12 software application sends a message in the form TriggerApplet (AppCardlet.ld, Arg, LINK_IRDA, CardletResponse) , with the identifier of the AppCardIet applet 21 as parameters to be triggered on the security module 20 (SIM card) of said MT mobile terminal 30, ie "AppCardlet.ld", as well as data (or arguments) "Arg" and the type of communication link 1 to be used for sending said data (IrDA infrared communication). The variable "CardletResponse" will contain the data of response of the AppCardIet 21 applet after the execution of said "TriggerApplet" function. The SIM Trigger 11 process constitutes a first short message "m1" of SMS (Short Message Service) type, represented by a character string of 140 bytes in general, containing a header byte (0x01) followed by the identifier of the 'AppCardIet 21 applet to be triggered, as well as "Arg" data (or arguments), accompanied if necessary by padding bytes (OxFF). The exchange of data between the two logical processes 11, 21 is carried out by the sending of a request by said SIM Trigger process 11, said short message "m1", followed by a response from said AppCardIet applet 21. The user must position said mobile terminal MT 30 so as to establish communication with the access point PA 10, using the local communication link 1 (infrared communication IrDA). The establishment of said local communication link 1 allows the exchange between the two logical processes
11 , 21. Une fois la communication établie, la procédure se poursuit sans intervention de l'utilisateur du terminal mobile MT 30. La mémoire SIM Buffer 22 peut être au moins constituée par un fichier EFSMS du module de sécurité 20 (la carte SIM), tel que spécifié dans la norme ETSI GSM 11.11. Ledit fichier EFSMS est également dédié à la mémorisation de textes de messagerie, par exemple de type messages SMS11, 21. Once the communication is established, the procedure continues without intervention by the user of the MT mobile terminal 30. The SIM Buffer memory 22 can be at least constituted by an EFSMS file from the security module 20 (the SIM card) , as specified in the ETSI GSM 11.11 standard. Said EFSMS file is also dedicated to the storage of messaging texts, for example of SMS messages type
(Short Message Service). L'utilisation de la mémoire SIM Buffer 22 par le processus SIM Trigger 11 s'effectue de préférence, mais non exclusivement, par des commandes AT, dont l'implémentation est très répandue et qui sont spécifiées dans les normes ETSI GSM 07.05 et 07.07. Le processus SIM Trigger 11 recherche un emplacement libre "IdSIot" dans ledit fichier EFSMS du module de sécurité 20 (carte SIM) du terminal mobile MT 30. Il écrit ledit premier message court SMS "m1" dans ledit fichier(Short Message Service). The use of the SIM Buffer 22 memory by the SIM Trigger 11 process is preferably, but not exclusively, carried out by AT commands, the implementation of which is very widespread and which are specified in the ETSI GSM standards 07.05 and 07.07. The SIM Trigger process 11 searches for a free location "IdSIot" in said EFSMS file of the security module 20 (SIM card) of the mobile terminal MT 30. It writes said first short SMS message "m1" in said file
EFSMS via ledit lien local 1 de communication, en utilisant une commandeEFSMS via said local communication link 1, using a command
AT+CMGW. La commande AT+CMGW permet d'accéder au fichier des messagesAT + CMGW. AT + CMGW command gives access to the message file
SMS d'une carte SIM via un port IrDA, Bluetooth ou série d'un terminal mobile, par exemple par un PC pour utiliser ledit terminal en tant que passerelle avec le réseau de téléphonie mobile. L'avantage de cette commande est qu'elle fonctionne sur tous les terminaux mobiles pour écrire un message SMS dans le fichier EFSMS de la carte SIM ou de la carte USIM. Toutefois, d'autres commandes comme la commande AT+CRSM peut également être utilisée pour réaliser une mise à jour (ou UpdateRecord) du fichier EFSMS. Dans le cas où aucun emplacement n'est disponible dans le fichier EFSMS, le processus SIM Trigger 11 peut lire un message SMS écrit dans ledit fichier EFSMS à l'enregistrement 0, puis le sauvegarder de manière à le réécrire en fin de procédure. Ensuite, le processus SIM Trigger 11 réalise une lecture périodique de l'enregistrement IdSIot du fichier EFSMS en vérifiant si la valeur du premier octet d'entêté est modifiée. Ledit processus SIM Trigger 11 est prévu pour relire à répétition ladite mémoire SIM Buffer 22 afin de relever une donnée inscrite par ledit deuxième processus logique 21 ou AppCardIet entre deux lectures consécutives. Par conséquent, ledit premier processus logique 11 (soit le processus SIM Trigger) de l'entité locale 10 écrit et lit dans ladite mémoire de transit 22 (soit la mémoire de transit SIM Buffer) du module de sécurité 20 du terminal mobile 30 via le lien de communication local. Ledit dispositif local communicant 10 héberge ledit premier processus logique 11 programmé pour utiliser ladite mémoire de transit 22 dudit module de sécurité 20 du terminal mobile 30. Ledit processus SIM trigger 11 (soit le premier processus logique) est prévu pour surveiller l'apparition sur ladite mémoire de transit SIM Buffer 22 d'au moins une donnée inscrite par l'applet AppCardIet 21 (soit le deuxième processus logique). Le processus SIM Trigger 11 scrute périodiquement, par exemple toutes les secondes, le contenu du fichier EFSMS en attente de la réponse de l'applet AppCardIet 21. Cette lecture se fait par la commande AT+CMGR envoyée par ledit processus SIM Trigger 11. Il est prévu dans les normes GSM 03.19 que les applets JavaCard de la carte SIM puissent détecter et être déclenchées par des événements externes et notamment par l'événement "EVENT_UNFORMATED_SMS_PP_UPD", qui correspond à la mise à jour du fichier EFSMS par une application tierce. Par conséquent, l'applet AppCardIet 21 réagit à l'événement "EVENT_UNFORMATED_SMS_PP_UPD" et lit le premier message court SMS "m1" écrit dans ladite mémoire SIM Buffer 22 par le processus SIM Trigger 11. Ladite applet AppCardIet 21 lit les données (ou arguments) stockées dans le premier message court SMS "m1". Si l'identifiant de l'applet correspond à son propre identifant, l'applet AppCardIet 21 continue le traitement. Sinon, l'applet termine le traitement et le système d'exploitation du module de sécurité 20 (carte SIM) envoie l'événement aux autres processus logiques 21 (ou applets) hébergées par ledit module de sécurité 20 (carte SIM). L'applet AppCardIet 21 exécute la fonction, pour laquelle elle est prévue, sur les données Arg lues dans le premier message court SMS "m1", par exemple une fonction de signature de données, soit Signature(Arg,certificat). L'applet AppCardIet 21 écrit dans le fichier EFSMS le résultat de ladite fonction exécutée. Dans le cas de la fonction de signature de données, l'applet AppCardIet 21 écrit la signature sur au moins 8 octets, en général 16 octets, précédée d'un octet d'entêté (0x01 ), sous la forme d'un deuxième message court SMS "m2" à l'emplacement IdSIot. Dans le point d'accès PA 10, le processus SIM Trigger 11 , qui était en attente de réponse, lit ladite donnée inscrite par ledit deuxième processus logique 21 ou AppCardIet. Ledit processus SIM Trigger 11 lit ladite réponse en provenance de l'applet AppCardIet 21 et envoie ladite réponse vers l'application logicielle AppSoftware 12. Dans le cas de la signature de données, l'application logicielleSMS from a SIM card via an IrDA, Bluetooth or serial port of a mobile terminal, for example by a PC to use said terminal as a gateway with the mobile phone network. The advantage of this command is that it works on all mobile terminals to write an SMS message to the EFSMS file on the SIM card or the USIM card. However, other commands such as the AT + CRSM command can also be used to perform an update (or UpdateRecord) of the EFSMS file. In the event that no location is available in the EFSMS file, the SIM Trigger 11 process can read an SMS message written in said EFSMS file at record 0, then save it so as to rewrite it at the end of the procedure. Then, the SIM Trigger 11 process performs a periodic reading of the IdSIot record of the EFSMS file, checking whether the value of the first header byte is modified. Said SIM Trigger process 11 is provided for repeatedly re-reading said SIM Buffer memory 22 in order to read a data item entered by said second logic process 21 or AppCardIet between two consecutive readings. Consequently, said first logical process 11 (ie the SIM Trigger process) of the local entity 10 writes and reads into said transit memory 22 (or the SIM Buffer transit memory) of the security module 20 of the mobile terminal 30 via the local communication link. Said local communicating device 10 hosts said first logic process 11 programmed to use said transit memory 22 of said security module 20 of the mobile terminal 30. Said SIM trigger process 11 (ie the first logic process) is provided for monitoring the appearance on said SIM Buffer 22 transit memory of at least one item of data written by the AppCardIet applet 21 (ie the second logical process). The SIM Trigger 11 process periodically scans, for example every second, the content of the EFSMS file awaiting the response of the AppCardIet 21 applet. This reading is done by the command AT + CMGR sent by said SIM Trigger 11 process. GSM 03.19 standards provide that JavaCard applets on the SIM card can detect and be triggered by external events, in particular by the event "EVENT_UNFORMATED_SMS_PP_UPD", which corresponds to the updating of the EFSMS file by a third-party application. Consequently, the AppCardIet 21 applet reacts to the event "EVENT_UNFORMATED_SMS_PP_UPD" and reads the first short SMS message "m1" written in said SIM Buffer 22 memory by the SIM Trigger 11 process. Said AppCardIet 21 applet reads the data (or arguments ) stored in the first short SMS message "m1". If the applet identifier corresponds to its own identifier, the AppCardIet 21 applet continues processing. Otherwise, the applet ends the processing and the operating system of the security module 20 (SIM card) sends the event to the other logical processes 21 (or applets) hosted by said security module 20 (SIM card). The AppCardIet applet 21 performs the function, for which it is intended, on the Arg data read in the first short SMS message "m1", for example a data signature function, ie Signature (Arg, certificate). The AppCardIet 21 applet writes to the EFSMS file the result of said function executed. In the case of the data signing function, the AppCardIet 21 applet writes the signature on at least 8 bytes, generally 16 bytes, preceded by a header byte (0x01), in the form of a second message short SMS "m2" at the IdSIot location. In the access point PA 10, the SIM Trigger process 11, which was waiting for a response, reads said data entered by said second logical process 21 or AppCardIet. Said SIM Trigger 11 process reads said response from the AppCardIet applet 21 and sends said response to the software application AppSoftware 12. In the case of data signing, the software application
AppSoftware 12 a sollicité le processus SIM Trigger 11 pour obtenir ledit certificat en provenance de l'applet AppCardIet 21. La réponse de l'appletAppSoftware 12 requested the SIM Trigger 11 process to obtain the said certificate from the AppCardIet 21 applet. The response from the applet
AppCardIet 21 permet la gestion de l'application logicielle 12 mise en œuvre par ledit point d'accès PA 10. Il est également possible de définir un protocole de transport de données plus élaboré, basé sur l'utilisation de plusieurs messages SMS. Dans ce cas, une entête, indiquant le numéro et le nombre de messages SMS utilisés, sera introduite par le processus SIM Trigger 11. Dans une autre application particulière de signature d'un message électronique ou e-mail, les équipements concernés sont un ordinateur personnel (ou PC) comme point d'accès PA 10, hébergeant une application logicielle 12 telle qu'une messagerie MailApp, un terminal mobile MT 30 et un module de sécurité 20 (carte SIM) hébergeant une applet de signature de données, soit SigCardlet 21. Ledit terminal mobile MT 30 et ledit ordinateur personnel (ou point d'accès PA) 10 sont convenablement appairés au niveau d'un lien local 1 de communication de type radio courte distance Bluetooth. Par exemple, ledit terminal mobile MT 30 est équipé d'un port Bluetooth de type "Sériai Port Profile". Dans le point d'accès PA 10, l'application logicielle MailApp 12 appelle le premier processus SIM Trigger 11. Ladite application logicielle MailApp 12 émet un message sous la forme TriggerApplet(SigCardlet.ld,s, LINK_BluetoothSerialPort,CardletResponse), avec pour paramètres l'identifiant de l'applet SigCardlet 21 à déclencher sur la carte SIM 20 dudit terminal mobile MT 30, soit "SigCardIet.ld", ainsi que des données "s" à signer et le type de lien 1 de communication à utiliser pour l'envoi desdites données (communication BluetoothSerialPort). Les données "s" peuvent être un condensé du message électronique (ou mail) à signer. La variable "CardletResponse" contiendra la réponse de l'applet SigCardlet 21 soit la signature produite, après exécution de ladite fonction "TriggerApplet". La procédure, de type requête-réponse, se poursuit comme décrit précédemment en utilisant la mémoire SIM Buffer 22. L'échange des données entre les deux processus logiques (11 , 21 ) est réalisé par l'envoi de la requête par le processus SIM Trigger 11 suivi de la réponse de ladite applet SigCardlet 21. Ladite procédure se poursuit jusqu'à la lecture de la réponse en provenance de l'applet SigCardlet 21 par le processus SIM Trigger 11 et l'envoi de ladite réponse vers l'application logicielle MailApp 12. Dans ce cas de signature d'un message électronique, l'application logicielle MailApp 12 a sollicité le processus SIM Trigger 11 pour obtenir ladite signature des données en provenance de l'applet SigCardlet 21. La réponse de l'applet SigCardlet 21 permet la gestion de l'application logicielle MailApp 12 mise en œuvre par ledit point d'accès PA 10. De la même façon que précédemment, une fois la communication établie entre le terminal mobile MT 30 et le point d'accès PA 10 grâce audit lien local 1 de communication (communication radio courte distanceAppCardIet 21 allows the management of the software application 12 implemented by said access point PA 10. It is also possible to define a more elaborate data transport protocol, based on the use of several SMS messages. In this case, a header, indicating the number and the number of SMS messages used, will be introduced by the SIM Trigger 11 process. In another particular application for signing an electronic message or e-mail, the equipment concerned is a personal computer (or PC) as access point PA 10, hosting a software application 12 such as a MailApp messaging service, a terminal mobile MT 30 and a security module 20 (SIM card) hosting a data signing applet, ie SigCardlet 21. Said MT mobile terminal 30 and said personal computer (or access point PA) 10 are suitably paired at a local communication link 1 of the Bluetooth short distance radio type. For example, said MT 30 mobile terminal is equipped with a Bluetooth port of the "Serial Port Profile" type. In the access point PA 10, the MailApp 12 software application calls the first SIM Trigger 11 process. Said MailApp 12 software application sends a message in the form TriggerApplet (SigCardlet.ld, s, LINK_BluetoothSerialPort, CardletResponse), with parameters the identifier of the SigCardlet applet 21 to be triggered on the SIM card 20 of said MT mobile terminal 30, ie "SigCardIet.ld", as well as data "s" to be signed and the type of communication link 1 to be used for the 'sending of said data (BluetoothSerialPort communication). The data "s" can be a summary of the electronic message (or mail) to be signed. The "CardletResponse" variable will contain the response of the SigCardlet 21 applet, ie the signature produced, after execution of said "TriggerApplet" function. The procedure, of request-response type, continues as described above using the SIM Buffer 22 memory. The exchange of data between the two logical processes (11, 21) is carried out by sending the request by the SIM process Trigger 11 followed by the response of said SigCardlet applet 21. Said procedure continues until the response from the SigCardlet 21 applet is read by the SIM Trigger 11 process and the sending of said response to the software application MailApp 12. In this case of signature of an electronic message, the MailApp software application 12 requested the SIM Trigger 11 process to obtain said signature of the data coming from the SigCardlet applet 21. The response of the SigCardlet applet 21 allows the management of the MailApp 12 software application implemented by said access point PA 10. In the same way as previously, once the communication established between the mobile terminal MT 30 and the access point PA 10 thanks to said local communication link 1 (short distance radio communication
Bluetooth), la procédure se poursuit sans intervention de l'utilisateur dudit terminal mobile MT 30. L'invention permet à un processus logique 21 , hébergé sur un module standard de sécurité 20 d'un terminal mobile sans nécessité d'ajout de fonctions spécifiques, de dialoguer avec un point d'accès PA 10 externe grâce à un échange de données de type requête-réponse simplifié, en utilisant un lien local 1 de communication. L'implémentation du procédé se fait par l'intermédiaire d'une mémoire SIM Buffer 22 située sur ledit module de sécurité 20 (soit une carte SIM). Le dialogue entre les processus logiques 11 , 21 du module de sécurité 20 et du point d'accès PA 10 s'effectue préférentiellement, mais non exclusivement, par un script de commandes qui est écrit et lu dans ladite mémoire SIM Buffer 22. Le deuxième processus logique 21 répond au premier processus logique 11 pour gérer une application logicielle 12 mise en œuvre par ledit point d'accès PA 10. Les services pouvant être appliqués à ce procédé sont très nombreux et permettent aussi bien l'authentification, le contrôle d'accès, la délivrance de ticket, la sécurisation de données, la personnalisation de messages, etc.. Bluetooth), the procedure continues without intervention by the user of said MT mobile terminal 30. The invention allows a logical process 21, hosted on a standard security module 20 of a mobile terminal without the need to add specific functions , to dialogue with an external access point PA 10 by means of a simplified request-response type data exchange, using a local communication link 1. The implementation of the method is done via a SIM Buffer memory 22 located on said security module 20 (ie a SIM card). The dialogue between the logical processes 11, 21 of the security module 20 and of the access point PA 10 is preferably, but not exclusively, carried out by a command script which is written and read in said SIM Buffer memory 22. The second logical process 21 responds to the first logical process 11 to manage a software application 12 implemented by said access point PA 10. The services that can be applied to this process are very numerous and allow authentication, control as well access, ticket issuance, data security, personalization of messages, etc.

Claims

REVENDICATIONS
1. Procédé d'échange de données entre au moins un premier processus logique (11 ) hébergé sur une entité locale (10) et au moins un deuxième processus logique (21) hébergé sur un module de sécurité (20) d'un terminal mobile (30), caractérisé en ce que ledit procédé, faisant appel à l'utilisation d'au moins une mémoire de transit (22) située sur ledit module de sécurité (20), est apte à répondre audit premier processus logique (11) par ledit deuxième processus logique (21 ) par l'intermédiaire d'au moins un message dans ladite mémoire de transit (22) pour gérer au moins une application logicielle (12) mise en œuvre par ladite entité locale (10).1. Method for exchanging data between at least a first logical process (11) hosted on a local entity (10) and at least a second logical process (21) hosted on a security module (20) of a mobile terminal (30), characterized in that said method, using the use of at least one transit memory (22) located on said security module (20), is capable of responding to said first logical process (11) by said second logic process (21) via at least one message in said transit memory (22) for managing at least one software application (12) implemented by said local entity (10).
2. Procédé d'échange de données selon la revendication 1 , caractérisé en ce que ledit procédé inclut une étape d'établissement d'un lien (1 ) de communication entre les deux processus logiques (11 , 21).2. A data exchange method according to claim 1, characterized in that said method includes a step of establishing a communication link (1) between the two logical processes (11, 21).
3. Procédé d'échange de données selon l'une des revendications 1 ou 2, caractérisé en ce que l'échange de données entre les deux processus logiques (1 1 , 21 ) est réalisé par l'envoi d'une requête par ledit premier processus logique (1 1 ) suivi d'au moins une réponse dudit deuxième processus logique (21 ).3. Data exchange method according to one of claims 1 or 2, characterized in that the data exchange between the two logical processes (1 1, 21) is carried out by sending a request by said first logical process (1 1) followed by at least one response from said second logical process (21).
4. Procédé d'échange de données selon l'une quelconque des revendications 1 à 3, caractérisé en ce que les processus respectifs (1 1 , 21 ) de l'entité locale (10) et du module de sécurité (20) sont prévus pour surveiller l'apparition sur ladite mémoire de transit (22) d'au moins une donnée inscrite par l'autre processus (1 1 , 21 ) et lire ladite donnée une fois son apparition détectée.4. Data exchange method according to any one of claims 1 to 3, characterized in that the respective processes (1 1, 21) of the local entity (10) and the security module (20) are provided to monitor the appearance on said transit memory (22) of at least one data item entered by the other process (1 1, 21) and read said data once its appearance has been detected.
5. Procédé d'échange de données selon la revendication 4, caractérisé en ce que ledit premier processus logique (1 1 ) est prévu pour relire à répétition ladite mémoire de transit (22) afin de relever une donnée inscrite entre deux lectures consécutives.5. Data exchange method according to claim 4, characterized in that said first logic process (1 1) is provided for repeatedly reading said transit memory (22) in order to read a data item entered between two consecutive readings.
6. Procédé d'échange de données selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit premier processus logique (11 ) de l'entité locale (10) écrit et lit dans ladite mémoire de transit (22) du module de sécurité (20) via un mode de communication appartenant au groupe constitué des communications optique, radiocommunication de proximité et filaire. 6. Data exchange method according to any one of claims 1 to 5, characterized in that said first logical process (11) of the local entity (10) writes and reads in said memory of transit (22) of the security module (20) via a communication mode belonging to the group consisting of optical communications, proximity and wired communications.
7. Procédé d'échange de données selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite mémoire de transit (22) est constituée par au moins un fichier du module de sécurité (20) qui est également dédié à la mémorisation de textes de messagerie. 7. Data exchange method according to any one of claims 1 to 6, characterized in that said transit memory (22) consists of at least one file of the security module (20) which is also dedicated to the storage of messaging texts.
8. Procédé d'échange de données selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ledit module de sécurité (20) du terminal mobile (30) est, séparément ou en combinaison, une carte UICC, une carte SIM, une carte USIM, une carte WIM.8. Data exchange method according to any one of claims 1 to 7, characterized in that said security module (20) of the mobile terminal (30) is, separately or in combination, a UICC card, a SIM card , a USIM card, a WIM card.
9. Module de sécurité (20) d'un terminal mobile (30) hébergeant au moins un processus logique (21 ) et au moins une mémoire (22), caractérisée en ce que ledit processus logique (21 ) est conçu pour détecter et lire dans ladite mémoire (22) au moins une donnée inscrite par un premier processus logique (1 1 ) hébergé par une entité locale (10), momentanément présente à proximité d'au moins un terminal mobile (30) équipé dudit module de sécurité (20), et en ce que ledit processus logique (21 ) dudit module de sécurité (20) est également conçu pour inscrire dans ladite mémoire (22) des données destinées audit premier processus logique (1 1 ) hébergé par ladite entité locale (10). 9. Security module (20) of a mobile terminal (30) hosting at least one logical process (21) and at least one memory (22), characterized in that said logical process (21) is designed to detect and read in said memory (22) at least one data item entered by a first logical process (1 1) hosted by a local entity (10), momentarily present near at least one mobile terminal (30) equipped with said security module (20 ), and in that said logical process (21) of said security module (20) is also designed to write into said memory (22) data intended for said first logical process (11) hosted by said local entity (10).
10. Module de sécurité (20) selon la revendication 8, caractérisée en ce que ledit processus logique (21 ) hébergé sur ledit module de sécurité (20) est constitué par une ou plusieurs applications programmées en langage JAVA.10. Security module (20) according to claim 8, characterized in that said logical process (21) hosted on said security module (20) consists of one or more applications programmed in JAVA language.
1 1 . Dispositif local (10) communicant, du type incluant au moins un processeur et des moyens d'émission et de réception (13) de données pour communiquer avec un terminal mobile (30) momentanément proche dudit dispositif (10), caractérisé en ce que ledit dispositif (10) héberge au moins un premier processus logique (1 1 ) programmé pour utiliser au moins une mémoire (22) d'un module de sécurité (20) dudit terminal mobile (30) en y inscrivant au moins une donnée destinée à au moins un deuxième processus logique (21 ) hébergé sur ledit module de sécurité (20), ainsi que pour lire dans ladite mémoire (22) des données inscrites par ledit deuxième processus (21 ) du module de sécurité (20). 1 1. Communicating local device (10), of the type including at least one processor and data transmission and reception means (13) for communicating with a mobile terminal (30) momentarily close to said device (10), characterized in that said device (10) hosts at least a first logic process (1 1) programmed to use at least one memory (22) of a security module (20) of said mobile terminal (30) by registering therein at least one piece of data intended for at least one second logical process (21) hosted on said security module (20), as well as for reading from said memory (22) data written by said second process (21) of the security module ( 20).
12. Programme d'ordinateur apte à être mis en œuvre dans un module de sécurité (20) d'un terminal mobile (30) selon la revendication 9, caractérisé en ce qu'il comporte des instructions de code pour exécuter les étapes suivantes lors d'une exécution du programme : - commander au moins un deuxième processus logique (21 ) dudit module de sécurité (20) pour détecter et lire dans au moins une mémoire (22) au moins une donnée inscrite par au moins un premier processus logique (11) hébergé par un dispositif local communicant (10), - commander ledit processus logique (21 ) dudit module de sécurité (20) pour inscrire dans ladite mémoire (22) au moins une donnée destinée audit premier processus logique (1 1 ) hébergé par ledit dispositif communicant (10).12. Computer program able to be implemented in a security module (20) of a mobile terminal (30) according to claim 9, characterized in that it includes code instructions for executing the following steps during of a program execution: - controlling at least a second logic process (21) of said security module (20) to detect and read in at least one memory (22) at least one data item entered by at least one first logic process ( 11) hosted by a local communicating device (10), - controlling said logical process (21) of said security module (20) to write in said memory (22) at least one piece of data intended for said first logical process (1 1) hosted by said communicating device (10).
13. Programme d'ordinateur apte à être mis en œuvre dans un dispositif local communicant (10) selon la revendication 1 1 , caractérisé en ce qu'il comporte des instructions de code pour exécuter les étapes suivantes lors d'une exécution du programme : - commander au moins un premier processus logique (1 1 ) hébergé par ledit dispositif local communicant (10) pour inscrire dans au moins une mémoire (22) au moins une donnée destinée à au moins un deuxième processus logique (21 ) hébergé par un module de sécurité (20) d'un terminal mobile (30), - commander ledit premier processus logique (1 1 ) dudit dispositif local communicant (10) pour lire dans ladite mémoire (22) au moins une donnée inscrite par ledit deuxième processus logique (21 ) dudit module de sécurité (20) du terminal mobile (30). 13. Computer program able to be implemented in a local communicating device (10) according to claim 1 1, characterized in that it comprises code instructions for executing the following steps during an execution of the program: - order at least a first logical process (1 1) hosted by said local communicating device (10) to write in at least one memory (22) at least one piece of data intended for at least a second logical process (21) hosted by a module security (20) of a mobile terminal (30), - controlling said first logic process (1 1) of said local communicating device (10) to read from said memory (22) at least one data item entered by said second logic process ( 21) of said security module (20) of the mobile terminal (30).
PCT/FR2004/001559 2003-07-04 2004-06-22 Method enabling an access point to communicate by using a mobile terminal WO2005015930A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04767415A EP1649713A1 (en) 2003-07-04 2004-06-22 Method enabling an access point to communicate by using a mobile terminal

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0308290A FR2857207B1 (en) 2003-07-04 2003-07-04 METHOD FOR ACCESSING A POINT OF COMMUNICATION WITH AN APPLICATION LOCATED ON A SIM CARD
FR03/08290 2003-07-04

Publications (1)

Publication Number Publication Date
WO2005015930A1 true WO2005015930A1 (en) 2005-02-17

Family

ID=33522826

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/001559 WO2005015930A1 (en) 2003-07-04 2004-06-22 Method enabling an access point to communicate by using a mobile terminal

Country Status (3)

Country Link
EP (1) EP1649713A1 (en)
FR (1) FR2857207B1 (en)
WO (1) WO2005015930A1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8095179B2 (en) 2004-10-14 2012-01-10 Nokia Corporation Proxy smart card applications

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6078806A (en) * 1995-02-15 2000-06-20 Nokia Mobile Phones Limited Method for using applications in a mobile station, a mobile station, and a system for effecting payments
EP1143688A1 (en) * 2000-03-02 2001-10-10 Client Electronics GmbH Mobile services on the basis of a smart card
GB2370659A (en) * 2000-12-29 2002-07-03 Nokia Mobile Phones Ltd Method of controlling access to a data file held by a smart card
WO2003051080A1 (en) * 2001-12-12 2003-06-19 Schlumberger Systemes Applet download in a communication system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6078806A (en) * 1995-02-15 2000-06-20 Nokia Mobile Phones Limited Method for using applications in a mobile station, a mobile station, and a system for effecting payments
EP1143688A1 (en) * 2000-03-02 2001-10-10 Client Electronics GmbH Mobile services on the basis of a smart card
GB2370659A (en) * 2000-12-29 2002-07-03 Nokia Mobile Phones Ltd Method of controlling access to a data file held by a smart card
WO2003051080A1 (en) * 2001-12-12 2003-06-19 Schlumberger Systemes Applet download in a communication system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"DIGITAL CELLULAR TELECOMMUNICATIONS SYSTEM (PHASE 2+);SPECIFICATION OF THE SUBSCRIBER IDENTITY MODULE - MOBILE EQUIPMENT (SIM - ME) INTERFACE (GSM 11.11 VERSION 5.9.1)", ETS 300 977, XX, XX, October 1998 (1998-10-01), pages 1 - 127, XP000863809 *
See also references of EP1649713A1 *
THIRIET F: "WHY JAVA IS HOT FOR SMART CARDS", ID SYSTEMS, HELMERS PUBLISHING, US, vol. 6, no. 1, 1998, pages 32 - 34, XP000738223, ISSN: 1081-275X *

Also Published As

Publication number Publication date
EP1649713A1 (en) 2006-04-26
FR2857207A1 (en) 2005-01-07
FR2857207B1 (en) 2005-10-14

Similar Documents

Publication Publication Date Title
EP2203835B1 (en) Method and device for managing application data in an nfc system in response to the sending or receiving of data without contact
Monteiro et al. A secure NFC application for credit transfer among mobile phones
US7191234B2 (en) Deployment of smart card based applications via mobile terminals
EP0932317B1 (en) Method for crypted data transmission between a subscriber identification module and a mobile radio terminal
KR100814428B1 (en) Short message processing method and apparatus
EP0897250A1 (en) Improved process for charging a predetermined list of articles through a mobile terminal controlled by a subscriber interface module, order, and apparatus therefor
EP2306324A1 (en) Method, system and adapting device enabling a data exchange between a communicating object and a processing unit
CN101931945B (en) Download and installation method for realizing (U) SIM card application by using PC terminal
EP1304007A1 (en) Method for interactive exchange between a subscriber identification module co-operating with a terminal in a radiotelephone, and a local device
FR2913546A1 (en) METHOD OF EXCHANGING DATA BETWEEN A CONTACTLESS COMMUNICATION TERMINAL AND A MOBILE TELEPHONY TERMINAL.
CN101895844A (en) Method for application downloading and installation of communication intelligent card
EP1967023A1 (en) Processing proprietary data transmitted over a radio communication network to a mobile terminal under the control of a smart card
EP2254077A1 (en) Device for a conventional smart card allowing an electronic transaction via a network
EP1649713A1 (en) Method enabling an access point to communicate by using a mobile terminal
EP4285491A1 (en) Method and device for adapting a near-field communication
CN102547661B (en) Method and device for establishing communication between Android system and telecommunications smart card
FR2857193A1 (en) Data communication process for communication terminal e.g. portable telephone, involves closing communication channel after exchanging data by subscriber identity module application toolkit command parameters
EP2022016A1 (en) Method and system for loading value to a smartcard
EP3314921B1 (en) Authentication method for connecting a companion device when same is disconnected from a subscriber device
FR2800223A1 (en) USE OF SIM TOOLS BETWEEN A NETWORK AND A MOBILE TELEPHONE
WO2004064428A1 (en) Method, sim card and local device enabling said sim card to communicate locally
FR3119284A1 (en) Method and device for near field data transfer.
FR2933559A1 (en) METHOD FOR INSTALLING A MANAGEMENT APPLICATION AND METHOD FOR MANAGING APPLICATION DATA OF A SECURITY MODULE ASSOCIATED WITH A MOBILE TERMINAL
FR2798497A1 (en) SYSTEM AND METHOD FOR LOADING DATA IN A CHIP CARD THROUGH A TELECOMMUNICATION NETWORK USING MELS
FR3073304A1 (en) METHOD FOR LEGITIMATION OF A TRANSPORT TITLE CARRIED BY A MOBILE TERMINAL, COMPUTER PROGRAM AND MOBILE TERMINAL THEREFOR

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2004767415

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2004767415

Country of ref document: EP