EP1234223A2 - Systeme et procede pour effectuer des transactions electroniques sures - Google Patents

Systeme et procede pour effectuer des transactions electroniques sures

Info

Publication number
EP1234223A2
EP1234223A2 EP00989685A EP00989685A EP1234223A2 EP 1234223 A2 EP1234223 A2 EP 1234223A2 EP 00989685 A EP00989685 A EP 00989685A EP 00989685 A EP00989685 A EP 00989685A EP 1234223 A2 EP1234223 A2 EP 1234223A2
Authority
EP
European Patent Office
Prior art keywords
transaction
transaction number
proxy
customer
account
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.)
Withdrawn
Application number
EP00989685A
Other languages
German (de)
English (en)
Inventor
Michael Tsur
Naftali Bennett
Lior Golan
Ben Enosh
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.)
Cyota Inc
Original Assignee
Cyota Inc
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 Cyota Inc filed Critical Cyota Inc
Publication of EP1234223A2 publication Critical patent/EP1234223A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes

Definitions

  • the present invention relates to a system and method which substitutes proxy transaction numbers for real credit card numbers and other financial account identifiers during electronic transactions. Further, by substituting proxy transaction numbers that can be used in an identical manner to conventional credit card numbers, a customer can conduct online transactions without ever exposing a genuine credit card number to misuse. As well, charges can be applied to financial accounts other than credit cards (i.e., debit cards and checking accounts), and transactions can be conducted via wireless devices.
  • a customer points web browsing software to an address where a retailer's online "store" is located.
  • the customer browses the product selection displayed at the website and determines which products they wish to purchase.
  • the retailers' website presents the customer with an order form asking for the customer's name, address, payment information, etc.
  • the customer fills out the order form, including their credit card number and submits the form to the retailer's website for processing.
  • the retailer's website submits the credit card number offered by the client for authorization; and upon approval of the credit card ships the products or services offered to the customer at the address specified on the order form.
  • the central server then generates the transaction number and associates it with the customer's real credit card number.
  • the proxy number is then sent to the customer who forwards it to the merchant.
  • the merchant uses the proxy number to obtain a credit card authorization and to submit charges to the customer card's issuing bank as though the proxy number were a real credit card number.
  • While the '810 patent discloses a method of conducting online transactions which avoids sending a customer's actual credit card number over the internet, it does not provide an adequate solution to the problem associated with securing credit card numbers for those consumers who already possess credit cards they wish to use in online transactions. To many consumers, applying for and obtaining an additional credit card is undesirable. Moreover, obtaining a credit card that is useful for the limited exclusive purpose of conducting online transactions is particularly burdensome, due to the annual fees many credit card issuers charge to those people who primarily use their credit cards for day-today activities in conventional retail establishments and only purchase products from online retailers on an occasional basis.
  • the '810 patent only addresses the substitution of proxy transaction numbers for credit card account numbers that are in the conventional sixteen (16) digit format. Many debit cards have nineteen (19) digit account numbers and the number of digits in a checking account can vary based on the institution that created the account. The '810 patent, therefore, does not describe a system or method which can accommodate the needs of those persons which wish to make online purchases using debit or checking account numbers.
  • 99/49424 discloses that it is preferable to generate the limited use numbers in large batches and forward them to customers for use at a later time.
  • persons without credit cards could purchase disposable credit cards with a credit limit equal to the purchase amount of the disposable card.
  • the disposable credit cards would offer security by having a credit limit equal to the purchase amount of the disposable card. This method, however, offers less security than a conventional credit card which typically limits the risks to the customer to the first $50 of fraudulent purchases. The purchaser of a disposable credit card would risk losing the entire unused balance on the disposable card if the credit card number was stolen and misused.
  • the present invention is directed toward a system and method which generates and substitutes transaction numbers for actual customer account numbers.
  • the proxy numbers are generated within a client user interface located on a customer's computer and sent to a central server for activation and cross-referencing with a customer's financial account.
  • notification is sent to the client user interface, by the central server, indicating that the proxy number is available and has been reserved for use the customer.
  • the client user interface To create the transaction number that the customer eventually sends to the merchant, in place of an actual credit card number, the client user interface must create a number that is in a format which is identical to a genuine credit card. To do this, the client user interface must create a 16 digit number that contains a BIN, or bank identification number, and a checksum.
  • the BIN is usually the first 2 to 7 digits of the credit card number.
  • the checksum digit is always the final digit of the credit card number. Accordingly, the proxy number generated by the client user interface should be from about 5 to 12 digits, to leave space for the BIN and checksum if the final transaction number is to be recognized in place of a credit card number.
  • the system can, of course, be used to prepare transaction numbers which can be used as proxies for numbers other than credit cards and can even be used to provide proxy data for personal information and non- numerical sequences.
  • Those skilled in the art will readily recognize the programming changes necessitated by a desire to provide proxies for information and numbers other than credit card data.
  • the specification will describe the generation of transaction numbers to be used as proxies for conventional credit card numbers over the internet as an ongoing example with a non-exclusive summary of other methods of use of the invention provided at the conclusion of the written description.
  • the transaction number Once the transaction number has been generated by the client, it is forwarded to a merchant to complete an online purchase for goods and services.
  • the merchant unaware that the credit card number received is a proxy for an actual credit card number, will forward the transaction number through current credit card association network routing systems, such as those operated by VISATM and MastercardTM.
  • the current credit card association network routing system receives authorization requests from merchants and evaluates the BIN (specifically, the card association network uses packet switched routing that is blind to individual credit card numbers, as a whole, and reads only the BIN portion of the entire card number.). Based on the BIN, the credit card association network routers forward the authorization request to the card issuer corresponding the BIN (each issuer has at least one, and usually many more, unique BIN numbers associated with it.)
  • the present invention contemplates the use of central servers having their own unique BINs, so that the credit card association network routers forward only proxy transaction numbers to the central servers. Non-proxy transaction numbers, i.e., real credit card numbers, are forwarded directly to the issuing bank or institution.
  • the central server of the present invention receives a transaction number it determines the real customer account from a cross-reference database and forwards the real account number along with the transaction routing number (also synonymously referred to as the network identification number, retrieval reference number and transaction-ID) to the issuing bank's authorization server.
  • the issuing bank's authorization server generates an authorization response based on the customer's real credit card number and forwards the response back to the central server.
  • the central server substitutes the transaction number for the real credit card account number and transmits the authorization response back to the network address specified by the credit card association network router.
  • the central server By cross-referencing the transaction number received for authorization with the transaction-ID number, the central server ensures that the correct proxy transaction number is returned to a merchant who requests an authorization, in instances where the customer has multiple transaction numbers active.
  • a merchant forwards the transaction number for settlement.
  • charges applied to transaction numbers are cross-referenced with real customer account numbers and substituted therefor so that the issuing bank can properly generate statements to send to cardholders.
  • central server places no restrictions on the format for actual credit card or financial account numbers, it is possible for customers to use debit card accounts (which typically includes nineteen (19) digits) or checking accounts to make purchases from online merchants that only accept credit card as a valid form of payment. Further, customers using wireless devices such as PDAs and cellular phones can purchase products from online retailers by having a proxy number generated which will associate the charges incurred thereon to their cellular or PDA online account.
  • the present system is not limited to the single use transaction numbers as taught by Franklin et al. in U.S. 5,883,810, or the limited use numbers taught in WO/9949424.
  • the present system allows for the generation of transaction numbers which must be used in accordance with rules applied by the central server and the customer. This allows a customer to obtain, for example, a proxy transaction number to be used for a long-term subscription.
  • the advantage to the customer is that they do not need to forward their actual credit card number to the subscription service and the customer can place a limit on the number of billing cycles during which charges can be applied.
  • the proxy transaction number could not be misused so as to incur liability to the issuer or the customer since most, if not all, transaction numbers will be limited to use by a single vendor, for specific amounts, or for any other criteria contemplated by the customer or the system administrator. An attempt to use a transaction number which does not fall within the criteria specified at the time of transaction number generation will not be authorized by the central server.
  • transaction numbers are generated for use by customers who do not possess any credit card accounts. These customers have debit card accounts that require the use of a pin number to authorization purchases. Many merchants, especially those who operate online, are not equipped to handle transactions involving debit cards.
  • the central server In order to provide a transaction number in place of a debit card account number the central server must associate the transaction number with a debit card account number and a debit card account pin number.
  • the central server cross-references the proxy number (which was used to generated the transaction number within the client user interface and cross referenced to the actual financial account by the central server at the time the proxy number was validated and reserved for use) to the debit card account number and pin number and forwards the actual customer data to the issuers authorization system.
  • the bank authorization server sends a positive reply to the central server of the present invention. The central server then forwards the reply to the network address from which the authorization request was received.
  • issuers who provided proxy transaction numbers for debit card account numbers create a transitory debit account into which fund are placed at the time an electronic transaction occurs using a transactions number.
  • settlement the funds are transferred from the transitory debit account to the credit account of the merchant.
  • transactions numbers are generated to allow wireless device users to purchase goods and services from online merchants.
  • the central server uses a single master credit account number to associated with all transaction numbers generated.
  • the central server also cross-references the transaction number with the wireless account number of the customer who purchased goods or services using a transaction numbers.
  • the wireless service provider can provide a detailed statement of charges to each individual customer.
  • Figure 1 is a diagram illustrating an electronic transaction system.
  • Figure 2 is a diagram illustrating a central server, a client computer, and an issuer computer and their relation to a credit card association network and merchant computer in an electronic transaction system.
  • Figure 3 depicts an electronic transaction system for a wireless device.
  • the present invention is directed toward an electronic transaction system in which proxy numbers are generated, formatted as transaction numbers and sent to merchants and processed as credit card numbers during electronic transactions.
  • proxy numbers are generated, formatted as transaction numbers and sent to merchants and processed as credit card numbers during electronic transactions.
  • a user account In order for a customer to use the electronic transaction system of the present invention, a user account must first be established on a central server.
  • a customer uses the client computer 20 to connect to the internet 10.
  • the customer Using a web browser installed on the client computer 20, the customer contacts a website operated in conjunction with central server 50 via the internet or other public network 10.
  • the website operating in connection the central server 50 will require a registration code be input by the customer operating the client computer 20.
  • the registration code can be sent from the issuing bank or institution to the customer in many ways: the registration code could be included in a monthly statement, sent by mail, or provided in any other manner that essentially ensures that the customer will receive the registration code.
  • the registration code has previously been crossed referenced to the customer's actual financial account established with the issuing bank or institution.
  • the issuing bank or institution may deactivate registration numbers after a short period of time so that unauthorized persons do not use the registration codes to establish electronic transactions system accounts on the central server.
  • the website operating in connection with the central server 50 may also require the customer operating the client computer 20 to enter personal information submitted to the issuing bank or institution at the time the financial account was created. Such information could include mother's maiden name, date of birth, social security number, or other information normally collected by financial institutions to verify the identify of a customer.
  • the software modules include a proxy number generator 28 and a client user interface 26, as shown in Figure 2.
  • a data file, not shown, which includes authorization and verification information and may also be encrypted can be sent to the client computer 20.
  • the transaction number generator 28 and the client user interface 26 can be combined into a single software download and even operate as a single software program on the client computer 20.
  • the client user interface 26 and proxy number generator 28 can be seamlessly integrated as an applet, i.e., a computer program running within another program, operating within the web browser 24.
  • the customer uses a web browser 24 to reach a merchant's computer 32 via the internet.
  • the customer operating the client computer 20 is now able to use the electronic transaction system 100 to purchase goods and services from a merchant's website operated at the merchant computer 30 over the internet 10 without having exposed a genuine credit card account number, or other financial account number, to interception by unscrupulous persons who "eavesdrop" on communications between merchants and customers on the internet to intercept credit card account information and make unauthorized purchases.
  • a customer points the web browser 24 on the client computer 22 to a website operated on a merchant computer 32 which displays goods or services that the customer wishes to purchase.
  • the website operated at the merchant's computer 32 submits a purchase and order form to the customer via the web browser 24 on the client computer 22.
  • personal information about the customer is requested such as a name, shipping address, telephone number and payment information.
  • the client user interface 26 will automatically recognize the order form submitted to the customer from the merchant computer 32 and will activate the proxy number generator 28 to initiate the generation of a proxy number.
  • the customer can manually activate the client user interface 26 to begin the process of generating a proxy number.
  • the customer will be prompted to enter authentication data such as a user identification number and password to verify that the customer operating the client computer 22 is authorized to conduct electronic transactions using the customer's credit card account or other financial account associated with the user account stored in the customer database 54 on the central server 52.
  • the client user interface 26 Assuming the client user interface 26 has received proper authorization from the customer using the client computer 22, the customer will then be asked to enter details regarding the nature of the transaction they wish to make. Such details may include the amount of the purchase, the identity of the merchant from which the purchase is to be made, whether the purchase is to be recurring in nature (such as a magazine subscription), etc. In one embodiment of the invention, this data is stored in the cache memory 25 of the client computer 22 and forms a set of transaction number usage limitations. The client user interface 26 then activates the proxy number generator 28 which generates a proxy number for the electronic transaction.
  • the client user interface 26 forwards the transaction number usage limitations and proxy number to the central server 52.
  • the central server 52 forwards the proxy number to the proxy number verifier and activator 57 to insure that the proposed proxy number is not already in use.
  • the proxy number verifier and activator 57 sends a response to the client user interface 26 indicating that the proxy number has been verified and activated and can be used in an electronic transaction.
  • the proxy number verifier and activator 57 records the proxy number in the proxy number database 58 as a proxy number transaction cross-reference.
  • the proxy number transaction cross reference record includes the proxy number and the actual customer financial account number.
  • the transaction number usage limitations sent from the client user interface 26 to the central server 52 are stored in the transaction number usage limitations database 53 with a cross-reference record to the proxy number to which they correspond.
  • the client user interface 26 Having received confirmation that the proxy number generated by the proxy number generator 28 is available for use by the customer in an electronic transaction, the client user interface 26 appends to the beginning of the proxy number a bank identification number ("BIN") and completes the generation of the transaction number by generating a "checksum” and appending that to the end of the proxy number.
  • BIN bank identification number
  • Transaction numbers differ from the proxy number by the inclusion of the BIN and checksum and generally contains 16 digits (when they are to be used as proxies for credit cards) and are in a format which is indistinguishable, to a merchant, from a conventional credit card number.
  • transaction numbers can be simulated in the same manner as credit cards numbers, so that anonymous data can be entered for people who wish to retain their privacy in electronic communications, while retaining the ability to allow authorized persons and entities to obtain a cross-referenced record containing the person's genuine data.
  • the transaction number will either be automatically inserted into the purchase and order form by the client user interface 26, or is manually transferred into the appropriate field on the order form by the customer. The customer then submits the form to the merchant computer 32 for further processing.
  • a server-based wallet can be used to fill in the purchase and order form for the user when asked by the merchant.
  • certain websites are recognized by the client user interface 26 and some information is automatically entered when these websites are used by the customer to make purchases.
  • the server may also recognize the website where the customer wishes to make a purchase and intercept the purchase and order form before it reaches the user's web browser 24.
  • the server-based wallet of the present invention completes the purchase and order form for the user and returns it directly to the merchant with a transaction number.
  • the merchant computer 32 Having received a transaction number, the merchant computer 32 will attempt to process the transaction number in the same manner it would process any conventional credit card number.
  • the merchant computer 32 forwards the transaction number to the credit card association network (usually through an "acquirer" which is the bank or institution used by the merchant to process credit card transactions).
  • the credit card association network i.e., the routing system for credit card transactions operated by major credit card companies such as MasterCard and Visa, then evaluates the BIN number which was appended to the proxy number by the client user interface 26. Based on the BIN number, the credit card association forwards the authorization request to the appropriate server.
  • transaction numbers include a BIN number so that at no point in the process is it necessary to distinguish transaction numbers which are proxies for actual credit card numbers from genuine credit card account numbers.
  • the credit card association network 42 will forward any transaction numbers received to the central server 52 for authorization processing. Further, with each authorization request forwarded from the credit card association network 42 to the central server 52 a retrieval reference number, i.e., transaction-ID or network identification number, is included to identify the originator of the authorization request.
  • the retrieval reference number will correspond to the merchant computer 32.
  • the central server 52 will remove the BIN number and checksum from the transaction number received in the authorization request, reducing the transaction number to the original proxy number. The central server will then compare the proxy number to cross-referenced records stored in the proxy number database 58 to determine the actual financial account number for the customer using the transaction number. Further, the central server 52 will compare the proxy number with the records stored in the transaction number usage limitation database 53 to determine what transaction number usage limitations were specified in the transaction number request originated by the customer. If any data received by the central server 52 as part of the authorization request from the merchant computer 32, does not meet the limitations stored in the transaction number usage limitations database 53 for the transaction number that is the subject of the authorization request, the central server will generate a rejection response and forward it to the merchant computer 32. This indicates to the merchant that the issuing bank or institution will not honor the charges for the requested credit transaction. In most circumstances, the merchant will refuse to deliver goods or services to the customer when the credit card transaction has been denied, or rejected, by the issuing bank or institution.
  • Some issuing banks or institutions may, in an alternate embodiment, nevertheless require transmitting the authorization request to their conventional authorization process, even in instances where the central server has determined that the transaction number submitted for authorization has not been used within the guidelines specified by the transaction number usage limitations. This is done prior to the central server 52 sending an authorization reply to the merchant computer 32 and may be done for accounting purposes or other reasons which the issuer decides are necessary to provide service to their customers or in instances where the issuer determines that they must issue the authorization rejections from their conventional authorization system.
  • the reasons why the central server 52 may send a rejection response to the merchant computer 32 can include factors such as where the merchant computer that requests the authorization response is not the merchant specified by the customer when the transaction number request was generated. Also, the purchase amount specified in the authorization request may exceed that which was specified by the customer at the time the transaction number request was made. If, for example, the proxy transaction number was intercepted by someone, other than the customer, who attempted to use it to purchase goods and services from a merchant other than that specified by the customer, the attempt would be foiled by the safeguard imposed by the transaction number usage limitations of the present invention.
  • the central server 52 When the data received in the authorization request from the merchant computer 32 meets the requirements imposed by the transaction number usage limitations, the central server 52 substitutes the actual financial account information for the customer for the transaction number and forwards the authorization request to the issuing bank or institution's computer 62 where it is handled by the authorization processor 65. Further, in conjunction with sending the authorization request to the issuer computer 62, the central server 52 stores within its cache memory 55 a temporary cross-reference record relating the retrieval reference number of the authorization request and the transaction number.
  • the authorization response is sent to the central computer 52 where the retrieval reference number is again cross-referenced with the correct transaction number and is substituted for the actual customer financial account number in the authorization response.
  • the central server 52 then forwards the authorization response to the network address specified within the retrieval reference number, i.e., the electronic address, specified in the authorization request, so that it is received by the merchant computer 32.
  • the central server 52 insures that the correct transaction number is associated with the correct authorization response in instances where the customer has multiple transaction numbers active at a given time.
  • the electronic transaction system allows customers with debit cards or checking accounts to conduct transactions with online merchants who otherwise only accept credit cards as an acceptable form of payment.
  • Such online merchants generally do not have debit accounts where they can immediately receive funds transferred from a customer's checking or debit card account.
  • the present invention contemplates the use of a transitory debit account to which the funds from the customer's checking or debit account are transferred immediately upon completion of the electronic transaction.
  • the function of the transitory debit account is simply to store funds until the merchant's acquiring bank or institution requests that the funds be transferred during the settlement, or clearance, process.
  • the funds are transferred to a transitory credit account and, therefrom, disbursed to merchants during the settlement process.
  • the function of the transitory credit account is to act as an intermediary account between the transitory debit account and a merchant's actual credit account, since it is not possible to transfer funds directly between a debit account and a credit account.
  • the merchant computer 32 receives a positive authorization response, i.e., or an approval, from the central server 52, the merchant computer 32 releases the goods or services for shipment to the customer.
  • a positive authorization response i.e., or an approval
  • the settlement process is the phase of the electronic transaction system wherein funds are dispersed by the issuing bank or institution to a merchant via the merchant's acquirer, i.e., the bank or institution which handles the credit card transactions processed by the merchant.
  • the acquiring bank associated with the merchant computer 32 prepares a "clearance file" containing an entry for each credit card transaction processed by the merchant computer for each issuing bank or institution. Since each transaction number used in accordance with the present invention contains a BIN number unique to the central server that verifies and activates it, an individual clearance file can be generated which details only the transactions conducted using transaction numbers.
  • the acquiring bank associated with the merchant computer 32 forwards the clearance file to the central server 52 through the card association network as a result of the central server 52 being identified by the card association network by its unique BIN, i.e., for all practical purposes the central server is viewed by the card association network as an independent issuer.
  • the central server 52 passes the clearance file and removes from each transaction number the BIN and checksum digits.
  • the remaining portion of the transaction number i.e., the proxy number
  • the remaining portion of the transaction number i.e., the proxy number
  • a new clearance file is created in which the customer's financial account number is substituted for the proxy number and includes the rest of the transaction information from the clearance file.
  • a flag, or identifier is placed in each record in the clearance file to identify to the issuing computer that each of the listed transactions was conducted using a transaction number. This can assist the issuing bank or institution's customer service department to quickly identify those situations in which an inquiry is received that is identified by a transaction number.
  • the clearance file is then forwarded to the issuer's payment processor 63 and processed according to the issuing bank or institution's conventional practices.
  • the clearance file may, as the flag, include the retrieval reference number associated with the transaction as a cross-reference identifier. Since the retrieval reference number will be unique to each credit card transaction processed by online merchants, this method of cross referencing avoids any ambiguity which could arise when transaction numbers are cross-referenced against customer's actual financial account numbers in instances where a customer has multiple transaction numbers active at a given time.
  • a transaction After a transaction has been completed between a customer and an online merchant, it is possible that either one of the parties involved may dispute or disagree with some aspect of the transaction.
  • a merchant who attempts to partially or fully cancel a transaction, i.e., for example where the goods or services are unavailable for shipment and money must be refunded to the customer, it is called a reversal.
  • a reversal Under the present invention, if a merchant attempts to fully or partially cancel a transaction they are likely to send the retrieval reference number included in the original authorization request with the transaction number via the card association network to the central server 52. If a significant period of time has passed, the central server may have deactivated or reissued the transaction number for reuse.
  • the transaction number is not issued for reuse for a period of at least six months from its original deactivation (deactivation occurs after the first authorization of a transaction number unless the transaction number usage limitations specified by the customer at the time the transaction number is requested specify that the transaction number is to be used more than once, as is the case in a recurring magazine subscription.)
  • the preferred embodiment of the present invention allows for the authorization of reversals in all instances. Further, if the transaction number included in the reversal request had previously been deactivated, it may be reactivated to allow for an additional transaction to occur using that transaction number. For example, in the situation where a customer orders particular goods or services from a merchant and that merchant obtains an authorization for a single use limited transaction number, the transaction number will be deactivated and can not be authorized if another authorization request is received using that transaction number.
  • the chargeback is where the card holder has disputed charges relating to a particular transaction number. This can arise where the customer has received defective goods, didn't get the product they requested, or finds unauthorized charges have been applied to their account.
  • the present system permits using the original clearance file to locate the proxy number used in the disputed transaction.
  • the transaction number is regenerated by appending thereto the BIN of the central server 52 prior to the first digit of the proxy number and the checksum after the last digit of the proxy number to recreate the 16 digit transaction number used by the merchant.
  • the remainder of the chargeback process is handled according to each issuing bank or institution ⁇ existing procedures.
  • Figure 3 depicts a wireless device 70 connected to a wireless service provider 80.
  • the wireless service provider 80 allows the user of the wireless device 70 to connect to the internet or other public network 12 and to browse the product selection of online merchants through a server which may be operated by the merchant's computer 34. Should the user of the wireless device 70 decide to purchase a product offered at the merchant's website on the merchant computer 34 the electronic transaction system of the present invention can be used with only slight modifications to the embodiment contemplated for use in conventional credit card transaction.
  • the wireless service provider 80 establishes a user account on the central server 90 with a master credit account. All charges applied to transaction numbers used for transaction conducted via wireless device are applied to the credit account of the wireless service provider 80.
  • the user of the wireless device 70 indicates through electronic means that they wish to purchase a particular product.
  • the website operating on the merchant computer 34 forwards the purchase and order form to the user of the wireless device 70 via the wireless service provider 80 the form is intercepted by the wireless service provider and, in one embodiment of the invention, the relevant information for the customer is provided by the wireless service provider; and, in another embodiment, the form is forwarded to the central server 90 to be completed.
  • the wireless service provider requests a transaction number be generated by the central server 90 and associated with the wireless account number, e.g., customer's telephone number or other identifier, and used to cross-reference the transaction number generated by the central server and the customer ordering the goods or services.
  • a proxy number is generated by the wireless service provider and sent to the central server 90 to be cross referenced against the account number of the user of the wireless device 70.
  • the central server verifies and activates the proxy number in the same manner as discussed in relation to conventional credit card transactions.
  • the central server 90 will cross reference the proxy number to the account number of the user of the wireless device 70 and respond to the wireless service provider 80 to indicate that the proposed proxy number has been activated for use.
  • the wireless service provider 80 will then generate a transaction number by appending to the proxy number a BIN, prior to the first digits of the proxy number, and by appending a checksum digit after the last digit of the proxy number.
  • the wireless service provider 80 then forwards the transaction number via the internet 12, or other public network, to the merchant computer 34 for further processing.
  • the merchant computer 34 prepares an authorization request and forwards it to the card association network 44 which then routes the request to the central server 90 based on the BIN included in the transaction number.
  • a unique BIN may be used for each wireless service provider to avoid the necessity of cross referencing between the transaction number and the actual customer account number during the authorization process.
  • the central server 90 each time the central server 90 receives an authorization request from the credit card association network 44, the account number of the wireless service provider 80 is substituted for the transaction number in the authorization request, and the authorization request is forwarded to the issuing bank or institution's computer to be handled by their conventional authorization process. Further, the central server 90 will cross-reference the transaction number received in the authorization request with the retrieval reference number contained in the authorization request, so that the central server 90 can properly route the authorization reply when it is received from the issuer computer 62.
  • the central server 90 When the central server 90 receives the authorization reply from the issuer computer 62, the account number of the wireless service provider 80 is substituted for with the transaction number included with the authorization request. To obtain the original transaction number, the central server cross references the retrieval reference number included in the authorization response from the issuer computer 62 to obtain the correct transaction number. The authorization response is then forwarded by the central server via the card association network 44 to the merchant's computer 34 containing the correct transaction number. The remainder of the wireless method functions in substantially the same manner as that previously described. However, an additional step in the settlement process is necessary in order to allow the wireless service provider 80 to properly reflect charges incurred by the user of the wireless device 70 and apply the charges to the monthly statement sent from the wireless service provider 80 to the user of the wireless device 70.
  • the additional step is to create a unique clearance file specific for the wireless service provider 80 by the central computer 90.
  • the central server 90 receives the clearance file for the BIN associated with the central server 90 from the credit card association network 44, the unique clearance file is generated by cross referencing each transaction number in the clearance file received from the card association network and substituting therefore the account number of the user of the wireless device 70 from which the request for each transaction number was initiated.
  • the unique clearance file is then forwarded to the wireless service provider 80 and the information stored therein is used to apply charges to the account of the user of the wireless device 70.
  • a person to person server is established that allows individuals to use transaction numbers to send money to one another for such things as purchases made in online auctions.
  • a person wishes to send money directly to another person, one way of transferring funds between them can occur if the first person requests a transaction number with a usage limitation specifying the amount of money they want to give to the second person.
  • a usage limitation specifying the amount of money they want to give to the second person.
  • amount if $1000.
  • the first person establishes a transaction number usage limitation of $1000 for the transaction number they request.
  • the person to person server then generates a transaction number (or alternately a proxy number is generated by the customer's client user interface and forwarded to the server for validation, activation, and cross-referencing with the customer ' s credit or financial account number and the transaction number is generated within the customer's client user interface software.)
  • the first person then forwards the transaction number to the second person as either payment for goods or services or, merely, as a gift.
  • the second person can use the transaction number as a prepaid credit card until the credit limit is met, at which time the transaction number will no longer be authorized by the person to person server.
  • the present invention contemplates that the first person ' s credit card is not charged for the amount of money sent to the second person until the second person actually uses the transaction number to obtain goods or services.
  • a benefit of the present invention is, also, that since the second person receives an transaction number in the form which is indistinguishable from a conventional credit card number, the transaction number can be used for any type of transaction where the physical, plastic credit card is not required (such as for telephone orders, etc.)
  • the present system and method provides the ability for parents, or other primary credit account holders to provide their children or corporations to provide their employees with credit card accounts that are proxies for a single, master account.
  • multiple user ID's and passwords are provided to a user to allow that user to generate transaction number requests relating to the same credit account which are each linked to a separate user account.
  • Each user can have transaction number usage limitations automatically applied to each of their transaction number requests which were specified by the master account holder at the time the individual user account was created.
  • a parent could specify the maximum total expenditures a child could make or an employer could give a credit card to an employee that can only be used for purchases from specified merchants.
  • Such a system is far superior to current methods where an employer may grant actual credit cards to their employees and have to face situations where employees use them irresponsibly or for personal use.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention concerne un système et un procédé qui permettent d'effectuer des transactions électroniques sûres. On décrit un système de serveur central qui peut traiter et corréler des numéros ou des données substitutifs remplaçant des données personnelles et des informations financières au cours de transactions pendant lesquelles des informations pourraient être interceptées, ou faire l'objet d'un usage illicite de la part du destinataire. Dans le mode préféré, des numéros de transaction sont utilisés par des clients pour cacher leur numéro de carte de crédit réel aux commerçants en ligne et aux personnes qui pourraient être tentées d'intercepter les numéros de carte de crédit utilisés dans les transactions en ligne.
EP00989685A 1999-10-22 2000-10-23 Systeme et procede pour effectuer des transactions electroniques sures Withdrawn EP1234223A2 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US16094599P 1999-10-22 1999-10-22
US160945P 1999-10-22
US20443900P 2000-05-15 2000-05-15
US204439P 2000-05-15
PCT/US2000/041480 WO2001029637A2 (fr) 1999-10-22 2000-10-23 Systeme et procede pour effectuer des transactions electroniques sures

Publications (1)

Publication Number Publication Date
EP1234223A2 true EP1234223A2 (fr) 2002-08-28

Family

ID=26857367

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00989685A Withdrawn EP1234223A2 (fr) 1999-10-22 2000-10-23 Systeme et procede pour effectuer des transactions electroniques sures

Country Status (5)

Country Link
EP (1) EP1234223A2 (fr)
JP (1) JP2003532170A (fr)
AU (1) AU2616501A (fr)
IL (1) IL149270A0 (fr)
WO (1) WO2001029637A2 (fr)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002366859A (ja) * 2001-06-11 2002-12-20 Sony Corp 与信仲介システム、与信仲介装置および方法、記録媒体、並びにプログラム
JP4363800B2 (ja) * 2001-06-11 2009-11-11 ソニー株式会社 電子商取引支援装置，電子商取引支援方法およびコンピュータプログラム
US7805376B2 (en) 2002-06-14 2010-09-28 American Express Travel Related Services Company, Inc. Methods and apparatus for facilitating a transaction
US6901387B2 (en) 2001-12-07 2005-05-31 General Electric Capital Financial Electronic purchasing method and apparatus for performing the same
US8689000B2 (en) 2003-05-21 2014-04-01 Hewlett-Packard Development Company, L.P. Use of certified secrets in communication
EP1733350A4 (fr) * 2004-03-26 2008-03-19 Citicorp Credit Services Inc Procedes et systemes d'integration de programmes de recompenses multiples
US8571980B1 (en) 2005-06-01 2013-10-29 Stragent, Llc System, method and computer program product for transferring money
JP4886365B2 (ja) * 2006-06-01 2012-02-29 ヤフー株式会社 本人確認を行う方法および当該方法を実現するサーバ
EA200900530A1 (ru) * 2006-10-12 2010-02-26 Нэткэш, Ллк Способ и устройство для осуществления анонимных онлайн покупок
JP4981461B2 (ja) * 2007-01-18 2012-07-18 株式会社日立製作所 情報秘匿化方法、および情報秘匿装置
US7841523B2 (en) 2007-05-17 2010-11-30 Shift4 Corporation Secure payment card transactions
EP2156397B1 (fr) * 2007-05-17 2019-06-26 Shift4 Corporation Transactions par carte de paiement sécurisées
US7891563B2 (en) 2007-05-17 2011-02-22 Shift4 Corporation Secure payment card transactions
US7770789B2 (en) * 2007-05-17 2010-08-10 Shift4 Corporation Secure payment card transactions
WO2020162706A1 (fr) * 2019-02-08 2020-08-13 주식회사 센스톤 Procédé, programme et système de fourniture de transaction financière fondée sur une carte d'entreprise virtuelle
JP6799097B2 (ja) * 2019-02-20 2020-12-09 ヤフー株式会社 情報処理装置、制御プログラム、情報処理方法及び情報処理プログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590197A (en) * 1995-04-04 1996-12-31 V-One Corporation Electronic payment system and method
US6138107A (en) * 1996-01-04 2000-10-24 Netscape Communications Corporation Method and apparatus for providing electronic accounts over a public network
US5822737A (en) * 1996-02-05 1998-10-13 Ogram; Mark E. Financial transaction system
US5930767A (en) * 1997-05-28 1999-07-27 Motorola, Inc. Transaction methods systems and devices
US5913203A (en) * 1996-10-03 1999-06-15 Jaesent Inc. System and method for pseudo cash transactions
US6061665A (en) * 1997-06-06 2000-05-09 Verifone, Inc. System, method and article of manufacture for dynamic negotiation of a network payment framework
US5949044A (en) * 1997-06-13 1999-09-07 Walker Asset Management Limited Partnership Method and apparatus for funds and credit line transfers
US6000832A (en) * 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
US6636833B1 (en) * 1998-03-25 2003-10-21 Obis Patents Ltd. Credit card system and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0129637A3 *

Also Published As

Publication number Publication date
AU2616501A (en) 2001-04-30
WO2001029637A2 (fr) 2001-04-26
JP2003532170A (ja) 2003-10-28
IL149270A0 (en) 2002-11-10
WO2001029637A8 (fr) 2002-01-24
WO2001029637A3 (fr) 2001-09-13

Similar Documents

Publication Publication Date Title
US7835960B2 (en) System for facilitating a transaction
EP1221146B1 (fr) Systeme de traitement de paiement sur et efficace
RU2438172C2 (ru) Способ и система для осуществления двухфакторной аутентификации при транзакциях, связанных с заказами по почте и телефону
US8396810B1 (en) Centralized authorization and fraud-prevention system including virtual wallet for network-based transactions
US9430769B2 (en) Secure and efficient payment processing system
US20050027617A1 (en) Third party privacy system
US20010051902A1 (en) Method for performing secure internet transactions
US20040254848A1 (en) Transaction system
EP1421732B1 (fr) Systeme de transaction
EP1234223A2 (fr) Systeme et procede pour effectuer des transactions electroniques sures
EP1095345A1 (fr) Systeme assurant la confidentialite de tiers
AU775065B2 (en) Payment method and system for online commerce
JP2001297286A (ja) 認証システム
KR20060124375A (ko) 거래 시스템 및 이 시스템을 통한 사용자 인증 방법
EP1744518A2 (fr) Système de transaction

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020517

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: TSUR, MICHAEL

Inventor name: BENNETT, NAFTALI

Inventor name: GOLAN, LIOR

Inventor name: ENOSH, BEN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20030501