FR 2881007 A1 20060721 FR 0500543 A 20050119 102480 Fr GEM1744- Henri Ohanian-Christophe Aillaud ETABLISSEMENT D'UNE COMMUNICATION ENTRE DISPOSITIFS SANS CONTACT L'invention porte sur les communications radiofréquences entre un dispositif sans contact maître et des dispositifs sans contact esclaves. L'invention concerne en particulier l'établissement d'une communication par une requête d'identification d'applications émise depuis un dispositif maître et par des réponses des dispositif esclaves dans des créneaux temporels définis par le dispositif maître. Le standard ISO 14443 définit des exigences pour une transaction radiofréquence entre une carte à puce sans contact et un terminal. La transaction comprend plusieurs phases successives. Lors d'une première phase, dite de mise sous tension, l'interface radiofréquence du terminal est allumée et réinitialisée. Le terminal émet avec une porteuse à 13,56 MHz. Les cartes situées dans le champ d'émission redressent la porteuse émise pour alimenter leurs circuits. Lors d'une deuxième phase, appelée phase de démarrage et d'anticollision, le terminal détermine la présence d'une ou plusieurs cartes dans son champ d'émission. Selon l'ISO 14443-3 type B, le terminal émet notamment une requête exigeant que les cartes situées dans son champ d'émission se présentent et définissant un nombre de créneaux temporels de réponse. Le terminal définit également les créneaux temporels de réponse, la fin d'émission de la requête lançant le premier créneau temporel. La figure 1 illustre ce fonctionnement: la requête REQB4SM du terminal annonce 4 créneaux temporels de réponse pour les différentes cartes dans son champ d'émission. Le premier créneau temporel débute à la fin de la requête REQB4SM. Le terminal émet ensuite des marqueurs de créneau SM2, SM3 et SM4 dont la fin marque le début des deuxième, troisième et quatrième créneaux temporels. Deux cartes répondent à la requête REQB4SM. Les cartes répondent respectivement par les trames de réponse ATQB1 et ATQB2. Chaque carte répond dans un créneau temporel distinct par une trame de réponse unique. Une réponse ATQB comprend les, données suivantes: un identifiant de carte pseudo-aléatoire, des paramètres de communication et des informations pour l'exécution d'une application par défaut. Les informations comprennent notamment un identificateur de l'unique famille d'applications (désigné par l'acronyme AFI en langue anglaise) par défaut dans la carte. Les informations comprennent également le nombre d'applications embarquées associées à cette famille d'applications ainsi que le nombre total d'applications embarquées dans la carte. Le terminal détermine ainsi les caractéristiques de ces cartes et en sélectionne une ou plusieurs. Lors d'une troisième phase, appelée phase d'activité, des échanges de commande sont effectués entre le terminal et une carte sélectionnée pour permettre l'exécution d'une famille d'applications (transport, opération bancaire, décompte de points de fidélité, contrôle d'identité... ) durant la transaction. De plus en plus fréquemment, une carte à puce présente plusieurs applications, familles ou sous-familles d'applications distinctes. Afin de déclarer ces différentes applications ou familles d'applications, un procédé connu propose de réaliser plusieurs phases de démarrage et d'anticollision successives. A de l'unique chaque nouvelle phase, l'identificateur famille d'applications par défaut est associé à une autre application ou famille d'applications. Ce procédé présente des inconvénients. Certaines transactions, telles que l'autorisation de passage d'un 15 usager à un portique de métro ou à un péage, requièrent une durée totale d'exécution inférieure à 100 millisecondes. La durée (et donc le nombre) des phases de démarrage et d'anticollision doit donc être limitée. Ainsi, l'ensemble des applications ou familles d'applications ne peut pas être déclaré dans une telle transaction. Il_ existe donc un besoin pour un dispositif sans contact esclave comprenant: -plusieurs applications; -une interface de communication sans contact; -un module de traitement, apte à interpréter une requête de présentation et des marqueurs de créneaux temporels reçus sur l'interface de communication sans contact, apte à sélectionner plusieurs applications ou 30 familles d'applications correspondant à la requête de présentation, apte à émettre un identifiant de dispositif sans contact esclave distinct pour chaque application ou famille d'applications sélectionnée, dans an créneau temporel distinct, en réponse à la requête de présentation. Selon une variante, le module de traitement est apte générer lesdits identifiants de dispositif sans contact et de les associer à des applications ou familles d'applications respectives, préalablement à ou lors du démarrage de la requête de présentation. Selon encore une variante, le dispositif comprend un identificateur distinct pour chaque application ou famille d'applications, le module de traitement étant apte à émettre l'identificateur d'une application ou famille d'applications dans le créneau temporel d'émission de l'identifiant de dispositif esclave associé à cette application ou famille d'applications. Selon une autre variante, le dispositif sans contact esclave est une carte à puce. L'invention concerne également un procédé d'établissement d'une communication sans contact comprenant les étapes suivantes: -un dispositif sans contact maître émet une requête de présentation définissant au moins des applications ou familles d'applications recherchées, et définit des créneaux temporels de réponse; -au moins un dispositif sans contact esclave tel que défini ci-dessus et disposé dans le champ d'émission sélectionne des applications ou familles d'applications et émet un identifiant de dispositif sans contact esclave distinct pour chaque application ou famille d'applications sélectionnée, dans un créneau temporel distinct, en réponse à la requête de présentation. Selon une variante, le module de traitement génère lesdits identifiants de dispositifs sans contact et les associe à des applications ou familles d'applications respectives, préalablement à ou lors de la requête de présentation. Selon encore une variante, le module de traitement émet un identificateur distinct pour chaque application ou famille d'applications sélectionnée dans le créneau temporel d'émission de l'identifiant de dispositif esclave associé à cette application ou famille d'applications sélectionnée. Selon une autre variante, les émissions entre les dispositifs sans contact maître et esclave sont conformes aux spécifications de la norme ISO 14443-3 type B. L'invention sera mieux comprise à la lecture de la description qui suit, accompagnée des dessins annexés qui représentent: Figure 1, des échanges selon l'art antérieur entre un terminal et une carte à puce durant la phase de démarrage et d'anticollision; -Figures 2 à 4, différents cas de figure d'échanges selon L'invention entre un terminal et une carte à puce durant la phase de démarrage et d'anticollision. L'invention propose de répondre à une requête de présentation d'un dispositif sans contact maître par plusieurs réponses d'un même dispositif sans contact esclave, déclarant plusieurs de ses applications ou familles d'applications dans des créneaux temporels de réponse distincts. Un identifiant de dispositif sans contact esclave distinct est associé à chaque application ou famille d'applications et émis en réponse à la requête. Plusieurs dispositifs sans contact esclaves sont virtuellement déclarés par un unique dispositif sans contact esclave. Un même dispositif sans contact esclave peut donc exploiter plusieurs créneaux temporels de réponse prévus à l'origine pour une réponse unique de chacun des dispositifs sans contact esclave disposé dans le champ d'émission du dispositif sans contact maître. Plusieurs applications ou familles d'applications peuvent ainsi être déclarées par un dispositif sans contact esclave dans le temps réduit d'une seule phase de démarrage et d'anticollision. La durée de transaction entre les dispositifs sans contact maître et esclave n'est ainsi pas rallongée. L'application de l'invention aux spécifications de la norme ISO 14443-3 type B décrite par la suite n'est donnée qu'à titre d'exemple, l'invention étant applicable à des protocoles dans lesquels une problématique similaire se pose. De même, l'invention est décrite dans son application à un terminal et à une carte à puce mais est applicable pour d'autres dispositifs sans contact maître et esclave. La figure 2 illustre un chronogramme d'un premier exemple d'échanges durant une phase de démarrage et d'anticollision. Les émissions du terminal et d'une première carte à puce sont illustrées respectivement sur les parties haute (PCD) et basse (Picc) du chronogramme. Lors d'une première étape, le terminal émet une requête ReqB4SMOO de présentation des cartes à puce disposées dans son champ d'émission. Cette requête peut prendre la forme suivante: 05h 00h 02h CRCB Le premier paramètre est un identifiant du terminal. Le second paramètre définit l'application ou la/les familles d'applications requises (identifiées par un AFI) pour les cartes à puces devant répondre. En l'occurrence, la valeur 00h définit que toute carte dans le champ doit répondre, quelles que soient ses applications. Le troisième paramètre définit le nombre de créneaux temporels de réponse à la requête. En l'occurrence, la valeur 02h définit l'utilisation de 4 créneaux temporels. La fin de la requête marque le début du premier créneau temporel. Une première carte à puce disposée dans le champ d'émission réceptionne la requête de présentation sur son interface de communication sans contact et son module de traitement traite la requête. Cette carte à puce dispose de 2 applications de transport, identifiées par des AFI respectifs 12h et 13h, appartenant à la famille d'applications lxh. La carte à puce dispose d'une application bancaire identifiée par l'AFI 21h et appartenant à la famille d'applications 2xh. =Le module de traitement sélectionne alors les applications qui correspondent à la requête du terminal. En l'occurrence, toutes les applications sont sélectionnées. Le module de traitement commande alors l'émission d'une réponse pour chaque application dans un créneau temporel distinct. Les créneaux temporels autres que le premier sont définis à l'expiration des marqueurs SM2 à SM4 émis par le terminal. Les réponses ATQB1, ATQB2 et ATQB4 sont transmises respectivement dans les premier, deuxième et quatrième créneaux temporels. Les réponses peuvent présenter la structure suivante: ATQB1: PUPI1 ApplicationDatal(AFI=13h) Protolnfol CRCB ATQB2: PUPI2 ApplicationData2(AFI=12h) Protolnfo2 CRCB ATQB3: PUPI3 ApplicationData3(AFI=21h) Protolnfo3 CRCB Le premier paramètre PUPI correspond à un identifiant de carte à puce distinct associé à chaque AFI transmis par la carte. La carte à puce déclare donc virtuellement au terminal les différentes applications ou familles d'applications sélectionnées comme des cartes à puces distinctes. Chaque identifiant de carte à puce est par exemple généré préalablement à ou lors de la réception de la requête en présentation, et mémorisé dans une table de la carte à puce. Le terminal détecte ainsi les différentes applications de la carte à puce comme différentes cartes à puce. Le second paramètre définit l'AFI d'une application. Le troisième paramètre définit un ou plusieurs paramètres du protocole associé à une application. A l'expiration des créneaux temporels, le terminal émet une commande de sélection Sel. Cette commande comprend l'identifiant PUPI1 et sélectionne ainsi l'application correspondant à l'AFI 13h dans la carte à puce. La commande de sélection peut prendre la structure suivante: lDh PJPI1 Paraml,2,3,4 Highlayer -INF(options) CRCB Le troisième paramètre définit l'utilisation qui est faite du protocole spécifié dans la réponse ATQB1. Le cinquième paramètre définit des options pour le traitement de la commande. A réception de la commande de sélection, la carte à puce détermine que la transaction avec le terminal mettra en oeuvre l'application 13h. L'association des identifiants PUPI aux applications ou familles d'applications est soit réalisée par la carte à puce de façon pseudoaléatoire, soit prédéfinie lors de sa fabrication. L'association des identifiants PUPI aux applications ou familles d'application est de préférence générée avant l'étape de démarrage et d'anti-collision, afin de ne pas rallonger la durée de la transaction. La figure 3 illustre un chronogramme d'un autre exemple d'échanges durant la phase de démarrage et d'anticollision. Lors d'une première étape, le terminal émet une requête RegB4SM10 de présentation des cartes à puce disposées dans son champ d'émission. Cette requête peut prendre la forme suivante: 05h 10h 02h CRCB La valeur 10h du second paramètre définit que toute carte dans le champ doit répondre si elle dispose d'une quelconque application de la famille lxh. La famille lxh correspond à la famille des applications de transport dans l'exemple. La valeur 02h du troisième paramètre définit 4 créneaux temporels de réponse. Comme dans l'exemple précédant, la requête RegB4SM10 et les marqueurs SM2, SM3 et SM4 délimitent les créneaux temporels de réponse. La première carte à puce dispose de 2 applications correspondant à la requête: les applications 12h et 13h. Le module de traitement sélectionne ces deux applications comme correspondant à la requête. Le module de traitement commande alors l'émission d'une réponse pour ces deux applications dans un créneau temporel distinct. Les réponses ATQB1 et ATQB2 sont transmises respectivement dans les deuxième et quatrième créneaux temporels. Les réponses peuvent présenter la structure suivante: ATQB1: PUPI1 ApplicationDatal(AFI=13h) Protolnfol CRCB ATQB2: PUPI2 ApplicationData2(AFI=12h) Protolnfol CRCB Le terminal traite les réponses et émet une commande de sélection Sel. Dans cette commande, il fournit l'identifiant PUPI2 et sélectionne ainsi l'application correspondant à l'AFI 12h dans la première carte à puce. La commande de sélection peut prendre la structure suivante: 1Ch PUPI2 Paraml,2,3,4 Highlayer INF(options) CRCB Ainsi, la carte à puce détermine que l'application 12h sera utilisée lors de la transaction avec le terminal. La figure 4 illustre un chronogramme d'un autre exemple d'échanges durant la phase de démarrage et d'anticollision, dans le cas où une seconde carte à puce est également présente dans le champ d'émission du terminal. La seconde carte à puce, réalisée selon l'état de la technique, présente uniquement une application bancaire 21h. Lors d'une première étape, le terminal émet une requête RegB4SM20 de présentation des cartes à puce. La première carte à puce dispose d'une seule application correspondant à la requête: l'application 21h. Son module de traitement sélectionne cette application comme correspondant à la requête. Le module de traitement commande alors l'émission d'une réponse ATQB3 pour cette application dans le quatrième créneau temporel. La seconde carte à puce répond automatiquement à la requête correspondant à son unique AFI dans le premier créneau temporel. Sa réponse peut présenter la structure suivante: ATQB4: PUPI4 ApplicationData4(AFI=21h) ProtoInfo4 CRCB Le terminal traite les réponses des cartes à puce et émet une commande de sélection Sel. Cette commande comprend l'identifiant PUPI4 et sélectionne ainsi l'application correspondant à l'AFI 21h dans la seconde carte à puce. La commande de sélection peut prendre la structure suivante: 1Eh PUPI4 Paraml,2,3,4 Highlayer -INF(options) CRCB Ainsi, la seconde carte à puce détermine qu'elle est sélectionnée et que l'application 21h sera utilisée lors de la transaction avec le terminal. Une carte à puce et un procédé selon l'invention peuvent donc être mis en oeuvre sans perturber la réponse de cartes à puce selon l'art antérieur. REVENDICATIONS 1. Dispositif sans contact esclave (Picc) comprenant: plusieurs applications; - une interface de communication sans contact; - un module de traitement, apte à interpréter une requête de présentation (RegB4SM00) et des marqueurs de créneaux temporels (RegB4SM00, SM2, SM3, SM4) reçus sur l'interface de communication sans contact; - caractérisé en ce que: -. 1e module de traitement est: -apte à sélectionner plusieurs applications ou familles d'applications correspondant à la requête de présentation (RegB4SM00) ; -apte à émettre un identifiant de dispositif sans contact esclave distinct pour chaque application ou famille d'applications sélectionnée, dans un créneau temporel distinct, en réponse à la requête de présentation. 2. Dispositif sans contact esclave selon la revendication 1, dans lequel le module de traitement est apte à générer lesdits identifiants de dispositif sans contact et de les associer à des applications ou familles d'applications respectives, préalablement à ou lors du démarrage de la requête de présentation. 3. Dispositif sans contact selon la revendication 1 ou 2, comprenant un identificateur distinct pour chaque application ou famille d'applications, le module de traitement étant apte à émettre l'identificateur d'une application ou famille d'applications dans le créneau temporel d'émission de l'identifiant de dispositif esclave associé à cette application ou famille d'applications. 4. Dispositif sans contact esclave selon l'une quelconque des revendications précédentes, dans lequel ce dispositif sans contact esclave est une carte à puce. 5. Procédé d'établissement d'une communication sans contact, caractérisé en ce qu'il comprend les étapes 15 suivantes: - un dispositif sans contact maître (PCD) émet une requête de présentation (ReqB4SMOO) définissant au moins des applications ou familles d'applications recherchées, et définit des créneaux temporels de réponse; - au moins un dispositif sans contact esclave selon l'une quelconque des revendications précédentes et disposé dans le champ d'émission sélectionne des applications ou familles d'applications et émet un identifiant de dispositif sans contact esclave distinct pour chaque application ou famille d'applications sélectionnée, dans un créneau temporel distinct, en réponse à la requête de présentation. 6. Procédé d'établissement d'une communication sans contact selon la revendication 5, dans lequel le module de traitement génère lesdits identifiants de dispositifs sans contact et les associe à des applications ou familles d'applications respectives, préalablement à ou lors de la requête de présentation. 7. Procédé d'établissement d'une communication sans contact selon la revendication 5 ou 6, dans lequel le module de traitement émet un identificateur distinct pour chaque application ou famille d'applications sélectionnée dans le créneau temporel d'émission de l'identifiant de dispositif esclave associé à cette application ou famille d'applications sélectionnée. 8. Procédé d'établissement d'une communication sans contact selon l'une quelconque des revendications 5 à 7, dans lequel les émissions entre les dispositifs sans contact maître et esclave sont conformes aux spécifications de la norme ISO 14443-3 type B.