WO1997050063A2 - Systeme portable sûr de gestion transactionnelle destine a des unites programmables intelligentes - Google Patents

Systeme portable sûr de gestion transactionnelle destine a des unites programmables intelligentes Download PDF

Info

Publication number
WO1997050063A2
WO1997050063A2 PCT/EP1997/003355 EP9703355W WO9750063A2 WO 1997050063 A2 WO1997050063 A2 WO 1997050063A2 EP 9703355 W EP9703355 W EP 9703355W WO 9750063 A2 WO9750063 A2 WO 9750063A2
Authority
WO
WIPO (PCT)
Prior art keywords
module
terminal
logical address
read
program
Prior art date
Application number
PCT/EP1997/003355
Other languages
English (en)
Other versions
WO1997050063A3 (fr
Inventor
Guido Heyns
Peter Johannes
Original Assignee
Europay International N.V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to JP10502361A priority Critical patent/JP2000514215A/ja
Priority to BR9710009-9A priority patent/BR9710009A/pt
Priority to SK1766-98A priority patent/SK176698A3/sk
Priority to TW086109069A priority patent/TW355776B/zh
Priority to AU32630/97A priority patent/AU716558B2/en
Priority to EP97928273A priority patent/EP0907936A2/fr
Priority to CA002257641A priority patent/CA2257641A1/fr
Priority to SI9720049A priority patent/SI9720049A/sl
Application filed by Europay International N.V. filed Critical Europay International N.V.
Priority to HU0001822A priority patent/HUP0001822A3/hu
Priority to EA199900060A priority patent/EA001598B1/ru
Priority to IL12753397A priority patent/IL127533A0/xx
Priority to PL97330930A priority patent/PL330930A1/xx
Priority to NZ333384A priority patent/NZ333384A/xx
Publication of WO1997050063A2 publication Critical patent/WO1997050063A2/fr
Publication of WO1997050063A3 publication Critical patent/WO1997050063A3/fr
Priority to NO985803A priority patent/NO985803L/no
Priority to IS4925A priority patent/IS4925A/is

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/067—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components
    • G06K19/07—Record carriers with conductive marks, printed circuits or semiconductor circuit elements, e.g. credit or identity cards also with resonating or responding marks without active components with integrated circuit chips
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data

Definitions

  • the present invention relates to a system including programmable, intelligent devices such as terminals and integrated circuit cards as well as a method of operation of such cards and terminals including automatic teller machines, personal computers, pay-television units, point of sale terminals, health cards or similar. It is particularly suitable for use in performing financial transactions.
  • terminals for the performance of transactions, e.g. financial transactions which involve transfer or exchange of value or transactions which are of a commercial nature such as transactions with health care cards or for accessing data in general, e.g. the SIM card of a GSM mobile telephone.
  • Terminals such as point of sale (POS) devices, automatic teller machines (ATM) or GSM mobile telephones are known
  • POS point of sale
  • ATM automatic teller machines
  • GSM mobile telephones are known
  • Actual products range from small, hand-held devices with simple 8-Bit microprocessors such as the Intel 8031/8051 series supplied by Intel Corp., USA or Integrated Circuit Cards (ICC) to 32-bit computers running operating systems such as UNIXTM, or Windows NT supplied by Microsoft Corp., USA.
  • a personal user card which may be a magnetic stripe card, smartcard or ICC which stores specific user identification and validation information necessary before communication can be initiated between the user and the terminal.
  • the user places the card in a card reader associated with the terminal, a terminal resident program in the terminal is executed and examines the card, checking the user information for its validity and if necessary prompting for a password or private number such as a PIN (personal identification number).
  • the program normally allows the user to select the desired services to be performed, e.g. withdrawal of cash, examination of current balance.
  • the terminal may be 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 run with the minimum of maintenance and with a high level of security. Such terminals represent a significant investment in hardware and are not normally replaced at frequent intervals. Updating of the software and programs running on such terminals becomes necessary as new services are offered and must be carried out securely. Generally, the terminal operating organizations such as banks require each update to be certified. Such updating may be by hand or remotely via a private or public communications network as is known from US Patent No. 5,434,999 Such known schemes require the type and model of the terminal to be known for new developments as the software for each terminal must be created specifically for that type of terminal and are therefore cost intensive. Further, to be able to offer services from all possible organizations offering similar services, e.g.
  • the terminal must be able to process all the programs of all the organizations. Due to the high mobility of both private and business people, it is advantageous that all services which are offered in one country should be available on each terminal. This would result in unnecessarily large processing capacity and memory size for each terminal. Further, each of these programs must be updated as required.
  • One solution could be using a small workstation for each terminal possibly connected to a telecommunications system. Such a system would be capable of off-line processing and could switch to on-line processing of unusual transactions or for automatic updating of resident programs. Workstations would be required, for instance, to carry out the complex validation and encryption schemes necessary to maintain security on a system open to attack via public telephone networks. With increasing size and complexity, the problem of maintaining security would also increase.
  • Terminals of the type described above also have a processor including some form of memory, usually some random access memory (RAM) for running programs, some read only memory (ROM) for storing data which only has to be read which can include the program for the operating system of the terminal and non- volatile read/write memory for the storing of general data which may change.
  • RAM random access memory
  • ROM read only memory
  • the user personal data should be kept private and therefore there should be no possibility of access by one user to the data of others, either accidentally or intentionally by a malicious person.
  • the various writable memories of the terminal should not become defragmented with time. Defragmentation of memory can result in blocks of contiguous memory being reduced in size so that certain programs cannot run. To avoid this problem some programming languages such as JavaTM make use of garbage collection.
  • Garbage collection is a routine which attempts to identify data in memory which is no longer required and deallocates it. It is current informed opinion that garbage collection is a more reliable way of managing memory than having a program explicitly deallocate its own stored data. Explicit memory allocation and deallocation is held by some to be the largest single source of programming errors in common high level programming languages such as C or C++.
  • Garbage collection has several disadvantages. Firstly, garbage collection is an operating system function rather than an application specific one. Therefore, garbage collection does not guarantee that the data of each application is deallocated at the end of the application, but rather such data may be present for some time until the lack of access triggers the garbage collection. A more secure method of elimination of the possibility of addressing private user data is required in financial transactions. Secondly, it increases the size of memory space required for the operating system. On ICC's and some terminals memory can be limited and use of garbage collection can be a serious disadvantage. As explained above, terminals are replaced very infrequently so that a wide variety of terminals including different processor capabilities and memory sizes are normally operated in the system concurrently. Older terminals are often severely limited in their capabilities.
  • garbage collection does not free memory as soon as it would be freed using explicit deallocation. This can also increase the amount of memory required as memory is tied up when it could be released..
  • An object of the present invention is to provide a secure transaction management system for transactions and a method of operating such a system.
  • It a further object of the present invention to provide secure terminals and ICC's for transactions and methods of operating such devices.
  • 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 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; a portable virtual machine for inte ⁇ reting a computer program on said first device, said virtual machine comprising a virtual microprocessor and a driver for said at least one input/output device; and execution means responsive to said interpreted program for executing said program. It is preferred if the portable virtual machine is a stack machine as this brings operating speed and compactness.
  • the present invention also provides a terminal comprising a first device for carrying out a transaction with a second device, at least one of said first and second devices being an integrated circuit card, comprising: a portable virtual machine inte ⁇ reting a computer program on said first device, said portable virtual machine comprising a virtual microprocessor and a driver for at least one input/output device, and execution means responsive to said inte ⁇ reted program for executing said program.
  • the present invention also provides a self-contained portable intelligent card including a first device for carrying out a transaction with a second device, said intelligent card comprising: a portable virtual machine comprising a virtual microprocessor and a driver for at least one input/output device.
  • the present invention also provides a transaction management system comprising: a first device and a second device, said first and second devices being adapted for communication with each other, at least one of said first and second devices being an integrated circuit card; said second device including means for providing at least one program instruction capable of at least modifying the execution time behavior of a computer program on said first device; said first device including a virtual machine, said virtual machine comprising means for loading and inte ⁇ reting said computer program, said means for loading and inte ⁇ reting being further adapted to load and inte ⁇ ret said at least one program instruction dependent upon a pre-defined security condition after said means for loading and inte ⁇ reting has loaded said computer program and while said computer program is running; and execution means for executing said loaded and inte ⁇ reted computer program with said modified behavior in response to said loaded and inte ⁇ reted program instruction.
  • the present invention provides a. terminal comprising a first device for carrying out a transaction with a second device and at least one of said first and second devices being an integrated circuit card, said second device including means for providing at least one program instruction capable of at least modifying the execution time behavior of a computer program on said first device; said terminal comprising: said first device including a virtual machine, said virtual machine comprising means for loading and inte ⁇ reting said computer program, said means for loading and inte ⁇ reting being further adapted to load and inte ⁇ ret said at least one program instruction dependent upon a pre ⁇ defined security condition after said means for loading and inte ⁇ reting has loaded said computer program and while said computer program is running; and execution means for executing said loaded and inte ⁇ reted computer program with said modified behavior in response to said loaded and inte ⁇ reted program instruction.
  • the present invention provides a self-contained portable intelligent card including a first device for carrying out a transaction with a second device, said second device including means for providing at least one program instruction capable of at least modifying the execution time behavior of a computer program on said first device, said intelligent card comprising: said first device including a virtual machine, said virtual machine comprising means for loading and inte ⁇ reting said computer program, said means for loading and inte ⁇ reting being further adapted to load and inte ⁇ ret said at least one program instruction dependent upon a pre-defined security condition after said means for loading and inte ⁇ reting has loaded said computer program and while said computer program is running; and execution means for executing said loaded and inte ⁇ reted computer program with said modified behavior in response to said loaded and inte ⁇ reted program instruction.
  • the present invention also provides a transaction system for executing transactions between a first device and a second device, said system comprising: a virtual machine for inte ⁇ reting a set of customized byte code tokens applied thereto; said virtual machine including a virtual processing unit and read/writable logical address space; at least one first application program including an indication of the amount of read/writable logical address space needed for its execution, said at least one first application program being written as a stream of tokens selected from said set of tokens and corresponding in-line data; said virtual machine also including: a loader for loading said at least one first application program; and means for allocating a first amount of read/writable logical address space specifically for said at least one first application program in accordance with said indication, said allocated read/writable logical address space having defined and protected boundaries.
  • the first device in accordance with the present invention may be a personal computer connected to the Internet and running a browser, the requirement that each module received by the browser, must contain an indication of its memory requirements, improves the security of the browser and limits the damage that could be done by any virus contained in the imported module
  • the present invention provides a terminal comprising a first device for executing transactions with a second device, said first device comprising: a virtual machine for inte ⁇ reting a set of customized byte code tokens applied thereto; said virtual machine including a virtual processing unit and read/writable logical address space; at least one first application program including an indication of the amount of read/writable logical address space needed for its execution and a first exclusive list of at least one function which can be exported to other application programs, said at least one first application program being written as a stream of tokens selected from said set of tokens and corresponding in-line data; said virtual machine also including: a loader for loading said at least one first application program; and means for allocating a first amount of read/writable logical address space specifically for said at least one first application program in accordance with said indication, said allocated read/writable logical address space having defined and protected boundaries.
  • the present invention may also provide a self-contained portable intelligent card including a first device for carrying out a transaction with a second device, said first device comprising: a virtual machine for inte ⁇ reting a set of customized byte code tokens applied thereto; said virtual machine including a virtual processing unit and read/writable logical address space; at least one first application program including an indication of the amount of read/writable logical address space needed for its execution, said at least one first application program being written as a stream of tokens selected from said set of tokens and corresponding in-line data; said virtual machine also including: a loader for loading said at least one first application program; and means for allocating a first amount of read/writable logical address space specifically for said at least one first application program in accordance with said indication, said allocated read/writable logical address space having defined and protected boundaries.
  • the present invention may also provide a transaction system for executing transactions between a first device and a second device, at least one of said first and second devices being an integrated circuit card, said system comprising: a virtual machine for inte ⁇ reting a set of customized byte code tokens applied thereto; said virtual machine including a virtual processing unit and read/writable logical address space; at least one database including at least one record and at least one computer program for execution by said virtual machine, said computer program being a module written in terms of a stream of said tokens selected from said set and including an indication of the amount of uninitialised read/writable logical address space necessary for execution of said module; a loader for loading said module and for allocating the required amount of uninitialised logical address/space in accordance with said indication; and means for accessing a record in said database, records in said database only being accessible through said module, and said accessing means providing a window onto a current record of said database and copying said record into a portion of said uninitialised read
  • the present invention may also provide a terminal comprising a first device for executing transactions with a second device, at least one of said first and second devices being an integrated circuit card, said first device comprising: a virtual machine for inte ⁇ reting a set of customized byte code tokens applied thereto; said virtual machine including a virtual processing unit and read/writable logical address space; at least one database including at least one record and at least one computer program for execution by said virtual machine, said computer program being a module written in terms of a stream of tokens selected form said set and including an indication of the amount of uninitialised read/writable logical address space necessary for execution of said module; a loader for loading said module and for allocating the required amount of uninitialised logical address/space in accordance with said indication; and means for accessing a record in said database, records in said database only being accessible through said module, and said accessing means providing a window onto a current record of said database and copying said record into a portion of said uninitialised
  • the present invention may provide a self-contained portable intelligent card including a first device for carrying out a transaction with a second device, said first device comprising: a virtual machine for inte ⁇ reting a set of customized byte code tokens applied thereto; said virtual machine including a virtual processing unit and read/writable logical address space; at least one database including at least one record and at least one computer program for execution by said virtual machine, said computer program being a module written in terms of a stream of tokens selected form said set and including an indication of the amount of uninitialised read/writable logical address space necessary for execution of said module; a loader for loading said module and for allocating the required amount of uninitialised logical address/space in accordance with said indication; and means for accessing a record in said database, records in said database only being accessible through said module, said accessing means providing a window onto a current record of said database and copying said record into a portion of said uninitialised read/writable logical address space address
  • the present invention also provides a method of carrying out a transaction between a first device and a second device, at least one of said first and second devices being an integrated circuit card; comprising: providing at least one program instruction on said second device capable of at least modifying the execution time behavior of a computer program on said first device; loading and inte ⁇ reting said computer program, loading and inte ⁇ reting said at least one program instruction dependent upon a pre ⁇ defined security condition while said computer program is running; and executing said loaded and inte ⁇ reted computer program with said modified behavior in response to said loaded and inte ⁇ reted program instruction
  • the present invention also provides a method of carrying out a transaction between a first device and a second device, comprising: inte ⁇ reting at least one application program written as a stream of byte code tokens selected from a set of tokens and corresponding in-line data; loading said at least one application program; allocating a first amount of read/writable logical address space specifically for said at least one application program in accordance with an indication contained within said application program of the amount of read/writable logical address space needed for its execution , and defining and protecting the boundaries of said allocated read/writable logical address space.
  • This method combines the use of an inte ⁇ reter with allocation and optional explicit deallocation of memory. This provides a mixture of flexibility and portability while providing rur.-time guarantees after the application program has been thoroughly checked at the compiling stage. It reduces the damage which can be caused by viruses in imported application modules.
  • the present invention also includes a method of carrying out a transaction system between a first device and a second device, at least one of said first and second devices being an integrated circuit card, comprising: inte ⁇ reting the tokens in a module written in terms of a stream of said tokens selected from a set of tokens; allocating an amount of uninitialised logical address/space in accordance with an indication in said module of the amount of uninitialised read/writable logical address space necessary for execution of said module; accessing a record in a database by providing a window onto a current record of said database, records in a database only being accessible through said module; and copying said record into a portion of said uninitialised read/writable logical address space addressable by said module.
  • the present invention also including a method of carrying out a transaction between a first device and a second device, at least one of said first and second devices being an integrated circuit card, comprising: providing a portable virtual machine comprising a virtual microprocessor and a driver for at least one input/output device; inte ⁇ reting a computer program on said first device using said portable virtual machine; and executing said program in response to said inte ⁇ reted program.
  • a secure transaction management system which preferably includes a portable virtual microprocessor.
  • each module owns a set of virtual address spaces guaranteed to be distinct from any other virtual address space.
  • the portable virtual microprocessor preferably, protects access to shared resources such as the various stacks or the databases.
  • the minimum protection is memory checking the bounds of data space access for reads and writes and absolute prohibition of writes to code space. Further, checking is preferred for underflow and overflow on data and return stacks.
  • a module can only access what some other module explicitly exports. Preferably, there is no way unexported data can be accessed (the virtual microprocessor doesn't leak) except through functions provided by a module.
  • Modules can preferably not export data in the usual sense; modules can preferably only export functions.
  • all the data owned by a module is preferably strictly private. This restriction is preferably enforced both at compile time and at runtime, as modules have separate address spaces, which means that the address of some data within some module is completely meaningless outside its owning module.
  • a module can only export a set of handles to trigger on or off a particular behavior.
  • well behaving modules will run flawlessly, while not so well behaving modules will be aborted by exceptions directly, thrown by the portable virtual microprocessor when an illegal operation is attempted
  • 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 the process of developing and executing a module in accordance with the present invention.
  • Fig. 4 is a schematic representation of a portable vertical microprocessor in accordance with the present invention as implemented on a terminal.
  • Fig. 5 is a schematic representation of the portable vertical microprocessor in accordance with the present invention.
  • Fig. 6 is a schematic representation of a modules loaded into memory in accordance with the present invention.
  • Fig. 7 is a schematic representation of the method of obtaining access to a database record in accordance with the present invention.
  • Fig. 8 is a schematic representation of the plug and socket procedure in accordance with the present invention.
  • Fig. 9 is a flow diagram of the module loading procedure of the present invention.
  • Fig. 10 is a flow diagram of the module executing procedure of the present invention.
  • Fig. 1 1 is a flow diagram of the socket plugging procedure of the present invention.
  • Fig 12 is a flow diagram of the card module loading procedure in accordance with the present invention. Appendix giving the token codes and standard exceptions
  • 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 one or more of the following features: using a virtual machine as an inte ⁇ reter, 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, including an indication of the amount of memory in the application program and allocating memory in accordance with the indication, explicitly deallocating memory and providing a secure way of importing and exporting data in and out of application programs and/or databases.
  • Fig. 1 is a schematic representation of a terminal 1 in accordance with the present invention.
  • the terminal 1 includes a central processor unit (CPU) 2 which is connected with memory 4 and input/output (I/O) devices 6 via a bus 3 for two way communication.
  • I/O devices 6 may be a keyboard for entering data and a screen such as a visual display unit, e.g. a liquid crystal (LCD) or light emitting diode (LED) display, for displaying the progress of the transaction and/or for displaying messages or prompts.
  • a visual display unit e.g. a liquid crystal (LCD) or light emitting diode (LED) display
  • One of the I/O devices 6 may be a card reader 7 with which an ICC 5 may be read when it is introduced into the receiving slot in the reader 7.
  • the actual form of the terminal may vary greatly, e.g.
  • POS point of sale
  • processors from an Intel 8051 to a PentiumTM.
  • the terminal 1 it is not necessary that the terminal 1 is all situated at one location, the various parts of the terminal such as the card reader 7, the I/O devices such as the keyboard and the display and the processor may located at different positions and connected by cables, wireless transmission or similar or be part of a local area network or interconnected by telecommunications networks.
  • Fig. 2 is a schematic representation of an ICC 5 in accordance with the present invention.
  • the present invention is however not limited thereto.
  • the ICC 5 includes at least an input/output (I/O) port 10 and some permanent storage, e.g. a non-volatile memory which may be provided, for instance, by a an EEPROM 15 connected to the I/O port 10 via a bus 17 or by battery-backed random access memory (RAM)
  • the I/O port 10 can be used for communication with the terminal 1 via 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 be a self-contained portable intelligent card and include a read/writable working memory e.g.
  • card ICC 5 can operate as a microprocessor, e.g. read only memory 13 for storing code, a sequencer 16 and connections with the card reader 7 for receiving the voltage sources Vss and VDD, a reset for the processor 12 and clock CLK to the sequencer 16.
  • the ICC 5 can be used as bank card, credit card, debit card, electronic purse, health card, SIM card or similar.
  • the present invention provides an integrated circuit controlled transaction management system intended to execute between an ICC 5 and a terminal 1 connected or not connected to a central unit, a transaction consisting of at least one execution of the following sequence:
  • selection of an application including selection of a computer program and the associated data set that defines the transaction in terms of the specific ICC 5 and the terminal 1 combination involved;
  • a transaction is an exchange of at least data between two or more devices and in accordance with the present invention is not specific to a commercial financial transaction.
  • the ICC 5 may be a mere memory ICC, i.e. not including processor 12, and the ICC 5 undergoes the transaction as determined by the terminal 1.
  • the ICC 5 may be a self-contained portable intelligent card and the transaction may be determined by the terminal 1, by the ICC 5 or by both.
  • the ICC 5 may include program code to securely enhance a terminal's processing.
  • ICC 5 may beone or more maintenance cards which may be used to update the applications stored in the terminal 5.
  • VM virtual machine
  • the virtual machine (VM) in accordance with the present invention explicitly makes available a theoretical or virtual microprocessor with standard characteristics that define addressing mode, stack usage, register usage, address space, addressing of I/O devices etc. in a generic way.
  • the kernel for each particular CPU type used in a terminal 1 or ICC 5 is written to make that respective processor 2, 12 emulate the VM. It is a specific aspect of the present invention that the kernel for the VM provides drivers for I/O devices and all low-level CPU logical and arithmetic functions, flow control, time handling.
  • the provision of I/O drivers in the VM has the advantage that any program written for the VM in accordance with the present invention addresses standard virtual I/O devices.
  • the implementation of the VM on a particular CPU then provides for the physical I/O devices connected to the terminal 1 or ICC 5 to be behave like the addressed virtual I/O devices.
  • the VM in accordance with the present invention is very compact and has been implemented successfully on a Siemens SLC044CR chip (derivative of the INTEL 8051 family) which may be included on an ICC 5.
  • the VM in accordance with the present invention makes a high degree of standardization possible across widely varying CPU and I/O types, and simplifies program portability, testing, and certification.
  • the portable VM 20 includes a virtual microprocessor and a driver for an I/O device.
  • the VM 20 provides logical and arithmetic functions and addressing of memory and the at least one input/output device.
  • the portable VM 20 in accordance with the present invention provides program portability across heterogeneous terminals 1 and card 5 by treating terminal and/or card programs as the intermediate code of a compiler. This code consists of streams of byte-codes, called tokens. Terminals 1 or ICC's 5 then process this code by inte ⁇ reting it or by other means such as native code compilation.
  • Virtual machine inte ⁇ retation of the tokens may preferably be accomplished by one of three methods: directly inte ⁇ reting virtual machine instructions, translating the virtual machine language into a directly executable intermediate form, or just-in-time compiling it into actual code for the target CPU. The latter two methods offer improved performance at a modest cost in complexity. Tokens are provided in a set which may be looked upon as the set of machine instructions for the VM 20.
  • modules which may include a list of tokens as executable code.
  • executable modules which have an entry point that is called directly by the VM 20 when the module is loaded
  • library modules which act as resources to other modules by providing exportable procedures that may be executed individually by intermodule calls.
  • the token set in accordance with the present invention includes firstly, the instruction set of the VM 20, which provides the instructions expected for a general processing language and are required for the efficient execution of programs and secondly tokens which provide what are normally called "operating system functions".
  • operating system functions include in accordance with the present invention specific functions such as I/O drivers, e.g. for displays and keyboards, and in terminals 1 and card 5, system functions may also include management of data object communication and transmission through I/O ports, and also inter-module access and access control mechanisms.
  • Tokens are preferably provided for the operation system of the VM, for stack manipulations, for socket handling, for control, e.g.
  • exception handling for the sockets themselves including their access rights, for I/O device access, for time handling, for language and message handling, for handling I/O readers, e.g. ICC, magnetic stripe card and modem handling, for blacklist management, for security algorithms, for terminal services, for database services, for data object handling, e.g. TLV handling, for module handling and for extensible memory handling,
  • Single-byte tokens are referred to as, primary tokens; these refer to primitive instructions such as are commonly found in any instruction set.
  • Multi-byte tokens are referred to as secondary tokens, and are used for less-frequently-used services.
  • the complete token set for the VM 20 is provided in the appendix As shown schematically in Fig 3 an application program is written on a PC host development system 70 and de ⁇ bugged and type approved in an appropriate high level language such as Forth, C, Pascal etc.
  • the source code of the program is compiled on a token compiler 71 into a stream of tokens
  • This token stream is separately combined with other data (the corresponding in ⁇ line data) needed by the program and a header, and encapsulated in a module delivery file to create a module 72, preferably in a standardized Module Delivery Format If the module contains executable tokens it is delivered in the Executable Program Format.
  • the executable modules contain not only the stream of tokens but also all corresponding in-line data (encapsulation)
  • the modules in accordance with the present invention contain an indication of how much read/writable memory should be allocated by the VM 20 for the module to execute
  • Module 72 is delivered to the terminal 1 by any suitable means, e.g in an ICC 5, via a telecommunications network After a module is downloaded, it is stored in a "module repository " When its function is required, the terminal 1 or card 5 uses a token loader/ interpreter 73 to process the tokens for execution on the terminal's CPU 2 This process consists of executing the function associated with each token
  • the token loader/inte ⁇ reter 72 is provided by the VM 20 in accordance with the present invention
  • the VM related software on a terminal 1 can be divided into four major categories
  • Kernel which includes terminal-dependent implementations of I/O drivers and all functions required in this specification for supporting the VM 20 Every other software related to the VM 20 is written in machine-independent tokens
  • Terminal Resident Services are at least one module which runs on the VM 20 as an applications manager, and includes all non-application functions, libraries supporting these functions, module loading functions, and the main loop defining the terminal's behavior Special tokens (e g. (DIOCTL) allow terminal-dependent aspects of I/O devices to be defined as in-line functions.
  • DIOCTL Terminal Resident Services
  • Terminal Selected Services include applications such as payment service functions, and libraries supporting these functions TSS contain only terminal independent tokens and are resident on the terminal 1
  • the TRS main program loop will select and call TSS functions as needed by a particular transaction
  • Card Selected Services include functions supporting terminal transactions, such as payment service functions that are used as part of a TSS application CSS are resident on an ICC 5 and downloaded to a terminal 1 as requested.
  • terminals 1 with two ICC readers 8 e.g., one for normal transactions and one for maintenance
  • there may be two independent sets of CSS CSS 1 and CSS2.
  • All software on a terminal 1 in accordance with the present invention is organized as a set of separate modules
  • the fundamental characteristic of a module is that it is a collection of definitions or program functions that have been passed through a token compiler 71 and encapsulated as a single package for delivery to a target environemnt, e.g. a terminal 1 or an ICC 5.
  • the main Terminal Program (TRS) each application, each library, and each CSS download are examples of modules.
  • all modules use a standard format.
  • the kernel in a system according to the present invention defines the VM 20 which provides a variety of high-level services to these modules, such as.
  • the VM 20 always operates in supervisor mode and can only execute instructions defined in terms of its token set and no module may operate in user mode, i.e. assume control of the VM 20 Hence, in an implementation of the VM 20 using a memory map, only one memory map is created , namely the supervisor map
  • No module may compromise the operating system defined by the VM 20 This is guaranteed because a module may only contain tokens from the VM token set and none of these tokens allow access to the code space where the kernel is stored. If a token is encountered by the VM 20 which lies outside the defined set, an exception is thrown (ILLOP)
  • terminal 1 includes the terminal specific operating system 8 responsible for loading the TRS module of the VM 20 (loading procedure is described later).
  • Code for the VM 20 is stored in the terminal read only non ⁇ volatile memory 1 1.
  • the terminal volatile memory 19 of the terminal 1 is empty of all transaction related data
  • the terminal read/write non- volatile memory 18 contains the applications to be executed by the VM 20 in the form of modules 72 in a module repository, the non-volatile databases containing user specific data and libraries such as the plug library which will be described later.
  • the VM 20 is also implemented upon an ICC 5, the same principles as described above apply with respect to the read only non-volatile memory 13, the volatile memory 14 and the read/write non ⁇ volatile memory 15 of ICC 5.
  • VM 20 As VM 20 is a virtual machine it addresses all forms of terminal or ICC memory 1 1, 18, 19; 13, 14, 15 as virtual memory, i.e. they are all addressed in logical address space as seen from the VM 20. In an actual implementation of VM 20, these logical address spaces are mapped into actual address spaces in the memory of terminal 1 or ICC 5 by a memory map or similar.
  • volatile, read/write non- volatile and read only non-volatile memory as being part of the VM 20. It is to be understood that this refers to logically addressed memory space unless specific mention is made to actual addresses in an implementation of VM 20 on a terminal 1 or ICC 5.
  • Volatile memory does not survive program loading or power-down and/or rebooting. Preferably, volatile memory does not survive power down for security reasons. Non ⁇ volatile memory survives program loading or power-down and rebooting.
  • the VM 20 is a stack machine and has a data stack pointer (stored in the data stack pointer register 32) that points to a pushdown data stack 27 preferably in on-chip memory. All operations are performed on this stack 27.
  • the data stack 27 is used to contain parameters of procedures and temporary results from expression evaluation. Data is pushed onto or popped 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 contain return addresses, and also may be used for temporary storage. This multiple stack architecture is known from the Forth programming language (ANSI X3.215-1994).
  • This architecture has been further modified for portability, code density, security, ease of compilation, and for use with other programming languages.
  • it contains provisions for local variable frames used in high level programming languages, such as C.
  • token compilers 71 in accordance with the present invention can be written not only for Forth but also for C and other programming languages.
  • application programs may only retrieve from the return stack 28 what they have explicitly put on it inside the current procedure, and must remove data placed on the return stack 28 during the current procedure before exiting the procedure.
  • the VM 20 includes a security manager for providing run-time integrity and which monitors every activity on the return stack and checks all data is removed during the currant procedure.
  • the VM 20 may hold exception execution state information, frames for local variables, loop control parameters and database context on the return stack 28.
  • the VM 20 may include a plurality of stacks.
  • further stacks 29 may be provided such as exception and frame stacks.
  • An exception stack is used to store the execution state during an exception processing.
  • a frame stack is used to maintain local variables information, as well as C language-like activation records.
  • the exception and frame stacks 29 may be implemented on the return stack 28
  • the data, return stacks 27, 28 and other stacks 29 such as the exception stack are not in a memory space directly accessible by any application program.
  • the data or return stacks 27, 28 cannot be addressed directly, they are only accessible via stack operations. For security reasons, there is no limitation on how the data is stored in an actual implementation, so that malicious persons may make no assumptions as to how the data is stored physically.
  • the VM 20 includes a virtual central processor unit 22 which includes a virtual arithmetic logic unit 23.
  • the VM 20 addresses a virtual or logical data space 24 and which is treated by the VM 20 as random access memory (RAM) and would normally be implemented as part of the volatile memory 19, e.g. in RAM in an actual terminal 1 or card 5.
  • RAM random access memory
  • the logical data space 24 is accessible for data storage only.
  • the token stream of a module is stored in by the VM 20 in code memory 26 which is treated as read only memory (ROM) by the VM 20. Only the VM 20 may read the tokens Code memory 26 is not accessible for application programs nor by any token.
  • the VM 20 may include virtual registers 30.
  • the VM 20 registers 30 may include Token Pointer register 31 which holds the pointer which points to the next token to be executed, Data Stack Pointer register 32 which holds the pointer which points to the current top of data stack 27 (TOS) location, Return Stack Pointer register 33 which holds the pointer which points to the current top of the return stack location, Frame Pointer register 34 which holds the pointer which points to the frame start in data space 24, Frame End Pointer register 35 which holds the pointer which points to the frame end in data space 24 No direct access is provided to registers 31 to 36 by the token set but only via the register access tokens
  • VM 20 in accordance with the present invention is defined preferably as a byte- addressed, two's complement, 32-bit machine, with 32-bit registers and stack elements however the invention is not limited thereto.
  • the register/stack size is referred to as the cell size of the VM 20, a cell being the basic unit of manipulation on the stacks and by the VM registers 31 to 36 The size of the cell used by the VM 20 is not considered to have a material affect upon the present invention
  • Programs may not assume that the data in any of the above categories is guaranteed to be held on the return stack 28, and so may use only the retrieval mechanism specified explicitly for a given category as the security manager ma delete any such data • Programs that pass data in one of these categories to the VM 20 must take appropriate action to recover the data storage from the VM 20 before exiting from the procedure in which it is passed otherwise the VM 20 will deallocate the relevant part of memory
  • Programs must assume that any data previously placed on the return stack 28 is rendered inaccessible by passing data in one of these categories to the VM 20 • Programs must assume that any data in one of these categories passed to the VM 20 is rendered inaccessible by executing code that places values on the return stack 28, until such time as those values are removed because the return stack is only accessible by the specified token procedures.
  • the operating system of VM 20 defines a single address space 24 available to each module This address space 24 shall be accessible for data storage only, and will be referred to as "data space" 24
  • Data space 24 is divided into three and one optional logical regions, each of which is individually contiguous 1 initialized data space 41, which contains initial values specified at compile time and set when the VM kernel is activated and subsequently when a module containing initialized data is loaded;
  • uninitialized data space 42 which contains variables and static buffers allocated during program compilation. This data space 42 is initialized to zero by the VM 20; 3. frame memory 46, which is managed by the frame tokens;
  • extensible memory 45 which contains one or more buffers allocated dynamically during program execution.
  • extended memory 43 typically mass storage which is used to contain data objects and volatile databases
  • non-volatile memory 44 is used to contain data that is guaranteed by the VM 20 to survive module loading or power-down and rebooting (within the limitations of the terminal hard-ware), including the module repository and non-volatile databases. This may be implemented in battery-backed RAM, disk, or other persistent storage. Non-volatile memory 44 may be implemented as part of the read/write permanent storage 18.
  • extended and non- volatile memory 43, 44 is accessed only through tokens that provide "windows" to selected data in the form of buffers in uninitialized data space 42.
  • a programmer can only ask for a record and cannot know the exact location of data in order to access it.
  • each data space 24 used by a module memory is allocated by relative addressing and only at run time. This means that an address only has meaning within each module when it is loaded. As absolute addressing is not used, it is not possible for a module to gain access to data of another module except by the secure module access mechanisms described later.
  • Theframe mechanism allows the VM 20 to satisfy the requirements of languages such as C that permit local variables to be defined at run time.
  • a frame holds procedure parameters passed on the data stack 27 as well as "local" variables (temporary data storage that shall be freed automatically when the frame is released, normally at the end of procedure execution).
  • Frame start and end pointers are maintained automatically by the VM 20 within the frame.
  • the frame pointer register 34 points to the logical base of the frame and frame end pointer 35 points to the logical end of the frame in data space 24. Parameters can be fetched from the frame using the frame access tokens.
  • the VM 20 may optionally provide a dynamically allocated pool of extensible memory 45 as a single extensible buffer managed by the VM 20 which appears outside the program's uninitialized data space 42.
  • Programs may request an allocation of a specified amount of extensible memory 45 and are returned a pointer to a base address for that memory 45.
  • Subsequently programs may release memory 45 from a given address, e g on termination of the program, causing all allocations beyond that address to be released
  • modules are executed in a single-thread but the invention is not limited thereto This means that if one module calls a second module, the second module terminates and all resources of the second module are deallocated before the VM 20 returns to the first module and continues processing.
  • Fig 6 show a schematic representation of logical memory as seen by the VM 20
  • a first module on the left with initialized memory 41, uninitialized memory 42 and frame memory 46 and token code space 26 has been loaded into the read/writable memory starting at address 1.
  • the first module has also called and been allocated a portion 45 of the extensible buffer
  • the second module on the right is called by the first module (e.g. to import the function fgh which is in the exclusive list in the header of module 1 of functions which may be imported)
  • data space 24' including initialized memory 41', uninitialised memory 42' and frame memory 46' are allocated as required starting at address 2.
  • the tokens of module 2 are read directly by the VM 20 from the module repository which is an option allowed in accordance with the present invention
  • the extensible memory 45' for the second module is allocated by the VM 20 higher in the memory than the extensible memory 45 for the first module
  • all memory above address 4 is deallocated ("rubber band effect")
  • all temporarily stored data is erased on deallocation. If necessary, more extensible memory 45 could then be called on return to the first module. If the second module is then called again, it will be allocated a different starting address for the extensible memory 45' than for the first time it was called.
  • An automatic release of dynamically allocated extensible memory 45 shall occur when a module's execution is completed, limiting the effects of program failure to release memory cleanly
  • the allocation of dynamically allocated extensible memory 45 may be restored to its condition at the time of the governing CATCH exception
  • User variables are cell-sized variables in which the VM 20 holds contextual information for the client programs Storage for user variables is pre-allocated by the VM 20.
  • a limited number of variables may be provided, e.g sixteen variables (referenced as 0 to 15).
  • An implementation of VM 20 that supports multitasking may provide one set of user variables for each task.
  • the VM 20 provides a single exception handling mechanism via the tokens
  • CATCH, THROW and QTHROW These tokens are derived from the Lisp exception handling mechanism, and appear in ANS Forth as CATCH and THROW
  • the pu ⁇ ose of this mechanism is to provide for local handling of exceptions under program control at various levels in the software
  • the concept is that the program passes a function's execution pointer to the token CATCH, which will execute that function and return a code indicating what, if any, exception occurred during its execution.
  • CATCH records implementation-dependent information sufficient to restore its current execution state should a THROW occur in the function passed to CATCH for execution This includes (but is not limited to) data and return stack depths, the frame pointer and, in some cases, the extensible memory pointer
  • the collection of information representing an execution state is referred to as an "exception frame " Exception frames are kept on the exception stack.
  • the program can examine any exception code that may have been returned, and elect to handle it locally or THROW it to a higher level for processing
  • the VM 20 provides a default outermost level at which exceptions will be trapped This outermost level will be activated when no inner level of CATCH has been established
  • the default exception handler aborts any current terminal transaction and attempt to reload TRS modules and re-enter the TRS main loop.
  • the VM 20 throws ANS Forth exception -10 (Division by zero) should that condition occur
  • the VM 20 may throw other general exceptions supported by ANS Forth, e g as given in the attached appendix
  • each device For handling devices and input/output (I/O) services, each device, including those devices whose lower-level operation is hidden by the VM 20 behind device-specific functions, is assigned a device type (used to categorize result codes) and a unique device number.
  • Device numbers are arbitrary; however, references to device numbers -1 through 15 (4 bits) may be made with only a single token, and so these are assigned to the most common devices such as keyboards, ICC readers, magnetic stripe card readers, displays, printers, power management devices or vending machine.
  • General I/O facilities are provided by functions taking the device number as an input parameter.
  • a terminal 1 in accordance with the present invention preferably contains at least three major non-volatile databases: an application-specific transaction log, a database of messages in one or more languages and a database of modules.
  • the VM 20 protects databases as much as possible as they may contain private information. Access to databases is restricted.
  • the VM 20 provides a mechanism for handling databases (the VM 20 as a "server") that conceals implementation details from the application software (application as the "client"). No direct access to the database is allowed from a module running on the VM 20.
  • the services implement the following features which will be described with reference to Fig. 7: • At any given time the client, i.e. a program running in an module, has access to one currently selected database (DBCURRENT) and one currently-selected record number (DBRECNUM) that is shared across all defined databases.
  • DBCURRENT currently selected database
  • DBRECNUM currently-selected record number
  • DPB 51 Database Parameter Block
  • the client "owns" the DPB 51 , in the sense that it is in the client's data space 24; but the client is not allowed to access it directly. Instead, only database service tokens may be used to access the data.
  • the DPB 51 has a standard structure including fields for at least a DPB link, a database pointer, an indication of the database type and of the record size and the next available record number. All information to specify a database must be preset in the DPB 51. Client software may not make any subsequent direct access to the DPB 51 and must make no assumptions about the values directly held in the DPB 51 after the module defining that DPB 51 has been loaded for execution.
  • Database Parameter Blocks 51 are passed to the token loader/inte ⁇ reter in the form of a pointer (DPB link) to a linked list in the initialized data section of a module.
  • This field must be preset to the address in initialized data of the next DPB 51 in the list; or zero if this DPB 51 is the last or only DPB 51 in the list.
  • the DB pointer For compiled databases that exist in the client's initialized data space, the DB pointer must be preset to the "origin" address in initialized data. For databases whose storage is controlled by the server, the field must be preset to zero.
  • the DB type provides details of the database in coded form.
  • Non-volatile databases whose content does not need to be preserved between module loads or across a power-down of the terminal 1 on which it resides.
  • Non-volatile databases whose content must be preserved between module loads or across a power-down. If the module defining a non-volatile database is replaced, the database is destroyed when the old module is unloaded.
  • Compiled databases are constructed by the token compiler 71 in a contiguous area of initialized data as fixed-length records. Records may not be added to or deleted from a compiled database, and the database may not be initialized at run-time, but otherwise full read- write capability shall be supported. The next available record number field must be set to one plus the last allocated record number in the database for compiled databases. For any other database this field is set to zero
  • the address of a window onto the current record (a record buffer 53) is provided by the server to the client for each client database.
  • the client may pass the addresses of strings and key buffers 52 to the server.
  • a record buffer 53 is provided by the VM 20. This buffer 53 starts at an aligned address.
  • the content of the record buffer 53 associated with a particular database after a record selection remains available until the client selects another record from that database.
  • no other data space 54 is shared between client and server. Programs may not assume that records in a database are contiguous in memory.
  • a database is instantiated by the loading process for the module in which its DPB is defined.
  • Volatile databases installed by application modules are uninstantiated automatically and transparently by the server when the application is terminated by Terminal Resident Services, when all server-allocated data storage relating to those databases is released.
  • the server deletes non-volatile databases when the module that defined them is replaced. If the module is loaded when replaced, e.g., in the case of a TRS module, the server must delete the module's non-volatile databases when the module is unloaded.
  • the action taken by the VM 20 when a database is instantiated at module load time depends on the value of DB type and DB pointer in the DPB 51, and whether the database is volatile or non-volatile. If the database is a non- volatile type, the DPB address is used in conjunction with the module identification (module LD) to identify any prior data that belongs to the database. If prior data exists, the next available record number is restored to its previous value. Otherwise, the server (VM 20) instantiates new non-volatile storage space and sets the next available record number to zero. In both cases a buffer 53 is provided for the current record in the database.
  • DB pointer is zero and DB type is not a compiled type
  • the server instantiates or makes available the storage required for the database, initializes the storage to all zeros, provides a buffer 53 for the "current record" of the database, and sets the next available record number (DBA VAIL) to zero.
  • DBA VAIL next available record number
  • the server sets up internal structures to make use of the client data structure whose origin address has been passed at DB pointer and sets the next available record number (DBA VABL) to the value passed in the next available record number field of the DPB 51.
  • the server maintains the actual database records 55, the relationship between the address location and the record in a database control block 56 and a record of which database a module is currently accessing in a context info block 57.
  • the secure module handling procedure in accordance with the present invention will now be described with reference to Fig. 6.
  • Fig. 6 an area of logical read/write memory is shown.
  • An area of memory which may be accessed by the left hand module (first module) has a dotted line.
  • An area of memory which cannot be accessed by the first module has a border of a continuous line.
  • An area of memory which can be accessed by more than one module is shown with a dot - dashed line.
  • VM 20 protects databases DB1 and DB2 and the database repository and the modules in the module repository so that they are not accessible by any module.
  • the uninitialised data in memory 42 can be accessed by the first module but the VM 20 does not allow that any area outside this module may be accessed directly by the module.
  • Access to registers, stacks or frame memory 46 can only be made through the relevant tokens.
  • Databases can only be accessed via the window procedure mentioned above.
  • the first module cannot access its own program memory 26 where the tokens are located nor access any other module. This is of importance for protection against viruses.
  • the memory is allocated to first module is defined and protected.
  • the exclusive import list of the first module is in its header which the first module cannot access directly.
  • the VM 20 reads the header and calls the second module which is mentioned in the import list (function fgh from the second module).
  • the VM 20 loads the second module and allocates memory for the uninitialized data 42', frame memory 46', and initialized data 41'.
  • the first module cannot access any part of the second module and vice versa.
  • the function fgh has been placed in the exclusive list of functions which can be exported. This makes the function fgh available for other modules.
  • the VM 20 searches for the function fgh in the code memory space 26' of the second module and executes the token stream with corresponding in-line data
  • a database in accordance with the present invention is "owned" by a module, i.e. a database can only be accessed by the module which instantiated it on first loading of the module.
  • the database access tokens read from code space 26' are executed by the VM 20 which allocated a buffer 53' in the uninitialised data space 42' of the second module on loading.
  • the function fgh requires access to the third record of DB2.
  • the VM 20 then transfers the referenced record to the window 53' in the second module from which it is exported to the uninitialised space 42 of the first module.
  • the first module may also obtain a record from its own database DB1 which is transferred to the buffer 53 in the uninitialised data space 42.
  • the first module may now operate on the results of the two procedures.
  • the VM 20 preferably deals with data objects by means of Basic Encoding Rules or Tag, Length, Value (BER-TLV shortened to TLV for this application), as described in ISO/IEC 8825 (1990).
  • TLV data objects consist of two or three consecutive fields: a tag field specifying its class, type and number, a length field specifying the size of the data, and if the length is not zero, a value field containing the data. Because ICC card responses are generally limited in size to say 255 bytes or less, there is a maximum size of a TLV object in accordance with the present invention.
  • the tag field is preferably one or two bytes
  • the length field is preferably one or two bytes
  • the maximum size of the value field is preferably 252 bytes (a field this long requires two length bytes, as explained below)
  • Bits 7 and 8 specify the class of the object. Bit 6 determines if the value field contains "primitive" data or if it is a "constructed" object consisting of other TLV-encoded fields. Constructed objects are also called templates. They cause their value fields to be parsed for TLV sequences when they are encountered. Bits 1 to 5 specify the number of the object or, if all these bits are set, they indicate that additional tag bytes follow. The additional tag bytes have their eighth bit set if yet another byte follows. All bits in up to two bytes are used to determine a tag name. The length field consists of one to three consecutive bytes, typically two.
  • bits 1 to 7 indicate the size of the value field. 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, indicate the size of the value field and occur with the most significant byte first.
  • the value field can consist of "primitive" data or be "constructed” with additional TLV encoded sequences. If bit 6 of the first byte in the tag field is set, then the value field contains additional TLV sequences.
  • the primitive objects can be encoded in several different formats: Binary Coded Decimal nibbles with leading zeros or trailing nibbles with all bits set, binary numbers or sequences of bytes, character sequences of alpha/numeric or ASCII bytes, or undefined formats.
  • An ICC 5 may also use a Data Object List (DOL) to request values of specified tag names.
  • the card 5 sends a DOL consisting of a list of tag and length fields, and the terminal 1 returns the corresponding value fields, without delimiters.
  • DOL Data Object List
  • Each TLV to be used must be defined by the terminal or application programs to establish its data type and name. Since the terminal program and the application programs are developed separately, the VM 20 in accordance with the present invention uses a linked structure (a balanced binary tree) to allow rapid addition and removal of tag names from the global tag name list. This requires that the following structure be compiled for each TLV in initialized data space 41 in the module defining the TLV: Link A cell with "left" (high-order two bytes) and "right” (low-order two bytes) components providing links to elements of the tree. Link left A 16-bit signed offset from this TLV's access parameter to the access parameter of a TLV record whose tag is numerically less than this record's tag.
  • a value of zero indicates that this TLV is not linked to a TLV with a tag numerically less than this one.
  • Link right A 16-bit signed offset from this TLV's access parameter to the access parameter of a TLV record whose tag is numerically greater than this record's tag.
  • a value of zero indicates that this TLV is not linked to a TLV with a tag numerically greater than this one.
  • TLV Tag A two-byte string whose big-endian numeric value is the TLV tag.
  • Reserved A byte that must be initialized to zero by the compiler 71.
  • Data A cell that holds VM-specific information including access to the length and value fields of this TLV. This field must be initialized to zero by the compiler 71.
  • the system must also maintain a status byte for each TLV. This may be the Reserved byte in the above structure. The low-order bit of this byte shall be set if the TLV has been assigned a value as a result of being in a sequence that has been processed by the tokens TLVPARSE or TLVSTORE.
  • the pu ⁇ ose of maintaining an assigned status is to identify TLV values that contain valid data (which may be zero) and distinguish them from TLV values that have never been set and are therefore invalid.
  • the VM kernel manages a global list of TLV tags by maintaining a list of pointers to the 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 it is unloaded, its TLV definitions shall be removed from the list automatically by the VM 20. An exception may be thrown if the module contains a TLV definition that already exists.
  • the address of the Link field described above is returned as the "access parameter" for TLV references. The programmer should not access these fields directly, nor make any assumption about their contents, after the VM 20 has instantiated the TLV definitions.
  • references to TLV definitions in the source code are compiled as either direct references to the definition structures defined above, or numerical tag values. Within certain binary TLV definitions, individual bits or groups of bits are defined to have certain meanings. These are referred to as "TLV bits". References to TLV bits may be compiled with a literal pointing to a bit within the value field of the TLV. Bit 0 is the least significant bit of the first byte, bit 7 is the most significant bit of that same byte, bit 8 is the least significant bit of the second byte and so forth.
  • the data assigned to a TLV definition is exposed to the application through a 252- byte scratch pad area maintained by the VM 20 in the form of a database window (see Fig. 7).
  • the application program is permitted to change the contents of this scratch pad area. If changes are to be retained, an address and length within the scratch pad area must be passed back to the TLVSTORE token. The address and contents of the scratch pad area may become invalid when any TLV token is subsequently executed.
  • Black or Hot Card List management is provided by a set of dedicated functions that are specific to the management of a large hot card list.
  • a typical list may contain 10,000 primary account numbers (PAN) of up to 10 bytes each, or 20 binary coded decimal (BCD) digits.
  • PAN primary account numbers
  • BCD binary coded decimal
  • the PAN entries are stored in compressed numeric (en) format, right padded with hexadecimal FH 's. As a PAN is a maximum of nineteen BCD digits, an entry in the list will always be padded with at least one FH .
  • FH 's in a list entry are considered as wild cards or "don't care" digits, but any FH 's in the PAN used as input are not wild cards Wild cards can only appear at the right-hand end of an entry.
  • a PAN shall be considered found in the hot card list if there is a list entry that is identical up to the first FH in the entry.
  • Another part of security management is the provision of cryptographic services for encrypting and decoding data. Any suitable encryption methods may be used. Three cryptographic algorithms are particularly provided for the VM 20: modulo multiplication and modulo exponentiation, which are used in the RSA algorithm; and the secure hashing algorithm SHA-1, but the invention is not limited thereto.
  • Modulo Multiplication performs a multiplication of two unsigned values x and y, where the product is reduced using the modulus z.
  • the input values (x,y,z) are all the same length. They are represented by byte strings and can be any multiple of 8 bits up to and including 1024 bits. The values must be in big-endian byte order.
  • the Secure Hash Algorithm (SHA-1) algorithm is standardized as FIPS 180-1. SHA-1 takes as input messages of arbitrary length and produces a 20-byte hash value. Modulo Exponentiation raises an unsigned value x to a power given by an unsigned exponent y, where the product is reduced using the modulus Z.
  • the input value x and modulus z are represented by byte strings and may be any multiple of 8 bits up to and including 1024 bits. The values must be in big-endian byte order. Services and therefore software and even I/O devices may change with time depending upon market requirements. When major changes are required, an update of the software in the terminal 1 may be carried out by hand or remotely via a telecommunications network. However, for user dependent services it is preferable to have a dynamic but secure method of making minor or user-specific upgrades to the services provided by a terminal 1.
  • the "plug and socket" software mechanism in accordance with the present invention provides a flexible and secure way of on-line configuration of the different modules that make up terminal programs and applications. As shown schematically in Fig.
  • a number of procedures may be defined that may be inserted by the application programmer (and hence secure because it is under acquirer control and under payment system supervision) into an application 61, 62 to act as placeholders for the addition of additional enhancing code (referred to as "plugs" 66) during transaction processing. All additional code to be plugged into a socket 60 must be written in terms of the token set of the VM 20. Sockets 60 are preferably placed at various suitable points in existing terminal applications 61, 62 or even in the terminal program itself.
  • Sockets 60 are initialized to default behaviors by the VM 20. If no further action is taken by the terminal program, the default behavior of sockets 60 will be to do nothing when they are executed (i.e. no-operation).
  • Plugs 66 include executable code, written in tokens supported . by the terminal 1, that may be inserted at points defined by sockets 60 to enhance the default terminal logic. Plugs 66 may already exist in the terminal 1 in a plug library 63 to be invoked from the ICC 5, e.g. socket/plug identifiers 67 in an ICC 5 and logic in the terminal 1.
  • Socket/plug identifiers 67 include a refernce to both the plug and the socket to be plugged whereby the plug is not on the ICC 5 but in the library 63.
  • Plugs 66 may also come from an input device 65 (such as the ICC 5 or a host system connected to the terminal 1 ), but only if agreed by the members of the payment system, e.g. issuer, acquirer, and merchant.
  • an ICC 5 does not contain entire applications but only plugs 66 that enhance existing terminal applications as these require less memory.
  • Sockets 60 hold execution pointers, also known as procedure pointers, that allow the creation of a procedure whose behavior may be changed at execution time. Sockets 60 may be viewed (and implemented) as an array of procedures that are accessed through the DOSOCKET token, which takes the socket number as an in-line byte, or by the IDOSOCKET token, which takes the socket number from the data stack 27.
  • DOSOCKET token which takes the socket number as an in-line byte
  • IDOSOCKET token which takes the socket number from the data stack 27.
  • Sockets 60 enable re-configuration of a terminal program or application to provide variations or enhancements in the transaction processing flow.
  • sockets in ICC 5 may allow upgrading of ICC's 5 from a terminal 1.
  • Sockets 60 provide an interface between software modules and procedures that may be coming from several different sources (acquirer, issuer, etc.). Since an acquirer and an issuer have a contractual relationship, they may agree to use specific sockets 60 provided by the acquirer's program in a terminal so that an issuer may extend the behavior of the program, for example to provide a loyalty function (air miles, coupons, etc.).
  • a module may specify that sockets 60 be reconfigured automatically when it is loaded for execution, or a client program may programmatically assign a new procedure to a socket at run-time.
  • sockets 60 in an application may be assigned a default behavior and then may be re-plugged with new procedures by subsequent modules, in order to provide specialized behaviors.
  • all procedures vectored to use a particular socket 60 have no data stack effect (except for socket zero as explained later). This ensures program continuity no matter which vectored version of the procedure is executed.
  • the default action of all sockets 60 before modification shall be at least that of a no-operation.
  • An acquirer may allow transaction enhancements by code on an ICC 5 as part of the CSS referred to above.
  • a library or executable module may include the definition of new sockets 60 for later plugs 66 coming from an ICC 5. In this case the module would define a socket 60 and then use the SETSOCKET token to assign a default behavior to it (often a null behavior). If access control allows it, an ICC 5 could later down-load a plug 66 including tokens that define a new behavior and then use the SETSOCKET token to store it in this same socket 60, overriding the default behavior.
  • Modifying behaviors is convenient and flexible but can provide the opportunity for malicious persons to modify behavior to their advantage. Special care may be required for plugs 66 from an ICC 5 if they can modify a socket's behavior or be placed in the program flow prior to successful card authentication.
  • the terminal software can specify in accordance with the present invention, a socket control procedure that controls whether or not each individual socket 60 can be modified.
  • the execution of code downloaded from an ICC 5 can be strictly controlled by the acquirer so that no socket may be plugged from the ICC 5 until all validation routines have been carried out on the card, e.g. examination of an electronic signature.
  • socket security includes specifying the socket control procedure to be applied on subsequent attempts to plug a socket 60 (SETPLUGCONTROL token).
  • the procedure PLUGCONTROL must be written to return, for a given socket number, whether that socket 60 may now be modified
  • the VM 20 first executes the user-written PLUGCONTROL procedure to determine whether the socket 60 really can be plugged, and retains the existing behavior of the socket 60 if it cannot.
  • a module that wishes to restrict access to any sockets 60 before another module is loaded for execution may execute a procedure defined by the SETPLUGCONTROL token on a pluggable socket (socket zero) with the chosen PLUGCONTROL function as a parameter, before loading that module.
  • sockets 60 to which access is denied by the user defined PLUGCONTROL procedure shall retain their existing behavior. This condition shall not be considered an error.
  • Code that wishes to restrict access to any sockets 60 before further code is executed may execute the procedure defined by the SETPLUGCONTROL token with the chosen PLUGCONTROL procedure as a parameter, at an appropriate point in program flow.
  • a programmatic request to plug a 60 can determine whether the request was accepted or denied by the call to SETSOCKET. Any socket 60 whose behavior was modified, either by the module loading process or dynamically by programmed command, is restored to the behavior it had when the last executable module was loaded for execution, as part of the termination procedure packaged within the procedure defined by the module execute token (EXECUTEMODULE)
  • the basic transaction code includes the phrase 27 SOCKET LOYALTY which defines LOYALTY and makes it available for later execution.
  • the acquirer's transaction program code further defines code that sets the permission flag for this socket only if the issuer is the same as the acquirer and the transaction amount exceeds a certain minimum.
  • During the transaction there is a command which reads in arbitrary code from the ICC 5.
  • Part of the ICC code could define a REWARD routine which updates the user's frequent flier miles, and then attempt to execute the phrase PLUG REWARD INTO LOYALTY. This phrase connects the execution of REWARD with the execution of LOYALTY. If the basic transaction code includes the phrase 27 SOCKET LOYALTY which defines LOYALTY and makes it available for later execution.
  • the acquirer's transaction program code further defines code that sets the permission flag for this socket only if the issuer is the same as the acquirer and the transaction amount exceeds a certain minimum.
  • During the transaction there is
  • LOYALTY socket permission flag is set according to the above logic, the SETSOCKET will take place, otherwise LOYALTY will retain its default behavior, likely a no-op Then when the application code executes its LOYALTY function later, it will allow the ICC- defined REWARD only according to the acquirer-defined rules.
  • the VM 20 running on a terminal 1 may have a limited number of sockets 60, e.g 64 sockets, numbered 0 through 63.
  • a skeleton terminal program could be composed nearly entirely of sockets 60 and basic program flow from socket to socket.
  • the sockets 60 would then be plugged with transaction processing procedures by other modules loaded at application selection time, either from the terminal 1 or from the ICC 5.
  • Sockets 60 occurring in the skeleton program before application selection are assigned a default null behavior by TRS. If a given socket 60 is plugged with a procedure by more than one module, the latest operation simply replaces any earlier ones.
  • Code written to run on the VM 20 may assume that following power-up the terminal-specific kernel software supporting the VM 20 has performed any necessary terminal-specific power-up initialization, and has started execution of the main processing loop of Terminal Resident Services (TRS) through a module loading process which is described below. If the main processing loop of the TRS is exited, control returns to the terminal-specific layer of software responsible for reloading the TRS and re-entering its main loop. All VM resources are released whenever the TRS exits, except for data in non-volatile databases. Resource releasing occurs when the terminal is powered down, the TRS exits, or the TRS is restarted by the terminal's Operating System (if any).
  • Terminal Resident Services Terminal Resident Services
  • Each module is preferably delivered to a terminal 1 in a Module Delivery Format (MDF)
  • MDF Module Delivery Format
  • the VM 20 maintains a non-volatile repository in the read/write non-volatile memory 18 of modules that have been delivered and installed on the terminal 1
  • Each module in the repository shall be identified by a module identifier or module ID Following registration in the module repository, module information is available through a non ⁇ volatile module database maintained by the VM 20 and stored in non-volatile memory 18
  • the VM 20 protects modules within the repository from modification by any other module because there are no tokens for such an access
  • the VM 20 makes provision for a new version of a given module to be placed in the repository while a module of the same module ID exists for execution pu ⁇ oses.
  • step 100 the resources are marked and saved Before execution of a module, the VM 20 marks its state and saves any resources needed so that this state can be restored later
  • the state includes
  • step 102 the module ID of the module to execute is passed to the Load Module subroutine, which will be described later If the module is loaded without error as determined in step 104, it can be executed and the program progresses to step 108 If an error is determined in step 104, the execution of the module is abandoned and all resources needed for execution of the module are released in step 105 This requires that VM 20 carries out the following actions
  • step 106 if the module is an executable or a library module. If the latter, no execution of the module takes place and the VM 20 releases all resources in step 110 as described for step 105. If the module is executable the field specifying the entry point of the module is determined.
  • the VM 20 starts the module by calling the token specified in the entry point field. Then each token is executed in turn in step 108. The module terminates using a RETURN token after which all resources are released in step 110.
  • Step 120 it is determined if the module is already loaded into memory. If it is already loaded, it is not loaded a second time and Load Module immediately succeeds, returning true.
  • step 122 it is determined if the module is in the repository. If not, it cannot be loaded so Load Module subroutine fails, returning./ ⁇ /st?.
  • step 124 is determined how many bytes of data for the module's uninitialized data area 41 are needed and the required amount is reserved. This area 41 is set to all zeroes by the VM 20.
  • step 126 the required number of bytes of data for the module's initialized data area 42 are reserved. Then, the initialized data is copied into this area.
  • step 18 the TLVs defined in the module to be loaded are added by the VM 20 to its internal name list used for TLV lookup. The root of the TLV data structure is stored.
  • step 130 the databases defined in the module to be loaded are instantiated by the VM 20. Steps 128 and 130 may be executed in any order.
  • step 132 the imported modules for the current module are selected.
  • step 134 the list of imported modules is traversed, recursively loading each one in turn. If an imported module cannot be loaded for any reason, as determined in step 136, the module that imported the module is also deemed to have failed to load, as it cannot access the imported module's services. In this case, Load Module In step 138 it is determined if a further module is to be imported. If yes, the procedure returns to step 132.
  • step 138 After the determination in step 138 that the last imported module has been recursively loaded, the current module has had its resources allocated, loaded, and instantiated without error, so the Load Module plugs the sockets 60 in its list in step 139 and then returns true indicating that the module was loaded successfully. Any attempt to plug socket zero must be ignored by the VM 20. If socket zero needs to be plugged, it may be accomplished using the SETSOCKET token.
  • step 140 the default behavior for each socket in a loaded module is instantiated.
  • step 141 it is determined if there is a plug. If no, then the module is executed in step 149. If yes, the first plug is selected in step 142.
  • step 143 it is determined if the security flag of the associated socket is set or not. If not, the socket is plugged in step 146. If yes, the security function specified for the socket is executed. If the security evaluation is positive the socket is plugged in step 146.
  • step 148 it is determined if the plug is the last plug. If no, the next plug is selected for evaluation.
  • the security check is negative, it is determined if the plug is the last plug in step 147. If in steps 147 or 148 it is determined that the plug is the last one, the module is executed with the default behavior for all sockets which have not been plugged and for the plugged behavior for those which have been plugged. By this means a secure modification of behavior has been achieved. Modules that are loaded from an ICC 5 by LOADCARDMODULE token must be handled differently than those loaded from the repository in the terminal 1 using the EXECUTEMODULE token.
  • the flowchart for LOADCARDMODULE is shown in Fig. 12. Before execution of a card module, the VM 20 marks its state and saves any resources needed in step 150 so that this state can be restored later.
  • the state includes: • The position of the extensible memory pointer, the frame pointer, and the frame end pointer.
  • the module is loaded in step 152 using the Load Module routine described above with reference to Fig. 9; the difference being that the module is on the ICC 5 and is not in the repository and is not already loaded. If it is determined in step 154 that the card module did not load successfully, all resources are returned in step 155 to the state they had immediately before execution of the LOADCARDMODULE token. This requires:
  • step 158 it is determined in step 158 if the module is an executable module and if so is executed in step 160 as described with reference to steps 106 and 108 of Fig. 9.
  • EPICode tokens are the instruction set of a two stack virtual machine with an additional frame pointer.
  • the tokens may also be treated as an intermediate language of a compiler. Some implementations of the program translator may actually compile EPICode tokens to machine code.
  • EPICode tokens are byte tokens, permitting a maximum of 256 tokens.
  • One-byte prefix tokens allow the range of tokens to be extended to a theoretical maximum of 65536 tokens, regarding prefixes as defining pages of 256 tokens each. In fact, a limited range of prefix tokens is defined.
  • Each token value is shown in hexadecimal as a 2 -digit hexadecimal code, with its corresponding name.
  • Tokens without a prefix are referred to as primary tokens, whereas those with prefixes (two-byte tokens) are referred to as secondary tokens.
  • This section presents an alphabetic concordence list of Forth words used as EPICode tokens. Each line contains, from left to right ⁇
  • H Host (compiler) word which may or may not contribute tokens to the target.
  • Numbers larger than one byte are transmitted in token programs in "big-endian" 2 * s complement form, most sigmficant byte first Within an EPICode program, numbers should always be accessed by operators of the correct format, in order to allow programs to store numbers in the form most suited to the underlying architecture
  • Control structures are formed by a control token (BRA, RLOOP, etc ) followed by a signed four-byte, two- byte or single byte offset
  • the offset following the control token is added to the Token Pointer (TP) after the offset has been fetched
  • TP Token Pointer
  • the destination address is addr+2+offset for a l-byte offset (SBRA).
  • EBRA 4-byte offset
  • Tokens taking four-byte offsets are available only to terminal-specific code on virtual machine implementa ⁇ ons that support a 32-bit linear address space for code
  • tokens operate on quantities with a data size and a signed or unsigned interpretation determined by the token, but instructions which access memory in die frame store can take a data type override determined by a prefix token
  • a set of byte codes, shown m Table 1, is reserved for such prefix tokens, but only SBYTE and UBYTE are currently used
  • Data types that require less than one cell ( 1 byte) are fetched from memory by using a byte operator or an APPENDIX til
  • Tokens are split into several logical sets for the sake of convenience and are shown in separate sections below. All token values are in hexadecimal.
  • Data type prefixes applicable to the tokens are listed explicitly, using the abbreviations given in Table 1. Any primary token which is prefixed by a token not in its prefix list is invalid, and die execution of such a token causes an ILLOP exception to be thrown.
  • the default type for the token is italicised, and is always listed first.
  • the default data type prefix is redundant, and is invalid if used to prefix a token, as above.
  • 04 BFETCHS ( addr — num ) Fetch an 8-bit byte from the given address, sign extending it.
  • Possible data type overrides include SL, SB, UB 54 5F TFRFETCH12 . . . TFRFETCH1
  • Possible data type ovemdes include SL, SB. UB 60..63 PFRSTORE2 . . . PFRSTORE5
  • Possible data type overrides include SL, SB 64..6F TFRSTORE12 . . . TFRSTORE1
  • Possible data type ovemdes include SL. SB
  • the offset is provided by a two-byte in-line value. See die description of SFRFETCH for more details.
  • Possible data type overrides include: SL, SB, UB
  • the offset is provided by a one-byte in-line value which is multiplied by 4 to give a byte offset for the default data type, and used directly as a byte index for a byte-sized data override.
  • Possible data type overrides include. SL, SB
  • the offset is provided by a two-byte in-line value which is multiplied by 4 to give a byte offset for the default data type, and used directly as a byte index for a byte-sized data override.
  • the virtual machine is permitted to build frames on die return stack, so use of frames is constrained by the rules that apply to return stack usage m general Procedure parameters will be moved from the data stack mto the frame by SMAKEFRAME so that they can be accessed by FRFETCH and FRSTORE
  • extension tokens for data types occupy tokens CO to CF. Unused tokens in this range are reserved for future use when additional data type prefixes are required.
  • Dunng loading CLASSPROC marks the entry to class handling code Used for compilation assistance and may be implemented as a NOOP F9 SYSFUNC
  • a page expansion token treated as the first byte of a secondary token Calls the routine specified by die following m-lme byte
  • the supported secondary token set is defined in Section 1 7
  • the stack effect is defined by the specified routme
  • the first eight secondary socket tokens are reserved for socket management functions, and defined management functions are descnbed below Remaining sockets (D2 08 to D2 3F) are for application use F9 91 SETSOCKET
  • dus procedure (which is here referred to as PLUGCONTROL for purposes of illustration) must be (u — flag) where u is die socket number and flag is returned FALSE if die socket can be plugged, or TRUE if it cannot
  • the PLUGCONTROL procedure must raise an exception - 24 (invalid numenc argument) for values of u outside die range 0-63
  • a default action of PLUGCONTROL is installed by the Virtual Machine to return FALSE for all values of u. enabling all sockets to be plugged D2 03 OSCALLBACK
  • a socket for an EPICode routme which may be called by the underlying operatmg system
  • the four parameters are 32-bit values mtended for use as follows dev selects the requested I/O device for with num, 32-bit parameters contained m the array num 2 , returning tor whose meaning is implementation dependent num, and num 2 correspond to arvc and argv, respectively, in C usage
  • This set defines the functions available via the SYSFUNC token, which acts as a generalised mterface to underlying operatmg system routmes
  • Each device is assigned a unique device number Status tor codes are device dependent, except that an tor code of 0 always indicates success F9 00 DKEY
  • This function may suspend processing for the specified duration F9 04 DREAD
  • Tokens in this group provide a mechamsm for handlmg language and message selection and display
  • This function erases pnvate issuer messages, numbered from CO to FF (hex) and any messages installed by LOADMESSAGES This function should be called after each user session F9 24 LOADMESSAGES
  • TOO_MANY_LANGUAGES addr gives the location of the TLV containing the message table defimtion. mcludmg die page code to use for messages, the two-letter language code in accordance with ISO 639, and the messages to be installed
  • Tokens in dus group provide a mechamsm for handlmg Integrated Circuit Card readers F9 30 INITCARD
  • the buffer c-addr, len must contain
  • Optional data (length followed by length bytes, where length may be 0-255)
  • the buffer c-addr 2 len 2 must provide adequate space for the answer from the card plus two status bytes containing SW1 and SW2
  • Tokens in this group provide a mechanism for handling Magnetic Stripe devices
  • num is the ISO identifier of the magstripe track(s) to read 1
  • c-addr is the destination address for the string
  • len is its maximum length (at least 78 bytes for ISOl, 41 bytes for IS02 and 108 for IS03, or sums of these for reading multiple magstripes ).
  • len 2 gives the actual length of the string read.
  • Tokens in this group provide a mechanism for handling die modem device.
  • c-addr len is a string containing the phone number to call. ',' can be included for dial tone waiting. If die first character of this string is 'P ⁇ pulse dialling is used instead of default tone dialling.
  • F9 41 MODEMHANGUP
  • c-addr is the destination address for the string, and len, is its maximum length. On return. len 2 gives the actual length of die string read. If no characters are received for a specified period, a time-out occurs.
  • Tokens in this group provide a mechanism for handling the blacklist file.
  • This function inserts an entry at c-addr len in the list, which is maintained in sorted order.
  • the returned flag is FALSE if die insertion was successful (the entry was not found in die existing list and die list was not full).
  • This function attempts to find a key c-addr, len, in die list.
  • c-addr 2 len 2 contain the result of the search (including remaining bytes from the selected entry and possibly some other information bytes), if the key was found.
  • the returned flag is FALSE if die number was found.
  • This function deletes an entry from the list, where c-addr len is the key for the entry to delete. It can be up to 18 bytes long.
  • the returned flag is FALSE if die deletion was successful (the entry was found).
  • Tokens in this group provide support for initializing and using security services.
  • c-addr len num — flag c-addr is the address of initialization buffer, and len is its lengdi.
  • the input parameter(s) for each algoridim may differ, though a key should usually be passed to diis initialization flag is FALSE if initialization occurred successfully.
  • c-addr is the input data buffer for computation, and len its lengdi.
  • c-addr 2 is the output buffer for storage of the result. flag is FALSE if computation occurred successfully.
  • Len may be shorter dian die defined length of the key field for dus structure, with the remaining characters being compared to blank (ASCII 20h) characters. If the match is successful, the matching record becomes current and flag is FALSE.
  • This token may only be used wrth an Ordered database.
  • Len may be shorter than the defined length of the key field for this structure, with the remaining characters being compared to blank (ASCII 20h) characters. If the match is successful, the matching record becomes current and flag is TRUE. If the match is not successful, a new record is inserted at the correct position in die database and die flag is FALSE. This new record will be initialized except for its key field which will contain die given key.
  • Len may be shorter than die defined lengdi of die key field for this structure, widi the remaining characters being compared to blank (ASCII 20h) characters. If the match is successful, die matching record is deleted and flag is FALSE. The deletion action closes up any potential "hole" in a physical implementation by taking appropriate action to physically reposition or relink the records in a pre-initialized database. This token may only be used with an Ordered database.
  • the server causes the server to stack the current context information, including the current database, die current record number and any ancillary information.
  • the server is entrtled to use die Virtual Machine's return stack to save context information, and client software must therefore observe the general rules diat apply for return stack usage.
  • the tokens described in this section provide TLV management and access function.
  • len 2 is equal to len, less the number of spaces (ASCII 20 h ) at the end of the character string specified by c-addr len, . If len, is zero or the entire string consists of spaces, len 2 is zero.
  • len 1 is greater than zero.
  • len 2 is equal to len, less the number of nulls (ASCII Oh) at die end of the character string specified by c-addr len,. If len, is zero or the entire string consists of nulls, len 2 is zero.
  • Each Tag field encountered will place Length field bytes from its Value field mto its mtemal buffer and set its parsed status bit
  • a constructed Tag field When a constructed Tag field is encountered, all the mtemal TLV buffers that have been defined as bemg associated with it are cleared before die Value field is parsed for TLV sequences No exception will be generated if a TLV is encountered in a constructed template to which it has not been defined as bemg associated with
  • TLV rules based upon die data in its mtemal buffer Return the beginning of die destination stnng (c- addr) and the sum of die two lengths (len 2 ) There must be room at the end of the output stnng to hold bodi strings
  • Decode the status of die TLV access parameter fmt The returned num is die format indicator 0- and bits in die returned char have die following significance, where bit 0 is the least sigmficant bit
  • Fetch number u from a Bmary Coded Decimal sequence at c-addr for len bytes The number is formatted wrth each digit representing 4-bit nibbles m die mput stnng A DIGIT_TOO_LARGE exception is dirown if any mbble is not a valid BCD digit
  • Fetch number u as a Binary Number from the stnng at c-addr for len bytes The most significant byte of the number is fetched first If there are more than four bytes of data at that location, the most sigmficant bytes will be lost
  • Trailmg nibbles will be filled with F " s if needed The number will be truncated if len 2 is not long enough to hold all the characters (len 2 ⁇ [len, + 1 ]/2)
  • a DIGIT_TOO_LARGE throw code will be generated if a character in the mput stnng is not a number
  • CANNOT_ADD_TO_MODULE is dirown if the module buffer has not been prepared, or if the module buffer capacity is exceeded.
  • the resources associated with managing die module buffer are automatically released
  • a-addr is the address of the header of an EPICode module delivered from the card mto mtemal storage
  • the exception BAD_CARD_MODULE is thrown if the module violates any precondition for card module loading
  • Bits 0 dirough 7 define which module classes have been registered in die module ⁇ rectory smce the last execution of dus token. For example, a module registered wrth an initial AID byte which is F4 will set bit 4 m the return status Bits 8 through 31 are reserved for future expansion.
  • the following tokens provide access to an extensible "rubber band" buffer of lmear memory m die data space provided and managed by the virtual machine.
  • Secu ⁇ ty algo ⁇ thm processmg may occupy several seconds on some terminals
  • the present mvention mcludes that die present smgle SECALGO command be factored mto initiation and completion components to facilitate use wrth multitasking implementations This is under mvestigation, and the following proposals are made as an alternative to SECALGO F9 56 SECALGOBEGIN

Landscapes

  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Programmable Controllers (AREA)
  • Input From Keyboards Or The Like (AREA)

Abstract

La présente invention porte sur un système de gestion transactionnel permettant d'exécuter des transactions entre une première unité (1) et une deuxième unité, lesdites première unité et deuxième unité étant conçues pour communiquer l'une avec l'autre. Au moins l'une desdites unités est une carte à circuit intégré et un système comprenant: au minimum un dispositif d'entrée/sortie (25), une machine virtuelle portable (20) pouvant interpréter un programme d'ordinateur sur ladite première unité, ladite machine virtuelle portable incluant un microprocesseur virtuel et un gestionnaire de périphériques pour ledit ou lesdits dispositif(s) d'entrée/sortie (25), et un moyen d'exécution répondant audit programme interprété pour exécuter ledit programme. Le concept technique général de liaison selon la présente invention est de combiner, dans un système de gestion transactionnelle, la portabilité, la sécurité des données et des garanties d'exécution, qui sont indépendantes de la mise en oeuvre visée pour autant que les vérifications concernant la durée de compilation soient menées à bien. Ledit concept est réalisé au moyen d'une machine virtuelle utilisée comme interpréteur comprenant un gestionnaire de périphéries pour les dispositifs d'entrée/sortie de la machine virtuelle (pour que les programmes d'application partagent la même interface avec les dispositifs d'entrée/sortie et deviennent ainsi portables dans des environnements très différents). Le concept est aussi réalisé par attribution ou libération de mémoire et par indication de la quantité de mémoire disponible pour le programme d'application (pour signifier que le programme tournera juste de manière satisfaisante ou qu'il ne fonctionnera pas du tout ou que les fonctions de gestion de la sécurité sont réduites au minimum pour améliorer la vitesse d'exécution). Le concept est en outre réalisé par la mise en place d'un moyen sûr permettant d'importer ou d'exporter des données à partir de ou vers les programmes d'application ou bases de données.
PCT/EP1997/003355 1996-06-27 1997-06-26 Systeme portable sûr de gestion transactionnelle destine a des unites programmables intelligentes WO1997050063A2 (fr)

Priority Applications (15)

Application Number Priority Date Filing Date Title
HU0001822A HUP0001822A3 (en) 1996-06-27 1997-06-26 Portable, secure transaction system for programmable, intelligent devices
BR9710009-9A BR9710009A (pt) 1996-06-27 1997-06-26 Sistema de transação segura portátil para dispositivo inteligentes programáveis
EA199900060A EA001598B1 (ru) 1996-06-27 1997-06-26 Переносимая защищенная система осуществления транзакций для программируемых устройств с микропроцессорами
AU32630/97A AU716558B2 (en) 1996-06-27 1997-06-26 Portable, secure transaction system for programmable, intelligent devices
EP97928273A EP0907936A2 (fr) 1996-06-27 1997-06-26 Systeme portable sur de gestion transactionnelle destine a des unites programmables intelligentes
CA002257641A CA2257641A1 (fr) 1996-06-27 1997-06-26 Systeme portable sur de gestion transactionnelle destine a des unites programmables intelligentes
SI9720049A SI9720049A (sl) 1996-06-27 1997-06-26 Prenosen, varen transakcijski sistem za programabilne inteligentne priprave
JP10502361A JP2000514215A (ja) 1996-06-27 1997-06-26 プログラム可能でインテリジェントなデバイスのための、移植可能な安全なトランザクションシステム
SK1766-98A SK176698A3 (en) 1996-06-27 1997-06-26 Portable, secure transaction system for programmable, intelligent devices
TW086109069A TW355776B (en) 1996-06-27 1997-06-26 Portable, secure transaction system for programmable terminals and ICC's this invention relates to a portable, secure transaction system for programmable terminals and integrated circuit card
IL12753397A IL127533A0 (en) 1996-06-27 1997-06-26 Portable secure transaction system for programmable intelligent devices
PL97330930A PL330930A1 (en) 1996-06-27 1997-06-26 Portable tamper-safe transaction system for programmable, intelligent equipment
NZ333384A NZ333384A (en) 1996-06-27 1997-06-26 Electronic transaction implementation using portable virtual machine interpreters
NO985803A NO985803L (no) 1996-06-27 1998-12-11 Bµrbart, sikkert transaksjonssystem for programmerbare, intelligente utstyrsenheter
IS4925A IS4925A (is) 1996-06-27 1998-12-15 Flytjanlegt, öruggt aðgerðakerfi fyrir forritanlegan búnað

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GBGB9613450.7A GB9613450D0 (en) 1996-06-27 1996-06-27 Payment system
GB9613450.7 1996-06-27

Publications (2)

Publication Number Publication Date
WO1997050063A2 true WO1997050063A2 (fr) 1997-12-31
WO1997050063A3 WO1997050063A3 (fr) 1998-03-26

Family

ID=10795955

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP1997/003355 WO1997050063A2 (fr) 1996-06-27 1997-06-26 Systeme portable sûr de gestion transactionnelle destine a des unites programmables intelligentes

Country Status (22)

Country Link
EP (1) EP0907936A2 (fr)
JP (1) JP2000514215A (fr)
AU (1) AU716558B2 (fr)
BR (1) BR9710009A (fr)
CA (1) CA2257641A1 (fr)
CZ (1) CZ423598A3 (fr)
EA (1) EA001598B1 (fr)
GB (1) GB9613450D0 (fr)
HR (1) HRP970354A2 (fr)
HU (1) HUP0001822A3 (fr)
IL (1) IL127533A0 (fr)
IS (1) IS4925A (fr)
NO (1) NO985803L (fr)
NZ (1) NZ333384A (fr)
PL (1) PL330930A1 (fr)
SI (1) SI9720049A (fr)
SK (1) SK176698A3 (fr)
TR (1) TR199802675T2 (fr)
TW (1) TW355776B (fr)
WO (1) WO1997050063A2 (fr)
YU (1) YU60798A (fr)
ZA (1) ZA975748B (fr)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1100059A1 (fr) * 1999-11-10 2001-05-16 Mars Incorporated Systèmes de transfert de valeurs
EP1113407A3 (fr) * 1999-12-27 2001-09-26 Hitachi, Ltd. Carte à puce et méthode pour charger celle-ci avec des programmes et des scripts d'application
JP2001283160A (ja) * 2000-03-30 2001-10-12 Dainippon Printing Co Ltd Ｉｃカードおよびｉｃカードの更新装置とその方法
FR2809852A1 (fr) * 2000-05-30 2001-12-07 Dassault Automatismes Terminal de paiement comprenant une carte memoire non volatile extractible
GB2337434B (en) * 1997-03-14 2002-01-30 Ian Charles Ogilvy Method and apparatus for controlling communications
WO2002047020A2 (fr) * 2000-12-06 2002-06-13 Mobile-Mind, Inc. Communication concommitante avec de multiple application sur une carte a puce
US6424950B1 (en) * 1999-05-10 2002-07-23 Xerox Corporation Remote feature delivery for output devices
JP2002538531A (ja) * 1999-02-22 2002-11-12 チップ アプリケーション テクノロジーズ リミテッド 販売時点情報管理及びインターネットマルチアプリケーション統合システム及びその使用方法
WO2003058446A1 (fr) * 2002-01-11 2003-07-17 Sierra Wireless, Inc. Interface d'application radio extensible a l'hote
AT501651A1 (de) * 2000-09-27 2006-10-15 Omnikey Gmbh Elektronisches modul mit einem steckverbinder zu einer übergeordneten recheneinheit
US8065695B1 (en) 2008-06-30 2011-11-22 United Services Automobile Association Systems and methods for increased security during logging in to web site
US8726247B2 (en) 1996-10-25 2014-05-13 Gemalto Sa Computer program product containing instructions for providing a processor the capability of executing an application derived from a compiled form
RU2544798C1 (ru) * 2013-01-15 2015-03-20 Хун-Чиэнь ЧОУ Переносное электронное устройство с модулем карты памяти, предназначенное для осуществления электронных транзакций
CN111133434A (zh) * 2017-07-27 2020-05-08 西门子股份公司 用于受密码保护地运行虚拟机的设备和方法
US11388576B2 (en) 2019-12-16 2022-07-12 Huawei Technologies Co., Ltd. Emergency call method and apparatus, and system

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5036461A (en) * 1990-05-16 1991-07-30 Elliott John C Two-way authentication system between user's smart card and issuer-specific plug-in application modules in multi-issued transaction device
US5067072A (en) * 1987-11-06 1991-11-19 Visystems, Inc. Virtual software machine which preprocesses application program to isolate execution dependencies and uses target computer processes to implement the execution dependencies
FR2667171A1 (fr) * 1990-09-25 1992-03-27 Gemplus Card Int Support portable a micro-circuit facilement programmable et procede de programmation de ce micro-circuit.
EP0510616A2 (fr) * 1991-04-23 1992-10-28 Hitachi, Ltd. Système de traitement d'information réorientable
WO1994010657A1 (fr) * 1992-10-26 1994-05-11 Intellect Australia Pty. Ltd. Systeme de transaction hote - utilisateur
US5434999A (en) * 1988-11-09 1995-07-18 Bull Cp8 Safeguarded remote loading of service programs by authorizing loading in protected memory zones in a terminal

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5067072A (en) * 1987-11-06 1991-11-19 Visystems, Inc. Virtual software machine which preprocesses application program to isolate execution dependencies and uses target computer processes to implement the execution dependencies
US5434999A (en) * 1988-11-09 1995-07-18 Bull Cp8 Safeguarded remote loading of service programs by authorizing loading in protected memory zones in a terminal
US5036461A (en) * 1990-05-16 1991-07-30 Elliott John C Two-way authentication system between user's smart card and issuer-specific plug-in application modules in multi-issued transaction device
FR2667171A1 (fr) * 1990-09-25 1992-03-27 Gemplus Card Int Support portable a micro-circuit facilement programmable et procede de programmation de ce micro-circuit.
EP0510616A2 (fr) * 1991-04-23 1992-10-28 Hitachi, Ltd. Système de traitement d'information réorientable
WO1994010657A1 (fr) * 1992-10-26 1994-05-11 Intellect Australia Pty. Ltd. Systeme de transaction hote - utilisateur

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8726247B2 (en) 1996-10-25 2014-05-13 Gemalto Sa Computer program product containing instructions for providing a processor the capability of executing an application derived from a compiled form
US9400668B2 (en) 1996-10-25 2016-07-26 Gemalto Sa Computer program product containing instructions for providing a processor the capability of executing an application derived from a compiled form
US8881119B2 (en) 1996-10-25 2014-11-04 Gemalto Sa Computer program product containing instructions for providing a processor the capability of executing an application derived from a compiled form
US8881118B2 (en) 1996-10-25 2014-11-04 Gemalto Sa Computer program product containing instructions for providing a processor the capability of executing an application derived from a compiled form
GB2337434B (en) * 1997-03-14 2002-01-30 Ian Charles Ogilvy Method and apparatus for controlling communications
JP2002538531A (ja) * 1999-02-22 2002-11-12 チップ アプリケーション テクノロジーズ リミテッド 販売時点情報管理及びインターネットマルチアプリケーション統合システム及びその使用方法
US8671059B2 (en) 1999-05-10 2014-03-11 Google Inc. Remote feature delivery for output devices
US8909554B2 (en) 1999-05-10 2014-12-09 Google Inc. System for installing programmable features on output devices
US6424950B1 (en) * 1999-05-10 2002-07-23 Xerox Corporation Remote feature delivery for output devices
EP1100059A1 (fr) * 1999-11-10 2001-05-16 Mars Incorporated Systèmes de transfert de valeurs
US8027920B1 (en) 1999-11-10 2011-09-27 Mei, Inc. Value transaction systems
EP1113407A3 (fr) * 1999-12-27 2001-09-26 Hitachi, Ltd. Carte à puce et méthode pour charger celle-ci avec des programmes et des scripts d'application
JP2001283160A (ja) * 2000-03-30 2001-10-12 Dainippon Printing Co Ltd Ｉｃカードおよびｉｃカードの更新装置とその方法
FR2809852A1 (fr) * 2000-05-30 2001-12-07 Dassault Automatismes Terminal de paiement comprenant une carte memoire non volatile extractible
AT501651A1 (de) * 2000-09-27 2006-10-15 Omnikey Gmbh Elektronisches modul mit einem steckverbinder zu einer übergeordneten recheneinheit
AT501651B1 (de) * 2000-09-27 2007-02-15 Omnikey Gmbh Elektronisches modul mit einem steckverbinder zu einer übergeordneten recheneinheit
US6824064B2 (en) 2000-12-06 2004-11-30 Mobile-Mind, Inc. Concurrent communication with multiple applications on a smart card
WO2002047020A2 (fr) * 2000-12-06 2002-06-13 Mobile-Mind, Inc. Communication concommitante avec de multiple application sur une carte a puce
WO2002047020A3 (fr) * 2000-12-06 2003-09-04 Mobile Mind Inc Communication concommitante avec de multiple application sur une carte a puce
WO2003058446A1 (fr) * 2002-01-11 2003-07-17 Sierra Wireless, Inc. Interface d'application radio extensible a l'hote
US8065695B1 (en) 2008-06-30 2011-11-22 United Services Automobile Association Systems and methods for increased security during logging in to web site
US8832803B1 (en) 2008-06-30 2014-09-09 United Services Automobile Association (Usaa) Systems and methods for increased security during logging in to web site
US8359639B1 (en) 2008-06-30 2013-01-22 United States Automobile Association (USAA) Systems and methods for increased security during logging in to web site
US8074263B1 (en) 2008-06-30 2011-12-06 United Services Automobile Association Systems and methods for increased security during logging in to web site
RU2544798C1 (ru) * 2013-01-15 2015-03-20 Хун-Чиэнь ЧОУ Переносное электронное устройство с модулем карты памяти, предназначенное для осуществления электронных транзакций
CN111133434A (zh) * 2017-07-27 2020-05-08 西门子股份公司 用于受密码保护地运行虚拟机的设备和方法
CN111133434B (zh) * 2017-07-27 2023-11-21 西门子股份公司 用于受密码保护地运行虚拟机的设备和方法
US11388576B2 (en) 2019-12-16 2022-07-12 Huawei Technologies Co., Ltd. Emergency call method and apparatus, and system

Also Published As

Publication number Publication date
CA2257641A1 (fr) 1997-12-31
IS4925A (is) 1998-12-15
IL127533A0 (en) 1999-10-28
HUP0001822A3 (en) 2002-01-28
NO985803L (no) 1999-02-24
CZ423598A3 (cs) 1999-10-13
JP2000514215A (ja) 2000-10-24
ZA975748B (en) 1998-07-27
EA199900060A1 (ru) 1999-08-26
TW355776B (en) 1999-04-11
HUP0001822A2 (hu) 2000-09-28
AU716558B2 (en) 2000-03-02
BR9710009A (pt) 2000-01-18
GB9613450D0 (en) 1996-08-28
EA001598B1 (ru) 2001-06-25
NO985803D0 (no) 1998-12-11
WO1997050063A3 (fr) 1998-03-26
HRP970354A2 (en) 1998-04-30
NZ333384A (en) 2001-01-26
YU60798A (sh) 1999-09-27
TR199802675T2 (xx) 1999-04-21
EP0907936A2 (fr) 1999-04-14
SI9720049A (sl) 1999-12-31
SK176698A3 (en) 2000-08-14
PL330930A1 (en) 1999-06-07
AU3263097A (en) 1998-01-14

Similar Documents

Publication Publication Date Title
US6880155B2 (en) Token-based linking
Chen Java card technology for smart cards: architecture and programmer's guide
US9400668B2 (en) Computer program product containing instructions for providing a processor the capability of executing an application derived from a compiled form
US6986132B1 (en) Remote incremental program binary compatibility verification using API definitions
US6651186B1 (en) Remote incremental program verification using API definitions
US6883163B1 (en) Populating resource-constrained devices with content verified using API definitions
KR100713740B1 (ko) 자원-제약 장치를 위한 객체지향 명령어 세트
AU716558B2 (en) Portable, secure transaction system for programmable, intelligent devices
US6981245B1 (en) Populating binary compatible resource-constrained devices with content verified using API definitions
Faraj et al. Investigation of Java Smart Card Technology for Multi-Task Applications
JP4378459B2 (ja) 特にスマートカードにおけるダウンロードしたアプリケーションの機密保護化
CA2422634A1 (fr) Peuplement de dispositifs a ressources limitees a compatibilite binaire avec contenu verifie par definitions api
MXPA99000076A (en) Portable system of safe transaction for intelligent devices and programab
AU2001290842B2 (en) Remote incremental program binary compatibility verification using API definitions
AU2001289078B2 (en) Method for remote incremental program verification and installation on resource-constrained devices
AU2001290892B2 (en) Method for remote incremental program verification and installation on resource-constrained devices
Markantonakis et al. Implementing a Secure Log File Download Manager for the Java Card
EP1417573A2 (fr) Peuplement de dispositifs a ressources limitees a compatibilite binaire avec contenu verifie par definitions api
AU2001289078A1 (en) Method for remote incremental program verification and installation on resource-constrained devices
AU2001290842A1 (en) Remote incremental program binary compatibility verification using API definitions
AU2001290892A1 (en) Method for remote incremental program verification and installation on resource-constrained devices

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 97195913.7

Country of ref document: CN

AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH HU IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG US UZ VN YU ZW AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH KE LS MW SD SZ UG ZW AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
ENP Entry into the national phase

Ref document number: 2257641

Country of ref document: CA

Ref document number: 2257641

Country of ref document: CA

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 333384

Country of ref document: NZ

WWE Wipo information: entry into national phase

Ref document number: 1997928273

Country of ref document: EP

Ref document number: PV1998-4235

Country of ref document: CZ

WWE Wipo information: entry into national phase

Ref document number: 176698

Country of ref document: SK

WWE Wipo information: entry into national phase

Ref document number: 1998/02675

Country of ref document: TR

WWE Wipo information: entry into national phase

Ref document number: P-607/98

Country of ref document: YU

WWE Wipo information: entry into national phase

Ref document number: PA/a/1999/000076

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 199900060

Country of ref document: EA

WWP Wipo information: published in national office

Ref document number: 1997928273

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: PV1998-4235

Country of ref document: CZ

WWE Wipo information: entry into national phase

Ref document number: PV2001-994

Country of ref document: CZ

WWR Wipo information: refused in national office

Ref document number: PV1998-4235

Country of ref document: CZ

WWR Wipo information: refused in national office

Ref document number: 1997928273

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1997928273

Country of ref document: EP

WWR Wipo information: refused in national office

Ref document number: PV2001-994

Country of ref document: CZ