|Numéro de publication||WO2005048082 A2|
|Type de publication||Demande|
|Numéro de demande||PCT/US2004/037878|
|Date de publication||26 mai 2005|
|Date de dépôt||12 nov. 2004|
|Date de priorité||12 nov. 2003|
|Autre référence de publication||WO2005048082A3|
|Numéro de publication||PCT/2004/37878, PCT/US/2004/037878, PCT/US/2004/37878, PCT/US/4/037878, PCT/US/4/37878, PCT/US2004/037878, PCT/US2004/37878, PCT/US2004037878, PCT/US200437878, PCT/US4/037878, PCT/US4/37878, PCT/US4037878, PCT/US437878, WO 2005/048082 A2, WO 2005048082 A2, WO 2005048082A2, WO-A2-2005048082, WO2005/048082A2, WO2005048082 A2, WO2005048082A2|
|Inventeurs||John L. Sokol|
|Déposant||Exsentrik Enterprises Inc.|
|Exporter la citation||BiBTeX, EndNote, RefMan|
|Citations de brevets (7), Référencé par (2), Classifications (3), Événements juridiques (5)|
|Liens externes: Patentscope, Espacenet|
ELECTRONIC COMMERCIAL TRANSACTION SYSTEM AND METHOD
Field of the Invention
 The invention pertains to the field of commercial transaction systems and methods, and in particular to a secure wireless commercial transaction system and method suitable for public networks.
Brief Description of the Drawing
 FIG. 1 is a schematic diagram of the method and system of the present invention.
Detailed Description of the Preferred Embodiments
 Referring to FIG. 1, the invention is particularly suitable for consumer transactions wherein the consumer uses a portable electronic wallet device 10 (such as a cell phone, personal digital assistant, wristwatch, etc.) to authorize a payment to a merchant.
 In the method, each electronic wallet 10 has a unique electronic wallet identification number (EWID). An issuing bank 12 acts as a token issuing authority and issues electronic monetary tokens to the electronic wallet 10, where each token has a fixed value that represents an amount of currency. Each token is assigned a unique token identification number (token ID), which is preferably a very large number (e.g., 1024 bits). Token IDs may be non-sequential to improve security. The token ID may also include an issuer identification code (Issuer ID) to identify the issuing bank (such as an ABA routing number, or the like), and a checksum value to check the validity of the token ID, issuer ID and/or token value.
 The fixed value of each token may be one of $0.01, $0.02, $0.04, $0.08, $0.16, $0.32, $0.64, $1.28, $2.56, etc., up to some predetermined maximum currency value. In other words, the value of each token is fixed at $0.01 multiplied by 2 to the Nth power, where N is a whole number from 0 to some predetermined maximum value. Providing tokens in these binary, exponential multiples (i.e., 1, 2, 4, 8, 16, 32, etc.) of a minimum currency value (i.e., $0.01) optimizes the "flow" of tokens. That is, if a user device has one of every token up to a maximum token value, the user device will be able to redeem an exact amount for any purchase price up to the sum of all of the tokens. However, other denominations are also suitable, such as $0.01, $0.05, $0.10, $0.50, $1.00, $5, $10, $20, $50, $100, like current paper and coin currency.
 Tokens are purchased by consumers by transferring cash or debt to the issuing bank 12. The IDs and values of purchased tokens are loaded into the consumer's electronic wallet 10. The issuing bank 12 compiles a database of issued tokens, which includes the token IDs, the values of the tokens, and the IDs of the electronic wallets 10 to which the tokens were issued.
 During a transaction, there is an electronic communication 16, 18 between the electronic wallet 10 of the consumer and a merchant sales device 14 (such as a vending machine, kiosk, point-of-purchase system, or the like). There is also an electronic communication 20 between the electronic wallet 10 and the issuing bank 12, and an electronic communication 22 between the merchant sales device 14 and the issuing bank 12.
 At the beginning of the transaction, the electronic wallet 10 receives a purchase price from the user as transmitted by the merchant sales device 14. The electronic wallet 10 then determines if it contains sufficient tokens to satisfy the purchase price. If enough tokens are present and the consumer authorizes the purchase, the consumer or, preferably, the electronic wallet 10 determines which of the tokens should be tendered to pay for the product or service. The token ID(s) and value(s) of the tokens selected to be tendered, and the ID of the electronic wallet 10 are then transmitted to the merchant sales device 14. Preferably the communication between the consumer's electronic Wallet 10 and the merchant sales device 14 is wireless, for example, via the IRFM Infra-Red Financial Messaging standard, which uses the Infrared Data Association (IrDA) transmission standard.
 In the next step of the transaction, the merchant sales device 14 and the electronic wallet 10 communicate independently with the bank 12 that issued the tokens. In each case, the token ID(s) and value(s), the electronic wallet ID and preferably the merchant sales device ID are transmitted to the issuing bank 12. If the information received from the merchant sales device 14 matches that from the electronic wallet 10, and if the tendered token ID(s) and values and the electronic wallet ID match the database records of valid tokens at the issuing bank 12, then the issuing bank 12 responds separately to the merchant sales device 14 and the electronic wallet 10 validating the transaction. In addition, the issuing bank 12 marks the used tokens in the valid token database as being redeemed.
 Preferably, the communication with the issuing bank 12 is, at least partially, via the public Internet 24. For example, the merchant sales device 14 may communicate with the issuing bank 12 via solely the public Internet 24, and the electronic wallet 10 of the consumer may communicate with the issuing bank 12 via the cellular phone network 26, as a first segment, and then the public Internet 24, as a second segment. While the public Internet 24 is a particularly suitable network, private networks are also suitable.
 Upon receipt of the validation response from the issuing bank 12, the electronic wallet 10 removes the used tokens from its database (or marks them as used) and the merchant sales device 14 authorizes the release of the product or service. Immediately thereafter, or at some future time, cash or a credit equal to the purchase price is transferred from the issuing bank 12 to a merchant bank 28 via any suitable means, such as Electronic Funds Transfer (EFT) 30.
 In the case where the consumer's electronic wallet 10 does not contain a combination of tokens that would produce the exact purchase price, the electronic wallet 10 may overpay for a product or service. The merchant sales device 14 and the electronic wallet 10 would then both transmit the purchase price to the issuing bank 12, in addition to the other information described above. Upon validating the transaction, the issuing bank 12 will pay/credit the merchant with the purchase price and will refund/credit the consumer with the overpayment. Preferably, the issuing bank 12 will refund the overpayment to the consumer by issuing new token(s) to the consumer's electronic wallet 10, which can be effected during the validation communication between the issuing bank 12 and the electronic wallet 10 or at a later time.
 For a transaction to be secure, both the electronic wallet 10 and the merchant sales device 14 must communicate with the issuing bank 12 at the time of the transaction. Insecure transactions can occur if the merchant sales device 14 communicates with the issuing bank 12 after releasing the goods or service to the buyer. However, this transaction will be unsecured and at the risk of the seller. To reduce the risk of such "off- line" transactions, each electronic wallet 10 may include a visible hologram containing all or part of the electronic wallet ID which can be verified by a human operator or a machine.
 The merchant sales device 14 or the electronic wallet 10 may communicate with the issuing bank 12 through one another if necessary. This may be necessary, for example, if the merchant sales device 14 is a vending machine without a connection to the public Internet 24. In this case, the electronic wallet 10 could act as a router connecting the merchant sales device 14 with the issuing bank 12. The communication between the merchant sales device 14 and the issuing bank 12 would be through a secure encrypted tunnel using SSH or SSL, or a similar protocol, where the issuing bank 12 and the merchant sales device 14 have previously exchanged encryption keys unknown to the electronic wallet 10 or consumer. Thus, the electronic wallet 10 could not understand or imitate the communication between the merchant sales device 14 and the issuing bank 12. Where only the merchant sales device 14 is able to connect to the issuing bank 12, the electronic wallet 10 could communicate through the merchant sales device 14 in a similar manner.
|Brevet cité||Date de dépôt||Date de publication||Déposant||Titre|
|US5642419 *||19 déc. 1995||24 juin 1997||Citibank N.A.||Method for acquiring and revalidating an electronic credential|
|US5963924 *||26 avr. 1996||5 oct. 1999||Verifone, Inc.||System, method and article of manufacture for the use of payment instrument holders and payment instruments in network electronic commerce|
|US5983207 *||26 août 1997||9 nov. 1999||Turk; James J.||Electronic cash eliminating payment risk|
|US6029150 *||4 oct. 1996||22 févr. 2000||Certco, Llc||Payment and transactions in electronic commerce system|
|US6453127 *||26 sept. 1997||17 sept. 2002||Nexpress Solutions Llc||Establishment at a remote location of an internet/intranet user interface to a copier/printer|
|US20010027116 *||22 mars 2001||4 oct. 2001||Ncr Corporation||Electronic wallet|
|US20020165831 *||30 mars 2001||7 nov. 2002||Michael Horn||Electronic payment method and system for carrying out the same|
|Brevet citant||Date de dépôt||Date de publication||Déposant||Titre|
|EP2518976A1 *||27 avr. 2012||31 oct. 2012||Crédit Mutuel Arkea||System and method for face-to-face payment between bank accounts|
|US20150254662 *||26 août 2014||10 sept. 2015||Mastercard International Incorporated||Verifying transaction context data at wallet service provider|
|26 mai 2005||AK||Designated states|
Kind code of ref document: A2
Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW
|26 mai 2005||AL||Designated countries for regional patents|
Kind code of ref document: A2
Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG
|20 juil. 2005||121||Ep: the epo has been informed by wipo that ep was designated in this application|
|17 janv. 2007||32PN||Ep: public notification in the ep bulletin as address of the adressee cannot be established|
Free format text: COMMUNICATION PURSUANT TO RULE 69 EPC (EPO FORM 1205A OF 061006)
|25 juil. 2007||122||Ep: pct application non-entry in european phase|