EP0907937A1

EP0907937A1 - Self-diagnostic or supervisory terminal and method and portable object used in such terminal or method

Info

Publication number: EP0907937A1
Application number: EP97952981A
Authority: EP
Inventors: Ronan Lapie
Original assignee: Bull CP8 SA
Current assignee: CP8 Technologies SA
Priority date: 1996-12-24
Filing date: 1997-12-23
Publication date: 1999-04-14
Also published as: CA2247474A1; WO1998028720A1; BR9707597A; NO983851L; US6505144B2; AR009843A1; AU5668298A; NO983851D0; FR2757664A1; JPH11504748A; US6253163B1; US20020022943A1; FR2757664B1; KR19990087204A; CN1212065A; AU723514B2

Abstract

The invention concerns a terminal equipped with an application programme, with at least one output consisting of either a display or a printer, or a communication network, or a portable object and co-operating with a portable object equipped with a non-volatile memory zone (ZD) containing data and comprising a reader communicating with said portable object. The invention is characterised in that the apparatus comprises means for reading or storing in its memory self-diagnostic or supervisory data (Ti, Dj, Sk) and means for transmitting said data to specific outputs (1-4) on the basis of information supplied by the self-diagnostic or supervisory data following the execution of at least one task (Tt) of its application programme relative to the portable object.

Description

TERMINAL AND SELF-DIAGNOSIS OR MONITORING METHOD AND PORTABLE OBJECT USED IN SUCH A TERMINAL OR METHOD

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.

In general, 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.

In all cases, we must be able to validate or test the terminal as a whole. 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. However, 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.

To this end, 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. with 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.

According to another characteristic, the means for transmitting the self-diagnostic data are activated a certain number of times.

According to another characteristic, the means for transmitting the self-diagnosis or supervision data comprises means for writing to the portable object connected to the device.

According to another characteristic, 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.

According to another characteristic, 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.

According to another characteristic, 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.

This object is achieved by the fact that 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:

- to execute a task of the application program on the terminal;

- to test an indicator either in the terminal or in the portable object to determine whether a self-diagnostic or supervision function is operational, then in the case of a positive response;

- To search in the memory of either the portable object or the terminal if there exists among the information triplets stored a triplet whose first information corresponds to the determined task executed by the terminal or the card; - to send to the output specified by the triplet thus read the value of the data correlated to the task executed and to reference by the second information of the triplet.

According to another particular feature, 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.

According to another particularity, 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.

According to another particular feature, 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.

According to another particular feature, 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.

This object is achieved by the fact that 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.

According to another particular feature, 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.

According to another particular feature, 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.

Other particularities and advantages of the present invention will appear more clearly on reading the description below made with reference to the appended drawings in which:

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.

On the other hand and always during a transaction, 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. During the execution of each elementary task, each of these data can be initialized, modified or unchanged. 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;

To do this, 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. To control the correct progress of a transaction, 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 value of this code specifies the type of output used to send the data to be checked: to the network when Sk is at a first value, for example "1" (Sk = 1), to the printer when Sk is at a second value for example "2" (Sk = 2), or to the screen when Sk is at a third value for example "3" (Sk = 3). 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.

Let us first describe the case where a special card called "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.

In anticipation of the storage of self-diagnostic data, 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. Thus 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. It is obvious that 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. Advantageously, the data Dj is the physical address of the data to be checked in the working memory of the terminal.

Once programmed, the test card is inserted into the terminal in which the self-diagnostic function must take place. 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. In 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).

Once the test card has been identified and authenticated, 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. Once the last triplet has been stored in the ZTD area, the terminal program, in step 7, 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.

A new card is introduced, it is a banal card, compatible with the application processed by the terminal. It has been said previously that the application software in the terminal is broken down into elementary tasks Tt which can be individually executed (step 8). At the end of the execution of each task which can be referenced by the code Tt, the application program tests in step 9 the indicator lnd_DT of the terminal. If it is inactive, the self-diagnostic function is not operational, the program continues to perform the other tasks. If the lnd_DT indicator is active, the terminal program searches in step 10 in the ZTD area of the terminal memory for the first triplet (Ti, Dj, Sk) for which Tt = Ti, that is, s' there is a data to test following the task which has just been executed. If yes, in step 11, the value "Val" of this datum (Dj) is temporarily stored in the memory of the terminal and according to the value of Sk, it is processed as follows:

If Sk is equal to "1" (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.

If Sk is equal to "2" (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.

If Sk is equal to "3" (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. Once the data Dj has been processed, the program checks in step 15, whether there are other triples in ZTD for which Tt = Ti. If yes, the program loops back to step 11 and processes a new triplet. For each elementary task, the search for triples is carried out by scanning the entire ZTD area. If there are no more triples (Ti = Tt, Dj, Sk) to be processed, the program, in step 16, continues in sequence and possibly passes in a variant to another task without performing the steps 17 and 18 described below. If there are no other tasks to perform, the program loops back to step 3, awaiting an order or a new card introduction.

It is possible to associate an initialized counter with a certain number with the indicator Ind-DT in the terminal so that, the self-diagnostic function is activated only for this number of introduction of banal card. To do this, the operator has previously entered this number in a specific location (21, fig. 2) in the programmable memory of the test card for example, next to the locations (230, 231) of ADD_ZD and ADF-ZD . This number is in this case stored in the memory of the terminal after the introduction of the test card, in step 6. Then this number is decremented (step 17) at each end of execution of a self-diagnostic function , (YES output from step 16). When this changes to "0", the lnd_DT indicator is positioned inactive (step 18) and, possibly, the content of the ZTD zone is erased.

If this counter is not installed, 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.

It is possible to avoid the use of a test card and to use only standard cards provided that they support the special functions of self-diagnosis. For this, 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.

Advantageously, 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 then 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 then 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.

In the same way as for the test card. 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.

In the case of a common card used to transmit the self-diagnostic data, 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. A fourth field located at an address "Adr-V" is then allocated following the triplet (Ti, Dj, Sk = 4) and therefore quadruplets are stored. The size of this field corresponds to that of the data to be entered, the operator must therefore specify the number of "Nb-V" bytes in this fourth field and its content is made up from the address (Adr-V) write then as we will see later after the output with the value "Val". 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.

Figure 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. In this step 2, the program selects the entity corresponding to the application. Unlike the test card, when the common card is inserted by the holder, the latter can perfectly ignore that the self-diagnostic function is active.

In 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. If the triplet contains information Sk whose value is "4", 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. Once all the information contained in the zone ZD has been stored in the memory zone ZTD of the terminal, the terminal positions its self-diagnostic indicator Ind-D in the active position (see step 5 of FIG. 5). 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. We said earlier that the application software is broken down into basic tasks that can be individually tested. At the end of the execution of each task that can be referenced by a Tt number (step 6), for example 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. Depending on the value of Sk, it is processed as follows (step 9):

If Sk is equal to "1" (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.

If Sk is equal to "2", the data must be sent to the terminal printer, the program continues with step 11. During this 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". Advantageously, we can group all the messages and print them at the end of the transaction.

If Sk is equal to "3", the data must be sent to the terminal display, the program continues with step 12. During this 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 (Tt, Dj, "3") are displayed successively for a certain time fixed by the self-diagnostic software. Advantageously, 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.

If Sk is equal to "4", the data must be stored in the card, the program continues with step 13. During this 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

Number of bytes to write: Nb-v

Value to write: "Val" that of the Dj data.

Writing to the ZD area is only authorized by the card's operating system in the fourth field of a Sk = 4 type triplet corresponding to the Ti. In the case where the triplet Ti of the card is not of the Sk = 4 type, the writing is refused. An execution report is systematically sent back to the terminal after each write command, if this has not been completed, the terminal notifies the user by a message. The use of the stored data is explained below. A variant consists in temporarily storing all the values of the data Dj of type Sk = 4 and in performing the commands for writing the values at the end of the transaction.

Once the data Dj has been processed, in step 14, the program checks whether there are other triplets in the zone ZTD for which Tt = Ti. If yes, the program loops back to step 9 and processes a new triplet. For each elementary task, the search for triples is carried out by scanning the entire ZTD area. If there are no more triples (Ti = TT, Dj, Sk) to process, the program goes to step 15, looking for another task to execute. If there are no other tasks to perform, the program loops back to step 2, waiting for a new card introduction. In the case of a common card used to transmit the self-diagnostic data, the self-diagnostic function must be able to be executed only once. Indeed, the operator may want to perform only one test of the card reader terminal, then the data must not leave the terminal. In addition, if the data to be checked has a Sk type 4 field, a single storage is not possible. To restart the function again, the card must be programmed again by the operator. To avoid being used several times with the self-diagnosis function, just after the ZD zone has been read by the terminal, the card's operating system will set the lnd_D indicator to the inactive state. For security reasons, it can also erase all triples of type Sk = 1, 2 and 3. The Ind-D flag is inactive, reading of the ZD zone is no longer possible.

The data corresponding to the Sk = 4 type is processed when the common card passes through a terminal authorized to read them, i.e. a terminal which is authenticated in the same way as when writing the self-diagnostic data. . Once all the triplets have been read, 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 agency will save the self-diagnostic data in this card by specifying that the transaction data (amount, date, certificate value) will be written to the card by positioning in each triplet corresponding to a task to save the third field Sk to the value "4" (Sk = 4). 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

debit requests on customer accounts. 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.

Another example: a bank can find it interesting to know quickly when and where a card is used for the first time. For this, before issuing the card to its holder, the latter contains two triples of type Sk = 1 in which each third field Sk is at the value "1". In the ZD area, with the Dj data corresponding to the date of the transaction and the Dj data corresponding to the identity of the terminal. During the first transaction, the two blocks (Ti, Dj, "date") and (Ti, Dj ', "terminal identity") will be sent immediately over the network.

Claims

1. Terminal equipped with an application program, at least one output consisting either of a display, or of a printer, or of a communication network, or of a portable object and comprising a portable object reader, and cooperating by said reader with a portable object provided with a non-volatile memory area (ZD) containing data, characterized in that it comprises means for reading or storing, in its memory, data (Ti, Dj, Sk) for self-diagnosis or supervision and a means for transmitting said data to specified outputs (1-4) as a function of information provided by the self-diagnosis or supervision data following the execution of at minus a task Tt of its application program in relation to the portable object.

2. Terminal according to claim 1, characterized in that the means for transmitting the self-diagnosis data are activated a certain number of times.

3. Terminal according to claim 1, characterized in that the means for transmitting the self-diagnosis or supervision data comprise means for writing to the portable object connected to the terminal.

4. Terminal according to claim 1, characterized in that the self-diagnosis or supervision data are constituted by at least one triplet

(Ti, Dj, Sk) of information corresponding for a first information (Ti) to a determined task of the application program, for the second information (Dj) to a type of data correlated to the task executed and to be presented to a output, and for the third information to a value (Sk) of specification of the output to which the type of data must be presented among those present on the terminal.

5. Terminal according to claim 1, characterized in that it has a means for testing the presence of self-diagnosis or supervision data in a portable object and for triggering the reading and storage of this data in a specific zone ZTD of the terminal memory.

6. Terminal, according to claim 1, characterized in that it comprises means for introducing self-diagnosis or supervision data into a portable object.

7. Method for supervising the operation of a terminal or for self-diagnosis of a terminal from an information triplet corresponding for a first item of information to a determined task of an application program executed either by a portable object either 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 for specifying the output among those present on the terminal characterized in that it consists of:

- to execute (9) a task of the application program on the terminal;

- to test (9) an indicator either in the terminal or in the portable object to determine whether a self-diagnostic or supervision function is operational, then in the case of a positive response;

- to search (9) in the memory of either the portable object or the terminal if there exists among the information triplets stored a triplet whose first information corresponds to the determined task executed by the terminal or the card;

- to send to the output specified by the triplet thus read the value of the data correlated to the task executed and to reference by the second information of the triplet.

8. Method according to claim 7, characterized in that it comprises a test step (16) consisting in determining if there are other tasks to be performed and following the execution of these tasks to be searched for all the information triples corresponding to the execution of this task.

9. Method according to claim 7, characterized in that it comprises a step of reading a portable object memorizing in its non-volatile memory a plurality of triplets and a step (6) of storing these triplets in an area terminal non-volatile memory tracked a step (7) of activating a self-diagnostic function or active supervision indicator.

10. Method according to claim 7, characterized in that it comprises a test step (3, 4) to determine whether the portable object is a card specific to the self-diagnosis or supervision function or a so-called ordinary card .

11. Method according to claim 7, characterized in that the self-diagnosis or supervision data are constituted by a fourth information field initially containing in the portable object the write address (Adr-V), the number of bytes to write (Nb-V), after the self-diagnostic operation the value to write (Val).

12. Portable object usable with a terminal equipped with an application program, at least one output constituted either by a display, or by a printer, or by a communication network, or by a portable object, of means of reading or storing, in its memory, data (Ti, Dj, Sk) for self-diagnosis or supervision and a means for transmitting said data to outputs (1-4) specified as a function of information supplied by the self-diagnosis or supervision data following the execution of at least one task Tt of its application program in relation to the portable object, characterized in that it comprises a microprocessor card operating thanks to a system operating system stored on the card and comprising a non-volatile memory containing at least one triplet (Ti, Dj, Sk) of information in a determined ZD area of this non-volatile memory whose position is defined by fields of address located in the part of memory used to store the operating system.

13. Portable object according to claim 12, characterized in that the part (25) of non-volatile memory used to store the operating system also includes in a memory field information constituting a counter (21) for using the self-diagnostic function.

14. Portable object according to claim 12, characterized in that the memory area (25) storing the operating system includes a field for storing an indicator (232) for activating the self-diagnosis or supervision function.