Method and apparatus for securing credit card transactions5317636Abstract This disclosure relates to a method and apparatus for improving the security of credit card transactions. It involves a so-called "smart" credit card, which includes a processor, a memory, and a display window. When used, the card produces a verification number, which is based on a transaction sequence number and an encryption algorithm stored in the memory of the card. The verification number produced by the card is read in the display window and transmitted to a verification computer. The computer uses the verification number, together with a de-encryption algorithm, to produce a computed transaction sequence number. If the computed transaction sequence number corresponds to a transaction sequence number stored in the memory of the computer, then the computer will authorize the transaction, otherwise it will not. Both the card and computer change their respective transaction sequence numbers, such as by incrementation, so that different transaction sequence numbers are stored in the respective memories, for the production of a different verification number for the next transaction. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE A
______________________________________
ENCRYPTED OUTPUT
INPUT (TSN 52)
(VERIFICATION NUMBER 44)
______________________________________
1.0000 7ED3323FA1601E21
2.0000 F36161065EB2ADFD
3.0000 6C0BE1CA263A3D1E
4.0000 809D777FF00CA02B
5.0000 C1D2497E7CBC2AF3
______________________________________
As seen from Table A, even though the TSN 52 values are incremented by 1, such that each successive TSN 52 has a clear relationship to its predecessor, the verification numbers 44 produced by the algorithm using the TSN's 52 show no apparent relationship to one another. The undecernable relationship between successive verification numbers 44 has an impact on achieving security insofar as it is desirable to implement an encoding system through which no one is able to predict a subsequent verification number 44 after having seen a previous verification number 44. Also with respect to Table A, it should be noted that this particular implentation is based on a rather large verification number 44, which is shown in hexadecimal representation. In actual practical implementations and other embodiments of the invention, verification number 44 could be made more conveniently smaller, and could be in only base ten numbers. In accordance with the present invention, in order to implement a system by which credit card transactions are made more secure, card 20 works in concert with a verification computer 80, which is shown in block diagram form on FIG. 4. Computer 80 is a general purpose computing device, which may be linked with a network of computers. In one embodiment, computer 80 can be the type of general purpose computer which is commonly used to process and verify credit card and bank card transactions. In order to do so, computer 80 is shown to include processor 82 and memory device 84. The storage capacity of memory device 84 of computer 80 can be far greater than that of memory device 34 of card 20, given that memory device 84 may include an electronic RAM, as well as axillary memory components, such as magnetic disk drives or tape drives. As shown on FIG. 4, memory device 84 includes account file 86, which represents the electronic file for a given customer. Account file 86 includes account information 90, which is the typical account data that is used to identify a given customer of a credit card service, including the name of the customer, a customer unique account number, a billing address, and credit information, such as any applicable credit limits. During the life span of the account, account information 90 may be periodically updated and changed as the customer changes addresses, or credit limits are altered, and so on. Also shown in FIG. 4, account file 86 includes a transaction sequence number, abbreviated "TSN 92", which, as discussed below, will change over time. Account file 86 further contains an algorithm, which is abbreviated "ALG-96", which does not change over time. In the preferred embodiment, ALG-96 will be the reverse encryption, or de-encryption, algorithm described in the Data Encryption Standard, discussed above. It should be noted at this point, the use of the "+" and "-" suffixes in connection with "ALG" is intended to indicate that the algorithms in memory device 34 and memory device 84 are complementary in the sense that, whereas ALG+50 performs an encryption function, ALG-96 performs a de-encryption function. More particularly, in card 20 processor 30 uses ALG+50 together with TSN 52, stored in memory device 34, to produce verification number 44. When computer 80 receives account number 24 and verification number 44, in the manner detailed below, processor 82 retrieves ALG-96 from memory device 84 and processes the received verification number 44 together with ALG-96 to produce a computed, transaction sequence number, which will eventually be compared with TSN 92, stored in memory device 84. FIG. 4 further shows processor 82 including comparator 100, which is the portion of processor 82 which compares data. After the computed transaction sequence number is produced by processor 82 using verification number 44, comparator 100 compares that computed number with TSN 92 stored in memory device 84. If the computed, transaction sequence number "corresponds" with TSN 92, as the term "correspondence (corresponds)" is hereinbelow defined, computer 80 will verify and approve the transaction, otherwise it will not. Assuming that computer 80 does verify the transaction, processor 82 then increments TSN 92, and stores the incremented transaction sequence number back in memory device 84, as TSN 92. Also shown on FIG. 4 is operator 102, who could be the card holder; however, in practical use applications it may also be another person, such as a clerk who is processing a retail transaction for the card holder. In accordance with this description, operator 102 is a person who enters certain account information, including verification number 44, into station 104. As shown on FIG. 4, station 104 is linked to computer 80 by means of transmission link 106, which is typically a telephone network. In one application of the embodiment of the invention, operator 102 could be the card holder placing a long distance call, and station 104 is a public telephone. In yet another application, operator 102 could be a store clerk verifying a credit card transaction, and station 104 is the computer keypad or keyboard, or telephone linking the clerk to computer 80. In order to explain the process by which card 20 and computer 80 are used together to improve the security of credit card transactions, reference will be made to the flow diagrams provided on FIGS. 5 and 6, as well as to an example developed in conjunction with FIG. 6 to illustrate certain principles about the operation of the embodiment of the invention. As shown in FIG. 5, the flow diagram commences with the creation of the card holder's account by opening an account file 86 in computer 80 (Step 110, FIG. 5). This is accomplished in a manner similar to the creation of an account with a traditional credit card. More particularly, the entity issuing the credit card will set up account file 86 so that memory device 84 is loaded with the relevant account information 90, which includes the name of the given customer, an account number, a billing address, and probably credit limits (Step 112, FIG. 5). In this particular embodiment, computer 80 is designed to access the accounts of the various customers of the card issuer by reference to the account number. The account number is the same as the number that is printed on the issued credit card, such as account number 24 shown on FIG. 1. In addition to loading account file 86 with account information 90, when the account is established, account file 86 is also loaded with a particular transaction sequence number, such as TSN 92, and a particular de-encryption algorithm, such as ALG-96, both shown in FIG. 4 (Step 114, FIG. 5). In addition, the process of establishing a customer account further involves loading memory device 34 of card 20 with a transaction sequence number, such as TSN 52, and an encryption algorithm, such as ALG+50 (Step 116, FIG. 5). At the point the account is established and information is loaded in memory devices 34 and 84, TSN 52 and TSN 92 can be virtually any number, subject to the limitations discussed below. In choosing the initial values for TSN 52 and TSN 92, it is necessary to anticipate that computer 80 will indirectly test the correspondence between these two numbers, and that correspondence is used as the basis for determining whether a given credit transaction is authorized by computer 80. In this detailed description, the term indirectly testing the "correspondence" means that computer 80 will compute a transaction sequence number, which is based on TSN 52, and then compare that computed transaction sequence number with TSN 92. In one implementation "correspondence" may exist only when the computed transaction sequence number is identical to TSN 92, while in other implementations "correspondence" may exist when the computed transaction sequence number falls within a certain predetermined margin. For example, in one embodiment of the invention, the relationship between TSN 52 and TSN 92 may require those two numbers to be identical in order for computer 80 to verify the transaction. In other words, computer 80 will only verify a transaction if the computed transaction sequence number is identical to TSN 92. To the extent that the computed transaction sequence number is based on TSN 52, in such an implementation, it would be necessary to insure that upon loading of TSN 52 in card 20 and TSN 92 in computer 80 they are equal. Such a close correspondence will create a very high degree of security for credit transactions; however, it may be more practical to implement a correspondence relationship that includes a margin of error for reasons discussed below. In another implementation of the invention, a margin of error is implemented in the correspondence relationship. In such an implementation, the correspondence may be somewhat looser, given that computer 80 will verify a credit transaction in which the computed transaction sequence number falls within a given numerical margin of TSN 92. For example, computer 80 may allow a margin of error equal to 5, which means that if the computed transaction sequence number falls within 5 of TSN 92, then the two numbers "correspond", and computer 80 will verify the transaction. Anything outside that margin results in a rejection. In yet another embodiment, there may be a double margin of error (or a single margin divided into a first and second portion) which is used to determine correspondence. In this implementation, computer 80 will automatically authorize any transaction in which the computed transaction sequence number falls within a given margin, such as 5 in the example above, of TSN 92. In addition, a second margin is implemented such that if the computed transaction sequence number falls within a second margin, computer 80 invokes a separate authorization sequence which may involve human intervention before the transaction is allowed. For example, computer 80 may have a first margin equal to 5, such that any computed transaction sequence number that is within 5 of TSN 92 results in an automatic authorization. Computer 80 further implements a second margin which establishes that if the computed transaction sequence number falls between a margin ranging between 6-10 away from TSN 92, for example, then computer 80 will signal an agent of the card issuer. The issuers agent then communicates with the party who is attempting to make the transaction, possibly by telephone or computer, to see whether the party can furnish correct information in response to questions asked by the agent. The solicitation of this additional information is to try to determine whether the person attempting the transaction is probably the legitimate card holder. For example, the issuers agent may ask the party questions relating to the card holder's account--such as street address, birth date, mother's maiden name, and the like. Such information is usually only known by the legitimate card owner, so that correct answers greatly increase the probability that the legitimate card owner is the party attempting the transaction. The implementation of the margin system in determining correspondence has practical advantages given that there are a number of reasons that TSN 52 and TSN 92 may fall out of synchronization, or identity, even if they were identical when the card was originally issued. For example, it is possible that the card holder may inadvertently push switch 26, shown in FIG. 2A, which, in one embodiment, causes card 20 to process verification number 44 and increment TSN 52, as described above. Given that, in this example, the incrementation is not part of a deliberate credit transaction, TSN 92 will not be incremented, resulting in a loss of synchronization between TSN 52 and TSN 92. Alternatively, the card holder may intentionally process a verification number 44 in order to undertake a credit transaction; however, due to the unavailability of computer 80, or temporarily incapacitated telephone lines, the transaction may not be processed to completion. Thus, in such cases, TSN 52 would have been incremented, even though TSN 92 was never incremented, resulting in the two numbers falling out of synchronization. Thus, a correspondence test which is based on the margin system better accommodates practical applications of card 20. Additional features could be added to a system which implements the margins approach. For example, although it is possible for TSN 52 to be incremented without the incrementation of TSN 92, the reverse is not likely, namely TSN 92 is not likely to be incremented without TS 52 being incremented. This is because TSN 92 only gets incremented after computer 80 verifies a transaction, which only occurs after card 20 has produced a verification number 44, which automatically causes TSN 52 to be incremented. Therefore, in order to enhance the security of a system which involves margins, computer 80 can implement a "positive margin", meaning that the margin is only applicable in the positive direction. In other words, computer 80 will verify a transaction only if the computed transaction sequence number falls within the range between TSN 92 and some number greater than TSN 92, such as TSN 92 +5 where the exemplary margin is equal to 5. Thus, computed transaction sequence numbers less than TSN 92 would not result an authorization by computer 80, even if they were within five of TSN 92. Computer 80 may also update TSN 92, whenever it finds a lack of identity between the computed transaction sequence number and TSN 92, but the computed transaction sequence number nonetheless falls within the established margins. In other words, after computer 80 determines that the computed transaction sequence number is not equal to TSN 92, but it does fall within allowable margins, computer 80 could change TSN 92 so that it is reset to the value of the computed transaction sequence number. To the extent that the computed transaction sequence number reflects the value of TSN 52, this updating approach will restore the synchronization between TSN 52 and TSN 92. Likewise the updating of TSN 92 could be done if the system were based on the double margin implementation, which involves the intervention of the issuer's agent, as discussed above. In the preferred embodiment, computer 80 tests the correspondence of TSN 52 and TSN 92 based on a positive margin. Additionally, the margins can obviously be changed on the basis of particular implementations. The actual margin information can be loaded into a given customer account file along with the other customer account information discussed in connection with steps 112 and 114, above. Additionally, one other factor that may influence the selection of the initial TSN 52 and TSN 92 is that the numbers cannot be so large that its binary representation exceeds the memory capacity of the memory devices. Not only should it not exceed the limits when it is first loaded, but it must be planned that it will not exceed the memory capacity as the transaction sequence number is incremented over time. Practically speaking, this is only a concern with respect to memory device 34 of card 20, given that memory device 84 is, in this context, virtually limitless. Still referring to the flow diagram of FIG. 5, after card 20 and computer 80 are loaded with their respective algorithms and transaction sequence numbers and account information, card 20 is issued to the authorized account owner for use (Step 118, FIG. 5). In order to demonstrate the method by which card 20 works together with computer 80 to create a secure transaction, an example will be developed using simplified numbers which demonstrate the principle by which the embodiment operates. This example is discussed in conjunction with the flow diagram of FIG. 6. This example is based upon a telephone credit card issued to a legitimate card owner, and the card owner's account includes the particular data shown in Table B. In addition, in the particular example developed, when card 20 and computer 80 increment their respective transaction sequence numbers, they will each increment by 5, instead of 1. Incrementation by differing numbers for the cards issued by a particular issuer adds yet another layer of security to the implementation of the security system. Thus, Table B includes an incrementation factor, which is stored in the respective memory devices 34, 84. Also, the incrementation factors shown in Table B is the same for card 20 and computer 80.
TABLE B
______________________________________
Card 20: initially loaded TSN 52 = 1;
ALG+ 50 : add 10 to TSN 52 to produce
verification number 44; and
incrementation factor = 5.
Computer 80:
initially loaded TSN 92 = 1;
ALG- : subtract 10 from verification number 44
to produce TSN 92;
incrementation factor = 5; and
positive margin = 10.
______________________________________
Although a preferred algorithm has been identified above, for the purpose of illustrating the principles underlying the embodiment of the present invention, a greatly simplified algorithm is presented in this particular example. Such a simplified algorithm is intended to serve as an example of how card 20 and computer 80 together improve the security of a credit card transaction. The principles underlying the process embodiment of the invention would be the same as this simplified example, if the algorithm of the Data Encryption Standard discussed above was used. As shown in Table B, the loaded transaction sequence numbers, TSN 52 and TSN 92 are identical upon loading. Comparing the two algorithms shown in Table B reveals that ALG+50 creates an encrypted verification number 44 by adding 10 to TSN 52, and that verification number 44 is de-encrypted by using ALG-96, which subtracts 10 from verification number 44. Also, computer 80 includes a positive margin equal to 10. Referring to the flow diagram of FIG. 6, assume a legitimate card holder wishes to make a long distance telephone call using a telephone credit card, which is card 20 in accordance with an embodiment of the present invention. In this exemplary transaction, the card owner is using card 20 for the first time after issuance such that the data of Table B has been loaded in card 20 and computer 80, and has not been changed at the time the card holder initiates this first transaction. Referring back to FIG. 4, the card holder, or operator 102, will initiate the transaction by calling a generally accessible number of the long distance carrier over a telephone, or station 104 (Step 120, FIG. 6). The number of the carrier can be an 800 number, for example, and is generally accessible because it is distributed on a non-confidential basis to all customers of the long distance service. By dialing the access number to the long distance carrier, operator 102 is connected with the long distance carrier's computer switching network, or computer 80, which has as part of its function connecting the call for the customer. Prior to making that connection, however, computer 80 will invoke an access sequence to make sure that operator 102 is authorized to use the network, and to make sure that the service is billed to the appropriate account, in this instance the account of the card holder. In response to the service request initiated by operator 102 and as part of the access sequence, operator 102 is requested by computer 80 to furnish an account number, such as account number 24 of card 20 shown on FIG. 1 (Step 122, FIG. 6). At this point operator 102 may well look at card 20 in order to read account number 24 from card 20, as it is unlikely that card holders of credit cards, especially those who own many credit cards, would commit their card account numbers to memory. Operator 102 next enters account number 24 through station 104, by using the key pad of the telephone, for example (Step 124, FIG. 6). Computer 80 then calls up account file 86 in response to the provision of account number 24, and will thereby have access to all of the data in account 86. Computer 80 will check to determine if account number 24 corresponds with a valid account, and, in some instances, to determine if the request exceeds any applicable credit limits. As discussed above, memory device 84 includes account information 90 which enables computer 80 to verify the existence of the account and whether account number 24 makes the caller eligible to proceed with the request. Assuming everything relating to the account is acceptable, computer 80 verifies the account (Step 126, FIG. 6). In accordance with the embodiment of the invention, account verification by computer 80 does not necessarily mean that the requested transaction is authorized, but simply that operator 102 may proceed in the manner to be discussed below. Thus far, the exemplary transaction is quite typical of the authorization sequence currently used by many telephone service providers. And, on a general level, the sequence is typical of the authorization of many credit card transactions. Furthermore, for many traditional credit card services, after the account number and credit limits, if any, are verified by the computer, the transaction is approved without any further verification. This portion of the exemplary transaction, however, reveals the vulnerability of a traditional credit card systems to theft. If, while the card owner reads an account number from the traditional card, a second party were to see and retain the account number from either looking at the card or the dialing sequence on the telephone, that second party could then place unauthorized calls. As described, in order to place calls the second party needs only the access number of the carrier, which is generally available, and the account number. In the example, both of these numbers are made accessible through the transaction, or, in the case of the access number, it is likely to be accessible generally. Thus, if the second party retained both numbers, they could be used to place unauthorized calls, at least until the unauthorized calling was detected and stopped. This, however, could take enough time so that significant charges could be amassed against the account. Such fraudulent practices could be costly to the account owner, the carrier, or both. Accordingly, an embodiment of the present invention enhances the security of a credit card transaction, by requiring the service requester to enter a verification number in addition to the other information required during the access sequence. More particularly, as shown in FIG. 2A, after operator 102 is required to provide account number 24, operator 102 is then required to provide verification number 44, in order to have the transaction authorized by computer 80. Given that operator 102 will have to furnish verification number 44 during the access sequence, at any time prior to or during the initiation of the transaction, probably at the time operator 102 takes out card 20 to read account number 24, operator activates switch 26, shown on FIGS. 1 and 2. The precise timing of when verification number 44 is computed, relative to the other steps of the access sequence, is not critical, provided it is accessible for entry during the time computer 80 makes available for the entry of that data. As described above, switch 26 or pad 27 will activate processor 30 to access memory device 34 and compute verification number 44 using ALG+50 and TSN 52. Using the data provided in Table B, in accordance with this particular example, processor 30 will compute a verification number 44 equal to 11, given that from Table B ALG+50 requires the addition of 10 to TSN 52 to produce verification number 44, or 10+1=11. Given that operator 102 has already entered account number 24, and assuming that computer 80 retrieves the account file 86 and determines that the account is valid for the request, computer 80 next requests operator 102 to enter verification number 44 produced by card 20 (Step 130, FIG. 6). Verification number 44 is provided through station 104, which in the example is a telephone key pad. Thus, in response to the request by computer 80, operator 102 transmits the number 11 through station 104 (Step 132, FIG. 6). Continuing with the authorization sequence of the preferred embodiment, computer 80 will receive verification number 44 from station 104. As detailed above, processor 82 of computer 80 then retrieves ALG-96 and the applicable positive margin from the account file 86. As discussed above, processor 82 will process verification number 44 together with ALG-96 and compute a transaction sequence number (Step 134, FIG. 6). In this example, which is based on the data in Table B, ALG-96 subtracts 10 from verification number 44 to produce a computed transaction sequence number equal to 1, or 11-10=1. Next, processor 82 retrieves TSN 92 from memory device 84, and tests whether the computed transaction sequence number corresponds to TSN 92 (Decision step 136, FIG. 6). In this example, correspondence is based on testing whether the computed transaction sequence number falls within the range TSN 92 through TSN 92+10. If so, then computer 80 will authorize the transaction (Step 140, FIG. 6); if not, computer 80 rejects the transaction, or, in this particular example, would not let operator 102 place the call (Step 142, FIG. 6). As discussed above, in other implementations computer 80 could include a double margin, which involves a second test to determine if the computed transaction sequence number falls within a second margin, in which case the issuer's agent queries the party attempting the transaction in the manner described above. In accordance with the example, the computed transaction sequence number is the same as TSN 92, or 1=1, so computer 80 will authorize the transaction, and operator 102 will be permitted to make the telephone call. Next, both card 20 and computer 80 update their respective transaction sequence numbers 52, 92, so that a new transaction sequence number is stored in their respective memory devices 34, 84. As shown on Table B, processor 30 increments TSN 52 by 5 (Step 144, FIG. 6), and processor 82 likewise increments TSN 92 by 5 (Step 146, FIG. 6). Thus, after incrementation, TSN 52 and TSN 92 are both equal to 6, and are both stored in their respective memory devices 34, 84. Additionally, if computer 80 implements a margin system, and during any given transaction approval process computer 80 detected a lack of identity between the computed transaction sequence number and TSN 92, at Step 146 computer 80 could correct TSN 92 so that it is once again synchronized with TSN 52. This, of course, is based on the assumption that the computed transaction sequence number fell within the applicable margins, and computer 80 determined that transaction should be authorized. In order to further show how the embodiment of the invention increases transaction security, it will be assumed that a second party observed the entire transaction of operator 102. It will further be assumed that the second party retained the account number 24 and the verification number 44 entered by operator 102 in making the telephone call. The second party will then attempt to use those numbers to place a telephone call which is to be charged against the account number 24 of the legitimate card holder. As indicated, the access number of the long distance carrier is assumed to be generally available. Thus, the second party makes contact with computer 80 through station 104, and computer 80 requests an account number. Account number 24 is entered and recognized by computer 80 as a valid account. Computer 80 next requests a verification number, but the only verification number the second party has is the one entered during the previous transaction. Alternatively, the second party could guess at a verification number, which is unlikely to be effective. In this example, the second party transmits the number 11, which was the previous verification number 44, to computer 80. As discussed, computer 80 accesses ALG-96 from account file 86, which is the account identified by the specific account number 24 provided by the second party. Computer 80 will process ALG-96 with the transmitted verification number 44. Using the number 11, processor 82 will compute the transaction sequence number 1, or 11-10=1. Thus, when comparator 100 tests the correspondence between the computed transaction sequence number with TSN 92, then stored in memory device 84, the two numbers will not correspond because the value 6 was stored in memory device 84 after the last transaction. It will be recalled that the margin implemented in this example is "positive" 10. Thus, even though the computed transaction sequence number is within 10 units of TSN 92, (i.e. 1 is within 10 units of 6), computer applies the margin only in the positive direction. Given that the computed transaction sequence number is less than TSN 92, computer 80 concludes that an invalid verification number 44 has been presented, and refuses to authorize the transaction. Accordingly, computer 80 would not allow the second party to charge the call to the given account number 24. To complete this example, it will be assumed that after the first transaction, the legitimate card owner wishes to conduct a second transaction, namely place a second call. In preparing to do so, the card owner will be assumed to have had card 20 produce a verification number 44, which automatically results in the incrementation of TSN 52. Due to some problem with the telephone network, however, it will be further assumed that when the card holder attempted to place the second call, the network was blocked such that the card owner never even had a chance to attempt authorization. Nonetheless, as a result of the incrementation in card 20, TSN 52 is now equal to 11, or 6+5=11. Shortly thereafter, the card holder attempts the call again, and this time the telephone network is operating. As shown on FIG. 4, operator 102 furnishes account number 24 through station 104. After account confirmation, as described above, computer 80 will again request verification number 44. In this instance, TSN 52, which is stored in memory device 84 is 11. As the number 11 is processed by processor 30 using ALG+50, verification number 44 is made equal to 21, or 11+10=21. Operator 102 reads verification number 44, in window 32 of card 20, and then transmits it to computer 80 through station 104. As in the previous exemplary operations, processor 82 of computer 80 processes verification number 44 with ALG-96 to generate a computed transaction sequence number equal to 11, or 21-10=11. Then, using the established positive margin for this account, comparator 100 will test the correspondence between the computed transaction sequence number and the stored TSN 92. Note that the two numbers are not equal due to the fact that the synchronization between the TSN 52 and TSN 92 was lost when the card owner attempted the transaction that never went through. On the other hand, computer 80 implements a margin system such that comparator 100 tests correspondence on the basis of whether the computed transaction sequence number falls within TSN 92 through TSN 92+10. In this instance that range is actually 6 through 16. Given that 11, the computed transaction sequence number, falls within this range, computer 80 will verify the transaction. Additionally, computer 80 will note that TSN 92 is out of synchronization the computed transaction sequence number, and therefore TSN 52, and computer 80 will "correct", or synchronize, TSN 92 with TSN 52 by changing TSN 92 to 11, before the automatic incrementation by 5. Thus, not only will the transaction be approved, but also when TSN 52 is next incremented by 5, so that 16 is stored in memory 34, the corrected TSN 92 will likewise be incremented by 5, so that 16 is stored in memory 84. By creating a transaction unique, verification number 44 which is required as part of the sequence by which credit card transactions are verified, the embodiment enhances the security of the credit card transaction. By requiring the unique verification number 44, the process effectively renders useless the verification number generated in one transaction for use during a subsequent transaction. Thus, even if an unscrupulous party were to observe and retain the numbers used to authorize one transaction, they would be useless for subsequent transactions. As indicated above, the example provided used highly simplified numbers for the purpose of illustrating the principles of the process and how card 20 and computer 80 work to secure the transaction. Thus, the numbers produced may seem simple; however, with card 20 implementing a more sophisticated algorithm, such as the one referred to above, it would be statistically impossible for a would-be thief to guess the correct verification number 44 for a future transaction, from the verification number 44 of a past transaction. As shown in the exemplary numbers of Table A, the verification numbers 44 bore no apparent relationship to one another, even though they were produced by simple numbers which were incremented by 1. Additionally, because of the incrementation of TSN 52 after each transaction, it is not possible for the same transaction sequence number to be produced by a given card 20, and correspondingly it is not possible for the same verification number 44 to be produced twice by the given card 20. Several additional points should be noted with respect to the embodiment of the invention. Firstly, the example provided an application of the embodiment of the invention to telephone credit cards. Card 20 can also be used in connection with a typical credit card transaction, and provide the enhanced transaction security. For example, if the legitimate owner of card 20 were to purchase an item in a store, the clerk, or operator 102 in FIG. 4, could enter the account number 24 into station 104. In this example, station 104 could be a card reader for reading account number 24 from a magnetic strip on card 20. Alternatively, station 104 could be a telephone or computer key pad, in which case operator 102 could enter account number 24 by means of either of these. As in the previous example, after account verification, computer 80 requests verification number 44, which is produced by card 20 in the manner discussed above. Assuming a correspondence between the stored TSN 92 and the computed transaction sequence number produced by processor 82, computer 80 authorizes the transaction. Once again, if the store clerk or another party were to attempt to use the numbers from the previous transaction, due to the incrementing of transaction sequence numbers 52, 92, in memory devices 34, 84, the verification number 44 from the earlier legitimate purchase would not work for the same reasons provided in connection with the second party who attempted the illicite telephone call. Accordingly, the embodiments of the present invention can be applied to credit card transactions generally, not simply telephone credit cards. Additionally, it should be noted that the embodiments of the invention are suitable for mass production and implementation. As discussed in one embodiment, when the account of the card holder is established, there will be a coordination between the data in memory device 34 of card 20 and memory device 84 of computer 80. In particular, the two will have corresponding transaction sequence numbers and incrementation factors, if any, and complimentary algorithms. Given that the installation of this data is relatively straightforward it is feasible to implement on a wide scale. Yet another reason the embodiments of the present invention are suitable for mass production, while still preserving security, is that the issuer of the cards can initially load different algorithms, transaction sequence numbers, and incrementation factors in some or all of the cards of their different customers. Loading different numbers insures that the verification number produced by one card is useless in determining the verification number which will be produced by another card, even though the cards are issued by the same entity. Changing the initially loaded algorithms, transaction sequence numbers, and incrementation factors for the cards produced by the issuer is also accomplished in a straightforward manner when the accounts are established and the cards are produced. In yet another embodiment of the invention, it is even possible to eliminate the need for establishing the initial correspondence between TSN 52 and TSN 92. Instead, in this alternate embodiment, a batch of cards 20 could be manufactured in which TSN 52 is not set to any particular number, for example memory 34 could be completely blank. In other words, TSN 52 for all of cards 20 could be 0. Additionally, TSN 92 would likewise be blank, or 0. This, of course, has significant advantages with respect to the mass production of cards 20, insofar as it does not require the recordation and coordination of the TSN 52 and TSN 92 at the time cards 20 are made and issued. In this implementation, processor 30 of card 20, shown on FIGS. 2A and 2B, includes a random number generator 102, which is capable of generating a random number that would be suitable as the first TSN 52, in accordance with the parameters discussed above. Then, after card 20 is issued and the card holder attempts the first transaction and signals card 20 to produce a verification number 44, processor 30 will first generate the random number using random number generator 102. This will be stored in memory 34, and will then be accessed by processor 30 along with ALG+50 for the purpose of producing the first verification number 44. Verification number 44 will then be furnished to computer 80 in the same manner detailed above. When computer 80 receives the verification number 44 it will, as discussed, use ALG-96 to compute a transaction sequence number. Unlike the forgoing examples, however, computer 80 does not have a specific value for TSN 92 that it can test for correspondence with the computed transaction sequence number. In this particular implementation, however, computer 80 will use the computed transaction sequence number as TSN 92, which effectively assures authorization of the first transaction relating to card 20. Thereafter, however, card 20 and computer 80 will at that point have synchronized numbers, and the system can work in the same manner as detailed above. In yet another embodiment, the same approach can be implemented, however, the system can be based on the understanding that the very first use of the card is solely for the establishment of TSN 52 and TSN 92. Thus, in order to increase the security of the system, such an approach can prohibit the charging of any services or goods against the card until the second time it is used. The invention in its broader aspects is not limited to the specific details, representative apparatus, and illustrative examples shown and described herein. Thus, departures may be made from such details without departing from the spirit or scope of the invention.
|
Same subclass Same class Consider this |
||||||||||