En d'autres termes, l'invention concerne la communication entre la carte SIM d'un téléphone mobile et une entité placée à proximité de ce téléphone, entité du type incluant des moyens de traitement et de mémorisation de données.

L'entité communicante est par exemple un ordinateur personnel, notamment dans le cas où il s'agit d'échanger des messages de type email entre le téléphone et l'ordinateur.

L'entité communicante peut également tre un distributeur de produits, par exemple des boissons, lorsque la carte SIM inclut une application de porte-monnaie électronique pour l'achat de tels produits.

L'entité communicante peut également tre une borne internet publique.

La carte SIM (Suscribe Identity Module) est l'élément permettant d'apporter la sécurité au réseau de téléphone mobile. Elle permet entre autre l'authentification de l'abonné sur le réseau, le chiffrement des échanges (vocaux ou données) ainsi que la personnalisation du terminal mobile. Elle permet aussi d'autres services à valeur ajoutée notamment lorsque ces services implémentés sous forme d'apples JAVA utilisent la norme SIM Toolkit présente maintenant sur l'ensemble des cartes SIM.

Dans leur état actuel, les cartes SIM peuvent communiquer avec un serveur applicatif distant par SMS (Short Message Service), par USSD (Unstructured Supplementary Service Data) ou par appel vocal. Dans de nombreuses situations, il est souhaitable de faire communiquer les applets (processus logique de carte SIM, typiquement programmé en langage JAVA) SIM sur des liens locaux avec des points d'accès de proximité (PC, Bornes publiques, distributeurs, terminaux de paiement). Le lien local souhaité peut tre par exemple de type IrDa (infrarouge), Bluetooth ou liaison radio basse fréquence ou filaire.

Les normes GSM 11.14 et ETSI 31.111 qui décrivent les fonctions SIM Toolkit (principalement les fonctions qui permettent à la carte SIM de prendre la main sur le téléphone mobile) pour la carte SIM (réseaux deuxième génération) et pour la carte USIM (réseaux troisième génération) apportent 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 d'ouvrir un canal de communication sur un lien local à préciser, d'envoyer/recevoir des données sur ce lien, de fermer te iien, etc.

Cependant la définition des couches « transport » des liens locaux IrDa (infra-rouge) et Bluetooth 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 fastidieuse à développer de nos jours.

Dans le document FR 99 13 645, il a été proposé un mode de communication entre un équipement tiers et une carte SIM portée par un téléphone mobile, dans lequel mode de communication, la carte SIM pilote l'équipement tiers via un modem.

Pour cela, des moyens de conversion sont utilisés entre la carte SIM et son téléphone porteur qui transforme un premier dialogue entre carte SIM et téléphone en un second dialogue entre téléphone et équipement tiers.

De cette façon, la carte SIM pilote l'équipement tiers via le téléphone. Ce mode de communication reste d'une complexité d'implémentation élevée, notamment lorsque l'équipement tiers vise à fournir un service de proximité.

Le but de l'invention est de permettre à une carte SIM, notamment à une carte SIM actuelle de type standard, d'exploiter des liens locaux de manière bidirectionnelle et ceci dans le but plus général de développer des services de proximité.

Le résultat technique obtenu tel qu'implémenté préférentiellement dans la carte SIM et dans le point d'accès, vise à offrir aux applets

(applications) SIM Toolkit, et aux points d'accès, des services de communication locale sur des liens de type IrDa, Bluetooth ou câble série.

Ce but est atteint selon l'invention grâce à un procédé d'échange de données bidirectionnel entre un processus logique (11) hébergé sur une carte SIM (10) et un processus logique (21) hébergé sur une entité locale, caractérisé en ce qu'il fait appel à l'utilisation d'une mémoire de transit (13) portée par la carte SIM, les deux processus utilisant cette mémoire en alternance pour chacun y inscrire des données, que l'autre processus vient ensuite lire.

On propose également selon l'invention une carte SIM hébergeant un processus logique et une mémoire, caractérisée en ce que le processus logique est conçu pour inscrire dans cette mémoire des données de communication destinées à un processus appartenant à une entité locale momentanément présente à proximité d'un téléphone équipé de la carte SIM, et en ce que le processus logique de la carte SIM est également conçu pour détecter et lire dans cette mémoire des données inscrites par le processus de cette entité locale.

On propose également selon l'invention un dispositif local communiquant, du type incluant un processeur et des moyens d'émission/réception de données pour communiquer avec un téléphone mobile momentanément proche de ce dispositif, caractérisé en ce qu'il héberge un processus logique programmé pour utiliser la mémoire d'une carte SIM d'un téléphone mobile momentanément proche, en y inscrivant des données destinées à un processus logique de la carte SIM, ainsi que pour lire dans cette mémoire des données inscrites par ce mme processus de carte SIM.

D'autres caractéristiques, buts et avantages de l'invention apparaîtront à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur lesquelles : - la figure 1 représente un ensemble téléphone mobile, carte SIM et borne locale selon l'invention ; - la figure 2 est un organigramme représentatif d'un procédé d'échange selon l'invention.

L'exemple privilégié de mise en oeuvre de l'invention, tel qu'il sera décrit maintenant, concerne le cas d'une implémentation de type Sim Toolkit sur la carte SIM 10 d'un téléphone GSM avec utilisation d'un lien IrDa (lien infrarouge connu en soi).

Les éléments en jeu sont ici un point d'accès 20 noté également PA pour PointAccess, un terminal mobile 30 noté ME et la carte SIM 10 notée simplement SIM.

Une application de type SIM toolkit, et qui met en oeuvre un service de proximité, est ici cliente d'un processus iogique 11 hébergé sur ta carte SIM 10, ce processus de carte SIM étant ici dénommé AppletClient.

La communication entre les processus s'effectue par l'intermédiaire d'un script de commandes.

Les commandes échangées dans le script doivent tre connues du point d'accès 20 (ici une borne locale), et connues d'une application d'interface 12 installée sur la carte SIM, application appelée ci-après SimAccess.

Le processus logique qui se trouve sur la borne locale (point d'accès PA), est ci-après dénommé PointAccess et est référencé 21 sur la figure 1.

On fait également appel à un module 22 ayant la forme d'une API (Application Program Interface) de communication (IrDa, Bluetooth ou série), et qui est localisé dans le point d'accès 20.

Comme on le décrira par la suite, le script de commandes est échangé dans un buffer (mémoire tampon) de communication 13 qui est situé sur la carte SIM 10. Ce buffer, appelée ci-après SIMbuffer (ici une mémoire de transit) est utilisé pour le processus logique SIMAccess 12 de la carte SIM pour la communication localisée.

La procédure d'utilisation du buffer SIMBuffer 13 par le processus PointAccess 21 localisé sur le point d'accès 20 est la suivante.

L'utilisation du buffer SIMBuffer 13 par le processus PointAccess 21 s'effectue de préférence par commandes AT telles que spécifiées dans les normes ETSI GSM 07.05 et 07.07.

Le buffer SIMbuffer 13 peut tre soit un fichier propriétaire de la carte SIM, soit un fichier EFsMS tel que spécifié dans la norme ETSI GSM 11.11.

Dans le cas d'un fichier propriétaire, le buffer SIMBuffer 13 est par exemple lu, effacé et écrit par la commande AT+CRSM. Cette commande vise à la base à inscrire des données sur une carte à puces, et par exemple une carte SIM répondant à la norme ISO 7816-3. Cette inscription est effectuée ici via le port IrDa, Bluetooth ou série d'un téléphone mobile.

L'inconvénient de la commande AT+CRSM est que celle-ci n'est pas implémentée sur tous les téléphones mobiles.

Dans le cas de l'utilisation d'un fichier SMS en tant que buffer, le buffer SiMbuffer est préférentiellement lu par la commande AT+CMGR, et par ailleurs effacé et écrit par la commande AT+CMGW. La commande AT+CMGW vise initialement à accéder au fichier des SMS d'une carte SIM via un port IrDa, Bluetooth ou série d'un téléphone mobile, par exemple par un PC pour utiliser le téléphone en tant que passerelle avec le réseau de téléphone mobile. L'avantage de cette variante est qu'elle fonctionne sur tous les téléphones mobiles.

Dans le présent exemple (fig. 2), la cinématique de communication de type requte/réponse entre les processus PointAccess 21 et SimAccess 11 est celle énumérée ci-après.

On entendra ici par lien local un lien de communication établi entre deux entités 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.

Le lien local prend typiquement place sur une distance d'un ou de quelques mètres, voire sur quelques dizaines de mètres.

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.

En d'autres termes, chaque processus a, pendant la durée de vie d'un lien, la possibilité de la mise en oeuvre d'échanges avec l'autre processus.

Sur la figure 2, on a représenté par des tirets en pointillés les éléments précédemment mentionnés, et en outre l'utilisateur physique du téléphone, sous la référence 40.

A l'étape 1, l'utilisateur active la liaisori sans fil (IrDa) de son terminal positionne son terminal mobile devant le port IrDa du point d'accès PA 20.

A l'étape 2, Le logiciel PointAccess 21, iocaiisé sur le point d'accès PA, détecte la présence du terminal mobile, établit une connexion sans fil (IrDa) avec le terminal mobile 30 et commence à lire en boucle le buffer de communication SIMBuffer 13.

A l'étape 3, l'utilisateur 40 sélectionne à l'aide de son terminal mobile 30 une commande dans un menu (SélectionMenultem) pour ouvrir une sesson avec le Point d'Accès local 20 ».

A l'étape 4, l'apple SIM Toolkit AppletClient 11 envoie une requte au processus logique PointAccess 21 : elle fait appel à l'API SimAccess 12 en appelant une fonction d'envoi de requte : SIMAccess. Request (commandid, Params), Commandld étant l'identifiant de la commande adressée au point d'accès PointAccess accompagnée de ses paramètres Params.

A l'étape 5, suite à cette demande, le processus logique SimAccess 12 écrit dans le buffer SIMBuffer 13 la commande texte « REQ » suivie de la valeur de la variable Commandid et de ses paramètres Params.) Le logiciel SimAccess 12 se place dans un état de lecture périodique du buffer SIMBuffer 13 et attend une réponse de PointAccess 21.

A l'étape 6, le processus PointAccess 21 qui lit en permanence lebuffer SIMBuffer 13 lit cette dernière commande 'REQ'+Commandld+Params et détecte ainsi la demande de requte d'une application.

A l'étape 7, le processus logique PointAccess 21 répond à l'apple SimAccess 11 en écrivant dans le buffer 13, après effacement de ce dernier, soit :

a) la réponse'RSP ERROR (Errorld) en cas d'imcompréhension de la commande par le point d'accès 20 ou d'erreur de fonctionnement. Errorld représente l'identification de l'erreur. b) la réponse'RSP'+Commandld+RspParams, RspParams représentant les paramètres de réponses dépendant de la commande en cas de succès.

A l'étape 8, le logiciel SIMAccess 12 lit alors la réponse 'RSP'+Commandld+RspParams A l'étape 9, ie logiciel SiMAccess 12 répond alors à i'appiet cliente AppletClient 11 en lui renvoyant les paramètres de réponse du processus PointAccess 21 RspParams ou l'identifiant de l'erreur en cas d'erreur.

La borne 20 hébergeant le processus PointAccess et l'application SimAccess 12 effectuent tour à tour une lecture et une écriture de commandes dans le buffer 13, qui est donc utilisé à la façon d'une boîte aux lettres commune par laquelle carte SIM 10 et borne 20 se répliquent tour à tour.

Bien que l'on ait décrit ici un mode de réalisation spécifique, dans le cadre duquel le téléphone mobile déclenche lui-mme l'établissement d'un lien de communication, une autre variante est également prévue, où la borne locale remplit ce rôle.

Ainsi, dans le cadre de l'invention, on notera la variante dans laquelle le lancement d'une application SIM Toolkit s'effectue dans la carte à l'initiative de la borne locale et non plus à l'initiative de téléphone mobile.

On décrira maintenant une application plus spécifique, consistant en un envoi sécurisé d'une donnée D à un point d'accès.

Une première étape consiste pour l'utilisateur à positionner son terminal mobile devant le port IrDa du point d'accès PA.

Dans une seconde étape, l'apple SIM Toolkit AppletClient 11, déclenchée par la sélection d'un menu par l'utilisateur 40, désire ouvrir une session avec le processus PointAccess 21 : elle fait appel à l'API SimAccess 12 en appelant une fonction d'ouverture de session SimAccess. Request (Open. LocalSession, Serviceld). Serviceld est, dans

cette requte, l'identifiant alphanumérique de l'application cliente AppletClient.

Ensuite, SimAccess écrit dans le buffer SimBuffer la commande texte'REQ_OpenLocalSession (Serviceld)'.

Puis le processus PointAccess 21, qui lit en permanence le buffer SIMBuffer 13 lit cette dernière commande'REQ_OpenLocalSession'et détecte ainsi la demande de connexion locale d'une application.

Ensuite, le processus PointAccess 21 répond à l'applet AppletClient 11 via SimAccess 12 en écrivant dans ie buffer 13, après effacement de ce dernier, la réponse'RSP'OpenLocaISession (ack)', La variable boolénne « ack » peut prendre les valeurs suivantes : -'TRUE' : demande de connexion acceptée -'FALSE': demande de connexion refusée Dans une étape suivante, si la demande de connexion est refusée par PointAccess 21, alors le processus SimAccess 12 en avertit l'application cliente AppletClient 11 qui avertit l'utilisateur 40 et termine l'opération. Dans le cas contraire, le processus SimAccess 12 informe l'application cliente 11 du succès de la demande de connexion.

Ensuite, l'apple cliente AppletClient 11 demande une authentification du processus PointAccess 21 en utilisant la commande 'ExternalAuthentification (NumKeyl, alea)'.

Ce paramètre NumKey1 est un numéro de clé utilisé pour le calcul du certificat.

Le paramètre Alea est un aléa permettant l'authentification active du point d'accès 20.

Par une autre étape, le processus PointAccess 21 répond à l'applet.

AppletClient 11 via SimAccess 12 en écrivant dans le buffer SimBuffer 13, après effacement de ce dernier, la réponse RSP ExternalAuthentification (certificat) '.

La variable certificat contient le certificat d'authentification produit par le point d'accès 20.

Dans une étape suivante, l'apple cliente Appletclient 11 calcule le certificat d'authentification avec la clé NumKeyl et vérifie l'égalité entre ce dernier certificat et le certificat retourné par PointAccess.

Puis l'apple cliente AppletClient 11 peut alors envoyer son information sécurisée D.

Dans un premier temps, elle peut optionnellement demander un PIN code à l'utilisateur de façon à protéger la donnée D. Ensuite, elle demande un aléa à PointAccess, ce dernier permettant de produire une signature de la donnée en uti', isant, a commande'AskRandom ()' Dans une étape suivante, le logiciel PointAccess répond à l'apple AppletClient 11 via SimAccess 12 en écrivant dans le buffer SIMBuffer 13, après effacement de ce dernier, la réponse'RSP_AskRandom (alea)'.

Ensuite, l'apple cliente Appletclient 11 calcule une signature du bloc de donnée [d, alea] avec la clé NumKey2 Puis elle envoie la donnée D au processus PointAccess 21 en utilisant la commande'SendSignedData (D, NumKey2, signature)'.

Le paramètre D est la donnée à transférer.

Le paramètre NumKey2 est le numéro de la clé utilisée pour le calcul de la signature.

Le paramètre signature est la signature produite par l'apple cliente AppletClient 11.

Puis le processus PointAccess 21 qui lit en permanence le buffer SIMBuffer 13 lit cette dernière commande'REQ SendSignedData (d, <BR> <BR> NumKey2, signature) 'et détecte ainsi la demande d'envoi d'une donnée sécurisée.

Puis le processus PointAccess 21 répond à l'apple AppletClient 11 via SimAccess 12 en écrivant dans le buffer SIMBuffer 13, après effacement de ce dernier, la réponse'RSP SendSignedData (ack) '.

La variable booléenne ack a pour valeur l'acquittement positif (TRUE) ou négatif (FALSE).

Enfin, l'apple cliente AppletClient 11 affiche un message à l'utilisateur lui indiquant le bon ou mauvais déroulement de l'opération.

Dans l'architecture décrite ici, le point d'accès peut tre considéré comme serveur et préférentiellement attend en permanence une demande de communication de la part d'un logiciel localisé sur la carte SIM.

L'invention permet à un processus localisé sur une carte SIM standard (sans nécessité d'ajout de fonctions spécifiques par l'encarteur) de dialoguer de manière bidirectionnelle avec un point d'accès externe en utilisant un lien local.

L'implémentation du procédé se fait par l'intermédiaire d'un buffer de communication situé sur ia carte SiM et accessible aussi bien par ie point d'accès que par le logiciel localisé sur la SIM.

Le dialogue entre le logiciel localisé sur la carte SIM et le point d'accès s'effectue préférentiellement, mais non exclusivement, par un script de commandes qui est écrit et lu dans le buffer de communication, aussi bien par l'application de la carte SIM que par l'application de la borne d'échange.