US20050137971A1 - Personally customizable credit card accounts - Google Patents

Personally customizable credit card accounts Download PDF

Info

Publication number
US20050137971A1
US20050137971A1 US11/063,143 US6314305A US2005137971A1 US 20050137971 A1 US20050137971 A1 US 20050137971A1 US 6314305 A US6314305 A US 6314305A US 2005137971 A1 US2005137971 A1 US 2005137971A1
Authority
US
United States
Prior art keywords
charge
vendor
account
specified
authorization request
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.)
Abandoned
Application number
US11/063,143
Inventor
Jerry Malcolm
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.)
PayPal Inc
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US11/063,143 priority Critical patent/US20050137971A1/en
Publication of US20050137971A1 publication Critical patent/US20050137971A1/en
Priority to US12/136,607 priority patent/US20080243691A1/en
Assigned to EBAY INC. reassignment EBAY INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: INTERNATIONAL BUSINESS MACHINES CORPORATION
Assigned to PAYPAL, INC. reassignment PAYPAL, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: EBAY INC.
Abandoned legal-status Critical Current

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/04Payment circuits
    • 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
    • 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
    • G06Q20/405Establishing or using transaction specific rules
    • 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
    • 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/03Credit; Loans; Processing thereof
    • 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/12Accounting

Definitions

  • the present invention generally relates to charge accounts and in particular to security of and control over charge account use. Still more particularly, the present invention relates to account holder control over charge authorizations using charge account numbers.
  • SSL secure socket layer
  • Another concern involves automatic renewal and rebilling by an enterprise upon expiration of a membership subscription.
  • reputable businesses offer procedures to cancel membership subscriptions, the risk of either a potential argument over cancellation or an error or delay in cancellation, while rebilling continues, is enough to prevent some consumers from even considering using their charge accounts on the Internet.
  • Single use charge account numbers employ numbers associated with an account which are only valid for a single charging activity. After the account number has been used once, charging authorization on that account number is denied for all subsequent charge requests. This approach, however, places a tremendous burden on the existing credit card numbering scheme since only a finite range of unique numbers exists. Single use account numbers would quickly run through the entire range of permutations. Much larger ranges of numbers than are currently employed would be required for this solution to be practical.
  • Account holders may specify vendor-specific charge restrictions for charging transactions against their accounts, where each vendor-specific charge restriction includes a unique identifier for the corresponding vendor to which the charge restriction is applicable.
  • the charge restriction may be an exclusion from approval of all charge authorization requests, an amount limit on charge authorization requests which may be approved, a “rebill” limit on the number of times subsequent charge authorization requests may be approved, or a combination of such restrictions and/or other restrictions.
  • the vendor identifier is extracted from the charge authorization request and employed to determine whether any charge restrictions are applicable to the requesting vendor.
  • the vendor-specific charge restrictions for a particular vendor may be specified by the account holder either before or after an initial charge transactions involving that vendor, with the vendor identifier either manually entered by the account holder or automatically extracted from an account transaction record.
  • FIG. 1 depicts a high-level block diagram of a credit card authorization system, in which a preferred embodiment of the present invention may be implemented;
  • FIG. 2 a block diagram of charge account information including vendor-specific charge restrictions specified by the charge account holder in accordance with a preferred embodiment of the present invention
  • FIG. 3 depicts a high level flow chart for a process of processing charge authorization requests utilizing vendor-specific charge restrictions specified by the charge account holder in accordance with a preferred embodiment of the present invention.
  • System 102 includes a number of requesting units 104 a - 104 n (where n is any integer) operating by vendor enterprises for the purposes of requesting charging transactions.
  • requesting units 104 a - 104 n (where n is any integer) operating by vendor enterprises for the purposes of requesting charging transactions.
  • charging transactions and “charge account” refer to any transaction or account relating to payment by transfer of credit or funds through a third party account provider utilizing an account number, including without limitation credit card transactions and accounts, debit card transactions and accounts, “check card” transactions and checking accounts, and the like.
  • Requesting units 104 a - 104 n are capable of generating charge authorization requests for transmission over the Internet 106 to a charge authorization server 108 or similar charge authorization clearing facility.
  • Charge authorization server 108 maintains a database 110 containing information regarding charge accounts which may be accessed utilizing the charge account number, including available credit or deposit balance for the account. Database 110 also includes vendor-specific charge restrictions specified by the account holder, described in further detail below.
  • a user unit 112 connected to charge authorization server 108 via Internet 106 , allows account holders to set or change vendor-specific charge restrictions for their account(s).
  • Charge authorization server 108 provides an interface allowing account holders to apply such vendor-specific charge restrictions to their account information within database 110 .
  • Charge authorization requests transmitted by any of requesting units 104 a - 104 n and received by charge authorization server 108 are processed by charge authorization server 108 utilizing the account information associated with the charge account number within the charge authorization request.
  • the charge authorization requests also contain vendor identification information, which includes a unique vendor identifier for the vendor requesting the charge authorization and may optionally include the vendor name.
  • Charge authorization server 108 employs the vendor identifier and/or name in processing charge authorization requests utilizing account information within database 110 . Other information, such as an identification of the account to be credited by the charge authorization, may also be contained within charge authorization requests in accordance with the known art.
  • the exemplary embodiment depicts transactions being performed over the Internet 106 , some or all of the transactions described above may occur between data processing systems having direct communications, such as requesting units which directly dial-up the charge authorization server over a telephone connection.
  • Database 110 contains a plurality of charge account records 202 a - 202 n for different charge accounts (which may include checking accounts), each identified by a unique charge account number.
  • Each charge account record 202 a - 202 n contains the charge account number 204 , together with a current available balance or credit amount 206 .
  • Each charge account record 202 a - 202 n also includes a listing of “allowed” vendors 208 , “excluded” vendors 210 , or both. Allowed and excluded vendors listings 208 and 210 are specified by the account holder and are employed in processing charge authorization requests. Charge authorization requests which would violate the restrictions specified by the account holder within allowed and excluded vendors listings 208 and 210 are declined; charge authorization requests which would not violate the restrictions specified by the account holder may be approved.
  • Allowed vendors listing 208 contains an entry for each vendor specified by the account holder, where each entry includes a unique (typically numeric or alphanumeric) identifier 212 for the vendor, and may also contain the vendor's name 214 . Each entry within allowed vendors listing 208 may also contain an amount limit 216 specified by the account holder, designating an amount limit for each charge which may be approved for that vendor. The amount limit 216 may be undefined to allow approval of any amount, or may be a finite dollar amount, and may also have a default value.
  • amount limit 216 could be simply a per-charge limit for the corresponding vendor, such a limitation would allow a number of smaller charges to be pushed through. Instead, amount limit 216 should preferably be a time-based limit (e.g., $100 per month). In this manner, no consideration is given to whether the charges by the vendor are a single charge for the full amount, or a number of smaller charges. Charges in excess of the specified amount limit 216 during the corresponding period will be declined.
  • Each entry within allowed vendors listing 208 may also have a “rebill” limit 218 , which specifies either an absolute number of subsequent charge authorizations which may be approved for the corresponding vendor or a number of billing periods during which charge authorization may be approved up to the amount limit 216 . After charge authorization requests for the specified number of billings or billing periods have been approved, subsequent charge authorization requests will be declined. In this manner, the number of rebillings by a particular vendor may be controlled by the account holder. Rebill limit 218 and amount (per billing period) limit 216 combine to provide control over both the amount and the duration of charges by a particular vendor (e.g., $100 per month for 12 months).
  • Excluded vendors listing 210 similarly contains an entry for each vendor specified by the account holder to be subject to special charge restrictions, with each entry containing a unique identifier 220 for the vendor and, optionally, the vendor's name 222 . Charge authorization requests from vendors identified within excluded vendors listing 210 will always be declined.
  • Allowed and excluded vendors listings 208 and 210 each include a flag, a decline-all-others flag 224 within allowed vendors listing 208 and an approve-all-others flag 226 within excluded vendors listing 210 .
  • Decline-all-others flag 224 when set, causes all charge authorization requests from any vendors not specifically identified within the approved vendors listing 208 to be declined.
  • Approve-all-others flag 226 when set, causes all charge authorization requests from any vendors not identified within the excluded vendors listing 210 to be approved, subject to amount and rebill limitations (if any) set in approved vendors listing 208 .
  • Decline-all-others flag 224 and approve-all-others flag 226 should be mutually exclusive, and should not both be set at the same time.
  • Vendors may be added to either allowed and excluded vendors listings 208 and 210 by an account holder either through manual entry of vendor information, or by selection of a transaction within account records and automatic extraction of vendor information (vendor identifier and name) from the account transaction records.
  • Vendor identifier and name A dictionary of vendor identifiers indexed by vendor name may be provided to the account holder for adding vendors to listings 208 and 210 .
  • vendor-specific charge restrictions including charge amount and rebilling limits, may be specified by the account holder either before or after an initial charge transaction.
  • the account holder employs user unit 112 to set or change vendors within the allowed and excluded vendors listings for their account information within database 110 .
  • Requesting units 104 a - 104 n generate and transmit charge authorization requests relating to the account holder's account, which are received by charge authorization server 108 and processed for approval utilizing the account information within database 110 . If a restriction set by the account holder within the allowed and excluded vendors listings would be violated by a received charge authorization request, the charge authorization request is declined in the response generated by charge authorization server 108 . If a received charge authorization request would not violate account holder restrictions, the charge authorization request may be approved, subject to other limitations such as available balance.
  • step 302 depicts receiving a charge authorization requests including a vendor identifier and a charge amount (together with a unique charge account number) at a charge authorization server.
  • step 304 illustrates extracting the charge amount, the vendor identifier, and the charge account number from the charge authorization request.
  • step 306 depicts a determination of whether the charge amount exceeds an available credit limit or account balance for the account identified by the account number within the charge authorization request. If not, the process proceeds to step 308 , which illustrates a determination of whether the vendor identifier from the charge authorization request matches a vendor identifier within an allowed vendors listing associated with the subject account. If so, the process proceeds to step 310 , which depicts a determination of whether an amount limit or a rebill limit specified by the account holder for the identified vendor would be exceeded by the requested charge to the account.
  • step 316 which illustrates declining the charge authorization request; if specified amount or rebill limits would not be exceeded (or if none are specified), the process proceeds instead to step 314 , which depicts approving the charge authorization request.
  • step 312 illustrates a determination of whether the vendor identifier matches a vendor identifier within any entry in an excluded vendors listing associated with the account. If so, the process proceeds to step 316 , which illustrates declining the charge authorization request; if not, the process proceeds instead to step 314 , which depicts approving the charge authorization request. From either of step 314 or 316 , the process then proceeds to step 318 , which depicts the process becoming idle until another charge authorization request is received.
  • the exemplary process of FIG. 3 is a simplistic example subject to myriad variations within the spirit and scope of the present invention.
  • the determination of whether vendor-specific charge restrictions (steps 308 and 310 ) have been specified by an account holder for the requesting vendor may be performed before the charge amount is compared to the available credit or account balance for the account.
  • additional steps may be performed to check the state of exclude-all-others and allow-all-others flags as described above before approving or declining a charge authorization request.
  • the present invention improves the security of employing charge accounts by permitting vendor-specific charge restrictions by the account holder.
  • the account holder can thus achieve “single use” charging with respect to a particular vendor by setting charge restrictions for that vendor, either before or after the charging transaction.
  • Amount limits may be specified by the account holder for budgeting purposes, and rebill limits may be specified by the account holder to avoid billing disputes.

Abstract

Account holders may specify vendor-specific charge restrictions for charging transactions against their accounts, where each vendor-specific charge restriction includes a unique identifier for the corresponding vendor to which the charge restriction is applicable. The charge restriction may be an exclusion from approval of all charge authorization requests, an amount limit on charge authorization requests which may be approved, a “rebill” limit on the number of times subsequent charge authorization requests may be approved, or a combination of such restrictions and/or other restrictions. When a charge authorization request is received for a charge against an account having vendor-specific charge restrictions set by the account holder, the vendor identifier is extracted from the charge authorization request and employed to determine whether any charge restrictions are applicable to the requesting vendor. The vendor-specific charge restrictions for a particular vendor may be specified by the account holder either before or after an initial charge transactions involving that vendor, with the vendor identifier either manually entered by the account holder or automatically extracted from an account transaction record.

Description

    BACKGROUND OF THE INVENTION
  • 1. Technical Field
  • The present invention generally relates to charge accounts and in particular to security of and control over charge account use. Still more particularly, the present invention relates to account holder control over charge authorizations using charge account numbers.
  • 2. Description of the Related Art
  • A major obstacle to broad public acceptance and use of e-business is reluctance of consumers to reveal their credit or debit card numbers over the Internet due to security concerns, both real and perceived. One fear is interception of the card number by a third party, although secure socket layer (SSL) encryption employed in secure Internet transactions renders such interception extremely improbable. However, the perception on the part of account holders remains.
  • Another concern, one having much more basis in reality, involves automatic renewal and rebilling by an enterprise upon expiration of a membership subscription. Although reputable businesses offer procedures to cancel membership subscriptions, the risk of either a potential argument over cancellation or an error or delay in cancellation, while rebilling continues, is enough to prevent some consumers from even considering using their charge accounts on the Internet.
  • Various methods have been employed or proposed for improving security and reducing the risk of unauthorized rebilling in charge account use. “Single use” charge account numbers, for example, employ numbers associated with an account which are only valid for a single charging activity. After the account number has been used once, charging authorization on that account number is denied for all subsequent charge requests. This approach, however, places a tremendous burden on the existing credit card numbering scheme since only a finite range of unique numbers exists. Single use account numbers would quickly run through the entire range of permutations. Much larger ranges of numbers than are currently employed would be required for this solution to be practical.
  • An alternative solution involves adding prefixes or suffixes to existing account numbers to create single use account numbers for that account. However, this requires a larger number of digits for account numbers than are currently employed (typically sixteen) to uniquely identify an account, which would cause much existing software depending on the current number of digits within account numbers to function improperly. Moreover, while single use account charging activity is desirable in some situations, modification of all charging activity to involve single use account numbers is not desirable for many types of transactions.
  • It would be desirable, therefore, to enable an account holder to establish single use charging functionality for an account in selected situations, while retaining the ability to generally employ unrestricted charging transactions in other situations. It would further be advantageous for the account holder to be able to establish such single use limitations either before or after the charging transaction.
  • SUMMARY OF THE INVENTION
  • It is therefore one object of the present invention to provide improved charge accounts.
  • It is another object of the present invention to provide improved security of and control over charge account use.
  • It is yet another object of the present invention to provide account holder control over charge authorizations using charge account numbers.
  • The foregoing objects are achieved as is now described. Account holders may specify vendor-specific charge restrictions for charging transactions against their accounts, where each vendor-specific charge restriction includes a unique identifier for the corresponding vendor to which the charge restriction is applicable. The charge restriction may be an exclusion from approval of all charge authorization requests, an amount limit on charge authorization requests which may be approved, a “rebill” limit on the number of times subsequent charge authorization requests may be approved, or a combination of such restrictions and/or other restrictions. When a charge authorization request is received for a charge against an account having vendor-specific charge restrictions set by the account holder, the vendor identifier is extracted from the charge authorization request and employed to determine whether any charge restrictions are applicable to the requesting vendor. The vendor-specific charge restrictions for a particular vendor may be specified by the account holder either before or after an initial charge transactions involving that vendor, with the vendor identifier either manually entered by the account holder or automatically extracted from an account transaction record.
  • The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
  • FIG. 1 depicts a high-level block diagram of a credit card authorization system, in which a preferred embodiment of the present invention may be implemented;
  • FIG. 2 a block diagram of charge account information including vendor-specific charge restrictions specified by the charge account holder in accordance with a preferred embodiment of the present invention; and
  • FIG. 3 depicts a high level flow chart for a process of processing charge authorization requests utilizing vendor-specific charge restrictions specified by the charge account holder in accordance with a preferred embodiment of the present invention.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
  • With reference now to the figures, and in particular with reference to FIG. 1, a high-level diagram of a charging transaction authorization system in accordance with a preferred embodiment of the present invention is depicted. System 102 includes a number of requesting units 104 a-104 n (where n is any integer) operating by vendor enterprises for the purposes of requesting charging transactions. As used herein, “charging transactions” and “charge account” refer to any transaction or account relating to payment by transfer of credit or funds through a third party account provider utilizing an account number, including without limitation credit card transactions and accounts, debit card transactions and accounts, “check card” transactions and checking accounts, and the like.
  • Requesting units 104 a-104 n are capable of generating charge authorization requests for transmission over the Internet 106 to a charge authorization server 108 or similar charge authorization clearing facility. Charge authorization server 108 maintains a database 110 containing information regarding charge accounts which may be accessed utilizing the charge account number, including available credit or deposit balance for the account. Database 110 also includes vendor-specific charge restrictions specified by the account holder, described in further detail below. A user unit 112, connected to charge authorization server 108 via Internet 106, allows account holders to set or change vendor-specific charge restrictions for their account(s). Charge authorization server 108 provides an interface allowing account holders to apply such vendor-specific charge restrictions to their account information within database 110.
  • Charge authorization requests transmitted by any of requesting units 104 a-104 n and received by charge authorization server 108 are processed by charge authorization server 108 utilizing the account information associated with the charge account number within the charge authorization request. The charge authorization requests also contain vendor identification information, which includes a unique vendor identifier for the vendor requesting the charge authorization and may optionally include the vendor name. Charge authorization server 108 employs the vendor identifier and/or name in processing charge authorization requests utilizing account information within database 110. Other information, such as an identification of the account to be credited by the charge authorization, may also be contained within charge authorization requests in accordance with the known art.
  • Although the exemplary embodiment depicts transactions being performed over the Internet 106, some or all of the transactions described above may occur between data processing systems having direct communications, such as requesting units which directly dial-up the charge authorization server over a telephone connection.
  • Referring to FIG. 2, which is intended to be read in conjunction with FIG. 1, a block diagram of charge account information including vendor-specific charge restrictions specified by the charge account holder in accordance with a preferred embodiment of the present invention is illustrated. Database 110 contains a plurality of charge account records 202 a-202 n for different charge accounts (which may include checking accounts), each identified by a unique charge account number. Each charge account record 202 a-202 n contains the charge account number 204, together with a current available balance or credit amount 206.
  • Each charge account record 202 a-202 n also includes a listing of “allowed” vendors 208, “excluded” vendors 210, or both. Allowed and excluded vendors listings 208 and 210 are specified by the account holder and are employed in processing charge authorization requests. Charge authorization requests which would violate the restrictions specified by the account holder within allowed and excluded vendors listings 208 and 210 are declined; charge authorization requests which would not violate the restrictions specified by the account holder may be approved.
  • Allowed vendors listing 208 contains an entry for each vendor specified by the account holder, where each entry includes a unique (typically numeric or alphanumeric) identifier 212 for the vendor, and may also contain the vendor's name 214. Each entry within allowed vendors listing 208 may also contain an amount limit 216 specified by the account holder, designating an amount limit for each charge which may be approved for that vendor. The amount limit 216 may be undefined to allow approval of any amount, or may be a finite dollar amount, and may also have a default value.
  • While the amount limit 216 could be simply a per-charge limit for the corresponding vendor, such a limitation would allow a number of smaller charges to be pushed through. Instead, amount limit 216 should preferably be a time-based limit (e.g., $100 per month). In this manner, no consideration is given to whether the charges by the vendor are a single charge for the full amount, or a number of smaller charges. Charges in excess of the specified amount limit 216 during the corresponding period will be declined.
  • Each entry within allowed vendors listing 208 may also have a “rebill” limit 218, which specifies either an absolute number of subsequent charge authorizations which may be approved for the corresponding vendor or a number of billing periods during which charge authorization may be approved up to the amount limit 216. After charge authorization requests for the specified number of billings or billing periods have been approved, subsequent charge authorization requests will be declined. In this manner, the number of rebillings by a particular vendor may be controlled by the account holder. Rebill limit 218 and amount (per billing period) limit 216 combine to provide control over both the amount and the duration of charges by a particular vendor (e.g., $100 per month for 12 months).
  • Excluded vendors listing 210 similarly contains an entry for each vendor specified by the account holder to be subject to special charge restrictions, with each entry containing a unique identifier 220 for the vendor and, optionally, the vendor's name 222. Charge authorization requests from vendors identified within excluded vendors listing 210 will always be declined.
  • Allowed and excluded vendors listings 208 and 210 each include a flag, a decline-all-others flag 224 within allowed vendors listing 208 and an approve-all-others flag 226 within excluded vendors listing 210. Decline-all-others flag 224, when set, causes all charge authorization requests from any vendors not specifically identified within the approved vendors listing 208 to be declined. Approve-all-others flag 226, when set, causes all charge authorization requests from any vendors not identified within the excluded vendors listing 210 to be approved, subject to amount and rebill limitations (if any) set in approved vendors listing 208. Decline-all-others flag 224 and approve-all-others flag 226 should be mutually exclusive, and should not both be set at the same time.
  • Vendors may be added to either allowed and excluded vendors listings 208 and 210 by an account holder either through manual entry of vendor information, or by selection of a transaction within account records and automatic extraction of vendor information (vendor identifier and name) from the account transaction records. A dictionary of vendor identifiers indexed by vendor name may be provided to the account holder for adding vendors to listings 208 and 210. In this manner, vendor-specific charge restrictions, including charge amount and rebilling limits, may be specified by the account holder either before or after an initial charge transaction.
  • Referring back to FIG. 1, the account holder employs user unit 112 to set or change vendors within the allowed and excluded vendors listings for their account information within database 110. Requesting units 104 a-104 n generate and transmit charge authorization requests relating to the account holder's account, which are received by charge authorization server 108 and processed for approval utilizing the account information within database 110. If a restriction set by the account holder within the allowed and excluded vendors listings would be violated by a received charge authorization request, the charge authorization request is declined in the response generated by charge authorization server 108. If a received charge authorization request would not violate account holder restrictions, the charge authorization request may be approved, subject to other limitations such as available balance.
  • With reference now to FIG. 3, a high level flow chart for a process of processing charge authorization requests utilizing vendor-specific charge restrictions specified by the charge account holder in accordance with a preferred embodiment of the present invention is depicted. The process begins at step 302, which depicts receiving a charge authorization requests including a vendor identifier and a charge amount (together with a unique charge account number) at a charge authorization server. The process first passes to step 304, which illustrates extracting the charge amount, the vendor identifier, and the charge account number from the charge authorization request.
  • The process next passes to step 306, which depicts a determination of whether the charge amount exceeds an available credit limit or account balance for the account identified by the account number within the charge authorization request. If not, the process proceeds to step 308, which illustrates a determination of whether the vendor identifier from the charge authorization request matches a vendor identifier within an allowed vendors listing associated with the subject account. If so, the process proceeds to step 310, which depicts a determination of whether an amount limit or a rebill limit specified by the account holder for the identified vendor would be exceeded by the requested charge to the account.
  • If a specified amount or rebill limit would be exceeded, the process proceeds to step 316, which illustrates declining the charge authorization request; if specified amount or rebill limits would not be exceeded (or if none are specified), the process proceeds instead to step 314, which depicts approving the charge authorization request.
  • Referring back to step 308, if the vendor identifier from the charge authorization request does not match any entry within the allowed vendors list associated with the account to be charged, the process proceeds instead to step 312, which illustrates a determination of whether the vendor identifier matches a vendor identifier within any entry in an excluded vendors listing associated with the account. If so, the process proceeds to step 316, which illustrates declining the charge authorization request; if not, the process proceeds instead to step 314, which depicts approving the charge authorization request. From either of step 314 or 316, the process then proceeds to step 318, which depicts the process becoming idle until another charge authorization request is received.
  • The exemplary process of FIG. 3 is a simplistic example subject to myriad variations within the spirit and scope of the present invention. For example, the determination of whether vendor-specific charge restrictions (steps 308 and 310) have been specified by an account holder for the requesting vendor may be performed before the charge amount is compared to the available credit or account balance for the account. Moreover, additional steps may be performed to check the state of exclude-all-others and allow-all-others flags as described above before approving or declining a charge authorization request.
  • The present invention improves the security of employing charge accounts by permitting vendor-specific charge restrictions by the account holder. The account holder can thus achieve “single use” charging with respect to a particular vendor by setting charge restrictions for that vendor, either before or after the charging transaction. Amount limits may be specified by the account holder for budgeting purposes, and rebill limits may be specified by the account holder to avoid billing disputes.
  • It is important to note that while the present invention has been described in the context of a fully functional data processing system and/or network, those skilled in the art will appreciate that the mechanism of the present invention is capable of being distributed in the form of a computer usable medium of instructions in a variety of forms, and that the present invention applies equally regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of computer usable mediums include: nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), recordable type mediums such as floppy disks, hard disk drives and CD-ROMs, and transmission type mediums such as digital and analog communication links.
  • While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.

Claims (33)

1. A method for managing charging transactions, comprising:
enabling a designation, by an owner of a chargeable account number and in association with the chargeable account number, of at least one specified allowed vendor and a corresponding amount limit chargeable by the specified allowed vendor; and
determining whether a current charging transaction for a specified amount by a charging vendor to the chargeable account number is within the designation.
2. The method of claim 1, wherein the step of enabling a designation of at least one specified allowed vendor and a corresponding amount limit chargeable by the specified allowed vendor further comprises:
enabling specification of the corresponding amount limit as a specified amount within a defined duration of time.
3. The method of claim 1, wherein the step of enabling a designation of at least one specified allowed vendor and a corresponding amount limit chargeable by the specified allowed vendor further comprises:
enabling specification of a number of times which the at least one specified allowed vendor is permitted to make a charging transaction within the corresponding amount limit on the chargeable account number.
4. The method of claim 1, further comprising:
enabling a designation, by the owner of the chargeable account number and in association with the chargeable account number, of at least one specified excluded vendor.
5. A method for limiting charging transactions, comprising:
responsive to receiving a charge authorization request for a charge on a charge account designated by a unique charge account number, determining whether an account holder for the charge account has specified vendor-specific charge restrictions for charges against the charge account;
responsive to determining that the account holder has specified vendor-specific charge restrictions for the charge account, determining a vendor identifier from the charge authorization request and comparing the vendor identifier to a list of vendor identifiers for the vendor-specific charge restrictions; and
responsive to identifying a match between the vendor identifier from the charge authorization request and a vendor identifier within an entry in the list of vendor identifiers for the vendor-specific charge restrictions, employing a charge restriction associated with the matching entry in responding to the charge authorization request.
6. The method of claim 5, wherein the step of determining whether an account holder for the charge account has specified vendor-specific charge restrictions for charges against the charge account further comprises:
employing the unique charge account number to retrieve account records for the charge account.
7. The method of claim 5, wherein the step of determining a vendor identifier from the charge authorization request and comparing the vendor identifier to a list of vendor identifiers for the vendor-specific charge restrictions further comprises:
comparing the vendor identifier from the charge authorization request to each vendor identifier within an entry in an allowed vendors listing associated with the charge account; and
comparing the vendor identifier from the charge authorization request to each vendor identifier within an entry in an excluded vendors listing associated with the charge account.
8. The method of claim 7, wherein the step of employing a charge restriction associated with the matching entry in responding to the charge authorization request further comprises:
determining whether a charge amount from the charge authorization request would exceed an amount limit specified within an entry in the allowed vendors listing; and
determining whether the charge would exceed a rebill limit specified within an entry in the allowed vendors listing.
9. The method of claim 7, wherein the step of employing a charge restriction associated with the matching entry in responding to the charge authorization request further comprises:
determining whether the allowed vendors listing specifies that charge authorization requests from all vendors not identified within the allowed vendors listing are to be declined.
10. The method of claim 7, wherein the step of employing a charge restriction associated with the matching entry in responding to the charge authorization request further comprises:
determining whether the excluded vendors listing specifies that charge authorization requests from all vendors not identified within the excluded vendors listing are to be approved.
11. The method of claim 5, further comprising:
approving the charge authorization request if no charge restriction specified by the account holder for the charge account will be violated by the charge; and
declining the charge authorization request if any charge restriction specified by the account holder for the charge account will be violated by the charge.
12. A system for managing charging transactions, comprising:
means for enabling a designation, by an owner of a chargeable account number and in association with the chargeable account number, of at least one specified allowed vendor and a corresponding amount limit chargeable by the specified allowed vendor; and
means for determining whether a current charging transaction for a specified amount by a charging vendor to the chargeable account number is within the designation.
13. The system of claim 12, wherein the means for enabling a designation of at least one specified allowed vendor and a corresponding amount limit chargeable by the specified allowed vendor further comprises:
means for enabling specification of the corresponding amount limit as a specified amount within a defined duration of time.
14. The system of claim 12, wherein the means for enabling a designation of at least one specified allowed vendor and a corresponding amount limit chargeable by the specified allowed vendor further comprises:
means for enabling specification of a number of times which the at least one specified allowed vendor is permitted to make a charging transaction within the corresponding amount limit on the chargeable account number.
15. The system of claim 12, further comprising:
means for enabling a designation, by the owner of the chargeable account number and in association with the chargeable account number, of at least one specified excluded vendor.
16. A system for limiting charging transactions, comprising:
means, responsive to receiving a charge authorization request for a charge on a charge account designated by a unique charge account number, for determining whether an account holder for the charge account has specified vendor-specific charge restrictions for charges against the charge account;
means, responsive to determining that the account holder has specified vendor-specific charge restrictions for the charge account, for determining a vendor identifier from the charge authorization request and comparing the vendor identifier to a list of vendor identifiers for the vendor-specific charge restrictions; and
means, responsive to identifying a match between the vendor identifier from the charge authorization request and a vendor identifier within an entry in the list of vendor identifiers for the vendor-specific charge restrictions, for employing a charge restriction associated with the matching entry in responding to the charge authorization request.
17. The system of claim 16, wherein the means for determining whether an account holder for the charge account has specified vendor-specific charge restrictions for charges against the charge account further comprises:
means for employing the unique charge account number to retrieve account records for the charge account.
18. The system of claim 16, wherein the means for determining a vendor identifier from the charge authorization request and comparing the vendor identifier to a list of vendor identifiers for the vendor-specific charge restrictions further comprises:
means for comparing the vendor identifier from the charge authorization request to each vendor identifier within an entry in an allowed vendors listing associated with the charge account; and
means for comparing the vendor identifier from the charge authorization request to each vendor identifier within an entry in an excluded vendors listing associated with the charge account.
19. The system of claim 18, wherein the means for employing a charge restriction associated with the matching entry in responding to the charge authorization request further comprises:
means for determining whether a charge amount from the charge authorization request would exceed an amount limit specified within an entry in the allowed vendors listing; and
means for determining whether the charge would exceed a rebill limit specified within an entry in the allowed vendors listing.
20. The system of claim 18, wherein the means for employing a charge restriction associated with the matching entry in responding to the charge authorization request further comprises:
means for determining whether the allowed vendors listing specifies that charge authorization requests from all vendors not identified within the allowed vendors listing are to be declined.
21. The system of claim 18, wherein the means for employing a charge restriction associated with the matching entry in responding to the charge authorization request further comprises:
means for determining whether the excluded vendors listing specifies that charge authorization requests from all vendors not identified within the excluded vendors listing are to be approved.
22. The system of claim 16, further comprising:
means for approving the charge authorization request if no charge restriction specified by the account holder for the charge account will be violated by the charge; and
means for declining the charge authorization request if any charge restriction specified by the account holder for the charge account will be violated by the charge.
23. A computer program product within a computer usable medium for managing charging transactions, comprising:
instructions for enabling a designation, by an owner of a chargeable account number and in association with the chargeable account number, of at least one specified allowed vendor and a corresponding amount limit chargeable by the specified allowed vendor; and
instructions for determining whether a current charging transaction for a specified amount by a charging vendor to the chargeable account number is within the designation.
24. The computer program product of claim 23, wherein the instructions for enabling a designation of at least one specified allowed vendor and a corresponding amount limit chargeable by the specified allowed vendor further comprise:
instructions for enabling specification of the corresponding amount limit as a specified amount within a defined duration of time.
25. The computer program product of claim 23, wherein the instructions for enabling a designation of at least one specified allowed vendor and a corresponding amount limit chargeable by the specified allowed vendor further comprise:
instructions for enabling specification of a number of times which the at least one specified allowed vendor is permitted to make a charging transaction within the corresponding amount limit on the chargeable account number.
26. The computer program product of claim 23, further comprising:
instructions for enabling a designation, by the owner of the chargeable account number and in association with the chargeable account number, of at least one specified excluded vendor.
27. A computer program product within a computer usable medium for limiting charging transactions, comprising:
instructions, responsive to receiving a charge authorization request for a charge on a charge account designated by a unique charge account number, for determining whether an account holder for the charge account has specified vendor-specific charge restrictions for charges against the charge account;
instructions, responsive to determining that the account holder has specified vendor-specific charge restrictions for the charge account, for determining a vendor identifier from the charge authorization request and comparing the vendor identifier to a list of vendor identifiers for the vendor-specific charge restrictions; and
instructions, responsive to identifying a match between the vendor identifier from the charge authorization request and a vendor identifier within an entry in the list of vendor identifiers for the vendor-specific charge restrictions, for employing a charge restriction associated with the matching entry in responding to the charge authorization request.
28. The computer program product of claim 27, wherein the instructions for determining whether an account holder for the charge account has specified vendor-specific charge restrictions for charges against the charge account further comprise:
instructions for employing the unique charge account number to retrieve account records for the charge account.
29. The computer program product of claim 28, wherein the instructions for determining a vendor identifier from the charge authorization request and comparing the vendor identifier to a list of vendor identifiers for the vendor-specific charge restrictions further comprise:
instructions for comparing the vendor identifier from the charge authorization request to each vendor identifier within an entry in an allowed vendors listing associated with the charge account; and
instructions for comparing the vendor identifier from the charge authorization request to each vendor identifier within an entry in an excluded vendors listing associated with the charge account.
30. The computer program product of claim 29, wherein the instructions for employing a charge restriction associated with the matching entry in responding to the charge authorization request further comprise:
instructions for determining whether a charge amount from the charge authorization request would exceed an amount limit specified within an entry in the allowed vendors listing; and
instructions for determining whether the charge would exceed a rebill limit specified within an entry in the allowed vendors listing.
31. The computer program product of claim 30, wherein the instructions for employing a charge restriction associated with the matching entry in responding to the charge authorization request further comprise:
instructions for determining whether the allowed vendors listing specifies that charge authorization requests from all vendors not identified within the allowed vendors listing are to be declined.
32. The computer program product of claim 30, wherein the instructions for employing a charge restriction associated with the matching entry in responding to the charge authorization request further comprise:
instructions for determining whether the excluded vendors listing specifies that charge authorization requests from all vendors not identified within the excluded vendors listing are to be approved.
33. The computer program product of claim 30, further comprising:
instructions for approving the charge authorization request if no charge restriction specified by the account holder for the charge account will be violated by the charge; and
instructions for declining the charge authorization request if any charge restriction specified by the account holder for the charge account will be violated by the charge.
US11/063,143 2000-10-02 2005-02-22 Personally customizable credit card accounts Abandoned US20050137971A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/063,143 US20050137971A1 (en) 2000-10-02 2005-02-22 Personally customizable credit card accounts
US12/136,607 US20080243691A1 (en) 2000-10-02 2008-06-10 Personally customizable credit card accounts

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US67657300A 2000-10-02 2000-10-02
US11/063,143 US20050137971A1 (en) 2000-10-02 2005-02-22 Personally customizable credit card accounts

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US67657300A Division 2000-10-02 2000-10-02

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/136,607 Continuation US20080243691A1 (en) 2000-10-02 2008-06-10 Personally customizable credit card accounts

Publications (1)

Publication Number Publication Date
US20050137971A1 true US20050137971A1 (en) 2005-06-23

Family

ID=34676986

Family Applications (4)

Application Number Title Priority Date Filing Date
US11/062,421 Expired - Fee Related US7552088B2 (en) 2000-10-02 2005-02-22 Personally customizable credit card accounts
US11/063,143 Abandoned US20050137971A1 (en) 2000-10-02 2005-02-22 Personally customizable credit card accounts
US12/059,677 Abandoned US20080177651A1 (en) 2000-10-02 2008-03-31 Personally customizable credit card accounts
US12/136,607 Abandoned US20080243691A1 (en) 2000-10-02 2008-06-10 Personally customizable credit card accounts

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US11/062,421 Expired - Fee Related US7552088B2 (en) 2000-10-02 2005-02-22 Personally customizable credit card accounts

Family Applications After (2)

Application Number Title Priority Date Filing Date
US12/059,677 Abandoned US20080177651A1 (en) 2000-10-02 2008-03-31 Personally customizable credit card accounts
US12/136,607 Abandoned US20080243691A1 (en) 2000-10-02 2008-06-10 Personally customizable credit card accounts

Country Status (1)

Country Link
US (4) US7552088B2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109615385A (en) * 2018-11-19 2019-04-12 中国银行股份有限公司 Limit control method, device and the storage medium of brush face transaction
US20220337558A1 (en) * 2021-04-16 2022-10-20 Nokia Technologies Oy Security enhancement on inter-network communication
CN116051058A (en) * 2023-03-18 2023-05-02 北京帮邦通达医疗器械有限公司 Method, system, terminal and storage medium for managing first camping of suppliers
US20230169512A1 (en) * 2021-11-30 2023-06-01 Capital One Services, Llc Systems and methods for dynamically funding transactions
US11935067B2 (en) * 2021-11-30 2024-03-19 Capital One Services, Llc Systems and methods for dynamically funding transactions

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7857212B1 (en) * 2008-02-14 2010-12-28 Capital One Financial Corporation Method and system for authorizing card account transactions by geographic region
US20110202462A1 (en) * 2008-09-08 2011-08-18 Mastercard International Inc. Method for a payment cardholder to control and manage the use of a payment card
US10867298B1 (en) 2008-10-31 2020-12-15 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US20100114768A1 (en) 2008-10-31 2010-05-06 Wachovia Corporation Payment vehicle with on and off function
US8019685B2 (en) * 2009-03-03 2011-09-13 Visa International Service Association System and method for account level blocking
US20110178929A1 (en) * 2009-03-03 2011-07-21 Paul Durkin Business-to-business transaction qualifier
US20110238465A1 (en) * 2010-03-25 2011-09-29 Leesa Shapiro Willet System for Controlling Card Transactions
US10043209B2 (en) 2010-11-19 2018-08-07 Mastercard International Incorporated Method and system for consumer transactions using voice or human based gesture actions
US9836737B2 (en) 2010-11-19 2017-12-05 Mastercard International Incorporated Method and system for distribution of advertisements to mobile devices prompted by aural sound stimulus
US9384499B2 (en) 2010-11-19 2016-07-05 Mastercard International Incorporated Method and system for indirect control of a website
US9836780B2 (en) 2010-11-19 2017-12-05 Mastercard International Incorporated Method and system for consumer transactions using voice or human based gesture actions
US10098813B2 (en) 2014-09-03 2018-10-16 Sun Pharmaceutical Industries Limited Perfusion dosage form
US11429975B1 (en) 2015-03-27 2022-08-30 Wells Fargo Bank, N.A. Token management system
US11170364B1 (en) 2015-07-31 2021-11-09 Wells Fargo Bank, N.A. Connected payment card systems and methods
IL261038B1 (en) 2016-02-09 2024-02-01 Sun Pharmaceutical Ind Ltd Perfusion system
US11615402B1 (en) 2016-07-01 2023-03-28 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
US11386223B1 (en) 2016-07-01 2022-07-12 Wells Fargo Bank, N.A. Access control tower
US10992679B1 (en) 2016-07-01 2021-04-27 Wells Fargo Bank, N.A. Access control tower
US11556936B1 (en) 2017-04-25 2023-01-17 Wells Fargo Bank, N.A. System and method for card control
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
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 (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4837422A (en) * 1987-09-08 1989-06-06 Juergen Dethloff Multi-user card system
US5350906A (en) * 1992-11-25 1994-09-27 Brody Bill E Currency transfer system and method using fixed limit cards
US5765144A (en) * 1996-06-24 1998-06-09 Merrill Lynch & Co., Inc. System for selecting liability products and preparing applications therefor
US5864830A (en) * 1997-02-13 1999-01-26 Armetta; David Data processing method of configuring and monitoring a satellite spending card linked to a host credit card
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
US5914472A (en) * 1997-09-23 1999-06-22 At&T Corp Credit card spending authorization control system
US5930775A (en) * 1997-01-14 1999-07-27 Freddie Mac Method and apparatus for determining an optimal investment plan for distressed residential real estate loans
US5953710A (en) * 1996-10-09 1999-09-14 Fleming; Stephen S. Children's credit or debit card system
US5961593A (en) * 1997-01-22 1999-10-05 Lucent Technologies, Inc. System and method for providing anonymous personalized browsing by a proxy system in a network
US5984180A (en) * 1997-10-06 1999-11-16 Albrecht; Jerry L. Method and system for gift credit card
US20010047336A1 (en) * 2000-04-03 2001-11-29 Maycock Sidney M. Credit card management system
US6374230B1 (en) * 1997-03-12 2002-04-16 Walker Digital, Llc Method, apparatus and program for customizing credit accounts
US6422462B1 (en) * 1998-03-30 2002-07-23 Morris E. Cohen Apparatus and methods for improved credit cards and credit card transactions

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5815657A (en) * 1996-04-26 1998-09-29 Verifone, Inc. System, method and article of manufacture for network electronic authorization utilizing an authorization instrument
US6636833B1 (en) 1998-03-25 2003-10-21 Obis Patents Ltd. Credit card system and method
WO2001042965A1 (en) * 1999-12-10 2001-06-14 Auripay, Inc. Method and apparatus for improved financial instrument processing
US7337144B1 (en) * 2000-09-28 2008-02-26 Microsoft Corporation Method and system for restricting the usage of payment accounts

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4837422A (en) * 1987-09-08 1989-06-06 Juergen Dethloff Multi-user card system
US5350906A (en) * 1992-11-25 1994-09-27 Brody Bill E Currency transfer system and method using fixed limit cards
US5765144A (en) * 1996-06-24 1998-06-09 Merrill Lynch & Co., Inc. System for selecting liability products and preparing applications therefor
US5953710A (en) * 1996-10-09 1999-09-14 Fleming; Stephen S. Children's credit or debit card system
US5930775A (en) * 1997-01-14 1999-07-27 Freddie Mac Method and apparatus for determining an optimal investment plan for distressed residential real estate loans
US5961593A (en) * 1997-01-22 1999-10-05 Lucent Technologies, Inc. System and method for providing anonymous personalized browsing by a proxy system in a network
US5864830A (en) * 1997-02-13 1999-01-26 Armetta; David Data processing method of configuring and monitoring a satellite spending card linked to a host credit card
US6374230B1 (en) * 1997-03-12 2002-04-16 Walker Digital, Llc Method, apparatus and program for customizing credit accounts
US5914472A (en) * 1997-09-23 1999-06-22 At&T Corp Credit card spending authorization control system
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
US5984180A (en) * 1997-10-06 1999-11-16 Albrecht; Jerry L. Method and system for gift credit card
US6422462B1 (en) * 1998-03-30 2002-07-23 Morris E. Cohen Apparatus and methods for improved credit cards and credit card transactions
US20010047336A1 (en) * 2000-04-03 2001-11-29 Maycock Sidney M. Credit card management system

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109615385A (en) * 2018-11-19 2019-04-12 中国银行股份有限公司 Limit control method, device and the storage medium of brush face transaction
US20220337558A1 (en) * 2021-04-16 2022-10-20 Nokia Technologies Oy Security enhancement on inter-network communication
US11818102B2 (en) * 2021-04-16 2023-11-14 Nokia Technologies Oy Security enhancement on inter-network communication
US20230169512A1 (en) * 2021-11-30 2023-06-01 Capital One Services, Llc Systems and methods for dynamically funding transactions
US11935067B2 (en) * 2021-11-30 2024-03-19 Capital One Services, Llc Systems and methods for dynamically funding transactions
CN116051058A (en) * 2023-03-18 2023-05-02 北京帮邦通达医疗器械有限公司 Method, system, terminal and storage medium for managing first camping of suppliers

Also Published As

Publication number Publication date
US7552088B2 (en) 2009-06-23
US20080243691A1 (en) 2008-10-02
US20050144123A1 (en) 2005-06-30
US20080177651A1 (en) 2008-07-24

Similar Documents

Publication Publication Date Title
US7552088B2 (en) Personally customizable credit card accounts
US8224753B2 (en) System and method for identity verification and management
US8818904B2 (en) Generation systems and methods for transaction identifiers having biometric keys associated therewith
CA2878813C (en) System and method for verifying a financial instrument
US20060218407A1 (en) Method of confirming the identity of a person
US7930243B1 (en) Method and system for management of financial accounts
US20040255143A1 (en) Data integrity
US20030074314A1 (en) Electronic money holding device and electronic money automatic payment method
US20100100482A1 (en) Intermediate Data Generation For Transaction Processing
EP1223524A2 (en) System and method for private and secure financial transactions
US20080172342A1 (en) Secure Money Transfer Systems And Methods Using Biometric Keys Associated Therewith
US7016878B2 (en) Content sales period verifying system and content decryption key effective period verifying system
JP2004506973A (en) Automatic payment system
US20020035479A1 (en) Access contract changing method for automatically changing an access contract between a prepaid contract and a postpaid contract
KR20200056648A (en) Method for mediating card payment using biometric data
AU2017269808A1 (en) System and method for account security
US20100094756A1 (en) System and method for rapid financial transactions through an open financial exchange or wire transfer
US20200342425A1 (en) Account balance sharing system
US20020091693A1 (en) Software program providing system and software program providing method
US11120432B2 (en) Security tool for information exchange
US20020143702A1 (en) Method and apparatus for settling online prepaid transaction with optical disc
KR101152891B1 (en) Financial Transaction System Providing Lifelong Account Number Service and Operating Method Thereof
JP2003162572A (en) Management system of credit information for leasing real estate property
WO2006133515A1 (en) A method of confirming the identity of a person

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: EXPRESSLY ABANDONED -- DURING EXAMINATION

AS Assignment

Owner name: EBAY INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:029528/0925

Effective date: 20120928

AS Assignment

Owner name: PAYPAL, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EBAY INC.;REEL/FRAME:036163/0469

Effective date: 20150717