US20080195497A1 - Unit-Based Prepaid Presentation Instrument Accounts And Methods - Google Patents

Unit-Based Prepaid Presentation Instrument Accounts And Methods Download PDF

Info

Publication number
US20080195497A1
US20080195497A1 US11/764,324 US76432407A US2008195497A1 US 20080195497 A1 US20080195497 A1 US 20080195497A1 US 76432407 A US76432407 A US 76432407A US 2008195497 A1 US2008195497 A1 US 2008195497A1
Authority
US
United States
Prior art keywords
transaction
unit
gas
balance
amount
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.)
Granted
Application number
US11/764,324
Other versions
US7813982B2 (en
Inventor
Gary Holme
Wayne Joseph Martin
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.)
First Data Corp
Original Assignee
First Data Corp
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
Priority claimed from US10/984,354 external-priority patent/US20060100959A1/en
Priority claimed from US11/283,532 external-priority patent/US7783539B2/en
Priority to US11/764,324 priority Critical patent/US7813982B2/en
Application filed by First Data Corp filed Critical First Data Corp
Assigned to FIRST DATA CORPORATION reassignment FIRST DATA CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MARTIN, WAYNE JOSEPH, HOLME, GARY
Assigned to CREDIT SUISSE, CAYMAN ISLANDS BRANCH, AS COLLATERAL AGENT reassignment CREDIT SUISSE, CAYMAN ISLANDS BRANCH, AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: CARDSERVICE INTERNATIONAL, INC., DW HOLDINGS, INC., FIRST DATA CORPORATION, FIRST DATA RESOURCES, INC., FUNDSXPRESS, INC., INTELLIGENT RESULTS, INC., LINKPOINT INTERNATIONAL, INC., SIZE TECHNOLOGIES, INC., TASQ TECHNOLOGY, INC., TELECHECK INTERNATIONAL, INC., TELECHECK SERVICES, INC.
Priority to PCT/US2008/067131 priority patent/WO2008157502A1/en
Priority to CA2691076A priority patent/CA2691076A1/en
Publication of US20080195497A1 publication Critical patent/US20080195497A1/en
Publication of US7813982B2 publication Critical patent/US7813982B2/en
Application granted granted Critical
Assigned to WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT reassignment WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: DW HOLDINGS, INC., FIRST DATA RESOURCES, INC. (K/N/A FIRST DATA RESOURCES, LLC), FUNDSXPRESS FINANCIAL NETWORKS, INC., INTELLIGENT RESULTS, INC. (K/N/A FIRST DATA SOLUTIONS, INC.), LINKPOINT INTERNATIONAL, INC., MONEY NETWORK FINANCIAL, LLC, SIZE TECHNOLOGIES, INC., TASQ TECHNOLOGY, INC., TELECHECK INTERNATIONAL, INC.
Assigned to WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT reassignment WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT SECURITY AGREEMENT Assignors: DW HOLDINGS, INC., FIRST DATA RESOURCES, LLC, FIRST DATA SOLUTIONS, INC., FUNDSXPRESS FINANCIAL NETWORKS, INC., LINKPOINT INTERNATIONAL, INC., MONEY NETWORK FINANCIAL, LLC, SIZE TECHNOLOGIES, INC., TASQ TECHNOLOGY, INC., TELECHECK INTERNATIONAL, INC
Assigned to CARDSERVICE INTERNATIONAL, INC., FIRST DATA CORPORATION, FUNDSXPRESS, INC., DW HOLDINGS INC., TELECHECK SERVICES, INC., TASQ TECHNOLOGY, INC., INTELLIGENT RESULTS, INC., SIZE TECHNOLOGIES, INC., FIRST DATA RESOURCES, LLC, LINKPOINT INTERNATIONAL, INC., TELECHECK INTERNATIONAL, INC. reassignment CARDSERVICE INTERNATIONAL, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH
Assigned to TELECHECK INTERNATIONAL, INC., TASQ TECHNOLOGY, INC., FIRST DATA RESOURCES, INC. (K/N/A FIRST DATA RESOURCES, LLC), MONEY NETWORK FINANCIAL, LLC, LINKPOINT INTERNATIONAL, INC., FUNDSXPRESS FINANCIAL NETWORKS, INC., DW HOLDINGS, INC., INTELLIGENT RESULTS, INC. (K/N/A FIRST DATA SOLUTIONS, INC.), FIRST DATA CORPORATION, SIZE TECHNOLOGIES, INC. reassignment TELECHECK INTERNATIONAL, INC. TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS Assignors: WELLS FARGO BANK, NATIONAL ASSOCIATION
Assigned to TASQ TECHNOLOGY, INC., MONEY NETWORK FINANCIAL, LLC, FIRST DATA CORPORATION, TELECHECK INTERNATIONAL, INC., FIRST DATA RESOURCES, LLC, LINKPOINT INTERNATIONAL, INC., FIRST DATA SOLUTIONS, INC., DW HOLDINGS, INC., FUNDSXPRESS FINANCIAL NETWORK, INC., SIZE TECHNOLOGIES, INC. reassignment TASQ TECHNOLOGY, INC. TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS Assignors: WELLS FARGO BANK, NATIONAL ASSOCIATION
Assigned to FIRST DATA CORPORATION reassignment FIRST DATA CORPORATION TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS Assignors: WELLS FARGO BANK, NATIONAL ASSOCIATION
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06Asset management; Financial planning or analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • G06Q20/202Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • G06Q20/204Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Definitions

  • This application relates generally to derivative transactions. More specifically, this application relates to methods and systems for implementing derivative transactions.
  • references to a “derivative transaction” are intended to refer to a transaction derived at least in part from another transaction that may be executed in the future. Execution of derivative transactions generally take the form of execution of an underlying contract between two parties.
  • a derivative transaction is a “futures transaction,” which is intended to refer herein to a transaction based on a futures contract between two parties specifying a date and certain terms for execution of the futures contract.
  • Another example of a derivative transaction is an “option transaction,” which is intended to refer herein to a transaction based on an option contract between two parties securing the right of at least one of the parties to execute a defined transaction.
  • the derivatives market has developed a great deal of complexity and is most often associated with relatively sophisticated investment strategies. Relatively few individual consumers and small business make practical use of the underlying derivatives as a mechanism for managing costs in a predictable way. Yet this ability is a primary benefit of the derivatives themselves.
  • the very complexity associated with managing derivatives has acted as a barrier to their practical use by individuals and small businesses. The result has been the development of system that is generally more concerned with the trade of derivatives and how profit may be generated by their purchase and sale, rather than their use as cost-management instruments.
  • Embodiments of the invention provide methods for executing a transaction between a first party and a second party. Instructions are received at a host system to stage the transaction. The instructions includes specification of terms of the transaction and specification of a trigger value of a fluctuating parameter. The terms of the transaction are dependent on a value of the fluctuating parameter. Confirmation is received that funds have been collected from the first party in support of the transaction. Thereafter, the value of the fluctuating parameter is monitored. It is determined whether the monitored value of the fluctuating parameter is at least as favorable to the first party as the trigger value.
  • the transaction is executed with terms in accordance with the monitored value of the fluctuating parameter.
  • it is determined that the monitored value of the fluctuating parameter is not as favorable to the first party as the trigger value. In such an embodiment, a refund of the funds to the first party is initiated.
  • the presentation instrument may includes a unit balance, for example, a balance of gallons of gas that have been pre-purchased by the user.
  • a financial processor, financial network computer and/or financial institution system may receive a preauthorization request from a point of sale device for a unit-based transaction using a presentation instrument.
  • the preauthorization request may include geographic location information (for example, a state and/or a zip code), a price-per-unit (for example, price per gallon of gas), product code (for example, fuel grade code), and/or a preauthorization amount.
  • the unit balance on the presentation instrument may then be converted into a currency amount and a determination is made whether this amount is sufficient to cover the preauthorization amount. This determination may be made by comparing the preauthorization amount with the currency amount.
  • the presentation instrument is authorized for the transaction and an indication that the preauthorization amount is authorized for the transaction is sent to the POS.
  • a currency balance is determined from the unit balance and possibly the price-per-unit. The presentation instrument may then be authorized based on the currency balance. An indication of this currency balance is then sent to the POS.
  • the method may further comprise determining whether the geographic location of the point of sale device is within a geographic area authorized by the presentation instrument limits. Moreover, the method may include determining whether the product code is a product code associated with the presentation instrument limits.
  • the method may be easily adapted for use in conjunction with a gas pump.
  • a POS device may be coupled with a gas pump and the presentation instrument may be a gas card.
  • a method for settling a transaction using a prepaid unit-based presentation instrument is disclosed according to one embodiment of the invention.
  • the method may include receiving a transaction amount and price-per-unit from a point of sale device.
  • the number of units corresponding to the transaction amount may be calculated using a price-per-unit and the balance on the presentation instrument may be decreased by the number of units corresponding to the transaction amount.
  • the presentation instrument is a preloaded gallon-based gas card and the price-per-unit is a price per gallon of gas.
  • the remaining unit balance on the transaction card may be calculated and sent to the POS.
  • a point of sale (POS) device coupled with a gas pump is also disclosed according to one embodiment of the invention.
  • the POS device may include a user interface, a network interface and computational logic.
  • the user interface for example, may include a card reader, a screen and input buttons.
  • the network interface may be coupled to a financial network and may be in communication with a financial processor.
  • An account number associated with a presentation instrument may be received through the card reader.
  • An indication of a gas type may be received from a user through the user interface.
  • the account number, gas type and the price-per-gallon for the selected gas type may be transmitted to a financial processor through the network interface.
  • An indication whether the presentation instrument is approved to purchase gas may be received from the financial processor through the network interface.
  • the POS may determine whether the account number is associated with a unit-based prepaid gas card and/or receive an indication of the amount of gas approved for a transaction.
  • the POS may include a gas pump interface that communicates information to the POS such as the price-per-gallon, the number of gallons, and/or transaction amount.
  • the POS may also send an authorization amount to the gas pump through the gas pump interface.
  • Embodiments of the invention provide methods for executing a money transfer from a first party to a second party.
  • Customer instructions are received at a host system to stage the money transfer.
  • the instructions include specification of an amount of money to be transferred, specification of a first currency in which the funds are to be provided by the first party, specification of a second currency different from the first currency in which the funds are to be received by the second party, and specification of a trigger currency exchange rate.
  • Confirmation is received that the funds have been collected from the first party.
  • a currency exchange rate between the first currency and the second currency is monitored. It is determined whether the monitored currency exchange rate is at least as favorable for the first party as the trigger currency exchange rate.
  • the amount of money to be transferred may be specified in the first currency or may be specified in the second currency.
  • the customer instructions may be received at the host system over the Internet or from an in-person money-transfer location.
  • the funds are converted from the first currency to the second currency at the monitored currency exchange race and the converted funds are transferred to the control of the second party.
  • the monitored currency exchange rate may sometimes be more favorable than the trigger currency exchange rate.
  • the amount of money to be transferred may be increased by an excess corresponding to a difference between the monitored currency exchange rate and the trigger currency exchange rate. Alternatively, a refund of the excess may be initiated.
  • the funds may be refunded to the customer.
  • the currency exchange rate between the first currency and the second currency may be monitored for a second defined time.
  • the funds may nonetheless be converted from the first currency to the second currency at the monitored currency exchange rate, with the converted funds being transferred to the control of the second party.
  • FIG. 1 is a block-diagram representation of an exemplary architecture for implementing methods of the invention in an embodiment.
  • FIG. 2 is a flow diagram that summarizes various methods for using stored-value tokens as part of the methods of the invention.
  • FIG. 3 is a schematic illustration of a physical structure of a host system on which methods of the invention may be embodied.
  • FIGS. 4A-4C illustrate the status of certain information that may be maintained in implementing methods of the invention in an exemplary embodiment.
  • FIG. 5 is a block-diagram representation of an exemplary architecture that may be used for effecting money transfers in accordance with certain embodiments.
  • FIG. 6 is a flow diagram summarizing certain methods of the invention.
  • FIG. 7 is a flow diagram summarizing a method of preauthorizing a gas purchase using a pre-purchased unit-based gas card.
  • FIG. 8 is a flow diagram summarizing a method of settling a gas purchase using a pre-purchased unit-based gas card.
  • Embodiments of the invention provide methods and systems for handling derivative transactions by using techniques developed for implementing stored-value accounts.
  • a typical stored value account operates by providing a host system that manages the stored-value account, maintaining records of such information as how much value exists in the account, where the value may be used, etc.
  • a token is provided to an owner of the stored-value account, such as in the form of a magnetic-stripe card, although other tokens may be used, such as in the form of a chip card, rf device, and the like.
  • the customer provides the token at the time of the transaction, and information is read from the token to identify the account.
  • This identifier is transmitted to the host system, which retrieves records of the amount of value available for use and confirms that the transaction may proceed.
  • the host system debits the value applied during the transaction from the account and performs settlement functions to ensure that the other party to the transaction is credited with that value.
  • Embodiments of the invention use such an arrangement for the implementation of derivative transactions.
  • a small business owner who has a generally predictable need for a commodity, such as gasoline.
  • the business owner would like to take advantage of the periodically lower costs for the gasoline by buying greater volumes of it, but lacks storage capacity to hold significant volumes.
  • a derivative would provide a convenient mechanism for the business owner to manage costs, such as by purchasing futures of gasoline at lower costs in accordance with the predicted needs.
  • the business owner might sometimes recognize the possibility of a higher-than-average short-term need for gasoline, in which case costs may be effectively managed through purchase of an option.
  • Use of a stored-value arrangement significantly increases the ease of entering and managing such derivative-transaction arrangements.
  • FIG. 1 provides a general overview of an architecture 100 that may be used in implementing embodiments of the invention.
  • the host system 138 that coordinates the transfer of information and that maintains account records comprises a host processor 136 and a data store 140 .
  • the host system 138 is provided in communication with a number of other elements of the architecture through communications links with the host processor 136 .
  • the communications links may be electrical, optical, wireless, or any other type of communications link known to those of skill in the art.
  • Point-of-sale devices which may be used when a stored-value token is initially acquired or when a transaction involving the stored-value token is executed, may be routed through a network 144 .
  • the network 144 usually comprises a secure network.
  • the drawing distinguishes between merchant processors 104 , which refer herein to parts of point-of-sale devices that are used in communicating information as part of executing a transaction, and sales terminals 112 , which refer herein to parts of point-of-sale devices used when a stored-value token is initially provided to a customer. This distinction is largely conceptual since the same physical devices may usually be used for either or both functions.
  • the point-sale-devices are shown as including a card reader 108 or 116 in communication with the merchant processor 104 or sales terminal 112 for reading magnetic-stripe information in those embodiments where the stored-value token comprises a magnetic-stripe card.
  • the point-of-sale devices may generally take a variety of different forms, including devices that may be operated by merchant clerks or may be self-operated by customers.
  • the card reader may also include an RFID reader.
  • the host processor 136 may also be provided in communication with one or more financial-institution processors 152 , each of which functions as part of a system that maintains accounts on behalf of account holders on associated data stores 156 .
  • the financial institutions are identified as banks in the drawing, but may more generally be any type of financial institution, such as a trust company, and credit union, and the like. Communications between the host processor 136 and the financial-institution processors 152 take place over a financial network 148 , which is generally provided as a secure network to protect the confidential and sensitive nature of the financial information that is routed.
  • the host system 138 may additionally be provided in communication with other networks that permit customers to access information regarding the stored-value accounts that are maintained on the data store 140 .
  • This additional capability is generally of an administrative nature to provide functionality that permits customers to be active in the administration of these accounts.
  • more substantive capabilities may also be provided, enabling the customer to transfer funds between a stored-value account maintained by the host system 138 with an account maintained by one of the financial institutions.
  • Other capabilities that might be provided include the ability to make bill payments with stored-value accounts through a network connection with the host system 138 , and the like.
  • Such additional networks may be provided in a number of different ways, such as through the use of a public network like the internet 120 that provides communications between the host processor 136 and a customer computers 124 .
  • the architecture 100 may support an interface to process touch-tone commands from customer telephones 132 through a dual-tone multiple-frequency (“DTMF”) processor 128 .
  • the DTMF processor 128 translates telephone touch tones to enable a customer to provide instructions through a telephone 132 and transmits audible responses to the customer.
  • Still other mechanisms that may be used in different embodiments include voice-recognition processors, cable processors, and the like.
  • the information-security issues related to the use of public networks like the internet may be different because of the greater risk of interception than over the private networks 144 and 148 .
  • a variety of techniques known to those of skill in the art may be used to provide enhanced security, including encryption of data transmitted over such public networks. Such techniques may be used with the transmission of information also over the private networks 144 and 148 to further provide strengthened security of the information.
  • FIG. 2 An overview of methods of the invention that may be implemented with an architecture like the one shown in FIG. 1 are summarized with the flow diagram of FIG. 2 .
  • the flow diagram shows three different types of transactions that may be executed using the stored-value token, including derivative transactions that are illustrated for a futures transaction and for an option transaction, and also including a purchase transaction using stored value.
  • the execution of a purchase transaction is illustrated explicitly since some embodiments may provide limitations on such a transaction as part of implementing certain types of derivative transactions. For instance, a portion of the stored value for an account may be frozen when the derivative includes a future contractual obligation to ensure that there is sufficient funds support for the contractual obligation.
  • the derivative transaction is a futures transaction obligating the customer to make a future purchase
  • the value needed for that purchase may be earmarked as inaccessible for use in purchase transactions.
  • the derivative transaction is an option transaction
  • there is no future obligation on the part of the customer to make a purchase so no value is specifically earmarked.
  • the flow diagram begins with the initial establishment of a customer's stored-value account, as indicated at block 202 with the purchase of a stored-value token equipped for use with derivative transactions.
  • a purchased token may have value that has been preloaded in the account, usually an amount that is equal to the purchase price of the token.
  • the customer may be provided with the capability of adding value to the account, as indicated at block 204 , to set a particular value for the account. Adding value may be performed in any of several different ways. For instance, the customer may use the administrative connections described in connection with FIG. 1 to supply a financial account from which value may be transferred to the stored-value account identified by the token.
  • the host processor 136 coordinates the value transfer in accordance with instructions from the customer and by using known techniques to identify the customer's authority to initiate debit instructions to a financial account held at a financial institution. Such techniques may include verification of a customer's personal identification number (“PIN”) associated with the account, and the like.
  • PIN personal identification number
  • the customer may present the token with a tendered value amount at a point-of-sale location, such as at one of the sales terminals 112 identified in FIG. 1 .
  • a clerk may swipe the card through the card reader 116 to extract the account identifier, which is transmitted to the host processor 136 to identify the account. The clerk may then accept tendered value from the customer, such as in the form of cash, a check, a credit card, etc.
  • Further ways of adding value may include similar processes that omit the involvement of the clerk by having the customer interact with a self-service device equipped with such devices as a cash collector, check reader, and the like to accept the tendered value.
  • the token may be used in the execution of derivative transactions and purchase transactions.
  • the left column of FIG. 2 illustrates the use of the token as part of a futures transaction, such as where the customer is tendered a futures contract at block 206 .
  • a futures transaction typically includes terms specifying a date or date range when the contract is to be executed, the goods to be provided to the customer from a seller at the time of execution, and the amount of value to be provided by the customer to the seller at the time of execution. Because a specific amount of value will be needed to support the contract, a check is made at block 208 whether the stored-value account identified by the token has sufficient value.
  • This may be done at any of the point-of-sale devices described in connection with FIG. 1 by extracting an identifier from the token and transmitting it to the host system 138 for retrieval of account information. If the account lacks sufficient value, the contract may be refused by the system at block 210 .
  • the terms of the contract are stored at the host system 138 at block 212 .
  • the storage of such terms may comprise freezing the amount of value required to support the contract so that they cannot be used as part of a purchase transaction or allocated to another futures transaction.
  • the customer may visit the merchant, as noted at block 214 , and present the stored-value token.
  • the location for execution of the contract may be different from the location where the terms were initially established, reflecting the fact that execution of the contract generally involves the delivery of a commodity or other goods to the customer.
  • the terms of the contract established as part of executing the futures transaction may have taken place a sales terminal 112 located at a sales office while execution of the contract is performed with a merchant processor 104 located at a distribution center.
  • the customer presents the stored-value token at block 216 .
  • the account identifier provided by the stored-value token is used to retrieve contract terms from the stored-value account at the host system 138 at block 218 , which may be displayed to the parties on a monitor or other output device to confirm the contract terms.
  • the merchant supplies the commodity or other goods in accordance with the contract terms and at block 222 the host processor 136 deducts the contract amount from the stored-value account.
  • the frozen-value amount is also reduced by the contract amount, but may not be reduced to zero if there were multiple derivative transactions executed that resulted in freezing of multiple amounts.
  • the amount owed to the merchant as a result of executing the contract is transmitted to an account of the merchant, usually at a financial institution, at block 224 . While in some instances, this may be done substantially immediately after execution of the contract, more usually it is performed as part of a settlement process that determines how changes in value handled by the host system 138 over some time period, such as a day, should be allocated among multiple merchants and financial institutions. Performing the settlement periodically in this fashion improves efficiency since the allocation of value amounts may be performed with a minimal set of transfers that defines the result of multiple transactions, rather than requiring a separate transfer for each of those transactions.
  • the middle column of FIG. 2 illustrates the use of the token as part of an option transaction, in which the customer purchases the right to execute a transaction without becoming obligated to do so.
  • an option transaction may be executed by a customer making payment of a certain amount in exchange for the right, which is then recorded by the system.
  • the customer purchases the option and the terms of the option are stored at the host system 138 at block 228 .
  • the terms of the option generally specify a date or range of dates when the option must be exercised, if at all, and specify the cost of a commodity or other goods to be supplied upon execution. If the customer fails to exercise the option before the end of the time period where he may, the recorded terms may simply be removed by the host system 138 , at least from records of currently exercisable options.
  • the customer may visit the merchant at block 230 during the valid time period.
  • the execution of the option transaction may take place at a different physical location than where it is exercised, such as where the option transaction is executed with a sales terminal at a sales office and the option itself is executed with a merchant processor 104 located at a distribution center.
  • the customer presents the stored-value token at block 232 so that the local processor may retrieve the relevant option information from the stored-value account maintained by the host system 138 at block 234 .
  • the merchant supplies the commodity or other goods at block 238 in accordance with the option terms.
  • the host processor deducts the amount to be charged from the stored-value account at block 240 and transmits that amount to the merchant account at block 242 , usually as part of a periodic settlement process as described above.
  • the right column of FIG. 2 illustrates the use of the token as part of a purchase transaction, highlighting the effect on the availability of stored value that may be manifested as a result of enabling futures transactions to be executed.
  • the customer visits and merchant and selects goods for purchase.
  • the local processor reads the account identifier from the token and uses it to retrieve the stored-value account information at block 250 . If there is not sufficient free value in the account, as checked at block 252 , then the purchase transaction is refused at block 254 .
  • the host processor deducts the transaction amount from the stored-value account at block 256 and transmits the transaction amount to a merchant account at block 258 , usually as part of a periodic settlement process.
  • the future transaction may more generally comprise execution of any contract that requires payment by the customer.
  • the future transaction comprises the purchase of a different currency by the customer, such as illustrated by an arrangement in which a customer arranges for the future purchase of 1000 euro for a cost of 1250 US dollars.
  • Such an arrangement has the same advantages as other futures arrangements, permitting the customer to avoid future cost fluctuations, in this instance of the purchase of currency.
  • the transaction may be structured as a futures transaction in which the customer obligates himself to purchase the currency, or may be structured as an options transaction in which the customer secures the right to purchase a specified amount or range of currency at a specified rate.
  • FIG. 3 provides a schematic illustration of a physical structure that may be used to implement the host system 138 in one embodiment.
  • FIG. 3 broadly illustrates how individual system elements may be implemented in a separated or more integrated manner.
  • the host system 138 is shown comprised of hardware elements that are electrically coupled via bus 326 , including the host processor 136 , an input device 304 , an output device 306 , the storage device 140 , a computer-readable storage media reader 310 a , a communications system 314 , a processing acceleration unit 316 such as a DSP or special-purpose processor, and a memory 318 .
  • the computer-readable storage media reader 310 a is further connected to a computer-readable storage medium 310 b , the combination comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information.
  • the communications system 314 may comprise a wired, wireless, modem, and/or other type of interfacing connection and permits data to be exchanged with the networks 144 , 148 , 120 , and 128 illustrated in FIG. 1 to implement embodiments as described.
  • the host system 138 also comprises software elements, shown as being currently located within working memory 320 , including an operating system 324 and other code 322 , such as a program designed to implement methods of the invention. It will be apparent to those skilled in the art that substantial variations may be made in accordance with specific requirements. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed.
  • FIGS. 4A-4C show an example of the type of information that may be maintained by the host system 138 for a particular account as the stored-value token is used by the customer to execute various derivative transactions and/or purchase transactions.
  • Part (a) of FIG. 4A shows an example of a record that may result when the customer initially purchases a stored-value token having a $100 value on February 1.
  • the cost of the token to the customer is equal to its cash value, although in some instances the cost may be different. For instance, if tokens are provided as part of promotional programs, the initial cost to the customer may be less than the cash value; conversely, if tokens are sold as part of a fund-raising campaign, the initial cost to the customer may be greater than the cash value, with the excess value being donated to the fundraisers.
  • the record for the account maintained on the data store 140 is shown to include a cash value of $100 and no other entries, meaning that the value within the account may be used to support any transaction available with the stored-value token.
  • Part (b) of FIG. 4A shows the result of the customer using the stored-value card on February 15 to execute a purchase transaction for the purchase of goods for $50.
  • the cash value in the account is thus reduced by that amount to $50.
  • a subsequent addition of $200 of value by the customer on March 1 results in the record shown in part (c) of FIG. 4A , reflecting a cash value of $250.
  • the operations shown in parts (a)-(c) of FIG. 4A thus illustrate traditional functionality of a reloadable stored-value account.
  • Part (d) of FIG. 4A shows the type of information that may be maintained when the card is used for execution of a derivative transaction, in this instance a futures transaction.
  • the futures contract that underlies the executed futures transaction is a contract between the customer and ABC Company for the purchase of 100 gallons of gasoline at a cost of $160, the purchase to take place between March 26 and April 2.
  • the futures transaction was approved because the available value in the account of $250 was greater than the contract amount of $160. Accordingly, the total cash value in the account is unchanged at $250, but the contract amount is frozen, leaving $90 of free value.
  • the terms of the underlying contract are also recorded.
  • the record is updated to reflect the new balance as shown in part (h) of FIG. 4B .
  • the customer subsequently purchases an option from the ABC company on April 8 for the purchase of gasoline.
  • the terms of the option are for an amount of gasoline less than 100 gallons at a rate of $1.65 per gallon, to be purchased between May 1 and May 6.
  • the option transaction costs the customer $20 and ensures the availability of the terms as specified, but does not bind the customer to execute the option; if circumstances are such that the gasoline is not needed, or if the price drops in the interim, the customer may simply allow the option to expire.
  • the updated record shown in part (i) of FIG. 4B shows that the terms of the option have been recorded and that the cash value has been decreased by the $20 payment made as part of executing the option transaction.
  • the value associated with the cost of executing the option which may be up to $165, is not frozen and the entire $220 of value remains free.
  • the transaction is approved even though the remaining value of $70 shown in part (j) of FIG. 4B is insufficient to cover the maximum potential option cost.
  • the system may record information regarding multiple derivatives. While generally there is no limit on the number of derivatives that may be accommodated at any time, the execution of derivative transactions being limited only by the need to have sufficient value to support binding derivatives like futures, it is possible in some embodiments for the system to limit the number of derivatives to some predetermined number or to some predetermined maximum value.
  • An illustration of recording information regarding multiple derivatives is provided with part (k) of FIG. 4C , which shows how the record is updated when the customer executes a second option transaction to purchase a further option from ABC Company.
  • the option again costs $20, which is reflected be the reduction in cash-value balance for the stored-value account, and provides for the purchase of up to 250 gallons of gasoline at $1.50 per gallon between May 3 and May 9.
  • the availability of such a second option with a lower price per gallon and a higher potential volume may reflect external changes in market conditions so that the expenditure of $20 by the customer to secure the second option may well result in a substantial savings overall.
  • the system may permit derivative transactions to be executed with multiple different entities.
  • the customer may wish to execute a futures transaction with XYZ Inc. and therefore adds $400 of value to the stored value account on April 26. This increase is reflected with the updated record shown in part (l) of FIG. 4C .
  • execution of the futures transaction to establish a futures contract for the purchase of 22 units at a cost of $125 between June 3 and June 25 is reflected in the updated record shown in part (m) of FIG. 4C . Because the futures contract binds the customer, the $125 of value is frozen so that the free value is identified in the figure as being $325.
  • the stored-value token may proceed in this way indefinitely, with the customer adding value as desired and using the stored value to support purchase transactions and derivative transactions that the customer wishes to execute.
  • the system may conveniently record historical track records of costs for the various commodities and other goods that are the subject of the derivative transactions. Such records may be valuable both to the customer and to the merchants who sell such goods.
  • Derivative transactions may also be implemented in some embodiments by using currency-exchange mechanisms.
  • currency-exchange mechanisms are implemented in several embodiments as an adjunct to a money-transfer mechanism, with the specific examples discussed herein being illustrative of certain more general derivative mechanisms that are within the intended scope of the invention.
  • a structure that may be used to effect money transfers is illustrated with the block diagram of FIG. 5 .
  • the money transfers are effected through a money-transfer network 504 that provides a communications interface between various devices that may be used to initiate money transfers and to receive funds transferred in this manner.
  • a money-transfer network 504 that provides a communications interface between various devices that may be used to initiate money transfers and to receive funds transferred in this manner.
  • local money-transfer processors 508 may be provided at various geographical locations and used to operate money-transfer terminals 512 , with each of the money-transfer processors 508 being interfaced with the money-transfer network 504 .
  • the processor 508 and terminals 512 are generally disposed at a physical location that operates as a money-transfer office.
  • a customer may visit the office physically to arrange for funds to be transferred, providing the funds in cash or through some other mechanism, such as with a credit card or debit card.
  • a clerk may operate one of the terminals 512 to provide information used in effecting the money transfer.
  • the terminals 512 may comprise a self-service terminal operated by the customer herself in staging the money transfer.
  • such a physical location may be used by the recipient to receive the transferred funds with clerk-operated or with self-operated terminals to receive the funds.
  • the physical locations of the initiating and receiving processor 508 /terminal 512 are typically in different countries.
  • Money transfers may alternatively be staged using other types of interfaces with the money-transfer network 504 .
  • the drawing shows explicitly that the money-transfer network 504 may be interfaced with the Internet 516 , which is in turn interfaced with various computational devices 520 .
  • This permits a customer to access money-transfer functionality by connecting his computational device 520 to the Internet 516 to access a web page where such functionality is implemented.
  • the customer With such an interface, the customer will usually provide funds for transfer by using a credit card, debit card, or similar mechanism that may be implemented electronically, instead of by providing cash.
  • Other types of interfaces may be provided with the money-transfer network 504 in various alternative embodiments, including telephone interfaces that respond to DTMF tones, cable interfaces, wireless interfaces, and the like.
  • the flow diagram of FIG. 6 summarizes a number of different embodiments in which a money transfer is implemented with a derivative transaction.
  • the derivative transaction comprises a futures transaction linked to a currency exchange rate to be implemented with the money transfer.
  • the money transfer is initiated with the customer visiting a money-transfer site at block 604 , either by visiting a physical site where to access a money-transfer terminal 512 or by visiting a virtual site such as where the money transfer is initiated from a web site over the Internet 516 .
  • the money transfer is then staged by the customer at block 608 .
  • the customer may provide a number of specifications, including the identity of the recipient of the money transfer, the amount of money to be transferred, the location to which the money is to be transferred, the currency in which the money to be transferred is supplied and the currency in which the money transferred is to be received, and the like.
  • embodiments of the invention permit the customer to impose a limit on the exchange rate to be applied. For example, if the customer wishes to transfer US$100 to a recipient in Mexico and to have the Mexican recipient receive the transferred money in Mexican pesos, the customer could require that the exchange rate be at least 10 pesos/US$ before the transfer is executed.
  • the size of the money transfer may be specified in terms of the amount to be received by the recipient, such as by specifying that M$1000 are to be transferred.
  • the applicable exchange rate is accordingly monitored at block 616 . Such monitoring may be substantially continuous, permitting the money transfer to be executed essentially as soon as the exchange rate becomes acceptable. Alternatively, the monitoring may be periodic so that the exchange rate is checked at different times. Such periodic monitoring, because it effectively samples the rates, may result in overlooking certain windows in which an acceptable exchange rate might have been used. At the same time, such periodic monitoring may also cause the system to respond when an even more favorable rate than the trigger value is available, while continuous monitoring would effectively always respond when the exchange rate is at the trigger value.
  • the customer may be notified of that determination at block 628 . Subsequent action may then proceed either on the basis of further instructions provided by the customer, on the basis of prior instructions provided by the customer at the time of staging, or in accordance with default procedures in different embodiments. For instance, the customer may indicate that the time limit is to be reset, a check for which is indicated at block 632 . Such an indication may be given explicitly by the customer after notification of the failure to meet the staging conditions, or could be a way of implementing a protocol where specified time limits are restricted to integral multiples of a base time limit.
  • Another option that may be provided is the option to execute the money transfer at the higher exchange rate, as checked at block 636 . If the customer declines to do so, either in accordance with standing or new instructions, the money transfer may be canceled at block 640 and a refund of amounts paid, perhaps less a service charge, refunded to the customer at block 644 .
  • execution of the staged money transfer may occur when the exchange rate is identified as being within an acceptable range or when a decision has been made to execute the transfer notwithstanding the failure of the exchange rate to fall within the acceptable range.
  • the funds are transferred to the recipient over the money-transfer network 504 at block 648 using methods known to those of skill in the art.
  • Such a funds transfer applies the current currency exchange rate and may sometimes result in there being an excess of funds as a result of the fluctuation of the exchange rate. This is especially possible in embodiments where the transfer amount is specified in terms of the amount to be provided to the recipient and where the exchange rate is monitored only periodically.
  • a check may thus be made at block 652 whether there are excess funds, with different options being available for handling the excess funds.
  • options may be selected by the customer upon notification of the existence of the excess funds, could have been identified by the customer at the time of staging the money transfer at block 608 , or could be performed in accordance with a default protocol.
  • the size of the money transfer may be increased in accordance with the excess funds made available by the favorable exchange rate.
  • the excess funds may be refunded to the customer.
  • FIG. 7 shows a flow diagram 700 summarizing a method of preauthorizing a gas purchase using a pre-purchased unit-based gas card according to one embodiment of the invention.
  • the method may be used in conjunction with a preloaded presentation instrument for purchasing gasoline from gas stations, for example, a preloaded gas card.
  • the presentation instrument may be purchased and preloaded with a number of gallons. For instance, a user may purchase a preloaded gas card with a set number of gallons. For example, the consumer may buy a gas card with 25 gallons or 50 gallons. If the price-per-gallon is set at the time of the purchase at $2.00 per gallon, the consumer would purchase the preloaded gas card for $50 and $100 respectfully.
  • the preloaded gas card may then be used to purchase gallons of gasoline from participating gas stations.
  • the number of gallons preloaded on the gas card may be decreased according to the number of gallons purchased. If the consumer wishes to purchase more than the number of gallons left on the gas card, they may present a second form of payment to pay for the surplus gas.
  • card info is received from a user 706 at a point of sale device 702 .
  • the card info may be received from a card reader and/or a RFID reader.
  • the consumer may be asked to enter a PIN, password and/or biometric sample to confirm ownership of the gas card.
  • the card information may include account number, name, etc.
  • the POS device 702 may then determine whether the card is, indeed, a unit-based gas card at block 708 .
  • a gift card or other card may also be used at the card reader. Accordingly, a determination regarding the type of card entered into the card reader must occur.
  • a gas card for example, may include a numeric code that differs from a gift card and which may be used to distinguish gas cards (or unit-based cards) from gift cards.
  • the method receives the fuel grade, gas price, geographic location, and preauthorization amount at block 710 .
  • This information, the fuel grade, gas price, geographic location, and preauthorization amount may then be packaged as part of a preauthorization request.
  • the fuel grade selection may be received from the user through the user interface. For example, once the unit-based card has been recognized, the user may be prompted for a fuel grade selection.
  • the gas price may be received from physical memory and associated with the fuel grade selection.
  • the geographic information may include a zip code and or state code. Gas prices vary from state to state, location to location and across zip codes. Accordingly, some preloaded gas cards may be geographically limited. For example, the gas cards may only be used in specific locations, such as states and/or zip codes.
  • the POS device 702 may also receive a preauthorization amount from memory. The preauthorization request may then be sent to a financial processor at block 712 .
  • the preauthorization request is received at block 714 .
  • the financial processor may then determine whether any limits are associated with the account and if the preauthorization request satisfies those limits. For example, the financial processor may compare the geographic location information received from the POS and determine whether the geographic location is within the limits set by the account.
  • the gas card may be limited to certain fuel grade, such as, premium or high octane. If the grade selection does not match the grade type associated with the gas card, then the transaction will terminate. Other limitations may also be applied to the account. If the limits are not met, the transaction ends at block 717 . If the limits are met, then the financial processor calculates the current currency amount of the balance of the card at block 718 .
  • the current currency balance (Bal $$ ) is determined by multiplying the unit balance (Bal unit ) on the card by the price-per-gallon (price) received in the preauthorization request. If the current currency amount is greater than or equal to the preauthorization amount, as determined at block 720 , then the authentication amount is set equal to the preauthorization amount at block 724 , otherwise the authorization amount is set to the current currency balance at block 722 .
  • the financial processor then locks an amount equal to the authorization amount on the card at block 726 .
  • the financial processor then sends the authorization amount to the POS at block 728 . Wherein, the POS receives the authorization amount at block 730 and limits the transaction to the authorization amount.
  • FIG. 8 shows a flow diagram 800 summarizing a method of settling a gas purchase using a pre-purchased unit-based gas card.
  • a gas card may have been previously authorized, for example, using methods described above in regard to FIG. 7 .
  • the consumer may dispense gas.
  • the gas is dispensed from a gas pump coupled with the POS 702 .
  • the POS device 702 receives a final transaction amount at block 802 .
  • the POS 702 may then send information to the financial processor 704 , including, for example, the final transaction amount, fuel grade, price-per-gallon, and/or geographic location at block 804 .
  • the financial processor 704 may receive this information at block 806 . Whereupon, the final number of gallons dispensed may be calculated using by dividing the final transaction amount by the price-per-gallon at block 808 . The card may then be unlocked at block 810 , and the preloaded balance may be decreased by the number of gallons. The financial processor 704 may then send the remaining balance of the prepaid unit-based gas card to the POS at blocks 814 , 816 . The POS 702 may communicate the remaining balance of the gas card to the user. The balance may also be printed on a receipt.
  • the POS may receive a second presentation instrument to cover the remainder of the transaction. For example, if the user has a prepaid user-based gas card with 9 gallons at a gas price of $3.00 per gallon and the preauthorization amount is $50, then the gas card may not be preauthorized at $50, because the gas card effectively has an $27 balance. Accordingly, the financial processor may communicate to the POS that the transaction is only approved up to $27 or 9 gallons. The POS may then ask the user to present a second presentation instrument if they chose to dispense more than $27 or 9 gallons of gas.
  • users may purchase preloaded unit-based gas cards when the price of the gas seems low. For example, a user may purchase a preloaded unit-based gas card with 100 gallons of gas for $231 when the price-per-gallon of the gas is $2.31. The user may use the preloaded unit-based gas card when the price-per-gallon of gas is $2.85 and, therefore, pay only $2.31 per gallon when the price is at $2.85.
  • inventions may include POS devices and/or methods for offering unit based transactions based on propane or other fuels; building materials, such as lumber, masonry, gravel, sand, concrete, drywall, etc; landscaping materials and/or services; produce, such as milk, fruit, vegetables, poultry, beef, etc; bulk goods; entertainment, etc. Any product or service may be included in a unit based transaction.
  • Embodiments of the invention may extend to purchases of gas in various other currencies and/or measures of volume.
  • the gas card may be used for liters and in Pounds.
  • Currency and/or volumetric conversions may also be applied.
  • embodiments of the invention may more generally permit a transaction to be staged that depends on a varying parameter taking a value in a specified range, with the transaction being executed when the value of the parameter is within that range.
  • placement of a wager might be staged to be dependent on certain payoff odds or on certain point spreads.
  • a horse-racing wager for instance, might be staged on a particular horse to place only if the payoff odds became more favorable than 5:1.
  • the varying odds would then be monitored and the wager placed when the condition was satisfied.
  • a football wager might be staged on a particular team when the point spread for payoff became more favorable than 15 points, with the wager being placed when the condition was satisfied. Still further examples of such transactions will be evident to those of skill in the art after reading this description.

Abstract

Methods and/or systems for providing preauthorization and transaction settlement for a transaction using a prepaid unit-based presentation instrument are disclosed, wherein the presentation instrument includes a unit balance. The method may include receiving a preauthorization request that includes a price-per-unit and a preauthorization amount. The methods and/or systems may then determine whether the unit balance is sufficient to cover the preauthorization amount. If the unit balance is sufficient to cover the preauthorization amount, the presentation instrument is authorized for the transaction. If the unit balance is insufficient to cover the preauthorization amount, a currency balance is determined from the unit balance and the price-per-unit, authorizing the presentation instrument for a transaction up to the currency balance and sending an indication that the currency balance is authorized for the transaction.

Description

    CROSS REFERENCE TO RELATED APPLICATION
  • This application is a continuation-in-part of U.S. patent application Ser. No. 11/283,532, filed Nov. 18, 2005, entitled “Derivative Currency-Exchange Transactions,” which is a continuation-in-part of U.S. patent application Ser. No. 10/984,354, filed Nov. 8, 2004, entitled “Methods And Systems For Implementing Derivative Transactions,” the entire disclosures of which are incorporated herein by reference for all purposes.
  • BACKGROUND OF THE INVENTION
  • This application relates generally to derivative transactions. More specifically, this application relates to methods and systems for implementing derivative transactions.
  • As used herein, references to a “derivative transaction” are intended to refer to a transaction derived at least in part from another transaction that may be executed in the future. Execution of derivative transactions generally take the form of execution of an underlying contract between two parties. One example of a derivative transaction is a “futures transaction,” which is intended to refer herein to a transaction based on a futures contract between two parties specifying a date and certain terms for execution of the futures contract. Another example of a derivative transaction is an “option transaction,” which is intended to refer herein to a transaction based on an option contract between two parties securing the right of at least one of the parties to execute a defined transaction.
  • The derivatives market has developed a great deal of complexity and is most often associated with relatively sophisticated investment strategies. Relatively few individual consumers and small business make practical use of the underlying derivatives as a mechanism for managing costs in a predictable way. Yet this ability is a primary benefit of the derivatives themselves. The very complexity associated with managing derivatives has acted as a barrier to their practical use by individuals and small businesses. The result has been the development of system that is generally more concerned with the trade of derivatives and how profit may be generated by their purchase and sale, rather than their use as cost-management instruments.
  • There is accordingly a general need in the art for methods and systems for implementing derivative transactions that provide more convenience and ease of execution and use.
  • BRIEF SUMMARY OF THE INVENTION
  • Embodiments of the invention provide methods for executing a transaction between a first party and a second party. Instructions are received at a host system to stage the transaction. The instructions includes specification of terms of the transaction and specification of a trigger value of a fluctuating parameter. The terms of the transaction are dependent on a value of the fluctuating parameter. Confirmation is received that funds have been collected from the first party in support of the transaction. Thereafter, the value of the fluctuating parameter is monitored. It is determined whether the monitored value of the fluctuating parameter is at least as favorable to the first party as the trigger value.
  • In one such embodiment, it is determined that the monitored value of the fluctuating parameter is at least as favorable to the first party as the trigger value. In such an embodiment, the transaction is executed with terms in accordance with the monitored value of the fluctuating parameter. In another embodiment, it is determined that the monitored value of the fluctuating parameter is not as favorable to the first party as the trigger value. In such an embodiment, a refund of the funds to the first party is initiated.
  • A method for providing preauthorization for a transaction using a prepaid unit-based presentation instrument is also disclosed according to another embodiment of the invention. The presentation instrument may includes a unit balance, for example, a balance of gallons of gas that have been pre-purchased by the user. A financial processor, financial network computer and/or financial institution system may receive a preauthorization request from a point of sale device for a unit-based transaction using a presentation instrument. The preauthorization request may include geographic location information (for example, a state and/or a zip code), a price-per-unit (for example, price per gallon of gas), product code (for example, fuel grade code), and/or a preauthorization amount. The unit balance on the presentation instrument may then be converted into a currency amount and a determination is made whether this amount is sufficient to cover the preauthorization amount. This determination may be made by comparing the preauthorization amount with the currency amount.
  • If the unit balance is sufficient to cover the preauthorization amount, then the presentation instrument is authorized for the transaction and an indication that the preauthorization amount is authorized for the transaction is sent to the POS. On the other hand, if the unit balance is insufficient to cover the preauthorization amount, then a currency balance is determined from the unit balance and possibly the price-per-unit. The presentation instrument may then be authorized based on the currency balance. An indication of this currency balance is then sent to the POS.
  • The method may further comprise determining whether the geographic location of the point of sale device is within a geographic area authorized by the presentation instrument limits. Moreover, the method may include determining whether the product code is a product code associated with the presentation instrument limits. The method may be easily adapted for use in conjunction with a gas pump. A POS device may be coupled with a gas pump and the presentation instrument may be a gas card.
  • A method for settling a transaction using a prepaid unit-based presentation instrument is disclosed according to one embodiment of the invention. The method may include receiving a transaction amount and price-per-unit from a point of sale device. The number of units corresponding to the transaction amount may be calculated using a price-per-unit and the balance on the presentation instrument may be decreased by the number of units corresponding to the transaction amount. In a specific example, the presentation instrument is a preloaded gallon-based gas card and the price-per-unit is a price per gallon of gas. The remaining unit balance on the transaction card may be calculated and sent to the POS.
  • A point of sale (POS) device coupled with a gas pump is also disclosed according to one embodiment of the invention. The POS device may include a user interface, a network interface and computational logic. The user interface, for example, may include a card reader, a screen and input buttons. The network interface may be coupled to a financial network and may be in communication with a financial processor. An account number associated with a presentation instrument may be received through the card reader. An indication of a gas type may be received from a user through the user interface. The account number, gas type and the price-per-gallon for the selected gas type may be transmitted to a financial processor through the network interface. An indication whether the presentation instrument is approved to purchase gas may be received from the financial processor through the network interface.
  • The POS may determine whether the account number is associated with a unit-based prepaid gas card and/or receive an indication of the amount of gas approved for a transaction. The POS may include a gas pump interface that communicates information to the POS such as the price-per-gallon, the number of gallons, and/or transaction amount. The POS may also send an authorization amount to the gas pump through the gas pump interface.
  • Embodiments of the invention provide methods for executing a money transfer from a first party to a second party. Customer instructions are received at a host system to stage the money transfer. The instructions include specification of an amount of money to be transferred, specification of a first currency in which the funds are to be provided by the first party, specification of a second currency different from the first currency in which the funds are to be received by the second party, and specification of a trigger currency exchange rate. Confirmation is received that the funds have been collected from the first party. A currency exchange rate between the first currency and the second currency is monitored. It is determined whether the monitored currency exchange rate is at least as favorable for the first party as the trigger currency exchange rate.
  • In different embodiments, the amount of money to be transferred may be specified in the first currency or may be specified in the second currency. In different embodiments, the customer instructions may be received at the host system over the Internet or from an in-person money-transfer location.
  • In some embodiments, a determination is made that the monitored currency exchange rate is at least as favorable as the trigger currency exchange rate. In such an instance, the funds are converted from the first currency to the second currency at the monitored currency exchange race and the converted funds are transferred to the control of the second party. The monitored currency exchange rate may sometimes be more favorable than the trigger currency exchange rate. In such a case, the amount of money to be transferred may be increased by an excess corresponding to a difference between the monitored currency exchange rate and the trigger currency exchange rate. Alternatively, a refund of the excess may be initiated.
  • In other embodiments, it may be determined that the monitored currency exchange rate has not become at least as favorable as the trigger currency exchange rate within a defined time. In some such instances, the funds may be refunded to the customer. In another embodiment, the currency exchange rate between the first currency and the second currency may be monitored for a second defined time. In a further embodiment, the funds may nonetheless be converted from the first currency to the second currency at the monitored currency exchange rate, with the converted funds being transferred to the control of the second party.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings wherein like reference numerals are used throughout the several drawings to refer to similar components. In some instances, a sublabel is associated with a reference numeral and follows a hyphen to denote one of multiple similar components. When reference is made to a reference numeral without specification to an existing sublabel, it is intended to refer to all such multiple similar components.
  • FIG. 1 is a block-diagram representation of an exemplary architecture for implementing methods of the invention in an embodiment.
  • FIG. 2 is a flow diagram that summarizes various methods for using stored-value tokens as part of the methods of the invention.
  • FIG. 3 is a schematic illustration of a physical structure of a host system on which methods of the invention may be embodied.
  • FIGS. 4A-4C illustrate the status of certain information that may be maintained in implementing methods of the invention in an exemplary embodiment.
  • FIG. 5 is a block-diagram representation of an exemplary architecture that may be used for effecting money transfers in accordance with certain embodiments.
  • FIG. 6 is a flow diagram summarizing certain methods of the invention.
  • FIG. 7 is a flow diagram summarizing a method of preauthorizing a gas purchase using a pre-purchased unit-based gas card.
  • FIG. 8 is a flow diagram summarizing a method of settling a gas purchase using a pre-purchased unit-based gas card.
  • DETAILED DESCRIPTION OF THE INVENTION
  • 1. Stored-Value-Account Implementations
  • Embodiments of the invention provide methods and systems for handling derivative transactions by using techniques developed for implementing stored-value accounts. A typical stored value account operates by providing a host system that manages the stored-value account, maintaining records of such information as how much value exists in the account, where the value may be used, etc. Generally, a token is provided to an owner of the stored-value account, such as in the form of a magnetic-stripe card, although other tokens may be used, such as in the form of a chip card, rf device, and the like. When a transaction is to be executed using the value stored in the account, the customer provides the token at the time of the transaction, and information is read from the token to identify the account. This identifier is transmitted to the host system, which retrieves records of the amount of value available for use and confirms that the transaction may proceed. The host system debits the value applied during the transaction from the account and performs settlement functions to ensure that the other party to the transaction is credited with that value.
  • Embodiments of the invention use such an arrangement for the implementation of derivative transactions. For purposes of illustration, consider the case of a small business owner who has a generally predictable need for a commodity, such as gasoline. The business owner would like to take advantage of the periodically lower costs for the gasoline by buying greater volumes of it, but lacks storage capacity to hold significant volumes. A derivative would provide a convenient mechanism for the business owner to manage costs, such as by purchasing futures of gasoline at lower costs in accordance with the predicted needs. Similarly, the business owner might sometimes recognize the possibility of a higher-than-average short-term need for gasoline, in which case costs may be effectively managed through purchase of an option. Use of a stored-value arrangement significantly increases the ease of entering and managing such derivative-transaction arrangements.
  • FIG. 1 provides a general overview of an architecture 100 that may be used in implementing embodiments of the invention. The host system 138 that coordinates the transfer of information and that maintains account records comprises a host processor 136 and a data store 140. The host system 138 is provided in communication with a number of other elements of the architecture through communications links with the host processor 136. The communications links may be electrical, optical, wireless, or any other type of communications link known to those of skill in the art.
  • Communications with point-of-sale devices, which may be used when a stored-value token is initially acquired or when a transaction involving the stored-value token is executed, may be routed through a network 144. Because of the sensitive financial nature of the communications, the network 144 usually comprises a secure network. The drawing distinguishes between merchant processors 104, which refer herein to parts of point-of-sale devices that are used in communicating information as part of executing a transaction, and sales terminals 112, which refer herein to parts of point-of-sale devices used when a stored-value token is initially provided to a customer. This distinction is largely conceptual since the same physical devices may usually be used for either or both functions. For purposes of illustration, the point-sale-devices are shown as including a card reader 108 or 116 in communication with the merchant processor 104 or sales terminal 112 for reading magnetic-stripe information in those embodiments where the stored-value token comprises a magnetic-stripe card. In other embodiments, other reading devices as appropriate for the type of token may be used instead. The point-of-sale devices may generally take a variety of different forms, including devices that may be operated by merchant clerks or may be self-operated by customers. The card reader may also include an RFID reader.
  • Examples of point-of-sale devices that have varied functionality are described in the following commonly assigned applications, the entire disclosures of which are incorporated herein by reference for all purposes: U.S. Provisional Patent Application No. 60/147,889, filed Aug. 9, 1999, entitled “Integrated Point Of Sale Device;” U.S. Pat. No. 6,547,132, filed Aug. 9, 2000, entitled “Point Of Sale Payment Terminal;” U.S. patent application Ser. No. 10/116,689, filed Apr. 3, 2002, entitled “Systems And Methods For Performing Transactions At A Point-Of-Sale;” U.S. patent application Ser. No. 10/116,733, filed Apr. 3, 2002, entitled “Systems And Methods For Deploying A Point-Of-Sale System;” U.S. patent application Ser. No. 10/116,686, filed Apr. 3, 2002, entitled “Systems And Methods For Utilizing A Point-Of-Sale System;” and U.S. patent application Ser. No. 10/116,735, filed Apr. 3, 2002, entitled “Systems And Methods For Configuring A Point-Of-Sale System.”
  • The host processor 136 may also be provided in communication with one or more financial-institution processors 152, each of which functions as part of a system that maintains accounts on behalf of account holders on associated data stores 156. The financial institutions are identified as banks in the drawing, but may more generally be any type of financial institution, such as a trust company, and credit union, and the like. Communications between the host processor 136 and the financial-institution processors 152 take place over a financial network 148, which is generally provided as a secure network to protect the confidential and sensitive nature of the financial information that is routed.
  • In some instances, the host system 138 may additionally be provided in communication with other networks that permit customers to access information regarding the stored-value accounts that are maintained on the data store 140. This additional capability is generally of an administrative nature to provide functionality that permits customers to be active in the administration of these accounts. In some instances, more substantive capabilities may also be provided, enabling the customer to transfer funds between a stored-value account maintained by the host system 138 with an account maintained by one of the financial institutions. Other capabilities that might be provided include the ability to make bill payments with stored-value accounts through a network connection with the host system 138, and the like. Such additional networks may be provided in a number of different ways, such as through the use of a public network like the internet 120 that provides communications between the host processor 136 and a customer computers 124. Alternatively or additionally, the architecture 100 may support an interface to process touch-tone commands from customer telephones 132 through a dual-tone multiple-frequency (“DTMF”) processor 128. The DTMF processor 128 translates telephone touch tones to enable a customer to provide instructions through a telephone 132 and transmits audible responses to the customer. Still other mechanisms that may be used in different embodiments include voice-recognition processors, cable processors, and the like. The information-security issues related to the use of public networks like the internet may be different because of the greater risk of interception than over the private networks 144 and 148. A variety of techniques known to those of skill in the art may be used to provide enhanced security, including encryption of data transmitted over such public networks. Such techniques may be used with the transmission of information also over the private networks 144 and 148 to further provide strengthened security of the information.
  • An overview of methods of the invention that may be implemented with an architecture like the one shown in FIG. 1 are summarized with the flow diagram of FIG. 2. For purposes of illustration, the flow diagram shows three different types of transactions that may be executed using the stored-value token, including derivative transactions that are illustrated for a futures transaction and for an option transaction, and also including a purchase transaction using stored value. The execution of a purchase transaction is illustrated explicitly since some embodiments may provide limitations on such a transaction as part of implementing certain types of derivative transactions. For instance, a portion of the stored value for an account may be frozen when the derivative includes a future contractual obligation to ensure that there is sufficient funds support for the contractual obligation. For instance, where the derivative transaction is a futures transaction obligating the customer to make a future purchase, the value needed for that purchase may be earmarked as inaccessible for use in purchase transactions. In contrast, where the derivative transaction is an option transaction, there is no future obligation on the part of the customer to make a purchase so no value is specifically earmarked.
  • These different features may be illustrated by considering the different paths through the flow diagram of FIG. 2. The flow diagram begins with the initial establishment of a customer's stored-value account, as indicated at block 202 with the purchase of a stored-value token equipped for use with derivative transactions. In some instances, a purchased token may have value that has been preloaded in the account, usually an amount that is equal to the purchase price of the token. In any event, the customer may be provided with the capability of adding value to the account, as indicated at block 204, to set a particular value for the account. Adding value may be performed in any of several different ways. For instance, the customer may use the administrative connections described in connection with FIG. 1 to supply a financial account from which value may be transferred to the stored-value account identified by the token. In such instances, the host processor 136 coordinates the value transfer in accordance with instructions from the customer and by using known techniques to identify the customer's authority to initiate debit instructions to a financial account held at a financial institution. Such techniques may include verification of a customer's personal identification number (“PIN”) associated with the account, and the like. Alternatively, the customer may present the token with a tendered value amount at a point-of-sale location, such as at one of the sales terminals 112 identified in FIG. 1. A clerk may swipe the card through the card reader 116 to extract the account identifier, which is transmitted to the host processor 136 to identify the account. The clerk may then accept tendered value from the customer, such as in the form of cash, a check, a credit card, etc. and key in the amount received so that the host system 138 updates the value associated with the identified account. Further ways of adding value may include similar processes that omit the involvement of the clerk by having the customer interact with a self-service device equipped with such devices as a cash collector, check reader, and the like to accept the tendered value.
  • Once a stored-value token has been provided to a customer and the corresponding account includes value, the token may be used in the execution of derivative transactions and purchase transactions. The left column of FIG. 2 illustrates the use of the token as part of a futures transaction, such as where the customer is tendered a futures contract at block 206. Such a contract typically includes terms specifying a date or date range when the contract is to be executed, the goods to be provided to the customer from a seller at the time of execution, and the amount of value to be provided by the customer to the seller at the time of execution. Because a specific amount of value will be needed to support the contract, a check is made at block 208 whether the stored-value account identified by the token has sufficient value. This may be done at any of the point-of-sale devices described in connection with FIG. 1 by extracting an identifier from the token and transmitting it to the host system 138 for retrieval of account information. If the account lacks sufficient value, the contract may be refused by the system at block 210.
  • If the account does have sufficient value, the terms of the contract are stored at the host system 138 at block 212. The storage of such terms may comprise freezing the amount of value required to support the contract so that they cannot be used as part of a purchase transaction or allocated to another futures transaction. At the time required for execution of the contract, the customer may visit the merchant, as noted at block 214, and present the stored-value token. In many instances, the location for execution of the contract may be different from the location where the terms were initially established, reflecting the fact that execution of the contract generally involves the delivery of a commodity or other goods to the customer. For instance, the terms of the contract established as part of executing the futures transaction may have taken place a sales terminal 112 located at a sales office while execution of the contract is performed with a merchant processor 104 located at a distribution center.
  • To execute the contract, the customer presents the stored-value token at block 216. The account identifier provided by the stored-value token is used to retrieve contract terms from the stored-value account at the host system 138 at block 218, which may be displayed to the parties on a monitor or other output device to confirm the contract terms. At block 220, the merchant supplies the commodity or other goods in accordance with the contract terms and at block 222 the host processor 136 deducts the contract amount from the stored-value account. The frozen-value amount is also reduced by the contract amount, but may not be reduced to zero if there were multiple derivative transactions executed that resulted in freezing of multiple amounts. The amount owed to the merchant as a result of executing the contract is transmitted to an account of the merchant, usually at a financial institution, at block 224. While in some instances, this may be done substantially immediately after execution of the contract, more usually it is performed as part of a settlement process that determines how changes in value handled by the host system 138 over some time period, such as a day, should be allocated among multiple merchants and financial institutions. Performing the settlement periodically in this fashion improves efficiency since the allocation of value amounts may be performed with a minimal set of transfers that defines the result of multiple transactions, rather than requiring a separate transfer for each of those transactions.
  • The middle column of FIG. 2 illustrates the use of the token as part of an option transaction, in which the customer purchases the right to execute a transaction without becoming obligated to do so. For example, an option transaction may be executed by a customer making payment of a certain amount in exchange for the right, which is then recorded by the system. Thus, at block 226, the customer purchases the option and the terms of the option are stored at the host system 138 at block 228. The terms of the option generally specify a date or range of dates when the option must be exercised, if at all, and specify the cost of a commodity or other goods to be supplied upon execution. If the customer fails to exercise the option before the end of the time period where he may, the recorded terms may simply be removed by the host system 138, at least from records of currently exercisable options.
  • In order for the customer to execute the option, he may visit the merchant at block 230 during the valid time period. As before, the execution of the option transaction may take place at a different physical location than where it is exercised, such as where the option transaction is executed with a sales terminal at a sales office and the option itself is executed with a merchant processor 104 located at a distribution center. Similar to the steps in executing a futures contract at this point, the customer presents the stored-value token at block 232 so that the local processor may retrieve the relevant option information from the stored-value account maintained by the host system 138 at block 234. In response to the customer exercising the option at block 236, the merchant supplies the commodity or other goods at block 238 in accordance with the option terms. The host processor deducts the amount to be charged from the stored-value account at block 240 and transmits that amount to the merchant account at block 242, usually as part of a periodic settlement process as described above.
  • The right column of FIG. 2 illustrates the use of the token as part of a purchase transaction, highlighting the effect on the availability of stored value that may be manifested as a result of enabling futures transactions to be executed. At block 246, the customer visits and merchant and selects goods for purchase. After the customer offers the stored-value token for payment at block 248, the local processor reads the account identifier from the token and uses it to retrieve the stored-value account information at block 250. If there is not sufficient free value in the account, as checked at block 252, then the purchase transaction is refused at block 254. There may be insufficient free value if the total value in the account is less than the transaction amount; alternatively, there may be insufficient free value even if the total value exceeds the transaction amount but with a portion of it frozen for use in supporting futures transactions or certain other derivative transactions. If the stored-value account has sufficient free value, the host processor deducts the transaction amount from the stored-value account at block 256 and transmits the transaction amount to a merchant account at block 258, usually as part of a periodic settlement process.
  • While the above discussion has focused on instances in which the future transaction is execution of a contract for a sale of goods or services, the future transaction may more generally comprise execution of any contract that requires payment by the customer. For example, in some embodiments, the future transaction comprises the purchase of a different currency by the customer, such as illustrated by an arrangement in which a customer arranges for the future purchase of 1000 euro for a cost of 1250 US dollars. Such an arrangement has the same advantages as other futures arrangements, permitting the customer to avoid future cost fluctuations, in this instance of the purchase of currency. Furthermore, in different embodiments, the transaction may be structured as a futures transaction in which the customer obligates himself to purchase the currency, or may be structured as an options transaction in which the customer secures the right to purchase a specified amount or range of currency at a specified rate.
  • FIG. 3 provides a schematic illustration of a physical structure that may be used to implement the host system 138 in one embodiment. FIG. 3 broadly illustrates how individual system elements may be implemented in a separated or more integrated manner. The host system 138 is shown comprised of hardware elements that are electrically coupled via bus 326, including the host processor 136, an input device 304, an output device 306, the storage device 140, a computer-readable storage media reader 310 a, a communications system 314, a processing acceleration unit 316 such as a DSP or special-purpose processor, and a memory 318. The computer-readable storage media reader 310 a is further connected to a computer-readable storage medium 310 b, the combination comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. The communications system 314 may comprise a wired, wireless, modem, and/or other type of interfacing connection and permits data to be exchanged with the networks 144, 148, 120, and 128 illustrated in FIG. 1 to implement embodiments as described.
  • The host system 138 also comprises software elements, shown as being currently located within working memory 320, including an operating system 324 and other code 322, such as a program designed to implement methods of the invention. It will be apparent to those skilled in the art that substantial variations may be made in accordance with specific requirements. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed.
  • EXAMPLE
  • Methods of the invention as described generally in connection with FIG. 2 are illustrated with a specific example using the diagrams of FIGS. 4A-4C. These diagrams show an example of the type of information that may be maintained by the host system 138 for a particular account as the stored-value token is used by the customer to execute various derivative transactions and/or purchase transactions.
  • Part (a) of FIG. 4A shows an example of a record that may result when the customer initially purchases a stored-value token having a $100 value on February 1. Usually, the cost of the token to the customer is equal to its cash value, although in some instances the cost may be different. For instance, if tokens are provided as part of promotional programs, the initial cost to the customer may be less than the cash value; conversely, if tokens are sold as part of a fund-raising campaign, the initial cost to the customer may be greater than the cash value, with the excess value being donated to the fundraisers. The record for the account maintained on the data store 140 is shown to include a cash value of $100 and no other entries, meaning that the value within the account may be used to support any transaction available with the stored-value token.
  • Part (b) of FIG. 4A shows the result of the customer using the stored-value card on February 15 to execute a purchase transaction for the purchase of goods for $50. The cash value in the account is thus reduced by that amount to $50. A subsequent addition of $200 of value by the customer on March 1 results in the record shown in part (c) of FIG. 4A, reflecting a cash value of $250. The operations shown in parts (a)-(c) of FIG. 4A thus illustrate traditional functionality of a reloadable stored-value account.
  • Part (d) of FIG. 4A shows the type of information that may be maintained when the card is used for execution of a derivative transaction, in this instance a futures transaction. The futures contract that underlies the executed futures transaction is a contract between the customer and ABC Company for the purchase of 100 gallons of gasoline at a cost of $160, the purchase to take place between March 26 and April 2. The futures transaction was approved because the available value in the account of $250 was greater than the contract amount of $160. Accordingly, the total cash value in the account is unchanged at $250, but the contract amount is frozen, leaving $90 of free value. The terms of the underlying contract are also recorded.
  • Because the free value is only $90, an attempt by the customer to execute a purchase transaction on March 20 is rejected, even though the total value in the account exceeds the transaction amount. The account record in part (e) of FIG. 4A is thus unchanged, still reflecting the same total and free value balances and maintaining a record of terms of the futures contract. Conversely, on March 22, when the customer executes a purchase transaction to buy goods for $50 using the stored-value token, the transaction is approved because the transaction amount is less than the free value. The record is thus updated in part (f) of FIG. 4B to reflect a reduction of $50 in both the total cash value stored in the account and in the amount of cash value that is free.
  • On March 30, i.e. within the time window for execution of the contract underlying the futures transaction, the customer visits a distribution center of the ABC company and executes the contract, purchasing the 100 gallons of gasoline for $160. The record maintained at the host system is initially used as described in connection with FIG. 2 to verify the terms of the contact, and is updated to reflect its execution. This is illustrated with part (g) of FIG. 4B, which shows both that the record of a future contract has been removed and that the value has been decremented by the contract amount. The remaining $40 of value is all free value.
  • When the customer adds an additional $200 of value to the account on April 6, the record is updated to reflect the new balance as shown in part (h) of FIG. 4B. The customer subsequently purchases an option from the ABC company on April 8 for the purchase of gasoline. The terms of the option are for an amount of gasoline less than 100 gallons at a rate of $1.65 per gallon, to be purchased between May 1 and May 6. The option transaction costs the customer $20 and ensures the availability of the terms as specified, but does not bind the customer to execute the option; if circumstances are such that the gasoline is not needed, or if the price drops in the interim, the customer may simply allow the option to expire. Accordingly, the updated record shown in part (i) of FIG. 4B shows that the terms of the option have been recorded and that the cash value has been decreased by the $20 payment made as part of executing the option transaction.
  • Because the option does not bind the customer, the value associated with the cost of executing the option, which may be up to $165, is not frozen and the entire $220 of value remains free. Thus, when the customer attempts to execute a purchase transaction on April 12 for $150, the transaction is approved even though the remaining value of $70 shown in part (j) of FIG. 4B is insufficient to cover the maximum potential option cost.
  • It is also possible for the system to record information regarding multiple derivatives. While generally there is no limit on the number of derivatives that may be accommodated at any time, the execution of derivative transactions being limited only by the need to have sufficient value to support binding derivatives like futures, it is possible in some embodiments for the system to limit the number of derivatives to some predetermined number or to some predetermined maximum value. An illustration of recording information regarding multiple derivatives is provided with part (k) of FIG. 4C, which shows how the record is updated when the customer executes a second option transaction to purchase a further option from ABC Company. In this instance, the option again costs $20, which is reflected be the reduction in cash-value balance for the stored-value account, and provides for the purchase of up to 250 gallons of gasoline at $1.50 per gallon between May 3 and May 9. The availability of such a second option with a lower price per gallon and a higher potential volume may reflect external changes in market conditions so that the expenditure of $20 by the customer to secure the second option may well result in a substantial savings overall.
  • Although the illustrations so far have shown examples of derivative transactions executed with a single company, the ABC Company, the system may permit derivative transactions to be executed with multiple different entities. Thus, the customer may wish to execute a futures transaction with XYZ Inc. and therefore adds $400 of value to the stored value account on April 26. This increase is reflected with the updated record shown in part (l) of FIG. 4C. On April 27, execution of the futures transaction to establish a futures contract for the purchase of 22 units at a cost of $125 between June 3 and June 25 is reflected in the updated record shown in part (m) of FIG. 4C. Because the futures contract binds the customer, the $125 of value is frozen so that the free value is identified in the figure as being $325.
  • On May 4, when the customer has the right to execute either or both of the options that have been recorded, he chooses to execute only the second option and to purchase 150 gallons of gasoline at $1.50 per gallon. The updated record in part (n) of FIG. 4C shows the corresponding reduction in total and free values by $225 and the removal of the information regarding the second option from the record. On May 7, when the first option expires, records related to it may simply be removed since the option has not been exercised, the removal of the record thereby preventing the option from being exercised outside the agreed time period.
  • Use of the stored-value token may proceed in this way indefinitely, with the customer adding value as desired and using the stored value to support purchase transactions and derivative transactions that the customer wishes to execute. In addition to records of the type illustrated in FIG. 4, the system may conveniently record historical track records of costs for the various commodities and other goods that are the subject of the derivative transactions. Such records may be valuable both to the customer and to the merchants who sell such goods.
  • 2. Currency-Exchange Implementations
  • Derivative transactions may also be implemented in some embodiments by using currency-exchange mechanisms. Such currency-exchange are implemented in several embodiments as an adjunct to a money-transfer mechanism, with the specific examples discussed herein being illustrative of certain more general derivative mechanisms that are within the intended scope of the invention.
  • A structure that may be used to effect money transfers is illustrated with the block diagram of FIG. 5. The money transfers are effected through a money-transfer network 504 that provides a communications interface between various devices that may be used to initiate money transfers and to receive funds transferred in this manner. For example, local money-transfer processors 508 may be provided at various geographical locations and used to operate money-transfer terminals 512, with each of the money-transfer processors 508 being interfaced with the money-transfer network 504. In such instances, the processor 508 and terminals 512 are generally disposed at a physical location that operates as a money-transfer office. A customer may visit the office physically to arrange for funds to be transferred, providing the funds in cash or through some other mechanism, such as with a credit card or debit card. A clerk may operate one of the terminals 512 to provide information used in effecting the money transfer. Alternatively, the terminals 512 may comprise a self-service terminal operated by the customer herself in staging the money transfer. Similarly, such a physical location may be used by the recipient to receive the transferred funds with clerk-operated or with self-operated terminals to receive the funds. In embodiments where the money transfer includes a currency exchange, the physical locations of the initiating and receiving processor 508/terminal 512 are typically in different countries.
  • Money transfers may alternatively be staged using other types of interfaces with the money-transfer network 504. The drawing shows explicitly that the money-transfer network 504 may be interfaced with the Internet 516, which is in turn interfaced with various computational devices 520. This permits a customer to access money-transfer functionality by connecting his computational device 520 to the Internet 516 to access a web page where such functionality is implemented. With such an interface, the customer will usually provide funds for transfer by using a credit card, debit card, or similar mechanism that may be implemented electronically, instead of by providing cash. Other types of interfaces may be provided with the money-transfer network 504 in various alternative embodiments, including telephone interfaces that respond to DTMF tones, cable interfaces, wireless interfaces, and the like.
  • The flow diagram of FIG. 6 summarizes a number of different embodiments in which a money transfer is implemented with a derivative transaction. In these examples, the derivative transaction comprises a futures transaction linked to a currency exchange rate to be implemented with the money transfer. The money transfer is initiated with the customer visiting a money-transfer site at block 604, either by visiting a physical site where to access a money-transfer terminal 512 or by visiting a virtual site such as where the money transfer is initiated from a web site over the Internet 516. The money transfer is then staged by the customer at block 608. In staging the money transfer, the customer may provide a number of specifications, including the identity of the recipient of the money transfer, the amount of money to be transferred, the location to which the money is to be transferred, the currency in which the money to be transferred is supplied and the currency in which the money transferred is to be received, and the like. When the currency is to be changed as part of the money transfer, embodiments of the invention permit the customer to impose a limit on the exchange rate to be applied. For example, if the customer wishes to transfer US$100 to a recipient in Mexico and to have the Mexican recipient receive the transferred money in Mexican pesos, the customer could require that the exchange rate be at least 10 pesos/US$ before the transfer is executed. In other embodiments, the size of the money transfer may be specified in terms of the amount to be received by the recipient, such as by specifying that M$1000 are to be transferred.
  • The customer pays for the staged money transfer at block 612, generally paying a service charge in addition to the amount of money that is to be transferred. Payment may be made in a variety of different ways in different embodiments, including by cash, by credit card, by debit card, by check, or by any other suitable payment mechanism. The applicable exchange rate is accordingly monitored at block 616. Such monitoring may be substantially continuous, permitting the money transfer to be executed essentially as soon as the exchange rate becomes acceptable. Alternatively, the monitoring may be periodic so that the exchange rate is checked at different times. Such periodic monitoring, because it effectively samples the rates, may result in overlooking certain windows in which an acceptable exchange rate might have been used. At the same time, such periodic monitoring may also cause the system to respond when an even more favorable rate than the trigger value is available, while continuous monitoring would effectively always respond when the exchange rate is at the trigger value.
  • A check is accordingly made, for either type of monitoring, at block 620 whether the current exchange rate is consistent with the terms established by the customer at that moment in time. If not, a number of different possibilities exist for responding, depending on other conditions that may have been specified by the customer. For example, a check is made at block 624 whether a time limit imposed by the customer has expired. If not, the method may simply continue to monitor the current exchange rate at block 616 as it fluctuates.
  • If the time limit has expired, or if some other condition has not been satisfied to indicate that the staging conditions have not been met, the customer may be notified of that determination at block 628. Subsequent action may then proceed either on the basis of further instructions provided by the customer, on the basis of prior instructions provided by the customer at the time of staging, or in accordance with default procedures in different embodiments. For instance, the customer may indicate that the time limit is to be reset, a check for which is indicated at block 632. Such an indication may be given explicitly by the customer after notification of the failure to meet the staging conditions, or could be a way of implementing a protocol where specified time limits are restricted to integral multiples of a base time limit.
  • Another option that may be provided is the option to execute the money transfer at the higher exchange rate, as checked at block 636. If the customer declines to do so, either in accordance with standing or new instructions, the money transfer may be canceled at block 640 and a refund of amounts paid, perhaps less a service charge, refunded to the customer at block 644.
  • Thus, in the embodiments illustrated by FIG. 6, execution of the staged money transfer may occur when the exchange rate is identified as being within an acceptable range or when a decision has been made to execute the transfer notwithstanding the failure of the exchange rate to fall within the acceptable range. In either case, the funds are transferred to the recipient over the money-transfer network 504 at block 648 using methods known to those of skill in the art. Such a funds transfer applies the current currency exchange rate and may sometimes result in there being an excess of funds as a result of the fluctuation of the exchange rate. This is especially possible in embodiments where the transfer amount is specified in terms of the amount to be provided to the recipient and where the exchange rate is monitored only periodically.
  • A check may thus be made at block 652 whether there are excess funds, with different options being available for handling the excess funds. Such options may be selected by the customer upon notification of the existence of the excess funds, could have been identified by the customer at the time of staging the money transfer at block 608, or could be performed in accordance with a default protocol. In some instances, as indicated at block 656, the size of the money transfer may be increased in accordance with the excess funds made available by the favorable exchange rate. Alternatively, as indicated at block 670, the excess funds may be refunded to the customer.
  • 3. Prepaid, Unit-Based Gas Card Implementations
  • FIG. 7 shows a flow diagram 700 summarizing a method of preauthorizing a gas purchase using a pre-purchased unit-based gas card according to one embodiment of the invention. The method may be used in conjunction with a preloaded presentation instrument for purchasing gasoline from gas stations, for example, a preloaded gas card. The presentation instrument may be purchased and preloaded with a number of gallons. For instance, a user may purchase a preloaded gas card with a set number of gallons. For example, the consumer may buy a gas card with 25 gallons or 50 gallons. If the price-per-gallon is set at the time of the purchase at $2.00 per gallon, the consumer would purchase the preloaded gas card for $50 and $100 respectfully.
  • The preloaded gas card may then be used to purchase gallons of gasoline from participating gas stations. The number of gallons preloaded on the gas card may be decreased according to the number of gallons purchased. If the consumer wishes to purchase more than the number of gallons left on the gas card, they may present a second form of payment to pay for the surplus gas.
  • According to the flow diagram 700, card info is received from a user 706 at a point of sale device 702. The card info may be received from a card reader and/or a RFID reader. The consumer may be asked to enter a PIN, password and/or biometric sample to confirm ownership of the gas card. The card information may include account number, name, etc. The POS device 702 may then determine whether the card is, indeed, a unit-based gas card at block 708. A gift card or other card may also be used at the card reader. Accordingly, a determination regarding the type of card entered into the card reader must occur. A gas card, for example, may include a numeric code that differs from a gift card and which may be used to distinguish gas cards (or unit-based cards) from gift cards.
  • If the card is a preloaded gas card, the method receives the fuel grade, gas price, geographic location, and preauthorization amount at block 710. This information, the fuel grade, gas price, geographic location, and preauthorization amount, may then be packaged as part of a preauthorization request. The fuel grade selection may be received from the user through the user interface. For example, once the unit-based card has been recognized, the user may be prompted for a fuel grade selection. The gas price may be received from physical memory and associated with the fuel grade selection. The geographic information may include a zip code and or state code. Gas prices vary from state to state, location to location and across zip codes. Accordingly, some preloaded gas cards may be geographically limited. For example, the gas cards may only be used in specific locations, such as states and/or zip codes. The POS device 702 may also receive a preauthorization amount from memory. The preauthorization request may then be sent to a financial processor at block 712.
  • At the financial processor 704, the preauthorization request is received at block 714. The financial processor may then determine whether any limits are associated with the account and if the preauthorization request satisfies those limits. For example, the financial processor may compare the geographic location information received from the POS and determine whether the geographic location is within the limits set by the account. As another example, the gas card may be limited to certain fuel grade, such as, premium or high octane. If the grade selection does not match the grade type associated with the gas card, then the transaction will terminate. Other limitations may also be applied to the account. If the limits are not met, the transaction ends at block 717. If the limits are met, then the financial processor calculates the current currency amount of the balance of the card at block 718. The current currency balance (Bal$$) is determined by multiplying the unit balance (Balunit) on the card by the price-per-gallon (price) received in the preauthorization request. If the current currency amount is greater than or equal to the preauthorization amount, as determined at block 720, then the authentication amount is set equal to the preauthorization amount at block 724, otherwise the authorization amount is set to the current currency balance at block 722. The financial processor then locks an amount equal to the authorization amount on the card at block 726. The financial processor then sends the authorization amount to the POS at block 728. Wherein, the POS receives the authorization amount at block 730 and limits the transaction to the authorization amount.
  • FIG. 8 shows a flow diagram 800 summarizing a method of settling a gas purchase using a pre-purchased unit-based gas card. Such a gas card may have been previously authorized, for example, using methods described above in regard to FIG. 7. Once a user has been preauthorized to user their unit-based gas card, the consumer may dispense gas. In one embodiment of the invention, the gas is dispensed from a gas pump coupled with the POS 702. When the user has finished dispensing the gas, the POS device 702 receives a final transaction amount at block 802. The POS 702 may then send information to the financial processor 704, including, for example, the final transaction amount, fuel grade, price-per-gallon, and/or geographic location at block 804.
  • The financial processor 704 may receive this information at block 806. Whereupon, the final number of gallons dispensed may be calculated using by dividing the final transaction amount by the price-per-gallon at block 808. The card may then be unlocked at block 810, and the preloaded balance may be decreased by the number of gallons. The financial processor 704 may then send the remaining balance of the prepaid unit-based gas card to the POS at blocks 814, 816. The POS 702 may communicate the remaining balance of the gas card to the user. The balance may also be printed on a receipt.
  • In another embodiment of the invention, if the balance on the prepaid unit-based gift card is not sufficient to cover the preauthorization amount and/or the user dispenses more gas than the prepaid unit-based gas card can accommodate, then the POS may receive a second presentation instrument to cover the remainder of the transaction. For example, if the user has a prepaid user-based gas card with 9 gallons at a gas price of $3.00 per gallon and the preauthorization amount is $50, then the gas card may not be preauthorized at $50, because the gas card effectively has an $27 balance. Accordingly, the financial processor may communicate to the POS that the transaction is only approved up to $27 or 9 gallons. The POS may then ask the user to present a second presentation instrument if they chose to dispense more than $27 or 9 gallons of gas.
  • With embodiments of the present invention, users may purchase preloaded unit-based gas cards when the price of the gas seems low. For example, a user may purchase a preloaded unit-based gas card with 100 gallons of gas for $231 when the price-per-gallon of the gas is $2.31. The user may use the preloaded unit-based gas card when the price-per-gallon of gas is $2.85 and, therefore, pay only $2.31 per gallon when the price is at $2.85.
  • Other embodiments of the invention may include POS devices and/or methods for offering unit based transactions based on propane or other fuels; building materials, such as lumber, masonry, gravel, sand, concrete, drywall, etc; landscaping materials and/or services; produce, such as milk, fruit, vegetables, poultry, beef, etc; bulk goods; entertainment, etc. Any product or service may be included in a unit based transaction.
  • Embodiments of the invention may extend to purchases of gas in various other currencies and/or measures of volume. For instance, the gas card may be used for liters and in Pounds. Currency and/or volumetric conversions may also be applied.
  • While the above description has focused on specific embodiments where variation in exchange rates is used to trigger execution of a future money transfer, other embodiments may more generally embrace either types of future transactions that depend on a varying parameter. In particular, embodiments of the invention may more generally permit a transaction to be staged that depends on a varying parameter taking a value in a specified range, with the transaction being executed when the value of the parameter is within that range. For example, in gambling contexts, placement of a wager might be staged to be dependent on certain payoff odds or on certain point spreads. A horse-racing wager, for instance, might be staged on a particular horse to place only if the payoff odds became more favorable than 5:1. The varying odds would then be monitored and the wager placed when the condition was satisfied. Similarly, a football wager might be staged on a particular team when the point spread for payoff became more favorable than 15 points, with the wager being placed when the condition was satisfied. Still further examples of such transactions will be evident to those of skill in the art after reading this description.
  • Thus, having described several embodiments, it will be recognized by those of skill in the art that various modifications, alternative constructions, and equivalents may be used without departing from the spirit of the invention. Accordingly, the above description should not be taken as limiting the scope of the invention, which is defined in the following claims.

Claims (18)

1. A method for providing preauthorization for a transaction using a prepaid unit-based presentation instrument, wherein the presentation instrument includes a unit balance, the method comprising:
receiving a preauthorization request from a point of sale device for a unit-based transaction using a presentation instrument;
determining whether the unit balance associated with the presentation instrument is sufficient to cover the preauthorization amount;
if the unit balance is sufficient to cover the preauthorization amount, authorizing the presentation instrument for the transaction and sending an indication that the preauthorization amount is authorized for the transaction; and
if the unit balance is insufficient to cover the preauthorization amount, determining a currency balance from the unit balance, authorizing the presentation instrument for a transaction up to the currency balance and sending an indication that the currency balance is authorized for the transaction.
2. The method of claim 1, wherein the determining comprises:
calculating a currency balance from the unit balance and a price-per-unit; and
comparing the currency balance with the preauthorization amount.
3. The method of claim 1, wherein the preauthorization requests comprises a price-per-unit and the currency balance depends on the price-per-unit.
4. The method of claim 1, wherein the transaction information comprises a geographic location and the method further comprises determining whether the geographic location is within a geographic area authorized by the presentation instrument limits.
5. The method of claim 1, wherein the transaction information comprises a product code and the method further comprises determining whether the product code is a product code associated with the presentation instrument limits.
6. The method of claim 5, wherein the product code comprises a fuel grade code.
7. The method of claim 1, wherein the transaction information further comprises information selected from the group consisting of a product code, a price, a currency type and a geographic location.
8. The method of claim 1, wherein:
the preauthorization request is received from a point of sale device at a gas station; and
the unit balance comprises a balance of prepaid gallons of gas.
9. The method of claim 1, wherein the presentation instrument is a gas card and the preauthorization comprises a price per gallon of gas.
10. A method for settling a transaction using a prepaid unit-based presentation instrument, the method comprising:
receiving a transaction amount and price-per-unit from a point of sale device;
calculating the number of units corresponding to the transaction amount using the price-per-unit; and
decreasing the balance on the presentation instrument by the number of units corresponding to the transaction amount.
11. The method of claim 10, wherein the presentation instrument comprises a preloaded gallon-based gas card and the price-per-unit comprises a price per gallon of gas.
12. The method of claim 10, further comprising:
calculating the remaining unit balance on the transaction card; and
sending the remaining balance to the point of sale device.
13. A point of sale (POS) device coupled with a gas pump, the POS device comprising:
a user interface comprising at least a card reader;
a network interface in communication with a financial processor; and
computational logic, wherein the computational logic is configured to:
receive an account number associated with a presentation instrument through the card reader;
receive an indication of a gas type from a user through the user interface;
transmit the account number, gas type and an indication of the price-per-gallon for the selected gas type through the network interface to the financial processor; and
receive an indication from the financial processor through the network interface whether the presentation instrument is approved to purchase gas.
14. The method of claim 13, wherein the computational logic is further configured to determine whether the account number is associated with a unit-based prepaid gas card.
15. The method of claim 13, wherein the computational logic is further configured to receive an indication of the amount of gas approved for a transaction.
16. The method of claim 13 further comprising a gas pump interface.
17. The method of claim 16, wherein the gas pump interface communicates information to the POS selected from the group consisting of the price-per-gallon, the number of gallons, and transaction amount.
18. The method of claim 16, wherein the gas pump interface sends an authorization amount to the gas pump through the gas pump interface.
US11/764,324 2004-11-08 2007-06-18 Unit-based prepaid presentation instrument accounts and methods Expired - Fee Related US7813982B2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US11/764,324 US7813982B2 (en) 2004-11-08 2007-06-18 Unit-based prepaid presentation instrument accounts and methods
CA2691076A CA2691076A1 (en) 2007-06-18 2008-06-16 Unit-based prepaid presentation instrument accounts and methods
PCT/US2008/067131 WO2008157502A1 (en) 2007-06-18 2008-06-16 Unit-based prepaid presentation instrument accounts and methods

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/984,354 US20060100959A1 (en) 2004-11-08 2004-11-08 Methods and systems for implementing derivative transactions
US11/283,532 US7783539B2 (en) 2004-11-08 2005-11-18 Derivative currency-exchange transactions
US11/764,324 US7813982B2 (en) 2004-11-08 2007-06-18 Unit-based prepaid presentation instrument accounts and methods

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/283,532 Continuation-In-Part US7783539B2 (en) 2004-11-08 2005-11-18 Derivative currency-exchange transactions

Publications (2)

Publication Number Publication Date
US20080195497A1 true US20080195497A1 (en) 2008-08-14
US7813982B2 US7813982B2 (en) 2010-10-12

Family

ID=40156660

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/764,324 Expired - Fee Related US7813982B2 (en) 2004-11-08 2007-06-18 Unit-based prepaid presentation instrument accounts and methods

Country Status (3)

Country Link
US (1) US7813982B2 (en)
CA (1) CA2691076A1 (en)
WO (1) WO2008157502A1 (en)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090048935A1 (en) * 2007-08-16 2009-02-19 Microsoft Corporation Application program interface to manage gift cards and check authorizations
US20150278788A1 (en) * 2014-03-28 2015-10-01 Kapsch Trafficcom Ag Eletronic commerce transaction system using electronic toll collection transponders
CN107077673A (en) * 2014-07-11 2017-08-18 谷歌公司 Exempt from transaction manually using inquiry request
US20190106317A1 (en) * 2016-06-20 2019-04-11 Visa International Service Association Efficient resource provider system
US20190228480A1 (en) * 2018-01-24 2019-07-25 Maverik, Inc Generating receipts at remote fuel dispensers
WO2021133536A1 (en) * 2019-12-23 2021-07-01 Futures Partners LLC Systems and methods for commodity exchanges
CN113129088A (en) * 2021-03-31 2021-07-16 郭军 Payment terminal financial bill big data management method and system
CN113450105A (en) * 2020-03-27 2021-09-28 丰田自动车株式会社 Recording medium storing settlement program, settlement system, and server
US11263610B2 (en) * 2015-04-14 2022-03-01 Amy SZETO Processing of unit-based transactions
US11270285B2 (en) * 2019-05-17 2022-03-08 Z Energy Limited Fuel pre-purchasing and sharing system and associated methods

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8346611B2 (en) * 2009-04-21 2013-01-01 First Data Corporation Systems and methods for pre-paid futures procurement
AU2010249214C1 (en) 2009-12-15 2014-08-21 Zonamovil, Inc. Methods, apparatus, and systems for supporting purchases of goods and services via prepaid telecommunication accounts

Citations (80)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3599151A (en) * 1969-12-29 1971-08-10 Ibm Character recognition photosensing apparatus having a threshold comparator circuit
US3833395A (en) * 1972-09-11 1974-09-03 Burroughs Corp Continuous form computer print-out document protection system
US4321672A (en) * 1979-11-26 1982-03-23 Braun Edward L Financial data processing system
US4562341A (en) * 1983-02-18 1985-12-31 Omron Tateisi Electronics Co. Electronic cash register
US4562340A (en) * 1982-10-19 1985-12-31 Omron Tateisi Electronics Co. Terminal device for making payments for credit transactions
US4630200A (en) * 1983-03-01 1986-12-16 Omron Tateisi Electronics Co. Electronic cash register capable of performing cash-dispensing transactions
US4678895A (en) * 1982-10-29 1987-07-07 Omron Tateisi Electronics Co. System for making payments for transactions
US4722554A (en) * 1986-08-27 1988-02-02 St. Ives Laboratories, Inc. Alternative-value paper refund form
US4812628A (en) * 1985-05-02 1989-03-14 Visa International Service Association Transaction system with off-line risk assessment
US4902881A (en) * 1988-06-10 1990-02-20 Faxplus Corporation Parallel process communications terminal and network
US4961142A (en) * 1988-06-29 1990-10-02 Mastercard International, Inc. Multi-issuer transaction device with individual identification verification plug-in application modules for each issuer
US5053607A (en) * 1986-10-06 1991-10-01 Carlson Steven R Point-of-sale device particularly adapted for processing checks
US5119293A (en) * 1988-09-16 1992-06-02 Republic Money Orders, Inc. System and apparatus for dispensing negotiable instruments
US5122625A (en) * 1989-09-18 1992-06-16 Mitsubishi Denki Kabushiki Kaisha Circuit breaker
US5175682A (en) * 1990-12-14 1992-12-29 Verifone, Inc. Check system and method including prioritizing checks for transmission to banks for processing
US5220501A (en) * 1989-12-08 1993-06-15 Online Resources, Ltd. Method and system for remote delivery of retail banking services
US5233167A (en) * 1991-06-24 1993-08-03 Positek Incorporated Multi-function terminal
US5367452A (en) * 1990-10-05 1994-11-22 Carts Of Colorado, Inc. Mobile merchandising business management system which provides comprehensive support services for transportable business operations
US5408077A (en) * 1992-07-16 1995-04-18 Telxon Corporation Portable point of sale terminal
US5426594A (en) * 1993-04-02 1995-06-20 Motorola, Inc. Electronic greeting card store and communication system
US5464971A (en) * 1991-03-12 1995-11-07 Sutcliffe; Peter H. Apparatus and method for receiving and processing a bet
US5484988A (en) * 1992-11-13 1996-01-16 Resource Technology Services, Inc. Checkwriting point of sale system
US5491325A (en) * 1992-08-25 1996-02-13 Huang; Dorge O. Method and system for payment and payment verification
US5504677A (en) * 1992-10-15 1996-04-02 Pollin; Robert E. Automated payment system
US5510979A (en) * 1991-07-30 1996-04-23 Restaurant Technology, Inc. Data processing system and method for retail stores
US5555496A (en) * 1994-05-06 1996-09-10 Mary T. Tackbary Method and apparatus for communicating with a card distribution center for management, selection, and delivery of social expression cards
US5577109A (en) * 1994-06-06 1996-11-19 Call Processing, Inc. Pre-paid card system and method
US5622388A (en) * 1995-03-23 1997-04-22 Alcordo; Isabelo S. Postcard rank check
US5650604A (en) * 1995-02-22 1997-07-22 Electronic Data Systems Corporation System and method for electronic transfer of funds using an automated teller machine to dispense the transferred funds
US5657201A (en) * 1995-11-06 1997-08-12 Teletransactions, Inc. Portable data collection terminal including arm mounting assembly
US5677955A (en) * 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US5679940A (en) * 1994-12-02 1997-10-21 Telecheck International, Inc. Transaction system with on/off line risk assessment
US5699528A (en) * 1995-10-31 1997-12-16 Mastercard International, Inc. System and method for bill delivery and payment over a communications network
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US5794207A (en) * 1996-09-04 1998-08-11 Walker Asset Management Limited Partnership Method and apparatus for a cryptographically assisted commercial network system designed to facilitate buyer-driven conditional purchase offers
US5815657A (en) * 1996-04-26 1998-09-29 Verifone, Inc. System, method and article of manufacture for network electronic authorization utilizing an authorization instrument
US5826241A (en) * 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US5825617A (en) * 1992-10-02 1998-10-20 Teletransactions, Inc. Workslate computer having modular device docking stations on horizontal and vertical side portions
US5828875A (en) * 1997-05-29 1998-10-27 Telefonaktiebolaget Lm Ericsson Unroll of instructions in a micro-controller
US5832463A (en) * 1996-03-28 1998-11-03 Electronic Data Systems Corporation Automated system and method for checkless check transaction
US5878211A (en) * 1996-12-20 1999-03-02 N C R Corporation Multi-functional retail terminal and associated method
US5893080A (en) * 1995-07-25 1999-04-06 Bottomline Technologies, Inc. Disbursement system and method
US5910988A (en) * 1997-08-27 1999-06-08 Csp Holdings, Inc. Remote image capture with centralized processing and storage
US5949044A (en) * 1997-06-13 1999-09-07 Walker Asset Management Limited Partnership Method and apparatus for funds and credit line transfers
US5987426A (en) * 1997-10-14 1999-11-16 Ncr Corporation Point-of-sale system including isolation layer between client and server software
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US6032133A (en) * 1993-11-01 2000-02-29 Visainternational Service Association Electronic bill pay system
US6030000A (en) * 1997-09-12 2000-02-29 Diamond Security, Inc. Negotiable document having enhanced security for deterring fraud by use of a thermochromatic fingerprint image
US6039245A (en) * 1996-06-10 2000-03-21 Diebold, Incorporated Financial transaction processing system and method
US6058417A (en) * 1998-10-23 2000-05-02 Ebay Inc. Information presentation and management in an online trading environment
US6064990A (en) * 1998-03-31 2000-05-16 International Business Machines Corporation System for electronic notification of account activity
US6070798A (en) * 1997-02-21 2000-06-06 Nethery; Kee Purchaser generated transaction recording and negotiable instrument payment system
US6097834A (en) * 1997-06-13 2000-08-01 Paystation America Inc. Financial transaction processing systems and methods
US6106020A (en) * 1997-10-28 2000-08-22 Kerning Data Systems, Inc. Fraud prevention method and system
US6119106A (en) * 1997-11-26 2000-09-12 Mersky; Randy Method and apparatus for facilitating customer payments to creditors from a remote site
US6149056A (en) * 1997-02-06 2000-11-21 Mr. Payroll Corporation Automatic check cashing using biometric identification verification
US6164528A (en) * 1996-12-31 2000-12-26 Chequemark Patent, Inc. Check writing point of sale system
US6175823B1 (en) * 1998-09-15 2001-01-16 Amazon.Com, Inc. Electronic gift certificate system
US6193152B1 (en) * 1997-05-09 2001-02-27 Receiptcity.Com, Inc. Modular signature and data-capture system and point of transaction payment and reward system
US6199791B1 (en) * 1996-07-12 2001-03-13 Fort James, S.A.R.L. Dispenser for roll material strip without winding core comprising an improved supporting spindle
US6305604B1 (en) * 1998-03-26 2001-10-23 Seiko Epson Corporation Printing apparatus, reading apparatus, and processing system for checks
US6308887B1 (en) * 1997-12-02 2001-10-30 Cash Technologies, Inc. Multi-transactional architecture
US6321984B1 (en) * 1997-02-25 2001-11-27 Dresser Equipment Group, Inc. Adjustable price fuel dispensing system
US6327570B1 (en) * 1998-11-06 2001-12-04 Dian Stevens Personal business service system and method
US6327575B1 (en) * 1999-04-26 2001-12-04 Ronald Craig Katz Point of sale terminal for the visually impaired
US20010049651A1 (en) * 2000-04-28 2001-12-06 Selleck Mark N. Global trading system and method
US20010051876A1 (en) * 2000-04-03 2001-12-13 Seigel Ronald E. System and method for personalizing, customizing and distributing geographically distinctive products and travel information over the internet
US6360254B1 (en) * 1998-09-15 2002-03-19 Amazon.Com Holdings, Inc. System and method for providing secure URL-based access to private resources
US6367693B1 (en) * 1997-10-02 2002-04-09 John C. Novogrod System and method for requesting and dispensing negotiable instruments
US20020153414A1 (en) * 1999-08-09 2002-10-24 First Data Corporation Systems and methods for performing transactions at a point-of-sale
US6484936B1 (en) * 1998-11-11 2002-11-26 Ncr Corporation Terminal
US6539363B1 (en) * 1990-08-30 2003-03-25 Ncr Corporation Write input credit transaction apparatus and method with paperless merchant credit card processing
US6549119B1 (en) * 1995-02-15 2003-04-15 International Computers Limited Electronic identification system
US6547132B1 (en) * 1999-08-09 2003-04-15 First Data Corporation Point of sale payment terminal
US20030097321A1 (en) * 2000-11-22 2003-05-22 Masakazu Arikawa Method and system for concentratedly managing funds among enterprises
US20030197060A1 (en) * 2001-12-06 2003-10-23 Vince Coyner Consumer-focused gallon-based prepaid gasoline card, system and method for a car drivers
US20040098326A1 (en) * 2002-11-01 2004-05-20 First Data Corporation Stored value currency conversion systems and methods
US6827260B2 (en) * 1999-08-09 2004-12-07 First Data Corporation Systems and methods for utilizing a point-of-sale system
US6886742B2 (en) * 1999-08-09 2005-05-03 First Data Corporation Systems and methods for deploying a point-of sale device
US7086584B2 (en) * 1999-08-09 2006-08-08 First Data Corporation Systems and methods for configuring a point-of-sale system

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4948174A (en) 1988-04-20 1990-08-14 Remittance Technology Corporation Financial data processing system
US5453601A (en) 1991-11-15 1995-09-26 Citibank, N.A. Electronic-monetary system
US6199761B1 (en) 1996-12-09 2001-03-13 Drexler Technology Corporation Validation method for electronic cash cards and digital identity cards utilizing optical data storage
EP0949596A3 (en) 1998-03-30 2003-01-08 Citibank, N.A. Method and system to perform electronic value exchange and settlement among heterogeneous payment schemes with heterogeneous currencies
WO2000046725A1 (en) 1999-02-05 2000-08-10 Fundsxpress, Inc. System and method for conducting online financial transactions using electronic funds transfer and public communications networks
CA2369081C (en) 1999-04-30 2012-02-07 X.Com Corporation System and method for electronically exchanging value among distributed users
WO2001004816A1 (en) 1999-07-09 2001-01-18 Citicorp Credit Services, Inc. Method and system for managing and conducting a network auction
EP1077436A3 (en) 1999-08-19 2005-06-22 Citicorp Development Center, Inc. System and method for performing an on-line transaction using a single-use payment instrument
EP1312012A4 (en) 2000-07-11 2006-09-06 First Data Corp Wide area network person-to-person payment

Patent Citations (83)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3599151A (en) * 1969-12-29 1971-08-10 Ibm Character recognition photosensing apparatus having a threshold comparator circuit
US3833395A (en) * 1972-09-11 1974-09-03 Burroughs Corp Continuous form computer print-out document protection system
US4321672A (en) * 1979-11-26 1982-03-23 Braun Edward L Financial data processing system
US4562340A (en) * 1982-10-19 1985-12-31 Omron Tateisi Electronics Co. Terminal device for making payments for credit transactions
US4678895A (en) * 1982-10-29 1987-07-07 Omron Tateisi Electronics Co. System for making payments for transactions
US4562341A (en) * 1983-02-18 1985-12-31 Omron Tateisi Electronics Co. Electronic cash register
US4630200A (en) * 1983-03-01 1986-12-16 Omron Tateisi Electronics Co. Electronic cash register capable of performing cash-dispensing transactions
US4812628A (en) * 1985-05-02 1989-03-14 Visa International Service Association Transaction system with off-line risk assessment
US4722554A (en) * 1986-08-27 1988-02-02 St. Ives Laboratories, Inc. Alternative-value paper refund form
US5053607A (en) * 1986-10-06 1991-10-01 Carlson Steven R Point-of-sale device particularly adapted for processing checks
US4902881A (en) * 1988-06-10 1990-02-20 Faxplus Corporation Parallel process communications terminal and network
US4961142A (en) * 1988-06-29 1990-10-02 Mastercard International, Inc. Multi-issuer transaction device with individual identification verification plug-in application modules for each issuer
US5119293A (en) * 1988-09-16 1992-06-02 Republic Money Orders, Inc. System and apparatus for dispensing negotiable instruments
US5122625A (en) * 1989-09-18 1992-06-16 Mitsubishi Denki Kabushiki Kaisha Circuit breaker
US5220501A (en) * 1989-12-08 1993-06-15 Online Resources, Ltd. Method and system for remote delivery of retail banking services
US6539363B1 (en) * 1990-08-30 2003-03-25 Ncr Corporation Write input credit transaction apparatus and method with paperless merchant credit card processing
US5367452A (en) * 1990-10-05 1994-11-22 Carts Of Colorado, Inc. Mobile merchandising business management system which provides comprehensive support services for transportable business operations
US5175682A (en) * 1990-12-14 1992-12-29 Verifone, Inc. Check system and method including prioritizing checks for transmission to banks for processing
US5464971A (en) * 1991-03-12 1995-11-07 Sutcliffe; Peter H. Apparatus and method for receiving and processing a bet
US5233167A (en) * 1991-06-24 1993-08-03 Positek Incorporated Multi-function terminal
US5510979A (en) * 1991-07-30 1996-04-23 Restaurant Technology, Inc. Data processing system and method for retail stores
US5408077A (en) * 1992-07-16 1995-04-18 Telxon Corporation Portable point of sale terminal
US5491325A (en) * 1992-08-25 1996-02-13 Huang; Dorge O. Method and system for payment and payment verification
US5825617A (en) * 1992-10-02 1998-10-20 Teletransactions, Inc. Workslate computer having modular device docking stations on horizontal and vertical side portions
US5504677A (en) * 1992-10-15 1996-04-02 Pollin; Robert E. Automated payment system
US5484988A (en) * 1992-11-13 1996-01-16 Resource Technology Services, Inc. Checkwriting point of sale system
US5426594A (en) * 1993-04-02 1995-06-20 Motorola, Inc. Electronic greeting card store and communication system
US6032133A (en) * 1993-11-01 2000-02-29 Visainternational Service Association Electronic bill pay system
US5555496A (en) * 1994-05-06 1996-09-10 Mary T. Tackbary Method and apparatus for communicating with a card distribution center for management, selection, and delivery of social expression cards
US5960412A (en) * 1994-05-06 1999-09-28 Tackbary; Mary Thomasma Method and apparatus for communicating with a card distribution center for management, selection, and delivery of social expression cards
US5577109A (en) * 1994-06-06 1996-11-19 Call Processing, Inc. Pre-paid card system and method
US6246996B1 (en) * 1994-09-16 2001-06-12 Messagemedia, Inc. Computerized system for facilitating transactions between parties on the internet using e-mail
US5826241A (en) * 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US5679940A (en) * 1994-12-02 1997-10-21 Telecheck International, Inc. Transaction system with on/off line risk assessment
US6549119B1 (en) * 1995-02-15 2003-04-15 International Computers Limited Electronic identification system
US5650604A (en) * 1995-02-22 1997-07-22 Electronic Data Systems Corporation System and method for electronic transfer of funds using an automated teller machine to dispense the transferred funds
US5622388A (en) * 1995-03-23 1997-04-22 Alcordo; Isabelo S. Postcard rank check
US5677955A (en) * 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US5893080A (en) * 1995-07-25 1999-04-06 Bottomline Technologies, Inc. Disbursement system and method
US5699528A (en) * 1995-10-31 1997-12-16 Mastercard International, Inc. System and method for bill delivery and payment over a communications network
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US5657201A (en) * 1995-11-06 1997-08-12 Teletransactions, Inc. Portable data collection terminal including arm mounting assembly
US5832463A (en) * 1996-03-28 1998-11-03 Electronic Data Systems Corporation Automated system and method for checkless check transaction
US5815657A (en) * 1996-04-26 1998-09-29 Verifone, Inc. System, method and article of manufacture for network electronic authorization utilizing an authorization instrument
US6039245A (en) * 1996-06-10 2000-03-21 Diebold, Incorporated Financial transaction processing system and method
US6199791B1 (en) * 1996-07-12 2001-03-13 Fort James, S.A.R.L. Dispenser for roll material strip without winding core comprising an improved supporting spindle
US5794207A (en) * 1996-09-04 1998-08-11 Walker Asset Management Limited Partnership Method and apparatus for a cryptographically assisted commercial network system designed to facilitate buyer-driven conditional purchase offers
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US5878211A (en) * 1996-12-20 1999-03-02 N C R Corporation Multi-functional retail terminal and associated method
US6164528A (en) * 1996-12-31 2000-12-26 Chequemark Patent, Inc. Check writing point of sale system
US6149056A (en) * 1997-02-06 2000-11-21 Mr. Payroll Corporation Automatic check cashing using biometric identification verification
US6070798A (en) * 1997-02-21 2000-06-06 Nethery; Kee Purchaser generated transaction recording and negotiable instrument payment system
US6321984B1 (en) * 1997-02-25 2001-11-27 Dresser Equipment Group, Inc. Adjustable price fuel dispensing system
US6193152B1 (en) * 1997-05-09 2001-02-27 Receiptcity.Com, Inc. Modular signature and data-capture system and point of transaction payment and reward system
US5828875A (en) * 1997-05-29 1998-10-27 Telefonaktiebolaget Lm Ericsson Unroll of instructions in a micro-controller
US6097834A (en) * 1997-06-13 2000-08-01 Paystation America Inc. Financial transaction processing systems and methods
US5949044A (en) * 1997-06-13 1999-09-07 Walker Asset Management Limited Partnership Method and apparatus for funds and credit line transfers
US5910988A (en) * 1997-08-27 1999-06-08 Csp Holdings, Inc. Remote image capture with centralized processing and storage
US6032137A (en) * 1997-08-27 2000-02-29 Csp Holdings, Llc Remote image capture with centralized processing and storage
US6030000A (en) * 1997-09-12 2000-02-29 Diamond Security, Inc. Negotiable document having enhanced security for deterring fraud by use of a thermochromatic fingerprint image
US6367693B1 (en) * 1997-10-02 2002-04-09 John C. Novogrod System and method for requesting and dispensing negotiable instruments
US5987426A (en) * 1997-10-14 1999-11-16 Ncr Corporation Point-of-sale system including isolation layer between client and server software
US6106020A (en) * 1997-10-28 2000-08-22 Kerning Data Systems, Inc. Fraud prevention method and system
US6119106A (en) * 1997-11-26 2000-09-12 Mersky; Randy Method and apparatus for facilitating customer payments to creditors from a remote site
US6308887B1 (en) * 1997-12-02 2001-10-30 Cash Technologies, Inc. Multi-transactional architecture
US6305604B1 (en) * 1998-03-26 2001-10-23 Seiko Epson Corporation Printing apparatus, reading apparatus, and processing system for checks
US6064990A (en) * 1998-03-31 2000-05-16 International Business Machines Corporation System for electronic notification of account activity
US6360254B1 (en) * 1998-09-15 2002-03-19 Amazon.Com Holdings, Inc. System and method for providing secure URL-based access to private resources
US6175823B1 (en) * 1998-09-15 2001-01-16 Amazon.Com, Inc. Electronic gift certificate system
US6058417A (en) * 1998-10-23 2000-05-02 Ebay Inc. Information presentation and management in an online trading environment
US6327570B1 (en) * 1998-11-06 2001-12-04 Dian Stevens Personal business service system and method
US6484936B1 (en) * 1998-11-11 2002-11-26 Ncr Corporation Terminal
US6327575B1 (en) * 1999-04-26 2001-12-04 Ronald Craig Katz Point of sale terminal for the visually impaired
US20020153414A1 (en) * 1999-08-09 2002-10-24 First Data Corporation Systems and methods for performing transactions at a point-of-sale
US6547132B1 (en) * 1999-08-09 2003-04-15 First Data Corporation Point of sale payment terminal
US6827260B2 (en) * 1999-08-09 2004-12-07 First Data Corporation Systems and methods for utilizing a point-of-sale system
US6886742B2 (en) * 1999-08-09 2005-05-03 First Data Corporation Systems and methods for deploying a point-of sale device
US7086584B2 (en) * 1999-08-09 2006-08-08 First Data Corporation Systems and methods for configuring a point-of-sale system
US20010051876A1 (en) * 2000-04-03 2001-12-13 Seigel Ronald E. System and method for personalizing, customizing and distributing geographically distinctive products and travel information over the internet
US20010049651A1 (en) * 2000-04-28 2001-12-06 Selleck Mark N. Global trading system and method
US20030097321A1 (en) * 2000-11-22 2003-05-22 Masakazu Arikawa Method and system for concentratedly managing funds among enterprises
US20030197060A1 (en) * 2001-12-06 2003-10-23 Vince Coyner Consumer-focused gallon-based prepaid gasoline card, system and method for a car drivers
US20040098326A1 (en) * 2002-11-01 2004-05-20 First Data Corporation Stored value currency conversion systems and methods

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090048935A1 (en) * 2007-08-16 2009-02-19 Microsoft Corporation Application program interface to manage gift cards and check authorizations
US20150278788A1 (en) * 2014-03-28 2015-10-01 Kapsch Trafficcom Ag Eletronic commerce transaction system using electronic toll collection transponders
CN107077673A (en) * 2014-07-11 2017-08-18 谷歌公司 Exempt from transaction manually using inquiry request
US11263610B2 (en) * 2015-04-14 2022-03-01 Amy SZETO Processing of unit-based transactions
US20190106317A1 (en) * 2016-06-20 2019-04-11 Visa International Service Association Efficient resource provider system
US11697581B2 (en) * 2016-06-20 2023-07-11 Visa International Service Association Efficient resource provider system
US20190228480A1 (en) * 2018-01-24 2019-07-25 Maverik, Inc Generating receipts at remote fuel dispensers
US11270285B2 (en) * 2019-05-17 2022-03-08 Z Energy Limited Fuel pre-purchasing and sharing system and associated methods
WO2021133536A1 (en) * 2019-12-23 2021-07-01 Futures Partners LLC Systems and methods for commodity exchanges
CN113450105A (en) * 2020-03-27 2021-09-28 丰田自动车株式会社 Recording medium storing settlement program, settlement system, and server
CN113129088A (en) * 2021-03-31 2021-07-16 郭军 Payment terminal financial bill big data management method and system

Also Published As

Publication number Publication date
WO2008157502A1 (en) 2008-12-24
CA2691076A1 (en) 2008-12-24
US7813982B2 (en) 2010-10-12

Similar Documents

Publication Publication Date Title
US7783539B2 (en) Derivative currency-exchange transactions
US7813982B2 (en) Unit-based prepaid presentation instrument accounts and methods
US20180365744A1 (en) Consumer operated kiosks for purchasing items online and associated systems and methods
US7828206B2 (en) System and method for exchanging loyalty points for acquisitions
US7280984B2 (en) Money card system, method and apparatus
US7891561B2 (en) Cash redemption of gift cards systems and methods
US6805289B2 (en) Prepaid card payment system and method for electronic commerce
US7328844B2 (en) Point-of-transaction machine with improved versatility and related method
US8200575B2 (en) Secure electronic payment system and methods
US8032452B2 (en) Multiple-entity transaction systems and methods
US20080275820A1 (en) Apparatus and method for providing account security
US20040185830A1 (en) Apparatus and method for providing account security
US8296235B2 (en) System and method for cashback funding
US20020072942A1 (en) System and method for push-model fund transfers
KR20190041539A (en) A system for payment via electronic wallet
JP2001514402A (en) Multi-function card system
KR100542386B1 (en) System and method for managing a payment relation between the enterprises
US20060036530A1 (en) Method and apparatus for facilitating micro energy derivatives transactions on a network system
US7472092B2 (en) Money order device with identity verification and method
US20110320292A1 (en) Systems and methods for obtaining debit card customer approval of overdraft fees
US20060100959A1 (en) Methods and systems for implementing derivative transactions
WO2001037228A1 (en) Anonymous debit account system and method
WO2007029123A2 (en) System and method for processing transactions

Legal Events

Date Code Title Description
AS Assignment

Owner name: FIRST DATA CORPORATION, COLORADO

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HOLME, GARY;MARTIN, WAYNE JOSEPH;SIGNING DATES FROM 20070626 TO 20070830;REEL/FRAME:019946/0366

AS Assignment

Owner name: CREDIT SUISSE, CAYMAN ISLANDS BRANCH, AS COLLATERA

Free format text: SECURITY AGREEMENT;ASSIGNORS:FIRST DATA CORPORATION;CARDSERVICE INTERNATIONAL, INC.;FUNDSXPRESS, INC.;AND OTHERS;REEL/FRAME:020045/0165

Effective date: 20071019

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT, NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNORS:DW HOLDINGS, INC.;FIRST DATA RESOURCES, INC. (K/N/A FIRST DATA RESOURCES, LLC);FUNDSXPRESS FINANCIAL NETWORKS, INC.;AND OTHERS;REEL/FRAME:025368/0183

Effective date: 20100820

Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATE

Free format text: SECURITY AGREEMENT;ASSIGNORS:DW HOLDINGS, INC.;FIRST DATA RESOURCES, INC. (K/N/A FIRST DATA RESOURCES, LLC);FUNDSXPRESS FINANCIAL NETWORKS, INC.;AND OTHERS;REEL/FRAME:025368/0183

Effective date: 20100820

AS Assignment

Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATERAL AGENT, NEW YORK

Free format text: SECURITY AGREEMENT;ASSIGNORS:DW HOLDINGS, INC.;FIRST DATA RESOURCES, LLC;FUNDSXPRESS FINANCIAL NETWORKS, INC.;AND OTHERS;REEL/FRAME:025719/0590

Effective date: 20101217

Owner name: WELLS FARGO BANK, NATIONAL ASSOCIATION, AS COLLATE

Free format text: SECURITY AGREEMENT;ASSIGNORS:DW HOLDINGS, INC.;FIRST DATA RESOURCES, LLC;FUNDSXPRESS FINANCIAL NETWORKS, INC.;AND OTHERS;REEL/FRAME:025719/0590

Effective date: 20101217

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552)

Year of fee payment: 8

AS Assignment

Owner name: TELECHECK SERVICES, INC., TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: TASQ TECHNOLOGY, INC., CALIFORNIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: FUNDSXPRESS, INC., TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: FIRST DATA CORPORATION, COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: LINKPOINT INTERNATIONAL, INC., CALIFORNIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: FIRST DATA RESOURCES, LLC, COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: TELECHECK INTERNATIONAL, INC., TEXAS

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: DW HOLDINGS INC., COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: INTELLIGENT RESULTS, INC., COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: SIZE TECHNOLOGIES, INC., COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

Owner name: CARDSERVICE INTERNATIONAL, INC., CALIFORNIA

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919

Effective date: 20190729

AS Assignment

Owner name: FIRST DATA RESOURCES, INC. (K/N/A FIRST DATA RESOU

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: TELECHECK INTERNATIONAL, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: FIRST DATA CORPORATION, NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: LINKPOINT INTERNATIONAL, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: TASQ TECHNOLOGY, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: INTELLIGENT RESULTS, INC. (K/N/A FIRST DATA SOLUTI

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: DW HOLDINGS, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: FUNDSXPRESS FINANCIAL NETWORKS, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: SIZE TECHNOLOGIES, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: MONEY NETWORK FINANCIAL, LLC, NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: DW HOLDINGS, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050091/0474

Effective date: 20190729

Owner name: FIRST DATA SOLUTIONS, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050091/0474

Effective date: 20190729

Owner name: FIRST DATA RESOURCES, LLC, NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050091/0474

Effective date: 20190729

Owner name: TASQ TECHNOLOGY, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050091/0474

Effective date: 20190729

Owner name: FIRST DATA CORPORATION, NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050091/0474

Effective date: 20190729

Owner name: FUNDSXPRESS FINANCIAL NETWORK, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050091/0474

Effective date: 20190729

Owner name: LINKPOINT INTERNATIONAL, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050091/0474

Effective date: 20190729

Owner name: TELECHECK INTERNATIONAL, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050091/0474

Effective date: 20190729

Owner name: SIZE TECHNOLOGIES, INC., NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050091/0474

Effective date: 20190729

Owner name: MONEY NETWORK FINANCIAL, LLC, NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050091/0474

Effective date: 20190729

Owner name: FIRST DATA CORPORATION, NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050094/0455

Effective date: 20190729

Owner name: FIRST DATA RESOURCES, INC. (K/N/A FIRST DATA RESOURCES, LLC), NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

Owner name: INTELLIGENT RESULTS, INC. (K/N/A FIRST DATA SOLUTIONS, INC.), NEW YORK

Free format text: TERMINATION AND RELEASE OF SECURITY INTEREST IN PATENT RIGHTS;ASSIGNOR:WELLS FARGO BANK, NATIONAL ASSOCIATION;REEL/FRAME:050090/0060

Effective date: 20190729

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20221012