SK176698A3 - Portable, secure transaction system for programmable, intelligent devices - Google Patents

Abstract

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

Description

Technical field

The present invention relates to a system comprising programmable smart devices, such as terminals and integrated circuit cards, as well as a method of operating such cards and terminals including ATMs, personal computers, television payment units, point of sale terminals, medical cards and the like. The invention is particularly suitable for use in conducting financial transactions.

BACKGROUND OF THE INVENTION

Various types of transaction terminals are known, for example financial transactions involving the transfer or exchange of value or transactions of a commercial nature, such as healthcare card transactions or for accessing data in general, such as GSM mobile phone SIM cards. Terminals such as point-of-sale (POS), automatic teller machine (ATM) or GSM mobile phones are known. The real range of products from small handheld devices with simple 8-bit microprocessors such as the Intel 8031/8051 series supplied by Intel Corp. US or ICC cards

- Integrated Circuit Cards) for 32-bit computers running operating systems such as UNIX ™ or Windows NT supplied by Microsoft Corp. USA. Some of these machines interact with users' personal cards, which may be magnetic strip cards, smart cards, or ICCs, which store specific user identification and validation information needed before communication can be initiated between the user and the terminal. Taking! inserts the card into a card reader connected to the terminal, the terminal program permanently stored in the terminal is running and checks the card by checking the user's information to verify it and, if necessary, requesting a password or private number such as PIN

- personal identification number). After validation, the program will normally allow the user to select the execution of the requested services, such as withdrawing cash, checking the current balance. The terminal may stand alone or be connected to a larger computer, either locally or via a telecommunications network. Such terminals are often available 24 hours a day and must be operated with minimal maintenance and a high level of safety.

Such terminals represent significant investments in hardware and are normally not replaced at frequent intervals. Updating the software and programs running on such terminals becomes necessary when new services are offered and must be done safely.

Terminal operating organizations, such as banks, generally require that every update be confirmed. Such an update may be manual or remote, via a private or public communications network, as 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 development, since the software for each terminal must be specifically designed for that type of terminal, and therefore the schemes are quite expensive. In addition to being able to offer the services of all possible organizations offering similar services, such as all banks and monetary institutions, the terminal must be able to process all programs of all organizations. Due to the great mobility of both private and business persons, it is advantageous that all services offered in one country are available at each terminal. This would lead to an unnecessarily large processing capacity and memory size of each terminal. Furthermore, each of these programs must be updated as required. One solution could be to use a small workstation for each terminal connected, for example, to a telecommunications system. Such a system would be capable of indirect processing and could switch to direct processing of unusual transactions or automatic updating of permanently stored programs. For example, a workstation would be required to perform the complex validation and encryption schemes necessary to maintain the security of a system exposed to attack over a public telephone network. With increasing size and complexity, the problem of maintaining safety would also increase.

Even with such a system, there may be problems with version checking. Not all service users of the same organization may have cards appropriate for the latest version of the service. This can occur when multinational organizations introduce or update services at different times in different countries. In WO 96/18979 it has been proposed that the terminals be updated only for the period contained in the personal ICC user. Program instructions representing standard subroutines are stored on the card and can be transferred to the terminal in which they are interpreted. Using an interpreter program in the terminal allows the same card to be used on any terminal containing the interpreter program and therefore executes a transaction independent of the main processor in the terminal. However, no method of safety control is described to exclude possible dangerous sub-programs.

Terminals of the type described above also have a processor containing some form of memory, usually some random access memory (RAM) for running programs and some read only memory (ROM) to store data to be read only, which may include a program for the terminal operating system and a non-volatile read / write memory for storing general data, which may vary. The user's personal data should be kept confidential and therefore there should be no possibility of one user having access to the data of other users who are deceiving accidentally or intentionally. Further, the various memories of the write terminal should not become segmented over time.

Memory segmentation can result in adjacent memory blocks being reduced in size so that certain programs cannot be run. To avoid this problem, some programming languages, such as Java ™, are used to inventory memory space. Inventory free memory is a standard program that attempts to identify data in memory that is no longer required and frees it. Normally, free space inventory is a more reliable way of memory management than a program that directly releases its own stored data. Some consider direct memory allocation or freeing as the largest single source of programming errors in common high-level programming languages, such as C or C ++.

Inventory of vacancies has several disadvantages. First, the inventory of vacancies is a function of the operating system rather than an application-specific function. Therefore, the vacancy inventory does not guarantee that the data of each application is released at the end of each application, but such data may be present for some time until the lack of access triggers the vacancy inventory. Financial transactions require a more secure method of excluding the ability to address private user data. Second, it increases the amount of memory space required for the operating system. Memory may be limited on ICC and some terminals and the use of free space inventory may be a serious disadvantage. As explained above, the terminals are replaced very irregularly, so that very different terminals containing different processor capabilities and memory sizes are normally run concurrently in the system. Older terminals often have very limited capabilities. Although the oldest terminals can be replaced, the demand for improved and more comprehensive services means that the oldest terminals will probably never be replaced so often that some of them will not be delayed in their capabilities. Also, the requirement for compact operating systems that can run on widely different processor types is likely to remain a requirement. Finally, the inventory of vacancies does not free up memory as soon as it would be released using direct release. Also, this can increase the size of the memory required because memory is bound, even if it could be freed.

One safe method of memory management during operation is described in U.S. Patent No. 5,434,999. For example, in accordance with this known method, an interpreter program at the terminal performs systematic checking of any address manipulating instructions in memory to verify that a memory area authorization exists to access requested. This system has the disadvantage that each instruction must be checked in this manner, which significantly slows down processing. Checking the program's operating time is costly.

There is a need for a system providing programmable terminals that allows an application programmer to be used to create software that is portable and neutral to disparate terminals, i. from. independent of the processor used in the terminal and does not need to be type approved for each type or version of the terminal. The permanently stored terminal operating system and application programs are preferably compact, operate fast and meet security conditions. Furthermore, it is advantageous if the application programs can be easily updated, at least so that each user! can receive the expected services independently of the geographical location of the terminal.

It is an object of the present invention to provide a secure transaction management system for transactions and for a method of operating such a system.

Another object of the present invention is to provide secure terminals and ICCs for the transactions and methods of operation of such devices.

Yet another object of the present invention is to provide a device usable for a transaction that can be implemented in small handheld devices such as ICC.

Yet another object of the present invention is to provide a transaction system in which terminals or ICCs can be updated using terminals or ICCs as sources of updating information.

It is another object of the present invention to provide a transaction management system and method of operating a system that provides high security with good operating speed.

SUMMARY OF THE INVENTION

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

at least one input / output device;

a portable virtual machine for interpreting a computer program in said first device, said virtual machine comprising a virtual microprocessor and an exciter for said at least one input / output device, and execution means responsive to said interpreted program for executing said program.

It is preferred that this portable virtual machine be a pushdown machine because this brings operational speed and compactness.

The present invention also provides a terminal that includes a first device for executing a transaction with a second device, at least one of said first or second devices being an integrated circuit card comprising:

a portable virtual machine interpreting a computer program in said first device, said portable virtual machine comprising a virtual microprocessor and an exciter for at least one input / output device and execution means responsive to said interpreted program for executing said program.

The present invention also provides a self-contained portable smart card comprising a first device for executing a transaction with a second device, said smart card comprising a portable virtual machine comprising a virtual microprocessor and an exciter for at least one input / output device.

The present invention also provides a transaction management system comprising:

a first device and a second device, said first and second devices being adapted to communicate with each other, and at least one of said first and second devices being an integrated circuit card;

said second device comprising means for providing at least one program instruction capable of at least modifying the execution time of the computer program in said first device;

said first apparatus comprising a virtual machine, said virtual machine comprising means for loading and interpreting said computer program and said means for loading and interpreting further adapted to load and interpret said at least one program instruction depending on a predefined security condition, then said means for the introduction and interpretation have introduced said computer program, and while said computer program is in operation and execution means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

The present invention further provides a terminal comprising a first device for executing a transaction with the second device and at least one of said first or second device is an integrated circuit card and said second device comprises means for providing at least one program instruction capable of at least modifying the execution time of the computer program in said device. first device. Said terminal comprises:

said first device comprising a virtual machine comprising means for loading and interpreting said computer program, said means for loading and interpreting further adapted to load and interpret said at least one program instruction dependent on a predefined security condition, said means for loading and the computer program is in operation and the execution means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

The present invention provides a self-contained portable smart card comprising a first device for executing a transaction with a second device, said second device comprising means for executing at least one program instruction capable of at least modifying the time execution behavior of a computer program in said first device. Said smart card includes:

said first device comprising a virtual machine comprising means for loading and interpreting said computer program, said means for loading and interpreting further adapted to load and interpret said at least one program instruction dependent on a predefined security condition, after said means for loading and interpreting and wherein said computer program is in operation and execution means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

The present invention also provides a transaction system for executing transactions between a first device and a second device. The transaction system includes:

a virtual machine for interpreting a set of order byte code entitlement symbols used therein, said virtual machine comprising a virtual processing unit and a logical address read / write space;

at least one first application program comprising the amount of read / write logical address space needed to execute it, said at least one first application program being written as a sequence of authority symbols selected from said set of authority symbols and corresponding input data;

said virtual machine also comprising a load program for loading said at least one first application program and means for allocating a first amount of logical address read / write space specifically for said at least one first application program in accordance with said data, said allocated read / write space logical addresses have defined and protected boundaries.

The first device, in accordance with the present invention, may be a personal computer connected to the Internet and operating a scanning standard program. The requirement that each module received by the scan standard program must include an indication of its memory requirements improves the security of the scan standard program and limits the damage that could be caused by any virus contained in the received module.

The present invention provides a terminal comprising a first device for executing transactions with a second device. The first device comprises:

a virtual machine for interpreting a set of order byte code authorization symbols used therein, wherein said virtual machine comprises a virtual processing unit and a logical address read / write space;

at least one application program comprising the amount of space to read / write the logical addresses required to execute it, and a first exclusive list of at least one function that can be transferred to other application programs, said at least one application program being written as a sequence of authority symbols selected from said set of authorization symbols and corresponding input data;

said virtual machine also comprising a load program for loading said at least one first application program and means for allocating a first amount of logical address read / write space specifically for said at least one first application program in accordance with said data, said allocated read / write space logical addresses have defined and protected boundaries.

The present invention may also provide a self-contained portable smart card comprising a first device for executing a transaction with the second device. The first device comprises:

a virtual machine for interpreting a set of order byte code authorization symbols used therein, wherein said virtual machine comprises a virtual processing unit and a logical address read / write space;

at least one first application program comprising the amount of read / write logical address space needed to execute it, said at least one first application program being written as a sequence of authority symbols selected from said set of authority symbols and corresponding embedded data;

said virtual machine also comprising a loader program for loading said at least one first application program and means for allocating a first amount of logical address read / write space specifically for said at least one first application program in accordance with said data, said allocated read / write space logical addresses have defined and protected boundaries.

The system may also provide a transaction system for executing transactions between the first device and the second device, wherein at least one of said first or second devices is an integrated circuit card. The system includes:

a virtual machine for interpreting a set of order byte code entitlement symbols used therein, said virtual machine comprising a virtual processing unit and a logical address read / write space;

at least one database comprising at least one record, and at least one computer program for executing said virtual machine, said computer program being a module written in the form of a sequence of said authorization symbols selected from said set and containing an amount of read / write space for uninitialized logical addresses needed for making said module;

a loader program for loading said module and for allocating a desired amount of uninitialized logical address space in accordance with said data and means for accessing a record in said database,

Λ. *.!.:. ·.

wherein the records in said database are accessible only by said module and said means of access provide a window to a conventional record in said database and copy said record to a portion of a read / write space of uninitialized logical addresses addressable by said application program.

Further, the present invention may also provide a terminal comprising a first device for executing transactions with a second device, wherein at least one of the first and second devices is an integrated circuit card. The first device comprises:

a virtual machine for interpreting a set of order byte code entitlement symbols used therein, said virtual machine comprising a virtual processing unit and a logical address read / write space;

at least one database comprising at least one record and at least one computer program for execution by said virtual machine, said computer program being a module written in the form of a sequence of authority symbols selected from said set and containing an amount of read / write space for uninitialized logical addresses needed to execute said module;

a loader program for loading said module and for allocating a desired amount of uninitialized logical address space in accordance with said data and means for accessing a record in said database, wherein records in said database are accessible only through said module and said means of access provide a window to a common a record in said database and copy said record to a portion of said space to read / write uninitialized logical addresses addressable by said application program.

The present invention may provide a self-contained portable smart card comprising a first device for executing a transaction with the second device. The first device comprises:

a virtual machine for interpreting a set of order byte code entitlement symbols used therein, said virtual machine comprising a virtual processing unit and a logical address read / write space;

at least one database comprising at least one record and at least one computer program for execution by said virtual machine, said computer program being a module written in the form of a sequence of authority symbols selected from said set and containing an amount of read / write space for uninitialized logical addresses needed to execute said module;

a loader program for deploying said module and for allocating a desired amount of uninitialized logical address space in accordance with said data and means for accessing a record in said database, the records in said database being accessible only by said module and said access means providing a window to a common a record in said database and copy said record to a portion of said space to read / write uninitialized logical addresses addressable by said application program.

The present invention also provides a method of executing a transaction between a first device and a second device, wherein at least one of said first or second devices is an integrated circuit card comprising:

providing at least one program instruction in said second device capable of at least modifying the time execution behavior of the computer program in said first device;

introducing and introducing an instruction to the condition, operation and interpretation of said computer program, and interpreting at least one program dependent on a predefined security while said computer program is in producing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction.

The present invention also provides a method of executing a transaction between a first device and a second device comprising:

interpreting at least one application program written as a sequence of byte code entitlement symbols selected from a set of authority symbols and corresponding embedded data;

implementing at least one application program;

allocating a first size of logical addresses specifically a read / write space for said at least one application program in accordance with the data contained within said application program about the size of the read / write space required to execute it and defining a space for reading and writing boundaries mentioned logical addresses.

assigned

This method combines the use of an interpretation program with allocation and, optionally, with direct memory release. This provides a blend of flexibility to provide on-the-fly guarantees after the application program has been fully checked at the compilation stage. This reduces the damage that could be caused by viruses in the received application modules.

The present invention also includes a method of establishing a transaction system between a first device and a second device, wherein at least one of said devices is an integrated circuit card, comprising:

interpreting the authorization symbols in a module written in the form of a sequence of said authorization symbols selected from a set of authorization symbols;

allocating an amount of uninitialized logical address space in accordance with the information in said module about the amount of space to read / write the uninitialized logical address needed to make said module;

accessing a record in the database by providing a window to a conventional record in said database, wherein records in said database are accessible only by said module and copying said record to a portion of said space to read / write uninitialized logical addresses addressable by said module.

The present invention also includes a method of executing a transaction between a first device and a second device, wherein at least one of said devices is an integrated circuit card comprising:

providing a portable virtual machine comprising a virtual microprocessor and driver for at least one input / output device;

interpreting a computer program in said first apparatus using said portable virtual machine and said execution program in response to said interpreted program.

It is in accordance with the present invention to provide a transaction system that preferably comprises a virtual microprocessor. Preferably, each module includes a set of virtual address spaces guaranteed to be separated from any other virtual address space. The portable virtual microprocessor also advantageously protects access to reported resources such as various stacks and databases. Preferably, the minimum protection is memory controlling the boundaries of access to the data space for reading and writing, and an absolute prohibition of writing to the code space. In addition, it is preferred to control the filling and overflow of data and return stacks. Advantageously, to what any other module just does not exist a path that could secure a portable can only be accessed. Preferably allow access (virtual microprocessor does not pass through) through the functions provided by the module. Preferably, the modules cannot transmit data in the usual sense, the modules can advantageously transmit only functions. Advantageously, logical boundaries prohibit data space leakage. In other words, all this data owned by the module is preferably strictly private. This constraint is advantageously ensured at compile time, as well as at module time, the compartments have separate spaces that the address of some data inside is completely meaningless except for it. The module can advantageously transfer only the set to pending data except traffic access, addresses, means a module owning module.

grabbing to start or stop a behavior. Preferably, the modules of good behavior will be in very good operation, while modules of not so good behavior will suddenly be terminated by exceptions directly inserted by the virtual microprocessor when an illegal operation is attempted.

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

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a schematic representation of a terminal in accordance with the present invention.

Fig. 2 is a schematic representation of an ICC in accordance with the present invention.

Fig. 3 is a schematic flow diagram of a module development and embodiment process in accordance with the present invention.

Fig. 4 is a schematic representation of a portable virtual microprocessor in accordance with the present invention as implemented in a terminal.

Fig. 5 is a schematic representation of a portable virtual microprocessor in accordance with the present invention.

Fig. 6 is a schematic representation of modules loaded in memory in accordance with the present invention.

Fig. 7 is a schematic illustration of a method of obtaining access to a database record in accordance with the present invention.

Fig. 8 is a schematic representation of a plug and socket operation in accordance with the present invention.

Fig. 9 is a flow chart of the process of introducing a module according to the present invention.

Fig. 10 is a flow chart of a process of embodiment of a module according to the present invention.

Fig. 11 is a flow chart of a plug-in process according to the present invention.

Fig. 12 is a flow chart of a process for introducing a card module in accordance with the present invention.

The Appendix lists the authorization symbol and standard exception codes.

DETAILED DESCRIPTION OF THE INVENTION

The present invention will be further described with reference to the specific drawings and certain embodiments, but the invention is not limited thereto, but only by the claims. The figures are only schematic and not limiting. The present invention will be further described with reference to financial transactions, but the invention is not limited thereto. The present invention will be further described in particular with reference to the terminal, but the present invention also includes providing a portable virtual microprocessor on any suitable device, such as a personal computer (PC), ICC or combined ICC and interface as described in WO 94 / 10657, which is incorporated herein by reference.

The general connecting technical concept on which the invention is based is portability combined with data security and runtime guarantees in a transaction system that are independent of the target implementation, provided that compile time checks pass successfully. This concept can be achieved by one or more of the following basic features: using a virtual machine as an interpreter program containing an exciter for an input / output device (1/0) in a virtual machine such that application programs have a common interface with input / output (1/0) devices, and are therefore portable across very different environments containing the amount of memory in the application program and allocating memory in accordance with the data, directly releasing memory and providing a secure path for receiving and transmitting data to and from application programs and / or databases.

Fig. 1 is a schematic representation of a terminal 1 in accordance with the present invention. The terminal 1 typically comprises a central processing unit (CPU) 2 which is connected to the memory 4 and the input / output (1/0) devices 6 via the bus 3 for communication in two directions. 1/0 of the device 6 may be a data entry keyboard and a shade 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 display messages or prompts. One of the 1/0 of the device 6 may be a card reader 7 by means of which it is inserted into a receiver where ICC 5 can be read, the grooves in the reader 7. The actual shape of the terminal can vary substantially, for example it can be a point of sale terminal hall) and can include processors from Intel 8051 to Pentium ™. Furthermore, it is not necessary for the terminal 1 to be entirely located in a single location of a different part of the terminal, such as a card reader 7, a device 1/0 like a keyboard; and the display and the processor may be located in different positions and connected by cables, likewise or may be part of or may be wireless or local area networks by telecommunication networks.

be connected

Fig. 2 is a schematic representation of ICC 5 in accordance with the present invention. However, the present invention is not limited to this. The ICC 5 comprises at least one input / output gate 10 (1/0) and some non-volatile memory, such as non-volatile memory, which can be provided, for example, by an EEPROM 15 connected to the 10 I / O gateway via bus 17 or random access memory (RAM). random access memory) with battery support. The I / O gate 10 can be used to communicate with the terminal 1 via a card reader 7. An integrated circuit card is a card into which one or more integrated circuits are inserted to perform at least memory functions. The ICC 5 may optionally be a self-contained portable smart card and may include a read / write working memory, for example, a volatile memory provided by RAM 14, and a central processor 12 as well as all necessary circuits, so that the ICC 5 may function as a microprocessor , for example, as a permanent memory 13 for storing the code, a sorter 16, and a connection to the card reader 7 for receiving the voltage sources Vss and VDD. In accordance with the present invention, the ICC 5 may be used as a bank card, credit card, debit card, electronic wallet, health card, SIM card and the like.

The present invention provides an integrated circuit-controlled transaction management system for executing a transaction between ICC 5 and a terminal 1 connected or not connected to a central unit, the transaction comprising at least one embodiment of the following sequence:

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

2. Performing a compatibility check to ensure that ICC 5 and terminal 1. are mechanically and electrically compatible;

3. Selecting an application comprising a selection of a computer program and an associated data set that defines the transaction in the form of the specific combination of ICC 5 and terminal 1 concerned;

4. Execution of the application;

5. Termination of the transaction, which optionally includes interrupting the communication link between ICC 5 and terminal 1; this will use the interpretation program to execute the application either on ICC 5 or at the terminal, or both. A transaction is an exchange of data between at least two or more devices and is not specific to commercial financial transactions in accordance with the present invention. Such a system is known from PCT / BE 95/00017. ICC 5 can only be an ICC memory, i. from. it does not include a processor 12 and the ICC 5 executes the transaction as determined by the terminal 1. Alternatively, the ICC 5 may be closed by a portable smart card and the transaction may be determined by the terminal 1, the ICC 5, or both. In accordance with the present invention, ICC 5 may include program code to safely increase terminal processing. ICC 5 can be one or more maintenance cards that can be used to update applications stored in the terminal.

In accordance with the present invention, the software is operated in terminal 1 and, optionally, in ICC 5 in the form of a virtual machine. A virtual machine (VM), in accordance with the present invention, directly provides a theoretical or virtual microprocessor with standard characteristics that define addressing, stack usage, register usage, address space, I / O device addressing, and so on. in a generally applicable manner. A core for each particular type of CPU used in terminal 1 or ICC 5 is written to cause the corresponding processor 2, 12 to emulate a VM. A specific aspect of the present invention is that the VM core provides drivers for 1/0 devices and all low-level CPU logic and arithmetic functions, flow control, and time manipulation. The existence of 1/0 drivers in the VM has the advantage that any program written for the VM in accordance with the present invention addresses a standard virtual 1/0 device. Implementing the VM in a particular CPU then provides physical I / O devices connected to terminal 1 or ICC 5 to behave similarly to the addressed virtual 1/0 devices. The VM in accordance with the present invention is very compact and has been successfully implemented on a Siemens SLC044CR chip (an INTEL 8051 family derivative) that can be included on ICC 5. The VM in accordance with the present invention allows for a high degree of standardization over very different CPU and I / O and simplifies program portability, testing and certification. According to this application, such a VM will be described as a portable virtual machine 20. The portable virtual machine 20 comprises a virtual microprocessor and an exciter for a 1/0 device. The VM 20 provides logical and arithmetic functions and memory addressing, and at least one input / output device. A portable VM 20 in accordance with the present invention provides program portability through various terminals 1 and card 5 by treating terminal programs and / or cards as intermediate code of the compiling program. This code consists of a stream of byte codes that are named Authorization Symbols. Terminals 1 or ICC 5 then process this code by interpreting it or by other means, such as natural code compilation. Advantageously, the interpretation of the entitlement symbol by the virtual machine can be accomplished by one of three methods: directly interpreting the instructions of the virtual machine, translating the language of the virtual machine into a directly executable transition form, or compiling it at the right time into actual code for the target CPU. The latter two methods offer improved operation at moderate cost complexity. Authorization symbols are provided in a kit that can be viewed as a set of machine instructions for VM 20.

Application programs in accordance with the present invention are embodied as modules that may include a list of authority symbols as an execution code. In accordance with the present invention, there are two basic types of modules: feasible modules having an entry point that is directly called by the virtual machine 20 when the module is loaded; and library modules that act as resources for other modules by providing feasible procedures that can be individually performed by intermodal calls.

The set of entitlement symbols in accordance with the present invention includes, first, a set of instructions of the virtual machine 20 that provides instructions expected for the general processing language and are required to efficiently execute programs, and secondly, entitlement symbols that provide what is normally called an operating system function. In terminals 1 or card 5, operating system functions in accordance with the present invention include such specific functions as I / O drivers, for example, for displays or keyboards, and in terminals or card 5, system functions may also include control of communication and data object transmission through gateways. I / O as well as cross-module access and access control mechanisms. The authorization symbols are preferably provided for the VM operating system, for container handling, for drawer handling, for checking e.g. exceptional handling, for sockets containing their access rights, for I / O device access, for time manipulation, for language and message manipulation, for I / O reader handling, e.g. ICC, magnetic tape and modem card handling, black record management, security algorithms, terminal services, database services, data object manipulation, e.g. for TLV manipulation, module manipulation and extensive memory manipulation.

Single-byte entitlement symbols are referred to as primary entitlement symbols; these refer to primitive instructions, such as those commonly found in any set of instructions. Multi-byte authorization symbols are referred to as secondary authorization symbols and are used for rarely used services. The complete set of authority symbols for VM 20 is given in the Appendix. As schematically shown in FIG. 3, the application program is written on the main PC development system 70 and is debugged and the type is approved in a suitable high-level language such as Forth, C, Pascal, etc. Then, the source code of the program is compiled by the entitlement symbol compiler 71 into a sequence of entitlement symbols. This sequence of authority symbols is separately combined with other data (corresponding embedded data) required for the program and header and is enclosed in the module delivery file to form the module 72, preferably in a standardized format of the delivery module. If the module contains executable entitlement symbols, it is supplied in an executable program format. It is a particular aspect of the present invention that the executable modules contain not only a sequence of authority symbols, but also all corresponding embedded data (closed). Another particular and separate aspect of the present invention is that the modules in accordance with the present invention contain an indication of how much read / write memory should be allocated by the VM 20 to make the module.

The module 72 is supplied to the terminal 1 by any suitable means, for example an ICC 5 over a telecommunications network. After the module is moved, the module is saved in the module box. When its function is desired, terminal 1 or card 5 uses the authorization symbol load / interpret program 73 to process authorization symbols for execution in the CPU 2 of the terminal. This process consists of performing a function attached to each authority symbol. An authorization symbol loading / interpreting program 72 is provided by the VM 20 in accordance with the present invention.

The software related to the VM JL terminal can be divided into four main categories:

A kernel that includes terminal-dependent 1/0 driver implementations and all the functions required in this specification to support VM 20. Any other software related to VM 20 is written in machine-dependent entitlement symbols.

Terminal Resident Services (TRS) consists of at least one module that runs on VM 20 as an application manager and includes all non-application functions, libraries supporting these functions, module load functions, and a main terminal defining terminal behavior, special symbols authorization (eg DIOCTL) allow terminal-dependent device aspects 1/0 to be defined as embedded functions.

Terminal Selected Services (TSS) includes applications such as payment service features and libraries supporting these services. TSSs contain only terminal-independent authorization symbols and are permanently stored in terminal 1. The TRS main program loop selects and calls TSS functions as needed for a particular transaction.

Card Selected Services (CSS) include features that support terminal transactions, such as payment services, that are used as part of TSS applications. CSS is permanently stored on ICC 5 and moved to terminal 1 as required. For terminals 1 with two ICC readers 2 (translator's note: incorrect 8 in the original) (for example, one for normal transactions and one for maintenance), there may be two independent sets of CSS (CSS1 and CSS2).

All software in terminal 1 above the core is organized in accordance with the present invention as a set of separate modules. The basic characteristic of the module is that it is a collection of definitions or program functions that have passed a compilation of entitlement symbol 71 and are enclosed in a single block for delivery to the target environment, such as terminal 1 or ICC 5. Terminal main program (TRS), each application, each library and every moved CSS are examples of modules. All modules preferably use a standard format. In accordance with the present invention, the kernel in the system defines a VM 20 that provides a variety of high-level services to such modules as:

A general purpose CPU and instruction set represented by authorization symbols;

General purpose I / O support for common devices with measures for generic I / O to support additional devices that may be added;

database management functions;

managing the transmission of data objects containing format conversions and other functions;

managing authority symbol modules containing their in-memory maintenance (updating if necessary) and performing them as required. In a preferred embodiment of the present invention, the design of the modules remains under the control of the VM 20. Thus, the modules never take control of the base processor, but are only passive with respect to the VM 20. Preferably, the VM 20 always operates in a supervisory manner and can execute only the instructions defined in the form of its authorization symbol set, and no module can operate in a user-friendly manner, i. from. Thus, in implementing the VM 20 using a memory map, only one memory map can be created, namely the map of the supervising program.

No module can compromise the operating system defined by VM 20. This is secured because the module can only contain authority symbols from the VM authority symbol set, and none of these authority symbols allow access to the code space where the kernel is stored. Also, the VM 20 encounters an authority symbol that is outside the defined set, an exception is thrown (ILLOP).

As schematically shown in FIG. 4, terminal 1 comprises a terminal specific operating system 80 (incorrectly translated by the translator) 8 of the terminal responsible for loading the TRS module of the VM 20 (the loading procedure is described below). The code for VM 20 is stored in the non-volatile non-volatile memory 11. Before the TRS is deployed, the non-volatile terminal 19 of the terminal is flushed from all transaction-related data, the non-volatile read / write terminal 18 contains applications to be executed by the machine. The VM 20 in the form of modules 72 in a non-volatile database module receptacle containing specific user and library data, such as a retractable library, to be described later. If VM 20 is also implemented on ICC 5, the same principles as described above are used with respect to non-volatile non-volatile memory 13, non-volatile memory 14, and non-volatile memory 15 for reading / writing ICC 5.

Because VM 20 is a virtual machine, it addresses all forms of memory 11, 18, 19, 15, 11, 11, 11, 11, 11, 11, 12, 11 of the terminal or ICC as virtual memory, i. from. they are all addressed in the logical address space from the perspective of VM 20. In an actual embodiment of the VM 20, these logical address spaces are mapped to the actual address spaces in the memory of the terminal 1 or ICC 5 by a memory map or the like. Reference will be made in the following to the non-volatile memory, non-volatile read / write memory, and non-volatile non-volatile memory included in ML20. It will be understood that this applies to logically addressed memory space unless specific reference is made. about actual addresses in the implementation of VM 20 in terminal 1 or ICC 5. The volatile memory does not withstand program loading or power down and / or restart. Advantageously, the volatile memory does not withstand power shutdown for safety reasons. Non-volatile memory can withstand program loading, power down, or restart.

Description of the virtual machine

A schematic representation of the VM 20 in accordance with the present invention is shown in FIG. Preferably, the VM 20 is a cartridge machine and has a data stack pointer (stored in the data stack pointer register 32) that points to the data stack 27, preferably in memory on a chip. All operations are performed on this stack 27. The data stack 27 is used to contain procedure parameters and temporary results from evaluating expressions. The data is readily retracted or removed from the data stack 27. The VM 20 also includes a return stack 28. The return stack 28 may be used by the VM 20 to include return addresses and may also be used as temporary memory. This multiple stack architecture is known from the Forth programming language (ÄNSI X3.215-1994). This architecture has been further modified for priority, code density, security, easy compilation and for use with other programming languages. It includes, for example, a measure for local frame variables used in high-level programming languages such as C. Compiler programs 71 entitlement symbols can thus be written not only in Forth, but also in C and other programming languages in accordance with the present invention. .

In accordance with the present invention, only one data stack 27 and one return stack 28 are connected to the VM 20. The data stack 27 and the return stack 28 are not provided for each processing thread. In accordance with the present invention, application programs can retrieve from the return stack 28 only what has been routinely inserted inside it by the routine and must delete data located in the return stack 28 during the routine procedure before exiting the procedure. The VM 20 also, optionally, includes a security control program to provide runtime integrity and which monitors each activity in the return stack and checks all data deleted during the routine procedure. In addition to the data placed explicitly therein for intermediate storage, the VM 20 may include status information for the exceptional execution, frames for local variables, loop control parameters, and database association in the return stack 28.

In accordance with the present invention, the VM 20 may comprise a plurality of cartridges. For example, rather than using only the return container 28, other containers 29, such as an exception stack or a frame stack, may optionally be provided. The exception stack is used to store the execution state during execution. The frame stack is used to hold local variable information as well as activation records of C-like languages. As mentioned, the exception stacks 29 and frames can be implemented in the return stack 28.

The data stack 27 and the return stack 28 and other stacks 29, such as the exception stack, are not directly accessible in the memory space by any application programs. The data stack 27 and the return stack 28 cannot be addressed directly, they are accessible only through stack operations. For security reasons, there is no limitation on how data is stored in the actual implementation, so deceiving persons cannot predict how data is physically stored.

The VM 20 includes a virtual central processing unit 22 that includes a virtual arithmetic logic unit (ALU) 23. The VM 20 addresses a space 24 of virtual or logical data that the VM 20 treats as a random access memory (RAM) and which would normally be implemented as part of the volatile memory 19, for example in RAM in the actual terminal 1 or card 5. The logical data space 24 is accessible only for data storage. The sequence of module authorization symbols is stored by the VM 20 in the code memory 26, which the VM 20 treats as non-volatile memory (ROM). Only VM 20 can read authority symbols. Code memory 26 is not accessible to application programs or any authorization symbol.

The VM 20 may also include virtual registers 30. The registers 30 of the VM 20 may include an entitlement symbol indicator register 31 that includes a pointer that points to the following execution authority symbol, a data stack pointer pointer 32 that includes a pointer that points to a common peak top of data stack (TOS) 27, a return stack pointer register 33 that includes a pointer * that points to a common top of the return stack location, a frame pointer register 34 that includes a pointer that points to the beginning of a frame in the data space 24. A frame end pointer register 35 that includes a pointer that points to the end of the frame in the data space 24. It is not intended to provide any direct access to registers 31 to 36 using a set of authorization symbols, but only through registry access authorization symbols.

Finally, the virtual 1/0 devices 25 are coupled to the CPU 22 by a virtual bus system 21, which also links stacks 27-29, ALUs 23, registers 30, code memory 26, and data space 24.

The VM 20 in accordance with the present invention is preferably defined as a byte addressed two-access 32-bit machine with 32-bit registers and cartridge elements, but the invention is not limited thereto. The size of the register / cartridge is referred to as the cell size of the VM 20 when the cell is the base handling unit in the cartridges and registers 31-36 of the VM. The cell size used by the VM 20 is not considered to have a material impact on the present invention.

All programs run from modules must follow the following rules:

Programs must not consider that data in any of the above categories are guaranteed to be contained in the return stack 28. and thus may only use a search mechanism specifically specified for that category, since the security control program may delete any such data.

Programs that pass data in one of these categories to VM 20 must take appropriate action to recover data from the VM 20 before it leaves the procedure in which it is being passed, otherwise the VM 20 frees the appropriate portion of memory.

Programs must consider that any data previously placed in the return stack 28 is provided as inaccessible when data in one of these categories is transferred to ML20.

Programs must consider that any data in one of these categories released to VM 20 *. Is rendered inaccessible by executing a code that places the values in the return stack 28 until the values are deleted because the return stack is only accessible by specified authorization symbol procedures.

In accordance with the present invention, the operating system of the VM 20 defines a single address space 24 available to each module. This address space 24 will be accessible only for data storage and will be referred to as data space 24.

Data space 24 is divided into three and one optional logical partition, each of which is individually contiguous:

1. an initialized data space 41 that includes initial values specified at compile time and set when the VM core is activated and subsequently when a module containing initialized data is loaded;

2. an uninitialized data space 42 that contains variables and static buffers allocated during compilation of the program. This data space 42 is initialized to zero by the VM 20;

3. a frame memory 46, which is controlled by frame authority symbols;

4. optionally, an extensible memory 45 that includes one or more buffers dynamically allocated during execution of the program.

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

5. Expanded memory 43 typically mass storage that is used to contain data objects and energy-dependent databases;

6. The non-volatile memory 44 is used to contain data that is guaranteed by the VM 20 to withstand module loading or power down or reboot (within a terminal hardware limitation) containing a module box and non-volatile databases. This can be implemented in RAM with support for battery, disk or other non-volatile memory. The non-volatile memory 44 may be implemented as part of the read / write non-volatile memory 18.

To enhance data security, extended memory 43 and non-volatile memory 44 can only be accessed through authorization symbols that provide windows to selected data in the form of buffers in uninitialized data space 42. The programmer can also only request a record and cannot know the exact location of the data, so that he cannot access them. Preferably, there is no file or tree structure that allows the programmer to place personal files or databases.

Within each data space 24 used by the module, memory is allocated by relative addressing, and only during operation. This means that the address only has meaning within each module, if loaded. Absolute addressing is not used because it is not possible for a module to gain access to the data of another module, except for the access module of the security module described below.

The frame mechanism allows the VM 20 to satisfy the requirements of languages, such as the C language, that allow local variables to be defined during the service life. The frame contains the process parameters that have passed in the data stack 27 as well as local variables (temporarily storing data that will be automatically released when the frame is released, normally at the end of the process). The frame start and end pointer is automatically maintained by the VM 20 inside the frame. The frame pointer register 34 shows the logical base of the frame, and the frame end pointer 35 shows the logical end of the frame in the data space 24. Parameters can be retrieved from the frame using the frame access authorization symbols.

The VM 20 can provide a dynamic allocation pool of expandable memory 4.5, as the only expandable buffer managed by the VM 20, that appears outside the uninitialized data space 42 of the program. The programs may request the allocation of the specified size of the expandable memory 45 and return the pointer to the base address for the memory 45. Subsequently, the programs may release the memory 45 from that address, for example at program termination, causing all allocations beyond that address to be released.

It is preferred that the modules be made in a single data thread, but the invention is not limited thereto. That is, if one module calls the other module, it terminates the other module and all resources of the other module are released before VM 20 returns to the first module and continues processing. Fig. 6 is a schematic representation of logical memory from the perspective of VM 20. As schematically shown in FIG. 6, the first module (left) with initialized memory 41, uninitialized memory 42 and frame memory 46, and a symbol symbol code space 26 was loaded into the read / write memory starting at address 1. The first module also called and was allocated to the expandable cache section 45 . When the second module (right) is called by the first module (for example, to receive a function fgh that is in the exclusive list in the header of the function module 1 that can be received), the data space 24 'containing the initialized memory 41' is uninitialized memory 42. ' and a frame memory 46 'allocated as a desired start at address 2. The authorization symbols of module 2 are read directly by the machine VM 20 from the module box, which is a permissible option in accordance with the present invention. Calling from module 2 is an expandable memory 45 'for the second module allocated by the VM 20 in a memory larger than in the expandable memory 45 for the first module. When the second module is completed, all memory above address 4 (flexible line method) is released. All temporarily stored data are preferably deleted when released. If necessary, more expandable memory 45 could be called upon returning to the first module. If the second module is then called again, the expandable memory 45 * will be assigned a different start address than if the module was called for the first time.

All entitlement symbols, except EXTEND, CEXTEND and RELEASE entitlements managing the expandable memory and the THROW and QTHROW entitlement symbols for exceptional processing, are required to have no net effect on the expandable memory indicator. If the authority symbol allocates expandable memory 45, it must also release it, including any cell leveling effect. The successive allocations of the expandable memory 45 are preferably adjacent within the module, but need not be adjacent between the modules. In addition to using IMCALL or DOSOCKET authorization symbols, intermodal calls maintain a neighborhood. The automatic release of the dynamically allocated expandable memory 45 is intended to occur when the execution of the module is completed by limiting the effects of the program's clean-memory freeze. Further, if a THROW exception occurs, the allocation of the dynamically allocated extensible memory 45 can be restored to its condition at the time of the CATCH exception.

User variables are cell size variables in which VM 20 has client context information for client programs. The memory for user variables is pre-allocated by VM 20. A limited number of variables may be provided, such as sixteen variables (designated as 0-15). An implementation of VM 20 that supports concurrent processing of tasks may provide one set of user variables for each task.

The VM 20 provides a single exception handling mechanism through CATCH, THROW, and QTHROW authority symbols. These authorization symbols are derived from the Lisp exception handling mechanism and occur in ANS Forth as CATCH and THROW. The aim of this mechanism is to provide local handling of exceptions when checking the program at different levels of software. The concept is that the program passes the function execution pointer to the CATCH authority symbol, which executes the function, and returns a code showing what exception, if any, occurred during its execution. The CATCH records implementation-dependent information sufficient to restore its normal execution state if the THROW symbol should appear in a function passed to execute the CATCH. This includes, but is not limited to, the depths of data and return stacks, frame pointer, and. # * · »· ·.

in some cases, an expandable memory pointer. The collection of information representing the state of implementation is referred to as the exceptions framework. Exception frames are contained in the exception stack. After CATCH, the program may examine any exception code that may have been returned and choose to be handled locally or thrown (THROW) to a higher level for processing. VM 20 provides the default value of the furthest level at which exceptions will be caught. This outermost level will be activated if no internal CATCH level has been created. The default value handler will cancel any normal terminal transactions and attempt to reload the TRS modules and re-enter the main TRS loop. ML 20 throws ANS Forth exception -10 (division by zero) if such a condition occurs. VM 20 may also throw other general exceptions supported by ANS Forth, such as those listed in the appended appendix.

For device handling and input / output (I / O) services, each device, including those whose low level operation is hidden by the VM 20 under device-specific functions, is assigned a device type (used to categorize the result codes) and a separate number devices. Device numbers are arbitrary, but references to device numbers - 1 to 5 (4 bits) - can only be made with a single authorization symbol, so these numbers are assigned to the most common devices such as keyboards, ICC readers, magnetic tape card readers, displays, printers, power management devices, or vending machines. General I / O equipment provides functions that

·. They take the device number as an input parameter.

Terminal 2 in accordance with the present invention comprises at least three larger non-volatile databases: application-specific transaction logging, a message database in one or more languages, and a module database. VM 20 protects databases as much as possible because they may contain private information. Access to databases is restricted. The VM 20 provides a database manipulation mechanism (VM 20 is a server) that hides implementation details from application software (applications as a client). No direct database access is allowed from a module that is running on VM 20. Services implementing the following features, which will be described above with reference to FIG. 7:

* At any given time the client has, ie. from. program running in the module, access to one commonly selected database (DBCURRENT) and one commonly selected record number (DBRECNUM) that is shared across all defined databases.

* Information about each database is transferred between the client and the server through the DPB Database Parameter Block 51, which the read / write server can access. The client owns DPB 51 in the sense that it is the data space of the client 24, but the client is not allowed to access it directly. Instead, only authorization symbols for database services can be used to access data. The DPB 51 has a standard structure comprising at least a DPB junction field, a database pointer, a database type and record size indication, and the next available record number. All database specification information must be in advance that exist in the pointer to the original address set in DPB 51. The client software must not make any subsequent direct access to DPB 51 and must not make assumptions about the values directly contained in DPB 51 after the module defining DPB 51 has been introduced for execution. Parameter blocks of database 51 go to boot / interpret. an authorization symbol program in the form of a pointer (DPB connection) to the attached list in the module initialization section. This field must be preset to the address in the initialized data of the next DPB 52 in the list or to zero if this DPB 51 is the last or only DPB 51 in the list. For compiled databases, client initialized data space, database (DB) be preset in the initialized data. For databases whose memory is managed by the server, the field must be set to zero by default. Database Type (DB) provides database details in coded form. There are at least three kinds of databases:

Energy-dependent databases whose contents do not need to be preserved between module loading or when the source of the terminal 1 on which they are fixed is turned off.

Non-volatile databases whose content must be preserved between module loading or power down. If the module defining the non-volatile memory is replaced, the database is destroyed if the old module is selected. The compiled databases are constructed by the entitlement symbol compiler 2i in the adjacent initialized data area as fixed length records. Records must not be added or deleted from the compiled database and the database must not be initialized at run time, otherwise full read / write capacity will be supported.

The next available record number field will be set to number one plus the last assigned record number in the database for compiled databases. For any other database, this field is set to zero.

* The window address for the regular record (record buffer 53) is provided to the client by the server for each client database. For certain database operations, the client may drop string and key buffer addresses 52 to the server. For each database known to the server by the client module, the VM 20 provides a record buffer 53. This record buffer 53 begins at the aligned address. The contents of the record cache 53 attached to a particular database after a certain record selection remains available until the client selects another record from the database. Except for these record buffers 53, compiled databases, and parameters moved to data stack 27 using specific database functions, no other data space 54 is shared between the client and the server. Programs must not consider that the records in the database are in a neighboring memory.

* The database is specified by the deployment process for the module in which its DPB is defined. Energy-dependent databases installed by application modules are not automatically and transparently specified by the server when the application is terminated by Permanently Stored Terminal Services (TRS) when all storage of data allocated by the server to these databases is released.

* The server deletes non-volatile databases if the module that defined them is replaced. If a module is loaded when it is replaced, for example, for a TRS module, the server must clear the non-volatile module databases when the module is released.

The operation performed by the VM .20 when the database is specified during module loading depends on the DB type value and the DB pointer in DPB 51 and whether the database is energy dependent or independent. If the database is of a non-volatile type, the DPB address shall be used in conjunction with the identification module (module ID) to identify any previous data belonging to the database. If previous data exists, the next available record number is restored to its previous value. Otherwise, the server (VM 20) instantiates the new non-volatile storage and sets the next available record number to zero. In both cases, a buffer 53 is provided for a common record in the database. If the DB pointer is zero and the DB type is of an uncompiled type, then the server instantiates or makes available memory required for the database, initializes memory to all zeros, provides buffer 53 for the current database record, and sets the next available record number (DBAVAIL) to zero. If the DB pointer is non-zero and the DB type is a compiled type, then the server sets the internal structures to use the client data structure whose original address passed the DB pointer and sets the next available record number (DBAVAIL) to the value that passed in the next available array of numbers. DPB records 51. The server maintains the actual database records 55, the relationship between the address location and the record in the database control block 56, and a record to which database the module normally gets in the context information block 57.

The process of handling safe modules in accordance with the present invention will now be described with reference to FIG. 6. In FIG. 6 shows a logical read / write memory area. The memory area to which the left module (the first module) can reach has a dotted line boundary. The memory area that the first module cannot access has a solid line boundary. The memory area that can be accessed by more than one module is indicated by a dashed line. VM 20 protects DB1 and DB2 databases and the database box and modules in the module box so that they are not accessible by any modules. After the first module has been loaded, uninitialized data in memory 42 can be accessed by the first module, but the VM 20 does not allow any areas other than this module to be accessed directly by the modules. Access to registers, stacks, or frame memory 46 can only be made by means of corresponding authorization symbols. Databases can only be accessed through the window process mentioned above. In particular, the first module cannot access its own program memory 26, where the entitlement symbols are located, or access any other module. This is important in the protection against viruses. In accordance with the present invention, the memory allocated to the first module is defined and protected. It is defined by the memory allocation according to the amount of memory to be allocated inside the module. It is protected because no other module can access the allocated space and no other boot mechanism is provided for any other module-only program. The preferred mode of operation of the modules is single-threaded, any memory allocated in the expandable buffer 45 is released before any other module can become active. The free memory is preferably erased.

The exclusive acceptance list of the first module is in its header, to which the first module cannot directly access. The VM 20 reads the header and calls the second module that is mentioned in the receive list (fgh function from the second module). The VM 20 loads the second module and allocates a memory for uninitialized data 42 *, frame memory 46. ' and for initialized data 41 '. The first module cannot reach any part of the second module and vice versa. In the second module header, fgh was placed in an exclusive list of functions that can be performed. This makes the fgh function available for other modules. The VM 20 searches for the function fgh in the code space of the second module 26 * and executes a sequence of authority symbols with corresponding input data (represented by a sequence of TITTITT). In this example, this piece of code requires access to the DB2 database. The database in accordance with the present invention is owned by a module, i. from. the database can only be accessed by the module that specified it when the module was first loaded. The access symbols for the database read from are provided by the VM 20, which allocates uninitialized access to the third DB2 record when the buffer 53 * in the data space 42 * of the second deployment code space module 26 allocates.

The fgh function VM 20 then transmits the reference record to the window 53 * in the second module, from which it is transferred to the uninitialized space 42 of the first module. Using the same database window process, the first module can also obtain a record from its own database DB1, which is transferred to a buffer 53 in the uninitialized data space 42. The first module can then be operated on the results of two processes.

Preferably, VM 20 deals with data objects, Basic Encoding Rules (BER), or flag, length, value (BER - TLV, for this application shortened to TLV Tag, Lengh, Value) means such as described in ISO / IEC 8825 (1990). TLV data objects consist of two or three of the following fields: a flag field specifying its class, type, and number? a length field specifying the size of the data when the length is not zero; value field containing data. Since ICC card responses are generally limited in size, say, 255 bytes or less, the maximum size of a TLV object is in accordance with the present invention. The field of flags is preferably single-byte or double-byte, the field of lengths is preferably single-byte or double-byte, and thus the maximum size of the values is preferably 252 bytes (an array of this length requires bytes of two lengths, as explained below). The first flat of symptoms is broken into three fields. Bits 7 and 8 specify the object class. Bit 6 determines whether the value field contains primitive data or whether it is a constructed object containing other TLV encoded fields. Constructed objects are also called templates. They cause their value fields to be separated for TLV sequences when they encounter them. Bits 1 to 5 specify the number of objects or, if all of these bits are a set, indicate that additional flag bytes follow. Additional flag bytes have their 8-bit set if another byte follows. All bits up to two bytes are used to determine the flag name. Depending on the length, it contains one to three consecutive bytes, typically two. If bit 8 of the first byte is zero, then bits to 7 indicate the value of the pole value. If bit 8 of the first byte is

1, then bits 1 to 7 indicate the number of bytes that follow.

The following bytes, if any, show the size of the pole values and occur with the most significant byte first. The array of values may contain primitive data or may be a constructed array with additional TLV encoded sequences. If bit 6 of the first byte is set in the flag field, then the value field contains additional TLV sequences. Primitive objects can be encoded in several different formats: binary-coded decimal poles with leading zeros or trailing bytes with a set of all bits, binary numbers or sequences of bytes, characters, or ASCII bytes, or each object is manipulated differently as used. ICC 5 may also use the Data Object List (DOL) to request values for specific flag names. The card 5 sends a DOL containing a list of flag poles and length poles and terminal 1 returns a corresponding value field without a separator.

alphanumeric sequence undefined formats. WITH

Each TLV to be used must be defined by the terminal or application programs to create its data type and name. Because the terminal program and application programs are developed separately, the VM 20 accordingly requires, each TLV of the invention uses a link structure (balanced binary tree) to allow for quick addition or removal of feature names from the global list of feature names. This is to compile the following structures for in the initialized data space 41 in the TLV defining module:

Link A lava cell (two bytes of high order) or the right one (two bytes of low order) providing a link to tree elements.

Link left A 16-bit relative pointer from this TLV access parameter to a TLV record access parameter whose flag is numerically smaller than this record flag. A value of zero indicates that this TLV is not connected to a TLV with a flag numerically smaller than this TLV.

Link right A 16-bit relative pointer from this TLV access parameter to a TLV record access parameter whose flag is numerically larger than this record flag. A value of zero indicates that this TLV is not connected to a TLV with a flag numerically larger than this TLV.

The double-byte string whose large final numeric value is a TLV flag.

Type One byte that specifies control information. Reserved Byte, which must be initialized to zero by compiler 71.

Data A cell that has VM-specific information containing access to the pole of lengths and the array of values of this TLV. This field must be initialized to zero by compiler 71. The system must also maintain a status byte for each TLV. This can be reserved byte in the structure mentioned above. The low order bit of this byte should be set if the TLV has been assigned a value as a result of being in a sequence that has been processed by TLVPARSE or TLVSTORE authority symbols. The purpose of maintaining an assigned status is to identify TLV values that contain valid data (which can be zero) and to distinguish them from TLV values that have never been set and are therefore invalid. The VM core manages the TLV global list of flags by maintaining a list of pointers and initialized data space 41 containing their actual definitions as described above. When a module is loaded, its TLV definitions are added to this list as part of its initialization; when selected, TLV definitions are to be automatically removed from this list by VM 20. An exception may be thrown if the module contains a TLV definition that already exists. The LINK address described above returns to the access parameter for TLV references. The programmer should not access these fields directly, nor make any assumptions about their content after VM 20 has specified TLV definitions.

References to TLV definitions in the source code are compiled either as direct references to the definition structure defined above, or as numeric values for flags. Within certain binary TLV definitions, individual bits or groups of bits are defined to have certain meanings. They are referred to as TLV bits. References to TLV bits can be compiled by pointing the literal per bit within an array of TLV values. Bit 0 is the least significant bit of the first byte, bit 7 is the most significant bit of the same byte, bit 8 is the least significant bit of the second byte, and so on.

The data allocated by the TLV definition is submitted to the application through a 252 byte area of the workbook memory maintained by the VM 20 in the form of a database window (see FIG. 7). The application program is allowed to change the contents of this area of the scratchpad memory. If the changes are to be retained, the address and length inside the workbook memory area must go back to the TLVSTORE authority symbol. The address and contents of the scratchpad memory area may become invalid if any TLV authority symbol is processed sequentially.

As part of the security management of the cards 5 introduced into the reader 7, the cards 5 known as lost or invalid will be checked. The list of such cards is known as the black or hot card list. Black or hot card list management is provided by a set of dedicated functions that are specific to managing a large list of hot cards. A typical list can contain 10,000 primary account numbers (PANs) with up to 10 bytes for each number or 20 binary coded decimal (BCD) digits. PAN inputs are stored in compressed numeric (cn compressed numeric) format, correctly filled with hexadecimal FH. Since the PAN is a maximum of 19 BCD digits, entry to the list will always be filled with at least one FH. When looking for a hot card list, the FH in the list is considered as a wild card or a non-interested number, but any FH in the PAN used as input is not a wild card. Wildcards can only appear at the right end of the entry. A pan is considered to be found in the hot card list if there is an entry list that is identical to the first FH in the entry.

Another part of the security management is the provision of coding services for coded and uncoded data. Any suitable coding method may be used. In particular, for the VM 20, three coding algorithms are provided: module multiplication and promotion to module, which are used in the RSA algorithm, and the SHA-1 key recalculation security algorithm, but the invention is not limited to these methods. Multiplication by a module involves multiplying two unsigned x and y values, where the product is reduced using module z. The formula is:

result = mod (x * y, z)

All input values (x, y, z) have the same length. They are a chain of flats and can be anything. multiple of 8 bits up to and including 1024 bits. Values must be in a large, bit-ending byte.

The Secure Hash Algorithm (SHA-1) security algorithm is standardized as FIPS 180-1. SHA-1 removes arbitrary lengths as input messages and generates 20 byte values for number marks. Promoting to module increases the unsigned x value to the power given by the unsigned exponent y, where the result is reduced by using the module z. The formula is:

result = mod (χ ¥, z)

The input value x and module z are byte strings and can be any multiple of 8 bits up to and including 1024 bits. Values must be in a large bit-ending byte order.

Services and therefore software, as well as I / O equipment, may change over time depending on market requirements. If major changes are required, the software update in terminal 1 can be performed manually or remotely via a telecommunications network. However, for user-dependent services, it is preferable to have a dynamic but secure method for making smaller or user-specified improvements to the services provided by terminal i. The plug and socket software mechanism in accordance with the present invention provides a flexible and secure way of directly configuring the various modules that create terminal programs and applications. As schematically shown in FIG. 8, procedures (designated as drawers 60) may be defined in the transaction system in accordance with the present invention, which may be inserted by the application programmer (and also securely because they are under the control of the acquirer and under the payment system supervision) into applications 61, 62 to act as holders for adding an additional extension code (labeled as plugs 66) during transaction processing. All additional codes to be plugged into the socket 60 must be written in the form of a set of authorization symbols of the machine VM 20. The sockets 60 are preferably located at different suitable points in existing terminal applications 61, 62 or even in the terminal program itself. They are used to refer to library functions and may also occur within the library function if the payment system foresees the need to change the path in which the library function operates. Sockets 60 are initialized by VM 20 for standard behavior. If no further operation is performed by the terminal program, the standard behavior of socket 60 will be such that it does nothing when it is executed (i.e., no operation).

The plugs 66 include the executable code written in the authorization symbols supported by the terminal 1, which can be inserted at the points defined by the sockets 60 to extend the standard logic of the terminal. Plugs 66 may already exist in terminal 1 in terminal library 63 to be retrieved from ICC 5, for example, socket / plug identification programs 67 in ICC 5 and logic in terminal 1. Socket / plug identification programs 67 include both plug and socket references. The plug 66 may also come from an input device 65 (such as ICC 5 or a base system connected to terminal 1), but only if all members of the payment system agree. , such as a publisher, acquirer, or merchant.

On completion of the transaction, drawers 60 are restored to their original application standard behavior. In accordance with the present invention, it is preferred that ICC 5 do not include whole applications, but only plugs 66 that extend existing terminal applications because this requires less memory.

Sockets 60 have performance indicators, also known as procedure indicators, that allow the creation of a procedure whose behavior can be changed during operation. Sockets 60 may be viewed (and implemented) as a field of procedures that is accessed through a DOSOCKET privilege symbol that takes over INDOSOCKET that takes the socket number from the data store 27.

Sockets 60 allow you to reconfigure the terminal program or application to provide changes or extensions in the transaction processing flow. Alternatively, sockets in ICC 5 may allow ICC 5 to be improved from terminal 1. Sockets 60 provide an interface between software modules and procedures that may come from several different sources (acquirer, publisher, etc.). Because the acquirer and the publisher! have a contractual relationship, they may agree to use the specific sockets 60 provided in the terminal by the acquirer program so that you issue! can extend the behavior of the program, for example, to provide a loyalty function (air miles, coupons, etc.).

The module may specify, if loaded to execute, that the sockets 60 are automatically reconfigured, or the client program may programmatically associate the new procedure with the sockets at runtime. The security conditions provided allow the sockets 60 in the application to be assigned standard behavior, and then the new modules can be re-inserted with new procedures to provide specialized behaviors. To avoid indeterminate situations, it is preferred that all procedures aimed at using a particular drawer 60 have no effect on the data stack (except drawer zero, as explained below). This ensures the continuity of the program regardless of which targeted version of the procedure is performed. The standard operation of all drawers 60 prior to modification should be at least such that they are inoperative.

Assignee! can allow code transaction to be extended to ICC 5 as part of the CSS above. If so, they can be realized by sockets 60. The library or executable module may include a definition of new sockets 60 for later plugs 66 coming from ICC 5. In this case, the module would define socket 60, and then use the SETSOCKET authority symbol to add to it standard behavior (often zero behavior). If allowed by the access control, ICC 5 could later move the plug 66 containing the authorization symbols that define the new behavior, and then use the SETSOCKET permission symbol to store it in this same socket 60, by discarding the standard behavior.

Modification of behavior is appropriate and flexible, but may provide an opportunity for misleading persons to modify the behavior in their favor. Special care may be required for plugs 66 from ICC 5 if they can modify the behavior of the socket or be placed in the program flow before the card is successfully authenticated. For safety, the terminal software in accordance with the present invention may specify a socket inspection procedure that checks whether each individual socket 60 can be modified or not. For example, the execution of the code removed from ICC 5 can be strictly controlled by the acquirer so that no socket can be inserted from the ICC 5 until all standard authorization programs, such as electronic signature checking, are executed on the card.

In accordance with the present invention, socket security includes a socket inspection procedure specification to be used in subsequent insertion attempts to socket 60 (SETPLUGCONTROL authorization symbol). The PLUGCONTROL procedure must be written to return for a given drawer number whether that drawer 60 can now be modified. When the list of socket modules is processed sequentially during module loading or when socket 60 is programmatically inserted, VM 20 first performs a user-written PLUGCONTROL procedure to determine if socket 60 can actually be inserted and maintains the existing behavior of socket 60 if this is the case. cannot happen.

A module wishing to restrict access to any sockets 60 prior to loading another module to execute may execute the procedure defined by the SETPLUGCONTROL authority symbol on the plug-in socket (socket zero) selected by the PLUGCONTROL function as a parameter prior to loading that module. If the other module and any other modules implemented to execute them have their socket records processed, the sockets 60 to which access is denied by the user defined by the PLUGCONTROL procedure are intended to maintain their existing behavior. This condition should not be considered as an error. A code wishing to restrict access to any sockets 60 before executing the next code may execute the procedure defined by the SETPLUGCONTROL authority symbol with the PLUGCONTROL procedure selected as a parameter at an appropriate point in the program flow. The programming request for plugging 60 may determine whether the request has been accepted or rejected by calling SETSOCKET. Any drawer 60 whose behavior has been modified by either the module load process or dynamically programmed command is restored to the behavior it had when the last executable module was loaded to execute as part of the exit procedure packaged within the procedure defined by the Execute Symbol module (EXECUTEMODULE).

As an example of an acquirer-specific function, we assume that the underlying transaction code contains a SOCKET LOYALTY sentence 27 that defines LOYALTY and makes it available for later execution. The acquirer's transaction program code further defines a code that sets the permission label for this drawer only if the publisher is the same as the acquirer and the transaction size exceeds a certain minimum. During the transaction, there is a command that reads any code from ICC. Part 5 of the ICC code could define a standard REWARD program that updates the user's frequent flight miles and then tries to execute the PLUG REWARD INTO LOYALTY sentence. This sentence associates the REWARD design with the LOYALTY design. If the LOYALTY socket permission label is set according to the logic above, it will take SETSOCKED; otherwise, LOYALTY will maintain its standard behavior likely to be inoperative. Then, when the application code executes its LOYALTY function later, the REWARD defined by the ICC will only allow the rules defined by the acquirer.

The VM 20 typically operating on the terminal 1 may have a limited number of sockets 60, for example 64 sockets numbered from 0 to 63. In the most basic form, the terminal program skeleton could consist almost entirely of sockets 60 and a base program flow from socket to socket. Sockets 60 would then receive transaction processing procedures by other modules loaded during application selection from either terminal 1 or from ICC 5. Sockets 60 present in the skeleton program prior to application selection have zero default behavior assigned by TRS. If a procedure is inserted into a given socket 60 by more than one module, it simply replaces the last operation of any previous operation.

Implementation, handling and execution of modules

The code written to run on VM 20 (including permanently stored terminal services, compiled as authority symbol modules) may consider that after powering on the kernel software resource specified by the terminal supporting VM 20, it performed any necessary power-up initialization of the terminal specified power and started execution the terminal processing services (TRS) loop processing through the module loading process described below. When it exits the main TRS processing loop, the control returns to the terminal-specific software layer responsible for TRS recovery and the new entry to the main loop. All VM resources are released whenever TRS exists, except for data in non-volatile databases. The resources are released when the terminal is disconnected from the source, the TRS output is executed, or the TRS is restarted by the terminal's operating system (if any). If an updated version of any TRS module has been obtained since the last entry to the main TRS loop, all TRS sources, including data in its non-volatile databases, are released, if any.

The operation of the software on Terminal 1 or ICC 5 is controlled by the VM 20 in the form of one or more modules, where each module may contain any of the following categories of information:

* Code in the authorization symbol * Initialized data * Allocation of non-initialized data * Database definitions * TLV definitions * Drawer list * Module interdependencies

Each module is preferably delivered to the terminal 1 in a Module Delivery Format (MDF). The VM 20 maintains a non-volatile receptacle in a non-volatile memory 18 for reading / writing modules that have been delivered and installed in the terminal 1. Each module is to be identified in the stack by a module identification program or an ID module. Upon registration in the module receptacle, module information is available through a non-volatile database maintained by the VM 20 and stored in a non-volatile memory 18. In accordance with the present invention, the VM 20 protects the modules inside the receptacle from modification by any other module because authorization symbols. The VM 20 further executes the arrangements for a new version of the module while a module of the same module ID exists for execution.

Conceptually, there are two stages of module processing: first, it is introduced, which means it is made accessible and its data, databases, etc. are specific and, secondly, if feasible, the VM 20 will process its authorization symbols starting from their entry point. The embodiment procedure will be described with reference to the flowchart of FIG. 9th

First, in step 100, the resources are marked and permanently stored. Prior to executing the module, the VM 20 indicates its status and permanently stores any necessary resources so that this status can be restored later. Status includes:

* Expandable memory pointer, frame pointer, and frame end pointer position.

* Contents of the entire common drawer list.

* TLV registered in TLV flag names list.

* Other internal data that the VM implementation needs to control the module activation and execution.

Next, the module is loaded at step 102. The module module ID to execute is released to load a module that will be loaded without error, as described in the standard subroutine later. When the module is detected in step 104, it can be executed and the program proceeds to step 108. If an error is detected in step 104, the execution of the module is canceled and all resources required to execute the module are released in step 105. This requires the VM 20 to:

* All volatile memory required to load a module and any module that requires it to load must be freed and cleared to zero. This should include, but is not limited to:

* Space required for all module initialized and uninitialized data.

* Space required for any internal TLV buffers and data management structures defined by these modules.

* Space required for any internal buffers and data management structures required by databases defined by these modules.

* The TLV name list maintained by the VM to find the flag must be restored to its state immediately before the module executes.

* The socket contents list maintained by the VM must be restored to its state immediately before the module is executed.

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

After the module has been successfully loaded, it is determined in step 106 whether the module is feasible or is a library module. If the module is a library module, no module execution is performed and the VM 20 frees all resources at step 110. as described for step 105. If the module is feasible, a field specifying the module entry point is determined.

The VM 20 starts the module by calling the authorization symbol specified at the pole entry point. Then, each entitlement symbol is executed sequentially in step 108. The module terminates by using the entitlement symbol RETURN, after which all resources in step 110 are released.

causes default to return false. General

The process required for module loading, the standard module load subroutine, will be described with reference to the flowchart shown in FIG. 10. If an error is detected during module loading, this subroutine to load the module immediately is an error as out of memory where there are insufficient resources to move the space for initialized data, uninitialized data, databases or TLV; when a duplicate TLV flag is detected, etc. Initialized data must be set before the database and TLV section are processed, as these are part of the initialized data section. In step 120, it is determined whether the module has already been loaded into memory. If it has already been loaded, it will not be loaded a second time, and the module will return immediately with a true return. Next, it is determined in step 122 whether the module is in the receptacle. If it is not, it cannot be loaded, so the standard subroutine will load a module with a false return. In step 124, it is determined how many data bytes are needed for the module uninitialized data area 42 and the requested size is reserved. This area 42 is set by the VM 20 to all

Zero. Similarly in] step 126 is reserved required number apartments data for Area 41 initialized data module. then to do this areas copy initialized data. IN step 128

are TLVs defined in the load module added by VM 20 to the list of internal names used to find the TLV.

I

The root node of the TLV data structure is stored. Then, in step 130, the databases 20 defined in the storage module are initialized by the VM 20. Steps 128 and 130 can be performed in any order. In step 132, the modules selected for the conventional module are received. In step 134, the list of received modules is transverse, introducing each module recursively sequentially. If the received module cannot be loaded for some reason, as determined in step 136., the module that received the module is also considered to have failed to load because it cannot access the received services of the module. In this case, load the module returns false. In step 138, it is determined whether another module is to be received. If so, the procedure returns to step 132. After determining in step 138 that the last module received was recursively stored, the conventional module had previously allocated its resources, loaded and initialized without error, so that the module plugs into the slots at step 139. 60 in their list, and then returns true indicating that the module has been loaded successfully. Any attempt to insert zero into the drawer must be ignored by VM 20. If the drawer needs zero to insert it, this can be achieved by using the SETSOCKET authorization symbol.

The procedure for inserting into drawers 60 at step 140 will be described with reference to FIG. 11. In step 140, the standard behavior is specified for each drawer in the loaded module. In step 141, it is determined whether there is a plug. If not, then the module is performed in step 149. If so, the first plug is removed in step 142. In step 143, it is determined whether or not the security label of the connected socket is set. If this is not the case, insertion into the drawer is performed at step 146. If this is the case, the safety function specified for the socket is performed. If the safety evaluation is positive, it is plugged in at step 146. In step 148, it is determined whether the plug is the last plug. If not, another plug is selected for evaluation. If the safety evaluation is negative, it is determined in step 147. whether the plug is the last plug. If it is determined in step 147 or 148 that the plug is the last, the module will execute with a standard behavior for all sockets which have not been plugged in and for a plug-in behavior for those sockets into which the plug has been inserted. By these means a safe behavioral modification can be achieved.

Modules that have been loaded from ICC 5 by the LOADCARDMODULE authority symbol must be handled differently than modules loaded from the terminal 1 box using the EXECUTEMODULE authority symbol. A flowchart for the LOADCARDMODULE authority symbol is shown in FIG. 12. Before executing the card module, the VM 20 marks its status and stores any necessary resources permanently in step 150 so that this status can be restored later. Status includes:

* Expandable memory pointer, frame pointer, and frame end pointer position.

* Contents of the entire list of common clamps.

* TLV registered in TLV flag names list.

* Other internal data that the VM needs to execute to control card module activation.

The module is loaded at step 152 using a standard program to introduce the module described above with reference to FIG. 9; the difference is that the module is on the ICC 5 card and that it is not in the container box and is not yet loaded.

If it is determined in step 154 that the card module is not successfully loaded, in step 155 all resources are returned to the state in which they were immediately before the LOADCARDMODULE authority symbol was executed. This requires:

* All the volatile memory required to load a module and any module that required it to be loaded must be freed and cleared to zero. This should include, but is not limited to:

* Space required for all module initialized and uninitialized data.

* Space required for any internal TLV buffers and data management structures defined by these modules.

* Space required for any internal buffers and data management structures required by the databases defined by these modules.

* The TLV name list maintained by the VM to find the flag must be restored to its state immediately before the module executes.

* The contents of the collar list maintained by the VM must be restored to their state immediately before the module is executed.

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

If the card module is successfully loaded, the state permanently stored in step 150 is marked, and the resource permanently stored is simply delayed in step 156. Thus, the card module was firmly connected to the system being operated. To be useful, the card module must be plugged into the slots, otherwise there is no way to execute any code contained in the card module. Subsequently, in step 158, it is determined whether the module is a feasible module and, if so, is performed in step 160 as described with reference to steps 106 and 108 in FIG. 9th

The specific embodiment of the invention described above is intended to be illustrative only and may be made of it

many modifications and modifications made in accordance with the principles of the present invention. All such embodiments and variations and modifications are within the scope of the invention as defined in the following claims.

SIDE DISH

1. Definition of authorization symbols

1.1 Overview

The EPICode entitlement pointer symbols are a set of instructions for a dual-container machine with additional frames. Authorization symbols can be treated as an intermediate language of the compiling program. Some embodiments of the compiler program can actually compile EPICode authorization symbols into machine code.

EPICode authority symbols are byte authority symbols allowing a maximum of 256 authority symbols. Authority symbols with a single byte prefix allow extending the content of authority symbols to a theoretical maximum of 65536 authority symbols with respect to prefixes defining sides, each having 256 authority symbols. In fact, a limited number of prefixed authorization symbols is defined. Each authorization symbol value is listed in hexadecimal as a two-digit hexadecimal code with its corresponding name.

Authorization symbols without prefixes (single-byte authorization symbols) are referred to as primary authorization symbols, while prefixed authorization symbols (double-byte authorization symbols) are referred to as secondary authorization symbols.

Execution of any primary or secondary authority symbol not defined in the list below causes an ILLOP exception.

SIDE DISH

1.1.1 Forth function for EPICode authority symbols

This section provides an alphabetical list of Forth word matches used as EPICode authorization symbols. Each row contains left to right:

* Definition of capitalization of the same width * Pronunciation in natural language - Slovak * Special designation when used:

A Forth word ANS (including all sets of words of choice).

C compilation program directive; it must be used within the definition.

G the generic word Forth (for general use, eg Forth, but not in Forth ANS).

H the main (compilation) word, which may or may not contribute to the target authorization symbol.

* Equivalent EPICode authorization symbol (s).

A word pronunciation codes EPICode authorization symbols - minus A SUB 1 • save A STORE « number sign A NMBR #> number tag greater than A NMBRGT " WITH number sign WITH A NMBRS

SIDE DISH

* star A MUL / slash A DIV • • colon A, H PROC • r semicolon A, C, H ENDPROC ? TO question to execute A, C, H RQDO <+ addr> ? DUP question for reproduction A QDUP ? THROW question to throw G QTHROW @ conjured A FETCH (*] comma in square brackets A, C, H LITC <+ addr> (CHAR) character in square frame A, C, H PLIT <n> + plus A ADD + í plus save A INCR + LOOP plus loop A, C RPLUSLOOP <+ addr> < less than A cmpl <# smaller than the number tag A LTNMBR <> not equal A CMPNE = is equal to A CMPEQ > greater than A cMPG > BODY into the body A, H WLIT <+ addr>

SIDE DISH

> NUMBER into heading A TONUMBER > R do r A, C TOR 0 < zero less than A Setla 0 <> zero is not equal A setName 0 = zero equals A SETEQ 0> zero is greater than A Setgás 1 - one minus A SSUBLIT 1 1 + one plus A SADDLIT 1 2! two imp A vStore 2 * two star A SHL 2 / two slash A SHR 2 @ two pick A AFETCH 2> R two to r A, C TWOTOR 2 DROP omit two A TWODROP 2 DUP two reproduces the A TWODUP 2 OVER two through A TWOOVER 2 R @ two r select A, C TWORFETCH 2 R> two r z A, C TWORFROM

SIDE DISH

2 ROT two course text A TWOROT 2 SWAP two move A TWOSWAP 2 VARIABLE two variables A, H LITU <+ addr> ABS ab signaling A ABS AGAIN over again A, C, H BRA <+ addr> AND and A AND BASE basis A USERVAR 1 BUFFER: leveling memory colon G, H LITU <+ addr> C! c save A BStore C @ c invoke A BFETCH C +! c plus save G BINCR CATCH Catch A CATCH CELL cell G FOUR CELL + cell plus A SADDLIT 4 CELLS cells A SMULLIT 4 CHAR sign A PLIT <n> CHAR + plus sign A SADDLIT 1 CHARS letters A Noop COMPARE clay A BCMP CONSTANT constant A, H LIT <X>

SIDE DISH

D + d plus A VADD DEPTH depth A DEPTH Deng d neguj A VNEG TO Make A, C, H RDO DROP Exclude A DROP DUP reproduces the A DUP ELSE otherwise A, C, H BRA <+ addr> ENDCASE end case A, C, H DROP endof end (of) A, C, H BRA <+ addr> EXECUTE Make A ICALL EXIT output A, C RETURN FILL Fill A BFILL GET_MSECS Get milliseconds G GETMS HOLD uchovaj A HOLD I and A, C RI IF if A, C, H BZ <+ addr> INVERT turn thee A INVERT J j A, C RJ LEAVE Exclude A, C RLEAVE <+ addr> LITERAL literal A, C, H LIT <n> LOCALS locations with a line A, C, H <method> <addr>

SIDE DISH

LOOP loop A, C, H RLOOP <+ addr> lShift 1 preraď A SHLN M * m star A MMULT M / MOD m slash module G MSLMOD MAX maximum A MAX MIN minimum A MIN MOD modulus A MOD MOVE Move A BMOVE MS millisecond A MS NEGATE negates A NEGATE NIP oddel A NIP NOT not SETEQ OF from A, C, H ROF <+ addr> OR or A OR OVER through A OVER PICK select A PICK PLUG Put the H LITC <+ addr> RECURSE recursion A, H CALL REPEAT repeat A, C, H BRA <+ addr> -Rotate minus running G ROTBAL R @ r invoke A, C RFETCH R> r z A, C RFROM

SIDE DISH

ROT running text A ROT rshift r shift A shRNA SIGN mark A SIGN Socket socket H DOSOCKET <n> SWAP Move A SWAP THROW throw the A THROW TIMESDÁTE time and date A gETTY -TRAILING minus trailing A MINUSTRAILING TUCK hide A TUCK U < u less than A CMPLTU U <= u less than or equal to G CMPLEU U> u greater than A CMPGTU U> = u greater than or equal to G CMPGEU UM * um asterisk A MMULT UM / MOD um slash module A MSLMODU UMOD u modulus G MODE UNTIL until A, C, H BZ <+ addr> USER taking! G USERVAR <n> VALUE Value A, H LITD <+ addrxmethod> VARIABLE variable A, H LITU <n> WHILE while A ₍ C, H BZ <+ addr>

SIDE DISH

WITHIN inside A WITHIN XOR exclusion or A XOR

1.2 Unification

1.2.1 Number formats

Numbers larger than one byte are transmitted in entitlement symbol programs in a large ending double complementary form, the most significant byte being the first. Within EPICode, numbers should always be accessed by operators of the correct format to allow programs to store numbers in the form best suited to the underlying architecture.

Multiple precise data types are held in the stack with the most prominent cell at the very top. These types of data are held in memory with the most significant cell in the lowest addressable cell within the multi-cell type.

1.2.2 Control structures and relative indicators

Control structures are made up of entitlement control symbols (BRA, RLOOP, etc.) followed by a four-byte, two-byte, or single-byte signposted relative pointer. The relative pointer following the authority check symbol is added to the Token Pointer (TP) indicator when the relative pointer has been invoked. If the branch permission symbol is in addr, the destination address is addr + 2 + offset for a one-byte relative

ANNEX Indicator (SBRA), addr + 3 + offset for 2-byte relative indicator (BRA) and in addr + 5 + offset for 4-byte relative indicator (EBRA).

Authorization symbols assuming four-byte relative pointers are available only to terminal-specific code in virtual machine implementations that support a 32-bit linear address space for the code.

1.2.3 Addresses

User-defined procedures defined by their addresses within EPICode. If authority symbols are translated or machine language compiled for larger processors, the authority symbol space address will not match the actual code address.

1.3 Typing Data

Most entitlement symbols work with data-size variables and with the sign or unsigned interpretation specified by the entitlement symbol, but instructions that access memory in the frame memory can take over the data type suppression specified by the prefixed entitlement symbol. Set of byte codes shown in tab. 1 is reserved for such prefixed authorization symbols, but normally only SBYTE and UBYTE are used.

Data types that require less than one cell (1 byte) are retrieved from memory using a byte or prefix suppressed operator. If the data type is

The APPENDIX is implicit or specified, the data is extended by the sign to the width of the cell. If the unsigned data type is implicit or specified, the data is null.

Tab. 1: Data type prefixes

prefix In short description size SBYTE SB byte sign 1 byte UBYTE UB unsigned byte 1 byte Slongo SL long sign 4 apartments ULONG UL unsigned long 4 apartments SVLONG SV very long with sign 8 apartments UVLONG UV very long unsigned 8 apartments

1.4 Arithmetic

Addition and subtraction operations that overflow the size specified for the returned results return that result by the [unsigned maximum value matched to dimension] + 1.

Save operations whose destination is smaller than the elapsed value size will save the value limited to the width of the destination.

Division operations are symmetrical, i. from. rounding is always towards zero regardless of the sign.

1.5 Primary Authorization Symbols

The entitlement symbols shall be subdivided into, for convenience,

ANNEX to several logical sets and are listed below in separate sections. All authority symbol values are hexadecimal.

The data type prefixes applicable to entitlement symbols are listed explicitly in the list using the abbreviations shown in Tab. 1. Any primary entitlement symbol that is prefixed with an authorization symbol, not in its prefix, shall be invalid, and the execution of such an authorization symbol shall cause the ILLOP exception to be thrown. The standard type for the authorization symbol is in italics and is always listed first. The default data type prefix is redundant and invalid if used for the authorization symbol prefix as above.

1.5.1 Set of operations

NOOP r -;

No action taken.

BFETCH (addr - num)

Get an 8-byte byte from the given address, the sign expands it.

LIT (- x)

Return the cell that follows the inserted data.

LITC

Return the cell that follows embedded as a literal that is the address in the code image. The literal value can be in

ANNEX moved to the image by the deployment program.

OA LITD

Return a cell that follows an inserted literal that is an address in the initialized data space. The value of the literal can be moved in that image by the boot loader.

OB LITU

Return a cell that follows an inserted literal that is an address in the uninitialized data space. The value of the literal can be moved in that image by the boot loader.

OC PLIT

Return the byte that follows the embedded. The byte is null extended to 32 bits.

FROM NLIT (- num)

Return the byte that follows the embedded, null extended to 32 bits, and then negated.

OE HLIT

Return the double-byte value that follows the inserted value. The value is null extended to 32 bits.

HLITC

Return the address resulting from the addition of an unsigned double-byte value that is pasted into the base address of the code image. The value is null extended to 32 bits.

SIDE DISH

SLITD (-a-addr)

Return the address resulting from the addition of an unsigned byte that follows an embedded interpreter interpreted as a base relative pointer in cells to the base address of the initialized data. The byte is zero extended to 32 bits and multiplied by 4 to give a relative pointer in bytes.

HLITD

Return the address resulting from the addition of a double-byte value that is inserted in the base address of the initialized data. The value is extended to 32 bits by sign.

SLITU (- addr)

Return the address resulting from the addition of the unsigned byte that follows the inserted, interpreted as the base relative pointer in the cells to the base address of the uninitialized data. The byte is zero extended to 32 bits and multiplied by 4 to give a relative pointer in bytes.

HLITU

Return the address resulting from the addition of a double-byte value that is pasted to the base of uninitialized data. The value is extended to 32 bits by sign.

ADDLIT (x -> - x?)

Add data to the cell that follows inserted into χ _χ , giving x ₂ .

SADDLIT (x ·, - x x)

Add the Iteral from a single-byte value with the sign x _x giving x ₂ .

SIDE DISH

SUBLIT (Χ _τ - x?)

Subtract the data in the cell that follows the inserted from χ _{1 #} providing x ₂ .

1A

1C

SSUBLIT (Χχ - ^x 2 ~ ^ť )

Subtract the single-byte signed value from χ ^, giving x ₂ .

VSUBLIT (d-d-lit)

Subtract the signed 8-bit signed value from the double number d.

ID SMMULIT (num-num * lit)

Multiple num single-byte sign literals that follow embedded.

1E SDIVLIT (num - num / lit)

Den num a one-byte literal sign followed by an embedded one.

DIVU (u _± u - u ₃ )

Divide u ₃ using u ₂ (unsigned) giving u ₃ .

3A SHRU (u-u »1)

Logical shift at the right one bit by inserting a zero bit.

Note. SETXX operators perform a comparison with zero, the label is set according to the results of the comparison.

à

SIDE DISH 42 (num - flag) Setgás Return TRUE if num <0 (with sign). 45 (num - flag) Setla Return TRUE if num> o (with sign). 48 (υγ ₂ - flag) CMPGEU Compare the values and if Uj> u ₂ . u ₂ unsigned, returning TRUE, 4C cMPG (num ^ num? - flag) Compare num · ^ values and num ₂ with a return sign TRUE if num ^> num ₂ · 4F cmpl (num ^ numj - flag) Compare num ^ values and num ₂ with a return sign TRUE if num ^ <num ₂ .

The following authority symbols provide access to the frame memory.

50..53 PFRFETCH 2 ... PFRFETCH4 (- num)

Short form equivalents for SFRFETCH n (q.v.), where n is 2..5. Possible data type overrides include: SL, SB, UB.

54..5F TFRFETCH12 ... TFRFETCH1 (-num)

Short form equivalents for SFRFETCH n (q.v.), where n is -12 .. -1. Possible data type overrides include: SL, SB, UB.

SIDE DISH

60..63 PFRSTORE2 ... PFESTORE5

Short form equivalents for SFRSTORE n (q.v.), where n is 2..5. Possible data type overrides include: SL, SB.

64..6F TFRSTORE12 ... TFRSTORE1 (num -)

Short form equivalents for SFRSTORE n (q.v.), where n is -12 .. -1. Possible data type overrides include: SL, SB.

SFRFETCH (- num)

Invokes a num value (by standard program, cell) with a one-byte relative frame pointer inserted. A relative pointer is interpreted as a cell index (i.e. multiplied by 4 to produce a byte-addressed relative pointer) for a standard data type and as a byte index to suppress byte size data. Note that SFRFETCH 0 and SFRFETCH 1 return inner frame control data without message meaning to the calling program, and thus do not create valid frame references. Thus, the parameters start at SFRFETCH 2 and the temporary variables begin at SFRFETCH -1, because the frame stacks are increasing in memory downwards. Possible data type overrides include: SL, SB, UB.

SFRSTORE

Store the num value (by standard program, cell) in the argument with the one-byte relative pointer inserted in the frame pointer. The relative pointer is supplied as an embedded value that is treated as a cell index (i.e. multiplied by 4 to produce a byte-addressed relative pointer) for a standard data type, and as a byte index to suppress byte size data. See SFRFETCH for further details. Possible data type overrides include: SL, SB.

SIDE DISH

FRFETCH

Invokes a num value for a signed signed pointer from a frame pointer. The relative indicator is provided by a two-byte insertion value. See description of SFRFETCH for details. Possible data type overrides include: SL, SB, UB.

FRSTORE (num -)

Store the num value in the argument for a signed signed pointer from the frame pointer. The relative indicator is provided by a two-byte insertion value. See SFRSTORE for more details. Possible data type overrides include: SL, SB.

SFRADDR

Return an address to a frame at a signed signed pointer from a frame pointer. The relative indicator is provided by a one-byte insertion value that is multiplied by 4 to produce a byte relative indicator for the standard data type and is used directly as a byte index to suppress byte size data. Possible data type overrides include: SL, SB.

FRADDR

Return an address to a frame at a relative pointer of a signed cell from a frame pointer. The relative indicator is provided by a two-byte insertion value that is multiplied by 4 to produce a byte relative indicator for the standard directly as a byte index for sizes.

data type and byte data suppression is used

Number Conversion Function For Authorization Symbols Providing Forth: NMBR Support in Names of Authorization Symbol Names A number is pronounced. The LTNMBR, NMBRS, and TONUMBER authority symbols use the user base variable (BASE) as the base variable.

SIDE DISH

8C UNDER (~ ^{x x x x x} 2)

Reproduce the second item in the tray.

9C ZERO

Omit the value 0 in the stack.

B ONE

Omit the value 1 in the stack.

9E MINUSONE

Leave -1 in the stack.

AO INDEX (addr-γ num-addr ₂ )

Multiply num four and add to addr _lt to create addr ₂ ·

A2 EDOCREATE (-a-addr)

Return an address to a data space whose relative pointer tracks the inserted cell immediately after this authorization symbol and executes a standard return subroutine. This authorization symbol is used to identify the data area by calling its corresponding procedure, allowing the creation of position-independent data tables.

A3 EDOCLASS (-a-addr)

A branch to an address of a code space whose relative pointer is contained in an inserted cell that follows an address being pushed into the data stack resulting from the addition of an unsigned relative pointer that follows in the next inserted cell

ANNEX (i.e., relative to the code pointer) to the base address of the initialized data space. This authority symbol is used to identify the structure of data in the program memory and to transfer control to a standard program that processes it and provides the basis for a simple class mechanism.

A4 DOCREATE (-a-addr)

Return an address to a data space whose relative pointer follows the entered double-byte value immediately after this authorization symbol and executes the standard return subroutine. This authorization symbol is used to identify the relative data pointer by calling its corresponding procedure to create position independent data tables.

A5 DOCLASS (-a-addr)

A branch to an address of a code space whose relative pointer is contained in an embedded cell that follows the address being pushed into the data stack resulting from the addition of an unsigned relative pointer that follows in two bytes further inserted (i.e. relative code pointer) data. This authority symbol is used to identify the structure of data in the program memory and to transfer control to a standard program that processes it and provides the basis for a simple class mechanism.

A6 ECALL

Following an embedded cell calls the procedure using that cell as a byte relative pointer to the code space.

A7 SCALL

Followed by one inserted byte calls the procedure using. of this byte as a byte relative pointer to the code space.

SIDE DISH

A8 CALL

Followed by an embedded two-byte relative pointer, it calls the procedure using this value as a signed byte relative to the code space.

AB SMAKEFRAME arams · · · * j “) edited by two unsigned single-byte literals containing the first params, the number of cells constituting the procedure parameters, and then the temps, the number of cells of the temporary variables. It assigns params + temps + 2 cells, and then sets the normal frame pointer to point to a new frame. This authority symbol allows access to procedure parameters and temporary variables using FRFETCH and FRSTORE.

The virtual machine is allowed to create frames in the return stack, so the use of frames is limited by rules that generally apply to the use of the return stack. The procedure parameters will be moved from the data stack to the frame using SMAKEFRAME so that they can be accessed using FRFETCH and FRSTORE. If it is not possible to create a frame of the desired size, FRAME_STACK_ERROR will be used.

AC MAKEFRAME arams * * *) edited by two unsigned double-byte literals containing the first params, the number of cells constituting the procedure parameters, and then the temps, the number of cells of the temporary variables. See SMAKEFRAME for more details.

AD RELFRAME ()

Reset the frame pointer to its previous value and release the normal frame.

1.5.2 Set of branches

These authorization symbols contain the usual operators of pushbutton branches plus runtime for Forth words

SIDE DISH

TO ? DO LOOP + LOOP LEAVE I and J.

AF EBRA -;

Always branch. Four-byte relative indicator.

BO EBZ (num -)

Branch if num = 0. Four-byte relative indicator inserted.

BI EBNZ (num -)

The branch if num does not equal zero. four - byte relative indicator.

B2 SBRA

Short branch. Byte embedded relative pointer with sign. ¹

B3 SBZ (num -)

Short branch if num = 0. Byte embedded relative pointer with sign.

B4 SBNZ (num -)

A short branch if num does not equal zero. Byte embedded relative pointer with sign.

B5 BRA

Unconditional branch. A two-byte embedded relative pointer with a sign.

SIDE DISH

ΒΝΖ (num -)

The branch if num does not equal zero. A two-byte embedded relative pointer with a sign.

1.5.3 Suppress data type and code box

This group allows you to overcome the 8-byte authorization limit. Note that their stack effect depends on the following authorization symbols. A pair of authority symbols is referred to as a secondary authority symbol.

Extended authorization symbols for data types occupy the authorization symbols CO to CF. Unused authorization symbols in this range are reserved for future use when additional data type prefixes are required.

Cl SBYTE (-)

Signed apartment.

C 2 ACCOMMODATION (~)

Byte without sign.

C5 SLONG

Signed 32-bit long.

C6 ULONG

Unsigned 32-bit long.

1.5.4 Symbols of authorization for handling sleeves

D2 DOSOCKET

Followed by an inserted byte (0..63) that specifies the required function number. The effect of the tray is

ANNEX defined by the function connected to the socket.

D3 INDOSOCKET

Performs the socket function whose socket number (0..63) is specified by u. The effect of the lower level tray is defined by the function connected to the outlet. 24 ANS Forth (invalid numeric argument) exception will be thrown if u is greater than 63.

1.5.5 Control kit

E6 IMCALL

Perform the function of the module whose module number (0 - 255) is given in the farthest inserted byte and whose function number (0 - 255) is given in the next inserted byte. The effects of the stack depend on the function being called.

E7 CLASSPROC

During the deployment, CLASSPROC marks the entry into the manipulation class code. It is used to aid compilation and can be implemented as a NOOP.

F9 SYSFUNC

The extension of the authorization symbol box is treated as the first byte of the secondary authorization symbol. Calls the standard program specified by the following byte. A supported set of secondary authority symbols is defined in section 1.7. The stack effect is defined by the specified standard program.

1.6 Sockets

The first eight secondary socket authorization symbols are reserved for socket management functions, and the defined management functions are described below. Other sockets (D2 08 to D2 3F) are for application use.

SIDE DISH

SETSOCKET

F9 90 (xp u - flag)

Set execution indicator xp to be a socket handler function that causes xp to be executed by the next execution of DOSOCKET <u>. Before the execution pointer is set, the running procedure is installed using SETPLUGCONTROL to determine if a new xp can be plugged into the socket. flag is the value returned by this procedure. SETSOCKET only sets the pointer if the flag is FALSE, otherwise the pointer is delayed. The -24 exception (invalid numeric argument) will be thrown if u is greater than 63.

D2 00 SETPLUGCONTROL (xp-)

Saves an execution indicator of the xp procedure written by the user, which will be run with SETSOCKET to determine if a plug can be plugged into the socket. The operation of this procedure (which for purposes of illustration as PLUGCONTROL) must be:

(u - flag) where u is the socket number and flag returns FALSE if insertion can occur or TRUE if insertion cannot occur. In addition, the PLUGCONTROL procedure must throw an exception - 24 (invalid argument) for u values except for the range 0-63.

The standard operation of the PLUGCONTROL procedure is installed by the virtual machine to return FALSE for all u values, allowing all slots to be inserted.

D2 03 OSCALLBACK (dev fn num ₁ num ₁ -ior)

It calls the standard operating system program with the parameters: dev selects the required 1/0 device for the fns function by the 32 bit parameters num ^ contained in the num ₂ field returning the ior, whose meaning depends on implementation. num · ^ and num ₂ correspond respectively to arvc and argv using c.

Note that this socket is implementation dependent and is provided so that a specific terminal program (TRS) written using EPICode can provide

ANNEX operating system standard callback programs. If the specified function is not supported, a -21 exception (unsupported operation) is thrown.

1.7 SYSFUNC I / O Kit

This set defines the functions that are available with the SYSFUNC authority symbol, which acts as a generalized interface for the underlying standard operating system programs.

1.7.1 Accessing the Device

Each device is assigned a unique device number. Ior status codes are device dependent, except that ior 0 always indicates success.

F9 00 DKEY (dev - echar)

Read character from input device dev.

F9 01 DKEYTEST (dev - flag) dev

Return TRUE if the character is ready to be read from the input device dev.

F9 02 DEMIT

Transfer char to output device dev.

F9 03 BEEP (for dev)

Ask the dev input device to generate sound for milliseconds. This feature may suspend processing for a specified duration.

SIDE DISH

F9 04 DREAD (addr only dev - ior)

Read the string from the dev input device by returning the device dependent ior. The returned string contains only a lower-order byte character read from the keyboard device.

F9 05 DWRITE (addr dev-ior only)

Write the string to the dev output device by returning the device dependent ior.

F9 06 DSTATUS (dev-ior)

To return the status ior of a resource connected to the dev device, where in general a ready or capable service is marked as o and unprepared is marked with any other value, a specific device can return nonzero values that are significant to that device. If the device was selected by the previous execution of the OUTPUT authority symbol, DSTATUS should return unprepared until the function that is released to OUTPUT is completed.

F9 07 DIOCTL (dev fn num a-addr - ior)

Perform the IOCTL fn function for the dev channel with num cell size arguments in the a-addr array.

F9 09 OUTPUT (xp dev - ior)

Execute a procedure whose execution indicator is given xp with the output pointing to the dev device. When returning from OUTPUT, the normal output device is not affected (see GETOP). ior is returned as zero if the procedure is feasible. All exceptions resulting from executing xp are caught by the virtual machine and cause the OUTPUT to terminate immediately.

100

SIDE DISH

DWRITESTRING

F9 (dev -)

This authority symbol is followed by a string of characters stored in the sequence of authority symbols as a read byte followed by so many bytes. The DWRUTESTRING authority symbol writes characters to the selected dev device. Execution continues immediately after the last character.

F9 0A GETOP

Returns the device dev last selected by SETOP or while executing a function passed to OUTPUT. Used to find a standard device for device-oriented I / O operations. This feature allows normal device-dependent functions to be easily implemented.

F9 0B SETOP (dev -)

Used to set the default dev device returned by GETOP for device-oriented I / O operations. This feature allows normal device-dependent functions to be easily implemented.

F9 OC FORMFEED

Performs a new device-dependent form on the dev device, such as clearing the screen (terminal display) or dropping the box (printer).

F9 OD CR (dev -)

Perform a new device-dependent line on device dev.

F9 0E SETXY (num ^ num2)

Perform on device dev the action to set the device-dependent absolute position using num-y as the x-coordinate and num ₂ as the y-coordinate.

101

SIDE DISH

1.7.2 Time manipulation

Forth Standard Words.

1.7.3 Handling languages and messages

The authorization symbols in this group provide a mechanism for manipulating languages and for selecting and displaying messages.

20 CHOOSELANG (addr - flag)

Select the language whose ISO 639 language code is given by two characters in addr. If flag is TRUE, the language has been found and is now a common language. Otherwise, the calling program should select a different language. At least one language (machine language of the terminal) is always available.

F9 20 CODEPAGE (num - flag)

Attempts to select a permanently stored page of num codes. Pages are numbered according to ISO 8859 (0 = normal character set, 1 = Latin 1, etc.). flag is TRUE if the code box has been selected.

F9 21 LOADPAGE (addr - flag)

Install the code page in the addr terminal (this page will usually be found in the card), flag indicates successful page feed. Page installation can be performed if a new ICC message table has been loaded that requires a code page that is not available in the terminal.

F9 23 INITMESSAGES

This feature deletes the publisher's private messages numbered from CO to FF (hex) and any messages installed using LOADMESSAGES. This function should be called after each user session.

102

SIDE DISH

LOADMESSAGES

F9 24 (c-addr-)

Install the message table in a convenient location in the temporary message database, c-addr specifies the location of the message table definition containing the page code to use for messages, a two-letter language code in accordance with ISO 639, and for messages to be installed.

F9 25 GETMESSAGES (num-c-addr len)

Returns string parameters for num messages. The trailing spaces are removed from the length of only the string.

F9 27 UPDATEMESSAGES (addr len -)

Install the message table into permanently stored language tables. If a language with the same code is already included, it will be replaced. Otherwise, a new language will be added. If there is not enough space for the new language, THROW will be issued with code 22 (TOO_MANY_LANGUAGES).

addr specifies TLV locations containing the definition of the message table, including the page code for use for messages, the two-letter ISO 639 language code, and the messages to be installed.

F9 28 MESSAGESIZE (- only)

Returns the standard message length for the terminal.

F9 29 TYPEMESSAGE (addr len -)

Displays the string on the terminal message line.

1.7.4 Handling ICC Cards

The permission symbols of this group provide a mechanism for manipulating the IC card reader.

103

SIDE DISH

INITCARD

F9 30 (num-ior)

Select the num ICC reader where num is 0 or 1.

F9 31 CARD (c-addr ^ as ^ caddr2 Ien2 ~ ien caddr2 ₃₎

Send the c-addr ^ only ^ data to the card and receive the c-addr _{2 data} only ₂ - The returned 2en ₃ indicates the actual length of the received string.

The c-addr ^ only ^ buffer must contain: Four-byte ISO standard header (class, instruction, PI, P2).

Option data (length followed by length bytes, where length can be 0 - 255).

Cache c-addr _{2 2} 2-ene must provide sufficient priestorpre response from the card plus two bytes containing the status of SW1 and SW2.

Error handling is done internally within the CARD.

F9 32 CARDON (c-addr only · ^ - c-addr only ₂ ior)

Connect the power supply to the ICC and perform the card recovery function. c-addr only, provides a buffer where the restore response will be placed, 2en ₂ is the actual length of the returned string.

F9 33 CARDOFF

Disconnect the ICC from the power supply. It is executed when all transactions are complete.

F9 35 CARDABSENT (- flag)

Return TRUE if ICC card is not present, otherwise return FALSE.

1.7.5 Handling of magnetic strips

The authorization symbols in this group provide a mechanism for manipulating the magnetic tape device.

104

SIDE DISH

F9 38 FROMMAG (c-addr only ^ num - c-addr only ₂ ior)

Read one or more ISO magnetic strips. The operation can be interrupted by the user by the CANCEL key or by a timeout. num is the ISO identifier (s) of the magnetic stripe (s) for reading, c-addr is the destination address for the string, and the maximum length (at least 78 bytes for IS01, 41 bytes for IS02 and 108 bytes for ISO3 or their sum to read multiple magnetic strip). On return, it indicates only _{2 the} actual length of the read string.

F9 39 TOMAG (c-addr num -ior only)

Write one ISO magnetic strip. The data is c-addr buffered only and will be written to the num bar (1-3). The operation can be interrupted by the user by the CANCEL key or by the timeout.

1.7.6 Modem Handling

The authorization symbols in this group provide a mechanism for manipulating the modem device.

F9 40 MODEMCALL (num ^ num ₂ num · * num ^ num ₅ c-addren-ior)

It calls a number using the internal modem of the terminal, num ^ and num ₂ indicate the input and output link speed for use (from 75 to 19200 baud). The actual supported speeds are defined by implementation. num ₃ indicates the equality (0 = none, 1 = odd, 2 = even) num ^ indicates the number of bits to use (7 or 8) num ₅ indicates the number of bits used for transmission (1 or 2 bits).

c-addr len is a string containing the phone number to call. can be inserted for a call waiting tone.

If the first character of this string is ‘P ', pulse dialing is used instead of standard tone dialing.

F9 41 MODEMHANGUP (- ior)

This function is used to end a normal modem session.

105

SIDE DISH

TOMODEM

F9 42 (c-addr len-ior)

Transfer the string in c-addr only to the created modem session.

F9 43 FROMMODEM (c-addr only ^ - c-addr only ₂ ior)

Receives a string from the modem, c-addr is the destination address for the string, and only ^ is the maximum length. On return, it indicates only _{2 the} actual length of the read string. If no characters are received during a specific period, a timeout occurs.

F9 44 (- ior)

This function sends a modem.

MODEMBREAK interrupt to connected session

1.7.7 Black List Management

The authorization symbols in this group provide a mechanism for manipulating the black list file.

F9 48 INITBLACKLIST

This function initializes the black list to an empty state.

F9 49 BLACKLISTINSERT (c-addr len - flag)

This function inserts input in c-addr only in a list that is maintained in categorized order.

This feature must be used when updating the list. The flag returned is FALSE if the insert was successful (no entry found in the existing list and the list was not full).

106

SIDE DISH

F9 4A INBLACKLIST (c-addr ^ only ^ - c-addr2 only ₂ flag)

This function attempts to find the c-addr ^ only ^ key in the list.

c-addr ₂ only? they contain a search result (containing the remaining bytes from the selected input and some other information bytes) if the key was found.

The flag returned is FALSE if the number was found.

F9 4B BLACKLISTDELETE (c-addr len - flag)

This function removes the entry from the list, where c-addr only is the entry key to remove. It can be up to 18 bytes long.

The flag returned is FALSE if the deletion was successful (input was found).

1.7.8 Support for security algorithms

The authorization symbols in this group provide support for initializing and using security services.

F9 50 INITSECALGO (c-addr num flag only) c-addr is the buffer initialization address and is only its length. The input parameter (s) may vary for each algorithm, although the key should normally pass to this initialization, flag is FALSE if initialization was successful.

F9 51 SECALGO (c-addr · ^ c-addr only ₂ num - flag)

When c-addr is the input data buffer for calculation and only the length thereof, c-addr ₂ is the output buffer for storing the results.

flag is FALSE if the calculation was successful.

107

SIDE DISH

POWERLESS

1.7.9 Terminal Services

58 (- flag)

Returns FALSE if there is enough performance to complete a regular transaction.

1.7.10 Database services

The following authority symbols provide a mechanism for manipulating databases.

F9 61 DBMAKECURRENT (a-addr -)

Make a database whose DPB is in an a-addr regular database.

F9 62 DBSIZE (- only)

Returns the size of the record cache that provides a window to a regular record in a regular database.

F9 63 DBFETCHCELL (num ^ - nunij)

Returns a 32-bit value of num ₂ ^{from a} cell in the byte relative pointer num · 2 aligned by the cell in the current database entry.

F9 64 DBFETCHBYTE (num-char)

Returns a one-bit char value from the byte relative num indicator in the current database record.

F9 65 DBFETCHSTRING (num len - addr len)

Returns the parameters of the addr alen byte sequence in a relative num pointer and a length only in the common database record.

108

SIDE DISH

F9 66 DBSTORECELL (num ^ num? -) i

Saves the 3 2 bit value of num · ^ into a cell in the relative num ₂ pointer aligned by the cell in the current database record and updates the database record.

F9 67 DBSTOREBYTE (char num -)

Stores a one-byte char value in the byte relative pointer num in the regular database record and updates the database record.

F9 68 DBSTORESTRING (addr len ^ num only ₂ ~)

It stores only a maximum of ₂ bytes of the byte sequence in the addr in the relative num pointer in the common database record. If only-j ^ is less than a _2, then the destination is cached record database space is filled with only _{the second}

F9 69 DBINITIALIZE (-)

Initializes the regular database to all zeros and sets the current and available database record numbers (see DBRECNUM and DBVAIL) to 0.

F9 6A DBRECNUM

Returns the current record number.

F9 6B DBCAPACITY

Returns the total number of records that a regular database can contain.

F9 6C DBVAIL

Returns the number of records of the next available record in a regular file.

109

SIDE DISH

F9 6D DBADDREC

Add a record to the end of the regular database with the record number given by DBVAIL.

F9 6F DBSELECT (num -)

Select the num record in the current selected database.

F9 70 DBMATCHBYKEY (addr len - flag)

Search for a common database to compare in the key field against the string specified by addr and len. It can only be shorter than the defined key field length for this structure with the remaining characters that are compared with the empty characters. The comparison is successful, becomes normal, and the flag is FALSE.

This authority symbol can only be used with an ordered database.

(19, ASCII). If comparative record

F9 71 DBADDBYKEY (addr len - flag)

Search for a common database to compare in the key field against the string specified by addr and len. It can only be shorter than the defined key field length for this structure with the remaining characters being compared with the empty characters. The comparison is successful, becomes normal, and the flag is TRUE. If the comparison is unsuccessful, the 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 key field containing the key.

This authority symbol can only be used with an ordered database.

(19, ASCII). If comparative record

F9 72 DBDELBYKEY (addr len - flag)

Search for a common database to compare in the key field against the string specified by addr and len. It can only be shorter than the defined key field length for this structure with the remaining characters

110

Appendix compares with white space (20, ASCII). If the comparison is successful, the comparison record is removed and the flag is FALSE. The removal action closes any possible hole in the physical implementation by performing appropriate action to physically move or rearrange a record in a pre-initialized database.

This authority symbol can only be used with an ordered database.

F9 73 DBSAVECONTEXT (-)

Causes the server to accumulate common context information containing a common database, a common record number, and any child information. The server is authorized to use the virtual machine return memory to permanently store the context information, and the client software must therefore follow the general rules that apply when using the return stack.

F9 74 DBRESTORECONTEXT

Causes the server to recover the most recently stored relationship information (see DBSAVECONTEXT). The server is authorized to use the virtual machine return memory to permanently store the context information, and the client software must therefore follow the general rules that apply when using the return stack.

1.8 TLV control

The authorization symbols described in this section provide TLV control and access function.

1.8.1 String processing support

F9 78 PLUGSTRING (c-addr ^ len ^ c-addr ₂ only ₂ - c-addr ₂ years)

Store the string in c-addr, at only · bytes at the end of the string in c-addr? at only ₂ bytes. Return the beginning of the destination string (fc-addr ₂ ) and the sum of two lengths (^ only). There must be space at the end of the destination string to contain both strings.

111

.. í

SIDE DISH

F9 79 CPLUSSTRING (char c-addr len - c-addr len + 1)

Save the char at the end of the string in c-addr at just bytes. Return the origin of the destination string (c-addr) and the length of the resulting string (plus 1 only). There must be space at the end of the destination string to contain an additional character.

F9 7A MINUSTRAILING (c-addr len-y-c-addr len2)

If lenj is greater than zero, only ₂ is equal to ^ less the number of spaces (20. ASCII) at the end of the character string specified by c-addr len ^. If only ^ is zero or the entire string consists of spaces, it is only ₂ zero.

F9 7B MINUSZEROS (c-addr only ± - c-addr only ₂ )

If only ^ is greater than zero, only ₂ equals less than the number of zeros (0. ASCII) at the end of the character string specified by c-addr len-^. If only · is zero, or the entire string consists of zeros, it is only ₂ zero.

F9 7C STORECOUNT (char c-addr-)

Save char number to apartment in c-addr. Generate the discard code STRING_TOO_LARGE if char is greater than 255.

1.8.2 Accessing the TLV cache

F9 80 TLV (num-c-addr only fm t)

Return access parameters for TLV flagged as num. This can generate the UNDEFINED_TLV throw code.

F9 81 TLVFETCH (c-addr ^ len ^^ fmt-num / c-addr ₂ only ₂ )

Return the contents of the internal TLV cache according to its TYPE field, which is the lower eight bits of fmt. Type codes 0 and 2 return numbers to the stack, while other codes return string pointers. Address returned by field

112

The type code ANNEX 3 is temporary and must be moved immediately to a more permanent location. only ₂ returned for strings is the same as the last buffered one.

F9 82 TLVSTORE (num c-addr? Only ₂ fmt / c-addr ^ only · ^ c-addr ₂ only ₂ fmt-) Set the contained TLV internal buffer according to its TYPE field, which is the lower eight bits of fmt. Type codes 0 and 2 take numbers in the stack, while other codes take string pointers. This action sets a separate status bit for this TLV.

F9 83 TLVBITFETCH (c-addr - flag)

Return the results of masking the contents of the internal TLV cache specified by the sequence in c-addr against the array of values at that location. This can generate the UNDEFINED_TLV throw code. flag returns TRUE if all the bits defined in the mask are in the internal buffer. Otherwise, FALSE is returned. Only apartments occupying the shorter of the two locations are checked.

F9 84 TLVBITSTORE (c-addr flag)

Adjust the contents of the internal TLV buffer specified by the sequence in the c-addr based on the array of values at that location. If flag is FALSE (0), then all bits defined there will be turned off. Otherwise, they will all be turned on.

1.8.3 TLV processing

F9 85 PARSETLV (c-addr len -)

Only process bytes in c-addr for TLV sequences. This can generate the UNDEFINED_TLV throw code. Each flag field encountered places the field length bytes from its value field in the internal buffer and sets a separate status bit. When a constructed flag field is encountered, all internal TLV buffers that are defined as attached to it are cleared before the value field is

113

ANNEX separate for TLV sequences. No exception will be generated if a TLV is encountered in a constructed template that has not been defined because it is attached to it.

F9 86 PLUSDOL (c-addr 2-addr ₂ 2en ₂ - c-addr ₂ 2en ₃ )

Process only -L bytes in c-addr ^ for flags and length fields. This can generate the UNDEFINED_TLV throw code. Each flag field encountered places the field length bytes from its internal buffer into a value array at the end of the output string in c-addr ₂ at only bytes. Returns the origin of the destination chain (c-addr ₂ ) and the sum of two lengths (only ₃ ). There must be space at the end of the output string to contain both strings.

F9 87 PLUSTLV (c-addr len ^ num - c-addr len ₂ )

Add the TLV sequence, whose flag is num, to the end of the output string in c-addr at byte bytes. This can generate the UNDEFINED_TLV throw code. Flag, value, and length fields are formatted according to TLV rules based on data in its internal cache. Returns the origin of the destination string (c-addr) and the sum of two lengths (only ₂ ). There must be space at the end of the output string to contain both strings.

F9 89 TLVSTATUS (fmt-num char)

Decode the TLV access fmt parameter status. The returned num is an 0-format indicator, and the bits in the returned char have the following meaning, where bit 0 is a less significant bit:

0 0 = not separated, 1 = separated 1-7 reserved for future use

114

SIDE DISH

1.8.4 Access to TLV sequences

F9 8A STOREBCD (for c-addr len -)

Store the u number as a binary-coded decimal sequence in a string in c-addr at bytes only. The number is formatted for each digit representing a four-bit polbyte in the output string. Leading polbyte will be filled with zeros if necessary. The most important part of the number will be truncated if it is not long enough to contain all the digits.

F9 8B FETCHBCD (c-addr len-u)

Retrieves a number u from a binary-coded decimal sequence in c-addr at bytes only. The number is formatted for each digit representing a four-bit byte in the input string. The DIGIT_TOO_LARGE exception is thrown if any polbyte is not a valid BCD digit.

F9 8C STOREBN (for c-addr only -)

Save the number u as a binary number in a string in c-addr for only bytes. The most important byte number is stored first. Leading flats will be filled with zeros if necessary. The most important part of the number will be truncated if it is not long enough to contain all the digits.

F9 8D FETCHBN (c-addr len)

Invokes the number u as a binary number into a string in c-addr at just bytes. The most important byte of the number is called first. If there are no more than four bytes of data in that location, the most important bytes will be lost.

F9 8E STORECN (c-addry only · ^ c-addr ₂ only ₂ “)

Store the number in c-addr · ^ at only ^ bytes as a compressed number in the string in c-addr? at only ₂ apartments. The number is formatted for each character representing a four-bit polbyte in the output string. The end polls will be

115

ANNEX filled with F if necessary. The number will be truncated if 2en is not long enough to contain all characters (only ₂ <[only, +1] / 2). The discard code DIGIT_TOO_LARGE will be generated if the character in the input string is not a number.

F9 8F FETCHCN (c-addr ^ len ^ - c-addren ₂ )

Invokes a string at the temporary location of c-addr ₂ at 2en ₂ bytes, which represents the compressed number in the string in c-addr 2 at bytes. The number is formatted for each character in the output string representing a four-bit polbyte in the input string. The output string will be terminated if it encounters a polbyte with all the bits set to the end of the string. The throw code DIGIT_TOO_LARGE will be generated if the polbyte in the input string is not a number. The output string must be immediately moved to a more permanent location.

F9 90 TLVFETCHNAME (c-addr ·, - c-addr ₂ )

Separate the TLV sequence in c-addr · ^ for the flag field. Return address c-addr ₂ that is outside the flags field and the num flags field.

F9 91 TLVFETCHLENGTH (c-addr · ^ - c-addr ₂ len)

Separate the TLV sequence in c-addr ^ for the length field. Return the address c-addr ₂ that is outside the length field and only contained in that field.

1.9 Module handling

The following legal symbols provide storage and execution of EPICode modules in a virtual machine.

F9 A0 EXECUTEMODULE (c-addr len - flag)

Boot a module from the module directory using the AID specified by c-addr only. If an error occurs

116

The attachment is a thrown exception CANNOT_LOAD_MODULE. flag is TRUE, if module is not found, FALSE is loaded successfully.

F9 AL INITMODULEBUFFER (-)

Prepare for a new module.

F9 A2 MODULEBUFFERAPPEND (c-addr len -)

Attach the contents of the c-addr-defined buffer and only to the module-acquisition buffer. The CANNOT_ _and _ADD_TO_MODULE exception is thrown if the module cache is not ready or if the module buffer capacity is exceeded.

F9 A3 REGISTERMODULE (c-addr len -)

Record the module cache in the module directory under the given EPICode specified by c-addr only. The resources associated with managing the module cache are automatically released.

F9 A4 RELEASEMODULEBUFFER (J

Free up resources used in the internal module cache. This is required if premature module loading must be terminated by the application without recording the module in the module directory.

F9 A5 DELETEMODULE (c-addr len - flag)

Remove a module whose AID is specified by c-addr only from the module directory, flag is zero if the operation succeeded.

F9 A6 MODULEINFO (c-addr ^ only ^ - c-addr ₂ only ₂ flag)

Return public information in a module that is recorded in the module directory under the AID specified by c-addr ^ len ^. flag is zero if the operation succeeded and the c-addr · ^ data is valid. structure

117

The buffer attachment returned is defined by the function information returned only through EPF_ENTRY.

with this module header privilege symbol. These input entries EPF_VER

F9 A7 LOADCARDMODULE (a-addr -)

Load the module in a-addr. a-addr is the EPICode header address delivered to the internal memory from the card. The BAD_CARD_MODULE exception is eligible if the module violates any pre-condition for loading the card module.

F9 A8 MODULESCHANGED f-u;

Return a value u indicating whether the modules have changed. Bits 0 to 7 define which module classes have been recorded in the module directory since this authorization symbol was last executed. For example, a module recorded with an initial byte AID that is F4 sets bit 4 in the return status. Bits 1 to 31 are reserved for future expansion.

1.10 Handling expandable memory

The following entitlement symbols provide access to an extensible linear memory buffer band in the data space provided and controlled by the virtual machine.

F9 BO EXTEND (only - a-addr)

Expand the elastic band buffer by using only cells by returning an α-addr address aligned by the cell of the first cell in the allocated buffer. ZERO EXTEND returns the pointer to the next unassigned cell. OUT_OF_MEMORY is thrown if insufficient memory is available.

F9 BI BEXTEND (only - c-addr)

Expand the buffer of the elastic band using only bytes by returning the a-addr address of the first byte in the allocated

118

ANNEX Cache. ZERO BEXTEND returns the pointer to the next unassigned apartment. OUT_OF_MEMORY is thrown if insufficient memory is available.

F9 B2 RELEASE l

Free up memory gained through EXTEND or BEXTEND by setting a free pointer to addr. If the addr is invalid (before running the buffer strip buffer or after the normal free pointer), an ANS -9 exception (invalid memory address) is thrown.

Additional Authority Symbols:

F9 BO DSCHECK

Check that it exists at least for the data cells remaining in the data stack. Return FALSE if this is the case, otherwise return TRUE.

F9 BI RSCHECK

Check that there are at least data cells remaining in the return stack. Return FALSE if this is the case, otherwise return TRUE.

1.11 Security commands

Security algorithms may take a few seconds to process on some terminals. The present invention ensures that the present single SECALGO command is decomposed into an initiation and termination component to facilitate the use of concurrent processing implementations. This is examined and the following suggestions are made as an alternative to SECALGO.

F9 56 SECALGOBEGIN (c-addr ^ only c-addr ₂ num -flag)

This calculates the use of the num algorithm. c-addr ^ is an input data buffer for calculation and is only its length. c-addr ₂ is an output buffer at

119

ANNEX Save the results. This function returns a flag indicating FALSE if the calculation could be successfully initialized.

F9 55 SECALGOEND (- ior)

This function returns the ior to show: 0 = calculation completed successfully, -1 = calculation still in progress, 1 = calculation failed.

Exceptional codes

This section contains all the codes used as arguments to the standard THROW exception handling function.

The following table lists the ANS Forth codes used in EPIC cores.

number reserved for

- 3 container overfill

- 4 not filling the cartridge

- 5 return stack overfill

- 6 not filling the return hopper

- 7 Loop too deep during execution

- 9 Invalid memory address

- 10 division by zero

- 11 out of range result

- 12 incorrect adjustment of argument type

- 17 overflow of sample numeric output string

- 20 write to read only location

- 21 unsupported operation

- 23 address settlement exception

- 24 invalid numeric argument

- 25 return stack imbalance

- 26 loop parameters not available

- 27 invalid repetitions

- 28 user interruptions

- 36 invalid file position

- 37 1/0 file exception

- 38 non-existent file

- 39 unexpected end of file

- 53 Exceptional overfilling of the container

- 57 exceptional transmission or reception of a character

Claims (62)

PATENT CLAIMS A transaction management system for executing transactions between a first device and a second device, said first and second devices being adapted to communicate with each other, and at least one of said first or second devices is an integrated circuit card. Said system is characterized in that it comprises: at least one input / output device; a portable virtual machine for interpreting a computer program in said first device, said virtual machine comprising a virtual microprocessor and an exciter for said at least one input / output device, and execution means responsive to said interpreted program for executing said program. 2. A terminal comprising a first device for executing a transaction with a second device, at least one of said first or second devices being an integrated circuit card, comprising: a portable virtual machine interpreting a computer program in said first device, said portable virtual machine comprising: a virtual microprocessor and driver for at least one input / output device and execution means responsive to said interpreted program for executing said program. 3. A self-contained portable smart card comprising a first device for executing a transaction with a second device, wherein said smart card with and 121, characterized in that it comprises: a portable virtual machine comprising a virtual microprocessor and an exciter for at least one input / output device. The system of claim 1 or the input terminal of claim 2 or the smart card of claim 3, wherein the machine instructions of said virtual machine are a set of authorization symbols, said authorization symbols being order byte codes. The smart card according to claim 3 or 4, further comprising a computer program stored on said smart card, said virtual machine interpreting said computer program, and execution means responsive to said interpreted program for executing said program. The system or terminal of claim 4 or the smart card of claim 5, wherein said computer program is written as a sequence of authority symbols selected from said set of authority symbols and corresponding input data. A system or terminal according to claim 4 or a smart card according to claim 5, characterized in that said sequence of authority symbols is transmitted in a module comprising a sequence of authority symbols together with corresponding input data required to execute the module. 8. System or terminal or smart card according to 122 of claim 7, characterized in that said module also includes a memory requirement data for carrying out said module. The system or terminal or smart card of claim 8, wherein the virtual machine also includes means for loading said module and interpreting the authorization symbols contained therein. The system or terminal or smart card of claim 9, wherein said means for introducing and interpreting authority symbols reads said authority symbols in said module, and an exception is thrown if the authority symbol that is not belonging to said set is read. System or terminal or smart card according to any one of claims 7 to 10, characterized in that said virtual machine comprises a logical address read / write space having a clipboard for at least said module, said module comprising a space amount of space for a logical address. reading / writing the logical addresses needed to execute it, and said virtual machine also comprising means for allocating a size of reading / writing logical address space for storing said module in accordance with said data, wherein said allocated logical address reading / writing space is defined and protected borders. 123 The system or terminal or smart card of claim 11, further comprising means for releasing said allocated size of logical address reading / writing space upon termination of said module. 13. A system or terminal or smart card according to any one of claims 7 to 10, wherein said virtual machine comprises means for providing at least one program instruction capable of at least modifying the time execution behavior of said computer program? and wherein said deployment and interpretation means have deployed said module and while said module is in operation, said deployment and interpretation means deploy and interpret said at least one program instruction dependent on a predefined security condition; as interpreted by said virtual machine and execute said computer program with modified behavior. The system or terminal or smart card of claim 13, wherein said security condition is provided by a function. A system or terminal or smart card according to any one of claims 9 to 14, further comprising a space for reading / writing logical addresses, including at least one database. 124 comprising at least one record, said module comprising an indication of the amount of space to read / write the logical uninitialized addresses needed to execute the module; said bootloader allocating a desired amount of uninitialized logical address space in accordance with said entry; and means for accessing a record in said database, said record in said database being accessible only by said module, and said means of accessing providing a window to a common record in said database and copying said record to a portion of said space to read / write uninitialized addressable logical addresses by said application program. 16. A transaction management system, further comprising: i a first device and a second device, said devices adapted to communicate with each other, at least one of said first or second devices being an integrated circuit card; said second device comprising means for providing at least one program instruction capable of at least modifying the execution time of a computer program in said first device; said first apparatus comprising a virtual machine, a virtual machine comprising means for and interpretation of said computer deployment means, and said interpretation means further adapted to deploy said program deployment, 125 and interpreting said at least one program instruction dependent on a predefined security condition, after said means for loading and interpreting have introduced said computer program and while said computer program is operated; and executing means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction. 17th The terminal comprising: a first device for executing a transaction with the second device and at least one of said first or second devices is an integrated circuit card; said second device comprising means for providing at least one program instruction capable of at least modifying the execution time of a computer program in said first device; said terminal comprises: said first machine comprising a virtual machine, said virtual machine comprising means for loading and interpreting said computer program, said means for loading and interpreting further adapted to load and interpret said at least one program instruction depending on a predefined security condition, then said means for loading and the interpretation has been introduced by said computer program and while said computer program is 126 operated; and executing means for executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction. 18. A self-contained portable smart card comprising: a first device for executing a transaction with the second device, said second device comprising means for providing at least one program instruction capable of at least modifying the execution time of the computer program in said first device; the smart card includes: said first apparatus comprising a virtual machine, a virtual machine comprising means for and interpretation of said computer means, said deployment and interpretation means further adapted to deploy and interpret said at least one program instruction dependent on a predefined security condition, after said deployment and interpretation means introduced said a computer program and the aforesaid computer program being operated; and implementing means for executing said deployed and interpreted computer program with modified behavior in response to the deployed and interpreted program of said deployment of said program. 127 instruction. The system of claim 16 or the terminal of claim 17 or the smart card of claim 18, characterized in that the safety condition mentioned therein is provided by a function. 20. The system or terminal or smart card of claim 19, wherein said at least one program instruction is a first program instruction, and said first device comprises a second program instruction capable of at least modifying the execution time behavior of said computer program, said first program instruction. includes referring to said second program instruction; and said means for loading and interpreting responsive to said reference to the introduction of said second program instruction, said executing means executing said computer program with said modified behavior as determined by said second program instruction. 21. The system or terminal or smart card of claim 20, wherein said computer program and said first and second program instructions are written in the form of a sequence of authority symbols and corresponding input data, each authority symbol being an order byte code selected from a set of order apartment codes. 128 22. The system or terminal or smart card of claim 21, wherein the virtual machine directs said entitlement sequence and said embedded data of said first and second program instructions to said entitlement sequence of said computer program. The system or terminal or smart card of claim 21 or 22, wherein at least each sequence of authorization symbols of said computer program and at least each said second program instruction is transmitted in a module, each module comprising a respective sequence of authorization symbols together with corresponding input data required to execute said module. 24. The system or terminal or smart card of claim 23, wherein said module also includes memory information required to execute said module. 25. A system or terminal or smart card according to claim 23 or 24, wherein said computer program module also comprises an exclusive list of at least one modified socket, said socket defining a position of a sequence of authorization symbols and input data of said computer program module into said virtual machine directing said first program instruction. 26. A system or terminal or smart card according to 129 of claim 25, wherein said at least one modified socket in said computer program module comprises an embodiment vector to standard behavior. 27. The system or terminal or smart card of claim 26 wherein said executing means executes said computer program with said standard behavior if said predefined security condition does not permit the introduction of said at least one program instruction. System or terminal or smart card according to any one of claims 23 to 27, characterized in that said virtual machine comprises a logical address read / write space, said module comprising an indication of the amount of logical address read / write space required for its the embodiment and said virtual machine also comprises means for allocating a size of a logical address read / write space for storing said module in accordance with said data, said allocated logical address read / write space having defined boundaries; and means for releasing said amount of space for reading / writing logical addresses upon termination of said computer program module. 29. A system or terminal or smart card according to 130 of any one of claims 23 to 28, further comprising a logical address read / write space comprising at least one database containing a plurality of records, said module comprising an indication of the amount of logical uninitialized address read / write space required to execute the module; said deployment means allocating a desired amount of uninitialized logical address space in accordance with said data; and means for accessing the record in said database, the records in said database being accessible only through said module, and said means of access providing a window to a common record in said database and for copying said record to a portion of said space to read / write uninitialized addressable logical addresses by said application program. System or terminal or smart card according to any one of claims 16 to 27, characterized in that said security condition comprises means for verifying at least the origin and completeness of the data and program instructions in said second device. 31. A transaction system for executing transactions between a first device and a second device, further comprising: a virtual machine for interpreting the order byte order code symbol set used therein, 131, a virtual machine comprising a virtual processing unit and a logical address read / write space, at least one first application program comprising the amount of read / write logical address space required to execute it, said at least one first application program written as a sequence of authority symbols selected from said set of entitlement symbols and corresponding input data, said virtual machine also includes: a boot program for loading at least one first application program, and means for allocating a first amount of logical address read / write space specifically for said at least one first application program in accordance with said data, said allocated logical address read / write space being defined and protected borders. 32. A terminal comprising a first device for executing transactions with a second device, the first device comprising: a virtual machine for interpreting a set of order byte code authorization symbols used therein, said virtual machine comprising a virtual processing unit and a logical address read / write space, at least one first application program containing the amount of read / write logical address space needed to execute it , said at least one first 132 the application program is written as a sequence of authority symbols selected from said set of authority symbols and corresponding input data, said virtual machine also comprising: a load program for loading at least one first application program, and means for allocating a first amount of logical address read / write space specifically for said at least one first application program in accordance with said data, said allocated logical address read / write space having defined and protected borders. 33. A self-contained portable smart card, characterized in that it comprises a first device for executing transactions with a second device, said first device comprising: a virtual machine for interpreting a set of order byte code permission symbols used therein, said virtual machine comprising a virtual processing unit and a logical address read / write space, at least one first application program containing the logical address read / write space size needed to execute it , said at least one first application program is written as a sequence of authority symbols selected from said set of authority symbols and corresponding input data, said virtual machine also comprising: a loader program for loading said at least one first application program, and 133 means for allocating a first size of logical address read / write space specifically for said at least one first application program in accordance with said data, said allocated logical address read / write space having defined and protected boundaries. 34. The system of claim 31 or the terminal of claim 32 or the smartcard of claim 33, further comprising means for expressing the release of said first size of logical address read / write space upon termination of said at least one program. A system or terminal or smart card according to any one of claims 31 to 34, wherein at least one of the first or second device is an ICC. 36. A system or terminal or smart card according to any one of claims 31 to 35, wherein said first application program also includes a first exclusive list of at least one function that can be transferred to other application programs, further comprising means for causing it. that at least one feature is available to other programs. 37. The system or terminal or smart card of any one of claims 31 to 36, wherein said first application program is a first module and said other application programs are different. 134 of the modules, each module comprising at least a sequence of authority symbols selected from said set of authority symbols corresponding to the entered data, a first exclusive list of at least one function to be performed, and an indication of the amount of read / write logical address space needed to execute the module. 39th The system or terminal of claim 37, wherein said first module comprises a second exclusive list identifying at least one second module from which said bootloader is referred to, or at least the second module is a second list for loading the first module. The system or terminal or smart card of claim 38, wherein said first module is terminated therein if said at least one second receive module is not successfully loaded. at least one function of a program implementing in accordance with said System or terminal or smart card according to any one of claims 37 to 39, characterized in that said allocation means allocates said first size of space for reading / writing logical addresses to load said first module and allocates only a second or additional space of space to read / write logical addresses for said first module in a single extensible buffer starting from the first address; and releasing said second size of logical address reading / writing space by said first module, said release means releasing said second size of logical reading / writing space 135 addresses and all other allocations after the first address. 41. The system or terminal or smart card of claim 40, wherein said release means releases said second amount of logical address read / write space and for all subsequent allocations after said first address upon termination of said first module. 42. A system or terminal or smart card according to any one of claims 37 to 41, wherein said logical address reading / writing space comprises at least one database comprising at least one record, said module comprising a read / write space size indication. uninitialized logical addresses needed to execute said module, and records of said database are accessible only through said module, said bootloader allocating a desired amount of uninitialized logical address space in accordance with said data, and means for accessing a record in said database providing said access means window to a common record in said database and copy said record to a portion of a read / write space of uninitialized logical addresses addressable by said application program. 136 43. A system or terminal or smart card according to any one of claims 34 to 42, wherein said release means delete any amount of allocated logical address read / write space upon termination of said first module. 44. A transaction system for executing transactions between first and second devices, characterized in that at least one of said first or second devices is an integrated circuit card, said system comprising: a virtual machine for interpreting the order byte order code symbol set used therein; said virtual machine comprising a virtual processing unit and a logical address read / write space; at least one database comprising at least one record and at least one computer program for execution by said virtual machine, said computer program being a module written in the form of a sequence of said authorization symbols selected from said set and containing an amount of read / write space for uninitialized logical addresses needed to execute said module; a loader program for loading said module to allocate a desired amount of space for uninitialized logical addresses in accordance with said data; and means for accessing a record in said database, records in said database are only accessible 137, by means of said module and said means of access, provide a window to a common record in said database and copy said record to a portion of said space for reading / writing uninitialized logical addresses addressable by said application program. 45. A terminal comprising a first device for conducting transactions with a second device, wherein at least one of said first or second devices is an integrated circuit card, said first device comprising: a virtual machine for interpreting the order byte order code symbol set used therein; said virtual machine comprising a virtual processing unit and a logical address read / write space; at least one database comprising at least one record and at least one computer program for execution by said virtual machine, said computer program being a module written in the form of a sequence of said authorization symbols selected from said set and containing an amount of read / write space for uninitialized logical addresses needed to execute said module; a loader program for loading said module and allocating a desired amount of space for uninitialized logical addresses in accordance with said data; and means for accessing a record in said database, records in said database are only accessible 138 through said module and said access means provide a window to a common record in said database and copy said record to a portion of said space to read / write uninitialized logical addresses addressable by said application program. 46. A self-contained portable smart card comprising a first device for conducting transactions with a second device, wherein said first device comprises: a virtual machine for interpreting the order byte order code symbol set used therein; said virtual machine comprising a virtual processing unit and a logical address read / write space; at least one database comprising at least one record and at least one computer program for execution by said virtual machine, said computer program being a module written in the form of a sequence of said authorization symbols selected from said set and containing an amount of read / write space for uninitialized logical addresses needed to execute said module; a loader program for loading said module and allocating a desired amount of space for uninitialized logical addresses in accordance with said data; and means for accessing the record in said database, the records in said database are accessible only through said module and said 139, the access means providing a window to a common record in said database and copying said record to a portion of said space for reading / writing uninitialized logical addresses addressable by said application program. 47. The system of claim 44 or the terminal of claim 45 or the smart card of claim 46, wherein said database is specific upon the first loading of said module. 48. A system or terminal or smart card according to any one of the preceding claims, wherein said virtual machine is a cartridge machine. 49. The system or terminal or smart card of claim 48, wherein said virtual machine is at least two pushdown machines, wherein the first stack is a data stack and the second stack is a return stack. System or terminal or smart card according to any one of the preceding claims 1 to 49, characterized in that said virtual machine comprises a local variable frame memory, a frame pointer register for storing a frame pointer pointing at the beginning of the frame and a register of the end-of-frame pointer. pointing to the end of the frame in memory. 51. System or terminal or smart card according to 140 to claims 49 or 50 characterized in that the one mentioned storage and return are directly adresovateíné memory by said computer program, but ^one accessible via stack operations defined by tokens and interpreted by said virtual machine. 52. The system or terminal of any preceding claim, wherein said first device is a handheld device. 53. The system or terminal of claim 52, wherein said handheld device comprises an integrated circuit card (ICC). 54. The system or terminal of any one of claims 1 to 52, wherein said second device comprises an ICC. 55. The system of any preceding claim, wherein said first device is a terminal. 56. A system or terminal or smart card according to any one of claims 1 to 55, wherein both the first and second devices comprise ICCs. 57. The system or terminal or smart card of any one of claims 1 to 56, wherein the transaction comprises at least one execution of the following sequence: a. establishing a communication link between said first and second devices b. selecting an application containing said computer program and a set of appended data that define the transaction c. executing said transaction; and d. transaction completion. 58. The system or terminal or smart card of any one of claims 1 to 57, wherein the transaction is a financial transaction and said system is a financial transaction management system. An integrated circuit card comprising a program instruction capable of modifying the behavior of a program running in a system according to any one of claims 1 to 58, a terminal according to any one of claims 2 to 58, or a smart card according to any one of claims 3 to 58 . 60. A method of executing transactions between a first device and a second device, wherein at least one of said first and second devices is an integrated circuit card comprising providing at least one program instruction in said second device capable of at least modifying the execution time of the computer program in said first device. equipment; introducing and interpreting said computer program; 142 introducing and interpreting said at least one program instruction dependent on a predefined security condition while said computer program is in progress; and executing said loaded and interpreted computer program with said modified behavior in response to said loaded and interpreted program instruction. 61. A method of executing a transaction between a first device and a second device, comprising: interpreting at least one application program written as a sequence of byte code entitlement symbols selected from a set of authority symbols and corresponding embedded data; introducing said at least one application program; allocating a first size of logical address read / write space specifically for said at least one application program in accordance with the data contained within said logical address space size read / write application program necessary to execute it; and defining and protecting the boundaries of said allocated space for reading / writing logical addresses. 62. The method of claim 61, further comprising: exclusively releasing said first size of logical address read / write space upon termination of said at least one first application program. 143 63. A method of executing a transaction system between a first device and a second device, wherein at least one of said first and second devices is an integrated circuit card comprising: interpreting authority symbols in a module written in the form of a sequence of said authority symbols selected from a set of authority symbols; allocating an amount of space for the uninitialized logical addresses in accordance with the information in said module for the amount of space to read / write the uninitialized logical addresses needed to execute said module; access to a database record by providing a window to a common record in said database; records in the database can only be accessed via said module; and copying said record to a portion of said space to read / write uninitialized logical addresses addressable by said module. 64. A method of executing a transaction between a first device and a second device, wherein at least one of said first and second devices is an integrated circuit card comprising: providing a portable virtual machine comprising a virtual microprocessor and an exciter for at least one input / output device; interpreting a computer program in said first device using said portable virtual machine; and executing said program in response to said interpreted program.