La présente invention concerne un procédé et un système de transaction à champ proche.

Ces dernières années l'apparition des techniques de communication sans contact par couplage inductif, également appelées techniques de communication à champ proche NFC ("Near Field Communication"), ont transformé le monde de la carte à puce en permettant dans un premier temps de réaliser des cartes de paiement sans contact puis, dans un second temps, d'intégrer un processeur sécurisé et un contrôleur NFC dans des objets portables électroniques tels les téléphones mobiles, pour conduire des transactions à champ proche au moyen de ces derniers.

La figure 1 représente schématiquement un système de transaction classique comprenant une carte à puce sans contact CC1 et un terminal de transaction TT. Le terminal TT est par exemple un point de retrait d'argent, un point de vente de produits (distributeur de tickets, distributeur de produits consommables,...), un terminal de contrôle d'accès payant avec débit automatique (borne d'accès au métro, borne de paiement d'autobus, etc.).

La carte sans contact CC1 comprend un circuit intégré sans contact CIC ("Contactless Integrated Circuit") équipé d'un processeur sécurisé et d'une bobine d'antenne AC1 connectée au circuit intégré. Le terminal TT comprend lui-même une bobine d'antenne AC2 et est configuré pour conduire une transaction à champ proche avec la carte CC1 en émettant un champ magnétique FLD. La transaction comprend l'échange d'unités de données de protocole d'application APDU ("Application Protocol Data Unit"). Les données de protocole d'application comprennent des commandes CAPDU envoyées par le terminal et des réponses RAPDU envoyées par la carte. Le terminal TT peut se relier en temps réel ou en temps différé à un serveur de transaction SVO, pour valider un paiement et/ou débiter un compte de l'utilisateur.

La figure 2 représente schématiquement un système de transaction comprenant un téléphone mobile HD1 et le terminal de transaction TT. Le téléphone HD1 comporte un processeur principal PROC1 , un circuit de radiocommunication RCCT, un processeur sécurisé PROC2 de carte SIM ("Subscriber Identity Module"), un contrôleur NFC désigné "NFCC", une bobine d'antenne AC3 reliée au contrôleur NFCC et un processeur sécurisé PROC3 configuré pour conduire des transactions NFC.

Le processeur PROC3 comprend une unité centrale de traitement CPU, un système d'exploitation OS, un programme application carte CAP ("Card Application") et/ou un programme application lecteur RAP ("Reader application"). Le processeur PROC3 est relié au contrôleur NFCC par un bus BS1 , par exemple un bus SWP ("Single Wire Protocol"). En pratique, le processeur PROC3 peut prendre la forme d'une carte à circuit intégré UICC ("Universal Integrated Circuit Card"), par exemple de type mini-SIM ou micro-SIM.

Un exemple d'architecture fonctionnelle du contrôleur NFCC et du processeur PROC3 est représenté sur la figure 3. Le contrôleur NFCC comprend un contrôleur hôte HC et une interface sans contact CLF ("Contactless Front End Interface") qui est reliée à la bobine d'antenne AC3. En pratique, le contrôleur hôte HC et l'interface CLF peuvent être intégrés dans la même puce de semiconducteur, telle la puce MicroRead® commercialisée par la demanderesse.

Le bus BS1 reliant le processeur PROC3 et le contrôleur NFCC sert de support physique à une interface de communication dite "HCI" ("Host Controller Interface") par l'intermédiaire de laquelle le contrôleur NFCC et le processeur PROC3 échangent des données conformément à un protocole dit "HCP" ("Host Controller Protocol"). L'interface HCI et le protocole HCP sont décrits dans les spécifications ETSI TS 102 622 de l'Institut Européen des Normes de Télécommunication, intitulées "Smart Cards ; Universal Integrated Circuit Card (UICC) ; Contactless Front-end (CLF) interface ; Host Controller Interface (HCI)". Le protocole HCP prévoit un routage des données selon des canaux de routage appelés "pipes" ("tuyaux"), par l'intermédiaire desquels des données de protocole d'application APDU sont échangées au cours d'une transaction entre le processeur PROC3 et terminal de transaction TT. L'interface CLF peut généralement opérer selon plusieurs technologies RF désignées "RFTi" sur la figure 3, par exemple "Type A" ou "Type B" telles que définies par ISO/IEC 14443 parties 2, 3 et 4, "Type B'" telle que définie par ISO/IEC 14443-2, avec un tramage normalisé ("standard framing") tel que défini par ISO/IEC 14443-3, et "Type F" telle que définie par ISO 18092 en tant que mode passif à 212 et 424 kilooctets par seconde) ou par la norme industrielle japonaise JIS X 6319-4.

Lors de l'exécution de l'application carte CAP, le processeur PROC3 émule une carte sans contact et utilise le contrôleur NFCC en mode passif pour conduire une transaction avec un terminal de transaction TT qui émet le champ magnétique FLD. Un canal P1 est tout d'abord ouvert entre l'application carte CAP et l'interface CLF du contrôleur NFCC, qui est configurée à cette occasion dans une technologie RFTi. Le terminal TT envoie au contrôleur NFCC des commandes CAPDU que ce dernier transmet au processeur PROC3 par l'intermédiaire du canal P1 . Le processeur PROC3 émet des réponses RAPDU qui sont transmises au contrôleur NFCC par l'intermédiaire du canal P1 , puis sont transmises au terminal TT par le contrôleur NFCC, par l'intermédiaire d'un canal RF.

Lors de l'exécution de l'application lecteur RAP, le processeur PROC3 conduit une transaction avec un circuit intégré sans contact CIC agencé dans une carte sans contact CC1 ou autre support. Le contrôleur NFCC est dans un mode de fonctionnement actif où il émet un champ magnétique FLD. Un canal P1 est tout d'abord ouvert entre l'application lecteur RAP et l'interface CLF du contrôleur NFCC, qui est configurée à cette occasion dans une technologie RFTi. L'application lecteur RAP émet ensuite des commandes CAPDU qui sont transmises au contrôleur NFCC par l'intermédiaire du canal P2 puis sont transmises au circuit intégré CIC par l'intermédiaire d'un canal RF. Le circuit intégré sans contact CIC renvoie au contrôleur NFCC des réponses RAPDU que ce dernier transmet au processeur PROC3 par l'intermédiaire du canal P2.

Il est connu que le développement de la technologie NFC est étroitement lié au développement des applications carte dans les dispositifs portables tels les téléphones mobiles, afin d'utiliser de tels dispositifs portables comme des cartes à puce sans contact. Bien que des infrastructures équipées de terminaux de transaction NFC existent déjà, notamment dans le domaine du paiement, l'intégration de processeurs sécurisés dans les téléphones mobiles pour exécuter de telles applications ne s'effectue pas à une cadence suffisante pour permettre le développement espéré de la technologie NFC.

Une contrainte qui freine ce développement est la complexité et le coût d'un processeur sécurisé tel que le processeur PROC3 représenté sur les figures 2 et 3. Celui-ci doit de préférence pouvoir exécuter diverses applications carte et doit donc contenir autant de clés bancaires (clés de cryptographie) que d'applications carte fournies par des banques différentes. Il doit de plus présenter une puissance de calcul suffisante pour réaliser des calculs cryptographique complexes pendant la phase d'authentification d'une transaction. De plus, la personnalisation du processeur, c'est-à-dire le chargement d'une application carte CAP dans sa mémoire, est une opération complexe devant être hautement sécurisée et nécessitant des intervenants externes tels qu'un Gestionnaire de Service de Confiance "TSM" ("Trusted Service Manager"). Enfin, en cas de vol du téléphone ou pendant une opération de maintenance du téléphone, le processeur PROC3 est susceptible d'attaque par un fraudeur afin de découvrir les clés bancaires qu'il comporte.

II pourrait donc être souhaité de prévoir un procédé permettant de conduire une transaction NFC au moyen d'un dispositif portable de type téléphone mobile ayant une architecture plus simple et moins coûteuse à mettre en œuvre que les architectures connues.

Des modes de réalisation de l'invention concernent un procédé pour conduire une transaction entre un dispositif portable et un terminal de transaction, comprenant les étapes consistant à prévoir au moins un serveur de transaction relié au terminal de transaction par des moyens informatiques et comprenant au moins un programme application configuré pour conduire une transaction avec le terminal de transaction pour le compte du dispositif portable, établir un canal de communication à champ proche entre le dispositif portable et le terminal de transaction et fournir au terminal de transaction, au moyen du dispositif portable, des informations d'application et de transaction, établir une première liaison de données entre le terminal de transaction et le serveur, sans passer par le dispositif portable, en utilisant les informations d'application et de transaction, et utiliser le programme application dans le serveur pour conduire la transaction avec le terminal de transaction par l'intermédiaire de la première liaison de données, pour le compte du dispositif portable, la transaction comprenant l'envoi au programme application du serveur, par le terminal de transaction, de premières données de protocole d'application, et l'envoi au terminal de transaction, par le programme application du serveur et pour le compte du dispositif portable, de secondes données de protocole d'application.

Selon un mode de réalisation, les informations d'application et de transaction comprennent des données d'identification du dispositif portable.

Selon un mode de réalisation, le procédé comprend l'étape consistant à activer le programme application dans le serveur et le relier au terminal de transaction par l'intermédiaire de la première liaison de données pour qu'il conduise la transaction pour le compte du dispositif portable.

Selon un mode de réalisation, une information relative au programme application à activer est incluse dans les informations d'application et de transaction fournie au serveur par l'intermédiaire de la première liaison de données.

Selon un mode de réalisation, le procédé comprend les étapes consistant à établir une seconde liaison de données entre le dispositif portable et le serveur, sans passer par le terminal de transaction, et fournir au serveur, par l'intermédiaire de la seconde liaison de données, une information relative au programme application à activer.

Selon un mode de réalisation, le procédé comprend l'étape consistant à fournir au serveur une information relative à une durée pendant laquelle le programme application peut être activé.

Selon un mode de réalisation, le procédé comprend les étapes consistant à fournir au serveur des données d'identification d'un utilisateur, et configurer le serveur pour qu'il refuse d'exécuter la transaction pour le compte du dispositif portable si les données d'identification sont erronées.

Des modes de réalisation concernent également un système de transaction comprenant un dispositif portable, un terminal de transaction, et au moins un serveur de transaction relié au terminal de transaction par des moyens informatiques, le dispositif portable et le terminal de transaction comprenant des moyens de communication à champ proche, dans lequel le serveur comprend au moins un programme application configuré pour conduire une transaction avec le terminal de transaction pour le compte du dispositif portable, le dispositif portable est configuré pour établir un canal de communication à champ proche avec le terminal de transaction, et fournir au terminal de transaction des informations d'application et de transaction, le terminal de transaction est configuré pour établir une première liaison de données entre le terminal de transaction et le serveur de transaction, sans passer par le dispositif portable, et le serveur de transaction est configuré pour utiliser le programme application pour conduire la transaction avec le terminal de transaction par l'intermédiaire de la première liaison de données, pour le compte du dispositif portable, la transaction comprenant l'envoi au programme application du serveur, par le terminal de transaction, de premières données de protocole d'application, et l'envoi au terminal de transaction, par le programme application du serveur et pour le compte du dispositif portable, de secondes données de protocole d'application.

Selon un mode de réalisation, les informations d'application et de transaction comprennent des données d'identification du dispositif portable.

Selon un mode de réalisation, le serveur de transaction est configuré pour activer le programme application et le relier au terminal de transaction par l'intermédiaire de la première liaison de données pour qu'il conduise la transaction pour le compte du dispositif portable.

Selon un mode de réalisation, le dispositif portable est configuré pour inclure dans les informations d'application et de transaction une information relative au programme application à activer. Selon un mode de réalisation, le dispositif portable est configuré pour établir une seconde liaison de données avec le serveur de transaction, sans passer par le terminal de transaction, et fournir au serveur, par l'intermédiaire de la seconde liaison de données, une information relative au programme application à activer.

Selon un mode de réalisation, le dispositif portable est configuré pour fournir au serveur une information relative à une durée pendant laquelle le programme application peut être activé.

Selon un mode de réalisation, le dispositif portable est configuré pour fournir au serveur des données d'identification d'un utilisateur, et le serveur est configuré pour refuser d'exécuter la transaction pour le compte du dispositif portable si les données d'identification sont erronées.

Selon un mode de réalisation, le terminal de transaction reçoit les informations d'application et de transaction en les lisant dans un registre ou une mémoire du dispositif portable.

Des modes de réalisation d'un système et d'un procédé de transaction selon l'invention seront décrits à titre non limitatif en relation avec les figures jointes, parmi lesquelles :

- la figure 1 précédemment décrite représente un système de transaction NFC classique comprenant une carte à puce sans contact,

- la figure 2 précédemment décrite représente un système de transaction NFC classique comprenant un dispositif portable équipé d'un processeur de transaction sécurisé,

- la figure 3 précédemment décrite est un schéma fonctionnel du système de transaction de la figure 2,

- la figure 4 représente un mode de réalisation d'un système de transaction NFC,

- la figure 5 montre des étapes d'une transaction NFC réalisée au moyen du système de la figure 4,

- la figure 6 montre plus en détail certaines étapes de la transaction,

- la figure 7 montre un mode de réalisation d'un procédé de déclaration d'un utilisateur auprès du système de transaction de la figure 4, - la figure 8 montre un mode de réalisation d'un procédé d'activation d'une application avant sa mise en œuvre dans le système de transaction représenté sur la figure 4,

- la figure 9 représente un autre mode de réalisation d'un système de transaction NFC,

- la figure 10 montre des étapes d'une transaction NFC réalisée au moyen du système de la figure 9,

- la figure 1 1 représente un mode de réalisation d'un système de transaction NFC selon l'invention, et

- la figure 12 montre des étapes d'un mode de réalisation d'un procédé de transaction NFC selon l'invention réalisé au moyen du système de la figure 1 1 .

La figure 4 représente un mode de réalisation d'un système de transaction. Le système comprend un terminal TT de transaction, un dispositif portable HD2 et un serveur de transaction SV1 connecté au réseau Internet.

Le terminal TT, équipé d'une bobine d'antenne AC2, est configuré pour conduire une transaction NFC avec une carte sans contact NFC telle que celle représentée en figure 1 ou un dispositif HD1 tel que celui représenté en figure 2.

Le dispositif HD2 comprend un processeur principal PROC1 , un afficheur DP, un clavier KB (pouvant être virtuel et présenté par l'afficheur), un contrôleur NFC "NFCC" équipé d'une bobine d'antenne AC3 pour établir une communication à champ proche avec le terminal TT, et un circuit de communication sans fil WCCT pour permettre au dispositif HD2 de se connecter au réseau Internet INW.

Le dispositif HD2 peut être un téléphone, un PDA (Assistant Personnel), un lecteur de fichiers MP3, ou tout autre dispositif portable équipé de moyens de connexion au réseau Internet. S'il forme un téléphone, le dispositif HD2 comporte également un processeur sécurisé PROC2 de carte SIM autorisant l'abonné à utiliser le réseau téléphonique GSM. Le circuit WCCT peut être un circuit de radiotéléphonie permettant une connexion au réseau Internet via le réseau GSM, par exemple une connexion LTE ("Long Term Evolution") ou GSM 4G, une carte Wifi, ou tout autre moyen de connexion sans fil au réseau Internet. Le processeur PROC1 peut être le processeur principal du dispositif HD2, par exemple un processeur bande de base si le dispositif HD2 est un téléphone mobile, ou un processeur auxiliaire. Le processeur PROC1 comprend une unité centrale de traitement CPU, une interface de communication ILR, un système d'exploitation OS1 .

Le circuit d'interface de communication ILR, représenté schématiquement sous forme de bloc, comprend l'ensemble des ports de connexion du processeur et des couches logicielles de gestion de protocoles de communication correspondants.

Le processeur PROC1 est relié au contrôleur NFCC, au processeur

PROC2, au circuit WCCT, au clavier KB et à l'afficheur DP par l'intermédiaire du circuit d'interface ILR. Plus particulièrement, le processeur PROC1 est relié au contrôleur NFCC par l'intermédiaire d'un bus BS2 et d'un port correspondant du circuit d'interface ILR. Le bus BS2 est par exemple un bus de données I2C ("Inter Integrated Circuit") ou SPI ("Sériai Peripheral Interface").

Le serveur SV1 est configuré pour offrir des services de transaction à des utilisateurs USRi (USR1 ,...USRn). Il comprend un dispositif de sécurité SDV, un programme GST de gestion de services de transaction et une zone mémoire SM dédiée au stockage de données et de programmes de transaction. La zone mémoire SM est divisée en secteurs comprenant chacun un portefeuille de cartes CPi (CP1 ,...CPn). Chaque secteur formant un portefeuille de cartes CPi est alloué à un utilisateur USRi et comprend des sous-secteurs recevant des cartes virtuelles VCj (VC1 ,...VCm). Chaque utilisateur USRi abonné aux services de transaction proposés par le serveur SV1 dispose d'une ou de plusieurs cartes virtuelles VCj au sein du portefeuille de cartes CPi qui lui est attribué. Chaque carte virtuelle VCj est configurée pour conduire au moins une transaction correspondant à un service, et ainsi émuler une carte de paiement d'un type déterminé, par exemple une carte de paiement de métro, d'autobus, une carte de paiement de supermarché, ou plus généralement une carte bancaire permettant d'effectuer des retraits d'argent ou de paiements. Une carte virtuelle VCj forme ainsi l'équivalent d'une carte matérielle, en combinaison avec le dispositif portable HD2. Un portefeuille de cartes CPi forme ainsi l'équivalent d'un portefeuille matériel dans lequel l'utilisateur rangerait une ou plusieurs cartes matérielles.

Chaque carte virtuelle VCj (VC1 ,...VCm) comporte un système d'exploitation virtuel VOSj (VOS 1 ,... VOS m) et au moins une application carte CAPj (CAP1 ,...CAPm). Vue sous l'angle du protocole transactionnel, chaque carte virtuelle VCj est l'équivalent fonctionnel d'un processeur sécurisé classique PROC3 du type précédemment décrit en relation avec la figure 2, réalisé dans l'art antérieur sous forme de puce de semi-conducteur.

Dans un mode de réalisation, le système d'exploitation virtuel VOSj est un programme qui émule un système d'exploitation OS de processeur sécurisé classique PROC3, tandis que l'application carte CAPj est un programme de transaction classique exécutable aussi bien par un processeur sécurisé classique PROC3 que par un système d'exploitation virtuel VOSj.

Dans un mode de réalisation équivalent, le système d'exploitation virtuel VOSj n'émule pas un système d'exploitation OS de processeur sécurisé classique. L'application carte CAPj n'est pas exécutable par un processeur sécurisé classique et est uniquement exécutable par le système d'exploitation virtuel VOSj. Le système d'exploitation virtuel VOSj et l'application carte CAPj sont des programmes spécifiques configurés pour fonctionner en combinaison et former, ensemble, l'équivalent d'un processeur sécurisé classique PROC3 équipé d'une application carte en ce qui concerne la conduite d'une transaction.

Dans encore un autre mode de réalisation équivalent, le système d'exploitation virtuel VOSj est inclus dans l'application carte CAPj, les deux programmes n'en formant qu'un seul.

Dans un mode de réalisation mettant la priorité sur l'optimisation de l'espace mémoire du serveur, les systèmes d'exploitation virtuels VOSj et les applications cartes CAPj des différentes cartes virtuelles VCj sont émulés par un ou plusieurs programmes centralisés exécutés par le serveur SV1 en mode multitâche. Par exemple, un premier programme central émule plusieurs systèmes d'exploitation à la fois et un second programme central émule la même application carte pour plusieurs cartes virtuelles à la fois. Dans un mode de réalisation préféré mettant la priorité sur la sécurité contre la fraude, la zone mémoire SM contient autant de systèmes d'exploitation virtuels VOSj et d'applications cartes CAPj que de cartes virtuelles VCj. En d'autres termes, les secteurs de la zone mémoire SM contenant les portefeuilles, et d'autre part les sous-secteurs contenant les cartes virtuelles sont entièrement cloisonnés les uns relativement aux autres et ne comportent aucun programme partagé fonctionnant en mode multitâche.

Dans un mode de réalisation, chaque application carte CAPj utilise une clé de cryptographie Kj(CAPj) lui permettant de répondre à des demandes d'authentification nécessitant un calcul cryptographique. Dans le mode de réalisation mettant l'accent sur la sécurité et le cloisonnement des secteurs et des sous-secteurs de la zone mémoire SM, la clé Kj est stockée dans le sous-secteur de la zone mémoire SM recevant la carte mémoire VCj qui exécute cette application, c'est-à-dire recevant le système d'exploitation virtuel VOSj et l'application carte CAPj formant ensemble la carte virtuelle.

Le dispositif de sécurité SDV protège le serveur et notamment l'accès à la zone mémoire SM et au programme de gestion de services de transaction GST. Le dispositif SDV peut être purement logiciel et exécuté par le serveur SV1 , ou comprendre une partie matérielle (hardware) distincte de la partie matérielle du serveur et une partie logicielle exécutée par le serveur ou par la partie matérielle distincte. Il inclut de préférence une fonction de pare-feu et de détection d'une tentative d'accès frauduleux à une application carte.

Le programme de gestion de services de transaction GST, désigné dans ce qui suit "gestionnaire de services", assure la création, l'activation, la mise à jour et la suppression des cartes virtuelles VCj, avec l'aide du dispositif de sécurité SDV qui lui accorde ou non les autorisations à cet effet.

Le serveur SV1 utilise le dispositif HD2 comme une interface NFC distante permettant à une carte virtuelle VCi de conduire une transaction avec le terminal TT. A cet effet, le processeur PROC1 comporte, dans une mémoire programme, un programme navigateur Internet BRW ("Browser"), un programme client web WCL désigné "client web" et un programme de connexion CXP. Le client web WCL est configuré pour établir une liaison de données CX1 avec le serveur SV1 par l'intermédiaire du navigateur BRW, du circuit de communication WCCT (connexion par téléphonie LTE par exemple, ou connexion Wifi) et du réseau Internet INW. Une fois connecté au serveur, le client web WCL dialogue avec le dispositif de sécurité SDV ou avec le gestionnaire de services GST, et présente à l'utilisateur des pages web, des informations ou des demandes d'information émises par ces derniers.

La liaison de données CX1 permet au client web WCL de dialoguer avec le dispositif de sécurité SDV et le gestionnaire de services GST, et est représentée en traits pointillés sur la figure 4. La liaison de données CX1 est de préférence une connexion sécurisée utilisant par exemple la technologie classique SSL ("Secure Sockets Layers") reposant sur un procédé de cryptographie à clef publique avec établissement d'un canal de communication chiffré après une étape d'authentification.

Le programme de connexion CXP est configuré pour assurer l'établissement d'une seconde liaison de données CX2 entre le contrôleur NFCC et une carte virtuelle VCj, par l'intermédiaire du bus BS2, du circuit de communication WCCT et du réseau Internet INW. Dans un mode de réalisation, la liaison de données CX2 est établie après réception d'une requête de connexion émise par le client web WCL ou par le navigateur BRW. Dans un autre mode de réalisation, la liaison de données CX2 est établie de manière permanente entre le contrôleur NFCC et le dispositif de sécurité SDV. Le dispositif SDV rend la liaison de données CX2 accessible à une carte virtuelle VCj au moment où la carte virtuelle doit conduire une transaction.

A l'instar de la liaison de données CX1 , la liaison de données CX2 est de préférence sécurisée. La liaison de données CX2 est par exemple formée via des canaux de communication http ("HyperText Transfer Protocol", ou "Protocole de Transfert Hypertexte) ou via une liaison UDP de bas niveau ("User Datagram Protocol" ou "Protocole de Datagramme Utilisateur") afin de limiter la charge d'échange de données. La liaison de données CX2 peut également être encryptée avec la technologie SSL ou au moyen d'un encodage propriétaire. Dans encore une autre variante, le contrôleur NFCC est équipé de moyens de connexion au réseau Internet et un système de chiffrement propriétaire est prévu dans sa mémoire programme. Cette méthode permet de réaliser un tunnel chiffré point à point entre le serveur SV1 et le contrôleur NFCC et offre un niveau de sécurité très élevé et non attaquable par un logiciel espion qui aurait été inséré dans la mémoire programme du processeur PROC1 . Dans un tel mode de réalisation, le programme de connexion CXP peut être agencé dans la mémoire programme du contrôleur NFCC, comme représenté schématiquement par des traits pointillés sur la figure 4. Dans ce cas, le bus BS2 est utilisé pour permettre au client web WCL d'envoyer au contrôleur NFCC une demande de connexion au serveur SV1 au début d'une étape de transaction S10 décrite plus loin. Un bus de données supplémentaire peut être prévu pour relier directement le contrôleur NFCC au circuit de communication sans fil WCCT, sans passer par le processeur PROC1 .

Dans encore une autre variante, un coprocesseur dédié à l'établissement et au chiffrement de la communication est prévu. Ce coprocesseur est relié au contrôleur NFCC et au circuit de communication sans fil WCCT et permet à une application carte CAPj de prendre le contrôle du contrôleur NFCC sans dépendre du logiciel du processeur PROC1 et d'un éventuel programme espion que celui-ci pourrait comporter.

Dans encore une autre variante, le dispositif portable HD2 ne comporte qu'un seul processeur assurant à la fois le contrôle des organes du dispositif HD2 et le contrôle de transactions NFC en relation avec le serveur de transaction SV1 .

En résumé, selon le mode de réalisation retenu, le programme de connexion CXP peut être inclus dans le client web WCL, être inclus dans le système d'exploitation OS1 du processeur PROC1 , être inclus dans une mémoire programme ou dans le système d'exploitation du contrôleur NFCC, être exécuté par un coprocesseur dédié, ou encore être exécuté par un processeur unique remplaçant le processeur PROC1 et le contrôleur NFCC.

La figure 5 représente des étapes d'un mode de réalisation d'un procédé de transaction mis en œuvre au moyen du système de transaction de la figure 4. On suppose ici qu'un utilisateur USRi se trouve à proximité du terminal TT et souhaite utiliser le dispositif portable HD2 pour effectuer une transaction. L'utilisateur active tout d'abord le client web WCL (étape S1 ), par exemple en appuyant sur une touche du clavier ou en sélectionnant un menu présenté sur l'afficheur. Le client web WCL demande alors à l'utilisateur de fournir des données d'identification USID1 .

Après saisie des données USID1 (étape S2), le client web WCL se relie au dispositif de sécurité SDV via la liaison de données CX1 et lui fournit des données d'identification USID2 (étape S3). Les données USID2 comprennent tout ou partie des données d'identification USID1 et peuvent comprendre des données d'identification additionnelles telles que des données propres au dispositif HD2 que le client web prélève dans une mémoire du dispositif HD2.

Les données d'identification USID1 peuvent être variées et visent à garantir un haut niveau de sécurité. Elles peuvent comporter un "login" (nom d'utilisateur ou adresse E-mail) que l'utilisateur doit fournir ainsi qu'un mot de passe. Un code de sécurité envoyé par une banque à l'utilisateur, par exemple au moyen d'un message de type SMS, peut également être inclus dans les données USID1 . Peuvent également être utilisées comme données d'identification USID1 des données biométriques (voix, visage, empreintes digitales...) et/ou des données dynamiques propres à l'utilisateur, par exemple des données de saisie du code de l'utilisateur (force d'appui sur le clavier, temps d'appui...). Ces données biométriques ou dynamiques permettent de vérifier, en sus de la vérification du code de l'utilisateur, que ce code a été saisi par la bonne personne.

Les données USID2 peuvent comprendre tout ou partie des données USID1 et des données supplémentaires que l'utilisateur n'a fourni qu'une fois lors de la création de son portefeuille de cartes CPi. Il peut s'agir de données d'état civil telles que la date de naissance, le numéro de carte d'identité, le numéro de passeport, l'adresse du domicile de l'utilisateur, etc. Les données USID2 peuvent également comprendre des données propres au dispositif HD2, telles que le numéro de téléphone de l'utilisateur, un numéro d'identification du dispositif, par exemple, s'il s'agit d'un téléphone, son numéro IMEI ("International Mobile

Equipment Identity") et/ou le numéro de la carte SIM.

Le dispositif de sécurité SDV utilise ensuite les données USID2 pour vérifier la légitimité de la demande de connexion. Si le résultat de la vérification est positif, le dispositif SDV communique au gestionnaire de services GST l'identité de l'utilisateur USRi et une autorisation d'accès aux services (étape S4). Il ouvre également la liaison de données CX1 au gestionnaire de services GST, si cela n'a pas été fait précédemment.

Ensuite, le gestionnaire de services GST accède au portefeuille CPi de l'utilisateur et détermine si des cartes virtuelles VCj et des applications carte correspondantes CAPj y ont été installées (étape S5).

Dans l'affirmative, le gestionnaire GST présente à l'utilisateur, par l'intermédiaire du client web, une liste de services correspondant aux applications carte CAPj installées (étape S6) et lui demande de sélectionner le service qu'il souhaite utiliser pour conduire une transaction. Les services sont par exemple

"accès au métro X", "paiement aux caisses du supermarché Y", "carte bancaire Z", etc. Cette page d'accueil propose également d'autres choix à l'utilisateur, notamment l'installation d'une nouvelle carte virtuelle et d'une application carte correspondante, la mise en œuvre de cette option étant décrite plus loin.

L'utilisateur sélectionne le service désiré (étape S7) et son choix

("application carte CAPj sélectionnée") est envoyé au gestionnaire GST par le client web (étape S8).

Dans une variante des étapes S7, S8, l'utilisateur confirme seulement son souhait de réaliser une transaction sans préciser le service souhaité. Dans ce cas, l'application carte CAPj appropriée est sélectionnée automatiquement au moment de la transaction.

Le client web WCL demande ensuite au programme de connexion CXP d'établir la liaison de données CX2 entre le serveur SV1 et le contrôleur NFCC, tandis que le gestionnaire de services GST sélectionne et active la carte virtuelle VCj de l'utilisateur et l'application carte CAPj que l'utilisateur a désignée (étape S9). De son côté, l'utilisateur approche le dispositif HD2 du terminal de transaction TT pour qu'un couplage inductif s'établisse entre les bobines d'antennes AC2 et AC3. Dans une variante de réalisation, la liaison de données CX2 est préalablement établie entre le dispositif de sécurité SDV et le contrôleur NFCC, et est simplement rendue accessible à l'application carte CAPj par le dispositif SDV après l'étape S9.

La carte virtuelle VCj est alors reliée au contrôleur NFCC. Une connexion est établie avec le terminal de transaction TT et l'application carte CAPj de la carte virtuelle VCj exécute la transaction demandée (étape S10). Cette transaction peut comprendre des actions de l'utilisateur, comme l'acceptation d'un montant ou le choix d'un produit. Également, bien que cela ne soit pas représenté sur la figure 5, le terminal de transaction TT peut être relié à un serveur bancaire SVO (Cf. Fig. 4) qui requiert des étapes d'authentification et vérifie que des réponses à des demandes d'authentification ont bien été envoyées par une application carte utilisant une clé bancaire autorisée.

Lorsque la transaction est terminée, la liaison de données CX2 est fermée, la carte virtuelle VCj est désactivée et le gestionnaire GST envoie au client web WCL des informations sur la transaction réalisée, par exemple l'objet et le montant de la transaction (étape S1 1 ). Le client web peut mémoriser et présenter ces informations à l'utilisateur.

L'homme de l'art notera que le procédé de transaction et le système de transaction qui viennent d'être décrits sont susceptibles de diverses variantes. Notamment, le client web WCL est un programme "chapeau" qui utilise des pages web ou des données fournies par le serveur SV1 pour former une interface utilisateur. Un tel programme peut ne pas être nécessaire. Dans ce cas, l'utilisateur dialogue directement avec le dispositif de sécurité SDV et le gestionnaire de services GST par l'intermédiaire de pages web que ces deux organes lui présentent par l'intermédiaire du navigateur BRW.

La figure 6 montre un exemple de transaction réalisée à l'étape S10. La transaction comprend les étapes suivantes :

i) Un canal P1 est créé entre la carte virtuelle VCj et une technologie RFTi exécutée par le contrôleur NFCC, au moyen de commandes "PIPE_CREATE", "PIPE_OPEN". Cette étape peut être conduite par le programme de connexion CXP, comme représenté. Alternativement, cette étape peut être conduite par la carte virtuelle VCj elle-même, si celle-ci comporte un programme de gestion de l'interface HCI, ou par le dispositif de sécurité SDV. Il sera noté que le canal P1 , ici conforme au protocole HCP, est établi à travers la liaison de données CX2 qui traverse le réseau Internet et le bus BS2 ;

ii) le contrôleur NFCC détecte le champ magnétique émis par le terminal TT et envoie la commande EVT_FIELD_ON à la carte virtuelle VCj ;

iii) le contrôleur NFCC conduit des étapes d'initialisation d'une communication avec le terminal TT incluant la création d'un canal de communication NFC (désigné "RFCH" sur la figure 6, ou canal RF), ainsi que des étapes éventuelles d'anticollision si d'autres dispositifs NFC ou cartes sans contact se trouvent dans le champ d'interrogation du terminal TT (étape "INIT, ANTICOL") ;

iv) lorsque la connexion avec le terminal TT est établie, le contrôleur NFCC envoie une commande EVT_CARD_ACTIVATED à la carte virtuelle VCj pour lui indiquer qu'une transaction peut commencer.

La transaction proprement dite comprend ensuite les étapes suivantes :

- l'envoi de commandes CAPDU par le terminal TT au processeur NFCC, via le canal de communication RF,

- la transmission de ces commandes à l'application carte CAPj de la carte virtuelle VCj par le contrôleur NFCC, par l'intermédiaire du canal P1 , sous une forme encapsulée dans des commandes EVT_SEND_DATA ;

- l'envoi au contrôleur NFCC, par l'application carte CAPj de la carte virtuelle VCj, de réponses RAPDU, via le canal P1 , sous une forme encapsulée dans des commandes EVT_SEND_DATA, et

- la transmission des réponses RAPDU au terminal TT par le contrôleur NFCC, via le canal RF.

Les commandes CAPDU et les réponses RAPDU (habituellement désignées "C-APDU" et "R-APDU") sont définies par la norme ISO 7816-4. Dans une variante de réalisation de la transaction, l'encapsulation des commandes CAPDU et des réponses RAPDU est effectué au moyen du protocole http au lieu d'utiliser des commandes d'encapsulation EVT_SEND_DATA.

La première commande CAPDU envoyée par le terminal TT peut être une commande de sélection de l'application carte CAPj, par exemple la commande "SELECT_AID" telle que définie par la norme ISO 7816-4. Si l'application carte a été sélectionnée préalablement par l'utilisateur à l'étape S7 et si cette application ne correspond pas à celle demandée par le terminal de transaction TT, la carte virtuelle VCj renvoie un message d'erreur et la transaction est interrompue.

Dans la variante de réalisation de l'étape S7 décrite plus haut, où l'utilisateur confirme seulement son souhait de réaliser une transaction sans sélectionner une carte virtuelle déterminée, la carte virtuelle contenant l'application carte appropriée est sélectionnée automatiquement par un programme de sélection de carte inclus dans le portefeuille de cartes de l'utilisateur. Au commencement de l'étape S10, ce programme de niveau haut assure l'activation initiale de la porte d'application carte CAG et la création du canal P1 afin de recevoir la commande de sélection de l'application carte. Il active ensuite l'application carte désignée par la commande, si celle-ci est installée dans le portefeuille de cartes. Dans le cas contraire, la transaction est interrompue.

Lorsque la transaction est terminée (ou interrompue), le terminal TT cesse d'émettre le champ magnétique et le contrôleur NFCC envoie à la carte virtuelle VCj une commande EVT_CARD_DEACTIVATED de désactivation de l'application carte et une commande EVT_FIELD_OFF indiquant que le champ magnétique n'est plus présent. Le canal P1 est ensuite fermé entre la carte virtuelle VCj et le contrôleur NFCC, au moyen d'une commande "PIPE_CLOSE". Cette étape de fermeture du canal P1 peut être conduite par la carte virtuelle VCj elle-même ou par le programme de connexion CXP, comme représenté. Alternativement, cette étape peut être conduite par le dispositif de sécurité SDV. Le gestionnaire de services GST exécute ensuite l'étape S1 1 décrite plus haut (fig. 7).

L'homme de l'art notera que cet exemple de transaction par l'intermédiaire d'une interface HCI n'est aucunement limitatif. La connexion entre la carte virtuelle VCj et le contrôleur NFCC peut être établie au moyen de divers autres protocoles et d'autres commandes peuvent être prévues.

L'exemple de transaction qui vient d'être décrit suppose d'une part que l'utilisateur USRi bénéficie d'un portefeuille de cartes CPi et, d'autre part, que le portefeuille contienne au moins la carte virtuelle VCj nécessaire à cette transaction.

La figure 7 représente un mode de réalisation d'un procédé de création d'un portefeuille de cartes CPi. On suppose que l'utilisateur USRi se connecte d'abord au gestionnaire de services GST en tant qu'utilisateur non enregistré, via une connexion Internet. Le gestionnaire GST fournit alors au dispositif HD2 une page d'accueil pour utilisateur non enregistré, dans laquelle on propose à l'utilisateur d'adhérer aux services de transaction (étape S20). L'acceptation par l'utilisateur de cette invitation entraîne ici le téléchargement et l'installation du client web WCL dans le dispositif HD2 (étape S21 ). Le client web WCL se connecte au gestionnaire GST (étape S22) au moyen de la liaison de données CX1 et le gestionnaire GST envoie à l'utilisateur une page d'enregistrement (étape S23) dans laquelle divers renseignements lui sont demandés, pour former les données d'identification USID1 . En sus de ces données, l'utilisateur peut être invité à communiquer ses coordonnées bancaires et toute donnée complémentaire permettant de définir les données USID2. Le client web peut également prélever dans le dispositif HD2 des données spécifiques à celui-ci, destinées à former des données USID2.

Lorsque le client web WCL dispose de l'intégralité des données USID1 et USID2 (étape S24) et des éventuels autres renseignements nécessaires à l'adhésion de l'utilisateur, il fournit les données USID2 au dispositif de sécurité SDV (étape S25). Le dispositif de sécurité SDV procède alors à une vérification des données d'identification USID2, détermine si l'utilisateur USRi peut être autorisé à disposer d'un portefeuille de cartes, puis adresse une autorisation de création du portefeuille au gestionnaire de services GST (étape S26).

Le gestionnaire GST crée alors le portefeuille CPi (étape S27). En pratique, cette création peut simplement consister en un enregistrement de l'utilisateur dans une base de données contenant les données d'identification USID2 et une table de correspondance désignant le secteur de la zone mémoire SM alloué à l'utilisateur.

Le gestionnaire GST adresse ensuite au dispositif HD2 une confirmation de création du portefeuille CPi (étape S30).

La figure 8 représente un mode de réalisation d'un procédé d'acquisition d'une carte virtuelle VCj. Ce procédé peut être engagé après l'étape S28 précédemment décrite ou, comme représenté sur la figure, après une nouvelle connexion au serveur SV1 . Cette nouvelle connexion comporte les étapes précédemment décrites à savoir :

- activation du client web (étape S1 ),

- saisie des données USID1 (étape S2),

- envoi des données USID2 au dispositif de sécurité SDV par le client web (étape

53) , pour vérifier la légitimité de la demande de connexion,

- vérification de la légitimité de la demande de connexion par le dispositif de sécurité et communication au gestionnaire GST d'une autorisation d'accès (étape

54) ,

- accès au portefeuille CPi par le gestionnaire GST et détermination des applications carte CAPj qui y ont été installées (étape S5),

- envoi à l'utilisateur d'une liste des applications carte CAPj installées, ainsi qu'une proposition d'installation d'une nouvelle application carte (étape S6).

On supposera ici que l'utilisateur sélectionne l'option "installation d'une nouvelle application" (étape S12) au lieu de sélectionner une application (étape S7, Fig. 5), soit parce qu'il ne possède aucune application installée soit parce qu'il souhaite en installer une nouvelle.

Le client web répercute la demande de nouvelle application au gestionnaire de services GST (étape S13). Les étapes qui suivent font intervenir un ou plusieurs serveurs bancaires, ou serveurs de certifications, ou de préférence un serveur unique de certification BSV regroupant des services d'une ou de plusieurs banques. Avant de traiter la demande d'installation d'une nouvelle application, le gestionnaire de services GST peut avoir préalablement reçu du serveur de certification BSV une offre d'applications CAPj (étape S0).

Le gestionnaire de services GST adresse ainsi au dispositif HD2 une page d'offre d'applications carte CAPj présentées sous forme d'une offre de services de transaction (étape S30).

L'utilisateur sélectionne ensuite un service de transaction, ce qui correspond à la sélection d'une application carte CAPj (étape S31 ). Son choix est répercuté au gestionnaire GST par le client web (étape S32).

Le gestionnaire GST adresse alors au serveur BSV les données USID2 d'identification de l'utilisateur ainsi qu'un identifiant de l'application carte CAPj demandée (étape S33), et requiert une autorisation de création de la carte virtuelle correspondante. Cette étape peut comprendre des accès multiples au serveur bancaire. Elle peut éventuellement être différée si le serveur de certification indique que l'utilisateur doit préalablement être contacté par des attachés commerciaux pour accomplir certaines formalités. Inversement, l'utilisateur peut avoir déjà accompli ces formalités et avoir fournit dans les données USID1 un code reçu de la banque, qui l'autorise à obtenir la carte.

Après vérification, le serveur BSV renvoie au gestionnaire GST le programme de l'application carte et une clé bancaire d'activation Kj(CAPj) permettant d'utiliser l'application carte (étape S34). Cette clé forme une clé de cryptographie permettant à l'application de s'authentifier auprès d'un terminal de transaction, lorsque cela lui est demandé. Le gestionnaire GST procède alors à la création de la carte virtuelle VCj dans le portefeuille CPi, y compris le cas échéant l'installation du système d'exploitation virtuel VOSj de la carte, puis à l'installation de l'application CAPj dans la carte virtuelle VCj, ainsi qu'à l'installation de la clé Kj (étape S35).

Dans une variante, diverses applications carte CAPj sont mémorisées dans un espace de stockage d'applications du gestionnaire GST et le serveur de certification ne fournit que la clé d'activation Kj.

Le gestionnaire GST retourne ensuite à l'étape S6 pour présenter à l'utilisateur une liste des applications carte CAPj installées, ainsi qu'une proposition d'installation d'une nouvelle application carte. L'utilisateur peut décider d'installer encore une nouvelle application, d'utiliser celle qui vient d'être installée ou une application précédemment installée, ou de se déconnecter du serveur SV1 .

Dans une variante, le gestionnaire GST ne dispose pas d'un droit de modification des cartes virtuelles VCj et les étapes S33, S34 et S35 sont confiées au dispositif de sécurité SDV.

L'exemple de système de transaction qui vient d'être décrit est susceptible de divers autres modes de réalisation. En particulier, des modes de réalisation du système de transaction peuvent concerner la virtualisation d'un point de paiement mettant en œuvre une application point de paiement au lieu d'une application carte. Une application point de paiement PAPj diffère d'une application carte CAPj en ce qu'elle vise à encaisser une somme d'argent par l'intermédiaire d'une transaction avec une carte à puce permettant au payeur de s'identifier.

La figure 9 représente un système de transaction qui présente, par rapport à celui de la figure 4, les différences suivantes :

- le dispositif HD2, au lieu d'être agencé en face d'un terminal de transaction TT, est agencé en face d'une carte sans contact CC1 comprenant une bobine d'antenne AC1 et un circuit intégré sans contact CIC, et conduit une transaction avec celle-ci ;

- le serveur SV1 , au lieu de gérer des applications cartes CAPj agencées dans des cartes virtuelles VCj, elles-mêmes agencées dans des portefeuilles de cartes CPi, gère des applications point de paiement PAPj (PAP1 ,...PAPm) agencées dans des points de paiement virtuels VPj (VP1 ,...VPm), eux-mêmes agencés dans des portefeuilles de points de paiement PPi (PP1 ,...PPn) attribués à des utilisateurs USRi. Chaque point de paiement virtuel peut comprendre, en sus d'une application point de paiement PAPj, un programme VOSj (VOS1 ,...VOSm) d'émulation d'un système d'exploitation d'un terminal de paiement, qui peut aussi être inclus dans l'application point de paiement PAPj.

Par analogie avec le système de transaction classique représenté sur la figure 1 , le dispositif HD2 agit ici en tant que terminal de transaction TT. Le contrôleur NFCC émet le champ magnétique FLD nécessaire à l'établissement d'un canal de communication sans contact avec la carte CC1 . Le programme application point de paiement PAPj prend le contrôle du contrôleur NFCC pour conduire la transaction. Il émet des commandes CAPDU et reçoit des réponses RAPDU. Le programme application point de paiement PAPj peut être configuré pour se connecter, pendant la transaction ou postérieurement à celle-ci, à un serveur d'autorisation bancaire tel que le serveur SVO montré sur la figure 1 .

Le procédé représenté sur la figure 5 peut être adapté à la réalisation d'une transaction en mode point de paiement, en activant à l'étape S10 une application point de paiement PAPj au lieu d'une application carte CAPj, et en recherchant à l'étape S5 les points de paiement virtuels VPj installés dans le portefeuille PPi d'un utilisateur USRi. A l'étape S6, le procédé peut comporter la présentation d'une liste d'applications point de paiement PAPj disponibles au lieu de la présentation d'une liste d'applications carte CAPj, ou une présentation des deux types de services de transaction. Enfin, le procédé représenté sur la figure 7 peut être adapté à la création d'un portefeuille de points de paiements PPi au lieu d'un portefeuille de cartes CPi. De même, le procédé représenté sur la figure 8 peut être modifié de manière que les étapes S31 à S35 se rapportent à l'installation d'une application point de paiement et d'un point de paiement virtuel.

La figure 10 montre un exemple de transaction réalisée entre un point de paiement virtuel VPj et la carte sans contact CC1 , qui intervient par exemple à l'étape S10 du procédé de la figure 5 adapté à la réalisation d'une transaction en mode point de paiement. La transaction comprend les étapes suivantes :

i) un canal P2 est créé entre le point de paiement virtuel VPj et une technologie RFTi exécutée par le contrôleur NFCC, au moyen de commandes "PIPE_CREATE", "PIPE_OPEN". Cette étape peut être conduite par le programme de connexion CXP, comme représenté. Alternativement, cette étape peut être conduite par le point de paiement virtuel VPj lui-même, si celui-ci comporte un programme de gestion de l'interface HCI, ou par le dispositif de sécurité SDV, avant que celui-ci ne rendre la liaison de donnée CX2 accessible au point de paiement virtuel VPj ; ii) l'envoi au contrôleur NFCC des commandes d'interrogation EVT_READER_REQUESTED visant à détecter la présence du circuit intégré sans contact CIC (méthode d'interrogation dite "polling"). Cette étape peut être conduite par le point de paiement virtuel VPj, comme représenté. Alternativement cette étape peut être conduite par le programme de connexion CXP, ou par le dispositif de sécurité SDV, avant que celui-ci ne rendre la liaison de donnée CX2 accessible au point de paiement virtuel VPj ;

iii) lorsque le circuit intégré sans contact CIC de la carte CC1 est détecté, le contrôleur NFCC conduit des étapes "INIT, ANTICOL" d'initialisation d'une communication avec le circuit intégré sans contact CIC avec création d'un canal de communication RF (désigné RFCH sur la figure 10), et optionnellement des étapes d'anticollision (si d'autres circuits intégrés sans contact sont présents dans le champ),

- le contrôleur NFCC envoie la commande EVT TARGET DISCOVERED au point de paiement virtuel VPj pour lui indiquer qu'une transaction peut commencer.

La transaction proprement dite comprend ensuite les étapes suivantes :

- l'envoi au contrôleur NFCC, par l'application point de paiement virtuel PAPj, de commandes CAPDU, via le canal P2, les commandes CAPDU étant encapsulées dans des commandes WR_XCHG_DATA,

- la transmission par le contrôleur NFCC des commandes CAPDU au circuit intégré sans contact CIC, par l'intermédiaire du canal RF,

- l'envoi au contrôleur NFCC, par le circuit intégré sans contact CIC, de réponses RAPDU,

- la transmission des réponses RAPDU à l'application point de paiement virtuel PAPj, par le contrôleur NFCC, via le canal P2, les réponses RAPDU étant encapsulées dans des commandes WR_XCHG_DATA.

La transaction est clôturée par l'envoi de la commande EVT_END_OPE RATION au contrôleur NFCC. Cette étape peut être conduite par le point de paiement virtuel VPj, comme représenté. Alternativement cette étape peut être conduite par le programme de connexion CXP, ou par le dispositif de sécurité SDV, avant que celui-ci ne rendre la liaison de donnée CX2 accessible au point de paiement virtuel VPj ;

Le canal P2 est ensuite fermé au moyen d'une commande "PIPE_CLOSE". Cette étape peut être conduite par le programme de connexion CXP, comme représenté. Alternativement, cette étape peut être conduite par le point de paiement virtuel VPj lui-même, si celui-ci comporte un programme de gestion de l'interface HCI, ou par le dispositif de sécurité SDV.

Le système de transaction représenté sur la figure 9 est lui-même susceptible de diverses variantes. Par exemple, la carte sans contact CC1 peut être remplacée par un autre dispositif portable HD2' qui fonctionne dans le mode émulation de carte, tel que précédemment décrit en relation avec les figures 5 et 6. Si le même serveur SV1 gère à la fois des applications carte et des applications point de paiement, les deux dispositifs portable HD2, HD2' se trouvant face à face peuvent exécuter une transaction, l'un en tant que carte, ou payeur, l'autre en tant que point de paiement, ou receveur, tout en étant connectés simultanément au même serveur SV1 . Un système de transaction tel que décrit ci-dessus peut donc permettre de conduire des transactions privées, par exemple un transfert d'une somme d'argent d'une personne à une autre au moyen de leurs téléphones portables.

La figure 1 1 représente un mode de réalisation d'un système de transaction selon l'invention, qui est dérivé de celui de la figure 4. Diverses caractéristiques du système ont été décrites plus haut en relation avec la figure 4 et ne le seront pas de nouveau. Le système se distingue de celui de la figure 4 en ce que le terminal TT est relié au serveur SV1 par des moyens informatiques et comporte un programme de connexion CXP' configuré pour assurer l'établissement d'une liaison de données CX3 entre le terminal TT et le serveur SV1 . Ces moyens de liaison informatiques peuvent être le réseau Internet INW ou un réseau privé reliant directement le terminal TT au serveur SV1 .

La liaison de données CX3 permet au serveur SV1 de conduire la transaction avec le terminal TT pour le compte du dispositif portable HD2 (c'est-à- dire pour le compte de l'utilisateur du dispositif HD2) sans passer par le dispositif HD2.

Ce mode de réalisation est une alternative au mode de réalisation décrit dans ce qui précède, qui était basé sur l'établissement de la liaison de données CX2. Il peut aussi trouver application lorsque la liaison de données CX2 présente un débit de données trop faible pour garantir que la transaction s'effectuera dans un temps limité acceptable pour l'utilisateur, ou lorsque la liaison de données CX2 ne peut pas être établie (absence totale de connexion par téléphonie LTE ou de connexion Wifi par exemple).

Une transaction conduite par l'intermédiaire de la liaison de données CX3 sera désignée dans ce qui suit "transaction dans le mode hors connexion".

Dans le terminal TT, le programme de connexion CXP' est configuré pour assurer l'établissement de la liaison de données CX3 après fourniture par le dispositif HD2 d'informations d'application et de transaction IAT qui permettent au terminal TT de demander au serveur SV1 de sélectionner et d'activer une carte virtuelle VCj et une application CAPj avec laquelle il va ensuite conduire une transaction. A l'instar de la liaison de données CX2, la liaison de données CX3 est de préférence sécurisée. La liaison de données CX3 est par exemple formée via des canaux de communication http ou via une liaison UDP de bas niveau. La liaison de données CX3 peut également être encryptée avec la technologie SSL ou au moyen d'un encodage propriétaire. Dans encore une autre variante, le terminal TT comprend un système de chiffrement propriétaire et réalise un tunnel chiffré point à point avec le serveur SV1 .

La figure 12 représente des étapes d'un procédé de transaction selon l'invention dans le mode hors connexion, mis en œuvre au moyen du système de transaction de la figure 1 1 .

Étape S1 a - Cette étape est optionnelle et permet à l'utilisateur USRi de sélectionner une application dont l'identité sera déterminée par le terminal TT au cours de l'étape S1 b suivante. On suppose comme précédemment qu'un utilisateur USRi se trouve à proximité du terminal TT et souhaite utiliser le dispositif portable HD2 pour effectuer une transaction. Un canal de communication NFC est établi entre le dispositif HD2 et le terminal TT.

Étape S1 b - Le terminal TT, par l'intermédiaire du canal RF, reçoit du dispositif HD2 les informations d'application et de transaction IAT, par exemple en les lisant dans un registre ou une mémoire du dispositif HD2. Les informations d'application et de transaction IAT comprennent par exemple :

- un identifiant de l'application sélectionnée par l'utilisateur, le cas échéant, sinon une liste d'identifiants d'application,

- une adresse IP du serveur de transaction SV1 (adresse internet),

- des données sécurisées d'identification du dispositif HD2 ("credentials").

Si l'utilisateur USRi a sélectionné une application à l'étape S1 a, le terminal TT ne trouve qu'un seul identifiant d'application dans le dispositif HD2. Si l'utilisateur ne l'a pas fait, le terminal peut trouver plusieurs identifiants d'application et sélectionne par défaut l'application pour laquelle il a été conçu. Par exemple, si le terminal TT est un terminal de gestion de titres de transport (borne d'accès au métro, à une ligne de bus, etc.) et qu'il trouve dans le dispositif HD2 un identifiant d'application transport et un identifiant d'application paiement, il sélectionne par défaut l'application transport puisqu'il ne gère pas l'application paiement.

Étapes S2a, S2b - L'utilisateur fournit au dispositif HD2 des données d'identification personnelles USID1 , par exemple un numéro d'identification personnel (code PIN), et le dispositif HD2 le communique au terminal TT. Ces étapes sont optionnelles et dépendent du niveau de sécurité souhaité, à l'instar des transactions classiques faites au moyen de cartes à puce qui, dans certaines applications, ne nécessitent pas la fourniture d'un identifiant par l'utilisateur. Par ailleurs, à l'étape S2a, les données d'identification personnelles USID1 peuvent être directement fournies au terminal TT par l'utilisateur, si le terminal dispose d'un clavier.

Étape S3a - Sur la base de l'adresse IP présente dans les informations d'application et de transaction IAT, et par l'intermédiaire de la liaison CX3, le terminal TT se relie au dispositif de sécurité SDV du serveur SV1 . Le terminal TT lui présente une demande d'autorisation d'accès aux services et lui fournit les autres informations d'application et de transaction IAT, notamment les données d'identification du dispositif HD2 ("credentials") et l'identifiant de l'application visée, ainsi que par ailleurs, et optionnellement, les données d'identification personnelles USID1 de l'utilisateur USRi.

Étape S4a - Le dispositif de sécurité SDV utilise ces informations pour vérifier la légitimité de la demande d'autorisation d'accès au service et l'identité de l'utilisateur USRi.

Étape S9a: Si le résultat de la vérification est positif, le dispositif SDV communique au gestionnaire de services GST l'identité de l'utilisateur USRi, une autorisation d'accès aux services, et l'identifiant de l'application visée. Il ouvre également la liaison de données CX3 au gestionnaire de services GST, si cela n'a pas été fait précédemment.

Ensuite, le gestionnaire de services GST sélectionne et active la carte virtuelle VCj de l'utilisateur et l'application carte CAPj correspondant à l'application demandée. La carte virtuelle VCj est alors reliée au terminal TT.

Étape S10a - L'application carte CAPj de la carte virtuelle VCj exécute la transaction demandée, par l'intermédiaire de la liaison de données CX3. Il sera noté que l'identification du terminal TT lui-même, en tant que terminal autorisé à conduire cette transaction, peut-être faite à cet instant par l'application carte elle- même. Il sera noté également que l'exemple de transaction décrit plus haut en relation avec la figure 6 pour illustrer l'étape S10, s'applique également à l'étape S10a, à la différence que les étapes intermédiaires entre le composant NFCC et le programme de connexion CXP sont supprimées, le terminal TT envoyant directement des données de protocole d'application (commandes CAPDU) à la carte virtuelle VCj et celle-ci envoyant directement des données de protocole d'application (réponses RAPDU) au terminal TT, sans passer par le dispositif portable HD2 et donc sans encapsulation dans la couche de protocole de communication NFC.

Par ailleurs, comme indiqué plus haut, le terminal de transaction TT peut être relié à un serveur bancaire SV0 (Cf. Fig. 1 1 ) qui requiert des étapes d'authentification et vérifie que des réponses à des demandes d'authentification ont bien été envoyées par une application carte utilisant une clé bancaire autorisée.

Étape S1 1 a (étape optionnelle) - La transaction est terminée et le gestionnaire GST envoie au terminal TT des informations sur la transaction réalisée, par exemple l'objet et le montant de la transaction, puis désactive la carte virtuelle VCj et ferme la liaison de données CX3.

Étape S1 1 b (étape optionnelle) - Le terminal répercute ces informations au dispositif HD2 qui peut les mémoriser et les présenter à l'utilisateur,

II sera noté qu'un mode de réalisation de ce procédé de transaction peut faire intervenir la liaison CX1 , dans le cas où le dispositif HD2 peut se connecter de manière autonome au serveur SV1 , y compris si la liaison CX1 présente un bas débit.

La liaison CX1 peut permettre d'accroître le niveau de sécurité de la transaction en permettant au serveur SV1 de s'assurer par exemple que l'utilisateur légitime est bien présent. Certaines étapes préparatoires de la transaction peuvent ainsi être réalisées via la liaison CX1 au lieu de la liaison CX3, par exemple la fourniture au dispositif de sécurité SDV du serveur des données d'identification personnelles USID1 de l'utilisateur USRi. Dans ce cas, les étapes S2a, S2b ne sont pas réalisées.

La liaison CX1 peut aussi être utilisée pour fournir au serveur SV1 l'identifiant d'une application sélectionnée par l'utilisateur. Dans ce cas, les informations d'application et de transaction IAT fournies au terminal TT par le dispositif HD2 ne comprennent que l'adresse IP du serveur de transaction SV1 et les données d'identification du dispositif HD2.

Egalement, l'adresse du serveur de transaction SV1 peut ne pas être comprise dans les informations d'application et de transaction IAT. Cette adresse peut être préenregistrée dans une mémoire du terminal TT (adresse fixe d'un serveur unique auquel le terminal TT est rattaché), ou choisie par le terminal TT dans une liste d'adresses préenregistrées dans sa mémoire, en fonction de l'identité du dispositif portable HD2 et/ou de l'application demandée. Dans ce cas, les informations d'application et de transaction IAT ne comprennent que les données d'identification du dispositif HD2, ou ne comprennent que les données d'identification du dispositif HD2 et l'identifiant de l'application sélectionnée.

D'autre part, toujours pour augmenter le niveau de sécurité, la liaison CX1 peut également permettre à l'utilisateur de spécifier au serveur, en sus de spécifier l'application sélectionnée, pendant combien de temps il autorise l'activation de cette application, en d'autres termes pendant combien de temps il autorise l'activation de l'application carte CAPj correspondante. Par exemple, l'utilisateur peut autoriser l'activation de l'application pendant deux minutes. Si le terminal ne réalise pas la transaction dans les deux minutes qui suivent, l'autorisation est retirée. Cette mesure de sécurité permet d'éviter qu'un terminal frauduleux tente ultérieurement de réaliser une transaction avec cette application carte.

Enfin, le canal de communication entre le dispositif portable et le terminal de transaction pourrait reposer sur une autre technologie que la technologie à champ proche qui utilise un champ magnétique comme support de communication. Il pourrait s'agir par exemple d'un champ électrique UHF.