Classifications

• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07F—COIN-FREED OR LIKE APPARATUS
  • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
  • G07F7/08—Mechanisms 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/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
  • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/357—Cards having a plurality of specified features
  • G06Q20/3572—Multiple accounts on card
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/357—Cards having a plurality of specified features
  • G06Q20/3576—Multiple memory zones on card
  • G06Q20/35765—Access rights to memory zones
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
  • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user

Definitions

• the present invention relates to smart cards, and in particular, to smart cards which, either solely or in conjunction with other purposes, are used to provide electronic cash services.
• a key disadvantage with scratch cards is the cost of distribution, which represents a significant percentage of the telecom operator's gross revenue (typically - 15% - 20%). For mobile phone network operators this can run into many millions of pounds per year.
• Mobile handsets with a smartcard interface (slot) specifically to communicate with card based applications that can perform the authentication "top up” function and provide payment are known.
• the method for payment in such an arrangement is for the handset to "go on-line” and transfer funds either by authorising a credit or debit transaction from a cardholder's bank account to the telecom network operator directly, or to transfer funds directly in the case of e-cash from a handset connected smartcard to a central server.
• a further problem is the cost associated with revenue collection, fro example from parking meters or the like.
• a suitable electronic cash system would in principle reduce the problems of coin collection and vandalism, but only if a simple, reliable scheme can be implemented.
• the present invention envisages providing, in addition to the single purse in a conventional smart card, an additional, escrow purse denominated in that scheme, with a software agent provided on the smart card.
• the agent is enabled to communicate with a terminal operating on a different electronic cash scheme, to transfer electronic cash according to that scheme, and to meanwhile debit the main purse of the card scheme and credit the separate escrow purse within the smart card.
• the electronic funds are removed from the funds available on the smart card to the holder.
• the funds in the additional purse are marked and recorded, preferably via some ledger facility, as being transferred to the alternative scheme to the credit of the particular merchant.
• the balance in the additional or escrow purse is reconciled, so that the funds can be transferred via the merchant's scheme to the merchant.
• More than one such escrow purse may be provided, to allow for separate escrow purses relating to different electronic cash schemes, or possibly currencies.
• the advantage of such a scheme is that the agent can be implemented purely in software within the smart card.
• the merchant's terminal needs only to support one of the schemes with which the agent is configured to operate, thereby reducing the cost of the merchant terminal. It is inherent in such a system that there needs to be a high degree of trust in the agent as it is mediating between schemes operating on different encryption techniques. Each of these schemes operates independently and does not necessarily fully trust the other. Accordingly, the arrangement proposed is particularly applicable to relatively low value electronic cash transfers, where the amounts involved do not constitute significant loss if the transaction is not completed for some reason. Daily amount and total amount limits on the escrow purse are desirably implemented to minimise the risk associated with fraud or misuse.
• the escrow purse is used to accumulate funds in off-line transactions, even where the same scheme is used by a terminal. This is particularly applicable to situations where it is difficult or expensive to provide a fully functioned terminal. Ledgers and reconciliation occur as in the multi-scheme implementation. Preferably, both multi-scheme and accumulation approaches can be used in tandem.
• the advantages of the inventive arrangement are most clear where a relatively low cost merchant terminal is used, it will be apparent that this arrangement could be used with more sophisticated terminals - for example, ATM type devices. Where on-line connections are available, from the terminal, the transaction could be affected directly via the respective schemes and/or issuers.
• the present invention has greater advantages in the off-line situation, as it allows for the smart card to still reflect the correct value of available electronic cash in the customer - accessible purse, and to have an amount for later reconciliation stored in the escrow purse, which is not susceptible to variation or alteration by the card user. We have accordingly applied the term escrow - that is, the funds are held in this purse, pending later reconciliation, and are not available to the card holder for use in subsequent purchases.
• the present invention allows the transaction to be conducted without the terminal or card operator being concerned with or even aware of which scheme is being used.
• the cardholder loads the smartcard with a value under either a principal or selected scheme, and is thereafter not required to draw distinctions.
• the scheme requires different or additional information or interactions, then the usual prompts will guide the user.
• the present invention is also applicable to other devices which function in similar ways to a smartcard - for example, devices which have been used to provide utility and other services - and these are intended to be encompassed by the broad term smartcard in this specification.
• the devices may use contact or contactless interfaces.
• Figure 1 is a block diagram of the schematic operation of the smart card in communicating with a simple terminal
• Figure 2 is a schematic illustration of the operation of the inventive smart card with a more sophisticated terminal
• Figure 3 is a schematic illustration of the functional blocks within the smart card where the agent has multiple scheme functionality
• FIG. 4 illustrates schematically the operation of one aspect of the invention.
• the present invention will be described in relation to a smart card, which is envisaged as having only electronic purse type functionality. Whilst this may be the case, it is likely that other functionalities - for example, conventional financial services, identification or access functionality - may also be included on the smart card. Only the aspect dealing with electronic cash will be discussed.
• the smart card may be of any conventional type, subject to sufficient non-volatile memory to support the application described.
• the application will be discussed in the context of what would be described as Schemes A, B, etc - it would be appreciated that these could be any electronic cash or similar schemes. For example, apart from the broad schemes previously discussed, they could include the ability to interoperate with specific schemes for telephone access or public transport.
• Electronic cash equivalent to $10.00 is deleted from the balance of purse A, and is credited to the balance of the escrow purse 12, also operating under scheme A. Details of the merchant, date, terminal scheme, etc are stored in ledger 15, to enable later reconciliation. Agent 20 then advises the terminal of the transfer of an appropriate amount of electronic cash under Scheme B, such transfer to be completed once smart card 10 has been inserted into a terminal arrangement capable of reconciling the transaction.
• the merchants terminal 40 may optionally retain appropriate details of the card, user, amount and date for later checking against finalisation of the transaction. Low cost terminals dealing with low value transactions may not retain a log, and simply rely on the single log within the purchaser's card. Alternatively, the merchant's card may be used to retain such a log rather than the terminal.
• a flowchart illustrating this process for an off-line situation is shown as figure 5.
• FIG. 3 illustrates schematically the arrangement of the agent 20 within smart card 10.
• the control software 25 after the card is powered up, determines the scheme in which the terminal operates - for example, this may be scheme B. It then selects from the schemes available to it - shown as interfaces 21 to 24 - the correct application to provide an appropriate interface, in this case scheme B. This provides also the correct protocols for interacting with a scheme B terminal, so that from the perspective of the terminal 40 it is interacting with a valid scheme B card.
• Each interface also communicates with a respective escrow purse 26, 28, 29 and 30, distinct for each scheme. Alternatively, a single escrow purse could be used with some indicia to associate the escrow purse with a particular scheme.
• the control 25 (or alternatively each interface 26, 28,29,30) debits the main purse operating under scheme A as appropriate for each transaction.
• the card user has access only to the balance available in purse A, and optionally the ledger and escrow purse as read only values.
• the ledger 15 can only be rectified and reconciled once appropriate communications with the issuer, or at least a more sophisticated terminal supporting multiple schemes, occurs.
• Figure 2 illustrates a situation when, at some later time after transactions have occurred off-line, smart card 10 is presented to a more sophisticated terminal 50.
• Figure 6 is a flowchart illustrating this process. Smart card 10 may well be inserted into terminal 50 for some other purpose than reconciliation - for example, obtaining an account balance.
• the terminal and smart card software interact using the details in the ledger and the escrow purse so as to reconcile the earlier off-line transaction, empty the escrow purse, and arrange transfer of the appropriate alternative scheme funds to the merchants.
• the smart card may retain a specific purse under the alternative schemes.
• the agent would mediate transfers amongst these purses, subject to the overall security arrangements for the principal or A scheme. It will be apparent that the agent needs to be placed in a secure memory within the smart card, so that it is not subject to alteration by parties other than the card issuer.
• a temporary escrow purse may be used to enable small value transactions i.e. several cents for a time period when operating a telephony device - to be added up, and the transaction finalised once the call is terminated.
• the agent may be enabled to accept the 'click' protocol operating on the telephony service providers lines, so as to add up a progressive tally.
• the proper amount could be debited from the A purse, and added to the appropriate escrow purse - for example, for one specific telecommunications provider or marked up to credit that provider through an alternative scheme.
• the agent will simply select the appropriate scheme, based upon those present at the terminal. Initially, it would attempt to utilise its principal scheme, and utilise others in some order of hierarchy. However, the arrangement is preferably such that the internal interfacing is transparent to the user - as far as the cardholder is concerned, all of these are occurring as scheme A type transactions and a consistent interface is presented to him by the smart card at each terminal to which it is inserted.
• FIG. 4 there is illustrated a smartcard, generally designated 10a.
• Another aspect of the present invention provides a service provision including the steps of: (a) presenting the smartcard 10a to at least one service access point 100a;
• This aspect is particularly relevant to pre-pay mobile phones, and funds collected later, under control of a "revenue collection body".
• the use of SMS' could, therefore, be greatly reduced by use of the improvement.
• the revenue collection body could use a server on the telecom network which "pulls" the funds from the escrow purse via the SMS, transparent to the card holder/phone user, or simply when the card holder/phone user connects the smartcard to the "revenue collection body” to access other services it provides. It is therefore envisaged that the "revenue collection” function, i.e. the emptying of the escrow purse, could be performed by the same bank that issued the payment smartcard.
• card 10a based software application “Intf Module” (2a) controlled by the “Ledger Agent application” (15a), authorises some other service provision point such as a ticket turnstile at a theatre, on a public transport vehicle or even a parking or utility meter.

Applications Claiming Priority (5)

Publications (2)

Family

ID=25645932

Family Applications (1)

Country Status (3)

Families Citing this family (3)

Citations (5)

Family Cites Families (2)

• 1999
  • 1999-11-22 WO PCT/AU1999/001037 patent/WO2000031685A1/en not_active Application Discontinuation
  • 1999-11-22 NZ NZ511831A patent/NZ511831A/xx unknown
  • 1999-11-22 EP EP99960707A patent/EP1131783A4/de not_active Withdrawn

Patent Citations (5)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events