Système de communication protocolaire entre une carte à puce et un terminal et son procédé de communication
La présente invention concerne un système de communication protocolaire entre une carte à puce et un terminal, particulièrement un système de communication protocolaire permettant à un applicatif intégré à une carte à puce d'être exécuté par un terminal et le procédé de communication associé.
II est connu dans l'art antérieur des terminaux acceptant des cartes à puce par exemple les terminaux de paiement électronique, les distributeurs de billets, les lecteurs personnels, les terminaux de santé. Ces terminaux doivent être programmés pour chaque application devant être supportée. Ainsi, si un émetteur de cartes souhaite lancer une application de fidélité, il lui faudra faire modifier tous les terminaux du parc pour que les cartes puissent être lues.
Cette procédure est très coûteuse, puisqu'il faut écrire un logiciel spécifique par terminal et par type de carte, puis installer ces logiciels sur chaque terminal d'un parc. Une technologie connue, le SIM Application Toolkit permet à une carte d'abonné de téléphonie mobile d'afficher un menu propre à l'opérateur de téléphonie sur un quelconque terminal GSM et d'effectuer quelques opérations de base.
L'inconvénient de cette technologie est qu'elle ne vise pas tous les types de terminaux, elle ne gère pas les communications complexes telles que la messagerie universelle, les feuilles de style, la gestion d'imprimantes, du multimédia, installation de logiciels....
La présente invention a pour but de pallier certains inconvénients de l'art antérieur en proposant un système de communication entre un terminal et une carte à puce permettant au terminal d'exécuter un applicatif intégré dans la carte à puce.
Ce but est atteint par un système de communication entre un terminal et une carte caractérisé en ce que la carte comprend un premier applicatif et le terminal comprend un deuxième applicatif et un ou plusieurs lecteurs de carte,
le premier applicatif et le deuxième applicatif permettant au système de réaliser l'exécution d'un traitement spécifique de la carte par envoi d'une requête de la carte vers le terminal, la carte adaptant le premier applicatif en fonction des caractéristiques du terminal et en ce que les paramètres envoyés par la carte comprennent un moyen permettant à la carte de décider de l'abandon ou non de l'exécution de ladite requête par le terminal si celui-ci rencontre une anomalie dans les conditions d'exécution de ladite requête.
Selon une autre particularité, les paramètres envoyés par la carte comprennent un moyen permettant au terminal de répondre ou non à la carte à la fin de l'exécution de la requête envoyée par la carte au terminal, si l'exécution de ladite requête par le terminal s'est déroulée avec succès.
Selon une autre particularité,
le premier applicatif implémenté dans la carte est mémorisé dans un espace mémoire de la carte.
Selon une autre particularité, le premier applicatif implémenté dans la carte s'exécute sur une machine virtuelle adaptable sur tout type de carte. Selon une autre particularité, la machine virtuelle est de type Java ou
Multos.
Selon une autre particularité, le deuxième applicatif implémenté dans le terminal est un interpréteur adaptable sur tout type de terminal.
Un autre but est atteint par un procédé de communication d'un système de communication entre un terminal et une carte, la carte comprenant un premier applicatif et le terminal comprenant un deuxième applicatif et un ou plusieurs lecteurs de carte,
ledit procédé est caractérisé en ce qu'il comprend un premier sous procédé d'identification du premier applicatif implémenté dans la carte et du deuxième applicatif implémenté dans le terminal et un second sous procédé permettant le transfert de requêtes et de données envoyées par la carte vers le terminal.
Selon une autre particularité, le premier sous procédé d'identification comprend les étapes suivantes :
- une étape d'initialisation de la carte dans un lecteur du terminal, et d'envoi d'un moyen identifiant le premier applicatif implémenté dans la carte. - une étape de détection par le terminal du moyen identifiant le premier applicatif représentatif du premier applicatif implémenté dans la carte, si le moyen identifiant le premier applicatif n'existe pas la communication entre le terminal et la carte s'effectue normalement,
- une étape d'envoi d'une commande comprenant des données afférentes aux caractéristiques du terminal, si le terminal comprend le deuxième applicatif, ladite étape permettant à la carte de détecter le deuxième applicatif implémenté dans le terminal ; si le terminal ne comprend pas l'applicatif la communication entre le terminal et la carte s'effectue normalement.
Selon une autre particularité, une requête envoyée par la carte permet d'imprimer des données choisies par la carte sur une imprimante du terminal, les données associées à cette requête représentant au moins un des paramètres suivants, un paramètre identifiant une imprimante destinataire de l'impression, une chaîne de texte non formaté, un paramètre identifiant le formatage d'un texte, des paramètres d'impression, un paramètre de priorité d'impression, l'exécution de cette commande par le terminal comprend au moins une des étapes suivantes :
- une étape permet de stocker les données à imprimer dans une mémoire tampon du terminal,
- une étape permet de vérifier si le paramètre fourni par la carte et identifiant le formatage d'un texte existe, si c'est le cas le terminal exécute le formatage des données suivant un format défini par la carte,
- une étape permet de définir l'imprimante destinataire d'impression, si le paramètre fourni par la carte et identifiant une imprimante destinataire n'indique pas d'imprimante, une imprimante d'impression sera choisie par défaut, si le paramètre identifiant une imprimante destinataire indique une imprimante destinataire mémorisée dans le terminal, c'est l'imprimante destinataire qui sera choisie, dans le dernier cas si cette imprimante n'existe pas dans le terminal, le terminal terminera l'exécution et retournera un message d'erreur à la carte,
- une étape permet d'imprimer les données choisies par la carte immédiatement si le terminal n'a pas de donnée, choisie par lui, à imprimer et si le paramètre d'impression fourni par la carte indique une impression immédiate, si ce paramètre n'indique pas d'impression immédiate les données choisies par la carte seront imprimées en même temps que des données choisies par le terminal, - une étape permet d'imprimer les données choisies par le terminal avant les données choisies par la carte si le terminal veut imprimer les données qu'il a choisies et si le paramètre de priorité fourni par la carte d'impression est actif,
- une étape permet d'imprimer les données choisies par le terminal après les données choisies par la carte, si le terminal veut imprimer les données, qu'il a choisies et si le paramètre de priorité d'impression fourni par la carte est inactif,
- à la fin de l'exécution de l'impression le terminal envoie un message indiquant le déroulement de l'exécution. Selon une autre particularité, une requête envoyée par la carte permet d'éjecter une carte d'un lecteur du terminal, une des données associée à cette requête étant un paramètre identifiant le lecteur du terminal dans lequel se trouve la carte à éjecter.
Selon une autre particularité, une requête envoyée par la carte permet de capturer une carte d'un lecteur du terminal, une des données associée à cette requête étant un paramètre identifiant le lecteur du terminal dans lequel se trouve la carte à éjecter, la carte à éjecter pouvant être la carte comprenant l'applicatif.
Selon une autre particularité, une requête envoyée par la carte permet d'ajouter un favori dans les fichiers de favoris du terminal,
les données envoyées par la carte relatives à ladite requête représentant au moins un des paramètres suivants, un paramètre indiquant un URL, un paramètre présentant un chemin d'accès au nouveau fichier de favori et un paramètre indiquant le nom du nouveau favori.
Selon une autre particularité, une requête envoyée par la carte permet de retirer un favori dans les fichiers de favoris du terminal, les données envoyées par la carte relatives à ladite requête présentant au moins un des paramètres suivants, un paramètre indiquant un chemin d'accès du fichier de favori et un paramètre indiquant le nom du favori à retirer du fichier favori du terminal.
Selon une autre particularité, une requête envoyée par la carte permet d'installer une nouvelle application dans le terminal,
les données envoyées par la carte relatives à ladite requête présentant au moins un des paramètres suivants, un nom de l'application, une version de l'application, un paramètre indiquant l'espace mémoire nécessaire à l'installation de l'application, un paramètre indiquant un URL où se trouve le programme à installer.
Selon une autre particularité, une requête envoyée par la carte permet de sélectionner un programme commercial dans le terminal, un des paramètres envoyé par la carte relatif à ladite requête étant un paramètre identifiant le programme commercial à sélectionner et le terminal répondant à la requête selon qu'il est ou non affilié au programme commercial passé en paramètre.
Selon une autre particularité, une requête envoyée par la carte permet de lancer une procédure complète de signature électronique d'un document.
Selon une autre particularité, une requête envoyée par la carte permet d'envoyer des messages à un dispositif distant, les données envoyées par la carte relatives à ladite requête présentant au moins un des paramètres suivants, une adresse d'un serveur de messagerie, une adresse de messagerie de retour,
un identifiant d'un compte de messagerie, un mot de passe.
Selon une autre particularité, une requête envoyée par la carte permet de récupérer des messages d'un dispositif distant, les données envoyées par la carte relatives à ladite requête présentant au moins un des paramètres suivants, une adresse d'un serveur de messagerie, un identifiant d'un compte de messagerie, un mot de passe.
D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après, faite en référence aux dessins annexés, dans lesquels :
- la figure 1 représente un système de communication entre un terminal et une carte à puce, selon un mode de réalisation de la présente invention ;
- la figure 2 représente un organigramme représentatif du procédé d'identification de la technologie supportée par la carte et le terminal, selon un mode de réalisation de la présente invention ;
- la figure 3 représente un organigramme représentatif du procédé de communication entre la carte et le terminal, selon un mode de communication de la présente invention ; - la figure 4 représente un organigramme représentatif du procédé de mise en place d'une commande d'impression entre la carte et le terminal, selon un mode de communication de la présente invention ;
- la figure 5 montre le schéma représentatif d'un message permettant à la carte d'envoyer des commandes au terminal ;
- la figure 6 montre le schéma représentatif d'un message suivant un protocole connu permettant au terminal d'envoyer vers la carte ou de récupérer des données de la carte.
La figure 1 représente un système de communication (1) utilisant un procédé de communication selon un mode de réalisation de la présente invention. Ledit système comprend un terminal (2) comportant un lecteur universel (20) de carte à puce et une carte à puce (3) à insérer dans le lecteur (20) du terminal (2). La carte à puce (3) comprend un premier moyen de traitement (30), dit applicatif, destiné à être exécuté par le terminal (2) et d'autres programmes d'applications propres à une utilisation spécifique de la carte, par exemple une carte bancaire ou une carte santé.
Le terminal (2) comprend des logiciels pilotes (21) qui lui sont propres tel que le gestionnaire d'affichage, il comprend également un second moyen de traitement (22), appelé également applicatif ou interpréteur, permettant de communiquer dans un mode maître (pour la carte) - esclave (pour le terminal) avec tous types de cartes à puce (3) comportant le premier moyen de traitement (30). L'interpréteur du terminal reçoit les requêtes envoyées par la carte et les exécute après réception. Pour que la transmission d'information entre le terminal (2) et la carte (3) soit réalisée, il faut que les deux éléments terminalcarte supportent la même technologie. Les deux moyens de traitement (30, 22) utilisent un protocole commun pour communiquer entre eux.
La présente invention est applicable sur tout type de terminal (2) et de carte à puces (3).
Le protocole de communication étant standardisé, un même moyen de traitement fonctionne sur tous les terminaux, quelle que soit leur marque, leur modèle et leur version logicielle, par exemple, un ordinateur PC connecté à Internet, un distributeur de billet, un terminal de paiement, un lecteur personnel. Une unique carte à puce (3) comportant l'applicatif de la présente invention peut communiquer en tant que maître de différents terminaux supportant également la technologie de la présente invention. Par exemple, une carte à puce, de type carte santé comprenant cet applicatif, peut être insérée dans un lecteur d'un distributeur de billet supportant également la technologie. La carte (3) demandera par des requêtes ou commandes adressées au distributeur d'afficher ou d'imprimer, par exemple le numéro de sécurité sociale.
Un utilisateur pourra ainsi visualiser via l'écran du distributeur de billet une information autre que le retrait ou le solde de ses comptes, cette information provenant de la carte à puce. Ainsi la carte (3) pilote le terminal avec lequel elle communique en lui demandant d'exécuter des commandes de l'applicatif implémenté dans la carte. La carte à puce (3) adapte son applicatif (30) au type de terminal (2) avec lequel elle communique. Par exemple, une carte bancaire supportant l'applicatif (30) ne va pas donner les mêmes informations à deux terminaux différents chacun ayant un profil différent. Un terminal du type lecteur de carte personnel va afficher sur demande de la carte (3) le montant des dernières transactions, le solde du compte.
Par contre un lecteur relié à un PC, lui-même connecté à Internet, va permettre d'afficher les différents montants précités, mais également ouvrir un favori Internet contenant l'adresse de la banque émettrice de la carte, imprimer des données afférentes à la carte (3) sur l'imprimante du PC. L'affichage des montants, l'impression de données, l'ouverture d'un favori Internet sont des commandes demandées par la carte (3) et exécutées par le terminal.
Le moyen de traitement (30) de la carte (3) peut être implémenté en dur dans la carte (3) en le stockant par exemple dans une mémoire de la carte (3). Le moyen de traitement peut également être implémenté dans la carte (3) grâce à l'intégration d'une machine virtuelle, par exemple, de type JavaCard ou Multos, avec les interfaces standards pour l'application de programme, dit API.
L'implantation de la technologie de la présente invention dans un terminal (2) est également faite par intégration d'un interpréteur de commandes. Ce type d'interpréteur a l'avantage de comprendre des fonctions standardisées applicables sur tout terminal. C'est l'applicatif (30), différent suivant son utilisation, intégré dans la carte (3) qui permet de différencier l'exécution à faire par le terminal. L'applicatif (30) de la carte (3) va s'adapter aux caractéristiques du terminal (2) pour lui faire exécuter une demande.
II peut s'avérer qu'une carte (3) supportant la technologie soit utilisée sur un terminal (2) ne supportant pas la technologie ou qu'une carte (3) ne supportant pas la technologie soit utilisée sur un terminal (2) supportant la technologie.
Dans ces cas, un procédé d'identification a été mis au point afin de préserver la compatibilité technologique entre la carte (3) et le terminal (2). Ce procédé comprend plusieurs étapes permettant de définir si la carte (3) et le terminal (2) supportent les applications (30, 22). La figure 2 présente ledit procédé. Une fois la carte à puce (3) insérée dans le lecteur (20) d'un terminal (2) (étape 40) ou lors de la sélection d'une application de la carte par le terminal ou lors de tout autre moment choisi par la carte, la carte envoie au terminal (2), via un message, un moyen identificateur lui indiquant si oui ou non elle supporte la technologie de la présente invention (étape 41). A l'aide de ce moyen identificateur le terminal détecte si la carte (3) supporte la technologie (étape 42).
Si le moyen identificateur n'est pas présent la carte (3) ne supporte pas la technologie, le traitement entre la carte (3) et le terminal (2) se fait normalement ou ne se fait pas (étape 45). Dans le cas contraire (étape 43), la carte (3) attend une réponse du terminal (2). Si le terminal (2) supporte la technologie, il envoie à la carte (3) des données représentatives de ses capacités vis à vis de la technologie de la présente invention, indiquant par conséquent à la carte (3) qu'il supporte lui aussi cette technologie (étape 46). Dans le cas contraire (étape 45), le terminal (2) n'envoie aucune donnée caractéristique le concernant et le fonctionnement entre la carte (3) et le terminal (2) s'effectue normalement.
Si les deux entités, la carte (3) et le terminal, supportent la technologie, la carte (3) peut commencer à envoyer au terminal (2) des commandes dont les formats sont définis ci-après. La carte (3) indique au terminal (2) l'action qu'il a à exécuter en utilisant les commandes. L'applicatif de la présente invention compris dans la carte ne perturbe pas les autres programmes d'application spécifiques à la carte. Une description plus détaillée du procédé d'identification est présentée ci-après.
Selon une méthode connue, dès l'insertion de la carte (3) dans le lecteur du terminal (2) (étape 40), la carte (3) peut envoyer à celui-ci (étape 41) une trame d'octets représentatifs de l'historique de la carte (3) indiquant ainsi ces caractéristiques d'opération.
II est également possible que lors de l'exécution d'une application spécifique à la carte et au terminal tel que le paiement par carte bancaire, la carte retourne au terminal un message de réponse incluant une donnée identifiant la présence de la technologie de la présente invention. L'annexe A présente, par exemple, la trame d'envoi lors de l'initialisation de la communication. Pour indiquer qu'elle supporte l'applicatif de la présente invention, la carte (3) doit avoir une donnée propriétaire particulière référencée par un identificateur de tête ou amorce, appelé, par exemple, H9 dans l'annexe A. Cet identificateur de tête a une valeur spécifique, par exemple dans l'annexe A, il est de valeur hexadécimale A1 . L'octet HA suivant l'étiquette H9 indique si la carte (3) supporte l'applicatif.
Par exemple, en se référant à l'annexe A, si la carte (3) supporte l'applicatif, cet octet appelé HA sera présent et aura pour valeur hexadécimale 00 .
Si l'octet identifiant l'existence de l'applicatif dans la carte, est présent dans la trame d'amorce, le terminal, supportant également la technologie, envoie une commande à la carte (3) (étape 46) accompagnée de données indiquant son profil, c'est à dire les caractéristiques supportées par le terminal. Par exemple, le terminal (2) est un PC ou un distributeur de billet, comprenant des périphériques telle qu'une imprimante. La commande envoyée par le terminal (2) à la carte (3) est nommée PUT DATA , indiquant que le terminal (2) envoie des données à la carte.
La commande PUT DATA présentant le profil du terminal, indique que le terminal (2) supporte l'applicatif (22) et indique également ses caractéristiques détaillées. Cette commande est utilisée pour informer la carte (3) des caractéristiques principales du terminal. La carte (3) peut demander, plus tard, d'autres détails en envoyant une commande demandant des informations d'environnement du terminal.
La transmission d'un message du terminal (2) vers la carte (3) comprend un protocole normalisé par l'ISO, similaire à la transmission de données d'un terminal GSM vers une carte Sim. Lors de l'envoi de données du terminal (2) vers la carte, le terminal (2) transmet une trame comprenant différents champs. La trame est représentée en figure 6. Le premier champ appelé CLA précise le type d'application, par exemple l'envoi d'une commande.
Le second champ appelé INS donne l'instruction de la commande, dans le cas présent l'instruction est PUT DATA . Le troisième champ et le quatrième champ appelés respectivement P1 et P2 , précisent, si nécessaire, les paramètres de l'instruction. Le cinquième champ appelé Le précise la longueur de la commande ou de la réponse attendue. Le sixième champ fournit les données à transmettre si nécessaire. Le septième et dernier champ appelé Le indique le nombre d'octets attendu en réponse. Le champ de données joint à la commande PUT DATA relative à l'envoi d'un profil du terminal, comprend au moins 14 octets correspondant aux capacités du terminal (2) en fonction de la technologie de la présente invention. Ce champ est représenté par un tableau dans l'annexe B.
Ce tableau indique, entre autres, le type de terminal (2) tels qu'un PC ou un distributeur de billet, un lecteur personnel, le type d'imprimante, le type d'afficheur, ainsi que les commandes, les connexions et les événements que veut supporter le terminal. Par exemple deux octets du champ de données indiquent les différents paramètres concernant le type d'imprimante associée au terminal. L'annexe C représente ces deux octets.
En réponse aux commandes transmises par le terminal, la carte (3) envoie une trame de réponse suivant le protocole ISO 7816. La figure 6 montre un schéma représentatif de la trame envoyée par la carte (3) au terminal. Les deux octets, appelés SW1 et SW2, indiquent, en général, le succès ou l'échec de la commande. Ces deux premiers champs peuvent être accompagnés ou non de données.
Dans le cas de la présente invention, le champ SW1 indique si la transmission entre la carte (3) et le terminal (2) est une transmission normale d'information avec succès ou si la carte (3) a des commandes à faire exécuter par le terminal. Dans ce dernier cas, le champ SW2 donne la longueur des octets que le terminal (2) doit récupérer. Lors d'une réponse signifiant un acquittement positif de la carte, le champ SW1 a, par exemple, pour valeur hexadécimale '90' et le champ SW2 a, par exemple, pour valeur hexadécimale '00'. Dans le deuxième cas, lorsque la carte (3) veut envoyer une commande au terminal, le champ SW1 a, par exemple, pour valeur hexadécimale '62' et le champ SW2 a, par exemple, une valeur hexadécimale indiquant le nombre d'octets que le terminal (2) devra récupérer.
La figure 3 représente le procédé de communication entre la carte (3) et le terminal, quand la carte (3) envoie une commande au terminal. Dès que la carte (3) a reçu la commande PUT DATA du terminal (2) (étape 47) indiquant les caractéristiques du terminal, la carte (3) envoie l'état du traitement de la commande dans le message de réponse comprenant les octets SW1 et SW2 (étape 48). Si le traitement de la commande PUT DATA est un succès (étape 51 ), les champs SW1 et SW2 du message de réponse sont par exemple à la valeur '9000'. Si la carte (3) veut signifier au terminal (2) qu'elle a une requête qu'il doit retirer et pour laquelle elle attend une réponse (étape 50), les champs SW1 et SW2 ont une valeur différente et sont par exemple à la valeur hexadécimale '62XY'.
Dans l'exemple ci-avant, la requête contient 'XY' octets en valeur hexadécimale, 'XY' pouvant être compris entre les valeurs hexadécimales '02' et '80'. La carte (3) utilise les octets SW1 et SW2 comme un moyen de lancement de commande, indiquant qu'elle veut émettre une trame pour laquelle elle attend une réponse. En réponse à la demande de la carte, le terminal (2) envoie une commande de récupération de données appelée de préférence GET DATA (étape 50). Les paramètres P1 et P2 de ladite commande sont, par exemple, à la valeur '0000' et le paramètre Le à la valeur 'XY'.
Par retour de réponse, la carte (3) envoie la commande au terminal (étape 51), ladite commande étant transmise par le champ de données situé après les champs SW1 et SW2. Un nouveau test est ensuite réalisé sur les champs SW1 et SW2 envoyés par la carte (3) au terminal (2) (étape 48).
Si les champs SW1 et SW2 sont à la valeur '62 XY', la carte (3) signifie qu'il y a encore une requête de 'XY' octets à récupérer (étape 50) et à concaténer avec la requête précédente avant traitement de ces données par le terminal (2). Si les champs SW1 et SW2 sont à la valeur '9000', la carte (3) signifie que la commande de récupération est un succès et que le terminal (2) peut traiter les données (étape 52).
Pour envoyer une commande, la carte (3) encapsule la commande et les données dans le champ données de la réponse précédant les octets SW1 et SW2, comme représenté en figure 5. Une commande comprend les mêmes champs qu'une commande du terminal. Le premier champ CLA indique le type d'application, ici l'application est une commande. Le second champ INS donne l'instruction, par exemple, imprimer les données suivantes.
Le cinquième champ Le indique la taille des données envoyées. Le sixième champ Data donne les données ou paramètres nécessaires à la mise en place de la commande. Dans l'exemple précédent il s'agit des données à imprimer. Le troisième champ et le quatrième champ P1 et P2 ont une utilité différente comparée au champ paramètres d'une commande envoyée par le terminal. Le champ P1 indique l'index de la commande, l'index étant un compteur permettant à la carte (3) d'adapter les réponses du terminal (2) avec les commandes envoyées. L'index doit être mis à la valeur hexadécimale 00 à chaque nouvelle session. Si l'index est à la valeur FF , la prochaine valeur est à 00 . Le champ P2 indique l'option de traitement de la commande. L'annexe D est un tableau récapitulant l'utilité des différents bits de l'octet P2.
Les deux bits, b8 et b7, de poids le plus fort de l'octet P2, sont les plus utilisés. Si le bit b8 de l'octet P2 est à la valeur logique '0', le terminal (2) doit arrêter le traitement de la commande, dès qu'une des conditions du traitement n'est pas présente. Si le bit est à la valeur logique , le terminal (2) essaie de continuer le traitement malgré une condition manquante. Lorsque cette commande ne peut pas être traitée, le terminal (2) peut envoyer une alarme dans le champ de réponse de la commande. Si le terminal (2) ne peut pas continuer le traitement, une erreur est alors envoyée. Si le bit b7 du champ P2 est à la valeur logique '0', le terminal (2) ne doit pas envoyer de réponse à la carte, lorsque le traitement s'est achevé avec succès. Ce bit b7 empêche des dialogues superflus entre la carte (3) et le terminal.
Les autres bits, b6 à b1 , de l'octet P2 sont disponibles pour toutes fonctions non encore définies. Les différentes commandes utilisées par la technologie de la présente invention, sont présentées dans la suite de la description.
Pour transmettre une réponse à la carte (3) concernant une commande, le terminal (2) envoie une commande 'PUT DATA' de réponse suivie des données réponses (étape 53 de la figure 3). Si la réponse est trop longue pour une simple commande, une chaîne de commande est appliquée. Le champ de données réponses comprend au moins trois octets. Le premier octet indique le numéro de la commande à laquelle le terminal (2) répond, Le second octet et troisième octet indiquent le statut de résultat de l'exécution de la commande. Les octets suivants sont des informations supplémentaires envoyées par le terminal.
Un octet de statut égal, par exemple, à la valeur hexadécimale '9000', indique que l'exécution de la commande par le terminal (2) est un succès. L'annexe F représente les différentes valeurs de cet octet de statut avec leur signification. La carte (3) répond à la dernière commande PUT DATA par les octets SW1-SW2 présentés ci-avant.
La carte (3) peut demander au terminal (2) de lui envoyer une information concernant un événement, pour qu'elle puisse faire exécuter une requête au terminal.
Les différents événements émis par le terminal (2) vers la carte (3) indiquent par exemple que le terminal (2) va être en ligne, qu'une touche a été actionnée, qu'un document va être imprimé, que la carte (3) va être éjectée, que la carte (3) va être avalée, la carte (3) a été insérée / retirée dans un autre lecteur ou enfin qu'une connexion à une ressource distante a relevé un événement. Cette demande d'information d'événement est réalisée par le biais d'une commande d'interruption appelée de préférence 'SET INTERRUPT.
La commande de notification d'un événement envoyé par le terminal (2) à la carte (3) se nomme [Epsilon]NVELOPE'.
Le système Sim Toolkit permet également d'envoyer à partir d'une carte SIM des commandes vers un terminal (2) GSM, tels que l'affichage de données choisies par la carte sur l'écran du terminal, l'activation d'une commande de la carte sur réception d'un événement. Le système de la présente invention, adaptable sur tout terminal, englobe toutes les commandes déjà mises en place par le dispositif GSM, mais nécessite également de nouvelles commandes pour fonctionner. Ces nouvelles commandes sont présentées ci-après.
La commande 'ADD TO FAVORITES' permet à la carte (3) d'ajouter une nouvelle adresse d'une ressource distante telle que Internet ou WAP, dans le navigateur du terminal. Cette adresse est appelée favori dans la suite de la description.
La commande comprend les champs décrit ci-avant : 'CLA', 'INS', 'P1 \ 'P2', 'Le' et le champ de données. Ce dernier champ comprend des informations ou paramètres relatifs à la commande tels que le nom donné au favori, l'URL du favori, le chemin d'accès du sous fichier du favori, cette dernière information étant obligatoire. Ces informations sont détectables dans le champ de données par un moyen de repérage telle qu'une étiquette ayant une valeur spécifique, l'annexe D présente un exemple des valeurs d'étiquette. Par exemple, en se référant à l'annexe, l'étiquette représentative du nom du favori est de valeur hexadécimale 'DF10'.
A la réception de la commande 'ADD TO FAVORITE', le terminal (2) ajoute aux fichiers de favori de son navigateur l'URL mentionné dans le paramètre 'URL', dans le sous fichier de favori mentionné par le chemin d'accès du favori, ledit favori apparaissant à l'utilisateur sous le nom mentionné par le paramètre 'Nom du favori'. En fin d'exécution de la commande, le terminal (2) envoie un message via la commande 'PUT DATA' précisant le déroulement du traitement de la commande, indiquant, s'il y a lieu, les erreurs de traitement. La commande 'REMOVE FROM FAVORITE' permet à la carte (3) via le terminal (2) de retirer un favori du navigateur du terminal. Le champ de données de la commande comprend les paramètres indiquant le chemin d'accès du favori et son nom.
A la réception de la commande, si le paramètre indiquant le chemin d'accès au favoris est présent, le terminal (2) retire de son fichier de favoris, le sous fichier de favoris indiqué par ledit paramètre. De même, si le paramètre indiquant le nom du favori est présent, le terminal (2) retire du fichier de favoris le favori mentionné par le paramètre nom du favori. En fin d'exécution de la commande, le terminal (2) envoie un message via la commande 'PUT DATA' précisant le déroulement du traitement de la commande, indiquant, s'il y a lieu, les erreurs.
La commande [Epsilon]JECT CARD' permet à la carte (3) via le terminal, d'éjecter une carte d'un lecteur du terminal. Le champ de données envoyées par la carte (3) indique l'identificateur du lecteur dans lequel est insérée la carte à éjecter.
A la réception de cette commande le terminal (2) vérifie si le lecteur identifié existe et est disponible. Si ce lecteur n'existe pas ou n'est pas disponible le terminal (2) termine le traitement et envoie un message d'erreur à la carte (3) précisant l'erreur. Si le lecteur existe et est disponible, le terminal (2) vérifie si une carte est insérée dans le lecteur. Si ce n'est pas le cas, le terminal (2) termine le traitement et envoie un message d'erreur à la carte (3) précisant l'erreur. Si une carte est présente dans le lecteur, et qu'elle ne supporte pas la commande d'éjection, le terminal (2) termine le traitement et envoie un message d'erreur à la carte (3) précisant l'erreur. Si toutes les conditions sont réunies, le terminal (2) active le mécanisme d'éjection de la carte du lecteur mentionné par le paramètre identifiant de la commande.
Si ce paramètre est égal à la valeur hexadécimale '00' c'est la carte, émettrice des commandes qui est éjectée. En fin d'exécution de la commande, le terminal (2) envoie un message via la commande 'PUT DATA' précisant le déroulement du traitement de la commande, indiquant, s'il y a lieu, les erreurs.
La commande 'SWALLOW CARD' permet à la carte (3) via le terminal (2) de capturer une carte lorsque le terminal (2) est en phase de lecture de la carte à éjecter. Le champ de données de la commande comprend le paramètre identifiant le lecteur dans lequel est insérée la carte à éjecter. A la réception de la commande, le terminal (2) contrôle si le lecteur de carte identifié par le paramètre de la commande existe et est disponible. Si aucune de ces conditions n'est vérifiée, le terminal (2) met fin au traitement et envoie un message d'erreur à la carte.
Sinon, le terminal (2) contrôle ensuite si une carte est insérée dans le lecteur de carte. Si cette condition n'est pas vérifiée, le terminal (2) met fin au traitement et envoie un message d'erreur à la carte. Si le lecteur de carte ne supporte pas la capture d'une carte, le terminal (2) met fin au traitement et envoie un message d'erreur à la carte. Si toutes les conditions sont présentes, le terminal (2) active un mécanisme de capture d'une carte insérée dans le lecteur mentionné par le paramètre de la commande. Si ce paramètre est égal à la valeur hexadécimale '00', alors le lecteur concerné est celui comprenant la carte (3) envoyant des commandes.
En fin d'exécution de la commande, le terminal (2) envoie un message via la commande 'PUT DATA' précisant le déroulement du traitement de la commande, indiquant, s'il y a lieu, les erreurs.
La commande 'INSTALL APPLICATION' permet à la carte (3) Via le terminal (2) d'installer une nouvelle application sur ledit terminal. La localisation de l'application est définie par une URL mémorisée dans la carte (3) et l'application peut être stockée sur la carte (3) émettrice de la commande ou sur un autre média amovible ou sur un serveur distant. Le champ de données envoyé par la carte (3) comprend des paramètres obligatoires et des paramètres optionnels, dont le nom de l'application, la version de l'application, l'espace mémoire demandé pour installer l'application et l'URL.
A la réception de la commande, le terminal (2) vérifie par comparaison l'espace mémoire du terminal (2) nécessaire pour installer l'application avec l'espace mémoire indiqué dans les paramètres de la commande. Puis, le terminal (2) démarre le programme d'installation sur l'emplacement indiqué par l'URL, l'application à installer se trouvant soit sur un serveur distant ou sur un terminal (2) ou sur la carte (3) elle-même. C'est le terminal (2) qui décide si l'installation doit être installée ou non, incluant ainsi des considérations sécuritaires. Ces conditions sont vérifiées par comparaison entre la version de l'application déjà installée sur le terminal (2) avec la version définie dans les paramètres de la commande.
En fin d'exécution de la commande, le terminal (2) envoie un message via la commande 'PUT DATA' précisant le déroulement du traitement de la commande, indiquant, s'il y a lieu, les erreurs.
La commande 'PRINT DOCUMENT permet à la carte (3) de faire exécuter une impression au terminal. Le champ de données de la commande comprend les paramètres nécessaires au terminal (2) pour imprimer un document : un champ de texte non formaté, un champ de texte formaté, des paramètres d'impression, une imprimante destinataire, un paramètre de priorité d'impression. La figure 4 représente le traitement de la commande d'impression par le terminal. A la réception de la commande (étape 600), le terminal (2) mémorise les données à imprimer envoyées par la carte (3) dans une de ses mémoires tampons (601). Le terminal (2) vérifie tous les paramètres envoyés par la carte.
Si le paramètre 'texte à formater' est à l'état actif (602) par exemple à la valeur le terminal (2) va formater les données (603), ci-avant mémorisées, suivant un style précédemment envoyé par une autre commande. Le terminal (2) va vérifier si une imprimante destinataire est définie dans les paramètres de la commande (604). Si ce n'est pas le cas, l'imprimante sélectionnée pour l'impression sera l'imprimante par défaut (605). Dans le cas où une imprimante destinataire est définie (606) et que cette imprimante existe (607) dans le terminal, le terminal (2) sélectionnera ladite imprimante définie. Par contre si cette imprimante n'existe pas, le terminal (2) termine le traitement et envoie un message d'erreur à la carte (3) précisant l'erreur (étape 613), ici l'imprimante n'est pas disponible.
Si le terminal (2) n'a aucune donnée choisie par un de ses traitements (608), à imprimer, et que le paramètre d'impression immédiate envoyé par la commande est actif, le terminal (2) imprimera les données choisies par la carte (3) sur une imprimante définie ou sur l'imprimante par défaut (609, 613). Sinon, l'impression sera exécutée ultérieurement en même temps que les données choisies par terminal. Lors de l'impression des données choisies par le terminal (2) et à la carte, un paramètre concernant la priorité de l'impression va définir l'emplacement de ces deux types de données sur l'imprimante (610). Si le paramètre est actif, ce sont les données choisies par la carte (3) qui seront imprimées avant les données choisies par terminal (611). Si ce paramètre n'est pas actif, ce sont les données choisies par terminal (2) qui sont imprimées en premier (612).
En fin d'exécution de la commande, le terminal (2) envoie un message via la commande 'PUT DATA' précisant le déroulement du traitement de la commande, indiquant, s'il y a lieu, les erreurs.
La commande 'SELECT APPLICATION' permet à la carte (3) de savoir si le terminal (2) supporte une application quelconque d'un point de vue commercial, par exemple pour la gestion de points de fidélité. Un terminal (2) supportant une application n'a pas nécessairement le logiciel pour traiter une telle application avec la carte (3). Le champ de données de la commande comprend un paramètre indiquant l'identificateur de l'application. A la réception de la commande, le terminal (2) regarde dans sa liste d'applications supportées, si l'application est supportée ou non. Si elle n'est pas supportée le terminal (2) met fin au traitement et envoie un message d'erreur à la carte.
Si elle est supportée, le terminal (2) peut envoyer à la carte (3) un message contenant des informations sur l'utilisation de l'application, les informations étant propriétaires. En fin d'exécution de la commande, le terminal (2) envoie un message via la commande 'PUT DATA' précisant le déroulement du traitement de la commande, indiquant, s'il y a lieu, les erreurs.
La commande 'SEND MESSAGE' permet à la carte (3) par le biais du terminal (2) d'envoyer un message à une entité distante. Plusieurs services de messagerie peuvent être supportés par exemple, l'e-mail, le SMS, le MMS.
Les données envoyées par la carte relatives à ladite requête sont une adresse d'un serveur de messagerie, une adresse de messagerie de retour, un identifiant d'un compte de messagerie, un mot de passe.
La commande 'GET MESSAGE' permet à la carte (3) par le biais du terminal (2) de recevoir des messages d'une entité distante. Plusieurs services de messagerie peuvent être supportés par exemple, l'e-mail, le SMS, le MMS. La carte gère le protocole de connexion au serveur et de récupération des messages depuis les serveurs.
Les données envoyées par la carte relatives à ladite requête sont une adresse d'un serveur de messagerie, un identifiant d'un compte de messagerie, un mot de passe.
La commande 'SIGN DOCUMENT permet à la carte (3) via le terminal
(2) de commencer une procédure de signature électronique d'un document.
La procédure peut encapsuler des commandes de la carte (3) avec d'autres opérations de sécurité permettant par exemple l'affichage de ces documents en utilisant un numéro, type PIN, sécurisé.
II doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué.
Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et l'invention ne doit pas être limitée aux détails donnés ci-dessus. Annexe A
TS TO TC1 H1 H2 H3 H4 H5 H6 H7 H8 H9 HA HB HC HD
<EMI ID=20.1>
3B 4D 00 00 30 80 64 12 34 56 78 A1 00 05 90 00
Octets Valeurs Signification
TS 3B Convention directe
TO 4D Les 13 octets historiques sont présents
TC1 00 Pas de temps de protection
Un indicateur de statuts sera présent sur les trois
H1 00 derniers octets
H2 31 Etiquette données de service de la carte
H3 80 Octet données de service de la carte
H4 64 En tête de données émises
H5 à H8 12 34 56 78 Données émises
H9 A1 En tête supportant la version Robin
HA 00 Version Robin supportée
HB 05 Octet temps de cycle de vie de la
carte
<EMI ID=20.2>
HC à HD 90 00 Octets statut du traitement
Annexe B
Octet Signification
Octet définissant la version supportée, '00' pour la présente
1 invention
2 Type de terminal
3-4 Classe d'affichage
5-6 Classe d'impression
7-10 Commandes envoyées par la carte supportées par le terminal
11 Octet à utiliser
12 Connexions supportées par le terminal
<EMI ID=20.3>
13-14 Evénements supportés par le terminal Annexe C (Profil du terminal - classe de l'imprimante) Octet 1 (options texte de l'imprimante)
b8 b7 b6 b5 b4 b3 b2 b1 Signification
0 Le terminal a une imprimante non graphique
0 0 2 lignes ou moins
0 1 Plus de 2 lignes
1 0 Plus de 8 lignes
1 1 Plus de 16 lignes
0 0 8 caractères par ligne ou moins
0 1 Plus de 8 caractères par ligne
1 0 Plus de 16 caractères par ligne
1 1 Plus de 32 caractères par ligne
1 Supporte les Icons prédéfinis
1 Supporte le format texte
0 non défini
Octet 2 (options graphiques de l'imprimante) b8 b7 b6 b5 b4 b3 b2 b1 Signification
0 0 Petite résolution(strictement inférieur à 128*64)
0 1 Moyenne Résolution (128<*>64 ou plus)
1 0 Grande résolution (320<*>240 ou plus)
1 1 Très grande résolution (640<*>480 ou plus)
0 0 Noir et Blanc (2 couleurs)
0 1 Echelle de gris
1 0 16 couleurs ou moins
1 1 Plus de 16 couleurs
1 Supporte les fonts graphiques
<EMI ID=21.1>
0 0 0 Non définis
Annexe D (Paramètre P2 d'une commande)
b8 b7 b6 b5 b4 b3 b2 b1 Signification
Le traitement continue, si un défaut
1 de condition est rencontré
Le traitement s'arrête, si un défaut de
0 condition est rencontré
1 Réponse attendue par la carte
0 Pas de réponse attendue par la carte
<EMI ID=22.1>
0 0 0 0 0 0 RFU
Annexe E (Champ de données d'une commande PUT DATA terminal profil)
Octet Valeur
1 Numéro de la commande
2 - 3 Résultat de la commande
<EMI ID=22.2>
4 - n Informations supplémentaires envoyées par le terminal
Annexe F (Champ de données PUT DATA response terminal)
Octets Valeur
1 Numéro de la commande
2 - 3 Résultat de la commande
<EMI ID=22.3>
4 - n Informations supplémentaires envoyées par le terminal
Annexe G PUT DATA Terminal respond
Statut Signification
6F81 ERROR BROWSER CANNOT BE STARTED
6F82 ERROR C APDU FORMAT NOT VALID
6F83 ERROR CARD EJECTION NOT SUPPORTED
6F84 ERROR CARD MUTE
6F85 ERROR CARD NOT POWERED
6F86 ERROR CARD NOT PRESENT
6F87 ERROR CARD SWALLOW NOT SUPPORTED
6F88 ERROR CARD READER NOT AVAILABLE
6F89 ERROR COMMAND BEYON CAD CAPABILITIES
6F8A ERROR COMMANDREFUSED BY CAD
6F8B ERROR CURRENTLY UNABLE TO PROCESS COMMAND
6F8C ERROR DOCUMENT NOT AVAILABLE
6F8D ERROR EVENT NOT SUPPORTED
6F8E ERROR HTTP ERROR
6F8F ERROR NO ITEM SELECTED
6F90 ERROR SCREEN BUSY
6F91 ERROR SCREEN NOT AVAILABLE
6F92 ERROR STYLE ALREADY DEFINED
6F93 ERROR TIMEOUT
6F94 ERROR UNDEFINED STYLE
6<t>80 WARMING COMMAND PERFORMED
PARTIALY
<EMI ID=23.1>
9000 SUCCESSFUL COMPLETION
Protocol communication system between a smart card and a terminal and its communication method
The present invention relates to a protocol communication system between a smart card and a terminal, particularly a protocol communication system allowing an application integrated in a smart card to be executed by a terminal and the associated communication method.
It is known in the prior art terminals accepting smart cards, for example electronic payment terminals, cash dispensers, personal readers, health terminals. These terminals must be programmed for each application to be supported. Thus, if a card issuer wishes to launch a loyalty application, it will have to modify all the terminals of the park so that the cards can be read.
This procedure is very expensive, since it is necessary to write a specific software by terminal and by type of card, then install these software on each terminal of a park. Known technology, the SIM Application Toolkit allows a mobile subscriber card to display a menu specific to the telephony operator on any GSM terminal and perform some basic operations.
The disadvantage of this technology is that it does not target all types of terminals, it does not handle complex communications such as universal messaging, style sheets, printer management, multimedia, software installation. . . .
The purpose of the present invention is to overcome certain disadvantages of the prior art by proposing a communication system between a terminal and a smart card enabling the terminal to execute an application integrated in the smart card.
This purpose is achieved by a communication system between a terminal and a card characterized in that the card comprises a first application and the terminal comprises a second application and one or more card readers,
the first application and the second application enabling the system to perform the execution of a specific processing of the card by sending a request from the card to the terminal, the card adapting the first application according to the characteristics of the terminal and what the parameters sent by the card include means for the card to decide whether or not the execution of said request by the terminal if the latter encounters an anomaly in the conditions of execution of said request.
According to another particularity, the parameters sent by the card include a means allowing the terminal to respond or not to the card at the end of the execution of the request sent by the card to the terminal, if the execution of said request by the terminal was successful.
According to another particularity,
the first application implemented in the card is stored in a memory space of the card.
In another feature, the first application implemented in the card runs on a virtual machine adaptable to any type of card. According to another particularity, the virtual machine is of Java type or
Multos.
According to another particularity, the second application implemented in the terminal is an interpreter adaptable on any type of terminal.
Another object is achieved by a communication method of a communication system between a terminal and a card, the card comprising a first application and the terminal comprising a second application and one or more card readers,
said method is characterized in that it comprises a first method of identification of the first application implemented in the card and the second application implemented in the terminal and a second sub method for the transfer of requests and data sent by the card to the terminal.
According to another feature, the first sub method of identification comprises the following steps:
a step of initializing the card in a reader of the terminal, and sending a means identifying the first application implemented in the card. a step of detection by the terminal of the means identifying the first application representative of the first application implemented in the card, if the means identifying the first application does not exist the communication between the terminal and the card is normally carried out,
a step of sending a command comprising data relating to the characteristics of the terminal, if the terminal comprises the second application, said step enabling the card to detect the second application implemented in the terminal; if the terminal does not understand the application, the communication between the terminal and the card is normally carried out.
According to another particularity, a request sent by the card makes it possible to print data chosen by the card on a printer of the terminal, the data associated with this request representing at least one of the following parameters, a parameter identifying a printer recipient of the printing, an unformatted text string, a parameter identifying the formatting of a text, print parameters, a print priority parameter, the execution of this command by the terminal comprises at least one of the following steps:
a step makes it possible to store the data to be printed in a buffer memory of the terminal,
a step makes it possible to check whether the parameter provided by the card and identifying the formatting of a text exists, if it is the case the terminal executes the formatting of the data according to a format defined by the card,
a step allows to define the printer receiving print, if the parameter provided by the card and identifying a destination printer does not indicate a printer, a printer will be chosen by default, if the parameter identifying a printer recipient indicates a destination printer stored in the terminal, it is the destination printer will be chosen, in the latter case if this printer does not exist in the terminal, the terminal will complete the execution and will return an error message to the map,
a step allows the data chosen by the card to be printed immediately if the terminal has no data, chosen by it, to print and if the printing parameter provided by the card indicates an immediate impression, if this parameter indicates no immediate printing the data chosen by the card will be printed at the same time as data selected by the terminal, - a step allows to print the data chosen by the terminal before the data chosen by the card if the terminal wants print the data he has chosen and if the priority setting provided by the print card is active,
a step makes it possible to print the data chosen by the terminal after the data chosen by the card, if the terminal wants to print the data it has chosen and if the print priority parameter provided by the card is inactive,
- At the end of the print run the terminal sends a message indicating the progress of the execution. According to another particularity, a request sent by the card makes it possible to eject a card from a reader of the terminal, one of the data associated with this request being a parameter identifying the reader of the terminal in which the card to be ejected is located.
According to another particularity, a request sent by the card makes it possible to capture a card from a reader of the terminal, one of the data associated with this request being a parameter identifying the reader of the terminal in which the card to be ejected, the card to be eject can be the card including the application.
According to another particularity, a request sent by the card makes it possible to add a favorite in the favorites files of the terminal,
the data sent by the card relating to said request representing at least one of the following parameters, a parameter indicating a URL, a parameter presenting a path to the new favorite file and a parameter indicating the name of the new favorite.
According to another particularity, a request sent by the card makes it possible to remove a favorite from the favorites files of the terminal, the data sent by the card relating to said request having at least one of the following parameters, a parameter indicating a path the favorite file and a parameter indicating the name of the favorite to remove from the favorite file of the terminal.
According to another particularity, a request sent by the card makes it possible to install a new application in the terminal,
the data sent by the card relating to said request having at least one of the following parameters, an application name, a version of the application, a parameter indicating the memory space required for the installation of the application, a parameter indicating a URL where the program to install is located.
According to another particularity, a request sent by the card makes it possible to select a commercial program in the terminal, one of the parameters sent by the card relating to said request being a parameter identifying the commercial program to be selected and the terminal responding to the request according to it is or is not affiliated with the commercial program passed as parameter.
According to another particularity, a request sent by the card makes it possible to launch a complete procedure for electronically signing a document.
According to another particularity, a request sent by the card makes it possible to send messages to a remote device, the data sent by the card relating to said request having at least one of the following parameters, an address of a messaging server, an return e-mail address,
an identifier of an email account, a password.
According to another feature, a request sent by the card retrieves messages from a remote device, the data sent by the card relating to said request having at least one of the following parameters, an address of a mail server, a identifier of an email account, a password.
Other features and advantages of the present invention will appear more clearly on reading the description below, made with reference to the accompanying drawings, in which:
- Figure 1 shows a communication system between a terminal and a smart card, according to one embodiment of the present invention;
FIG. 2 represents a flowchart representative of the method of identification of the technology supported by the card and the terminal, according to an embodiment of the present invention;
FIG. 3 represents a flowchart representative of the communication method between the card and the terminal, according to a communication mode of the present invention; FIG. 4 represents a representative flowchart of the method of setting up a print command between the card and the terminal, according to a communication mode of the present invention;
FIG. 5 shows the representative diagram of a message allowing the card to send commands to the terminal;
FIG. 6 shows the representative diagram of a message following a known protocol enabling the terminal to send to the card or to retrieve data from the card.
Fig. 1 shows a communication system (1) using a communication method according to an embodiment of the present invention. Said system comprises a terminal (2) comprising a universal smart card reader (20) and a smart card (3) to be inserted into the reader (20) of the terminal (2). The smart card (3) comprises a first processing means (30), said application, intended to be executed by the terminal (2) and other application programs specific to a specific use of the card, for example a bank card or a health card.
The terminal (2) comprises pilot software (21) which is its own such as the display manager, it also comprises a second processing means (22), also called application or interpreter, for communicating in a master mode ( for the card) - slave (for the terminal) with all types of smart cards (3) including the first processing means (30). The interpreter of the terminal receives the requests sent by the card and executes them after reception. In order for the transmission of information between the terminal (2) and the card (3) to be carried out, the two terminal card elements must support the same technology. The two processing means (30, 22) use a common protocol to communicate with each other.
The present invention is applicable on any type of terminal (2) and smart card (3).
The communication protocol being standardized, the same means of processing works on all terminals, regardless of their brand, their model and their software version, for example, a PC computer connected to the Internet, a ticket machine, a payment terminal , a personal reader. A single chip card (3) comprising the application of the present invention can communicate as a master of different terminals also supporting the technology of the present invention. For example, a smart card, health card type comprising this application, can be inserted into a reader of a ticket machine also supporting the technology. The card (3) will ask by requests or orders addressed to the distributor to display or print, for example the social security number.
A user can thus view via the ticket distributor screen information other than the withdrawal or the balance of its accounts, this information from the smart card. Thus the card (3) controls the terminal with which it communicates by asking it to execute commands of the application implemented in the card. The smart card (3) adapts its application (30) to the type of terminal (2) with which it communicates. For example, a bank card supporting the application (30) will not give the same information to two different terminals each having a different profile. A terminal of the personal card reader type will display on request of the card (3) the amount of the last transactions, the balance of the account.
On the other hand a reader connected to a PC, itself connected to Internet, will make it possible to display the various aforementioned amounts, but also to open an Internet favorite containing the address of the bank issuing the card, to print data relating to the card (3) on the PC printer. The display of the amounts, the printing of data, the opening of an Internet favorite are commands requested by the card (3) and executed by the terminal.
The processing means (30) of the card (3) can be implemented hard in the card (3) by storing for example in a memory card (3). The processing means can also be implemented in the card (3) through the integration of a virtual machine, for example, JavaCard or Multos type, with the standard interfaces for the program application, called API.
The implementation of the technology of the present invention in a terminal (2) is also made by integration of a command interpreter. This type of interpreter has the advantage of including standardized functions applicable on any terminal. It is the application (30), different according to its use, integrated in the card (3) which differentiates the execution to be done by the terminal. The application (30) of the card (3) will adapt to the characteristics of the terminal (2) to make it execute a request.
It may be that a card (3) supporting the technology is used on a terminal (2) not supporting the technology or a card (3) not supporting the technology is used on a terminal (2) supporting technology.
In these cases, an identification method has been developed in order to preserve the technological compatibility between the card (3) and the terminal (2). The method includes a plurality of steps for defining whether the card (3) and the terminal (2) support the applications (30, 22). Figure 2 shows the method. Once the smart card (3) inserted in the reader (20) of a terminal (2) (step 40) or during the selection of an application of the card by the terminal or at any other time chosen by the card, the card sends to the terminal (2), via a message, an identifier means indicating whether or not it supports the technology of the present invention (step 41). Using this identifier means the terminal detects whether the card (3) supports the technology (step 42).
If the identifier means is not present the card (3) does not support the technology, the processing between the card (3) and the terminal (2) is normally or not done (step 45). In the opposite case (step 43), the card (3) waits for a response from the terminal (2). If the terminal (2) supports the technology, it sends to the card (3) data representative of its capabilities with respect to the technology of the present invention, thus indicating to the card (3) that it also supports this technology (step 46). In the opposite case (step 45), the terminal (2) does not send any characteristic data concerning it and the operation between the card (3) and the terminal (2) is carried out normally.
If the two entities, the card (3) and the terminal, support the technology, the card (3) can begin to send to the terminal (2) commands whose formats are defined below. The card (3) indicates to the terminal (2) the action it has to execute using the commands. The application of the present invention included in the card does not interfere with other application programs specific to the card. A more detailed description of the identification process is presented below.
According to a known method, as soon as the card (3) is inserted in the reader of the terminal (2) (step 40), the card (3) can send to it (step 41) a frame of bytes representative of the history of the map (3) thus indicating these operating characteristics.
It is also possible that when executing an application specific to the card and the terminal such as payment by credit card, the card returns to the terminal a response message including a data identifying the presence of the technology of the present invention. Appendix A shows, for example, the send frame during initialization of the communication. To indicate that it supports the application of the present invention, the card (3) must have a particular proprietary data referenced by a head identifier or primer, called, for example, H9 in Appendix A. This head identifier has a specific value, for example in Annex A, it is of hexadecimal value A1. The HA byte according to the H9 tag indicates whether the card (3) supports the application.
For example, referring to Appendix A, if the card (3) supports the application, this byte called HA will be present and will be hexadecimal 00.
If the byte identifying the existence of the application in the card, is present in the boot frame, the terminal, also supporting the technology, sends a command to the card (3) (step 46) accompanied by data indicating its profile, ie the characteristics supported by the terminal. For example, the terminal (2) is a PC or a ticket dispenser, including peripherals such as a printer. The command sent by the terminal (2) to the card (3) is named PUT DATA, indicating that the terminal (2) sends data to the card.
The PUT DATA command presenting the profile of the terminal, indicates that the terminal (2) supports the application (22) and also indicates its detailed characteristics. This command is used to inform the card (3) of the main characteristics of the terminal. The card (3) may request further details later by sending a command requesting terminal environment information.
The transmission of a message from the terminal (2) to the card (3) comprises a protocol standardized by the ISO, similar to the transmission of data from a GSM terminal to a SIM card. When sending data from the terminal (2) to the card, the terminal (2) transmits a frame comprising different fields. The frame is represented in FIG. The first field called CLA specifies the type of application, for example the sending of an order.
The second field called INS gives the instruction of the command, in this case the instruction is PUT DATA. The third field and the fourth field respectively called P1 and P2, specify, if necessary, the parameters of the instruction. The fifth field called Le specifies the length of the command or expected response. The sixth field provides the data to be transmitted if necessary. The seventh and last field called Le indicates the expected number of bytes in response. The data field attached to the PUT DATA command for sending a profile of the terminal comprises at least 14 bytes corresponding to the capabilities of the terminal (2) according to the technology of the present invention. This field is represented by a table in Appendix B.
This table indicates, among other things, the type of terminal (2) such as a PC or a ticket machine, a personal reader, the type of printer, the type of display, as well as the commands, connections and events that wants to support the terminal. For example, two bytes of the data field indicate the various parameters relating to the type of printer associated with the terminal. Appendix C represents these two bytes.
In response to the commands transmitted by the terminal, the card (3) sends a response frame according to the ISO 7816 protocol. FIG. 6 shows a representative diagram of the frame sent by the card (3) to the terminal. The two bytes, called SW1 and SW2, indicate, in general, the success or failure of the command. These first two fields can be accompanied or not by data.
In the case of the present invention, the field SW1 indicates whether the transmission between the card (3) and the terminal (2) is a normal transmission of information successfully or if the card (3) has commands to be executed by the terminal. In the latter case, the field SW2 gives the length of the bytes that the terminal (2) must recover. In a response signifying a positive acknowledgment of the card, the field SW1 has, for example, hexadecimal value '90' and the field SW2 has, for example, hexadecimal value '00'. In the second case, when the card (3) wants to send a command to the terminal, the field SW1 has, for example, hexadecimal value '62' and the field SW2 has, for example, a hexadecimal value indicating the number of bytes that the terminal (2) will have to recover.
FIG. 3 represents the method of communication between the card (3) and the terminal, when the card (3) sends a command to the terminal. As soon as the card (3) has received the PUT DATA command from the terminal (2) (step 47) indicating the characteristics of the terminal, the card (3) sends the state of the processing of the command in the response message comprising the bytes SW1 and SW2 (step 48). If the processing of the PUT DATA command is successful (step 51), the fields SW1 and SW2 of the response message are for example at the value '9000'. If the card (3) means to the terminal (2) that it has a request that it must withdraw and for which it waits for a response (step 50), the fields SW1 and SW2 have a different value and are for example to the hexadecimal value '62XY'.
In the example above, the query contains 'XY' bytes in hexadecimal value, 'XY' can be between the hexadecimal values '02' and '80'. The card (3) uses the bytes SW1 and SW2 as a command launch means, indicating that it wants to transmit a frame for which it is waiting for a response. In response to the request of the card, the terminal (2) sends a data recovery command preferably called GET DATA (step 50). The parameters P1 and P2 of said command are, for example, at the value '0000' and the parameter Le at the value 'XY'.
By return of response, the card (3) sends the command to the terminal (step 51), said command being transmitted by the data field located after the fields SW1 and SW2. A new test is then performed on the fields SW1 and SW2 sent by the card (3) to the terminal (2) (step 48).
If the fields SW1 and SW2 are at the value '62 XY ', the card (3) means that there is still a request for' XY 'bytes to be recovered (step 50) and to concatenate with the previous request before processing. these data by the terminal (2). If the fields SW1 and SW2 are at the value '9000', the card (3) means that the recovery command is successful and that the terminal (2) can process the data (step 52).
To send a command, the card (3) encapsulates the command and the data in the data field of the response preceding the bytes SW1 and SW2, as shown in FIG. A command includes the same fields as a terminal command. The first CLA field indicates the type of application, here the application is a command. The second INS field instructs, for example, to print the following data.
The fifth field indicates the size of the data sent. The sixth Data field gives the data or parameters needed to set up the command. In the previous example, this is the data to print. The third field and the fourth field P1 and P2 have a different utility compared to the parameter field of a command sent by the terminal. The field P1 indicates the index of the command, the index being a counter allowing the card (3) to adapt the responses of the terminal (2) with the commands sent. The index must be set to hexadecimal 00 at each new session. If the index is at the FF value, the next value is at 00. The P2 field indicates the command processing option. Appendix D is a table summarizing the usefulness of the different bits of P2 byte.
The two bits, b8 and b7, of the highest weight of the byte P2, are the most used. If the bit b8 of the byte P2 is at the logic value '0', the terminal (2) must stop the processing of the command, as soon as one of the conditions of the processing is not present. If the bit is at the logical value, the terminal (2) tries to continue processing despite a missing condition. When this command can not be processed, the terminal (2) can send an alarm in the response field of the command. If the terminal (2) can not continue processing, an error is sent. If the bit b7 of the P2 field is at the logic value '0', the terminal (2) must not send a response to the card when the processing has been completed successfully. This bit b7 prevents unnecessary dialogues between the card (3) and the terminal.
The other bits, b6 to b1, of the P2 byte are available for all functions not yet defined. The various commands used by the technology of the present invention are presented in the following description.
To transmit a response to the card (3) concerning a command, the terminal (2) sends a 'PUT DATA' response command followed by the response data (step 53 of FIG. 3). If the answer is too long for a simple command, a command string is applied. The response data field has at least three bytes. The first byte indicates the number of the command to which the terminal (2) responds, the second byte and third byte indicate the result status of the execution of the command. The following bytes are additional information sent by the terminal.
A status byte equal, for example, to the hexadecimal value '9000', indicates that the execution of the command by the terminal (2) is a success. Appendix F represents the different values of this status byte with their meanings. The card (3) responds to the last PUT DATA command by the SW1-SW2 bytes presented above.
The card (3) can request the terminal (2) to send him information about an event, so that it can execute a request to the terminal.
The various events transmitted by the terminal (2) to the card (3) indicate for example that the terminal (2) is going to be online, that a key has been pressed, that a document will be printed, that the card ( 3) will be ejected, the card (3) will be swallowed, the card (3) has been inserted / removed in another reader, or a connection to a remote resource has logged an event. This event information request is made through an interrupt command preferably called 'SET INTERRUPT'.
The notification command of an event sent by the terminal (2) to the card (3) is called [Epsilon] NVELOPE '.
The Sim Toolkit system also makes it possible to send commands from a SIM card to a terminal (2) GSM, such as the display of data chosen by the card on the terminal screen, the activation of a device. control of the card upon receipt of an event. The system of the present invention, adaptable on any terminal, encompasses all commands already implemented by the GSM device, but also requires new commands to operate. These new orders are presented below.
The command 'ADD TO FAVORITES' allows the card (3) to add a new address of a remote resource such as Internet or WAP, in the terminal browser. This address is called favorite in the following description.
The command includes the fields described above: 'CLA', 'INS', 'P1 \' P2 ',' The 'and the data field. This last field includes information or parameters relating to the order such as the name given to the favorite, the URL of the favorite, the path of the subfile of the favorite, the latter information being mandatory. This information is detectable in the data field by a locating means such as a label having a specific value, Appendix D shows an example of the tag values. For example, referring to the appendix, the label representing the name of the favorite is of hexadecimal value 'DF10'.
On receipt of the 'ADD TO FAVORITE' command, the terminal (2) adds to the browser's favorite files the URL mentioned in the 'URL' parameter, in the favorite sub-file mentioned by the path of the browser. favorite, said favorite appearing to the user under the name mentioned by the parameter 'Name of the favorite'. At the end of the execution of the command, the terminal (2) sends a message via the 'PUT DATA' command specifying the progress of the processing of the command, indicating, if necessary, the processing errors. The 'REMOVE FROM FAVORITE' command allows the card (3) via the terminal (2) to remove a favorite from the terminal browser. The data field of the command includes the parameters indicating the path of the favorite and its name.
Upon receipt of the command, if the parameter indicating the path to the favorites is present, the terminal (2) removes from its favorites file, the sub-favorites file indicated by said parameter. Likewise, if the parameter indicating the name of the favorite is present, the terminal (2) removes from the favorites file the favorite mentioned by the parameter name of the favorite. At the end of the execution of the command, the terminal (2) sends a message via the 'PUT DATA' command specifying the progress of the processing of the command, indicating, if necessary, the errors.
The command [Epsilon] JECT CARD 'allows the card (3) via the terminal, to eject a card from a reader of the terminal. The data field sent by the card (3) indicates the identifier of the reader in which the card to be ejected is inserted.
Upon receipt of this command the terminal (2) checks whether the identified reader exists and is available. If this reader does not exist or is not available, the terminal (2) terminates the processing and sends an error message to the card (3) specifying the error. If the reader exists and is available, the terminal (2) checks whether a card is inserted into the reader. If this is not the case, the terminal (2) terminates the processing and sends an error message to the card (3) specifying the error. If a card is present in the reader, and it does not support the ejection command, the terminal (2) ends the processing and sends an error message to the card (3) specifying the error. If all the conditions are met, the terminal (2) activates the ejection mechanism of the reader card mentioned by the identifier parameter of the command.
If this parameter is equal to the hexadecimal value '00' it is the card issuing the commands which is ejected. At the end of the execution of the command, the terminal (2) sends a message via the 'PUT DATA' command specifying the progress of the processing of the command, indicating, if necessary, the errors.
The command 'SWALLOW CARD' allows the card (3) via the terminal (2) to capture a card when the terminal (2) is in the reading phase of the card to be ejected. The data field of the command includes the parameter identifying the reader in which the card to be ejected is inserted. Upon receipt of the command, the terminal (2) controls whether the card reader identified by the command parameter exists and is available. If neither of these conditions is verified, the terminal (2) terminates the processing and sends an error message to the card.
Otherwise, the terminal (2) then checks whether a card is inserted in the card reader. If this condition is not verified, the terminal (2) terminates the processing and sends an error message to the card. If the card reader does not support the capture of a card, the terminal (2) terminates the processing and sends an error message to the card. If all the conditions are present, the terminal (2) activates a mechanism for capturing a card inserted in the reader mentioned by the parameter of the command. If this parameter is equal to the hexadecimal value '00', then the reader concerned is the one comprising the card (3) sending commands.
At the end of the execution of the command, the terminal (2) sends a message via the 'PUT DATA' command specifying the progress of the processing of the command, indicating, if necessary, the errors.
The command 'INSTALL APPLICATION' allows the card (3) Via the terminal (2) to install a new application on said terminal. The location of the application is defined by a URL stored in the card (3) and the application can be stored on the card (3) issuing the command or on another removable media or on a remote server. The data field sent by the card (3) includes mandatory parameters and optional parameters, including the name of the application, the version of the application, the memory space required to install the application and the URL.
Upon receipt of the command, the terminal (2) comparatively checks the memory space of the terminal (2) necessary to install the application with the memory space indicated in the command parameters. Then, the terminal (2) starts the installation program on the location indicated by the URL, the application to be installed either on a remote server or on a terminal (2) or on the map (3) it -even. It is the terminal (2) that decides whether the installation should be installed or not, thus including security considerations. These conditions are verified by comparison between the version of the application already installed on the terminal (2) with the version defined in the parameters of the command.
At the end of the execution of the command, the terminal (2) sends a message via the 'PUT DATA' command specifying the progress of the processing of the command, indicating, if necessary, the errors.
The 'PRINT DOCUMENT' command allows the card (3) to print the terminal. The data field of the command includes the parameters necessary for the terminal (2) to print a document: an unformatted text field, a formatted text field, print parameters, a destination printer, a priority parameter of impression. Figure 4 shows the processing of the print command by the terminal. On receipt of the command (step 600), the terminal (2) stores the data to be printed sent by the card (3) in one of its buffers (601). The terminal (2) checks all the parameters sent by the card.
If the parameter 'text to format' is in the active state (602) for example at the value the terminal (2) will format the data (603), previously stored, in a style previously sent by another command. The terminal (2) will check if a destination printer is defined in the parameters of the command (604). If this is not the case, the printer selected for printing will be the default printer (605). In the case where a destination printer is defined (606) and this printer exists (607) in the terminal, the terminal (2) will select said defined printer. On the other hand, if this printer does not exist, the terminal (2) terminates the processing and sends an error message to the card (3) specifying the error (step 613), here the printer is not available.
If the terminal (2) has no data chosen by one of its processes (608) to print, and the immediate printing parameter sent by the command is active, the terminal (2) will print the data chosen by the card (3) on a defined printer or on the default printer (609, 613). Otherwise, printing will be performed later at the same time as the data chosen by the terminal. When printing the data selected by the terminal (2) and the card, a parameter concerning the priority of the print will define the location of these two types of data on the printer (610). If the parameter is active, the data chosen by the card (3) will be printed before the data chosen by the terminal (611). If this parameter is not active, the data selected by terminal (2) is printed first (612).
At the end of the execution of the command, the terminal (2) sends a message via the 'PUT DATA' command specifying the progress of the processing of the command, indicating, if necessary, the errors.
The command 'SELECT APPLICATION' allows the card (3) to know if the terminal (2) supports any application from a commercial point of view, for example for the management of loyalty points. A terminal (2) supporting an application does not necessarily have the software to process such an application with the card (3). The data field of the command includes a parameter indicating the identifier of the application. Upon receipt of the command, the terminal (2) looks in its list of supported applications, whether the application is supported or not. If it is not supported the terminal (2) terminates the processing and sends an error message to the card.
If it is supported, the terminal (2) can send to the card (3) a message containing information on the use of the application, the information being proprietary. At the end of the execution of the command, the terminal (2) sends a message via the 'PUT DATA' command specifying the progress of the processing of the command, indicating, if necessary, the errors.
The command 'SEND MESSAGE' allows the card (3) through the terminal (2) to send a message to a remote entity. Several messaging services can be supported for example, e-mail, SMS, MMS.
The data sent by the card relating to said request is an address of a mail server, a return e-mail address, an identifier of an e-mail account, a password.
The command 'GET MESSAGE' allows the card (3) through the terminal (2) to receive messages from a remote entity. Several messaging services can be supported for example, e-mail, SMS, MMS. The card supports the protocol for connecting to the server and retrieving messages from the servers.
The data sent by the card relating to said request is an address of a mail server, an identifier of an email account, a password.
The 'SIGN DOCUMENT' command allows the card (3) via the terminal
(2) to begin an electronic signature procedure of a document.
The procedure can encapsulate commands of the card (3) with other security operations allowing for example the display of these documents by using a number, type PIN, secure.
It should be obvious to those skilled in the art that the present invention allows embodiments in many other specific forms without departing from the scope of the invention as claimed.
Therefore, the present embodiments should be considered by way of illustration, but may be modified within the scope defined by the scope of the appended claims, and the invention should not be limited to the details given above. Annex A
TS TO TC1 H1 H2 H3 H4 H5 H6 H7 H8 H9 HA HB HC HD
<EMI ID = 20.1>
3B 4D 00 00 30 80 64 12 34 56 78 A1 00 05 90 00
Bytes Values Meaning
TS 3B Direct Convention
TO 4D The 13 historical bytes are present
TC1 00 No protection time
A status indicator will be present on all three
H1 last 00 bytes
H2 31 Label service data of the card
H3 80 Byte card service data
H4 64 Top of data emitted
H5 to H8 12 34 56 78 Issued data
H9 A1 Leading the Robin version
HA 00 Robin version supported
HB 05 octet life cycle time of the
map
<EMI ID = 20.2>
HC to HD 90 00 Bytes Treatment Status
Appendix B
Octet Meaning
Byte defining the supported version, '00' for the present
1 invention
2 Terminal type
3-4 Display class
5-6 Print Class
7-10 Terminal Sent Card Commands Supported by the Terminal
11 Byte to use
12 Connections supported by the terminal
<EMI ID = 20.3>
13-14 Events Supported by the Terminal Appendix C (Terminal Profile - Printer Class) Byte 1 (Printer Text Options)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 The terminal has a non-graphic printer
0 0 2 lines or less
0 1 More than 2 lines
1 0 More than 8 lines
1 1 More than 16 lines
0 0 8 characters per line or less
0 1 More than 8 characters per line
1 0 More than 16 characters per line
1 1 More than 32 characters per line
1 Supports pre-defined Icons
1 Supports text format
0 undefined
Byte 2 (printer graphic options) b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 Small resolution (strictly less than 128 * 64)
0 1 Medium Resolution (128 <*> 64 or more)
1 0 High resolution (320 <*> 240 or more)
1 1 Very high resolution (640 <*> 480 or more)
0 0 Black and White (2 colors)
0 1 Scale of gray
1 0 16 colors or less
1 1 More than 16 colors
1 Supports graphic fonts
<EMI ID = 21.1>
0 0 0 Not defined
Appendix D (Parameter P2 of an order)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
The treatment continues, if a defect
1 of condition is met
The processing stops, if a defect of
0 condition is met
1 Answer expected by the map
0 No answer expected by the card
<EMI ID = 22.1>
0 0 0 0 0 0 RFU
Appendix E (Data Field of a PUT DATA Terminal Profile Command)
Value Byte
1 Order number
2 - 3 Result of the order
<EMI ID = 22.2>
4 - n Additional information sent by the terminal
Annex F (PUT DATA response terminal data field)
Bytes Value
1 Order number
2 - 3 Result of the order
<EMI ID = 22.3>
4 - n Additional information sent by the terminal
Annex G PUT DATA Terminal respond
Status Meaning
6F81 ERROR BROWSER CAN NOT BE STARTED
6F82 ERROR C APDU NOT VALID FORMAT
6F83 ERROR CARD EJECTION NOT SUPPORTED
6F84 ERROR CARD MUTE
6F85 ERROR CARD NOT POWERED
6F86 ERROR CARD NOT PRESENT
6F87 ERROR CARD SWALLOW NOT SUPPORTED
6F88 ERROR CARD READER NOT AVAILABLE
6F89 ERROR COMMAND BEYON CAD CAPABILITIES
6F8A ERROR COMMANDREFUSED BY CAD
6F8B ERROR CURRENTLY UNABLE TO PROCESS COMMAND
6F8C ERROR DOCUMENT NOT AVAILABLE
6F8D ERROR EVENT NOT SUPPORTED
6F8E ERROR HTTP ERROR
6F8F ERROR NO ITEM SELECTED
6F90 ERROR SCREEN BUSY
6F91 ERROR SCREEN NOT AVAILABLE
6F92 ERROR STYLE ALREADY DEFINED
6F93 ERROR TIMEOUT
6F94 ERROR UNDEFINED STYLE
6 <t> 80 WARMING COMMAND PERFORMED
Partialy
<EMI ID = 23.1>
9000 SUCCESSFUL COMPLETION