JP2006501584A - Electronic payment confirmation using transaction authorization token - Google Patents

Abstract

The account holder initiates the transaction by providing the vendor with both the account information previously stored in the token log and a specific transaction authorization token (TAT). The vendor passes the account information and TAT along with the transaction information to an organization that can respond to approve one or more transactions involving the financial account. The institution decides whether to approve the transaction by consulting token log entries against this given TAT.

Description

DETAILED DESCRIPTION OF THE INVENTION The present invention relates generally to payment systems, and more particularly to systems and methods for authorizing electronic transactions.

Industrial application fields

  The majority of financial transactions in the developed world are increasingly being conducted electronically. Electronic trading has many advantages such as greater efficiency than non-electronic trading. But electronic transactions will also introduce new opportunities for fraud.

  When a currency is stolen, it is physically stolen. However, in electronic transactions, the thief only needs to get the victim's account number to get close to this financial source. This stealing area corresponds to the field of so-called “personal information thieves” where a thief acts as if he is an account holder in accessing the financial resources of the account holder as electronically. .

Conventional technology

  One form of protection is written on the signature. This signature is not always required, especially for online transactions. Another form of protection is a personal identification number (PIN). This PIN can be stolen almost as easily as the account number.

  The present invention provides a system and method for preventing personal information thieves and other forms of fraud with respect to financial transactions. When a person initiates a financial transaction, the person initiates approval of the transaction by opening and / or accessing a transaction authorization token (TAT) at the same time. The TAT is a symbol stored in a token log (hereinafter also referred to as a token action log). This token log also contains the conditions for the transaction associated with a particular TAT entry. The token log can be accessed either directly by, for example, a financial institution that holds the account on which the financial transaction is based, or by polling the device or scheme that stores the token log.

  At the time of this transaction, the account holder provides this account number and the selected TAT to the vendor (usually a product seller or service provider). The vendor communicates that information to the financial institution to approve the transaction. The financial institution decides whether to approve the transaction by checking transaction information against the conditions recorded in the token log for a given TAT.

  In one example, the financial institution checks for a valid TAT by “polling” the account holder's communication device, eg, by sending a message query and expecting a response. In such an example, this TAT can be stored in the transaction log of the account holder's communication device. The polling inquiry message can include a display of transaction details such as transaction volume, vendor name, and the like.

  The communication device can then check those details against the parameters stored with the TAT of the token log. For example, TAT can only be effective for transactions that are less than a certain amount of money. The communication device can respond to the polling inquiry with an indication that the transaction is approved or not approved. The communication device may inform that a particular TAT has been accessed and, if specified as a single use, that the particular TAT can no longer be used to approve transactions. Other TATs can be specified to approve a specific number of transactions, or even countless transactions.

  In another example, the TAT can be transmitted to a financial institution before or immediately after the transaction is initiated. This TAT is accompanied by parameters that specify the terms of the transaction (eg, maximum dollar amount, pattern matching against vendor name, etc.). The financial institution then uses the TAT and accompanying parameters to verify the transaction. In this case, this TAT may be temporarily stored by the financial institution.

  In yet another example, by polling a third-party computer system similar to the polling method described above, this TAT can be placed away from either the account holder's communications device or the financial institution's effective TAT. Can be stored.

  When checking a token against the conditions recorded in the token log, the system will also initiate other actions configured for it. For example, a token log entry for a given token includes information about the nature of this transaction, ie it was operating expenses, and perhaps even a category of spending (lodging, meals, etc.). If the token indicates operating expenses, the system can be configured to automatically notify the company that a predetermined category of operating expenses has been incurred. The process of operating expenses can be simplified. The reason is that the employee indicates the type of spending when the predetermined token is stored in the token log.

  In general, the token log can include information in addition to the transaction terms associated with the token, and the additional information can be used for other trends related to the transaction other than simply approving the transaction.

  Another example is an account holder who wants to be notified when a given transaction is checked against a token log entry. The account holder can record information in a token log indicating that when a transaction is validated with a given token, an email message needs to be sent to a given address.

  This token log entry can include information that initiates an action after a given transaction is checked against the entry. For example, if the token log entry contains information about the category of transaction (e.g., business-related, tax deduction, food, etc.), the financial institution will later declaratively organize the account holder. This information can be used to provide a completed statement.

  The general concept is that in addition to being related to the terms of a given transaction, the token entry in the token log can contain information about other actions besides simply approving the transaction. This is because the token log includes a token and is also called a token action log related to action information.

  One aspect of the present invention is that this account holder can require, with possible exceptions, to approve transactions via a communication channel that is different from the transaction interaction with the vendor. Accordingly, a financial institution can require, with possible exceptions, that a valid TAT entry in the token log be negotiated before a given transaction is fully processed.

  This possible exception requiring a valid TAT to approve a transaction is, for example, if communication between the account holder's communication device and this financial institution is neither practical nor possible, and Consider the case where this financial institution or third party token log administrator does not already have a TAT for the transaction.

  As an example, the communication device can be implemented as a mobile phone and the account holder may want to conduct a financial transaction at a location outside the calling area of the mobile phone. In such cases, the exceptions required for TAT approval can be coordinated in advance between the account holder and the financial institution.

  As a further example, it can be specified that pre-adjusted exceptions can be handled up to a total of up to 3 transactions totaling less than $ 500 without confirmation from TAT. In one example, a financial institution's or third party token log may pre-store tokens and conditions that are specifically designated for transactions that would otherwise not involve a token.

  Alternatively, the account holder outside the communication can give the merchant the TAT previously stored in the token log at the financial institution or at a third party token log administrator. In this way, the account holder does not need to communicate with the token log administrator at the time of the transaction, but can simply call the previously stored TAT. An account holder holds one or more previously stored TATs on a person for such instances, such as a piece of paper, or the person's mind, in a portable electronic device Can do.

  Additional aspects of the invention will be apparent from the following detailed description of the preferred embodiments that follow this accompanying drawing.

  In the following description, well-known structures, materials, or acts are not shown or described in detail to avoid obscuring aspects of the invention. Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

The invention will be described with reference to the drawings.
FIG. 1 shows a block diagram of a system according to an example of the present invention. In one example, the account holder system 102 includes a token opening and editing module 104 that is controlled in turn by a user interface 106. Also, as used herein, the term “account holder” also means a user who is authorized by the account holder.

  When the user begins opening or editing a token or token setting, the token log access module 108 stores the token and token setting value in the token log 110. In FIG. 1, the token log 110 is shown separated from the account holder system 102, the vendor system 114, and the financial institution system 122. However, in other examples, the token log 110 may be part of the account holder system 102, part of the financial institution system 122, or part of a third party system. Throughout this description, the term “financial institution” may refer to an entity represented by a financial institution that authorizes for a transaction.

  If the user indicates that a token should be issued, the token issue module 112 retrieves that the token is appropriate via this token access module 108. In some cases, the user requests the issuance of a token that is not already in this token log, in which case the token is opened and issued.

  As shown, the token issuing module 112 issues tokens via the user interface 106 so that the user can pass the tokens through the vendor user interface 116. However, in other examples, the token issuing module 112 can interface directly to the vendor system 114, thereby allowing a particular TAT for a given transaction to pass without user interaction.

  If the vendor receives token and accompanying account number information, in one example, it is entered via the vendor's user interface 116. This information is then combined with other transaction information such as the transaction amount. The transaction authorization request module 118 communicates this information to the financial institution system 122.

  If the financial institution receives transaction information (and TAT) via the communication interface 120, it is processed by the transaction approval module 124 to determine whether the transaction should be approved. The transaction authorization module 124 accomplishes this by having a token log access module 126 that looks for conditions and actions associated with tokens in this token log 110. The transaction approval module 124 uses this information to determine whether the transaction should be approved. This determination communicates via the communication interface 120 to the original vendor transaction approval response module 130 that is responsible for informing the vendor 160 of the result.

  In some instances, the financial institution's transaction authorization module also initiates other actions associated with a given token through the use of action processing module 128. Examples of such actions are as described above and include notifying an account holder or other entity that a token has been used to approve or reject a given transaction.

  Figure 2 is a basic flowchart of how TATs can be used to approve financial transactions and prevent fraud. This diagram is broken down into three areas of action: account holder action 202, vendor action 204, and financial institution action 206. This actual token log 208 is shown in a separate state from these action areas. The reason is that in different examples, this token log exists with an account holder, financial institution, or third party.

The account holder initiates his action 202 by opening the token and associated financial transaction terms, and these terms are stored in the token log until they are used to approve the transaction. This token can be opened and stored days or months before the transaction, just before the transaction, or between transactions. This undefined time lag is represented by a dashed line for the step in which the account holder provides account information and tokens to the vendor.
In general, the account information includes the account type and account number. This account number is a credit card number, a debit card number, or the like.

  Vendor action 204 continues with the vendor receiving the account information and token from the account holder and sending it to the financial institution along with the transaction information. The transaction information can include the volume of the transaction and vendor confirmation. In one example, the financial institution is a credit card processor.

The first action of the financial institution 206 is to approve or not approve the transaction as appropriate. The financial institution determines whether the transaction is appropriate by examining this token log according to a predetermined token. For a given token, this token log indicates any conditions necessary for the transaction associated with that token. Exemplary conditions include the following:
• The amount of currency in a transaction cannot be greater than a specific amount.
• The date of the transaction must be before or after the prescribed date.
-Transactions must be at least a predetermined number of days after the previous transaction or event.
• Vendor names need to match specific patterns.
• Tokens could not be used to approve more than the specified number of previous transactions.

  The conditions recorded in the token log are usually determined by the account holder. However, in other examples, this condition is specified by the financial institution or specified as (discount) in the token log.

  The financial institution examines the token log by accessing the token log directly or polling a system that controls the token log. In any case, the objective is for the financial institution to decide whether the transaction is approved. Once the transaction is approved, the financial institution can notify the vendor and the vendor can continue the transaction. If the transaction is not approved, the financial institution can also notify the vendor and stop the transaction.

  FIG. 3 shows a block diagram of the token log structure. The token log 302 can be implemented as a data structure that associates tokens with related information. For example, the token log entry 304 is not limited by the present invention for the specific format of the token containing the token 306, which is the optional symbol “2945”, and can contain numbers, letters, or other symbols. Please pay attention. The advantage of using numbers is that many vendors can enter these numbers into this numeric keypad that they already use to authorize credit card transactions.

  The token entry 304 in this example also includes information regarding the conditions 308 that need to authorize the transaction. In this example, the transaction amount is limited to less than $ 50, the vendor's name must begin with the letter 'b', the token only approves transactions prior to October 15, 2003, which is at most It only approves one transaction.

  The token entry 304 in this example also includes information regarding other actions 310 to be performed when a given token is used for transaction authorization. Including other actions is why the token log is also referred to as the “token action log”. In addition, this entry can include metadata 312 that is other information related to the token, such as the number of transactions, which is used to authorize categories such as these transactions. Below the entry 304 in this example are three other entries indicating that multiple tokens and related information are recorded in the token log 302.

  FIG. 4 shows an example of a TAT system where the account is a credit card account and the account holder opens and stores a token using his mobile phone. Note that a token can be opened as easily as a computer or other device. For this example, the account holder opens a token at the time of the transaction. Alternatively, the account holder can use a token previously opened and stored in the token log.

The steps of the example of FIG. 4 are numbered in the diagram of each block and are described as follows:
Step 1: The account holder orders his meal.
Step 2: Restaurant employees show prices ($ 3.39).
Step 3: The account holder opens a TAT that uses his mobile phone by using the software function of the phone. Techniques for programming mobile phones are known in the art. Note that the account holder can use a previously opened token or open a new token for just this transaction. In this example, he specified that he would open a new token and use it on or before March 3, 2003 with a $ 5 limit from a vendor whose name begins with the letter "B." To do. In this example, the mobile phone software comes up with a token (eg, “1593”) as an arbitrary sequence of four numbers. Of course, any number of numbers or other types of codes may be used within the spirit of the invention.
Step 4: The mobile phone stores this TAT in this token log and can keep it on the mobile phone or it can be kept at a remote location (eg, a central server). There are various ways to send a token to a remote location, one of which is sent to the token log administrator (eg via SMS) as part of a specially formatted text message. The message can be formatted as XML or some other structure. In any case, this TAT is stored in a token log that is organized using any suitable data structure.
Step 5: Display TAT to account holder via mobile phone and hand it over to vendor.
Step 6: The account holder gives the credit card to the vendor along with the opened TAT.
Step 7: The restaurant employee executes the card through the merchant card reader and a predetermined TAT type (“pass machine”).
Step 8: This card reader forwards information to the credit card processing institution that is the “financial institution” for this scenario. The communicated information includes the vendor's name and / or identifier, credit card number, transaction volume, and a predetermined TAT. Although not shown as such in the figure, this information can be formatted in XML or other structured format.・
Step 9: This credit card processor checks the TAT against the token log information. If this token log is stored on the account holder's mobile phone, the card processor will send a short text message to the account holder's mobile phone that will trigger the mobile phone to automatically check the token log condition. Polling this mobile phone by sending. Alternatively, a message can be sent to a third party who can respond to keep this token log. If this token log is maintained by the card processor, the card processor's computer system can check this particular token condition directly in the token log.
Step 10: Since this example shows a legitimate transaction that satisfies this token condition, the card processor can report to the vendor (restaurant card device) that the transaction has been approved. Thus, restaurant employees can complete transactions and serve burgers and fries. When the system is functioning properly, the entire authentication process takes only a few seconds or less.

FIG. 5 is a continuation of the example of FIG. 4 in a situation where a restaurant employee attempts to fraudulently use an account holder's credit card to purchase a large screen television from an online vendor. The steps in this scenario are as follows:
Step 1: The employee gets an account holder credit card number from the account holder who used it at the restaurant. The employee understands that this card calls for TATs for approval, and at the same time immediately gets a TAT opened for restaurant transactions.
• Step 2: Employees find television vendors on the Internet.
Step 3: The employee selects the highest quality plasma television to purchase.
Step 4: The online television vendor's website reports a price of $ 9999.
Step 5: The employee navigates to the checkout part of the website and enters the stolen credit card number and TAT.
Step 6: The vendor's computer automatically transmits the appropriate transaction information to the credit card processor for approval.
In practical application, information can be formatted in XML or other structural format, but an example of that information is shown in step 7.
Step 8: The credit card processor checks the token and transaction information against the token log, for example by one of the methods described in the description of FIG. In this case, the transaction has already been used to approve one transaction, and it was previously set up only to approve one transaction. In addition, the amount is beyond the $ 5 limit, and the vendor's name does not begin with the letter `` B ''.
Step 9: Since this transaction condition is not met, the card processor notifies the television vendor that the transaction is not approved, so the television vendor cannot cancel the transaction and ship this television to the employee Can be.

  The examples described in FIGS. 4 and 5 are merely examples of the present invention. The present invention is not limited to the example of using a mobile phone or a computer as a device for establishing and / or transmitting a token. The present invention is not limited to the means or location where the token is stored in the token log, nor is it limited to the means by which the token log is checked against a given token associated with a given transaction. It will be apparent to those skilled in the art that there are many methods and data structures that can be used for these functions.

  Based on the foregoing, the present invention can provide a number of advantages not found in prior solutions. For example, according to the present invention, the account holder can be protected from personal information thieves and unauthorized unauthorized use of account resources. Even if an dishonest person steals an account holder's account number, it is useless unless it has the ability to reproduce valid tokens present in the token log. Even if the token is generated, for example, by an account holder's mobile phone, stealing the account number and mobile phone is a personal information thief and unauthorized unauthorized use of account resources. The solution in this case is to generate a token and ask the mobile phone user to enter a special code before accessing it. A person stealing a mobile phone does not have such a code and therefore cannot reproduce TATs.

  Also, the present invention typically protects financial institutions that are responsible for any transaction for transactions involving stolen account information. In addition, the present invention protects vendors who may be responsible for the failure of transactions involving fraud.

  An additional advantage over vendors can improve the opportunity to have non-repudiation of transactions. For example, if an online vendor ships a product to a customer who pays online with a credit card, the customer later ordered that product for credit card processor transactions, and someone You may argue that you must have stolen your credit card number. However, vendors can require that such transactions can only be paid online with a TAT that accepts non-repudiation conditions. Thus, checking the token log includes checking that the transaction cannot be reversed by the customer without vendor approval.

FIG. 1 is a block diagram of the components of a system according to an example of the present invention. FIG. 2 is a basic flow chart for the means by which transaction authorization tokens (TATs) are used to authorize a transaction. FIG. 3 is a block diagram of the token log structure. Figure 4 shows an application example of a TAT system that uses the account holder's mobile phone to open a token. FIG. 5 is a sequel to FIG. 4 illustrating the attempted fraud.

Claims (43)

Associate multiple tokens with a financial account by recording multiple tokens in the token log, making the token log accessible by an organization that can respond to approve one or more transactions involving the account; One of the accounts and the account disclosure to the vendor to initiate a transaction involving the financial account; the vendor provides information about the token, account disclosure, and transaction to the authorizing authority; A method of providing transaction approval to a vendor based on a token found to exist in Receive token, account disclosure, and transaction information from vendor; check whether token exists in token log; and inform vendor that transaction was approved based on token found to be present in token log The method according to claim 1, wherein notification is performed. Associate a token with one or more conditions in a token log accessible by an institution capable of approving one or more transactions involving a financial account; financial accounts by providing vendors with token and account disclosure The vendor provides tokens, account disclosures, and information about the transaction to an agency that can respond to the approval of the transaction, which is associated with the token in the satisfied token log. A method of providing transaction approval to a vendor based on one or more conditions. Receive token, account disclosure, and transaction information from vendor; check whether token exists in token log; and inform vendor that transaction was approved based on token found to be present in token log 4. The method according to claim 3, wherein notification is performed. Received disclosure of one or more terms from the account holder to complete one or more transactions; one in a token log accessible by an institution that can respond to approve one or more transactions involving a financial account Associate a token with one or more conditions; initiate a transaction involving a financial account by providing the vendor with token and account disclosure, and the vendor responds to the transaction's approval with information about the token, account disclosure, and transaction A method characterized in that it is provided to a potential authority and, by means of this approval authority, provides transaction approval to the vendor based on one or more conditions associated with tokens in a satisfied token log. Receiving token, account disclosure, and transaction information from the vendor; checking whether one or more conditions related to tokens in the token log are met; and that the one or more conditions are met In response, notify the vendor that the transaction has been approved. 6. The method according to claim 5, wherein: 6. The method of claim 5, wherein the account disclosure is one of a credit card number, a debit card number, an online payment transaction count, a merchant account number, and a bank account number. 6. The method of claim 5, wherein the token log comprises a data structure associated with a specific token in one or more specific transaction conditions. 6. The method of claim 5, wherein the trading conditions include a maximum monetary amount for one or more specific transactions. 6. The method of claim 5, wherein the transaction conditions include a pattern in which vendor names for one or more specific transactions match. 6. The method of claim 5, wherein the transaction conditions include a time frame in which one or more specific transactions are to be completed. 6. The method of claim 5, wherein the transaction terms include that a particular token can be used multiple times to authorize the transaction. 6. The method of claim 5, wherein the trading conditions have a minimum time interval between the exercise of a particular token to approve the transaction. 6. The method of claim 5, wherein the trading conditions include the presence of a particular token in the token log. 6. The method of claim 5, wherein the transaction conditions include a mechanism for preventing non-repudiation of financial transactions. 7. The method of claim 6, wherein the token log is stored in an account holder's communication device. The communication device is one of a telephone, a mobile phone, a desktop computer, and a portable computing device. The method of claim 16. The method of claim 16, wherein checking whether at least one condition associated with a token in the token log is satisfied is performed by polling an account holder's communication device. Polling the account holder's communication device sends a structured message containing transaction information and specific tokens to the account holder's communication device: and from the account holder's communication device one or more conditions for the transaction 19. The method of claim 18, comprising receiving a structured message indicating whether to be approved or denied based on the satisfaction of. Polling the account holder's communication device: Sends a structured message containing a specific token to the account holder's communication device; from the account holder's communication device, information from the token log associated with the given token 19. The method of claim 18, comprising using information to determine whether the transaction should be approved or denied. 7. The method of claim 6, wherein the token log is stored at a financial institution location that can respond to the approval of one or more transactions involving the financial account. The token log is stored in a third party location accessible to both the account holder and the institution that may be involved in the financial account and respond to the approval of one or more transactions of this establishment. The method according to claim 6. 7. The method of claim 6, wherein the vendor is one of a physical seller, a service seller, a public interest foundation, and an institution where the account holder borrows money. 6. The method of claim 5, wherein associating with one or more tokens includes receiving at least one condition for the one or more tokens from an external financial source. 6. The method of claim 5, wherein the entry in the token log includes disclosure of a transaction type associated with one or more specific tokens. 6. The method of claim 5, further comprising automatically opening one or more tokens in the account holder's communication device. 6. The method of claim 5, wherein providing a token to a vendor includes entering a passcode to access a desired token. 6. The method of claim 5, wherein providing a token to a vendor includes presenting a token that the account holder has known previously stored in the token log. Receive transaction information from a vendor whose transaction information does not accompany the token; otherwise associate the transaction with a special token indicated for transactions that do not accompany the token; and A method characterized by checking a special token within one or more conditions associated with a special token against information in the token log for verification. 30. The method of claim 29, wherein the account holder defines one or more conditions associated with special tokens that are indicated for transactions that do not otherwise accompany the token. A token opener that enters and stores one or more tokens; a token log that associates a specific token with a specific condition in which a specific financial transaction is valid; and a transaction related to an account holder's account A token access subsystem that makes one or more tokens available to account holders for distribution to one or more vendors involved; each vendor responds to the approval of one or more transactions involving the account Provide information about specific tokens, account disclosures, and transactions to the institution that obtains, in response to specific conditions associated with each specific token that is met in each vendor's token log A system characterized by authorizing each vendor to complete the transaction. 32. The system of claim 31, wherein the account disclosure is one of a credit card number, a debit card number, an online payment transaction count, a merchant account number, and a bank account number. 32. The system of claim 31, wherein the token log comprises a data structure associated with a particular token at one or more particular transaction conditions. 32. The system of claim 31, wherein the transaction terms include a maximum monetary amount for one or more specific transactions. 32. The system of claim 31, wherein the transaction terms include a pattern that matches vendor names for one or more specific transactions. 32. The system of claim 31, wherein the transaction terms include a time frame in which one or more specific transactions are to be completed. 32. The system of claim 31, wherein the transaction terms include that a particular token can be used multiple times to authorize a transaction. 32. The system of claim 31, wherein the transaction terms have a minimum time interval between the exercise of a particular token to approve a transaction. 32. The system of claim 31, wherein the transaction conditions include the presence of a particular token in a token log. A communication interface for receiving information about tokens, account disclosures and transactions from a vendor; a transaction approval module for checking whether at least one condition related to tokens in the token log is met; said communication A system characterized in that the interface informs the vendor that the transaction is approved in response to at least one satisfied condition. Means for storing one or more tokens in the token log; means for associating each token with the conditions under which a particular financial transaction is valid; allowing access to the tokens to associate these tokens with a particular financial transaction Means for authorizing a particular transaction by verifying that the conditions for the token associated with this particular transaction have been satisfied. A program code that receives disclosure of one or more terms from the account holder to complete one or more transactions; and a token accessible by an institution that can respond to approve one or more transactions involving a financial account Program code for associating a token with one or more conditions in the log; and program code for facilitating the initiation of transactions involving financial accounts by providing the vendor with disclosure of tokens and accounts; Provides information about tokens, account disclosures, transactions to institutions that can respond to approving the transaction, and based on one or more conditions associated with tokens in a satisfied token log A computer-readable medium characterized by providing transaction approval to a vendor. Program code for receiving tokens, account disclosure, and transaction information from vendors; program code for checking whether one or more conditions associated with token tokens are met; and 43. The computer readable medium of claim 42, further comprising: program code for notifying a vendor that a transaction is approved in response to a condition being met.

Images