WO1998028720A1 - 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
WO1998028720A1
WO1998028720A1 PCT/FR1997/002388 FR9702388W WO9828720A1 WO 1998028720 A1 WO1998028720 A1 WO 1998028720A1 FR 9702388 W FR9702388 W FR 9702388W WO 9828720 A1 WO9828720 A1 WO 9828720A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
self
data
portable object
information
Prior art date
Application number
PCT/FR1997/002388
Other languages
English (en)
Inventor
Ronan Lapie
Original Assignee
Bull Cp8
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
Application filed by Bull Cp8 filed Critical Bull Cp8
Priority to EP97952981A priority Critical patent/EP0907937A1/fr
Priority to US09/125,714 priority patent/US6253163B1/en
Priority to AU56682/98A priority patent/AU723514B2/en
Priority to BR9707597A priority patent/BR9707597A/pt
Priority to JP10528479A priority patent/JPH11504748A/ja
Publication of WO1998028720A1 publication Critical patent/WO1998028720A1/fr
Priority to NO983851A priority patent/NO983851L/no
Priority to US09/827,905 priority patent/US6505144B2/en

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

Definitions

  • the present invention relates to a terminal and a method of self-diagnosis or supervision and the portable object of the microcircuit card type used in such a method or terminal or reader.
  • These objects include a Central Unit, a program memory containing executable code constituting the operating system, a non-volatile and programmable data memory and, one or more communication interfaces.
  • Terminals are devices with an interface compatible with those of objects, they have a central processing unit and software capable of communicating and using data from the non-volatile memory of the portable object.
  • the terminals are equipped with specific software corresponding to their use, for example, the portable payment terminals are provided with an operating program of the banking type.
  • This software is produced or specified by the organization that manages this application, in the example cited, it is a banking organization.
  • This organization is generally not the manufacturer of the terminal, it buys or has the hardware part made, that is to say, the terminal, it introduces the specific program in order to configure its terminal for its own application.
  • the banking organization finds its advantage there by buying a standard product therefore inexpensive, and by adapting it according to its needs.
  • the manufacturer offers a basic model that can suit several applications, which allows it to expand its market.
  • the organization operating a given application may wish to have several models of card reader terminals, it is not desirable to develop application software for each terminal.
  • This has led manufacturers to implement a basic software layer which provides the interface between hardware and application software.
  • This software layer ensures adaptation between the same application software and different terminals.
  • One way of doing this is to create an interpreter, so that the body can develop its application in well-known advanced language, almost independently of the constraints of the material.
  • Another way to do this is to organize a software layer of low level which manages all the hardware inputs and outputs, and to make available to the organization operating a library of primitives that the application software will call.
  • the validation or the test of the terminal must take into account the two parts: the hardware with its basic software and the application software.
  • a self-test makes it possible to check each piece of equipment on the terminal; it generally consists of a routine implemented in the basic software.
  • the testing of the application software must be carried out in the laboratory, it is important in this type of application to verify the operation of the program before it is put into service.
  • the multiplicity of cards leads to a very large number of specific cases that cannot be reproduced in the laboratory.
  • the purpose of the following invention is to validate or test the operation of application software under normal conditions of use.
  • the invention relates to a terminal provided with an application program, of at least one output constituted either by a display, or by a printer, or by a communication network, or by a portable and cooperating object.
  • a portable object provided with a non-volatile memory area containing data and comprising a reader communicating with said portable object, characterized in that the apparatus includes means for reading or storing in its memory diagnostic data or of supervision and a means of transmitting said data to specified outputs as a function of information supplied by the self-diagnosis or supervision data following the execution of at least one task of its application program in relation to the portable object.
  • the means for transmitting the self-diagnostic data are activated a certain number of times.
  • the means for transmitting the self-diagnosis or supervision data comprises means for writing to the portable object connected to the device.
  • the self-diagnosis or supervision data consist of at least one triplet of information corresponding for a first piece of information to a determined task of the application program, for the second piece of information to a type of data correlated to the task executed and to be presented to an output, and for the third piece of information to a value of specification of the output to which the type of data must be presented among those present on the terminal.
  • the device has a means of testing the presence of self-diagnosis or supervision data in a portable object and of triggering the reading and storage of this data in a specific zone ZTD of the memory of the terminal.
  • the terminal includes means for introducing self-diagnostic or supervision data into a portable object.
  • Another object of the invention is to propose a method for supervising the operation of a terminal or for self-diagnosis of a terminal.
  • the method of self-diagnosis or of supervision starting from at least one triplet of information corresponding for a first information to a determined task of an application program executed either by a portable object or by a terminal, for the second information to a type of data correlated to the task executed and to be presented on an output and for the third information to a value of specification of the output among those present on the terminal is characterized in that it consists of:
  • the method comprises a test step consisting in determining whether there are other tasks to be executed and, following the execution of these tasks, in searching for all the triplets of information corresponding to the execution of this task.
  • the method comprises a step of reading a portable object memorizing in its non-volatile memory a plurality of triplets and a step of storing these triplets in a non-volatile memory area of the terminal followed by a step of activating a self-diagnostic function or active supervision indicator.
  • the method comprises a test step to determine whether the portable object is a card specific to the self-diagnosis or supervision function or a so-called banal card.
  • the self-diagnosis or supervision data are constituted by a fourth information field containing, at the start in the portable object the write address (Adr-V), the number of bytes to be written (Nb-V), after the self-diagnostic operation the value to be written (Val).
  • Another object of the invention is to propose a portable object usable with the terminal and the self-diagnosis or supervision method.
  • the portable object is a microprocessor card operating thanks to an operating system stored on the card and comprising a non-volatile memory containing at least one triplet of information in a determined zone of this non-volatile memory whose position is defined by address fields located in the memory part used to store the operating system.
  • the part of non-volatile memory used to memorize the operating system also includes in a field memory information constituting a counter for use of the self-diagnosis function.
  • the memory area storing the operating system includes a field making it possible to store an indicator for activating the self-diagnosis or supervision function.
  • Figure 1 is an explanatory table of triples consisting of elementary tasks, types of data and types of outputs that can be associated with the execution of each of the tasks of an application program;
  • FIG. 2 is a diagram of the non-volatile memory areas used on a portable test object necessary for implementing the method of the invention
  • FIG. 3 represents the different stages of execution of the terminal initialization programs and of execution of the self-diagnostic function
  • FIG. 4 represents a schematic view of the areas for storing information in the non-volatile memory of a portable object called commonplace;
  • FIG. 5 represents the different stages of execution of a terminal initialization program and execution of the self-diagnostic function on this terminal with a so-called banal card.
  • One way of carrying out the invention consists in a first variant, on the one hand, of using a microprocessor card operating thanks to an operating system stored on the card and constituting a "smart card called intelligent" which is previously initialized with self-diagnostic data, on the other hand to have these data taken into account by the terminal whose application software is to be tested.
  • Application software in a terminal can be broken down into elementary tasks which follow one another at determined times. For example, for a banking application, we can break down a transaction by following basic tasks (Ti): Verification (T1, Fig. 1) if the card inserted is authorized, Authentication (12) of the bearer, Acquisition (T3) of the transaction data in the terminal, Recording of this data in the microcircuit of the card, Validation (T4) of the transaction in the terminal and the card.
  • the application software manipulates data, this data can be used temporarily like, on the one hand the Code developed by the carrier (Cp) which is stored in the memory of the terminal , on the other hand the identity of the holder (Ip) which is stored in the card or also as the Amount of the transaction (Mt) or the Date of the transaction (Dt) which are stored in the terminal and the card.
  • Cp Code developed by the carrier
  • Ip identity of the holder
  • Mt Amount of the transaction
  • Dt Date of the transaction
  • the self-diagnostic function of using the application software consists in checking the transaction data during certain tasks and this under normal conditions of use. This function can be performed either by the basic software or by the application software;
  • the operator responsible for the control draws up a grid composed on one side of the identifiable elementary tasks denoted Ti and on the other side, data Dj consisting of information such as: Cp, Ip, Mt and Dt.
  • Figure 1 shows an example of such a grid.
  • the operator chooses to check the value of certain data when performing specific tasks. This amounts to associating a data item Dj with a task Ti, these associations are symbolized by crosses on the grid of FIG. 1.
  • a third element of information Sk is added.
  • the operator introduces the information triplets (Ti, Dj, Sk) into a special central unit called diagnostic, this central unit is equipped with a card reader.
  • the diagnostic software is configured according to the application to be tested so that the triplets (Ti, Dj, Sk) are identified when entering on screen by the indication specifies basic tasks and data to be checked and not the numerical references Ti, Dj, Sk ...
  • the card containing the self-diagnostic data is: either a special card or a common card commonly used for an application. A detailed description of an achievement is given for each case.
  • test card (20, Fig. 2) is used to contain the self-diagnostic data.
  • a security procedure is implemented to prevent a fraudster from being able to use such a card in an unauthorized manner.
  • the test card contains, in the secret memory area not shown, a so-called diagnostic code "KD". This secret code must be presented beforehand to the card which verifies it and, if it is equal to a reference code, authorizes the writing of the self-diagnosis data in the programmable memory of the card.
  • KD diagnostic code
  • the non-volatile programmable memory of the test card has, in addition to the system zone ZS containing the operating system of the card and the zone (AZU other usable zone) allowing other memorizations, a zone (22) called "ZD". It is in this zone that the triplets (Ti, Dj, Sk) are stored successively.
  • a first zone (220) of a memory allows the storage of the first triplet T1, D2, 1; a second zone (221) allows the storage of the second triplet T2, D1, 2; a third zone (222) allows the storage of the third triplet T3, D3, 1; a fourth zone (223) allows the storage of the fourth triplet D4, D3, 3; a fifth zone (224) allows the storage of the triplet T4, D4, 1; T1, T2, T3, T4, D1, D2, D3, D4 respectively representing the information in Figure 1.
  • the portable object can include more or less triplet depending on the type of supervision or self-diagnosis that one wants to perform on the tasks executed by the application program.
  • the ZD area is identified by its start address: "ADD_ZD" and its end address "ADF-ZD", the two address values are stored in the part (230, 231) of the programmable memory allocated to the exploitation.
  • the non-volatile programmable memory is of EPROM, EEPROM, FeRAM, SRAM or FLASH type.
  • Figure 2 describes the organization of this memory by taking up the information cited in FIG. 1.
  • the data Dj is the physical address of the data to be checked in the working memory of the terminal.
  • FIG. 3 is a flowchart illustrating the chronology of the events of the program consisting of a waiting and test sequence (1, 2, 3), the test triggering depending on the result being a loading sequence (4 to 7, Fig. . 3) of the terminal with the self-diagnostic data, either a sequence of execution of the self-diagnostic program (8 to 16, Fig. 3) which is incorporated either in the basic software of the terminal, or in the software of application.
  • Step 1 is the initialization of the terminal after a power up and step 2 is the phase of waiting for an order or a card introduction.
  • step 3 the terminal tests if the card inserted in the reader is a common card, and in step 4 if the card is a test card. In the latter case, the terminal performs in step 5 a procedure for authenticating the card by a reference code or, by a conventional challenge-response authentication scheme using an algorithm and a secret key (KD).
  • KD secret key
  • the terminal program reads in step 6 the information contained in the zone ZD.
  • the selection and the localization of the triples are carried out using two pointers ADD_ZD and ADF-ZD.
  • the triplets (Ti, Dj, Sk) successively read in the zone ZD are stored in the same order in a zone of the memory of the terminal called ZTD.
  • the terminal program sets a self-diagnostic indicator "lnd_DT" in the terminal memory to the active state. Then the terminal program loops while waiting for an order or another card introduction in step 2.
  • step 12 the data Dj must be sent to the network.
  • a block of three data is then formed: the value of the Tt field, the reference Dj of the data to be analyzed and the value "Val" of this data extracted from the memory of the terminal.
  • These blocks are stored one after the other in an area of the terminal memory called "ZDR". The content of this area is sent to the network at the end of the transaction or when the network requests self-diagnostic data. Once all the data has been transmitted, the ZDR area is emptied to be reused during a new card introduction.
  • step 13 the data Dj must be sent to the printer of the terminal for printing.
  • a message is then created in the printer's software buffer, it is composed of a text (ASCII code) recalling the nature of the data, for example "AMOUNT:” followed by the decimal or hexadecimal value of the data Dj, the message ends with a separator and a "RETURN TROLLEY - LINE JUMP". You can group all the self-diagnostic messages and print them at the end of the transaction.
  • step 14 the data must be sent to the terminal display for display.
  • a message is then created in the display buffer, composed of a text (ASCII code) recalling the nature of the data, for example "AMOUNT:” followed by the decimal or hexadecimal value of the data Dj.
  • the messages corresponding to each element (Tt, Dj, "3") are displayed successively for a certain time fixed by the program. We can group all the messages and display them at the end of the transaction, the scrolling of the messages can be controlled by pressing a key on the terminal keyboard.
  • step 11 the program loops back to step 11 and processes a new triplet.
  • steps 17 and 18 do not exist and the self-diagnosis function is executed only once or, indefinitely, until a new insertion of the test card switches the indicator again. lnd_DT in the inactive position.
  • the programmable memory of the common card contains in addition to the system zone ZS and the user zone ZU, a zone ZD which is identified by its start address: "ADD_ZD” and its end address "ADF-ZD” ( see figure 4).
  • the programmable memory of the common card also contains in its system area at a location (232) an "lnd_D" indicator signaling whether the self-diagnostic function is active or not. All this data ADD-ZD, ADF-ZD, Ind-D is stored in slots (230, 231, 232), of the ZS part of the programmable memory allocated to the operating system.
  • the two address values are determined and written during the personalization of the map of the ZD area, this method is simple to implement but has the disadvantage of requiring the reservation of an important location in all the maps that can be used for self-diagnosis.
  • the location of the zone ZD can be allocated dynamically by the operating system of the card following the correct presentation of the KD code.
  • the operator specifies on the map the number of triplets (Ti, Dj, Sk) or the number of bytes to reserve for ZD.
  • the card's operating system searches the programmable memory for a sufficient blank slot. If the memory does not contain such a blank location, the operating system returns an error message and interrupts the procedure for entering the self-diagnostic data. Otherwise, there is enough space.
  • the operating system stores the start address: "ADD_ZD" and the end address "ADF-ZD". We will see later how, after the execution of the self-diagnostic function, we can erase the presence of the ZD area and thus free this memory location.
  • a security procedure is provided to prevent a fraudster from using a common card to enter self-diagnostic data.
  • a challenge-response type mechanism with algorithm and secret code makes it possible to authenticate the operator and authorize the writing and reading (we will see why later) of the triplets in ZD.
  • the Sk code can take a fourth value: 4, this value indicates that the value of the Dj data to be checked is entered in the card.
  • the fifth triplet (225) in Figure 4 has this structure. When all the triples (Ti, Dj, Sk) (220 to 225) are entered in the ZD area, the "lnd_D" indicator is positioned active, signaling that the self-diagnostic function is active in this map.
  • FIG. 5 shows the flow of operations when the card described above is inserted into a terminal.
  • Step 1 is the initialization of the terminal after a power-up and step 2 is the waiting phase for a card introduction, the program continues, when the card is recognized as compatible with the application by recognition by the terminal of the presence of the necessary information.
  • step 2 the program selects the entity corresponding to the application.
  • the program selects the entity corresponding to the application.
  • the program can perfectly ignore that the self-diagnostic function is active.
  • step 3 the terminal tests whether the lnd_D indicator in the card is positioned active and therefore, whether the self-diagnostic function is operational.
  • the indicator can be emitted either by a particular value in the bytes emitted by the card during power-up, or by a particular value emitted during the selection of the entity corresponding to the application used on the card. If lnd_D is active, the program goes to step 4. During this step 4, the zone ZD is read using the two address values ADD-ZD and ADF_ZD and all the triplets read in the card are stored in the terminal's ZTD memory.
  • the operating system of the card returns in addition to the three values Ti, Dj and Sk, the address "Adr-v" in the fourth field reserved for entering the given in ZD and the number of bytes "Nb_v” of this field. For security reasons, read access to the ZD area of the card is only granted by the card's operating system if the lnd_D indicator on the card is active.
  • Steps 3, 4 and 5 are parts of the initialization sequence of the dialogue between the common card and the terminal and are executed before the execution of the application program.
  • the application software is broken down into basic tasks that can be individually tested.
  • the basic software takes control and tests if the internal terminal diagnostic indicator is active (step 7). If this is active, in step 8, the program searches if there is an element (Ti, Dj, Sk) stored in the zone ZTD which has a field value Ti equal to that of Tt. If yes: there is a datum (referenced Dj) to be checked following the task which has just been executed, the value of this datum is then temporarily stored in the memory of the terminal.
  • Sk it is processed as follows (step 9):
  • step 10 the data Dj must be sent by the terminal to the network.
  • a block of three data then consists of the value of the Tt field, the reference Dj of the data to be analyzed and the value "Val" of this data extracted from the memory of the terminal.
  • These blocks are stored one after the other in an area of the terminal memory called "ZDR". The content of this area is sent to the network at the end of the transaction or during a request by the network for self-diagnostic data. Once all the data has been transmitted, the ZDR area is emptied to be re-used during a new card introduction.
  • step 11 a message is created in the printer buffer, composed of a text (ASCII code) recalling the nature of the data, for example "AMOUNT:” followed by the decimal or hexadecimal value of the data Dj, the message ends with a separator and a "RETURN TROLLEY - SKIPPING".
  • ASCII code a text recalling the nature of the data, for example "AMOUNT:” followed by the decimal or hexadecimal value of the data Dj
  • step 12 a message is then created in the buffer of the display , composed of a text (ASCII code) recalling the nature of the data, for example "AMOUNT:” followed by the decimal or hexadecimal value of the data Dj.
  • the messages corresponding to each element are displayed successively for a certain time fixed by the self-diagnostic software.
  • all the messages can be grouped together and displayed at the end of the transaction, the scrolling of the messages can be controlled by pressing a key on the terminal keyboard.
  • step 13 a fourth field is reserved for this use in ZD, the address " Adr-v "in this fourth field and the number of bytes" Nb_v "in this field were stored in the ZTD area when loading the self-diagnostic data into the terminal.
  • the terminal therefore sends a write command to the card with the following parameters: Write address: Adr-v
  • the operator may want to perform only one test of the card reader terminal, then the data must not leave the terminal.
  • the data to be checked has a Sk type 4 field, a single storage is not possible.
  • the card To restart the function again, the card must be programmed again by the operator.
  • a terminal authorized to read them i.e. a terminal which is authenticated in the same way as when writing the self-diagnostic data.
  • the entire zone ZD can be erased. This erasure can be caused by a special command or when writing to the ZD area for the first time. The erasure, justified by security, also frees up the space occupied by the ZD zone. This location can be used by the application.
  • This "one-shot" style operation of the self-diagnostic function can be interesting, when a person returns his credit card to a bank branch by declaring that, on a certain type of payment terminal, his card "does not work ".
  • the person returns to the merchant where the terminal to be tested is located, performs a transaction and returns to his agency which analyzes or has the information stored in ZD analyzed remotely.
  • Single-shot operation is also useful for verifying the operation of a terminal suspected of fraud.
  • a banking organization notices that transactions on a terminal are credited without there being any
  • the banking organization will send controllers equipped with banal cards with the function of self-diagnosis. Upon their return, the data loaded in the card will be analyzed.

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'un 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ées 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 chaque terminal. 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, l'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, 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é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 (12) 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, l'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, l'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, D1 , 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 ; T1 , 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 : "ADD_ZD" 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 challenge- ré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 "lnd_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 l'indicateur lnd_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 lnd_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 11 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, l'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", l'indicateur lnd_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 lnd_DT en position inactive.
Il 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, l'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 challenge- ré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, l'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 lnd_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 lnd_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 lnd_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 la 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 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, le message se termine par un séparateur et un " RETOUR CHARIOT - SAUT DE LIGNE ". Avantageusement, on peut regrouper tous les messages et les imprimer à la fin de la transaction.
Si Sk est égal à "3", la donnée doit être envoyée vers l'afficheur du terminal, le programme se poursuit par l'étape 12. Au cours de cette étape 12, 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 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 lnd_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, l'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

REVENDICATIONS
1. 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 comportant un lecteur d'objet portatif, et coopérant par ledit lecteur avec un objet portable doté d'une zone de mémoire non-volatile (ZD) contenant des données, caractérisé en ce qu'il 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 comportent des moyens d'écriture dans l'objet portable connecté au terminal.
4. Terminal, selon la revendication 1 , 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 la revendication 1 , caractérisé en ce qu'il 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 la revendication 1 , 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 la revendication 7, 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 la revendication 7, 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 banale.
11. Procédé, selon la revendication 7, 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 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, de moyens de lecture ou de stockage, dans sa mémoire, de données (Ti, Dj, Sk) d'autodiagnostic ou de supervision et d'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, 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 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.
13. Objet portable selon la revendication 12, 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 la revendication 12, 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.
PCT/FR1997/002388 1996-12-24 1997-12-23 Terminal et procede d'autodiagnostic ou de supervision et objet portatif utilise dans un tel terminal ou procede WO1998028720A1 (fr)

Priority Applications (7)

Application Number Priority Date Filing Date Title
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
US09/125,714 US6253163B1 (en) 1996-12-24 1997-12-23 Portable object reader terminal and process for self-diagnosis and supervision of same
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
JP10528479A JPH11504748A (ja) 1996-12-24 1997-12-23 自己診断又は監視のための端末及び方法、ならびに該端末又は方法に使用される携帯品
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 (2)

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
FR96/15997 1996-12-24

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US09/827,905 Continuation US6505144B2 (en) 1996-12-24 2001-04-09 Portable object reader terminal, portable object, and process for self-diagnosis and supervision of same

Publications (1)

Publication Number Publication Date
WO1998028720A1 true WO1998028720A1 (fr) 1998-07-02

Family

ID=9499124

Family Applications (1)

Application Number Title Priority Date Filing Date
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

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 (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6968321B1 (en) * 1999-11-01 2005-11-22 Citicorp Development Center, Inc. Method and system for remote operator interface with a self-service financial transactions terminal

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2781592B1 (fr) * 1998-07-27 2000-09-08 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
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
DE10038764A1 (de) * 2000-08-09 2002-02-21 Bosch Gmbh Robert Verfahren zur Ferndiagnose und zentralen Fehlerauswertung von dezentralen elektrischen Geräten und dezentrales elektronisches Gerät hierzu
US6868507B1 (en) * 2000-11-07 2005-03-15 Intel Corporation Operating system independent
US6711520B2 (en) 2001-07-12 2004-03-23 Seagate Technology Llc Remote execution of diagnostic firmware in a block data storage device
US6694281B2 (en) 2001-07-12 2004-02-17 Seagate Technology Llc Real time signal analysis of a remote 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 엘지전자 주식회사 위치 추적 기능을 갖는 단말기의 성능 테스트 장치 및방법
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
US7231549B1 (en) * 2002-10-04 2007-06-12 American Megatrends, Inc. Method and apparatus for providing on-demand computer diagnostics
US7200775B1 (en) 2002-10-04 2007-04-03 American Megatrends, Inc. Method and data structures for use in providing on-demand computer diagnostics
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
KR101488317B1 (ko) 2005-12-20 2015-02-04 아비트론 인코포레이티드 리서치 작업을 수행하는 방법 및 시스템
US8041030B2 (en) * 2007-01-09 2011-10-18 Mastercard International Incorporated Techniques for evaluating live payment terminals in a payment system
US9038914B2 (en) * 2007-07-05 2015-05-26 Mastercard International Corporation Method and system for simulating a proximity-based transaction device
WO2009006635A1 (fr) * 2007-07-05 2009-01-08 Mastercard International Incorporated Procédé et système permettant de détecter un signal généré par un dispositif de transaction basé sur la proximité
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

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 (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6968321B1 (en) * 1999-11-01 2005-11-22 Citicorp Development Center, Inc. Method and system for remote operator interface with a self-service financial transactions terminal

Also Published As

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

Similar Documents

Publication Publication Date Title
WO1998028720A1 (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
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
CA2293297C (fr) Carte a puce comprenant des moyens pour gerer une memoire virtuelle, procede et protocole de communication associes
FR2612316A1 (fr) Carte a circuits integres ayant une capacite de verification d'erreur interne
FR2606909A1 (fr) Systeme de traitement pour un appareil electronique portatif, tel qu'une carte a circuit integre
EP0626664B1 (fr) Système de communication avec cartes à puce
FR2635891A1 (fr) Dispositif electronique portatif comportant des donnees-cle limitant l'acces a la memoire
EP0049650A1 (fr) Appareil de distribution d'objets et d'acquisition de services
FR2766942A1 (fr) Lecteur de carte a puce avec microcontroleur et composant de securite
FR2627609A1 (fr) Dispositif electronique portatif
CA2296009A1 (fr) Procede de gestion d'un terminal securise
FR2613851A1 (fr) Carte a circuits integres et procede pour y enregistrer des donnees
EP2569735B1 (fr) Carte de paiement comportant une puce de jeu electronique
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
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
EP0944880A1 (fr) Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires
FR2612668A1 (fr) Dispositif electronique portable
FR2771531A1 (fr) Procede, dispositif, systeme en reseau et support d'informations codees, automatiques de configuration securisee, de memorisation/acces et de calcul de cout d'applications
EP0948186A1 (fr) Carte à mémoire de test d'automate lisant des cartes à puce
FR2833093A1 (fr) Procede d'echange de blocs de donnees, procede d'echange et de traitement de blocs de donnees, objet portatif, et automate pour la mise en oeuvre de procede

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 97192506.2

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AU BR CA CN JP KR NO SG US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WWE Wipo information: entry into national phase

Ref document number: 1997952981

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2247474

Country of ref document: CA

Ref document number: 2247474

Country of ref document: CA

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 1998 528479

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 1019980706599

Country of ref document: KR

Ref document number: 09125714

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 56682/98

Country of ref document: AU

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 1997952981

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1019980706599

Country of ref document: KR

WWG Wipo information: grant in national office

Ref document number: 56682/98

Country of ref document: AU

WWW Wipo information: withdrawn in national office

Ref document number: 1997952981

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1019980706599

Country of ref document: KR