MXPA99000076A - Portable system of safe transaction for intelligent devices and programab - Google Patents

Abstract

The present invention provides a transaction management system for executing transactions between a first device (1) and a second device, the first and second devices are adapted for communication with each other and at least one of the first and second devices is a circuit card integrated, the system comprises: at least one input / output device (25), a portable virtual machine (20) to interpret a computer program in the first device, the virtual machine comprises a virtual microprocessor and an impeller for less an input / output device (25), and an execution means that responds to the program interpreted to execute the program. The general link technical concept behind the present invention is the portable condition, combined with data security and operating time guarantees in a transaction system which are independent of the implementation objective with the condition that the time compilation checks. This concept is obtained by: using a virtual machine as an interpreter, including an impeller for the I / 0 devices in the virtual machine so that the application programs have a common interface with the I / 0 devices and therefore are portable through widely different environments, allocating and, allocating memory and including an indication of the amount of memory in the application program which means that the program will only function successfully or will not work in any way and will reduce the security management functions to a minimum which improves the speed of operation, and provides a safe way to import and export data inside and outside the programs and databases of the application.

Description

SAFE TRANSACTION PORTABLE SYSTEM FOR INTELLIGENT AND PROGRAMMABLE DEVICES DESCRIPTION OF THE INVENTION The present invention relates to a system that includes programmable, intelligent devices, such as terminals and integrated circuit cards as well as a method of operation of such cards and terminals that include automatic answering machines, personal computers, paid television units, terminals of point of sale, health cards or similar. It is particularly suitable for use in conducting financial transactions.

ANTECEDENTS OF THE TECHNIQUE Various types of terminals are known to carry out transactions, for example, financial transactions which involve the transfer or exchange of value, or transactions which are of a commercial nature such that transactions with health care cards or for data of general access, for example, the SIM card or a mobile phone, GSM. Terminals such as point-of-sale (POS) devices, automatic answering machines (ATM) or GSM mobile phones are known. Current products range from small, portable devices with simple 8-bit microprocessors such as the Intel 8031/8051 series, supplied by Intel Corp., USA or integrated circuit cards (ICC) for 32-bit computers running on systems operatives such as UNIXHR or Windows NT supplied by Microsoft Corp., USA. Some of these machines interact with a personal user card which can be a magnetic strip card, a smart card or ICC which stores the specific identification of the user and necessary validation information before the communication is initiated between the user and the user. the terminal . The user places the card in a card reader associated with the terminal, executes a terminal resident program in the terminal and examines the card, verifies the user's information regarding its validity, and if necessary, requests a keyword or number private such as a PIN (personal identification number). After validation, the program usually allows the user to select the desired services that will be carried out, for example cash withdrawal, account examination. The terminal can be self-sustaining or it can be connected to a larger computer, either locally or through a telecommunications network. Such terminals are often available 24 hours a day and must operate with minimal maintenance and a high level of security.

Such terminals represent a significant investment in physical elements and are usually not replaced at frequent intervals. The updating of the software and the programs that are carried out in such terminals becomes necessary as new services are offered and these must be carried out safely. Generally, the organizations that operate the terminals, such as banks, require that each update be certified. Each update may be manual or remotely through a private or public communications network as is known from U.S. Patent No. 5,434,999. Such known schemes require that the type and model of the terminal be known for new developments as the software for each terminal must be created specifically for this type of terminal and therefore is an expensive investment. In addition, in order to offer services from all possible organizations offering similar services, for example all banks or credit institutions, the terminal must be able to process all programs of all organizations. Due to the high mobility of both private and business people, it is advantageous that all the services which are offered in a country are available in each terminal. This would result in unnecessarily large processing capacity and memory size for each terminal. further, each of these programs must be updated as required. One solution would be to use a small workstation for each terminal possibly connected to a telecommunications system. Such a system would be capable of off-line processing and can switch to on-line processing of unusual transactions or to automatic updating of resident programs. The work stations would be required, for example, to carry out the complex validation and coding (encryption) schemes necessary to maintain security in an open system and resist attacks via public telephone networks. As the size and complexity increase, the problem of maintaining security also increases. Even with such a system, there may be problems with version control. Not all users of the services of the same organization can have cards suitable for the latest version of a service. This can happen when multinational organizations introduce or update services at different times in different countries. It has been proposed in WO 96/18979 to update the terminals only for the session involved from the user's personal ICC. The program instructions that represent your routines are stored on the card and can be exported to the terminal where they are interpreted. The use of an interpreter in the terminal allows the same card to be used with any terminal that contains the interpreter and therefore perform the independent transaction of the host processor in the terminal. However, no security control method is described to eliminate potentially dangerous subroutines. Terminals of the type described above also have a processor that includes some form of memory, usually some random access memory (RAM) for program development, some read-only memory (ROM) for storing data which should only be read, which includes a program for the operating system of the terminal and a non-volatile read / write memory for the storage of general data which may change. The personal data of the user must be kept private and therefore there is no possibility of access by a user to the data of another, either accidentally or intentionally by a person with bad intentions. In addition, the various writable memories of the terminal should not be defragmented over time. Memory defragmentation can result in continuous memory blocks that are small in size so that certain programs can not be carried out. To avoid this problem, some programming languages such as JavaMR make use of garbage collection. Garbage collection is a routine which attempts to identify data in the memory which is no longer required and disassociates it. It is the currently informed opinion that garbage collection is a more reliable way of managing memory than having a program that explicitly evicts your own stored data. Explicit memory allocation and deallocation is handled by some to be the single largest source of programming errors in common high-level programming languages such as C or C ++. Garbage collection has several disadvantages. First, garbage collection is an operating system function instead of a specific application. Therefore, garbage collection does not guarantee that the data of each application will be unassigned at the end of the application, but rather that such data may be present for a certain time until the lack of access activates garbage collection. A more secure method of eliminating the possibility of directing private user data is required in financial transactions. Second, it increases the size of the memory space required for the operating system. In the CCI and in some terminals, memory may be limited and the use of garbage collection can be a serious disadvantage. As explained above, terminals are replaced very infrequently so that a wide variety of terminals that include different capacities and processor memory sizes usually operate in the system concurrently. Older terminals are often severely limited in their capabilities. Although the older types can be replaced, the demand for more refined and complex services means that the older terminals will probably never be replaced so frequently that some of them do not fall behind in their capabilities. Therefore, it probably remains a necessity to require compact operating systems which can work on a wide variety of processor types. Finally, garbage collection does not release memory as soon as it would release it using an explicit deallocation. This can also increase the amount of memory needed because the memory is busy when it must be released. A secure method of memory management in process time is described in U.S. Patent No. 5,434,999. For example, in accordance with this known method, an interpreter in the terminal performs a systematic check of any instruction manipulation and a memory address in order to verify whether the region of memory to which access is requested is authorized. This system has the disadvantage that each instruction must be verified in this way which decreases the processing considerably. The verification in program process time is expensive in terms of operation. There is a need for a system that provides programmable terminals which allow the programmer of the general software to be portable and neutral through heterogeneous terminals, that is, independent of the processor used in the terminal, and does not need to be of the type tested for each type or product of terminal. The operating system resident in the terminal and the application programs are preferably compact, run quickly and satisfy security reguires. In addition, it is preferable if the application programs can be easily updated, at least where each user can obtain the services that are expected independent of the geographical position of the terminal. An object of the present invention is to provide a secure transaction management system for transactions and a method for operating such a system. A further objective of the present invention is to provide secure terminals and ICC for transactions and methods of operation of such devices. A further objective of the invention is to provide a device usable in a transaction which can be implemented in portable devices such as an ICC. A further objective of the present invention is to provide a transaction system in which terminals or CCIs can be updated using terminals or CCI as sources of update information. A further objective of the present invention is to provide a transaction management system and method for operating the system which provides high security with good operating speed.

BRIEF DESCRIPTION OF THE INVENTION The present invention relates to a transaction management system for executing transactions between a first device and a second device, the first and second devices are adapted for communication with each other and at least one of the first and second devices is a circuit card integrated, the system comprises: at least one input / output device; a portable virtual machine to interpret a computer program on the first device, the virtual machine comprises a virtual microprocessor and an impeller for at least one input / output device; and a means of execution that responds to the interpreted program to execute the program. It is preferred that the portable virtual machine be a stacking machine and that it perform the operation with speed and in a compact manner. The present invention also provides a terminal comprising a first device for carrying out a transaction with a second device, at least one of the first and second devices is an integrated circuit card, which comprises: a portable virtual machine that interprets a program of a computer on the first device, the portable virtual machine comprises a virtual microprocessor and an impeller for at least one input / output device and a means of execution that responds to the program interpreted to execute the program. The present invention also provides a portable, self-contained smart card, including a first device for carrying out a transaction with a second device, the smart card comprising: a portable virtual machine comprising a virtual microprocessor and an impeller for at least one device of entry / exit. The present invention also provides a transaction management system comprising: a first device and a second device, the first and second devices are adapted for communication with each other, at least one of the first and second devices is an integrated circuit card; the second device includes a means for providing at least one program instruction capable of modifying at least the runtime behavior of a computer program in the first device; the first device includes a virtual machine, the virtual machine comprises a means for loading and interpreting the computer program, the means for loading and interpreting is further adapted to load and interpret at least one program instruction dependent on a predefined security condition after the medium for loading and interpreting has loaded the computer program and while the computer program is being developed; and an execution means for executing the loaded and interpreted computer program with the modified behavior in response to the program instruction loaded and interpreted. In addition, the present invention provides a terminal comprising a first device for carrying out a transaction with a second device and at least one of the first and second devices is an integrated circuit card, the second device includes a means for providing minus a program instruction capable of modifying at least the runtime behavior of a computer program on the first device, the terminal comprises: a first device that includes a virtual machine, the virtual wizard comprises a means for loading and interpreting the computer program, the means for loading and interpreting is further adapted to load and interpret at least one program instruction dependent on a predefined security condition after the means for loading and interpreting has loaded such computer program and while is developing the computer program; and a means of execution to execute the loaded and interpreted computer program with the modified behavior, in response to the program instruction loaded and interpreted. The present invention provides a portable, self-contained smart card, which includes a first device for carrying out a transaction with a second device, the second device includes a means for providing at least one program instruction capable of modifying at least the behavior of the type of execution of a computer program on the first device, the smart card comprises; a first device that includes a virtual machine, the virtual machine comprises a means for loading and interpreting the computer program, the means for loading and interpreting is further adapted to load and interpret at least one program instruction dependent on a security condition predefined after the medium for loading and interpreting has loaded the computer program and while the computer program is carried out; and an execution means for loading the loaded and interpreted computer program with the modified behavior in response to the program instruction loaded and interpreted. The present invention also provides a transaction system for executing transactions between a first device and a second device, the system comprising: a virtual machine for interpreting a set of adapted octet code symbols, applied to it; the virtual machine includes a virtual processing unit and a read / write logical address space; At least one first application program which includes an indication of the amount of read / write logical address space necessary for its execution, at least one first application program is written as a stream of symbols selected from the set of symbols and corresponding online data; The virtual machine also includes: a loader to load at least a first application program; and a means for allocating a first amount of read / write logical address space specifically for at least one first application program according to the indication, the assigned read / write logical address space has defined and protected limits. The first device according to the present invention may be a personal computer connected to the internet and which operates an examiner, the reguence that each module received by the examiner must contain an indication of his memory regiments, improves security the examiner and limits the damage that can be done by any virus contained in the imported module. The present invention provides a terminal comprising a first device for executing transactions with a second device, the first device comprising: a virtual device for interpreting a set of adapted octet code symbols, applied to it; a virtual machine that includes a virtual processing unit and a read / writable logical address space; at least a first application program which includes an indication of the amount of read / write logical address space necessary for its execution and a first exclusive list of at least one function which can be imported into other application programs, at least the first application program is written as a stream of symbols which are selected from the set of symbols and which correspond to data in line; The virtual machine also includes: a loader to load at least a first application program; and means for allocating a first amount of read / write logical address space for at least the first application program according to the indication, the assigned read / write logical address space has defined and protected limits. The present invention can also provide a self-contained portable smart card that includes a first device for performing a transaction with a second device, the first device comprising: a virtual machine for interpreting a set of adapted byte code symbols, applied to it; the virtual machine includes a virtual processing unit and a read / writable logical address space; At least one first application program including an indication of the amount of read / write logical address space necessary for its execution, at least the first application program is written as a stream of symbols that are selected from a set of corresponding online symbols and data; the virtual machine also includes: a loader to load at least a first application program; and a means for allocating a first amount of read / write logical address space specifically for at least one first application program according to the indication, the assigned read / write logical address space has defined and protected limits. The present invention also provides a transaction system for executing transactions between a first device and a second device, at least the first and second devices are an integrated circuit card, the system comprises: a virtual machine for interpreting a set of symbols of code of adapted octets; the virtual machine includes a virtual processing unit and a read / writable logical address space; At least one database that includes at least one record and at least one computer program for execution by the virtual machine, the computer program is a module written in terms of a stream of symbols that are selected from the set and which includes an indication of the amount of read / write logical address space not initialized necessary for module execution; a charger for charging the module and for allocating the required amount of logical address / uninitialized space, in accordance with such indication; and a means to access the record in the database, the records in the database are only accessible through the module, and the means of access provides a window on a current record of the database and copies the record in a portion of the uninitialized read / write logical address space addressable by the application program. In addition, the present invention also provides a terminal comprising a first device for executing transactions with a second device, at least one of the first and second devices in an integrated circuit card, the first device comprising: a virtual machine for interpreting a set of octet code symbols, adapted, applied to it; the virtual machine includes a virtual processing unit and a read / writable logical address space; at least one database that includes at least one registry and at least one computer program for execution by the virtual machine, the program of • computer is a module written in terms of a stream of symbols that are selected together and that include an indication of the amount of read / write logical address space uninitialized for module execution; a charger for charging the module and for assigning the required amount of logical address / uninitialized space according to the indication; and a means to access a database record, records in the database are only accessible through the module, and the means of access provides a window on the current record of the database and copies the record in a portion of the read / writable logical address space not initialized addressable by the application program. The present invention can provide a portable, self-contained smart card, which includes a first device for carrying out a transaction with a second device, the first device comprising: a virtual machine for interpreting a set of adapted octet code symbols, applied to the same; the virtual machine includes a virtual processing unit and a read / writable logical address space; At least one database that includes at least one record and at least one computer program for execution by the virtual machine, the computer program is a module written in terms of a stream of symbols that are selected from the set and which include an indication of the amount of read / write logical address space not initialized necessary for module execution; a charger for charging the module and for assigning the requested amount of logical address / uninitialized space according to the indication; and a means to access a record in the database, the records in the database are only accessible through the module, the means of access provides a window on a current record of the database and copies the record in a portion of the uninitialized read / write logical address addressable by the application program. The present invention also provides a method for carrying out a transaction between a first device and a second device, at least one of the first and second devices is an integrated circuit card; which comprise: providing at least one program instruction on the second device capable of modifying at least the runtime behavior of a computer program on the first device; load and interpret the computer program, load and interpret at least one program instruction dependent on the predefined security condition while the computer program is being carried out; and execute the loaded and interpreted computer program with the modified behavior in response to the program instruction loaded and interpreted. The present invention also provides a method for carrying out a transaction between a first device and a second device, comprising: interpreting at least one written application program as a stream of octet code symbols which are selected from a set of symbols and gue correspond to data online; load at least one application program; assign a first number of read / write logical address spaces specifically for at least one application program according to an indication contained within the application program of the read / write logical address amount necessary for its execution and define and protect the boundaries of the assigned read / writable logical address space. This method combines the use of an interpreter with optional explicit assignment and de-allocation of memory. This provides a mixture of flexibility and portable capacity and at the same time provides guarantees of process time after the application program has been carefully verified in its compilation stage. Damage is reduced which can be caused by viruses in imported application modules. The present invention also includes a method for carrying out a transaction system between a first device and a second device, at least one of the first and second devices is an integrated circuit card, which comprises: interpreting the symbols in a module written in terms of a stream of the symbols that are selected from a set of symbols; allocate a logical address / uninitialized space quantity according to an indication in the module of the amount of read / write logical address space not initialized necessary for module execution; access a record in a database by providing a database on a current record of the database, records in a database are only accessible through the module; and copying the record into a portion of the uninitialized read / writable logical address space, addressable by the module. The present invention also includes a method for carrying out a transaction between a first device and a second device, at least one of the first and second devices is an integrated circuit card, comprising: providing a portable virtual device comprising a virtual microprocessor and an impeller for at least one input / output device; interpret a computer program about the first device using the portable virtual machine; and execute the program in response to the interpreted program. In accordance with the present invention, a • secure transaction management system which preferably includes a portable virtual microprocessor. Preferably, each module has a set of virtual address spaces that are guaranteed to be different from each other in any other virtual address space. In addition, the portable virtual microprocessor preferably protects access to shared resources such as the various stacks or databases. Preferably, the minimum protection is memory verification of the data space access limits for readings and writes and absolute prohibition of writes to the code space. In addition, verification is preferred for data overflow and overflow and return stacks. Preferably, the module can only access aguello that another module explicitly exports. Preferably, there is no way that non-exported data can be accessed (the virtual microprocessor does not leak) except through functions provided by a module. The modules preferably can not export data in the usual sense; preferably, modules can only export functions. Preferably, logical limits prohibit the leakage of data space. In other words, all data held by a module is preferably strictly private. This restriction is preferably reinforced both in the compile time and in the process time, since the modules have separate address spaces, which means that the address of some data within a module is completely meaningless outside its own module. Preferably, a module can export a scroll group set to activate or deactivate a particular behavior. Preferably, the modules of good behavior will run without defects, while the modules that do not behave will also be contributed by exceptions extracted directly by the portable virtual microprocessor when illegal operations are attempted.

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

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a schematic representation of a terminal according to the present invention. 'Figure 2 is a schematic representation of a ICC according to the present invention. Figure 3 is a schematic flow diagram of the process of developing and executing a module according to the present invention. Figure 4 is a schematic representation of a portable vertical microprocessor in accordance with the present invention as implemented in a terminal. Figure 5 is a schematic representation of the portable vertical microprocessor according to the present invention. Figure 6 is a schematic representation of modules loaded in a memory according to the present invention.

Figure 7 is a schematic representation of the method for obtaining access to a database record according to the present invention. Figure 8 is a schematic representation of the plug and plug method (improvement and process) according to the present invention. Figure 9 is a flow chart of the module loading method of the present invention. Figure 10 is a flowchart of the method of executing the module of the present invention. Figure 11 is a flow diagram of the receptacle method in the plug of the present invention. Figure 12 is a flow diagram of a card module charging method according to the present invention. The appendix provides the symbol codes and standard exceptions.

DESCRIPTION OF THE ILLUSTRATIVE MODALITIES The present invention will be described in the following with reference to particular drawings and certain modalities, but the invention is not limited to these but only by the claims. The drawings are only schematic and are not limiting. The present invention will be described with reference to financial transactions, but the invention is not limited thereto. In addition, the present invention will be described primarily with reference to a terminal, but the present invention also includes providing the portable virtual microprocessor in accordance with the present invention in any suitable device, for example, a personal computer (PC), an ICC or a Combined ICC and interface, as described in WO94 / 10657, which is incorporated herein by reference. The general link technical concept behind the present invention is the portable capability combined with the data security and process time guarantee in a transaction system which is independent of the objective implementation with the condition that they are successfully passed. the compile time checks. This concept is obtained by one or more of the following characteristics: use a virtual machine as an interpreter, include an impeller for the 1/0 devices in the virtual machine so that the application programs have a common interface with I / O devices and therefore be portable through widely differing environments, which include an indication of the amount of memory in the application program and allocate memory according to the indication, explicitly allocate memory and provide a secure way to import and export data inside and outside application programs and / or databases. Figure 1 is a schematic representation of a terminal 1 according to the present invention. Terminal 1 typically includes a central processing unit (CPU) 2 which is connected to a memory 4 and input / output devices 6 (1/0) via common link 3 for two-way communication. The 1/0 devices can be a keyboard for entering data and a screen such as a visual display unit, for example, a liquid crystal display (LCD) or a light emitting diode (LED), to show the progress of the transaction and / or to write messages or requests. One of the I / O devices 6 can be a card reader 7 with which an ICC 5 can be read when it is inserted into the receiving slot in the reader 7. The actual shape of the terminal can vary greatly, i.e. it can be a point-of-sale (POS) terminal and can include processors from an Intel 8051 to a PentiumHR. Furthermore, it is not necessary that the terminal 1 be completely located in one position, the various parts of the terminal such as the card reader 7, the I / O devices such as the keyboard and the screen and the processor can be located in different positions and connected by cables, wireless transmission or similar, or be part of a local area network or interconnected by telecommunications networks.

Figure 2 is a schematic representation of an ICC 5 according to the present invention. However, the present invention is not limited to this. The ICC 5 includes at least one input / output port 10 (1/0) and certain permanent storage, for example, a non-volatile memory which can be provided, for example, by an EEPROM 15 connected to port 10 of I / O via a common link 17 or a random access memory stacked in matter (RAM). Port 10 of I / O can be used for communication with terminal 1 via a card reader 7. An integrated circuit card is a card in which one or more integrated circuits are inserted - to perform at least memory functions. Optionally, ICC 5 can be a self-contained portable smart card and include a read / writable working memory, for For example, a volatile memory provided by a RAM 14 and a central processor 12, as well as all the necessary circuits so that the ICC card 5 can operate as a microprocessor, for example, a read-only memory 13 for storing codes, a sequencer 16 and connections with reader 7 of card for receiving the voltage sources Vss and VDD, a reset for the processor 12 and a clock CLK for the sequencer 16. In accordance with the present invention, the ICC can be used as a bank card, credit card, card debit, electronic purchases, greeting card, SIM card or similar.

The present invention provides an integrated circuit controlled transaction management system designed to run between an ICC 5 and a terminal 1 connected or not connected to a central unit, a transaction consisting of at least one execution of the following sequence: 1. create a communication link between ICC 5 and terminal 1; 2. perform a compatibility check to ensure that ICC 5 and terminal 1 are mechanically and electrically compatible; 3. selection of an application that includes selection of a computer program and the associated data set that define the transaction in terms of the combination of the specific CCI 5 and the terminal 1 involved; 4. execution of the application; 5. termination of the transaction, which optionally includes interrupting the communication link between ICC 5 and terminal 1; therefore, an interpreter is used to execute the application, either in the ICC 5 or in the terminal, or in both. The transaction is an exchange of at least data between two or more devices, and, in accordance with the present invention, is not specific to a commercial financial transaction. Such a system is known from document PCT / BE 95/00017. ICC 5 can be only ICC memory, ie not include a processor 12, and ICC 5 undergoes the transaction determined by terminal 1. Alternatively, ICC 5 can be a self-contained portable smart card and a transaction can be determined by Terminal 1, by ICC 5 or both. In accordance with the present invention, ICC 5 may include a program code to securely allow processing by the terminal. In particular, the ICC 5 can be one or more maintenance cards which can be used to update the applications stored in the terminal 5. According to the present invention, a software is developed in the terminal 1 and optionally in the ICC 5 in terms of a "virtual machine". The virtual machine (VM) according to the present invention makes explicitly available a theoretical or virtual microprocessor with standard features that define mode of addressing, use of stacking, use of register, address space, addressing of the 1/0 devices, etc., in a generic way. The core of each particular CPU type used in a terminal 1 or ICC 5 is written to make the processor 2, 12 respectively, emulate the VM. It is a specific aspect of the present invention the core of the VM provide impellers for 1/0 devices and low-level logic and arithmetic functions of CPU, flow control and time management. The fact of providing 1/0 impellers in the VM has the advantage any program written for the VM according to the present invention addresses standard virtual 1/0 devices. The implementation of the VM in a particular CPU then provides the physical 1/0 devices connected to the terminal or ICC 5 to behave similarly to the addressed virtual 1/0 devices. The VM according to the present invention is very compact and has been implemented successfully on a Siemens SLC044CR chip (derived from the INTEL 8051 family) which can be included in an ICC 5. The VM according to the present invention performs a high degree of standardization possible through widely varying types of CPU and I / O, and simplifies the portable capacity of the program, testing and certification. According to the present application, such VM will be described as a portable virtual machine. The portable VM 20 includes a virtual microprocessor and an impeller for a 1/0 device. The VM 20 provides logic and arithmetic functions and memory addressing and at least one input / output device. The portable VM 20 according to the present invention provides portable program capability through heterogeneous terminals 1 and the card 5 by treating card programs to the terminal I / O as an intermediate code of a compiler. This code consists of streams of octet codes, called symbols. Terminals 1 or ICC 5 then process this code when interpreted by another means such as a compilation of native code. The interpretation of the virtual machine of the symbols can preferably be carried out by one of three methods. By directly interpreting the instructions of the virtual machine, by translating the language of the virtual machine into an intermediate form directly executable, or by compiling it, just in time, to a real code for the target CPU. These last two methods offer improved performance at a moderate cost in terms of complexity. The symbols are provided in a set which can be searched as a set of machine instructions for the VM 20. The application programs according to the present invention are constituted as modules which can include a list of symbols as executable code. According to the present invention, there are two basic types of modules: executable modules, which have an entry point is requested directly by the VM 20 when the module is loaded, and library modules, which act as resources for others modules by providing exportable procedures can be executed individually by intermodule calls. The set of symbols according to the present invention includes, first, the adjustment instruction of the VM 20, which provides the expected instructions for a general processing language and are required for efficient program execution, and secondly place, symbols which provide what are usually called "operating system functions". In terminals 1, or card 5, operating system functions include, in accordance with the present invention, specific functions such as 1/0 impellers, for example, for displays and keyboards, and in terminals 1 and card 5, the system also works to include the handling of communication and transmission data objects through the 1/0 ports and also access • intermodule and access control mechanisms. The symbols are preferably provided for the VM's operating system, for stacking manipulations, for receptacle handling, for control, for example, exception handling, for the same receptacles that include their access rights, for accesses of 1/0 devices, for time management, for language and message handling, for managing readers of I / O, for example, the ICC, the magnetic strip card and the modem management, for managing a blacklist, for algorithms of • security, for terminal services, for database services, for handling data objects, for example, management of TLV, for handling modules and for extensible memory management. The symbols of a single octet are referred to as primary symbols; this refers to primitive instructions such as those commonly found in any set of instructions. Multiple octet symbols are referred to as secondary octets and are used for less frequently used services. The complete set of symbols for VM -20 is provided in the appendix. As shown schematically in Figure 3, the application program is written to a PC guest development system 70 and is debugged and approved in an appropriate high level language such as Forth, C, Pascal, etc. Then the source code of the program is compiled into a symbol compiler 71 in a stream of symbols. This stream of symbols is combined separately with other data (the corresponding online data) needed by the program and a header, and is encapsulated in a module supply file to create a module 72, preferably in a standardized module delivery format . If the module contains executable symbols, it is supplied in the executable program format. It is a particular aspect of the present invention that the executable modules contain not only the symbol stream but also all the corresponding online data (encapsulation). A further particular and separate aspect of the present invention is one in which the modules according to the present invention contain an indication of how much writable / read memory will be allocated by the VM 20 to execute the module. The module 72 is supplied to the terminal 1 by any suitable means, for example, in an ICC 5, via a telecommunications network. After the module is downloaded, it is stored in a "warehouse module". When this function is regulated, the terminal 1 or the card 5 uses a symbol loader / interpreter 73 to process the symbols for execution in the CPU 2 of the terminal. This process consists of executing the function associated with each symbol. The symbol loader / interpreter 72 is provided by the VM 20 in accordance with the present invention. . The VM-related software in a terminal 1 can be divided into four main categories: • The core, which includes the terminal-dependent implementations of the 1/0 impellers and all the functions required in this specification to support the VM 20. All other software related to the VM 20 is written in symbols independent of the machine. • Terminal resident services (TRS) are at least one module which operates on VM 20 as a handler and applications, and includes all non-application functions, libraries that support these functions, module loading functions and the main circuit that defines the behavior of the terminals. Special symbols (for example (DIOCTL) allow terminal-dependent aspects of 1/0 devices to be defined as on-line functions • Selected terminal services (TSS) include applications such as payment service functions and libraries that support these functions, TSS contains only • terminal-independent symbols that are resident in terminal 1. The main program circuit TRS will select and request TSS functions as needed for a particular transaction. • Selected card services (CSS) includes features that support terminal transactions, such as payment service functions that are used as part of a TSS application. The CSS is resident in an ICC 5 and is downloaded to terminal 1 as requested. For terminals 1 with two ICC readers 8 (for example, one for normal transactions and one for maintenance), there can be two independent sets of CSS (CSS1 and CSS2). All the software in a terminal l according to the present invention, above the core, is organized as a set of separate modules. The fundamental characteristic of a module is that it is a collection of definitions or program functions that have passed through a compiler 71 of symbols that have been encapsulated in a single package for delivery to a target environment, for example, a terminal 1 in an ICC 5. The Main Terminal Program (TRS), each application, each library and each CSS downloaded are examples of modules. Preferably, all modules use a standard format. The core in a system according to the present invention defines the VM 20 which provides a variety of high level services for these modules, such as: • General purpose CPU and set of instructions, represented by symbols; • general-purpose I / O support for common devices, with provisions for generic 1/0 for .upport additional devices that can be added; • database management functions; • handling of transmission of data objects, including format conversions and other functions; • management of symbol modules, which include maintaining them in storage (updating, if necessary) and executing them as requested. In a preferred embodiment of the present invention, the execution of the modules remains in control of the VM 20 at all times. For the • Therefore, the modules never take control of the host processor but are only passive with respect to the VM 20.

Preferably, the VM 20 always operates in supervisor mode and can only execute instructions defined in terms of its set of symbols and there are no modules that can operate in user mode, that is, assume control of the VM 20. therefore, in an implementation of the VM 20 that uses a memory map, only a single memory map is generated, specifically the supervisor map. No module can compromise the operating system defined by VM 20. This is guaranteed because a module can only contain symbols from the set of VM symbols and none of these symbols allow access to the code space when the kernel is stored. . If a symbol is found by VM 20 which is outside the defined set, an exception is requested (ILLOP). As shown schematically in Figure 4, terminal 1 includes a terminal-specific operating system 8 responsive for loading the TRS module of the VM 20 (the loading procedure is described below). The code for the VM 20 is stored in a volatile read-only terminal memory. Before loading the TRS, the terminal volatile memory 19 of terminal 1 is emptied of all transaction related data, the nonvolatile read / write memory 18 contains the applications to be executed by the VM 20 in form of modules 72 in a module store, non-volatile databases containing user-specific data and libraries such as the receptacle library which will be described later. If the VM 20 is also implemented on an ICC 5, the same principles as described above apply with respect to the non-volatile read-only memory 13, the volatile memory 14 and the non-volatile read / write memory of the ICC. 5. Since VM 20 is a virtual machine, it addresses all forms of the memory of the terminal or CCI 11, 18, 19; 13, 14, 15 as virtual memory, that is, they are addressed in a logical address space as seen from VM 20. In a current implementation of VM 20, these logical address spaces are mapped into address spaces current in the memory of terminal 1 or ICC 5 by a memory map or the like. In the following, reference will be made to the volatile, non-volatile read / write and nonvolatile, read-only memory as constituting parts of the VM 20. It should be understood that this refers to logically addressed memory spaces unless it is made specific mention to real addresses in a VM 20 implementation over a terminal 1 or ICC 5. Volatile memory does not survive program loading or power removal and / or restart. Preferably, volatile memory does not survive inactivation for security reasons.

Non-volatile memory survives program loading or inactivation and reactivation.

Description of the virtual machine In Figure 5 a schematic representation of the VM 20 according to the present invention is shown.

Preferably, the VM 20 is a stacking machine and has • a data stacking pointer (stored in the data stacking pointer register 32) pointing to a stacked data stack 27, preferably in a memory on a chip. All operations are performed in this stack 27. The data stack 27 is used to contain procedural parameters and temporal results of expression evaluation. The data is driven or extracted from the data stack 27. The VM 20 also includes a return stack 28. The return stack 28 can be used by the VM 20 to contain return addresses, and can also be used for temporary storage. This multiple stacking architecture knows from the Forth programming language (ANSI X3.215-1994). This arguitectura has been modified additionally for portable capacity, density of codes, security, ease of compilation and for use with other programming languages. For example, it contains provisions for local variable information units used in high-level programming languages, such as C. Therefore, the compilers 71 of symbols according to the present invention can be written not only for Forth but also for C and other programming languages. In accordance with the present invention, there is only one data and return stack 27 associated with the VM 20. The data and return stacks 27, 28 are not created for each processing sequence. In accordance with the present invention, the application programs can only be recovered from the return stack 28 when they have been explicitly placed within the current procedure, and they must remove data placed in the return stack 28 during the current procedure before leaving the stack. process. Optionally, the VM 20 includes a security handler to provide integrity in the process time and which monitors each activity in the return stack and verifies that all the data has been removed during the current procedure. In addition to the data placed there explicitly for temporary storage, the VM 20 may retain exception execution status information, information units for local variables, circuit control parameters and database context in the return stack 28. According to the present invention, the VM 20 may include a plurality of stacks. For example, instead of using only the return stack 28, optionally additional stacks 29 may be provided such as exception stacks and information unit stacks. An exception stack is used to store the state of execution during exception processing. An information unit stack is used to maintain the information of local variables, as well as activation records similar to the C language. As mentioned above, the exception and information unit stacks 28 can be implemented in the return stack 28 . The data, stacks 27, 28, return and other stacks 29 such as exception stacking are not in the memory space directly accessible by any application program. The data or return stacks 21, 28 can not be directly addressed, they are only accessible via stacking operations. For security reasons, there is no limitation on how data is stored in a real implementation, so that people with bad intentions can not make assumptions about how the data is physically stored. The VM 20 includes a virtual central processing unit 22 which includes a virtual arithmetic logic unit 23. The VM 20 selects a virtual or logical data space 24 and which are treated by the VM 20 as random access memory (RAM) and would normally be implemented as parts of the volatile memory 19, for example, in the RAM in a terminal 1 real or the card 5. The logical data space 24 is accessible only for data storage. The symbol stream of a module is stored in the VM 20 in the code memory 26 which is treated as read-only memory (ROM) by the VM 20. Only the VM 20 can read the symbols. The code memory 26 is not accessible for application programs or for any symbol. The VM 20 may include virtual registers. The registers 30 of the VM 20 may include the symbol pointer register 31 which keeps the pointer which points to the next symbol to be executed, the data stacking pointer register 32, which retains the pointer which points to the current upper portion of the data stacking position 27 (TOS), a return stacking pointer register 33 which maintains the pointer which points to the top of the return stacking position, a frame pointer register 34 which maintains the pointer which points to the frame start in the data space 24, a frame end pointer record 35 which retains the pointer which points to the frame end in the 24 data space. Direct access to registers 31 to 36 is not provided by the set symbol but only via the registration access symbols. Finally, the virtual 1/0 devices 25 are linked to the CPU 22 by a virtual common link system 21, which also links the stacks 27-29, ALU 23, the registers 30, the code memory 26 and the space 24 of data. The VM 20 according to the present invention is preferably defined as a 32-bit magic of two add-ons, .directed by octets, with 32 bit registers and stacking elements however, the invention is not limited thereto. The record / stacking size is referred to as the cell size of the VM 20, since the cell is the basic unit of manipulation in the stacks and by registers 31 to 36 of the VM. The size of the cell used by VM 20 is not considered to have a material effect on the present invention. All the programs carried out from the modules must comply with the following rules: • The programs can not assume that the data in any of the previous categories is guaranteed to be handled in the return stack, and thus can only be use the recovery mechanism specified explicitly for a given category because the security manager can suppress such data. • Programs that pass data in one of these categories to the VM 20 must take appropriate action to recover the VM 20 data storage before exiting the procedure in which the VM 20 is otherwise passed on to deallocate the part. of relevant memory. • Programs must assume that any data previously placed in return stack 28 becomes inaccessible when passing data in one of these categories to VM 20. • Programs must assume that any data in one of these categories is passed to the VM. 20 becomes inaccessible when executing a code that places values in the return stack 28, until the time these values are removed because the return stack is only accessible by the specified symbol procedures. In accordance with the present invention, the operation system of the VM 20 defines a single address space 24 available to each module. This address space 24 may be accessible only for data storage, and shall be referred to as "data space" 24. The data space 24 is divided into three logical and optional regions, each of which is individually contiguous: 1. 41 space of initialized data, which contains initial values specified in the compilation time and establishes the moment in which the VM core is activated and then the moment in which a module that contains initialized data is downloaded; 2. initialized data space 42, which contains variables and static buffers allocated during the compilation of the program. This data space 42 is initialized to zero by the VM 20; 3. information unit memory 46, which is handled by the information unit symbols; 4. optionally: extendable memory 45 which contains one or more intermediate memories assigned dynamically during the execution of the program. There are two additional data regions, which are not directly addressable: 5. extended memory 43 which typically stores in bulk what is used to hold data objects and volatile databases; 6. non-volatile memory 44 that is used to hold data that is guaranteed by the VM 20 to survive the loading of the module or power loss or restart, (within the limitations of the terminal hardware) that includes the module store and the bases of non-volatile data. This can be implemented in a RAM with battery support, a disk or other persistent storage. The non-volatile memory 44 can be implemented as part of the permanent read / write storage 18. To increase the security of the data, the memory 43, 44 extended and non-volatile is accessed only through symbols that provide "windows" to the selected data in the form of buffers in uninitialized data space 42. Therefore, a programmer can only request a registration and can not know the exact position of the data in order to have access to them. Preferably, there is no file or tree structure which allows a programmer to assign files or personal databases. Within each data space 24 used by a module, the memory is allocated by relative addressing and only in the process time. This means that an address only has meaning within each module when it is loaded. Absolute addressing is not used, it is not possible for a module to have access to data from another module except for the secure module access mechanisms described below. The information unit mechanism allows VM 20 to satisfy the language requirements such as C that allow local variables to be defined at the time of the process. An information unit retains process parameters that pass in the data stack 27 as well as "local" variables (temporary data storage that will be released automatically when the information unit is released, usually at the end of the execution procedure). The start pointers of the information unit end are automatically maintained by the VM 20 within the information unit.

The information unit pointer register 34 points to the logical basis of the information unit and the pointer 35 of the information unit end points to the logical end of the information unit in the data space 24. The parameters can be extracted from the information unit using the information unit access symbols. Optionally the VM 20 can provide a dynamically assigned concentrate of extendable memory 45 as a single extendable buffer handled by the VM 20 which appears outside the uninitialized program data space 42. The programs may request an allocation of a specified amount of extendable memory 45 and are returned to a pointer to a base address for that memory 45.

Subsequently, the programs can release memory 45 from a given address, for example, at the end of the program, causing all assignments beyond the address to be released. It is preferred if the modules are executed in a single sequence, but the invention is not limited thereto. This means that if a module requests a second module, the second module ends and all the resources of the second module are deallocated before the VM 20 returns to the first module and the processing continues. Figure 6 shows a schematic representation of the logical memory as seen by the VM 20. As shown schematically in Figure 6, a first module (on the left) with initialized memory 41, uninitialized memory 42 and unit memory 46 of information and symbol code space 26 has been loaded into the read / write memory starting at address 1. The first module has also been called and an extendable buffer portion 45 has been allocated. When the second module (on the right) is requested by the first module (for example, to impart the function fgh which is an exclusive list in the header of module 1 of the functions which can be imported), the space data 24 'which include the memory 41' initialized, the memory 42 'not initialized and the information unit memory 46 'are assigned as required starting at address 2. The symbols of module 2 are read directly by the VM 20 from the module store which is an allowed option according to the present invention. If called from module 2, the extendable memory 45 'for the second module is allocated by the upper VM 20 in the memory compared to the extendable memory 45 for the first module. When the second module is completed, all memory is unassigned above address 4 ("rubber band effect"). Preferably, all temporarily stored data is deleted when unassigning. If necessary, then more extendable memory 45 can be requested upon return to the first module. If the second module is requested again, a different start address will be assigned for the extendable memory 45 'compared to the one requested the first time. All symbols, except extendable memory handling symbols? XT? ND, CEXTEND and RELAY, and the exception handling symbols THROW and QTHROW are required to have no effect on the extendable memory pointer. If a symbol allocates extensible memory, you must also release it, including any cell alignment effects. The successive allocations of extendable memory preferably are contiguous within a module but do not need to be contiguous between modules, except that the intermodule requests use IMCALL or DOSOCK? T symbols to retain contiguity. A dynamically allocated automatic release of extensible memory 45 will be presented when the execution of the module is completed, limiting the effects of program failure to free memory cleanly. In addition, if a THROW exception occurs, the extendable memory allocation assigned dynamically to its condition at the time the CATCH exception is governed can be reset. The user variables are cell size variables in which the VM 20 retains contextual information for the client programs. The storage for the user variables is pre-assigned by the VM 20. A limited number of variables can be provided, for example sixteen variables (referred to as 0 to 15). An implementation of the VM 20 that supports multiple tasks can provide a set of user variables for each task. The VM 20 provides a unique exception handling mechanism via the symbols CATCH, THROW and QTHROW. These symbols are derived from the Lisp exception handling mechanism, and appear in ANS Forth as CATCH and THROW. The purpose of this mechanism is to provide local handling of exceptions under program control at various levels in the software. The concept is that the program passes to a function execution pointer to the CATCH symbol, which will execute this function and return a code indicating if, in any case, the exception occurred during its execution. The implementation-dependent information of the CATCH records sufficient to restore its current execution status if THROW is presented in the function passes to CATCH for execution. This includes (but is not limited to) depths of data stacking and return, the information unit pointer and, in some cases, the extendable memory pointer. The collection of information represents a state of execution and is referred to as the "exception information unit". The exception information units are kept in the exception stack. After a CATCH the program can examine any exception code that has been returned, and choose to handle it locally or THROW to a higher level for processing. The VM 20 provides the outermost level by default in which exceptions will be caught. This outermost level is activated when an internal level of CATCH has not been established. The default exception handler aborts any current terminal transection and attempts to reload the TRS modules and reintroduce the main TRS circuit. The VM 20 extracts ANS Forth exception-10 (Division between zero) that whenever this condition can occur. The VM 20 can extract other general exceptions supported by ANS Forth, for example, those provided in. the appendix attached. For input / output service management devices (1/0) each device, which includes those devices whose lower level of operation is hidden by the VM 20 of device-specific transactions, is assigned a type of device (used to categorize the result codes) and a unique device number. The numbers of devices are arbitrary, however, references can be made to device numbers -1 to 15 (4 bits) with only a single symbol, and in this way these are assigned to the most common devices, such as keyboards, ICC readers, card readers with magnetic tape, screens, printers, energy management devices or vending machines. General 1/0 installations are provided by functions that take the device number as an input parameter. A terminal 1 according to the present invention preferably contains at least three main non-volatile databases: a specific transaction record for the application, a message database in one or more languages and a module database. The VM 20 protects the databases as much as possible because they contain private information. Access to databases is restricted. The VM 20 provides a mechanism for handling databases (the VM 20 as a "server") that hides implementation details of the application software (application as the "client"). Direct access to the database is not allowed from a module operating in the VM 20. The service implements the following characteristics which will be described with reference to figure 7. • At any given time the client, ie a program that is developed in a module, has access to a currently selected database (DBCURRENT) and a currently selected record number (DBRECNUM) that is shared through all the defined databases. • The information about each database is transferred between the client and the server through a database parameter block (DPB) 51, to which the server can access to read and write. The client "owns" the DPB 51, in the sense that it is in the client's data space 24; but the client is not allowed to have access to it directly. Instead, only the database service symbols can be used to access the data. The DPB 51 has a standard structure that includes fields for at least one DPB link, a database pointer, an indication of the type of database and the record size and the next available registration number. All the information to specify a database must be present in the DPB 51.

The client software can not perform any subsequent direct parts to the DPB 51 and must not make assumptions about the values handled directly on the DPB 51 after the module defining DPB 51 has been loaded for execution. The database parameter blocks 51 are passed to the symbol loader / interpreter in the form of a pointer (DPB link) to a linked list in the initialized data section of a module. This field must be preset to the address in the initialized data of the DPB text 51 in the list; or zero if DPB 51 is the last or the only DPB 51 in the list. For compiled databases that exist in the client's initialized data space, the DB pointer must be preset to the "origin" address of the initialized data. For databases whose storage is controlled by the server, the field must be preset to zero. The type of DB provides details of the database in coded form. There are at least three kinds of databases: "Volatile" databases whose content does not need to be conserved between module loads or through a lack of power supply from terminal 1 on which they reside. "Non-volatile" databases whose content must be preserved between module loads or through a power interruption if the module that defines a non-volatile database is replaced, the database is destroyed when the old module is downloaded. "Compiled databases" are constructed by the symbol compiler 71 in a contiguous area of data initialized as fixed length records. The records can not be added or deleted from a compiled database, and the database can not be initialized at the time of processing, otherwise a full read-write capability will be supported. The next available record number field should be set to one more than the last record number assigned in the database for compiled databases. For any other database this field is set to zero. • The address of a window in the current record (a registration buffer 53) is provided by the server to the client for each client database. For certain database operations, the client may pass the sequence addresses and key buffers to the server. For each database that has been known to the server by a client module, a buffer memory 53 is provided by the VM 20. This buffer 53 begins in an aligned direction. The contents of the registration buffer 53 associated with a particular database after a record selection remains available until the client selects another record from that database. Except for these logging buffers 53, compiled databases and parameters passing over the data stack 27 by the specific database functions, no other data space 54 is shared between the client and the server. Programs may not assume that records in a database are contiguous in memory. • A database is instantiated by the loading process for the module in which its DPB is defined. The volatile databases installed by application modules are automatically uninstalled and transparent by the server when the application is terminated by terminal resident services, when all the data storage allocated to the server related to those databases is released. • The server suppresses the non-volatile databases when the module that defines them has been replaced. If the module is loaded when it is replaced, for example, in the case of a TRS module, the server must delete the non-volatile databases of the module when the module is downloaded. The action taken by the VM 20 when a database is instantiated in the module load time, depends on the value of the DB type and DB pointer on the DPB 51, and whether the database is volatile or non-volatile. If the database is of the non-volatile type, the DPB address is used together with the identification of the module (module ID) to identify any previous data that belongs to the database. If there is previous data, the next available registration number is reset to its previous value. Otherwise, the server (VM 20) instantiates the new non-volatile storage space and sets the next available registration number to zero. In both cases, a buffer 53 is provided for the current record in the database. If the DB pointer is zero and the DB type is not a compiled type, then the server instantiates or makes available the storage required for the database, initializes the storage on all zeros, provides an intermetered memory 53 for the "current record" of the database and adjusts the next available registration number (DBAVAIL) to zero. If the DB pointer is not zero and the DB type is a compiled type, then the server adjusts the internal structures to make use of a customer data structure whose source address has passed in the DB pointer and adjusts the following registration number available (DBAVAIL) to the value that was passed in the next available registration number field of the DPB 51. The server maintains the records 55 of actual databases, the relationship between the address position and the record in a block 56 of database control and a record for which the database of a module currently has access in a context of the information block 57. The safe module handling method according to the present invention will now be described with reference to Figure 6. In Figure 6, a logical read / write memory area is shown. A memory area which can be accessed by the module on the left side (first module) has a dashed line. A memory area which can not be • Accessed by the first module has a limit of one continuous line. A memory area which can be accessed by more than one module is shown with a line with periods and dashes. The VM 20 protects the DB1 and DB2 databases and the database store and the modules in the module store so that they are not accessible by any module. After the first module is loaded, the data not initialized in the memory 42 can be accessed by the first module, but the VM 20 does not allow any area outside this module to be accessed directly by the module. The access to the registers, the stacking or the information unit memory 46 can only be done through the relevant symbols. The databases can only be accessed via the window procedure mentioned above. In particular, the first module can not access its own program memory 26 where the symbols are located nor can it access any other module. This is important for virus protection. According to the present invention, the memory is assigned to a first module is defined and protected. It is defined by memory allocation according to the indication of the amount of memory to be allocated contained within the module. It is protected because no other module can access the allocated space, and no other loading mechanism is provided for any program other than that for modules. Since the preferred method for processing modules is not a single sequence, any memory allocated in the extendable buffer is delocalized before any other module is activated. The unassigned memory is preferably erased. The list of expressive importance of the first module is in the header to which the first module can not access directly. The VM 20 reads the header and requests the second module which is mentioned in the import list (function fgh of the second module). The VM 20 loads the second module and allocates memory for the uninitialized data 42 ', the buffer memory 46' and the data 41 'initialized. The first module can not access any part of the second module and vice versa. In the second module header, the fgh function has been placed in the exclusive list of functions which can be exported. This makes the fgh function available to other modules. The VM 20 looks for the function fgh in the code memory space 26 'of the second module and executes the symbol sequence with the corresponding online data (represented by the TITTITT sequence). In this example, this piece of code requires access to a DB2 database. A database according to the present invention is "owned" by a module, that is, a database can only be accessed by the module which starts at the first loading of the module. The database access symbols read from the code space 26 'are executed by the VM 20 which allocates a buffer 53' in the uninitialized data space 42 'of the second loading module. The fgh function requires access to the third DB2 registry. The VM 20 then transfers the record referenced to the window 53 'in the second module from which it is exported to the uninitialized space 42 of the first module. Using the same database window procedure, the first module can also obtain a record of its own database DB1, which is transferred to the buffer 53 in the uninitialized data space 42. The first module can now operate based on the results of the two procedures. VM 20 preferably works with data objects by means of basic encoding rules or label, length, value (BER-TLV abbreviated to TLV for this request), as described in ISO / IEC 8825 (1990). The TLV data objects consist of two or three consecutive fields. An ethigueta field that specifies its class, type and number, a length field that specifies the size of the data, and if the length is not zero, a value field that contains the data. Because the responses of the ICC card are generally limited in size to say 255 octets or less, there is a maximum size of a TLV object according to the present invention. The label field is preferably one or two octets, the length field is preferably one or two octets, and therefore the maximum size of the value field is preferably 252 octets (a field of this length requires two octets of long, as explained later). The first octet of the tagr field is broken down into three fields. Bits 7 and 8 specify the class of the object. Bit 6 determines whether the value field contains "primitive" data or whether it is a "constructed" object consisting of other fields encoded by TLV. The built octets are also called templates. These can cause their value fields to be scattered for TLV sequences when they are found. Bits 1 to 5 specify the object number, or, if all these bits are set, indicate that they follow additional etteta octets. The additional ettect octets have their own 8-bit setting if another octet does not follow. All bits in up to two octets are used to determine the name of a strip. The length field consists of one to three consecutive octets, typically two. If bit 8 of the first octet of 0, then bits 1 to 7 indicate the size of the value field. If bit 8 of the first octet is 1, then bits 1 through 7 indicate the number of octets that follow. The following octets, if any, indicate the size of the value field and are presented with the most significant octet first. The value field may consist of "primitive" data or may be "constructed" with sequences encoded by additional TLVs. If the .bit 6 of the first octet is set in the ethiguet field, then the value field contains additional TLV sequences. The primitive octets can be encoded in several different formats: binary coded decimal quartets with leading zeros or back quartets with all the established bits, binary numbers or sequences of octets, character sequence or alpha / numeric or ASCII octets, or undefined formats. Each is handled differently as it is used. An ICC 5 can also use a data object list (DOL) to request • values of names of specified etchings. Card 5 sends a DOL consisting of a list of label fields and lengths, and terminal 1 returns the corresponding value fields, without delimiters. Each TLV that is going to be used must be defined by the terminal or application programs to establish its data type and name. Since the terminal program and the application programs are developed separately, the VM 20 according to the present invention uses a linked structure (a balanced binary tree) to allow rapid addition and removal of tag names from the global tag name list. This requires that the following structure be compiled for each TLV in data space 41 initialized in the module that defines the TLV: Link One cell with "left" components (two higher order bytes) and "right" components (two lower order bytes) ) provides links to the elements of the tree. Left link A signed 16-bit offset from this TLV access parameter to the access parameter of a TLV record whose label is numerically smaller than its record label. A value of zero indicates that this TLV is not bound to a TLV with a label numerically less than 1. Right link A signed 16-bit offset from this TLV access parameter to the access parameter of a TLV record whose label is numerically greater than this record label. A value of zero indicates that this TLV is not bound to a TLV with a numerically greater label than this one. Label A two-octet string whose high-end numeric value is the TLV tag. Type A single octet that specifies control information. Reserved An octet that must be initialized to zero by the compiler 71. Data A cell that retains VM-specific information that includes access to the length and value fields of this TLV. This field must be initialized to zero by the compiler 71. The system also maintains a state byte for each TLV. This may be an octet reserved in the previous structure. The least-order bit of this octet must be set if a TLV has been assigned a value as a result of being in a sequence that has been processed by the symbols TLVPARS? or TLVSTORE. The purpose of maintaining an assigned state is to identify TLV values that contain valid data (which can be zero) and differentiate them from TLV values that have never been established and therefore are not valid. The VM core handles a global list of TLV tags to maintain a list of pointers to the initialized data space 41 that contains its current definitions, as described above. When a module is loaded, its TLV definitions are added to this list as part of its initialization; when they are downloaded, their TLV definitions will be automatically removed from the list by VM 20. An exception can be extracted if the module contains a TLV definition that already exists. The link field address described above is returned as the "access parameter" for TLV references. The programmer can not access these fields directly, nor can he make any assumptions about their content, after the VM 20 has distanced the TLV definitions. References to the TLV definitions in the source code are compiled either as direct references to the definition structures defined above, or as numerical label values. Within certain binary TLV definitions, individual bits or groups of bits are defined to have certain meanings. This is referred to as "TLV bits." References to TLV bits can be compiled with a literal pointer to a bit within the value field of the TLV, bit zero is the least significant bit of the first octet, bit 7 is the bit most significant from the same octet, bit 8 is the least significant bit of the second octet, and so on. The data assigned to a TLV definition is exposed to the application through a transient memory area of 252 octets that are maintained by VM 20 in the form of a database window (see Figure 7). The application program is allowed to change the content of this transient memory area. If the changes are to be retained, an address and length within the transient memory area must be passed back to the TLVSTOR ?. The address and contents of the transient memory area may become invalid when any TLV symbol is executed subsequently. As part of the security management of the cards 5 introduced in the reader 7, a verification is performed for the cards 5 which are known to be lost or invalid. A list of such cards 5 is known as a blacklist of cards or list of stolen cards. The handling of the blacklist of cards to the list of stolen cards is done by a set of dedicated functions that are specific to the handling of a list of stolen cards. A typical list can contain 10,000 primary account numbers (PAN) or up to 10 octets of each, or 20 binary coded decimal digits (BCD). The PAN entries are stored in a compressed (in) numeric format, they are translated with hexadecimal FH. As a PAN is a maximum of nineteen BCD digits, an entry in the list will always be translated with at least one FH. When examining in the list of stolen cards, the FH in a list entry are considered as wildcards or digits "it does not matter", but any FH in the PAN used as input are not wildcards. Wildcards can only appear at the far right of an entry. It can be considered that a PAN is found in the list of stolen cards if there is an entry in the list that is identical up to the first FH in the entry. Another part of security management is to provide cryptographic services to encode and decode data. Any suitable coding method can be used. T cryptographic algorithms are particularly provided for VM 20: module multiplication and module exponentiation, which are used in the RSA algorithm; and SHA-1 secure key calculation algorithm, but the invention is not limited to these. The multiplication of the module multiplies by two unsigned values x and y, where the product is reduced using the z module. The formula is : result = mod (x * y, z) The input values (x, y, z) are always of the same length. They are represented by octet chains and can be multiples of up to 8 bits and include 1024 bits. The values must be in order of high termination octets. The Secure Hash Algorithm (SHA-1) is an algorithm that is standardized as FIPS 180-1. SHA-1 takes input messages of arbitrary length and produces a key calculation value of 20 octets. The module exponentiation increases an unsigned value x to a power given by an exponent and not signed, where the product is reduced using the Z module. The formula is: result = mod (x? Y, z) The input x value and the z module are represented by octet strings and can be any multiple of up to 8 octets that includes 1024 octets. The values must be in order of high termination octets. Services and therefore software and even 1/0 devices can change over time based on market requirements. When major changes are required, a software update can be carried out in terminal 1 or remotely via the telecommunications network. However, for the user-dependent services it is preferable to have a dynamic but secure method for making minor updates specific to the user to the services provided by a terminal 1. The "plug and socket" software mechanism according to the present invention provides a flexible and secure online configuration of the different modules that make up terminal programs and applications. As shown schematically in Figure 8, in the transaction system according to the present invention, numerous procedures (referred to as "receptacles" 60) can be defined that can be inserted into the application scheduler (and therefore safe because to which they are under the control of the acquirer and under the supervision of the payment system) in an application 61, 62 to act as an apart-house for the addition of an additional improvement code (referred to as "plugs" 66) during the transaction processing. Any additional code that is to be plugged into a receptacle 60 must be written in terms of the set of symbols of the VM 20. The receptacles 60 are preferably placed at various points • suitable in the existing terminal applications 61, 62 or even in the terminal program itself. They are used to refer to library functions and can even be presented within a library function if a payment system anticipates the need to change the way the library function operates. The receptacles 70 are initialized for default behaviors by the VM 20. If no additional action is taken by the terminal program, the default behavior of the receptacles 60 will be to perform nothing when they are "executed (ie, they do not perform operation). The receptacles 66 include an executable code, written in symbols supported by the terminal 1, which can be inserted at points defined by the receptacles 60 to improve the default terminal logic The receptacles 66 can already exist in terminal 1 in a 63 library of plugs that may be requested from ICC 5, eg, receptacle / plug identifiers 67 in an ICC 5 and logic in terminal 1. The plug / receptacle identifiers 67 include a reference to both the plug and the receptacle that is plugged in so the plug is not in the ICC 5, but in the library 63. The plugs 66 can also come from an input device. da (so that the ICC 5 or a guest system connected to terminal 1), but only if there is agreement with the members of the payment system, for example, the distributor, the acquirer and the merchant. Upon completion of the transaction, the receptacles 60 are stored in their original default application behaviors. In accordance with the present invention, it is preferred that an ICC 5 does not contain the complete requests but only the plugs 66 that improve the existing applications of the terminal as these provide less memory. The receptacles 60 retain the execution pointers, also known as process pointers, which allow the creation of a procedure whose behavior may change at the time of execution. The receptacles 60 can be considered (and implemented) as an arrangement of procedures that are accessed through the DOSOCKET symbol which takes the receptacle number in an on-line byte, or by the IDOSOCKET symbol which takes the stacking receptacle number 27 of data. The receptacles 60 allow the reconfiguration of a terminal program or application to provide variations or improvements in the processing flow of the transaction. Alternatively, the receptacles in the ICC 5 may allow improvement of the ICC 5 of a terminal 1. The receptacles 60 provide an interface between software modules and • procedures that may come from several different sources. (acquirer, distributor, etc.). Since the acquirer and the distributor have a contractual relationship, they can agree to use specific receptacles provided by the acquirer of the program in a terminal so that a distributor can extend the behavior of the program, for example, to provide a constancy function ( airline miles, coupons, etc.). A module may specify that the receptacles 60 are automatically reconfigured when they are loaded for execution, or a client program may automatically assign a new procedure to a receptacle at the time of processing. Providing security conditions allows receptacles 60 in an application to be assigned a default behavior and then re-plugged with new procedures by subsequent modules, in order to provide specialized behaviors. To avoid undefined situations it is preferable if all the procedures are directed to a particular receptacle 60 which has no data stacking effect (except for the receptacle 0, as explained below). This ensures program continuity no matter which directed version of the procedure is executed. The default action of all receptacles 60 prior to modification will be at least one lack of non-operation.

An acquirer can allow improvements in the transaction by coding in an ICC 5 as part of the CSS mentioned above. By doing this, it can be implemented with receptacles 60. An executable module library can include the definition of new receptacles 60 for subsequent 66 plugs coming from an ICC 5. In this case, the module will define a receptacle 60 and then use the symbol SETSOCKET to assign a default behavior to it (often a null behavior). If the access control allows it, an ICC 5 can subsequently download an outlet 66 that includes symbols defining a new behavior and then use the symbol SETSOCKET to store it in the same receptacle 60, overriding the default behavior. Behavior modification is convenient and flexible but may provide the opportunity for people with bad intentions to modify the behavior at their convenience. Special care must be taken with the plugs 66 of an ICC 5 if they can modify the behavior of a receptacle or they can be placed in the program flow before a successful card authentication. For security, the terminal software may specify, in accordance with the present invention, a receptacle control method which controls whether a single receptacle 60 can be modified or not. Thus, for example, the execution of a code downloaded from an ICC 5 can be strictly controlled by an acquirer so that a receptacle can not be plugged in from ICC 5 until all the routines in the card have been carried out on the card. validation, for example, examination of an electronic signature. In accordance with the present invention, the security receptacle includes specifying the receptacle control procedure to be applied in subsequent attempts to plug a receptacle 60 (symbol SETPLUGCONTROL). The PLUGCONTROL procedure must be written to return, for a given receptacle number, provided that the receptacle 60 can now be modified. When a module receptacle list is subsequently processed at the module load time, or when a receptacle 60 is programmatically plugged in, the VM 20 first executes the PLUGCONTROL procedure described by the user to determine whether the receptacle 60 can actually be plugged in, and retains the existing behavior of the receptacle 60 in case it can not. A module that wishes to restrict the access of any receptacle 60 before another module is loaded for execution, you can carry out a procedure defined by the SETPLUGCONTROL symbol on a plug-in plug (zero plug) with the PLUGCONTROL function chosen as a parameter, before loading that module. When the next module, or any other module loaded for execution that has its list of receptacles processed, the receptacles 60 to which user access is denied defined by the PLUGCONTROL procedure will retain their existing behavior. This condition will not be considered an error. The code that is to restrict access to any receptacle 60 before an additional code is executed may carry out the procedure defined by the symbol SETPLUGCONTROL with the PLUGCONTROL procedure chosen as a parameter, at an appropriate point in the program flow. A programmatic request to plug in a receptacle 60 can determine whether the request is accepted or denied by the request to SETSOCKET. Any receptacle 60 whose behavior is modified, either by the module loading process or dynamically by a programmed command, is reset to the behavior it had when the last executable module was loaded for execution, as part of the termination procedure packaged within the procedure defined by the module execution symbol (? XCECUTEMODULE). As an example of a specific function of the acquirer, suppose that the basic 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 the code that sets the permission flag for this receptacle only if the distributor is the same and the acquirer and the transaction amount exceeds a certain minimum. During the transaction there is an instruction which reads an arbitrary code from the ICC 5. Part of the ICC code defines a REWARD routine (reward) which updates the frequent user miles, and then tries to execute the phrase PLUG REWARD INTO LOYALTY. This phrase connects the execution of REWARD with the execution of LOYALTY. If the LOYALTY receptacle permission flag is set according to the above logic, SETSOCKET will take place; otherwise, LOYALTY will retain its default behavior, similar to a null operation. Subsequently, when the application code executes its LOYALTY function later, it allows R? WARD defined by the ICC only in accordance with the rules defined by the acquirer. Typically, the VM 20 operating in a terminal 1 may have a limited number of receptacles 60, for example 64 receptacles numbered from 0 to 63. In its most basic form, a main terminal program may be composed almost entirely of the receptacles 60 and the basic program flow from one receptacle to another. The receptacles can then 'be plugged with transaction processing procedures by other modules loaded at the time of application selection, either from terminal 1 or from ICC 5. The receptacles 60 that are presented to the main program before the application selection are assigned as a null vior by default by TRS. If a given receptacle 60 is plugged with a procedure for more than one module, this last operation simply replaces any previous one.

Load, handling and execution of the module The code written to operate in VM 20 (which includes resident terminal services compiled as symbol modules) can assume that the next activation of the terminal-specific kernel software that supports VM 20 has made any terminal-specific activation initialization. necessary, and the execution of the main processing circuit of terminal resident services (TRS) has begun through a module load process which is described later. If the main TRS processing circuit is removed, the control returns to the specific terminal layer of the software responsible for the newly loaded TRS and re-introduces its main circuit. All VM resources are released whenever TRS exits, except for data in non-volatile database. The release of resources occurs when the terminal is inactivated, when TRS is exited or when TRS is restarted by the terminal's operating system (if any). An updated version of any TRS module can be acquired since the main TRS circuit can be entered at the end, all TRS resources including data in its non-volatile database are supplied when they are released. The software works in a terminal 1 or an ICC 5 can be managed by the VM 20 in the form of one or more modules, where each module can contain one of the following categories of information: Symbolized code Initialized data Assignment of non-initialized data Definition Database TLV definitions List of receptacles (procedures) Module interdependencies Each module is preferably supplied to a terminal 1 in a module supply format (MDF). The VM 20 maintains a non-volatile store in the read / write non-volatile memory 18 of the modules that have been supplied and installed in terminal 1. Each module in the store will be identified by a module identifier or module ID.

After registration in the module store, the module information is available through a non-volatile module database maintained by the VM 20 and stored in the non-volatile memory 18. In accordance with the present invention, the VM 20 protects the modules within the store by preventing the modification of any other module because there are no symbols for such access. In addition, VM 20 provides a new version of a given module which is placed in the warehouse while a module of the same module ID exists for execution purposes.

There are conceptually two phases in the processing of a module: firstly it is "loaded", which means that it becomes accessible, and its data, databases, etc. are started. and secondly, if it is an executable module, the VM 20 begins to process its symbols starting at its entry point. The execution procedure will be described with reference to the flow chart in Figure 9. First, in step 100, the resources are marked and saved. Before executing a module, VM 20 marks its status and saves any necessary resources so that this state can be restored later. The state includes: • The position of the extendable memory pointer, the information unit pointer, and the information unit end pointer. • The contents of the current complete plug list. • The TLVs registered in the list of TLV label names. • Other internal data than the implementation of the VM needs in order to handle the activation and execution of the modules. Subsequently, the module is loaded in step 102. The module ID of each module to be executed is passed to the Load Module subroutine (load module), which will be described later. If the module is loaded without error, as determined in step 104, it can be executed and the program advances to step 108. If an error is determined in step 104, the execution of the module and all necessary resources for the execution of the module are released in step 105. This requires the VM 20 to perform the following actions: • All the volatile memory necessary to load the module, and any module that is required to be loaded, must be released and cleaned. to zero. This includes, but is not limited to: • The space required for all the initialized and uninitialized data of the module. • The space needed for any internal memory of TLV and management of data structures defined by these modules. • The space required by any internal memory and the management of data structures required by the databases defined by these modules. • The TLV name list maintained by the VM for tag search which must be restored to its state immediately prior to the execution of the module. • The content of the receptacle list maintained by the VM must be restored to its state immediately prior to the execution of the module.

• The contents of the information unit pointer, information unit end pointer, and extendable memory pointer are reset to their values immediately prior to module execution. • After successful loading of the module, it is determined in step 106 whether the module is an executable or library module. In the case of the latter, the execution of the module does not take place and the VM 20 releases all the resources in step 110 as described for step 105. If the module is executable, the field specifying the use of input is determined of the module. VM 20 starts the module by requesting the symbol specified in the entry point field. Then each symbol is executed in turn in step 108. The module ends using the symbol R? TURN after which all resources are released in step 110. The process necessary to load a module, the subroutine "load module ", will be described with reference to the flow diagram shown in figure 10. If an error is detected during the loading of a module, this causes the subroutine to load a module immediately return false (false) . A general error is one such as "out of memory" where there are insufficient resources to provide space for initialized data, uninitialized data, databases or TLVs; when a duplicate TLV tag is discovered; and so on, the initialized data must be adjusted before database processing and TLV sections • because these are parts of the initialized data section. In step 120 it is determined whether the module is already loaded in the memory. If it is already loaded, it does not load a second time and the load module immediately succeeds, returning a true (true) . Subsequently, in step 122, it is determined whether the module is in the warehouse. If not, it can not be loaded, so the subroutine of loading module fails, returning a false (false). In step 124 it is determined how many bytes of data for the uninitialized data area 41 of the module are necessary and the required quantity is reserved. This area 41 is set to all zeros by the VM 20. Similarly, in step 126, the required number of data octets is reserved for the initialized data area 42 of the module. After, the initialized data is copied in this area. In step 18, the TLV defined in the module to be loaded is added by the VM 20 to its internal name list used for the TLV search. The root of the TLV data structure is stored. After, in step 130, the databases defined in the module to be loaded are instantiated by the VM 20. The steps 128 and 130 can be executed in any order. In step 132 the imported modules are selected for the current module. In step 134 the list of imported modules is examined, recursively loading each one at a time. If an imported module can not be loaded for any reason, as determined in step 136, the module that imports the module is also considered to have failed in its loaded, as it can not access the services of the imported module. In this case, the module load module returns false (false). In step 138 it is determined whether an additional module will not be imported. In case of an affirmative answer, the procedure returns to step 132. After the determination in step 138 that the last imported module has been recursively loaded, the current module has left its resources allocated, loaded and initiated without error, in a way The module loading plugs the receptacles 70 into the list in step 139 and then returns true, indicating that the module has been loaded successfully. Any attempt to plug the zero receptacle must be ignored by the VM 20. If the zero receptacle needs to be plugged in, it can be carried out using the S? TSOCKET symbol. The procedure for plugging receptacles 70 into step 140 will be described with reference to FIG. 11. In step 140 the default behavior of each plug in the loaded module is instantiated. In step 141, it is determined if there is a plug. If this is not the case, then the module is executed in step 149. In the positive case, the first plug is selected in step 142. In 143 it is determined whether the security flag or the associated socket is set or not. If this is not the case, the receptacle is plugged into stage 146. In the affirmative case, the specified safety function for the receptacle is executed.If the safety evaluation is positive, the receptacle is plugged into stage 146. In stage 148 is determined if the plug is the last plug in. If not, the next plug for evaluation is selected If the safety check is negative, it is determined whether the plug is the last plug in step 147. If in steps 147 or 148 it is determined that the plug is the last, the module is executed with the default behavior, for all receptacles which have not been plugged in and for the plugged behavior for those that have been plugged in. medium, a safe modification of the behavior has been obtained.The modules that are loaded from an ICC 5 by the symbol LADCARDMODULE must be handled differently from the ones loaded from the warehouse in the terminal. nal 1 using the symbol EXECUTEMODULE. Figure 12 shows the flow diagram for LOADCARDMODULE. Before the execution of the card module, the VM 20 marks its status and saves any necessary resources in "step 150 so that this state can be restored later." The state includes: • the position of the extendable memory pointer, the information unit pointer and the information unit end pointer • the content of the entire the receptacle list (procedure) of the TLV label.

• Other internal data needed by the implementation of the VM in order to manage the activation of the card modules. The module is loaded in step 152 using the routine load module described above with reference to Figure 9; the difference is that the module is in the ICC 5 and not in the warehouse, and it is no longer loaded. If it is determined in step 154 that the card module is not loaded successfully, all resources are returned in step 155 to the state they were in immediately before the execution of the LOADCARDMODULE symbol. This requires that: • All the volatile memory needed to load the module and any module to be loaded, must be released and erased to zero. This may include, but is not limited to: • The space required for the initialized and uninitialized module data. • The space for any internal TLV buffer and data structure management defined by these modules. • The necessary space for any internal buffer and the necessary data management structures for the databases defined by these modules.

• The list of TLV names maintained by the VM for tag search which must be restored to its state immediately prior to the execution of the module. • The content of the receptacle list (procedure) maintained by the VM which must be restored to its state immediately prior to the execution of the module. • The contents of the information unit pointer, the information unit end pointer, and the extendable memory pointer are reset to their values immediately prior to module execution. If the card module is successfully loaded, the state saved in step 150"Mark and save resources" is simply discarded in step 156. In this way, a card module has been grafted onto a system in process. To be useful, the card module must plug receptacles (improve procedure) otherwise there is no way to execute any code that is present in the card module. Subsequently, it is determined in step 158 whether the module is an executable module and if so, stage 160 is executed as described with reference to steps 106 and 108 of figure 9. The specific embodiments of the invention described in FIG. the foregoing is intended to be illustrative only, and many other variations and modifications may be made thereto in accordance with the principles of the invention. The entirety of such embodiments and variations as well as the modifications thereof are considered to be within the scope of the invention as defined in the following claims: APPENDIX 1. Definition of symbols 1. 1 General The EPICode symbols are the instruction set of a two-stacked virtual machine with an additional information unit pointer. Symbols can also be treated as the intermediate language of a compiler. Some implementations of the translator program can actually compile EPICode symbols to machine code. The EPICode symbols are octet symbols, which allow a maximum of 256 symbols. The symbols with prefix of an octet allow the range of symbols to extend to a theoretical maximum of 65536 symbols, considering the prefixes as defined pages of 256 symbols each. In fact, a limited range of prefix symbols is defined. Each symbol value is shown in hexadecimal system as a 2-digit hexadecimal code, with its corresponding name.

Symbols with a prefix (single octet symbols) are declared as primary symbols, while those with prefixes (two-octet symbols) are called secondary. The execution of any primary or secondary symbol that is not defined in the following list will result in an ILLOP exception. 1. 1.1 Forth functions for symbols? PICode This section presents an alphabetical match list of Forth words using EPICode symbols. Each line contains, from left to right: • Name of the definition, in capital letters, in bold letters and in a single space; • Natural language pronunciation if it differs from English; • Special designators, where applicable: A Word Forth ANS (which includes all sets of optional words) C Compiler directive, must be used within a definition G Generic word Forth (in common use, for example, interest group Forth, but not in ANS Forth).

H Host word (compiler) which may or may not contribute symbols to the target. Equivalent EPICode symbols. 1. 2 Conventionalisms 1. 2.1 Number formats Larger numbers of one octet are transmitted in symbol programs in the form of a 2"high termination complement of the first most significant octet. Within the EPICode program, numbers must always be accessed by operators of the correct format, in order to allow programs to store numbers in the most appropriate way to the underlying architecture. The multiple precision data types are handled in the stack with the most significant cell in the uppermost part. In memory, these types of data are handled with the most significant cell in the least addressed cell within the multiple cell type. 1. 2.2 Control and movement structures The control structures are formed by a control symbol (BRA, RLOOP, etc.) followed by a four octet, two octet or a single byte shift, signed. The scrolling followed by the control symbol is added to the Pointer Symbol (TP) after the scroll has been placed at it. Therefore, if the branching symbol is in addr, the destination address is addr + 2 + offset for a 1-octet offset (SBRA), addr + 3 + offset for a 2-octet offset (BRA) and in addr + 5 + offset for a 4 octet offset (EBRA). Symbols that require 4 octet shifts are available only for a specific terminal code in the virtual machine implementation that supports a 32 bit linear address slot for code. 1. 2.3 Directions The procedures defined by the user are defined by their addresses within the EPICode program. If the symbols are translated or compiled into native code for larger processors, the symbol space address will not correspond to the actual address of the code. 1. 3 Data Typing Most of the symbols operate in quantities with a size of data and a signed or unsigned interpretation, determined by the symbol, but the instructions which have access to the memory in the storage of the information unit can take a type of Cancellation data determined by a prefix symbol. A set of octet codes, shown in Table 1, is reserved for such prefix symbols, but only SBYTE and UBYTE are currently used. Data types that require less than one cell (1 octet) are marked with at the memory by using an octet operator or an operator with a cancellation prefix. If signed data is implied or specified, the data is extended with a signature to the width of the cell. If a data without signature is implied or specified, the data has no extension.

Table 1: Prefixes of data types 1. 4 Arithmetic Addition and subtraction operations that exceed the specified size of the returned result will return this result module [unsigned maximum value adapted to that size] +1. Storage operations whose destination storage is smaller than the size of the transmitted value will store the truncated value to the destination width. The division operations are symmetric; that is, it is always rounded to zero, regardless of the sign. 1. 5 Primary symbols The symbols are divided into several logical sets for convenience and are shown in separate sections below. All symbol values are in hexadecimal. The data type prefixes applicable to the symbols are implicitly included using the abbreviations shown in table 1. Any primary symbol which has a prefix for a symbol not found in the prefix list is invalid, and the execution of such symbol causes one to carry out an ILLOP exception. The default type of the symbol is in italics, and always included first. The default data type prefix is redundant, and is invalid if it is used as a prefix for a symbol, as in • the above. 1. 5.1 Set of Operations 00 NOOP (-) No action is taken. 04 BF? TCHS (addr - piup) Arroba an 8 bit octet from the given address, the sign extends to it. 08 LIT (- x) Returns to the cell that follows online as data. 09 LITC (- addr) Returns the cell that follows online as a literal that is an address in the code image. The value of the literal can be repositioned in that image by the program loader. OA LITD (- addr) Returns the cell that follows online as a literal that is an address in an initialized data space. The value of the literal can be reassigned in that image by the program loader. OB LITU (- addr Returns the cell that follows in line as a literal that is in an address in an uninitialized data space.The value of the literal can be reassigned in that image by the program loader. OC PLIT (-u ) Returns the octet that follows online The octet has a zero extension of 32 bits OD NLIT (- num) Returns the octet that follows online, with a zero extension of 32 bits and then is denied OE HLIT (-u) Returns the value of 2 octets that follows online The value has a zero extension of 32 bits 10 HLITC (-addr) Returns the address that results from adding the value of 2 unsigned bytes that follow in line with the base address of the code image The value has a 32-bit zero extension 11 SLITD -a-addr 'Returns the address that results from adding the unsigned octet that follows the line interpreted as positive offset in cells to the initialized database address. The octet has extensive zero ion at 32 bits and multiplied by 4 to - provide a shift in octets. 12 HLITD (-addr) Returns the address that results from adding the 2-octet value that follows in line to the initialized database address. The value is sign-extended to 32 bits. 13 SLITU (-addr) 5 Returns the address that results from adding the unsigned octet that follows online, interpreted as a positive displacement in cells, to the uninitialized database address. The octet is zero- extended to 32 bits, and multiplied by 4 to 10 provide a shift in octets. 14 HLITÜ (-addr Returns the address that results from adding the 2-octet value that follows in line to the non-initialized database 15. The value has a 32-bit sign extension 15 ADDLIT (x - x3) Adds the data in the cell that follows in line with xlf 20 what is provided by x2 16 SADDLIT (xx - x2) Adds a literal of the value in line of a signed octet to xlf what is provided by x2 25 19 SUBLIT (Xi - x2) Subtract the data in the cell that follows in line with xlf what is provided by xa.1A SSUBLIT (j, - X2-t) Subtract the value in line from a signed octet of xx, which provides xa.IC VSUBLIT (dd-lit) Subtracts the online value of eight octets signed of the double number d. SMULLIT ID (mira - num * lit) Multiply num by the literal of a signed octet that follows online 1E SDIVLIT (num - num * lit) Divide num by the literal of a signed octet that is still online 21 DIVU (ux u - u3) Divides ux and u2 (not signed) what is provided by u3 .3A SHRU (u - u »l) Logical shift of u to the right one bit, inserting a zero bit.

N.B. The SETxx operators perform a comparison with zero, the flag is adjusted according to the results of this comparison. 42 SETGE (num - flag) Return TRUE (TRUE) if num 0 (signed) 45 SETLE (num - flag) Return TRUE (TRUE) if num 0 (signed) 48 CMPGEU (uxu2 - flag) Compare unsigned values ut and u2, returning TRUE (TRUE) if Ua U2. 4C CMPGE (nutrí! Nutria ~ flag) Compare the signed values numa and num3 returning TRUE (TRUE) if num! num3 4F CMPLE Compare the signed values nurpj and num2, returning TRUE (TRUE) if nup »! < num2.

The following symbols provide access to information unit storage. 50..53 PFRFETCH2 ... PFRFETCH5 - num) 5 Equivalents of short form for SFREFETCH n (q.v.) where n is 2..5. The types of possible data of cancellation include: SL, SB, UB 54..5F TFRFETCH12 ... TFRFETCH1 10 (- num) Equivalents of short form for SFRFETCH n (q.v.), where n is -12 .. -1. The types of possible data of cancellation include: SL, SB, UB 15 60..63 PFRSTORE2 ... PFRSTORE5 (num -) Equivalent of short form for SFRSTORE n (q.v.), where n is 2..5. The types of possible data of cancellation include: SL, 20 SB 64..6F TFRSTORE12 ... TFRSTORE1 (nial-) Equivalents of short form for SFRSTORE n (q.v.), where n is -12 .. -1.

The types of possible data for cancellation include: SL, SB SFRFETCH (- num) Places at the value (default, cells) num in the offset of an inline signed octet from the information unit pointer. The offset is interpreted as a cell index (that is, it is multiplied by four to provide the offset by octet) for the default data type, and as an octet index for an octet size override. Note that SFRFETCH 0 and SFRFETCH i return the internal information unit management data without meaning to the requested program, so that they do not constitute valid references within the information unit. Therefore, the parameters that start in SFRFETCH 2 and the temporary variables that start in SFRFETCH -1, since the information units stack the growth back into memory. The types of possible cancellation data include: SL, SB, UB. SFRSTORE (num-) Stores the value (per commission, cell) num in the argument in the displacement of an inline signed octet from the pointer of the information unit. The offset is supplied in an on-line value which is treated as a cell index (that is, multiplied by 4 to provide a byte-directed offset) for the default data type, and as an octet index for data dimensioned byte byte. See SFRFETCH for additional details. The types of possible cancellation data include: SL, SB. FRFETCH (- zium) Extracts the num value in the signed offset of the information unit pointer. The offset is provided by an online value of two octets. See the description of SFRFETCH for more details. The type of possible cancellation data includes: SL, SB, UB. FRSTORE (num -) Stores the num value in the argument and the signed offset of the information unit pointer. The offset is provided by an online value of two octets. See SFRSTORE for additional details. The type of possible cancellation data includes: SL, SB, UB. SFRADDR (-addr) Returns the address in the frame in the signed offset from the information unit pointer. The offset is provided by an on-line value of one octet which is multiplied by four to provide an octet offset for the default data type, and is used directly as an octet index for byte-size data bypass. The type of possible cancellation data includes: SL, SB. FRADDR (-addr) Returns the address in the frame in the signed cell offset of the information unit pointer. The offset is provided by an in-line value of two octets which is multiplied by four to provide an octet offset for the default data type, and is used directly as an octet index for byte-size data bypass.

For symbols that provide support for Forth standard number conversion functions: the NMBR in the names of the symbols "numbers" is provided. The symbols LTNMBR, NMBRS and TONUMBER use the BASE user variable as the base of the conversion number. 8C UNDER (X] X2 - X] XjX2 / doubles the second step in the stack 9C ZERO (-0) Leaves the value zero in the stack 9D ONE (-1) Leaves the value of 1 in the stack 9E MINUSONE (-1) Leave the value of -1 in the stack AO INDEX (addrjnum - addr2) Multiply num by 4 and add a addr! To provide addr2 A2 EDOCREATE (-a-addr) Return to the address in the space of data whose displacement follows the cell in line immediately after this symbol, and performs a subroutine return.This symbol is used to identify a data area when requesting a procedure corresponding to it, which allows the creation of tables of data. position-independent data A3 EDOCLASS (-a-addr) Branches to the code space address whose offset remains in the in-line cell as follows, after pushing in the data stack the address that results from adding the offset not signed that is still in the cell s next in line (that is, after the code has been moved) to the base address of the initialized data space. This symbol is used to identify a data structure in the program memory and to transfer control to the routine that processes it, providing the basis for a simple class mechanism. A4 DOCREATE (-a-addr) Returns the address in the data space whose displacement follows the value of two octets in line immediately after this symbol, and performs a subroutine return. This symbol is used to identify a data shift when requesting a procedure that corresponds to it, which allows the creation of independent data tables. of position. A5 DOCLASS (-a-addr) Branches to the code space address whose offset remains in the in-line cell that follows, after pushing on the data stack the address that results from adding the unsigned offset that follows in the next two octets in line (that is, after the code shift) to the base address of the initialized data spaces. This symbol is used to identify a data structure in the program memory and to transfer control to the routine that processes it, providing the basis of a simple class mechanism.

• A6 ECALL (- Followed by an inline cell, request that the procedure use this cell as a signed octet offset in code space.) A7 SCALL (-) Followed by an online octet, request that the procedure use this octet as a signed octet offset in the code space A8 CALL (-) Followed by a displacement of two octets in line, request that the procedure use this value as an octet offset signed in the code space AB SMAKEFRAME Followed by two non-signed octet literals containing first params, the number of cells that form the procedure parameters, and then terpps, the number of temporary variable cells. Assign cells params + temps + 2 and then set the current information unit pointer to indicate the new unit of information. This symbol assigns procedure parameters and temporary variables that will be accessed by FRFETCH and FRSTORE. The individual machine is allowed to accumulate information units in the return stack, so that the use of information units is restricted by the rules that apply to the use of return stacking in general. The procedure parameters will be moved from the data stack within the frame by SMAKEFRAME so that they can be accessed by FRFETCH and FRSTORE. If it is not possible to accumulate an information unit of the requested size, FRAME_STACK__ERROR will be extracted. AC MAKEFRAME (Xparaaß * •. Xj ~ ~) Followed by two literals of two unformatted octets, it contains the first ones for s the number of cells that form the procedure parameters, and then temps, the number of temporary variable cells. See SMAKEFRAME for additional details. AD RELFRAME (-) Restores the pointer of the information unit to its previous value and frees the current information unit. 1. 5.2 Branch Establishment These symbols include the usual machine branch stacker operators, plus the process times for the Forth DO? DO LOOP + L00P LEAVE I and J. words.

AF EBRA (-) Branch always. Online displacement of four octets. BO EBZ (num-) Branch if num = 0. Line displacement of four octets. Bl EBNZ (num-) Branch if num? 0. Online displacement of four octets. B2 SBRA (-) Short branch. Offset in line of signed octet. B3 SBZ (num-) Branch short if num = 0. Offset in line of signed octet. B4 SBNZ (num-) Branch short if pum? 0. Offset in line of signed octet. B5 BRA (-) Branch not conditioned. Online displacement of two octets signed. B7 BNZ (num-) Branch short if num? 0. Online offset of two signed octets. 1. 5.3 Data Type and Code Page Overrides This group allows eight-bit symbol limitations to be removed. Note that its stacking action depends on the following symbol. The pair of symbols is referred to as a secondary symbol. The extension symbols for data types that occupy symbols CO to CF. The symbols not used in this. Interval are reserved for future use when the prefix types of additional data are required.

Cl SBYTE (-) Signed octet. C2 UBYTE (-) Unsigned octet • C5 SLONG (-) Signed length, 32 bits. C6 ULONG (-) Length unsigned, 32 bits. 1. 5.4 Plug Management Symbols D2 DOSOCKET (-) Followed by an online octet (0..63) which specifies the required function number. The stacking effect is defined by the function attached to the plug. D3 IDOSOCKET fu-; Execute the plug function whose plug number (0..63) is specified by u. The lower level stacking effect is defined by the function attached to the plug. The ANS Forth 24 exception (invalid numeric argument) will be extracted from if u is greater than 63. 1. 5.5 Control Adjustment E6 IMCALL (-) Executes the function of the module whose number of modules • (0-255) is given in the next on-line octet, and whose function number (0-255) is given in the next on-line byte. 5 Stacking effects depend on the function requested. E7 CLASSPROC (-) During loading CLASSPROC marks the entry of the • 10 class management code. Used for compilation assistance and can be implemented with a NOOP. F9 SYSFUNC (-) A page expansion symbol treated as the first octet of a secondary symbol. Request the routine specified by the following online byte. The supported secondary symbol setting is defined in Section 1.7. The stacking effect is defined by the specified routine. 20 1.6 Plugs The first eight secondary plug symbols are reserved for plug-in handling functions, and the defined operating functions are described below. The remaining plugs (D2 08 to D2 3F) are for application use.

F9 91 SETSOCKET (xp u -flag) Sets the execution pointer xp to the handler of the plug-in function u, which will cause xp to execute in any subsequent execution of DOSOCKET < u > . Before the execution pointer is adjusted, the procedure installed by SETPLUGCONTROL to determine if the plug can be plugged in with your new xp. flag is the value returned by this procedure. SETSOCKET only adjusts in the pointer if flag is FALSE, otherwise the pointer is discarded. The exception will be requested -24 (invalid numeric argument) if u is greater than 63. D2 00 SETPLUGCONTROL (Xp -) Executes the execution pointer xp of a procedure written by the user that will be returned by SETSOCKET to determine if the plug can be plugged in. The action of this procedure (which is referred to herein as PLUGCONTROL for illustration purposes) must be: (u -flag) where u is the number of soc et and flagr is returned as FALSE (FALSE), if the plug can be plugged in, or as TRUE (TRUE) if it can not. In addition, the PLUGCONTROL procedure must produce an exception -24 (invalid numeric argument) for values of u outside the range 0-63. A default action of PLUGCONTROL is installed by the virtual machine to return FALSE for all values of u, which allows all plugs to be plugged in. OSCALLBACK (dev fn num num2 - ior) Requests an operating system routine with the parameters: dev selects the requested I / O device for function fn with num! 32 bit parameters contained in it array num2, returning ior, which is dependent on the implementation. Note that 2ium2 is the top of the stack. and nmu2 correspond to arvc and argv, respectively, in course C. Note that this plug is implementation dependent, and is provided so that specific terminal programs (TRS) described using EPICode may have terminal-dependent I / O. If the specified function is not supported, the exception -21 (operation not supported) is activated. D2 04 EPICALLBACK (dev fn numx num2 - ior) A receptacle for an EPIC routine which can be requested by the underlying operating system. The four parameters are 32 bit values designed for use as follows: dev selects the requested I / O device for function fn with nu i of 32 bit parameters contained in array num2, returning ior whose meaning is implementation dependent. num! And num2 correspond to arvc and argv, respectively, in use C. Note that this receptacle is implementation dependent and is provided so that specific terminal programs (TRS) written using the EPICode code can provide callback routines for the operating system. If the specified function is not supported, the exception -21 (operation not supported) is activated. 1. 7 SYSFUNC I / O Setting This set defines the functions available via the SYSFUNC symbol, which acts as a generalized interface for underlying operating system routines. 1. 7.1 Access to Devices Each device is assigned a unique device number. The ior status codes are dependent on the device, except where a ior code of zero always indicates success.

F9 00 DKEY (dev - throw) Reads a character from dev input device.

F9 01 DKEYTEST (dev - flag) Returns a TRUE (TRUE) if the character is ready to read from the dev input device. F9 02 DEMIT (char dev -) Transmits char to the output device dev. F9 03 BEEP (u dev -) Requests that the output device dev generate a sound of duration of u milliseconds. This function can suspend processing for the specified duration. F9 04 DREAD (addr len dev - ior) Reads a sequence from the dev input device, returning a device dependent ior. The returned sequence contains only minor order bytes of characters read from a keyboard device. F9 05 DWRITE (addr len dev - ior) Write a sequence to the dev output device, returning a dependent ior to the device. F9 06 DSTATUS (back) Returns the state of the resource associated with the dev device, where in the general case the "ready" and "treatable" states are indicated by zero and "not ready" is indicated by any other value . A specific device can return non-zero values that have significance for that device. If the device has been selected by a previous execution of the OUTPUT symbol, a "not ready" DSTATUS will be returned until the execution of the function passed to OUTPUT is completed. F9 07 DIOCTL (dev fn num a-addr - ior) Performs the IOCTL function fn for the dev channel with pum arguments of cell size in the array as a- addr. F9 08 OUTPUT (xp dev - ior) Executes the procedure whose execution pointer is given by xp with the output addressed to the dev device. When returning from OUTPUT the current output device (see GETOP) is not affected, ior is returned as zero if the procedure is executable. All the exceptions that arise from the execution of xp are captured by the virtual machine and cause immediate termination of OUTPUT. F9 09 DWRITESTRING (dev -) This symbol is followed by a sequence of characters, stored in the stream of symbols as an octet count followed by many octets. The DWRITESTRING symbol writes the characters. to the selected dev device. The execution continues immediately after the last character. F9 OA GETOP (- dev) Returns the dev device finally selected by - SETOP or during the execution of a function that passes to OUTPUT. It is used to find a default device for 1/0 operations oriented by the device. This function allows the dependent functions of a current device to be easily implemented. F9 OB SETOP (dev -) Used to set the default dev device returned by GETOP for 1/0 operations oriented by device. This function allows the dependent functions of a current device to be easily implemented. F9 OC FORMFEED (dev -) Executes a "new form" action depending on the device such as "delete screen" (terminal screen) or "extract page" (printer) on the dev device. F9 OD CR (dev -) Executes a device-dependent "new line" action on the dev device. F9 OE SETXY (nuttij.nuttia dev -) Execute an action of "establish absolute position", dependent on the device, on the dev device using pum: as the ordinate x and num2 as the ordered y. 1. 7.2 Time Management Standard Forth words. 1. 7.3. Language and Hand Management The signs in this group provide a mechanism for selection of language and message handling as well as display. F9 20 C? OOS? LANG (addr - flga) Selects the language whose ISO 639 language code is provided by the two characters in addr. Yes flag (flag) is TRUE (TRUE), the language is found and now it is the current language. Otherwise, the program you are requesting will select another language. At least one language (the native terminal language) will always be available. F9 21 CODEPAGE (num - flag) Attempts to select the resident page code num. The code pages are numbered according to ISO 8859 (0 = set of common characters, 1 = Latin l, etc.). flag (flag) is TRUE (TRUE) if the code page has been selected. F9 22 LOADPAGE (addr - flag) Install the code page in addr in the terminal (the page will usually be found on the card). flag indicates a successful loading of the page. Installation on the page can be done when a new table message has been loaded from the ICC that requires a page of code that is not available in the terminal. F9 23 INITMESSAGES (-) This function deletes private provider messages, numbered from CO to FF (hex) and any message installed by LOADMESSAGES. This function must be requested after each user session. F9 24 LOADMESSAGES (c-addr-) Installs a message table in an appropriate place in the transient message database, c-addr provides the position of the message table definition, which includes the page code to be used for messages, the two-letter language code according to ISO 639, and the messages to be installed. F9 25 GETMESSAGE (num - c - addr len) Returns the sequence parameters for the pum message. The back spaces of the len length of the sequence are removed. F9 27 UPDATEMESSAGES (addr len -) Installs a message table in the resident language tables. If a language with the same code is already present, it will be replaced. Otherwise, the new language will be added. If there is not enough space for the new language, THROW will be supplied with Code 22 (TOO MANY LENGUAGES) addr provides the position of the TLV that contains the message table definition, which includes the page code to be used for messages, the code of two-letter language according to ISO 639, and the messages to be installed. F9 28 MESSAG? SIZE (- len) Returns the standard message length for this terminal. F9 29 TYPEMESSAGE (addr len -) Displays the given sequence of the message line of the terminal. 1. 7.4 Handling of ICC Card The symbols in this group provide a mechanism to handle integrated circuit card readers. F9 30 INITCARD (num - ior) Selects the ICC reader pum, where pum is 0 or 1. F9 31 CARD (c-addrx lent c-addr2 len2 - c-addr2 len3) Sends the data in the buffer c- addr! lenx to the card, and receive data with c-addr2 len2. The len3 returned provides the current length of the received sequence. The c-addr buffer! epi must contain: A standard four octet ISO header (Class, Instruction, Pl, P2). Optional data (lengh followed by lengh octets, where lengh can be 0-225) The c-addr2 buffer len2 must provide adequate space for the card response plus two status octets containing SW1 and SW2.

Error handling is performed internally within CARD F9 32 CARDON (c-addr lenx - c-addr len2 ior) Applies power to the ICC and executes the card setting function, c-addr lenx provides a buffer over which the response to restart will be placed; len2 is the actual length of the returned sequence. F9 33 CARDOFF (-) Inactive to the ICC. It is executed when all transactions have been completed. F9 34 CARDABSENT (-flag = Returns TRUE (TRUE) if an ICC card is not present in the reader, otherwise it returns FALSE (FALSE). 1. 7.5. Magnetic Strip Handling The symbols in this group provide a mechanism for handling magnetic strip devices. F9 38 FROMMAG (c-addr lenx num - c-addr len2 ior) Read one or more ISO magnetic strips. The operation can be interrupted by the CANCEL button of the user or by elapsed time. pum is the ISO identifier that the track or tracks of the magnetic tape to read1, c-addr is the destination address for the sequence and len is the maximum length (at least 78 octets for IS01, 41 bytes for IS02 and 108 for IS03, or sums of these for readings of multiple magnetic strips). When returning, len2 provides the actual length of the read strip. F9 39 TOMAG (c-addr len num - ior) Write an ISO magnetic strip. The data is in the buffer c-addr len and will be written to the pum strip (1-3). The operation can be interrupted by the CANCEL button of the user or by elapsed time. 1. 7.6. Man of Modem The symbols in this group provide a mechanism for handling the modem device, F9 40 MODEMCALL (nutrí! Nutt ^ nu, nura, nuitis c - addr len - ior) Requests a number using an internal terminal modem. pu! and pum2 indicates the speed of the input and output line that is used (from 75 to 19200 bauidia). The current supported speeds are defined by implementation. num3 indicates parity (0 = none, 1 = odd, 2 = even). num4 indicates the number of bits to use (7 or 8) pums indicates the number of stop bits used for transmission (1 or 2 bits). c-addr len is the sequence that contains the phone number to call ',' can be included to wait dial tone. If the character of this sequence is 'P', is used marked by pulses instead of marked by tones, used by default. F9 41 MODEMHANGUP (- ior) This function is used to end the current modem session. F9 42 TOMODEM (c-addr len - ior) Transmits the sequence to c-addr len over an established modem session. F9 43 FROMMODEM (c-addr lenx - c-addr len2 ior) Receive a modem sequence. c-addr is the destination address for the sequence and lenx is its maximum length. On return, len2 provides the actual length of the sequence read. If characters are not received during a specific period, an elapsed time occurs. F9 44 MODEMBREAK (- ior) This function sends an interrupt in the connected modem session. 1. 7.7. Management of Black List The symbols in this group provide a mechanism for handling the blacklist file. F9 48 INITBLACKLIST (-) This function initialises the black list to an empty state. F9 49 BLACKLISTINSERT (c-addr len-flag) This function inserts an entry in c-addr in the list, which is kept in the sorted order. This function must be used when the list is updated.

The flagr (flag) returned is FALSE if the insert is successful (the entry is not in the existing list and the list is not complete). F9 4A INBLACKLIST (c-addr! Lenx - c-addr2 len2 flag) This function tries to find a key c-ad r! len in the list. c-addr2 len2 contains the search result (which includes the remaining octets from the selected entry and possibly some other information octets), if the key is found. The flag (flag) returned is FALSE if the number is found. F9 4B BLACKLISTDELETE (c-addr len-flag) This function deletes an entry from the list, where c-addr len is the key for the entry to be deleted. It can be up to 18 octets long. The flag (flag) returned is FALSE if the deletion is successful (the input is found). 1. 7.8 Support for Security Algorithms The symbols in this group provide support for initialization and use of security services.

F9 50 INITSECALGO (c-addr len num-flag) c-addr is the buffer initialization address, and len is its length. The parameter or input parameters for each algorithm can be swallowed, although a key is usually passed for initialization. flag (flag) is FALSE if the initialization occurs successfully. F9 51 SECALGO (c-addr? Len c-addr2 num-flag) When c-addr1 is the input data buffer for computation, and len is its length. c-addr2 is the output buffer for storage of the result. flag (flag) is FALSE if the calculation occurs successfully. Terminal Services 1. 7.9. Terminal Services F9 58 POWERLESS (- flag) Returns FALSE if there is enough energy to complete the current transaction. 1. 7.10 Database Service The following symbols provide a mechanism to manage database. F9 61 DBMAKECURRENT (a-addr -) Performs the database whose DPB is in a-addr as the current database. F9 62 DBSIZE (- len) Returns the size of the log buffer that the window provides over the current record of the current database. F9 63 DBFETCHCELL (nutrii - nup ^) Returns the value of 32 bits pum2 of the cell in the octet offset aligned by pu cell! in the current record of the current database. F9 64 DBFETCHBYTE (pum-char) Returns the value of a char octet from the octet offset num in the current record of the current database. F9 65 DBFETCHSTRING (pum len - addr len) Returns the sequence parameters addr and len in the octet sequence in the pum offset and with len length in the current record of the current database F9 66 DBSTOR? C? LL ( pu! num2 -) Stores the value of 32 bits pu! to the cell in the aligned displacement of cell pum2 in the current record of the current database and update the database record. F9 67 DBSTOREBYTE (char pum -) Stores the value of 1 octet charx to the octet in the pum offset in the current record of the current database and updates the database record.

F9 68 DBSTORESTRING (addr lenx num len2-) Stores most len2 octets in the octet sequence in addr to move pum in the current record in the current database and updates the database record. If lepj is less than len2, then the destination in the database register buffer is filled with spaces up to len2.

F9 69 DBINITIALIZE (-) Initializes the current database to all zeros and sets the "current" and "available" register numbers of the database (see DBRECNUM and DBAVAIL) to 9. F9 6A DBRECNUM (- U) Returns the current registration number. F9 6B DBCAPACITY (- u) Returns the total number of records that the current database can handle. F9 6C DBAVAIL (- num) Returns the registration number of the next available record in the current file. F9 6D DBADDREC (-) Add a record to the end of the current database, in the registration number provided by DBAVAIL. F9 6F DBSELECT (num -) Selects pum record in the current selected database. 9 70 DBMATCHBYKEY (addr len - flag) Searches the current database for a match in the key field against the sequence specified by addr and len. Len can be shorter than the defined length of the key field for this structure, with the remaining characters compared to blank characters (ASCII 20h). If the match is successful, the match record is updated and flag (flag) is FALSE. This symbol can only be used in an ordered database. F9 71 DBADDBYKEY (addr len - flag) Examines the current database by matching the key field against the sequence specified by addr and len. Len can be shorter than the defined length of the key field for this structure, with the remaining characters being compared with blank characters (ASCII 20h). If the match succeeds, the match records are updated and flagr (flag) is TRUE (TRUE). If the match does not succeed, a new record is inserted in the correct position in the database and the flag is FALSE. This new record will be initialized except for its soft field which will contain the given key. This symbol can only be used in a database used. F9 72 DBDELBYKEY (addr len - flag) Examines the current database to find a match on the key field against the sequence specified by addr and len. Len can be shorter than the defined length of the key field for this structure, with the remaining characters being compared with blank characters (ASCII 20 h). If the match succeeds, the match record is deleted and the flag is FALSE. The suppression action closes any potential "holes" in a physical implementation by taking the appropriate action by physically repositioning or re-joining the records in a pre-initialized database. This symbol can only be used with an ordered database. F9 73 DBSAVECONTEXT (-) Causes the server to stack in the current context information that includes the current database, the current registration number and any auxiliary information. This server is entitled to use the return stacking of the virtual machine to store context information, and the client software must thus observe the general rules that apply for the use of return stacking. F9 74 DBRESTORECONTEXT (-) Causes the server to re-store the most recently saved context information (see DBSAVECONTEXT). The server is used to use the virtual machine's return stack to store context information, and the client software must therefore observe the general rules that apply for the use of return stacking. 1. 8. Management of TLV The symbols described in this section provide management and access functions to TLV. 1. 8.1. Sequence Processing Support F9 78 PLUSSTRING (c-addrx lenx c-addr2 len2 - c-addr2 len3) Stores the sequence in c-addrj for lenx bytes and the end of the sequence in c-addr2 for len2 octets. Return to the beginning of the destination sequence (c-addr2) and the sum of the two lengths (len3). There must be space at the end of the destination chain to retain both sequences. F9 79 CPLUSSTRING (char c-addr len - c-addr len + 1) Stores the char character at the end in the sequence in c-addr for len octets. Return to the beginning of the destination sequence (c-addr) and the length of the resulting sequence (len plus 1).

There must be space at the end of the destination chain to retain the additional character. F9 7A MINUSTRAILING (c-addr lenx - c-addr len2) If len is greater than zero, len2 is equal to lenx minus the number of spaces (ASCII 20h) at the end of the character of the sequence specified by c-addr len¿ . If lenx is zero or the complete sequence consists of spaces, len2 is zero. F9 7B MINUSSERS (c-addr lenx - c-addr len2) If len is greater than zero, len2 is equal to lenl t minus the number of null spaces (ASCII Oh) at the end of the character sequence specified by c-addr len-,. Yes len? is zero or the complete sequence consists of null characters, len2 is zero.

F9 7C STORECOUNT (char c-addr-) Stores the char number to the octet in c-addr. Generates an extraction code STRING_TOO_LARGE if char is greater than 255. 1. 8.2. Access to the TLV Intermediate Memory F9 80 TLV (num - c - addr len fmt) Returns the access parameters for TLV whose label is pum. This can lead to the extraction of an UNDEFINED_TLV code. F9 81 TLVFETCH (c-addrx lenx fmt-num c-addr2 len2) 5 Returns the contents of the internal TLV memory according to its TYPE field which is eight bits less than fmt. The codes of type 0 and 2 return numbers to the stack, while the others return sequence pointers. The address returned by the type 3 code fields is temporary and should be moved immediately to a more permanent position. The len2 returned for sequences is the same as the last one stored in the buffer. F9 82 TLVSTORE (num c-addr2 len2 fmt c-addrx lenx c-addr2 len2 fmt -) Sets the contents of the internal TLV buffer according to its TYPE field in its eight lower octets of fmt. The codes 0 and 2 of type take the numbers in the stack, while the others take the sequence pointers. This action will adjust the analyzed status bit to this TLV. F9 83 TLVBITFETCH (c-addr - flag) Returns the masking results of the content of the internal TLV buffer that is referenced by the sequence in c-addr against the value field in that position.

This can generate an activation code UNDEFINED_TLV. The flag will return TRUE if all the bits defined in the mask are in the internal memory. Otherwise, it returns, FALSE. Only the octets covered with the shortest of the two positions are verified. F9 84 TLVBITSTORE (flag c-addr -) Adjusts the contents of the internal TLV buffer that is referenced in the sequence in c-addr based on the value field in that position. If flag is FALSE (0), then all the bits defined there will be inactivated. Otherwise, everyone will be activated. 1. 8.3. TLV processing F9 85 PARSETLV (c-addr len -) Process len bytes in c-addr for TLV sequences. This can generate an activation code UNDEFINED_TLV. Each Tag field (tag) found will replace the Lengh (length) field of octets from its Valué field (Value) in its internal memory and will set its analyzed state bit. When a built Tag (tag) field is found, all internal TLV buffers that have been defined as associated with it are deleted before the Valué field (value) is analyzed for TLV sequences. No exception will be generated if a TLV is found in a constructed template that has not been defined as associated. F9 86 PLUSDOL (c-addrx lenx c-addr2 len2 - c-addr2 len2) Process len bytes in c-addrx for the Tag and Lengh fields. This can generate an activation code UNDEFINED_TLV. Each Tag field found will place Length field octets from its internal buffer in a Valué field at the end of the output sequence in c-addr2 for len2 octets. The return to the beginning of the destination sequence (c-addr2) and the sum of the two lengths (2in3). You must make space at the end of the output sequence to retain both sequences. F9 87 PLUSTLV (c-addr lenx num - c-addr len2) Adds the TLV sequence whose Tag is pum to the end of the output string in c-add for lenx octets. This can generate an activation code UNDEFINED_TLV. The Tag fields, Lenght and Valué are formatted according to the TLV rules based on the data in their internal memory. The return to the beginning of the destination sequence (c-addr) and the sum of the two lengths (lep2). There must be space at the end of the output sequence to retain both sequences. F9 89 TLVSTATUS (fmt - num char) Decodes the status of the TLV access fmt parameter. The returned pum is the 0- format indicator and the bits in the returned char have the following significance, where bit 0 is the least significant bit: 1. 8.4. Access to the TLV Sequence F9 8A STOREBCD (u c-addr len -) Stores the number u as a binary coded decimal sequence in a sequence in c-addr for lep bytes. The number is formatted with each digit representing 4-bit quartets in the output sequence. The front quartets will be filled with 0 if necessary. The most significant part of the number will be truncated if it is not large enough to hold all the digits. F9 8B FETCHCD (c-addr len - u) Extracts the number u of the binary coded decimal sequence in c-addr for len octets. The number is formatted with each digit representing 4-bit quartets in the input sequence.

A DIGIT_TOO_LARGE exception is triggered if any quartet is not a valid BCD digit. F9 8C STOREBN (u c-addr len -) Stores the number u as a binary number in the sequence in c-addr for len octets. The most significant octet of the number is stored first. The front octets will be filled with 0 if necessary. The most significant part of the number will be truncated if it is not large enough to hold all octets. F9 8D FETCHBN (c-addr len - u) Extract the number u as a binary number of the sequence in c-addr for len octets. The most significant octet of the number is extracted first. If there are more than 4 octets of data in that position, the most significant octets will be lost. F 8E STORECN (c-addrx lenx c-addr2 len2 -) Stores the number in c-addr! for lenx bytes as a compressed number in the sequence in c-addr2 for len2 octets. The number is formatted with each character representing a 4-bit quartet in the output sequence. The final quartets will be filled with F if necessary. The number will be truncated if len2 is not large enough to retain all the characters (len2 <[len1 + l] / 2). An activation code DIGIT_TOO_LARGE will be generated if a character in the input sequence is not a number. F9 8C FETCHCN (c-addrx lenx-c-addr2 len2) Extract a sequence to the temporary position c-addr2 for len2 octets that represent the number compressed in the sequence in c-addrx for 2enx octets. The number is formatted with each character of the output sequence representing a 4-bit quartet in the input sequence. The output sequence will end when a quartet is found with all the octets placed at the end of the sequence. An activation code DIGIT_T00_LARGE will be generated if a quartet in the input sequence is not a number. The output sequence must be moved to a more permanent position immediately. F9 90 TLVFETCHNAME (c-addrx - c-addr2 num) Analyzes the TLV sequence in c-addr for a Tag field. Return the address c-addr2, which is Tag, and the pum of the Tag field. F9 91 TLVFETCHLENGTH (c-addrx - c-addr2 len) Analyzes the TLV sequence in c-addr for a Length field. Return the address c-addr2, which is passing the Length field, and the len contained in that field. 1. 9 Module Management The following symbols provide storage and execution of EPICode modules in the virtual magic.

F9 AO EX? CUT? MODULE (c-addr len-flag) A module is loaded from the module directory using the AID specified by c-addr len. The CANNOT_LOAD_MODULE exception is triggered if an error occurs. The flag is TRUE (TRUE) if the module is not found, FALSE if it is "loaded successfully". F9 To the INITMODULEBUFFER (-) Prepare for the adguisition of a new module. F9 A2 MODULEBUFFERAPP? ND (c-addr len -) Attaches the contents of the buffer defined by c-addr and len to the module adguis- tion buffer. The CANNOT_ADD_TO_MODULE exception is activated if the module buffer has not been prepared, or if the buffer capacity of the module is exceeded. F9 A3 REGISTERMODULE (c-addr len -) Registers the module buffer in the module directory under the provided EPICode AID, specified by c-addr len. The resources associated with handling the module buffer are released automatically. F9 A4 RELEASEMPDUL? BUFFER (-) Free the resources used in the internal memory of the internal module. This is regulated if a premature loading of a module by the application must be completed without the module registration in the module directory. F9 A5 DELETEMODULE (c-addr len-flag) Deletes the module whose AID is specified by c-addr len from the module directory. The flag is zero if the operation succeeds. F9 A6 MODULEINFO c-addrx lenx - c-addr2 len2 flag) Returns "public" information in the module which is registered in the module directory under the AID specified by c-addr! lenx flag (flag) is zero if the operation is successful and the data in c-addr! they are valid. The structure of the buffer returned by this symbol is defined by module header information. Only tickets EPF_VER to EPF_ENTRY are returned by this function. F9 A7 LOADCARDMODULE (a-addr-) Load the module in a-ddr. a-ddr is the address of the header for an EPICode module supplied from the card in internal storage. The BAD__CARD_MODULE exception is activated if the module violates any precondition for loading the card module. F9 A8 MODUL? SCHANGED (- u) Returns a value with u indicating whether the modules have changed. Bits 0 to 7 define which module class has been registered in the module directory since the last execution of this symbol. For example, a module registered with an initial AID octet which is F4 will set bit 4 in the return state. Bits 8 through 31 are reserved for future expansion. 1. 10 Management of Extendable Memory The following symbols provide access to an extendable "rubber band" memory of the linear memory in the data space provided and handled by the virtual machine.

F9 BO EXTEND (len - a - addr) Extends the "rubber band" buffer by len cells, returning the address aligned with the a - addr cell of the first cell in the assigned buffer. ZERO EXTEND returns a pointer to the next unassigned cell. An OUT_OF_MEMORY exception is activated if there is insufficient available memory. F9 Bl BEXTEND (len - c - addr) Extends the "rubber band" buffer by lep bytes, regression of the c - addr address of the first octet in the assigned buffer. ZERO BEXTEND returns a pointer to the next unassigned octet. An OUT_OF_MEMORY exception is activated if there is insufficient available memory. F9 B2 RELEASE (addr -) Releases the storage acquired through EXTEND or BEXTEND, adjusting the "free pointer" to addr. If addr is invalid (before the start of the rubber band buffer, or beyond the current "free pointer"), an ANS -9 exception (invalid memory address) is triggered.

Additional Symbols F9 BO DSCHECK (a - flagr) Verify that there are at least u cells of retentive data in the data stack. Return FALSE (FALSE) if this is the case, otherwise, TRUE (TRUE). F9 Bl RSCHEK (u - flag) Verify that there are at least u cells of retentive data in the return stack. Return FALSE (FALSE) if this is the case, otherwise, TRUE (TRUE). 1. 11 Security Commands The processing of the security algorithm can take several seconds in some terminals. The present invention includes that the present single SECALCGO instruction can be carried out on the start and completion components to facilitate use with multi-tasking implementations. This is under investigation, and the following proposals are made as an alternative to SECALGO. F9 56 SECALGOBEGIN (c-addr! Leni c-addr2 pum-flag) This performs a count using the pum-type algorithm. c-addr! is the input data buffer for computation, and len is its length, c- addr2 is the output buffer for storage of the result. This function returns a flag (flag) indicating FALSE if the count can be started successfully. F9 57 SECALGOEND (isr -) This function returns an ior indicating: 0 = successful completion; -1 = computation still in progress; l = failed computation.

Exception codes This section includes all the codes used as arguments for the handling of the standard exception of the THROW function (ACTIVATION). The following table shows the ANS Forth codes used in EPIC cores.

Claims (10)

1. CLAIMS 1. A transaction management system for executing transactions between a first device and a second device, the first and second devices are adapted for communication with each other and at least one of the first and second devices being an integrated circuit card, the system characterized: at least one input / output device; a portable virtual machine for interpreting a computer program in the first device, the virtual machine comprises a virtual microprocessor and an impeller for at least one input / output device; and a means of execution that responds to the program interpreted to execute the program.
2. 2. A terminal comprising a first device for carrying out a transaction with a second device, at least one of the first and second devices is an integrated circuit card, characterized in that it comprises: a portable virtual machine that interprets a computer program in a first device, the portable virtual machine comprises a virtual microprocessor and an impeller for at least one input / output device, an execution means that responds to the program interpreted to execute the program.
3. 3. A portable, self-contained smart card, including a first device for carrying out a transaction with a second device, the smart card is characterized in that it comprises: a portable virtual machine that interprets a computer program, the virtual machine comprises: a virtual processor and an impeller for at least one input / output device.
4. 4. The system according to claim 1 or a terminal according to claim 2, or a smart card according to claim 3, characterized in that the machine instructions of the virtual machine are a set of symbols, the symbols are codes of adapted octets.
5. 5. The smart card according to claim 3 or 4, characterized in that it also comprises a computer program stored on a smart card, the virtual machine interprets the computer program and a means of execution that responds to the interpreted program to execute the program.
6. 6. The system or terminal according to claim 4, or the smart card according to claim 5, characterized in that the computer program is written as a stream of symbols that is 5 select from a set of symbols and data in corresponding lines.
7. 7. The system or the terminal or the smart card according to claim 6, characterized in that 10 the symbol stream is transported in a module, a module includes the symbol stream together with the corresponding online data necessary for module execution.
8. 8. The system or terminal or smart card 15 according to claim 7, characterized in that the module also includes an indication of the memory requirements for execution of the module.
9. 9. The system or terminal or smart card 20 according to claim 8, characterized in that the virtual machine also includes a means for loading the module and interpreting the symbols therein.
10. 10. The system or terminal or smart card according to claim 9, characterized in that the means for loading and interpreting read the symbols in the module and an exception is extracted if a symbol is read which does not belong to the set. eleven'. The system or the terminal or the smart card according to any of claims 7 to 10, characterized in that the virtual machine includes a read / write logical address space having a store for at least the module, the module includes a indication of the amount of read / write logical address space necessary for its execution; and the virtual machine also includes a means for assigning, in the loading of the module, an amount of read / write logical address space-according to the indication, the assigned read / write logical address space has defined and protected limits . 12. The system or the terminal or the smart card according to claim 11, further characterized by a means for designating the allocated amount of logical address space for writable read before the termination of the module. 13. The system or the terminal or the smart card according to any of claims 9 to 12, characterized in that the second device includes a means for providing at least one program instruction capable of modifying at least the execution time behavior of the device. Computer program; and after the means for loading and interpretation has loaded the module and while the module is running, the means for loading and interpreting loads and interprets at least one program instruction dependent on a predefined security condition; and the execution means responds to the loaded program instruction as interpreted by the virtual machine and executes the computer program with the modified behavior '. 14. The system or terminal or smart card according to claim 13, characterized in that the security condition is provided by a function. 15. The system or terminal or smart card according to any of claims 9 to 14, further characterized by comprising a read / write logical address space that includes at least one database that includes at least one record , the module includes an indication of the amount of read / write logical address space initialized necessary for the execution of the module; the loader assigns the required amount of logical address space not initialized according to the indication; and a means to access a record in the database, the record in the database is only accessible through the module, and the means of access provides a window on the current record of the database and copies the record in a proportion of the read / write logical address space not initialized, addressable by the application program. 16. A transaction management system characterized in that it comprises: a first device and a second device, the first and second devices are adapted for communication with each other and at least one of the first and second devices being an integrated circuit card; the second device includes means for providing at least one program instruction capable of at least modifying the runtime behavior of a computer program in the first device; the first device includes a virtual machine, the virtual machine comprises means for loading and interpreting the computer program, the means for loading and interpreting being further adapted to load and interpret at least one program instruction dependent on a predefined security condition after the means to load and interpret have the computer program loaded and while the computer program is started; and means of execution to execute the load and interpret the computer program with modified behavior in response to the program instruction loaded and interpreted. 17. A terminal characterized in that it comprises a first device for carrying out a transaction with a second device and at least one of the first and second devices being an integrated circuit card, the second device includes means for providing at least one program instruction capable of least modify the runtime behavior of a computer program in the first device; the terminal characterized in that it comprises the first device that includes a virtual machine, the virtual machine comprises means for loading and interpreting the computer program, the means for loading and interpreting being further adapted to load and interpret at least one program instruction dependent on a pre-defined security condition, then the means to load and interpret have the computer program loaded and while the computer program is booted; and the means of execution for executing the load and interpreting the computer program with the modified behavior in response to the program instruction loaded and interpreted. 18. A portable, self-contained smart card, including a first device for carrying out a transaction with a second device, the second device includes means for providing at least one program instruction capable of at least modifying the execution time behavior of a program of a computer in the first device, the smart card characterized in that it comprises: the first device includes a virtual machine, the virtual machine comprises means for loading and interpreting the computer program, the means for loading and interpreting, being further adapted to load and interpret the minus a program instruction dependent on a predefined security condition after the means for loading and interpreting have the computer program loaded and while the computer program is booted; and execution means for executing the loaded and interpreted computer program with the modified behavior in response to the program instruction loaded and interpreted. 19. A system according to claim 16 or a terminal according to claim 17 or a smart card according to claim 18, characterized in that the security condition is provided by a function. 20. The system or terminal or smart card according to claim 19, characterized in that at least one program instruction is a first program instruction and the first device includes a second program instruction capable of at least modifying the execution time behavior of the program. computer program, the first program instruction includes a reference of the second program instruction; and the means for loading and interpreting are responsive to the reference to loading the second program instruction, the executing means executing the computer program with the modified behavior as determined by the second program instruction. 21. The system or terminal or smart card according to claim 20, characterized in that the computer program and the first and second instructions are written in terms of a corresponding online symbol and data stream, each symbol being an adapted byte code selected of a set of adapted octet codes. 22. The system or terminal or smart card according to claim 21, characterized in that the virtual machine carries the stream of symbols and data in the line of the first and second program instructions in the symbol stream of the computer program. 23. The system or terminal or smart card according to claim 21 or 22, characterized in that at least the symbol stream of the computer program and at least the second program instruction are each transported in a module, each module includes the relevant stream of symbols together with the corresponding online data required for the execution of the module. 24. The system or terminal or smart card according to claim 23, characterized in that the module also includes an indicator of the memory required for the execution of the module. 25. The system or terminal or smart card according to claim 23 or 24, characterized in that the computer program module also includes a unique list of at least one modifiable connector, at least one connector that defines the position in the symbol stream and Online data from the computer program module, in which the virtual machine carries the first program instruction. 26 '. The system or terminal or smart card according to claim 25, characterized in that at least one modifiable connector in the computer program module contains an execution that leads to an absent behavior. 27. The system or terminal or smart card according to claim 26, characterized in that the executing means executes the computer program with the absent behavior if the predefined security condition does not allow loading of at least one program instruction. 28. The system or terminal or smart card according to any of claims 23 to 27, characterized in that the virtual machine includes read / writable logical address spaces, the module includes an indication of the amount of read / writable logical address space. necessary for its execution and; the virtual machine also includes means for assigning, loading the computer program module, an amount of logical read / writable address space according to the indication, read / writable logical address space allocation having defined limits and protected; and means for unassigning the amount of read / write logical address space at the termination of the computer program module. 29. The system or terminal or smart card according to any of claims 23 to 28, characterized in that it also comprises read / write logical address space that. includes at least one database that includes a plurality of registers, the module includes an indication of the amount of read / write logical address space not initialized necessary to execute the module; means for assigning loading the required amount of logical address space uninitialized according to the indication; and means to access a record in the database, the records in the database are only accessible through the module, the accessed means provide a window in a current record of the database and to copy the record in a portion of the uninitialized read / write logical address space addressed by the application program. 30. The system or terminal or smart card according to any of claims 16 to 27, characterized in that the security condition includes means for verifying at least the origin and integrity of data and the program instructions in the second device. 31. A transaction system for executing transactions between a first device and a second device, the system characterized in that it comprises: a virtual machine for interpreting a set of adapted octet code symbols applied thereto; the virtual machine includes a virtual processing unit and a read / writable logical address space; at least one first application program including an indication of the amount of read / write logical address space necessary for its execution, at least one first application program being written as a stream of symbols selected from the set of symbols and corresponding online data; the virtual machine also includes: a loader to load at least a first application program; and means for allocating a first amount of read / writable logical address space specifically for at least a first application program according to the indication, the assigned read / writable logical address space has defined and protected limits. 32. A terminal comprising a first device for executing transactions with a second device, the first device characterized in that it comprises: a virtual machine for interpreting a code symbol set of adapted octets applied to it, the virtual machine includes a virtual processing unit and logical read / writable address space; at least a first application program including an indication of the amount of read / write logical address space necessary for its execution, at least a first application program being written as a stream of symbols selected from the set of symbols and corresponding online data; the virtual machine also includes: a loader to load at least a first application program; and means for allocating a first amount of read / writable logical address space for at least a first application program according to the indication, the assigned read / writable logical address space has defined and protected limits. 33. A portable, self-contained smart card that includes a first device for carrying out a transaction with a second device, the first device characterized in that it comprises: a virtual machine for interpreting a set of adapted octet code symbols applied thereto; the virtual machine includes a virtual processing unit and read / writable logical address space; at least a first application program that. includes an indication of the amount of read / write logical address space necessary for its execution; at least a first application program being written as a stream of symbols selected from the set of corresponding on-line data and symbols; the virtual machine also includes: a loader to load at least a first application program; and means for allocating a first amount of read / writable logical address space specifically for at least a first application program according to the indication, the assigned read / writable logical address space having defined and protected limits. 34. The system according to claim 31 or terminal according to claim 32 or smart card according to claim 33, characterized in that it also comprises means for explicitly designating the first amount of read / writable logical address space at the end of less a program. 35. The system or terminal or smart card according to any of claims 31 to 34, characterized in that at least one of the first and second devices is an ICC. 36. The system or terminal or smart card according to any of claims 31 to 35, characterized in that the first application program also includes a first exclusive list of at least one function, which can be exported to other application programs, further comprises means to manufacture at least one function available to other programs. 37. The system or terminal or smart card according to any of claims 31 to 36, characterized in that the first application program is a first module and the other application programs are other modules, each module includes at least one stream of selected symbols at starting from the set of symbols, corresponding on-line data, a first exclusive list of at least one function to be exported and an indication of the amount of read / write logical address space needed to execute the module. 38. The system or terminal according to claim 37, characterized in that the first module includes a second exclusive list identified at least one second module from which at least one function is being imported, and the charger loaded with at least one second module in accordance with the second list in loading the first module. 39. The system or terminal or smart card according to claim 38, characterized in that the first module is terminated if at least one second module being imported is not being loaded successfully. 40. The system or terminal or smart card according to any of claims 37 to 39, characterized in that the means assigning allocate the first amount of read / writable logical address space in loading the first module and only assigning a second or another amount of read / write logical address space for the first module in a simple extendable buffer, initializing a first address; and in releasing the second amount of read / writable logical address space by means of the first module, the means designating the second amount of read / write logical address space and in addition all locations beyond the first address. 41. The system or terminal or smart card according to claim 40, characterized in that the means that designate assigning the second amount of read / write logical address and all the other locations beyond the first termination address of the first module. 42. The system or smart card according to any of claims 37 to 41, characterized in that the read / writable logical address space includes at least one database that includes at least one register, the module includes an indication of the amount of logical address space of read / writable not initialized necessary to execute the module, and registers in only the database being accessible through the module; the loader that loads the required amount of space / logical address not initialized according to the indication; and means for accessing a record in the database, the access means providing a window in the current record of the database and copying the record in a portion of the uninitialized read / writable logical address space dirigible by the application program. 43. The system or terminal or smart card according to any of claims 34 to 42, characterized in that the means of unassigning delete any amount of read / write logical address space designated at the termination of the first module. 44. A transaction system for executing transactions between a first device and a second device, at least one of the first and second devices being an integrated circuit card, the system characterized in that it comprises: a virtual machine for interpreting a set of adapted byte code symbols applied to it; the virtual machine includes a virtual processing unit and a read / writable logical address space; at least one database includes at least one register and at least one computer program for execution by the virtual machine, the computer program being a module script in terms of a stream of symbols selected from the set and includes an indication of the amount of read / write logical address space not initialized necessary for module execution; a load to load the module and to allocate the required amount of space / logical address not initialized according to the indication; and means to access a record in the database, register in the database only by being accessible through the module and accessible means by providing a window in a current record of the database and copying the record in a portion of the space Logical read / writable uninitialized address can be addressed by the application program. 45. A terminal comprising a first device for executing transactions with a second device, at least one of the first and second devices being an integrated circuit card, the first device characterized in that it comprises: a virtual machine for interpreting a set of interpreted byte code signals applied to it; the virtual machine includes a virtual processing unit and read / writable logical address space; at least one database that includes at least one registry and at least one computer program to run through the virtual machine, the computer program being a module script in terms of a stream of signals selected from the set and including an indication of the amount of read / write logical address space not initialized necessary for the execution of the module; . a load to load the module and to designate the required amount of space / logical address of not initialized according to the indication; and means to access a record in the database, register in the database only by being accessible through the module, and the accessed means by providing a window in the current record of the database and copying the record in a portion of the database. uninitialized logical / writable address space that can be addressed by the application program. 46. A smart card, self-contained, including a first device for carrying out a transaction with a second device, the first device characterized in that it comprises: a virtual machine for interpreting a set of octet code signals adapted from it; the virtual machine that includes a virtual processing unit and read / writable logical address space; at least one database that includes at least one register and at least one computer program to run through the virtual machine, the computer program being a module script in terms of a stream of symbols selected from the set and including an indication of the amount of read / write logical address space not initialized necessary to execute the module; a load to load the module and to assign the required amount of space / logical address not initialized according to the indication; and means to access a record in the database, register in the. database only being accessible through the module, accessible means by providing a window in a current database record and to copy in the portion of the uninitialized read / writable logical address space dirigible by the application program. 47. The system in accordance with the claim 44 or a terminal according to claim 45 or a smart card according to claim 46, characterized in that the database is exemplified in the first module load. 48. The system or terminal or smart card according to any of the preceding claims 1 to 47, characterized in that the virtual machine is a stacking machine. 49. The system or terminal or smart card, according to claim 48, characterized in that the virtual machine is at least two stacked machines, in which 53. The system or terminal according to claim 52, characterized in that the manual device includes an Integrated Circuit Card (ICC). 54. The system or terminal according to any of the preceding claims 1 to 53, characterized in that the second device comprises an ICC. 55. The system according to any of the preceding claims 1 to 54, characterized in that the first device is a terminal. 56. The system or terminal or smart card according to any of the preceding claims 1 to 55, characterized in that both of the first and second devices include the ICC. 57. The system or terminal or smart card according to any of the preceding claims 1 to 56, characterized in that the transaction comprises at least one execution of the following sequence: a. create a communication link between the first and second devices; b. select from an application that includes a computer program and the associated data set that define the transaction; c. execution of the application; and d. termination of the transaction. 58. The system or terminal or smart card according to any of the preceding claims 1 to 57, characterized in that the transaction is a financial transaction and the system is a financial transaction management system .. 59. An integrated circuit card containing a program instruction capable of modifying the behavior of a boot program in the system according to any of claims 1 to 58, in a terminal according to any of the claims according to any of claims 2 to 58 or an intelligent card according to any of claims 3 to 58. 60. A method for carrying out a transaction between a first device and a second device, at least one of the first and second devices is an integrated circuit card; characterized in that it comprises providing at least one program instruction in the second device capable of at least modifying the runtime behavior of a computer program in the first device; upload and interpret the computer program; load and interpret at least one program instruction dependent on a predefined security condition while the computer program is booted; and executing the computer program loaded and interpreted with the behavior modifier in response to the program instruction loaded and interpreted. 61. A method of carrying out a transaction between the first device and a second device, characterized in that it comprises: interpreting at least one written application program as a stream of octet code symbols selected from a set of symbols and corresponding to on-line data; load at least one application program; designating a first number of read / write logical address spaces specifically for at least one application program according to an indication contained within the application program of the amount of read / write logical address space necessary for its execution; and define and protect the boundaries of the allocated logical / writable address space. 62. The method according to claim 61, further characterized in that it comprises: explicitly designating the first amount of read / writable logical address space in the termination of at least one first application program. 63. A method of carrying out a transaction system between a first device and a following device, at least the first and second devices being an integrated circuit card, characterized in that it comprises: interpreting the symbols in a module written in terms of a current of symbols that are selected from a set of symbols; assigning an uninitialized logical address / space quantity according to an initialization in the module of the uninitialized read / write logical space / address amount necessary for module execution; access a record in a database by providing a window on a current record of the database, records in a database are only accessible through the module; and copying the record into a portion of the uninitialized read / writable logical address space, addressable by the module. 64. A method for carrying out a transaction between a first device and a second device, at least the first device and the second device being an integrated circuit card, characterized in that it comprises: providing a portable virtual machine comprising a virtual microprocessor and a controller for at least one output / input device; interpret a computer program on the first device using a portable virtual machine; and execute the program in response to the interpreted program.