FR2816785A1

FR2816785A1 - Protocole de communication entre une carte a puce de type pro-active et son terminal d'accueil

Info

Publication number: FR2816785A1
Application number: FR0014440A
Authority: FR
Inventors: Renaud Mariana
Original assignee: Bull CP8 SA
Current assignee: Bull CP8 SA
Priority date: 2000-11-10
Filing date: 2000-11-10
Publication date: 2002-05-17
Anticipated expiration: 2020-11-10
Also published as: FR2816785B1; WO2002039369A1

Abstract

Le protocole de communication PCINV gère la communication et les échanges de données entre une carte à puce proactive CPA 10 compatible ISO 7816-3/ 4 et son terminal d'accueil TAC 12 au travers d'un lecteur de carte LEC 11, le terminal TAC 12 de type PC étant relié à un réseau externe de type Internet ou X25 par un câble réseau 53. Le terminal TAC 12 peut être également en liaison avec un lecteur local auxiliaire. Le protocole de communication représenté par la couche PCINV intègre et étend les commandes pro-actives APDU de lecteur de carte de la couche PCPA et la procédure de Notification de carte de type Evénement sur lecteur de carte, en particulier pour une carte SIM pro-active les commandes et procédure de la spécification GSM 11. 14/ classe a. Les transferts de données sont gérés par sessions de communication sur canaux de données alloués dynamiquement.

Description

PROTOCOLE DE COMMUNICATION ENTRE UNE CARTE A PUCE DE TYPE
PRO-ACTIVE ET SON TERMINAL D'ACCUEIL La présente invention concerne un protocole de communication entre une carte à puce de type pro-active et son terminal d'accueil, le protocole étant destiné entre autres à gérer des transferts de données soit localement entre la carte à puce et un équipement associé au terminal d'accueil, soit à distance entre la carte à puce et un équipement associé à un terminal distant connecté à un réseau externe. On notera que dans le cadre de l'invention le terme données est pris dans son sens le plus large et couvre, outre des fichiers de données proprement dits, des instructions codées, des programmes et autres logiciels, des protocoles de communication, des messages divers, etc..

D'une façon générale les cartes à puce de type pro-active utilisables dans le cadre de l'invention sont conformes aux normes ISO 7816-3 et 7816-4 (ci-après ISO 7816-3/4) de l'Organisation Internationale de Normalisation. Une telle carte communique et échange des données avec son terminal d'accueil, par exemple un mobile téléphonique, suivant le protocole T=0 défini par la norme ISO 7816-3 et selon lequel les dialogues sont toujours réalisés à l'initiative du terminal, celui-ci envoyant des commandes entraînant des réponses par la carte. Ces commandes présentent un format spécifique APDU (Application Protocol Data Unit) et permettent entre autre le transfert de données. Dans certains cas la carte ISO 7816-3/4 est qualifiée de pro-active lorsqu'elle est capable par des commandes appropriées dites pro-actives d'initier des actions sur le terminal.

Parmi les exemples de cartes à puce ou à microprocesseur ISO 7816-3/4 utilisables dans le cadre de la présente

invention on peut citer de façon non limitative les cartes à microprocesseur SIM (Subscriber Identity Module) permettant l'identification d'un abonné. Ces cartes SIM sont largement utilisées aujourd'hui notamment dans la téléphonie mobile, dans les décodeurs de télévision à péage et dans les systèmes de contrôle d'accès.

A titre d'exemple non limitatif, les spécifications GSM (Global System for Mobile Communications) de l'ETSI (European Telecommunications Standards Institute), couramment utilisées dans la téléphonie mobile, définissent un certain nombre de commandes pro-actives, notamment dans la spécification GSM 11.14 compatible ISO 7816-3/4. Ces commandes pro-actives GSM 11.14 sont regroupées sous le vocable SIM Application Toolkit ou SIMToolkit . De plus à côté de la version de base de la spécification GSM 11.14 ont été définies cinq versions étendues à commandes additionnelles à la version de base et ci-après nommées de GSM 11. 14/classe a à GSM 11.14/classe e . Par exemple la version GSM 11.14/classe a intègre des commandes pro-actives

permettant à la carte SIMToolkit de dialoguer avec un lecteur de carte additionnel physiquement présent dans le terminal GSM et/ou avec la carte résidant dans ce lecteur en particulier une carte bancaire ou un portefeuille électronique.

Avec le développement des réseaux de données, notamment du réseau Internet, il apparaît intéressant pour une carte à puce d'être en mesure de dialoguer avec une infrastructure de réseau telle qu'un serveur ou une autre carte à puce dans de bonnes conditions de fiabilité et de rapidité.

En particulier le développeur-programmeur d'applications SIM, notamment SIMToolkit, contenant des échanges de

données avec une entité du réseau doit pouvoir disposer d'un canal de communication assurant toutes les garanties d'acheminement dans un temps raisonnable.

Cependant les capacités en mémoire et les temps de traitement des données sont trop limités sur une carte à puce pour généraliser la technique connue des mini messages SMS actuellement utilisée pour faire communiquer la carte SIMToolkit avec le monde extérieur. Il est de fait impossible de faire coexister sur une même carte

SlMToolkit plusieurs applications logicielles utilisant des mini messages. De plus le temps d'une transaction quelque peu complexe dépasse la minute.

La spécification GSM 11.14 définit en effet un mécanisme d'envoi et de réception de mini messages SMS (Short Message Service). Ces mini messages sont courts avec 140 octets au maximum. Malgré un faible débit, l'utilisation de ces mini messages permet à une application d'envoyer des données à un équipement (serveur, cartes à puce, etc...) par l'envoi d'un ou plusieurs mini messages.

L'échange en sens inverse s'effectue également par l'envoi de mini messages du destinataire, l'application SIMToolkit utilisant une commande ENVELOPE définie par la spécification GSM 11.14.

Toutefois cette technique SMS a l'inconvénient d'être peu pratique à programmer, l'application logicielle en effet sortant à chaque envoi d'un mini message (avec perte des paramètres de la connexion) d'où la nécessité de garder un contexte pour interpréter l'ensemble des mini messages reçus. La programmation SIMToolkit par mini messages SMS exige un traitement global au niveau de l'application et du noyau tant du point de vue mémoire (allocation des mémoires tampons ou buffers) que de temps CPU (processeur) pour l'assemblage, le désassemblage et

traitement des mini messages. De plus la programmation de l'envoi et réception des mini messages n'est pas simple car elle nécessite la configuration d'un grand nombre de paramètres. Enfin ce style de programmation est événementiel, ou asynchrone, par opposition à une programmation séquentielle ou synchrone (avec exécution d'une suite d'instructions assurant l'envoi et/ou la réception séquentielle ou synchrone de données), ce qui impose au programmeur de positionner des drapeaux et contextes de façon à traiter correctement les mini messages entrants en fonction de l'état d'avancement de la procédure ou de la transaction.

En résumé l'envoi, la réception et le traitement de mini messages SMS sont longs et peu pratiques, surtout si l'on tient compte de la mobilité du portable GSM et donc des risques de perturbation des mini messages lors de la transaction.

Par ailleurs la spécification GSM 11. 14/classe e incorpore le protocole BIP (Bearer Independent Protocol)

permettant d'ouvrir la carte SIMToolkit ainsi modifiée (carte GSM/BIP) aux réseaux de données de type X25 ou Internet, le mobile en supportant la spécification GSM 11.14/classe e servant de relais vers le destinataire.

Ce protocole BIP présente un inconvénient lors de la lecture de données du réseau selon lequel le terminal retourne sa réponse sans résultat du réseau puis notifie la carte lors de la réception des données. Ce mode de fonctionnement dit asynchrone entraîne une difficulté d'implantation sur la carte, à partir du protocole BIP, de protocoles synchrones basés sur un mode séquentiel d'ouverture/utilisation/fermeture des connexions (le protocole TCP par exemple). De plus le protocole BIP ne

prévoit pas la possibilité d'établir une connexion à partir du réseau vers la carte.

L'invention a pour but de proposer un protocole de communication entre une carte de type pro-active ISO 7816-3/4 et son terminal d'accueil qui élimine ou réduit sensiblement les inconvénients présentés ci-dessus et notamment qui donne à la carte la capacité de dialoguer avec une infrastructure de réseau distant dans de bonnes conditions de fiabilité et de rapidité tout en présentant des conditions de programmation facilitées.

A cette fin l'invention propose un protocole de communication destiné entre autres à gérer les transferts de données entre une carte à puce pro-active conforme ou compatible ISO 7816-3/4 ou capable, éventuellement à l'aide d'une machine proxy, d'émuler le protocole ISO 7816-3/4 ou des protocoles supportant ce protocole ISO 7816-3/4, ci-après la carte initiatrice, et son terminal d'accueil, ledit protocole de communication comportant au moins les commandes pro-actives de carte ou de lecteur de carte correspondant aux opérations suivantes : Activation de lecteur de carte, Transfert (s) de données, Désactivation de lecteur de carte, et une procédure de Notification de carte de type Evénement sur lecteur de carte, ledit protocole de communication étant caractérisé en ce que lesdits transferts de données sont gérés par sessions de communication sur carte pro-active comportant au moins la séquence d'opérations suivante : Ouverture de session, l'ouverture étant locale à partir de la carte ou distante à partir du terminal, Transfert (s) de données synchrone (s) ou asynchrone (s), Fermeture de session, la fermeture étant locale à partir de la carte ou distante à partir du terminal, au moyen de commandes pro-actives étendues dérivées desdites commandes pro-actives de carte ou de lecteur de carte et

d'une procédure de Notification de carte étendue dérivée de ladite procédure de Notification de carte de type Evénement sur lecteur de carte.

Ainsi le protocole de communication selon l'invention est basé sur l'utilisation de sessions de communication entre la carte et son terminal d'accueil avec ouverture (et fermeture) bidirectionnelles des sessions tout en bénéficiant des acquis des commandes pro-actives d'origine de carte ou de lecteurs de carte pour obtenir au final des commandes pro-actives très homogènes. On obtient ainsi un protocole de communication nettement plus performant que le protocole SMS, avec notamment un niveau élevé des débits des données transférées, obtenu grâce au transfert par sessions, et beaucoup plus facile à mettre en oeuvre (notamment au niveau de la programmation) que le protocole BIP, ce dernier restant un protocole à ouverture et fermeture monodirectionnelles à partir de la carte seulement.

Avantageusement selon une première variante de l'invention, le protocole selon l'invention est utilisé dans une ou plusieurs sessions de communication sur carte pro-active localement distinctes pour des transferts de données carte à carte au travers d'une chaîne de sessions de communication assurant la connexion directe et permanente entre les deux cartes pendant la durée des sessions. Cette connexion carte à carte est importante dans le domaine des cartes à puce car elle permet une authentification réelle et sûre, ce qui est très recherché pour les transactions dans le cadre du commerce électronique. On notera que le protocole BIP ne prévoit pas de telle connexion carte à carte.

Plus particulièrement le protocole selon l'invention est utilisé pour le transfert de données au travers du

terminal d'accueil entre la carte initiatrice et au moins une carte locale connectée audit terminal par un lecteur de carte local réel ou virtuel ou au moins une carte réseau connectée à un réseau de données externe ou distant par un lecteur réseau réel ou virtuel. On notera que l'invention prévoit, à côté des lecteurs réels (les lecteurs physiques), des lecteurs virtuels définis par des applications logicielles qui par émulation appropriée agrandissent très considérablement le champ d'action de l'invention.

De plus le protocole selon l'invention n'est pas limité à la carte initiatrice et est également utilisé sur au moins une desdites cartes locales ou au moins une desdites cartes réseau, ce qui accélère, uniformise et facilite d'autant les dialogues entre cartes, qu'elles soient initiatrice, locale ou distante.

Avantageusement les transferts de données entre la carte initiatrice, les cartes locales et/ou les cartes réseau sont réalisés en tout ou partie sur une ou plusieurs interfaces au travers de canaux de communication alloués dynamiquement. Plus particulièrement une commande d'ouverture d'une session de communication sur carte proactive génère l'attribution locale entre la carte et le terminal d'un numéro de session et l'attribution d'un numéro de canal de communication. Ainsi l'ouverture d'une session de communication de carte pro-active réserve de façon exclusive le canal de communication correspondant à la session aussi longtemps que celle-ci ne sera pas fermée. On notera également parmi les avantages du protocole selon l'invention que ce protocole est capable au niveau de la carte de gérer plusieurs sessions simultanément et que de plus la lecture synchrone ou asynchrone est possible.

Selon une autre variante d'utilisation le protocole selon l'invention est utilisé de façon bidirectionnelle aux deux extrémités d'une connexion entre deux cartes proactives distantes, chaque carte étant connectée localement à son terminal correspondant par une session de communication sur carte pro-active, les deux terminaux étant connectés entre eux par au moins une session réseau et adaptés pour gérer les conversions de protocoles entre les sessions sur cartes pro-actives et la session réseau et les flux de données dans les canaux de communications correspondants. Ce schéma de connexion entre une carte et un réseau externe est particulièrement performant, notamment au niveau de la fiabilité des transferts de données.

Avantageusement l'adresse utilisée pour les lecteurs est constituée d'un numéro de téléphone, notamment pour les réseaux du type X25, ATM, RNIS ou analogue, d'une adresse IP (Internet Protocol) avec numéro de port implicite prédéfini, d'une adresse IP avec numéro de port TCP/IP ou un nom logique, définitif ou temporaire, composé d'un nom de machine, par exemple son adresse réseau, et d'un nom d'application logicielle, par exemple son AID (Application Identifier Discriminator).

On notera que le mode d'adressage logique temporaire facilite le contrôle direct de la connexion de bout en bout carte à carte, étant fait remarquer que l'adressage d'un lecteur est souvent remplacé grâce à l'adressage logique temporaire par un adressage direct de la carte insérée de façon temporaire dans ce lecteur.

Avantageusement et en variante optionnelle le protocole selon l'invention utilisant un nom logique avec un adressage réseau est caractérisé en ce que :

- à l'ouverture de session une première connexion est d'abord établie entre deux applications réseau, ladite première connexion ou connexion réseau étant suivie d'une connexion de type applicatif avec échange de messages sur la connexion réseau, et - à la fermeture de session, la fermeture de ladite connexion de type applicatif est réalisée dans un premier temps puis suivie de la fermeture de la connexion réseau.

L'utilisation de plusieurs niveaux de connexion, y compris des connexions virtuelles logicielles, facilite grandement la programmation avec l'utilisation d'un langage applicatif de haut niveau.

Selon encore plusieurs variantes du protocole de communication selon l'invention la carte initiatrice est connectée : I) soit en mode APDU strict avec transfert de données au format APDU sur session : la) avec un lecteur de carte associé localement au lecteur de la carte initiatrice, par exemple un mobile GSM bi-fentes avec carte initiatrice SIM et une carte classique de débit/crédit ; Ib) avec un lecteur de carte distant, associé à un réseau externe de données, la carte initiatrice accédant au réseau par des serveurs de réseaux, par exemple par une machine proxy locale à la carte initiatrice et une machine proxy locale au lecteur de carte distant ; ou le) une carte à puce virtuelle définie par une application informatique locale ou distante émulant le protocole ISO 7816-3/4 ou des protocoles supportant ce protocole ISO 7816-3/4 ; II) soit en mode binaire sur session avec transfert de données en format binaire : lisa) avec un lecteur de carte associé localement au lecteur de la carte initiatrice et supportant un

protocole supportant l'ouverture de session de communication sur carte pro-active ; IIb) avec un lecteur de carte distant associé à un réseau externe de données et supportant un protocole supportant l'ouverture de session, la carte initiatrice accédant à des serveurs de réseau assurant la gestion de la session carte initiatrice et de la session réseau distant ; ou IIc) une carte à puce virtuelle définie par une application informatique locale ou distante et gérant des sessions de type TCP ou X25.

Plus particulièrement le protocole de l'invention selon lequel ladite carte initiatrice est connectée, en mode APDU strict avec transfert de données au format APDU sur session, avec un lecteur de carte distant associé à un réseau externe de données, est caractérisé en ce que ladite carte initiatrice est connectée à un coffre-fort électronique de type SAM ou à une carte RMI (Remote Method Invocation de l'environnement Java) utilisant un protocole basé sur le protocole ISO 7816-3/4, la carte initiatrice accédant au réseau par des serveurs de réseaux, par exemple par une machine proxy locale à la carte initiatrice et une machine proxy locale au lecteur de carte distant.

Plus particulièrement encore le protocole de l'invention selon lequel la carte initiatrice est connectée, en mode binaire sur session avec transfert de données en format binaire, avec un lecteur de carte associé localement au lecteur de la carte initiatrice et supportant un protocole supportant l'ouverture de session de communication sur carte pro-active, caractérisé en ce que ladite carte initiatrice est connectée à un mobile GSM bi-fentes avec carte initiatrice SIM et une carte proactive supportant le protocole de l'invention défini ci-

avant ou le protocole GSM/BIP, et hébergeant un miniserveur Web comportant des données personnelles. Plus particulièrement encore le protocole de l'invention selon lequel la carte initiatrice est connectée, en mode binaire sur session avec transfert de données en format binaire, avec une carte à puce virtuelle définie par une application informatique locale ou distante et gérant des sessions de type TCP ou X25, caractérisé en ce que ladite carte initiatrice est connectée à des serveurs Web distants, des serveurs de bases de données ou un navigateur résidant sur un PC auquel est raccordé le lecteur de la carte initiatrice.

Ainsi le protocole selon l'invention peut être utilisé pour l'acheminement de données de type APDU entre la carte initiatrice et des terminaux supportant indifféremment le mode APDU ou le mode binaire pour permettre au niveau carte l'utilisation d'interfaces de programmation d'application, également dénommées API (Application Programming Interfaces), homogènes et de haut niveau.

Selon un mode de réalisation préférentiel de l'invention, le protocole selon l'invention est utilisé avec une carte initiatrice de type carte SIM pro-active et un terminal d'accueil compatible GSM, le protocole comportant une extension de commandes pro-actives de lecteur de carte local de la spécification GSM 11. 14/classe a de façon à utiliser des commandes pro-actives étendues uniformes pour gérer les transferts de données entre la carte SIM et indifféremment un lecteur local ou un lecteur réseau externe.

Cette caractéristique, par l'utilisation maximale du préexistant, a pour avantage d'une part de réduire le

nombre des modifications nécessaires de la spécification GSM 11. 14/classe a et d'autre part d'offrir une grande souplesse d'utilisation pour le développeur-programmeur au niveau de la compatibilité avec la version GSM 11.14/classe a d'origine.

Toujours selon le mode de réalisation préférentiel du protocole de l'invention, les commandes de lecteur de carte de la spécification GSM 11.14/classe a faisant l'objet d'une extension sont les suivantes : - POWER ON CARD/ACTIVATION LECTEUR DE CARTE utilisée pour l'Ouverture locale de session - PERFORM CARD APDU/EXECUTION COMMANDE APDU PAR LE LECTEUR CARTE utilisée pour les Transferts de données synchrones - POWER OFF CARD/DESACTIVATION LECTEUR DE CARTE utilisée pour la fermeture locale de session et de façon optionnelle la commande : - GET READER STATUS/RECHERCHE STATUT LECTEUR DE CARTE.

Ainsi les quatre commandes lecteur de carte de la spécification GSM 11.14/classe a (au départ utilisées pour un lecteur local sans session de communication), sont après extension d'une part utilisées en session de communication pour un lecteur local, et d'autre part utilisées pour gérer une session de communication avec un lecteur distant, en l'espèce un lecteur réseau, en particulier la commande primitive PERFORM CARD APDU est utilisée pour l'envoi synchrone de données sous forme d'APDU.

De façon particulièrement avantageuse, le protocole selon l'invention présente la capacité d'insertion dynamique des lecteurs réseau et de réalisation de sessions de communication sur carte pro-active à partir de cartes distantes et/ou de cartes locales, avec possibilité d'ouverture et de fermeture de session distantes à partir

du terminal d'accueil, par extension de la procédure de Notification de carte EVENT DOWNLOAD-CARD READER STATUS /NOTIFICATION D'EVENEMENT-STATUT LECTEUR DE CARTE de la spécification GSM 11.14/classe a. Ainsi une connexion peut être initiée de façon simple de manière événementielle asynchrone à partir du réseau, donnant au protocole selon l'invention un véritable caractère bidirectionnel (ce que le protocole BIP ne prévoit pas).

Ainsi le protocole selon l'invention peut également être utilisé pour l'envoi asynchrone de données vers une application en état de session ouverte ou l'extraction asynchrone de données à partir d'une application en état de session ouverte.

Selon une première variante optionnelle du mode de réalisation préférentiel du protocole selon l'invention, les commandes étendues sont optimisées pour combiner en une seule commande une commande d'opération de transfert de données avec une commande de fermeture de session.

Cette caractéristique facilite la programmation et procure un gain de temps appréciable pour l'exécution des transactions et permet d'optimiser la manipulation du flux de données.

Selon une seconde variante optionnelle du mode de réalisation préférentiel du protocole selon l'invention, la commande étendue PERFORM CARD ADPU pour la lecture à partir de la carte SIM pro-active, est optimisée pour permettre lors de la lecture d'une chaîne d'octets à accès séquentiel, ci-après flux de données, de réaliser au moins une des opérations : - de glissement du pointeur de lecture du flux de données par intégration d'une commande complémentaire SKIP-DATA /GLISSERDONNEES,

- d'élimination de tous les caractères du flux de données en attente de lecture par intégration d'une commande complémentaire FLUSHDATA/VIDERDONNEES et - de recherche dans les caractères du flux de données en attente de lecture par intégration d'une commande complémentaire FINDDATA/TROUVERDONNEES.

Cette caractéristique permet d'optimiser la manipulation d'un flux de données et facilite pour la carte SIM proactive l'accès à des bases de données de tailles importantes (réseau Internet).

Tout aussi avantageusement pour augmenter les débits de transfert sur le réseau externe le terminal d'accueil de la carte initiatrice supporte la compatibilité GSM/GPRS permettant l'exécution de sessions de communication GPRS (General Packet Radio Service) et/ou supporte la compatibilité UMTS (Universal Mobile Telecommunication System) permettant l'exécution de sessions de communication UMTS.

D'autres buts, avantages et caractéristiques de l'invention apparaîtront à la lecture de la description qui va suivre du mode de réalisation préférentiel du protocole de communication selon l'invention donné à titre d'exemple non limitatif en référence aux dessins ci-annexés dans lesquels : la figure 1 montre un schéma de communication illustrant la mise en oeuvre du protocole de communication selon l'invention entre la carte pro-active et son terminal d'accueil ; la figure 2 montre un schéma de communication illustrant la mise en oeuvre du protocole de communication associé à la figure 1 dans une structure locale ; et

la figure 3 montre un schéma de communication illustrant la mise en oeuvre du protocole de communication associé la figure 1 dans une structure de réseau externe.

Il est à noter au préalable qu'il pourra être avantageux lors de la lecture du présent exposé de se reporter aux normes ISO concernant les cartes à puce, notamment les normes ISO 7816-3/4 et aux diverses publications de l'ETSI, notamment celles concernant les spécifications GSM dont la spécification GSM 11.14 V8.2. 0 (2000-04).

D'une façon générale le protocole de communication selon l'invention est mis en oeuvre dans un système télématique liant télécommunications et informatique (matérielle et logicielle) dont la plupart des éléments, pour certains rapidement présentés ci-après, sont connus et ne seront décrits en détail.

Comme tout mode opératoire, le protocole selon l'invention comporte un certain nombre de mécanismes logiques et de règles, souvent traduits sous forme de logiciels, destinés à la mise en oeuvre globale et unitaire des éléments physiques du système, y compris la gestion des interfaces entre ces divers éléments physiques. En l'espèce le protocole selon l'invention a pour objet la communication et les échanges de données entre une carte à puce SIM pro-active d'abord avec son terminal d'accueil puis avec un réseau de données local ou distant par exemple le réseau Internet.

Selon le mode de réalisation préférentiel du protocole de communication de l'invention maintenant décrit à titre d'exemple non limitatif, les échanges de données entre une carte à puce pro-active CPA 10 conforme ou compatible ISO 7816-3/4, et son terminal d'accueil TAC 12 au travers

d'un lecteur de carte LEC 11 sont réalisés selon le schéma de communication illustré à la figure 1.

Si l'on considère la figure 1, les différents équipements, carte CFA 10, lecteur LEC 11 et terminal d'accueil TAC 12 sont illustrés selon la représentation graphique de couches logicielles, les parallèles en pointillés définissant un même niveau de protocole pour les divers équipements, c'est à dire que chaque composant physique ou chaque application logicielle situé à la même latitude utilise le même dialecte protocolaire ; par exemple le même langage applicatif est utilisé pour le dialogue entre l'application APPLI (CPA) et l'application APPLI (TAC) illustré par la double flèche 54. De plus une série de doubles flèches 51,52 et 53 illustre les liens entre les trois équipements et le réseau externe.

Concrètement le lien 51 entre la carte 10 et le lecteur 11 schématise l'interface par contacts entre ces deux équipements, le lien 52 entre le lecteur 11 et le terminal 12, en l'espèce un ordinateur compatible PC, schématise un câble série (RS232 ou USE) et le lien 53 entre le terminal 12 et le réseau externe (non représenté) schématise un câble réseau.

La carte CFA 10 est représentée de façon simplifiée avec quatre couches logicielles concernées par l'invention allant du plus bas niveau au plus haut : - la couche du protocole ISO (ISO 7816-3/4) - la couche du protocole des commandes pro-actives PCPA y compris la procédure de Notification carte d'Evénement sur lecteur de carte (par exemple en environnement GSM, le protocole selon la spécification GSM 11.14/classe a) - la couche du protocole de communication selon l'invention PCINV (protocole avec sessions de communication sur carte pro-active)

- la couche application carte APPLI (CPA), par exemple l'affichage de données sur l'écran du terminal.

Le lecteur LEC Il est représenté de façon simplifiée avec deux couches logicielles concernées par l'invention, allant du plus bas niveau au plus haut : - la couche du protocole ISO (ISO 7816-3/4) - en parallèle à la couche ISO 7816-3/4 une pile de deux couches, une couche RS232, USB, etc... surmontée par exemple d'une couche PC/SC (protocole standard défini par la société MICROSOFT pour l'interface entre les terminaux PC et les lecteurs de cartes à puce) ou d'une couche d'un protocole analogue.

- une couche d'adaptation de protocole AP (LEC) entre la couche ISO et la couche PC/SC.

Le terminal TAC 12 est représenté de façon simplifiée avec cinq couches logicielles concernées par l'invention allant du plus bas niveau au plus haut : - une pile de 4 couches composée de la couche RS232, USB ou analogue, la couche PC/SC, la couche PCPA et la couche PCINV, - en parallèle à la pile 4 couches, une couche réseau TCP/IP, X25 ou analogue, - surmontant la pile 4 couches, une couche d'application terminal APPLI (TAC) d'une part et une couche d'adaptation de protocole AP (TAC) entre la couche PCINV et la couche TCP/IP d'autre part.

On notera que : i) pour certaines cartes CPA (non GSM) il est possible que certains composants PC/SC se trouvent dans la carte. Toutefois le schéma de la figure 1 se limite au regard de PC/SC au dialogue entre le terminal PC 12 et le lecteur de carte 11.

ii) en environnement GSM le protocole PC/SC n'existe pas, les applications terminal APPLI (TAC) dialoguant directement avec le lecteur ; de même le lien 52 n'existe pas.

La figure 2 montre un schéma de communication illustrant la mise en oeuvre du protocole de communication selon l'invention dans une structure locale.

Tel que représenté sur la figure 2 le terminal local TLOC 21 est équipé de deux lecteurs de carte 22 et 23 pour lesquels les couches de protocole de terminal pour accéder à ces lecteurs ne sont pas représentées. Le terminal 21, par son lecteur 22 disposant des couches ISO 7816-3/4, PCPA et PCINV (protocole de communication selon l'invention), dialogue avec la carte pro-active 20 dite initiatrice par définition et disposant des mêmes couches ISO 7816-3/4, PCPA et PCINV par l'intermédiaire du lien 61 (supportant en l'espèce une session de communication selon l'invention). De même le terminal 21 par son lecteur 23 disposant des couches ISO 7816-3/4, PCPA et PCINV dialogue avec la carte pro-active CPA-2 24 disposant des mêmes couches ISO 7816-3/4, PCPA et PCINV par l'intermédiaire du lien 62 (supportant en l'espèce une autre session de communication selon l'invention distincte de la session supportée par le lien 61). Le terminal 21 comporte également les protocoles et procédures (représentés par les doubles flèches 223 et 225) adaptées pour gérer et réaliser la résolution des adresses, l'établissement des connexions, les transferts et les conversions de protocoles entre le lecteur 22 de la carte initiatrice 20 et une application terminal 220 APPLI (TLOC) d'une part (double flèche 223) et entre les deux lecteurs 22 et 23 d'autre part (double flèche 225).

Dans la configuration représentée le terminal 21 dispose de l'application APPLI (TLOC) 220, par exemple un serveur Web utilisant sur le lien 61 une session de communication de la carte pro-active CFA 20 pour afficher des données sur le terminal 21 ou pour gérer l'interface utilisateur de ce terminal.

De plus le lien 62 est utilisé pour le dialogue entre les deux cartes pro-actives CFA 20 et CPA-2 24, par exemple entre les applications APPLI (CPA) 200 et APPLI (CPA-2) 240, les liens 61 et 62 supportant chacun une session de communication selon l'invention, ces sessions étant distinctes l'une de l'autre.

Enfin le terminal 21 après reconfiguration du lecteur 23 peut aussi acheminer des données vers l'application 250 de la carte CISO 25 seulement conforme ou compatible ISO 7816-3/4 par une session établie sur le lien 61 entre la carte pro-active CFA 20 et le terminal TLOC 21. Dans ce cas circuleront sur le lien 61 des données de type APDU sur session et sur le lien 63 des données de type APDU strict, ce dernier lien ne supportant que des données dans le mode APDU strict (sans session).

La figure 3 montre un schéma de communication illustrant la mise en oeuvre du protocole de communication selon l'invention dans une structure de réseau externe.

Tel que représenté sur la figure 3 le terminal local TLOC 31 est équipé d'un lecteur de carte 32 et d'une interface réseau 33 pour lesquels les couches de protocole de terminal pour accéder à ce lecteur ou à cette interface réseau ne sont pas représentées. Le terminal local 31 par son lecteur 32 disposant des couches ISO 7816-3/4, PCPA et PCINV (protocole de communication selon l'invention) dialogue avec la carte pro-active CFA 30 dite initiatrice

par définition et disposant des mêmes couches ISO 7816- 3/4, PCPA et PCINV par l'intermédiaire du lien 71 (supportant en l'espèce une ou plusieurs sessions de communication selon l'invention). De même le terminal 31, par son interface réseau 33 disposant de la pile réseau TCP/X25 dialogue au travers de la pile réseau TCP/X25 de l'interface réseau 35 avec un terminal distant TDIS 34 par l'intermédiaire du lien 72 (supportant en l'espèce une session de communication réseau).

Le terminal distant 34, par son lecteur de carte 36 disposant des couches ISO 7816-3/4, PCPA et PCINV (protocole de communication selon l'invention), dialogue avec la carte réseau pro-active CPA-3 37 disposant des mêmes couches ISO 7816-3/4, PCPA et PCINV par l'intermédiaire du lien 73 (supportant en l'espèce une ou plusieurs sessions de communication selon l'invention).

Le terminal local 31 et le terminal distant 34 comportent chacun les protocoles et procédures (représentés par les doubles flèches 310 et 320) adaptées pour gérer et réaliser la résolution des adresses, l'établissement des connexions, les transferts et les conversions de protocoles entre chaque lecteur 32,36 de carte proactive et la pile réseau TCP/X25 correspondante des interfaces réseau 33,35. Dans cette configuration les terminaux 31,34 disposent chacun d'un équipement ou d'une application logicielle faisant fonction de proxy 310,320 qui fait la conversion de protocole entre le protocole de l'invention PCINV et les protocoles réseau.

Ainsi les deux cartes pro-actives 30,37 [ou les deux applications carte APPLI (CPA) 300 et APPLI (CPA-3) 340] peuvent se connecter et dialoguer directement entre elles, les liens 71 et 73 supportant chacun une session

selon l'invention et le lien 72 supportant une session réseau. Dans une autre variante de structure de réseau non représentée dans laquelle la carte pro-active 37 est remplacée par une carte classique seulement conforme ou compatible ISO 7816-3/4, le terminal distant comporte un équipement proxy distant pour effectuer la conversion entre protocole réseau et le protocole APDU, permettant ainsi une connexion en session de la carte locale proactive vers la carte classique par l'intermédiaire de deux sessions distinctes (une session selon l'invention entre la carte pro-active et le terminal local et une session réseau entre les deux terminaux) suivie d'un transfert de données en mode APDU entre le terminal distant et la carte classique.

Bien entendu il est possible dans le cadre de l'invention d'utiliser des terminaux mixtes (non représentés) combinant les deux types de structures locale et distante, chaque terminal possédant au moins deux lecteurs de carte dont au moins un est équipé de la couche du protocole selon l'invention PCINV et au moins une carte réseau permettant le dialogue entre toutes les cartes à puce sur lecteur associées localement ou à distance. De même les lecteurs de carte physiques locaux ou distants susceptibles de dialoguer entre eux ou avec la carte initiatrice peuvent être remplacés par des lecteurs virtuels pour autant que ces lecteurs supportent la compatibilité ISO 7816-3/4 ou sont capables d'émuler ou de supporter le protocole ISO 7816-3/4 ainsi qu'il a été présenté ci-avant dans le préambule du présent exposé.

Après avoir présenté le protocole de communication de l'invention dans son concept le plus large (en

particulier non nécessairement limité à l'environnement GSM) et notamment plusieurs modes de mises en oeuvre et/ou d'utilisation de ce protocole en structure locale et en réseau externe, il convient d'exposer l'implémentation du protocole selon l'invention au niveau de l'extension des commandes pro-actives de carte ou de lecteur de carte d'un protocole de type PCPA. A titre d'exemple non limitatif on décrira ci-après un mode préférentiel d'implémentation selon l'invention dans l'environnement GSM, les cartes pro-actives CFA (capables d'initier des actions de la carte vers le terminal) étant choisies du type SIM pro-active avec pour protocole de commandes pro-actives PCPA le protocole selon la spécification GSM 11. 14/classe a et pour terminal d'accueil un terminal compatible GSM.

D'une façon générale, les cartes à microprocesseur SIM (Subscriber Identity Module) sont définies par les spécifications GSM tout en étant compatibles avec les normes ISO 7816-3/4. Ces cartes comportent une zone de personnalisation, en l'espèce d'identité d'un abonné, l'IMSI, (International Mobile Subscriber Identity). Les cartes SIM trouvent leur application la plus courante dans les terminaux mobiles de radiotéléphonie compatible GSM.

En l'espèce la carte SIM utilisée pour la présente invention est du type pro-active (également appelée de

type SIMToolkit) et compatible avec la spécification GSM 11. 14./classe a. Toutefois pour la suite de l'exposé, une carte SIM pro-active sera sauf mention particulière simplement appelée carte SIM.

Le protocole de communication selon l'invention, conforme aux normes ISO 7816-3/4 ou compatible avec elles, utilise de ce fait des commandes logicielles APDU au départ du

terminal GSM, ou terminal ou mobile ME (Mobile Equipment), et qui selon ces normes commencent par un en- tête de 5 octets définis ci après : octet 1 (CLA) = classe de l'application octet 2 (INS) = instruction octet 3 et 4 (Pi et P2) = paramètres de l'instruction octet 5 (P3) = longueur commande ou longueur réponse.

Cet en-tête est éventuellement suivi par un champ de données présent dans la commande.

De plus la réponse de la carte SIM à une commande APDU comporte un épilogue de deux octets SW1 et Sw2 (Status Word) éventuellement précédé d'un champ de données. Le

code de SW1 est compris en codage hexadécimal (hex) entre 90 (acquittement positif) et 9F ou entre 60 et 6F en cas de problème indépendant de l'application. Le code SW2 sert à expliciter la cause du refus d'exécution de la commande.

Le protocole de communication selon la variante d'implémentation préférentielle de l'invention intègre la spécification GSM 11.14 selon laquelle l'émission d'une commande pro-active à partir de la carte SIM se fait selon le protocole spécifique suivant : - émission par la carte d'une réponse en retour d'une commande APDU du terminal, la réponse comportant les deux octets de statut SW1/SW2 avec SW1 (hex) =91 pour indiquer une commande pro-active en attente et SW2 (hex) =xx où xx est la longueur de la commande pro-active. Le terminal ME émet alors une commande APDU FETCH vers la carte SIM dont la réponse en retour vers le terminal contiendra la commande pro-active en attente. La commande pro-active est exécutée par le terminal ME qui émet ensuite une réponse appelée TERMINAL RESPONSE pour rendre compte du résultat de l'exécution de la commande pro-active ou de son inexécution.

Pour la suite de la présentation du protocole selon l'invention les opérations d'émission du statut = 91xx et de la commande FETCH à partir du terminal GSM seront, sauf indication particulière, considérées comme implicites (ou implicitement remplacées par des opérations produisant les mêmes effets).

Par ailleurs la spécification GSM 11. 14/classe a conceptualise la notion de lecteur de carte (card reader) par : i) les quatre commandes carte : POWER ON CARD, PERFORM CARD APDU, POWER OFF CARD, GET READER STATUS, et ii) une commande terminal ENVELOPE (...) associée à la procédure de Notification à la carte d'Evénement sur

lecteur de carte : ENVELOPE (EVENT DOWNLOAD-card reader status) dans laquelle la structure EVENT = card reader status est encapsulée dans la commande EVENT DOWNLOAD (Notification d'événement) elle-même encapsulée dans la commande terminal plus générale ENVELOPE (...).

Ces commandes permettent respectivement à une application carte : - de mettre sous tension un lecteur carte résidant dans le mobile, - d'envoyer des données sous forme d'APDU, - de mettre ce lecteur hors-tension, - de vérifier le statut du lecteur, et - d'être notifiée d'événements lecteur carte.

Selon le protocole de l'invention on utilise les 4 commandes carte et la notification de carte Evénement du lecteur de carte (card reader) pour gérer une session de communication vers un lecteur de carte distant ou local : ouverture de la session, transfert de données sur la

session et contrôle de la session, fermeture de la session et notification de changement de session. On étend ainsi la localisation des lecteurs du mobile GSM vers Internet ou les autres réseaux tout en conservant une compatibilité avec les applications existantes. La carte SIM pro-active utilisera donc les mêmes commandes pour adresser un lecteur carte situé sur le réseau, par exemple un coffre fort électronique SAM, qu'un lecteur local comportant un porte-monnaie électronique.

Pour faciliter la compréhension de la suite de l'exposé on rappellera brièvement quelques caractéristiques des commandes de lecteur carte (card reader) de la spécification GSM 11. 14/classe a. Comme toutes les commandes pro-actives les 4 commandes de lecteur carte (card reader) incluent un discriminant identités des équipements (Device identities) qui spécifie l'équipement émetteur et l'équipement destinataire.

Dans le sens e Carte SIM vers Mobile ME le discriminant Device identities est positionné pour les 4 commandes de lecteur carte avec : - Identité Emetteur = 81 (hex) = Carte SIM - Identité Destinataire = 10 (hex) à 17 (hex) = Lecteur carte additionnel x (0 à 7) (additionnal card reader x).

Par exemple une commande POWER ON CARD (non encore étendue selon l'invention) pourra s'écrire selon la spécification GSM 11. 14/classe a : POWER ON CARD (hex) = DO 09 01 03 01 31 00 02 02 81 11 90 00 dans laquelle - DO 09 01 03 01 31 00 forme l'en-tête de la commande pro-active avec à la fin un octet d'attribut de commande

(Command Qualifier) CQ = 00 réservé pour usage futur (rfu). - 02 02 81 11 est un champ de donnée comportant en épilogue les identités de l'émetteur 81 (la carte SIM) et le destinataire 11 (le lecteur résidant 11), et - 90 00 correspond à SW1/SW2.

Dans le sens Mobile ME vers Carte SIM la réception de l'Evénement card reader status permet à l'application

SIMToolkit d'être notifiée d'une modification de l'état du lecteur, par exemple'carte insérée','carte retirée'.

Cet événement fait partie de la commande terminal ENVELOPE (EVENT DOWNLOAD-card reader status) qui inclut un discriminant Device identities positionné avec : - Identité Emetteur = 82 (hex) = Mobile ME - Identité Destinataire = 81 (hex) = Carte SIM et un champ card reader status (codé sur un octet) = nO lecteur (3 bits) +'drapeaux' (flags) d'état de statut.

Enfin la réponse TERMINAL RESPONSE aux commandes de lecteur carte du type PERFORM CARD APDU contient le discriminant Device Identities positionné avec - Identité Emetteur = 82 (hex) = Mobile ME.

- Identité Destinataire = 81 (hex) = Carte SIM PRESENTATION DES COMMANDES PRO-ACTIVES GSM 11.14/ CLASSE A (COMMANDES Card Reader) ETENDUES UTILISEES DANS LE PROTOCOLE SELON L'INVENTION I MODE SYNCHRONE Selon l'invention la correspondance entre les commandes card reader et les opérations de gestion d'une session de communication commence par l'ouverture d'une session par la carte SIM pro-active avec établissement de la

connexion et l'introduction d'un numéro de session à l'aide de la commande POWER ON CARD étendue.

OUVERTURE D'UNE SESSION PAR LA CARTE SIM (OUVERTURE LOCALE)/ETABLISSEMENT D'UNE CONNEXION (POWER ON CARD) Plus particulièrement selon l'invention la commande POWER ON CARD étendue comporte deux champs complémentaires constitués chacun d'une chaîne de caractères au format e machine~1 : application~2 , (format non limitatif). En pratique chaque chaîne définit un champ de type TLV (Tag/Length/Value) indiquant l'identité Address de l'équipement Emetteur ou de l'équipement Destinataire.

Selon un premier exemple avec un lecteur local destinataire la commande POWER ON CARD étendue pourra s'écrire (hex) [après mise en caractères gras des champs

ajoutés ou modifiés dans leurs interprétations] : D0090103013100020281110606FF00000000010606FF00000001039000 dans laquelle l'Identité Destinataire = 11 (lecteur local) et le NO de canal = 11-10 = 1 - le TLV 0606FF0000000001 = Address-Emetteur (adresse AID) - le TLV 0606FF0000000103 = Address-Destinataire (adresse AID), et l'attribut de commande CQ = 00 (mode APDU).

La réponse TERMINAL RESPONSE s'écrira : A01400001701030131000202828103010021092802063BF01100FF00 où l'identité Emetteur = 82 = Mobile.

On notera que l'Address-Destinataire doit toujours être une adresse application AID ou à défaut une adresse machine par exemple : www. bull. net : 8070 (où 8070 est le

code du Serveur Web et 70 le code du numéro de port TCP) soit en codage (hex) : 7777772E62756C6C2E6E65743A38303730 Selon un second exemple avec un lecteur réseau destinataire (la machine www. bull. net : 8070) la commande POWER ON CARD étendue pourra s'écrire (hex) [après mise en caractères gras des champs ajoutés ou modifiés dans leurs interprétations] : D0230103013102020281210606FF0606FF00000000010612FF7777772 E62756C6C2E6E65743A383037309000 avec : - l'attribut de commande CQ = 02 signifie que le dialogue s'effectue en mode binaire.

- l'Identité Destinataire = 21 (lecteur réseau) et le NO de canal (hex) = 21-20 = 01 - le TLV 0606FF0000000001 = Address-Emetteur (adresse AID) - le TLV 0612FF7777772E62756C6C2E6E65743A38303730 Address-Destinataire avec une adresse machine.

La réponse TERMINAL RESPONSE s'écrira : A01400001701030131000202838103010021092802063BF01100FF00 où l'identité Emetteur = 83 = Réseau (Network) au lieu de 82 = Mobile.

Par convention le numéro du lecteur de carte reste le numéro des lecteurs du mobile pour les valeurs (hex) 10 à 17 et devient égal à (hex) 20 à 2F pour les lecteurs distants, ce qui garantit la compatibilité avec la spécification GSM 11. 14/classe a existante.

A titre d'exemple non limitatif, on donne par convention et par commodité le numéro d'Identité Destinataire comme numéro de session de communication. Ainsi la présence du motif binaire 0010 xxxx qui correspond à la plage (hex)

20 à 2F permet au mobile i) d'interpréter la commande comme une commande de gestion de session avec un lecteur réseau par opposition au motif binaire 0001 Oxxx qui identifie les numéros logiques (0 à 7) des lecteurs cartes locaux résidants dans le mobile et ii) d'aller lire le nom du lecteur réseau Identité Destinataire qui sera un champ supplémentaire dans la structure Device identities.

Ainsi le numéro de session défini par la commande POWER ON CARD sera utilisé par les autres commandes de la séquence PERFORM CARD APDU, POWER OFF CARD et GET READER STATUS lors du déroulement séquentiel ou synchrone de la session.

Le mobile se sert de ce numéro de session pour : - créer en réception de la commande POWER ON CARD un tunnel entre le mobile et le lecteur réseau ou le site rattaché au lecteur carte, utilisant ainsi la possibilité d'envoyer des APDU par un tunnel GPRS, - fermer ce tunnel en fonction des événements réseaux ou de l'ordre carte POWER OFF CARD, - gérer le flot de données en provenance de la carte SIM et du tunnel (par la commande PERFORM CARD APDU), - notifier à la carte SIM des changements d'état de la connexion par réception de l'événement'card reader status'ou par la commande carte GET READER STATUS.

La validité du numéro de session expire à la fin de la session par la commande POWER OFF CARD du lecteur distant, une réinitialisation de la carte SIM, ou un problème de liaison dans la connexion.

On notera que plusieurs sessions peuvent être gérées simultanément au niveau de la carte SIM et que la lecture synchrone/asynchrone sur plusieurs canaux est possible.

ECRITURE SYNCHRONE DE DONNEES PAR LA CARTE SIM (PERFORM CARD APDU) Selon l'invention la commande PERFORM CARD APDU étendue est complétée par : - un attribut de commande (Command Qualifier) CQ (hex) = 02 (ou 04) où CQ = 02 = PUTDATA = transfert de n octets de la carte SIM vers le mobile, les données échangées étant du type APDU ou binaires sur APDU ; et où CQ = 04 = PUTDATAEND transfert de n octets de la carte SIM vers le mobile avec la fin du transfert ; - une Identité Destinataire = 21 - un objet données TLV = CAPDU contenant les données à transférer [en l'espèce AAAA = (hex) 41414141 de longueur quatre octets L = 04].

La commande PERFORM CARD DATA (ECRITURE) s'écrit :

DOOF010301300202028121220441414141 La réponse TERMINAL RESPONSE contiendra un TLV = RAPDU contenant les données à transférer en réponse, en l'espèce (hex) 0000 et s'écrit : A01400001001030130020202838103010023020000 où l'Identité Emetteur = 83 = Réseau (Network) LECTURE SYNCHRONE DE DONNEES PAR LA CARTE SIM (PERFORM CARD APDU) Pour cette opération de lecture par la carte SIM la commande PERFORM CARD APDU étendue est complétée selon l'invention par : - un attribut de commande Command Qualifier CQ (hex) = 01

où CQ = 01 = GETDATA = transfert de n octets du Mobile vers la carte SIM - une Identité Destinataire (hex) = 21 donnant le no de canal = 21-20 = 01 - un objet données TLV = CAPDU contenant des valeurs nulles sur deux octets [en l'espèce (hex) OOOO avec L = 02].

La commande PERFORM CARD DATA (LECTURE) s'écrit : DOOD010301300102028121220200009000 La réponse TERMINAL RESPONSE contiendra un objet TLV =

RAPDU contenant les données à transférer en réponse, en l'espèce (hex) 414243 et s'écrira : A0140000FA0103013002020283810301002303414243 où l'Identité Emetteur = 83 = Réseau (Network) et où l'attribut de commande Command Qualifier CQ = 02 (ou 04) avec CQ = 02 = lecture incomplète, autres données disponibles sur le Mobile CQ = 04 = lecture complète, plus de données disponibles.

FERMETURE D'UNE SESSION PAR LA CARTE SIM (FERMETURE LOCALE) /FIN DE CONNEXION (POWER OFF CARD) Pour cette opération de fermeture par la carte SIM la commande POWER OFF CARD étendue est complétée selon l'invention par : - une Identité Destinataire (hex) = 21 donnant le no de canal = 21-20 = 01 La commande s'écrit alors : D0090103013200020281219000

II MODE ASYNCHRONE Le mode asynchrone est caractérisé par la venue au coup par coup de Notifications à la carte SIM pro-active de l'Evénement card reader status par l'intermédiaire de la commande terminal ENVELOPE, étant fait remarquer que le contenu de l'événement card reader status est modifié selon le type d'événement lecteur à prendre en considération par la carte SIM (ouverture de session, transfert de données, fermeture de session).

OUVERTURE D'UNE SESSION PAR LE RESEAU OU PAR UN LECTEUR LOCAL A PARTIR DU MOBILE (OUVERTURE DISTANTE) /ENVELOPE (EVENT DOWNLOAD-card reader status) Une caractéristique très intéressante du protocole selon l'invention réside dans la possibilité d'avertir la carte SIM de l'ouverture d'une session par le réseau ou par un lecteur local. On est ainsi en présence d'une requête Serveur (ouverture distante) par opposition à une requête Client (ouverture locale où la carte SIM prend l'initiative de l'ouverture de la session tel que présenté ci-avant).

La réception de l'événement GSM 11. 14 card reader status par la carte SIM grâce à la commande terminal ENVELOPPE (EVENT DOWNLOAD-card reader status) permet à l'application SIMToolkit d'être notifiée d'une modification de l'état du lecteur (par exemple'carte insérée'/'carte

retirée'). L'application SIMToolkit peut alors dérouler une procédure correspondant à une demande de connexion ou à une fin de connexion. Une demande de connexion peut correspondre à une requête Serveur, l'application SIMToolkit étant configurée dans ce cas en Serveur par exemple en Serveur TCP/IP ou HTTP si la pile logicielle adéquate est présente au dessus des quatre commandes

lecteur carte de l'API GSM 11. 14/classe a. Les détails de la notification au niveau du mobile d'une demande de connexion réseau doit faire l'objet d'un protocole spécifique d'échange de données GPRS ou autre (IP, X25, etc..).

Dans la pratique la gestion du statut du lecteur local résidant dans le mobile ou du lecteur réseau peut se faire tout en gardant la compatibilité réciproque à l'aide d'un champ Device identities de la structure TERMINAL RESPONSE qui contient l'identité de l'Emetteur (Source Device Identity) avec : (hex) 82 = Mobile pour les lecteurs locaux résidant dans le Mobile (hex) 83 = Réseau (Network) pour les connexions réseau Il est à noter que d'une façon distincte, la demande de statut par la carte SIM pro-active par la commande GET READER STATUS peut se faire en utilisant le numéro de session (hex) 20 à 2F, la présence du motif binaire 0010 xxxx permet au mobile d'interpréter la commande comme une demande des statuts des sessions en cours par opposition au motif binaire 0001 lxxx qui identifie les numéros logiques (0 à 7) des lecteurs carte résidant dans le mobile. Le mobile envoie alors à la carte SIM la concaténation des statuts de tous les lecteurs carte réseau soit n fois une structure de 3 octets TLV (Tag/Length/Status).

Selon l'invention la structure EVENT DOWNLOAD-card reader status est étendue par l'ajout en fin de structure d'un champ card reader status (hex) = 81 par exemple et de deux objets TLV donnant l'Address-Emetteur = 0606FF0000000001 et l'Address-Destinataire= 0612FF- 7777772E62756C6C2E6E65743A38303730.

La structure EVENT DOWNLOAD-Card reader status pourra alors s'écrire : AOC4000028D626190106020283812001810606FF00000000010612FF 7777772E62756C6C2E6E65743A38303730 où l'octet du card reader status = 81 = ssss iiii où ssss

= statut et iiii = canal id = (hex) 1 = 1 avec - statut (hex) = 8 = SESSIONOPEN (ouverture session) et 8x = requête du Mobile pour l'ouverture d'une session sur le canal x, - statut (hex) = 0 = SESSIONCLOSE (fermeture session) et Ox = requête du Mobile pour la fermeture d'une session sur le canal x, - statut (hex) = C = SESSION~DATA (transfert données) et Cx = requête du Mobile pour le transfert de données sur le canal x, Dans le cas présent Statut = 81 correspond à une ouverture de session sur le canal 1 avec en ce qui concerne l'identification de l'Emetteur : (hex) 82 = Mobile pour les lecteurs locaux résidant dans le Mobile

(hex) 83 = Réseau (Network) pour les connexions réseau (cas présent).

LECTURE ASYNCHRONE DE DONNEES PAR LA CARTE SIM/ENVELOPE (EVENT DOWNLOAD-card reader status) Cette opération de lecture asynchrone par la carte SIM est également réalisée par l'intermédiaire de la commande terminal ENVELOPPE (EVENT DOWNLOAD-card reader status).

Selon l'invention la structure EVENT DOWNLOAD-card reader status est étendue par l'ajout en fin de structure :

i) d'un champ card reader status (hex) = Cl par exemple, avec statut (hex) = C = SESSIONDATA (transfert données) et Cx = requête du Mobile pour le transfert de données sur le canal x et statut = Cl correspondant à l'arrivée de données nouvelles sur le canal 1 ; ii) et d'un objet TLV de type R-APDU qui contient le données A1A2A3A4A5 à transférer à la carte, par exemple TLV (R-APDU) = 2305A1A2A3A4A5.

La structure EVENT DOWNLOAD-card reader status pourra s'écrire :

AOC2000013D611190106020283812001C12305A1A2A3A4A5 avec en ce qui concerne l'identification de l'Emetteur : (hex) 82 = Mobile pour les lecteurs locaux résidant dans le Mobile (hex) 83 = Réseau (Network) pour les connexions réseau (cas présent).

FERMETURE D'UNE SESSION PAR LE RESEAU OU PAR UN LECTEUR LOCAL A PARTIR DU MOBILE (FERMETURE DISTANTE)/ENVELOPE (EVENT DOWNLOAD-card reader status) D'une façon parallèle à l'ouverture distante d'une session (établissement d'une connexion) par le réseau ou par un lecteur local, la fermeture distante d'une session (fin de connexion) est réalisée par l'intermédiaire de la commande terminal ENVELOPE encapsulant la structure EVENT DOWNLOAD-card reader status.

Selon l'invention la structure EVENT DOWNLOAD-card reader status est étendue par le positionnement en fin de structure d'un champ card reader status (hex) = 01 par exemple. Dans le cas présent statut = 01 correspond à une requête de fin de connexion (ssss = 0) sur le canal 01 (iiii = 1)

La structure EVENT DOWNLOAD-card reader status pourra s'écrire : AOC200000CD60A19010602028381200101 avec en ce qui concerne l'identification de l'Emetteur : (hex) 82 = Mobile pour les lecteurs locaux résidant dans le Mobile (hex) 83 = Réseau (Network) pour les connexions réseau (cas présent).

En conclusion le protocole selon l'invention décrit ciavant dans sa version de base présente un certain nombre d'avantages déjà mis en avant au cours de l'exposé de l'invention et qui sont résumés ci-après.

Le protocole selon l'invention permet une programmation simplifiée puisque que les ordres (commandes) sont soumis séquentiellement vers le lecteur sans nécessité de sortir de l'application à chaque ordre. En particulier le lecteur reste bloqué et indisponible pour une autre session jusqu'à réception du résultat de la commande proactive (ceci n'empêchant pas l'envoi de Notifications de carte par la commande ENVELOPE), toute erreur rencontrée pouvant ainsi être traitée immédiatement.

Pour le mobile le taux de transfert est amélioré par le protocole selon l'invention par rapport à l'utilisation des mini messages SMS, le mobile étant susceptible d'utiliser un circuit externe GPRS dans l'état actuel de l'art d'un débit d'au moins 9600 bits/s.

Par ailleurs les données sont échangées par une API uniforme quelque soit la localisation du lecteur (lecteur local résidant dans le mobile ou lecteur réseau distant) et la compatibilité avec le mécanisme de base de la

spécification GSM 11. 14/classe a pour le dialogue avec un lecteur est respectée.

De plus la disponibilité du canal de communication de données (réseau Internet, lien GPRS) est connue dès l'ouverture de la session par la commande POWER ON CARD qui retournera une erreur si le Mobile est dans l'incapacité d'ouvrir ce canal, par exemple si toutes les sessions sont actives, si la couverture radio est mauvaise ou si la machine distante ne répond pas au delà d'un certain délai (time out), par exemple de plusieurs secondes.

La disponibilité d'un circuit et la vitesse des transfert permettent d'envisager des transactions courtes ainsi que la mise en place sur la carte SIM pro-active de piles de protocoles tels que TCP étant données la simplicité de l'API (4 commandes) et son efficacité.

Enfin la connaissance avant de démarrer la transaction de la disponibilité du lien avec le lecteur et la rapidité du transfert de données obtenues grâce au protocole selon l'invention permet d'envisager avec ce protocole des applications de commerce électronique beaucoup plus fiables qu'en mode SMS.

III OPTIMISATION DE LA COMMANDE (PERFORM CARD APDU) Au delà de son implémentation de base, le protocole de communication selon l'invention comporte également en une première variante optionnelle un jeu de commandes optimisées pour combiner en une seule commande une commande d'opération de transfert de données avec une commande de fermeture de session.

COMMANDE COMBINEE D'ECRITURE A PARTIR DE LA CARTE SIM ET DE FERMETURE DE SESSION (PERFORM CARD APDU) Par rapport à la commande d'écriture étendue PERFORM CARD APDU décrite ci-avant, la commande combinée comporte un attribut de commande Command Qualifier CQ = 06 (PUTDATAANDCLOSE), avec - une Identité Destinataire = 21 - un objet données TLV = CAPDU contenant les données à transférer [en l'espèce AAAA = (hex) 41414141 de longueur quatre octets L = 04].

La commande PERFORM CARD DATA (ECRITURE + FERMETURE) s'écrira : DOOF010301300602028121220441414141 Dans le cas présent l'attribut Command Qualifier CQ = 06 correspond au transfert de n octets de la carte SIM vers le Mobile, à la clôture d'écriture (absence d'octets à transférer) et à la fin de la connexion.

La réponse TERMINAL RESPONSE contiendra un TLV = RAPDU contenant les données à transférer en réponse, en l'espèce (hex) 0000, et s'écrira : A01400001001030130060202838103010023020000 avec l'Identité Emetteur = 83 = Réseau (Network) COMMANDE COMBINEE D'ECRITURE A PARTIR DU MOBILE (LECTURE DE DONNEES PAR LA CARTE SIM) ET DE FERMETURE DE SESSION (PERFORM CARD APDU) Pour cette opération de lecture par la carte SIM la commande PERFORM CARD APDU étendue est complétée selon l'invention par : - un attribut de commande (Command Qualifier) CQ (hex) = 01 avec CQ = 01 = GET-DATA= transfert de n octets du Mobile vers la carte SIM

- une Identité Destinataire (hex) = 21 donnant le no de canal = 21-20 = 01 - un objet données TLV = CAPDU contenant les données à transférer [en l'espèce (hex) OOOO avec L= 02].

La commande PERFORM CARD DATA (LECTURE) s'écrit au départ carte SIM sans changement par rapport à la commande étendue correspondante : DOOD010301300102028121220200009000 Par contre la modification apparaîtra dans la réponse TERMINAL RESPONSE dont le champ attribut de commande Command Qualifier sera porté à la valeur (hex) CQ = 06 (au lieu de CQ = 02 = lecture incomplète ou CQ = 04 = lecture complète) et correspondant à la fin de la lecture par la carte en fait de l'écriture par le Mobile, toutes les données étant disponibles dans l'objet TLV RAPDU, et à la fin de la connexion.

Ainsi la réponse TERMINAL RESPONSE qui contient un TLV = RAPDU contenant les données à transférer en réponse, en l'espèce (hex) 414243 s'écrira :

A0140000110103013006020283810301002303414243 où l'Identité Emetteur = 83 = Réseau (Network) et où le champ Command Qualifier CQ = 06.

De plus le protocole selon l'invention comporte également en une seconde variante optionnelle un jeu de commandes optimisées pour la lecture d'une chaîne d'octets à accès séquentiel, ci-après flux de données (stream), et notamment pour réaliser au moins une des opérations :

- de glissement du pointeur de lecture du flux de données par intégration d'une commande complémentaire SKIPDATA /GLISSERDONNEES,

LECTURE OPTIMISEE A PARTIR DE LA CARTE SIM (PERFORM CARD APDU) Dans cette seconde variante la commande de lecture entendue PERFORM CARD APDU [qui dans sa version de base présente un champ attribut de commande Command Qualifier CQ = 01 (GETDATA)] voit le champ CQ élargi selon les options d'écriture suivantes : CQ = 01 (GETDATA) CQ = 03 (SKIPDATA) avec glissement du pointeur de lecture du flux de données venant du Mobile de N octets, N étant spécifié dans l'objet TLV (C~APDU) CQ =-1 (FLUSHDATA) avec élimination de tous les caractères du flux de données en attente de lecture CQ = 05 (FINDDATA) avec glissement du pointeur de lecture du flux de données venant du Mobile jusqu'à trouver dans les caractères du flux de données en attente de lecture l'élément TLV, ASN, etc.. dont la valeur est spécifiée dans l'objet TLV (C~APDU).

Ainsi la commande PERFORM CARD ADPU (SKIPDATA) s'écrit : DOOD010301300302028111220202AE9000 où l'Identité Destinataire (hex) = 21 permet de connaître le no de canal = 21-20 = 01 et où N (hex) = 02AE soit 686 octets.

En retour le TERMINAL RESPONSE correspondant s'écrira : A0140000110103013002020283810301002303414243

où CQ = 02 (lecture incomplète) l'Identité Emetteur = 83 (Réseau/Network) TLV (RAPDU) = 2303414243 contient les données (hex) à transférer à la carte soit en l'espèce 414243.

Cette dernière commande de lecture PERFORM CARD APDU optimisée est particulièrement performante pour la lecture dans des bases de données de grandes dimensions souvent rencontrées dans les réseaux de données, notamment dans le réseau Internet.

Dans la pratique on notera que ces extensions selon l'invention des commandes pro-actives GSM 11.14/classe a et de la procédure de Notification carte Evénement sur lecteur de carte sont réalisées sous la forme d'une ou plusieurs applications logicielles conformes aux nouvelles règles et procédures présentées ci-avant pour les commandes pro-actives de carte ou de lecteur de carte et la procédure de Notification ainsi modifiées, ces applications logicielles étant regroupées pour former de façon non limitative la couche logicielle du protocole de communication selon l'invention PCINV.

On rappellera pour finir que bien entendu le protocole de communication selon l'invention n'est pas limité à sa mise en oeuvre et à son implémentation dans l'environnement GSM décrites ci-devant mais est susceptible d'être mis en oeuvre dans le cadre de l'invention défini par les revendications ci-après dans toute application utilisant une carte pro-active conforme ou compatible ISO 7816-3/4 ou capable d'émuler ou de supporter le protocole ISO 7816-3/4 et comportant un jeu de commandes pro-actives de carte ou de lecteur de carte susceptibles d'être étendues pour gérer une session de communication entre la carte et son terminal d'accueil.

Claims

REVENDICATIONS : 1. Protocole de communication destiné entre autres à gérer les transferts de données entre une carte à puce pro-active (10,20, 30) conforme ou compatible ISO 7816-3/4 ou capable, éventuellement à l'aide d'une machine proxy, d'émuler le protocole ISO 7816-3/4 ou des protocoles supportant ce protocole ISO 7816-3/4, ci-après la carte initiatrice, et son terminal d'accueil (11-12,21, 31), ledit protocole de communication comportant au moins les commandes pro-actives de carte ou de lecteur de carte correspondant aux opérations suivantes : Activation de lecteur de carte, Transfert (s) de données, Désactivation de lecteur de carte, et une procédure de Notification de carte de type Evénement sur lecteur de carte, ledit protocole de communication étant caractérisé en ce que lesdits transferts de données sont gérés par sessions de communication sur carte pro-active comportant au moins la séquence d'opérations suivante : Ouverture de session, l'ouverture étant locale à partir de la carte ou distante à partir du terminal, Transfert (s) de données synchrone (s) ou asynchrone (s), Fermeture de session, la fermeture étant locale à partir de la carte ou distante à partir du terminal, au moyen de commandes pro-actives étendues dérivées desdites commandes pro-actives de carte ou de lecteur de carte et d'une procédure de Notification de carte étendue dérivée de ladite procédure de Notification de carte de type Evénement sur lecteur de carte.
2. Protocole selon la revendication 1, caractérisé en ce qu'il est utilisé dans une ou plusieurs sessions de communication sur carte pro-active localement distinctes pour des transferts de données carte à carte au travers d'une chaîne de sessions de communication assurant la

<Desc/Clms Page number 43>

connexion directe et permanente entre les deux cartes (20-24, 30-37) pendant la durée des sessions.
3. Protocole selon la revendication 1, caractérisé en ce qu'il est utilisé pour le transfert de données au travers du terminal d'accueil (21) entre la carte initiatrice (20,30) et au moins une carte locale (24) connectée audit terminal (21) par un lecteur de carte local réel ou virtuel (22) ou au moins une carte réseau (37) connectée à un réseau de données externe ou distant (72,34, 73) par un lecteur réseau réel ou virtuel (36).
4. Protocole selon la revendication 1, caractérisé en ce que les transferts de données entre ladite carte initiatrice (20,30), les cartes locales (24,25) et/ou les cartes réseau (37) sont réalisés en tout ou partie sur une ou plusieurs interfaces au travers de canaux de communication alloués dynamiquement.
5. Protocole selon la revendication 4, caractérisé en ce qu'une commande d'ouverture d'une session de communication sur carte pro-active (10) génère l'attribution locale entre la carte (10) et le terminal (12) d'un numéro de session et l'attribution d'un numéro de canal de communication.
6. Protocole selon la revendication 5, caractérisé en ce qu'il est utilisé de façon bidirectionnelle aux deux extrémités d'une connexion entre deux cartes pro-actives distantes (30-37), chaque carte (30-37) étant connectée localement à son terminal correspondant (31-34) par une session de communication sur carte pro-active, les deux terminaux (31-34) étant connectés entre eux par au moins une session réseau et adaptés pour gérer les conversions de protocoles entre les sessions sur cartes pro-actives

<Desc/Clms Page number 44>

et la session réseau et les flux de données dans les canaux de communications correspondants.
7. Protocole selon la revendication 1, caractérisé en ce que l'adresse utilisée pour les lecteurs est constituée d'un numéro de téléphone, notamment pour les réseaux du type X25, ATM, RNIS ou analogue, d'une adresse IP avec numéro de port implicite prédéfini, d'une adresse IP avec numéro de port TCP/IP ou un nom logique, définitif ou temporaire, composé d'un nom de machine, par exemple son adresse réseau, et d'un nom d'application logicielle, par exemple son AID.
8. Protocole selon la revendication 7, utilisant un nom logique avec un adressage réseau, caractérisé en ce que : - à l'ouverture de session une première connexion est d'abord établie entre deux applications réseau, ladite première connexion ou connexion réseau étant suivie d'une connexion de type applicatif avec échange de messages sur la connexion réseau, et - à la fermeture de session, la fermeture de ladite connexion de type applicatif est réalisée dans un premier temps puis suivie de la fermeture de la connexion réseau.
9. Protocole selon la revendication 1, caractérisé en ce que ladite carte initiatrice (20,30) est connectée : I) soit en mode APDU strict avec transfert de données au format APDU sur session : la) avec un lecteur de carte (25) associé localement au lecteur de la carte initiatrice (22), par exemple un mobile GSM bi-fentes avec carte initiatrice SIM et une carte classique de débit/crédit ; Ib) avec un lecteur de carte distant associé à un réseau externe de données, la carte initiatrice accédant au réseau par des terminaux (31,34) formant serveurs de réseaux, par exemple par une machine proxy locale à la

<Desc/Clms Page number 45>

carte initiatrice et une machine proxy locale au lecteur de carte distant ; ou le) une carte à puce virtuelle définie par une application informatique locale ou distante émulant le protocole ISO 7816-3/4 ou des protocoles supportant ce protocole ISO 7816-3/4 ; II) soit en mode binaire sur session avec transfert de données en format binaire : lia) avec un lecteur de carte (24) associé localement au lecteur de la carte initiatrice (20) et supportant un protocole supportant l'ouverture de session de communication sur carte pro-active ; IIb) avec un lecteur de carte distant (37) associé à un réseau externe de données (72) et supportant un protocole supportant l'ouverture de session, la carte initiatrice (30) accédant à des terminaux (31,34) formant serveurs de réseau assurant la gestion de la session carte initiatrice et de la session réseau distant ; ou IIc) une carte à puce virtuelle définie par une application informatique locale ou distante et gérant des sessions de type TCP ou X25.
10. Protocole selon la revendication 1, caractérisé en ce qu'il est utilisé pour l'acheminement de données de type APDU entre la carte initiatrice (20,30) et des terminaux (21,34) supportant indifféremment le mode APDU ou le mode binaire pour permettre au niveau carte l'utilisation d'interfaces de programmation d'application, également dénommées API, homogènes et de haut niveau.
11. Protocole selon la revendication 1, caractérisé en ce qu'il est utilisé avec une carte initiatrice (10,20, 30) de type carte SIM pro-active et un terminal d'accueil compatible GSM, ledit protocole comportant une extension de commandes pro-actives de lecteur de carte local de la spécification GSM 11. 14/classe a de façon à utiliser des

<Desc/Clms Page number 46>

commandes pro-actives étendues uniformes pour gérer les transferts de données entre la carte SIM (10, 20, 30) et indifféremment un lecteur local (24) ou un lecteur réseau externe (37).
12. Protocole selon la revendication 11, caractérisé en ce que les commandes de lecteur de carte de la spécification GSM 11.14/classe a faisant l'objet d'une extension sont les suivantes : - POWER ON CARD/ACTIVATION LECTEUR DE CARTE utilisée pour l'Ouverture locale de session - PERFORM CARD APDU/EXECUTION COMMANDE APDU PAR LE LECTEUR CARTE utilisée pour les Transferts de données synchrones - POWER OFF CARD/DESACTIVATION LECTEUR DE CARTE utilisée pour la Fermeture locale de session et de façon optionnelle la commande : - GET READER STATUS/RECHERCHE STATUT LECTEUR DE CARTE.
13. Protocole selon la revendication 12, caractérisé en ce qu'il présente la capacité d'insertion dynamique des lecteurs réseau (36) et/ou de lecteurs locaux (24) et de réalisation de sessions de communication sur carte proactive à partir de cartes distantes (37) et/ou de cartes locales (24), avec possibilité d'ouverture et de fermeture de session distantes à partir du terminal d'accueil, par extension de la procédure de Notification de carte EVENT DOWNLOAD-CARD READER STATUS/NOTIFICATION D'EVENEMENT-STATUT LECTEUR DE CARTE de la spécification GSM 11.14/classe a.
14. Protocole selon la revendication 13, caractérisé en ce qu'il est utilisé pour l'envoi asynchrone de données vers une application en état de session ouverte ou l'extraction asynchrone de données à partir d'une application en état de session ouverte.

<Desc/Clms Page number 47>
15. Protocole selon la revendication 11, caractérisé en ce que les commandes étendues sont optimisées pour combiner en une seule commande une commande d'opération de transfert avec une commande de fermeture de session.
16. Protocole selon la revendication 12, caractérisé en ce que la commande étendue PERFORM CARD ADPU pour la lecture à partir de la carte SIM pro-active (10,20, 30) est optimisée pour permettre lors de la lecture d'une chaîne d'octets à accès séquentiel, ci-après flux de données, de réaliser au moins une des opérations : - de glissement du pointeur de lecture du flux de données par intégration d'une commande complémentaire SKIPDATA /GLISSER-DONNEES, - d'élimination de tous les caractères du flux de données en attente de lecture par intégration d'une commande complémentaire FLUSHDATA/VIDERDONNEES et - de recherche dans les caractères du flux de données en attente de lecture par intégration d'une commande complémentaire FIND~DATA/TROUVER~DONNEES.