CA1281420C - Transaction approval system - Google Patents
Transaction approval systemInfo
- Publication number
- CA1281420C CA1281420C CA000551653A CA551653A CA1281420C CA 1281420 C CA1281420 C CA 1281420C CA 000551653 A CA000551653 A CA 000551653A CA 551653 A CA551653 A CA 551653A CA 1281420 C CA1281420 C CA 1281420C
- Authority
- CA
- Canada
- Prior art keywords
- transaction
- card
- invalid
- master table
- indicator
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/403—Solvency checks
Abstract
ABSTRACT OF THE DISCLOSURE
An improved system is disclosed for detecting invalid transaction cards at remote transaction terminals. The system includes providing each terminal with a master table having data corresponding to invalid cards. The data in the master table is less than the actual account numbers of the invalid cards. By using a compressed version of the data, the file can be shortened to facilitate storage and transmission. The compressed data file is arranged such that when an invalid card is presented, it will be identified and routed on for further processing. In the preferred embodiment, the probability that a valid card will be identified as potentially invalid is on the order of one to three percent.
An improved system is disclosed for detecting invalid transaction cards at remote transaction terminals. The system includes providing each terminal with a master table having data corresponding to invalid cards. The data in the master table is less than the actual account numbers of the invalid cards. By using a compressed version of the data, the file can be shortened to facilitate storage and transmission. The compressed data file is arranged such that when an invalid card is presented, it will be identified and routed on for further processing. In the preferred embodiment, the probability that a valid card will be identified as potentially invalid is on the order of one to three percent.
Description
~.2~4~
TRANSACTION APPROVAI SYSTEM
Technical F_eld The subject invention relates to a financial transaction network. The invention includes an improved system for distributing information about invalid transaction cards.
Back~E~und of the Invention In the last fifteen years the use of transaction cards as substitutes for cash has greatly expanded.
Along with this expanded use has come an increase in losses due to fraud. One of the most costly problems is caused by the use of invalid cards. The term invalid card includes those cards which have been lost or stolen. The term can also include cards whose credit limits have been exceeded by the holder. Significant efforts have been made to minimize the use and abuse of invalid cards.
One of the earliest approaches used to combat this fraud was to distribute a printed list of invalid cards.
One such list is called the Card Recovery Bulletin or CRB. In use, the merchant checks the account number on - the card presented for the transaction with the account numbers printed in the CRB. If the account number is listed, the transaction would be declined.
This use of the CRB is effective in reducing a large percentage of fraud losses. Unfortunately, this approach has a few drawbacks. For example, a transaction card is often used almost immediately after it has been lost or stolen. This immediate use will occur before the card has been listed in the bulletin or before the bulletin has been distributed. Another problem with this approach is that from a practioal '~
.
~8~4~0 standpoint, it is often difficult to insure that store clerks use the list properly or at all.
Because of these difficulties, many other more sophisticated approaches have been taken. One of the most effective schemes is to authorize every transaction through a real-time, on-line communications network.
For example, the merchant can report the account number of the card presented for a transaction to a central processor by telephone. The account number on the card can then be checked against a current list of invalid card numbers stored either at the central processor or back at the card issuer. In another variation on this scheme, a transaction terminal is provided with a card reader which reads a magnetic stripe encoded with an account number. The terminal can then automatically ; transmit the account number to the central processor for approval.
This on-line scheme eliminates the lay time inherent in using the Card Recovery Bullatin.
Unfortunately, a fully on-line system turns out to be prohibitively expensive and prone to communication delays. An on-line approach also does not provide any protection when the network is down.
More recently, many approaches have been taken to reduce transaction approval costs while also controlling fraud losses. As microprocessors become smaller, cheaper and faster, some of the transactional analysis can be performed at the terminal itself. Efforts have been made to develop screening procedures that avoid having to transmit the transaction information to the central processor. For example, the transaction terminal can be programmed to authorize every transaction below a certain dollar limit or floor limit.
In this mannar, the cost of communication can be balanced against the risk of loss.
;~
~ -3 ~ 14X~ 26469-26 The terminal may also be provided with the capability to verify a cardholder secret personal identification number or PIN.
In this scenario, a version of -the PIN is encoded onto the magnetic stripe on the card and read by the terminal. The terminal then compares the PIN read from the card with a PIN
entered into a keypad on the terminal by the cardholder. If the two PINs match, the transaction can be approved. The use of PINs sharply reduces the fraudulent use of lost or stolen cards.
A more sophisticated approach is described in Canadian Patent 1,252,566, assigned to the same assignee as the subject invention. In that patent, a system is described wherein risk assessment data is encoded onto the card by the card issuer. This risk assessment data is tailored to define the credit worthiness of each specific cardholder. This risk assessment data can be analyzed by the transaction terminal and if the transaction amount falls within the parameters encoded on the card by the issuer, the transaction can be automatically approved. If the transaction - amount exceeds these parameters, the transaction information is routed on to the central processor for further analysis.
As the cost of computer memory space has decreased, the idea~of storing the account numbers of invalid cards in each transaction terminal has been explored. If this scheme were implemented, the account number of the card being presented for the transaction could be automatically compared at the terminal.
One prior art system which utilized this approach is described in U. S. Patent No. 3,696,335, issued October 3, 1972 to Lemelson.
42~
The approach illustrated in the Lemelson patent has been deemed impractical for a number oE reasons. More specifically, in order to keep the lists current, they would have to distributed to the terminals and updated on a frequent basis. With the number of transaction terminals rapidly expanding, it would be virtually impossible to physically transfer this data to the terminals on a routine basis. Therefore, distribution of tha list of invalid account numbers must be through some type of communication link. Unfortunately, the lists of invalid cards are so large for the major transaction card systems that on-line distribution becomes quite difficult. However, if some way could be developed to distribute the list in an efficient manner, this approach could be very effective in reducing both communication costs and fraud losses.
One technique for attaining this goal is described in U.S. Patent No. ~,~58,211, issued December 10, 1985 to Berstein. This disclosure acknowledges that a complete "hot card" list would be too large to transmit to each transaction terminal. ~he solution proposed in the latter patent is to add an identi~ier to each listed hot card which indicates the geographical location in which the card is most likely to be used. Subsets of the hot card list geared to speci~ic geographical locations can then be generated. The greatly shortened lists can then be dis~ribu~ed to the terminals and stored. The patent suggests that a standard 4K byts memory in a terminal could hold a list of 800 invalid cards. Since most invalid cards are used in the area where they were lost or stolen, this approach could be very effective as long as only 800 invalid cards exist ; in any geographical area.
Unfortunately, major transaction card companies ; 35 will typically have over one million invalid cards ~2~ 2~3 listed on any given day in the United States alone.
Even when these lists are broken down geographically, the size of the smallest list does not fall much below 100,000 cards. Obviously, if the geographical area i9 made too small, the effectiveness of the system will be reduced since it will be limited to catching an unauthorized user only at the exact location the card was lost or stolen.
- Accordingly, it is the object of the subject invention to provide a new system for distributing information about invalid cards.
It is another object of the subject invention to provide a new system for distributin~ lists of invalid cards which can be used to authorize transactions at a ~ 15 transaction terminal.
`~ It is a further object of the subject invention to provide a new system far distributing lists of invalid cards in a cost effective manner.
It is still another object of the subject invention ; 20 to provide a new system for rapidly distributing lists ; of invalid cards in an on-line manner.
It is still a further object of the subject invention to provide a new data file containing information about invalid cards that takes up very little memory space.
It is still another object of the subject invention to provide a compressed data file that can be easily transmitted to remote transaction terminals.
It is still a further object of th subject inventian to proved a compressed data file which will ~; always indicate when an invalid card has been presented ~ and wherein the probability of identifying a valid card ; as a potentially invalid card is on the order of one to three percent.
.~
~' ~`
. - ,............. .
42~
It is still another object of the subject invention to provide a hot card authorization system that can easily be implemented in current microprocessor based remote transaction terminals.
It is still a further object of the subject invention to provide a compressed data file with information on an invalid transaction that is arranged in a manner such that the entire file does not have to be searched in order to determine if a particular account number is invalid.
SUMMARY OF THE INVENTION
In accordance with these and many other objects, the subject invention provides for a method for generating and distributing a master table containing infor~ation about invalid cards. A unique data compression method is used to substantially reduce the amount of memory needed to hold the master table. By reducing the size of the file, the downloading of the information to local transaction terminals is greatly facilitated.
The information contained in the master file is less than the actual account numbers of the invalid cards. Nonetheless, the data is so arranged that if an invalid card is presented to a transaction terminal, it will always be identified as requiring further analysis prior to approval. If the card is so identified, the account information can then be transmitted to a central pxocessor for final confirmation against a complete invalid card list. Conversely, if an account number is tested against the master file at the transaction terminal and is cleared, the transaction can safely be approved off-line since this result insures that the account number is not listed in the invalid card file.
~\
~.X8~4~3 Because of the characteristics of the data compression system of the subject invention, a certain percentage of valid cards which are presented will be identified as potentially invalid. In such cases, the information about the transaction will be passed on to the central processor for absolute verification. The probability of a valid card being identified as potentially invalid can be adjusted by varying the characteristics of the master table. The probability of a valid card being identified as potentially invalid should be less than ten percent and preferably on the order of one to three percent. Since many transactions ara transferred to the central processor for other reasons ~i.e. high dollar amount transactions which exceed the floor limit o~ the terminal), the fact that a small percentage of transactions are sent to the central processor under this scheme will have an insignificant impact on overall system performance.
; The master table is defined by a plurality of bit maps. As discussed in detail below, by using a plurality of bit maps in the master table instead of just one, the probability of a valid card being identified as potentially invalid can be reduced.
Conversely, as the number of bit maps is increased, ~5 processing time is also increased.
Each of the bit maps in the table is B bits in length. Information about the invalid cards is represented by indicators within the bit map. In order to set the indicators~ the account number of the invalid card is subjected to an algorithmic function to generate an index value betwsen zero and the number of bits in the bit map. When this value is obtained, an indicator is placed in the location in the bit map corresponding to the index value that is generated. In the illustrated embodiment, where five bit maps are used, ` ~81.~2~
the account number is subjected to five di~ferent algorithmic procedures to generate five different index values, each of which is used to place an indicator in one of the five bit maps.
The algorithm used to generate an index value may be relatively sophisticated, such as the data encryption standard (DES). For ~reater speed and simplicity, select~d digits of the account number can be mixed and added to generate an index value. The process of lo mathematically reducing the information content in a data stream is typically called "hashing'l.
The selected hashing procedures are repeated for each of the invalid cards on the list. When the table is complete, it is distri~uted to the transaction terminals. In the preferred embodiment, this list is downloaded by radio transmission to all terminals simultaneouslyO This list can be downloaded through any other suitable type of communication link.
In operation, the account number of the card presented for the transaction is read into the terminal.
The terminal then performs the same algorithmic steps, or, hashing on the new account number that was done to create the table in the first place~ An index value is generated for each bit map. The transaction terminal then determines if an indicator is present in each bit map in the master table corresponding to each of the newly generated index values. I~ any hit map does not contain an indiaator, then the card is immediately known to be valid and the transaction may be approved off-line. If the comparison reveals that the indicator~ are present in every bit map, then there is a possibility that an invalid card has been presented. In this case, some form of ~urther processing will be required. At that point, the transaction may be routed to the cantral processor for an absolute comparison of the account ~' , :
.
1~8~
_9_ numbers against the entire list of invalid cards. If the transaction system happens to be down, a message may be relayed to the operator that the account number should be checked against a printed list. As pointed out above, the terminal will identify some small percentage of valid cards as potentially invalid but the results of further processing will indicate that those cards so identified are in fact valid and that the transaction should proceed.
It is estimated that a master table generated with the subject data compression system will be one-fourth to one-sixth the length of a list of actual invalid account numbers. This shorter file can be more easily transmitted and stored. Another advantage to this approach is that the entire table does not have to be scanned to determine if a card is valid. The index values are used to pinpoint specific locations in the table. As soon as such a location is encountered in which no indicator is present, the card in question is immediately known to be valid.
, BRIEF DESCRLPTION OF THE DRAWINGS
Figure 1 is a schematic diagram illustrating a transaction network where the method of the subject invention can be implemented.
Figure 2 is a representation of a master table having five bit maps.
Figure 3 is a representation of the last 12 digits of an invalid account number.
Figure 4 is a flow chart illustrating the steps taken at the transaction terminal in accordance with the subject invention.
, , ~ , ,, ' : :. . . ::
42~
; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Referring to Figure 1, there is illustrated a transaction network in which the subjact invention may be implemented. As shown in Figure 1, a transaction network typically will include one or more issuers 10 of transaction cards. The transaction cards are distributed to customers and will include an account number identifying the cardholder. The cards are presented to merchants for yoods and ser~ices in lieu of cash.
The transaction is frequently authorized through the use of transaction terminals 20. There are a large number of transaction terminals publically available and therefore they will not be described in detail herein.
The current state of the art transaction terminal ; typically includes a card reader for reading account information and other data from the magnetic stripe on the transaction card. The terminal can also be provided with the ability to automatically dial and make an on-line connection to a computer located either at a merchant bank, a network switch or to one of the card issuers. For the purposes of this disclosure, block 30, labelled "CPU," is inkended to correspond to a central ; processing unit having higher l vel decision-making authority. For example, the central processing unit 30 can have stored therein a full list of invalid cards 32 which may be consulted to determine if the transaction should be approved.
~ As discussed above, the transaction terminal 20 may ; 30 be provided with the ability to perform some transactional analysis without connection to the main CPU 30. To carry out these functions, the terminals will include a microprocessor, dedicated ROMs, random access memories, a keypad and display. In order to .~
4'~
perform the subject invenkion, some dynamic memory space must ba allocated for holding the master table 40. In addition, a program must be provided for analyzing the account number presented with the data in the master table. The programming of a terminal to perform these functions is well within the abilities of one skilled in the software development art.
In accordance with the subject invention, the terminal 20 is capable o~ determining whether a card, presented for a transaction, is likely to be invalid.
This result was achieved in the above cited U.S.
Patents. In the prior art systems, actual invalid account numbers axe supplied to each transaction terminal. The account number of the card presented is compared to the account numbers listed in the memory to determine if the transaction should be approved. In contrast, in the subject invention, a master table containing information less than the invalid account ~-numbers is generated and supplied to the terminals. In this manner, meaningful data can be stored in less space. In addition, only precise locations in the table are searched to determine if the card is invalid.
;In accordance with the subject invention, the A~information on the invalid cards is contained in a master table 40 generated at the central processor 30.
An example of a master table 40 is shown in detail in Fiyure 2. ~he mastar table consists of at least one bit map of B bits in length. Preferably, a plurality of bit maps are used. As will be seen below, by using a plurality of bit maps in the master table instead of just one, the probability of a valid card being identified as potentially invalid is decreased. In the illustrated embodiment of Figure 2, five bit maps are used.
~L2~ 2C3 When selecting the length of the bit map, consideration should be given to maximizing khe information content within the map. From a statistical analysis, it can be shown that greatest information content in a bit map occurs when roughly half the bits are zero and half the bits are one. Assuming that the algorithmic functions used to generate the table provide results with pseudo-random characteristics, the fraction of bits in a bit map which are zero is given by the following equation:
(1~ Z = [1 - (~/B)]
where Z is the ~raction, B is the number of bits in the map and N is the number of invalid cards listed. Where each bit map is 200,000 bits in length, a distribution profile where half the bits are zero and half the bits are one (Z = 0.5) would occur when about 138,000 account numbers are listed. In the illustrated embodiment, where roughly 100,000 cards are initially listed, the probability of any bit being a one is on the order of 0.4. In operation, as account numbers are added to the mastsr table through an update procedure discussed below, the information content in the bit map will increase as the probability increases to 0.~.
In order to generate the table, the account numbers of the invalid cards are "hashed" to derive compressed data. An account number can be hashed by encrypting the numbQr using the data encryption standard (DES) and a secret key. The resulting number can be truncated to an index value between zero and B-l. An indicator, (for example, a "one" if all the bits are originally set to "zero") can then be placed in the bit map at the location corresponding to the index value which has been generated by the algorithmic function. If more than one , , ~128~
bit map is used, the account number could be encrypted again, using a different key. The result is truncated to obtain another index value which will be used to place an indicator in the second bit map. This process would be repeated, encrypting the account number one time for each bit map present in the master table. Each invalid card would then have one indicator in each of the bit maps. Similar steps would be performed for each invalid card, and indicators would be added into the table. If an indicator was already located at an index value ~rom a previous card, this indicator would remain unchanged.
While the data encryption standard (DES) provides a method of hashing account numbers which has suitable pseudo-random characteristics, it is also time-consuming and complex. In the illustrated embodiment, a simpler and faster hashing algorithm is described which has an acceptable degree of pseudo-random characteristics. In ~` this context, a pseudo-random algorithmic function will insure that any index value generated from the account number will have an equal probability of lying anywhere in the bit map. Furthermore, *he results of the algorithmic function used with one bit map should not corraspond in any way to the results of the algorithmic function used to generate a different bit map.
In the illustrated embodiment, these factors are balanced by selecting and combining small groups of digits in the account number to create index values.
This approach can best be understood by referring to Figure 3 and the tables below. Figure 3 illustrates the last 12 digits of an account number 0358-2314-2787. The position of these digits has been labelled 1 to 12, from right to left. Where the bit map has 200,000 entries, index values between 0 and 199,999 must be generated~
The most significant digit of that six-digit index value 4~0 must be either a one or a zero. The remaining five digits must be between O and 9.
The first index value which will be used to place an indicator in the first bit map in Figure 2, can be generated using Table I, which is merely intended to illustrate a suitable hashing ~unction.
TABLE I
IND~X VALUE ACCOUNT NUMBER CORRESPONDING INDEX
1 (4 ~ 5) (2 ~ 4) 0 2 (1, 7 ~ 8) (7 ~ 3 ~ 2) 2 3 (2, 4 & 9) (8 + 2 + 8) 8 (~, 5 & 10) (8 + 4 + 5) 7 ` 5 ~3~ 6 & 11) (7 + 1 + 3) :~ 15 6 (3, 7 & 12) (7 + 3 + O) O
:;
As ~een from Table I above, the first digit is derived ; based upon whether the sum of two digits in the account number is even or odd. In this example, in index digit 1, the two account number digits selected (2, 4~
~ 20 are in the fourth and fifth position. Since 2 plus 4 is ;~' even, the ~irst digit of the index value will be 0.
~: Digit 2 of index 1 is the modulo 10 summation of the account number digits located at positions 1, 7 and 8, namely, 7, 3 and 2. The sum of 7~3~ equals 12, with the modulo 10 sum being 2, such that digit 2 of the index value is 2. Similarlyl digit 3 is the modulo 10 sum of 8+2+8 (positions 2, 4 ~ 9), which is equal to 8.
Therefore, the third digit in the index is 8. The remaining digits are calculated in a similar manner to ~: 30 yield digits 7, 1 and 0. When read together, the index value ~or the account number in Figure 3 is 028170. An indicator will then be placed in the first bit map at the 28,170th bit. If an indicator is already present at '~:
,, . . ' :. . :. ' 2C~
that bit from a previous table entry, no change will be made.
Similar index values are thPn calculated for each of the bit maps present in the master table. In the preferred embodiment with 5 bit maps, another four index values will be generated. A table will be used for each index value that is similar in structure, but different in content to the table illustrated above. The index digits selected for the tables will preferably be as different from each other as possible.
A second table (Table I~) is set forth below as another illu~trative example:
:
,,~
~, ~
` 12~3~4~
I
TABLE II
INDEX VALUE ACCOUNT NUMBER CORRESPONDING INDEX
DIGIT __ POSITIONS _ ACCOUNT DIGITS VALUE
1 (2 & ~ (8 + 1) 2 (4, 5 & 8) (2 + 4 ~ 2) 8 3 (1, 3 & 9) (7 + 7 ~ 8) 2 4 (3, 5 ~ 10) (7 ~ 4 + 5) 6 (2, 7 & 11) (8 + 3 ~ 3) 4 6 (4, 6 ~ 123 (2 + 1 + o) 3 When the account number shown in ~igure 3 (0358-~314-2787) is hashed in accordance with the algorithm of Table II, an index value o* 182,643 is generated. An indicator would then be placed in the 182,643rd bit of the associated bit map.
~y generating a master table in this ~ashion, an indicator will be placed in each bit map for each invalid card. When the table is used to detect an invalid account number (a process described in greater detail below) an indicator must be present in each bit map tested, otherwise the card is known to be valid.
The converse of this statement is not true. More specifically, even if an indicator is present in each bit map, the card might still be valid. As can be appreciated, as more invalid cards are listed in the table, and more indicators are added to the bit map based on the results o* random algorithmic functions, the likelihood that indicators will be present for the index values obtained by hashing any account number will lncrease .
The probability that an unlisted valid account number will be identified as potentially invalid is given by the following formula:
~2~3~4~:0 (2) P = [1 ~ /B)N]M
where P is equal to the probability, B is equal to the number of bits in each map, N is equal to the number of listed account numbers, and M is equal to the number of bit maps. In the arrangement shown herein, where five bit maps are used, each 200,000 bits long, if 200,000 account numbers are listed, the probability of a valid card being identified as potentially invalid would be on the order of 10.1 percent. If the file is reduced to 100,000 account numbers, the probability of identifying a valid card as potentially invalid drops to just below one percent.
The probability of identifying a valid card as ; potentially invalid can be varied by changing the total number of bit maps in the master table. Assuming that the length of the bit map has been adjusted to maximize inPormation content (as discussed above) the probability that a valid account number will be identified as potentially invalid is given by the following equation:
`~'' (3) P = 1/2M
This equation demonstrates that when five bits maps are used, the probability of identifying a valid card as potentially invalid is 1 in 32 or about 3.1 percent. In ~` the illustrated embodiment, where only 100,000 cards are initially listed, the bit maps are not utilizPd to their full information carrying capacity and the probability of identifying a valid card as potentially invalid is just under one percent as noted above.
From a purely statistical analysis, if 100,000 invalid cards are to be listed in a master table one million bits long, seven bit maps should be used. To implement such a master table, a hashing algorithm which ~' 1'~81~0 will randomly distribute information within seven bit maps, each 142,857 bits long, must be created. For practical reasons, five bit maps were selected for this illustration since a sui~able hashing algorithm could be created more readily. Furthermore, while the use of ~ive bit maps instead of seven in the master table will result in an increase in the percentaqe of valid cards that are identified as potentially invalid, this increase is relatively small and not considered unacceptable. Finally, the use o~ five bit maps allows the number of listed account numbers to increase to about 140,000 with the probability of identifying a valid card as potentially invalid increasing to only about 3.25 percent.
The effect of the subject data compression system can be compared with listing the actual account numbers in a memory. For the comparison, the least 12 - significant digits of the account number are selected.
Each 12 digit account number would require 48 bits of memory, assuming four bits per digit in a binary codsd decimal format. In contrast, in the subject system, reasonable operation is achieved when the number of bits ; in the master table is roughly seven to ten times greater than the number o~ invalid account numbers to be listed. This represents a reduction in memory needs by ~ roughly factor of five and balances the competing - factors of limited memory and information content.
In practice, the list of invalid cards used to generate the table can also be trimmed with respect to the geographical location of the invalid cards in a manner similar to that described in the Berstein patent.
However, rather than distributing these reduced lists as called for in the Berstein patent, the lists are used to generate a plurality o~ master tables which are then distributed geographically. In this manner, the total o list of invalid cards, which may exceed one million in the United States alone, can be broken into regional subsets having a length on the order of lO0,000 cards each~ This master table can be one million bits or 125 K-bytes long. 128K dynamic RAM memories are readily available at relatively low cost and can easily store this size master table. More importantly, the reduced size of the master ~iles simplifies and shortens the time necassary to transmit the in~ormation to the terminals.
The transmission of the master table to each individual terminal could be done along the same type of communication lines used to interconnect the terminal and the central processor unit for on-line authorizations. These lines are shown as 50 in Figure 1. In this approach, a communication protocol must be established with each terminal to send the ~ information. In the preferred embodiment of the subject ;` invention, the master table 40 is broadcast over radio waves to the terminal. As shown in Figure 1, the CPU is connected to a transmitter 60. Transmitter 60 generates radio waves which are received by the antenna 72 of :
radio receiver 70 provided in eacb terminal. The information received by the receiver is downloaded into memory in each terminal. Information on radio waves can be readily transmitted at 38,400 bits per second such that the entire one million bit master file could be transmitted in less than one-half a minute. This file could be generated and transmitted once a day so that the most current information on invalid cards is available to the terminals.
If less frequent transmission of the entire master table i~ desired, the table can be updated with additions. For example, if the master table is transmitted weekly, updates could be transmitted on a 14~0 daily basis. In this case, lists of additional invalid cards could be supplied to each terminal. ~ach newly transmitted invalid account number would be hash~d by the individual terminal and indicators would be placed into the bit maps of the master table.
If the system is operated in a manner where a i~ significant number of new entries are typically supplied to the terminal prior to retransmitting an entirely new master table, steps can be taken to reduce the transmission time of the updates. For example, when the table is initially created, each twelve digit account number could be "prehashed" to yield a seven digit number. This seven digit number would then be hashed to create index values in a manner similar to that described above. If the master table is created in this manner, only the seven digit, prehashed account numbers, rather than the full twelve digit numbers, would have to be supplied to the transaction terminals when the master table is updated. This approach would shorten transmission time by almost one-half.
`~ It should be noted that while individual account ;~ numbers can be added to the master table, individual ;;~ account numbers cannot be deleted~ As can be appreciated, any time a file i5 created by data ~5 compression, there will be duplicakes or overlapping entries. Therefore, even if a particular card has regained valid status (or the listing period has expired), the indicators could not be safely removed from the file without unintentionally destroying other meaningful data.
Effective deletion of account numbers can only be achieved by transmitting a newly generated master file.
Transmi~sion of a new master file should occur before the number of account numbers listed in the file, as increased by updates, reaches a level where an :, ~z~
unacceptable percentage of valid cards are being identi~ied potentially invalid.
Having described the generation and transmission of the master table to the transaction terminals, the use of the master table at the transaction terminal will now be discussed with reference to the flow chart of Figure 4. At the time of a purchase, a cardholder will present his transaction card to a merchant. The account number of the card is then supplied to the transaction terminal, as shown in step lO0 in Fiyure 4. The processor in the transaction terminal can then generate index values for each bit map in a manner exactly e~livalent to the algorithms used to generate the master table.
Assuming the hashing system described above has been us~d to create the master table, the first digit of the first index value will be defined by whether the sum ~; of digits in positions 4 and 5 are odd or even. The remaining five digits of the first index value will be the modulo sum of each group of three sel~cted digits.
After the first index value is generated (step 102), the processor will look into the first bit map of the master table to determine if an indicator has been placed at ~- the location defined by the index value~step 104). If there is no indica~or at that location in the first bit map, the analysis is complete and the transaction can be allowed to continue (step 106).
Step 106 is intended to represent the next set of steps to which the transaction would normally be subjected. For example, the transaction amount could be compared to a dollar limit stored either on the card as risk assessment data or in the terminal. If the ; transaction falls below that dollar limit it could be automatically approved right at the terminal. If the transaction limit is above that amount, the transaction ; information may still be sent on to the central processor for further analysis.
If an indicator is present in the first bit map, the analysis will continue for each remaining bit map.
The processor will first determine if there are any bit maps remaining that have not been tested (step 107~. If there are any bit maps remaining, the processor will ~ generate the index value for the next bit map in step ; 108. The processor will check to determine if an indicator has been placed in the next bit map of the ~-~ master table at the location defined by the newly generated index value (step 104~. As noted above, if no indicator is present at that location, the card is known to be valid and the transaction can proceed. (step 106) If indicators are present in all of the bit maps, ~i.e. there are no more bit maps left to test and therefore the answer to decision step 107 is "no") there is a possibility that the card is invalid and the information must be routed for further processing as shown in step 110. In this step, an on-line connection can be established to the central processor 30. The transaction information is transmitted to the central processor where it can be further analyzed. The analysis can be made at the central processor if the list of all invalid cards is stored at that location.
In the alternative, where the invalid card lists are ~ stored at the issuers 10, the transaction can be `~ rerouted for further analysis at the issuer. If the card is, indeed, invalid, a return message can be given to the terminal to decline the transaction. If, however, the card is valid, the transaction can be approved.
1 As discussed above, the subject system provides a master table with a large amount of information held in a ~mall space. This approach de~cribed herein, however, , 4~:~
has an additional advantage. More specifically, in ~ order to check any card against the master file, there ;~ is no need to go through the entire table. In the system described in U.S. Patent No. 3,696,335, where the list of actual account numbers is supplied to the terminal, the account number is compaxed to sach of the - numbers in the list in order to determine if the card is listed. Even if more sophisticated binary searching algorithms are used (where lists are arranged in numeric order), a number of comparisons are still necessary. In contrast, in the subject syskem, only the location in the bit map corresponding to the index value must be checked to determine if an indicator is present. The entire bit map does not have to be reviewed. In a master table having five bit maps, a determination can be made as to whether an account number is present in a universe of 100,000 invalid cards simply by looking at five locations in the master table. I~ any indicator is missing, the card is known to be valid.
In summary, there has been provided a new and improved system ~or distributing in~ormation about invalid transaction cards. In this system, a master ~ file is created containing less than the entire account ;; number of the cards. The master file consists of at ~; 25 least one bit map having indicators corresponding to invalid cards. The location o~ each indicator is determined by hashing the account numbers to produce an index value which is then used as an address for supplying the indicator to the bit map. Once indicators have besn placed in all the bit maps of the master table for all the invalid account numbers, the master table is then transmitted to the transaction terminals. The transaction terminals which the information in the master table to analyze pending transactions. The information in the table is arranged such that if a 2~ ;
potentially invalid card is presented, a signal will be generated which will cause the transaction to be passed onto the central processor for further analysis. In the preferred embodiment, the table is arranged such that the probability of a valid card being identified as potentially invalid is less than ten percent and preferably on the order of one to three percent. In this manner, only a small percentage of valid transactions will be transmitted to the central processor for further analysis as a result of this scheme.
While the subject invention has been dsscribed with reference to preferred embodiments, it is apparent that other changes and modifications could be made therein by one skilled in the art without varying from the scope and spirit of the subject invention as defined by the appended claims.
TRANSACTION APPROVAI SYSTEM
Technical F_eld The subject invention relates to a financial transaction network. The invention includes an improved system for distributing information about invalid transaction cards.
Back~E~und of the Invention In the last fifteen years the use of transaction cards as substitutes for cash has greatly expanded.
Along with this expanded use has come an increase in losses due to fraud. One of the most costly problems is caused by the use of invalid cards. The term invalid card includes those cards which have been lost or stolen. The term can also include cards whose credit limits have been exceeded by the holder. Significant efforts have been made to minimize the use and abuse of invalid cards.
One of the earliest approaches used to combat this fraud was to distribute a printed list of invalid cards.
One such list is called the Card Recovery Bulletin or CRB. In use, the merchant checks the account number on - the card presented for the transaction with the account numbers printed in the CRB. If the account number is listed, the transaction would be declined.
This use of the CRB is effective in reducing a large percentage of fraud losses. Unfortunately, this approach has a few drawbacks. For example, a transaction card is often used almost immediately after it has been lost or stolen. This immediate use will occur before the card has been listed in the bulletin or before the bulletin has been distributed. Another problem with this approach is that from a practioal '~
.
~8~4~0 standpoint, it is often difficult to insure that store clerks use the list properly or at all.
Because of these difficulties, many other more sophisticated approaches have been taken. One of the most effective schemes is to authorize every transaction through a real-time, on-line communications network.
For example, the merchant can report the account number of the card presented for a transaction to a central processor by telephone. The account number on the card can then be checked against a current list of invalid card numbers stored either at the central processor or back at the card issuer. In another variation on this scheme, a transaction terminal is provided with a card reader which reads a magnetic stripe encoded with an account number. The terminal can then automatically ; transmit the account number to the central processor for approval.
This on-line scheme eliminates the lay time inherent in using the Card Recovery Bullatin.
Unfortunately, a fully on-line system turns out to be prohibitively expensive and prone to communication delays. An on-line approach also does not provide any protection when the network is down.
More recently, many approaches have been taken to reduce transaction approval costs while also controlling fraud losses. As microprocessors become smaller, cheaper and faster, some of the transactional analysis can be performed at the terminal itself. Efforts have been made to develop screening procedures that avoid having to transmit the transaction information to the central processor. For example, the transaction terminal can be programmed to authorize every transaction below a certain dollar limit or floor limit.
In this mannar, the cost of communication can be balanced against the risk of loss.
;~
~ -3 ~ 14X~ 26469-26 The terminal may also be provided with the capability to verify a cardholder secret personal identification number or PIN.
In this scenario, a version of -the PIN is encoded onto the magnetic stripe on the card and read by the terminal. The terminal then compares the PIN read from the card with a PIN
entered into a keypad on the terminal by the cardholder. If the two PINs match, the transaction can be approved. The use of PINs sharply reduces the fraudulent use of lost or stolen cards.
A more sophisticated approach is described in Canadian Patent 1,252,566, assigned to the same assignee as the subject invention. In that patent, a system is described wherein risk assessment data is encoded onto the card by the card issuer. This risk assessment data is tailored to define the credit worthiness of each specific cardholder. This risk assessment data can be analyzed by the transaction terminal and if the transaction amount falls within the parameters encoded on the card by the issuer, the transaction can be automatically approved. If the transaction - amount exceeds these parameters, the transaction information is routed on to the central processor for further analysis.
As the cost of computer memory space has decreased, the idea~of storing the account numbers of invalid cards in each transaction terminal has been explored. If this scheme were implemented, the account number of the card being presented for the transaction could be automatically compared at the terminal.
One prior art system which utilized this approach is described in U. S. Patent No. 3,696,335, issued October 3, 1972 to Lemelson.
42~
The approach illustrated in the Lemelson patent has been deemed impractical for a number oE reasons. More specifically, in order to keep the lists current, they would have to distributed to the terminals and updated on a frequent basis. With the number of transaction terminals rapidly expanding, it would be virtually impossible to physically transfer this data to the terminals on a routine basis. Therefore, distribution of tha list of invalid account numbers must be through some type of communication link. Unfortunately, the lists of invalid cards are so large for the major transaction card systems that on-line distribution becomes quite difficult. However, if some way could be developed to distribute the list in an efficient manner, this approach could be very effective in reducing both communication costs and fraud losses.
One technique for attaining this goal is described in U.S. Patent No. ~,~58,211, issued December 10, 1985 to Berstein. This disclosure acknowledges that a complete "hot card" list would be too large to transmit to each transaction terminal. ~he solution proposed in the latter patent is to add an identi~ier to each listed hot card which indicates the geographical location in which the card is most likely to be used. Subsets of the hot card list geared to speci~ic geographical locations can then be generated. The greatly shortened lists can then be dis~ribu~ed to the terminals and stored. The patent suggests that a standard 4K byts memory in a terminal could hold a list of 800 invalid cards. Since most invalid cards are used in the area where they were lost or stolen, this approach could be very effective as long as only 800 invalid cards exist ; in any geographical area.
Unfortunately, major transaction card companies ; 35 will typically have over one million invalid cards ~2~ 2~3 listed on any given day in the United States alone.
Even when these lists are broken down geographically, the size of the smallest list does not fall much below 100,000 cards. Obviously, if the geographical area i9 made too small, the effectiveness of the system will be reduced since it will be limited to catching an unauthorized user only at the exact location the card was lost or stolen.
- Accordingly, it is the object of the subject invention to provide a new system for distributing information about invalid cards.
It is another object of the subject invention to provide a new system for distributin~ lists of invalid cards which can be used to authorize transactions at a ~ 15 transaction terminal.
`~ It is a further object of the subject invention to provide a new system far distributing lists of invalid cards in a cost effective manner.
It is still another object of the subject invention ; 20 to provide a new system for rapidly distributing lists ; of invalid cards in an on-line manner.
It is still a further object of the subject invention to provide a new data file containing information about invalid cards that takes up very little memory space.
It is still another object of the subject invention to provide a compressed data file that can be easily transmitted to remote transaction terminals.
It is still a further object of th subject inventian to proved a compressed data file which will ~; always indicate when an invalid card has been presented ~ and wherein the probability of identifying a valid card ; as a potentially invalid card is on the order of one to three percent.
.~
~' ~`
. - ,............. .
42~
It is still another object of the subject invention to provide a hot card authorization system that can easily be implemented in current microprocessor based remote transaction terminals.
It is still a further object of the subject invention to provide a compressed data file with information on an invalid transaction that is arranged in a manner such that the entire file does not have to be searched in order to determine if a particular account number is invalid.
SUMMARY OF THE INVENTION
In accordance with these and many other objects, the subject invention provides for a method for generating and distributing a master table containing infor~ation about invalid cards. A unique data compression method is used to substantially reduce the amount of memory needed to hold the master table. By reducing the size of the file, the downloading of the information to local transaction terminals is greatly facilitated.
The information contained in the master file is less than the actual account numbers of the invalid cards. Nonetheless, the data is so arranged that if an invalid card is presented to a transaction terminal, it will always be identified as requiring further analysis prior to approval. If the card is so identified, the account information can then be transmitted to a central pxocessor for final confirmation against a complete invalid card list. Conversely, if an account number is tested against the master file at the transaction terminal and is cleared, the transaction can safely be approved off-line since this result insures that the account number is not listed in the invalid card file.
~\
~.X8~4~3 Because of the characteristics of the data compression system of the subject invention, a certain percentage of valid cards which are presented will be identified as potentially invalid. In such cases, the information about the transaction will be passed on to the central processor for absolute verification. The probability of a valid card being identified as potentially invalid can be adjusted by varying the characteristics of the master table. The probability of a valid card being identified as potentially invalid should be less than ten percent and preferably on the order of one to three percent. Since many transactions ara transferred to the central processor for other reasons ~i.e. high dollar amount transactions which exceed the floor limit o~ the terminal), the fact that a small percentage of transactions are sent to the central processor under this scheme will have an insignificant impact on overall system performance.
; The master table is defined by a plurality of bit maps. As discussed in detail below, by using a plurality of bit maps in the master table instead of just one, the probability of a valid card being identified as potentially invalid can be reduced.
Conversely, as the number of bit maps is increased, ~5 processing time is also increased.
Each of the bit maps in the table is B bits in length. Information about the invalid cards is represented by indicators within the bit map. In order to set the indicators~ the account number of the invalid card is subjected to an algorithmic function to generate an index value betwsen zero and the number of bits in the bit map. When this value is obtained, an indicator is placed in the location in the bit map corresponding to the index value that is generated. In the illustrated embodiment, where five bit maps are used, ` ~81.~2~
the account number is subjected to five di~ferent algorithmic procedures to generate five different index values, each of which is used to place an indicator in one of the five bit maps.
The algorithm used to generate an index value may be relatively sophisticated, such as the data encryption standard (DES). For ~reater speed and simplicity, select~d digits of the account number can be mixed and added to generate an index value. The process of lo mathematically reducing the information content in a data stream is typically called "hashing'l.
The selected hashing procedures are repeated for each of the invalid cards on the list. When the table is complete, it is distri~uted to the transaction terminals. In the preferred embodiment, this list is downloaded by radio transmission to all terminals simultaneouslyO This list can be downloaded through any other suitable type of communication link.
In operation, the account number of the card presented for the transaction is read into the terminal.
The terminal then performs the same algorithmic steps, or, hashing on the new account number that was done to create the table in the first place~ An index value is generated for each bit map. The transaction terminal then determines if an indicator is present in each bit map in the master table corresponding to each of the newly generated index values. I~ any hit map does not contain an indiaator, then the card is immediately known to be valid and the transaction may be approved off-line. If the comparison reveals that the indicator~ are present in every bit map, then there is a possibility that an invalid card has been presented. In this case, some form of ~urther processing will be required. At that point, the transaction may be routed to the cantral processor for an absolute comparison of the account ~' , :
.
1~8~
_9_ numbers against the entire list of invalid cards. If the transaction system happens to be down, a message may be relayed to the operator that the account number should be checked against a printed list. As pointed out above, the terminal will identify some small percentage of valid cards as potentially invalid but the results of further processing will indicate that those cards so identified are in fact valid and that the transaction should proceed.
It is estimated that a master table generated with the subject data compression system will be one-fourth to one-sixth the length of a list of actual invalid account numbers. This shorter file can be more easily transmitted and stored. Another advantage to this approach is that the entire table does not have to be scanned to determine if a card is valid. The index values are used to pinpoint specific locations in the table. As soon as such a location is encountered in which no indicator is present, the card in question is immediately known to be valid.
, BRIEF DESCRLPTION OF THE DRAWINGS
Figure 1 is a schematic diagram illustrating a transaction network where the method of the subject invention can be implemented.
Figure 2 is a representation of a master table having five bit maps.
Figure 3 is a representation of the last 12 digits of an invalid account number.
Figure 4 is a flow chart illustrating the steps taken at the transaction terminal in accordance with the subject invention.
, , ~ , ,, ' : :. . . ::
42~
; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Referring to Figure 1, there is illustrated a transaction network in which the subjact invention may be implemented. As shown in Figure 1, a transaction network typically will include one or more issuers 10 of transaction cards. The transaction cards are distributed to customers and will include an account number identifying the cardholder. The cards are presented to merchants for yoods and ser~ices in lieu of cash.
The transaction is frequently authorized through the use of transaction terminals 20. There are a large number of transaction terminals publically available and therefore they will not be described in detail herein.
The current state of the art transaction terminal ; typically includes a card reader for reading account information and other data from the magnetic stripe on the transaction card. The terminal can also be provided with the ability to automatically dial and make an on-line connection to a computer located either at a merchant bank, a network switch or to one of the card issuers. For the purposes of this disclosure, block 30, labelled "CPU," is inkended to correspond to a central ; processing unit having higher l vel decision-making authority. For example, the central processing unit 30 can have stored therein a full list of invalid cards 32 which may be consulted to determine if the transaction should be approved.
~ As discussed above, the transaction terminal 20 may ; 30 be provided with the ability to perform some transactional analysis without connection to the main CPU 30. To carry out these functions, the terminals will include a microprocessor, dedicated ROMs, random access memories, a keypad and display. In order to .~
4'~
perform the subject invenkion, some dynamic memory space must ba allocated for holding the master table 40. In addition, a program must be provided for analyzing the account number presented with the data in the master table. The programming of a terminal to perform these functions is well within the abilities of one skilled in the software development art.
In accordance with the subject invention, the terminal 20 is capable o~ determining whether a card, presented for a transaction, is likely to be invalid.
This result was achieved in the above cited U.S.
Patents. In the prior art systems, actual invalid account numbers axe supplied to each transaction terminal. The account number of the card presented is compared to the account numbers listed in the memory to determine if the transaction should be approved. In contrast, in the subject invention, a master table containing information less than the invalid account ~-numbers is generated and supplied to the terminals. In this manner, meaningful data can be stored in less space. In addition, only precise locations in the table are searched to determine if the card is invalid.
;In accordance with the subject invention, the A~information on the invalid cards is contained in a master table 40 generated at the central processor 30.
An example of a master table 40 is shown in detail in Fiyure 2. ~he mastar table consists of at least one bit map of B bits in length. Preferably, a plurality of bit maps are used. As will be seen below, by using a plurality of bit maps in the master table instead of just one, the probability of a valid card being identified as potentially invalid is decreased. In the illustrated embodiment of Figure 2, five bit maps are used.
~L2~ 2C3 When selecting the length of the bit map, consideration should be given to maximizing khe information content within the map. From a statistical analysis, it can be shown that greatest information content in a bit map occurs when roughly half the bits are zero and half the bits are one. Assuming that the algorithmic functions used to generate the table provide results with pseudo-random characteristics, the fraction of bits in a bit map which are zero is given by the following equation:
(1~ Z = [1 - (~/B)]
where Z is the ~raction, B is the number of bits in the map and N is the number of invalid cards listed. Where each bit map is 200,000 bits in length, a distribution profile where half the bits are zero and half the bits are one (Z = 0.5) would occur when about 138,000 account numbers are listed. In the illustrated embodiment, where roughly 100,000 cards are initially listed, the probability of any bit being a one is on the order of 0.4. In operation, as account numbers are added to the mastsr table through an update procedure discussed below, the information content in the bit map will increase as the probability increases to 0.~.
In order to generate the table, the account numbers of the invalid cards are "hashed" to derive compressed data. An account number can be hashed by encrypting the numbQr using the data encryption standard (DES) and a secret key. The resulting number can be truncated to an index value between zero and B-l. An indicator, (for example, a "one" if all the bits are originally set to "zero") can then be placed in the bit map at the location corresponding to the index value which has been generated by the algorithmic function. If more than one , , ~128~
bit map is used, the account number could be encrypted again, using a different key. The result is truncated to obtain another index value which will be used to place an indicator in the second bit map. This process would be repeated, encrypting the account number one time for each bit map present in the master table. Each invalid card would then have one indicator in each of the bit maps. Similar steps would be performed for each invalid card, and indicators would be added into the table. If an indicator was already located at an index value ~rom a previous card, this indicator would remain unchanged.
While the data encryption standard (DES) provides a method of hashing account numbers which has suitable pseudo-random characteristics, it is also time-consuming and complex. In the illustrated embodiment, a simpler and faster hashing algorithm is described which has an acceptable degree of pseudo-random characteristics. In ~` this context, a pseudo-random algorithmic function will insure that any index value generated from the account number will have an equal probability of lying anywhere in the bit map. Furthermore, *he results of the algorithmic function used with one bit map should not corraspond in any way to the results of the algorithmic function used to generate a different bit map.
In the illustrated embodiment, these factors are balanced by selecting and combining small groups of digits in the account number to create index values.
This approach can best be understood by referring to Figure 3 and the tables below. Figure 3 illustrates the last 12 digits of an account number 0358-2314-2787. The position of these digits has been labelled 1 to 12, from right to left. Where the bit map has 200,000 entries, index values between 0 and 199,999 must be generated~
The most significant digit of that six-digit index value 4~0 must be either a one or a zero. The remaining five digits must be between O and 9.
The first index value which will be used to place an indicator in the first bit map in Figure 2, can be generated using Table I, which is merely intended to illustrate a suitable hashing ~unction.
TABLE I
IND~X VALUE ACCOUNT NUMBER CORRESPONDING INDEX
1 (4 ~ 5) (2 ~ 4) 0 2 (1, 7 ~ 8) (7 ~ 3 ~ 2) 2 3 (2, 4 & 9) (8 + 2 + 8) 8 (~, 5 & 10) (8 + 4 + 5) 7 ` 5 ~3~ 6 & 11) (7 + 1 + 3) :~ 15 6 (3, 7 & 12) (7 + 3 + O) O
:;
As ~een from Table I above, the first digit is derived ; based upon whether the sum of two digits in the account number is even or odd. In this example, in index digit 1, the two account number digits selected (2, 4~
~ 20 are in the fourth and fifth position. Since 2 plus 4 is ;~' even, the ~irst digit of the index value will be 0.
~: Digit 2 of index 1 is the modulo 10 summation of the account number digits located at positions 1, 7 and 8, namely, 7, 3 and 2. The sum of 7~3~ equals 12, with the modulo 10 sum being 2, such that digit 2 of the index value is 2. Similarlyl digit 3 is the modulo 10 sum of 8+2+8 (positions 2, 4 ~ 9), which is equal to 8.
Therefore, the third digit in the index is 8. The remaining digits are calculated in a similar manner to ~: 30 yield digits 7, 1 and 0. When read together, the index value ~or the account number in Figure 3 is 028170. An indicator will then be placed in the first bit map at the 28,170th bit. If an indicator is already present at '~:
,, . . ' :. . :. ' 2C~
that bit from a previous table entry, no change will be made.
Similar index values are thPn calculated for each of the bit maps present in the master table. In the preferred embodiment with 5 bit maps, another four index values will be generated. A table will be used for each index value that is similar in structure, but different in content to the table illustrated above. The index digits selected for the tables will preferably be as different from each other as possible.
A second table (Table I~) is set forth below as another illu~trative example:
:
,,~
~, ~
` 12~3~4~
I
TABLE II
INDEX VALUE ACCOUNT NUMBER CORRESPONDING INDEX
DIGIT __ POSITIONS _ ACCOUNT DIGITS VALUE
1 (2 & ~ (8 + 1) 2 (4, 5 & 8) (2 + 4 ~ 2) 8 3 (1, 3 & 9) (7 + 7 ~ 8) 2 4 (3, 5 ~ 10) (7 ~ 4 + 5) 6 (2, 7 & 11) (8 + 3 ~ 3) 4 6 (4, 6 ~ 123 (2 + 1 + o) 3 When the account number shown in ~igure 3 (0358-~314-2787) is hashed in accordance with the algorithm of Table II, an index value o* 182,643 is generated. An indicator would then be placed in the 182,643rd bit of the associated bit map.
~y generating a master table in this ~ashion, an indicator will be placed in each bit map for each invalid card. When the table is used to detect an invalid account number (a process described in greater detail below) an indicator must be present in each bit map tested, otherwise the card is known to be valid.
The converse of this statement is not true. More specifically, even if an indicator is present in each bit map, the card might still be valid. As can be appreciated, as more invalid cards are listed in the table, and more indicators are added to the bit map based on the results o* random algorithmic functions, the likelihood that indicators will be present for the index values obtained by hashing any account number will lncrease .
The probability that an unlisted valid account number will be identified as potentially invalid is given by the following formula:
~2~3~4~:0 (2) P = [1 ~ /B)N]M
where P is equal to the probability, B is equal to the number of bits in each map, N is equal to the number of listed account numbers, and M is equal to the number of bit maps. In the arrangement shown herein, where five bit maps are used, each 200,000 bits long, if 200,000 account numbers are listed, the probability of a valid card being identified as potentially invalid would be on the order of 10.1 percent. If the file is reduced to 100,000 account numbers, the probability of identifying a valid card as potentially invalid drops to just below one percent.
The probability of identifying a valid card as ; potentially invalid can be varied by changing the total number of bit maps in the master table. Assuming that the length of the bit map has been adjusted to maximize inPormation content (as discussed above) the probability that a valid account number will be identified as potentially invalid is given by the following equation:
`~'' (3) P = 1/2M
This equation demonstrates that when five bits maps are used, the probability of identifying a valid card as potentially invalid is 1 in 32 or about 3.1 percent. In ~` the illustrated embodiment, where only 100,000 cards are initially listed, the bit maps are not utilizPd to their full information carrying capacity and the probability of identifying a valid card as potentially invalid is just under one percent as noted above.
From a purely statistical analysis, if 100,000 invalid cards are to be listed in a master table one million bits long, seven bit maps should be used. To implement such a master table, a hashing algorithm which ~' 1'~81~0 will randomly distribute information within seven bit maps, each 142,857 bits long, must be created. For practical reasons, five bit maps were selected for this illustration since a sui~able hashing algorithm could be created more readily. Furthermore, while the use of ~ive bit maps instead of seven in the master table will result in an increase in the percentaqe of valid cards that are identified as potentially invalid, this increase is relatively small and not considered unacceptable. Finally, the use o~ five bit maps allows the number of listed account numbers to increase to about 140,000 with the probability of identifying a valid card as potentially invalid increasing to only about 3.25 percent.
The effect of the subject data compression system can be compared with listing the actual account numbers in a memory. For the comparison, the least 12 - significant digits of the account number are selected.
Each 12 digit account number would require 48 bits of memory, assuming four bits per digit in a binary codsd decimal format. In contrast, in the subject system, reasonable operation is achieved when the number of bits ; in the master table is roughly seven to ten times greater than the number o~ invalid account numbers to be listed. This represents a reduction in memory needs by ~ roughly factor of five and balances the competing - factors of limited memory and information content.
In practice, the list of invalid cards used to generate the table can also be trimmed with respect to the geographical location of the invalid cards in a manner similar to that described in the Berstein patent.
However, rather than distributing these reduced lists as called for in the Berstein patent, the lists are used to generate a plurality o~ master tables which are then distributed geographically. In this manner, the total o list of invalid cards, which may exceed one million in the United States alone, can be broken into regional subsets having a length on the order of lO0,000 cards each~ This master table can be one million bits or 125 K-bytes long. 128K dynamic RAM memories are readily available at relatively low cost and can easily store this size master table. More importantly, the reduced size of the master ~iles simplifies and shortens the time necassary to transmit the in~ormation to the terminals.
The transmission of the master table to each individual terminal could be done along the same type of communication lines used to interconnect the terminal and the central processor unit for on-line authorizations. These lines are shown as 50 in Figure 1. In this approach, a communication protocol must be established with each terminal to send the ~ information. In the preferred embodiment of the subject ;` invention, the master table 40 is broadcast over radio waves to the terminal. As shown in Figure 1, the CPU is connected to a transmitter 60. Transmitter 60 generates radio waves which are received by the antenna 72 of :
radio receiver 70 provided in eacb terminal. The information received by the receiver is downloaded into memory in each terminal. Information on radio waves can be readily transmitted at 38,400 bits per second such that the entire one million bit master file could be transmitted in less than one-half a minute. This file could be generated and transmitted once a day so that the most current information on invalid cards is available to the terminals.
If less frequent transmission of the entire master table i~ desired, the table can be updated with additions. For example, if the master table is transmitted weekly, updates could be transmitted on a 14~0 daily basis. In this case, lists of additional invalid cards could be supplied to each terminal. ~ach newly transmitted invalid account number would be hash~d by the individual terminal and indicators would be placed into the bit maps of the master table.
If the system is operated in a manner where a i~ significant number of new entries are typically supplied to the terminal prior to retransmitting an entirely new master table, steps can be taken to reduce the transmission time of the updates. For example, when the table is initially created, each twelve digit account number could be "prehashed" to yield a seven digit number. This seven digit number would then be hashed to create index values in a manner similar to that described above. If the master table is created in this manner, only the seven digit, prehashed account numbers, rather than the full twelve digit numbers, would have to be supplied to the transaction terminals when the master table is updated. This approach would shorten transmission time by almost one-half.
`~ It should be noted that while individual account ;~ numbers can be added to the master table, individual ;;~ account numbers cannot be deleted~ As can be appreciated, any time a file i5 created by data ~5 compression, there will be duplicakes or overlapping entries. Therefore, even if a particular card has regained valid status (or the listing period has expired), the indicators could not be safely removed from the file without unintentionally destroying other meaningful data.
Effective deletion of account numbers can only be achieved by transmitting a newly generated master file.
Transmi~sion of a new master file should occur before the number of account numbers listed in the file, as increased by updates, reaches a level where an :, ~z~
unacceptable percentage of valid cards are being identi~ied potentially invalid.
Having described the generation and transmission of the master table to the transaction terminals, the use of the master table at the transaction terminal will now be discussed with reference to the flow chart of Figure 4. At the time of a purchase, a cardholder will present his transaction card to a merchant. The account number of the card is then supplied to the transaction terminal, as shown in step lO0 in Fiyure 4. The processor in the transaction terminal can then generate index values for each bit map in a manner exactly e~livalent to the algorithms used to generate the master table.
Assuming the hashing system described above has been us~d to create the master table, the first digit of the first index value will be defined by whether the sum ~; of digits in positions 4 and 5 are odd or even. The remaining five digits of the first index value will be the modulo sum of each group of three sel~cted digits.
After the first index value is generated (step 102), the processor will look into the first bit map of the master table to determine if an indicator has been placed at ~- the location defined by the index value~step 104). If there is no indica~or at that location in the first bit map, the analysis is complete and the transaction can be allowed to continue (step 106).
Step 106 is intended to represent the next set of steps to which the transaction would normally be subjected. For example, the transaction amount could be compared to a dollar limit stored either on the card as risk assessment data or in the terminal. If the ; transaction falls below that dollar limit it could be automatically approved right at the terminal. If the transaction limit is above that amount, the transaction ; information may still be sent on to the central processor for further analysis.
If an indicator is present in the first bit map, the analysis will continue for each remaining bit map.
The processor will first determine if there are any bit maps remaining that have not been tested (step 107~. If there are any bit maps remaining, the processor will ~ generate the index value for the next bit map in step ; 108. The processor will check to determine if an indicator has been placed in the next bit map of the ~-~ master table at the location defined by the newly generated index value (step 104~. As noted above, if no indicator is present at that location, the card is known to be valid and the transaction can proceed. (step 106) If indicators are present in all of the bit maps, ~i.e. there are no more bit maps left to test and therefore the answer to decision step 107 is "no") there is a possibility that the card is invalid and the information must be routed for further processing as shown in step 110. In this step, an on-line connection can be established to the central processor 30. The transaction information is transmitted to the central processor where it can be further analyzed. The analysis can be made at the central processor if the list of all invalid cards is stored at that location.
In the alternative, where the invalid card lists are ~ stored at the issuers 10, the transaction can be `~ rerouted for further analysis at the issuer. If the card is, indeed, invalid, a return message can be given to the terminal to decline the transaction. If, however, the card is valid, the transaction can be approved.
1 As discussed above, the subject system provides a master table with a large amount of information held in a ~mall space. This approach de~cribed herein, however, , 4~:~
has an additional advantage. More specifically, in ~ order to check any card against the master file, there ;~ is no need to go through the entire table. In the system described in U.S. Patent No. 3,696,335, where the list of actual account numbers is supplied to the terminal, the account number is compaxed to sach of the - numbers in the list in order to determine if the card is listed. Even if more sophisticated binary searching algorithms are used (where lists are arranged in numeric order), a number of comparisons are still necessary. In contrast, in the subject syskem, only the location in the bit map corresponding to the index value must be checked to determine if an indicator is present. The entire bit map does not have to be reviewed. In a master table having five bit maps, a determination can be made as to whether an account number is present in a universe of 100,000 invalid cards simply by looking at five locations in the master table. I~ any indicator is missing, the card is known to be valid.
In summary, there has been provided a new and improved system ~or distributing in~ormation about invalid transaction cards. In this system, a master ~ file is created containing less than the entire account ;; number of the cards. The master file consists of at ~; 25 least one bit map having indicators corresponding to invalid cards. The location o~ each indicator is determined by hashing the account numbers to produce an index value which is then used as an address for supplying the indicator to the bit map. Once indicators have besn placed in all the bit maps of the master table for all the invalid account numbers, the master table is then transmitted to the transaction terminals. The transaction terminals which the information in the master table to analyze pending transactions. The information in the table is arranged such that if a 2~ ;
potentially invalid card is presented, a signal will be generated which will cause the transaction to be passed onto the central processor for further analysis. In the preferred embodiment, the table is arranged such that the probability of a valid card being identified as potentially invalid is less than ten percent and preferably on the order of one to three percent. In this manner, only a small percentage of valid transactions will be transmitted to the central processor for further analysis as a result of this scheme.
While the subject invention has been dsscribed with reference to preferred embodiments, it is apparent that other changes and modifications could be made therein by one skilled in the art without varying from the scope and spirit of the subject invention as defined by the appended claims.
Claims (29)
1. In a transaction network including a central processor, a plurality of transaction terminals and a plurality of transaction cards, each card having an account number associated therewith, a method for identifying invalid cards comprising the steps of:
a) generating a master table at said central processor, said table including at least a first bit map B bits in length;
b) selecting a set of digits from the account number of a first invalid transaction card;
c) calculating a first index value which is an algorithmic function of said set of digits, said first index value being between zero and B-1;
d) placing an indicator within said first bit map corresponding to said first index value;
e) repeating steps b though d for each invalid card; and f) supplying the master table to each transaction terminal whereby during a transaction, the transaction terminal determines if an indicator exists in the master table corresponding to the account number of the card presented for the transaction.
a) generating a master table at said central processor, said table including at least a first bit map B bits in length;
b) selecting a set of digits from the account number of a first invalid transaction card;
c) calculating a first index value which is an algorithmic function of said set of digits, said first index value being between zero and B-1;
d) placing an indicator within said first bit map corresponding to said first index value;
e) repeating steps b though d for each invalid card; and f) supplying the master table to each transaction terminal whereby during a transaction, the transaction terminal determines if an indicator exists in the master table corresponding to the account number of the card presented for the transaction.
2. A transaction network as recited in claim 1 further including the steps at the transaction terminal of:
repeating steps b and c for the account number of the card presented to generate a first index value;
determining if an indicator is present in the first bit map at a location corresponding to the generated first index value.
repeating steps b and c for the account number of the card presented to generate a first index value;
determining if an indicator is present in the first bit map at a location corresponding to the generated first index value.
3. A transaction network as recited in claim 2 further including the steps at the transaction terminal of:
allowing the transaction to continue unless an indicator is present whereupon the transaction is subjected to further verification.
allowing the transaction to continue unless an indicator is present whereupon the transaction is subjected to further verification.
4. In a transaction network including a central processor, a plurality of transaction terminals and a plurality of transaction cards, each card having an account number associated therewith, a method for identifying invalid cards comprising the steps of:
a) generating a master table at said central processor, said table including a plurality of bit maps, each map being B bits in length;
b) selecting a set of digits from the account number of a first invalid transaction card;
c) calculating a first index value which is an algorithmic function of said set of digits, said first index value being between zero and B-1;
d) placing an indicator within one of said bit maps, said indicator corresponding to said first index value;
e) repeating steps b and c for each bit map in said master table, each time selecting a unique set of digits from the account number and placing an indicator corresponding to each calculated value in the associated bit map:
f) repeating steps b though e for each invalid card; and g) supplying the master table to each transaction terminal whereby during a transaction, the transaction terminal determines if an indicator exists in the master table corresponding to the account number of the card presented for the transaction.
a) generating a master table at said central processor, said table including a plurality of bit maps, each map being B bits in length;
b) selecting a set of digits from the account number of a first invalid transaction card;
c) calculating a first index value which is an algorithmic function of said set of digits, said first index value being between zero and B-1;
d) placing an indicator within one of said bit maps, said indicator corresponding to said first index value;
e) repeating steps b and c for each bit map in said master table, each time selecting a unique set of digits from the account number and placing an indicator corresponding to each calculated value in the associated bit map:
f) repeating steps b though e for each invalid card; and g) supplying the master table to each transaction terminal whereby during a transaction, the transaction terminal determines if an indicator exists in the master table corresponding to the account number of the card presented for the transaction.
5. A transaction network as recited in claim 4 further including the steps at the transaction terminal of:
repeating steps b and c for each bit map for the account number of the card presented to generate a plurality of values;
determining if indicators are present in each bit map corresponding to the generated values.
repeating steps b and c for each bit map for the account number of the card presented to generate a plurality of values;
determining if indicators are present in each bit map corresponding to the generated values.
6. A transaction network as recited in claim 5 further including the steps at the transaction terminal of:
allowing the transaction to continue unless an indicator is present in each bit map whereupon the transaction is subjected to further verification.
allowing the transaction to continue unless an indicator is present in each bit map whereupon the transaction is subjected to further verification.
7. In a transaction network including a central processor, a plurality of transaction terminals and a plurality of transaction cards, each card having an account number associated therewith, a method for identifying invalid cards comprising the steps of:
a) generating a master table at said central processor, said table including data derived from a list of invalid transaction cards, said data being less than the entire account number of each card and including at least one indicator for each invalid card; and b) supplying the master table to each transaction terminal whereby during a transaction, the transaction terminal determines if an indicator exists in the master table for the account number of the card presented for the transaction and allowing the transaction to continue unless an indicator is present whereupon the transaction will be subjected to further verification.
a) generating a master table at said central processor, said table including data derived from a list of invalid transaction cards, said data being less than the entire account number of each card and including at least one indicator for each invalid card; and b) supplying the master table to each transaction terminal whereby during a transaction, the transaction terminal determines if an indicator exists in the master table for the account number of the card presented for the transaction and allowing the transaction to continue unless an indicator is present whereupon the transaction will be subjected to further verification.
8. A system as recited in claim 7 wherein the entire master table does not have to be scanned to determine if an indicator exists for the account number of the card presented for the transaction.
9. A data file for use in transaction networks, said data file including information about the account numbers of invalid transaction cards comprising:
a master table including a plurality of bit maps each having B bits; and one indicator in each bit map for each invalid card, each said indicator being at a location corresponding to an index value which is an algorithmic function of a set of digits in the account number of the transaction card.
a master table including a plurality of bit maps each having B bits; and one indicator in each bit map for each invalid card, each said indicator being at a location corresponding to an index value which is an algorithmic function of a set of digits in the account number of the transaction card.
10. A data file as recited in claim 9 wherein the length of the bit maps in the master table are set with respect to the number of invalid transaction cards such that the probability of an indicator being present in a bit map is approximately 0.4 to 0.5.
11. A data file as recited in claim 10 wherein the number of bit maps in the master table are selected such that the probability of a valid card bring represented as an invalid card in the data file is less than ten percent.
12. A data file as recited in claim 10 wherein the number of bit maps in the master table are selected such that the probability of a valid card being represented as an invalid card in the data file is on the order of one to three percent.
13. A transaction system including a central processor and a plurality of transaction terminals and a plurality of transaction cards each having an account number, and with some of said cards being invalid, said system for facilitating off line approval of transactions comprising:
means at said central processor for creating a master table, said master table having a plurality of bit maps, wherein one indicator is provided in each bit map for each invalid transaction card;
means for supplying the master table to each of the transaction terminals; and means at each transaction terminal for determining if an indicator is present in each bit map for the account number of the transaction card being presented.
means at said central processor for creating a master table, said master table having a plurality of bit maps, wherein one indicator is provided in each bit map for each invalid transaction card;
means for supplying the master table to each of the transaction terminals; and means at each transaction terminal for determining if an indicator is present in each bit map for the account number of the transaction card being presented.
14. A transaction system as recited in claim 13 wherein said means for supplying the master table to the transaction terminals comprises:
a radio transmitter; and a receiver located at each transaction terminal.
a radio transmitter; and a receiver located at each transaction terminal.
15. A transaction system as recited in claim 13 wherein said means at said central processor generates said master table by selecting sets of digits from the account number of each invalid transaction card and calculating an index value for each set of digits which is an algorithmic function thereof and placing an indicator in individual bit maps at locations corresponding to the calculated index values.
16. A transaction system as recited in claim 15 wherein said transaction terminal selects sets of digits from the account number of the transaction card which has been presented and generates a set of index values and wherein said index values are used to determine if indicators are present in corresponding locations in the bit maps of the master table.
17. A transaction system as recited in claim 16 wherein the transaction terminal allows the transaction to continue unless an indicator is present in each bit map and in that case, the transaction is subjected to further verification.
18. A transaction system as recited in claim 15 wherein the length of each bit map is set with respect to the number of invalid transaction cards such that the probability of an indicator being present in the bit map is approximately 0.4 to 0.5.
19. A transaction system as recited in claim 13 wherein the number of bit maps in the master table are selected such that the probability of a valid card being represented as an invalid card in the data file is less than ten percent.
20. A transaction system as recited in claim 13 wherein the number of bit maps in the master table are selected such that the probability of a valid card being represented as an invalid card in the data file is on the order of one to three percent.
21. A financial transaction system including a central processor and a plurality of transaction terminals and a plurality of transaction cards each having an account number, and with some of said cards being invalid, said system for facilitating off-line approval of transactions comprising:
means at said central processor for creating a master table, said master table having data derived from a list of invalid transaction cards, said data being less than the entire account number of each card and including at least one indicator for each invalid transaction card;
means for supplying the master table to each of the transaction terminals; and means at each transaction terminal for determining if an indicator is exists in the master table for the account number of the transaction card being presented and allowing the transaction to continue if no indicator is present and subjecting the transaction to further verification if an indicator is present.
means at said central processor for creating a master table, said master table having data derived from a list of invalid transaction cards, said data being less than the entire account number of each card and including at least one indicator for each invalid transaction card;
means for supplying the master table to each of the transaction terminals; and means at each transaction terminal for determining if an indicator is exists in the master table for the account number of the transaction card being presented and allowing the transaction to continue if no indicator is present and subjecting the transaction to further verification if an indicator is present.
22. A transaction system as recited in claim 21 wherein said means for supplying the master table to the transaction terminals comprises:
a radio transmitter; and a receiver located at each transaction terminal.
a radio transmitter; and a receiver located at each transaction terminal.
23. A transaction system as recited in claim 21 wherein said master table includes a plurality of bit maps and wherein said means at said central processor generates said master table by selecting sets of digits from the account number of each invalid transaction card and calculating an index value for each set of digits which is an algorithmic function thereof and placing an indicator in individual bit maps at locations corresponding to the calculated index values.
24. A transaction system as recited in claim 23 wherein said transaction terminal selects sets of digits from the account number of the transaction card which has been presented and generates a set of index values and wherein said index values are used to determine if indicators are present in corresponding locations in the bit maps of the master table.
25. A transaction system as recited in claim 24 wherein the transaction terminal allows the transaction to continue unless an indicator is present in each bit map and in that case, the transaction is subjected to further verification.
26. A transaction system as recited in claim 23 wherein the length of each bit map is set with respect to the number of invalid transaction cards such that the probability of an indicator being present in the bit map is approximately 0.4 to 0.5.
27. A transaction system as recited in claim 23 wherein the number of bit maps in the master table are selected such that the probability of a valid card being represented as an invalid card in the data file is less than ten percent.
28. A transaction system as recited in claim 23 wherein the number of bit maps in the master table are selected such that the probability of a valid card being represented as an invalid card in the data file is on the order of one to three percent.
29. A transaction system as recited in Claim 21 wherein the entire master table does not have to be scanned to determine if an indicator exists for the account number of the transaction card presented for the transaction.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US000,596 | 1987-01-06 | ||
| US07/000,596 US4822985A (en) | 1987-01-06 | 1987-01-06 | Transaction approval system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA1281420C true CA1281420C (en) | 1991-03-12 |
Family
ID=21692186
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA000551653A Expired - Lifetime CA1281420C (en) | 1987-01-06 | 1987-11-12 | Transaction approval system |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US4822985A (en) |
| EP (1) | EP0274191A3 (en) |
| JP (1) | JPS63174170A (en) |
| AU (1) | AU602539B2 (en) |
| CA (1) | CA1281420C (en) |
| NO (1) | NO179119C (en) |
Families Citing this family (95)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2196450B (en) * | 1986-10-20 | 1991-02-13 | Mars Inc | Data-storing tokens |
| US4908521A (en) * | 1987-01-06 | 1990-03-13 | Visa International Service Association | Transaction approval system |
| FR2633411B1 (en) * | 1988-06-28 | 1991-09-27 | Schlumberger Ind Sa | PORTABLE INFORMATION MEDIA MANAGEMENT SYSTEM |
| JP2776929B2 (en) * | 1989-03-29 | 1998-07-16 | 株式会社日立製作所 | Card data processing system and card data processing method |
| US5231569A (en) * | 1990-06-12 | 1993-07-27 | Sears Payment Systems, Inc. | Account transaction system |
| US5177342A (en) * | 1990-11-09 | 1993-01-05 | Visa International Service Association | Transaction approval system |
| US5396624A (en) * | 1990-12-20 | 1995-03-07 | Visa International Service Association | Account file for off-line transaction authorization |
| US5285382A (en) * | 1991-02-25 | 1994-02-08 | Keyosk Corporation | System and method for processing credit and debit card validity and funds transactions from vending machines and similar terminals |
| US5340969A (en) * | 1991-10-01 | 1994-08-23 | Dresser Industries, Inc. | Method and apparatus for approving transaction card based transactions |
| FR2685111B1 (en) * | 1991-12-12 | 1998-07-24 | Schlumberger Ind Sa | INSTALLATION FOR VERIFICATION OF THE IDENTIFICATION INFORMATION OF SECURITIES WITH REGARD TO A LIST OF SECURITIES THAT ARE IMPACTED. |
| US5428210A (en) * | 1992-01-10 | 1995-06-27 | National Bancard Corporation | Data card terminal with embossed character reader and signature capture |
| US5334823A (en) * | 1992-01-10 | 1994-08-02 | National Bancard Corporation | Systems and methods for operating data card terminals for transaction chargeback protection |
| US5384449A (en) * | 1992-04-28 | 1995-01-24 | Visa International Service Association | Authorization matching system |
| GB2268294B (en) * | 1992-11-14 | 1994-06-22 | Htec Ltd | Data validation system |
| US5679938A (en) * | 1994-12-02 | 1997-10-21 | Telecheck International, Inc. | Methods and systems for interactive check authorizations |
| KR0146624B1 (en) * | 1994-12-19 | 1998-09-15 | 김광호 | Credit dealing card and credit dealing apparatus and method thereof |
| US6856974B1 (en) * | 1998-02-02 | 2005-02-15 | Checkfree Corporation | Electronic bill presentment technique with enhanced biller control |
| US6615189B1 (en) | 1998-06-22 | 2003-09-02 | Bank One, Delaware, National Association | Debit purchasing of stored value card for use by and/or delivery to others |
| US7809642B1 (en) | 1998-06-22 | 2010-10-05 | Jpmorgan Chase Bank, N.A. | Debit purchasing of stored value card for use by and/or delivery to others |
| US6032136A (en) * | 1998-11-17 | 2000-02-29 | First Usa Bank, N.A. | Customer activated multi-value (CAM) card |
| US7660763B1 (en) | 1998-11-17 | 2010-02-09 | Jpmorgan Chase Bank, N.A. | Customer activated multi-value (CAM) card |
| CA2291920A1 (en) * | 1998-12-11 | 2000-06-11 | Karuna Ganesan | Technique for conducting secure transactions over a network |
| EP1049056A3 (en) * | 1999-04-26 | 2001-06-13 | CheckFree Corporation | Electronic bill presentment and/or payment clearinghouse |
| US6678664B1 (en) | 1999-04-26 | 2004-01-13 | Checkfree Corporation | Cashless transactions without credit cards, debit cards or checks |
| US6882984B1 (en) | 1999-06-04 | 2005-04-19 | Bank One, Delaware, National Association | Credit instrument and system with automated payment of club, merchant, and service provider fees |
| WO2000074973A1 (en) | 1999-06-08 | 2000-12-14 | 911 Emergency Products, Inc. | Rotational led reflector |
| US7249093B1 (en) | 1999-09-07 | 2007-07-24 | Rysix Holdings, Llc | Method of and system for making purchases over a computer network |
| US7370004B1 (en) * | 1999-11-15 | 2008-05-06 | The Chase Manhattan Bank | Personalized interactive network architecture |
| US8793160B2 (en) | 1999-12-07 | 2014-07-29 | Steve Sorem | System and method for processing transactions |
| US6615190B1 (en) * | 2000-02-09 | 2003-09-02 | Bank One, Delaware, National Association | Sponsor funded stored value card |
| US6941279B1 (en) * | 2000-02-23 | 2005-09-06 | Banke One Corporation | Mutual fund card method and system |
| US7113914B1 (en) | 2000-04-07 | 2006-09-26 | Jpmorgan Chase Bank, N.A. | Method and system for managing risks |
| WO2002011019A1 (en) | 2000-08-01 | 2002-02-07 | First Usa Bank, N.A. | System and method for transponder-enabled account transactions |
| US6427912B1 (en) | 2000-08-16 | 2002-08-06 | Coin Acceptors, Inc. | Off-line credit card transaction system and method for vending machines |
| US6631849B2 (en) | 2000-12-06 | 2003-10-14 | Bank One, Delaware, National Association | Selectable multi-purpose card |
| US7433829B2 (en) | 2000-12-12 | 2008-10-07 | Jpmorgan Chase Bank, N.A. | System and method for managing global risk |
| US20020087468A1 (en) * | 2000-12-28 | 2002-07-04 | Ravi Ganesan | Electronic payment risk processing |
| US6985873B2 (en) | 2001-01-18 | 2006-01-10 | First Usa Bank, N.A. | System and method for administering a brokerage rebate card program |
| US7313546B2 (en) | 2001-05-23 | 2007-12-25 | Jp Morgan Chase Bank, N.A. | System and method for currency selectable stored value instrument |
| AU2002327322A1 (en) | 2001-07-24 | 2003-02-17 | First Usa Bank, N.A. | Multiple account card and transaction routing |
| US7809641B2 (en) | 2001-07-26 | 2010-10-05 | Jpmorgan Chase Bank, National Association | System and method for funding a collective account |
| US6945453B1 (en) | 2001-08-13 | 2005-09-20 | Bank One Delaware N.A. | System and method for funding a collective account by use of an electronic tag |
| US8020754B2 (en) | 2001-08-13 | 2011-09-20 | Jpmorgan Chase Bank, N.A. | System and method for funding a collective account by use of an electronic tag |
| US7311244B1 (en) | 2001-08-13 | 2007-12-25 | Jpmorgan Chase Bank, N.A. | System and method for funding a collective account by use of an electronic tag |
| US8800857B1 (en) | 2001-08-13 | 2014-08-12 | Jpmorgan Chase Bank, N.A. | System and method for crediting loyalty program points and providing loyalty rewards by use of an electronic tag |
| EP1451741A2 (en) * | 2001-11-26 | 2004-09-01 | Epacific Inc. | Systems and methods for fund transfers |
| US7512566B1 (en) | 2001-12-11 | 2009-03-31 | Jpmorgan Chase Bank, N.A. | System and method for using a stored value account having subaccount feature |
| US7756896B1 (en) | 2002-03-11 | 2010-07-13 | Jp Morgan Chase Bank | System and method for multi-dimensional risk analysis |
| US20180165441A1 (en) | 2002-03-25 | 2018-06-14 | Glenn Cobourn Everhart | Systems and methods for multifactor authentication |
| US7899753B1 (en) | 2002-03-25 | 2011-03-01 | Jpmorgan Chase Bank, N.A | Systems and methods for time variable financial authentication |
| US20040210498A1 (en) | 2002-03-29 | 2004-10-21 | Bank One, National Association | Method and system for performing purchase and other transactions using tokens with multiple chips |
| US8751391B2 (en) | 2002-03-29 | 2014-06-10 | Jpmorgan Chase Bank, N.A. | System and process for performing purchase transactions using tokens |
| US8239304B1 (en) | 2002-07-29 | 2012-08-07 | Jpmorgan Chase Bank, N.A. | Method and system for providing pre-approved targeted products |
| US7809595B2 (en) | 2002-09-17 | 2010-10-05 | Jpmorgan Chase Bank, Na | System and method for managing risks associated with outside service providers |
| US20040122736A1 (en) | 2002-10-11 | 2004-06-24 | Bank One, Delaware, N.A. | System and method for granting promotional rewards to credit account holders |
| US20040133515A1 (en) * | 2002-11-01 | 2004-07-08 | Mccoy Randal A. | Distributed matching of consumers with billers having bills available for electronic presentment |
| US7526448B2 (en) * | 2002-11-01 | 2009-04-28 | Checkfree Corporation | Matching consumers with billers having bills available for electronic presentment |
| US8073773B2 (en) * | 2002-11-01 | 2011-12-06 | Checkfree Corporation | Technique for identifying probable billers of a consumer |
| US20040133513A1 (en) * | 2002-11-01 | 2004-07-08 | Mccoy Randal | Identity protection technique in matching consumers with electronic billers |
| US20040133509A1 (en) * | 2002-11-01 | 2004-07-08 | Mccoy Randal A. | Technique for making payments for a non-subscriber payor |
| US7395243B1 (en) | 2002-11-01 | 2008-07-01 | Checkfree Corporation | Technique for presenting matched billers to a consumer |
| US20040088235A1 (en) * | 2002-11-01 | 2004-05-06 | Ziekle William D. | Technique for customizing electronic commerce user |
| US7729996B2 (en) * | 2002-11-01 | 2010-06-01 | Checkfree Corporation | Reuse of an EBP account through alternate authentication |
| US8601606B2 (en) | 2002-11-25 | 2013-12-03 | Carolyn W. Hafeman | Computer recovery or return |
| US7702916B2 (en) * | 2003-03-31 | 2010-04-20 | Visa U.S.A. Inc. | Method and system for secure authentication |
| US20040220876A1 (en) * | 2003-05-02 | 2004-11-04 | Liu David J. | Systems and methods for services over a financial transaction platform |
| US8306907B2 (en) | 2003-05-30 | 2012-11-06 | Jpmorgan Chase Bank N.A. | System and method for offering risk-based interest rates in a credit instrument |
| US7086586B1 (en) | 2003-08-13 | 2006-08-08 | Bank One, Delaware, National Association | System and method for a card payment program providing mutual benefits to card issuers and cardholders based on financial performance |
| US7953663B1 (en) | 2003-09-04 | 2011-05-31 | Jpmorgan Chase Bank, N.A. | System and method for financial instrument pre-qualification and offering |
| US8239323B2 (en) | 2003-09-23 | 2012-08-07 | Jpmorgan Chase Bank, N.A. | Method and system for distribution of unactivated bank account cards |
| US7392222B1 (en) | 2004-08-03 | 2008-06-24 | Jpmorgan Chase Bank, N.A. | System and method for providing promotional pricing |
| US8630898B1 (en) | 2005-02-22 | 2014-01-14 | Jpmorgan Chase Bank, N.A. | Stored value card provided with merchandise as rebate |
| US20060195396A1 (en) * | 2005-02-28 | 2006-08-31 | Checkfree Corporation | Centralized customer care for electronic payments and other transactions via a wide area communications network |
| US20060195397A1 (en) * | 2005-02-28 | 2006-08-31 | Checkfree Corporation | Centralized electronic bill presentment |
| US20060195395A1 (en) * | 2005-02-28 | 2006-08-31 | Checkfree Corporation | Facilitating electronic payment on behalf of a customer of electronic presented bills |
| US7401731B1 (en) | 2005-05-27 | 2008-07-22 | Jpmorgan Chase Bank, Na | Method and system for implementing a card product with multiple customized relationships |
| US7225093B1 (en) * | 2005-11-21 | 2007-05-29 | Agilent Technologies, Inc. | System and method for generating triggers based on predetermined trigger waveform and a measurement signal |
| US7784682B2 (en) | 2006-02-08 | 2010-08-31 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to both customers and non-customers |
| US8408455B1 (en) | 2006-02-08 | 2013-04-02 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to both customers and non-customers |
| US7753259B1 (en) | 2006-04-13 | 2010-07-13 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to both customers and non-customers |
| US7505918B1 (en) | 2006-05-26 | 2009-03-17 | Jpmorgan Chase Bank | Method and system for managing risks |
| US8386349B2 (en) | 2007-02-28 | 2013-02-26 | Visa U.S.A. Inc. | Verification of a portable consumer device in an offline environment |
| US20080208681A1 (en) * | 2006-09-28 | 2008-08-28 | Ayman Hammad | Payment using a mobile device |
| US8523069B2 (en) | 2006-09-28 | 2013-09-03 | Visa U.S.A. Inc. | Mobile transit fare payment |
| US8738485B2 (en) | 2007-12-28 | 2014-05-27 | Visa U.S.A. Inc. | Contactless prepaid product for transit fare collection |
| US8346639B2 (en) | 2007-02-28 | 2013-01-01 | Visa U.S.A. Inc. | Authentication of a data card using a transit verification value |
| US20080203170A1 (en) * | 2007-02-28 | 2008-08-28 | Visa U.S.A. Inc. | Fraud prevention for transit fare collection |
| US8118223B2 (en) | 2006-09-28 | 2012-02-21 | Visa U.S.A. Inc. | Smart sign mobile transit fare payment |
| US7527208B2 (en) | 2006-12-04 | 2009-05-05 | Visa U.S.A. Inc. | Bank issued contactless payment card used in transit fare collection |
| US7866551B2 (en) * | 2007-02-15 | 2011-01-11 | Visa U.S.A. Inc. | Dynamic payment device characteristics |
| US8676642B1 (en) | 2007-07-05 | 2014-03-18 | Jpmorgan Chase Bank, N.A. | System and method for granting promotional rewards to financial account holders |
| US8417601B1 (en) | 2007-10-18 | 2013-04-09 | Jpmorgan Chase Bank, N.A. | Variable rate payment card |
| US20100027786A1 (en) * | 2008-02-14 | 2010-02-04 | Patrick Faith | Dynamic encryption authentication |
| US8725611B1 (en) | 2008-02-21 | 2014-05-13 | Jpmorgan Chase Bank, N.A. | System and method for providing borrowing schemes |
| US10008067B2 (en) | 2008-06-16 | 2018-06-26 | Visa U.S.A. Inc. | System and method for authorizing financial transactions with online merchants |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US2092345A (en) * | 1937-01-11 | 1937-09-07 | Edward K Yuasa | Ratchet wrench |
| US3696335A (en) * | 1970-04-21 | 1972-10-03 | Jerome H Lemelson | Credit verification system |
| US4186871A (en) * | 1978-03-01 | 1980-02-05 | International Business Machines Corporation | Transaction execution system with secure encryption key storage and communications |
| DE2929603A1 (en) * | 1979-07-21 | 1981-01-29 | Juergen Beust | Credit card validity checker - has inputs for card scanning linked to processor with connections to memory and display unit |
| MX155784A (en) * | 1981-01-16 | 1988-04-29 | Salomon Frid Ran | IMPROVEMENTS IN FINANCIAL DOCUMENT PROTECTION DEVICE |
| FR2526977B1 (en) * | 1982-05-14 | 1988-06-10 | Cii Honeywell Bull | METHOD AND DEVICE FOR AUTHENTICATING OR CERTIFYING AT LEAST INFORMATION CONTAINED IN A MEMORY OF AN ELECTRONIC MEDIUM IN PARTICULAR REMOVABLE AND PORTABLE SUCH AS A CARD |
| US4558211A (en) * | 1983-05-23 | 1985-12-10 | Imperial Oil Limited | Transaction terminal system |
| JPS6123281A (en) * | 1984-07-11 | 1986-01-31 | Toshiba Corp | Identification number setting system |
| JPS61143871A (en) * | 1984-08-30 | 1986-07-01 | Casio Comput Co Ltd | Ic card collation system |
| US4679236A (en) * | 1984-12-21 | 1987-07-07 | Davies Richard E | Identification verification method and system |
| US4734564A (en) * | 1985-05-02 | 1988-03-29 | Visa International Service Association | Transaction system with off-line risk assessment |
-
1987
- 1987-01-06 US US07/000,596 patent/US4822985A/en not_active Expired - Lifetime
- 1987-10-30 EP EP87309649A patent/EP0274191A3/en not_active Withdrawn
- 1987-11-02 AU AU80586/87A patent/AU602539B2/en not_active Expired
- 1987-11-12 CA CA000551653A patent/CA1281420C/en not_active Expired - Lifetime
- 1987-11-24 JP JP62294301A patent/JPS63174170A/en active Granted
-
1988
- 1988-01-05 NO NO880018A patent/NO179119C/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| NO179119C (en) | 1996-08-07 |
| JPS63174170A (en) | 1988-07-18 |
| EP0274191A2 (en) | 1988-07-13 |
| JPH0547873B2 (en) | 1993-07-19 |
| AU8058687A (en) | 1988-07-07 |
| NO179119B (en) | 1996-04-29 |
| US4822985A (en) | 1989-04-18 |
| EP0274191A3 (en) | 1989-08-30 |
| AU602539B2 (en) | 1990-10-18 |
| NO880018L (en) | 1988-07-07 |
| NO880018D0 (en) | 1988-01-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA1281420C (en) | Transaction approval system | |
| US4870259A (en) | Transaction approval system | |
| US4943707A (en) | Transaction approval system | |
| US4908521A (en) | Transaction approval system | |
| US4423287A (en) | End-to-end encryption system and method of operation | |
| US4812628A (en) | Transaction system with off-line risk assessment | |
| EP0387599B1 (en) | Method of encrypting transmitted data using a unique key | |
| US4578530A (en) | End-to-end encryption system and method of operation | |
| EP0131906B1 (en) | Pocket banking terminal, method and system | |
| EP0385400B1 (en) | Multilevel security apparatus and method with personal key | |
| US4734564A (en) | Transaction system with off-line risk assessment | |
| US4386266A (en) | Method for operating a transaction execution system having improved verification of personal identification | |
| US5231570A (en) | Credit verification system | |
| JPS61502999A (en) | Safety system and method for remote terminal networks | |
| WO1998052158A2 (en) | Integrated circuit card with application history list | |
| NZ235926A (en) | Validation of new smart card | |
| EP1746535A1 (en) | Secure transaction string | |
| EP0138320A2 (en) | Cryptographic key management system | |
| EP0112944B1 (en) | Testing the validity of identification codes | |
| JP2003536181A (en) | Improved method and system for processing secure payments across computer networks without pseudo or proxy account numbers | |
| EP0254565B1 (en) | Methods of and apparatus for forming identification data | |
| CA1165445A (en) | Method for operating a transaction execution system having improved verification of personal identification | |
| AP322A (en) | System for the provision of a reticulated utility. | |
| JPH05333774A (en) | Information processing system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| MKEX | Expiry |