US20140222646A1

US20140222646A1 - Smartcard-based value transfer

Info

Publication number: US20140222646A1
Application number: US14/246,778
Authority: US
Inventors: Barry Sim Hochfield; Anthony Breslin; Michael Peters
Original assignee: Ecebs Ltd
Current assignee: Ecebs Ltd
Priority date: 2003-03-13
Filing date: 2014-04-07
Publication date: 2014-08-07
Also published as: CN1788291A; JP4490965B2; GB2414590A; CN103839329A; GB2414590B; JP2006520499A; US20070094149A1; US8694437B2; WO2004081889A1; EP1609122A1; GB0305806D0; CN103839329B; GB0519180D0; HK1197310A1

Abstract

In a value transfer scheme, users are provided with programmable devices, for example, smart cards, capable of carrying data representing at least one available commodity value. Data representing user accounts is held at a remote processing station. Transactions between users are effected by the off-line exchange of data between users' respective smartcards, the exchanged data containing a record of each transaction entered into. The user account data for each user's account held at the remote processing station is updated only subsequently when the user's smartcard is on-line to the remote processing station and data therefrom is uploaded to the remote processing station. The scheme of the invention can, conveniently, be based around the ITSO scheme which is used to govern the secure transfer of data The scheme is capable of providing a secure multi-commodity value transfer system.

Description

PRIORITY CLAIM

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.

BACKGROUND

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.

SUMMARY

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.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other advantages of the invention will become apparent from the following detailed description and upon reference to the drawings, wherein:

FIG. 1 is a block diagram showing the high-level architecture of a scheme described herein;

FIG. 2 depicts a sequence of commands between terminal and cards as described herein;

FIG. 3 schematically illustrates a typical smart card architecture as described herein; and

FIG. 4 depicts a sequence of commands between terminal and cards as described herein and in FIG. 2.

DETAILED DESCRIPTION

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 FIG. 1.
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 FIG. 3, which includes a hardware unit (microprocessor/integrated circuit) 210, software 220, secured memory (ROM) 230, working memory (RAM) 240, an input/output controller 250, and a communications unit 260, said architecture can, in accordance ITSO Specification, support executable code that may be loaded thereon to configure its operation as required. Typically, this can all be provided in a standard ISO 7810 and ID-000 form-factor to fit into a socket as for a GSM SIM, of the kind used in mobile telephones. The ISAM has been developed to meet the internationally recognised security assurance methodology, Common Criteria at AEL 4 high.
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 FIG. 1. At 10 there is shown schematically the situation which holds when off-line card-to-card transactions are carried out. Each card-holder's card interfaces with a local terminal which is not connected to the central processing location 14 or ‘back room’.
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 FIG. 1, the scheme of the invention operates as follows.
The sequence of commands shown in FIG. 2 between terminal and cards is proposed to conduct a card-to-card value transfer based on the ITSO standard. Reference is made to FIG. 3, which also shows sequence of commands provided in FIG. 2, and as outlined in the discussion below.
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 FIG. 2; hardware 310, software 320, memory 330, controller 350, and communications unit 360 of FIG. 3; and steps 405, 410, 415, and 420 of FIG. 4. If the PIN or other verification is not supplied, then the transaction will cease.
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 FIG. 2; hardware 310, software 320, memory 330, controller 350, and communications unit 360 of FIG. 3; and steps 415, 420, and 430 of FIG. 4. The ISAM then reads the corresponding e-chequebook value (IPE2) from the second card, Card2, verifies it, and writes it to Card1, so that each card now has a verified copy of the e-chequebook value of the other card, in accordance with steps 275, 280 of FIG. 2; hardware 310, software 320, memory 330, controller 350, and communications unit 360 of FIG. 3; and steps 415, 420, 425 of FIG. 4.
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 FIG. 2; hardware 310, software 320, memory 330, and controller 350 of FIG. 3; and step 440 of FIG. 4. It also creates an internal IMAC command to log the fact that the amount has been deducted from Card1, in accordance with step 285 of FIG. 2; hardware 310, software 320, memory 330, memory 340, and controller 350 of FIG. 3; and step 440 of FIG. 4.
The terminal then reads the modified value IPE1 from Card2 and passes it to the other card, Card1, in accordance with step 290 of FIG. 2; hardware 310, software 320, memory 330, controller 350, and communications unit 360 of FIG. 3; and step 440 of FIG. 4. Card1 can then calculate how much has been subtracted from its own IPE and internally issues a MODIFY VALUE IPE command to add that amount to IPE2, in accordance with step 290 of FIG. 2; hardware 310, software 320, memory 330, controller 350, and communications unit 360 of FIG. 3; and step 435 of FIG. 4. Card1 logs the transaction by creating an IMAC command to record the fact that the amount has been added to the IPE of Card2, in accordance with step 290 of FIG. 2; hardware 310, software 320, memory 330, memory 340, controller 350, and communications unit 360 of FIG. 3; and step 440 of FIG. 4.
The terminal then reads the modified IPE2 from Card1 and writes it back to Card2, in accordance with step 295 of FIG. 2; and hardware 310, software 320, memory 330, memory 340, controller 350, and communications unit 360 of FIG. 3. Preferably, the terminal also generates an IMAC log to record the transaction details.
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 FIG. 2; and hardware 310, software 320, memory 330, memory 340, controller 350, and communications unit 360 of FIG. 3.
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.

Claims

What is claimed is:

1. 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 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; and

the second programmable hardware device 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;

wherein 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, and

wherein 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.

2. The system of claim 1, further comprising 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.

3. The system of claim 1, wherein the first and second programmable hardware devices are smartcards.

4. The system of claim 1, wherein the commodity is a monetary commodity and the first and second values are monetary values.

5. The system of claim 1, wherein the commodity is a non-monetary commodity and the first and second values are amounts of the non-monetary commodity.

6. The system of claim 1, wherein the first programmable further performs 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.

7. The system of claim 1, wherein the second programmable further performs 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.

8. The system of claim 1, wherein the first programmable hardware device also stores 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

wherein 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.

9. The system of claim 1, wherein the first programmable hardware device also stores 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

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.

10. 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, wherein the commodity values comprise:

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;

wherein the first one of the plurality of programmable hardware devices receives the second value, performs a calculation to generate the second modified value and generates the information upload with respect to the commodity account for the first user; and

wherein the second one of the plurality of programmable hardware devices receives the first value, performs a calculation to generate the first modified value and generates the information upload with respect to the commodity account for the second user.

11. The system of claim 10, wherein the transaction terminal is 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.

12. The system of claim 10, wherein the first and second programmable hardware devices are smartcards.

13. The system of claim 10, wherein each programmable hardware device stores a plurality of data item, each data item including a value of a different commodity owned by the user.

14. The system of claim 10, wherein the commodity is a non-monetary commodity and the first and second values are amounts of the non-monetary commodity.

15. The system of claim 10, wherein the remote processing station updates 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.

16. The system of claim 10, wherein the remote processing station updates 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.