MXPA97006234A - Circuit controlled transaction management system integr - Google Patents

Abstract

A transaction management system controlled by integrated circuit that uses an interpreter that has to do with the execution of an application, be it in an ICC, or a terminal, or both, is particularly capable of executing an application between the ICC and the terminal connected or not to a central unit, when the interpreter in the terminal is able to access it, uses at least a part of the terminal memory and at least a part of the peripherals of the terminal, while an optional interpreter in the ICC is able to access and use at least a part of the ICC memory and at least a part of the peripherals of ICC

Description

TRANSACTION MANAGEMENT SYSTEM CONTROLLED BY INTEGRATED CIRCUIT DESCRIPTION OF THE INVENTION The present invention relates to an integrated circuit-controlled transaction management system which intends to execute a transaction between an integrated circuit card (ICC) and a terminal connected or not to a central unit, a transaction consisting of at least one execution of the following sequence: 1. create a communication link between the ICC and the terminal; 2. perform a compatibility check to ensure that the ICC and the terminal are mechanically and electrically compatible; 3. select from an application supported by both the ICC and the terminal, representing the section of a computer program and the group of associated data that define the transaction in terms of the combination of ICC and specific terminal present; 4. execute the application in the ICC and terminal system, and 5. terminate the transaction, which optionally includes breaking the communication link between the ICC and the terminal. WO 92/13322 describes a secure method for loading a plurality of applications into a microprocessor memory ICC, containing means for creating a communication link in an ICC and terminal system. There are several types of transactions between an ICC and a terminal: the terminal can control access to places where only ICC carriers can access; in so-called financial transactions, the ICC may be charged with indications representing consumer items that are obtained at a terminal site (eg, frequent flight miles, telecommunication units, etc.), or the ICC can act as a repository of bank account information, allowing more general financial transactions; or the ICC can be used as data storage, for example, as an ICC registry storage or identity doctor. The known aspects of the ICC and terminal system are: 1. The terminal hardware (i.e., the processor and the peripherals, which at least include the ICC communication device) has access through a terminal operation system. The terminal operation systems are specific to the vendor. 2. Each terminal that participates in certain types of standardized transaction types (for example, international financial transactions) supports, for those transactions, a common standard that allows ICCs to perform applications in a normal way with terminals from any vendor. As an example, international financial transactions are currently based on inter-industry standards as defined in ISO 7810/7811/7812/7813/7816. 3. Each provider of standardized transactions in a terminal has to provide an application, that is, a program and the associated data group, or an application specification, defined in terms of a common standard. 4. Some parts provide applications or specifications of specification applications that are only partly developed in a common standard. For special requirements, which are outside the scope of the common standard, such parts need to be based on the terminal operation system. 5. Other parties provide applications or application specifications, which are proprietary or not based on any common standard. In this case, they only rely on the terminal operation system to perform the transaction. 6. Each application program needs to be compiled and linked separately for each type of terminal. This means that the specific software must be resident in the terminal for each application. 7. Applications define large groups of terminal parameters that govern the rules of their acceptance. These parameters may be necessary to be shared with other applications. 8. The application software must be physically installed in each terminal. 9. Different software application versions may be required that define the same transaction in the terminal during more or less extended conversion periods. Aspects associated with the known ICC and terminal system loaded with multiple applications, impose heavy restrictions on terminal hardware, which must be available to store and manage all possible application software and classified data groups. In addition, a considerable logistical effort is essential to manage the distribution and maintenance of all the software in all the terminals. Those aspects have the following disadvantages: * They change specifications or parts of terminal software of the same, change specifications or parts of the application software of the same or change implementations of a specification or parts of it or create new applications that require the development new software for each type of target terminal and to load this new software in each target terminal. In addition, certification against all types of ICC in circulation at that time and against those marked for future release, is required; * Restricted flexibility since minor changes to a common standard have to be agreed between all the parties that use it; * Each application requires storage capacity in the terminal, which is limited; * Common standards are not complete enough to support all the owner's needs; * The applications need to be implemented carefully, so that neither their programs nor their parameters interfere with each other; * This aspect reduces the ICC to a mere memory device, since it is not possible to give the ICC control over each type of terminal due to the plethora of different operating systems in use.

The aforementioned disadvantages result in the lack of flexibility of the ICC and terminal system. Therefore, the time to sell new, updated or improved applications is extremely long, in the order of several years since all ICC and all terminals are affected. The present invention aims to facilitate the handling of all possible applications with all possible ICC in all possible terminals. This purpose is achieved through an ICC transaction management system of the type described in the preamble of appended claim 1 using an interpreter, which has to do with the execution of an application either in the ICC or in the terminal , or in both, so that the interpreter in the terminal is able to access and use at least a part of the terminal memory and a part of the peripherals of the terminal, for example, board, screen, printer, modem , whereas an optional interpreter in the ICC is able to access and use at least a part of the ICC memory and at least a part of the ICC peripherals, for example, keyboard, screen. In reality, an interpreter performs the interpretation between a program written in a high-level compact and universal language and a specific language to operate the terminal or the CCI. For all practical purposes, an interpreter consists of a program that reads an input current (the interpreter in the ICC reads the input current coming from the terminal and the interpreter in the terminal reads the input current coming from the ICC ) and one or more dictionaries, so a dictionary is a collection of words, each referring to executable statements. The language of the interpreter is independent of the ICC and terminal system, and may be, for example, FORTH (see standard ANSI: X3J14 Secretary, c / o FORTH Inc. 111 Sepulveda Blvd. Suite 300, Manhattan Beach, CA 90266). A first advantage of using an interpreter in a transaction management system controlled by ICC according to the invention, is the possibility of storing new applications or parts thereof or updating or improving existing applications or parts thereof in the encrypted ICC in an interpreted language. This allows to reduce the time to sell new applications or update or improve existing applications or parts of them. The time or effort required to sell new updated or improved applications is reduced to the time or effort required to load them in terms of the interpreter's language in the ICC, which may require loading of new dictionaries, improved or updated in the ICC. In this way, the ICC has control over the application. No effort or time is required to update the terminals. Even when changes must be made to the terminal dictionaries, it is sufficient to upload the new definitions, updated or improved in the ICC during an introductory or reconversion period until the new, updated or improved definitions are available in the terminal. It is possible to implement the. ICC system and terminal in such a way that new definitions, updated or improved in the ICC are transferred to the terminal during a transaction and stored permanently in the memory of the terminal, afterwards. The operation of the functionality of the terminal is reduced to the installation once the same interpreter program and the same interpreting language dictionary, hereinafter referred to as the interpreting core dictionary, either during the manufacturing procedure of the terminal or after It is possible to update or improve the interpreter after the installation of the terminal, for example, through an on-line upload or through an ICC. Additional optional dictionaries, for example, owner dictionaries or common standard dictionaries, they can be loaded in the terminal. A second advantage of using an interpreter in a transaction management system controlled by ICC according to the invention, is that the support for many applications in the terminal is reduced to the availability in the interpreter program terminal and the core dictionary interpreter and identifications of the supported applications. Additional dictionaries are optional. A third advantage of using an interpreter in the transaction management system controlled by ICC according to the invention is the possibility that the ICC completely defines, and therefore controls, the application. The present invention provides the possibility of efficiently managing many applications in many fundamentally different terminals and the possibility of installing new or improved applications or parts thereof in a very efficient way, in order to have an extremely short time to sell the new transactions, updated or improved and allow the ICC to control the transaction. The positive implications of the above are: * Change the specifications of the terminal's software that only affects the implementation of the interpreter on that terminal. The only effort required to maintain compatibility with existing applications is to ensure that the interpreting program and the interpreting kernel remain implemented correctly.

Therefore, only a software needs to be recertified, and only against a specification, mainly the definition of interpreter. CCIs do not need to be recertified since the interpreting language used in the application requires the same specification. * The need for common standards is reduced to the capacity of the interpreter since a normal function can be encoded in the interpreting language and stored in the ICC. * The introduction of new, improved or updated applications does not need to affect the dictionaries that have to be stored in the terminal, since all applications and related dictionaries are defined in terms of the interpreting language and can be loaded into the ICC. * The application data groups are all handled by the interpreter, which facilitates their management. * The ICC can actively take part in the implementation of the application program or parts thereof, also implementing an interpreter program and core dictionary in the ICC. If the CCI is an ICC of mere memory, it can continue to control the application through the complete storage of the same, that is, the terminal acts completely according to the definitions of the CCI.

Some applications may require specific security services, for example, data integrity, ICC authentication, terminal authentication or data confidentiality. This can be provided with the state of the techniques as defined, for example in ISO 10202. According to a first particularity of the invention, an application consists of one or more functions, each function consisting of a control part referred to as the head of the function of an executable part named as the body of said function. The head determines which bodies have to be executed and under what conditions. Both parts of the function are capable of being independently stored in a dictionary. Functions can be defined in terms of other functions, that is, functions can be nested. A body that is stored in a dictionary has access through its body name, and a head stored in a dictionary has access through its head name. This does not in any way prevent programming a function in the interpreting language, it merely offers the possibility of writing compact and even flexible applications by carefully mixing the body names, the head names and the interpreter language code. The same functions can also be stored in dictionaries, named by their head names. This reference method allows to define each function in four ways: 1. Both the head and the body can be the interpreting language code; 2. The head can be the interpreter language code, while the body is activated through its body name; 3. The head is defined by its head name, while the body is fully expanded in the interpreting language code; 4. Both head and body are stored as reference, head name and body name, respectively. The invention allows the presence of several types of dictionaries in the ICC and terminal system: 1. The interpreter core, a mandatory dictionary; 2. A number of optional dictionaries that include definitions that relate to: a) certain types of standardized transactions, for example, the dictionary that contains all the functions defined in ISO / IEC 7816 used in international financial transactions, referred to as the dictionary of norm; b) owner transactions that do not require normal definitions, called as the owner's dictionary; The dictionary defined in the ICC may contain new, improved or updated functions or parts thereof. Those dictionaries usually take precedence of terminal dictionaries. Nevertheless, the security of some applications may prohibit the redefinition of certain words in certain dictionaries. Security aspects can be provided through the specific protection mechanisms available in the state of the interpreter's implementations of the technique. The invention allows an application to be efficiently stored in the ICC and allows flexible execution in the ICC and terminal system. Actually, the following scenarios are possible thanks to the invention: 1. The transaction completely adheres to a standard. This means that the ICC only has to store the name of the function of the application; which is defined in the normal dictionary of the terminal; 2. If the transaction is proprietary and the application is defined in the terminal, it communicates with, the ICC only has to store the function name of the application, which is defined in the owner's dictionary in the terminal; 3. If the transaction is proprietary and the application is not defined in the terminal with which it is communicated, the definition of the application must then be stored in the ICC, in the ICC dictionary. The functions of the application can use body names and head names of both normal and proprietary dictionaries, but can also include interpreter language code.

Example 1: Assume an application with the following head (giving a pseudocode): if (x = l) then func_a (y) then if (x_2) then func_b (y) then func_c (y) so func_a, func_b and func_c are defined in the terminal owner dictionary. Assuming that func_a (y) = y + x, in that dictionary. Then the head as represented above, is all the needs that are stored in the ICC that will be able to execute them. In this case, there is no need for an ICC dictionary.

Now, assuming the interpreter implementation that allows ICC dictionaries to take precedence over the terminal dictionaries, and assuming that the application provider wants to redefine func_a (y), func_a (y) = y-x. In this case, you can still use the same head, and now you have the choice of either updating all owner dictionaries in all terminals, or including the new definition in the ICC dictionary. This new definition will then be used during the execution of the application. The invention allows that: a) an ICC dictionary can be used to add, improve or update terminal dictionary definitions. A mechanism to do, that is, for example, provided in the FORTH language, where the last defined words can redefine previous dictionary entries. b) some dictionaries, for example, the interpreter kernel or the normal dictionary for some applications, can be protected against deletion and redifinition. The techniques for achieving such protection are established in art; an example is shown in WO90 / 05347. The following execution scenarios are possible thanks to the invention: 1. The terminal executes the application program or parts thereof, so the ICC only acts as a data container and possibly as a storage device for the application program of owner, or parts thereof. 2. Both the ICC and the terminal execute parts of the application. For security reasons, it may be required that certain data do not leave the 'ICC, therefore, all manipulations involving such data must be executed by the ICC. In this way, the ICC and the terminal communicate the results of data manipulations instead of the same data. 3. The ICC executes the application, so the terminal only needs to contain application identifications that it supports. In this case, the terminal can be used as a mere storage device, for example, the terminal can provide the ICC with a dictionary that contains definitions of functions in terms of interpreter language that are used during the execution of the application by the ICC. This allows the ICC to use definitions without having to store them. The above means that the invention provides the following advantages: 1. The flexibility to define, improve or update applications that easily and quickly store them in the ICC, based on the terminal interpreter for execution and based on the dictionary of the interpreter core of terminal for definitions. 2. The flexibility to store applications in a compact form in the ICC using dictionaries in the terminal. 3. The flexibility of executing the application either in the ICC, the terminal or both in the ICC and in the terminal, depending on the availability of the processing power in the ICC and in the terminal. 4. The flexibility to allow multiple CCIs to participate in a transaction. The interpreter can be implemented in a multiple ICC connector terminal. In such a system, it is possible to provide applications, either stored in one or more ICC, a terminal or any combination of terminal and ICC, that perform ICC transactions to ICC. In this case, the terminal can be very simple, only providing the means of communication between the CCIs and possibly providing some dictionaries to reduce the storage requirements in the CCI. CCIs can also provide resources to each other. 5. The flexibility to control the transaction of the ICC, the terminal or both the ICC and the terminal.

The transaction is the result of the execution of an application and, therefore, is totally determined by the application program and the associated data group. Since such transaction control or parts of it is determined by the contribution of the ICC, the terminal or both the ICC and the terminal. When the transaction is completely determined by an application resident in the terminal, the card can only contribute to the application with a group of data it contains and then suffers the transaction. When the transaction is completely determined by the application resident in the CCI, the terminal contributes with it to its data group and suffers the transaction. The terminal and the ICC can also perform the transaction in the same way, so both determine and carry out the transaction. It may happen that the ICC and terminal system is connected to a central unit, from which additional services are requested, in which case, the central unit can contribute dynamically to the application. For example, the ICC can force the terminal to connect to its central unit and request the update of data in the ICC. The control of the application does not need to be strictly in the ICC or in the terminal. In an initial step, an application has to be selected for execution in the ICC and terminal system. This selection is trivial, when the ICC and the terminal have no application or exactly one application in common. When multiple applications are supported by both the terminal and the ICC, the current practice is to leave the ICC support or the terminal operator interactively defining which application to choose. This is not excluded by the invention, which also provides an intelligent mechanism for selecting the application, depending on the ICC parameters, terminal parameters and ICC capabilities and terminal capabilities. In fact, after the insertion of the ICC in the terminal and after the ICC has satisfied all the compatibility checks, the first action the terminal takes is to verify if the ICC supports an application that it knows. In order to find this, the terminal will try to consecutively select one of its resident applications. If an application is present in the ICC, the ICC contains the description of the application. According to the invention, a possible body in the application head is an application selection function. This application selection function will be executed by the interpreter with arguments determined by the ICC. This means that with the application supported by the terminal and defined in the ICC, the selection of one of many applications only defined in the ICC, becomes possible. Since the bodies of an application selection function can be application selection functions, the application can be recursively selected.

Example 2: The following example was considered: The ICC contains the following applications: Euro, Euro-Debit, Euro-Credit, Us-Debit, Us-Credit. The terminal only knows the Euro application. When the terminal inspects the CCI, the result of the selection application function will be Euro and its related data. The Euro application definition can be stored either in the terminal or in the ICC. If it is assumed that it is stored in the ICC it can be defined as follows (in pseudocode): start if (amount of ICC <100) then if (the terminal is located in Europe) then select Euro-Debit from the application anywhere if (the terminal is located in the US) then select the US-Debit application anywhere abort the transaction anywhere if (the terminal is located in Europe) then select the Euro-Credit application anywhere if (the terminal is located in the US) then select the US-credit application anywhere abort the transaction end transaction, where * the text not underlined means the head, and underlined text means a body. In this case, only the terminal that knows EURO can select applications defined in the ICC. Any implementation of the present invention provides the following efforts: 1. If the ICC is to be used as a mere memory ICC: a) implement a secure interpreter in the terminal, with its interpreter core dictionary; b) define and implement dictionaries for the application; c) implement the application in the interpreting language, making possible the use of available dictionaries; d) implement a mechanism to use the ICC dictionaries. 2. If the ICC takes an active part in the execution of the application: a) implement an insurance interpreter and its core dictionary in the terminal and implement an insurance interpreter and its core dictionary in the ICC. b) define and implement dictionaries for applications; c) implement the application in the interpreting language, making possible the use of the available dictionaries; d) implement a mechanism on the terminal to use the ICC dictionaries; e) implement a mechanism in the ICC and the terminal to manage the execution of the applications in the ICC and terminal system; f) implement a mechanism on the card to use terminal dictionaries. The invention is obviously not limited to a transaction management system using a card. Many changes can be made in the form, arrangement and constitution of the integrated circuit carrier, without departing from the scope of the invention, for example, a key or a symbol.

Claims (12)

1. A transaction management system controlled by integrated circuit that aims to execute between an ICC and a terminal connected or not to a central unit, a transaction consisting of at least one execution of the following sequence: a) creating a communication link between the ICC and the terminal; b) perform a compatibility check to ensure that the ICC and the terminal are mechanically and electrically compatible. c) selecting an application contained in the ICC and the terminal, which represents the selection of the computer program and the group of associated data that define the transaction in terms of the specific combination of ICC and present terminal; d) execute the application in the ICC-terminal system, and e) finalize the transaction, which optionally includes breaking the communication link between the ICC and the terminal, characterized in that it uses an interpreter that has to do with the execution of an application , either in the ICC or in the terminal, or in both, so that the interpreter in the terminal is able to access and use at least a part of the terminal memory and at least a part of the peripherals of the terminal. terminal, while an optional interpreter in the ICC is able to access and use at least a portion of the ICC memory and at least a portion of the ICC peripherals.

2. A transaction management system according to claim 1, further characterized in that each application consists of a number of functions, each function consists of a control part called the head and an executable part called the function body, both parts of the function possibly being independently stored in a dictionary.

3. The transaction management system according to claim 1, further characterized in that the functions can be nested.

4. The transaction management system according to any of claims 1 to 3, further characterized in that a function in the application prescription is a "selection application function", which is executed by the interpreter with arguments determined by the ICC , so that the application selection can be executed recursively.

5. The transaction management system according to any of the preceding claims, further characterized in that the interpreter in the ICC is able to access and use at least a portion of the ICC memory and at least a portion of the associated peripherals of the ICC.

6. The transaction management system according to any of the preceding claims, further characterized in that the interpreter in the terminal is capable of accessing and using at least a part of the terminal memory and at least a portion of the peripherals of the terminal. the terminal.

7. The transaction management system according to any of the preceding claims, further characterized in that the ICC is a mere memory ICC that undergoes the transaction determined by the terminal.

8. The transaction management system according to any of claims 1 to 6, further characterized in that the ICC determines the transaction and the terminal that only needs to recognize an application in the ICC and that is capable of selecting it, suffers the transaction.

9. The transaction management system according to any of claims 1 to 6, further characterized in that the ICC and the terminal both determine and perform the transaction.

10. The transaction management system according to claim 8, further characterized in that the terminal is a pure interface device between an ICC number.

11. The transaction management system according to any of claims 7 to 9, further characterized in that each ICC contains a different customized application.

12. The transaction management system according to any of the preceding claims, further characterized in that an interpreter is implemented in a terminal with many ICC readers, and provided with applications, either in the ICC, in the terminal or in both, that perform the combination of transactions.