Data processing: financial – business practice – management – or co – Business processing using cryptography – Secure transaction
Reexamination Certificate
2000-06-05
2004-01-13
Hayes, John W. (Department: 3621)
Data processing: financial, business practice, management, or co
Business processing using cryptography
Secure transaction
C705S078000
Reexamination Certificate
active
06678666
ABSTRACT:
I. BACKGROUND
1. Field of Invention
This invention relates primarily to accounts such as credit card accounts, checking and/or savings accounts, and any related method of electronic funds. Also note that this invention can take many forms and it is the purpose of this draft to explain the most common embodiments of this invention. This invention includes a compact, portable calculating apparatus having a memory for storing a price and an internal clock for conveniently determining the time and/or date value for computing an authorization code and its use for calculating and allowing a vendor to store protected, anti-fraud bank security deposits for annual fees and other purposes, even after the later changing of a formula by the account holder.
It is well known in the prior art that traditional credit cards and other accounts can be overcharged and fraudulently used. The main purpose of this invention is to prevent credit card fraud and to simultaneously allow a vendor to make an annual fee or other charge to a credit-card user's account, even after constant changing of one's own formula, which comprises variables of date, time, and price.
2. Description of Prior Art
U.S. Pat. No. 5,485,510 to Raymond O. Colbert (Jan. 16, 1996) mentions a way of providing a method to produce an authorization code that keeps the account number of a card confidential. This method normally requires the account holder to call in to receive an authorization code from a bank and send the code to a merchant for a purchase. The account holder makes a purchase by providing an authorization code and not the account number to a vendor, ensuring its security. This prior art patent discloses a way to include a time limit for a vendor to make a charge, but does not mention any method of providing to an account holder a calculating apparatus that can conveniently store on file a preset formula which can be used to make purchases possible, nor does the prior art patent disclose any portable apparatus having an internal clock for creating the necessary time and/or date restrictions. This method also only explains a method of making phone transactions safer against fraud, but does not protect against fraudulent charges made by someone who documents your account number and makes charges by other methods.
In U.S. Pat. Nos. 6,023,682 and 6,052,675 to R. Checchio (They disclose the same invention.), a method is explained for using an apparatus to determine whether or not a credit card user is an authorized user during a transaction. In use, an authorized user makes a purchase by first entering a price into a purchase apparatus, which is then encrypted into a code using a pre-stored PIC as a “key”. The method explains that the credit card number, and the “purchase token” are then transferred to a merchant, who then transfers the data to a verification system to determine whether or not a user is an authorized user. Only an authorized user and the bank have knowledge of the confidential PIC, which a verification system uses to compare a “test token” with a “purchase token”; and that a third party who gets access to a lone credit card cannot use it without the confidential PIC. This only allows the merchant to determine whether or not a user is authorized, and the main flaw is that a dishonest merchant, whom allows an authorized user to use one's card at a vendor location, can use a valid “test token” repeatedly for a multiple charge amount.
Since the purpose behind U.S Pat. No. 6,052,675 was simply to determine whether a card-user is the real user when making a purchase (without comparing signatures), its inventor failed to recognize that also including time-date data as well as price encryption information would stop a merchant from fraudulently using a credit card at all. The patent just explains that a calculating apparatus to produce a “purchase token” may contain various types of information for validating that a user is authorized to make a transaction. In addition, U.S. Pat. No. 6,052,675 to R. Checchio, does not even mention the idea of a calculating apparatus having an internal clock for encrypting time AND date data into a “purchase token” nor does it explain whether or not a merchant having prerecorded data can use the exact same price and credit card data again (on the SAME DAY) for a duplicate charge. The method disclosed in U.S. Pat. No. 6,052,675 to R. Checchio simply cites that a string of data “CAN also include other types of information, for example, vendor name, type of lease, type of purchase, date of sale, category of merchandise, location of the vendor or any other relevant piece of information . . . that would serve to distinguish a particular purchase or lease transaction.”
If a bank allows a “purchase token” or authorization code having valid purchase amount data to be used more than once on the same day, a merchant can use the same information over and over for multiple charges of the same purchase amount. This would breach security to a cardholder. Since it is such a critical function of a calculating apparatus to have its own internal clock to produce time data (and not JUST date data) restrictions to correctly perform, but no calculating apparatus with an internal clock to produce a time figure is mentioned in U.S. Pat. No. 6,023,682 to R. Checchio OR in U.S. Pat. No. 5,485,510 to Raymond Colbert (even though the first cites the latter!), an internal clock within a calculating apparatus to produce time-date variables, therefore, cannot be considered obvious. It is, once again, very important to provide a method so that a person who has a card number cannot increase the price of a charge, make a charge again with the same price on a different date and/or time, or make a valid charge again with the same date-time-price data once a valid charge is withdrawn.
Also, other flaws of U.S. Pat. Nos. 6,023,682 and 5,485,510 can be recognized after being thoroughly explained. It is well known that some companies, such as car rentals, require a credit card number to be held as a payment option so that any losses to the company can later be compensated by charging a predetermined amount on the credit card. This is known as a security payment option. The main problem with U.S. Pat. No. 5,485,510 to Raymond O. Colbert, is that without an advanced system of storing and verifying Price-Date-Time data by a bank, security deposits, annual fees, and later payments would have difficulty being collected at a later date when a formula is changed by the cardholder. An account holder may find it necessary to communicate price, date and other data to a merchant for being held as a security deposit, then change a formula for producing an authorization code if its user thinks that a particular merchant, after being visited by the particular customer for a long time, has determined a pattern to produce an authorization code.
Also, if a dishonest person somehow acquires a cardholder's formula, the account holder should be able to change his formula without blocking any annual fees or other services that are put on a particular credit card. There would be a great inconvenience in having to call the account holder, get his authorization code and all variables associated with a purchase that utilizes a newly created formula, then run the account to collect payment from the credit card user. This can be extremely problematic if an account holder decides to damage merchandise such as a car and be called to get his authorization code. In most instances, the account holder after having damaged merchandise may not want to give the required information for the merchant to collect payment. This would in turn defeat the purpose as to why the company held the account number on record and would negate the reason to holding a credit card number.
Also, U.S. Pat. No. 6,052,675, does not disclose any method to avoid this problem if a formula or “key” is changed. Another method for the company to do in this instance would be to charge the card in advance and hold the deposit in a savings account. This can be t
Harrison R. Keith
Hayes John W.
Huseman M.
LandOfFree
Method of conducting anti-fraud electronic bank security... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of conducting anti-fraud electronic bank security..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of conducting anti-fraud electronic bank security... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3268246