Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.


  1. Advanced Patent Search
Publication numberUS20060015646 A1
Publication typeApplication
Application numberUS 11/207,771
Publication dateJan 19, 2006
Filing dateAug 22, 2005
Priority dateMar 14, 1997
Also published asUS6934945, US7302683, WO1998041918A1
Publication number11207771, 207771, US 2006/0015646 A1, US 2006/015646 A1, US 20060015646 A1, US 20060015646A1, US 2006015646 A1, US 2006015646A1, US-A1-20060015646, US-A1-2006015646, US2006/0015646A1, US2006/015646A1, US20060015646 A1, US20060015646A1, US2006015646 A1, US2006015646A1
InventorsIan Ogilvy
Original AssigneeOgilvy Ian C
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Method and apparatus for controlling communications
US 20060015646 A1
The present invention relates generally to a method and apparatus for preparing and processing information to be sent or received via a network, or communicated to or from other data carriers such as smart cards. The present invention describes the construction of a novel “virtual machine” which can be implemented on a device having a minimal amount of hardware, such as hardware which is P used for processing payment transactions (EFTPOS and the like). Prior art DATA/virtual machines tend to slow down operation of the device, as they are effectively acting as an interface between an applications program and the actual device drivers. This is a problem. The virtual machine of the device of the present invention incorporates a virtual message processing means, which is arranged to construct, deconstruct and compare messages and which is applied in the native code of the processor. The message instruction means are provided in the application to direct and control the message processor. Similarly, a protocol processor means is provided in the virtual machine for governing and organising communications, under the direction of a protocol instruction means in the application. The provision of these elements increases the speed and efficiency of the virtual machine and allows implementation of a practical device for use in communications, able to be implemented on different hardware having different BIOS/OS.
Previous page
Next page
1. A communications device which is arranged to process messages for communications, comprising a virtual machine means which includes:
a virtual function processor and function processor instructions for controlling operation of the device, and
message instruction means including a set of descriptions of message data;
a virtual message processor, which is arranged to be called by the function processor and which is arranged to carry out the message handling tasks of assembling the messages, disassembling messages and comparing the messages under the direction of the message instruction means that is arranged to provide directions for operation of the virtual message processor, whereby when a message is required to be handled by the communications device the message processor is called to carry out the message handling task,
wherein the virtual machine means is emulatable in different computers having incompatible hardwares or operating systems.
2. (canceled)
3. (canceled)
4. (canceled)
5. (canceled)
6. (canceled)
7. (canceled)
8. (canceled)
9. (canceled)
10. (canceled)
11. (canceled)
12. (canceled)
13. (canceled)
14. (canceled)
15. (canceled)
16. (canceled)
17. (canceled)
18. (canceled)
19. (canceled)
20. (canceled)
21. (canceled)
22. (canceled)
23. (canceled)
24. (canceled)
25. (canceled)
26. A device in accordance with claim 1, wherein said device is a payment terminal device and wherein said virtual message processor is used to communicate with peripheral units associated with said device.
27. A device in accordance with claim 1, wherein said device is a payment terminal device and wherein said virtual message processor is used to communicate with an application associated with said device.
28. A device in accordance with claim 1, wherein said wherein said virtual message processor is used to communicate means associated with the device for implementing cryptographic services.
29. A device in accordance with claim 1, wherein said device is a personal mobile device.
30. A device in accordance with claim 27, wherein said virtual message processor implements secure communication services.
  • [0001]
    From a first, general aspect, the present invention relates to a method and apparatus for preparing and processing information to be sent or received via a network. A network in this instance may be implemented as data carried either over communications lines and/or stored on smart cards (or other data carriers) and physically transported.
  • [0002]
    From a second, more specific aspect, the present invention relates to a method and apparatus for controlling remote payment transactions, particularly, but not exclusively, for controlling remote payment transactions where a persons account is credited and/or debited from a remote location in exchange for goods/services cash or credit, or where account information is accessed remotely to enable approval of a transaction.
  • [0003]
    Devices for carrying out remote payment transactions are well-known. These “payment terminals” include EFTPOS, credit card payment terminals, etc.
  • [0004]
    The most common function of payment terminals is to remotely access a persons account information and either carry out a transaction, such as crediting or debiting the account, or, particularly in the case of credit card payment terminals, to check the users account to ensure that there are sufficient funds to cover a transaction. Note that although credit card terminals do not necessa-rily remotely credit or debit the users account (the credit/debit transaction usually being carried out by a separate paper bill trail) and merely provide the information that the users account is sufficient to cover the transaction, such payment terminals still fall within the ambit of the present invention and the term “transaction” as used herein includes the operation of remotely checking the users account to “ok” a transaction.
  • [0005]
    A payment terminal may, for example, provide for the following basic operations:
  • [0006]
    (1) Input of information which is required to enable access to a customers account. The information is most often read from a magnetic stripe on a credit card or bank card or the like, or a smart card. In addition to reading details from a card a personal identification number (PIN) or the like code may also be required.
  • [0007]
    (2) Obtain access to the customers account. This is usually done by remote communication with a processing device holding the person's account data, usually on bank premises and remote from the payment terminal. Usually, information on the customers account input to the payment terminal will need to be transmitted for verifica-tion and to enable access to the account. Also a money amount will usually need to be input to the payment terminal and transmitted over the communications line. At least some and perhaps all of the transmitted data may be encrypted for security purposes and the payment termi-nal is therefore, in such a case, required to have means (3) providing encryption.
  • [0008]
    (4) The payment terminal may need to be able to receive communications over the remote line from the processor accessing the customers account, ie. to provide an “answer” to the payment device regarding the user transaction. The answer may include information that an account debit/credit has taken place (eg. EFTPOS) or merely an approval that the customer has enough money in his account to enable a transaction (some credit card payment terminals). Again, this transmitted information may be encrypted and, if so, will require translation (5) in the payment terminal.
  • [0009]
    (6) To provide an indication that the transaction request is approved or that a transaction has occurred, by display or printer, for example. Displays may also be required to prompt an operator or customer to input information, e.g., input your PIN “Input Amount”.
  • [0010]
    There are many different brands of payment terminal, utilising many different software and hardware arrangements. This gives rise to a number of problems.
  • [0011]
    Any account acquirer (eg. bank) will generally have their own operating requirements as to how remote payment trans-actions will be handled. The account acquirer may purchase a series of payment terminals which have been configured by a manufacturer to the acquirer's requirements. These payment terminals will then be licensed or rented or more often supplied at no charge to merchants (e.g., retail stores, garages, restaurants). Multiple account acquirers may require access to their customers accounts via a single payment terminal. That is, one particular merchant may operate payment terminals which provide access to customers accounts at other account acquirers (e.g., other banks). Because of different requirements of different acquirers for handling of remote payment transac-tions, the payment terminal must be arranged to operate to satisfy the different require-ments.
  • [0012]
    The terminal owner (often a principle acquirer) will have the terminal appropriate-ly arranged and programmed by the terminal manufacturer to satisfy the re-quirements of all account acquirers utilising the termi-nal. Payment terminals may need to contain several programs and select the appropriate program depending on the card to be processed or on an operator selection.
  • [0013]
    It is often the case that the terminal owner may need to have the operation of the payment device amended to, for example, enable it to operate for an additional account acquirer, or to satisfy changed requirements for a particular account acquirer. Because of the different hardware/software architectures available, any operational alterations generally the require the input of the terminal supplier or manufacturer. The supplier/manufacturer will be required to reprogram the termi-nal or amend the hardware in order to carry out the alterations and they will usually be the only person who has the appropriate knowledge. The terminal owner is thus tied to the particular supplier/manufactur-er of the par-ticu-lar brand of payment terminal.
  • [0014]
    It is often the case that, the terminal owner may over time obtain different brands from different manufacturers and for operational alterations may need to return the particular brand to each separate manufacturer. Over time, manufacturers may go out of business, in which case the payment terminals made by that particular manufacturer may be unsupported and any alteration may be difficult to achieve, or at least will require the input of a skilled person having detailed knowledge of the programming and/or hardware of the redun-dant manufacturer's devices.
  • [0015]
    Being tied to a particular manufacturer for a particular brand therefore causes cost, time and trouble when any operational alterations are required. There is therefore a reluctance to carry out operational alterations, which sometimes means that requirements of vari-ous account acquirers are not fully satisfied. When an oper-ational alteration does have to be carried out, it is costly. If a manufacturer goes out of business, the terminal owner may be left with nobody to alter the operation of his payment terminals, or indeed maintain the payment terminals. The present system is costly and inflexible.
  • [0016]
    A payment terminal device usually includes a microprocessor and a number of peripheral units (e.g., card reader, display, printer, communications interface, _etc) controlled by the processor. A payment terminal device usually comprises hardware, an operating system or a BIOS and is ready to accept an application for that arrangement. Or the device may be supplied with an interpreter to accept the applica-tions.
  • [0017]
    To alter the operation of payment terminals, a new appli-cation must be created. This can be time consuming, costly and as the programming will be different for different types of devices, which may have different hardware arrangements as well, and must be carried out separately for each different type of device (i.e., different reprogramming operations must be carried out for different devices even where the same operational alterations may be required).
  • [0018]
    The programming alterations are not “portable” between different types of devices.
  • [0019]
    The most time critical aspects of operation of a remote payment terminal involve the building up and break-ing down of “messages” and the formulation and operation of communications. By “messages” is meant, for example, information data which is required to be input to the device or communicated or displayed in order to enable carrying out of a remote payment transaction, and includes information to be communicated to the bank, e.g., customers card number, customers PIN, amount of transaction, etc; displayed information such as “Please Input Amount”; information to be read from a customers magnetic stripe card or smart card and manipulated by the device e.g., card number, expiry date, etc. The operation of payment termi-nals is greatly concerned with the collection, rearrangement and communication of this message data to enable a remote payment transaction.
  • [0020]
    In conventional devices, each time a message is constructed or deconstructed, the operation of the machine will be handled by the application program. To change operation of the machine, the application must be changed. This is laborious, and gives rise to problems, as discussed above.
  • [0021]
    The technique of creating a _virtual processor_ (or in this case microprocessor) is well known and referred to as an interpreter. This allows programs to operate independent of processor. With the newer technique of also creating virtual peripherals then the whole is referred to as a “virtual machine”.
  • [0022]
    A _virtual machine_ is computer programmed to emulate a hypothetical computer. Different incompatible computers may be programmed to emulate the same hypotheti-cal computer. Any computer programmed to emulate the hypotheti-cal computer will thus be capable of executing programs for the virtual computer. This creates a complete portable environment for program operations.
  • [0023]
    A problem with virtual machines is emulation is slower than normal program execution. For some applications this performance penalty is a significant problem.
  • [0024]
    The above problems and disadvantages which have been discussed specifically in relation to devices configured to process payment transactions also would apply to devices configured to prepare and process any information to be sent or received via a network, not restricted to payment transaction information.
  • [0025]
    From a first aspect the present invention pro-vides a device arranged to process messages for communications, comprising a virtual machine means including a message processor means which is ar-ranged to process messages communicated to and/or to be communicated from the device, and message processor instruction means, arranged to provide directions for operation of the message processor means.
  • [0026]
    “Communicated” includes transport of data via a data carrier such as a smart card.
  • [0027]
    The message processor means is preferably a program mod-ule the specif-ic function of which is to assem-ble, disassemble and com-pare mes-sages. By mes-sages we mean a se-quence of data comprising usually a plu-rality of information fields to be com-muni-cated.
  • [0028]
    The message processor means is preferably translated into the native code of the microprocessor in each hard-ware device on which the virtual machine is to be implemented. The message processor instructions are preferably virtual instructions to be expressed only in the language defined by the message processor means- and thus never requiring trans-lation to any real hardware processor.
  • [0029]
    The message pro-cessor means in at least a pre-ferred embodiment provides two specif-ic advan-tages over con-ven-tional arrange-ments
      • 1) Faster Operation. The processor (executing as native code) operates at full micropro-cessor speed overcoming the problem of slow emulation speed for message related func-tions.
      • 2) Faster, simpler programming. The instructions for the message processor preferably consist of actual message “descrip-tions”. The programmer need only describe the message content, all data conversion, manipulation and processing is automati-cally performed based on the mes-sage descrip-tion. This is a more intuitive and-compart-mentalised approach which preferably leads to faster programming with less errors.
  • [0032]
    The virtual machine preferably also includes a protocol processor means particularly arranged to organ-ise communications to and from the device, and also pre-ferably include protocol processor instructions which are arranged to provide directions for operation of the protocol processor means.
  • [0033]
    The protocol processor means is preferably a program mod-ule the spe-cific function of which is to control and select the se-quence of message processor oper-ations in relation to mes-sages received and trans-mit-ted.
  • [0034]
    The protocol processor means is preferably translat-ed into the native code of the micro-pro-ces-sor in each hard-ware device on which the virtual machine is to be implemented. The protocol proces-sor in-structions are virtual instructions ex-pressed only in the language defined by the protocol processor means- and thus never requiring trans-lation to any real hardware pro-cessor. The protocol processor means provides two specific advantages over conven-tional arrangements:
      • 1) Faster Operation. The processor (executing as native code) preferably operates at full micropro-cessor speed overcoming the problem of slow emulation speed for proto-col related functions.
      • 2) Faster, simpler programming. The instructions for the protocol engine preferably consist of an actual diagram of the message flow. To change message flow or sequence, the programmer can modify an intuitive diagram, all multi-processing and other complica-tions are handled auto-matically. This more intuitive and compartmentalised approach leads to faster programming with less errors.
  • [0037]
    In a preferred embodiment, therefore, a device in accordance with the present invention includes a virtual machine including virtual processors which are specifically arranged to control message construction, deconstruction, comparison and to control the communica-tion of information, both for reception from a network and transmission to a network. These operations can therefore be carried out at speed, overcoming the prob-lems with known virtual machines and interpreters, which tend to operate slower than conventionally programmed devices. The virtual machine therefore lends itself particularly to applications relating to communications, such as payment terminal devices and other devices in which message pro-cessing and communication comprise a significant proportion of the operation of the device. In payment terminals, for example, a payment terminal including a virtual machine having the message proces-sor means and protocol processor means can operate satisfactorily speedwise. The virtual machine can be implemented on any hardware, BIOS/OS arrangement and therefore fa-cilitates portability of programs.
  • [0038]
    Implementation of such a virtual machine on pay-ment terminal devices of different brands enables operation of the payment terminal devices or brands to be altered merely by altering application commands generic to all brands. Each brand is seen by the appli-cation as the same virtual machine.
  • [0039]
    The virtual machine preferably also includes a function processor means arranged to control overall vir-tual machine action in response to operator or other external events, and also preferably includes function processor instruc-tions which are arranged to provide directions for operation of the function processor means.
  • [0040]
    The function processor means is preferably a program mod-ule the spe-cific function of which is to control and select general op-er-ations of the device not specially con-trolled by the mes-sage and proto-col pro-cessor means.
  • [0041]
    The function processor means is preferably translat-ed into the native code of the micro-pro-ces-sor in each hard-ware device on which the vir-tual machine is to be implemented. The function proces-sor in-structions are preferably virtual instruc-tions to be expressed only in the language defined by the function processor means- and thus never re-quiring trans-lation to any real hard-ware pro-cessor.
  • [0042]
    In the preferred embodiment, the “applica-tion” will there-fore com-prise in-structions for the mes-sage, proto-col and func-tion pro-ces-sor means. The instruc-tions for the func-tion processor means may include such pri-or art modules as a function event schedular and func-tion selector.
  • [0043]
    Although the present invention is particularly applicable to application in payment terminals, it is not limited to such applications. The invention can be applied in any device where advantages are likely to be achieved for the arrangement and control of communica-tions.
  • [0044]
    With the advent of the Internet and other extensive communications networks, it is believed that the operation of computers, such as PC's, will become more and more oriented towards acting as “servers” and/or “brows-ers”. In other words, a major function of PC's connected to a network will be to operate either as a server, provid-ing information and/or programs to the network for access by other parties, or as a “browser” for obtaining information/programs available on the network and operating on them. It is likely, in fact, that PC's will be asked to operate as both a server and a browser. This operation will not merely be restricted to the Internet, but for any network, even Local Area Net-works.
  • [0045]
    The applicant also believes that many other classes of devices may be connected to a network. For example in the future a home video cassette recording machine could be connected to the Internet (along with other devices) allowing remote programming from a browser device. An example of the use of this would be a worker upon learning of a requirement to stay at the office late and miss a favourite show could access their home VCR from the office and pro-gram it.
  • [0046]
    Telephone calls will eventually be digital and most likely use the Internet as the digital network. Like the VCR, this does not mean all phones would need a qwerty keyboard and colour-display. They will both represent other classes of Internet connected devices- not requir-ing the exact same configuration as PC's.
  • [0047]
    The present invention facilitates the production of a small, economical device which is particularly ar-ranged to deal with communications, to build, compare and deconstruct message information. Such a device is novel maybe termed a Specialised Network Access Computer (SNAC). The appli-cants believe that a SNAC could emerge as a class of device allowing data entry and control through the Internet where a smaller, more economical device than a conventional PC is appropriate. In a preferred embodiment, the device is implemented utilising a virtual machine having a message processor and a proto-col proces-sor as discussed above. In the preferred embodiment, the software of the device can be considered to include three layers of virtual machine software (the HW drive layer, the Hardware Abstraction Layer, and the Vir-tual Machine Processor layer) and a software application. All layers other than the Virtual Machine Pro-cessor Layers are well established by prior art. A payment termi-nal can be used substantially without alter-ation as the hardware component of the device. A hardware abstraction layer (HAL) is a set of routines providing a common application program interface (API) to exercise the operating system, BIOS or hardware drivers.
  • [0048]
    HAL consists of routines to either (a) implement the functionality not provided by the underlying operating system, BIOS or hardware drivers, but needed for the common API, and (b) translation of parameters and adjustments of functionality required to adapted underlining OS, BIOS routines for the routines specified by the common API.
  • [0049]
    Such a SNAC can be applied in many different types of communication application over a network.
  • [0050]
    The present invention also facilitates the production of devices which incorporate a snac as a functional element of the device. Such devices could include both devices collecting information for transmission over a network such a pay telephones, particularly those equipped with smart card facility, or devices receiving information from a network such as the futuristic VCR or even washing machine.
  • [0051]
    Preferably, message instructions and protocol instructions may be developed on a convenient device such as a PC or general purpose computer, utilising a develop-ment tool in accordance with another aspect of the inven-tion.
  • [0052]
    From a further aspect, the present invention provides a development tool for developing message in-structions for providing directions for operation of a message processor means to be implemented in a virtual machine as discussed above, the development tool compris-ing a processing apparatus arranged to receive data input by a user to build message instructions for the message processor means.
  • [0053]
    The arrangement is preferably driven by a graphical user interface based program which provides various screens and fields for the user to input data relating to message instructions.
  • [0054]
    The message instructions are preferably subse-quently con-verted to code and downloaded into the device which is to employ them with the virtual machine. From a further aspect the present invention provides a development tool for developing protocol instructions for directing operation of a protocol processor means to be implemented with the virtual machine as discussed above, the development tool comprising processing means arranged to receive data input by a user to build protocol instructions.
  • [0055]
    The arrangement is preferably a program which is arranged to build protocol instructions from the data input by the user. The program is preferably graphical user interface based and provides screens and fields to facilitate data input for the protocol instructions.
  • [0056]
    Protocol instructions and message instructions can therefore be built on a PC and downloaded to device where the virtual machine is to be implemented.
  • [0057]
    A tool has also preferably been provided for developing function processor instructions, along the lines of the tool for the protocol processor instructions and message protocol instructions.
  • [0058]
    Limited hardware provided by such a device as a payment terminal or other SNAC device does not lend itself to development and testing of applications programs. Although the final-ised application must run on the hardware, to devel-op and test an application it is more convenient to be able to utilise a more user-friendly device, such as a PC or general purpose computer.
  • [0059]
    From a further aspect, the present invention provides a communications device including a virtual machine means including a protocol processor means arranged to organise communications to and from the device and protocol processor instruction means arranged to provide directions for operation of the protocol processor means.
  • [0060]
    From a further aspect, the present invention provides means for emulating a virtual machine on a PC or other general purpose computer, the virtual machine comprising a message processing means as discussed above. The virtual machine is arranged to operate on the PC or other general purpose computer so that instructions developed for the machine can be tested.
  • [0061]
    Similar emulation is preferably provided for the protocol processor means.
  • [0062]
    Emulation can therefore be used to test payment terminal or other SNAC application programs.
  • [0063]
    The present invention further provides a method of operating a communications device, comprising the step of processing messages for communications by employing a virtual machine means including a message processor means processing messages for communication to and/or communi-cated from a remote device, and message instruction means providing directions for operation of the message processor means.
  • [0064]
    The method preferably also includes the steps of processing communications by employing a protocol processor means and protocol processor instructions providing directions for operation of the protocol processor means.
  • [0065]
    Message processor means, message instructions, protocol processor means and protocol instructions are preferably as discussed above in relation to previous aspects of the invention.
  • [0066]
    The present invention yet further provides a method of programming a device for processing communications, comprising the steps of loading a processing means of the processor means which is arranged to process messages communicated to and/or to be communicated from the device, and message processor instruction means arranged to provide directions for operation of the message processor means.
  • [0067]
    The method of programming preferably also in-cludes the step of loading the processor means of the device with a protocol processor means arranged to organ-ise communications to and from the device, and protocol processor instructions arranged to provide directions for operation of the protocol processor means.
  • [0068]
    The present invention yet further provides a computer readable memory storing code for implementing a virtual machine comprising a message processor means arranged to process messages communicated to and/or from the device.
  • [0069]
    From yet a further aspect the present invention provides a computer readable memory storing code for implementing message processor instruction means arranged to provide directions for operation of a message proces-sor in a virtual machine means, the message processor being arranged to process messages for communication to and/or from a device.
  • [0070]
    From yet a further aspect the present invention provides a computer readable memory storing code for implementing the virtual machine including a protocol processor means arranged to organise communications to and from a device.
  • [0071]
    From yet a further aspect the present invention provides a computer readable memory storing code for implementing protocol processor instructions arranged to provide directions for operation of a protocol processor means arranged to organise communications to and from a device.
  • [0072]
    From yet a further aspect the present invention provides a specialised network access computer, including a micro processor and a virtual machine means, the virtual machine means including instructions for running on a virtual micro processor and an interface enabling the micro processor to operate the virtual processor.
  • [0073]
    Preferably the specialised network access computer is a payment terminal or other type of “card computer” (being a computer which is arranged to process information from cards and/or communicate information to cards—cards being smart cards, magnetic cards or similar).
  • [0074]
    The interface between the actual processor and the virtual processor preferably includes a hardware abstraction layer (AJL) or the like which provides a common API.
  • [0075]
    Features and advantages of the present invention will become apparent from the following description of an embodiment thereof, by way of example only, with refer-ence to the accompanying drawings, in which:
  • [0076]
    FIG. 1 is a schematic block diagram of a payment terminal in accord-ance with an embodiment of the present invention;
  • [0077]
    FIG. 2 is a schematic diagram of a control program architecture for the embodiment of FIG. 1;
  • [0078]
    FIG. 3 is a schematic flow diagram illustrat-ing device operation which requires the operation of the message engine;
  • [0079]
    FIG. 4 is a schematic flow diagram illustrat-ing an example of operation of the protocol engine;
  • [0080]
    FIG. 5 is a representation of a display (screen dump) available on a development tool for developing a program for a device in accordance with an embodiment of the present invention, illustrating devel-opment of a message instruction for an example mes-sage;
  • [0081]
    FIG. 6 is a screen dump of a further develop-ment tool display illustrating further detail of develop-ment of a message instruction;
  • [0082]
    FIG. 7 is a further screen dump of a develop-ment tool display illustrating further detail of develop-ment of a message instruction;
  • [0083]
    FIG. 8 is a screen dump of a further develop-ment tool display illustrating development of a further message instruction.
  • [0084]
    FIG. 9 is a screen dump of a further develop-ment tool display illustrating development of a protocol instruction;
  • [0085]
    FIG. 10 is a screen dump of a further develop-ment tool display illustrates further detail of develop-ment of a protocol instruction;
  • [0086]
    FIG. 11 is a schematic diagram showing a struc-tural embodiment of the message instructions and description for the message processing means, and
  • [0087]
    FIG. 12A is a schematic diagram showing the structure of protocol instructions for an embodiment of the protocol processor means.
  • [0088]
    FIG. 12B is a representation of a display of a development tool for developing protocol instructions.
  • [0089]
    An embodiment of the invention will now be described particularly with reference to a payment termi-nal device. The invention is not limited to payment terminal devices and the following description is given as an illustrative example only. The invention can be employed in all devices concerned with communications over a network, such as a Specialised Network Access Device.
  • [0090]
    A payment terminal device in accordance with an embodiment of the present invention is illustrated in FIG. 1. The device hardware comprises a processing means which, in this embodiment includes a central processing unit 1 and a memory 2 for storing instructions and data. The device further comprises a keyboard 3 for input; a card reader for inputting information from a card 5; a display 6; a printer 7, and a communications interface 8 for communication with an account acquirer.
  • [0091]
    Prior art devices generally have similar ar-range-ments to that illustrated in FIG. 1. The number and type of peripherals to the CPU may vary, but the essential operation required by the prior art and the present inven-tion are similar.
  • [0092]
    Such devices operate to facilitate remote pay-ment transactions, and a general overview of operation is as follows:
      • (1) Information is taken from an account holder's (customer) card 5 via a card reader 4. Transac-tion information is input via the keyboard 3. The trans-ac-tion information may include a money amount. The display 6 may prompt the user (merchant employee, custom-er) to input information (e.g., it may ask a merchant employee to input an amount) and may also display information as it is input. The keyboard 3 may also be used by the customer to input a code for the account, such as a PIN number.
      • (2) The CPU communicates the information via communications interface 8 with an account acquirer com-puter. The account acquirer computer may carry out a transaction (e.g., deduct money from the customers ac-count and pay the merchants account) or may provide an “authori-sation” that a transaction can be carried out. Information that an account transaction has taken place or that the account acquirer authorises a transaction to take place is transmitted to the communications interface 8 from the account acquirer computer. A display 6 may be provided to indicate that the transaction has occurred or may proceed.
      • (3) When the transaction is complete, a print out of transaction information may be provided from printer 7.
  • [0096]
    Prior art payment terminal devices are generally programmed in a conventional manner. That is, programming comprises a sequential set of operating instructions which are executed in sequence to carry out a remote payment transaction. This “sequential program” may be directly compiled onto the processor of the device so that the device is under direct program control or, as is more-usual, an applications program in a conventional programming language may control operations through a BIOS/OS. Whatever conventional programming form is used, however, the device suffers from the problems which are discussed in the preamble of this specifica-tion. The programs are not portable between devices having differ-ent hardware or operating system architectures and it is necessary to write a program specifically for each type of device. Further, any amendments to the operation of the device must be programmed by a programmer having knowledge of that particular device and program arrangement.
  • [0097]
    FIG. 2 is a schematic block diagram illustrating architecture of a device in accordance with an embodiment of the present invention.
  • [0098]
    The architecture comprises the hardware 100 the device, as illustrated and described in relation to FIG. 1. It also comprises the hardware drivers, known in the prior art, and including an existing BIOS/OS or hardware drivers, reference numeral 101 and also includes the Hardware Abstraction Layer Interface (HAL) 102. The HAL 102 and hardware drivers 101 form a layer of a virtual machine which also includes virtual machine processors 103.
  • [0099]
    The virtual machine 101, 102, 103 is arranged to emulate a hypothetical payment terminal. Application 104 controls the virtual machine 101, 102, 103 which in turn controls operation of the hardware 100. The virtual machine 101, 102, 103 can be adapted for many different hardware 100 arrangements (i.e. many different brands of payment terminal). Different arrangements of hardware 100 can therefore be controlled by the same application software 104.
  • [0100]
    The provision of Hardware Abstraction Layers and hardware drivers for virtual machines is known in the prior art and fully described in various publications. Each peripheral of the virtual machine is defined to be able to act in some manner on a standard set of commands. The HAL implements the best interpretation of each command on the actual peripheral present. For example a printer is defined to implement a “feed paper ready for tear off” instruction. On differing roll paper printers this requires feeding a different number of lines, on tractor feed printers this requires feed to the next perforation.
  • [0101]
    The virtual machine processors include a message processor 105 and a protocol processor 106, implemented in software code. The message processor is arranged to process messages communicated to or to be communicated from the payment terminal via the communications inter-face 8. The protocol processor is arranged to organise communica-tions to and from the device, and to control and select the sequence of message processor operations in relation to messages received and transmitted. The message processor 105 and protocol processor 106 are implemented in native code of the payment terminal and therefore operate at relatively high speed. Because much of the “work” of the payment terminal is in building, comparing and deconstructing messages and processing communications, the operation of the device is relatively quick even though employing a virtual machine, 101, 102, 103.
  • [0102]
    The virtual machine processors 103 also comprise a function processor 107 the operation of which is to control and select general operations of the device not specially controlled by the message and protocol proces-sors 105, 106. The function processor is also preferably implemented in the native code of the micro-processor of the hardware 100. The application 104 includes protocol instructions 108, message instructions, 109, function support 110 and function instructions 111. The protocol instructions 108 govern operation of the protocol processor 106. The message instructions 109 provide directions for operation of the message processor 105. Function support 110 and function instructions 111 govern operation of the function processor 107. The application 104 and virtual machine 101, 102, 103 operate on data 112 input to the payment terminal to process it in accordance with the application 104.
  • [0103]
    In this example, the application in-clude a set of “primitives” which are a series of symbol-ic commands which are executed by the device to control carry-ing out of a remote payment transaction. The appendix A to this specification lists primitives utilised by a pre-ferred embodi-ment of the invention and gives descrip-tions of their respective functions. It will be appreciat-ed, however, that a skilled person would be able to design their own primitives for carrying out remote payment transactions and the invention should therefore not be considered limited to use of the primi-tives listed in the appendix. It is in fact anticipated that users of the system may desired to created their own primitives and product documentation attached includes instruction for this procedure should it be desired.
  • [0104]
    Appendix A is in the form of a “HELP” file to be used with a product. The important information for the purpose of this description is the brief description of each “PRIMITIVE” and their function.
  • [0105]
    The primitives operate utilising the data 112. The data 112 may be data being input to the device, such as the customers account number, information which is fixed (strings) in the device e.g., a particular account acquir-ers identity.
  • [0106]
    The function processor 107 includes an event schedular and index as known in the prior art. In re-sponse to an event (e.g., swipe card) the event schedular operates via the index to look up a sequence of primi-tives 11 to be executed in response to that particular event.
  • [0107]
    In the preferred embodiment, the virtual machine processors 103 are constructed using C and the applica-tion is constructed using C++ or Java.
  • [0108]
    The device of this embodiment is event driven. When converting a device incorporation the SNAC hardware requirements to a SNAC by the provision of an appropriate HAL and virtual processors, and event driven structure can be added to a non-event driven underlying architecture through the HAL. This can be achieved through a software loop detecting events and generating an event call for any detected event.
  • [0109]
    The application 104 responds to the occurrence of an event to dictate subsequent operation of the de-vice. For example, when a card is swiped through card reader 4, the appropri-ate sequence of instructions from the applica-tion 104 will be implemented. The event driven structure allows the hardware drives 101 to have control during idle periods. When an input event occurs the application is called to process the input and then returns control to the hardware drives 101.
  • [0110]
    The application may be loaded on a remote payment terminal device with a pre-existing operating system. Where the operating system is event driven HW drivers 102 can operate as an interface layer without any prob-lems. Where the pre-existing operat-ing system (HW drivers) is not event driven, amendments must be made via the HAL to convert to an event driven structure.
  • [0111]
    Appendix B includes a description of a operation of the HAL 18 in accordance with an embodiment of the present invention, on a functional level. A skilled person would be able to develop an appropriate HAL structure for an existing device or a new device. The appendix B is in the form of a “HELP” file for a product. It merely describes an example of implementation of a HAL and adaptation of an existing devices existing BIOS.
  • [0112]
    FIG. 3 illustrates an example of an operation of the device, for one typical step in a remote payment transaction. The other steps in the remote payment trans-action are carried out in a similar way. That is, they may require the operation of the message processor 105. They are event driven, such that the application 104 is called up to deal with any particular event after the event occurs, etc.
  • [0113]
    The operation schematically outlined in FIG. 3 is that of reading information from a customers card and storing information in fields for subsequent processing by the application 105. In overall operation of the device, the information from the card will be required to identify a user and enable access to the user account to cause a transaction or authorise a transaction.
  • [0114]
    FIG. 3A illustrates example information in-cluded on a magnetic stripe on a magnetic stripe card 5. The information includes track 1 information, track 2 information, track 3 information, the customer name, the PAN, the expiry date and End-Of-Form label. This information must be taken off the card and stored in appropriately labelled fields so that it can be accessed to enable processing of the transaction.
  • [0115]
    At step (1), on a card swipe of card 5 through reader 4, the card swipe event is detected by the HW drivers 101.
  • [0116]
    The HW drivers 101 causes a call back to an event table in HAL 102 for the peripheral card reader 4 which contains a series of names for routines to be performed on the occurrence of a particular event on the card reader 4. There are also event tables for the other device peripherals.
  • [0117]
    FIG. 3B is a schematic illustration of the event table for the card reader 4. Event “2” is for card swipe. In this example, there are three alternatives available for a card swipe event, labelled “1”, “2” and “3”. These labels may be dynamically updated in the event table, depending upon the particular stage of operation of the device.
  • [0118]
    Label “1” is for the routine “handle idle card”. This is a routine which is instigated where no payment transaction routine has yet been instigated, i.e., this is “kicking off” operation.
  • [0119]
    Label “2” is the label for the “handle card” routine. This is where the payment terminal device is waiting for a card read event, e.g., where one has a device of the type which requires a money amount to be input before the card is read.
  • [0120]
    Label “3” is where the device may be at a stage in the operation where it does not require a card reader, i.e., the card is swiped in error. In this case, nothing happens and no routine is initiated.
  • [0121]
    Note that the above descriptions of the routines are not “primitives” but are merely general descriptions.
  • [0122]
    It will be appreciated that the event table may contain labels for any number of events to carry out operation of the device peripheral the card reader 4. Similarly the other event tables for the other peripher-als will be configured with labels for various routines they are required to carry out, as will be appreciated by the skilled person. It is not necessary to go into detail detailing all the routines, as they will vary from device to device and will be a matter of choice of the skilled programmer, and the operator of the payment terminal device.
  • [0123]
    This event table driven structure is ideal. In a conventional terminal, where the terminal is executing sequential program instructions, for “handle card” rou-tine the device will merely sit in a loop waiting for a card to swipe. With this architecture, however, the device does not have to sit in a loop waiting for a card swipe. It can leave the applica-tion program and return to the HW drivers 101 and in the mean-time the CPU 1 can be carrying out other jobs.
  • [0124]
    With the event label, the sequence of the appli-cation in-struc-tions for the particular routine is then looked up via an index from the application 104. The function processor 107 is then called up, step (3) to com-mence imple-mentation of the instructions for card swipe. The function processor 103 then implements the instruction sequential-ly. The function processor 103 is a conventional inter-preter, as will be understood by those skilled in the art, arranged to implement the high level primitives of the application 104 via HW drivers 101.
  • [0125]
    The first primitive requiring execution for the “handle card” routine in this example is the SAVE primi-tive, step (4). The first operation of the SAVE primi-tive is to call up the message processor 105. The mes-sage processor 105 is a series of several sub-routines implemented in the native code of the CPU 1, the specific operation of which is to construct, de-construct and compare messages in accordance with message instruc-tions 109 from the application 104. The SAVE primi-tive will have associated with it a label indicating the particular message instruction 109 associated with this particular event. The function processor 107 fetches the message instruc-tion 109 for this event and the message processor 105 then operates to load the data from the card into labelled fields (steps 5, 6 and 7) according to the message in-structions.
  • [0126]
    Once the message processor 105 has loaded the information from the card into the appropriate fields, in accordance with the message instructions 109, the SAVE function is completed and the device proceeds to carry out the next function in the sequence for “card swipe” fetched by the function processor 107. Alternatively, the sequence of functions for “card swipe” may be completed and the device may wait for the next event before proceeding further.
  • [0127]
    There are a number of ways that the payment transaction could continue once the SAVE function has been carried out. For example, steps could be taken to create a display asking the customer to input a PIN. Again, such steps would be carried out by the function processor 105 implementing the instructions, which would include a function to call up the message processor 105 to build a “form” to display the request on the screen. Alterna-tively, the device could be controlled to take steps with regard to the information loaded into the fields by the card in accord-ance with the SAVE function. For example, it could compare a PAN number taken from the card with an equivalent PAN number stored in memory of the device to establish the identity of the account acquirer. A skilled person will realise that a number of possibili-ties are available for continuing with the transaction, and would be able to formulate appropri-ate programming from this description and the following appendices.
  • [0128]
    As discussed, the message virtual processor means is directed by message instructions 109.
  • [0129]
    FIG. 11 is a schematic diagram illustrating the structure of the message instruction means 109. The message instruction means is in fact in the form of a set of “descriptions” of the messages. Each message usually comprises a plurality of fields 120, and the message instruction means for each message contains a corresponding plurality of message instructions. One field may be the CUSTOMER NAME, for example. In the message instruction means, each field is associated with a number of message descriptors 121 which designate characteristic to be applied to the information in that field or to be expected of the information in that field. Operations which may be carried out on the data included in that field may also be included in the descriptors 121. As illustrated in the drawing, the descriptors may include:
      • 1. Data Location Identification. This will indicate either where the data is to be found and/or where data is to be put. In the current embodiment the data location information is contained in a two byte field descriptor (thus having 65535 different possible values) with value ranges allocated to
        • 1) 2000 strings
        • 2) literal numeric values from 0 to 32,000 in abbreviated form
        • 3) data field Ids where each ID is represented as an entry in a table, and each table may contain up to 256 fields.
      • 2. Data Representation (i.e. Ascci, Binary, etc.). This indicates what representation form the data is in and/or what it is to be converted to.
      • 3. Format. This provides a description of the format that the data is in and/or is to be placed in.
      • 4. Test Function. The index of a function processor set of instructions to determine if the current field is to be included or excluded at this time
      • 5. Line & Column. Relative position for use in constructing messages for display or printing. These values are used to determine the quantity of space characters, and or new line characters that are required in the buffer.
      • 6. Substitution list. A list of text representations to substitute for numeric values e.g., display the value “1” as “Monday” and “2” as “Wednesday”.
      • 7. Additional description options as required by the application or prove useful in future embodiments.
  • [0140]
    Each message instruction will therefore include a description of a field of message data, providing instruction for the virtual message processor means which enable it to carry out a number of tasks:
      • 1. To compare a message with a message description to see if it is the correct required message.
      • 2. To take a message of the correct descrip-tion from a location and place it in an-other location.
  • [0143]
    3. To take a message and deconstruct it into various components and place the various components into other locations.
  • [0144]
    4. To take data and build a message in accordance with the message description and place the built message in a location.
  • [0145]
    5. Compare one message with another message.
  • [0146]
    Other functions may also be carried out by the message processor as required by the application. The message processor can manipulate data in any desired way in accordance with descriptions provided by the message instructions. Messages comprising data can therefore be billed, placed in locations, taken from locations, deconstructed with elements being placed in locations, etc. for subsequent operation on the data by the application. Any device which deals with significant amounts of mes-sages in such form can therefore benefit from this ar-rangement.
  • [0147]
    Each message description is labelled so that it can be identified by the application, e.g. each message description may be numerically labelled.
  • [0148]
    A development tool for developing the applica-tion 104, in particular the message and protocol instructions 108, 109 comprises a graphical user interface based program which may be run on a PC or other general purpose computer. The program provides a graphical user interface based framework which en-ables message instructions to be built from data input by a programmer. Message instructions can subsequently be translated into code readable by the virtual machine 102, 101, 103 and downloaded into the application device. FIGS. 5, 6, and 7 are “screen dumps” which illustrate displays generated by the development tool for an example message instruction. In this case the message relates to data from a magnetic stripe of a customers card. The message instructions direct the message processor 105 to take the fields of the message and place them in known locations in accordance with the instructions. Such a message instruction may be called up in response to the SAVE primitive, in the event of a card read. Data from the magnetic stripe of the card would be stored away in the appropriate locations in accord-ance with the instructions, for subsequent process-ing.
  • [0149]
    Each message is provided with a message name 30, in this case “TrackData”. This message name identifier can be used to call up this particular set of message instructions in the development tool. An alternative numeric identifier is generated for use by the virtual processor. This numeric identifier may also be displayed by the development tool. Each message is made up of a number of message “fields” 120. In this particular examples there are seven fields, being “Track1”, “Track2”, “Track3”, “CustName”, “PAN”, “ExpD” and “End-Of-Form”. Each of the seven field is converted to a message instruction for use by the virtual message processor. This is the information which is typical-ly found on any magnetic stripe card. The message instructions in ac-cord-ance with this embodi-ment direct the message proces-sor to process these elements. Each field is associat-ed with descriptors which provide further in-structions for the handling of that element. FIG. 6 illustrates a display 33 which enables a programmer to provide message descriptors to CustName element.
  • [0150]
    Each field 120 has a “format” descriptor 34. There is an instruction as to the Data Represen-tation (“Type”) reference numeral 35. In the illustrated em-bodi-ment there are four types, Ascll, Hex, Binary and BCD. There is also a logical operation instruction (option test), reference numeral 36. This logic instruction can be used to determine whether or not the message processor will process this element at all, for example, i.e., it will only include the CustName element in the message when the logic function equals “True”. Other instructions desig-nate the data source, reference numeral 37, in this case a field, and the field label, refer-ence numeral 39. The format 34 is labelled with a name, in this case, “Tracks”. There are further instructions which dictate the format Tracks to be applied to CustName. FIG. 7 shows a display which illustrates the instructions for the format “Tracks”.
  • [0151]
    The message processor is responsive to all the message instructions to load the data from the magnetic stripe card into the appropriate fields with the appro-pri-ate formats in accordance with all the rules designated in the instructions.
  • [0152]
    This embodiment of the present invention includes another class of message instruction means, known as a “Form”. Instead of a Data Representation as a message descriptor, a Form includes description of a Location of the data field in the Form. FIG. 8 is a display provided by a development tool enabling the programmer to prepare message instructions for a Form message. On the left hand side of the display a panel 70 illustrates Form layout. The fields in the Form include MerName, Address Line 1, etc. The location of these fields can be moved within the panel 70. The location in the panel is provided as a descriptor and for the message instruction. The Form type of message instruction controls displays, reports, print-outs, and the like. The type of Form is given by the instruction designated by reference numeral 71, in the example illustrated in FIG. 8 being a print-out. The message processor takes the fields from known memory locations or other locations and enters them in the locations enabling the Form described by the Form instruction to be produced.
  • [0153]
    As discussed previously, another major function of a SNAC device is communications. For example, it is necessary for the majority of remote payment transactions for communications to be able to occur between an account acquirer location, in order to enable access to an account, and the remote payment device. Communication with a data carrier, such as a smart card device may also be required.
  • [0154]
    The protocol processor 106 is arranged to organise communications, in accordance with directions from the protocol processor instructions 108. Referring to FIG. 4, in a typical remote payment transaction, after a card has been swiped, a PIN number has been input and a charge amount has been input, information then needs to be communicated to an external computer, at the account acquirers, in order to enable further processing of the transaction. After an event such as a communications message arriving, therefore, HAL 102 detects the event (step 1) and activates the protocol processor (step 2), FIG. 4. The protocol instruction 108 for the event is rolled up (step 3). The protocol processor 108 implements the protocol in-structions for that event, (step (4)).
  • [0155]
    The protocol instructions are divided into “sections” 130, “lines” 131 and “protocol commands” 132, as illustrated in FIG. 12A. FIG. 12B illustrates how an instruction is displayed on a development tool for protocol instructions. Protocol instructions describe message flow both from and to the device. The top line specifies outgoing messages and the other lines display possible incoming results. A protocol consists of lines and sections. At the start of each section is a line 1 (optional for the first section) which describes the outgoing message. There are a number of protocol commands, and these include:
      • 1. Protocol—Run a sub protocol
      • 2. Message—Send a message or handle an incoming message using the virtual message processor means
      • 3. Retry—re execute the steps of protocol from and indicated point
      • 4. End —End of the protocol
      • 5. Exit—Stop the protocol from an intermediate point
      • 6. Timeouto—Specify the a delay after which the protocol should automatically jump to the point at which the timeout instruction is placed.
      • 7. Control—Specifies a control character to be send or received.
      • 8. Function—Execute a virtual function processor function
  • [0164]
    Protocol instructions are organised in lines and sections. In each section Line 1 indicates the information to be send by the SNAC device and subsequent lines indicate actions to be taken in response to the alternate possible events which may occur in reply. The first instruction on each of these subsequent lines is used to identify the response. Control( ), Message( ), Function and timeout( ) may all be used to identify responses as follows.
      • 1) When the time specified by a timeout instruction elapses then the line commencing with the timeout will be selected.
      • 2) When data is received it will be sequentially compared to a lines commencing with Control( ) Message( ) or Function to see if the data matches the control character, matches the message of causes the test contained in the function to evaluate to true.
  • [0167]
    FIGS. 9 and 10 illustrate displays of a development tool for protocol instructions for the protocol “General” which is the Protocol Name (refer-ence numeral 42). Instructions are presented as a screen dump in the form of a table 43, which can be accessed by a programmer if he wishes to alter the protocol.
  • [0168]
    Protocols are arranged to control message flow both from and to the target device (e.g., account acquir-er computer). The top line of the display panel 44 specifies outgoing messages and the other lines display possible incoming results.
  • [0169]
    A particular protocol is able to call up other protocols “nested” within it and is also able to call up the message engine to deal with messages.
  • [0170]
    Referring to FIG. 10, the top line of panel 44 specifies the outgoing message. The first operation of protocol “General” is to call up and carry out a further protocol, “Reversal”. FIG. 11 illustrates instructions for the protocol Reversal, reference numeral 45. Rever-sal operates to call up the message engine to construct message number 0400 and this message is then sent to the target device.
  • [0000]
    The either
  • [0000]
      • 1). Message number 0410 should then be re-ceived back from the target device and the message processor will be called up to deal with that data, which involves the message processor comparing the incoming mes-sage against the description specified by the message instruction means and storing the data if a match occurs. Or
      • 2) A timeout of 100 tenths of a second elapses.
  • [0173]
    Then the protocol is ended and re-turned to the protocol General, which causes a further message, 0100 to be formulated and sent out.
  • [0000]
    Then either
  • [0000]
      • 1) A message matching 0110 will be received or
      • 2) A message matching 820 will be received or
      • 3) neither 1 or 2 will occur for the timeout( ) period, in this case specified as 000 tenths of a second.
  • [0177]
    If the message 0110 should then be received from the target device and compared by the message engine, then another protocol “adjustments” will then be carried out. The protocol would then end.
  • [0178]
    If the message 820 should be received from the target device, which can be dealt with by the message engine and compared with the instructions from the mes-sage instruction means. The “Retry” instruction will then be executed causing the virtual protocol processor to move execution back to the sending of the (0100) message. The retry count of zero indicates this loop would continue whilst 820 messages are received.
  • [0179]
    If the Timeout occurs, then the retry(5) would be applied causing the protocol processor to move execution back to the Send 0100 message. This loop would occur up to five times as indicated by the retry(5). After the fifth time execution would move to the next section causing the protocol to End.
  • [0180]
    More details of operation and build up of mes-sages and protocols are given in the appendix A.
  • [0181]
    The device in accordance with the present invention for example a payment terminal, may be implemented in GAVA by defining a class library payment terminals. This class library would contain calls to all the functions of how to HAL and preferably the message and protocol engines. Similarly, a specialised network access computer or card computer could be implemented in GAVA.
  • [0182]
    Please note that the arrangement of the present invention can be used to deal with any payment transaction device, including one which deals with smart cards.
  • [0183]
    The present invention can also be used to implement a specialised network access device, which may use similar hardware to that provided for a payment terminal.
  • [0184]
    In the attached Appendix A, the term “CardScript” is the name the applicants have given to programming required to implement this embodiment of the invention.
  • [0185]
    It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.
  • [0186]
  • [0000]
  • [0000]
  • [0000]
  • [0000]
    Help for CardScript Scribe
  • [0187]
    The Scribe program assist in the design of stored information & programs for EFTPOS terminals, PINpads, Electronic Cash Reqisters and other small computer systems.
  • [0000]
    Writing a Program
  • [0188]
    For help on writing a CardScript, program, rather than operation of the Scribe tool, see
  • [0000]
    Writing a CardScript Program
  • [0189]
    A CardScript program is more similar to a Windows RAD tool program than a conventional C Language or Assember program.
  • [0190]
    The “target” device has several keys, one or more card readers, and usually one or more communications ports. Defining a program consists of attaching actions to these events, or the special events of terminal power on and terminal idle.
  • [0191]
    CardScript programs—as all other program—manipulate data. Data is defined in a Data Dictionary. Unlike normal programs, it is normal to write many CardScript programs using the same Data Dictionary. Standard Data Dictionaries are available from CardSoft for EFTPOS and several other application types. It is recommended to write initial applications based on one of these standard dictionaries. Once the program is experienced, the Data Dictionary for an Application may be modified. see
  • [0000]
    Configure Data Dictionary
  • [0000]
    Data Dictionary Usage
  • [0192]
    The Data Dictionary represents the list of all “variables” or information values used in the target device. These “variables” are in formation which may change over time, or be different from device to device.
  • [0193]
    Information which is fixed for all devices usually is defined by strings. All information to be included in displays, receipts, messages etc, comes from either the Data Dictionary or from STRINGS.
  • [0000]
    Data Dictionary Fields may Have an Initial Value Set From the Initial Data Tables
  • [0000]
  • [0000]
  • [0194]
    The Data Dictionary is divided into tables. Each record displayed in Configure Data
  • [0195]
    Dictionary describes one table. Fields are placed by selecting add and clicking on the Panel.
  • [0000]
    Field Attributes
  • [0196]
    Double Clicking on any field reveals and allows viewing and/or editing of Data Dictionary Field Attributes.
  • [0000]
    Field Order
  • [0197]
    Layouts are stored indexing fields by table#1field#. This means existing scripts will behave strangely if the Data Dictionary is changes the number Of referenced fields.
  • [0198]
    For example if “Merchant Name” is table 3/field 2 and “Address” is table 3/field 3. Then deleting field is table3/field1 will make any prior references “Merchant Name” now reference “Address”. This can be remedied by inserting a dummy table3/field 1 as a placeholder. Generally this problem does not arise since new dictionaries are not to be used for old applications, and existing dictionaries are usually only extend. In the rare event that a dictionary used by existing applications is to have fields deleted, it recommended to rename them to “dummy” or “unused”. Be careful since any existing data in the files will be rearranged when retrieved, it will simply be move from the record into the fields in the order listed at the time. New fields added in graphic display mode are always added at the end
  • [0000]
    Reserved Settings
  • [0000]
    See Reserved Data Dictionary Settings
  • [0000]
    See Also
  • [0000]
    Data Dictionary Field Attributes
  • [0199]
    The field attributes which may be set are as follows
  • [0000]
  • [0200]
    Type refers to the format in which data is held. “X-Ref’ is a special value used to indicate that another table will be referenced at run time and thus must be included in the build.
  • [0000]
    Binary Data Fields
  • [0201]
    Binary. either 1 or 2 bytes in length for Integer values in calculations, longer fields hold bit fields or keys. 250 bytes is the maximum permissible number of bytes
  • [0000]
    Maximum Integer Values
  • [0202]
    Depending on the number of bytes used to represent the Binary number, the following values are possible
    1 Byte O . . . 255
    2 Byte O . . . 65,535
    3 Byte O . . . 16,777,215
    4 Byte O . . . 4,294,967,295
    • Text-up to 250 bytes
    • BCD up to 250 bytes
    • Date/Time (2 Bytes for Dates, 2 or 3 bytes for Time)
    • see Date & Time Fields
    • Amount—10 bytes, internal format is target device dependent
    • Packed Amount—not currently used
    • X-Ref—Advanced use only
    • Flags
    • 0=Field is fixed and never reset
    • 1=Reserved for future use
    • 2=Reserved—used with deleted fields
    • 3=Field is reset when terminal is loaded
    • 4=Field is reset at power on
    • 5=Field is reset by idle function
  • [0217]
    The leright of stored data in bytes
  • [0000]
  • [0218]
    Caution: When you create new data dictionary fields, make sure their leright is not zero if you want to use them, or they will be invisible.
  • [0219]
    The number of characters allocated to display the field as text
  • [0000]
  • [0220]
    The name of the field for display on receipts etc.
  • [0000]
  • [0221]
    The “refer” Initial Data File from which the field initial value is extracted. Blank if the field is extracted from the default file.
  • [0000]
    Table ldx
  • [0222]
    When “Table” is non-blank, “Table ldx”specifies the “refer” of the Initial Data Field in the default file used to indicate the record number in “Table” from which data is to be extracted. In other words the join field between the default table and the joined table.
  • [0000]
  • [0223]
    The “refer” of the Initial Data Field from which the initial value of the field is to be obtained.
  • [0000]
    Creating a New Application
  • [0224]
    As suggested above to create any application, it is recommended to copy a “template” application. Simply copy the entire template directory.
  • [0225]
    To then work with the new directory, select File/Installation and edit the data directory. (Don't forget the trailing I) Is the recommended to exit Scribe and restart. Scribe and restart.
  • [0000]
  • [0226]
    The display console used with CardScript is quite sophisticated. see
  • [0000]
    The Console
  • [0227]
    CardScript can be used in a variety of devices, some of which may not support all the features described here.
  • [0000]
  • [0228]
    The CardScript Console has a number of sophisticated features
  • [0000]
    Hot Keys
  • [0229]
    Keys used to launch only one action, where the action is part of the application, are known as hot keys. Typically the action may be activated only when the terminal is idle. For further information see the “KeyBd” primitive.
  • [0230]
    In an EFTPOS application, on a terminal with Keyboard Buttons available for allocation, Hot Keys will normally be allocated to such functions as “Sale”, “Adjustment”, “End of Day” etc.
  • [0231]
    Hot keys normally would have their label printed on the keyboard, or on the physical button.
  • [0000]
    Multiple Field Input
  • [0232]
    On any Layout displayed on the console, several field may be selected for input. The OK key steps from one input to the next. Any soft key terminates all input.
  • [0000]
  • [0233]
    The display may be scrolled, permitting a larger virtual display than the physical display. Scrolling is performed automatically by the driver in the target device. All that is needed to enable scrolling is to tell the scrolling driver what keys on the keyboard perform scrolling. The keys used to scroll are set by the
    • Console Primitive
    • Console(Command,Parameter)
  • [0236]
    The command determines which of the following console options is set.
  • [0237]
    Command I—Set Scroll Keys
  • [0238]
    The Parameter is a string of four hex values, in order key-left, key-right, key-up, key-down
  • [0239]
    The keyvalues specified are assigned to the scrolling engine within the target device. Note scrolling my not function on all CardScript “targets” and the size of the scrollable area may vary.
  • [0240]
    Command 2—Set Keymap
  • [0241]
    The parameter is a Key board map. This command is now the preferred method for setting the keyboard map. The old Keymap primitive will be obsolete in a future version. See
  • [0000]
  • [0000]
    Structure of Keymaps
  • [0242]
    The “field” or String used as a keymap must be a list of 4digit hex blocks, the first two digits of each block representing the hex code of the key to be mapped and the next two digits representing the hex value to map be returned. Usually used from the startup function, using a field from the terminal groups record.
  • [0243]
    Note that the following key codes have special meaning.
  • [0000]
  • [0000]
    • Represents a backspace or ‘CLR’ code.
    • Represents an ‘OK or ‘Enter
    • Represents a cancel.
      30 through 39
    • Represent the digits “0123456789”
      Command 3-Keybd
  • [0248]
    The parameter is evaluated to zero, or non zero.
  • [0249]
    Upon entering idle state, the action of the keyboard is determined by the last KeyBd command. The keyboard (except cancel) will be ignored if off was specified.
  • [0250]
    This command replaces the old keybd primitive, which will be obsolete in a future version.
  • [0000]
    Command 4—Invalid Entry
  • [0251]
    The parameter is the text message to be displayed.
  • [0252]
    This command is designed to be called from an input validation function. Calling this command indicates the input is invalid, the text specialised in the parameter should be display to indicate the error.
  • [0000]
    Soft Keys
  • [0253]
    Some keyboard buttons on a target device may be used as soft keys. As opposed to Hot Keys these are buttons which may be used to initiate different actions, depending on the display present when they are pressed.
  • [0254]
    Since the principle of Soft Keys is to use the same buttons for different actions, displays must in some way indicate to the user the operation of each currently active soft key.
  • [0000]
    Soft Key Button Sets
  • [0255]
    Target devices may allocate certain buttons on the keyboard for use as soft keys. Button sets are numbered from zero. If a specified set is not available, then set zero is used. By convention:—
    • Set 0 keys ‘O’ thru ‘9’ (the numeric keys)
  • [0257]
    Set 1 are dedicated soft keys, usually positioned directly adjacent to the display, in order that the display may be easily used to indicate their function.
  • [0258]
    Set 3 is the new standard for dedicated soft keys—hex values 81,82 . . . AO.
  • [0259]
    Set 3 will normally be requested on forms where numeric/text input is also required.
  • [0260]
    Set 4 is the same as set 3, but allowing use of the numeric keys if no dedicated soft keys are available. Set 4 should not be specified on screens where numeric input is also available, since this may cause a conflict.
  • [0000]
    Soft Key Action Groups
  • [0261]
    These are the groups of actions that may be offered at any given time.
  • [0262]
    In Layouts/Forms, a soft key action set may be selected for any display. Individual functions may be assigned to an action group from the Function/General Purpose Functions, in the Function activation section.
  • [0263]
    Note Action group 0 is used to indicate a function is NOT part of any group
  • [0000]
    Correlation of Actions to Buttons
  • [0264]
    If a display allows soft key Button Set 0, (Keys ‘0’,‘1’,‘2’,‘3’ etc) and action set“I‘ then when the ‘2’ key is pressed, then soft key group ‘1’, An Group ‘2’ (Key ‘2’minus the first key in the action set equals 2), if it exists, will be activated.
  • [0000]
    The Keyboard
  • [0265]
    To control the features available, and make best use of your terminal, you can recode the keys on your keyboard using the keymap primitive. This allows you to customise the target device to allow portable and easy to operate applications.
  • [0000]
  • [0000]
    Keyboard Codes
  • [0266]
    The Keyboard codes are designed to accommodate a wide variety of keyboard configurations. At any given time each key (or button) will act as one of the following key types
    • 1 Control/Data Entry Control
    • 2Data Entry
    • 3Soft/Hot key function activation
      Control/Data Entry Control
  • [0270]
    Some keys are required for control. Control keys should not be used for any other purpose than control, otherwise the user interface will incredibly confusing.
  • [0000]
    Minimum Requirements
  • [0271]
    All CardScript drivers should provide these key codes without any mapping required.
    • 08 Backspace or Cir
    • 1B Cancel
    • OA OK or Enter
    • 1A Fn—For general Function selection, and for double (or tripple) zero.
      Additional Options
    • OD or complete form (combined with tab as an alternativ to OA)
    • 09 Tab (move to next field—does not complete form)
    • OB Vertical Tab—Used as back tab or move to prior field.
    • 11 (XON)DCI—Used as cursor left
    • 12 DC2—Used as cursor right
    • 13 DC3—Dedicated double zero
    • 14 DC4—Dedicated Function Key (combined with DC3 as an alternative to 1 A).
      Data Entry
  • [0283]
    Three levels of data entry may be available at any one time. Text, Hex,Alpha. The bios can automatically determine the available level and act accordingly.
  • [0000]
    Minimum Requirements
  • [0000]
    • 30.39 (Numerics)
      Additional Options
    • A B C D E F (allowing Hex data entry)
    • Full ‘querty’ keyboard
      Soft & Hot keys
  • [0287]
    Soft keys previously were recommened to be ‘a″b-c’ etc Now the are recommended to be hex 81 82 83 etc up to a maximum of AO allowing upt to 32 dedicated Soft keys. The change in recommended values is to allow for terminals with full alphabetic keyboards. Hot Keys (When/Additional to soft keys) should be allocated from A1 . . . DO
  • [0000]
    Program Portability
  • [0000]
    Portable Programs
  • [0288]
    CardScript allows the writing of totally portable programs, it is also possible to write programs that are not very portable. Any CardScript program will “execute” on any CardScript enabled target, however the result could be of no use on the target if special hardware characteristics are required for practical operation of the program. CardScript provides a mechanism for avoiding the traps and keeping programs portable whilst still taking advantage of special hardware when available.
  • [0000]
    Keyboard Traps
  • [0289]
    The key map primitive represents a trap in that this function should never be used with a literal string, or your program won't be portable.
  • [0000]
    Processing Cards
  • [0000]
    Magnetic Cards
  • [0000]
    • Automatic Processing
    • Automatic Magnetic Card Processing, from
  • [0292]
    Upon Card read, data from the card is placed int the Receive buffer. The format in the buffer is
    • Track 1 (I terminated)
    • Track 2 (I terminated)
    • Track 3 (I terminated)
    • Customer Name (I terminated)
    • PAN (I terminated)
    • Expiry Date (6 bytes ASCII)
  • [0299]
    If the read occured at terminal idle, the Cacluation Result is set to zero and the system event Magnetic Card Read is generated. After executing any function for the Magnetic Card Read Event, if the Calculation Result is non zero this value is used to select a function for further processing of the specific card type.
  • [0000]
    Automatic Magnetic Card Processing
  • [0300]
    Upon card swipe, the data dictionary fields
    • Transaction/Track2 tru Transaction/Customer
    • Name are filled with the card details. These are data dictionary fields Table1/Field2 thru
    • Table1/Field7. see Reserved Data Dictionary Settings for details.
  • [0304]
    Table 5 is then scanned to find a column matching the PAN of the swiped card. If a column in table 5 is found then the tables 3 & 4 have their columns set according to the entries for Issuer & Acquirer in Table 5.
  • [0305]
    Table 5 is set during the build to indicate the appropriate action should a card be swiped at idle. If the teminal was idle at the card swipe this function is now executed.
  • [0000]
    Typical Processing.
  • [0306]
    For standard processing, create a function as follows
    • store (O, CardMsg)
    • if ColFind(Pan,PanLow,PanHigh)
      • ColSelect(Issuer, IssuTbl)
      • ColSelect(Aquirer,AcqTbi)
      • Exit(O,CardFunc)
        Smart Cards
  • [0312]
    Two primitives are available for controlling Smart Cards.
  • [0000]
  • [0313]
    1A command of 1 is used to read the smart card status into the field “FieldNalue”. Using a value for “FieldNalue” does achieves nothing.
  • [0314]
    2A command of 2 is used to control the power to the card. If “FieldNalue” is 1, the card is powered on, if “FieldNalue” is 0 the card is powered off.
  • [0315]
    3Select. A command of 3 is used to select which smart card reader(or plug in is surrently selected. By convention, 1 is the user card(or if only one reader is present, this reader), 2 is the separate merchant card slot or the plug in, where present. “FieldNalue” contains the card number to be selected.
  • [0316]
    4A command of 4 is used to read the Smart Card Type Code
  • [0317]
    5A code of 5 performs a logical test on smart card type. If the field/value supplied matches the Smart Card Type Code of the current code, the logical true flag is set. This command is designed to be used in an “if”test
  • [0318]
    6Code 6 reads the CardEntryMode into the specified FieldNalue. See CardEntryMode 7Set Card entry mode to the value specified in FieldNalue
  • [0000]
    see Also
  • [0000]
    TPDU(Command, SendMsg,RxMsg,Status)
  • [0319]
    The TPDU primitive is used to send a command to the card. If the TxMsg is present this data is also sent to the card. If the RxMsg is present then a response is expected from the card and is stored in the RxMsg buffer.
  • [0000]
  • [0320]
    This if the actual 5 bytes TPDU to be send to the card
  • [0000]
  • [0321]
    This optional parameter specifies the message used to build the data send to the card.
  • [0000]
  • [0322]
    This optional parameter specifies message used to store any data returned by the card in response to the TPDU.
  • [0000]
  • [0323]
    This mandatory message specifies the location of status variables to record the status of the TPDU operation.
  • [0324]
    The TPDU primitive with Synchronous (Memory Cards) 416 Cards
  • [0325]
    Drivers for 416 Cards support the following TPDU Commands
    • ReadBytes
    • WriteBytes
    • EraseBytes
    • Present Key
    • see Commands for Memory Cards
  • [0331]
    The present Key uses the lenght indicator to select either the CardSecret Code (2 bytes) or the application erase secret code (4 bytes)
  • [0000]
    Answer to Reset, & Card Type
  • [0332]
    The 416 has a card type code of 4 and an answet to reset of
    • 3Bh 00 00 00 00 00
      Commands For Memory Cards
    • ReadBytes
    • CL (any)
    • INS BO
    • ADDR XXXX (Byte Address an Card)
    • LN LL Number of bytes to read.
    • CL (any)
    • INS DO
    • ADDR XXXX (Byte Address an Card)
    • LN LL Number of bytes to write.
    • CL (any)
    • INS DE
    • ADDR XXXX (Byte Address on Card)
    • LN LL Number of bytes to erase.
    • CL (any)
    • INS 20
    • ADDR XXXX (Byte Address on Card)
    • LN LL Lenght of Key.
      Other Smart Card Commands
  • [0351]
    For selecting the smart card reader, and control of the reader.
  • [0352]
    For sending information to the card, and receiving information from the card.
  • [0000]
    Smart Card Type Codes
  • [0000]
    • 1 Async ISO type Card
    • 2416
    • Asynchronous SCHLUMBERGER type EE2K
    • Asynchronous SCHLUMBERGER type EE4K.
    • Asynchronous SCHILUMBERGER type EE16K.
    • Asynchronous type GPM256
    • Asynchronous generic type 12C BUS
    • Asynchronous type GFM2K
    • 9 synchronous type GFIVl4K
    • For coding of smart card types.
      Running A CardScript Program
  • [0363]
    To run the program on the PC simulator, see
  • [0000]
    PC Simulator
  • [0364]
    There is a impimentation of the CardScript Virtual machine available on the PC that not only runs your program, it also emulates the keyboard layout and other controls of any target machine.
  • [0365]
    To run the simulator—select “Build/Run Simulation of Build”
    • Stored Information—Data Tables
  • [0367]
    For Information on setting & changing values in the Data Tables See—
    • Tables Menu
  • [0369]
    CardScript includes all tools for maintaining data tables to control the setup and distribution of Data Tables required for any application.
  • [0000]
    The System Data Table
  • [0370]
    The system data table has a fixed format identical in all systems. This table contains general information and current setting for use within the scribe program.
  • [0000]
    See —
  • [0000]
    System Table Settings
  • [0371]
    Settings in the system table are used to both miscellaneous settings in the script, and options for viewing the script.
  • [0000]
    Loader Settings
  • [0000]
    • Terminal For Mask Load
    • Not used by scribe
      Default Prompt (or String) Table
  • [0374]
    The string table displayed within Scribe. Multiple string tables may be used to support multi language applications.
  • [0000]
  • [0375]
    Description the peripherals of a the target system here and displays and reciepts will in scribe will show guides to assist in design. These setting have no affect on program execution in target devices and may be changed at any time.
  • [0000]
    Reserved Functions
  • [0000]
    Idle State
  • [0376]
    Set this pointer to indicate a function to be executed each time the “target” becomes idle.
  • [0000]
  • [0377]
    Normally left at <none> since applications may vary default options during execution.
  • [0000]
  • [0378]
    This function is executed at “target” power on.
  • [0000]
  • [0379]
    Previously used to indicate the byte order used in the “target”. It is now recommeded to use “Low-High (INTEL)” for all systems.
  • [0000]
    Configurable Data Tables
  • [0380]
    The data tables used by CardScript can have their names, field names, layout and even the number of tables used altered according to the current system setup.
  • [0000]
    Configure Initial Data
  • [0000]
    Initial Data Usage
  • [0381]
    The purpose of initial data tables is to provide a database of information for initial values for the data dictionary loaded into the target device.
  • [0000]
  • [0000]
  • [0382]
    Each record in the configuration describes one table. Fields are placed on the Panel and dragged to the appropriate position.
  • [0000]
    Field Atttributes
  • [0383]
    Double Clicking on any field reveals and allows viewing and/or editing of Initial Data Field Atributes.
  • [0000]
    Field Order
  • [0384]
    Clicking on “Graphic Display” toggles between the standard graphic view of the fields and a simple ordered list of the fields. In the ordered list mode fields may be dragged to rearange the field order.
  • [0385]
    Be careful since any existing data in the files will be rearranged when retreived, it will simply be move from the record into the fiels in the order listed at the time. New fields added in graphic display mode are always added at the end.
  • [0000]
    Reserved Initial Data13ase Settings
  • [0386]
    Certain fields must be present in the for the build process.
  • [0000]
    File Usage
  • [0000]
    • File 1—“Terminals”. The name may be changed however this file is used to initialise individual target devices with the optional “NetMgr” module. No other special usage at present
    • File 2 “Groups”—no special considerations
    • File 3 “Issuers” no special considerations
    • File 4 “Aquirers” no special considerations
    • File 5 “Card Ranges”—must be used as card ranges, and must have fields “lo” “hi” and “Ien”
    • File 6 “Products” no special considerations
    • File 7 “Region Settings” no special considerations
    • File 8 “Issuer Sets” no special considerations
    • File 9 “Card Sets” must contain the fields “cards” as an index into card ranges
    • see also
      Initial Data Field Attributes
      Current usage
    • 0=Place label to Left
    • I=Place lable above
  • [0399]
    The number of times the field is to appear on the form
  • [0000]
  • [0400]
    The current value of X-positon of the field on the form. Usually modified by dragging the field.
  • [0000]
  • [0401]
    The current value of Y-positon of the field on the form. Usually modified by dragging the field.
  • [0000]
  • [0402]
    The label to appear for the field on screen.
  • [0000]
  • [0403]
    The “refer’ label used to access the field when building the initial data dictionary Display (Type=Text only) The number of characters to be displayed on screen. 0 (zero) for default.
  • [0000]
  • [0000]
  • [0404]
    For information on defining functions in your application see —
  • [0000]
    Functions Menu
  • [0000]
    see also Function Primitives
  • [0405]
    For Describing any function within the “target” to the system, or in program terms for writing scripts see
  • [0000]
    General Purpose Functions
  • [0406]
    Use this selection for describing functions
  • [0000]
  • [0407]
    The function name
  • [0000]
  • [0408]
    A brief descrition of the function. The function can be located by description
  • [0000]
  • [0409]
    A window to the function actions. Double click on this window to see or edit the full Function Action. see also Function Primitives & Function Primitive Catagories. see
  • [0000]
    Function Action
  • [0410]
    Double clicking on a function action block brings a panel into view for editting the function actions.
  • [0000]
    Adding Actions
  • [0411]
    Select the apprioate action from the alphabetical list beside the add option, select add and then click on the panel at the appropriate postion. Clicking over an existing action will insert the new action before the existing action
  • [0000]
    Deleteing, Actions
  • [0412]
    Select delete and click on the action. Take care to deslect delete before clicking on other actions.
  • [0000]
    Editting Actions
  • [0413]
    Double Click on any action to activate the edit dialog box.
  • [0000]
    Function Index
  • [0414]
    Shown for reference purposes. Cannot be changed.
  • [0000]
  • [0415]
    See your driver information. Currently this information is not used by most drivers.
  • [0000]
    Function Activation
  • [0416]
    Specifies when this fuction will be executed. see
  • [0000]
    Starting A Function
  • [0000]
    Function Number
  • [0417]
    Each function may be assigned a number. The operator may then enter the number and the program easily select from the list using the Function# primitive.
  • [0000]
    Hot Key Code
  • [0418]
    Each function may be assigned a hot key code. Enter a non-zero code in HEX and if a key with this code is pressed at idle, or any other time hot keys are activated, the function will be activated. Note that the Cancel Key is regarded as as system event.
  • [0000]
    System Events
  • [0419]
    System Events are similar to hot keys, only instead of keys being pressed (Note that the Cancel key, IS a system event), other actions on the target device are involved. For each target machine a list of System events is maintained, but these should always include the standard events. Only one function may be assigned to any System Event.
  • [0000]
  • [0000]
    Standard Event Codes
  • [0000]
  • [0420]
    Keys on the keyboard with a value less than 128 (O8O hexadecimal) generate an event code with the value of the key.
  • [0000]
    Other Event Codes
  • [0000]
    • 0=Reserved
    • 1 System becomes Idle
    • 2Cancel Key Pressed
    • 3System Power On
    • 4Numberic Entry
    • 5Smart Card Insertion
    • 6Smart Card Extraction
    • 7Magnetic Card Swiped
    • 8Checksum Error Detected on Batch
    • 9Checksum Error Detected on Data
      Card Set
  • [0431]
    Select a card set. When any card belonging to this set is swiped at idle, the function will be activated.
  • [0000]
    Usage Flags
  • [0000]
    • Operator Function—The operator of the target device selects the function
    • Library Function—The function is an internal “subroutine”
    • Not Used—The function is not used
    • For adding actions to functions which may be varied by issuer or by acquirer see
    • Transaction Function Input
    • Transaction Function Approval
      Function Primitive Catagories.
  • [0438]
    Function script is a sequence of calls to system and user primitives. For information ol
    • primitives available see
    • Function Primitives
    • Assignment Primitive
    • Field1:=String/FfeW
    • Set field1 to the string/field2.
    • => (goes to) primitive
    • => field
  • [0446]
    The vaule of the last logical or other operation using the “calculation result” is stored in field
    • specified
    • eg
    • Account ==000
    • => zAccount
  • [0451]
    Would set the field zAccount to 1 if Account was zero, othersize zAccount would be zero.
    • => result (goes to) primitive
    • => field
  • [0454]
    The vaule of the last logical or other operation using the “calculation result” is stored in field specified
    • eg
    • Account ==000
    • => zAccount
  • [0458]
    Would set the field zAccount to 1 if Account was zero, othersize zAccount would be zero.
  • [0000]
    see also
  • [0000]
    Calcuation Result.
  • [0459]
    Calculations generate a “Calcualtion Result”. Think of this value as the value you would see on the display of a calcuator if the caluculation was performed on a calcuator.
  • [0000]
    Math Primitves
  • [0000]
    • Field1+=Number/Field2
    • Field1−=Number/Field2
    • Field1*=Number/Field2
    • Field1/=Number/Field2
    • Field1 is modified by thefield2/number.
      Relational Primitives
  • [0465]
    • Field1value1>Field/value2
    • Field1value1 ==Field/value2
  • [0468]
    The two fields or values are compared. If one field is text and the other numeric then the return value will always be false.
  • [0000]
    <> !=>=<=
  • [0469]
    For not equals (whether thought of as < > or!=), greater than or equals (>=) and less than or equals (<=) use the opposite case. With the WHILE PRIMITIVE and REPEAT UNTIL primitive then use the NOT option. With the IF PRIMITIVE use the ELSE clause.
  • [0000]
    Abort Primitive
  • [0000]
  • [0470]
    This primitive causes the target device to stop all functions and become idle
  • [0000]
    Alarm Primitve
  • [0000]
    Alarm (noise type)
  • [0471]
    Makes the sound specified
    • 1 error alarm
    • 2bip type noise
    • 3most severe alarm
      Bit Manipulation
      Bit Numbering
  • [0475]
    All binary fields can be accessed as a number of bits where the number of bits no.of.bytes*8
  • [0476]
    The MSB of each byte has the highest bit number and the LSB the lowest bit number. Note ISO bitmaps do NOT follow this rule, but these do not need bit manipulation by the application.
  • [0477]
    This result in the LSB of the last byte being bit 0 (zero) and the MSB of the first byte being no.of.bytes*8-1. Eg for two bytes 15.
  • [0000]
    Bitcount Primitive
  • [0000]
    • bitcount(field,start,end,bitvalue)
      start & end
  • [0479]
    These are both bit numbers. see bitnumbering. Direction of counting is from start to end, either may be the larger number.
  • [0000]
  • [0000]
    • 0 indicates count zeros
    • 1 Indicates count ones
    • 2 Indicates counts zeros and stop at the first non zero bit
    • 3 Indicates count ones and stop at the first bit no set to one.
  • [0484]
    The numer of sequential bits of the value “bitvalue” starting from bit “start” and working towards “end” is counted.
  • [0485]
    If the result is non-zero the logical true status is set, otherwise the logical false value is set, allowing “if′type tests of the result
  • [0486]
    The count is stored as the “working value” allowing storage via the “->” (goes to) primitive. see -> (goes to) primitive Setbits Primitive
    • Setbits(field,startbit,endbit,value)
  • [0488]
    Bits number “start bit” thru “endbit” are set to the value “value”. No all values are extracted from the least significant bits of value.e.g. For a 1 bit field, all values are considered either 1 or 0. (Odd numbers are 1)
  • [0000]
    Batch Primitive
  • [0000]
    Batch (Operation)
  • [0000]
    • Operation 0=reset to first txn in batch
    • Operation 1=find & restore next txn
    • Operation 2=delete current transaction
    • Operation 3=delete all transactions
      CardRead Primitive
    • Card (string, field form, default)
  • [0494]
    This primitive is identical in operation to the show primitive, with three extra facilities
    • 1input is terminated by either the introduction of a smart card, or the swiping of a magnetic card.
    • 2Data from a magnetic card read is stored in the reserved fields
    • 31f the (card entry mode) is non zero, this primitive does nothing. This allows logic to read a card only if the card is not already read.
      See also
  • [0498]
    A function requiring input of both “Tip Amount” and “Cash Out Amount” can input both using the same field.
  • [0499]
    Create a form as follows. Edit the PFIELD to indicate an input field.
      • PSTRING Name: Form
      • PFIELD
      • Create a function
      • Show(Tip, TipAmt, Form, 0)
      • Show(Cash, CashAmt, Form, 0)
  • [0505]
    Where “Tip” and “Cash” are strings. On the first call to show the display will prompt “Tip” and accept input into the TipAmt field. On the second call to Show the display will prompt “Cash” and accept input into the CashAmt field.
  • [0000]
    Show (string, field jorm, default)
  • [0000]
  • [0506]
    This primitive is specialised for displaying input forms. Two parameters (string and field) substitute with PSTRING and PFIELD in forms, allowing the same form to be used for multiple inputs.
  • [0000]
  • [0507]
    String to replace the PSTRING field on the form. <none> if unused.
  • [0000]
  • [0508]
    Field to replace the PFIELD field on the for.
  • [0000]
  • [0509]
    The Form may be selected from the list box- or alternatively by selecting Field->Value[X] taken from a field in the data base.
  • [0000]
  • [0510]
    A value of one (1) if the existing value of the field is to be displayed as a default, otherwise 0.
  • [0000]
    Reserved Data Dictionary Settings
  • [0511]
    The driver in the “target” makes direct use of some fields in the data dictionay. Using these table#/field# settings for other use will have strange results and is not recommended.
  • [0000]
    Table 1 (Transaction Table)
  • [0512]
    Fields in this table may be initialised to default values only. The first fields in the transaction table are reserved for (in order)
    • 1ROCNUM
    • 2Track 2
    • 3Track 1
    • 4Track 3
    • 5SPAN
    • 6Expiry Date
    • 7Customer Name
    • 8Protocol Status
    • 9Card Entry Mode
      Table 2 (Totals Table)
  • [0522]
    No reserved settings, however a fixed ten copies are available. Initialisation of fields to default values only.
  • [0000]
    Table 3 (Terminal Table)
  • [0523]
    This table is the basis of the build of terminal groups, and may be initialised from the Initial Data Table. There is always only one record in the table.
  • [0000]
    Table 4 (Issuer Table)
  • [0524]
    One record per issuer, with the current record selected automatically when a card is swiped.
  • [0000]
    Table 5 (Acquirer Table)
  • [0525]
    One record per acquirer, with the current record selected automatically when a card is swiped.
  • [0000]
    Table 6 (Card Table)
  • [0526]
    Fixed layout, Dictionary specification currently ignored.
  • [0000]
    Coffind Primitive
  • [0000]
  • [0527]
    Both LowField and HighField must be in the same table. This table is scanned for a column with the value ‘value’ between the two fields. The primfive is normally used to locate the CardTable Column for a card. The result variable is set to 0 if no match is found, or 1 if a match is found.
  • [0000]
    ColSelect Primitive
  • [0000]
    ColSelect(Column, Table, Reset)
  • [0528]
    Selects the relevant column of the table indicated.
  • [0000]
  • [0529]
    The column to use. The transaction table has only one column, the totals table has ten. The other tables (issuers, aquirers etc have one colum for each record in the corresponding initialisation data base
  • [0000]
  • [0530]
    For comparability, 0 (zero) selects the totals table. The tables are as follows
    • 1Transaction
    • 2Totals
    • 3lssuers
    • 4Acquirers
    • 5Card Ranges
  • [0536]
    If reset is 1 then all fields in the column are reset.
  • [0000]
    CommStat Primitive
  • [0000]
    • CommState(port, value, field)
    • port indicates the port to be tested
    • value indicates a value to compare and set the status accordingly.
  • [0540]
    field (optional) indicates a field to store ComsState Value. This function reads the state of the port store the value in field (if specified) and sets the current function result status to true if the value matches “value”.
  • [0000]
    Date Primitive
  • [0000]
    Date(commdnd, date-field, time-field)
  • [0000]
    • 1Read system date into date field and time field
    • 2Set system date from date field and time field
      see also
      Dates and Times
  • [0543]
    Daces & Times are special data types both are stored as special numbers.
  • [0000]
    Date Fields
  • [0544]
    A Date field is a two byte number, representing a date since 1Janl940 to 1Jan2110. Subtracting two dates reveals the number of days between the dates, dividing by 7 reveals the day of the week (Monday=O,Tuesday=1 etc).
  • [0545]
    When moving to or from a text field a date is converted to a text format of DDMMYY. If a format is used this may be converted to DD/MM/YY by using a currency symbol of/in the format. The text format of a date may be either 6 or 8 bytes long—showing the year as 2 or 4 digits.
  • [0546]
    Date Fields only contain valid dates. Since every date is stored as a day number, the storing the string 32/01/1980 will give is the acutal date 01/01/1980. If data is entered directly into date fields, then dates are corrected in this manner automatically. If you wish to check the was entered correctly, then enter the data to a text field, then move the value to the date and check it is equal to the string.
  • [0000]
  • [0000]
  • [0000]
      • Print(GetDdte,O)
      • ActualDate:=TextDate
      • Until ActualDate ==TextDate
  • [0550]
    The above example will continue to ask for a date until a valid date is entered.
  • [0000]
    Time Fields
  • [0551]
    Time fields may be either two or three bytes representing either the time of day to 2 seconds (two bytes) or 1/100 of a second (three bytes) accuracy.
  • [0552]
    Moving a time to a 2 byte integer gives the number of two second periods elapsed this day. Moving to a 1 byte integer extracs the 1/100s second fraction (up to 199) Moving to a value or larger integer extracts the total number of tics ( 1/100s sec) which have occurred prior to the time.
  • [0553]
    Moving a time to of from a text field results in either HHMIVISSFF when moving to a 8 or more byte field and HHMMSS when moving to/from a six byte field.
  • [0554]
    This text value may be formated with a format to give HH:MM:SS.FF
  • [0555]
    Moving values between data and time fields and other numeric types results occurs without conversion. Moving to and from text values results in conversion. See specic entries for conversion details
  • [0000]
    Dial Primitive
  • [0000]
    Dial (phone numberphone number)
  • [0556]
    The numbers specified must be fields. Immediately following each number field in the data dictionary must be a a timeout field then a retry field and then a mode field. The upstream prot is implied.
  • [0000]
    Do Primitive
  • [0000]
    Do (Function)
  • [0000]
    also known as
  • [0000]
  • [0557]
    This primitive is used to activate another script function as a subroutine call
    • Event Primitive
    • Event(Function,system event)
  • [0560]
    Sets the specified fuction to be actived whenerver the event occurs
    • Exit Primitive
    • Exit(Now?, Value)
  • [0563]
    This primitive is used to set the return value of the current function, and optionally, exit immediately.
  • [0564]
    The ‘Value’ is stored in the Calculation Result, which will be regarded by any calling function as a result.
  • [0565]
    If “Now” is true (is 1) exit will be immediate, otherwise the exit value will be established.
  • [0000]
    Func Number Primitive
  • [0000]
    Function#ffieldlnumber . bad number function)
  • [0566]
    Execute the function with the assigned function#. Typically this primitive will be used by a user function set to be activated by a Hot Key on the target device labeled “Fn” or “Function” or similar. Such a user function would prompt for a number and then call this primitive (Function#) with that number as a parameter.
  • [0000]
    See Function Activation.
  • [0567]
    The “Bad—Number—Function” is a function in the script to be executed if the no function matching the first paramter exists.
  • [0568]
    This is used to implement number functions—for example clearing memory might be function 1055. The user presses the “Function” hot key, then enters 1055 to execute the function.
  • [0000]
    To achieve this
  • [0000]
    • 1a function containing this primitive should created and set up under function activation to have the appropriate key code.
    • 2A function containing the appropirate action for the numbered function should be created and set up under function activation to have the approiate function number
  • [0571]
    The function number also returns the logical result of the request to call the numbered function. i.e false if no function exists, otherwise true.
  • [0000]
    If Else End Primitives
  • [0000]
  • [0572]
    The next primitive is executed. If true then all primitives between the if and the else are executed. If false all primitives between the Else and End are executed. If nothing is required between for false then Else may be ommited.
    • If ! (if with <not?> parameter)
    • Else
    • Optional in an If see above.
    • End
    • Marks the end of an If or While. See While End
    • KeyBd Primitive
    • KeyBd(mode)—(O=off/I=on)
  • [0580]
    Upon entering idle state, the action of the keyboard is determined by the last KeyBd command. The keyboard (except cancel) will be ignored if off was specified.
  • [0000]
    MAC Primitive
  • [0000]
  • [0581]
    All targets must support the storing and use of 4 64 bit keys.
  • [0000]
    mode I
  • [0582]
    Calculates a mac of the ‘message’and stores the value in the ‘field’ specified. Uses the ‘key’ specified. If the ‘message’ is 8 bytes in lenght only (or less) then a single DES encription only results.
  • [0000]
    mode 2
  • [0583]
    Stores the specied key into secure memory from ‘field’-.
  • [0000]
  • [0000]
  • [0584]
    The value “value” id divided by the divisor, and the remainder is the result.
  • [0000]
    e.g.—the following example would set the Data Field “Remainder” to 4. (25 divided by 7 has a remainder of 4.
  • [0000]
    Mod(25, 7)
  • [0000]
      • => Remainder
        Pin Primitive
        pin (field)
  • [0586]
    Retrieves pin block from pinpad. Not supported on all cardscript devices
  • [0000]
    Print(Display/Report, Part)
  • [0000]
  • [0587]
    The Display/Report may be selected from the list box—or alternatively by selecting Field->Value[X] taken from a field in the data base.
  • [0000]
  • [0000]
    • Values—0=all, 1 pre print/header, 2=body, 3=post print/footer
    • see Forms—end of Header/PrePrintt & Start of Footer/Post Print
  • [0590]
    The selected section (or all) of the display is displayed or, in the case of a report, printed.
  • [0591]
    With displays, any input fields will be accepted, however the Show Primitive is recommended for input operations
  • [0000]
    ProcDown Primitive
  • [0000]
    Procdown(protocol, port)
  • [0592]
    The specified protocol is started on the port specified. This function is normally used for downstream protocols such as an ECR. This function is intended for more advanced users and the protocol must specify its own success and fail functions.
  • [0000]
    Protocol Primitive
  • [0000]
    Prot (protocol, Function 1, Function 2)
  • [0593]
    The specified protocol is started on the bank corns (upstream) port. The current function execution continues. KeyBd(Off) is set (it may be overridden). If the protocol returns a value of zero, Function 1 will execute, if any other value is return Function 2 will execute. (A KeyBd(on) will automatically happen before either function.
  • [0000]
    Range Primitive
  • [0000]
  • [0594]
    Returns true if the value specified is >=min and <=max value
  • [0000]
    Repeat/Until Primitives
  • [0000]
  • [0595]
    Repeat sets the execution point for a following until
    • Until(Case) Cases are 0=False, 1=True
  • [0597]
    Executes the next primitive and if the result agrees with Case then the Repeats everything after the repeat primitive.
  • [0000]
    Report (Form, Function)
  • [0000]
  • [0598]
    First prints any pre print or header from “Form”. Then for each transaction in the batch calls “Function” and prints the details section of “Form”. After cycling throughout the batch, then prints any post print data from “Form”.
  • [0000]
  • [0599]
    The Display/Report may be selected from the list box- or alternatively by selecting Field->Value[X] taken from a field in the data base.
  • [0000]
  • [0600]
    A function to be executed before each detail section is printed. For any transaction in the batch for which the function returns FALSE will be skipped.
  • [0000]
    Restore Primitive
  • [0000]
    Restore(layout,field,secondary field)
  • [0601]
    This primitive is used to retrieve information from the Batch Area.
  • [0000]
  • [0602]
    This optional (“none” is permitted) parameter specifies which transaction layouts are considered for retreival.
  • [0603]
    WARNING! All records searched using a field other than RECNUM are actually retreived, changing the contents of the data fields in their layout. Using a value of “none” may have side effects!
  • [0000]
  • [0604]
    The primary search field. Searching will advance throught the Batch Area until a match is found.
  • [0000]
    Secondary Field
  • [0000]
    an optional (Use RECNUM for “none”) secondary search field.
  • [0000]
    Rom Function Primitive
  • [0000]
    Rom(valuelfield, Message)
  • [0605]
    Generally the parameter passed is passed directly though to the bios. The following values are assigned for portability % The message parameter is ignored unless otherwise stated.
  • [0000]
    1Go to ROM mode.
  • [0000]
    2Erase memory and return to Rom
  • [0000]
    3Start TIVIS download (from ROM mode).
  • [0000]
    4Store Rom Params.
  • [0000]
    • Uses Message and returns Success status.
      51-oad Rom Params.
    • Uses Message and returns Success status.
      6Activate Rom Edit.
    • Returns Success status. See ROM SETTINGS
    • see Also
    • What are ROM SETTINGS
    • Sub Heading
  • [0614]
    Normally target devices store programs in RAM memory, and are capable of loading these programs over the telephone Network. In order to acheive remote loading the device must store telephone number and other details required. The device must have a method of loading and/or editing these details.
  • [0615]
    Methods vary from device to device with information normally being obtained from the keyboard, a smart or magnetic card or some combination. Obviosly the information must be able to be set prior to the application loading.
  • [0000]
    Communication Between Rom & CardScript
  • [0616]
    Two possible reasons for CardScript to interact with the ROM Settings arise.
    • 1 The parameters may need to changed in a device already loaded with the CardScript application.
    • 2A CardScript application may need access to the ROM Setting values.
      Edit Rom Settings—Rom Function 6.
  • [0619]
    The desired method of allowing change to the settings is to use this function primitive call.(see Rom Function Primitive.) This primitive may not be supported by all Drivers and (check with the driver provider) but provides the only device independent method of implimenting the function. An advantage of this function is the operator sees the same interface as when configuring the terminal prior to loading CardScript.
  • [0000]
    Load Rom Settings—Rom Function 4.
  • [0620]
    This function is used to obtain the ROM settings in a Script.
  • [0000]
    Store Rom Settings—Rom Function 5.
  • [0621]
    A Script Program may load the Rom Settings with Function 4, allow editing of values and use this function to store the settings. It is recommened to use function 6 (edit) in place of this proceedure where available as this mechanism allow changing of device specific settings.
  • [0000]
    The Rom Communciations Buffer.
  • [0622]
    To provide a much device indepenance as possible using functions 4 and 5 CardScript defines a standard Communications Buffer Layout with a private area at the end. All Fields are ASCII.
  • [0623]
    The first three fields are assumed to be used for all communcications. 2 bytes connection mode. Lan Leased Line etc 4 bytes station/Lan Address
    • 8 bytes telephone prefix—eg “9,”
      Field 1 16 Bytes Terminal ID. The ID as seen by the software management system and not
    • necessarily other systems.
      8 bytes terminal type
      24 bytes phone number
      24 bytes connection string
      Save Primitve
      Save(transaction layout)
  • [0626]
    Saves the current transaction to the batch using the layout specified. A new Transaction Index is generated according to the method speified by the last TxnIdx: Primitive, with the new index stored int field(0,0) RECNUM. For details on RECNUM see Reserved Data Dictionay Settings.
  • [0627]
    The number of transactions (of the selected layout) which can be stored is returned. If zero is returned, then the save could not work! If 1 (one) is returned then no more may be saved. If two is returned then only one more may be saved, etc.
  • [0000]
    Store Primitive
  • [0000]
  • [0628]
    The store primitve stores the last received message, starting at byte <offset>, using the specified message layout. The function result status is set by the operation. (Set to FALSE if the store did not match).
  • [0000]
    Tots Primitive
  • [0000]
    Tots(valuer Field)
  • [0000]
    Selects the relevant totals column.
  • [0629]
    This primitive has been replaced by the ColSelect primitive. Old programs are automatically upgraded, since parameter 2 or LineTble, when zero, will select the totals table
  • [0000]
    TxnIdx Primitive. Set Transaction Index.
  • [0000]
    Txnldx (Field1,Field2,mode)
  • [0000]
    • Field1 is optional. If include the first two digits of the Index are set from this field.
    • Field2 specifies the the main field on which the Index is based. By default this is the ROC field.
    • the mode specifies how cardscript increments the Txn Idx.
    • 0=add 1
    • 1=Amex Style
    • 2=None. Incrimented by script.
  • [0636]
    This function would normally only ever be used in a start up function. The calculated value is always stored in the ROC field.
  • [0000]
    User Function Primitive
  • [0637]
    The user function primitive is used to call any of a range of functions. The functions call by user function are NOT standard.
  • [0000]
  • [0638]
    It is possible to extend the primitives available to cardscript. The extensions take to form of a block of ‘C’ code loaded with the Script. ‘C’ code, of course, has the restriction of being non portable.
  • [0639]
    The existence of these extensions is to allow extensions to a set of primitives to be tested without changing the core driver. Any extentions initialy tested by this means must be added to the set of primitives in a new release, otherwise the code calling them will never be portable.
  • [0000]
    Wait Primitive
  • [0000]
    wait(minutes, 100 msecs)
  • [0640]
    The current function pauses for then number of minutes+1 Oths of seconds specified. A delay of up to 1000 minutes (over sixteen hours is possible) and as small as 1/10 of a second.
  • [0000]
    While/End Primitives
  • [0000]
    • While(Case) Cases are 0 False, 1=True
  • [0642]
    The next primitive is executed. If the result matches Case then all primitives between the While and the End are executed, then we come back again to the While. If the result does not match Case then execution continues with the primitive following the End.
  • [0000]
  • [0643]
    Marks the end of an If or While. See also -.- If End For specific categories of primitives see
    • Communications Primitives
    • Data Entry Primitives
    • Displaying and Printing
  • [0647]
    For information on configuring CardScript for target device function primitives (advanced users only) see
    • Configure Function Primitives
    • For advanced users only!!
      Usage—Name Changes
  • [0650]
    Changing the name of a primitive or a primitive parameter will cause all scripts using the name change to be automatically updated. Both this type of change and any chages to the “infix” status of a function will have no affect on the driver and scripts will function without further change.
  • [0000]
    Usage—Adding, Deleteing, Changing Parameter Types
  • [0000]
    Parameter Settings
  • [0651]
    Each function parameter has the following possible catagories
    • 1A Field from the data Dictionary
    • 2Numeric Value—Which may be displayed as an index to a file 3A String
    • Any parameter may legally accept any combination of categories
  • [0655]
    Cardscript allows you to graphically enter your layout specifications. For details on Reciepts, ‘Reports, Displays, Messages, Protocols, and Transactions see Layouts Menu
  • [0656]
    Layouts are the main engine of any application. Although all layouts must bee brought into operation by functions, layouts also in turn launch functions and other layouts.
  • [0657]
    Form layouts, message layouts, and transaction layouts are similar in operation. All three are an arrangement of fields and strings called a field panel. For details see
  • [0000]
    Field Panels
  • [0658]
    All field Panels (Displays/receipts, messages and transactions) have a Panel Control box in common. The selection in the Panel Control box selects the action to take place when the left mouse button is clicked over the panel.
  • [0659]
    Additional controls are present of some panels, however, this box always contains
  • [0660]
    An add field—control with field edit box and pallete selector
  • [0661]
    Clicking on the p‘a’nel when [add] is selected adds a new field as displayed in the edit box
  • [0662]
    Before—clicking on the edit box to set the field to be added, select the approriate type of item in the “from pallete” drop down list box
  • [0663]
    Clicking on the edit box brings up either the Select Field Dialog or the Enter String Dialog, in accordance with the pallete selector
    • A dealt field control
    • Select [delete] and then click on the appropriate field
    • A select field Control
    • Select [delete] and then click on the appropriate field
    • Field Edditing
    • To edit any field, double click on the field
    • Forms (Displays and Reports)
    • see also Field Panel, Print Primitive, Show Primitive and Report Primitive
    • The Screen is Divided into four sections
      The Form (Display/Report) Panel
  • [0673]
    The panel is a Field Panel where the location of the of each field corresponds to the place actual data will appear on the display/printer
  • [0000]
    The Dashed Boundary
  • [0674]
    Depending on the Display/Report type, a dashed line will appear showing the limits of the display or printer. This boundary is drawn in accordance with the settings in the Tables/System menu and can be changed at any time.
  • [0000]
    Form Name
  • [0675]
    The display report name is used for reference to this screen and should contain a meaningful name.
  • [0000]
    Panel Control
  • [0676]
    In addition to the panel controls discussed in Field Panel, two additional controls are present.—<
  • [0000]
    <<End of Pre Print
  • [0677]
    Pre-Print fields appear with a grey background Select this item and click on the field after the end of the header section of the report.
  • [0678]
    Used in reports, the header section is printed once at the beginning of the report. The sections following the header will be printed once for each transaction in the batch. see Report Function for further details
  • [0679]
    Used in receipts (see Print Function for futher details) used to divide the receipt inot sections
  • [0000]
    Start of post print
  • [0680]
    Post-Print fields appear with a grey background, and can only be distinguished from Pre-Print fields if there are fields in between. (As would normally be the case.)
  • [0681]
    Select this item and click on the first field of the post print section of the report.
  • [0682]
    Used in reports, the Post-Print section is printed once at the end of the report. see Report Function for further details
  • [0000]
    Display/Report Type
  • [0683]
    The types are
    • Display—layout will always appear on the display, and in scribe will have a border reflecting display width and number of lines
    • Secure Display—reserved for future use
    • Printout—layout will always appear on the printer, and in scribe will have a border reflecting printer width
      Soft Keys
  • [0687]
    The Soft Keys Button allows selection oof a soft key set. see
  • [0000]
  • [0000]
    Output Messages
  • [0688]
    A messages buffer is built from fields in the data dictionary, and from strings in much the same way a printout is build. However, in messages, all data may be represented in forms other than ASCII. (see “the message engine”. Formats may be used to specify data within the selected representation.
  • [0000]
    Input Messages
  • [0689]
    Messages are also used to specifiy how data is transfered from a received buffer and stored in data fields.
  • [0000]
    see also
  • [0000]
    The Message Engine (Processor)
  • [0690]
    The message engine is used both to transfer information both from data fields inot a message buffer, and from a message buffer to data fields
  • [0000]
    see also
  • [0000]
    Message Data Mapping
  • [0691]
    Every field in a message buffer is converted from the type in the data field, to the representation of in the message buffer. For “Forms” all data in the buffer is Ascii, but in other messages the data may be any of the following
    • Ascii
    • Ascii Representation
    • Strings and Text Fields
  • [0695]
    Strings & text fields are simply copied. If the source is shorter then the destination, spaces are used for padding
  • [0000]
  • [0000]
    Integer to Asch
  • [0696]
    For one & two byte integers, the binary value is converted to its string equivalent and then formated acording to any format specified. Larger inger conversion may appear in a later release
  • [0000]
    Ascii to Integer
  • [0697]
    Again limited to 1 and two byte integers, the value of the text is calcuated and stored in the integer.
  • [0000]
  • [0698]
    As for integer.
  • [0000]
  • [0699]
    Dates are converted to either DDMMYY or DDMMYYYY if the Ascii field is longer than 7. Formating is applied on convesion to ASCII only.
  • [0000]
  • [0700]
    Times are converted to either HHMMSS or HHMMSSFF (where FF is the fractions of a.second in hundredths) if the Ascii field is longer than 7. Formating is applied on convesion to ASCII only.
  • [0000]
  • [0000]
    Hex Represntation
  • [0000]
  • [0701]
    To Hex: The data is coverted to a BCD string and then expaned
  • [0000]
  • [0702]
    The binary value is conveted directly to Hex. eg a one byte value set to 35decimal (23 hex) would be conveted to two bytes—characters' (O32) and ‘3’ (O33) representing the hex value 23.
  • [0000]
  • [0000]
    Binary Represnation
  • [0000]
  • [0703]
    Binary representation of integers is High Byte . . . Low Byte. As a binary value. No Actual conversion takes place
  • [0000]
  • [0704]
    Binary respesnation of Text is to assume the text is a hexadecimal string and convert this to binary. To get an exact copy of the string use Text Representation.
  • [0000]
  • [0000]
    BCD Representation.
  • [0705]
    The Data is converted to the BCD data type.
  • [0000]
  • [0706]
    Formats are used for specifying exactly how data will be represented
  • [0000]
  • [0707]
    Any time the data lenght is less than the field width, the justification will be used to decide where the data is placed.
  • [0000]
    Allowed Characters
  • [0708]
    Specifiies the type ot characters allowed during input.
  • [0000]
    Minimum Characters
  • [0709]
    Specifies the minimum characters allowed for entry to a field.
  • [0000]
    Maximum Characters
  • [0710]
    Specifies the maximum characters allowed for data entry, and the maximum displayed characters on output.
  • [0000]
    Input Window
  • [0711]
    A non-zero value in this field specifies input will occur within a window. e.g A 24 character text field may be input using a 10 character window because of limited display space. Note that only ten characters of the input would then be visible at any one time.
  • [0000]
    Input Validation
  • [0712]
    A function may be specified here to valid input using this format. The validation function may store the current input using the ->(res) primitive. See also the Console Primitive command 4.
  • [0713]
    Note that an input validation function MUST NOT do any displays, as the current display would be overwritten.
  • [0000]
    Suppress Leading Zeros
  • [0714]
    Check here to suppress leading zeros in numeric fields, or leading spaces in text fields
  • [0000]
    Decimal Places
  • [0715]
    Select the appropriate number of places, and the character to use as the decimal indicator. Selecting the decimal (from ‘.’ or ‘,’) also determines the character for thousands separation. (The opposite character to the decimal is used for thousands.
  • [0716]
    Check the box to require keying of the decimal indicator during input. If this box is left unchecked, data 1.00 (. as decimal) would be input as 100, cash register style.
  • [0000]
    Auto OK
  • [0717]
    If this box is checked, when the maximum characters are entered, input will be concluded.
  • [0000]
  • [0718]
    The thousands separator(as determined under decimal places) will be automatically inserted.
  • [0000]
    Password Mode
  • [0719]
    The first character of the currency symbol will be be displayed in each position, in place of the actual character entered.
  • [0000]
    Currency Symbol
  • [0720]
    Specify if the currency symbol is to be displayed. One or two characters may be entered. If the value is two digits, the digits are legal hex digits then these will specify a the character. e.g. 41 would specify the characters', as would a single A character.
  • [0721]
    This field as has other uses.
  • [0722]
    The separator for date & time fields is the first character. For time fields the second character is used to separater the hundreths of seconds when displayed
  • [0000]
    Lenght Indicator
  • [0723]
    In additon to the data, the data length is to be included. The number of digits to use may be 1,2 or 3. The lenght may be before (pre) the data or trailing (post). As an alternative to a numeric length specification the currency symbol may be used to indicate the end of a variable lenght field
  • [0000]
  • [0000]
    • lenght as 1-5abcde is a five character field
    • lenght as 2- 05abcde is the same field
    • currency symbol as ‘:’ and use currency selected
      • abcde: is the same field again
    • Pad BCF with F
  • [0729]
    Check here for BCD fields of odd lenght to be filled with a trailing F nibble. If unchecked a leading zero nibble would be used.
  • [0000]
  • [0730]
    Two other layouts types are also available
    • Bitmaps
    • Protocols
  • [0733]
    Protocols describe message flow both from and to the target device. The top line specifies outgoing messages and the other lines display possible incoming results. A protocol consists of lines and sections.
  • [0000]
    Request Line
  • [0734]
    At the start of each section is a line 1 (optional for the first section) which describes the outgoing message. This is the request line.
  • [0000]
    Response Lines
  • [0735]
    Lines 2, 3 and above define actions to be taken when a response is received. These are the response lines. A response may be a data received or a time out. When a timout occurs the first line with a timeout will be selected, any other line with a timeout will never be used. When data is received, all lines beginning with a message are tested to see if received message matches the requirements.
  • [0736]
    The first item on each response line must be either a message or a timeout.
  • [0000]
    Protocol Screen Editing
  • [0000]
    Adding Entries
  • [0737]
    Select the desired item to add, then click on the display at the desired location
  • [0000]
    Splitting Sections
  • [0738]
    A section may be split on line 1. Click below the line slightly to the left of the field to become part of the second section.
  • [0000]
    Adding to a Line
  • [0739]
    When adding fields click on the field that will be after the new field. To add to the end of a line click about 3 spaces beyond the end of the line. Always click on the desired line.
  • [0000]
    Inserting a line.
  • [0000]
    Click where the new line should start
  • [0000]
  • [0740]
    After entering a Retry, the retyr field will be selected. Or you can select the retry later. Once a retry is selected the <<set retry>> and <<set skip>> commands can be used to set the points where execution should move in the event of either a retry or the retry count being exceeded. Note, retry can only move back and skip can only move forward. For those with color displays, the retry arrow is green and the skip arrow is drawn as red. You can't put a retry/skip on line one.
  • [0000]
    Identifying Input Messages
  • [0741]
    The first field of each input line is used to select when the input is appropriate. The following possibilites are catered for
  • [0000]
  • [0742]
    The input line is selected when the a message begins with the specified character
  • [0000]
  • [0743]
    The incomming message is matched against the message specified.
  • [0000]
  • [0744]
    A timeout line will automatically be selected in response to an incoming timeout.
  • [0000]
  • [0745]
    If the function returns true the message is matched. The Store Function.
  • [0000]
    Functions Launced By Protocols
  • [0746]
    Within protocols it is possible to launch functions for various reasons, particularly to store complex messages and select options.
  • [0747]
    Such functions should NOT halt operation, either by WAIT(or for input or any other event. Should a function attempt to do so, subsequent functions launched from the protocol, including the “good” and “bad” functions, will execute before the function resumes.
  • [0748]
    Delay any inputs until the good or bad functions at protocol end. If you are an expert user and must do an input, make it the last command in the function and exersize caution.
  • [0000]
    Repeated Messages
  • [0749]
    A protocol may involve repeated messages. That is, after storing the data from an input message, another similar message will be received.
  • [0000]
    Fixed Number of Repeat Messages
  • [0750]
    If the number of times a message is to be received is fixed then the following approch may be used
    • <Msg><Retry(nn)>
      Where nn is then number of messages expected
      Variable Number of Repeat Messages
  • [0752]
    If the number of times the message will be repeated will vary, i.e a flag in the message indicates that a repeat message will follow, then the following technique is recommended.
    • use an input line with <Function><Retry(O)>
  • [0754]
    This will cause a loop whilst the function returns true. From the function, use the store primitive to save the data and return true if another message is expected
  • [0000]
    Layout Primitives
  • [0755]
    Layouts use the following elements as building blocks
    • Putting it all together
    • Build Menu
    • Build Target Group Files
    • Builds the font and conf files ready for program execution
    • Build Script as Fragment
  • [0761]
    Builds a reduced script for loading either onto a smart or through the communciations network, for describing a particular operation which may be chenged without loading a new program.
  • [0000]
    Build Secure Prompts
  • [0762]
    Builds the list of secure displays and associated strings for loading into a secure display.
  • [0000]
    Run Simulation of Build
  • [0763]
    Activates the terminal simulator program see also
  • [0000]
    Files Produced By Build
  • [0000]
    Font Files
  • [0764]
    xxx is the number of the font. Currently always zero
  • [0000]
  • [0765]
    Characters O . . . 127. Bytes are dots across. First byte is top row. If more than 8 dots across, then the next byte continues the dots
  • [0000]
  • [0766]
    Characters 128.255, using the same format as theTfile
  • [0000]
  • [0767]
    Characters O . . . 1 28. Bytes are up and down. First dot is top left (bit 0 of byte 1) then dots down the character.
  • [0000]
  • [0000]
    Script Fragrments
  • [0768]
    Script fragments are small scripts (usually <256 bytes) built separately to a main program. Theses scripts may then be loaded into the terminal (either from a smart card or as part of a message) in order to specify operation of changeable program feature
  • [0000]
    A Fragment for User Authentification
  • [0769]
    A Smart Card could contain a program fragment specifying how the terminal should check the user of the card is the real owner. Then cards may be issued with varied scripts such as
  • [0000]
    Input & Check PIN
  • [0770]
    Print A Slip and request a signature Do nothing—no check
  • [0000]
    A Fragment for Communications Protocol
  • [0771]
    A server could have a iist of communications protocols or various networks. Then the terminal could dial the server and request the relevant fragment for a particular network(either because the terminal has no information on the network—or the exsting protocol no longer functions), allowing the terminal to operate on a new or changed network with obtaining a complete new application.
  • [0000]
  • [0000]
    File Menu
  • [0000]
    Configure Menu
  • [0772]
    The configure menu is greyed on standard level Scribe. The functions available are for the use of advanced users only. Generally within an Organisation using CardScript either one master user will be placed in charge of setting configurations or configurations will be set by an external consultant.
  • [0773]
    The configuration options are
  • [0000]
    Configure Simulation
  • [0000]
    Host Comms
  • [0774]
    Select a comm port for the simulator to use for modem communications. If none are available select “none”. Selecting “none” precludes testing comms facilities
  • [0000]
    Terminal Group
  • [0775]
    The Build process creates serveral build files one for each terminal group. The setting chosen here determines which build file will be used for simulation.
  • [0000]
  • [0776]
    The simulator does not use a real card reader. Instead it supplies card data from this table. Enter card data as required for up to eight test cards.
  • [0777]
    To provide the simulator with information on this PC and to create test “Cards”.
  • [0000]
    Configure Targets
  • [0778]
    A number of target machines may be described to the cardscript system. The information about the target machines is used in various places throughout the scribe system to present information in a manner appropriate to a currently selected “target” machine. see System Record information for setting a Current target.
  • [0000]
    Object Types
  • [0779]
    The target machine is descibed by arranging an number of “objects” on this panel. Their is one of each of the display, printer, and reader objects, and as many button objects as are appropriate.
  • [0780]
    The display object is used to specify the display configuration in lines and columns. This object should be dragged to an approriate loaction in the window.
  • [0781]
    The printer object is used to specify the print width columns. This object should be dragged to an approriate loaction in the window. The number of lines setting bears no relation to the number of lines on a printer paqe, this field determines how many lines will be available for viewing during simulation.
  • [0782]
    The reader object is used to describe which area of the window will be used to display buttons for simuation of a card reader. This area bears no relationship th an actual card reader. Draq this object to an otherwise unused area of the window.
  • [0783]
    Any number of button objects. The object correspone to the push buttons on the target device. Five different button styles are available. Confiqure these styles as required. When a style is changed, all buttons of that style will change in appearance. Keycodes returned should match those returned by the actual terminal B10S. Use the KeVMap Primitive to force the map these codes to the codes required by the actual application.
  • [0784]
    For describing the various hardware platforms to the system
  • [0785]
    For designing Tables Screen Layouts and Contents used on the PC with Scribe
  • [0786]
    For designing the Data Dictionary used in the Target Device
  • [0787]
    For Specifing the functions available within the target device.
  • [0000]
  • [0000]
  • [0000]
  • [0000]
    • “−>“(goes to) primitive: <goes to primitive>
    • “KeyBd”: <KeyBd Primitive>
    • “refer”:<ColSelect Primitive>
    • “target”: the PC, EFTPOS terminal, PiNpad or cash register which will be used to run the
    • developed application.
    • -> (res): <result goes to primitive>
  • [0794]
    Batch Area: Storage area of memory. Used for storing transactions and any other miscelanous data. Also may be thought of as file storage.
  • [0000]
    bitnumbering: <Bit Numbering>
  • [0000]
  • [0000]
    • CardEntryMode: <Card Entry Mode>
    • ColSelect primitive:
    • Commands for Memory Cards: <Commands For Memory Cards>
    • Console Primitive: <Console Primitive>
    • Data Dictionary Field Atributes: <Data Dictionary Field Attributes>
    • Date & Time Fields: <Dates and Times>
    • eserved data dictionary fields:
    • Field Panel: <Field Panels>
    • Forms -end of Header/PrePrinft & Start of Footer/Post Print:
    • <Forms>
    • Function Action: <Function Action>
    • Function Actions: <Function Actions.>
    • Function Primitive Catagories: <Function Primitive Catagories.>
    • Function Primitives: <Function Primitives>
    • HEX: . Digits 0.9 and A.F
    • Initial Data Field Atributes.: <Initial Data Field Attributes>
    • KeyMap Primitive: <KeyMap Primitve>
    • PFIELD: special field for use on Forms. In place of this field a supplied parameter field will be displayed
    • Print Primitive: <Print Primitive>
    • PSTRING: special field for use on Forms. In place of this field a supplied parameter string will be displayed.
    • RAD: Application Development (especially used with ‘tool’)The process of defining a program in a very short time by starting the progfram definition wtih the user interface.
    • Report Primitive: <Report Primitive>
    • Reserved Data Dictionary Settings:
    • Reserved Data Dictionay Settings: <Reseved Data Dictionary Settings>
    • Show Primitive: <Show Primitive>
    • Smart Card Type Code: <Smart Card Type Codes>
    • System Table Settings: <System Table Settings>
    • Txnldx Primitive: <Txnldx Primitive>
    • Windows: popular operating system for PCs. based on an event driven architecture.
  • [0825]
  • [0000]
    Bios Objectives
  • [0826]
    The objective of the Cardsoft BIOS is to make all devices used for running Point of Sale software compatible with CardScript programs.
  • [0000]
    Bios Usage
  • [0827]
    The Cardsoft BIOS specification is designed to allow the creation of portable programs for Payment Terminals. Any given implementation of the BIOS will encompass its own “look and feel” which, in turn, is imparted to applications using the system. This is possible since the BIOS specifies what must be achieved by low level functions, rather that the manner of achievement, This means that not all implementations of the BIOS are equivalent and there is scope for vastly different performance and operational convenience whilst still maintaining BIOS compatibility. As an example, the BIOS itself does not specify how such things as how cursors and editing functions are implemented, there is simply a call specifying display this field and allow it to be edited. Thus the field editing ruies are determined by the individual BIOS implementation. One brand of equipment over type may be standard, on another insert may be the default.
  • [0828]
    This leaves individual implimentors with the ability for creativity and a framework which allows for the performance and convenience of their programmers to be a product advantage.
  • [0829]
    Also supplied in addition to the core BIOS are some implementation routines. These are supplied in source code as a starting point for actual implementation. However the code in these routines is not applicable to all hardware configurations and would expect over time to be modified in any given implementation.
  • [0830]
    The BIOS described in this manual represent the interface between Cardsoft EFT applications (including the driver for CardScript) and an EFT terminal, however the specification is general purpose in nature and may in future be used to support other systems. This manual assumes CardScript is to be supported and is geared to assist in achieving this goal. In addition to the functionality described here the EFT device must have its own “bootstrap” system. Where Cardsoft applications are being added to existing products a software module which interfaces between routines described here and the existing driver software can easily be produced. This BIOS specification remains the property of Cardsoft.
  • [0000]
    Utilising Existing Operating Systems
  • [0831]
    When first adding CardScript to a device, some level of BIOS or operating system will normally be already in place. In many cases it is desirable to add CardScript to devices originally developed years prior with well tested hardware device drivers. In these instances the BIOS will constitute an interface between the existing operating system and the CardScript driver. The BIOS may then be linked with the Driver and the combined application loaded as one conventional application.
  • [0832]
    The BIOS is designed to be able to be placed as a layer above any pre-existing operating system, and be loaded together with the Driver program an one application to devices installed in the field.
  • [0000]
    New Products
  • [0833]
    In the case of new products, created for use with CardScript, a purpose build BIOS will minimise memory requirements and speed time to market.
  • [0000]
    Steps To Implementation
  • [0834]
    The steps in implementing the Cardsoft BIOS are as follows. Check the BIOS library supplied with this manual is correct for your microprocessor development tools. Other versions of this library for other development environments may be obtained from Cardsoft.
  • [0835]
    Choose appropriate optional code. In order to simplify implementation of the BIOS sample code is supplied for some typical hardware configurations types providing higher level functionality and simplifying installation. It is recommended to make use of this software initially, and replace code as desired once the system is operation on the target hardware. Use supplied outline “main.c” and compile & link.
  • [0836]
    Add routines to eliminate unresolved externals. Use empty routines supplied for routines to be supplied later. It is recommended to initially include real keyboard and display routines and then add others.
  • [0000]
  • [0000]
    Event Driven Structure
  • [0837]
    Applications constructed to run on the Cardsoft BIOS must be event driven. This allows the BIOS or operating system to have control during idle periods. When an input event occurs, the application is called to process the input, and then returns to the BIOS/operating system. The application sets which routine will handle each message and what messages are enabled.
  • [0838]
    This event driven structure allows the BIOS to operate as an interface layer to event driven operating systems without problems. Where the underlying structure is not event driven This enables the BIOS functionality to be matched by either low level BIOS code or by a high level operating systems ensuring maximum portability of Cardsoft application, and enabling sophisticated underlying structures to be utilised where present. The event driven structure of the system means that applications do not contain a “main” procedure. Applications have an init-application(routine which sets up a table of routines addresses to bo called in the case of external events occurring.
  • [0000]
  • [0000]
    Callback Control—Input
  • [0839]
    The BIOS must maintain a callback address table with four entries for each input/output file. Associated with each entry in the table is an enable status. When the corresponding event occurs a callback should be made using the address from the table. Each callback contains an optional Code and Message (see below). The BIOS should not issue a second callback while another callback is in progress. This can lead to race conditions.
  • [0000]
  • [0840]
    For porting the Cardsoft Bios to a new machine see
  • [0000]
    Low Level Interface
  • [0841]
    The low level interface represents the routines that must be custom written when porting CardScript to a new device. These routines assume that the standard Console module, or equivalent are used. Use of these modules eliminates most of the work in implimenting the Cardsoft Bios, but postpones fine tuning the Bios to make use of Specific hardware in the most efficient manner.
  • [0000]
    Standard Modules
  • [0842]
    The following modules irriDliment the high level interface
    • console.c
    • callback.c
    • math.c
  • [0846]
    To impliement the low level interface, a single module may be created interfacing the foiling routines to the actual hardware or existing drivers. the categories of routine are
    • Low Level Display
    • void dispbin(uchar ch)
  • [0849]
    Display characher ch at current cursor position and advance cursor one place
    • void cleardisplay( )
    • void dispStr(uchar *str,int len)
    • continuous dispbin for lenght of str.
    • lenght of str is either len characters, or if len=−1, then
    • str is null terminated.
    • uchar dispScroll(uchar direction)
  • [0856]
    Directions are
    • 1 left
    • 2right
    • 3up
    • 4down
  • [0861]
    Each call is a request to scroll one place in the specified direction. Thje result indicates the sucess of the request (1=OK, 0=can't do)
  • [0000]
    Low Level Printer
  • [0862]
    The only printer routine is low level. see
    • Printer
    • void prch(uchar ch)
  • [0865]
    This routine simply prints the character “ch” on the printer device.
    • Special codes are as follows
    • OA (10) end of line
    • OC (12) end of form. Feed I ines as required for tear off of receipt
      10 General Routines
    • uchar softKeyBase(uchar select)
  • [0870]
    By convention returns V for a paramter of 0, and ‘a’ for a paramter of 1. Change these to indicate actual key values for soft key sets
    • buz
    • void buz(int freq, int duration)
  • [0873]
    The following routines must have the code inserted to call the low level drivers correctly.
  • [0874]
    All routines work with a comfile number. Number 0 is the default and is used for the modem. Number I should be the auxiliary com port, if present. Number 2 is the second auxiliary (again if present) etc.
  • [0000]
  • [0875]
    This routine sends block of characters to the specified port. If low level drivers (such as those used with HDLC) require the block at one time then you will need to call those drivers directly from here. If the target device supports only character mode communications, then the “sendcom” routine may be called once for each character.
  • [0000]
    void sendcom-msg(int comfile,uchar *buf,int countOfChars)
  • [0000]
    • {
    • }
  • [0878]
    A singe character is transfered to the specifed port.
    • /* individual cons character send routine */
    • void sendcom(int comfile,int ch)
    • {
    • }
  • [0883]
    This routine is used to start the dial process. “num1” is to be dialed “cnt1 times, then if this fails, “num2” is to be dialed “cnt2” times. “Mode” indicates the communction mode to be used. These paramters are under direct control of the application programmer, but by convention
    • model=async, 2=HDLC
    • /+MODEM */
    • void dial(uchar *num1,uchar len1,uchar cnt1 ,uchar *num2,uchar len2,uchar cnt2,uchar mode)
    • {
    • }
  • [0889]
    The equivalent of the ATH command on a hayes modem.
    • void hangup( )
    • {
    • }
    • txstate( )
      uchar txstate( )
  • [0894]
    This return should return a status as follows
    • 0=busy
    • 1Ready
    • 2Reserved for errors, no currently used
      Real Time Clock
  • [0898]
    The real time clock is red & set with the biosDateTime( ) routine
    • biosDateTime( )
    • unsigned int biosDateTime(command , buffer)
    • Command (1=read Dateltime, 2=set date & time from buffer
    • TPDU—The smart card interface
    • uchar driveTPDU(uchar 11, uchar 12,uchar *Command,uchar *sendbuf,uchar *receiveBuf)
  • [0905]
    This routine implements, both the Scribe TPDU and SmartCard primitives. To decide which is call is being made, the Command parameter must be tested.
    • Command ==NULL, SmartCard Primitive
    • 11, and 12 are the parmaters. Refer Scribe.hlp for details
    • Command!=NULL−TPDU primitive
  • [0909]
    This a direct implementation of the scribe TPDU primitive,. with L1 as the length of the sendbuffer, and L2 the length of the receive buffer.
  • [0910]
    If L1 is non zero, there is data to send to the card. If L2 is non ZERO, then data from the card is required.
  • [0000]
  • [0911]
    Return zero, unless the function is used as the SmartCard Primitive, and a result is required.
  • [0000]
  • [0912]
    Cardscript requires the target device to have a 100 millisecond timer. This timer should may a call to the script routine “time-tick( )”
  • [0913]
    It is recommended not to make a call direct from the hardware timer interupt. This would result in actions launched by time ticko to execute with interrupts off, giving some very strange results.
  • [0914]
    Instead set a flag in the interupt handler and have the event loop clear the flag and call time-tick( ) (if using an interrupt handler).
  • [0915]
    The script driver includes the routine “start-bomb( )” which may be called by the bios interface if required
  • [0000]
    The Font File
  • [0916]
    The font file consists of sets of entries as follows
    • 1 Character code—1 byte
    • 2Width—1 byte
    • 31-leight—1 byte
    • 4 Bitmap
  • [0921]
    The bitmap is arranged as follows
  • [0922]
    For each row of height as many bytes as needed for the bits (1 for width <=8, 2 for width <=16 etc).
  • [0923]
    Left most bit in the MSB of the first byte.
  • [0924]
    The file is appended with a block of three zero bytes. (Code, width, Height=O) and no bitmap.
  • [0000]
    For fine tuning an operational Bios see
  • [0925]
    BIOS Specification (High Level Interface)
  • [0926]
    By Catagory Routines are:—
    • Console (Display & Keyboard)
    • Input
    • Sequential (Non event driven)
  • [0930]
    Since the non event driven machine must be made to appear event driven, the bios interface must include the main line and call the application to handle any events
    Sample main( )
    init - hardware( ); /* perform any hardware specific
    initialisation */
    init - applications( ); /* call to routine in module DRIVE */
    if(event) /* test for event*/
    { clear - event( ); /* clear event status */
    handle-event( )*/ call cardscript event handle - see

    Events and Handlers
  • [0931]
    The following list of events should be catered for
    • Events List
    • Console
    • If the high level console is used. Keyboard events are reduced to a single call-Process—
    • void process-key(uchar key-code)
  • [0936]
    All that is required by the implimentor is to may key codes from the actual machine to the those to be seen by the cardscipt application.
  • [0937]
    Please note that the application programmer has the ability to remap the keys sing cardscript.
  • [0000]
    Special Key Codes
  • [0000]
    • OA “Enter” or “OK”. (Completion of input)
    • 0B “Clr′ or backspace
    • 0x1B Cancel
  • [0941]
    The only other console input is the magnetic card reader.
    • Please use
    • callback(Console, 3,<unused>,buffer,<unused>);
      • (use 0 (zero) for unused parameters. or
    • process-card (<unused>, buffer)
      Magnetic Card Read Buffer
  • [0946]
    The buffer may include any or all of the following sections. They must appear in order.
  • [0000]
    Section I (optional)
  • [0000]
    • Identifier byte (001)
    • Track 1 Data—all ascii values
      Track2 (optional)
    • Identifier byte (002)
    • Track 2 Data—all ascii values
      Track 3 (optional)
    • Identifier byte (N03)
    • Track 3 Data—all ascii values
      End of data marker
    • Identifier byte (0x0)
      System Events
  • [0954]
    For each event, make a call to the routine
    • void systemEvent(uchar event)
      Comms Events
    • Character comms
    • callback(Port,1,Character,NULL,O)
      Message based comms
    • callback(port,2,0,BufferAddress.MessageLenght)
      Dial or Tx Finished
  • [0959]
    When any operation which made the communications port busy has finished, it should tell the script driver by the following call
    • callback(port,4,0,NULL,0)
    • see also
      Event Driven Input
  • [0962]
    Please consult Cardsoft for further information
  • [0000]
  • [0000]
    Memory Management
  • [0000]
    The MEMPTR type
  • [0000]
    External Memofy
  • [0963]
    Often target devices have 8 or 16 bit microprocessors which can address limited memory without the use of paging. To allow access to such memory, the concept of External Memory has been defined
  • [0964]
    It is not assumed that this external memory is directly addressable by the CPU, instead this memory is accessed only via the memory management functions.
  • [0965]
    The script, the data dictionay fields, any optional fonts and the file storage area are all stored in “external” memory. These areas of external memory are allocated numbers as used in the getbase(function,
  • [0966]
    A type MEMPTR is used to address this external memory. In the include file custom.h the type MEMPTR must be defined. If has less than 64k of memory allocated amongst the external memory areas MEMPTR could be defined as unsigned integer. If the memory is larger than this than MEMPTR will normally be defined as “long”.
  • [0967]
    Each block of external memory must APPEAR to be continuous. That is incrimenting a MEMPTR with the c++operator must always generate a pointer to the next byte of the area.
  • [0968]
    The memormy management routines must map these virtual memory addresses in to real memory addresses
    • getbase(base)
  • [0970]
    The function getbase returns the virtual memory address of each of the following blocks of memory
    • 1 The smart card execution buffer
    • 2The Script area—(includes the initialised data dictionary tables
    • 3The Uninitialised data dictionary table area
    • 4The file/ batch area
    • getDataByte
    • Returns the byte at the virtual address
    • uchar getDatalnt(offset)
  • [0978]
    Returns the two byte value at the virtul address specified. The format of the two byte value is always Low/High regardless of the byte ordering of the microprocessor.
  • [0000]
  • [0000]
    • void getscripfflata(uchar *bufferMEMPTR offset,int size)
    • Transfers data from the buffer to the virtual address “offset”
    • setScriptData
    • void setscripfflata(uchar *buffer,OFFSETTYPE offset,int size)
  • [0983]
    Either set external memory to NULL bytes or to a copy of a buffer buffer is the memory buffer in the standard memory area OR if NULL then the operation is like a memset
    • add notes on offset type
    • size is the number of bytes to store
    • For customising the cardscript command set set
    • Adding Function Primitives
  • [0988]
    All function primitives have up to four parameters. Each Parameter is of either one or two bytes length.
  • [0989]
    Numeric value parameters of values O . . . 1 27 are one byte in lenght. Numeric values of greater lenght and in the general format, with a maximum value of 4999.
  • [0990]
    All other parameters are in the general format, sixteen bits High order first
    • bit 15 set—numeric value all other 15 bits contain the value high nibble=0x5 next three nibbles give string number.
    • all other values high byte=table, low byte=field.
  • [0000]
  • [0000]
  • [0000]
  • [0000]
    • “start bomb( )”: <start-bomb>
    • “time-tick( )“: in the script-driver for processing 1/10 second time ticks
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5336870 *May 26, 1992Aug 9, 1994Hughes Thomas SSystem for remote purchase payment transactions and remote bill payments
US5479643 *Aug 22, 1991Dec 26, 1995John Fluke Mfg. Co., Inc.Virtual machine programming system
US5553291 *Sep 14, 1993Sep 3, 1996Hitachi, Ltd.Virtual machine control method and virtual machine system
US5590281 *Oct 28, 1991Dec 31, 1996The United States Of Americas As Represented By The Secretary Of The NavyAsynchronous bidirectional application program processes interface for a distributed heterogeneous multiprocessor system
US5708838 *Sep 8, 1995Jan 13, 1998Iq Systems, Inc.Distributed processing systems having a host processor and at least one object oriented processor
US5745886 *Jun 7, 1995Apr 28, 1998Citibank, N.A.Trusted agents for open distribution of electronic money
US5923884 *Aug 30, 1996Jul 13, 1999Gemplus S.C.A.System and method for loading applications onto a smart card
US5926631 *Aug 15, 1997Jul 20, 1999International Business Machines CorporationNetwork computer emulator systems, methods and computer program products for personal computers
US5931917 *Sep 26, 1996Aug 3, 1999Verifone, Inc.System, method and article of manufacture for a gateway system architecture with system administration information accessible from a browser
US5935249 *Feb 26, 1997Aug 10, 1999Sun Microsystems, Inc.Mechanism for embedding network based control systems in a local network interface device
US6021275 *Aug 5, 1996Feb 1, 2000General Magic, Inc.Object code structure and method for translation of architecture independent program implementations
US6199160 *Apr 6, 1994Mar 6, 2001International Business Machines CorporationComputer system and method for performing multiple tasks
US6308317 *Oct 24, 1997Oct 23, 2001Schlumberger Technologies, Inc.Using a high level programming language with a microcontroller
US6934945 *Mar 16, 1998Aug 23, 2005Cardsoft, Inc.Method and apparatus for controlling communications
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7506037 *May 13, 2008Mar 17, 2009International Business Machines CorporationMethod determining whether to seek operator assistance for incompatible virtual environment migration
US8122109 *Feb 4, 2009Feb 21, 2012International Business Machines CorporationMethod and system for dynamic virtual environment migration
US8682963 *Jul 27, 2009Mar 25, 2014Sony CorporationClient device, information processing system and associated methodology of accessing networked services
US8806059 *Apr 5, 2007Aug 12, 2014Juniper Networks, Inc.Rule tree for network device
US8990109 *Mar 17, 2010Mar 24, 2015Global Refund Holdings AbInterface module, system and method
US20090288083 *Nov 19, 2009International Business Machines CorporationMethod and System for Dynamic Virtual Environment Migration
US20110106882 *Jul 27, 2009May 5, 2011Sony CorporationClient device, information processing system and associated methodology of accessing networked services
US20120011008 *Mar 17, 2010Jan 12, 2012Global Blue Holdings AbInterface module, system and method
U.S. Classification709/238
International ClassificationG06Q20/18, H04L29/06, G06F9/455, G06F15/173, G07F19/00
Cooperative ClassificationG07F19/20, G07F19/206, H04L29/06, G06Q20/18
European ClassificationG06Q20/18, G07F19/20, G07F19/206, H04L29/06
Legal Events
Mar 24, 2011FPAYFee payment
Year of fee payment: 4
Jun 24, 2014IPRAia trial proceeding filed before the patent and appeal board: inter partes review
Free format text: TRIAL NO: IPR2014-00720
Effective date: 20140501
May 27, 2015FPAYFee payment
Year of fee payment: 8
Oct 27, 2015ASAssignment
Effective date: 20050225
Effective date: 19991220