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 numberUS20070192249 A1
Publication typeApplication
Application numberUS 11/303,018
Publication dateAug 16, 2007
Filing dateDec 16, 2005
Priority dateFeb 9, 2004
Also published asUS8386376, US20070282674, WO2005077066A2, WO2005077066A3
Publication number11303018, 303018, US 2007/0192249 A1, US 2007/192249 A1, US 20070192249 A1, US 20070192249A1, US 2007192249 A1, US 2007192249A1, US-A1-20070192249, US-A1-2007192249, US2007/0192249A1, US2007/192249A1, US20070192249 A1, US20070192249A1, US2007192249 A1, US2007192249A1
InventorsJanet Biffle, Danielle Domenica, Chanderpreet Duggal, Kristin Gomes, Stuart Goulden, Chin Khor, Vernon Marshall, Sabyasachi Mohanty, Ian Webb
Original AssigneeAmerican Express Travel Related Services Company, Inc., A New York Corporation
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
System, method and computer program product for authorizing transactions using enhanced authorization data
US 20070192249 A1
Abstract
The present invention provides systems, methods and computer program products for authorizing transactions based on, at least in part on, enhanced authorization data. In one embodiment, enhanced authorization data is received in a request for authorization to accept a transaction instrument as payment. Examples of enhanced authorization data include an automatic number identification, an information identifier, an email address, a contact telephone number, a ship-to-name, ship-to-address, an Internet Protocol address, and a seller identification. A risk analysis is performed based, at least in part, on the enhanced authorization data to determine the risk of the request being associated with a fraudulent purchase. The risk may be calculated by comparing the enhanced authorization data with information stored about the transaction instrument or with historical transaction information. Furthermore, the velocity of transactions associated with the enhanced authorization data may be measured in calculating the risk.
Images(9)
Previous page
Next page
Claims(30)
1. A method for authorizing a financial transaction, comprising:
receiving, from a device associated with a merchant, a request for authorization to accept a transaction instrument as payment for a purchase, the request including enhanced authorization data;
making an authorization decision for the request based, at least in part, upon the enhanced authorization data; and
sending the authorization decision to the device.
2. The method of claim 1, wherein the enhanced authorization data includes at least one of: an automatic number identification or an information identifier.
3. The method of claim 1, wherein the enhanced authorization data includes at least one of: an email address; a contact telephone number; a ship-to-name; a ship-to-address; an Internet Protocol (IP) address; or a seller identification.
4. The method of claim 1, wherein the enhanced authorization data includes at least one of: a passenger name; a travel date; a routing description; an electronic ticket indicator; an origin city; a destination city; a class of service; a number of passengers; a reservation code; or carrier code.
5. The method of claim 1, wherein the making step comprises:
calculating a risk based, at least in part, on the enhanced authorization data; and
comparing the risk with a range of acceptable risks.
6. The method of claim 5, wherein the calculating step comprises:
calculating the risk based, at least in part, on a historical transaction associated with the enhanced authorization data.
7. The method of claim 6, wherein the historical transaction is associated with another transaction instrument.
8. The method of claim 5, wherein the calculating step comprises:
calculating the risk based, at least in part, on the velocity of transactions associated with the enhanced authorization data.
9. The method of claim 5, wherein the calculating step comprises:
calculating the risk based, at least in part, on a comparison between the enhanced authorization data and information stored by a card issuer about a card member associated with the transaction instrument.
10. The method of claim 1, further comprising:
receiving an indication from a card member that the purchase is fraudulent; and
reversing the authorization decision.
11. A system for authorizing a financial transaction comprising:
a processor; and
a memory in communication with the processor, wherein the memory stores a plurality of processing instructions for directing the processor to:
receive, from a device associated with a merchant, a request for authorization to accept a transaction instrument as payment for a purchase, the request including enhanced authorization data;
make an authorization decision for the request based, at least in part, upon the enhanced authorization data; and
send the authorization decision to the device.
12. The system of claim 11, wherein the enhanced authorization data includes at least one of: an automatic number identification or an information identifier.
13. The system of claim 11, wherein the enhanced authorization data includes at least one of: an email address; a contact telephone number; a ship-to-name; a ship-to-address; an Internet Protocol (IP) address; or a seller identification.
14. The system of claim 11, wherein the enhanced authorization data includes at least one of: a passenger name; a travel date; a routing description; an electronic ticket indicator; an origin city; a destination city; a class of service; a number of passengers; a reservation code; or carrier code.
15. The system of claim 11, wherein the processing instructions for directing the processor to make an authorization decision include instructions for directing the processor to:
calculate a risk based, at least in part, on the enhanced authorization data; and
compare the risk with a range of acceptable risks.
16. The system of claim 15, wherein the processing instructions for directing the processor to calculate a risk include instructions for directing the processor to:
calculate the risk based, at least in part, on a historical transaction associated with the enhanced authorization data.
17. The system of claim 16, wherein the historical transaction is associated with another transaction instrument.
18. The system of claim 15, wherein the processing instructions for directing the processor to calculate a risk include instructions for directing the processor to:
calculate the risk based, at least in part, on the velocity of transactions associated with the enhanced authorization data.
19. The system of claim 15, wherein the processing instructions for directing the processor to calculate a risk include instructions for directing the processor to:
calculate the risk based, at least in part, on a comparison between the enhanced authorization data and information stored by a card issuer about a card member associated with the transaction instrument.
20. The system of claim 11, wherein the plurality of processing instructions includes instructions for directing the processor to:
receive an indication from a card member that the purchase is fraudulent; and
reverse the authorization decision.
21. A computer program product comprising a computer usable medium having control logic stored therein for causing a computer to associate a reference magnetic signature with a transaction instrument, said control logic comprising:
first computer readable program code means for causing the computer to receive, from a device associated with a merchant, a request for authorization to accept a transaction instrument as payment for a purchase, the request including enhanced authorization data;
second computer readable program code means for causing the computer to make an authorization decision for the request based, at least in part, upon the enhanced authorization data; and
third computer readable program code means for causing the computer to send the authorization decision to the device.
22. The computer program product of claim 21, wherein the enhanced authorization data includes at least one of: an automatic number identification or an information identifier.
23. The computer program product of claim 21, wherein the enhanced authorization data includes at least one of: an email address; a contact telephone number; a ship-to-name; a ship-to-address; an Internet Protocol (EP) address; or a seller identification.
24. The computer program product of claim 21, wherein the enhanced authorization data includes at least one of: a passenger name; a travel date; a routing description; an electronic ticket indicator; an origin city; a destination city; a class of service; a number of passengers; a reservation code; or carrier code.
25. The computer program product of claim 21, wherein the second computer readable program code means comprises:
fourth computer readable program code means for causing the computer to calculate a risk based, at least in part, on the enhanced authorization data; and
fifth computer readable program code means for causing the computer to compare the risk with a range of acceptable risks.
26. The computer program product of claim 25, wherein the fourth computer readable program code means comprises:
sixth computer readable program code means for causing the computer to calculate the risk based, at least in part, on a historical transaction associated with the enhanced authorization data.
27. The computer program product of claim 26, wherein the historical transaction is associated with another transaction instrument.
28. The computer program product of claim 25, wherein the fourth computer readable program code means comprises:
sixth computer readable program code means for causing the computer to calculate the risk based, at least in part, on the velocity of transactions associated with the enhanced authorization data.
29. The computer program product of claim 25, wherein the fourth computer readable program code means comprises:
sixth computer readable program code means for causing the computer to calculate the risk based, at least in part, on a comparison between the enhanced authorization data and information stored by a card issuer about a card member associated with the transaction instrument.
30. The system of claim 21, further comprising:
fourth computer readable program code means for causing the computer to receive an indication from a card member that the purchase is fraudulent; and
fifth computer readable program code means for causing the computer to reverse the authorization decision.
Description
    CROSS REFERENCE TO RELATED APPLICATIONS
  • [0001]
    This application is a continuation-in-part of Patent Cooperation Treaty Application No. PCT/US05/004135, filed Feb. 9, 2005, and titled “System And Method Using Enhanced Authorization Data To Reduce Travel-Related Transaction Fraud,” which claims the benefit of U.S. Provisional Patent Application Ser. No. 60/543,044, filed Feb. 9, 2004, and titled “Enhanced Airline Authorization Data For Fraud Control,” which are all hereby incorporated by reference herein in their entireties.
  • BACKGROUND OF THE INVENTION
  • [0002]
    1. Field of the Invention
  • [0003]
    The present invention generally relates to fraud detection and more particularly to reducing fraudulent transactions.
  • [0004]
    2. Related Art
  • [0005]
    Credit cards, charge cards, and other transaction instruments are commonly accepted today as a form of payment under a variety of circumstances. A transaction instrument may be used to make a purchase in-person, for example, at a retail store, a restaurant, or a hotel by physically presenting a merchant with the transaction instrument. A transaction instrument may also be used to make a purchase without physically presenting the transaction instrument by relaying information associated with the transaction instrument, such as account number, account name, expiration date, and billing address, to a merchant. Examples of merchants that accept transaction instruments as payment without physically receiving the transaction instrument include Internet, telephone and mail order merchants.
  • [0006]
    Although transaction instruments provide a convenient means for making payments, they are vulnerable to fraud. A transaction instrument may be copied, or information about a transaction instrument necessary to make purchases may be stolen. While the card member and card issuer are unsuspecting of any fraudulent activity, numerous fraudulent purchases may be charged to the card member's transaction instrument.
  • [0007]
    To counteract fraudulent purchases, a card issuer may employ a risk analysis when a merchant requests authorization to receive a transaction instrument as payment. Risk analysis is utilized to evaluate the risks of a purchase being fraudulent. If the risks are determined to be, unacceptable, the card issuer may deny the merchant's request to receive the transaction instrument as payment. For example, if a transaction instrument is reported as being lost, risk analysis may indicate an unacceptable level of risk for any further purchases involving the transaction instrument. The card issuer may then deny any requests made by merchants for authorization to accept the transaction instrument as payment.
  • [0008]
    Although conventional risk analysis reduces incidences of fraud, its ability to distinguish genuine and fraudulent purchases is limited because only a limited amount of information about a purchase is provided to a card issuer from the merchant. Conventional risk analysis is based on transaction account information and payment information. Transaction account information may include, for example, account number, account name, expiration date, billing address, and credit card verification (CCV) number. Payment information may include, for example, payment amount and payment recipient. Conventional risk analysis does not utilize other information associated with a purchase such as, for example, a ship-to-address, an email address of the purchaser, an IP address of the machine from which the purchase was initiated, etc.
  • [0009]
    Given the foregoing, what is needed is a system, method and computer program product that accepts a greater amount of purchase-related information than that used by conventional risk analysis to further reduce incidences of fraud.
  • BRIEF DESCRIPTION OF THE INVENTION
  • [0010]
    Systems, methods and computer program products for authorizing transactions based at least in part on enhanced authorization data are provided. Enhanced authorization data includes information associated with a purchase other than transaction account information and payment information. The enhanced authorization data may be received from a merchant in a request for authorization to accept a transaction instrument as payment. A decision to approve, deny, or refer the request is made based, at least in part, on the enhanced authorization data. The authorization decision is then provided to the merchant.
  • [0011]
    Examples of enhanced authorization data include an automatic number identification (ANI), an information identifier (II), an email address, a contact telephone number, a ship-to-name, a ship-to-address, an Internet Protocol (IP) address, and a seller identification. Enhanced authorization data may be specific to a particular industry or category of merchants. For example, merchants dealing in airline tickets may provide information such as a passenger name, a travel date and/or a destination city as enhanced authorization data.
  • [0012]
    Enhanced authorization data is collected, for example, by a merchant in the course of fulfilling a purchase desired by a purchaser. When enhanced authorization data is provided with a request for authorization to accept a transaction instrument as payment, risk analysis is performed using the enhanced authorization data to calculate the risks of the purchase being fraudulent.
  • [0013]
    In performing risk analysis, enhanced authorization data may be compared with historical transaction information as well as with information stored for a card member associated with the request. Historical transaction information includes information about previous transactions. Historical transaction data may be compared to determine, for example, if the enhanced authorization data was provided previously in fraudulent purchases. Historical transactions may also be examined to determine the rate, also referred to as velocity, at which transactions associated with an enhanced authorization data are initiated to evaluate the risks of the request being fraudulent.
  • [0014]
    Once a risk is calculated for a request, it is compared with a range of acceptable risks to make an authorization decision. If the risk is acceptable, an authorization decision is made to approve the request. If the risk is not acceptable, an authorization decision to deny or to refer the request is made.
  • [0015]
    The authorization decision is provided to the merchant in response to the merchant's request for authorization. If the request is approved, the merchant may complete the purchase by accepting the transaction instrument as payment. If the request is denied, the merchant may ask for another form of payment from the purchaser to complete the purchase. If the request is referred, the merchant or the purchaser may be asked to contact the card issuer to provide additional information so that the request may be approved.
  • [0016]
    If a request is approved and it is later determined to be associated with a fraudulent purchase, the merchant may be contacted to reverse the authorization. If the purchase has not yet been fulfilled, for example, because the purchased item has not yet been shipped, the merchant may cancel the purchase. A request may be determined as being fraudulent, for example, by contacting a card member of the transaction instrument associated with the request to confirm the validity of the transaction or purchase.
  • [0017]
    An advantage of the present invention is that a more sophisticated risk analysis may be performed since enhanced authorization data provides additional information that can be used to distinguish between requests for genuine transactions and fraudulent transactions. Furthermore, since enhanced authorization data is typically captured by a merchant during the ordinary course of processing a purchase, the purchaser is not burdened with providing information other than those the purchaser is ordinarily asked to provide. Another advantage of the present invention is that since enhanced authorization data is independent of transaction account information, it may be used to correlate fraudulent activity patterns experienced across multiple card members and merchants.
  • [0018]
    Further features and advantages of the present invention as well as the structure and operation of various embodiments of the present invention are described in detail below with reference to the accompanying drawings.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0019]
    The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings in which like reference numbers indicate identical or functionally similar elements. Additionally, the left-most digit of a reference number identifies the drawing in which the reference number first appears.
  • [0020]
    FIG. 1 is a system diagram of an exemplary environment in which the present invention can be implemented.
  • [0021]
    FIG. 2 is a flowchart illustrating an example authorization process.
  • [0022]
    FIG. 3 is a diagram illustrating an example of risk analysis based on the velocity of transactions.
  • [0023]
    FIG. 4 is a block diagram of a first exemplary financial transaction network for processing financial transactions involving the purchase of airline tickets.
  • [0024]
    FIG. 5 is a flowchart illustrating a first exemplary method for processing a financial transaction involving the purchase of airline tickets using enhanced transaction variables.
  • [0025]
    FIG. 6 is a block diagram of a second exemplary financial transaction network for processing financial transactions involving the purchase of airline tickets.
  • [0026]
    FIG. 7 is a flowchart illustrating a second exemplary method for processing a financial transaction involving the purchase of airline tickets using enhanced transaction variables.
  • [0027]
    FIG. 8 is a block diagram of an exemplary computer system useful for implementing the present invention.
  • DETAILED DESCRIPTION I. OVERVIEW AND TERMINOLOGY
  • [0028]
    Systems, methods and computer program products for authorizing transactions based at least in part on enhanced authorization data are provided. In the detailed description of the invention that follows, references to “one embodiment”, “an embodiment”, “an example embodiment”, etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. After reading the following description, it will be apparent to one skilled in the relevant art(s) how to implement the following invention in alternative embodiments.
  • [0029]
    The terms “business” or “merchant” may be used interchangeably with each other and shall mean any person, entity, distributor system, software and/or hardware that is a provider, broker and/or any other entity in the distribution chain of goods or services. For example, a merchant may be a grocery store, a retail store, a travel agency, a service provider, an on-line merchant or the like.
  • [0030]
    A “transaction account” as used herein refers to an account associated with an open account or a closed account system (as described below). The transaction account may exist in a physical or non-physical embodiment. For example, a transaction account may be distributed in non-physical embodiments such as an account number, frequent-flyer account, telephone calling account or the like. Furthermore, a physical embodiment of a transaction account may be distributed as a financial instrument.
  • [0031]
    A financial transaction instrument may be traditional plastic transaction cards, titanium-containing, or other metal-containing, transaction cards, clear and/or translucent transaction cards, foldable or otherwise unconventionally-sized transaction cards, radio-frequency enabled transaction cards, or other types of transaction cards, such as credit, charge, debit, pre-paid or stored-value cards, or any other like financial transaction instrument. A financial transaction instrument may also have electronic functionality provided by a network of electronic circuitry that is printed or otherwise incorporated onto or within the transaction instrument (and typically referred to as a “smart card”), or be a fob having a transponder and an RFID reader.
  • [0032]
    “Open cards” are financial transaction cards that are generally accepted at different merchants. Examples of open cards include the American Express®, Visa®, MasterCard® and Discover® cards, which may be used at many different retailers and other businesses. In contrast, “closed cards” are financial transaction cards that may be restricted to use in a particular store, a particular chain of stores or a collection of affiliated stores. One example of a closed card is a pre-paid gift card that may only be purchased at, and only be accepted at, a clothing retailer, such as The Gap® store.
  • [0033]
    Stored value cards are forms of transaction instruments associated with transaction accounts, wherein the stored value cards provide cash equivalent value that may be used within an existing payment/transaction infrastructure. Stored value cards are frequently referred to as gift, pre-paid or cash cards, in that money is deposited in the account associated with the card before use of the card is allowed. For example, if a customer deposits ten dollars of value into the account associated with the stored value card, the card may only be used for payments up to ten dollars.
  • [0034]
    An “account,” “account number” or “account code”, as used herein, may include any device, code, number, letter, symbol, digital certificate, smart chip, digital signal, analog signal, biometric or other identifier/indicia suitably configured to allow a consumer to access, interact with or communicate with a financial transaction system. The account number may optionally be located on or associated with any financial transaction instrument (e.g., rewards, charge, credit, debit, prepaid, telephone, embossed, smart, magnetic stripe, bar code, transponder or radio frequency card).
  • [0035]
    The terms “card member,” “card holder,” and/or the plural form of these terms are used interchangeably throughout herein to refer to those persons or entities that own or are authorized to use a transaction account.
  • [0036]
    The terms “user,” “consumer,” “purchaser,” and/or the plural form of these terms are used interchangeably throughout herein to refer to those persons or entities that are alleged to be authorized to use a transaction account.
  • [0037]
    The terms “payment vehicle,” “financial transaction instrument,” “transaction instrument” and/or the plural form of these terms are used interchangeably throughout to refer to a financial instrument.
  • II. SYSTEM
  • [0038]
    Referring to FIG. 1, a system diagram of an exemplary system 100 in which the present invention can be implemented is shown.
  • [0039]
    System 100 includes a purchaser 102, a merchant 104, an authorization system 106, a card member database 108, and a transaction database 110. Purchaser 102 interacts with merchant 104 to make a purchase with a transaction instrument. Merchant 104 asks for authorization to accept the transaction instrument as payment by sending a request to authorization system 106. Authorization system 106 performs risk analysis on the request using information, for example, from card member database 108 and transaction database 110. Based on the risk analysis, authorization system 106 makes an authorization decision to approve, deny or refer the request. The authorization decision is provided to merchant 104. Merchant 104 completes the purchase if the request is approved or asks for an alternative form of payment from the purchaser if the request is denied. If the request is referred, merchant 104 may contact the card issuer or ask the purchaser to contact the card issuer to provide additional information to have the request approved.
  • [0040]
    Purchaser 102 may interact with merchant 104 in person (e.g., at the box office), telephonically, or electronically (e.g., from a user computer via the Internet) to make a purchase. When interacting in person, purchaser 102 may physically present a transaction instrument to merchant 104 as a form of payment. When communicating with merchant 104 through a telephone or a computer (e.g., using a web enabled computer, kiosk, terminal or the like), purchaser 102 may provide information associated with a transaction instrument, such as account number, expiration date, account name, and billing address, to merchant 104 to make a payment using the transaction instrument.
  • [0041]
    Along with providing a transaction instrument as payment, purchaser 102 may provide additional information to merchant 104 while making a purchase. For example, purchaser 102 may provide a ship-to-address or a ship-to-name that is different than a name or billing address associated with the transaction instrument. Purchaser 102 may provide an email address or a contact telephone number to merchant 104 so that purchaser 102 may be updated with the status of a purchase.
  • [0042]
    Furthermore, merchant 104 may obtain additional information about purchaser 102 from other sources while interacting with purchaser 102. For example, if purchaser 102 is communicating with merchant 104 over a telephone, merchant 104 may receive an automatic number identification (ANI) and a corresponding information identifier (II) for purchaser 102 from a telephone company. ANI provides the telephone number of the telephone used by purchaser 102 to communicate with merchant 104. II identifies the type of telephone used by purchaser 102 such as, for example, a cellular telephone, coin-operated telephone, prison telephone, or a standard land-line telephone. In another example, if purchaser 102 is communicating with merchant 104 over the Internet, the Internet Protocol (IP) address of the machine that purchaser 102 used to initiate the purchase may be captured by whatever Internet-based commerce system utilized by merchant 104.
  • [0043]
    Merchant 104 is any entity or system capable of receiving a payment from purchaser 102 using a transaction instrument. Merchant 104 may offer goods and services in exchange for payment from purchaser 102. Merchant 104 may be, for example, an Internet commerce, telephone order or mail order company. Merchant 104 may also be, for example, an aggregator or a third-party biller that facilitates transactions between purchaser 102 and a seller (not shown). Examples of aggregators or third-party billers include eBay® and PayPal®. If merchant 104 is an aggregator or a third-party biller, merchant 104 may capture information such as a seller identification and/or description of the type of goods or services sought to be purchased by purchaser 102 from the seller. Goods and services purchased through merchant 104 may be delivered physically (e.g., through the mail) or electronically (e.g., such as by downloading software over the Internet) to purchaser 102.
  • [0044]
    When purchaser 102 wishes to make a payment using a transaction instrument, merchant 104 makes a request to authorization system 106 for authorization to accept the transaction instrument as payment. Merchant 104 formats the request using a computer device to include information about the transaction instrument, payment information, and enhanced authorization data. Examples of enhanced authorization data include, for example, an ANI, an II, an email address, a contact telephone number, a ship-to-name, a ship-to-address, an IP address, and a seller identification. The request is transmitted to authorization system 106. The request may be sent to authorization system 106 over, for example, a telephone network, intranet, the Internet, wireless communications, and/or the like.
  • [0045]
    Authorization system 106 receives the request for authorization to accept a transaction instrument as payment and performs a risk analysis to assess the risks of the request being associated with a fraudulent purchase. In assessing the risks, authorization system 106 may compare the information in the request with information in card member database 108 and transaction database 110. Card member database 108 includes information about card members and transaction instruments. For example, card member database 108 may include the billing address, email address, and contact telephone number of each card member. Transaction database 110 includes information about previous transactions (e.g., purchases). For example, transaction database 110 may include information about previous requests for authorization, decisions made for the previous requests, and any subsequent information obtained for those requests, such as whether a purchase associated with a request was later reported as being fraudulent. Although databases 108 and 110 are shown separately, as would be appreciated by one skilled in the relevant arts, the two databases may be implemented as a single or multiple databases. The risk analysis will be described in more detail below.
  • [0046]
    After risk analysis is performed for the request, authorization system 106 makes an authorization decision to approve, deny, or refer the request and provides the decision to merchant 104. If the request is approved, merchant 104 may accept the transaction instrument as payment. If the request is denied, merchant 104 may inform purchaser 102 that the request was denied and ask purchaser 102 for another form of payment to complete the purchase. If the request is referred, merchant 104 and/or purchaser 102 may be asked to contact a card issuer to provide additional information to have the request approved.
  • [0047]
    If at a later time a purchase that was approved by authorization system 106 is determined to be fraudulent, authorization system 106 or a card issuer may contact merchant 104 to reverse the approval. If merchant 104 has not yet completed the purchase, for example, by not shipping goods to purchaser 102, merchant 104 may cancel the purchase.
  • III. PROCESS
  • [0048]
    FIG. 2 illustrates an example process 200 for authorizing a request to receive a transaction instrument as payment. Process 200 begins at step 202.
  • [0049]
    In step 202, a request for authorization to accept a payment associated with a transaction instrument is received from a merchant such as merchant 104. The merchant makes a request when a purchaser provides the merchant with a transaction instrument or information about the transaction instrument to make a payment for a purchase. The request may include enhanced authorization data such as, for example, an ANI, an II, an email address, a contact telephone number, a ship-to-name, a ship-to-address, an IP address, or a seller identification that was obtained by the merchant during the course of fulfilling the purchase. Enhanced authorization data may be specific to a particular industry or category of merchants. For example, merchants dealing in airline tickets may provide as enhanced authorization data information such as passenger name, travel date, or destination city.
  • [0050]
    In step 204, an authorization decision is made based, at least in part, upon the enhanced authorization data included in the request received in step 202. The authorization decision is based on a risk analysis performed using the information in the request. If the risks are within a range of acceptable risks, a decision to approve the request is made. If the risks are outside the range of acceptable risks, a decision to deny or refer the request is made.
  • [0051]
    Various risk analysis may be performed using the enhanced authorization data provided in a request. For example, enhanced authorization data may be compared with information stored about the transaction instrument or with information stored about a card member associated with the transaction instrument to assess risks. If the enhanced authorization data includes an email address, contact telephone number, or a ship-to-name, each can be compared with stored values of the card member's email address, telephone numbers, and name, respectively. If the comparisons match, less risk is assigned to the request. In another example, if the enhanced authorization data includes an IP address, it can be compared with the IP address, for example, of the machine the card member uses to access the card issuer's bank website. If the IP addresses match, less risk is assigned to the request.
  • [0052]
    Historical transaction information may also be compared with enhanced authorization data to calculate risks. Historical transaction information includes information about previous transactions. For example, if enhanced authorization data includes a ship-to-address, it may be compared with prior ship-to-addresses used in historical transactions. If the ship-to-address is associated with numerous historical transactions that were reported as being fraudulent, more risk is assigned to the request.
  • [0053]
    In evaluating enhanced authorization data with historical transaction information, transaction information associated with other card members and other merchants may be used to calculate risks. For example, if the enhanced authorization data includes a seller identification, an ANI, or an II information, this information may be compared with historical transactions across multiple card members and merchants. If the seller identification, ANI, or II information provided in the request is associated with fraudulent activity across multiple card members and merchants, a greater level of risk may be assigned to the request.
  • [0054]
    Furthermore, historical transactions may be examined to determine the velocity of transactions associated with an enhanced authorization data to calculate risks. The velocity of transactions is the rate at which transactions are initiated in a designated period of time. For example, if an IP address is included as part of an enhanced authorization data, the velocity of prior transactions which are also associated with the IP address can be measured. If the velocity is atypically high for the IP address, a greater level of risk may be associated with the request. Assessing risks based on the velocity of transactions is explained in greater detail herein with respect to FIG. 3.
  • [0055]
    As would be appreciated by persons skilled in the relevant arts, enhanced authorization data such as an ANI, II, an email address, a contact telephone number, a ship-to-name, a ship-to-address, an IP address, or a seller identification may be used in different ways to assess the risks of an authorization request being associated with a fraudulent purchase.
  • [0056]
    In step 206, the authorization decision made in step 204 is sent to the merchant that provided the request in step 202. The merchant proceeds according to the authorization decision. If the request is approved, the merchant completes the purchase. If the request is denied, the merchant may inform the purchaser that the transaction instrument was denied and/or ask the purchaser for another form of payment to complete the purchase. If the request is referred, the merchant may contact the card issuer or ask the purchaser to contact the card issuer to provide additional information to have the request approved.
  • [0057]
    FIG. 3 illustrates a diagram 300 that shows an example of risk analysis based on the velocity of transactions. Diagram 300 includes a purchaser 302, merchants 304, 306 and 308, authorization system 106, and request data 314, 316, and 318. Diagram 300 depicts examples of three requests for authorization to accept transaction instruments as payment from three different merchants 304, 306, and 308.
  • [0058]
    As shown by request data 314, a first request for authorization to accept a transaction instrument as payment was made by merchant 304 on Sep. 7, 2004 at 5:05 PM. Along with the date and time, transaction account information associated with the transaction instrument such as the name of the account holder (e.g., Joe White) and billing address (e.g., 2213 E. Main St) was provided by merchant 304 in the request. Furthermore enhanced authorization data such as the email address of the purchaser (e.g., funstuff@abc.com) and IP address of the machine with which the purchaser initiated the purchase (e.g., 123.22.15.18) was also provided by merchant 304 to authorization system 106 in the request.
  • [0059]
    A second request for authorization to accept a transaction instrument as payment, as shown by request data 316, was made by merchant 306 just 27 minutes after the first request (e.g., Sep. 7, 2004 at 5:32 PM). In addition to the date and time information, request data 316 includes transaction account information such as the name of the account holder (e.g., Stan Rogers) and billing address (e.g., 555 Bermuda Ave). Request data 316 further includes an email address of the purchaser (e.g., funstuff@abc.com) as enhanced authorization data.
  • [0060]
    When a third request for authorization, as shown by request data 318, is received by authorization system 106, the velocity of historical transactions may be examined to assess the risk of the third request being associated with a fraudulent purchase. Request data 318 includes a date and time (e.g., Sep. 7, 2004 at 6:01 PM), name of the account holder (e.g., Jennifer Saks) and billing address (e.g., 3133 S Central Ave.). Request data 318 further includes, as enhanced authorization data 320, an email address of the purchaser (e.g., funstuff@abc.com). To determine the velocity of transactions, authorization system 106 examines historical transactions that are associated with enhanced authorization data received in the request such as, for example, enhanced authorization data 320. Request data 314 and request data 316 are examined since they both contain enhanced authorization data 320 (e.g., funstuff@abc.com). The velocity of these requests is considered by authorization system 106 in assessing the risks of the third request being associated with a fraudulent purchase. In the example depicted in diagram 300, considering that all three requests occurred within one hour of each other, each request is associated with a different transaction instrument, and all requests point to a single purchaser 302 as identified by the enhanced authorization data 320, authorization system 106 may assign a greater level of risk for the third request. If the transaction accounts associated with the three requests do not have a history of being associated with enhanced authorization data 320, the velocity of transactions as depicted in FIG. 3 may suggest that purchaser 302 is making fraudulent purchases using transaction instruments belonging to several people (e.g., Joe White, Stan Rogers, and Jennifer Saks).
  • [0061]
    Based on the risk analysis performed by authorization system 106 for the third request, authorization system 106 provides an authorization decision to merchant 308. Card members associated with transaction instruments provided in the first, second, and third requests may be contacted to determine the validity of the requests. If a request is determined to be associated with a fraudulent purchase, the appropriate merchant may be contacted to cancel a purchase associated with the request.
  • IV. EXAMPLE EMBODIMENT
  • [0062]
    An example embodiment, according to the present invention, is provided below with reference to enhanced authorization data as it relates to merchants dealing with airline travel tickets.
  • [0063]
    Financial institutions currently have existing transaction networks over which financial transactions between its account holders and various merchants may be completed. Financial institutions are therefore uniquely positioned to offer advanced risk identification and prevention measures to its customers, merchants and partners by leveraging these existing networks, or by establishing new networks where these capabilities are provided.
  • [0064]
    The processes introduced herein enable financial institutions to make improved fraud risk management decisions for transactions, particularly those involving travel tickets such as airline tickets. By capturing and analyzing certain additional information at the point of authorization of a charge, the risk that the transaction is fraudulent may be more accurately evaluated before the ticket purchase is authorized. In an embodiment, real-time fraud risk decisions are based on an evaluation of the data traditionally provided in an authorization request plus ten additional transaction variables that have routinely been captured by the merchant and are now transmitted to the financial institution with a real-time authorization request.
  • [0065]
    The processes will be described throughout with reference to airline tickets. However, it should be readily apparent that the processes may be used regarding any transaction in which similar data may be captured and evaluated. In an embodiment, the additional transaction variables provided with respect to the purchase of airline tickets may include: an airline reservation code for the ticket; the passenger name listed on the ticket; an origin airport for the ticket; a destination airport for the ticket; a travel date for the ticket; a description of routing airports or city codes of the airline ticket (e.g., New York to Miami returning to New York: JFK-MIA-MIA-JFK); a class of service (e.g., first class, business class, or coach class, including fare basis information and ticket designator information); an indicator of whether the airline ticket is an electronic ticket; a number of passengers for which tickets are purchased; and a code corresponding to an airline carrier for which the ticket is booked. Advantageously, these ten variables are typically captured in various transactions by airlines and other airline ticket merchants, such as travel agencies and online travel web sites. However, these transaction variables have not previously been provided as part of real-time authorization requests to financial institutions that maintain account holder accounts, and such transaction variables have not been used for fraud risk screening by financial institutions prior to or during the real-time authorization of a transaction.
  • [0066]
    According to the present disclosure then, one or more of the additional transaction variables are now transmitted from the merchant to a financial institution in an automated manner and in a standardized format over the financial transaction network during a transaction initiation and authorization process so that standard authorization times (based on all types of financial transactions using similar payment vehicles) are not affected. The received transaction variables (traditional plus additional) are immediately presented to one or more software-implemented fraud-risk models maintained by the financial institution, which are well-known in the relevant art(s), but must now account for additional variables as described below with respect to FIG. 5. Such software-implemented fraud-risk models would then evaluate the received transaction variables, and from this, an immediate risk decision (e.g., to accept or refer the transaction for further identification, or a request to contact the financial institution) based on a determined risk factor can be made.
  • [0067]
    In various embodiments, the transaction variables may be used in combination with standard information utilized by financial institutions to authorize transactions (e.g., amount of transaction, status of account holder account, purchases and transaction history of the particular account holder, available credit for the financial account, and a transaction history of the particular merchant). The combination of the processes introduced herein with standard authorization decision-making criteria will provide enhanced fraud risk assessment before the ticket or service is authorized for payment on a payment vehicle. This, in turn, will reduce the incidence of fraudulent transactions and reduce processing costs for charge backs and the like.
  • [0068]
    Turning now to FIG. 4, there is depicted a conceptual block diagram of a first exemplary transaction network 400, over which the processes of the present disclosure may be performed. In the network 400, an account holder 402 may initiate a transaction with an airline carrier server 404 for the purchase of airline tickets in any standard manner. When the account holder wishes to pay for the tickets using a payment vehicle, the airline carrier server 404, in turn, may communicate with a financial institution server 406 of the financial institution that maintains the account corresponding to the payment vehicle.
  • [0069]
    In various embodiments, the account holder 402 may communicate with the airline carrier over the Internet using a computer terminal or the like, via telephone, or in person. The account holder 402 may use a credit card, charge card, stored value card, debit card or other type of payment vehicle for the transaction.
  • [0070]
    The airline carrier server 404 may be any type of computer server, or group of distributed servers, that include appropriate processors, memory and network communication devices, as well as application and operating systems software that includes processing instructions and programming for performing the processes disclosed herein. The airline carrier server 404 may communicate with the financial server 406 using any existing transaction processing network, with little need for changes to existing network hardware. Merchants and financial institutions may require certain software changes to capture and transmit the ten transaction variables with authorization requests for ticket purchases in an acceptable format. When the transaction involves an AMERICAN EXPRESS card, for example, the transaction variables can be sent in the AMERICAN EXPRESS Authorization ISO 8583 Version 1 Specification format.
  • [0071]
    Turning now to FIG. 5, there is depicted a flowchart of an exemplary method 500 for processing a financial transaction involving the purchase of airline tickets using enhanced transaction variables. The method 500 commences when an account holder initiates a transaction with an airline carrier for a purchase of an airline ticket (step 502). During the course of the transaction, the airline receives certain of the transaction variable information from the account holder, including the account holder name; a passenger name; an origin airport for the ticket; a destination airport for the ticket; a travel date for the ticket; a description of routing airports or city codes of the airline ticket (e.g., New York to Miami returning to New York: JFK-MIA-MIA-JFK); a class of service (e.g., first class, business class, or coach class, including fare basis information and ticket designator information); an indicator of whether the airline ticket is an electronic ticket. During the course of the transaction, the airline may also determine a reservation code for the ticket and supply its airline carrier code (step 504).
  • [0072]
    Upon agreement of the terms of the ticket, the airline receives a method of payment from the account holder, and then contacts the financial institution maintaining the account holder's account. The airline then transmits the enhanced transaction variables, in addition to the variables traditionally provided, to the financial institution in a standard format with a request to authorize the transaction for payment (step 506).
  • [0073]
    Next, at step 508, the financial institution processes the received transaction variables through at least one fraud-risk model in order to determine the risk of fraud presented by the transaction variables using historical transaction data. Any transactions identified as high risk may be referred for further identification or in case of extreme risk declined. Such a result may occur where the risk models determine that the probability of fraud is within a range of unacceptable values. This range may be established based on historical data so that legitimate transactions are not unduly prevented by the fraud-risk models. The range may be adjusted over time as more historical data is collected and analyzed.
  • [0074]
    Alternatively, or in addition thereto, where the fraud-risk models indicate a risk factor within a certain range of unacceptable values for the transaction, the financial institution may instead transmit a request to be contacted by the account holder by telephone or the like (referred to herein as a call referral message) before the transaction can be authorized. Alternatively, when the fraud-risk models indicate that the risk is within a range of acceptable values, the transaction may then continue to be processed in a standard manner.
  • [0075]
    The financial institution replies to the authorization request with an approval, declination or call referral message based on the outcome of the fraud-risk model along with standard authorization decision-making criteria (step 510). The airline then processes the transaction in accordance with the reply received from the financial institution (step 512), after which process 500 ends.
  • [0076]
    The fraud-risk model or models may be generated from collected data regarding fraudulent and/or legitimate transactions over a large group of account holders on a national or international scale. A risk value may be determined for each collected transaction variable or for inter-comparisons between the received transaction variables, using such historical transaction data. These empirically-determined, risk values may be applied within the risk models in any of a variety of useful manners to determine an overall risk for a given transaction.
  • [0077]
    The received transaction variable data can be applied to historical data in any of a wide variety of useful ways using a wide number of formulas and other forms of risk models. Since historical financial transaction data is used to determine the risk, these values and formulas will be largely dependent on the empirical data used. The formulas may further be refined over time by examining changes in historical data patterns as time progresses, as will be readily apparent to one of ordinary skill in the art.
  • [0078]
    In one example, transactions in which a reservation code is provided may have less risk of fraud than transactions in which no reservation code is provided. The fraud-risk model may then apply a risk value to a received transaction based on whether a reservation code has been provided and the historical data on prior transactions in which a reservation code has not been received.
  • [0079]
    In another example, historical data may reveal that fraudulent transactions are more likely for tickets of a certain type of routing (e.g., one-way ticket purchases may have a greater risk of being fraudulent than round-trip purchases), a certain class of service, or for certain airline carriers. Appropriate risk values will then be applied to these individual transaction variables for each transaction received.
  • [0080]
    In a further example, a transaction is received in which the transaction variable “Passenger Name” is not the same as the transaction variable “Account Holder Name.” The risk value based on such inter-comparison of received transaction variables may be determined based on data of prior fraudulent transactions. For example, it may be that the historical data shows that 5% of transactions in which the Passenger Name does not match the account holder name are fraudulent. A risk value of 0.05 for this transaction variable may accordingly be applied within the fraud-risk models for any transaction in which this is the case, and this value may be added, multiplied or combined with similar determinations for other risk values regarding the remaining transaction variables to determine an overall risk factor for the transaction.
  • [0081]
    It is important that the introduction of this fraud risk decision-making process to financial transaction authorization processes not substantially impact the standard time it currently takes to authorize a credit transaction with airlines or travel agencies, and does not unduly impact the identification and processing of legitimate transactions. That is, legitimate transactions should never be misidentified as fraudulent. Appropriate values and formulas for the risk values and the fraud-risk models, as well as range of acceptable and unacceptable values for transaction risk, may be designed with this goal in mind and refined over time by continuously analyzing historical transaction data to ensure that this goal is achieved.
  • [0082]
    Another embodiment of the present disclosure, shown in FIG. 6, involves the case where the merchant selling the ticket is a travel agent or other third-party, and not the travel carrier engaging in a direct sale. Accordingly, a second exemplary transaction network 600 may include the account holder 402, in communication with a travel agency server 602 or other third-party merchant. The travel agency server 602, in turn, may communicate with the financial institution via a third-party processing system 604, such as may be provided by existing Global Distribution Service (GDS) providers.
  • [0083]
    In such existing systems, only minor hardware and software changes may be needed to accommodate the processes disclosed herein, so that the third-party processors can capture and transmit additional variables for fraud risk screening. In examples where the payment vehicle is maintained by AMERICAN EXPRESS, the travel agencies and Global Distribution System providers must be able to send this information to AMERICAN EXPRESS in the authorization request using the ISO 8583 Version 1 Specification format. Other third-party processors who assist in transferring authorization requests to American Express or other financial institutions (i.e., issuers of payment vehicles used for such transactions) on behalf of airlines or GDS's must also be able to accept and transfer this information in the authorization stream as specified therein.
  • [0084]
    Turning now to FIG. 7, there is depicted a flowchart of an exemplary method 700 for processing a financial transaction involving the purchase of airline tickets from a travel agency or other third-party merchant. The method 700 is similar to the method 500 described above.
  • [0085]
    The method 700 commences when an account holder initiates a transaction with the merchant for the purchase of an airline ticket (step 702). The travel agency captures the transaction variables (the variables in a traditional authorization request and the ten listed above) for the transaction as received from the airline and the account holder (step 704) and transmits them to the financial institution - in almost all cases via the airline or a GDS—in a standard format with the request for authorization of the transaction (step 706).
  • [0086]
    The financial institution processes the received transaction variables against at least one fraud-risk model (step 708) and, in various embodiments, applies standard authorization decision-making criteria as well. The financial institution replies to the authorization request real-time with an approval, declination or call referral message based on outcome of the fraud-risk model and standard decisioning criteria (step 710). The travel agency then processes the transaction in accordance with the received reply (step 712), after which the process 700 ends.
  • [0087]
    The enhanced processes disclosed herein are an important tool that can be consistently implemented for all airline transactions in which the enhanced data (i.e., the additional transaction variables) is transmitted to a card issuer in the real-time authorizations request. Such data is already collected by airlines, travel agencies and GDS's for other purposes, and can be transmitted onwards to issuers with only minor adjustments to current software and without requiring the replacement of network hardware currently used in many systems.
  • [0088]
    Airlines that participate in providing this enhanced data will realize fewer fraudulent airline tickets charged back to them since the fraud models used have a higher probability of detecting and preventing fraudulent transactions than in existing systems. Airline ticket merchants will also spend less time serving fraudulent customers or investigating charge backs, resulting in reduced operational expenses. Additionally, the system makes it harder for a card holder that legitimately enters into a transaction from later claiming that the transaction was fraudulent. In this manner, the card issuer, card holder and airline vendors each benefit from the security provided by the disclosed processes.
  • [0089]
    The card issuer may secure the collected enhanced transaction data in a variety of known and effective manners so that card member information cannot be obtained or used by unauthorized third parties.
  • [0090]
    The disclosed enhancements to financial transaction processing have applicability to various types of transactions involving travel tickets (e.g., train tickets, cruise tickets, car rentals and the like) other than the specific examples involving airlines as described herein, as will be apparent to one of ordinary skill in the art. The risk values and overall ranges of acceptable risk values may be the same or different for different transaction types. The type of ticket purchased can be readily identified based on the merchant or the carrier code received with the transaction variables.
  • [0091]
    Although the best methodologies of the invention have been particularly described in the foregoing disclosure, it is to be understood that such descriptions have been provided for purposes of illustration only, and that other variations both in form and in detail can be made thereupon by those skilled in the art without departing from the spirit and scope thereof, which is defined first and foremost by the appended claims.
  • V. EXAMPLE IMPLEMENTATIONS
  • [0092]
    The present invention may be implemented using hardware, software or a combination thereof and may be implemented in one or more computer systems or other processing systems. However, the manipulations performed by the present invention were often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention. Rather, the operations are machine operations. Useful machines for performing the operation of the present invention include general purpose digital computers or similar devices.
  • [0093]
    In fact, in one embodiment, the invention is directed toward one or more computer systems capable of carrying out the functionality described herein. An example of a computer system 800 is shown in FIG. 8.
  • [0094]
    Computer system 800 includes one or more processors, such as processor 804. Processor 804 is connected to a communication infrastructure 806 (e.g., a communications bus, cross-over bar, or network). Various software embodiments are described in terms of this exemplary computer system. After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or architectures.
  • [0095]
    Computer system 800 can include a display interface 802 that forwards graphics, text, and other data from communication infrastructure 806 (or from a frame buffer not shown) for display on display unit 816.
  • [0096]
    Computer system 800 also includes a main memory 808, preferably random access memory (RAM), and may also include a secondary memory 810. Secondary memory 810 may include, for example, a hard disk drive 812 and/or a removable storage drive 814, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. Removable storage drive 814 reads from and/or writes to a removable storage unit 818 in a well known manner. Removable storage unit 818 represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 814. As will be appreciated, removable storage unit 818 includes a computer usable storage medium having stored therein computer software and/or data.
  • [0097]
    In alternative embodiments, secondary memory 810 may include other similar devices for allowing computer programs or other instructions to be loaded into computer system 800. Such devices may include, for example, a removable storage unit 822 and an interface 820. Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an erasable programmable read only memory (EPROM), or programmable read only memory (PROM)) and associated socket, and other removable storage units 822 and interfaces 820, which allow software and data to be transferred from removable storage unit 822 to computer system 800.
  • [0098]
    Computer system 800 may also include a communications interface 824. Communications interface 824 allows software and data to be transferred between computer system 800 and external devices. Examples of communications interface 824 may include a modem, a network interface (such as an Ethernet card), a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Software and data transferred via communications interface 824 are in the form of signals 828 which may be electronic, electromagnetic, optical or other signals capable of being received by communications interface 824. These signals 828 are provided to communications interface 824 via a communications path (e.g., channel) 826. This channel 826 carries signals 828 and may be implemented using wire or cable, fiber optics, a telephone line, a cellular link, an radio frequency (RF) link and other communications channels.
  • [0099]
    In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as removable storage drive 814, a hard disk installed in hard disk drive 812, and signals 828. These computer program products provide software to computer system 800. The invention is directed to such computer program products.
  • [0100]
    Computer programs (also referred to as computer control logic) are stored in main memory 808 and/or secondary memory 810. Computer programs may also be received via communications interface 824. Such computer programs, when executed, enable computer system 800 to perform the features of the present invention, as discussed herein. In particular, the computer programs, when executed, enable processor 804 to perform the features of the present invention. Accordingly, such computer programs represent controllers of computer system 800.
  • [0101]
    In an embodiment where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system 800 using removable storage drive 814, hard drive 812 or communications interface 824. The control logic (software), when executed by processor 804, causes processor 804 to perform the functions of the invention as described herein.
  • [0102]
    In another embodiment, the invention is implemented primarily in hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of the hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s).
  • [0103]
    In yet another embodiment, the invention is implemented using a combination of both hardware and software.
  • VI. CONCLUSION
  • [0104]
    While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope of the present invention. Thus, the present invention should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
  • [0105]
    In addition, it should be understood that the figures illustrated in the attachments, which highlight the functionality and advantages of the present invention, are presented for example purposes only. The architecture of the present invention is sufficiently flexible and configurable, such that it may be utilized (and navigated) in ways other than that shown in the accompanying figures.
  • [0106]
    Further, the purpose of the foregoing Abstract is to enable the U.S. Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the present invention in any way.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US4864557 *Feb 6, 1987Sep 5, 1989Northern Telecom LimitedAutomatic refresh of operating parameters in equipment with volatile storage
US5602933 *Mar 15, 1995Feb 11, 1997Scientific-Atlanta, Inc.Method and apparatus for verification of remotely accessed data
US5648647 *Dec 24, 1993Jul 15, 1997Seiler; Dieter G.Anti-fraud credit card dispatch system
US5696952 *Aug 3, 1995Dec 9, 1997Pontarelli; Mark C.Dynamic speed switching software for power management
US5768602 *Aug 4, 1995Jun 16, 1998Apple Computer, Inc.Sleep mode controller for power management
US5812668 *Jun 17, 1996Sep 22, 1998Verifone, Inc.System, method and article of manufacture for verifying the operation of a remote transaction clearance system utilizing a multichannel, extensible, flexible architecture
US5832283 *Mar 25, 1997Nov 3, 1998Intel CorporationMethod and apparatus for providing unattended on-demand availability of a computer system
US5850446 *Jun 17, 1996Dec 15, 1998Verifone, Inc.System, method and article of manufacture for virtual point of sale processing utilizing an extensible, flexible architecture
US5913202 *Jun 13, 1997Jun 15, 1999Fujitsu LimitedFinancial information intermediary system
US5949045 *Jul 3, 1997Sep 7, 1999At&T Corp.Micro-dynamic simulation of electronic cash transactions
US5996076 *Feb 19, 1997Nov 30, 1999Verifone, Inc.System, method and article of manufacture for secure digital certification of electronic commerce
US6023679 *Dec 19, 1996Feb 8, 2000Amadeus Global Travel Distribution LlcPre- and post-ticketed travel reservation information management system
US6029154 *Jul 28, 1997Feb 22, 2000Internet Commerce Services CorporationMethod and system for detecting fraud in a credit card transaction over the internet
US6160874 *Oct 21, 1997Dec 12, 2000Mci Communications CorporationValidation gateway
US6223289 *Apr 20, 1998Apr 24, 2001Sun Microsystems, Inc.Method and apparatus for session management and user authentication
US6256019 *Mar 30, 1999Jul 3, 2001Eremote, Inc.Methods of using a controller for controlling multi-user access to the functionality of consumer devices
US6347339 *Dec 1, 1998Feb 12, 2002Cisco Technology, Inc.Detecting an active network node using a login attempt
US6349335 *Jan 8, 1999Feb 19, 2002International Business Machines CorporationComputer system, program product and method for monitoring the operational status of a computer
US6374145 *Dec 14, 1998Apr 16, 2002Mark LignoulProximity sensor for screen saver and password delay
US6463474 *Jul 2, 1999Oct 8, 2002Cisco Technology, Inc.Local authentication of a client at a network device
US6484174 *Oct 31, 2000Nov 19, 2002Sun Microsystems, Inc.Method and apparatus for session management and user authentication
US6490624 *Jul 28, 1999Dec 3, 2002Entrust, Inc.Session management in a stateless network system
US6560322 *May 14, 1999May 6, 2003Minolta Co., Ltd.Centralized management unit receiving data from management unit of different communication methods
US6560711 *Aug 27, 2001May 6, 2003Paul GivenActivity sensing interface between a computer and an input peripheral
US6609154 *Oct 3, 2002Aug 19, 2003Cisco Technology, Inc.Local authentication of a client at a network device
US6615244 *Nov 28, 1998Sep 2, 2003Tara C SinghalInternet based archive system for personal computers
US6631405 *Oct 13, 1998Oct 7, 2003Atabok, Inc.Smart internet information delivery system which automatically detects and schedules data transmission based on status of client's CPU
US6658393 *Sep 15, 1999Dec 2, 2003Visa Internation Service AssociationFinancial risk prediction systems and methods therefor
US6732919 *Feb 19, 2002May 11, 2004Hewlett-Packard Development Company, L.P.System and method for using a multiple-use credit card
US6926203 *Feb 3, 2003Aug 9, 2005Richard P. SehrTravel system and methods utilizing multi-application traveler devices
US6999943 *Mar 10, 2000Feb 14, 2006Doublecredit.Com, Inc.Routing methods and systems for increasing payment transaction volume and profitability
US7024556 *Jun 2, 2000Apr 4, 20063Com CorporationDistributed system authentication
US7051002 *Jun 12, 2003May 23, 2006Cardinalcommerce CorporationUniversal merchant platform for payment authentication
US7100203 *Apr 19, 2000Aug 29, 2006Glenayre Electronics, Inc.Operating session reauthorization in a user-operated device
US7136835 *Sep 18, 2000Nov 14, 2006Orbis Patents Ltd.Credit card system and method
US7331518 *Apr 4, 2006Feb 19, 2008Factortrust, Inc.Transaction processing systems and methods
US7337210 *Nov 24, 2003Feb 26, 2008International Business Machines CorporationMethod and apparatus for determining availability of a user of an instant messaging application
US7640185 *Dec 31, 1998Dec 29, 2009Dresser, Inc.Dispensing system and method with radio frequency customer identification
US7660756 *May 8, 2002Feb 9, 2010Sony CorporationClient terminal device, storage medium product, bank server apparatus, information transmitting method, information transmitting program, and information transmitting/receiving program
US7904332 *Mar 8, 2011Deere & CompanyIntegrated financial processing system and method for facilitating an incentive program
US8214292 *Apr 1, 2009Jul 3, 2012American Express Travel Related Services Company, Inc.Post-authorization message for a financial transaction
US20020035548 *Apr 11, 2001Mar 21, 2002Hogan Edward J.Method and system for conducting secure payments over a computer network
US20020052852 *Oct 23, 2001May 2, 2002Bozeman William O.Universal positive pay match, authentication, authorization, settlement and clearing system
US20020091554 *Jul 20, 2001Jul 11, 2002Rodger BurrowsMethods and apparatus for electronically storing travel agents coupons
US20020138418 *Feb 25, 2002Sep 26, 2002Zarin Marjorie FaithMethod and apparatus for providing pre-existing and prospective customers with an immediately accessible account
US20020165954 *May 4, 2001Nov 7, 2002Kave EshghiSystem and method for monitoring browser event activities
US20020174065 *May 18, 2001Nov 21, 2002Chalice CowardMulti-currency electronic payment system and terminal emulator
US20020174335 *Nov 21, 2001Nov 21, 2002Junbiao ZhangIP-based AAA scheme for wireless LAN virtual operators
US20020188573 *Jan 8, 2002Dec 12, 2002Calhoon Gordon W.Universal electronic tagging for credit/debit transactions
US20030061157 *Jul 24, 2002Mar 27, 2003Hirka Jeffrey L.Multiple account advanced payment card and method of routing card transactions
US20030105707 *Nov 30, 2001Jun 5, 2003Yves AudebertFinancial risk management system and method
US20030120615 *Feb 4, 2000Jun 26, 2003B. Todd PattersonProcess and method for secure online transactions with calculated risk and against fraud
US20030167226 *Mar 4, 2002Sep 4, 2003First Data CorporationMethod and system for improving fraud prevention in connection with a newly opened credit account
US20030195963 *Apr 10, 2002Oct 16, 2003Yu SongSession preservation and migration among different browsers on different devices
US20030225687 *Jun 6, 2003Dec 4, 2003David LawrenceTravel related risk management clearinghouse
US20040059930 *Sep 19, 2002Mar 25, 2004Difalco Robert A.Computing environment and apparatuses with integrity based fail over
US20040167854 *Feb 21, 2003Aug 26, 2004Knowles W. JeffreySystem and method of currency conversion in financial transaction process
US20040232225 *Jul 14, 2004Nov 25, 2004American Express Travel Related Services Company,System and method for re-associating an account number to another transaction account
US20050108178 *Nov 17, 2003May 19, 2005Richard YorkOrder risk determination
US20050240522 *Jan 30, 2003Oct 27, 2005Mastercard International IncorporatedSystem and method for conducting secure payment transaction
US20060026076 *Aug 2, 2004Feb 2, 2006Raymond James MMethod and apparatus for providing an online ordering system of a retail establishment
US20060026689 *Nov 10, 2004Feb 2, 2006Research In Motion LimitedMethod and system for coordinating client and host security modules
US20060106738 *Nov 17, 2004May 18, 2006Paypal. Inc.Automatic address validation
US20060212387 *Mar 21, 2005Sep 21, 2006Genzen Ltd.Method and system for administrating funding of product development
US20070215698 *Mar 13, 2007Sep 20, 2007Perry Daniel DCredit card security system and method
US20070282674 *Feb 9, 2005Dec 6, 2007American Express Travel Related Services Company, Inc.System and Method Using Enhanced Authorization Data to Reduce Travel-Related
US20070284433 *Jun 8, 2006Dec 13, 2007American Express Travel Related Services Company, Inc.Method, system, and computer program product for customer-level data verification
US20080275821 *Jun 28, 2008Nov 6, 2008American Express Travel Related Services Company, Inc.Systems and methods for risk triggering values
US20080314977 *Sep 5, 2008Dec 25, 2008American Express Travel Related Services Company, Inc.Method, System, and Computer Program Product for Customer-Level Data Verification
US20090313134 *Apr 30, 2009Dec 17, 2009Patrick FaithRecovery of transaction information
US20100100484 *Dec 28, 2009Apr 22, 2010Loc NguyenProduct level payment network acquired transaction authorization
US20100257068 *Apr 1, 2009Oct 7, 2010American Express Travel Related Services Co. Inc.Authorization Request for Financial Transactions
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7757943 *Jul 20, 2010Metavante CorporationCombined payment/access-control instrument
US7784687Aug 31, 2010Dynamics Inc.Payment cards and devices with displays, chips, RFIDS, magnetic emulators, magnetic decoders, and other components
US7793851May 9, 2006Sep 14, 2010Dynamics Inc.Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card
US7828220Oct 30, 2007Nov 9, 2010Dynamics Inc.Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card
US7931195Oct 29, 2007Apr 26, 2011Dynamics Inc.Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card
US7954705Jun 7, 2011Dynamics Inc.Dynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card
US8011577Dec 19, 2008Sep 6, 2011Dynamics Inc.Payment cards and devices with gift card, global integration, and magnetic stripe reader communication functionality
US8020775Dec 19, 2008Sep 20, 2011Dynamics Inc.Payment cards and devices with enhanced magnetic emulators
US8066191Nov 29, 2011Dynamics Inc.Cards and assemblies with user interfaces
US8074877Dec 19, 2008Dec 13, 2011Dynamics Inc.Systems and methods for programmable payment cards and devices with loyalty-based payment applications
US8172148Feb 22, 2010May 8, 2012Dynamics Inc.Cards and assemblies with user interfaces
US8226001Jul 24, 2012Fiteq, Inc.Method for broadcasting a magnetic stripe data packet from an electronic smart card
US8231063Jul 31, 2012Privasys Inc.Electronic card and methods for making same
US8282007Feb 22, 2010Oct 9, 2012Dynamics Inc.Laminated cards with manual input interfaces
US8286876Jul 20, 2011Oct 16, 2012Dynamics Inc.Cards and devices with magnetic emulators and magnetic reader read-head detectors
US8286889Apr 23, 2012Oct 16, 2012Privasys, IncElectronic financial transaction cards and methods
US8302871Apr 16, 2012Nov 6, 2012Privasys, IncMethod for conducting a transaction between a magnetic stripe reader and an electronic card
US8302872Jul 20, 2011Nov 6, 2012Dynamics Inc.Advanced dynamic credit cards
US8317103Nov 27, 2012FiTeqMethod for broadcasting a magnetic stripe data packet from an electronic smart card
US8322623Dec 4, 2012Dynamics Inc.Systems and methods for advanced card printing
US8348172Jan 8, 2013Dynamics Inc.Systems and methods for detection mechanisms for magnetic cards and devices
US8360332Jan 29, 2013PrivasysElectronic card
US8382000Feb 26, 2013Dynamics Inc.Payment cards and devices with enhanced magnetic emulators
US8393545Mar 12, 2013Dynamics Inc.Cards deployed with inactivated products for activation
US8393546Mar 12, 2013Dynamics Inc.Games, prizes, and entertainment for powered cards and devices
US8413892Apr 9, 2013Dynamics Inc.Payment cards and devices with displays, chips, RFIDs, magnetic emulators, magnetic encoders, and other components
US8424773Apr 23, 2013Dynamics Inc.Payment cards and devices with enhanced magnetic emulators
US8459548Jul 20, 2011Jun 11, 2013Dynamics Inc.Payment cards and devices with gift card, global integration, and magnetic stripe reader communication functionality
US8480002Apr 16, 2012Jul 9, 2013Mark PoidomaniConducting a transaction with an electronic card
US8485437Jul 20, 2011Jul 16, 2013Dynamics Inc.Systems and methods for programmable payment cards and devices with loyalty-based payment applications
US8485446Mar 28, 2012Jul 16, 2013Dynamics Inc.Shielded magnetic stripe for magnetic cards and devices
US8500019Apr 16, 2012Aug 6, 2013Mark PoidomaniElectronic cards and methods for making same
US8511574Aug 17, 2010Aug 20, 2013Dynamics Inc.Advanced loyalty applications for powered cards and devices
US8517276Dec 19, 2008Aug 27, 2013Dynamics Inc.Cards and devices with multifunction magnetic emulators and methods for using same
US8523059Oct 20, 2010Sep 3, 2013Dynamics Inc.Advanced payment options for powered cards and devices
US8540165Apr 3, 2012Sep 24, 2013Privasys, Inc.Laminated electronic card assembly
US8554631 *Dec 13, 2010Oct 8, 2013Jpmorgan Chase Bank, N.A.Method and system for determining point of sale authorization
US8561894Oct 20, 2011Oct 22, 2013Dynamics Inc.Powered cards and devices designed, programmed, and deployed from a kiosk
US8567679Jan 23, 2012Oct 29, 2013Dynamics Inc.Cards and devices with embedded holograms
US8573503Sep 25, 2012Nov 5, 2013Dynamics Inc.Systems and methods for detection mechanisms for magnetic cards and devices
US8579203Nov 23, 2011Nov 12, 2013Dynamics Inc.Electronic magnetic recorded media emulators in magnetic card devices
US8590796Feb 22, 2010Nov 26, 2013Dynamics Inc.Cards having dynamic magnetic stripe communication devices fabricated from multiple boards
US8602312Feb 16, 2011Dec 10, 2013Dynamics Inc.Systems and methods for drive circuits for dynamic magnetic stripe communications devices
US8608083Jul 20, 2011Dec 17, 2013Dynamics Inc.Cards and devices with magnetic emulators with zoning control and advanced interiors
US8620798Sep 8, 2010Dec 31, 2013Visa International Service AssociationSystem and method using predicted consumer behavior to reduce use of transaction risk analysis and transaction denials
US8622309Apr 5, 2010Jan 7, 2014Dynamics Inc.Payment cards and devices with budgets, parental controls, and virtual accounts
US8628022May 23, 2012Jan 14, 2014Dynamics Inc.Systems and methods for sensor mechanisms for magnetic cards and devices
US8650120Mar 2, 2012Feb 11, 2014American Express Travel Related Services Company, Inc.Systems and methods for enhanced authorization fraud mitigation
US8668143Jul 20, 2011Mar 11, 2014Dynamics Inc.Payment cards and devices with gift card, global integration, and magnetic stripe reader communication functionality
US8684267Apr 3, 2012Apr 1, 2014PrivasysMethod for broadcasting a magnetic stripe data packet from an electronic smart card
US8719167Mar 2, 2012May 6, 2014American Express Travel Related Services Company, Inc.Systems and methods for enhanced authorization fraud mitigation
US8727219Oct 12, 2010May 20, 2014Dynamics Inc.Magnetic stripe track signal having multiple communications channels
US8733638Jul 20, 2011May 27, 2014Dynamics Inc.Payment cards and devices with displays, chips, RFIDs, magnetic emulators, magentic decoders, and other components
US8746579Jul 1, 2013Jun 10, 2014Dynamics Inc.Systems and methods for detection mechanisms for magnetic cards and devices
US8757483Feb 8, 2013Jun 24, 2014Dynamics Inc.Cards deployed with inactivated products for activation
US8757499Sep 10, 2012Jun 24, 2014Dynamics Inc.Laminated cards with manual input interfaces
US8762239Jan 12, 2009Jun 24, 2014Visa U.S.A. Inc.Non-financial transactions in a financial transaction network
US8814050Mar 26, 2013Aug 26, 2014Dynamics Inc.Advanced payment options for powered cards and devices
US8827153Jul 17, 2012Sep 9, 2014Dynamics Inc.Systems and methods for waveform generation for dynamic magnetic stripe communications devices
US8875999Apr 29, 2013Nov 4, 2014Dynamics Inc.Payment cards and devices with gift card, global integration, and magnetic stripe reader communication functionality
US8881989Jul 20, 2011Nov 11, 2014Dynamics Inc.Cards and devices with magnetic emulators with zoning control and advanced interiors
US8888009Feb 13, 2013Nov 18, 2014Dynamics Inc.Systems and methods for extended stripe mechanisms for magnetic cards and devices
US8924279May 5, 2010Dec 30, 2014Visa U.S.A. Inc.Risk assessment rule set application for fraud prevention
US8931703Mar 16, 2010Jan 13, 2015Dynamics Inc.Payment cards and devices for displaying barcodes
US8944333Sep 18, 2013Feb 3, 2015Dynamics Inc.Cards and devices with embedded holograms
US8960545Nov 16, 2012Feb 24, 2015Dynamics Inc.Data modification for magnetic cards and devices
US8966065Oct 4, 2012Feb 24, 2015Iii Holdings 1, LlcMethod and apparatus for managing an interactive network session
US8973824Dec 19, 2008Mar 10, 2015Dynamics Inc.Cards and devices with magnetic emulators with zoning control and advanced interiors
US9004368Jul 20, 2011Apr 14, 2015Dynamics Inc.Payment cards and devices with enhanced magnetic emulators
US9010630Dec 19, 2008Apr 21, 2015Dynamics Inc.Systems and methods for programmable payment cards and devices with loyalty-based payment applications
US9010644Nov 4, 2013Apr 21, 2015Dynamics Inc.Dynamic magnetic stripe communications device with stepped magnetic material for magnetic cards and devices
US9010647Feb 19, 2013Apr 21, 2015Dynamics Inc.Multiple sensor detector systems and detection methods of magnetic cards and devices
US9033218May 14, 2013May 19, 2015Dynamics Inc.Cards, devices, systems, methods and dynamic security codes
US9053398Aug 12, 2011Jun 9, 2015Dynamics Inc.Passive detection mechanisms for magnetic cards and devices
US9053399Apr 3, 2012Jun 9, 2015PrivasysMethod for broadcasting a magnetic stripe data packet from an electronic smart card
US9064195Feb 19, 2013Jun 23, 2015Dynamics Inc.Multiple layer card circuit boards
US9064255May 9, 2014Jun 23, 2015Dynamics Inc.Cards deployed with inactivated products for activation
US9111278Oct 7, 2013Aug 18, 2015Jpmorgan Chase Bank, N.A.Method and system for determining point of sale authorization
US9152996 *Mar 21, 2014Oct 6, 2015KnowVera, LLCMethods and system for visually designing trading strategies and execution thereof
US9195985Jun 8, 2006Nov 24, 2015Iii Holdings 1, LlcMethod, system, and computer program product for customer-level data verification
US9292843Jul 21, 2014Mar 22, 2016Dynamics Inc.Advanced payment options for powered cards and devices
US9306666Sep 24, 2010Apr 5, 2016Dynamics Inc.Programming protocols for powered cards and devices
US9329619Mar 2, 2010May 3, 2016Dynamics Inc.Cards with power management
US9349089Dec 10, 2013May 24, 2016Dynamics Inc.Systems and methods for sensor mechanisms for magnetic cards and devices
US9361569Dec 19, 2008Jun 7, 2016Dynamics, Inc.Cards with serial magnetic emulators
US9373069Oct 25, 2013Jun 21, 2016Dynamics Inc.Systems and methods for drive circuits for dynamic magnetic stripe communications devices
US9384438Jul 20, 2011Jul 5, 2016Dynamics, Inc.Cards with serial magnetic emulators
US9386078 *May 30, 2014Jul 5, 2016Ca, Inc.Controlling application programming interface transactions based on content of earlier transactions
US9396465Jul 22, 2009Jul 19, 2016Visa International Service AssociationApparatus including data bearing medium for reducing fraud in payment transactions using a black list
US20040210519 *May 12, 2004Oct 21, 2004Carole OppenlanderSystem and method for authorizing transactions
US20070284433 *Jun 8, 2006Dec 13, 2007American Express Travel Related Services Company, Inc.Method, system, and computer program product for customer-level data verification
US20080054065 *Aug 29, 2006Mar 6, 2008Metavante CorporationCombined payment/access-control instrument
US20080302869 *Oct 30, 2007Dec 11, 2008Mullen Jeffrey DDynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card
US20080302876 *Oct 29, 2007Dec 11, 2008Mullen Jeffrey DDynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card
US20080314977 *Sep 5, 2008Dec 25, 2008American Express Travel Related Services Company, Inc.Method, System, and Computer Program Product for Customer-Level Data Verification
US20090308921 *Oct 30, 2007Dec 17, 2009Mullen Jeffrey DDynamic credit card with magnetic stripe and embedded encoder and methods for using the same to provide a copy-proof credit card
US20090313134 *Apr 30, 2009Dec 17, 2009Patrick FaithRecovery of transaction information
US20100179891 *Jul 15, 2010Visa U.S.A. Inc.Non-financial transactions in a financial transaction network
US20100287099 *May 5, 2010Nov 11, 2010Frederick LiuRisk assessment rule set application for fraud prevention
US20110016041 *Jan 20, 2011Scragg Ernest MTriggering Fraud Rules for Financial Transactions
US20110016052 *Jan 20, 2011Scragg Ernest MEvent Tracking and Velocity Fraud Rules for Financial Transactions
US20110022483 *Jan 27, 2011Ayman HammadApparatus including data bearing medium for reducing fraud in payment transactions using a black list
US20110022517 *Jan 27, 2011Ayman HammadApparatus including data bearing medium for authorizing a payment transaction using seasoned data
US20110022518 *Jan 27, 2011Ayman HammadApparatus including data bearing medium for seasoning a device using data obtained from multiple transaction environments
US20110066493 *Sep 8, 2010Mar 17, 2011Faith Patrick LSystem and Method Using Predicted Consumer Behavior to Reduce Use of Transaction Risk Analysis and Transaction Denials
US20120054101 *Sep 1, 2010Mar 1, 2012American Express Travel Related Services Company, Inc.Application program interface based fraud mitigation
US20130013512 *Jan 10, 2013American Express Travel Related Services Company, Inc.Software development kit based fraud mitigation
US20130103577 *Oct 23, 2012Apr 25, 2013Fiserv, Inc.Systems and methods for optimizing financial transactions
US20140058767 *Mar 15, 2013Feb 27, 2014Mastercard International IncorporatedReservation realization scoring system and method
US20140067672 *Aug 31, 2012Mar 6, 2014Fiserv, Inc.Systems and methods for performing financial transactions
US20140297503 *Mar 21, 2014Oct 2, 2014Joseph MurphyMethods and system for visually designing trading strategies and execution thereof
US20150142663 *Jan 29, 2015May 21, 2015Fiserv, Inc.Systems and methods for optimizing financial transactions
US20150178733 *Dec 23, 2013Jun 25, 2015International Business Machines CorporationPayment card fraud protection
USD643063Aug 9, 2011Dynamics Inc.Interactive electronic card with display
USD651237Dec 27, 2011Dynamics Inc.Interactive electronic card with display
USD651238Dec 27, 2011Dynamics Inc.Interactive electronic card with display
USD651644Jan 3, 2012Dynamics Inc.Interactive electronic card with display
USD652075Jan 10, 2012Dynamics Inc.Multiple button interactive electronic card
USD652076Jan 10, 2012Dynamics Inc.Multiple button interactive electronic card with display
USD652448Jan 17, 2012Dynamics Inc.Multiple button interactive electronic card
USD652449Jan 17, 2012Dynamics Inc.Multiple button interactive electronic card
USD652450Jan 17, 2012Dynamics Inc.Multiple button interactive electronic card
USD652867Jan 24, 2012Dynamics Inc.Multiple button interactive electronic card
USD653288Jan 31, 2012Dynamics Inc.Multiple button interactive electronic card
USD665022Aug 7, 2012Dynamics Inc.Multiple button interactive electronic card with light source
USD665447Aug 14, 2012Dynamics Inc.Multiple button interactive electronic card with light source and display
USD666241Aug 28, 2012Dynamics Inc.Multiple button interactive electronic card with light source
USD670329Nov 6, 2012Dynamics Inc.Interactive display card
USD670330Nov 6, 2012Dynamics Inc.Interactive card
USD670331Nov 6, 2012Dynamics Inc.Interactive display card
USD670332Nov 6, 2012Dynamics Inc.Interactive card
USD670759Nov 13, 2012Dynamics Inc.Multiple button interactive electronic card with light sources
USD672389Dec 11, 2012Dynamics Inc.Multiple button interactive electronic card with light sources
USD673606Jan 1, 2013Dynamics Inc.Interactive electronic card with display and buttons
USD674013Jan 8, 2013Dynamics Inc.Multiple button interactive electronic card with light sources
USD675256Jan 29, 2013Dynamics Inc.Interactive electronic card with display and button
USD676487Feb 19, 2013Dynamics Inc.Interactive electronic card with display and buttons
USD676904Feb 26, 2013Dynamics Inc.Interactive display card
USD687094Jul 2, 2010Jul 30, 2013Dynamics Inc.Multiple button interactive electronic card with light sources
USD687095Aug 27, 2012Jul 30, 2013Dynamics Inc.Interactive electronic card with buttons
USD687487Aug 27, 2012Aug 6, 2013Dynamics Inc.Interactive electronic card with display and button
USD687488Aug 27, 2012Aug 6, 2013Dynamics Inc.Interactive electronic card with buttons
USD687489Aug 27, 2012Aug 6, 2013Dynamics Inc.Interactive electronic card with buttons
USD687490Aug 27, 2012Aug 6, 2013Dynamics Inc.Interactive electronic card with display and button
USD687887Aug 27, 2012Aug 13, 2013Dynamics Inc.Interactive electronic card with buttons
USD688744Aug 27, 2012Aug 27, 2013Dynamics Inc.Interactive electronic card with display and button
USD692053Aug 27, 2012Oct 22, 2013Dynamics Inc.Interactive electronic card with display and button
USD694322Aug 27, 2012Nov 26, 2013Dynamics Inc.Interactive electronic card with display buttons
USD695636Aug 27, 2012Dec 17, 2013Dynamics Inc.Interactive electronic card with display and buttons
USD729869Aug 27, 2012May 19, 2015Dynamics Inc.Interactive electronic card with display and button
USD729870Aug 27, 2012May 19, 2015Dynamics Inc.Interactive electronic card with display and button
USD729871Aug 27, 2012May 19, 2015Dynamics Inc.Interactive electronic card with display and buttons
USD730438Aug 27, 2012May 26, 2015Dynamics Inc.Interactive electronic card with display and button
USD730439Aug 27, 2012May 26, 2015Dynamics Inc.Interactive electronic card with buttons
USD737373Sep 10, 2013Aug 25, 2015Dynamics Inc.Interactive electronic card with contact connector
USD750166Mar 4, 2013Feb 23, 2016Dynamics Inc.Interactive electronic card with display and buttons
USD750167Mar 4, 2013Feb 23, 2016Dynamics Inc.Interactive electronic card with buttons
USD750168Mar 4, 2013Feb 23, 2016Dynamics Inc.Interactive electronic card with display and button
USD751639Mar 4, 2013Mar 15, 2016Dynamics Inc.Interactive electronic card with display and button
USD751640Mar 4, 2013Mar 15, 2016Dynamics Inc.Interactive electronic card with display and button
USD764584Mar 4, 2013Aug 23, 2016Dynamics Inc.Interactive electronic card with buttons
Classifications
U.S. Classification705/44
International ClassificationG06Q10/00, G06Q50/00, G07B15/02, G06Q20/00, G06Q40/00
Cooperative ClassificationG06Q20/40, G06Q20/4016, G06Q20/12, G06Q10/02, G06Q30/06, G06Q20/24
European ClassificationG06Q20/12, G06Q10/02, G06Q30/06, G06Q20/24, G06Q20/4016, G06Q20/40
Legal Events
DateCodeEventDescription
Mar 15, 2006ASAssignment
Owner name: AMERICAN EXPRESS TRAVEL RELATED SERVICES COMPANY,
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BIFFLE, JANET L.;DOMENICA, DANIELLE;DUGGAL, CHANDERPREET;AND OTHERS;REEL/FRAME:017306/0898;SIGNING DATES FROM 20060209 TO 20060222
Apr 21, 2014ASAssignment
Owner name: III HOLDINGS 1, LLC, DELAWARE
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:AMERICAN EXPRESS TRAVEL RELATED SERVICES COMPANY, INC.;REEL/FRAME:032722/0746
Effective date: 20140324