+

WO2003012714A1 - Systeme de securite pour transactions - Google Patents

Systeme de securite pour transactions Download PDF

Info

Publication number
WO2003012714A1
WO2003012714A1 PCT/NZ2002/000142 NZ0200142W WO03012714A1 WO 2003012714 A1 WO2003012714 A1 WO 2003012714A1 NZ 0200142 W NZ0200142 W NZ 0200142W WO 03012714 A1 WO03012714 A1 WO 03012714A1
Authority
WO
WIPO (PCT)
Prior art keywords
tan
bank
payer
payee
transaction
Prior art date
Application number
PCT/NZ2002/000142
Other languages
English (en)
Inventor
Karen Elizabeth Courtney
Original Assignee
Karen Elizabeth Courtney
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 Karen Elizabeth Courtney filed Critical Karen Elizabeth Courtney
Publication of WO2003012714A1 publication Critical patent/WO2003012714A1/fr

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
    • 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/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes

Definitions

  • This invention relates to a system for enhancing the security of a financial transaction; such as a transaction between a person and a bank or other financial institution, or between one financial institution and another, and more particularly this invention relates to a system for authenticating or authorising such a transaction.
  • TAN - Transaction Authorisation Number Vendor - refers to the intended recipient of the transaction regardless of whether any goods or services are given in return. This term is interchangeable with Payee, Seller or recipient. This person is the intended recipient of monies and / or information with regard to a transaction from the Purchaser.
  • Payee - refers to the intended recipient of the transaction regardless of whether any goods or services are given in return. This term is interchangeable with Vendor, Seller or recipient. This person is the intended recipient of monies and/or information with regard to a transaction from the Purchaser.
  • Payer - refers to the person making the TAN request regardless of whether any goods or services are given in return. This term is interchangeable with Purchaser or Buyer. This also refers to anyone from whom instructions for a transaction are taken. Person - Individual, Company, Corporation, Governmental Institution, Partnership, Charitable Trust, Incorporated Society, or any group of individuals who is a party to the transaction. The terms he, his, him, her(s) she, you or your(s) are interchangeable with any of these descriptions.
  • Bank - refers to any institution with whom the Purchaser's monies, stocks, bonds or shares are held, or where they have a deposit or credit facility.
  • Transaction - refers to any passing of monies or any form of instruction for a Transaction between parties regardless of whether any goods or services are given in return.
  • Credit Card refers to either a credit facility or other facility whereby the card account or credit account can be used in making a payment.
  • Validated Once the Vendor has presented the TAN to the bank, the payment of funds are then validated if the TAN has not been cancelled prior by the Purchaser.
  • Non-validated If the Purchaser cancels the transaction prior to presentation to the bank by the Vendor of the TAN, then monies are not passed to the Vendor and the transaction is void.
  • TAN request - Refers to the point where the Purchaser requests their Bank, for a TAN and supplies specific information regarding the transaction at that time to their Bank.
  • TAN cancellation - Refers to the point prior to validation of the TAN where the Purchaser for whatever reason decides he does not want to proceed with the Transaction and notifies his Bank from whom the TAN has been authorised that the TAN is cancelled.
  • this invention provides a device for assisting in execution of any one of a variety of financial transactions between a payer and a payee, such as a transfer of funds from a payer account held in a payer bank (the term "bank” is as previously defined), to a payee account held in a payee bank, wherein the device (hereinafter called the TAN) comprises a unique string of human-readable characters created in a medium by secure software at the payer bank and made available to the payer for forwarding to the payee and in turn to the payee bank in order to identify and authorise the transfer; the TAN including (a) at least part of a descriptor capable of determining the source of the funds, (b) at least part of a descriptor capable of determining the destination of the funds, and (c) a description of the funds to be transferred; the TAN having an effective lifetime which ceases on completion of the transaction
  • the level of security operating within the bank is not compromised by existence of the TANS function.
  • the invention provides a method for assisting in execution of a financial transaction between a payer and a payee such as a transfer of funds from a payer account held in a payer bank (the term "bank” is as herein defined), to a payee account held in a payee bank, wherein the method includes the creation of a TAN by secure bank software upon initiation of the transfer; the TAN being made available to the payer for forwarding to the payee as proof of availability of funds; the TAN including at least part of a descriptor capable of dete ⁇ nining the payer account, and at least part of a descriptor capable of determining the payee account; the TAN further includes a description of the funds to be transferred, so that the TAN is capable of use as an identifier for, and as authorisation for the transaction, and having an effective lifetime which ceases on completion of the transaction.
  • the level of security operating within the bank is not compromised by performance of the TANS function.
  • the TAN further includes a randomly generated or non-deterministically generated component which might be based on a fast real-time clock.
  • the environmental information includes date and time.
  • the TAN is converted into an encrypted form, so that it is relatively infeasible for a person lacking an appropriate recovery algorithm to recover information 100 pertaining to the translation.
  • the TAN comprises said information encrypted into a second form, and capable of being decrypted back into the first form.
  • the TAN is converted into a human-compatible shortened form, so that it is easier for any persons involved in the financial transaction to reliably communicate the TAN 105 between themselves by oral, written, or like means including allowances or human error.
  • the TAN is provided with at least one character capable of representing an outcome of a self-check procedure, so that subsequent repetition of the self-check procedure is capable of indicating any corruption of the TAN.
  • the invention provides a form of debit banking, wherein the method for 110 enhancing the security of a financial transaction as previously described in this section requires an availability of sufficient funds within the payer account as a prerequisite for construction of the TAN, so that existence of the TAN serves to indicate to a payee that sufficient funds have been set aside and that the transaction is able to be completed.
  • the invention provides a method for allowing an intending purchaser 115 (payer) entitled to use a payer account within a payer bank to purchase a purchaser's goods or services on a debit basis in a public environment at risk of interception of data by an unauthorised person, wherein the method includes that the payer: presents a request for a TAN to the payer bank, identifying the payer account, specifying the cost of the goods or services, and specifying the location of a payee account within a payee 120 bank, whereupon the payer bank attempts to set aside funds, verifies if possible that funds have been set aside, and generates a corresponding TAN including information describing (1) identifying at least in part the payer account, (2) the cost of the goods or services, and (3) at least in part the identity of the payee account, receives the TAN from the payer bank, 125 forwards the TAN to a vendor (the payee) of the goods or services, so that the payee can present the TAN to the payee bank thereby
  • the invention provides a method of implementing an e-commerce transaction, for allowing an intending purchaser (payer) entitled to use a payer account within a payer bank to purchase a purchaser's goods or services on a debit basis over the world-wide 135 web, characterised in that the method includes use of a personal computer connected to the world-wide web and hence capable of facilitating communications between one or more of (1) the buyer (payer), (2) a TAN-capable payer bank, (3) the vendor (payee) and (4) the vendor bank, so that the personal computer connected to the world-wide web is capable of implementing a rapid TAN-based debit payment from the payer to the payee.
  • the invention provides a digital computer running a set of instructions capable of causing the method previously described in this section to be put into effect.
  • digital computer when running the above-mentioned software, is capable at least of:
  • the set of rules includes a randomisation step.
  • the digital computer is one also at least in part entrusted with the running of the accounting software of a bank or other financial institution, or alternatively is in communications with other computers that are so entrusted, so that security measures used 155 within the bank in general are inherently applied to the generation and utilisation of TANS.
  • Fig 1 is a block diagram showing a person-to-person transaction involving a TAN generated by a purchaser's bank computer in software according to the invention.
  • Fig 2 also a block diagram, shows a simple TAN payment flow pattern, involving a TAN generated by a purchaser's bank computer in software according to the invention.
  • Fig 3 shows a foreign-exchange TAN payment flow, involving a TAN generated by a
  • the TANS For each transaction, the TANS involves the automated generation of a unique authorisation code which provides instructions to a bank or other intermediary to facilitate the transaction.
  • TANS is a system implemented as computer code that sits inside the bank's existing security 170 structures and firewalls. It resides as a layer on top of the bank's existing payments systems, from where it gives the purchaser a means of authorising an individual, specific transaction by issuing a unique transaction number that will facilitate payment. Note that the purchaser's account details are not passed to the other party of a transaction and are thereby kept as secure as the bank's security system allows.
  • the unique transaction number is generated within an algorithm by taking specific data elements of the transaction and converting them into a string of numbers. This resulting number may have, but does not necessarily have a component derived from additional, random or otherwise undetermined numbers such as instant time. A mathematical algorithm is then passed over these identifying numbers reflecting the transaction to produce a shortened and
  • TAN 180 more convenient, manageable transaction number consisting of alpha and/or numeric characters.
  • a checksum is included, so that any change made to a character after TAN generation can be identified.
  • a TAN to be passed between people might be written as "EH8 9JR PX7 221" which is not difficult to relay accurately, verbally or in writing. It may be useful for the TAN generator to screen out confusingly similar sounds such as M - N,
  • a TAN used within computers, such during an e-commerce transaction, is free of length and similarity constraints.
  • the TAN is specific to that one transaction. If the number is found and used by another party, it will be of no value to them other than to pay for the purchaser's intended transaction.
  • the TAN has a brief life. It expires as soon as the transaction is completed. In some circumstances, it may remain available for only a few days at most, after which the reserved funds are returned to the payer's account.
  • TANs each created as an authorisation for a specific type of 195 transaction.
  • Any transaction involves a set of descriptors capable of identifying it as unique: derived from the persons, the amount, and the instant of time at which the transaction is said to occur. For example:
  • the Payer a) The Payer's Date of birth or Company Incorporation or Registration 200 b) The number of the Payer's Bank e.g. 050 c) The number of the Branch or Authorisation Centre e.g. 252
  • Randomised element a) Optionally, one or more randomly produced numbers can be included. A number made by concatenating all numerals involved is large (at about 60 characters) and
  • the number can then be converted into a compressed representation by passing it through a mathematical algorithm in order to provide a smaller alphanumeric string (the TAN of this invention) suitable to be passed to the Vendor.
  • This number is always linkable back to the parties and elements of the Transaction that uniquely identify it. That is, the algorithm can be run in reverse to at least
  • TAN 220 confirm that a specific shortened form TAN could have been made from the full set of descriptors.
  • This algorithm may be as simple as converting the string of base-ten (decimal) numbers into base-36 numbers using 0-9 and A-Z to represent the new set of digits. In that case, though, the TAN could be unpacked easily by a hacker in order to ascertain the participants' account 225 numbers. Further processing, such as a rearrangement of the numbers to be packed in a prescribed way, is likely to be required. Alternatively, known methods of data compression such as Huffman codes may be used.
  • this algorithm forms a TAN which is self-confirming by including a checksum to indicate inadvertent or deliberate mis-communication. I also prefer that the algorithm also
  • checking means such as a list of all previous TANS made that day, or all currently valid TANs
  • the reader will be aware that as the TAN gets shorter and shorter, the risk of inadvertent duplication or other confusion rises. Note that the risk that a criminal will crack the TAN by generating and communicating a large number of guesses is not large, because if the
  • TAN has not been generated by the bank it will not be recognised and if it has already been issued it will facilitate a specific bank transfer between bona fide parties unrelated to the fraudster. I expect that the bank generating the TAN may directly communicate to the bank which is intended to receive the payment the TAN itself, if not more information.
  • TANs may be subject to a number of rules of use to be configured according to each market to be
  • the payer's age could be included within the portion of information that is specific to the transaction to assist in on-line and other age limited transactions.
  • the age information could be passed into the TAN as communicated between the people involved in the transaction without compression. This could alert a potential vendor that the potential purchaser is not 245 eligible for the goods requested. For example, it could caution a vendor who is a liquor wholesaler not to supply under-aged persons with alcohol.
  • NB Variations on how this can be structured may vary with each bank, dependent on the structure and options of their existing facilities, and the specific level of security required. For example, for a cash transaction, payee information may not be required.
  • Example 1 This scenario is a sale by a vendor to a purchaser, as shown in Fig 1.
  • Fig 1 is a block diagram 100 with time increasing downward, with marketplace actions at the left and intra- and inter-bank processes at centre and right.
  • An intending purchaser 101 wishes to purchase some item, shown here as goods or services 102.
  • the purchaser (who presumably has already arranged with his bank 103 to make use of the present invention) contacts his bank
  • 260 preferably by a form of digital telecommunications, alternatively voice, mail, or any other convenient means and using the security procedures previously arranged to verify that the person calling is in fact able to authorise payments from the nominated account 105. He makes a request for a certain amount of money 110 to be given a TAN (Transaction Authorisation Number) and set aside for collection. The bank computer now attempts to reserve the money
  • 270 channel 111 (preferably a form of digital telecommunications) if bidirectional.
  • a "transaction declined" type of error message may be returned if for example insufficient funds are available.
  • the purchaser 101 hands the TAN to the vendor 107, on a piece of paper, verbally, using a shift register, memory, or other storage means in a shared piece of electronic hardware, or the like.
  • the vendor requests his bank 108 to use the TAN to transfer funds into his (the vendor's)
  • the vendor's bank need not be particularly set up for TAN processing. All that is required is passing the code (plus destination account details) from bank 108 to bank 103, as a request for the immediate transfer of the funds from bank 103 to bank 108, normally in the usual virtual form. If the purchaser's bank software is able to locate the cited TAN, the funds are removed from the purchaser's account, the TAN is deactivated, and the funds are placed in
  • this block diagram shows that the payer (purchaser) 101 communicates securely with his bank 103 to provide the payee 107 (vendor's) name and bank sort code as sufficient details, together with the value of the purchase.
  • the payer bank 108 optionally communicates with the payee bank during establishment of a TAN and debiting of the payer's account, for better validation.
  • the TAN is returned (4d) to the payer, who passes it (5) to the payee who then passes the TAN top his bank, which returns it to the payer bank and at that time, payment (9) is made.
  • TAN for example it may be on a discarded scrap of paper
  • the vendor can learn the size of the payment at the time of the response from his bank.
  • Example 2 This scenario is that of a person entering retail premises to buy some goods or services.
  • the intending purchaser accesses his account, held by his bank.
  • One specific way may be over the Internet: another may be at a telecommunications-linked terminal analogous to an Eftpos 320 terminal, and a third way may be over one's digital cellphone, WAP phone, or using conventional branch or call centre facilities, or the like.
  • the next selection screen shows the following fields:
  • the purchaser may print the page (if facilities to print exist) and submits it by pressing the 'submit' field.
  • a TAN is calculated within the bank using the algorithm described previously, and sent to the purchaser's terminal for his use.
  • money from the purchaser's account is instantly set aside (or flagged) for this specific transaction and is not available for other use unless cancelled by the purchaser prior to submission of the TAN by the vendor. (This aspect gives the vendor more assurance that
  • the purchaser will be prompted to copy the TAN. Perhaps it will be printed if printing means are available, or perhaps a pencil and paper are called for. Usually, though, the whole process is likely to be occurring on a terminal at the vendor's premises, or while the purchaser is on the vendor's web site and is able to establish a secure connection to his bank 350 whether by phone or on-line from which purchaser obtains the TAN immediately the purchaser's call has ended. Otherwise the purchaser gives the TAN to the vendor.
  • the TAN however is media independent and could be used by a traditional bank customer who would go to a branch, obtain a number and pass it to the merchant either directly or by mail.
  • the vendor submits the TAN to his bank (requiring a second call to a new called party), which 355 immediately communicates on-line with the purchaser's bank to get verification of funds held under that same TAN at the purchaser's bank.
  • the TAN is disabled/exhausted at the purchaser's bank.
  • the vendor can instantly supply the goods that were purchased.
  • the purchaser's bank is in a position to immediately confirm details of the transaction that has just taken place to the 360 purchaser, optionally including the remaining funds in the account and optionally naming the person who claimed the money held under the TAN.
  • the precise details of the way the TAN will operate will depend upon the condition of use created by the bank with the customer, and the arrangements as to confirmation of an effective value in the purchaser's account. Users of the TAN may apply different rules as to when value 365 passes and when cancellation or retraction is possible.
  • the TAN is usable only once, as a kind of disposable validation certificate of the transaction. Also, because of the use of fine divisions of real time and the optional use of random numbers, a second TAN is most unlikely to resemble the first TAN. A would-be thief would, if they manage to obtain the real TAN, merely facilitate 370 the transaction by delivering it to the bank unless the TAN issued was a bearer or cash TAN.
  • Example 3 This scenario is that of a retailer who wishes to increase business by selling goods online, where the existing problem is that potential customers are reluctant to give banking or credit information over the Internet, to a non-secure site.
  • the solution using a TAN is as follows:
  • a print facility is available on this page to confirm the customer's initial submission.
  • TAN is given. Monies are instantly set aside (or flagged) on the customer's bank account for this specific transaction and are not available for other use unless cancelled by the customer. The customer will be prompted to copy the TAN (a macro can be set up for this, to cut and paste the number), and give the TAN to ABC Retailer. ABC Retailer submits this TAN immediately to his bank, which can get
  • ABC Retailer can instantly supply the goods purchased, and the customer's bank can confirm the transaction details to the customer immediately.
  • Example 4 This example scenario is that of a roofing contractor working for a house owner.
  • the solution using a TAN is as follows: 415
  • the roofing contractor having installed a new roof for the house owner, gives a physical (paper) invoice to the house owner via hardcopy in the usual way.
  • the house owner obtains a TAN from his bank to cover payment.
  • the roofing contractor phones his bank, using secure phone banking services of the type currently available, while a new option to receipt monies is now available.
  • the TAN can be given by the
  • his bank immediately seeks verification of the TAN from the house owner's bank, gets verification of receipt of payment and the house owner gets confirmation of the payment with a reference number.
  • Example 5 This example scenario is that of a Personnel Consultancy who invoices a client for 425 successful placement of a candidate.
  • the solution using a TAN is as follows:
  • the personnel consultancy emails the client with a copy of the invoice.
  • the client accesses his credit card account and authorises the transaction which procedure involves generation of a TAN.
  • the TAN is given to the personnel consultancy who emails this string of characters to his bank account.
  • the TAN included sufficient data to identify the customer down to branch 430 level, in case of multiple accounts the TANs would by prior agreement go to a specific account.
  • the payment is verified instantly as monies had already been set aside at the time of generation of the TAN, and clearing is not required.
  • the payment is deposited directly into the personnel consultancy account and confirmation is sent to both parties by the client's credit card company.
  • Example 6 This example scenario is that of a Car Sales Company dealing with an individual customer.
  • the solution using a TAN is as follows:
  • the customer selects a car of choice for purchase.
  • the customer uses the offices of the car sales company and accesses the Web using their PC to obtain a TAN.
  • the TAN is confirmed (if sufficient money exists) and money is 440 transferred immediately to the car sales company.
  • Example 7 This example scenario is when solicitors for a vendor and a purchaser settle the purchase of a residential dwelling.
  • the solution using a TAN is as follows:
  • a TAN is given by the purchaser to their solicitor to pay the vendor.
  • the solicitor passes this number to the vendor's solicitor via fax.
  • Authorisation is verified and monies are deposited 445 accordingly.
  • the vendor's soHcitor passes a separate TAN to the company holding their mortgage to discharge it in order to give clear title at settlement.
  • One of the issues in matching is that 450 although matching is anonymous the parties need to have authorised trading limits available for the transaction.
  • the matching system is obliged to store and maintain those limits on a real time basis. This adds complexity to the system, increases processing time, and raises security issues for both network provider and trading parties.
  • a party inserting a foreign exchange bid for a specific size and 455 price of a currency would have the option to insert a TAN that would indicate that funds were available within the relevant nostro/vostro account, and authorising funds to be transferred in accordance with market convention for the trade.
  • the TAN would include standard bank instructions plus potentially dealer information to improve trading limit management within the dealing room.
  • Example 9 Flow chart depiction of a foreign exchange TAN payment.
  • this block diagram shows how the payer (purchaser) 101 communicates securely (2) with his bank 103 to provide the payee 107 (vendor's) name and bank sort code and other details 465 together with the value of the purchase.
  • the payer bank 108 optionally communicates with the payee bank during establishment of a TAN and debiting of the payer's account, or his notes position, for better validation both at generation of the TAN and the transmission of the TAN from payee (or dealer) 107 to payee bank 108 for payment, as per the value date instruction at 9.
  • a foreign exchange transaction may generate two TANs, each representing an instruction by the party to its Nostro account holder, to facilitate the transaction.
  • the TANs should be constructed for facilitating automatic reconciliation.
  • the TANs can completely reconstitute the elements of the transaction, it is up to 480 the foreign exchange dealers to determine whether common values, currencies, dealer ID size, and time are recorded (given that clocks sometimes drift fast or slow. 6.
  • the respective banks 103, 108 could be the back offices of the respective banks or in fact the respective Nostro and Vostro account holders.
  • TANS need not be delivered to the bank by the payer bank. Further, they could be a special confirmation TAN that would validate against payee delivered TANs.
  • the dealer ID may be the name of the dealer or limited to a dealer call code.
  • TANs could be left at an untruncated length or tmncated into a short string of characters preferably retaining uniqueness for a limited period such as a month or thereabouts.
  • the invention can be used instead of cheques or credit cards and can be used for international monetary transactions, including stocks, bonds, and futures trading.
  • Transactions can be made in any variety of ways. For example, over the Wolrd Wide Web, by email, by mail, face to face, over the phone, or by fax.

Landscapes

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

Abstract

L'invention se rapporte à un système de sécurité utilisé dans les transactions financières et fonctionnant au moyen d'un seul jeton à utilisation unique et généré sur demande de la banque d'un débiteur par le logiciel sécurisé de la banque. Ce jeton ne représente aucune valeur pour un intercepteur. Ce jeton qui contient des informations abrégées sur les comptes est remis au bénéficiaire en tant que preuve que les fonds ont été mis de côté. Le bénéficiaire remet le jeton à sa banque et les fonds sont alors transférés. Ce système facilite les débits en banque, les transactions dans des environnements extérieurs non sécurisés, le commerce électronique et favorise une « société sans liquide ». Cette invention porte sur un système qui vient se rajouter aux autres systèmes de paiements bancaires existant.
PCT/NZ2002/000142 2001-07-31 2002-07-31 Systeme de securite pour transactions WO2003012714A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
NZ51328701 2001-07-31
NZ513287 2001-07-31
NZ51933502 2002-06-04
NZ519335 2002-06-04

Publications (1)

Publication Number Publication Date
WO2003012714A1 true WO2003012714A1 (fr) 2003-02-13

Family

ID=26652267

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/NZ2002/000142 WO2003012714A1 (fr) 2001-07-31 2002-07-31 Systeme de securite pour transactions

Country Status (1)

Country Link
WO (1) WO2003012714A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005031625A1 (fr) * 2003-09-29 2005-04-07 Tapsell, Yvonne, Erima Procede et systeme de cryptographie a clefs publiques
EP1650923A1 (fr) * 2004-10-22 2006-04-26 Software Ag Dispositifs et procédé d'authentification
US7689483B2 (en) 2003-05-20 2010-03-30 Amegy Bank of Texas System to facilitate payments for a customer through a foreign bank, software, business methods, and other related methods
WO2015126333A1 (fr) * 2014-02-21 2015-08-27 Global Exchange Payments, Se Procédé de paiement électronique sans espèces par l'intermédiaire d'un identifiant unique créé hors ligne
EP3017409A4 (fr) * 2013-07-02 2017-02-22 Accounts 4 Life Pty Ltd. Système de paiement
US11416933B2 (en) * 2020-01-07 2022-08-16 Bank Of America Corporation Event management and validation platform using a recursive hierarchic blockchain

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2317983A (en) * 1996-10-05 1998-04-08 Samsung Electronics Co Ltd Authenticating user
US6163771A (en) * 1997-08-28 2000-12-19 Walker Digital, Llc Method and device for generating a single-use financial account number
EP1077436A2 (fr) * 1999-08-19 2001-02-21 Citicorp Development Center, Inc. Système et méthode pour effectuer une transaction en-ligne utilisant un titre de paiement à usage unique
EP1150263A2 (fr) * 2000-02-28 2001-10-31 Castelberg Technologies S.r.l Système de télécommunication à sécurité totale pour transaction financière
WO2001092989A2 (fr) * 2000-05-26 2001-12-06 Interchecks, Llc Procedes et systemes pour systeme d'achat electronique via un reseau

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2317983A (en) * 1996-10-05 1998-04-08 Samsung Electronics Co Ltd Authenticating user
US6163771A (en) * 1997-08-28 2000-12-19 Walker Digital, Llc Method and device for generating a single-use financial account number
EP1077436A2 (fr) * 1999-08-19 2001-02-21 Citicorp Development Center, Inc. Système et méthode pour effectuer une transaction en-ligne utilisant un titre de paiement à usage unique
EP1150263A2 (fr) * 2000-02-28 2001-10-31 Castelberg Technologies S.r.l Système de télécommunication à sécurité totale pour transaction financière
WO2001092989A2 (fr) * 2000-05-26 2001-12-06 Interchecks, Llc Procedes et systemes pour systeme d'achat electronique via un reseau

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7689483B2 (en) 2003-05-20 2010-03-30 Amegy Bank of Texas System to facilitate payments for a customer through a foreign bank, software, business methods, and other related methods
WO2005031625A1 (fr) * 2003-09-29 2005-04-07 Tapsell, Yvonne, Erima Procede et systeme de cryptographie a clefs publiques
EP1650923A1 (fr) * 2004-10-22 2006-04-26 Software Ag Dispositifs et procédé d'authentification
US8028331B2 (en) 2004-10-22 2011-09-27 Software Ag Source access using request and one-way authentication tokens
US8312525B2 (en) 2004-10-22 2012-11-13 Software Ag Authentication over a network using one-way tokens
EP3017409A4 (fr) * 2013-07-02 2017-02-22 Accounts 4 Life Pty Ltd. Système de paiement
WO2015126333A1 (fr) * 2014-02-21 2015-08-27 Global Exchange Payments, Se Procédé de paiement électronique sans espèces par l'intermédiaire d'un identifiant unique créé hors ligne
US11416933B2 (en) * 2020-01-07 2022-08-16 Bank Of America Corporation Event management and validation platform using a recursive hierarchic blockchain
US11978118B2 (en) 2020-01-07 2024-05-07 Bank Of America Corporation Event management and validation platform using a recursive hierarchic blockchain

Similar Documents

Publication Publication Date Title
US20240020660A1 (en) Blockchain digital currency systems and methods for use in enterprise blockchain banking
KR102619524B1 (ko) 디지털 화폐를 사용하는 거래를 용이하게 하기 위한 시스템 및 방법
US7376628B2 (en) Methods and systems for carrying out contingency-dependent payments via secure electronic bank drafts supported by online letters of credit and/or online performance bonds
US8224753B2 (en) System and method for identity verification and management
US6529885B1 (en) Methods and systems for carrying out directory-authenticated electronic transactions including contingency-dependent payments via secure electronic bank drafts
US7483858B2 (en) Network-based system
US7143062B2 (en) Electronic cash eliminating payment risk
US8676707B2 (en) Credit cards system and method having additional features
KR100933387B1 (ko) 온라인 지불인 인증 서비스
JP3027128B2 (ja) 電子マネーシステム
JP6513254B2 (ja) 仲介業者によって媒介される支払いシステムおよび方法
US20150220892A1 (en) Platform for the purchase and sale of digital currency
US6941282B1 (en) Methods and systems for carrying out directory-authenticated electronic transactions including contingency-dependent payments via secure electronic bank drafts
CN108292398A (zh) 利用增强的持卡人认证令牌
AU2002250316A1 (en) Methods and systems for carrying out contingency-dependent payments via secure electronic bank drafts supported by online letters of credit and/or online performance bonds
MX2010010812A (es) Sistemas y metodos de transaccion usando telefonos celulares.
CN116472696A (zh) 数字资产兑换系统、数字钱包和数字资产兑换架构
WO2003012714A1 (fr) Systeme de securite pour transactions
TWM649100U (zh) 信託財產通報系統
WO2022087033A1 (fr) Système d'échange de paiement par devise fédéré
GB2434241A (en) Payment card system with main and temporary card accounts
Ezema et al. An Assessment of Computer Based Transactions in Nigeria

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE 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 NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG US UZ VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ 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 IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载