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 ou 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 carte SIM ("Subscriber Identity Module", module d'identité abonné) ou une carte USIM (UMTS Subscriber Identity Module) ou une carte WIM (WAP Identity Module) ou tout autre carte d'identification d'abonné d'un terminal mobile.

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 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 gtobal pour les communications avec les mobiles) ou bien le réseau GPRS ("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 norme 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 Telecommunications Standards Institute, soit institut européen de normalisation des télécommunications), qui décrivent les fonctions SIM Toolkit 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 independant 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'apple 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 carte 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 oeuvre 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 oeuvre 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 oeuvre 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 oeuvre 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 requte 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 requte 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 requte. Puis, ledit premier processus logique va lire la réponse à la requte en provenance dudit deuxième processus logique.

L'échange de type requte-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 oeuvre 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 Telecommunications 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 requte, suivie d'une réponse, par l'intermédiaire d'un script de commandes.

L'exemple privilégié de mise en oeuvre de l'invention, tel qu'il est décrit ci-dessous, concerne le cas d'une implémentation de type SIM Toolkit 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 oeuvre 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 11, 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 11 (ou SIM Trigger) est sollicité par au moins une application logicielle 12, appelée AppSoftware.

La norme SIM Toolkit 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é AppCardlet, et permet la mise en oeuvre d'un service de proximité, tels que le chiffrement de données, la certification de données ou une authentification. Ladite applet AppCardlet

21 est compatible avec le déclenchement par un événement extérieur, ici pour tre déclenchée par ledit processus SIM Trigger 11.

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 oeuvre 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 oeuvre 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 oeuvre 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 11,21 peuvent tre situés, tous les deux, sur un mme terminal mobile MT 30, lorsque que ledit terminal est bi- processeur, 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 AppCardlet 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 AppCardlet, 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 AppCardlet 21 et le stockage du résultat produit par ladite applet AppCardlet 21.

Selon l'invention, ledit point d'accès PA 10 entre en communication avec ladite applet AppCardlet 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 requte-réponse entre les deux processus SIM Trigger 11 et AppCardlet 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 oeuvre 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. Id, Arg, LI N K_l RDA, CardletResponse), avec pour paramètres l'identifiant de l'apple AppCardlet 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"CardtetResponse"contiendra les données de

réponse de l'apple AppCardlet 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'entte (0x01) suivi de l'identifiant de l'applet AppCardlet 21 à déclencher, ainsi que des données <BR> <BR> (ou arguments) "Arg", accompagnées si besoin par des octets de bourrage<BR> (OxFF).

L'échange de données entre les deux processus logiques 11,21 est réalisé par l'envoi d'une requte par ledit processus SIM Trigger 11, ledit message court"m1", suivi d'une réponse de ladite applet AppCardlet 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 logiques 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 SMS (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"IdSlot" 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 EFSMS via ledit lien local 1 de communication, en utilisant une commande AT+CMGW.

La commande AT+CMGW permet d'accéder au fichier des messages 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 IdSlot du fichier EFSMS en vérifiant si la valeur du premier octet d'entte 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 AppCardlet 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'apple AppCardlet 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 AppCardlet 21. Cette lecture se fait par la commande AT+CMGR envoyée par ledit processus SIM Trigger 11.

II 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"EVENTUNFORMATEDSMSPPUPD", qui correspond à la mise à jour du fichier EFSMS par une application tierce.

Par conséquent, l'applet AppCardlet 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 AppCardlet 21 lit les données (ou arguments) stockées dans le premier message court SMS"m1". Si l'identifiant de l'apple correspond à son propre identifant, l'apple AppCardlet 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 apples) hébergées par ledit module de sécurité 20 (carte SIM).

L'apple AppCardlet 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 AppCardlet 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'apple AppCardlet 21 écrit la signature sur au moins 8 octets, en général 16 octets, précédée d'un octet d'entte (0x01), sous la forme d'un deuxième message court SMS"m2"à l'emplacement IdSlot.

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 AppCardlet. Ledit processus SIM Trigger 11 lit ladite réponse en provenance de l'apple AppCardlet 21 et envoie ladite réponse vers l'application logicielle AppSoftware 12.

Dans le cas de la signature de données, l'application logicielle AppSoftware 12 a sollicité le processus SIM Trigger 11 pour obtenir ledit certificat en provenance de l'apple AppCardlet 21. La réponse de l'apple AppCardlet 21 permet la gestion de l'application logicielle 12 mise en oeuvre 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 entte, 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"Serial 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, LlNK_BluetoothSerialPort, CardletResponse), avec pour paramètres l'identifiant de l'apple SigCardlet 21 à déclencher sur la carte SIM 20 dudit terminal mobile MT 30, soit"SigCardlet. 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'apple SigCardlet 21 soit la signature produite, après exécution de ladite fonction"TriggerApplet".

La procédure, de type requte-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 requte 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'apple 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'apple SigCardlet 21. La réponse de l'apple SigCardlet 21 permet la gestion de l'application logicielle MaiiApp 12 mise en oeuvre par ledit point d'accès PA 10.

De la mme 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 distance 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 requte-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 oeuvre 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...