New! View global litigation for patent families

WO2001004851A1 - Improved apparatus for remote payment transactions - Google Patents

Improved apparatus for remote payment transactions

Info

Publication number
WO2001004851A1
WO2001004851A1 PCT/AU2000/000833 AU0000833W WO2001004851A1 WO 2001004851 A1 WO2001004851 A1 WO 2001004851A1 AU 0000833 W AU0000833 W AU 0000833W WO 2001004851 A1 WO2001004851 A1 WO 2001004851A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
payment
application
means
terminal
instruction
Prior art date
Application number
PCT/AU2000/000833
Other languages
French (fr)
Inventor
Ian Charles Ogilvy
Original Assignee
Cardsoft International Pty Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355Personalisation of cards for use
    • G06Q20/3552Downloading or loading of personalisation data
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357Cards having a plurality of specified features
    • G06Q20/3578Hierarchy of users of cards

Abstract

The present invention relates to a system and method for carrying out remote payment transactions. In prior art remote payment terminals, a remote payment transaction is controlled by software application instructions which have been tested for compliance with security standards, and which are provided together with the remote payment terminal. A problem arises where it is required to update the application software. Any update requires reprogramming and retesting for compliance with security requirements. In the present invention, the application instruction means (software) are provided separately from a basic 'universal' remote payment terminal and downloaded to the terminal to control a remote payment transaction. This has the advantage that if a change in the software application is required, it can be carried out and tested for security, separately from the terminal.

Description

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 .

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:
1. 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, and 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 from the rest of the payment terminal .
2. A system m accordance with claim 1, wherein the application memory means is a separate memory module.
3. A system m accordance with claim 2 wherein the memory module is provided on a smart card or the like.
4. A system m accordance with claim 2 or claim 3 , wherein the application memory means is carried on a card intended for a cardholder, and also including data enabling a transaction with the cardholder's account.
5. A system m accordance with claim 1, wherein the remote payment terminal includes a partitioned memory with secure memory address locations for the application instruction means.
6. A system m accordance with any one of the preceding claims, wherein there are a plurality of application instruction means, each application instruction means enabling control of a transaction by an account acquirer associated with those application instruction means, whereby different account acquirers may control transactions depending upon the application instruction means utilised.
7. A remote payment terminal, comprising a processing means and an operating system arranged to carry out remote payment transaction operation m accordance with application instruction means, the operating system being arranged to access the application instruction means in an application memory means, and the remote payment terminal and operating system being arranged to be independent from the application instruction means .
8. A remote payment terminal in accordance with claim 7, wherein the operating system includes a fixed program arranged to interface with a plurality of different application instructions means for controlling operation of the terminal.
9. A system for controlling remote payment transactions, comprising a remote payment terminal in accordance with any one of claims 7 or 8 , and a plurality of memory means each storing application instruction means for controlling the remote payment terminal, the application instruction means of each memory means being arranged to provide for different requirements for operation of a remote payment terminal .
10. An application memory means, storing application instruction means for instructing a remote payment terminal in accordance with any one of claims 7 or 8 , to carry out remote payment transactions in accordance with the application instructions being independent from the payment terminal .
11. A method of operating a remote payment terminal comprising a processing means and operating system arranged to carry out remote payment transactions in accordance with application instructions means, comprising the steps of providing the application instruction means as an independent entity.
12. A method of arranging a remote payment transaction processing system, comprising steps of providing a universal terminal which includes a set of operating instructions and hardware sufficient for carrying out remote payment transactions in 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.
13. A method m accordance with claim 12, comprising the step of separately testing the application instruction means for compliance with the remote processing system.
14. A computer readable medium storing instructions for controlling a remote pa ment terminal to operate m accordance with any one of claims 7 and 8.
15. A remote payment terminal, comprising a processing means and an operating system arranged to carry out remote payment transaction operations in accordance with application instruction means, the operating system including a fixed program arranged to interface with a plurality of alternative different application instruction means for controlling operation of the terminal .
16. 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 in accordance with application instruction means, the remote payment terminal including a fixed program, and memory means storing a plurality of different application instruction means being arranged to interface with the fixed program, for controlling operation at the terminal m accordance with one or more of the plurality of application instruction means .
PCT/AU2000/000833 1999-07-12 2000-07-12 Improved apparatus for remote payment transactions WO2001004851A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AUPQ5265 1999-07-12
AUPQ526599 1999-07-12

Publications (1)

Publication Number Publication Date
WO2001004851A1 true true WO2001004851A1 (en) 2001-01-18

Family

ID=3819389

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2000/000833 WO2001004851A1 (en) 1999-07-12 2000-07-12 Improved apparatus for remote payment transactions

Country Status (1)

Country Link
WO (1) WO2001004851A1 (en)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10156783A1 (en) * 2001-11-19 2003-05-28 Giesecke & Devrient Gmbh Control and programming of payment terminals, whereby program commands have validity conditions under which they run, thus allowing a single program to be created that will run on different hardware types
EP1229505A3 (en) * 2001-01-19 2005-06-01 Hitachi, Ltd. Method of providing IC card service, card terminal, and IC card
US7591419B2 (en) 2006-03-28 2009-09-22 HSBC Card Services Inc. User selectable functionality facilitator
US7653602B2 (en) 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US7725369B2 (en) 2003-05-02 2010-05-25 Visa U.S.A. Inc. Method and server for management of electronic receipts
US7857215B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system including phone with rewards image
US8005763B2 (en) 2003-09-30 2011-08-23 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US8010405B1 (en) 2002-07-26 2011-08-30 Visa Usa Inc. Multi-application smart card device software solution for smart cardholder reward selection and redemption
US8015060B2 (en) 2002-09-13 2011-09-06 Visa Usa, Inc. Method and system for managing limited use coupon and coupon prioritization
US8119282B2 (en) 2005-06-16 2012-02-21 Exide Technologies Gmbh Pole bridge for a battery
US8162208B2 (en) 2009-01-23 2012-04-24 HSBC Card Services Inc. Systems and methods for user identification string generation for selection of a function
US8407083B2 (en) 2003-09-30 2013-03-26 Visa U.S.A., Inc. Method and system for managing reward reversal after posting
US8429048B2 (en) 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts
US8554610B1 (en) 2003-08-29 2013-10-08 Visa U.S.A. Inc. Method and system for providing reward status
US8626577B2 (en) 2002-09-13 2014-01-07 Visa U.S.A Network centric loyalty system
US9852437B2 (en) 2002-09-13 2017-12-26 Visa U.S.A. Inc. Opt-in/opt-out in loyalty system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998002834A1 (en) * 1996-07-16 1998-01-22 Transaction Technology, Inc. A method and system for using an application programmable smart card for financial transactions in multiple countries
WO1998049658A1 (en) * 1997-04-30 1998-11-05 Visa International Service Association Internet payment and loading system using smart card

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998002834A1 (en) * 1996-07-16 1998-01-22 Transaction Technology, Inc. A method and system for using an application programmable smart card for financial transactions in multiple countries
WO1998049658A1 (en) * 1997-04-30 1998-11-05 Visa International Service Association Internet payment and loading system using smart card

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OESTREICHER M.: "Computer security applications conference", ACSAC'99, PROCEEDINGS 15TH ANNUAL, 6 December 1999 (1999-12-06) - 10 December 1999 (1999-12-10), pages 291 - 298 *

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1229505A3 (en) * 2001-01-19 2005-06-01 Hitachi, Ltd. Method of providing IC card service, card terminal, and IC card
US6976635B2 (en) 2001-01-19 2005-12-20 Hitachi, Ltd. Method of providing IC card service, card terminal, and IC card
DE10156783A1 (en) * 2001-11-19 2003-05-28 Giesecke & Devrient Gmbh Control and programming of payment terminals, whereby program commands have validity conditions under which they run, thus allowing a single program to be created that will run on different hardware types
US8010405B1 (en) 2002-07-26 2011-08-30 Visa Usa Inc. Multi-application smart card device software solution for smart cardholder reward selection and redemption
US8626577B2 (en) 2002-09-13 2014-01-07 Visa U.S.A Network centric loyalty system
US8239261B2 (en) 2002-09-13 2012-08-07 Liane Redford Method and system for managing limited use coupon and coupon prioritization
US8015060B2 (en) 2002-09-13 2011-09-06 Visa Usa, Inc. Method and system for managing limited use coupon and coupon prioritization
US9852437B2 (en) 2002-09-13 2017-12-26 Visa U.S.A. Inc. Opt-in/opt-out in loyalty system
US8386343B2 (en) 2003-05-02 2013-02-26 Visa U.S.A. Inc. Method and user device for management of electronic receipts
US7987120B2 (en) 2003-05-02 2011-07-26 Visa U.S.A. Inc. Method and portable device for management of electronic receipts
US9087426B2 (en) 2003-05-02 2015-07-21 Visa U.S.A. Inc. Method and administration system for management of electronic receipts
US7827077B2 (en) 2003-05-02 2010-11-02 Visa U.S.A. Inc. Method and apparatus for management of electronic receipts on portable devices
US7725369B2 (en) 2003-05-02 2010-05-25 Visa U.S.A. Inc. Method and server for management of electronic receipts
US8793156B2 (en) 2003-08-29 2014-07-29 Visa U.S.A. Inc. Method and system for providing reward status
US8554610B1 (en) 2003-08-29 2013-10-08 Visa U.S.A. Inc. Method and system for providing reward status
US7857215B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system including phone with rewards image
US7857216B2 (en) 2003-09-12 2010-12-28 Visa U.S.A. Inc. Method and system for providing interactive cardholder rewards image replacement
US8244648B2 (en) 2003-09-30 2012-08-14 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US8005763B2 (en) 2003-09-30 2011-08-23 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US8407083B2 (en) 2003-09-30 2013-03-26 Visa U.S.A., Inc. Method and system for managing reward reversal after posting
US9141967B2 (en) 2003-09-30 2015-09-22 Visa U.S.A. Inc. Method and system for managing reward reversal after posting
US9710811B2 (en) 2003-11-06 2017-07-18 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US7653602B2 (en) 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
US8119282B2 (en) 2005-06-16 2012-02-21 Exide Technologies Gmbh Pole bridge for a battery
US8157165B2 (en) 2006-03-28 2012-04-17 HSBC Card Services Inc. User selectable functionality facilitator
US7591419B2 (en) 2006-03-28 2009-09-22 HSBC Card Services Inc. User selectable functionality facilitator
US8162208B2 (en) 2009-01-23 2012-04-24 HSBC Card Services Inc. Systems and methods for user identification string generation for selection of a function
US8429048B2 (en) 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts

Similar Documents

Publication Publication Date Title
US5036461A (en) Two-way authentication system between user's smart card and issuer-specific plug-in application modules in multi-issued transaction device
US4961142A (en) Multi-issuer transaction device with individual identification verification plug-in application modules for each issuer
US7413113B1 (en) Context-based card selection device
US5705798A (en) System and method for processing a customized financial transaction card
US6220510B1 (en) Multi-application IC card with delegation feature
US6409080B2 (en) Portable electronic device and loyalty point system
US8403211B2 (en) System, program product and methods for retail activation and reload associated with partial authorization transactions
US6539282B2 (en) Vending machine for vending age-restricted products using a credit card and associated methods
US7908216B1 (en) Internet payment, authentication and loading system using virtual smart card
US20040230489A1 (en) System and method for mobile payment and fulfillment of digital goods
US20080017704A1 (en) Contactless Electronic Wallet Payment Device
US6145740A (en) Electronic purse card value system
US6095412A (en) Host and user transaction system
US6808111B2 (en) Terminal software architecture for use with smart cards
US20060064391A1 (en) System and method for a secure transaction module
US6557032B1 (en) Data processing system using active tokens and method for controlling such a system
US20070005685A1 (en) Browser-based payment system
US6145739A (en) System and method for performing transactions and an intelligent device therefor
US4752677A (en) Customer service system for use in IC card system
US20110145047A1 (en) System and method for applying credits from third parties for redemption at member retailers
US20030132284A1 (en) System and method for integrated circuit card data storage
US6328217B1 (en) Integrated circuit card with application history list
US6402028B1 (en) Integrated production of smart cards
US6317832B1 (en) Secure multiple application card system and process
US20060085357A1 (en) Methods and systems for performing credit transactions with a wireless device

Legal Events

Date Code Title Description
AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

AK Designated states

Kind code of ref document: A1

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

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

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP