Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20050279827 A1
Publication typeApplication
Application numberUS 11/105,167
Publication dateDec 22, 2005
Filing dateApr 12, 2005
Priority dateApr 28, 2004
Also published asCA2563722A1, EP1747522A2, EP1747522A4, US7967195, US20080052235, WO2005109307A2, WO2005109307A3
Publication number105167, 11105167, US 2005/0279827 A1, US 2005/279827 A1, US 20050279827 A1, US 20050279827A1, US 2005279827 A1, US 2005279827A1, US-A1-20050279827, US-A1-2005279827, US2005/0279827A1, US2005/279827A1, US20050279827 A1, US20050279827A1, US2005279827 A1, US2005279827A1
InventorsJohn Mascavage, Margaret Weichert, Robert Hogan
Original AssigneeFirst Data Corporation
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Methods and systems for providing guaranteed merchant transactions
US 20050279827 A1
Abstract
A network arrangement is provided for processing credit transactions. A financial network is used to route communications securely between interfaces with the financial network. Merchant systems are coupled with the interfaces, with each merchant system transmitting requests for authorization of credit transactions through the financial network. An issuer system authorizes credit transactions in response to receipt of requests that specify at least a credit account to be used to support a particular credit transaction and a transaction amount for the particular credit transaction. A guarantor system separate from the issuer system determines whether to guarantee credit transactions in response to the requests and transmits responses indicating whether specific credit transactions are to be guaranteed through the financial network to the merchant systems.
Images(6)
Previous page
Next page
Claims(15)
1. A method for processing a credit transaction by a merchant, the method comprising:
receiving, with a merchant system, information defining a credit account to be used to support the credit transaction;
transmitting, with the merchant system over a financial network, a request for authorization of the credit transaction, the request including the information defining the credit account and a transaction amount for the transaction; and
receiving, with the merchant system over the financial network, a response to the request identifying whether an issuer of the credit account has authorized the credit transaction and whether a guarantor separate from the issuer has guaranteed payment of the transaction amount for the transaction to the merchant.
2. The method recited in claim 1 wherein receiving the response comprises receiving the response from a guarantor system controlled by the guarantor.
3. The method recited in claim 1 wherein receiving the response comprises receiving a first portion of the response from an issuer system controlled by the issuer and receiving a second portion of the response from a guarantor system controlled by the guarantor.
4. The method recited in claim 1 wherein receiving the information defining the credit account comprises reading the information from a credit card presented to the merchant.
5. The method recited in claim 1 wherein receiving the information defining the credit account comprises receiving the information over an interface to the merchant system from a customer located remotely from the merchant.
6. The method recited in claim 1 wherein transmitting the request comprises transmitting the request from the merchant system to an issuer system controlled by the issuer.
7. A method for processing a credit transaction by a merchant, the method comprising:
receiving, with a guarantor system, a request for authorization of a credit transaction between the merchant and a customer, the request including an identification of a credit account used to support the credit transaction, a transaction amount for the transaction, and an authorization for the transaction provided by an issuer of the credit account;
determining, with the guarantor system, whether to provide a guarantee of payment of the transaction amount to the merchant; and
transmitting, from the guarantor system over a financial network, a response to the request indicating whether to guarantee payment of the transaction amount to the merchant.
8. The method recited in claim 7 wherein determining whether to provide the guarantee comprises determining a risk of repudiation of the transaction by a holder of the credit account.
9. The method recited in claim 7 wherein receiving the request for authorization comprises receiving the request for authorization over the financial network from an issuer system controlled by the issuer.
10. The method recited in claim 7 wherein receiving the request for authorization comprises receiving the request for authorization over the financial network from a merchant system controlled by the merchant.
11. A network arrangement for processing credit transactions between merchants and customers, the network arrangement comprising:
a financial network adapted to route communications securely between interfaces with the financial network;
a plurality of merchant systems coupled with the interfaces, each such merchant system being adapted to transmit requests for authorization of credit transactions through the financial network;
an issuer system coupled with at least one of the interfaces, the issuer system being adapted to authorize credit transactions in response to receipt of requests specifying at least a credit account to be used to support a particular credit transaction and a transaction amount for the particular credit transactions; and
a guarantor system separate from the issuer system and coupled with at least one of the interfaces, the guarantor system being adapted to determine whether to guarantee credit transactions for merchants in response to the requests for authorization of credit transactions and to transmit responses indicating whether specific credit transactions are to be guaranteed through the financial network to the merchant systems.
12. The network arrangement recited in claim 11 wherein each such merchant system is adapted to transmit the requests for authorization through the financial network to the issuer system.
13. The network arrangement recited in claim 11 further comprising a merchant-bank system coupled with at least one of the interfaces, the merchant-bank system being controlled by a financial institution that holds a depository account on behalf of a merchant that controls at least one of the merchant systems.
14. The network arrangement recited in claim 11 wherein at least one the merchant systems is interfaced with a point-of-sale device adapted to read information defining the credit account from a credit card.
15. The network arrangement recited in claim 11 wherein at least one of the merchant systems is interfaced with a public network through which a customer may provide information defining the credit account.
Description
    CROSS REFERENCE TO RELATED APPLICATION
  • [0001]
    This application is a nonprovisional of, and claims the benefit of the filing date of, U.S. Provisional Patent Appl. No. 60/566,486, entitled “METHODS AND SYSTEMS FOR PROVIDING GUARANTEED MERCHANT TRANSACTIONS,” filed Apr. 28, 2004 by John Joseph Mascavage et al., the entire disclosure of which is incorporated herein by reference for all purposes.
  • BACKGROUND OF THE INVENTION
  • [0002]
    This application relates generally to merchant transactions. More specifically, this application relates to methods and systems for providing guaranteed merchant transactions.
  • [0003]
    Currently, about 31% of all purchases in the United States are made using payment cards, such as credit, debit, and stored value cards, with the remaining purchases being made in cash (about 38%) and by check (about 27%). Although it is not always evident to many consumers, there is a significant difference in different types of transaction types, in that some transactions are “guaranteed” to the merchant while others are not. As used herein, a “guaranteed” transaction is one in which a merchant is a party to the transaction and in which the risk of loss resulting from successful repudiation is borne by someone other than the merchant party. The most obvious guaranteed transactions are thus those made in cash, where the merchant receives the funds at the time of the purchase directly. Check-based transactions may also be guaranteed transactions when supported by services such as TeleCheck™. With respect to card-based transactions, debit transactions made using a debit card are generally guaranteed transactions because part of the transaction includes a transfer of funds from a customer's account to the merchant's account at the time of the transaction.
  • [0004]
    Credit-card transactions are the prime example of transactions that are not guaranteed. Such transactions typically proceed by having a customer present a credit card, with a receipt of the transaction being presented later by the merchant to a financial institution for payment. Settlement of the transaction involves an issuer of the credit card making the payment and extending credit to the customer, eventually recovering payment for the transaction, and perhaps also a finance charge, from the customer in accordance with a cardholder agreement. Until payment is made to the merchant, however, there remains the possibility that the legitimacy of the transaction may be repudiated, such as by an allegation that the credit card had been stolen, was forged, and the like. The lack of a guarantee thus puts the risk of being defrauded onto the merchant.
  • [0005]
    The protocol for executing transactions sometimes includes safeguards intended to reduce the chance of fraud, but such safeguards are of limited effectiveness. For example, a merchant may seek preauthorization for a transaction by using a network infrastructure to transmit some details of the transaction, such as the credit-card number and a transaction amount, to the issuer. Preauthorization may include verifying that the card number is a valid card number, verifying that the credit account identified by the card number has an open status, and verifying that the credit account has on “open to buy” status on the credit limit. In some instances, such as were an address is provided as part of an address-verification service (“AVS”), the preauthorization may additionally include verifying that the billing address for the credit account matches the address on file for the account holder. Similarly, for certain transactions such as non-face-to-face transactions, a card validation value (“CVV”), often printed on the back of the credit card, may be provided and verified, providing some additional measure of validation that the purchaser is in possession of the card.
  • [0006]
    Thus, if the transaction amount is less than the available credit on the account and the card has no derogatory marks indicating its theft and the like, the transaction may be authorized. Such authorization does not necessarily protect the merchant, however, from presentment of a stolen credit card whose theft has not been reported, or from a variety of other fraud schemes. Legitimate bases may be asserted by the true cardholder to establish that the use of the card was fraudulent, with the risk of such an assertion for every transaction being borne by the merchant. For this reason, some merchants may refuse to accept credit cards or may institute procedures to encourage the use of debit cards over credit cards, but such activities sometimes have the effect of discouraging consumers from purchasing at all from those merchants.
  • [0007]
    In recent years, dangers of fraud perpetrated on merchants have received even more attention because of the evolution of electronic commerce on the Internet, the increase in mail-order and telephone-order transactions, and the like. Such transactions are examples of transactions where the credit card itself is not even presented, and in this way are similar to more traditional telephone and mail-order purchases. A typical electronic transaction proceeds similarly to the transaction described above, but the credit-account number is provided by the customer rather than being extracted directly from the card. Confirmatory information, such as cardholder name, expiry date, and/or identification of a security code printed on the back of the credit card, may sometimes also be collected to try to limit transactions to being executed by the cardholder in possession of the card. A somewhat more sophisticated version of the security-code method has recently been proposed by allowing cardholders to register their cards with a secret password that is not printed on the card. With such a system, registered credit accounts may only be used when the secret password is also provided at the time of transaction. One such method is currently being promoted under the name “Verified by Visa.” While such techniques have the potential of adding greater security to online transactions, they require special registration by the customer and the maintenance of the secret password. In addition, the “Verified by Visa” method currently covers only a small set of chargeback reason codes (two codes), leaving a large number of other potential chargeback codes unaddressed.
  • [0008]
    There accordingly remains a general need in the art for methods and systems that provide convenient guaranteed transactions to merchants for credit transactions.
  • BRIEF SUMMARY OF THE INVENTION
  • [0009]
    Embodiments of the invention thus provide a network arrangement that may be used for processing credit transactions. A financial network is used to route communications securely between interfaces with the financial network. A plurality of merchant systems are coupled with the interfaces, with each such merchant system being adapted to transmit requests for authorization of credit transactions through the financial network. An issuer system is coupled with at least one of the interfaces, and is adapted to authorize credit transactions in response to receipt of requests that specify at least a credit account to be used to support a particular credit transaction and a transaction amount for the particular credit transaction. A guarantor system separate from the issuer system is also coupled with at least one of the interfaces. The guarantor system is adapted to determine whether to guarantee credit transactions in response to the requests for authorization of credit transactions and to transmit responses indicating whether specific credit transactions are to be guaranteed through the financial network to the merchant systems.
  • [0010]
    In some embodiments, each merchant system may be adapted to transmit the requests for authorization through the financial network to the issuer system. In other embodiments, the network arrangement further comprises a merchant-bank system coupled with at least one of the interfaces; the merchant-bank system is controlled by a financial institution that holds a depository account on behalf of a merchant that controls at least one of the merchant systems. The merchant systems may be interfaced with point-of-sale devices adapted to read information defining the credit account from a credit card. Alternatively, the merchant systems may be interfaced with a public network through which a customer may provide information defining the credit account.
  • [0011]
    The network arrangement may be used in methods for processing a credit transaction by a merchant. In one set of embodiments, information defining a credit account to be used to support the credit transaction is received with a merchant system. A request for authorization of the credit transaction is transmitted with the merchant system over a financial network; the request includes the information defining the credit account and a transaction amount for the transaction. A response to the request is received with the merchant system over the financial network. The response identifies whether an issuer of the credit account has authorized the credit transaction and whether a guarantor separate from the issuer has guaranteed payment of the transaction amount for the transaction to the merchant.
  • [0012]
    In some such embodiments, the response may be received from a guarantor system controlled by the guarantor. In other embodiments, a first portion of the response may be received from an issuer system controlled by the issuer and a second portion of the response may be received from a guarantor system controlled by the guarantor. The information defining the credit account may be read from a credit card presented to the merchant or may be received over an interface to the merchant system from a customer located remotely from the merchant in different embodiments. In one embodiment, the request for authorization of the credit transaction is transmitted from the merchant system to an issuer system controlled by the issuer.
  • [0013]
    In another set of embodiments, a request for authorization of a credit transaction between the merchant and a customer is received with a guarantor system. The request includes an identification of a credit account used to support the credit transaction, a transaction amount for the transaction, and an authorization for the transaction provided by an issuer of the credit account. A determination is made with the guarantor system whether to provide a guarantee of payment of the transaction amount to the merchant. A response to the request is transmitted from the guarantor system over a financial network indicating whether to guarantee payment of the transaction amount to the merchant.
  • [0014]
    In some such embodiments, the determination of whether to provide the guarantee is made by determining a risk of repudiation of the transaction by a holder of the credit account. The request for authorization may be received over the financial network from an issuer system controlled by the issuer or from a merchant system controlled by the merchant in different embodiments.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0015]
    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.
  • [0016]
    FIG. 1 is a schematic diagram of a network arrangement that may be used in some embodiments of the invention;
  • [0017]
    FIG. 2 is a schematic diagram illustrating a logical structure of a guarantor system that may be used in executing and settling guaranteed credit transactions in some embodiments;
  • [0018]
    FIG. 3 is a schematic illustration of a physical structure of a guarantor system that may be used in executing and settling guaranteed credit transactions in some embodiments;
  • [0019]
    FIG. 4 is a flow diagram providing exemplary illustrations of methods for executing a guaranteed credit transaction in some embodiments; and
  • [0020]
    FIG. 5 is a flow diagram providing exemplary illustrations of methods for settling a guaranteed credit transaction in some embodiments.
  • DETAILED DESCRIPTION OF THE INVENTION
  • [0021]
    Embodiments of the invention provide methods and systems for providing guaranteed credit transactions, where the “guaranteed” nature of each transaction means that the risk of a valid repudiation of the transaction is borne by a party other than a merchant party to the transaction. This is achieved in embodiments of the invention by integrating a guarantor system within a network suitable for processing credit transactions with merchants. The guarantor system is equipped with modules that permit enhanced authorization techniques to be applied with a variety of risk filters so that the guarantor can determine whether to provide the guarantee. In exchange for the guarantee, the guarantor usually receives a small fee from the merchant, effectively providing a cost-based insurance to the merchant. The guarantor system may also be equipped with modules that improve adjudication of repudiations of transactions before payment is made on the guarantee.
  • [0022]
    One example of a network arrangement in which a guarantor system has been integrated in accordance with embodiments of the invention is shown with the schematic diagram of FIG. 1. In this arrangement 100, a plurality of merchant systems 116 are provided in communication with a financial network 112. Usually the financial network is a private network having a variety of security protocols intended to protect the sensitive financial information being exchanged from interception by eavesdroppers. In many instances, for example, communications with the financial network 112 are encrypted. Each of the merchant systems 116 is generally also provided in communication with one or more transaction interfaces. In the case of brick-and-mortar transactions executed when a customer is physically present at a merchant location, the transaction interface may comprise a point-of-sale device 120 equipped to read information from a magnetic stripe of a card, to read information from a chip on a smart card, to read information optically from a card, and the like. Examples of point-of-sale devices that include multiple functionality are described in the following commonly assigned applications, the entire disclosures of which are incorporated herein by reference for all purposes: U.S. Prov. Pat. Appl. No. 60/147,889, entitled “INTEGRATED POINT OF SALE DEVICE,” filed Aug. 9, 1999 by Randy J. Templeton et al.; U.S. Patent Application Ser. No. 09/634,901, entitled “POINT OF SALE PAYMENT SYSTEM,” filed Aug. 9, 2000 by Randy J. Templeton et al.; U.S. Patent Application Ser. No. 10/116,689, entitled “SYSTEMS AND METHODS FOR PERFORMING TRANSACTIONS AT A POINT-OF-SALE,” filed Apr. 3, 2002 by Earney Stoutenburg et al.; U.S. Patent Application Ser. No. 10/116,733, entitled “SYSTEMS AND METHODS FOR DEPLOYING A POINT-OF-SALE SYSTEM,” filed Apr. 3, 2002 by Earney Stoutenburg et al.; U.S. Patent Application Ser. No. 10/116,686, entitled “SYSTEMS AND METHODS FOR UTILIZING A POINT-OF-SALE SYSTEM,” filed Apr. 3, 2002 by Earney Stoutenburg et al.; and U.S. Patent Application Ser. No. 10/116,735, entitled “SYSTEMS AND METHODS FOR CONFIGURING A POINT-OF-SALE SYSTEM,” filed Apr. 3, 2002 by Earney Stoutenburg. In cases where the customer is not physically present, such as where a transaction is executed over a public network 124 like the Internet, the public network 124 itself may correspond to the transaction interface. Other examples of transaction interfaces that may be used when the customer is not physically present include telephone interfaces used to support telephone orders, and the like.
  • [0023]
    FIG. 1 provides examples of different types of merchants who may be equipped to accommodate different types of transactions. For instance, the merchant having merchant system 116-n is equipped only to accommodate brick-and-mortar transactions with a customer 128-3 through a point-of-sale transaction device 120. Transactions executed by such a merchant are thus restricted to “card-present transactions,” in which the credit card is physically present for examination during the transaction itself. In contrast, the merchant having merchant system 116-2 is a purely online Internet retailer and is equipped only to accommodate transactions executed over the public network 124. In such transactions, a customer 128-2 provides only information about the credit card without the card actually being present to execute a so-called “card-not-present transaction.” Some merchant systems, such as merchant system 116-1 may be equipped to interface with different types of transaction interfaces, such as with the public network 124 and with point-of-sale devices 120. Such merchant systems may accommodate a customer 128-1 who executes a card-present transaction at a merchant location, as well as a customer 128-2 who executes a card-not-present transaction over the Internet or telephone.
  • [0024]
    The financial network 112 is also interfaced with financial-institution systems 104 operated by financial institutions. Such financial institutions may act as depository institutions that provide services to one or more of the merchants and/or may act as issuers of credit cards to customers 128. To facilitate the discussion below, a specific embodiment is indicated in FIG. 1 in which financial-institution system 104-2 is operated by a merchant bank that provides services to one of the merchants, and in which financial-institution 104-1 is operated by a credit-card issuer that provides a credit account for one of the customers 128. Of course, both those institutions may act in other capacities as well, with the merchant bank also acting as an issuer to some customers and with the issuer acting as a merchant bank for other customers.
  • [0025]
    The guarantor system 108 is integrated into this network arrangement through an interface with the financial network 112, allowing it to exchange communications both with the merchant systems 116 and with the financial-institution systems 104. The guarantor system 108 may comprise a computational system having programming to implement methods for guaranteeing transactions and for settling guaranteed transactions. Such a computational system is described for certain embodiments with reference to FIGS. 2 and 3, which respectively show logical and physical structures that may be used in some embodiments.
  • [0026]
    For instance, FIG. 2 illustrates that the guarantor system 108 may comprise a plurality of logical modules for implementing methods of the invention. The modules on the left side of the drawing generally correspond to those modules that may be used in coordinating execution of guaranteed transaction, while the modules on the right side of the drawing generally correspond to those modules used in settling a previously guaranteed transaction.
  • [0027]
    In coordinating execution of a guaranteed transaction, information about the transaction may be received by a transaction-receipt module 212 over a first input interface 204. The information is parsed by a transaction-parsing module 216 so that the parsed information may be analyzed for risk factors by a risk-evaluation module 220. The risk-evaluation module may comprise one or more risk filters used in evaluating the risk of repudiation of a transaction. For example, a demographic filter 220 may apply demographic factors like age, occupation, income level, geographic location, and the like that are known to be correlated with relatively high or low levels of repudiation. Similarly, a transaction filter 228 may identify certain aspects of the transaction that are known to be correlated with relatively high or low levels of repudiation, such as the transaction amount, the nature of the product purchased, the type of merchant selling the product, the frequency of the transaction, the time of day of the transaction, hardware- and software-related parameters such as fingerprinting-type information captured by certain scanners, and the like. Of each of the factors may be used in the computation of a risk score, with those aspects correlated with high levels of repudiation tending to increase the score and those with aspects correlated with low levels of repudiation tending to decrease the score. Different aspects may be weighted in different ways by the risk-evaluation module, and the weighting factors may even vary on a transaction-by-transaction basis. For example, a transaction by Customer X known to have a history of repudiating transactions may weight those factors tending to decrease the risk score more heavily than for a transaction by Customer Y known rarely to repudiate a transaction. The application of the various filters may draw on information stored in a data store 236, that may record such information as the correlation levels with identified demographic, transactional, and other factors, a credit score or transaction history for individual customers, and the like.
  • [0028]
    Once the risk-evaluation module has generated a risk score for a particular transaction, a guarantee module 232 determines whether the transaction qualifies for a guarantee by the guarantor. In some instances, such a determination may be made simply on the basis of the risk score alone, while in other embodiments other factors may also be applied. The determination of the guarantee module 232 is routed as a response from the guarantor system 108 by a routing module 246 over output interface 250.
  • [0029]
    Similarly, as part of a method for settling a guaranteed transaction, a repudiation-receipt module 240 may receive information over a second input interface 208 that a particular guaranteed transaction has been repudiated by the cardholder. Generally, this information includes details of the transaction and reasons for the repudiation, and perhaps also detailed results of an investigation performed by an issuer suggesting that the repudiation is valid. An adjudication module 242 coordinates activity for determining whether the guarantor is obliged to pay the merchant for the repudiated transaction. In doing so, the adjudication module may access information from the data store 236. In some instances the adjudication may rely completely on the information received by the repudiation-receipt module 240, such as by honoring a conclusion of an issuer that the transaction was legitimately repudiated. In other instances, an independent adjudication may be initiated by the adjudication module 242 by issuing directions for collection of additional information, to verify an identity of the party to the transaction, address, and other factors known to be correlated with a fraud technique. Results of such investigations are received by the adjudication module 242, which determines the legitimacy of the repudiation and maintains records sufficient to establish the basis for its determination; maintaining such records is especially desired in circumstances where the repudiation is determined to be invalid so that the guarantor will refuse to pay. The determination is provided to the routing module 246 for transmission to appropriate parties as described below.
  • [0030]
    FIG. 3 provides a schematic illustration of a physical structure that may be used to implement the guarantor system 108. FIG. 3 broadly illustrates how individual system elements may be implemented in a separated or more integrated manner. The guarantor system 108 is shown comprised of hardware elements that are electrically coupled via bus 326, including a processor 302, an input device 304, an output device 306, the data store 236, 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 over input interfaces 204 and 208 and over output interface 250 to implement embodiments described herein.
  • [0031]
    The guarantor system 108 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.
  • [0032]
    FIGS. 4 and 5 provide flow diagrams that respectively illustrate methods for executing a guaranteed transaction and methods for settling a guaranteed transaction using the network arrangement 100 described in connection with FIGS. 1-3. As FIG. 4 illustrates, methods of the invention may accommodate both card-present transactions and card-not-present transactions. In the case of a card-present transaction, a customer may select items, including goods and/or services, for purchase at a merchant location at block 404. The customer presents his credit card for reading by the point-of-sale device, which extracts an account number and perhaps other identification from a magnetic stripe, embedded chip, or other storage medium at block 408. A package having transaction information is prepared, including such information as the account number and identification extracted from the credit card, a transaction amount, a listing of items purchased, and the like. The transaction package is transmitted by a merchant system 116 interfaced with the point-of-sale device over the financial network 112 to the merchant-bank system 104-2. Alternatively, in the case of a card-not-present transaction, a customer may select items for purchase from an online Internet shopping site at block 412. The customer communicates identification information printed on the credit card, such as the credit-card number, his name, and the expiration date, at block 416 over an interface connected with a merchant system 116. In the case of an online purchase, the interface may comprise the Internet and in the alternative case of a catalog purchase, the interface may comprise a telephone interface. At block 420, transaction information is prepared in the same fashion as for a card-present transaction, i.e. by preparing a packet having such information as account number, transaction amount, items purchased, and the like, and transmitted over the financial network 112 to the merchant-bank system 104-2.
  • [0033]
    For both card-present and card-not-present transactions, the merchant-bank system 104-2 identifies the issuer from the received information and routes it or a subset of it to the appropriate issuer system 104-1 over the financial network 112 at block 424. The information thus provided to the issuer system 104-3 permits the issuer system 104-1 to determine at block 428 whether to authorize the transaction in accordance with a cardholder agreement between the issuer and cardholder. Such a decision typically turns on such factors as whether the transaction amount is less than an available credit amount and whether the credit account is free of derogatory marks that indicate such things as delinquency on the part of the cardholder, unusual levels of activity on the account (particularly in unusual geographic locations) suggesting fraudulent activity, and the like. If the transaction is denied by the issuer, a denial code is routed by the issuer system 104-1 through the financial network 112 to the merchant system 116 that originated the transaction at block 432. Normally, the merchant will decline the credit transaction upon receipt of a denial code or will allow the customer to provide an alternative method of payment for the selected items.
  • [0034]
    If the issuer authorizes the transaction, the transaction information may be routed through the financial network 112 to the guarantor system 108 at block 436, together with an approval code generated by the issuer system 104-1. Using the methods described above, the guarantor system 108 evaluates risk factors at block 440 to determine whether the transaction is one that meets criteria for providing a guarantee. In some instances, the cost for providing a guarantee of the transaction may vary according to the determined risk level, so that the possibility of obtaining a guarantee is still provided to the merchant, but at a cost that reflects the increased risk. The guarantor system 108 transmits the transaction authorization together with its guarantee decision to the merchant system 116 that originated the transaction request at block 444. If the transaction is guaranteed under conditions acceptable to the merchant, as checked at block 448, the merchant executes the transaction at block 452. If the guarantor is unwilling to guarantee the transaction, or if the guarantee is offered under conditions unacceptable to the merchant, the merchant may still have the option of accepting the risk of loss at block 456 using internal decision-making criteria. Since the transaction has been authorized by the issuer despite the lack of guarantee, a decision by the merchant to execute the transaction and accept the risk is similar to execution of a traditional authorized credit transaction. In many instances, however, the risk evaluation performed by the guarantor system 108 will be recognized by the merchant to be a reliable indicator of risk levels so that the merchant will decline to execute the transaction in the absence of a guarantee.
  • [0035]
    While FIG. 4 indicates one specific order for the routing of transaction information, it should be appreciated that other routings may be performed without exceeding the scope of the invention. For example, in some embodiments, the transaction information may not be routed to the merchant-bank system initially, being instead routed directly from the merchant system to the issuer system. In other embodiments, transaction information may be routed to the issuer system and guarantor system simultaneously, with a transaction being executed only if a positive response is received from both; such simultaneous routing may increase the speed of executing a transaction, but requires the risk-analysis techniques used by the guarantor system 108 to be applied even for transactions that are denied by the issuer system. Still other variations in the order of the functions included in FIG. 4 will be evident to those of skill in the art, as will be functions that may be omitted in some embodiments and supplementary functions that may be performed in some embodiments.
  • [0036]
    After a guaranteed transaction has been executed, it may be settled so that the appropriate parties pay and are paid for the transaction in accordance with the relevant agreements. FIG. 5 provides an overview of settlement functions in some embodiments, although, as for the methods described in connection with FIG. 4, various additional functions may be performed in some embodiments, various functions may be omitted in some embodiments, and various functions may be performed in a different order in some embodiments. Settlement of a particular transaction may begin at block 504 with the merchant depositing a receipt of the transaction with its financial institution, the merchant bark 104-2. At block 508, the merchant bank 104-2 transmits an electronic version of the transaction receipt to the issuer system 104-1 over the financial network 112. This electronic version might include an image reproduction of the transaction receipt or might be comprise descriptive text setting forth relevant particulars of the transaction receipt.
  • [0037]
    At block 512, the issuer system 104-1 posts the transaction to the cardholder's account and later transmits a credit-card statement to the cardholder at block 516 that includes the transaction, and usually several additional transactions executed within a defined period. Under most circumstances, all of the transactions set forth on the cardholder statement will be accepted by the cardholder as legitimate charges, as checked at block 520, so that the cardholder will provide payment towards the outstanding balance of the credit account by a specified due date at block 552. The issuer system 104-1 accordingly initiates transmission of the transaction amount to the merchant bank 104-2 at block 556, and the merchant bank 104-2 credits the merchant account at block 560. While transmission of funds to the merchant bank 104-2 and crediting of the merchant account are shown in FIG. 5 to occur after the cardholder has reviewed his statement, in many instances such crediting will occur much earlier in the process. When such crediting is performed earlier, a successful repudiation of the transaction by the cardholder may require a refund if the transaction was not guaranteed; it is thus particularly convenient to perform the crediting earlier for at least all guaranteed transactions, and even for some nonguaranteed transactions since most of those will not be repudiated in any event.
  • [0038]
    If the transaction is repudiated by the cardholder at block 520, usually by the cardholder informing the issuer that the transaction was not executed by the cardholder or authorized by the cardholder, the issuer will investigate the repudiation at block 524. Such an investigation may be performed at a relatively high level, checking such things as the account number on the transaction receipt, checking the signature on the transaction receipt, and the like, or may be performed at a more detailed level in some embodiments. If the investigation results in a determination that the repudiation is not valid, as checked at block 528, the issuer may demand payment from the cardholder at block 532, with the expectation that the cardholder will pay as described previously so that the merchant account may be properly credited. Continued failure of the cardholder to pay for the transaction may result in recovery actions against the cardholder in accordance with the cardholder agreement.
  • [0039]
    If the repudiation is valid, the ability for the merchant to recover the transaction amount depends on whether the transaction was guaranteed. If not, as checked at block 536, then the merchant has been defrauded as indicated at block 564. If the transaction was guaranteed, however, then responsibility for making the merchant whole rests with the guarantor. Accordingly, at block 540, the issuer system 104-1 transmits information to the guarantor system 108 over the financial network 112. This information may include the electronic version of the transaction receipt, details of the repudiation supplied by the cardholder, details of the investigation that was performed by the issuer and the results of that investigation, and the like. This information may then be used by the adjudication modules of the guarantor system 108 to perform an enhanced adjudication at block 544; some discussion of the nature of the enhanced adjudication was presented above in connection with FIG. 2. If the result of that enhanced adjudication confirms the conclusion that the repudiation was valid, as checked at block 548, then the transaction is one of those that the prior risk analysis failed to identify sufficiently well as likely to be repudiated. Accordingly, the guarantor system 108 initiates transmission of the transaction amount to the merchant bank at block 576 so that the merchant bank may credit the merchant account at block 580. Because of the guaranteed nature of the transaction, such transfer of funds is also performed by the guarantor system 108 when the repudiation is found not to be valid by the enhanced adjudication; in addition, however, the guarantor takes steps to recover payment from the cardholder at block 568, with the expectation that the cardholder will pay the guarantor the requisite amount at block 572 when presented with the evidence that the transaction was improperly repudiated.
  • [0040]
    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.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5334823 *Jan 10, 1992Aug 2, 1994National Bancard CorporationSystems and methods for operating data card terminals for transaction chargeback protection
US5428210 *Jan 10, 1992Jun 27, 1995National Bancard CorporationData card terminal with embossed character reader and signature capture
US5432326 *Jun 28, 1994Jul 11, 1995National Bancard CorporationSystems and methods for operating data card terminals for transaction chargeback protection
US5448047 *Jun 16, 1994Sep 5, 1995Microbilt CorporationCard validation method using multiple cord data regions
US5903882 *Dec 13, 1996May 11, 1999Certco, LlcReliance server for electronic transaction system
US5914472 *Sep 23, 1997Jun 22, 1999At&T CorpCredit card spending authorization control system
US6163771 *Aug 28, 1997Dec 19, 2000Walker Digital, LlcMethod and device for generating a single-use financial account number
US6254000 *Nov 13, 1998Jul 3, 2001First Data CorporationSystem and method for providing a card transaction authorization fraud warning
US6783065 *Mar 12, 2001Aug 31, 2004First Data CorporationPurchasing card transaction risk model
US6999943 *Mar 10, 2000Feb 14, 2006Doublecredit.Com, Inc.Routing methods and systems for increasing payment transaction volume and profitability
US7043441 *Mar 9, 2000May 9, 2006At&T Corp.Method and apparatus using digital credentials and other electronic certificates for electronic transactions
US7191151 *Aug 23, 2001Mar 13, 2007Paypal, Inc.Instant availability of electronically transferred funds
US20010034702 *Feb 5, 2001Oct 25, 2001Mockett Gregory P.System and method for dynamically issuing and processing transaction specific digital credit or debit cards
US20010034720 *Mar 7, 2001Oct 25, 2001David ArmesSystem for facilitating a transaction
US20020013765 *May 22, 2001Jan 31, 2002Gil ShwartzIntrinsic authorization for electronic transactions
US20020120582 *Mar 4, 2002Aug 29, 2002Stephen ElstonMethod for establishing an electronic commerce account
US20020123938 *Mar 1, 2001Sep 5, 2002Yu Philip S.Systems and methods to facilitate a transaction wherein a purchaser is associated with an approver
US20020139837 *Mar 12, 2001Oct 3, 2002Spitz Clayton P.Purchasing card transaction risk model
US20030046224 *Aug 30, 2001Mar 6, 2003Mujtaba M. ShahidMethod and apparatus for handling monetary transactions
US20030083986 *Oct 26, 2001May 1, 2003Toshiaki KobayashiMethod of credit guarantee in electronic commerce
US20030093367 *Nov 15, 2001May 15, 2003First Data CorporationOnline incremental payment method
US20030101134 *Nov 28, 2001May 29, 2003Liu James C.Method and system for trusted transaction approval
US20030126075 *Nov 14, 2002Jul 3, 2003First Data CorporationOnline funds transfer method
US20030172027 *Oct 31, 2002Sep 11, 2003Scott Walter G.Method for conducting a credit transaction using biometric information
US20030233292 *Jun 13, 2002Dec 18, 2003Visa U.S.A., Inc.Method and system for facilitating electronic dispute resolution
US20040030644 *Dec 14, 2001Feb 12, 2004Shaper Stephen J.Systems for facilitating card processing systems/improved risk control
US20040031856 *Jul 14, 2003Feb 19, 2004Alon AtsmonPhysical presence digital authentication system
US20040049455 *Jul 6, 2001Mar 11, 2004Hossein MohsenzadehSecure authentication and payment system
US20040064405 *Sep 30, 2002Apr 1, 2004First Data CorporationMethods and systems for processing partial payments using debit cards
US20040199462 *Apr 2, 2003Oct 7, 2004Ed StarrsFraud control method and system for network transactions
US20040230527 *Apr 26, 2004Nov 18, 2004First Data CorporationAuthentication for online money transfers
US20040260644 *Apr 23, 2004Dec 23, 2004Robert DoernerCredit authorization systems and methods
US20050131816 *Feb 3, 2005Jun 16, 2005Britto Mark J.Computer-based funds transfer system
US20050192901 *May 2, 2005Sep 1, 2005Mccoy Randal A.Credit card supported electronic payments
US20050234833 *Apr 16, 2004Oct 20, 2005First Data CorporationMethods and systems for online transaction processing
US20050278244 *Oct 4, 2004Dec 15, 2005Yuan Frank SAuction with methods and mechanisms to avoid fraud
US20060016880 *Nov 18, 2004Jan 26, 2006Irek SingerWireless payment processing system
US20060026097 *Jul 30, 2004Feb 2, 2006Kagi, Inc.Method and apparatus for verifying a financial instrument
US20060031161 *Oct 17, 2005Feb 9, 2006D Agostino JohnSystem and method for performing secure credit card purchases
US20060143121 *Feb 21, 2006Jun 29, 2006Treider Kevin CElectronic factoring
US20060229961 *Apr 8, 2005Oct 12, 2006Efunds CorporationRisk evaluation method and system using ACH data
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7328844 *Apr 19, 2004Feb 12, 2008Darwin Innovations CorporationPoint-of-transaction machine with improved versatility and related method
US7566002 *Jan 6, 2005Jul 28, 2009Early Warning Services, LlcIdentity verification systems and methods
US7822209Jun 6, 2006Oct 26, 2010Red Hat, Inc.Methods and systems for key recovery for a token
US7962418 *Mar 30, 2007Jun 14, 2011Amazon Technologies, Inc.System and method of fulfilling a transaction
US7967195 *Oct 26, 2007Jun 28, 2011First Data CorporationMethods and systems for providing guaranteed merchant transactions
US7992203May 24, 2006Aug 2, 2011Red Hat, Inc.Methods and systems for secure shared smartcard access
US8074265Aug 31, 2006Dec 6, 2011Red Hat, Inc.Methods and systems for verifying a location factor associated with a token
US8098829Jun 6, 2006Jan 17, 2012Red Hat, Inc.Methods and systems for secure key delivery
US8099765Jun 7, 2006Jan 17, 2012Red Hat, Inc.Methods and systems for remote password reset using an authentication credential managed by a third party
US8109435 *Jul 14, 2005Feb 7, 2012Early Warning Services, LlcIdentity verification switch
US8172132Jul 24, 2009May 8, 2012Early Warning Services, LlcIdentity verification systems and methods
US8176564Jun 14, 2005May 8, 2012Microsoft CorporationSpecial PC mode entered upon detection of undesired state
US8180741Jun 6, 2006May 15, 2012Red Hat, Inc.Methods and systems for providing data objects on a token
US8332637Jun 6, 2006Dec 11, 2012Red Hat, Inc.Methods and systems for nonce generation in a token
US8336085 *Sep 12, 2005Dec 18, 2012Microsoft CorporationTuning product policy using observed evidence of customer behavior
US8347078Dec 20, 2004Jan 1, 2013Microsoft CorporationDevice certificate individualization
US8353046Jun 8, 2005Jan 8, 2013Microsoft CorporationSystem and method for delivery of a modular operating system
US8356342 *Aug 31, 2006Jan 15, 2013Red Hat, Inc.Method and system for issuing a kill sequence for a token
US8364588 *Sep 2, 2010Jan 29, 2013Experian Information Solutions, Inc.System and method for automated detection of never-pay data sets
US8364952Jun 6, 2006Jan 29, 2013Red Hat, Inc.Methods and system for a key recovery plan
US8370264Jun 1, 2011Feb 5, 2013Amazon Technologies, Inc.System and method of fulfilling a transaction
US8376225 *Nov 11, 2011Feb 19, 2013United Services Automobile Association (Usaa)Secure card
US8412927Jun 7, 2006Apr 2, 2013Red Hat, Inc.Profile framework for token processing system
US8438645Apr 27, 2005May 7, 2013Microsoft CorporationSecure clock with grace periods
US8464348Dec 22, 2004Jun 11, 2013Microsoft CorporationIsolated computing environment anchored into CPU and motherboard
US8495380Jun 6, 2006Jul 23, 2013Red Hat, Inc.Methods and systems for server-side key generation
US8589695Jun 7, 2006Nov 19, 2013Red Hat, Inc.Methods and systems for entropy collection for server-side key generation
US8595101Sep 4, 2009Nov 26, 2013Exerian Information Solutions, Inc.Systems and methods for managing consumer accounts using data migration
US8622292 *Sep 29, 2005Jan 7, 2014Jeffrey Bart KatzReservation-based preauthorization payment system
US8639940Feb 28, 2007Jan 28, 2014Red Hat, Inc.Methods and systems for assigning roles on a token
US8693690Dec 4, 2006Apr 8, 2014Red Hat, Inc.Organizing an extensible table for storing cryptographic objects
US8700535Mar 21, 2008Apr 15, 2014Microsoft CorporationIssuing a publisher use license off-line in a digital rights management (DRM) system
US8707024Aug 4, 2006Apr 22, 2014Red Hat, Inc.Methods and systems for managing identity management security domains
US8719171Jul 8, 2010May 6, 2014Microsoft CorporationIssuing a publisher use license off-line in a digital rights management (DRM) system
US8725646Apr 15, 2005May 13, 2014Microsoft CorporationOutput protection levels
US8733640Feb 14, 2013May 27, 2014United Services Automobile Association (Usaa)Secure card
US8762350Mar 13, 2012Jun 24, 2014Red Hat, Inc.Methods and systems for providing data objects on a token
US8775299Jul 11, 2012Jul 8, 2014Experian Information Solutions, Inc.Systems and methods for large-scale credit data processing
US8775305 *May 25, 2012Jul 8, 2014First Data CorporationCard-present on-line transactions
US8781953Feb 9, 2010Jul 15, 2014Consumerinfo.Com, Inc.Card management system and method
US8781969Jul 13, 2010Jul 15, 2014Microsoft CorporationExtensible media rights
US8787566Aug 23, 2006Jul 22, 2014Red Hat, Inc.Strong encryption
US8793777 *Jun 29, 2012Jul 29, 2014Equifax, Inc.Verification and authentication systems and methods
US8806219Aug 23, 2006Aug 12, 2014Red Hat, Inc.Time-based function back-off
US8813243Feb 2, 2007Aug 19, 2014Red Hat, Inc.Reducing a size of a security-related data object stored on a token
US8832453Feb 28, 2007Sep 9, 2014Red Hat, Inc.Token recycling
US8856894Mar 12, 2013Oct 7, 2014Consumerinfo.Com, Inc.Always on authentication
US8930251Jan 6, 2012Jan 6, 2015Consumerinfo.Com, Inc.Debt trending systems and methods
US8977844Aug 31, 2006Mar 10, 2015Red Hat, Inc.Smartcard formation with authentication keys
US9004355Nov 11, 2009Apr 14, 2015Cardfree IncSecure system and method to pay for a service provided at a reservation
US9038154Aug 31, 2006May 19, 2015Red Hat, Inc.Token Registration
US9058627Mar 26, 2014Jun 16, 2015Consumerinfo.Com, Inc.Circular rotational interface for display of consumer credit information
US9059980May 25, 2012Jun 16, 2015First Data CorporationSystems and methods for authenticating mobile devices
US9081948Mar 13, 2007Jul 14, 2015Red Hat, Inc.Configurable smartcard
US9106632May 25, 2012Aug 11, 2015First Data CorporationProvisioning by delivered items
US9106633May 25, 2012Aug 11, 2015First Data CorporationSystems and methods for authenticating mobile device communications
US9147042Nov 22, 2011Sep 29, 2015Experian Information Solutions, Inc.Systems and methods for data verification
US9154477May 25, 2012Oct 6, 2015First Data CorporationSystems and methods for encrypting mobile device communications
US9189605Feb 23, 2009Nov 17, 2015Microsoft Technology Licensing, LlcProtected computing environment
US9224168Dec 11, 2012Dec 29, 2015Microsoft Technology Licensing, LlcTuning product policy using observed evidence of customer behavior
US9230283Jun 17, 2013Jan 5, 2016Consumerinfo.Com, Inc.Card registry systems and methods
US9251541 *Dec 18, 2012Feb 2, 2016Experian Information Solutions, Inc.System and method for automated detection of never-pay data sets
US9256904Aug 14, 2009Feb 9, 2016Experian Information Solutions, Inc.Multi-bureau credit file freeze and unfreeze
US9299073May 23, 2014Mar 29, 2016United Services Automobile Association (Usaa)Secure card
US9331996May 2, 2014May 3, 2016First Data CorporationSystems and methods for identifying devices by a trusted service manager
US9336359Feb 6, 2012May 10, 2016Microsoft Technology Licensing, LlcDevice certificate individualization
US9363481Apr 27, 2005Jun 7, 2016Microsoft Technology Licensing, LlcProtected media pipeline
US9400589Mar 12, 2013Jul 26, 2016Consumerinfo.Com, Inc.Circular rotational interface for display of consumer credit information
US9436804Sep 15, 2005Sep 6, 2016Microsoft Technology Licensing, LlcEstablishing a unique session key using a hardware functionality scan
US9450763Jul 22, 2013Sep 20, 2016Red Hat, Inc.Server-side key generation
US9489694 *Feb 4, 2016Nov 8, 2016Experian Information Solutions, Inc.Multi-bureau credit file freeze and unfreeze
US9542682Jan 4, 2016Jan 10, 2017Consumerinfo.Com, Inc.Card registry systems and methods
US9558519Apr 29, 2011Jan 31, 2017Consumerinfo.Com, Inc.Exposing reporting cycle information
US9563916Nov 26, 2013Feb 7, 2017Experian Information Solutions, Inc.System and method for generating a finance attribute from tradeline data
US9576030May 7, 2014Feb 21, 2017Consumerinfo.Com, Inc.Keeping up with the joneses
US9595051Feb 20, 2015Mar 14, 2017Experian Marketing Solutions, Inc.Systems and methods for providing anonymized user profile data
US9607336Jun 15, 2012Mar 28, 2017Consumerinfo.Com, Inc.Providing credit inquiry alerts
US9652802Mar 23, 2011May 16, 2017Consumerinfo.Com, Inc.Indirect monitoring and reporting of a user's credit data
US9684905Sep 28, 2015Jun 20, 2017Experian Information Solutions, Inc.Systems and methods for data verification
US9690820Apr 1, 2016Jun 27, 2017Experian Information Solutions, Inc.Database system for triggering event notifications based on updates to database records
US9697263Mar 4, 2013Jul 4, 2017Experian Information Solutions, Inc.Consumer data request fulfillment system
US9710852Apr 22, 2014Jul 18, 2017Consumerinfo.Com, Inc.Credit report timeline user interface
US9762572Feb 26, 2015Sep 12, 2017Red Hat, Inc.Smartcard formation with authentication
US20060144927 *Jan 6, 2005Jul 6, 2006First Data CorporationIdentity verification systems and methods
US20070012757 *Jul 14, 2005Jan 18, 2007First Data CorporationIdentity verification switch
US20070233603 *Oct 18, 2006Oct 4, 2007Schmidgall Matthew MFlexible routing of electronic-based transactions
US20080052235 *Oct 26, 2007Feb 28, 2008First Data CorporationMethods And Systems For Providing Guaranteed Merchant Transactions
US20090313069 *Jul 24, 2009Dec 17, 2009Early Warning Services, LlcIdentity Verification Systems and Methods
US20100332381 *Sep 2, 2010Dec 30, 2010Celka Christopher JSystem and method for automated detection of never-pay data sets
US20120266227 *Jun 29, 2012Oct 18, 2012Equifax Inc.Verification and authentication systems and methods
US20120317019 *May 25, 2012Dec 13, 2012First Data CorporationCard-Present On-Line Transactions
US20130105573 *Apr 20, 2012May 2, 2013Early Warning Services, LlcIdentity verification systems and methods
US20130173450 *Dec 18, 2012Jul 4, 2013Experian Information Solutions, Inc.System and method for automated detection of never-pay data sets
US20150088613 *Sep 23, 2013Mar 26, 2015Comdata Network, Inc.Systems, methods, and computer program products for managing fuel costs
US20150120440 *Dec 5, 2013Apr 30, 2015Elwha LLC, a limited liability corporation of the State of DelawareGuaranty provisioning via internetworking
US20150120473 *Nov 7, 2013Apr 30, 2015Elwha LLC, a limited liability corporation of the State of DelawareVendor-facilitated guaranty provisioning
US20150120500 *Oct 29, 2013Apr 30, 2015Elwha LLC, a limited liability corporation of the State of DelawareFacilitating guaranty provisioning for an exchange
US20150120502 *Mar 17, 2014Apr 30, 2015Elwha LLC, a limited liability corporation of the State of DelawareSupporting guaranty provisioning via user attribute proffering
US20150120550 *Dec 31, 2013Apr 30, 2015Elwha LLC, a limited liability corporation of the State of DelawareGuaranty provisioning via wireless service purveyance
US20150120555 *Aug 14, 2014Apr 30, 2015Elwha LlcExchange authorization analysis infused with network-acquired data stream information
US20150199738 *Aug 12, 2014Jul 16, 2015Elwha LlcGuaranty investigation
USD759689Mar 25, 2014Jun 21, 2016Consumerinfo.Com, Inc.Display screen or portion thereof with graphical user interface
USD759690Mar 25, 2014Jun 21, 2016Consumerinfo.Com, Inc.Display screen or portion thereof with graphical user interface
USD760256Mar 25, 2014Jun 28, 2016Consumerinfo.Com, Inc.Display screen or portion thereof with graphical user interface
Classifications
U.S. Classification235/380, 705/39
International ClassificationG07F7/08, G06Q20/00, G06K5/00
Cooperative ClassificationG06Q20/4016, G06Q20/12, G06Q20/403, G07F7/08, G06Q20/40, G06Q40/025, G06Q20/10, G06Q20/4037, G06Q20/02, G06Q20/0855
European ClassificationG06Q20/02, G06Q20/12, G06Q20/4037, G06Q20/403, G06Q20/0855, G06Q20/10, G06Q20/4016, G06Q20/40, G06Q40/025, G07F7/08
Legal Events
DateCodeEventDescription
Aug 30, 2005ASAssignment
Owner name: FIRST DATA CORPORATION, COLORADO
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MASCAVAGE, JOHN JOSEPH;WEICHERT, MARGARET MORGAN;HOGAN, ROBERT;REEL/FRAME:016473/0494;SIGNING DATES FROM 20050707 TO 20050814
Oct 31, 2007ASAssignment
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
Nov 17, 2010ASAssignment
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
Jan 31, 2011ASAssignment
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