Patent Application
20140222646
The present invention relates to a scheme to enable value transfers of commodities with multiple denominations using smartcards, including card-to-card transactions. In this context, the term ‘commodity’ is used to denote anything which is perceived as having a value, including, for example, a currency.
Card-to-card transactions and smartcard-based ‘electronic purse’ schemes have been the subject of research and design activity over the past twenty years. A number of different schemes have been set up, each using differing standards and technologies, for example, the ‘Mondex’ scheme provides ‘loss-less’ value transfer card-toward. Any new scheme should ideally be able to operate with at least a proportion of existing schemes. The approach proposed is, therefore, to utilise ‘open standards’ wherever possible.
The overall goal of any new scheme is to create a viable alternative payment system to that provided by bankcards. The circulation of value should be stimulated through the ubiquitous convenience of an off-line transaction capability, while, at the same time this circulation must be controlled and monitored to provide strong governance to prevent fraud, and to enable the collection of revenues for the provision of the scheme, i.e. cardholders should be required, every so often but not so often as to be perceived an inconvenience, to go on-line to continue to use the service.
It should also be possible to transfer value to a card that, previously, did not trade in a particular commodity from a particular broker. This has the added benefit from the broker's perspective of bringing a new account holder, as in order to register that newly acquired value, a new account must be opened.
For such a scheme to be workable, that is, for it to be secure enough to be practicable, any such scheme should include the following features:
Card-to-host logon should provide remote authentication utilising two separate factors to secure identification of account holder, in general, possession of the card, and knowledge of a separate PIN (personal identification number).
The commodities exchange functionality should permit transactions between card and host, and between one card and another card, that is, both face-to-face and remote transactions.
Multiple commodities from multiple brokers should preferably be present on the same card. If this is to be achieved then this requirement implies an Open System.
It should be possible to introduce new commodities, for example, silver, palladium, etc. into the scheme, both from existing or new brokers and onto cards already in circulation.
There should be provision for interchange between different brokers' commodities, in other words, the technology used must enable the scheme to become an Open System, where commodity brokers and their competitors can inter-operate within the same card-base.
The scheme should have the capability to recognise cards used by ‘merchants’ as opposed to those of ‘consumers’, so that different deposit fee structures can be applied.
There should be provision made, in a customer-merchant situation, to prevent a transaction failing because of ‘insufficient funds’ on the customer card. In this case, the system should support the option for the card to go online to the host to download more available funds to the cardholder and then allow the transaction to retry.
In putting in place a scheme of the kind outlined above, there is a choice of open standard technologies available to adopt. On the surface, the requirements for such a scheme are very similar to the pre-authorised off-line debit profiles found in EMV (Europay, MasterCard & Visa) 2000 [see EMV2000 Integrated Circuit Card Specification for Payment Systems, Book 1: Application Independent ICC to Terminal Interface Requirements, EMVCo, LLC (“EMVCo”), Version 4, December 2000; M/Chip 4 Card Application Specifications for Debit and Credit, Version 1.0 dated October 2002; and Visa Integrated Circuit Card: Card (ICC) Specification, Visa International, Versions 1.4, October 2001]. However, these schemes do not cater to multiple commodities in an open manner, in particular, they do not provide for dynamic management of the addition, deletion or modification of such commodities. More fundamentally, EMV is not capable of handling card-to-card transactions.
In accordance with the invention, there is provided a value transfer scheme wherein users are provided with programmable devices capable of carrying data representing at least one available commodity value, and data representing user accounts are held at a remote processing station; wherein transactions between users are effected by the off-line exchange of data between users' respective programmable devices, the exchanged data containing a record of the or each transaction entered into; and wherein the user account data for each user's account held at the remote processing station is updated only subsequently when that user's programmable device is on-line to the remote processing station and data therefrom is uploaded to the remote processing station.
The invention also provides both an interface device for use in the scheme and a programmable device which carries at least one data file representing an available commodity value and means for interfacing with the programmable device of another user offline by means of the interface device.
In one or more embodiments is provided a system for calculating a commodity transfer by electronic communication between a first programmable hardware device and a second programmable hardware device, the system comprising. The first programmable hardware device is associated with a first user and a first account, the first programmable hardware device generating a first data item including a first value of the commodity owned by the first user. The second programmable hardware device is associated with a second user and a second account, the second programmable hardware device generating a second data item including a second value of said commodity owned by the second user. In the system, the second programmable hardware device receives from the first programmable hardware device the first value of the commodity owned by the first use, subtracts a transfer value from the received first value to create a modified first value; and receives a modified second value from the first programmable hardware device that is created by the first programmable hardware device. In the system, the first programmable hardware device receives from the second programmable hardware device the second value of the commodity owned by the second use, adds the transfer value to the received second value to create a modified second value; and receives a modified first value from the second programmable hardware device that is created by the second programmable hardware device. The system may further comprise a terminal in electronic communication with the first and second programmable hardware devices, wherein the terminal is adapted to support the electronic transaction, the terminal configured to: retrieve the first value from the first programmable hardware device and verify the first value prior to sending the first value to the second programmable hardware device; and retrieve the second value from the second programmable hardware device and verify the second value prior to sending the second value to the first programmable hardware device.
In the system, the first and second programmable hardware devices may be smartcards. In the system, the commodity may be a monetary commodity and the first and second values are monetary values. In the system, the commodity may be a non-monetary commodity and the first and second values are amounts of the non-monetary commodity. In the system, the first programmable may further perform at least one of the group consisting of: creating a log record that the transfer value has been added to the second value of the second user in response to receipt of the modified first value; and uploading information comprising the log record and the modified first value to a remote processing station, wherein the remote processing station stores data representing a first account associated with the first user, wherein the remote processing station updates said first account to reflect subtraction of the transfer value from the first account. In the system, the second programmable may further perform at least one of the group consisting of: creating a log record that the transfer value has been subtracted from the first value of the first user in response to receipt of the modified second value; and uploading information comprising the log record and the modified second value to a remote processing station, wherein the remote processing station stores data representing a second account associated with the second user, wherein the remote processing station updates said second account to reflect addition of the transfer value to the second account.
In the system, the first programmable hardware device may also store a third data item including a third value of a different commodity owned by the first user and the second programmable hardware device stores a fourth data item including a fourth value of said different commodity owned by the second user; and the commodity is a monetary commodity and the first and second values are monetary values; and wherein the different commodity is a non-monetary commodity and the third and fourth values are amounts of the non-monetary commodity. In the system, the first programmable hardware device may also store a third data item including a third value of a different commodity owned by the first user and the second programmable hardware device stores a fourth data item including a fourth value of said different commodity owned by the second user; wherein the commodity is a non-monetary commodity and the first and second values are amounts of the non-monetary commodity; and wherein the different commodity is a monetary commodity and the third and fourth values are monetary values.
Also described herein is a system for calculating commodity transfers between users, the system comprising: a plurality of programmable hardware devices, each programmable hardware device associated with a different user, wherein each programmable hardware device stores a data item including a value of a commodity owned by its user; a remote processing station that stores account data representing user commodity accounts and update said account data in response to an information upload from at least one of the programmable hardware devices; and a transaction terminal for interfacing with at least a first one of the plurality of programmable hardware devices with a second one of the plurality of programmable hardware devices in support of effectuating an electronic transaction, the transaction terminal configured supporting an application module for exchanging commodity values between the first and second ones of the plurality of programmable hardware devices. The commodity values may include: a first value of a commodity owned by a first user of the first one of the plurality of programmable hardware devices; a second value of said commodity owned by a second user of the second one of the plurality of programmable hardware devices; a first modified value comprising the first value minus the transfer value; and a second modified value comprising the second value plus the transfer value. In the system, the first one of the plurality of programmable hardware devices may receive the second value, may perform a calculation to generate the second modified value and may generate the information upload with respect to the commodity account for the first user. In the system, the second one of the plurality of programmable hardware devices may receive the first value, may perform a calculation to generate the first modified value and may generate the information upload with respect to the commodity account for the second user.
In the system, the transaction terminal may be configured to: retrieve the first value from the first programmable hardware device, verify the first value, and then send the first value to the second programmable hardware device; and retrieve the second value from the second programmable hardware device, verify the second value, and then send the second value to the first programmable hardware device. In the system, the first and second programmable hardware devices may be smartcards. In the system, each programmable hardware device may store a plurality of data item, each data item including a value of a different commodity owned by the user. In the system, the commodity may be a non-monetary commodity and the first and second values are amounts of the non-monetary commodity.
In the system, the remote processing station may update said account data with respect to the commodity account for the first user in response to the information upload from at the first one of the plurality of programmable hardware devices by subtracting the transfer value. In the system, the remote processing station may update said account data with respect to the commodity account for the second user in response to the information upload from at the second one of the plurality of programmable hardware devices by adding the transfer value.
The foregoing and other advantages of the invention will become apparent from the following detailed description and upon reference to the drawings, wherein:
A scheme in accordance with the invention will now be described in detail, by way of example, with reference to the drawings, which include a block diagram showing the high-level architecture of a scheme in accordance with the invention, as illustrated in
The scheme of the invention is based around technology derived from the ITSO scheme which is an open standard, as proposed above. For the purposes of this document, the term ‘ITSO’ is intended to denote the Interoperable Ticketing Transaction Scheme for smartcards developed by UK Government and incorporated in European Standard EN 1545, in any of the versions currently available or which become available in future.
ITSO provides a standard set of specifications, an organisation, an open scheme, and a technical architecture. It has enabled the creation of a number of ticketing based smartcard applications, both contact and contactless.
The EMV scheme mentioned above provides a payment method based on credit or debit to one bank's card-carrying customer, while at the same time enabling payment underwriting and collection to another bank's merchant customer.
ITSO operates on somewhat similar principles, however it ensures trust between the parties by enforcing the scheme's security.
In any multi-user scheme, it is essential that the parties taking part—the merchants—must receive their fair share of the income generated or value transferred. In order to achieve precise revenue apportionment, one must create a fully accounted scheme which can capture and subsequently clear each and every transaction with guaranteed integrity and completeness. Also, any log of transaction records must have its integrity ensured and its subsequent transfer for clearance and apportionment guaranteed.
ITSO achieves these various requirements by enabling and enforcing security off-line. This is achieved by providing a tamper resistant Secure Access Module (the ‘ITSO SAM’ or ‘ISAM’) which is present, in transport schemes, in every ticketing machine and turnstile, and which is managed by ITSO's Security Manager module. The ISAM participates in every ticket transaction by acting as the ‘policeman’ or security enforcer of the scheme. It checks integrity of every ticket presented and certifies every transaction. In the scheme of the invention, it is anticipated that each and every terminal which interfaces with cards, whether on-line or off-line will incorporate an ISAM.
The ITSO scheme also specifies a variety of soft ticket templates secured by the ISAM's cryptographic functionality. Within these ticket templates, ticket products ‘owned’ by any scheme operator can be created and processed by virtue of the fact that each and every ticket product can have its own key, also stored in the card.
ISAM and again managed by the ITSO Security Manager. These soft tickets are independent of the card platform technology. This enables any card which conforms with ISO 14443, whether it be memory only or CPU based, to carry an ITSO ticket wallet either alone on a single application card, or alongside other applications on a multi-application card.
At the heart of the ITSO scheme is the ITSO Secure Application Module, the ‘ISAM’, a secure electronic programmable data processing module, the underlying platform for which is an ISO 7816 compliant High Capacity Card. The card has over 4 Megabytes of secured memory and the ISAM can communicate at over 600 Kb/s (ISO 7816 T=1). The card includes a full set of hardware accelerated cryptographic capabilities, such as RSA (a cryptosystem that executes symmetric or asymmetric algorithms) and triple DES (Data Encryption Standard module that performs calculations and algorithms). Architecture of such a card is depicted generally in
In the ITSO scheme, each card may carry one or more ‘e-tickets’. These are acquired from merchants taking part in the scheme in return for payment. When a card-user is acquiring e-tickets from the merchant the data files which form the e-tickets are loaded onto the smartcard from an interface device containing an ISAM. When the card-holder wishes to use the tickets he has purchased, in order to travel, the e-ticket files are downloaded from the smartcard to the ISAM-containing interface device. It will be appreciated that in the conventional ITSO scheme, there is no provision for a two way flow nor is there any provision for card-to-card transactions. At first glance, therefore, the ITSO scheme has some of the same disadvantages as a basis for a multiple commodity value transfer scheme as the EMV scheme discussed above.
However, we have appreciated that the ITSO scheme is capable of adaptation to provide a workable value transfer scheme with the functionality outlined above.
The scheme of the invention relies on the provision of multiple ‘e-chequebooks,’ one for each commodity account, resident on each card. The structures for these e-chequebooks are based on ITSO ticket templates [see ITSO Specification Part 2: Card and Basic Data structure Version 2 November 2000 and ITSO Specification Part 5: Card format and Data Records Version 2 November 2000, incorporated herein by reference]. Each e-chequebook is, in fact, a digital certificate, that is, a set of data, the integrity of which is enforced by the use of cryptography. Multiple e-chequebooks representing multiple accounts from multiple commodity brokers can be loaded or deleted on a card even in the field, assuming the card issuer gives permission. Thus, the scheme will permit multiple commodities from multiple brokers to be present on the same card.
The keys used to verify and modify the contents of each e-chequebook are also stored in each card. As each e-chequebook can have its own key, the privacy and security of the account is assured across the entire scheme. The Scheme has a Security Management System (SSMS) that is responsible for the generation and usage of all keys. There is also an Application Management System (AMS) responsible for the secure loading and deletion of e-chequebooks, which, in turn, is reliant on keys managed by the SSMS.
Transactions between card-holders are effected by transferring electronic cheques (‘e-cheques’) between cards, off-line.
The e-chequebooks are analogous to ITSO IPEs (Interoperable Product Entity: ITSO terminology for an e-ticket), and the cheques are analogous to ITSO ticket transaction records. The secure loading and deletion of cheques and the host-to-card increment/decrement of the balance in each cheque-book [see ITSO Specification Part 4: Back Office Systems Version 2 November 2000, incorporated herein by reference] is managed by the ITSO Secure Frame messaging [see ITSO Specification Part 7: Security Access Module Version 2 November 2000, incorporated herein by reference].
Unlike the EMV scheme, the ‘e-cheques’ do not themselves change the commodity values held in some form of electronic purse or account, but, rather, act as a record of a transaction which is to take place in the future. This is exactly analogous to cheques written on a conventional bank account; it is not the writing and handing over of the cheque which affects the transfer of funds to the recipient but, rather the clearing of the cheque through the recipient's bank account.
Card to card transactions can be repeated off-line until either there is no more available memory to store new ‘cheques’, or, alternatively, a ‘cheques counter’ is tripped. At this point the card must go on-line to the scheme host to ‘cash the cheques’, i.e. the transactions are uploaded from the card to be cleared through a central exchange processing center.
When the card goes on line to the host, its unique ID is first passed to the SSMS. The SSMS will send a card-unique challenge in the form of a message secured by the scheme keys. Only a single valid card can respond correctly. This response will also depend on the correct entry of a cardholder validation method such as a PIN. This action therefore serves as a secure remote login, using two-factor remote authentication as proposed in the list of desiderata set out above. The unique ID allows the host to recognise ‘merchant’ cards and distinguish them from those of consumers.
Thus, in the scheme of the invention, e-cheques are exchanged between cards off-line, until the user goes on-line to the ‘back office’, that is, the central processing location for the scheme. At that point, the e-cheques are downloaded and electronic purses and accounts updated on-line.
As mentioned above the ITSO transport-related scheme itself does not require provision for card-to-card transactions and so we have had to modify the ITSO structure to allow for this in the value transfer scheme of the invention.
When two cards interface, the presence of compatible e-chequebooks is verified, and, upon authorisation, in the form of a cardholder verification method, two ‘e-cheques’ are created and exchanged. One of these, analogous to a paper cheque, acts to increment the e-chequebook balance on one card, and the other to perform the corresponding complimentary decrement of the balance in the e-chequebook in the other card, analogous, perhaps, to the record kept on the chequebook stub in a paper system.
The cardholder verification, under present systems, is likely to involve provision of a PIN but this can be modified to other cardholder verification method, such as biometrics, in the future.
If the second card does not have the required e-chequebook then providing the card permissions allow a new e-chequebook to be created into which the value is added. Thus, the functionality of the scheme proposed permits easy introduction of new commodities, when required.
If, in a customer-merchant situation, a transaction fails due to insufficient funds being available on the customer's car, the customer card may go on-line to the host to download more available funds and then allow the local transaction to try again. This operation may be entirely transparent to both the merchant and customer. This is only possible, of course, where, as is usual, the merchant terminal is connected to the central processing location.
The high-level architecture of the scheme in accordance with the invention is shown in
When a card-holder needs to go on-line, the card interfaces with a terminal 12 connected, for example, by means of the internet or other computer network, with the back room 14 so that existing e-cheques can be cleared and values for accounts or electronic purses up- or downloaded. Part of the back room operation 16 also deals with the issuing and personalisation of new cards.
Where card-to-card transactions are to take place as at 10 in
The sequence of commands shown in
First of all mutual authentication of the two cards is carried out by the terminal; in each case the card-holder is required to supply a PIN or other means of verifying the card's authenticity, in accordance with steps 210 and 220 of
The terminal application (the ISAM) then reads the binary DIR from each card and verifies it and then reads the e-chequebook value (IPE1) from the first card, Card1, verifies it and writes it to the other card, Card2, in accordance with steps 230, 240, 250, 260, 265, and 270 of
The second card, Card2, then creates internally a MODIFY VALUE IPE command to subtract the desired amount from the value of the e-chequebook IPE1 to create a modified version of IPE1, in accordance with step 285 of
The terminal then reads the modified value IPE1 from Card2 and passes it to the other card, Card1, in accordance with step 290 of
The terminal then reads the modified IPE2 from Card1 and writes it back to Card2, in accordance with step 295 of
The terminal interfaces with the cards to update the running totals for the e-chequebooks held on the cards, although this information is not updated against the card-holders accounts until they go on-line to the host, and also, by means of the ‘e-cheques’ in the form of the IMAC logs, creates a record of each transaction affecting the e-chequebook, in accordance with steps 290, 295 of
Thus, the scheme of the present invention is capable of providing a multiple commodity value transfer scheme which permits the desirable features listed above, including, in particular, card-to-card transactions off-line from the central processing location.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0305806.2 | Mar 2003 | GB | national |
The present application is a continuation application, claiming the benefit of priority to U.S. application Ser. No. 10/548,762 filed Aug. 16, 2006, which claims the benefit of International Application No. PCT/GB04/01094 filed Mar. 15, 2004, which claims the benefit of GB 0305806.2 filed Mar. 13, 2003, all of which are hereby incorporated by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10548762 | Aug 2006 | US |
| Child | 14246778 | US |
