Recherche Images Maps Play YouTube Actualités Gmail Drive Plus »
Connexion
Les utilisateurs de lecteurs d'écran peuvent cliquer sur ce lien pour activer le mode d'accessibilité. Celui-ci propose les mêmes fonctionnalités principales, mais il est optimisé pour votre lecteur d'écran.

Brevets

  1. Recherche avancée dans les brevets
Numéro de publicationWO2005048082 A2
Type de publicationDemande
Numéro de demandePCT/US2004/037878
Date de publication26 mai 2005
Date de dépôt12 nov. 2004
Date de priorité12 nov. 2003
Autre référence de publicationWO2005048082A3
Numéro de publicationPCT/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
InventeursJohn L. Sokol
DéposantExsentrik Enterprises Inc.
Exporter la citationBiBTeX, EndNote, RefMan
Liens externes:  Patentscope, Espacenet
Electronic commercial transaction system and method
WO 2005048082 A2
Résumé
A secure electronic commercial transaction system and method wherein electronic wallets and merchant sales devices exchange identification codes and identification codes and values of electronic monetary tokens and then simultaneously, independently communicate with a token issuing authority which compares the independently-transmitted identification codes of the devices and the identification codes and values of the electronic tokens and approves the transactions if all values match. The electronic wallet or the merchant sales device may communicate with the token authority through the other device via a secure funneling electronic communication protocol.
Revendications  (Le texte OCR peut contenir des erreurs.)
What is claimed:
1. A method of conducting electronic commercial transactions, comprising: providing a portable electronic wallet having a transceiver and a memory and having a unique identification code and a plurality of electronic monetary tokens stored in said memory; each electronic monetary token representing a fixed value of currency and including a unique identification code and a value; providing a merchant sales device having a transceiver and a memory and having a unique identification code stored in said memory; providing a token issuing authority having a database containing records of said electronic monetary tokens stored in said memory of said electronic wallet, said electronic monetary tokens being associated to said identification code of said electronic wallet in said database, said token issuing authority receiving a first electronic communication from said electronic wallet including said identification code of said electronic wallet, an identification code of at least one tendered electronic monetary token, a value of said tendered electronic monetary token and said identification code of said merchant sales device; said token issuing authority receiving a second electronic communication from said merchant sales device including said identification code of said electronic wallet, said identification code of said tendered electronic monetary token, said value of said tendered electronic monetary token and said identification code of said merchant sales device; said token issuing authority confirming said first and second electronic communications by comparing identification codes of said electronic wallet, said merchant sales device and said tendered electronic monetary token, and comparing said value of said tendered electronic monetary token, as received in said first and second electronic communications; said token issuing authority validating said tendered electronic monetary token by comparing said identification code of said electronic wallet and said identification code and said value of said tendered electronic monetary token to said records in said database; and said token issuing authority sending a transaction approval message to said merchant sales device if both said step of confirming said first and second electronic communications and said step of validating said tendered electronic monetary token result in a match.
2. A method as in claim 1, further comprising: - said merchant sales device transmitting a purchase price to said electronic wallet; said electronic wallet transmitting said identification code of said electronic wallet and said value of said tendered electronic monetary token to said merchant sales device.
3. A method as in claim 1, further comprising: one of said merchant sales device and said electronic wallet communicates with said token issuing authority through another one of said merchant sales device or electronic wallet via a secure electronic communication protocol.
Description  (Le texte OCR peut contenir des erreurs.)

ELECTRONIC COMMERCIAL TRANSACTION SYSTEM AND METHOD

Field of the Invention

[0001] 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

[0002] FIG. 1 is a schematic diagram of the method and system of the present invention.

Detailed Description of the Preferred Embodiments

[0003] 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.

[0004] 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.

[0005] 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.

[0006] 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.

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] 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.

[0012] 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.

[0013] 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.

[0014] 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.

Citations de brevets
Brevet cité Date de dépôt Date de publication Déposant Titre
US5642419 *19 déc. 199524 juin 1997Citibank N.A.Method for acquiring and revalidating an electronic credential
US5963924 *26 avr. 19965 oct. 1999Verifone, 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 19979 nov. 1999Turk; James J.Electronic cash eliminating payment risk
US6029150 *4 oct. 199622 févr. 2000Certco, LlcPayment and transactions in electronic commerce system
US6453127 *26 sept. 199717 sept. 2002Nexpress Solutions LlcEstablishment at a remote location of an internet/intranet user interface to a copier/printer
US20010027116 *22 mars 20014 oct. 2001Ncr CorporationElectronic wallet
US20020165831 *30 mars 20017 nov. 2002Michael HornElectronic payment method and system for carrying out the same
Référencé par
Brevet citant Date de dépôt Date de publication Déposant Titre
EP2518976A1 *27 avr. 201231 oct. 2012Crédit Mutuel ArkeaSystem and method for face-to-face payment between bank accounts
US20150254662 *26 août 201410 sept. 2015Mastercard International IncorporatedVerifying transaction context data at wallet service provider
Classifications
Classification internationaleG06F
Classification coopérativeG06Q30/00
Classification européenneG06Q30/00
Événements juridiques
DateCodeÉvénementDescription
26 mai 2005AKDesignated 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 2005ALDesignated 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. 2005121Ep: the epo has been informed by wipo that ep was designated in this application
17 janv. 200732PNEp: 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. 2007122Ep: pct application non-entry in european phase