US8074879B2 - System and method for securing a credit account - Google Patents

System and method for securing a credit account Download PDF

Info

Publication number
US8074879B2
US8074879B2 US12/803,219 US80321910A US8074879B2 US 8074879 B2 US8074879 B2 US 8074879B2 US 80321910 A US80321910 A US 80321910A US 8074879 B2 US8074879 B2 US 8074879B2
Authority
US
United States
Prior art keywords
account
holder
tar
activation
card
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
US12/803,219
Other versions
US20100268647A1 (en
Inventor
David N. Harris
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Harris Intellectual Property LP
Original Assignee
Harris Intellectual Property LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Harris Intellectual Property LP filed Critical Harris Intellectual Property LP
Priority to US12/803,219 priority Critical patent/US8074879B2/en
Publication of US20100268647A1 publication Critical patent/US20100268647A1/en
Priority to US13/300,142 priority patent/US20120118983A1/en
Application granted granted Critical
Publication of US8074879B2 publication Critical patent/US8074879B2/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/24Credit schemes, i.e. "pay after"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes

Definitions

  • This invention relates generally to electronic commerce, and more particularly to a system and method for providing secure electronic transactions. Even more particularly, the present invention relates a system and method for facilitating verification of an electronic purchase by an account holder.
  • the primary means of payment for most consumer electronic purchases is a credit card.
  • the credit card represents a prearranged credit account of the card-holder.
  • the card-holder makes an electronic purchase with a merchant, using a credit card.
  • the merchant submits the purchase request (including transmitting the entire credit card number) to the credit card company for purchase authorization.
  • the credit card company then authorizes or denies the credit card transaction with the merchant. If the purchase is approved the prearranged credit account is debited in the amount of the purchase.
  • Credit cards offer many advantages to card-holders. For example, persons having access to a credit card spend less time at the bank, as well as, balancing checking and savings accounts. In addition, a credit card eliminates the need to carry large sums of cash. Further, purchase approval is automated when using a credit card while purchase approval with check or money order is delayed. Therefore, when making a purchase by phone or mail order, using a credit card eliminates the delay associated with sending payment through the mail.
  • Some commercial accounts offer debit cards that face the same, if not increased, security risks as credit cards.
  • Debit cards are similar to credit cards, however to complete a debit transaction, the card-holder's Personal Identification Number (PIN) must be given in addition to the card number at the time of purchase.
  • PIN Personal Identification Number
  • the debit card draws funds from the account (typically a checking account) that it is linked to.
  • the PIN given with debit card transactions is the same PIN used to access (e.g. via ATM machine or phone) the account that the debit card is linked to. If a purchase transaction made using a debit card is intercepted and used fraudulently, the thief has the ability to both make purchases using the debit card number and PIN, as well as, draw funds directly from the associated debit account.
  • U.S. Pat. No. 6,012,144 (Pickett) describes a method of maintaining Internet credit card transaction security by splitting the credit card number into two pieces and storing each piece on a separate data storage device of one or more server computers. The card-holder decides which portions of the credit card number will be sent to each storage device and then secures several processing codes (passwords). The processing codes are later obtained from the card-holder by an automated telephone call so that the purchase may be verified. There are several disadvantages to this methodology. First, Pickett's method is extremely time consuming for the card-holder because the full credit card number is not transmitted to the merchant in its entirety.
  • the card-holder must parse the credit card number and calculate a slicing code.
  • the card-holder must remember the slicing code, which may be different for each transaction, in order to verify the transaction.
  • the burden of providing the security software falls on the merchant, which may or may not be willing to provide such a system. Thus, no security is provided if the card-holder wishes to purchase from a merchant without such a system.
  • U.S. Pat. No. 5,903,721 (Sixtus) describes an alternate method of providing improved credit card transaction security.
  • the method of Sixtus involves a card-holder making a purchase over the Internet.
  • IP Internet Protocol
  • ISP Internet Service Providers
  • Some Internet Service Providers use dynamic IP addressing, wherein a temporary IP address is assigned as the user logs onto the ISP's network.
  • a card-holder having an Internet Service Provider that utilizes dynamic IP addressing is unable to use the transaction security system taught by Sixtus.
  • U.S. Pat. No. 5,991,738 teaches a method utilizing encryption software.
  • a card-holder wishing to purchase an item from a merchant employing Ogram's methodology, downloads encryption software from the merchant computer.
  • the encryption software encodes any sensitive information before transmission to the merchant.
  • One disadvantage of Ogram's methodology is the lack of a secured purchase verification process with the card-holder.
  • the employed encryption techniques can be intercepted and deciphered during transmission.
  • What is needed is a system and method for providing safe and secure credit card transaction processing. What is also needed is a system and method for providing safe and secure credit card transactions that are transparent to merchants. What is also needed is a system and method for facilitating card-holder verification of credit card transactions and providing prompt notice of each attempted use of a card-holder's credit card.
  • the present invention overcomes the problems associated with the prior art by providing a system and method for providing safe and secure credit card transaction processing which is transparent to the merchant.
  • the invention facilitates card-holder verification of each credit card transaction prior to transmitting an approval to the merchant, and provides prompt notice of each attempted use of the credit card to the account-holder.
  • a computer system for processing a commercial transaction between an account-holder and a merchant, comprising a processing unit to execute data and code, and a memory device for storing data and code.
  • the stored and executed code includes a merchant communications module operative to receive a transaction approval request, including an entire account number, an account-holder communications module operative to facilitate a separate connection with the account-holder for verifying the received transaction approval request, and an authorization module responsive to the transaction approval request and operative to transmit an approval to the merchant only if the transaction approval request is verified by the account-holder.
  • the authorization module includes an interactive verification module, responsive to the receipt of a transaction approval request and operative to initiate a connection with the account-holder.
  • the computer system further includes a network interface, and the interactive verification module is operative to transmit an electronic message to the account-holder via the network interface, and is further operative to verify the transaction approval request upon receipt of a reply to the transmitted electronic message.
  • the computer system further comprises a telecommunications device and the interactive verification module is operative to place an automated telephone call to the account-holder, recite a portion of the transaction approval request to the account-holder, and receive verification instructions from the account holder.
  • the interactive verification module is operative to require an authentication code before reciting a portion of the transaction approval request.
  • the interactive verification module waits for the account-holder to initiate communication with the system.
  • the system initiates communication with the account-holder to verify pending transaction approval requests.
  • the authorization module responsive to instructions from the account holder, can selectively disable the verification process by automatically verifying subsequent transaction approval requests without further input form the account holder.
  • the authorization module includes a master verification module that automatically disclaims a transaction approval request if the account holder has not verified the transaction approval request prior to the lapse of a predetermined time period.
  • the master verification module is further operative to transmit notice to the account holder when the transaction approval request is disclaimed.
  • a transaction approval request comprises a verification request from a third party financial institution, and the authorization module is operative to transmit indicia of verification to the third party financial institution.
  • a method for providing safe and secure commercial transactions between an account-holder and a merchant.
  • the method includes receiving a transaction approval request including a full account number identifying the account-holders account, electronically verifying the transaction approval request with the account-holder via a separate communication from the merchant, and transmitting an approval to the merchant only if the transaction approval request is verified by the account-holder.
  • the step of verifying the transaction approval request with the account-holder includes prompting the account-holder to verify the transaction approval request.
  • prompting the account-holder includes sending an electronic message.
  • the step of verifying the transaction approval request includes receiving a reply to the electronic message.
  • prompting the account-holder includes placing an automated telephone call to the account-holder, establishing a connection with the account-holder, reciting at least a portion of the transaction approval request, and receiving verification instructions from the account-holder.
  • the account holder is authenticated before the recitation of at least a portion of the transaction approval request.
  • An alternate method includes waiting for the account-holder to initiate the verification process by communicating with the computer system.
  • verification is initiated by the account-holder over a network or a telephone connection and includes, receiving a connection request from the account-holder via a network or telecommunications device, establishing a connection with the account-holder, authenticating the account-holder, transmitting at least a portion of the transaction approval request to the account-holder, and receiving verification instructions from the account-holder with respect to the transaction approval request.
  • the verification process can be selectively enabled or disabled by the account holder.
  • the step of electronically verifying the transaction approval request includes disclaiming the transaction approval request if the account holder does not verify the transaction approval request within a predetermined time interval.
  • notice is transmitted to the account-holder when the transaction approval request has been disclaimed.
  • the step of receiving a transaction approval request from the merchant comprises receiving a verification request from a third party financial institution that received the transaction approval request from the merchant.
  • the step of transmitting an approval to the merchant comprises transmitting indicia of verification to the third-party financial institution.
  • a computer system includes a processing unit for processing data and code, and a memory device for storing the data and code.
  • the data includes at least one pre-verification criteria associated with the account-holder.
  • the code includes a merchant communications module for receiving a transaction approval request from the merchant, and an authorization module.
  • the authorization module compares the transaction approval request with the pre-verification criteria, and automatically verifies the transaction approval request if the pre-verification criteria are met, thereby eliminating the need to obtain direct verification of the transaction approval request from the account-holder prior to completing the approval process.
  • the pre-verification criteria includes a plurality of pre-verification criteria associated with the account-holder, and the transaction approval request is verified if any one of the pre-verification criteria are satisfied.
  • the transaction approval request is not automatically verified unless all of the plurality of pre-verification criteria are satisfied.
  • useful pre-verification criteria include, but are not limited to, merchant identifiers, transaction amounts (e.g., purchase prices), transaction dates, transaction times, or any other criteria that an account-holder might find convenient.
  • the code further includes a card-holder communications module and/or an interactive verification module that facilitates modification of the pre-verification criteria by the account-holder.
  • the pre-verification criteria are initially set so that no transaction approval request can be automatically verified until the pre-verification criteria are modified by the account-holder.
  • the initial pre-verification criteria can be determined by the account-holder (e.g., when the account is opened).
  • a system and method for selectively activating and deactivating the account-holder's account is also disclosed.
  • a computer system includes a processing unit for processing data and code, and a memory device for storing the data and code.
  • the data includes activation data accessible to the account-holder that is indicative of the activation status of the account-holder's account.
  • the code includes a merchant communications module for receiving a transaction approval request from the merchant, and an authorization module.
  • the authorization module approves or denies the transaction approval request based at least in part on the activation data and the associated activation status of the account, thereby permitting the account-holder to temporarily activate and deactivate their account as desired.
  • the activation data includes at least one activation condition (e.g., an activation date and time), and the authorization module is operative to approve the transaction approval request if the transaction approval request satisfies the activation condition (e.g., the purchase date and time is after the activation date and time).
  • the activation data also includes at least one deactivation condition (e.g., a deactivation date and time), and the authorization module will approve the transaction approval request only if the transaction approval request satisfies the activation condition and does not satisfy the deactivation condition (e.g., the purchase date and time falls before the deactivation date and time).
  • the account-holder can specify automatic activation or deactivation criteria which the authorization module can implement automatically.
  • One possible deactivation criteria is a predetermined number of transaction approval requests (e.g., one) received by the computer system, and then the authorization module is operative to automatically deactivate the account-holder's account.
  • the authorization module includes an interactive activation module operative to establish a connection with the account-holder, authenticate the account-holder, present the current activation status of the account-holder's account to the account holder, and receive instructions from the account holder to modify the activation data.
  • the connection between the account-holder and the interactive activation module can be established, for example, by telephone.
  • the interactive activation module is operative to store instructions (e.g., the activation or deactivation date and time) received from the account-holder.
  • a method for facilitating commercial transactions between an account-holder and a merchant including the steps of receiving deactivation instructions from the account-holder to temporarily deactivate their account, receiving a transaction approval request from a merchant, determining whether the account holder has temporarily deactivated the account, and denying the transaction approval request if the account is temporarily deactivated.
  • FIG. 1 is a block diagram of an internetwork between, a card-holder, a merchant, a credit card company, and a third party verification company according to the present invention
  • FIG. 2 is a block diagram showing a server of the credit card company of FIG. 1 , to include a working memory and an authorization module within said working memory;
  • FIG. 3 is a block diagram detailing the authorization module shown in FIG. 2 ;
  • FIG. 4 is a block diagram showing exemplary data structures for storing transaction approval requests records in the Credit Approval Request Queue of FIG. 2 ;
  • FIG. 5 is a block diagram showing exemplary data structures for storing card-holder data in the Card-holder List module of FIG. 2 ;
  • FIG. 6 is a block diagram showing exemplary data structures for storing transaction records in the Purchase History module of FIG. 2 ;
  • FIG. 7 is a flowchart summarizing one method of providing safe and secure electronic transactions according to the present invention.
  • FIG. 8 is a flowchart summarizing one method of performing the fourth step (verification disabled?) of the method of FIG. 7 ;
  • FIG. 9 is a flowchart summarizing one method of performing the fifth step (card-holder verification) of the method of FIG. 7 ;
  • FIG. 10 is a flowchart summarizing an alternate method of performing the fifth step (card-holder verification) of the method of FIG. 7 .
  • FIG. 11 is a block diagram showing an alternate server including pre-verification criteria and an alternate authorization module used to pre-verify transactions according to the present invention
  • FIG. 12 is a block diagram detailing the alternate authorization module of FIG. 11 ;
  • FIG. 13 is a block diagram showing exemplary data structures for storing the pre-verification criteria of FIG. 11 ;
  • FIG. 14 is a flowchart summarizing another method of providing safe and secure electronic transactions according to the present invention.
  • FIG. 15 is a flowchart summarizing one method of performing the fifth step (pre-verification criteria met?) of the method of FIG. 14 ;
  • FIG. 15A is a flowchart summarizing an alternate method of performing the fifth step (pre-verification criteria met?) of the method of FIG. 14 ;
  • FIG. 16 is a flowchart summarizing one method for a card-holder to modify pre-verification criteria associated with said card-holder's account
  • FIG. 17 is a block diagram showing an alternate server including an activation database used to store activation and deactivation data according to the present invention
  • FIG. 18 is a block diagram detailing the alternate authorization module of FIG. 17 ;
  • FIG. 19 is a block diagram showing an exemplary data structure for storing the activation data in the activation database of FIG. 17 ;
  • FIG. 20 is a flowchart summarizing yet another method of processing electronic transactions according to the present invention.
  • FIG. 21 is a flowchart summarizing one method for allowing a card-holder to modify the activation status of the card-holder's account
  • FIG. 22 is a flowchart summarizing one method for selectively activating/deactivating an account according to the present invention.
  • FIG. 23 shows a credit card having security indicia thereon indicating that the associated card-holder's account is protected by one or more security features.
  • the present invention overcomes the problems associated with the prior art, by providing a novel system and method of providing safe and secure electronic transactions by verifying each electronic transaction with the account-holder.
  • numerous specific details are set forth (e.g. verification processed by credit card company, verification initiated by card-holder, etc.) in order to provide a thorough understanding of the invention. Those skilled in the art will recognize, however, that the invention may be practiced apart from these specific details.
  • details of well-known electronic commerce practices e.g. electronic credit request/approval processes, computer operating systems, communication software, etc.
  • FIG. 1 is a block diagram showing a system 100 including a card-holder 102 , a merchant 104 , a credit card company 106 , and a third-party verification company 108 , each connected to an internetwork 110 (e.g., the Internet) by physical network media 112 ( 1 - 4 ) (e.g. telephone line, coaxial cable, etc.).
  • physical network media 112 e.g. telephone line, coaxial cable, etc.
  • Card-holder 102 , merchant 104 , credit card company 106 , and verification company 108 are also in communication via another physical network media 114 (e.g. a telephone line).
  • Card-holder 102 possesses a credit card with a number identifying an account provided by credit card company 106 .
  • Merchant 104 offers goods or services which can be purchased via internetwork 110 by card-holder 102 using the credit card number.
  • Card-holder 102 makes an electronic purchase request from merchant 104 , by providing the entire credit card number. This purchase may be made over internetwork 110 , physical network media 114 , or even in person. Responsive to receipt of the purchase request, merchant 104 submits a transaction approval request (TAR) to credit card company 106 .
  • TAR transaction approval request
  • the TAR then undergoes a two-part authorization before an approval or denial is issued to merchant 104 .
  • the purchase request undergoes standard credit approval by credit card company 106 .
  • the purchase request is verified with card-holder 102 either by credit card company 106 , or by verification company 108 . Verification is executed either over internetwork 110 or physical network media 114 .
  • an approval is transmitted to merchant 104 via physical network media 114 or internetwork 110 :
  • a credit card facilitates electronic commerce.
  • the present invention may be used in conjunction with any type of account (e.g. debit cards) to facilitate safe and secure electronic transactions that include transmission of an account number.
  • credit card company 106 executes the verification process.
  • the verification process may optionally be performed by third party verification company 108 .
  • credit card company 106 transmits a verification request to verification company 108 .
  • Verification company 108 then verifies the transaction request with card-holder 102 , and transmits indicia of verification (indicating whether the transaction request has been verified, disclaimed, etc.) back to credit card company 106 .
  • FIG. 2 is a block diagram of a server 200 (e.g. an HTTP Internet Server) connected to internetwork 110 via physical network media 112 ( 3 ).
  • server 200 is a transaction server of credit card company 106 , for processing credit card transactions for credit card company 106 .
  • Server 200 includes a processing unit (PU) 202 , a network interface 204 , a system bus 206 , non-volatile memory 208 , at least one input/output (I/O) controller 210 , a system clock 212 , a telecommunications device 214 , and a working memory 216 .
  • PU 202 executes data and code contained in working memory 216 to cause server 200 to carry out its intended functions (e.g. processing credit card transactions).
  • System bus 206 facilitates intercommunication between the various components of server 200 .
  • Server 200 communicates over Internetwork 110 via network interface 204 .
  • Network interface 204 e.g. an Ethernet adapter card
  • Network interface 204 transmits data packets onto and receives data packets from internetwork 110 , thus allowing server 200 to communicate with card-holder 102 and merchant 104 via internetwork 110 .
  • Non-volatile memory 208 e.g. read-only memory, or one or more hard disk drives
  • I/O controller 210 manages connections for user interface devices (not shown) for a system administrator of server 200 . I/O devices typically include a keyboard, mouse, monitor, printer, and other such devices that facilitate communications between server 200 and an administrator.
  • Server 200 further includes a system clock 212 that maintains proper date and time, and provides date and time data upon request.
  • Server 200 further includes a telecommunications device 214 (e.g. a modem, or telephone) for establishing either a data or voice connection between a remote system or party and server 200 .
  • a telecommunications device 214 e.g. a modem, or telephone
  • remote systems include a computer owned by card-holder 102 , merchant 104 , or verification company 108 .
  • a voice connection with card-holder 102 is used to verify pending TARs.
  • Working memory 216 (e.g. random access memory) provides dynamic memory to server 200 , and includes executable code (e.g. an operating system 218 ), which is loaded into working memory 216 during system start-up. Operating system 218 facilitates control and execution of all other modules loaded into working memory 216 .
  • Working memory 216 further includes a Credit Approval Request Queue (CARQ) 220 , a card-holder list module 222 , a card-holder communications module 224 , an authorization module 226 , a verification pending queue (VPQ) 228 , a purchase history module 230 , and a merchant communications module 232 .
  • CARQ Credit Approval Request Queue
  • VPQ verification pending queue
  • Each of the foregoing modules and queues are initialized and loaded into working memory 216 at startup from non-volatile memory 208 using methods well known to those skilled in the art.
  • the foregoing modules and queues can be loaded into working memory 216 from alternate mass data storage devices including, but not limited to, a CD-ROM, a tape, or a drive having high capacity removable data storage disks (e.g. Iomega's JazTM or ZipTM drives).
  • Authorization module 226 controls and coordinates the approval and verification of TARs. As described above, in the alternate embodiment where verification is processed by third-party verification company 108 , authorization module 226 is operative to transmit a request for verification to verification company 108 and receive indicia of verification from verification company 108 .
  • the transmitted request for verification would include information related to the purchase request such as a product description, purchase price, merchant's name, or any other information helpful to identify the transaction to the card-holder for verification.
  • the received indicia of verification would include, for example, a code indicating that the particular transaction has been verified or disclaimed by the card-holder.
  • authorization module responsive to instructions given by card-holder 102 , is further operative to selectively disable the verification process (e.g., automatically verify every transaction or transactions for a particular merchant). Instructions to disable the verification process would generally be initiated by card-holder 102 over a secure network (e.g. via telephone, or mail).
  • a secure network e.g. via telephone, or mail.
  • Card-holder Communications module 224 manages communications between server 200 and card-holder 102 , via internetwork 110 or physical network media 114 .
  • Card-holder list module 222 is a database for storing personal and account information for current customers of credit card company 106 , including card-holder 102 . Those skilled in the art will understand that card-holder list module 222 would typically be a very large file.
  • card-holder list module 222 is shown in memory 216 , it should be understood that the entire customer files would likely be stored in a mass data storage system such as non-volatile memory 208 , with portions of the entire list being swapped in and out of card-holder list 222 as necessary.
  • Credit Approval Request Queue (CARQ) 220 provides storage for pending TARs awaiting conventional credit approval by authorization module 226 .
  • Merchant communications module 232 periodically polls network interface 204 and telecommunications device 214 to determine whether there are any incoming TARs from merchant 104 , and transfers any such requests to CARQ 220 .
  • Verification Pending Queue (VPQ) 228 provides storage for pending TARs awaiting verification by card-holder 102 .
  • Authorization module 226 transfers TARs from CARQ 220 to VPQ 228 after the TAR is confirmed as corresponding to a valid account and passes conventional credit approval. TARs remain in VPQ 228 until verified, denied, or until the lapse of a predetermined time period.
  • a record of the TAR is transferred to purchase history module 230 .
  • Purchase history module 230 stores information about previous account activity, for a predetermined time period (e.g. a period of thirty days). Upon lapse of the predetermined time period, at which point a written record (e.g. a bill, an e-bill, etc.) of the transaction has been conveyed to card-holder 102 , each expired TAR is transferred from working memory 216 to a more permanent storage media (e.g., magnetic tape).
  • a predetermined time period e.g. a period of thirty days.
  • FIG. 3 shows a block diagram of authorization module 226 to include a credit approval module 302 , a master verification module 304 , an interactive verification module 306 , and a merchant response module 308 .
  • Credit approval module 302 executes conventional credit approval for each TAR contained in CARQ 220 by means well known to those skilled in the art.
  • Master verification module 304 coordinates the authorization and verification processes, and is responsible for overall control of authorization module 226 .
  • Interactive verification module 306 carries out verification with card-holder 102 .
  • Merchant response module 308 initiates final communication with merchant 104 by transmitting either a transaction approval or a transaction denial.
  • FIG. 4 shows an example of a credit approval request data structure 400 suitable for use with a particular embodiment of the present invention.
  • data structure 400 as a linked-list of records 402 ( 1 - n ).
  • Each of records 402 ( 1 - n ) represents a pending TAR and includes a full credit card number 404 , a purchase description 406 , a purchase price 408 , merchant information 410 , purchase date and time information 412 ; a verified flag 414 , a verification initiated flag 415 , an approved flag 416 , a denied flag 418 , and a pointer 420 .
  • Full credit card number 404 , purchase description 406 , purchase price 408 , merchant information 410 , and purchase date and time information 412 are received by server 200 from merchant 104 with the TAR.
  • Verified flag 414 , approved flag 416 , and denied flag 418 are used to indicate the status of each record 402 in the authorization process, as will be explained in greater detail below.
  • Pointer 420 indicates the memory address of the next record 402 (+1) in the list.
  • the last record 402 ( n ) includes an end of list value 422 , that indicates that record 402 ( n ) is the last record in the list.
  • Verified flag 414 , verification initiated flag 415 , approved flag 416 , and denied flag 418 are single bit flags indicating the status of the respective record.
  • Verification initiated flag 415 indicates whether server 200 has initiated the verification process with card-holder 102 .
  • FIG. 5 shows an example of a card-holder data structure 500 suitable for storing card-holder data in card-holder list module 222 .
  • data structure 500 is a linked list of records 502 ( 1 - n ), with one record 502 for each valid credit account extended by credit card company 106 .
  • Each record 502 includes a full credit card number 504 issued to an associated card-holder, a personal identification number (PIN) 506 , card-holder information 508 , contact information 510 , a credit limit 512 , a verification requested flag 514 , an initiate verification flag 516 , and a pointer 518 .
  • PIN personal identification number
  • PIN 506 is a code used to authenticate card-holder 102 during the verification process or to allow card-holder 102 to set preference settings (e.g., verification requested flag 514 , initiate verification flag 516 , etc.).
  • Card-holder information 508 includes, but is not limited to, such personal information as card-holder's first and last names, date of birth, social security number, and/or address.
  • Contact information 510 comprises information necessary for communications with the associated card-holder, especially for TAR verification. Contact information 510 may include, but is not limited to, a telephone number, a pager number, or an e-mail address.
  • Credit limit 512 indicates the prearranged credit limit for the associated card-holder.
  • Verification requested flag 514 allows card-holder 102 to selectively disable the verification process by for example, automatically verifying subsequent TARs without further input from card-holder 102 .
  • verification requested flag 514 is a single bit flag, wherein a value of 1 indicates that the verification process should be carried out, and a value of 0 indicates that the card-holder wishes to suspend the verification process.
  • Single bit initiate verification flag 516 indicates whether card-holder 102 wishes server 200 to initiate the verification process, or if server 200 should wait for user 102 to initiate the verification process. If initiate verification flag 516 has a value of 1, interactive verification module 306 initiates the verification process with the associated card-holder (e.g. e-mail, automated telephone call, etc.).
  • initiate verification flag 516 has a value of 0, the associated card-holder must initiate verification (e.g., place telephone call to server 200 , log onto server 200 via internetwork 110 , etc.).
  • Pointer 518 indicates the start address of the next record 502 in card-holder data structure 500 .
  • End of list indicator 520 indicates that record 502 ( n ) is last record in card-holder data structure 500 .
  • FIG. 6 shows an example of a purchase history data structure 606 , suitable for use with a particular embodiment of the present invention.
  • Purchase history data structure 600 is a linked-list of records 602 ( 1 - n ), each of which includes a full credit card number 604 , purchase information 606 , a purchase price 608 , merchant information 610 , a verification date and time 612 , and a pointer 614 .
  • Credit card number 604 identifies the particular transaction with the associated card-holder.
  • Purchase information 606 includes information (e.g., product description) that will help identify the transaction to the card-holder.
  • Purchase price 608 indicates the cost associated with the purchase.
  • Merchant information 610 identifies the merchant that submitted the TAR.
  • Verification date and time 612 indicates when, if at all, the associated card-holder verified the TAR.
  • Pointer 614 indicates the address of the next record. 602 in data structure 600 .
  • End of list indicator 616 ( n ) indicates that record 602 ( n ) is the last record in purchase history data structure 600 .
  • the process begins when card-holder 102 submits an order for goods or services to merchant 104 , and uses a credit card number assigned by credit card company 106 as the means of payment. Merchant 104 then transmits a transaction approval request to credit card company 106 including the credit card number supplied by card-holder 102 , a description of the purchase, the purchase price, the purchase date and time, and information identifying merchant 104 .
  • Merchant communications module 232 ( FIG. 2 ) periodically polls network interface 204 and telecommunications device 214 for any incoming TARs from merchant 104 .
  • merchant communications module 232 scans card-holder list 222 to determine whether there is a record 502 ( FIG. 5 ) with a credit card number 504 matching the credit card number provided with the TAR. If there is no such record in card-holder list 222 , then merchant communications module 232 transmits a denial to merchant 104 .
  • merchant communications module 232 If, however, the submitted credit card number matches a credit card number 502 ( x ) in card-holder list 222 , then merchant communications module 232 generates a credit approval request record 402 using the information provided in the TAR to create fields 404 , 406 , 408 , 410 , and 412 , and stores the new record in CARQ 220 . Initially, verified flag 414 , approved flag 416 , and denied flag 418 are all set equal to zero.
  • Master verification module 304 of authorization module 226 periodically scans CARQ 220 for pending TARs. Any pending TARs are processed based on the status of flags 414 , 416 , and 418 . For example, if approved flag 416 ( 1 ) of the first TAR record 402 ( 1 ) is set equal to zero, then master verification module 304 calls credit approval module 302 to perform the conventional credit approval of TAR 402 ( 1 ).
  • Credit approval module 302 performs the conventional credit approval process by means well know to those skilled in the art.
  • Conventional credit approval typically comprises, but is not restricted to, credit approval module 302 comparing purchase price 408 ( 1 ) and the associated card-holder's 102 ( x ) existing balance to card-holder's 102 ( x ) credit limit 512 ( x ). If the sum of purchase price 408 ( 1 ) and card-holder's 102 ( x ) existing balance is less than or equal to credit limit 512 ( x ), then credit approval module 302 sets approved flag 416 ( 1 ) equal to 1.
  • credit approval module 302 sets denied flag 418 ( 1 ) equal to 1.
  • master verification module 304 again checks flags 414 ( 1 ), 416 ( 1 ), and 418 ( 1 ) to determine the appropriate action. Note that verified flag 414 ( 1 ) should still be equal to 0, because the TAR record 402 ( 1 ) has not yet been processed for verification. If denied flag 418 ( 1 ) is set equal to 1, then master verification module 304 calls merchant response module 308 to transmit a denial to merchant 104 , removes record 402 ( 1 ) from CARQ 220 , and writes a record 602 of the denied transaction in purchase history module 230 .
  • master authorization module 304 retrieves verification requested flag 514 ( x ) to determine whether card-holder 102 ( x ) has selectively disabled the verification process. If verification requested flag 514 ( x ) is set equal to 0, then master verification module 304 automatically sets verified flag 416 ( 1 ) equal to 1, and leaves TAR record 402 ( 1 ) in CARQ 220 . If verification requested flag 514 ( x ) is equal to 0, then master authorization module 304 transfers TAR record 402 ( 1 ) to VPQ 228 to await verification by card-holder 102 ( x ).
  • Master verification module 304 also scans VPQ 228 periodically (e.g., after each scan of CARQ 220 ) to process any pending TAR records 402 in VPQ 228 for verification. If verified flag 414 of a particular record 402 is set equal to 1, it indicates that the TAR corresponding to record 402 has been verified by card-holder 102 ( x ). The first time TAR record 402 ( 1 ) is scanned in VPQ 228 , verified flag 414 ( 1 ) and verification initiated flag 415 ( 1 ) should both be set equal to 0.
  • Master verification module 304 then retrieves record 502 ( x ) from card-holder list 222 to determine whether server 200 should initiate the verification process (e.g., send an e-mail to user 102 ( x ), page user 102 ( x ), place a call to user 102 ( x ), etc.), or whether server 200 should wait for user 102 ( x ) to initiate the verification process. If initiate verification flag 516 ( x ) is set equal to 0, then master verification module sets verification initiated flag 415 ( 1 ) equal to 1. Setting the. verification initiated flag equal to 1, even though server 200 has not initiated the verification process, eliminates the need to check verification requested flag 516 ( x ) each time VPQ 228 is scanned by master verification module 304 .
  • master verification module 304 determines that initiate verification flag 516 ( x ) had been set equal to 1, then master verification module 304 calls interactive verification module 306 to initiate the verification process with card-holder 102 ( x ). Interactive verification module 306 then initiates the verification process, sets verification initiated flag 415 ( 1 ) equal to 1, and returns control to master verification module 304 , which retrieves the next record 402 in VPQ 228 for processing.
  • Master verification module 304 also periodically calls interactive verification module 306 to conduct the actual verification of TARs pending in VPQ 228 .
  • Verification of pending TARs is accomplished by establishing a connection with card-holder 102 ( x ) separate from the connection with merchant 104 over which the TAR was originally received, providing additional security compared to prior art electronic transactions such as ATM card purchases.
  • the phrase “establishing a connection” is understood to be interpreted in its broadest possible sense to include, but not be limited to, establishing a network connection, establishing a data connection over a modem, establishing a voice connection over a telecommunications device, sending or receiving e-mail, etc.
  • card-holder 102 could verify pending transaction approval requests by logging onto server 200 via internetwork 110 , making a direct modem connection with server 200 via network 114 , dialing into server 200 via a telephone, sending an e-mail to server 200 , responding to an e-mail from server 200 , or any other form of electronic communication.
  • system 200 can be modified to allow account-holder 102 to pre-approve certain charges.
  • card-holder list 222 could include a field for pre-approved merchants (or any other desirable criteria).
  • authorization module 226 can compare the merchant identification to the associated card-holder's pre-approved merchant's list, and, if the merchant appears on the list, automatically verify the TAR.
  • Card-holder 102 could access system 200 to modify such pre-approved lists via internetwork 110 , network 114 , or any other means known for updating customer data.
  • interactive verification module 306 communicates with card-holders 102 via card-holder communications module 224 and network interface 204 and telecommunications device 214 .
  • Card-holder communications module 224 periodically polls network interface 204 and telecommunications device 214 for incoming connection requests (e.g., e-mail, network connection, phone call, etc.) and establishes any such connections.
  • connection requests e.g., e-mail, network connection, phone call, etc.
  • Such communications programs e.g., e-mail software, network protocols, etc.
  • Interactive verification module 306 polls card-holder communications module 224 to determine whether there are any established connections with card-holders 102 , and processes each established connection. Assuming card-holder 102 ( x ) has established a connection with server 200 , the verification of pending TARs proceeds as follows.
  • the connection request should identify card-holder 102 ( x ) (e.g., by credit card number), and optionally includes an authentication code (e.g., a personal identification number (PIN)) to authenticate card-holder 102 ( x ).
  • Interactive verification module 306 uses the identification information in the connection request to retrieve record 502 ( x ) corresponding to card-holder 102 ( x ) from card-holder list 222 . Then, interactive verification module 306 compares the PIN provided in the connection request with PIN 506 ( x ) to authenticate the card-holder. If the PINs do not match, the connection is terminated. If the PINs match, the verification process proceeds.
  • connection with card-holder 102 ( x ) need not be terminated the first time an incorrect PIN is received.
  • conventional network security systems typically allow a predetermined number of incorrect entries prior to disconnecting a user.
  • security measures such as stalling the user attempting to access the system, while a trace of the connection is initiated, can be employed.
  • interactive verification module 306 scans verification pending queue 228 for all TARs with a credit card number 402 matching credit card number 504 ( x ) of card-holder 102 ( x ). Each matching TAR is then presented to card-holder 102 ( x ) to be verified disclaimed. If card-holder 102 ( x ) verifies a particular transaction, then interactive verification module 306 sets the verified flag 414 of that TAR record to equal 1. If card-holder 102 ( x ) disclaims the transaction (e.g., because the purchase was unauthorized), then interactive verification module 306 sets the denied flag 418 of the TAR record to equal 1.
  • card-holder 102 ( x ) There are many possible ways to present pending TARs to card-holder 102 ( x ) and to receive verification instructions from card-holder 102 ( x ), depending on the type of connection established with server 200 . For example, if card-holder 102 establishes an HTTP connection with server 200 , then pending TARs could be presented in the form of an Internet web page. Alternatively, if the connection between card-holder 102 ( x ) and server 200 is a telephone voice connection, then pending TARs can be presented to card-holder 102 ( x ) via an automated text to speech system, such as are well known in the art. Card-holder 102 ( x ) could then transmit verification instructions via voice or keypad commands (e.g.
  • connection request is in the form of an e-mail response
  • the e-mail response can include verification instructions (e.g., in the subject line of the e-mail) that can be automatically processed by interactive verification module 306 .
  • verification instructions e.g., in the subject line of the e-mail
  • control is returned to master verification module 304 , which scans VPQ 228 and transfers any TAR records whose verified flag 414 or denied flag 418 has been set equal to 1. Additionally, master verification module 304 scans all records 402 remaining in VPQ 228 , and compares the value in the purchase date and time field 412 with the date and time provided by system clock 212 . If the resulting time difference exceeds a predetermined time interval (e.g., 24 hours), then master verification module 304 sets the denied flag 418 of the associated record 402 equal to 1 and transfers the record 402 to CARQ 220 .
  • a predetermined time interval e.g., 24 hours
  • master verification module 304 will locate any TAR records that have both verified flag 414 and approved flag 416 set equal to 1, call merchant response module to transmit an approval to the merchant identified in field 410 of the record, remove the record from CARQ 220 , and write a record 602 into purchase history data 230 to document the completed transaction. Records whose denied flags 418 are found to be set equal to 1 are handled similarly, except that a denial is transmitted to the identified merchant instead of an approval.
  • FIG. 7 is a flowchart summarizing a method 700 of processing a TAR in accordance with the present invention.
  • merchant communications module 232 receives a TAR including a full credit card number from a merchant 104 , generates a TAR record 402 , and writes TAR record 402 into CARQ 220 .
  • authorization module 226 subjects TAR record 402 to a conventional credit approval process, and sets approved flag 416 or denied flag 418 to indicate whether the requested credit is approved or denied.
  • authorization module 226 determines from flags 416 and 418 whether the requested credit has been approved or denied.
  • authorization module 226 determines whether card-holder 102 has selectively disabled the verification process. If the verification process has not been selectively disabled, then in a fifth step 710 authorization module 226 verifies the transaction with card-holder 102 . Then, in a sixth step 712 authorization module 226 determines whether the TAR has been verified by card-holder 102 . If the TAR has been verified, then in a seventh step 714 merchant communications module 232 transmits a transaction approval to merchant 104 . Next, in an eighth step 716 , authorization module 226 determines whether there are any more TAR records in CARQ 220 . If there are no more records in CARQ 220 , then method 700 ends.
  • authorization module 226 determines that the credit request has been denied, then method 700 proceeds to a ninth step 718 where merchant communications module 232 transmits a denial to merchant 104 . If in fourth step 708 , authorization module 226 determines that the verification process has been selectively disabled, then method 700 proceeds to seventh step 714 where merchant communications module 232 transmits an approval to merchant 104 . If in sixth step 712 , authorization module 226 determines that the TAR has not been verified by card-holder 102 , then method 700 proceeds to ninth step 718 where merchant communications module 232 transmits a denial to merchant 104 . Finally, if in eighth step 716 , authorization module 226 determines that there are more pending TAR records in CARQ 220 , then method 700 returns to first step 702 to process the next record in CARQ 220 .
  • FIG. 8 is a flowchart summarizing a method 800 for implementing the selective disabling of the TAR verification process according to a particular embodiment of the present invention.
  • authorization module 226 determines if CARQ 220 is empty. If CARQ 220 is not empty, then in a second step 804 authorization module 226 reads the first TAR record in CARQ 220 . Then, in a third step 806 , authorization module 226 associates the first TAR with a card-holder 102 and retrieves a card-holder record 502 corresponding to the particular card-holder from card-holder list 222 . In a fourth step 808 , authorization module 226 determines from card-holder record 502 whether card-holder 102 has requested that TARs be verified with card-holder 102 prior to transmitting an approval to merchant 104 .
  • authorization module 226 transfers the associated TAR record to VPQ 228 .
  • authorization module 226 determines whether the last record in CARQ 220 has been processed, and if so then method 800 ends.
  • authorization module 226 determines that verification is not required (i.e., disabled), then in a seventh step 814 verified flag 414 is automatically set to 1 to indicate that the TAR has been verified. If in sixth step 812 , authorization module 226 determines that the last record in CARQ 220 has not been processed, then method 800 returns to second step 804 to begin processing the next record in CARQ 220 .
  • FIG. 9 is a flowchart summarizing a particular method 900 for verifying a TAR in accordance with the present invention.
  • authorization module 226 determines whether VPQ 228 is empty. If VPQ 228 is not empty, then in a second step 904 authorization module 226 reads the first TAR record 402 in VPQ 228 .
  • authorization module 226 determines if the last record in VPQ 228 has been processed. If all the records in VPQ have been processed, then in a tenth step 920 authorization module 226 performs the card-holder verification process for any TAR records remaining in VPQ 228 .
  • authorization module 226 determines that VPQ 228 is empty, then method 900 ends. If, in third step 906 , authorization module 226 determines that the TAR record being processed has been denied, then method 900 proceeds directly to eighth step 916 . Similarly, if in fourth step 908 authorization module 226 determines that the TAR record being processed has been previously verified, then method 900 proceeds to eighth step 916 .
  • authorization module 226 determines that the predetermined time interval has not lapsed, then method 900 proceeds to eighth step 916 . If, in ninth step 918 , authorization module 226 determines that there are additional TAR records in VPQ 228 , then method 900 returns to second step 904 to process the next TAR record.
  • FIG. 10 is a flowchart summarizing a method 1000 of verifying pending TARs with card-holder 102 .
  • card-holder communications module 224 polls network interface 204 and telecommunications device 214 to determine whether there are any card-holder communication requests (e.g. a telephone call, network connection requests, etc.) from card-holder 102 , and if so then in second step 1004 , authorization module 226 calls interactive verification module 306 to establish a connection with card-holder 102 .
  • interactive verification module 306 authenticates card-holder 102 (e.g. requires an authentication code), and in a fourth step 1008 searches VPQ 228 for records related to card-holder 102 .
  • interactive verification module 306 presents at least a portion of a pending TAR (sufficient for card-holder recognition) to card-holder 102 .
  • interactive verification module polls the established connection to determine whether card-holder 102 has transmitted instructions to verify the presented TAR. If there are no instructions from card-holder 102 to verify the TAR, then in a seventh step 1014 interactive verification module 306 determines whether card-holder 102 has transmitted instructions to disclaim the TAR. If there are no instructions to disclaim the TAR, then in an eighth step 1016 interactive verification module 306 determines whether the last pending TAR associated with card-holder 102 has been processed.
  • step 1018 interactive verification module 306 terminates the established connection with card-holder 102 , and method 1000 returns to step 1002 to determine whether there are any communication requests from other card-holders. If, in first step 1002 , card-holder communications module 224 determines that there are no card-holder communication requests, then method 1000 ends.
  • interactive verification module 306 receives instructions from card-holder 102 to verify the presented TAR, then in a tenth step 1020 interactive verification module 306 sets verified flag 414 of the TAR record 402 to a value of 1, indicating the TAR has been verified. Then, method 1000 returns to fifth step 1010 .
  • interactive verification module 306 receives instructions from card-holder 102 to disclaim the presented TAR, then in an eleventh step 1022 interactive verification module 306 sets denied flag 418 of the TAR record 402 to a value of 1, indicating the TAR has been disclaimed. Then, method 1000 returns to fifth step 1010 .
  • step 1016 If, in eighth step 1016 , interactive verification module 306 determines that the last pending request for the particular card-holder has not been processed, then method 1000 returns to fifth step 1010 to process the next pending TAR for the particular card-holder.
  • FIG. 11 is a block diagram of an alternate server 200 A.
  • Server 200 A functions similar to server 200 of FIG. 2 , except that server 200 A includes pre-verification criteria (PVC) 1102 and an alternate authorization module 226 A.
  • PVC pre-verification criteria
  • Authorization module 226 A controls and coordinates the approval and verification of TARs, and, in addition to the functions performed by authorization module 226 , uses pre-verification criteria 1102 to automatically verify any TAR meeting the requirements of pre-verification criteria 1102 .
  • the use of pre-verification criteria 1102 facilitates accelerated verification of TARs, because authorization module 226 A does not need to wait for direct verification by card-holder 102 .
  • Pre-verification criteria 1102 is a database that includes individualized pre-verification criteria for each current customer of credit card company 106 , including card-holder 102 .
  • Pre-verification criteria typically include, but are not limited to, merchant identifiers, a maximum purchase price, and specified dates between which purchases can be automatically verified by authorization module 226 A.
  • pre-verification criteria module 1102 would typically be a very large file. Therefore, while pre-verification criteria module 1102 is shown in memory 216 , it should be understood that the entire customer files would likely be stored in a mass data storage system such as non-volatile memory 208 , with portions of the entire list being swapped in and out of pre-verification criteria module 1102 as necessary.
  • pre-verification criteria are determined by credit card company 106 at the time the credit card account is opened, so that no purchases can be verified by the pre-verification criteria.
  • the pre-verification criteria may be determined by card-holder 102 when the account is opened (e.g. on their credit card application). In either case, card-holder 102 can modify their pre-verification criteria over a secure network (e.g. via telephone or modem access), as will be described below.
  • FIG. 12 shows a block diagram of authorization module 226 A to include a credit approval module 302 , an alternate master verification module 304 A, an interactive verification module 306 , and a merchant response module 308 .
  • Credit approval module 302 executes conventional credit approval for each TAR contained in CARQ 220 by means well known to those skilled in the art.
  • Master verification module 304 A coordinates the authorization and verification processes, including verification using pre-verification criteria, and is responsible for overall control of authorization module 226 A.
  • Interactive verification module 306 A carries out verification with card-holder 102 , and coordinates modification of pre-verification criteria by card-holder 102 .
  • Merchant response module 308 initiates final communication with merchant 104 by transmitting either a transaction approval or a transaction denial.
  • FIG. 13 shows an example of a pre-verification criteria data structure 1300 suitable for use with a particular embodiment of the present invention.
  • data structure 1300 as a linked-list of records 1302 ( 1 - n ).
  • Each record 1302 ( 1 - n ) represents pre-verification criteria associated with a particular card-holder, and includes a full credit card number 1304 , a first merchant identifier 1306 ( 1 ), an rth merchant identifier 1306 ( r ), a maximum pre-verified purchase price 1310 , a pair of pre-verification dates 1312 , miscellaneous pre-verification criteria 1314 , and a pointer 1316 .
  • Full credit card number 1304 associates a pre-verification criteria record 1302 ( a ) with a specific card-holder 102 ( a ).
  • Merchant identifiers 1306 ( 1 - r ) each contain information similar to merchant information 410 contained in each TAR.
  • Merchant identifiers 1306 ( 1 - r ) each identify a certain pre-verified merchants for each card-holder.
  • TARs received from pre-verified merchants are automatically verified by authorization module 226 A.
  • Pre-verified purchase price 1310 sets a maximum purchase price for automatic verification. Any TAR including a purchase price 408 that is lower than pre-verified purchase price 1310 is automatically verified by authorization module 226 A.
  • Pre-verification dates 1312 include a begin date and an end date.
  • Any TAR including a purchase date 412 that falls between the begin date and end date of pre-verification dates 1314 is automatically verified by authorization module 226 A.
  • Miscellaneous pre-verification criteria 1314 are included to illustrate that particular criteria other than those specifically listed above can be used to cause authorization module 226 A to verify a TAR.
  • card-holder 102 may want to specify particular hours of the day when purchases should be automatically verified.
  • miscellaneous pre-verification criteria 1314 would include a start time and a stop time.
  • Pointer 1316 ( a ) indicates the memory address of the next record 1316 (a+1) in the list.
  • the last record 1302 ( n ) includes an end of list value 1318 that indicates that record 1302 ( n ) is the last record in the list.
  • FIG. 14 is a flowchart summarizing one method 800 A for implementing the automatic verification of a TAR using pre-verification criteria according to a particular embodiment of the present invention.
  • authorization module 226 A determines if CARQ 220 is empty. If CARQ is empty, then method 800 A ends. If CARQ 220 is not empty, then in a second step 804 , authorization module 226 A reads the first TAR record in CARQ 220 . Then, in a third step 806 , authorization module 226 A associates the first TAR with a card-holder 102 and retrieves a card-holder record 502 corresponding to the particular card-holder from card-holder list 222 .
  • authorization module 226 A determines from card-holder record 502 whether card-holder 102 has requested that TARs be verified with card-holder 102 prior to transmitting an approval to merchant 104 . If it is determined that card-holder verification is requested (i.e., enabled), then in a fifth step 809 authorization module 226 A determines if the pre-verification criteria associated with card-holder 102 have been satisfied. If in fifth step 809 the pre-verification requirements are not satisfied, then in a sixth step 810 authorization module 226 A transfers the associated TAR record to VPQ 228 . Next, in a seventh step 812 , authorization module 226 A determines whether the last record in CARQ 220 has been processed, and if so then method 800 A ends.
  • authorization module 226 A determines that verification is not required (i.e., disabled)
  • method 800 A proceeds to an eighth step 814 where authorization module 226 A sets verified flag 414 to 1 to indicate that the TAR has been verified.
  • authorization module 226 A sets verified flag 414 to 1. If in seventh step 812 , authorization module 226 A determines that the last record in CARQ 220 has not been processed, then method 800 A returns to second step 804 to begin processing the next record in CARQ 220 .
  • FIG. 15 is a flowchart showing one method 1500 of performing fifth step 809 (determining whether the pre-verification criteria are met) of the method of FIG. 14 .
  • authorization module 226 A retrieves record 1302 ( a ) of pre-verification criteria 1102 associated with the card-holder (e.g. card-holder 102 ( a )) identified in the TAR.
  • authorization module 226 A determines whether one of merchant identifiers 1306 ( a )( 1 - r ) of record 1302 ( a ) corresponds with the merchant information 410 contained in the TAR.
  • authorization module 226 A determines whether the purchase price 408 of the TAR is below the maximum pre-verified purchase price 1310 ( a ). If purchase price 408 of the TAR is not below the maximum pre-verified purchase price 1310 ( a ), then in a fourth step 1508 authorization module 226 A determines if purchase date 412 of the TAR falls within pre-verified dates 1312 ( a ).
  • authorization module 226 A determines whether miscellaneous pre-verification criteria 1314 ( a ) are satisfied. If miscellaneous pre-verification criteria 1314 are not satisfied or the card-holder has not specified any miscellaneous criteria 1314 , then method 1500 determines that the pre-verification criteria have not been met.
  • authorization module 226 A determines that one of merchant identifiers 1306 ( 1 - r ) of record 1302 ( a ) corresponds with the merchant information 410 contained in the TAR, then method 1500 determines that the pre-verification criteria have been met. If in third step 1506 , authorization module 226 A determines that purchase price 408 is below pre-verified purchase price 1310 ( a ), then method 1500 determines that the pre-verification criteria have been met. Similarly, if in fourth step 1508 , authorization module 226 A determines that purchase date 412 of the TAR falls within pre-verified purchase dates 1312 ( a ), then method 1500 determines that the pre-verification criteria have been met.
  • authorization module 226 A determines the miscellaneous pre-verification criteria 1314 ( a ) are met by the pending TAR, then method 1500 determines that the pre-verification criteria have been met.
  • method 1500 will determine that a particular TAR meets the pre-verification criteria, and is therefore automatically verified, if any one of the various criteria (e.g., the maximum purchase price) are met.
  • FIG. 15A is a flowchart showing an alternate method 1500 A of performing step 809 of the method of FIG. 14 , wherein all of the pre-verification criteria must be met before a TAR is automatically verified.
  • authorization module 226 A retrieves record 1302 ( a ) of pre-verification criteria 1102 associated with the card-holder (e.g. card-holder 102 ( a )) identified in the TAR being processed by authorization module 226 A.
  • authorization module 226 A determines whether one of merchant identifiers 1306 ( 1 - r ) of record 1302 ( a ) corresponds with the merchant information 410 contained in the TAR.
  • method 1500 A determines that the pre-verification criteria are not met by the pending TAR, and method 1500 A ends. However, if one of merchant identifiers 1306 ( 1 - r ) of record 1302 ( a ) do correspond to the merchant identified in the TAR, then method 1500 A proceeds to a third step 1506 A wherein authorization module 226 A determines whether the purchase price 408 of the TAR is below the maximum pre-verified purchase price 1310 ( a ).
  • method 1500 A determines that the pre-verification criteria are not met, and the method ends. If purchase price 408 of the TAR is below the maximum pre-verified purchase price 1310 ( a ), then in a fourth step 1508 A authorization module 226 A determines if purchase date 412 of the TAR falls within pre-verified dates 1312 ( a ). If purchase date 412 does not fall within the dates specified in pre-verified dates 1312 ( a ), then method 1500 A determines that the pre-verification criteria are not met, and the method ends.
  • authorization module 226 A determines whether miscellaneous pre-verification criteria 1314 ( a ) are satisfied. If miscellaneous pre-verification criteria 1314 ( a ) are not satisfied or the card-holder has not specified any miscellaneous criteria 1314 ( a ), then method 1500 determines that the pre-verification criteria have not been met, and method 1500 A ends. However, if miscellaneous pre-verification criteria 1314 ( a ) are satisfied, then method 1500 determines that the pre-verification criteria have been met, and the pending TAR should be automatically verified.
  • FIG. 16 is a flowchart summarizing one method 1600 for permitting card-holder 102 to modify associated pre-verification criteria 1302 .
  • Interactive verification module 306 A can perform the same functions as interactive verification module 306 , but is further operative to coordinate and control modification of pre-verification criteria records 1302 ( 1 - n ).
  • card-holder communications module 224 polls network interface 204 and telecommunications device 214 to determine whether there are any card-holder communication requests (e.g. a telephone call, network connection requests, etc.) from card-holder 102 , and if so then in a second step 1604 , interactive verification module 306 A establishes a connection with card-holder 102 .
  • card-holder communication requests e.g. a telephone call, network connection requests, etc.
  • interactive verification module 306 A retrieves pre-verification criteria 1302 associated with card-holder 102 .
  • interactive verification module 306 A determines if card-holder 102 wishes to modify pre-verification criteria 1302 (e.g., receives a touch tone response to a pre-recorded menu). If interactive verification module 306 A determines that card-holder 102 wishes to modify pre-verification criteria 1302 , then, in a sixth step 1612 , interactive verification module 306 A presents the first pre-verification criteria (e.g.
  • interactive verification module 306 A determines if card-holder 102 wishes to modify the criteria presented in step 1612 . If card-holder 102 chooses not to modify the presented pre-verification criteria 1302 , then, in eighth step 1616 , interactive verification module determines if card-holder 102 wants to proceed to the next pre-verification criteria (e.g. merchant identifier 1306 ( 2 )). If the card-holder 102 does not want to continue pre-verification criteria modification, interactive verification module 306 A terminates connection with card-holder 102 in ninth step 1618 .
  • pre-verification criteria e.g. merchant identifier 1306 ( 2 )
  • step 1602 If, in first step 1602 , there are no communication requests from card-holders, then method 1600 ends. If, in step 1610 , card-holder 102 does not want to modify any pre-verification criteria, then method 1600 proceeds to ninth step 1618 , where interactive verification module 306 A terminates the connection with card-holder 102 . If in step 1614 card-holder 102 wishes to modify the presented pre-verification data, then interactive verification module 306 A initiates a tenth step 1620 , wherein new data is received from card-holder 102 , and the new data is substituted for the presented pre-verification criteria before method 1600 proceeds to eighth step 1616 . If in eighth step 1616 receives instructions card-holder 102 to make more modifications to pre-verification criteria 1302 , then method 1600 returns to step 1610 .
  • FIG. 17 is a block diagram of another alternate server 200 B.
  • Server 200 B functions similar to server 200 of FIG. 2 and/or server 200 A of FIG. 11 , except that server 200 B includes an activation database 1702 and an alternate authorization module 226 B.
  • Authorization module 226 B controls and coordinates the approval and verification of TARs and, in addition to the functions performed by authorization modules 226 , 226 A, evaluates the activation status of card-holder 102 's account and automatically denies any TAR having a transaction date and time corresponding to a date and time when card-holder 102 's credit account is/was deactivated. Automatically denying every TAR having a transaction date falling within a deactivated time period of the credit account reduces the chance of an unauthorized user successfully making fraudulent purchases with the card-holder's credit account.
  • Activation database 1702 is a database that includes activation data/conditions for current customers of credit card company 106 , including card-holder 102 .
  • Activation conditions can include, but are not limited to, particular dates and/or times input by card-holder 102 to either activate or deactivate their account, particular dates and time when card-holder 102 activates or deactivates the account, or other specific activation and deactivation criteria defined by card-holder 102 .
  • card-holder 102 could specify times of the day only during which the credit card would be activated.
  • card-holder 102 's credit card could be automatically deactivated after a predetermined number (e.g., one) of transaction approval requests are received.
  • Card-holder 102 could either define such criteria when the account is opened (e.g., on the application form) or after the account is opened by connecting remotely with server 200 B via card-holder communications module 224 .
  • activation database 1702 would typically be a very large file. Therefore, while activation database 1702 is shown in memory 216 , it should be understood that the entire customer files would likely be stored in a mass data storage system such as non-volatile memory 208 , with portions of the entire database being swapped in and out of activation database 1702 as necessary.
  • FIG. 18 shows a block diagram of authorization module 226 B to include a credit approval module 302 , an alternate master verification module 304 B, an interactive verification module 306 , a merchant response module 308 , and an interactive activation module 1802 .
  • Credit approval module 302 executes conventional credit approval for each TAR contained in CARQ 220 by means well known to those skilled in the art.
  • Master verification module 304 B coordinates the authorization and verification processes, including determining the activation status of an account, and is responsible for overall control of authorization module 226 B.
  • Interactive verification module 306 carries out verification with card-holder 102 .
  • Merchant response module 308 communicates with merchant 104 by transmitting either a transaction approval or a transaction denial.
  • Interactive activation module 1802 coordinates modification of the activation status of the account associated with card-holder 102 . After establishing a connection with and authenticating card-holder 102 (e.g., via card-holder communications module 224 ), interactive activation module 1802 is operative to present the current activation status of card-holder 102 's account, and to receive modification instructions from card-holder 102 to change the activation status of the associated account. Optionally, interactive activation module 1802 is operative to transfer card-holder 102 to interactive verification module 306 such that card-holder 102 can verify pending TARs or modify pre-verification criteria if authorization module 226 B also includes the functions of authorization module 226 A.
  • FIG. 19 shows an example of an activation data structure 1900 suitable for use in activation database 1702 of the present invention.
  • Activation data structure 1900 includes a linked list of activation records 1902 ( 1 )- 1902 ( n ) associated with customer accounts of credit card company 106 , including card-holder 102 's account.
  • Each record 1902 ( 1 - n ) includes an account identifier (e.g., a credit card number) field 1904 , and a series of activation and deactivation conditions/entries including an automatic activation date and time field 1906 , an automatic deactivation date and time field 1908 , a first activation field 1910 ( 1 ), a first deactivation field 1912 ( 1 ), a last activation field 1910 ( r ), a last deactivation field 1912 ( r ), and a pointer field 1914 pointing to the next activation record 1902 .
  • Activation record 1902 ( n ) includes an “End of List” record 1916 instead of pointer 1914 , indicating that activation record 1902 ( n ) is the last activation record in activation database 1702 .
  • Credit card number field 1904 is the key field of each activation record 1902 , and is used to identify activation settings/entries associated with a particular customer of credit card company 106 (e.g., card-holder 102 ).
  • Automatic activation and deactivation date and time fields 1906 and 1908 store automatic activation and deactivation data associated with card-holder 102 .
  • card-holder 102 could set auto-activation field 1906 to automatically activate his/her credit card each morning at 8:00 a.m., and set auto-deactivation field 1908 to automatically deactivate his/her credit card each evening at 8:00 p.m.
  • card-holder 102 could set automatic activation field 1906 and automatic deactivation field 1908 to automatically deactivate his/her credit card over the weekdays, or alternately the weekends, of each month. Indeed, any desirable automatic “on-off” schedule can be specified by card-holder 102 .
  • Activation date and time field 1910 ( x )( 1 ) stores the date and time card-holder 102 initially activates his/her credit card, where (x) represents the activation record 1902 ( x ) associated with card-holder 102 (e.g., record 1902 ( 1 )( 1 )).
  • De-activation date and time field 1912 ( x )( 1 ) indicates the first date and time that card-holder 102 selectively deactivated their credit card (e.g., via telephone, secure website, etc.), such that transactions could no longer be made. Additional activation and deactivation fields are added to each record 1902 , as the credit card is subsequently activated and deactivated by card-holder 102 .
  • the last (i.e., the most recent) activation record 1910 ( x )( r ) and deactivation record 1912 ( x )( r ) are stored in card-holder 102 's activation record 1902 ( x ), followed by a pointer 1914 ( x ), pointing to the next activation record 1902 (x+1).
  • the final activation record 1902 ( n ) has an “end of list” indicator 1916 instead of a pointer 1914 indicating that activation record 1902 ( n ) is the final record in activation database 1702 .
  • data structure 1900 is illustrated as a simple liked list, it should be understood that data structure 1900 can be implemented in a relational database containing records including similar data fields.
  • Master verification module 304 B utilizes the activation data stored in each activation record 1902 as follows. Once a TAR is received and associated with a particular card-holder, master verification module 304 B determines the state of activation of the card-holder's account based on the purchase date and time included in the TAR. If the purchase date and time falls during a time when the card-holder's credit card was deactivated, then master verification module 304 B is operative to automatically deny the TAR. As shown in records 1902 ( 1 - n ), a deactivated purchase date and time would correspond to any date and time defined by Auto Deactivation date and time field 1908 , or any time period between a deactivation date and time and the following reactivation date and time stored in record 1902 .
  • master verification module 304 B would be operative to set denied flag 418 to a value of 1 (e.g., denied) because the purchase was made on a weekend (assuming the card-holder did not reactivate the card over the weekend in question).
  • denied flag 418 e.g. 1
  • the purchase was made after the deactivation date and time stored in deactivation date and time field 1912 ( x )( 1 ), and before the re-activation date stored in activation date and time field 1910 ( x )( 2 ), the TAR would also be denied.
  • the information stored in activation and deactivation fields 1910 ( x )( 1 )- 1910 ( x )( r ) and 1912 ( x )( 1 )- 1912 ( x )( r ) and the automatic activation and deactivation data stored in fields 1904 ( 1 ) and 1906 ( 1 ) are all evaluated during the approval process.
  • card-holder 102 can activate the account after an automatic deactivation, but prior to the next automatic activation, simply by making a new activation entry 1910 in record 1902 . Accordingly, there are no conflicts between automatic activation/deactivation and subsequent card-holder activations/deactivations. Rather, all activation/deactivation data, whether automatic or individually entered, are considered as equally valid points on a time line.
  • Master verification module 304 B when receiving a TAR, is operative to compare the purchase date and time included in the TAR with each of activation records 1910 ( x )( 1 )- 1910 ( x )( r ) and each of deactivation records 1912 ( x )( 1 )- 1912 ( x )( r ). Therefore, as long as the purchase date and time included with the TAR is correct and corresponds with an activated state, the TAR is passed to the previously described credit approval and verification processes for processing.
  • FIG. 20 is a flowchart summarizing a method 2000 of processing a TAR in accordance with one particular embodiment of the present invention.
  • merchant communications module 232 of server 200 B receives a TAR including an account identifier (e.g., a credit card number) from a merchant 104 , generates a TAR record 402 , and writes TAR record 402 into CARQ 220 .
  • authorization module 226 B determines if card-holder 102 has selectively deactivated their credit card. If not, then in a third step 2006 authorization module 226 B subjects TAR record 402 to a conventional credit approval process, and sets approved flag 416 or denied flag 418 to indicate whether the requested credit is approved or denied.
  • authorization module 226 B determines from flags 416 and 418 whether the requested credit has been approved or denied. If, in fourth step 2008 , authorization module 226 B determines that the requested credit has been approved, then in a fifth step 2010 authorization module 226 B determines whether card-holder 102 has selectively disabled the verification process. If the verification process has not been selectively disabled, then in a sixth step 2012 authorization module 226 B verifies the transaction with card-holder 102 . Then, in a seventh step 2014 authorization module 226 B determines whether the TAR has been verified by card-holder 102 . If the TAR has been verified, then in an eighth step 2016 merchant communications module 232 transmits a transaction approval to merchant 104 . Next, in a ninth step 2018 , authorization module 226 B determines whether there are any more TAR records in CARQ 220 . If there are no more records in CARQ 220 , then method 2000 ends.
  • authorization module 226 B determines that card-holder 102 has deactivated their credit card
  • method 2000 proceeds to a tenth step 2020 where merchant communications module 232 transmits a denial to merchant 104 . If, in fourth step 2008 , authorization module 226 B determines that the credit request has been denied, then method 2000 proceeds to tenth step 2020 where merchant communications module 232 transmits a denial to merchant 104 . If, in fifth step 2010 , authorization module 226 B determines that the verification process has been selectively disabled, then method 2000 proceeds to eighth step 2016 where merchant communications module 232 transmits an approval to merchant 104 .
  • authorization module 226 B determines that the TAR has not been verified by card-holder 102 . If, in seventh step 2014 , authorization module 226 B determines that the TAR has not been verified by card-holder 102 , then method 2000 proceeds to tenth step 2020 where merchant communications module 232 transmits a denial to merchant 104 . Finally, if in ninth step 2018 authorization module 226 B determines that there are more pending TAR records in CARQ 220 , then method 2000 returns to first step 2002 to process the next record in CARQ 220 .
  • FIG. 21 is a flowchart summarizing one method 2100 for permitting card-holder 102 to modify the activation status of his/her account.
  • card-holder communications module 224 polls network interface 204 and telecommunications device 214 to determine whether there are any card-holder communication requests (e.g. a telephone call, network connection requests, etc.) from card-holder 102 , and if so then in a second step 2104 , interactive activation module 1802 establishes a connection with card-holder 102 .
  • interactive activation module 1802 authenticates card-holder 102 (e.g.
  • interactive activation module 1802 retrieves the activation status of the credit card account associated with card-holder 102 .
  • interactive activation module 1802 determines if card-holder 102 wishes to modify the activation status of the credit card (e.g., receives a prompt from a pre-recorded menu). If card-holder 102 wishes to modify the activation status of the account, method 2100 proceeds to a sixth step 2112 , where card-holder 102 can set the activation status of the credit account, optionally including defining automatic activation and deactivation date and times or other activation/deactivation data. Then, in a seventh step 2114 , interactive activation module 1802 terminates the connection with card-holder 102 .
  • step 2110 card-holder 102 does not wish to modify the activation status of the credit card
  • method 2100 proceeds to seventh step 2114 and terminates the connection with card-holder 102 .
  • interactive activation module 1802 could instead transfer card-holder 102 to interactive verification module 306 (or 306 A), or some other service module, where the card-holder could instruct interactive verification module 306 (or 306 A) to verify TARs or modify pre-verification criteria 1302 .
  • FIG. 22 is a flowchart summarizing one method 2200 for making commercial transactions according to the present invention, including card-holder 102 selectively activating and deactivating a credit account.
  • card-holder 102 activates the credit card via conventional means, such as by calling an automated service when their credit card is first received in the mail.
  • the initial activation date and time is stored in the first activation field (e.g., activation date and time field 1910 ( 1 )( 1 )) of the record 1902 ( x ) in activation database 1702 associated with card holder 102 .
  • card-holder 102 makes one or more purchases with the credit card.
  • card-holder 102 deactivates the credit card by, for example, connecting with server 200 B, via card-holder communications module 224 , and instructing interactive activation module 1802 to record a deactivation date and time in an associated activation record 1902 (e.g., in deactivation date and time 1912 ( 1 )( 1 )).
  • card-holder 102 determines if he/she needs to make any further commercial transactions.
  • card-holder 102 reconnects with server 200 B and reactivates the credit card by instructing interactive activation module 1802 to record a next activation date and time (e.g., activation date and time 1910 ( 1 )( 2 )), so that additional purchase can be made.
  • a next activation date and time e.g., activation date and time 1910 ( 1 )( 2 )
  • step 2208 if in step 2208 no further transactions are necessary, the credit account associated with card-holder 102 remains deactivated and protected, thereby preventing unauthorized use of card-holder 102 's account.
  • FIG. 23 shows a credit card 2300 having a front side 2302 and a back side 2304 .
  • Front side 2302 of credit card 2300 has account indicia including an account number 2306 , an expiration date 2308 , and the name 2310 of a card-holder (e.g., card-holder 102 ).
  • Front side 2302 of card 2300 also includes security indicia 2312 .
  • Account number 2306 , expiration date 2308 , and name 2310 are common features of credit cards and are associated with the credit account of card-holder 102 .
  • Security indicia 2312 is an inventive feature that indicates that transactions made with card 2300 are protected by one or more security features, including but not limited to the security features of the present invention.
  • Security indicia 2312 alerts would-be thieves that attempts to make illegal transactions using credit card 2300 and/or the associated credit account number 2306 would be difficult, because purchases require account-holder verification.
  • Back side 2304 of credit card 2300 includes a magnetic stripe 2314 , a signature field 2316 , and a second security indicia 2318 .
  • Magnetic stripe 2314 contains electronically readable account data such that card 2300 can be swiped through a card reader
  • signature field 2316 provides a place for card-holder 102 to sign credit card 2300 .
  • second security indicia 2318 is an inventive feature that provides a more detailed description of the transaction security features associated with the account linked to credit card 2300 .
  • Security indicia 2318 (like indicia 2312 ) deter would-be thieves by indicating that illegally using credit card 2300 will be particularly difficult. It is thought that indicia indicating that account-holder verification is required will be effective to provide a significant reduction in fraudulent use, even if other security features are not fully implemented.
  • card-holder communications module 224 and interactive verification module 306 can be combined into a single operative module.
  • functional modules of the present disclosure are organized and labeled to provide a clear illustration of the invention, and no particular segregation of functionality is considered to be an essential element of the present invention.

Abstract

A system and method is disclosed for verifying a commercial transaction between a card-holder, a merchant, and a credit card company. The card-holder makes a purchase with the merchant using a full credit card number. The merchant submits a transaction approval request for approval with the credit card company. The credit card company executes conventional credit approval of the transaction approval request, as well as verifies the transaction approval request with the card-holder. An approval is sent to the merchant only after the transaction approval request is both conventionally approved by the credit card company and verified by the card-holder. The card-holder, or the credit card company, may initiate verification of the transaction approval request. The transaction approval request can also be automatically verified if one or many pre-verification criteria is/are satisfied by data contained in the transaction approval request. The pre-verification criteria can be initially determined and/or modified by the card-holder. As another security feature, the card-holder may selectively activate and deactivate their credit card/account as desired. The credit card itself includes indicia of security measures.

Description

RELATED APPLICATIONS
This application is a continuation of U.S. application Ser. No. 11/895,837 (now U.S. Pat. No. 7,753,265 filed Aug. 28, 2007 by the same inventor, which is a continuation of U.S. application Ser. No. 10/889,227 (now U.S. Pat. No. 7,264,154) filed Jul. 12, 2004 by the same inventor, both of which are incorporated herein by reference in their entireties.
BACKGROUND
1. Field of the Invention
This invention relates generally to electronic commerce, and more particularly to a system and method for providing secure electronic transactions. Even more particularly, the present invention relates a system and method for facilitating verification of an electronic purchase by an account holder.
2. Description of the Background
Electronic commerce, buying and selling by electronic means, has become commonplace in modern society. With the mainstreaming of the Internet (most specifically the World Wide Web), electronic commerce has made its way into the home or office of any person with a computer. For several reasons, more and more people are choosing to do business (e.g. shopping) from their home or office computer. For example, consumers are attracted to Internet commerce because Internet based businesses typically offer items at discounted prices. In addition, the Internet is accessible twenty-four hours a day, enabling the consumer to make purchases at their convenience.
The primary means of payment for most consumer electronic purchases is a credit card. The credit card represents a prearranged credit account of the card-holder. The card-holder makes an electronic purchase with a merchant, using a credit card. The merchant submits the purchase request (including transmitting the entire credit card number) to the credit card company for purchase authorization. The credit card company then authorizes or denies the credit card transaction with the merchant. If the purchase is approved the prearranged credit account is debited in the amount of the purchase.
Credit cards offer many advantages to card-holders. For example, persons having access to a credit card spend less time at the bank, as well as, balancing checking and savings accounts. In addition, a credit card eliminates the need to carry large sums of cash. Further, purchase approval is automated when using a credit card while purchase approval with check or money order is delayed. Therefore, when making a purchase by phone or mail order, using a credit card eliminates the delay associated with sending payment through the mail.
As a result of increased electronic commerce, credit card security has become a major concern for card-holders. Some card-holders are wary of purchasing items over the Internet using their credit cards for fear of interception and unauthorized use of their credit card number. Their fears are justified because the language, in which most Internet web pages are written, HyperText Markup Language (HTML), uses vulnerable methods of transferring information. To combat Internet security issues some merchant networks use encryption techniques to secure transactions made over the Internet. This offers little comfort to the concerned consumer, because such encryption techniques can be deciphered by sophisticated criminals. Further, even if the transmission of the credit card number is secure, the card number is still stored on the receiving computer, and could be stolen by breaking into that computer. Additionally, credit card numbers can be stolen directly from the card by such devices as pocket scanners used by dishonest waiters, store clerks and the like.
Some commercial accounts (e.g. checking accounts) offer debit cards that face the same, if not increased, security risks as credit cards. Debit cards are similar to credit cards, however to complete a debit transaction, the card-holder's Personal Identification Number (PIN) must be given in addition to the card number at the time of purchase. In addition, the debit card draws funds from the account (typically a checking account) that it is linked to. In many cases the PIN given with debit card transactions is the same PIN used to access (e.g. via ATM machine or phone) the account that the debit card is linked to. If a purchase transaction made using a debit card is intercepted and used fraudulently, the thief has the ability to both make purchases using the debit card number and PIN, as well as, draw funds directly from the associated debit account.
The concern for improved credit card safety has put pressure on credit card companies and merchants to provide methods of ensuring secure electronic transactions. For example, U.S. Pat. No. 6,012,144 (Pickett) describes a method of maintaining Internet credit card transaction security by splitting the credit card number into two pieces and storing each piece on a separate data storage device of one or more server computers. The card-holder decides which portions of the credit card number will be sent to each storage device and then secures several processing codes (passwords). The processing codes are later obtained from the card-holder by an automated telephone call so that the purchase may be verified. There are several disadvantages to this methodology. First, Pickett's method is extremely time consuming for the card-holder because the full credit card number is not transmitted to the merchant in its entirety. Rather, the card-holder must parse the credit card number and calculate a slicing code. In addition, the card-holder must remember the slicing code, which may be different for each transaction, in order to verify the transaction. Further, the burden of providing the security software falls on the merchant, which may or may not be willing to provide such a system. Thus, no security is provided if the card-holder wishes to purchase from a merchant without such a system.
U.S. Pat. No. 5,903,721 (Sixtus) describes an alternate method of providing improved credit card transaction security. The method of Sixtus involves a card-holder making a purchase over the Internet. A “trust server”, used to verify the card-holder, receives a purchase request along with the card-holder's IP (Internet Protocol) address. If the IP address received by the trust server matches a registered IP address for that card-holder, the purchase is verified and forwarded to a “Credit Clearinghouse” where the purchase is approved or disapproved. While no sensitive credit card information is transmitted over an unsecured network, transactions can only be made from the computer having the IP address registered with the trust server. In addition, some Internet Service Providers (ISP) use dynamic IP addressing, wherein a temporary IP address is assigned as the user logs onto the ISP's network. Thus, a card-holder having an Internet Service Provider that utilizes dynamic IP addressing is unable to use the transaction security system taught by Sixtus.
As another example, U.S. Pat. No. 5,991,738 (Ogram) teaches a method utilizing encryption software. A card-holder, wishing to purchase an item from a merchant employing Ogram's methodology, downloads encryption software from the merchant computer. The encryption software encodes any sensitive information before transmission to the merchant. One disadvantage of Ogram's methodology is the lack of a secured purchase verification process with the card-holder. In addition, the employed encryption techniques can be intercepted and deciphered during transmission.
What is needed is a system and method for providing safe and secure credit card transaction processing. What is also needed is a system and method for providing safe and secure credit card transactions that are transparent to merchants. What is also needed is a system and method for facilitating card-holder verification of credit card transactions and providing prompt notice of each attempted use of a card-holder's credit card.
SUMMARY
The present invention overcomes the problems associated with the prior art by providing a system and method for providing safe and secure credit card transaction processing which is transparent to the merchant. The invention facilitates card-holder verification of each credit card transaction prior to transmitting an approval to the merchant, and provides prompt notice of each attempted use of the credit card to the account-holder.
A computer system is disclosed, for processing a commercial transaction between an account-holder and a merchant, comprising a processing unit to execute data and code, and a memory device for storing data and code. The stored and executed code includes a merchant communications module operative to receive a transaction approval request, including an entire account number, an account-holder communications module operative to facilitate a separate connection with the account-holder for verifying the received transaction approval request, and an authorization module responsive to the transaction approval request and operative to transmit an approval to the merchant only if the transaction approval request is verified by the account-holder.
In a particular embodiment, the authorization module includes an interactive verification module, responsive to the receipt of a transaction approval request and operative to initiate a connection with the account-holder. In a more particular embodiment, the computer system further includes a network interface, and the interactive verification module is operative to transmit an electronic message to the account-holder via the network interface, and is further operative to verify the transaction approval request upon receipt of a reply to the transmitted electronic message.
In another particular embodiment, the computer system further comprises a telecommunications device and the interactive verification module is operative to place an automated telephone call to the account-holder, recite a portion of the transaction approval request to the account-holder, and receive verification instructions from the account holder. In a more particular embodiment, the interactive verification module is operative to require an authentication code before reciting a portion of the transaction approval request.
Optionally, the interactive verification module waits for the account-holder to initiate communication with the system. Alternatively, the system initiates communication with the account-holder to verify pending transaction approval requests.
In a particular embodiment, the authorization module, responsive to instructions from the account holder, can selectively disable the verification process by automatically verifying subsequent transaction approval requests without further input form the account holder.
In yet another particular embodiment, the authorization module includes a master verification module that automatically disclaims a transaction approval request if the account holder has not verified the transaction approval request prior to the lapse of a predetermined time period. The master verification module is further operative to transmit notice to the account holder when the transaction approval request is disclaimed.
In yet another particular embodiment, a transaction approval request comprises a verification request from a third party financial institution, and the authorization module is operative to transmit indicia of verification to the third party financial institution.
A method is also disclosed for providing safe and secure commercial transactions between an account-holder and a merchant. The method includes receiving a transaction approval request including a full account number identifying the account-holders account, electronically verifying the transaction approval request with the account-holder via a separate communication from the merchant, and transmitting an approval to the merchant only if the transaction approval request is verified by the account-holder.
In a particular method, the step of verifying the transaction approval request with the account-holder includes prompting the account-holder to verify the transaction approval request. In a more particular method, prompting the account-holder includes sending an electronic message. In yet a more particular method, the step of verifying the transaction approval request includes receiving a reply to the electronic message. In another particular method, prompting the account-holder includes placing an automated telephone call to the account-holder, establishing a connection with the account-holder, reciting at least a portion of the transaction approval request, and receiving verification instructions from the account-holder. In an even more particular method, the account holder is authenticated before the recitation of at least a portion of the transaction approval request.
An alternate method includes waiting for the account-holder to initiate the verification process by communicating with the computer system. In a particular method verification is initiated by the account-holder over a network or a telephone connection and includes, receiving a connection request from the account-holder via a network or telecommunications device, establishing a connection with the account-holder, authenticating the account-holder, transmitting at least a portion of the transaction approval request to the account-holder, and receiving verification instructions from the account-holder with respect to the transaction approval request.
Optionally, the verification process can be selectively enabled or disabled by the account holder.
In another particular method, the step of electronically verifying the transaction approval request includes disclaiming the transaction approval request if the account holder does not verify the transaction approval request within a predetermined time interval. In a more particular method notice is transmitted to the account-holder when the transaction approval request has been disclaimed.
In yet another particular method, the step of receiving a transaction approval request from the merchant comprises receiving a verification request from a third party financial institution that received the transaction approval request from the merchant. The step of transmitting an approval to the merchant comprises transmitting indicia of verification to the third-party financial institution.
A system and method for pre-verifying certain transactions between a merchant and an account-holder is also disclosed. In a particular embodiment, a computer system includes a processing unit for processing data and code, and a memory device for storing the data and code. The data includes at least one pre-verification criteria associated with the account-holder. The code includes a merchant communications module for receiving a transaction approval request from the merchant, and an authorization module. The authorization module compares the transaction approval request with the pre-verification criteria, and automatically verifies the transaction approval request if the pre-verification criteria are met, thereby eliminating the need to obtain direct verification of the transaction approval request from the account-holder prior to completing the approval process.
In a particular embodiment, the pre-verification criteria includes a plurality of pre-verification criteria associated with the account-holder, and the transaction approval request is verified if any one of the pre-verification criteria are satisfied. In an alternate embodiment, the transaction approval request is not automatically verified unless all of the plurality of pre-verification criteria are satisfied. Examples of useful pre-verification criteria include, but are not limited to, merchant identifiers, transaction amounts (e.g., purchase prices), transaction dates, transaction times, or any other criteria that an account-holder might find convenient. Optionally, the code further includes a card-holder communications module and/or an interactive verification module that facilitates modification of the pre-verification criteria by the account-holder. In one embodiment, the pre-verification criteria are initially set so that no transaction approval request can be automatically verified until the pre-verification criteria are modified by the account-holder. As an alternative, the initial pre-verification criteria can be determined by the account-holder (e.g., when the account is opened).
A system and method for selectively activating and deactivating the account-holder's account is also disclosed. A computer system includes a processing unit for processing data and code, and a memory device for storing the data and code. The data includes activation data accessible to the account-holder that is indicative of the activation status of the account-holder's account. The code includes a merchant communications module for receiving a transaction approval request from the merchant, and an authorization module. The authorization module approves or denies the transaction approval request based at least in part on the activation data and the associated activation status of the account, thereby permitting the account-holder to temporarily activate and deactivate their account as desired.
In a particular embodiment, the activation data includes at least one activation condition (e.g., an activation date and time), and the authorization module is operative to approve the transaction approval request if the transaction approval request satisfies the activation condition (e.g., the purchase date and time is after the activation date and time). In another particular embodiment the activation data also includes at least one deactivation condition (e.g., a deactivation date and time), and the authorization module will approve the transaction approval request only if the transaction approval request satisfies the activation condition and does not satisfy the deactivation condition (e.g., the purchase date and time falls before the deactivation date and time).
In another particular embodiment, the account-holder can specify automatic activation or deactivation criteria which the authorization module can implement automatically. One possible deactivation criteria is a predetermined number of transaction approval requests (e.g., one) received by the computer system, and then the authorization module is operative to automatically deactivate the account-holder's account.
In yet another particular embodiment, the authorization module includes an interactive activation module operative to establish a connection with the account-holder, authenticate the account-holder, present the current activation status of the account-holder's account to the account holder, and receive instructions from the account holder to modify the activation data. The connection between the account-holder and the interactive activation module can be established, for example, by telephone. In a more particular embodiment, the interactive activation module is operative to store instructions (e.g., the activation or deactivation date and time) received from the account-holder.
A method is also disclosed for facilitating commercial transactions between an account-holder and a merchant including the steps of receiving deactivation instructions from the account-holder to temporarily deactivate their account, receiving a transaction approval request from a merchant, determining whether the account holder has temporarily deactivated the account, and denying the transaction approval request if the account is temporarily deactivated.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is described with reference to the following drawings, wherein like reference numbers denote substantially similar elements:
FIG. 1 is a block diagram of an internetwork between, a card-holder, a merchant, a credit card company, and a third party verification company according to the present invention;
FIG. 2 is a block diagram showing a server of the credit card company of FIG. 1, to include a working memory and an authorization module within said working memory;
FIG. 3 is a block diagram detailing the authorization module shown in FIG. 2;
FIG. 4 is a block diagram showing exemplary data structures for storing transaction approval requests records in the Credit Approval Request Queue of FIG. 2;
FIG. 5 is a block diagram showing exemplary data structures for storing card-holder data in the Card-holder List module of FIG. 2;
FIG. 6 is a block diagram showing exemplary data structures for storing transaction records in the Purchase History module of FIG. 2;
FIG. 7 is a flowchart summarizing one method of providing safe and secure electronic transactions according to the present invention;
FIG. 8 is a flowchart summarizing one method of performing the fourth step (verification disabled?) of the method of FIG. 7;
FIG. 9 is a flowchart summarizing one method of performing the fifth step (card-holder verification) of the method of FIG. 7;
FIG. 10 is a flowchart summarizing an alternate method of performing the fifth step (card-holder verification) of the method of FIG. 7.
FIG. 11 is a block diagram showing an alternate server including pre-verification criteria and an alternate authorization module used to pre-verify transactions according to the present invention;
FIG. 12 is a block diagram detailing the alternate authorization module of FIG. 11;
FIG. 13 is a block diagram showing exemplary data structures for storing the pre-verification criteria of FIG. 11;
FIG. 14 is a flowchart summarizing another method of providing safe and secure electronic transactions according to the present invention;
FIG. 15 is a flowchart summarizing one method of performing the fifth step (pre-verification criteria met?) of the method of FIG. 14;
FIG. 15A is a flowchart summarizing an alternate method of performing the fifth step (pre-verification criteria met?) of the method of FIG. 14;
FIG. 16 is a flowchart summarizing one method for a card-holder to modify pre-verification criteria associated with said card-holder's account;
FIG. 17 is a block diagram showing an alternate server including an activation database used to store activation and deactivation data according to the present invention;
FIG. 18 is a block diagram detailing the alternate authorization module of FIG. 17;
FIG. 19 is a block diagram showing an exemplary data structure for storing the activation data in the activation database of FIG. 17;
FIG. 20 is a flowchart summarizing yet another method of processing electronic transactions according to the present invention;
FIG. 21 is a flowchart summarizing one method for allowing a card-holder to modify the activation status of the card-holder's account;
FIG. 22 is a flowchart summarizing one method for selectively activating/deactivating an account according to the present invention; and
FIG. 23 shows a credit card having security indicia thereon indicating that the associated card-holder's account is protected by one or more security features.
DETAILED DESCRIPTION
The present invention overcomes the problems associated with the prior art, by providing a novel system and method of providing safe and secure electronic transactions by verifying each electronic transaction with the account-holder. In the following description, numerous specific details are set forth (e.g. verification processed by credit card company, verification initiated by card-holder, etc.) in order to provide a thorough understanding of the invention. Those skilled in the art will recognize, however, that the invention may be practiced apart from these specific details. In other instances, details of well-known electronic commerce practices (e.g. electronic credit request/approval processes, computer operating systems, communication software, etc.) have been omitted, so as not to unnecessarily obscure the present invention.
FIG. 1 is a block diagram showing a system 100 including a card-holder 102, a merchant 104, a credit card company 106, and a third-party verification company 108, each connected to an internetwork 110 (e.g., the Internet) by physical network media 112(1-4) (e.g. telephone line, coaxial cable, etc.). Card-holder 102, merchant 104, credit card company 106, and verification company 108 are also in communication via another physical network media 114 (e.g. a telephone line).
Card-holder 102 possesses a credit card with a number identifying an account provided by credit card company 106. Merchant 104 offers goods or services which can be purchased via internetwork 110 by card-holder 102 using the credit card number. Card-holder 102 makes an electronic purchase request from merchant 104, by providing the entire credit card number. This purchase may be made over internetwork 110, physical network media 114, or even in person. Responsive to receipt of the purchase request, merchant 104 submits a transaction approval request (TAR) to credit card company 106.
The TAR then undergoes a two-part authorization before an approval or denial is issued to merchant 104. First, the purchase request undergoes standard credit approval by credit card company 106. Following credit approval, the purchase request is verified with card-holder 102 either by credit card company 106, or by verification company 108. Verification is executed either over internetwork 110 or physical network media 114. Following verification, if the purchase is both approved by credit card company 106 and verified by card-holder 102, an approval is transmitted to merchant 104 via physical network media 114 or internetwork 110:
In this particular embodiment a credit card facilitates electronic commerce. Those skilled in the art will realize that the present invention is not, however, limited to purchases made using credit cards. The present invention may be used in conjunction with any type of account (e.g. debit cards) to facilitate safe and secure electronic transactions that include transmission of an account number. It is further understood that in the following description, credit card company 106 executes the verification process. However, the verification process may optionally be performed by third party verification company 108. In such an embodiment, credit card company 106 transmits a verification request to verification company 108. Verification company 108 then verifies the transaction request with card-holder 102, and transmits indicia of verification (indicating whether the transaction request has been verified, disclaimed, etc.) back to credit card company 106.
FIG. 2 is a block diagram of a server 200 (e.g. an HTTP Internet Server) connected to internetwork 110 via physical network media 112(3). In this particular embodiment server 200 is a transaction server of credit card company 106, for processing credit card transactions for credit card company 106. Server 200 includes a processing unit (PU) 202, a network interface 204, a system bus 206, non-volatile memory 208, at least one input/output (I/O) controller 210, a system clock 212, a telecommunications device 214, and a working memory 216. PU 202 executes data and code contained in working memory 216 to cause server 200 to carry out its intended functions (e.g. processing credit card transactions). System bus 206 facilitates intercommunication between the various components of server 200.
Server 200 communicates over Internetwork 110 via network interface 204. Network interface 204 (e.g. an Ethernet adapter card) transmits data packets onto and receives data packets from internetwork 110, thus allowing server 200 to communicate with card-holder 102 and merchant 104 via internetwork 110. Non-volatile memory 208 (e.g. read-only memory, or one or more hard disk drives) provides storage for data and code (e.g., boot code and programs) that are retained even when server 200 is powered down. I/O controller 210 manages connections for user interface devices (not shown) for a system administrator of server 200. I/O devices typically include a keyboard, mouse, monitor, printer, and other such devices that facilitate communications between server 200 and an administrator. Server 200 further includes a system clock 212 that maintains proper date and time, and provides date and time data upon request.
Server 200 further includes a telecommunications device 214 (e.g. a modem, or telephone) for establishing either a data or voice connection between a remote system or party and server 200. Examples of remote systems include a computer owned by card-holder 102, merchant 104, or verification company 108. In a particular embodiment, a voice connection with card-holder 102 is used to verify pending TARs.
Working memory 216 (e.g. random access memory) provides dynamic memory to server 200, and includes executable code (e.g. an operating system 218), which is loaded into working memory 216 during system start-up. Operating system 218 facilitates control and execution of all other modules loaded into working memory 216. Working memory 216 further includes a Credit Approval Request Queue (CARQ) 220, a card-holder list module 222, a card-holder communications module 224, an authorization module 226, a verification pending queue (VPQ) 228, a purchase history module 230, and a merchant communications module 232. Each of the foregoing modules and queues are initialized and loaded into working memory 216 at startup from non-volatile memory 208 using methods well known to those skilled in the art. Optionally, the foregoing modules and queues can be loaded into working memory 216 from alternate mass data storage devices including, but not limited to, a CD-ROM, a tape, or a drive having high capacity removable data storage disks (e.g. Iomega's Jaz™ or Zip™ drives).
Authorization module 226 controls and coordinates the approval and verification of TARs. As described above, in the alternate embodiment where verification is processed by third-party verification company 108, authorization module 226 is operative to transmit a request for verification to verification company 108 and receive indicia of verification from verification company 108. The transmitted request for verification would include information related to the purchase request such as a product description, purchase price, merchant's name, or any other information helpful to identify the transaction to the card-holder for verification. The received indicia of verification would include, for example, a code indicating that the particular transaction has been verified or disclaimed by the card-holder. Optionally, authorization module, responsive to instructions given by card-holder 102, is further operative to selectively disable the verification process (e.g., automatically verify every transaction or transactions for a particular merchant). Instructions to disable the verification process would generally be initiated by card-holder 102 over a secure network (e.g. via telephone, or mail).
Merchant communications module 232 receives TARs from and transmits approvals or denials to merchant 104 via network interface 204 or telecommunications device 214. Card-holder Communications module 224 manages communications between server 200 and card-holder 102, via internetwork 110 or physical network media 114. Card-holder list module 222 is a database for storing personal and account information for current customers of credit card company 106, including card-holder 102. Those skilled in the art will understand that card-holder list module 222 would typically be a very large file. Therefore, while card-holder list module 222 is shown in memory 216, it should be understood that the entire customer files would likely be stored in a mass data storage system such as non-volatile memory 208, with portions of the entire list being swapped in and out of card-holder list 222 as necessary.
Credit Approval Request Queue (CARQ) 220 provides storage for pending TARs awaiting conventional credit approval by authorization module 226. Merchant communications module 232 periodically polls network interface 204 and telecommunications device 214 to determine whether there are any incoming TARs from merchant 104, and transfers any such requests to CARQ 220.
Verification Pending Queue (VPQ) 228 provides storage for pending TARs awaiting verification by card-holder 102. Authorization module 226 transfers TARs from CARQ 220 to VPQ 228 after the TAR is confirmed as corresponding to a valid account and passes conventional credit approval. TARs remain in VPQ 228 until verified, denied, or until the lapse of a predetermined time period.
Once a TAR is approved or denied, a record of the TAR is transferred to purchase history module 230. Purchase history module 230 stores information about previous account activity, for a predetermined time period (e.g. a period of thirty days). Upon lapse of the predetermined time period, at which point a written record (e.g. a bill, an e-bill, etc.) of the transaction has been conveyed to card-holder 102, each expired TAR is transferred from working memory 216 to a more permanent storage media (e.g., magnetic tape).
FIG. 3 shows a block diagram of authorization module 226 to include a credit approval module 302, a master verification module 304, an interactive verification module 306, and a merchant response module 308. Credit approval module 302 executes conventional credit approval for each TAR contained in CARQ 220 by means well known to those skilled in the art. Master verification module 304 coordinates the authorization and verification processes, and is responsible for overall control of authorization module 226. Interactive verification module 306 carries out verification with card-holder 102. Merchant response module 308 initiates final communication with merchant 104 by transmitting either a transaction approval or a transaction denial.
FIG. 4 shows an example of a credit approval request data structure 400 suitable for use with a particular embodiment of the present invention. Those skilled in the art will recognize data structure 400 as a linked-list of records 402(1-n). Each of records 402(1-n) represents a pending TAR and includes a full credit card number 404, a purchase description 406, a purchase price 408, merchant information 410, purchase date and time information 412; a verified flag 414, a verification initiated flag 415, an approved flag 416, a denied flag 418, and a pointer 420. Full credit card number 404, purchase description 406, purchase price 408, merchant information 410, and purchase date and time information 412 are received by server 200 from merchant 104 with the TAR. Verified flag 414, approved flag 416, and denied flag 418 are used to indicate the status of each record 402 in the authorization process, as will be explained in greater detail below. Pointer 420 indicates the memory address of the next record 402(+1) in the list. The last record 402(n) includes an end of list value 422, that indicates that record 402(n) is the last record in the list.
Verified flag 414, verification initiated flag 415, approved flag 416, and denied flag 418 are single bit flags indicating the status of the respective record. Verified flag 414 indicates if the associated TAR has been verified (e.g. verified flag 414=1) or if the TAR is not verified (e.g. verified flag 414=0). Verification initiated flag 415 indicates whether server 200 has initiated the verification process with card-holder 102. Approved flag 416 indicates whether or not the associated TAR has been approved (e.g. approved flag=1). Denied flag 418 indicates whether the associated TAR has been denied (e.g. denied flag=1).
FIG. 5 shows an example of a card-holder data structure 500 suitable for storing card-holder data in card-holder list module 222. Those skilled in the art will recognize that data structure 500 is a linked list of records 502(1-n), with one record 502 for each valid credit account extended by credit card company 106. Each record 502 includes a full credit card number 504 issued to an associated card-holder, a personal identification number (PIN) 506, card-holder information 508, contact information 510, a credit limit 512, a verification requested flag 514, an initiate verification flag 516, and a pointer 518.
PIN 506 is a code used to authenticate card-holder 102 during the verification process or to allow card-holder 102 to set preference settings (e.g., verification requested flag 514, initiate verification flag 516, etc.). Card-holder information 508 includes, but is not limited to, such personal information as card-holder's first and last names, date of birth, social security number, and/or address. Contact information 510 comprises information necessary for communications with the associated card-holder, especially for TAR verification. Contact information 510 may include, but is not limited to, a telephone number, a pager number, or an e-mail address. Credit limit 512 indicates the prearranged credit limit for the associated card-holder. Verification requested flag 514 allows card-holder 102 to selectively disable the verification process by for example, automatically verifying subsequent TARs without further input from card-holder 102. In this embodiment, verification requested flag 514 is a single bit flag, wherein a value of 1 indicates that the verification process should be carried out, and a value of 0 indicates that the card-holder wishes to suspend the verification process. Single bit initiate verification flag 516 indicates whether card-holder 102 wishes server 200 to initiate the verification process, or if server 200 should wait for user 102 to initiate the verification process. If initiate verification flag 516 has a value of 1, interactive verification module 306 initiates the verification process with the associated card-holder (e.g. e-mail, automated telephone call, etc.). If initiate verification flag 516 has a value of 0, the associated card-holder must initiate verification (e.g., place telephone call to server 200, log onto server 200 via internetwork 110, etc.). Pointer 518 indicates the start address of the next record 502 in card-holder data structure 500. End of list indicator 520 indicates that record 502(n) is last record in card-holder data structure 500.
FIG. 6 shows an example of a purchase history data structure 606, suitable for use with a particular embodiment of the present invention. Purchase history data structure 600 is a linked-list of records 602(1-n), each of which includes a full credit card number 604, purchase information 606, a purchase price 608, merchant information 610, a verification date and time 612, and a pointer 614. Credit card number 604 identifies the particular transaction with the associated card-holder. Purchase information 606 includes information (e.g., product description) that will help identify the transaction to the card-holder. Purchase price 608 indicates the cost associated with the purchase. Merchant information 610 identifies the merchant that submitted the TAR. Verification date and time 612 indicates when, if at all, the associated card-holder verified the TAR. Pointer 614 indicates the address of the next record. 602 in data structure 600. End of list indicator 616(n) indicates that record 602(n) is the last record in purchase history data structure 600.
Those skilled in the art will understand that the above-described credit approval request data structure 400, card-holder data structure 500, and purchase history data structure 600 are exemplary in nature, and that other data structures may, and likely will, be employed with the present invention. Accordingly, the particular data structures described herein by way of example are not considered to be essential elements of the present invention.
The operation of a particular embodiment of the present invention will now be explained with reference to FIGS. 1-6. The process begins when card-holder 102 submits an order for goods or services to merchant 104, and uses a credit card number assigned by credit card company 106 as the means of payment. Merchant 104 then transmits a transaction approval request to credit card company 106 including the credit card number supplied by card-holder 102, a description of the purchase, the purchase price, the purchase date and time, and information identifying merchant 104.
Merchant communications module 232 (FIG. 2) periodically polls network interface 204 and telecommunications device 214 for any incoming TARs from merchant 104. When a TAR is received, merchant communications module 232 scans card-holder list 222 to determine whether there is a record 502 (FIG. 5) with a credit card number 504 matching the credit card number provided with the TAR. If there is no such record in card-holder list 222, then merchant communications module 232 transmits a denial to merchant 104.
If, however, the submitted credit card number matches a credit card number 502(x) in card-holder list 222, then merchant communications module 232 generates a credit approval request record 402 using the information provided in the TAR to create fields 404, 406, 408, 410, and 412, and stores the new record in CARQ 220. Initially, verified flag 414, approved flag 416, and denied flag 418 are all set equal to zero.
Master verification module 304 of authorization module 226 periodically scans CARQ 220 for pending TARs. Any pending TARs are processed based on the status of flags 414, 416, and 418. For example, if approved flag 416(1) of the first TAR record 402(1) is set equal to zero, then master verification module 304 calls credit approval module 302 to perform the conventional credit approval of TAR 402(1).
Credit approval module 302 performs the conventional credit approval process by means well know to those skilled in the art. Conventional credit approval typically comprises, but is not restricted to, credit approval module 302 comparing purchase price 408(1) and the associated card-holder's 102(x) existing balance to card-holder's 102(x) credit limit 512(x). If the sum of purchase price 408(1) and card-holder's 102(x) existing balance is less than or equal to credit limit 512(x), then credit approval module 302 sets approved flag 416(1) equal to 1. If there are any outstanding discrepancies in the account (e.g., overdue payments), or if the sum of purchase price 408(1) and card-holder's 102(x) existing balance is greater than credit limit 512(x), then credit approval module 302 sets denied flag 418(1) equal to 1.
During the next scan of CARQ 220 master verification module 304 again checks flags 414(1), 416(1), and 418(1) to determine the appropriate action. Note that verified flag 414(1) should still be equal to 0, because the TAR record 402(1) has not yet been processed for verification. If denied flag 418(1) is set equal to 1, then master verification module 304 calls merchant response module 308 to transmit a denial to merchant 104, removes record 402(1) from CARQ 220, and writes a record 602 of the denied transaction in purchase history module 230. If approved flag 416(1) is set equal to 1, then master authorization module 304 retrieves verification requested flag 514(x) to determine whether card-holder 102(x) has selectively disabled the verification process. If verification requested flag 514(x) is set equal to 0, then master verification module 304 automatically sets verified flag 416(1) equal to 1, and leaves TAR record 402(1) in CARQ 220. If verification requested flag 514(x) is equal to 0, then master authorization module 304 transfers TAR record 402(1) to VPQ 228 to await verification by card-holder 102(x).
Master verification module 304 also scans VPQ 228 periodically (e.g., after each scan of CARQ 220) to process any pending TAR records 402 in VPQ 228 for verification. If verified flag 414 of a particular record 402 is set equal to 1, it indicates that the TAR corresponding to record 402 has been verified by card-holder 102(x). The first time TAR record 402(1) is scanned in VPQ 228, verified flag 414(1) and verification initiated flag 415(1) should both be set equal to 0. Master verification module 304 then retrieves record 502(x) from card-holder list 222 to determine whether server 200 should initiate the verification process (e.g., send an e-mail to user 102(x), page user 102(x), place a call to user 102(x), etc.), or whether server 200 should wait for user 102(x) to initiate the verification process. If initiate verification flag 516(x) is set equal to 0, then master verification module sets verification initiated flag 415(1) equal to 1. Setting the. verification initiated flag equal to 1, even though server 200 has not initiated the verification process, eliminates the need to check verification requested flag 516(x) each time VPQ 228 is scanned by master verification module 304.
If, during the first scan of record 402(1) in VPQ 228, master verification module 304 determines that initiate verification flag 516(x) had been set equal to 1, then master verification module 304 calls interactive verification module 306 to initiate the verification process with card-holder 102(x). Interactive verification module 306 then initiates the verification process, sets verification initiated flag 415(1) equal to 1, and returns control to master verification module 304, which retrieves the next record 402 in VPQ 228 for processing.
Master verification module 304 also periodically calls interactive verification module 306 to conduct the actual verification of TARs pending in VPQ 228. Verification of pending TARs is accomplished by establishing a connection with card-holder 102(x) separate from the connection with merchant 104 over which the TAR was originally received, providing additional security compared to prior art electronic transactions such as ATM card purchases. As used herein, the phrase “establishing a connection” is understood to be interpreted in its broadest possible sense to include, but not be limited to, establishing a network connection, establishing a data connection over a modem, establishing a voice connection over a telecommunications device, sending or receiving e-mail, etc. Thus, card-holder 102 could verify pending transaction approval requests by logging onto server 200 via internetwork 110, making a direct modem connection with server 200 via network 114, dialing into server 200 via a telephone, sending an e-mail to server 200, responding to an e-mail from server 200, or any other form of electronic communication.
In an alternate embodiment, system 200 can be modified to allow account-holder 102 to pre-approve certain charges. For example, card-holder list 222 could include a field for pre-approved merchants (or any other desirable criteria). Then, when a transaction approval request is processed, authorization module 226 can compare the merchant identification to the associated card-holder's pre-approved merchant's list, and, if the merchant appears on the list, automatically verify the TAR. Card-holder 102 could access system 200 to modify such pre-approved lists via internetwork 110, network 114, or any other means known for updating customer data.
In the particular embodiment of the present invention shown in FIGS. 1-3, interactive verification module 306 communicates with card-holders 102 via card-holder communications module 224 and network interface 204 and telecommunications device 214. Card-holder communications module 224 periodically polls network interface 204 and telecommunications device 214 for incoming connection requests (e.g., e-mail, network connection, phone call, etc.) and establishes any such connections. Such communications programs (e.g., e-mail software, network protocols, etc.) are well known to those skilled in the art, and are not therefore described in detail so as not to unnecessarily obscure the present invention.
Interactive verification module 306 polls card-holder communications module 224 to determine whether there are any established connections with card-holders 102, and processes each established connection. Assuming card-holder 102(x) has established a connection with server 200, the verification of pending TARs proceeds as follows. The connection request should identify card-holder 102(x) (e.g., by credit card number), and optionally includes an authentication code (e.g., a personal identification number (PIN)) to authenticate card-holder 102(x). Interactive verification module 306 uses the identification information in the connection request to retrieve record 502(x) corresponding to card-holder 102(x) from card-holder list 222. Then, interactive verification module 306 compares the PIN provided in the connection request with PIN 506(x) to authenticate the card-holder. If the PINs do not match, the connection is terminated. If the PINs match, the verification process proceeds.
Those skilled in the art will understand that the connection with card-holder 102(x) need not be terminated the first time an incorrect PIN is received. For example, conventional network security systems typically allow a predetermined number of incorrect entries prior to disconnecting a user. Alternatively, security measures such as stalling the user attempting to access the system, while a trace of the connection is initiated, can be employed.
Next, interactive verification module 306 scans verification pending queue 228 for all TARs with a credit card number 402 matching credit card number 504(x) of card-holder 102(x). Each matching TAR is then presented to card-holder 102(x) to be verified disclaimed. If card-holder 102(x) verifies a particular transaction, then interactive verification module 306 sets the verified flag 414 of that TAR record to equal 1. If card-holder 102(x) disclaims the transaction (e.g., because the purchase was unauthorized), then interactive verification module 306 sets the denied flag 418 of the TAR record to equal 1.
There are many possible ways to present pending TARs to card-holder 102(x) and to receive verification instructions from card-holder 102(x), depending on the type of connection established with server 200. For example, if card-holder 102 establishes an HTTP connection with server 200, then pending TARs could be presented in the form of an Internet web page. Alternatively, if the connection between card-holder 102(x) and server 200 is a telephone voice connection, then pending TARs can be presented to card-holder 102(x) via an automated text to speech system, such as are well known in the art. Card-holder 102(x) could then transmit verification instructions via voice or keypad commands (e.g. touching button 1 to verify; or touching button 2 to disclaim). As yet another example, in the case where the connection request is in the form of an e-mail response, the e-mail response can include verification instructions (e.g., in the subject line of the e-mail) that can be automatically processed by interactive verification module 306. While using any of the above-described types of connections to verify TARs is considered to be a novel aspect of the present invention, no particular type of connection is considered to be an essential element of the present invention.
After interactive verification module 306 has processed any connection requests, control is returned to master verification module 304, which scans VPQ 228 and transfers any TAR records whose verified flag 414 or denied flag 418 has been set equal to 1. Additionally, master verification module 304 scans all records 402 remaining in VPQ 228, and compares the value in the purchase date and time field 412 with the date and time provided by system clock 212. If the resulting time difference exceeds a predetermined time interval (e.g., 24 hours), then master verification module 304 sets the denied flag 418 of the associated record 402 equal to 1 and transfers the record 402 to CARQ 220.
During the next scan of CARQ 220, master verification module 304 will locate any TAR records that have both verified flag 414 and approved flag 416 set equal to 1, call merchant response module to transmit an approval to the merchant identified in field 410 of the record, remove the record from CARQ 220, and write a record 602 into purchase history data 230 to document the completed transaction. Records whose denied flags 418 are found to be set equal to 1 are handled similarly, except that a denial is transmitted to the identified merchant instead of an approval.
FIG. 7 is a flowchart summarizing a method 700 of processing a TAR in accordance with the present invention. In a first step 702 merchant communications module 232 receives a TAR including a full credit card number from a merchant 104, generates a TAR record 402, and writes TAR record 402 into CARQ 220. In a second step 704 authorization module 226 subjects TAR record 402 to a conventional credit approval process, and sets approved flag 416 or denied flag 418 to indicate whether the requested credit is approved or denied. In a third step 706, authorization module 226 determines from flags 416 and 418 whether the requested credit has been approved or denied. If in third step 706, authorization module 226 determines that the requested credit has been approved, then in a fourth step 708 authorization module 226 determines whether card-holder 102 has selectively disabled the verification process. If the verification process has not been selectively disabled, then in a fifth step 710 authorization module 226 verifies the transaction with card-holder 102. Then, in a sixth step 712 authorization module 226 determines whether the TAR has been verified by card-holder 102. If the TAR has been verified, then in a seventh step 714 merchant communications module 232 transmits a transaction approval to merchant 104. Next, in an eighth step 716, authorization module 226 determines whether there are any more TAR records in CARQ 220. If there are no more records in CARQ 220, then method 700 ends.
If in third step 706 authorization module 226 determines that the credit request has been denied, then method 700 proceeds to a ninth step 718 where merchant communications module 232 transmits a denial to merchant 104. If in fourth step 708, authorization module 226 determines that the verification process has been selectively disabled, then method 700 proceeds to seventh step 714 where merchant communications module 232 transmits an approval to merchant 104. If in sixth step 712, authorization module 226 determines that the TAR has not been verified by card-holder 102, then method 700 proceeds to ninth step 718 where merchant communications module 232 transmits a denial to merchant 104. Finally, if in eighth step 716, authorization module 226 determines that there are more pending TAR records in CARQ 220, then method 700 returns to first step 702 to process the next record in CARQ 220.
FIG. 8 is a flowchart summarizing a method 800 for implementing the selective disabling of the TAR verification process according to a particular embodiment of the present invention.
In a first step 802, authorization module 226 determines if CARQ 220 is empty. If CARQ 220 is not empty, then in a second step 804 authorization module 226 reads the first TAR record in CARQ 220. Then, in a third step 806, authorization module 226 associates the first TAR with a card-holder 102 and retrieves a card-holder record 502 corresponding to the particular card-holder from card-holder list 222. In a fourth step 808, authorization module 226 determines from card-holder record 502 whether card-holder 102 has requested that TARs be verified with card-holder 102 prior to transmitting an approval to merchant 104. If it is determined that card-holder verification is requested (i.e., enabled), then in a fifth step 810 authorization module 226 transfers the associated TAR record to VPQ 228. Next, in a sixth step 812, authorization module 226 determines whether the last record in CARQ 220 has been processed, and if so then method 800 ends.
If, in fourth step 808, authorization module 226 determines that verification is not required (i.e., disabled), then in a seventh step 814 verified flag 414 is automatically set to 1 to indicate that the TAR has been verified. If in sixth step 812, authorization module 226 determines that the last record in CARQ 220 has not been processed, then method 800 returns to second step 804 to begin processing the next record in CARQ 220.
FIG. 9 is a flowchart summarizing a particular method 900 for verifying a TAR in accordance with the present invention. In a first step 902 authorization module 226 determines whether VPQ 228 is empty. If VPQ 228 is not empty, then in a second step 904 authorization module 226 reads the first TAR record 402 in VPQ 228. In a third step 906 authorization module 226 determines whether TAR record 402 has been previously denied (e.g., denied flag 418=1). If TAR record 402 has not been previously denied, then in a fourth step 908 authorization module 226 determines if the current TAR has been previously verified (e.g. verified flag 414=1). If the TAR has not yet been verified, then in a fifth step 910 authorization module 226 determines whether the verification process has already been initiated by server 200 (e.g., verification initiated flag 415=1). If the verification initiated flag 415 is equal to 1, then in a sixth step 912 authorization module 226 determines if there has been a lapse of a predetermined time period since the current TAR was received by server 200 (e.g. read purchase date and time 412 and compare to system clock 212). If the predetermined time period has lapsed, then in a seventh step 914 authorization module 226 automatically disclaims the TAR (e.g. sets denied flag=1), and, in an eighth step 916, transfers the TAR record to CARQ 220. In a ninth step 918 authorization module 226 determines if the last record in VPQ 228 has been processed. If all the records in VPQ have been processed, then in a tenth step 920 authorization module 226 performs the card-holder verification process for any TAR records remaining in VPQ 228.
If, in first step 902, authorization module 226 determines that VPQ 228 is empty, then method 900 ends. If, in third step 906, authorization module 226 determines that the TAR record being processed has been denied, then method 900 proceeds directly to eighth step 916. Similarly, if in fourth step 908 authorization module 226 determines that the TAR record being processed has been previously verified, then method 900 proceeds to eighth step 916.
If in fifth step 910, authorization module 226 determines that verification initiated flag 415 is equal to 0, then method 900 proceeds to an eleventh step 922 where authorization module 226 further determines whether the verification process should be initiated by authorization module 226 (e.g. initiate verification flag 516=1). If, in eleventh step 922, authorization module 226 determines that it is to initiate the verification process with card-holder 102, then in a twelfth step 924 server 200 initiates the verification process with card-holder 102, and in a thirteenth step 926 sets the initiated verification flag equal to 1. Then, method 900 proceeds to eighth step 916. If, in eleventh step 922, authorization module 226 determines that the initiate verification flag 516 is set equal to 0, then method 900 proceeds directly to thirteenth step 926.
If in sixth step 912 authorization module 226 determines that the predetermined time interval has not lapsed, then method 900 proceeds to eighth step 916. If, in ninth step 918, authorization module 226 determines that there are additional TAR records in VPQ 228, then method 900 returns to second step 904 to process the next TAR record.
FIG. 10 is a flowchart summarizing a method 1000 of verifying pending TARs with card-holder 102. In a first step 1002, card-holder communications module 224 polls network interface 204 and telecommunications device 214 to determine whether there are any card-holder communication requests (e.g. a telephone call, network connection requests, etc.) from card-holder 102, and if so then in second step 1004, authorization module 226 calls interactive verification module 306 to establish a connection with card-holder 102. In a third step 1006, interactive verification module 306 authenticates card-holder 102 (e.g. requires an authentication code), and in a fourth step 1008 searches VPQ 228 for records related to card-holder 102. Then, in a fifth step 1010, interactive verification module 306 presents at least a portion of a pending TAR (sufficient for card-holder recognition) to card-holder 102. Next, in a sixth step 1012, interactive verification module polls the established connection to determine whether card-holder 102 has transmitted instructions to verify the presented TAR. If there are no instructions from card-holder 102 to verify the TAR, then in a seventh step 1014 interactive verification module 306 determines whether card-holder 102 has transmitted instructions to disclaim the TAR. If there are no instructions to disclaim the TAR, then in an eighth step 1016 interactive verification module 306 determines whether the last pending TAR associated with card-holder 102 has been processed. If the last pending TAR has been processed, then in a ninth step 1018 interactive verification module 306 terminates the established connection with card-holder 102, and method 1000 returns to step 1002 to determine whether there are any communication requests from other card-holders. If, in first step 1002, card-holder communications module 224 determines that there are no card-holder communication requests, then method 1000 ends.
If in sixth step 1012, interactive verification module 306 receives instructions from card-holder 102 to verify the presented TAR, then in a tenth step 1020 interactive verification module 306 sets verified flag 414 of the TAR record 402 to a value of 1, indicating the TAR has been verified. Then, method 1000 returns to fifth step 1010. Similarly, if in seventh step 1014, interactive verification module 306 receives instructions from card-holder 102 to disclaim the presented TAR, then in an eleventh step 1022 interactive verification module 306 sets denied flag 418 of the TAR record 402 to a value of 1, indicating the TAR has been disclaimed. Then, method 1000 returns to fifth step 1010.
If, in eighth step 1016, interactive verification module 306 determines that the last pending request for the particular card-holder has not been processed, then method 1000 returns to fifth step 1010 to process the next pending TAR for the particular card-holder.
FIG. 11 is a block diagram of an alternate server 200A. Server 200A functions similar to server 200 of FIG. 2, except that server 200A includes pre-verification criteria (PVC) 1102 and an alternate authorization module 226A. Authorization module 226A controls and coordinates the approval and verification of TARs, and, in addition to the functions performed by authorization module 226, uses pre-verification criteria 1102 to automatically verify any TAR meeting the requirements of pre-verification criteria 1102. The use of pre-verification criteria 1102 facilitates accelerated verification of TARs, because authorization module 226A does not need to wait for direct verification by card-holder 102.
Pre-verification criteria 1102 is a database that includes individualized pre-verification criteria for each current customer of credit card company 106, including card-holder 102. Pre-verification criteria typically include, but are not limited to, merchant identifiers, a maximum purchase price, and specified dates between which purchases can be automatically verified by authorization module 226A. Those skilled in the art will understand that pre-verification criteria module 1102 would typically be a very large file. Therefore, while pre-verification criteria module 1102 is shown in memory 216, it should be understood that the entire customer files would likely be stored in a mass data storage system such as non-volatile memory 208, with portions of the entire list being swapped in and out of pre-verification criteria module 1102 as necessary.
Initially, pre-verification criteria are determined by credit card company 106 at the time the credit card account is opened, so that no purchases can be verified by the pre-verification criteria. In other words, the initial default value of the pre-verification criteria for each account is set such that no TAR could meet the pre-verification criteria (e.g., maximum purchase price=0). Alternately, the pre-verification criteria may be determined by card-holder 102 when the account is opened (e.g. on their credit card application). In either case, card-holder 102 can modify their pre-verification criteria over a secure network (e.g. via telephone or modem access), as will be described below.
FIG. 12 shows a block diagram of authorization module 226A to include a credit approval module 302, an alternate master verification module 304A, an interactive verification module 306, and a merchant response module 308. Credit approval module 302 executes conventional credit approval for each TAR contained in CARQ 220 by means well known to those skilled in the art. Master verification module 304A coordinates the authorization and verification processes, including verification using pre-verification criteria, and is responsible for overall control of authorization module 226A. Interactive verification module 306A carries out verification with card-holder 102, and coordinates modification of pre-verification criteria by card-holder 102. Merchant response module 308 initiates final communication with merchant 104 by transmitting either a transaction approval or a transaction denial.
FIG. 13 shows an example of a pre-verification criteria data structure 1300 suitable for use with a particular embodiment of the present invention. Those skilled in the art will recognize data structure 1300 as a linked-list of records 1302(1-n). Each record 1302(1-n) represents pre-verification criteria associated with a particular card-holder, and includes a full credit card number 1304, a first merchant identifier 1306(1), an rth merchant identifier 1306(r), a maximum pre-verified purchase price 1310, a pair of pre-verification dates 1312, miscellaneous pre-verification criteria 1314, and a pointer 1316. Full credit card number 1304 associates a pre-verification criteria record 1302(a) with a specific card-holder 102(a). Merchant identifiers 1306(1-r) each contain information similar to merchant information 410 contained in each TAR. Merchant identifiers 1306(1-r) each identify a certain pre-verified merchants for each card-holder. TARs received from pre-verified merchants are automatically verified by authorization module 226A. Pre-verified purchase price 1310 sets a maximum purchase price for automatic verification. Any TAR including a purchase price 408 that is lower than pre-verified purchase price 1310 is automatically verified by authorization module 226A. Pre-verification dates 1312 include a begin date and an end date. Any TAR including a purchase date 412 that falls between the begin date and end date of pre-verification dates 1314 is automatically verified by authorization module 226A. Miscellaneous pre-verification criteria 1314 are included to illustrate that particular criteria other than those specifically listed above can be used to cause authorization module 226A to verify a TAR. For example, card-holder 102 may want to specify particular hours of the day when purchases should be automatically verified. For such a case, miscellaneous pre-verification criteria 1314 would include a start time and a stop time. Pointer 1316(a) indicates the memory address of the next record 1316(a+1) in the list. The last record 1302(n) includes an end of list value 1318 that indicates that record 1302(n) is the last record in the list.
FIG. 14 is a flowchart summarizing one method 800A for implementing the automatic verification of a TAR using pre-verification criteria according to a particular embodiment of the present invention. In a first step 802, authorization module 226A determines if CARQ 220 is empty. If CARQ is empty, then method 800A ends. If CARQ 220 is not empty, then in a second step 804, authorization module 226A reads the first TAR record in CARQ 220. Then, in a third step 806, authorization module 226A associates the first TAR with a card-holder 102 and retrieves a card-holder record 502 corresponding to the particular card-holder from card-holder list 222. In a fourth step 808, authorization module 226A determines from card-holder record 502 whether card-holder 102 has requested that TARs be verified with card-holder 102 prior to transmitting an approval to merchant 104. If it is determined that card-holder verification is requested (i.e., enabled), then in a fifth step 809 authorization module 226A determines if the pre-verification criteria associated with card-holder 102 have been satisfied. If in fifth step 809 the pre-verification requirements are not satisfied, then in a sixth step 810 authorization module 226A transfers the associated TAR record to VPQ 228. Next, in a seventh step 812, authorization module 226A determines whether the last record in CARQ 220 has been processed, and if so then method 800A ends.
If, in fourth step 808, authorization module 226A determines that verification is not required (i.e., disabled), then method 800A proceeds to an eighth step 814 where authorization module 226A sets verified flag 414 to 1 to indicate that the TAR has been verified. Similarly, if in fifth step 809 authorization module 226A determines that the pre-verification criteria have been satisfied, then method 800A proceeds to eighth step 814 where authorization module 226A sets verified flag 414 to 1. If in seventh step 812, authorization module 226A determines that the last record in CARQ 220 has not been processed, then method 800A returns to second step 804 to begin processing the next record in CARQ 220.
FIG. 15 is a flowchart showing one method 1500 of performing fifth step 809 (determining whether the pre-verification criteria are met) of the method of FIG. 14. In a first step 1502, authorization module 226A retrieves record 1302(a) of pre-verification criteria 1102 associated with the card-holder (e.g. card-holder 102(a)) identified in the TAR. In a second step 1504, authorization module 226A determines whether one of merchant identifiers 1306(a)(1-r) of record 1302(a) corresponds with the merchant information 410 contained in the TAR. If none of merchant identifiers 1306(a)(1-r) of record 1302(a) identify the merchant, then in a third step 1506 authorization module 226A determines whether the purchase price 408 of the TAR is below the maximum pre-verified purchase price 1310(a). If purchase price 408 of the TAR is not below the maximum pre-verified purchase price 1310(a), then in a fourth step 1508 authorization module 226A determines if purchase date 412 of the TAR falls within pre-verified dates 1312(a). If purchase date 412 does not fall within the dates specified in pre-verified dates 1312(a), then in a fifth step 1510 authorization module 226A determines whether miscellaneous pre-verification criteria 1314(a) are satisfied. If miscellaneous pre-verification criteria 1314 are not satisfied or the card-holder has not specified any miscellaneous criteria 1314, then method 1500 determines that the pre-verification criteria have not been met.
If in a second step 1504, authorization module 226A determines that one of merchant identifiers 1306(1-r) of record 1302(a) corresponds with the merchant information 410 contained in the TAR, then method 1500 determines that the pre-verification criteria have been met. If in third step 1506, authorization module 226A determines that purchase price 408 is below pre-verified purchase price 1310(a), then method 1500 determines that the pre-verification criteria have been met. Similarly, if in fourth step 1508, authorization module 226A determines that purchase date 412 of the TAR falls within pre-verified purchase dates 1312(a), then method 1500 determines that the pre-verification criteria have been met. Finally, if in fifth step 1510 authorization module 226A determines the miscellaneous pre-verification criteria 1314(a) are met by the pending TAR, then method 1500 determines that the pre-verification criteria have been met. Those skilled in the art will recognize that method 1500 will determine that a particular TAR meets the pre-verification criteria, and is therefore automatically verified, if any one of the various criteria (e.g., the maximum purchase price) are met.
FIG. 15A is a flowchart showing an alternate method 1500A of performing step 809 of the method of FIG. 14, wherein all of the pre-verification criteria must be met before a TAR is automatically verified. In a first step 1502, authorization module 226A retrieves record 1302(a) of pre-verification criteria 1102 associated with the card-holder (e.g. card-holder 102(a)) identified in the TAR being processed by authorization module 226A. In a second step 1504A, authorization module 226A determines whether one of merchant identifiers 1306(1-r) of record 1302(a) corresponds with the merchant information 410 contained in the TAR. If none of merchant identifiers 1306(1-r) of record 1302(a) identify the merchant, then method 1500A determines that the pre-verification criteria are not met by the pending TAR, and method 1500A ends. However, if one of merchant identifiers 1306(1-r) of record 1302(a) do correspond to the merchant identified in the TAR, then method 1500A proceeds to a third step 1506A wherein authorization module 226A determines whether the purchase price 408 of the TAR is below the maximum pre-verified purchase price 1310(a). If purchase price 408 of the TAR is not below the maximum pre-verified purchase price 1310(a), then method 1500A determines that the pre-verification criteria are not met, and the method ends. If purchase price 408 of the TAR is below the maximum pre-verified purchase price 1310(a), then in a fourth step 1508A authorization module 226A determines if purchase date 412 of the TAR falls within pre-verified dates 1312(a). If purchase date 412 does not fall within the dates specified in pre-verified dates 1312(a), then method 1500A determines that the pre-verification criteria are not met, and the method ends. If purchase date 412 does fall within the dates specified in pre-verified dates 1312(a), then in a fifth step 1510A authorization module 226A determines whether miscellaneous pre-verification criteria 1314(a) are satisfied. If miscellaneous pre-verification criteria 1314(a) are not satisfied or the card-holder has not specified any miscellaneous criteria 1314(a), then method 1500 determines that the pre-verification criteria have not been met, and method 1500A ends. However, if miscellaneous pre-verification criteria 1314(a) are satisfied, then method 1500 determines that the pre-verification criteria have been met, and the pending TAR should be automatically verified.
FIG. 16 is a flowchart summarizing one method 1600 for permitting card-holder 102 to modify associated pre-verification criteria 1302. Interactive verification module 306A can perform the same functions as interactive verification module 306, but is further operative to coordinate and control modification of pre-verification criteria records 1302(1-n). In a first step 1602, card-holder communications module 224 polls network interface 204 and telecommunications device 214 to determine whether there are any card-holder communication requests (e.g. a telephone call, network connection requests, etc.) from card-holder 102, and if so then in a second step 1604, interactive verification module 306A establishes a connection with card-holder 102. In a third step 1606, interactive verification module authenticates card-holder 102 (e.g. requires an authentication code) and in a fourth step 1608 interactive verification module 306A retrieves pre-verification criteria 1302 associated with card-holder 102. In a fifth step 1610 interactive verification module 306A determines if card-holder 102 wishes to modify pre-verification criteria 1302 (e.g., receives a touch tone response to a pre-recorded menu). If interactive verification module 306A determines that card-holder 102 wishes to modify pre-verification criteria 1302, then, in a sixth step 1612, interactive verification module 306A presents the first pre-verification criteria (e.g. merchant identifier 1306(1)(1) to card-holder 102. Next, in a seventh step 1614, interactive verification module 306A determines if card-holder 102 wishes to modify the criteria presented in step 1612. If card-holder 102 chooses not to modify the presented pre-verification criteria 1302, then, in eighth step 1616, interactive verification module determines if card-holder 102 wants to proceed to the next pre-verification criteria (e.g. merchant identifier 1306(2)). If the card-holder 102 does not want to continue pre-verification criteria modification, interactive verification module 306A terminates connection with card-holder 102 in ninth step 1618.
If, in first step 1602, there are no communication requests from card-holders, then method 1600 ends. If, in step 1610, card-holder 102 does not want to modify any pre-verification criteria, then method 1600 proceeds to ninth step 1618, where interactive verification module 306A terminates the connection with card-holder 102. If in step 1614 card-holder 102 wishes to modify the presented pre-verification data, then interactive verification module 306A initiates a tenth step 1620, wherein new data is received from card-holder 102, and the new data is substituted for the presented pre-verification criteria before method 1600 proceeds to eighth step 1616. If in eighth step 1616 receives instructions card-holder 102 to make more modifications to pre-verification criteria 1302, then method 1600 returns to step 1610.
FIG. 17 is a block diagram of another alternate server 200B. Server 200B functions similar to server 200 of FIG. 2 and/or server 200A of FIG. 11, except that server 200B includes an activation database 1702 and an alternate authorization module 226B. Authorization module 226B controls and coordinates the approval and verification of TARs and, in addition to the functions performed by authorization modules 226, 226A, evaluates the activation status of card-holder 102's account and automatically denies any TAR having a transaction date and time corresponding to a date and time when card-holder 102's credit account is/was deactivated. Automatically denying every TAR having a transaction date falling within a deactivated time period of the credit account reduces the chance of an unauthorized user successfully making fraudulent purchases with the card-holder's credit account.
Activation database 1702 is a database that includes activation data/conditions for current customers of credit card company 106, including card-holder 102. Activation conditions can include, but are not limited to, particular dates and/or times input by card-holder 102 to either activate or deactivate their account, particular dates and time when card-holder 102 activates or deactivates the account, or other specific activation and deactivation criteria defined by card-holder 102. For example, card-holder 102 could specify times of the day only during which the credit card would be activated. As another example, card-holder 102's credit card could be automatically deactivated after a predetermined number (e.g., one) of transaction approval requests are received. Card-holder 102 could either define such criteria when the account is opened (e.g., on the application form) or after the account is opened by connecting remotely with server 200B via card-holder communications module 224.
It should also be noted that activation database 1702 would typically be a very large file. Therefore, while activation database 1702 is shown in memory 216, it should be understood that the entire customer files would likely be stored in a mass data storage system such as non-volatile memory 208, with portions of the entire database being swapped in and out of activation database 1702 as necessary.
FIG. 18 shows a block diagram of authorization module 226B to include a credit approval module 302, an alternate master verification module 304B, an interactive verification module 306, a merchant response module 308, and an interactive activation module 1802. Credit approval module 302 executes conventional credit approval for each TAR contained in CARQ 220 by means well known to those skilled in the art. Master verification module 304B coordinates the authorization and verification processes, including determining the activation status of an account, and is responsible for overall control of authorization module 226B. Interactive verification module 306 carries out verification with card-holder 102. Merchant response module 308 communicates with merchant 104 by transmitting either a transaction approval or a transaction denial. Interactive activation module 1802 coordinates modification of the activation status of the account associated with card-holder 102. After establishing a connection with and authenticating card-holder 102 (e.g., via card-holder communications module 224), interactive activation module 1802 is operative to present the current activation status of card-holder 102's account, and to receive modification instructions from card-holder 102 to change the activation status of the associated account. Optionally, interactive activation module 1802 is operative to transfer card-holder 102 to interactive verification module 306 such that card-holder 102 can verify pending TARs or modify pre-verification criteria if authorization module 226B also includes the functions of authorization module 226A.
FIG. 19 shows an example of an activation data structure 1900 suitable for use in activation database 1702 of the present invention. Activation data structure 1900 includes a linked list of activation records 1902(1)-1902(n) associated with customer accounts of credit card company 106, including card-holder 102's account. Each record 1902(1-n) includes an account identifier (e.g., a credit card number) field 1904, and a series of activation and deactivation conditions/entries including an automatic activation date and time field 1906, an automatic deactivation date and time field 1908, a first activation field 1910(1), a first deactivation field 1912(1), a last activation field 1910(r), a last deactivation field 1912(r), and a pointer field 1914 pointing to the next activation record 1902. Activation record 1902(n) includes an “End of List” record 1916 instead of pointer 1914, indicating that activation record 1902(n) is the last activation record in activation database 1702.
Credit card number field 1904 is the key field of each activation record 1902, and is used to identify activation settings/entries associated with a particular customer of credit card company 106 (e.g., card-holder 102). Automatic activation and deactivation date and time fields 1906 and 1908 store automatic activation and deactivation data associated with card-holder 102. For example, card-holder 102 could set auto-activation field 1906 to automatically activate his/her credit card each morning at 8:00 a.m., and set auto-deactivation field 1908 to automatically deactivate his/her credit card each evening at 8:00 p.m. As another option, card-holder 102 could set automatic activation field 1906 and automatic deactivation field 1908 to automatically deactivate his/her credit card over the weekdays, or alternately the weekends, of each month. Indeed, any desirable automatic “on-off” schedule can be specified by card-holder 102. Activation date and time field 1910(x)(1) stores the date and time card-holder 102 initially activates his/her credit card, where (x) represents the activation record 1902(x) associated with card-holder 102 (e.g., record 1902(1)(1)). De-activation date and time field 1912(x)(1) indicates the first date and time that card-holder 102 selectively deactivated their credit card (e.g., via telephone, secure website, etc.), such that transactions could no longer be made. Additional activation and deactivation fields are added to each record 1902, as the credit card is subsequently activated and deactivated by card-holder 102. The last (i.e., the most recent) activation record 1910(x)(r) and deactivation record 1912(x)(r) are stored in card-holder 102's activation record 1902(x), followed by a pointer 1914(x), pointing to the next activation record 1902(x+1). The final activation record 1902(n) has an “end of list” indicator 1916 instead of a pointer 1914 indicating that activation record 1902(n) is the final record in activation database 1702. Although data structure 1900 is illustrated as a simple liked list, it should be understood that data structure 1900 can be implemented in a relational database containing records including similar data fields.
Master verification module 304B utilizes the activation data stored in each activation record 1902 as follows. Once a TAR is received and associated with a particular card-holder, master verification module 304B determines the state of activation of the card-holder's account based on the purchase date and time included in the TAR. If the purchase date and time falls during a time when the card-holder's credit card was deactivated, then master verification module 304B is operative to automatically deny the TAR. As shown in records 1902(1-n), a deactivated purchase date and time would correspond to any date and time defined by Auto Deactivation date and time field 1908, or any time period between a deactivation date and time and the following reactivation date and time stored in record 1902. For example, if auto-deactivation date and time field 1908 indicated that the card-holder's account is automatically deactivated at the beginning of each weekend, and a TAR was received having a purchase date and time corresponding to a weekend date, then master verification module 304B would be operative to set denied flag 418 to a value of 1 (e.g., denied) because the purchase was made on a weekend (assuming the card-holder did not reactivate the card over the weekend in question). As another example, if the purchase was made after the deactivation date and time stored in deactivation date and time field 1912(x)(1), and before the re-activation date stored in activation date and time field 1910(x)(2), the TAR would also be denied.
In the presently described embodiment, the information stored in activation and deactivation fields 1910(x)(1)-1910(x)(r) and 1912(x)(1)-1912(x)(r) and the automatic activation and deactivation data stored in fields 1904(1) and 1906(1) are all evaluated during the approval process. Thus, card-holder 102 can activate the account after an automatic deactivation, but prior to the next automatic activation, simply by making a new activation entry 1910 in record 1902. Accordingly, there are no conflicts between automatic activation/deactivation and subsequent card-holder activations/deactivations. Rather, all activation/deactivation data, whether automatic or individually entered, are considered as equally valid points on a time line.
Storing activation and deactivation data in database 1702 also provides another particular advantage. In cases where TARs are not sent to the credit card company for several days after the transaction is initiated, the card-holder may still deactivate their card without worry of TARs of earlier transactions being denied. Master verification module 304B, when receiving a TAR, is operative to compare the purchase date and time included in the TAR with each of activation records 1910(x)(1)-1910(x)(r) and each of deactivation records 1912(x)(1)-1912(x)(r). Therefore, as long as the purchase date and time included with the TAR is correct and corresponds with an activated state, the TAR is passed to the previously described credit approval and verification processes for processing.
FIG. 20 is a flowchart summarizing a method 2000 of processing a TAR in accordance with one particular embodiment of the present invention. In a first step 2002 merchant communications module 232 of server 200B receives a TAR including an account identifier (e.g., a credit card number) from a merchant 104, generates a TAR record 402, and writes TAR record 402 into CARQ 220. In a second step 2004, authorization module 226B determines if card-holder 102 has selectively deactivated their credit card. If not, then in a third step 2006 authorization module 226B subjects TAR record 402 to a conventional credit approval process, and sets approved flag 416 or denied flag 418 to indicate whether the requested credit is approved or denied. In a fourth step 2008, authorization module 226B determines from flags 416 and 418 whether the requested credit has been approved or denied. If, in fourth step 2008, authorization module 226B determines that the requested credit has been approved, then in a fifth step 2010 authorization module 226B determines whether card-holder 102 has selectively disabled the verification process. If the verification process has not been selectively disabled, then in a sixth step 2012 authorization module 226B verifies the transaction with card-holder 102. Then, in a seventh step 2014 authorization module 226B determines whether the TAR has been verified by card-holder 102. If the TAR has been verified, then in an eighth step 2016 merchant communications module 232 transmits a transaction approval to merchant 104. Next, in a ninth step 2018, authorization module 226B determines whether there are any more TAR records in CARQ 220. If there are no more records in CARQ 220, then method 2000 ends.
If, in second step 2004, authorization module 226B determines that card-holder 102 has deactivated their credit card, then method 2000 proceeds to a tenth step 2020 where merchant communications module 232 transmits a denial to merchant 104. If, in fourth step 2008, authorization module 226B determines that the credit request has been denied, then method 2000 proceeds to tenth step 2020 where merchant communications module 232 transmits a denial to merchant 104. If, in fifth step 2010, authorization module 226B determines that the verification process has been selectively disabled, then method 2000 proceeds to eighth step 2016 where merchant communications module 232 transmits an approval to merchant 104. If, in seventh step 2014, authorization module 226B determines that the TAR has not been verified by card-holder 102, then method 2000 proceeds to tenth step 2020 where merchant communications module 232 transmits a denial to merchant 104. Finally, if in ninth step 2018 authorization module 226B determines that there are more pending TAR records in CARQ 220, then method 2000 returns to first step 2002 to process the next record in CARQ 220.
FIG. 21 is a flowchart summarizing one method 2100 for permitting card-holder 102 to modify the activation status of his/her account. In a first step 2102, card-holder communications module 224 polls network interface 204 and telecommunications device 214 to determine whether there are any card-holder communication requests (e.g. a telephone call, network connection requests, etc.) from card-holder 102, and if so then in a second step 2104, interactive activation module 1802 establishes a connection with card-holder 102. In a third step 2106, interactive activation module 1802 authenticates card-holder 102 (e.g. requires an authentication code), and in a fourth step 2108 interactive activation module 1802 retrieves the activation status of the credit card account associated with card-holder 102. In a fifth step 2110 interactive activation module 1802 determines if card-holder 102 wishes to modify the activation status of the credit card (e.g., receives a prompt from a pre-recorded menu). If card-holder 102 wishes to modify the activation status of the account, method 2100 proceeds to a sixth step 2112, where card-holder 102 can set the activation status of the credit account, optionally including defining automatic activation and deactivation date and times or other activation/deactivation data. Then, in a seventh step 2114, interactive activation module 1802 terminates the connection with card-holder 102.
If in fifth step 2110, card-holder 102 does not wish to modify the activation status of the credit card, method 2100 proceeds to seventh step 2114 and terminates the connection with card-holder 102. Optionally, interactive activation module 1802 could instead transfer card-holder 102 to interactive verification module 306 (or 306A), or some other service module, where the card-holder could instruct interactive verification module 306 (or 306A) to verify TARs or modify pre-verification criteria 1302.
FIG. 22 is a flowchart summarizing one method 2200 for making commercial transactions according to the present invention, including card-holder 102 selectively activating and deactivating a credit account. In a first step 2202, card-holder 102 activates the credit card via conventional means, such as by calling an automated service when their credit card is first received in the mail. The initial activation date and time is stored in the first activation field (e.g., activation date and time field 1910(1)(1)) of the record 1902(x) in activation database 1702 associated with card holder 102. In a second step 2204, card-holder 102 makes one or more purchases with the credit card. Then, in a third step 2206 card-holder 102 deactivates the credit card by, for example, connecting with server 200B, via card-holder communications module 224, and instructing interactive activation module 1802 to record a deactivation date and time in an associated activation record 1902 (e.g., in deactivation date and time 1912(1)(1)). Next, in a fourth step 2208, card-holder 102 determines if he/she needs to make any further commercial transactions. If more transactions are desired, card-holder 102 reconnects with server 200B and reactivates the credit card by instructing interactive activation module 1802 to record a next activation date and time (e.g., activation date and time 1910(1)(2)), so that additional purchase can be made.
However, if in step 2208 no further transactions are necessary, the credit account associated with card-holder 102 remains deactivated and protected, thereby preventing unauthorized use of card-holder 102's account.
FIG. 23 shows a credit card 2300 having a front side 2302 and a back side 2304. Front side 2302 of credit card 2300 has account indicia including an account number 2306, an expiration date 2308, and the name 2310 of a card-holder (e.g., card-holder 102). Front side 2302 of card 2300 also includes security indicia 2312.
Account number 2306, expiration date 2308, and name 2310 are common features of credit cards and are associated with the credit account of card-holder 102. Security indicia 2312, however, is an inventive feature that indicates that transactions made with card 2300 are protected by one or more security features, including but not limited to the security features of the present invention. Security indicia 2312 alerts would-be thieves that attempts to make illegal transactions using credit card 2300 and/or the associated credit account number 2306 would be difficult, because purchases require account-holder verification.
Back side 2304 of credit card 2300 includes a magnetic stripe 2314, a signature field 2316, and a second security indicia 2318. Magnetic stripe 2314 contains electronically readable account data such that card 2300 can be swiped through a card reader, and signature field 2316 provides a place for card-holder 102 to sign credit card 2300. Finally, second security indicia 2318 is an inventive feature that provides a more detailed description of the transaction security features associated with the account linked to credit card 2300. Security indicia 2318 (like indicia 2312) deter would-be thieves by indicating that illegally using credit card 2300 will be particularly difficult. It is thought that indicia indicating that account-holder verification is required will be effective to provide a significant reduction in fraudulent use, even if other security features are not fully implemented.
The description of particular embodiments of the present invention is now complete. Many of the described features may be substituted, altered or omitted without departing from the scope of the invention. For example, the present invention may be implemented in conjunction with alternate types of accounts (e.g. debit accounts) requiring secure processing in addition to the credit card type account described herein. As another example, a third party verification company 108 may employ the transaction processing methods described herein on behalf of credit card company 106, and then transmit indicia of verification to credit card company 106. Further, while pre-verification criteria 1102 is shown in FIG. 11 as a separate block, those skilled in the art will understand that pre-verification criteria may instead be stored within other records such as card-holder list 222. Similarly, the functionality of card-holder communications module 224 and interactive verification module 306 can be combined into a single operative module. In fact, the functional modules of the present disclosure are organized and labeled to provide a clear illustration of the invention, and no particular segregation of functionality is considered to be an essential element of the present invention. These and other deviations from the particular embodiments shown will be apparent to those skilled in the art, particularly in view of the foregoing disclosure.

Claims (39)

1. A computer system for approving a commercial transaction between a user with account information and a merchant, said computer system comprising:
a processing unit for processing data and code; and
memory for storing said data and said code, said data and said code together including
a merchant communications module operative to facilitate a connection with said merchant for receiving a transaction approval request (TAR),
activation data accessible to an account-holder, said activation data indicative of the activation status of an account associated with said account-holder and with said account information,
an interactive activation module operative to establish a connection with said account-holder, to receive instructions from said account-holder to modify said activation data, and to modify said activation data according to said instructions received from said account-holder, and
an authorization module responsive to said TAR and operative to deny said TAR if said account associated with said account-holder is deactivated; and wherein
prior to said user initiating said transaction with said merchant, said interactive activation module establishes a first connection with said account-holder, receives activation instructions from said account-holder to activate said account, and modifies said activation data to activate said account, said account being previously deactivated, thereby facilitating approval of said TAR;
subsequent to receipt of said TAR, said interactive activation module establishes a second connection with said account-holder, receives deactivation instructions from said account-holder to deactivate said account, and modifies said activation data to deactivate said account such that subsequent TARs will be denied; and
in the absence of said deactivation instructions, said account remains activated such that subsequent TARs may be approved.
2. A computer system according to claim 1, wherein:
said activation data includes at least one activation condition; and
said authorization module is operative to approve said TAR only if said TAR satisfies said activation condition.
3. A computer system according to claim 2, wherein:
said activation condition comprises an activation date and time corresponding to a date and time that said instructions to activate said account were received from said account-holder; and
said authorization module is operative to approve said TAR only if a purchase date and time contained in said TAR falls after said activation date and time.
4. A computer system according to claim 2, wherein:
said activation data further includes at least one deactivation condition; and
said authorization module is operative to approve said TAR only if said TAR satisfies said activation condition and does not satisfy said deactivation condition.
5. A computer system according to claim 4, wherein:
said deactivation condition comprises a deactivation date and time corresponding to a date and time that said instructions to deactivate said account were received from said account-holder; and
said authorization module is operative to approve said TAR only if said purchase date and time contained in said TAR falls after said activation date and time and before said deactivation date and time.
6. A computer system according to claim 5, wherein:
said activation data includes a second activation condition defining a reactivation date and time corresponding to a date and time that reactivation instructions to reactivate said account were received from said account-holder; and
said authorization module is operative to approve said TAR only if said purchase date and time contained is said TAR falls after said activation date and time and before said deactivation date and time or falls after said reactivation date and time.
7. A computer system according to claim 1, wherein:
said activation data further includes at least one automatic activation or deactivation criteria determined by said account-holder; and
said authorization module is operative to automatically modify said activation data to change the activation status of said account based on said automatic activation or deactivation criteria.
8. A computer system according to claim 7, wherein:
said automatic deactivation criteria facilitates deactivation of said account if a predetermined number of TARs are received within a predetermined time period, said predetermined number of TARs determined by said account-holder; and
said authorization module is operative to automatically deactivate said account by recording a date and time in said activation data corresponding to the date and time at which said predetermined number of TARs is reached.
9. A computer system according to claim 1, wherein:
said code further includes an account-holder communications module operative to facilitate a separate connection with said account-holder for verifying said TAR; and
said authorization module is further operative to transmit an approval to said merchant only if said TAR is verified by said account-holder.
10. A computer system according to claim 1, wherein:
said data further includes at least one pre-verification criteria associated with said account-holder;
said authorization module is operative to transmit an approval to said merchant only if said TAR is verified; and
said authorization module is further operative to compare said TAR with said at least one pre-verification criteria, and to automatically verify said TAR without verifying said TAR with said account-holder if said at least one pre-verification criteria is satisfied.
11. A computer system according to claim 1, wherein:
said interactive activation module establishes said first connection with said account-holder responsive to receiving a first connection request from said account-holder; and
said interactive activation module establishes said second connection with said account-holder responsive to receiving a second connection request from said account-holder, said second connection request received after said first connection with said account-holder has been terminated.
12. A computer system according to claim 1, wherein each time said account is activated, said account remains activated indefinitely until said account is deactivated by said account-holder.
13. A computer system according to claim 12, wherein each time said account is activated, the duration that said account is activated is determined at the time said account is deactivated by said account-holder.
14. A computer system according to claim 1, wherein said user is said account-holder.
15. In a computer system, a method for facilitating commercial transactions between a user with account information and a merchant, said method comprising:
establishing a first connection with said account-holder responsive to receiving a first connection request from said account-holder;
receiving, via said first connection, activation instructions from said account-holder to temporarily activate an account associated with said account-holder and said account information, said account being previously deactivated;
modifying activation data associated with said account to activate said account in response to receiving said activation instructions;
receiving a transaction approval request (TAR) from said merchant, said TAR indicative of a commercial transaction between said user and said merchant;
establishing a second connection with said account-holder responsive to receiving a second connection request from said account-holder;
receiving deactivation instructions from said account-holder to again deactivate said account, said deactivation instructions being received via said second connection and subsequent to said TAR and said activation instructions;
modifying said activation data to deactivate said account in response to receiving said deactivation instructions;
determining whether said account was deactivated at a time associated with said TAR; and
denying said TAR if said account was deactivated at said time associated with said TAR.
16. A method according to claim 15, further comprising:
storing the dates and times that said activation instructions and said deactivation instructions were received; and wherein
said step of determining whether said account was temporarily deactivated includes comparing a purchase date and time included in said TAR with said dates and times that said activation instructions and said deactivation instructions were received; and
said step of denying said TAR includes denying said TAR if said purchase date and time is before said date and time that said activation instructions were received or after said date and time that said deactivation instructions were received.
17. A method according to claim 16, further comprising:
establishing a third connection with said account-holder responsive to receiving a third connection request from said account-holder;
receiving reactivation instructions from said account-holder to again activate said account, said reactivation instructions being received via said third connection and subsequent to receipt of said deactivation instructions;
modifying said activation data to reactivate said account in response to said reactivation instructions; and
storing the date and time that said reactivation instructions were received.
18. A method according to claim 17, further comprising:
receiving a second TAR from a second merchant, said second TAR indicative of a transaction between said user and said second merchant;
determining whether said account was reactivated at a time associated with said second TAR; and
approving said second TAR only if said account was reactivated at said time associated with said second TAR.
19. A method according to claim 18, wherein:
said step of determining whether said account was reactivated includes comparing a purchase date and time included in said second TAR with said date and time that said reactivation instructions were received; and
said step of approving said second TAR includes approving said second TAR only if said purchase date and time of said second TAR is after said date and time that said reactivation instructions were received.
20. A method according to claim 15, further comprising:
storing at least one automatic deactivation criteria associated with said account-holder; and
automatically deactivating said account when said at least one deactivation criteria is met.
21. A method according to claim 20, wherein:
said at least one deactivation criteria includes receiving a predetermined number of TARs; and
said step of automatically temporarily deactivating said account includes deactivating said account after the receipt of said predetermined number of TARs.
22. A method according to claim 15, further comprising:
establishing a separate connection with said account-holder;
verifying said TAR with said account-holder via said separate connection; and
approving said TAR only if said TAR is verified.
23. A method according to claim 15, further comprising:
receiving at least one pre-verification criteria associated with said account-holder;
comparing said TAR with said at least one pre-verification criteria;
automatically verifying said TAR without input from said account-holder if said at least one pre-verification criteria is satisfied; and
approving said TAR only if said TAR is verified.
24. A method according to claim 15, wherein each time said account is activated, said account remains activated indefinitely until said account is deactivated by said account-holder.
25. A method according to claim 24, wherein each time said account is activated, the duration that said account is activated is determined at the time said account is deactivated by said account-holder.
26. A method according to claim 15, wherein said user is said account-holder.
27. A non-transitory, electronically-readable storage medium having code embodied therein for causing an electronic device to perform a method of facilitating commercial transactions between a user with account information and a merchant, said method comprising the steps of:
establishing a first connection with said account-holder responsive to receiving a first connection request from said account-holder;
receiving, via said first connection, activation instructions from said account-holder to temporarily activate an account associated with said account-holder and said account information, said account being previously deactivated;
modifying activation data associated with said account to activate said account in response to receiving said activation instructions;
receiving a transaction approval request (TAR) from said merchant, said TAR indicative of a commercial transaction between said user and said merchant;
establishing a second connection with said account-holder responsive to receiving a second connection request from said account-holder;
receiving deactivation instructions from said account-holder to again deactivate said account, said deactivation instructions being received via said second connection and subsequent to said TAR and said activation instructions;
modifying said activation data to deactivate said account in response to receiving said deactivation instructions;
determining whether said account was deactivated at a time associated with said TAR; and
denying said TAR if said account was deactivated at said time associated with said TAR.
28. A non-transitory, electronically-readable storage medium according to claim 27, wherein:
said method further includes the step of storing the dates and times that said activation instructions and said deactivation instructions were received;
said step of determining whether said account was temporarily deactivated includes comparing a purchase date and time included in said TAR with said dates and times that said activation instructions and said deactivation instructions were received; and
said step of denying said TAR includes denying said TAR if said purchase date and time is before said date and time that said activation instructions were received or after said date and time that said deactivation instructions were received.
29. A non-transitory, electronically-readable storage medium according to claim 28, wherein said method further includes the steps of:
establishing a third connection with said account-holder responsive to receiving a third connection request from said account-holder;
receiving reactivation instructions from said account-holder to again activate said account, said reactivation instructions being received via said third connection and subsequent to receipt of said deactivation instructions;
modifying said activation data to reactivate said account in response to said reactivation instructions; and
storing the date and time that said reactivation instructions were received.
30. A non-transitory, electronically-readable storage medium according to claim 29, wherein said method further includes the steps of:
receiving a second TAR from a second merchant, said second TAR indicative of a transaction between said user and said second merchant;
determining whether said account was reactivated at a time associated with said second TAR; and
approving said second TAR only if said account was reactivated at said time associated with said second TAR.
31. A non-transitory, electronically-readable storage medium according to claim 30, wherein:
said step of determining whether said account was reactivated includes comparing a purchase date and time included in said second TAR with said date and time that said reactivation instructions were received; and
said step of approving said second TAR includes approving said second TAR only if said purchase date and time of said second TAR is after said date and time that said reactivation instructions were received.
32. A non-transitory, electronically-readable storage medium according to claim 27, wherein said method further includes the steps of:
storing at least one automatic deactivation criteria associated with said account-holder; and
automatically deactivating said account when said at least one deactivation criteria is met.
33. A non-transitory, electronically-readable storage medium according to claim 32, wherein:
said at least one deactivation criteria includes receiving a predetermined number of TARs; and
said step of automatically temporarily deactivating said account includes deactivating said account after the receipt of said predetermined number of TARs.
34. A non-transitory, electronically-readable storage medium according to claim 27, wherein said method further includes the steps of:
establishing a separate connection with said account-holder;
verifying said TAR with said account-holder via said separate connection; and
approving said TAR only if said TAR is verified.
35. A non-transitory, electronically-readable storage medium according to claim 27, wherein said method further includes the steps of:
receiving at least one pre-verification criteria associated with said account-holder;
comparing said TAR with said at least one pre-verification criteria;
automatically verifying said TAR without input from said account-holder if said at least one pre-verification criteria is satisfied; and
approving said TAR only if said TAR is verified.
36. A non-transitory, electronically-readable storage medium according to claim 27, wherein each time said account is activated, said account remains activated indefinitely until said account is deactivated by said account-holder.
37. A non-transitory, electronically-readable storage medium according to claim 36, wherein each time said account is activated, the duration that said account is activated is determined at the time said account is deactivated by said account-holder.
38. A non-transitory, electronically-readable storage medium according to claim 27, wherein said user is said account-holder.
39. A computer system for approving a commercial transaction between a user with account information and a merchant, said computer system comprising:
a processing unit for processing data and code; and
memory for storing said data and said code, said data and said code together including
means for facilitating a connection with said merchant and for receiving a transaction approval request (TAR),
activation data accessible to an account-holder and indicative of the activation status of an account associated with said account-holder,
means for communicating with said account-holder and for receiving instructions from said account-holder to modify said activation data;
means for modifying said activation data responsive to said instructions received from said account-holder, and
means, responsive to said TAR, for denying said TAR if said is deactivated; and wherein
prior to said user initiating said transaction with said merchant, said means for communicating is operative to establish a first connection with said account-holder and receive activation instructions from said account-holder to activate said account;
responsive to said activation instructions, said means for modifying is operative to modify said activation data to activate said account thereby facilitating approval of said TAR, said account being previously deactivated;
subsequent to receipt of said TAR, said means for communicating is operative to establish a second connection with said account-holder and receive deactivation instructions from said account-holder to deactivate said account;
responsive to said deactivation instructions, said means for modifying is operative to modify said activation data to deactivate said account such that subsequent TARs will be denied; and
in the absence of said deactivation instructions, said account remains activated such that said subsequent TARs may be approved.
US12/803,219 2004-07-12 2010-06-22 System and method for securing a credit account Expired - Fee Related US8074879B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/803,219 US8074879B2 (en) 2004-07-12 2010-06-22 System and method for securing a credit account
US13/300,142 US20120118983A1 (en) 2004-07-12 2011-11-18 Commercial Transactions Card With Security Markings

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US10/889,227 US7264154B2 (en) 2004-07-12 2004-07-12 System and method for securing a credit account
US11/895,837 US7753265B2 (en) 2004-07-12 2007-08-28 System and method for securing a credit account
US12/803,219 US8074879B2 (en) 2004-07-12 2010-06-22 System and method for securing a credit account

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/895,837 Continuation US7753265B2 (en) 2004-07-12 2007-08-28 System and method for securing a credit account

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/300,142 Division US20120118983A1 (en) 2004-07-12 2011-11-18 Commercial Transactions Card With Security Markings

Publications (2)

Publication Number Publication Date
US20100268647A1 US20100268647A1 (en) 2010-10-21
US8074879B2 true US8074879B2 (en) 2011-12-13

Family

ID=35540268

Family Applications (4)

Application Number Title Priority Date Filing Date
US10/889,227 Active 2025-07-19 US7264154B2 (en) 2004-07-12 2004-07-12 System and method for securing a credit account
US11/895,837 Active US7753265B2 (en) 2004-07-12 2007-08-28 System and method for securing a credit account
US12/803,219 Expired - Fee Related US8074879B2 (en) 2004-07-12 2010-06-22 System and method for securing a credit account
US13/300,142 Abandoned US20120118983A1 (en) 2004-07-12 2011-11-18 Commercial Transactions Card With Security Markings

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US10/889,227 Active 2025-07-19 US7264154B2 (en) 2004-07-12 2004-07-12 System and method for securing a credit account
US11/895,837 Active US7753265B2 (en) 2004-07-12 2007-08-28 System and method for securing a credit account

Family Applications After (1)

Application Number Title Priority Date Filing Date
US13/300,142 Abandoned US20120118983A1 (en) 2004-07-12 2011-11-18 Commercial Transactions Card With Security Markings

Country Status (12)

Country Link
US (4) US7264154B2 (en)
EP (1) EP1800210A4 (en)
JP (1) JP2008506206A (en)
KR (1) KR20070032806A (en)
CN (2) CN101027685A (en)
AU (1) AU2005271884B8 (en)
BR (1) BRPI0513273A (en)
CA (1) CA2573287A1 (en)
IL (1) IL180640A0 (en)
MX (1) MX2007000484A (en)
NZ (1) NZ552703A (en)
WO (1) WO2006017165A2 (en)

Cited By (127)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110099108A1 (en) * 2000-03-01 2011-04-28 Passgate Corporation Method, system and computer readable medium for web site account and e-commerce management from a central location
US20110106702A1 (en) * 2000-03-01 2011-05-05 Passgate Corporation Method, system and computer readable medium for web site account and e-commerce management from a central location
US20120082311A1 (en) * 2000-11-02 2012-04-05 Oleg Rashkovskiy Content protection using block reordering
US8827154B2 (en) 2009-05-15 2014-09-09 Visa International Service Association Verification of portable consumer devices
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US9256871B2 (en) 2012-07-26 2016-02-09 Visa U.S.A. Inc. Configurable payment tokens
US9280765B2 (en) 2011-04-11 2016-03-08 Visa International Service Association Multiple tokenization for authentication
US9317672B2 (en) 2011-12-14 2016-04-19 Visa International Service Association Online account access control by mobile device
US9317848B2 (en) 2009-05-15 2016-04-19 Visa International Service Association Integration of verification tokens with mobile communication devices
US9372971B2 (en) 2009-05-15 2016-06-21 Visa International Service Association Integration of verification tokens with portable computing devices
US9424413B2 (en) 2010-02-24 2016-08-23 Visa International Service Association Integration of payment capability into secure elements of computers
US9516487B2 (en) 2013-11-19 2016-12-06 Visa International Service Association Automated account provisioning
US9524501B2 (en) 2012-06-06 2016-12-20 Visa International Service Association Method and system for correlating diverse transaction data
US9530131B2 (en) 2008-07-29 2016-12-27 Visa U.S.A. Inc. Transaction processing using a global unique identifier
US9547769B2 (en) 2012-07-03 2017-01-17 Visa International Service Association Data protection hub
US9552573B2 (en) 2011-04-11 2017-01-24 Visa International Service Association Interoperable financial transactions via mobile devices
US9582801B2 (en) 2009-05-15 2017-02-28 Visa International Service Association Secure communication of payment information to merchants using a verification token
US9665722B2 (en) 2012-08-10 2017-05-30 Visa International Service Association Privacy firewall
US9680942B2 (en) 2014-05-01 2017-06-13 Visa International Service Association Data verification using access device
US9704155B2 (en) 2011-07-29 2017-07-11 Visa International Service Association Passing payment tokens through an hop/sop
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US9741051B2 (en) 2013-01-02 2017-08-22 Visa International Service Association Tokenization and third-party interaction
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US9780953B2 (en) 2014-07-23 2017-10-03 Visa International Service Association Systems and methods for secure detokenization
US9792611B2 (en) 2009-05-15 2017-10-17 Visa International Service Association Secure authentication system and method
US9830595B2 (en) 2012-01-26 2017-11-28 Visa International Service Association System and method of providing tokenization as a service
US9848052B2 (en) 2014-05-05 2017-12-19 Visa International Service Association System and method for token domain control
US9846878B2 (en) 2014-01-14 2017-12-19 Visa International Service Association Payment account identifier system
US9846861B2 (en) 2012-07-25 2017-12-19 Visa International Service Association Upstream and downstream data conversion
US9898740B2 (en) 2008-11-06 2018-02-20 Visa International Service Association Online challenge-response
US9911118B2 (en) 2012-11-21 2018-03-06 Visa International Service Association Device pairing via trusted intermediary
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
US9942043B2 (en) 2014-04-23 2018-04-10 Visa International Service Association Token security on a communication device
US9959531B2 (en) 2011-08-18 2018-05-01 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US9972005B2 (en) 2013-12-19 2018-05-15 Visa International Service Association Cloud-based transactions methods and systems
US9978094B2 (en) 2013-10-11 2018-05-22 Visa International Service Association Tokenization revocation list
US9978062B2 (en) 2013-05-15 2018-05-22 Visa International Service Association Mobile tokenization hub
US9996835B2 (en) 2013-07-24 2018-06-12 Visa International Service Association Systems and methods for communicating token attributes associated with a token vault
US9998978B2 (en) 2015-04-16 2018-06-12 Visa International Service Association Systems and methods for processing dormant virtual access devices
US10015147B2 (en) 2014-10-22 2018-07-03 Visa International Service Association Token enrollment system and method
US10026087B2 (en) 2014-04-08 2018-07-17 Visa International Service Association Data passed in an interaction
US10043178B2 (en) 2007-06-25 2018-08-07 Visa International Service Association Secure mobile payment system
US10078832B2 (en) 2011-08-24 2018-09-18 Visa International Service Association Method for using barcodes and mobile devices to conduct payment transactions
US10096009B2 (en) 2015-01-20 2018-10-09 Visa International Service Association Secure payment processing using authorization request
US10121129B2 (en) 2011-07-05 2018-11-06 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US10140615B2 (en) 2014-09-22 2018-11-27 Visa International Service Association Secure mobile device credential provisioning using risk decision non-overrides
US10147089B2 (en) 2012-01-05 2018-12-04 Visa International Service Association Data protection with translation
US10154084B2 (en) 2011-07-05 2018-12-11 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US10164996B2 (en) 2015-03-12 2018-12-25 Visa International Service Association Methods and systems for providing a low value token buffer
US10176478B2 (en) 2012-10-23 2019-01-08 Visa International Service Association Transaction initiation determination system utilizing transaction data elements
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
US10192216B2 (en) 2012-09-11 2019-01-29 Visa International Service Association Cloud-based virtual wallet NFC apparatuses, methods and systems
US10223691B2 (en) 2011-02-22 2019-03-05 Visa International Service Association Universal electronic payment apparatuses, methods and systems
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
US10223710B2 (en) 2013-01-04 2019-03-05 Visa International Service Association Wearable intelligent vision device apparatuses, methods and systems
US10243958B2 (en) 2016-01-07 2019-03-26 Visa International Service Association Systems and methods for device push provisoning
US10242358B2 (en) 2011-08-18 2019-03-26 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US10255601B2 (en) 2010-02-25 2019-04-09 Visa International Service Association Multifactor authentication using a directory server
US10255591B2 (en) 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
US10257185B2 (en) 2014-12-12 2019-04-09 Visa International Service Association Automated access data provisioning
US10255456B2 (en) 2014-09-26 2019-04-09 Visa International Service Association Remote server encrypted data provisioning system and methods
US10262308B2 (en) 2007-06-25 2019-04-16 Visa U.S.A. Inc. Cardless challenge systems and methods
US10262001B2 (en) 2012-02-02 2019-04-16 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia merchant analytics database platform apparatuses, methods and systems
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US10289999B2 (en) 2005-09-06 2019-05-14 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
US10304047B2 (en) 2012-12-07 2019-05-28 Visa International Service Association Token generating component
US10313321B2 (en) 2016-04-07 2019-06-04 Visa International Service Association Tokenization of co-network accounts
US10325261B2 (en) 2014-11-25 2019-06-18 Visa International Service Association Systems communications with non-sensitive identifiers
US10333921B2 (en) 2015-04-10 2019-06-25 Visa International Service Association Browser integration with Cryptogram
US10361856B2 (en) 2016-06-24 2019-07-23 Visa International Service Association Unique token authentication cryptogram
US10366387B2 (en) 2013-10-29 2019-07-30 Visa International Service Association Digital wallet system and method
US10373133B2 (en) 2010-03-03 2019-08-06 Visa International Service Association Portable account number for consumer payment account
US10433128B2 (en) 2014-01-07 2019-10-01 Visa International Service Association Methods and systems for provisioning multiple devices
US10484345B2 (en) 2014-07-31 2019-11-19 Visa International Service Association System and method for identity verification across mobile applications
US10489779B2 (en) 2013-10-21 2019-11-26 Visa International Service Association Multi-network token bin routing with defined verification parameters
US10491389B2 (en) 2017-07-14 2019-11-26 Visa International Service Association Token provisioning utilizing a secure authentication system
US10496986B2 (en) 2013-08-08 2019-12-03 Visa International Service Association Multi-network tokenization processing
US10496990B2 (en) 2012-02-22 2019-12-03 Visa International Service Association Data security system using mobile communications device
US10509779B2 (en) 2016-09-14 2019-12-17 Visa International Service Association Self-cleaning token vault
US10510073B2 (en) 2013-08-08 2019-12-17 Visa International Service Association Methods and systems for provisioning mobile devices with payment credentials
US10515358B2 (en) 2013-10-18 2019-12-24 Visa International Service Association Contextual transaction token methods and systems
US10552834B2 (en) 2015-04-30 2020-02-04 Visa International Service Association Tokenization capable authentication framework
US10586229B2 (en) 2010-01-12 2020-03-10 Visa International Service Association Anytime validation tokens
US10586227B2 (en) 2011-02-16 2020-03-10 Visa International Service Association Snap mobile payment apparatuses, methods and systems
US10643191B2 (en) 2012-01-27 2020-05-05 Visa International Service Association Mobile services remote deposit capture
US10664843B2 (en) 2015-12-04 2020-05-26 Visa International Service Association Unique code for token verification
US10726413B2 (en) 2010-08-12 2020-07-28 Visa International Service Association Securing external systems with account token substitution
US10733604B2 (en) 2007-09-13 2020-08-04 Visa U.S.A. Inc. Account permanence
US10740731B2 (en) 2013-01-02 2020-08-11 Visa International Service Association Third party settlement
US10769628B2 (en) 2014-10-24 2020-09-08 Visa Europe Limited Transaction messaging
US10825001B2 (en) 2011-08-18 2020-11-03 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US10846683B2 (en) 2009-05-15 2020-11-24 Visa International Service Association Integration of verification tokens with mobile communication devices
US10846694B2 (en) 2014-05-21 2020-11-24 Visa International Service Association Offline authentication
US10878422B2 (en) 2013-06-17 2020-12-29 Visa International Service Association System and method using merchant token
US10891610B2 (en) 2013-10-11 2021-01-12 Visa International Service Association Network token system
US10902418B2 (en) 2017-05-02 2021-01-26 Visa International Service Association System and method using interaction token
US10902421B2 (en) 2013-07-26 2021-01-26 Visa International Service Association Provisioning payment credentials to a consumer
US10915899B2 (en) 2017-03-17 2021-02-09 Visa International Service Association Replacing token on a multi-token user device
US10937031B2 (en) 2012-05-04 2021-03-02 Visa International Service Association System and method for local data conversion
US10977657B2 (en) 2015-02-09 2021-04-13 Visa International Service Association Token processing utilizing multiple authorizations
US10990967B2 (en) 2016-07-19 2021-04-27 Visa International Service Association Method of distributing tokens and managing token relationships
US11004043B2 (en) 2009-05-20 2021-05-11 Visa International Service Association Device including encrypted data for expiration date and verification value creation
US11023890B2 (en) 2014-06-05 2021-06-01 Visa International Service Association Identification and verification for provisioning mobile application
US11037138B2 (en) 2011-08-18 2021-06-15 Visa International Service Association Third-party value added wallet features and interfaces apparatuses, methods, and systems
US11055710B2 (en) 2013-05-02 2021-07-06 Visa International Service Association Systems and methods for verifying and processing transactions using virtual currency
US11068889B2 (en) 2015-10-15 2021-07-20 Visa International Service Association Instant token issuance
US11068578B2 (en) 2016-06-03 2021-07-20 Visa International Service Association Subtoken management system for connected devices
US11068899B2 (en) 2016-06-17 2021-07-20 Visa International Service Association Token aggregation for multi-party transactions
US11080696B2 (en) 2016-02-01 2021-08-03 Visa International Service Association Systems and methods for code display and use
US11176554B2 (en) 2015-02-03 2021-11-16 Visa International Service Association Validation identity tokens for transactions
US11238140B2 (en) 2016-07-11 2022-02-01 Visa International Service Association Encryption key exchange process using access device
US11250391B2 (en) 2015-01-30 2022-02-15 Visa International Service Association Token check offline
US11250424B2 (en) 2016-05-19 2022-02-15 Visa International Service Association Systems and methods for creating subtokens using primary tokens
US11257074B2 (en) 2014-09-29 2022-02-22 Visa International Service Association Transaction risk based token
US11256789B2 (en) 2018-06-18 2022-02-22 Visa International Service Association Recurring token transactions
US11288661B2 (en) 2011-02-16 2022-03-29 Visa International Service Association Snap mobile payment apparatuses, methods and systems
US11323443B2 (en) 2016-11-28 2022-05-03 Visa International Service Association Access identifier provisioning to application
US11356257B2 (en) 2018-03-07 2022-06-07 Visa International Service Association Secure remote token release with online authentication
US11386421B2 (en) 2016-04-19 2022-07-12 Visa International Service Association Systems and methods for performing push transactions
US11469895B2 (en) 2018-11-14 2022-10-11 Visa International Service Association Cloud token provisioning of multiple tokens
US11494765B2 (en) 2017-05-11 2022-11-08 Visa International Service Association Secure remote transaction system using mobile devices
US11580519B2 (en) 2014-12-12 2023-02-14 Visa International Service Association Provisioning platform for machine-to-machine devices
US11620643B2 (en) 2014-11-26 2023-04-04 Visa International Service Association Tokenization request via access device
US11727392B2 (en) 2011-02-22 2023-08-15 Visa International Service Association Multi-purpose virtual card transaction apparatuses, methods and systems
US11777934B2 (en) 2018-08-22 2023-10-03 Visa International Service Association Method and system for token provisioning and processing
US11849042B2 (en) 2019-05-17 2023-12-19 Visa International Service Association Virtual access credential interaction system and method
US11900361B2 (en) 2016-02-09 2024-02-13 Visa International Service Association Resource provider account token provisioning and processing

Families Citing this family (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8380628B1 (en) 2000-07-17 2013-02-19 Harris Intellectual Property, Lp System and method for verifying commercial transactions
US7881992B1 (en) 2002-07-31 2011-02-01 The Pnc Financial Services Group, Inc. Methods and systems for processing and managing corporate action information
US7740168B2 (en) 2003-08-18 2010-06-22 Visa U.S.A. Inc. Method and system for generating a dynamic verification value
US7761374B2 (en) 2003-08-18 2010-07-20 Visa International Service Association Method and system for generating a dynamic verification value
US8694397B2 (en) 2004-06-18 2014-04-08 Sap Ag Consistent set of interfaces derived from a business object model
US7264154B2 (en) 2004-07-12 2007-09-04 Harris David N System and method for securing a credit account
FR2882880B1 (en) * 2005-03-04 2007-06-22 Barret Patrick METHOD OF SECURING A TRANSACTION WITH A PAYMENT CARD, AND AUTHORIZATION CENTER FOR CARRYING OUT SAID METHOD
US7555467B2 (en) * 2005-05-31 2009-06-30 Pitney Bowes Inc. System and method for reliable transfer of virtual stamps
US7664699B1 (en) * 2005-12-21 2010-02-16 Symantec Corporation Automatic generation of temporary credit card information
US20090292619A1 (en) * 2006-04-03 2009-11-26 Gershon Kagan Method for universal electronic payment processing
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US9065643B2 (en) 2006-04-05 2015-06-23 Visa U.S.A. Inc. System and method for account identifier obfuscation
WO2008005102A2 (en) 2006-05-13 2008-01-10 Sap Ag Consistent set of interfaces derived from a business object model
US8640247B2 (en) * 2006-05-31 2014-01-28 The Invention Science Fund I, Llc Receiving an indication of a security breach of a protected set of files
EP2118837A4 (en) 2007-01-09 2012-07-11 Visa Usa Inc Mobile phone payment process including threshold indicator
US20080187112A1 (en) * 2007-02-07 2008-08-07 Tribal Shout!, Inc. Method and system for delivering podcasts to communication devices
US20080189211A1 (en) * 2007-02-07 2008-08-07 Elias Obadia System and methods for processing credit transactions
US8473411B2 (en) * 2007-05-30 2013-06-25 Visa U.S.A. Inc. Bulk activation of portable consumer payment devices
US7930228B1 (en) 2007-06-29 2011-04-19 Hawkins Charles S Promoting compliance by financial institutions with due diligence requirements
WO2009026450A1 (en) * 2007-08-21 2009-02-26 Daniel Jonathan Baron Methods and systems for preauthorizing venue-based credit accounts
US8417593B2 (en) 2008-02-28 2013-04-09 Sap Ag System and computer-readable medium for managing consistent interfaces for business objects across heterogeneous systems
US8996867B2 (en) * 2008-02-28 2015-03-31 At&T Intellectual Property I, L.P. Method and device for end-user verification of an electronic transaction
EP2128809A1 (en) * 2008-05-30 2009-12-02 Luc Stals Server device for controlling a transaction, first entity and second entity
US20090326988A1 (en) 2008-06-26 2009-12-31 Robert Barth Managing consistent interfaces for business objects across heterogeneous systems
US8478692B2 (en) 2008-06-26 2013-07-02 Visa International Service Association Systems and methods for geographic location notifications of payment transactions
US9542687B2 (en) 2008-06-26 2017-01-10 Visa International Service Association Systems and methods for visual representation of offers
US8396455B2 (en) 2008-09-25 2013-03-12 Visa International Service Association Systems and methods for sorting alert and offer messages on a mobile device
US20100114768A1 (en) 2008-10-31 2010-05-06 Wachovia Corporation Payment vehicle with on and off function
US10867298B1 (en) 2008-10-31 2020-12-15 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US8725601B2 (en) * 2008-11-21 2014-05-13 Pscu Financial Services Method and apparatus for consumer driven protection for payment card transactions
US20100153297A1 (en) 2008-12-12 2010-06-17 Sap Ag Managing Consistent Interfaces for Credit Portfolio Business Objects Across Heterogeneous Systems
US8396751B2 (en) 2009-09-30 2013-03-12 Sap Ag Managing consistent interfaces for merchandising business objects across heterogeneous systems
AU2010249214C1 (en) * 2009-12-15 2014-08-21 Zonamovil, Inc. Methods, apparatus, and systems for supporting purchases of goods and services via prepaid telecommunication accounts
US8387869B2 (en) 2009-12-24 2013-03-05 International Business Machines Corporation Protecting electronic cards
US8868458B1 (en) * 2010-02-12 2014-10-21 Jpmorgan Chase Bank, N.A. Remote account control system and method
TW201135619A (en) * 2010-04-07 2011-10-16 Era Comm Co Ltd Electronic transaction method and system utilizing QR code
US8732083B2 (en) * 2010-06-15 2014-05-20 Sap Ag Managing consistent interfaces for number range, number range profile, payment card payment authorisation, and product template template business objects across heterogeneous systems
US9135585B2 (en) 2010-06-15 2015-09-15 Sap Se Managing consistent interfaces for property library, property list template, quantity conversion virtual object, and supplier property specification business objects across heterogeneous systems
US8630952B2 (en) * 2011-03-04 2014-01-14 Citibank, N.A. Methods and systems using contactless card
US8352370B1 (en) * 2011-03-28 2013-01-08 Jpmorgan Chase Bank, N.A. System and method for universal instant credit
US8775280B2 (en) 2011-07-28 2014-07-08 Sap Ag Managing consistent interfaces for financial business objects across heterogeneous systems
US8725654B2 (en) 2011-07-28 2014-05-13 Sap Ag Managing consistent interfaces for employee data replication business objects across heterogeneous systems
US8601490B2 (en) 2011-07-28 2013-12-03 Sap Ag Managing consistent interfaces for business rule business object across heterogeneous systems
US8762454B2 (en) 2012-02-16 2014-06-24 Sap Ag Consistent interface for flag and tag
US9232368B2 (en) 2012-02-16 2016-01-05 Sap Se Consistent interface for user feed administrator, user feed event link and user feed settings
US9237425B2 (en) 2012-02-16 2016-01-12 Sap Se Consistent interface for feed event, feed event document and feed event type
US8762453B2 (en) 2012-02-16 2014-06-24 Sap Ag Consistent interface for feed collaboration group and feed event subscription
US8756274B2 (en) 2012-02-16 2014-06-17 Sap Ag Consistent interface for sales territory message type set 1
US8984050B2 (en) 2012-02-16 2015-03-17 Sap Se Consistent interface for sales territory message type set 2
US9400998B2 (en) 2012-06-28 2016-07-26 Sap Se Consistent interface for message-based communication arrangement, organisational centre replication request, and payment schedule
US9246869B2 (en) 2012-06-28 2016-01-26 Sap Se Consistent interface for opportunity
US8949855B2 (en) 2012-06-28 2015-02-03 Sap Se Consistent interface for address snapshot and approval process definition
WO2014000200A1 (en) 2012-06-28 2014-01-03 Sap Ag Consistent interface for document output request
US9367826B2 (en) 2012-06-28 2016-06-14 Sap Se Consistent interface for entitlement product
US8756135B2 (en) 2012-06-28 2014-06-17 Sap Ag Consistent interface for product valuation data and product valuation level
US8615451B1 (en) 2012-06-28 2013-12-24 Sap Ag Consistent interface for goods and activity confirmation
GB2503909A (en) * 2012-07-11 2014-01-15 Peter Elsom Green Electronic account access security system based on trusted proxy and communication using an account identifier to control at least account status
US8639619B1 (en) 2012-07-13 2014-01-28 Scvngr, Inc. Secure payment method and system
US9076112B2 (en) 2012-08-22 2015-07-07 Sap Se Consistent interface for financial instrument impairment expected cash flow analytical result
US9043236B2 (en) 2012-08-22 2015-05-26 Sap Se Consistent interface for financial instrument impairment attribute values analytical result
US9547833B2 (en) 2012-08-22 2017-01-17 Sap Se Consistent interface for financial instrument impairment calculation
DE102012112967B4 (en) 2012-12-21 2016-06-16 Sqwin Sa online transaction system
US20140222635A1 (en) * 2013-02-04 2014-08-07 Parvinder Chopra System, Software, and Method for Reducing Fraud
US20140279554A1 (en) * 2013-03-12 2014-09-18 Seth Priebatsch Distributed authenticity verification for consumer payment transactions
US20140279332A1 (en) * 2013-03-14 2014-09-18 Capital One Financial Corporation Systems and methods for configuring and controlling financial account products
US9191357B2 (en) 2013-03-15 2015-11-17 Sap Se Consistent interface for email activity business object
US9191343B2 (en) 2013-03-15 2015-11-17 Sap Se Consistent interface for appointment activity business object
US8770478B2 (en) 2013-07-11 2014-07-08 Scvngr, Inc. Payment processing with automatic no-touch mode selection
US10380564B1 (en) 2013-12-05 2019-08-13 Square, Inc. Merchant performed banking-type transactions
CN106537345B (en) * 2014-06-13 2020-10-13 皮沃塔尔软件公司 Accurately tracking memory usage in a multi-process computing environment
US10121147B2 (en) 2014-06-20 2018-11-06 Ca, Inc. Methods of processing transactions and related systems and computer program products
US10891622B2 (en) * 2014-11-13 2021-01-12 Mastercard International Incorporated Providing online cardholder authentication services on-behalf-of issuers
GB2533333A (en) 2014-12-16 2016-06-22 Visa Europe Ltd Transaction authorisation
US11429975B1 (en) 2015-03-27 2022-08-30 Wells Fargo Bank, N.A. Token management system
US10210569B1 (en) 2015-06-23 2019-02-19 Square, Inc. Encouraging spending goals and discouraging impulse purchases
US11170364B1 (en) 2015-07-31 2021-11-09 Wells Fargo Bank, N.A. Connected payment card systems and methods
EP3335371A4 (en) * 2015-08-10 2019-02-06 Idsidy, Inc. A method and system for transaction authorization basd on a parallel autonomous channel multi-user and multi-factor authentication
US10992679B1 (en) 2016-07-01 2021-04-27 Wells Fargo Bank, N.A. Access control tower
US11886611B1 (en) 2016-07-01 2024-01-30 Wells Fargo Bank, N.A. Control tower for virtual rewards currency
US11615402B1 (en) 2016-07-01 2023-03-28 Wells Fargo Bank, N.A. Access control tower
US11386223B1 (en) 2016-07-01 2022-07-12 Wells Fargo Bank, N.A. Access control tower
US11023873B1 (en) 2017-03-31 2021-06-01 Square, Inc. Resources for peer-to-peer messaging
US11556936B1 (en) 2017-04-25 2023-01-17 Wells Fargo Bank, N.A. System and method for card control
US10453056B2 (en) * 2017-06-29 2019-10-22 Square, Inc. Secure account creation
US11062388B1 (en) 2017-07-06 2021-07-13 Wells Fargo Bank, N.A Data control tower
US11188887B1 (en) 2017-11-20 2021-11-30 Wells Fargo Bank, N.A. Systems and methods for payment information access management
CN107909469A (en) * 2017-11-21 2018-04-13 中国银行股份有限公司 The unlocking method and device of bank transaction coded lock
US10467601B1 (en) 2018-03-30 2019-11-05 Square, Inc. Itemized digital receipts
US10769618B2 (en) * 2018-07-10 2020-09-08 Capital One Services, Llc Systems and methods for temporarily activating a payment account for fraud prevention
US11887102B1 (en) 2019-07-31 2024-01-30 Block, Inc. Temporary virtual payment card
US10992606B1 (en) 2020-09-04 2021-04-27 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
US11546338B1 (en) 2021-01-05 2023-01-03 Wells Fargo Bank, N.A. Digital account controls portal and protocols for federated and non-federated systems and devices

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10105627A (en) 1996-09-30 1998-04-24 Hitachi Software Eng Co Ltd Method for protecting electronic currency transaction machine from being lost or stolen and electronic currency transaction machine
JP2000306161A (en) 1999-04-21 2000-11-02 Sony Corp Electronic money system, electronic money terminal device, and information card
US20010047330A1 (en) * 1998-12-02 2001-11-29 Gephart Brian R. Electronic payment system employing selectively activatable limited-use account number
US6422462B1 (en) * 1998-03-30 2002-07-23 Morris E. Cohen Apparatus and methods for improved credit cards and credit card transactions
US20020169720A1 (en) * 2001-05-12 2002-11-14 Wilson Phillip C. Method for cardholder to place use restrictions on credit card at will
US20040078325A1 (en) * 2002-10-21 2004-04-22 International Business Machines Corporation Managing activation/deactivation of transaction accounts enabling temporary use of those accounts
US20040133507A1 (en) * 2003-01-02 2004-07-08 Paul Barbour Method and system for conducting financial transactions using single use credit card numbers
US20040148259A1 (en) * 2001-03-26 2004-07-29 Reiners Wolfram Johannes Bernd Transaction authorisation system
US20060261152A1 (en) * 2004-01-20 2006-11-23 Kamfu Wong Banking computer account system with lock for secure payment via telephone
US7264154B2 (en) * 2004-07-12 2007-09-04 Harris David N System and method for securing a credit account
US7702578B2 (en) * 2000-03-01 2010-04-20 Passgate Corporation Method, system and computer readable medium for web site account and e-commerce management from a central location

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3287839A (en) * 1965-03-24 1966-11-29 Rotwein Identification card provided with combination locking means
CA2100134C (en) * 1992-09-29 1999-06-22 Raymond Otto Colbert Secure credit/debit card authorization
US5530438A (en) 1995-01-09 1996-06-25 Motorola, Inc. Method of providing an alert of a financial transaction
US5826245A (en) * 1995-03-20 1998-10-20 Sandberg-Diment; Erik Providing verification information for a transaction
US5715399A (en) * 1995-03-30 1998-02-03 Amazon.Com, Inc. Secure method and system for communicating a list of credit card numbers over a non-secure network
US5708422A (en) * 1995-05-31 1998-01-13 At&T Transaction authorization and alert system
US5671279A (en) * 1995-11-13 1997-09-23 Netscape Communications Corporation Electronic commerce using a secure courier system
US5822737A (en) * 1996-02-05 1998-10-13 Ogram; Mark E. Financial transaction system
US5903830A (en) 1996-08-08 1999-05-11 Joao; Raymond Anthony Transaction security apparatus and method
US6088683A (en) * 1996-08-21 2000-07-11 Jalili; Reza Secure purchase transaction method using telephone number
US6012144A (en) * 1996-10-08 2000-01-04 Pickett; Thomas E. Transaction security method and apparatus
US5953710A (en) * 1996-10-09 1999-09-14 Fleming; Stephen S. Children's credit or debit card system
US5903721A (en) * 1997-03-13 1999-05-11 cha|Technologies Services, Inc. Method and system for secure online transaction processing
US6282522B1 (en) * 1997-04-30 2001-08-28 Visa International Service Association Internet payment system using smart card
US6000832A (en) * 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
US6055505A (en) * 1997-12-30 2000-04-25 U S West, Inc. Automatic customer notification system and method
US6233565B1 (en) 1998-02-13 2001-05-15 Saranac Software, Inc. Methods and apparatus for internet based financial transactions with evidence of payment
JP3587973B2 (en) * 1998-03-04 2004-11-10 沖電気工業株式会社 IC card and transaction processing method thereof
US6064990A (en) * 1998-03-31 2000-05-16 International Business Machines Corporation System for electronic notification of account activity
EP1006469A1 (en) 1998-12-02 2000-06-07 Koninklijke KPN N.V. System for secure transactions
EP1153375B1 (en) 1999-02-18 2003-01-15 Orbis Patents Limited Credit card system and method
KR20000024216A (en) 2000-01-29 2000-05-06 유세형 Payment Agency System of Transacting a Sale over a Network of Computers, and the Method
JP2001283118A (en) * 2000-03-30 2001-10-12 Internatl Business Mach Corp <Ibm> On-line settling system and settling method in on-line shopping and server and seller's terminal
KR100344114B1 (en) 2000-04-19 2002-07-24 주식회사 모빌리언스 Method for approving electronic commerce using the short message service and system therefor
JP2001351050A (en) * 2000-06-05 2001-12-21 Shigeru Nakatsuru Card loss/robbery notification processing system for quickly notifying loss/robbery of card such as cash card, credit card and debit card, recording medium with recorded notification processing program and notification processing method
AU2001273490A1 (en) * 2000-07-17 2002-02-05 David N. Harris System and method for verifying commercial transactions
US8380628B1 (en) 2000-07-17 2013-02-19 Harris Intellectual Property, Lp System and method for verifying commercial transactions
JP2002298045A (en) * 2001-03-30 2002-10-11 Fujitsu Ltd Credit card control method
JP2002324219A (en) * 2001-04-24 2002-11-08 Seiko Instruments Inc Card authentication system
JP2005502951A (en) * 2001-09-06 2005-01-27 マスターカード インターナシヨナル インコーポレーテツド Control method and control device via personal data by consumer

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10105627A (en) 1996-09-30 1998-04-24 Hitachi Software Eng Co Ltd Method for protecting electronic currency transaction machine from being lost or stolen and electronic currency transaction machine
US6422462B1 (en) * 1998-03-30 2002-07-23 Morris E. Cohen Apparatus and methods for improved credit cards and credit card transactions
US20010047330A1 (en) * 1998-12-02 2001-11-29 Gephart Brian R. Electronic payment system employing selectively activatable limited-use account number
US6339766B1 (en) * 1998-12-02 2002-01-15 Transactionsecure Electronic payment system employing limited-use account number
JP2000306161A (en) 1999-04-21 2000-11-02 Sony Corp Electronic money system, electronic money terminal device, and information card
US7702578B2 (en) * 2000-03-01 2010-04-20 Passgate Corporation Method, system and computer readable medium for web site account and e-commerce management from a central location
US20040148259A1 (en) * 2001-03-26 2004-07-29 Reiners Wolfram Johannes Bernd Transaction authorisation system
US20020169720A1 (en) * 2001-05-12 2002-11-14 Wilson Phillip C. Method for cardholder to place use restrictions on credit card at will
US20040078325A1 (en) * 2002-10-21 2004-04-22 International Business Machines Corporation Managing activation/deactivation of transaction accounts enabling temporary use of those accounts
US20040133507A1 (en) * 2003-01-02 2004-07-08 Paul Barbour Method and system for conducting financial transactions using single use credit card numbers
US20060261152A1 (en) * 2004-01-20 2006-11-23 Kamfu Wong Banking computer account system with lock for secure payment via telephone
US7264154B2 (en) * 2004-07-12 2007-09-04 Harris David N System and method for securing a credit account
US7753265B2 (en) * 2004-07-12 2010-07-13 Harris Intellectual Property, Lp System and method for securing a credit account

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JP Application No. 2007-521513, Office Action dated Jul. 6, 2011 (with English summary).

Cited By (240)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10102521B2 (en) 2000-03-01 2018-10-16 Gula Consulting Limited Liability Company Method, system and computer readable medium for web site account and e-commerce management from a central location
US20110106702A1 (en) * 2000-03-01 2011-05-05 Passgate Corporation Method, system and computer readable medium for web site account and e-commerce management from a central location
US20110099108A1 (en) * 2000-03-01 2011-04-28 Passgate Corporation Method, system and computer readable medium for web site account and e-commerce management from a central location
US20120082311A1 (en) * 2000-11-02 2012-04-05 Oleg Rashkovskiy Content protection using block reordering
US10922686B2 (en) 2005-09-06 2021-02-16 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
US10289999B2 (en) 2005-09-06 2019-05-14 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
US11605074B2 (en) 2005-09-06 2023-03-14 Visa U.S.A. Inc. System and method for secured account numbers in proximily devices
US10726416B2 (en) 2007-06-25 2020-07-28 Visa International Service Association Secure mobile payment system
US11481742B2 (en) 2007-06-25 2022-10-25 Visa U.S.A. Inc. Cardless challenge systems and methods
US10043178B2 (en) 2007-06-25 2018-08-07 Visa International Service Association Secure mobile payment system
US10262308B2 (en) 2007-06-25 2019-04-16 Visa U.S.A. Inc. Cardless challenge systems and methods
US10733604B2 (en) 2007-09-13 2020-08-04 Visa U.S.A. Inc. Account permanence
US9530131B2 (en) 2008-07-29 2016-12-27 Visa U.S.A. Inc. Transaction processing using a global unique identifier
US9898740B2 (en) 2008-11-06 2018-02-20 Visa International Service Association Online challenge-response
US10572864B2 (en) 2009-04-28 2020-02-25 Visa International Service Association Verification of portable consumer devices
US10997573B2 (en) 2009-04-28 2021-05-04 Visa International Service Association Verification of portable consumer devices
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US9904919B2 (en) 2009-05-15 2018-02-27 Visa International Service Association Verification of portable consumer devices
US10846683B2 (en) 2009-05-15 2020-11-24 Visa International Service Association Integration of verification tokens with mobile communication devices
US9582801B2 (en) 2009-05-15 2017-02-28 Visa International Service Association Secure communication of payment information to merchants using a verification token
US9317848B2 (en) 2009-05-15 2016-04-19 Visa International Service Association Integration of verification tokens with mobile communication devices
US8827154B2 (en) 2009-05-15 2014-09-09 Visa International Service Association Verification of portable consumer devices
US10043186B2 (en) 2009-05-15 2018-08-07 Visa International Service Association Secure authentication system and method
US10009177B2 (en) 2009-05-15 2018-06-26 Visa International Service Association Integration of verification tokens with mobile communication devices
US11574312B2 (en) 2009-05-15 2023-02-07 Visa International Service Association Secure authentication system and method
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US9792611B2 (en) 2009-05-15 2017-10-17 Visa International Service Association Secure authentication system and method
US10387871B2 (en) 2009-05-15 2019-08-20 Visa International Service Association Integration of verification tokens with mobile communication devices
US10049360B2 (en) 2009-05-15 2018-08-14 Visa International Service Association Secure communication of payment information to merchants using a verification token
US9372971B2 (en) 2009-05-15 2016-06-21 Visa International Service Association Integration of verification tokens with portable computing devices
US11004043B2 (en) 2009-05-20 2021-05-11 Visa International Service Association Device including encrypted data for expiration date and verification value creation
US10255591B2 (en) 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
US10586229B2 (en) 2010-01-12 2020-03-10 Visa International Service Association Anytime validation tokens
US9589268B2 (en) 2010-02-24 2017-03-07 Visa International Service Association Integration of payment capability into secure elements of computers
US9424413B2 (en) 2010-02-24 2016-08-23 Visa International Service Association Integration of payment capability into secure elements of computers
US10657528B2 (en) 2010-02-24 2020-05-19 Visa International Service Association Integration of payment capability into secure elements of computers
US10255601B2 (en) 2010-02-25 2019-04-09 Visa International Service Association Multifactor authentication using a directory server
US11900343B2 (en) 2010-03-03 2024-02-13 Visa International Service Association Portable account number for consumer payment account
US10373133B2 (en) 2010-03-03 2019-08-06 Visa International Service Association Portable account number for consumer payment account
US11803846B2 (en) 2010-08-12 2023-10-31 Visa International Service Association Securing external systems with account token substitution
US11847645B2 (en) 2010-08-12 2023-12-19 Visa International Service Association Securing external systems with account token substitution
US10726413B2 (en) 2010-08-12 2020-07-28 Visa International Service Association Securing external systems with account token substitution
US10586227B2 (en) 2011-02-16 2020-03-10 Visa International Service Association Snap mobile payment apparatuses, methods and systems
US11288661B2 (en) 2011-02-16 2022-03-29 Visa International Service Association Snap mobile payment apparatuses, methods and systems
US11727392B2 (en) 2011-02-22 2023-08-15 Visa International Service Association Multi-purpose virtual card transaction apparatuses, methods and systems
US10223691B2 (en) 2011-02-22 2019-03-05 Visa International Service Association Universal electronic payment apparatuses, methods and systems
US11023886B2 (en) 2011-02-22 2021-06-01 Visa International Service Association Universal electronic payment apparatuses, methods and systems
US9280765B2 (en) 2011-04-11 2016-03-08 Visa International Service Association Multiple tokenization for authentication
US9552573B2 (en) 2011-04-11 2017-01-24 Visa International Service Association Interoperable financial transactions via mobile devices
US10504082B2 (en) 2011-04-11 2019-12-10 Visa International Service Association Interoperable financial transactions via mobile devices
US10552828B2 (en) 2011-04-11 2020-02-04 Visa International Service Association Multiple tokenization for authentication
US10902397B2 (en) 2011-04-11 2021-01-26 Visa International Service Association Interoperable financial transactions via mobile devices
US11900359B2 (en) 2011-07-05 2024-02-13 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US10419529B2 (en) 2011-07-05 2019-09-17 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US11010753B2 (en) 2011-07-05 2021-05-18 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US10803449B2 (en) 2011-07-05 2020-10-13 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US10121129B2 (en) 2011-07-05 2018-11-06 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US10154084B2 (en) 2011-07-05 2018-12-11 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US9704155B2 (en) 2011-07-29 2017-07-11 Visa International Service Association Passing payment tokens through an hop/sop
US10839374B2 (en) 2011-07-29 2020-11-17 Visa International Service Association Passing payment tokens through an HOP / SOP
US10242358B2 (en) 2011-08-18 2019-03-26 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US11037138B2 (en) 2011-08-18 2021-06-15 Visa International Service Association Third-party value added wallet features and interfaces apparatuses, methods, and systems
US11010756B2 (en) 2011-08-18 2021-05-18 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US11763294B2 (en) 2011-08-18 2023-09-19 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US10354240B2 (en) 2011-08-18 2019-07-16 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US10825001B2 (en) 2011-08-18 2020-11-03 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US9959531B2 (en) 2011-08-18 2018-05-01 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US11803825B2 (en) 2011-08-18 2023-10-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US11397931B2 (en) 2011-08-18 2022-07-26 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US10402815B2 (en) 2011-08-24 2019-09-03 Visa International Service Association Method for using barcodes and mobile devices to conduct payment transactions
US10078832B2 (en) 2011-08-24 2018-09-18 Visa International Service Association Method for using barcodes and mobile devices to conduct payment transactions
US11354723B2 (en) 2011-09-23 2022-06-07 Visa International Service Association Smart shopping cart with E-wallet store injection search
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
US10614199B2 (en) 2011-12-14 2020-04-07 Visa International Service Association Online account access control by mobile device
US9317672B2 (en) 2011-12-14 2016-04-19 Visa International Service Association Online account access control by mobile device
US10275582B2 (en) 2011-12-14 2019-04-30 Visa International Service Association Online account access control by mobile device
US10147089B2 (en) 2012-01-05 2018-12-04 Visa International Service Association Data protection with translation
US10685379B2 (en) 2012-01-05 2020-06-16 Visa International Service Association Wearable intelligent vision device apparatuses, methods and systems
US11276058B2 (en) 2012-01-05 2022-03-15 Visa International Service Association Data protection with translation
US10607217B2 (en) 2012-01-26 2020-03-31 Visa International Service Association System and method of providing tokenization as a service
US9830595B2 (en) 2012-01-26 2017-11-28 Visa International Service Association System and method of providing tokenization as a service
US10643191B2 (en) 2012-01-27 2020-05-05 Visa International Service Association Mobile services remote deposit capture
US10430381B2 (en) 2012-02-02 2019-10-01 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia centralized personal information database platform apparatuses, methods and systems
US10983960B2 (en) 2012-02-02 2021-04-20 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia centralized personal information database platform apparatuses, methods and systems
US10262001B2 (en) 2012-02-02 2019-04-16 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia merchant analytics database platform apparatuses, methods and systems
US11036681B2 (en) 2012-02-02 2021-06-15 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia analytical model sharing database platform apparatuses, methods and systems
US11074218B2 (en) 2012-02-02 2021-07-27 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia merchant analytics database platform apparatuses, methods and systems
US11443314B2 (en) 2012-02-22 2022-09-13 Visa International Service Association Data security system using mobile communications device
US10496990B2 (en) 2012-02-22 2019-12-03 Visa International Service Association Data security system using mobile communications device
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US10937031B2 (en) 2012-05-04 2021-03-02 Visa International Service Association System and method for local data conversion
US11037140B2 (en) 2012-06-06 2021-06-15 Visa International Service Association Method and system for correlating diverse transaction data
US9524501B2 (en) 2012-06-06 2016-12-20 Visa International Service Association Method and system for correlating diverse transaction data
US10296904B2 (en) 2012-06-06 2019-05-21 Visa International Service Association Method and system for correlating diverse transaction data
US9547769B2 (en) 2012-07-03 2017-01-17 Visa International Service Association Data protection hub
US9846861B2 (en) 2012-07-25 2017-12-19 Visa International Service Association Upstream and downstream data conversion
US9727858B2 (en) 2012-07-26 2017-08-08 Visa U.S.A. Inc. Configurable payment tokens
US9256871B2 (en) 2012-07-26 2016-02-09 Visa U.S.A. Inc. Configurable payment tokens
US9665722B2 (en) 2012-08-10 2017-05-30 Visa International Service Association Privacy firewall
US10586054B2 (en) 2012-08-10 2020-03-10 Visa International Service Association Privacy firewall
US10204227B2 (en) 2012-08-10 2019-02-12 Visa International Service Association Privacy firewall
US10853797B2 (en) 2012-09-11 2020-12-01 Visa International Service Association Cloud-based virtual wallet NFC apparatuses, methods and systems
US11715097B2 (en) 2012-09-11 2023-08-01 Visa International Service Association Cloud-based virtual wallet NFC apparatuses, methods and systems
US10192216B2 (en) 2012-09-11 2019-01-29 Visa International Service Association Cloud-based virtual wallet NFC apparatuses, methods and systems
US10614460B2 (en) 2012-10-23 2020-04-07 Visa International Service Association Transaction initiation determination system utilizing transaction data elements
US10176478B2 (en) 2012-10-23 2019-01-08 Visa International Service Association Transaction initiation determination system utilizing transaction data elements
US10692076B2 (en) 2012-11-21 2020-06-23 Visa International Service Association Device pairing via trusted intermediary
US9911118B2 (en) 2012-11-21 2018-03-06 Visa International Service Association Device pairing via trusted intermediary
US10304047B2 (en) 2012-12-07 2019-05-28 Visa International Service Association Token generating component
US9741051B2 (en) 2013-01-02 2017-08-22 Visa International Service Association Tokenization and third-party interaction
US10740731B2 (en) 2013-01-02 2020-08-11 Visa International Service Association Third party settlement
US10223710B2 (en) 2013-01-04 2019-03-05 Visa International Service Association Wearable intelligent vision device apparatuses, methods and systems
US11055710B2 (en) 2013-05-02 2021-07-06 Visa International Service Association Systems and methods for verifying and processing transactions using virtual currency
US11861607B2 (en) 2013-05-15 2024-01-02 Visa International Service Association Mobile tokenization hub using dynamic identity information
US9978062B2 (en) 2013-05-15 2018-05-22 Visa International Service Association Mobile tokenization hub
US11341491B2 (en) 2013-05-15 2022-05-24 Visa International Service Association Mobile tokenization hub using dynamic identity information
US11017402B2 (en) 2013-06-17 2021-05-25 Visa International Service Association System and method using authorization and direct credit messaging
US10878422B2 (en) 2013-06-17 2020-12-29 Visa International Service Association System and method using merchant token
US11915235B2 (en) 2013-07-24 2024-02-27 Visa International Service Association Systems and methods for communicating token attributes associated with a token vault
US9996835B2 (en) 2013-07-24 2018-06-12 Visa International Service Association Systems and methods for communicating token attributes associated with a token vault
US11093936B2 (en) 2013-07-24 2021-08-17 Visa International Service Association Systems and methods for communicating token attributes associated with a token vault
US10902421B2 (en) 2013-07-26 2021-01-26 Visa International Service Association Provisioning payment credentials to a consumer
US11676138B2 (en) 2013-08-08 2023-06-13 Visa International Service Association Multi-network tokenization processing
US11392939B2 (en) 2013-08-08 2022-07-19 Visa International Service Association Methods and systems for provisioning mobile devices with payment credentials
US10496986B2 (en) 2013-08-08 2019-12-03 Visa International Service Association Multi-network tokenization processing
US10510073B2 (en) 2013-08-08 2019-12-17 Visa International Service Association Methods and systems for provisioning mobile devices with payment credentials
US10891610B2 (en) 2013-10-11 2021-01-12 Visa International Service Association Network token system
US11710119B2 (en) 2013-10-11 2023-07-25 Visa International Service Association Network token system
US9978094B2 (en) 2013-10-11 2018-05-22 Visa International Service Association Tokenization revocation list
US10515358B2 (en) 2013-10-18 2019-12-24 Visa International Service Association Contextual transaction token methods and systems
US10489779B2 (en) 2013-10-21 2019-11-26 Visa International Service Association Multi-network token bin routing with defined verification parameters
US10366387B2 (en) 2013-10-29 2019-07-30 Visa International Service Association Digital wallet system and method
US9516487B2 (en) 2013-11-19 2016-12-06 Visa International Service Association Automated account provisioning
US10248952B2 (en) 2013-11-19 2019-04-02 Visa International Service Association Automated account provisioning
US11875344B2 (en) 2013-12-19 2024-01-16 Visa International Service Association Cloud-based transactions with magnetic secure transmission
US11017386B2 (en) 2013-12-19 2021-05-25 Visa International Service Association Cloud-based transactions with magnetic secure transmission
US10664824B2 (en) 2013-12-19 2020-05-26 Visa International Service Association Cloud-based transactions methods and systems
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
US10402814B2 (en) 2013-12-19 2019-09-03 Visa International Service Association Cloud-based transactions methods and systems
US11164176B2 (en) 2013-12-19 2021-11-02 Visa International Service Association Limited-use keys and cryptograms
US9972005B2 (en) 2013-12-19 2018-05-15 Visa International Service Association Cloud-based transactions methods and systems
US10909522B2 (en) 2013-12-19 2021-02-02 Visa International Service Association Cloud-based transactions methods and systems
US10433128B2 (en) 2014-01-07 2019-10-01 Visa International Service Association Methods and systems for provisioning multiple devices
US10269018B2 (en) 2014-01-14 2019-04-23 Visa International Service Association Payment account identifier system
US10062079B2 (en) 2014-01-14 2018-08-28 Visa International Service Association Payment account identifier system
US9846878B2 (en) 2014-01-14 2017-12-19 Visa International Service Association Payment account identifier system
US10026087B2 (en) 2014-04-08 2018-07-17 Visa International Service Association Data passed in an interaction
US11100507B2 (en) 2014-04-08 2021-08-24 Visa International Service Association Data passed in an interaction
US10904002B2 (en) 2014-04-23 2021-01-26 Visa International Service Association Token security on a communication device
US10404461B2 (en) 2014-04-23 2019-09-03 Visa International Service Association Token security on a communication device
US9942043B2 (en) 2014-04-23 2018-04-10 Visa International Service Association Token security on a communication device
US9680942B2 (en) 2014-05-01 2017-06-13 Visa International Service Association Data verification using access device
US11470164B2 (en) 2014-05-01 2022-10-11 Visa International Service Association Data verification using access device
US11122133B2 (en) 2014-05-05 2021-09-14 Visa International Service Association System and method for token domain control
US9848052B2 (en) 2014-05-05 2017-12-19 Visa International Service Association System and method for token domain control
US10846694B2 (en) 2014-05-21 2020-11-24 Visa International Service Association Offline authentication
US11842350B2 (en) 2014-05-21 2023-12-12 Visa International Service Association Offline authentication
US11568405B2 (en) 2014-06-05 2023-01-31 Visa International Service Association Identification and verification for provisioning mobile application
US11023890B2 (en) 2014-06-05 2021-06-01 Visa International Service Association Identification and verification for provisioning mobile application
US10652028B2 (en) 2014-07-23 2020-05-12 Visa International Service Association Systems and methods for secure detokenization
US10038563B2 (en) 2014-07-23 2018-07-31 Visa International Service Association Systems and methods for secure detokenization
US9780953B2 (en) 2014-07-23 2017-10-03 Visa International Service Association Systems and methods for secure detokenization
US11770369B2 (en) 2014-07-31 2023-09-26 Visa International Service Association System and method for identity verification across mobile applications
US10484345B2 (en) 2014-07-31 2019-11-19 Visa International Service Association System and method for identity verification across mobile applications
US11252136B2 (en) 2014-07-31 2022-02-15 Visa International Service Association System and method for identity verification across mobile applications
US11036873B2 (en) 2014-08-22 2021-06-15 Visa International Service Association Embedding cloud-based functionalities in a communication device
US10049353B2 (en) 2014-08-22 2018-08-14 Visa International Service Association Embedding cloud-based functionalities in a communication device
US11783061B2 (en) 2014-08-22 2023-10-10 Visa International Service Association Embedding cloud-based functionalities in a communication device
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
US10477393B2 (en) 2014-08-22 2019-11-12 Visa International Service Association Embedding cloud-based functionalities in a communication device
US11574311B2 (en) 2014-09-22 2023-02-07 Visa International Service Association Secure mobile device credential provisioning using risk decision non-overrides
US10140615B2 (en) 2014-09-22 2018-11-27 Visa International Service Association Secure mobile device credential provisioning using risk decision non-overrides
US11087328B2 (en) 2014-09-22 2021-08-10 Visa International Service Association Secure mobile device credential provisioning using risk decision non-overrides
US10255456B2 (en) 2014-09-26 2019-04-09 Visa International Service Association Remote server encrypted data provisioning system and methods
US10643001B2 (en) 2014-09-26 2020-05-05 Visa International Service Association Remote server encrypted data provisioning system and methods
US11734679B2 (en) 2014-09-29 2023-08-22 Visa International Service Association Transaction risk based token
US11257074B2 (en) 2014-09-29 2022-02-22 Visa International Service Association Transaction risk based token
US10412060B2 (en) 2014-10-22 2019-09-10 Visa International Service Association Token enrollment system and method
US10015147B2 (en) 2014-10-22 2018-07-03 Visa International Service Association Token enrollment system and method
US10769628B2 (en) 2014-10-24 2020-09-08 Visa Europe Limited Transaction messaging
US10990977B2 (en) 2014-11-25 2021-04-27 Visa International Service Association System communications with non-sensitive identifiers
US10325261B2 (en) 2014-11-25 2019-06-18 Visa International Service Association Systems communications with non-sensitive identifiers
US11620643B2 (en) 2014-11-26 2023-04-04 Visa International Service Association Tokenization request via access device
US10257185B2 (en) 2014-12-12 2019-04-09 Visa International Service Association Automated access data provisioning
US11580519B2 (en) 2014-12-12 2023-02-14 Visa International Service Association Provisioning platform for machine-to-machine devices
US10785212B2 (en) 2014-12-12 2020-09-22 Visa International Service Association Automated access data provisioning
US10187363B2 (en) 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
US11240219B2 (en) 2014-12-31 2022-02-01 Visa International Service Association Hybrid integration of software development kit with secure execution environment
US10511583B2 (en) 2014-12-31 2019-12-17 Visa International Service Association Hybrid integration of software development kit with secure execution environment
US11010734B2 (en) 2015-01-20 2021-05-18 Visa International Service Association Secure payment processing using authorization request
US10096009B2 (en) 2015-01-20 2018-10-09 Visa International Service Association Secure payment processing using authorization request
US10496965B2 (en) 2015-01-20 2019-12-03 Visa International Service Association Secure payment processing using authorization request
US11250391B2 (en) 2015-01-30 2022-02-15 Visa International Service Association Token check offline
US11176554B2 (en) 2015-02-03 2021-11-16 Visa International Service Association Validation identity tokens for transactions
US11915243B2 (en) 2015-02-03 2024-02-27 Visa International Service Association Validation identity tokens for transactions
US10977657B2 (en) 2015-02-09 2021-04-13 Visa International Service Association Token processing utilizing multiple authorizations
US10164996B2 (en) 2015-03-12 2018-12-25 Visa International Service Association Methods and systems for providing a low value token buffer
US10333921B2 (en) 2015-04-10 2019-06-25 Visa International Service Association Browser integration with Cryptogram
US11271921B2 (en) 2015-04-10 2022-03-08 Visa International Service Association Browser integration with cryptogram
US9998978B2 (en) 2015-04-16 2018-06-12 Visa International Service Association Systems and methods for processing dormant virtual access devices
US10568016B2 (en) 2015-04-16 2020-02-18 Visa International Service Association Systems and methods for processing dormant virtual access devices
US10552834B2 (en) 2015-04-30 2020-02-04 Visa International Service Association Tokenization capable authentication framework
US11068889B2 (en) 2015-10-15 2021-07-20 Visa International Service Association Instant token issuance
US10664844B2 (en) 2015-12-04 2020-05-26 Visa International Service Association Unique code for token verification
US10664843B2 (en) 2015-12-04 2020-05-26 Visa International Service Association Unique code for token verification
US11127016B2 (en) 2015-12-04 2021-09-21 Visa International Service Association Unique code for token verification
US10243958B2 (en) 2016-01-07 2019-03-26 Visa International Service Association Systems and methods for device push provisoning
US10911456B2 (en) 2016-01-07 2021-02-02 Visa International Service Association Systems and methods for device push provisioning
US11720893B2 (en) 2016-02-01 2023-08-08 Visa International Service Association Systems and methods for code display and use
US11080696B2 (en) 2016-02-01 2021-08-03 Visa International Service Association Systems and methods for code display and use
US11900361B2 (en) 2016-02-09 2024-02-13 Visa International Service Association Resource provider account token provisioning and processing
US10313321B2 (en) 2016-04-07 2019-06-04 Visa International Service Association Tokenization of co-network accounts
US11386421B2 (en) 2016-04-19 2022-07-12 Visa International Service Association Systems and methods for performing push transactions
US11250424B2 (en) 2016-05-19 2022-02-15 Visa International Service Association Systems and methods for creating subtokens using primary tokens
US11068578B2 (en) 2016-06-03 2021-07-20 Visa International Service Association Subtoken management system for connected devices
US11783343B2 (en) 2016-06-17 2023-10-10 Visa International Service Association Token aggregation for multi-party transactions
US11068899B2 (en) 2016-06-17 2021-07-20 Visa International Service Association Token aggregation for multi-party transactions
US10361856B2 (en) 2016-06-24 2019-07-23 Visa International Service Association Unique token authentication cryptogram
US11329822B2 (en) 2016-06-24 2022-05-10 Visa International Service Association Unique token authentication verification value
US11238140B2 (en) 2016-07-11 2022-02-01 Visa International Service Association Encryption key exchange process using access device
US11714885B2 (en) 2016-07-11 2023-08-01 Visa International Service Association Encryption key exchange process using access device
US10990967B2 (en) 2016-07-19 2021-04-27 Visa International Service Association Method of distributing tokens and managing token relationships
US10509779B2 (en) 2016-09-14 2019-12-17 Visa International Service Association Self-cleaning token vault
US10942918B2 (en) 2016-09-14 2021-03-09 Visa International Service Association Self-cleaning token vault
US11799862B2 (en) 2016-11-28 2023-10-24 Visa International Service Association Access identifier provisioning to application
US11323443B2 (en) 2016-11-28 2022-05-03 Visa International Service Association Access identifier provisioning to application
US11900371B2 (en) 2017-03-17 2024-02-13 Visa International Service Association Replacing token on a multi-token user device
US10915899B2 (en) 2017-03-17 2021-02-09 Visa International Service Association Replacing token on a multi-token user device
US11449862B2 (en) 2017-05-02 2022-09-20 Visa International Service Association System and method using interaction token
US10902418B2 (en) 2017-05-02 2021-01-26 Visa International Service Association System and method using interaction token
US11494765B2 (en) 2017-05-11 2022-11-08 Visa International Service Association Secure remote transaction system using mobile devices
US11398910B2 (en) 2017-07-14 2022-07-26 Visa International Service Association Token provisioning utilizing a secure authentication system
US10491389B2 (en) 2017-07-14 2019-11-26 Visa International Service Association Token provisioning utilizing a secure authentication system
US11356257B2 (en) 2018-03-07 2022-06-07 Visa International Service Association Secure remote token release with online authentication
US11743042B2 (en) 2018-03-07 2023-08-29 Visa International Service Association Secure remote token release with online authentication
US11256789B2 (en) 2018-06-18 2022-02-22 Visa International Service Association Recurring token transactions
US11777934B2 (en) 2018-08-22 2023-10-03 Visa International Service Association Method and system for token provisioning and processing
US11870903B2 (en) 2018-11-14 2024-01-09 Visa International Service Association Cloud token provisioning of multiple tokens
US11469895B2 (en) 2018-11-14 2022-10-11 Visa International Service Association Cloud token provisioning of multiple tokens
US11849042B2 (en) 2019-05-17 2023-12-19 Visa International Service Association Virtual access credential interaction system and method

Also Published As

Publication number Publication date
CA2573287A1 (en) 2006-02-16
IL180640A0 (en) 2007-06-03
JP2008506206A (en) 2008-02-28
WO2006017165A3 (en) 2007-05-03
KR20070032806A (en) 2007-03-22
AU2005271884A8 (en) 2011-07-21
EP1800210A2 (en) 2007-06-27
MX2007000484A (en) 2007-06-11
AU2005271884B8 (en) 2011-07-21
US20120118983A1 (en) 2012-05-17
AU2005271884B2 (en) 2011-03-24
AU2005271884A1 (en) 2006-02-16
US7264154B2 (en) 2007-09-04
US20060006223A1 (en) 2006-01-12
CN101901452A (en) 2010-12-01
BRPI0513273A (en) 2008-05-06
EP1800210A4 (en) 2010-03-17
US20100268647A1 (en) 2010-10-21
US7753265B2 (en) 2010-07-13
WO2006017165A2 (en) 2006-02-16
CN101027685A (en) 2007-08-29
US20070295801A1 (en) 2007-12-27
NZ552703A (en) 2010-03-26

Similar Documents

Publication Publication Date Title
US8074879B2 (en) System and method for securing a credit account
US8352369B2 (en) System and method for pre-verifying commercial transactions
US7681228B2 (en) Method of one time authentication response to a session-specific challenge indicating a random subset of password or PIN character positions
US20040073688A1 (en) Electronic payment validation using Transaction Authorization Tokens
US20030061163A1 (en) Method and apparatus for verification/authorization by credit or debit card owner of use of card concurrently with merchant transaction
US20060173776A1 (en) A Method of Authentication
JP2004527861A (en) Method for conducting secure cashless payment transactions and cashless payment system
AU2008202099A1 (en) System and method for verifying commercial transactions
WO2002005077A2 (en) Method and system for using biometric sample to electronically access accounts and authorize transactions
CA2349306C (en) Method of and apparatus for executing automated transactions

Legal Events

Date Code Title Description
ZAAA Notice of allowance and fees due

Free format text: ORIGINAL CODE: NOA

ZAAB Notice of allowance mailed

Free format text: ORIGINAL CODE: MN/=.

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

FEPP Fee payment procedure

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

FEPP Fee payment procedure

Free format text: 7.5 YR SURCHARGE - LATE PMT W/IN 6 MO, SMALL ENTITY (ORIGINAL EVENT CODE: M2555); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2552); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

Year of fee payment: 8

FEPP Fee payment procedure

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

LAPS Lapse for failure to pay maintenance fees

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

STCH Information on status: patent discontinuation

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

FP Lapsed due to failure to pay maintenance fee

Effective date: 20231213