Browse Prior Art Database

Purse Load Recovery

IP.com Disclosure Number: IPCOM000119068D
Original Publication Date: 1997-Nov-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 4 page(s) / 146K

Publishing Venue

IBM

Related People

Bublitz, H: AUTHOR [+2]

Abstract

The electronic purse, typically in the form of a smart card which is loadable from a payment system, such as an Automatic Teller Machine (ATM) network, is an increasingly popular form of payment system.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 42% of the total text.

Purse Load Recovery

      The electronic purse, typically in the form of a smart card
which is loadable from a payment system, such as an Automatic Teller
Machine (ATM) network, is an increasingly popular form of payment
system.

      Moreover, purse load processes can be interrupted.  This can
happen due to electrical mechanical failures at the load station or
within the network of the purse provider or the payment agency.

      The interruption causes inconsistencies between the state on
the card and the state in the payment agency system and the state in
the purse provider system.  The states involve financial balances and
a properly balanced state needs to be recovered.  Since the three
parties are not necessarily connected anymore when the failure ends,
the recovery  cannot be done with a simple commit/rollback protocol.
The recovery has  to take place when the card is on-line to the
system.  Again, very likely  at another load station.

      Currently, recovery is largely performed at the lowest protocol
level, namely at the card protocol level leaving the system
recoverable to fraud.

      In the improved system described here, the commit process
sequence is such that the payment committed with respect to the purse
card holder's disadvantage, if the transaction is interrupted.  This
ensures that incomplete load/unload transactions are always at the
disadvantage of the purse card holder.  For load, the money is
transferred to the purse provider, but the purse is not incremented.
For unload, the purse is decremented, but the money is not
transferred to the purse card holder.  This should prevent most
attempts of fraud by removing cards or interrupting communication.

      During the load/unload transaction, both the purse and the
associated transaction in the load/unload server are kept in an
'in-doubt' state.

      With the 'Initialize IEP for LOAD' command to the purse, the
transaction data is written to the load log of the purse and is
marked as 'in-doubt'.  When a purse is removed from a load/unload
transaction is completed on the purse, the purse stays in the
'in-doubt' state, and  the load log contains the data on the
incomplete transaction.  The purse  can still be used at both
purchase and load devices.  At the next visit  to a load/unload
station, the purse data on the card is reconciled with  the
transaction data in the load/unload server.  Purchase devices may
optionally implement an informational indication displayed when the
purse in the 'in-doubt' state.

      When a load/unload transaction terminates prematurely in the
load/unload server (usually due to a time-out caused by a failure in
the net or in the load/unload device or due to the purse card being
removed), the transaction is logged as 'in-doubt' being either in
phase 'p1' or 'p2'.  During phase 'p1', the payment has not yet been
committed and the purse is in the 'in-doubt' state, too.  During
phase 'p2', th...