Methods for Customizing Secured Transactions that are Verified by a Money Source
Methods for providing secure transactions in which a customization parameter and an encrypted transaction validation code are received from a user to positively identify a transaction for a user who has a first entity identifier. The validation code and first entity identifier are used by a money source which electronically verifies that the transaction is valid by use of the first entity identifier and the validation code while the first transaction is customized through use of the customization parameter.
Latest PRIVASYS, INC. Patents:
The present application is a continuation application of U.S. patent application Ser. No. 10/968,401, filed Oct. 18, 2004, which was a continuation application of U.S. patent application Ser. No. 09/960,714, filed Sep. 21, 2001, which was a continuation-in-part application of U.S. application Ser. Nos. 09/667,081 and 09/667,089, filed Sep. 21, 2000, which are continuation-in-part applications of U.S. Ser. No. 09/659,434, filed Sep. 8, 2000, which is a continuation-in-part of U.S. Ser. No. 09/640,044, filed Aug. 15, 2000, which is a continuation-in-part of U.S. Ser. No. 09/619,859, filed Jul. 20, 2000, which is a continuation-in-part of U.S. Pat. No. 6,592,044, all of which disclosures are specifically incorporated herein by reference. The present application' is also related to U.S. patent application Ser. Nos. 09/667,835, 09/667,089, and 09/667,082, all of which were filed on Sep. 21, 2000, and all of which are specifically incorporated herein by reference.
FIELD OF THE INVENTIONThe present invention is in the field of methods for customizing secured transactions between multiple parties that are verified by a money source.
BACKGROUND OF THE INVENTIONThree forms of money in widespread use today throughout the world are cash, checks and payment cards (debit or credit). Each has distinct advantages, and distinct disadvantages. Cash is readily accepted, easy to use and anonymous, but it does not earn interest, it can be lost or stolen, and it is not always readily accessible. Checks are not always accepted, but they offer many advantages, since they do not have to be written until the time of payment. However, they must be physically presented and they are not anonymous. Payment cards are readily, but not always, accepted, and they offer many advantages over checks. If the card is a credit card, payment can be deferred, but the transaction is not anonymous. If the card is a debit card, payment has usually been made prior to its use, but it is anonymous. Accordingly, it is apparent that different types of money have different advantages to different persons in different situations. This may be one reason why all these forms of money are still in widespread use, and are even used by the same persons at different times.
As society and international commerce have become more dependent upon electronic transactions, money has also become more electronic. Many attempts have been made to come up with suitable forms of electronic money that mimic the physical world, or even create new forms of electronic money. However, despite the enormous need for such money, and efforts by some of the best minds and most successful companies in the world, electronic money has suffered many setbacks and been far slower to materialize than many had hoped or predicted. The reasons are many and varied, but some of the obvious reasons are security, ease of use/operation, and unwillingness of the public and/or commerce to make radical changes or embrace new technology and/or procedures. As a result, many efforts, including several potentially promising efforts, have met with failure.
Even though new forms of electronic money have been slow to develop or gain widespread acceptance, electronic payments have still moved forward. Many banks now offer some form of electronic checking. And payment cards have been used for electronic transactions in e-commerce and m-commerce (mobile commerce). Still, there is widespread concern about the safety of such transactions, and recent news stories have uncovered widespread fraudulent activity associated with use of traditional credit card numbers in e-commerce over the Internet. In addition, there is growing concern about consumer privacy, or lack thereof, due to widespread electronic profiling of consumers who make electronic payments.
Although the media has been quick to cover fraud associated with use of credit cards over the Internet, it is often overlooked, at least by the public and the media (but not the credit card companies), that the majority of fraudulent activity concerning credit cards is not associated with e-commerce activity. Most fraud occurs in the “brick and mortar” world, and the numbers are daunting. Despite many attempts to combat unauthorized or fraudulent use of credit cards, it is estimated that credit card fraud now exceeds hundreds of millions, if not several billion, dollars per year. And this does not even count the cost of inconvenience to consumers, merchants and credit card issuer/providers, or the emotional distress caused to victims of such fraud, or the cost to society in terms of law enforcement and preventative activities.
Accordingly, there is a very real, long-felt need to reduce the amount of fraudulent activity that is associated with credit cards, and this need has only grown more acute as consumers and commerce search for better ways to purchase and sell goods and services via e-commerce and m-commerce. However, any solution needs to be something that is acceptable to the public at large. It should be easy to use. It should not be complicated or expensive to implement. Preferably, it should fit within the existing infrastructure, and not be something that requires a great deal of educational effort, or a radical change in behavior or habits of consumers. In other words, it should be user friendly, readily understandable and something that does not require a completely new infrastructure, which is a reason suggested by some as to why smart cards have not been widely accepted in the United States.
In addition, it is highly desirable that any solution to such problems be capable of widespread use, in many different platforms, for many different applications.
In U.S. Pat. No. 5,956,699 issued in September of 1999, Wong and Anderson were the first to introduce the methodology of a system for secure and anonymous credit card transactions on the Internet. This patent introduced a system which used an algorithm to use one's own selected Personal Identification Number or PIN as one's own de facto digital signature. The algorithm instructs the cardholder how to insert one's PIN into one's valid credit card number before using it for any transactions on the Internet. The resultant scrambled up credit card number, which is tailored by the algorithm to having the same number of digits as before, is rendered useless on the Internet because the PIN insertion algorithm is changed automatically after every transaction. This methodology is not only capable of drastically reducing credit card fraud on the Internet, it is also capable of safeguarding one's anonymity, and thus privacy, in credit card purchases on the Internet.
Since the issuance of U.S. Pat. No. 5,956,699, Wong and Anderson have also invented an anonymous electronic card for generating personal Coupons useful in commercial and security transactions, as well as various methods related to earlier work.
SUMMARY OF THE INVENTIONThe present invention is generally directed to methods for providing one or more secure transactions between a first entity and an additional entity. In each method, a customization parameter is received from the first entity along with an encrypted transaction validation code which positively identifies a transaction for the first entity who has a first entity identifier. The validation code and the first entity identifier are used by a money source which electronically verifies that the first transaction is valid by use of the first entity identifier and the validation code while the first transaction is customized through use of the customization parameter. In one method the first entity identifier can be transferred to the money source as an account number and the validation code can be transferred to the money in a non-account data field. In a second method the money source validates the validation code by duplicating the encryption process used to create the validation code and then compares the result to the validation code received with the first transaction. In a third method the validation code is, at least in part, encrypted, and the money source validates the validation code by duplicating a validation code encryption process and by then comparing the result to the validation code received with the first transaction.
The customization variable can be used to select between a first handling option and a second handling option between the money source and the first entity. For example, such options can be mechanisms to bill a first account and a separate second account and the user can be sent a single bill for charges to both accounts, or separate bills. The two accounts can be credit accounts established with different money sources. The handling options can provide different mechanisms for dealing with distribution of information concerning different transactions, such as restricting the distribution of information from the money source to a third party for any transaction in which the user payment card number is generated by use of the a first user key or restricting distribution of personal information of the user relating to any payment card transaction, and the user may either provide or receive consideration for such handling options, Different handling options may be invoked by use of a second user key. The handling options can also provide a mechanism for classifying the nature of card transactions, such as noting personal transactions or identifying different users, and approval of a transaction can be subject to different restrictions depending upon whom the user is. The handling options can also be used to control what information is reported about a transaction in a billing statement.
The validation code can be formed by using a Triple Data Encryption Standard algorithm (“TEDS”). The money source can obtain the customization variable from the validation code and the customization variable can be received through use of at least one button.
Accordingly, it is a primary object of the present invention to provide improved methods for providing more secure transactions between multiple entities.
This and further objects and advantages will be apparent to those skilled in the art in connection with the detailed description of the preferred embodiments set forth below.
The present invention is related to U.S. Pat. Nos. 5,913,203, 5,937,394 and 5,956,699, the disclosures of which are all specifically incorporated herein by reference.
U.S. Pat. No. 6,592,044 provides the following disclosure of an electronic card.
A unitary, self-contained electronic device is provided having physical planar dimensions that are essentially identical to those of a conventional magnetic stripe credit card, which is widely used in electronic commerce today. The device has seven basic components, although it is possible to combine some of these components together.
The first component is the card base. The other components, in one way or another, are attached to this base.
The second component is a computer. It is preferable that the computer be a single integrated chip, but it need not be A computer typically contains a central processing unit connected to both storage memory and random access memory (RAM). RAM is used to load and run application programs as well as for storing data during run time. The storage memory can hold a variety of computer programs.
The third component is a display controlled by the computer. In the preferred embodiment, this is a liquid crystal display (LCD). The LCD can be controlled by a LCD driver, and the LCD driver can be contained in storage memory of the computer. In an alternative embodiment, the third component could be an electronic ink display, which is a novel and newly available display medium. The electronic ink display can be fabricated with highly flexible physical dimensions, especially in thickness, which is likened to a thin piece of paper and also much cheaper to manufacture than conventional LCD display.
The fourth component is an input mechanism. In the preferred embodiment, this is a keypad. However, it is possible that the input mechanism might rely upon voice recognition as this technology becomes more and more developed.
The fifth component is a magnetic storage medium. In the preferred embodiment, this is a magnetic stripe.
The sixth component is an encoder for generating a data packet that is stored in a designated portion of the magnetic storage medium. This component is what allows the electronic device to be dynamic by relying upon an input to generate the data packet.
The seventh component is a power source. In the preferred embodiment, this is a battery or a solar cell.
A primary function of this electronic device, which shall be referred to as the Universal Anonymous Credit Card (UACC), is to allow a credit cardholder to execute secure and anonymous credit card transactions on and off the Internet in accordance with the teachings of U.S. Pat. No. 5,956,699. This can be done in a system and in methodology in which merchants no longer have access to the cardholder's real name, address and the actual valid credit card number. Such an effectual personal encryption does not however, prevent the additional use of an Internet standard encryption such as SSL or SET for online data exchanges. The latter will simply make such online transactions even more secured.
For purposes of clarification and illustration, an example of an application that uses the methodology taught in U.S. Pat. No. 5,956,699 is presented here. Assume that the valid credit card number (VCCN) and the PIN number are, respectively: VCCN=4678 0123 4567 8012 1200 PIN=2468
Next, assume that the application uses an algorithm that first deletes four (4) digits from the VCCN and then inserts in their place the PIN according to the insertion sequence indicated by a so-called PIN Sequence Insertion Number (PSIN) in order to come up with the scrambled Anonymous Credit Card Number (ACCN), also containing 20 digits. The 4-digit PSIN number can either be chosen by the cardholder or assigned by the issuer. Let us assume for this example that the cardholder's PSIN is 1357.
Next, assume that the algorithm only operates on digits 5 through 6 of the VCCN. This takes into account the fact that the first 4 digits of the standard VCCN denote the identification of the credit card issuer and the last 4 digits of the standard VCCN are reserved for the expiration date, all of which should be left undisturbed. Thus, it is the middle 12 digits that indicate the account number for the cardholder of the VCCN. Therefore, the algorithm calls for the cardholder to first delete the last four digits of the 12-digit account number. In this example the 4 digits to be deleted will be “8012”. The 8-digit number before the cardholder PIN is inserted according to the cardholder's PSIN is “0123 4567”.
Now the algorithm defines the numbering convention of the digit positions in the ACCN. The first digit position is defined as the zeroth (0.sup.th) and the second is the first (1.sup.st) etc. Thus, according to the PISN 1357, the PIN 2468 should be inserted to form the ACCN as follows: ACCN=4678 021426384567 1200
The 4 digits of the PIN=2468 occupy, respectively, the 1.sup.st, 3.sup.rd, 5.sup.th and 7.sup.th positions (according to PISN=1357) using the defined digit position numbering convention. In a simpler algorithm for inserting the PIN, the PIN number itself can act effectively as the PSIN so that the cardholder does not have to remember two numbers. Using such an algorithm, in the example above, the ACCN will now be: ACCN=4678 012243648567 1200
The 4 digits of the PIN=2468 also occupy, respectively the 2.sup.nd, 4.sup.th, 6.sup.th and 8.sup.th positions of the ACCN (according to an implicit PSIN=PIN=2468) using the defined digit position numbering convention.
The applications of the teachings of U.S. Pat. No. 5,956,699 just described can be used in a system that reduces fraud while protecting consumer privacy through anonymous transactions, on and off the Internet. Such a system has three main components that are provided to complete a commercial credit card transaction. First, instead of using a valid credit card number, an ACCN is used. Second, instead of using the cardholder's real name, an alias is used. The alias can be selected by the cardholder or the issuer of the credit card, but it has to be known by both. Third, instead of using a cardholder's real address, a “Proxy Agent” is used to conceal the cardholder's actual address and still comply with current credit card transaction regulations. In such a system, the use of a credit card for transactions on the Internet can be anonymous to all except the cardholder and the credit card issuer.
In order to reduce the cost of use of the UACC, and increase the range of applications in which it can be used the UACC should have a magnetic storage medium that can be read by a standard magnetic stripe reader. This means that the magnetic storage medium must be capable of being read by a standard magnetic stripe reader. It also means that the portion of the UACC containing the magnetic storage medium must be sized such that the magnetic storage medium will work with standard magnetic stripe readers. A standard magnetic stripe reader works by passing the magnetic stripe portion of a card, such as a credit card, through the magnetic stripe reader in a swiping motion. Standard magnetic stripe readers have been prevalent in retail stores throughout the United States for many years.
An especially preferred embodiment of the UACC will now be described in even greater detail. The especially preferred embodiment uses a standard microprocessor having its usual Central Processing Unit (CPU), Read-Only-Memory (ROM), Random-Access-Memory (RAM) and Input-Output devices (I/O), There are two types of ROMs in the UACC. The first type is a standard semiconductor ROM, ROM1, fabricated as part of the microprocessor. ROM1 stores the microprocessor operating system and also the bulk of the methodology software. The second type of ROM, ROM2, is a portion of a magnetic stripe, namely Tracks 1 and 3. ROM2 stores the relevant information about the cardholder such as primary account number VCCN name, expiration date, encrypted PIN etc. There are also two types of RAMs in the UACC. The first type of RAM, RAM1, is a standard semiconductor RAM as part of the microprocessor and needed for its normal operation. The second type of RAM, RAM2, is a portion of a magnetic stripe, namely Track 2. RAM2 temporarily stores the encoded ACCN to be read by a standard magnetic stripe reader during a normal credit card transaction after the cardholder inputs the PIN according to the PSIN algorithm into the UACC.
The methodology software is installed into ROM1 of the microprocessor during production. A standard parallel port Input Device serves to interface a numeric keypad and other functional switches of the UACC to the microprocessor. The UACC also has two Output Devices. The first Output Device is a standard parallel output port of the microprocessor used for interfacing to it a 10—or more character alphanumeric LCD display through a driver far outputting information such as recalling from memory alias or typed in PIN verification. It is also used for production testing and repair or servicing of the UACC. The second Output Device is an integrated circuit (IC) magnetic encoder unit built into the UACC so as to encode Track 2 of the magnetic stripe or RAM2, either statically in conjunction with the existing magnetic stripe, or dynamically without the use of the existing magnetic stripe, with the temporary ACCN information for off the Internet credit card transactions. In this especially preferred embodiment of the present invention illustrated below, only the static magnetic encoder working in conjunction with the existing magnetic stripe is described in detailed. For those skillful in the art, the dynamic thin film magnetic encoder, working without the use of the existing magnetic stripe, can also be used in the present invention as an alternative embodiment. In a preferred embodiment of the present invention, the UACC also contains a battery cell, ON/OFF and other functional switches to render it a fully functional and self-contained credit card (see
The UACC bridges the old economy world of brick and mortar to the new economy world of the Internet. The integrated circuit (IC) magnetic encoder with current-carrying conductive writing heads is fabricated on a flexible and ultra-thin polymer (e.g. polyimide) printed circuit board (PCB) intimately in contact with the magnetic stripe located above for data impression. The encoder driver and digital logic chips are also mounted on the flexible PCB, but in different areas to form the complete IC magnetic encoder. The IC magnetic encoder is technically compatible with conventional magnetic data transfer methodology and makes possible the fabrication of the present UACC with physical dimensions exactly like those for a regular magnetic stripe portion of a credit card.
When the UACC is used in a retail transaction, by merely entering one's own PIN into the UACC prior to giving it to the merchant for swiping the credit card transaction, one takes full advantage of the secure and anonymous transaction afforded by the UACC. The user can first check his or her alias and entered PIN (note that the PIN is never stored in the UACC) using the LCD display on the UACC before the UACC is handed it over to the merchant. Since the cardholder has in effect already signed the transaction with a digital signature (his or her PIN), no additional hand signature is required to complete the transaction. The merchant only need receive the PIN-modified anonymous credit card number (ACCN) and the user's alias. The ACCN and the alias are read by a conventional magnetic stripe reader and are processed in exactly the same fashion as a conventional credit card number and credit cardholder name since such information can be sent to a credit card approval agent for approval of the transaction. The credit card approval agent has all of the information necessary to determine if the transaction is valid or fraudulent. The identity of the entity who authorized the credit card, as well as it expiration date, is available in the ACCN in just the same manner as it is available in a conventional credit card transaction. The card number is verified by confirming the card number contained in the ACCN as valid for the alias.
To use the UACC for Internet transactions, a cardholder first enters the PIN into the UACC exactly like that for off the Internet transactions. Next, the cardholder continues the transaction using only the cardholders alias, the ACCN appearing in the LCD display and also the cardholder's choice of trusted delivery (optional) should the cardholder prefer to make this transaction completely anonymous. Thus, by carrying just one UACC which looks and feels exactly like a regular magnetic stripe credit card, one is now able to make old world credit card transactions like one always has done in the past. But, more importantly, one can now use the same UACC for making secure and anonymous transactions, anywhere in the world, and for both on and off the Internet transactions.
The especially preferred embodiment of a UACC will now be described in even greater detail by reference to
In addition to the switches 3-8, there is a 12-character keypad 9. The primary function of the keypad 9 is for the cardholder to enter the PIN into the UACC 1 for generating the ACCN for on and off Internet commerce transactions. There is also a 10- or more character alphanumeric liquid crystal display (LCD) 10 on the front side 2 of the UACC 1. This LCD 10 displays the alias and the ACCN for use for Internet commerce transactions or the alias and bar code representing the ACCN after the cardholder's PIN is entered. The display of the ACCN will automatically erase itself after about 2 minutes to avoid exposing significant information to third parties.
At the top of the back side 11 of UACC 1 is a standard 3-track magnetic stripe 12 found in every common magnetic stripe credit card in use today. Track-113 and track-314 are used to store the relevant information about the cardholder such as primary account number VCCN, name, expiration date, encrypted PIN etc. Track-215 of the magnetic stripe 12 normally contains only the cardholder's VCCN to be read by a magnetic stripe reader at the merchant's site. For the present UACC device, the ACCN, instead of the VCCN, will be generated on command by entering the PIN with the appropriate function switch “MC” 7 by a special encoder 16 located at a designated location underneath the magnetic strip 12. As will be explained in more detail below, the generated ACCN which resides temporarily on Track-215 of the magnetic stripe 12 will disappear automatically 2 minutes after it is being generated. This is to ensure that no significant information about the credit card account stays long enough for fraudsters to steal for committing subsequent credit card frauds.
The system block diagram for the especially preferred embodiment of the present invention is shown in
The software program for implementing the methodology provided by U.S. Pat. No. 5,956,699 for the cardholder to execute secured and anonymous credit card transactions on and off the Internet is installed into ROM118 of the microprocessor 16 during production of the current UACC unit. Information pertaining to the cardholder is encoded onto Track-113 and Track-314 of the magnetic stripe 12 which serves as an independent ROM, ROM2, for the UACC unit. Since information stored in ROM2 will be read with a standard magnetic stripe reader, it operates independently of the microprocessor 16. A battery supply 26 with contacts 27, controlled by the ON/OFF switch 3, completes the UACC system. The battery supply provides power to all the components of the UACC system, including the microprocessor 16, LCD display driver 23, encoder driver 24, LCD display 10 and the keypad 9.
A much simplified theory on magnetic stripe technology, especially on how to encode (write) and decode (read) digital data respectively on and off a magnetic stripe used in ordinary credit cards of today, will now be provided in order to better explain how an encoder can be fabricated and work. A magnetic stripe is made out of a thin layer of very tiny ferromagnetic particles (typically 0.5 micron long) bound together with resin and subjected to a very strong magnetizing magnetic field (known as “coercivity”) when such a stripe is printed onto a substrate. When the resin is cured or set, these tiny “magnets” are magnetically and permanently aligned (magnetized) into a series of South-North magnetic domains forming a chain of S-N, S-N . . . interfaces. The adjacent N-S magnetic fluxes of these magnetic domains are normally linked together for the entire magnetic stripe to act like a single magnet with South and North poles at its ends. In other words, an un-encoded magnetic stripe is actually a series of aligned South-North magnetic domains (see
If a N-N interface (instead of the normal N-S interface for un-encoded magnetic domains) is created somewhere on the stripe, the magnetic fluxes at the N-N interface will repel each other, resulting in a concentration or increase of flux lines around the N-N interface called a “flux reversal”. The same situation exists for a S-S interface as compared with a normal N-S interface. Such a situation will take place if a strong magnetizing magnet 31 having an opposite magnetic orientation, namely N-S, is suddenly introduced on top of one of the S-N magnetic domains 32 of the magnetic stripe as shown in
The process of encoding or writing involves the creation of N-N and S-S magnetic domain interfaces, or flux reversals, and the process of decoding or reading that of detecting them. Knowing that magnetic flux lines always emanate from the North pole and terminate on the South pole, a sudden introduction of a strong magnetic field (greater than the coercivity of the magnetic domains) having a N-S magnetic orientation can magnetize a normal S-N magnetic domain into N-S orientation, resulting in the creation of a pair of flux reversals S-S and N-N, much like that shown in
Before proceeding to explain how the encoder of the especially preferred embodiment writes the ACCN on Track-215 of the magnetic stripe 12, it is helpful to delve deeper into the data storage mechanics of the magnetic stripe 12 itself. As stated earlier, the magnetic stripe 12 has three tracks, namely Track-113, Track-215 and Track-314. Digital data are stored in these three tracks according to the American National Standards Institute (ANSI) and International Standards Organization (ISO) BCD (5-bit Binary Coded Decimal Format) or ALPHA (alphanumeric) standards. The ANSI/ISO standards for Tracks 1, 2 and 3 are summarized in Table I as follows:
Track-1 13, named after the “International Air Transport Association” (IATA), contains the cardholder's name as well as account and other discretionary data, Track-2 15, “American Banking Association” (ABA), is the most commonly used. This is the track that is read by ATMs and credit card checkers. The ABA designed the specifications of this track and it is believed all major world banks abide by it. It contains the cardholder's account number, encrypted PIN, plus other discretionary data. Track-3 14 is unique and intended to have data read from and written on it. At present, it is an orphaned standard and has not been widely used to date.
Before the encoder can write on command the ACCN on Track-2 15 of the magnetic stripe, attention must be paid to the data layout for Track-2 15, Encoding protocol specifies that each track must begin and end with a length of all Zero bits, called CLOCKING BITS. These are used to synchronize the self-clocking feature of bi-phase decoding, an industry standard. A typical Track-2 layout is shown as follows:
0000000000000000; 1111222233334444=9912****000000XXXX0000? The symbol “;” after the “0's” is the “START SENTINEL” according to the BCD data format. The 4 digits “1111” following is the issuer or acquiring bank's identification number. The 12 digits following is the cardholder's account number. The symbol following is the “FIELD SEPARATOR” according to BCD data format. The 4 digits “9912” following is the expiration date. The four characters following “****” are data reserved for private use. The data length “XXXX” after the string of 0's may vary and is the encrypted PIN offset. Finally the symbol “?” after another string of 0's is “END SENTINEL”.
The location of the 12 digits that need to be encoded or written on command is represented by “2222 33334444” on Track-215 of the magnetic stripe 12 in the example cited above.
Next, it is helpful to have an understanding of how the 12 digits are represented in BCD data format on Track-215 of the magnetic stripe 12. According to the BCD data format, each decimal digit is coded by 5 bits. The ANSI/ISO BCD Data Format is reproduced in Table II below. Note that all 21 digits, including the field separator, namely “1111222233334444=9912”, can also be encoded on command if so desired.
How BCD data is actually encoded onto Track-215 of the magnetic stripe 12 can now be explained. Table I above notes that Track-2 has a density of 75 bits per inch (bpi). According to the ANSI/ISO BCD data format, each character is represented by 5 bits. Thus, if the encoder needs to encode 12 digits (see “222233334444” in example above), it will require a total of 60 bits. Since the density is 75 bpi, the maximum physical space available for a stationary encoder head is 0.800″. But the important dimension for the design of the encoder head is the space available for each BCD bit. In the present case, the bit dimension is 1,000 mils/75 bits or 13.33 mils (0.0133″) per bit.
At this point, it is useful to explain with the help of
Consistent with the Aiken Biphase convention therefore,
In order to encode in the present example a total of 12 decimal digits, one would need to encode 5.times.12 or 60 bits of data As shown in
The manner in which the Universal Anonymous Credit Card (UACC) will work under different on and offline transaction circumstances will now be described. It is first assumed that the cardholder has opened an UACC account with an issuer or acquiring bank. The cardholder has turned over a real name, address, personal and financial information to the issuer. In return, the cardholder is assigned a valid credit card number. VCCN, a credit limit, an Alias (chosen by the cardholder) and a proxy agent, and most importantly a cardholder UACC. The issuer has to assign the cardholder a proxy agent to use instead of giving out the cardholder's address in order to comply with the existing credit card transaction regulation. After obtaining a UACC from the issuer, the cardholder is now free to do anything and everything on and off the Internet safely with full assurance that nobody will find out what, where, when and how money is being spent with the UACC card, except its issuer.
The manner in which the cardholder can use his or her UACC to shop on the Internet will now be described. It is possible that not every online merchant will accept the UACC in the beginning, so the cardholder may have to identify those merchants that are partners with the UACC issuer bank. Otherwise, the transactions with the UACC will not be processed properly by the existing infrastructure that processes only conventional credit cards. Suppose the cardholder now wishes to purchase some merchandise from an online merchant who accepts UACC. All the cardholder has to send to the merchant's Web site online is his or her alias, a proxy agent's name assigned to the cardholder by the issuer bank, the ACCN or anonymous credit card number which will be obtained from the UACC (to be explained below), the merchandise and shipment choice. This is completely different from what the cardholder normally has to give out viz. a real name, address and the valid credit card number, should the cardholder use a regular credit card. To obtain the ACCN from his UACC device, all the cardholder has to do is to first push the button “CC” which is reserved for Anonymous Credit Card transactions, then to enter the cardholder's PIN using the keypad and then the “#” key. In the LCD display, the alias will first be scrolled across the display followed by the 10-digit ACCN. Note that the first six digits (four digits are used to identify the issuer bank and two more digits to designate a specific BIN number) and the last four digits of the ACCN always remain the same as those in the VCCN which signifies the issuer's identification and credit card BIN number, and the expiration date respectively. The cardholder can then use this ACCN to complete the transaction with the online merchant. After the cardholder finishes using the ACCN, he or she can either erase it from the LCD display by pressing “*” followed by “#” in the keypad, otherwise the ACCN will disappear from the LCD display automatically after approximately 2 minutes.
As one can see from this transaction on the Internet using the UACC, the real name and address of the cardholder, including the credit card number itself, never appear on the Internet or even are made known to the merchant. Even though the ACCN or Coupon does appear, together with the alias of the cardholder, across the Internet during the online transaction, this ACCN or Coupon number does not stay the same, according to the methodology of U.S. Pat. No. 5,956,699, but changes automatically after every transaction or use. Thus, unlike all the other credit card transactions on the Internet today, no valid credit card numbers are actually available in transmission for theft by anybody. Only the ACCN or Coupon number will appear on any or all transaction records and that number is useless for any subsequent transactions because it is time variant.
For off the Internet transactions, the UACC behaves just like an ordinary credit card. The only difference is that before one hands over the UACC to the merchant for charging the amount, one enters one's PIN after pushing first the “MC” button on the UACC device, which is reserved for magnetic stripe credit card transactions, and then follows it with a “#” key on the keypad. It is assumed here that the cardholder is satisfied with what is being charged on the credit card before the cardholder, in effect, “signs” it digitally in the transaction. Unlike ordinary magnetic stripe credit cards of today, no personal hand signature is needed for off the Internet transactions with the UACC. By entering the PIN, the UACC automatically encodes temporarily the ACCN onto Track-2 of the magnetic stripe 12. The use of the resultant ACCN or Coupon is likened to the cardholder already signing the credit card with a personal digital signature for the transaction. The rest of the transaction simply follows that of a regular magnetic stripe credit card with the existing credit card processing infrastructure.
Thus, there has been described a Universal Anonymous Credit Card (UACC) device that is capable of allowing the cardholder to execute on and off the Internet secure and anonymous credit card transactions. The UACC can be used in methods for implementing an anonymous credit card transaction between a user and a merchant as is described in U.S. Ser. No. 09/619,859. An embodiment of such a method is set forth in
After a user account is established, the credit source will create one or more user account records associated with the user account to contain a variety of information, including a user account number, a fictitious account name, a “Proxy Agent,” a user key and when applicable, a user insertion key. The fictitious account name can be selected by the cardholder or the issuer of the credit card, but it has to be known by both. The “Proxy Agent” is used to conceal the cardholder's actual address and still comply with current credit card transaction regulations—in other words, it is a fictitious address. Additional information that might typically be contained within such records includes cross references to other accounts, the user's name and the user's billing address. An electronic card, such as the UACC card, uses an algorithm to generate a valid personal charge number.
When the electronic card is used in a retail transaction, by merely entering ones own PIN into the electronic card prior to giving it to the merchant for swiping the credit card transaction, one takes full advantage of the secure and anonymous transaction afforded by the electronic card. The user can first check his or her alias and entered PIN (note that the PIN is never stored in the electronic card) using the keypad on the electronic card before the electronic card is handed it over to the merchant. Since the cardholder has in effect already signed the transaction with a digital signature (his or her PIN), no additional hand signature is required to complete the transaction. The merchant only need receive the PIN-modified anonymous credit card number (ACCN) and the user's alias. The ACCN and the alias are read by a conventional magnetic stripe reader and are processed in exactly the same fashion as a conventional credit card number and credit cardholder name since such information can be sent to a credit card approval agent for approval of the transaction. The credit card approval agent has all of the Information necessary to determine if the transaction is valid or fraudulent. The identity of the entity who authorized the credit card, as well as It expiration date, is available in the ACCN in just the same manner as it is available in a conventional credit card transaction. The card number is verified by confirming the card number contained in the ACCN as valid for the alias.
To use the electronic card for Internet transactions, a cardholder first enters the PIN into the electronic card exactly like that for off the Internet transactions. Next, the cardholder continues the transaction using only the cardholder's alias, the ACCN appearing in the LCD display and also the cardholders choice of trusted delivery or Proxy Agent (optional) should the cardholder prefer to make this transaction completely anonymous. Thus, by carrying just one electronic card which looks and feels exactly like a regular magnetic stripe credit card, one is now able to make old world credit card transactions like one always has done in the past. But, more importantly, one can now use the same electronic card for making secure and anonymous transactions, anywhere in the world, and for both on and off the Internet transactions.
As is apparent from the foregoing description, the real name and address of the cardholder, including the credit card number itself, never need appear on the Internet or even need to be made known to the merchant. Even though the ACCN or Coupon (Customer One-time Unique Purchase Order Number) does appear, together with the alias of the cardholder, across the Internet during the online transaction, this ACCN or Coupon number does not stay the same, according to the methodology of U.S. Pat. No. 5,956,699, but changes automatically after every transaction or use. Thus, unlike all the other credit card transactions on the Internet today, no valid credit card numbers are actually available in transmission for theft by anybody. Only the ACCN or Coupon number will appear on any or all transaction records and that number is useless for any subsequent transactions because it is time variant.
Accordingly, this disclosure includes the following methods.
Method 1. A method for implementing an anonymous Mail Order Telephone Order (“MOTO”) credit card transaction between a user and a merchant, comprising the steps of:
establishing a user account between a credit source and the user which is associated with a fictitious account name, a user account number, a user key and a user settlement mechanism through which the user can pay the credit source for charges and fees billed to the user account;
providing the user with an electronic card that is comprised of:
a card base;
a storage medium affixed to the card that can be read by a card reader but is not readable by a human eye;
a computer affixed to the card;
an input mechanism for providing input to the computer;
a display controlled by the computer; and
a power source for supplying power to the computer;
wherein the electronic card has a fictitious account name stored in a memory device accessible by the computer, the computer is capable of causing data to be stored in the storage medium and the electronic card is sized such that a standard magnetic stripe reader can read the magnetic storage medium;
completing a MOTO credit card transaction between the user and the merchant in which the user is charged a monetary value by the merchant, comprising the following steps:
entering the user key into the input mechanism;
executing an algorithm by the computer that uses the user key and a card number stored in the electronic card as input variables to generate a valid personal charge number;
visually reading the valid personal charge number from the display;
providing the valid personal charge number and the fictitious account name to the merchant;
sending the monetary value, the valid personal charge number and the fictitious account name to a credit approval center that verifies that the valid personal charge number is valid for the fictitious account name and approves the MOTO credit card transaction; and
sending an approval of the transaction from the credit approval center to the merchant.
Method 2. Method 1 wherein the MOTO credit card transaction is conducted between the user and the merchant over a computer network.
Method 3. Method 1 and the further steps of:
establishing a user insertion key that is associated with the user account; and
generating the valid personal charge number from the card number by inserting the user key into the card number through use of the user insertion key and a permutation variable.
Method 4. Method 3 and the further steps of:
changing the permutation variable from an initial state to a different state; and
generating a second valid personal charge number from the card number by inserting the user key into the card number through use of the user insertion key and the permutation variable in the different state.
One particular method that can be used to generate a one-time payment card number, which is described in U.S. application Ser. No. 09/659,434, will now be discussed.
The present disclosure is adapted for use in many kinds of financial transactions. For example, it can be used in credit card transactions, bank or debit card transactions, or electronic script transactions. Because of the versatility of this embodiment, it can be used in connection with a wide variety of instruments that can be used in connection with such financial transactions. Thus, it can be used with electronic cards, software programs used in network applications, or telephones (especially telephones used in what is now being referred to as m-commerce, or mobile commerce). Moreover, it can be used whether such transactions are conducted in person, face-to-face, or whether such transactions are conducted by an indirect medium, such as a mail order transaction, a transaction conducted over a computer network (for example, the Internet), or a telephone transaction.
As is the case in most financial transactions, three parties are typically involved in completed financial transactions according to the present invention. A party makes a monetary payment. In the context of the following description, this is the first entity or customer. Another party receives the monetary payment, and this party can be a single party or two or more parties. In the context of the following description, the party or parties that are receiving the monetary payment are referred to as the second entity. Finally, there is at least one party, and usually multiple parties, that serve as intermediaries to allow the customer to transfer monetary value to the second entity. The intermediary group of one or more parties will be referred to in the context of the following description as a money source. Thus, the money source may be one or more banks, a credit card company or any other institution involved with issuance of credit cards or bank debit cards, such as a credit union or other institution, or a money source as described in U.S. Pat. No. 5,913,203 which states, in col. 5, lines 6-17: “Initially, there must be a money source. This is described as a pseudo cash repository, but it does not need to be a single entity. In practice, it can be a single bank, or a single credit card company or a number of affiliated banks (a bank group) or a number of affiliated credit card companies (a card group) affiliated with one or more merchants and set up to do business with one or more money source customers or some other entity or entities that will perform such a function. The pseudo cash repository, in concept, is similar to an entity that issues traveler's checks (for a non-anonymous cash-like transaction) or a money order (for a potentially anonymous cash-like transaction).” U.S. Pat. No. 5,913,203 further states, in col. 6, lines 34-41: “The pseudo cash repository maintains a record of the pseudo cash unit and the fixed monetary value associated with the pseudo cash unit and in an especially preferred embodiment, can be either a computer or a network of computers that operates as the money source. If the pseudo cash repository relies upon a network of computers, the network can be dedicated or it can be connected by an encrypted two-way communication linkage.”
In connection with this embodiment, it is not necessary that the first entity use a real identity, although such an option is also acceptable. Instead, a pseudonym, such as a screen name or an alias, could be used to protect the first entity's privacy and provide additional security.
Although the first entity need not use a real identity, the first entity must establish an account with a money source. When the account is established, the first entity and the money source must agree upon a payment mechanism or protocol. In the case of a credit card or a bank card, this could be done in the same fashion as exists today, and the first entity could select a fictitious account name as is explained in greater detail in co-pending U.S. patent application Ser. No. 09/619,859. It is especially preferred that two different users not be allowed to select the same fictitious account name so that a fictitious account name also represents a unique identifier. However, the preferred embodiment could also be used in connection with a prepaid account. In such a scenario, the first entity could simply purchase a prepaid card and no real identity would ever be required.
When the first entity establishes an account with the money source, a user key must be selected. The user key can be a Personal Identification Number, or “PIN,” similar to that which is currently in widespread use in the United States in connection with automated teller machines. Both the first entity and the money source must have access to the user key, which can be selected by either entity. In order to be able to retrieve this user key, the money source must create a record associated with the first entity that includes the user key and a first entity identifier (whether this be the real name of the first entity or a fictitious account name).
Once the first entity has established an account with the money source and a user key has been selected, the first entity must be supplied with the means to generate a customer one-time unique purchase order number (“Coupon”). As already described, this could be hardware or software, but, in either case, it will include a customer random number generator and a customer permutation variable that is correlated with a customer sequence number.
There is some debate, within the mathematical and cryptographic communities, as to what constitutes a “random number generator.” At times, the term is used somewhat loosely, and sometimes it is used to refer to what is also commonly referred to as a “pseudo random number generator. In the context of the present invention, a “random number generator” shall be defined to include a pseudo-random number generator. The details of how a random number generator (or a pseudo-random number generator) works, and how they can be used to generate a series of random (or pseudo-random) numbers, are well known in the art of cryptography and will not be repeated here. (A general description of random number generators and various pseudo-random number generators, and a discussion of common implementation mistakes that are made when using pseudo-random generators, is set forth in ICSA Guide to Cryptography (McGraw-Hill 1999), by Randall K Nichols, at pages 356, 399-406, and 702, the disclosure of which is specifically incorporated herein by reference.)
A person skilled in the art could choose one of many different “random number generators” known in the art for use in connection with the present invention, and any number of such devices will suffice, although it is probably most desirable, from a security standpoint, to use a cryptographic pseudo-random number generator. In an especially preferred embodiment, the “random number generator” is what has been referred to by H. D. Knoble as a “Portable Quasi-Random Number Generator.” More specifically, it is especially preferred that the random number generator be an additive three part prime modulus multiplicative linear congruent random number generator which can be generated by the following algorithm:
RN=INT((R−(INT(R)))×10)
where RN is the random number, INT stands for an Integer function, and R is calculated as follows:
R=(SA/K4)+(SB/K8)+(SC/K12), where
SA=K1×MOD(SA,K2)−K3×(SA/K2), but if SA is less than zero, SA=SA+K4,
SB=K5×MOD(SB,K6)−K7×(SB/K6), but if SB is less than zero, SB=SB+K8,
SC=K9×MOD(SC,K10)−K11×(SC/K10), but if SC is less than zero, SC=SC+K12,
where SA, SB and SC are seed values, all K numbers are constants, and MOD is a Modulo function. The above-identified algorithm uses three additive parts, but an algorithm with additional (or, less preferably, fewer) additive parts could also be used. Additional details concerning Modulo and Integer functions can be obtained from VS FORTRAN Application Programming: Language Reference, Release 2.0, IBM (3rd Ed., September 1982), pages 215 and 216, the disclosure of which is specifically incorporated herein by reference.
The customer random generator is used to generate a sequence of numbers with qualities similar to that of a sequence of truly random numbers. By using a pseudo-random number generator, the sequence will be fixed for a given algorithm, using a given set of constants, starting from a given seed value. A number in such a sequence can be referenced by its position relative to an initial setting, and this shall be referred to as a sequence number. Thus, a string of one hundred numbers generated by a random number generator can be assigned sequence numbers of 1-100, respectively, which means that the fiftieth number in the string would be assigned the sequence number of 50.
Because the money source must also use a random number generator, the customer random number generator and the money random number generator must be synchronized so that they will achieve identical results when the customer sequence number and the money source sequence number are identical. If a money source wants a number of different customers to use the same random number generator but generate different sequences of numbers, such results can be obtained several ways. For example, different customers might have different initial seed values, different customers might have one or more different constants, different customers might have a different permutation variable as an initial setting, or two or more of these options might be employed.
When the first entity wishes to generate a Coupon, the first entity enters the user key into the hardware or software used to generate the Coupon. Once the user key is entered, it is combined with a customer permutation variable that is correlated with a customer sequence number to form a customer permutated user key. The combination can be done by any number of mathematical functions (simple examples of which are addition, subtraction, division and multiplication) or by any suitable algorithm or set of rules. The customer permutation variable and the customer sequence number can be correlated in many different ways, the simplest example of which is that they are identical. Another example of a simple correlation would be to vary the permutation variable according to a preselected algorithm in accordance with the customer sequence number, or through use of the customer sequence number as an input into the algorithm.
The customer permutated user key and the user insertion key are used as input variables in an algorithm to form a Coupon. In an especially preferred embodiment, the customer permutated user key is inserted into a user account number. Simple methods of insertion include addition and substitution, or a combination of the two. After a Coupon is generated, the customer sequence number is changed, and a new entry of the user key will result in generation of a new customer permutated user key and a new Coupon. Because generation of the Coupon can be done by a computer (whether it be a “traditional” computer or some other device that can be a host computer or a client computer, such as a chip located in an electronic card or telephone), for all practical purposes, the Coupon can be generated as soon as the user key is entered into the computer.
Once a Coupon is generated, it can be transferred to a second entity, along with a first identity identifier, to pay for goods or services and, in turn, the Coupon and the first identity identifier can be transferred to the money center.
When a customer's user key is entered into an input device, there is always a possibility of mistake due to human error. Accordingly, it is highly desirable to provide a mechanism to account for such mistakes. However, the mechanism should be controlled to avoid the possibility of an unacceptable compromise to security, as could be the case if unlimited errors in entry of the customer's user key are allowed. The preferred embodiment provides a mechanism to satisfy both desires by the method a Coupon is validated and by allowing the customer random number generator and the money source random number generator to be resynchronized from a first setting to a second setting.
A Coupon is validated when the money source determines that the Coupon is valid for the first entity identifier submitted with the Coupon. In order to determine what Coupons might be valid for the first entity, the money source determines what Coupons the first entity will generate, and the order in which they will be generated. One way that the money source can determine what Coupons will be generated by the first entity is to generate coupons from the same starting input that would be used by the first entity, using the same random number generator. In other words, the money source uses a money source random generator that uses the same algorithm as the customer random generator (including initial seed(s) and constants), using the same user key. Thus, when the money source generates a money source Coupon from a money source sequence number that is identical to a customer sequence number used by a customer to generate a Coupon, the money source Coupon should be identical to, and thus match, the Coupon. This, in turn, validates the Coupon.
Validation of a Coupon is very simple to implement when the customer sequence number and the money source setting are synchronized. The money source Coupon could be generated at the time the Coupon is submitted for validation, or it could already be generated, and stored, in a look-up table. However, there are reasons why such synchronization may not exist. For example, a customer might generate a Coupon but, for whatever reason, not use it. Alternatively, a consumer might make a mistake and not enter the correct user key, and thus generate an invalid Coupon. (Although the latter possibility could be avoided by storing the user key in the hardware/software and confirming that the user key entered is correct, such storage is undesirable since the existence of such a record compromises security).
In order to account for the possibility that the customer sequence number and the money source setting may not be synchronized, validation can be permitted if the Coupon matches any one of a preselected number of money source Coupons generated in series by the money source from an expected starting value of the customer sequence number. (Selection of the preselected number is a matter of design choice that involves a tradeoff between usability and security, and the number might be changed at different times or for different conditions.) Although such series could be generated at the time of submission of a Coupon for validation, it is especially preferred that the series be generated and stored as a sequential set that can be queried upon submission of a Coupon for validation. Using this methodology, once a Coupon is validated, the matching money source Coupon and all earlier created money source Coupons can be deleted from the sequential set. Then, since the sequential set now contains less than the preselected number of Coupons, one or more additional money source Coupons are generated to bring the population of money source Coupons back up to the preselected number (or a newly selected number).
The use of a sequential set of money source Coupons works well as long as Coupons are submitted for verification in correct sequential order. Normally, this should not be a problem. However, there may be instances where this could present a problem, such as use of a Coupon to pay for something ordered by mail. In order to account for such a possibility, the money source can store money source Coupons deleted from the sequential set in a recent history file, and this file can be maintained for a preselected length of time. Using this methodology, if a match with a money source Coupon stored in the sequential set does not validate a Coupon, a match with a money source Coupon stored in the recent history file can still validate it. However, the money source might also want to implement additional security measures when validating a Coupon by comparison with the recent history file. Thus, in the given example of a mail order, the money source might also require that the shipping address match an approved shipping address for the first entity. Alternatively, the money source might also require independent confirmation of the validity of the Coupon by contacting the first entity, e.g. by telephone or e-mail, if the value of the Coupon exceeds a threshold limit.
If a Coupon is not validated, the money source will reject it as invalid. The Coupon might be invalid due to error by the first entity, or due to error somewhere during its path of transmission to the money source, or due to fraudulent activity, Accordingly, it is highly desirable not to place a hold on activity by a customer whose first entity identifier has been used with an invalid Coupon until such activity exceeds a threshold level. Once this threshold level has been exceeded because a preselected number of invalid Coupons are not verified for the first entity, an invalid user account number condition can be triggered to prevent any further processing of Coupons submitted with the first entity identifier until the invalid user account number condition is removed.
If a first entity has submitted too many invalid Coupons, or has just gotten too far out of synchronization from the money source (e.g., a child playing with an electronic card), it may be desirable to resynchronize the customer random number generator with the bank random number generator. One easy way to do this is as follows. The first entity could contact the money source, enter the first entity's user key, and provide the money source with the resultant Coupon. The money source could then use this Coupon to determine what customer sequence number was used to generate the Coupon, and reset its records accordingly, as is illustrated in the following example:
Assume that the sequential set maintained by the money source contains 10 money source Coupons, that the first entity has previously successfully submitted Coupons for transactions 1-5, and that the first entity's customer sequence number is now 25. When the first entity contacts the money source, the Coupon that it will generate will be the 25th Coupon in a string, but the sequential set maintained by the money source will only contain the 6th through 15th Coupons. Therefore, the money source will not generate a match until its 25th money source Coupon is generated, at which point the customer random number generator and the money source random number generator will be resynchronized. Next, the money source will generate money source Coupons 26 through 35 and place them in its sequential set of money source Coupons for the first entity, and an invalid user account number condition, if set, can be removed.
Another way that the customer random number generator and the money source random number generator can be resynchronized is for the money source to provide the first entity with a new seed value to be input into the random number generator, but this would require some mechanism to allow such input. In the case of an electronic card, telephone or other hardware device, a special function key, followed by the input, might perform this.
Although the foregoing discussion of the preferred embodiment has focused on use of a single Coupon, additional security could be obtained by requiring use of two or more Coupons for a given transaction, especially if it exceeds a preselected threshold value or if a requirement for additional security is triggered. If two Coupons are required to process a given transaction, it is far less likely that a random guess or person without access to the valid user key and requisite algorithm could generate a correct sequence of Coupons. This fact can also be used to prove fraudulent or unauthorized use, or to check for such use. For example, suppose a first entity submits a Coupon for validation in connection with a certain transaction, and its validity is called into question. The first entity could be prompted to provide one or more additional valid Coupons, and if this could not be done, it would be a good indication of potential fraud.
In certain types of transactions, such as transactions over the Internet, there is some possibility that a first entity identifier could be intercepted and somebody might make fraudulent attempts to guess a valid Coupon for an intercepted first entity identifier without actual possession of authorized hardware or software that might be used to generate a valid Coupon. Once again, by requiring use of two or more valid Coupons, the potential for fraud could be reduced. Alternatively, the first entity could be asked to generate a Coupon using an incorrect user key. In this scenario, if the first entity does not actually have possession of the hardware or software to generate a Coupon, it would not be possible for the first entity to generate the Coupon that could be generated by the money source through use of the incorrect user key, the money source permutation variable and the money source sequence number.
Fraudulent activity might also be detected by the nature of invalid Coupons submitted for verification. When the money source receives a Coupon for verification, it is possible to work backwards from the Coupon to determine what user key and permutation variable were used to generate the Coupon for a given sequence number. Based upon what user keys were used in generating invalid Coupons, it might be possible to spot potential fraudulent activity. It is also possible to detect or deter fraudulent activity, and increase security, if the user key is periodically changed. This can be done when the first entity and the money source validly agree to change the user key, and the money source's records are changed accordingly (including the money source Coupons contained within the sequential set).
Although the foregoing detailed description is illustrative of preferred embodiments of the present invention, it is to be understood that additional embodiments thereof will be obvious to those skilled in the art. For example, the same inventive concepts disclosed herein could be used in a system in which a customer has two or more account numbers and/or identities, with the same or different user keys. In the case of an electronic card or telephone, this would allow the customer to select which account should be used (for example, to choose a business credit card for use with a business expense, a personal credit card for use with a personal expense, or a bank card at a local store for groceries and cash back). Alternatively, a customer might be permitted to use multiple user keys for the same account number and the same identity. This could allow some of the same functionality, or it could be used to classify the type or nature of the expense or transaction. Further modifications are also possible in alternative embodiments without departing from the inventive concept.
Accordingly, this disclosure includes the following methods. Method 1. A method for providing multiple secure transactions between a first entity and at least one additional entity, comprising the steps of
(1) generating a customer one-time unique purchase order number (“Coupon”) for the first entity by the following steps:
(a) combining a user key with a customer permutation variable that is correlated with a customer sequence number to form a customer permutated user key;
(b) using a customer random number generator to generate a customer user insertion key that is correlated with the customer sequence number; and
(c) generating a Coupon from a user account number by inserting the permutated user key into the user account number in accordance with an algorithm that uses the customer user insertion key;
(2) transferring the Coupon and a first entity identifier to a second entity;
(3) transferring the Coupon and the first entity identifier from the second entity to a money source repository;
(4) creating a sequential set of the money source repository having a preselected number of money source Coupons for the first entity by the following steps:
(a) combining the user key with a money source permutation variable that is correlated with a money source sequence number to form a money source permutated user key;
(b) using a money source random number generator to generate a money source user insertion key that is correlated with the money source sequence number;
(c) generating a money source Coupon from the user account number by inserting the money source permutated user key into the user account number in accordance with the algorithm that uses the money source user insertion key, wherein the money source Coupon is correlated with the money source sequence number and stored in the sequential set, said money source Coupon being identical to the Coupon when the customer permutation variable and the money source permutation variable are identical;
(d) changing the money source sequence number; and
(e) repeating steps (a) through (d) as needed so that the sequential set has the preselected number of money source Coupons;
(5) verifying that the Coupon is valid for the first entity by confirming that it is identical to a matching money source Coupon contained within the sequential set;
(6) deleting the matching money source Coupon and all earlier created money source Coupons from the sequential set;
(7) changing the customer sequence number; and
(8) repeating steps (2) through (7).
Method 2. A method as recited in method 1, wherein the second entity is comprised of a plurality of different entities.
Method 3. A method as recited in method 1, wherein the customer random number generator and the money source random number generator are resynchronized from a first setting to a second setting.
Method 4. A method as recited in method 1, wherein the customer sequence number is changed every time a Coupon is generated.
Method 5. A method as recited in method 1, wherein the user key is entered into an input device whose output is used to generate the Coupon.
Method 6. A method as recited in method 5, wherein the customer sequence number is changed every time the user key is entered into the input device.
Method 7. A method as recited in method 1, comprising the following additional steps:
setting an invalid user account number condition if a preselected number of Coupons are not verified for the first entity; and
terminating step (5) when the invalid user account number condition is set.
The disclosure of U.S. Ser. No. 10/968,401 provides an unprecedented opportunity to customize use and processing of payment card transactions through use of one or more customization variables.
In the context of this description, a one-time payment card number refers to a payment card number of either a credit or a debit card, generated in accordance with the present invention, that is useful in financial transactions in the same fashion as a traditional payment card number.
Like a traditional payment card number, a one-time payment card number should be capable of being read by a standard magnetic stripe reader when it is part of a physical card used in traditional face-to-face transactions in which a user presents the physical card to a merchant for payment. However, like traditional payment card numbers, a one-time payment card number should also be capable of being used in a Mail Order Telephone Order (“MOTO”) credit card transaction between the user and a merchant. Thus, like a traditional payment card number, the one-time payment card number should fit within, and work with, present platforms and protocols for financial transactions involving payment cards, such as traditional credit cards. This versatility allows the one-time payment card number to be used with electronic cards, software programs used in network applications, or telephones (especially telephones used in what is now being referred to as m-commerce, or mobile commerce).
A traditional payment card number can be characterized as having three parts. First, there is a set of fixed variables. This contains numerals that represent certain specified data fields, such as a bank identifier and a month and year expiration date for a given payment card. (The “bank” may be any “money source” as that term has been defined in U.S. Pat. No. 5,937,394.) Second, there is a set of variable variables. This contains numerals that will vary for different payment cards issued by the same money source. In other words, this is the portion of the card number that will be specific to an individual entity or account for a given issuing money source. Third, there is a check sum digit. The value of the check sum digit is dictated by the other numerals in the card number.
In the context of the present invention, a user one-time payment card number is akin to a traditional payment card number, with certain exceptions. In a traditional payment card number, there might be a set of six fixed variables, followed by a set of nine variable variables, followed by a check sum digit and another set of four fixed variables representing the month and year. When a user uses this traditional payment card number to complete a given financial transaction, the transaction is always completed by using the same twenty digits for the payment card number. By contrast, if the user uses a one-time payment card number to complete any such given financial transaction, the transaction will not be completed by always using the same twenty digits for the payment card number. Instead, the twenty digits of the one-time payment card number will vary, and the degree to which they vary may depend upon user selection of a customization parameter. In addition, because the one-time payment card number varies with successive usage, the check sum digit will not necessarily be the same with successive usage, although it may be. Thus, the check sum digit must be recalculated for each new one-time payment card number, and this is why it shall be referred to as a “check sum variable” in the context of a one-time payment card number according to the present invention.
Another difference between a traditional payment card number and a one-time payment card number is the way that a given transaction using either number is validated by a verification agency, which may be a money source or an entity who processes payment card transactions. When a transaction involving a one-time payment card number is processed, the verification agency must verify that the one-time payment card number is valid for the user identifier for the particular given transaction, as opposed to any given transaction involving the user identifier. (The verification process must take into account how selection of the customization parameter may affect what the verification agency will receive for verification. Additional details regarding procedures that can be used to verify a one-time card number that can be customized are set forth in U.S. Pat. No. 6,609,654.) This difference is a reason why use of the one-time payment card number provides greater security and anonymity than can be obtained through use of a traditional payment card.
A card number generator generates a one-time payment card number. As already described, this could be hardware or software, but, in either case, it will preferably include a customer random number generator and a customer sequence number. It is especially preferred that the card number generator be part of an electronic card, and that the electronic card be of the type described in U.S. application Ser. No. 09/571,707 filed May 15, 2000 for Anonymous Electronic Card for Generating Personal Coupons Useful in Commercial and Security Transactions, or in U.S. application Ser. No. 09/667,835.
Several different methods can be used to generate a one-time payment card. No matter what method is used to generate a one-time payment card number, two successive one-time payment card numbers should be different. This can be accomplished by using a sequence number that is changed after each one-time payment card number is generated. (The present invention does not require that all theoretical possibilities will result in different one-time payment card numbers. Instead, it is preferred that there be a low probability of occurrence of identical one-time payment card numbers attributable to convergence of two different inputs leading to the same result due to operations performed on the inputs by the algorithm.)
The preferred embodiments allow a user to customize use of an electronic card having a card number that varies with each use by selecting at least one customization parameter to customize a given use of the electronic card. There are three general customization parameters that can be used to customize a given use.
First, the user can customize generation of the one-time card number. This can be done many different ways. An example of one way in which it can be done is to customize selection of a selected user key that is used to generate the one-time card number as is explained in U.S. Pat. No. 6,609,654. Another way in which it can be done is to include a customization variable in the one-time card number, or as an input into the algorithm used to generate the one-time card number.
Second, the user can customize the user identifier that is used to validate the one-time card number. This can be done many different ways. One way is to choose one of two or more preselected identifiers as a selected user identifier. Another way is to modify the user identifier. Still another way is to add a customization variable, such as a numeric character, to the user identifier at a preselected location.
Third, the user can include a customization variable with information transmitted to a verification agency for validation of the given use. Unlike the first two customization parameters, this parameter relies upon use of an additional field of data collected as part of the validation process for a given transaction, and this may require a change in established validation protocols. It is especially preferred that any such change be technically feasible within the confines of hardware that is being used to process traditional payment card transactions. In the context of an electronic card with a magnetic stripe, this means that it is preferred that the additional customization variable be stored in the magnetic stripe, and it is especially preferred that it be stored in the second track of the magnetic stripe. Additional details regarding inclusion of a customization variable in a magnetic stripe are set forth in U.S. Ser. No. 09/667,089.
Once it is recognized that using one or more of the foregoing customization parameters will customize a given transaction involving use of a one-time payment card number, and that such customization will seamlessly allow a user to transmit additional information to the money source processing such transaction, without loss of desired security or anonymity, the options for using such customization are virtually limitless.
After a one-time payment card number is validated for a given transaction, the money source can determine what customization parameter(s) was selected by the user for the given transaction, which allows the money source to determine what handling option should be used for the transaction involving the one-time payment card number. (It also allows the money source to determine what sequence number is associated with the one-time payment card number, so that its records can be synchronized as part of the validation process.)
One use of multiple handling options is to allow the money source to access multiple accounts. For example, a user might use one account as a credit card, and another account as a debit or checking card. By choosing which account should be used for a given transaction, the user could determine, at the point of use, whether to charge the transaction, or have it deducted from an existing account balance. The same idea could be used for multiple credit cards, whether they are from the same issuer or different issuers, or even different cards, such as Visa®, MasterCard? Diner's Card®, Discover® or American Express®. In addition, the user might elect to have separate billing statements for separate accounts, or have all billing consolidated in a single statement.
Another use of multiple handling options is to allow identification of the person completing a transaction, or to allow multiple persons access to a single account, or place different restrictions on multiple persons on a single account, For example, a single account might be opened with an issuing bank, but an entire family might be authorized to use the account. Thus, a father and a mother might have their own customization parameter, a teenage child might have another customization parameter and a lower authorized spending limit, and a preteen child might have a fourth customization parameter, but only be authorized to engage in a certain limited number of transactions per time period with a maximum spending limit for each transaction. All the members of this family could use the same card number generator embedded within a PDA or mobile phone, or on a computer or in an electronic card. At the end of a specified billing cycle, all transactions completed by any member of this family could be consolidated in a single bill, and that bill could indicate who spent what when during the billing cycle, and what it was spent on.
Still another use of multiple handling options is to allow a user to classify the nature of a particular transaction at the time it is completed. For example, suppose an individual uses a single credit card for personal expenditures and business expenditures. By assigning one customization parameter to personal transactions, and a second customization parameter to business transactions, the user can simplify accounting for such transactions without the necessity of having and carrying two separate cards. If desired, the user could even receive two separate statements for such expenditures so that the personal expenditures would not be discernable from the documentation associated with the business expenditures. Individual transactions could also be classified according to a preselected set of criteria, and such criteria could be used in various financial programs. For example, a user might include a code classification system used in a money management system to create various reports that itemize categories of spending or assist in budgeting of finances.
Yet another use of multiple handling options is to allow a user to preselect how a particular transaction is treated in a subsequent bill. For example, an individual user might not want a billing statement to include information about the identity of second entities who provide certain goods or services, or when transactions with such entities take place, but still want to have the billing statement include such information for other transactions. By selecting two different customization parameters with these two different handling options, the user has the option of controlling what information it receives in billing statements about individual transactions.
Multiple handling options can also be used to guard privacy, or for commercial purposes that do not presently exist. For example, the user and the money source might enter into an agreement about how, and under what circumstances, the money source can distribute information about transactions of the user, depending upon which customization parameter is used in a given transaction. The agreement might provide different levels of confidentiality, and set up different levels or types of compensation tied to transactions falling within the different levels for a given time period.
One level of confidentiality might restrict distribution of any information concerning a transaction by the money source to any third party. For example, a user might want strict confidentiality of any transaction involving medical services, and would not want the money source to divulge that information to any party unless legally required to do so. Or, maybe the user does not want any third party to learn of any transaction that exceeds a certain dollar amount, for fear of a potential deluge of unsolicited advertising. A user might pay a monthly fee for use of this option, a transaction based fee, or no fee at all.
A second level of confidentiality might permit distribution of any information concerning a transaction by the money source to any third party. Such information is potentially valuable for purposes of advertising, and creating profiles for targeted marketing, and the money source might even pay the user for the right to sell such information.
Other levels of confidentiality might fall between those already noted. For example, a third level might permit distribution of certain information concerning a transaction (such as the payee, the amount of purchase, the date of purchase, and a profile of the user), but restrict distribution of other information concerning a transaction (such as the identity of the user). Another level of confidentiality might restrict distribution of information concerning a transaction to any third party, but allow the money source to use such information for its own marketing efforts directed to the user.
The teachings of U.S. Ser. No. 09/960,714, which has issued as U.S. Pat. No. 6,805,288, will now be discussed. This disclosure seeks to provide new methods for generating and processing Secure Card Numbers (SCN) that can be used in all types of transactions in which a conventional credit card account number is accepted. In addition, this disclosure conforms to the existing standards for PIN encryption as promulgated by the American Bankers Association (ABA), the American National Standards Institute (ANSI), the International Standards Organization (ISO), and the Federal Information Processing Standards (FIPS) Publications of the National Institute of Standards and Technology (NIST). Because the methodology is well suited for use in hardware and software applications, it has widespread applicability to many different types of transactions.
The present disclosure is related to the concept of customer one-time unique purchase order numbers (“Coupons”) as described in U.S. Ser. No. 09/640,044. An algorithm is executed that uses a user account number, a customer sequence number, a customer permutated user key, and a Transaction Information Block (TIB) as input variables to form an SCN that is correlated with a sequence number. Combining a user key with a user account number, a user insertion key correlated with the customer sequence number, and then encrypting the result using the Triple Data Encryption Standards (TDES), forms the customer permutated user key. A random number generator generates the user insertion key that is correlated with the sequence number. The TIB may provide several pieces of information, including the conditions under which the SCN will be valid (i.e., the SCN type), additional account identification information, and the status of the device used for SCN generation. The sequence number can be changed after each SCN is generated and a new SCN can then be generated using a new user insertion variable correlated to the changed sequence number.
After an SCN is generated, it is transferred with a first entity identifier to a second entity (which can actually be several entities), which then transfers the information to a money source. An individual SCN is verified as being valid by the money source by duplicating the generation of the customer permutated user key for the specified first entity and the specified sequence number, and then comparing it to the customer permutated user key which is embedded in the provided SCN. Additionally, the money source verifies that the specified SCN type is valid given the specific conditions of the transaction. Once verified as valid, each SCN passes through a life cycle in accordance with conventional credit card processing practices and with its SCN type, in which it may be used for various types of transactions before being retired. If a preselected number of SCNs are received by the money source and determined to be invalid (either consecutively or within a predetermined timeframe), then an invalid user account number condition is set to prevent further attempts to verify SCNs for that first entity.
A user key can be entered into an input device which validates the user key by comparing it to a stored user key. If the entered user key is valid, the user can generate an SCN. The sequence number changes each time a user key is entered into the input device.
A preferred embodiment of this disclosure is adapted for use in credit card transactions, and as such can be used in connection with a wide variety of instruments that can be used in connection with such financial transactions: electronic cards, software programs used in network applications, telephones (especially telephones used in what is now being referred to as m-commerce, or mobile commerce), or even physical imprint transactions. Moreover, it can be used whether such transactions are conducted in person, face-to-face, or whether such transactions are conducted by an indirect medium, such as a mail order transaction, a transaction conducted over a computer network (for example, the Internet), or a telephone transaction.
As is the case in most financial transactions, three parties are typically involved in completed credit card transactions according to the present invention. A party presents a credit card account number with the intent to initiate a monetary payment (or credit/return). In the context of the following description, this is the first entity or customer. Another party receives the credit card account number with the intent to receive a monetary payment (or credit/return), and this party can be a single party or two or more parties. In the context of the following description, the party or parties that are receiving the credit card account number are referred to as the second entity or merchant Finally, there is at least one party, and usually multiple parties, that serve as intermediaries to the monetary payment (or credit/return). The second entity provides the credit card account number to this party over several transactions to effect the monetary payment (or credit/return): authorization, incremental authorization, authorization reversal, settlement, and credit/return. The intermediary group of one or more parties will be referred to in the context of the following description as a money source. Thus, the money source may be one or more banks, a credit card company or any other institution involved with issuance of credit cards or bank debit cards, such as a credit union or other institution, or a money source as described in U.S. Pat. No. 5,913,203.
In connection with this embodiment, it is not necessary that the first entity use a real identity, although such an option is also acceptable. Instead, a pseudonym, such as a screen name or an alias, could be used to protect the first entity's privacy and provide additional security.
Although the first entity need not use a real identity, the first entity must establish an account with a money source. When the account is established, the first entity and the money source must agree upon a payment mechanism or protocol. In the case of a credit card or a bank card, this could be done in the same fashion as exists today, and the first entity could select a fictitious account name as is explained in greater detail in co-pending U.S. patent application Ser. No. 09/619,859. It is especially preferred that two different users not be allowed to select the same fictitious account name so that a fictitious account name also represents a unique identifier. However, the preferred embodiment could also be used in connection with a prepaid account. In such a scenario, the first entity could simply purchase a prepaid card and no real identity would ever be required.
When the first entity establishes an account with the money source, a user key must be selected. The user key can be a PIN, similar to that which is currently in widespread use in the United States in connection with automated teller machines. Both the first entity and the money source must have access to the user key, which can be selected by either entity. In order to be able to retrieve this user key, the money source must create a record associated with the first entity that includes the user key and a first entity identifier (whether this be the real name of the first entity or a fictitious account name).
Once the first entity has established an account with the money source and a user key has been selected, the first entity must be supplied with the means to generate a customer SCN. As already described, this could be hardware or software, but in either case it will include a user account number, a customer random number generator that will be used to generate user insertion keys that are correlated with a customer sequence number, and TDES encryption keys.
The TDES encryption standard is the accepted standard for protecting a PIN during data transmission of financial transactions, as described by ISO 9564-1-1991 (Banking—Personal Identification Number Management and Security—PIN Protection Principles and Techniques, Section 6.2), ISO 9564-2-1991 (Banking—Personal Identification Number Management and Security—Approved Algorithms for PIN Encipherment), ANSI X9.52-1998 (Triple Data Encryption Algorithm—Modes of Operation), and FIPS PUB 46-3 (Data Encryption Standard (DES), dated 1999), the disclosures of which are specifically incorporated herein by reference.
In order to effectively use TDES for PIN encryption, the PIN must be combined with a new set of randomly generated data for each transaction. Otherwise, the encrypted PIN would always be the same value. A customer random number generator, such as the one that is described in U.S. patent application Ser. No. 09/640,044, filed Aug. 15, 2000 and which is generally known as a Linear Congruential Generator (LCG), is used for this purpose. This random number generator is algorithmic (i.e., pseudo-random)—when starting with the same set of seeds, it always produces the same sequence of numbers. It can therefore be reproduced by the money source in order to validate a given SCN. Furthermore, since this pseudo random number generator generates its values in a reproducible sequence, each of the values in the sequence can be identified by a Counter value that indicates that number's location in the sequence. The set of random numbers generated and combined with the PIN are collectively referred to as the Sequence Insertion Number (SIN).
In the real world of credit card transactions, it is not possible to assume that transactions conducted by the first entity in a given order will always be received by the money source in that same order. Therefore, the money source method of SCN validation must be based on an embedded sequence value. The Counter value is used for this purpose in the preferred embodiment.
In general, this method can be used to generate SCNs of many different lengths. In the conventional credit card processing infrastructure, a credit card number is typically 16 digits in length. Such a number comprises three sub-numbers: a 6 digit Bank Identification Number (BIN), a 9-digit account number, and a 1-digit checksum number. For the purpose of being compatible with the existing credit card processing infrastructure, the SCN could be 9 digits in length, and could take the place of the account number in the conventional 16-digit credit card number.
In a preferred embodiment, the 9-digit SCN itself comprises three sub-numbers: a 1 digit TIB, a 4 digit Counter Block (which identifies the random number being used for encryption), and a 4 digit encrypted PIN Block.
The 1 digit TIB may take on up to 10 different values, each of which may indicate multiple pieces of information. The TIB can be used to determine which of a plurality of account numbers associated with the first entity should be used for the first transaction. The account numbers can represent, for example, different credit card accounts or different payment or credit cards. A first account number might be associated with the TIB value of 0, a second account number might be associated with the values of 1 and 2, a third account number might be associated with values of 3 and 4, and so forth, wherein any odd value may be restricted to a one transaction limitation while any even value may be used to invoke permission for multiple transactions at a single merchant. In the preferred embodiment, a TIB value of 0 indicates that the SCN may only be used for one transaction; any attempts to use it for subsequent transactions will result in a transaction denial from the money source. A value of 1 indicates the same transaction restrictions as 0, but also indicates that the device generating the SCN has a low battery power condition. A low battery power condition can be detected by a diagnostic program or it can be extrapolated from an empirical record (or counter) of the number of transactions presented for authorization. The transaction counter used to extrapolate a low batter power condition can be collected from the firmware used to generate SCNs or from software behind the money source firewall. A value of 2 indicates that the SCN may be used for multiple transactions, but only at a single merchant; any attempts to use it for subsequent transactions at a different merchant will result in a transaction denial from the money source. A value of 3 indicates the same transaction restrictions as 1, but also indicates that the device generating the SCN has a low battery power condition. Furthermore, a set of TIB values (4, 5, 6, 7) might represent the same restriction and status information as (0, 1, 2, 3), respectively, but further indicate that the transaction is associated with a different subentity (e.g., the first entity identifier identifies a married couple, and the TIB identifies each individual spouse.) Other values might also be used to enforce additional transaction restrictions in ways readily apparent to those skilled in the art.
The TIB can also be used by the money source to uniquely identify a physical device (such as an electronic card) used to generate the SCN. This aspect of the TIB is especially useful when the money source issues more than one card to a first entity. Multiple cards might be issued to the same person (i.e., the first entity) for different uses, or multiple cards might be issued to the same person for use by different individuals (such as family members). In such instances, the TIB can identify which physical card, issued to the first entity, is used for a given transaction. When the TIB is used in this way, the TIB can be used as a customization variable to recognize multiple cards otherwise issued to a single first entity (which might also be a legal entity, such as a corporation).
The 4-digit Counter Block is unencrypted information provided so that the money source may decrypt and validate the SCN. It may be simply the actual Counter value (incremented after each use), but in the preferred embodiment, it is created by adding the Counter value to a starting value known to both the first entity and to the money source.
The 4-digit PIN Block is the encrypted information that is used to validate the fact that the SCN originated from the first entity. The PIN Block is formed using the PIN, the SIN, and a starting value known to both the first entity and to the money source. It is encrypted using TDES, which requires use of three 64-bit keys known to both the first entity and to the money source. In order to encrypt such a small number (16 bits) with such a high level of encryption (158 bits), the PIN must first be expanded to a 64 bit number, then encrypted, and finally reduced back to a 16 bit number—and in such a way that it is guaranteed to be different for each transaction.
The SIN is the product of an LCG random number generator that is initialized with three 2-byte integer seeds—the result of operating the LCG on these seeds is a 2-byte random value. The 8-byte SIN consists of the three seeds plus the random value. As a by-product of its operation, the LCG also produces three new seeds, which will be used for the next iteration of the LCG algorithm. The SIN may therefore be associated with a Counter value that indicates a unique location in the sequence of seeds and value generated by the LCG. This SIN is used as the random basis for each successively TDES-encrypted PIN Block, and guarantees a properly encrypted PIN Block for each transaction. To allow proper validation of the SCN, the Counter value stored in the Counter block is the one associated with the SIN used as the random basis for the PIN Block.
The creation of the PIN Block starts by dividing the 8-byte SIN into four 2-byte integers. The PIN and a predefined constant value are both added to each individual 2-byte integer. The results are then concatenated back again to form an 8-byte input block to the TDES algorithm, which encrypts them into an 8-byte output block. The output block is then divided back into four 2-byte integers (x1, x2, x3, x4). These four values are then used in the following formula to produce the 4-digit PIN Block value P:
Formula 1: PRNG Value Calculation
P=(Ax1+Bx2+Cx3+Dx4)mod10000
In this formula, the four values (A,B,C,D) are each odd integers. The “mod” calculation is a standard modulo arithmetic operation, and works as follows: if the resulting number is greater than 10,000 (or 20,000 or 30,000, etc.), then the value of 10,000 (or 20,000 or 30,000, etc.) is subtracted from it, leaving a positive four digit value.
Once created, the SCN is transmitted along with the first entity identifier from the first entity to the second entity and, subsequently, to the money source. In one embodiment, the SCN is used in an account number that replaces the conventional credit card number, and the first entity identifier is a static 9 digit number pre-assigned to the first entity that is transferred to the money source in a non-account data field. In the case of an electronic swipe credit card transaction, the first entity identifier is dynamically encoded onto Track 1 and/or Track 2 of the magnetic stripe in the area known as the Discretionary Data Field, which comprises up to 13 digits of information. In the case of a transaction where the first entity is not present, such as a mail order, telephone order, or Internet order, the first entity identifier is transmitted as part of the Billing Address field in one of many possible forms. For example, it may be entered as “P.O. Box <first-entity-identifier”.
In an especially preferred embodiment, the SCN is not used in an account number to replace the conventional credit card number, but is instead used in conjunction with it—the conventional credit card number itself functions as the first entity identifier, and the SCN is used as a dynamic digital signature to positively identify the first entity and is transferred to the money source in a non-account field of data. In this case, the SCN is transmitted either in the Discretionary Data Field of Track 1 and/or Track 2 or via the Billing Address in a card-not-present transaction.
The Money Source validates the SCN by using the first entity identifier to lookup the information necessary to reproduce the PIN Block encryption for the first entity: the TDES keys, the LCG Seeds, and the PIN. The Money source determines the Counter value by examining the Counter Block, reproduces the calculation of the PIN Block, and then compares the results to the received PIN Block to perform the actual validation.
The Money Source also validates the usage of the SCN based on the embedded TIB. It therefore enforces the various policies based on the first entity's previous transaction history: single-use, multiple-use for single merchant, card-present only.
In the embodiment when the SCN is used in an account number in place of the conventional credit card number, it passes through the standard credit card transaction life-cycle: initial authorization, potential incremental authorization, potential authorization reversal, settlement, and potential credit/return. However, in an especially preferred embodiment, the SCN is only used for initial authorization—beyond that, the Money Source performs its standard transaction processing.
The Money Source may detect fraudulent transaction attempts in various ways. In both the embodiment where the SCN replaces the conventional credit card number, the Money Source may check for re-use of single-use SCNs, use of SCNs without first entity identifiers when the card is not present, re-use of multiple-use/single-merchant SCNs at a different merchant, or SCNs with invalid PIN Blocks. Each of these cases represents a different type of fraud. The Money Source may take various actions in response to each of these types of attacks, such as disabling the account after an excessive number of fraudulent transaction attempts, or returning the code indicating that the merchant should retain the credit card being used for the transaction.
In the preferred embodiment, the Money Source detects fraudulent authorization attempts such as re-use of single-use SCNs, re-use of multiple-use/single-merchant SCNs at a different merchant, SCNs with invalid PIN Blocks, or use of the conventional credit card number on an SCN-enabled account without inclusion of an SCN when the card is not-present. This last case covers simple Internet fraud attempts, but allows, for example, a manual-entry transaction at a POS machine or an imprint transaction. After detecting fraud attempts, the Money Source may take the same types of actions as described above.
It should be noted that the preferred embodiment allows the SCN, when paired with a conventional credit card number, to be validated by back-end software that is integrated with the issuing money source's authorization and settlement processing. An issuing money source can identify an SCN-enabled credit card account in an issuer-determined fashion (e.g., a unique Bank Identification Number). It then forwards select transaction information to the SCN-enabling software, which is installed behind the issuing money source's firewall, which validates the SCN. This means that software generating the SCN can be allowed operate in isolation—it does not have to be in communication with the back-end software—and thus it can be embedded in a credit card or other standalone device.
The inventions described above can be implemented by a money source for use with an electronic card. It is preferable that every user account utilizes the same Pseudo Random Number Generator (PRNG), such as the PRNG described in P. L′Ecuyer, “Efficient and Portable Combined Random Number Generators”, Communications of the ACM, 31(6):742-749,774, 1988, the disclosure of which is specifically incorporated herein by reference. However, each cardholder account has a different initial seed, and thus uses a different part of the PRNG sequence. Since the PRNG has an overall period of 10.sup.12, there is ample room for each account to have its own non-repeating subsequence of 10,000 values.
The PRNG is divided into two parts: seed generation (Formula 2) and value calculation (Formula 3). In these formulas (expressed using C code fragments), the set (S.sub.x.sup.0, S.sub.x.sup.1, S.sub.x.sup.2) is a triplet of five-digit values in the range ([1, 32362], [1, 31726], [1, 31656])), and represents the seed in the x.sup.th location in the sequence. Z is interim storage for the pseudo random number, and PRNG[x] indicates the pseudo random number in the x.sup.th location in the sequence. Note that for the practical usage of this algorithm, “x” corresponds to the current Counter value. For each transaction, Formula 2 generates the seed (based on the previous seed) and Formula 3 generates the PRNG value.
Formula 2: PRNG Value Calculation
Z=Sx0−Sx1;
if (Z>706)Z=Z−32362;
Z=Z+Sx2;
if (Z<1)Z=Z+32362;
PRNG[x]=Z
Formula 3: PRNG Seed Generation
Sx10=(Sx−10*157)mod 32363
Sx20=(Sx−11*146)mod 31727
Sx2=(Sx−12*142)mod 31657
In all cases, the initial PRNG seed (which generates value 0 in the PRNG sequence) is pre-assigned to the card. Additionally, the most recently used seed is stored in Random Access Memory (RAM). Thus, when an SCN must be generated, the card runs through both Formulas 2 and 3 exactly once, and then updates the seed storage in RAM. The Counter value is also stored in RAM, and is initialized to the value of 1 at the time the card is manufactured. Multiple values of the Counter are stored to detect accidental corruption. Each time an SCN is generated, the current value of the Counter is used. The Counter is then incremented by 1, and stored again for the next use.
Since the SCN is calculated in an algorithmic fashion, it is possible to pre-calculate the values for a given first entity, and store them on an electronic card. This embodiment is most useful where it is more advantageous to store a large amount of data on the electronic card than it is to perform the algorithms discussed above.
Use of the SCN technology described herein is secure when it requires the cardholder to enter a PIN in order to generate a unique SCN that is valid for only one transaction, and for only the specified cardholder. At no time during the transaction is the PIN at risk. By utilizing both encryption and random number generation technologies described herein, it is possible to achieve at least a 99.9% level of protection against fraud.
Thus, this disclosure teaches a method for providing one or more secure transactions between a first entity and at least one additional entity, comprising the steps of (1) using an electronic card to generate a Secure Card Number (“SCN”) for the first entity, wherein the SCN is comprised of (a) a Transaction Information Block (“TIB”); (b) a Counter Block; and (c) an encrypted Personal Identification Number (“PIN”) Block; (2) transferring the SCN and a first entity identifier to a second entity in a first transaction; (3) transferring the SCN and the first entity identifier from the second entity to a money source; and (4) verifying that the first transaction is valid with the money source by use of the first entity identifier and the SCN; wherein the TIB can be used for invoking one or more restrictions on use of the SCN; and wherein the TIB is used by the money source to determine whether the device which generated the SCN has changed status condition. The changed status condition can be a low battery condition detected by a diagnostic program or by using an empirical record of the number of transactions presented for authorization and determination of the low battery condition can be made by the electronic card which also keeps the empirical record. Alternatively, determination of the low battery condition is made by the money source which the empirical record. The changed status condition can also be an invalid user input status.
Although the foregoing detailed description is illustrative of preferred embodiments of the present invention, it is to be understood that additional embodiments thereof will be obvious to those skilled in the art. Further modifications are also possible in alternative embodiments without departing from the inventive concept.
Accordingly, it will be readily apparent to those skilled in the art that still further changes and modifications in the actual concepts described herein can readily be made without departing from the spirit and scope of the disclosed inventions as defined by the following claims.
Claims
1. A method for providing one or more secure transactions between a first entity and at least one additional entity comprising:
- (a) receiving a customization parameter from the first entity;
- (b) electronically generating an encrypted transaction validation code which positively identifies a transaction for a first entity, the first entity having a first entity identifier;
- (c) electronically transferring the validation code and the first entity identifier to a second entity in a first transaction;
- (d) electronically transferring the validation code and the first entity identifier from the second entity to a money source;
- (e) electronically verifying that the first transaction is valid with the money source by use of the first entity identifier and the validation code; and
- (f) customizing the first transaction through use of the customization parameter;
- wherein the first entity identifier is transferred to the money source as an account number and the validation code is transferred to the money in a non-account data field.
2. A method, comprising:
- (a) receiving an encrypted transaction validation code which positively identifies a first transaction for a first entity, the first entity having a first entity identifier;
- (b) receiving a customization parameter for the first transaction;
- (c) electronically verifying that the first transaction is valid by use of the first entity identifier and the validation code; and
- (d) customizing the first transaction through use of the customization parameter;
- wherein the first entity identifier is transferred to a money source as an account number and the validation code is transferred to the money source in a non-account data field.
3. The method as recited in claim 2, wherein the validation code is formed by using a Triple Data Encryption Standard algorithm (“TEDS”).
4. The method as recited in claim 2, wherein the customization variable is used to select between a first handling option and a second handling option between the money source and the first entity.
5. The method as recited in claim 4, wherein the first and the second handling options are mechanisms to bill a first account and a second account and the first account and the second account are two separate accounts.
6. The method as recited in claim 5, wherein the first entity is sent a single bill for charges to the first account and the second account.
7. The method as recited in claim 6, wherein the first account is established with a first money source and the second account is established with a second money source and the second money source is different from the first money source.
8. The method as recited in claim 5, wherein the first account is a credit account and the second account is a credit account.
9. The method as recited in claim 5, wherein the first entity is sent a first bill for the first account and a separate bill for the second amount.
10. The method as recited in claim 4, wherein the first and the second handling options are a first and a second mechanism for dealing with distribution of information concerning a plurality of payment card transactions.
11. The method as recited in claim 10, wherein the first mechanism restricts the distribution from the money source to a third party of information relating to any payment card transaction in which the user payment card number is generated by use of a first user key.
12. The method as recited in claim 10, wherein the first mechanism restricts the distribution from the money source to a second entity of personal information of the first entity relating to any payment card transaction in which the user payment card number is generated by use of a first user key.
13. The method as recited in claim 11, wherein the money source receives consideration from the first entity for use of the first mechanism.
14. The method as recited in claim 10, wherein the second mechanism permits the distribution from the money source to a third party of information relating to any payment card transaction in which the user payment card number is generated by use of a second user key.
15. The method as recited in claim 10, wherein the second mechanism permits the distribution from the money source to a second entity of personal information of the first entity relating to any payment card transaction in which the user payment card number is generated by use of a second user key.
16. The method as recited in claim 14, wherein the money source provides the first entity with consideration for use of the second mechanism.
17. The method as recited in claim 4, wherein the first and the second handling options provide a mechanism for classifying the nature of the plurality of payment card transactions.
18. The method as recited in claim 4, wherein the first handling option is used for business transactions and the second handling option is used for personal transactions.
19. The method as recited in claim 4, wherein the first and the second handling options provide a mechanism for identifying either a first user or a second user as the first entity.
20. The method as recited in claim 19, wherein approval of a payment card transaction for the first user is subject to different restrictions than approval of a payment card transaction for the second user.
21. The method as recited in claim 4, wherein the first and the second handling options provide a mechanism for controlling what information is reported about the plurality of payment card transactions in a billing statement.
22. The method as recited in claim 2 wherein the money source obtains the customization variable from the validation code.
23. The method as recited in claim 2 wherein the customization variable is received through use of at least one button.
24. A method for providing one or more secure transactions between a first entity and at least one additional entity comprising:
- (a) receiving an encrypted transaction validation code which positively identifies a first transaction for a first entity, the first entity having a first entity identifier;
- (b) receiving a customization parameter for the first transaction;
- (c) electronically verifying that the first transaction is valid by use of the first entity identifier and the validation code; and
- (d) customizing the first transaction through use of the customization parameter;
- wherein the money source validates the validation code by duplicating the encryption process used to create the validation code and by then comparing the result to the validation code received with the first transaction.
25. The method as recited in claim 24, wherein the customization variable is used to select between a first handling option and a second handling option between the money source and the first entity.
26. The method as recited in claim 25, wherein the first and the second handling options are mechanisms to bill a first account and a second account and the first account and the second account are two separate accounts.
27. The method as recited in claim 26, wherein the first entity is sent a single bill for charges to the first account and the second account.
28. The method as recited in claim 27, wherein the first account is established with a first money source and the second account is established with a second money source and the second money source is different from the first money source.
29. The method as recited in claim 26, wherein the first account is a credit account and the second account is a credit account.
30. The method as recited in claim 26, wherein the first entity is sent a first bill for the first account and a separate bill for the second amount.
31. The method as recited in claim 25, wherein the first and the second handling options are a first and a second mechanism for dealing with distribution of information concerning a plurality of payment card transactions.
32. The method as recited in claim 31, wherein the first mechanism restricts the distribution from the money source to a third party of information relating to any payment card transaction in which the user payment card number is generated by use of a first user key.
33. The method as recited in claim 31, wherein the first mechanism restricts the distribution from the money source to a second entity of personal information of the user relating to any payment card transaction in which the user payment card number is generated by use of a first user key.
34. The method as recited in claim 32, wherein the money source receives consideration from the first entity for use of the first mechanism.
35. The method as recited in claim 31, wherein the second mechanism permits the distribution from the money source to a third party of information relating to any payment card transaction in which the user payment card number is generated by use of a second user key.
36. The method as recited in claim 31, wherein the second mechanism permits the distribution from the money source to a second entity of personal information of the first entity relating to any payment card transaction in which the user payment card number is generated by use of a second user key.
37. The method as recited in claim 35, wherein the money source provides the user with consideration for use of the second mechanism.
38. The method as recited in claim 25, wherein the first and second handling options provide a mechanism for classifying the nature of a plurality of payment card transactions.
39. The method as recited in claim 25, wherein the first handling option is used for business transactions and the second handling option is used for personal transactions.
40. The method as recited in claim 25, wherein the first and the second handling options provide a mechanism for identifying either a first user or a second user as the first entity.
41. The method as recited in claim 40, wherein approval of a payment card transaction for the first user is subject to different restrictions than approval of a payment card transaction for the second user.
42. The method as recited in claim 25, wherein the first and the second handling options provide a mechanism for controlling what information is reported about a plurality of payment card transactions in a billing statement.
43. The method as recited in claim 24 wherein the money source obtains the customization variable from the validation code.
44. A method, comprising:
- (a) receiving an encrypted transaction validation code which positively identifies a first transaction for a first entity, the first entity having a first entity identifier;
- (b) receiving a customization parameter for the first transaction;
- (c) electronically verifying that the first transaction is valid by use of the first entity identifier and the validation code; and
- (d) customizing the first transaction through use of the customization parameter;
- wherein the validation code is, at least in part, encrypted, and
- wherein the money source validates the validation code by duplicating a validation code encryption process and by then comparing the result to the validation code received with the first transaction.
45. The method as recited in claim 44, wherein the customization variable is used to select between a first handling option and a second handling option between the money source and the first entity.
46. The method as recited in claim 45, wherein the first and the second handling options are mechanisms to bill a first account and a second account and the first account and the second account are two separate accounts.
47. The method as recited in claim 46, wherein the first entity is sent a single bill for charges to the first account and the second account.
48. The method as recited in claim 47, wherein the first account is established with a first money source and the second account is established with a second money source and the second money source is different from the first money source.
49. The method as recited in claim 46, wherein the first account is a credit account and the second account is a credit account.
50. The method as recited in claim 46, wherein the first entity is sent a first bill for the first account and a separate bill for the second amount.
51. The method as recited in claim 45, wherein the first and the second handling options are a first and a second mechanism for dealing with distribution of information concerning a plurality of payment card transactions.
52. The method as recited in claim 51, wherein the first mechanism restricts the distribution from the money source to a third party of information relating to any payment card transaction in which the user payment card number is generated by use of the first user key.
53. The method as recited in claim 51, wherein the first mechanism restricts the distribution from the money source to a second entity of personal information of the first entity relating to any payment card transaction in which the user payment card number is generated by use of a first user key.
54. The method as recited in claim 52, wherein the money source receives consideration from the first entity for use of the first mechanism.
55. The method as recited in claim 51, wherein the second mechanism permits distribution from the money source to a third party of information relating to any payment card transaction in which the user payment card number is generated by use of a second user key.
56. The method as recited in claim 51, wherein the second mechanism permits distribution from the money source to a second entity of personal information of the first entity relating to any payment card transaction in which the user payment card number is generated by use of a second user key.
57. The method as recited in claim 55, wherein the money source provides the user with consideration for use of the second mechanism.
58. The method as recited in claim 45, wherein the first and second handling options provide a mechanism for classifying the nature of a plurality of payment card transactions.
59. The method as recited in claim 45, wherein the first handling option is used for business transactions and the second handling option is used for personal transactions.
60. The method as recited in claim 45, wherein the first and the second handling options provide a mechanism for identifying either a first user or a second user as the first entity.
61. The method as recited in claim 60, wherein approval of a payment card transaction for the first user is subject to different restrictions than approval of a payment card transaction for the second user.
62. The method as recited in claim 45, wherein the first and the second handling options provide a mechanism for controlling what information is reported about a plurality of payment card transactions in a billing statement.
63. The method as recited in claim 44 wherein the money source obtains the customization variable from the validation code.
64. The method as recited in claim 44 wherein the customization variable is received through use of at least one button.
Type: Application
Filed: Jun 21, 2012
Publication Date: Oct 18, 2012
Applicant: PRIVASYS, INC. (Tiburon, CA)
Inventors: Larry Routhenstein (Orlando, FL), Roy L. Anderson (Glendale, CA), Jacob Y. Wong (Goleta, CA)
Application Number: 13/529,713
International Classification: G06Q 20/40 (20120101);
