Systems and methods for dynamic report generation based on automatic modeling of complex data structures

Description

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

This application claims priority benefit under 35 U.S.C. § 119(e) to U.S. Provisional Application No. 62/094,819, filed on Dec. 19, 2014, entitled “Systems and Interactive User Interfaces for Database Access and Application of Rules to Determine Recommendations for User Actions,” the disclosure of which is incorporated herein by reference in its entirety. Any and all applications for which a foreign or domestic priority claim is identified in the Application Data Sheet as filed with the present application, or any correction thereto, are hereby incorporated by reference under 37 CFR 1.57.

This application is also related to U.S. application Ser. No. 14/975,654 (now U.S. Pat. No. 10,242,019) filed on the same day as the present application, entitled “USER BEHAVIOR SEGMENTATION USING LATENT TOPIC DETECTION,” the disclosure of which is hereby incorporated herein by reference in its entirety.

This application is also related to U.S. application Ser. No. 14/975,536 filed on the same day as the present application, entitled “SYSTEMS AND METHODS FOR GENERATING ENTITY RECOMMENDATION DATA,” the disclosure of which is hereby incorporated herein by reference in its entirety.

BACKGROUND

With the advent of modern computing devices and communication networks, the ways in which users use electronic devices to interact with various entities has dramatically increased. Each user event—whether by making a small purchase at a grocery store, logging into a web-site, checking out a book from a library, driving a car, making a phone call, or exercising at the gym—can be tracked. The availability of this data makes it possible to analyze a user's event behaviors and take actions based on the analysis.

One particular advantage of having access to such event data is the ability to identify when a user's activity patterns change. A change in a user's behavior may signal an opportunity for an interested party (e.g., a merchant or a credit issuer) to actively engage the user to motivate or otherwise incentivize the user to transact. The change in behavior may also provide an opportunity for the interested party to engage the user to gain an understanding of the user's reasons for changing behavior.

SUMMARY

Various systems and methods are disclosed for accessing and traversing disparate, complex, and multi-dimensional data structures to dynamically and interactively generate reports based on automated modeling of complex and non-uniformly formatted data. Automated analysis of probabilistic functions and temporal based data records enable non-technical users to quickly and dynamically act on time-sensitive information. In response to various user inputs, the system automatically accesses and traverses complex data structures (including, for example, frequency distribution models) calculates complex data based on the traversals, displays the calculated complex data to the user, and enters the calculated complex data into the reports.

This disclosure presents systems, methods, devices, and non-transitory, computer-readable media directed to accessing and traversing disparate, complex, and multi-dimensional data structures to analyze event behavior of populations of users and of individual users. In particular, changes in an individual user's event behavior may be detected, and timely, actionable alerts may be transmitted to interested parties.

According to one embodiment, a system dynamically generates event frequency distribution models for populations and for individual users by automatically modeling data traversed, accessed, and derived from complex and multi-dimensional data structures. The system employs principles of artificial intelligence and machine-learning to automatically update the event frequency distribution models. The system performs automated analysis of probabilistic functions and temporal-based data records to enable non-technical clients and users to quickly and dynamically act on time-sensitive information. In certain embodiments, the system enables real-time analysis and corresponding action in response to event triggers.

In one embodiment, various client inputs are provided interactively. In response to the inputs, the system automatically accesses and traverses complex and disparate data structures, calculates complex data based on the traversals, automatically generates probabilistic event frequency distribution models to predict future behavior, displays the calculated complex data and models to the client, and enters the calculated complex data into reports that are generated for and transmitted to the client.

In certain embodiments, an event frequency distribution model is constructed for each user. The event frequency distribution model may be based, initially, on the event data of a population relevant to the user as well as the user's historical event behavior. The event frequency distribution model provides the likelihood that the user will perform a particular event in the future. Future event behavior (i.e., new events or a lack of new events) cause changes to this distribution model. If a preset unlikeliness threshold is exceeded an alert may be generated. These event frequency distribution models can be constructed for a user's overall volume of events and/or for a user's events in certain categories and/or sub-categories of events that a client might wish to monitor. Advantageously, event change alerts may be transmitted to the interested entities when specific conditions are met. In one embodiment, the output of this solution is zero or more event change alerts for each user for whom a significant change in event behavior has occurred. Additional information about the user, for example attributes describing the user's recent behavior or characteristics of the user's event frequency distribution model can also be included in the event alert output to assist interested parties in acting on the provided information.

According to an embodiment, a computing system is configured to access one or more electronic data sources in response to periodic automated inquiries in order to automatically calculate data for inclusion into a report. The computing system comprises a computer processor that is configured to execute software instructions and a non-transitory storage device storing a plurality of software components. The software components include, without limitation, a data aggregation component that is configured to access a plurality of event records associated with respective users, where each of the event records indicates an event made by the associated respective user. For each of the event records, the data aggregation component assigns a category to the event record. The category is selected from a plurality of predetermined categories. Another of the software components is an event distribution component configured to generate a baseline event frequency distribution model that indicates a likelihood of an event by a generic user based on the accessed plurality of event records. The event distribution component also generates a user profile for a particular user, wherein the user profile comprises categorized event records associated with the particular user during a set time period. The event distribution component updates the baseline event frequency distribution model, based on the categorized event records in the user profile of the particular user, to generate a user event frequency distribution model. Another software component is an event distribution update component configured to periodically access event data sources to determine whether there is an additional event record associated with the particular user that has not been analyzed by the computing system. In response to determining that there is an additional event record associated with the particular user that has not been analyzed by the computing system, the event distribution update component updates the user event frequency distribution model based on the additional event record to form an updated user event frequency distribution model. Another software component is an event change alert component configured to access the generated user profile for the particular user and the updated user event frequency distribution model. The component determines a gap, indicating a time period since a last event by the particular user occurred, and compares the determined gap to a gap limit that indicates an expected period of time between events. In response to determining that the gap is greater than the gap limit, the event change alert component generates an event change alert and transmits, to a client system, the generated event change alert.

In one aspect of the present disclosure, the event change alert component is further configured to determine, in response to determining that the gap is greater than the gap limit, if a filter condition exists, and in response to determining that a filter condition does not exist, generate an event change alert.

In another aspect of the present disclosure, the gap limit is a period of time in which the particular user is expected to perform a next event within a specified probability, the gap limit being based on the updated user event frequency distribution model for the particular user.

In another aspect of the present disclosure, the gap limit is a period of time within which the particular user is expected to perform a next event, for example, a ninety-five percent (95%) probability, based on the updated user event frequency distribution model for the particular user.

In another aspect of the present disclosure, the event distribution component is further configured to generate a category baseline event frequency distribution model for a particular category. The model indicates a likelihood of an event in the particular category by a generic user based on a set of the accessed plurality of event records that are assigned to the particular category. The event distribution component is also configured to update the generated category baseline event frequency distribution model for the particular category based on a set of the categorized event records of the particular user and associated with the particular category to generate a category-specific user event frequency distribution model.

In another aspect of the present disclosure, the event distribution update component is further configured to periodically access event data sources to determine whether there is an additional event record associated with the particular user and with the particular category, and in response to determining that there is an additional event record associated with the particular user and with the particular category, update the category-specific user event frequency distribution model based on the determined additional event record.

In another aspect of the present disclosure, the event change alert component is further configured to determine a second gap, indicating a time period since a last event by the particular user associated with the particular category occurred, and compare the second gap to a second gap limit indicating an expected period of time between events associated with the particular user and with the particular category. In response to determining that the second gap is greater than the second gap limit, the event change alert component is configured to generate a category-specific event change alert, and to transmit, to a client system, the category-specific event change alert.

In another aspect of the present disclosure, the event distribution update component is further configured to generate an event frequency distribution model for the additional event record associated with the particular user, and calculate a weighted sum of the event distribution for the additional event record and the user event frequency distribution model to generate the updated user event frequency distribution model.

In another aspect of the present disclosure, the event frequency distribution model for the additional event record associated with the particular user comprises a distribution having a one hundred percent (100%) probability of occurring within a time period between a last event by the particular user and a time of an event associated with the additional event record associated with the particular user. In another embodiment, the event frequency distribution model for the additional event record associated with the particular user comprises a distribution centered on a time period between a last event by the particular user and a time of an event associated with the additional event record.

In another aspect of the present disclosure, the event change alert component is further configured to generate the event change alert comprising an identification of an event category associated with the event change alert, a number of days since a last event by the particular user occurred, and a number of events performed by the particular user within a preceding two months.

In another aspect of the present disclosure, the event change alert component is further configured to, in response to determining that a filter condition exists, determine whether the filter condition is met, and in response to determining that a filter condition is not met, generate an event change alert indicating that the gap is greater than the gap limit and transmit, to a client system, the event change alert. The event change alert includes an identification of an event category associated with the event change alert, a number of days since a last event by the particular user occurred, and a number of events performed by the particular user within the preceding two months.

In another aspect of the present disclosure, the computing system further comprises a card reader in communication with the computer processor. The card reader includes an event information detector configured to detect event information for an event of a user, a targeted content generator configured to receive event data during the event of the user, and to identify content stored by the card reader using a comparison between a content selection rule and the event data, the content for presentation via the card reader, and a display configured to present the content to the user.

According to another embodiment, a method of automatically generating a transaction frequency change alert is disclosed. The method comprises accessing, from a raw transaction data store, a plurality of transaction records associated with respective users. Each of the transaction records includes attributes of a transaction made by the associated respective user. The method also includes accessing, from a categorized transaction data store, a transaction categories data structure including a plurality of transaction categories and, for each transaction category, attribute criteria usable to identify transactions associated with respective transaction categories. For each of the accessed plurality of transaction records, the method identifies one or more of the attributes of the transaction record and compares the identified one or more attributes of the transaction record to the attribute criteria of respective transaction categories to identify a transaction category among the plurality of transaction categories that matches the one or more attributes of the transaction record. The method categorizes the accessed transaction record with the identified transaction category and stores, in the categorized transaction data store, a plurality of categorized transaction records. The method also accesses, from the categorized transaction data store, the plurality of categorized transaction records and determines, for each user and for each pair of consecutive transactions of the user based on the accessed plurality of categorized transaction records, a time between transactions. The method generates, based on the determined time between transactions, a user base transaction frequency distribution model that indicates a likelihood of a transaction by a generic user based on the accessed plurality of categorized transaction records. The method identifies, from the accessed plurality of categorized transaction records, a first plurality of categorized transaction records associated with a first user and updates the generated user base transaction frequency distribution model based on the first plurality of categorized transaction records to generate a first user transaction frequency distribution model. The method periodically accesses, from the categorized transaction data store, additional categorized transaction records to determine whether there is an additional categorized transaction record associated with the first user which has not been analyzed, and in response to determining that there is an additional categorized transaction record associated with the first user that has not been analyzed, the method updates the first user transaction frequency distribution model based on the additional categorized transaction record. The method accesses the updated first user transaction frequency distribution model and determines a time duration since a last transaction by the first user occurred and compares the determined time duration to a threshold period of time. The threshold period of time indicates an expected period of time between transactions. In response to determining that the time duration is greater than the threshold period of time, the method generates a spend change alert and transmits, to a client system, the generated spend change alert.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram of an example of a transaction data spend change alert system.

FIG. 2 illustrates example transaction frequency distribution models for three different users that may be used to predict when the users will likely transact in the future.

FIG. 3 is an example process for delivering timely alerts in response to detected spend attrition risk.

FIG. 4 is a process flow diagram of an example method of generating and updating a transactional frequency distribution model.

FIGS. 5A and 5B depict a process flow diagram of an example method of updating a transactional frequency distribution model as well as generating and transmitting a spend change alert based on a change in the user's transactional behavior.

FIG. 6 is an example of a process to update a transaction frequency distribution model.

FIG. 7 is a process flow diagram of an example method of transmitting a spend change alert to a client, which in turn, transmits user communications to a user.

FIG. 8 is a schematic perspective view of an example credit/debit card reader.

FIG. 9 is a functional block diagram of the example credit/debit card reader of FIG. 8.

FIG. 10 is a block diagram showing example components of a computing system that may be used to implement the transaction data spend change alert system.

DETAILED DESCRIPTION

Disclosed herein are systems, methods, devices, and non-transitory, computer-readable media for accessing, traversing, analyzing, processing, and manipulating complex, multi-dimensional data structures having large sets of transaction data (also referred to herein as “event data”) of users to provide automated reports, visualizations, alerts, and other actionable intelligence to merchants, users, and others. The transaction data structures may include, for example, specific transactions (also referred to herein as “events”) on one or more credit cards of a user, such as the detailed transaction data that is available on credit card statements. Transaction data may also include transaction-level debit information, such as regarding debit card or checking account transactions. The transaction data may be obtained from various sources, such as from credit issuers (e.g., financial institutions that issue credit cards), transaction processors (e.g., entities that process credit card swipes at points-of-sale), transaction aggregators, merchant retailers, and/or any other source. Transaction data may also include non-financial exchanges, such as for example, login activity, Internet search history, Internet browsing history, posts to a social media platform, or other interactions between communication devices. In some implementations, the users may be machines interacting with each other (e.g., machine-to-machine communications).

This disclosure describes unique methods of accessing, traversing, and processing event data. In general, the features relate to probabilistic modeling and analysis of user transaction data which enable prediction of a user's transactional behavior based on that user's transactional history. The disclosure describes automated analysis of probabilistic functions and temporal-based data records to enable non-technical users to quickly and dynamically act on time-sensitive information. More particularly, the disclosure relates to machine-learning as applied to tracking the spending behavior of users, possibly within certain segments or categories, and predicting a likelihood of the user transacting in one or more particular segments within a certain time frame, again based largely on the transaction data of the user and/or populations of users. Further aspects are described for including features in transaction processing data flows and devices such as card readers or point-of-sale systems. Features for identifying targeted users and for providing content to the targeted users based on spending activity, and in particular, on changes in spending activity, are also included.

In some embodiments, a user's transaction data may be analyzed and processed to create a transaction frequency distribution model that may be used to predict a likelihood of the user spending in one or more particular segments or categories within a certain time frame. Advantageously, the transaction data spend change alert system may detect downward changes in the frequency and/or volume of a user's transactions, and provide alerts of such changes to merchants and/or other interested parties (i.e., clients).

Each of the processes described herein may be performed by a transaction data spend change alert processing system (also referred to herein as “the system,” “the transaction spend change alert system,” or “the processing system”), which may be implemented in a computing system such as the example computing system illustrated in FIG. 10 and discussed below. In other embodiments, other processing systems, such as systems including additional or fewer components than are illustrated in FIG. 10 may be used to implement and perform the processes. In other embodiments, certain processes are performed by multiple processing systems, such as one or more servers performing certain processes in communication with a client's or a user's computing device (e.g., mobile device) that performs other processes.

As noted above, in one embodiment the transaction data spend change alert system accesses transaction data associated with a user (and populations of users) to generate a transaction frequency distribution model for the user. This transaction frequency distribution model provides an assessment of the user's historical transactional activity that may be used to probabilistically predict the user's future transactions. In particular, the transaction data spend change alert system can identify when the user's spending activity decreases, generate one or more spend change alerts, and transmit the generated spend change alerts to one or more clients, enabling the clients to take actions, such as, by way of non-limiting example, sending promotional materials to the user.

Exemplary Definitions

To facilitate an understanding of the systems and methods discussed herein, a number of terms are defined below. The terms defined below, as well as other terms used herein, should be construed to include the provided definitions, the ordinary and customary meaning of the terms, and/or any other implied meaning for the respective terms. Thus, the definitions below do not limit the meaning of these terms; they provide exemplary definitions.

Transaction data (also referred to as event data) generally refers to data associated with any event, such as an interaction by a user device with a server, website, database, and/or other online data owned by or under control of a requesting entity, such as a server controlled by a third party, such as a merchant. Transaction data may include merchant name, merchant location, merchant category, transaction dollar amount, transaction date, transaction channel (e.g., physical point of sale, Internet, etc.) and/or an indicator as to whether or not the physical payment card (e.g., credit card or debit card) was present for the transaction. Transaction data structures may include, for example, specific transactions on one or more credit cards of a user, such as the detailed transaction data that is available on credit card statements. Transaction data may also include transaction-level debit information, such as regarding debit card or checking account transactions. The transaction data may be obtained from various sources, such as from credit issuers (e.g., financial institutions that issue credit cards), transaction processors (e.g., entities that process credit card swipes at points-of-sale), transaction aggregators, merchant retailers, and/or any other source. Transaction data may also include non-financial exchanges, such as login activity, Internet search history, Internet browsing history, posts to a social media platform, or other interactions between communication devices. In some implementations, the users may be machines interacting with each other (e.g., machine-to-machine communications). Transaction data may be presented in raw form. Raw transaction data generally refers to transaction data as received by the transaction processing system from a third party transaction data provider. Transaction data may be compressed. Compressed transaction data may refer to transaction data that may be stored and/or transmitted using fewer resources than when in raw form. Compressed transaction data need not be “uncompressible.” Compressed transaction data preferably retains certain identifying characteristics of the user associated with the transaction data such as spend patterns, data cluster affinity, or the like.

A message encompasses a wide variety of formats for communicating (e.g., transmitting or receiving) information. A message may include a machine-readable aggregation of information such as an XML document, a fixed-field message, a comma-separated message, or the like. A message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, a message may be composed, transmitted, stored, received, etc. in multiple parts.

The terms determine or determining encompass a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, looking up (e.g., looking up in a table, a database, or another data structure), ascertaining, and the like. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. Also, “determining” may include resolving, selecting, choosing, establishing, and the like.

The term selectively or selective may encompass a wide variety of actions. For example, a “selective” process may include determining one option from multiple options. A “selective” process may include one or more of: dynamically-determined inputs, preconfigured inputs, or user-initiated inputs for making the determination. In some implementations, an n-input switch may be included to provide selective functionality where n is the number of inputs used to make the selection.

The terms provide or providing encompass a wide variety of actions. For example, “providing” may include storing a value in a location for subsequent retrieval, transmitting a value directly to a recipient, transmitting or storing a reference to a value, and the like. “Providing” may also include encoding, decoding, encrypting, decrypting, validating, verifying, and the like.

A user interface (also referred to as an interactive user interface, a graphical user interface, a GUI, or a UI) may refer to a web-based interface including data fields for receiving input signals or for providing electronic information and/or for providing information to the user in response to any received input signals. A UI may be implemented in whole or in part using technologies such as HTML, Flash, Java, .net, web services, and RSS. In some implementations, a UI may be included in a stand-alone client (for example, thick client, fat client) configured to communicate (e.g., send or receive data) in accordance with one or more of the aspects described.

Example Spend Change Alert System

FIG. 1 shows a functional block diagram of an example of a transaction data spend change alert system 100. The transaction data spend change alert system 100 shown can process transaction data from a variety of sources. As shown, transaction data may be received from a credit bureau repository 102 or one or more financial institutions 104, such as financial institutions that issue credit and debit cards to users. Transaction data may also be received from credit/debit card readers 106 or from other sources of transactions 108, such as, by way of non-limiting example, a user's car, a gym, a library, a merchant, or another system with which the user interacts to perform a transaction.

Illustratively, transaction data may include, for example, data elements such as merchant name, merchant location, merchant category, transaction category, transaction sub-category, transaction dollar amount, transaction time, and whether the physical credit or debit card was present or not. The transaction data may be processed by the disclosed transaction data spend change alert system 100 using, e.g., machine learning algorithms applied to a large set of transaction data associated with multiple users.

The transaction data may be received by a spend distribution service 120. Although FIG. 1 shows a direct connection between the spend distribution service 120 and the sources of transaction data, it will be understood that other intermediate systems may be used during transmission. The spend distribution service 120 analyzes transactional data to predict when users—both individual users and populations of users—will likely engage in transactions in the future. The transaction data spend change alert system 100 may be particularly useful to provide clients with timely notifications when an individual user's transactional behavior changes. In some implementations, the transaction data spend change alert system 100 determines when a user exhibits a reduction in spending behavior. The reduction in spending behavior may be determined for example by a time between (or frequency of) transactions, thereby enabling the client to engage the user with timely and/or targeted communications designed to motivate the user to engage in transactions. Accordingly, the spend distribution service 120 is provided to generate and update probability distributions, based on historical transaction data, that can predict the likelihood a user will transact within a specified period of time (e.g., within 5 days).

The spend distribution service 120 includes a data aggregation module 130. The data aggregation module 130 is provided to organize transaction data prior to performing spend frequency distribution analysis. A transaction data collection service 132 is included to receive the transaction data from transaction data sources, such as a credit bureau repository 102, financial institutions 104, and credit/debit card readers 106, and other sources of transactions 108. The transaction data may be received via wire, wireless, or hybrid wired and wireless means. The transaction data collection service 132 may collect data by requesting transaction data from a data source. In some implementations, the transaction data collection service 132 may receive transaction data from a transaction data source such as according to a schedule.

The transaction data received from a transaction data source may be stored in a raw transaction data store 134. The raw transaction data store 134 may be a specialized data store device configured to handle large volumes of data.

The data aggregation module 130 shown in FIG. 1 includes a transaction categorization engine 136 that may be implemented using a hardware processor specially programmed with executable instructions to generate categorized transaction data. Illustratively, each user may be represented by a list of his or her transactions during the designated time period, and each transaction may be represented by a categorical description of the type of transaction. For example, a particular card transaction may be associated with a category of “Restaurant,” or more specifically “Chinese Restaurant.” Alternatively a transaction may also be represented by the specific merchant the transaction occurred at, for example “Starbucks,” or “Home Depot.” A more complex pre-processing step that automatically groups correlated merchants together may also be used to perform category assignment.

The executable instructions may further cause the transaction categorization engine 136 to categorize the transaction data. Categories may be included in the raw transaction data. In some implementations, the categories may be added to the raw transaction data by the transaction categorization engine 136. The category assigned to a particular transaction may be determined by the transaction categorization engine 136 using the transaction data such as an item identifier, an item name, merchant name, a merchant code, or a merchant category code, to name a few. For example, the spend distribution service 120 may analyze the transactional data for specific content, such as health and safety information. As such, it may be desirable to categorize the transactions in a variety of health and safety categories. In certain embodiments, the transaction categorization engine 136 may access from the categorized transaction data store 138, a transaction categories data structure that includes a plurality of transaction categories. For each transaction category, the data structure identifies attribute criteria that may be used to identify transactions associated with respective transaction categories. For each of the accessed transaction records, the transaction categorization engine 136 identifies one or more attributes of the transaction, compares the identified attributes with the attribute criteria to identify a transaction category that matches the identified attributes of the transaction record, categories the transaction record, and stores the categorized transaction record in the categorized transaction data store 138. The categories may be provided as a configuration to the spend distribution service 120 such that the same raw transaction data may be analyzed in different ways. The configuration may identify the available categories and transaction data that cause the transaction categorization engine 136 to assign the associated category.

The categorization process may also include normalizing the data such that transaction data from different sources provided in different data formats may each appear in a standardized data record. For example, the transaction data spend change alert system 100 may have a target record type and include one or more conversion algorithms to map data from the raw transaction record to a field of the target record type.

The normalization may also include spend level normalization. For example, the transaction categorization engine 136 may normalize a level of the transaction based on spend levels of individual users. This type of normalization helps smooth the discrete outlier transaction events in such a manner that a single relatively large or relatively small transaction does not skew the transaction data for a given user account.

The transaction categorization engine 136 is in data communication with a categorized transaction data store 138. The categorized transaction data store 138 may be a specially-configured transaction data storage device capable of handling large volumes of data. Illustratively, the transaction data spend change alert system 100 may include hundreds of millions, or billions of transaction records. Advantageously, the disclosed transaction data spend change alert system 100 is able to process these records in a duration of a few hours, whereas if such processing were to be performed manually by humans, it could take days, weeks, months, or years, depending on the number of human resources applied to the effort. In some implementations, the categorized transaction data store 138 may be commonly-implemented with the raw transaction data store 134. In some implementations, such as when the spend distribution service 120 provides data for different clients, it may be desirable to maintain separate data stores to ensure the security of the categorized data for each client.

The spend distribution service 120 includes a transaction distribution module 150. The transaction distribution module 150 is in data communication with the categorized transaction data store 138. The transaction distribution module 150 may be configured to generate and update user transaction frequency distribution models. According to some embodiments, a user transaction frequency distribution model is generated by compiling a multi-dimensional, relational data structure identifying, for example, each transaction and the amount of time between each transaction, among other parameters. Additional parameters of the transaction frequency distribution model data structure may include, without limitation, the merchant name, the merchant location, the merchant category, the transaction category, the transaction sub-category, the dollar amount of the purchase, the date of the transaction, the time of day that the transaction occurred, and whether or not the physical credit card was present, to name a few. Based on historical transaction data, a user transaction frequency distribution model may predict—with a degree of confidence—the likelihood that the user will engage in a future transaction within a specified period of time. Illustratively, by way of non-limiting example, a user transaction frequency distribution model may predict with a 95% probability that a user will transact within the next seven days.

To generate the user transaction frequency distribution models, the transaction distribution module 150 may include a user base distribution generator 152. The user base distribution generator 152 generates transaction frequency distribution models based on transactional histories of multiple users (i.e., populations). Illustratively, the user base distribution generator 152 may generate one or more transaction frequency distribution models based on the transactional data of users who share one or more attributes. For example, the user base distribution generator 152 may generate a transaction frequency distribution model for a set of users who attend live sporting events. The transaction frequency distribution models may include all users in the transaction data collection that meet this category, or alternatively, the transaction frequency distribution model may be based on a more selective set of users, such as those who have attended at least five live sporting events in the past year.

The transaction distribution module 150 may also include a user level distribution generator 154. The user level distribution generator 154 generates user transaction frequency distribution models for individual users, based at least in part on each user's historical transaction data. In some embodiments, the user level transaction frequency distribution model begins with a population-based user base model and then is updated with a user's specific transaction data. The user's transaction data may be weighted more heavily in the updating process so as to better account for the individual transactional practices and behaviors of the particular user.

In certain embodiments, the user level transaction frequency distribution model is based only on an individual user's transaction data. For certain users, the user level spend distribution based only on the user's transaction data may be the most accurate predictor of the user's future transactional behavior because it reflects only the past behavior of the user.

A distribution update generator 156 may be included in the transaction distribution module 150 to update previously-generated user base and user level distributions with new transaction data. The transaction frequency distribution models generated and updated by the user base distribution generator 152, the user level distribution generator 154, and the distribution update generator 156 can be stored on a transaction frequency distribution model data store 158 which is in data communication with the generators 152, 154, and 156.

The transaction data spend change alert system 100 may also include elements configured to generate alerts to clients based on, for example, changes in transactional behavior of a user. For example, an alert may be generated and communicated to a client enrolled in the services offered by the transaction data spend change alert system 100 when a user fails to transact within a predefined period of time.

As shown in FIG. 1, a change alert detection service 110 includes an alert condition detector 112, a filter condition detector 114, and an alert configuration engine 116. The change alert detection service 110 may use the transaction frequency distribution models stored in the transaction frequency distribution model data store 158 to detect an alert condition, to detect a filter condition, and to generate an alert to be sent to a client of the transaction data spend change alert system 100. A set of alert filtering rules may be stored in the filtering rules data store 122 and accessed by the alert condition detector 112 and the filter condition detector 114 and the alert configuration engine 116 to govern the circumstances under which an alert may be generated. Advantageously, the alert filtering rules, which optionally may be informed by user data sources, offer a high degree of customization for generating and communicating spend change alerts to a client.

The change alert detection service 110 may then generate an electronic communication to provide to the client, the electronic communication including content indicated by the alert configuration engine 116. In some implementations, the change alert detection service 110 may provide a description of the content of the generated alert to another aspect of the transaction data spend change alert system 100, such as an alert generation service 170. The alert generation service 170 may generate and communicate the identified content to the identified client.

To support these features of the change alert detection service 110, the alert condition detector 112 may be included to compare the user's transaction data with the user's transaction frequency distribution model to determine whether the user's spending behavior has changed to the point where it will trigger an alert condition. Illustratively, by way of non-limiting example, an alert condition may be detected when the user fails to transact within the time period that, according to the user's transaction frequency distribution model, has a ninety-five percent (95%) likelihood of occurring. The filter condition detector 114 may be included to detect additional filters to increase or decrease the sensitivity of the alerts. The alert configuration engine 116 may be included to configure an alert to be transmitted to the client. Using alert and filtering rules, the alert configuration engine 116 may automatically retrieve the relevant user transaction data to be included in the alert.

The filtering rules data store 122 may also be provided. The filtering rules data store 122 may include additional conditions necessary to generate an alert by the change alert detection service 110. A filtering rule identifies one or more conditions that must be met before an alert may be transmitted to client. Illustratively, by way of non-limiting example, a filtering rule might instruct the transaction data spend change alert system 100 to wait seven days before transmitting the alert. Such a filtering rule may serve to avoid taking action despite the occurrence of a spend change alert or an event change alert condition. For example, it may be desirable to wait before sending an alert to account for irregular but nevertheless ordinary circumstances, such as illnesses, vacations, or other brief (i.e., weeklong) breaks from normal transactional behavior.

The change alert detection service 110 may store information about the identified user in a user data sources store 118. This user data sources store 118 may be accessed by the alert configuration engine 116 to associate additional or supplemental user-specific information with the alert data the engine 116 prepares. In some embodiments, a standard data format for the alert is established, and therefore the alert configuration engine 116 is able to format the alert in the predefined, standard format.

An alert generation service 170 may generate and deliver the alert to the client or clients that subscribe to the service and are interested in the particular user. According to some embodiments, to generate the alert, an alert generator 172 may be included in the alert generation service 170. The alert generator 172 may be configured to provide the alert in a customized format for each client. For example, different clients may use different devices and systems to receive and process alerts provided by the transaction data spend change alert system 100. In such instances, the alert generator 172 may adjust, reformat, convert, or otherwise change the alert so that a client can receive the content in the client's preferred format.

Once the alert is prepared, a communication service 174 is included to communicate the generated alert to the clients. As shown in FIG. 1, the communication service 174 provides the alert to client systems 190. In some embodiments, the communication service 174 may be configured to control the timing of the alert delivery.

In some embodiments, the disclosed transaction data spend change alert system 100 generates an alert that automatically activates a user communication function in the client system 190. For example, the automatically-activated user communication function may generate and transmit a communication to one or more user systems 195 associated with a particular user. Illustratively, by way of non-limiting example, a spend change alert may be generated by the transaction data spend change alert system 100 and transmitted to a particular client system 190 to indicate that a particular user has stopped using his or her fuel credit card. The spend change alert is triggered once a period of time between timewise consecutive transactions exceeds a predetermined gap limit for this particular category of transaction, such as seven days. The client system 190 may be configured to enable the received alert to automatically activate a user communication functionality which is stored and operated on the client system 190. In response to the received spend alert, the client system 190 may generate and transmit one or more communications to one or more user systems 195 associated with the particular user. For example, a communication may be sent by email to the particular user. The email communication may include a coupon or an offer to provide an incentive for the particular user to engage in a transaction. Additionally, a communication may be sent by text (SMS) message to the particular user. In some embodiments, similarly, a print communication may be generated and sent to the particular user by regular mail or to be included in the user's next bill.

In some embodiments, the communication transmitted to the particular user (e.g., a mobile device of the particular user) is automatically transmitted from the client system 190 at the time that the client system 190 receives the alert, or at some determined time after receiving the alert. When received by the user's device, the user communication can cause the user's device to display the communication via the activation of an application on the device (e.g., a browser, a mobile application, etc.). For example, receipt of the user communication may automatically activate an application on the device, such as a messaging application (e.g., SMS or MMS messaging application), a standalone application, or a browser, and display information included in the user communication. If the device is offline when the user communication is transmitted, the application may be automatically activated when the device is online such that the user communication is displayed. The user communication may include a URL of a webpage (or other online information) associated with the user communication, such that when the device (e.g., a mobile device) receives the user communication, a browser (or other application) is automatically activated, and the URL included in the user communication is accessed via the Internet.

In some embodiments, the transaction data spend change alert system 100 may detect downward changes in the volume and/or frequency of a user's transactions, and provide alerts of such changes to merchants or other interested parties. For example, an alert may indicate that a user has failed to engage in a transaction within a predicted time period, thereby indicating a change in the user's transactional behavior. The transaction data spend change alert system 100 analyzes a user's historical transaction data to create one or more user transaction frequency distribution models which may be used to make predictions about the user's future spending habits.

An alert performance service 180 includes a treatment database 182 that receives input from client system 190, and an alert database 184 that receives input from the alert generator 172. The alert performance service 180 also receives categorized transaction data from the categorized transaction data store 138. The alert performance service 180 may be implemented using a hardware processor specially programmed with executable instructions to determine one or more gap limits for particular users. The alert performance service 180 analyzes the user's historical transactional behavior and, based on the analysis, determines one or more gap limits for that particular user which are communicated to the alert condition detector 112. The alert performance service 180 may also determine filtering rules for a particular user and/or client, which may be communicated to the filtering rules data store 122 for implementation by the filter condition detector 114.

FIG. 2 shows, by way of illustrative example, three sample visualizations of spend prediction information for three different users. The three charts of FIG. 2 indicate, respectively, that 95% of the time User 1 will make a fuel transaction within 7 days; that 99% of the time User 2 will make a grocery transaction within 25 days; and 99% of the time User 3 will make a restaurant transaction within 30 days.

The user's transaction data may be analyzed based on the frequency by which the user transacts in a particular segment or category. The time between transactions provides insight into the user's spending behavior. Accordingly, analysis of the data relative to the time between adjacent (i.e., consecutive) transactions may be analyzed to indicate a frequency of occurrence. For example, the graph on the left in FIG. 2 relates the percentage of historical fuel transactions to the time between adjacent transactions. Thus, the user made adjacent fuel transactions: one day apart approximately 2% of the time, two days apart approximately 6% of the time, three days apart approximately 15% of the time, and so on. Each bar on the graph represents a percentage of the user's historical fuel transactions for which adjacent transactions were separated by a particular number of days. Necessarily, the sum of all of the bars equals 100%. Thus, according to the frequency distribution model, as indicated in FIG. 2, there is a 95% likelihood that User 1 will engage in a fuel transaction within seven days from User 1's most recent fuel transaction. Similarly, there is a 99% likelihood that the User 2 will engage in a grocery transaction within twenty-five days of User 2's most recent grocery transaction, and there is a 99% likelihood that User 3 will engage in a restaurant transaction within thirty days of User 3's most recent restaurant transaction. In other embodiments, predicted spending may be analyzed and visualized in any other manner.

In accordance with certain embodiments of the present disclosure, an initial transaction frequency distribution model may be constructed by creating a histogram that identifies the percentage of historical transactions corresponding to specific time periods between each transaction. Illustratively, the time period may be days, weeks, months, hours or minutes, depending on what time period is most relevant to the set of transactions being analyzed.

In one embodiment, a transaction frequency distribution model describing how a user transacted historically is constructed. Future transactions—or a lack of future transactions within a predetermined period of time—can trigger a process to update the transaction frequency distribution model. If a predetermined gap limit (i.e., a maximum expected time between transactions) is exceeded, an alert may be generated. Notably, each new transaction by a given user presents a need to update the existing one or more transaction frequency distribution models for that user. Thus, the disclosed transaction data spend change alert system 100 is regularly updated to provide current transactional information. The transaction frequency distribution models can be calculated for the overall volume of transactions of a user as well as for categories or sub-categories of transactions that a client might wish to monitor. Alerts may be transmitted to the interested entities (i.e., clients that subscribe to the services provided by the transaction data spend change alert system 100) when deemed appropriate. In one embodiment, the output of this solution is zero or more alerts for each user for which a significant change in spending has occurred in the user's transactional behavior. Additional information about the user, for example attributes describing the user's recent behavior or characteristics of the transaction distribution, can also be included in the output to assist interested parties in acting on the information provided.

Example Method

FIG. 3 is a flowchart illustrating an example process of detecting spending patterns of a user and generating an alert based on those patterns. The top graphs in FIG. 3 illustrate the transaction history of a user over time in which the abscissa (x-axis) corresponds to the date and time of the transaction (typically spanning a multi-year timeframe), and the ordinate (y-axis) reflects dollar amounts of transactions. The data points on the graphs indicate transactions made by the user at a particular date and time. The bottom graphs are transaction frequency distribution models for the user at three different points in time.

At label 1, an initial transaction frequency distribution model based at least partially on the historical transactional behavior of a user is constructed. In the illustrated example, only one transaction by the user has been recorded. Thus, the initial transaction distribution model for the user may be based on the transaction data of a population that is representative of the user. Times between transactions (i.e., gaps) are identified and organized, as illustrated by the bottom graph at label 1. Based on the initial transaction frequency distribution model, a gap limit that indicates an expected period of time between transactions can be determined. For example, the gap limit may be selected to have a ninety-five percent (95%) likelihood that the user will make a transaction within an expected time period, based on the transaction frequency distribution model. In this example, a gap limit of twenty-eight (28) days is set as illustrated by the vertical line in the bottom graph at label 1.

The transaction frequency distribution model enables the transaction data spend change alert system 100 to calculate probabilities that the user will engage in a transaction within a specified period of time, such as within a day, a week, or a month, and the like. At label 2, new transactions by the user are identified, and the transaction frequency distribution model is updated to reflect the new information. Additionally, new probabilities that the user will engage in a transaction within a specified period of time are calculated based on the updated transaction frequency distribution model. In this example, a new gap limit is set to twenty (20) days, corresponding to the expected period of time between transactions by the user.

At label 3, a period in excess of the previously-calculated gap limit of twenty (20) days has transpired since the most recent user transaction, as indicated by the vertical line in the top graph at label 3. This triggers a spend change alert condition (also referred to herein as an event change alert condition), indicating that the user has potentially reduced his or her spending behavior. Under such a circumstance, the process may transmit a spend change alert (also referred to herein as an event change alert) to one or more interested parties to inform the interested parties of the user's change in spending behavior. In light of the detected change in the user's transactional behavior, the gap limit is updated to reflect a new expectation. As illustrated in the bottom graph at label 3, the new gap limit is set to thirty-seven (37) days.

FIG. 4 is a process flow diagram of an example method of generating and updating a transaction frequency distribution model. At block 402 the process 400 accesses transaction records for a set of users. As describe above, the transaction records may be aggregated from multiple sources including credit bureau repositories 102, financial institutions 104, credit/debit card readers 106, and other sources 108 that engage with users in transactions.

At block 404, the process 400 categorizes each transaction record based on one or more transaction attributes. The category (or categories) assigned to a particular transaction record may be determined based on specific transaction attributes such as, by way of non-limiting example, an item name, a merchant name, a merchant code, a merchant category code (e.g., clothing, auto, coffee, etc.), and the like.

At Block 406, the process 400 generates, based on the transaction records of multiple users, a baseline probability distribution model (Baseline Distribution). The Baseline Distribution is developed by determining each time between transactions for each pair of adjacent (i.e., consecutive) transactions of each user. The Baseline Distribution describes the overall probability of a generic user having a transaction within in a given time period. The Baseline Distribution represents a transaction frequency distribution model of a population. Such a model may be particularly useful when the population data is selected based on one or more attributes, such as age, gender, category, and the like.

Each individual user may be represented by the list of transactions that were initiated by that user during the specified time period. Each transaction will have a date and time associated with it. Each user's initial transaction frequency distribution model is set to the Baseline Distribution. At block 408, user-specific transactions over a certain period of time are accessed. Each transaction for that user is processed in the order that it occurred. Such processing may include normalizing the user's transaction. At block 410, the Baseline Distribution is updated to the user's transaction data reflecting the difference in time between the user's prior transaction and most recent transaction. At block 412, the process 400 checks to determine whether another user transaction has occurred. If so, the process 400 returns to block 410. After processing each user transaction, the Baseline Distribution has been transformed by user transaction data to the user's transaction frequency distribution model, reflecting the user's specific transaction activity. This version of the user's transaction frequency distribution model may be referred to as the user's “Initial Distribution.” Next, the process 400 advances to block 414, where the user-specific transaction frequency distribution model is output and stored.

According to certain embodiments of the present disclosure, each user's transaction frequency distribution model may be developed based only on the individual user's transaction data. The user transaction frequency distribution model may be developed analytically. In particular, each pair of timewise adjacent transactions (i.e., two consecutive transactions in time) is analyzed statistically to determine the time between the two transactions of the pair. Illustratively, each transaction for a particular user is processed relative to the preceding transaction. The results are binned (i.e., grouped together) into relevant time periods, such as, by way of non-limiting example, days or weeks. Once constructed, the transaction frequency distribution model describes the overall probability of a user engaging in a transaction within a given time period, based on the user's historical transactional behavior. Once historical transactions have been processed to the present time, each user's frequency of transaction is represented by the user's transaction frequency distribution model up to that point in time.

The transaction frequency distribution model has a point referred to as a “gap limit” which represents the maximum desired length of time before an alert will be transmitted. The gap limit is based on the user's transaction history and may be set by the client interested in receiving spend change alerts. The gap limit may be different for different clients. Illustratively, a gap limit may be defined as the period of time by which the user is expected to make a next transaction within a specified probability of certainty. For example, a gap limit may be set to the period of time by which the user will engage in a next transaction with a ninety-five percent (95%) probability of occurrence. The gap limit may be used as a spend change alert triggering mechanism. For example, when a user does not make a transaction within the time period defined by the gap limit, an alert may be sent to the client indicating that the user has changed his or her spending behavior.

The transaction data spend change alert system 100 may create, update, and store multiple transaction frequency distribution models for a single user. For example, a client that subscribes to the service offered by the transaction data spend change alert system 100 may be interested in a user's overall transactional behavior as well as the user's transactional behavior with respect to specific categories and/or sub-categories. In such circumstances, the transaction data spend change alert system 100 will generate multiple transaction frequency distribution models for the user.

FIGS. 5A and 5B depict a process flow diagram of another example process 500 of updating a transactional frequency distribution model as well as generating and transmitting a spend change alert based on a change in the user's transactional behavior. Illustratively, after a designated period of time (for example one day) the disclosed process 500 processes transactions that have occurred between the last time this action was performed and the present. If a user has not had any new transactions, the distribution associated with that user is analyzed to determine whether the gap limit has been met. If the time between the most recent transaction and the present time (i.e., the present gap) exceeds the “gap limit,” then the system will evaluate whether an alert will be transmitted to one or more clients. This process is repeated for as long as it is desirable to monitor that user. The user's transaction frequency distribution model may then be replaced by the updated distribution model which may be used the next time the analysis is performed.

At block 502, the process 500 accesses a transaction frequency distribution model for a particular user. The accessed transaction frequency distribution model may have been created in the manner or manners described above.

At block 504, the process 500 determines whether the user has engaged in a new transaction since the last time the process 500 checked for an update. If a new transaction has taken place, then the process 500 advances to block 530, which is described in further detail below with respect to FIG. 5B. If the user has not engaged in a new transaction since the last time that the process 500 checked for an update, then the process 500 advances to block 506.

At block 506, the process 500 determines whether the time period (i.e., gap) since the user's most recent transaction is greater than a predetermined threshold time period for alert generation (i.e., gap limit). As discussed above, the gap limit may be set by a client to define the conditions by which the client desires to be informed of a change in the user's transactional behavior. The gap limit is flexible and can be determined by examining the user's historical behavior as performed by the alert performance service 180. The gap limit can be set at any value or values that meet the client's needs. In some embodiments, the gap limit may be set to a particular probability value, such as for example, the time period associated with a ninety-five percent (95%) likelihood that the user will make a transaction, as determined by the user's transaction frequency distribution model. Illustratively, the time period associated with a ninety-five percent (95%) likelihood that the user will make a transaction may change as the user's transaction frequency distribution model is updated with additional transaction data. Thus, by selecting a probability value (as opposed to a particular time duration) the transaction data spend change alert system 100 advantageously relates the user's historical transactional behavior to the alert condition. If the process 500 determines that the gap since the user's most recent transaction is not greater than the gap limit, then no action is taken. The process 500 advances to block 508, where the process 500 waits for the next update period. If the process 500 determines that the gap since the user's most recent transaction is greater than the gap limit, then the process 500 advances to block 510.

At block 510, the process 500 generates a spend change alert based on the time period since the user's most recent transaction and the present time. Generated alerts may be applied either to known transactions or alternatively and additionally to specific subsets of transactions which are of interest. For example, for credit card transactions, one could apply the above-described methodology to overall transactions as well as to sub-categories of transactions, such as automobile fuel or restaurant transactions. Illustratively, a spend change alert may include an alert category (e.g., overall, eat, fuel, grocery, etc.), the number of days since the last transaction, and the number of transactions within the previous two months. At block 512, the process 500 determines whether the gap is greater than a category gap limit for a particular category of interest to the client. The category gap limit may be based on a different value that is more relevant to a transaction cycle of that category. For example, transactions related to hair grooming services may be likely to occur on a weekly, every-two-week, or monthly cycle, whereas transactions related to coffee boutique services may be likely to occur on a daily cycle. If the process 500 determines that the gap since the user's most recent transaction is not greater than the category gap limit, then the process 500 advances to block 508 and waits for the next update period. If the process 500 determines that the gap since the user's most recent transaction is greater than the category gap limit, then the process 500 advances to block 514.

In addition to simply using the transaction frequency distribution model to trigger alerts, the process 500 can also optionally add filters to increase or decrease the sensitivity of the alerts. Illustratively, by way of non-limiting example, filters having rules such as “do not alert prior to at least a one week gap between transactions,” or “wait a specified number of days after exceeding the gap limit to transmit an alert” may be employed. Additional illustrative examples of filter rules may include “do not alert unless: a share of wallet is reduced by a specified percentage; a specified number of days have passed since the user's last transaction, the total number of transactions within a specified number of months has decreased by a specified percentage; the total dollar transaction within a specified number of months has decreased by a specified percentage, and a specified number of days since the last alert have passed. At block 514, the process 500 determines whether a filter condition that would prevent transmission of the generated spend change alert is associated with the particular user's transaction data. If such a filter condition exists, then the process 500 advances to block 508 and waits for the next update period. If the process 500 determines that such a filter condition does not exist, then it advances to block 516, where the process 500 outputs an updated transaction frequency distribution model for the particular user.

At block 518, the process 500 may generate a set of attributes or characteristics describing the user's behavior to be included in the generated alert. Such attributes or characteristics can be used by interested entities to further understand the circumstances or causes of the user's transaction velocity change. At block 520, the process transmits the generated spend change alert for the user to the client or clients that seek to be alerted.

FIG. 5B illustrates a portion of the process 500 when the process 500 has determined that the user has engaged in a new transaction since the last time the process 500 checked for an update. Illustratively, the process updates overall and category-specific transaction frequency distribution models for the user based on the new transactions. At block 532, the process 500 updates the user's transaction frequency distribution model based on the new transaction. At block 534, the updating is repeated for each new transaction since the last time the process 500 checked for an update. Once new transactions are included in the updated transaction frequency distribution model, the process 500 advances to block 536, where each new transaction is categorized for the user based on one or more transaction attributes, as discussed above. At block 538, the process 500 determines whether a new transaction matches a category-specific transaction frequency distribution model for the user. If it does, the process 500 advances to block 540 where it updates the category-specific transaction frequency distribution model based on the new transaction, and then advances to block 542. If it does not, the process 500 advances directly to block 542. At block 542, the updating is repeated for each new transaction that matches a category-specific transaction frequency distribution model for the user. At block 544, the updated transaction frequency distribution model(s) for the user are output and stored for subsequent use.

Updating the Transaction Frequency Distribution Model

FIG. 6 illustrates graphically a method of updating the transaction frequency distribution model by representing the current (new) transaction as its own probability distribution (“Transaction Distribution”). The Transaction Distribution can be represented by a distribution having a 100% probability of occurring on the particular transaction gap and zero probability everywhere else. Alternatively the current transaction can be represented as a distribution centered on the actual gap but with a non-zero probability elsewhere, as depicted in FIG. 6. The weighted sum of the prior distribution and the current transaction distribution may then be calculated according to preset parameters such as:
Updated Transaction Frequency Distribution Model=α*(Prior Distribution Model)+(1−α)*(Transaction Distribution),
where, α is a weighting factor. In an embodiment, α is chosen to be a number close to 1, such as by way of non-limiting example, 0.95, to minimize the sensitivity to a single transaction. Advantageously, this updating process can be used to give greater weight to more recent transactions by the user which are likely to more accurately reflect the frequency of the user's transaction behavior at the present time. The distribution can be normalized so that the sum of all probabilities continues to equal one. The result may be used to replace the user's prior transaction frequency distribution model. Illustratively, by way of non-limiting example, for a user with twenty (20) past transactions, the nineteen (19) gaps between those transactions can be expressed as g₁, g₂, g₃, . . . g₁₉. The relative contributions of g₁ to g₁₉ in the transaction frequency distribution model is α¹⁹, which is approximately 0.377 for α=0.95. Accordingly, the more recent transactions have larger weights than the older transactions in the transaction frequency distribution model.

Alerts

FIG. 7 is a block diagram illustrating a spend change alert condition related to transactions for a particular user. The transaction data spend change alert system 100 delivers a spend change alert to a client system 190. In response to receiving the spend change alert, the client system 190 generates one or more user communications to be transmitted to the user, whose transactional behavior has changed. The user communications may be generated by the client system 190 or by a user communications generator 192. The user communications may be transmitted to one or more user systems 195, such as by way of non-limiting example, the user's computer and mobile device. The client system 190 may generate and transmit various forms of communications to the user, such as coupons or notifications providing incentives for the user to engage in transactions. Illustratively, by way of non-limiting example, the user communications can present coupons, offers for discounts, advertisements for specific products or services, and the like. The user communications can relate to products and services in which the user is expected to transact, such as, for example, restaurants, fuel, grocery shopping, and the like to stimulate transactions by the user. FIG. 7 illustrates non-limiting examples of such potential forms of user communications directed to various user systems 195 that include transmission of email messages directed to the user's e-mail account(s), text messages (e.g., SMS or MMS) directed to the user's mobile device, and printed messages directed by postal or other delivery services to the user's home, place of business, or other physical location.

In certain implementations, the spend change alert is operable to automatically activate a user communication service program on the client system 190. The activated user communication service program automatically generates one or more communications directed to the user about whom the spend change alert was transmitted. Generation of the user communications can be informed by the informational content of the spend change alert. The user communications are then automatically transmitted to the user in one or more modes of communication, such as, for example, electronic mail, text messaging, and regular postal mail, to name a few. In certain modes of communication to the user, the user communication may be configured to automatically operate on the user's electronic device. For example, the user's mobile device may, upon receipt of the transmitted user communication, activate a software application installed on the user's mobile device to deliver the user communication to the user. Alternatively, the user communication may activate a web browser and access a web site to present the user communication to the user. In another example, a user communication may be transmitted to a user's email account and, when received, automatically cause the user's device, such as a computer, tablet, or the like, to display the transmitted user communication. In another example, the user may receive from the client a coupon/discount offer in various manners, such as in a billing statement delivered via postal or other delivery service, in a text message to the user's mobile device, and in an email message sent to one or more of the user's email accounts. When the spend change alert is transmitted to the client in response to the user having exceeded an expected time period to engage in a transaction, such offers may be effective because they are provided at a time that the product or service may be purchased by the user.

Example Point-of-Sale Card Reader

FIG. 8 shows a schematic perspective view of an exemplary credit/debit card reader 106. As seen in FIG. 8, a point-of-sale credit/debit card reader 106 includes a housing 10. The housing 10 may enclose transaction circuitry (not shown) and other electronic components to implement one or more of the transaction data spend change alert features described.

The credit/debit card reader 106 includes a keypad 16, which interfaces with the point-of-sale transaction circuitry to provide input signals. The credit/debit card reader 106 also includes a magnetic card reader 18 and a smart card reader 20, which is adapted to receive a smart card 22.

The credit/debit card reader 106 also includes a display 24 and a printer 26 configured to provide output information prior to, during, or after a transaction. In some implementations, the display 24 may present content selected based on transaction data. The content may include single media or multimedia content. The content may be static (e.g., a movie, a text, an image, and/or audio) or dynamically generated. For example, using the transaction data, the card swiped may be identified with a data cluster for sports fans. In such an implementation, the content may be adapted to include sports-centric information such as inserting a team logo into the presented content.

FIG. 9 shows a functional block diagram of the exemplary credit/debit card reader 106, including a controller 40 which interfaces with the keypad 16, the display 24, the printer 26, and with a targeted content generator 60. A controller 40, which may include card reader and/or point-of-sale terminal functionality interfaces with the conventional magnetic card reader 18 and, when available, the smart card reader 20. The controller 40 also interfaces with a mobile computing communication device 41 and may interface with an optional modem 42. The mobile computing communication device 41 and the modem 42 may be used by the credit/debit card reader 106 to communicate messages such as between a point-of-sale system or other merchant transaction processing equipment.

The credit/debit card reader 106 shown in FIG. 9 includes a wireless modem 43 and various types of communications points such as an RF port 44, an IR port 46, a serial port 48, and a USB port 50. The communication ports may also be used by the credit/debit card reader 106 to communicate messages as described in this application. A removable media adapter 52 may also interface with the controller 40. Removable media may be employed for storage, archiving, and processing of data relevant to the credit/debit card reader 106 functionality. For example, transaction data may be stored on removable media for transfer, at a later time, to merchant transaction processing equipment.

The targeted content generator 60 may be configured to obtain content and transaction data. Using the transaction data, the targeted content generator 60 may identify one or more elements of obtained content for presentation via one or more of the outputs of the credit/debit card reader 106. For example, the display 24 may be used to show content to a user who presented a card at the credit/debit card reader 106. During the transaction, such as part of the authorization process, a transactional record for the user may be received and processed by the credit/debit card reader 106. By comparing at least a portion of the transaction data to selection criteria associated with the obtained content, the targeted content generator 60 may identify a relevant content element for presentation to the user and cause it to be presented.

Example System Implementation Architecture

FIG. 10 is a block diagram showing example components of a computing system 1000. The computing system 1000 includes, for example, a personal computer that is IBM, Macintosh, or Linux/Unix compatible or a server or workstation. In one embodiment, the computing system 1000 comprises a server, a laptop computer, a smart phone, a personal digital assistant, a kiosk, or a media player, for example. In one embodiment, the computing system 1000 includes one or more central processing unit (“CPU”) 1005, which may each include a conventional or proprietary microprocessor. The computing system 1000 further includes one or more memory 1032, such as random access memory (“RAM”) for temporary storage of information, one or more read only memory (“ROM”) for permanent storage of information, and one or more mass storage device 1022, such as a hard drive, diskette, solid state drive, or optical media storage device. Typically, the components of the computing system 1000 are connected to the computer using a standards-based bus system 1090. In different embodiments, the standards-based bus system could be implemented in Peripheral Component Interconnect (“PCI”), Microchannel, Small Computer System Interface (“SCSI”), Industrial Standard Architecture (“ISA”) and Extended ISA (“EISA”) architectures, for example. In addition, the functionality provided for in the components and modules of computing system 1000 may be combined into fewer components and modules or further separated into additional components and modules.

The computing system 1000 is generally controlled and coordinated by operating system software, such as Windows XP, Windows Vista, Windows 7, Windows 8, Windows Server, Unix, Linux, SunOS, Solaris, iOS, Blackberry OS, or other compatible operating systems. In Macintosh systems, the operating system may be any available operating system, such as MAC OS X. In other embodiments, the computing system 1000 may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, I/O services, and provide a user interface, such as a graphical user interface (“GUI”), among other things.

The computing system 1000 may include one or more commonly available input/output (I/O) devices and interfaces 1012, such as a keyboard, mouse, touchpad, and printer. In one embodiment, the I/O devices and interfaces 1012 include one or more display devices, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs, application software data, and multimedia presentations, for example. The computing system 1000 may also include one or more multimedia devices 1042, such as speakers, video cards, graphics accelerators, and microphones, for example.

In the embodiment of FIG. 10, the I/O devices and interfaces 1012 may provide a communication interface to various external devices. The computing system 1000 may be electronically coupled to one or more networks, which comprise one or more of a LAN, WAN, and/or the Internet, for example, via a wired, wireless, or combination of wired and wireless, communication link. The networks communicate with various computing devices and/or other electronic devices via wired or wireless communication links, such as the credit bureau repository 102 data sources and the financial institution 104 data sources.

In some embodiments, information may be provided to the computing system 1000 over a network from one or more data sources. The data sources may include one or more internal and/or external data sources that provide transaction data, such as credit issuers (e.g., financial institutions that issue credit cards), transaction processors (e.g., entities that process credit card swipes at points-of-sale), and/or transaction aggregators. The data sources may include internal and external data sources which store, for example, credit bureau data (for example, credit bureau data from File One℠) and/or other user data. In some embodiments, one or more of the databases or data sources may be implemented using a relational database, such as Sybase, Oracle, CodeBase and Microsoft® SQL Server as well as other types of databases such as, for example, a flat file database, an entity-relationship database, and object-oriented database, and/or a record-based database.

In general, the word “module,” as used herein, refers to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, Lua, C or C++. A software module may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that software modules may be callable from other modules or from themselves, and/or may be invoked in response to detected events or interrupts. Software modules configured for execution on computing devices may be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, or any other tangible medium. Such software code may be stored, partially or fully, on a memory device of the executing computing device, such as the computing system 1000, for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM. It will be further appreciated that hardware modules may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors. The modules described herein are preferably implemented as software modules. They may be represented in hardware or firmware. Generally, the modules described herein refer to logical modules that may be combined with other modules or divided into sub-modules despite their physical organization or storage.

Additional Embodiments

Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code modules executed by one or more computer systems or computer processors comprising computer hardware. The code modules may be stored on any type of non-transitory computer-readable medium or computer storage device, such as hard drives, solid state memory, optical disc, and/or the like. The systems and modules may also be transmitted as generated data signals (for example, as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums, and may take a variety of forms (for example, as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). The processes and algorithms may be implemented partially or wholly in application-specific circuitry. The results of the disclosed processes and process steps may be stored, persistently or otherwise, in any type of non-transitory computer storage such as, for example, volatile or non-volatile storage.

The various features and processes described above may be used independently of one another, or may be combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. In addition, certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate. For example, described blocks or states may be performed in an order other than that specifically disclosed, or multiple blocks or states may be combined in a single block or state. The example blocks or states may be performed in serial, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added to, removed from, or rearranged compared to the disclosed example embodiments.

Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

Any process descriptions, elements, or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those skilled in the art.

All of the methods and processes described above may be embodied in, and partially or fully automated via, software code modules executed by one or more general purpose computers. For example, the methods described herein may be performed by the computing system and/or any other suitable computing device. The methods may be executed on the computing devices in response to execution of software instructions or other executable code read from a tangible computer readable medium. A tangible computer readable medium is a data storage device that can store data that is readable by a computer system. Examples of computer readable mediums include read-only memory, random-access memory, other volatile or non-volatile memory devices, compact disk read-only memories (CD-ROMs), magnetic tape, flash drives, and optical data storage devices.

It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure. The foregoing description details certain embodiments. It will be appreciated that no matter how detailed the foregoing appears in text, the systems and methods can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the systems and methods should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the systems and methods with which that terminology is associated.