WO1997010560A1 - Stored value transaction system and method using anonymous account numbers - Google Patents

Stored value transaction system and method using anonymous account numbers Download PDF

Info

Publication number
WO1997010560A1
WO1997010560A1 PCT/US1996/014414 US9614414W WO9710560A1 WO 1997010560 A1 WO1997010560 A1 WO 1997010560A1 US 9614414 W US9614414 W US 9614414W WO 9710560 A1 WO9710560 A1 WO 9710560A1
Authority
WO
WIPO (PCT)
Prior art keywords
die
value
transaction
card
transactions
Prior art date
Application number
PCT/US1996/014414
Other languages
French (fr)
Inventor
G. Fred Renner
Gilles Garon
Original Assignee
Cybermark, L.L.C.
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
Application filed by Cybermark, L.L.C. filed Critical Cybermark, L.L.C.
Priority to AU69700/96A priority Critical patent/AU6970096A/en
Publication of WO1997010560A1 publication Critical patent/WO1997010560A1/en

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 OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/342Cards defining paid or billed services or quantities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/349Rechargeable cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/383Anonymous user system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Payment protocols; Details thereof using an alias or single-use codes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409Device specific authentication in transaction processing
    • G06Q20/4093Monitoring of device authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • 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/02Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices
    • G07F7/025Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by keys or other credit registering devices by means, e.g. cards, providing billing information at the time of purchase, e.g. identification of seller or purchaser, quantity of goods delivered or to be delivered
    • 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/0866Mechanisms 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 by active credit-cards adapted therefor

Definitions

  • This invention relates generally to so-called "stored value" systems which use smart cards (i.e. , cards having an embedded microprocessor) to replace cash. More particularly, the invention provides a system in which smart cards can be used to perform financial transactioas wherein individual transactions can be settled against a cardholder's account balance while preventing the cardholder's account number or balance from being traced to the cardholder.
  • smart cards i.e. , cards having an embedded microprocessor
  • Smart cards which electronically hold a cash equivalent value are hereinafter referred to as "stored value” cards.
  • Stored value cards One example of such a card is the Gemplus MPCOS card, made by Gemplus Card International.
  • Devices which install or increase value on stored value cards, such as a cash-to-card machine, are hereinafter referred to as “revalue devices”.
  • Devices which accept stored value cards and dispense a product or service in exchange for decrementing the value on the card are hereinafter referred to as “spend value” devices.
  • bit card as used herein will be understood to refer to a card which is used to transfer funds directly from a cardholder's identifiable bank account, usually via an on-line transaction from an ATM or other suitable terminal.
  • stored value card as used herem will be understood to refer to cards in which a certain predetermined value is installed directly on the card itself and which can be expended by the cardholder without requi ⁇ ng an on-line transaction. Stored value systems can be generally classified into one of three types:
  • on-line systems (2) off-line systems; and (3) hybrid systems.
  • an on-line transaction occurs between the spend value device and a central computer.
  • the central computer is thus able to verify prior to authorizing the transaction that the inserted card has been properly valued, and that the proposed transaction can proceed.
  • a major drawback of such systems is the overhead of on-line communications, including cost of the equipment and communication delays. It would thus be extremely expensive, for example, to provide a communication link between a central computer and every vending machine which accepts stored value cards.
  • An off-line stored value system allows purchases to be made without an on-line authorization.
  • the spend value device e.g., a vending machine
  • a successful transaction occurs, even if the value on the card was fraudulently installed or increased.
  • a major drawback of conventional off-line systems is the lack of security and a resulting potential for fraudulent transactions. It may be possible to mitigate this lack of security in certain circumstances by providing security features intrinsic to the stored value card itself and security features in revalue devices used to install value on the cards.
  • security features intrinsic to the stored value card itself such as a cash-to-card machine
  • revalue devices used to install value on the cards.
  • a crook is able to defeat a single revalue device (such as a cash-to-card machine) and cause it to produce newly revalued cards, or is able to persuade a crooked clerical employee to fraudulently add value to cards without requiring a corresponding payment, the entire system can still be defeated.
  • the present invention contemplates a "hybrid" system in which revalue transactions are performed on-line with a central computer server, but in which spend value transactions are performed in an off-line manner. Records of the off-line transactions are stored and transmitted back to the central computer server for later off-line settlement with accounts which track the on-line valuations.
  • Such a scheme maximizes security by (1) ensuring that stored value cards cannot be fraudulently valued, (2) ensuring that all spend value transactions are eventually "settled” widi accounts maintained in a central computer, and (3) providing auditable information which allows suspicious trends to be followed and security breaches detected.
  • a first merchant may provide a variety of vending machines which accept stored value cards; a second merchant may provide a group of photocopiers which accept stored value cards; and a third merchant may provide retail point-of-sale (RPOS) terminals which accept stored value cards in addition to credit and debit cards.
  • RPOS point-of-sale
  • the present invention solves the aforementioned problems by providing a stored value system in which revalue transactions are performed in an on-line manner, but in which spend value transactions are performed off-line. Records of the off-line transactions are later collected, consolidated, and settled against individual accounts in a manner which prevents any individual account from being traced to a pa ⁇ icular cardholder, thus assuring cardholder anonymity and avoiding onerous banking regulations.
  • Such a "closed loop" approach overcomes problems associated with entirely off-line systems without compromising cardholder privacy.
  • the system of the present invention may include so-called “intelligent card readers” as described and disclosed in copending parent application serial number 08/414,495, filed on March 31 , 1995, entitled “Intelligent Card Reader Having Emulation Features", which is incorporated by reference herein.
  • intelligent card readers allows the card-based devices herein to accept a variety of different types of sma ⁇ cards. Details of various types of vending machine card readers, public and private kiosk card readers, multimachine controllers and the like are described in more detail in the aforementioned copending application and are not repeated here.
  • a stored value account number is created as a function of a unique sma ⁇ card identifier, and a corresponding account having a balance is established in a stored value server.
  • Each account is thus associated with a specific sma ⁇ card, but the account is not directly traceable to any pa ⁇ icular cardholder.
  • a single cash pool is maintained at a financial institution which corresponds to the sum of all the balances of the anonymous account numbers.
  • Off-line transactions may be collected from vending machines and the like through one or more transaction collection devices which batch together multiple transactions for later transmission to a transaction concentrator, which in turn provides the transactions to the stored value server.
  • a transaction concentrator which in turn provides the transactions to the stored value server.
  • FIG. IA shows in simplified form various principles of the invention relating to the transfer of funds from individual cardholder bank accounts to merchant bank accounts.
  • FIG. IB shows in simplified form steps which may be performed to carry out various principles of the invention.
  • FIG. 2 depicts in more detail one possible implementation of a stored value system corresponding to element 100 of FIG. IA.
  • FIG. 3 shows relevant po ⁇ ions of one possible file stnicture for storing data on each stored value card.
  • FIG. 4 shows various steps of a method which may be carried out to add value to a card.
  • FIG. 5 shows various steps of a method which may be carried out to spend value on a card which has been previously valued.
  • FIG. 6 shows various steps of a method which may be carried out to download and settle off-line transactions.
  • FIG. 7 shows one possible arrangement for implementing computer processes on a stored value server to carry out the principles of the invention.
  • FIG. 8 illustrates one possible approach for creating a stored value account number (SVAN).
  • FIG. 9 shows one possible configuration for a revalue device such as a public kiosk.
  • FIG. IA shows in simplified form a system employing various principles of the invention.
  • a stored value system 100 (shown in more detail in FIG. 2) is coupled to a cash pool account 101 at Bank A, which may comprise a commercial checking account owned by the stored value system provider.
  • the stored value system 100 is also coupled to one or more financial networks 102 through which various financial transactions such as debit or credit transactions may be initiated. Transactions in such a network may be effected by using financial service providers such as Gensar (one regional financial service provider) who provide such services.
  • Gensar one regional financial service provider
  • Each cardholder may optionally maintain a regular bank account 103 which is coupled to one of the financial networks 102 in order to transfer funds from the cardholder's account to the cash pool 101. It is not necessary for a cardholder to maintain such a bank account if the cardholder always uses "hard” currency to revalue a stored value card.
  • Cash pool account 101 may also be coupled to an Automated Clearing House (ACH) network 105 to facilitate transfers of funds from the cash pool account 101 to merchant accounts 104 maintained at other banks.
  • ACH Automated Clearing House
  • stored value system 100 generates requests to transfer funds from cardholder accounts 103 to cash pool account 101 as pan of a revalue transaction. Off-line spend value transactions using cardholders' stored value cards are batched and so ⁇ ed according to specific merchants, and corresponding fund transfers are initiated from stored value system 100 to effect fund transfers from cash pool 101 to individual merchant accounts 104 maintained at other banks.
  • the bank at which cash pool account 101 is maintained may also transmit account activity and balance reports back to stored value system 100.
  • Stored value system 100 includes a stored value server 201 (shown in FIG.
  • FIG. IB shows in simplified form various steps which may be carried out in accordance with the system shown in FIG. IA. Beginning in step 120, an anonymous stored value account number is created, preferably using a cryptographic function based on a unique card identifier such as a serial number (details of these steps are described in more detail herein).
  • SVAN unique card identifier
  • step 121 the SVAN is written to a stored value card, and an account having a zero or a predetermined balance is created in a database in stored value server 201.
  • the step of creating many different SVANs may be carried out at a card production facility long before the cards themselves are to be used: the SVANs may be transferred to the stored value server in bulk via floppy disk or the like.
  • the end result of performing steps 120 and 121 is that SVANs are installed on stored value cards and corresponding accounts are created in stored value server 201 with zero or predetermined balances.
  • the total value of all balances in the stored value accounts maintained in stored value server 201 should equal the account balance in cash pool 101.
  • the stored value server does not maintain a record of the cardholder's identity (such as name, address, social security number, or the like) in coimection with the SVAN; the expendimre of funds in each stored value account is uniquely associated with the SVAN and not any pa ⁇ icular cardholder.
  • the stored value card is nearly as vulnerable as carrying cash. The latter problem can be mitigated somewhat by requiring the entry of a PIN prior to performing certain high- value spend value transactions.
  • step 122 a cardholder inserts a stored value card into a revalue device and inserts hard currency into a bill acceptor.
  • step 123 the cardholder may perform a debit transaction using his bank debit card to transfer funds from his bank account.
  • the cardholder's regular bank account number may be pre-stored on a magnetic stripe on the back of the stored value smart card itself. This allows a single card to be used to transfer funds from a bank account to the stored value account.
  • a credit transaction may be performed in step 124 in which the customer's credit card account is used to transfer funds on margin.
  • the cardholder's credit card information may be stored on a magnetic stripe on the stored value card itself, or it may be programmed in the stored value card.
  • an on-line transaction occurs in step 125 to credit the SVAN account in the stored value server corresponding to the stored value card which was inse ⁇ ed.
  • the cardholder inserts hard currency into a stored value machine, no value will be added to the stored value card until after an on-line communication between the revalue device and the stored value server takes place.
  • the SVAN is verified and then credited
  • step 126 the credited value is also written to the stored value card using an electronic purse function which is well known in the an. After value has been added to the card and a corresponding credit added to the SVAN at the server computer, the card is ejected and the cardholder is free to spend the value on the card.
  • the cardholder may spend value on the card in any of a variety of spend value devices using off-line transactions as described in more detail herein.
  • the cardholder may use me card in vending machines, photocopiers, or RPOS terminals equipped to handle the cards. These transactions result in the value stored on the card being decremented, but no on ⁇ line communication with the stored value server takes place. It is, however, within the scope of this invention to also allow on-line spend value transactions, such that the system can suppo ⁇ a mixture of off-line and on-line transactions.
  • steps relating to the collection of off-line transactions can be omitted. For example, there would be no need to store in a vending machine a record of an on-line transaction.
  • each spend value device accumulates off-line spend transactions over a period of time, such as a day or a week.
  • the accumulated transactions are transferred to the stored value server using devices such as those shown in FIG. 2, or using store-and-forward techniques.
  • settlement occurs both with the stored value accounts in the server and with merchant's accounts which may be at the same or other banks.
  • This settlement step includes decrementing value of the SVANs in the stored value server by the amount of spend value transactions which have been accumulated in various devices, and also so ⁇ ing out credits to be applied to the various merchants whose spend value devices were used. For example, the value of all transactions conducted at a pa ⁇ icular merchant's vending machines is accumulated and then credited to the merchant's bank account (see FIG. IA).
  • FIG. 2 shows in more detail one possible embodiment for the stored value system 100 depicted in FIG. IA.
  • Card production facility 200 initializes a plurality of stored value cards and creates a unique SVAN for each card.
  • One possible method of generating a SVAN is to use a cryptographic function based on the serial number of each card. For example, a triple DES (Data Encryption Standard) operation may be performed using a privacy key to generate a unique anonymous SVAN for each card based on the card's serial number.
  • the SVAN is written to the card and also to a medium such as disk Dl , preferably in batches. Issued cards thus have an SVAN installed on them, and the SVANs are transmitted to stored value server 201 as shown in FIG. 2.
  • Stored value server 201 receives the SVANs and stores them in a database 201a, such as a relational database. Each SVAN has an associated balance as illustrated in 201a. Balances may be initially set to zero and then increased when revaluing a corresponding card; alternatively, each card may be provided with an initial balance. Stored value server 201 thus maintains a record of balances for each SVAN in an anonymous manner. Stored value server 201 may be coupled to a cash pool and to financial networks as illustrated in FIG. IA. Additionally, stored value server 201 is preferably connected to a network 213 which may comprise a LAN or WAN.
  • a network 213 which may comprise a LAN or WAN.
  • a transaction concentrator 202 also coupled to network 213, collects off-line transactions from various spend value devices and transmits the transactions to stored value server 201, preferably over network 213.
  • Transaction concentrator 202 may collect off-line spend value transactions from media such as disk D2, or through direct connection from various spend value devices 203.
  • Spend value device 203 which represents any of a variety of devices such as vending machines and the like, includes a card reader which accepts stored value cards previously initialized by card production facility 200.
  • Vending machines 210 and 211 include a vending control reader which may be of a type described in copending parent application serial number 08/414,495, inco ⁇ orated by reference herein. Such readers can accept sma ⁇ cards of various types and operate vending machines such as those conforming to the MC 5000, MC 5800, or multidrop standards, the particular control lines being selected to suit the specific vending machine type. In various embodiments, these readers comprise a microcontroller which executes a "spend value" process which is described in more detail herein.
  • the vending control readers may be any type of sma ⁇ card reader which controls the vending machine in response to insertion of a stored value card and maintains a log of all transactions.
  • each vending control reader verifies that an inse ⁇ ed card is authentic, dispenses a product or service in response to a cardholder's selection, and decrements the value on the stored value card by a corresponding amount. Additionally, a transaction record containing the SVAN is created in the machine for later off ⁇ line settlement.
  • Each vending machine may also include a Secure Application Module (SAM) which performs card authentication and other security features associated with an inse ⁇ ed card.
  • SAM Secure Application Module
  • each SAM contains a unique number which is stored in each transaction record and which allows the transaction to be later associated with a pa ⁇ icular merchant. For example, a merchant who owns a group of 5 vending machines can be provided with 5 SAMs to install in the machines. Each of the SAMs may contain a unique identifier which, when stored into a transaction record, allows the transaction to be traced back to the merchant when the transaction is settled in stored value server 201.
  • Photocopier 209 also includes a vending control reader which operates the photocopier in response to the insertion of a stored value card. Other types of spend value devices, such as washing machines and the like, are of course possible.
  • a Retail Point of Sale (RPOS) terminal 208 is provided with a card reader and (optionally) a SAM, and operates in a manner similar to the vending machines.
  • the terminal may include a cash register type of device which calculates a total amount to be purchased and a card reader which accepts a cardholder's stored value card.
  • RPOS terminal 208 causes the value on the card to be decremented by the amount of the purchase and creates a transaction log record for later off-line settlement.
  • Public kiosk 206 may comprise a terminal located in a public location which includes a card reader and (optionally) a SAM. This public kiosk may provide services such as the sale of info ⁇ nation or the installation of various applications such as a meal plan on the card. Additionally, a cardholder may order goods and services such as a pizza or the like using his stored value card at d e kiosk. The kiosk generally allows the cardholder to select various goods or services, and generates a receipt.
  • Private kiosk 207 may comprise a home computer which is equipped to accept stored value cards, and may provide a limited set of services which differs from those offered at public kiosk 206.
  • Transaction collection device 212 may be coupled to all of the above described spend value devices through one or more links 214 such as RS-232, RS-485, a LAN, or the like.
  • links 214 such as RS-232, RS-485, a LAN, or the like.
  • transactions which are stored in each spend value device may be transmitted over link 214 to transaction collection device at predetermined intervals, such as daily.
  • Transactions which have been downloaded into collection device 212 may be offloaded to a disk D2 and subsequently transfe ⁇ ed to transaction concentrator 202. In this manner, efficient collection of transaction information may be achieved.
  • each spend value device may be provided with a disk unit to individually offload stored transactions. Other variations are of course possible.
  • spend value devices may be directly connected to network 213, or to one or more transaction concentrators 202 such as illustrated in FIG. 2.
  • Cash to card device 204 includes a bill acceptor 204a which allows a cardholder to add value to a stored value card by inse ⁇ ing hard currency.
  • an on-line transaction with stored value server 201 occurs to ensure that the SVAN on the card is valid, and to store a corresponding balance amount in database 201a in the stored value server.
  • 204 also preferably includes a door open detector 204b which transmits a message to stored value server 201 when the device is opened.
  • This message may be time stamped and used to coordinate door openings with maintenance operations in order to prevent fraud. For example, revalue operations which occur while the door is open, or after the door has been opened during a non- maintenance period, can be identified as suspicious and an appropriate ale ⁇ can be generated to prevent further on-line card valuations from that device.
  • Public kiosk 205 may be physically the same type of unit as public kiosk 206, but configured to include the ability to revalue a stored value card. For example, it may include the ability to read a magnetic stripe from a debit card or credit card in order to add value to a stored value card. Alternatively, it may include a hybrid card reader which uses a magnetic stripe on the stored value card itself to extract bank account information in order to perform a revalue operation.
  • the devices coupled to network 213 may use a DCE/Encina client-server protocol to perform transactions over the network.
  • network 213 may be connected to another network (not shown) of another such system through a gateway, such that transactions can be processed across systems. This would allow, for example, a student who purchases a stored value account card for use at one campus to use the card at a second campus at a second geographic location and still provide for settlement of transactions.
  • This section describes generally how cards may be initialized in the system, and various data structures which may be used to hold information on the cards.
  • MPCOS card produced by
  • the MPCOS card uses encryption keys and secret codes for security pu ⁇ oses. These security features may be used to provide message and data security for storage and transfer. Other types of cards may of course be used.
  • the stored value card preferably provides an intrinsic stored value function (electronic purse) which is protected using encryption/decryption techniques based on keys which may be derived from a unique issuer serial number or from the SVAN.
  • Payment security functions preferably include secure messaging and cryptographic ce ⁇ ificate verification based on cryptographic payment keys.
  • Electronic purse transactions are preferably protected by payment keys stored on each card which are unique to the card.
  • a ce ⁇ ificate verification derivation key is preferably known to all SAMs.
  • cryptographic keys are not directly stored in revalue or spend value devices, but instead are protected within each SAM associated with the devices. All purse transactions that result in a change to the purse balance preferably use a cryptographic key for secure messaging.
  • the stored value account number (SVAN) generated and stored on each card may be generated using a cryptographically derived number which is unique on every card. In various embodiments, this number may be generated by performing a "triple DES" function on the card's serial number using a protected privacy key.
  • the resulting number (SVAN) is then stored onto the card and also transmitted to the stored value server, preferably in batches on media such as a floppy disk.
  • a cardholder's identity is not maintained in connection to a SVAN; however, it may be generally desirable to maintain a cardholder's identity in connection with an issuer serial number associated with a particular card. Because the SVAN may be generated from the issuer serial number using an encipbe ⁇ nent process, the SVAN can, in various embodiments, be linked to the last four bytes of the issuer serial number when using a cryptographic key for SVAN calculation.
  • this association could be used to help trace a card back to a pa ⁇ icular card serial number (e.g., if supplied with the key used to generate the original SVAN, a reverse operation could be performed to restore the last 4 bytes of the issuer serial number, which could help trace the number to a pa ⁇ icular card).
  • a data strucmre is preferably defined on the card to maintain the 10 most recent financial transactions. For security reasons, it may be desirable to require that the cardholder enter a PIN before certain information on the card is allowed to be read by a device (for example, the transaction log). This provides some measure of protection for lost or stolen cards.
  • FIG. 3 shows relevant po ⁇ ions of a file strucmre 301 for storing information relating to the stored value application on the cards.
  • the file strucmre includes, in relevant pan, a group of stored value files 302 and one or more bank files 303. It will be recognized that this strucmre is exemplary only and various different strucmres are of course possible. The following describes in more detail data which may be stored in these files.
  • KCT a control key file which contains a stored value control key used to create files, download cryptographic keys, passwords, and the like.
  • KAD authentication, certification, and debit key file which contains an authentication key, a certification key used for off-line debit, and an on-line debit key.
  • KCR (306) stores a key used for enabling a purse credit function and for computing a credit cryptogram.
  • PUR (307) a purse file, which may be supplied by the smart card vendor, used to store the card's monetary value.
  • the purse file can be loaded either from a cash-to-card process or from an on-line debit from a cardholder's financial institution such as a bank identified in bank files 315.
  • Various sma ⁇ card vendors, such as Gemplus, may allow only indirect access to purse files on the card.
  • TXL (308) a transaction log file used to store the 10 most recent transactions of the card's stored value file. Each transaction entry may include for example the following information:
  • transaction ce ⁇ ificate includes SVAN
  • DFC (309) cardholder data file which is used to store the stored value account number (SVAN).
  • Bank Files (303) contains cardholder banking information such as checking account number, credit card numbers, etc. (This information may also be stored on a magnetic stripe on the sma ⁇ card itself). Although not shown explicitly in FIG. 3, each card may also contain a transaction counter which is incremented for each transaction.
  • Stored value cards may be initialized at a first level by the card manufacmrer, such as Gemplus.
  • the card manufacmrer can initialize the card so that secure messaging is required to create files, and to write and update the files created.
  • the manufacturer can install a card serial number and issuer reference number.
  • Stored value cards may be initialized at a second level by the card issuer, such as the entity that installs and operates the stored value system.
  • This second- level initialization can be protected through the use of secure procedures which require that a card be authenticated before certain information is installed on the card.
  • personalized information can be installed, as well as the creation of other files such as those shown in FIG. 3 preferably using secure techniques to prevent fraudulent card creation. Provisions may also be made for de-activating a previously initialized card. 3. ADDING VALUE TO A CARD
  • value may be generally added to a stored value card in one of three ways: (1) inse ⁇ ing cash into a cash-to-card machine: (2) performing a debit transaction between the cardholder's personal bank account and the cash pool maintained by the stored value provider, or (3) performing a credit transaction between the cardholder's credit account at his bank and die cash pool maintained by the stored value provider.
  • This section describes in more detail how value may be added to a card using the SVAN in a manner which prevents the cardholder's account from being associated with individual purchases traceable to the cardholder.
  • SAM Secure Application Module
  • both the cash-to-card device 204 and die public kiosk 205 shown in FIG. 2 preferably include such a SAM for providing security features, it will be appreciated d at cards can be revalued without the use of such a SAM. Accordingly, two different methods are described herein; the first method assumes that the revalue device includes a SAM, while the second method assumes that the revalue device does not include such a SAM.
  • Each SAM may be implemented either in hardware or in software, and generally provides certain cryptographic services to support the device into which it is installed. A detailed description of each revalue process (with SAM and widiout SAM) appears separately below.
  • FIG. 7 shows one possible context in which card revaluation may be performed.
  • FIG. 7 shows various databases and computer processes which may reside on stored value server 201 (see FIG. 2).
  • a revalue control process 701, financial network access process 702, and SVAN account database 703 may be implemented to carry out the process described in more detail below.
  • stored value account numbers may be received from a disk into a maintenance process 713, which creates entries in SVAN account database 703.
  • Messages from revalue devices can be processed by revalue control process 701, which, in cooperation with financial network access process 702, performs the necessary bank transfers to transfer funds from a cardholder's p ⁇ vate bank account to the cash pool account 101 (see FIG. 1) and diereafter credits the conesponding SVAN in database 703. Further details of FIG. 7 are explained below with respect to spending value from me cards and transaction settlement.
  • FIG. 4 shows va ⁇ ous steps which can be performed at a revalue device (such as cash-to-card device 204 or public kiosk 205) to add value to a stored value card in d e case where the revalue device includes -a SAM.
  • a revalue device such as cash-to-card device 204 or public kiosk 205
  • the stored value card is activated.
  • this step could mclude the step of determinmg what type of card was inserted, and initializing software pointers m the card reader to support the specific type of card inserted.
  • Step 401 includes steps of checking the answer-to-reset data supplied by die card, selecting the stored value file (DFC in FIG. 3) and reading die SVAN from this file, and requesting that the SAM derive the conect key from the issuer serial number or SVAN for the particular card.
  • the revalue device can authenticate the smart card and communicate encrypted data with die smart card.
  • step 402 the stored value card is audienticated through the use of the SAM.
  • This step generally includes requesting a random number from die SAM, sending die random number to d e card, having the card encipher the random number and requesting that the SAM also encipher the random number, men requesting that the SAM compare the enciphered number returned from die card with d at enciphered in the SAM. If the results match (i.e. , the comparison is favorable), the card is deemed to have been audienticated.
  • Such authentication techniques are well known.
  • the cardholder specifies a revalue amount dirough the use of a suitable input device such as a keyboard or touch-panel display, and, if die cardholder is using die cardholder's own bank account to transfer funds, d e cardholder enters his PIN to be used with his normal bank account (this is not to be confused widi a PIN or password which can be stored on die card itself). If the cardholder is using a credit card or cash to transfer funds, no PIN need be provided, aldiough it is within the scope of the invention to also require a PIN for credit transactions. If either the cardholder's debit account or credit card account are used, die appropriate bank information can be read from me appropriate bank file (see FIG. 3) or from a magnetic stripe on the sma ⁇ card itself. If the cardholder inserts hard currency into the machine, the machine itself can determine die revalue amount.
  • a suitable input device such as a keyboard or touch-panel display
  • Step 404 includes steps of reading die purse value from e card, verifying that die amount requested plus die current purse value on die card does not exceed a maximum balance for the card, and aborting the transaction if the maximum purse value would be exceeded. Additionally, a card transaction counter and card balance certificate is obtained from the card in order to ensure non-repudiation (i.e., it allows die system to prove that the transaction came from that particular card and prevents unauthorized changes to the card balance amount; me card transaction counter also ensures that transactions such as loading value on a card cannot be replayed). In various embodiments, me card balance ce ⁇ ificate may be provided as a function by the smart card vendor (e.g. , Gemplus).
  • the smart card vendor e.g. , Gemplus
  • step 405 a request message to validate die funds transfer operation is created, audienticated, encrypted, and transmitted on-line to me stored value server (element 201 in FIG. 2). This generally includes steps of encrypting d e
  • the stored value server decrypts die request, verifies the MAC, verifies the balance certificate, and verifies that the SVAN from the card exists in database 201a and diat the accumulated balance is not less dian zero (if so, an unaudiorized revalue might have taken place and appropriate reporting may be initiated).
  • the stored value server initiates a funds transfer request through a financial network
  • die stored value server prepares a credit certificate for the card, and authenticates and encrypts die response message to the revalue device.
  • stored value server 201 may include a SAM to perform the security-related features.
  • Step 407 includes steps of decrypting d e response message in the revalue device, extracting and verifying the MAC, transmitting a credit ce ⁇ ificate to d e stored value card, verifying in die stored value card d at die credit ce ⁇ ificate is valid, and, if valid, updating die current balance (i.e., updating die purse file), and obtaining a transaction ce ⁇ ificate in d e card.
  • the generation and verification of credit ce ⁇ ificates is well known in the an (the MPCOS card provides proprietary functions for performing these operations which differ in some respects from conesponding ISO standards), and a detailed explanation of d at po ⁇ ion of the operation is omitted.
  • step 408 a record is written to the transaction log on die card (including die transaction ce ⁇ ificate), and die card is ejected from die revalue device.
  • a completion message is generated in d e revalue device and encrypted for transmission back to the stored value server.
  • This step includes steps of calculating a MAC, inse ⁇ ing a ce ⁇ ificate obtained-from the card which confirms that the card has been revalued, authenticating the message, encrypting the message, and transmitting the encrypted message to d e stored value server over a network.
  • a revalue device (such as cash-to-card device 204 or public kiosk 205) can also be used to add value to a stored value card in the case where the revalue device does not include a SAM.
  • keys maintained in d e stored value server and on die card may be used to encrypt data between the two, with the revalue device merely "passing dirough" the encrypted data.
  • FIG. 5 illustrates steps which may be performed to spend value on a previously valued card.
  • a SAM is provided in each spend value device to assist in certain security functions
  • d e explanation below assumes that such a SAM is provided.
  • d e use of a SAM may not be required, and die steps below can be performed as explained above to omit a SAM.
  • step 501 a stored value card inse ⁇ ed into a spend value device is activated in a manner similar to step 401 of FIG. 4.
  • step 502 the inse ⁇ ed card is authenticated to ensure d at die card can be initially trusted. This step is similar to step 402 of FIG. 4. Additionally, the available balance on the card may be displayed on die spend value device.
  • the purchase amount is determined.
  • die cardholder may make a selection which generates a signal indicating the amount of me selected item.
  • a cash register may generate a total indicating the accumulated value of a purchase.
  • a signal may be generated indicating a standard cost (e.g., 10 cents) for each dispensed copy. Other variations are of course possible.
  • step 504 ihe purchase amount is compared wi the available balance on the card.
  • the cardholder may be required to enter a password (PIN) which is compared to the pre-stored PIN on the stored value card. If die purchase amount exceeds me available balance, the transaction is abo ⁇ ed and die card returned to the cardholder. In step 505, die purse on the card is debited.
  • PIN password
  • a card transaction record is created containing fields such as d ose described widi reference to FIG. 3 and stored into the transaction log on the card (TXL file). This log may be viewed by the cardholder when die card is inserted into a machine.
  • a transaction record is created and stored in a transaction log in the spend value device itself. This may include steps of calculating a message authentication code (MAC), encrypting the transaction data, and storing the encrypted record in the spend value device.
  • the transaction record stored in the spend value device may, in various embodiments, include more information than that stored on the card itself. For example, the following information may be included in d e device's transaction log:
  • terminal transaction counter (a one-up counter) 8. time stamp
  • storing die SAM serial number of the spend value device allows a transaction to be credited to die merchant who owns or operates the device.
  • the stored value system provider provides SAMs to merchants to control the generation of encrypted transaction records in order to prevent unscrupulous merchants from fraudulently generating spend value transactions.
  • identifiers such as a merchant code or machine identifier may be used.
  • each spend value device maintains a "current transactions" buffer 210b (see FIG. 2) which records transactions which have occurred since the last download operation from the device was performed, and a "previous transactions" buffer 210a (see FIG. 2) which retains the previous batch of transactions which were downloaded.
  • a verification is preferably generated for the spend value device which indicates that d e previous transactions were actually received and stored in the stored value server and that the conesponding "previous transactions" buffer can be deleted. This principle - 26 - is explained in more detail in the next section.
  • step 508 the product or service selected by die cardholder is dispensed or odierwise provided to the cardholder. It will be recognized that diis step need not be performed at diis pa ⁇ icular stage in the process; it could occur before step 507 or earlier, for example.
  • FIG. 6 shows various steps which may be carried out to collect and settle transactions.
  • FIG. 2 shows a system containing devices for implementing these steps
  • FIG. 7 illustrates various computer processes which may be implemented for carrying out these steps.
  • each spend value device may be coupled via a communication link to a transaction collection device 212 such as a PC -compatible computer.
  • a transaction collection device 212 such as a PC -compatible computer.
  • die spend value devices may download a current buffer of transactions to the transaction collection device. This may be done on an hourly, daily, weekly basis or the like, or upon demand.
  • Transaction collection device 212 may collect multiple batches from different devices and store the combined batches on a medium such as disk D2. Thereafter, the medium may be inserted into a transaction concentrator 202 which can accept disks from many different transaction collection devices and fu ⁇ her download d e transactions into stored value server 201 over a network 213.
  • spend value devices such as device 203 may direcdy download transactions into transaction concentrator 202 as shown in FIG. 2.
  • transaction collection device 212 may be connected directly to network 213 to download batches of transactions into stored value server 201.
  • d e net result is diat batches of transactions previously logged off line in die spend value devices are loaded into stored value server 201 for settlement.
  • step 601 indicates that batches of transaction logs from the spend value devices are transfened to a collection device such as 212 or 202 as explained above.
  • each spend value device which has downloaded its cunent transaction log switches over its transaction log buffer to a second "cunent" buffer, and designates the downloaded buffer as "previous transactions" .
  • each spend value device preferably maintains a copy of the old transactions in the event that diey are not successfully loaded into stored value server 201.
  • step 603 batches of transaction logs which have been received from transaction concentrator 202 (or transaction collector device 212) are transferred to die stored value server 201.
  • a transaction batch receiver process 704 in stored value server 201 receives batches of transactions, decrypts each transaction and verifies die MAC for each, and stores d em into a database 705.
  • each transaction extracted from database 705 is posted against die stored value account corresponding to die transaction.
  • die SVAN for each transaction is extracted from the transaction record, and die balance of die conesponding account in SVAN account database 703 is decremented by die amount of die transaction.
  • Other steps of verifying die authenticity of each transaction are also included but not explicidy shown in FIG. 6.
  • an off ⁇ line certificate can be generated by die card during a card decrementing operation, and die certificate verified by a SAM in the spend value device. After verifying this off-line certificate, die spend value device can request diat the card generate an on-line ce ⁇ ificate using a key which is not known to the SAM, but which is known to the computer server which wUl eventually settle the transaction in an on-line process. This prevents can help prevent fraudulent generation of transaction ce ⁇ ificates by someone who steals a SAM.
  • step 605 transactions which have been newly posted in die database are so ⁇ ed by merchant in process 706, preferably based on d e SAM serial number extracted from each transaction record.
  • the conelation between SAM serial number and merchant identifier can be stored in a merchant information database 712.
  • the result of this step is that all newly posted transactions are so ⁇ ed by merchant and accumulated in value (i.e., die value of all transactions attributable to a pa ⁇ icular merchant are added togedier).
  • each merchant can be paid using a merchant repayment process 709 which extracts merchant bank account information from database 712 and initiates a funds transfer using ACH process 708.
  • This step may also include a human review of me payments before authorizing die bank funds transfer.
  • reports may be optionally generated to send to die merchants showing a detailed breakdown of sales per device and die like.
  • An accounting package 710 may be used to generate statistical analyses and die like as desired.
  • a "buffer verified" indication is generated eidier by storing a flag on a disk D2 used for later collection, by transmitting a message over network 213, or the like, to indicate to each spend value device diat die
  • "previous transactions" buffer may be discarded. This indication may be conveniently combined wim die next round of transaction collections, such that the step of transaction collection begins with a verification that die previously downloaded transactions have been properly posted.
  • an anonymous stored value account number may comprise 12 bytes that uniquely identify a stored value card. It is apparent, however, that fewer or more than 12 bytes may be used.
  • FIG. 8 illustrates one possible method for deriving a SVAN in die manner described below. The first two bytes may be set to zero, and the last eight bytes can be derived by enciphering th ⁇ issuer serial number using a double lengdi privacy key as follows:
  • the issuer reference number may be used to identify die geographic location of the system, such as a campus identifier or a company location identifier.
  • a card preparation SAM may be used to prepare cards, including deriving various types of keys. 7. REVALUE DEVICE DESIGN
  • the revalue device 901 generally includes a processor 902 and memory 903 for storing control programs and information needed to execute various steps described elsewhere in mis specification.
  • SAM 910 is coupled to processor 902 and generally provides security functions such as key storage and derivation, audientication, ce ⁇ ification, and encryption/decryption functions.
  • a hybrid card acceptor 906 accepts microprocessor-equipped sma ⁇ cards which may also have a magnetic stripe. This allows certain bank information to be stored on die magnetic stripe in a manner compatible with existing debit cards, and diis information may be used to perform an on-line debit operation in e revalue device.
  • Control circuit 905 generally performs card reader-related functions, augmented slighdy to handle die magnetic stripe information from cards so equipped.
  • An encrypted PIN pad 907 may be used to enter a PIN for cardholder verification.
  • a receipt printer 908 generates receipts for products or services purchased by die cardholder.
  • An input device 909 may comprise a keyboard or the like, or alteratively display 904 may comprise a touch-panel display which performs these functions.
  • Processor 902 may be coupled to a nerwork such as network 213 shown in FIG. 2.

Abstract

A stored value transaction system includes a computer having a database of stored value accounts identified by an anonymous account number (i.e. not correlated with any particular cardholder). Using an on-line transaction with the computer database, cash equivalent value can be added to smart cards (C) onto which corresponding anonymous account numbers have been written. Properly valued cards can then be used in off-line transactions at various types of spend value devices such as vending machines, photocopiers and the like. The off-line transactions from the spend value devices (206, 207, 208, 209, 210, 211, 212) are collected and settled with the account numbers in the anonymous database, thus ensuring system integrity in an off-line system. The settled transactions are sorted by merchant and payment is made to the merchants based on accumulated transactions. The system also includes an efficient transaction collection approach.

Description

STORED VALUE TRANSACTION SYSTEM AND METHOD USING ANONYMOUS ACCOUNT NUMBERS
This application is a continuation-in-part of U.S. application serial number 08/414,495, filed on March 31 , 1995, which is incoφorated by reference herein. BACKGROUND OF THE INVENTION
1. Technical Field
This invention relates generally to so-called "stored value" systems which use smart cards (i.e. , cards having an embedded microprocessor) to replace cash. More particularly, the invention provides a system in which smart cards can be used to perform financial transactioas wherein individual transactions can be settled against a cardholder's account balance while preventing the cardholder's account number or balance from being traced to the cardholder.
2. Related Information
The use of smart cards to perform cashless transactions in systems is well known. These systems typically provide a way for a cardholder to install a fixed amount of cash equivalent value onto a smart card and to spend the value on the card by inserting the card into any of various types of devices, such as vending machines. After the value on a card is exhausted, the cardholder may "revalue" the card by inserting it into a cash-to-card machine and then inserting cash, a debit card, or a credit card to transfer additional funds to the smart card.
Smart cards which electronically hold a cash equivalent value are hereinafter referred to as "stored value" cards. One example of such a card is the Gemplus MPCOS card, made by Gemplus Card International. Devices which install or increase value on stored value cards, such as a cash-to-card machine, are hereinafter referred to as "revalue devices". Devices which accept stored value cards and dispense a product or service in exchange for decrementing the value on the card are hereinafter referred to as "spend value" devices.
The term "debit card" as used herein will be understood to refer to a card which is used to transfer funds directly from a cardholder's identifiable bank account, usually via an on-line transaction from an ATM or other suitable terminal. In contrast, the term "stored value card" as used herem will be understood to refer to cards in which a certain predetermined value is installed directly on the card itself and which can be expended by the cardholder without requiπng an on-line transaction. Stored value systems can be generally classified into one of three types:
(1) on-line systems; (2) off-line systems; and (3) hybrid systems. In an entirely on-line system, each time a card is used to make a purchase in a spend value device, an on-line transaction occurs between the spend value device and a central computer. The central computer is thus able to verify prior to authorizing the transaction that the inserted card has been properly valued, and that the proposed transaction can proceed. A major drawback of such systems is the overhead of on-line communications, including cost of the equipment and communication delays. It would thus be extremely expensive, for example, to provide a communication link between a central computer and every vending machine which accepts stored value cards.
An off-line stored value system allows purchases to be made without an on-line authorization. In an entirely off-line system, when a stored value card is used to make a purchase, the spend value device (e.g., a vending machine) decrements a value directly on the card in exchange for a product or service. As long as a card which appears to be properly valued is inserted into the machine, a successful transaction occurs, even if the value on the card was fraudulently installed or increased.
A major drawback of conventional off-line systems is the lack of security and a resulting potential for fraudulent transactions. It may be possible to mitigate this lack of security in certain circumstances by providing security features intrinsic to the stored value card itself and security features in revalue devices used to install value on the cards. However, to the extent that a crook is able to defeat a single revalue device (such as a cash-to-card machine) and cause it to produce newly revalued cards, or is able to persuade a crooked clerical employee to fraudulently add value to cards without requiring a corresponding payment, the entire system can still be defeated. For example, if a crook steals a cash-to-card machine and cracks it open, it may be possible to insert a single $20 bill repeatedly to "revalue" many valid stored value cards. Thus, even if a crook is unable to defeat the data security scheme used to install value on the card or crack cryptographic data stored on the card, cards can still be fraudulently revalued. Accordingly, off-line systems are considerably more vulnerable to theft.
The present invention contemplates a "hybrid" system in which revalue transactions are performed on-line with a central computer server, but in which spend value transactions are performed in an off-line manner. Records of the off-line transactions are stored and transmitted back to the central computer server for later off-line settlement with accounts which track the on-line valuations. Such a scheme maximizes security by (1) ensuring that stored value cards cannot be fraudulently valued, (2) ensuring that all spend value transactions are eventually "settled" widi accounts maintained in a central computer, and (3) providing auditable information which allows suspicious trends to be followed and security breaches detected.
One major problem in implementing a so-called hybrid system is the need to avoid becoming a "bank". The United States government imposes strict regulations which require that entities which provide banking services to individuals must provide monthly statements and receipts for transactions, and must cover certain losses. Therefore, if each cardholder in a stored value system is provided with an identifiable account number which is credited with value in a central computer and later debited in the central computer when a transaction takes place, the arrangement appears to be similar in many respects to a bank (i.e., spend value transactions become very similar to writing checks which are later settled with the cardholder's bank account). Under regulations such as a regulation "E" promulgated by the Treasury Department, providers of services which are deemed to be "banking" services must comply with a litany of costly rules and restrictions. Accordingly, a major drawback of implementing a hybrid system as described above is that the system provider may be considered to be a bank, thus imposing onerous requirements and significantly driving up cost. For example, the system provider may need to provide deposit insurance to cover losses from cardholder accounts.
In addition to the above problems, conventional stored value transaction systems do not provide an efficient method of collecting off-line transaction information from a variety of different types of spend value devices for settlement with different merchants. For example, a first merchant may provide a variety of vending machines which accept stored value cards; a second merchant may provide a group of photocopiers which accept stored value cards; and a third merchant may provide retail point-of-sale (RPOS) terminals which accept stored value cards in addition to credit and debit cards. In order to collect off-line transactions from each of the different merchants, a common collection scheme is needed to facilitate settlement with the vendors' accounts.
Unfortunately, large investments must be made to modify the machines according to a common scheme, or else new machines adapted to a common scheme must be used. Additionally, security mechanisms must be provided to ensure that crooked merchants cannot fraudulently obtain credits for goods or services which were never provided. Consequently, there is a high cost associated with providing merchants with the ability to accept stored value cards in their devices. SUMMARY OF THE INVENTION
The present invention solves the aforementioned problems by providing a stored value system in which revalue transactions are performed in an on-line manner, but in which spend value transactions are performed off-line. Records of the off-line transactions are later collected, consolidated, and settled against individual accounts in a manner which prevents any individual account from being traced to a paπicular cardholder, thus assuring cardholder anonymity and avoiding onerous banking regulations. Such a "closed loop" approach overcomes problems associated with entirely off-line systems without compromising cardholder privacy.
The system of the present invention may include so-called "intelligent card readers" as described and disclosed in copending parent application serial number 08/414,495, filed on March 31 , 1995, entitled "Intelligent Card Reader Having Emulation Features", which is incorporated by reference herein. The u->e of such intelligent card readers allows the card-based devices herein to accept a variety of different types of smaπ cards. Details of various types of vending machine card readers, public and private kiosk card readers, multimachine controllers and the like are described in more detail in the aforementioned copending application and are not repeated here. In various embodiments of the invention, a stored value account number is created as a function of a unique smaπ card identifier, and a corresponding account having a balance is established in a stored value server. Each account is thus associated with a specific smaπ card, but the account is not directly traceable to any paπicular cardholder. A single cash pool is maintained at a financial institution which corresponds to the sum of all the balances of the anonymous account numbers.
When a cardholder installs value on a card at a revalue device, an on-line transaction occurs between the revalue device, a stored value server and, in certain cases, the cardholder's personal bank account. Cash inseπed into the revalue device or transferred from the cardholder's bank account is installed on the stored value card and a corresponding balance is established in the stored value server under the anonymous stored value account number.
As the cardholder spends value on the card in various types of devices (such as vending machines) using off-line transactions, records of the transactions are transmitted back to the stored value server for settlement with the stored value account. Batches of such transactions are soπed by merchant, and corresponding funds transfers are initiated from the cash pool account to each merchant's account. Additionally, the off-line transactions are posted to the cardholder's stored value account. If a merchant transmits "spend value" transactions for a paπicular stored value account in an amount which exceeds the available balance in the central computer, such fraudulent transactions can be easily detected. Additional security provisions to prevent theft and fraud are explained in more detail herein. Off-line transactions may be collected from vending machines and the like through one or more transaction collection devices which batch together multiple transactions for later transmission to a transaction concentrator, which in turn provides the transactions to the stored value server. By using a double buffering scheme to clear out old transactions only when verification of a previous transfer has occurred, the possibility of losing a batch of transactions is significantly reduced.
The system may be employed on a college campus or at a company-wide location with devices coupled through a local area network or wide area network as suited to the particular geography. Various other objects and advantages of the present invention will become apparent through the following detailed description, figures, and the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS
FIG. IA shows in simplified form various principles of the invention relating to the transfer of funds from individual cardholder bank accounts to merchant bank accounts.
FIG. IB shows in simplified form steps which may be performed to carry out various principles of the invention.
FIG. 2 depicts in more detail one possible implementation of a stored value system corresponding to element 100 of FIG. IA. FIG. 3 shows relevant poπions of one possible file stnicture for storing data on each stored value card.
FIG. 4 shows various steps of a method which may be carried out to add value to a card. FIG. 5 shows various steps of a method which may be carried out to spend value on a card which has been previously valued.
FIG. 6 shows various steps of a method which may be carried out to download and settle off-line transactions.
FIG. 7 shows one possible arrangement for implementing computer processes on a stored value server to carry out the principles of the invention.
FIG. 8 illustrates one possible approach for creating a stored value account number (SVAN).
FIG. 9 shows one possible configuration for a revalue device such as a public kiosk. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
1. SYSTEM OVERVIEW AND GENERAL PRINCIPLES
FIG. IA shows in simplified form a system employing various principles of the invention. A stored value system 100 (shown in more detail in FIG. 2) is coupled to a cash pool account 101 at Bank A, which may comprise a commercial checking account owned by the stored value system provider. The stored value system 100 is also coupled to one or more financial networks 102 through which various financial transactions such as debit or credit transactions may be initiated. Transactions in such a network may be effected by using financial service providers such as Gensar (one regional financial service provider) who provide such services.
Each cardholder may optionally maintain a regular bank account 103 which is coupled to one of the financial networks 102 in order to transfer funds from the cardholder's account to the cash pool 101. It is not necessary for a cardholder to maintain such a bank account if the cardholder always uses "hard" currency to revalue a stored value card.
Cash pool account 101 may also be coupled to an Automated Clearing House (ACH) network 105 to facilitate transfers of funds from the cash pool account 101 to merchant accounts 104 maintained at other banks. In general, stored value system 100 generates requests to transfer funds from cardholder accounts 103 to cash pool account 101 as pan of a revalue transaction. Off-line spend value transactions using cardholders' stored value cards are batched and soπed according to specific merchants, and corresponding fund transfers are initiated from stored value system 100 to effect fund transfers from cash pool 101 to individual merchant accounts 104 maintained at other banks. The bank at which cash pool account 101 is maintained may also transmit account activity and balance reports back to stored value system 100. Stored value system 100 includes a stored value server 201 (shown in FIG. 2) which authorizes on-line revalue operations and settles off-line spend value transactions. Variations on the basic architecture shown in FIG. IA are of course possible; a primary objective is the ability to transfer funds from a common cash pool account to various merchant accounts according to posted transactions, and optionally to transfer funds from a cardholder's bank account to the common cash pool account under the control of stored value system 100. FIG. IB shows in simplified form various steps which may be carried out in accordance with the system shown in FIG. IA. Beginning in step 120, an anonymous stored value account number is created, preferably using a cryptographic function based on a unique card identifier such as a serial number (details of these steps are described in more detail herein). The term "stored value account number", referring to this anonymous identifier, is hereinafter abbreviated SVAN.
In step 121 , the SVAN is written to a stored value card, and an account having a zero or a predetermined balance is created in a database in stored value server 201. The step of creating many different SVANs may be carried out at a card production facility long before the cards themselves are to be used: the SVANs may be transferred to the stored value server in bulk via floppy disk or the like. The end result of performing steps 120 and 121 is that SVANs are installed on stored value cards and corresponding accounts are created in stored value server 201 with zero or predetermined balances. The total value of all balances in the stored value accounts maintained in stored value server 201 should equal the account balance in cash pool 101.
Of primary importance in the system is the non-association (in stored value server 201 or in cash pool 101) of the SVAN with any information which could identify the cardholder. In other words, the stored value server does not maintain a record of the cardholder's identity (such as name, address, social security number, or the like) in coimection with the SVAN; the expendimre of funds in each stored value account is uniquely associated with the SVAN and not any paπicular cardholder. Thus, for example, if the cardholder loses his stored value card, a person who finds the card could spend the value on the card. In this respect, the stored value card is nearly as vulnerable as carrying cash. The latter problem can be mitigated somewhat by requiring the entry of a PIN prior to performing certain high- value spend value transactions.
After step 121, one of steps 122, 123, or 124 is performed at a revalue device in system 100. In step 122, a cardholder inserts a stored value card into a revalue device and inserts hard currency into a bill acceptor. Alternatively, in step 123 the cardholder may perform a debit transaction using his bank debit card to transfer funds from his bank account. Rather than using a separate debit card, the cardholder's regular bank account number may be pre-stored on a magnetic stripe on the back of the stored value smart card itself. This allows a single card to be used to transfer funds from a bank account to the stored value account.
Instead of steps 122 or 123, a credit transaction may be performed in step 124 in which the customer's credit card account is used to transfer funds on margin. As with step 123, rather than requiring a separate credit card, the cardholder's credit card information may be stored on a magnetic stripe on the stored value card itself, or it may be programmed in the stored value card.
Regardless of how funds are obtained (i.e. , by inseπing cash into a revalue device, performing a debit transaction, or performing a credit transaction), an on-line transaction occurs in step 125 to credit the SVAN account in the stored value server corresponding to the stored value card which was inseπed. In other words, even if the cardholder inserts hard currency into a stored value machine, no value will be added to the stored value card until after an on-line communication between the revalue device and the stored value server takes place. During this communication, the SVAN is verified and then credited
(at the stored value server) with the amount of funds provided by the cardholder. In step 126, the credited value is also written to the stored value card using an electronic purse function which is well known in the an. After value has been added to the card and a corresponding credit added to the SVAN at the server computer, the card is ejected and the cardholder is free to spend the value on the card.
In step 127, the cardholder may spend value on the card in any of a variety of spend value devices using off-line transactions as described in more detail herein. For example, the cardholder may use me card in vending machines, photocopiers, or RPOS terminals equipped to handle the cards. These transactions result in the value stored on the card being decremented, but no on¬ line communication with the stored value server takes place. It is, however, within the scope of this invention to also allow on-line spend value transactions, such that the system can suppoπ a mixture of off-line and on-line transactions. For on-line spend value transactions, steps relating to the collection of off-line transactions can be omitted. For example, there would be no need to store in a vending machine a record of an on-line transaction. In step 128, each spend value device accumulates off-line spend transactions over a period of time, such as a day or a week. The accumulated transactions are transferred to the stored value server using devices such as those shown in FIG. 2, or using store-and-forward techniques. Finally, in step 129, settlement occurs both with the stored value accounts in the server and with merchant's accounts which may be at the same or other banks. This settlement step includes decrementing value of the SVANs in the stored value server by the amount of spend value transactions which have been accumulated in various devices, and also soπing out credits to be applied to the various merchants whose spend value devices were used. For example, the value of all transactions conducted at a paπicular merchant's vending machines is accumulated and then credited to the merchant's bank account (see FIG. IA).
FIG. 2 shows in more detail one possible embodiment for the stored value system 100 depicted in FIG. IA. Card production facility 200 initializes a plurality of stored value cards and creates a unique SVAN for each card. One possible method of generating a SVAN is to use a cryptographic function based on the serial number of each card. For example, a triple DES (Data Encryption Standard) operation may be performed using a privacy key to generate a unique anonymous SVAN for each card based on the card's serial number. The SVAN is written to the card and also to a medium such as disk Dl , preferably in batches. Issued cards thus have an SVAN installed on them, and the SVANs are transmitted to stored value server 201 as shown in FIG. 2.
Stored value server 201 receives the SVANs and stores them in a database 201a, such as a relational database. Each SVAN has an associated balance as illustrated in 201a. Balances may be initially set to zero and then increased when revaluing a corresponding card; alternatively, each card may be provided with an initial balance. Stored value server 201 thus maintains a record of balances for each SVAN in an anonymous manner. Stored value server 201 may be coupled to a cash pool and to financial networks as illustrated in FIG. IA. Additionally, stored value server 201 is preferably connected to a network 213 which may comprise a LAN or WAN. A transaction concentrator 202, also coupled to network 213, collects off-line transactions from various spend value devices and transmits the transactions to stored value server 201, preferably over network 213. Transaction concentrator 202 may collect off-line spend value transactions from media such as disk D2, or through direct connection from various spend value devices 203. Spend value device 203, which represents any of a variety of devices such as vending machines and the like, includes a card reader which accepts stored value cards previously initialized by card production facility 200.
The various types of spend value devices will now be described. Vending machines 210 and 211 include a vending control reader which may be of a type described in copending parent application serial number 08/414,495, incoφorated by reference herein. Such readers can accept smaπ cards of various types and operate vending machines such as those conforming to the MC 5000, MC 5800, or multidrop standards, the particular control lines being selected to suit the specific vending machine type. In various embodiments, these readers comprise a microcontroller which executes a "spend value" process which is described in more detail herein.
Altematively, the vending control readers may be any type of smaπ card reader which controls the vending machine in response to insertion of a stored value card and maintains a log of all transactions. Generally speaking, each vending control reader verifies that an inseπed card is authentic, dispenses a product or service in response to a cardholder's selection, and decrements the value on the stored value card by a corresponding amount. Additionally, a transaction record containing the SVAN is created in the machine for later off¬ line settlement. Each vending machine may also include a Secure Application Module (SAM) which performs card authentication and other security features associated with an inseπed card. Additionally, each SAM contains a unique number which is stored in each transaction record and which allows the transaction to be later associated with a paπicular merchant. For example, a merchant who owns a group of 5 vending machines can be provided with 5 SAMs to install in the machines. Each of the SAMs may contain a unique identifier which, when stored into a transaction record, allows the transaction to be traced back to the merchant when the transaction is settled in stored value server 201. Photocopier 209 also includes a vending control reader which operates the photocopier in response to the insertion of a stored value card. Other types of spend value devices, such as washing machines and the like, are of course possible.
A Retail Point of Sale (RPOS) terminal 208 is provided with a card reader and (optionally) a SAM, and operates in a manner similar to the vending machines. The terminal may include a cash register type of device which calculates a total amount to be purchased and a card reader which accepts a cardholder's stored value card. In response to inseπion of the card, RPOS terminal 208 causes the value on the card to be decremented by the amount of the purchase and creates a transaction log record for later off-line settlement.
Public kiosk 206 may comprise a terminal located in a public location which includes a card reader and (optionally) a SAM. This public kiosk may provide services such as the sale of infoπnation or the installation of various applications such as a meal plan on the card. Additionally, a cardholder may order goods and services such as a pizza or the like using his stored value card at d e kiosk. The kiosk generally allows the cardholder to select various goods or services, and generates a receipt.
Private kiosk 207 may comprise a home computer which is equipped to accept stored value cards, and may provide a limited set of services which differs from those offered at public kiosk 206.
Transaction collection device 212 may be coupled to all of the above described spend value devices through one or more links 214 such as RS-232, RS-485, a LAN, or the like. Generally speaking, transactions which are stored in each spend value device may be transmitted over link 214 to transaction collection device at predetermined intervals, such as daily. Transactions which have been downloaded into collection device 212 may be offloaded to a disk D2 and subsequently transfeπed to transaction concentrator 202. In this manner, efficient collection of transaction information may be achieved. Note that instead of transmitting transaction information across link 214, each spend value device may be provided with a disk unit to individually offload stored transactions. Other variations are of course possible. For example, spend value devices may be directly connected to network 213, or to one or more transaction concentrators 202 such as illustrated in FIG. 2. Cash to card device 204 includes a bill acceptor 204a which allows a cardholder to add value to a stored value card by inseπing hard currency. However, in accordance with various principles of the invention, when cash is used to add value to a card, an on-line transaction with stored value server 201 occurs to ensure that the SVAN on the card is valid, and to store a corresponding balance amount in database 201a in the stored value server. Cash-to-card device
204 also preferably includes a door open detector 204b which transmits a message to stored value server 201 when the device is opened. This message may be time stamped and used to coordinate door openings with maintenance operations in order to prevent fraud. For example, revalue operations which occur while the door is open, or after the door has been opened during a non- maintenance period, can be identified as suspicious and an appropriate aleπ can be generated to prevent further on-line card valuations from that device.
Public kiosk 205 may be physically the same type of unit as public kiosk 206, but configured to include the ability to revalue a stored value card. For example, it may include the ability to read a magnetic stripe from a debit card or credit card in order to add value to a stored value card. Alternatively, it may include a hybrid card reader which uses a magnetic stripe on the stored value card itself to extract bank account information in order to perform a revalue operation.
In various embodiments, the devices coupled to network 213 may use a DCE/Encina client-server protocol to perform transactions over the network.
It will be recognized that while the system shown in FIG. 2 may preferably be employed at a single company-wide or campus-wide location, two or more systems such as that shown in FIG. 2 may be connected to handle transactions across multiple locations. For example, network 213 may be connected to another network (not shown) of another such system through a gateway, such that transactions can be processed across systems. This would allow, for example, a student who purchases a stored value account card for use at one campus to use the card at a second campus at a second geographic location and still provide for settlement of transactions.
2. CARD INITIALIZATION AND DATA FILES
This section describes generally how cards may be initialized in the system, and various data structures which may be used to hold information on the cards.
As noted above, one type of card which may be used to implement stored value features in accordance with the invention is the MPCOS card produced by
Gemplus. The MPCOS card uses encryption keys and secret codes for security puφoses. These security features may be used to provide message and data security for storage and transfer. Other types of cards may of course be used.
The stored value card preferably provides an intrinsic stored value function (electronic purse) which is protected using encryption/decryption techniques based on keys which may be derived from a unique issuer serial number or from the SVAN. Payment security functions preferably include secure messaging and cryptographic ceπificate verification based on cryptographic payment keys. Electronic purse transactions are preferably protected by payment keys stored on each card which are unique to the card. A ceπificate verification derivation key is preferably known to all SAMs. In various embodiments, cryptographic keys are not directly stored in revalue or spend value devices, but instead are protected within each SAM associated with the devices. All purse transactions that result in a change to the purse balance preferably use a cryptographic key for secure messaging.
The stored value account number (SVAN) generated and stored on each card may be generated using a cryptographically derived number which is unique on every card. In various embodiments, this number may be generated by performing a "triple DES" function on the card's serial number using a protected privacy key. The resulting number (SVAN) is then stored onto the card and also transmitted to the stored value server, preferably in batches on media such as a floppy disk.
In accordance with the principles of the present invention, a cardholder's identity is not maintained in connection to a SVAN; however, it may be generally desirable to maintain a cardholder's identity in connection with an issuer serial number associated with a particular card. Because the SVAN may be generated from the issuer serial number using an encipbeπnent process, the SVAN can, in various embodiments, be linked to the last four bytes of the issuer serial number when using a cryptographic key for SVAN calculation. In case of fraud or illegal activity, this association could be used to help trace a card back to a paπicular card serial number (e.g., if supplied with the key used to generate the original SVAN, a reverse operation could be performed to restore the last 4 bytes of the issuer serial number, which could help trace the number to a paπicular card). However, as explained herein, there is no direct correlation between a cardholder's identity and the SVAN used to revalue and devalue credits stored on his card. A data strucmre is preferably defined on the card to maintain the 10 most recent financial transactions. For security reasons, it may be desirable to require that the cardholder enter a PIN before certain information on the card is allowed to be read by a device (for example, the transaction log). This provides some measure of protection for lost or stolen cards.
FIG. 3 shows relevant poπions of a file strucmre 301 for storing information relating to the stored value application on the cards. The file strucmre includes, in relevant pan, a group of stored value files 302 and one or more bank files 303. It will be recognized that this strucmre is exemplary only and various different strucmres are of course possible. The following describes in more detail data which may be stored in these files.
KCT (304): a control key file which contains a stored value control key used to create files, download cryptographic keys, passwords, and the like.
KAD (305): authentication, certification, and debit key file which contains an authentication key, a certification key used for off-line debit, and an on-line debit key.
KCR (306): stores a key used for enabling a purse credit function and for computing a credit cryptogram.
PUR (307): a purse file, which may be supplied by the smart card vendor, used to store the card's monetary value. The purse file can be loaded either from a cash-to-card process or from an on-line debit from a cardholder's financial institution such as a bank identified in bank files 315. Various smaπ card vendors, such as Gemplus, may allow only indirect access to purse files on the card. TXL (308): a transaction log file used to store the 10 most recent transactions of the card's stored value file. Each transaction entry may include for example the following information:
1. amount of the transaction
2. type of transaction 3. terminal/vendor ID
4. date
5. time
6. transaction ceπificate (includes SVAN) DFC (309): cardholder data file which is used to store the stored value account number (SVAN).
Bank Files (303): contains cardholder banking information such as checking account number, credit card numbers, etc. (This information may also be stored on a magnetic stripe on the smaπ card itself). Although not shown explicitly in FIG. 3, each card may also contain a transaction counter which is incremented for each transaction.
Stored value cards may be initialized at a first level by the card manufacmrer, such as Gemplus. For example, the card manufacmrer can initialize the card so that secure messaging is required to create files, and to write and update the files created. Additionally, the manufacturer can install a card serial number and issuer reference number.
Stored value cards may be initialized at a second level by the card issuer, such as the entity that installs and operates the stored value system. This second- level initialization can be protected through the use of secure procedures which require that a card be authenticated before certain information is installed on the card. During second-level initialization, personalized information can be installed, as well as the creation of other files such as those shown in FIG. 3 preferably using secure techniques to prevent fraudulent card creation. Provisions may also be made for de-activating a previously initialized card. 3. ADDING VALUE TO A CARD
As shown by steps 122 to 124 in FIG. IB, value may be generally added to a stored value card in one of three ways: (1) inseπing cash into a cash-to-card machine: (2) performing a debit transaction between the cardholder's personal bank account and the cash pool maintained by the stored value provider, or (3) performing a credit transaction between the cardholder's credit account at his bank and die cash pool maintained by the stored value provider. This section describes in more detail how value may be added to a card using the SVAN in a manner which prevents the cardholder's account from being associated with individual purchases traceable to the cardholder.
Regardless of whether cash, an on-line debit transaction, or an on-line credit transaction is used, certain principles are generally followed to ensure that value is not fraudulently installed on a card. These principles can take two different forms, depending on whedier or not the device being used to revalue die card includes a Secure Application Module (SAM).
Although both the cash-to-card device 204 and die public kiosk 205 shown in FIG. 2 preferably include such a SAM for providing security features, it will be appreciated d at cards can be revalued without the use of such a SAM. Accordingly, two different methods are described herein; the first method assumes that the revalue device includes a SAM, while the second method assumes that the revalue device does not include such a SAM. Each SAM may be implemented either in hardware or in software, and generally provides certain cryptographic services to support the device into which it is installed. A detailed description of each revalue process (with SAM and widiout SAM) appears separately below.
FIG. 7 shows one possible context in which card revaluation may be performed. Generally speaking, FIG. 7 shows various databases and computer processes which may reside on stored value server 201 (see FIG. 2). A revalue control process 701, financial network access process 702, and SVAN account database 703 (identical to database 201a of FIG. 2) may be implemented to carry out the process described in more detail below. In summary, stored value account numbers may be received from a disk into a maintenance process 713, which creates entries in SVAN account database 703. Messages from revalue devices can be processed by revalue control process 701, which, in cooperation with financial network access process 702, performs the necessary bank transfers to transfer funds from a cardholder's pπvate bank account to the cash pool account 101 (see FIG. 1) and diereafter credits the conesponding SVAN in database 703. Further details of FIG. 7 are explained below with respect to spending value from me cards and transaction settlement.
A. Revalue Method Using a Secure Application Module (SAM) FIG. 4 shows vaπous steps which can be performed at a revalue device (such as cash-to-card device 204 or public kiosk 205) to add value to a stored value card in d e case where the revalue device includes -a SAM. Beginning in step 401, the stored value card is activated. For card readers which can suppoπ different types of smaπ cards (see parent application senal no. 08/414,495, incorporated by reference herem), this step could mclude the step of determinmg what type of card was inserted, and initializing software pointers m the card reader to support the specific type of card inserted. Step 401 includes steps of checking the answer-to-reset data supplied by die card, selecting the stored value file (DFC in FIG. 3) and reading die SVAN from this file, and requesting that the SAM derive the conect key from the issuer serial number or SVAN for the particular card. Usmg die SAM, the revalue device can authenticate the smart card and communicate encrypted data with die smart card.
In order to increase the level of secunty, it is preferable to use different keys for authenticating a stored value card, performing an on-line revalue operation, performing an off-line spend value operation, and calculating vanous ceπificates. Additional keys may be used to encrypt data transmitted between various types of devices and die stored value server. Rather than explicidy identifymg keys, implicit key identifiers (e.g., a file name identifymg where a key may be found) may instead be used to prevent die misuse of cryptographic keys and to save storage space in off-line transaction logs, while explicit key identification may be used for on-line transactions. Continuing with FIG. 4, in step 402 the stored value card is audienticated through the use of the SAM. This step generally includes requesting a random number from die SAM, sending die random number to d e card, having the card encipher the random number and requesting that the SAM also encipher the random number, men requesting that the SAM compare the enciphered number returned from die card with d at enciphered in the SAM. If the results match (i.e. , the comparison is favorable), the card is deemed to have been audienticated. Such authentication techniques are well known.
Next, in step 403, the cardholder specifies a revalue amount dirough the use of a suitable input device such as a keyboard or touch-panel display, and, if die cardholder is using die cardholder's own bank account to transfer funds, d e cardholder enters his PIN to be used with his normal bank account (this is not to be confused widi a PIN or password which can be stored on die card itself). If the cardholder is using a credit card or cash to transfer funds, no PIN need be provided, aldiough it is within the scope of the invention to also require a PIN for credit transactions. If either the cardholder's debit account or credit card account are used, die appropriate bank information can be read from me appropriate bank file (see FIG. 3) or from a magnetic stripe on the smaπ card itself. If the cardholder inserts hard currency into the machine, the machine itself can determine die revalue amount.
Step 404 includes steps of reading die purse value from e card, verifying that die amount requested plus die current purse value on die card does not exceed a maximum balance for the card, and aborting the transaction if the maximum purse value would be exceeded. Additionally, a card transaction counter and card balance certificate is obtained from the card in order to ensure non-repudiation (i.e., it allows die system to prove that the transaction came from that particular card and prevents unauthorized changes to the card balance amount; me card transaction counter also ensures that transactions such as loading value on a card cannot be replayed). In various embodiments, me card balance ceπificate may be provided as a function by the smart card vendor (e.g. , Gemplus).
In step 405, a request message to validate die funds transfer operation is created, audienticated, encrypted, and transmitted on-line to me stored value server (element 201 in FIG. 2). This generally includes steps of encrypting d e
SVAN, card balance certificate, and PIN (if required), and transmitting the encrypted message to the stored value server over a network with a message authentication code (MAC) provided by the SAM. The network may include DCE/Encina client/ server protocols to perform these transactions. The stored value server decrypts die request, verifies the MAC, verifies the balance certificate, and verifies that the SVAN from the card exists in database 201a and diat the accumulated balance is not less dian zero (if so, an unaudiorized revalue might have taken place and appropriate reporting may be initiated).
If me funds transfer was an on-line debit or on-line credit transaction, the stored value server initiates a funds transfer request through a financial network
102 or ACH as illustrated in FIG. IA. If die funds transfer was a hard currency operation at the revalue device, diere is no need to perform such a transaction. After receiving a verification that the funds transfer has occurred (i.e. , a successful debit operation or credit transaction from the cardholder's bank account), die stored value server prepares a credit certificate for the card, and authenticates and encrypts die response message to the revalue device. Note that stored value server 201 may include a SAM to perform the security-related features.
Step 407 includes steps of decrypting d e response message in the revalue device, extracting and verifying the MAC, transmitting a credit ceπificate to d e stored value card, verifying in die stored value card d at die credit ceπificate is valid, and, if valid, updating die current balance (i.e., updating die purse file), and obtaining a transaction ceπificate in d e card. The generation and verification of credit ceπificates is well known in the an (the MPCOS card provides proprietary functions for performing these operations which differ in some respects from conesponding ISO standards), and a detailed explanation of d at poπion of the operation is omitted.
In step 408, a record is written to the transaction log on die card (including die transaction ceπificate), and die card is ejected from die revalue device.
Finally, in step 409, a completion message is generated in d e revalue device and encrypted for transmission back to the stored value server. This step includes steps of calculating a MAC, inseπing a ceπificate obtained-from the card which confirms that the card has been revalued, authenticating the message, encrypting the message, and transmitting the encrypted message to d e stored value server over a network.
B. Revalue Method Without a Secure Application Module (SAM)
A revalue device (such as cash-to-card device 204 or public kiosk 205) can also be used to add value to a stored value card in the case where the revalue device does not include a SAM. Instead of using a SAM, keys maintained in d e stored value server and on die card may be used to encrypt data between the two, with the revalue device merely "passing dirough" the encrypted data.
4. SPENDING VALUE ON A CARD FIG. 5 illustrates steps which may be performed to spend value on a previously valued card. In various embodiments, it is assumed diat a SAM is provided in each spend value device to assist in certain security functions, and d e explanation below assumes that such a SAM is provided. However, d e use of a SAM may not be required, and die steps below can be performed as explained above to omit a SAM.
Beginning in step 501 , a stored value card inseπed into a spend value device is activated in a manner similar to step 401 of FIG. 4.
In step 502, the inseπed card is authenticated to ensure d at die card can be initially trusted. This step is similar to step 402 of FIG. 4. Additionally, the available balance on the card may be displayed on die spend value device.
In step 503, the purchase amount is determined. For a vending machine or menu type display at a kiosk, die cardholder may make a selection which generates a signal indicating the amount of me selected item. For an RPOS terminal, a cash register may generate a total indicating the accumulated value of a purchase. For a photocopier, a signal may be generated indicating a standard cost (e.g., 10 cents) for each dispensed copy. Other variations are of course possible.
In step 504, ihe purchase amount is compared wi the available balance on the card. Optionally, if the purchase amount exceeds a predetermined d reshold, the cardholder may be required to enter a password (PIN) which is compared to the pre-stored PIN on the stored value card. If die purchase amount exceeds me available balance, the transaction is aboπed and die card returned to the cardholder. In step 505, die purse on the card is debited. This may include steps of decrementing the purse by the purchase amount, obtaining a debit ceπificate from the card (diis can be done using intrinsic MPCOS card functions, supplied by Gemplus), verifying the debit certificate in die spend value device (such as using a Gemplus-supplied method), and aborting the transaction if it is not legitimate. In step 506, a card transaction record is created containing fields such as d ose described widi reference to FIG. 3 and stored into the transaction log on the card (TXL file). This log may be viewed by the cardholder when die card is inserted into a machine.
In step 507, a transaction record is created and stored in a transaction log in the spend value device itself. This may include steps of calculating a message authentication code (MAC), encrypting the transaction data, and storing the encrypted record in the spend value device. The transaction record stored in the spend value device may, in various embodiments, include more information than that stored on the card itself. For example, the following information may be included in d e device's transaction log:
1. serial number of the SAM used in the transaction (used to trace merchant)
2. stored value account number (SVAN) 3. card transaction ceπificate for d e transaction
4. card transaction counter (a one-up counter)
5. terminal identifier
6. actual debit amount
7. terminal transaction counter (a one-up counter) 8. time stamp
9. MAC for the transaction record
In various embodiments, storing die SAM serial number of the spend value device allows a transaction to be credited to die merchant who owns or operates the device. Preferably, the stored value system provider provides SAMs to merchants to control the generation of encrypted transaction records in order to prevent unscrupulous merchants from fraudulently generating spend value transactions. However, other types of identifiers such as a merchant code or machine identifier may be used.
Storage of transaction records may be done using a "double buffering" memod in each spend value device. In this regard, each spend value device maintains a "current transactions" buffer 210b (see FIG. 2) which records transactions which have occurred since the last download operation from the device was performed, and a "previous transactions" buffer 210a (see FIG. 2) which retains the previous batch of transactions which were downloaded. After d e "current transactions" buffer is downloaded from the spend value device and successfully stored in the stored value server, a verification is preferably generated for the spend value device which indicates that d e previous transactions were actually received and stored in the stored value server and that the conesponding "previous transactions" buffer can be deleted. This principle - 26 - is explained in more detail in the next section.
In step 508, the product or service selected by die cardholder is dispensed or odierwise provided to the cardholder. It will be recognized that diis step need not be performed at diis paπicular stage in the process; it could occur before step 507 or earlier, for example.
5. TRANSACTION COLLECTION AND SETTLEMENT
Reference will now be made to FIG. 6, which shows various steps which may be carried out to collect and settle transactions. Reference will also be made to FIG. 2, which shows a system containing devices for implementing these steps, and FIG. 7, which illustrates various computer processes which may be implemented for carrying out these steps.
Referring first to FIG. 2, each spend value device (elements 207 through 211) may be coupled via a communication link to a transaction collection device 212 such as a PC -compatible computer. Periodically, die spend value devices may download a current buffer of transactions to the transaction collection device. This may be done on an hourly, daily, weekly basis or the like, or upon demand. Transaction collection device 212 may collect multiple batches from different devices and store the combined batches on a medium such as disk D2. Thereafter, the medium may be inserted into a transaction concentrator 202 which can accept disks from many different transaction collection devices and fuπher download d e transactions into stored value server 201 over a network 213.
Alternatively, spend value devices such as device 203 may direcdy download transactions into transaction concentrator 202 as shown in FIG. 2. Yet anodier variation is for transaction collection device 212 to be connected directly to network 213 to download batches of transactions into stored value server 201. Regardless of d e paπicular arrangement used, d e net result is diat batches of transactions previously logged off line in die spend value devices are loaded into stored value server 201 for settlement. Referring now to FIG. 6, step 601 indicates that batches of transaction logs from the spend value devices are transfened to a collection device such as 212 or 202 as explained above. In step 602, each spend value device which has downloaded its cunent transaction log switches over its transaction log buffer to a second "cunent" buffer, and designates the downloaded buffer as "previous transactions" . In other words, each spend value device preferably maintains a copy of the old transactions in the event that diey are not successfully loaded into stored value server 201.
Next, in step 603, batches of transaction logs which have been received from transaction concentrator 202 (or transaction collector device 212) are transferred to die stored value server 201. Referring to FIG. 7, a transaction batch receiver process 704 in stored value server 201 receives batches of transactions, decrypts each transaction and verifies die MAC for each, and stores d em into a database 705. In step 604, each transaction extracted from database 705 is posted against die stored value account corresponding to die transaction. In other words, die SVAN for each transaction is extracted from the transaction record, and die balance of die conesponding account in SVAN account database 703 is decremented by die amount of die transaction. Other steps of verifying die authenticity of each transaction (e.g. , verifying the transaction certificate) are also included but not explicidy shown in FIG. 6.
In various embodiments, it may be preferably to include two types of transaction certificates: and off-line certificate, and an on-line certificate. An off¬ line certificate can be generated by die card during a card decrementing operation, and die certificate verified by a SAM in the spend value device. After verifying this off-line certificate, die spend value device can request diat the card generate an on-line ceπificate using a key which is not known to the SAM, but which is known to the computer server which wUl eventually settle the transaction in an on-line process. This prevents can help prevent fraudulent generation of transaction ceπificates by someone who steals a SAM.
In step 605, transactions which have been newly posted in die database are soπed by merchant in process 706, preferably based on d e SAM serial number extracted from each transaction record. The conelation between SAM serial number and merchant identifier can be stored in a merchant information database 712. The result of this step is that all newly posted transactions are soπed by merchant and accumulated in value (i.e., die value of all transactions attributable to a paπicular merchant are added togedier).
In step 606, each merchant can be paid using a merchant repayment process 709 which extracts merchant bank account information from database 712 and initiates a funds transfer using ACH process 708. This step may also include a human review of me payments before authorizing die bank funds transfer.
In step 607, reports may be optionally generated to send to die merchants showing a detailed breakdown of sales per device and die like. An accounting package 710 may be used to generate statistical analyses and die like as desired.
Finally, in step 608, a "buffer verified" indication is generated eidier by storing a flag on a disk D2 used for later collection, by transmitting a message over network 213, or the like, to indicate to each spend value device diat die
"previous transactions" buffer may be discarded. This indication may be conveniently combined wim die next round of transaction collections, such that the step of transaction collection begins with a verification that die previously downloaded transactions have been properly posted.
The above described procedure provides a convenient and reliable method of collecting and settling off-line transactions in a system. Other variations are of course possible.
When each transaction record is verified, a failure of verification may result in aborting the current batch of transactions and returning d em to die merchant for further action. It is apparent diat the information in the transaction records can be combined, sorted and analyzed for various puφoses such as detecting fraud and tracing suspicious activity to a paπicular machine or merchant.
6. GENERATINGSTOREDVALUEACCOUNTNUMBERS
In various embodiments, an anonymous stored value account number (SVAN) may comprise 12 bytes that uniquely identify a stored value card. It is apparent, however, that fewer or more than 12 bytes may be used. FIG. 8 illustrates one possible method for deriving a SVAN in die manner described below. The first two bytes may be set to zero, and the last eight bytes can be derived by enciphering thε issuer serial number using a double lengdi privacy key as follows:
SVAN (8) = ede*KEY(issuer serial number) where ede = encipher/decipher/encipher
KEY = a double length key issuer serial number = constructed and stored on die card. The issuer serial number may be constructed as follows: first 4 bytes = the last 4 bytes of the SAM serial number of a SAM used in die card production process fifth byte = not used (zero) last 3 bytes = a unique sequence number (one-up counter) generated by d e card preparation system SAM.
The SAM serial number may be an 8 byte number that uniquely identifies a SAM, and may be constructed as follows: first 4 bytes = same as the issuer reference last 4 bytes = a number sequentially assigned which uniquely identifies the SAM.
The issuer reference number may be used to identify die geographic location of the system, such as a campus identifier or a company location identifier. A card preparation SAM may be used to prepare cards, including deriving various types of keys. 7. REVALUE DEVICE DESIGN
One possible configuration for a revalue device such as public kiosk 205 is shown in FIG. 9. The revalue device 901 generally includes a processor 902 and memory 903 for storing control programs and information needed to execute various steps described elsewhere in mis specification. SAM 910 is coupled to processor 902 and generally provides security functions such as key storage and derivation, audientication, ceπification, and encryption/decryption functions. A hybrid card acceptor 906 accepts microprocessor-equipped smaπ cards which may also have a magnetic stripe. This allows certain bank information to be stored on die magnetic stripe in a manner compatible with existing debit cards, and diis information may be used to perform an on-line debit operation in e revalue device.
Control circuit 905 generally performs card reader-related functions, augmented slighdy to handle die magnetic stripe information from cards so equipped. An encrypted PIN pad 907 may be used to enter a PIN for cardholder verification. A receipt printer 908 generates receipts for products or services purchased by die cardholder. An input device 909 may comprise a keyboard or the like, or alteratively display 904 may comprise a touch-panel display which performs these functions. Processor 902 may be coupled to a nerwork such as network 213 shown in FIG. 2.
It is apparent that many modifications and variations of die present invention are possible, and references to specific values are by example only. The method steps of die invention may be practiced in a different ordered sequence from that illustrated widiout departing from the scope of the invention. It is, therefore, to be understood diat widiin the scope of the appended claims the invention may be practiced od erwise dian as specifically described.

Claims

1. A stored value transaction system for carrying out transactions using a plurality of smaπ cards, comprising: a computer comprising a database which maintains a balance for each of a plurality of stored value accounts, wherein each of die stored value accounts has an identifying number which is stored on one of die plurality of smaπ cards and which is not conelated in the computer to any paπicular cardholder; and a spend value device which conducts an off-line transaction with one of the plurality of smaπ cards by decrementing value stored on die one smaπ card and storing a record of die off-line transaction including the identifying number stored on die one smaπ card; wherein the computer decreases the balance of one of die stored value accounts conesponding to the identifying number of the one smaπ card in response to receiving at a later time a copy of the stored record of die off-line transaction.
2. The system of claim 1, wherein the record of the off-line transaction is stored in encrypted form in the revalue device.
3. The system of claim 2, wherein the computer receives a plurality of encrypted off-line transaction records and separately decrypts each record prior to decreasing the balance of a corresponding stored value account.
4. The system of claim 1, further comprising: a revalue device which adds value to die one smart card by performing an on-line transaction with the computer, wherein die computer verifies the audienticity of the identifying number stored on die one smart card by checking the database prior to authorizing the addition of value to the one smart card.
5. The system of claim 4, wherein the revalue device comprises a currency acceptor which accepts hard currency, wherein me on-line transaction is conducted in an amount equal to die amount of hard currency accepted in die cunency acceptor.
6. The system of claim 5, wherein the revalue device comprises a secure application module (SAM) which is used to audienticate the one smaπ card prior to adding value to die one smaπ card.
7. The system of claim 4, wherein the on-line transaction comprises an on-line debit operation using a cardholder-entered PIN.
8. The system of claim 7, wherein the on-line debit operation is performed between a cardholder's private bank account and a cash pool account maintained at a separate bank.
9. The system of claim 7, wherein the on-line debit operation is performed on the basis of data read from a magnetic stripe on the smaπ card.
10. The system of claim 4, wherein the on-line transaction comprises an on-line credit operation using cardholder-provided credit card infoπnation.
11. The system of claim 10, wherein die credit card information is read from a magnetic stripe on the smart card.
12. The system of claim 1, wherein the identifying number is derived by performing an encryption operation on another number.
13. The system of claim 12, wherein the encryption operation is performed on a number provided by a secure application module in a card preparation device.
14. The system of claim 1, further comprising a transaction collection device, coupled to die spend value device, for collecting batches of transactions stored in die spend value device and providing them to die computer.
15. The system of claim 14, wherein the spend value device maintains a cunent transaction storage area used to store ongoing transactions and a previous transaction storage area used to retain transactions which were previously collected by die transaction collection device but not yet stored in d e computer.
16. The system of claim 1, wherein the spend value device comprises a vending machine having a secure application module (SAM) used for encrypting transaction records.
17. The system of claim 16, wherein the vending machine accumulates a plurality of off-line transactions and downloads d e accumulated transactions to a transaction collection device.
18. The system of claim 1, wherein the spend value device comprises a retail point of sale (RPOS) terminal which accumulates a total sale amount as the value to be decremented on die one smaπ card.
19. The system of claim 1, wherein the spend value device comprises a photocopy machine.
20. The system of claim 1, wherein the spend value device comprises a kiosk having a display and means for selecting a product or service from the display.
21. The system of claim 1, wherein the spend value device further stores transaction information on the one smart card.
22. The system of claim 1, wherein the spend value device accepts a plurality of different types of smart cards.
23. A system comprising: a plurality of different types of spend value devices each of which decrements, using an off-line transaction, value from a smart card and retains an encrypted record of each off-line transaction, wherein each transaction includes an anonymous account number used for settling the transaction against an anonymous account maintained in a computer; and a transaction collection device, coupled to die plurality of different types of spend value devices, for collecting a plurality of encrypted transactions stored in die plurality of spend value devices and downloading die collected transactions to the computer in which the anonymous accounts are maintained.
24. The system of claim 23, wherein each of the plurality of spend value devices comprises a card reader which can read a plurality of different types of smart cards.
25. The system of claim 23, wherein each of the plurality of spend value devices maintains a cunent transaction storage area for storing ongoing transactions and a previous transaction storage area for storing transactions which were previously collected by the transaction collection device but not yet stored in die computer.
26. The system of claim 23, further comprising a transaction concentrator which accepts off-line transaction records collected by d e transaction collection device and downloads them to die computer.
27. A system for conducting transactions with smaπ cards, die system comprising: a computer comprising a database which maintains a balance for each of a plurality of stored value accounts, each of d e stored value accounts being identified by an anonymous account number which is not associated wid any particular cardholder; a plurality of smaπ cards each having one of the anonymous account numbers stored diereon; a plurality of spend value devices each of which decrements value from one of e smart cards using an off-line transaction and retains a record of each transaction including die anonymous account number of the smart card used in the transaction; and means for settling each of die retained transaction records widi die stored value accounts in d e database.
28. The system of claim 27, further comprising means for generating the plurality of anonymous account numbers using an encryption function.
29. The system of claim 27, further comprising a transaction collection device, coupled to die plurality of different types of spend value devices, for collecting a plurality of transactions stored in the plurality of spend value devices and downloading d e collected transactions to the computer in which the anonymous accounts are maintained.
30. The system of claim 29, wherein the transaction collection device uses a disk for collecting the plurality of transactions.
31. The system of claim 29, further comprising a transaction concentrator, coupled to the computer, for concentrating transactions from one or more transaction collection devices.
32. The system of claim 27, further comprising means for sorting and accumulating transactions by merchant and au iorizing a funds transfer to merchants for the accumulated amounts.
33. The system of claim 32, wherein each of the spend value devices comprises a secure application module having a unique number which is included in each of the off-line transactions, and wherein the sorting and accumulating means uses die unique number to sort transactions by merchant.
34. The system of claim 27, wherein the system controls transfers from a bank cash pool account having a value corresponding to the accumulated value of the stored value accounts.
35. The system of claim 27, wherein die system is coupled to a financial network and issues funds transfer requests to the financial network in order to increase the value of one of the stored value accounts.
36. The system of claim 27, further comprising a revalue device, coupled to die computer, which accepts one of the smart cards and increases value on the one smart card after communicating wim the computer, wherein the revalue device comprises a door open detector which transmits a message to the computer upon detecting diat a door on the revalue device has been opened.
37. A method for tracking expenditures in a system which uses smaπ cards, comprising d e steps of:
(1) inseπing a smaπ card into a revalue device in communication with a computer having a plurality of stored value accounts, wherein the smaπ card contains an anonymous account number which conesponds to one of the stored value accounts in die computer but which is not directly traceable to any particular cardholder; and
(2) adding value directly to die smart card only after communicating with die computer to verify that die stored value account number on me inseπed smaπ card corresponds to one of the anonymous account numbers stored in die computer.
38. The method of claim 37, wherein step (2) comprises me step of transferring, under the control of the computer, funds from a cardholder's private bank account to a cash pool account conesponding to the total value of all the stored value accounts in the computer.
39. The method of claim 37, further comprising the step of increasing a balance of one of the stored value accounts in the computer corresponding to the stored value account number contained on die smaπ card inseπed in step (1).
40. The method of claim 37, further comprising me steps of:
(3) inserting the smart card into an off-line spend value device which decrements value on die smart card widiout communicating with die computer and which stores a record of die value decrementing transaction; and
(4) downloading at a later time the record of d e transaction to the computer and settling die transaction with one of the stored value accounts.
41. The method of claim 40, further comprising the step of accumulating a plurality of value decrementing transactions in a U-ansaction collection device and downloading die accumulated plurality of transactions to the computer for settlement.
PCT/US1996/014414 1995-09-14 1996-09-12 Stored value transaction system and method using anonymous account numbers WO1997010560A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU69700/96A AU6970096A (en) 1995-09-14 1996-09-12 Stored value transaction system and method using anonymous account numbers

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US52830795A 1995-09-14 1995-09-14
US08/528,307 1995-09-14

Publications (1)

Publication Number Publication Date
WO1997010560A1 true WO1997010560A1 (en) 1997-03-20

Family

ID=24105128

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1996/014414 WO1997010560A1 (en) 1995-09-14 1996-09-12 Stored value transaction system and method using anonymous account numbers

Country Status (2)

Country Link
AU (1) AU6970096A (en)
WO (1) WO1997010560A1 (en)

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000000915A1 (en) * 1998-06-26 2000-01-06 American Express Travel Related Services Company, Inc. Stored value transaction system including an integrated database server
EP1000503A1 (en) * 1997-08-29 2000-05-17 Alexander Mashinsky Method and system for global communications network management and display of market-price information
WO2000028490A1 (en) * 1998-11-07 2000-05-18 Ncr International, Inc. Smart card and method of operating the smart card
WO2001043084A3 (en) * 1999-12-06 2002-02-14 Ted A Pielemeier Method of masking the identity of a purchaser during a credit transaction
WO2003063100A2 (en) * 2002-01-23 2003-07-31 Giesecke & Devrient Gmbh Terminal security module for the transfer of electronic value units
KR20030073182A (en) * 2002-03-08 2003-09-19 (주)씨큐텍 Prepayment card with a lottery ticket function and payment system and method for election commerce using the card
WO2003083792A2 (en) * 2002-03-28 2003-10-09 Burrows, Colin, Cyril Administration of transactions with pre-payment debit and credit cards
EP1374136A1 (en) * 2001-03-29 2004-01-02 Ebestcard Ltd Card transaction system and method on on-line and/or off-line
US6807530B1 (en) * 1998-08-05 2004-10-19 International Business Machines Corporation Method and apparatus for remote commerce with customer anonymity
US6889198B2 (en) * 1998-01-30 2005-05-03 Citicorp Development Center, Inc. Method and system for tracking smart card loyalty points
FR2872325A1 (en) * 2004-06-24 2005-12-30 Columbia Finances Sa Payment system for use in shop, has central processing units incrementing balance of credited amount corresponding to amount to be transferred and decrementing balance of deducted amount corresponding to credited amount
US7587434B2 (en) 2002-10-01 2009-09-08 Acs State & Local Solutions, Inc. Method and system for managing a distributed transaction process
US7774273B2 (en) 2002-07-30 2010-08-10 Acs State & Local Solutions, Inc. Systems and methods for processing benefits
EP2325770A1 (en) * 2000-12-29 2011-05-25 Intel Corporation Anonymized electronic transaction
US8024260B1 (en) * 1999-06-10 2011-09-20 Paypal Inc. Method for transmitting a code
US8204829B2 (en) * 2003-10-17 2012-06-19 Nexxo Financial Corporation Systems and methods for money sharing
US8296204B2 (en) 2000-07-10 2012-10-23 Paypal Inc. System and method for reducing RIKS associated with accepting a financial instrument
US8340979B2 (en) 2002-10-01 2012-12-25 Acs State & Local Solutions, Inc. Systems and methods for electronically processing government sponsored benefits
CN103473850A (en) * 2012-06-06 2013-12-25 中国银联股份有限公司 Offline loading method and system
US8690054B1 (en) 2013-05-29 2014-04-08 The Toronto-Dominion Bank System and method for chip-enabled card transaction processing and alert communication
US8793187B2 (en) 2003-10-17 2014-07-29 Nexxo Financial Corporation Self-service money remittance with an access card
US8856024B2 (en) 2010-10-26 2014-10-07 Cubic Corporation Determining companion and joint cards in transit
US8942677B2 (en) 2009-07-09 2015-01-27 Cubic Corporation Transit account management with mobile device messaging
US8991699B2 (en) 2009-09-08 2015-03-31 Cubic Corporation Association of contactless payment card primary account number
WO2017074244A1 (en) * 2015-10-30 2017-05-04 Id Loop Ab Method for payment with a cash card
US11055758B2 (en) 2014-09-30 2021-07-06 Ebay Inc. Garment size mapping
US11100564B2 (en) 2013-12-27 2021-08-24 Ebay Inc. Regional item recommendations
US11145118B2 (en) 2013-11-14 2021-10-12 Ebay Inc. Extraction of body dimensions from planar garment photographs of fitting garments

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4630201A (en) * 1984-02-14 1986-12-16 International Security Note & Computer Corporation On-line and off-line transaction security system using a code generated from a transaction parameter and a random number
US4804825A (en) * 1986-06-17 1989-02-14 Casio Computer Co., Ltd. I C card system
US5144115A (en) * 1990-01-29 1992-09-01 Hi Tachi, Ltd. Transaction inquiring method and apparatus

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4630201A (en) * 1984-02-14 1986-12-16 International Security Note & Computer Corporation On-line and off-line transaction security system using a code generated from a transaction parameter and a random number
US4804825A (en) * 1986-06-17 1989-02-14 Casio Computer Co., Ltd. I C card system
US5144115A (en) * 1990-01-29 1992-09-01 Hi Tachi, Ltd. Transaction inquiring method and apparatus

Cited By (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1000503A4 (en) * 1997-08-29 2002-12-04 Anip Inc Method and system for global communications network management and display of market-price information
EP1000503A1 (en) * 1997-08-29 2000-05-17 Alexander Mashinsky Method and system for global communications network management and display of market-price information
EP1633124A3 (en) * 1997-08-29 2006-03-22 Anip, Inc. Global communications network management
EP1633124A2 (en) * 1997-08-29 2006-03-08 Anip, Inc. Global communications network management
US6889198B2 (en) * 1998-01-30 2005-05-03 Citicorp Development Center, Inc. Method and system for tracking smart card loyalty points
GB2354359B (en) * 1998-06-26 2003-07-23 American Express Travel Relate Stored value transaction system including an integrated database server
GB2354359A (en) * 1998-06-26 2001-03-21 American Express Travel Relate Stored value transaction system including an integrated database server
US7840446B2 (en) 1998-06-26 2010-11-23 American Express Travel Related Services Company, Inc. Stored value transaction system including an integrated database server
US8635114B2 (en) 1998-06-26 2014-01-21 Lead Core Fund, L.L.C. Stored value transaction system and method including an integrated database server
WO2000000915A1 (en) * 1998-06-26 2000-01-06 American Express Travel Related Services Company, Inc. Stored value transaction system including an integrated database server
US7447648B2 (en) 1998-06-26 2008-11-04 American Express Travel Related Services Company, Inc. Stored value transaction system including an integrated database server
US7216091B1 (en) 1998-06-26 2007-05-08 American Express Travel Related Services Company, Inc. Stored value transaction system including an integrated database server
US6807530B1 (en) * 1998-08-05 2004-10-19 International Business Machines Corporation Method and apparatus for remote commerce with customer anonymity
US6760796B1 (en) 1998-11-07 2004-07-06 Ncr Corporation Smart card which temporarily stores transactions in non-secure memory and consolidates the transactions into secure memory
WO2000028490A1 (en) * 1998-11-07 2000-05-18 Ncr International, Inc. Smart card and method of operating the smart card
US20130006864A1 (en) * 1999-06-10 2013-01-03 Paypal Inc. Method for transmitting a code
US8301556B2 (en) 1999-06-10 2012-10-30 Paypal Inc. Method for transmitting a code
US8600878B2 (en) 1999-06-10 2013-12-03 Ebay Inc. Method for transmitting a code
US8024260B1 (en) * 1999-06-10 2011-09-20 Paypal Inc. Method for transmitting a code
WO2001043084A3 (en) * 1999-12-06 2002-02-14 Ted A Pielemeier Method of masking the identity of a purchaser during a credit transaction
US8370259B2 (en) 2000-07-10 2013-02-05 Ebay, Inc. Verifying the source of electronically exchanged value
US8417637B2 (en) 2000-07-10 2013-04-09 Paypal Inc. Approving the use of the source of funds
US8515871B2 (en) 2000-07-10 2013-08-20 Paypal Inc. Authorizing use of a financial instrument
US8296204B2 (en) 2000-07-10 2012-10-23 Paypal Inc. System and method for reducing RIKS associated with accepting a financial instrument
EP2325770A1 (en) * 2000-12-29 2011-05-25 Intel Corporation Anonymized electronic transaction
US10032211B2 (en) 2000-12-29 2018-07-24 Intel Corporation Anonymous electronic transactions
EP2293263A3 (en) * 2001-03-29 2012-01-04 Ebestcard Ltd On-line and/or off-line card transaction system and method
EP1374136A4 (en) * 2001-03-29 2007-11-28 Ebestcard Ltd Card transaction system and method on on-line and/or off-line
EP1374136A1 (en) * 2001-03-29 2004-01-02 Ebestcard Ltd Card transaction system and method on on-line and/or off-line
WO2003063100A3 (en) * 2002-01-23 2004-11-04 Giesecke & Devrient Gmbh Terminal security module for the transfer of electronic value units
WO2003063100A2 (en) * 2002-01-23 2003-07-31 Giesecke & Devrient Gmbh Terminal security module for the transfer of electronic value units
KR20030073182A (en) * 2002-03-08 2003-09-19 (주)씨큐텍 Prepayment card with a lottery ticket function and payment system and method for election commerce using the card
WO2003083792A2 (en) * 2002-03-28 2003-10-09 Burrows, Colin, Cyril Administration of transactions with pre-payment debit and credit cards
WO2003083792A3 (en) * 2002-03-28 2003-12-18 Burrows Colin Cyril Administration of transactions with pre-payment debit and credit cards
US8315946B2 (en) 2002-07-30 2012-11-20 Acs State & Local Solutions, Inc. Systems and methods for processing benefits
US7865437B2 (en) 2002-07-30 2011-01-04 Acs State & Local Solutions, Inc. Systems and methods for processing benefits
US8185470B2 (en) 2002-07-30 2012-05-22 Acs State & Local Solutions, Inc. Systems and methods for processing benefits
US7774273B2 (en) 2002-07-30 2010-08-10 Acs State & Local Solutions, Inc. Systems and methods for processing benefits
US8340979B2 (en) 2002-10-01 2012-12-25 Acs State & Local Solutions, Inc. Systems and methods for electronically processing government sponsored benefits
US7587434B2 (en) 2002-10-01 2009-09-08 Acs State & Local Solutions, Inc. Method and system for managing a distributed transaction process
US8793187B2 (en) 2003-10-17 2014-07-29 Nexxo Financial Corporation Self-service money remittance with an access card
US8204829B2 (en) * 2003-10-17 2012-06-19 Nexxo Financial Corporation Systems and methods for money sharing
FR2872325A1 (en) * 2004-06-24 2005-12-30 Columbia Finances Sa Payment system for use in shop, has central processing units incrementing balance of credited amount corresponding to amount to be transferred and decrementing balance of deducted amount corresponding to credited amount
US8942677B2 (en) 2009-07-09 2015-01-27 Cubic Corporation Transit account management with mobile device messaging
US10121288B2 (en) 2009-07-09 2018-11-06 Cubic Corporation Transit account management with mobile device messaging
US9996985B2 (en) 2009-07-09 2018-06-12 Cubic Corporation Distribution and enablement of reloadable prepaid cards in transit
US8991699B2 (en) 2009-09-08 2015-03-31 Cubic Corporation Association of contactless payment card primary account number
US8856024B2 (en) 2010-10-26 2014-10-07 Cubic Corporation Determining companion and joint cards in transit
US20150339660A1 (en) * 2012-06-06 2015-11-26 China Unionpay Co., Ltd. Method and system for off-line credit for load
CN103473850B (en) * 2012-06-06 2016-09-28 中国银联股份有限公司 A kind of off line circle deposit method and system
CN103473850A (en) * 2012-06-06 2013-12-25 中国银联股份有限公司 Offline loading method and system
US8690054B1 (en) 2013-05-29 2014-04-08 The Toronto-Dominion Bank System and method for chip-enabled card transaction processing and alert communication
US8864024B1 (en) 2013-05-29 2014-10-21 The Toronto-Dominion Bank System and method for chip-enabled card transaction processing and alert communication
US11145118B2 (en) 2013-11-14 2021-10-12 Ebay Inc. Extraction of body dimensions from planar garment photographs of fitting garments
US11100564B2 (en) 2013-12-27 2021-08-24 Ebay Inc. Regional item recommendations
US11055758B2 (en) 2014-09-30 2021-07-06 Ebay Inc. Garment size mapping
US11734740B2 (en) 2014-09-30 2023-08-22 Ebay Inc. Garment size mapping
WO2017074244A1 (en) * 2015-10-30 2017-05-04 Id Loop Ab Method for payment with a cash card
US11461758B2 (en) 2015-10-30 2022-10-04 Id Loop Ab Method for payment with cash card

Also Published As

Publication number Publication date
AU6970096A (en) 1997-04-01

Similar Documents

Publication Publication Date Title
WO1997010560A1 (en) Stored value transaction system and method using anonymous account numbers
US5596642A (en) Network settlement performed on consolidated information
US6286099B1 (en) Determining point of interaction device security properties and ensuring secure transactions in an open networking environment
US5544086A (en) Information consolidation within a transaction network
US5633930A (en) Common cryptographic key verification in a transaction network
US5621796A (en) Transferring information between transaction networks
US5590197A (en) Electronic payment system and method
US5559887A (en) Collection of value from stored value systems
EP0385400B1 (en) Multilevel security apparatus and method with personal key
US8175973B2 (en) Internet payment, authentication and loading system using virtual smart card
US4386266A (en) Method for operating a transaction execution system having improved verification of personal identification
US5917168A (en) System and method for revaluation of stored tokens in IC cards
US7103575B1 (en) Enabling use of smart cards by consumer devices for internet commerce
EP0047285B1 (en) A system for authenticating users and devices in on-line transaction networks
CA2322356C (en) Credit card system and method
CA2362234A1 (en) Tokenless biometric electronic rewards system
CN104732379A (en) Secure Payment System
Havinga et al. Survey of electronic payment methods and systems
US20020035694A1 (en) Method and apparatus for anonymous remote transactions
WO2001015094A2 (en) Secure system for conducting electronic transactions and method for use thereof
JP2000507380A (en) Safety module
AU723525B2 (en) A method for certifying a running total in a reader
EP1374193B1 (en) Method for conducting secure e-commerce transactions
Kraus Integrity mechanisms in German and International payment systems
Putland et al. Electronic Payment Systems

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
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

Ref country code: CA