FR2945141A1 - Procede et systeme de gestion d'une application de paiement mobile sans contact mettant en oeuvre une verification de code personnel - Google Patents

Procede et systeme de gestion d'une application de paiement mobile sans contact mettant en oeuvre une verification de code personnel Download PDF

Info

Publication number
FR2945141A1
FR2945141A1 FR0952960A FR0952960A FR2945141A1 FR 2945141 A1 FR2945141 A1 FR 2945141A1 FR 0952960 A FR0952960 A FR 0952960A FR 0952960 A FR0952960 A FR 0952960A FR 2945141 A1 FR2945141 A1 FR 2945141A1
Authority
FR
France
Prior art keywords
payment
session
application
indicator
verification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0952960A
Other languages
English (en)
Other versions
FR2945141B1 (fr
Inventor
Jean Desbizet
Cyril Roger
Tolla Lamaa
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BANQUE FEDERALE DES BANQUES PO
BANQUE POSTALE
CAISSE FEDERALE DU CREDIT MUTU
CAISSE NATIONALE DES CAISSES D
SOC GEN
BNP Paribas SA
Bouygues Telecom SA
Orange SA
Societe Francaise du Radiotelephone SFR SA
Credit Agricole SA
Societe Generale SA
Original Assignee
BANQUE FEDERALE DES BANQUES PO
BANQUE POSTALE
CAISSE FEDERALE DU CREDIT MUTU
CAISSE NATIONALE DES CAISSES D
SOC GEN
France Telecom SA
BNP Paribas SA
Bouygues Telecom SA
Societe Francaise du Radiotelephone SFR SA
Credit Agricole SA
Societe Generale SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by BANQUE FEDERALE DES BANQUES PO, BANQUE POSTALE, CAISSE FEDERALE DU CREDIT MUTU, CAISSE NATIONALE DES CAISSES D, SOC GEN, France Telecom SA, BNP Paribas SA, Bouygues Telecom SA, Societe Francaise du Radiotelephone SFR SA, Credit Agricole SA, Societe Generale SA filed Critical BANQUE FEDERALE DES BANQUES PO
Priority to FR0952960A priority Critical patent/FR2945141B1/fr
Publication of FR2945141A1 publication Critical patent/FR2945141A1/fr
Application granted granted Critical
Publication of FR2945141B1 publication Critical patent/FR2945141B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1025—Identification of user by a PIN code
    • G07F7/1058—PIN is checked locally
    • G07F7/1066—PIN data being compared to data on card

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Telephone Function (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne selon un premier aspect un procédé pour la gestion d'une application de paiement sans contact active embarquée au sein d'un appareil apte à établir une communication sans contact avec un terminal de paiement sans contact, comprenant les étapes suivantes : o suite à l'initialisation d'une session de paiement mettant en oeuvre l'application de paiement sans contact, saisie d'un code personnel via une interface ; o vérification du code personnel saisi par un module de gestion associé à un groupe d'une ou plusieurs applications comprenant l'application mise en oeuvre dans la session de paiement, et en cas de vérification positive, renseignement par le module de gestion d'un indicateur de vérification du code personnel ; o lecture de l'indicateur par l'application et finalisation de la session de paiement si l'indicateur est renseigné ; o réinitialisation de l'indicateur une fois la session finalisée.

Description

Le domaine de l'invention est celui des solutions de paiement sans contact dans lesquelles des transactions de paiement sont effectuées entre un appareil mobile et un lecteur externe. L'invention concerne des applications de paiement sans contact activées pour qu'un appareil, tel qu'un appareil 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. Plus particulièrement encore, l'invention concerne un processus de gestion d'une application de paiement sans contact activée nécessitant la vérification d'un code personnel pour la finalisation de la transaction. 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 WO 2008/086421 Al, un procédé de gestion d'une application de paiement sans contact au sein d'un appareil mobile, lequel procédé comprend les étapes suivantes : - entrée d'une limite de temps prédéterminée dans le téléphone mobile, - activation d'une application de paiement mobile associée avec le téléphone mobile, - désactivation de ladite application, une fois la limite de temps prédéterminée dépassée. On relèvera en premier lieu que ce document est relativement silencieux quant à l'implémentation pratique de ce procédé de gestion de l'application.
Et on relèvera surtout que le procédé proposé par ce document n'est applicable que pour des scénarios dans lesquels l'application n'est activée que pour une seule transaction. Ce document ne traite effectivement pas du cas d'un mode d'exécution dans lequel l'application est en permanence active (mode d'exécution appelé always on selon lequel l'application de paiement peut directement être mise en oeuvre dans le cadre d'une session de paiement, ladite session étant par exemple initiée lorsque le terminal mobile est placé à proximité d'un terminal de paiement sans contact ou lorsque l'utilisateur du terminal mobile sélectionne manuellement une fonction de paiement pour la réalisation de la session avec l'application active). Or les solutions de paiement mobile sans contact aujourd'hui envisagées préconisent de pouvoir utiliser les applications de paiement dans n'importe quelle situation sans avoir forcément à les activer manuellement au préalable à chaque transaction.
On notera par ailleurs que la solution préconisée par le document précité n'est pas entièrement satisfaisante en ce que, dans le cas d'un dépassement de la limite de temps, elle nécessite une réactivation manuelle de l'application pour toute nouvelle transaction envisagée. L'invention a donc pour objectif de résoudre ces inconvénients afin de proposer un procédé de gestion d'un groupe d'une ou plusieurs applications de paiement permettant de maintenir la ou les applications du groupe actives sans pour autant réduire le niveau de sécurité attendu quant à l'utilisation d'une application du groupe D'une manière plus générale, l'invention a pour objectif d'offrir à un groupe d'applications de paiement différents services nécessaires à la mise en oeuvre d'une solution de paiement mobile sans contact, en particulier un service de vérification d'un code personnel. A cet effet, l'invention propose selon un premier aspect un procédé pour la gestion d'une application de paiement sans contact active embarquée au sein d'un appareil apte à établir une communication sans contact avec un terminal de paiement sans contact, comprenant les étapes suivantes : - suite à l'initialisation d'une session de paiement mettant en oeuvre l'application de paiement sans contact, saisie d'un code personnel via une interface; ù vérification du code personnel saisi par un module de gestion associé à un groupe d'une ou plusieurs applications comprenant l'application mise en oeuvre dans la session de paiement, et en cas de vérification positive, renseignement par le module de gestion d'un indicateur de vérification du code personnel ; ù lecture de l'indicateur par l'application et finalisation de la session de paiement si l'indicateur est renseigné ; ù réinitialisation de l'indicateur une fois la session finalisée. Avantageusement mais facultativement, l'invention comprend au moins l'une des caractéristiques suivantes : - le procédé comprend les étapes suivantes mises en oeuvre en cas de vérification positive du code personnel : ^ démarrage d'un compteur de temps; ^ dans le cas où la session de paiement n'est pas finalisée une fois une limite de temps prédéterminée atteinte par le compteur, fermeture de la session de paiement tandis que l'application reste active de manière à pouvoir directement être mise en oeuvre pour une nouvelle session de paiement. - l'initialisation de la session de paiement fait suite à une étape de communication sans contact entre l'appareil et un terminal de paiement ; - l'initialisation de la session de paiement met en oeuvre une sélection de l'application de paiement par le terminal de paiement parmi la ou les applications de paiement actives ; - l'initialisation de la session de paiement fait suite à la sélection, via l'interface, par un utilisateur de l'appareil, de l'application de paiement parmi la ou les applications de paiement actives. - la fermeture de la session de paiement entraîne la fermeture de l'interface ; 30 - le procédé comprend en outre les étapes suivantes : une fois le code saisi, envoi par l'interface, à destination d'un module de gestion associé à un groupe d'une ou plusieurs applications de paiement sans contact comprenant l'application destinée à être mise en oeuvre dans la session de paiement, d'une commande de vérification du code saisi ; vérification du code saisi par le module de gestion : en cas de succès de la vérification, envoi par le module de gestion à l'interface d'une commande de démarrage du compteur de temps. - en cas de vérification positive du code saisi par le module de gestion, le module de gestion renseigne un indicateur de vérification du code personnel ; - suite à la fermeture ou à la finalisation de la session de paiement, le module de gestion réinitialise l'indicateur de vérification du code personnel ; Selon d'autres aspects, l'invention s'étend à un module de gestion d'un groupe d'applications ainsi qu'à une carte à puce stockant un tel module et à un appareil 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 : - 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 est un schéma représentant de manière plus détaillée une solution de paiement mobile sans contact mettant en oeuvre un appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un terminal de paiement sans contact ; - la figure 3 représente un premier mode de réalisation possible du procédé selon le premier aspect de l'invention - la figure 4 représente un second mode de réalisation possible du procédé selon le premier aspect de l'invention - la figure 5 illustre les communications conformes à un mode de réalisation possible de l'invention entre une interface utilisateur et un module de gestion associé à l'application de paiement sans contact. 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 Card), 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 A et, facultativement, une seconde solution de paiement proposée par une Banque B. 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 ou la carte 2. 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 A comprend une application de paiement locale et une application de paiement internationale. 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 Card.
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. Chaque domaine de sécurité supplémentaire alloué à une banque 11, 21 contient un groupe d'une ou plusieurs applications 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 A. 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 21 est quant à lui alloué à la Banque B 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 ou la carte 2. / Comme déjà décrit précédemment, une interface sous la responsabilité d'une banque est dédiée à chacune des solutions de paiement embarquées dans la carte. Cette interface est ainsi reliée de manière sécurisée à un unique domaine de sécurité supplémentaire dans la carte et offre différents outils de gestion à l'utilisateur, en particulier la possibilité d'activer ou désactiver la carte de paiement virtuelle, de 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 à un domaine de sécurité supplémentaire 11, 21. / Une interface 9 (dénommée 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 réalisée par l'utilisateur, l'IHM Banque correspondante. L'interface 9 est apte à dialoguer avec un module 6 de listage des applications, hébergé dans la carte UICC, par exemple dans le domaine ISD. On a également représenté sur la figure 2 le système d'exploitation 30 de la carte 2 lequel met notamment en oeuvre une interface de contrôleur NFC et un environnement répondant aux spécifications GlobalPlatform . Dans le cadre de l'invention un module de gestion comprend : un espace mémoire stockant un code de référence commun aux applications de paiement du groupe et un indicateur de vérification du code personnel ; des moyens pour confronter le code de référence avec un code personnel saisi via l'interface IHM Banque correspondante; des moyens configurés pour renseigner l'indicateur en cas de confrontation positive et pour réinitialiser l'indicateur suite à la fermeture ou à la finalisation d'une session de paiement mise en oeuvre avec une application du groupe ; des moyens formant interface commune permettant de rendre accessible l'indicateur aux applications du groupe. Le module de gestion offre ainsi aux différentes applications du groupe un service de vérification du code personnel. Selon un mode de réalisation possible, le module de gestion peut en outre être configuré pour offrir aux différentes applications du groupe un service d'agrégation et de mise à disposition de l'utilisateur (typiquement via l'IHM Banque correspondante) des transactions de paiement archivées au niveau de chaque application de paiement. Le module de gestion peut en particulier être configuré de manière à ajouter à l'enregistrement d'une transaction l'identifiant de l'application de paiement concernée de manière à permettre à l'IHM Banque d'identifier les paiements (par exemple paiements locaux, paiements internationaux, etc.). 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, 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 A va entraîner le lancement de l'IHM Banque 10, tandis que la sélection de la solution de paiement offerte par la Banque B 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és : activation/désactivation de la solution, saisie de code personnel, changement de code personnel, consultation d'un historique de transaction, etc. L'utilisateur choisit ainsi 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 B. En référence à la figure 3, et selon une réalisation possible de la présente invention, une fois l'application de paiement activée, cette dernière reste en attente d'une communication sans contact avec un terminal de paiement sans contact (étape 300).
Ainsi, lorsque l'utilisateur U veut réaliser une transaction (également dénommée session de paiement dans ce qui suit) par exemple pour régler ses achats, il initialise une session de paiement en établissant une communication entre son appareil mobile 1 et un terminal de paiement sans contact en mettant son appareil mobile à proximité du terminal de paiement.
Le module NFC de l'appareil mobile 3 rentrant dans la zone de communication du terminal de paiement sans contact, une communication est établie entre le terminal de paiement et l'application de paiement de l'appareil mobile, permettant à ladite application de récupérer les informations nécessaires à la transaction.
Dans le cadre de ce mode de réalisation, l'initialisation de la session de paiement peut mettre en oeuvre une sélection de l'application de paiement par le terminal de paiement parmi la ou les applications de paiement actives. C'est notamment le cas lorsqu'un groupe d'applications est actif, par exemple lorsque le groupe est formé d'une application de paiement locale et d'une application de paiement internationale. Le terminal de paiement est alors avisé des identifiants des applications actives, et choisit selon des règles connues en soi, l'application active avec laquelle la transaction doit être réalisée (par exemple l'application internationale lorsque l'utilisateur se trouve à l'étranger). Afin de s'assurer de l'identité de l'utilisateur U, un code personnel d'identification (PIN) est demandé à ce dernier. Une fois le code d'identification saisi et vérifié (étape 302), un compteur de temps 303 est lancé avec en paramètre une limite de temps 307 prédéterminée. Selon un mode de réalisation possible, l'application de paiement devant être utilisée pour la réalisation de la session de paiement transmet, par exemple après détermination qu'une vérification d'un code personnel est nécessaire, au module de gestion à laquelle elle est associée un événement permettant de réveiller l'IHM Banque avec un paramètre correspondant à une requête de vérification de code personnel. En référence à la figure 5, l'exécution du compteur de temps est initiée par le module de gestion 22. Pour ce faire, ce dernier envoie à l'IHM Banque 20 les informations nécessaires à l'activation du compteur de temps via une communication 50. Par exemple, il peut être prévu que le module de gestion 22 envoie à l'IHM Banque les informations relatives à la limite de temps liée au compteur de temps. Ainsi, l'IHM Banque 20 exécute le compteur de temps et la surveillance de la limite de temps sous ordre du module de gestion 22. L'IHM Banque invite alors l'utilisateur à rentrer son code personnel (par exemple à travers un message affiché sur un moyen d'affichage 201 de l'appareil mobile, tel qu'un écran LCD). Une fois le code rentré par l'utilisateur à l'aide par exemple d'un clavier alphanumérique 202 de l'appareil mobile 1, l'IHM Banque 20 envoie au module de gestion 22 une commande de vérification 54 du code rentré par l'utilisateur. En cas de succès de la vérification opérée par le module de gestion (le code saisi par l'utilisateur étant confronté à un code stocké dans le module de gestion 22), le module de gestion 22 enregistre le résultat de cette vérification par exemple en renseignant un indicateur de vérification du code personnel 222 indiquant l'état de vérification du code personnel (par exemple, la valeur de cet indicateur, par défaut à 0, est alors fixée à 1, signifiant alors que le code rentré par l'utilisateur a bien été vérifié et qu'une transaction peut être finalisée). Une fois le code vérifié avec succès, le module de gestion 22 signale à l'IHM Banque 20 le succès de cette vérification via une communication 58, afin qu'avantageusement l'IHM Banque 20 puisse le notifier à l'utilisateur via le moyen d'affichage 201. Durant l'activité du compteur de temps et avant que la limite de temps ne soit dépassée, l'utilisateur doit en principe ré-effectuer une communication entre l'appareil mobile et le terminal de paiement afin de finaliser la transaction, en approchant l'appareil mobile 1 du terminal de paiement. Dans le cas où une telle communication n'est pas effectuée (étape 305), l'IHM Banque 20 signale au module de gestion le dépassement de la limite de temps via une communication 56. En conséquence de cette communication, le module de gestion 22 fixe la valeur de l'indicateur de vérification du code personnel 222 à 0, signifiant que le code n'est plus considéré comme vérifié et qu'en conséquence la transaction en cours est annulée (étape 306 : fermeture de la session de paiement avec réinitialisation de son contexte, en particulier l'indicateur 222) tandis que l'application reste active (retour à l'étape 300) de manière à pouvoir être directement réutilisée pour une transaction ultérieure. Si au contraire une telle communication entre l'appareil mobile 1 et le terminal de paiement est effectuée (étape 304) avant le dépassement de la limite de temps, la transaction en cours est finalisée avec le terminal de paiement (l'application de paiement vient pour cela lire la valeur de l'indicateur 222 ; si ce dernier est renseigné - par exemple à la valeur 1 û la vérification du code personnel a été réalisée avec succès et la session de paiement peut alors se finaliser). L'indicateur de vérification du code personnel 222 est ensuite réinitialisé (sa valeur est par exemple fixée à 0), signifiant que le code personnel n'est plus considéré comme vérifié, et l'application de paiement se réinitialise (retour à l'étape 300) en attente d'une communication ultérieure avec un lecteur extérieur. On comprend ainsi que d'une part la communication avec l'extérieur de l'appareil mobile est sécurisée par la saisie et la vérification du code personnel et par un compteur de temps, garant d'une limite de validité du code personnel et d'autre part, le fait que l'application reste activée même lorsque la limite de temps est dépassée permettant de démarrer toute nouvelle transaction sans nécessité une activation manuelle de l'application. Ainsi un tel procédé permet d'offrir une sécurisation de l'application de paiement dans le cas où cette dernière reste activée en permanence (mode always on ). Une telle sécurisation est rendue possible notamment par le fait que le démarrage du compteur de temps n'est pas assujetti à l'activation de l'application de paiement. Il peut être également prévu que la valeur de l'indicateur 222 soit fixée à 0 lorsque l'utilisateur annule la transaction en cours (par exemple en désactivant l'application de paiement). Afin de garantir un meilleur niveau de sécurité, il est prévu des moyens de contrôle permettant de vérifier les commandes 54 et 56 (permettant respectivement de faire vérifier le code rentré par l'utilisateur et de signaler le dépassement de la limite de temps au module de gestion 22) soient bien envoyées par l'IHM Banque, seule entité autorisée à envoyer de telles communications. Par ailleurs, une méthode de chiffrement peut être mise en oeuvre afin d'assurer la confidentialité des communications entre une application de paiement et le module de gestion auquel elle est associée.
En référence à la figure 4, et selon une autre réalisation possible de la présente invention, une fois l'application de paiement activée, cette dernière reste en attente d'une invitation par l'utilisateur U à démarrer une transaction (étape 400). Dans le cadre de ce mode de réalisation, l'initialisation de la session de paiement fait suite à la sélection, via l'interface 20, par un utilisateur de l'appareil, de l'application de paiement parmi la ou les applications actives. Ainsi, lorsque l'utilisateur U veut réaliser une transaction par exemple pour régler ses achats, il indique à l'IHM Banque 20 (par exemple via le clavier alphanumérique 202) de son appareil mobile 1 son intention d'effectuer une transaction et, après une invitation de ladite interface, rentre son code personnel (PIN). Une fois le code d'identification entré et vérifié de la manière décrite précédemment (étape 401), un compteur de temps 403 est lancé avec en paramètre une limite de temps 404 prédéterminée. Ainsi l'utilisateur U, voulant finaliser la transaction, dispose de cette limite de temps pour établir une communication sans contact entre son appareil mobile 1 et un terminal de paiement en mettant son appareil mobile à proximité du terminal de paiement. L'exécution du compteur de temps est similaire à celui décrit précédemment et est initiée par le module de gestion 22. Si une communication n'est pas effectuée avant le dépassement de la limite de temps (étape 405), la transaction en cours est annulée (étape 406) au sein de l'application de paiement, la valeur de l'indicateur 222 est fixée à 0, et l'application est réinitialisée tout en restant toujours active (retour à l'étape 400). Si au contraire une telle communication est effectuée (étape 407) avant le dépassement de la limite de temps, la transaction en cours est finalisée avec le terminal de paiement 3, la valeur de l'indicateur 222 est fixée à 0, et l'application de paiement se réinitialise (retour à l'étape 400) en attente d'une communication sans contact avec un lecteur extérieur. De la même manière que précédemment, durant cette communication, le module NFC du téléphone 3 rentrant dans la zone de communication du terminal de paiement (POS), une communication est établie entre le terminal de paiement et l'application de paiement, permettant à ce dernier de récupérer les informations nécessaires à la transaction. D'autres modes de réalisation et modifications peuvent être ajoutées à la présente invention sans toutefois sortir de son cadre.
Notamment, selon une réalisation possible de la présente invention, il est prévu que le dépassement de la limite de temps implique la fermeture de l'IHM Banque (tant en conservant l'application de paiement active de manière à pouvoir être réutilisée pour une transaction ultérieure). A titre d'exemple illustratif, la limite de temps est fixée à 1 minute.30 L'invention concerne un module de gestion destiné à être associé à un groupe d'une ou plusieurs applications de paiement embarquées dans un appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, chaque application de paiement pouvant être mise en oeuvre dans le cadre d'une session de paiement sans contact entre le lecteur externe et l'appareil, caractérisé en ce qu'il comporte • un espace mémoire stockant un code de référence commun aux applications de paiement du groupe et un indicateur de vérification du code personnel ; • des moyens pour confronter un code personnel saisi via une interface utilisateur au code de référence ; • des moyens configurés pour renseigner l'indicateur en cas de confrontation positive et pour réinitialiser l'indicateur suite à la fermeture ou à la finalisation d'une session de paiement mise en 15 oeuvre avec une application du groupe ; • des moyens formant interface commune permettant de rendre accessible l'indicateur aux applications du groupe.
L'invention concerne également une carte à puce destinée à être utilisée dans un 20 appareil à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, comprenant au moins un groupe d'une ou plusieurs applications de paiement pouvant être sélectionné pour que l'une des applications du groupe puisse être utilisée pour mettre en oeuvre une session de paiement entre. l'appareil et le lecteur externe, caractérisée en ce qu'elle comporte un module de gestion 25 conforme à l'invention associé à chaque groupe.
L'invention concerne également un appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, embarquant une carte à puce selon l'invention.

Claims (10)

  1. REVENDICATIONS1. Procédé pour la gestion d'une application de paiement sans contact active embarquée au sein d'un appareil apte à établir une communication sans contact avec un terminal de paiement sans contact, comprenant les étapes suivantes : ù suite à l'initialisation (300, 400) d'une session de paiement mettant en oeuvre l'application de paiement sans contact, saisie d'un code personnel (302, 401) via une interface (20) ; ù vérification du code personnel saisi par un module de gestion associé à un groupe d'une ou plusieurs applications comprenant l'application mise en oeuvre dans la session de paiement, et en cas de vérification positive, renseignement par le module de gestion d'un indicateur de vérification du code personnel (222) ; ù lecture de l'indicateur par l'application et finalisation de la session de paiement si l'indicateur est renseigné ù réinitialisation de l'indicateur une fois la session finalisée.
  2. 2. Procédé selon la revendication précédente, comprenant les étapes suivantes mises en oeuvre en cas de vérification positive du code personnel : ù démarrage d'un compteur de temps (302, 401) ; ù dans le cas où la session de paiement n'est pas finalisée une fois une limite de temps prédéterminée (307, 404) atteinte par le compteur, fermeture de la session de paiement tandis que l'application reste active de manière à pouvoir directement être mise en oeuvre pour une nouvelle session de paiement.
  3. 3. Procédé selon l'une des revendications 1 à 2, dans lequel l'initialisation de la session de paiement fait suite à une étape (301) de communication sans contact entre l'appareil et un terminal de paiement (POS).
  4. 4. Procédé selon la revendication 3, dans lequel l'initialisation de la session de paiement met en oeuvre une sélection de l'application de paiement par le terminal de paiement parmi la ou les applications de paiement actives.
  5. 5. Procédé selon l'une des revendications 1 à 4, dans lequel l'initialisation de la session de paiement fait suite à la sélection, via l'interface (20), par un utilisateur de l'appareil, de l'application de paiement parmi la ou les applications de paiement actives.
  6. 6. Procédé selon l'une des revendications précédentes, comprenant en outre les étapes suivantes : une fois le code saisi, envoi par l'interface (20), à destination du module de gestion (22) associé au groupe d'une ou plusieurs applications de paiement sans contact comprenant l'application destinée à être mise en oeuvre dans la session de paiement, d'une commande de vérification (54) du code saisi ; vérification du code saisi par le module de gestion (22) ; en cas de succès de la vérification, envoi par le module de gestion (22) à l'interface (20) d'une commande de démarrage de compteur de temps.
  7. 7. Procédé selon la revendication 6, dans lequel le module de gestion réinitialise l'indicateur de vérification du code personnel (222) suite à la fermeture ou à la finalisation de la session de paiement.
  8. 8. Module de gestion destiné à être associé à un groupe d'une ou plusieurs applications de paiement embarquées dans un appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, chaque application de paiement pouvant être mise en oeuvre dans le cadre d'une session de paiement sans contact entre le lecteur externe et l'appareil, caractérisé en ce qu'il comporte • un espace mémoire stockant un code de référence commun aux applications de paiement du groupe et un indicateur de vérification du code personnel ; • des moyens pour confronter un code personnel saisi via une interface utilisateur au code de référence ; • des moyens configurés pour renseigner l'indicateur en cas de confrontation positive et pour réinitialiser l'indicateur suite à la fermeture ou à la finalisation d'une session de paiement mise en oeuvre avec une application du groupe ; • des moyens formant interface commune permettant de rendre accessible l'indicateur aux applications du groupe.
  9. 9. Carte à puce destinée à être utilisée dans un appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, comprenant au moins un groupe d'une ou plusieurs 20 applications de paiement pouvant être sélectionné pour que l'une des applications du groupe puisse être utilisée pour mettre en oeuvre une session de paiement entre l'appareil et le lecteur externe, caractérisée en ce qu'elle comporte un module de gestion conforme à la revendication précédente associé à chaque groupe. 25
  10. 10. Appareil apte à communiquer par l'intermédiaire d'une liaison sans contact avec un lecteur externe, embarquant une carte à puce selon la revendication précédente. 10 15
FR0952960A 2009-05-04 2009-05-04 Procede et systeme de gestion d'une application de paiement mobile sans contact mettant en oeuvre une verification de code personnel Expired - Fee Related FR2945141B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0952960A FR2945141B1 (fr) 2009-05-04 2009-05-04 Procede et systeme de gestion d'une application de paiement mobile sans contact mettant en oeuvre une verification de code personnel

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0952960A FR2945141B1 (fr) 2009-05-04 2009-05-04 Procede et systeme de gestion d'une application de paiement mobile sans contact mettant en oeuvre une verification de code personnel

Publications (2)

Publication Number Publication Date
FR2945141A1 true FR2945141A1 (fr) 2010-11-05
FR2945141B1 FR2945141B1 (fr) 2012-07-06

Family

ID=41376389

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0952960A Expired - Fee Related FR2945141B1 (fr) 2009-05-04 2009-05-04 Procede et systeme de gestion d'une application de paiement mobile sans contact mettant en oeuvre une verification de code personnel

Country Status (1)

Country Link
FR (1) FR2945141B1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2503496A1 (fr) * 2011-03-24 2012-09-26 Danal Co., Ltd. Procédé de système de contrôle et dispositif mobile pour le traitement de paiements et de données
EP2595417A1 (fr) * 2011-11-17 2013-05-22 Oberthur Technologies Procede de selection d'une application dans un terminal, et terminal mettant en oeuvre ce procede.
EP2698756A1 (fr) * 2012-08-13 2014-02-19 Nxp B.V. Gestionnaire de service fiabilisé local
WO2015158618A1 (fr) * 2014-04-18 2015-10-22 Ingenico Group Procédé de traitement de données transactionnelles, dispositif et programme correspondant

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030006280A1 (en) * 2001-06-27 2003-01-09 Kazuhisa Seita Portable terminal apparatus with IC card function
US20050006461A1 (en) * 2003-07-11 2005-01-13 Gavin Shenker System and method for managing electronic data transfer applications
EP1553530A1 (fr) * 2003-12-15 2005-07-13 Matsushita Electric Industrial Co., Ltd. Un dispositif sécurisé et appareil de traitement d'informations
WO2006095212A1 (fr) * 2005-03-07 2006-09-14 Nokia Corporation Procede et dispositif terminal mobile comprenant un module de carte a puce et un dispositif de communications en champ proche
FR2892261A1 (fr) * 2005-10-17 2007-04-20 France Telecom Procede et systeme de gestion des applications d'un terminal mobile
WO2008086421A1 (fr) * 2007-01-09 2008-07-17 Visa U.S.A. Inc. Règlement de téléphone mobile comportant une caractéristique de mise hors service

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030006280A1 (en) * 2001-06-27 2003-01-09 Kazuhisa Seita Portable terminal apparatus with IC card function
US20050006461A1 (en) * 2003-07-11 2005-01-13 Gavin Shenker System and method for managing electronic data transfer applications
EP1553530A1 (fr) * 2003-12-15 2005-07-13 Matsushita Electric Industrial Co., Ltd. Un dispositif sécurisé et appareil de traitement d'informations
WO2006095212A1 (fr) * 2005-03-07 2006-09-14 Nokia Corporation Procede et dispositif terminal mobile comprenant un module de carte a puce et un dispositif de communications en champ proche
FR2892261A1 (fr) * 2005-10-17 2007-04-20 France Telecom Procede et systeme de gestion des applications d'un terminal mobile
WO2008086421A1 (fr) * 2007-01-09 2008-07-17 Visa U.S.A. Inc. Règlement de téléphone mobile comportant une caractéristique de mise hors service

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2503496A1 (fr) * 2011-03-24 2012-09-26 Danal Co., Ltd. Procédé de système de contrôle et dispositif mobile pour le traitement de paiements et de données
EP2595417A1 (fr) * 2011-11-17 2013-05-22 Oberthur Technologies Procede de selection d'une application dans un terminal, et terminal mettant en oeuvre ce procede.
FR2983027A1 (fr) * 2011-11-17 2013-05-24 Oberthur Technologies Procede de selection d'une application dans un terminal, et terminal mettant en oeuvre ce procede
US9386403B2 (en) 2011-11-17 2016-07-05 Oberthur Technologies Selection process for an application in a terminal using local information obtained from a secure module
RU2643788C2 (ru) * 2011-11-17 2018-02-06 Обертур Техноложи Способ выбора терминалом приложения для выполнения защищенным модулем, терминал, защищенный модуль и носитель информации
EP2698756A1 (fr) * 2012-08-13 2014-02-19 Nxp B.V. Gestionnaire de service fiabilisé local
CN103593621A (zh) * 2012-08-13 2014-02-19 Nxp股份有限公司 本地可信服务管理器
US9473932B2 (en) 2012-08-13 2016-10-18 Nxp B.V. Local trusted service manager
CN103593621B (zh) * 2012-08-13 2017-04-26 Nxp股份有限公司 用于管理安全元件的方法、安全元件和移动通信装置
WO2015158618A1 (fr) * 2014-04-18 2015-10-22 Ingenico Group Procédé de traitement de données transactionnelles, dispositif et programme correspondant
FR3020165A1 (fr) * 2014-04-18 2015-10-23 Ingenico Sa Procede de traitement de donnees transactionnelles, dispositif et programme correspondant
US10915893B2 (en) 2014-04-18 2021-02-09 Ingenico Group Method for processing transaction data, device and corresponding program

Also Published As

Publication number Publication date
FR2945141B1 (fr) 2012-07-06

Similar Documents

Publication Publication Date Title
CA2971635C (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
EP3168769B1 (fr) Procédé d'aide à l'authentification d'un utilisateur, serveur et programme d'ordinateur correspondants
CA2946143C (fr) Procede de traitement de donnees transactionnelles, dispositif et programme correspondant
EP3189485A1 (fr) Gestion de ticket électronique
FR2980891A1 (fr) Procede et systeme de signalisation de paiement, application a la location automatisee de vehicules.
FR2987199A1 (fr) Securisation d'une transmission de donnees.
FR2945141A1 (fr) Procede et systeme de gestion d'une application de paiement mobile sans contact mettant en oeuvre une verification de code personnel
FR2945143A1 (fr) Procede et systeme d'activation d'applications de paiement sans contact
EP3384449A1 (fr) Methode de paiement et dispositif utilisant cette methode
EP3215991A1 (fr) Transaction simplifiee a l'aide d'un dispositif de paiement et d'un terminal de communication
FR3023640A1 (fr) Procede de gestion d'une transaction, serveur, produit programme d'ordinateur et medium de stockage correspondants.
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
EP2933767A1 (fr) Procédé de désactivation d'un module de paiement, produit programme d'ordinateur, medium de stockage et module de paiement correspondants
WO2013098238A1 (fr) Procédé et système de sécurisation d'un paiement réalisé à l'aide d'une carte de paiement
EP2306414A1 (fr) Procédé de communication entre un lecteur et deux cartes à puce
CA2434192A1 (fr) Systeme et methode de renouvellement de donnees d'identification sur un dispositif de transaction portatif
EP3391316A1 (fr) Procédé de sécurisation d'une transaction depuis un terminal mobile
EP3371760A1 (fr) Procédé de verification d'identité lors d'une virtualisation
FR3031609A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
FR3031608A1 (fr) Methode de traitement d'une autorisation de mise en œuvre d'un service, dispositifs et programme d'ordinateur correspondant
FR2985340A1 (fr) Procede et systeme de securisation d'un paiement realise a l'aide d'une carte de paiement notamment bancaire
FR2945142A1 (fr) Procede et systeme de reinitialisation d'un compteur d'une application de paiement mobile sans contact
FR2963975A1 (fr) Systeme de paiement en ligne

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140131