IMPROVED APPARATUS FOR REMOTE PAYMENT TRANSACTIONS
The present invention relates to a method and apparatus for controlling remote payment transactions, and particularly, but not exclusively, to a remote payment terminal for facilitating payment transactions and to a method of controlling the terminal.
Devices for carrying out remote payment transactions are well-known. These "payment terminals" include EFTPOS, credit card payment terminals, etc. The function of such remote payment terminals is to facilitate payment transactions. Goods/services will usually be offered by the payment terminal holder. The payment terminal provides message information to a "transaction acquirer" (which may be a bank) to enable the transaction acquirer to settle the transaction. Message information may also be provided to determine whether the person who owns the card has sufficient funds to enable the transaction. A transaction usually takes place by means of a card, such as a credit card or a debit card. A payment terminal may, for example, provide for the following basic operations:
(1) Input of information which is required to enable a transaction eg. identification of the card holder's 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 PIN number or the like code may also be required, for security purposes.
(2) Obtain access to the users 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, the information on the person's account input to the payment terminal will need to be transmitted for verification 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 terminal is therefore, m such a case, required to have means (3) providing for encryption.
(4) The payment terminal may need to be able to receive communications over the remote line from the processor accessing the user's account, le. 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 user has enough money m 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) m the payment terminal .
(6) To provide a message that the transaction request is approved or that a transaction has occurred, by display or printer, for example. These basic operations can be carried out m number of different ways, governed by the hardware/software combination of the brand of payment terminal and the requirements of the owner of the payment terminal . The payment terminal owner is usually an account acquirer such as a bank. Different account acquirers generally have very different requirements for operation of their payment terminals. For example, they will generally have differing requirements for the type and operation of encryption for communications. They would also generally have different requirements for the display and formatting of any
"receipt" to be printed out for the customer. Also, communications protocols may be very different from bank to bank. The format of data storage on an account holders card generally varies quite widely from bank to bank as, indeed, may the content of the data on the account holders card.
To date, various account acquirers have usually directed a manufacturer of payment terminals to manufacture a terminal m accordance with their requirements. Thus, there are many different brands of payment terminal, operating different varieties of hardware and software m order to satisfy the various requirements of the various account acquirers . Not only account acquirers may require tailored payment terminal operation, but requirements may be dictated by goods/service providers who operate the terminals at the "front end", eg. retail chains.
An important requirement for payment terminals is that they must generally ensure that communicated information is secure, usually by way of encryption. Security must also be provided to govern access to accounts. Often the payment terminal will include security information such as one or more "secret keys" which facilitate secure communications and ensures that access to an account can't be obtained in error or fraudulently.
Because these devices are required to deal with security sensitive information, it is a requirement that these devices be thoroughly tested before they are allowed to be used, in order to ensure that they operate correctly and no errors are likely to be made, particularly with the security sensitive information. Such testing can take many man hours and is therefore quite expensive. It is nevertheless absolutely necessary and devices will not be allowed to be used which have not been "certified" as complying with all security and operational requirements.
Because of the need to ensure that operation of the payment terminal does not cause any security risk, any software change which may be required by an account acquirer requires the entire terminal and software to be completely retes ed to ensure compliance. Any change, therefore, is extremely expensive because of this need for testing and also because it is necessary to reprogram the terminal m each case. Another problem with payment
terminals is that because of the way the terminal is established, i.e., by being manufactured and tested with software and hardware for one particular account acquirer who is the owner of the terminal, a terminal has a "primary" relationship to the owner ("primary") account acquirer. The primary account acquirer will essentially dictate the nature of the operation of the terminal and will select the software operation to be carried out by the device. Although the primary acquirer may well take into account some of the needs of other acquirers whose accounts may also be accessed via the terminal, there will be a natural reluctance on behalf of the primary acquirer to meet all the other acquirers operational needs. After all, the primary acquirer will usually be m competition with the other acquirers. Further, even if the desire were there for the primary acquirer to meet the other acquirers needs m detail, expense of changes, mainly due to it being necessary to test the entire terminal and software for certification purposes, is another disincentive. The cost involved m making any changes is great, and therefore the primary acquirer is likely to be reluctant to do so.
Thus, the primary acquirer will usually program a device m a way m which suits them rather than other acquirers. This and other factors lead to a lot of "back-end" processing. Rather than dealing with acquirers requirements m the software and arrangement of the terminal device itself, processing is carried out by computers at the "back-end". For example, all communications from the payment terminal for all account acquirers may be routed to a processing system at a primary account acquirer. The processing system at the primary account acquirer then further processes the information and may send further communications to other account acquirers in order to process a transaction. These acquirers may have their own processing systems carrying out further processes This "back-end" processing leads to an increase
m cost for the consumer.
The present invention provides a system for controlling remote payment transactions, comprising a remote payment terminal including processing means and an operating system arranged to carry out a remote payment transaction operation m accordance with application instruction means, an application memory means storing the application instruction means for operation of the payment terminal, the arrangement being such that application instruction means is independent of the rest of the payment terminal .
By "independent" is meant that the application instruction means can be handled as a separate entity. For example, they may be able to be altered and tested separately from the rest of the payment terminal . They may also be able to be provided to the system separately from the rest of the payment terminal . A common payment terminal may thus be able to handle a number of different sets of application instruction means, provided independently.
Preferably, any change m the application instruction means can be carried out without it being necessary to re- test the other software and/or hardware of the terminal, by applying the present invention. Preferably, the application instruction means (usually in the form of software) is stored m a separate memory means, preferably a separate memory module. The memory module may be of the "plug-m" variety arranged to plug into the payment terminal - or may be stored on a "smart card" . Where the application instruction means is stored on a smart card, a smart card reader is preferably provided with the payment terminal to enable the application instruction means to be read to the payment terminal operating systems. In a payment processing system utilising the present invention, therefore, each account acquirer may preferably
provide its own application instruction means stored on a memory module, such as a smart card. A particular application instruction means will be selected when the respective account acquirers system is to be accessed, eg when a user of that acquirers accounts system wishes to make a payment transaction via the remote payment transaction terminal.
Preferably, if the application instruction means is on a smart card or the l ke, when a user swipes their magnetic card or smart card the remote payment terminal is arranged to call for the particular account acquirers application instruction means, and the vendor (i.e payment terminal operator) will then load the terminal with the particular account acquirers application instructions, m one embodiment by reading the account acquirers smart card containing the particular application instruction means.
Different account acquirers can therefore conveniently implement different processing requirements for their accounts systems by providing different application instructions. These application instructions may govern all aspects of the remote payment transaction including communications, i.e. the remote payment terminal may be directed to communicate with the particular account acquirers "host" terminal. Because the application instruction means can preferably be tested separately from the payment terminal, it is not necessary to go to the expense of retestmg the entire payment terminal and operating system merely for an applications upgrade for a particular account acquirer. Application changes and upgrades can therefore be implemented relatively cheaply. A payment terminal arranged to receive the application instruction means m this form can be termed a "universal" terminal. The operating system and payment terminal may only need to be tested and certified once. Applications may then be provided separately, and also tested separately.
Preferably, security of data can also be included m the memory module, for controlling the security for each particular acquirer.
Different applications may be provided for the same account acquirer. For example, the account acquirer may require different applications for different types of account it administers, eg credit card accounts, current accounts, etc. Present invention preferably facilitates the provision of as many different applications as may be required.
An alternative to providing application on separate memory modules is to provide a universal terminal having a partitioned memory with secure memory address locations for loading application instruction means for particular account acquirers. Application instruction means could then be uploaded by telecommunications, i.e data transfer
In the prior art, generally one account acquirer controls transactions with all the other account acquirers. With use of the present system, however, it would be possible for each acquirer to control its own transactions, as each acquirer may provide separate application instructions .
In a preferred embodiment, an arrangement m accordance with the applicants co-pending International Patent Application Number PCT/AU98/00173 may be utilised. This co-pending application describes a generic software arrangement which is particularly suitable for remote payment transaction processing and which can be adapted to run on different hardware architectures.
Any other "open" software system may be used and applicants invention is not limited to that disclosed m PCT/AU98/00173.
Another feature of the present invention, is that m some cases the memory module may preferably include memory locations for storing details of transactions which have
taken place over a particular time period (eg on a day by day basis) . The memory module can then be returned to the account acquirer, eg. at the end of the day, so transactions can be processed. This will be most convenient where the memory module is a smart card. This arrangement does not require any on-line communications between the account acquirer system and the remote payment terminal .
By "operating system" we don't necessarily mean an operating system as is conventionally understood i.e. an operating system arranged to control hardware and peripherals m accordance with application commands. While it includes such a basic operating system, it is also envisaged that the operating system m the payment terminal may also include commands which enable it to interface with the application instruction means and may also include more sophisticated "high level" commands for controlling operation of a remote payment transaction.
For example, the application instruction means may be a set of instructions arranged to control merely the aspects of operation of the terminal which are required to be varied from account acquirer to account acquirer. "Application" instructions, m this case, will also be included m the operating system, for controlling aspects of operation of the terminal which are common to all acquirers .
Preferably, therefore, a payment terminal device is developed and tested separately from application software for running the device. Different payment terminal devices m the present invention, including the basic payment terminal operating system and software ("fixed program") may be certified to carry out a number of applications and the fixed program may include a list of options that the device is certified for. Any application software being run on that particular device will, preferably, first check whether device is suitable for running all the options
available m that particular application software module. It may only run a limited number of the options available, or the device may be arranged to run all the options.
On the other hand, the fixed program of the device is preferably arranged to register the application software
(external) software and determine what cards it can process. Both the device and the application software may be able to determine whether to or not they are compatible and if they are, exactly what operations can be run. The remote payment terminal, therefore, preferably includes a fixed program which includes instructions for controlling the terminal to access application software from a separate memory area and control the payment terminal to run m accordance with one, some or all of options and features which may be included m the separate applications software. Preferably, the applications program is arranged to assess the security of the device and what operations it is certified for, and then only to run the operations m the application software that the device is certified for.
The present invention therefore preferably has the advantage that a plurality of "generic" payment terminals can be provided. The generic terminals are certified by the account acquirers to run application software which is provided separately, preferably by the generic terminal being able to accept separate memory modules containing the software. The generic terminals can therefore be purchased by prospective users, e.g., merchants, as well as by account acquirers and the like. The user is then provided with the application software required for dealing with different account acquirers, by the provision of separate memory modules. Each application software module can be tested and certified separately from the device.
As an alternative to providing separate memory modules, separate memory areas may merely be specified m the generic terminal for loading of the separate
independent application instruction means.
The present invention further provides a remote payment terminal, comprising a processing means and operating system arranged to carry out a remote payment transaction operation m accordance with application instruction means, the operating system being arranged to access the application instruction means m a separate application memory means, and the remote payment terminal and operating system being arranged to be independent from the application instruction means.
By "independent" is meant that the remote payment terminal can be handled as a separate entity, and may be provided with a plurality of separate independent application instruction means to operate m accordance with those instructions. The remote payment terminal is preferably essentially generic to the plurality of separate application instruction means. Preferably, the remote payment terminal can be tested for compliance with predetermined requirements, separately from the application instruction means.
Preferably, the operating system includes a fixed program which is arranged to interface with the application instruction means. The fixed program may, for example, include a list of applications which it is compatible with and on operation of the card by a user (e.g., to swipe a certain account acquirers bank card) .
The present invention yet further provides an application memory means, storing application instruction means for instructing a remote payment terminal comprising a processing means and operating system, to carry out remote payment transactions m accordance with the application instruction means, the application instruction means being independent from the payment terminal and operating system. Preferably, the application memory means is a separate memory module and is preferably provided by way of a smart
card or the like. Preferably, security information may also be stored m the application memory means. In one embodiment, memory locations may also be provided for storing data on transactions. The present invention yet further provides a method of operating a remote payment terminal comprising a processing means and operating system arranged to carry out remote payment transactions m accordance with application instruction means, comprising the steps of providing the application instruction as an independent entity.
Preferably, the application instruction means provided from a separate application memory means.
Preferably, the separate application memory means is a separate memory module, such as a smart card. The present invention yet further provides a method of arranging a remote payment transaction processing system, comprising the steps of providing a universal terminal which includes a basic set of operating instructions and hardware sufficient for carrying out remote payment transactions m accordance with application instruction means, separately providing independent application instruction means for instructing operating of the remote payment terminal to carry out remote payment transactions.
Preferably the method also includes the step of separately testing the application instruction means for compliance with a remote payment processing system, separately from testing of the remote payment terminal.
The present invention yet further provides a system for controlling remote payment transactions, comprising a remote payment terminal including a processing means and operating system arranged to carry out a remote payment transaction operation m accordance with application instruction means, and a separate memory module, such as a smart card, storing the application instruction means for instructing the remote payment transaction.
Features and advantages of the present invention will
become apparent from the following description of an embodiment thereof, by way of example only, with reference to the accompanying drawings, m which;
Figure 1 is a schematic diagram of a system for controlling remote payment transactions m accordance with an embodiment of the present invention, and
Figure 2 is a diagram showing the architecture of the system of figure 1.
Reference numeral 1 indicates a "universal" payment processing terminal m accordance with an embodiment of the present invention.
The payment terminal comprises a central processing unit 2 which includes a memory, a microprocessor, and other hardware as would be known to a person skilled m the art, and an operating system for carrying out remote payment transaction operations m accordance with application instruction means. The terminal 1 also includes a smart card reader 3 connected to the central processing unit 1 and a communications module 4 also connected to the central processing unit 2. The communications module 4 is used for communications with host computers of an account acquirer, to facilitate on-line remote payment transactions, as is well-known to persons skilled m the art.
The terminal 1 also includes a printer 5 and a display 6 for printing and displaying information on remote payment transactions, and a keyboard 7 for inputting data.
Reference numerals 8,9 and 10 designate "smart" cards, each of which includes a memory module 8a, 9a, 10a which is arranged to store application instruction means for instructing operation of the terminal 1 to control remote payment transactions.
This arrangement s very different from payment processors of the prior art, which incorporate the application instruction means directly within the terminal 1, not separately on a separate memory module.
In operation, when a customer requires a remote
payment transaction, the customer will be required to insert their account card, which may be a smart card, m the card reader. Note that the account card may alternatively be a standard magnetic card, and a magnetic card reader (not shown) may be provided, m which case the customer will swipe their card through the magnetic stripe card reader. The central processing unit 2 is arranged to detect that a card has been swiped and (or customer smart card read) and will then ask or require that an application instruction means be loaded. This may be done m a number of ways. For example, the display 6 may indicate which particular application instruction means is required by the CPU 2. Alternatively, a payment terminal operator may know from the customers card exactly which set of application instruction means are required. There are a number of ways m which the required application instruction means can be indicated. The next step is that the required application instruction means is loaded to the CPU 2 by inserting the card 8,9,10 into the card reader and downloading the application instruction means. Subsequently, the remote payment process may be carried out, m accordance with the application instruction means which have been downloaded for the customer.
In a subsequent transaction requiring different application instruction means, then the terminal would require a different card 8,9,10 to be loaded into the card reader.
There are a number of ways m which the application instruction means may be provided to the payment terminal 1. Separate "plug-m" memory modules could be provided, which are not smart cards; application instruction means could be downloaded on-line and stored m a separate memory location m the central processing unit 2. The important feature of the invention is that the application instruction means can be dealt with completely separately from the remote payment terminal . It is therefore
necessary only to test and certify the remote payment terminal itself once. Each time application instruction means require updating or modifying, because of the requirements of a particular account acquirer, for example, this can be done completely separately, and testing of the application can be done separately.
Another possibility for providing the application instruction means may be on a customer card having a memory module for containing application instruction means, as well as having means containing the customer information and data. The card holder may therefore have a smart card which, as well as containing information for enabling a transaction with his account, also contains the application instruction means for operating a "universal" terminal. The memory module which separately contains the application instruction means may also preferably contain the security data for the particular account acquirer.
Figure 2 shows an architecture for a preferred embodiment of the present invention. The payment terminal 1 incorporates an operating system 20 and hardware 21 (the hardware is described above with reference to Figure 1) . The operating system controls the hardware to carry out remote payment transaction m accordance with application instructions 23, 24 which are provided via a separate memory module as explained with reference to Figure 1. The separate memory module also includes security data 25, 26. The payment transaction will also require information from the user card and other input information, such as a PIN (via the keypad 7) , as indicated by reference, 27.
In accordance with a preferred embodiment, the architecture of the present invention utilises the novel software configuration described m applicants co-pending Application Number PCT/AU98/00173 , the specification of which is incorporated herein by reference. The operating system therefore comprises a fixed program including
virtual machine (λ/M) processors 30, comprising a message engine, a protocol engine and a function processor, forming a "virtual machine" for running generic application instruction means. The message engine is a separate virtual processor whose function is to deal with the assembly and disassembly of messages. The protocol engine is a separate virtual processor whose function is to organise communications.
The present invention is not limited to utilising the virtual machine described m PCT/AU98/00173. Any "open" software system could be applied. Virtual machines, which operate on different hardware are well-known m the art. Any software operating system may be used as long as the application instructions are compliant with the operating system.
The fixed program also includes an interface 35 which is arranged to interface with application instruction means 23, 24. The interface 35 may include a list or table of the applications which this particular device 1 is compatible with. On insertion and swiping of a user card, the type of application required is detected and the interface 35 will check the list and ask for the particular application if it is available, and if it is not available m this particular device 1 it will indicate that the transaction cannot be carried out for this particular user card. The interface 35 also preferably includes a list of options accessible by application instruction means 23, 24, indicating the features or options of payment transactions which the device 1 is capable of carrying out . The application instructions may include means for determining which of a number of options m the application instructions the device is capable of carrying out and only then running those options that the device is capable of carrying out. This arrangement takes into account the fact that over a period of time developments to applications may occur which may not be compatible with machines that were
developed some time ago.
Variations and/or modifications may be made to the invention as shown m the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered m all respects as illustrated and not restrictive .