WO2003046848A2 - Purse interoperability - Google Patents

Purse interoperability Download PDF

Info

Publication number
WO2003046848A2
WO2003046848A2 PCT/GB2002/005313 GB0205313W WO03046848A2 WO 2003046848 A2 WO2003046848 A2 WO 2003046848A2 GB 0205313 W GB0205313 W GB 0205313W WO 03046848 A2 WO03046848 A2 WO 03046848A2
Authority
WO
WIPO (PCT)
Prior art keywords
card
data item
value data
purse
application
Prior art date
Application number
PCT/GB2002/005313
Other languages
French (fr)
Other versions
WO2003046848A3 (en
Inventor
Barry Sim Hochfield
William Stephen Mcspadden
Original Assignee
Ecebs Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ecebs Limited filed Critical Ecebs Limited
Priority to AU2002343091A priority Critical patent/AU2002343091A1/en
Publication of WO2003046848A2 publication Critical patent/WO2003046848A2/en
Publication of WO2003046848A3 publication Critical patent/WO2003046848A3/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/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

  • the invention relates to electronic purse applications.
  • Such applications are not new technology; they allow consumers who do not have, or cannot obtain, bank accounts, a means of carrying 'cash' with reduced risk. These same consumers are, of course, excluded from paying by credit card by the very fact that they do not hold a bank account.
  • the card application allows them to pay merchants or vendors involved in the scheme using the card.
  • EMV Europay/Mastercard ⁇ isa
  • EMV Europay/Mastercard ⁇
  • ICC Visa Integrated Circuit Card
  • the application allows a card to determine whether a user should be allowed to complete off-line transactions according to in-built card risk management rules. These rules are based on limits specified by the card issuer. Under the Visa scheme, the card is also allowed to force a transaction to go on-line to the issuer if certain limits are exceeded. The card can also decline a transaction instantly if additional limits are reached. All of these limits are configurable by the card issuer and are set according to the issuer's requirements for the application. They also incorporate the cardholder's credit history and requirements.
  • a smartcard and a smartcard system comprising a card bearing an electronic purse application including a current purse value data item and an interface device by means of which the current purse value data item can be input to the electronic purse application; the card also carrying a card risk management application requiring at least one limit value data item; the system being characterised in that the card risk management application utilises the said current purse value data item as the required limit value data item.
  • the current purse value data item and the limit value data item may be stored on the card using different formats; the card is, in a preferred embodiment provided with means for converting the current purse value data item to the format used for storing the limit value data item.
  • such a scheme has the advantage the card can be accepted and will perform the 'normal' transaction irrespective of the terminal used, secure in the knowledge that settlement will occur in the usual way.
  • GenerateAC Generate Application Cryptogram
  • a second GenerateAC command is usually executed so that the card is informed of the issuer's response and/or whether the terminal was actually able to communicate with the issuer.
  • the card then employs further risk management rules to determine how it should react to the different possible responses, that is, either accept or decline transaction.
  • the Visa application specification utilises three data items which are of particular interest. These are described in Table 1 below and are explained in detail in Appendix A of the Visa specification referred to above.
  • these data items are used at a point in the card risk management where the amount of the transaction (Amount Authorised - 'AA') is combined with the COT and then compared to the Cumulative total Transaction Amount limit ('CTTAL'). If the combined total exceeds the CTTAL, the transaction is generally forced to go online. It is only at this point in the transaction flow that the actual amount of the transaction plays any part in the decision process. In effect, all three data items are counters and can be regarded as such. In a similarly simplistic view, the balance held on an electronic purse is also a counter. All of these 'counters' have application-specific rules as to when and how they are updated.
  • the balance can only be updated via a dedicated terminal which accepts cash, performs suitable mutual authentication with the card and then credits the card's cash balance with the received cash value. If this data item is then also referenced as the CTTAL within the Visa application, it is clear that, as cash is spent, the COT will be incremented with each AA received in each offline transaction (as per the normal Visa application flow) until a point is reached where the offline amount stored plus the amount of the desired transaction exceeds the CTTAL (the purse balance) and an online transaction is required to reload the purse.
  • the Visa application allows for 15 bytes of Issuer Discretionary Data, which terminals (in national markets only) pass back to the issuer for interpretation.
  • the purse vendor is the issuer, the opportunity to place status, balance and any other information the issuer desires is provided for via this mechanism.
  • the merchant terminal has the means to accept cash from the cardholder at that point, it may be possible to perform a reload of the purse balance at the merchant terminal.
  • the COT and CTTAL can either be reset as part of the proprietary purse LOAD command or via a zero amount transaction followed by the secure messaging commands detailed below. If the merchant terminal cannot accept cash, visiting the purse issuer's dedicated terminal will allow the purse balance (limit) to be configured under the complete control of the issuer. A dummy EMV transaction, for a zero amount, can then be performed by that terminal to reset the COT value so that the cardholder can immediately use the card in an offline environment.
  • script processing can then be used to update the CTTAL value via a PUT DATA command.
  • the additional benefit of using this value as the 'hook' between the two applications is that there are no limitations as to when the PUT DATA command is executed. If this value were stored in a record within a file, for instance, then the UPDATE RECORD command with secure messaging would need to be invoked.
  • the issue here is that with the current Visa application, only non-critical script processing is supported. Thus, no script processing can occur between GenerateAC commands. Any updates can only be performed after the transaction has been concluded under the currently supported Visa application.
  • the purse issuer is the Visa card issuer
  • the purse balance can be controlled precisely by the issuer using standard Visa functionality.
  • the transaction is simply declined and a standard reload of the purse (with whatever security mechanisms for authentication and data integrity that that scheme provides) is used to add value to the purse.
  • the balance repository if the purse is updated as per normal and the next time the Visa application is called on to perform a transaction, the current purse balance will be extracted and used.
  • the main difficulty which arises is the possibility of a discrepancy between the format used to store the purse balance and, specifically in the case of the Visa application, the CTTAL, which, in the case of Visa V 1.3.2 is a BCD encoded 12-digit value. If the purse application uses a different mechanism, then one of the two applications will require additional functionality to convert the value to the correct format.

Abstract

In a smartcard system, a card bears an electronic purse application including a current purse value data item. The system includes an interface device by means of which the current purse value data item can be input to the electronic purse application. The card also carries a card risk management application requiring at least one limit value data item. In accordance with the invention, the card risk management application utilises the said current purse value data item as the required limit value data item. The current purse value data item and the limit value data item may be stored on the card using different formats and the card may be provided with means for converting the current purse value data item to the format used for storing the limit value data item. This permits the card to be used with a variety of interface devices compatible with different electronic purse applications.

Description

PURSE INTEROPERABILITY
The invention relates to electronic purse applications. Such applications are not new technology; they allow consumers who do not have, or cannot obtain, bank accounts, a means of carrying 'cash' with reduced risk. These same consumers are, of course, excluded from paying by credit card by the very fact that they do not hold a bank account. The card application allows them to pay merchants or vendors involved in the scheme using the card.
One well-known application in this field is the EMV (Europay/MastercardΛ isa) compliant Visa debit/credit V1.3.2 smartcard application detailed in Visa Integrated Circuit Card: Card (ICC) Specification, Visa International, Version 1.3.2, July 1999. The application allows a card to determine whether a user should be allowed to complete off-line transactions according to in-built card risk management rules. These rules are based on limits specified by the card issuer. Under the Visa scheme, the card is also allowed to force a transaction to go on-line to the issuer if certain limits are exceeded. The card can also decline a transaction instantly if additional limits are reached. All of these limits are configurable by the card issuer and are set according to the issuer's requirements for the application. They also incorporate the cardholder's credit history and requirements.
The problem with existing card applications and schemes is the lack of infrastructure needed to support the various schemes in operation. A classical 'chicken-and-egg' situation occurs; unless there are sufficient terminals available for a cardholder to use, the card scheme is of little assistance to the cardholder. Conversely, merchants and vendors cannot be expected to invest in terminals to accept cards, unless there are a significant number of cardholders to support a particular card or purse scheme. Clearly, this situation would be improved if terminals were capable of accepting cards from a number of different schemes.
In accordance with the invention, there is provided a smartcard and a smartcard system comprising a card bearing an electronic purse application including a current purse value data item and an interface device by means of which the current purse value data item can be input to the electronic purse application; the card also carrying a card risk management application requiring at least one limit value data item; the system being characterised in that the card risk management application utilises the said current purse value data item as the required limit value data item. The current purse value data item and the limit value data item may be stored on the card using different formats; the card is, in a preferred embodiment provided with means for converting the current purse value data item to the format used for storing the limit value data item.
Three schemes dominate the retail environment, those of Visa, Europay and Mastercard. In a preferred scheme in accordance with the invention, the same terminal would accept all three kinds of card for payment and existing terminals could be converted to accept all three cards transparently. This would have the advantage to the cardholder that it would no longer be necessary to search for a retail outlet with a terminal specific to his card before being able to use the card to pay for items. (Although, it may be desirable to require a specific terminal to be used to 'reload' the card.)
For the merchant/vendor, such a scheme has the advantage the card can be accepted and will perform the 'normal' transaction irrespective of the terminal used, secure in the knowledge that settlement will occur in the usual way.
An embodiment of the invention will now be described in detail, by way of example.
The core of the Visa application referred to above is a function called Generate Application Cryptogram ('GenerateAC'). One of the key functions of GenerateAC is that of Card Risk Management; during this function the card decides whether or not to accept a transaction, to request that the card goes online or to decline a transaction.
If the card requests to go online, a second GenerateAC command is usually executed so that the card is informed of the issuer's response and/or whether the terminal was actually able to communicate with the issuer. The card then employs further risk management rules to determine how it should react to the different possible responses, that is, either accept or decline transaction.
All of these interactions are transparent to the cardholder. The only indication that either the card holder or merchant/vendor will receive that any additional processing is occurring is that the transaction will take longer to complete if the card and terminal have to go online to the issuer to resolve the transaction status. It is clear from this that it is at the risk management points of the EMV application that any purse application on the consumer's card must interact with the credit/debit application.
The Visa application specification utilises three data items which are of particular interest. These are described in Table 1 below and are explained in detail in Appendix A of the Visa specification referred to above.
Figure imgf000004_0001
Table 1
With respect to the first of the two possible GenerateAC commands, these data items are used at a point in the card risk management where the amount of the transaction (Amount Authorised - 'AA') is combined with the COT and then compared to the Cumulative total Transaction Amount limit ('CTTAL'). If the combined total exceeds the CTTAL, the transaction is generally forced to go online. It is only at this point in the transaction flow that the actual amount of the transaction plays any part in the decision process. In effect, all three data items are counters and can be regarded as such. In a similarly simplistic view, the balance held on an electronic purse is also a counter. All of these 'counters' have application-specific rules as to when and how they are updated.
From this, we have appreciated that there is an opportunity to integrate the purse application.
As a starting point we have considered the on-card applications not to be completely independent of one another. This is a valid assumption because, in fact, most applications share data items such as the PIN used to access the card. If this idea is extended, then there is no reason not to share other information as long as access to those data items is strictly controlled when those items are to be written, updated or read.
For example, if we consider the purse balance, it can be assumed that the balance can only be updated via a dedicated terminal which accepts cash, performs suitable mutual authentication with the card and then credits the card's cash balance with the received cash value. If this data item is then also referenced as the CTTAL within the Visa application, it is clear that, as cash is spent, the COT will be incremented with each AA received in each offline transaction (as per the normal Visa application flow) until a point is reached where the offline amount stored plus the amount of the desired transaction exceeds the CTTAL (the purse balance) and an online transaction is required to reload the purse.
The Visa application allows for 15 bytes of Issuer Discretionary Data, which terminals (in national markets only) pass back to the issuer for interpretation. As the purse vendor is the issuer, the opportunity to place status, balance and any other information the issuer desires is provided for via this mechanism.
If the merchant terminal has the means to accept cash from the cardholder at that point, it may be possible to perform a reload of the purse balance at the merchant terminal. The COT and CTTAL can either be reset as part of the proprietary purse LOAD command or via a zero amount transaction followed by the secure messaging commands detailed below. If the merchant terminal cannot accept cash, visiting the purse issuer's dedicated terminal will allow the purse balance (limit) to be configured under the complete control of the issuer. A dummy EMV transaction, for a zero amount, can then be performed by that terminal to reset the COT value so that the cardholder can immediately use the card in an offline environment.
If this is the case, and there is a mechanism for the issuer to ratify that cash has been received by the merchant on his or her behalf, script processing can then be used to update the CTTAL value via a PUT DATA command. The additional benefit of using this value as the 'hook' between the two applications is that there are no limitations as to when the PUT DATA command is executed. If this value were stored in a record within a file, for instance, then the UPDATE RECORD command with secure messaging would need to be invoked. The issue here is that with the current Visa application, only non-critical script processing is supported. Thus, no script processing can occur between GenerateAC commands. Any updates can only be performed after the transaction has been concluded under the currently supported Visa application.
Thus, in effect, if the purse issuer is the Visa card issuer, the purse balance can be controlled precisely by the issuer using standard Visa functionality.
If, on the other hand, another standard profile, for example, the Europay/Mastercard Mchip Lite profile, were to be used, the same functionality is provided by the comparison of the AA when added to the COT with the Upper and Lower Maximum Off-line Cumulative Amounts. These items are records within the Card Risk management file, but, as the applications supports critical scripts, the issuer can update the balance of the purse (limits) by executing UPDATE RECORD commands between the two GenerateAC commands required to complete the transaction. This again assumes that there is a mechanism by which the merchant can accept cash or payment and this can be ratified between the issuer and the merchant.
In the cases where this is not possible, the transaction is simply declined and a standard reload of the purse (with whatever security mechanisms for authentication and data integrity that that scheme provides) is used to add value to the purse. The balance repository if the purse is updated as per normal and the next time the Visa application is called on to perform a transaction, the current purse balance will be extracted and used. The main difficulty which arises is the possibility of a discrepancy between the format used to store the purse balance and, specifically in the case of the Visa application, the CTTAL, which, in the case of Visa V 1.3.2 is a BCD encoded 12-digit value. If the purse application uses a different mechanism, then one of the two applications will require additional functionality to convert the value to the correct format.
For example, in the case of an existing purse which does not have the correct data format for its balance, it is fair to assume that new cards incorporating this use of both purse and EMV terminals will be issued. It is not unreasonable for the new purse application on these cards to convert the value in the proprietary LOAD_VALUE command into the format used by Visa. The conversion to/from the storage format can be handled by that purse application. This will ensure that existing purse cards and the 'new' purse cards will operate correctly with the dedicated purse terminals.
Conversely, if it is not possible to modify the purse application, it will be necessary to modify the EMV application to perform format conversion when accessing this data value. Additional flags will also be required within the Visa implementation to determine when any modification of the CTTAL value is being performed as part of a Visa standard PUT DATA command when the standard Visa formatting of the command data is being used. All reads and writes of the value will have to be aware of the formatting conversion which occurs. The major impact of this is the need for recertification of the EMV application for any change. Once achieved, interoperability is ensured.
While the invention has been described in relation to the Visa debit/credit V1.3.2 and Europay/ Mastercard Mchip Lite applications, it will be apparent that any EMV application satisfying these specifications will utilise the same group of values and that the format conversion necessary for interoperability can be implemented for other applications as well as those described above.

Claims

1. A smartcard system comprising a card bearing an electronic purse application including a current purse value data item and an interface device by means of which the current purse value data item can be input to the electronic purse application; the card also carrying a card risk management application requiring at least one limit value data item; the system being characterised in that the card risk management application utilises the said current purse value data item as the required limit value data item.
A system according to claim 1 in which the current purse value data item and the limit value data item are stored on the card using different formats; the card being provided with means for converting the current purse value data item to the format used for storing the limit value data item.
3. A system according to claim 1 or 2 in which the limit value data item stored on the card represents the cumulative total transaction amount limit permitted by the on-card electronic purse application before a transaction between the card and the interface device is required to go on-line.
4. A smartcard for use in the system of any of claims 1 to 3 the card comprising an electronic purse application including a current purse value data item and an interface device by means of which the current purse value data item can be input to the electronic purse application; the card also carrying a card risk management application requiring at least one limit value data item; the system being characterised in that the card risk management application utilises the said current purse value data item as the required limit value data item.
5. A smartcard according to claim 4 in which the current purse value data item and the limit value data item are stored on the card using different formats; the card being provided with means for converting the current purse value data item to the format used for storing the limit value data item.
PCT/GB2002/005313 2001-11-26 2002-11-26 Purse interoperability WO2003046848A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002343091A AU2002343091A1 (en) 2001-11-26 2002-11-26 Purse interoperability

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0128292A GB0128292D0 (en) 2001-11-26 2001-11-26 Purse interoperability
GB0128292.0 2001-11-26

Publications (2)

Publication Number Publication Date
WO2003046848A2 true WO2003046848A2 (en) 2003-06-05
WO2003046848A3 WO2003046848A3 (en) 2003-10-16

Family

ID=9926462

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2002/005313 WO2003046848A2 (en) 2001-11-26 2002-11-26 Purse interoperability

Country Status (3)

Country Link
AU (1) AU2002343091A1 (en)
GB (1) GB0128292D0 (en)
WO (1) WO2003046848A2 (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590038A (en) * 1994-06-20 1996-12-31 Pitroda; Satyan G. Universal electronic transaction card including receipt storage and system and methods of conducting electronic transactions
WO1998014916A2 (en) * 1996-10-01 1998-04-09 Michael Coveley Universal credit card
US6016963A (en) * 1998-01-23 2000-01-25 Mondex International Limited Integrated circuit card with means for performing risk management

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590038A (en) * 1994-06-20 1996-12-31 Pitroda; Satyan G. Universal electronic transaction card including receipt storage and system and methods of conducting electronic transactions
WO1998014916A2 (en) * 1996-10-01 1998-04-09 Michael Coveley Universal credit card
US6016963A (en) * 1998-01-23 2000-01-25 Mondex International Limited Integrated circuit card with means for performing risk management

Also Published As

Publication number Publication date
WO2003046848A3 (en) 2003-10-16
AU2002343091A1 (en) 2003-06-10
GB0128292D0 (en) 2002-01-16

Similar Documents

Publication Publication Date Title
US9965762B2 (en) Combicard transaction method and system having an application parameter update mechanism
EP0421808B1 (en) Funds transfer system
USRE36788E (en) Funds transfer system
US8479981B2 (en) Multi application smartcard with currency exchange, location, tracking and personal identification capabilities
AU2002347822B2 (en) System and method for integrated circuit card data storage
US8554668B2 (en) Financial transaction card with installment loan feature
US20040210519A1 (en) System and method for authorizing transactions
JPH07104891B2 (en) Transaction processor
EP1125261B1 (en) Smart card with consolidation means and method of operating the smart card
EP0945833A2 (en) Method and system for remote banking with a multi-memory technology smart card
JP2000163493A (en) Electronic settlement method and system for executing the same
Kwan et al. PIC based smart card prepayment system
US9600954B2 (en) Dynamic application name display
WO2003046848A2 (en) Purse interoperability
US20070069015A1 (en) Payment terminals
JP4490965B2 (en) Value transfer based on smart cards
JPH09134457A (en) Trasaction device for portable recording medium
JPH0830693A (en) Transaction processing method
GB2326011A (en) Mobile data carrier for security modules
JPH11134538A (en) Transaction processor
KR20120031032A (en) Ic card
CN101083006A (en) Method and system for managing self-determination off-line financial trading
KR20120090892A (en) Method for controlling payment

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

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

AL Designated countries for regional patents

Kind code of ref document: A2

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP