SI9720049A - Portable, secure transaction system for programable, inteligent devices - Google Patents

Abstract

The present invention provides a transaction management system for executing transactions between a first device (1) and a second device, said first and second devices being adapted for communication with each other and at least one of said first and second devices being an integrated circuit card, said system comprising: at least one input/output device (25); a portable virtual machine (20) for interpreting a computer program on said first device, said virtual machine comprising a virtual microprocessor and a driver for said at least one input/output device (25); and execution means responsive to said interpreted program for executing said program. The general linking technical concept behind the present invention is portability combined with security of data and run-time guarantees in a transaction system which are independent of the target implementation provided compile time checks are passed successfully. This concept is achieved by: using a virtual machine as an interpreter, including a driver for the I/O devices in the virtual machine so that application programs have a common interface with I/O devices and are therefore portable across widely differing environments, allocating and deallocating memory and including an indication of the amount of memory in the application program which means that the program will only run successfully or it will not run at all and security management functions are reduced to a minimum which improves operating speed, and providing a secure way of importing and exporting data in and out of application programs and databases.

Description

EUROPAY INTERNATIONAL N.V.

A portable, secure transaction system for programmable intelligent preparations

The present invention relates to a system incorporating programmable, intelligent devices such as terminals and integrated circuit cards, as well as the process of operation of such cards and terminals involving automatic voice machines, personal computers, pay-TV units, point-of-sale terminals, health cards or the like. It is especially suitable for use in the execution of financial transactions.

Technical background

Different types of terminals are known for performing transactions, e.g. financial transactions involving the transfer or exchange of value or transactions of a commercial nature, such as medical card transactions or access to data in general, e.g. SIM card with GSM mobile phone. Terminals are known, such as point-of-sale (POS) devices, automatic speech machines (ATMs), or GSM mobile phones. The actual products range from small, hand-held devices with simple 8-bit microprocessors, such as the Intel 8031/8051 series supplied by Intel Corp., USA, or integrated circuit ICCs, to 32-bit computers that run operating systems , such as UNIX ™ or Windovs NT, provided by Microsoft Corp., USA. Some of these machines work with a personal user card, which can be a magnetic stripe card, smart card, or ICC, which stores the user-specific identification and confirmation information required before communication between the user and the terminal can begin. The user installs the card in a card reader connected to the terminal, a terminal resident program is executed in the terminal and the card is checked, and the user's information is tested to confirm it and if necessary pass on a password or private number as is a PIN (Personal Identification Number). After confirmation, the program normally allows the user to select the desired services to be performed, e.g. cash withdrawal, current account check. The terminal may be stand-alone or connected to a larger computer either locally or through a telecommunications network. Such terminals are often available 24 hours a day and have to run at minimum maintenance and with a high level of security.

Such terminals represent a significant investment in hardware and are not typically replaced at frequent intervals. Updating of software and programs running at such terminals becomes necessary when new services are offered and must be performed safely. Generally, terminal management organizations, such as banks, require that each update be confirmed. Such updating may be performed manually or remotely over a private or public communications network, as known from US Patent 5,434,999. Such known schemes require that the type and model of the terminal for new developments be known, as must be specifically created by the software for each terminal for that type of terminal, and are therefore cost-intensive. To be able to offer services from all possible organizations offering similar services, e.g. any banks or credit institutes, furthermore, the terminals must be able to handle all the programs of all organizations. Due to the high mobility of both private and business people, it is preferable that all services offered in one country are available at each terminal. This would result in unnecessarily high processing capacity and memory size for each terminal. Furthermore, each of these programs must be updated as required. One solution could be to use a small workstation for each terminal, possibly connected to a telecommunications system. Such a system would be capable of counter-processing and could switch to online processing of unusual transactions or to automatically update resident programs. Workstations would e.g. required the implementation of the complex validation and coding schemes necessary to maintain security on a system exposed to attack through public telephone networks. With increasing size and complexity, the problem of maintaining security would also increase.

Even with such a system there could be problems with version control. It may be that not all users of the services have the same organization of cards that are suitable for the latest version of services. This can happen when multinational organizations introduce or update services at different times in different countries. In WO 96/18979, it was suggested that terminals be updated only for a session initiated by the user's personal ICC. Software instructions representing the subroutines are stored on the card and can be exported to the terminal for interpretation. The use of an interpreter in a terminal allows the same card to be used with any terminal that contains the interpreter and therefore makes the transaction independent of the main processor at the terminal. However, no security procedures are described for eliminating potentially dangerous subroutines.

Terminals of the type described above also have a processor that includes some form of memory, usually some sort of read / write memory (RAM) for running programs, some sort of read only memory (ROM) for read only data that can include an operating program terminal system and existing read / write memory for storing general information that can be changed. The user's personal data should be kept private and therefore one user should not be allowed to access another user's data, either accidentally or intentionally by a malicious person. Furthermore, the fragmented writing memory of the terminal should not be reduced over time. Reducing memory fragmentation can result in reducing adjacent memory blocks by size so that certain programs cannot run. To avoid this problem, some application languages, such as Java ™, use memory space restoration. Memory Space Recovery is a program that tries to identify in-memory data that is no longer needed and is removed from memory. The current opinion, knowing the facts, is that restoring memory space is a more reliable way of managing memory than having a program to explicitly release its own stored data. Explicit memory allocation and release are some of the biggest single source of errors in high-level programming languages like C or C ⁺⁺ .

Recovering memory space has some drawbacks. First of all, restoring memory space is a function of the operating system rather than a user feature. Therefore, restoring memory space does not guarantee that each usage data is removed from memory at the end of that use, but such data may be present for some time until an access disruption triggers memory storage recovery. A more reliable process of eliminating the ability to address private user information is required in financial transactions. It further increases the amount of memory space required for the operating system. At ICCs and some terminals, memory may be limited, and rebuilding memory space can be a serious disadvantage. As explained above, the terminals are replaced very rarely, so that at the same time a wide variety of terminals, which include different processing capabilities and memory sizes, normally function in the system. Older terminals are often very limited in their capabilities. Although the oldest types may be interchanged, the demand for improved and more complex services means that older terminals will probably never be replaced so often that some of them will not lag behind in their capabilities. Therefore, the requirement for compact operating systems that can run on a wide variety of processor types will very likely remain as a requirement. Finally, restoring memory space does not free up memory as quickly as it would have been released if explicit memory removal had been used. Also, this can increase the amount of memory required, since memory is overloaded when it could be released.

A safe procedure for managing memory during operation is described in US Patent 5,434,999. According to this known process, e.g. the terminal compiler performs a systematic check on each instruction that manages the memory address to verify that the memory area to which access is requested is allowed. This system has the disadvantage that each instruction must be verified in this way, which significantly slows down processing. Checking a program while in operation is valuable for efficiency.

There is a need for a system that provides programmable terminals, which allows the user programmer to create software that is portable and neutral via heterogeneous terminals, that is, independent of the processor used in the terminal and does not need to be customized for each type of terminal. Terminally resident operating system and application programs are preferably compact, run fast, and meet security requirements. Furthermore, it is preferable that user programs can be easily updated, at least so that each user can obtain the services expected independently of the geographical location of the terminal.

It is an object of the present invention to provide a secure transaction management system and process for managing this system.

A further object of the present invention is to provide you with terminals and ICCs for transactions and procedures for managing these devices.

A further object of the present invention is to provide a device that can be used in a transaction and can be used on small hand held devices such as the ICC.

It is a further object of the present invention to provide a transaction system in which terminals or ICCs can be updated by using terminals or ICCs as sources of update information.

It is a further object of the present invention to provide a transaction management system and process management system that provides high security at good speed of operation.

Summary of the Invention

The present invention relates to a transaction management system for performing transactions between a first device and a second device, said first device and said second device being adapted to communicate with each other, and at least one of said first and second devices is an integrated circuit card, said system comprising:

at least one input / output device;

a portable virtual machine for interpreting a computer program on said first device, said virtual machine comprising a virtual microprocessor and a driver for said at least one input / output device;

and an executing agent that responds to said interpreted program for executing said program.

Preferably, a portable virtual machine is a stacking machine because it delivers speed in performance and compactness.

The present invention also provides a terminal comprising a first device for carrying out a transaction with a second device, wherein at least one of said first device and said second device is an integrated circuit card comprising; a portable virtual machine that interprets a computer program at said first preparation, said portable virtual machine comprising a virtual microprocessor and a driver for at least one input / output device and a executing agent that responds to said interpreted program for executing said program.

The present invention also provides an independent portable intelligent card comprising a first device for performing a transaction with a second device, said intelligent card comprising: a portable virtual machine comprising a virtual microprocessor and a driver for at least one input / output device.

The present invention also provides a transaction management system comprising: a first device and a second device, the first device and the second device being adapted to communicate with each other, and at least one of said first device and the second device is an integrated circuit card; said second device includes a means of providing at least one program instruction that can at least modify the behavior while executing the computer program on said first device; said first preparation comprises a virtual machine, wherein the virtual machine comprises means for downloading and interpreting said computer program, and said means for downloading and interpreting being further adapted for loading and interpreting said at least one program instruction depending on a predetermined security condition after said downloading and interpreting means downloaded said computer program and while said computer program is running; executing means for executing said downloaded and interpreted computer program with said modified behavior in response to said downloaded and interpreted program instruction.

The present invention further provides a terminal comprising a first device for conducting a transaction with a second device and at least one of said first devices and a second device being an integrated circuit card, the second device including means for providing at least one program instruction that can at least modifies the behavior while executing a computer program on said first preparation; said terminal comprising: said first device including a virtual machine, said virtual machine comprising means for loading and interpreting said computer program and means for loading and interpreting further adapted to download and interpret said at least one program instruction depending on a predetermined security conditions after said loading and interpreting means has been downloaded by said computer program and while said computer program is running; and an executable means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

The present invention provides an independent portable intelligent card comprising a first device for performing a transaction with a second device, the second device including a means for providing at least one program instruction capable of at least modifying the behavior while executing a computer program on said first device, wherein said intelligent card comprises: said first device comprising a virtual machine and said virtual machine comprising means for loading and interpreting said computer program, said means for loading and interpreting being further adapted for loading and interpreting said at least one program instruction depending on a predetermined a security condition after said uploader and interpreter downloaded said computer program while the computer program was running; executing means for executing said downloaded and interpreted computer program with said modified behavior in response to said downloaded and interpreted program instruction.

The present invention also provides a transaction system for performing transactions between the first preparation and the second preparation, said system comprising; a virtual machine for interpreting user-generated syllable code chips used in it;

said virtual machine includes a virtual processing unit and a read / write logical address space; at least one first utility includes an indication of the amount of read / write logical address space required to execute it, said at least one first utility being written as a stream of tokens selected from said set of tokens and corresponding interrupted data; said virtual machine also includes; a downloader for downloading said at least one first utility; and means for allocating the first amount of read / write logical address space specifically for said at least one first application program according to said indication, wherein said adapted read / write logical address space defines and protects the boundaries. The first preparation according to the present invention may be a personal computer connected to the Internet and powered by the browser, requiring that each module received by the browser must include an indication of its memory requirements, improve browser security and limit the damage that may occur because of any virus contained in the imported module.

The present invention provides a terminal comprising a first device for performing transactions with a second device, said first preparation comprising: a virtual machine for interpreting a set of user-defined syllable code tokens used therein; said virtual machine includes a virtual processing unit and a read / write logical address space; at least one first application includes an indication of the amount of read / write logical address space required to execute it, and a first exclusive statement of at least one function that can be exported to other user programs, said at least one first user program being written as a token stream which are selected from said set of tokens and corresponding interrupt data; said virtual machine also includes: a downloader for downloading said at least one first application program; and means for arranging the first amount of read / write logical address space specifically for said at least one first application program according to said indication, said bound read / write logical address space defining and protecting boundaries.

The present invention may also provide an independent portable intelligent card comprising a first device for performing a transaction with a second device, the first preparation comprising: a virtual machine for interpreting a set of user-defined syllable code tokens used for it; said virtual machine comprising a virtual processing unit and a read / write logical address space; at least one first application program including an indication of the amount of read / write logical address space required to execute it, said at least one first application program being recorded as a stream of tokens selected from said set of tokens and corresponding interrupted data; said virtual machine also includes: a downloader for downloading said at least one first application program; and means for allocating the first amount of read / write logical address space, especially for said at least the first application program according to said indication, wherein said read / write logical address space defines and protects the boundaries.

The present invention may also provide a transaction system for performing transactions between the first preparation and the second preparation, at least one of said first preparation and the second preparation being an integrated circuit card, said system comprising: a virtual machine for interpreting a set of user-adapted syllable codes tokens used for it; said virtual machine includes a virtual processing unit and a read / write logical address space; at least one database includes at least one record and at least one computer program to execute with said virtual machine, the computer program being written in modules by the stream of said tokens selected from said set, and includes an indication of the amount of uninitialized read / write logical the address space required to implement said module; a loader for loading said module and for assigning the required amount of uninitialized logical address space according to said indication; and means for accessing the record of said database, wherein the records in said database are accessible only through said module and said access means providing a window to said record of said database and copying said record to a portion of said uninitialized read / write logical address space, which may be addressed by said application.

Furthermore, the present invention may also provide a terminal comprising a first device for performing transactions with a second device, wherein at least one of said first device and the second device is an integrated circuit card, said first device comprising: a virtual machine for interpreting a set of user customized ones. syllable code tokens used for it; said virtual machine includes a virtual processing unit and a read / write logical address space; at least one database comprising at least one record and at least one computer program for execution with said virtual machine, said computer program being written in modules using a stream of tokens selected from said set and including an indication of the amount of uninitialized read / the written logical address space required to execute said module; a loader for loading said module and for assigning the required amount of uninitialized logical address space according to said indication; and a means of accessing a record in said database, wherein the records in said database are accessible only through said module, and said access means providing a window to the current record of said database and copying said record to a portion of said uninitialized read / write logical address space that is addressed by said application.

The present invention may provide an independent portable intelligent card comprising a first device for performing a transaction with a second device, the first preparation comprising: a virtual machine for interpreting a set of user-defined syllable code tokens used for it; said virtual machine includes a virtual processing unit and a read / write logical address space; at least one database comprising at least one record and at least one computer program for execution with said virtual machine, the computer program being written in modules using a stream of tokens selected from said set and including the amount of uninitialized read / write the logical address space required to execute said module; a loader for loading said module and for assigning the required amount of uninitialized logical address space according to said indication; and a means of accessing a record in said database, wherein the records in said database are accessible only through said module and said access means providing a window to said record of said database and copying said record to a portion of said uninitialized read / write logical address space , which can be addressed by said application.

The present invention also provides a method for performing a transaction between a first device and a second device, wherein at least one of said first devices and the second device is an integrated circuit card and includes: providing at least one program instruction on said second device that can at least modify the behavior between executing a computer program on said first preparation; downloading and interpreting said computer program, downloading and interpreting said at least one program instruction depending on a predetermined security condition while said computer program is running; and executing said downloaded and interpreted computer program with said modified behavior in response to said downloaded and interpreted program instruction.

The present invention also provides a method for performing a transaction between a first preparation and a second preparation, comprising: interpreting at least one application program written as a stream of syllable code tokens selected from the token set and the corresponding interrupted data; downloading said at least one user program; assigning the first amount of read / write logical address space specifically to said at least one application program according to the statement contained in said user program for the amount of read / write logical address space required to execute it, and defining and protecting the boundaries thereof assigned read / write logical address space. This process combines the use of an interpreter with the allocation and optionally explicit memory release. This provides a mixture of agility and portability while providing a guarantee of performance after the application program has been seriously verified in the translation stage. Reduces the damage that can be caused by viruses in the entered user modules.

The present invention also includes a method for executing a transaction system between a first draw and a second draw, wherein at least one of said first draw and second draw is an integrated circuit card comprising: interpreting tokens in a module written with expressions of the flow of said tokens, selected from a set of tokens; allocating the amount of uninitialized logical address space according to the indication in said module of the amount of uninitialized read / write logical address space required to execute said module; accessing the record in the database by providing a window on the current record of said database, the records being in the database only via said module, and copying said record to a portion of said uninitialized read / write logical address space configurable by this module .

The present invention also includes a method for performing a transaction between a first device and a second device, wherein at least one of said first device and the second device is an integrated circuit card and comprises: providing a portable virtual machine comprising a virtual microprocessor and a driver for at least one input / output preparation; interpreting a computer program on said first device using said portable virtual machine; and executing said program in response to said interpreted program.

According to the present invention, a secure transaction management system is provided, which preferably includes a portable virtual microprocessor. Preferably, each module has a set of virtual setups that are reliably different from any other virtual setup space. Also, a portable virtual microprocessor preferentially protects access to shared resources, such as different funds or databases. Preferably, the minimum security is that the memory checks the read-write access boundaries of the data space and the absolute prohibition of writing to the code space. Further, checking for overlaps and overlaps on data and backfill is preferred. Preferably, the module can only access what any other module explicitly exports. Preferably, there is no way to access the non-exported data (the virtual microprocessor does not leak) except through the functions provided by the module. Preferably, modules cannot export data in the normal sense; modules can preferentially export functions only. Preferably, logical boundaries prohibit data space leaks. In other words, all data held by the module is preferably strictly private. This restriction is preferentially enforced both during compile time and during runtime, since the modules have separate address spaces, which means that the address of individual data within a particular module is completely meaningless outside their own module. Preferably, the module can only export a set of hooks to initiate or retain a particular behavior. Preferably, well-functioning modules will run without comment, while non-behavioral modules will be discarded, with exceptions directly given by a portable virtual microprocessor when unauthorized operation is attempted.

Dependent claims identify individual embodiments of the present invention. The present invention, its embodiments and advantages will now be described with reference to the following drawings.

Brief description of the drawings

FIG. 1 is a schematic representation of a terminal according to the present invention.

FIG. 2 is a schematic representation of the ICC according to the present invention.

FIG. 3 is a schematic flowchart for the process of developing and executing a module according to the present invention.

FIG. 4 is a schematic representation of a portable vertical microprocessor according to the present invention as performed at a terminal.

FIG. 5 is a schematic representation of a portable vertical microprocessor according to the present invention.

FIG. 6 is a schematic representation of a module loaded in memory according to the present invention.

FIG. 7 is a schematic representation of a process for gaining access to a database record according to the present invention.

FIG. 8 is a schematic representation of a plug and socket process according to the present invention.

FIG. 9 is a flowchart for the module loading process of the present invention.

FIG. 10 is a flowchart for implementing a module of the present invention.

FIG. 11 is a flowchart for the plug-in process of the socket according to the present invention. FIG. 12 is a flowchart for loading a card module in accordance with the present invention.

The add-on specifies the token codes and standard exceptions.

Description of typical implementation examples

The present invention will be hereinafter described with reference to the individual drawings and specific embodiments, but the invention is not limited thereto but only by the claims. The drawings are merely schematic and not restrictive. The present invention will be described with reference to financial transactions, but the invention is not limited thereto. Further, the present invention will be described primarily with respect to the terminal, but the present invention also includes providing a portable virtual microprocessor according to the present invention in any suitable device, e.g. on a personal computer (PC), on an ICC, or on a combination ICC and interface as described in WO 94/10657, which is hereby incorporated by reference.

A general binding technical idea behind the present invention is portability, which is related to data security and guarantees during operation of the transaction system that are independent of the intended execution, provided that only checks during the translation time have been successfully completed. This idea is achieved by one or more of the following characteristics: using a virtual machine as an interpreter, integrating an I / O device driver in a virtual machine so that the application programs have a common interface with the I / O devices and are therefore portable across very different environments, by including an indication of the amount of space in the application program and allocating memory according to that indication, explicit memory allocation and providing a secure method for entering and exporting data to and from the application programs and / or databases.

FIG. 1 is a schematic view of a terminal 1 according to the present invention. Typically, terminal 1 includes a central processing unit (CPU) 2 that is connected to the memory 4 and to the input / output (I / O) devices 6 via bus 3 for bidirectional communication. The I / O devices 6 can be a keyboard for data input and a display, such as. visual display unit, e.g. liquid crystal (LCD) or light emitting diode (LED) display to show transaction progress and / or display messages or prompts. One of the I / O devices 6 may be a card reader 7 that can read the ICC 5 when inserted into the receiving slot in the reader 7. The actual shape of the terminal may vary greatly, e.g. it can be a point of sale (POS) terminal and can include processors from an Intel 8051 processor to a Pentium ™ processor. Furthermore, it is not necessary to have the entire terminal 1 in one place, different parts of the terminal, such as card reader 7, I / O devices such as keyboard and display, and the processor can be installed in different places and connected by cables, wireless transmission or similar, or part of a local area network or interconnected with telecommunications networks.

FIG. 2 is a schematic representation of ICC 5 according to the present invention. However, the present invention is not limited thereto. ICC 5 includes at least one input / output (I / O) port 10 and some permanent memory, e.g. Existing memory that can be e.g. provided with an EEPROM 15 that is connected to the I / O port 10 via bus 17, or with battery-operated read / write memory (RAM). The I / O port 10 can be used to communicate with terminal 1 through a card reader 7. An integrated circuit card is a card into which one or more integrated circuits are inserted to perform at least memory functions. Optionally, ICC 5 may be an independent portable intelligent card and include read / write working memory, e.g. the non-existent memory provided by RAM 14 and the CPU 12 as well as all the necessary circuits so that the ICC 5 card can act as a microprocessor, e.g. read memory 13 for storing code, a timer 16 sequences in conjunction with a card reader 7 for receiving voltage sources Vss and VDD, reset for processor 12 and CLK clock for timer 16 sequences. According to the present invention, ICC 5 can be used as a bank card, credit card, debt card, electronic wallet, medical card, SIM card or the like.

The present invention provides a transaction management system controlled by an integrated circuit to be implemented between ICC 5 and terminal 1, which is or is not connected to a central unit, the transaction consisting of at least one implementation in the following sequence;

1. forming a communication link between ICC 5 and terminal 1;

2. performing compatibility checks to ensure that ICC 5 and terminal 1 are mechanically and electrically compatible;

3. use selection involving the selection of a computer program and a customized data set identifying the transaction by means of an involved combination of a particular ICC 5 and terminal 1;

4. implementation of use;

5. termination of a transaction which optionally involves breaking the communication link between ICC 5 and terminal 1; an interpreter is used to perform the application, either at ICC 5 or at the terminal or both. A transaction is the exchange of at least data between two or more devices in accordance with the present invention and is not specific to commercial financial transactions. Such a system is known from patent application PCT / BE 95/00017. ICC 5 can only be a memory ICC, that is, it does not include processor 12, and ICC 5 undertakes a transaction as specified by terminal 1. Alternatively, the ICC may be an independent portable intelligent card and the transaction may be determined by terminal 1, with ICC 5 or with both. According to the present invention, ICC 5 may include a program code to safely promote terminal processing. In particular, ICC 5 may be one or more maintenance cards that can be used to update the uses stored on terminal 5.

According to the present invention, the software is implemented at terminal 1 and optionally at ICC 5 using a virtual machine. According to the present invention, a virtual machine (VM) explicitly makes available a theoretical or virtual microprocessor with standard features that define addressing mode, stack usage, use of registers, address space, addressing I / O devices, etc. in a generic way. The kernel for each particular type of CPU used in terminal 1 or ICC 5 is written to cause the corresponding processor 2, 12 to replicate the VM. It is a particular aspect of the present invention that the VM kernel provides drivers for I / O preparation and low-level CPU logic and arithmetic functions, flow control and timing. Providing I / O drivers in the VM has the advantage that any program written with the VM according to the present invention addresses standard virtual I / O devices. The implementation of the VM on each CPU then ensures that the physical I / O devices attached to Terminal 1 or ICC 5 behave just like the addressed virtual I / O devices. The VM according to the present invention is very compact and has been successfully used on the Siemens SLC044CR chip (derived from the INTEL 8051 family), which can be integrated into the ICC 5. The VM according to the present invention provides a high degree of standardization possible through very various CPU and I / O types and simplifies program portability, testing and validation. According to the application provided, such VM will be described as a portable virtual machine 20. The portable VM includes a virtual microprocessor and an I / O preparation driver. VM 20 provides logical and arithmetic functions and memory addressing and at least one input / output device. The portable VM 20 according to the present invention provides program portability through heterogeneous terminals 1 and card 5 by treating terminal and / or card programs as interpreter codes. This code is made up of syllable code streams called tokens. Terminals 1 or ICCs 5 then process this code by interpreting it or otherwise as translating their own machine code. Preferably, the interpretation of tokens by a virtual machine can be accomplished by one of three processes: direct interpretation of virtual machine instructions, translation of the virtual machine language into a direct executable intermediate format, or timely translation into actual code for the target CPU. The last two procedures offer improved efficiency at the expense of only moderate complexity. The tokens are provided in a set that can be viewed on the VM 20 machine instruction set.

The user programs according to the present invention are implemented as modules that may include a token list as executable code. According to the present invention there are two basic types of modules: executable modules having an entry point called directly by VM 20 when the module is loaded and library modules that act as resources for other modules by providing exportable processes, which can be made individually through intermodule calls.

The token set in accordance with the present invention first include a set of instructions for VM 20, which provides the instructions expected for the general processing language and is required for the effective execution of the programs, and second, the tokens that provide what is commonly called operating system features . In terminals 1 or card 5, operating system features include, in accordance with the present invention, specific features such as L / O drivers, e.g. displays or keyboards, and in terminals 1 and 5, system functions may also include managing the communication of data objects and transmission through I / O ports, as well as mechanisms for intermodule access and access control. The tokens are preferably provided with an operating system on the VM for manipulation of the stack handlers, for control, e.g. exceptional handling, for the sockets themselves, which include their access rights, for access to I / O preparation, for time management, for language and message handling, for handling I / O readers, e.g. handling of ICCs, magnetic tape and modem card, blacklist management, security algorithms, terminal services, database services, data object handling, e.g. TLV Handling, Module Handling and Expandable Memory Handling.

Single-stack tokens are called primary tokens; these refer to simple instructions as they are usually found in any set of instructions. Multiple tokens are called second tokens and are used for less commonly used services. A complete set of tokens for VM 20 is provided in the appendix. As schematically presented in FIG. 3 is a user program written on PC major development system 70 and debugged and is type approved in primitive high-level languages such as Forth, C, Pascal, etc. The source code of the program is then translated on the token stream into the token stream by 71 tokens. This token stream is separately combined with other data (relevant interstitial data) required by the program and title description, and encapsulated in a modular delivery file to create module 72, preferably in a standardized module delivery format. If the module contains executable tokens, it is delivered in executable program format. A particular aspect of the present invention is that the feasible modules comprise not only the flow of tokens but also the corresponding encapsulated data (encapsulation). A particular further and separate aspect of the present invention is that the modules according to the present invention include an indication of how much read / write memory must be allocated by VM 20 for the module to perform.

Module 72 is delivered to terminal 1 by suitable means, e.g. in ICC 5, via telecommunication network. After the module is loaded, it is stored in the module repository. When its operation is required, terminal 1 or card 5 uses a token loader / interpreter 73 to process execution tokens on terminal CPU 2. This process consists of performing a function associated with each token. The token loader / interpreter 72 is provided by VM 20 in accordance with the present invention.

The software related to the VM in Terminal 1 can be divided into 4 major categories:

• A kernel that includes terminal dependent I / O drivers and all the features required in this description to support VM 20. Any other software related to VM 20 is written in machine dependent tokens.

• Terminal Resident Services (TRS) have at least one module running on VM 20 as a user manager and include all non-user functions, libraries that support these functions, module load functions, and a master loop that defines the behavior of the terminal. Special tokens - (eg DIOCTL) allow terminal-dependent aspects of I / O preparations to be defined as interrupted functions.

• Terminal Selected Services (TSS) include uses such as payment service features and libraries that support these features. TSSs contain only terminally independent tokens and are resident at terminal 1. The main TRS program loop will select and call TSS functions as needed for a single transaction.

• Card-selected services (CSS) include terminal transaction support features, such as payment service features used as part of TSS usage. CSSs are resident at ICC 5 and loaded at Terminal 1 as required. For terminals 1 with two ICC readers 8 - e.g. one for normal transactions and the other for maintenance can be two independent sets of CSSs (CSS1 and CSS2).

All software at Terminal 1 according to the present invention above the kernel is organized as a set of separate modules. The basic feature of the module is that the sum of definitions or programming functions that have passed through the 71 token compiler and are encapsulated as a single wrap for delivery to the target environment, e.g. terminal 1 or ICC

5. The Main Terminal Program (TRS), every usage, every library, and every CSS that is loaded are examples of modules. Preferably, all modules use the standard format. The core of the system according to the present invention defines VM 20, which provides various high-level services to these modules, such as:

• general-purpose CPU and instruction set presented with tokens;

• general purpose I / O support for routine preparations by providing generic I / O to support additional devices that can be added;

• database management functions;

• manage the transfer of data objects including format conversions and other features;

• Manage token modules, including keeping them in memory, updating as needed - and performing them on demand. In a preferred embodiment of the present invention, the implementation of the modules remains under the control of VM 20. Therefore, the modules never control the main processor, but are only passive with respect to VM 20. Preferably, VM 20 always operates in a mono-mode and can only execute instructions defined as its tokens, and no module can operate in user mode, that is, take control of VM 20. Therefore, only one memory schedule is created when executing VM 20, which uses a memory schedule, namely a sub-layout.

No module can invalidate an operating system defined by VM 20. This is guaranteed because the module can only contain tokens from a set of VM tokens, and none of these tokens allow access to the code space where the kernel is stored. When VM 20 encounters a token lying outside the defined set, an exception (ILLOP) is applied.

As shown schematically in FIG. 4, terminal 1 includes a terminal-specific operating system 8 that is responsible for loading the TRS module from VM 20 - the loading process will be described later. The code for VM 20 is stored in terminal read-only memory 11. Prior to loading TRS, terminal non-existent memory 19 of terminal 1 is empty as far as data pertaining to any transaction is concerned, terminal read / write persistent memory 18 contains uses that must be executed by VM 20 in the form of modules 72 in the module repository, with persistent databases comprising user-specific data and libraries, such as the footer library, which will be described later. If VM 20 is also used on ICC 5, the same principles as described above are applied to read persistent memory 13, non-existent memory 14, and read / write persistent memory 15 to ICC 5.

Because VM 20 is a virtual machine, it addresses all forms of terminal or ICC memories 11, 18, 19; 13, 14, 15 as virtual memory, that is, all are addressed in logical address space as seen by VM 20. In actual use by VM 20, these logical address spaces are mapped to actual address spaces in terminal 1 or ICC memory 5 with memory mapping or the like. In the following, reference will be made to non-existent, read / write persistent and read persistent memory as part of VM 20. It should be understood that this refers to logically addressed memory space, unless the actual addresses in the VM 20 implementation of the terminal are specifically mentioned 1 or ICC 5. Non-volatile memory does not survive program loading or power failure and / or restart. Non-volatile memory preferably does not survive a power outage for security reasons. Permanent memory survives downloading the program or turning off the power and restarting.

Description of the virtual machine

A schematic representation of VM 20 according to the present invention is shown in FIG. 5. VM 20 is preferably a stack machine and has a data stack pointer (stored in a register of 32 data stack pointers) pointing to a downward slotted data stack 27, preferably in memory on a chip. All operations are performed on this fund

27. Data pool 27 is used to contain procedure parameters and temporary results from expression evaluations. The data is pushed to or removed from the data pool 27. VM 20 also includes a repository 28. The repository 28 can be used by the VM 20 to capture return addresses, and can also be used for temporary storage. This multiple stack architecture is known from the Forth programmable language (ANSI X3.215-1994). This architecture has been further modified in terms of portability, code density, security, ease of translation and for use with other programmatic languages. It covers e.g. assurances for frameworks of local variables used in high-level language programs such as C. Thus, 71 token compilers according to the present invention can be written not only for Forth but also for C and other language programs.

According to the present invention, there is only one data or return pool 27, 28 associated with VM 20. Data and return pools 27, 28 are not created for each processing thread. According to the present invention, the user program can only retrieve from the return fund 28, which they explicitly filed for it during the ongoing process, and must remove the data deposited on the return fund 28 during the ongoing process before exiting the process. VM 20 optionally comprises a runtime security runtime controller that monitors each activity on the return pool and checks all data and is removed during the ongoing process. In addition to the data stored there for temporary storage, VM 20 can hold information about the runtime state, frameworks for local variables, loop control parameters, and database context on the return 28.

According to the present invention, VM 20 may include a plurality of stacks. Instead of using only a return fund 28, e.g. optionally provided by further funds 29 as exceptional and indicative funds. An exceptional stack is used to save the execution state during an exceptional processing. The Framework Fund is used to maintain information on local variables as well as C-language records of similar activation. As mentioned above, exceptional and framework funds 29 may be implemented on a return fund 28.

Data, paybacks 27, 28 and other funds 29 as an exceptional pool are not directly accessible in the memory space by the application program. Data or return funds 27, 28 cannot be addressed directly, but are only accessible through stack operations. For security reasons, there is no limit to how the data is stored in actual use, so that malicious persons have no assumptions about how the data is physically stored.

VM 20 includes a virtual central processing unit 22 that includes a virtual arithmetic logic unit 23. VM 20 addresses a virtual or logical data space 24, which is treated by VM 20 as read / write memory (RAM) and would normally be used as part of a non-existent of memory 19, e.g. in RAM in actual terminal 1 or card 5. The logical data space 24 is accessible only for data storage. The module tokens stream is stored by VM 20 in code memory 26, which is treated as read memory (ROM) by VM 20. Only VM 20 can read tokens. Code memory 26 is not accessible for application programs or by any token.

VM 20 may include virtual registers 30. VM 20 registers 30 may include a token register 31 holding a pointer pointing to the next token to be executed, a register of 32 data fund pointers holding an pointer pointing to the top location of the data stack 27 (TOS), the register of 33 return fund indicators points to an indicator pointing to the current top position of the return fund, the register 34 frame indicators, the pointer indicating the beginning of a frame in the data space 24, the register 35 indicators of the end of the frame holds the pointer pointing to the end of the frame in data space 24. No direct access to registers 31 to 36 is provided by a set of tokens, but only through tokens to access registers.

Finally, the virtual I / O devices 25 are connected to the CPU 22 through a virtual bus system 21 that connects the stacks 27-29, the ALU 23, the registers 30, the code memory 26 and the data space 24.

According to the present invention, VM 20 is preferably defined as an infamously addressed, binary component, 32 bit machine with 32 bit registers and stack elements, but the invention is not limited thereto. The size of the register / stack is referred to as the cell size for VM 20, with the cell being the basic unit of manipulation on the stacks and with the VM registers 31 to 36. The cell size used by VM 20 is not treated as having material effect on the present invention.

All module-driven programs must obey the following rules:

• programs must not assume the assurance that data in any of the above categories is held in a return 28, and thus can only use an acquisition mechanism explicitly described for a particular category, since the security manager can destroy any such data.

• Programs submitting data in one of these categories to VM 20 must execute a primitive action to restore data storage from VM 20 before the process in which they are transferred is initiated, otherwise VM 20 will free up the corresponding portion of memory.

• Programs must assume that any data previously installed on the return 28 is rendered inaccessible by passing data in one of these categories to VM 20.

• Programs must assume that any data in one of these categories submitted to VM 20 is rendered inaccessible by an executable code that sets values on the return 28 until such time as these values are removed because the return is accessible only with defined token processes.

According to the present invention, the operating system for VM 20 defines an individual address space 24 that is available to each module. This address space 24 will be accessible only for data storage and will be called data space 24.

The data space is divided into three and one optional logical areas, each individually close:

1. an initialized data space 41 comprising the initial values indicated at compile time and set when the VM kernel is activated and then when a module containing the initialized data is loaded;

2. space 42 of uninitialized data, comprising variables and static buffers that are allocated during program translation. This data space 42 is initialized to zero by VM 20;

3. frame memory 46 managed by frame tokens;

Optional 4. Expandable memory 45 comprising one or more buffers dynamically allocated during program execution.

There are two additional data areas that are not directly configurable:

5. expandable memory 43, which is typically a mass memory used to contain data objects and non-existent databases;

6. persistent memory 44 is used to contain information that VM 20 provides to survive module load or power failure or restart (within terminal hardware limitations), including module repository and persistent databases. This can be done in battery-backed RAM, disk, or other permanent memory. Persistent memory 44 may be implemented as part of read / write persistent memory 18.

To increase data security, extended and persistent memory 43, 44 is only accessed through tokens that provide windows to selected data in the form of buffers in the non-initialized data space 42. Therefore, the programmer can only request a record and cannot know the exact location of the data to would access them. Preferably, there is no file or tree structure that allows the programmer to locate personal files or databases.

Within each data space 24 used by the module, memory is allocated by relative addressing and only during operation. This means that the title only has meaning within each module when loaded. Because absolute addressing is not used, the module cannot access the data of another module except by the mechanism behind you access to the module, which will be described later.

The framework mechanism allows VM 20 to meet the requirements of languages such as C that allow local variables to be defined during runtime. The frame holds the process parameters passed to the data pool 27 as well as local variables (temporary storage of data that will be released automatically when the frame is released, normally at the end of the process). The frame start and end pointers are automatically maintained by the VM 20 inside the frame. The register of frame indicators 34 points to the logical base of the frame and the frame end pointer 35 indicates the logical end of the frame in the data space 24. Parameters can be delivered from the frame using tokens to access the frame.

VM 20 may optionally provide a dynamically allocated pool of expandable memory 45 as a single expandable buffer managed by VM 20 that occurs outside the program space 42 of uninitialized data. Programs can request the allocation of a defined amount of expandable memory 45 and return a pointer to the base address for the same memory 45. Then programs can free up memory 45 from a given address, e.g. after the end of the program, resulting in the release of all assignments behind that title

Preferably, the modules are implemented in a single thread, but the invention is not limited thereto. If the module calls the second module, it means that the second module terminates and all resources of the second module are released before VM 20 returns to the first module and resumes processing. FIG. 6 shows a schematic representation of logical memory as seen by VM 20. As shown schematically in FIG. 6, the first module (on the left) with initialized memory 41, not initialized memory 42 and frame memory 46 and space of 26 token codes was loaded into read / write memory, starting at address 1. The first module also called and was assigned compartment 45 of expandable buffer. When the second module (on the right) is called by the first module (e.g. to import the fgh function that is on the exclusive list in the address of module 1 of the importable functions), the data space 24 ', which includes the initialized memory 4Γ, uninitialized frame memory 42 'and frame memory 46' are allocated, as required, starting at title 2. Module 2 tokens are read directly from VM 20 from the module repository, a permissible option in accordance with the present invention. If called by Module 2, expandable memory 45 'for the second module is allocated by VM 20 more in memory than expandable memory 45 for the first module. When the second module is completed, all memory above Title 4 is released - the effect of the rubber band. Preferably, upon release, all temporarily stored data will be deleted. If necessary, more expandable memory 45 can then be called after returning to the first module. If the second module is then called again, it will be assigned a different start address for 45 'expandable memory than when it was first called.

All tokens except EXTEND, CEXTEND and RELEASE tokens for expandable memory management and THROW and QTHROW tokens for exceptional handling are required to have no actual effect on the expandable memory pointer. If a token allocates expandable memory 45, it must also free it, including any effect of sorting cells. Successive allocations of extensible memory 45 are preferably closer within the module, but need not be close between modules, except that intermodule calls using IMCALL or DOSOCKET tokens should remain adjacent. The automatic release of dynamically allocated expandable memory 45 occurs when a module that limits the effects of a program deficiency to free up memory is terminated. If a THROW exception occurs, the additional allocation of dynamically allocated expandable memory 45 may be restored to its state at the time of the CATCH exception.

User variables are cell size variables in which VM 20 holds contextual information for client programs. Storage for user variables is pre-assigned by VM 20. A limited number of variables can be provided, e.g. 16 variables - with reference marks 0 to 16. Running VM 20 that supports multiple tasks can provide one set of user variables for each task.

VM 20 provides a single mechanism for CATCH token handling,

THROW and QTHROW. These tokens are derived from the exceptional handling mechanism in

Lisp and appear in ANS Forth as CATCH and THROW. The purpose of this mechanism is to provide for the local handling of exceptions under program control at different levels in the software. The idea is that the program passes a function implementation pointer to the CATCH token that will execute this function and return the code, and indicate which, if any, exception occurred during its execution. CATCH records execution-dependent information that is sufficient to restore its current execution state if THROW is to appear in a function that is handed over to CACTH for execution. This includes - but is not limited to - data and rollback depths, a frame pointer, and in some cases an expandable memory pointer. A collection of information that represents an implementation state is called an exceptional framework. Exceptional frames are held in remarkable harmony. Following CATCH, the program can test any outstanding code that may have returned and choose to handle it locally or throw (THROW) to a higher level for processing. VM 20 guarantees to assume the outermost level at which exceptions are captured. This outermost level will be activated when no internal CACTH level is established. The default exception monitor discards any current terminal transaction and attempts to reload the TRS module and re-enter the TRS master loop. VM 20 throws ANS Forth exception - 10 (zero division) if this condition occurs.VM 20 may trigger other general exceptions that are supported by ANS Forth, e.g. as given in the attached appendix.

Each preparation, which includes monitoring devices and I / O (services) whose lower operating level is hidden by VM 20 for function-specific features, is assigned a device type (used to categorize result codes) and a unique number preparation. Preparation numbers are arbitrary; however, it can refer to preparation numbers - from 1 to 15 (four bits) - with only one token, so these are tailored to the most common devices such as keyboards, ICC readers, magnetic stripe card readers, screens, printers, prepa power supply or vending machine. General I / O utilities are provided with features that take the preparation number as an input parameter.

In accordance with the present invention, terminal 1 preferably comprises at least three major permanent databases: a specific transaction log, a database of messages in one or more languages, and a module database. VM 20 protects databases as far as they can, since they may contain private information. Access to databases is limited. VM 20 provides a database monitoring mechanism (VM 20 as a server) that hides post-implementation details from the application software (used as a client). No direct access to the database is permitted from the module running on VM 20. The services use the following features, which will be described, with reference to FIG. 7;

• At any given time, a client, that is, a program running on a module, has access to one currently selected database (DBCURRENT) and one currently selected record number (DBRECNUM) that is common to all defined databases.

• Information about each database is passed between the client and the server via a block (DPB) of 51 database parameters that the server can access for reading and writing purposes. The client has a DPB 51 in the sense that there is 24 in the client data space; however, the client is not allowed to access it directly. Instead, only database service tokens can be used to access the data. DPB 51 has a standard structure that includes fields for at least a DPB connection, a database pointer, an indication of the database type and record size, and the number of the next available record. All database definition information must be pre-configured in DPB 51. Client software must not make any subsequent direct access to DPB 51 and must not make any assumptions about values directly held in DPB 51 after the module has defined, that DPB 51 was ordered for execution. Blocks of 51 database parameters are passed to the pointer loader / interpreter in the form of a pointer (DPB connection) to a linked list in the module's initialized data section. This field must be pre-set to the address in the initialized data of the next DPB 51 in the list; or nothing if this DPB 51 is the last or only DPB 51 on the list. For compiled databases that exist in the client's initialized data space, the DB cursor must be pre-set to the start address in the initialized data. For databases whose storage is server-controlled, the field must be preset to zero. The DB type provides the database details in coded form. There are at least three types of databases:

Non-existent databases whose contents are not required to be maintained during module load or in the event of a power failure of the terminal 1 on which it resides.

Stable databases whose contents must be maintained during module loading or power failure. If a module defining a persistent database is replaced, the database is destroyed when the old module is removed.

Translated databases are created using the 71 token compiler in the adjacent initialized data area as fixed length records. The records must not be added or destroyed from the compiled database and the database must not be initialized while running, otherwise full read / write capacity should be supported.

The next available record number field must be set to the number of the most recently assigned record, plus 1, in the compiled database. For every other database this field is set to zero.

• The window title to the current record (buffer 53 of the record) is provided to the client by the server for each client database. For certain database operations, the client may submit string addresses and key buffers to the server. For each database, this was reported to the server by the client module, and the buffer 53 is provided with VM 20. This buffer 53 starts at the sorted address. The contents of the buffer 53 of the record are linked to an individual database after the selection of the record remains available until the client selects another record from that database. Except for those buffers 53 of the record, compiled databases, and parameters passed to the data pool 27 with specific database functions, the client and server do not share any other data space 54. The programs must not assume that all the data in the memory is adjacent.

• The database is defined by a loading process for a module that defines its DPB. Non-existent databases uploaded by user modules become indeterminate automatically and transparently by the server when use ends with terminal resident services when all server-allocated storage is released in connection with these databases.

• The server destroys the persistent databases when the module that defined them is replaced. If the module loads when it is replaced, e.g. in the case of a TRS module, the persistant must destroy the persistent database of the module when the module is explained.

The procedure undertaken by VM 20 when the database is defined during module load depends on the DB type and DB pointer values in DPB 51 and whether the database is non-existent or persistent. If the database is of persistent type, the DPB address is used in conjunction with module ID to identify any previous data belonging to that database. If previous data is available, the next available record number is restored to its previous value. Otherwise, the server (VM 20) defines a new existing storage space and sets the next available record number to zero. In both cases, buffer 53 is provided for the current record in the database. If the DB pointer is zero and the DB type is not a translated type, then the server defines or makes available the storage required for the database, initiates storage at all zeros, provides buffer 53 for the current database record, and sets the next available record number (DBAVAIL ) to zero. If the DB pointer is null and the DB type is a translated type, then the server establishes internal structures to ensure that the client data structure whose source address was given to the DB cursor is used and sets the next available record number (DBAVAIL) for the value passed to the field from DPB 51 for the next available record number. The server maintains up-to-date records of 55 databases, the delimitation between the address location and the record in block 56 for controlling the databases, and a record of which module of the database is accessing at a given moment in the context of info block 57.

A secure process for handling modules according to the present invention will now be described in connection with FIG. 6. In FIG. 6 shows the area of logical read / write memory. The memory area that can be accessed by the module on the left (first module) has a dashed line. The memory area, which cannot be accessed by the first module, has a border drawn by a continuous line. The memory area that can be accessed by more than one module is shown by the dotted-dashed line. VM 20 protects DB 1 and DB 2 databases and the database repository and modules in the module repository so that they are not accessible by any module. After the first module is loaded, uninitialized data in memory 42 can be accessed with the first module, but VM 20 does not allow any area outside this module to be accessed directly by the module. Access to registers, stacks or memory of 46 frames can only be done through the appropriate tokens. Databases can only be accessed through the window procedure mentioned above. In particular, the first module cannot access the memory 26 of its own program where the tokens are located, nor can it access any other module. This is important for virus protection. According to the present invention, the memory allocated to the first module is defined and protected. It is defined by allocating memory according to the amount of memory to be allocated and contained in the module. It is protected because no other module can access the allocated space and no loading mechanism is provided for any program other than modules. Since the preferred process of running modules is one-threaded, any memory allocated in expandable buffer 45 is released before any other module can become active. The free memory is preferably erased.

The list of exclusive entries of the first module is in its title description, which the first module cannot directly access. VM 20 reads the title description and calls the second module mentioned in the entry list - the fgh function from the other module. VM 20 loads the second module and allocates memory for uninitialized data 42 ', frame memory 46' and initialized data 4Γ. The first module cannot access any part of the second module and vice versa. In the title description of the second module, the fgh function was installed in an exclusive list of exportable features. This makes the fgh function available for other modules. VM 20 searches for the fgh function in the code memory space 26 'of the second module and executes the token stream with the corresponding interrupted data (represented by the TITTITT stream). In this case, the piece of code requires access to the DB2 database. According to the present invention, a database is the property of a module, that is, a database can only be accessed by a module that it defined when it first loaded the module. Database access tokens read from code space 26 'are executed by VM 20, which allocated buffer 53' in the uninitiated database space 42 'of the second module at loading. The fgh function requires access to a third record from DB2. VM 20 then transfers the referenced record to window 43 'in the second module, from which it is exported to the uninitialized space 42 of the first module. Using the same procedure for database windows, the first module can also retrieve a record from its own DB1 database, which is transferred to buffer 53 in an uninitialized database space 42. The first module can now work on the results of these two operations.

VM 20 preferentially deals with data objects using Basic Encoding Rules or Tag, Length, Value, abbreviated BER-TLV and abbreviated as TLV for this application, as described in ISO / IEC 8825 (1990). TLV data objects consist of two or three consecutive fields: the tag field indicates their class, type and number, the length field specifies the size of the data and, if the length is not zero, the value field containing the data. Because ICC card responses are generally limited in size to e.g. 255 syllables or less, there is a maximum TLV object size according to the present invention. The tag field is preferably one or two syllables, the length field is preferably one or two syllables, and thus the maximum size of the value field is preferably 252 syllables (this length field requires two length syllables, as explained below). The first tag field is broken into three fields. Bits 7 and 8 define the class of the object. Bit 6 specifies whether the ab value field contains simple data or is a constructed object consisting of other TLV encoded fields. Constructed objects are also called patterns. These cause their value fields to be recognized by TLV sequences when encountered. Being 1 to 5 defines the object number, or, if all of these are set, indicates that they follow additional tag syllables. Additional tag syllables have their 8th set if another syllable follows. All be in up to two syllables are used to determine the name of the tag. The length field consists of one to three consecutive syllables, typically two. If bit 8 of the first syllable is 0, then being 1 to 7 indicates the size of the value field. If bit 8 of the first syllable is 1, then 1 to 7 indicate the number of syllables that follow. The following syllables, if any, indicate the size of the value field and appear with the most characteristic first bit. The value field can either consist of simple data or be constructed with additional TLV encoded sequences. If bit 6 of the first syllable in the tag field is set, then the value of the field contains additional TLV sequences. Simple objects can be encoded in several different formats: binary encoded decimal nodes with leading zeros or finite nodes with all bits set, binary numbers or syllable sequences, alphanumeric or ASCII syllable sequences, or undefined formats. Each one is treated differently depending on how it is used. ICC 5 can also use the Data Object List (abbreviated DOL) to request the values of defined tag names. Card 5 sends a DOL consisting of a list of tag and length fields, and terminal 1 returns the corresponding value fields without punctuation.

Each TLV to be used must be defined by terminal or user programs to establish its data type and name. Because terminal programs and applications are developed separately, VM 20 according to the present invention utilizes an associated structure (balanced binary tree) to allow the rapid addition and removal of tag names from the global tag name list. This requires that the following structure must be translated for each TLV in the initialized data space 41 in the module defining the TLV:

Link A cell with left (two high order syllables) and right (two low order syllables) provides links to tree elements.

Linkleft 16-bit offset with a sign from this TLV access parameter to an access parameter TLV record whose tag is numerically smaller than the tag of this record. A value of zero indicates that this TLV is not associated with a TLV with a tag that is numerically smaller than that TLV.

Linkright 16-bit offset with a sign from this TLV access parameter to an access parameter TLV record whose tag is numerically larger than the tag of this record. A value of zero indicates that this TLV is not associated with a TLV with a tag that is numerically larger than that TLV.

Tag A two-string string whose big-endian (the system in which the highest order syllable in the cell is at the lowest address and first appears in the data stream) is a numeric value TLV tag.

Type A single syllable defining visual information.

Reserved A syllable that must be initialized to zero with compiler 71.

Data Cell holding VM-specific information that includes access to the length and value fields for this TLV. This field must be initialized to zero with compiler 71. The system must also maintain a status syllable for each TLV. This may be a reserved syllable in the structure above. The low order bit in this syllable should be set if TLV was a modified value as a result of being in a sequence that was processed with TLVPARSE or TLVSTORE tokens. The purpose of maintaining custom status is to identify TLV values that contain valid data (which can be null) and distinguish them from TLV values that were never set and are therefore not valid. The VM kernel manages the global TLV tag list by managing the list of pointers to the initialized data space 41, which maintains their actual definitions as described above. When a module is loaded, its TLV definitions are added to this list as part of its initialization; when explained, its TLV definitions should be automatically removed from the list using VM 20. An exception can be used if the module contains a TLV definition that already exists. The address for the Link field described above returns as an access parameter for TLV references. The programmer should not access these fields directly or make any defaults on their contents after VM 20 has defined TLV definitions.

References to TLV definitions in source code are translated as either direct references to the definition structures defined above or numeric tag values. Within certain binary TLV definitions, individual syllables or groups of bits are defined to have definite meanings. They are referred to as TLV bits. References to TLV bits can be translated by literally laughing at a syllable within the TLV value field. Bit 0 is the least significant bit in the first syllable, bit 7 is the most significant bit of the same syllable, bit 8 is the least significant bit of the second syllable, etc.

The data attributed to the TLV definition is exposed to use over a 252-syllable temporary fill area maintained by VM 20 in the form of a database window (see Fig. 7). It is permitted for the application program to modify the contents of this temporary fill area. If changes are to be withheld, the title and length within the temporary fill area must be handed back to the TLVSTORE token. The title and contents of the temporary storage pool may become invalid when any TLV token is executed afterwards.

As part of the security management of the cards 5 inserted in the reader 5, a check of the cards 5 known to be lost or invalid is performed. The list of such cards is known as the Black or Hot Card Mouth. Black or hot card management is provided by a set of defined features that are specific to managing a large hot card. A typical list can contain 10,000 primary account numbers (PANs), each with up to 10 syllables or 20 binary coded decimal (BCD) digits. PAN items are stored in compressed numeric (cn) format, filled to the right with hexadecimal FHs. Because PAN has a maximum of 19 BCD digits, the item in the list will always be filled with at least one FH. When searching through a hot card list, FHs in a list item are understood to be wild cards or digits that are not cared for, but any FHs in the PAN used as an entry are not wild cards. Wild cards can only appear at the right end of the item. PAN is understood to be on the hot card list if there is an item on the list identical to the first FH in the item.

The second part of security management is the provision of cryptographic services for data encryption and decoding. Any suitable encoding procedures may be used. Three encoding algorithms are specifically provided for VM 20: module multiplication and module potentiation, which are used in the RS A algorithm; and the SHA-1 algorithm for safe scattering, but the invention is not limited thereto. Modulo multiplication performs the multiplication of two unspecified values of x and y, where the product is reduced using module Z. The formula is:

result = mod (x * y, z).

The values entered (x, y, z) all have the same length. They are represented by syllable strings and can be any multiple of 8 up to and including 1024 bits. These values must be in big-endian syllable order.

The Secure Hash Algorithm (SHA-1) algorithm is standardized as FIPS 180-1. SHA-1 takes arbitrary lengths of incoming messages to form a 20-syllable scatter value. Modulus potentiation raises an unspecified value of x to the potency given by an unspecified exponent y, where the product is reduced using module Z. The formula applies:

result = mod (x ^A y, z).

The input value x and module z are represented by syllable strings and can be any multiple of 8 bits up to and including 1024 bits. Values must be in big-endian syllable order.

Services and therefore software and even I / O preparations may change over time depending on market requirements. When major changes are required, software updates in Terminal 1 can be performed manually or remotely over a telecommunications network. For user-dependent services, however, it is preferable to use a dynamic but secure procedure for performing minor or user-specific updates for the services provided by Terminal 1. The software mechanism of the plug and socket according to the present invention provides a flexible and secure a way of real-time configuration of the various modules that make up terminal programs and uses. As shown schematically in FIG. 8, the transaction system according to the present invention may specify the number of processes (called sockets 60) that can be inserted by the user programmer (and therefore to you because it is under the control of the acquirer and controlled by the payment system), 61, 62, that they act as storehouses for adding additional reinforcement code (called plugs 66) during transactional processing. All additional code to be inserted into socket 60 must be written using a set of tokens for VM 20. Sockets 60 are preferably located at various appropriate points in existing terminal uses 61, 62, or even in the terminal program itself. They are used to refer to library functions and may even appear within a library function if the payment system anticipates the need to change the way the library function works. Sockets 60 are initialized to embedded behaviors using the VM

20. If the terminal does not take any additional action, the behavior of sockets 60 will be embedded in that they do nothing when they are performed (i.e. non-operation).

Plugs 66 include executable code written with tokens supported by Terminal 1 and can be inserted at points defined by sockets to reinforce the embedded terminal logic. Plugs 66 may already exist in terminal 1 in the plug library 63 to be retrieved from ICC 5, e.g. 67 socket-socket identifiers in ICC 5 and logic in terminal 1. Socket-socket identifiers 67 include references to both the socket and the socket to be filled with the socket, with the socket not ICC 5 but library 63. Sockets 66 they can also come from input device 65 (such as ICC 5 or the main system connected to terminal 1), but only if payment system members agree, e.g. issuer, acquirer and trader.

At the conclusion of the transaction, sockets 60 will return to their original user embedded behavior. According to the present invention, it is preferred that ICC 5 does not include all uses but only plugs 66 that amplify existing terminal uses because they require less memory.

Sockets 60 hold execution pointers, also known as process indicators, that allow the creation of a process whose behavior may change during run time. Sockets 60 can be viewed (and executed) as a field of operations accessed using the DOSOCKET token that retrieves the socket number as a stacked syllable, or the IDOSOCKET token that retrieves the socket number from the data stack 27.

The sockets 60 allow the terminal program to be reconfigured or used to provide changes or amplification of the transaction processing flow. Alternatively, sockets in ICCs-5 may allow ICCs 5 to be upgraded by terminal 1. Sockets 60 provide an interface between software modules and processes that may come from several different sources (acquirer, publisher, and more). Because the acquirer and the issuer have a contractual relationship, they may agree to use certain sockets 60 provided by the acquirer's program at the terminal so that the issuer can extend the behavior of the program, e.g. by providing a loyalty feature (air miles, coupons, and more).

The module may specify that sockets 60 are automatically reconfigured when loaded for execution, or the client program may assign a new procedure programmatically during socket operation. If the safety conditions so permit, in-service sockets may be assigned embedded behavior and may then be retrofitted with plug-ins with new procedures from the following modules to ensure specialized behaviors. In order to avoid undetermined situations, it is preferable that all operations directed to use a particular socket 60 have no data malt effect (except for the socket zero, as will be explained later). This ensures programmatic continuity regardless of which directed version of the process is running. The built-in operation of all sockets 60 prior to the change must be at least that of non-operation.

The acquirer may allow transactional reinforcements with code on ICC 5 as part of the CSS referenced above. If so, it can be implemented with sockets 60. The library or executable module may include the definition of new sockets 60 for later plugs 66 coming from ICC 5. In this case, the module would define socket 60 and then use the SETSOCKET token to attach it embedded behavior (often zero behavior).

v

If access control allows, ICC 5 could later load a plug 66 that includes tokens that define a new behavior and then use the SETSOCKET token to be stored in the same socket 60, transporting the embedded behavior.

Behavioral modification is nimble and flexible, but it can give malicious people the ability to modify behavior to their advantage. Special care is required for plugs 66 of ICC 5 if they can modify the behavior of the socket or be installed in the software stream before successful card authentication. For security, the terminal software according to the present invention can define a socket control process that controls whether or not each individual socket can be modified. Thus, e.g. the acquirer strictly controls the execution of the code loaded from the ICC 5 card so that the ICC 5 cannot be plugged into any socket until all validation programs have been executed on the card, e.g. electronic signature verification.

In accordance with the present invention, socket security includes the definition of an socket monitoring process to be used in the following socket attempts at socket 60 (SETPLUGCONTROL token). The PLUGCONTROL procedure must be written in such a way that a return for a specific socket number is returned, or that socket 60 should now be modified. When the list of sockets is then processed during module loading or when socket 60 is filled programmatically, VM 20 first executes a user-written PLUGCONTROL process to determine if socket 60 can actually be filled with socket and retain the existing socket behavior 60 if can not.

A module that wishes to restrict access to any socket 60 before loading another module for execution may execute a process defined by the SETPLUGCONTROL token in a plug-in socket (socket zero) with the PLUGCONTROL function selected as a parameter before loading that module. When lists of sockets for the next module and any other modules loaded for its implementation are processed, sockets 60 that are denied access by a user-defined PLUGCONTROL procedure should retain their existing behavior. This condition should not be interpreted as a mistake. A code that wants to restrict access to any socket before executing further code can execute a process defined by a SETPLUGCONTROL token with the PLUGCONTROL procedure selected as a parameter at the appropriate point in the program stream. The software request to fill socket 60 may determine if the request was accepted or rejected by a call to SETSOCKET. Any socket whose behavior has been modified either by the module loading process or dynamically by a programmed command is restored to the behavior it had when it was loaded to execute the last executable module as part of a stopping process stored inside a process that defined by the module execution token (EXECUTEMODULE).

As an example of an acquirer-specific function, suppose the transaction code includes the phrase 27 SOCKET LOYALTY, which defines LOYALTY and makes it available for later execution. The acquirer's transaction program code further defines a code that sets the permission tag for this socket only if the user is the same as the acquirer and the transaction amount exceeds a certain minimum. A transaction is present that reads any code from ICC during the transaction. a program that updates user miles for frequent air travelers and then attempts to implement the PLUG REWARD INTO LOYALTY phrase. This phrase links the implementation of REWARD to the implementation of LOYALTY. If the LOYALTY tag for socket permission is set according to the logic above, then SETSOCKET occurs; otherwise, LOYALTY will retain its embedded behavior like e.g. non-action. When the user code performs its LOYALTY function later, it will then allow ICC defined REWARD only according to the rules defined by the acquirer.

In a typical manner, VM 20 running at terminal 1 may have a limited number of sockets 60, e.g. 64 sockets numbered from 0 to 63. In its most basic form, a skeletal terminal program could be composed approximately entirely of sockets 60 and a basic program stream from socket to socket. The sockets 60 would then be filled with transaction processing operations with other modules loaded during use-select time either by terminal 1 or by ICC 5. Sockets 60 appearing in the skeleton program prior to use selection are assigned an embedded null behavior by TRS. If a procedure from more than one module is plugged into a given socket 60, the last operation simply replaces any previous one.

Module loading, module handling, and execution

Code written to run on VM 20 (which includes terminal resident services translated as token modules) may assume that the subsequent inclusion of terminal specific kernel hardware supporting VM 20 has performed any necessary terminal-specific initialization initialization and has initiated the implementation of the Master Terminal Loop of Terminal Resident Services (TRS) through the module loading process described below. If it exits the main processing loop for the TRS, control returns to the terminal-specific software layer responsible for reloading the TRS and re-entering the main loop. All VM resources are released when TRS exits except for data in persistent databases. Source release occurs when the terminal is disconnected from power, the TRS goes out, or the TRS restarts with the terminal operating system (if any). If an updated version of any TRS module has been obtained since it last entered the TRS main loop, all TRS resources are released, including data in its persistent databases when it exits.

Software running on Terminal 1 or ICC 5 is managed by VM 20 in the form of one or more modules, each module may contain any of the following categories of information:

• token code • initialized data • assignment of uninitialized data • database definitions • TL V definitions • socket list • module interdependencies.

Each module is preferably delivered to Terminal 1 in Format (MDF) for module delivery. VM 20 maintains a persistent repository in read / write persistent memory 18 for modules delivered and installed at terminal 1. Each module in the repository must be identified by a module identifier or module ID. After registering in a module repository, module information is available through a persistent module database maintained by VM 20 and stored in persistent memory 18. According to the present invention, VM 20 protects modules in the repository from being modified by any other module because there are no tokens for such access. Furthermore, VM 20 ensures that a new version of the given module is installed in the repository, while the module with the same module ID exits the execution purposes.

According to the design, there are two stages of processing a module: first it is loaded, which means that it becomes accessible and its data, databases, etc. are defined, and second, if it is a viable module, VM 20 starts processing its tokens, starting at its entry point . The implementation process will be described in connection with the flowchart of FIG. 9.

First, in step 100, the resources are tagged and saved. Before running VM 20, it flags its status and stores all the resources needed to recover it later. This condition includes;

• The location of the expandable memory pointer, frame pointer, and frame end pointer.

• The contents of the complete list of liquid sockets.

• TLVs recorded in the list of TLV tag names.

• Other internal data required by the VM implementation to manage module activation and execution.

The module is further loaded in step 102. The execution module ID is handed over to the Load Module routine, which will be described later. If the module loads without error as specified in step 104, it can be executed and the program continues until step 108. If an error is fixed in step 104, the implementation of the module is discontinued and all the resources needed to execute the module are released to step 105. This requires VM 20 to perform the following actions;

• All non-existent memory required to load a module and any module that is required to be loaded must be released and cleared to zero. This includes, but is not limited to;

• Space required for initialized and non-initialized data of all modules.

• The space required for any internal TLV buffers and data management structures defined by these modules.

• The space required for any internal buffers and management data structures required by the databases identified by these modules.

• The TLV name list maintained by the VM for character mapping must be restored to its state immediately prior to module execution.

• The contents of the socket list maintained by the VM must be restored to their state immediately before executing the module.

• The contents of the frame pointer, the frame end pointer and the expandable memory pointer are restored to their values immediately before the module is executed.

After successful loading of the module, it is determined in step 106 whether the module is executable or a library module. In the latter case, the module does not execute and VM 20 releases all resources in step 110, as described for step 105. If a module is feasible, a field defining the module entry point is determined.

VM 20 starts the module by calling the token defined by the entry point field. Then, in each step 108, each token is executed. The module ends with the use of a RETURN token, after which all resources are released in step 110.

The procedure required to load a module, the Load Module subroutine, will be described, referring to the flowchart shown in FIG. 10. If an error is detected while loading a module, it causes the Load Module routine to return false immediately. The general error is e.g. out of memory, where there are insufficient resources to provide space for initialized data, uninitialized data, databases or TLVs; when a duplicate of the TLV tag is detected; etc. Initialized data must be established before the database and TLV sections are processed, as these are part of the initialized data section. In step 120, it is determined whether the module is already loaded in memory. If it is already loaded, it is not loaded a second time and the Load Module follows directly and returns true. It is further determined in step 122 whether the module is in the repository. If not, it cannot be loaded and the Load Module routine fails and returns false. In step 124, it is determined how many syllables in the data are required for area 41 of the uninitialized module data and the required amount is reserved. This area 41 is completely set to zero by VM 20. Similarly, in Step 126, the required number of data syllables is reserved for the module initialized data area 42. The initialized data is then copied to this area. In step 18, the TLVs defined in the module are added to its internal names list using the VM 20 used for the TLV mapping. The root of the TLV data structure is saved. Further, in step 130, the databases identified by VM20 are defined in the module to be loaded. Steps 128 and 130 can be performed in any order. In step 132, the input modules for the liquid module are separated. In step 134, a list of the modules entered is traversed, each being recursively loaded. If the module entered cannot be loaded for any reason as specified in step 136, the module entered by this module is also understood to have failed to load because it cannot access the services of the module entered. In this case, the Load Module returns false. Step 138 specifies whether a further module should be entered. If yes, then the process returns to step 132. After determining in step 138 that the last module entered was recursively loaded, the current module has its resources allocated, loaded and defined without error, then the Load Module fills the sockets 60 in its list in step 139 and returns true, indicating that the module was loaded successfully. Any attempt to fill the socket with zero must be ignored by VM 20. If the socket zero is to be filled, this must be achieved by using the SETSOCKET token.

The process of filling the sockets 60 in step 140 will be described with reference to FIG. 11. Step 140 defines the embedded behavior for each socket in the loaded module. In step 141, it is determined whether a plug exists. If not, then the module is implemented in step 149. If yes, the first plug is selected in step 142. In 143, it is determined whether or not the security socket of the modified socket is affixed. If not, the socket is filled in step 146. If yes, the security function defined for the socket is executed. If the safety evaluation is positive, the socket is filled in step 146. In step 148, it is determined whether the socket is the last socket. If not, the following plug is selected for evaluation. If the security check is negative, determine whether the plug is the last plug in step 147. If it is determined in steps 147 or 148 that the plug is the last plug, the module is implemented with embedded behavior for all sockets that were not filled and filled with behavior for those who have been filled. This is how behavior modification is achieved for you.

Modules loaded with ICC 5 using the LOADCARDMODULE token must be treated differently from those loaded from the repository at Terminal 1 using the EXECUTEMODULE token. The flowchart for LOADCARDMODULE is shown in fig. 12. Before running the card module, VM 20 indicates its status and stores all the resources needed in step 150 so that this status can be restored later. The status includes:

• The location of the expandable memory pointer, frame pointer, and frame end pointer.

• The contents of the full list of sockets.

• TLVs recorded in the list of TLV tag names.

• Other internal data that the VM requires to control the activation of the card modules.

The module is loaded in step 152 using the Load Module program described above in connection with FIG. 9; the difference is that the module is on ICC 5 and not in the repository and not yet loaded.

If it is determined in step 154 that the card module failed to load successfully, all resources are returned in step 155 to the status they had immediately before executing the LOADCARDMODULE token. This requires:

• All non-volatile memory required to load a module and any module that needs to be loaded must be released and cleared to zero. This should include, but is not limited to:

• The space required for all initialized and non-initialized module data.

• The space required for any internal TLV buffers and management data structures defined by these modules.

• The space required for internal buffers and management structures required by the databases identified by these modules.

• The TLV name list maintained by the VM for character mapping must be restored to its state immediately before executing the module.

• The contents of the socket list maintained by the VM must be restored to their state immediately before executing the module.

• The contents of the frame pointer, the frame end pointer, and the expandable memory pointer are restored to their values immediately before the module is executed.

If the card module is loaded successfully, the status stored in step 150 Mark and save resources is simply discarded in step 156. Thus, the card module was transferred to the current system. In order to be useful, the card module must fill the sockets, otherwise there is no way to execute any code present in the card module. Further specified in step 158, ab is an executable module, and if so, is performed in step 160 as described in conjunction with steps 106 and 108 of FIG. 9.

The specific embodiments of the invention described above are intended to be illustrative only and may be subject to many other variations and modifications in accordance with the principles of the invention. All such embodiments and variations and modifications thereof are understood to be within the scope of the invention as defined by the following claims.

Claims (64)

1. A transaction management system for performing transactions between the first device and the second device, said first and second device being adapted to communicate with each other and at least one of said first and second device is an integrated circuit card, said system comprising at least one input / output device; a portable virtual machine for interpreting a computer program at said first preparation and a means of responding to said interpreted program for executing said program, characterized in that said virtual machine comprises a virtual microprocessor and a driver for said at least one input / output device. A terminal comprising a first device for performing a transaction with a second device, at least one of said first and second devices being an integrated circuit card comprising: a portable virtual machine that interprets a computer program at said first preparation and a runtime capable of responding to said interpreted program for executing said program, characterized by said portable virtual machine comprising a virtual processor and driver for at least one input / output device. 3. An independent portable intelligent card, comprising a first device for performing a transaction with a second device, said intelligent card comprising a portable virtual machine marked with a virtual microprocessor and a driver for at least one input / output device. A system according to claim 1 or a terminal according to claim 2 or an intelligent card according to claim 3, characterized in that the machine instructions for said virtual machine are a set of tokens, said tokens being a custom syllable code. An intelligent card according to claim 3 or 4, further comprising a computer program stored on said intelligent card, said virtual machine interpreting said computer program and the execution means responding to said interpreted program for executing said program. System or terminal according to claim 4 or an intelligent card according to claim 5, characterized in that said computer program is written as a stream of tokens selected from said set of tokens and corresponding interrupted data. System or terminal or intelligent card according to claim 6, characterized in that said token flow is transmitted to the module, the module including the token flow together with the corresponding interrupted data required to execute the module. System or terminal or intelligent card according to claim 7, characterized in that said module also includes an indication of memory requirements for executing said module. System or terminal or intelligent card according to claim 8, characterized in that the virtual machine also includes means for loading said module and interpreting tokens therein. System or terminal or intelligent card according to claim 9, characterized in that said means for loading and interpreting tokens reads said tokens in said module and an exception is used if a token not belonging to said set is read. System or terminal or intelligent card according to any one of claims 7 to 10, characterized in that said virtual machine includes a read / write logical address space that has a repository for at least said module, and said module includes an indication of the amount of read / write logical the address space required for its implementation; and said virtual machine also includes an allocation means for loading said read / write logical address space amount according to said indication, wherein said assigned read / write logical address space has defined and protected boundaries. System or terminal or intelligent card according to claim 11, further comprising means for releasing said amount of read / write logical address space upon completion of said module. System or terminal or intelligent card according to any one of claims 9 to 12, characterized in that said second device includes means for providing at least one program instruction which can at least modify the behavior during the execution of said computer program; and after said loading and interpreting means has loaded said module and while said module is running, said loading and interpreting means uploads and interprets said at least one program instruction depending on a predetermined security condition; and said executing agent responds to the loaded program instruction * interpreted by said virtual machine, and executes said computer program with said modified behavior. System or terminal or intelligent card according to claim 13, characterized in that said security condition is provided by a function. System or terminal or intelligent card according to any one of claims 9 to 14, characterized in that it further comprises a read / write logical address space including at least one database including at least one record, said module including an indication of the amount of uninitialized read / the written logical address space required to execute said module; said loader allocates the required amount of uninitialized logical address space according to said indication; and means for accessing a record in said database, wherein the record in said database is accessible only through said module, and said access means providing a window on the current record of said database and copying said record in the region of said uninitialized read / write logical address space that can be addressed by said application program. 16. Transaction management system, comprising: a first device and a second device, said first device and said second device being adapted to communicate with each other, and at least one of said first device and the second device is an integrated circuit card; said first device includes a virtual machine, said virtual machine comprising means for downloading and interpreting said computer program, indicated that said second device includes means for providing at least one program instruction capable of at least modifying the behavior of the computer program during execution at said the first draw; and said uploading and interpreting means being further adapted to download and interpret said at least one program instruction depending on a predetermined security condition after said uploading and interpreting means has loaded said computer program and while said computer program is running; and an executable means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction. 17. A terminal comprising a first device for performing a transaction with a second device and at least one of said first and second devices is an integrated circuit card, said terminal comprising: said first device comprising a virtual machine, wherein the virtual machine includes a loading means and interpreting said computer program, characterized in that said second device includes means for providing at least one program instruction capable of at least modifying the behavior of the computer program during execution on said first device; the uploading and interpreting means is further adapted to load and interpret said at least one program instruction depending on a predetermined security condition after said uploading and interpreting means has loaded said computer program and while said computer program has been running; and an executable means for executing said downloaded and interpreted computer program with said modified behavior in response to said and interpreted program instruction. 18. An independent portable intelligent card including a first device for performing a transaction with a second device, said intelligent card comprising: said first device comprising a virtual machine, said virtual machine comprising means for downloading and interpreting said computer program, said second device including means for providing at least one program instruction that can at least modify the behavior of a computer program while operating on said first device, and said loading and interpreting means being further adapted to load and interpret said at least one program instruction depending from a predetermined security condition after said loading and interpreting means downloaded said computer program and while said computer program was running; and an executable means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction. iv. The system of claim 16 or the terminal of claim 17 or the intelligent card of claim 18, wherein said security condition is provided by a function. System or terminal or intelligent card according to claim 19, characterized in that said at least one program instruction is a first program instruction and said first preparation includes a second program instruction that can at least modify the behavior of said computer program during operation, and said first program instruction includes reference to said second program instruction; and said loading and interpreting means responding to said loading reference of said second program instruction, said executing agent executing said computer program with said modified behavior as defined by said second program instruction. 21. The system or terminal or intelligent card according to claim 20, characterized in that said program and said first and second program instructions are written using a stream of tokens and corresponding interrupted data, each token being a custom syllable selected from a set of customized syllable codes. System or terminal or intelligent card according to claim 21, characterized in that said virtual machine directs said token stream and said interrupted data of said first and second program instructions to said token stream of said computer program. 23, System or terminal or intelligent card according to claim 21 or 22, characterized in that at least the token stream of said computer program and at least one other computer program instruction is transported in a module, each module including the corresponding token flow together with the corresponding interrupted data required to implement said module. A system or terminal or intelligent card according to claim 23, characterized in that said module also includes an indication of the memory required to execute said module. A system or terminal or intelligent card according to claim 23 or 24, characterized in that the module of said computer program also includes an exclusive list of at least one flexible socket, said at least one socket specifying the position in the flow of tokens and interrupted data of said computer program module to which said computer program directs said first program instruction. 26. The system or terminal or intelligent card according to claim 25, characterized in that said at least one adaptive socket in said computer program module includes an executable reference to the modified behavior. System or terminal or intelligent card according to claim 26, characterized in that said means executes said computer program with said default behavior of said predefined security condition and does not allow the loading of said at least one program instruction. 28. A system or terminal or intelligent card according to any one of claims 23 to 27, characterized in that said virtual machine includes a read / write logical address space and said module includes an indication of the amount of read / write logical address space required for its implementation; and said virtual machine also includes an allocation means for loading said computer program module amount of read / write logical address space according to said indication, wherein said assigned read / write logical address space has defined and protected boundaries; and means for releasing said amount of read / write logical address space after completion of said computer program module. System or terminal or intelligent card according to any one of claims 23 to 28, further comprising a read / write logical address space including at least one database comprising a plurality of records, said module including an indication of the amount of uninitialized the read / write logical address space required to execute said module; said loading means adapting the required amount of uninitialized logical address space according to said indication; and a means of accessing a record in said database, wherein the records in said database are accessible only through said module and said access means providing a window to said record of said database and for copying said record to a portion of said uninitialized read / write logical address space that can be addressed by said application. A system or terminal or intelligent card according to any one of claims 16 to 27, characterized in that said security condition includes means for verifying at least the origin and integrity of the data and program instructions for said other device. 31. A transaction system for performing transactions between the first preparation and the second preparation, the system comprising: a virtual machine for interpreting a set of custom tokens with a syllable code used for this purpose; said virtual machine includes a virtual processing unit and a read / write logical address space; at least one first application program is written as a stream of tokens selected from said set of tokens and corresponding interrupted data; and a downloader for downloading said at least one first application program; characterized in that at least one said first application program comprising an indication of the amount of read / write logical address required to execute it; and said virtual machine includes; means for assigning the first amount of read / write logical address space characteristic of said at least one first application program in accordance with said instruction, wherein said assigned read / write logical address space has defined and protected boundaries. 32. A terminal comprising a first device for performing transactions with a second device, said first preparation comprising; a virtual machine for interpreting a set of custom tokens with a syllable code adapted for that purpose; and said at least one first application program written as a stream of tokens selected from said set of tokens and corresponding interrupted data; said virtual machine includes a virtual processing unit and a read / write logical address space; a downloader for downloading said at least one first application program; and characterized in that at least one first application program includes an indication of the amount of read / write logical address space required for its implementation, and said virtual machine also includes: means for assigning the first amount of read / write logical address space characteristic of said at least one first application program according to said indication, wherein said assigned read / write logical address space has defined and protected boundaries. 33. An independent portable intelligent card, including a first device for performing a transaction with a second device, said first preparation comprising: a virtual machine for interpreting a set of custom tokens with a syllable code used for this purpose; and at least one first application program is written as a stream of tokens selected from said set of tokens and corresponding interrupted data; said virtual machine includes a virtual processing unit and a read / write logical address space; and a downloader for downloading said at least one first application program; characterized in that at least one first application program includes an indication of the amount of read / write logical address space required to execute it; and said virtual machine also includes: means for assigning the first amount of read / write logical address space characteristic of said at least one first application program according to said indication, wherein said assigned read / write logical address space has defined and protected boundaries. 34, characterized in that it is at least one of the first and second ICC devices. The system of claim 31 or the terminal of claim 32, or the intelligent card of claim 33, further comprising means for explicitly releasing said first amount of read / write logical address space upon completion of said at least one program. 35, characterized in that said first application program also includes a first exclusive list of at least one function that can be exported to other application programs, and further comprises means for generating said at least one function available to other programs. A system or terminal or intelligent card according to any one of claims 31 to A system or terminal or intelligent card according to any one of claims 31 to A system or terminal or intelligent card according to any one of claims 31 to 36, characterized in that said first application program is a module and said second application programs are other modules, each module including at least one token stream selected from said the token set, the corresponding data intrusions, the first exclusive list of at least one function to be exported, and an indication of the amount of read / write logical address space required to execute the module. 38. The system or terminal of claim 37, wherein said first module includes a second exclusive list identifying at least one second module from which at least one function is to be exported, and said loader loading said at least second module in accordance with said to the second list after loading said first module. 39. The system or terminal or intelligent card according to claim 38, characterized in that said first module terminates if said at least one second module to be imported fails to load successfully. System or terminal or intelligent card according to any one of claims 37 to 39, characterized in that said allocation means allocates said first amount of read / write logical address space after loading said first module and only assigns a second or further amount of read / write a logical address space for said first module in a single expandable buffer, starting at the first address; and upon releasing said second amount of read / write logical address space by said first module, said release means releases said second amount of read / write logical address space and any further allocations behind said first address. 41, characterized in that said read / write logical address space includes at least one database that includes at least one record, and said module includes an indication of the amount of uninitialized read / write logical address space required to execute said module, and are records in said database accessible only through said module; said loader allocates the required amount of uninitialized logical address space according to said indication; and a record access means in said database, said access means providing a window to the current record of said database and copying said record to a portion of said uninitialized read / write logical address space that can be addressed by said user program. 41. The system or terminal or smart card of claim 40, wherein said release means releases said second amount of read / write logical address space and any further allocations behind said first address after completion of said first module. 42, characterized in that said release means deletes any amount of adapted read / write logical address space upon completion of said first module. A system or card or intelligent card according to any one of claims 37 to A system or terminal or intelligent card according to any one of claims 34 to 44. A transaction system for performing transactions between the first preparation and the second preparation, wherein at least one of said first and second preparations is an integrated circuit card and said system comprises: a virtual machine for interpreting a set of custom tokens used for this purpose; said virtual machine includes a virtual processing unit and a read / write logical address space; at least one database comprising at least one record and at least a computer program to execute with said virtual machine, characterized in that said computer program is a module written with the flow of said tokens selected from said set and including an indication of the amount of uninitialized read / the written logical address space required to execute said module; a loader for loading said module and for assigning the required amount of uninitialized logical address space according to said indication; and a means of accessing the record in said database, wherein the records in said database are accessible only through said pedodule and said access means providing a window on the current record of said database and copying said record to a portion of said uninitialized read / write logical address space , which can be addressed by said application. 45. A terminal comprising a first device for performing transactions with a second device, wherein at least one of said first and second preparations is an integrated circuit card and said first preparation comprises: a virtual machine for interpreting a set of custom tokens from the syllable codes used in this purpose; said virtual machine includes a virtual processing unit and a read / write logical address space; at least one database comprising at least one record and at least one computer program to execute with said virtual machine, characterized in that said computer program is written in a module by a stream of tokens selected from said set and including an indication of the amount of uninitialized read / the written logical address space required to execute said module; a loader for loading said module and for assigning the required amount of uninitialized logical address space according to said indication; and a means for accessing a record in said database, wherein the records in said database are accessible only through said module, and said access means providing a window on the current record of said database and copying said record to a portion of said uninitialized read / write logical address space that can be addressed by said application. 46. An independent portable intelligent card including a first device for carrying out a transaction with a second device, said first preparation comprising: a virtual machine for interpreting a set of personalized token code tokens used for this purpose; said virtual machine includes a virtual processing unit and a read / write logical address space; at least one database comprising at least one record and at least one computer program for execution with said virtual machine, characterized in that the computer program is written in a module with a stream of tokens selected from said set, which includes an indication of the amount of uninitialized read / the written logical address space required to execute said module; a loader for loading said module and for assigning the required amount of uninitialized logical address space according to said indication; and means for accessing the record in said database, wherein the records in said database are accessible only through said module and the access means providing a window to the current record of said database and copying said record to a portion of said uninitialized read / write logical address space , which can be addressed by said application. A system according to claim 44 or a terminal according to claim 45 or an intelligent card according to claim 46, characterized in that said database is defined after the first loading of said module. A system or terminal or intelligent card according to any one of the preceding claims 1 to 47, characterized in that said virtual machine is a stacking machine. 49. The system or terminal or intelligent card of claim 48, wherein said virtual machine is at least a two-layer machine in which the first stack is a data store m the second stack is a return stack. System or terminal or intelligent card according to any one of the preceding claims 1 to 49, characterized in that the virtual machine includes frame memory of the local variable, a frame pointer register for storing frame pointers pointing to the beginning of the frame in memory, and a pointer end register frames pointing to the end of the frame in memory. , 51. A system or terminal or intelligent card according to claim 49 or 50, characterized in that said data or return stacks in the memory are not directly addressable by said computer program, but are only accessible through stack operations defined by tokens and interpreted by said virtual machine. System or terminal according to any one of the preceding claims, characterized in that said first device is a hand-held device. 53. The system or terminal of claim 52, wherein said hand-held device includes an integrated circuit ICC. System or terminal according to any one of the preceding claims 1 to 53, characterized in that said second device comprises an ICC. A system according to any one of the preceding claims 1 to 54, characterized in that said device is a terminal. 56. The system or terminal or intelligent card according to any one of the preceding claims 1 to 55, characterized in that both the first and second devices include ICCs. A system or terminal or intelligent card according to any one of the preceding claims 1 to 56, characterized in that the transaction system comprises at least one implementation of the following sequence: a. establishing a communication link between said first and said second devices; b. a choice of use that includes said computer program and a customized data set identifying the transaction; c. implementing said use; and d. ending the transaction. 58. The system or terminal or intelligent card according to any one of the preceding claims 1 to 57, characterized in that the transaction is a financial transaction and said system is a financial transaction management system. An integrated circuit card comprising a program instruction that can modify the behavior of a running program in a system according to any one of claims 1 to 58, in a terminal according to any one of claims 2 to 58, or an intelligent card according to any one of claims 3 to 58. 60. A method of performing a transaction between a first device and a second device, at least one of said first devices and the second device being an integrated circuit card; comprising providing at least one program instruction on said second device capable of at least modifying the behavior of the computer program while operating on said first device; downloading and interpreting said computer program, downloading and interpreting said at least one program instruction depending on a predetermined security condition while said computer program is running; and executing said downloaded and interpreted computer program with said modified behavior in response to said downloaded and interpreted program instruction. 61. A method of performing a transaction between a first draw and a second draw, comprising: interpreting at least one application program written as a stream of syllable code tokens selected from the token set and the corresponding interrupted data; downloading said at least one user program; assigning the first amount of read / write logical address space specific to said at least one application program according to the indication contained in said computer program, the amount of read / write logical address space required to execute it; and defining and protecting the boundaries of said assigned read / write logical address space. The method of claim 61, further comprising: explicitly releasing said first amount of read / write logical address space upon completion of said at least one first user program. 63. A method for implementing a transaction system between a first preparation and a second preparation, wherein at least one of said first preparation and the second preparation is an integrated circuit card comprising: interpreting tokens in a module written by the flow of said modules selected from the token set ; allocating the amount of uninitialized logical address space according to the indication in said module of the amount of uninitialized read / write logical address space required to execute said module; accessing the record in the database by providing a window to the current record of said database, the records in the database being accessible only through said module; and copying said record to a portion of said uninitialized read / write logical address space that can be addressed by said module. 64. A method of performing a transaction between a first device and a second device, wherein at least one of said first devices and the second device is an integrated circuit card comprising: providing a portable virtual machine comprising a virtual microprocessor and driver for at least one input / output device; interpreting a computer program at said first preparation using a portable virtual machine; and executing said program in response to said interpreted program.