Procédé de gestion de l'interface utilisateur d'un terminal mobile associé à un module de sécurité et terminal mobile associé

La présente invention se rapporte au domaine des télécommunications, et plus particulièrement à celui de la gestion des applications hébergées sur un élément sécurisé d'un terminal mobile.

La plupart des terminaux mobiles existants permettent, non seulement d'établir des communications téléphoniques, mais également d'exécuter un certain nombre d'applications téléchargées dans un module sécurisé lié au terminal. Ce module de sécurité peut être un module mémoire du terminal ou un support amovible (par exemple une carte à puce d'abonné) inséré dans le terminal.

Parmi les applications présentes sur le module de sécurité, un certain nombre d'entre elles peuvent être des applications dites "sans contact". Ces applications sont exécutées à la demande d'un équipement extérieur, appelé "borne sans contact". Un module spécifique, dit "module sans contact", installé sur le terminal mobile, permet le dialogue entre le module de sécurité et la "borne sans contact".

Le téléchargement de telles applications peut être effectué, via le terminal mobile, entre un serveur d'un fournisseur de services et le module sécurisé. Le fonctionnement de telles applications ne nécessitent généralement pas d'utiliser les fonctions du terminal mobile. Cependant, des fonctions d'interface homme machine (en abrégé "IHM") du terminal mobile peuvent être sollicitées en parallèle de l'exécution d'une application installée sur le module de sécurité. Ceci nécessite l'installation sur le terminal mobile, par le même fournisseur de services, d'un module logiciel (appelé "programme d'interface" ou "application d'interface") associé à l'application.

Ce programme permet par exemple l'exécution d'une sonnerie ou l'affichage d'un fond d'écran particulier lorsque l'application associée est activée.

Les paramètres (type de sonnerie par exemple) utilisés par ce programme sont déterminés par le fournisseur de service.

L'utilisateur ne peut pas aisément modifier ces paramètres. Ainsi, il ne peut pas configurer son terminal pour avoir, par exemple, la même sonnerie pour toutes les applications de transport. Pour obtenir cette fonctionnalité, il doit contacter chaque fournisseur de services ayant installé une application de transport sur le module de sécurité lié à son terminal mobile et le programme d'interface associé, en lui demandant de télécharger un nouveau programme d'interface contenant les paramètres modifiés.

La présente invention améliore la situation de l'état de l'art. A cet effet, l'invention vise un procédé de gestion de l'interface utilisateur d'un terminal mobile associé à un module de sécurité contenant au moins une application. Selon l'invention, ce procédé comprend : une étape préalable d'enregistrement dans le terminal mobile d'au moins un paramètre d'interface en association avec un identifiant d'application et pour au moins une fonction d'interface utilisateur; - lors de l'installation d'une application d'interface associée à une application installée sur le module de sécurité, o une étape de réception d'un identifiant de ladite application; o en fonction dudit identifiant d'application reçu, une étape d'association, d'un lien vers ledit au moins un paramètre enregistré en association avec ledit l'identifiant et pour la fonction d'interface utilisateur correspondante; o une étape de sauvegarde dans une zone mémoire accessible par l'application d'interface de ladite association.

Ainsi, lors de l'appel d'une fonction d'interface utilisateur par une application d'interface associée à une application du module de sécurité, les paramètres d'interface utilisés pour cette fonction d'interface utilisateur correspondent au choix de l'utilisateur du terminal mobile sans que celui-ci fasse appel au fournisseur de service.

Selon une caractéristique de réalisation, l'identifiant d'application est un identifiant relatif au type d'application. Cette caractéristique permet à l'utilisateur de reconnaître rapidement le type de l'application pour laquelle une transaction est

effectuée. Par exemple, il peut configurer son terminal mobile pour entendre une sonnerie brève pour les applications de type transport et une sonnerie plus longue pour les applications de type paiement.

Selon une autre caractéristique de l'invention, l'identifiant d'application est le nom de l'application. Ainsi, l'utilisateur peut choisir des paramètres d'interface adaptés à l'application. Par exemple, il peut choisir un fond d'écran par application, pour l'affichage des messages de fin de transaction. L'affichage du fond d'écran lui permet ainsi d'être informé rapidement de l'application utilisée.

Dans un mode de réalisation particulier, l'identifiant d'application est publié dans une zone mémoire du terminal mobile accessible en écriture par l'application d'interface et l'étape de réception est une étape de lecture de ladite zone mémoire.

Selon un autre mode de réalisation, le procédé comporte en outre, lors de l'installation d'une application d'interface, une étape de détermination de l'application d'interface à installer. Dans un mode de réalisation particulier, l'étape de détermination comprend une étape de synchronisation du terminal mobile avec le module de sécurité associé.

Avantageusement, l'étape de synchronisation comprend une étape de comparaison d'informations relatives à au moins une application installée sur le module de sécurité avec des informations relatives à au moins une application d'interface du terminal mobile. Cette comparaison permet au terminal mobile de déterminer les applications d'interfaces, associées aux applications installées sur le module de sécurité, qui ne sont pas installées dans le terminal mobile et qui doivent donc être téléchargées

Avantageusement, l'étape de synchronisation comprend une étape de comparaison d'une première valeur représentative des applications installées sur le module de sécurité et stockée dans le module de sécurité avec une deuxième valeur représentative des applications installées sur le module de sécurité stockée dans le terminal mobile. Cette comparaison permet au terminal mobile de déterminer rapidement s'il dispose de l'ensemble des applications d'interfaces associées aux applications installées sur le module de sécurité.

L'invention concerne également un terminal mobile associé à un module de sécurité contenant au moins une application comprenant :

- des moyens d'enregistrement d'au moins un paramètre d'interface en association avec un identifiant d'application pour au moins une fonction d'interface utilisateur; des moyens de réception d'au moins un identifiant de ladite application; des moyens d'association, en fonction dudit identifiant d'application reçu, d'un lien vers ledit au moins un paramètre d'interface et pour la fonction d'interface utilisateur correspondante; - des moyens de sauvegarde dans une zone mémoire accessible par l'application d'interface de ladite association.

L'invention concerne enfin un programme d'ordinateur comportant des instructions pour : enregistrer dans le terminal mobile au moins un paramètre d'interface en association avec un identifiant d'application, et pour au moins une fonction d'interface utilisateur, lors de l'installation d'une application d'interface associée à une application installée sur le module de sécurité :

- recevoir un identifiant de ladite application; - associer, en fonction dudit identifiant d'application reçu, un lien vers ledit au moins un paramètre d'interface enregistré en association avec ledit identifiant, et pour la fonction d'interface utilisateur correspondante;

- sauvegarder dans une zone mémoire accessible par l'application d'interface de ladite association; lorsqu'il est exécuté par un terminal mobile.

D'autre particularités et avantages de la présente invention apparaitront dans la description suivante d'un mode de réalisation donné à titre d'exemple non limitatif, en référence aux dessins annexés dans lesquels : - la figure 1 est un schéma général présentant le contexte de l'invention,

la figure 2 est un organigramme illustrant les différentes étapes du procédé de l'invention, la figure 3 est un schéma bloc représentant un terminal mobile selon l'invention, - la figure 4 est un schéma illustrant le contenu d'une première zone mémoire particulière du module de sécurité selon un mode de réalisation, la figure 5 est un schéma illustrant le contenu d'une deuxième zone mémoire particulière du module de sécurité selon un mode de réalisation.

En référence à la figure 1, un utilisateur dispose d'un terminal mobile 100, par exemple un téléphone mobile ou un PDA (pour "Personal Digital Assistant" en anglais).

Ce terminal mobile 100 comporte un module de communication sans contact 10 permettant un dialogue entre le terminal 100 et un équipement 200 appelé par la suite "borne sans contact". Le module sans contact 10 est par exemple un module compatible NFC (pour "Near Field Communication" en anglais).

Le terminal mobile 100 comporte également un module sécurisé 20 qui est par exemple une carte à mémoire amovible compatible avec les spécifications de GlobalPlatform (GlobalPlatform Card Spécification - version 2.2 de mars 2006). A titre d'alternative, ce module peut être une zone mémoire sécurisée du terminal mobile ou un support amovible d'un autre type (par exemple une carte d'abonné de type SIM ou UICC (pour "Universal Integrated Circuit Card") ou une carte à mémoire hébergeant un élément sécurisé (SD card, Embeded Secure contrôler ...)). Une ou plusieurs applications ont été stockées dans la mémoire du module de sécurité 20. Parmi ces applications, une ou plusieurs sont des applications qui peuvent être utilisées en mode sans contact et fonctionnent en utilisant le module sans contact 10.

Une telle application est, par exemple, une application de transport. Cette application est alors utilisée à chaque fois que le porteur du mobile présente son mobile devant une borne 200 située à l'entrée du moyen de transport.

La borne sans contact 200 émet un champ magnétique. Lorsque l'utilisateur du mobile se présente devant la borne, son terminal mobile entre dans le champ magnétique émis par la borne 200. A l'initiative de la borne sans contact, un dialogue entre l'application stockée sur le module 20 et la borne sans contact 200 permet de réaliser une transaction. Ce dialogue entre le module sécurisé 20 et la borne sans contact 200 est effectué via le module sans contact 10. L'échange des messages entre le module sans contact et le module sécurisé s'effectue alors de façon classique, par exemple en utilisant le protocole SWP pour "Single Wire Protocol" ou l'interface S ² C pour "Sigln-SigOut-Connection". En fonction de l'application sélectionnée, un certain nombre de messages vont ensuite être échangés entre l'application et la borne sans contact. Le terminal mobile comporte également un module de communication 30 permettant une communication, via un réseau de communication R, avec des serveurs distants, par exemple avec une plateforme de services SP ou des serveurs SPl, SP2, SP3 de fournisseurs de services. Cette communication est par exemple une communication "OTA" (pour "Over The Air"), c'est-à-dire une communication sans fil classique. A titre d'alternative, le terminal mobile est relié au réseau R pour une ligne téléphonique filaire.

Le procédé conforme à l'invention va maintenant être décrit, en référence à la figure 2.

Lors d'une étape préalable d'enregistrement El, l'utilisateur enregistre dans le terminal mobile au moins un paramètre relatif à l'interface utilisateur en association avec un identifiant d'application pour au moins une fonction d'interface utilisateur (fonction IHM). Par exemple, pour indiquer qu'il souhaite associer une sonnerie déterminée (sonnerie A) aux applications de transport, il enregistre dans le terminal mobile un paramètre relatif à cette sonnerie "A", par exemple l'adresse de cette

fonction, en association avec un identifiant d'application de transport et la fonction d'interface utilisateur "sonnerie".

Ultérieurement, suite à l'installation d'une nouvelle application APl, référencée en figure 3, dans le module de sécurité 20 et d'une application d'interface associée à cette application APl dans le terminal mobile, le terminal mobile reçoit, lors d'une étape E21, un identifiant de l'application APl, par exemple, un identifiant indiquant que l'application APl est une application de transport.

Lors de l'étape E23 suivante, le terminal mobile associe, en fonction de l'identifiant reçu à l'étape E21, un lien vers le paramètre enregistré lors de l'étape préalable d'enregistrement El. Ce lien est, par exemple, l'adresse de la sonnerie à utiliser pour les applications de transport.

Ce lien est ensuite enregistré, lors d'une étape E25, dans une zone mémoire du terminal mobile, accessible par l'application d'interface associée à l'application APl.

Ainsi, lorsqu'une transaction est effectuée par l'application APl, l'application d'interface associée lancée en fin de transaction exécute la sonnerie déterminée par le lien enregistré.

Un mode de réalisation détaillé du terminal selon l'invention va maintenant être décrit.

En référence à la figure 3, le terminal mobile 100 comporte également un microprocesseur 12, une mémoire réinscriptible 14 (EPROM ou EEPROM), une zone mémoire 15 (ROM ou Eprom), une zone mémoire vive 16 ainsi qu'un écran 18 et un clavier 19.

Le microprocesseur 12 exécute un programme, enregistré dans une zone de la mémoire 14 ou 15, mettant en œuvre les étapes du procédé de l'invention. Le module de sécurité 20 comporte un microprocesseur 22, une mémoire réinscriptible 24 (EPROM ou EEPROM), une zone mémoire 25 (ROM ou Eprom), et une zone mémoire vive 26

Une application notée IP installée dans la mémoire 14 ou 15 du terminal mobile, permet de gérer les différentes applications présentes sur le module de sécurité 20 ainsi que leurs interfaces respectives. Par exemple, cette application

permet à un utilisateur du terminal mobile d'obtenir facilement la liste des services "sans contact" auxquels il a souscrit, ainsi que les paramètres associés. Cette application permet également d'obtenir la liste de l'ensemble des services auxquels l'utilisateur peut souscrire. De plus, elle offre une interface simplifiée à l'utilisateur lors de la souscription à un nouveau service.

Cette application IP est lancée à chaque fois que l'utilisateur met en marche son terminal mobile et/ou à la demande de l'utilisateur.

Cette application IP fonctionne en association avec une application IC installée dans la mémoire 24 ou 25 du module de sécurité 20. L'application IC gère et stocke dans une zone ZC de la mémoire 24 du module de sécurité la liste LC des applications installées sur le module de sécurité ainsi que des paramètres associés à chacune des applications.

Lorsqu'un utilisateur du terminal mobile demande, à l'aide d'un menu proposé par l'application IP, la liste des applications présentes, l'application IP interroge l'application IC du module de sécurité pour obtenir cette liste.

Lors de l'étape préalable El de configuration, l'utilisateur utilise un menu de configuration disponible sur le terminal mobile. Dans ce mode de réalisation, ce menu est proposé par l'application IP.

Ce menu de configuration lui permet par exemple de choisir la sonnerie S 1 pour les applications de transport et la sonnerie S2 pour les applications de paiement. Ces choix sont ensuite enregistrés dans une zone C de la mémoire 14 du terminal mobile

100. Par exemple, comme illustré sur la figure 4, une adresse "ADA" de la sonnerie

S 1 qui représente un paramètre d'interface, est stockée en association avec l'identifiant d'application "transport" TR et la fonction d'interface utilisateur "sonnerie" S et l'adresse "ADB" de la sonnerie S2 est stockée en association avec l'identifiant d'application "paiement" P et la fonction d'interface utilisateur "sonnerie" S.

Un choix par défaut est enregistré lors de l'installation de l'application IP dans le terminal mobile. Ainsi, si l'utilisateur n'effectue pas de choix, ce choix par défaut sera utilisé.

L'utilisateur souhaite, par la suite, installer une nouvelle application sans contact, par exemple une application de transport APl. Pour cela, il choisit la fonction "ajout d'un nouveau service" proposé sur l'écran 18 du terminal mobile 100 par un menu de l'application IP. Suite à ce choix, l'application IP se connecte à un serveur distant gérant l'ensemble des services, par exemple à la plateforme de services SP et obtient en retour une liste des services pouvant être installés sur le terminal mobile 100. Cette liste est affichée sur l'écran du terminal mobile. L'utilisateur peut alors sélectionner l'application de transport APl. Son choix est transmis à la plateforme de services SP qui redirige la demande vers le fournisseur de services SP2 gérant cette application. Si nécessaire, le fournisseur de services SP2 dialogue avec l'application IP, via le réseau R, pour obtenir des données de l'utilisateur nécessaires pour configurer le service, par exemple un numéro d'abonnement. Puis, il transmet l'application APl ainsi qu'une application d'interface (ou "midlet") MPI, associée à cette application, à la plateforme de services SP.

De façon connue, la plateforme de services SP procède au téléchargement de l'application APl dans une mémoire du module de sécurité 20 associé à son terminal mobile.

A titre d'alternative, le téléchargement peut être effectué directement par le fournisseur de services SP2.

Le téléchargement de l'application APl terminé, la plateforme de services met à jour la liste LC gérée par l'application IC du module de sécurité. Pour cela, elle transmet à l'application IC, via le réseau R, des informations concernant l'application APl venant d'être téléchargée. Dans le mode de réalisation décrit, ces informations sont l'adresse URL de l'application d'interface MPI associée à l'application APl, l'identifiant AID de l'application APl et le nom du service. Suite à la réception de ces informations, l'application IC du module de sécurité met à jour sa liste LC des applications présentes sur le module de sécurité.

Dans ce mode de réalisation, le téléchargement de l'application d'interface MPI dans le terminal mobile nécessite une étape de synchronisation de l'application IP avec

le module de sécurité 20. Cette étape décrite dans la suite de la description, est réalisée suite à un redémarrage de l'application IP et permet à celle-ci de déterminer que l'application d'interface MPI doit être téléchargée.

A titre d'alternative, l'application IP commande le téléchargement de l'application d'interface MPI sans réaliser l'étape de synchronisation de l'application IP avec le module de sécurité 20.

L'application IP du terminal mobile s'adresse alors à la plateforme de services SP pour obtenir le téléchargement de l'application d'interface (ou "midlet") MPI dans une zone de la mémoire 14 du terminal mobile. Suite à l'installation de cette application MPI dans le terminal mobile, l'application IP demande à l'application MPI de publier ses informations, par exemple en utilisant une commande "register". Cette commande permet à l'application MPI de publier dans une base partagée (appelée RMS pour " Record Management System") ses informations. RMS est un mécanisme décrit dans les spécifications MIDP (pour "Mobile Information Device Profile") émises par le JCP (Java Community Process) (http ://jcp .org/en/j sr/detail?id= 118). RMS permet a une première application de partager des données avec une seconde application. Cette seconde application doit connaître le nom de la première application qui exporte sa base RMS pour y lire les informations partagées publiées. Ce principe est utilisé ici entre l'application MPI et l'application IP. L'application MPI inscrit dans une zone B de la mémoire 14 du terminal mobile, accessible à l'application IP, les informations à partager, c'est-à-dire des informations accessibles en lecture par l'application IP. Plus précisément et comme illustré sur la figure 5, ces informations sont enregistrées dans une zone BMPl de la mémoire B. A titre d'alternative, toute autre méthode de publication connue de l'homme de l'art peut être utilisée comme, par exemple, l'envoi d'une commande web locale.

Dans le mode de réalisation décrit, les informations publiées dans la zone BMPl par l'application d'interface MPI sont : le nom Nl de l'application APl, son identifiant IdI, son logo Ll, un identifiant de type d'application Tl.

A titre d'alternative, la liste des informations publiées peut contenir plus d'éléments, moins d'éléments ou des éléments différents. Néanmoins, la liste des informations à publier étant également utilisée par l'application IC, la liste des éléments de cette liste doit être déterminée avant compilation de l'application IP et transmise aux fournisseurs de service susceptibles de télécharger des applications dans un module de sécurité associé à un terminal mobile contenant une telle application IC. Un changement de liste implique de modifier l'application IP d'une part et d'autre part oblige les fournisseurs de services de chaque application téléchargée à modifier l'application d'interface associée. A l'étape E21 décrite en référence à la figure 2, l'application IP lit dans la zone d'information partagée BMPl un identifiant d'application. Cela peut être un identifiant IdI propre à l'application, le nom de l'application ou encore l'identifiant de type d'application Tl. Dans l'exemple décrit ici, l'identifiant d'application est l'identifiant de type Tl par exemple un identifiant de type transport TR. Par lecture des informations de configuration stockées dans la mémoire C, l'application IP détermine que la sonnerie S à utiliser pour cette application est enregistrée à l'adresse ADA (adresse de la sonnerie Sl). Lors de l'étape E23 décrite à la figure 2, l'application IP associe alors à la fonction sonnerie S, un lien vers la sonnerie attribuée aux applications de transport. Dans le mode de réalisation décrit, ce lien est l'adresse C(S ₅ TR) de la mémoire C dans laquelle l'adresse (ADA) de la sonnerie Sl a été stockée en association avec la fonction sonnerie S et l'identifiant de type d'application TR.

Lors de l'étape E25 suivante, le lien est sauvegardé dans une mémoire du terminal mobile accessible par l'application IP et par l'application d'interface MPI. Dans ce mode de réalisation, cette étape consiste, pour l'application IP à publier ces informations dans une base de type RMS, partagée par l'application IP et par l'application d'interface MPI. Cette zone mémoire BIPl du terminal mobile, représentée sur la figure 5, est accessible en lecture et en écriture par l'application IP et n'est accessible qu'en lecture par l'application d'interface MPI. Elle n'est pas accessible par les autres applications d'interface téléchargées sur le terminal mobile 100.

La liste des informations publiées par l'application IP à destination d'une application d'interface doit être identique pour toutes les applications d'interface.

Dans le mode de réalisation décrit ici cette liste ne comprend que la fonction sonnerie. D'autres fonctions peuvent bien évidemment être prévues. La liste peut par exemple contenir la fonction sonnerie, la fonction écran (permettant d'afficher un fond d'écran particulier), la taille de la police de caractères à utiliser pour afficher des messages sur l'écran du terminal mobile ou toutes autres fonctions d'interface.

Cette liste des fonctions doit être déterminée à l'avance. En effet, une modification de cette liste entraîne une modification d'une part de l'application IP et d'autre part, de chaque application d'interface associée à une application installée sur le module de sécurité du terminal mobile.

Dans une phase ultérieure, par exemple suite à l'exécution d'une transaction par l'application APl, l'application d'interface MPI est réveillée par la réception d'un événement provenant du module sans contact du mobile indiquant qu'une communication sans contact a été établie avec l'application APl et la fonction sonnerie doit être activée. L'application d'interface MPI lit alors dans la zone BIPl publiée par l'application IP et accessible par l'application d'interface MPI, le lien

C(S ₅ TR). Ce lien étant une adresse mémoire, l'application d'interface récupère l'adresse ADA contenue à cette adresse C(S ₅ TR) et exécute le programme de sonnerie située à l'adresse ADA, c'est-à-dire la sonnerie S 1.

A tout moment, lorsque l'utilisateur le souhaite, la configuration enregistrée lors de l'étape préalable El peut être modifiée. Par exemple, l'utilisateur, à l'aide du menu de configuration peut choisir la sonnerie S2 pour les applications de transport. L'adresse ADA contenue dans le tableau C est alors remplacée par l'adresse ADB de la sonnerie S2. Lorsque l'application APl est activée et en conséquence l'application d'interface MPI, la sonnerie S2 est activée.

Dans le mode de réalisation décrit, le paramètre d'interface enregistré lors de l'étape de configuration El est l'adresse d'une sonnerie. A titre d'alternative, le paramètre d'interface peut être un autre paramètre de la fonction d'interface

utilisateur. Par exemple, ce paramètre peut être une valeur représentant le niveau sonore d'une sonnerie.

Dans un autre mode de réalisation, plusieurs paramètres d'interface peuvent être associés à un identifiant d'application pour une fonction d'interface utilisateur. Par exemple, un premier paramètre détermine le type de la sonnerie (musique 1, musique 2...) et un deuxième paramètre détermine le niveau sonore de cette sonnerie. L'adresse C(S ₅ TR) contient alors ces deux paramètres. Lors de l'exécution de l'application d'interface MPI et plus particulièrement lors de l'appel de la fonction d'interface utilisateur, l'application d'interface MPI lit alors dans la zone BIPl publiée par l'application IP et accessible par l'application d'interface MPI, le lien C(S ₅ TR). L'application d'interface MPI récupère les deux paramètres contenus à cette adresse C(S ₅ TR) et lance l'exécution du programme de sonnerie avec ces deux paramètres.

L'invention a été décrite avec une seule fonction d'interface utilisateur. L'invention s'applique également au cas où plusieurs fonctions d'interface utilisateur sont utilisées en association avec un ou plusieurs identifiant d'application. Par exemple, lors de l'étape El de configuration, on peut associer d'une part le paramètre d'interface "type de sonnerie" à l'identifiant d'application "transport" pour la fonction d'interface utilisateur "sonnerie" et d'autre part le paramètre "taille des caractères" au même identifiant "transport" pour la fonction d'interface utilisateur "affichage". Lors de cette même étape ou dans un autre mode de réalisation, on peut également associer le paramètre "logo" à l'identifiant d'application "paiement" pour la fonction d'interface utilisateur "affichage" pour afficher un logo enregistré par l'utilisateur lors de chaque transaction de paiement.

L'invention a été décrite avec un module de sécurité contenant une seule application sans contact. Elle s'applique également au cas où plusieurs applications avec ou sans contact sont installées sur le module de sécurité. Dans ce cas, autant d'applications d'interface que d'applications ont été chargées dans la mémoire du terminal mobile. Comme illustré figure 5, chaque application d'interface publie des informations dans une zone partagée par elle et l'application IP (BMP1,BMP2,...) et

l'application IP publie des informations dans une zone (BIP1,BIP2,...) partagée avec chaque application d'interface.

Dans le mode de réalisation décrit, l'étape de configuration El permet d'associer un paramètre à une fonction d'IHM et à un identifiant d'application qui est un type d'application (transport, paiement, ... ) .

Dans un autre mode de réalisation, l'identifiant d'application est par exemple le nom de l'application, un logo ou tout autre identifiant d'application publié par l'application d'interface.

La configuration peut également s'effectuer à partir de plusieurs identifiants; un ordre de priorité parmi les identifiants à utiliser doit alors être défini. Par exemple, l'utilisateur peut choisir un type de sonnerie commun à toutes les applications de type paiement sauf pour une application de paiement particulière pour lequel il choisit un autre type de sonnerie.

Un procédé de synchronisation entre le terminal mobile 100 et le module de sécurité 20 va maintenant être décrit.

Lors d'une utilisation précédente, le terminal mobile a enregistré dans une zone

Z de la mémoire 14 du terminal mobile, la liste LM des applications d'interface téléchargées dans ce terminal. Il a également enregistré dans cette zone Z une valeur

H2 représentative des applications installées sur le module de sécurité, transmise par le module de sécurité.

D'autre part, comme décrit précédemment, une application IC du module de sécurité maintient à jour une liste des applications présentes dans le module de sécurité. Plus précisément, cette liste LC, enregistrée dans une zone ZC de la mémoire

24, est un tableau contenant pour chaque application téléchargée dans le module de sécurité, des informations relatives à cette application. Dans le mode de réalisation décrit, ces informations sont, par exemple, l'URL de stockage de l'application d'interface associée à l'application (c'est-à-dire l'adresse permettant de télécharger et d'installer l'application d'interface, l'identifiant de l'application et le nom du service.

Lors de chaque modification de ce tableau LC, l'application IC calcule, à partir des données de ce tableau, une valeur Hl représentative des applications installées sur le

module de sécurité. Par exemple, la valeur Hl est un condensé du tableau ou est obtenue par application d'une fonction de hachage au tableau LC.

La valeur Hl est également enregistrée dans la mémoire ZC du module de sécurité. Lors du démarrage du terminal mobile et/ou du lancement de l'application IP, l'application IP s'adresse à l'application IC du module de sécurité pour obtenir la valeur Hl enregistrée dans le module de sécurité. L'application IP compare ensuite la valeur Hl avec la valeur H2 stockée dans le terminal mobile.

Si ces valeurs ne sont pas identiques, cela signifie que le terminal mobile et le module de sécurité ne sont pas synchronisés, c'est-à-dire qu'au moins un programme d'interface associé à une des applications n'est pas téléchargé dans le terminal mobile, et une procédure de synchronisation est exécutée.

Pour cela, l'application s'adresse au module de sécurité pour obtenir la liste LC et compare les informations contenues dans cette liste avec les informations stockées dans la liste LM du terminal mobile. Elle détermine ainsi le nom du service pour lequel l'application d'interface n'a pas été téléchargée. L'application IP met à jour les informations de sa liste LM et remplace dans la mémoire Z la valeur H2 par la valeur

Hl. Puis, à l'aide de l'URL de l'application d'interface lue dans la liste LC, elle commande le téléchargement de ce programme d'interface. Dans le cas où le module de sécurité est amovible, ce procédé permet également de télécharger l'ensemble des programmes d'interface nécessaires lorsque le module de sécurité est inséré dans un autre terminal mobile.