AU6603398A

AU6603398A - Method and apparatus for controlling communications

Info

Publication number: AU6603398A
Application number: AU66033/98A
Authority: AU
Inventors: Ian Charles Ogilvy
Original assignee: Cardsoft Inc
Current assignee: Cardsoft Inc
Priority date: 1997-03-14
Filing date: 1998-03-16
Publication date: 1998-10-12
Anticipated expiration: 2018-03-16
Also published as: AU753163B2

Description

- i -

METHOD AND APPARATUS FOR CONTROLLING COMMUNICATIONS

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.

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.

Devices for carrying out remote payment transactions are well-known. These "payment terminals" include EFTPOS, credit card payment terminals, etc. 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 transac-tion. 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 transac-tion. A payment terminal may, for example, provide for the following basic operations: (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.

(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. (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.

(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".

There are many different brands of payment terminal, utilising many different software and hardware arrangements. This gives rise to a number of problems.

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 .

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.

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 .

It is often the case that, the terminal owner may over time obtain different brands from dif-ferent 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. 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. 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.

To alter the operation of payment terminals, a new appli-cation must be created. This can be time consuming, costly and as the program-ming 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) .

The programming alterations are not "portable" between different types of devices.

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, rearrange-ment and communication of this message data to enable a remote payment transaction.

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 . 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" .

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.

A problem with virtual machines is emulation is slower than normal program execution. For some applications this performance penalty is a significant problem. 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.

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.

"Communicated" includes transport of data via a data carrier such as a smart card. The message processor means is preferably a program mod-ule the specif-ic function of which is to assem-ble, disassemble and corn-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. 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 instruc-tions to be expressed only in the language defined by the message processor means- and thus never requiring trans-lation to any real hardware processor. 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-mental- ised approach which preferably leads to faster programming with less errors.

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.

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. 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 multiprocessing and other complica-tions are handled automatically. This more intuitive and compartmentalised approach leads to faster programming with less errors. 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. 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.

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.

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. The function processor means is preferably translat-ed into the native code of the micro-pro-ces-sor in each hardware 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 processor.

In the preferred embodiment, the "applica-tion" will there-fore corn-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 function selector.

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.

With the advent of the Internet and other exten-sive 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.

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. 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.

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 embodi-ment, 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 applica-tion. 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 alteration 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.

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.

Such a SNAC can be applied in many different types of communication application over a network. 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.

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.

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.

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 . 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 pro-cessor 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. 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. Protocol instructions and message instructions can therefore be built on a PC and downloaded to device where the virtual machine is to be implemented.

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.

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.

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. 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.

Similar emulation is preferably provided for the protocol processor means.

Emulation can therefore be used to test payment terminal or other SNAC application programs. 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 proces-sor means .

The method preferably also includes the steps of processing communications by employing a protocol proces-sor means and protocol processor instructions providing directions for operation of the protocol processor means.

Message processor means, message instructions, protocol processor means and protocol instructions are preferably as discussed above in relation to previous aspects of the invention.

The present invention yet further provides a method of programming a device for processing communica-tions, comprising the steps of loading a processing means of the device with a virtual machine means including a message 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 pro-cessor means.

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.

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.

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 . 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. 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.

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.

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) . 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.

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:

Figure 1 is a schematic block diagram of a payment terminal in accord-ance with an embodiment of the present invention;

Figure 2 is a schematic diagram of a control program architecture for the embodiment of figure 1;

Figure 3 is a schematic flow diagram illustrat-ing device operation which requires the operation of the message engine;

Figure 4 is a schematic flow diagram illustrat-ing an example of operation of the protocol engine;

Figure 5 is a representation of a display (screen dump) available on a development tool for devel-oping 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;

Figure 6 is a screen dump of a further develop-ment tool display illustrating further detail of develop-ment of a message instruction;

Figure 7 is a further screen dump of a develop-ment tool display illustrating further detail of develop-ment of a message instruction;

Figure 8 is a screen dump of a further develop-ment tool display illustrating development of a further message instruction.

Figure 9 is a screen dump of a further develop-ment tool display illustrating development of a protocol instruction; Figure 10 is a screen dump of a further develop-ment tool display illustrates further detail of develop-ment of a protocol instruction;

Figure 11 is a schematic diagram showing a struc-tural embodiment of the message instructions and description for the message processing means, and Figure 12A is a schematic diagram showing the structure of protocol instructions for an embodiment of the protocol processor means.

Figure 12B is a representation of a display of a development tool for developing protocol instructions. 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.

A payment terminal device in accordance with an embodiment of the present invention is illustrated in figure 1. The device hardware comprises a processing means which, in this embodiment includes a central pro-cessing 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.

Prior art devices generally have similar ar-range-ments to that illustrated in Figure 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.

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 "authorisation" 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. Prior art payment terminal devices are generally programmed in a conventional manner. That is, program-ming comprises a sequential set of operating instructions which are executed in sequence to carry out a remote payment transac-tion. 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 program-ming 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 par- ticular device and program arrange-ment .

Figure 2 is a schematic block diagram illustrat-ing architecture of a device in accordance with an em-bodiment of the present invention. The architecture comprises the hardware 100 the device, as illustrated and described in relation to figure 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.

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.

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.

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.

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 instruc-tions 108, message instructions, 109, function support 110 and function instructions 111. The protocol instruc-tions 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.

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.

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.

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 acquirers identity.

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.

In the preferred embodiment, the virtual machine processors 103 are constructed using C and the applica-tion is constructed using C++ or Java. 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.

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.

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.

Appendix B includes a description of a operation of the HAL 18 in accordance with an embodiment of the present inven-tion, 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.

Figure 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.

The operation schematically outlined in figure 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.

Figure 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.

At step (1), on a card swipe of card 5 through reader 4, the card swipe event is detected by the HW drivers 101. 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 periph-erals . Figure 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.

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. 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. 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.

Note that the above descriptions of the routines are not "primitives" but are merely general descriptions.

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. 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 .

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.

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 ac-cordance 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.

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 com-pleted and the device may wait for the next event before proceeding further.

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 exam-pie, 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 . As discussed, the message virtual processor means is directed by message instructions 109. Figure 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 instruc-tion 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.

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.

3. To take a message and deconstruct it into various components and place the various components into other locations. 4. To take data and build a message in ac-cordance with the message description and place the built message in a location.

5. Compare one message with another message. 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, de- constructed 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 . Each message description is labelled so that it can be identified by the application, e.g. each message description may be numerically labelled. A development tool for developing the applica-tion 104, in particular the message and protocol instruc-tions 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. Figures 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 instruc-tions. 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 instruc-tions, for subsequent process-ing.

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 exam-pie, there are seven fields, being "Trackl", "Track2", "Track3", "CustNa e", "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 in- structions 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 instructions for the handling of that element. Figure 6 illustrates a display 33 which enables a programmer to provide message descriptors to CustName element. 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 instruc-tion 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. Figure 7 shows a display which illustrates the instructions for the format "Tracks".

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 designat-ed in the instructions.

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. Figure 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 figure 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. 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. The protocol processor 106 is arranged to organise communications, in accordance with directions from the protocol processor instructions 108. Referring to Figure 4, in a typical remote payment transac-tion, 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), figure 4. The protocol instruction 108 for the event is rolled up (step 3) . The protocol processor 108 implements the protocol in-struc^¬ tions for that event, (step (4) ) . The protocol instructions are divided into "sections"

130, "lines" 131 and "protocol commands" 132, as illustrated in Figure 12A. Figure 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. Timeout () - 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 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.

Figures 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.

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.

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.

Referring to figure 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". Figure 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. The either

1) Message number 0410 should then be re-ceived back from the target device and the message pro-cessor 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 in-struction means and storing the data if a match occurs. Or

2) A timeout of 100 tenths of a second elapses. Then the protocol is ended and re-turned to the protocol General, which causes a further message, 0100 to be formulated and sent out. Then either

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. 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.

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.

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. More details of operation and build up of mes-sages and protocols are given in the appendix A.

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 HAL and preferably the message and protocol engines. Similarly, a specialised network access computer or card computer could be implemented in GAVA.

Please note that the arrangement of the present invention can be used to deal with any payment transac-tion device, including one which deals with smart cards.

The present invention can also be used to imple-ment a specialised network access device, which may use similar hardware to that provided for a payment terminal . 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.

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 embodi-ments 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.

APPENDIX A

Contents .

Introduction

Help for CardScript Scribe

The Scribe program assist in the design of stored information & programs for EFTPOS terminals, PINpads,

Electronic Cash Reqisters and other small computer systems.

Writing A Program

For help on writing a CardScript, program, rather than operation of the Scribe tool, see

Writing A CardScript Program

A CardScript program is more similar to a Windows RAD tool program than a conventional C Language or Assember program.

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.

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

Configure Data Dictionary

Data Dictionary Usage

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.

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.

Data Dictionary fields may have an initial value set from the Initial Data Tables

Structure

Tables

The Data Dictionary is divided into tables. Each record displayed in Configure Data Dictionary describes one table. Fields are placed by selecting add and clicking on the Panel. Field Attributes

Double Clicking on any field reveals and allows viewing and/or editing of Data Dictionary Field Attributes.

Field Order

Layouts are stored indexing fields by table#lfield#. This means existing scripts will behave strangely if the Data Dictionary is changes the number Of referenced fields.

For example if "Merchant Name" is table 3/field 2 and "Address" is table 31field 3. Then deleting field table3/fieldl 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

Reserved Settings

see Reserved Data Dictionary Settings

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A device arranged to process messages for com^┬¼ munications, comprising a virtual machine means including a message 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 .

2. A device in accordance with claim 1, further comprising protocol processor means arranged to organise communications to and from the device, and protocol processor instruction means arranged to provide direc-tions for operation of the protocol processor means.

3. A device in accordance with claim 1 or claim 2, wherein the device includes a micro .processor which runs in accordance with native software code, and the message processor means is implemented as the native software code of the micro processor.

4. A device in accordance with claim 2, wherein the device includes a micro processor which runs in accordance with native software code and the protocol processor means is implemented as a native software code and the protocol processor means is implemented as a native software code of the micro processor.

5. A device in accordance with any preceding claim, further comprising a function processor means arranged to control and select general operations of the device not controlled by the message processor means, and function processor instructions arranged to provide directions for operation of the function processor.

6. A device in accordance with claim 5, wherein the device includes a micro processor which runs in accordance with native software code and the function processor means is implemented as native code of the micro processor.

7. A device in accordance with any preceding claim, wherein the message processor means is arranged to assemble, disassemble and compare messages.

8. A device in accordance with claim 7, wherein the message instruction means includes a set of descriptions of message data.

9. A device in accordance with any preceding claim, wherein the message processor instruction means is implemented in software defined by the message processor means, where the device includes a micro processor, and wherein the message instruction means do not require translation to the native software code of the micro processor.

10. A device in accordance with any one of claims 2 to

9, wherein the device includes a micro processor which runs in accordance with native software code and wherein the protocol instruction means are implemented in software defined by the protocol processor means, and do not require translation to the native code of the micro processor.

11. A device in accordance with any one of claims 5 to

10, wherein the device includes a micro processor which runs in accordance with a native software code, and wherein the function processor instruction means are implemented in software defined by the function processor means and do not require translation to the native code of the micro processor.

12. A device in accordance with any preceding claim, including a hardware abstraction layer comprising a series of routines which provide a application program interface to exercise an operating system, BIOS or hardware drivers of the device .

13. A device in accordance with any one of the preceding claims, wherein the device is a specialised network access device arranged for communicating over a network.

14. A device in accordance with claim 13, the device being a remote payment terminal and the messages being messages relating to remote payment transactions.

15. A computer for developing message instructions for providing directions for operation of a message processor means in accordance with any one of the preceding claims, computer including a processing means arranged to receive data input by a user to build message instructions for the message processor means.

16. A computer in accordance with claim 15, wherein the processing means is also arranged to receive data input by a user to build protocol instructions for a protocol instruction means of the device of any one of claims 2 to 15.

17. A computer including means for emulating the device of any one of claims 1 to 15, in order that the message instruction means developed for the device can be tested.

18. A method of programming a device for processing communications, comprising the steps of loading a processing means of the device with a virtual machine means including a message 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 .

19. A method in accordance with claim 18, comprising the further step of loading the processor means of the device with a protocol processor means arranged to organise communications to and from the device, and protocol processor instructions arranged to provide directions for operation of the protocol processor means.

20. A computer memory storing instructions for controlling a computing device to implement a virtual machine means comprising a message processor means arranged to processor messages communicated to and/or from the device.

21. A computer readable memory in accordance with claim 20, further storing instructions for implementing message processor instruction means arranged to provide directions for operation of the message processor.

22. A computer readable memory in accordance with claim 20 or claim 21, further storing instructions for implementing protocol processor means arranged to organise communications to and from the computing device.

23. A computer readable memory in accordance with claim 22, further storing instructions for implementing protocol processor instructions arranged to provide directions for operation of the protocol processor means.

24. 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.

25. A specialised network access computer in accordance with claim 25, being a remote payment terminal.