Brevet FR3087307A1 — publié le 20200417

Description Titre de l'invention : Gestion de transactions dans un dispositif NFC Domaine technique [0001] La présente description concerne de façon générale les dispositifs électroniques et, plus particulièrement, les dispositifs intégrant des circuits de communication en champ proche (NFC - Ncar Field Communication). La présente description s'applique plus précisément à la gestion de transactions en champ proche entre des éléments du dispositif et l'extérieur. Technique antérieure [0002] Les systèmes de communication radiofréquence en champ proche sont de plus en plus fréquents, en particulier, depuis le développement des technologies de communication en champ proche selon la norme 1SO 14443 ou le NFC forum. [0003] Ces systèmes exploitent un champ électromagnétique radiofréquence émis par un dispositif (terminal ou lecteur) pour communiquer avec un autre dispositif (carte). [0004] Ces communications intègrent diverses transactions entre des éléments internes et externes au dispositif de communication en champ proche. La gestion de ces transactions est rendue complexe par la multiplicité des applications susceptibles d'être hébergées par le dispositif. Résumé de l'invention 100051 11 existe un besoin d'amélioration des dispositifs de communication en champ proche notamment en termes de gestion des transactions entre différentes applications hébergées par le dispositif. [0006] Un tel besoin est particulièrement présent pour la gestion d'applications requérant un environnement sécurisé comme, par exemple, la gestion des informations d'un fournisseur de services (les clés et données du fournisseur de services sont généralement protégées par des éléments offrant un haut niveau de sécurité contre les attaques). [0007] Un mode de réalisation vise à réduire tout ou partie des inconvénients des techniques connues de gestion de transactions dans un dispositif de communication en champ proche. [0008] Un mode de réalisation prévoit un procédé de routage de communications en champ proche, dans un dispositif comportant : - un routcur de communication en champ proche ; - au moins un élément sécurisé ; - un module d'interface utilisateur ; et - une unité de gestion, dans lequel l'unité de gestion sélectionne un élément sécurisé vers lequel aiguiller une communication. [0009] Selon un mode de réalisation, ladite unité de gestion sélectionne ledit élément sécurisé en fonction de données reçues du module d'interface utilisateur. [0010] Selon un mode de réalisation, ladite unité de gestion sélectionne ledit élément sécurisé à partir d'une analyse de la communication et/ou du champ électromagnétique. [0011] Selon un mode de réalisation, ladite unité de gestion sélectionne ledit élément sécurisé à partir d'informations sur l'environnement tel qu'un positionnement GPS, une information sur le type de transaction par WiFi, ou sur le type de transaction par Bluctooth. [0012] Selon un mode de réalisation, ladite unité de gestion sélectionne ledit élément sécurisé à partir d'une analyse d'une première trame de communication reçue. [0013] Selon un mode de réalisation, le routcur de communication en champ proche comporte une table de routage configurée au moins par l'unité de gestion. [0014] Selon un mode de réalisation, le routcur comporte une configuration dans laquelle sa table de routage oriente toute requête de sélection d'un environnement sécurisé vers l'unité de gestion. [0015] Selon un mode de réalisation, le routcur comporte une configuration dans laquelle sa table de routage oriente les requêtes de sélection des applications nonactives/non-disponibles hébergées dans un environnement sécurisé vers l'unité de gestion et oriente directement les requêtes de sélection des applications actives/ disponibles vers ces applications hébergées dans les éléments sécurisés. 100161 Selon un mode de réalisation, le routeur comporte une configuration dans laquelle sa table de routage oriente les requêtes de sélection vers un environnement sécurisé et, si la requête n'est pas à destination de l'élément sécurisé de cet environnement, le routeur envoie la requête à l'unité de gestion. 100171 Selon un mode de réalisation, le routeur comporte une configuration dans laquelle sa table de routage oriente les requêtes de sélection vers un environnement sécurisé et, si la requête n'est pas à destination de l'élément sécurisé de cet environnement, l'élément sécurisé informe l'unité de gestion. 100181 Selon un mode de réalisation, le routeur, une fois configuré par l'unité de gestion comporte, dans sa table de routage, des paramètres de routage des communications vers l'élément sécurisé sélectionné. 100191 Selon un mode de réalisation, une application utilisateur est associée au module d'interface utilisateur pour interazir avec l'unité de gestion. 100201 Selon un mode de réalisation, chaque élément sécurisé héberge au moins un envi- ronnement carte, un ou plusieurs environnements pouvant être sélectionnés par l'unité de gestion. [0021] Selon un mode dc réalisation, une communication est initiée par le routcur de com- munication en champ proche et est poursuivie sur un autre canal de communication radiofréquence. [0022] Un mode de réalisation prévoit un dispositif de communication en champ proche, comportant : - un routcur de communication en champ proche ; - plusieurs éléments sécurisés ; - un module d'interface utilisateur ; et - une unité de gestion, dans lequel, l'unité de gestion sélectionne un élément sécurisé vers lequel aiguiller une communication. [0023] Selon un mode dc réalisation, le dispositif est programmé pour la mise en oeuvre du procédé de routage de communications en champ proche. [0024] Selon un mode dc réalisation, l'unité dc gestion fait partie d'un contrôleur de com- munications en champ proche intégré dans le dispositif [0025] Un mode de réalisation prévoit un téléphone mobile, comportant un dispositif dc communication en champ proche. Brève description des dessins [0026] Ces caractéristiques et avantages, ainsi que d'autres, seront exposés en détail dans la description suivante de modes de réalisation particuliers faite à titre non limitatif en relation avec les figures jointes parmi lesquelles : [0027] lfig.11 la figure 1 représente, de façon très schématique et sous forme de blocs, un exemple de système de communication en champ proche du type auquel s'appliquent les modes de réalisation décrits ; [0028] [fig.2] la figure 2 représente, de façon très schématique et partielle, différents constituants d'un dispositif de communication en champ proche ; [0029] [fig.3] la figure 3 représente, de façon très schématique et sous forme de blocs, un exemple d'étapes pour effectuer une transaction entre des éléments interne et externe au dispositif par communication en champ proche ; et [0030] [fig.41 la figure 4 représente, de façon très schématique et partielle, un mode de réalisation d'un dispositif de communication en champ proche. Description des modes de réalisation 4 [0031] De mêmes éléments ont été désignés par de mêmes références dans les différentes figures. En particulier, les éléments structurels et/ou fonctionnels communs aux différents modes de réalisation peuvent présenter les mêmes références et peuvent disposer de propriétés structurelles, dimensionnelles et matérielles identiques. [0032] Par souci de clarté, seuls les étapes et éléments utiles à la compréhension des modes de réalisation décrits ont été représentés et sont détaillés. En particulier, les protocoles de communication (techniques de modulation du champ électromagnétique), qu'ils soient sécurisés ou non sécurisés, entre le dispositif et l'extérieur n'ont pas été détaillés, les modes de réalisation décrits étant compatibles avec les techniques usuelles de génération et de modulation de signaux radiofréquences pour communication en champ proche. [0033] Sauf précision contraire, lorsque l'on fait référence à deux éléments connectés entre eux, cela signifie directement connectés sans éléments intermédiaires autres que des conducteurs, et lorsque l'on fait référence à deux éléments reliés ou couplés entre eux, cela signifie que ces deux éléments peuvent être connectés ou être reliés ou couplés par l'intermédiaire d'un ou plusieurs autres éléments. [0034] Dans la description qui suit, lorsque l'on fait référence à des qualificatifs de position absolue, tels que les termes "avant", "arrière", "haut", "bas", "gauche", "droite", etc., ou relative, tels que les termes "dessus", "dessous", "supérieur", "inférieur", etc., ou à des qualificatifs d'orientation, tels que les termes "horizontal", "vertical", etc., il est fait référence sauf précision contraire à l'orientation des figures. [0035] Sauf précision contraire, les expressions "environ", "approximativement", "sen- siblement", et "de l'ordre de" signifient à 10 % près, de préférence à 5 % près. 100361 La figure 1 représente, de façon très schématique et sous forme de blocs, un exemple de système de communication en champ proche du type auquel s'appliquent les modes de réalisation décrits. 100371 Des circuits de communication en champ proche se retrouvent notamment dans des dispositifs électroniques communiquants, de type téléphone mobile 1. Typiquement, un téléphone mobile, équipé de fonctionnalités NFC, est capable de communiquer non seulement par le réseau de téléphonie sans fil (par exemple GSM) ou selon des protocoles radiofréquences à moyenne portée (par exemple, Wi-Fi, Bluetooth), mais également en champ proche (dit aussi sans contact), du quasi contact à 4-5 centimètres, d'après des normes, par exemple 14443 ou NFC Forum. On fera par la suite référence à un dispositif NFC pour désigner un dispositif intégrant des fonctionnalités de communication sans contact en champ proche. 100381 Le dispositif NFC (téléphone I en figure 1) est susceptible de communiquer par couplage électromagnétique en champ proche avec un autre dispositif NFC 3. Cet autre dispositif 3s, par exemple un terminal (TERM), rayonne un champ magnétique destiné à être capté par les circuits NFC du téléphone. On suppose le cas d'un téléphone 1 et d'un terminal 3 (par exemple, un terminal de paiement sans contact), niais tout ce qui va être décrit s'applique plus généralement à tout système dans lequel un transpondcur électromagnétique ou dispositif NFC capte un champ électromagnétique rayonné par un lecteur, home ou terminal. En d'autres ternies, les modes de réalisation s'appliquent à tout système dans lequel deux dispositifs NFC 1 et 3 sont susceptibles de communiquer par couplage électromagnétique en champ proche. Selon les applications, pour une communication, un des dispositifs fonctionne en mode dit lecteur tandis que l'autre fonctionne en mode dit carte, ou les deux dispositifs communiquent en mode poste à poste (peer to peer - P2P). Dans d'autres applications visées par la présente description, la communication est initiée en champ proche niais la transaction elle-même (la suite de la communication) est effectuée par un autre canal, par exemple Bluctooth ou autre canal de transmission sans contact. Chaque dispositif 1, 3, comporte divers circuits électroniques, parmi lesquels un circuit constituant une interface de communication en champ proche, ou interface NFC, entre le dispositif NFC et l'extérieur. Cette interface sert entre autres, en mode lecteur, à générer un signal radiofréquence émis à l'aide d'une antenne et, en mode carte, à décoder un signal radiofréquence capté. Le champ radiofréquence généré par l'un des dispositifs est capté par l'autre dispositif qui se trouve à portée et qui comporte également une antenne. [0039] Dans l'exemple d'un terminal mobile de type smartphone 1, ce dernier comporte au moins un écran 12 ainsi que des éléments 14 (boutons, touches, capteur d'empreinte, zones tactiles d'écran, caméras, etc.) constituant des éléments d'interface utilisateur. [0040] La figure 2 représente, de façon très schématique et partielle, différents constituants d'un dispositif 2 de communication en champ proche. Un tel dispositif peut faire partie du dispositif mobile 1 et du terminal 3 de la figure 1 selon les applications. 100411 Le fonctionnement en champ proche d'un dispositif 2 est basé sur l'utilisation d'un contrôleur NFC ou routeur NFC 22 (NFCC/CLF) associé à une tête d'émission-réception sans contact (CLF - ContactLess Front end). Le rouleur 22 communique d'une part avec une antenne 29 d'émission-réception et d'autre part avec un circuit hôte ou processeur hôte 21 (DEVICE HOST) du dispositif 2. Le circuit hôte 21 est susceptible de relayer des communications entre le contrôleur/routeur 22 et différentes applications hébergées par le dispositif 2. On fera par la suite indifféremment référence à un rouleur on contrôleur (rouleur NFC, routeur CLF, contrôleur NFC, contrôleur NFCC) pour désigner le circuit 22. 100421 Parmi ces applications, certaines sont des applications dites sécurisées (par op- position à des applications non sécurisées) qui font appel à des circuits spécifiques de validation ou de contrôle. Ces applications sécurisées sont alors, en tout ou en partie, hébergées par des circuits spécifiques communément appelés éléments sécurisés (Soeur° Elements - SE) qui sont pourvus de circuits de traitement et/ou de mémorisation de clé/code/signature/etc. permettant de valider/traiter/authentifier/etc. une opération ou transaction sécurisée. Par exemple, une transaction sécurisée consiste en une opération de paiement (une opération de paiement sans contact), une opération de contrôle d'accès, une opération de déverrouillage d'une application ou d'un périphérique, etc. [0043] Différents éléments sécurisés sont susceptibles de communiquer avec le processeur 21 pour effectuer (généralement de façon chiffrée) des transactions NFC. Il s'agit, par exemple : d'éléments sécurisés amovibles 23, montés dans un lecteur du dispositif 2, par exemple une carte SIM (Secure Identification Module) ; d'éléments sécurisés intégrés au dispositif 2, par exemple un élément sécurisé embarqué 24 (ESE - Embedded Secure Element) ou intégré (iSE - Integrated/ Imbedded Secure Element) ; et/ou d'éléments sécurisés portés par des éléments 25 externes au dispositif 2 (par exemple des cartes de paiement) et dont les informations transitent par un processeur 26 (PROC) générique (non dédié aux opérations NFC) que contient le dispositif 2 et qui communique avec le circuit 21 et, par cc biais, avec le contrôleur 22. [0044] Le contrôleur 22 contient notamment une table de routage définissant les paramètres et canaux de communication entre la tête d'émission-réception radiofréquence et les éléments du dispositif 2 en fonction de l'application exécutée. Cette table de routage permet au circuit hôte 21 d'aiguiller correctement les communications vers les différents éléments et au contrôleur 22 d'émettre correctement les communications reçues du circuit 21. Dans certains cas, des éléments sécurisés sont capables de communiquer directement avec le contrôleur 22 sans passer par le circuit hôte 21. Ce cas est illustré en figure 1 par des liaisons en pointillés entre le contrôleur 22 et les éléments 23 et 24. 100451 Des modules d'interface utilisateur 27 (UIM) sont également susceptibles de com- muniquer avec le contrôleur 21 lorsqu'une interaction avec l'utilisateur est requise. Ces modules sont typiquement des applications (app) dédiées aux différents systèmes susceptibles d'interagir avec le téléphone pour des applications requérant l'implication d'un élément sécurisé. H s'agit par exemple, d'applications de porte-monnaie électronique, d'applications de réservation de titres de transport, d'applications bancaires, etc. Ces modules d'interface utilisateur 27 utilisent l'écran 12 du téléphone et divers dispositifs d'entrée-sortie 14 afin d'interagir avec l'utilisateur. 100461 Bien entendu, d'autres applications peuvent également avoir accès au contrôleur NFCC 22 à des fins de communication en champ proche. Toutefois, les modes de réalisation décrits s'appliquent plus particulièrement à la gestion d'applications sé- 7 curisées. [0047] Le développement des applications NFC qui incluent de plus en plus d'applications sécurisées (par exemple, des applications de paiement) engendre des besoins particuliers en ternies de gestion des transactions NFC (utilisant des communications NFC). En particulier, de plus en plus d'éléments sécurisés, non portés par des cartes, émulent un fonctionnement de carte sans contact afin de permettre d'utiliser le téléphone 1 à la manière d'une carte sans contact. [0048] La figure 3 représente, de façon très schématique et sous forme de blocs, un exemple d'étapes pour effectuer une transaction entre des éléments interne et externe au dispositif par communication en champ proche ; [0049] Typiquement et de façon simplifiée, une transaction impliquant un élément sécurisé commence par un processus d'établissement d'une communication entre le dispositif 1 (figure 1) opérant en mode carte et un terminal 3. [0050] Le terminal 3 qui fonctionne en mode lecteur émet un champ électromagnétique ra- diofréquence destiné à être capté par une carte. Un tel champ est émis, selon les systèmes, de façon continue ou selon des trames périodiques jusqu'à ce qu'une carte 1 soit détectée (bloc 31, CARD DETECT). Une fois la carte détectée, un processus d'établissement de communication (bloc 33, COMM ESTABLISH) est mis en oeuvre. Lors de cette étape d'établissement de la communication, des paramètres radiofréquences spécifiques sont attendus par le terminal en fonction de l'application qu'il cible dans le téléphone. Ces paramètres diffèrent généralement en fonction de l'élément sécurisé impliqué dans la transaction à venir. Les paramètres peuvent concerner le type de modulation, le type de codage, des paramètres temporels, fréquentiels, etc. 100511 Lorsque la communication est établie, le terminal envoie au téléphone une requête (bloc 35, SELECT APPLI) de sélection de l'application en fonction de l'opération qu'il souhaite effectuer. Cette requête doit permettre, côté téléphone, de sélectionner l'application et plus particulièrement l'élément sécurisé, avec lequel effectuer ensuite la transaction. Une fois l'application sélectionnée, celle-ci a accès au routeur CLF 22 et la transaction est effectuée (bloc 37, PERFORM TRANS). La transaction est effectuée en utilisant la communication établie. 100521 Le processus décrit ci-dessus est en lui-même usuel pour ce qui est du fonc- tionnement côté terminal. 100531 Toutefois, côté dispositif opérant en mode carte, la présence de multiples éléments sécurisés engendre des contraintes particulières. 100541 En effet, il peut se produire que plusieurs éléments sécurisés, requérant d'utiliser les paramètres radiofréquences et hébergeant des applications qui sont simultanément disponibles côté terminal, donc du point de vue communication radiofréquence, soient présents. Dans ce cas, le routeur CLF 22 peut se trouver dans une situation où il lui faut déterminer à quel élément sécurisé faire suivre la requête et la transaction qui suit. [0055] Il peut également se produire que plusieurs systèmes d'exploitation (OS) ayant leurs propres applications sans contact (système VPP - Virtual Primary Platform) soient hébergés dans ou compatibles avec un même élément sécurisé intégré (iSE) ou embarqué (ESE) et que l'application VPP active ne soit pas compatible avec celle hébergée par le lecteur. [0056] Une difficulté est que, dans un système usuel, l'utilisateur ne sait pas qu'une action est requise au niveau du routcur CLF 22 afin de permettre la transaction. [0057] La figure 4 représente, de façon très schématique et partielle, un mode de réalisation d'un dispositif de communication en champ proche. [0058] On prévoit d'intercaler, entre le contrôleur NFC / routcur CLF 22 et le circuit hôte 21, une unité de gestion 4 (ME) dont le rôle est de permettre l'aiguillage des requêtes de sélection d'application provenant d'un terminal ainsi que les transactions sécurisées. Cette unité 4 communique (est interfacée) avec les différents éléments (23, 24, 25) émulant un environnement en mode carte sécurisé (CEE). L'unité 4 a également accès aux différents modules d'interface utilisateur 27 (UIM) c'est-à-dire aux applications en charge d'une interaction avec l'utilisateur. [0059] L'unité 4 peut faire partie du contrôleur NFC 22, du circuit hôte 22 ou être une entité distincte. [0060] Les modes de réalisation décrits tirent profit du fait que, dans la plupart des ap- plications sécurisées (de paiement, d'authentification, etc.), une intervention de l'utilisateur est requise. Une telle intervention correspond par exemple à la validation d'un paiement en cours de transaction avec un terminal de paiement, une acceptation d'un prélèvement, etc. 100611 Ainsi, il n'est pas gênant ni contraignant de faire appel à l'utilisateur pour valider celui des éléments sécurisés, ou plus généralement celui des environnements d'émulation carte (un même élément sécurisé pouvant comprendre plusieurs environnements), qui doit être sélectionné pour la transaction. De surcroît, de telles applications étant généralement considérées comme sensibles du point de vue de l'accès à des données privées, une telle sélection par l'utilisateur sera hien perçue. 100621 L'unité de gestion 4 connait (contient des paramètres et identifiants) toutes les ap- plications installées via tous les éléments sécurisés contenus dans le mobile. Pour cela, toute application hébergée dans un quelconque élément sécurisé du dispositif 2 s'enregistre (par exemple dans une phase d'initialisation du dispositif 2 ou lors du lancement de l'application concernée) auprès de l'unité 4. Ainsi, l'unité 4 connait, à tout moment, l'état actif ou non de chaque application. 100631 Lorsqu'un même élément sécurisé héberge plusieurs applications, c'est-à-dire plusieurs environnements d'émulation carte, l'unité de gestion 4 peut (via une commande de l'utilisateur) soit combiner les paramètres radiofréquence selon des règles associées aux différentes applications hébergées, soit sélectionner un seul environnement. [0064] Le routage en lui-même des requêtes et des transactions exploite les éléments usuels d'un routeur CLF. En particulier, un tel routeur 22 comporte généralement une table de routage lui permettant d'aiguiller les communications vers les éléments (sécurisé ou non sécurisé) appropriés du téléphone. L'intervention de l'unité de gestion 4 consiste à configurcr le contrôleur NFCC, donc modifier sa table de routage afin de lui permettre d'aiguiller correctement les transactions. [0065] En variante, toute communication et transaction transite par l'unité de gestion qui effectue directement l'aiguille vers les éléments sécurisé, la table de routage du routeur aiguillant toute communication et transaction sécurisée vers l'arbitre du module de gestion. [0066] Le fonctionnement du système est le suivant. L'unité de gestion 4 programme le routeur 22 (sa table de routage) afin que, lorsqu'une commande de sélection provenant d'un terminal appelle une application sécurisée qui n'est pas disponible dans le contrôleur 22 (par exemple, une application sécurisée qui n'est pas active), cette commande soit redirigée vers un circuit ou une fonction d'arbitrage ou de sélection contenue dans l'unité de gestion 4. La fonction d'arbitrage est configurée (programmée) pour que lorsque « l'Arbitre » reçoit une commande de sélection, soit il sélectionne l'environnement carte approprié, soit il propose à l'utilisateur de sélectionner l'environnement qu'il souhaite. 100671 De préférence, une fois la sélection effectuée, celle-ci est programmée dans la table de routage du routeur 22 de façon à gagner du temps lors des transactions ultérieures. Cette programmation subsiste (c'est-à-dire que l'Arbitre est inactif) tant que l'utilisateur n'effectue pas une intervention volontaire ou que l'environnement en termes d'éléments sécurisés n'est pas modifié (ajout, suppression d'un élément sécurisé par exemple). 100681 De préférence, lorsque le téléphone mobile (le routeur CLF) détecte un appel à un en- vironnement sécurisé, seules les applications sécurisées sont actives et les autres applications hébergées par le téléphone sont désactivées, à l'exception d'une application spécifique associée à l'unité de gestion pour permettre à l'utilisateur de sélectionner l'élément sécurisé qu'il souhaite associer à la requête. 100691 La sélection par l'utilisateur fait donc appel, de préférence, à une application spécifique, associée à l'unité de gestion. Une telle application est, par exemple, lancée automatiquement par l'unité de gestion à réception d'une requête de sélection qu'il reçoit du routeur 22 et à tout moment sous commande de l'utilisateur. IO [0070] La détection, par l'unité de gestion 4, de la nature et du type de transaction, pour lui permettre de sélectionner l'élément sécurisé ou l'application/environnement d'un élément sécurisé vers lequel aiguiller la communication, peut prendre différentes formes. Selon un mode de réalisation, l'unité de gestion 4 sélectionne l'élément sécurisé et/ou un environnement et/ou une application dans celui-ci à partir d'une analyse de la communication et/ou du champ électromagnétique (par exemple l'intensité du champ, le type de requêtes d'interrogation (polling), les pauses entre les requêtes, le processus d'anticollision utilisé, la gestion d'erreurs dans le processus d'anticollision, etc.). Selon un autre exemple, l'unité de gestion reçoit une information de l'utilisateur, via le module d'interface 27, lui permettant d'identifier l'élément sécurisé et/ou l'environnement/application. Selon encore un autre exemple, l'unité de gestion 4 analyse la première trame reçue du lecteur pour identifier l'élément sécurisé et/ou l'environnement ou l'application concerné. Ces modes de détection sont bien entendu combinables. Dans tous les cas, on peut prévoir que tout changement de configuration à la suite de cette détection soit conditionné par une confirmation par l'utilisateur, via le module d'interface utilisateur 27. [0071] A titre d'exemple particulier de réalisation, on peut mentionner les situations suivantes. [0072] On suppose le cas d'un système comportant une puce sécurisée qui implémente un système de gestion de plusieurs systèmes d'exploitation (OS) avec la limitation qu'un seul système d'exploitation à la fois peut exploiter les ressources du processeur 26 (figure 1). Par conséquent, s'il faut activer un autre système d'exploitation, il faut « décharger » le premier pour (re)charger le deuxième (technologie décrite comme VPP). Si le système d'exploitation qui est actif au moment de la transaction NFC héberge une application de paiement mais que l'application visée par la transaction NFC se trouve dans le deuxième système d'exploitation contenu dans un élément sécurisé qui n'est pas actif au moment de la transaction, le routeur CLF 22 transmet la requête à l'unité de gestion 4 qui, lorsqu'elle détectera la requête, reconfigurera l'élément sécurisé pour que le deuxième système d'exploitation soit disponible dans la nouvelle transaction. L'unité de gestion 4 prend en charge (ou fait effectuer) la reconfiguration de la table de routage du contrôleur NFCC pour que la transaction suivante soit envoyée à l'élément sécurisé qui héberge le deuxième système d'exploitation. 100731 Selon un autre exemple, on suppose un système hébergeant plusieurs éléments sécurisés qui ne travaillent pas en mode collahoratif (Managing Entity - legacy). L'unité de gestion 4 intercepte alors le début de la transmission pour reconfigurer le routeur CLF afin que la prochaine transmission atteigne l'élément sécurisé qui héberge l'application visée par la transaction. Par exemple, un élément sécurisé embarqué (eSE) 24 héberge une application de paiement et un module d'identification sécurisé (STIVI) 23 héberge une application de transit. En supposant que, dans la configuration courante, le contrôleur NFCC envoie les transactions de paiement à l'élément sécurisé embarqué 24 et les transactions de transit à l'unité de gestion 4, si le lecteur sans contact démarre une transaction de transit, cette transaction sera envoyée à l'unité de gestion qui va reconfigurer les tables de routage du contrôleur NFCC (et les autres paramètres si besoin) pour que la prochaine transaction soit envoyée vers le module d'identification sécurisé (STIVI) 23 et que les transactions de paiement soient envoyées vers l'unité de gestion 4. [0074] Dans les deux exemples ci-dessus, l'unité de gestion 4 pourrait demander à l'utilisateur une confirmation pour la rcconfiguration. [0075] Par ailleurs, dans ces deux exemples, l'unité de gestion 4 détecte le type de transaction grâce aux débuts de trame envoyés. D'autres méthodes peuvent également être utilisées pour détecter le type de transaction (par exemple, l'analyse du champ du lecteur, l'analyse du type de polling, de l'anticollision, etc.). On pourrait également utiliser d'autres moyens tel que le GPS (par exemple, dans le métro, l'unité de gestion sélectionnerait l'application de transit) ou une identification du type de transaction sur un autre canal (par exemple, un signal Bluetooth ou Wi-Fi indiquerait le type de transaction dans un magasin). [0076] D'autres réalisations sont bien entendu possibles. [0077] Un avantage des modes de réalisation décrits est qu'ils ne requièrent pas de modifier les applications elles-mêmes. En effet, l'unité de gestion gère d'elle-même l'appel à l'application/interface utilisateur qui permet d'aiguiller correctement la requête de sélection provenant du terminal ainsi que la transaction qui suit. 100781 Un avantage des modes de réalisation décrits est qu'ils ne requièrent aucune modi- fication côté terminal. Ainsi, des dispositifs carte I réalisés selon les modes de réalisation décrits sont compatibles avec les terminaux existants. 100791 Divers modes de réalisation et variantes ont été décrits. L'homme de l'art comprendra que certaines caractéristiques de ces divers modes de réalisation et variantes pourraient être combinées, et d'autres variantes apparaitront à l'homme de l'art. Par exemple, on peut prévoir qu'une communication soit initiée par le routeur de communication en champ proche 22 et que la communication soit ensuite poursuivie (c'est-à-dire que la transaction elle-même, de paiement par exemple, soit effectuée) sur un autre canal de communication radiofréquence, par exemple Wifi, Bluetooth, etc. 100801 Enfin, la mise en oeuvre pratique des modes de réalisation et variantes décrits est à la portée de l'homme du métier à partir des indications fonctionnelles données ci-dessus. En particulier, la réalisation matérielle et logicielle de l'unité de gestion est à la portée de l'homme du métier en fonction de l'application et des indications fonctionnelles données.