FR2957173A1 - Procede pour conduire un transaction au moyen d'un dispositif nfc - Google Patents

Procede pour conduire un transaction au moyen d'un dispositif nfc Download PDF

Info

Publication number
FR2957173A1
FR2957173A1 FR1000871A FR1000871A FR2957173A1 FR 2957173 A1 FR2957173 A1 FR 2957173A1 FR 1000871 A FR1000871 A FR 1000871A FR 1000871 A FR1000871 A FR 1000871A FR 2957173 A1 FR2957173 A1 FR 2957173A1
Authority
FR
France
Prior art keywords
reader
application
host processor
commands
integrated circuit
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
FR1000871A
Other languages
English (en)
Other versions
FR2957173B1 (fr
Inventor
Kian Teck Soh
Jean Bernard Blanchet
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.)
Inside Secure SA
Original Assignee
Inside Contactless 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 Inside Contactless SA filed Critical Inside Contactless SA
Priority to FR1000871A priority Critical patent/FR2957173B1/fr
Priority to EP11001493.3A priority patent/EP2363825B1/fr
Priority to CA2733304A priority patent/CA2733304C/fr
Priority to KR1020110019607A priority patent/KR101819100B1/ko
Priority to CN201110052419.8A priority patent/CN102194085B/zh
Publication of FR2957173A1 publication Critical patent/FR2957173A1/fr
Application granted granted Critical
Publication of FR2957173B1 publication Critical patent/FR2957173B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/0008—General problems related to the reading of electronic memory record carriers, independent of its reading method, e.g. power transfer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
    • G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
    • G06K7/10237—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves the reader and the record carrier being capable of selectively switching between reader and record carrier appearance, e.g. in near field communication [NFC] devices where the NFC device may function as an RFID reader or as an RFID tag
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
    • G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
    • G06K7/10297—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves arrangements for handling protocols designed for non-contact record carriers such as RFIDs NFCs, e.g. ISO/IEC 14443 and 18092

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Toxicology (AREA)
  • Health & Medical Sciences (AREA)
  • Theoretical Computer Science (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Electromagnetism (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Systems (AREA)

Abstract

L'invention concerne un procédé pour conduire une transaction entre un dispositif NFC (NFCC, HP1) et un circuit intégré sans contact (RCIC) de type lecteur passif. Le procédé comprend des étapes consistant à prévoir dans le circuit intégré sans contact (RCIC) au moins un programme d'émulation d'application lecteur (RAEP) et, au moyen d'un organe intermédiaire (HC, HP2) du dispositif NFC, établir une communication avec le circuit intégré sans contact (RCIC), recevoir du circuit intégré sans contact (RCIC) des commandes d'application lecteur (CAPDU1) et les transférer au premier processeur hôte (HP1), et recevoir des réponses d'application carte (RAPDU1) fournies par le premier processeur hôte (HP1) et les transférer au circuit intégré sans contact (RCIC).

Description

PROCEDE POUR CONDUIRE UNE TRANSACTION AU MOYEN D'UN DISPOSITIF NFC
La présente invention concerne les transactions sans contact conduites au moyen d'un contrôleur NFC couplé à au moins un processeur hôte. La technologie NEC est actuellement développée par s un consortium industriel regroupé sous le nom de Forum NFC (http://www.nfc-forum.org). La technologie NFC est dérivée de la technologie RFID (Radio Frequency Identification) et utilise des contrôleurs NFC présentant plusieurs modes de fonctionnement, notamment un mode 10 lecteur ("Reader Mode") et un mode émulation de carte ("Card emulation"). La figure 1 représente un dispositif NFC généralement appelé "chipset NFC" (ensemble de puces) comprenant un contrôleur NFC référencé NFCC et au moins 15 un processeur hôte processeur HP1 relié au contrôleur NFCC par un bus BS1, par exemple de type SWP ("Single Wire Protocol"). Le processeur hôte peut prendre la forme d'une carte à circuit intégré désignée UICC ("Universal Integrated Circuit Card"), telle une carte SIM 20 (Subscriber Identity Module). Le processeur hôte peut aussi être le processeur de bande de base ("Baseband") d'un téléphone mobile (soit le processeur en charge des communications téléphoniques). Les ressources du contrôleur NFCC sont mises à la disposition du processeur 25 hôte HP1 pour lui permettre de gérer des applications sans contact. Le contrôleur NFCC comprend un contrôleur hôte HC et une interface sans contact CLF ("Contactless Front End Interface") équipée d'une bobine d'antenne AC1. En pratique, le contrôleur hôte HC et l'interface CLF 30 peuvent être réalisés sur la même puce de semi-conducteur, telle la puce MicroRead® commercialisée par la demanderesse, ou être formés de deux puces distinctes, telle les puces "PicoRead® Microcontroller" et "PicoRead® RF Interface" commercialisées par la demanderesse. L'interface CLF du contrôleur NFCC peut généralement s fonctionner selon plusieurs technologies RF, désignées RFTi sur la figure 1, 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") telle que défini Io par ISO/IEC 14443-3, et "Type F" telle que définie par ISO 18092 en tant que mode passif à 212 et 424 kops (kilo octets par seconde) ou par la norme industrielle japonaise JIS X 6319-4. Chaque technologie RF, ou protocole de communication sans contact, définit une 15 fréquence d'émission du champ magnétique, une méthode de modulation du champ magnétique pour transmettre des données en mode actif, une méthode de modulation de charge pour transmettre des données en mode passif, une méthode de codage des données, un format de trame de 20 données, etc. En raison de ses capacités de communication étendues, un tel dispositif NEC est généralement intégré dans un dispositif portatif HD ("Handheld Device") tel un téléphone portable, un PDA (Assistant Numérique 25 Personnel), etc. Des exemples d'application du dispositif NFC sont illustrés sur la figure 2 qui représente un dispositif portatif HD équipé du dispositif NFC de la figure 1, le dispositif HD prenant ici la forme d'un téléphone mobile. On distingue des applications lecteur 30 RAP ("Reader Applications") et des applications carte CAP ("Card Applications") Applications lecteur (RAP) Le contrôleur NFCC fonctionne comme un lecteur NFC pour conduire une transaction avec un circuit intégré 35 sans contact CIC ("Contactless Integrated Circuit"). Une
application lecteur RAPi est exécutée par le processeur hôte HP1 (Cf. Fig. 1). Ce dernier place l'interface CLF dans un mode de fonctionnement actif où elle émet un champ magnétique FLD, envoie des données par modulation du champ magnétique et reçoit des données par modulation de charge et couplage inductif. Ce type d'application peut être gratuit (par exemple lecture d'une étiquette électronique ou "tag" présente dans un abribus contenant les horaires des lignes de bus) et être exécutée par un io processeur non sécurisé. Le processeur hôte HP1 peut dans ce cas être le processeur de bande de base du téléphone mobile. S'il s'agit d'une application payante, le processeur hôte HP1 est de préférence un processeur sécurisé, par exemple un processeur de carte SIM, car 15 l'accès au service nécessite une identification de l'abonné. Applications carte (CAP) Le principe de fonctionnement du mode émulation de carte est décrit par le brevet EP 1 327 222 (US 7 098 20 770) au nom de la demanderesse. Une application carte (CAPi) est exécutée par le processeur hôte HP1 (Cf. Fig. 1). Ce dernier place le contrôleur NFCC dans un mode de fonctionnement passif et forme, avec le contrôleur NFCC, l'équivalent d'un circuit intégré sans contact, qui est 25 vu par un lecteur RD comme une carte sans contact. Ainsi, le contrôleur NFCC n'émet pas de champ magnétique, reçoit des données en démodulant un champ magnétique FLD émis par le lecteur RD et émet des données par modulation de l'impédance de son circuit d'antenne (modulation de 30 charge). Les applications concernées sont généralement des applications au paiement ou au contrôle d'accès payant (machine de paiement, entrée de métro, etc.). Le dispositif portatif HD est donc utilisé dans ce cas comme une carte à puce. Ce type d'application est le plus 35 souvent sécurisé et le processeur hôte HP1 qui exécute le
programme application est dans ce cas un processeur sécurisé, par exemple un processeur de carte SIM. Architecture normalisée d'un dispositif NFC A l'intérieur du dispositif NFC, le bus BS1 supporte généralement une interface de communication dite HCI ("Host Controller Interface") par l'intermédiaire de laquelle le contrôleur NFCC et le processeur hôte HP1 échangent des données conformément au protocole HCP ("Host Controller Protocol"). Ce protocole prévoit un routage des données selon des canaux de routage appelés "pipes" ("tuyaux") décrits dans les demandes EP 1 855 229 (US 2007/0263595) ou EP 1 855 389 (US 2007/0263596) au nom de la demanderesse. L'interface HCI et le protocole HCP sont également 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)". Par ailleurs, les commandes et les réponses à des commandes échangées au cours d'une transaction entre le processeur hôte HP1 et un dispositif externe, tel quel que le circuit intégré sans contact passif CIC ou le lecteur RD, sont définies par les spécifications NFCForum-TS-Type-4-Tag intitulées "Type 4 Tag Operation". Également, le format des données échangées au cours d'une transaction NFC est défini par les spécifications NFCForum-TS-NDEF intitulées "NFC Data Exchange Format (NDEF)". Comme illustré sur la figure 1, ces diverses spécifications définissent une architecture de dispositif NFC dans laquelle le contrôleur NFCC exécute une ou plusieurs technologies RFTi (modes de fonctionnement de l'interface CLF, par exemple Type A, Type B, Type B' et Type F) tandis que le processeur hôte HP1 exécute des applications lecteur RAPi et des applications carte CAPi.
Chaque technologie RFTi est accessible par l'intermédiaire d'une porte de lecteur RF RRFG ("Reader RF Gate") ou d'une porte de carte RF CRFG ("Card RF Gate"). Chaque application lecteur RAPi comporte une porte d'application lecteur RAG ("Reader Application Gate") qui est connectée par l'intermédiaire d'un canal ("pipe") à une porte de lecteur RF RRFG associée à une technologie RFTi. De même, chaque application carte CAPi comporte une porte d'application carte CAG ("Card Io Application Gate") qui est connectée par l'intermédiaire d'un canal ("pipe") à une porte de carte RF CRFG associée à une technologie RFTi. A chaque porte de lecteur RRFG ou de carte CRFG est associé un registre appelé "registry" qui contient des paramètres nécessaires à la gestion du 15 canal RF selon la technologie RFTi que l'application lecteur ou l'application carte utilise. Commandes échangées lors de l'exécution d'une application lecteur Lors de l'exécution d'une application lecteur RAPi, 20 le processeur hôte HP1 configure l'interface CLF en mode actif par l'intermédiaire d'une porte d'application lecteur RAG. L'application lecteur RAPi active une porte RAG sollicite de l'administrateur HCI (organe logiciel exécuté par le contrôleur NFCC) l'ouverture d'un canal Pl 25 entre la porte RAG et une porte RRFG associée à une technologie RFTi qu'elle veut utiliser. L'application RAPi émet ensuite des commandes CAPDU qui sont transmises au contrôleur NFCC par l'intermédiaire du canal Pl puis sont transmises au circuit intégré CIC par 30 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 hôte HP1 par l'intermédiaire du canal P1. Commandes échangées lors de l'exécution d'une 35 application carte Lors de l'exécution d'une application carte CAPi, le processeur hôte HP1 émule une carte sans contact passive et utilise l'interface CLF en mode passif. L'application carte CAPi active une porte CAG et s sollicite de l'administrateur HCI l'ouverture d'un canal P2 entre la porte CAG et une porte CRFG associée à une technologie RFTi qu'elle veut utiliser. Le lecteur RD envoie au contrôleur NFCC des commandes CAPDU que ce dernier transmet au processeur hôte HP1 par 10 l'intermédiaire du canal P2. Le processeur hôte HP1 émet des réponses RAPDU qui sont transmises au contrôleur NFCC par l'intermédiaire du canal P2, puis sont transmises au lecteur RD par le contrôleur NFCC, par l'intermédiaire d'un canal RF. 15 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 et sont précisées au point 5 des spécifications "Type 4 Tag Operation". En résumé, dans l'état de la technique, le 20 processeur hôte HP1 émet des commandes CAPDU lorsqu'il fonctionne en mode lecteur et conduit une transaction avec un circuit intégré sans contact CIO, et le circuit intégré sans contact CIO renvoie des réponses RAPDU au processeur hôte. Inversement, lorsqu'il fonctionne en 25 mode émulation de carte, le processeur hôte HP1 reçoit des commandes CAPDU émises par un lecteur RD et renvoie des réponses RAPDU au lecteur RD. Il est connu que le développement de la technologie NEC est étroitement lié au développement des applications 30 de type émulation de carte, qui permettent d'utiliser un dispositif portatif HD en tant que carte à puce sans contact. Bien que des infrastructures équipées de lecteurs NFC existent déjà, notamment dans le domaine du contrôle d'accès, ces infrastructures sont peu nombreuses 35 et ne se développent pas à une cadence suffisante pour
permettre le développement souhaité de la technologie NFC. En particulier, une contrainte qui freine le développement des infrastructures NEC est le prix de revient des lecteurs NFC eux-mêmes, ainsi que le coût de leur installation sur les lieux de l'application. Un lecteur étant un dispositif actif qui émet un champ magnétique, il présente une certaine complexité et un coût non négligeable, et doit être raccordé à une source d'alimentation électrique. io Il peut donc être souhaité de prévoir un procédé pour conduire une transaction NFC et un dispositif NFC qui permette de mettre en oeuvre des applications carte sans la contrainte que nécessite l'installation d'un parc de lecteurs. 15 La présente invention inclut l'observation que, lors d'une transaction en mode émulation de carte, le contrôleur NFC n'utilise pas les ressources de l'interface sans contact CLF en ce qui concerne ses moyens d'émission d'un champ magnétique. Il pourrait donc 20 être considéré qu'une transaction conduite entre un lecteur NFC dans le mode actif et un contrôleur NFC dans le mode passif représente un "gaspillage" de ressources, puisque chacun des deux éléments possède des moyens d'émission de champ magnétique, ceux du contrôleur NFC 25 n'étant pas utilisés. Sur le fondement de cette observation, des modes de réalisation de l'invention concernent un procédé pour conduire une transaction entre un dispositif NFC et un passif, couplé circuit intégré sans contact 30 comprenant un contrôleur NFC communication sans contact, et processeur hôte comprenant au d'application carte, le procédé consistant à : prévoir dans le le dispositif NFC à une interface de au moins un premier moins un programme comprenant des étapes circuit intégré sans 35 contact au moins un programme d'émulation d'application
lecteur configuré pour fournir des premières commandes d'application lecteur et traiter des premières réponses d'application carte, et au moyen d'un organe intermédiaire du dispositif NFC : placer l'interface de communication sans contact dans un mode actif où elle émet un champ magnétique et établir une communication avec le circuit intégré sans contact ; recevoir du circuit intégré sans contact des premières commandes d'application lecteur et les transférer au premier Io processeur hôte ; et recevoir du premier processeur hôte des premières réponses d'application carte et les transférer au circuit intégré sans contact. Selon un mode de réalisation, le procédé comprend des étapes consistant à prévoir dans l'organe 15 intermédiaire un premier programme d'inversion de protocole; prévoir dans le circuit intégré sans contact un second programme d'inversion de protocole configuré pour coopérer avec le programme d'émulation d'application lecteur; établir entre le premier et le second programmes 20 d'inversion une communication sans contact dans laquelle l'organe intermédiaire agit en tant que lecteur relativement au circuit intégré sans contact; et, par l'intermédiaire du second et du premier programmes d'inversion transférer au premier processeur hôte des 25 premières commandes d'application lecteur fournies par le programme d'émulation d'application lecteur, et transférer au programme d'émulation d'application lecteur des premières réponses d'application carte fournies par l'application carte du premier processeur hôte. 30 Selon un mode de réalisation, le procédé comprend les étapes suivantes, conduites par l'organe intermédiaire : recevoir du premier processeur hôte des premières réponses d'application carte, les encapsuler dans des secondes commandes d'application lecteur et 35 transférer les secondes commandes d'application lecteur au circuit intégré sans contact; recevoir du circuit intégré sans contact des premières commandes d'application lecteur encapsulées dans des secondes réponses d'application carte; désencapsuler les premières s commandes d'application lecteur et les transférer au premier processeur hôte. Selon un mode de réalisation, les premières commandes d'application lecteur émises par le programme d'émulation d'application lecteur et les premières io réponses d'application carte émises par le programme d'application carte sont au format APDU ISO 7816. Selon un mode de réalisation, les secondes commandes d'application lecteur et les secondes réponses d'application carte sont au format APDU ISO 7816. 15 Selon un mode de réalisation, le procédé comprend une étape consistant à fournir au premier processeur hôte, au moyen de l'organe intermédiaire, des commandes d'interface ROI choisies de manière à faire croire au premier processeur hôte que les premières commandes 20 d'application lecteur reçues du circuit intégré sans contact sont émises par un lecteur NFC dans le mode actif. Selon un mode de réalisation, le procédé comprend une étape consistant à mettre à la disposition du premier 25 processeur hôte, dans un registre, des paramètres de canal RF choisis de manière à faire croire au premier processeur hôte que les premières commandes d'application lecteur reçues du circuit intégré sans contact sont émises par un lecteur NFC dans le mode actif. 30 Selon un mode de réalisation, l'organe intermédiaire est un contrôleur hôte du dispositif NFC. Selon un mode de réalisation, l'organe intermédiaire est un second processeur hôte du dispositif NFC. Des modes de réalisation de l'invention concernent 35 également un circuit intégré sans contact de type passif 2957173 io
agencé ou destiné à être solidaire d'un support fixe ou portatif, le circuit intégré comportant un programme d'émulation de lecteur NFC et étant configuré pour fournir des premières commandes d'application lecteur et s de traiter des premières réponses d'application carte reçues en réponse à des commandes d'application lecteur. Selon un mode de réalisation, le circuit intégré comprend un programme d'inversion de protocole configuré pour répondre à des secondes commandes d'application Io lecteur et fournir des secondes réponses d'application carte, et au moins un programme d'émulation d'application lecteur configuré pour fournir les premières commandes d'application lecteur et traiter les premières réponses d'application carte. 15 Selon un mode de réalisation, le circuit intégré est configuré pour recevoir des premières réponses d'application carte encapsulées dans des secondes commandes d'application lecteur, et encapsuler dans des secondes réponses d'application carte des premières 20 commandes d'application lecteur. Selon un mode de réalisation, le circuit intégré est configuré pour recevoir des premières réponses d'application carte et des secondes commandes d'application lecteur au format APDU ISO 7816, et émettre 25 des premières commandes d'application lecteur et des secondes réponses d'application carte au format APDU ISO 7816. Des modes de réalisation de l'invention concernent également un dispositif NFC comprenant un contrôleur NEC 30 couplé à une interface de communication sans contact, un premier processeur hôte comprenant au moinsun programme d'application carte et configuré pour traiter des premières commandes d'application lecteur et fournir des premières réponses d'application carte, et un organe 35 intermédiaire pour coordonner une transaction entre le
processeur hôte et un circuit intégré sans contact passif de type lecteur, l'organe intermédiaire étant configuré pour : placer l'interface de communication sans contact dans un mode actif où elle émet un champ magnétique; recevoir, par l'intermédiaire de l'interface de communication sans contact en mode actif, des premières commandes d'application lecteur émises par un circuit intégré sans contact passif de type lecteur et les transférer au premier processeur hôte; et recevoir des lo premières réponses d'application carte fournies par le premier processeur hôte et les transférer, par l'intermédiaire de l'interface de communication sans contact en mode actif, au circuit intégré sans contact passif de type lecteur. 15 Selon un mode de réalisation, l'organe intermédiaire est également configuré pour émettre par l'intermédiaire de l'interface de communication sans contact des secondes commandes d'application lecteur permettant de gérer une communication avec un circuit intégré sans contact passif 20 de type lecteur, et recevoir par l'intermédiaire de l'interface de communication sans contact des secondes réponses d'application carte émises par un circuit intégré sans contact passif de type lecteur. Selon un mode de réalisation, l'organe intermédiaire 25 est configuré pour encapsuler dans des secondes commandes d'application lecteur des premières réponses d'application carte fournies par le premier processeur hôte et transmettre les secondes commandes d'application lecteur par l'intermédiaire de l'interface de 30 communication sans contact, et recevoir, par l'intermédiaire de l'interface de communication sans contact, des secondes réponses d'application carte dans lesquelles sont encapsulées des premières commandes d'application lecteur, désencapsuler les premières commandes d'application lecteur et les transférer au premier processeur hôte. Selon un mode de réalisation, l'organe intermédiaire est configuré pour transmettre par l'intermédiaire de s l'interface de communication sans contact des secondes commandes d'application lecteur et des premières réponses d'application carte au format APDU ISO 7816, et recevoir par l'intermédiaire de l'interface de communication sans contact des secondes réponses d'application carte et des 10 premières commandes d'application lecteur au format APDU ISO 7816. Selon un mode de réalisation, l'organe intermédiaire est également configuré pour fournir au premier processeur hôte des commandes d'interface HCI choisies de 15 manière à faire croire au premier processeur hôte que les premières commandes d'application lecteur reçues d'un circuit intégré sans contact sont émises par un lecteur NFC dans le mode actif. Selon un mode de réalisation, l'organe intermédiaire 20 est également configuré pour fournir au premier processeur hôte des paramètres de canal RF choisis de manière à faire croire au premier processeur hôte que des commandes d'application lecteur reçues d'un circuit intégré sans contact sont émises par un lecteur NFC dans 25 le mode actif. Selon un mode de réalisation, l'organe intermédiaire est un contrôleur hôte du dispositif NFC. Selon un mode de réalisation, l'organe intermédiaire est un second processeur hôte du dispositif NFC. 30 Des modes de réalisation de l'invention concernent également un dispositif portatif, comprenant un dispositif NFC selon l'invention. Des modes de réalisation du procédé selon l'invention et de dispositifs NFC mettant en oeuvre ce 35 procédé seront exposés plus en détail dans la description
suivante, faite à titre non limitatif en relation avec les figures jointes parmi lesquelles - la figure 1 précédemment décrite représente l'architecture d'un dispositif NFC classique, - la figure 2 précédemment décrite représente des applications du dispositif NFC, - la figure 3 montre des étapes d'une transaction classique entre le dispositif NFC de la figure 1 et un lecteur NFC externe, Io la figure 4 montre des étapes d'une transaction classique entre le dispositif NFC de la figure 1 en mode lecteur et un circuit intégré sans contact, - la figure 5 représente l'architecture d'un mode de réalisation d'un dispositif NEC selon l'invention, 15 - la figure 6 représente des applications du dispositif NFC de la figure 5, - la figure 7 illustre une transaction entre le dispositif NFC de la figure 5 et un lecteur passif selon l'invention, 20 la figure 8 montre des étapes d'une transaction entre le dispositif NFC de la figure 5 et un lecteur passif selon l'invention, - la figure 9 représente l'architecture d'un autre mode de réalisation d'un dispositif NFC selon l'invention, 25 - la figure 10 illustre une transaction entre le dispositif NFC de la figure 9 et un lecteur passif selon l'invention, et - la figure 11 montre des étapes d'une transaction entre le dispositif NFC de la figure 9 et un lecteur passif 30 selon l'invention. La figure 3 montre des étapes d'une transaction classique entre le dispositif NFC de la figure 1 et un lecteur RD. La figure 4 montre des étapes d'une transaction classique entre le dispositif NFC de la 35 figure 1 et un circuit intégré sans contact CIC. Les
étapes montrées sur les figures 3, 4 mettent en jeu des commandes normalisées décrites par les spécifications ETSI TS 102 622, NFCForum-TS-Type-4-Tag et NFCForum-TSNDEF.
Transaction en mode émulation de carte La transaction représentée sur la figure 3 comprend les étapes d'initialisation suivantes : - un canal Pl est créé puis ouvert entre une application carte CAPi exécutée par le processeur hôte HP1 et une Io technologie RFTi exécutée par le contrôleur NFCC, par l'intermédiaire d'une porte d'application carte CAG et d'une porte de carte RF CRFG (étape "PIPE CREATE, PIPE OPEN") ; - le contrôleur NFCC détecte le champ magnétique émis par 15 le lecteur RD et envoie une commande EVT FIELD ON au processeur HP1 ; - le contrôleur NFCC conduit des étapes d'initialisation d'une communication avec le lecteur RD avec création d'un canal de communication RF, ainsi que des étapes 20 d'anticollision si d'autres dispositifs NFC ou cartes sans contact se trouvent dans le champ d'interrogation du lecteur RD (étape "INIT, ANTICOL") ; - lorsque la connexion avec le lecteur RD est établie, le contrôleur NFCC envoie une commande EVT CARD ACTIVATED au 25 processeur hôte HP1 pour lui indiquer qu'une transaction peut commencer ; La transaction proprement dite comprend ensuite les étapes suivantes : - l'envoi de commandes CAPDU par le lecteur RD au 30 processeur NFCC, via le canal de communication RF ; - la transmission de ces commandes au processeur hôte HP1 par le contrôleur NFCC, par l'intermédiaire du canal Pl, et sous une forme encapsulée dans des commandes EVT SEND DATA (commande de type "événement" du jeu de
commandes de l'interface HCI défini par les spécifications ETSI); - l'envoi au contrôleur NFCC, par l'application carte CAPi du processeur hôte processeur HP1, de réponses RAPDU, via le canal Pl et sous une forme encapsulée dans des commandes EVT SEND DATA ; et - la transmission des réponses RAPDU au lecteur RD par le contrôleur NFCC, via le canal RF. Il sera noté qu'une première commande CAPDU émise Io par le lecteur RD peut être une commande de sélection de l'application carte CAPi que le processeur hôte HP1 exécute, par exemple la commande "Tag Application Select" définie au point 6.4.2 des spécifications "Type 4 Tag Operation": 15 CLA INS P1 P2 Lc Data Le 00h A4h 04h 00h 07h D2760000850100h - La transaction peut être interrompue si le processeur hôte HP1 ne répond pas en renvoyant la réponse SW1-SW2=9000h (notation hexadécimale). 20 Lorsque la transaction est terminée (ou interrompue), le lecteur RD cesse d'émettre le champ magnétique et le contrôleur NFCC envoie au processeur hôte HP1 une commande EVT CARD DEACTIVATED de désactivation de l'application carte et une commande 25 EVT FIELD OFF indiquant que le champ magnétique n'est plus présent. Le canal Pl est ensuite fermé (étape "PIPE CLOSE"). Transaction en mode lecteur La transaction représentée sur la figure 4 30 comprend les étapes d'initialisation suivantes : - un canal P2 est créé puis ouvert entre une application lecteur RAPi du processeur hôte HP1 et une technologie RFTi du contrôleur NFCC, par l'intermédiaire d'une porte d'application lecteur RAG et d'une porte de lecteur RF RRFG (étapes "PIPE CREATE, PIPE OPEN") - l'application lecteur RAPi envoie à intervalles réguliers au contrôleur NFCC des commandes s d'interrogation EVT READER REQUESTED visant à détecter la présence du circuit intégré sans contact CIC (méthode d'interrogation dite "polling"); - lorsque le circuit intégré sans contact CIC est détecté, le contrôleur NFCC conduit des étapes "INIT, 10 ANTICOL" d'initialisation d'une communication avec le circuit intégré sans contact CIC avec création d'un canal de communication RF, et optionnellement des étapes d'anticollision (si d'autres circuits intégrés sans contact sont présents dans le champ) ; 15 - le contrôleur NFCC envoie la commande EVT TARGET DISCOVERED au processeur hôte HP1 pour lui indiquer qu'une transaction peut commencer ; La transaction proprement dite comprend ensuite les étapes suivantes : 20 ù l'envoi au contrôleur NFCC, par le processeur hôte HP1, de commandes CAPDU, via le canal P2, les commande 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 25 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 au processeur hôte HP1, par le contrôleur NFCC, via le canal P2, les 30 réponses RAPDU étant encapsulées dans des commandes WR XCHG DATA. Comme précédemment, une première commande CAPDU émise par le processeur hôte HP1 peut être une commande de sélection de l'application que le circuit intégré CIC 35 exécute, par exemple la commande décrite plus haut. La
transaction peut être interrompue si le circuit intégré sans contact CIC ne répond pas en renvoyant la réponse SW1-SW2=9000h (notation hexadécimale), ce qui signifie qu'il ne comporte pas d'application correspondant à l'application lecteur que le processeur hôte HP1 exécute. Lorsque la transaction est terminée (ou interrompue), le processeur hôte HP1 adresse au contrôleur NFCC une commande EVT END OPÉRATION de fermeture du canal RF, le canal P2 est ensuite fermé Io (étape "PIPE CLOSE"). 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. Leur format est précisé au point 5 des spécifications "Type 4 Tag Operation" 15 (NFCForum-TS-Type-4-Tag). Les commandes CAPDU préconisées par ces spécifications sont les commandes Select, ReadBinary, UpdateBinary, par exemple "Tag Application Select", "Capability Container Select", "NDEF Select", "Capability Container Read", "NDEF Read", "NDEF Update". 20 Les transactions classiques du type décrit ci-dessus définissent ainsi un circuit intégré sans contact passif comme un élément configuré pour traiter des commandes CAPDU émises par un lecteur et fournir des réponses RAPDU à des commandes d'application lecteur. 25 Exemples de transactions selon l'invention et architectures de dispositif NFC correspondantes Un procédé de transaction NFC selon l'invention prévoit un circuit intégré sans contact passif de type lecteur RCIC, désigné dans ce qui suit, par commodité, 30 "circuit intégré sans contact passif de type lecteur" ou "lecteur passif" car il forme l'équivalent d'un lecteur n'émettant pas de champ magnétique. Un tel lecteur passif est configuré pour fournir des commandes de type lecteur et traiter des réponses émises par- un processeur hôte en 35 mode émulation de carte. Il est généralement réalisé sous la forme d'un circuit intégré à microprocesseur ou microcontrôleur équipé d'une interface de communication sans contact, d'une mémoire programme (mémoire morte) et d'une mémoire de données (mémoire vive) et offrant une s capacité de calcul suffisante pour émuler le fonctionnement d'un lecteur. Un mode de réalisation du procédé selon l'invention prévoit également une architecture de dispositif NFC qui est conçue pour permettre à un processeur hôte du 10 dispositif configuré dans le mode émulation de carte de conduire une transaction avec un tel lecteur passif. La figure 5 représente un mode de réalisation d'une telle architecture de dispositif NFC. Le dispositif NFC est susceptible d'être intégré dans un dispositif 15 portatif HD ("Handheld Device") tel un téléphone portable, un PDA (Assistant Numérique Personnel), une carte active appelée "sticker" (carte destinée à être collée à l'arrière d'un téléphone mobile), une enveloppe de protection de téléphone mobile ("skins") etc. Le 20 dispositif NFC comprend un contrôleur NFCC et au moins un processeur hôte HP1 relié au contrôleur NFCC par un bus de donnée BS1, par exemple de type SWP ("Single Wire Protocol"). Le contrôleur NFCC comporte une interface sans contact CLF équipée d'une bobine d'antenne AC1, et 25 un contrôleur hôte HC. On suppose ici à titre non limitatif que le contrôleur NFCC présente toutes les fonctionnalités d'un contrôleur NFC classique, notamment qu'il implémente une ou plusieurs technologies RF RFTi, et qu'il est configuré pour activer une porte de lecteur 30 RF RRFG ou une porte de carte RF CRFG1 pour permettre au processeur hôte HP1 d'exécuter des applications lecteur RAPT et des applications carte CAPi en utilisant ces technologies RF. On suppose également que le processeur hôte HP1 comprend au moins une application carte CAPi au 35 moins une application lecteur RAPi, une porte
d'application carte CAG pour l'application carte CAPi et une porte d'application lecteur RAG pour l'application lecteur RAPi. Ainsi, le dispositif NFC peut conduire une transaction avec un circuit intégré sans contact CIC classique en ouvrant un canal Pl entre l'application lecteur RAPi et une technologie RFTi, par l'intermédiaire des portes RAG et RRFG. Il peut également conduire une transaction avec un lecteur RD classique, en ouvrant un canal P2 entre l'application carte CAPi et une technologie RFTi, par l'intermédiaire des portes CAG et CRFG1. Le dispositif NFCC comprend également une fonctionnalité PINVP1 appelée dans ce qui suit "programme d'inversion de protocole" ou "programme d'inversion". Le programme d'inversion PINVP1 est exécuté ici par le contrôleur hôte HC du contrôleur NFCC et est prévu pour établir une communication avec un lecteur passif RCIC selon l'invention, par l'intermédiaire d'une technologie RFTi et de l'interface CLF. Le programme d'inversion PINVP1 est également configuré pour activer une porte de carte RF CRFG2 et solliciter de l'administrateur HCI l'ouverture d'un canal P3 reliant la porte CRFG2 à une porte CAG d'une application carte CAPi du processeur hôte HP1, afin de transmettre au processeur hôte HP1 des commandes fournies par le lecteur passif RCIC comme s'il s'agissait de commandes reçues d'un véritable lecteur NFC ou dispositif équivalent, notamment un autre dispositif NFC fonctionnant en mode lecteur. Le programme d'inversion PINVP1 est également configuré pour recevoir du processeur hôte HP1 des réponses à de telles commandes, et les transmettre au lecteur passif RCIC. Des exemples d'application du dispositif NFC selon l'invention sont illustrés sur la figure 6, qui représente un dispositif portatif HD équipé du dispositif NEC de la figure 5, le dispositif HD étant ici un
téléphone mobile. On distingue les applications lecteur RAP et les applications carte CAP précédemment décrites en relation avec la figure 2. Parmi les applications carte CAP, on distingue une application supplémentaire selon la présente invention, à savoir une transaction entre le dispositif HD1 et un lecteur passif RCIC. Sur la figure 6, le lecteur passif RCIC est représenté comme une puce nue connectée à une bobine d'antenne AC2. Cet ensemble puce et bobine d'antenne est susceptible en pratique d'être intégré dans ou monté sur tout type de support portatif. Il peut par exemple se présenter sous forme d'étiquette électronique ("tag"), de carte sans contact, ou être directement intégré dans un support fixe quelconque.
L'avantage d'un tel lecteur passif RCIC est qu'il permet d'émuler la présence d'un lecteur NFC tel que le lecteur RD représenté sur la figure 5, sans les inconvénients liés à l'installation d'un véritable lecteur. Grâce à l'invention, il devient ainsi possible d'installer à moindre coût un parc de "lecteurs virtuels" formés par des lecteurs passifs RCIC selon l'invention. Dans un mode de réalisation de l'invention, il est souhaité que l'émulation d'un lecteur NFC au moyen du lecteur passif RCIC soit transparente pour le processeur hôte HP1, afin d'assurer la compatibilité de l'invention avec des processeurs hôtes classiques conçus pour dialoguer en mode émulation de carte avec de véritables lecteurs NFC, notamment des processeurs des cartes NFCSIM récemment commercialisées et prévues pour être associées à un contrôleur NFC en tant que processeurs hôtes. Dans un tel mode de réalisation, le programme d'inversion PINVP1 est configuré de manière à "faire croire" au processeur hôte HP1, pendant une transaction avec le lecteur passif RCIC, qu'il est en présence d'un véritable lecteur.
La figure 7 représente une architecture fonctionnelle du dispositif NFC et du lecteur passif RCIC conçue à cet effet et montre une application carte CAPi du processeur HP1 en train de conduire une transaction avec le lecteur passif RCIC. Chaque élément RCIC, NFCC, HP1 comporte des moyens de communication représentés sous la forme d'une couche physique PHL et d'une couche de liaison de données DLL. Chaque couche physique comprend des moyens hardwares et des moyens d'exécution de protocoles de bas niveau pour l'émission et la réception de données (modulation et démodulation de signaux, codage et décodage des données, etc.). Une couche physique PHLa du lecteur passif RCIC coopère avec une première couche physique PHLb du contrôleur NFCC, à savoir l'interface CLF, pour créer un canal de communication RF et assurer la transmission et la réception de données dans le canal RF. Une seconde couche physique PHLc du contrôleur NFCC coopère avec une couche physique PHLd du processeur hôte HP1 pour assurer la transmission de données sur le bus BS1. Les couches physiques PHLc, PHLd comprennent par exemple des moyens hardwares de gestion d'un bus SWP et des moyens d'exécution d'un protocole de bas niveau pour l'émission et la réception de données via le bus SWP. Au dessus des couches physiques, une couche de liaison de données DLLa du lecteur passif RCIC coopère avec une première couche de liaison de données DLLb du contrôleur NFCC, pour former une liaison de données DLL1 assurant le transport de données dans le canal RF créé par les couches physiques PHLa et PHLb. Le protocole de couche de liaison de données dépend de la technologie RFTi qui est activée par l'application lors d'une transaction, par exemple type A, type B, type B' ou type F, et est défini par les spécifications précédemment mentionnées. Une seconde couche de liaison de données DLLc du contrôleur NFCC coopère avec une couche de
liaison de données DLLd du processeur hôte HP1 pour former une liaison de données DLL2 assurant le transport de données entre le contrôleur NFCC et le processeur hôte HP1. Les couches DLLc, DLLd comprennent par exemple des couches de liaison de données SWP et des couches liaison de données HCI. Telle que définie par les spécifications ETSI TS 102 622, paragraphe 4.1 figure 1, une couche de liaison de données HCI comprend par exemple une couche d'administration HCI, une couche de routage HCP ("HCP routing"), une couche de transport de messages ("HCP messaging") et une couche "porte" ("gate layer") qui comprend les portes d'application carte ou lecteur et les portes de carte RF et les portes de lecteur RF. Enfin, au-dessus des couches liaison de données, le contrôleur NFCC comporte le programme d'inversion PINVP1, le processeur hôte HP1 comporte au moins une application carte CAPi, et le lecteur passif RCIC comporte un programme d'inversion de protocole PINVP2 coopérant avec un programme d'émulation d'application lecteur RAEP ("Reader Application Emulation Program"). Lors d'une transaction avec le lecteur passif RCIC, le programme d'inversion PINVP1 configure l'interface CLF en mode actif pour qu'elle émette un champ magnétique permettant d'établir un canal RF selon une technologie RFTi avec le lecteur passif RCIC. Le programme d'inversion PINVP1 dialogue ensuite avec le programme d'inversion PINVP2 du lecteur passif RCIC et lui adresse des commandes CAPDU2. Il reçoit des réponses RAPDU2 émises par le programme d'inversion PINVP2 dans lesquelles sont encapsulées les commandes CAPDU1 fournies par le programme RAEP, destinées au processeur hôte HP1. Le programme d'inversion PINVP1 désencapsule les commandes CAPDU1 et les communique à l'application carte CAPi du processeur hôte HP1 via un canal HCI, au moyen de commandes HCI. Le programme d'inversion PINVP1 reçoit
ensuite des réponses RAPDU1 émises par l'application carte CAPi du processeur hôte HP1, via l'interface HCI. Il les encapsule dans des commandes CAPDU2 qu'il envoie au lecteur passif RCIC via le canal RF. Le programme d'inversion PINVP2 du lecteur passif RCIC reçoit ces commandes, en extrait les réponses RAPDU1, et les communique au programme RAEP pour traitement, lequel fournit ensuite une nouvelle commande CAPDU1 et ainsi de suite jusqu'à ce que la transaction soit achevée. lo Une commande CAPDU comprend généralement des champs "CLA "INS", "Pl", "P2", "Lc", "DATA", "Le". Le champ "DATA" est un champ de données optionnel. L'encapsulation des réponses RAPDU1 dans des commandes CAPDU2 est faite par le programme d'inversion PINVP1 en insérant les 15 réponses RAPDU1 dans ce champ de données "DATA". De même, une réponse RAPDU, comprend généralement des champs DATA, SW1, SW2, le champ "DATA" étant également un champ de données optionnel. L'encapsulation des commandes CAPDU1 dans des réponses RAPDU2 est faite par le programme 20 d'inversion PINVP2 en insérant ces commandes CAPDU1 dans ce champ de données "DATA". L'application carte CAPi du processeur hôte HP1 reçoit donc, vie l'interface HCI, des commandes CAPDU1 qui semblent émises par un lecteur NFC, et renvoie au 25 lecteur "virtuel" des réponses CAPDU1. Sur la figure 7, une liaison en trait gras illustre une liaison virtuelle qui est établie entre l'application carte CAPi du processeur hôte HP1 et le programme d'émulation d'application lecteur RAEP du lecteur passif RCIC, par 30 l'intermédiaire des programmes d'inversion PINVP1, PINVP2. La figure 8 décrit plus en détail des étapes d'une transaction entre le processeur hôte HP1 et le lecteur passif RCIC. Cet exemple de mise en oeuvre de l'invention 35 se base sur les spécifications ETSI TS 102 622 en ce qui
concerne l'interface entre le processeur hôte HP1 et le contrôleur NFCC. On distingue une phase de détection ("DET") du lecteur passif RCIC, une phase d'initialisation de la transaction ("TINIT"), une phase de transaction proprement dite ("TRANSACTION") et une phase de fin de transaction (EOT). La phase de détection ("DET") vise à détecter la présence du lecteur passif RCIC. Celui-ci n'émettant pas Io de champ, il doit être détecté comme un circuit intégré sans contact classique, avant de constater qu'il comporte un programme d'émulation d'application lecteur RAEP. Cette phase de détection préalable peut être mise en oeuvre selon différentes méthodes. Dans un mode de 15 réalisation, le programme d'inversion PINVP1 est en permanence actif et demande régulièrement à l'interface CIL d'émettre le champ magnétique pour détecter la présence d'un circuit intégré sans contact, puis cherche à déterminer si ce circuit intégré sans contact est un 20 lecteur passif ou non. Dans un autre mode de réalisation, la détection du lecteur passif RCIC est confiée à une application lecteur RAPi situé dans le processeur 'hôte HP1 ou tout autre processeur hôte susceptible d'être relié au contrôleur NFCC. Cette seconde méthode est celle 25 qui sera décrite ci-après car elle est en conformité avec l'architecture de dispositif NFC telle que définie par les spécifications ETSI précitées, selon lesquelles le contrôleur NFCC émet le champ magnétique en réponse à des commandes fournies par des processeurs hôtes. 30 Phase de détection (DET) On suppose ici qu'une application lecteur RAPT, exécutée ici par le processeur hôte HP1, a été préalablement activée et est reliée au contrôleur NFCC par l'intermédiaire de portes RAG, RRFG et d'un canal Pl 35 (Cf. Fig. 5). L'application RAPi sonde régulièrement les
environs du dispositif NFC en adressant au contrôleur NFCC la commande EVT READER REQUESTED. Lorsque le lecteur passif RCIC est détecté, le contrôleur NFCC conduit des étapes d'initialisation d'un canal de communication RF, optionnellement d'anticollision, et d'activation du circuit intégré RCIC (étapes "INIT, ANTICOL"). Le contrôleur NFCC envoie ensuite à l'application RAPT la commande EVT TARGET DISCOVERED. L'application RAPT adresse ensuite au contrôleur NFCC la commande classique de sélection d'application "TagApplicationSelect". La commande est émise sous forme de commande CAPDU2 ("CAPDU2 [TagApplicationSelect]") et est adressée au contrôleur NFCC1 encapsulée dans la commande WR XCHG DATA. La commande CAPDU2 est transférée par le contrôleur NFCC au lecteur passif RCIC via le canal RF. Le lecteur passif RCIC renvoie une réponse particulière RAPDU2 contenant une information "ReaderTagType" signifiant qu'il forme un lecteur passif. Cette réponse particulière se distingue des réponses classiques telles que définies par la spécification NFCForum-TS-Type-4-Tag, table 3 section 5.2.2. Cette réponse peut être une réponse sans champ de données contenant un champ SWl-SW2 différent de celui habituellement renvoyé par un circuit intégré sans contact, par exemple le champ SW1-SW2=9001h (notation hexadécimale) au lieu du champ SW1-SW2=9000h. Dans un autre mode de réalisation, la réponse contient un champ SW1-SW2 standard de valeur 9000h mais contient un champ de données déterminé, signifiant que le circuit intégré est de type lecteur passif.
Phase d'initialisation de la transaction ("TINIT") La réponse particulière RAPDU2 provoque l'activation du programme d'inversion PINVP1 par le contrôleur NFCC. Le programme d'inversion PINVP1 active ensuite la porte de carte RF CRFG2 et génère un registre associé de type "registry" tel que décrit par ETSI TS 102 622 point
9.3.3.4. Ce registre volatile contient des paramètres du canal RF que l'application carte doit connaitre. La création et l'utilisation de ce registre ne seront pas décrites en détail ici et relèvent des compétences de l'homme de l'art. Il sera toutefois noté que le programme d'inversion PINVP1 peut placer dans ce registre des paramètres de canal RF qui ne correspondent pas à ceux du canal RF qui a été créé par le contrôleur NFCC pour accéder au lecteur passif RCIC. Ainsi, en sus de sa Io fonction d'émulation de lecteur NFC, le programme d'inversion PINVP1 peut permettre d'émuler une technologie RF vis-à-vis de l'application carte CAPi, notamment si l'application n'est pas compatible avec la technologie RF du lecteur passif RCIC. Par exemple, 15 pendant la phase de détection, l'application lecteur RAPi peut avoir détecté le lecteur passif RCIC en utilisant le protocole de type A. Toutefois, l'application carte pourrait être configurée pour dialoguer avec des lecteurs de type B. Dans un mode de réalisation, le programme 20 d'inversion de protocole PINVP1 extrait du registre ("registry") du contrôleur NFC l'information sur le type de protocole accepté par l'application carte CAPi. Ensuite, le programme d'inversion de protocole PINVP1 insère ou encapsule cette information dans une commande 25 CAPDU2[RequestforCAPDU] décrite plus loin, qui est envoyée au lecteur passif RCIC. Le programme d'émulation d'application lecteur RAEP du lecteur passif RCIC utilise ensuite le protocole de type B pour communiquer avec l'application carte CAPi, tandis que les programmes 30 d'inversion de protocole PINVP1 et PINVP2 continuent d'échanger des données en utilisant le protocole de type A. Ainsi, le protocole de transport de données utilisé entre le lecteur passif RCIC et l'interface sans contact CLF du contrôleur NFCC est "transparent" pour
l'application carte CAPi et le programme d'émulation d'application lecteur RAEP. Lorsque la porte de carte RF CRFG2 a été activée, le programme d'inversion PINVP1 sollicite auprès de l'administrateur HCI l'ouverture du canal P3 entre la porte CAG de l'application carte CAPi et la porte CRFG2 (étapes "PIPE CREATE, PIPE OPEN"). Le programme d'inversion envoie ensuite la commande EVT FIELD ON à l'application carte CAPi pour lui faire croire qu'un Io lecteur NFC émettant un champ magnétique a été détecté. La phase d'initialisation comprend ensuite l'envoi par le programme d'inversion PINVP1 d'une commande CAPDU2 de type CAPDU2[RequestforCAPDU] formant une demande de fourniture d'une première commande d'application lecteur 15 CAPDU1. Le lecteur passif RCIC répond par exemple au moyen d'une réponse du type RAPDU2(CAPDUI[SelAppX]), dans laquelle est encapsulée une commande CAPDU1 qui désigne l'application "X" à sélectionner ("SelAppX"). Sur réception de la réponse RAPDU2, le programme d'inversion 20 PINVP1 désencapsule la commande CAPDU1, adresse à l'application carte CAPi la commande EVT CARD ACTIVATED qui signifie que l'application doit devenir active, puis lui adresse la commande CAPDUI[SelAppX] encapsulée dans la commande "EVT SEND DATA". 25 Phase de transaction ("TRANSACTION") La phase de transaction proprement dite a été décrite plus haut en relation avec la figure 7. Elle comprend l'échange de commandes CAPDU1 et de réponses RAPDU1 entre l'application carte CAPi et le programme 30 d'émulation d'application lecteur RAEP. Plus précisément, en réponse à la commande CAPDUI[SelAppX] reçue au terme de la phase d'initialisation, l'application carte CAPi renvoie une première réponse RAPDU1, puis le programme RAEP renvoie une commande CAPDU1, et ainsi de suite 35 jusqu'à la fin de la transaction. Les commandes CAPDU1 et
les réponses RAPDU1 sont respectivement encapsulées dans des réponses RAPDU2 et des commandes CAPDU2 lorsqu'elles sont transmises dans le canal RF, et sont encapsulées dans des commandes HCP "EVT SEND DATA" lorsqu'elles sont transmises dans le canal P3 de l'interface HCI. Le programme d'inversion PINVP1 se charge de l'encapsulation des réponses RAPDU1 dans des commandes CAPDU2 et de la désencapsulation des commandes CAPDU1 présentes dans les réponses RAPDU2. La porte de carte RF CRFG2 se charge de lo l'encapsulation des commandes CAPDU1 et des réponses RAPDU1 dans des commandes "EVT SEND DATA". Phase de fin de transaction (EOT) La transaction se termine par l'envoi d'une commande particulière CAPDU2 par le lecteur passif RCIC ou par 15 l'absence d'envoi d'une nouvelle commande par celui-ci. Le programme d'inversion PINVP1 assure alors la fermeture du canal RF en demandant au processeur hôte HP1 de cesser d'émettre le champ et il adresse à l'application lecteur CAPi les commandes "EVT CARD DEACTIVATED" puis 20 "EVT FIELD OFF". Le canal P3 est ensuite fermé (étape <PIPE CLOSE>). On a décrit dans ce qui précède un mode de réalisation de l'invention dans lequel le programme d'inversion PINVP1 est exécuté par le contrôleur hôte HC 25 du contrôleur NFCC. Dans d'autres modes de réalisation, le programme d'inversion peut être exécuté par un autre organe du dispositif NFC, par exemple un second processeur hôte HP2, qui agit alors en tant qu'intermédiaire entre le contrôleur NFCC et le 3o processeur hôte HP1. Une tel mode de réalisation sera maintenant décrit. Programme d'inversion exécuté par un processeur hôte La figure 9 représente un autre mode de réalisation d'un dispositif NFC selon l'invention, intégré dans un 35 dispositif portatif HD. Le dispositif NFC comprend le
contrôleur NFCC, le processeur hôte HP1 et un second processeur hôte HP2. Le processeur hôte HP2 est relié au contrôleur NFCC par un bus BS2, par exemple un bus asynchrone reliant des interfaces UART ("Universal Asynchronous Receiver Transmitter") du contrôleur NFCC et du processeur hôte HP2. Le processeur hôte HP1 est relié au contrôleur NFCC par le bus BS1 décrit plus haut et au processeur hôte HP2 par un bus BS3, par exemple un bus ISO 7816. Le processeur HP2 est par exemple un processeur io bande de base de téléphone mobile et le processeur HP1 un processeur sécurisé tel qu'un processeur de carte SIM. Le contrôleur NFCC comprend comme précédemment une interface sans contact CLF équipée d'une bobine d'antenne ACl et un contrôleur hôte HC. On suppose comme 15 précédemment, à titre non limitatif, que le processeur hôte HP1 présente toutes les fonctionnalités d'un contrôleur NEC classique, notamment qu'il peut mettre en oeuvre une ou plusieurs technologies RF RFTi et qu'il est configuré pour activer une porte de lecteur RF RRFG ou 20 une porte de carte RF CRFG1 pour permettre aux processeurs hôtes HP1, HP2 d'exécuter des applications lecteur RAPi et des applications carte CAPi. On suppose également que les processeurs hôtes HP1, HP2 comprennent chacun au moins une application carte CAPi et une 25 application lecteur RAPT. Ainsi, le dispositif NFC peut conduire une transaction avec un circuit intégré sans contact CIC classique en ouvrant un canal Pl entre une application lecteur RAPi exécutée par le processeur hôte HP1 et une technologie RFTi, ou un canal P4 entre une 30 application lecteur RAPi exécutée par le processeur hôte HP2 et une technologie RFTi, par l'intermédiaire de portes RAG et RRFG. Il peut également conduire une transaction avec un lecteur RD classique en ouvrant un canal P2 entre une application carte CAPi exécutée par le 35 processeur hôte HP1 et une technologie RFTi, ou un canal
P5 entre une application carte CAPi exécutée par le processeur hôte HP2 et une technologie RFTi, par l'intermédiaire de portes CAG et CRFG1. Par ailleurs, le processeur hôte HP2 comprend également un programme d'inversion de protocole PINVP3 selon l'invention. Ce programme d'inversion PINVP3 est configuré pour établir une communication avec un lecteur passif RCIC selon l'invention, par l'intermédiaire d'une technologie RFTi et de l'interface CLF, et recevoir du lecteur passif RCIC des commandes CAPDU1 et les communiquer au processeur hôte HP1 comme s'il s'agissait de commandes reçues d'un véritable lecteur NFC. Il est également configuré pour recevoir du processeur hôte HP1 des réponses RAPDU1 à de telles commandes, et les fournir au lecteur passif RCIC pour traitement. A cet effet, le programme d'inversion PINVP3 est configuré pour activer une porte d'application lecteur RAG et solliciter de l'administrateur HCI l'ouverture d'un canal P6 reliant la porte RAG à une porte de lecteur RF RRFG associée à une technologie RFTi. Le programme d'inversion PINVP3 est également configuré pour activer une porte de carte RF CRFG2 et solliciter de l'administrateur HCI l'ouverture d'un canal P7 reliant la porte de carte RF CRFG2 à une porte CAG d'une application carte CAPi exécutée par le processeur hôte HP1. La figure 10 est une vue d'ensemble d'une architecture fonctionnelle du dispositif NFC et du lecteur passif RCIC permettant à l'application carte CAPi du processeur HP1 de conduire une transaction avec le lecteur passif RCIC, par l'intermédiaire du processeur HP2 et du contrôleur NFCC. Chaque élément RCIC, NFCC, HP1, HP2 comporte une couche physique PHL et une couche de liaison de données DLL. Une couche physique PHLa du lecteur passif RCIC coopère avec une première couche physique PHLb du contrôleur NFCC, à savoir l'interface CLF, pour créer un canal de communication RF et assurer la transmission et la réception de données dans le canal RF. Une seconde couche physique PHLc du contrôleur NFCC coopère avec une première couche physique PHLd du s processeur hôte HP2 pour assurer la transmission de données sur le bus BS2. Les couche physique PHLc, PHLd sont par exemple des interfaces UART. Une seconde couche physique PHLe du processeur hôte HP2 coopère avec une couche physique PHLf du processeur hôte HP1 pour assurer Io la transmission de données sur le bus BS2. Les couches physiques PHLe, PHLf sont par exemple des interfaces de bus ISO 7816. De même, une couche de liaison de données DLLa du lecteur passif RCIC coopère avec une première couche de 15 liaison de données DLLb du contrôleur NFCC pour former une liaison de données DLL1 assurant le transport de données dans le canal RF créé par les couches physiques PHLa et PHLb, selon une technologie RFTi (par exemple de type A, B, B' ou F). Une seconde couche de liaison de 20 données DLLc du contrôleur NFCC coopère avec une première couche de liaison de données DLLd du processeur hôte HP2 pour former une liaison de données DLL2 assurant le transport de données entre le contrôleur NFCC et le processeur hôte HP2. Les couches de liaison de données 25 DLLc, DLLd comprennent par exemple une couche de liaison de données asynchrone et une couche de liaison de données HCI. Enfin, une seconde couche de liaison de données DLLe du processeur hôte HP2 coopère avec une couche de liaison de données DLLf du processeur hôte HP1 pour former une 30 liaison de données DLL3 assurant le transport de données entre le processeur hôte HP2 et le processeur hôte HP1. Les couches de liaison de données DLLe, DLLf comprennent par exemple une couche de liaison de données ISO 7816 et une couche de liaison de données HCI.
Enfin, au-dessus des couches liaison de données, le contrôleur NFCC comporte une technologie RFTi et une porte de lecteur RF RRFG, le processeur hôte HP2 comporte le programme d'inversion PINVP3 et le processeur hôte HP1 comporte une application carte CAPi. Le lecteur passif RCIC comporte comme précédemment le programme d'inversion PINVP2 coopérant avec le programme d'émulation d'application lecteur RAEP. Le programme d'inversion PINVP3 comprend une lo fonction RAPL (sous-programme) formant l'équivalent d'une application lecteur, pour détecter puis établir une communication avec le lecteur passif RCIC en tant que circuit intégré sans contact, par l'intermédiaire du contrôleur NFCC. Ainsi, au moyen de la fonction RAPL, le 15 programme d'inversion PINVP3 configure l'interface CLF en mode actif pour qu'elle émette un champ magnétique et établisse un canal RF selon une technologie RFTi avec le lecteur passif RCIC. Le programme d'inversion PINVP3 dialogue ensuite avec le programme d'inversion PINVP2 du 20 lecteur passif RCIC et lui adresse des commandes CAPDU2. Il reçoit des réponses RAPDU2 émises par le programme d'inversion PINVP2 dans lesquelles sont encapsulées les commandes CAPDU2 fournies par le programme RAEP. Il désencapsule les commandes CAPDU1 et les communique à 25 l'application carte CAPi du processeur hôte HP1 via le canal P7 de l'interface HCI. Le programme d'inversion PINVP3 reçoit ensuite des réponses RAPDU1 émises par l'application carte CAPi du processeur hôte HP1, via le canal P7 de l'interface HCI. Il les encapsule dans des 30 commandes CAPDU2 qu'il envoie au lecteur passif RCIC via le canal P6 de l'interface HCI et le canal RF. Le programme d'inversion PINVP2 reçoit ces commandes, en extrait les réponses RAPDU1, et les communique au programme RAEP pour traitement, lequel fournit ensuite
une nouvelle commande CAPDU1 et ainsi de suite jusqu'à ce que la transaction soit achevée. La figure 11 décrit plus en détail des étapes d'une transaction entre le processeur hôte HP1 et le lecteur passif RCIC. On distingue une phase de détection ("DET") du lecteur passif RCIC, une phase d'initialisation de la transaction ("INIT"), une phase de transaction proprement dite ("TRANSACTION") et une phase de fin de transaction (EOT). io On suppose dans cet exemple de réalisation que le programme d'inversion PINVP3 est configuré pour détecter lui-même la présence du lecteur passif RCIC, au moyen de la fonction RAPL, en adressant cycliquement des commandes HCI "EVT READER REQUESTED" au contrôleur NFCC. Toutefois, 15 la phase de détection du lecteur passif RCIC pourrait aussi être conduite par une application lecteur du processeur hôte HP2, voire une application lecteur du processeur hôte HPl. Dans ce cas, la détection du lecteur passif RCIC provoquerait l'activation du programme 20 d'inversion PINVP3. Phase de détection (DET) La phase de détection comprend donc ici l'activation préalable du programme d'inversion PINVP3 et la création du canal P6 entre le programme PINVP3 et le contrôleur 25 NFCC, au moyen d'une porte d'application lecteur RAG (Cf. Fig. 9), au cours d'étapes "PIPE CREATE, PIPE OPEN". Ensuite, le programme d'inversion PINVP3 sonde régulièrement les environs du dispositif NFC en adressant au contrôleur NFCC la commande EVT READER REQUESTED. 30 Lorsque le lecteur passif RCIC est détecté, le contrôleur NFCC conduit des étapes d'initialisation d'un canal de communication RF, et optionnellement d'anticollision, et d'activation du circuit intégré (étapes "INIT, ANTICOL"). Le contrôleur NFCC envoie ensuite à l'application lecteur 35 RAPi la commande EVT TARGET DISCOVERED. Le programme d'inversion PINVP3 adresse ensuite au contrôleur NFCC une commande de sélection d'application "TagApplicationSelect". La commande est du type "CAPDU2 [TagApplicationSelect]") et est encapsulée dans la s commande WR XCHG DATA dans le canal P6. La commande CAPDU2 est transférée par le contrôleur NFCC au lecteur passif RCIC via le canal RF. Le lecteur passif RCIC renvoie une réponse RAPDU2 particulière contenant une information "ReaderTagType" signifiant qu'il forme un 10 lecteur passif. Comme indiqué plus haut, cette réponse RAPDU2 particulière se distingue d'une réponse classique de circuit intégré sans contact. Il peut s'agir d'une réponse contenant un champ SW1-SW2 différent de celui habituellement renvoyé par un circuit intégré sans 15 contact, par exemple SWl-SW2=9001h (notation hexadécimale), ou d'une réponse contenant un champ SW1-SW2 standard de valeur 9000h et un champ de données déterminé signifiant que le circuit intégré est de type lecteur passif. Cette réponse particulière est 20 communiquée au programme d'inversion PINVP3 au moyen de la commande WR XCHG DATA, via le canal P6. Phase d'initialisation de la transaction ("TINIT") La réponse RAPDU particulière conduit le programme d'inversion PINVP3 à activer la porte de carte RF CRFG2 25 ainsi qu'un registre associé de type "registry" contenant des paramètres du canal RF. Comme précédemment le programme d'inversion PINVP3 peut placer dans ce registre des paramètres de canal RF qui ne correspondent pas à ceux du canal RF qui a été créé par le contrôleur NFCC 30 pour accéder au lecteur passif RCIC. Le programme d'inversion PINVP3 sollicite ensuite auprès de l'administrateur HCI l'ouverture du canal P7 reliant la porte CRFG2 à la porte CAG de l'application carte CAPi du processeur hôte HP1 (étapes "PIPE CREATE, 35 PIPE OPEN"). Le programme d'inversion PINVP3 envoie
ensuite la commande EVT FIELD ON a l'application carte CAPi pour lui faire croire qu'un lecteur NFC émettant un champ magnétique a été détecté. La phase d'initialisation comprend également l'envoi au lecteur passif RCIC d'une commande CAPDU2 de type CAPDU2[RequestforCAPDU] formant une demande de fourniture d'une commande d'application lecteur CAPDU1. Le programme d'inversion PINVP3 envoie cette commande au contrôleur NFCC via le canal P6 au moyen d'une commande WR XCHG DATA et le processeur hôte HP1 la répercute au lecteur passif RCIC. Le lecteur passif RCIC répond au moyen d'une réponse de type RAPDU2(CAPDUI[SelAppX]) dans laquelle est encapsulée une commande CAPDU1. La commande CAPDU1 est par exemple une commande de sélection d'une application ux,, à sélectionner ("SelAppX"). La réponse RAPDU2 contenant la commande CAPDU1 est transmise au programme d'inversion PINVP3 via le canal P6 sous forme encapsulée dans une commande WR XCHG DATA. Sur réception de la réponse RAPDU2, le programme d'inversion PINVP3 désencapsule la commande CAPDU1, adresse à l'application carte CAPi, via le canal P7, la commande EVT CARD ACTIVATED, puis lui adresse la commande CAPDUl[SelAppX] encapsulée dans la commande "EVT SEND DATA".
Phase de transaction ("TRANSACTION") La phase de transaction décrite plus haut en relation avec la figure 10 comprend l'échange de commandes CAPDU1 et de réponses RAPDU1 entre l'application carte CAPi et le programme d'émulation d'application lecteur RAEP. Plus précisément, en réponse à la commande CAPDUl[SelAppX] reçue au terme de la phase d'initialisation, l'application carte CAPi renvoie une première réponse RAPDU1, puis le programme d'émulation d'application lecteur RAEP du lecteur passif RCIC renvoie
une commande CAPDU1, et ainsi de suite jusqu'à la fin de la transaction. Les commandes CAPDU1 et les réponses RAPDU1 sont respectivement encapsulées dans des réponses RAPDU2 et des commandes CAPDU2 lorsqu'elles sont transmises dans le canal RF. Les réponses RAPDU2 et les commandes CAPDU2 sont elles-mêmes encapsulées dans des commandes WR XCHG DATA lorsqu'elles circulent dans le canal P6 entre le contrôleur NFCC1 et le programme d'inversion io PINVP3. Les réponses RAPDU1 et les commandes CAPDU1 sont encapsulées dans des commandes EVT SEND DATA lorsqu'elles circulent dans le canal P7 entre le programme d'inversion PINVP3 et l'application carte CAPi. La porte d'application lecteur RAG du programme d'inversion PINVP3 15 se charge de l'encapsulation des commandes CAPDU2 dans des commandes "WR XCHG DATA" et de la désencapsulation des réponses RAPDU1 présentes dans les commandes WR XCHG DATA. Le programme d'inversion PINVP1 se charge de l'encapsulation des réponses RAPDU1 dans des commandes 20 CAPDU2 et de la désencapsulation des commandes CAPDU1 présentes dans les réponses RAPDU2. La porte de carte RF CRFG2 se charge de l'encapsulation des commandes CAPDU1 et des réponses RAPDU1 dans des commandes "EVT SEND DATA" (Cf. Fig. 9). 25 Phase de fin de transaction (EOT) La transaction de termine par l'envoi d'une commande particulière CAPDU2 par le lecteur passif RCIC ou par l'absence d'envoi d'une nouvelle commande par celui-ci. Le programme d'inversion PINVP3 assure alors la fermeture 30 du canal RF en demandant au processeur hôte HP1 de cesser d'émettre le champ, et adresse à l'application lecteur CAPi les commandes HCP "EVT CARD DEACTIVATED" puis "EVT FIELD OFF". Le canal P7 entre les porte CRFG2 et CAG est ensuite fermé (étape <PIPE CLOSE>). 35 Variantes de réalisation et applications
Il apparaîtra clairement à l'homme de l'art que la présente invention est susceptible de diverses applications. De façon générale, un lecteur passif RCIC selon l'invention est susceptible d'être intégré dans tout type de dispositif portatif ou fixe. Les termes "carte", "carte à puce sans contact" ou "étiquette" ("tag") ont la même signification et désignent un support équipé d'un lecteur passif RCIC selon l'invention. Un lecteur passif selon l'invention étant destiné à être utilisé en tant que lecteur et non en tant que circuit intégré de carte à puce sans contact, il n'est pas nécessairement intégré dans un support portatif et peut être agencé dans ou sur un support fixe, par exemple des portiques de paiement ou de contrôle d'accès. Également, bien qu'un tel lecteur passif ait été présenté comme un circuit intégré sans contact, le terme "sans contact" désigne l'interface de communication que le lecteur passif utilise pour échanger des données avec le dispositif NEC et ne signifie aucunement que le circuit intégré ne peut pas être équipé de contacts. Le lecteur passif RCIC pourrait en effet être réalisé au moyen d'un circuit intégré dit "combi" comprenant à la fois une interface de communication à contact (par exemple des contacts ISO 7816) et une interface de communication sans contact. Par ailleurs le terme "passif" ne doit pas être interprété comme signifiant qu'un circuit intégré sans contact formant un lecteur passif selon l'invention ne comporte aucun moyen pour émettre un champ magnétique et/ou qu'il n'émet aucun champ magnétique pendant une transaction. En effet, selon le principe de fonctionnement du mode émulation de carte tel que décrit par le brevet EP 1 327 222 (US 7 098 770), une modulation de charge passive peut également être émulée par des émissions de courte durée de champ magnétique, qui sont
perçues par l'organe émettant le champ principal comme des signaux de modulation de charge. Le terme "passif" signifie donc simplement qu'un lecteur passif RCIC selon l'invention n'émet pas le champ magnétique principal permettant de conduire la transaction, à l'inverse d'un lecteur conventionnel. On a décrit dans ce qui précède des modes de réalisation de l'invention compatibles avec les spécifications du NFC Forum en ce qui concerne Io l'interface de communication entre le dispositif NFC et le lecteur passif RCIC, cette compatibilité étant notamment assurée grâce à l'encapsulation de commandes et réponses CAPDU1 et RAPDU1 dans des réponses et commandes RAPDU2 et CAPDU2 circulant dans le canal RF. De même, on 15 a décrit des modes de réalisation de l'invention compatibles avec les spécifications ETSI en ce qui concerne l'interface de communication entre le contrôleur NFCC et le processeur hôte HP1 (premier mode de réalisation, ou en ce qui concerne l'interface de 20 communication entre le contrôleur NFCC1 et les processeurs hôtes HP1, HP2 et entre les processeurs hôtes HP1, HP2 (second mode de réalisation), grâce à l'utilisation de canaux HCI ("pipes") et de commandes HCP. L'invention peut toutefois être mise en œuvre d'une 25 manière différente dans des applications où il n'est pas nécessaire ou souhaité d'assurer la compatibilité avec de telles spécifications. Ainsi, dans des modes de réalisation de l'invention, le lecteur passif RCIC peut fournir des commandes CAPDU1 qui ne sont pas encapsulées 30 dans des réponses RAPDU2 à des commandes CAPDU2 envoyées par le dispositif NFC et le contrôleur NFCC1 peut envoyer au lecteur passif RCIC des réponses RAPDU1 qui ne sont pas encapsulées dans des commandes CAPDU2. De même le programme d'inversion PINVP1 ou PINVP3 peut transférer au 35 processeur hôte HP1 des commandes fournies par le lecteur
passif RCIC sans les encapsuler dans des commandes HCI. Également, les commandes et les réponses peuvent ne pas être au format APDU et peuvent présenter tout format pouvant être conçu par l'homme de l'art. Dans de tels modes de réalisation, un protocole est prévu pour distinguer d'une part des commandes et des réponses (CAPDU2, RAPDU2) qui permettent de gérer une communication entre le programme d'inversion PINVP1 ou PINVP3 du dispositif NFC et le programme d'inversion Io PINVP2 du lecteur passif RCIC, et d'autre part des commandes et des réponses (CAPDU1, RAPDUI) relatives à la transaction entre le programme d'émulation RAEP du lecteur passif et l'application carte du processeur hôte HP1. Ce protocole permet au programme d'inversion PINVP1 15 ou PINVP3 du dispositif NFC et au programme d'inversion PINVP2 du lecteur passif RCIC de distinguer les commandes ou les réponses qui les concernent et les commandes ou les réponses qu'ils doivent transférer aux programmes de niveau supérieur, respectivement l'application carte CAPi 20 et le programme d'émulation RAEP.

Claims (22)

  1. REVENDICATIONS1. Procédé pour conduire une transaction entre un dispositif NFC et un circuit intégré sans contact passif (RCIC), le dispositif NFC comprenant : - un contrôleur NFC (NFCC) couplé à une interface de 5 communication sans contact (CLF), et - au moins un premier processeur hôte (HP1) comprenant au moins un programme d'application carte (CAPi), procédé caractérisé en ce qu'il comprend des étapes consistant à : 10 - prévoir dans le circuit intégré sans contact (RCIC) au moins un programme d'émulation d'application lecteur (RAEP) configuré pour fournir des premières commandes d'application lecteur (CAPDUI) et traiter des premières réponses d'application carte (RAPDUI), et 15 - au moyen d'un organe intermédiaire (HC, HP2) du dispositif NFC : - placer l'interface de communication sans contact (CLF) dans un mode actif où elle émet un champ magnétique et établir une communication avec le 20 circuit intégré sans contact (RCIC), - recevoir du circuit intégré sans contact (RCIC) des premières commandes d'application lecteur (CAPDUI) et les transférer au premier processeur hôte (HP1), et 25 - recevoir du premier processeur hôte (HP1) des premières réponses d'application carte (RAPDUl) et les transférer au circuit intégré sans contact (RCIC). 30
  2. 2. Procédé selon la revendication 1, comprenant des étapes consistant à : 40 - prévoir dans l'organe intermédiaire (HC, HP2) un premier programme d'inversion de protocole (PINVP1, PINVP3), - prévoir dans le circuit intégré sans contact (RCIC) un second programme d'inversion de protocole (PINVP2) configuré pour coopérer avec le programme d'émulation d'application lecteur (RAEP), - établir entre le premier et le second programmes d'inversion une communication sans contact dans laquelle Io l'organe intermédiaire (HC, HP2) agit en tant que lecteur relativement au circuit intégré sans contact (RCIC), et, - par l'intermédiaire du second et du premier programmes d'inversion : - transférer au premier processeur hôte (HP1) des 15 premières commandes d'application lecteur (CAPDUl) fournies par le programme d'émulation d'application lecteur (RAEP), et - transférer au programme d'émulation d'application lecteur (RAEP) des premières réponses d'application 20 carte (RAPDUI) fournies par l'application carte (CAPi) du premier processeur hôte.
  3. 3. Procédé selon l'une des revendications 1 et 2, comprenant les étapes suivantes, conduites par l'organe 25 intermédiaire : - recevoir du premier processeur hôte (HP1) des premières réponses d'application carte (RAPDUI), les encapsuler dans des secondes commandes d'application lecteur (CAPDU2) et transférer les secondes commandes 30 d'application lecteur (CAPDU2) au circuit intégré sans contact (RCIC), - recevoir du circuit intégré sans contact (RCIC) des premières commandes d'application lecteur (CAPDUl) encapsulées dans des secondes réponses d'application 35 carte (RAPDU2), désencapsuler les premières commandes d'application lecteur (CAPDUl) et les transférer au premier processeur hôte (HP1).
  4. 4. Procédé selon l'une des revendications 1 à 3, dans lequel les premières commandes d'application lecteur (CAPDUl) émises par le programme d'émulation d'application lecteur et les premières réponses d'application carte émises par le programme d'application carte (CAPi) sont au format APDU ISO 7816.
  5. 5. Procédé selon la revendication 3, dans lequel les secondes commandes d'application lecteur (CAPDU2) et les secondes réponses d'application carte (RAPDU2) sont au format APDU ISO 7816.
  6. 6. Procédé selon l'une des revendications 1 à 5, comprenant une étape consistant à fournir au premier processeur hôte (HP1), au moyen de l'organe intermédiaire (NFCC, HP2), des commandes d'interface HCI choisies de manière à faire croire au premier processeur hôte que les premières commandes d'application lecteur (CAPDUl) reçues du circuit intégré sans contact (RCIC) sont émises par un lecteur NFC dans le mode actif.
  7. 7. Procédé selon l'une des revendications 1 à 6, comprenant une étape consistant à mettre à la disposition du premier processeur hôte (HP1), dans un registre, des paramètres de canal RF choisis de manière à faire croire au premier processeur hôte que les premières commandes d'application lecteur (CAPDUl) reçues du circuit intégré sans contact (RCIC) sont émises par un lecteur NFC dans le mode actif.
  8. 8. Procédé selon l'une des revendications 1 à 7, dans lequel l'organe intermédiaire est un contrôleur hôte (HC) du dispositif NEC.
  9. 9. Procédé selon l'une des revendications 1 à 8, dans lequel l'organe intermédiaire est un second processeur hôte (HP2) du dispositif NFC.
  10. 10. Circuit intégré sans contact (RCIC) de type passif agencé ou destiné à être solidaire d'un support fixe ou portatif, caractérisé en ce qu'il comporte un programme (RAEP) d'émulation de lecteur NFC et est configuré pour fournir des premières commandes d'application lecteur (CAPDUl) et de traiter des premières réponses d'application carte (RAPDUl) reçues en réponse à des commandes d'application lecteur .
  11. 11. Circuit intégré sans contact selon la revendication 10, comprenant : - un programme d'inversion de protocole (PINVP2) configuré pour répondre à des secondes commandes d'application lecteur (CAPDU2) et fournir des secondes réponses d'application carte (RAPDU2), et - au moins un programme d'émulation d'application lecteur (RAEP) configuré pour fournir les premières commandes d'application lecteur (CAPDUl) et traiter les premières réponses d'application carte (RAPDUl).
  12. 12. Circuit intégré sans contact (RCIC) selon l'une 30 des revendications 10 et 11, configuré pour : - recevoir des premières réponses d'application carte (RAPDUl) encapsulées dans des secondes commandes d'application lecteur (CAPDU2), et - encapsuler dans des secondes réponses d'application carte (RAPDU2) des premières commandes d'application lecteur (CAPDUI).
  13. 13. Circuit intégré sans contact (RCIC) selon l'une des revendications 11 et 12, configuré pour : - recevoir des premières réponses d'application carte (RAPDUI) et des secondes commandes d'application lecteur (CAPDU2) au format APDU ISO 7816, et - émettre des premières commandes d'application lecteur (CAPDUI) et des secondes réponses d'application carte (RAPDU2) au format APDU ISO 7816.
  14. 14. Dispositif NFC comprenant : - un contrôleur NFC (NFCC) couplé à une interface de communication sans contact (CLF), et - un premier processeur hôte (HP1) comprenant au moins un programme d'application carte (CAPi) et configuré pour traiter des premières commandes d'application lecteur (CAPDUI) et fournir des premières réponses d'application carte (RAPDUI), caractérisé en ce qu'il comprend un organe intermédiaire (HC, HP2) pour coordonner une transaction entre le processeur hôte (HP1) et un circuit intégré sans contact passif (RCIC) de type lecteur, l'organe intermédiaire étant configuré pour : - placer l'interface de communication sans contact (CLF) dans un mode actif où elle émet un champ magnétique, recevoir, par l'intermédiaire de l'interface de communication sans contact en mode actif, des premières commandes d'application lecteur (CAPDUI) émises par un circuit intégré sans contact passif de type lecteur et les transférer au premier processeur hôte (HP1), et - recevoir des premières réponses d'application carte (RAPDUl) fournies par le premier processeur hôte (HP1) et les transférer, par l'intermédiaire de l'interface de communication sans contact en mode actif, au circuit intégré sans contact passif (RCIC) de type lecteur.
  15. 15. Dispositif NFC selon la revendication 14, dans lequel l'organe intermédiaire (HC, HP2) est également configuré pour : - émettre par l'intermédiaire de l'interface de communication sans contact (CLF) des secondes commandes d'application lecteur (CAPDU2) permettant de gérer une communication avec un circuit intégré sans contact passif de type lecteur, et - recevoir par l'intermédiaire de l'interface de communication sans contact (CLF) des secondes réponses d'application carte (RAPDU2) émises par un circuit intégré sans contact passif de type lecteur.
  16. 16. Dispositif NFC selon l'une des revendications 14 et 15, dans lequel l'organe intermédiaire (HC, HP2) est 20 configuré pour : - encapsuler dans des secondes commandes d'application lecteur (CAPDU2) des premières réponses d'application carte (RAPDUl) fournies par le premier processeur hôte (HP1) et transmettre les secondes commandes d'application 25 lecteur (CAPDU2) par l'intermédiaire de l'interface de communication sans contact, et - recevoir, par l'intermédiaire de l'interface de communication sans contact, des secondes réponses d'application carte (RAPDU2) dans lesquelles sont 30 encapsulées despremières commandes d'application lecteur (CAPDUl), désencapsuler les premières commandes d'application lecteur (CAPDUl) et les transférer au premier processeur hôte (HP1).
  17. 17. Dispositif NFC selon l'une des revendications 15 et 16, dans lequel l'organe intermédiaire (HC, HP2) est configuré pour - transmettre par l'intermédiaire de l'interface de communication sans contact des secondes commandes d'application lecteur (CAPDU2) et des premières réponses d'application carte (RAPDUI) au format APDU ISO 7816, et - recevoir par l'intermédiaire de l'interface de communication sans contact des secondes réponses d'application carte (RAPDU2) et des premières commandes d'application lecteur (CAPDU1) au format APDU ISO 7816.
  18. 18. Dispositif NFC selon l'une des revendications 14 à 17, dans lequel l'organe intermédiaire (NFCC, HP2) est également configuré pour fournir au premier processeur hôte (HP1) des commandes d'interface HCI choisies de manière à faire croire au premier processeur hôte que les premières commandes d'application lecteur (CAPDUl) reçues d'un circuit intégré sans contact (RCIC) sont émises par un lecteur NFC dans le mode actif.
  19. 19. Dispositif NFC selon l'une des revendications 14 à 17, dans lequel l'organe intermédiaire (NFCC, HP2) est également configuré pour fournir au premier processeur hôte (HP1) des paramètres de canal RF choisis de manière à faire croire au premier processeur hôte que des commandes d'application lecteur (CAPDUI) reçues d'un circuit intégré sans contact (RCIC) sont émises par un lecteur NFC dans le mode actif.
  20. 20. Dispositif NFC selon l'une des revendications 14 à 19, dans lequel l'organe intermédiaire est un contrôleur hôte (HC) du dispositif NFC.
  21. 21. Dispositif NFC selon l'une des revendications 14 à 19, dans lequel l'organe intermédiaire est un second processeur hôte (HP2) du dispositif NFC. s
  22. 22. Dispositif portatif (HD), caractérisé en ce qu'il comprend un dispositif NFC selon l'une des revendications 14 à 21.
FR1000871A 2010-03-04 2010-03-04 Procede pour conduire un transaction au moyen d'un dispositif nfc Expired - Fee Related FR2957173B1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR1000871A FR2957173B1 (fr) 2010-03-04 2010-03-04 Procede pour conduire un transaction au moyen d'un dispositif nfc
EP11001493.3A EP2363825B1 (fr) 2010-03-04 2011-02-23 Procédé pour conduire une transaction au moyen d'un dispositif NFC
CA2733304A CA2733304C (fr) 2010-03-04 2011-02-25 Procede pour conduire une transaction au moyen d'un dispositif nfc
KR1020110019607A KR101819100B1 (ko) 2010-03-04 2011-03-04 Ｎｆｃ 장치를 이용한 트랜잭션 수행 방법
CN201110052419.8A CN102194085B (zh) 2010-03-04 2011-03-04 借助nfc设备进行事务处理的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1000871A FR2957173B1 (fr) 2010-03-04 2010-03-04 Procede pour conduire un transaction au moyen d'un dispositif nfc

Publications (2)

Publication Number Publication Date
FR2957173A1 true FR2957173A1 (fr) 2011-09-09
FR2957173B1 FR2957173B1 (fr) 2013-10-18

Family

ID=43014986

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1000871A Expired - Fee Related FR2957173B1 (fr) 2010-03-04 2010-03-04 Procede pour conduire un transaction au moyen d'un dispositif nfc

Country Status (2)

Country Link
CN (1) CN102194085B (fr)
FR (1) FR2957173B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2717193A1 (fr) * 2012-09-21 2014-04-09 Kabushiki Kaisha Toshiba Carte CI, dispositif électronique portable et dispositif de lecture/écriture

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5633336B2 (ja) 2010-11-29 2014-12-03 ソニー株式会社 通信装置および通信方法、通信制御装置および通信制御方法、並びにプログラム
CN103825632B (zh) * 2012-11-16 2016-08-03 纬创资通股份有限公司 应用近场通信的信息快速同步方法
CN103503323B (zh) * 2013-03-05 2015-02-04 华为终端有限公司 近场通信射频通信方法、装置和终端设备
US9559753B2 (en) * 2013-03-15 2017-01-31 Keyssa, Inc. Virtualized physical layer adapted for EHF contactless communication
FR3105663B1 (fr) * 2019-12-23 2022-09-09 St Microelectronics Rousset Configuration d'une transaction dans un dispositif électronique sans contact
FR3105662B1 (fr) * 2019-12-23 2021-11-26 St Microelectronics Rousset Configuration d'une transaction dans un dispositif électronique sans contact

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080006695A1 (en) * 2006-07-06 2008-01-10 Sony Corporation Information processing system, and information processing apparatus and method

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6157966A (en) * 1997-06-30 2000-12-05 Schlumberger Malco, Inc. System and method for an ISO7816 complaint smart card to become master over a terminal
JP5205720B2 (ja) * 2006-05-12 2013-06-05 ソニー株式会社 通信システムおよび通信方法、デバイス、情報処理装置、並びにプログラム
FR2903549B1 (fr) * 2006-07-10 2008-09-26 Inside Contactless Sa Procede de controle d'application dans un chipset nfc comprenant plusieurs processeurs hotes
FR2905782B1 (fr) * 2006-09-11 2008-12-05 Inside Contactless Sa Procede de connexion d'un circuit integre sans contact a un composant nfc.

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080006695A1 (en) * 2006-07-06 2008-01-10 Sony Corporation Information processing system, and information processing apparatus and method

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2717193A1 (fr) * 2012-09-21 2014-04-09 Kabushiki Kaisha Toshiba Carte CI, dispositif électronique portable et dispositif de lecture/écriture
US9542632B2 (en) 2012-09-21 2017-01-10 Kabushiki Kaisha Toshiba IC card, portable electronic device, and reader/writer

Also Published As

Publication number Publication date
CN102194085A (zh) 2011-09-21
CN102194085B (zh) 2015-10-07
FR2957173B1 (fr) 2013-10-18

Similar Documents

Publication Publication Date Title
EP2455922B1 (fr) Procédé et système de transaction NFC
FR2957173A1 (fr) Procede pour conduire un transaction au moyen d&#39;un dispositif nfc
CA2971635C (fr) Procede de traitement d&#39;une transaction a partir d&#39;un terminal de communication
CA2659756C (fr) Procede de routage de donnees d&#39;application entrantes dans un chipset nfc, par identification de l&#39;application
EP2002376B1 (fr) Procédé d&#39;allocation dynamique des contacts d&#39;une carte à puce d&#39;abonné dans un terminal mobile, ainsi que programme et terminal mobile correspondants
EP2203835A1 (fr) Procédé et dispositif de gestion de données d&#39;application dans un système nfc en réponse à l&#39;émission ou la réception de données sans contact
EP2764481B1 (fr) Procédé et système pour executer une transaction sans contact autorisant de multiples applications et de multiples instances d&#39;une même application
WO2008006958A2 (fr) Procede de controle d&#39;application dans un chipset nfc comprenant plusieurs processeurs hotes
FR2901077A1 (fr) Procede de routage de donnees entrantes et sortantes dans un jeu de puces nfc
FR3035252A1 (fr) Procede de gestion de la communication d&#39;informations entre un controleur nfc et un element securise au sein d&#39;un appareil, et appareil et controleur nfc correspondants
US8958746B2 (en) Mobile integrated distribution and transaction system and method for NFC services, and a mobile electronic device thereof
EP2065857A2 (fr) Carte à microprocesseur, téléphone comprenant une telle carte et procédé d&#39;exécution d&#39;une commande dans une telle carte
EP2901391A1 (fr) Procede de protection de donnees sensibles transmises dans un systeme nfc
EP2363825B1 (fr) Procédé pour conduire une transaction au moyen d&#39;un dispositif NFC
WO2011039123A1 (fr) Procede, systeme et dispositif d&#39;adaptation permettant un echange de donnees entre un objet de communication et une unite de traitement
EP2065858A2 (fr) Carte à microprocesseur, téléphone comprenant une telle carte et procédé d&#39;exécution d&#39;une commande dans une telle carte
EP3552327B1 (fr) Procédé de personnalisation d&#39;une transaction sécurisée lors d&#39;une communication radio
WO2022162289A1 (fr) Procédé et dispositif d&#39;adaptation d&#39;une communication en champ proche
WO2020078930A1 (fr) Gestion de transactions dans un dispositif nfc
EP3813330B1 (fr) Procédés et dispositifs d&#39;appairage
FR3017733A1 (fr) Titre non renseigne.
EP2817951B1 (fr) Systeme de telecommunication
EP3177998B1 (fr) Procédé de consultation de l&#39;état d&#39;une ressource d&#39;un appareil électronique, entité électronique associée et appareil électronique équipé d&#39;une telle entité électronique
FR2992806A1 (fr) Systeme de transmission securisee de donnees numeriques
WO2020115378A1 (fr) Système de personnalisation utilisant une communication en champ proche

Legal Events

Date Code Title Description
CA Change of address

Effective date: 20140129

CD Change of name or company name

Owner name: INSIDE SECURE, FR

Effective date: 20140129

PLFP Fee payment

Year of fee payment: 6

CL Concession to grant licences

Name of requester: FRANCE BREVETS, FR

Effective date: 20151027

PLFP Fee payment

Year of fee payment: 7

ST Notification of lapse

Effective date: 20171130