FR2945143A1 - Procede et systeme d'activation d'applications de paiement sans contact - Google Patents

Abstract

L'invention concerne selon un premier aspect un procédé d'administration d'applications (13a, 13b ; 23) dans lequel on sélectionne un groupe d'une ou plusieurs applications pour que l'une des applications du groupe puisse être utilisée par un dispositif (1) afin de réaliser une transaction sans contact avec un lecteur externe (3), caractérisé par les étapes selon lesquelles : - un module de gestion du groupe (12, 22) transmet une requête d'activation du groupe à un contrôleur d'accès (32) à un registre d'applications (33) stockant le statut de chacune des applications pouvant être utilisées par le dispositif ; - un module d'activation/désactivation des applications (7) indépendant du module de gestion transmet une requête de désactivation du groupe d'applications préalablement activé au contrôleur d'accès.

Description

1

Le domaine de l'invention est celui de l'administration d'applications dans lequel on sélectionne un groupe d'une ou plusieurs applications pour que l'une des applications du groupe puisse être utilisée par un dispositif afin de réaliser une transaction sans contact avec un lecteur externe.

L'invention concerne plus particulièrement l'activation d'applications de paiement sans contact pour qu'un dispositif, tel qu'un terminal de téléphonie mobile, dans lequel les applications sont stockées puisse réaliser des transactions de paiement sans contact avec un lecteur externe de type terminal de paiement électronique.

De nombreux travaux sont aujourd'hui menés pour élaborer des solutions de paiement mobiles sans contact ayant pour objectif de simplifier les paiements de proximité en mettant à disposition des utilisateurs un moyen rapide, simple et sûr pour effectuer leurs transactions de la vie quotidienne avec leurs téléphones mobiles.

Ces solutions s'appuient sur une application de paiement répondant aux règles de fonctionnement de type carte bancaire, installée dans la carte SIM du téléphone mobile d'un utilisateur et sur la technologie sans contact NFC ( Near Field Communication désignant une communication en champ proche).

On connaît du document EP 1 939 822 un système de paiement mobile sans contact dans lequel le dispositif utilisé pour le paiement sans contact contient un ou plusieurs gestionnaires d'applications où chaque gestionnaire est apte à communiquer avec plusieurs applications différentes ou plusieurs instances de la même application. Le dispositif comporte en outre une interface de sélection d'application pouvant être invoquée par un utilisateur afin de sélectionner une application devant être activée. En réponse à la sélection réalisée par l'utilisateur, l'interface de sélection d'application peut activer l'application sélectionnée et procéder à la désactivation des applications qui étaient préalablement actives.

En variante, l'interface de sélection d'application peut notifier le gestionnaire d'applications chargé de l'application sélectionné afin que celui- ci procède à l'activation de l'application sélectionné et à la désactivation des applications qui étaient préalablement actives. On relèvera en premier lieu que ce document est relativement silencieux quant à l'implémentation pratique de ces mécanismes d'activation/désactivation. Et on relèvera surtout que les mécanismes proposés dans ce document n'apportent pas les garanties de sécurité nécessaires dans des applications bancaires. Ce document prévoit en effet l'initiation de l'activation d'une application 1 o par sélection via une interface commune à l'ensemble des applications. Or les solutions de paiement mobile sans contact aujourd'hui envisagées préconisent à des fins de sécurité d'avoir recours à un lien privilégié entre une application de paiement dans la carte SIM et une interface qui lui est dédiée dans le terminal mobile, plutôt qu'à un lien peu 15 sécurisé entre une application et une interface commune à toutes les applications. De telle manière, la sélection d'une application à activer ne peut être réalisée dans les solutions aujourd'hui envisagées que par l'intermédiaire de l'interface dédiée à l'application sélectionnée. 20 On notera par ailleurs qu'il est considéré nécessaire qu'un code personnel lié à l'application soit saisi et vérifié afin de pouvoir activer l'application. On comprend que l'intervention d'une interface commune dans un tel contexte n'est alors pas satisfaisante et que la gestion sécurisé d'un tel processus de vérification de code personnel impose l'établissement du lien 25 privilégié mentionné ci-dessus. En outre, les solutions de paiement mobile sans contact aujourd'hui envisagées préconisent que seule une application de paiement (ou un groupe d'applications comme cela sera explicité par la suite) soit active à un moment donné. Ce qui impose lors de l'activation d'une nouvelle application 30 (ou d'un groupe d'applications) que l'application (ou le groupe d'application) préalablement active soit désactivée.

3

Or le document EP 1 939 822 propose dans sa variante de réalisation que le gestionnaire de l'application sélectionné pour activation vienne désactiver les applications préalablement actives. Une telle solution est une fois encore non satisfaisante en terme de sécurité car le gestionnaire d'applications y désactive des applications qu'il ne gère pas, en outrepassant ainsi ses droits. L'invention a pour objectif de résoudre ces inconvénients afin de proposer un mécanisme d'activation d'applications présentant le niveau de sécurité nécessaire dans des applications de type paiement mobile sans contact. A cet effet, l'invention propose selon un premier aspect un procédé d'administration d'applications dans lequel on sélectionne un groupe d'une ou plusieurs applications pour que l'une des applications du groupe puisse être utilisée par un dispositif afin de réaliser une transaction sans contact avec un lecteur externe, caractérisé par les étapes selon lesquelles : - un module de gestion du groupe transmet une requête d'activation du groupe à un contrôleur d'accès à un registre d'applications stockant le statut de chacune des applications pouvant être utilisées par le dispositif ; - un module d'activation/désactivation des applications indépendant du module de gestion transmet une requête de désactivation du groupe d'applications préalablement activé au contrôleur d'accès. Certains aspects préférés, mais non limitatifs, de ce procédé sont les suivants : - suite à la réception des requêtes, le contrôleur d'accès procède à des modifications de statut dans le registre pour marquer la ou les applications du groupe sélectionné comme étant activées et pour marquer comme étant désactivées la ou les applications préalablement marquées comme étant activées ; - suite au marquage comme étant activées de la ou des applications du groupe sélectionné, le contrôleur d'accès notifie ce marquage au module d'activation/désactivation des applications, lequel module transmet en retour au contrôleur d'accès la requête de désactivation du groupe préalablement activé afin que le contrôleur d'accès puisse marquer la ou les applications du groupe préalablement activé comme étant désactivées ; - la requête d'activation d'un groupe transmise par le module de gestion du groupe est une requête d'activation temporaire pour un nombre prédéterminé de transactions ou pour une durée prédéterminée et dans lequel le contrôleur d'accès vient réactiver le groupe désactivé après réception de ladite requête d'activation une fois que ledit nombre prédéterminé de transactions est réalisé ou une fois que ladite durée 1 o prédéterminée est expirée ; - le module d'activation/désactivation des applications mémorise un identifiant du groupe désactivé à titre temporaire ; - un module d'élaboration d'une réponse à une requête de transaction sans contact issue du lecteur mémorise un identifiant de la ou des 15 applications marquées comme étant activées dans le registre ; - le module d'élaboration d'une réponse à une requête de transaction sans contact est notifié par le contrôleur d'accès des modifications de statut dans le registre, de manière à que ledit module vienne mettre à jour l'identifiant qu'il mémorise ; 20 - le module de gestion du groupe met en oeuvre une vérification de code personnel pour ne valider la sélection du groupe et ne transmettre la requête d'activation du groupe au contrôleur d'accès qu'en cas de vérification positive du code personnel ; - suite à la réception de la requête d'activation du groupe, le contrôleur 25 d'accès vérifie si l'utilisation d'une application du groupe qui serait alors activée est susceptible d'engendrer des conflits radio avec l'utilisation d'autres applications stockées dans le dispositif. Selon d'autres aspects, l'invention propose une carte à puce configurée de manière à pouvoir mettre en oeuvre le procédé selon le premier aspect 30 ainsi qu'un dispositif hébergeant une telle carte à puce. D'autres aspects, buts et avantages de la présente invention apparaîtront mieux à la lecture de la description détaillée suivante de formes de réalisation préférées de celle-ci, donnée à titre d'exemple non limitatif, et faite en référence aux dessins annexés sur lesquels : 5 - la figure 1 est un schéma illustrant le stockage de différentes applications de paiement dans une carte à puce destinée à être insérée dans un terminal de téléphonie mobile pour offrir différentes solutions de paiement mobile sans contact ; - la figure 2 représente de manière plus détaillée une solution de paiement mobile sans contact, et illustre notamment un mécanisme d'activation d'un groupe d'une ou plusieurs applications conforme à un mode de réalisation possible de l'invention. - la figure 3 illustre un mécanisme d'activation d'un groupe lorsqu'aucun autre groupe n'est préalablement activé ainsi qu'un mécanisme de désactivation d'un groupe, tous deux conformes à un mode de réalisation possible de l'invention ; - la figure 4 représente un mode de réalisation possible de l'invention selon lequel la requête d'activation d'un groupe transmise par le module de gestion du groupe est une requête d'activation pour un nombre prédéterminé de transactions ou pour une durée prédéterminée. En référence à la figure 1, on a représenté un terminal de téléphonie mobile 1 dans lequel une carte à puce 2 de type carte UICC (Universal Integrated Circuit Gard), par exemple une carte SIM ou une carte USIM, stockant les informations spécifiques à l'abonné d'un réseau mobile peut être insérée pour gérer l'authentification de l'abonné dans le réseau. Dans le cadre de l'invention, le terminal peut être doté de plusieurs solutions de paiement. Comme cela est représenté à titre d'exemple sur la figure 1, le terminal 1 peut utiliser une première solution de paiement proposée par une Banque 1 et une seconde solution de paiement proposée par une Banque 2.

Chaque solution de paiement est composée d'une carte de paiement virtuelle stockée dans la carte 2 et d'une interface homme machine (IHM) dédiée à la solution de paiement qui est stockée dans le terminal 1. L'IHM offre différents outils de gestion de la carte de paiement virtuelle à laquelle elle est associée. Elle permet en particulier à l'utilisateur d'activer ou désactiver la ou les applications de la carte de paiement virtuelle, de réaliser un paiement, de modifier un code personnel, de visualiser les paiements réalisés, etc. Une carte de paiement virtuelle peut comprendre une ou plusieurs applications de paiement. Comme représenté à titre d'exemple sur la figure 1, la solution de paiement de la Banque 1 comprend une application de paiement locale et une application de paiement internationale. L'application de paiement locale est typiquement utilisée pour réaliser des transactions sur le marché domestique de la Banque 1, tandis que l'application de paiement internationale est typiquement utilisée lorsque l'utilisateur se trouve à l'étranger. La solution de paiement de la Banque 2 ne comprend quant à elle qu'une seule application. On relèvera que le stockage et l'exécution des applications dans la carte 2 peuvent être réalisés d'une manière connue en soi sur la base du SIM Application Toolkit (USIM Application Toolkit dans le cas de l'UMTS) et d'un environnement applicatif Java Gard. La figure 2 représente de manière plus détaillée une solution de paiement mobile sans contact mettant en oeuvre un dispositif apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe. Le dispositif est typiquement un terminal de téléphonique mobile 1 disposant d'un contrôleur NFC 3 et dans lequel peut être logée une carte UICC 2. On comprendra cependant que l'invention n'est pas limité par le type de dispositif pouvant être utilisé ni par le type de technologie sans contact.

De manière connue en soi, la carte 2 contient plusieurs domaines de sécurité (Security Domains), à savoir un domaine de sécurité de l'émetteur de la carte (Issuer Security Domain - ISD) et un ou plusieurs domaines de sécurité supplémentaires (Supplementary Security Domains - SSD) tels que définis dans la norme GlobalPlatform Gard Specifications v.2.2 . Chaque fournisseur d'applications dispose ainsi de la possibilité de stocker et de gérer ses propres applications dans un environnement sécurisé dont il est le seul responsable. En particulier, un domaine de sécurité supplémentaire peut être dédié à une solution de paiement d'une banque. On a ainsi représenté sur la figure 2, le domaine ISD 4 et deux domaines supplémentaires 11, 21 chacun dédié à une solution de paiement.

Le domaine ISD contient de manière classiquement connue en soi l'application SIM ou USIM permettant de gérer l'authentification de l'abonné auprès du réseau. Dans le cadre d'un mode de réalisation possible de l'invention, le domaine ISD 4 contient également différents modules 6, 7, 8 dédiés à la solution de paiement mobile sans contact qui seront décrites plus en détail par la suite, à savoir : - un module 6 de listage des applications ; - un module 7 d'activation/désactivation; - un module 8 d'élaboration d'une réponse à une requête de transaction sans contact.

Chaque domaine de sécurité supplémentaire alloué à une banque 11, 21 contient un groupe d'une ou plusieurs applications 12, 13a, 13b ; 23 et un module de gestion 12, 22 du groupe. En conservant l'exemple de la figure 1, le domaine de sécurité supplémentaire 11 est par exemple alloué à la Banque 1. Il contient un groupe d'applications comprenant une application de paiement locale 13a et une application de paiement internationale 13b, ainsi qu'un module de gestion du groupe 12. Le domaine de sécurité supplémentaire 12 est quant à lui alloué à la Banque 2 et contient un groupe comprenant une seule application de paiement 23, ainsi qu'un module de gestion du groupe 22.

On relèvera qu'un module de gestion de groupe a pour objectif de remplir des fonctions spécifiques à une solution de paiement mobile sans contact dans la mesure où ces fonctions ne sont pas couvertes par les applications de paiement. L'invention n'est toutefois pas limitée à un module de gestion de groupe indépendant d'une application de paiement, et s'étend également au cas où une application de paiement peut elle-même réaliser les fonctions spécifiques au paiement mobile sans contact, le module de gestion de groupe y étant de la sorte intégré. Différentes interfaces homme-machine (typiquement des applets Java) sont par ailleurs chargées dans le terminal 1. / Comme déjà décrit précédemment, une interface sous la responsabilité 1 o d'une banque est dédiée à chacune des solutions de paiement embarquées dans la carte. Cette interface peut notamment être reliée de manière sécurisée à une ou plusieurs applications stockées dans un unique domaine de sécurité supplémentaire dans la carte. L'interface offre différents outils de gestion à l'utilisateur, en particulier la possibilité d'activer ou désactiver la ou 15 les applications de la carte de paiement virtuelle, de sélectionner une application pour réaliser un paiement, de modifier un code personnel, de visualiser les paiements réalisés, etc. On a représenté sur la figure 2, deux interfaces 10, 20 de ce type (dénommées IHM Banque dans ce qui suit) reliées respectivement à une application (appelée module de gestion d'un 20 groupe d'applications de paiement dans ce qui suit) d'un domaine de sécurité supplémentaire 11, 21. / Une interface 9 (dénommées IHM Opérateur dans ce qui suit) sous la responsabilité de l'opérateur permettant à l'utilisateur de visualiser tous les services NFC stockés dans la carte et de lancer, suite à une sélection 25 réalisée par l'utilisateur, l'IHM Banque correspondante. On a également représenté sur la figure 2 le système d'exploitation 30 de la carte 2 lequel met notamment en ouvre une interface de contrôleur NFC 31, un environnement répondant aux spécifications GlobalPlatform (comprenant un registre 33 stockant le statut de chacune des applications, 30 un contrôleur d'accès au registre 32, ainsi qu'un module de routage 34) qui sera détaillé plus en avant par la suite.

Le procédé selon le premier aspect de l'invention a pour objectif de fournir un mécanisme d'administration des applications 13a, 13b, 23 stockées dans la carte 2 dans lequel on sélectionne un groupe d'une ou plusieurs applications pour que l'une des applications du groupe puisse être utilisée pour réaliser une transaction sans contact entre le dispositif 1 et le lecteur externe 3. Typiquement l'utilisateur consulte via l'IHM Opérateur 9 une liste des différentes solutions de paiement susceptibles d'être utilisées pour réaliser une transaction de paiement sans contact entre le terminal mobile 1 et un lecteur externe 3, tel qu'un terminal de paiement électronique doté de moyens pour établir une liaison sans contact. La sélection par l'utilisateur d'une solution de paiement dans la liste va alors entraîner le lancement de l'interface Banque 10, 20 correspondant à la solution de paiement sélectionnée. A titre d'exemple, la sélection via l'IHM Opérateur 9 de la solution de paiement offerte par la Banque 1 va entraîner le lancement de l'IHM Banque 10, tandis que la sélection de la solution de paiement offerte par la Banque 2 va entraîner le lancement de l'IHM Banque 20. L'utilisateur visualise alors un menu dans lequel différents outils d'administration de la solution de paiement sont proposées : activation/désactivation de la solution, saisie de code personnel, changement de code personnel, consultation d'un historique de transaction, etc. Revenant à la description du procédé selon le premier aspect de l'invention, l'utilisateur choisit via l'IHM Banque d'activer la solution de paiement correspondante. On prendra dans ce qui suit l'exemple de l'activation via l'IHM Banque 20 de la solution de paiement de la Banque 2. On précise à ce stade que l'activation (ou la désactivation) d'une solution de paiement correspond à l'activation (ou la désactivation) de l'ensemble des applications de paiement formant la solution de paiement. Ainsi dans le cas de la solution de paiement de la banque 1, l'activation (désactivation) correspond à l'activation

10

(désactivation) de l'application de paiement locale 13a et de l'application de paiement internationale 13b. Les différentes flèches sur la figure 2 illustrent les échanges entre les différents composants de la carte 2 et du terminal 1 suite à cette sélection opérée par l'utilisateur, les flèches portant un numéro de référence représentant la séquence de ces différents échanges telle que décrite ci-après. (1) L'IHM Banque 20 transmet au module de gestion 22 une requête d'activation du groupe d'applications de la solution de paiement de la banque 2 (ici activation de la seule application de paiement 23). Dans un mode de réalisation préférentiel, cette requête comprend un code personnel saisi par l'utilisateur via l'IHM Banque 20 et le module de gestion met alors en oeuvre une vérification du code personnel afin de valider la sélection. (2) Le module de gestion 22 transmet ensuite, le cas échéant après vérification positive du code personnel, une requête d'activation du groupe au contrôleur d'accès 32 au registre 33. Il requiert ainsi sa propre activation. Ainsi, dans le cadre de l'invention, seul le module de gestion du groupe est habilité à initier l'activation de la ou des applications du groupe par transmission d'une requête d'activation du groupe au contrôleur d'accès. De telle manière, le lien sécurisé entre l'IHM Banque et le domaine de sécurité correspondant est privilégié (plutôt que le lien non spécifique entre l'IHM Opérateur 9 et l'application de listage des applications 6 qui court-circuiterait le module de gestion et empêcherait en particulier la vérification d'un code personnel lors de l'activation) et on s'assure qu'une application ne puisse être activée (ou désactivée) que par le module de gestion auquel elle appartient (ce dernier n'outrepassant dès lors pas ces droits). Suite à cette requête d'activation du groupe, et comme cela est détaillé ci-après, le contrôleur d'accès 32 procède à des modifications de statut dans le registre 33 pour marquer la ou les applications du groupe sélectionné

11

comme étant activées (étape 3) et pour marquer comme étant désactivées la ou les applications préalablement marquées comme étant activées (étape 7). (3) Le contrôleur d'accès 32 modifie le statut de l'application du groupe dans le registre 33, en marquant l'application 23 comme étant active. Dans le cas d'un groupe comprenant plusieurs applications (tel que le groupe de la Banque 1 comprenant l'application locale 13a et l'application internationale 13b), toutes les applications du groupe sont alors marquées comme étant actives. (4) Le contrôleur d'accès 32 notifie le module d'activation/désactivation 7 1 o qu'une nouvelle application a été activée. (5) Le contrôleur d'accès 32 retourne au module de gestion 22 le résultat positif ou négatif de l'activation de l'application 23. On notera que dans un mode de réalisation possible de l'invention, le contrôleur d'accès vérifie, suite à la réception de la requête d'activation du 15 groupe, si l'utilisation d'une application du groupe qui serait alors activée est susceptible d'engendrer des conflits radio avec l'utilisation d'autres applications stockées dans le dispositif. Le cas échéant, l'activation peut ne pas être réalisée, et le module de gestion en est alors avisé au cours de cette étape (5). 20 (6) Le module d'activation/désactivation 7 sollicite la désactivation du groupe précédemment actif en envoyant une requête de désactivation au contrôleur 32. On notera que ce mécanisme est défini de manière à n'avoir qu'une application (ou groupe d'applications) active à un instant donné. La requête de désactivation consiste à instruire le contrôleur 32 de désactiver toutes les 25 applications marquées comme étant actives dans le registre 33, à l'exception de l'application nouvellement activée. (7) Le contrôleur 32 modifie le statut de la ou des applications préalablement marquées comme étant actives dans le registre 33 pour la ou les marquer comme étant désactivées. 30 (8) Le contrôleur 32 notifie le module d'activation/désactivation 7 du résultat positif ou négatif de la désactivation (9) Le contrôleur 32 notifie le module 8 d'élaboration d'une réponse à une requête de transaction sans contact issue du lecteur du fait de la nouvelle activation. (10) Le module 8 vient alors consulter le registre 33 afin de retrouver la ou les identifiants de la ou des applications actives de manière à pouvoir mettre à jour la réponse à une requête de transaction sans contact. On précise qu'une telle requête de transaction sans contact issue du lecteur est connue sous le nom de commande SELECT PPSE (où PPSE désigne Proximity Payment System Environment ), la réponse à cette commande étant connu sous le nom de PPSE RESPONSE dont un attribut est l'identifiant AID de chacune des applications actives. La commande SELECT PPSE est plus précisément routée au module 8 par l'interface de contrôleur NFC 31. Suite à la réception de la réponse PPSE RESPONSE, le lecteur sélectionne l'application avec laquelle il souhaite réaliser une transaction (cette application 23 étant unique dans le cas où la solution de paiement de la Banque 2 est activée ; il peut également s'agir de l'application locale 13a ou de l'application internationale 13b dans le cas où la solution de paiement de la Banque 1 est activée, le choix étant typiquement réalisé en fonction du lieu où la transaction doit être menée). Le lecteur fournit pour cela une commande SELECT dont un attribut est l'identifiant AID de l'application sélectionnée. On relèvera que du point de vue du lecteur la sélection de l'application est réalisée en utilisant un AID court, tandis que dans l'environnement Global Platform la sélection de l'application utilise un AID long. D'une manière connue en soi, le module de routage 34 permet de faire suivre les commandes issues du lecteur à l'application dont l'AID long correspond à l'AID court reçu dans la commande SELECT. On a représenté sur la figure 3, le cas d'une activation d'un groupe réalisée alors qu'aucun autre groupe n'est alors marqué comme étant actif. On comprendra que le cas d'une désactivation d'un groupe suit les mêmes

13

étapes. Sur la figure 3, les éléments similaires à ceux de la figure 2 portent les mêmes références numériques. (1) Une requête d'activation (respectivement de désactivation) est transmise au module de gestion de groupe 22 par l'IHM Banque correspondante 20.

Cette requête peut être associée à une requête de vérification du code personnel saisi par l'utilisateur via l'IHM Banque 20. (2) Le module de gestion 22 transmet une requête d'activation (resp. de désactivation) au contrôleur d'accès 32. (3) Le contrôleur d'accès marque l'application 23 gérée par le module de 1 o gestion 22 comme étant activée (resp. désactivée) dans le registre 33. (4) Le contrôleur d'accès notifie le module d'activation/désactivation 7 de l'activation (resp. de la désactivation) (5) Le contrôleur d'accès notifie le module de gestion du succès ou non de l'activation (resp. désactivation) 15 (6) Non applicable (7) Non applicable (8) Non applicable Les étapes (6), (7) et (8) ne sont pas mises en oeuvre car non nécessaires dans ces cas de figure (aucune application préalablement active n'est à 20 désactiver). (9) Le contrôleur d'accès notifie le module 8 de l'activation (désactivation) (10) Le module 8 se met à jour par consultation du registre. On a représenté sur la figure 4, un mode de réalisation possible de l'invention selon lequel la requête d'activation d'un groupe transmise par le 25 module de gestion du groupe (activation de l'application 23 via le module de gestion 22 dans l'exemple représenté) est une requête d'activation temporaire pour un nombre prédéterminé de transactions ou pour une durée prédéterminée. Dans ce mode de réalisation, le contrôleur d'accès vient réactiver le groupe désactivé après réception de ladite requête d'activation 30 une fois que ledit nombre prédéterminé de transactions est réalisé ou une fois que ladite durée prédéterminée est expirée.

14

Sur cette figure 4 également, les éléments similaires à ceux de la figure 2 portent les mêmes références numériques. Les étapes (3), (5) à (10) sont similaires à celles mises en oeuvre sur la figure 2, tandis que les requêtes d'activation des étapes (1) et (2) et la notification de l'étape (4) sont modifiées pour faire état de ce qu'il s'agit une activation temporaire (par exemple pour la réalisation d'une seule transaction). Les étapes (1) à (10) sont suivies des étapes suivantes (11) à (20) mises en oeuvre afin de réactiver la ou les applications désactivées temporairement (ici l'application 23) une fois que ledit nombre prédéterminé de transactions est réalisé ou une fois que ladite durée prédéterminée est expirée. (11) Le module de gestion 22 transmet une requête de désactivation au contrôleur d'accès 32. Cette requête de désactivation indique qu'il s'agit de venir désactiver l'application 23 préalablement activée à titre temporaire. (12) Le contrôleur d'accès 32 marque l'application 23 comme désactivée dans le registre 33. (13) Le contrôleur d'accès 32 notifie le module d'activation/désactivation 7 de la désactivation de l'application 23 préalablement activée à titre temporaire. (14) Le contrôleur d'accès 32 notifie le module 8 d'élaboration d'une réponse à une requête de transaction sans contact de la désactivation de l'application 23. (15) Le contrôleur d'accès 32 notifie le module de gestion 22 du succès ou non de la désactivation de l'application 23. (16) Le module d'activation/désactivation 7 sollicite l'activation du groupe qui était actif préalablement à l'activation de l'application 23 à titre temporaire en envoyant une requête d'activation au contrôleur d'accès 32. Le module d'activation/désactivation 7 est pour ce faire configuré de manière à conserver en mémoire l'AID du groupe d'applications désactivé lors de

15

l'activation de l'application 23 à titre temporaire de manière à pouvoir transmettre cet AID au contrôleur d'accès 22 dans la requête d'activation. (17) Le contrôleur d'accès marque comme étant active(s) la ou les applications du groupe désactivé lors de l'activation de l'application 23 à titre temporaire. (18) Le contrôleur d'accès notifie le module 7 d'activation/désactivation du résultat de l'activation. (19) Le contrôleur d'accès notifie le module 8 d'élaboration d'une réponse à une requête de transaction sans contact du fait de la nouvelle activation. (20) Le module 8 vient consulter le registre 33 afin de retrouver l'AID du groupe d'applications (ré-)activé. Revenant à la description de la figure 2, le module de listage des applications 6 assure la synchronisation entre les applications chargées dans la carte 2 et les IHM Banque 10, 20 installées dans le terminal 2. Il est en particulier configuré de manière à pouvoir dialoguer avec le contrôleur d'accès 32 afin de lister les applications chargées dans la carte et leurs statuts et à pouvoir communiquer cette liste à l'IHM Opérateur 9 afin que celle-ci puisse présenter à l'utilisateur une liste des applications pour sélection.

On précise par ailleurs que le module d'activation/désactivation 7 et le module 8 d'élaboration d'une réponse à une requête de transaction sans contact sont représentés sur la figure 2 comme étant installés dans le domaine ISD 4. L'invention n'est toutefois pas limitée à ce mode de réalisation, mais s'étend également au cas où ces modules sont installés dans un domaine SSD neutre , au cas où les fonctions réalisées par ces modules sont implémentées par un seul module, etc. Enfin on comprendra que les différents éléments (modules, applications, contrôleur, interface, registre) mentionnés précédemment peuvent tout indifféremment être implémentés sous forme logicielle, micrologicielle ou matérielle.

L'invention n'est par ailleurs pas limitée à un procédé d'administration selon son premier aspect, mais s'étend également à une carte à puce comprenant les modules nécessaires à la mise en oeuvre du procédé selon le premier aspect de l'invention ainsi qu'à un dispositif intégrant une telle carte à puce.

Claims (10)

1. REVENDICATIONS1. Procédé d'administration d'applications (13a, 13b ; 23) dans lequel on sélectionne un groupe d'une ou plusieurs applications pour que l'une des applications du groupe puisse être utilisée par un dispositif (1) afin de réaliser une transaction sans contact avec un lecteur externe (3), caractérisé par les étapes selon lesquelles : - un module de gestion du groupe (12, 22) transmet une requête d'activation du groupe à un contrôleur d'accès (32) à un registre d'applications (33) stockant le statut de chacune des applications pouvant être utilisées par le dispositif ; - un module d'activation/désactivation des applications (7) indépendant du module de gestion transmet une requête de désactivation du groupe d'applications préalablement activé au contrôleur d'accès.
2. 2. Procédé selon la revendication 1, dans lequel suite à la réception des requêtes, le contrôleur d'accès procède à des modifications de statut dans le registre pour marquer la ou les applications du groupe sélectionné comme étant activées et pour marquer comme étant désactivées la ou les applications préalablement marquées comme étant activées.
3. 3. Procédé selon la revendication précédente, dans lequel suite au marquage comme étant activées de la ou des applications du groupe sélectionné, le contrôleur d'accès notifie ce marquage au module d'activation/désactivation des applications (7), lequel module transmet en retour au contrôleur d'accès la requête de désactivation du groupe préalablement activé afin que le contrôleur d'accès puisse marquer la ou les applications du groupe préalablement activé comme étant désactivées.
4. 4. Procédé selon l'une des revendications précédentes, dans lequel la requête d'activation d'un groupe transmise par le module de gestion du groupe est une requête d'activation temporaire pour un nombre prédéterminé de transactions ou pour une durée prédéterminée et dans lequel le contrôleur d'accès vient réactiver le groupe désactivé après réception de ladite requête d'activation une fois que ledit nombre prédéterminé de transactions est réalisé ou une fois que ladite durée prédéterminée est expirée.
5. 5. Procédé selon la revendication précédente prise en combinaison avec la revendication 3, dans lequel le module d'activation/désactivation des applications mémorise un identifiant du groupe désactivé à titre temporaire.
6. 6. Procédé selon l'une des revendications précédentes, dans lequel un module (8) d'élaboration d'une réponse à une requête de transaction sans contact issue du lecteur mémorise un identifiant de la ou des applications marquées comme étant activées dans le registre.
7. 7. Procédé selon la revendication précédente, dans lequel le module d'élaboration d'une réponse à une requête de transaction sans contact est notifié par le contrôleur d'accès des modifications de statut dans le registre, de manière à que ledit module vienne mettre à jour l'identifiant qu'il mémorise.
8. 8. Procédé selon l'une des revendications précédentes, dans lequel le module de gestion du groupe met en oeuvre une vérification de code personnel pour ne valider la sélection du groupe et ne transmettre la requête d'activation du groupe au contrôleur d'accès qu'en cas de vérification positive du code personnel.
9. 9. Procédé selon l'une des revendications précédentes, dans lequel suite à la réception de la requête d'activation du groupe, le contrôleur d'accès vérifie si l'utilisation d'une application du groupe qui serait alors activée est susceptible d'engendrer des conflits radio avec l'utilisation d'autres applications stockées dans le dispositif.30. Carte à puce (2) destinée à être utilisée dans un dispositif (1) apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe (3), comprenant : - au moins un groupe d'une ou plusieurs applications (13a, 13b ; 23) pouvant être sélectionné pour que l'une des applications du groupe puisse être utilisée pour réaliser une transaction sans contact entre le dispositif et le lecteur externe, - un registre d'applications (33) stockant le statut de chacune des applications pouvant être utilisées par le dispositif ; - un contrôleur d'accès au registre (32) apte à procéder à des modifications de statut dans le registre ; la carte à puce étant caractérisée en ce qu'elle comporte : - un module de gestion (12, 22) associé à chaque groupe et configuré pour, suite à la sélection du groupe, transmettre une requête d'activation du groupe au contrôleur d'accès, - un module d'activation/désactivation des applications (7) indépendant du module de gestion et configuré pour transmettre une requête de désactivation du groupe d'applications préalablement activé au contrôleur d'accès. 11. Carte à puce selon la revendication précédente, dans lequel, suite à la sélection d'un groupe, le module de gestion associé au groupe est configuré pour transmettre une requête d'activation du groupe au contrôleur d'accès, ladite requête étant interprétée par le contrôleur d'accès de telle manière que la ou les applications du groupe sélectionné sont marquées comme étant activées dans le registre et que la ou les applications préalablement marquées comme étant activées dans le registre sont marquées comme étant désactivées. 12. Carte à puce selon l'une des deux revendications précédentes, dans laquelle le contrôleur d'accès est configuré pour notifier le module d'activation/désactivation des applications (7) de l'activation de la ou des applications du groupe sélectionné et pour recevoir en retour la requête de désactivation du groupe préalablement activé.. Carte à puce selon l'une des trois revendications précédentes, dans lequel le module de gestion du groupe est configuré pour mettre en oeuvre une vérification de code personnel et pour ne transmettre la requête d'activation du groupe au 5 contrôleur d'accès qu'en cas de vérification positive du code personnel. 14. Carte à puce selon l'une des quatre revendications précédentes, dans laquelle un groupe d'une ou plusieurs applications et le module de gestion associé sont stockés dans un domaine de sécurité supplémentaire (11, 21).
10. 10 15. Carte à puce selon l'une des revendications 11 à 14, dans laquelle un groupe comprend une seule application (23) dans laquelle le module de gestion du groupe est intégré. 15 16. Carte à puce selon l'une des revendications 11 à 15, dans laquelle un groupe comprend deux applications (13a, 13b), l'une destinée à être utilisée pour une transaction locale et l'autre destinée à être utilisée pour une transaction internationale. 20 17. Carte à puce selon l'une des revendications 13 à 16, dans laquelle le module d'activation/désactivation des applications (7) est stocké dans un domaine de sécurité, par exemple dans un domaine de sécurité (4) sous la responsabilité d'un émetteur de la carte. 25 18. Dispositif intégrant une carte à puce selon l'une des revendications 11 à 17. 19. Dispositif selon la revendication 18, comprenant une application formant interface utilisateur (10, 20) associée à chaque module de gestion de groupe (11, 21) dans la carte à puce, à partir de laquelle un utilisateur peut solliciter l'activation 30 du groupe ce qui engendre la transmission d'une requête d'activation de l'interface utilisateur au module de gestion.