FR2901077A1

FR2901077A1 - Data routing method for near field communication chipset of e.g. computer, involves sending data to destination point by encapsulating data in frame, and searching destination point in routing table using channel number as selection index

Info

Publication number: FR2901077A1
Application number: FR0604180A
Authority: FR
Inventors: Bruno Charrat
Original assignee: Inside Contactless SA
Current assignee: Inside Secure SA
Priority date: 2006-05-10
Filing date: 2006-05-10
Publication date: 2007-11-16
Anticipated expiration: 2026-05-10
Also published as: FR2901077B1; CN101079013A; CN101072051B; CN101072051A; CN101079013B

Abstract

The method involves defining a data path by attributing a routing channel number (CHANi) and storing the number and routing parameters in a routing table (RT) responsive to a data path opening control (CMD) designating a destination point in a radio frequency identification type contact less data transmitting/receiving interface (CLINT), where the path connects source points (P1, P2) and destination point. The data is sent to the destination point from source points by encapsulating the data in a frame. A data destination point is searched in the table using the number as a selection index. An independent claim is also included for a device for transmitting and receiving data.

Description

PROCÉDÉ DE ROUTAGE DE DONNÉES ENTRANTES ET SORTANTES DANS UN CHIPSET NFCMETHOD FOR ROUTING INPUT AND OUTGOING DATA IN AN NFC CHIPSET

La présente invention concerne un procédé de routage de données dans un jeu de puces comprenant au moins un processeur hôte et une interface d'émission/réception de données sans contact de type RFID. La présente invention concerne également un circuit d'émission/réception de données comprenant une interface d'émission/réception de données sans contact de type RFID, un contrôleur et au moins un port d'entrée/sortie pour relier l'interface d'émission/réception de données à un processeur hôte. La présente invention concerne notamment la réalisation d'un chipset NFC (Near Field Communication). La technologie NFC est actuellement développée par 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 lecteurs NFC présentant plusieurs modes de fonctionnement, à savoir un mode "lecteur" (Reader Mode), un mode "émulation de carte", et un mode "device " (appelé également mode "device-todevice" soit "dispositif à dispositif"). Dans le mode "lecteur", le lecteur NFC fonctionne comme un lecteur RFID conventionnel pour accéder en lecture ou écriture à une puce RFID (carte à puce ou étiquette sans contact). Il émet un champ magnétique, envoie des données par modulation dje l'amplitude du champ magnétique et reçoit des données par modulation de charge et couplage inductif. Dans le mode "émulation", décrit par le brevet EP 1 327 222 au nom de la demanderesse, le lecteur NFC fonctionne de façon passive à la manière d'un transpondeur pour dialoguer avec un autre lecteur et être vu par l'autre lecteur comme une puce RFI:D. Le lecteur The present invention relates to a method for routing data in a chipset comprising at least one host processor and an RFID-free contactless data transmission / reception interface. The present invention also relates to a data transmission / reception circuit comprising an RFID-type contactless transmission / reception interface, a controller and at least one input / output port for connecting the transmission interface. / receiving data to a host processor. The present invention relates in particular to the realization of a chipset NFC (Near Field Communication). NFC technology is being developed by an industry consortium called the NFC Forum (http://www.nfc-forum.org). NFC technology is derived from RFID (Radio Frequency Identification) technology and uses NFC readers with several modes of operation, namely a "Reader Mode", a "card emulation" mode, and a "device" mode. "(also referred to as" device-to-device "or" device-to-device "). In the "reader" mode, the NFC reader functions as a conventional RFID reader for reading or writing access to an RFID chip (smart card or contactless tag). It emits a magnetic field, sends data by modulating the magnitude of the magnetic field, and receives data by charge modulation and inductive coupling. In the "emulation" mode, described by the patent EP 1 327 222 in the name of the applicant, the NFC reader operates in a passive way in the manner of a transponder to dialogue with another reader and be seen by the other reader as an RFI chip: D. The reader

n'émet pas de champ magnétique, reçoit des données en démodulant un champ magnétique émis par l'autre lecteur et émet des données par modulation de l'impédance de son circuit d'antenne (modulation de charge). Dans le mode "device", le lecteur doit s'apparier avec un autre lecteur se trouvant également dans le même mode de fonctionnement, et chaque lecteur se place alternativement dans un état passif (sans émission de champ) pour recevoir des données et dans un état actif (avec émission de champ) pour émettre des données. En sus de ces trois modes de fonctionnement (d'autres modes de fonctionnement pourraient être imaginés dans le futur), un lecteur NFC peut mettre en oeuvre plusieurs protocoles de communication sans contact et est par exemple capable d'échanger des données suivant le protocole ISO 14443-A, le protocole ISO 14443-B, le protocole ISO 15693, etc.. Chaque protocole définit une fréquence d'émission du champ magnétique, une méthode de modulation de l'amplitude du champ magnétique pour émettre des données en mode actif, et une méthode de modulation de charge par couplage inductif pour émettre des données en mode passif. Un lecteur NFC est donc un dispositif multimode et multiprotocole. La demanderesse commercialise par exemple un lecteur NFC sous la désignation "MicroRead". En raison de ses capacités de communication étendues, un lecteur NFC est destiné à être intégré dans des dispositifs portatifs tels des téléphones portables ou des PDA (Assistant Numérique Personnel). On est donc amené à réaliser un chipset NFC du type représenté en figure 1, c'est à dire un ensemble de puces comprenant un lecteur NFC (référencé "NFCRl") et au moins un premier processeur hôte HP1. On entend par "processeur hôte" tout circuit intégré comprenant un microprocesseur ou un microcontrôleur et qui est connecté à un port du lecteur NFC. Dans de nombreuses applications, le ch:Lpset comprend également un second processeur hôte HP2. Le premier does not emit a magnetic field, receives data by demodulating a magnetic field emitted by the other reader and transmits data by modulating the impedance of its antenna circuit (charge modulation). In the "device" mode, the player must pair with another player that is also in the same operating mode, and each reader is alternately placed in a passive state (without field emission) to receive data and in a active state (with field emission) to transmit data. In addition to these three modes of operation (other modes of operation could be imagined in the future), an NFC reader can implement several contactless communication protocols and is for example able to exchange data according to the ISO protocol. 14443-A, the ISO 14443-B protocol, the ISO 15693 protocol, etc. Each protocol defines a transmission frequency of the magnetic field, a method of modulating the amplitude of the magnetic field to transmit data in active mode, and an inductively coupled load modulation method for transmitting passive mode data. An NFC reader is therefore a multimode and multiprotocol device. The Applicant sells for example an NFC reader under the designation "MicroRead". Due to its extensive communication capabilities, an NFC reader is intended to be integrated into portable devices such as mobile phones or PDAs (Personal Digital Assistant). It is therefore necessary to produce an NFC chipset of the type shown in FIG. 1, that is to say a set of chips comprising an NFC reader (referenced "NFCR1") and at least a first host processor HP1. The term "host processor" means any integrated circuit comprising a microprocessor or a microcontroller and which is connected to a port of the NFC reader. In many applications, the ch: Lpset also includes a second HP2 host processor. The first

processeur I-ôte HP1 est le processeur principal du dispositif dans lequel le lecteur NFC est embarqué, tandis que le second processeur hôte HP2 est un circuit sécurisé. Le processeur hôte HP1 est par exemple le circuit de bande de base d'un téléphone mobile ("baseband" ou circuit de radiotéléphonie) et le processeur hôte HP2 est par exemple une carte SIM (c'est-à-dire le microcontrôleur présent dans une carte SIM). Les ressources du lecteur NFC sont donc mises à la disposition des deux processeurs HP1 pour leur permettre de gérer des applications sans contact. De telles applications sont illustrées sur la figure 2 qui représente un téléphone mobile 30 équipé du chipset NFC de la figure 1. On distingue : 1) des applications de type API : le lecteur NFC du téléphone mobile 30 est en mode lecteur pour lire ou écrire un circuit intégré sans contact CLCT. Le téléphone mobile est dans ce cas utilisé comme un lecteur RFID. Ce type d'application peut être gratuit et consister par exemple dans la lecture de données publicitaires insérées dans un affichage publicitaire d'une aubette. L'application peut aussi être payante et consister par exemple dans la lecture d'informations réservées à des abonnés. Le programme de l'application AP1 est de préférence détenu et exécuté par le processeur HP1 si le service est gratuit ou sera de préférence détenu et exécuté par le processeur HP2 s'il est payant car il nécessite une identification de l'abonné. Ainsi, comme illustré en figure 1, une application API peut être prise en charge par le processeur HP1 ou le processeur HP2. 2) des applications de type AP2 : le lecteur NFC du téléphone 30 est en mode émulation de carte pour être lu par des lecteurs RD conventionnels dans des applications de paiement pu de contrôle d'accès payant (machine de paiement, entrée de métro, etc.). Le téléphone mobile 30 est alors utilisé comme une carte à puce. Le programme de l'application AP2 est de préférence détenu et exécuté par HP-I processor is the main processor of the device in which the NFC reader is embedded, while the second host processor HP2 is a secure circuit. The host processor HP1 is for example the baseband circuit of a mobile telephone ("baseband" or radiotelephone circuit) and the host processor HP2 is for example a SIM card (that is to say the microcontroller present in a SIM card). The resources of the NFC reader are therefore made available to both HP1 processors to enable them to manage contactless applications. Such applications are illustrated in FIG. 2 which represents a mobile telephone 30 equipped with the NFC chipset of FIG. 1. There are: 1) API type applications: the NFC reader of the mobile telephone 30 is in reader mode for reading or writing a contactless integrated circuit CLCT. The mobile phone is in this case used as an RFID reader. This type of application can be free and consist, for example, in the reading of advertising data inserted in an advertising display of a canopy. The application can also be paid and consist for example in reading information reserved for subscribers. The program of the AP1 application is preferably owned and executed by the processor HP1 if the service is free or will preferably be owned and executed by the processor HP2 if it is paid because it requires an identification of the subscriber. Thus, as illustrated in FIG. 1, an API application can be supported by the processor HP1 or the processor HP2. 2) applications of the AP2 type: the NFC reader of the telephone 30 is in card emulation mode to be read by conventional RD readers in paid payment control applications or payment access applications (payment machine, metro entrance, etc. .). The mobile phone 30 is then used as a smart card. The program of the AP2 application is preferably owned and executed by

le processeur sécurisé HP2, comme représenté en figure 1, car l'accès au service nécessite une identification de l'abonné. 3) des applications de type AP3 : le lecteur NFC du téléphone 30 est en mode "devise" et dialogue avec un autre dispositif, par exemple un lecteur embarqué dans un autre téléphone mobile 31 ou dans un ordinateur 32. Ce type d'application est généralement gratuit et permet de transférer des paquets de données d'un dispositif à l'autre (transfert de fichiers en point à point notamment). Le programme de l'application AP3 est de préférence détenu et exécuté par le processeur non sécurisé HP1, comme illustré en figure 1, qui dispose d'une puissance de calcul supérieure au processeur sécurisé HP2 si celui-ci est un processeur de carte SIM . Ainsi, la réalisation d'un chipset NFC nécessite de prévoir un routage des flux de données entre chacun des processeurs HP1, HP2 et le lecteur NFC (données émises via le canal de transmission de données sans contact) et des flux de données entrantes (données reçues via le canal de transmission de données sans contact) entre le lecteur NFC et chacun des processeurs HP1, HP2. Cela pose un certain nombre de problèmes pratiques qui seront compris en se référant aux figures 3A, 3B. the secure processor HP2, as shown in Figure 1, because access to the service requires identification of the subscriber. 3) AP3 type applications: the NFC reader of the telephone 30 is in "currency" mode and dialogue with another device, for example a reader embedded in another mobile phone 31 or in a computer 32. This type of application is generally free of charge and allows the transfer of data packets from one device to another (eg point-to-point file transfer). The program of the AP3 application is preferably owned and executed by the insecure processor HP1, as illustrated in Figure 1, which has a computing power greater than the secure processor HP2 if it is a SIM card processor. Thus, the realization of an NFC chipset requires routing of the data flows between each of the processors HP1, HP2 and the NFC reader (data transmitted via the contactless data transmission channel) and the incoming data streams (data received via the non-contact data transmission channel) between the NFC reader and each of the processors HP1, HP2. This poses a number of practical problems which will be understood with reference to Figs. 3A, 3B.

La figure 3A représente schématiquement l'architecture du lecteur NFC. Le lecteur comprend une interface d'émission/réception de données sans contact CLINT équipée d'un circuit d'antenne ACT, des interfaces de communication filaires INT1, INT2 reliées à l'interface CLINT, et un contrôleur NFCC. L'interface INT1 est connectée au processeur hôte HP1 et l'interface INT2 connectée au processeur hôte HP2, l'ensemble formant un chipset NF: (désigné "CHIPSET"). La figure 3B représente les flux de données devant être aiguillés pour que les ressources de l'interface d'émission/réception de données sans contact CLINT puissent être utilisées par chacun des processeurs HP1, Figure 3A schematically shows the architecture of the NFC reader. The reader comprises a CLINT contactless transmission / reception interface equipped with an antenna circuit ACT, wired communication interfaces INT1, INT2 connected to the interface CLINT, and a controller NFCC. The interface INT1 is connected to the host processor HP1 and the interface INT2 connected to the host processor HP2, the assembly forming a chipset NF: (designated "CHIPSET"). FIG. 3B shows the data streams to be switched so that the resources of the CLINT contactless transmission / reception interface can be used by each of the HP1 processors,

HP2. On suppose dans un souci de simplicité que l'interface CLINT peut émettre ou recevoir des données selon trois protocoles PT1, PT2, PT3 seulement, par exemple ISO 14443-A, ISO 14443-B et ISO 15693, et présente les trois modes de fonctionnement: M1, M2, M3 susmentionnés (mode lecteur, mode émulation et mode "device"). On distingue ainsi quatre types différents de flux de données : 1) un flux de données sortant DTlout(Mi, P^i) issu d'un point source Pl localisé dans le processeur HP1, transmis à un point de destination P3 localisé dans l'interface CLINT puis transmis par celle-ci dans un canal de transmission de données sans contact créé suivant un protocole PTi (PT1, PT2 ou PT3) et un mode de fonctionnement Mi (Ml, M2 ou M3), 2) un flux de données sortant DT2out(Mi, PTi) issu d'un point source P2 localisé dans le processeur HP2, transmis à un point de destination P3 localisé dans l'interface CLINT puis transmis par celle-ci via un canal de transmission de données sans contact créé suivant un protocole PTi et un mode de fonctionnement Mi, 3) un flux de données entrant DTlin(Mi, PTi) reçu par l'interface CLINT via un canal de transmission de données sans contact créé suivant un protocole PTi et un mode de fonctionnement Mi, puis transmis par l'interface CLINT à partir d'un point source P3 jusqu'à un point de destination Pl se trouvant dans le processeur HP1, 4) un flux de données entrant DT2in(Mi, PTi) reçu par l'interface CLINT via un canal de transmission de données sans contact créé suivant un protocole PTi et un mode de fonctionnement Mi, puis transmis par l'interface CLINT à partir d'un point source P3 jusqu'à un point de destination P2 se trouvant dans le processeur HP2. Chaque :_lux de données sortant pouvant être émis dans trois modes de fonctionnement Ml, M2, M3 et selon trois protocoles PT1, PT2, PT3 il vient que 9 configurations différentes sont possibles pour chaque HP2. It is assumed for the sake of simplicity that the CLINT interface can transmit or receive data according to three protocols PT1, PT2, PT3 only, for example ISO 14443-A, ISO 14443-B and ISO 15693, and presents the three modes of operation. : M1, M2, M3 mentioned above (reader mode, emulation mode and "device" mode). There are thus four different types of data streams: 1) an outgoing data flow DTlout (Mi, P ^ i) from a source point Pl located in the processor HP1, transmitted to a destination point P3 located in the CLINT interface then transmitted by it in a contactless data transmission channel created according to a PTi protocol (PT1, PT2 or PT3) and an operating mode Mi (Ml, M2 or M3), 2) an outgoing data flow DT2out (Mi, PTi) from a source point P2 located in the processor HP2, transmitted to a destination point P3 located in the CLINT interface and then transmitted by it via a contactless data transmission channel created according to a PTi protocol and an operating mode Mi, 3) an incoming data stream DTlin (Mi, PTi) received by the CLINT interface via a contactless data transmission channel created according to a protocol PTi and an operating mode Mi, then transmitted by the CLINT interface from a point source P3 to a destination point P1 located in the processor HP1; 4) an incoming data stream DT2in (Mi, PTi) received by the interface CLINT via a contactless data transmission channel created according to a protocol PTi and an operating mode Mi, then transmitted by the CLINT interface from a source point P3 to a destination point P2 located in the processor HP2. Each: _lux of outgoing data can be emitted in three operating modes Ml, M2, M3 and according to three protocols PT1, PT2, PT3 it comes that 9 different configurations are possible for each

flux de données sortant (en supposant que chaque combinaison mode Mi et protocole PTi soit: autorisée). Cela signifie qu'il ne suffit pas que l'un des processeurs HP1 ou HP2 envoie à l'interface CLINT les données à émettre. Le processeur doit également préciser, pour chaque chaîne de données émise, la configuration mode/protocole Mi/PTi à utiliser par l'interface CLINT pour transmettre ces données dans un canal de transmission de données sans contact. outgoing data stream (assuming that each Mi mode and PTi protocol combination is: allowed). This means that it is not enough for one of the HP1 or HP2 processors to send the data to be sent to the CLINT interface. The processor shall also specify, for each data string transmitted, the Mi / PTi mode / protocol configuration to be used by the CLINT interface to transmit this data in a contactless data transmission channel.

Pour permettre le routage de données sortantes tout en permettant de configurer l'interface CLINT de façon appropriée, il a été proposé de prévoir un protocole de transfert de données HCI ("Hast Controler Interface") de type "universel", permettant à tout type de processeur hôte de fournir à l'interface CLINT des données à émettre, tout en spécifiant la configuration à utiliser (protocole PTi et mode de fonctionnement Mi) pour transmettre :es données dans le canal de communication sans contact. Un tel protocole HCI prévoit des trames de données comprenant chacune des champs d'en-tête et des champs de données. Les champs d'en-tête comprennent les informations nécessaires au contrôle de l'interface CLINT, notamment des champs spécifiant les points de départ et de destination des données, le mode de fonctionnement et le protocole à utiliser par l'interface CLINT. Un premier problème que l'invention vise à résoudre est que le protocole HCI classique prévoit des trames de données ayant des champs d'en-tête longs et complexes, nécessitant un temps de traitement non négligeable avant le traitement: des données elles-mêmes. Ce problème est appelé "overheading", ce qui signifie que des en-têtes de trames trop longues surchargent les flux de données et grèvent le temps de transmission des données. Ces champs d'en-tête de grande taille nécessitent de plus des circuits tarrpon (buffers) de grande taille et une puissance de traitement élevée. To allow the routing of outgoing data while allowing to configure the CLINT interface appropriately, it has been proposed to provide a "universal" type HAS ("Hast Controler Interface") data transfer protocol, allowing any type host processor to provide the CLINT interface with data to be transmitted, while specifying the configuration to be used (PTi protocol and Mi operating mode) to transmit: the data in the contactless communication channel. Such an HCI protocol provides data frames each comprising header fields and data fields. The header fields include the information needed to control the CLINT interface, including fields specifying data start and destination points, the operating mode, and the protocol to be used by the CLINT interface. A first problem that the invention aims to solve is that the conventional HCI protocol provides data frames having long and complex header fields, requiring a significant processing time before processing: the data themselves. This problem is called overheading, which means that overly long frame headers overload data streams and strain the data transmission time. These large header fields also require large tarrpon circuits (buffers) and high processing power.

Ainsi, un premier objectif de la présente invention est de prévo:r un procédé de routage de données dans un chipset NFC qui soit simple à mettre en oeuvre et ne nécessite pas des champs d'en-tête de grande longueur, tout en permettant le paramétrage du protocole et du mode de fonctionnement de l'interface d'émission/réception de données sans contact. Un autre problème que l'invention vise à résoudre, distinct du premier problème, concerne le routage des données entrantes (DTlin et DT2in). Lorsque des données entrantes sont reçues, l'interface d'émission/réception de données sans contact CLINT ainsi que :e contrôleur NFCC ne savent pas nécessairement quel est le processeur hôte destinataire de ces données. En conséquence, les données sont envoyées aux deux processeurs, à charge au processeur qui n'est pas concerné par les données de ne pas y répondre. La demande WO 2004/029860 propose un procédé de routage qui consiste à utiliser, comme moyen de routage de données entrantes, le champ APDU (Application Protocol Data Unit) se trouvant dans des commandes reçues via le canal de transmission de données sans contact. Toutefois, comme indiqué en page 13 de cette demande, ce procédé nécessite que de nouveaux protocoles soient développés pour mettre en oeuvre le routage, ce qui signifie que l'organe externe émettant les données dans le canal de transmission de données sans contact doit spécifier à quel organe interne (quel processeur hôte) les données sont destinées. Thus, a first object of the present invention is to provide: a data routing method in an NFC chipset that is simple to implement and does not require very long header fields, while allowing the parameterization of the protocol and the operating mode of the contactless transmission / reception interface. Another problem that the invention aims to solve, distinct from the first problem, relates to the routing of incoming data (DTlin and DT2in). When incoming data is received, the CLINT contactless transmission / reception interface as well as the NFCC controller do not necessarily know which host processor is receiving this data. As a result, the data is sent to both processors, with the processor not affected by the data not being able to respond to it. The application WO 2004/029860 proposes a method of routing which consists in using, as means of routing incoming data, the APDU (Application Protocol Data Unit) field that is in commands received via the contactless data transmission channel. However, as indicated on page 13 of this application, this method requires that new protocols be developed to implement the routing, which means that the external device transmitting the data in the contactless data transmission channel must specify to which internal organ (which host processor) the data is intended for.

Or, dans de nombreuses applications, l'organe externe émettant des données n'est pas conçu pour donner des indications de routage permettant de savoir quel est le processeur destinataire de ces données. En effet le routage est un problème interne lié au fait que plusieurs processeurs d'un même chipset partagent la même interface d'émission/réception de données sans contact. Il est donc peu probable qu'un protocole de routage universel soit However, in many applications, the external device transmitting data is not designed to give routing indications to know which is the recipient processor of these data. Indeed the routing is an internal problem related to the fact that several processors of the same chipset share the same interface of emission / reception of data without contact. It is therefore unlikely that a universal routing protocol will be

intégré dans un proche avenir dans des dispositifs ne répondant pas à une norme NFC. Par exemple, un lecteur conventionnel utilisé pour du paiement ou du contrôle d'accès envoie des commandes d'authentification et/ou de vérification de code secret qui s'adressent à des cartes à puce sans contact. Au cours d'une authentification, un tel lecteur ne sait donc pas s'il s'adresse à une vraie carte sans contact ou à un chipset NFC en mode émulation de carte. Par conséquent, un tel lecteur n'est pas conçu pour émettre des paramètres permettant le routage, à l'intérieur du chipset, des données d'application qu'il envoie. Ainsi, un autre objectif de l'invention est de prévoir un procédé permettant de déterminer, dans un chipset NFC, le processeur hôte destinataire de données reçues via un canal de transmission de données sans contact, sans devoir nécessairement analyser le contenu de ces données. Au moins un objectif de l'invention est atteint par la prévision d'un procédé de routage de données dans un jeu de puces comprenant au moins deux processeurs hôtes et une interface d'émission/réception de données sans contact de type RFID configurable selon plusieurs modes de fonctionr..ement et selon plusieurs protocoles de communication sans contact, le procédé comprenant une étape de routage, vers au moins l'un des processeurs hôtes, de données reçues par l'interface d'émission/réception de données sans contact via un canal de transmission de données sans contact, procédé dans lequel l'étape de routage comprend une étape préalable de détermination d'un point de destination des données dans un processeur hôte en utilisant comme critères de détermination du point de destination le mode de fonctionnement et le protocole de communication sans contact utilisés par l'interface d'émission/réception de données sans contact pour créer le canal de transmission integrated in the near future in devices not meeting an NFC standard. For example, a conventional reader used for payment or access control sends authentication and / or secret code verification commands that are addressed to contactless smart cards. During an authentication, such a reader does not know if he is speaking to a real contactless card or an NFC chipset in card emulation mode. Therefore, such a reader is not designed to issue parameters for routing, within the chipset, the application data that it sends. Thus, another object of the invention is to provide a method for determining, in an NFC chipset, the host processor receiving data received via a contactless data transmission channel, without necessarily having to analyze the content of these data. At least one objective of the invention is achieved by the provision of a data routing method in a chipset comprising at least two host processors and a contactless RFID-type contactless data transmission / reception interface configurable according to several modes of operation and according to several contactless communication protocols, the method comprising a step of routing, to at least one of the host processors, data received by the contactless transmission / reception interface via a non-contact data transmission channel, wherein the routing step comprises a prior step of determining a destination point of the data in a host processor using as the destination point determining criteria the operating mode and the contactless communication protocol used by the contactless transmission / reception interface to create the transmission channel

de données sans contact par l'intermédiaire duquel les données sont reçues. Selon un mode de réalisation, le procédé comprend les étapes consistant à préenregistrer dans une table de routage des chemins de données comprenant chacun un identifiant d'un point de destination, un paramètre de mode de fonctionnement de l'interface d'émission/réception de données sans contact et un paramètre de protocole de communication sans contact, et, lorsque des données sont reçues par l'interface d'émission/réception de données sans contact via un canal de transmission de données sans contact, déterminer au moins un point de destination des données en recherchant dans la table de routage un chemin de données ayant un paramètre de mode de fonctionnement et un paramètre de protocole de communication sans contact correspondant aux paramètres de mode de fonctionnement et de protocole de communication sans contact utilisés par l'interface d'émission/réception de données sans contact pour créer le canal de transmission de données sans contact par l'intermédiaire duquel les données sont reçues. Selon un mode de réalisation, le procédé comprend les étapes consistant à : en réponse à une commande d'ouverture de chemin de données émise par un point source localisé dans le processeur hôte, et désignant un point de destination localisé dans l'interface d'émission/réception de données sans contact, définir un chemin de données reliant le point source au point de destination en attribuant au chemin de données un numéro de canal de routage et en enregistrant dans une table de routage le numéro de canal de routage et des paramètres de routage comprenant au moins un identifiant du point source et un identifiant du point de destination ; envoyer au point de destination des données fournies par le point source en les encapsulant dans une trame ayant un champ d'en-tête de taille réduite comprenant le numéro de canal de routage ; et sur réception de données contactless data through which data is received. According to one embodiment, the method comprises the steps of pre-registering in a routing table data paths each comprising an identifier of a destination point, a mode of operation parameter of the transmission / reception interface of contactless data and a non-contact communication protocol parameter, and, when data is received by the contactless transmission / reception interface via a contactless data transmission channel, determining at least one destination point data by searching the routing table for a data path having an operation mode parameter and a non-contact communication protocol parameter corresponding to the operating mode and contactless communication protocol parameters used by the interface of transmission / reception of contactless data to create the contactless data transmission channel the data are received. According to one embodiment, the method comprises the steps of: in response to a data path opening command issued by a source point located in the host processor, and designating a destination point located in the interface of transmission / reception of contactless data, defining a data path connecting the source point to the destination point by assigning the data path a routing channel number and recording in a routing table the routing channel number and parameters routing system comprising at least an identifier of the source point and an identifier of the destination point; sending the data supplied by the source point to the destination point by encapsulating them in a frame having a reduced header field including the routing channel number; and upon receipt of data

encapsulées dans une trame ayant un champ d'en-tête comprenant le numéro de canal de routage, rechercher un point de destination des données dans la table de routage en utilisant le numéro de canal de routage en tant qu'index de sélection du point de destination. Selon un mode de réalisation, le procédé comprend les étapes consistant à : en réponse à une commande d'ouverture de chemin de données émise par un point source localisé dans le processeur hôte et désignant un point de destination localisé dans l'interface d'émission/réception de données sans contact, ouvrir un chemin de données entre le point source et le point de destination en attribuant au chemin de données un numéro de canal de routage et en enregistrant dans la table de routage le numéro de canal de routage et des paramètres de routage comprenant un paramètre de mode de fonctionnement de l'interface d'émission/réception de données sans contact et un paramètre de protocole de communication sans contact, et configurer l'interface d'émission/réception de données sans contact pour qu'elle émette des données dans un canal de transmission de données sans contact en utilisant les paramètres de mode de fonctionnement et de protocole de communication sans contact figurant dans la table de routage pour le chemin de données par l'intermédiaire duquel les données à émettre ont été reçues. Selon un mode de réalisation, la table de routage est également utilisée pour ouvrir un chemin de données entre deux processeurs hôtes. encapsulated in a frame having a header field including the routing channel number, retrieving a destination point of the data in the routing table using the routing channel number as a selection point index index destination. According to one embodiment, the method comprises the steps of: in response to a data path opener command issued by a source point located in the host processor and designating a destination point located in the transmit interface / receive contactless data, open a data path between the source point and the destination point by assigning the data path a routing channel number and registering in the routing table the routing channel number and parameters method comprising an operating mode parameter of the contactless transmission / reception interface and a contactless communication protocol parameter, and configuring the contactless transmission / reception interface for transmits data in a contactless data transmission channel using the operating mode and communication protocol parameters without contact in the routing table for the data path through which the data to be transmitted has been received. According to one embodiment, the routing table is also used to open a data path between two host processors.

Selon un mode de réalisation, le procédé comprend une étape de prévision de commandes de création de chemins de données comprenant des paramètres de routage et des paramètres de configuration de l'interface d'émission/réception de données sans contact à enregistrer dans la table de routage. Selon un mode de réalisation, la table de routage est remplie ou vidée de façon dynamique lorsque des According to one embodiment, the method comprises a step of predicting commands for creating data paths comprising routing parameters and configuration parameters of the contactless data transmission / reception interface to be recorded in the data table. routing. According to one embodiment, the routing table is filled or emptied dynamically when

chemins de données ayant un point source localisé dans un processeur hôte sont créés ou fermés. Selon un mode de réalisation, le procédé comprend une étape de préenregistrement dans la table de routage de chemins de données ayant un point source localisé dans un processeur hôte. Selon un mode de réalisation, des points sources ou des points de destination enregistrés dans la table de routage sont des services exécutés par un processeur hôte. Selon un mode de réalisation, les paramètres de routage mémorisés dans la table de routage comprennent également un identifiant d'un point de notification devant recevoir copie des données envoyées au point de destination. Selon un mode de réalisation, le procédé est mis en oeuvre dans un jeu de puces dans lequel un processeur hôte est un circuit sécurisé tel un circuit intégré de carte SIM. Data paths having a source point located in a host processor are created or closed. According to one embodiment, the method comprises a step of pre-recording in the routing table of data paths having a source point located in a host processor. According to one embodiment, source points or destination points registered in the routing table are services executed by a host processor. According to one embodiment, the routing parameters stored in the routing table also include an identifier of a notification point to receive a copy of the data sent to the destination point. According to one embodiment, the method is implemented in a chipset in which a host processor is a secure circuit such as a SIM card integrated circuit.

L'invention concerne également un dispositif d'émission/réception de données comprenant une interface d'émission/réception de données sans contact de type RFID configurable selon plusieurs modes de fonctionnement et selon plusieurs protocoles de communication sans contact, un contrôleur et au moins deux ports d'entrée/sortie pour relier l'interface d'émission/réception de données sans contact à au moins deux processeurs hôtes, dans lequel le contrôleur est configuré pour, lorsque des données sont reçues par l'interface d'émission/réception de données sans contact via un canal de transmission de données sans contact, déterminer au moins un point de destination des données dans un processeur hôte en utilisant comme critères de détermination du point de destination le mode de fonctionnement et le protocole de communication sans contact utilisés par l'interface d'émission/réception de données sans contact pour créer le canal de transmission The invention also relates to a data transmission / reception device comprising an RFID-type contactless transmission / reception interface configurable according to several operating modes and according to several contactless communication protocols, a controller and at least two input / output ports for connecting the contactless transmission / reception interface to at least two host processors, wherein the controller is configured to, when data is received by the transmit / receive interface of contactless data via a non-contact data transmission channel, determining at least one destination point of the data in a host processor by using as the destination point determination criteria the operation mode and the contactless communication protocol used by the contactless data transmission / reception interface to create the transmission channel

de données sans contact par l'intermédiaire duquel les données sont reçues. Selon un mode de réalisation, le contrôleur est configuré pour : préenregistrer dans une table de routage des chemins de données ayant un point source localisé dans l'interface d'émission/réception de données sans contact, et pour chacun de ces chemins de données, au moins un identifiant d'un point de destination, un paramètre de mode de fonctionnement de l'interface d'émission/réception de données sans contact et un paramètre de protocole de communication sans contact, et, lorsque des données sont reçues par l'interface d'émission/réception de données sans contact via un canal de transmission de données sans contact, déterminer au moins un poir..t de destination des données en recherchant dans la table de routage un chemin de données ayant un paramètre de mode de fonctionnement et un paramètre de protocole de communication sans contact correspondant aux paramètres de mode de fonctionnement et de protocole de communication sans contact utilisés par l'interface d'émission/réception de données sans contact pour créer le canal de transmission de données sans contact par l'intermédiaire duquel les données sont reçues. Selon un mode de réalisation, le contrôleur est configuré pour : en réponse à une commande d'ouverture de chemin de données émise par un point source localisé dans le processeur hôte et désignant un point de destination localisé dans l'interface d'émission/réception de données sans contact, ouvrir un chemin de données entre le point source et le point de destination en attribuant au chemin de données un numéro de canal de routage et en enregistrant dans une table de routage le numéro de canal de routage et des paramètres de routage comprenant au moins un identifiant du point source et un identifiant du point de destination, et, sur réception de données encapsulées dans une trame ayant un champ d'en-tête comprenant le numéro de canal de routage, rechercher un contactless data through which data is received. According to one embodiment, the controller is configured to: pre-register in a routing table data paths having a source point located in the contactless transmission / reception interface, and for each of these data paths, at least one identifier of a destination point, an operating mode parameter of the contactless transmission / reception interface and a contactless communication protocol parameter, and, when data is received by the contactless transmission / reception interface via a contactless data transmission channel, determining at least one destination of the data by searching the routing table for a data path having a mode of operation parameter and a non-contact communication protocol parameter corresponding to the operating mode and contactless communication protocol parameters used by the interfa this contactless transmission / reception of data to create the contactless data transmission channel through which the data is received. According to one embodiment, the controller is configured to: in response to a data path opener command issued by a source point located in the host processor and designating a destination point located in the transmit / receive interface of contactless data, open a data path between the source point and the destination point by assigning the data path a routing channel number and storing in a routing table the routing channel number and routing parameters comprising at least one source point identifier and one destination point identifier, and upon receiving encapsulated data in a frame having a header field including the routing channel number, search a

point de destination des données dans la table de routage en utilisant le numéro de canal de routage en tant qu'index de sélection du point de destination. Selon un mode de réalisation, le contrôleur est configuré pour, en réponse à une commande d'ouverture de chemin de données émise par un point source localisé dans un processeur hôte et désignant un point de destination localisé dans l'interface d'émission/réception de données sans contact, ouvrir un chemin de données entre le point source et le point de destination en attribuant au chemin de données un numéro de canal de routage et en enregistrant dans la table de routage le numéro de canal de routage et des paramètres de routage comprenant un paramètre de mode de fonctionnement de l'interface d'émission/réception de données sans contact et un paramètre de protocole de communication sans contact, et l'interface d'émission/réception de données sans contact est configurée pour émettre des données dans un canal de transmission de données sans contact en utilisant les paramètres de mode de fonctionnement et de protocole de communication sans contact figurant dans la table de routage pour le chemin de données par l'intermédiaire duquel les données à émettre ont été reçues. Selon un mode de réalisation, le contrôleur utilise 25 également la table de routage pour ouvrir un chemin de données entre deux processeurs hôtes Selon un mode de réalisation, le contrôleur est configuré pour décoder des commandes de création de chemins de données comprenant des paramètres de routage 30 et des paramètres de configuration de l'interface d'émission/réception de données sans contact, et pour enregistrer dans la table de routage les paramètres de routage et de configuration présents dans les commandes. Selon un mode de réalisation, le contrôleur est 35 configuré pour remplir ou vider de façon dynamique la table de routage lorsque des chemins de données ayant un point source localisé dans un processeur hôte sont créés ou fermés. Selon un mode de réalisation, le contrôleur est configuré pour préenregistrer dans la table de routage des chemins de données ayant un point source localisé dans un processeur hôte. Selon un mode de réalisation, des points sources ou des points de destination enregistrés dans la table de routage sont des services exécutés par un processeur hôte. Selon un mode de réalisation, les paramètres de routage mémorisés dans la table de routage comprennent également un identifiant d'un point de notification devant recevcir copie des données envoyées au point de destination. Ces objets, caractéristiques et avantages ainsi que d'autres de la présente invention seront exposés plus en détail dans la description suivante du procédé de l'invention, faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : - la figure 1 précédemment décrite représente sous forme de bloc une architecture classique de chipset NFC, et des circuits sans contact avec lesquels le chipset NFC peut dialoguer, - la figure 2 précédemment décrite illustre diverses applications d'un chipset NFC intégré dans un téléphone mobile, - la figure 3A précédemment décrite représente sous forme de bloc l'architecture classique d'un lecteur NFC présent 30 dans le chipset NFC de la figure 1, - la figure _B précédemment décrite représente des flux de données traversant le chipset NFC et correspondant à différentes applications, - la figure 4 illustre de façon schématique la mise en 35 oeuvre du procédé de routage selon l'invention dans un chipset NFC, - la figure 5 représente un exemple d'architecture matérielle d'un lecteur NFC présent dans le chipset de la figure 4, et la figure 6 représente un exemple d'architecture 5 logicielle du lecteur NFC de la figure 5. Premier aspect de l'invention un procédé de routage de données basé sur l'utilisation d'une table de routage La figure 4 illustre de façon schématique la mise 10 en oeuvre du procédé de routage selon l'invention. Le procédé est mis en oeuvre dans un chipset NFC comprenant un lecteur NFC référencé "NFCR2" et des processeurs hôtes HP1, HP2 déjà décrits plus haut. Le lecteur NFCR2 comprend les mêmes organes que le lecteur NFCR1 décrit 15 plus haut, notamment un contrôleur NFCC et une interface d'émission/ré:eption de données sans contact CLINT équipée d'un circuit d'antenne ACT. Dans un souci de simplicité, on suppose que l'interface CLINT ne peut émettre ou recevoir des données que selon trois 20 protocoles PTi, à savoir le protocole PT1 (ISO 14443-A ou "ISOA"), le protocole PT2 (ISO 14443-B ou "ISOB") et le protocole PT3 (ISO 15693 ou "ISO15"). Elle présente par ailleurs les trois modes de fonctionnement Mi susmentionnés, à savoir Ml (Mode "lecteur"), M2 (mode 25 "émulation decarte") et M3 (mode "device"). Des points source ou destination d'un flux de données dans le chipset sont désignés Pl (point localisé dans le processeur hôte HP1), P2 (point localisé dans le processeur hôte HP2) et P3 (point localisé dans 30 l'interface sans contact CLINT). Selon 1 invention, le contrôleur NFCC du lecteur NFC est utilisé en tant qu'administrateur d'un protocole HCI (Host Computer Interface) qui présente les caractéristiques suivantes : 35 - l'utilisation d'une table de routage RT dans laquelle sont enregistrés des chemins de données, chaque chemin de données étant identifié par un numéro de canal de routage CHANi, - l'utilisation de commandes CMD permettant la gestion des chemins de données (canaux de routage), notamment des commandes d'ouverture et de fermeture de chemins de données, et - l'utilisation de trames de données DF comprenant un champ d'en-tête de longueur réduite et un champ de données (DATA), le champ d'en-tête comportant un numéro de canal de routage CHANT. Les chemins de données enregistrés dans la table de routage sont différentiés les uns des autres au moins par les paramètres suivant : CHANi; IDsp ; IDdp, Mi, PTi data destination point in the routing table using the routing channel number as the destination point selection index. According to one embodiment, the controller is configured to, in response to a data path opener command issued by a source point located in a host processor and designating a destination point located in the transmit / receive interface of contactless data, open a data path between the source point and the destination point by assigning the data path a routing channel number and recording in the routing table the routing channel number and routing parameters comprising an operating mode parameter of the contactless transmission / reception interface and a contactless communication protocol parameter, and the contactless transmission / reception interface is configured to transmit data in a non-contact data transmission channel using the operating mode and contactless communication protocol parameters listed in the routing table for the data path through which the data to be transmitted has been received. According to one embodiment, the controller also uses the routing table to open a data path between two host processors. According to one embodiment, the controller is configured to decode commands for creating data paths including routing parameters. 30 and configuration parameters of the contactless transmission / reception interface, and to record in the routing table the routing and configuration parameters present in the commands. According to one embodiment, the controller is configured to dynamically fill or empty the routing table when data paths having a source point located in a host processor are created or closed. According to one embodiment, the controller is configured to pre-register in the routing table data paths having a source point located in a host processor. According to one embodiment, source points or destination points registered in the routing table are services executed by a host processor. According to one embodiment, the routing parameters stored in the routing table also include an identifier of a notification point to receive a copy of the data sent to the destination point. These and other objects, features and advantages of the present invention will be set out in more detail in the following description of the method of the invention, given in a non-limiting manner in relation to the appended figures among which: FIG. described shows in block form a conventional architecture of NFC chipset, and contactless circuits with which the NFC chipset can dialogue, - Figure 2 previously described illustrates various applications of a NFC chipset integrated in a mobile phone, - Figure 3A previously described represents in block form the conventional architecture of an NFC reader present in the NFC chipset of FIG. 1; FIG. B previously described represents data streams traversing the NFC chipset and corresponding to different applications; FIG. 4 schematically illustrates the implementation of the routing method according to the invention in a chips and NFC, FIG. 5 shows an exemplary hardware architecture of an NFC reader present in the chipset of FIG. 4, and FIG. 6 represents an example of a software architecture of the NFC reader of FIG. The invention provides a method of routing data based on the use of a routing table. FIG. 4 schematically illustrates the implementation of the routing method according to the invention. The method is implemented in an NFC chipset comprising an NFC reader referenced "NFCR2" and host processors HP1, HP2 already described above. The NFCR2 reader comprises the same organs as the NFCR1 reader described above, in particular an NFCC controller and a contactless data transmission / reception interface CLINT equipped with an antenna circuit ACT. For the sake of simplicity, it is assumed that the CLINT interface can transmit or receive data only according to three PTi protocols, namely the PT1 protocol (ISO 14443-A or "ISOA"), the PT2 protocol (ISO 14443- B or "ISOB") and the PT3 protocol (ISO 15693 or "ISO15"). It also has the three aforementioned operating modes Mi, namely Ml ("Reader" mode), M2 ("emulation card" mode) and M3 ("device" mode). Source or destination points of a data stream in the chipset are designated Pl (point located in the host processor HP1), P2 (point located in the host processor HP2) and P3 (point located in the contactless interface CLINT ). According to the invention, the NFCC controller of the NFC reader is used as an administrator of a Host Computer Interface (HCI) which has the following characteristics: the use of an RT routing table in which data paths, each data path being identified by a routing channel number CHANi, - the use of CMD commands for managing data paths (routing channels), including path opening and closing commands data, and - the use of DF data frames comprising a header field of reduced length and a data field (DATA), the header field having a routing channel number CHANT. The data paths stored in the routing table are differentiated from each other by at least the following parameters: CHANi; IDsp; IDdp, Mi, PTi

CHANi étant le numéro de canal de routage attribué au chemin de données, IDsp un identifiant du point source du chemin de données, destination du chemin de fonctionnement et contact utilisés par recevoir des données données sans contact. CHANi being the routing channel number assigned to the data path, IDsp an identifier of the source point of the data path, destination of the operating path and contact used to receive contactless data.

Des exemples de IDdp un identifiant du point de données, Mi et PTi étant le mode le protocole de communication sans l'interface CLINT pour émettre ou via un canal de transmission de Examples of IDdp an identifier of the data point, Mi and PTi being the communication protocol mode without the CLINT interface to transmit or via a transmission channel of

commandes de routage ainsi que des exemples de trames de données sont décrits en Annexe 1 qui fait partie intégrante de la description. Toutes les commandes pouvant être prévues ne seront pas décrites ici, dans un souci de simplicité. L'Annexe 1 décrit des commandes essentielles de création de route, de modification de route et de suppression de route, et les réponses à de telles commandes (messages de confirmation ou d'erreur). L'Annexe 1 décrit également le format des trames de dcnnées DF, qui présente avantageusement un champ d'en-tête de taille réduite ne comprenant que 8 bits. Routing commands and sample data frames are described in Appendix 1 which forms an integral part of the description. All the commands that can be planned will not be described here, for the sake of simplicity. Annex 1 describes essential commands for route creation, route modification and route deletion, and responses to such commands (confirmation or error messages). Annex 1 also describes the format of the DF data frames, which advantageously has a header field of reduced size comprising only 8 bits.

Les commandes d'ouverture, de fermeture ou de modification d'un chemin de données sont émises par l'un des processeurs hôtes HP1, HP2 ou par l'interface CLINT et sont traitées par le contrôleur NFCC. Ces commandes spécifient le mode de fonctionnement Mi et le protocole PTi de l'interface CLINT pour le chemin de données concerné. Si l'ouverture d'un chemin de données est demandée par l'un des processeurs hôtes HP1 ou HP2, le mode Mi et le protocole PTi figurant dans la commande sont utilisés par le contrôleur NFCC pour configurer l'interface CLINT en ce qui concerne le canal de communication sans contact que l'interface CLINT doit créer pour émettre les données qui seront reçues via le chemin de données. Si l'ouverture d'un chemin de données est demandée par l'interface CLINT, le mode de fonctionnement Mi et le protocole PTi spécifiés dans la commande émise par l'interface CLINT sont informatifs et précisent les conditions de mode de fonctionnement et de protocole dar.Ls lesquelles l'interface CLINT a reçu les données qu'elle veut transmettre dans le chemin de données. La création proprement dite d'un chemin de données est assurée par le contrôleur NFCC en tant qu'administrateur HCI ("HCI ADMIN"). Lorsqu'une commande de création d'un chemin de données est reçue (commande "Création d'une route") et est recevable, le contrôleur NFCC attribue à la route un numéro de canal de routage CHANi, puis inscrit dans la table de routage RT les paramètres IDsp, IDdp, Mi, PTi indiqués dans la commande, et envoie ensuite un message de confirmation à l'entité ayant émis la commande. Un exemple de table de routage créée par le contrôleur NFCC est décrit par le tableau 1 en Annexe 2, qui fait partie intégrante de la description. Cette table de routage est créée après réception d'une série de commandes d'ouverture de route ayant des points sources localisés dans l'un des processeurs HP1 ou HP2 (soit un The commands to open, close or modify a data path are issued by one of the host processors HP1, HP2 or by the interface CLINT and are processed by the controller NFCC. These commands specify the Mi operating mode and the PTi protocol of the CLINT interface for the data path concerned. If the opening of a data path is requested by one of the HP1 or HP2 host processors, the Mi mode and the PTi protocol in the command are used by the NFCC controller to configure the CLINT interface with respect to the contactless communication channel that the CLINT interface must create to transmit the data that will be received via the data path. If the opening of a data path is requested by the CLINT interface, the Mi operating mode and the PTi protocol specified in the command issued by the CLINT interface are informative and specify the operating mode and protocol conditions. dar.Ls which interface CLINT has received the data it wants to transmit in the data path. The actual creation of a data path is performed by the controller NFCC as an HCI administrator ("HCI ADMIN"). When a command for creating a data path is received (command "Creation of a route") and is receivable, the controller NFCC assigns to the route a routing channel number CHANi, then registered in the routing table RT the IDsp, IDdp, Mi, PTi parameters indicated in the command, and then sends a confirmation message to the entity that issued the command. An example of a routing table created by the NFCC controller is described in Table 1 in Appendix 2, which is an integral part of the description. This routing table is created after receiving a series of route-open commands having source points located in one of the processors HP1 or HP2 (a

point source Pl ou P2). Optionnellement, le contrôleur peut définir un point destinataire secondaire destiné à recevoir copie des données circulant dans le chemin de données. Le destinataire secondaire ou point de notification est déterminé par le contrôleur à partir d'une table de notification (non représentée sur les figures) qui lui indique les chemins de données pour lesquels les données doivent être notifiées à l'autre processeur hôte. Bien que présentée de façon statique dans le tableau 1, la table de routage est dynamique et est mise à jour en temps réel en fonction des commandes de création, de modification ou de suppression reçues par le contrôleur NFCC. Dans une variante de réalisation, :La table de routage est statique et a été préenregistrée par le contrôleur NFCC, par exemple à la demande de l'un des processeurs hôtes et à la mise sous tension. du chipset. Le tableau 2 en Annexe 2 décrit un exemple de table de routage préenregistrée ayant comme points sources les points Pl ou P2 localisés dans les processeurs hôtes HP1, HP2. Le numéro de canal CHANi peut également être préenregistré dans la table pour chaque configuration de routage envisageable. Dans une telle table préenregistrée, un champ "occupé" est prévu dans chaque ligne de la table (une ligne correspondant à un canal de routage). Le contrôleur NFCC inscrit la valeur "1" dans le champ "occupé" lorsqu'il ouvre le chemin de données correspondant, et inscrit la valeur "0" en réponse à une commande de suppression du chemin de données. source point P1 or P2). Optionally, the controller may define a secondary recipient point for receiving a copy of the data flowing in the data path. The secondary recipient or notification point is determined by the controller from a notification table (not shown in the figures) that indicates the data paths for which the data must be notified to the other host processor. Although presented statically in Table 1, the routing table is dynamic and is updated in real time according to the creation, modification or deletion commands received by the NFCC controller. In an alternative embodiment, the routing table is static and has been pre-recorded by the controller NFCC, for example at the request of one of the host processors and at power-up. chipset. Table 2 in Appendix 2 describes an example of a prerecorded routing table whose source points are the points P1 or P2 located in the host processors HP1, HP2. The channel number CHANi can also be prerecorded in the table for each possible routing configuration. In such a prerecorded table, a "busy" field is provided in each row of the table (a line corresponding to a routing channel). The NFCC controller enters the value "1" in the "busy" field when it opens the corresponding data path, and writes the value "0" in response to a command to delete the data path.

La transmission des données reçues dans les trames de données est également sous le contrôle du contrôleur NFCC, qui se réfère à la table de routage pour déterminer les points de destination de ces données. Avantageusement, comme cela apparaît dans le format des trames de données décrites en Annexe 1, il n'est pas nécessaire que le point source qui envoie les données au processeur spécifie tous les paramètres du canal de The transmission of the received data in the data frames is also under the control of the NFCC controller, which refers to the routing table to determine the destination points of these data. Advantageously, as appears in the format of the data frames described in Appendix 1, it is not necessary for the source point which sends the data to the processor to specify all the parameters of the data channel.

routage utilisé le champ d'en-tête de la trame de données comprend simplement des bits de paramétrage T et L et 6 bits de numéro de canal (permettant de router simultanément 63 chemins de données, le canal "0" étant réservé à l'administration du protocole HCI). Ainsi, :pur réception d'une trame de données, le contrôleur NFCC renvoie les données au point de destination désigné dans la table de routage, en utilisant le numéro de canal en tant qu'index pour trouver ce point de destination dans la table de routage (ainsi qu'éventuellement le point de notification). Si le point de destination est le point P3 (interface CLINT), le contrôleur NFCC assure le paramétrage de l'interface CLINT pour que celle-ci envoie les données dans un canal de transmission de données sans contact conforme aux informations 3e protocole sans contact PTi et de mode de fonctionnemen: Mi figurant dans la table de routage. Dans une variante de réalisation, l'interface CLINT assure elle-même son paramétrage en lisant la table de routage lorsque des données sont reçues dans une trame de données (ce qui nécessite qu'une partie des attributions du contrôleur NFCC soit transférée dans l'interface CLINT). Ainsi, un autre avantage de la présente invention est que la table de routage permet le paramétrage de l'interface CLINT sans qu'il soit nécessaire d'inclure les paramètres de mode de fonctionnement Mi et de protocole de communication sans contact PTi dans les en-têtes des trames de données. La table de routage selon l'invention n'est donc pas une simple table de routage au sens conventionnel du terme, mais forme également une table de paramétrage. Le tableau 3 en Annexe 2 décrit un exemple de table de routage dynamique comprenant des chemins de données créés à la demande de l'interface CLINT (ayant P3 comme point source). Comme on l'a indiqué au préambule, le problème que pose le routage de données entrantes (données reçues via un canal de communication sans Routing used the header field of the data frame simply comprises parameter bits T and L and 6 channel number bits (for routing simultaneously 63 data paths, the channel "0" being reserved for the administration of the HCI protocol). Thus, if a data frame is received, the NFCC controller returns the data to the designated destination point in the routing table, using the channel number as an index to find that destination point in the routing table. routing (as well as possibly the notification point). If the point of destination is point P3 (CLINT interface), the NFCC controller ensures the setting of the CLINT interface so that it sends the data in a non-contact data transmission channel in accordance with the information 3rd contactless protocol PTi and mode of operation: Mi listed in the routing table. In an alternative embodiment, the CLINT interface itself performs its parameterization by reading the routing table when data is received in a data frame (which requires that part of the NFCC controller's assignments be transferred to the CLINT interface). Thus, another advantage of the present invention is that the routing table makes it possible to parameterize the interface CLINT without it being necessary to include the operating mode parameters Mi and the contactless communication protocol PTi in them. -heads of data frames. The routing table according to the invention is therefore not a simple routing table in the conventional sense of the term, but also forms a parameterization table. Table 3 in Appendix 2 describes an example of a dynamic routing table including data paths created at the request of the CLINT interface (having P3 as the source point). As mentioned in the preamble, the problem posed by the routing of incoming data (data received via a communication channel without

contact) est que l'interface CLINT ainsi que le contrôleur NFCC ne savent pas nécessairement quel est le processeur hôte destinataire de ces données. En conséquence, la table de routage créée ici par le contrôleur NFCC à la demande de l'interface CLINT indique que les données doivent être envoyées aux deux points de destination Pl, P2 localisés dans les deux processeurs hôtes HP1, HP2, à charge au processeur hôte qui n'est pas concerné par les données de ne pas y répondre et de laisser l'autre processeur hôte envoyer à l'interface CLINT des données de réponse. Il sera noté ici que les chemins de données créés à la demande de l'un des processeurs hôtes HP1, HP2 ou à la demande de l'interface CLINT sont de préférence bidirectionnels. Ainsi, par exemple, un fois qu'un chemin de données a été créé par un point Pi localisé dans le processeur HP1, pour émettre des données dans un canal de communication sans contact définit par le paramètre de mode M2 et le protocole PT2, toutes les données reçues par l'interface CLINT dans le mode M2 et suivant le protocole PT2 seront envoyées dans ce chemin de données et seront donc reçues par le point P1. L'homme de l'art notera également que la prévision de chemins de données bidirectionnels impose une gestion des conflits éventuels, en interdisant que deux chemins bidirectionnels ayant des points source et/ou destination différents utilisent les mêmes paramètres de mode Mi et de protocole PTi pour l'interface CLINT. Par exemple, la table de routage décrite par le tableau 1 représente des chemins de do:lnées qui ne peuvent coexister (par exemple canal 1 et canal 9, ces chemins de données n'étant décrits dans :e même tableau qu'à titre illustratif). Second aspect de l'invention : routage des données entrantes en fonction des paramètres de mode et de protocole de l'interface sans contact La présente invention se base ici sur deux constatations : 1) les processeurs hôtes présents dans un chipset NFC sont "spécialisés" dans certaines applications ou types d'application en raison de leur nature (sécurisé ou non, processeur de carte SIM ou processeur Baseband), de leur puissance de traitement et des organes de traitement qu'ils comportent, 2) parmi les diverses applications qu'un chipset NFC peut être amené à gérer, chaque application ou type d'application correspond généralement à un mode de fonctionnement déterminé de l'interface d'émission/réception de données sans contact CLINT et à un protocole de communication sans contact déterminé (PT1, PT2, PT3...) . En conséquence, une combinaison d'un mode de fonctionnement Mi de l'interface CLINT et d'un protocole PTi peut correspondre à un type d'application qui est destiné à être géré par un processeur hôte particulier. Cela apparaît sur la figure 1 où l'on voit que des applications sécurisées AP2 en mode émulation sont généralement gérées par une carte SIM (processeur HP2), alors que des applications non sécurisées du type AP3 (par exemple transfert de fichier en point à point) sont préférentiellement gérées par le processeur Baseband en raison de sa puissance de traitement plus élevé et de l'absence de sécurisation du transfert. Par ailleurs, les applications sécurisées en mode émulation reposent généralement sur les protocoles ISOA et ISOB, tandis que le mode ISO 13693, offrant une plus grande distance de communication, est préférentiellement destiné à des applications non sécurisées générées par _Le processeur hôte HP1 et non par le processeur HP2 si celui-ci est une carte SIM. Ainsi, selon l'invention, on prédéfinit des règles de routage de données entrantes en fonction du mode de fonctionnement Mi de l'interface CLINT et du protocole de communication sans contact PTi suivant lequel les données sont reçues. Les règles de routage prédéterminées sont contact) is that the CLINT interface as well as the NFCC controller do not necessarily know which host processor is receiving this data. As a result, the routing table created here by the NFCC controller at the request of the CLINT interface indicates that the data must be sent to the two destination points P1, P2 located in the two host processors HP1, HP2, to the processor host that is not affected by the data to not respond to it and let the other host processor send response data to the CLINT interface. It will be noted here that the data paths created at the request of one of the host processors HP1, HP2 or at the request of the CLINT interface are preferably bidirectional. Thus, for example, once a data path has been created by a point Pi located in the processor HP1, to transmit data in a contactless communication channel defined by the mode parameter M2 and the protocol PT2, all the data received by the interface CLINT in the mode M2 and following the protocol PT2 will be sent in this data path and will therefore be received by the point P1. Those skilled in the art will also note that bidirectional data path prediction requires management of potential conflicts, by prohibiting two bidirectional paths having different source and / or destination points using the same Mi mode and protocol PTi parameters. for the CLINT interface. For example, the routing table described in Table 1 represents paths of do: lnes that can not coexist (for example channel 1 and channel 9, these data paths being described in the same table as illustrative ). Second aspect of the invention: routing of incoming data as a function of the mode and protocol parameters of the contactless interface The present invention is based here on two observations: 1) the host processors present in an NFC chipset are "specialized" in certain applications or types of applications because of their nature (secure or not, SIM card processor or Baseband processor), their processing power and processing devices that they include, 2) among the various applications that an NFC chipset can be made to manage, each application or type of application generally corresponds to a specific operating mode of the CLINT contactless transmission / reception interface and to a determined contactless communication protocol (PT1, PT2, PT3 ...). Accordingly, a combination of an operating mode Mi of the CLINT interface and a PTi protocol may correspond to a type of application that is intended to be managed by a particular host processor. This appears in Figure 1 where we see that AP2 secure applications in emulation mode are generally managed by a SIM card (HP2 processor), while insecure applications of the AP3 type (eg point-to-point file transfer). ) are preferentially managed by the Baseband processor because of its higher processing power and the lack of secure transfer. Furthermore, secure applications in emulation mode are generally based on ISOA and ISOB protocols, while ISO 13693 mode, offering a greater communication distance, is preferentially intended for non-secure applications generated by the host processor HP1 and not by the HP2 processor if it is a SIM card. Thus, according to the invention, predefined incoming data routing rules according to the operating mode Mi of the CLINT interface and the contactless communication protocol PTi according to which the data is received. The predetermined routing rules are

par exemple :Les suivantes (exemples donnés à titre non limitatif) . -quand l'interface CLINT reçoit des données en mode lecteur ISO A, les données sont envoyées prioritairement au processeur hôte HP1 et sont notifiées au processeur hôte HP2, - quand l'interface CLINT reçoit des données en mode lecteur ISO B, les données sont envoyées prioritairement au processeur hôte HP1 et sont notifiées au processeur hôte HP2, - quand l'interface CLINT reçoit des données en mode lecteur ISO 15693, les données sont envoyées prioritairement au processeur hôte HP2 et ne sont pas notifiées au processeur hôte HP1, - quand l'interface CLINT reçoit des données en mode émulation carte ISO A, les données sont envoyées prioritairement au processeur hôte HP2 et ne sont pas notifiées au processeur hôte HP1, - quand l'interface CLINT reçoit des données en mode émulation carte ISO B vers processeur hôte HP1, les données sont envoyées prioritairement au processeur hôte HP1 et ne sons_ pas notifiées au processeur hôte HP2, - quand l'interface CLINT reçoit des données en mode émulation carte ISO 15693, les données sont seulement notifiées au processeur hôte HP2 et ne sont ni envoyées ni notifiées au processeur hôte HP1, - quand l'interface CLINT reçoit des données en mode "device" ISO A (appariement géré par le processeur hôte HP1), les données sont envoyées prioritairement au processeur hôte HP1 et sont notifiées au processeur hôte HP2, - quand l'interface CLINT reçoit des données en mode "device" ISO B, les données sont bloquées (aucune action), - quand l'interface CLINT reçoit des données en mode "device" ISO 15693 (appariement géré par le processeur hôte HP1), les données sont envoyées prioritairement au for example: The following (examples given in a non-limiting way). when the CLINT interface receives data in ISO A drive mode, the data is sent as a priority to the host processor HP1 and is notified to the host processor HP2, when the CLINT interface receives data in ISO B drive mode, the data is sent as a priority to the host processor HP1 and notified to the host processor HP2, - when the CLINT interface receives data in ISO 15693 reader mode, the data is sent as a priority to the host processor HP2 and are not notified to the host processor HP1, - when the CLINT interface receives data in ISO A card emulation mode, the data is sent as a priority to the host processor HP2 and is not notified to the host processor HP1, - when the CLINT interface receives data in ISO B card emulation mode to processor host HP1, the data is sent as a priority to the host processor HP1 and is not notified to the host processor HP2, - when the interface C LINT receives data in ISO 15693 card emulation mode, the data is only notified to the host processor HP2 and is neither sent nor notified to the host processor HP1, - when the CLINT interface receives data in "device" mode ISO A (pairing managed by the host processor HP1), the data is sent as a priority to the host processor HP1 and is notified to the host processor HP2, - when the CLINT interface receives data in "device" mode ISO B, the data are blocked (no action) - when the CLINT interface receives data in ISO 15693 "device" mode (pairing managed by the HP1 host processor), the data is sent as a priority to

processeur hôte HP1 et sont notifiées au processeur hôte HP2. Cet ensemble de règles permet de définir une table de routage des données entrantes, telle que décrite par le tableau 4 en Annexe 2. Cette table de routage est statique et est préenregistrée par le contrôleur NFCC, par exemple à la demande du processeur sécurisé HP2 et à la mise sous tension du chipset NFC. Cette table est bien entendu susceptible de modification en temps réel. host processor HP1 and are notified to the host processor HP2. This set of rules makes it possible to define an inbound data routing table, as described in Table 4 in Appendix 2. This routing table is static and is pre-recorded by the NFCC controller, for example at the request of the secure processor HP2 and when you turn on the NFC chipset. This table is of course susceptible of modification in real time.

L'homme de l'art notera que le second aspect de l'invention est indépendant du premier, dans la mesure où le routage des données entrantes suivant le procédé qui vient d'être décrit peut être mis en oeuvre en utilisant un protocole :ICI classique, c'est-à-dire sans utilisation d'une table de routage et de trames de données ayant un champ d'en-tête de longueur réduite. Exemple d'architecture matérielle et logicielle du lecteur NFC permettant de mettre en oeuvre le procédé selon l'invention La figure 5 représente un exemple d'architecture matérielle du lecteur NFCR2 de la figure 4. Le lecteur comprend : - le contrôleur NFCC et l'interface CLINT déjà décrits, - un plan mémoire comprenant une mémoire programme MEM1 de type ROM (mémoire morte), une mémoire de données MEM2 de type RAM ;mémoire vive), et une mémoire effaçable et programmable électriquement MEM3 de type EEPROM dans laquelle la table de routage RT est enregistrée, - un circuit d'authentification et de correction d'erreur AUTHCT comprenant des algorithmes DES et ECC (Error Correction Code), - un port de connexion INT1 de type UART (Universal Asynchronous Receiving Transmitting), auquel le processeur hôte HP1 est ici connecté, - un port de connexion INT2 de type ISO7816 auquel le processeur hôte HP2 est ici connecté (le processeur HP2 étant supposé ici être une carte SIM), - un port de connexion INT3 de type SWP (Single Wire Protocol) permettant de connecter un troisième processeur hôte, par exemple une autre carte sécurisée, - un bus de données DTB et un bus d'adresse ADB reliant 5 le plan mémoire, le contrôleur NFCC, l'interface CLINT et les ports INT1, INT2, INT3, et - un bus de contrôle CTB permettant au contrôleur NFCC de contrôler et d'accéder à ces divers éléments en lecture et/ou écriture. W L'interface CLINT et les ports INT1, INT2, INT3 comportent chacun un tampon d'entrée BUF1 à entrée parallèle et un tampon de sortie BUF2 à sortie parallèle accessible en écriture, respectivement en lecture, via le bus de données et le bus d'adresse. L'échange de données 15 formant les commandes de routage ou les trames de données entre les processeurs hôtes HP1, HP2 et le contrôleur NFCC ou l'interface CLINT s'effectue ainsi par blocs de données de la taille des tampon BUF1, BUF2, et est cadencé par le contrôleur NFCC. 20 La figure 6 représente un exemple d'architecture logicielle du lecteur NFCR2 et des processeurs hôtes HP1, HP2. Cette architecture logicielle comprend, pour chaque élément du chipset, plusieurs couches logicielles allant du niveau le plus bas (couche liaison de données) au 25 niveau le plus haut (couche application). La représentation qui est faite de ces couches logicielles en figure 6 est simplifiée par rapport à l'architecture logicielle réelle d'un chipset NFC selon l'invention mais est suffisante pour l'homme de l'art souhaitant réaliser 30 l'invention de la manière proposée ici. Chaque processeur hôte HP1, HP2 comprend au moins quatre couches logicielles, dans un ordre de niveau croissant : - une couche de plus bas niveau HWML (Hardware Management 35 Layer) qui gère le fonctionnement des éléments matériels (hardware) permettant aux processeurs hôtes d'échanger des données avec le contrôleur NFCC. Il s'agit par Those skilled in the art will note that the second aspect of the invention is independent of the first, insofar as the routing of the incoming data according to the method just described can be implemented using a protocol: HERE conventional, that is, without the use of a routing table and data frames having a header field of reduced length. Example of hardware and software architecture of the NFC reader for implementing the method according to the invention FIG. 5 represents an example of hardware architecture of the reader NFCR2 of FIG. 4. The reader comprises: the controller NFCC and the CLINT interface already described, - a memory array comprising a ROM1 program memory ROM (ROM), a RAM type memory MEM2 memory RAM), and a MEM3 electrically erasable and programmable memory type EEPROM in which the table RT is registered, - an authentication and error correction circuit AUTHCT including algorithms DES and ECC (Error Correction Code), - a connection port INT1 type UART (Universal Asynchronous Receiving Transmitting), to which the processor host HP1 is connected here, - an ISO7816 type INT2 connection port to which the host processor HP2 is connected here (the processor HP2 being assumed here to be a card SIM), an INT3 connection port of SWP type (Single Wire Protocol) making it possible to connect a third host processor, for example another secure card, a DTB data bus and an address bus ADB connecting the memory plane. , the NFCC controller, the CLINT interface and the INT1, INT2, INT3 ports, and a CTB control bus allowing the NFCC controller to control and access these various elements for reading and / or writing. W The CLINT interface and the INT1, INT2, INT3 ports each comprise a BUF1 input buffer with parallel input and a BUF2 output buffer with parallel output accessible in writing, respectively read, via the data bus and the bus. 'address. The exchange of data forming the routing commands or the data frames between the host processors HP1, HP2 and the NFCC controller or the CLINT interface is thus performed by data blocks of the buffer size BUF1, BUF2, and is clocked by the NFCC controller. FIG. 6 shows an exemplary software architecture of the NFCR2 reader and HP1, HP2 host processors. This software architecture comprises, for each element of the chipset, several software layers ranging from the lowest level (data link layer) to the highest level (application layer). The representation that is made of these software layers in FIG. 6 is simplified with respect to the actual software architecture of an NFC chipset according to the invention but is sufficient for those skilled in the art wishing to realize the invention of the way proposed here. Each host processor HP1, HP2 comprises at least four software layers, in an increasing order of level: - a lower level layer HWML (Hardware Management 35 Layer) which manages the operation of the hardware elements (hardware) allowing the host processors exchange data with the NFCC controller. This is by

exemple de la couche de gestion de l'interface UART pour le processeur HP1 et de la couche de gestion de l'interface I507816 pour le processeur HP2. - une couche :NTPL (Interface Protocol Layer) qui gère le protocole des ports de communication INT1, INT1, INT3. Il s'agit par exemple de la couche de gestion du protocole UART pour le processeur HP1 et de la couche de gestion du protocole IS07816 pour le processeur HP2. - une couche HCIL (HCI Layer) qui gère le protocole HCI selon l'invention, c'est-à-dire qui gère la création d'un canal de communication en générant les commandes décrites plus haut et en Annexel et en traitant les messages de réponse à de telles commandes. Cette couche repose sur les couches ]:NTPL et HWML qui sont quasi transparentes pour elle. - une couche APL (Application Layer) de haut niveau qui gère les applications RFID telles que celles représentées en figures 2 et 4 (lecture d'une carte à puce ou d'une étiquette électronique, émulation d'une carte à puce, dialogue en mode "device-to-device" avec un processeur externe pour échanger des fichiers, etc..). Cette couche peut comprendre plusieurs programmes application, chacun étant sécurisé ou non (selon les ressources internes du processeur) et chacun utilisant tel type de protocole PTi et tel mode de fonctionnement Mi de l'interface CLINT. Ainsi, cette couche de haut niveau repose sur les couches HWML, INTPL et la couche HCIL selon l'invention, qui sont quasi transparentes pour elle. La rapidité du transfert des données à travers les chemins de données crées grâce à la couche HCIL selon l'invention entraîne avantageusement un accroissement sensible des performances de la couche application APL. Selon un autre aspect avantageux de l'invention, les points source ou destination Pl et P2 localisés dans les processeurs hôtes sont des "services" (des applications déterminées). Ces services peuvent demander au contrôleur NFCC, chacun indépendamment de l'autre, de example of the management layer of the UART interface for the processor HP1 and the management layer of the interface I507816 for the processor HP2. a layer: NTPL (Interface Protocol Layer) which manages the protocol of the communication ports INT1, INT1, INT3. These are, for example, the UART protocol management layer for the processor HP1 and the protocol management layer IS07816 for the processor HP2. an HCIL layer (HCI) which manages the HCI protocol according to the invention, that is to say which manages the creation of a communication channel by generating the commands described above and in Annexel and by processing the messages response to such commands. This layer relies on the layers: NTPL and HWML which are almost transparent for it. a high level Application Layer (APL) layer that manages RFID applications such as those represented in FIGS. 2 and 4 (reading a smart card or an electronic tag, emulating a smart card, "device-to-device" mode with an external processor to exchange files, etc.). This layer can comprise several application programs, each one being secured or not (depending on the internal resources of the processor) and each using this type of protocol PTi and such operating mode Mi of the CLINT interface. Thus, this high level layer relies on the HWML layers, INTPL and the HCIL layer according to the invention, which are almost transparent for it. The speed of the data transfer through the data paths created by the HCIL layer according to the invention advantageously leads to a significant increase in the performance of the APL application layer. According to another advantageous aspect of the invention, the source or destination points P1 and P2 located in the host processors are "services" (specific applications). These services may request the NFCC controller, each independently of the other, to

créer des chemins de données pour utiliser simultanément l'interface CLINT (sous réserve de collision de modes et de protocoles, comme indiqué plus haut). Ainsi, cette architecture logicielle permet de mettre en oeuvre un service en tant que points source ou destination d'un chemin de données, et permet la création simultanée de plusieurs chemins de données entre deux entités, par exemple entre deux processeurs hôtes ou entre un processeur hôte et l'interface d'émission/réception de données sans contact. De façon sensiblement similaire, le contrôleur NFCC comporte les couches logicielles suivantes : - deux couches HWML1 et INTPL du même type que les couches HWML et INTPL présentes dans les processeurs hôtes. Dans un souci de simplification du schéma, ces couches sont représentées dans le processeur NFCC mais sont en réalité localisées dans les ports I.NT1 et INT2, qui sont considérés comme faisant partie du contrôleur, ainsi que les bus ADB, DTB, CTB. En effet le traitement des protocoles UART et 7816 est assuré ici dans les ports INT1, INT2, qui mettent à la disposition du contrôleur leurs tampons d'entrée et de sortie BUF1, BUF2 via les bus ADB, DTB, CTB. - une autre couche de bas niveau HWML2 qui permet au contrôleur d'écrire les tampons BUF1 et de lire les tampons BUF2, via les bus ADB, DTB, CTB, en décomposant les trames de données ou les commandes en blocs de données de même taille que les tampons. - une couche HCI-ADMIN-L ou couche d'administration du protocole HC_C, qui dialogue avec les couches HCIL des processeurs hôtes HP1, HP2 en tant qu'administrateur du routage. Ainsi cette couche exécute les tâches d'attribution de chemins de données décrites plus haut, et accède à la table de routage RT en lecture et en écriture via la couche de bas niveau HWML2. - une couche CLINTCL (Contactless Interface Control Layer) qui gère l'interface CLINT et qui indique à cette create data paths to simultaneously use the CLINT interface (subject to collision modes and protocols, as noted above). Thus, this software architecture makes it possible to implement a service as source or destination points of a data path, and allows the simultaneous creation of several data paths between two entities, for example between two host processors or between a processor host and the contactless transmission / reception interface. In a substantially similar manner, the NFCC controller comprises the following software layers: two HWML1 and INTPL layers of the same type as the HWML and INTPL layers present in the host processors. For the sake of simplification of the scheme, these layers are represented in the NFCC processor but are actually located in the ports I.NT1 and INT2, which are considered to be part of the controller, as well as the buses ADB, DTB, CTB. In fact, the processing of the UART and 7816 protocols is ensured here in the ports INT1, INT2, which make available to the controller their input and output buffers BUF1, BUF2 via the buses ADB, DTB, CTB. another low level layer HWML2 which allows the controller to write the buffers BUF1 and to read the buffers BUF2, via the buses ADB, DTB, CTB, by decomposing the data frames or the commands into blocks of data of the same size as buffers. an HCI-ADMIN-L layer or administration layer of the HC_C protocol, which dialogs with the HCIL layers of the host processors HP1, HP2 as routing administrator. Thus, this layer executes the data path assignment tasks described above, and accesses the RT read and write routing table via the low level layer HWML2. a CLINTCL layer (Contactless Interface Control Layer) which manages the CLINT interface and which indicates to this

dernière le mode Mi dans lequel elle doit se placer et le protocole PTi à utiliser pour émettre des données dans un canal de communication sans contact. A cet effet, la couche CLINTCL exploite les paramètres PTi et Mi présents dans la table de routage. Plus particulièrement, la couche HCI-ADMIN-L écrit ces paramètres dans la table de routage en réponse à des commandes d'ouverture de chemins de données, tandis que la couche CLINTCL recherche ces paramètres dans la table en utilisant comme index le numéro de canal des trames de données envoyées par les processeurs hôtes HP1, HP2. Cette couche contrôle également l'interface CLINT en mode réception de données sans contact et lui demande cycliquement d'effectuer un balayage des modes (mode lecteur, mode émulation et mode "device") et, dans chaque mode, de rechercher des données entrantes. Cela signifie que l'interface CLINT émet à intervalles réguliers un champ magnétique pour interroger d'éventuelles cartes ou étiquettes sans contact (ou autres objets portatifs fonctionnant sans contact) qui pourraient être présentes dans son champ d'interrogation. L'interface CLINT se place également à intervalles réguliers dans un mode d'écoute (mode "émulation") pour détecter si un lecteur en mode actif envoie des messages d'interrogation. - une couche optionnelle APL qui peut gérer elle-même des applications, à l'instar des processeurs hôtes. En effet, bien que cela. n'ait pas été décrit jusqu'à présent pour rester dans l'objet de l'invention, des applications peuvent également être prises en charge par le lecteur NFC lui-même. Dans ce cas, la communication de données entre le contrôleur NFCC et l'interface CLINT peut être faite en passant par le canal de communication HCI selon l'invention, si l'interface CLINT est équipée de la couche INTPL, ce qui est le cas dans le mode de réalisation représenté en figure 6. Enfin, l'interface CLINT comporte les couches logicielles suivantes : last the Mi mode in which it must be placed and the PTi protocol to be used to transmit data in a contactless communication channel. For this purpose, the CLINTCL layer exploits the parameters PTi and Mi present in the routing table. Specifically, the HCI-ADMIN-L writes these parameters to the routing table in response to open data path commands, while the CLINTCL layer searches for these parameters in the table using the channel number as indexes. data frames sent by the host processors HP1, HP2. This layer also controls the CLINT interface in non-contact data reception mode and cyclically requests it to scan modes (drive mode, emulation mode, and device mode) and, in each mode, to look for incoming data. This means that the CLINT interface emits a magnetic field at regular intervals to interrogate any contactless cards or tags (or other non-contact portable objects) that may be present in its interrogation field. The CLINT interface is also placed at regular intervals in a listening mode ("emulation" mode) to detect if a reader in active mode is sending interrogation messages. an optional APL layer that can manage applications itself, like host processors. Indeed, although that. has not been described so far to remain within the scope of the invention, applications may also be supported by the NFC reader itself. In this case, the data communication between the NFCC controller and the CLINT interface can be made via the HCI communication channel according to the invention, if the CLINT interface is equipped with the INTPL layer, which is the case. in the embodiment shown in FIG. 6. Finally, the CLINT interface comprises the following software layers:

- du côté du contrôleur NFCC, une couche de bas niveau HWML équivalente à la couche HWML2 du contrôleur NFCC, pour gérer les tampons de données BUF1, BUF2 via les bus ADB, DTB, CTB, - une couche HCIL (comme indiqué ci-dessus) qui rend l'interface =NT compatible avec le protocole HCI selon l'invention et offre de plus grandes possibilités d'implémentation de l'invention (notamment le fait que l'interface CLINT génère elle-même les trames de données pour envoyer aux processeurs hôtes des données reçues via un canal de communication sans contact). - du coté du circuit d'antenne ACT, des couches CLPTL (Contactless Protocol Layer) et MCL (Mode Control Layer) qui assurent le contrôle ou le traitement des signaux électriques appliqués au circuit d'antenne ACT ou reçus par celui-ci, pour la mise en oeuvre des modes de fonctionnement Ml, M2, M3 et des protocoles PT1, PT2, PT3. - entre les couches situées du coté du contrôleur et les couches situées du coté du circuit d'antenne, une couche centrale de haut niveau HLSL (High Level Service Layer) qui permet de définir dans l'interface CLINT plusieurs points source ou destination P3 pour créer plusieurs chemins de données avec des points P1, P2 multiples dans les couches application APL des processeurs hôtes HP1, HP2. Bien entendu, cette architecture de haut niveau est optionnelle et des points multiples P3 localisés virtuellement dans l'interface CLINT peuvent être gérés par le contrôleur NFCC. on the NFCC controller side, a low level HWML layer equivalent to the HWML2 layer of the NFCC controller, for managing the BUF1, BUF2 data buffers via the ADB, DTB, CTB buses, an HCIL layer (as indicated above); ) which makes the interface = NT compatible with the HCI protocol according to the invention and offers greater possibilities of implementation of the invention (in particular the fact that the interface CLINT itself generates the data frames to send to the host processors data received via a contactless communication channel). on the ACT antenna circuit side, Contactless Protocol Layer (CLPTL) and Mode Control Layer (MCL) layers which control or process the electrical signals applied to or received by the antenna circuit ACT, for the implementation of operating modes Ml, M2, M3 and protocols PT1, PT2, PT3. between the layers located on the controller side and the layers located on the side of the antenna circuit, a high level Layer (HLSL) central layer that makes it possible to define in the CLINT interface several source points or destination P3 for create multiple data paths with multiple points P1, P2 in the APL application layers of the host processors HP1, HP2. Of course, this high-level architecture is optional and multiple points P3 virtually located in the CLINT interface can be managed by the NFCC controller.

I1 apparaîtra clairement à l'homme de l'art que la présente invention est susceptible de diverses variantes de réalisation, tant en ce qui concerne le format des commandes, décrites ici uniquement à titre d'exemple (notamment le bit "T" peut être supprimé pour obtenir 124 canaux de routage au lieu de 64 tout en conservant un champ d'en-tête de 8 bits), le format de la table de routage et la gestion dynamique ou statique, ou les deux à la fois, de la table de routage. It will be clear to those skilled in the art that the present invention is capable of various alternative embodiments, both as regards the format of the commands, described here only by way of example (in particular the "T" bit may be deleted to obtain 124 routing channels instead of 64 while maintaining an 8-bit header field), the routing table format, and dynamic or static management, or both, of the table Routing.

Annexe 1 faisant partie intégrante de la description 5 A/ Exemples de cc miandes de routage Format général En-tête Paramètres Taille 1 bit bit b ts 2 ou 3 octets Signifie ou T L CCMD Selon commande contient Valeur 1 0-1 0-31 10 T = Type ; T = 1 pour une commande ou une réponse à une commande L = longueur du champ "paramètres" . 2 octets si L = 0 ou 3 octets si L = 1 15 CCMD = code de la commande ou du message Annex 1 as an integral part of the description 5 A / Examples of routing messages General format Header Parameters Size 1 bit bit b ts 2 or 3 bytes Mean or TL CCMD Depending on order contains Value 1 0-1 0-31 10 T = Type; T = 1 for a command or a response to a command L = length of the "parameters" field. 2 bytes if L = 0 or 3 bytes if L = 1 15 CCMD = command or message code

Exemples de commandes et de messages de réponse: Commande "Création d'une Route": En-tête Paramètres Taille 1 bit 1 bit 6 bits 1 octet 4 bits 4 bits oct et Signifie ou T L CCMD IDsp IDdp Mi PTi contient Valeur 1 1 VALl 0-255 0-255 0-15 0-15 VALl = valeur du code de la commande IDsp = Identifiant du point source de la commande IDdp = Identifiant du point de destination de la route 25 Mi = mode de fonctionnement de l'interface d'émission/réception de données sans contact (Ml, M2 ou M3) PTi = protocole de communication sans contact (PT1, PT2 ou PT3) 20 10 20 Message "Création Route OK" En-tête Paramètres Taille 1 bit 1 bit 6 bits 1 6 bits 2 bits octet Signifie ou T L CCMD IDsp CHANi RFU contient Valeur 1 0 VAL2 0-255 0-63 0-3 VAL2 = valeur du code de la réponse IDsp = Identifiant du point source de la commande CHANi = Numéro de la route attribuée (Numéro de Canal) RFU = Réservé pour utilisation future Examples of commands and response messages: "Create Route" command: Header Parameters Size 1 bit 1 bit 6 bits 1 byte 4 bits 4 bits oct and Mean or TL CCMD IDsp IDdp Mi PTi contains Value 1 1 VAL1 0-255 0-255 0-15 0-15 VALl = IDsp command code value = IDdp command source point identifier = Route destination point identifier 25 Mi = Interface operating mode d transmission / reception of contactless data (Ml, M2 or M3) PTi = contactless communication protocol (PT1, PT2 or PT3) 20 10 20 "Route OK creation" message Header Parameters Size 1 bit 1 bit 6 bits 1 6 bits 2 bits byte Mean or TL CCMD IDsp CHANi RFU contains Value 1 0 VAL2 0-255 0-63 0-3 VAL2 = Code value of the response IDsp = Identifier of the source point of the CHANi command = Number of the assigned route (Channel Number) RFU = Reserved for future use

Message "Erreur de Création Route" En-tête Paramètres Taille 1 bit 1 bit 6 bits 1 1 octet octet Signifie ou T L CCND IDsp IDdp contient Valeur 1 0 VAL3 0-255 0-255 VAL3 = valeur du code du message IDsp = Identifiant du point source de la commande IDdp = Identifiant du point de destination de la route 15 Mi = mode de fonctionnement de l'interface d'émission/réception de données sans contact (Ml, M2 ou M3) PTi = protocole de communication sans contact (PT1, PT2 ou PT3) "Route creation error" message Header Parameters Size 1 bit 1 bit 6 bits 1 1 byte byte Mean or TL CCND IDsp IDdp contains Value 1 0 VAL3 0-255 0-255 VAL3 = value of the message code IDsp = Identifier of the message IDdp command source point = Route destination point identifier 15 Mi = Contactless transmission / reception interface mode of operation (Ml, M2 or M3) PTi = Contactless communication protocol (PT1) , PT2 or PT3)

Commande "Modification de Route" ou "Suppression de Route" En-tête Paramètres Taille 1 bit 1 bit 6 bits 1 6 bits 2 bits 4 bits 4 bits octet Signifie ou T L CCMD IDsp CHANi RFU Mi PTi contient Valeur 1 1 VAL4 0-255 0-63 0-3 0-15 0-15 ou VAL5 VAL4 ou VAL5 = valeur du code de chaque commande IDsp = Identifiant du point source de la commande 30 "Route Edit" or "Route Delete" command Header Parameters Size 1 bit 1 bit 6 bits 1 6 bits 2 bits 4 bits 4 bits byte Mean or TL CCMD IDsp CHANi RFU Mi PTi contains Value 1 1 VAL4 0-255 0-63 0-3 0-15 0-15 or VAL5 VAL4 or VAL5 = value of the code of each command IDsp = Identifier of the source point of the command 30

CHANT = Numéro de la route à modifier ou supprimer RFU = Réservé pour utilisation future Mi = mode de fonctionnement de l'interface émission/réception de données sans contact (Ml, M2 ou M3) PTi = protocole de communication sans contact (PT1, PT2 ou PT3) CHANT = Number of the route to modify or delete RFU = Reserved for future use Mi = mode of operation of the contactless transmission / reception interface (Ml, M2 or M3) PTi = contactless communication protocol (PT1, PT2 or PT3)

Messages "Modification de Route OK " ou "Suppression de Route OK" En-tête Paramètres Taille 1 bit 1 bit 6 bits 1 6 bits 2 bits octet Signifie ou T L CCMD IDsp CHANi RFU contient Valeur 1 0 VAL6 0-255 0-63 0-3 ou VAL7 VAL6 ou VAL 7 = valeur du code de chaque message IDsp = Identifiant du point source de la commande CHANi = Numéro de la route modifiée ou supprimée RFU= Réservé pour utilisation future Messages "Erreur de Modification de Route" ou "Erreur de Suppression de Route" En-tête Paramètres Taille 1 bit 1 bit 6 bits 1 6 bits 2 bits octet Signifie ou T L CCND IDsp CHANi RFU contient Valeur 1 0 VAL8 0-255 0-63 0-3 ou VAL9 VAL8 ou VAL 9 = valeur du code de chaque message 20 IDsp = Identifiant du point source de la commande CHANT = Numéro de la route concernée RFU = Réservé pour utilisation future B/ Exemples de trames de données Messages "Edit Route OK" or "Delete Route OK" Header Parameters Size 1 bit 1 bit 6 bits 1 6 bits 2 bits byte Mean or TL CCMD IDsp CHANi RFU contains Value 1 0 VAL6 0-255 0-63 0 -3 or VAL7 VAL6 or VAL 7 = code value of each message IDsp = Source point identifier of the CHANi command = Route number modified or deleted RFU = Reserved for future use Messages "Route Modification Error" or "Error Deletion of Route "Header Parameters Size 1 bit 1 bit 6 bits 1 6 bits 2 bits byte Mean or TL CCND IDsp CHANi RFU contains Value 1 0 VAL8 0-255 0-63 0-3 or VAL9 VAL8 or VAL 9 = value of the code of each message IDsp = Identifier of the source point of the command CHANT = Number of the concerned route RFU = Reserved for future use B / Examples of data frames

T = 0 pour une trame de données ou une réponse à une trame de données L = 0 si trame de 256 octets de données L = 1 si trame de 64 Koctets de données DL = Longueur des données en octets DATA = Données d'application CHANi = numéro de canal de routage 10 Trame de 255 octets de données En-tête Taille 1 bit 1 bit 6 bits 1 octet o à 255 octets Signifie ou T L CHANi DL DATA contient Valeur 0 0 0-63 255 Trame de 64K octets de données En-tête Taille 1 bit 1 bit 6 bits 2 octets O à 65535 octets Signifie ou T L CHANi DL DATA contient Valeur 0 1 0-63 65535 Message "Accusé, de réception sans erreur" Taille 1 bit 1 bit 6 bits Signifie ou T Pas CHANT contient d'erreur Valeur 0 0 0-63 Message "Erreur de réception" Taille __ bit 1 bit 6 bits 1 octet _ Signifie ou T Erreur CHANi Code de contient l'erreur Valeur 0 1 0-63 0-255 32 15 20 Annexe 2 faisant partie intégrante de la description - Exemples de tables de routage Tableau 1 : Exemple de table de routage dynamique avec des points sources localisés dans HP1 ou HP2 IDdp CHANi IDsp PTi Mi Envoyer Notifier Commentaires 1 ID(Pl) PT1 Ml ID(P3) ID(P2) Processeur hôte HP1 vers interface CLINT en mode lecteur ISOA 2 ID(Pl) PT2 Ml ID(P3) - Processeur hôte HP1 vers interface CLINT en mode lecteur ISOB 3 ID(Pl) PT3 Ml ID(P3) - Processeur hôte HP1 vers interface CLINT en mode lecteur ISO15 4 ID(Pl) PT1 M3 ID(P3) ID(P2) Processeur hôte HP1 vers interface CLINT en mode "device" ISOA 5 ID(P1) PT2 M3 ID(P3) - Processeur hôte HP1 vers interface CLINT en mode "device" ISOB 6 ID(Pl) PT3 M3 ID(P3) - Processeur hôte HP1 vers interface CLINT en mode "device" ISO15 7 ID(Pl) - - ID(P2) Processeur hôte HP1 vers carte SIM (HP2) 8 ID(P2) - - ID(P1) - Carte SIM (HP2) vers processeur hôte 9 ID(P2) PT1 M1 ID(P3) - Carte SIM (HP2) vers interface CLINT en mode lecteur ISOA ID(P2) PT2 M1 ID(P3) ID(P2) Carte SIM (HP2) vers interface CLINT en mode lecteur ISOB 11 ID(P2) PT3 Ml ID(P3) ID(P2) Carte SIM (HP2) vers interface CLINT en mode lecteur I5015 12 ID(P2) PT1 M3 ID(P3) - Carte SIM (HP2) vers interface CLINT en mode "device" ISOA 13 ID(P2) PT2 M3 ID(P3) ID(P2) Carte SIM (HP2) vers interface CLINT en mode "device" ISOB 14 ID(P2) PT3 M3 ID(P3) ID(P2) Carte SIM (HP2) vers interface CLINT en mode "device" ISO15 5 34 Tableau 2 : Exemple de table de routage préenregistrée avec des points sources localisés dans HP1 ou HP2 ID CHANT IDsp PTi Mi Envoyer Notifier Occupée Commentaires 1 ID(P1) PT1 Ml ID(P3) ID(P2) 1 Processeur hôte HP1 vers interface CLINT en mode lecteur ISOA 2 ID(Pl) PT2 M1 ID(P3) - 0 Processeur hôte HP1 vers interface CLINT en mode lecteur ISOB 3 ID(Pl) PT3 M1 ID(P3) - 0 Processeur hôte HP1 vers interface CLINT en mode lecteur ISO15 4 ID(P1) PT1 M3 ID(P3) ID(P2) 0 Processeur hôte HP1 vers interface CLINT en mode "device" ISOA 5 ID(Pl) PT2 M3 ID(P3) - 0 Processeur hôte HP1 vers interface CLINT en mode "device" ISOB 6 ID(P1) PT3 M3 ID(P3) - 0 Processeur hôte HP1 vers interface CLINT en mode "device" I5015 7 ID(Pl) -- ID(P2) 1 Processeur hôte HP1 vers carte SIM (HP2) 8 ID(P2) - - ID(Pl) -0 Carte SIM (HP2) vers processeur hôte HP1 9 ID(P2) PT1 Ml ID(P3) - 0 Carte SIM (HP2) vers interface CLINT en mode lecteur ISOA 10 ID(P2) PT2 Ml ID(P3) ID(P2) 0 Carte SIM (HP2) vers interface CLINT en mode lecteur ISOB 11 ID(P2) PT3 Ml ID(P3) ID(P2) 0 Carte SIM (HP2) vers interface CLINT en mode lecteur ISO15 12 ID(P2) PT1 M3 ID(P3) - 1 Carte SIM (HP2) vers interface CLINT en mode "device" ISOA 13 ID(P2) F12 M3 ID(P3) ID(P2) 0 Carte SIM (HP2) vers interface CLINT en mode "device" ISOB 14 ID(P2) PT3 M3 ID(P3) ID(P2) 0 Carte SIM (HP2) vers interface CLINT en mode "device" ISO15 5 5 35 Tableau 3 : Exemple de table de routage dynamique avec un point source localisé dans l'interface CLINT et sans mettre en oeuvre le second aspect de l'invention (toutes les données sont envoyées aux deux processeurs hôtes HP1, HP2 ) CHANT IDsp PTi Mi I.Ddp Commentaires 40 ID(P3) PTl Ml ID(Pl) ID(P2) Interface CLINT en mode lecteur ISO A vers processeurs hôtes HP1, HP2 41 ID(P3) PT2 Ml ID(P1) ID(P2) Interface CLINT en mode lecteur ISO B vers processeurs hôtes HP1, HP2 42 ID(P3) PT3 Ml ID(Pl) ID(P2) Interface CLINT en mode lecteur ISO 15693 vers processeurs hôtes HP1, HP2 43 ID(P3) PT1 M2 ID(P2) ID(P2) Interface CLINT en mode émulation ISO A vers processeurs hôtes HP1, HP2 44 ID(P3) 212 M2 ID(Pl) ID(P2) Interface CLINT en mode émulation ISO B vers processeurs hôtes HP1, HP2 45 ID(P3) PT3 M2 ID(P1) ID(P2) Interface CLINT en mode émulation ISO 15693 vers processeurs hôtes HP1, HP2 46 ID(P3) PTl M3 ID(Pl) ID(P2) Interface CLINT en mode "device" ISO A vers processeurs hôtes HP1, HP2 47 ID(P3) PT2 M3 ID(Pl) ID(P2) Interface CLINT en mode "device" ISO B vers processeurs hôtes HP1, HP2 48 ID(P3) PT3 M3 ID(Pl) ID(P2) Interface CLINT en mode "device" ISO 15693 vers processeurs hôtes HP1, HP2 36 Tableau 4 : Exemple de table de routage préenregistrée ayant un point source localisé dans l'interface CLINT (second aspect de l'invention) IDdp CHANi IDsp PTi Ni. Envoyer Notifier Utilisé Coumentaires 40 ID(P3) PT1 M1 ID(P1) ID(P2) Interface CLINT en mode lecteur ISO Avers processeur hôte HP1 41 ID(P3) PT2 Ml ID(P1) ID(P2) Interface CLINT en mode lecteur ISO B vers processeur hôte HP1 42 ID(P3) PT3 Ml ID(P2) Interface CLINT en mode lecteur ISO 15693 vers carte SIM (H12) 43 ID(P3) PT1 M2 ID(P2) Interface CLINT en mode émulation carte ISO A vers carte SIM (HP2) 44 ID(P3) PT2 M2 ID(Pl) _ Interface CLINT en mode émulation carte ISO B vers processeur hôte HP1 45 ID(P3) PT3 M2 - ID(P2) Interface CLINT en mode émulation carte ISO 15693 vers carte SIM (HP2) (notification uniquement) 46 ID(P3) PT1 M3 ID(Pl) (P2) Mode "device" ISO A ; appariement géré par le processeur ID(P2) 47 ID(P3) PT2 M3 - - Aucune action (configuration interdite) 48 ID(P3) PT3 M3 ID(P1) ID(P2) Mode "device" ISO 15693 ; appariement géré par le processeur hôte T = 0 for a data frame or response to a data frame L = 0 if frame of 256 bytes of data L = 1 if frame of 64 K bytes of data DL = Length of data in bytes DATA = Application data CHANi = routing channel number 10 Frame of 255 bytes of data Header Size 1 bit 1 bit 6 bits 1 byte o to 255 bytes Signifies where TL CHANi DL DATA contains Value 0 0 0-63 255 Frame of 64K bytes of data En -head Size 1 bit 1 bit 6 bits 2 bytes O to 65535 bytes Mean or TL CHANi DL DATA contains Value 0 1 0-63 65535 Message "Acknowledged, Received without error" Size 1 bit 1 bit 6 bits Means or T Not SINGLE contains error Value 0 0 0-63 Message "Receive error" Size __ bit 1 bit 6 bits 1 byte _ Means or T Error CHANi Code contains the error Value 0 1 0-63 0-255 32 15 20 Appendix 2 being an integral part of the description - Examples of routing tables Table 1: Example of dynamic routing table with points localized sources in HP1 or HP2 IDdp CHANi IDsp PTi Mi Send Notifier Comments 1 ID (Pl) PT1 Ml ID (P3) ID (P2) Host processor HP1 to CLINT interface in ISOA reader mode 2 ID (Pl) PT2 Ml ID (P3) - Host processor HP1 to CLINT interface in ISOB reader mode 3 ID (Pl) PT3 Ml ID (P3) - Host processor HP1 to CLINT interface in ISO15 reader mode 4 ID (Pl) PT1 M3 ID (P3) ID (P2) Host processor HP1 to CLINT interface in "device" mode ISOA 5 ID (P1) PT2 M3 ID (P3) - HP1 host processor to CLINT interface in "device" mode ISOB 6 ID (Pl) PT3 M3 ID (P3) - HP1 host processor to CLINT interface in "device" mode ISO15 7 ID (Pl) - - ID (P2) Host processor HP1 to SIM card (HP2) 8 ID (P2) - - ID (P1) - SIM card (HP2) to host processor 9 ID (P2) PT1 M1 ID (P3) - SIM card (HP2) to CLINT interface in ISOA ID (P2) drive mode PT2 M1 ID (P3) ID (P2) SIM card (HP2) to CLINT interface in ISOB 11 ID reader mode (P2) PT3 Ml ID (P3) ID (P2) SIM Card (HP2) to CLINT Interface in Mode I5015 12 ID (P2) PT1 M3 ID (P3) - SIM (HP2) to CLINT interface in "device" mode ISOA 13 ID (P2) PT2 M3 ID (P3) ID (P2) SIM card (HP2) to interface CLINT in "device" mode ISOB 14 ID (P2) PT3 M3 ID (P3) ID (P2) SIM card (HP2) to CLINT interface in "device" mode ISO15 5 34 Table 2: Example of pre-recorded routing table with dots sources located in HP1 or HP2 ID SINGLE IDsp PTi Mi Send Notifier Busy Comments 1 ID (P1) PT1 Ml ID (P3) ID (P2) 1 Host processor HP1 to CLINT interface in ISOA reader mode 2 ID (Pl) PT2 M1 ID ( P3) - 0 Host processor HP1 to CLINT interface in ISOB reader mode 3 ID (Pl) PT3 M1 ID (P3) - 0 Host processor HP1 to CLINT interface in ISO15 drive mode 4 ID (P1) PT1 M3 ID (P3) ID (P3) P2) 0 Host processor HP1 to CLINT interface in "device" mode ISOA 5 ID (Pl) PT2 M3 ID (P3) - 0 Host processor HP1 to CLINT interface in "device" mode ISOB 6 ID (P1) PT3 M3 ID (P3) ) - 0 HP1 host processor to CLINT interface in "device" mode I5015 7 ID (Pl) - ID (P2) 1 Host processor HP1 to SIM card (HP2) 8 ID (P2) - - ID (Pl) -0 SIM card (HP2) to host processor HP1 9 ID (P2) PT1 Ml ID (P3) - 0 SIM card (HP2) to CLINT interface in ISOA reader mode 10 ID (P2) PT2 Ml ID (P3) ID (P2) 0 SIM card (HP2) to CLINT interface in ISOB 11 ID reader mode ( P2) PT3 Ml ID (P3) ID (P2) 0 SIM card (HP2) to CLINT interface in ISO15 reader mode 12 ID (P2) PT1 M3 ID (P3) - 1 SIM card (HP2) to CLINT interface in "device" mode "ISOA 13 ID (P2) F12 M3 ID (P3) ID (P2) 0 SIM card (HP2) to CLINT interface in" device "mode ISOB 14 ID (P2) PT3 M3 ID (P3) ID (P2) 0 SIM card (HP2) to CLINT interface in "device" mode ISO15 5 5 35 Table 3: Example of a dynamic routing table with a source point located in the CLINT interface and without implementing the second aspect of the invention (all data are sent to the two host processors HP1, HP2) SINGLE IDsp PTi Mi I.Ddp Comments 40 ID (P3) PTl Ml ID (Pl) ID (P2) CLINT interface in drive mode ISO A to host processors HP1, HP2 41 ID (P3) PT2 Ml ID (P1) ID (P2) CLINT interface in ISO B drive mode to host processors HP1, HP2 42 ID (P3) PT3 Ml ID (Pl) ID (P2) CLINT interface in ISO 15693 drive mode to host processors HP1, HP2 43 ID (P3) PT1 M2 ID (P2) ID (P2) CLINT interface in ISO A emulation mode to host processors HP1, HP2 44 ID (P3) 212 M2 ID (Pl) ID (P2) CLINT interface in ISO B emulation mode to host processors HP1, HP2 45 ID (P3) M2 PT3 ID (P1) ID (P2) CLINT interface in ISO 15693 emulation mode to HP1 host processors, HP2 46 ID (P3) PTl M3 ID (Pl) ID (P2) CLINT interface in "device" mode ISO A to host processors HP1, HP2 47 ID (P3) PT2 M3 ID (Pl) ID (P2) CLINT interface in mode "device" ISO B to host processors HP1, HP2 48 ID (P3) PT3 M3 ID (Pl) ID (P2) CLINT interface in "device" mode ISO 15693 to host processors HP1, HP2 36 Table 4: Example of a routing table prerecorded having a source point located in the inter CLINT face (second aspect of the invention) IDdp CHANi IDsp PTi Ni. Send Notifier Used Enclosures 40 ID (P3) PT1 M1 ID (P1) ID (P2) CLINT interface in ISO drive mode HP1 host processor 41 ID (P3) PT2 Ml ID (P1) ID (P2) CLINT interface in ISO drive mode B to Host Processor HP1 42 ID (P3) PT3 Ml ID (P2) CLINT Interface in ISO 15693 Drive Mode to SIM (H12) 43 ID (P3) PT1 M2 ID (P2) CLINT Interface in ISO Map A Emulation Mode to Card SIM (HP2) 44 ID (P3) PT2 M2 ID (Pl) _ CLINT interface in ISO B card emulation mode to HP1 host processor 45 ID (P3) PT3 M2 - ID (P2) CLINT interface in ISO 15693 card-to-card emulation mode SIM (HP2) (notification only) 46 ID (P3) PT1 M3 ID (Pl) (P2) "Device" mode ISO A; processor-controlled pairing ID (P2) 47 ID (P3) PT2 M3 - - No action (configuration prohibited) 48 ID (P3) PT3 M3 ID (P1) ID (P2) Device mode ISO 15693; pairing managed by the host processor

Claims

A method of routing data in a chipset comprising at least two host processors (HP1, HP2) and a RFID-type contactless data transmission / reception interface (CLINT) configurable according to a plurality of operating modes (Mi, Ml, M2, M3) and according to several contactless communication protocols (PTi, PT1, PT2, PT3), the method comprising a step of routing, to at least one of the host processors, data received by the interface of transmission / reception of contactless data via a contactless data transmission channel, characterized in that the routing step comprises a preliminary step of determining a destination point of the data in a host processor (HP1, HP2) in using as the destination point determination criteria the operation mode (Mi) and the contactless communication protocol (PTi) used by the contactless transmission / reception interface to create the tran channel smission of contactless data through which data is received.

The method according to claim 1, comprising the steps of: - pre-registering in a routing table (RT) data paths each comprising an identifier of a destination point (IDdp), a mode of operation parameter (Mi ) of the contactless data transmission / reception interface and a contactless communication protocol (PTi) parameter, and - when data is received by the contactless transmission / reception interface via a channel for contactless data transmission, determining at least one destination point of the data by searching in the routing table for a data path having an operating mode parameter (Mi) and a contactless communication protocol parameter (PTi) corresponding: to the operating mode and contactless communication protocol parameters used by the contactless transmission / reception interface to create the transmitted channel contactless data via which the data is received.

3. Method according to one of claims 1 and 2, comprising the steps of: - in response to a command (CMD) opening data path issued by a source point (P1, P2) located in the host processor , and designating a destination point (P3) located in the contactless transmission / reception interface (CLINT), defining a data path connecting the source point to the destination point by assigning the data path a number of routing channel (CHANi) and storing in a routing table (RT) the routing channel number and routing parameters comprising at least one identifier (IDsp) of the source point and an identifier (IDdp) of the destination point, sending to the destination point data provided by the source point by encapsulating them in a frame (DF) having a reduced header field including the routing channel number, and on receiving data encapsulated in a frame (DF) having a header field including the routing channel number, searching for a data destination point in the routing table using the routing channel number as the destination point selection index.

The method according to claim 3, comprising the steps of: - in response to a data path open command (CMD) issued by a source point (Pi, P2) located in the host processor and designating a point of destination (P3) located in the contactless transmission / reception interface (CLINT), open a data path between the source point and the destination point by assigning the data path a routing channel number (CHANi ) and storing in the routing table the routing channel number and routing parameters including an operating mode parameter (Mi) of the contactless transmission / reception interface and a communication protocol parameter without contact (PTi), and - configure the contactless transmission / reception interface to transmit data in a contactless data transmission channel using the operating mode parameters Ionization (Mi) and contactless communication protocol (PTi) contained in the routing table for the data path through which the data to be transmitted has been received.

5. Method according to one of claims 3 and 4, wherein the routing table is also used to open a data path between two host processors.

6. Method according to one of claims 1 to 5, comprising a step of predicting commands for creating data paths comprising routing parameters and configuration parameters of the interface for sending / receiving contactless data to register in the routing table.

The method of one of claims 1 to 6, wherein the routing table is dynamically populated or emptied when data paths having a source point located in a host processor (HP1, HP2) are created or closed.

8. Method according to one of claims 1 to 6, comprising a prerecording step in the routing table of data paths having a source point located in a host processor (HP1, HP2).

The method of one of claims 1 to 8, wherein source points or destination points registered in the routing table are services executed by a host processor.

The method of one of claims 1 to 9, wherein the routing parameters stored in the routing table also include a. identifier of a notification point (IDdp) to receive a copy of the data sent to the destination point.

11. Method according to one of claims 1 to 10, implemented in a chipset wherein a host processor is a secure circuit such as a SIM card integrated circuit.

12. Data transmission / reception device (NFCR2) comprising an RFID-type contactless data transmission / reception interface (CLINT) configurable according to several operating modes (Mi, Ml, M2, M3) and according to several protocols non-contact communication (PTi, PT1, PT2, PT3), a controller (NFCC) and at least two input / output ports (INT1, INT2) for connecting the contactless transmission / reception interface (CLINT) ) to at least two host processors (HP1, HP2), characterized in that the controller (NFCC) is configured to, when data is received by the contactless transmission / reception interface via a transmission channel of contactless data, determining at least one destination point of the data in a host processor (HP1, HP2) using as criteria for determining the destination point the operating mode (Mi) and the contactless communication protocol (PTi) used through the interface transmission / reception of contactless data to create the contactless data transmission channel through which the data is received.

Device according to claim 12, wherein the controller (NFCC) is configured to: - pre-register in a routing table (RT) data paths having a source point: Located in the data transmission / reception interface without contact (CLINT), and for each of these data paths, at least one destination destination identifier (IDdp), an operating mode parameter (Mi) of the transmission / reception interface contactless data and a non-contact communication protocol (PTi) parameter, and - when data is received by the contactless transmission / reception interface via a contactless data transmission channel, determining at least a data destination point by searching the routing table for a data path having an operating mode parameter (Mi) and a non-contact communication protocol parameter (PTi) corresponding to the function mode parameters and contactless communication protocol used by the contactless transmission / reception interface to create the contactless data transmission channel through which the data is received.

14. Device according to one of claims 12 and 13, wherein the controller (NFCC) is configured for: - in response to a command (CMD) data path opening issued by a source point (P1, P2) located in the host processor and designating a destination point (P3) located in the contactless transmission / reception interface (CLINT), open a data path between the source point and the destination point by assigning the path a routing channel number (CHANi) and storing in a routing table (RT) the routing channel number and routing parameters comprising at least one identifier (IDsp) of the source point and an identifier (IDdp) of the destination point, and - upon receiving data encapsulated in a frame (DF) having a header field including the routing channel number, searching for a destination point of the data in the routing table using the number of routa channel ge as the destination point selection index.

The device of claim 14, wherein: the controller (NFCC) is configured to respond to a data path open command (CMD) issued by a source point located in a host processor (HP1, HP2) ) and designating a destination point (P3) located in the contactless transmission / reception interface (CLINT), open a data path between the source point and the destination point by assigning the data path a number of a routing channel (CHANi) and storing in the routing table the routing channel number and routing parameters including an operating mode parameter (Mi) of the contactless transmission / reception interface and a contactless communication protocol parameter (PTi), and - the contactless transmission / reception interface is configured to transmit data in a contactless data transmission channel using the parameters the operating mode (Mi) and contactless communication protocol (PTi) in the routing table for the data path through which the data to be transmitted has been received.

Device according to one of claims 14 and 15, wherein the controller also uses the routing table to open a data path between two host processors (HP1, HP2).

Device according to one of claims 14 to 16, wherein the controller (NFCC) is configured to decode data path creation commands comprising routing parameters and configuration parameters of the transmission interface. receiving contactless data, and to record in the routing table the routing and configuration parameters present in the commands.

Apparatus according to one of claims 14 to 17, wherein the controller (NFCC) is configured to dynamically fill or v = _der the routing table when data paths having a source point located in a host processor ( HP1, HP2) are created or closed.

19. Device according to one of claims 14 to 17, wherein the controller (NFCC) is configured to pre-register in the routing table data paths having a source point located in a host processor (HP1, HP2).

20. Device according to one of claims 14 to 19, wherein source points or destination points recorded in the routing table are services executed by a host processor.

21. Device according to one of claims 14 to 20, wherein the routing parameters stored in the routing table also include a notification point identifier (IDdp) to receive copy of the data sent to the destination point.