FR2757664A1 - Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede - Google Patents

Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede Download PDF

Info

Publication number
FR2757664A1
FR2757664A1 FR9615997A FR9615997A FR2757664A1 FR 2757664 A1 FR2757664 A1 FR 2757664A1 FR 9615997 A FR9615997 A FR 9615997A FR 9615997 A FR9615997 A FR 9615997A FR 2757664 A1 FR2757664 A1 FR 2757664A1
Authority
FR
France
Prior art keywords
terminal
self
data
portable object
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR9615997A
Other languages
English (en)
Other versions
FR2757664B1 (fr
Inventor
Ronan Lapie
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CP8 Transac
Bull CP8 SA
Original Assignee
CP8 Transac
Bull CP8 SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR9615997A priority Critical patent/FR2757664B1/fr
Application filed by CP8 Transac, Bull CP8 SA filed Critical CP8 Transac
Priority to CN97192506A priority patent/CN1212065A/zh
Priority to BR9707597A priority patent/BR9707597A/pt
Priority to KR1019980706599A priority patent/KR19990087204A/ko
Priority to PCT/FR1997/002388 priority patent/WO1998028720A1/fr
Priority to EP97952981A priority patent/EP0907937A1/fr
Priority to JP10528479A priority patent/JPH11504748A/ja
Priority to CA002247474A priority patent/CA2247474A1/fr
Priority to ARP970106133A priority patent/AR009843A1/es
Priority to AU56682/98A priority patent/AU723514B2/en
Priority to US09/125,714 priority patent/US6253163B1/en
Publication of FR2757664A1 publication Critical patent/FR2757664A1/fr
Priority to NO983851A priority patent/NO983851L/no
Application granted granted Critical
Publication of FR2757664B1 publication Critical patent/FR2757664B1/fr
Priority to US09/827,905 priority patent/US6505144B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0833—Card having specific functional components
    • G07F7/084—Additional components relating to data transfer and storing, e.g. error detection, self-diagnosis

Landscapes

  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Terminal doté d'un programme d'application, d'au moins une sortie constitué soit par un affichage, soit par une imprimante, soit par un réseau de communication, soit par un objet portable et coopérant avec un objet portable doté d'une zone de mémoire non-volatile (ZD) contenant des données et comportant un lecteur communiquant avec ledit objet portable, caractérisé en ce que l'appareil comporte des moyens de lecture ou de stockage dans sa mémoire de données (Ti, Dj, Sk) d'autodiagnostic ou de supervision et un moyen d'émission desdites données vers des sorties (1-4) spécifiées en fonction d'informations fournies par les données d'autodiagnostic ou de supervision suite à l'exécution d'au moins une tâche (Tt) de son programme d'application en relation avec l'objet portable.

Description

TERMINAL ET PROCEDE D'AUTODIAGNOSTIC OU DE SUPERVISION
ET OBJET PORTATIF UTILISE DANS UN TEL TERMINAL OU PROCEDE
La présente invention concerne un terminal et un procédé d'autodiagnostic ou de supervision et l'objet portatif de type carte à microcircuit utilisé dans un tel procédé ou terminal ou lecteur. Ces objets comportent une Unité
Centrale, une mémoire programme contenant du code exécutable constituant le système d'exploitation, une mémoire de donnée non volatile et programmable et, une ou plusieurs interfaces de communication. Les terminaux sont des appareils dotés d'une interface compatible avec celles des objets, ils possèdent une Unité centrale et un logiciel capable de communiquer et d'exploiter les données provenant de la mémoire non volatile de l'objet portable.
En général, les terminaux sont équipés d'un logiciel spécifique correspondant à leur utilisation, par exemple, les terminaux portables de paiement sont dotés d'un programme d'exploitation de type bancaire. Ce logiciel est réalisé ou spécifié par l'organisme qui gère cette application, dans l'exemple cité, c'est un organisme bancaire. Cet organisme n'est généralement pas le fabricant du terminal, il achète ou fait fabriquer la partie matérielle c'est-à-dire le terminal, il y introduit le programme spécifique afin de configurer son terminal pour sa propre application. L'organisme bancaire y trouve son avantage en achetant un produit standard donc bon marché, et en l'adaptant selon ses besoins. Le fabricant propose un modèle de base qui peut convenir à plusieurs applications, ce qui lui permet d'étendre son marché.
L'organisme exploitant une application donnée peut désirer disposer de plusieurs modèles de terminaux lecteurs de cartes, il n'est pas souhaitable de développer des logiciels applicatifs pour chaques terminaux. Ce qui a conduit les fabricants à implémenter une couche logicielle de base qui assure l'interface entre le matériel et le logiciel applicatif. Cette couche logicielle assure l'adaptation entre un même logiciel applicatif et des terminaux différents. Une façon de faire consiste à créer un interpréteur, de telle sorte que l'organisme peut développer son application en langage évolué bien connu et ceci quasiment indépendamment des contraintes du matériel. Une autre façon de faire est d'organiser une couche logicielle de bas niveau qui gère toutes les entrées sorties matérielles et, à mettre à la disposition de l'organisme exploitant une bibliothèque de primitives que le logiciel applicatif va appeler.
Dans tous les cas, on doit être en mesure de valider ou de tester le terminal dans son ensemble. La validation ou le test du terminal doit prendre en compte les deux parties : le matériel avec son logiciel de base et le logiciel d'application. Un auto-test permet de vérifier chaque équipement du terminal, il est généralement constitué d'une routine implémentée dans le logiciel de base. Le test du logiciel d'application doit être réalisé en laboratoire, il est important dans ce type d'application de bien vérifier le fonctionnement du programme avant sa mise en service. Toutefois, la multiplicité des cartes entraîne un très grand nombre de cas particuliers non reproductibles en laboratoire. L'invention suivante a pour but de valider ou tester en conditions normales d'utilisation le fonctionnement d'un logiciel d'application.
A cet effet, I'invention concerne un terminal doté d'un programme d'application, d'au moins une sortie constituée soit par un affichage, soit par une imprimante, soit par un réseau de communication, soit par un objet portable et coopérant avec un objet portable doté d'une zone de mémoire non-volatile contenant des données et comportant un lecteur communiquant avec ledit objet portable, caractérisé en ce que l'appareil comporte des moyens de lecture ou de stockage dans sa mémoire de données de diagnostic ou de supervision et un moyen d'émission desdites données vers des sorties spécifiées en fonction d'informations fournies par les données d'autodiagnostic ou de supervision suite à l'exécution d'au moins une tâche de son programme d'application en relation avec l'objet portable.
Selon une autre caractéristique, les moyens d'émission des données d'autodiagnostic sont activés un certain nombre de fois.
Selon une autre caractéristique, les moyens d'émission des données d'autodiagnostic ou de supervision comporte des moyens d'écriture dans l'objet portable connecté à l'appareil.
Selon une autre caractéristique, les données d'autodiagnostic ou de supervision sont constituées par au moins un triplet d'information correspondant pour une première information à une tâche déterminée du programme d'application, pour la seconde information à un type de données corrélées à la tâche exécutée et à présenter à une sortie, et pour la troisième information à une valeur de spécification de la sortie à laquelle le type de données doit être présenté parmi celles présentes sur le terminal.
Selon une autre caractéristique, I'appareil dispose d'un moyen de test de la présence de données d'autodiagnostic ou de supervision dans un objet portable et de déclencher la lecture et le stockage de ces données dans une zone spécifique ZTD de la mémoire du terminal.
Selon une autre caractéristique, le terminal comporte des moyens d'introduction de données d'autodiagnostic ou de supervision dans un objet portable.
Un autre but de l'invention est de proposer un procédé de supervision du fonctionnement d'un terminal ou d'autodiagnostic d'un terminal.
Ce but est atteint par le fait que le procédé d'autodiagnostic ou de supervision à partir d'au moins un triplet d'information correspondant pour une première information à une tâche déterminée d'un programme d'application exécuté soit par un objet portable soit par un terminal, pour la seconde information à un type de données corrélées à la tâche exécutée et à présenter sur une sortie et pour la troisiéme information à une valeur de spécification de la sortie parmi celles présentes sur le terminal se caractérise en ce qu'il consiste: à à exécuter une tâche du programme d'application sur le terminal - à tester un indicateur soit dans le terminal soit dans l'objet portable pour déterminer si une fonction d'autodiagnostic ou de supervision est opérationnelle, puis dans le cas d'une réponse positive - à rechercher dans la mémoire soit de l'objet portable soit du terminal s'il existe parmi les triplets d'information stockés un triplet dont la première information correspond à la tâche déterminée exécutée par le terminal ou la carte; - à émettre vers la sortie spécifiée par le triplet ainsi lu la valeur de la donnée corrélée à la tâche exécutée et à référencer par la seconde information du triplet.
Selon une autre particularité, le procédé comporte une étape de test consistant à déterminer s'il existe d'autres tâches à exécuter et à la suite de l'exécution de ces tâches à rechercher tous les triplets d'information correspondants à l'exécution de cette tâche.
Selon une autre particularité, le procédé comporte une étape de lecture d'un objet portable mémorisant dans sa mémoire non-volatile une pluralité de triplets et une étape de stockage de ces triplets dans une zone de mémoire non-volatile du terminal suivie d'une étape d'activation d'un indicateur de fonction d'autodiagnostic ou de supervision active.
Selon une autre particularité, le procédé comporte une étape de test pour déterminer si l'objet portable est une carte spécifique à la fonction d'autodiagnostic ou de supervision ou une carte dite banale.
Selon une autre particularité, les données d'autodiagnostic ou de supervision sont constituées par un quatrième champ d'information contenant, au départ dans l'objet portable l'adresse d'écriture (Adr-V), le nombre d'octets à écrire (Nb-V), après l'opération d'autodiagnostic la valeur à écrire (Val).
Un autre but de l'invention est de proposer un objet portable utilisable avec le terminal et le procédé d'autodiagnostic ou de supervision.
Ce but est atteint par le fait que l'objet portable est une carte à microprocesseur fonctionnant grâce à un système d'exploitation mémorisé sur la carte et comportant une mémoire non-volatile contenant au moins un triplet d'information dans une zone déterminée de cette mémoire non-volatile dont la position est définie par des champs d'adresse situés dans la partie de mémoire servant à stocker le système d'exploitation.
Selon une autre particularité, la partie de mémoire non-volatile servant à mémoriser le système d'exploitation comporte également dans un champ mémoire une information constituant un compteur d'utilisation de la fonction d'autodiagnostic.
Selon une autre particularité, la zone mémoire stockant le système d'exploitation comporte un champ permettant de mémoriser un indicateur d'activation de la fonction d'autodiagnostic ou de supervision.
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 est un tableau explicatif des triplets constitués des tâches élémentaires, des types de données et des types de sorties que l'on peut associer à l'exécution de chacune des tâches d'un programme d'application; la figure 2 est un schéma des zones mémoire non-volatile utilisées sur un objet portable de test nécessaire à la mise en oeuvre du procédé de l'invention la figure 3 représente les différentes étapes d'exécution des programmes d'initialisation du terminal et d'exécution de la fonction d'autodiagnostic; la figure 4 représente une vue schématique des zones de stockage des informations dans la mémoire non-volatile d'un objet portable dit banal la figure 5 représente les différentes étapes d'exécution d'un programme d'initialisation du terminal et d'exécution de la fonction d'autodiagnostic sur ce terminal avec une carte dite banale.
Une manière de réaliser l'invention consiste dans une première variante, d'une part à utiliser une carte à microprocesseur fonctionnant grâce à un système d'exploitation mémorisé sur la carte et constituant une "carte à puce dite intelligente" qui est préalablement initialisée avec des données d'autodiagnostic, d'autre part à faire prendre en compte ces données par le terminal dont on veut tester le logiciel d'application.
Un logiciel d'application dans un terminal peut se décomposer en tâches élémentaires qui se succèdent à des moments déterminés. Par exemple, pour une application bancaire, on peut décomposer une transaction par les tâches élémentaires (Ti) suivantes : Vérification (T1, Fig. 1) si la carte introduite est habilitée, Authentification (T2) du porteur, Acquisition (T3) des données de la transaction dans le terminal, Inscription de ces données dans le microcircuit de la carte, Validation (T4) de la transaction dans le terminal et la carte.
D'autres part et toujours lors d'une transaction, le logiciel d'application manipule des données, ces données peuvent être utilisées temporairement comme, d'une part le Code élaboré par le porteur (Cp) qui est stocké dans la mémoire du terminal, d'autre part l'identité du porteur (Ip) qui est stockée dans la carte ou encore comme le Montant de la transaction (Mt) ou la Date de la transaction (Dt) qui sont stockés dans le terminal et la carte. Lors de l'exécution de chaque tâche élémentaire, chacune de ces données peuvent être initialisées, modifiées ou inchangées. La fonction d'autodiagnostic d'utilisation du logiciel d'application consiste à contrôler les données de la transaction au moment de certaines tâches et ceci dans des conditions normales d'utilisation. Cette fonction peut être réalisée soit par le logiciel de base, soit par le logiciel d'application;
Pour ce faire, I'opérateur chargé du contrôle élabore une grille composée d'un coté des tâches élémentaires identifiables notées Ti et de l'autre coté, des données Dj constituées par les informations telles que: Cp, Ip, Mt et Dt.
La figure 1 montre un exemple d'une telle grille. Pour contrôler le déroulement correct d'une transaction, I'opérateur choisit de vérifier la valeur de certaines données lors de l'exécution de tâches bien précises. Cela revient à associer une donnée Dj à une tâche Ti, ces associations sont symbolisées par des croix sur la grille de la figure 1. Un troisième élément d'information Sk est rajouté. La valeur de ce code précise le type de sortie utilisée pour émettre la donnée à contrôler: vers le réseau lorsque Sk est à une première valeur par exemple "1" (Sk = 1), vers l'imprimante lorsque Sk est à une deuxième valeur par exemple "2" (Sk = 2), ou vers l'écran lorsque
Sk est à une troisième valeur par exemple "3" (Sk = 3). L'opérateur introduit les triplets d'information (Ti, Dj, Sk) dans une unité centrale spéciale dite de diagnostic, cette unité centrale est dotée d'un lecteur de carte. Le logiciel de diagnostic est configuré selon l'application à tester de telle sorte que les triplets (Ti, Dj, Sk) sont identifiés lors de la saisie sur écran par l'indication précise des tâches élémentaires et des données à contrôler et non les références numériques Ti, Dj, Sk...
La carte contenant les données d'autodiagnostic est : soit une carte spéciale, soit une carte banale utilisée couramment pour une application.
Une description détaillée d'une réalisation est donnée pour chaque cas.
Décrivons tout d'abord le cas où une carte spéciale dite "carte de test" (20,
Fig. 2) est utilisée pour contenir les données d'autodiagnostic. Une procédure sécuritaire est mise en oeuvre pour éviter qu'un fraudeur puisse se servir d'une telle carte de façon non autorisée. La carte de test contient, dans la zone mémoire secrète non représentée, un code secret dit de diagnostic "KD" Ce code secret doit être préalablement présenté à la carte qui le vérifie et, s'il est égal à un code de référence, autorise l'écriture des données d'autodiagnostic dans la mémoire programmable de la carte.
En prévision du stockage des données d'autodiagnostic, la mémoire programmable non volatile de la carte de test possède en plus de la zone système ZS contenant le système d'exploitation de la carte et de la zone (AZU autre zone utilisable) permettant d'autres mémorisations, une zone (22) appelée "ZD" C'est dans cette zone que sont stockés successivement les triplets (Ti, Dj, Sk). Ainsi une première zone (220) d'une mémoire permet le stockage du premier triplet T1, D2, 1; une deuxième zone (221) permet le stockage du deuxième triplet T2, Dl, 2 ; une troisième zone (222) permet le stockage du troisième triplet T3, D3, 1; une quatrième zone (223) permet le stockage du quatrième triplet D4, D3, 3 ; une cinquième zone (224) permet le stockage du triplet T4, D4, 1; TI, T2, T3, T4, D1, D2, D3, D4 représentant respectivement les informations de la figure 1. Il est bien évident que l'objet portable peut comporter plus ou moins de triplet selon le type de supervision ou d'autodiagnostic que l'on veut effectuer sur les tâches exécutées par le programme d'application. La zone ZD est repérée par son adresse de début : "ADDZD" et son adresse de fin "ADF-ZD", les deux valeurs d'adresse sont stockées dans la partie (230, 231) de la mémoire programmable allouée au système d'exploitation.
La mémoire programmable non volatile est de type EPROM, EEPROM,
FeRAM, SRAM ou FLASH. La figure 2 décrit l'organisation de cette mémoire en reprenant les informations citées par la figure 1. Avantageusement, la donnée Dj est l'adresse physique de la donnée à contrôler dans la mémoire de travail du terminal.
Une fois programmée, la carte de test est introduite dans le terminal dans lequel doit se dérouler la fonction d'autodiagnostic. La figure 3 est un organigramme illustrant la chronologie des événements du programme constituée d'une séquence d'attente et de test (1, 2, 3), le test déclenchant en fonction du résultat soit une séquence de chargement (4 à 7, Fig. 3) du terminal avec les données d'autodiagnostic, soit une séquence d'exécution du programme d'autodiagnostic (8 à 16, Fig. 3) qui est incorporé soit dans le logiciel de base du terminal, soit dans le logiciel d'application. L'étape 1 est l'initialisation du terminal après une mise sous tension et l'étape 2 est la phase d'attente d'un ordre ou d'une introduction de carte. A l'étape 3, le terminal teste si la carte introduite dans le lecteur est une carte banale, et à l'étape 4 si la carte est une carte de test. Dans ce dernier cas, le terminal exécute à l'étape 5 une procédure d'authentification de la carte par un code de référence ou, par un schéma classique d'authentification challengeréponse utilisant un algorithme et une clé secrète (KD).
Une fois la carte de test identifiée et authentifiée, le programme du terminal lit à l'étape 6 les informations contenues dans la zone ZD. La sélection et la localisation des triplets s'effectuent à l'aide des deux pointeurs ADD~ZD et
ADF-ZD. Les triplets (Ti, Dj, Sk) successivement lus dans la zone ZD sont stockés dans le même ordre dans une zone de la mémoire du terminal appelée ZTD. Une fois le dernier triplet stocké dans la zone ZTD, le programme du terminal, à l'étape 7, positionne à l'état actif un indicateur d'autodiagnostic "Ind~DT" dans la mémoire du terminal. Puis le programme du terminal reboucle en attente d'une commande ou d'une autre introduction de carte sur l'étape 2.
Une nouvelle carte est introduite, c'est une carte banale, compatible avec l'application traitée par le terminal. On a dit précédemment que le logiciel d'application dans le terminal se décompose en tâches élémentaires Tt que l'on peut individuellement exécuter (étape 8). A la fin de l'exécution de chaque tâche que l'on peut référencer par le code Tt, le programme d'application teste à l'étape 9 I'indicateur Ind~DT du terminal. S'il est inactif, la fonction d'autodiagnostic n'est pas opérationnelle, le programme continue à exécuter les autres tâches. Si l'indicateur Ind~DT est actif, le programme du terminal recherche à l'étape 10 dans la zone ZTD de la mémoire du terminal le premier triplet (Ti, Dj, Sk) pour lequel Tt =Ti c'est à dire, s'il y a une donnée à tester à la suite de la tâche qui vient de s'exécuter. Si oui, à l'étape 11, la valeur "Val" de cette donnée (Dj) est stockée temporairement dans la mémoire du terminal et en fonction de la valeur de Sk, elle est traitée de la façon suivante:
Si Sk est égal à "1" (étape 12), la donnée Dj doit être envoyée vers le réseau. Un bloc de trois données est alors constitué: la valeur du champ Tt, la référence Dj de la donnée à analyser et la valeur "Val" de cette donnée extraite de la mémoire du terminal. Ces blocs sont mémorisés les uns à la suite des autres dans une zone de la mémoire du terminal appelée "ZDR".
Le contenu de cette zone est envoyé vers le réseau à la fin de la transaction ou lors d'une demande par le réseau des données d'autodiagnostic. Une fois toutes les données transmises, la zone ZDR est vidée pour être reutilisée lors d'une nouvelle introduction de carte.
Si Sk est égal à "2" (étape 13), la donnée Dj doit être envoyée vers l'imprimante du terminal pour impression. Un message est alors créé dans le tampon logiciel de l'imprimante, il est composé d'un texte (code ASCII) rappelant la nature de la donnée, par exemple "MONTANT : "suivi de la valeur décimale ou hexadécimale de la donnée Dj, le message se termine par un séparateur et un "RETOUR CHARIOT - SAUT DE LIGNE". On peut regrouper tous les messages d'autodiagnostic et les imprimer à la fin de la transaction.
Si Sk est égal à "3" (étape 14), la donnée doit être envoyée vers l'afficheur du terminal pour affichage. Un message est alors créé dans le tampon de l'afficheur, composé d'un texte (code ASCII) rappelant la nature de la donnée par exemple "MONTANT "suivie de la valeur décimale ou hexadécimale de la donnée Dj. Les messages correspondant à chaque élément (Tt, Dj, "3") sont affichés successivement pendant un certain temps fixé par le programme. On peut regrouper tous les messages et les afficher à la fin de la transaction, le défilement des messages peut être contrôlé par l'appui sur une touche du clavier du terminal.
Une fois la donnée Dj traitée, le programme vérifie à l'étape 15, s'il existe dans ZTD d'autres triplets pour lesquels Tt =Ti. Si oui, le programme reboucle à l'étape Il et traite un nouveau triplet. Pour chaque tâche élémentaire, la recherche de triplets s'effectue en balayant toute la zone
ZTD. S'il ne reste plus de triplets (Ti=Tt, Dj, Sk) à traiter, le programme, à l'étape 16, continue en séquence et passe éventuellement dans une variante à une autre tâche sans exécuter les étapes 17 et 18 décrites ci-après. S'il n'y a plus d'autres tâches à exécuter, le programme reboucle à l'étape 3, en attente d'une commande ou d'une nouvelle introduction de carte.
On peut associer un compteur initialisé avec un certain nombre à l'indicateur
Ind-DT dans le terminal de telle sorte que, la fonction d'autodiagnostic est activée que pour ce nombre d'introduction de carte banale. Pour ce faire,
I'opérateur a préalablement introduit ce nombre dans un emplacement spécifique (21, fig. 2) de la mémoire programmable de la carte de test par exemple, à coté des emplacements (230, 231) de ADD~ZD et ADF-ZD. Ce nombre est dans ce cas stocké dans la mémoire du terminal après l'introduction de la carte de test, à l'étape 6. Puis ce nombre est décrémenté (étape 17) à chaque fin d'exécution d'une fonction d'autodiagnostic, (sortie
OUI de l'étape 16). Lorsque celui-ci passe à "0", I'indicateur Ind~DT est positionné inactif (étape 18) et, éventuellement, le contenu de la zone ZTD est effacée.
Si ce compteur n'est pas installé les étapes 17 et 18 n'existent pas et la fonction d'autodiagnostic s'exécute une seule fois ou, indéfiniment jusqu'à ce qu'une nouvelle introduction de la carte de test rebascule l'indicateur Ind~DT en position inactive.
II est possible d'éviter l'utilisation d'une carte de test et d'employer que des cartes banales à condition qu'elles supportent les fonctions spéciales d'autodiagnostic. Pour cela la mémoire programmable de la carte banale contient en plus de la zone système ZS et de la zone utilisateur ZU, une zone ZD qui est repérée par son adresse de début "ADD~ZD" et son adresse de fin "ADF-ZD" (voir figure 4). La mémoire programmable de la carte banale contient dans sa zone système également à un emplacement (232) un indicateur "lnd D" signalant si la fonction d'autodiagnostic est active ou non. Toutes ces données ADD-ZD, ADF-ZD, Ind-D sont stockées dans des emplacements (230, 231, 232), de la partie ZS de la mémoire programmable allouée au système d'exploitation. Les deux valeurs d'adresse sont déterminées et écrites lors de la personnalisation de la carte la zone ZD, cette méthode est simple à mettre en oeuvre mais possède l'inconvénient de nécessiter la réservation d'un emplacement important dans toutes les cartes pouvant servir pour l'autodiagnostic.
Avantageusement, I'emplacement de la zone ZD peut être alloué dynamiquement par le système d'exploitation de la carte à la suite de la bonne présentation du code KD. L'opérateur précise alors à la carte le nombre de triplets (Ti, Dj, Sk) ou le nombre d'octets à réserver pour ZD. Le système d'exploitation de la carte recherche alors dans la mémoire programmable un emplacement vierge suffisant. Si la mémoire ne contient pas un tel emplacement vierge, le système d'exploitation renvoie un message d'erreur et interrompt la procédure d'introduction des données d'autodiagnostic. Dans le cas contraire, la place est suffisante le système d'exploitation mémorise l'adresse de début : "ADD~ZD" et l'adresse de fin "ADF-ZD". Nous verrons par la suite comment, après l'exécution de la fonction d'autodiagnostic, on peut effacer la présence de la zone ZD et ainsi libérer cet emplacement mémoire.
De la même façon que pour la carte de test. Une procédure sécuritaire est prévue pour éviter qu'un fraudeur puisse se servir d'une carte banale pour y introduire des données d'autodiagnostic. Un mécanisme de type challengeréponse avec algorithme et code secret permet d'authentifier l'opérateur et d'autoriser l'écriture et la lecture (nous le verrons pourquoi par la suite) des triplets dans ZD.
Dans le cas d'une carte banale utilisée pour transmettre les données d'autodiagnostic, le code Sk peut prendre une quatrième valeur : 4, cette valeur indique que la valeur de la donnée Dj à contrôler est inscrite dans la carte. Un quatrième champ situé à une adresse "Adr-V" est alors alloué à la suite du triplet (Ti, Dj, Sk=4) et on mémorise donc des quadruplets. La taille de ce champ correspond à celle de la donnée à inscrire, I'opérateur doit donc préciser le nombre d'octets "Nb-V" de ce quatrième champ et son contenu est constitué au départ de l'adresse (Adr-V) d'écriture puis comme on le verra par la suite après la sortie par la valeur "Val". Le cinquième triplet (225) de la figure 4 possède cette structure. Lorsque tous les triplets (Ti, Dj, Sk) (220 à 225) sont introduits dans la zone ZD, l'indicateur "lnd~D" est positionné actif signalant ainsi que la fonction d'autodiagnostic est active dans cette carte.
La figure 5 montre le déroulement des opérations lorsque la carte décrite précédemment est introduite dans un terminal. L'étape 1 est l'initialisation du terminal après une mise sous tension et l'étape 2 est la phase d'attente d'une introduction de carte, le programme continue, lorsque la carte est reconnue comme compatible avec l'application par reconnaissance par le terminal de la présence des informations nécessaires. A cette étape 2, le programme effectue la sélection de l'entité correspondant à l'application. A la différence de la carte de test, lorsque la carte banale est introduite par le porteur, ce dernier peut parfaitement ignorer que la fonction d'autodiagnostic est active.
A l'étape 3, le terminal teste si l'indicateur Ind~D dans la carte est positionné actif et donc, si la fonction d'autodiagnostic est opérationnelle.
L'indicateur peut être émis soit par une valeur particulière dans les octets émis par la carte lors de la mise sous tension, soit par une valeur particulière émise lors de la sélection de l'entité correspondant à l'application utilisée sur la carte. Si Ind D est actif, le programme passe à l'étape 4. Au cours de cette étape 4, la zone ZD est lue à l'aide des deux valeurs d'adresse ADD-ZD et ADF~ZD et l'ensemble des triplets lus dans la carte sont stockés dans la mémoire ZTD du terminal. Si le triplet comporte une information Sk dont la valeur est "4", le système d'exploitation de la carte renvoie en plus des trois valeurs Ti, Dj et Sk , L'adresse "Adr-v" du quatrième champ réservé pour inscrire la donnée dans ZD et le nombre d'octet "Nb~v" de ce champ. Pour des raisons de sécurité, l'accès en lecture à la zone ZD de la carte n'est accordé par le système d'exploitation de la carte que si l'indicateur Ind~D de la carte est actif Une fois toutes les informations contenues dans la zone ZD stockées dans la zone mémoire
ZTD du terminal, le terminal positionne son indicateur d'autodiagnostic Ind-D en position active (voir étape 5 de la figure 5). Les étapes 3, 4 et 5 sont des parties de ia séquence d'initialisation du dialogue entre la carte banale et le terminal et s'exécutent avant l'exécution du programme d'application.
On a dit précédemment que le logiciel d'application se décompose en tâches élémentaires que l'on peut individuellement tester. A la fin de l'exécution de chaque tâche que l'on peut référencer par un numéro Tt (étape 6), par exemple le logiciel de base, reprend la main et teste si l'indicateur de diagnostic interne au terminal est actif (étape 7). Si celui-ci est actif, à l'étape 8, le programme recherche s'il existe un élément (Ti, Dj, Sk) stocké dans la zone ZTD qui possède une valeur de champ Ti égale à celle de Tt.
Si oui : il y a une donnée (référencé Dj) à contrôler à la suite de la tâche qui vient de s'exécuter, la valeur de cette donnée est alors stockée temporairement dans la mémoire du terminal. En fonction de la valeur de Sk, elle est traitée de la façon suivante (étape 9):
Si Sk est égal à "1" (étape 10), la donnée Dj doit être envoyée par le terminal vers le réseau. Un bloc de trois données est alors constitué de la valeur du champ Tt, de la référence Dj de la donnée à analyser et de la valeur "Val" de cette donnée extraite de la mémoire du terminal. Ces blocs sont mémorisés les uns à la suite des autres dans une zone de la mémoire du terminal appelée "ZDR" Le contenu de cette zone est envoyée vers le réseau à la fin de la transaction ou lors d'une demande par le réseau des données d'autodiagnostic. Une fois toutes les données transmises, la zone
ZDR est vidée pour être re-utilisée lors d'une nouvelle introduction de carte.
Si Sk est égal à "2", la donnée doit être envoyée vers l'imprimante du terminal, le programme se poursuit par l'étape 11. Au cours de cette étape 11 un message est créé dans le tampon de l'imprimante, composé d'un successivement pendant un certain temps fixé par le logiciel d'autodiagnostic. Avantageusement, on peut regrouper tous les messages et les afficher à la fin de la transaction, le défilement des messages peut être contrôlé par l'appui sur une touche du clavier du terminal.
Si Sk est égal à "4", la donnée doit être mémorisée dans la carte, le programme se poursuit par l'étape 13. Au cours de cette étape 13, un quatrième champ est réservé à cet usage dans ZD, l'adresse "Adr-v" de ce quatrième champ et le nombre d'octets "Nb~v" de ce champ ont été mémorisés dans la zone ZTD lors du chargement des données d'autodiagnostic dans le terminal. Le terminal envoie donc à la carte une commande d'écriture avec les paramètres suivants:
Adresse d'écriture : Adr-v
Nombre d'octets à écrire: Nb-v
Valeur à écrire: "Val" celle de la donnée Dj.
L'écriture dans la zone ZD n'est autorisée par le système d'exploitation de la carte que dans le quatrième champ d'un triplet de type Sk=4 correspondant à la Ti. Dans le cas où le triplet Ti de la carte n'est pas de type Sk=4,
L'écriture est refusée. Un compte rendu d'exécution est systématiquement renvoyé au terminal après chaque commande d'écriture, si celle-ci n'a pas été menée à bien, le terminal avertit l'utilisateur par un message. L'utilisation des données mémorisée est expliquée dans la suite. Une variante consiste à stocker temporairement toutes les valeurs des données Dj de type Sk=4 et à effectuer les commandes d'écriture des valeurs à la fin de la transaction.
Une fois la donnée Dj traitée, à l'étape 14, le programme vérifie s'il existe dans la zone ZTD d'autres triplets pour lesquels Tt =Ti. Si oui, le programme reboucle à l'étape 9 et traite un nouveau triplet. Pour chaque tâche élémentaire, la recherche de triplets s'effectue en balayant toute la zone
ZTD. S'il ne reste plus de triplets (Ti=TT, Dj, Sk) à traiter, le programme passe à l'étape 15 en recherchant d'autre tâche à exécuter. S'il n'y a plus d'autres tâches à exécuter, le programme reboucle à l'étape 2, en attente d'une nouvelle introduction de carte.
Dans le cas d'une carte banale utilisée pour transmettre les données d'autodiagnostic, la fonction d'autodiagnostic doit pouvoir s'exécuter qu'une seule fois. En effet, l'opérateur peut ne vouloir effectuer qu'un seul test du terminal lecteur de carte, ensuite les données ne doivent pas sortir du terminal. De plus, si la donnée à contrôler possède un champ Sk de type 4, un seul stockage n'est pas possible. Pour recommencer une nouvelle fois la fonction, la carte doit être de nouveau programmée par l'opérateur. Pour éviter d'être utilisée plusieurs fois avec la fonction d'autodiagnostic, juste après la lecture de la zone ZD par le terminal, le système d'exploitation de la carte va positionner à l'état inactif l'indicateur Ind~D. Pour des raisons de sécurité, il peut aussi effacer tous les triplets de type Sk=1, 2 et 3.
L'indicateur Ind-D est inactif, la lecture de la zone ZD n'est plus possible.
Les données correspondant au type Sk=4 sont traitées lorsque la carte banale passe dans un terminal habilité à les lire, c'est à dire un terminal qui s'est authentifié de la même façon que lors de l'écriture des données d'autodiagnostic. Une fois tous les triplets lus, I'effacement total de la zone
ZD peut être effectué. Cet effacement peut être provoqué par une commande spéciale ou lors de la première écriture dans la zone ZD.
L'effacement, que justifie la sécurité, permet aussi de libérer la place occupée par la zone ZD. Cet emplacement peut être utilisé par l'application.
Ce fonctionnement style "mono-coup" de la fonction d'autodiagnostic peut être intéressant, lorsqu'une personne rapporte sa carte de crédit à une agence bancaire en déclarant que, sur un certain type de terminal de paiement, sa carte "ne marche pas" L'agence va enregistrer les données d'autodiagnostic dans cette carte en spécifiant que les données de la transaction (montant, date, valeur du certificat) seront écrites dans la carte en positionnant dans chaque triplet correspondant à une tâche à enregistrer le troisième champ Sk à la valeur "4" (Sk=4). La personne retourne chez le commerçant où se trouve le terminal à tester, effectue une transaction et revient à son agence qui analyse ou fait analyser à distance les informations stockées dans ZD.
Le fonctionnement mono-coup est aussi intéressant pour vérifier le fonctionnement d'un terminal soupçonné de fraude. Un organisme bancaire repère que, sur un terminal, des transactions sont créditées sans qu'il existe des demandes de débit sur des comptes clients. L'organisme bancaire va envoyer des contrôleurs dotés de cartes banales avec la fonction d'autodiagnostic. A leurs retours, les données chargées dans la carte seront analysées.
Un autre exemple : un organisme bancaire peut trouver intéressant de connaître rapidement le moment et l'endroit où une carte est utilisée pour la première fois. Pour cela, avant de délivrer la carte à son porteur, cette dernière contient deux triplets de type Sk=1 dans lequel chaque troisième champ Sk est à la valeur "1". Dans la zone ZD, avec la donnée Dj correspondant à la date de la transaction et la donnée Dj correspondant à l'identité du terminal. Lors de la première transaction, les deux blocs (Ti, Dj, "date") et (Ti, Dj', "identité du terminal") seront envoyés immédiatement sur le réseau.

Claims (14)

REVENDICATIONS
1. Terminal doté d'un programme d'application, d'au moins une sortie constitué soit par un affichage, soit par une imprimante, soit par un réseau de communication, soit par un objet portable et coopérant avec un objet portable doté d'une zone de mémoire non-volatile (ZD) contenant des données et comportant un lecteur communiquant avec ledit objet portable, caractérisé en ce que l'appareil comporte des moyens de lecture ou de stockage dans sa mémoire de données (Ti, Dj, Sk) d'autodiagnostic ou de supervision et un moyen d'émission desdites données vers des sorties (1-4) spécifiées en fonction d'informations fournies par les données d'autodiagnostic ou de supervision suite à l'exécution d'au moins une tâche
Tt de son programme d'application en relation avec l'objet portable.
2. Terminal, selon la revendication 1, caractérisé en ce que les moyens d'émission des données d'autodiagnostic sont activés un certain nombre de fois.
3. Terminal, selon la revendication 1, caractérisé en ce que les moyens d'émission des données d'autodiagnostic ou de supervision comporte des moyens d'écriture dans l'objet portable connecté à l'appareil.
4. Terminal, selon une des revendications 1 à 3, caractérisé en ce que les données d'autodiagnostic ou de supervision sont constituées par au moins un triplet (Ti, Dj, Sk) d'information correspondant pour une première information (Ti) à une tâche déterminée du programme d'application, pour la seconde information (Dj) à un type de données corrélées à la tâche exécutée et à présenter à une sortie, et pour la troisième information à une valeur (Sk) de spécification de la sortie à laquelle le type de données doit être présenté parmi celles présentes sur le terminal.
5. Terminal, selon une des revendications précédentes, caractérisé en ce que l'appareil dispose d'un moyen de test de la présence de données d'autodiagnostic ou de supervision dans un objet portable et de déclenchement de la lecture et du stockage de ces données dans une zone spécifique ZTD de la mémoire du terminal.
6. Terminal, selon une des revendications précédentes, caractérisé en ce qu'il comporte des moyens d'introduction de données d'autodiagnostic ou de supervision dans un objet portable.
7. Procédé de supervision du fonctionnement d'un terminal ou d'autodiagnostic d'un terminal à partir d'un triplet d'information correspondant pour une première information à une tâche déterminée d'un programme d'application exécuté soit par un objet portable soit par un terminal, pour la seconde information à un type de données corrélées à la tâche exécutée et à présenter sur une sortie et pour la troisième information à une valeur de spécification de la sortie parmi celles présentes sur le terminal caractérisé en ce qu'il consiste: - à exécuter (9) une tâche du programme d'application sur le terminal - à tester (9) un indicateur soit dans le terminal soit dans l'objet portable pour déterminer si une fonction d'autodiagnostic ou de supervision est opérationnelle, puis dans le cas d'une réponse positive - à rechercher (9) dans la mémoire soit de l'objet portable soit du terminal s'il existe parmi les triplets d'information stockés un triplet dont la première information correspond à la tâche déterminée exécutée par le terminal ou la carte; - à émettre vers la sortie spécifiée par le triplet ainsi lu la valeur de la donnée corrélée à la tâche exécutée et à référencer par la seconde information du triplet.
8. Procédé, selon la revendication 7, caractérisé en ce qu'il comporte une étape de test (16) consistant à déterminer s'il existe d'autres tâches à exécuter et à la suite de l'exécution de ces tâches à rechercher tous les triplets d'information correspondants à l'exécution de cette tâche.
9. Procédé, selon une des revendications 7 et 8, caractérisé en ce qu'il comporte une étape de lecture d'un objet portable mémorisant dans sa mémoire non-volatile une pluralité de triplets et une étape (6) de stockage de ces triplets dans une zone de mémoire non-volatile du terminal suivie d'une étape (7) d'activation d'un indicateur de fonction d'autodiagnostic ou de supervision active.
10. Procédé, selon une des revendications 7 à 9, caractérisé en ce qu'il comporte une étape de test (3, 4) pour déterminer si l'objet portable est une carte spécifique à la fonction d'autodiagnostic ou de supervision ou une carte dite bancale.
11. Procédé, selon une des revendications 7 et 10, caractérisé en ce que les données d'autodiagnostic ou de supervision sont constituées par un quatrième champ d'information contenant au départ dans l'objet portable l'adresse d'écriture (Adr-V), le nombre d'octets à écrire (Nb-V), après l'opération d'autodiagnostic la valeur à écrire (Val).
12. Objet portable utilisable avec le terminal selon une des revendications 1 à 6, caractérisé en ce qu'il comporte une carte à microprocesseur fonctionnant grâce à un système d'exploitation mémorisé sur la carte et comportant une mémoire non-volatile contenant au moins un triplet (Ti, Dj,
Sk) d'information dans une zone ZD déterminée de cette mémoire nonvolatile dont la position est définie par des champs d'adresse situés dans la partie de mémoire servant à stocker le système d'exploitation.
13. Objet portable selon la revendication précédente, caractérisé en ce que la partie (25) de mémoire non-volatile servant à mémoriser le système d'exploitation comporte également dans un champ mémoire une information constituant un compteur (21) d'utilisation de la fonction d'autodiagnostic.
14. Objet portable selon une des revendications 12 et 13, caractérisé en ce que la zone mémoire (25) stockant le système d'exploitation comporte un champ permettant de mémoriser un indicateur (232) d'activation de la fonction d'autodiagnostic ou de supervision.
FR9615997A 1996-12-24 1996-12-24 Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede Expired - Fee Related FR2757664B1 (fr)

Priority Applications (13)

Application Number Priority Date Filing Date Title
FR9615997A FR2757664B1 (fr) 1996-12-24 1996-12-24 Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede
US09/125,714 US6253163B1 (en) 1996-12-24 1997-12-23 Portable object reader terminal and process for self-diagnosis and supervision of same
KR1019980706599A KR19990087204A (ko) 1996-12-24 1997-12-23 자가 진단 또는 관리 터미널과 방법 및 이런터미널 또는 방법에 사용되는 포터블 오브젝트
PCT/FR1997/002388 WO1998028720A1 (fr) 1996-12-24 1997-12-23 Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede
EP97952981A EP0907937A1 (fr) 1996-12-24 1997-12-23 Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede
JP10528479A JPH11504748A (ja) 1996-12-24 1997-12-23 自己診断又は監視のための端末及び方法、ならびに該端末又は方法に使用される携帯品
CN97192506A CN1212065A (zh) 1996-12-24 1997-12-23 终端和自诊断或监测方法以及用于该终端或方法的便携物品
ARP970106133A AR009843A1 (es) 1996-12-24 1997-12-23 Terminal y procedimiento de autodiagnostico o de supervision y objeto portatil utilizado con dicha terminal
AU56682/98A AU723514B2 (en) 1996-12-24 1997-12-23 Terminal and process for self-diagnosis or supervision and portable object used in a terminal or process of this type
BR9707597A BR9707597A (pt) 1996-12-24 1997-12-23 Terminal e processo de autodiagnóstico ou de supervis o e objeto portátil utilizado em um tal terminal ou processo
CA002247474A CA2247474A1 (fr) 1996-12-24 1997-12-23 Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede
NO983851A NO983851L (no) 1996-12-24 1998-08-21 Terminal og fremgangsmÕte for selvdiagnose eller overvÕkning, samt bµrbar gjenstand for anvendelse i en slik terminal eller fremgangsmÕte
US09/827,905 US6505144B2 (en) 1996-12-24 2001-04-09 Portable object reader terminal, portable object, and process for self-diagnosis and supervision of same

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR9615997A FR2757664B1 (fr) 1996-12-24 1996-12-24 Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede

Publications (2)

Publication Number Publication Date
FR2757664A1 true FR2757664A1 (fr) 1998-06-26
FR2757664B1 FR2757664B1 (fr) 1999-01-22

Family

ID=9499124

Family Applications (1)

Application Number Title Priority Date Filing Date
FR9615997A Expired - Fee Related FR2757664B1 (fr) 1996-12-24 1996-12-24 Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede

Country Status (12)

Country Link
US (2) US6253163B1 (fr)
EP (1) EP0907937A1 (fr)
JP (1) JPH11504748A (fr)
KR (1) KR19990087204A (fr)
CN (1) CN1212065A (fr)
AR (1) AR009843A1 (fr)
AU (1) AU723514B2 (fr)
BR (1) BR9707597A (fr)
CA (1) CA2247474A1 (fr)
FR (1) FR2757664B1 (fr)
NO (1) NO983851L (fr)
WO (1) WO1998028720A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2781592A1 (fr) * 1998-07-27 2000-01-28 Gemplus Card Int Procede de controle de l'execution d'une demande d'actions transmise par un serveur vers une carte a puce via un terminal
WO2002013560A1 (fr) * 2000-08-09 2002-02-14 Robert Bosch Gmbh Procede de telediagnostic et d'evaluation d'erreurs centralisee concernant des appareils electriques decentralises, et appareil electronique decentralise

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1098487A3 (fr) * 1999-11-01 2004-04-07 Citicorp Development Center, Inc. Méthode et système pour coordination des activités de session à un terminal de transactions financières en libre-service
FR2810138B1 (fr) * 2000-06-08 2005-02-11 Bull Cp8 Procede de stockage securise d'une donnee sensible dans une memoire d'un systeme embarque a puce electronique, notamment d'une carte a puce, et systeme embarque mettant en oeuvre le procede
US6868507B1 (en) * 2000-11-07 2005-03-15 Intel Corporation Operating system independent
US6694281B2 (en) 2001-07-12 2004-02-17 Seagate Technology Llc Real time signal analysis of a remote block data storage device
US6711520B2 (en) 2001-07-12 2004-03-23 Seagate Technology Llc Remote execution of diagnostic firmware in a block data storage device
JP2003242452A (ja) * 2002-02-19 2003-08-29 Sankyo Seiki Mfg Co Ltd Ｉｃカードリーダの自己診断方法
KR20030091040A (ko) * 2002-05-22 2003-12-01 톰슨 라이센싱 소시에떼 아노님 비디오 신호의 수신 및/또는 처리를 위한 디바이스,메모리 카드, 디바이스와 카드로 구성되는 어셈블리 및디바이스를 제어하기 위한 방법
KR100487368B1 (ko) * 2002-06-26 2005-05-03 엘지전자 주식회사 위치 추적 기능을 갖는 단말기의 성능 테스트 장치 및방법
US7200775B1 (en) 2002-10-04 2007-04-03 American Megatrends, Inc. Method and data structures for use in providing on-demand computer diagnostics
US7231549B1 (en) * 2002-10-04 2007-06-12 American Megatrends, Inc. Method and apparatus for providing on-demand computer diagnostics
US7334166B1 (en) 2002-10-04 2008-02-19 American Megatrends, Inc. Method, system, and apparatus for providing and utilizing server-side entry points for use in diagnostics on-demand services
US20040153773A1 (en) * 2002-12-10 2004-08-05 Woo Arthur Cheumin Diagnosing faults in electronic machines
US6880752B2 (en) * 2003-04-16 2005-04-19 George V. Tarnovsky System for testing, verifying legitimacy of smart card in-situ and for storing data therein
FR2859559B1 (fr) * 2003-09-10 2005-12-09 Ascom Monetel Lecteur de carte sans contact
US8527320B2 (en) * 2005-12-20 2013-09-03 Arbitron, Inc. Methods and systems for initiating a research panel of persons operating under a group agreement
US8041030B2 (en) * 2007-01-09 2011-10-18 Mastercard International Incorporated Techniques for evaluating live payment terminals in a payment system
US8442796B2 (en) * 2007-07-05 2013-05-14 Mastercard International Incorporated Method and system for simulating a proximity-based transaction device
US9038914B2 (en) * 2007-07-05 2015-05-26 Mastercard International Corporation Method and system for simulating a proximity-based transaction device
US8132713B2 (en) * 2009-10-16 2012-03-13 Visa International Service Association System and method for automated selection of testing criteria for payment devices
CN103763103B (zh) * 2013-12-31 2017-02-01 飞天诚信科技股份有限公司 一种智能卡生成脱机认证凭据的方法
US9961059B2 (en) * 2014-07-10 2018-05-01 Red Hat Israel, Ltd. Authenticator plugin interface
US12099425B2 (en) * 2022-12-08 2024-09-24 Google Llc Automated testing of digital keys for vehicles

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0131331A2 (fr) * 1983-07-11 1985-01-16 Mainmet Limited Appareil pour la distribution de services tels que l'eau, l'électricité etc.
US4777355A (en) * 1986-12-24 1988-10-11 Mitsubishi Denki Kabushiki Kaisha IC card and system for checking the functionality thereof
EP0387972A1 (fr) * 1989-03-17 1990-09-19 Klüssendorf Aktiengesellschaft Méthode de commande d'un automate

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2206432B (en) * 1987-05-20 1991-07-24 Furuno Electric Co Bar code printing and/or reading apparatus
US5294782A (en) * 1991-09-27 1994-03-15 Khyber Technologies Corporation Integrated portable device for point of sale transactions
JP3810813B2 (ja) * 1994-03-14 2006-08-16 富士通株式会社 セルフスキャニングｐｏｓシステム，セルフスキャン式登録端末，セルフスキャン式登録端末用管理装置およびセルフスキャン式登録端末用ｐｏｓ装置
US5979757A (en) * 1996-09-05 1999-11-09 Symbol Technologies, Inc. Method and system for presenting item information using a portable data terminal
US6084528A (en) * 1996-09-05 2000-07-04 Symbol Technologies, Inc. Intranet scanning terminal system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0131331A2 (fr) * 1983-07-11 1985-01-16 Mainmet Limited Appareil pour la distribution de services tels que l'eau, l'électricité etc.
US4777355A (en) * 1986-12-24 1988-10-11 Mitsubishi Denki Kabushiki Kaisha IC card and system for checking the functionality thereof
EP0387972A1 (fr) * 1989-03-17 1990-09-19 Klüssendorf Aktiengesellschaft Méthode de commande d'un automate

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2781592A1 (fr) * 1998-07-27 2000-01-28 Gemplus Card Int Procede de controle de l'execution d'une demande d'actions transmise par un serveur vers une carte a puce via un terminal
WO2000007153A1 (fr) * 1998-07-27 2000-02-10 Gemplus Procede de controle de l'execution d'une demande d'actions transmise par un serveur vers une carte a puce via un terminal
WO2002013560A1 (fr) * 2000-08-09 2002-02-14 Robert Bosch Gmbh Procede de telediagnostic et d'evaluation d'erreurs centralisee concernant des appareils electriques decentralises, et appareil electronique decentralise
US7110757B2 (en) 2000-08-09 2006-09-19 Robert Bosch Gmbh Remote diagnosis and central fault evaluation method of decentralized electric devices, and decentralized electronic device

Also Published As

Publication number Publication date
CA2247474A1 (fr) 1998-07-02
EP0907937A1 (fr) 1999-04-14
WO1998028720A1 (fr) 1998-07-02
BR9707597A (pt) 1999-07-27
NO983851L (no) 1998-10-21
US6505144B2 (en) 2003-01-07
AR009843A1 (es) 2000-05-03
AU5668298A (en) 1998-07-17
NO983851D0 (no) 1998-08-21
JPH11504748A (ja) 1999-04-27
US6253163B1 (en) 2001-06-26
US20020022943A1 (en) 2002-02-21
FR2757664B1 (fr) 1999-01-22
KR19990087204A (ko) 1999-12-15
CN1212065A (zh) 1999-03-24
AU723514B2 (en) 2000-08-31

Similar Documents

Publication Publication Date Title
FR2757664A1 (fr) Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede
EP0589884B1 (fr) Procede securise de chargement de plusieurs applications dans une carte a memoire a microprocesseur
EP0018889B1 (fr) Procédé pour prolonger la validité d'une zone de travail de la mémoire d'un support d'enregistrement
EP0096599B1 (fr) Procédé pour authentifier ou certifier au moins une information contenue dans une mémoire d'un support électronique, notamment amovible et portatif tel qu'une carte
EP0250309B1 (fr) Procédé pour faire authentifier par un milieu extérieur un objet portatif tel qu'une carte à mémoire accouplée à ce milieu
FR2612316A1 (fr) Carte a circuits integres ayant une capacite de verification d'erreur interne
EP0626664B1 (fr) Système de communication avec cartes à puce
FR2635891A1 (fr) Dispositif electronique portatif comportant des donnees-cle limitant l'acces a la memoire
FR2606909A1 (fr) Systeme de traitement pour un appareil electronique portatif, tel qu'une carte a circuit integre
EP0049650A1 (fr) Appareil de distribution d'objets et d'acquisition de services
FR2627609A1 (fr) Dispositif electronique portatif
FR2766942A1 (fr) Lecteur de carte a puce avec microcontroleur et composant de securite
FR2609175A1 (fr) Carte a circuits integres et systeme pour verifier le bon fonctionnement de la carte
FR2777673A1 (fr) Dispositif de traitement de l'information comprenant des moyens pour gerer une memoire virtuelle, et procede de stockage d'informations associe
FR2765985A1 (fr) Procede de gestion d'un terminal securise
FR2613851A1 (fr) Carte a circuits integres et procede pour y enregistrer des donnees
EP1388134A1 (fr) Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable
FR2473755A1 (fr) Procede et dispositif electronique de memorisation et de traitement confidentiel de donnees
EP1029312B1 (fr) Procede de gestion securise d'une memoire
FR2674647A1 (fr) Appareil formant chequier electronique pour transactions financieres et procede d'utilisation d'un tel appareil.
EP0957461B1 (fr) Procédé de personnalisation d'une carte à puce
EP1012710A1 (fr) Procede de chargement d'un programme d'utilisation dans un support a puce
EP0974131B1 (fr) Procede d'interpretation dynamique de donnees pour une carte a puce
EP0246119B1 (fr) Système optionnel de protection de l'accès à un ordinateur
FR2612668A1 (fr) Dispositif electronique portable

Legal Events

Date Code Title Description
ST Notification of lapse