WO2003044751A2

WO2003044751A2 - Control of a traffic toll terminal

Info

Publication number: WO2003044751A2
Application number: PCT/EP2002/012842
Authority: WO
Inventors: Arndt Berthold; Ludger Holtmann; Andreas Johne; Bernhard Pluhatsch; Gabriele Willer-Scheib
Original assignee: Giesecke & Devrient Gmbh
Priority date: 2001-11-19
Filing date: 2002-11-15
Publication date: 2003-05-30
Also published as: AU2002365986A8; AU2002365986A1; DE10156783A1; WO2003044751A3

Abstract

The invention relates to a method for controlling a traffic toll terminal, during which the control is effected, at least in part, according to program commands (80x), each of which having a command part and a validity condition. Only program commands (80x) are executed whose respective validity condition is fulfilled at the time of execution. In another method of this type, the program commands (80x) are interpreted at the time of execution by an interpreter of the traffic toll terminal. A data carrier that can be read by a computer and a traffic toll terminal both have corresponding features. The invention creates technical foundations for simplifying the programming of traffic toll terminals and/or their adaptation to modified conditions.

Description

Control of a payment transaction terminal

The invention relates to the technical field of control and programming of payment traffic terminals.

In the present document, a payment transaction terminal is to be understood in particular to mean any device which carries out transactions using a chip card or other electronic identification and / or storage means. Payment transaction terminals of this type are used in particular for cashless payments of all types by means of credit cards, ec cards, bank cards or cash cards. In the wording used here, ATMs and ATMs for refilling cash cards are also regarded as payment terminals, as well as devices that are only indirectly involved in payment and settlement processes (e.g. account statement printers or access control systems).

It is known to control the necessary processes (such as transactions with the chip card or with a background system, control of a display or a printer, input processes) in a payment transaction terminal of this type using a program written in assembler or in a higher programming language. If programming is carried out, for example, in the programming language C, the source program is converted by means of a compiler into an object code that can be executed directly by the processor of the payment transaction terminal.

However, such control programs written in a general programming language are complex and confusing. They are susceptible to programming errors and can only be maintained with great effort. Adaptation to customer requirements, changed specifications and change requests from network operators is complex and time-consuming. An in Assembler-written programs must be newly developed for each hardware platform. Even with programs in a higher programming language (eg the C language), considerable adjustment work is required for each new hardware.

The object of the invention is to avoid all or part of the problems mentioned. In particular, the technical fundamentals are to be created by the invention in order to facilitate the programming of payment terminals and / or the adaptation to changed circumstances. Furthermore, the most extensive possible

Hardware independence of the control program can be achieved.

According to the invention, this object is achieved by methods having the features of claims 1 and 6, and by a computer-readable data carrier according to claim 8 and a payment transaction terminal according to claim 9. The dependent claims relate to preferred embodiments of the invention.

The invention is based on the basic idea of not using a program written in a general-purpose programming language for controlling a payment traffic terminal, but rather a control program which is specifically tailored to the requirements and circumstances of payment transaction terminals.

According to a first aspect of the invention, it is provided that the payment terminal is controlled in part or in full in accordance with program instructions, each of which has an instruction part and a validity condition, with each program command being executed only when the validity condition is fulfilled at runtime. This measure represents a Moving away from the technology common in conventional general-purpose programming languages is to use different constructs for conditions and instructions.

The technique according to the invention is particularly advantageous in particular because it enables the payment terminal to be programmed in a manner similar to the representation in typical specifications for transaction processes. The control program can be developed relatively easily on the basis of such a specification, which represents a sequence of input and output actions under predetermined conditions. The time and effort required is reduced and mistakes are avoided. Adaptation to changed specifications or customer requests is also particularly easy and quick.

According to the invention, the payment terminal is controlled at least in part in accordance with program instructions which have a specific structure. This wording is also intended to include the case that the program instructions only have the structure mentioned during the development of the program and no longer during the runtime of the control program. For example, in some embodiments, the control program can be translated by a compiler into machine-language program structures that are optimized with regard to the execution speed and / or the memory space and therefore have no relation to the structure required according to the invention. In preferred embodiments, however, this structure of the program instructions (instruction part and validity condition) is still present at runtime of the control program, because coding steps are carried out that allow efficient storage and / or interpretation of the program instructions, but without changing their basic structure , According to a second aspect of the invention, an interpreter is provided which interprets non-machine-language program commands during the program runtime. The use of an interpreter in this way considerably reduces the hardware dependency of the control program, because the interpreter can be viewed as an abstract machine that is uniform for several hardware environments. One and the same control program can therefore be used for payment terminals of various designs. As a result, the total development costs incurred are significantly reduced. In addition, this aspect of the invention provides the technical foundations for being able to offer a program instruction set which contains particularly powerful and / or program instructions which are close to the specification. This measure also results in a significant increase in productivity and quality in the creation of control programs for payment terminals.

In preferred embodiments, the two previously described aspects of the invention are combined with one another in order to achieve a combination of the advantages mentioned.

The validity condition is preferably composed of several different condition types. In particular, one or more run-over conditions and / or one or more simple execution conditions and / or one or more combined execution conditions can be provided. In preferred embodiments, the command part is divided into a functional section and a parameter section, the functional section in turn being able to specify a command group and a command type at least for some program commands. A particularly memory-saving coding of the program commands takes advantage of the fact that in control programs that occur in practice, many program commands have identical or at least partially identical validity conditions. If the program instructions are stored partly in an instruction memory area and partly in a condition memory area, then identical validity conditions or parts thereof need only be contained once in the condition memory area. Several program instructions can then refer to one and the same data in the condition memory area.

A representation of the control program that is particularly advantageous for program development has a main table and, if appropriate, one or more secondary tables. Aids are preferably provided in order to process a control program shown in table form and to convert it into a code that can be processed by the interpreter.

The computer-readable data carrier provided according to the invention can be an electronic or magnetic or optical storage medium, e.g. be a floppy disk or hard drive or CD-ROM, but is not limited to physical media. Also electrical or optical signals, e.g. Voltage level of a communication link should be interpreted as computer-readable data carriers in the sense used here.

In preferred configurations, the computer-readable data carrier and / or the payment transaction terminal are further developed with features which correspond to the features described above and / or to the features mentioned in the method claims. Further features, advantages and objects of the invention will become apparent from the following detailed description of several exemplary embodiments and alternative embodiments of the invention. Reference is made to the schematic drawings, in which:

1 is a representation of hardware and software levels in a payment terminal according to an embodiment of the invention,

FIG. 2 shows an exemplary representation of a main table in the exemplary embodiment from FIG. 1, FIG.

3 shows an exemplary specification of a data record format,

4 shows an exemplary specification of a transaction flow,

5A and 5B show an exemplary representation of a main table for the specification according to FIG. 4,

6 shows a flow chart of the program loop executed by an interpreter,

FIG. 7 shows an exemplary representation of a coding of the main table from FIG. 2 during the runtime of the control program, and

8 shows a flow chart of a conversion process for generating a loadable control program.

1 shows a payment transaction terminal in its functional layers that build on one another. A hardware Layer 10 has the hardware elements of the payment transaction terminal. With regard to its hardware structure, the payment transaction terminal is known as such. It has a processor 12 which accesses a working memory 14, for example RAM and EEPROM, and a program memory 16, for example ROM and EEPROM. The software to be described for the payment transaction terminal is contained in the program memory 16.

The processor 12 is also via a bus 18 with a chip card interface 20, a message interface 22, a crypto processor 24, a printer interface 26, a keyboard interface 28, a display interface 30 and a timer 32 connected. A chip card 34 can be connected to the chip card interface 20. The chip card 34 is not part of the payment transaction terminal and is therefore shown in broken lines in FIG. 1.

The message interface 22 can be configured, for example, as a modem for wired or wireless communication. The payment transaction terminal can communicate via the message interface 22 and a corresponding communication medium, e.g. a telephone line or the GSM network or the Internet, with a background system, e.g. the computer system of a bank or a billing center.

The crypto processor 24 is a module which is specially protected against attacks and which provides cryptographic functions, for example for encrypting personal identification numbers. In alternative embodiments, the crypto processor 24 is not implemented as a hardware module, but rather as a software module executed by the processor 12. The printer interface 26, the keyboard interface 28 and the display interface 30 serve in a manner known per se to control a printer 36, a keyboard 38 and a display 40. The timer 32 provides functions for the program-controlled generation of timeout signals which are required in the communication with the chip card 34 and the background system.

A hardware-related software layer 42 with drivers for the hardware elements 20 to 40 just mentioned is placed directly on the hardware layer 10. In the exemplary embodiment shown in FIG. 1, software modules for a chip card driver 44, a message driver 46, a crypto driver 48, a printer driver 50, a keyboard driver 52, a display driver 54 and a timer driver 56 are provided here.

An interpreter layer 58 builds on the hardware-related software layer 42 as a further abstraction level. The interpreter layer 58 contains, as an essential component, an interpreter 60 for the program instructions used to control the payment transaction terminal.

The program instructions and further information required for the control form a control program 62, which conceptually represents a control program layer 64 arranged above the interpreter layer 58. The control program 62 has a main table 66 in which each line contains a program instruction.

In the exemplary embodiment described here, a plurality of secondary tables 68, 70, 72, 74 are also provided, in which information that logically belongs together is collected. For example, the secondary table contains 68 entries that describe the structure of the individual chip card commands. The secondary table 70 contains information about the structure of the individual messages to the background system, the secondary table 72 contains information about the structure of the responses expected by the background system and the secondary table 74 contains as text table entries with the character strings to be displayed or printed.

In the control commands of the main table 66, a corresponding entry in one of the secondary tables 68 to 74 is referred to, if necessary. By outsourcing all information about certain functional units, e.g. The clarity of the control program 62 is considerably increased via the format of chip card commands in the secondary tables 68 to 74. In addition, the structure of the control program 62 is brought into line with the structure of the relevant specifications and standards.

1, for the sake of clarity, the elements of the control program 62 are shown in a tabular form, as is used during the program development. In different exemplary embodiments, this table form is more or less blurred in the final coding of the control program 62, as it is located in the program memory 16, or in extreme cases is no longer recognizable.

2 shows an example of the structure of the main table 66. The table form used for the program development is also shown here; an exemplary runtime coding will be described later with reference to FIG. 7. As already mentioned, the main table 66 has a large number of lines, each of which contains a program instruction 80 A, 80B, 80C, ... (the program instructions 80 A, 80B, 80C, ... are also summarized below in the following 80x). The main table 66 and thus each program instruction 80x is divided into four main sections, namely a function section 82, a parameter section 84, a condition section 86 and a comment section 88. The function section 82 and the parameter section 84 of each program instruction 80x together form the instruction part of this program instruction 80x.

The function section 82 of each program instruction 80x defines the function carried out by the program instruction 80x and thus corresponds, for example, to the operation code (OP code) in assembler programming. In the exemplary embodiment described here, the functional section 82 is divided into a first subsection 90 for the command group and a second subsection 92 for the command type within each command group. This measure further subdivides the commands available in order to achieve a particularly high level of clarity in the programming and maintenance of the control program 62.

The parameter section 84 of each program instruction 80x contains the parameters required for this program instruction. A maximum of three parameters are drawn in the main table 66 according to FIG. 2; however, instruction sets that have a higher or lower maximum number of parameters can also be used in alternative embodiments. In further alternative embodiments, the command type is not contained in the second subsection 92 of the function section 82, but as a first parameter in the parameter section 84.

In the present exemplary embodiment, program commands 80x are provided for the control program 62, which are those which occur at payment terminals Correspond to basic tasks. The instruction set includes the following program instructions 80x:

a) Command group: reset

Command type: ID of the processor to be reset. Parameter: none

b) Command group: display

Command type: Output device (printer 36 or display 40) 1. Parameter: Reference to text to be output in the secondary table 74

c) Command group: keyboard query

Command type: no different command types provided 1. Parameter: value range of the expected input

d) Command group: Send to chip card

Command type: no different command types provided 1. Parameter: chip card command

e) Command group: Receive chip card

Command type: no different command types are provided

1. Parameter: chip card command

2. Parameter: maximum waiting time until a time error is generated

f) Command group: Send a message to the background system

Command type: no different command types are provided

1. Parameter: settlement indicator

2. Parameter: Reference to message in secondary table 70

g) Command group: Receiving a message from the background system Command type: No different command types provided

1. Parameter: settlement indicator

2. Parameter: Reference to response condition in secondary table 72

3. Parameter: Reference to confirmation message in secondary table 70

h) Command group: Encrypt

Command type: Encryption method to be used 1. Parameter: Reference to data to be encrypted 2. Parameter: Reference to memory area for decrypted data

i) Command group: Decrypt

Command type: Decryption method to be used 1. Parameter: Reference to data to be decrypted

2. Parameter: Reference to memory area for decrypted data

j) Command group: Check

Command type: test criterion, e.g. "Date>" = current date earlier than the date in the one specified by the parameters

storage area

1. Parameter: Reference to the beginning of the memory area to be checked

2. Parameter: Reference to the end of the memory area to be checked

The breakdown of the components of a program instruction 80x into instruction group, instruction type and parameter serves, as already mentioned, primarily for better clarity. Other structures are therefore possible in alternative versions. For example, in the case of the above-mentioned command b), the output device can be specified in the command group instead of, as above, in the command type. With regard to commands d) and f), on the other hand, it is provided in other embodiment variants not to specify the receiver as part of the command group, but as a command type or even as a parameter. It is also noted that commands with different numbers of parameters up to the maximum number of parameters provided are contained in the command set.

The individual program instructions 80x of the main table 66 are processed in sequence by the interpreter 60 (FIG. 1), as will be described in detail later. Special commands for program flow control are not provided or only to a very limited extent. Rather, the main mechanism for controlling program flow is that each program instruction 80x in condition section 86 has a valid condition. During the In the program sequence, only those program instructions 80x are executed whose respective validity conditions are fulfilled at runtime. Other program instructions 80x are skipped. With this procedure when processing the program instructions 80x, the program flow is adapted to runtime criteria or inputs or external or internal events, whereby constructs such as conditional jumps can be avoided. For example, this mechanism can be used to send a first message to the background system on successful reading from the chip card, but in the case of a timeout, a second message.

2 shows exemplary validity conditions, which are composed of up to six predetermined criteria. Typical examples of such criteria are the set payment method, the device variant, an optional functionality, an external event, an internal status of the payment processor or the usage control of the memory or other actuators. The effect of a fulfilled criterion is indicated in the table representation of FIG. 2 by the characters "+", "&" and "\" in the corresponding column of the condition section 86. If there is no character for a program command 80x in a criteria column, this criterion does not affect the execution of this program command 80x.

In the case of the program instruction 80A, the validity condition contained in the condition section 86 takes the form of a simple execution condition. This is indicated by the fact that a single criterion in the condition section 86 is marked with the sign "+". The program instruction 80A is executed precisely when the marked criterion, here criterion 2), is fulfilled at runtime. In program instruction 80B, several simple execution conditions are provided by marking several criteria with the "+" sign. Here the validity condition corresponds to the OR operation of the individual execution conditions. The program instruction 80B is therefore executed exactly when at least one of the criteria 1, 2 or 3 is fulfilled at runtime.

A validity condition called a "combined execution condition" is shown in program instruction 80C. This validity condition is fulfilled if all criteria marked with the character "&" in condition section 86 are met at runtime.

All validity conditions mentioned so far can be restricted by a crossing condition. Such a crossing condition is indicated by the character "\" for one or more criteria of condition section 86. If a run-over condition is met when a program command 80x is executed, this program command 80x is skipped without the other criteria in condition section 86 playing a role. For example, program instruction 80D is never executed if criterion 4 is fulfilled at runtime. As a further example, the program instruction 80E is executed exactly when either criterion 1 is met and criterion 4 is not met, or when criteria 2, 3 and 5 are all met and criterion 4 is not met.

3 shows an exemplary specification of a response data record of the chip card 34 in tabular form. Corresponding data can be entered in a secondary table on the basis of which the validity of a chip card card response is checked. The secondary table 72 for checking responses of the background system can also have a similar structure. This corresponds to the principles generally used in the present exemplary embodiment, to outsource complex structures and mechanisms in secondary tables and to approximate the representation of the control program 62 as closely as possible to the underlying specifications, at least during the program development.

FIG. 4 shows an exemplary and simplified section of the "Prepare loading" sequence for a chip card 34 configured as a cash card in accordance with Chapter 4.12 of the document "Interface specification for the ec card with chip 3.0, cash card loading terminal". In general, such specifications describe processes in a payment transaction terminal as a sequence of successive, that is to say sequential, output actions (sending) and input actions (receiving). The specification is largely hardware-independent.

The main table 66 of a control program 62 corresponding to the specification of FIG. 4 is shown in FIGS. 5A and 5B, FIG. 5A showing the left half of the main table 66 and FIG. 5B the right, immediately following half. In this more detailed example, the condition section 86 of each program instruction 80x has a variety of possible validity criteria, which are divided into the categories "device functions", "status", "errors" and "card type".

Criteria of the "device functions" category relate to external conditions which are selected via the keyboard 38 or a cash register or which result from the type of card used or the current operating mode. Examples of such criteria are payment by ec card in an online mode, ie if there is communication with the background system, payment by ec card in an offline mode, ie without access to the background system, payment with a cash card, reloading the cash card from a bank account or payment by Credit card or fleet card.

Status and error criteria are usually those that relate to internal device processes and that only occur during the program runtime or change during the program runtime. Examples of such criteria are time errors, interrupts, negative feedback from the background system or the chip card, and auto cancellation conditions.

The "Memory" column shown in FIG. 5B serves to specify selectable memory locations for results or input values of individual program instructions. The information shown there is therefore to be understood conceptually as a command parameter, even if it is optically arranged in the condition section 86 and is stored internally in some embodiments of the system according to the invention like criteria of validity conditions.

During the operation of the payment transaction terminal shown in FIG. 1, the interpreter 60 executes a program loop, as is shown by way of example in FIG. 6. In a first step 100, a command counter of the interpreter 60 is set to the first program command 80A in the main table 66 of the control program 62. In a next step 102, a device status is formed which contains the current status of the individual criteria possible for the validity conditions. The interpreter 60 now accesses the current program instruction 80x and loads its validity condition contained in the condition section 86 (step 104).

In query 106 it is checked whether at least one crossing criterion specified in the validity condition of the current program command

(Character "\" in Fig. 2) is satisfied. If this is the case ("yes" branch in query 106), the current program command is skipped. If no run-over condition is met ("No" branch in query 106), it is checked in query 108 whether there is currently at least one criterion marked as a simple execution condition (character "+" in FIG. 2). If this is the case ("yes" branch in query 108), the current program instruction 80x is executed in steps 110 and 112.

To execute the program instruction 80x, its function section 82 is first decoded (step 110). In step 112, the interpreter 60 calls the corresponding driver (reference numerals 44 to 56 in FIG. 1) and transfers the data to the driver module 44 to 56 in accordance with the parameter section 84 of the program instruction 80x. After the command execution by the driver module 44 to 56, possibly returned data values are stored in accordance with the information in parameter section 84.

If none of the simple execution conditions was met ("No" branch in query 108), the presence of a combined execution condition ("&" sign in FIG. 2) is still checked in query 114. If all of the criteria specified in such a combined execution condition are met (“yes” branch in query 114), the instructions are also executed in steps 110 and 112. After the end of the command execution or if a program command 80x has been skipped, the command counter is increased in step 116. If the end of the table has not yet been reached ("No" branch in query 118), the program execution is continued with the next program command 80x. Otherwise, the processing of the main table 66 starts again with the first program instruction 80A.

In the exemplary embodiment described here, the entire main table 66 is thus cycled through in an endless loop. In contrast, in alternative embodiments, means are provided for structuring the control program 62 or for controlling the program flow. For example, program parts can be exported to other tables and how subroutines can be called. The instruction set can also contain jump instructions to predetermined destinations within the main table 66 or to the sub-tables just mentioned; such jumps are carried out when their respective validity condition is fulfilled.

As already mentioned above, the control program 62 can be present in different codings. A particularly simple coding of the tables shown in the previous figures would be, for example, the representation as ASCII text or in a page description language, for example HTML or XML or in a common file format, for example as in the programs Microsoft® Word or Microsoft® Excel®. In some embodiments of the invention it can be provided that the interpreter 60 reads in and executes control programs 62 in such a coding directly. Because of the associated high storage space and computational effort, however, exemplary embodiments are preferred in which the control program 62 is in an efficiently coded form. An example of such a coding of the main table 66 of FIG. 2 is shown in FIG. 7. In the exemplary coding of FIG. 7, the main table 66 is stored partly in an instruction memory area 120 and partly in a condition memory area 122. For each program instruction 80x, the instruction memory area 120 has two, three or four bytes, namely a first byte for coding the function (instruction group and possibly instruction type), a second byte which contains a reference to a validity condition entered in the condition memory area 122, and zero , one or two further bytes for the corresponding number of parameters of the program instruction 80x. For commands with three parameters, the first parameter is to be coded in the first byte like a command type. The values shown in FIG. 7 are exemplary encodings for the program instructions 80x shown in plain text in FIG. 2.

The condition storage area 122 contains an entry for each valid condition occurring in the main table 66. As can be seen from FIGS. 5A and 5B, in practice several program instructions 80x of the main table 66 often have the same validity condition. This validity condition is only present once in the condition storage area 122, thereby avoiding unnecessary duplication of identical validity conditions.

In the present exemplary embodiment, each entry in the condition storage area 122 has two bit fields 124, 126 which each contain one bit for each possible validity criterion. The assignment of these bits to the validity criteria is identical in both bit fields 124, 126. In the example described here, only six validity criteria are provided, so that each of the bit fields 124, 126 uses only six bits of one byte each. In a typical embodiment of the invention, in which the main 5A and 5B, for example, 32 validity criteria and accordingly 32 bits (= four bytes) are provided for each of the two bit fields 124, 126.

The validity conditions already described are encoded in the corresponding bits of the two bit fields 124, 126 according to the following table:

7, the queries 106, 108 and 114 of FIG. 6 can be carried out in a particularly simple manner. For this purpose, the device status is also represented in step 102 in the form of a bit field which corresponds to the format of the bit fields 124, 126 with regard to the arrangement of the validity criteria. A runover condition is fulfilled if the AND link between the device status and the second bit field 126 and the negation of the first bit field 124 is not equal to zero. Similarly, in step 108, the existence of a simple execution condition can be checked by an AND operation between the device status and the first bit field 124 and the negation of the second bit field 126. To check the combined execution condition in query 114, an AND operation of the two bit f eider 124, 126 and then an exclusive OR link of the result with the device status and a zero comparison required.

While in the present exemplary embodiment the run-over information is contained in the condition storage area 122, in alternative embodiments it can be provided that only condition conditions are recorded in the condition storage area 122 and any existing run-over conditions are managed separately. In general, provision can also be made to use the procedure proposed here for the common storage of identical validity conditions only for some of the available validity criteria.

FIG. 8 shows a method which is used in the exemplary embodiment described here for coding the various tables of the control program 62 (FIG. 1) and for generating a program which can be loaded into the program memory 16 (file "zvt.hex" in the hex code).

The method according to FIG. 8 is based on a main table 66, which is in a coding that is easy to edit for the programmer (here as file "zvt_tab.xls" in the format of the spreadsheet program Microsoft® Excel®). This file is analyzed in step 130 and converted into a coding which corresponds to a source text segment of the programming language C (file "zvt_tab.c"). Common tools such as e.g. the Lex and Yacc programs are used. For example, a code segment can be created in the following structure:

const uchar ztab [] = {OxCO, 0x01, / * 1-byte command * /

0x10, 0x04, 0x65, / * 2-byte command * / OxEl, 0x05, OxEO, OxFO, / * 3-By te command * /

In a next step 132, the main table 66 coded as a program section is converted into an object file by a conventional compiler, which is tailored to the hardware of the payment transaction terminal (file "zvt_tab.obj"). Together with other object files, which contain secondary tables of the control program 62 as well as the interpreter 60 and the driver modules 44 to 56 (FIG. 1), a binding program generates a loadable program therefrom in step 134 (file "zvt.hex"). Both the object file "zvt_tab.obj" and the loadable program "zvt.hex" contain binary data which correspond to the coding shown by way of example in FIG. 7.

The loadable program (file "zvt.hex") implements the software layers 42, 58 and 64 (FIG. 1) of the payment transaction terminal according to the exemplary embodiment of the invention described here. The program is loaded into the hardware of the payment terminal via a suitable interface in order to obtain a workable system.

Claims

claims

1. A method for controlling a payment transaction terminal, characterized in that the control takes place at least in part in accordance with program instructions (80x), each of which has an instruction part and a validity condition, wherein only those program commands (80x) are executed whose respective validity condition is fulfilled at runtime ,

2. The method according to claim 1, characterized in that the validity condition comprises at least one of the following elements: at least one runover condition, which, if it is fulfilled at runtime, prevents the execution of the command, at least one simple execution condition, which, if it is fulfilled at runtime , which releases instruction execution, and a combined execution condition which has multiple execution conditions and which, when all of these execution conditions are met, releases instruction execution.

3. The method according to claim 1 or claim 2, characterized in that the command part comprises at least one of the following elements: - a functional section (82) which by the program command

(80x) specifies the function to be executed, and a parameter section (84) which specifies at least one parameter relevant to the execution of the program command (80x).

4. The method according to any one of claims 1 to 3, characterized in that the program instructions (80x) are present at runtime in a coding which has at least one instruction memory area (120) and at least one condition memory area (122), wherein: in the instruction memory area (120) functions and / or parameters of program instructions (80x) as well as references to data in the condition memory area (122) are contained, in the condition memory area (122) at least parts of validity conditions for the execution of program instructions (80x) are contained, and

Entries in the command memory area (120), which are assigned to program commands (80x) with at least partially identical validity conditions, refer to common data in the condition memory area (122).

5. The method according to any one of claims 1 to 4, characterized in that a control program (62) with a plurality of program instructions (80x) at least for the purpose of program development in the form of one or more tables

(66, 68, 70, 72, 74) can be displayed.

6. A method for controlling a payment transaction terminal, characterized in that the control takes place according to programming instructions (80x), which are interpreted by means of an interpreter (60) of the payment transaction terminal at runtime.

7. A method for controlling a payment terminal according to claim 6 and one of claims 1 to 5.

8. Computer-readable data carrier with a control program (62), which is set up to be executed by at least one processor (12) of a payment transaction terminal in order to control the payment transaction terminal by a method according to one of claims 1 to 7.

9. Payment traffic terminal which is set up to be controlled by a method according to one of claims 1 to 7.