AU2013267037B2 - Frequency-based transaction prediction and processing - Google Patents

Abstract

FREQUENCY-BASED TRANSACTION PREDICTION AND PROCESSING Methods, apparatus, and systems for determining a likelihood of an occurrence of a transaction involving a consumer are provided. The method comprises receiving data (310) associated with transactions previously performed by the consumer, determining a plurality of correlated pairs of the transactions, and providing a plurality of counters. A counter is associated with a time range. For each course a pair of transactions: the method comprises a computer system determining a time interval between the transactions of the correlated pair and the computer system increases a counter of the plurality of counters when the time interval is within the time range associated with the increased counter and uses the values of the counters to determine a likelihood (380) of an occurrence of another transaction involving the consumer. 8108851_1

Description

1 FREQUENCY-BASED TRANSACTION PREDICTION AND PROCESSING CROSS-REFERENCES TO RELATED APPLICATIONS [0001] This application is a divisional application of Australian Patent Application No. 2010246077, a national phase entry of International Application No. PCT/US 2010/033556, filed on 4 May 2010 which claims priority from and is a nonprovisional application of U.S. Provisional Application No. 61/175,381, entitled "SYSTEMS AND METHODS FOR DETERMINING AUTHORIZATION, RISK SCORES, AND PREDICTION OF TRANSACTIONS" filed May 4, 2009.The entire contents of Australian Patent Application No. 2010246077, International Application PCT/US2010/033556 and US Application No. 61/175,381 are herein incorporated by reference in their entirety for all purposes. [0002] This application is related to commonly owned and concurrently filed U.S. Patent applications entitled "PRE-AUTHORIZATION OF A TRANSACTION USING PREDICTIVE MODELING" by Faith et al. (attorney docket number 016222-046210US), "DETERMINING TARGETED INCENTIVES BASED ON CONSUMER TRANSACTION HISTORY" by Faith et al. (attorney docket number 01 6222-046220US), "DEMOGRAPHIC ANALYSIS USING TIME BASED CONSUMER TRANSACTION HISTORIES" by Faith et al. (attorney docket number 01 6222-046230US), and "FREQUENCY-BASED TRANSACTION PREDICTION AND PROCESSING" by Faith et al. (attorney docket number 016222-046240US), the entire contents of which are herein incorporated by reference for all purposes. BACKGROUND [0003] The present application is generally related to consumer events (e.g. transactions), and more specifically to tracking consumer activity, which may be used in processing consumer transactions. [0004] An amount that a consumer spends and the general type of goods that a consumer buys can be used in marketing efforts. Efforts to track such consumer activity have generally looked only at the broad behavior of a consumer, e.g., total amount spent by a consumer within a fixed time period. Such efforts to track consumer activity have also generally analyzed or otherwise used the consumer activity quite infrequently. For example, the consumer behavior might be analyzed only once or twice a year, or just before a big marketing campaign. [0005] The ability to track finely tuned consumer activity can add a large amount of computational and storage complexity. This complexity could necessitate that an analysis of the data be infrequent as any more frequent analysis would not be computationally feasible. [0006] Accordingly, it is desirable to provide more accurate and robust tracking of consumer activity and tracking where the data can be analyzed and used frequently, e.g., in real time. 8107079_1 2 [0007] Additionally, many transactions (such as purchases, wire transfers, and the like) are performed with reference to a payment account, e.g., a credit card account, bank account, or other type of account. These types of accounts are subject to fraud since the money to pay for the transaction is not directly provided, but is instead retrieved from the payment account. For example, fraud might occur when someone other than the credit card holder uses the credit card number to make a purchase. [0008] A reduction in fraud may be achieved in different ways. For example, when a consumer initiates a transaction with a merchant using a payment account, the merchant can send an authorization request for the payment account to a payment processing network. This authorization request can be part of a check for fraud, as well as a way to ensure that sufficient funds are available to pay for the transaction. However, such an authorization step can take a substantial amount of time. Thus, such an authorization step can reduce the amount of transactions that a merchant can handle, thereby reducing revenue. Consumers also may be delayed, which can discourage a transaction using the payment account. [0009] Accordingly, it is desirable to provide more efficient processing of transactions while maintaining some mechanism for checking fraud. SUMMARY [0009a] It is an object of the present disclosure to substantially overcome, or at least ameliorate, at least one disadvantage of present arrangements. [0010] The present disclosure provides systems, apparatus, and methods for tracking and analyzing data of consumer activity. The tracked data can be organized (e.g. as stored in cache, RAM, hard drives) in certain types of tables, where the tables can be associated with certain tags (keys) for efficiently accessing the data. The organization and associations of the data can also provide simple mechanisms for manipulating the data to obtain results specifically relevant for a task, such as detection of fraud or prediction of consumer behavior to provide better customer service or new services. For example, the tables may contain counters that store the number of times that two correlated consumer events occur within specific time intervals of each other. Such time data can provide efficient determination of patterns of consumer activity. [0011] According to one aspect, a method of determining a likelihood of an occurrence of a transaction involving a consumer is provided. Data associated with transactions previously performed by the consumer are received, and a plurality of correlated pairs of the transactions is determined. Each of a plurality of counters are associated with a time range. For each correlated pair, a first computer apparatus determines a time interval between the transactions of the correlated pair and increases a counter of the plurality of counters. The time interval is within the time range associated with the increased counter. The values of the counters are used to determine a likelihood of an occurrence of another transaction involving the consumer. 8107079_1 3 [0012] According to another aspect, a method of determining a likelihood of an occurrence of a transaction involving a consumer is provided. Data for events associated with the consumer are received, and a plurality of correlated pairs of the events is determined. One or more keys are associated with each event; and for each correlated pair of the events, one or more key pairs associated with the correlated pair are identified. Each identified key pair has a set of counters, where each counter is associated with a time range. For each correlated pair of events, a first computer apparatus determines a time interval between the two events of the correlated pair, and increases a counter for each key pair associated with the correlated pair of events. The time interval is within the time range associated with the increased counter. The values of the counters are used to determine a likelihood of an occurrence of another event that involves the consumer and that is associated with one or more keys. [0012a] Another aspect of the present disclosure provides a method of determining a likelihood of an occurrence of a second transaction involving a consumer, the method comprising: receiving data associated with first transactions previously performed by the consumer; determining a plurality of correlated pairs of the first transactions, wherein a correlated pair of first transactions includes an initial transaction and a final transaction that occurs after the initial transaction; providing a plurality of counters, wherein each counter in the plurality of counters is associated with a different time range; after determining the plurality of correlated pairs of the first transactions, for each correlated pair of transactions: a computer system determining a time interval between the final transaction and the initial transaction of the correlated pair; the computer system selecting a counter of the plurality of counters having a first time range that includes the time interval; and the computer system increasing a counter of the plurality of counters; and using the values of the counters to determine a likelihood of an occurrence of the second transaction involving the consumer. [0012b] Another aspect of the present disclosure provides a method of determining a likelihood of an occurrence of a second event involving a consumer, the method comprising: receiving data of first events associated with the consumer; associating one or more keys with each first event and the second event, the second event associated with a first key; determining a plurality of correlated pairs of the first events, wherein a correlated pair of first events include an initial event and a final event that occurs after the initial event; for each correlated pair of the first events, identifying one or more key pairs associated with the correlated pair; providing a set of counters for each identified key pair, wherein each counter in the set of counters is associated with a different time range; after determining the plurality of correlated pairs of the first events, for each correlated pair of first events: a computer system determining a time interval between 3a the final event and the initial event of the correlated pair; for each key pair associated with the correlated pair of first events: selecting a counter having a first time range that includes the time interval; and the computer system increasing the counter; and identifying a group of the key pairs associated with the first key; and using at least one of the values of the counters of each of the identified group of the key pairs to determine a likelihood of an occurrence of the second event involving the consumer. [0013] The present disclosure can also provides systems, apparatus, and methods for efficiently authorizing a transaction initiated by a consumer. In one aspect, an authorization is generated before the consumer actually initiates the transaction. For example, a future transaction can be predicted, and an authorization can be generated for the predicted transaction. In this manner, the authorization can be ready and quickly used when the consumer does initiate the transaction. Previous transactions made by the consumer can be used to predict when the future transaction is likely. In various examples, the authorization can be sent to a specific merchant or to the consumer for use when the consumer initiates the predicted transaction, or saved by an authorization entity for use in response to an authorization request from the merchant. [0014] According to one aspect, a method of pre-authorizing a future transaction of a consumer is provided. Data corresponding to previous transactions is received. A computer system determines one or more patterns of the previous transactions. Based on the determined patterns, it is predicting when the consumer is likely to initiate the future transaction. An authorization of the future transaction is generated prior to the consumer initiating the transaction. [0015] According to another aspect, a method of using an authorization for a future transaction by a consumer is provided. The consumer performs a plurality of previous transactions. A token for authorization of a future transaction is received. The authorization is for a time when the future transaction is predicted to be likely based on the previous transactions. The consumer provides the authorization to a merchant at the time when the future transaction is predicted to be likely. [0016] The present disclosure can provide systems, apparatus, and methods for authorizing a transaction initiated by a consumer. In one aspect, a likelihood function approximates a pattern of previous transactions and provides a measure of how likely it is for a transaction to occur as a function of time. The time of a current transaction can be used to determine a corresponding 4 likelihood value of a likelihood function associated with the transaction. The likelihood value can be used to determine a score for authorizing the transaction. As the likelihood corresponds to a particular time of a pattern, the score can be tailored to the current transaction and achieve greater accuracy. [0017] According to one aspect, a method of determining authorization of a transaction involving a consumer is provided. Data associated with the transaction is received. The data includes a time T of the transaction. A likelihood function associated with the consumer and with the transaction is identified. The likelihood function approximates one or more patterns of previously performed transactions. Also, the likelihood function has a respective likelihood value for each of a plurality of times. A computer system determines a first likelihood value of the likelihood function, where the first likelihood provides a measure of a likelihood of a transaction occurring at the time T. A score is determined using the likelihood value and is adapted to be used to determine authorization of the transaction. [0018] According to another aspect, data associated with the transaction is received. One or more tables are identified as being associated with the consumer and with the transaction. Each table includes a plurality of values organized along at least one axis. A first axis of each table corresponds to a plurality of different time ranges. The values in each table correspond to a number of previous transactions occurring within one of the different time ranges. A computer system determines at least one value from each table, where the at least one value is for a time range in which the time T corresponds. A score is determined using the at least one value and adapted to be used to determine authorization of the transaction. [0018a] Another aspect provides a method of providing an incentive to a consumer, the method comprising: receiving data corresponding to previous transactions; a computer system determining one or more patterns of the previous transactions; based on the determined patterns of the previous transactions, determining a likelihood for the future transaction at a plurality of times; based on the likelihoods at the plurality of times, predicting a time window when the consumer is likely to initiate a future transaction; and sending an incentive associated with the future transaction to the consumer such that the consumer receives the incentive at a time correlated with the predicted time window. [0018b] Another aspect provides a method of providing an incentive to a consumer, the method comprising: a computer system determining a likelihood of any transaction occurring after a first type of transaction initiated by the consumer; and sending, to the consumer, an incentive for a future transaction of the first type based on the likelihood being greater than a threshold. [0018c] Another aspect provides a method of providing an incentive to a consumer, the method comprising: a computer system determining an amount of transactions that are correlated to a first transaction type and that occur after the first transaction type; and after a transaction of the 8107079_1 5 first transaction type occurs, sending an incentive for any transaction based on the amount being below a threshold. [0018d] Another aspect provides a method of identifying a consumer as belonging to a particular demographic, the method comprising: receiving first data associated with first transactions of a first entity and second data associated with second transactions of one or more second entities; a computer system identifying one or more first patterns of the first transactions and identifying one or more second patterns of the second transactions, wherein each pattern includes a plurality of values, with at least two of the values respectively including contributions from transactions corresponding to different time ranges; comparing the one or more first patterns to the one or more second patterns; and based on the comparison, determining whether the first entity and the one or more second entities belong to a same demographic. [0018e] Another aspect provides a method of identifying a trend in consumer behavior, the method comprising: receiving data associated with previous transactions of an entity; a computer system determining one or more patterns of the previous transactions, wherein each pattern includes a plurality of values, with at least two of the values respectively including contributions from transactions corresponding to different time ranges; determining likelihoods for an occurrence of a transaction according to the one or more patterns, each likelihood at a respective one of a plurality of different times; and identifying a trend in occurrences of the transaction based on the likelihoods at the plurality of different times. [0019] Other aspects of the present disclosure are directed to systems, apparatuses, portable consumer devices, and computer readable media associated with methods described herein. [0020] A better understanding of the nature and advantages of the present invention may be gained with reference to the following detailed description and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS [0021] FIG. 1 shows a block diagram of a system according to an embodiment of the invention. [0022] FIGS. 2A and 2B shows plots of transaction history of a consumer as analyzed according to embodiments of the present invention. [0023] FIG. 3A is a flowchart illustrating a method for analyzing transaction history associated with a consumer according to embodiments of the present invention. [0024] FIG. 3B shows a mapping module that receives transaction data and provides keys that are associated with the transaction data according to embodiments of the present invention. [0025] FIG. 4 is a plot of a number of transactions at certain elapsed times between a final key and an initial key of a correlated key pair according to embodiments of the present invention. 8107079_1 5a [0026] FIG. 5A shows a table that stores time information for a key pair according to embodiments of the present invention. 8107079_1 [0027] FIG. 5B shows a plot for use in determining the time intervals for table 500 according to an embodiment of the present invention. [0028] FIG. 6A shows transaction data with example categories of key elements listed according to an embodiment of the present invention. 5 [0029] FIG. 6B shows a set of correlated key pairs being tracked for account entity according to an embodiment of the present invention. [0030] FIG. 7A shows different queries and results according to embodiments of the present invention. [0031] FIG. 7B shows a lookup table of key pair identifiers, where each key pair 10 number has a pair of hashes associated with it, according to embodiments of the present invention. [0032] FIG. 7C shows an alignment method for finding a similar key when an exact match for an input key(s) is not found according to embodiments of the present invention. 15 [0033] FIG. 7D shows a matching and retrieval module that obtains matching key pair tables based on keys received from a mapping function according to embodiments of the present invention. [0034] FIG. 8 shows different tables updated for a same K5 transaction according to an embodiment of the present invention. 20 [0035] FIG. 9 shows an example of obtaining indicia of a similarity of a recent transaction relative to an established transaction pattern of a consumer according to an embodiment of the present invention. [0036] FIG. 10 illustrates the alignment of a short-term key pair table with established key pair tables according to embodiments of the present invention. 25 [0037] FIG. 11 shows a calculation of a likelihood that a transaction or set of transactions are similar to established patterns according to embodiments of the present invention. [0038] FIG. 12 is a flowchart of a method for determining a likelihood of events for which data has been received according to embodiments. 6 [0039] FIG. 13 is a flowchart of a method for authorizing a transaction of a consumer according to embodiments of the present invention. [0040] FIG. 14 a flowchart of a method for predicting an event according to embodiments of the present invention of the present invention. 5 [0041] FIG. 15 is a flowchart of a method for pre-authorizing a transaction of a consumer according to embodiments. [0042] FIG. 16 shows a block diagram of an example computer system usable with systems and methods according to embodiments of the present invention. DETAILED DESCRIPTION 10 [0043] Embodiments provide systems, apparatus, and methods for tracking and analyzing data of consumer activity. The tracked data can be organized (e.g. as stored in cache, RAM, hard drives) in certain types of tables, where the tables can be associated with certain tags (keys) for efficiently accessing the data. The organization and associations of the data can also provide simple mechanisms for 15 manipulating the data to obtain results specifically relevant for a task (e.g. detection of fraud or prediction of consumer behavior to provide better customer service or new services). [0044] A framework is provided to track consumers, merchants, area and use different events (e.g. a transaction or beginning of a time period) to determine 20 relevant consumer behavior. The consumer behavior can then be used for different purposes. A general structure of payment processing is first described, then the concept of a pattern for transactions is introduced. A manner for storing timing information for transaction data in tables with discretized time ranges and a relation to periodic functions is discussed. The organization of the tables for different 25 transaction attributes and the extension to different events and entities elaborates on different embodiments. The filtering for relevant events and entities is described so as to obtain the relevant data for calculations. The use of an imaginary part of complex numbers in the tables for estimating when a future transaction is likely is also described. Examples of various calculations using this infrastructure is then 30 provided. 7 [0045] 1. SYSTEM OVERVIEW [0046] FIG. 1 shows an exemplary system 20 according to an embodiment of the invention. Other systems according to other embodiments of the invention may include more or less components than are shown in FIG. 1. 5 [0047] The system 20 shown in FIG. 1 includes a merchant 22 and an acquirer 24 associated with the merchant 22. In a typical payment transaction, a consumer 30 may purchase goods or services at the merchant 22 using a portable consumer device 32. The merchant 22 could be a physical brick and mortar merchant or an e merchant. The acquirer 24 can communicate with an issuer 28 via a payment 10 processing network 26. The merchant 22 could alternatively be connected directly to the payment processing network 26. The consumer may interact with the payment processing network 26 and the merchant through an access device 34. [0048] As used herein, an "acquirer" is typically a business entity, e.g., a commercial bank that has a business relationship with a particular merchant or an 15 ATM. An "issuer" is typically a business entity (e.g., a bank) which issues a portable consumer device such as a credit or debit card to a consumer. Some entities can perform both issuer and acquirer functions. Embodiments of the invention encompass such single entity issuer-acquirers. [0049] The consumer 30 may be an individual, or an organization such as a 20 business that is capable of purchasing goods or services. In other embodiments, the consumer 30 may simply be a person who wants to conduct some other type of transaction such as a money transfer transaction or a transaction at an ATM. [0050] The portable consumer device 32 may be in any suitable form. For example, suitable portable consumer devices can be hand-held and compact so that 25 they can fit into a consumer's wallet and/or pocket (e.g., pocket-sized). They may include smart cards, ordinary credit or debit cards (with a magnetic strip and without a microprocessor), keychain devices (such as the Speedpass TM commercially available from Exxon-Mobil Corp.), etc. Other examples of portable consumer devices include cellular phones, personal digital assistants (PDAs), pagers, payment 30 cards, security cards, access cards, smart media, transponders, and the like. The portable consumer devices can also be debit devices (e.g., a debit card), credit devices (e.g., a credit card), or stored value devices (e.g., a stored value card). 8 [0051] The merchant 22 may also have, or may receive communications from, an access device 34 that can interact with the portable consumer device 32. The access devices according to embodiments of the invention can be in any suitable form. Examples of access devices include point of sale (POS) devices, cellular 5 phones, PDAs, personal computers (PCs), tablet PCs, handheld specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like. [0052] If the access device 34 is a point of sale terminal, any suitable point of sale terminal may be used including card readers. The card readers may include any 10 suitable contact or contactless mode of operation. For example, exemplary card readers can include RF (radio frequency) antennas, magnetic stripe readers, etc. to interact with the portable consumer devices 32. [0053] The access device 34 may also be a wireless phone. In one embodiment, the portable consumer device 32 and the access device are the same device. For 15 example, a consumer may use a wireless to phone to select items to buy through a browser. [0054] When the access device 34 is a personal computer, the interaction of the portable consumer devices 32 may be achieved via the consumer 30 or another person entering the credit card information into an application (e.g. a browser) that 20 was opened to purchase goods or services and that connects to a server of the merchant, e.g. through a web site. In one embodiment, the personal computer may be at a checkout stand of a retail store of the merchant, and the application may already be connected to the merchant server. [0055] The portable consumer device 32 may further include a contactless element, 25 which is typically implemented in the form of a semiconductor chip (or other data storage element) with an associated wireless transfer (e.g., data transmission) element, such as an antenna. Contactless element is associated with (e.g., embedded within) portable consumer device 32 and data or control instructions transmitted via a cellular network may be applied to contactless element by means of 30 a contactless element interface (not shown). The contactless element interface functions to permit the exchange of data and/or control instructions between the mobile device circuitry (and hence the cellular network) and an optional contactless element. 9 [0056] The portable consumer device 32 may also include a processor (e.g., a microprocessor) for processing the functions of the portable consumer device 32 and a display to allow a consumer to see phone numbers and other information and messages. 5 [0057] If the portable consumer device is in the form of a debit, credit, or smartcard, the portable consumer device may also optionally have features such as magnetic strips. Such devices can operate in either a contact or contactless mode. [0058] Referring again to FIG. 1, the payment processing network 26 may include data processing subsystems, networks, and operations used to support and deliver 10 authorization services, exception file services, and clearing and settlement services. An exemplary payment processing network may include VisaNetTM. Payment processing networks such as VisaNetTM are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet

TM

, in particular, includes a VIP system (Visa Integrated Payments system) which 15 processes authorization requests and a Base II system which performs clearing and settlement services. [0059] The payment processing network 26 may include a server computer or other computer apparatus. A server computer is typically a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a 20 minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The payment processing network 26 may use any suitable wired or wireless network, including the Internet. [0060] As shown in FIG. 1, the payment processing network 26 may comprise a 25 server 26a, a transaction history database 26b, and a transaction analyzer 26c. In various embodiments, transaction analyzer 26c can determine patterns in transactions stored in transaction history database 26b to determine certain actions, such as authorizing a transaction or sending an incentive. In one embodiment, an incentive system 27 is coupled with or part of payment processing network 26 and 30 can be used to determine an incentive based on determined transaction patterns. Each of these apparatus can be in communication with each other. In one embodiment, all or parts of transaction analyzer 26c and/or transaction history database 26b may be part of or share circuitry with server 26a. 10 [0061] As used herein, an "incentive" can be any data or information sent to a consumer to encourage a transaction. For example, a coupon can be sent to a consumer as an incentive since the consumer can obtain a better transaction price. As another example, an advertisement can be sent to a consumer to encourage a 5 transaction by making the consumer aware of a product or service. Other example of incentives can include rewards for making a transaction and preferential treatment when making the transaction. [0062] In one embodiment, the payment processing network 26 may have relationship deals with specific companies, advertisers, or manufacturers for sending 10 incentives. The payment processing network 26 may then retrieve an incentive from an incentive system 27 that is coupled with or part of the payment processing network 26. The incentive system 27 may be a simple repository of incentives or information on specific incentives. In one embodiment, the payment processing network 26 can identify specific properties of a incentive (e.g. merchant, merchant 15 type, product, ...) and then query the incentive system 27 for an incentive. The incentive system 27 may be tasked with keeping an up to date listing of incentives that may be used. The incentive system 27 may also retrieve incentives from servers associated with particular merchants, manufactures, advertisers, or other companies. 20 [0063] The issuer 28 may be a bank or other organization that may have an account associated with the consumer 30. The issuer 28 may operate a server which may be in communication with the payment processing network 26. [0064] Embodiments of the invention are not limited to the above-described embodiments. For example, although separate functional blocks are shown for an 25 issuer, payment processing network, and acquirer, some entities perform all or any suitable combination of these functions and may be included in embodiments of invention. Additional components may also be included in embodiments of the invention. [0065] II. IDENTIFYING PATTERNS 30 [0066] Consumer activity can include transactions, among other things. Knowledge of a pattern of transactions of a consumer can allow better fraud detection, better customer service by preparing for a transaction, or an identification of opportunities to incentivize continuing or new behavior of a consumer, as well as provide other 11 advantages. However, the identification of a pattern can be difficult given the enormous amount of data, some of which might exhibit patterns and some of which may not. [0067] As used herein, the term "pattern" refers broadly to a behavior of any set of 5 events (e.g. transactions) that have a likelihood of repeating. In one aspect, the likelihood can be greater than a random set of events, e.g., events that are uncorrelated. The likelihood can be expressed as a probability (e.g. as a percentage or ratio), a rank (e.g. with numbers or organized words), or other suitable values or characters. One type of pattern is a frequency-based pattern in which the events 10 repeats with one or more frequencies, which may be predefined. To define a pattern, a reference frame may be used. In various embodiments, the reference frame may be or include an elapsed time since a last event (e.g. of a type correlated to the current event), since a beginning of a fixed time period, such as day, week, month, year,... (which is an example of a starting event), before an end of a fixed 15 time period, or before occurrence of a scheduled event (an example of an ending event). Another event can be certain actions by the consumer, such as traveling to a specific geographic location or browsing a certain address location on the Internet. [0068] FIG. 2A shows a plot 200 of a transaction history or other events of a consumer as analyzed according to embodiments of the present invention. Plot 200 20 shows times at which each of a plurality of previous transactions 210 have occurred. As shown, time is an absolute time (e.g. date and time), but it can be an elapsed time in other embodiments. Herein, the term "time" can refer to either or both a date and a time of a particular day. These previous transactions 210, which occur before an end time 205, can be analyzed to determine a pattern 220, which can be a 25 function that approximates when the transactions are likely to occur. As examples, an identified pattern can be used to predict a next transaction or authorize a new transaction, e.g. transaction 230. [0069] The identification of a pattern can have many difficulties. If the previous transactions 210 include all of the transactions of a consumer and exhibit only one 30 pattern, then the identification of a pattern may be relatively easy. However, if only certain types of transactions for a consumer show a pattern, then the identification can be more difficult. Some embodiments can use keys (K1, K2, ...) to facilitate the analysis of certain types of transactions, where a key can correspond to a type of 12 transaction. The keys also allow identification of transactions as being relevant for a current task (e.g. associated with a current transaction). [0070] Adding to the complexity can be whether the path to a particular transaction has an impact on the pattern, e.g., a pattern that exists only when certain 5 transactions precede or follow a transaction. Embodiments can store transaction data associated with a specific order of keys (e.g. K1, K3). In this manner, the data for that specific order can be analyzed to determine the pattern. The order of keys also allows the further identification of relevant transactions. [0071] All of this complexity can be further compounded in instances where a 10 certain path (sequence of two or more transactions) can have more than one pattern. Embodiments can use certain functional forms to help identify different patterns. In some embodiments, periodic functions are used, e.g., e-wt, where w is a frequency of the pattern. In one embodiment, the frequencies are pre-selected thereby allowing an efficient determination of the patterns. Further, the frequencies can be identified 15 by an associated wavelength, or wavelength range. Counters can be used for each wavelength range, thereby allowing a pattern to be very quickly identified by analyzing the values of the counters. [0072] Various embodiments can handle certain ones or all of these instances of complexity. Herein, examples of lower complexity are introduced first in order to 20 gain an understanding of the basic concepts, and examples of higher complexity are added later. [0073] FIG. 3A is a flowchart illustrating a method 300 for analyzing transaction history associated with a consumer according to embodiments of the present invention. For example, the previous transactions 210 can be considered as the 25 transaction history. In one embodiment, transactions within a specific time period are analyzed, e.g., last year or within a certain time window (e.g. shown start 203 to end 205). In another embodiment, all transactions before an analysis time are analyzed as part of the transaction history. The transactions can also be filtered based on certain criteria, such that only certain types of transactions are analyzed. 30 The transaction history can include valid and fraudulent transactions. All or parts of method 300 or other methods herein can be performed by a computer system that can include all or parts of network 26; such a system can include disparate subsystems that can exchange data, for example, via a network, by reading and 13 writing to a same memory, or via portable memory devices that are transferred from one subsystem to another. [0074] In step 310, a computer apparatus (e.g. all or portions of network 26, such as database 26b and analyzer 26c) receives data associated with transactions 5 previously performed by the consumer. Each transaction can have any number of pieces of data associated with it. For example, the data may include categories of an account number, amount of the transaction, a time and date, type or name of product or service involved in the transaction, merchant name or code (mcc), industry code, terminal field (whether a card is swiped), and geographic location 10 (country, zip code, ...). In one embodiment, a merchant could be a whole chain or a particular store of a chain. In some embodiments, the transaction data can also include video and/or audio data, e.g., to identify a person or a behavior of a person. The transaction data can be different for each transaction, including the account number. For example, the consumer can be identified with the account number and 15 other account numbers of the consumer can be included in the analysis of the behavior of the consumer. [0075] In step 320, each transaction is associated with one or more keys ( e.g., K1, K2, ...). In various embodiments, a key can includes parts of the transaction data and/or data derived from the transaction data. For example, a key could identify the 20 transaction by including one or more of an account number (or other identifying alphanumeric code), a time and date, merchant name, industry code, and geographic location (country, zip code, ... ). A key could also be composed of results from an analysis of a transaction, e.g., whether the transaction is a card-present transaction or a card-not-present transaction could be determined from the 25 transaction data and included in the key. [0076] Each piece of data of a key is referred to as a key element. A longer key can have more key elements and may be a more selective identifier of a type of transactions. Thus, each transaction can be associated with different keys, each with a different scope of specificity for characterizing the transaction. 30 [0077] FIG. 3B shows a mapping module 392 that receives transaction data 390 and provides keys (e.g. K1 and K2) that are associated with the transaction data according to embodiments. In the simple example shown, the transaction data 390 includes a zip code, merchant code, and account number. Mapping module 392 14 determines that there are at least two keys K1 (zip, account #) and K2 (mcc, account #) associated with the transaction data. These keys can be used to track various levels of detail about transactions across, for example, multiple zip codes, merchant codes, and account numbers. In one aspect, the more keys that are associated, the 5 more various information is tracked. Mapping module 392 may be performed in various ways. For example, U.S. patent No. 7,227,950 to Faith et al. describes some implementations using doors and locks for associating transaction data with a key. [0078] In some embodiments, mapping module 392 can have a prescribed set of 10 operations, which can provide a various number of associated keys depending on the transaction data received. In one embodiment, these operations can be performed in the same order for each set of transaction data that is received. In other embodiments, the order and specific functions performed by mapping module 392 may change depending on the transaction data and intermediate data derived 15 therefrom. For example, a different set of mapping functions may be used for particular account numbers, which can result in more information being tracked for a particular consumer (e.g. if the consumer spends a lot of money or is associated with a lot of fraud). Mapping module 392 can retrieve data or functions from a memory in order to provide a result tailored to the received transaction data. 20 [0079] Referring back to FIG. 3A, in step 330, pairs of correlated keys (e.g. a key pair <KI:KF>) are determined based on whether transactions associated with an initial key (KI) are correlated with transactions with a final a final key (KF). A first (initial) transaction can be correlated with a later (final) transaction. The initial key and the final key may be the same or different from each other. For example, a transaction 25 at one merchant may be correlated to a later purchase at another merchant, which might occur if the merchants are near to each other. In one embodiment, a group of more than two keys could be correlated together, e.g. a group of three keys can be correlated. [0080] In one embodiment, the transactions are correlated if the two transactions 30 appear a significant number of times. A proximity in time may also be used as a criteria. The likelihood of two transactions being correlated typically is reduced if more key elements (e.g. transaction data) is used in the keys. In one embodiment, the two keys of a key pair have the same level of specificity. 15 [0081] Transactions can be correlated in multiple ways depending on how many keys are associated with each transaction. Thus, two transactions can contribute to more than one key pair, when the transactions are associated with multiple keys. For example, if an initial transaction is associated with two keys and the final 5 transaction is also associated with two keys, then there could be four resulting key pairs. [0082] A transaction may be correlated to another transaction only via certain keys. For example, a first transaction T1 is associated with keys K1 and K2, and a second transaction T2 is associated with keys K3 and K4. If <K1:K2> is a correlated key 10 pair, then data for transactions T1 and T2 are associated with the key pair <K1 :K2>. But if <K3:K4> are not correlated, then the key pair <K3:K4> is not tracked, and thus no transaction data is associated with it. Effectively different keys for the same transaction can be viewed as different transactions. [0083] In step 340, for each correlated key pair, time information associated with 15 transactions for that key pair or other key group is stored (e.g. in transaction history database 26b). In one aspect, a key pair identifier (e.g. a unique ID number) is associated with the stored time information. As examples of an association, a key pair identifier could point to the time information, the time information could be stored in a same row as the key pair identifier, and the key pair identifier could be stored 20 associated with the pointer. [0084] In some embodiments, the time information for the key pair <K1:K2> can be stored in a database table that can be accessed with a query containing K1, K2, or the combination (potentially in the order of K1:K2). For example, a search for K1 and/or K2 can provide the associated identifiers. In one embodiment, a hash of each 25 key of a pair is also associated with the key pair identifier, so that information for each key can be indexed and found separately. For example, hashes of K1 and K2 can be stored in a lookup table so the key pair identifiers (and thus the key pair information) can be easily found. Thus, storing time information in association with certain key pairs can allow the time information for specific types of transactions to 30 be easily accessed. Also, such organization can provide easier analysis of the data to identify patterns for specific key pairs. [0085] In one embodiment, the time information can be an absolute time. For example, the time and date for all transactions having K1 or K2 can individually be 16 stored for the key pair <K1:K2>, or both stored for each instance of correlation. Other data can be stored as well, such as whether the transaction is K1 or K2 and other data not included in the keys, such as an amount of the transaction. When a key pair is <K1:K1>, the date and time may only need to be stored once. 5 [0086] In another embodiment, the time information can be an elapsed time. For example, the elapsed time may be the time elapsed between a transaction with K1 and the next transaction with K2 for the correlated <K1 :K2> pair. In this embodiment, K1 is an initial key and K2 is a final key. [0087] In step 350, relevant key pairs are selected. The relevant key pairs may be 10 determined based on a particular task that the transaction history is being used. For example, if the task is to determine whether to authorize a new transaction (e.g., current transaction 230 in FIG. 2A), then the relevant keys pairs would the pairs that include keys associated with the new transaction. In one embodiment, the relevant key pairs are all of the key pairs that are associated with the current transaction as a 15 final key. [0088] In step 360, a pattern analyzer (e.g. transaction analyzer 26c) determines one or more patterns of the previous transactions from the time information for the relevant key pairs. As the time information is organized with an association to the relevant key pairs, the pattern analyzer can easily obtain the specific data needed. 20 [0089] For example, assume that FIG. 2A shows all of the transactions with key K1 (i.e. each of the transactions have the same key). The pattern analyzer can obtain this time information by making a query for the key pair <K1:K1>. The time information could be stored as a list of the transactions in chronological order. The occurrences of the transaction can then be analyzed (e.g. Fourier analysis or other 25 functional analysis) to identify a pattern of the times and dates of these transactions. As shown, the transactions are modeled with a periodic function (such as a sine or cosine), which approximates the occurrences of the transactions. Parameters of the function(s) can be modified until a good approximation of the transactions occurring at peaks of the function(s). As shown, pattern 220 exhibits a relatively long 30 wavelength with groups of transactions at the peaks of the pattern. [0090] As an example of a different pattern, FIG. 2B shows a plot 250 of previous transactions 260 of a consumer as analyzed according to embodiments of the present invention. In a case where FIG. 2B is for a different key pair <K2:K2>, the 17 data only for that specific key pair can again be accessed easily as the data is already stored associated with the key pair. Thus, pattern 270 for the previous transactions can be identified by only analyzing the transactions associated with the key pair <K2:K2>. Predicted or current transactions 280 can be then analyzed in 5 relation to pattern 270. If both previous transactions 210 and 260 were analyzed as a single set of previous transactions for a consumer, the different patterns 220 and 270 would be harder to identify. Other more efficient methods of determining patterns are discussed later. [0091] In step 370, one or more indicia of the pattern can be obtained. The indicia 10 may be any characteristic of a consumer's transaction pattern, e.g. a numerical value. In one embodiment, the indicia is how a specific transaction relates to an overall pattern of the consumer's transactions. The indicia can also relate a current transaction to patterns of other entities, such as certain demographics or fraudulent patterns. 15 [0092] In various embodiments, the indicia may be a number of transactions in a time range or the probability (or other measure of likelihood) at a given point in time, e.g., as calculated from a value of the pattern function at the point in time. For example, if authorization for a current transaction is requested, the indicia can include the probability for a transaction at the time of the current transaction (e.g. 20 transaction 230). In one embodiment, for a predicted transaction, the indicia can include a probability and a time window of when a high probability for the predicted transaction occurs. The time window can be measured from a time when the analysis is being done (e.g. at the end time 205). The time window may be specified in any number of ways. For example, the time window may specify a start date/time 25 and an end date/time. [0093] In an embodiment where a current transaction has multiple keys associated with it, the indicia (e.g. the probabilities) could be summed. For example, assume that a current transaction has both keys K1 and K2 associated with it. Thus, patterns 220 and 270 both might apply to the transaction. The indicia of both these patterns 30 can be summed, as the total probability for the transaction is affected by both patterns. In one embodiment, having a transaction associated with multiple keys can result in a summing to determine overall likelihood, and separating out the keys can allow the patterns to be more easily identified. In another embodiment, the likelihood values are analyzed separately, as mentioned below. 18 [0094] In step 380, the indicia from one or more patterns can be used to determine a total likelihood, which can be used to determine an action. For example, the indicia can be used to determine a risk score, which can be used to determine whether to authorize a current transaction. An action can also include whether to 5 pre-authorize a transaction or send an incentive (e.g. a coupon). In various embodiments, the total likelihood can correspond to a likelihood that a transaction is fraudulent, a likelihood that a transaction will occur at a specific absolute or relative time, a likelihood (e.g. a percentage) that one consumer's transaction pattern is similar to another consumer 's transaction pattern. 10 [0095] In some embodiments, the indicia can be input into a modeling function as part of the determination of the total likelihood. In various implementations, the modeling function can be an optimization function (e.g. a neural network) or can be a decision tree (e.g. composed of IF THEN logic that compares the indicia to one or more cutoff values). In one embodiment, an optimization function can be trained on 15 previous transactions, and thus can determine whether a current event (e.g. a transaction) fits previous patterns by a particular entity (e.g. a consumer or merchant) to a sufficient degree to perform an action. The optimization algorithm can also be trained using previous patterns from multiple entities. In another embodiment, the number of associated keys from step 320 relates to the number of 20 inputs into the modeling function. The relationship is not necessarily one-to-one as similar keys (e.g. ones of a same category) may be combined (e.g. same key elements, but just different values), but there may be a correspondence between the number of different types of keys and the number of inputs. [0096] Examples where key pairs have different keys 25 [0097] The above examples for identifying a pattern specifically addressed instances when the key pairs were both the same key. In such instances, the absolute times of the transactions can be plotted and fit to a function. However, when the transactions are from two different keys, the identification of a pattern can be more difficult. In these instances, elapsed time (time interval between two 30 events) may be used. [0098] In such an embodiment, the key pair can have an initial key and a final key, as mentioned above. The initial key occurs first in time and the second key occurs second in time. The elapsed time would be the time between the final key and the 19 initial key. Thus, if two keys K1,K2 are correlated there can be two key pairs <K1:K2> and <K2:K1>. Note it is possible that only one of these key pairs exists, since it is possible that the other key pair is not correlated. In one embodiment, where K2 is a current transaction, the elapsed times for a K2 transaction since the 5 last K1 transaction are analyzed. [0099] FIG. 4 is a plot 400 of a number of transactions at certain elapsed times between a final event (with key KF) and an initial event (with key KI) of a correlated key pair according to embodiments. Plot 400 can be considered as a histogram. The X axis is elapsed time between a final event (e.g. a transaction) and a correlated 10 initial event. Any unit of time may be employed, such as minutes, hours, days, weeks, and even years. The Y axis is proportional to a number of transactions. Each bar 410 corresponds to the number of transactions at an elapsed time. Each bar 410 can increase over time as new transactions are received, where a new transaction would have an elapsed time relative to a correlated initial event. Note 15 that more than one event pair can have the same elapsed time [0100] In one embodiment, the X axis can have discrete times. For example, only transactions for each day may be tracked. Thus, if the initial event was the start of a month, then the number of discrete time periods would have a maximum of 31 days. In such an embodiment, elapsed time values within a certain range can all contribute 20 to a same parameter, and bars 410 may be considered as counters. For example, if the discrete times were by day, any two transactions that have an elapsed time of 12 days since a correlated KI event would both cause the same counter to be increased. In one embodiment, these counters are the time information that is stored in step 340 of method 300. In some implementations, the time ranges do not 25 all have the same length. For example, the time ranges closer to zero can have a smaller length (e.g. just a few minutes) than the time ranges further from zero (e.g. days or months). [0101] A pattern 420 can be discerned from the elapsed times. As shown, pattern 420 has a higher value at elapsed times where more transactions have occurred. In 30 one embodiment, pattern 420 could simply be the counters themselves. However, in cases where the time intervals are not discrete or have a small range, bars 410 might have zero or low value at times that happen to lie between many transactions. In these cases, certain embodiments can account for transactions at a specific time as well as transactions at times that are close. For example, as shown, a function 20 representing a pattern of transactions begins curving up and plateaus near the cluster 460 of transactions to form a peak 430. In one embodiment, each time point of the function can have a value of a moving average of the number of transaction within a time period before and after (or just one or the other) the time point. In other 5 embodiments, function can be determined from interpolation or other fitting method (e.g., a fit to periodic functions) performed on the counters. [0102] In some embodiments where elapsed time is being used, the predicted or current transaction can be analyzed relative to time zero, and the indicia may be taken from the pattern at the elapsed time since a last transaction of KI. One 10 indicium may be a time window that a transaction is likely. A width of the function at specific values or times may then be used as the time window [0103] In one embodiment, a full width at half maximum may be used, such as the width of peak 430. In another embodiment, the window (e.g., 440) above a threshold value 450 is used, or just part of this window, e.g., starting at the time where pattern 15 420 is above the threshold and ending at the top (or other part) of peak 430. In yet another embodiment, the time window may have a predetermined width centered or otherwise place around maximum or other value above a threshold. [0104] In embodiments using a threshold, the value of the pattern function may be required to be above the threshold value before a transaction is considered likely 20 enough to occur to send an authorization to a merchant. Multiple threshold levels can be used, with the various levels potentially being used to determine when, how, and what incentives to use. The modeling function mentioned above for step 380 may be used to perform any of these determinations. [0105] In one embodiment, a threshold determination could be whether a counter 25 has a high enough value (absolute or relative to one or more other counter). In another embodiment, a threshold level can be relative (e.g. normalized) compared to a total number of transactions. A normalization or determination of a threshold can be performed by adjusting the level depending on the low values of likelihood of a pattern, e.g., a peak to trough height could be used. In one aspect, the troughs may 30 be offset to zero. [0106] Storing time information that includes a number of transaction at certain elapsed times, one can not only handle paths (such as initial key to final key), but one can also easily identify multiple patterns. Each peak can correspond to a 21 different pattern. For example, each peak can correspond to a different frequency of occurrence for a transaction associated with the final key relative to a transaction associated with the initial key. In one embodiment, the time information for the elapsed times can be stored by storing a time of when both events occur. In another 5 embodiment, time information can store the elapsed time as one value. In yet another embodiment, the time of one event might implicitly include the time of the initial event (e.g. when the first event is beginning of a month or other fixed time period). [0107] From FIG. 4, one can quickly identify one predominant pattern (peak 430) 10 with a long wavelength (short frequency), which does not occur very often, and three minor peaks with higher frequencies. Accordingly, if the transactions of FIG. 2A and 2B were both patterns for the key pair <K1 :K1>, using elapsed time, both patterns 220 and 270 could be identified. However, the determination of a pattern might still take significant computational effort if the pattern can have any functional form. 15 [0108] Ill. DETERMINING PATTERNS USING e'w WITH SET FREQUENCIES [0109] Some embodiments use certain functional forms to help identify different patterns. As mentioned above, periodic functions can be used, e.g., e'd, where w is a frequency of the pattern. For example, each bar (counter) 410 of FIG. 4 can correspond to a different frequency. The total probability V of a K2 transaction 20 occurring at a time t after a K1 transaction can be considered as proportional to SCe' , where C, corresponds to the counter value at the frequency w and w runs w over all of the frequencies. Cw can be considered a coefficient of the periodic function e'w at a particular frequency. Thus, conceptually, a probability can be calculated directly from the above formula. 25 [0110] In one embodiment, the frequencies are pre-selected thereby allowing an efficient determination of the patterns. Further, the frequencies can be identified only by the associated wavelength, or wavelength range. Note that in certain embodiments, the use of e'w is simply a tool and the actual value of the function is not determined. 30 [0111] FIG. 5A shows a table 500 that stores time information for a key pair <KI:KF> according to embodiments of the present invention. The table 500 stores information for elapsed times between transactions associated with the particular key 22 pair, e.g. as performed in step 340 of method 300. Table 500 can also store amount information for the transactions. Table 500 can be viewed as a tabular form of plot 400 along with all the possible variations for different embodiments described for plot 400. 5 [0112] In one embodiment, each column 510 corresponds to a different time range. The time range may correspond to ranges mentioned above with reference to FIG. 4. As shown table 500 has 6 time ranges, but any number of time ranges may be used. The time ranges can be considered to correspond to different functions that approximate the transaction patterns of a consumer or other entity. For example, 10 each time range can correspond to or be considered a different frequency w for e". [0113] In some embodiments, table 500 only has one row. In other embodiments, the rows of table 500 correspond to different dollar amounts (or dollar amount ranges). Thus, each time range may have subgroups for set ranges of amounts (e.g. dollar amounts). The organization is similar to a matrix, where a row or a 15 column can be viewed as a group or subgroup. Although five amount ranges are shown, table 500 can have any number of dollar amounts. In some embodiments, there is only one row. i.e. when dollar amounts are not differentiated. Note that the convention of row and column is used for ease of illustration, but either time or amount could be used for either row or column (each an example of an axis). Also, 20 the data for a table can be stored in any manner, e.g. as a single array or a two dimensional array. [0114] The values for the matrix elements 520 correspond to a number of KF transactions that have elapsed times relative to a KI transaction that fall within the time range of a particular column 510. In one embodiment, each newly received K2 25 transaction can cause a box (element) 520 of the table (matrix) 500 to be increased. The value can be incremented by one for each transaction, or another integer or non-integer value. The value can also be a complex number, as described below. In another embodiment, a table can be required to have a certain total of all values, average of the values, minimum value in any matrix element, or other measure of the 30 values in the table. Such a requirement can ensure that enough data has been received to provide an accurate pattern. [0115] The values of the matrix elements can be used to determine the pattern for the key pair <KI:KF>, e.g. as part of step 360 of method 300. For example, matrix 23 elements with high values relative to the other matrix elements can indicate a pattern of transactions in the corresponding time range, which can correspond to a particular frequency w. In another embodiment, one could view each matrix element in isolation to determine whether a transaction is likely. For example, if a matrix 5 element exceeds a threshold value, it may be determined that a transaction is likely to occur in that time range. The threshold can be determined in various ways, for example, as a function of a sum of all of the matrix elements, or equivalently can be fixed with the matrix elements being normalized before a comparison to a threshold. Thus, step 360 can be accomplished easier based on how step 340 is done. 10 [0116] As mentioned above, the time ranges can all be of the same length (e.g. 24 hours) or be of varying lengths. In one embodiment, the first column is of very short time length, the second column is of longer time length, and so on. In this manner, more detail is obtained for short wavelengths while still allowing data to be stored for long wavelengths without exhausting storage capacity. In another embodiment, 15 dollar amount ranges are progressively structured in a similar manner as the time ranges can be. In one implementation, the dollar amount range can be used to track the likelihood of transactions having certain dollar amounts. A predicted dollar amount for a likely transaction can be used to determine a price range in which a pre-authorization is valid. Also, a dollar amount for a current transaction can be 20 used to determine a specific likelihood function that corresponds to the amount, e.g., a row of the table. [0117] FIG. 5B shows a plot 510 for use in determining the time ranges for table 500 according to an embodiment of the present invention. The X axis corresponds to the column numbers. The Y axis corresponds to the time of particular column in 25 minutes. For example, the first column includes times between the first data point at time domain zero and the data point at time domain 1. Due to the large scale of the Y axis, the second data point appears to be at zero, but is simply quite small relative to the maximum value. [0118] The wavelength A of a pattern corresponds to the time range of a column. 30 For embodiments, using time relative to another transaction, then the A is the time between transactions. In one embodiment, 16 time domains (ranges) are selected as follows: Ao is under 1 minute, A, is between 1 minute and 2.7 minutes, A 2 is between 2.7 minutes and 7.4 minutes, A 3 is between 7.4 minutes and 20 minutes, 24 and A 15 is over 1.2 million minutes. In one aspect, smaller time ranges can provide greater accuracy, but can result in more total time ranges, thus using more storage. [0119] The amount values can also be used to determine patterns for transactions of certain dollar amounts. If the amount is not of concern, then the values in a 5 column can be summed to get a total value for a certain time range. The amounts can also be incorporated into the mathematical concept introduced above. For example, in mathematical notation, a value function can be defined as V = ZCAevt , where A is an amount of a transaction. Ignoring Cw for the moment, this W equation provides V=e'n(A)*ew= e(iwt+In(A)), as X = eln(x). Thus, if the amount ranges are 10 expressed as In(A) then calculations can be performed without performing any exponentiation, since In(A) and iwt both lie in the exponent. In one aspect, to actually obtain the value of V, a time t can be plugged in. But in practice, this does not need to be done as for most purposes, one can just see what wavelengths have the highest values in the matrix elements. 15 [0120] For eight amount ranges and 10 time ranges, the table can be defined as follows. Using group operations, A is defined as: A = eLa so In(eLa)=La, with La being an index that runs 1:8. Therefore V is rewritten: V=e(wt+1n(A)) (iwt+La). If Liwt is an index from -1:8, then a cycle can be defined as e'm=eLi. Therefore V=e (Liwt+La) or In(V) = Liwt+La. Accordingly, Liwt and La can be linearly related. 20 [0121] When a transaction is received, the amount and corresponding elapsed time for a particular key pair can be used to determine a corresponding matrix element for the key pair table. The values in the matrix elements can be normalized across one table and across multiple tables. For example, a value can be divided by a sum for all the values of a particular key pair table. Also, a sum can be calculated for all 25 values across multiple tables, and the values for each table divided by this sum. As part of a normalization, the value for a matrix element may be decreased when some of the data used to determine the value becomes too old. For example, for a time range that includes short time intervals, counts from transactions that have occurred more than a year ago may be dropped as being out of data since short timeframe 30 patterns can change quickly. [0122] In one embodiment, the values in the matrix elements can be smoothed. That is the values in one matrix element can be altered (smoothed) to account for values in other (e.g. neighboring) matrix elements. The smoothing can occur 25 independently across time and amount. For example, assume the matrix elements for dollar amount Al for consecutive time ranges are 0,20,0. These values might cause edge effects in the calculations as the probability jumps up and then jumps down. Therefore, a calculation for a new transaction at the end of the first time 5 range might actually be part of the pattern for the next time range, but this would not be identified. [0123] In one embodiment, the probability for the 1 st and 3 rd time ranges can be taken to not be zero but some larger value due to a smoothing of the value 20. The middle bin might get a slightly lower value due to the smoothing. Such smoothing 10 can account for statistical variation in the transaction history. In one aspect, the smoothing is because the matrix elements are not in frequency, but in time. If the matrix elements were in frequency and then converted to time, the conversion would smooth out the function. Instead of the conversion, embodiments can treat the bins as being exactly in the time domain and then smoothing them out in that 15 representation. The smoothing can provide similar results as discussed with the curve near peak 430 of FIG. 4. [0124] In some embodiments, the frequency w can be defined as being inversely proportional to the wavelength A: woc2Tr/A. In one embodiment, the proportionality constant is 1, which can correspond to elapsed time 0 being considered a maximum 20 probability. In another embodiment, the proportionality constant is 2, which can correspond to elapsed time 0 being considered a minimum probability. Effectively, the time range can be considered the full wavelength or half of the wavelength. Depending on which convention is chosen, the resulting pattern will have a different shape, which can have consequences when the matrix elements are smoothed. In 25 embodiments using time ranges, each matrix element does not correspond to just one frequency, but a range of frequencies. However, a single frequency can be approximated. In various embodiments, the frequency can be from the median frequency for the time range, the frequency for the start of the time range, the frequency for the end of the time range. 30 [0125] In various embodiments, tables for different key pairs can have different time ranges and/or amount ranges. If such differences do occur, the differences can be accounted when a summing operation is performed across the tables. 26 [0126] In other embodiments, specific amount ranges or time ranges can be suppressed. For example, if only certain types of patterns (e.g. only certain frequencies) are desired to be analyzed, then one can suppress the data for the other frequencies. In one embodiment, the suppression is performed with a mask 5 matrix that has zeros in frequency columns and/or amount rows to be suppressed. Thus, one can just multiply the matrices to obtain the desired data. The amount ranges can be similarly suppressed. When suppressing certain frequencies, these mask matrices can act similarly to a high pass, low pass, or notch filters. For example, if one wanted a coupon to be good only for 7 days, and it takes 1 day to 10 create the coupon, the desired time window is any time range that includes those 6 days. Accordingly, the time information for transactions outside the time window can be suppressed as not being of interest. [0127] IV. ORGANIZING MANY TABLES FOR DIFFERENT KEYS [0128] As discussed above, tables can be organized as being associated with a 15 respective key pair. For a single consumer, there could be many key pairs that are correlated based on that consumer's transaction history, and that are thus tracked. A single table could be used for all transactions for that person (effectively just one key equal to the person), but to have more finely tuned predictive capabilities, more information can be used. Thus, multiple key pairs can be tracked for the consumer, 20 with the keys including various identifications of where transactions occurred and what was bought. In this manner, a more detailed path to current or predicted transactions can be known. Below are further details on the organization of the keys and tables. [0129] A. Key Hierarchy (which key pairs to track) 25 [0130] As described above, an event (e.g. a transaction) has a set of event data associated with it. The event data can be manipulated to obtain one or more keys that associated with the event. Each key includes one or more key elements, which can be obtained from the event data. The key elements can be combined in numerous ways to obtain keys that are associated with an event. As one adds more 30 key elements to a specific key, the key generally becomes more selective in terms of number of events to which the key is associated. [0131] Example of categories of key elements are: country or other large region (e.g. Europe); zip code of merchant or of consumer; industry code (e.g., travel); 27 product code (e.g., gas, food, etc.); merchant name; consumer or consumer type (e.g. a certain demographic); and date. Different tables can have different lengths for each key of the key pair, i.e. different number of key elements used. [0132] FIG. 6A shows transaction data 600 with example categories of key 5 elements 610 listed according to embodiments. Key K1 620 shows an example key K1 having specific values in certain key element categories of transaction data 600. The key elements include country, zip code, a merchant code, an industry code, account number, and merchant name. Note that the account number and merchant name can be used to identify a particular entity (e.g. consumer or merchant) for 10 which the transaction data may be used to update tables for the particular entity, and can be included in a separate identifier from the key. As another example, the key could be for any consumer or merchant. Thus, one key could then just be US 94566 4812 3. [0133] The US signifies that the country of the transaction is the US. The country 15 typically is the location of the merchant, as opposed to a person's home address when the person is buying over the Internet. The number 94566.is the zip code of the merchant. The number 4812 is the merchant code. The number 3 is the industry code. [0134] Examples of other keys that can be made from the key elements include K2 20 630 {US}; K3 640{94566}; K4 650 {94566, 4812}, and K5 660 {945**, 4812}, where * is wildcard value. Examples like K5 show that only part of a key element can be used. Using only part of a key element broadens out the key, i.e. makes it less selective. Such broadening can be used to capture more transactions in a table, but also where the data in the key element may be unreliable. For example, the specific 25 zip code may not always be accurate. Also when a merchant name is a key element, the name may be XYZ, XYZ inc., XYZ, inc., or other variations. Allowing wildcards or just suing only part of a key element can accommodate instances when there are some errors or variations in the key. [0135] Accordingly, a single transaction can be represented with many different 30 keys. In particular, if the key elements can be used independent of other key elements, the number of possible categories (e.g., country and zip code) of key pairs is N*N, where N is the number of key elements. For example, <zip codel zip code> or <country, merchant codelzip code> would be different categories. As each of these key elements can have different values, the number of total possible key pairs can be extremely high. Also, the number of key elements can even be larger when key elements are new values derived from the transaction data. [0136] B. Correlation Of Keys To Determine Which Key Pairs To Track 5 [0137] The total number of possible key pairs (e.g. for every zip code) may be too many to track. Thus, not every possible combination of keys will generally be tracked. For example, key pairs that exhibit a correlation may be tracked. Often, for a table to be tracked, at least one of the key elements (e.g. a consumer identifier or merchant) will be shared by the key pair. In other instances a table may be tracked 10 for very broad characteristics, e.g., a transaction pair from one country to another. However, in such instances, the transaction pair from which an elapsed time is calculated may be for a same account or consumer. [0138] To determine whether to track a certain key pair, a sampling of transactions may be taken to identify transactions that occur often in relation to each other. A 15 threshold can be used to determine whether a key pair will be tracked. Key pairs with long frequencies may require data over long periods of time to determine whether they are significant enough to track. In one embodiment, as long as one matrix element would have a significant value, then the whole table is tracked. [0139] FIG. 6B shows a set 680 of correlated key pairs being tracked for account 20 entity 670 according to embodiments. Key pair 691 tracks patterns of K4 transactions occurring after transactions in zip code 94566 with merchant code 3510 (key is {94566, 3510}. Key pair 692 tracks patterns of K5 transactions occurring after transactions in zip codes 945** with merchant code 3510 (key is {945**, 3510}. Key pair 691 tracks patterns of K3 transactions occurring after K4 transactions. 25 [0140] Other entities can have key pair tables tracked as well. For example, a merchant can have transactions tracked via different key pairs. Also, groups of consumers (e.g. by zip code) can be tracked as a single entity. Consumers, demographics (affinity groups), and merchant are examples of entities whose behavior can be tracked using different sets of key pair tables. 30 [0141] In one embodiment, certain consumers may be grouped initially as part of a demographic to obtain more data points in order to identify the key pairs that are correlated. Thus, the transactions of a group of consumers can all be analyzed together to determine correlations of transactions having certain keys. Consumers may even be defined in terms of demographic groups. Besides using just a sampling to determine which keys to track, certain key pairs can be pre-determined for tracking. For example, a store may want to have transactions at a specific 5 location (or all locations) tracked. [0142] There can also be a certain hierarchy as to what combination of key elements are tracked as key pairs. For example, there may not be enough transactions to determine correlations for a particular consumer at a specific merchant location within a particular zip code. Thus, the keys may be broadened out 10 to only include the merchant, or only include the industry code. Such broadening can be used to capture correlation when the whole key element may not have enough data to exhibit correlation. [0143] In another embodiment, a broad key may be combined with a very narrow key to obtain specific information, but still ensure enough transaction data to 15 determine statistically significant correlations. For example, certain key element categories, such as country, cover a large number of transactions. Thus, if a very selective key element is desired (e.g., merchant name), then this key element can be paired with the country key element to create a key that has a significant amount of transactions to determine whether correlations exist. 20 [0144] As another example, a key can include a specific time as well. In one embodiment, a key includes time (e.g. 4 hour blocks of a day, day of the week, month of the year) only when the rest of the key elements of the key are quite broad. Examples of broad key elements include all transactions at a merchant, all transactions for a specific affinity group (group of similar consumers), all transactions 25 in the US, or all transactions that have an initial key with US and a final key with Canada, and card not present transactions from US to Canada. Using these broader key elements with a specific key element (like time) can ensure that there will still be a large amount of data for the table to convey meaningful results. [0145] In some embodiments, certain key pairs may also be tracked when the 30 transaction activity is important. For example, if a lot of fraud occurs at specific times, then a key pair may be tracked. Even if there are not a lot of data points, the information for such a key pair is valuable since the consequences are very cost sensitive. As another example, charges for internet dating at certain time and in a 30 certain country can have high instances of fraud. Thus, the specific country and time may be included in a key of a key pair as a significant amount of money could otherwise be lost to fraud. [0146] Transaction activity can also be important when the profit for a particular key 5 pair is high. In such instances, the key pairs can be more selective since the specific knowledge of a selective key pair can contribute significantly to an overall profit. For example, a corporate account for a manager of a performing artist might have a very large amount of purchases, particularly expensive purchases, such as hotel rooms for 20 people. Since the profit is quite large, it is important to have specific 10 knowledge of the transaction patterns. Such knowledge can be used to more accurately and quickly authorize transactions, and to predict when transactions might occur so that incentives (e.g. coupons) can be provided to ensure that the transactions do occur. In all of these instances of important transaction activity, multiple key pair tables may be used for a particular entity. 15 [0147] In one embodiment, the amounts of a transaction can also be correlated. For example, for a certain key pair, the amount of the first transaction to the amount of the second transaction can be correlated. This could be done, for example, by having multiple values per matrix element. Effectively, each matrix element could be a vector. Each value of the vector would correspond to a different amount for the 20 initial transaction of the key pair. [0148] Which key pairs are tracked for different entities can be updated at different times, e.g. at certain fixed times (e.g. periodically) or when certain events occur. For example, every month new data points may be used to add new tables, or remove tables where the correlation is no longer significant. The existing tables can be 25 updated periodically in batches (e.g. every day, week, ..), or can also be updated individually after every transaction. In one embodiment, key pair tables may be updated at night relative to where an entity, i.e. merchant or consumer is located. [0149] C. Filtering [0150] As there are numerous tables, each tracking different information for a key 30 pair (or for a larger group of correlated keys), embodiments can provide a filtering mechanism for accessing specific data. In one aspect, the keys and/or key elements are used to retrieve the desired data. As each table has an initial key and a final key associated with it, the keys can be used in a query to retrieve the tables. When 31 three or more keys are associated with a table, there may be intermediate keys, each of which can be used to retrieve tables having a particular key in a particular position. [0151] In some embodiments, a matching function can receive a key and return 5 one or more tables associated with the key. Examples of results include a list of pointers that point to each of the tables associated with that key and the tables themselves. In one embodiment, the matching function involves a query. For example, a key (or a derivative of the key, such as a hash) can be stored with a table (or a pointer to the table) and a query can be placed to find the tables with the 10 associated key. In one embodiment, this could be done by having each key of a pair in a different field of larger object (e.g. a table or other data structure) that includes the key pair table. In another embodiment, a separate lookup table may be used. [0152] A query can include an input key, and all tables associated with that input key can be returned. In various embodiments, the query can specify the level of 15 matching. In one embodiment, the query can specify that all of the key elements of the input key are matched exactly. That is if a country, merchant code, and zip code are entered in the query then only tables that have keys with the exact country, merchant code, and zip code, with no less and potentially no more key elements, are returned. In another embodiment, more key elements may be allowed. In yet 20 another embodiment, the match of each key element may be allowed to not be exact, as described herein. [0153] FIG. 7A shows different queries and results according to embodiments. Query 705 is provided to return tables that are for key pairs with K4 as the initial key. The result 710 shows a list of the tables that are returned from the query. This may 25 be done, e.g., when K4 is an initial event, such as the beginning of a day. See section V.A for an additional description of such events. Patterns in the resulting matrices can then be analyzed to determine patterns in events in relation to a K4 initial event occurring. [0154] Query 715 is provided to return tables that are for key pairs with K5 as a 30 final key. The result 720 shows a list of the tables that are returned from the query. This may be done, e.g., when K5 is a current transaction for authorization is requested. The time and amount of the current transaction can also be used to select out specific matrix elements of these tables. The selected matrix elements 32 can then be used to determine whether the current transaction is of a normal pattern (e.g. high relative value for the matrix elements) for consumer or is unusual (e.g. low relative value for the matrix elements). [0155] Query 725 is provided to return tables that are for key pairs where the zip 5 code 94566 exists as a key element in the final key. One table of result 730 is for <K4194566>, where 94566 is the entire final key. However, another table of result 730 is for <K46194566,4812>, where 94566 is only one of the key elements of the final key. Queries can also include requests for both initial and final keys. [0156] In another embodiment, the query can specify that the input key only needs 10 to appear. That is one can specify a zip code, and any key pairs that include the zip code, as well as other key elements, can be retrieved. For example, all transactions for a consumer associated with a certain merchant can be accessed by filtering with the merchant ID. One can require the input key to be the only key element in the final key, as mentioned above. A specific entity can also be included in the query. 15 For example, the tables for a specific consumer can be accessed. [0157] When specified in a query or otherwise, the results of a query can be combined into a single table when many tables are returned. For example, a query for a particular key K2 included in a final key for a particular consumer can provide an aggregation of all of the tables for which the query matches. In one aspect, the 20 result can be equivalent to the table <*|K2>, which corresponds to the occurrence of K2 after any transaction. The aggregated table can be provided by: for each matrix element of the final table, summing the corresponding matrix elements from the returned tables. In this manner, more general patterns can be identified, and more specific patterns can also be tracked and identified. For example, via a filtering 25 mechanism, events that have similar data (e.g. all transactions in the US) can be grouped together. The data can be aggregated to determine a pattern for US transactions. [0158] In embodiments where at least some of the tables have time as a key element, filtering on time can provide behavior at points of a day, week, month., etc. 30 For example, one can filter on a specific transaction occurring at 3 am (or a range such as 1 am to 4 am). The tables of transactions that are correlated to this transaction occurring at 3 am are then selected. In one embodiment, one can filter on initial keys that occur at a specific time. Then, the matrix elements of the returned I3I tables can be used to identify the transaction patterns that occur after such transactions. [0159] In one embodiment, the tables can be indexed by the values of the key elements. The key elements that are numbers can directly specify the 5 corresponding table, which can be a specific element of a multi-dimensional array. For example, array valuee, value2, table) can be found with key element of value and value2, which effectively point to the appropriate table. The values could be a zip code that runs from the lowest available zip code to the highest available value. However, such a method can have limited functionality and have large storage 10 requirement, particularly when not every possible value for a key element (e.g. every zip code) is being tracked. [0160] In another embodiment, a lookup table is used to identify the one or more tables matching an input key. Each table that is tracked can be entered as a new entry with an identifier (e.g. a pointer or an alphanumeric value) in the lookup table. 15 The lookup table can be dynamic in that a new entry can be entered at any point. Each entry can have the corresponding input key and final key stored in association with the entry, e.g., in a same row. Once a key is matched the corresponding tables can be identified with the identifier. The entries can be organized by what the values of the keys are (e.g. ascending with zip code), but do not necessarily have any 20 particular organization. In one implementation, the keys are a string of the key elements, which can be hashed. These hashes can be stored instead of the raw values of the keys. [0161] FIG. 7B shows a lookup table 740 of key pair identifiers 750, where each key pair number has a pair of hashes 760 and 770 associated with it according to 25 embodiments. If the filter is searching for tables having a particular final key, the column 770 can be searched for the matching hash. This table may be spread across multiple memories, each corresponding to a different processor or set of processors. Thus, access can be easily parallelized. The processor storing an entry can also store the actual key pair table corresponding to the identifier of that entry. 30 In this manner, the identifiers may not be globally unique, but be unique on a particular processor. [0162] In one embodiment, if there is an organization to the hashes, the search can be smarter than simply starting at key pair # 1. In such situations a binary tree 34 search (or other level of tree) or other methods can be used. Also multiple tables (e.g. with a hierarchy) can be used. For example, a first table can be used for broader key elements, such as country. Based on the country, another table may be selected, where the another table is for keys that include explicitly or implicitly (e.g. 5 based on the first table) the specified country in the key. [0163] In another embodiment, only one key may be stored when the initial key and the final key are the same. Also, the initial or final key may be a wildcard as any key may match (e.g. when the correlation is from any initial transaction to a specific final transaction). 10 [0164] As mentioned above, an exact match can be required. However, in an event that an exact match is not found (e.g. for a specific key pair), an alignment mechanism may be used to identify a similar matching entry. Examples of when such alignment would be performed include: when a specific key for a current transaction is received, but only a broader version of that key is being tracked; and 15 when two entities are being compared and different key pairs are tracked. [0165] FIG. 7C shows an alignment method 700 for finding a similar key when an exact match for an input key(s) is not found according to embodiments. In step 781, one or more keys (e.g. both initial and final key) are received for filtering. In step 782, a hash is optionally calculated for the input key(s). The hash would be 20 calculated, for example, when lookup table 740 is used. In step 783, it is determined whether the hash (or just the raw key) matches to a hash in the lookup table. If there is a match, then the desired key pair matrix (or other pattern object) or just an identifier to obtain the key pair matrix can be retrieved at step 784. If there is not a match, then the input key(s) is modified at step 785. For example, the number of 25 digits in the zip code can be reduced from five to four or to three. In step 786, a new hash is created from the modified key, and the method returns to step 783 to find a match of the modified key. The modified key is broader than the original input key, and thus a match is more likely. [0166] In some embodiments, a match is guaranteed. For example, key elements 30 can be dropped until the key is small enough that it matches with at least one key pair matrix that is being tracked. In other embodiments, a stopping point may be determined for the modification (e.g. a minimum size, i.e. # of key elements or total size of the key or of a key element). And, if no match has been found, then the input 35 key may be dropped from the filtering process. In one embodiment, a key is only dropped if another key for the event is still remaining. [0167] In one embodiment, alignment method 700 may occur in mapping function 392 of FIG. 3B so that the mapped keys are ones that are currently being tracked. 5 Such broadening of a key can also help when certain data is missing or unreliable. In other embodiments, keys output from mapping function 392 may be input into another function (e.g. an update module for updating a table, or a scoring (e.g. probability scoring) module for determining a score associated with the transaction data. 10 [0168] FIG. 7D shows a matching and retrieval module 794 that obtains matching key pair tables based on keys received from a mapping function 792 (e.g. function 392 of FIG. 3B) according to embodiments. Module 794 can receive keys resulting from the transaction data and determine whether the keys correspond to existing key pair tables, e.g. using table 740. After the table has been identified, the data for that 15 table may be retrieved. Module 794 can include an alignment (e.g. implement method 700) as part of the matching function to allow similar as well as exact matches. [0169] D. Updating Tables [0170] After an event (e.g. a consumer transaction) is received, embodiments can 20 determine which tracked key pairs have finals keys that match with the keys resulting from the transaction. As a transaction can be associated with many keys and key pairs, a transaction may cause many tables to have a matrix element updated. For example, the transaction may cause different tables for a specific consumer to be updated. The updates could be for one table for all transactions by that consumer 25 (an example of a general table), and more specific tables for particular zip codes, merchants, and other key elements. The transaction can also cause updates of tables for the particular merchant where the transaction occurred. In one embodiment, method 700 can be used to determine which tables are to be updated. As described in a later section, method 700 may also be used to determine which 30 tables to use to obtain the indicia of a pattern from step 370. [0171] As there are different tables that can be updated, each with a different initial key, the time range (and thus the matrix element) that is updated may be different for each table. For example, when elapsed time is used, the last transaction for each 36 table may be at a different elapsed time since the different initial transactions. The transaction amount would typically be the same, thus the exact row for the matrix element to be increased can be the same, as long as the tables have the same amount ranges. But the column (i.e. time) could be different for each table. 5 [0172] Regarding which time column to update, there can also be more than one column updated for a particular table. For example, a K2 transaction may have different time patterns relative to K1 transactions (i.e., <K1:K2> pair). Accordingly, when a K2 transaction is received, elapsed times from the last two, three, or more K1 transactions could be used to update the table. 10 [0173] In a similar manner, one key pair table could be <*:K2>, which includes correlations from a plurality of initial keys to the K2 key in the same table. Effectively, this table could equal the sum of all tables where K2 is the final key for a particular consumer or other entity. However, if the individual key pairs are not significant enough, the <*:K2> table may be the only table that is tracked. Tables of 15 the type <K1:*> could also be tracked. [0174] FIG. 8 shows different tables updated for a same K5 transaction according to embodiments of the present invention. For the key pair <K4:K5> table 810, the fourth time range is updated as a result of the K5 transaction. The "X" marks the matrix element being changed due to the K5 transaction. For the key pair <K80:K5> 20 table 820, the second time range is updated for the K5 transaction. For the key pair <*:K5> table 830, both the second and the fourth time ranges are updated, as may occur to account for both the <K4:K5> and the <K80:K5> key pairs. For <*:K5>, the X matrix elements could be increased by different values if there were more than one key pair with K5 as a final key for which the elapsed time was in the second time 25 range. [0175] The tables can be updated right after a transaction is received, at periodic times (e.g. every 10 minutes or once a day), or at other times. Also, different parts of a table can be updated at different times. For example, the high frequency (short time frame) matrix elements of the tables can be generated from a list of recent 30 transactions, which can be stored in a local memory (e.g. RAM). As examples, the recent transactions can be the last N (e.g. 10) transactions or all of the transactions in during fixed timeframe (e.g. the last 24 hours). Other tables or parts of tables can be stored in long term memory (e.g. a hard drive). The different short and long term 37 data can be combined into a table, or if one is interested in only short term or long term patterns, only one set of data can be used. Note that such a decision can be similar to using a mask matrix to select only certain time ranges. [0176] In some embodiments, a time of a transaction may not be exact, e.g., a 5 merchant can batch authorization requests (i.e. not doing them in real time). In these embodiments, a transaction can have more than one time or a range of times. Thus, when an elapsed time is calculated and a table is updated, there can be more than one matrix element that is increased. The increase can be partial since the transaction pair is shared over more than one matrix element. 10 [0177] E. Representative Consumers [0178] As mentioned above, the number of tables being tracked for a consumer can be reduced by only tracking key pairs that show a correlation. Even by such a reduction, there still could be too many tables to track. For example, a consumer could still have 4,000 up to a million possible tables. 15 [0179] In one embodiment, to reduce the number of tables, different zip codes of a consumer could be considered the same. For example, a salesperson might have similar transaction history in cities on his/her route. All of these zip codes can be considered to be equivalent, and thus put into one table. A similar treatment can be made for other key elements. Also, in a similar manner, different consumers can be 20 treated as being equivalent. [0180] As mentioned above, certain consumers can be grouped into affinity groups (demographics) in order to obtain more information about correlated keys. In one embodiment, the affinity groups may be used to define a consumer. For example, if a group of consumers had identical or substantially similar transaction histories then 25 separate tables do not need to be stored. When a consumer of the affinity group made a purchase, the tables of the affinity group could be accessed. [0181] Accordingly, the amount of total storage can be reduced by defining a consumer by his/her affinity groups. Instead of storing the redundant tables for each consumer, just one set of tables can be stored. However, it may be uncommon for a 30 consumer to have the same transaction patterns as a particular affinity group. In such cases, the consumer can be defined as being a linear combination of affinity groups, which are each a combination of key pairs. For example, there can be 100 38 affinity groups AG. A consumer can be defined as 10% AG1, 15% AG 23, 30% AG 41, 20% AG 66, and 25% AG 88. A consumer can also have individual tables that are used in combination with the affinity group tables. [0182] A consumer can thus be viewed as a combination of representative 5 consumers (affinity groups). Which representative consumers to use for a particular consumer can be determined by sampling transactions of the consumer. The sampling can be relatively small compared to the total transaction history that would be used if the consumer had his/her own tables. For example, the sample transaction of a consumer can show that he/she has similar transactions to a certain 10 demographic group. The percentage for each affinity group can be determined by a similarity in the tables for the consumer relative to the affinity group. [0183] In one embodiment, the similarity can be defined by taking the difference between each of the matrices (tables) of the consumer from each of the matrices of the affinity group. Where a table exists for the consumer, but not for the affinity 15 group, a table of zeros can be assumed for the affinity group, and vice versa. As an alternative or in combination, an alignment mechanism (e.g. method 700) can be used to obtain more matches between the set of tables for the consumer and the set of tables for the affinity group. [0184] In one aspect, tables for a consumer could be created initially until one or 20 more affinity groups are identified. Certain tables for a consumer could still be kept to ensure that the transaction patterns do not change, thereby causing a need to reevaluate the specific linear combination being employed. Thus, transaction data can be used to determine which demographic a person fits into, as opposed to determining what a demographic is based on similar consumers. 25 [0185] In one embodiment, if no transaction history is available for a consumer, the consumer may be approximated using selected representative consumers. The selected representative consumers can be based on attributes, such as age or residence. In another embodiment, a representative consumer can be built for each zip code. This representative consumer can be used as a default for a consumer 30 living in that zip code, at least until more information is obtained. [0186] In another embodiment, a coupon can be used to probe a consumer to determine if he/she belongs to a specific group. The coupon can be for a certain product and/or merchant that is highly correlated to a certain affinity group. If the 39 customer uses the coupon, then there is a higher likelihood that the consumer is at least partially included that affinity group. [0187] V. EXTENSION TO DIFFERENT EVENTS AND ENTITIES [0188] So far, key pair tables have been discussed primarily for tracking transaction 5 history. However, other events besides transactions can be tracked. For example, a certain transaction pattern may occur before and after a major sporting event. Thus, the sporting event can be identified with a key and included as an initial key or a final key, with the elapsed time being measured relative to the sporting event. Additionally, transaction patterns of entities other than consumers can be tracked. 10 [0189] A. Tables Including Events Beyond Transactions [0190] In some embodiments, any two events can be correlated and tracked in key pair tables (or tables for other groups of correlated keys). Each event can have an associated time, and thus as elapsed time between the events can be determined. The associated time does not have to be the instant that the event occurs but at 15 least some measure of time. [0191] In one embodiment, one type of event is the beginning or end of a time period. For example, the beginning of a new year can be an event. The beginning of a day, week, month, or other unit of time can also be used. Typically, the beginning of a time period is associated with an initial key of a table and the end of a 20 time period is associated with the final key. Such events can be used to select different patterns that specifically occur in relation to the event. For example, a person might buy lottery tickets on the 1 5 th of every month. [0192] For tables where the initial key is the start/end of a new time period, the different time ranges (columns) may be of the same duration. For example, for the 25 event of the beginning of a new month, the time ranges may be by day, with up to 31 columns. In order to determine a transaction pattern for a specific month (e.g. March), tables with an initial key of March can be retrieved using March as a filter on the initial key. As an alternative, if the keys for transactions included a date, the keys themselves could filtered for specific dates, but additional analysis might be required. 30 Having starting/ending events for certain time periods can provide a simpler method, all within the same framework. 40 [0193] In some embodiments, for an initial key being the start of a day, each of 6 columns of a table have time ranges of 4 hours. The start of the day could be midnight, 4am, or any set time. Thus, the behavior of a consumer, affinity group, or other group of consumers can be determined on a daily basis. The exact day can 5 also be part of the key, so that patterns on a weekend can be differentiated from patterns on a weekday. In one embodiment, one simply could provide a query for an initial key of type "start of a time period" and for "Monday" and transaction patterns for Monday can be retrieved. The inclusion of the type of event may be needed if the time period (e.g. day) is included in the tables for other types of events, e.g. 10 transactions. [0194] In another embodiment, the event can be related to the movement of the entity (e.g. a particular consumer) being tracked. The temporary movement of a person to a new city or country may be related to a specific set of transaction patterns. For example, when a person visits San Francisco, France, Europe, or other 15 location, the person may enter a new state (e.g. the tourist state). When a consumer is acting as a tourist, he/she will have the transaction pattern of a tourist. [0195] Knowledge of the movement of the consumer could be identified through the person's mobile phone. As another example, a purchase of plane tickets can be used to identify a specific destination from the transaction data, such an explicit 20 mention of the destination or an amount can be suggestive of the destination. If a person lives on the east coast, one dollar amount could suggest Europe and a larger dollar amount could suggest Asia. Note that the time of the movement may not exactly correspond exactly to the time used in the key pair table. For example, the mobile phone location may not be determined right away. An actual transaction in 25 the destination location can be used to confirm the initial event. The transaction can also be used as the initial event for the movement of the entity. [0196] Other events related to actions of a consumer could be travel to a store (possibly of a specific type, brand, or location) or an act of viewing content (such as movies or radio, even could be selection of a channel). The event could also be an 30 external event, such as the time of a sporting event or election. In each of these examples, the event could correspond to an initial key to determine patterns after the event, or as a final key to determine patterns before the event. 41 [0197] In another embodiment, sending a coupon can be an initial event. The final event can provide a time pattern for when the coupon is used. If the coupon is not used, then that key pair is not tracked. The absence of such a key pair can be used in various instances, e.g., in determining an affinity group of a person. 5 [0198] B. Extension Of Tables To Other Entities Besides Consumers [0199] The concept of an entity being tracked has already been briefly mentioned. Mostly, the consumer entity has been discussed. A first consumer can be associated with a set of tables (key pairs) that can define the event patterns (e.g. transaction patterns) of that consumer. These tables may be shared by other 10 consumers. For example, other consumers can be defined by some of these same tables as part of an affinity group (discussed above). However, other entities besides consumers can exhibit patterns. [0200] As events (e.g. transactions) have multiple pieces of data, each piece of data can be associated with a different entity. For example, the account number 15 used in a transaction is associated with a particular consumer. The transaction may also have the name of a merchant, a merchant code, and/or a specific location (store) of the merchant. Each of these pieces of data can be associated with a merchant entity at different levels of specificity. Such a merchant entity can be used to determine transaction patterns for that merchant. The merchant can use such 20 patterns to forecast business needs, regulate inventory (buying and location), modify hiring practices, create sales to liquefy inventory, build/close stores, or any other suitable response. Other entities can include a location or moveable objects, such as a car. [0201] Accordingly, any entity can be defined by the tables created from event data 25 that is associated with the entity. Another example of an entity is a transaction entity. The transaction entity corresponds to the whole universe of transactions, typically having similar key elements, e.g. zip code, month, etc.. Tables of the transaction entity can be used to investigate patterns for all consumers. Another entity is a fraud entity. The fraud entity is composed of transactions that have been 30 determined as being fraudulent (e.g. a consumer has made a fraud complaint). The decline of a transaction could also be used. Other entities for other types of events can also exist. For example, all transactions in the U.S. for a certain merchant code 42 can be put into one key of an table to determine an overall pattern for a certain merchant code in the U.S.. [0202] In various embodiments, the entities can be associated with particular tables by storing a list of tables for an entity, or the tables themselves can store the entity 5 information. The entity information could be stored as part of the key elements, or as separate fields for a data structure that includes the tables. [0203] VI. FILTERING FOR RELEVANT EVENTS AND ENTITIES [0204] The concept of filtering was previously introduced in order to obtain tables relevant to a particular key. The relevant tables contain the patterns of events, which 10 can then be used to calculate, for example, a likelihood (such as a probability) of a transaction being valid, a transaction being from a particular consumer, and a consumer being part of a specific affinity group. The specific filtering performed depends on the calculation to be performed. [0205] In one embodiment, the filter can be considered an impulse that acts on 15 different entities to identify desired patterns. The impulses are generally derived from an event occurring, and then using that event to retrieve the relevant tables. Such impulses could be the start of a new year. This impulse would filter out the relevant data that is correlated with the start of the year event. Below are some examples of how such impulses could be used. 20 [0206] A. Risk Analysis Of Actual Transaction. [0207] In one embodiment, the impulse is a current transaction for which authorization is requested. Such an authorization request would typically be generated by a merchant and sent to a payment processing network (e.g. network 26). The authorization request can include transaction data, such as the account 25 number, merchant code, country, industry code, etc. The payment processing network can determine one or more keys from this transaction data. One or more entities can also be determined. For authorization requests, one entity would normally correspond to the account number or to the consumer in general (i.e. across multiple accounts). 30 [0208] The determined keys along with the entity can be used as an impulse to select out the relevant tables from the entire space of all tables. Such an operation can be performed quickly as the associations of the tables to certain keys and to the 43 entity have been previously stored. The time and amount of the current transaction can also be used to determine the specific matrix elements of each table that are relevant. These values can then be used to determine whether the transaction is one that has occurred with high probability. Probability value(s) (e.g. a sum of the 5 matrix elements or a vector of the probability values) can then be used to determine whether to authorize the transaction. In one embodiment, the probability value(s) are input into a neural net that uses other information to determine an overall risk score, which is used to determine whether to authorize the transaction. [0209] B. Prediction 10 [0210] In some embodiments, the impulse can be a starting event, which can be used to predict patterns occurring after the starting event. For example, as described above, the start of a month (in general or for a specific month) can be used to determine specific buying patterns. Such calculations can be run before or around the start of a month. The start of a month is associated with a certain type of 15 tables, and a prediction calculation can be run for a specific entity (e.g. a particular consumer, affinity group, or merchant). Ending events also can be used similarly to predict what may happen before the event. Since the occurrence of an ending event can be known ahead of time (e.g. scheduled for a particular time), the correlated initial events can still be predicted. For example, consumer activity prior to a 20 schedule sporting event can be determined, which may be done using tables having negative time ranges with the ending event as an initial key or with positive time ranges with the ending event as a final key. [0211] Once behavior is predicted, any number of responses can be made. For example, for a predicted transaction, a pre-authorization can be sent to a merchant 25 at which a transaction is predicted to occur, or a coupon can be sent. In one embodiment, the amount (as a number or as a range) predicted from a table may be used to provide a maximum for which the predicted transaction is authorized. Besides a prediction of a transaction, the input data can also be used to predict other actions, e.g. movements (other events) throughout a store. Such data can be 30 obtained from cameras inside a store as well as through a mobile phone (e.g. using GPS and/or an accelerometer). This data can be part of an initial event or a final event. 44 [0212] C. Prediction After an Entity Enters A State [0213] The prediction calculation was mentioned with reference to a starting event being used to obtain certain patterns. Such an event can be considered causing a particular entity to enter into a new state. For example, the start of December can 5 cause a consumer or a merchant to enter into a state of holiday transactions. Similarly, an event of entering a different location can cause a consumer to enter into a new state, which exhibits a different transaction pattern than when the consumer is at home. [0214] Accordingly, searching a specific event can give the frequency of actions 10 related to a state related to that event. For example, if someone goes to San Francisco, the person might have a certain transaction pattern. The event is entering San Francisco (the time can be to the minute, hour, day, week). To access this pattern, one can perform a search for event pairs that start with San Francisco. Essentially all event pairs <SF:X>, where X is the other event correlated to entering 15 the San Francisco state. One could also search for data on location in transaction key pairs that include San Francisco as a location associated with the transaction. [0215] In some embodiments, specific patterns of transactions when an entity is within a specific state can be accessed by combining different tables. For example, key pairs can be dependent on the state. The key pair can be between two 20 transactions, but with the requirement that both transactions occur while the entity is in the state (e.g. in November). Accordingly, the patterns between transactions specifically in November could be obtained. In one embodiment, to obtain such information, one could apply the filter <Novl to obtain the tables correlated to this state. These resulting tables <Nov:KF> can be multiplied times corresponding tables 25 that have one of the KF keys as the initial key. For example, the key pair <NovlK1> multiplied by <K1:K2> can be used to approximate the November behavior of <K1 :K2>. [0216] The type of event that the impulse is (e.g. current transaction or starting event) can be used as part of the filter to determine the relevant tables. For 30 example, the type of event could be included as a key element in the key for the event. In this manner, the occurrence of the key element November, can be used as a filter to only obtain events correlated to the start of November and not other instances of the key element November. 45 [0217] VII. IMPEDANCE (LIKELIHOOD OF ANOTHER TRANSACTION) [0218] Besides being able to predict when a particular transaction will occur, embodiments can also predict if another transaction is going to occur after a current or a predicted transaction, which is referred to as impedance. In some 5 embodiments, such information can be tracked by using complex numbers for the matrix elements of the final event, with the imaginary part corresponding to the impedance. In other embodiments, the impedance can be tracked simply using another number for a matrix element or using another table. [0219] In such embodiments, the imaginary part of a matrix element can 10 correspond to an impedance that measures how likely it is that another transaction will occur. The likelihood can specifically correspond to a future transaction being correlated to the current transaction having the time range and dollar amount of the matrix element. The real value of a matrix element can correspond to the probability that the KF event will occur, and the imaginary value can relate to the probability that 15 another event will be correlated to the KF event. The imaginary part can be updated when another transaction is correlated to the KF event of the specific time and amount. In one embodiment, a table can have just one impedance value for the likelihood of any transaction occurring later. Thus, just one imaginary part could be stored for an entire table. In another embodiment, the imaginary parts could be 20 different for each matrix element. [0220] In an embodiment, a low impedance (e.g. a large negative imaginary part) for a matrix element means that there is a high probability that another transaction is going to occur, and a high impedance (e.g. high positive value ) means that it is unlikely that another transaction is going to occur, with zero being indeterminate. 25 The implication of negative and positive values can be swapped. In another embodiment, a high impedance is provided by a low number (negative or positive), with larger numbers providing low impedance, or vice versa. Certain future transactions can be ignored (e.g. not counted) in determining impedance, for example, if the dollar amount is too low. 30 [0221] In one embodiment, the imaginary number can be tracked (e.g. increased or decreased) in the following way. (1) When a KF event is received, each of the key pair tables that have the transaction as the ending event are increased in real part of the appropriate matrix element, with an elapsed time measured from the respective 46 starting event KI. (2) For each key pair table, the specific Kl event to which KF was correlated is determined. Then for that KI event, each KO event to which KI is correlated as a final event is determined, and the appropriate matrix elements of specific tables are determined using an elapsed time between the specific KI and KO 5 events. (3) The imaginary part of the individual matrix elements can then be adjusted (e.g. decreased to obtain a reduced impedance) to reflect a higher likelihood that a another transaction follows KI, since the KF event did indeed follow. If all of the matrix elements for a table have the same imaginary part, then the specific KI event does not need to be known, just the tables that have the key for an ending KI need to 10 be known, which can be determined with filters operating on the final keys. [0222] In another embodiment, the imaginary part could be updated in a forward manner. (a) A KF event is identified. Each of the key pair tables that have KF as the ending event are increased for the real part in the appropriate matrix element, with a KI event being the starting event. In one aspect, KF might not have just come in, but 15 could be part of a whole collection of events being processed. (b) Then specific K2 final events that correlate to the KF event as an initial event are identified. (c) Depending on the number of K2 transactions, the imaginary part of the appropriate matrix element can then be adjusted (e.g. increased, decreased, set, or reset). At this point, the imaginary part for just one matrix element (e.g. the matrix element 20 from (a)) of tables for KF could be determined. Or, all of the other matrix elements of the tables could also be determined as well based on the value for the specific matrix elements just determined. For example, all of the other matrix elements of a table can be updated to reflect that the K2 transaction occurred. This can be done when all of the imaginary parts are the same, or if just one value is stored for an entire 25 table. [0223] In one embodiment, the default for the imaginary part can be set at zero or some average value for a likelihood that a transaction occurs. If after a certain amount of time, there are no transactions correlated to it, then the value might increase and continue to increase. Or the default could be set at a high impedance, 30 and then lowered as more transactions occur. In another embodiment, if the future transaction is fraudulent, then the complex part can also be changed to reflect a higher impedance since a valid transaction does not occur. In another embodiment, if a decline occurs after a transaction then the impedance is increased (e.g. the 47 imaginary part is decreased by one), if an acceptance occurs after a transaction then the impedance is decreased (e.g. the imaginary part is increased by one). [0224] In this way, one can determine the specific instances where the transaction is a dead end (i.e. not leading to other transactions), and other instances where the 5 transaction leads to other transactions. A high impedance would convey that the transaction is a dead end as no further transactions occur very often. Conversely, one can determine that a transaction is a gateway to many other transactions when it has a low impedance. In one embodiment, an average or sum of all of the imaginary parts of the matrix elements can be used to determine whether any future 10 transaction is likely. [0225] Some embodiments can aggregate the imaginary part over all KI correlated to a KF to determine a total likelihood that a KF will provide more transactions. Thus, one can incentivize KF if the likelihood is high. Each of the tables with KF as the final event can be used to determine exactly when to send an incentive and what 15 the incentive might be. [0226] In one embodiment, one can see a dead end for one affinity group, but then look at another affinity group that does not show this dead end. An analysis can then be made as to why the one group dead ends, and strategy developed for causing the dead end not to occur (e.g. sending a coupon, pre-authorization, or other 20 inventive). For example, one can identify stores that the one affinity group does go to after the transaction, and send coupons to that store. As another example, one can identify stores geographically near a merchant that is a dead end and send a coupon for a nearby store, even potentially for use within a short time period after a predicted visit to the dead end merchant. After seeing if a strategy works by sending 25 coupons to a couple people in an affinity group, coupons can be sent to more people in the affinity group (including people just partially in the affinity group). [0227] Instead of or in addition to the above use of imaginary values for impedance, greater impedance can also correspond to fraud. If a fraud transaction K2 is found to correlate to a transaction K1, then the <KI:K1> matrix elements (or just a specific 30 element) can have the impedance increased. Thus, the impedance can reflect the profitability of the present transaction. For example, certain transactions happening right after buying a concert ticket can be associated with fraud, which is an example of where each matrix element may have its own complex part. 48 [0228] In some embodiments, both real and imaginary parts of a matrix element can contribute to an overall value, which provides whether the transaction is a good transaction with regards to likely occurring or being a transaction that leads to other transactions. Such transactions can be encouraged. In other embodiments, values 5 for the real or the imaginary components can be analyzed separately. [0229] Vill. CALCULATION OF INDICIA OF PATTERNS [0230] Once the relevant patterns (e.g. key pair tables resulting from a filtering process) are obtained, the patterns can be analyzed to provide indicia (e.g. a likelihood) for specific events. The indicia can be used to determine a total likelihood 10 (e.g. whether a transaction is fraudulent or a person belongs to a particular demographic), from which a course of action can be determined (e.g. whether to authorize a transaction event). [0231] The calculation of the indicia can be performed in numerous ways. In one embodiment, the indicia can include specific matrix elements corresponding to a 15 current transaction. The matrix elements can be modified (e.g. normalized) and/or summed to provide an overall indicia. In another embodiment, the indicia can be operated upon (e.g. summed or added with other values). This section describes some embodiments for obtaining relevant indicia of a likelihood for an event from certain event patterns. 20 [0232] A. Determining Similarity Of Transactions To Established Patterns [0233] One likelihood of interest is whether a specific transaction fits established transaction patterns of a consumer. Such a likelihood can be used to predict transactions, authorize a current transaction, or many other uses, some of which are explicitly mentioned herein. To determine a likelihood, the current transaction can be 25 compared to established transaction patterns. [0234] In an example where one or more recent transactions are received, these recent transaction(s) can be compared to established transaction patterns of the consumer or other entities (e.g. fraudsters or a specific demographic). Such a comparison may be done as part of a determination whether to authorize a recent 30 transaction. For example, if the transaction is similar to the established patterns of the consumer, then there is a greater likelihood of authorizing the transaction. Conversely, if the recent transaction is similar to the long term patterns of a 49 fraudster, the likelihood of authorizing the transaction is less. The established patterns can be created from previous transactions that are known or assumed to be associated with a particular entity. [0235] In one embodiment, a time interval between a recent transaction associated 5 with a key KF and one or more other transactions associated with a key KI can be determined. Using methods described herein, one can obtain the <KI:KF> key pair table, created from KF transactions that have previously been correlated to KI transactions. For example, the keys KI and KF can be used to query the established tables for a consumer to obtain the <KI:KF> key pair table. 10 [0236] The time interval and potentially a dollar amount can then be used to select the appropriate matrix element. This matrix element, potentially along with the other matrix elements of the retrieved matrices can provide a likelihood directly or in combination with other values. For example, the matrix element can be divided by a sum of matrix elements in a row, all matrix elements in a table, or all transactions of 15 a person to determine a likelihood for the recent transaction. The appropriate matrix element(s) can be selected using multiplication. [0237] FIG. 9 shows an example of obtaining indicia of a similarity of a recent transaction relative to an established transaction pattern of a consumer according to embodiments. In FIG. 9, a short-term table 910 created from one or more recent 20 transactions is multiplied (element by element) by pattern table 920 to provide indicia 930. Indicia 930 can provide a measure of how similar the short-term table is to the pattern table 920, and thus how likely that it is for the recent transaction to have occurred. [0238] In this simple example, suppose the recent transaction is associated only 25 with K1, and K1 is correlated only to K2. Then a table <K2:K1> can be created with a "1" in the proper matrix element of table 910 relative to the last K2 transaction, with zeros in the other matrix elements. Table 910 shows a value of 1 for the first dollar amount and the fourth time range. Then, short-term table 910 can multiply the <K2:K1> key pair table 920 (which has been matched and retrieved), with the result 30 selecting out the matrix element that matches the short-term matrix element, in this case "2". The value of this matrix element 930 can (e.g. when normalized) can provide a measure of a likelihood of the K1 transaction at that specific time. Since "2" is relatively low compared to the other matrix elements, the likelihood of the K2 50 transaction occurring with the specified dollar amount is relatively low. Note that the likelihood can be determined only based the matrix elements in the same row. [0239] In another embodiment, pattern table 920 can correspond to a pattern of fraud. Thus, the indicia 930 having a value of "2" this can be seen as a low 5 likelihood of fraud relative to the other times. However, if the matrix element was the largest value in the table, then the recent transaction K1 can be seen as having a higher likelihood of fraud. [0240] Overall, multiple short-term tables might result for a current K1 transaction. Also, a single short-term table could have multiple matrix elements with a "1' or other 10 value to signify that the time interval between transactions falls within the specified time range. Multiple recent transactions may also be used to determine the likelihood for the K1 transaction. For example, if other recent transactions are not likely, then they may affect the likelihood of the most recent transaction. Such use of other recent transactions may be used in any embodiment. 15 [0241] B. Multiplying Tables - alignment [0242] There may be instances where the key pair for a short-term table is not found in the key pairs of an established pattern tables. When this occurs, a short term table may be aligned with an established pattern table to determine a matching table for multiplying. In one embodiment, method 700 can be used to perform the 20 alignment. [0243] FIG. 10 illustrates the alignment of a short-term key pair table 1010 with established key pair tables 1020 an according to embodiments. Short-term table 1010 can be created based on one or more recent transactions of a consumer. In one embodiment, short-term table 1010 can be generated when the multiplication is 25 to be performed, and is not already stored. Whereas, established key pair tables 1020 can already be stored, e.g., in RAM or disk. For simplicity, these tables are shown only with the final key (but the example applies equally well to an initial key). In one aspect, the initial keys for all of the tables shown can be the same key, e.g., K1. In another aspect, the initial keys can be the same as the final keys. 30 [0244] Short-tem table 1010 has a final key of :4812,345>, where 4812 is the merchant code and 345 is the first three digits of a zip code. However, the key pair tables 1020 do not contain a table with this final key. This may be because the 51 consumer has few transaction in zip codes starting with 345. But short-term table 1010 may still contain useful information. Thus, the key :4812,345> can be broadened to be :4812,*> so that it matches with table 1030. The zip code can be broadened in one step or incrementally to :4812,34>, :4812,3>, and then :4812,*>, 5 where a match is found. [0245] Such alignment can be performed between sets of key pair tables. In one embodiment, each set can correspond to a different entity, e.g., two different consumers, In a general sense, a set of key pair tables can be viewed as a key manifold. When the key manifolds are normal (i.e. both spaces have identical 10 amounts of keys), then one can apply the operations directly. However, if the key spaces are not normalized (as in the example of FIG. 10), then an alignment may be performed, as described herein. [0246] In one embodiment, each table of one manifold is aligned with exactly one table of the other manifold. In another embodiment, there may not be a match found 15 for a table from one manifold to another. In such a case, the non-matching tables can be dropped, or distinguished from tables that did match after alignment. A distinction can also be made between tables that only match after alignment and tables that match exactly. For example, it may be useful to know what the entities do that is not the same (no match), or maybe just similar (match after some alignment). 20 [0247] Also, other operations besides multiplication can be performed, such as division, subtraction, and addition. In some embodiments, alignment is not needed. For example, different tables may be added with a final key being the intersection of the keys (e.g. the broadest key the tables have in common). As another example, after summation, an association with a specific key can be dropped. 25 [0248] C. Other Calculations of Likelihood [0249] With this framework of aligning and multiplying keys, more complicated calculations of likelihood can be performed. As mentioned above, other operations, such as division can be used. A purpose of division can be to normalize a key manifold (i.e. a set of tables). 30 [0250] FIG. 11 shows a calculation of a likelihood that a transaction or set of transactions are similar to established patterns according to embodiments. Such a calculation can provide a likelihood of occurrence of a transaction. Fraud tables 52 1110 and total transaction tables 1120 are established pattern tables, which can be updated at set times, e.g., once a day, week, etc.. Account tables 1130 are short term tables created from the transaction or set of transactions. The constants table 1140 is a table that can be used for normalizing, e.g., to place the values of a table 5 to be within a specific range. [0251] Fraud tables 1110 can be obtained from fraudulent transactions across all or many entities. In one embodiment, the specific set of tables have a common key element, e.g., all fraud for a specific merchant or during a specific month. Other key elements can be used, e.g., zip code, country, or any other suitable key element. 10 The fraud tables selected may be ones that have a significant amount of fraud. For example, a transaction from one zip code to another zip code far away within a short time frame is likely to be fraud. [0252] Total transactions tables 1120 can be obtained from all transactions across all or many entities. In one embodiment, the total transactions tables 1120 are 15 obtained from the same entities as the fraud tables 1110. Similar to fraud tables 1110, total transactions tables 1120 can share a same key element, for example, the same key element as in fraud tables 1110. The total transactions can include fraudulent transactions and valid transactions, or just valid transactions. The fraud and total transactions tables can be computed in a batch at prescribed times, e.g., 20 every day, week, month. The number of fraud and/or total transaction tables can be quite high, e.g., 10,000 to 500,000 or more. [0253] In an example where the fraud tables 1110 and the total transactions tables 1120 include transactions for a particular month, there may be fewer fraud tables than total transaction tables. This may occur since not all key pairs may have a 25 significant enough fraudulent transactions to have a certain key pair table tracked. In such instances, the fraud tables that are being tracked can be aligned with the total transaction tables. [0254] Once the tables are aligned, the total transaction tables 1120 can be used to normalize the fraud tables 1110 by dividing a fraud table by the corresponding total 30 transaction table. After the division, the normalized fraud tables can be stored in RAM (or any other memory with faster access than disk). As with FIG. 9, the division operation divides each matrix element of a fraud table with the corresponding matrix element of the total transaction table. The division can provide a normalization of the counters for the fraud tables. For instance, a particular fraud table may have high values, but if there are many total transactions, the total percentage of transactions that are fraudulent is low. Thus, the likelihood of a fraudulent transaction is low. [0255] In one embodiment, each fraud table is aligned with exactly one transaction 5 table. For example, if there are 100 fraud tables tracked (i.e. for a given group having a common element, such as month), then 100 tables result from the alignment and division. Note that the alignment can be implicit in the notation of a division operation. In some embodiments, there may not be a match of a fraud table to a total transaction table, although this may happen rarely. In such a case, the 10 fraud table may be dropped, and thus there may be fewer resulting tables than fraud tables. In an embodiment, one can differentiate fraud tables that do not have a match from tables that did match, or between tables that only match after alignment and tables that match exactly. [0256] Account tables 1130 can be created from a plurality of recent transactions, 15 e.g., as fraud tends to happen in bunches of consecutive transactions. Regardless of how many recent transactions are used, multiple account tables can result. For example, one transaction can have a key that is correlated to multiple initial keys. Thus, a plurality of short-term key pair tables can be generated. An account table can have a form as described above for table 910. In various embodiments, 20 mapping module 392 and/or a matching module (e.g. module 794) can be used to determine which short-term key pair tables are created. [0257] Account tables 1130 can then aligned with the normalized fraud tables. Before alignment, some or all of the account tables can be summed. In one embodiment, two account tables can be summed when the keys are similar. In 25 effect, the final transactions for each of the tables can be considered to be of a same type, i.e. have the same key. For example, if the merchant is the same, but the zip codes are different, the two tables can be merged and the zip code dropped or broadened (which can be considered an intersection of the two key pair tables). This summing may be particularly appropriate when both tables would be aligned with a 30 same fraud table. In such a case, a summing after multiplying the account tables by the normalized fraud tables provides the same resulting table. [0258] After alignment, the account tables can be multiplied element-by-element with the normalized fraud tables, thereby providing a plurality of account-fraud tables. In one embodiment, these account-fraud tables can be summed to provide one final table. In one aspect, the summing can be due to the fraud tables 1110 being grouped to have a similar key element, and thus the final table can relate to the one key element. This final table can provide an overall similarity of the 5 transaction patterns to certain types of fraud, and therefore can be used (e.g. by a modeling function as mentioned in step 380 of method 300) to determine a likelihood of whether a transaction is actually from the consumer. In another embodiment, each of the account-fraud tables can independently be final tables that are used by a modeling function. 10 [0259] In one embodiment, if an account table cannot be aligned (i.e. there is no corresponding normalized fraud table), then an average value of fraud can be used. In various embodiments, this average level of fraud is single number that multiplies the account table, is a table of average values, and can be the same across all fraud groups or just the same within a single fraud group. 15 [0260] In another embodiment, a mask matrix can be used to remove certain matrix elements from the account-fraud tables or from the final table. For example, the mask matrix can remove low frequency or high frequency components, or be a notch filter to select frequencies in the middle. Also, certain dollar amounts can also be removed. In one implementation, the mask matrix has 1s in matrix elements that are 20 to be kept and Os in matrix elements that are not to be analyzed. [0261] Although fraud tables 1110 were normalized, the final table(s) may still have matrix elements with values that can vary widely. This variation in values can cause instability in a modeling function, which uses the matrix element as indicia of the patterns to obtain a total likelihood. Accordingly, in some embodiments, constants 25 matrix 1140 is used to constrain the final matrix element to be within a certain range of values, e.g., between -1 and 1 or 0 and 1. In one embodiment, constants matrix 1140 is created from a specified functional form, such as tanh, log, or sigmoid (generally S shaped) functional form. [0262] Constants matrix 1140 can also constrain matrix elements values to 30 correspond to a third number within the prescribed range. For example, a zero output can be mapped to a matrix element value where fraud and valid transactions may be more difficult to determine and thus sensitivity needs to be greater. In one embodiment, the functional form of constants matrix 1140 can be kept for an 55 extended period of time, where inputs of specific matrix element values (e.g. maximum and minimum values in a specific table) are used to determine the exact values. Which count corresponds to zero may also have an input parameter. The functional forms may be constant or vary across multiple entities. 5 [0263] The calculation shown in FIG. 11 can done for different groups of fraud tables, e.g. one group shares a same merchant, one group shares a month, etc. In such embodiments, the account tables used for a particular group can be chosen to correspond with a particular group. Thus, different account tables can be used for different groups. In one embodiment, each of these calculations can then be 10 combined and provided to a model function that uses the inputs to determine a risk score related to whether the transaction is fraudulent or not. [0264] Instead of or in addition to the comparison to fraud, one can also add a calculation involving the established transaction pattern of a consumer. In such embodiments, the fraud tables can be replaced with the established key pair tables 15 of the consumer. The multiplication operation can then provide a measure of how likely the recent transactions fit the consumer's pattern, and thus can contribute to a determination of whether a transaction is from the consumer. A higher similarity to the established pattern can signify a higher likelihood of the transaction being valid. The final results from the fraud comparison and the consumer comparison can be 20 analyzed separately or both be input to a same modeling function that accounts for the respective values. [0265] The form of the formula in FIG. 11 can also be used to determine how likely a consumer is part of an affinity group. Instead of the fraud tables, the key pair tables of an affinity group can be used. Normalization can still be performed with 25 total transaction tables for the specific affinity group or transaction tables across multiple affinity groups. The account tables can still be made of just recent transactions, or can be tables for established patterns of a consumer. The tables can be normalized as well. [0266] In one embodiment, the normalized fraud tables (and potentially the account 30 tables) can be stored across multiple processors and each one can perform the corresponding multiplication if there is a match to an account table. As an alternative, a query can be provided to each processor and the processor that is storing the desired fraud table can return the requested table. The final table(s) can 56 be provided to a single processor or set of processors that are configured to run a modeling function. [0267] D. Subtraction of Matrices [0268] Besides comparing different entities by multiplying their respective key 5 manifolds (sets of key pair tables), the manifolds can also be subtracted from each other. Each table (which can be normalized) can be aligned and the elements subtracted. If the difference is large, then the two manifolds are less likely to be part of the same affinity group. Embodiments can also analyze tables that do not match exactly, and ones that match only after an alignment procedure. The values of these 10 matrices can be analyzed along with the differences for the tables that did match. [0269] E. Prediction [0270] In embodiments that predict a likelihood of a future event, one can obtain the relevant key pair tables for the entity (e.g. a consumer) and then analyze these tables. Which tables are obtained and how they are analyzed depends on exactly 15 what events are trying to be predicted, i.e. the question being answered. [0271] In one embodiment, if one wants to identify when a particular event E is likely to occur, the event can be represented with one or more keys KF. These keys can then be used to filter key pair tables having a final key that matches a KF key associated with the event E. The result being a set of tables <Kl:KF>, where each KI 20 event is correlated with event E. At this point, one can analyze the tables to obtain the time ranges for event E that are most likely (e.g. the ones having the highest values), but these time ranges are elapsed times from KI events. In order to obtain an actual (absolute) time and date, one can obtain time information for the KI events. In this way, the contributions of the likelihood from each table can also be combined 25 since a same absolute timeframe can be used; whereas with elapsed time, the timeframes for each of the tables could be different. If a dollar amount is specified for the E event, then a specific matrix element in a time range (e.g. a column) can be identified. If any amount is allowed, then all of the matrix elements in a column can be used. 30 [0272] In another embodiment, if one wants to identify which events are likely to occur after an initial event E, the event can be represented with one or more keys KI. These keys can then be used to filter key pair tables having an initial key that 57 matches a KI key associated with the event E. The result being a set of tables <KI:KF>, where each KF event is correlated with event E. For each KF event, one can then obtain the elapsed time that is most likely by choosing the matrix element with the largest value. If one wants additional information of a likelihood of a 5 particular KF event, embodiments in the previous paragraph can then be employed. [0273] In addition to determining when a KF event is likely, a calculation of a likelihood that such a KF event is related to fraud can also be determined. For example, after determining that a KF event is likely at a particular time, any action (e.g. sending a coupon) might also depend on whether such an event could be 10 fraudulent. [0274] IX. METHOD FOR LIKELIHOOD FOR A SPECIFIC TRANSACTION [0275] As stated above, embodiments can be used to determine a likelihood (e.g. a risk score) that an event (e.g. a transaction) is fraudulent, a likelihood of an entity being similar to a demographic, a likelihood of an event occurring, or any other 15 likelihood measure. FIG. 12 is a flowchart of a method 1200 for determining a likelihood of events for which data has been received according to embodiments. Method 1200 can be performed by any one, plurality, or combination of computer apparatus described herein, and components thereof. [0276] In step 1210, data for one or more events is received. In one embodiment, 20 the event data (e.g. transaction data) is associated with one entity, e.g., a particular consumer or affinity group. The event data may be for only recent events, or for just old events, or a combination of both. [0277] In some embodiments, an event is a pending transaction that has been initiated by a consumer, but has not completed as authorization has not yet been 25 provided. In one embodiment, the transaction data is received as part of an authorization request sent by a merchant. In another embodiment, data for recent events (e.g. transactions) are retrieved for processing as well. These recent transactions may be used to determine authorization of the pending transaction, for example, by being used to determine if a fraud pattern is emerging and thus if fraud 30 for the pending transaction is more likely (e.g. as described above for FIG. 11). [0278] In step 1220, the event data is used to map each event to one or more keys. If recent events are used, the recent transactions can also be mapped, or have been 58 previously mapped. In some embodiments, the mapped keys are specifically keys that are being tracked, for example, for the consumer, an affinity group, or a fraud entity. In one embodiment, the mapping is performed by mapping module 392 in FIG. 3B, which can also ensure that the mapped keys are specifically keys that are 5 being tracked for a particular entity. [0279] In step 1230, key pair tables (e.g. tables 1130) are generated using the keys and time information of the events. In one embodiment where the events are recent, the key pair tables have a final key matching one of the keys resulting from step 1220 are obtained. In another embodiment, the key pair tables can be combined 10 when two transactions are similar. For example, similar zip code keys for two transactions (e.g. one recent and the pending transaction) can be combined into a single broader zip code key. Either of these embodiments can be performed, for example, when an authorization is requested. [0280] In step 1240, tables of established patterns that correspond to the generated 15 key tables from step 1230 are identified. These tables can be likelihood functions that approximate patterns. The corresponding tables may be associated with a same entity as the key pair tables in step 1230. For example, the corresponding tables may be the established event patterns for a consumer. In other embodiments, the corresponding tables are for an affinity group or for a fraud entity, both of which 20 are associated with the consumer as entities whose patterns can relate to determining whether to authorize the transactions of a consumer. The corresponding tables may be a combination of tables, e.g., fraud tables 1110 divided by total transaction tables 1120. In one embodiment, matching and retrieval function 794 of FIG. 7D identifies the key pair tables using methods described herein. In 25 another embodiment, an established pattern table is required to have a certain total of all values, average of the values, minimum value in any matrix element, or other measure of the values in the table. Such a requirement can ensure that enough data has been received to provide an accurate pattern. [0281] In step 1250, each generated key pair table is multiplied by a corresponding 30 established pattern table, thereby providing a plurality of resulting tables. In one aspect, each matrix element of one table is multiplied by a corresponding matrix element of the other table. These resulting tables can be summed into one final table, only some of the tables can be summed, or not summed. In one embodiment, the final table(s) are multiplied by a table of constants to transform the matrix 59 element values to be within a predetermined range of values. In one embodiment, the values of the resulting tables can each be used as likelihood values. In another embodiment, only the non-zero values of the resulting tables are used as likelihood values. 5 [0282] In step 1260, at least some of the values of the final tables are used as input to a modeling function, such as an optimization algorithm or a decision tree. The matrix elements of the final tables can be separately input to the modeling function. The modeling function can analyze the final tables to determine a score, such as a risk score for the event being fraud or a similarity score for the generated key pair 10 tables being similar to the pattern tables (e.g. to see if a person is part of an affinity group). [0283] In step 1270, the score is used to determine whether a certain action is performed. For example, if a risk score is above a certain value the event can be considered to valid, and not fraud, or vice versa. A level of validity or fraud can 15 depend on the specific values of the score. The risk score by itself or other factors can be used by an authorization entity (e.g. an issuer or a payment processing network) to determine whether or not to authorize the transaction. As another example, the score can also be used to define the consumer as being a certain percentage of an affinity group. 20 [0284] In embodiments where the score includes a similarity to the transaction patterns of a consumer, a person may be allowed to enter incorrect information (e.g. mistype a zip code), but the system will still authorize the transaction when the transaction fits established patterns. Some embodiments can even have a requirement of entering the zip code to be actively removed after a swipe of a card if 25 the likelihood is sufficiently high. In one embodiment, challenge questions can be determined based on a value of the score. [0285] X. AUTHORIZATION OF A TRANSACTION [0286] It is advantageous to authorize a transaction quickly while maintaining an accurate risk assessment of the transaction, e.g. via an authorization process. As 30 mentioned above, once a pattern has been determined, a transaction can be predicted to occur, e.g., in a specific time window. Knowing when transactions tend to occur can allow an accurate determination of whether to authorize a transaction when one does occur. For example, if an authorization request is received for a 60 current transaction at a time when the transaction generally occurs, it is more likely that the transaction is being initiated by the consumer. [0287] FIG. 13 is a flowchart of a method 1300 for authorizing a transaction of a consumer according to embodiments. In one embodiment, previous transactions 5 (e.g. 210) are used to determine if a current transaction is to be authorized. In one implementation, transactions within a specific time period are analyzed, e.g., last year or all transactions before the current transaction. [0288] In step 1310, data associated with transactions previously performed, e.g. by the consumer or other similar consumers (an affinity group), is received. For 10 example, the data in the transaction history database 26(b) can be received at a transaction analyzer 26(c) of system 20 in FIG. 1, which includes a processor that may be configured with software. Each transaction can have any number of pieces of data associated with it. This data can be used to identify a particular type of transaction. In one embodiment, the data for a transaction is parsed to identify one 15 or more keys, which are used as identifiers for a particular transaction. In another embodiment, a mapping module can perform the mapping of the transaction data to one or more keys. A key can be composed of multiple pieces of data (referred to herein as a key element), and have properties described herein. [0289] In step 1320, transactions are optionally correlated with other transactions 20 and events. In this manner, different transaction patterns can be identified for different types of transactions. Other events (e.g. start or end of a day, week, etc.) can be correlated to transactions as well. An event can also be a movement of the consumer from one state to another (e.g. from an at-home state to an on-vacation state). Different events can also be identified with keys. Herein, examples are used 25 to described how keys are used to identify transaction types, but other suitable methods can be used. In one embodiment, pairs of correlated keys (e.g. a key pair <KI:KF>) are determined based on whether events associated with an initial key (KI) are correlated with transactions with a final a final key (KF). [0290] In step 1330, likelihood function(s) that approximate one or more patterns of 30 when the previous transactions occur are created. In one embodiment, the likelihood functions of when the previous transactions occur are determined with a computer system, e.g., the transaction analyzer 26(c), which can be a subsystem or one apparatus. The likelihood function(s) can convey the likelihood of a transaction 61 as a function of time and can include contributions from multiple patterns, or just one pattern. For example, pattern function 220 can be considered a likelihood function, and a combination of pattern functions 220 and 270 can be considered a likelihood function. In these examples, transactions are more likely when the function has a 5 higher value, and thus more likely to lead to authorization. In other embodiments (described in more detail below), a higher value can be less likely to lead to authorization, e.g., when the pattern is of fraudulent transactions. [0291] In one embodiment, pairs of correlated transactions (or other events) are used to determine a pattern, e.g., as times of final transactions related to initial 10 events. The times can be stored as an absolute time and/or date for each transaction (e.g. in chronological order) or organized as elapsed times for correlated events of certain key pairs. The elapsed time may be the time between a transaction with K1 and the next transaction with K2 for the correlated <K1:K2> pair. Other data can be stored as well, e.g. data not included in the keys, such as an amount of the 15 transaction. The elapsed time can effectively equal an absolute time if the initial event is the beginning of a time period. [0292] In some embodiments, the time information is stored (e.g. in transaction history database 26b) associated with the corresponding key pair. In one embodiment, the time information for the key pair <K1:K2> can be stored in a 20 database table that can be accessed with a query containing K1, K2, or the combination (potentially in the order of K1:K2). A key pair table is an example of a likelihood function, or a group of likelihood functions, as the case may be. In one aspect, storing time information in association with certain key pairs can allow the time information for specific types of transactions to be easily accessed. Also, such 25 organization can provide easier analysis of the data to identify patterns for specific key pairs. The occurrences of the transaction can then be analyzed (e.g. Fourier analysis or other functional analysis) to identify a pattern of the times and dates of these transactions. [0293] In step 1340, data for a transaction at time T is received. In one 30 embodiment, the transaction is a pending transaction that has not yet completed. As an example, payment processing network 26 can receive the data as part of an authorization request from a merchant. Payment processing network 26 can then perform a procedure to aid in the determination of whether to authorize this current transaction, e.g., by calculating a risk score or other score. 62 [0294] In step 1350, relevant likelihood function(s) are determined. The relevant likelihood function(s) can be determined based on whether a likelihood function and the transaction data share matching values. In one embodiment, the matching can be performed using keys. For example, relevant key pairs can be selected, and 5 tables or other data for a key pair can be obtained. In some embodiments, to determine whether to authorize the transaction (e.g., current transaction 230 in FIG. 2A), the relevant keys pairs are all or some of the pairs that include keys that match a key associated with the transaction. In one embodiment, the relevant key pairs are all of the key pairs that are associated with the current transaction as a final key. In 10 another embodiment, the relevant likelihood function(s) can be for patterns of other entities, such as certain demographics or fraudulent patterns. [0295] In step 1360, one or more likelihood values of a relevant likelihood function(s) at time T are determined. In one embodiment, the likelihood values can be obtained from the tables for the relevant key pairs. In various embodiments, the 15 likelihood value can be a number of transactions in a time range in which time T falls within, the probability of a continuous function at time T (e.g., as calculated from a value of one or more pattern functions at time T), or other measure related to likelihood. In an embodiment where a current transaction has multiple keys associated with it, multiple likelihood values can be summed. The likelihood values 20 for likelihood functions of multiple patterns can be summed, as the total likelihood for the transaction is affected by the patterns. [0296] In step 1370, the likelihood value(s) can be used to determine a risk score or other score, which can be used to determine whether to authorize a current transaction. In various embodiments, the score can correspond to a likelihood that a 25 transaction is fraudulent, a likelihood that a transaction occurs at a specific absolute or relative time, or a combination of both. In some embodiments, the likelihood value(s) can be input into a modeling function as part of the determination of the score. [0297] XI. METHOD FOR PREDICTION OF AN EVENT 30 [0298] As opposed to calculating a likelihood for an event that has already occurred, certain embodiments can also predict an occurrence of a future event (e.g. a transaction). Based on the prediction, embodiments can perform an action, such as pre-authorizing a predicted transaction, sending a coupon to use for a predicted 61 transaction or to incentivize a transaction when the likelihood of occurrence is low, and actions related to inventory of a business. [0299] FIG. 14 a flowchart of a method 1400 for predicting an event according to embodiments. Method 1400 can be performed by any one, plurality, or combination 5 of computer apparatus described herein, and components thereof. [0300] In step 1410, data for one or more recent and/or upcoming events is received. In one embodiment, the event data (e.g. transaction data) is associated with one entity, e.g., a particular consumer or affinity group. For recent events, whether an event is "recent" can be relative to other events. For example, if an 10 event does not occur often, a recent event (e.g. a last event of that type) can still occur a long time ago in absolute terms. For an upcoming event, the event has not occurred yet, but can be known to occur. For example, the start of a month (or other time period) has a known time of occurrence. As another example, a scheduled event (such as a sporting event or concert) can be used. Data for these scheduled 15 events can be obtained before they occur due to the nature of these events. [0301] In step 1420, the event data is used to map each event to one or more keys KI. In some embodiments, the mapped keys KI are specifically keys that are being tracked for an entity. In step 1430, tables of established patterns that have an initial key of KI are obtained, thereby providing <KI: tables relevant to the received event 20 data. In one embodiment, matching and retrieval function 794 of FIG. 7D identifies the relevant tables using methods described herein. In embodiments where an event is an upcoming event, the upcoming event can be a final event (or effectively the time ranges can be negative with the upcoming event being an initial event), where transactions before the ending event are analyzed. 25 [0302] In step 1440, the <KI: tables having matrix elements with sufficiently high counts are identified to determine KF events that are likely to occur. In one embodiment, to determine whether a matrix element has a sufficiently high count, one or more absolute or relative threshold numbers can be used. A relative threshold (e.g. a percentage) could be determined using a total number of counts for 30 a table or group of tables. In another embodiment, all tables (i.e. not just ones with a matching KI for initial key) could be analyzed to find matrix elements with high counts. thereby eliminating steps 1410 to 1430. However, using recent or upcoming events can provide greater timeliness for any result, or action to be performed based C64 on the a result. The identified KF events along with the specific time ranges for the matrix elements with the high counts can then be analyzed. [0303] In other embodiments, the <KI: tables having matrix elements with sufficiently high or low counts can be identified, e.g., to determine KF events that can 5 be part of a trend. The trend may be a change in likelihood, which can be identified when a count is outside of a band of expected or average values. In one embodiment, to determine whether a matrix element has a sufficient count, one or more absolute or relative threshold numbers can be used (e.g. below a lower and above an upper bound). A relative threshold (e.g. a percentage) could be 10 determined using a total number of counts for a table or group of tables. In another embodiment, all tables (i.e. not just ones with a matching KI for initial key) could be analyzed to find matrix elements with high or low counts, thereby eliminating steps 810 to 830. However, using recent or upcoming events can provide greater timeliness for any result, or action to be performed based on a result. The identified 15 KF events along with the specific time ranges for the matrix elements with the high or low counts can then be analyzed. [0304] In step 1450, other matrix elements not previously identified are obtained for each likely KF event. For example, a KF event can be correlated to more initial keys than just the ones identified in step 1420. These previously unanalyzed tables can 20 also have high counts for certain matrix elements involving a KF event. The KF event can be used as a filter to identify unanalyzed tables, from which other high count matrix elements can be obtained. Thus, this step can be used to obtain a more accurate likelihood for a specific KF event. Obtaining these other high-count matrix elements may not be needed, e.g., if KI is starting event, such as a beginning 25 of a week, month, etc. In this case, since other tables would include the same data points, these other tables would just include redundant information. [0305] Also, low count matrix elements for KF events already determined to be likely can be important if high accuracy is desired. For example, as the timeframes of the different :KF> tables can be different (due to different KI events), matrix 30 elements having relatively low counts can correspond to the same timeframe as a high-count matrix element. Thus, the number of counts for a likely time range can be revised.

[0306] In this manner, high probability KF events can be determined based on a few recent or upcoming KI events, and then a full analysis of :KF> tables can be performed, as opposed to randomly selecting KF events to determine when they might be likely to occur. A KF event could be chosen for analysis, but a selected KF 5 event might not be highly likely. However, if one were interested in a specific KF event, then it may be desirable to start method 1400 at step 1450. [0307] In step 1460, the matrix elements (e.g., just from step 1440 or also from step 1450) are combined to obtain a probability distribution vs. time for a :KF> event, which is correlated to many <Kl: events. In one embodiment, each of the matrix 10 elements for the KF event are combined from a portion or all of the <KI:KF> tables, where KI runs over the initial events that are correlated to the KF event. This combination can account for the fact that the different KI events occur at different times, and thus the time ranges for each table can be different (e.g. offset). [0308] In one implementation, the earliest or latest KI event can be identified, and 15 offsets for the time ranges of the other tables can be determined. The corresponding matrix elements can then be added using the offsets. If a time range of a matrix element of one table only partially overlaps an offset time range of another table, then the combination can be broken up into more time ranges with proportional contributions from each previous rime range. For example, if two time ranges 20 overlap, then three time sections can result. The overlap section can receive contributions (i.e. a percentage of the counts) from the two matrix elements, with the amount of contribution proportional to the amount of overlap in time for the respective time ranges. [0309] To determine a time range of high likelihood, a probability distribution can be 25 created from the resulting time ranges X after the combination and the counts Y for each time range. The resulting time ranges X with the respective counts Y can be analyzed as a function Y=F(X), which can correspond to pattern 420 of FIG. 4. The Y values can be normalized so that the counts for time ranges of different lengths are accounted. The Y values can also be normalized based on the dollar amount of 30 a transaction. [0310] In step 1470, a total likelihood for a KF event (e.g. across multiple initial events) is calculated. In one embodiment, different likelihoods can be determined for different transaction amounts for the KF event, which can be selected by multiplying 66 with a mask matrix. In another embodiment, the likelihood may be for a specific time window or for the KF event occurring at any future time. A specific time window may correspond to a predetermined time range of a matrix element, or be another time range that results from an overlap of multiple time ranges. For example, if two 5 matrix elements overlap in time (e.g. because the KI events occur at different times), then the time window may have the range of the overlap time. [0311] In other embodiments, a trend can be confirmed for a particular time or time window (e.g. time range of the identified matrix element) by analyzing the probability distribution. In one embodiment, a total likelihood for a KF event can be calculated 10 to confirm that the likelihood is still outside the average or expected band. Likelihood values near the time range can also be examined to identify regions of significant change in probability. [0312] To determine a time range of high likelihood, the probability function F can be analyzed. For example, the function F can be analyzed with a numerical routine 15 to identify a maximum or regions having values above a threshold (or potentially within a range, e.g., using multiple thresholds). To identify maximum regions, techniques such as finite difference, interpolation, finite element, or other suitable methods, can be used to obtain first and second derivatives of F. These derivates can then be used in an optimization algorithm for finding a maximum. Global 20 optimization methods can also be used, such as simulated annealing. [0313] In addition to finding a time window when an event is likely, a total probability over a specific time period can be obtained. In one embodiment, the function F can be integrated (e.g. sum counters for time ranges) over the desired time range. In effect, to obtain a probability that an event will occur within a 25 prescribed time period, one can integrate contributions over all of the relevant key pairs during the time period. As an example with one key pair, a probability that someone will perform a certain event (e.g. a transaction) once they are visiting San Francisco can be obtained by integrating the key pair <SF: KF> over all of the desired time periods. In one aspect, time periods of greater than one month may not 30 be relevant if a person never stays in San Francisco for that long. One could also determine a probability for a transaction to occur in November in a similar way. [0314] As an alternative to all of the above steps, one can select a particular event and a particular time, which can be used to select the relevant patterns from which 67 the corresponding matrix element can be analyzed. Then, the time interval from that time to the recent correlated events can provide a set of key pair tables with 1 or other non-zero values in the appropriate matrix elements, much as account tables 1130 can be created. These tables are then multiplied by the long term behavior to 5 obtain the likelihood. Effectively, the prediction can be treated as if the particular event has actually occurred. Besides a particular time, a time window can also be specified, which may cause more than one matrix element in a table to have a non zero value. In this case, the non-zero values can be based on a level of overlap of the time window with the corresponding time ranges of the matrix elements. 10 [0315] In one embodiment, the relevant patterns from which the corresponding matrix element are selected by creating a set of key pair tables with 1 or other non zero values in the appropriate matrix elements. These tables are then multiplied by the saved tables (i.e. known patterns) to obtain the likelihood, effectively filtering out the desired values. Besides a particular time, a time window can also be specified, 15 which may cause more than one matrix element in a table to have a non-zero value. In this case, the non-zero values can be based on a level of overlap of the time window with the corresponding time ranges of the matrix elements [0316] In another embodiment, the currently calculated probability distribution can optionally be compared to other probability distributions calculated previously. In 20 one embodiment, the previously calculated distributions are for the same :KF> event. In this manner, a change in probability at a particular time in one distribution to another can be determined. This change can be used to determine a trend. For example, the change can be plotted and a trend in the change can be determined. The change can be used to predict a trend even when the likelihood values fall within 25 an expected or average band. [0317] Referring back to method 1400, in step 1480, a course of action can be determined based on likelihood and/or time window. Various example actions and determinations are now described. If a likelihood is low, then no action can be taken. If the likelihood is sufficiently high (e.g. relative to threshold values), then the 30 transaction can be authorized or a time window for that high likelihood can be determined. If the time window starts soon, an action that can be performed soon (e.g. sending a coupon via e-mail or text message) can be initiated. Whereas if the time window does not start for an extended period of time, an action that takes longer (e.g. ordering more inventory) can be performed. Examples of actions taking 68 longer include business decisions such as opening or closing a store in a particular zip code, and buying or moving inventory. [0318] Also, once an event is found to be likely, further analysis can be performed to determine whether and how and action is to be performed. For example, a cost of 5 an action, such as the cost of sending a coupon can be determined as part of a cost benefit analysis. As another example, a cost of an action, such as the cost of moving inventory or discounting the price of a product can be determined as part of a cost-benefit analysis. [0319] In one embodiment, the cost of an action can include a loss due to fraud, 10 which can be calculated using methods described herein, e.g., as described for FIG. 11. In one aspect, if the likelihood of an event is low, then a high cost will not be tolerated (e.g. no action performed). In another aspect, if the likelihood of an event is high (potentially coupled with a high expected profit), then a high cost may be tolerated. Also, if the cost is high, it may be desirable to obtain further information 15 (e.g. about the customer). In another embodiment, a profit of an event can be determined, e.g., the profit from a transaction resulting from an incentive or resulting from a pre-authorization sent to a consumer. If the profit is high, then a higher cost and lower likelihood can be tolerated. [0320] In one embodiment, calculations for the prediction of an event can be run in 20 real time (e.g. within several hours after an event or series of events occur). In another embodiment, the calculations can be run as batch jobs that are run periodically, e.g., daily, weekly or monthly. For example, a calculation can run monthly to determine who is likely to buy a house, and then a coupon for art, furniture, etc. can be sent to that person. In various embodiments, prediction of 25 major purchases can generally be run in larger batches, whereas prediction of small purchases can be run in real-time (e.g., in reaction to a specific transaction). [0321] In some embodiments, ending events also can be used similarly to predict what may happen before the event. Since the occurrence of an ending event can be known ahead of time (e.g. scheduled for a particular time), the correlated initial 30 events can still be predicted. For example, consumer activity prior to a schedule sporting event can be determined, which may be done, e.g., using tables having negative time ranges with the ending event as an initial key or with positive time ranges with the ending event as a final key. 69 [0322] XII. PRE-AUTHORIZATION OF A TRANSACTION [0323] It is advantageous to be able to authorize a transaction quickly while maintaining an accurate risk assessment of the transaction, e.g. via an authorization process. As mentioned above, once a pattern has been determined, a future 5 transaction can be predicted to occur, e.g., in a specific time window. Knowing when a future transaction might occur can allow a determination of whether to authorize the future transaction before the transaction actually occurs. Such pre-authorizing can provide quicker responses to authorization requests or can even be used to send authorization before a request is made. 10 [0324] FIG. 15 is a flowchart of a method 1500 for pre-authorizing a transaction of a consumer according to embodiments. In one embodiment, previous transactions (e.g. 210) are used to determine a future transaction that can be pre-authorized, and when such an authorization can be valid. In one implementation, transactions within a specific time period are analyzed, e.g., last year or all transactions before an end 15 time. [0325] In step 1510, data associated with transactions previously performed, e.g. by the consumer or other similar consumers (an affinity group), is received. Each transaction can have any number of pieces of data associated with it. This data can be used to identify a particular type of transaction. 20 [0326] In step 1520, transactions are optionally correlated with other transactions and events. In this manner, different transaction patterns can be identified for different types of transactions. Other events (e.g. start or end of a day, week, etc.) can be correlated to transactions as well. In one embodiment, pairs of correlated keys (e.g. a key pair <KI:KF>) are determined based on whether events associated 25 with an initial key (KI) are correlated with transactions with a final a final key (KF). [0327] In step 1530, one or more patterns of when the previous transactions occur are determined with a computer system, e.g., the transaction analyzer 26(c). The patterns can convey the likelihood of a transaction as a function of time. For example, pattern 220 conveys that transactions are likely when the function has a 30 higher value. In one embodiment, pairs of correlated transactions (or other events) are used to determine a pattern, e.g., as times of final transactions related to initial events. The times can be stored as an absolute time and/or date for each transaction (e.g. in chronological order) or organized as elapsed times for correlated 70 events of certain key pairs. In some embodiments, the time information is stored (e.g. in transaction history database 26b) associated with the corresponding key pair. In one embodiment, the time information for the key pair <K1:K2> can be stored in a database table that can be accessed with a query containing K1, K2, or the 5 combination (potentially in the order of K1:K2). [0328] In step 1540, the one or more patterns are used to predict when the consumer is likely to initiate a future transaction. In one embodiment, the likelihood is for any transaction by the consumer, and thus the entire transaction history can be used. In another embodiment, the likelihood is for a particular transaction. When a 10 particular transaction is being investigated, the relevant pattern can be found by querying a database using the key(s) of the particular transaction. [0329] In some embodiments, a single point in time can be determined for the when the future transaction is likely to occur. However, such embodiments can be impractical, especially when times are reported to the second. In other 15 embodiments, a time window when the consumer is likely to initiate a future transaction is determined. The time window may be specified in any number of ways. For example, the time window may specify a start date/time and an end date/time. Multiple time windows can be specified. [0330] In one embodiment, the patterns of the previous transactions are used to 20 determine a likelihood for the future transaction at a plurality of times. A time window can be identified by analyzing the consumer's transaction pattern to determine times with a desirable level of likelihood for a transaction to occur. In such embodiments, the time window can be obtained with greater accuracy since a plurality of times are used. Also, one can be more likely to identify a time window having a desirable level 25 of likelihood since multiple times are analyzed. [0331] A pattern can have certain indicia that can be analyzed to determine likelihoods at different times. In one embodiment, the indicia of the relevant pattern can be input into a modeling function as part of the determination of the time window. In another embodiment, the time window is determined from when the pattern shows 30 a likelihood above a threshold value. If the likelihood is sufficiently high, it can be assumed with greater certainty that the transaction will actually be from the consumer and not a fraudster. In these and other embodiments, the duration of the time window can be variable (i.e. no predetermined) duration. For instance, the 71 duration of the time window can be based on the likelihood values (e.g. the times when the likelihood rises above and falls below the threshold. [0332] The time window for a first consumer can also be based on the transaction activity of other consumers, or in place of the transaction activity of the first 5 consumer. For example, the pre-authorization could also be sent at a particular time that a transaction for such a product is predicted for a similar consumer, and thus can be likely for the first consumer. Such a strategy may be employed when data for the first consumer is limited and does not yet show the particular pattern. [0333] In an embodiment using other consumers, the first consumer can be 10 determined to be similar to an affinity group (group of similar consumers). In one aspect, consumers can be similar to an affinity group with varying degrees of similarity (e.g. by percentage of similarity). In one embodiment, a likely time window can correspond to when a corresponding affinity group has a high likelihood for the transaction at a specific time, but the consumer does not show any pattern for the 15 transaction or has a relatively low likelihood at the specific time (but potentially high at other times). In another embodiment, the optimization algorithm mentioned above can also be trained using previous patterns from multiple entities. [0334] Referring back to method 1500, in step 1550, an authorization server generates an authorization of the future transaction before the consumer initiates the 20 transaction. In one embodiment, the authorization is generated by a payment processing network (e.g. network 26). In another embodiment, the authorization can be generated at an issuer, potentially in conjunction with a payment processing network. [0335] In one embodiment, the authorization is only valid during a time window in 25 which the transaction is determined to be likely. In another embodiment, the authorization could specify more than one time window, e.g., if the probability function shows a high likelihood around the 15-1 7 th of the month, but only for 5pm 10pm. In yet another embodiment, a pre-authorization sent to a consumer or merchant can continue to be valid for a certain time every week (e.g. 5-7 pm on 30 Thursday). In this manner, a pre-authorization does not have to be sent every week. A revocation of the pre-authorization can be sent when the likelihood of the transaction no longer supports an authorization. 72 [0336] In step 1560, the generated authorization can be used to respond to an authorization request. When a matching authorization already exists, a normal authorization process can be bypassed. For example, if an authorization request for a current transaction is received from a merchant, the current transaction can be 5 matched to the predicted transaction of the generated authorization. Once the current transaction is matched, an approval can be sent to the merchant. In one embodiment, an authorization server can save the generated authorization in a RAM or other local memory of a server, which can be accessed quickly. [0337] In one implementation, keys can be used to match the current transaction 10 with the predicted transaction. In another implementation, the matching can compare a time of when future transaction was predicted to the time of the current transaction. For example, if the time of the current transaction falls within a predicted time window, then the transaction can be authenticated as originating from the consumer. The authentication can be absolute (i.e. authenticated or not) or be at 15 varying levels (e.g. 60% probably the consumer). The authentication can be used as one factor in an authorization procedure, which can include patterns of fraud as well as a determination of whether the consumer has sufficient funds. [0338] In one embodiment, a token (e.g. an authorization code) associated with the authorization can be sent to the consumer, who can use it for a transaction with a 20 merchant. A token can be any electronically identifiable object, which can include characters that can be entered for electronic transmission. A token could include the account number of a consumer. The merchant can then send the token to an authorization server (e.g. of a payment processing network), which can use the token to cross-reference a list of generated authorizations to determine if a 25 corresponding authorization exists and if the authorization is valid (e.g. checking whether the transaction is within a time window) Once an authorization expires, the authorization can be removed form a list of valid authorizations. In one embodiment, the authorization server can be of an acquirer for the merchant, which can save the authorization. The acquirer can then respond without waiting for a response from a 30 payment processing network or an issuer. [0339] In step 1570, as a different option to step 1560, the authorization can be transmitted (e.g. from the payment processing network 26) to a server associated with a first merchant. The authorization can be sent prior to the consumer initiating a transaction, and thus the authorization is ready when the consumer initiates the 73 transaction. In one embodiment, the authorization is only valid during a time window in which the transaction is predicted to be likely. In another embodiment, the authorization is only valid for a transaction amount less than a specified amount or within a specified range. 5 [0340] The first merchant can be identified via a specific pattern in which the transaction was predicted. For example, a key of a pattern can be specifically associated with a merchant or a group of merchants. The key can be identified when the transaction data includes information regarding a merchant or a merchant category. For a group of merchants, the authorization can be sent to each merchant 10 of a group or only certain ones. [0341] In step 1580, when the transaction does occur (e.g. in the specified time window), the merchant can immediately complete the transaction since the transaction is pre-authorized. For instance, the merchant can send transaction data (which may include the token) to an acquirer, but not wait for an authorization 15 response. A specific channel could be used so that the acquirer and a payment processing network know that a pre-authorization has been used. In another embodiment, the merchant can send the authorization (e.g. as a token) back to the authorization server, which can provide confirmation that the authorization is still valid. This may be done, for example, when a valid time window is not specified to 20 the merchant. [0342] Instead of sending the authorization to a merchant, the authorization can be sent to the consumer, e.g. as an authorization token. The token can be sent to the consumer in numerous ways, e.g., in any electronic message to a computing device or account associated with the consumer. For example, the token can be sent to a 25 user's mobile phone, which can be used a payment device (e.g., portable consumer device 32). In one embodiment, the authorization can be for a specific account of the user. The token can or cannot convey a time and/or amount when the authorization is valid. [0343] In one embodiment, such an authorization token can be coupled with an 30 incentive. The consumer can then present the authorization code to the merchant, who can verify the code. In another embodiment, the authorization token can include information used to verify (e.g. a time when valid and a valid merchant). In 74 embodiments where the pre-authorization is sent to the consumer, a merchant advantageously does not need to be known. [0344] As an example, a consumer might have a predicted transaction pattern after visiting a certain website (an initial event). A future transaction can be predicted to 5 occur within a time window correlated to the time that the website was visited. For example, a time window from 30 minutes to an hour after the website was visited can be used. If the predicted transaction does occur in that time window, a previously generated authorization can be used. As another example, a consumer's transactions can be tracked relative to the beginning of a month. For example, a 10 person might buy lottery tickets on the 15 th of every month. This pattern can be identified, and merchants at which the consumer might be the lottery ticket can be sent a pre-authorization, or an authorization server can generate an authorization and wait for an authorization request. [0345] XIII. GENERALIZATION OF CALCULATION 15 [0346] Any of the calculations above can be generalized to a basic framework, which can include contributions from different types of established patterns (potentially from multiple entities), as well as contributions from multiple entities for the short-term tables. [0347] A. One Entity 20 [0348] In some embodiments, the account entity corresponding to a particular consumer is the only entity involved in a calculation. The account entity can be represented as Ga. Ga can refer generally to all of the tables associated with a particular account entity. The notation Ga(mcc,ctry:mcc,ctry) refers to the specific set of tables (and thus a specific type of patterns) where the keys have key elements 25 in categories mcc (merchant code) and ctry (country). [0349] An event is represented with E, which can act as an impulse as described above. The event can be represented with any key elements mentioned herein and be of any type of event (e.g. a transaction or a start of a time period) mentioned herein. In one aspect, the event E can be represented with a key having key 30 elements from the same categories as the specific account object, in this case mcc and ctry. 75 [0350] In some embodiments, the indicia V of account patterns relevant to an event E can be obtained with the formula: V= E 0 Ga(mcc,ctry:mcc,ctry). The event E can be for a final or an initial event. The symbol 0 is a filtering operation that selects the relevant tables from a particular object (i.e. set of tables for the account 5 entity). [0351] In one embodiment, the event E can be represented by one or more tables (e.g. similar to tables 1130), and the filtering can be performed by matching (including aligning) and multiplying the tables. In another embodiment, the result of a filtering operation (e.g. the above V) can be matrix elements of one table or 10 multiple tables, e.g., as described for FIGS. 9 and 11. Also, the matrix elements can be summed to provide one number, e.g., if one wanted a total probability to occur during all of the time ranges. [0352] When only specific frequency patterns are desired, a mask matrix can be used, as described herein. An example of a formula obtaining indicia with a mask 15 matrix is V= E 0 (Mlow - Ga(mcc,ctry:mcc,ctry)). Here, Mlow is a low pass filter implemented as a mask matrix, e.g., a matrix having 1s in matrix elements for the desired frequencies and Os in the other matrix elements. The operator - is an element by element multiplication, which can be performed for each table. [0353] In one embodiment, a combination of events may be used in a calculation. 20 For example, the last five events for the Ga account entity may be used. In simplified notation, this can give the formula: V= El 0 Ga, E2 0 Ga, E3 0 Ga, E4 0 Ga, E5 0 Ga. Thus, if the last five events were used, five sets of indicia (e.g. 5 tables) could be obtained using the above formula. The previous events could be used to see if potentially fraudulent behavior has recently been seen for the 25 particular account. In another embodiment, the indicia for each event can be combined, thereby still providing only one table. [0354] The formulas above can equally be applied to other entities, such as an affinity group or a merchant. The formulas effectively determine how the impulse events fit the established patterns of the entity. Also, Ga can be linear combination 30 of other entities, e.g., affinity groups, as described above. 76 [0355] B. One Entity with Multiple Types of Patterns [0356] For just one event, there can be multiple types of patterns, each of which can be output as a different set of indicia. One type of pattern can be for when any transaction for a consumer occurs. Other types of patterns can include a pattern of 5 transactions: at a specific store or during a specific time period; from issuer country to acquirer country; from zip codes to other zip codes; from prior mcc to mcc, and in a specific country. Thus, a type of pattern can correspond to a particular combination of categories of key elements for a key pair, e.g., <mcc:mcc> and <zip:zip> can be different types of patterns. 10 [0357] As an event can be associated with many keys and different patterns may exist for different categories of key elements, further symbols can be used to identify a unique representation of E. For example, E(:mccl,ctryl,merchl) can be an impulse for specific values (mccl,ctryl,merchl) for the key elements mcc, ctry, and merch (merchant name) in a final key. Accordingly, in an embodiment, the indicia V 15 of account patterns relevant to a final event E can be obtained with the formula: V= E(:mccl,ctryl,merchl) 0 Ga( *:mcc,ctry,merch), E(:mccl,ctryl) 0 Ga(mcc,ctry:mcc,ctry), E(:mccl,ctryl) 0 Ga(*:mcc,ctry). [0358] As shown, there are three sets of indicia (separated by a comma), one set for each filtering operation and each type of pattern. The result of each filter can be 20 matrix elements of one table or multiple tables. The wildcard "*" in Ga(*:mcc,ctry,merch) denotes that this set of tables include any events associated with the entity Ga for the initial event, and not just events with a particular key. As an example, for a final key of (mccl,ctryl,merchl), the key pair table can track a pattern of (mccl,ctryl,merchl) events occurring after any event. 25 [0359] C. Multiple Entities with One Type of Pattern [0360] In a calculation of one set of indicia, more than one entity can be used, e.g., as described for FIG. 11 with an account entity and a normalized fraud entity. The normalized fraud entity can be represented as Gt. Thus, in one embodiment, the indicia V of account patterns relevant to a final event E can be obtained with the 30 formula: V= E(:mccl,ctryl,merch1) 0 ((Gt(*:mcc,ctry,merch) - Ga-st( *:mcc,ctry,merch)). Here, Ga-st are short term tables for an account entity. In this manner, the recent 77 behavior of the account entity can be checked for fraudulent behavior based on particular final events E. [0361] The inner product operator - is an element-by-element multiplication of matching or aligned tables. In one embodiment, when complex numbers are used, 5 the multiplication is performed by multiplying the real parts by the real parts and imaginary parts by the imaginary parts (i.e. real*real and imaginary*imaginary). A normalization can also occur after the inner product is taken. [0362] In one embodiment, the filter operation can act first on Ga to create a short-term table for an event, for example, as described for tables 1130. The 10 formula can be more efficient and could be written as: V= (E(:mcc1,ctry1,merch1) @ (Ga-st(*:mcc,ctry,merch)) - Gt( *:mccctrymerch). [0363] The other entity can be any other entity, not just a fraud entity. In one embodiment, the other entity is one in which an established pattern is to be compared to Ga-st. Also, Gt or tables for another entity can be created in different 15 ways, e.g., other than the normalizing division operation from FIG. 11. In one aspect, the multiplication of Ga with the tables of the other entity provides a measure of a larger group (e.g. all consumers) to be of a certain type (e.g. fraudsters). [0364] D. Multiple Entities with Multiple Types of Patterns [0365] The concepts above can be combined. Thus, in one embodiment, the indicia 20 V of account patterns relevant to a final event E can be obtained with the formula: V=(E(:mcc1,ctry1,merch1) 0 (Ga-st(*:mcc,ctry,merch)) - Gt( *:mccctrymerch), (E(:mccl,ctryl) 0 (Ga-st(mcc,ctry:mcc,ctry)) - Gt( mcc,ctry:mcc,ctry), (E(:mccl,ctryl) 0 (Ga-st(*:mcc,ctry)) - Ga( *:mcc,ctry). Each set of indicia can be calculated independently, and in parallel. Also, the 25 calculation for each set of indicia can use a different Gt, which can be for different entities. [0366] E. Multiple Account Entities [0367] In some embodiments, more than one account entity can be used in a calculation regarding patterns for a particular account entity Ga. A reason for such a 30 combination can be that information about what other consumers do can be useful in investigating the patterns of a particular consumer. For example, what other 78 consumers in the same affinity group or geographic location and be helpful. One other entity is Gh, which can include all of the consumers in the same household as the consumer for account entity Ga, where Gh-st is the recent behavior (e.g. tables of recent transactions) for the household. Other examples include the consumers in 5 the same zip code or on the same street as Ga. These other entities incorporate contributions from these entities as to whether an event fits an established pattern, or is unusual for a particular consumer, merchant, affinity group, etc. [0368] In the following formula, the different representations of impulse events are labeled with short hand. Each impulse notes the account entity and the number 10 within the account entity. Thus, in one embodiment, the indicia V of account patterns relevant to a final event E can be obtained with the formula: V = Eal @ ( Gt (*:mcc,ctry,merch) - ( Mlowpass - Ga-st(*:mcc,ctry,merch))), Ea2 0 ( Gt (mcc,ctry:mcc,ctry) - ( Mlow - Ga-st(mcc,ctry:mcc,ctry))), Ea3 0 ( Gt (*:mcc, ctry) - ( Mlow - Ga-st(*:mcc,ctry) ) ), 15 Eh1 0 ( Gt (*:mcc,ctry,merch) - ( Gh-st(*:mcc,ctry,merch))), Eh2 0 ( Gt (*:mcc, ctry) - ( Gh-st(*:mcc,ctry) ) ), Eh3 0 ( Gt (mcc, ctry:mcc,ctry) - ( Gh-st(mcc,ctry:mcc,ctry))). As mentioned above, the order of operation can vary from that indicated. [0369] Any of the computer systems mentioned herein may utilize any suitable 20 number of subsystems. Examples of such subsystems are shown in FIG. 16 in computer apparatus 1600. In some embodiments, a computer system includes a single computer apparatus, where the subsystems can be the components of the computer apparatus. In other embodiments, a computer system can include multiple computer apparatuses, each being a subsystem, with internal components. 25 [0370] The subsystems shown in FIG. 16 are interconnected via a system bus 1675. Additional subsystems such as a printer 1674, keyboard 1678, fixed disk 1679, monitor 1676, which is coupled to display adapter 1682, and others are shown. Peripherals and input/output (1/O) devices, which couple to 1/O controller 1671, can be connected to the computer system by any number of means known in 30 the art, such as serial port 1677. For example, serial port 1677 or external interface 1681 can be used to connect computer system 1600 to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus 1675 allows the central processor 1673 to communicate with each subsystem 79 and to control the execution of instructions from system memory 1672 or the fixed disk 1679, as well as the exchange of information between subsystems. The system memory 1672 and/or the fixed disk 1679 may embody a computer readable medium. Any of the values mentioned herein can be output from one component to another 5 component and can be output to the user. [0371] A computer system can include a plurality of the same components or subsystems, e.g., connected together by external interface 1681. In some embodiments, computer systems, subsystem, or apparatuses can communicate over a network. In such instances, one computer can be considered a client and another 10 computer a server. A client and a server can each include multiple systems, subsystems, or components, mentioned herein. [0372] The specific details of particular embodiments may be combined in any suitable manner without departing from the spirit and scope of embodiments of the invention. However, other embodiments of the invention may be directed to specific 15 embodiments relating to each individual aspect, or specific combinations of these individual aspects. [0373] It should be understood that the present invention as described above can be implemented in the form of control logic using hardware and/or using computer software in a modular or integrated manner. Based on the disclosure and teachings 20 provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software [0374] Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any 25 suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions, or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy 30 disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices. 80 [0375] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data 5 signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer program product (e.g. a hard drive, a CD, or an entire computer system), and may be present on or within different 10 computer program products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user. [0376] The above description of exemplary embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be 15 exhaustive or to limit the invention to the precise form described, and many modifications and variations are possible in light of the teaching above. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as 20 are suited to the particular use contemplated. [0377] Other methods of determining risk can be found in patents 6,018,723; 6,119,103; 6,658,393; and 7,227,950, which are incorporated by reference.

Claims (26)

1. A method of determining a likelihood of an occurrence of a second transaction involving a consumer, the method comprising: receiving data associated with first transactions previously performed by the consumer; determining a plurality of correlated pairs of the first transactions, wherein a correlated pair of first transactions includes an initial transaction and a final transaction that occurs after the initial transaction; providing a plurality of counters, wherein each counter in the plurality of counters is associated with a different time range; after determining the plurality of correlated pairs of the first transactions, for each correlated pair of transactions: a computer system determining a time interval between the final transaction and the initial transaction of the correlated pair; the computer system selecting a counter of the plurality of counters having a first time range that includes the time interval; and the computer system increasing a counter of the plurality of counters; and using the values of the counters to determine a likelihood of an occurrence of the second transaction involving the consumer.

2. The method of claim 1, wherein the likelihood of the occurrence of the second transaction involving the consumer is a likelihood of the second transaction occurring at a particular time.

3. The method of claim 1, wherein the second transaction is a future transaction that has not occurred.

4. The method of claim 1, further comprising: associating one or more keys with each first transaction previously performed by the consumer and the second transaction, the second transaction associated with a first key; and for each correlated pair of first transactions, selecting at least one set of one or more keys that are associated with the correlated pair of first transactions, wherein the plurality of counters include a set of counters for each selected set of one or more keys. 83

5. The method of claim 4, wherein each increased counter is also associated with an amount of at least one of the transactions of the correlated pair, and wherein the counters of a set form a table of various amounts and time ranges.

6. The method of claim 4, wherein a key includes at least a portion of the data associated with a first transaction.

7. The method of claim 4, wherein increasing a counter of the plurality of counters for a correlated pair of first transactions includes increasing a counter for each set of counters associated with the correlated pair, wherein each increased counter is associated with the time interval for the correlated pair.

8. The method of claim 4, wherein the counters of a set are associated with various time ranges.

9. The method of claim 8, wherein the various time ranges for each set of counters are predetermined.

10. The method of claim 9, wherein each time range corresponds with a frequency of a periodic function that is used to determine the likelihood of the occurrence of the second transaction involving the consumer.

11. The method of claim 9, wherein the time ranges increase in length as the time intervals within the time ranges increase.

12. The method of claim 11, wherein a portion of the counters of a set are respectively associated with time ranges of: zero to 1 minute, between 1 minute and 2.7 minutes, between 2.7 minutes and 7.4 minutes, between 7.4 minutes and 20 minutes, and over 1.2 million minutes.

13. A method of determining a likelihood of an occurrence of a second event involving a consumer, the method comprising: receiving data of first events associated with the consumer; associating one or more keys with each first event and the second event, the second event associated with a first key; 84 determining a plurality of correlated pairs of the first events, wherein a correlated pair of first events include an initial event and a final event that occurs after the initial event; for each correlated pair of the first events, identifying one or more key pairs associated with the correlated pair; providing a set of counters for each identified key pair, wherein each counter in the set of counters is associated with a different time range; after determining the plurality of correlated pairs of the first events, for each correlated pair of first events: a computer system determining a time interval between the final event and the initial event of the correlated pair; for each key pair associated with the correlated pair of first events: selecting a counter having a first time range that includes the time interval; and the computer system increasing the counter; and identifying a group of the key pairs associated with the first key; and using at least one of the values of the counters of each of the identified group of the key pairs to determine a likelihood of an occurrence of the second event involving the consumer.

14. The method of claim 13, wherein the second event has already occurred.

15. The method of claim 13, wherein each set of counters is stored in a table associated with a respective key pair.

16. The method of claim 15, wherein the first events are associated with an amount, and wherein the tables have amount ranges on a first axis and time ranges on a second axis.

17. The method of claim 15, wherein each of the key pair tables is associated with an initial key associated with the initial events used to determine the counters of the respective key pair table and a final key associated with the final events used to determine the counters of the respective key pair table.

18. The method of claim 17, wherein identifying a group of the key pairs associated with the first key includes: 85 identifying a group of one or more key pairs having a final key that matches the first other key; selecting the sets of counters of the identified group of the key pairs; and using the selected sets of counters to determine the likelihood of the occurrence of the second event involving the consumer.

19. The method of claim 18 wherein using the selected sets of counters to determine the likelihood of the occurrence of the second event involving the consumer includes: for each of the identified group of key pairs: identifying a third event associated with the initial key of the key pair; determining a respective time interval between the second event and the third event; using the respective time interval to identify a counter from the respective set of counters, the identified counter associated with the time range that includes the determined time interval.

20. The method of claim 19, further comprising: summing the values of the identified counters.

21. The method of claim 18, wherein identifying a group of one or more key pairs having a final key that matches the first other key includes: matching the first other key associated with the second event to the final keys of the identified group of key pairs, wherein matching the first other key includes aligning the first other key by broadening key elements of the first other key until a match with the final key is found.

22. The method of claim 17, wherein using the values of the counters to determine the likelihood of the occurrence of the second event involving the consumer includes: identifying one or more other keys associated with the second event, the one or more other keys including a first other key; identifying a group of one or more key pairs having an initial key that matches the first other key; selecting the sets of counters of the identified group of key pairs; and using the selected sets of counters to determine the likelihood of the occurrence of the second event involving the consumer. 86

23. The method of claim 13, wherein at least one of the first events associated with the consumer includes a beginning of a time period.

24. The method of claim 13, wherein at least one of the first events associated with the consumer includes a financial transaction.

25. A computer program product comprising a tangible computer readable medium storing a plurality of instructions for controlling one or more processors to perform the method of any one of claims 1-24.

26. A computer system comprising: one or more processors; and the computer program product of claim 25. Visa International Service Association Patent Attorneys for the Applicant/Nominated Person SPRUSON & FERGUSON