US20030236748A1 - Apparatus and methods for collecting value - Google Patents

Apparatus and methods for collecting value Download PDF

Info

Publication number
US20030236748A1
US20030236748A1 US10/462,315 US46231503A US2003236748A1 US 20030236748 A1 US20030236748 A1 US 20030236748A1 US 46231503 A US46231503 A US 46231503A US 2003236748 A1 US2003236748 A1 US 2003236748A1
Authority
US
United States
Prior art keywords
purse
credit
receipt
cheque
granted
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US10/462,315
Inventor
Carmi Gressel
David Milstein
Avi Sander
Isaac Hadad
Ran Granot
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Western Digital Israel Ltd
Original Assignee
M Systems Flash Disk Pionners Ltd
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 M Systems Flash Disk Pionners Ltd filed Critical M Systems Flash Disk Pionners Ltd
Priority to US10/462,315 priority Critical patent/US20030236748A1/en
Publication of US20030236748A1 publication Critical patent/US20030236748A1/en
Assigned to MSYSTEMS LTD reassignment MSYSTEMS LTD CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: M-SYSTEMS FLASH DISK PIONEERS LTD.
Assigned to SANDISK IL LTD reassignment SANDISK IL LTD CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: MSYSTEMS LTD
Abandoned legal-status Critical Current

Links

Images

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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363Payment 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 apparatus and methods for computerized collection of payment.
  • the present invention seeks to provide improved apparatus and methods for computerized control of payment collection.
  • a system for safe collection of payment in return for goods, values or services including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a purse control unit operative to prevent the purse, off-line, from exceeding the credit for value receivable which it has been granted.
  • each of the purses includes a SAM (security application module).
  • each purse monitor is public-key protected.
  • each purse control unit is public-key protected.
  • a system for safe collection of payment in return for goods, values or services including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including a purse monitor operative to sign and authenticate a time-stamped transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a purse control unit operative to prevent the purse, off-line, from extending a credit for value receivable which it has been granted over more than a predetermined period of time.
  • the purse control unit operates off-line.
  • a public-key protected system for safe collection of payment in return for goods, values or services including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing, in public key protected form, an amount of credit for value receivable granted to the individual system element, each purse including a public-key protected purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a public-key protected purse control unit operative to prevent the purse, off-line, from exceeding the credit for value receivable which it has been granted.
  • system for safe collection of payment in return for goods, values or services including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a purse control unit operative to prevent the purse from exceeding the credit for value receivable which it has been granted, wherein at least one first purse from among the multiplicity of purses includes a credit granting unit operative to grant an amount of credit for value receivable granted to at least one second purse from among the multiplicity of purses only in response to activation by a predetermined plurality of system directors.
  • a system for safe collection of payment in return for at least one of goods, values and services including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a purse control unit operative to prevent the purse from exceeding the credit for value receivable which it has been granted, wherein at least one first purse from among the multiplicity of purses includes a credit granting unit operative to grant an amount of credit for value receivable granted to at least one second purse from among the multiplicity of purses only in response to activation by at least one system director and operative to record information regarding the activation including the identity of the at least one system director.
  • a cheque-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a cheque having an intended beneficiary
  • a cheque-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a cheque
  • a set of rules frozen within the first and second memories which allows a cheque issued by the cheque sending security access module to be used by the cheque receiving securing access module only if the cheque has not been used previously and only if the intended beneficiary of the cheque is the cheque-receiving security access module.
  • each of the memories includes a public-key signature protected in non-volatile memory.
  • each of the memories includes public key data in protected externally inaccessible non-volatile memory which would include the SAM's secret key and the application owner's certification of the SAM's identifying data and public key.
  • a method for safe collection of payment in return for goods, values or services including providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, and, for at least one purse, signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and preventing the purse, off-line, from exceeding the credit for value receivable which it has been granted.
  • the second cryptocomputer is operative to generate a sequence of non-repeating numbers, wherein the set of rules includes the following rules:
  • a cheque cannot be received by the cheque receiving module unless a request therefor has been generated by the cheque receiving module, the request including a unique number from the sequence,
  • a cheque generated by the cheque-sending module must include the unique number associated with that cheque, the amount of the cheque and the identity of the intended beneficiary of the cheque, and the cheque-sending module's signature upon the number, the amount and the identity, and
  • the cheque-receiving module must keep a record enabling itself to differentiate used cheques from unused cheques and must confirm that a cheque is an unused cheque before using the cheque.
  • apparatus for transmitting electronic receipts over open channels, each receipt having an intended beneficiary
  • the apparatus including a receipt-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a receipt, a receipt-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a receipt to generate credit, and a set of rules frozen within the first and second memories which allows a receipt issued by the receipt sending security access module to be used by the receipt receiving securing access module only if the receipt has not been used previously to generate credit and only if the intended beneficiary of the receipt is the receipt-receiving security access module.
  • each of the memories includes a public-key signature certificate protected in non-volatile memory.
  • the set of rules is protected by a tamper-resistant architecture.
  • the second cryptocomputer is operative to generate a sequence of non-repeating numbers, wherein the set of rules includes the following rules:
  • a receipt cannot be received by the receipt receiving module unless a request therefor has been generated by the receipt receiving module, the request including a unique number from the sequence,
  • a receipt generated by the receipt-sending module must include the unique number associated with that receipt, the amount of the receipt and the identity of the intended beneficiary of the receipt, and the receipt sending module's signature upon the number, the amount and the identity, and
  • the receipt-receiving module must keep a record enabling itself to differentiate used receipts from unused receipts and must confirm that a receipt is an unused receipt before using the receipt.
  • the value receivable includes cash receivable and/or accounts receivable.
  • a method for safe collection of payment in return for goods, values or services including providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, and, for at least one of the purses, signing and authenticating a time-stamped transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and preventing the purse, off-line, from extending a credit for value receivable which it has been granted over more than a predetermined period of time.
  • a public-key protected method for safe collection of payment in return for goods, values or services including providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing, in public key protected form, an amount of credit for value receivable granted to the individual system element, and, for at least one of the purses, signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and preventing the purse, off-line, from exceeding the credit for value receivable which it has been granted.
  • a method for safe collection of payment in return for goods, values or services including providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, and, for at least one of the purses, signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and preventing the purse from exceeding the credit for value receivable which it has been granted, wherein at least one first purse from among the multiplicity of purses grants an amount of credit for value receivable granted to at least one second purse from among the multiplicity of purses only in response to activation by a predetermined plurality of system directors.
  • a method for safe collection of payment in return for at least one of goods, values and services including providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, and, for at least one of the purses, signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and preventing the purse from exceeding the credit for value receivable which it has been granted, wherein at least one first purse from among the multiplicity of purses grants an amount of credit for value receivable granted to at least one second purse from among the multiplicity of purses only in response to activation by at least one system director and operative to record information regarding the activation including the identity of the at least one system director.
  • a method for transmitting electronic cheques over open channels, each cheque having an intended beneficiary including providing a cheque-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a cheque having an intended beneficiary, providing a cheque-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a cheque, and following a set of rules frozen within the first and second memories which allows a cheque issued by the cheque sending security access module to be used by the cheque receiving securing access module only if the cheque has not been used previously and only if the intended beneficiary of the cheque is the cheque-receiving security access module.
  • a method for transmitting electronic receipts over open channels, each receipt having an intended beneficiary including providing a receipt-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a receipt, providing a receipt-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a receipt to generate credit, and following a set of rules frozen within the first and second memories which allows a receipt issued by the receipt sending security access module to be used by the receipt receiving securing access module only if the receipt has not been used previously to generate credit and only if the intended beneficiary of the receipt is the receipt-receiving security access module.
  • off-line agents bus drivers, fuel station attendants, merchants, parking meters, vending machines, etc.
  • An off-line terminal is one that handles all or some transactions without communicating with a central data-base.
  • the electronic purse for relatively large transactions, used in true off line applications, is a relatively new technology, due to the only recent advent of Public Key Smart Cards. With these new smart cards, a valid user can prove to any accepting terminal in the system, that the smart card is owned by a valid user, and that at a given time, the card has a credit balance sufficient to cover a proposed transaction.
  • a smart card chip such as those manufactured by the applicant/assignee, Fortress U & T Ltd.
  • the same chip can be uniquely initialized and personalized by several independent issuers, and each issuer may embed a unique variety of purses and information protecting applications in an individual user's card.
  • a vendor or service terminal can receive payment for goods and services from either a debit (stored cash value) purse or a credit purse. This electronic money is transferred, probably at the end of the day, to a clearance organization which properly credits his account.
  • the EMV is drafting new rules which will allow the terminal to agree, for instance, that certain payments, usually small payments less than a predetermined threshold, be made only from a stored cash value purse, and larger transactions are made using a regulated debit or credit purse.
  • the terminal will either maintain separate purses for each clearance organization, as in all probability, the strategies for each might differ, or it may collect all electronic payments, archive them, hash and sign the hash to testify to origin, and send to a single clearance organization. Purses in smart cards with safely stored electronic cash or electronic credit will make electronically signed purchases, which will benefit from clearance procedures similar to today's checks and credit card purchases, with a larger degree of confidence than was previously enjoyed.
  • each level of transactions involves larger value physical cash purse to purse transactions, e.g., drivers to cashiers or treasurers, or cashiers to treasurers, in-system employees to validating participants where at each stage the sums of CCRs grow. Collusion between high and low hierarchy participants is most likely. Keeping control of cash with proper archiving, transmission of all raw data to the central computer for filtering, and purse to purse transactions using PKC offer good protection.
  • CCR credit for cash receivable'
  • CCR is a regulating entitlement mechanism that the system operator may employ to administer the limits of the amount of cash in the float, and to assure that operators of purse-reloading terminals, or any intermediaries who receive cash destined to the system operator are limited in the amount of cash they receive before depositing such physical cash with the entitled SSC holder or bank, and to compel them to remit all of the receipts provide for in an orderly and secured continuation of the cash collection system.
  • a system smart card's CCR is exhausted, the owner cannot use his purse to dun a consumer or another system card for cash.
  • the SSC CCR purse is decremented by the same amount that the consumer's electronic purse is incremented, e.g. a bus driver who accepts AMT cash from a passenger, to be deposited in the passenger's cash purse; the driver's CCR will now contain AMT less, and the passenger will have AMT more in his ECASH purse to be spent on travel or in the bus station, or cashiers to treasurers, in-system participants to validating participants where at each stage the sums of CCRs grow.
  • a bus driver who accepts AMT cash from a passenger, to be deposited in the passenger's cash purse
  • the driver's CCR will now contain AMT less, and the passenger will have AMT more in his ECASH purse to be spent on travel or in the bus station, or cashiers to treasurers, in-system participants to validating participants where at each stage the sums of CCRs grow.
  • the CCR in A is decremented as he receives cash from B, whilst the same value from A's CCR increments B's CCR; e.g., a driver brings his $600 in cash receipts to a station's treasurer; the treasurer's CCR is decreased by $600, and the driver's CCR is reloaded with $600, probably following a company rule that at every deposit that the driver makes with a treasurer, the driver must replenish his CCR to the maximum float that the system operator granted him.
  • the single entry point for CCRs is via the managing directors to the central accountant.
  • the accountant arranges the individual allotments according to the director's strategy, and submits, with a single CCR of the total sum to be allotted, accompanied by a list of unsigned CCCRs (cheques for credit for cash receivables) to the manager of cashflow—who electronically allots CCRs, e.g. by simply approving a spread sheet sent to him by the accountant, with a program which commands his smart card to sign the cheques and then to dispatch these cheques for credit for cash receivables; much as he would sign and send present day cheques.
  • CCCRs cheques for credit for cash receivables
  • a secured file is generated, which can be read by any terminal, but can only be addressed by the manager of cashflow.
  • This file contains the limit of CCRs which can be loaded into a card, and an optional date of expiration. In general, this file can only be changed by the manager of cashflow, and this only under the aegis of central accounting. An option is allowed for the station manager to grant, to a qualified SSC, a larger amount of maximum float, for a minimal period of time.
  • a preferred solution to this problem is that the treasurer will receive a blind cheque, that goes through a normal clearance mechanism, wherein the treasurer alone is able to use the cheque to increment his CCR, and he and only he can use the cheque once and only once.
  • An analogy might be—a rogue treasurer receiving a conventional bank check payable to him alone which he wished to use to credit his account several times (in the absence of a clearance mechanism that might detect such a scam); as the check was made from an easily detectable unobtainable paper, and the printing on the checks was impossible to duplicate, no matter what methods he would use, he would be unable to make acceptable copies of the cheque to enable him to credit his account several more times.
  • the method used here for assuring that a cheque can be credited, once, and only once, is for the issuer of the cheque to know a unique number, which was provably generated by the receiver's smart card (SAM) to be used once and only once, which, as the receiver's protocol is frozen, entitles the receiver to receive a cheque with his primary account number and the unique number only once.
  • This number can be the result of a simple count.
  • the writer of the cheque knows these numbers, as his smart card (SAM), received the number in an electronically signed request for the cheque for credit for cash receivables (RCCCR), signed duly by the potential recipient of the cheque.
  • the Bank's Receipts A similar situation arises when the treasurer (or a lottery kiosk collector or a fuel station treasurer) deposits value in the bank.
  • the bank is typically not an active participant in the payment system, but may be willing that the teller be willing to confirm with an electronic receipt (the equivalent of signing a deposit slip), which the teller can sign. This is making no more demand of the teller for actions, other than those he normally executes.
  • the central accountant's SAM and his alone, is programmed to be able to convert a RECeipt from the bank into CCRS.
  • the central accountant's SAM CCR account is totaled once a day, and converted into a single cheque for the manager of cashflow.
  • the manager of cashflow sets the strategy for distributing CCCRs to the depot treasurers, and the central accountant reconciles this policy, and prepares unsigned electronic cheques for the manager of cashflow to approve and sign. These cheques are automatically distributed by modem to the depots' electronic mailboxes for the treasurers to collect and reinstate their CCRS, entitling them to continue collecting $CASH from drivers and cashiers, to be deposited in the bank, to credit the transportation system's account.
  • parking meters and vending machines in sensitive to vandalism locations which cannot accept $CASH will be programmed to allow a user to draw a small amount (such as $25) from his credit purse (account) in order to restore his stored value purse and use the meter/machine.
  • account a small amount
  • the meter/machine would be limited with “credit for cash receivables”, determined by the system operators.
  • a vendor's terminal can be programmed so that it must deposit cash received within a certain time bound. In a public transportation scenario, 48 hours is a suitable limit, without levying a fine.
  • the above-described cashflow system may be generated as follows: The hardware is supplied off the shelf by Fortress U&T Ltd.
  • Each work station in a preferred embodiment is an IBM type PC equipped with Windows 3.1 or 95, 16 Mbyte of RAM, a hard disk and a BestCrypt-4-PC drop in card, at least one smart card reader.
  • An issuer's workstation is maintained in a very well protected area, used for initializing smart cards and workstation SAMS, and it is used to configure the workstations, each with proper access and priority.
  • the Smart Cards and SAMS used in the system are the first generation SGS-Thomson ST-CF54 with the first version SCOS+ operating system.
  • FIG. 1 is a simplified block diagram of a payment collection system useful for a transportation network, the system being constructed and operative in accordance with a preferred embodiment of the present invention
  • FIG. 2 is a simplified flowchart illustration of a method for performing a purse-to-purse transaction between two operator personal modules (OPMs) of FIG. 1 such as between a driver's OPM and a depot treasurer's OPM or such as between a depot treasurer's OPM and a depot manager's OPM;
  • OPMs operator personal modules
  • FIG. 3 is a simplified flowchart illustration of a method for canceling the purse-to-purse transaction of FIG. 2 if the purse-to-purse transaction failed;
  • FIG. 4 is a simplified flowchart illustration of a method for performing the cheque receiving step of FIG. 2 for applications in which the cheque for credit for cash receivables as sent without third party clearance;
  • FIG. 5 is a simplified flowchart illustration of a transaction cycle performed by the various elements of FIG. 1;
  • FIG. 6 is a simplified block diagram of a payment collection system constructed and operative in accordance with a preferred embodiment of the present invention which is operative to collect value from smart card bearers (clients) and to load electronic money into the clients' smart cards;
  • FIG. 7 is a simplified flowchart illustration of the operation of the smart card of FIG. 6, for an application in which the smart card is installed in a parking meter;
  • FIG. 8A is a simplified flowchart illustration of a preferred method for performing the “charge for parking” step 750 of FIG. 7;
  • FIG. 8B is a sample table storing predetermined sequences of parking time-intervals
  • FIG. 9 is a simplified flowchart illustration of a preferred method for performing the “process smart card insertion event” step of FIG. 8A;
  • FIG. 10 is a simplified flowchart illustration of a preferred method of operation for a warden summoned by the method of FIG. 7;
  • FIG. 11 is a simplified flowchart illustration of a preferred method for incrementing the electronic cash balance of a user's card
  • FIG. 12 is a pictorial diagram illustrating the flow of electronic value between a user's smart card/s, a parking meter's SAM and a parking warden's OPM;
  • FIG. 13 is a pictorial diagram illustrating a preferred flow of electronic value between a parking warden's OPM, a parking meter operator, and a purse operator.
  • FIG. 14 is an illustration of a public key authentication hardware interface supporting up to four smart card readers which is useful in one implementation of the present invention
  • FIG. 15 is a pictorial illustration of a display screen generated by a transaction terminal.
  • FIG. 16 is a pictorial illustration of a display screen generated by a smart card application developer.
  • Appendix A is a computer listing of a preferred software implementation of the present invention operative in conjunction with a plurality of SGS-Thomson STCF 54 chips equipped with a SCOS+ or SCOS++ operating system, commercially available from Personal Cipher Card Corporation, Lakeland, Fla., USA or Fortress U & T Ltd., Beer-Sheva, Israel, the chips being customized using an SCAD development system, commercially available from Fortress U & T Ltd.
  • An entity is considered to have “a credit of X dollars for cash receivables”, also termed herein AMT, or “X$ of CCRs”, if he has been granted the right to accept X dollars in cash.
  • a client of a system which provides services in return for payment is an entity which pays the system and, in return, receives a service.
  • the passengers of a transportation system are the transportation system's clients.
  • a “purse” is used to denote a payment manipulating element.
  • a “client's purse” is a purse belonging to a client which holds a certain amount of value, either cash or virtual value, which the client may use to pay the system.
  • a “system element's purse” is a purse belonging to an element of the system, such as one of elements 20 , 60 , 70 , 80 , etc., which holds a credit for cash receivables, i.e. an entitlement to receive physical cash.
  • ACN Account Number A unique number identifying smart card's account with an issuer. See PAN. ACK Acknowledgment- Confirmation of acceptance of transmission.
  • Application Default Action A data element indicating the action a card should take for certain exceptional conditions.
  • ADF Application Definition File A file that contains data which defines application properties.
  • AED Application Expiration Date A closure date after which application may cease to be valid.
  • AEF Application Elementary File A basic file that contains data which can be used by the SAM/SC.
  • Application Effective Date - Starting Date from which the application may be used.
  • AFL Application File Locator A string divided into fields of typically four bytes, pointing to file and record numbers, containing relevant application information.
  • AID Application Identifier - Identifies the application as described in ISO 7816-5, comprises the RID and the PIX.
  • ISO7816- A set of standards for manufacturing ICCs. Serves as basis Parts 1 + 5 for most other standards.
  • AIP Application Interchange Profile Indicates capabilities of the card.
  • AMD Application Management Data AMT Amount of Transaction - A Binary Coded Decimal, exact to 1/100, in the present example.
  • Subscript DP signifies the amount to be collected by a [AMT xy ] parking meter for parking until the end of the regulated parking day, e.g., parking may be free from 7:00 PM.
  • XY signifies AMT transferred from X to Y.
  • an Alphanumeric A data sequence which may represent letters, punctuation marks, and numbers (characters). ASCII is for alphanumerics.
  • ans Alphanumeric Special- APC Automatic Passenger Counting system an electronic system which audits the number of passengers in an autobus.
  • APDU Application Protocol Data Unit A command response, data template or data structure
  • AR Account Receivables an archive of completed transactions, preferably with PK proof, typically with identification and time of transaction.
  • the account receivable archive is external to the SAM; as opposed to the CAR, the credit for accounts receivable, which may only be a PK protected re Archive File (Cryptographically Linked) - A working file which is composed of data fields which are linked together in a fashion such that removal of or alteration of data in any Archive File field can be detected.
  • Asymmetric (PKC) Public Key Cryposystems where all subscribers have unique (not shared) secret keys and unique, universally available public identifiers.
  • ARQC Authorization Request Cryptogram - A response sent by the card, indicating a request to go on-line.
  • ATC Application Transaction Counter The transaction numerator which is incremented at every transaction performed by a SAM/SC.
  • ATM Automated Teller Machine A remote banking machine for distributing money and performing other functions generally performed by a human bank teller. (Banking)
  • ATM Automatic Ticketing Machine see TIM ATR Answer to Reset -
  • Auth. Authentication - proving the validity and acceptance of liability to a string of data (certificate), usually to prove identity of a device, either as a preamble to a transaction or as a control to access.
  • C-APDU Command APDU- for T 0 timing - Command + Data sent from an application to the TTL.
  • CAR Credit for Accounts Receivables The mechanism, (very similar to the CCR), meant to control account value (generally electronic) received and transferred by SAM/SCs. Generally, such value will be handled by a central clearance organization (see acquirer). When electronic value is accepted by a SAM/SC, e.g., a vending machine, a TIM, a parking meter, following rules established by the SC issuer, the SAM/SC's CAR is decremented. Means and methodology in this document with relation to transfers of CCRs may be applicable with CARs.
  • a cash advance public key smart card parking transaction is demonstrated; assuming that all financial service and handling charges between a parking meter (PM) operator, an ECASH purse operator and credit card applications are reconciled on a monthly basis, and that these service charges are not relevant to the transactions involved; and assuming that the client who is paying for parking services (the cardholder) has two applications, a public key credit smart card, and a public key ECASH smart card, either on the same smart card or on two separate public key SAM/SCs, preferably both able to authenticate to the PM that they have the same owner; and assuming here, entitlement to load ECASH into a client's purse (tantamount to printing electronic money) is granted to a secured PM, where the source of the payment is a client's credit card giving a “cash advance”, and assuming that the PM operator's strategy for risk assessment, in addition or in place of the EMV strategy for off-line assessment of risk collections, is to allow a cash advance only for the exact amount necessary to pay for parking for a full
  • the warden's terminal When servicing the PM, the warden's terminal would unload the PM's CRs into its own CR purse, decrement the warden's CCRs by $40 to replenish the PM's CCR back to the PM's maximum CCR entitlement; and then unload the $16 of ECASH from the PM's AR purse, into its own AR purse, decrementing the warden's CAR and incrementing the PM's CAR by $16, to return the CAR to its maximum entitlement.
  • the warden's “dunning” terminal archives and transmits proof of ARs collected (parking tariff) to the operator's accounting system and ECASH reloaded in client purses.
  • Cashback- the ability to cancel a transaction and return value.
  • an option can be allowed to cancel the last transaction in a client's card, if and only if the request is for cancelling the very last transaction.
  • Cashback Purse- In the driver traveller scheme, a preferred feature is cancelling of a hardcopy ticket purchased with $CASH.
  • the specification preferably allows the driver the option of returning full or part fare in $CASH to a traveller if a claim is made in reasonable time, e.g. a traveller who took a bus in the wrong direction and realized his mistake in the first one-half hour of the trip.
  • the OPM also has a Cashback Purse which is incremented with Cashback Credit each instance that the driver prints a cashback receipt on the TIM.
  • a Cashback Purse which is incremented with Cashback Credit each instance that the driver prints a cashback receipt on the TIM.
  • an entitled acceptor of cashback credit e.g. a depot treasurer
  • the driver reconciles $CASH and CCRs with an entitled acceptor of cashback credit, e.g. a depot treasurer
  • he deposits cashback credits and $CASH with the depot treasurer and receives CCRs equal to the sum of cashback and $CASH.
  • Such an entitled cashback credit acceptor is enabled to decrement his CCR purse with the cashback credits received from the driver.
  • the cashback purse preferably contains a cumulative register which sums all cashbacks from a start date, as a measure of merit for a driver.
  • CCCR Cheque for Credit for Cash Receivables A cheque sent over an open channel to replenish CCRs without handshake, as opposed to a purse to purse CCR transaction, wherein two SAM/SCs communicate in a handshaking protocol.
  • the CCCR can only be deposited once, and only by the recipient whose PAN and ATC numbers appeared in the RCCCR. See CCR and RCCCR.
  • CCR Credit for $CASH Receivables the credit limiting license granted to a system employee or device to collect $CASH or $CASH equivalent (e.g. a “cash advance from a credit card”), from consumers. This credit is held in a purse in a SAM/SC, protected by strong PKC.
  • CCR can also be incremented with receipt of a CCCR.
  • the (payer) sender of a CCCR writes the cheque, his CCR is reduced by the equivalent amount.
  • CCRs are only legal tender between system employees or agents, and can only be transferred between SSCs.
  • a vital link in the CCR mechanism is the use of a REC (an electronic $CASH receipt from a bank or similar repository), wherein the bank signs a receipt for the $CASH deposited.
  • this receipt can be converted to CCRs, only by an entitled entity, e.g., an accountant who can reconcile such RECs with accounts received from the banks and hardcopy receipts sent via internal mail.
  • CCPS Chip Card Payment Service CD Committee Draft CDOL Card Risk Management Data Object List A list of data objects used by the card to perform a transaction. Cert. Certified - Authorized by an agreed upon Trusted Authority (whose ID is recorded in non-volatile memory in a SAM/SC) Certificate- A cryptogram signed by an issuer or a sub-issuer of a system whose public key is known and recognized by the authenticator, thereby proving responsibility and origin of the hashed contents of the cryptogram (generally the hashed data relating to the validity of membership of a cardholder in a community, e.g.
  • Cheque- Here used as an vehicle for a blind secured transaction sent over an open channel, without third party regulated clearance procedure. Cheques (CCCRs) transfer CCRs to recipients who have designated a request, see RCCCRs. See also RECeipts and requests for receipts (RRs). CID Cryptogram Information Data - Indicating the type of cryptogram (AAC, ARQC, AAR or TC) returned by the card.
  • CLA Class Byte of the Command Message- First byte of a command conveying attributes of command processing CLK The signal used to drive and synchronize the workings of the CPU (or the state machine in a secured memory chip) in an ICC.
  • Clone- A device which behaves like another device, under all relevant conditions. cn Compressed Numeric - Same as BCD. Cons. Consecutive- following immediately, e.g., 369 follows 368 consecutively.
  • CPLC Card Production Life Cycle The period of relevance of a card's life, from embedding of module or Issuance to end of card validity.
  • credit receivables contain credits which the meter collected for a purse operator, wherein the parking meter serves as a surrogate for the purse operator, entitling the meter to reload ECASH into clients' PK smart card purses.
  • CSC Consumer's Smart Card - In a system wherein physical cash ($CASH) and/or ECASH flow is protected using CCRs and/or CARs; a CSC is a smart card held by a consumer whose card can be loaded with electronic cash from an SSC (system smart card). A CSC cannot increment CCRs in an SSC. When a consumer gives an SSC holder, AMT of $CASH to an SSC holder for reloading cash to his CSC electronic cash purse, the SSC's CCR purse is decremented by AMT, as the CSC's electronic purse is incremented by AMT.
  • the SSC's CCR is decremented, while the SSC executes a purchase from the TIM, e.g., the driver receives $10 from a passenger; keys in the “purchase” on the terminal, thereby decrementing his CCR by $10, to make a purchase from the terminal, which prints the $10 travel voucher; the terminal archives the purchase in a file for further reconciliation by accounting but does not increment a CCR.
  • the SSC's CCR is decremented, while the SSC executes the purchase from the TIM, whence the TIM opens a secured file in the CSC e.g., the driver receives $20 from a passenger; keys in the “purchase” of a day pass (or a multiple local 6 ticket or a special fare excursion . . .) on the terminal, thereby decrementing his CCR by $20, to make a purchase from the terminal, which prints the $20 travel voucher; the terminal archives the purchase in a file for further reconciliation by accounting.
  • CSN Card's Sequence Number - A counter managed by the card, which is increased with each transaction and authentication. See ATC. Cum.
  • CVM Cardholder Verification Method A data object read from the card, indicating the procedure used to verify the card holder (PIN).
  • CVR Card Verification Results A data object, managed by the terminal, indicating the result of the authentication check of card holder.
  • DAD Destination node Address- T 1 transport layer.
  • DDF Directory Definition File A file that contains entries for other DDFs and ADFs in the current directory.
  • D-H Diffie-Hellman- public key method for secret key exchange.
  • D N Data Block N DSA DSS
  • DSS Digital Signature Method
  • DTA EasyEntry Visa spec - file for all MagStripe Info in every Visa ICC application, to provide a minimum of compliance to old applications.
  • ECASH Electronic value commensurate to a national currency, kept in a consumer's ICC purse, and in some payment schemes, in a vending device.
  • EDC Error Detection Code- A system of adding redundant code to blocks of message, wherein it is possible to determine (but not necessarily detect) that an error of up to a predetermined size has occurred within the block.
  • EEPROM Electronically Erasable Programmable Read Only Memory - Non volatile memory which can be written to/erased in small increments.
  • EMV Work group consisting of Europay, MasterCard and Visa formed to standardize smart card payment systems, based on ISO 7816 specs, RSA, SHA1, triple DES, etc. Entitlement to accept $CASH, ECASH.
  • the CCRs and the CARs are the vehicles which put working limits on the entitlement of devices, agents, or employees in a payment system to accept physical cash or electronic value.
  • Entitlement- The procedure allowing an issuer or a subissuer the proper priority to access applications -no access, read only, write only and read and write. In a payment scheme, additional entitlements may be appended; e.g., enabling the acceptance of receipts, cheques, etc.
  • these tickets reside in secured purses within a PKC Smart. Card, adjunct to a control file which regulates usage.
  • FCP File Control Parameters- A template used by the EMV to control file parameters, can be part of the FCI.
  • Firewall - a virtual barricade to prevent illicit access to computer systems, typically based on sound authentication methodology.
  • FMD File Management Data A template used by the EMV to control file parameters, can be part of the FCI.
  • Floor Limit an EMV value variable, above which a terminal has the option to transfer the negotiation process to the On-Line host Free Access Purse- A client purse for executing accelerated preferably small payments.
  • a purse that allows a terminal free access is designed for those payments where the SC holder recognizes the terminal (a transportation ticketing device, a parking meter), where he has reasonable confidence that the terminal is operated by a responsible party, and where he can assume that he can immediately ascertain what transactions the terminal has executed, and that he will have sufficient proof in his history file, to rectify any aberrations, e.g., when a traveller inserts his SC in a TIM, the CAR purse to purse protocol will not include the TIMs proving to the SC that the TIM belongs to the bus company and is entitled to collect ECASH; however the SC does prove to the TIM that it has decremented its purse by the AMT demanded by the TIM, after having archived the transaction in the SC's history file.
  • Frozen Protocol procedures which may be followed assuming the inviolability of SAM/SC modules and terminal procedures.
  • GPO GET PROCESSING OPTIONS An EMV command that initiates a transaction by sending processing options to the smart card. In return, if the smart card approves the processing options, it sends the AIP and the AFL.
  • Hash - a nonsecret one-way transformation of data, usually converting a large string to a much smaller string - usually prior to signing the smaller string - to prove authenticity of a large string - see Message and Signature. See SHA1. hex.
  • IAC Issuer Action Code A set of i under defined action lists, indicating the behavior of the card, in different situations.
  • I-Block Information Block- in the T 1 transportation layer, the command + data set which is transmitted from the TTL to a SAM/SC.
  • IC Integrated Circuit A microelectronic device on which there are a multiplicity of transistors, resistors, capacitors, etc. usually to manipulate digital data.
  • ICC Integrated Circuit Card a smart card with an embedded secure CPU module, preferably with PKC protection.
  • IEC International Electrotechnical Commission - one of several standardization agencies defining ICC device specs, working with ISO.
  • IFD Interface Device- Generally an ICC reader.
  • IFS Information Field Size- See T 1
  • IFSC Information Field Size for the ICC- See T 1.
  • IFSD Information Field Size for the Terminal- See T 1.
  • IFSI Information Field Size Integer INF Information Field INS Instruction Byte of the Command Message - According to ISO 7816 structure, typically.
  • ISO International Organization for Standardization issuers of internationally accepted technical standards - see Normative References - ISO xx (•) ISO Format Function 9796 on xx bytes of text (specified in parenthesis) - a data structure for electronic signatures to protect message/document integrity.
  • Issuer - Card Issuer or Card Issuer's Agent Journal Printer An internal device which prints a record of every transaction, e.g., on a continuous tape.
  • K M Master Key A shared secret key in a DES system.
  • K S Session Key- A (DES) Key which is generated for, and used only once, securely exchanged for use in accelerated transmission of data between two implicitly trusting communicants.
  • L D Length of the Plaintext Data in the Command Data Field- a one byte variable defining the length (in bytes) of plaintext data.
  • MIC Message Integrity Check MIN(I) A variable time increment in a service tariff table, e.g., in a parking meter tariff table in a very busy street, the zero'th time increment might be 15 minutes, (at a lower PM_INC(0) tariff of $.50), and the 3rd time increment might be 60 minutes and call for a tariff, (PM_INC(3), of $10. MIPS Million (Assembly Language) Instructions Per Second- a commonly used measure of computational performance.
  • n Numeric - A data string of “countable” values on which computations can be executed in integer mode only.
  • N/A Not Applicable NAD Node Address- In T 1 transport level, the addresses of the source and destination.
  • NAK Not Acknowledged- A signal transmitted by a receiver denoting inability to correctly receive a message.
  • No. Number - A mathematical definition of a total of finite items, which can be used directly in computationS. O Optional One way function.
  • Off-Line Terminal/Transactions - Instances where negotiations and risk management are handled by a remote terminal. Most PKC applications are executed Off-Line. An off-line terminal may have a dial-up option for updating and data transfer. Using public key protocols, risk management can be handled successfully off-line, wherein transactions which do not meet acceptable off-line criteria, will either be refused, or if the on-line terminal option is available, the terminal can go on-line to central clearance.
  • On-Line Terminal/Transactions - Transactions, preferably asymmetric, where the remote terminal serves as an intermediary to a central Host which negotiates directly with the external device.
  • all ATM transactions value transfer to a user
  • On-Line In PKC applications, fewer transactions must be executed On-Line OPM Operator's Personal Module.
  • An enclosed device which contains protected transaction memory and a SAM/SC to protect transactions and gain access. Acts as a Smart Card with a large external memory.
  • P1 Parameter 1 In ISO 7816 standard command, the first number which appears after the command.
  • P2 Parameter 2 In ISO 7816 standard command, the second number which appears after the command.
  • P3 Parameter 3 In the EMV extension, the third number which appears after the command (used to specify length of data).
  • Parameter Printer A printer which accepts commands (e.g., for following $45) for complete lines of data with additional parameters, e.g., “Time elapsed from start of journey - 30 minutes , kilometers 34 .” - 30 and 34 are parameters; e.g., the complete command would be 45, 30, 34.
  • Personalization A procedure followed by an issuer wherein a smart card or SAM/SC is assigned to a subscriber with unique identification, and file structures are programmed into the EEPROM with access priorities and keys.
  • PAN Primary Account Number the EMV identifier of an account.
  • P CA Certification Authority's Public Key P CA Certification Authority's Public Key.
  • PCB Protocol Control Byte PDOL Processing Data Object List - list of data objects that a system uses to initiate a transaction.
  • PIN Personal Identification Number A unique number, preferably known only to the owner of a SAM/SC or smart card or an application, wherein, assuming the integrity of the keyboard used to authenticate the rightful user of said SAM/SC, and which can be used to activate the SAM/SC.
  • PIX Proprietary Application Identifier Extension In a proprietary approved EMV application, an extension to the AID giving parameters necessary to regulate the application.
  • PKC public Key Cryptography - One of asymmetric message systems using integrity methods with public-private key pairs, e.g., RSA, D-H, DSS, El Gamal, Schnorr, Fiat Shamir, etc.
  • PM Parking Meter (See OPM - former alias) A device used by public authorities to regulate parking times commensurate to the AMT which a SC grants to the meter.
  • PM_INC(I) The price of a time increment in a service tariff table, e.g. the tariff for parking in a parking space reserved for load/unload for the zero'th 15 minute increment might be $.10, whereas in the tenth thirty minute increment might be $40.
  • POS Point of Service A terminal, capable of performing a transaction on a smart card, in exchange for a service.
  • Proprietary Encryption Method Usually a symmetric encryption method wherein the user assumes added security because of the adversary's ignorance of the method. Generally considered dangerous in an open system.
  • PSA Payment System Application PSE Payment System Environment A smart card based payment system environment, including POS, terminals, etc. PT Command to Perform Transaction followed by Terminal Certificate on Data (SCOS++)
  • PTICKET Printed Ticket A paper travel voucher purchased with AMT of $CASH issued by a TIM. The driver's OPM's CCR is reduced by AMT as it purchases the voucher from the TIM (or the parametric printer's SAM/SC).
  • a secured purse consists of public key protected files encapsuled within a secured silicon architecture.
  • An SCOS++ purse can only be loaded with value by another purse, wherein the value held in the donor purse is decremented, and the value held in the recipient's purse is incremented.
  • a purse with proper entitlement can be loaded by a valid donor purse using one or more of the three mechanisms; as on-line purse to purse transaction; a cheque for credit for value ($CASH or ECASH) receivables possibly sent to a mailbox over an open, interceptable channel; a receipt signed by a system recognized repository (a bank). Entitlement is subject to system strategy, e.g., in a preferred strategy only an accountant can convert RRs to CCRs in his SAM; similarly only Depot Managers and Treasurers and Cashflow Managers are entitled to request and receive CCCRs. Purse to purse transactions- Purse to purse transactions are performed generally between two $CASH purses in SAMs, linked through what may be a dumb terminal.
  • RAM Random Access Memory- Memory which be specifically addressed, then written to (changed) or read from with relatively fast access time (10 to 150 ns).
  • R-Block Receive Ready Block- A T 1 signal.
  • RCCCR Request for a Cheque for Credit for Cash Receivables the token generated by a potential receiver of a CCCR's SAM/SC to enable the SAM/SC to accept a single cheque from a designated source, assuring the writer of the CCCR that the cheque can and will be used to credit the receiver's CCR once, and only once.
  • Remote (Terminal) A terminal device which does not normally communicate with a central host computer.
  • RF Radio Frequency Communication An option for allowing dispersed not otherwise communicating devices, to go on-line to a central node for reconciliation, downloading CRLs, for uploading transactions, etc.
  • RFU Reserved for Future Use RID Registered Application Provider Identifier- 5 bytes which uniquely identify an application provider.
  • RN or RND Random Number unpredictable number (sequence of 1 and 0 bits), physically generated and computationally randomized.
  • RNG Random Number Generator preferably a Real Random Number Generator which generates a completely unpredictable number under all conditions.
  • ROM Read Only Memory- non-volatile immutable memory that can be read from, but not written to.
  • RR XY Request for Receipt. X requests an electronic receipt from Y. This assumes that X has the authority to convert a receipt into an increment to X's CCR or CAR. This function is typically used by accountants who reconcile receipts with accounting statistics and transfer CCRs to a company treasurer whose duty is to send CCCRs to dispersed $CASH collectors.
  • This signed request for receipt typically includes proof of X's belonging to the system, and data issued by X's SAM/SC which will enable to convert said receipt once, and only once into CCR or CAR (CxR).
  • RSA Rivest-Shalnir-Adelman Method most flexible and de facto standard PKC - for electronic en/decryption, key exchange and document signature.
  • RS485 See Standard Serial Communication.
  • RTC Real Time Clock A vital component in a secured system to attest to the time that a transaction is performed.
  • R-TPDU Response TPDU- Response received by the terminal transport layer from an ICC.
  • SAD Source Node Address- In T 1, that part of the NAD which indicates the source of a block of data.
  • S-Block Supervisory Block- In T 1, used to send control blocks.
  • Subscript x signifies SC or SAM belonging to x.
  • Secured ICC architecture a monolithic silicon cryptocomputer, essentially characterized to disallow illicitly invasion, with a virtually inviolate internal bus, no test points, hardware to disable running at low speeds (less than 0.5 mhz), insuring a block erase of EEPROM when top metal layer is scratched, etc.
  • SFI Short File Identifier- A unique 5 bit number used to access an SF within the same application or directory.
  • this key is generated by the card, within the card, and is in a secured section of the ESPROM, accessed only by the proprletary library.
  • Signature - Computational transformation on a message using a signer's private key proving document integrity and liability of signer to unalterable contents.
  • EMV authorize the RSA method for signatures.
  • Usually part of a signature is composed of a hash on large quantities of data, to enable a single signature to prove integrity of more than one block of data. See SHA1, DSA, and RSA.
  • SHA1 NIST's Secured Hash Method a very strong one way function to transform a long data string into a 160 binary bit sequence for signing with the DSA or other signature methods. (Second rendition, first was designated SHA).
  • Standard Serial Communication - B0485 - A multidrop noise resistant network standard, often used for in situ automotive peripheral communication.
  • Static Data Authentication - Off-line asymmetric PKC authentication of certificates as opposed to dynamic data authentication, wherein both prove their identities and can prove integrity of messages.
  • SSC System Smart Card In a system wherein $CASH flow is protected using CCRs, a SSC is a card or SAM held by employees of the system which are entitled to accept cash in return for CCRs.
  • T 0
  • T 1
  • Tachometer/graph- a device measures and charts the speed of a vehicle as a function of time.
  • TAL Terminal Application Layer- an application program running on the terminal using the TTL to communicate with the ICC.
  • TCK Check Character TCLK X A time measuring device used to measure the incrementing period of X's parking. (measured from time X inserts SC in PM).
  • TDOL Transaction Certification Data Object List Tear Protection A backup firmware methodology to prevent or compensate for illicit or unintentional interruption of a transaction procedure.
  • TIM Ticket Issuing Machine A cryptocomputer regulated device that controls money collection, ticket issuing and collection, controls access to vehicle, and collects transaction and automotive data relevant to a payment collection operation.
  • Time Stamp That part of a certificate which testifies to the time of signature on a string of data.
  • TPDU Transport Protocol Data Unit The data unit sent by the ICC to the terminal to regulate communication.
  • TPMP Temporary Purse in Parking Meter- A purse which receives the client's parking deposit and dispenses increments to the account's receivable while client's car is parked; holding the client's unspent ECASH; If the “unspent” surplus is returned to the client's smart card when the client retrieves his vehicle; the unspent portion or part therof increments (is returned to) the client's ECASH purse, any other remainder increments the accounts receivable and decrements the entitlement contained in the CAR.
  • TSI Transaction Status Information A present assessment of negotiated information.
  • TTL Terminal Transport Layer manages the command/response pair transmission sequence between an ICC and a Terminal. Receives an APDU from the TAL and sends a TPDU to the IC.
  • TVR Terminal Verification Results A bit mask, managed by the terminals containing the status of the card verification process.
  • UDK Unique DEA Key A secret random key, unique to a DES process.
  • Validator In the mass transportation scenario, a Smart Card accepting device to collect value from a multi-ride ticket purse, and for allowing cardholders to read last transactions. var.
  • Variable - A data string whose value can be changed by authorized members of a defined cryptographic community. Verification - Generally the check performed by a cryptocomputer, to ascertain the values contained in a signed transaction certificate.
  • V.I.P. VisaNet Integrated Payment Warden An inspector whose duty is to inspect violations and failures in a service system (parking meters), and in those systems which cannot communicate on-line to a central database, to download data and CRLs, and transfer transaction data for central clearance.
  • YDDD Year, Day (‘Y’ Rightmost digit of the year (0-9).
  • ‘D’ Day of the year (1-366))- A two byte hexadecimal representation of date.
  • YYMMDD Year, Month, Day - A three byte hexadecimal representation of a date.
  • FIG. 1 is a simplified block diagram of a payment collection system useful for a transportation network, the system being constructed and operative in accordance with a preferred embodiment of the present invention.
  • the system of FIG. 1 includes a population of travelers 10 and a population of transportation service providers 20 .
  • Each transportation service provider is equipped with an “OPM” or operator's personal module.
  • the OPM includes an electronic purse which stores the transportation service provider's current entitlement to collect physical cash payment from travelers.
  • the electronic purse is preferably public key signature protected.
  • Each transportation service provider also termed herein a “driver”, is operative to perform transactions, each of which includes:
  • a preferred feature of the driver's OPM is that (c) is performed automatically once (b) is initiated by the driver.
  • the population 10 of travelers includes one, some or all of the following types of travelers:
  • a a first type of travelers who interact with the transportation service providers 20 by transferring physical money, also termed herein “$cash”, to the service providers 20 and receiving a paper ticket therefrom in return.
  • the system of FIG. 1 also includes a population of depot treasurers 60 each equipped with an “OPM” or operator's personal module.
  • the OPM includes an electronic purse which stores the depot treasurer's current entitlement to collect physical cash payment from drivers.
  • the electronic purse is preferably public key signature protected.
  • Each depot treasurer is operative to perform transactions, each of which includes:
  • a particular feature of the depot treasurer's OPM is that (c) is performed automatically once (b) is initiated by the depot treasurer.
  • the system of FIG. 1 also preferably includes a population of depot managers 70 which serve as a buffer, each of which is equipped with a smart card or an OPM.
  • the manager's OPM or smart card includes an electronic purse which stores the depot manager's current entitlement to lend physical cash payment collection entitlement to treasurers.
  • the electronic purse is preferably public key signature protected.
  • Each depot manager is operative to perform transactions, each of which includes:
  • a particular feature of the depot manager's OPM or smart card is that (b) is performed automatically once (a) is initiated by the depot treasurer.
  • the OPM of each depot treasurer associated with a depot manager is also operative to perform the above type of transaction, so that a depot treasurer is able to return to his depot manager payment collection entitlement which the manager previously lent to the treasurer.
  • the system of FIG. 1 also includes a population of local banks 80 each equipped with a smart card and an associated computer.
  • the smart card is preferably public key signature protected.
  • Each local bank is operative to perform transactions, each of which includes:
  • step (a) b. electronically signing an electronic document provided and signed by the depot treasurer.
  • the electronic document indicates the sum total of physical cash payment collection entitlements which the depot treasurer dispensed to drivers since he last interacted with the local bank. Except for human error or system malfunction, this sum total is the exact amount of physical money transferred in step (a).
  • the electronic document also includes a request for a receipt (RR) and a request for a cheque for credit for cash receivables (RCCCR).
  • RR receipt
  • RCCCR cheque for credit for cash receivables
  • the local bank's signature includes an indication of the amount of physical money received. It is in the interest of the depot treasurer and the local bank personnel to communicate in the event that the indication of the amount of physical money received differs from the sum total included in the electronic document, e.g. due to human error on the part of the local bank personnel.
  • the electronic document provided by the depot treasurer 60 and signed by the local bank 80 is transmitted to a central accountant 90 equipped with a security module.
  • the electronic document includes a token which enables only the security module of the central accountant 90 to convert, exactly once, the amount specified in the electronic document, into credit for cash receivables of the same amount.
  • credit for cash receivables refers to entitlement to collect a certain amount of physical cash payment.
  • the central accountant 90 Periodically such as daily, or upon demand, the central accountant 90 prepares and signs an electronic cheque for credit for cash receivables for the amount specified in the electronic document.
  • This cheque termed herein the “accountant-to-manager cheque”
  • the central accountant 90 also prepares, for each of the depots, an electronic cheque.
  • the electronic cheques for the depots also termed herein “depot cheques” or CCCRs (cheques for credit for cash receivables) are transmitted to and signed by the cash flow manager 100 .
  • Each depot cheque typically includes the following:
  • a “cheque”, drawn to a certain amount, means an entitlement granted to the beneficiary of the cheque to collect exactly that amount of physical cash payment.
  • This entitlement also termed herein “credit for cash receivables”, is transferable exactly once from the donor of the cheque to the recipient thereof.
  • the cash flow manager After having received the unsigned depot cheques, the cash flow manager signs these cheques electronically, and transmits them to the appropriate depots. Typically, the cheques are sent via an electronic mailbox 110 to either the depot manager or the depot treasurer.
  • Each of the entities in FIG. 1 has a security application module (SAM).
  • SAMs are operative to receive cheques, typically the SAMs of each of the following entities: Depot manager 70 , depot treasurer 60 , cash flow manager 100 .
  • Each SAM is operative to prevent the entity with which it is associated from converting a cheque to credit for cash receivables, more than once. This is done by generating a sequence of non-repeating cheque identification numbers, e.g. by means of a counter, and storing these numbers in its public key secured non-volatile memory.
  • the non-repeating cheque identification numbers prevent repeated use of a single cheque, thereby ensuring entitlement, exactly once, to the exact amount on the cheque, as described in detail below with reference to FIGS. 4 - 5 .
  • a preferred feature of the present invention is that although the electronic cheques are typically transmitted over open channels and therefore can be copied freely, nonetheless the electronic cheques can only be used (i.e. converted to credit for cash receivables) once and only by their intended beneficiary.
  • This feature is preferably implemented by “freezing” a protocol which ensures only a single use of cheques by only their intended beneficiary such as one of the protocols shown and described herein.
  • the protocol is typically “frozen” within a secured externally immutable non-volatile memory of a SAM which includes a monolithic (i.e. single-chip) public key protected cryptocomputer.
  • the protocol typically includes the following rules:
  • a cheque cannot be received unless it has been requested.
  • Each request includes an index or other unique number, generated by the monolithic public key protected cryptocomputer so as to be different from the identification numbers of all previous requests.
  • the mechanism in the cryptocomputer which generates these indices or other unique numbers is also termed herein an ATC (application transaction counter).
  • a cheque includes the index of the request for that cheque.
  • the cheque reaches its intended recipient signed, and therefore, the intended recipient cannot tamper with the index.
  • the electronic receipts are typically transmitted over open channels and therefore can be copied freely, nonetheless the electronic receipts can be used by the central accountant 90 (i.e. converted to credit for cash receivables) only once.
  • This feature is preferably implemented by “freezing” a protocol which ensures only a single use of receipts.
  • the protocol is typically “frozen” within the central accountant's SAM which includes a monolithic (i.e. single-chip) public key protected cryptocomputer.
  • the protocol typically includes the following rules:
  • a receipt cannot be received unless it has been requested.
  • Each request includes an index or other unique number, generated by the monolithic public key protected cryptocomputer so as to be different from the identification numbers of all previous requests.
  • the mechanism in the cryptocomputer which generates these indices or other unique numbers is also termed herein an ATC (application transaction counter).
  • a receipt includes the index of the request for that receipt.
  • the receipt reaches its intended recipient signed, and therefore, the intended recipient cannot tamper with the index.
  • the cryptocomputer stores a “used” indication in association with the index of that receipt.
  • credit for cash receivables i.e. entitlement to receive physical cash
  • entitlement to receive physical cash is transferred, in normal steady state operation in a cycle, from the central accountant 90 , to the cash flow manager 100 , to the depot treasurer 60 and/or manager 70 , to the drivers 20 .
  • the drivers' entitlement to receive physical cash is reduced to the extent that they receive actual physical cash but is restored by the depot treasurer in return for transferring the physical cash to the depot treasurer 60 .
  • the depot treasurer's now depleted entitlement is eventually restored by the cash flow manager 100 , once the depot treasurer 60 has deposited the physical cash he received from the drivers in the bank 80 and once that physical cash has merited the central accountant with a receipt which in turn merits the cash flow manager to receive renewed entitlement to receive physical cash.
  • Entitlement to receive physical cash is typically injected into the system of FIG. 1 initially and upon occasion, by an external source 120 .
  • an external source 120 Preferably, the interface between the external source 120 and the central accountant 90 is secured by a portion of the protocol of the central accountant's SAM which only accepts cheques which are multi-signed.
  • the uniqueness of the interface is preferably maintained by a portion of the protocols of all SAMs other than the central accountant's which portion rejects input from the external source.
  • each bus is equipped with a ticket issuing machine (TIM) and each operator (driver) is equipped with a portable personal module (OPM).
  • TIM ticket issuing machine
  • OPM portable personal module
  • Each OPM or operator's personal module typically includes a SAM (security application module) which stores the operator's electronic purse, a memory, a CPU and a real time clock.
  • the TIM is operative to load up a traveler's smart card in response to a driver's actuation.
  • the driver actuates the TIM to do this in return for receiving X dollars of physical cash.
  • the OPM records the driver's usage of the TIM by decrementing the driver's entitlement to receive cash by X dollars as the driver actuates loading up of a traveler's smart card by X dollars and incrementing the TIM's electronic purse by the same amount.
  • the TIM is operative to issue a paper ticket in response to a driver's actuation.
  • the driver actuates the TIM to do this in return for receiving the price of the paper ticket from the traveler.
  • the OPM records the driver's usage of the TIM by decrementing the driver's entitlement to receive cash by the price of the paper ticket and incrementing the TIM's electronic purse by the same amount.
  • the TIM is operative to issue multiple or free pass tickets in response to a driver's actuation.
  • the driver actuates the TIM to do this in return for receiving the price of the desired ticket.
  • the OPM records the driver's usage of the TIM by decrementing the driver's entitlement to receive cash by the price of the desired tickets as the driver actuates loading up of a traveler's smart card by the same price and incrementing the TIM's electronic purse by the same amount.
  • the TIM is operative to decrement a traveler's smart card, in response to insertion of the smart card into the TIM.
  • the smart card may be a card issued by the transportation system, or may be an “external” card such as a conventional credit card.
  • the driver inputs into the TIM an indication of the nature and/or price of goods or services which the traveler wishes to purchase.
  • the TIM's electronic purse is incremented by the same amount that the traveler's smart card's electronic purse is decremented.
  • the TIM is operative to decrement a traveler's multiple-ride transportation pass, entitling the traveler to a specific amount of transportation service, such as a specific number of rides, in response to insertion of the pass into the TIM.
  • the driver inputs into the TIM an indication of the nature of transportation services which the traveler wishes to purchase.
  • the TIM's electronic purse is incremented, and the traveler's pass is decremented, by the cost of the service being purchased.
  • the TIM is operative to decrement a traveler's free travel transportation pass, entitling the traveler to an unlimited amount of transportation service, in response to insertion of the pass into the TIM.
  • the TIM's electronic purse is incremented, and the traveler's pass is decremented, by a very small sum such that even if the traveler heavily utilizes his pass, nonetheless the pass's electronic purse will not be decremented totally to zero within the time period for which the pass is valid.
  • FIG. 2 is a simplified flowchart illustration of a method for performing a purse-to-purse transaction between two operator personal modules (OPMs) of FIG. 1 such as between a driver's OPM and a depot treasurer's OPM or such as between a depot treasurer's OPM and a depot manager's OPM.
  • OPMs operator personal modules
  • a purse-to-purse transaction is a transaction between two public-key signature secured electronic purses in which value X is transferred from one of the purses to the other, resulting in an decrement of X dollars to the first purse and an increment of X dollars to the second purse.
  • the transaction illustrated in FIG. 2 takes place between two smart cards or SAMs, SC 1 and SC 2 , and is performed by a terminal having one or more smart card readers.
  • a value designated AMT is transferred from SC 1 to SC 2 .
  • the transaction initiates with a challenge by SC 1 which comprises a random number transmitted to the terminal (step 210 ). If the receiving smart card SC 2 agrees to accept the value being transferred from the donor smart card SC 1 (step 220 ), then precautions are preferably taken to make sure that SC 1 is not double-charged.
  • SC 2 signs and transmits to SC 1 a payment request, also termed herein an “RCCCR” (request for cheque for credit for cash receivables) (steps 230 and 240 ).
  • SC 1 If the donor smart card SC 1 agrees to comply with the payment request, then SC 1 stores the transaction data which appears in the payment request (step 260 ). SC 1 then signs and sends to SC 2 a cheque for credit for cash receivables, typically for the amount requested by SC 2 (step 264 ). SC 2 receives the cheque (step 266 , described in detail below with reference to FIG. 4).
  • FIG. 3 is a simplified flowchart illustration of a method for canceling the purse-to-purse transaction of FIG. 2 if the purse-to-purse transaction failed. e.g. that the “end of session” step in FIG. 2 was not reached or
  • SC 1 is the donor smart card and SC 2 is the intended receiving smart card which does not, in fact, receive any value from SC 1 due to failure of the transaction.
  • the terminal may detect that a transaction failed in step 310 in one, some or all of the following ways:
  • the terminal has programmed time limits for response for each of the steps performed by one or other of the smart cards and if these time limits are exceeded, i.e. if either of the smart cards fails to perform on time, the terminal assumes that the transaction has failed;
  • the terminal has a programmed time limit for the “end of session” step 274 of FIG. 2. If the session does not terminate within this time limit, the terminal assumes the transaction has failed; and/or
  • the terminal is equipped with microswitches which sense if a card has been removed from the terminal while a transaction is in process.
  • FIG. 4 is a simplified flowchart illustration of a preferred method by which a receiving smart card, SC 2 , performs the cheque receiving step 266 of FIG. 2.
  • the embodiment of FIG. 4 is suited for applications in which the cheque for credit for cash receivables (CCCR) is sent without third party clearance.
  • CCCR cash receivables
  • the method of FIG. 4 maintains a binary cheque token within each signed cheque which is maintained as valid until the cheque is honored at which point (step 440 ) the token is invalidated.
  • the cheque is only honored if (step 420 ) the cheque token is still valid.
  • the binary cheque token is also termed herein an ATC (application transaction counter).
  • FIG. 5 is a simplified flowchart illustration of a transaction cycle performed by the various elements of FIG. 1.
  • each local bank 80 receives a deposit slip as described above with reference to FIG. 1.
  • step 480 the bank 80 may send the central accountant 90 clear redundant data which facilitates authentication procedures, including reconciliation procedures, performed by the central accountant.
  • SUM(AMTs) refers to the sum of amounts of all receipts received by the bank from a plurality of depots.
  • the cash flow manager sends an RCCCR (request for accountant-manager cheque) to the central accountant 90 .
  • the cash flow manager 100 also sends instructions regarding how to distribute CCRs to depots. For example, if a slow period is anticipated, the instructions may indicate that relatively little CCR should be distributed to the depots, whereas a relatively large amount of CCR may be distributed during the period that monthly passes are sold to travelers.
  • step 510 the central accountant preferably performs reconciliation activities before sending an unsigned CCCR to the cash flow manager.
  • step 520 the cash flow manager 70 increments his own balance of credit for cash receivables and then sends cheques for credit for cash receivables to all depots, preferably through electronic mailbox 110 .
  • FIG. 5 is slightly different from the embodiment described below which is based on the software listing of Appendix A.
  • FIG. 6 is a simplified block diagram of a payment collection system constructed and operative in accordance with a preferred embodiment of the present invention which is operative to collect value from smart card bearers (clients) and to load electronic money into the clients'smart cards.
  • the value collected from the clients typically includes physical cash ($Cash), and/or cash equivalents such as a cash advance from a credit card.
  • the system of FIG. 6 is characterized in that agents typically provide advance payment to management for entitlements to collect cash, rather than the agents receiving entitlement to collect cash without paying for it, and turning in collected cash to management only after it is received.
  • the management typically benefits from the float, whereas in the embodiment of FIGS. 1 - 5 the service providers who collect the cash from the customers and other intermediaries typically benefit from the float.
  • Each of the following elements is equipped with a SAM: management 550 , operator accountant 560 , the operator treasurer 570 , the bank 580 , the agent 590 , and the client's smart card 600 .
  • the operator treasurer 570 preferably provides the agent 590 , such as the fuel station or lottery kiosk, a cheque for credit for cash receivables whose value preferably exceeds the total amount provided to the bank 580 by the agent 590 in the previous transaction cycle. Typically, the value exceeds the total amount by a predetermined margin which compensates the entities which handle the cash.
  • the agent 590 such as the fuel station or lottery kiosk
  • CCR refers to an additional entitlement to collect cash.
  • the management generates a cheque for credit for cash receivables (CCCR) in response to receiving a request therefor.
  • the embodiment of FIG. 6 is suitable for a wide variety of applications.
  • the population of agents may, for example, comprise any of the following: a population of loading electric meter smart cards, a population of lottery ticket sales points, a population of fuel stations, a population of transportation service providers, and a population of parking meter ticket reloaders.
  • FIGS. 7 - 13 illustrate the operation of an electronic value collection device which is operative to collect payment for services rendered or products provided and is also “multi-application” in that it enables value to be transferred between electronic value storing devices such as electronic purses, or electronic credit or debit accounts.
  • FIG. 7 is a simplified flowchart illustration of a method for unloading electronic money from a client's smart card.
  • the implementation of FIG. 7 is, for example, suitable for an interaction between a client's smart card ( 600 of FIG. 6) and a parking meter in which the parking meter unloads electronic cash from the client's smart card.
  • step 620 the parking meter or other device for unloading electronic money waits for a smart card to be inserted Once the smart card has been detected, the meter checks itself to determine its present credit for accounts receivable. If (step 630 ) its present credit for accounts receivable is lower than a predetermined threshold such as 10% of its maximum entitlement CAR_MAX, then (step 640 ) the meter typically summons a warden, e.g. by means of an RF (radio frequency) signal, if the warden can be summoned by an RF receiver. The meter then continues to step 650 .
  • a predetermined threshold such as 10% of its maximum entitlement CAR_MAX
  • step 660 If the present credit for accounts receivable is not greater than zero, the method terminates (step 660 ), because the meter is not operative until the warden unloads the history of all transactions performed by the meter and restores his credit for accounts receivable, typically to CAR_MAX level.
  • the parking meter preferably records the time of day, the user preferably enters user-identifying information such as his license plate number, the meter displays the balance of electronic cash possessed by the smart card inserted and/or the amount of parking time equivalent thereto.
  • the meter is operative to enable a user to accumulate a small over-draft, corresponding to a brief interval of time, also termed herein a grace period, during which the user can approach an electronic cash sales point and have his smart card, if empty or near empty, reloaded as described above with reference to FIG. 6.
  • a brief interval of time also termed herein a grace period
  • the reloading process may be performed by a conventional AIM (automatic teller machine).
  • the grace period is charged at a higher rate than ordinary parking time.
  • step 680 the meter generates a display prompting the user to indicate a desire to increment his balance of electronic cash. If the user indicates such a desire then (step 700 ) the user is prompted to indicate whether to increment his balance of electronic cash at the parking meter or at a remote location such as a human-operated or electronically operated electronic cash dispensing point.
  • the parking meter increments his electronic cash balance (step 710 ) using any suitable method such as the method described below with reference to FIG. 11.
  • step 720 the parking meter starts a timer which is programmed to indicate a short grace period.
  • the user removes his smart card and approaches an electronic cash dispensing point which dispenses electronic cash, preferably as described herein with reference to FIG. 6.
  • the user then returns to the parking meter and re-inserts his card as described below with reference to FIG. 9.
  • step 680 If (step 680 ) the user indicates that he does not wish to increment his electronic cash balance then the parking meter merely debits the user's electronic cash balance as payment for the parking service which the user is about to avail himself of.
  • step 730 the user is preferably prompted to indicate how much electronic cash value he wishes to be debited by.
  • the parking meter is configured to accept either of the following two user responses:
  • step 750 Charging of that value (step 750 ) is performed as described below in FIGS. 8 A- 8 B, following an initialization step 740 .
  • FIG. 8A is a simplified flowchart illustration of a preferred method for performing the “charge for parking” step 750 of FIG. 7.
  • this electronic cash is preferably stored in a temporary purse (also termed TPMP-temporary parking meter purse) and is preferably only used to increment the parking meter's accounts receivable as parking time is used in actual fact. Any electronic cash remaining in the temporary purse is returned to the driver's electronic cash purse when the driver returns and inserts his smart card into the parking meter, as described herein with reference to FIG. 9.
  • TPMP-temporary parking meter purse also termed TPMP-temporary parking meter purse
  • step 810 the parking meter determines whether the balance of electronic cash left in its temporary purse by the driver is sufficient to completely pay for the next time-interval of parking in a predetermined sequence of parking time-intervals.
  • FIG. 8B is a sample table storing two sequences of parking time-intervals.
  • the parking meter can preferably be programmed to employ either of the two sequences.
  • the first sequence is suitable for busy parking locations in which it is desired to strongly deter drivers from parking for periods longer than a few minutes.
  • the second sequence is suitable for ordinary parking locations in which it is desired to only mildly deter drivers from parking for more than a few hours.
  • the following information is stored: the length of the time interval, and the cost of parking during that time interval.
  • the parking meter decrements the temporary purse accordingly (step 820 ). If the balance of electronic cash is not sufficient to completely pay for the next time interval, the temporary purse is zeroed and the amount of time which the temporary purse if capable of paying for is computed.
  • step 840 the method of FIG. 9 is carried out to process this interrupt. Otherwise, the method continues to step 870 in which the parking meter determines by consulting its timer whether the present time interval has elapsed. If not, the method continues to wait for the driver's return or for the current parking time interval to elapse. If the present time interval has elapsed then (step 880 ) the parking meter determines whether the temporary purse is already empty. If not, the parking meter returns to step 810 and transfers from the temporary purse to its accounts receivable, the amount of value required to pay for the next parking time interval.
  • the parking meter calls the warden using its radio transmitter (step 890 ), preferably archives the transaction (step 900 ) and returns to the beginning of FIG. 7 to await the next driver's smart card.
  • FIG. 9 is a simplified flowchart illustration of a preferred method for performing the “process smart card insertion event” step 850 of FIG. 8A.
  • the method of FIG. 9 preferably includes the following steps:
  • the parking meter compares the inserted smart card's ID number to the ID number of the currently-parking smart card to determine whether the smart card now inserted belongs to the currently parking vehicle or individual. If so, then the parking meter prompts the user to indicate whether or not he is leaving the parking area.
  • FIG. 10 is a simplified flowchart illustration of a preferred method of operation for a warden's SAM (security application module) once the warden has been summoned by the method of FIG. 7 to restore a parking meter's credit for cash receivables and to collect accounts receivable accumulated in the parking mater. by unloading particulars of all completed and suspended transactions.
  • SAM security application module
  • step 1100 the warden connects his OPM (operator personal module), which includes a SAM and a memory, to the parking meter.
  • OPM operator personal module
  • step 1110 all completed and suspended transactions are unloaded into the OPM's memory.
  • step 1120 the difference between the parking meter's maximum entitlement to collect electro c cash in return for services rendered (maximum credit for accounts receivable—CAR_MAX) and between the parking meter's present balance of entitlement is compared to the sum of service transactions carried out by the parking meter since the parking meter was last accessed by a warden.
  • service transactions refers to transactions in which payment is made for services rendered or, in certain applications, for products received.
  • value advance transactions refers to transactions in which value is transferred between electronic value storing devices, such as between a multi-purpose credit card and a single-application electronic purse.
  • step 1130 the current balance is restored to, i.e. incremented to, CAR_MAX level, less the amount of electronic cash presently stored in the parking meter's temporary purse.
  • CAR_OPM The warden's entitlement to collect electronic cash, CAR_OPM, conversely, is decremented by the amount of account collection entitlement which was conferred on the parking meter.
  • step 1120 If the comparison of step 1120 does not yield the expected equality, this is symptomatic of malfunctioning of the parking meter and the parking meter electronics is typically replaced (step 1140 ).
  • step 1150 the warden's OPM then compares the sum of value advance transactions performed by the parking meter since it was last warden-accessed to the difference between the parking meter's maximum credit for cash receivable and between the parking meter's current balance of credit for cash receivable.
  • step 1160 the parking meter's current balance of credit for cash receivable is incremented to a predetermined maximum level. If the two quantities are not equal, the error is archived (step 1170 ). The method then returns to step 610 of FIG. 7.
  • FIG. 11 is a simplified flowchart illustration of a preferred method for incrementing the electronic cash balance of a user's card.
  • the method of FIG. 11 preferably includes the following steps:
  • Step 1200 if the parking meter's credit for cash receivables has dropped below a predetermined threshold quantity, then (step 1210 ) the warden is summoned to access the parking meter, to collect the credit for cash receivables and subsequently restore the parking meter's credit for cash receivables to a predetermined maximum value.
  • Step 1220 If the parking meter's entitlement to collect electronic cash is no longer positive, the transaction is refused (step 1224 ) and the method returns to step 610 in FIG. 7. If the parking meter's entitlement is positive,
  • Step 1240 the parking meter accepts electronic value equivalent, in the illustrated embodiment, to a full day's parking.
  • electronic value equivalents such as a user selected amount of electronic value, may be accepted.
  • Step 1250 Typically, at least one aspect of the transaction is investigated such as the legitimacy of the user's signature as received by the parking meter, or the credit status of the user. If the investigated aspect/s of the transaction are not approved, the method returns to step 610 of FIG. 7. If the investigated aspect/s of the transaction are approved, the parking meter accepts the amount of payment provided by the user, lowers its own credit for cash receivables by the same amount, and archives a record of the transaction (step 1270 ). The method then returns to step 740 of FIG. 7.
  • FIG. 12 is a pictorial diagram illustrating the flow of electronic value between a user's smart card/s 1300 , a parking meter's SAM 1310 and a parking warden's OPM 1320 .
  • a minus sign associated with a vertical arrow head adjacent a particular electronic value holding device indicates that that device is decremented by a particular electronic value quantity and the electronic value holding device at the base of the same vertical arrow is incremented by the same amount.
  • a plus sign associated with a vertical arrow head adjacent a particular electronic value holding device indicates that that device is incremented by a particular electronic value quantity and the electronic value holding device at the base of the same vertical arrow is decremented by the same amount.
  • the credit card application 1324 and electronic cash application 1328 may reside on a single smart card or on different smart cards which typically are owned by a single owner.
  • Horizontal arrows whose head is associated with a minus sign indicate that, concurrently with the transaction indicated by the vertical arrow which intersects the horizontal arrow's base, the electronic value holding device associated with the horizontal arrow's head is decremented. Conversely, horizontal arrows whose head is associated with a plus sign indicate that, concurrently with the transaction indicated by the vertical arrow which intersects the horizontal arrow's base, the electronic value holding device associated with the horizontal arrow's head is incremented.
  • Electronic counters can be regarded as residing at the bases of the horizontal arrows in order to count electronic value passing through the vertical arrow intersecting with each horizontal arrow base, thereby to determine the quantity of electronic value by which the device at the horizontal arrow's head should be incremented or decremented.
  • FIG. 13 is a pictorial diagram illustrating a preferred flow of electronic value between a parking warden's OPM 1320 , a parking meter operator 1330 , and a purse operator 1340 .
  • the significance of horizontal arrows and vertical arrows, plus and minus signs are as described above with reference to FIG. 12.
  • the warden need not be a human operating a SAM who is summoned by means of an RF transmitter.
  • the transactions described herein may be performed by a central electronic warden using any suitable means of communication such as RF communication.
  • a preferred feature of the present invention is that each of the methods and devices of FIGS. 1 - 13 are embedded in silicon as externally immutable protocol in public-key signature protected non-volatile memory.
  • Conventional secured silicon architectures include the following integrated circuits: Motorola SC29, Motorola SC49 and SGS-Thomson CF54.
  • a preferred method for embedding the methods and devices of FIGS. 1 - 13 in silicon as externally immutable protocol in public-key signature protected non-volatile memory is to use the SCAD developing system, marketed by Fortress U & T. Ltd., Beer Sheva, Israel, in conjunction with one of the above-mentioned integrated circuits in which is programmed the SCOS++ operating system.
  • a preferred method for manufacturing a safe payment collection system constructed and operative in accordance with a preferred embodiment of the present invention is based on Appendix A.
  • Appendix A contains source code listing and specifications for MS Visual Basic form object ‘PRFM_TRN.FRM’ useful for the Cashflow Terminal implementation.
  • the correct address of the ‘BestCRYPT 4 PC’ peripheral card is set, and smart card acceptors are connected to it. See FIG. 14 for a general view of ‘BestCRYPT 4 PC’, commercially available from Fortress.
  • SMARTCARD 1 - 4 are the Smart-card reader connectors. Reader A should be attached to SMARTCARD 1 and reader B to SMARTCARD 2 . Wires should point away from the ‘BestCRYPT 4 PC’ card, i.e., red wire on smart card reader cable, should be placed opposite to the battery (BAT).
  • J 5 -J 7 are the ,Address jumpers. All jumpers must be present to set an address.
  • Each jumper can be positioned on an upper (‘0’) or lower (‘1’) position.
  • the ‘BestCRYPT 4 PC’ card contains a SAM (Security Application Module). The location of the SAM is shown on the view of ‘BestCRYPT 4 PC’ card of FIG. 14. The SAM is an important part of the system and its removal or modification may cause a system failure.
  • SAM Security Application Module
  • the installation directory may be modified if desired by the installer.
  • TRANSACTOR.EXE is run under Microsoft Windows version 3.11 or later by double clicking ‘TRANSACTOR.EXE’ in the Microsoft Windows File Manager.
  • the system users are defined, i.e. the various system smart-cards are assigned their definitions. This is performed using the SCAD Application Developer modules.
  • the SCAD Application Engine is used for creating the application definitions, and the SCAD Issuing Station enables the system manager to issue the smart-cards for the system, as described in FIG. 16.
  • the smart-card is issued, it is a secured information environment subject to the application authorization and restriction, modified only if reissued by the system manager.
  • the system is initialized by entering an initial Cash for Credit Receivables amount, CCR, to the central accountant purse balance. This process can only be executed in the SCAD File Management work station by the system owner. Without this initialization, no CCR type credits exist within the system.
  • CCR Cash for Credit Receivables amount
  • a message is sent containing success or failure information and current purse status details (balance) Any RR, RCCCR, Bank approval, or CCCR dispatched to the terminal can be viewed by entering the appropriate folder in the main transaction window, as shown in FIG. 15.
  • RCCCR bank receipt To approve a treasurer's “deposit slip” the bank teller's smart-card-must be inserted in reader A, after selecting the proper RR and RCCCR in the RR folder. The RR and RCCCR selected will be signed together and dispatched. The CCR amount sent with the approval is the amount entered in the amount textbox.
  • Accountant's converting deposit to CCRs Accountant's card in A is credited with CCRs of all valid and dispatched bank approved RCCCRs (receipts). The card in A will be credited only if it is the central accountant card's and only with approvals not obsolete and not deposited previously. All deposited approvals are moved to the accountant's terminal for RCCCR dispatching to the cashflow manager.
  • Send Cheque (CCCR): To generate a CCCR, an RCCCR must first be selected from the RCCCR folder to be used as the destination for the CCCR. The C( of the cheque sender (the donor) in reader A is charged with the amount specified in the amount textbox, set by the sender of the cheque, and the cheque is dispatched.
  • CCCR Deposit Cheque
  • the software components of the present invention may, if desired, be implemented in protected externally immutable ROM (read-only memory) form.
  • the software components may, generally, be implemented in hardware, if desired, using conventional techniques.

Abstract

This invention discloses a system for safe collection of payment in return for goods, values or services, the system including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a purse control unit operative to prevent the purse, off-line, from exceeding the credit for value receivable which it has been granted.
A method for safe collection of payment in return for goods, values or services, is also disclosed.

Description

    FIELD OF THE INVENTION
  • The present invention relates to apparatus and methods for computerized collection of payment. [0001]
  • BACKGROUND OF THE INVENTION
  • Conventional systems for computerized collection of payment are described in: [0002]
  • Published PCT Application WO 96/0952 (PCT US95/12164) to Brun and Advanced Retail Systems, Ltd. [0003]
  • Schneier, B. [0004] Applied Cryptography, Second Edition, John Wiley & Sons, New York, 1996, pages 139-146.
  • “Integrated circuit card specifications for payment systems”, [0005] Version 3, Jun. 30, 1996, published and distributed by EMV (Europay MasterCard Visa).
  • The disclosures of all publications mentioned in the specification, of the publications cited by these publications and of the standards and specifications mentioned by these publications are hereby incorporated by reference. [0006]
  • SUMMARY OF THE INVENTION
  • The present invention seeks to provide improved apparatus and methods for computerized control of payment collection. [0007]
  • There is thus provided, in accordance with a preferred embodiment of the present invention, a system for safe collection of payment in return for goods, values or services, the system including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a purse control unit operative to prevent the purse, off-line, from exceeding the credit for value receivable which it has been granted. [0008]
  • Further in accordance with a preferred embodiment of the present invention, each of the purses includes a SAM (security application module). [0009]
  • Still further in accordance with a preferred embodiment of the present invention, each purse monitor is public-key protected. [0010]
  • Additionally in accordance with a preferred embodiment of the present invention, each purse control unit is public-key protected. [0011]
  • There is also provided, in accordance with another preferred embodiment of the present invention, a system for safe collection of payment in return for goods, values or services, the system including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including a purse monitor operative to sign and authenticate a time-stamped transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a purse control unit operative to prevent the purse, off-line, from extending a credit for value receivable which it has been granted over more than a predetermined period of time. [0012]
  • Further in accordance with a preferred embodiment of the present invention, the purse control unit operates off-line. [0013]
  • Also provided, in accordance with another preferred embodiment of the present invention, is a public-key protected system for safe collection of payment in return for goods, values or services, the system including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing, in public key protected form, an amount of credit for value receivable granted to the individual system element, each purse including a public-key protected purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a public-key protected purse control unit operative to prevent the purse, off-line, from exceeding the credit for value receivable which it has been granted. [0014]
  • Also provided, in accordance with another preferred embodiment of the present invention, system for safe collection of payment in return for goods, values or services, the system including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a purse control unit operative to prevent the purse from exceeding the credit for value receivable which it has been granted, wherein at least one first purse from among the multiplicity of purses includes a credit granting unit operative to grant an amount of credit for value receivable granted to at least one second purse from among the multiplicity of purses only in response to activation by a predetermined plurality of system directors. [0015]
  • Also provided, in accordance with still another preferred embodiment of the present invention, is a system for safe collection of payment in return for at least one of goods, values and services, the system including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a purse control unit operative to prevent the purse from exceeding the credit for value receivable which it has been granted, wherein at least one first purse from among the multiplicity of purses includes a credit granting unit operative to grant an amount of credit for value receivable granted to at least one second purse from among the multiplicity of purses only in response to activation by at least one system director and operative to record information regarding the activation including the identity of the at least one system director. [0016]
  • Further provided, in accordance with still another preferred embodiment of the present invention, is apparatus for transmitting electronic cheques over open channels, each cheque having an intended beneficiary, the apparatus including a cheque-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a cheque having an intended beneficiary, a cheque-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a cheque, and a set of rules frozen within the first and second memories which allows a cheque issued by the cheque sending security access module to be used by the cheque receiving securing access module only if the cheque has not been used previously and only if the intended beneficiary of the cheque is the cheque-receiving security access module. [0017]
  • Further in accordance with a preferred embodiment of the present invention, each of the memories includes a public-key signature protected in non-volatile memory. Preferably, each of the memories includes public key data in protected externally inaccessible non-volatile memory which would include the SAM's secret key and the application owner's certification of the SAM's identifying data and public key. [0018]
  • Also provided, in accordance with yet another preferred embodiment of the present invention, is a method for safe collection of payment in return for goods, values or services, the method including providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, and, for at least one purse, signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and preventing the purse, off-line, from exceeding the credit for value receivable which it has been granted. [0019]
  • Further in accordance with a preferred embodiment of the present invention, the second cryptocomputer is operative to generate a sequence of non-repeating numbers, wherein the set of rules includes the following rules: [0020]
  • a. A cheque cannot be received by the cheque receiving module unless a request therefor has been generated by the cheque receiving module, the request including a unique number from the sequence, [0021]
  • b. A cheque generated by the cheque-sending module must include the unique number associated with that cheque, the amount of the cheque and the identity of the intended beneficiary of the cheque, and the cheque-sending module's signature upon the number, the amount and the identity, and [0022]
  • c. The cheque-receiving module must keep a record enabling itself to differentiate used cheques from unused cheques and must confirm that a cheque is an unused cheque before using the cheque. [0023]
  • Also provided, in accordance with another preferred embodiment of the present invention, is apparatus for transmitting electronic receipts over open channels, each receipt having an intended beneficiary, the apparatus including a receipt-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a receipt, a receipt-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a receipt to generate credit, and a set of rules frozen within the first and second memories which allows a receipt issued by the receipt sending security access module to be used by the receipt receiving securing access module only if the receipt has not been used previously to generate credit and only if the intended beneficiary of the receipt is the receipt-receiving security access module. [0024]
  • Further in accordance with a preferred embodiment of the present invention, each of the memories includes a public-key signature certificate protected in non-volatile memory. [0025]
  • Still further in accordance with a preferred embodiment of the present invention, the set of rules is protected by a tamper-resistant architecture. [0026]
  • Additionally in accordance with a preferred embodiment of the present invention, the second cryptocomputer is operative to generate a sequence of non-repeating numbers, wherein the set of rules includes the following rules: [0027]
  • a. A receipt cannot be received by the receipt receiving module unless a request therefor has been generated by the receipt receiving module, the request including a unique number from the sequence, [0028]
  • b. A receipt generated by the receipt-sending module must include the unique number associated with that receipt, the amount of the receipt and the identity of the intended beneficiary of the receipt, and the receipt sending module's signature upon the number, the amount and the identity, and [0029]
  • c. The receipt-receiving module must keep a record enabling itself to differentiate used receipts from unused receipts and must confirm that a receipt is an unused receipt before using the receipt. [0030]
  • Further in accordance with a preferred embodiment of the present invention, the value receivable includes cash receivable and/or accounts receivable. [0031]
  • Also provided, in accordance with another preferred embodiment of the present invention, is a method for safe collection of payment in return for goods, values or services, the method including providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, and, for at least one of the purses, signing and authenticating a time-stamped transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and preventing the purse, off-line, from extending a credit for value receivable which it has been granted over more than a predetermined period of time. [0032]
  • Further provided, in accordance with still another preferred embodiment of the present invention, is a public-key protected method for safe collection of payment in return for goods, values or services, the method including providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing, in public key protected form, an amount of credit for value receivable granted to the individual system element, and, for at least one of the purses, signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and preventing the purse, off-line, from exceeding the credit for value receivable which it has been granted. [0033]
  • Further provided, in accordance with still another preferred embodiment of the present invention, is a method for safe collection of payment in return for goods, values or services, the method including providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, and, for at least one of the purses, signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and preventing the purse from exceeding the credit for value receivable which it has been granted, wherein at least one first purse from among the multiplicity of purses grants an amount of credit for value receivable granted to at least one second purse from among the multiplicity of purses only in response to activation by a predetermined plurality of system directors. [0034]
  • Also provided, in accordance with another preferred embodiment of the present invention, is a method for safe collection of payment in return for at least one of goods, values and services, the method including providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, and, for at least one of the purses, signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and preventing the purse from exceeding the credit for value receivable which it has been granted, wherein at least one first purse from among the multiplicity of purses grants an amount of credit for value receivable granted to at least one second purse from among the multiplicity of purses only in response to activation by at least one system director and operative to record information regarding the activation including the identity of the at least one system director. [0035]
  • Further provided, in accordance with yet another preferred embodiment of the present invention, is a method for transmitting electronic cheques over open channels, each cheque having an intended beneficiary, the method including providing a cheque-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a cheque having an intended beneficiary, providing a cheque-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a cheque, and following a set of rules frozen within the first and second memories which allows a cheque issued by the cheque sending security access module to be used by the cheque receiving securing access module only if the cheque has not been used previously and only if the intended beneficiary of the cheque is the cheque-receiving security access module. [0036]
  • Also provided, in accordance with yet another preferred embodiment of the present invention, is a method for transmitting electronic receipts over open channels, each receipt having an intended beneficiary, the method including providing a receipt-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a receipt, providing a receipt-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a receipt to generate credit, and following a set of rules frozen within the first and second memories which allows a receipt issued by the receipt sending security access module to be used by the receipt receiving securing access module only if the receipt has not been used previously to generate credit and only if the intended beneficiary of the receipt is the receipt-receiving security access module. [0037]
  • A preferred embodiment of the present invention is now described: [0038]
  • In large and small scale distributed payment schemes, off-line agents (bus drivers, fuel station attendants, merchants, parking meters, vending machines, etc.) are called upon to accept cash or equivalent cash advances from credit granting entities and transfer value to (reload) smart cards. An off-line terminal is one that handles all or some transactions without communicating with a central data-base. These applications, before the introduction of Fortress or similar monolithic silicon cryptocomputers, would not have been practical being subject to large scale interference from fraudulent adversaries. [0039]
  • Operators, who in the past were able to work in a cash-only environment, or others, who may not remember the universality of “folding or physical money” as it once existed, would benefit from an electronic purse cash scheme that would be convenient both for consumers and suppliers, with such savings as they once existed. Now, with the advent of electronic money, it is desirable to enhance the option of converting customers' physical money into electronic cash, simplifying and securing clearance through credit card companies, allowing consumers to be benefited with cash discounts, while spreading an equitable part of the savings to participating vendors and providers of service. [0040]
  • In a typical system, customers benefit from having cash held safely in a protected purse. Participating purse loaders may receive a bonus for handling cash (bills and coins=$CASH) or in any other way reloading electronic purses with electronic cash (ECASH or stored value of any form). The operator benefits from interest on the outstanding float held in the consumers' smart cards. [0041]
  • An important issue is how the system operator can be assured, that, in such a dispersed system, where the purse loader and the various cashiers may have only the loosest common interest with the purse operator, that all cash and value will be deposited by the purse operator's agents to the operator's account. Without proper protection agents who load value into cards may be tempted to engage in ‘printing money’). [0042]
  • This issue is now resolved as there are compact mass produced, securely protected monolithic data protection mechanism (public key cryptographic) which immutably compel participants (i.e. silicon microchips) to follow system rules (i.e. protocol frozen in the microchips). [0043]
  • The electronic purse, for relatively large transactions, used in true off line applications, is a relatively new technology, due to the only recent advent of Public Key Smart Cards. With these new smart cards, a valid user can prove to any accepting terminal in the system, that the smart card is owned by a valid user, and that at a given time, the card has a credit balance sufficient to cover a proposed transaction. [0044]
  • In a smart card chip such as those manufactured by the applicant/assignee, Fortress U & T Ltd., there may be several purses. The same chip can be uniquely initialized and personalized by several independent issuers, and each issuer may embed a unique variety of purses and information protecting applications in an individual user's card. [0045]
  • To protect honest users, vendors and issuers from fraud, rules are made and followed to assure the validity of a transaction, and protect honest vendors and consumers. [0046]
  • With credit purchases, general rules of what the EMV calls risk assessment typically include data to prove that an off-line transaction is protected by the cryptographically authenticated knowledge that the purse in the smart card and the accepting terminal are in a valid status; meaning that they are both in good standing, and that the smart card has not used more credit than is allowed, has paid his bills as recently as was demanded, and of course a check for any other aberrations that an issuer might desire, such as a limit on the number of withdrawals in a period of time; the number of purchases that can be made without the vendor's terminal “going on-line” to the central computer in order to restore the line of credit in the card. In the Fortress purse each off-line purchase instantaneously reduces the amount of credit available to the user, which can be reinstated in an on-line transaction or in a purse to purse session with an approved agent. [0047]
  • A vendor or service terminal can receive payment for goods and services from either a debit (stored cash value) purse or a credit purse. This electronic money is transferred, probably at the end of the day, to a clearance organization which properly credits his account. The EMV is drafting new rules which will allow the terminal to insist, for instance, that certain payments, usually small payments less than a predetermined threshold, be made only from a stored cash value purse, and larger transactions are made using a regulated debit or credit purse. [0048]
  • It is anticipated that the terminal will either maintain separate purses for each clearance organization, as in all probability, the strategies for each might differ, or it may collect all electronic payments, archive them, hash and sign the hash to testify to origin, and send to a single clearance organization. Purses in smart cards with safely stored electronic cash or electronic credit will make electronically signed purchases, which will benefit from clearance procedures similar to today's checks and credit card purchases, with a larger degree of confidence than was previously enjoyed. [0049]
  • There are rules for a client depositing $CASH with an agent who then reloads an equivalent value of ECASH in the client's smart card (replenishing spent value) at an off-line site. This has inherent potential danger as an ‘unruly’ terminal reloading electronic cash literally can print money. In this venue, the consumer has assuredly proved his credit by furnishing the purse reloader with cash. The system operator now must be sure that the value reloaded into the consumer's card is commensurate with the monies the operator is to receive in his bank account from the purse reloader, so that he can compensate vendors for goods and services to be received from card-holders who pay with electronic cash. [0050]
  • Purse to Purse Transactions: In purse to purse transactions, value is removed from one purse and loaded into a second purse. In all such transactions, the value should be commensurate and cryptographically protected. Owners of both purses have controlled access to a ‘rotating’ file of last transactions (a history file), enabling them to validate, in any compliant terminal, who, and what monies have been removed or added into their purses. This can protect them from rogue vendors who may have purposefully overcharged or fraudulent terminals which may have ‘short changed’ the card when loading ECASH. [0051]
  • Direct Purse to Purse transactions: Most purse transfers of small value, the largest number of transactions in this scheme, are consummated between dispersed off-line SSCs (terminals and field operators' security application modules/smart cards) and consumer/client CSCs. Preferably, the parties identify each other on the spot and terminate a one or two sided authenticated transaction in a maximum of about half second to two second period of customer transaction time. [0052]
  • As the hierarchy in a deployment scheme such as FIG. 1 is ascended, each level of transactions involves larger value physical cash purse to purse transactions, e.g., drivers to cashiers or treasurers, or cashiers to treasurers, in-system employees to validating participants where at each stage the sums of CCRs grow. Collusion between high and low hierarchy participants is most likely. Keeping control of cash with proper archiving, transmission of all raw data to the central computer for filtering, and purse to purse transactions using PKC offer good protection. [0053]
  • The concept of “credit for cash receivable' (CCRs)—CCR is a regulating entitlement mechanism that the system operator may employ to administer the limits of the amount of cash in the float, and to assure that operators of purse-reloading terminals, or any intermediaries who receive cash destined to the system operator are limited in the amount of cash they receive before depositing such physical cash with the entitled SSC holder or bank, and to compel them to remit all of the receipts provide for in an orderly and secured continuation of the cash collection system. When a system smart card's CCR is exhausted, the owner cannot use his purse to dun a consumer or another system card for cash. [0054]
  • In a system smart card-consumer smart card, purse to purse (physical cash via SSC to consumer's electronic cash) transaction, the SSC CCR purse is decremented by the same amount that the consumer's electronic purse is incremented, e.g. a bus driver who accepts AMT cash from a passenger, to be deposited in the passenger's cash purse; the driver's CCR will now contain AMT less, and the passenger will have AMT more in his ECASH purse to be spent on travel or in the bus station, or cashiers to treasurers, in-system participants to validating participants where at each stage the sums of CCRs grow. [0055]
  • In a cash transaction between two system smart cards, the CCR in A is decremented as he receives cash from B, whilst the same value from A's CCR increments B's CCR; e.g., a driver brings his $600 in cash receipts to a station's treasurer; the treasurer's CCR is decreased by $600, and the driver's CCR is reloaded with $600, probably following a company rule that at every deposit that the driver makes with a treasurer, the driver must replenish his CCR to the maximum float that the system operator granted him. [0056]
  • The Maximum Total Float and each individual SSC Float In this system the decision for, and allocation of the CCRs in the float is directed by the committee or board of directors, and the implementation of allocating the amount installed in a system by these directors is authorized by the manager of the cashflow, monitored and reconciled in all phases by the Central Accountant. Subsequent day to day operation can be automatic. [0057]
  • The single entry point for CCRs is via the managing directors to the central accountant. The accountant arranges the individual allotments according to the director's strategy, and submits, with a single CCR of the total sum to be allotted, accompanied by a list of unsigned CCCRs (cheques for credit for cash receivables) to the manager of cashflow—who electronically allots CCRs, e.g. by simply approving a spread sheet sent to him by the accountant, with a program which commands his smart card to sign the cheques and then to dispatch these cheques for credit for cash receivables; much as he would sign and send present day cheques. [0058]
  • In a transportation system, the only occasions when the directors add CCRs to the float are typically either a system expansion or during a period of inflation. [0059]
  • During system and card initialization, a secured file is generated, which can be read by any terminal, but can only be addressed by the manager of cashflow. This file contains the limit of CCRs which can be loaded into a card, and an optional date of expiration. In general, this file can only be changed by the manager of cashflow, and this only under the aegis of central accounting. An option is allowed for the station manager to grant, to a qualified SSC, a larger amount of maximum float, for a minimal period of time. [0060]
  • Replenishing Purses with ‘Blind Cheques’ CCCRS—Checks for Credits for Cash Receivables—[0061]
  • In the cash transactions described above, two purses, the cash depositor and the cash receiver were simultaneously inserted in a dumb terminal, which monitored the purse to purse negotiations and transaction. Negotiations and transfers were secured internally in the two purse's smart card. When the money is deposited in the bank, the treasurer may or may not be present at the teller's counter, and as the system operator will probably not agree that the treasurer's CCR purse is replenished daily to the same maximum amount, because of normal daily and seasonal fluctuations. The anticipated receipts vary greatly, and there may be a change of treasurers or treasurer's working venue. A preferred solution to this problem is that the treasurer will receive a blind cheque, that goes through a normal clearance mechanism, wherein the treasurer alone is able to use the cheque to increment his CCR, and he and only he can use the cheque once and only once. An analogy might be—a rogue treasurer receiving a conventional bank check payable to him alone which he wished to use to credit his account several times (in the absence of a clearance mechanism that might detect such a scam); as the check was made from an easily detectable unobtainable paper, and the printing on the checks was impossible to duplicate, no matter what methods he would use, he would be unable to make acceptable copies of the cheque to enable him to credit his account several more times. [0062]
  • A similar situation arises in the United States where the Department of Agriculture issues food credits to the needy. A blind cheque must be issued to each of the indigents, who can only use a cheque once, and the USDA must know who the recipient of the cheque is, and that his purse will only be credited with the given amount a single time, when presented to a potentially fraudulent terminal. [0063]
  • In the present embodiment of the present invention, all payments to station managers, station treasurers, and cash flow managers are made with cheques (CCCRs). [0064]
  • The method used here for assuring that a cheque can be credited, once, and only once, is for the issuer of the cheque to know a unique number, which was provably generated by the receiver's smart card (SAM) to be used once and only once, which, as the receiver's protocol is frozen, entitles the receiver to receive a cheque with his primary account number and the unique number only once. This number can be the result of a simple count. In this system, the writer of the cheque knows these numbers, as his smart card (SAM), received the number in an electronically signed request for the cheque for credit for cash receivables (RCCCR), signed duly by the potential recipient of the cheque. [0065]
  • The Bank's Receipts—A similar situation arises when the treasurer (or a lottery kiosk collector or a fuel station treasurer) deposits value in the bank. The bank is typically not an active participant in the payment system, but may be willing that the teller be willing to confirm with an electronic receipt (the equivalent of signing a deposit slip), which the teller can sign. This is making no more demand of the teller for actions, other than those he normally executes. [0066]
  • The central accountant's SAM, and his alone, is programmed to be able to convert a RECeipt from the bank into CCRS. The central accountant's SAM CCR account is totaled once a day, and converted into a single cheque for the manager of cashflow. [0067]
  • The manager of cashflow sets the strategy for distributing CCCRs to the depot treasurers, and the central accountant reconciles this policy, and prepares unsigned electronic cheques for the manager of cashflow to approve and sign. These cheques are automatically distributed by modem to the depots' electronic mailboxes for the treasurers to collect and reinstate their CCRS, entitling them to continue collecting $CASH from drivers and cashiers, to be deposited in the bank, to credit the transportation system's account. [0068]
  • Preferably, parking meters and vending machines, in sensitive to vandalism locations which cannot accept $CASH will be programmed to allow a user to draw a small amount (such as $25) from his credit purse (account) in order to restore his stored value purse and use the meter/machine. In such a case, the meter/machine would be limited with “credit for cash receivables”, determined by the system operators. [0069]
  • Restraint and constraint strategies to be placed on vendor's use of “cash received” in lieu of “credit for cash receivables”. [0070]
  • Time Restraint: [0071]
  • A vendor's terminal can be programmed so that it must deposit cash received within a certain time bound. In a public transportation scenario, 48 hours is a suitable limit, without levying a fine. [0072]
  • This, obviously, would be unsatisfactory in a situation where very small amounts are involved, as participating merchants, in such a situation would be daunted by the difficulties of handling transactions. [0073]
  • Limiting the Credit for Cash Receivable that a Vendor is Allowed: [0074]
  • In all Fortress vendor and consumer SAMs and smart cards, a value of use limit is put on all purses. The system operator is probably not willing that the vendor collects and holds large amounts of money for long lengths of time which he used to reload customer purses; certainly not without receiving interest for non-payment on time. [0075]
  • This is the “hold” that the system operator has on the vendor. If a vendor does not comply with the operator's rules, and has used up his credit for cash receivables, then the vendor may refuse to reissue his credit, and the vendor will then be unable to reload stored value into consumers' purses. [0076]
  • Coupling the Motivating Bonus which the Vendor receives for handling the cash with interest charged to the vendor for delayed transfer of funds, in those cases where the vendor does not ‘buy’ the original CCR sum, but is allotted by the system operator. [0077]
  • All cash which is collected by vendors is archived in the vendors'terminals, dated and certified. All funds collected by a vendor grant him a percentage bonus for handling and transferring the money for clearance, and for his part in collecting payments in advance. [0078]
  • What would be a typical strategy, would consist of a bonus percentage, and an “average per day delayed transfer percentage”. [0079]
  • To demonstrate, let us assume a 3% bonus, a three day grace period, and a 1/10% per day “average per day delayed transfer percentage”, and that a convenience store accepted cash, as appeared in the table from the 10th of the month (the last time cash was transferred) until the 18th of the month, when the convenience store made a bank transfer to the system operator. [0080]
    1/1000 of Bonus $
    Daily $ Totaled 3rd day Interest less
    Day Receipts Receipts$ (Interest) to Date Bonus$ Interest
    10/11 1000  1000
    11/11 1500  2500
    12/11 3000  5500
    13/11 1000  6500 1.0
    14/11  500  7000 2.5  3.5
    15/11 1500  8500 5.5  9.0
    16/11 6000 14500 6.5 15.5
    17/11 2000 16500 7.5 23.0
    18/11  500 17000 8.5 31.0 510.00 478.50
  • Availability of the System [0081]
  • The above-described cashflow system may be generated as follows: The hardware is supplied off the shelf by Fortress U&T Ltd. [0082]
  • Each work station in a preferred embodiment is an IBM type PC equipped with Windows 3.1 or 95, 16 Mbyte of RAM, a hard disk and a BestCrypt-4-PC drop in card, at least one smart card reader. [0083]
  • An issuer's workstation is maintained in a very well protected area, used for initializing smart cards and workstation SAMS, and it is used to configure the workstations, each with proper access and priority. [0084]
  • The Smart Cards and SAMS used in the system are the first generation SGS-Thomson ST-CF54 with the first version SCOS+ operating system. [0085]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The present invention will be understood and appreciated from the following detailed description, taken in conjunction with the drawings in which: [0086]
  • FIG. 1 is a simplified block diagram of a payment collection system useful for a transportation network, the system being constructed and operative in accordance with a preferred embodiment of the present invention; [0087]
  • FIG. 2 is a simplified flowchart illustration of a method for performing a purse-to-purse transaction between two operator personal modules (OPMs) of FIG. 1 such as between a driver's OPM and a depot treasurer's OPM or such as between a depot treasurer's OPM and a depot manager's OPM; [0088]
  • FIG. 3 is a simplified flowchart illustration of a method for canceling the purse-to-purse transaction of FIG. 2 if the purse-to-purse transaction failed; [0089]
  • FIG. 4 is a simplified flowchart illustration of a method for performing the cheque receiving step of FIG. 2 for applications in which the cheque for credit for cash receivables as sent without third party clearance; [0090]
  • FIG. 5 is a simplified flowchart illustration of a transaction cycle performed by the various elements of FIG. 1; [0091]
  • FIG. 6 is a simplified block diagram of a payment collection system constructed and operative in accordance with a preferred embodiment of the present invention which is operative to collect value from smart card bearers (clients) and to load electronic money into the clients' smart cards; [0092]
  • FIG. 7 is a simplified flowchart illustration of the operation of the smart card of FIG. 6, for an application in which the smart card is installed in a parking meter; [0093]
  • FIG. 8A is a simplified flowchart illustration of a preferred method for performing the “charge for parking” [0094] step 750 of FIG. 7;
  • FIG. 8B is a sample table storing predetermined sequences of parking time-intervals; [0095]
  • FIG. 9 is a simplified flowchart illustration of a preferred method for performing the “process smart card insertion event” step of FIG. 8A; [0096]
  • FIG. 10 is a simplified flowchart illustration of a preferred method of operation for a warden summoned by the method of FIG. 7; [0097]
  • FIG. 11 is a simplified flowchart illustration of a preferred method for incrementing the electronic cash balance of a user's card; [0098]
  • FIG. 12 is a pictorial diagram illustrating the flow of electronic value between a user's smart card/s, a parking meter's SAM and a parking warden's OPM; [0099]
  • FIG. 13 is a pictorial diagram illustrating a preferred flow of electronic value between a parking warden's OPM, a parking meter operator, and a purse operator. [0100]
  • FIG. 14 is an illustration of a public key authentication hardware interface supporting up to four smart card readers which is useful in one implementation of the present invention; [0101]
  • FIG. 15 is a pictorial illustration of a display screen generated by a transaction terminal; and [0102]
  • FIG. 16 is a pictorial illustration of a display screen generated by a smart card application developer.[0103]
  • Attached herewith is the following appendix which aids in the understanding and appreciation of one preferred embodiment of the invention shown and described herein: [0104]
  • Appendix A is a computer listing of a preferred software implementation of the present invention operative in conjunction with a plurality of SGS-Thomson STCF[0105] 54 chips equipped with a SCOS+ or SCOS++ operating system, commercially available from Personal Cipher Card Corporation, Lakeland, Fla., USA or Fortress U & T Ltd., Beer-Sheva, Israel, the chips being customized using an SCAD development system, commercially available from Fortress U & T Ltd.
  • DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
  • A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. [0106]
  • In the present specification and claims, the following terminology is employed: [0107]
  • An entity is considered to have “a credit of X dollars for cash receivables”, also termed herein AMT, or “X$ of CCRs”, if he has been granted the right to accept X dollars in cash. [0108]
  • The term “cash” or “$CASH” refers to physical money as opposed to other vehicles by which payment can be made such as electronic money, credit cards, cheques, bank transfers and the like. [0109]
  • A client of a system which provides services in return for payment is an entity which pays the system and, in return, receives a service. For example, the passengers of a transportation system are the transportation system's clients. [0110]
  • The term “purse” is used to denote a payment manipulating element. A “client's purse” is a purse belonging to a client which holds a certain amount of value, either cash or virtual value, which the client may use to pay the system. A “system element's purse” is a purse belonging to an element of the system, such as one of [0111] elements 20, 60, 70, 80, etc., which holds a credit for cash receivables, i.e. an entitlement to receive physical cash.
  • The following abbreviations and notations are employed in the present specification. The definitions provided herein refer only to a preferred embodiment of the present invention and are not intended to be limiting. [0112]
    $CASH - Bills and coins (physical cash), normally used as
    legal tender.
    Acquirer - Bank or other Issuer who clears transactions.
    a Alpha- the first letter of the Greek alphabet.
    A (a)
    AAC Application Authentication Cryptogram - A response sent by
    the SAM/SC indicating a rejection of a transaction.
    AAR Application Authorization Referral - A response sent by the
    SAM/SC indicating a request for a referral.
    AC Application Cryptogram - A cryptogram sent by the SAM/SC
    indicating the state of a transaction.
    ACC Application Currency Code - Identifies what currency is used
    in a transaction
    ACN Account Number- A unique number identifying smart card's
    account with an issuer. See PAN.
    ACK Acknowledgment- Confirmation of acceptance of transmission.
    Application Default Action - A data element indicating the
    action a card should take for certain exceptional conditions.
    ADF Application Definition File - A file that contains data which
    defines application properties.
    AED Application Expiration Date - A closure date after which
    application may cease to be valid.
    AEF Application Elementary File - A basic file that contains data
    which can be used by the SAM/SC.
    Application Elementary File Data Template- Attributes of a
    file stored in the FCI.
    Application Effective Date - Starting Date from which the
    application may be used.
    AFL Application File Locator - A string divided into fields of
    typically four bytes, pointing to file and record numbers,
    containing relevant application information.
    AID Application Identifier - Identifies the application as
    described in ISO 7816-5, comprises the RID and the PIX.
    ISO7816- A set of standards for manufacturing ICCs. Serves as basis
    Parts
    1 + 5 for most other standards.
    AIP Application Interchange Profile - Indicates capabilities of
    the card.
    AMD Application Management Data
    AMT Amount of Transaction - A Binary Coded Decimal, exact to
    1/100, in the present example.
    Subscript DP signifies the amount to be collected by a
    [AMTxy] parking meter for parking until the end of the regulated
    parking day, e.g., parking may be free from 7:00 PM.
    Else, subscript XY signifies AMT transferred from X to Y.
    an Alphanumeric - A data sequence which may represent letters,
    punctuation marks, and numbers (characters). ASCII is for
    alphanumerics.
    ans Alphanumeric Special-
    APC Automatic Passenger Counting system- an electronic system
    which audits the number of passengers in an autobus.
    APDU Application Protocol Data Unit - A command response, data
    template or data structure
    AR Account Receivables- an archive of completed transactions,
    preferably with PK proof, typically with identification and
    time of transaction. The account receivable archive is
    external to the SAM; as opposed to the CAR, the credit for
    accounts receivable, which may only be a PK protected re
    Archive File (Cryptographically Linked) - A working file
    which is composed of data fields which are linked together in
    a fashion such that removal of or alteration of data in any
    Archive File field can be detected.
    Asymmetric (PKC) - Public Key Cryposystems where all
    subscribers have unique (not shared) secret keys and unique,
    universally available public identifiers.
    ARPC Authorization Response Cryptogram - A response, sent by the
    issuer, upon receipt of an ARQC, which proves its
    authenticity.
    ARQC Authorization Request Cryptogram - A response, sent by the
    card, indicating a request to go on-line.
    ATC Application Transaction Counter- The transaction numerator
    which is incremented at every transaction performed by a
    SAM/SC.
    ATM Automated Teller Machine - A remote banking machine for
    distributing money and performing other functions generally
    performed by a human bank teller. (Banking)
    ATM Automatic Ticketing Machine- see TIM
    ATR Answer to Reset - A data string emitted by a smart card ICC
    at reset, to supply information, e.g., the type of circuit,
    operating system ID, communication parameters, etc.
    Auth. Authentication - proving the validity and acceptance of
    liability to a string of data (certificate), usually to prove
    identity of a device, either as a preamble to a transaction
    or as a control to access.
    b Binary - An Integer number system where all numbers are
    represented by strings of modulo 2 digits (bits), e.g., each
    digit is either a one or a zero. The string 1011 is equal to
    23 + 21 + 20 = 11.
    BAL Balance in a purse
    BCD Binary Coded Decimals - A binary code where each decimal
    digit is represented by a nibble (4 bits)
    bit- a binary digit, i.e. a bit can be equal to a one or a
    zero.
    BER-TLV Basic Encoding Rules Tag Length Value
    BGT Block Guard Time- see T = 1 timing.
    BIN Base Identification Number -
    Blind transfer. Sending an electronic transaction over an
    open channel, without first establishing a formal link with a
    second party, e.g., depositing an electronic cheque in a
    mailbox, without explicitly communicating with the recipient,
    while enabling the recipient of the transfer to credit his
    internal purse without performing a clearance via a trusted
    third party, e.g., a bank, Visa, etc. See CCCR and RCCCR.
    bus (Motorola often prints buss)- an internal data channel
    which connects a CPU with its peripherals.
    BUI Bus (Autobus) Interface Unit- Connects the TIM's bus
    peripherals, power supply, network interface, etc. to the
    TIM's motherboard.
    BWI Block Waiting time Integer- see T = 1 timing.
    BWT Block Waiting Time- see T = 1 timing.
    C-APDU Command APDU- for T = 0 timing - Command + Data sent from an
    application to the TTL.
    CAR Credit for Accounts Receivables - The mechanism, (very
    similar to the CCR), meant to control account value
    (generally electronic) received and transferred by SAM/SCs.
    Generally, such value will be handled by a central clearance
    organization (see acquirer). When electronic value is
    accepted by a SAM/SC, e.g., a vending machine, a TIM, a
    parking meter, following rules established by the SC issuer,
    the SAM/SC's CAR is decremented. Means and methodology in
    this document with relation to transfers of CCRs may be
    applicable with CARs. However, the motivation for full
    authentication of the terminal to the SAM/SC is diminished by
    the inherent delay in debiting and crediting ECASH, and the
    decreased value of ECASH to a rogue or a rogue organization,
    owing to the traceability of an ECASH transaction, and the
    efficient clearance abilities of the acquirer.
    For example a cash advance public key smart card parking
    transaction is demonstrated;
    assuming that all financial service and handling charges
    between a parking meter (PM) operator, an ECASH purse
    operator and credit card applications are reconciled on a
    monthly basis, and that these service charges are not
    relevant to the transactions involved; and assuming that the
    client who is paying for parking services (the cardholder)
    has two applications, a public key credit smart card, and a
    public key ECASH smart card, either on the same smart card or
    on two separate public key SAM/SCs, preferably both able to
    authenticate to the PM that they have the same owner;
    and assuming here, entitlement to load ECASH into a client's
    purse (tantamount to printing electronic money) is granted to
    a secured PM, where the source of the payment is a client's
    credit card giving a “cash advance”,
    and assuming that the PM operator's strategy for risk
    assessment, in addition or in place of the EMV strategy for
    off-line assessment of risk collections, is to allow a cash
    advance only for the exact amount necessary to pay for
    parking for a full day (AMTDP), (about $40), and for only
    one cash advance per day without going on-line and that it
    immediately charges for the first double time increment, and
    will only return the surplus when the client returns to take
    his vehicle, and no sooner than 15 minutes from the client's
    initializing of the transaction;
    as the meter receives AMTDP from the client's SC credit card,
    the meter's credit receivables purse is incremented; the PM's
    CCR entitlement is decremented; as the TPMP is incremented by
    AMTDP; and the TPMP purse is immediately decremented by the
    PM_INC's first two increments of ECASH reducing the CAR by
    the same amount and incrementing the accounts receivables
    (AR) purse by the same sum;
    subsequent time increments elapsing before the return of the
    client with his SC will activate additional incremental
    transfers from the TPMP to the AR purse, and decrements from
    the entitling CAR;
    when the client returns to retrieve his vehicle, he inserts
    his smart card; the TPMP is entitled to return to the
    cardholder the remainder of the ECASH left in the TPMP from
    the credit card cash advance to replenish the cardholder's
    ECASH purse; the total parking transaction is archived in the
    accounts receivable purse.
    Assume that there was only this single parking transaction,
    and that the meter accepted $16 for parking, and received a
    cash advance of $40 from the credit card application. The PM
    would have returned $24 to the cardholder's ECASH purse; used
    $40 of the PM's entitlement; taken $40 of credit receivables
    to be given eventually to the ECASH purse operator who would
    use it to dun the credit card acquirer, and $16 of accounts
    receivable to be used by the PM operator to dun the purse
    operator for parking services.
    When servicing the PM, the warden's terminal would unload
    the PM's CRs into its own CR purse, decrement the warden's
    CCRs by $40 to replenish the PM's CCR back to the PM's
    maximum CCR entitlement; and then unload the $16 of ECASH
    from the PM's AR purse, into its own AR purse,
    decrementing the warden's CAR and incrementing the PM's
    CAR by $16, to return the CAR to its maximum entitlement.
    When the Warden or RF network connection “duns” the meter,
    the warden's “dunning” terminal archives and transmits proof
    of ARs collected (parking tariff) to the operator's
    accounting system and ECASH reloaded in client purses.
    Cashback- the ability to cancel a transaction and return
    value. In the normal merchant client transaction an option
    can be allowed to cancel the last transaction in a client's
    card, if and only if the request is for cancelling the very
    last transaction.
    Cashback Purse- In the driver traveller scheme, a preferred
    feature is cancelling of a hardcopy ticket purchased with
    $CASH. The specification preferably allows the driver the
    option of returning full or part fare in $CASH to a traveller
    if a claim is made in reasonable time, e.g. a traveller who
    took a bus in the wrong direction and realized his mistake in
    the first one-half hour of the trip.
    E.g., for this purpose, the OPM also has a Cashback Purse
    which is incremented with Cashback Credit each instance that
    the driver prints a cashback receipt on the TIM. When the
    driver reconciles $CASH and CCRs with an entitled acceptor of
    cashback credit, e.g. a depot treasurer, he deposits cashback
    credits and $CASH with the depot treasurer and receives CCRs
    equal to the sum of cashback and $CASH. Such an entitled
    cashback credit acceptor is enabled to decrement his CCR
    purse with the cashback credits received from the driver.
    The cashback purse preferably contains a cumulative register
    which sums all cashbacks from a start date, as a measure of
    merit for a driver. (A large sum in the cashback summation
    may signify suspected fraud.)
    Cashiers, Depot- Acceptors of moneys from drivers. Depot
    Cashiers deposit their collected funds with the Depot
    Treasurer At present, Depotlast. purse Cashiers are sellers of tickets
    to drivers. In some depots, the treasurer may also act as a
    depot cashier.
    Cashiers, Ticket- Sellers of tickets to passengers at depots.
    Also have TIMs and OPMs.
    CBC Cipher Block Chaining- A typical feedback mode of DES
    En/Decryption wherein many blocks of data are sent, often
    quite similar messages are dispersed to varied recipients.
    Here the results of one encryption are XORed to the following
    block. Any change in the first block will assure non-
    identical encryption of following blocks, should the
    following data be identical.
    CCCR Cheque for Credit for Cash Receivables- A cheque sent over an
    open channel to replenish CCRs without handshake, as opposed
    to a purse to purse CCR transaction, wherein two SAM/SCs
    communicate in a handshaking protocol. The CCCR can only be
    deposited once, and only by the recipient whose PAN and ATC
    numbers appeared in the RCCCR. See CCR and RCCCR.
    CCR Credit for $CASH Receivables- the credit limiting license
    granted to a system employee or device to collect $CASH or
    $CASH equivalent (e.g. a “cash advance from a credit card”),
    from consumers. This credit is held in a purse in a SAM/SC,
    protected by strong PKC.
    In the system steady state, in a one to one transaction,
    these credits can only be incremented in one purse if
    decremented by the same amount from another system purse.
    When a vendor accepts AMT of $CASH for the system from a
    consumer the vendor's CCR is decremented by AMT and he
    typically executes a system “purchase” in order to decrement
    his CCR. An example of such a purchase; in a purse to purse
    transaction with a consumer's purse in a CSC, a lottery
    ticket seller, who is entitled to load ECASH in CSCs, accepts
    AMT of $CASH, wherein he increments AMT of ECASH in the
    client's CSC, he purchased ECASH from the system (e.g. the
    client's ECASH purse), while decrementing his CCR by AMT. His
    CCR may subsequently be replenished by a CCCR sent to him by
    electronic mail, after he has deposited $CASH at his local
    bank.
    In transactions between system employees, where $CASH is
    handed from one to another, reconciliation is executed purse
    to purse, wherein the recipient of the $CASH's purse is
    decremented, and the depositing employee's purse is
    incremented.
    To demonstrate another such $CASH transaction; a driver
    deposits AMT of $CASH receipts with a cashier. The cashier
    accepts the $CASH; during the transaction the cashier's CCR
    purse is decremented by AMT, and the driver's purse is
    replenished by AMT.
    CCR can also be incremented with receipt of a CCCR. When the
    (payer) sender of a CCCR writes the cheque, his CCR is
    reduced by the equivalent amount. CCRs are only legal tender
    between system employees or agents, and can only be
    transferred between SSCs.
    A vital link in the CCR mechanism is the use of a REC (an
    electronic $CASH receipt from a bank or similar repository),
    wherein the bank signs a receipt for the $CASH deposited.
    Typically, this receipt can be converted to CCRs, only by an
    entitled entity, e.g., an accountant who can reconcile such
    RECs with accounts received from the banks and hardcopy
    receipts sent via internal mail.
    CCPS Chip Card Payment Service
    CD Committee Draft
    CDOL Card Risk Management Data Object List - A list of data
    objects used by the card to perform a transaction.
    Cert. Certified - Authorized by an agreed upon Trusted Authority
    (whose ID is recorded in non-volatile memory in a SAM/SC)
    Certificate- A cryptogram signed by an issuer or a sub-issuer
    of a system whose public key is known and recognized by the
    authenticator, thereby proving responsibility and origin of
    the hashed contents of the cryptogram (generally the hashed
    data relating to the validity of membership of a cardholder
    in a community, e.g. a Visa cardholder, his ID, his public
    key, the period of validity, his credit rating, etc.)
    Cheque- Here used as an vehicle for a blind secured
    transaction sent over an open channel, without third party
    regulated clearance procedure. Cheques (CCCRs) transfer CCRs
    to recipients who have designated a request, see RCCCRs. See
    also RECeipts and requests for receipts (RRs).
    CID Cryptogram Information Data - Indicating the type of
    cryptogram (AAC, ARQC, AAR or TC) returned by the card.
    CLA Class Byte of the Command Message- First byte of a command
    conveying attributes of command processing
    CLK The signal used to drive and synchronize the workings of the
    CPU (or the state machine in a secured memory chip) in an
    ICC.
    Clone- A device which behaves like another device, under all
    relevant conditions.
    cn Compressed Numeric - Same as BCD.
    Cons. Consecutive- following immediately, e.g., 369 follows 368
    consecutively.
    CPLC Card Production Life Cycle- The period of relevance of a
    card's life, from embedding of module or Issuance to end of
    card validity.
    CR Credit Receivables-An archive of credits which are to be
    presented to a credit organization, in the parking meter
    scenario, assumed to be in lieu of cash (a cash advance).
    In the parking meter scenario, credit receivables contain
    credits which the meter collected for a purse operator,
    wherein the parking meter serves as a surrogate for the purse
    operator, entitling the meter to reload ECASH into clients'
    PK smart card purses.
    CRL Certificate Revocation List- listings of disqualified members
    of a system (black listed users or issuers)- issuers' and
    users' CRLs should be kept in separate files. These listings
    may be made current at regular intervals.
    CRT Chinese Remainder Theorem- an acceleration method for modular
    multiplication over composite moduli (moduli which are a
    multiple of two or more factors) - used especially with RSA
    and sometimes with D-H.
    CSC Consumer's Smart Card - In a system wherein physical cash
    ($CASH) and/or ECASH flow is protected using CCRs and/or
    CARs; a CSC is a smart card held by a consumer whose card can
    be loaded with electronic cash from an SSC (system smart
    card). A CSC cannot increment CCRs in an SSC.
    When a consumer gives an SSC holder, AMT of $CASH to an SSC
    holder for reloading cash to his CSC electronic cash purse,
    the SSC's CCR purse is decremented by AMT, as the CSC's
    electronic purse is incremented by AMT.
    When a consumer gives an SSC holder $CASH to purchase a
    printed travel ticket, the SSC's CCR is decremented, while
    the SSC executes a purchase from the TIM, e.g., the driver
    receives $10 from a passenger; keys in the “purchase” on the
    terminal, thereby decrementing his CCR by $10, to make a
    purchase from the terminal, which prints the $10 travel
    voucher; the terminal archives the purchase in a file for
    further reconciliation by accounting but does not increment a
    CCR.
    When a consumer gives an SSC holder $CASH to purchase a
    multiple smart card travel ticket, the SSC's CCR is
    decremented, while the SSC executes the purchase from the
    TIM, whence the TIM opens a secured file in the CSC e.g., the
    driver receives $20 from a passenger; keys in the “purchase”
    of a day pass (or a multiple local 6 ticket or a special fare
    excursion . . .) on the terminal, thereby decrementing his CCR
    by $20, to make a purchase from the terminal, which prints
    the $20 travel voucher; the terminal archives the purchase in
    a file for further reconciliation by accounting.
    CSN Card's Sequence Number - A counter, managed by the card,
    which is increased with each transaction and authentication.
    See ATC.
    Cum. Cumulative- a process where all values are added together.
    CVM Cardholder Verification Method - A data object read from the
    card, indicating the procedure used to verify the card holder
    (PIN).
    CVR Card Verification Results - A data object, managed by the
    terminal, indicating the result of the authentication check
    of card holder.
    CVV Card Verification Value -
    CWI Character Waiting Time Integer- See T = 1 timing.
    DAD Destination node Address- T = 1 transport layer.
    DDF Directory Definition File - A file that contains entries for
    other DDFs and ADFs in the current directory.
    DDOL Dynamic data authentication Data Object List- Data Object
    list that is used to perform authentication.
    DEA Data Encryption method- symmetric cryptographic method used
    in DES)-
    DEK Data Encryption Key (shared secret between 2 DES subscribers)
    Deposit- The amount (or act of giving) receivables, e.g. to
    a treasurer or teller.
    Depot- In the mass transportation deployment any station or
    substation on line to central computer where transactions
    between drivers and cashiers/treasurers are executed.
    DES Data Encryption Standard - de jure symmetric crypto standard.
    DF Dedicated File - A file containing directory entries, or
    application definition data.
    D-H Diffie-Hellman- public key method for secret key exchange.
    DIR Directory File - A DDF that includes only EMV applications.
    DIS Draft International Standard
    DK Derivation Key- One of the 16 different 48 bit Secret Keys
    derived from a 56 bit DES Master Key. For triple DES there
    may be two Master Keys.
    DN Data Block N
    DSA (DSS) Digital Signature Method (Standard) NIST method for
    documentation integrity
    Dual Message Transaction - 2 step - Authentication - then
    clearance
    Dynamic Data Authentication - Proving authenticity by
    answering a challenge using a secret without divulging the
    secret.
    DTA EasyEntry Visa spec - file for all MagStripe Info in every
    Visa ICC application, to provide a minimum of compliance to
    old applications.
    ECASH Electronic value, commensurate to a national currency, kept
    in a consumer's ICC purse, and in some payment schemes, in a
    vending device.
    ECB Electronic Code Book- A mode of use for DES, wherein a block
    (64 bits) of plain text is encrypted to 64 bits of
    ciphertext. Note that for the same key and the same block of
    plain text, the result will always be identical. See CBC.
    EDC Error Detection Code- A system of adding redundant code to
    blocks of message, wherein it is possible to determine (but
    not necessarily detect) that an error of up to a
    predetermined size has occurred within the block.
    EDT Electronic Data Transactor - Transaction terminals for
    depots, communicating with central data processing computer.
    All raw data is transmitted for processing in a central
    computer.
    EEPROM Electronically Erasable Programmable Read Only Memory - Non
    volatile memory which can be written to/erased in small
    increments.
    EF Elementary File (ISO, EMV, PC3)
    EMV Work group consisting of Europay, MasterCard and Visa formed
    to standardize smart card payment systems, based on ISO 7816
    specs, RSA, SHA1, triple DES, etc.
    Entitlement to accept $CASH, ECASH. The CCRs and the CARs are
    the vehicles which put working limits on the entitlement of
    devices, agents, or employees in a payment system to accept
    physical cash or electronic value.
    Entitlement- The procedure allowing an issuer or a subissuer
    the proper priority to access applications -no access, read
    only, write only and read and write. In a payment scheme,
    additional entitlements may be appended; e.g., enabling the
    acceptance of receipts, cheques, etc.
    ETICKET Electronic ticket(s) or voucher(s), equivalent to hardcopy
    ticket(s) and voucher(s). Typically, these tickets reside in
    secured purses within a PKC Smart. Card, adjunct to a control
    file which regulates usage.
    etu Elementary Time Unit- Used to define the synchronized baud
    rate between ICC and terminal.
    FCI File Control Information - A template, returned by the card,
    containing relevant data options about the accessed file.
    FCP File Control Parameters- A template used by the EMV to
    control file parameters, can be part of the FCI.
    Firewall - a virtual barricade to prevent illicit access to
    computer systems, typically based on sound authentication
    methodology.
    FIPS Federal Information Standard- NIST designation for US
    Government approved standards.
    FMD File Management Data- A template used by the EMV to control
    file parameters, can be part of the FCI.
    Floor Limit - an EMV value variable, above which a terminal
    has the option to transfer the negotiation process to the
    On-Line host
    Free Access Purse- A client purse for executing accelerated
    preferably small payments. A purse that allows a terminal
    free access is designed for those payments where the SC
    holder recognizes the terminal (a transportation ticketing
    device, a parking meter), where he has reasonable confidence
    that the terminal is operated by a responsible party, and
    where he can assume that he can immediately ascertain what
    transactions the terminal has executed, and that he will have
    sufficient proof in his history file, to rectify any
    aberrations, e.g., when a traveller inserts his SC in a TIM,
    the CAR purse to purse protocol will not include the TIMs
    proving to the SC that the TIM belongs to the bus company and
    is entitled to collect ECASH; however the SC does prove to
    the TIM that it has decremented its purse by the AMT demanded
    by the TIM, after having archived the transaction in the SC's
    history file.
    Frozen Protocol - procedures which may be followed assuming
    the inviolability of SAM/SC modules and terminal procedures.
    GPO GET PROCESSING OPTIONS - An EMV command that initiates a
    transaction by sending processing options to the smart card.
    In return, if the smart card approves the processing options,
    it sends the AIP and the AFL.
    Hacker - a real time programmer who find weaknesses in
    systems with intention to penetrate networks and databases.
    Hash - a nonsecret one-way transformation of data, usually
    converting a large string to a much smaller string - usually
    prior to signing the smaller string - to prove authenticity
    of a large string - see Message and Signature. See SHA1.
    hex. Hexadecimal - also ‘nnn’ as in ‘9F01’ or $9F01 as in Motorola.
    HHMM Hours Minutes- A 4 byte real time data segment.
    HHMMSS Hours, Minutes, Seconds - A 6 byte real time data segment.
    History File- A rotatino file of last purse transactions
    performed by a SAM. In general, only the cardholder and the
    issuer (not the issuer's agents) have entitlement to read the
    file on any system terminal. This permits the cardholder to
    confirm the actual value of his transactions. The card issuer
    determines how many “last transactions” can be stored in the
    EEPROM.
    IAC Issuer Action Code - A set of i under defined action lists,
    indicating the behavior of the card, in different situations.
    I-Block Information Block- in the T = 1 transportation layer, the
    command + data set which is transmitted from the TTL to a
    SAM/SC.
    IC Integrated Circuit - A microelectronic device on which there
    are a multiplicity of transistors, resistors, capacitors,
    etc. usually to manipulate digital data.
    ICC Integrated Circuit Card - a smart card with an embedded
    secure CPU module, preferably with PKC protection.
    IEC International Electrotechnical Commission - one of several
    standardization agencies defining ICC device specs, working
    with ISO.
    IFD Interface Device- Generally an ICC reader.
    IFS Information Field Size- See T = 1
    IFSC Information Field Size for the ICC- See T = 1.
    IFSD Information Field Size for the Terminal- See T = 1.
    IFSI Information Field Size Integer
    INF Information Field
    INS Instruction Byte of the Command Message - According to ISO
    7816 structure, typically.
    ISO International Organization for Standardization issuers of
    internationally accepted technical standards - see Normative
    References -
    ISOxx(•) ISO Format Function 9796 on xx bytes of text (specified in
    parenthesis) - a data structure for electronic signatures to
    protect message/document integrity.
    Issuer - Card Issuer or Card Issuer's Agent
    Journal Printer - An internal device which prints a record of
    every transaction, e.g., on a continuous tape.
    KM Master Key- A shared secret key in a DES system.
    KS Session Key- A (DES) Key, which is generated for, and used
    only once, securely exchanged for use in accelerated
    transmission of data between two implicitly trusting
    communicants.
    LC Length of the Command Data Field- Number of bytes in a
    command.
    lcm least common multiple- the smallest factor that is common to
    two numbers. The lcm of two different prime numbers is one.
    LD Length of the Plaintext Data in the Command Data Field- a one
    byte variable defining the length (in bytes) of plaintext
    data.
    LDD Length of the ICC Dynamic Data- A one byte variable.
    Le Maximum Length of Data Expected by the TAL in Response to a
    ISO 7816-4 Case 2 or 4 Command
    LEN or Length- Length of Data in Bytes (a one byte variable)
    len
    Licc Exact Length of Data (denoted by a one byte variable)
    available in the ICC to be Returned in Response to the 7816-4
    Case 2 or 4 Command Received by the ICC
    Lock - A closure put on an application(s) by a terminal, an
    issuer, or by internal negotiation within the ICC, preventing
    access to such applications. Some closures can be removed by
    the issuer, probably after card user has fulfilled
    obligations, or following return of card to rightful owner.
    Lr Length of Response Data Field- Length of Data in bytes
    received by the Terminal.
    LRC Longitudinal Redundancy Check- A check of transmitted data
    integrity.
    M Mandatory
    MAC Message Authentication Code- A one way function, using an
    accepted key, usually in symmetric cryptography (with
    publicly known DES keys), to prove the validity of a
    document, and its origin. See also hashes and signatures in
    public key cryptography.
    Message - a binary string which may include random or
    formatted data, and/or a Hash of said data.
    MIC Message Integrity Check
    MIN(I) A variable time increment in a service tariff table, e.g., in
    a parking meter tariff table in a very busy street, the
    zero'th time increment might be 15 minutes, (at a lower
    PM_INC(0) tariff of $.50), and the 3rd time increment might
    be 60 minutes and call for a tariff, (PM_INC(3), of $10.
    MIPS Million (Assembly Language) Instructions Per Second- a
    commonly used measure of computational performance.
    n Numeric - A data string of “countable” values on which
    computations can be executed in integer mode only.
    N/A Not Applicable
    NAD Node Address- In T = 1 transport level, the addresses of the
    source and destination.
    NAK Not Acknowledged- A signal transmitted by a receiver denoting
    inability to correctly receive a message.
    NCA Length of Certification Authority's Public Key Modulus in
    bytes.
    NI Length of the Issuer's Public Key Modulus in bytes.
    NIC Length of the ICC's Public Key Modulus in bytes.
    Nibble - A group of 4 bits of binary data (one half of a
    byte).
    No. Number - A mathematical definition of a total of finite
    items, which can be used directly in computationS.
    O Optional
    One way function. Any function which is relatively easy to
    perform, but is computationally unfeasible to reverse, e.g.,
    squaring a large integer over a composite modulus is very
    easy, but finding the square root of such a number is
    considered computationally intractable to an attacker who
    does not know the secret factors of the modulus.
    Off-Line Terminal/Transactions - Instances where negotiations
    and risk management are handled by a remote terminal. Most
    PKC applications are executed Off-Line. An off-line terminal
    may have a dial-up option for updating and data transfer.
    Using public key protocols, risk management can be handled
    successfully off-line, wherein transactions which do not meet
    acceptable off-line criteria, will either be refused, or if
    the on-line terminal option is available, the terminal can go
    on-line to central clearance.
    On-Line Terminal/Transactions - Transactions, preferably
    asymmetric, where the remote terminal serves as an
    intermediary to a central Host which negotiates directly with
    the external device. In the EMV scenarios, all ATM
    transactions (value transfer to a user) are On-Line. In PKC
    applications, fewer transactions must be executed On-Line
    OPM Operator's Personal Module. An enclosed device which contains
    protected transaction memory and a SAM/SC to protect
    transactions and gain access. Acts as a Smart Card with a
    large external memory.
    P1 Parameter 1 - In ISO 7816 standard command, the first number
    which appears after the command.
    P2 Parameter 2 - In ISO 7816 standard command, the second number
    which appears after the command.
    P3 Parameter 3 - In the EMV extension, the third number which
    appears after the command (used to specify length of data).
    Parameter Printer - A printer which accepts commands (e.g.,
    for following $45) for complete lines of data with additional
    parameters, e.g., “Time elapsed from start of journey - 30
    minutes , kilometers 34.” - 30 and 34 are parameters; e.g.,
    the complete command would be 45, 30, 34.
    Personalization - A procedure followed by an issuer wherein a
    smart card or SAM/SC is assigned to a subscriber with unique
    identification, and file structures are programmed into the
    EEPROM with access priorities and keys.
    PAN Primary Account Number- the EMV identifier of an account.
    PCA Certification Authority's Public Key.
    PCB Protocol Control Byte
    PDOL Processing Data Object List - list of data objects that a
    system uses to initiate a transaction.
    Phase A- first deployment of TIM on 200 busses. Basic System
    experiments.
    Phase B- System expanded with complete transition to Smart
    Cards.
    Phase C- Total deployment with Smart Cards.
    PIN Personal Identification Number- A unique number, preferably
    known only to the owner of a SAM/SC or smart card or an
    application, wherein, assuming the integrity of the keyboard
    used to authenticate the rightful user of said SAM/SC, and
    which can be used to activate the SAM/SC.
    PIX Proprietary Application Identifier Extension- In a
    proprietary approved EMV application, an extension to the AID
    giving parameters necessary to regulate the application.
    PKC public Key Cryptography - One of asymmetric message systems
    using integrity methods with public-private key pairs, e.g.,
    RSA, D-H, DSS, El Gamal, Schnorr, Fiat Shamir, etc.
    PM Parking Meter. (See OPM - former alias) A device used by
    public authorities to regulate parking times commensurate to
    the AMT which a SC grants to the meter.
    PM_INC(I) The price of a time increment in a service tariff table, e.g.
    the tariff for parking in a parking space reserved for
    load/unload for the zero'th 15 minute increment might be
    $.10, whereas in the tenth thirty minute increment might be
    $40.
    POS Point of Service - A terminal, capable of performing a
    transaction on a smart card, in exchange for a service.
    Proprietary Encryption Method- Usually a symmetric encryption
    method wherein the user assumes added security because of the
    adversary's ignorance of the method. Generally considered
    dangerous in an open system.
    PSA Payment System Application
    PSE Payment System Environment - A smart card based payment
    system environment, including POS, terminals, etc.
    PT Command to Perform Transaction followed by Terminal
    Certificate on Data (SCOS++)
    PTICKET Printed Ticket - A paper travel voucher purchased with AMT of
    $CASH issued by a TIM. The driver's OPM's CCR is reduced by
    AMT as it purchases the voucher from the TIM (or the
    parametric printer's SAM/SC).
    PTR Portable Ticket Reader- Inspector's tool to confirm proper
    procedure and one to one agreement between moneys received,
    tickets issued, credit for cash receivables reduced, and
    validity of passenger's proof of payment.
    PTS protocol Type Selection
    Purse- In the SCOS++ operating system, a secured purse
    consists of public key protected files encapsuled within a
    secured silicon architecture. An SCOS++ purse can only be
    loaded with value by another purse, wherein the value held in
    the donor purse is decremented, and the value held in the
    recipient's purse is incremented.
    A purse with proper entitlement can be loaded by a valid
    donor purse using one or more of the three mechanisms; as
    on-line purse to purse transaction; a cheque for credit for
    value ($CASH or ECASH) receivables possibly sent to a mailbox
    over an open, interceptable channel; a receipt signed by a
    system recognized repository (a bank). Entitlement is subject
    to system strategy, e.g., in a preferred strategy only an
    accountant can convert RRs to CCRs in his SAM; similarly only
    Depot Managers and Treasurers and Cashflow Managers are
    entitled to request and receive CCCRs.
    Purse to purse transactions- Purse to purse transactions are
    performed generally between two $CASH purses in SAMs, linked
    through what may be a dumb terminal. In a $CASH purse to
    purse process, a very rigorous mutual authentication
    negotiation is executed with public key signed challenges and
    responses and confirmations, assuring that one purse is not
    charged and another not made beneficiary unless the
    negotiation procedure has been executed properly and in its
    entirety.
    PV Private (Secret) Key in PKC used for Signature SFI(•) and
    Decryption (RSA)
    PVV PIN Verification Value- A transformation of the PIN value
    enabling the system operator to verify the validity of the
    PIN, without broadcasting a client or system secret PIN in
    the clear over an open channel.
    RAM Random Access Memory- Memory which be specifically addressed,
    then written to (changed) or read from with relatively fast
    access time (10 to 150 ns).
    R-APDU Response APDU- Response of Data and Status from the Transport
    to the Application layer.
    R-Block Receive Ready Block- A T = 1 signal.
    RCCCR Request for a Cheque for Credit for Cash Receivables- the
    token generated by a potential receiver of a CCCR's SAM/SC to
    enable the SAM/SC to accept a single cheque from a designated
    source, assuring the writer of the CCCR that the cheque can
    and will be used to credit the receiver's CCR once, and only
    once.
    Remote (Terminal) - A terminal device which does not normally
    communicate with a central host computer.
    RECB A receipt from B, probably the bank who is not a fully
    participating actor in the system, proved by the signature
    on an RR and relevant data attesting to AMT of $CASH having
    been deposited in a receptory (a bank or a clearing
    organization). Only entitled recipients can convert the AMT
    in a REC into CCR. The mechanism is similar to “cashing” a
    CCCR.
    RF Radio Frequency Communication. An option for allowing
    dispersed not otherwise communicating devices, to go on-line
    to a central node for reconciliation, downloading CRLs, for
    uploading transactions, etc.
    RFU Reserved for Future Use
    RID Registered Application Provider Identifier- 5 bytes which
    uniquely identify an application provider.
    RN or RND Random Number, unpredictable number (sequence of 1 and 0
    bits), physically generated and computationally randomized.
    RNG Random Number Generator. preferably a Real Random Number
    Generator which generates a completely unpredictable number
    under all conditions.
    ROM Read Only Memory- non-volatile immutable memory, that can be
    read from, but not written to.
    RPA Request Purse Account - to ICC to supply an AC, which
    includes present status of account, type of transaction
    willing to perform, and an RN, generated by the ICC (SCOS++).
    RRXY Request for Receipt. X requests an electronic receipt from Y.
    This assumes that X has the authority to convert a receipt
    into an increment to X's CCR or CAR.
    This function is typically used by accountants who reconcile
    receipts with accounting statistics and transfer CCRs to a
    company treasurer whose duty is to send CCCRs to dispersed
    $CASH collectors.
    This signed request for receipt typically includes proof of
    X's belonging to the system, and data issued by X's SAM/SC
    which will enable to convert said receipt once, and only once
    into CCR or CAR (CxR).
    RSA Rivest-Shalnir-Adelman Method - most flexible and de facto
    standard PKC - for electronic en/decryption, key exchange and
    document signature.
    RS485 See Standard Serial Communication.
    RST Reset - A software or hardware triggered initialization,
    which erases sensitive data and forces the system into a safe
    starting procedure.
    RTC Real Time Clock - A vital component in a secured system to
    attest to the time that a transaction is performed.
    R-TPDU Response TPDU- Response received by the terminal transport
    layer from an ICC.
    SAD Source Node Address- In T = 1, that part of the NAD which
    indicates the source of a block of data.
    SAM Secure Access Module- A Motorola SC49 or CF54, for example,
    can be embedded in a smart card, or the security module in a
    larger computing device.
    S-Block Supervisory Block- In T = 1, used to send control blocks.
    SC, SCx. Smart Card or SAM. Subscript x signifies SC or SAM belonging
    to x.
    SC1, SC2 In a specific scheme, SC1 generally defines the granter of
    value, SC2 the acceptor of value.
    SCA Certification Authority Private Key.
    Script - in EMV nomenclature, a sequence of commands coupled
    with data to be conveyed by the terminal to the ICC without
    interpretation.
    Secured ICC architecture - a monolithic silicon
    cryptocomputer, essentially characterized to disallow
    illicitly invasion, with a virtually inviolate internal bus,
    no test points, hardware to disable running at low speeds
    (less than 0.5 mhz), insuring a block erase of EEPROM when top
    metal layer is scratched, etc.
    SFI Short File Identifier- A unique 5 bit number used to access
    an SF within the same application or directory.
    SI Issuer's Private Key- The Secret (only RSA in present EMV
    specs) key used by the issuer to sign certificates of
    participants in the Issuer's applications.
    SIC ICC's Private Key- The Secret key (RSA in EMV) embedded in
    the EEPROM. In the “off the shelf” SCOS+, ICCs, this key is
    generated by the card, within the card, and is in a secured
    section of the ESPROM, accessed only by the proprletary
    library.
    Signature - Computational transformation on a message using a
    signer's private key, proving document integrity and
    liability of signer to unalterable contents. EMV authorize
    the RSA method for signatures. Usually part of a signature is
    composed of a hash on large quantities of data, to enable a
    single signature to prove integrity of more than one block of
    data. See SHA1, DSA, and RSA.
    SHA1 NIST's Secured Hash Method - a very strong one way function
    to transform a long data string into a 160 binary bit
    sequence for signing with the DSA or other signature methods.
    (Second rendition, first was designated SHA).
    Standard Serial Communication - B0485 - A multidrop noise
    resistant network standard, often used for in situ automotive
    peripheral communication.
    Static Data Authentication - Off-line asymmetric PKC
    authentication of certificates as opposed to dynamic data
    authentication, wherein both prove their identities and can
    prove integrity of messages.
    SSC System Smart Card - In a system wherein $CASH flow is
    protected using CCRs, a SSC is a card or SAM held by
    employees of the system which are entitled to accept cash in
    return for CCRs. When an SSC accepts $CASH or writes a cheque
    for credit for cash receivables; its CCR is decremented by
    AMT if it received $CASH; its CCR is incremented by AMT if it
    bestows $CASH. When an SSC loads a Consumer's Smart Card with
    electronic cash, the SSC's CCR is decremented and the CSC's
    electronic purse is incremented with electronic cash.
    Electronic cash ordinarily, cannot be transformed, off-line,
    back into CCR. See CSC.
    SW1,SW2 Status Words - Returned by the card, to indicate command
    termination status.
    String - A sequence of ones and zeros.
    Sweethearting - A state of collusion where a service or goods
    provider conspires to defraud his employer while charging a
    lower than proper AMT.
    Sxx(•) xx's PKC signature on the value in parentheses. If the data
    in the parentheses is longer than the modulus of the signer's
    (certifier of validity) modulus, then it is assumed that
    either the data is signed in parts, or, preferably, the data
    is transmitted separately, then hashed, and the signature is
    then performed on the hashed value, and/or on the hashed
    value and a part of the data that is transmitted along with
    Sxx.
    T Transaction Type - designation of credit/debit, secured/free
    access balance, cashback, or lock application.
    T = 0 The original ISO byte oriented single user protocol for data
    transmission between a contact smart card and a terminal.
    T = 1 The advanced ISO packet oriented multi-user protocol for data
    transmission between several smart cards and a terminal.
    Tachometer/graph- a device measures and charts the speed of
    a vehicle as a function of time.
    TAL Terminal Application Layer- an application program running on
    the terminal using the TTL to communicate with the ICC.
    TC Transaction Certificate - a “Signed Cheque”.
    TCK Check Character
    TCLKX A time measuring device used to measure the incrementing
    period of X's parking. (measured from time X inserts SC in
    PM).
    TDOL Transaction Certification Data Object List
    Tear Protection - A backup firmware methodology to prevent or
    compensate for illicit or unintentional interruption of a
    transaction procedure.
    TIM Ticket Issuing Machine- A cryptocomputer regulated device
    that controls money collection, ticket issuing and
    collection, controls access to vehicle, and collects
    transaction and automotive data relevant to a payment
    collection operation.
    Time Stamp - That part of a certificate which testifies to
    the time of signature on a string of data.
    TLV Tag-Length-Value - Data object structure definition,
    preferably according to ISO Basic Encoding Rules.
    TPDU Transport Protocol Data Unit- The data unit sent by the ICC
    to the terminal to regulate communication.
    TPMP Temporary Purse in Parking Meter- A purse which receives the
    client's parking deposit and dispenses increments to the
    account's receivable while client's car is parked; holding
    the client's unspent ECASH; If the “unspent” surplus is
    returned to the client's smart card when the client retrieves
    his vehicle; the unspent portion or part therof increments
    (is returned to) the client's ECASH purse, any other
    remainder increments the accounts receivable and decrements
    the entitlement contained in the CAR.
    Trace - A service giver/terminal's ID string (8 bytes).
    Trans. Transaction - A negotiated transmission of data.
    TSI Transaction Status Information - A present assessment of
    negotiated information.
    Transaction Velocity Check - An method that decides to
    perform the transaction on-line or continue off-line,
    dependent on several risk assessment variables.
    TTL Terminal Transport Layer- manages the command/response pair
    transmission sequence between an ICC and a Terminal. Receives
    an APDU from the TAL and sends a TPDU to the IC.
    TVR Terminal Verification Results - A bit mask, managed by the
    terminals containing the status of the card verification
    process.
    UDK Unique DEA Key - A secret random key, unique to a DES
    process.
    Validator- In the mass transportation scenario, a Smart Card
    accepting device to collect value from a multi-ride ticket
    purse, and for allowing cardholders to read last
    transactions.
    var. Variable - A data string whose value can be changed by
    authorized members of a defined cryptographic community.
    Verification - Generally the check performed by a
    cryptocomputer, to ascertain the values contained in a signed
    transaction certificate.
    V.I.P. VisaNet Integrated Payment
    Warden- An inspector whose duty is to inspect violations and
    failures in a service system (parking meters), and in those
    systems which cannot communicate on-line to a central
    database, to download data and CRLs, and transfer transaction
    data for central clearance.
    YDDD Year, Day (‘Y’ = Rightmost digit of the year (0-9). ‘D’ = Day
    of the year (1-366))- A two byte hexadecimal representation
    of date.
    YYMMDD Year, Month, Day - A three byte hexadecimal representation of
    a date.
  • Reference is now made to FIG. 1 which is a simplified block diagram of a payment collection system useful for a transportation network, the system being constructed and operative in accordance with a preferred embodiment of the present invention. [0113]
  • The system of FIG. 1 includes a population of [0114] travelers 10 and a population of transportation service providers 20. Each transportation service provider is equipped with an “OPM” or operator's personal module. The OPM includes an electronic purse which stores the transportation service provider's current entitlement to collect physical cash payment from travelers. The electronic purse is preferably public key signature protected.
  • Each transportation service provider, also termed herein a “driver”, is operative to perform transactions, each of which includes: [0115]
  • a. receiving physical money from a traveler; [0116]
  • b. in return, providing an electronic or paper ticket to the traveler or loading the traveler's smart card, all in proportion to the amount of physical money received; and [0117]
  • c. Debiting his own electronic purse to reflect the value of the ticket issued or the amount of value loaded into the traveler's smart card. [0118]
  • A preferred feature of the driver's OPM is that (c) is performed automatically once (b) is initiated by the driver. [0119]
  • The [0120] population 10 of travelers includes one, some or all of the following types of travelers:
  • a. a first type of travelers who interact with the [0121] transportation service providers 20 by transferring physical money, also termed herein “$cash”, to the service providers 20 and receiving a paper ticket therefrom in return.
  • b. a second type of travelers who interact with the [0122] transportation service providers 20 by transferring physical money to the service providers 20 and, in return, having their smart cards loaded with electronic cash by the transportation service providers;
  • c. a third type of travelers who interact with the [0123] transportation service providers 20 by transferring physical money to the service providers 20 a receiving electronic tickets therefrom in return.
  • The system of FIG. 1 also includes a population of [0124] depot treasurers 60 each equipped with an “OPM” or operator's personal module. The OPM includes an electronic purse which stores the depot treasurer's current entitlement to collect physical cash payment from drivers. The electronic purse is preferably public key signature protected.
  • Each depot treasurer is operative to perform transactions, each of which includes: [0125]
  • a. receiving physical money from a driver; [0126]
  • b. in return, incrementing the driver's electronic purse, in proportion to the amount of physical money received from the driver; and [0127]
  • c. Debiting his own electronic purse to reflect the increment to the driver's electronic purse. [0128]
  • A particular feature of the depot treasurer's OPM is that (c) is performed automatically once (b) is initiated by the depot treasurer. [0129]
  • Optionally, some or all of the drivers do not interact directly with depot treasurers but rather via an intermediate entity known as a “branch cashier”. [0130]
  • The system of FIG. 1 also preferably includes a population of [0131] depot managers 70 which serve as a buffer, each of which is equipped with a smart card or an OPM. The manager's OPM or smart card includes an electronic purse which stores the depot manager's current entitlement to lend physical cash payment collection entitlement to treasurers. The electronic purse is preferably public key signature protected.
  • Each depot manager is operative to perform transactions, each of which includes: [0132]
  • a. incrementing a depot treasurer's electronic purse; and [0133]
  • b. debiting his own electronic purse to reflect the increment to the treasurer's electronic purse. [0134]
  • A particular feature of the depot manager's OPM or smart card is that (b) is performed automatically once (a) is initiated by the depot treasurer. [0135]
  • If the system includes depot managers, the OPM of each depot treasurer associated with a depot manager is also operative to perform the above type of transaction, so that a depot treasurer is able to return to his depot manager payment collection entitlement which the manager previously lent to the treasurer. [0136]
  • The system of FIG. 1 also includes a population of [0137] local banks 80 each equipped with a smart card and an associated computer. The smart card is preferably public key signature protected.
  • Each local bank is operative to perform transactions, each of which includes: [0138]
  • a. receiving physical money from a depot treasurer; [0139]
  • b. electronically signing an electronic document provided and signed by the depot treasurer. The electronic document indicates the sum total of physical cash payment collection entitlements which the depot treasurer dispensed to drivers since he last interacted with the local bank. Except for human error or system malfunction, this sum total is the exact amount of physical money transferred in step (a). [0140]
  • The electronic document also includes a request for a receipt (RR) and a request for a cheque for credit for cash receivables (RCCCR). A preferred embodiment of these requests and their operation is described in detail above. [0141]
  • The local bank's signature includes an indication of the amount of physical money received. It is in the interest of the depot treasurer and the local bank personnel to communicate in the event that the indication of the amount of physical money received differs from the sum total included in the electronic document, e.g. due to human error on the part of the local bank personnel. [0142]
  • The electronic document provided by the [0143] depot treasurer 60 and signed by the local bank 80 is transmitted to a central accountant 90 equipped with a security module. The electronic document includes a token which enables only the security module of the central accountant 90 to convert, exactly once, the amount specified in the electronic document, into credit for cash receivables of the same amount. The term “credit for cash receivables” refers to entitlement to collect a certain amount of physical cash payment.
  • Periodically such as daily, or upon demand, the [0144] central accountant 90 prepares and signs an electronic cheque for credit for cash receivables for the amount specified in the electronic document. This cheque, termed herein the “accountant-to-manager cheque”, is transmitted to a cash flow manager 100 equipped with a security module. The central accountant 90 also prepares, for each of the depots, an electronic cheque. The electronic cheques for the depots, also termed herein “depot cheques” or CCCRs (cheques for credit for cash receivables) are transmitted to and signed by the cash flow manager 100. Each depot cheque typically includes the following:
  • a. A numbered request, signed by [0145] accountant 90, for a receipt;
  • b. A numbered request, signed by [0146] depot entity 60 or 70, for a cheque;
  • c. The amount of the cheque. [0147]
  • In FIG. 1, a “cheque”, drawn to a certain amount, means an entitlement granted to the beneficiary of the cheque to collect exactly that amount of physical cash payment. This entitlement, also termed herein “credit for cash receivables”, is transferable exactly once from the donor of the cheque to the recipient thereof. [0148]
  • After having received the unsigned depot cheques, the cash flow manager signs these cheques electronically, and transmits them to the appropriate depots. Typically, the cheques are sent via an [0149] electronic mailbox 110 to either the depot manager or the depot treasurer.
  • Each of the entities in FIG. 1 has a security application module (SAM). Some of these SAMs are operative to receive cheques, typically the SAMs of each of the following entities: [0150] Depot manager 70, depot treasurer 60, cash flow manager 100.
  • Each SAM is operative to prevent the entity with which it is associated from converting a cheque to credit for cash receivables, more than once. This is done by generating a sequence of non-repeating cheque identification numbers, e.g. by means of a counter, and storing these numbers in its public key secured non-volatile memory. The non-repeating cheque identification numbers prevent repeated use of a single cheque, thereby ensuring entitlement, exactly once, to the exact amount on the cheque, as described in detail below with reference to FIGS. [0151] 4-5.
  • A preferred feature of the present invention is that although the electronic cheques are typically transmitted over open channels and therefore can be copied freely, nonetheless the electronic cheques can only be used (i.e. converted to credit for cash receivables) once and only by their intended beneficiary. This feature is preferably implemented by “freezing” a protocol which ensures only a single use of cheques by only their intended beneficiary such as one of the protocols shown and described herein. The protocol is typically “frozen” within a secured externally immutable non-volatile memory of a SAM which includes a monolithic (i.e. single-chip) public key protected cryptocomputer. The protocol typically includes the following rules: [0152]
  • a. A cheque cannot be received unless it has been requested. Each request includes an index or other unique number, generated by the monolithic public key protected cryptocomputer so as to be different from the identification numbers of all previous requests. The mechanism in the cryptocomputer which generates these indices or other unique numbers is also termed herein an ATC (application transaction counter). [0153]
  • b. A cheque includes the index of the request for that cheque. The cheque reaches its intended recipient signed, and therefore, the intended recipient cannot tamper with the index. [0154]
  • c. When a cheque has been used, the cryptocomputer notes this, e.g. by storing a “used” indication in association with the index of that cheque or by deleting the cheque's index from memory. [0155]
  • d. A cheque which has been received cannot be used if a “used” indication is stored in association with its index. [0156]
  • Similarly, although the electronic receipts are typically transmitted over open channels and therefore can be copied freely, nonetheless the electronic receipts can be used by the central accountant [0157] 90 (i.e. converted to credit for cash receivables) only once. This feature is preferably implemented by “freezing” a protocol which ensures only a single use of receipts. The protocol is typically “frozen” within the central accountant's SAM which includes a monolithic (i.e. single-chip) public key protected cryptocomputer. The protocol typically includes the following rules:
  • a. A receipt cannot be received unless it has been requested. Each request includes an index or other unique number, generated by the monolithic public key protected cryptocomputer so as to be different from the identification numbers of all previous requests. The mechanism in the cryptocomputer which generates these indices or other unique numbers is also termed herein an ATC (application transaction counter). [0158]
  • b. A receipt includes the index of the request for that receipt. The receipt reaches its intended recipient signed, and therefore, the intended recipient cannot tamper with the index. [0159]
  • c. When a receipt has been used, the cryptocomputer stores a “used” indication in association with the index of that receipt. [0160]
  • d. A receipt which has been received cannot be used if a “used” indication is stored in association with its index. [0161]
  • In FIG. 1, credit for cash receivables, i.e. entitlement to receive physical cash, is transferred, in normal steady state operation in a cycle, from the [0162] central accountant 90, to the cash flow manager 100, to the depot treasurer 60 and/or manager 70, to the drivers 20. The drivers' entitlement to receive physical cash is reduced to the extent that they receive actual physical cash but is restored by the depot treasurer in return for transferring the physical cash to the depot treasurer 60. The depot treasurer's now depleted entitlement is eventually restored by the cash flow manager 100, once the depot treasurer 60 has deposited the physical cash he received from the drivers in the bank 80 and once that physical cash has merited the central accountant with a receipt which in turn merits the cash flow manager to receive renewed entitlement to receive physical cash.
  • Entitlement to receive physical cash, also termed herein credit for cash receivables, is typically injected into the system of FIG. 1 initially and upon occasion, by an [0163] external source 120. Preferably, the interface between the external source 120 and the central accountant 90 is secured by a portion of the protocol of the central accountant's SAM which only accepts cheques which are multi-signed. In addition, the uniqueness of the interface is preferably maintained by a portion of the protocols of all SAMs other than the central accountant's which portion rejects input from the external source.
  • Typically, each bus is equipped with a ticket issuing machine (TIM) and each operator (driver) is equipped with a portable personal module (OPM). Each OPM or operator's personal module typically includes a SAM (security application module) which stores the operator's electronic purse, a memory, a CPU and a real time clock. [0164]
  • The operations of the OPM and the TIM are as follows: [0165]
  • a. The TIM is operative to load up a traveler's smart card in response to a driver's actuation. Typically, the driver actuates the TIM to do this in return for receiving X dollars of physical cash. The OPM records the driver's usage of the TIM by decrementing the driver's entitlement to receive cash by X dollars as the driver actuates loading up of a traveler's smart card by X dollars and incrementing the TIM's electronic purse by the same amount. [0166]
  • b. The TIM is operative to issue a paper ticket in response to a driver's actuation. Typically, the driver actuates the TIM to do this in return for receiving the price of the paper ticket from the traveler. The OPM records the driver's usage of the TIM by decrementing the driver's entitlement to receive cash by the price of the paper ticket and incrementing the TIM's electronic purse by the same amount. [0167]
  • c. The TIM is operative to issue multiple or free pass tickets in response to a driver's actuation. Typically, the driver actuates the TIM to do this in return for receiving the price of the desired ticket. The OPM records the driver's usage of the TIM by decrementing the driver's entitlement to receive cash by the price of the desired tickets as the driver actuates loading up of a traveler's smart card by the same price and incrementing the TIM's electronic purse by the same amount. [0168]
  • d. The TIM is operative to decrement a traveler's smart card, in response to insertion of the smart card into the TIM. The smart card may be a card issued by the transportation system, or may be an “external” card such as a conventional credit card. Typically, the driver inputs into the TIM an indication of the nature and/or price of goods or services which the traveler wishes to purchase. The TIM's electronic purse is incremented by the same amount that the traveler's smart card's electronic purse is decremented. [0169]
  • e. The TIM is operative to decrement a traveler's multiple-ride transportation pass, entitling the traveler to a specific amount of transportation service, such as a specific number of rides, in response to insertion of the pass into the TIM. Typically, the driver inputs into the TIM an indication of the nature of transportation services which the traveler wishes to purchase. The TIM's electronic purse is incremented, and the traveler's pass is decremented, by the cost of the service being purchased. [0170]
  • f. The TIM is operative to decrement a traveler's free travel transportation pass, entitling the traveler to an unlimited amount of transportation service, in response to insertion of the pass into the TIM. Preferably, the TIM's electronic purse is incremented, and the traveler's pass is decremented, by a very small sum such that even if the traveler heavily utilizes his pass, nonetheless the pass's electronic purse will not be decremented totally to zero within the time period for which the pass is valid. [0171]
  • FIG. 2 is a simplified flowchart illustration of a method for performing a purse-to-purse transaction between two operator personal modules (OPMs) of FIG. 1 such as between a driver's OPM and a depot treasurer's OPM or such as between a depot treasurer's OPM and a depot manager's OPM. A purse-to-purse transaction is a transaction between two public-key signature secured electronic purses in which value X is transferred from one of the purses to the other, resulting in an decrement of X dollars to the first purse and an increment of X dollars to the second purse. [0172]
  • The transaction illustrated in FIG. 2 takes place between two smart cards or SAMs, SC[0173] 1 and SC2, and is performed by a terminal having one or more smart card readers. A value designated AMT (amount) is transferred from SC1 to SC2. The transaction initiates with a challenge by SC1 which comprises a random number transmitted to the terminal (step 210). If the receiving smart card SC2 agrees to accept the value being transferred from the donor smart card SC1 (step 220), then precautions are preferably taken to make sure that SC1 is not double-charged. Specifically, SC2 signs and transmits to SC1 a payment request, also termed herein an “RCCCR” (request for cheque for credit for cash receivables) (steps 230 and 240).
  • If the donor smart card SC[0174] 1 agrees to comply with the payment request, then SC1 stores the transaction data which appears in the payment request (step 260). SC1 then signs and sends to SC2 a cheque for credit for cash receivables, typically for the amount requested by SC2 (step 264). SC2 receives the cheque (step 266, described in detail below with reference to FIG. 4).
  • Upon receipt of the cheque, SC[0175] 2 signs and sends to SC1 a receipt therefor (step 270).
  • FIG. 3 is a simplified flowchart illustration of a method for canceling the purse-to-purse transaction of FIG. 2 if the purse-to-purse transaction failed. e.g. that the “end of session” step in FIG. 2 was not reached or [0176]
  • As in FIG. 2, SC[0177] 1 is the donor smart card and SC2 is the intended receiving smart card which does not, in fact, receive any value from SC1 due to failure of the transaction. The terminal may detect that a transaction failed in step 310 in one, some or all of the following ways:
  • a. The terminal has programmed time limits for response for each of the steps performed by one or other of the smart cards and if these time limits are exceeded, i.e. if either of the smart cards fails to perform on time, the terminal assumes that the transaction has failed; [0178]
  • b. The terminal has a programmed time limit for the “end of session” [0179] step 274 of FIG. 2. If the session does not terminate within this time limit, the terminal assumes the transaction has failed; and/or
  • c. The terminal is equipped with microswitches which sense if a card has been removed from the terminal while a transaction is in process. [0180]
  • FIG. 4 is a simplified flowchart illustration of a preferred method by which a receiving smart card, SC[0181] 2, performs the cheque receiving step 266 of FIG. 2. The embodiment of FIG. 4 is suited for applications in which the cheque for credit for cash receivables (CCCR) is sent without third party clearance. When the method of FIG. 4 is embedded in silicon as externally immutable protocol in public-key signature protected non-volatile memory, third party clearance is not required because the embedded method ensures that the cheque will not be honored more than once.
  • To ensure that the cheque is not honored more than once, the method of FIG. 4 maintains a binary cheque token within each signed cheque which is maintained as valid until the cheque is honored at which point (step [0182] 440) the token is invalidated. The cheque is only honored if (step 420) the cheque token is still valid. The binary cheque token is also termed herein an ATC (application transaction counter).
  • Reference is now made to FIG. 5 which is a simplified flowchart illustration of a transaction cycle performed by the various elements of FIG. 1. [0183]
  • In [0184] step 470, each local bank 80 receives a deposit slip as described above with reference to FIG. 1.
  • In [0185] step 480, the bank 80 may send the central accountant 90 clear redundant data which facilitates authentication procedures, including reconciliation procedures, performed by the central accountant.
  • In [0186] step 490, SUM(AMTs) refers to the sum of amounts of all receipts received by the bank from a plurality of depots.
  • In [0187] step 500, the cash flow manager sends an RCCCR (request for accountant-manager cheque) to the central accountant 90. Preferably, the cash flow manager 100 also sends instructions regarding how to distribute CCRs to depots. For example, if a slow period is anticipated, the instructions may indicate that relatively little CCR should be distributed to the depots, whereas a relatively large amount of CCR may be distributed during the period that monthly passes are sold to travelers.
  • In [0188] step 510, the central accountant preferably performs reconciliation activities before sending an unsigned CCCR to the cash flow manager.
  • In [0189] step 520, the cash flow manager 70 increments his own balance of credit for cash receivables and then sends cheques for credit for cash receivables to all depots, preferably through electronic mailbox 110.
  • FIG. 5 is slightly different from the embodiment described below which is based on the software listing of Appendix A. [0190]
  • FIG. 6 is a simplified block diagram of a payment collection system constructed and operative in accordance with a preferred embodiment of the present invention which is operative to collect value from smart card bearers (clients) and to load electronic money into the clients'smart cards. The value collected from the clients typically includes physical cash ($Cash), and/or cash equivalents such as a cash advance from a credit card. [0191]
  • The system of FIG. 6 is characterized in that agents typically provide advance payment to management for entitlements to collect cash, rather than the agents receiving entitlement to collect cash without paying for it, and turning in collected cash to management only after it is received. In the embodiment of FIG. 6, the management typically benefits from the float, whereas in the embodiment of FIGS. [0192] 1-5 the service providers who collect the cash from the customers and other intermediaries typically benefit from the float.
  • Each of the following elements is equipped with a SAM: [0193] management 550, operator accountant 560, the operator treasurer 570, the bank 580, the agent 590, and the client's smart card 600.
  • As shown, the [0194] operator treasurer 570 preferably provides the agent 590, such as the fuel station or lottery kiosk, a cheque for credit for cash receivables whose value preferably exceeds the total amount provided to the bank 580 by the agent 590 in the previous transaction cycle. Typically, the value exceeds the total amount by a predetermined margin which compensates the entities which handle the cash.
  • As a result of the discrepancy between the size of the cheque given out and the amount of value collected, it is necessary for [0195] management 550 to periodically inject CCR into the system, where CCR refers to an additional entitlement to collect cash. To do this, the management generates a cheque for credit for cash receivables (CCCR) in response to receiving a request therefor.
  • The embodiment of FIG. 6 is suitable for a wide variety of applications. The population of agents may, for example, comprise any of the following: a population of loading electric meter smart cards, a population of lottery ticket sales points, a population of fuel stations, a population of transportation service providers, and a population of parking meter ticket reloaders. [0196]
  • FIGS. [0197] 7-13 illustrate the operation of an electronic value collection device which is operative to collect payment for services rendered or products provided and is also “multi-application” in that it enables value to be transferred between electronic value storing devices such as electronic purses, or electronic credit or debit accounts.
  • FIG. 7 is a simplified flowchart illustration of a method for unloading electronic money from a client's smart card. The implementation of FIG. 7 is, for example, suitable for an interaction between a client's smart card ([0198] 600 of FIG. 6) and a parking meter in which the parking meter unloads electronic cash from the client's smart card.
  • In [0199] step 620, the parking meter or other device for unloading electronic money waits for a smart card to be inserted Once the smart card has been detected, the meter checks itself to determine its present credit for accounts receivable. If (step 630) its present credit for accounts receivable is lower than a predetermined threshold such as 10% of its maximum entitlement CAR_MAX, then (step 640) the meter typically summons a warden, e.g. by means of an RF (radio frequency) signal, if the warden can be summoned by an RF receiver. The meter then continues to step 650.
  • If the present credit for accounts receivable is not greater than zero, the method terminates (step [0200] 660), because the meter is not operative until the warden unloads the history of all transactions performed by the meter and restores his credit for accounts receivable, typically to CAR_MAX level.
  • If the present credit for accounts receivable is positive, then (step [0201] 670) the parking meter preferably records the time of day, the user preferably enters user-identifying information such as his license plate number, the meter displays the balance of electronic cash possessed by the smart card inserted and/or the amount of parking time equivalent thereto.
  • According to a preferred embodiment of the present invention, the meter is operative to enable a user to accumulate a small over-draft, corresponding to a brief interval of time, also termed herein a grace period, during which the user can approach an electronic cash sales point and have his smart card, if empty or near empty, reloaded as described above with reference to FIG. 6. Alternatively, the reloading process may be performed by a conventional AIM (automatic teller machine). Typically, the grace period is charged at a higher rate than ordinary parking time. [0202]
  • In step [0203] 680, the meter generates a display prompting the user to indicate a desire to increment his balance of electronic cash. If the user indicates such a desire then (step 700) the user is prompted to indicate whether to increment his balance of electronic cash at the parking meter or at a remote location such as a human-operated or electronically operated electronic cash dispensing point.
  • If the user indicates a desire to increment his electronic cash balance “here”, then the parking meter increments his electronic cash balance (step [0204] 710) using any suitable method such as the method described below with reference to FIG. 11.
  • If the user indicates a desire to increment his electronic cash balance elsewhere, then (step [0205] 720), the parking meter starts a timer which is programmed to indicate a short grace period. The user removes his smart card and approaches an electronic cash dispensing point which dispenses electronic cash, preferably as described herein with reference to FIG. 6. The user then returns to the parking meter and re-inserts his card as described below with reference to FIG. 9.
  • If (step [0206] 680) the user indicates that he does not wish to increment his electronic cash balance then the parking meter merely debits the user's electronic cash balance as payment for the parking service which the user is about to avail himself of.
  • In [0207] step 730, the user is preferably prompted to indicate how much electronic cash value he wishes to be debited by. Preferably, the parking meter is configured to accept either of the following two user responses:
  • a. An indication that the user wishes to leave a deposit equivalent in value to an entire day's parking or [0208]
  • b. An indication of a value which the user wishes to be debited by. [0209]
  • Charging of that value (step [0210] 750) is performed as described below in FIGS. 8A-8B, following an initialization step 740.
  • FIG. 8A is a simplified flowchart illustration of a preferred method for performing the “charge for parking” [0211] step 750 of FIG. 7.
  • When a driver leaves electronic cash in the parking meter, this electronic cash is preferably stored in a temporary purse (also termed TPMP-temporary parking meter purse) and is preferably only used to increment the parking meter's accounts receivable as parking time is used in actual fact. Any electronic cash remaining in the temporary purse is returned to the driver's electronic cash purse when the driver returns and inserts his smart card into the parking meter, as described herein with reference to FIG. 9. [0212]
  • In [0213] step 810, the parking meter determines whether the balance of electronic cash left in its temporary purse by the driver is sufficient to completely pay for the next time-interval of parking in a predetermined sequence of parking time-intervals. FIG. 8B is a sample table storing two sequences of parking time-intervals. The parking meter can preferably be programmed to employ either of the two sequences. The first sequence is suitable for busy parking locations in which it is desired to strongly deter drivers from parking for periods longer than a few minutes. The second sequence is suitable for ordinary parking locations in which it is desired to only mildly deter drivers from parking for more than a few hours. For each parking time interval in each of the tables, the following information is stored: the length of the time interval, and the cost of parking during that time interval.
  • If the balance of electronic cash left by the driver is sufficient to completely pay for the next time-interval, the parking meter decrements the temporary purse accordingly (step [0214] 820). If the balance of electronic cash is not sufficient to completely pay for the next time interval, the temporary purse is zeroed and the amount of time which the temporary purse if capable of paying for is computed.
  • If the smart card is inserted at this point (step [0215] 840), the method of FIG. 9 is carried out to process this interrupt. Otherwise, the method continues to step 870 in which the parking meter determines by consulting its timer whether the present time interval has elapsed. If not, the method continues to wait for the driver's return or for the current parking time interval to elapse. If the present time interval has elapsed then (step 880) the parking meter determines whether the temporary purse is already empty. If not, the parking meter returns to step 810 and transfers from the temporary purse to its accounts receivable, the amount of value required to pay for the next parking time interval.
  • If the temporary purse is found to be empty, the parking meter calls the warden using its radio transmitter (step [0216] 890), preferably archives the transaction (step 900) and returns to the beginning of FIG. 7 to await the next driver's smart card.
  • FIG. 9 is a simplified flowchart illustration of a preferred method for performing the “process smart card insertion event” [0217] step 850 of FIG. 8A. The method of FIG. 9 preferably includes the following steps:
  • The parking meter compares the inserted smart card's ID number to the ID number of the currently-parking smart card to determine whether the smart card now inserted belongs to the currently parking vehicle or individual. If so, then the parking meter prompts the user to indicate whether or not he is leaving the parking area. [0218]
  • FIG. 10 is a simplified flowchart illustration of a preferred method of operation for a warden's SAM (security application module) once the warden has been summoned by the method of FIG. 7 to restore a parking meter's credit for cash receivables and to collect accounts receivable accumulated in the parking mater. by unloading particulars of all completed and suspended transactions. [0219]
  • In [0220] step 1100, the warden connects his OPM (operator personal module), which includes a SAM and a memory, to the parking meter.
  • In [0221] step 1110, all completed and suspended transactions are unloaded into the OPM's memory.
  • In [0222] step 1120, the difference between the parking meter's maximum entitlement to collect electro c cash in return for services rendered (maximum credit for accounts receivable—CAR_MAX) and between the parking meter's present balance of entitlement is compared to the sum of service transactions carried out by the parking meter since the parking meter was last accessed by a warden.
  • The term “service transactions” refers to transactions in which payment is made for services rendered or, in certain applications, for products received. Conversely, the term “value advance transactions” refers to transactions in which value is transferred between electronic value storing devices, such as between a multi-purpose credit card and a single-application electronic purse. [0223]
  • If these two electronic cash quantities are found to be equal, then (step [0224] 1130) the current balance is restored to, i.e. incremented to, CAR_MAX level, less the amount of electronic cash presently stored in the parking meter's temporary purse. The warden's entitlement to collect electronic cash, CAR_OPM, conversely, is decremented by the amount of account collection entitlement which was conferred on the parking meter.
  • If the comparison of [0225] step 1120 does not yield the expected equality, this is symptomatic of malfunctioning of the parking meter and the parking meter electronics is typically replaced (step 1140).
  • In [0226] step 1150, the warden's OPM then compares the sum of value advance transactions performed by the parking meter since it was last warden-accessed to the difference between the parking meter's maximum credit for cash receivable and between the parking meter's current balance of credit for cash receivable.
  • If the two quantities are equal, as expected, then (step [0227] 1160) the parking meter's current balance of credit for cash receivable is incremented to a predetermined maximum level. If the two quantities are not equal, the error is archived (step 1170). The method then returns to step 610 of FIG. 7.
  • FIG. 11 is a simplified flowchart illustration of a preferred method for incrementing the electronic cash balance of a user's card. The method of FIG. 11 preferably includes the following steps: [0228]
  • [0229] Step 1200—if the parking meter's credit for cash receivables has dropped below a predetermined threshold quantity, then (step 1210) the warden is summoned to access the parking meter, to collect the credit for cash receivables and subsequently restore the parking meter's credit for cash receivables to a predetermined maximum value.
  • [0230] Step 1220—If the parking meter's entitlement to collect electronic cash is no longer positive, the transaction is refused (step 1224) and the method returns to step 610 in FIG. 7. If the parking meter's entitlement is positive,
  • [0231] Step 1240—the parking meter accepts electronic value equivalent, in the illustrated embodiment, to a full day's parking. Alternatively, of course, different electronic value equivalents, such as a user selected amount of electronic value, may be accepted.
  • [0232] Step 1250—Typically, at least one aspect of the transaction is investigated such as the legitimacy of the user's signature as received by the parking meter, or the credit status of the user. If the investigated aspect/s of the transaction are not approved, the method returns to step 610 of FIG. 7. If the investigated aspect/s of the transaction are approved, the parking meter accepts the amount of payment provided by the user, lowers its own credit for cash receivables by the same amount, and archives a record of the transaction (step 1270). The method then returns to step 740 of FIG. 7.
  • FIG. 12 is a pictorial diagram illustrating the flow of electronic value between a user's smart card/s [0233] 1300, a parking meter's SAM 1310 and a parking warden's OPM 1320. A minus sign associated with a vertical arrow head adjacent a particular electronic value holding device indicates that that device is decremented by a particular electronic value quantity and the electronic value holding device at the base of the same vertical arrow is incremented by the same amount. Conversely, a plus sign associated with a vertical arrow head adjacent a particular electronic value holding device indicates that that device is incremented by a particular electronic value quantity and the electronic value holding device at the base of the same vertical arrow is decremented by the same amount.
  • It is appreciated that the [0234] credit card application 1324 and electronic cash application 1328 may reside on a single smart card or on different smart cards which typically are owned by a single owner.
  • Horizontal arrows whose head is associated with a minus sign indicate that, concurrently with the transaction indicated by the vertical arrow which intersects the horizontal arrow's base, the electronic value holding device associated with the horizontal arrow's head is decremented. Conversely, horizontal arrows whose head is associated with a plus sign indicate that, concurrently with the transaction indicated by the vertical arrow which intersects the horizontal arrow's base, the electronic value holding device associated with the horizontal arrow's head is incremented. Electronic counters can be regarded as residing at the bases of the horizontal arrows in order to count electronic value passing through the vertical arrow intersecting with each horizontal arrow base, thereby to determine the quantity of electronic value by which the device at the horizontal arrow's head should be incremented or decremented. [0235]
  • FIG. 13 is a pictorial diagram illustrating a preferred flow of electronic value between a parking warden's [0236] OPM 1320, a parking meter operator 1330, and a purse operator 1340. The significance of horizontal arrows and vertical arrows, plus and minus signs are as described above with reference to FIG. 12.
  • It is appreciated that the warden need not be a human operating a SAM who is summoned by means of an RF transmitter. Alternatively, the transactions described herein may be performed by a central electronic warden using any suitable means of communication such as RF communication. [0237]
  • A preferred feature of the present invention is that each of the methods and devices of FIGS. [0238] 1-13 are embedded in silicon as externally immutable protocol in public-key signature protected non-volatile memory. Conventional secured silicon architectures include the following integrated circuits: Motorola SC29, Motorola SC49 and SGS-Thomson CF54. A preferred method for embedding the methods and devices of FIGS. 1-13 in silicon as externally immutable protocol in public-key signature protected non-volatile memory, is to use the SCAD developing system, marketed by Fortress U & T. Ltd., Beer Sheva, Israel, in conjunction with one of the above-mentioned integrated circuits in which is programmed the SCOS++ operating system.
  • A preferred method for manufacturing a safe payment collection system constructed and operative in accordance with a preferred embodiment of the present invention is based on Appendix A. [0239]
  • To implement the Transaction Terminal as here described, the following standard configuration of the SCAD may be employed: [0240]
  • A. ‘[0241] BestCRYPT 4 PC’ peripheral cards for each terminal configured with the SCAD Application Developer, each with two Amphenol 3.5″ smart card acceptors (catalog number C702)—Reader A and Reader B.
  • B. System owner smart card-an SGS-Thomson CF54 chip masked with the SCOS+ operating system configured with the SCAD Application Developer. SGS-Thomson CF54 chip masked with the SCOS+ operating system smart-cards, used for system operators and clients' smart-cards which are configured with the SCAD Application Developer. [0242]
  • C. The complete standard SCAD software module setup disks for the SGS-Thomson CF54 cryptocomputer chip which includes the optional SCAD Microsoft Visual Basic source module APPMODUL.BAS. [0243]
  • D. Appendix A contains source code listing and specifications for MS Visual Basic form object ‘PRFM_TRN.FRM’ useful for the Cashflow Terminal implementation. [0244]
  • Now, the correct address of the ‘[0245] BestCRYPT 4 PC’ peripheral card is set, and smart card acceptors are connected to it. See FIG. 14 for a general view of ‘BestCRYPT 4 PC’, commercially available from Fortress. SMARTCARD1-4 are the Smart-card reader connectors. Reader A should be attached to SMARTCARD1 and reader B to SMARTCARD2. Wires should point away from the ‘BestCRYPT 4 PC’ card, i.e., red wire on smart card reader cable, should be placed opposite to the battery (BAT). J5-J7 are the ,Address jumpers. All jumpers must be present to set an address. Each jumper can be positioned on an upper (‘0’) or lower (‘1’) position. There are eight different base addresses, in which the card may be installed, displayed in the following table:
    J7 J6 J5 Address
    0 0 0 200h (Factory setting)
    0 0 1 220h
    0 1 0 240h
    0 1 1 260h
    1 0 0 300h
    1 0 1 320h
    1 1 0 340h
    1 1 1 360h
  • To install the hardware correctly in a PC, the following steps may be performed: [0246]
  • a. Turn off the PC. [0247]
  • b. Disconnect the power cord from the PC. [0248]
  • c. Take off the cover of the PC, to provide easy access to the mother board. [0249]
  • d. Find a free [0250] 16 bit IDE slot, and plug the ‘BestCRYPT 4 PC’ card in. Use a screw to tighten the card. e. If necessary, set the desired address on the ‘BestCRYPT 4 PC’ card, using jumpers J5-J7,as presented above. The address should be set to the lowest address which does not interfere with other installed peripheral equipment on the PC.
  • f. Screw in the two smart card acceptors. Use the 5.25″ adapter, if necessary. [0251]
  • g. Connect the smart card acceptor cables to the ‘[0252] BestCRYPT 4 PC’ card, according to the instructions in the ‘Setting the hardware’ section.
  • h. To install the smart card readers; Install the smart card reader A in an upper floppy slot; and reader B in a lower floppy slot. [0253]
  • i. Cover the PC and connect the power cord. [0254]
  • j. Turn the PC on. Check if operation is normal. If not, or the PC speaker beeps more than once, when powered on, turn off the computer and refer to the ‘Trouble shooting’ section below. [0255]
  • Note: The ‘[0256] BestCRYPT 4 PC’ card contains a SAM (Security Application Module). The location of the SAM is shown on the view of ‘BestCRYPT 4 PC’ card of FIG. 14. The SAM is an important part of the system and its removal or modification may cause a system failure.
  • To install the software correctly in the PC: a. Activate Windows operating system version 3.11 or later on the PC. [0257]
  • b. Run SETUP.EXE from [0258] setup disk number 1.
  • c. Follow setup program instructions. [0259]
  • d. The installation directory may be modified if desired by the installer. [0260]
  • e. If Setup was not completed successfully refer to Trouble shooting section below. [0261]
  • f. The PRFM[0262] 13 TRN.FRM and APPMODUL.BAS specified previously are linked and compiled using the Microsoft Visual Basic development environment to create a single executable (.EXE) file named TRANSACTOR.EXE This generates a complete Transaction Terminal for controlling value flow.
  • g. The TRANSACTOR.EXE is run under Microsoft Windows version 3.11 or later by double clicking ‘TRANSACTOR.EXE’ in the Microsoft Windows File Manager. [0263]
  • Before the Transaction Terminal can be run, the system users are defined, i.e. the various system smart-cards are assigned their definitions. This is performed using the SCAD Application Developer modules. The SCAD Application Engine is used for creating the application definitions, and the SCAD Issuing Station enables the system manager to issue the smart-cards for the system, as described in FIG. 16. Once the smart-card is issued, it is a secured information environment subject to the application authorization and restriction, modified only if reissued by the system manager. [0264]
  • The User defined priority types used by the Transaction Terminal are: [0265]
  • Accountant [0266]
  • Cashflow Manager [0267]
  • Bank Teller [0268]
  • Depot Manager [0269]
  • Depot Treasurer [0270]
  • Branch Cashier [0271]
  • OPM [0272]
  • TIM [0273]
  • Client [0274]
  • A card not belonging to any of these users will not have access to any purse in the Transaction Terminal. Any SCAD Application defined with users from the list above will have access to the Transaction Terminal purses. [0275]
  • The system is initialized by entering an initial Cash for Credit Receivables amount, CCR, to the central accountant purse balance. This process can only be executed in the SCAD File Management work station by the system owner. Without this initialization, no CCR type credits exist within the system. [0276]
  • All transactions take place with smart-cards inserted in terminal readers, A and B. Transactions are governed by the SAM terminal and by predetermined external smart-cards SCOS authorizations. If the cards executing a transaction have no proper authorization, security or incompatibility errors occur; appropriate messages are sent to the terminal operator. The smart-card's details i.e. the user type, name, ID and validity dates are displayed during transaction execution. Execution takes place after the user selects the transaction type from the options once [Execute] is clicked. At the end of each transaction a message is sent containing success or failure information and current purse status details (balance) Any RR, RCCCR, Bank approval, or CCCR dispatched to the terminal can be viewed by entering the appropriate folder in the main transaction window, as shown in FIG. 15. [0277]
  • Credit for Cash Receivables: This command generates a purse to purse transaction which increments the CCR of the smart-card purse in reader B and decrements the CCR of the smart-card purse in reader A. After recipient and donor cards are inserted, the operator enters the amount to be transacted, donor gives $CASH to recipient, and the operator clicks [Execute] to perform the CCR transaction. The users' details are displayed on the screen, and if the users are properly authorized, the transaction takes place with a proper message. [0278]
  • Generate Request for CCCRs: This command generates a Request for a Cheque for Credit for Cash Receivables, RCCCR, and dispatches it. The operator inserts the recipient smart-card in reader A and enters the amount requested in the amount textbox. [0279]
  • Generate Request for receipt: This command generates a Request for Receipt, RR. RRs can be generated only by the central accountant and the card inserted in A is verified as such. If authorized the RR is formatted signed and dispatched. [0280]
  • RCCCR bank receipt: To approve a treasurer's “deposit slip” the bank teller's smart-card-must be inserted in reader A, after selecting the proper RR and RCCCR in the RR folder. The RR and RCCCR selected will be signed together and dispatched. The CCR amount sent with the approval is the amount entered in the amount textbox. [0281]
  • Accountant's converting deposit to CCRs: Accountant's card in A is credited with CCRs of all valid and dispatched bank approved RCCCRs (receipts). The card in A will be credited only if it is the central accountant card's and only with approvals not obsolete and not deposited previously. All deposited approvals are moved to the accountant's terminal for RCCCR dispatching to the cashflow manager. [0282]
  • Send Cheque (CCCR): To generate a CCCR, an RCCCR must first be selected from the RCCCR folder to be used as the destination for the CCCR. The C( of the cheque sender (the donor) in reader A is charged with the amount specified in the amount textbox, set by the sender of the cheque, and the cheque is dispatched. [0283]
  • Deposit Cheque (CCCR): The command to deposit a received CCCR. Deposit dispatched CCCR. User in reader A selects a dispatched CCCR from the CCCR folder. If authorized and if the cheque is valid, sent to the proper recipient, and contains a valid ATC; the user's purse is credited. [0284]
  • Trouble shooting: [0285]
  • 1. (Q) The available addresses on the PC are unknown. [0286]
  • (A) Check the other hardware that is currently installed on the PC. Make a list of the addresses other peripherals occupy, and find a free base address for the ‘[0287] BestCRYPT 4 PC’ card. If unable to list, try installing the ‘BestCRYPT 4 PC’ card, using the factory setting.
  • 2. (Q) During the installation process, a file sharing error has occurred (‘File already opened’ or ‘Can not access file’). [0288]
  • (A) The installation program can not access files that are being used by other applications. When installing the software, quit all open applications to avoid conflict, Then try installing the software again. [0289]
  • 3. (Q) The installation program declares that the ‘[0290] BestCRYPT 4 PC’ card was not found.
  • (A) This could be caused by several reasons: The card was not properly installed. The base address that was set by J[0291] 5-J7 is occupied by other hardware. The card is missing or damaged. Turn off the PC, take off the cover and check if the card is installed properly.
  • Refer to the answer to (1), and check if the address selected is free. [0292]
  • 4. (Q) When running the SCAD issuing station, or the SCAD file management work station, there is a ‘File not found’ message. [0293]
  • (A) This message indicates that the ‘[0294] BestCRYPT 4 PC’ card was not installed properly. Refer to previous answers for help.
  • 5. (Q) The SCAD is installed, but the application engine does not start. The error message says: “Application owner card not in A:”[0295]
  • (A) Check if the application owner card is inserted in reader A, and that it is properly inserted, i.e., gold contacts facing upwards. If this does not solve the problem, turn off the PC, take off the cover and check if you have connected the smart-card reader wires properly, as per hardware installation instructions. [0296]
  • 6. (Q) The SCAD has been installed, operated for a period of time, but suddenly causes problems involving the system clock. [0297]
  • (A) Try setting the system clock, using the application engine software and the application owner card, and then turn the computer off, turn it on and read the system clock setting. If the clock is reset when read, it means that the ‘[0298] BestCRYPT 4 PC’ card backup battery is discharged. In this case, replace it with a similar battery, or reset the clock when running the PC.
  • It is appreciated that the software components of the present invention may, if desired, be implemented in protected externally immutable ROM (read-only memory) form. The software components may, generally, be implemented in hardware, if desired, using conventional techniques. [0299]
  • It is appreciated that the particular embodiment described in the Appendices is intended only to provide an extremely detailed disclosure of the present invention and is not intended to be limiting. [0300]
  • It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination. [0301]
  • It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention is defined only by the claims that follow: [0302]

Claims (35)

1. A system for safe collection of payment in return for goods, values or services, the system comprising:
a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including:
a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted; and
a purse control unit operative to prevent said purse, off-line, from exceeding the credit for value receivable which it has been granted.
2. A system according to claim 1 wherein each of said purses includes a SAM (security application module).
3. A system according to claim 1 wherein each purse monitor is public-key protected.
4. A system according to claim 1 wherein each purse control unit is public-key protected.
5. A system for safe collection of payment in return for goods, values or services, the system comprising:
a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including:
a purse monitor operative to sign and authenticate a time-stamped transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted; and
a purse control unit operative to prevent said purse, off-line, from extending a credit for value receivable which it has been granted over more than a predetermined period of time.
6. A system according to claim 5 wherein said purse control unit operates off-line.
7. A public-key protected system for safe collection of payment in return for goods, values or services, the system comprising:
a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing, in public key protected form, an amount of credit for value receivable granted to the individual system element, each purse including:
a public-key protected purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted; and
a public-key protected purse control unit operative to prevent said purse, off-line, from exceeding the credit for value receivable which it has been granted.
8. A system for safe collection of payment in return for goods, values or services, the system comprising:
a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including:
a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted; and
a purse control unit operative to prevent said purse from exceeding the credit for value receivable which it has been granted,
wherein at least one first purse from among said multiplicity of purses includes a credit granting unit operative to grant an amount of credit for value receivable granted to at least one second purse from among said multiplicity of purses only in response to activation by a predetermined plurality of system directors.
9. A system for safe collection of payment in return for at least one of goods, values and services, the system comprising:
a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including:
a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted; and
a purse control unit operative to prevent said purse from exceeding the credit for value receivable which it has been granted,
wherein at least one first purse from among said multiplicity of purses includes a credit granting unit operative to grant an amount of credit for value receivable granted to at least one second purse from among said multiplicity of purses only in response to activation by at least one system director and operative to record information regarding the activation including the identity of said at least one system director.
10. Apparatus for transmitting electronic cheques over open channels, each cheque having an intended beneficiary, the apparatus comprising:
a cheque-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a cheque having an intended beneficiary;
a cheque-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a cheque; and
a set of rules frozen within said first and second memories which allows a cheque issued by the cheque sending security access module to be used by the cheque receiving securing access module only if said cheque has not been used previously and only if the intended beneficiary of said cheque is said cheque-receiving security access module.
11. Apparatus according to claim 10 wherein each of said memories comprises a public-key signature protected in non-volatile memory.
12. A method for safe collection of payment in return for goods, values or services, the method comprising:
providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element; and, for at least one purse
signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted; and
preventing said purse, off-line, from exceeding the credit for value receivable which it has been granted.
13. Apparatus according claim 10 wherein said second cryptocomputer is operative to generate a sequence of non-repeating numbers, wherein said set of rules includes the following rules:
a. A cheque cannot be received by said cheque receiving module unless a request therefor has been generated by said cheque receiving module, said request including a unique number from said sequence;
b. A cheque generated by the cheque-sending module must include the unique number associated with that cheque, the amount of the cheque and the identity of the intended beneficiary of the cheque, and the cheque-sending module's signature upon said number, said amount and said identity; and
c. The cheque-receiving module must keep a record enabling itself to differentiate used cheques from unused cheques and must confirm that a cheque is an unused cheque before using said cheque.
14. Apparatus for transmitting electronic receipts over open channels, each receipt having an intended beneficiary, the apparatus comprising:
a receipt-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a receipt;
a receipt-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a receipt to generate credit; and
a set of rules frozen within said first and second memories which allows a receipt issued by the receipt sending security access module to be used by the receipt receiving securing access module only if said receipt has not been used previously to generate credit and only if the intended beneficiary of said receipt is said receipt-receiving security access module.
15. Apparatus according to claim 14 wherein each of said memories comprises a public-key signature certificate protected in non-volatile memory.
16. Apparatus according to claim 14 wherein said set of rules is protected by a tamper-resistant architecture.
17. Apparatus according to claim 15 wherein said set of rules is protected by a tamper-resistant architecture.
18. Apparatus according to claim 14 wherein said second cryptocomputer is operative to generate a sequence of non-repeating numbers, wherein said set of rules includes the following rules:
a. A receipt cannot be received by said receipt receiving module unless a request therefor has been generated by said receipt receiving module, said request including a unique number from said sequence;
b. A receipt generated by the receipt-sending module must include the unique number associated with that receipt, the amount of the receipt and the identity of the intended beneficiary of the receipt, and the receipt-sending module's signature upon said number, said amount and said identity; and
c. The receipt-receiving module must keep a record enabling itself to differentiate used receipts from unused receipts and must confirm that a receipt is an unused receipt before using said receipt.
19. Apparatus according to claim 15 wherein said second cryptocomputer is operative to generate a sequence of non-repeating numbers, wherein said set of rules includes the following rules:
a. A receipt cannot be received by said receipt receiving module unless a request therefor has been generated by said receipt receiving module, said request including a unique number from said sequence;
b. A receipt generated by the receipt-sending module must include the unique number associated with that receipt, the amount of the receipt and the identity of the intended beneficiary of the receipt, and the receipt-sending module's signature upon said number, said amount and said identity; and
c. The receipt-receiving module must keep a record enabling itself to differentiate used receipts from unused receipts and must confirm that a receipt is an unused receipt before using said receipt.
20. A system according to claim 1 wherein said value receivable comprises cash receivable.
21. A system according to claim 5 wherein said value receivable comprises cash receivable.
22. A system according to claim 7 wherein said value receivable comprises cash receivable.
23. A system according to claim 8 wherein said value receivable comprises cash receivable.
24. A system according to claim 9 wherein said value receivable comprises cash receivable.
25. A system according to claim 1 wherein said value receivable comprises accounts receivable.
26. A system according to claim 5 wherein said value receivable comprises accounts receivable.
27. A system according to claim 7 wherein said value receivable comprises accounts receivable.
28. A system according to claim 8 wherein said value receivable comprises accounts receivable.
29. A system according to claim 9 wherein said value receivable comprises accounts receivable.
30. A method for safe collection of payment in return for goods, values or services, the method comprising:
providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element; and, for at least one of the purses,
signing and authenticating a time-stamped transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted; and
preventing said purse, off-line, from extending a credit for value receivable which it has been granted over more than a predetermined period of time.
31. A public-key protected method for safe collection of payment in return for goods, values or services, the method comprising:
providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing, in public key protected form, an amount of credit for value receivable granted to the individual system element; and, for at least one of the purses
signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted; and
preventing said purse, off-line, from exceeding the credit for value receivable which it has been granted.
32. A method for safe collection of payment in return for goods, values or services, the method comprising:
providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element; and, for at least one of the purses,
signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted; and
preventing said purse from exceeding the credit for value receivable which it has been granted,
wherein at least one first purse from among said multiplicity of purses grants an amount of credit for value receivable granted to at least one second purse from among said multiplicity of purses only in response to activation by a predetermined plurality of system directors.
33. A method for safe collection of payment in return for at least one of goods, values and services, the method comprising:
providing a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element; and, for at least one of the purses,
signing and authenticating a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted; and
preventing said purse from exceeding the credit for value receivable which it has been granted,
wherein at least one first purse from among said multiplicity of purses grants an amount of credit for value receivable granted to at least one second purse from among said multiplicity of purses only in response to activation by at least one system director and operative to record information regarding the activation including the identity of said at least one system director.
34. A method for transmitting electronic cheques over open channels, each cheque having an intended beneficiary, the method comprising:
providing a cheque-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a cheque having an intended beneficiary;
providing a cheque-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a cheque; and
following a set of rules frozen within said first and second memories which allows a cheque issued by the cheque sending security access module to be used by the cheque receiving securing access module only if said cheque has not been used previously and only if the intended beneficiary of said cheque is said cheque-receiving security access module.
35. A method for transmitting electronic receipts over open channels, each receipt having an intended beneficiary, the method comprising:
providing a receipt-sending security access module including a first monolithic public key protected cryptocomputer having a first secured externally immutable non-volatile memory which is operative to generate a receipt;
providing a receipt-receiving security access module including a second monolithic public key protected cryptocomputer having a second secured externally immutable non-volatile memory which is operative to use a receipt to generate credit; and
following a set of rules frozen within said first and second memories which allows a receipt issued by the receipt sending security access module to be used by the receipt receiving securing access module only if said receipt has not been used previously to generate credit and only if the intended beneficiary of said receipt is said receipt-receiving security access module.
US10/462,315 1996-10-24 2003-06-13 Apparatus and methods for collecting value Abandoned US20030236748A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/462,315 US20030236748A1 (en) 1996-10-24 2003-06-13 Apparatus and methods for collecting value

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
IL119486 1996-10-24
IL11948696A IL119486A0 (en) 1996-10-24 1996-10-24 Apparatus and methods for collecting value
US08/956,060 US6609114B1 (en) 1996-10-24 1997-10-22 System for safe collection of payment including electronic payment receipt generators having electronic purses
US10/462,315 US20030236748A1 (en) 1996-10-24 2003-06-13 Apparatus and methods for collecting value

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US08/956,060 Continuation US6609114B1 (en) 1996-10-24 1997-10-22 System for safe collection of payment including electronic payment receipt generators having electronic purses

Publications (1)

Publication Number Publication Date
US20030236748A1 true US20030236748A1 (en) 2003-12-25

Family

ID=11069405

Family Applications (2)

Application Number Title Priority Date Filing Date
US08/956,060 Expired - Lifetime US6609114B1 (en) 1996-10-24 1997-10-22 System for safe collection of payment including electronic payment receipt generators having electronic purses
US10/462,315 Abandoned US20030236748A1 (en) 1996-10-24 2003-06-13 Apparatus and methods for collecting value

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US08/956,060 Expired - Lifetime US6609114B1 (en) 1996-10-24 1997-10-22 System for safe collection of payment including electronic payment receipt generators having electronic purses

Country Status (6)

Country Link
US (2) US6609114B1 (en)
EP (1) EP0944879B1 (en)
AT (1) ATE256901T1 (en)
DE (1) DE69726882D1 (en)
IL (1) IL119486A0 (en)
WO (1) WO1998018107A1 (en)

Cited By (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030110121A1 (en) * 2001-12-10 2003-06-12 Naofumi Miyamoto Method for procuring and redeeming construction/operation fund for power generating equipment
US20040215473A1 (en) * 2003-04-24 2004-10-28 Sun Microsystems, Inc. Simultaneous global transaction and local transaction management in an application server
US20050015353A1 (en) * 2003-07-14 2005-01-20 Sun Microsystems, Inc. Read/write lock transaction manager freezing
US20060113385A1 (en) * 2004-11-30 2006-06-01 International Business Machines Corporation Contactless card reader and information processing system
US20060187857A1 (en) * 2005-02-18 2006-08-24 Fujitsu Limited System and method to provide device control service, and computer product
US20070299722A1 (en) * 2004-12-02 2007-12-27 Stoffelsma Bouke C Method For The Automatic Detection Of The Use Of Chargeable Means Of Transport Conveying Passengers
WO2007070722A3 (en) * 2005-12-16 2007-12-27 Apex Analytix Inc Systems and methods for automated vendor risk analysis
US20080243627A1 (en) * 2005-08-23 2008-10-02 The Western Union Company Presentation Instrument Display And Activation Systems And Methods
US20080275916A1 (en) * 2007-05-02 2008-11-06 Mypoints.Com Inc. Rule-based dry run methodology in an information management system
US20090185687A1 (en) * 2008-01-23 2009-07-23 John Wankmueller Systems and Methods for Mutual Authentication Using One Time Codes
US20100014658A1 (en) * 2006-08-25 2010-01-21 Thales Method of customizing a security component, notably in an unprotected environment
US20100036742A1 (en) * 2006-12-13 2010-02-11 Sony Corporation Electronic money system, amount-of-money change information transmitter, server, and amount-of-money change information transmitting method
US20100082480A1 (en) * 2008-09-30 2010-04-01 Jason Alexander Korosec Payments with virtual value
US7698230B1 (en) * 2002-02-15 2010-04-13 ContractPal, Inc. Transaction architecture utilizing transaction policy statements
US20100116878A1 (en) * 2008-11-11 2010-05-13 Nautilus Hyosung Inc. Method for on-line sharing of tmk (terminal master key) between atm and host
US20100163616A1 (en) * 2008-12-29 2010-07-01 Simon Phillips Methods and apparatus for use in association with identification token
US20100250407A1 (en) * 2009-03-30 2010-09-30 Edson Silva Systems, methods and machine-readable mediums for consolidating financial information from multiple accounts maintained with a plurality of financial institutions
US20100274712A1 (en) * 2009-04-28 2010-10-28 Mastercard International Incorporated Apparatus, method, and computer program product for providing a quality control mechanism for the contactless interface of a dual-interface card
US20100274722A1 (en) * 2009-04-28 2010-10-28 Mastercard International Incorporated Apparatus, method, and computer program product for recovering torn smart payment device transactions
US20100310069A1 (en) * 2008-12-09 2010-12-09 Wincor Nixdorf International Gmbh System and method for secure communication of components inside self-service automats
US20120016896A1 (en) * 2010-05-28 2012-01-19 Securitymetrics, Inc. Systems and methods employing searches for known identifiers of sensitive information to identify sensitive information in data
US20120078944A1 (en) * 2010-09-28 2012-03-29 Schneider Electric USA, Inc. Calculation engine and calculation providers
US8364608B2 (en) 2010-06-15 2013-01-29 Sap Ag Managing consistent interfaces for export declaration and export declaration request business objects across heterogeneous systems
US8364715B2 (en) 2008-03-31 2013-01-29 Sap Ag Managing consistent interfaces for automatic identification label business objects across heterogeneous systems
US8370272B2 (en) 2010-06-15 2013-02-05 Sap Ag Managing consistent interfaces for business document message monitoring view, customs arrangement, and freight list business objects across heterogeneous systems
US8370233B2 (en) 2008-03-31 2013-02-05 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8374931B2 (en) 2006-03-31 2013-02-12 Sap Ag Consistent set of interfaces derived from a business object model
US8392364B2 (en) 2006-07-10 2013-03-05 Sap Ag Consistent set of interfaces derived from a business object model
US8396751B2 (en) 2009-09-30 2013-03-12 Sap Ag Managing consistent interfaces for merchandising business objects across heterogeneous systems
US8396768B1 (en) 2006-09-28 2013-03-12 Sap Ag Managing consistent interfaces for human resources business objects across heterogeneous systems
US8412603B2 (en) 2010-06-15 2013-04-02 Sap Ag Managing consistent interfaces for currency conversion and date and time business objects across heterogeneous systems
US8413165B2 (en) 2008-03-31 2013-04-02 Sap Ag Managing consistent interfaces for maintenance order business objects across heterogeneous systems
US8417588B2 (en) 2010-06-15 2013-04-09 Sap Ag Managing consistent interfaces for goods tag, production bill of material hierarchy, and release order template business objects across heterogeneous systems
US8417593B2 (en) 2008-02-28 2013-04-09 Sap Ag System and computer-readable medium for managing consistent interfaces for business objects across heterogeneous systems
US8423418B2 (en) 2008-03-31 2013-04-16 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8433585B2 (en) 2008-03-31 2013-04-30 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8463666B2 (en) 2008-11-25 2013-06-11 Sap Ag Managing consistent interfaces for merchandise and assortment planning business objects across heterogeneous systems
US8473317B2 (en) 2008-03-31 2013-06-25 Sap Ag Managing consistent interfaces for service part business objects across heterogeneous systems
US8515794B2 (en) 2010-06-15 2013-08-20 Sap Ag Managing consistent interfaces for employee time event and human capital management view of payroll process business objects across heterogeneous systems
US8521621B1 (en) 2012-06-28 2013-08-27 Sap Ag Consistent interface for inbound delivery request
US8521838B2 (en) 2011-07-28 2013-08-27 Sap Ag Managing consistent interfaces for communication system and object identifier mapping business objects across heterogeneous systems
US8554586B2 (en) 2008-06-26 2013-10-08 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8560392B2 (en) 2011-07-28 2013-10-15 Sap Ag Managing consistent interfaces for a point of sale transaction business object across heterogeneous systems
US8566193B2 (en) 2006-08-11 2013-10-22 Sap Ag Consistent set of interfaces derived from a business object model
US8566185B2 (en) 2008-06-26 2013-10-22 Sap Ag Managing consistent interfaces for financial instrument business objects across heterogeneous systems
US8577991B2 (en) 2008-03-31 2013-11-05 Sap Ag Managing consistent interfaces for internal service request business objects across heterogeneous systems
US8577760B2 (en) 2008-11-25 2013-11-05 Sap Ag Managing consistent interfaces for tax authority business objects across heterogeneous systems
US8583534B1 (en) * 2005-09-30 2013-11-12 Trading Technologies International Inc. System and method for multi-market risk control in a distributed electronic trading environment
US8589263B2 (en) 2008-03-31 2013-11-19 Sap Ag Managing consistent interfaces for retail business objects across heterogeneous systems
US8601490B2 (en) 2011-07-28 2013-12-03 Sap Ag Managing consistent interfaces for business rule business object across heterogeneous systems
US8606723B2 (en) 2004-06-04 2013-12-10 Sap Ag Consistent set of interfaces derived from a business object model
US8615451B1 (en) 2012-06-28 2013-12-24 Sap Ag Consistent interface for goods and activity confirmation
US8645228B2 (en) 2008-06-26 2014-02-04 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8655756B2 (en) 2004-06-04 2014-02-18 Sap Ag Consistent set of interfaces derived from a business object model
US8666845B2 (en) 2011-07-28 2014-03-04 Sap Ag Managing consistent interfaces for a customer requirement business object across heterogeneous systems
US8671064B2 (en) 2008-06-26 2014-03-11 Sap Ag Managing consistent interfaces for supply chain management business objects across heterogeneous systems
US8671041B2 (en) 2008-12-12 2014-03-11 Sap Ag Managing consistent interfaces for credit portfolio business objects across heterogeneous systems
US8694397B2 (en) 2004-06-18 2014-04-08 Sap Ag Consistent set of interfaces derived from a business object model
US8725654B2 (en) 2011-07-28 2014-05-13 Sap Ag Managing consistent interfaces for employee data replication business objects across heterogeneous systems
US8732083B2 (en) 2010-06-15 2014-05-20 Sap Ag Managing consistent interfaces for number range, number range profile, payment card payment authorisation, and product template template business objects across heterogeneous systems
US8744937B2 (en) 2005-02-25 2014-06-03 Sap Ag Consistent set of interfaces derived from a business object model
US8756274B2 (en) 2012-02-16 2014-06-17 Sap Ag Consistent interface for sales territory message type set 1
US8756135B2 (en) 2012-06-28 2014-06-17 Sap Ag Consistent interface for product valuation data and product valuation level
US8762453B2 (en) 2012-02-16 2014-06-24 Sap Ag Consistent interface for feed collaboration group and feed event subscription
US8762454B2 (en) 2012-02-16 2014-06-24 Sap Ag Consistent interface for flag and tag
US8775280B2 (en) 2011-07-28 2014-07-08 Sap Ag Managing consistent interfaces for financial business objects across heterogeneous systems
US8788324B1 (en) * 2007-12-14 2014-07-22 Amazon Technologies, Inc. Preferred payment type
US8924269B2 (en) * 2006-05-13 2014-12-30 Sap Ag Consistent set of interfaces derived from a business object model
US8930248B2 (en) 2008-03-31 2015-01-06 Sap Se Managing consistent interfaces for supply network business objects across heterogeneous systems
US8949855B2 (en) 2012-06-28 2015-02-03 Sap Se Consistent interface for address snapshot and approval process definition
US8984050B2 (en) 2012-02-16 2015-03-17 Sap Se Consistent interface for sales territory message type set 2
US9043236B2 (en) 2012-08-22 2015-05-26 Sap Se Consistent interface for financial instrument impairment attribute values analytical result
US9076112B2 (en) 2012-08-22 2015-07-07 Sap Se Consistent interface for financial instrument impairment expected cash flow analytical result
US9135585B2 (en) 2010-06-15 2015-09-15 Sap Se Managing consistent interfaces for property library, property list template, quantity conversion virtual object, and supplier property specification business objects across heterogeneous systems
US9191357B2 (en) 2013-03-15 2015-11-17 Sap Se Consistent interface for email activity business object
US9191343B2 (en) 2013-03-15 2015-11-17 Sap Se Consistent interface for appointment activity business object
US9232368B2 (en) 2012-02-16 2016-01-05 Sap Se Consistent interface for user feed administrator, user feed event link and user feed settings
US9237425B2 (en) 2012-02-16 2016-01-12 Sap Se Consistent interface for feed event, feed event document and feed event type
US9246869B2 (en) 2012-06-28 2016-01-26 Sap Se Consistent interface for opportunity
US9261950B2 (en) 2012-06-28 2016-02-16 Sap Se Consistent interface for document output request
US9317845B1 (en) * 2014-12-23 2016-04-19 Mastercard International Incorporated Flexible electronic payment transaction process
US9367826B2 (en) 2012-06-28 2016-06-14 Sap Se Consistent interface for entitlement product
US9400998B2 (en) 2012-06-28 2016-07-26 Sap Se Consistent interface for message-based communication arrangement, organisational centre replication request, and payment schedule
US9547833B2 (en) 2012-08-22 2017-01-17 Sap Se Consistent interface for financial instrument impairment calculation
US20170220958A1 (en) * 2014-07-24 2017-08-03 Schucan Management Ag Ticketing Method and System
US9781256B2 (en) * 2012-10-31 2017-10-03 Intellisist Inc. Computer-implemented system and method for determining a status of a call connection
US20180336766A1 (en) * 2017-05-18 2018-11-22 Bank Of America Corporation System for providing on-demand resource delivery to resource dispensers
US10338945B2 (en) * 2017-02-09 2019-07-02 Kyland Technology Co., Ltd. Heterogeneous field devices control management system based on industrial internet operating system
US20190296902A1 (en) * 2018-03-20 2019-09-26 Mocana Corporation Dynamic domain key exchange for authenticated device to device communications
TWI696135B (en) * 2017-08-22 2020-06-11 香港商阿里巴巴集團服務有限公司 Method and device for off-line payment, business processing, and payment processing
US20220138865A1 (en) * 2020-11-05 2022-05-05 Fmr Llc Systems and methods for multi-purse transaction file splitting
US11595217B2 (en) 2018-12-06 2023-02-28 Digicert, Inc. System and method for zero touch provisioning of IoT devices

Families Citing this family (109)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6453334B1 (en) 1997-06-16 2002-09-17 Streamtheory, Inc. Method and apparatus to allow remotely located computer programs and/or data to be accessed on a local computer in a secure, time-limited manner, with persistent caching
US6422459B1 (en) 1997-10-15 2002-07-23 Citicorp Development Center, Inc. Method and system for off-line loading of stored value cards using a batch-load terminal
EP1161716B1 (en) * 1999-02-15 2013-11-27 Hewlett-Packard Development Company, L.P. Trusted computing platform
US7239226B2 (en) 2001-07-10 2007-07-03 American Express Travel Related Services Company, Inc. System and method for payment using radio frequency identification in contact and contactless transactions
US6990578B1 (en) * 1999-10-29 2006-01-24 International Business Machines Corp. Method and apparatus for encrypting electronic messages composed using abbreviated address books
KR20070094988A (en) * 1999-11-05 2007-09-27 소니 가부시끼 가이샤 Data decoding apparatus and method, charge information processing apparatus and method, data reproducing apparatus and method, electronic money, electronic use right, and terminal apparatus
JP2001222740A (en) * 2000-02-09 2001-08-17 Sony Corp Electronic money system and electronic money terminal device
US7234103B1 (en) 2000-04-26 2007-06-19 Accenture Llp Network-based tax framework database
US7603301B1 (en) * 2000-04-26 2009-10-13 Accenture Llp Verification and printing of a tax return in a network-based tax architecture
US7024696B1 (en) * 2000-06-14 2006-04-04 Reuben Bahar Method and system for prevention of piracy of a given software application via a communications network
US7953834B1 (en) * 2000-06-22 2011-05-31 Emc Corporation System and method for reducing bandwidth consumed by looping message packets in local area network
US7249039B2 (en) * 2000-07-06 2007-07-24 Hitachi, Ltd. Processing system for providing services and processing method therefor
US7546275B1 (en) * 2000-07-20 2009-06-09 International Business Machines Corporation Decentralized electronic certified payment
US6883004B2 (en) * 2000-08-04 2005-04-19 Bottomline Technologies (De), Inc. Automated invoice receipt and management system
FR2815445B1 (en) * 2000-10-18 2002-12-27 Gemplus Card Int EMULATION METHOD FOR MANAGING A SMART CARD READER INCOMPATIBLE WITH AN ENVIRONMENT
US7333953B1 (en) 2000-10-31 2008-02-19 Wells Fargo Bank, N.A. Method and apparatus for integrated payments processing and decisioning for internet transactions
US8145567B2 (en) 2000-10-31 2012-03-27 Wells Fargo Bank, N.A. Transaction ID system and process
US20020083183A1 (en) * 2000-11-06 2002-06-27 Sanjay Pujare Conventionally coded application conversion system for streamed delivery and execution
US20020087883A1 (en) * 2000-11-06 2002-07-04 Curt Wohlgemuth Anti-piracy system for remotely served computer applications
US7062567B2 (en) 2000-11-06 2006-06-13 Endeavors Technology, Inc. Intelligent network streaming and execution system for conventionally coded applications
US8831995B2 (en) 2000-11-06 2014-09-09 Numecent Holdings, Inc. Optimized server for streamed applications
US7451196B1 (en) 2000-12-15 2008-11-11 Stream Theory, Inc. Method and system for executing a software application in a virtual environment
TWI238637B (en) * 2001-01-10 2005-08-21 Ibm Method and system for processing of documents with electronic signatures
US7124118B2 (en) * 2001-02-20 2006-10-17 Cubic Corporation Transit best fare system and method
US6643635B2 (en) * 2001-03-15 2003-11-04 Sagemetrics Corporation Methods for dynamically accessing, processing, and presenting data acquired from disparate data sources
US8140415B2 (en) * 2001-03-20 2012-03-20 Goldman Sachs & Co. Automated global risk management
US8209246B2 (en) 2001-03-20 2012-06-26 Goldman, Sachs & Co. Proprietary risk management clearinghouse
US7904361B2 (en) * 2001-03-20 2011-03-08 Goldman Sachs & Co. Risk management customer registry
US8121937B2 (en) 2001-03-20 2012-02-21 Goldman Sachs & Co. Gaming industry risk management clearinghouse
US7493288B2 (en) 2001-07-10 2009-02-17 Xatra Fund Mx, Llc RF payment via a mobile device
US7249112B2 (en) 2002-07-09 2007-07-24 American Express Travel Related Services Company, Inc. System and method for assigning a funding source for a radio frequency identification device
US7207060B2 (en) * 2001-10-18 2007-04-17 Nokia Corporation Method, system and computer program product for secure ticketing in a communications device
US7178041B2 (en) * 2001-10-18 2007-02-13 Nokia Corporation Method, system and computer program product for a trusted counter in an external security element for securing a personal communication device
US7386528B2 (en) * 2002-05-31 2008-06-10 American Express Travel Related Services Company, Inc. System and method for acquisition, assimilation and storage of information
US7121460B1 (en) 2002-07-16 2006-10-17 Diebold Self-Service Systems Division Of Diebold, Incorporated Automated banking machine component authentication system and method
US7580873B1 (en) * 2002-07-23 2009-08-25 At&T Intellectual Property I, L.P. Electronic financial assistant
SG145524A1 (en) * 2002-08-07 2008-09-29 Mobilastic Technologies Pte Lt Secure transfer of digital tokens
JP2004085286A (en) * 2002-08-26 2004-03-18 Alpine Electronics Inc On-vehicle navigation device, navigation information display method and program
JP2004110147A (en) * 2002-09-13 2004-04-08 Reiko Tei Automatic payment system
GB0221639D0 (en) * 2002-09-17 2002-10-30 Hewlett Packard Co Method and apparatus for printing
US7309004B1 (en) * 2002-12-26 2007-12-18 Diebold Self-Service Systems, Division Of Diebold, Incorporated Cash dispensing automated banking machine firmware authentication system and method
GB0305806D0 (en) * 2003-03-13 2003-04-16 Ecebs Ltd Smartcard based value transfer
KR100818992B1 (en) * 2004-05-31 2008-04-03 삼성전자주식회사 Apparatus and method for sending and receiving digital right objects in a transfomred format between device and portable storage
US8996481B2 (en) 2004-07-02 2015-03-31 Goldman, Sach & Co. Method, system, apparatus, program code and means for identifying and extracting information
US8510300B2 (en) 2004-07-02 2013-08-13 Goldman, Sachs & Co. Systems and methods for managing information associated with legal, compliance and regulatory risk
US8442953B2 (en) 2004-07-02 2013-05-14 Goldman, Sachs & Co. Method, system, apparatus, program code and means for determining a redundancy of information
US8762191B2 (en) 2004-07-02 2014-06-24 Goldman, Sachs & Co. Systems, methods, apparatus, and schema for storing, managing and retrieving information
US7240162B2 (en) 2004-10-22 2007-07-03 Stream Theory, Inc. System and method for predictive streaming
EP1825390A2 (en) 2004-11-13 2007-08-29 Stream Theory, Inc. Hybrid local/remote streaming
EP1866825A1 (en) 2005-03-22 2007-12-19 Hewlett-Packard Development Company, L.P. Methods, devices and data structures for trusted data
EP1875364A2 (en) 2005-03-23 2008-01-09 Stream Theory, Inc. System and method for tracking changes to files in streaming applications
US8024523B2 (en) 2007-11-07 2011-09-20 Endeavors Technologies, Inc. Opportunistic block transmission with time constraints
US8196818B2 (en) 2005-07-13 2012-06-12 Mastercard International Incorporated Apparatus and method for integrated payment and electronic merchandise transfer
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
WO2007086068A2 (en) * 2006-01-30 2007-08-02 Fortressgb Ltd. System for accepting value from closed groups
US11019007B1 (en) 2006-07-13 2021-05-25 United Services Automobile Association (Usaa) Systems and methods for providing electronic official documents
US8261345B2 (en) 2006-10-23 2012-09-04 Endeavors Technologies, Inc. Rule-based application access management
US20080290994A1 (en) * 2007-03-30 2008-11-27 Skyetek, Inc. Method For Cryptographically Combining HF and UHF RFID Tags/Smart Cards To Create A Single Multi-Use Credential
US7710681B2 (en) * 2007-06-06 2010-05-04 International Business Machines Corporation Optimizing tape speed for a sync operation
US8370254B1 (en) 2007-09-26 2013-02-05 United Services Automobile Association Enhanced vehicle identification card
US8025226B1 (en) 2007-09-26 2011-09-27 United States Automobile Association (USAA) Enhanced vehicle identification card
US8376222B1 (en) 2007-10-30 2013-02-19 United Services Automobile Association (Usaa) Systems and methods to temporarily transfer funds to a member
US8892738B2 (en) 2007-11-07 2014-11-18 Numecent Holdings, Inc. Deriving component statistics for a stream enabled application
US20090271265A1 (en) * 2008-04-28 2009-10-29 Cyndigo, Corp. Electronic receipt system and method
US20090271322A1 (en) * 2008-04-28 2009-10-29 Isaac Lay Electronic receipt system and method
EP2380149B1 (en) * 2008-12-19 2016-10-12 Nxp B.V. Enhanced smart card usage
US20100332319A1 (en) * 2009-06-24 2010-12-30 Craig Stephen Etchegoyen Methods and Systems for Dynamic Serving of Advertisements in a Game or Virtual Reality Environment
US20100332320A1 (en) * 2009-06-24 2010-12-30 Joseph Martin Mordetsky Systems and Methods for Providing Conditional Authorization to Operate Licensed Software
US20100332331A1 (en) * 2009-06-24 2010-12-30 Craig Stephen Etchegoyen Systems and Methods for Providing an Interface for Purchasing Ad Slots in an Executable Program
US20110029432A1 (en) * 2009-07-30 2011-02-03 Hildred Richard N Computer-implemented methods of processing payments for a merchant selling goods or services to a consumer
US20110060600A1 (en) * 2009-09-10 2011-03-10 Transittix, Llc Systems and Methods For Tracking the Transportation of Passengers
US20110137803A1 (en) * 2009-12-03 2011-06-09 Symbol Technologies, Inc. Secure electronic receipt systems and methods
WO2012000438A1 (en) * 2010-06-29 2012-01-05 飞天诚信科技股份有限公司 Method for operating electronic purse
WO2012004838A1 (en) * 2010-07-09 2012-01-12 Takeshi Mizunuma Service provision method
FR2972830B1 (en) * 2011-03-15 2014-01-10 Affiliated Computer Services Solutions France SYSTEM FOR CONTROLLING VALIDATION OF TRANSPORT TITLES
US8849878B1 (en) * 2011-09-30 2014-09-30 Emc Corporation Efficient data rehydration
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US10318936B2 (en) 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US9626664B2 (en) 2012-03-07 2017-04-18 Clearxchange, Llc System and method for transferring funds
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US20140156535A1 (en) * 2012-06-01 2014-06-05 Nameh Jabbour System and method for requesting and processing pin data using a digit subset for subsequent pin authentication
GB2515763A (en) * 2013-07-02 2015-01-07 Mastercard International Inc Improvements relating to unpredictable number generation
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10878387B2 (en) 2015-03-23 2020-12-29 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
JP6648461B2 (en) * 2015-09-30 2020-02-14 富士ゼロックス株式会社 Information processing device and program
US11144928B2 (en) 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US20190097803A1 (en) * 2017-09-22 2019-03-28 Cubic Corporation Encrypted reverse biometric token validation
US11777913B2 (en) * 2018-12-04 2023-10-03 Journey.ai Generating reports from information within a zero-knowledge data management network
US11532040B2 (en) 2019-11-12 2022-12-20 Bottomline Technologies Sarl International cash management software using machine learning
US11526859B1 (en) 2019-11-12 2022-12-13 Bottomline Technologies, Sarl Cash flow forecasting using a bottoms-up machine learning approach
US11599886B2 (en) * 2020-01-17 2023-03-07 Bank Of America Corporation System for impetus resource distribution process confirmation with wearable device integration
US11704671B2 (en) 2020-04-02 2023-07-18 Bottomline Technologies Limited Financial messaging transformation-as-a-service
CN111798220B (en) * 2020-07-20 2023-11-07 四川中电启明星信息技术有限公司 Material purchase settlement management system based on financial robot

Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4802218A (en) * 1986-11-26 1989-01-31 Wright Technologies, L.P. Automated transaction system
US4804825A (en) * 1986-06-17 1989-02-14 Casio Computer Co., Ltd. I C card system
US5175416A (en) * 1989-10-06 1992-12-29 Mansvelt Andre Peter Funds transfer system
US5315510A (en) * 1991-05-13 1994-05-24 Tokyo Electric Co., Ltd. Electronic cash register indicating when cash is required to be collected from the cash drawer
US5440634A (en) * 1991-10-16 1995-08-08 Jonhig Limited Value transfer system
US5577121A (en) * 1994-06-09 1996-11-19 Electronic Payment Services, Inc. Transaction system for integrated circuit cards
US5621797A (en) * 1994-04-28 1997-04-15 Citibank, N.A. Electronic ticket presentation and transfer method
US5623547A (en) * 1990-04-12 1997-04-22 Jonhig Limited Value transfer system
US5677955A (en) * 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US5754654A (en) * 1994-11-18 1998-05-19 Hitachi, Ltd Electronic ticket vending system and method thereof
US5857152A (en) * 1994-02-01 1999-01-05 Mondex International Limited Electronic toll payment
US5913203A (en) * 1996-10-03 1999-06-15 Jaesent Inc. System and method for pseudo cash transactions
US5936221A (en) * 1997-10-02 1999-08-10 Bridgepoint Systems, Inc. Smart card system and method for transferring value
US5991747A (en) * 1995-08-02 1999-11-23 Hitachi, Ltd. Electronic purse loan system
US6119946A (en) * 1997-04-01 2000-09-19 Cardis Enterprise International N.V. Countable electronic monetary system and method
US6439455B1 (en) * 1995-05-11 2002-08-27 Mondex International Limited Value transfer system
US6553351B1 (en) * 1996-05-24 2003-04-22 Eduard Karel De Jong System with and method of cryptographically protecting communications

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3184196B2 (en) * 1989-09-06 2001-07-09 株式会社富士通総研 Electronic wallet system
JP3092966B2 (en) 1991-04-01 2000-09-25 株式会社日阪製作所 Wood drying method and drying equipment
DE4333388A1 (en) * 1993-09-30 1995-04-06 Giesecke & Devrient Gmbh System for carrying out transactions with a multifunction card with an electronic wallet
IL107789A0 (en) * 1993-11-29 1995-03-15 Cortress U & T Ltd Data verification system and method
DE69529083T2 (en) * 1994-09-25 2003-09-04 Cardis Entpr Internat N V A SALES MACHINE, A SALES SYSTEM AND METHOD FOR OPERATING IT
EP0724238A1 (en) * 1995-01-24 1996-07-31 Europay International S.A. Card apparatus and cashless transaction system

Patent Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4804825A (en) * 1986-06-17 1989-02-14 Casio Computer Co., Ltd. I C card system
US4802218A (en) * 1986-11-26 1989-01-31 Wright Technologies, L.P. Automated transaction system
US5175416A (en) * 1989-10-06 1992-12-29 Mansvelt Andre Peter Funds transfer system
US5623547A (en) * 1990-04-12 1997-04-22 Jonhig Limited Value transfer system
US5315510A (en) * 1991-05-13 1994-05-24 Tokyo Electric Co., Ltd. Electronic cash register indicating when cash is required to be collected from the cash drawer
US5440634A (en) * 1991-10-16 1995-08-08 Jonhig Limited Value transfer system
US5857152A (en) * 1994-02-01 1999-01-05 Mondex International Limited Electronic toll payment
US5621797A (en) * 1994-04-28 1997-04-15 Citibank, N.A. Electronic ticket presentation and transfer method
US5577121A (en) * 1994-06-09 1996-11-19 Electronic Payment Services, Inc. Transaction system for integrated circuit cards
US5754654A (en) * 1994-11-18 1998-05-19 Hitachi, Ltd Electronic ticket vending system and method thereof
US5677955A (en) * 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US6439455B1 (en) * 1995-05-11 2002-08-27 Mondex International Limited Value transfer system
US5991747A (en) * 1995-08-02 1999-11-23 Hitachi, Ltd. Electronic purse loan system
US6553351B1 (en) * 1996-05-24 2003-04-22 Eduard Karel De Jong System with and method of cryptographically protecting communications
US5913203A (en) * 1996-10-03 1999-06-15 Jaesent Inc. System and method for pseudo cash transactions
US6119946A (en) * 1997-04-01 2000-09-19 Cardis Enterprise International N.V. Countable electronic monetary system and method
US5936221A (en) * 1997-10-02 1999-08-10 Bridgepoint Systems, Inc. Smart card system and method for transferring value

Cited By (142)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030110121A1 (en) * 2001-12-10 2003-06-12 Naofumi Miyamoto Method for procuring and redeeming construction/operation fund for power generating equipment
US7698230B1 (en) * 2002-02-15 2010-04-13 ContractPal, Inc. Transaction architecture utilizing transaction policy statements
US20040215473A1 (en) * 2003-04-24 2004-10-28 Sun Microsystems, Inc. Simultaneous global transaction and local transaction management in an application server
US7610305B2 (en) 2003-04-24 2009-10-27 Sun Microsystems, Inc. Simultaneous global transaction and local transaction management in an application server
US20050015353A1 (en) * 2003-07-14 2005-01-20 Sun Microsystems, Inc. Read/write lock transaction manager freezing
US7739252B2 (en) * 2003-07-14 2010-06-15 Oracle America, Inc. Read/write lock transaction manager freezing
US8606723B2 (en) 2004-06-04 2013-12-10 Sap Ag Consistent set of interfaces derived from a business object model
US8655756B2 (en) 2004-06-04 2014-02-18 Sap Ag Consistent set of interfaces derived from a business object model
US8694397B2 (en) 2004-06-18 2014-04-08 Sap Ag Consistent set of interfaces derived from a business object model
US20060113385A1 (en) * 2004-11-30 2006-06-01 International Business Machines Corporation Contactless card reader and information processing system
US7845567B2 (en) 2004-11-30 2010-12-07 International Business Machines Corporation Contactless card reader and information processing system
US20080126188A1 (en) * 2004-12-02 2008-05-29 Mcity Gmbh Method For Automatically Detecting The Use Of A Means Of Transport Conveying Persons
US20080120127A1 (en) * 2004-12-02 2008-05-22 Mcity Gmbh Method for Checking Electronic Tickets Stored on User Terminals
US8018330B2 (en) 2004-12-02 2011-09-13 Mcity Gmbh Method for automatically detecting the use of a means of transport conveying persons
US20070299722A1 (en) * 2004-12-02 2007-12-27 Stoffelsma Bouke C Method For The Automatic Detection Of The Use Of Chargeable Means Of Transport Conveying Passengers
US8443055B2 (en) * 2005-02-18 2013-05-14 Fujitsu Limited System and method to provide device control service, and computer product
US20060187857A1 (en) * 2005-02-18 2006-08-24 Fujitsu Limited System and method to provide device control service, and computer product
US8744937B2 (en) 2005-02-25 2014-06-03 Sap Ag Consistent set of interfaces derived from a business object model
US10269203B2 (en) 2005-08-23 2019-04-23 The Western Union Company Presentation instrument display and activation systems and methods
US8175924B2 (en) * 2005-08-23 2012-05-08 The Western Union Company Presentation instrument display and activation systems and methods
US20080243627A1 (en) * 2005-08-23 2008-10-02 The Western Union Company Presentation Instrument Display And Activation Systems And Methods
US10037572B2 (en) 2005-09-30 2018-07-31 Trading Technologies International, Inc. System and method for multi-market risk control in a distributed electronic trading environment
US11625776B2 (en) 2005-09-30 2023-04-11 Trading Technologies International, Inc. System and method for multi-market risk control in a distributed electronic trading environment
US8583534B1 (en) * 2005-09-30 2013-11-12 Trading Technologies International Inc. System and method for multi-market risk control in a distributed electronic trading environment
US8825543B2 (en) 2005-09-30 2014-09-02 Trading Technologies International Inc. System and method for multi-market risk control in a distributed electronic trading environment
WO2007070722A3 (en) * 2005-12-16 2007-12-27 Apex Analytix Inc Systems and methods for automated vendor risk analysis
US8374931B2 (en) 2006-03-31 2013-02-12 Sap Ag Consistent set of interfaces derived from a business object model
US8924269B2 (en) * 2006-05-13 2014-12-30 Sap Ag Consistent set of interfaces derived from a business object model
US8392364B2 (en) 2006-07-10 2013-03-05 Sap Ag Consistent set of interfaces derived from a business object model
US8566193B2 (en) 2006-08-11 2013-10-22 Sap Ag Consistent set of interfaces derived from a business object model
US20100014658A1 (en) * 2006-08-25 2010-01-21 Thales Method of customizing a security component, notably in an unprotected environment
US8468544B1 (en) 2006-09-28 2013-06-18 Sap Ag Managing consistent interfaces for demand planning business objects across heterogeneous systems
US8606639B1 (en) 2006-09-28 2013-12-10 Sap Ag Managing consistent interfaces for purchase order business objects across heterogeneous systems
US8571961B1 (en) 2006-09-28 2013-10-29 Sap Ag Managing consistent interfaces for financial business objects across heterogeneous systems
US8402473B1 (en) 2006-09-28 2013-03-19 Sap Ag Managing consistent interfaces for demand business objects across heterogeneous systems
US8396768B1 (en) 2006-09-28 2013-03-12 Sap Ag Managing consistent interfaces for human resources business objects across heterogeneous systems
US9355397B2 (en) * 2006-12-13 2016-05-31 Sony Corporation Electronic money system, amount-of-money change information transmitter, server, and amount-of-money change information transmitting method
US20100036742A1 (en) * 2006-12-13 2010-02-11 Sony Corporation Electronic money system, amount-of-money change information transmitter, server, and amount-of-money change information transmitting method
US20080275916A1 (en) * 2007-05-02 2008-11-06 Mypoints.Com Inc. Rule-based dry run methodology in an information management system
US7627572B2 (en) * 2007-05-02 2009-12-01 Mypoints.Com Inc. Rule-based dry run methodology in an information management system
US8788324B1 (en) * 2007-12-14 2014-07-22 Amazon Technologies, Inc. Preferred payment type
US8627080B2 (en) * 2008-01-23 2014-01-07 Mastercard International Incorporated Systems and methods for mutual authentication using one time codes
US8255688B2 (en) * 2008-01-23 2012-08-28 Mastercard International Incorporated Systems and methods for mutual authentication using one time codes
US20120303960A1 (en) * 2008-01-23 2012-11-29 John Wankmueller Systems and Methods for Mutual Authentication Using One Time Codes
US20090185687A1 (en) * 2008-01-23 2009-07-23 John Wankmueller Systems and Methods for Mutual Authentication Using One Time Codes
US8417593B2 (en) 2008-02-28 2013-04-09 Sap Ag System and computer-readable medium for managing consistent interfaces for business objects across heterogeneous systems
US8799115B2 (en) 2008-02-28 2014-08-05 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8413165B2 (en) 2008-03-31 2013-04-02 Sap Ag Managing consistent interfaces for maintenance order business objects across heterogeneous systems
US8473317B2 (en) 2008-03-31 2013-06-25 Sap Ag Managing consistent interfaces for service part business objects across heterogeneous systems
US8589263B2 (en) 2008-03-31 2013-11-19 Sap Ag Managing consistent interfaces for retail business objects across heterogeneous systems
US8370233B2 (en) 2008-03-31 2013-02-05 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8423418B2 (en) 2008-03-31 2013-04-16 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8433585B2 (en) 2008-03-31 2013-04-30 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8930248B2 (en) 2008-03-31 2015-01-06 Sap Se Managing consistent interfaces for supply network business objects across heterogeneous systems
US8577991B2 (en) 2008-03-31 2013-11-05 Sap Ag Managing consistent interfaces for internal service request business objects across heterogeneous systems
US8364715B2 (en) 2008-03-31 2013-01-29 Sap Ag Managing consistent interfaces for automatic identification label business objects across heterogeneous systems
US8554586B2 (en) 2008-06-26 2013-10-08 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8671064B2 (en) 2008-06-26 2014-03-11 Sap Ag Managing consistent interfaces for supply chain management business objects across heterogeneous systems
US8645228B2 (en) 2008-06-26 2014-02-04 Sap Ag Managing consistent interfaces for business objects across heterogeneous systems
US8566185B2 (en) 2008-06-26 2013-10-22 Sap Ag Managing consistent interfaces for financial instrument business objects across heterogeneous systems
US9047578B2 (en) 2008-06-26 2015-06-02 Sap Se Consistent set of interfaces for business objects across heterogeneous systems
US20100082480A1 (en) * 2008-09-30 2010-04-01 Jason Alexander Korosec Payments with virtual value
US20100116878A1 (en) * 2008-11-11 2010-05-13 Nautilus Hyosung Inc. Method for on-line sharing of tmk (terminal master key) between atm and host
US7837098B2 (en) * 2008-11-11 2010-11-23 Nautilus Hyosung Inc. Method for on-line sharing of TMK (terminal master key) between ATM and host
US8577760B2 (en) 2008-11-25 2013-11-05 Sap Ag Managing consistent interfaces for tax authority business objects across heterogeneous systems
US8463666B2 (en) 2008-11-25 2013-06-11 Sap Ag Managing consistent interfaces for merchandise and assortment planning business objects across heterogeneous systems
US20100310069A1 (en) * 2008-12-09 2010-12-09 Wincor Nixdorf International Gmbh System and method for secure communication of components inside self-service automats
US8787569B2 (en) * 2008-12-09 2014-07-22 Wincor Nixdorf International Gmbh System and method for secure communication of components inside self-service automats
US8671041B2 (en) 2008-12-12 2014-03-11 Sap Ag Managing consistent interfaces for credit portfolio business objects across heterogeneous systems
US20100163616A1 (en) * 2008-12-29 2010-07-01 Simon Phillips Methods and apparatus for use in association with identification token
US8794532B2 (en) * 2008-12-29 2014-08-05 Mastercard International Incorporated Methods and apparatus for use in association with identification token
US20100250407A1 (en) * 2009-03-30 2010-09-30 Edson Silva Systems, methods and machine-readable mediums for consolidating financial information from multiple accounts maintained with a plurality of financial institutions
US8583561B2 (en) 2009-04-28 2013-11-12 Mastercard International Incorporated Apparatus, method, and computer program product for providing a quality control mechanism for the contactless interface of a dual-interface card
US8401964B2 (en) 2009-04-28 2013-03-19 Mastercard International Incorporated Apparatus, method, and computer program product for encoding enhanced issuer information in a card
US11120441B2 (en) 2009-04-28 2021-09-14 Mastercard International Incorporated Apparatus, method, and computer program product for providing a quality control mechanism for the contactless interface of a dual-interface card
US20100325039A1 (en) * 2009-04-28 2010-12-23 Mastercard International Incorporated Apparatus, method, and computer program product for encoding enhanced issuer information in a card
US20100274722A1 (en) * 2009-04-28 2010-10-28 Mastercard International Incorporated Apparatus, method, and computer program product for recovering torn smart payment device transactions
WO2010127003A1 (en) * 2009-04-28 2010-11-04 Mastercard International Incorporated Apparatus, method, and computer program product for encoding enhanced issuer information in a card
WO2010127012A1 (en) * 2009-04-28 2010-11-04 Mastercard International Incorporated Apparatus, method, and computer program product for providing a quality control mechanism for the contactless interface of a dual-interface card
US20100274712A1 (en) * 2009-04-28 2010-10-28 Mastercard International Incorporated Apparatus, method, and computer program product for providing a quality control mechanism for the contactless interface of a dual-interface card
US10181121B2 (en) 2009-04-28 2019-01-15 Mastercard International Incorporated Apparatus, method, and computer program product for recovering torn smart payment device transactions
US8370258B2 (en) 2009-04-28 2013-02-05 Mastercard International Incorporated Apparatus, method, and computer program product for recovering torn smart payment device transactions
US8554637B2 (en) 2009-09-30 2013-10-08 Sap Ag Managing consistent interfaces for merchandising business objects across heterogeneous systems
US8396751B2 (en) 2009-09-30 2013-03-12 Sap Ag Managing consistent interfaces for merchandising business objects across heterogeneous systems
US20120016896A1 (en) * 2010-05-28 2012-01-19 Securitymetrics, Inc. Systems and methods employing searches for known identifiers of sensitive information to identify sensitive information in data
US11704672B2 (en) 2010-05-28 2023-07-18 Securitymetrics, Inc. Systems and methods employing searches for known identifiers of sensitive information to identify sensitive information in data
US10679218B2 (en) * 2010-05-28 2020-06-09 Securitymetrics, Inc. Systems and methods employing searches for known identifiers of sensitive information to identify sensitive information in data
US8515794B2 (en) 2010-06-15 2013-08-20 Sap Ag Managing consistent interfaces for employee time event and human capital management view of payroll process business objects across heterogeneous systems
US9135585B2 (en) 2010-06-15 2015-09-15 Sap Se Managing consistent interfaces for property library, property list template, quantity conversion virtual object, and supplier property specification business objects across heterogeneous systems
US8732083B2 (en) 2010-06-15 2014-05-20 Sap Ag Managing consistent interfaces for number range, number range profile, payment card payment authorisation, and product template template business objects across heterogeneous systems
US8412603B2 (en) 2010-06-15 2013-04-02 Sap Ag Managing consistent interfaces for currency conversion and date and time business objects across heterogeneous systems
US8417588B2 (en) 2010-06-15 2013-04-09 Sap Ag Managing consistent interfaces for goods tag, production bill of material hierarchy, and release order template business objects across heterogeneous systems
US8370272B2 (en) 2010-06-15 2013-02-05 Sap Ag Managing consistent interfaces for business document message monitoring view, customs arrangement, and freight list business objects across heterogeneous systems
US8364608B2 (en) 2010-06-15 2013-01-29 Sap Ag Managing consistent interfaces for export declaration and export declaration request business objects across heterogeneous systems
US8984034B2 (en) * 2010-09-28 2015-03-17 Schneider Electric USA, Inc. Calculation engine and calculation providers
US20120078944A1 (en) * 2010-09-28 2012-03-29 Schneider Electric USA, Inc. Calculation engine and calculation providers
US8725654B2 (en) 2011-07-28 2014-05-13 Sap Ag Managing consistent interfaces for employee data replication business objects across heterogeneous systems
US8666845B2 (en) 2011-07-28 2014-03-04 Sap Ag Managing consistent interfaces for a customer requirement business object across heterogeneous systems
US8775280B2 (en) 2011-07-28 2014-07-08 Sap Ag Managing consistent interfaces for financial business objects across heterogeneous systems
US8521838B2 (en) 2011-07-28 2013-08-27 Sap Ag Managing consistent interfaces for communication system and object identifier mapping business objects across heterogeneous systems
US8601490B2 (en) 2011-07-28 2013-12-03 Sap Ag Managing consistent interfaces for business rule business object across heterogeneous systems
US8560392B2 (en) 2011-07-28 2013-10-15 Sap Ag Managing consistent interfaces for a point of sale transaction business object across heterogeneous systems
US9237425B2 (en) 2012-02-16 2016-01-12 Sap Se Consistent interface for feed event, feed event document and feed event type
US8984050B2 (en) 2012-02-16 2015-03-17 Sap Se Consistent interface for sales territory message type set 2
US8756274B2 (en) 2012-02-16 2014-06-17 Sap Ag Consistent interface for sales territory message type set 1
US8762453B2 (en) 2012-02-16 2014-06-24 Sap Ag Consistent interface for feed collaboration group and feed event subscription
US9232368B2 (en) 2012-02-16 2016-01-05 Sap Se Consistent interface for user feed administrator, user feed event link and user feed settings
US8762454B2 (en) 2012-02-16 2014-06-24 Sap Ag Consistent interface for flag and tag
US9367826B2 (en) 2012-06-28 2016-06-14 Sap Se Consistent interface for entitlement product
US8949855B2 (en) 2012-06-28 2015-02-03 Sap Se Consistent interface for address snapshot and approval process definition
US8615451B1 (en) 2012-06-28 2013-12-24 Sap Ag Consistent interface for goods and activity confirmation
US9246869B2 (en) 2012-06-28 2016-01-26 Sap Se Consistent interface for opportunity
US9400998B2 (en) 2012-06-28 2016-07-26 Sap Se Consistent interface for message-based communication arrangement, organisational centre replication request, and payment schedule
US8521621B1 (en) 2012-06-28 2013-08-27 Sap Ag Consistent interface for inbound delivery request
US8756135B2 (en) 2012-06-28 2014-06-17 Sap Ag Consistent interface for product valuation data and product valuation level
US9261950B2 (en) 2012-06-28 2016-02-16 Sap Se Consistent interface for document output request
US9076112B2 (en) 2012-08-22 2015-07-07 Sap Se Consistent interface for financial instrument impairment expected cash flow analytical result
US9547833B2 (en) 2012-08-22 2017-01-17 Sap Se Consistent interface for financial instrument impairment calculation
US9043236B2 (en) 2012-08-22 2015-05-26 Sap Se Consistent interface for financial instrument impairment attribute values analytical result
US10511710B2 (en) 2012-10-31 2019-12-17 Intellisist, Inc. Computer-implemented system and method for call status determination
US9781256B2 (en) * 2012-10-31 2017-10-03 Intellisist Inc. Computer-implemented system and method for determining a status of a call connection
US9912806B1 (en) 2012-10-31 2018-03-06 Intellisist, Inc. Computer-implemented system and method for determining call status
US9191357B2 (en) 2013-03-15 2015-11-17 Sap Se Consistent interface for email activity business object
US9191343B2 (en) 2013-03-15 2015-11-17 Sap Se Consistent interface for appointment activity business object
US10796249B2 (en) * 2014-07-24 2020-10-06 Fairtiq Ag Ticketing method and system
US20170220958A1 (en) * 2014-07-24 2017-08-03 Schucan Management Ag Ticketing Method and System
US9317845B1 (en) * 2014-12-23 2016-04-19 Mastercard International Incorporated Flexible electronic payment transaction process
US9595030B2 (en) 2014-12-23 2017-03-14 Mastercard International Incorporated Flexible electronic payment transaction process
US10338945B2 (en) * 2017-02-09 2019-07-02 Kyland Technology Co., Ltd. Heterogeneous field devices control management system based on industrial internet operating system
US10515518B2 (en) * 2017-05-18 2019-12-24 Bank Of America Corporation System for providing on-demand resource delivery to resource dispensers
US10922930B2 (en) 2017-05-18 2021-02-16 Bank Of America Corporation System for providing on-demand resource delivery to resource dispensers
US20180336766A1 (en) * 2017-05-18 2018-11-22 Bank Of America Corporation System for providing on-demand resource delivery to resource dispensers
US10692091B2 (en) 2017-08-22 2020-06-23 Alibaba Group Holding Limited Method and apparatus for offline payment, service processing, and payment processing
US11836732B2 (en) 2017-08-22 2023-12-05 Advanced New Technologies Co., Ltd. Method and apparatus for offline payment, service processing, and payment processing
TWI696135B (en) * 2017-08-22 2020-06-11 香港商阿里巴巴集團服務有限公司 Method and device for off-line payment, business processing, and payment processing
US11113697B2 (en) 2017-08-22 2021-09-07 Advanced New Technologies Co., Ltd. Method and apparatus for offline payment, service processing, and payment processing
US10872342B2 (en) 2017-08-22 2020-12-22 Advanced New Technologies Co., Ltd. Method and apparatus for offline payment, service processing, and payment processing
US10764040B2 (en) * 2018-03-20 2020-09-01 Mocana Corporation Dynamic domain key exchange for authenticated device to device communications
US20190296902A1 (en) * 2018-03-20 2019-09-26 Mocana Corporation Dynamic domain key exchange for authenticated device to device communications
US11595217B2 (en) 2018-12-06 2023-02-28 Digicert, Inc. System and method for zero touch provisioning of IoT devices
US20220138865A1 (en) * 2020-11-05 2022-05-05 Fmr Llc Systems and methods for multi-purse transaction file splitting
US11720975B2 (en) * 2020-11-05 2023-08-08 Fmr Llc Systems and methods for multi-purse transaction file splitting

Also Published As

Publication number Publication date
ATE256901T1 (en) 2004-01-15
IL119486A0 (en) 1997-01-10
EP0944879A1 (en) 1999-09-29
US6609114B1 (en) 2003-08-19
EP0944879B1 (en) 2003-12-17
DE69726882D1 (en) 2004-01-29
WO1998018107A1 (en) 1998-04-30

Similar Documents

Publication Publication Date Title
US6609114B1 (en) System for safe collection of payment including electronic payment receipt generators having electronic purses
US7269256B2 (en) Electronic-monetary system
US8244636B2 (en) Payment system
CA2302695C (en) System and method for fast smart card transactions
US5949044A (en) Method and apparatus for funds and credit line transfers
US7478239B1 (en) Electronic ticket vending system
US6442532B1 (en) Wireless transaction and information system
US6913193B1 (en) Method and system of tracking and providing an audit trail of smart card transactions
US5544086A (en) Information consolidation within a transaction network
US5559887A (en) Collection of value from stored value systems
US7505944B2 (en) Method and system of payment by electronic cheque
US5898154A (en) System and method for updating security information in a time-based electronic monetary system
JP3390017B2 (en) Commercial payment system and method using a trust agent
JP3722751B2 (en) Parameter distribution method in offline chip card terminal, chip card terminal and user chip card suitable for it
US6859795B1 (en) Method for carrying out transactions and device for realizing the same
EP1190396B1 (en) Payment system
US20040128247A1 (en) Bank system program, credit service program and IC card
EP0926636B1 (en) Protection of transaction data
US20040034597A1 (en) System and method for managing micropayment transactions, corresponding client terminal and trader equipment
US20070034684A1 (en) Electronic money management system, electronic money management method and computer program
JP2003507824A (en) Guarantee system for performing electronic commerce and method used therefor
RU2170455C1 (en) Electronic system for executing financial transactions
JP2000067132A (en) Ic card for electronic cash and defray system using the same
MXPA97007739A (en) Instruments for defon electronic transfer

Legal Events

Date Code Title Description
AS Assignment

Owner name: MSYSTEMS LTD, ISRAEL

Free format text: CHANGE OF NAME;ASSIGNOR:M-SYSTEMS FLASH DISK PIONEERS LTD.;REEL/FRAME:019679/0287

Effective date: 20060405

AS Assignment

Owner name: SANDISK IL LTD, ISRAEL

Free format text: CHANGE OF NAME;ASSIGNOR:MSYSTEMS LTD;REEL/FRAME:019690/0151

Effective date: 20070101

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION