User behavior segmentation using latent topic detection

Description

CROSS-REFERENCE TO RELATED 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 hereby incorporated herein by reference in its entirety. Any and all priority claims identified in the Application Data Sheet, or any correction thereto, are hereby incorporated by reference under 37 C.F.R. § 1.57.

This application is also related to U.S. application Ser. No. 14/975,536 filed on the same day as the present application, entitled “ENTITY RECOMMENDATION SYSTEMS AND METHODS,” 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,440 filed on the same day as the present application, entitled “SYSTEMS AND METHODS FOR DYNAMIC REPORT GENERATION BASED ON AUTOMATIC MODELING OF COMPLEX DATA STRUCTURES,” the disclosure of which is hereby incorporated herein by reference in its entirety.

BACKGROUND

Field

The present development relates to applying topic discovery algorithms, such as a latent dirichlet allocation algorithm, to reduce the dimensionality of event data to develop segmentations based on user n behavior indicated by the event data.

Description of Related Art

With the advent of modern computing devices, the ways in which users use electronic devices to interact with various entities has dramatically increased. Each event a user performs, whether by making a small purchasing at a grocery store, logging into a web-site, checking a book out of a library, driving a car, making a phone call, or exercising at the gym, the digital foot print of the users interactions can be tracked. The quantity of event data collected for just one user can be immense. The enormity of the data may be compounded by the number of users connected and the increasing number of event types that are made possible through an increasing number of event sources and entities. To understand a particular user, one can provide large swaths of the user's event history, but there are several obstacles which make this difficult if not impossible. To ensure a full picture of the user is provided, all event data would need to be considered. As mentioned, this can include providing many megabytes, if not gigabytes of data, for one user. This may pose a problem in limited resource environments such as mobile computing or networked system. In the mobile world, mobile computing devices typically have constraints on the memory, power, and processing capabilities. To provide a lot of data to the device could drain these precious resources. In the networked systems, one concern is network utilization. Providing all of a user's event data for each event could increase the traffic flowing through the network and thus adversely impact the overall performance.

One solution could be to take a snapshot of a user's events. However, this method fails to consider longer term trends by making an arbitrary cutoff to the data. The cutoff may be based on date, event source, or other criteria to limit the event data that would be transmitted for a user. This can lead to inaccurate assumptions about the user based on the limited view of their historical events. Making sense of the collected event data and providing usable forms of the data.

Accordingly, improved systems, devices, and methods for compressing event data to reduce its dimensionality and then placing users into segments with similar behavior without losing descriptive details of the underlying set of event data set are desirable.

SUMMARY

Various systems and methods are disclosed which include features relating to artificial intelligence directed compression of user event data based on complex analysis of user event data including latent feature detection and clustering. Further features are described for reducing the size of data transmitted during event processing data flows and devices such as card readers or point of sale systems. Machine learning features for dynamically determining an optimal compression as well as identifying targeted users and providing content to the targeted users based on the compressed data are also included.

The systems, methods, and devices of the disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

In one innovative aspect, a method of artificial intelligence guided segmentation of event data is provided. The method includes accessing, from a data store, a set of event records associated with respective users of a group of users. A first set of event records is associated with a first user is stored using a first quantity of storage. The method also includes accessing an event categories data structure indicating a set of event categories and, for each event category, attribute criteria usable to identify events associated with respective event categories. For the event records, the method includes identifying one or more attributes of the event record, comparing the identified one or more attributes of the event record to the attribute criteria of respective event categories, and based on said comparing, assigning, to the event record, an event category having attribute criteria matching the identified one or more attributes of the event record. The method also includes generating, for the first user, first compressed event data using the event records associated with the first user and a latent feature identification model such as a dirichlet allocation model. The latent feature identification model takes the event records for the first user and the event categories assigned thereto as inputs. The first compressed event data associated with the first user is stored using a second quantity of storage that is less than the first quantity of storage for storing the event records of the first user. The method also includes assigning each user to one of the data clusters included in a clustering model using respective first compressed event data for the user. The method further includes generating, for the first user, second compressed event data using a comparison between the first compressed event data for the first user and an average latent feature identification value for a latent feature included in the data cluster to which the first user has been assigned. The second compressed event data associated with the first user is stored using a third quantity of storage that is less than the second quantity of storage.

In some implementations of the method, assigning a user to one of the data clusters includes identifying center points for each data cluster included in the clustering model. In such implementations, the method may also include generating an association strength for each latent feature included in the first compressed event data for the users for each data cluster. The association strength may indicate a degree of association between the first compressed event data for a user and respective data cluster center points. The method may also include identifying the one of the data clusters as having the highest association strength for the user from amongst the data clusters included in the clustering model.

In some implementations, generating the association strength for a user includes comparing a latent feature identification value included in the first compressed event record for a latent feature for the user to the center point.

Generating the second compressed event data, may in some implementations, include calculating a secondary center point for a secondary data cluster using first compressed event data for each user assigned to the secondary data cluster. In such implementations, the method may include generating a secondary association strength for each latent feature included in the first compressed event data for a user assigned to the data cluster. The secondary association strength may indicate a secondary degree of association between the first compressed event data for the user assigned to the data cluster and the secondary center point of the secondary data cluster to which the user is not assigned. The second compressed event data may include an identifier for the secondary data cluster and the generated secondary association strengths.

In some implementations, the method may include accessing content data including a content identifier and an indication of a target data cluster of the data clusters. The method may also include identifying a group of users assigned to the target data cluster and selecting a target group of users having second compressed event data including generated association strengths indicating a threshold degree of association to the center point of the target data cluster. An electronic communication may be generated to provide to the target set of user profiles, the electronic communication including content indicated by the content identifier.

In some implementations, the method may include training the latent feature identification model through probabilistic analysis of a plurality of historical event records to identify a target number of topics. The method may also include training the clustering model using a desired compression level indicating a number of data clusters for the clustering model. Training the clustering model may include generating a center point for each data cluster using topically compressed historical event data.

In another innovative aspect, a method of compressing transaction data is provided. The method includes receiving a set of transaction records each identifying a transaction by one of a group of users. The method further includes assigning a category to each of the set of transaction records. The method also includes generating first compressed transaction records using a latent feature identification model. The method includes identifying a clustering compression model for the one of the group of users. The method further includes generating second compressed transaction records using the first compressed transaction records and the clustering compression model.

In some implementations, generating a first compressed transaction record for a user includes receiving association strengths for each topic identified by the latent feature identification model for a set of transactions for the user.

Some implementations of the method may include receiving a compression configuration indicating a target number of features to identify for an end user and training a latent dirichlet allocation model to identify the target number of features using the received set of transaction records. The latent feature identification model may include the latent dirichlet allocation model trained.

Each data cluster included in the clustering compression model may be associated with at least one latent feature identifiable by the latent feature identification model. In such implementations, generating the second compressed transaction records may include assigning each user to one of the data clusters using the first compressed transaction records. Generating the second compressed transaction records may also include generating the second compressed transaction records for each user using a comparison between the first compressed transaction data for a user and the center point for the cluster to which the user is assigned.

In some implementations, generating the second compressed transaction records may include calculating a secondary center point for a secondary data cluster using first compressed transaction data for each user assigned to the secondary data cluster, and generating a secondary association strength for each latent feature included in the first compressed transaction data for a user assigned to the data cluster. The secondary association strength may indicate a secondary degree of association between the first compressed transaction data for the user assigned to the data cluster and the secondary center point of the secondary data cluster to which the user is not assigned. The second compressed transaction data may include an identifier for the secondary data cluster and the generated secondary association strengths.

In some implementations, the method includes training a clustering model using the desired compression level and at least a portion of the set of transaction records.

In some implementations, the method includes receiving, from a transaction terminal, a pending transaction record for a user included in the group of users. The pending transaction record is not included in the set of transaction records. The method may also include retrieving a second compressed transaction record for the user using an identifier of the user included in the pending transaction record. The method may further include transmitting the second compressed transaction record to the transaction terminal.

A content element may be selected for presentation to the user during or after the current transaction using the second compressed transaction record. The content element may be provided to a content delivery system configured to transmit the content element to the user.

In another innovative aspect, a transaction data compression system is provided. The system includes a data preparation module configured to access transaction data associated with a group of users. For a set of transactions in the transaction data, the data preparation module is configured to assign a transaction category based on one or more attributes of the transaction, and normalize a level of the transaction based on spend levels of individual users.

The system includes a compression module configured to generate, for each user, first compressed transaction data using the transaction categories assigned to the transaction records for a respective user and a latent feature identification model. The first compressed transaction data associated with the one of the respective users is stored using a second quantity of storage that is less than the first quantity of storage. The compression module is further configured to identify a clustering compression model for users included in the plurality of users. The compression module may be further configured to assign each of the users to one of a set of data clusters included in the respective clustering compression model using respective first compressed transaction data for the user, and generate, for each user, second compressed transaction data using a comparison between the first compressed transaction data for a user and an average for the data cluster to which the user has been assigned. The second compressed transaction data may be stored using a third quantity of storage that is less than the second quantity of storage.

In some implementations, the system may include a profile targeting module. The profile targeting module may be configured to access content data including a content identifier and an indication of a target data cluster of the data clusters. The profile targeting module may be further configured to identify a group of users assigned to the target data cluster. The profile targeting module may be further configured to select a target group of users having second compressed transaction data including generated association strengths indicating a threshold degree of association to the center point of the target data cluster. The profile targeting module may also be configured to generate an electronic communication to provide to the target set of user profiles, the electronic communication including content indicated by the content identifier.

A content generation module may be included in the system. The content generation module may be configured to access the target group of users and identify a target device for a user included in the target group of users. In some implementations, the content generation module may be configured to provide the electronic communication to the target device.

A card reader may be included in some implementations of the system. The card reader may include a payment information detector configured to detect payment information for a transaction for a user. The card reader may further include a targeted content generator configured to receive compressed transaction data during the transaction for the user, and identify content stored by the card reader using a comparison between a content selection rule and the compressed transaction data, the content for presentation via the card reader. The card reader may also include a display configured to present the content to the user.

A compression model generator may be included in the system. The compression model generator may be configured to generate at least one of the latent feature identification model and a clustering model identifying the set of data clusters for the set of transaction records.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a functional block diagram of an example of a user behavior segmentation system.

FIG. 2 shows a functional block diagram of an example of a process to train a user behavior segmentation system.

FIG. 3 shows a process flow diagram of example method of transaction data compression with machine learning.

FIG. 4 shows a functional block diagram of an example of the user behavior segmentation system generating segments for users using trained models.

FIG. 5 shows a process flow diagram of an example method of reducing the dimensionality of transaction data.

FIG. 6 shows a process flow diagram of an example of a method of segmenting user by using topically compressed user records.

FIG. 7 is a plot diagram showing an example visualization of data clusters with center points.

FIG. 8 shows a process flow diagram of an example method of providing content using segmentation.

FIG. 9 shows a data flow diagram for an example dimension reduction and segmentation assignment for transaction data.

FIG. 10 shows some sample user behavior segments generated from transaction data.

FIG. 11 shows a message flow diagram of an example transaction with transaction data compression and content provided based on the compressed transaction data.

FIG. 12 shows a message flow diagram of an example batch transaction processing with transaction data compression and content provided based on the compressed transaction data.

FIG. 13 shows a schematic perspective view an example card reader.

FIG. 14 shows a functional block diagram of the card reader of FIG. 13.

FIG. 15 is a block diagram showing example components of a transaction analysis processing system.

DETAILED DESCRIPTION

Disclosed herein are system and methods of analyzing, processing, and manipulating large sets of event data of users in order to provide various visualizations, alerts, and other actionable intelligence to users, merchants, and others. The event data 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 include transaction-level debit information also, 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. For example, login in 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 several unique uses of such transaction data. In general, the features relate to compression of user transaction database on complex analysis of user transaction data including latent feature detection and clustering. Further features are described for including these features in transaction processing data flows and devices such as card readers or point of sale systems. Features for identifying targeted users and providing content to the targeted users based on the detected behavioral segmentation are also included. The identification may also be used for login authentication, fraud detection, or activity alerting. For example, the compressed user transaction data may provide a transaction “fingerprint” for a user. Using the fingerprint, a requested transaction may be analyzed to determine a likelihood that the transaction was initiated by the user. Where the transaction is a login in attempt, the authentication may include this likelihood in considering whether to authenticate the user. Where the transaction is an exchange, the authorization of the exchange may consider the likelihood in making the authorization decision.

Each of the processes described herein may be performed by a transaction analysis processing system (also referred to as simply “the system,” “the transaction analysis system,” or “the processing system” herein), such as the example transaction analysis system illustrated in FIG. 15 and discussed below. In other embodiments, other processing systems, such as systems including additional or fewer components than are illustrated in FIG. 15 may be used to 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 user computing device (e.g., mobile device) that performs other processes.

As noted above, in one embodiment the transaction analysis processing system accesses transaction data associated with a plurality of users in order to segment the users into groups. This transaction based segmentation provides advantages over other segmentation systems that make use of demographic information to find groups of “like” individuals, some of which are discussed below. Furthermore, it may be desirable to provide accurate information about a user during a transaction. Such “real-time” data allows the user to receive relevant information at a specific point in time.

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, but only 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 a 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 behavior patterns (e.g., spend patterns), data cluster affinity, or the like.

A model generally refers to a machine learning construct which may be used by the segmentation system to automatically identify the latent topics in the transaction data and to generate segments for each user based on their transaction behavior as indicated by their transaction data. A model may be trained. Training a model generally refers to an automated machine learning process to generate the model. A model may be represented as a data structure that identifies, for a given value, one or more correlated values. For example, a topic identification data structure may include data indicating, for a candidate list of transactions, one or more topics.

A topic generally refers to a theme or common behavior exhibited in transaction data. Topics can be learned by examining the transaction behavior of users we are interested in analyzing. Each topic may be defined by a subset of merchant categories or other information included in the transaction data. The topics may be learned such that they closely reproduce the observed behaviors in the transaction data set. For example, a set of transaction may be analyzed to determine what transaction aspects (e.g., transaction category, merchant, amount, location, time and/or day of the week of the transaction) are represented across a significant number of transactions. These aspects may be included as topics describing, in general terms, what the set of transactions are directed to.

A segment (also referred to herein as a “data cluster”) generally refers to a group of users where each user is associated with one or more topics within a set of topics with different weights. A segment generally indicates a collection of users with similar topic distribution in their transaction behavior. For example, a segment identifying a lifestyle of “sports fan” may include a user having transactions identified in the topics of “athletic events,” “sporting goods,” “physical fitness,” and “sports bar.”

The term machine learning generally refers to automated processes by which received data is analyzed to generate and/or update one or more models. Machine learning may include artificial intelligence such as neural networks, genetic algorithms, clustering, or the like. Machine learning may be performed using a training set of data. The training data may be used to generate the model that best characterizes a feature of interest using the training data. In some implementations, the class of features may be identified before training. In such instances, the model may be trained to provide outputs most closely resembling the target class of features. In some implementations, no prior knowledge may be available for training the data. In such instances, the model may discover new relationships for the provided training data. Such relationships may include similarities between data elements such as transactions or transaction categories as will be described in further detail below.

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, fixed field message, 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 or a UI) may refer to a web-based interface including data fields for receiving input signals or 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 Transaction Data Compression System

FIG. 1 shows a functional block diagram of an example of a user behavior segmentation system. The 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. However, as discussed above, transaction data may be received from a user's car, a gym, a library, a merchant, or other system whereby the user interacts to perform a transaction.

The transaction data may be received by a segmentation service 120. Although FIG. 1 shows a direct connection between the segmentation service 120 and the sources of transaction data, it will be understood that other intermediate systems may be used during transmission. The segmentation service 120 is responsible for reducing the dimensionality of the transaction data such that user behavior-based segmentation can be performed effectively and accurately. As discussed above, the transaction data dimension reduction may be particularly useful to allow accurate user profiling based on large volumes of transaction data. In some implementations, the large volume of transaction data may also be from disparate sources. Accordingly, the segmentation service 120 is provided to compress transaction data while retaining meaningful profiling data for each account holder.

The segmentation service 120 includes a data preparation module 130. The data preparation module is provided to ensure transaction data is uniformly organized prior to dimension reduction. A transaction data collection service 132 is included to receive the transaction data from the transaction data sources. 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 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 preparation module 130 shown in FIG. 1 includes a normalization and codification device 136 which may be implemented using a processor specially programmed with executable instructions to generate normalized and codified transaction data. The normalization process may include normalizing the format of the data such that transaction data from different sources each appear in a uniform record. For example, the system 100 may have a target record type and include one or more conversions to map a value from the raw transaction record to a field of the target record type.

The instructions may further cause the device 136 to categorize or codify the transaction data. In some implementations, the set of all users is run through one or more models, such as a latent dirichlet allocation (LDA) algorithm, which was originally designed to discover topics in text documents. In this approach each user is treated as a document, and each transaction is converted to a “word” by codification. These “words,” which are analogous to the “categories” discussed herein, may be included in the raw transaction data. In some implementations, the categories may be added to the raw transaction data by the device 136. The category or “word” assigned to a particular transaction may be determined by the device 136 using the transaction data such as an item identifier, an item name, merchant name, a merchant code, or a merchant category code or merchant location, or transaction amount, or transaction time, or combinations of the above. For example, the segmentation service 120 may be segmenting the data for identifying users to whom the system 100 will be providing 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. The categories may be provided as a configuration to the segmentation service 120 such that the same raw transaction data may be compressed in different ways. The configuration may identify the available categories and transaction data that cause the categorization device 136 to assign the associated category or word.

The normalization and codification device 136 is in data communication with a codified transaction data store 138. The codified transaction data store 138 is a specially configured transaction data storage device capable of handling large volumes of data (e.g., hundreds of millions of records). Illustratively, the system 100 may include hundreds of millions, or billions of transaction records. Advantageously, the 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 processing task. In some implementations, the codified transaction data store 138 may be commonly implemented with the raw transaction data store 134. However, in some implementations, such as when the segmentation service 120 provides segmentation data for different end uses, it may be desirable maintain separate data stores to ensure the security of the categorized or codified data for each end user.

The segmentation service 120 includes a dimension reduction module 150. The dimension reduction module 150 is in data communication with the codified transaction data store 138. The dimension reduction module 150 may be configured to generate compressed transaction records. To reduce the dimensions of the normalized transaction records, the dimension reduction module 150 may include a latent topic compression unit 152. The latent topic compression unit 152 may be configured to analyze transaction data for a group of users and identify latent features, such as topics, included in the transaction data. One example of latent topic identification may include a latent dirichlet allocation (LDA) model. The topic identification information can be a compressed representation of the normalized transaction data for a user. The topic identification information may include, for each topic modeled by the latent feature model used by the latent topic compression unit 152, an association value. The association value may indicate how closely the user is associated with each of the topics modeled. The topic identification information may be stored in a topic compressed data store 182.

The dimension reduction module 150 may include a segment generator 154. The latent topic compression unit 152 may provide the topic compressed data to the segment generator 154. In some implementations, the latent topic compression unit 152 may transmit a message including an identifier for the topic compressed data. The segment generator 154 may use the identifier to obtain the topically compressed transaction records from the topic compressed data store 182. Once obtained, the segment generator 154 may assign each user to a data cluster or segment. The assignment information may be stored in a segment assignment data store 184. Although topic compressed data store 182 and the segment assignment data store 184 are shown as separate data storage devices, it will be understood that all or some portion of these may be commonly implemented on a single data storage device.

As discussed above, the topic and/or segmentation compression may be performed using models. The models may be generated by a compression model generator 200.

Example Training Phase

To train models for transaction data compression, the transaction analysis system may collect, for each entity (e.g., individual users), transaction data over a certain period of time (for example one year). Each user may be represented by a list of all of their transactions during the designated time period and each transaction may be converted to a “word” by means of 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”

In some implementations, the set of all users is run through one or more models, such as a latent dirichlet allocation (LDA) algorithm, which was originally designed to discover topics in text documents. In this approach each user is treated as a document, and each transaction is converted to a “word” by codification. The transaction to word conversion can be based on merchant category code (MCC) or merchant name, or merchant location, or transaction amount, or transaction time, or combinations of the above. Transaction at restaurant, restaurant transaction with transaction amount larger than $100, restaurant transaction from 6 pm to 9 pm and with transaction amount larger than $100 are examples of valid conversions. Transaction codification or conversion is a crucial step in transaction data compression by using latent topic discovery algorithm such as LDA. Different codification will lead to different results and optimal codification is problem dependent. The optimal codification for fraud detection may not be optimal for extracting insights from transaction data for marketing optimization. After codification transactions are treated as words that make up the documents. Each document (a proxy for the user) may be represented by a collection of words. The words may be derived from transaction MCCs or merchant names or merchant location or transaction amount or transaction time or combination of the above for transactions performed by the user. The latent topic identification model may be configured to discover a set of statistical properties common in the dataset and creates topics which describe various archetypes of spend patterns. The number of spend patterns to be discovered can be set manually or discovered automatically. The output of this model may be a series of parameters describing the topics which may be referred to in this example as “Model A.”

In addition to creating “Model A”, each user may be assigned a likeness measure to each of the topics discovered by “Model A.” In one embodiment, this measure represents the weight of a particular topic in order to most accurately represent the user's spending behavior. The result of this step is a set of users which are each represented by a vector of the length of the number of topics which may be referred to in this example as “Vector A.”

“Vector A” can be used to assign each user to one or more segments in a variety of ways such as, for example, by assigning the user to the segment which represents the largest in the vector (e.g., strongest association) or assigning the user to all segments above a particular threshold. It is also possible to use “Vector A” as in input to additional algorithms which can be used to further classify a user. In addition, “Vector A” is itself a potential output of the system which describes the user's transactional behavior in a compressed manner.

“Vector A” may then be used as an input to a clustering algorithm, such as k-means clustering in order to produce clustering results, which will be referred to as “Model B.” In one embodiment, the clustering algorithm returns the location of the center of a preset number of clusters in the same space as “Vector A”. A segment can then be assigned to a user by measuring the distance from “Vector A” to each of the points described in “Model B.” This system may then, optionally, generate a second vector, “Vector B” which measures the distances of the given data point (user) to the center point of each cluster in the topic space. “Vector B” is of the same dimension as the number of clusters produced by “Model B” and can be used in a similar manner to “Vector A.”

FIG. 2 shows a functional block diagram of an example of a process to train a user behavior segmentation system. A set of user level normalized and codified transaction data 202 may be provided for training the models. A topic compression model generator 208 may receive the user level normalized and codified transaction data 202. The topic compression model generator 208 may then generate a topic compression model 210. The model 210 may be generated by iteratively analyzing the user level records to generate a model that accurately compresses the user data records into smaller, compressed records. For example, when generating a latent topic model, the iterations may adjust the number of topics to identify a model that meets specific criteria such as a target number of topics or a target “goodness-of-fit” measure.

In some embodiments, the topic compression model generator 208 may automatically determine an optimal number of topics to learn during the training phase. For example, the topic compression model generator 208 may divide the population into two pieces referred to as “Train and Test” groups. The topic compression model generator 208 may then execute the training algorithm described above multiple times with a variety number of topics in order to learn using the “Train” data. As a side-benefit of the training phase, a total probability of the dataset may be produced. This can be thought of as a goodness of fit measure. In general the more topics developed off of the training set the higher the total probability will be on the training data set. The “Test” data may then be run through the generated models (e.g., topic compression model). Finally, the topic compression model generator 208 may measure the total probability for the “Test” data for each model and select the model with the highest “Test” probability.

FIG. 3 shows a process flow diagram of an example method of transaction data compression with machine learning. The method 300 shown in FIG. 3 may be implemented in whole or in part by one or more of the devices described in this application such as FIG. 1 or 2. FIG. 3 summarizes some of the aspects of model generation discussed with reference to FIG. 2.

A network of card readers 302 may provide transaction data 304 for transactions processed via a reader. In this example, the transaction data may be obtained from a point of sale transaction processor, such as an entity that is the intermediary between the point-of-sale and the credit card issuer, which may be referred to herein as a transaction processor.

The transaction data 304 may include merchant name, merchant location, merchant category, transaction dollar amount, transaction date, and an indicator as to whether or not the card was present for the transaction.

At block 306, the number of dimensions of information represented by the transaction data may be reduced using latent topic detection techniques. Once the clustering is performed, at block 308, data clusters indicative of behavior segments may be generated. The clustering at block 308 may produce an interface, or underlying data for generating the interface, shown in FIG. 10.

At block 308, the transaction data may be further processed, such as by the transaction analysis system using machine learning to a large set of transaction data associated with multiple users, to determine behavior segments associated with respective users. The behavior segments may be selected based on such transaction data and/or compressed transaction data to provide a different segmentation than is possible using traditional user information alone such as demographic data of users. Depending on the embodiment, a user can be associated of more than one segment.

Returning to FIG. 2, once an optimal topic model is identified, the topic compression model generator 208 may output a topic compressed transaction data 212 including the topic compressed transaction data for each user. A clustering compression model generator 214 may also be included. The clustering compression model generator 214 may obtain the topic compressed transaction data 212 and generate a clustering compression model 216. The generation of the clustering compression model 216 may be an iterative process for generating an appropriate clustering compression model. For example, the clustering compression model generator 214 may iteratively identify center points for clusters. For each iteration, how compressed user records are assigned to clusters may be evaluated as a criteria for determining whether the model is suitable. The evaluation may include density of users within the clusters, number of clusters, center points for a cluster, average distance to a center point for each cluster, and other similar information that may be identified from the cluster and/or transaction data for users assigned to the cluster.

In one example, the clustering compression model generator 214 may compare the topically compressed user records to each other to identify clusters of compressed user records. The data clusters may be determined using an automated, machine-driven approach, without manually-driven rules. It may not be clear given the quantity of transactions and compressed transaction data records how users can be grouped to form data clusters. In one embodiment, the clustering compression model generator 214 may automatically group “like” users to indicate affinity groups. The grouping may be based on transaction data and/or topically compressed transaction data for the users. For example, data clusters may be identified using spend categories for a set of users. The clustering compression model generator 214 may process the transaction data and/or compressed transaction data to determine likely data clusters within the data set. It may be desirable to direct the comparison such that a predetermined number of clusters are identified. For example, some end users may wish to selectively provide content to ten different clusters of users. In such implementations, the identification of clusters may be guided such that the number of clusters identified matches the target number of clusters (e.g., in this example, ten clusters). In some embodiments, multiple techniques may be applied to identify clusters, such as combining traditional clustering algorithms with machine-learning based techniques, such as topic modeling.

The topic compression model 210 and the clustering compression model 216 may be provided to the compression module 150 and used to compress subsequently received transaction data as described above and in further detail below.

The models generated by the compression model generator 200 shown in FIG. 2 may be used by different end users. As such, the compression model generator 200 may receive a training configuration to generate models for specific end users. For example, the number of topics, specific topics, compression ratios, data cluster size, data cluster density, transaction categorization rules, and the like may be provided as the training configuration. In such implementations, the models generated may include an identifier indicating the end user and/or training configuration used to generate the model. This allows the compression model generator 200 to use the same structures to generate different models for compressing transaction data.

The behavior segmentation systems and methods described herein may group like sets of users into overlapping groups based on their transactional behavior. This differs from other traditional transaction based segmentation in a variety of ways. One way is that the described features may include a latent topic identification model, such as a model generated via a latent dirichlet allocation (LDA) algorithm, to uncover spending patterns among the population automatically. Unlike other methods, LDA does not require grouping merchants either manually using ad hoc rules or statistically by counting co-occurrence as in content vector approach. It operates directly on the collection of transactions over many users and allows users to belong to multiple groups. This makes particular sense when thinking about transactional behavior as each transaction may be driven by different characteristics about the user. For instance, some spend may be driven by necessity, e.g., grocery shopping, whereas other types of spend may be hobby driven, e.g., photography or entertainment.

As noted above, the behavior segments may be determined using an automated, machine-driven approach, without manually-driven rules. In one embodiment, clustering algorithms automatically group “like” individuals by their spend. In some embodiments, multiple techniques may be applied to develop more optimized data clusters, such as combining clustering algorithms with machine-learning based techniques, such as topic modeling. In some embodiments, a clustering output maps distance of users to the developed segment centers. Thus, a user may be assigned to a segment they are closest to along with distance measurements that show the user's proximity to other (possibly all) segments. This creates opportunities to consider multiple types of transaction behavior of the user in assessing how their behavior (such as spending patterns) is unique from other users in the population and target content accordingly.

In some embodiments, the segmentation methodology is data driven with a few parameters that can be tuned to produce different model outputs.

Example Computing Phase

The compression models may be used to compress transaction data. Transaction data for users may be initially prepared in the same manner as described in FIG. 1 discussed above. For example, the transaction analysis system 100 may collect (or otherwise accesses) transaction data for users over a certain period of time. The system 100 may then use “Model A” as computed during the training phase to compute the equivalent of “Vector A” for the data used in the testing phase. If there is a “Model B”, the series of parameters describing the segments may be used to generate the equivalent of “Vector B” for the data used in the computing phase.

FIG. 4 shows a functional block diagram of an example of the user behavior segmentation system generating segments for users using trained models. The compression module 150 may be similar that shown and described above, such as with reference to FIG. 1. User level normalized and codified transaction data 406 may be provided to the compression module 150. The compression module 150 shown in FIG. 4 also receives the trained compression models. As shown in FIG. 4, the compression module 150 receives a topic compression model 410 and a clustering compression model 416. The compression models may be provided to the compression module 150 such as via a message from the compression model generator 200. In some implementations, the compression module 150 may request a model from the compression model generator 200 or a data storage device configured to store models generated thereby. Such model requests may include one or more of: an end user identifier, a model identifier, a model type identifier, a security/authorization token to ensure the requesting device is authorized to access the requested model, or the like.

The latent topic compression 152 may be configured to generate topic compressed transaction data 412 using the user level normalized transaction data 406 and the topic compression model 410. The topic compressed transaction data 412 may include, for each user, an indication of how closely the transaction data for the user is associated with the topics identified by the model. As noted above, the topic compressed transaction data 412 may be stored using a quantity of storage resources that are less than the storage resources used to store the user level normalized transaction data 406.

The compression segment generator 156 included in the compression module 150 may be similarly configured to obtain the clustering compression model 416. Using the topic compressed transaction data 1012 and the clustering compression model 416, the compression segment generator 156 may generate cluster compressed transaction data 418 for the users. As noted above, the cluster compressed transaction data 418 may be stored using a quantity of storage resources that are less than the storage resources used to store the topic compressed transaction data 412.

Example Uses of Compressed Transaction Data

Returning to FIG. 1, the system 100 may also include elements configured to utilize the compressed transaction data. As shown in FIG. 1, a profile target service 110 is provided. The profile target service 110 may use the user segmentation data to identify users to target to receive specific content. The profile target service 110 may access content data including a content identifier and an indication of a target data cluster of the data clusters. The target data cluster may identify the segment to which the content is to be provided. In some implementations, the profile target service 110 may identify a plurality of users assigned to the target data cluster. The profile target service 110 may also select a target set of users including generated association strengths that indicate a threshold degree of association to the center point of the target data cluster. The profile target service 110 may then generate an electronic communication to provide to the target set of user profiles, the electronic communication including content indicated by the content identifier. In some implementations, the profile target service 110 may provide an indication of the set of users to another aspect of the system 100, such as a content generation server 170, to generate and communicate the identified content to the identified target.

In implementations where the profile target service 110 generates an electronic communication to provide to the target set of user profiles, the electronic communication may be implemented as or included within a message transmitted via a communication channel such as a wireless communication channel to a wireless device of a targeted user. The message may cause the wireless device to activate and/or initiate an application that is configured to acquire content for the user based on the segment identified for the user. In some implementations, the application may be initiated on the user device and, upon receipt of the message, the interface of the application may be adjusted using the received message. For example, a card issuer may provide an interactive application for managing a user account. As a user device operates the interactive application, a message including segmentation information may be received. This message may cause the interactive application to adjust one or more functions using the segmentation information. For example, the segmentation information may indicate the user has a disability. In such instances, a prompt may be presented via the interactive application, asking whether the user would like to switch to a high contrast mode. Content may also be selected for presentation using data provided in the message as selection criteria. Because the application may be initiated or adjusted upon receipt of the message, additional attributes may be identified at or near the same time the message is provided. These additional attributes may include location of the wireless device, power mode of the wireless device, connectivity of the wireless device (e.g., WiFi, cellular, USB tether), other applications executing on the wireless device (e.g., music, photos, movies, Internet browsing), or the like. These attributes may also be used in conjunction with the segmentation data to provide a contextually relevant interactive application adjustments and/or content to the user.

To support these features of the profile target service 110, a targeting rules data store 111 may be provided. The targeting rules data store 111 may include the targeting goals to be achieved by the profile target service 110. A targeting rule may identify an assigned segment, association strengths to the assigned segment, association strengths to a non-assigned segment, or other transaction data that can be used to determine which users should receive the content.

A segment selector 112 may be included to compare the segment assignment data with one or more targeting rule to select a portion of the users which are associated with a desired target segment. A profile selection engine 114 may then narrow the users identified by the segment selector 112 to focus on a particular set of the users to target. For example, the profile selection engine 114 may identify users having a certain distance to the center point of the assigned cluster. The distance may be a short distance, which would indicate a group of users who are strongly identified with the cluster. Such strong affinity can be useful in providing specific content of interest to those within the cluster. The distance may be larger distance, which would indicate a group of users who are identified, but not as strongly as others, with the cluster. Such loose affinity can be useful in providing specific content to increase a user's affinity with the assigned segment.

As noted above, the profile selection engine 114 may also consider relationships between the users assigned to the target cluster and another data cluster to which the users have not been assigned. Such relationships may indicate that while a user is strongly affiliated with the assigned cluster, there may be some interest in another cluster. Such relationships may indicate that a user has a very strong distaste for a very distant cluster. These valuable insights may be determined using the smaller compressed records for the users quickly and with efficient use of system resources.

Similar to the profile selection engine 114, a profile exclusion engine 116 may be included to filter out selected target users. Using targeting rules, the automatically generated target set of users can be further processed to ensure accurate and timely selection. For example, it may be desirable to exclude targeting of a user who has transaction data indicating a recent illness or death (e.g., transactions at a hospital, funeral home, or pharmacy). As another example, it may be desirable to avoid targeting of a user for an end user who is already a loyal customer of a merchant identified in a user's transaction data. For instance, a new user incentive need not be provided to a long time user of a service.

The profile target service 110 may store information for the identified target users in a selected profiles data store 118. The selected profiles data store 118 may be access by the content generation service 170 to generate and deliver the content to each of the identified target users. To generate the content, a targeted content generator 172 may be included in the content generation service 170. The targeted content generator 172 may be configured to format the targeted content element for each user. For example, different targeted users may use different devices to receive content. In such instance, the targeted content generator 172 may adjust, reformat, convert, or otherwise change the targeted content so that a registered user device for a targeted user can receive the content. The targeted content generator 172 may also dynamically adjust content to include targeted user specific information in the content such as the user's name, home town, or other user or transaction information available to the content generation service. The targeted content generator 172 may also prepare printable materials for mailing to the user.

Once the targeted content is prepared, a communication service 174 is included to communicate the generated content to the targeted users. As shown in FIG. 1, the communication service 174 provides the content to user devices 190. In some implementations, the content may be provided to a bulk printing service for physical print and mailing to the targeted users. The communication service 174 may be configured to control the timing of the content delivery. For example, the communication service 174 may transmit the content during a period of time (e.g., at night) when the network for the system 100 is experiencing slow traffic and may have available resources or when the cost of transmitting the content is lower than other times (e.g., nights and weekends). This can also help reduce the resource strain on the network in providing the transaction data targeting.

FIG. 5 shows a process flow diagram of an example method of reducing the dimensionality of transaction data. The method 500 shown in FIG. 5 may be implemented in whole or in part by one or more of the devices described in this application such as FIG. 1 or 4. The dimension reduction described in FIG. 5 may be achieved, in part, by mapping the transaction data to latent topics. The mapping via the latent topics provides a more focused representation of the transaction data over fewer dimensions.

At block 502, raw transaction data is received from a transaction data source such as a financial institution or credit data repositories. As discussed above, the data may be received in batch mode. The data may be pushed from the source to the transaction data processing system. The data may be requested by the system 100 from a source. In some implementations, some data may be pushed and some may be requested.

At block 504, raw transaction data may be categorized or codified using one or more transaction attributes. The transaction attributes that may be used to categorize transactions include merchant name, merchant category code, transaction amount, transaction channel (online versus off-line), or the like. The categorization may utilize match rules which identify transaction data attribute and values therefor that match a given category.

At block 506, the transaction data may be normalized. For example, the normalization may be performed to ensure transaction data from different sources are represented in a consistent format.

At block 508, latent topics for the codified transaction data are identified. The latent topics may be identified using latent topic detection which may include, in some implementations, an LDA model. The topics may be identified by training an LDA model using previous transaction data. For example, the training may reveal that a set of transactions are each related to a transaction topic such as traveling.

At block 510, a compressed record of the user is generated. The compressed record may be generated using the latent topics identified at block 508. To generate the compressed record, for an identified latent topic for a given user's transaction data, a value may be generated. The value may indicate how closely a specific user's transactions match an identified topic. In implementations where multiple topics are identified, values for each topic may be generated. The values may be expressed as an ordered vector of match values. Each match value may indicate how closely the user matches the associated topic. The match value may be expressed as an integer number or decimal number depending on the target compression level. For example, in some implementations, it may be desirable to provide a binary indication as to whether a topic applied to a given user. In such implementations, the values may be 1 or 0. In some implementations, it may be desirable to provide a decimal value where 0 is no match and 1 is a perfect match. The decimal values between 0 and 1 identify the degree of matching for a given value.

Having generated compressed transaction data using topics, it may be desirable perform a segmentation based on the topically compressed user records. The segmentation provides further summarization the behavior of a user. This can be useful in implementations where users with similar behavior patterns will be analyzed or provided content in similar fashions. This summary may also be useful to reduce the amount of data transmitted for a user such as in environments where resources are limited for exchanging, storing, and processing transaction data such as via mobile devices.

FIG. 6 shows a process flow diagram of an example of a method of segmenting users by using topically compressed user records. The method 600 shown in FIG. 6 may be implemented in whole or in part by one or more of the devices described in this application such as FIG. 1 or 4.

At block 602, the topically compressed user records are received. The records may be received via wired, wireless, or hybrid wired-wireless means. In some implementations, the segment generator 154 may receive the records.

At block 604, a cluster compression model for the compressed user records is received. The cluster compression model may be received along with the user records. In some implementations, the cluster compression model may be received from a model storage device such as in response to a query. The query may include information to identify the model of interest. For example, the query may indicate a target entity for which the compression is being performed, such as a bank or credit card issuing company.

At block 606, statistical information (e.g., an association strength) for each topic (e.g., latent feature) included in the compressed transaction data for the users is generated. The cluster compression model may include one or more center points for each cluster included in the model. Where the compressed transaction data is used for clustering, the center point of a cluster may identify a point within the data cluster that is most centrally located to represent an average topic match value for each topic included in the data cluster.

The statistical information generated at block 606 may indicate how well the compressed user record matches to the respective cluster. In some embodiments, a clustering output maps distance of users to the modeled segment centers. The association strength may indicate a degree of association between a topic in the topically compressed transaction data for a user and the center point of a data cluster included in the cluster compression model.

FIG. 7 is a plot diagram showing an example visualization of data clusters with center points. The diagram 700 shows compressed data for two topics. The x-axis shows the match value for topic 1 and the y-axis shown the match value for topic 2. Twenty-one compressed transaction records are shown. The process of identifying data clusters included a configuration to identify three clusters. A first cluster 702, a second cluster 704, and a third cluster 706 have been identified and are shown in the diagram 700. Each data cluster includes a center point (e.g., 708, 710, and 712). For the first cluster 702, the distances to the center point 408 are shown. These distances identify how far a given user record is from the “ideal” compressed record for the data cluster. The center point may indicate an average topic match value taken from compressed transaction records to be included in the cluster.

In FIG. 7, a distance 750 is shown between a compressed user record 720 included in the first data cluster 702 and the center point 710 of the second data cluster 704. In some implementations, it may be desirable to ensure a user record is at least a certain distance from another data cluster. Because the topics and clusters are generated through machine learning, preferences for edge records (e.g., records which may lie at the boundary of a data cluster) may be difficult to predict. Accordingly, it may be desirable to identify those records for further analysis or exclusion from, say, content delivery.

Returning to FIG. 6, the statistical information based on, for example, the distance information, indicates how well a compressed user record matches each cluster included in the model. In some embodiments, a clustering output maps distance of users to the developed segment centers expressed in the cluster compression model. Thus, at block 608, a user may be assigned to a data cluster they are closest to along with distance measurements that show the customer's proximity to other (possibly all) data cluster. The assignment may be based on the difference between topic match values for the record and the center points of the identified data clusters. Assigning users to one or more clusters creates opportunities to consider multiple types of behavior as expressed via transaction data of the user in assessing how their behavior(s) is/are unique from other users in the population. The clustering also allows targeting of products, offers, or other messaging according to the assigned cluster and/or relationship to other non-assigned clusters.

Thus, a user may be assigned to a data cluster they are closest to along with distance measurements that show the customer's proximity to other (possibly all) data cluster. This creates opportunities to consider multiple types of behavior of the user in assessing how their behavior is unique from other users in the population and target products, offers or messaging accordingly.

FIG. 8 shows a process flow diagram of an example method of providing content using segmentation. The method 800 shown in FIG. 8 may be implemented in whole or in part by one or more of the devices described in this application such as FIG. 1.

At block 802, content to provide to users associated with a predetermined cluster is received. The content may be received via wired, wireless, or hybrid wired and wireless means. The content may be received in a machine readable message. The content may include audio, video, text, graphic, olfactory, or haptic content.

At block 804, content access information for a set of users for content associated with a data cluster is received. The content access information may indicate which users within a data cluster should have access to the content. The content access information may include compression values for a given user record such as topic association strengths. For example, a content element may be accessed if, for a given data cluster, the association strength for a first topic is greater than a first threshold and the association strength for a second topic is less than a second threshold. In some implementations, the compression information for association strength with non-assigned data clusters may be specified in the content access information. The content access information may be received via wired, wireless, or hybrid wired and wireless means. The content access information may also include time information indicating when access to the content should be granted. For example, the time may be specified as a date range during which a particular video should be available for access. The content access information may be received in a machine readable message. The content access information may be received together with the content or in a separate message.

At block 806, a compressed user record for each user included in the set of users is received. The compressed user records may be received via wired, wireless, or hybrid wired and wireless means. The compressed user records may be received in a machine readable message. The compressed user records may include topically compressed transaction data and/or clustered compressed data. The compressed user records may be received from a transaction processing system.

At block 808, the compressed user records are filtered. The filtering may be applied using the content access information in comparison to the compressed user records. For example, a record may be filtered out of consideration if the compression information for the record includes an association strength with a non-assigned data cluster at or above a threshold value. Accordingly, the filtering may use statistical information for the compressed user record indicating a relative match level for another identified cluster to which the compressed user record has not been assigned.

At block 810, a subset of the filtered user records are selected as candidates to receive the content based on the statistical information for the compressed user record indicating a relative match level for the predetermined data cluster. In some implementations, it may be desirable to target only a portion of the filtered user records to receive the content. The selection may be based on a comparison of the content access information with the compressed user record. For example, a comparison of topic match level to a threshold may be performed to determine whether a user record should be included in the subset of the filtered user records.

At block 812, a content message is generated and provided to at least a portion of the candidates. The content message includes the content. The content message may include a dynamic portion of content generated based on compressed user records for each candidate. This provides a second level of tailoring and access control for the content. The content message may be provide via wired or wireless means to a device of the user. In some implementations, the content may be provided to a fulfillment device such as a bulk mail generator for printing and shipping to one or more of the candidate users. In such implementations, the content may be provided with shipping information or an identifier that can be used to obtain the shipping information for the content.

In certain implementations, one or more of the content messages are operable to automatically activate a user communication service program on the user device 190 or a client service system (not shown). The activated user communication service program automatically generates one or more communications directed to the user for whom at least one of the content messages was transmitted. Generation of the user communications can be informed by informational included in the content message. 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 device 190. For example, a 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 service system 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 a content message is transmitted to the client in response to a transaction, such offers may be effective because they are provided at or near a time that the product or service may be purchased by the user.

FIG. 9 shows a data flow diagram for an example dimension reduction and segmentation assignment for transaction data. The data flow 900 begins with an initial set of transaction data 902 for multiple users. Each transaction may be categorized or codified (e.g., clothing, auto, coffee). The initial transaction data 902 may be parsed to identify only those transactions for a specific user. A set of user transaction data 910 for a user (e.g., “Sara Smith”) is shown in FIG. 9. It will be appreciated that additional sets may be identified for other users and processed in a similar manner.

A topic identification model 914 may be used in conjunction with the set of user transaction data 910 to generate first compressed user transaction data 916. One example topic identification model 914 is a latent feature model such as an LDA model. The latent feature model may be used to discover the behavior topic and to reduce dimensionality of the transaction data. The discovery via the latent feature model is probabilistic based on identified connections between transaction data elements.

The first compressed user transaction data 916 may include a list of values indicating how closely the transaction data matches a given topic. The values are generated by the topic identification model. As shown in FIG. 9, each topic is included as a row in a vector representation of the first compressed data. It will be understood that the representation may be different (e.g., string of characters, binary encoded value, XML, or other machine readable format).

Transactional data for one user or a group of users may then be provided to a cluster identifier 920. This allows the cluster identifier to group the transaction data for the users based on the intrinsic similarities of their transaction data in the topic space.

The cluster identifier 920 may obtain a set of data clusters 930 for the transaction data 902. The set of data cluster 930 may provide as a segmentation model (e.g., “Model B”). The cluster identifier 920 may generate association strength values for transaction data for a user with one or more data clusters included in the data clusters 930. The association strength values for a given user may represent the distance of the user to a center point of a data cluster, such as the center point shown in FIG. 7. Users may be assigned to one or more clusters and a second compressed transaction data record 940 (e.g., the user segmentation) may be generated. As shown in FIG. 9, the user (e.g., “Sara Smith”) has the smallest distance to the center point of cluster 2 therefore she may be assigned to data cluster 2. The second compressed transaction data record 940 includes a row for each cluster included in the set of data clusters. The rows may include a distance value to the center point of the respective data cluster. In some implementations, the row may simply include the topic association strength values for the cluster included in the data clusters to which the user record was assigned. As shown, an indicator that the user associated with the second compressed transaction data record 940 is assigned to data cluster 2 may be included. This may further reduce the amount of data needed to represent the transactions for the user.

FIG. 10 shows some sample user behavior segments generated from transaction data. The interface 1000 includes four clusters 1002, 1004, 1006, and 1008. As shown in FIG. 10 the data clusters are presented as segments. For each cluster, topic summaries may be presented to indicate the characteristics of users assigned to the cluster. For example, for the first cluster 1002, a first indicator 1010 may be included to identify that the users assigned to the first data cluster 1002 spend 5 times more than the average user on child and infant-wear. A second indicator 1012 may be included to indicate the users assigned to the first cluster 1002 spend only 20 percent of the average on nightclubs and bars. The interface diagram may be generated using the identified data clusters and the center point information. The interface 1000 may be useful to help quickly assess the types of users present within a set of transaction data. The assessment may be for the purposes of providing content. As such, it may be desirable to provide an accurate but abbreviated view of a data cluster rather than generating specific views for each user.

Example Transaction Processing with Compression

FIG. 11 shows a message flow diagram of an example transaction with transaction data compression and content provided based on the compressed transaction data. A merchant system 1110 may include a card reader 1102 and a point of sale system 1104. The card reader 1102 may be configured to receive card or other payment information from a user. The card reader 1102 may be in data communication with the point of sale system 1104 to receive information collected by the card reader 1102 and other equipment at the merchant site such as a cash register, product scanner, receipt printer, display terminal, and the like. The merchant system 1110 may communicate with an acquisition server 1112. The acquisition server 1112 may be configured to determine, for payment tendered for a transaction, which issuer is responsible for the payment presented. In the case of credit cards, the issuer may be a card issuer 1114.

The message flow 1100 shown in FIG. 11 provides a simplified view of messages that may be exchanged between the entities shown for gathering, processing, and compressing transaction data as well as providing content based on the compressed transaction data for a user. It will be understood that additional entities may mediate one or more of the messages shown in FIG. 11.

The message flow 1100 may begin with a card swipe detection by the card reader 1102 based on a message 1120. The message 1120 may include the payment information read from the card such as from a magnetic strip, an embedded memory chip, a near-field communication element, or other information source included on the card. Via message 1122, the card information may be transmitted from the card reader 1102 to the point of sale system 1104. The point of sale system 1104 may determine that the card is a credit card and identify the acquisition server 1112 as a source for determining whether the payment is authorized.

The point of sale system 1104 may transmit a message 1124 to the acquisition server 1112 including the card information and merchant information. The merchant information may include a merchant identifier, merchant transaction information (e.g., desired payment amount), or other information available to the merchant for the transaction. The acquisition service 1112 may identify the card issuer based on the card information received and transmit a message 1126 to the card issuer 1114. The message 1126 may include the card information and merchant information received via message 1124. The message 1126 may also include information about the acquisition server 1112. The card issuer 1114 may then authorize the requested payment amount via message 1128. The authorization of payment is known in the field of payment processing. The authorization determines whether or not the requested payment for the transaction is to be honored. The card issuer 1114 also knows one of their users is at a payment terminal trying to make a purchase. This can be a desirable moment to interact with the customer to provide additional content to the customer, such as content selected by the card issuer or by the merchant. To select content however, an accurate record of the user may be needed to provide relevant content for the specific user involved in the transaction. As such, via message 1130, one or more compressed transaction records may be generated by the card issuer 1114.

It will be understood that the compression may be performed by a third-party system, such as the system 100 shown in FIG. 1. It will also be understood that transaction data may be stored, and thus compressed, by any of the entities shown in FIG. 11. For example, the acquisition server 1112 or the merchant system 1110 may store and compress transaction data. Furthermore, any of the systems or servers through which the transaction data is passed may serve as a transaction data source for the system 100 shown in FIG. 1.

Via message 1132, the authorization decision and compressed user data may be transmitted back to the merchant system 1110 via the acquisition server 1112. Because the compressed user data may be represented using a relatively small quantity of resources, this data may be easily included in the current messaging used to authorize transactions. The point of sale system 1104 may use the authorization information to determine whether or not to allow the transaction to proceed. If the authorization is negative, then the point of sale system 1104 may request alternate payment from the user. As shown in FIG. 11, the compressed user data may be transmitted to the card reader 1102 via message 1136. The merchant may desire to present content relevant to the tastes of the user. In such implementations, the card reader 1102 may be configured to select content via message 1138. The content or indicators therefor (e.g., file names, network locations, uniform resource locators, etc.) may be stored at the card reader along with selection criteria. The card reader 1102 may compare the compressed user data to the selection criteria for the content stored at the card reader 1102. For example, the compressed user data may include data cluster compressed user data indicating an association strength to a particular topic such as “business travel.” A content element discussing a business service may be relevant to business travelers. As such, this content element may have a selection criteria such that a user having an association strength to the topic of “business travel” that exceeds a threshold value is eligible to receive the content. The identified content may be provided to the card reader (e.g., a display, a printer, a speaker) via message 1140. The card reader 1102 may then render the content for presentation to the user. As noted above, the entities processing the transaction may store and/or compress the transaction data. As shown in FIG. 11, the point of sale system 1104 may store the transaction data via message 1142. The storage of the transaction data may be performed to allow the merchant to submit all transactions in batch for processing at a later time or date, such as shown in FIG. 12.

In some implementations, the user data may be transmitted via a message 1144 to a card holder device 1116. The card holder device 1116 is an electronic communication device associated with a user who has been issued a payment card or otherwise accesses the system to perform a transaction. As shown in FIG. 11, the user data may be sent from the card issuer 1114, however, it will be appreciated that the user data may be transmitted to the card holder device 1116 from any of the entities shown in FIG. 11 with access to the user data. The message 1144 may cause the card holder device 1116 to initiate an application that is configured to acquire content for the user based on the segment identified for the user. In some implementations, the application may be initiated on the card holder device 1114 and, upon receipt of the message 1144, the interface of the application may be adjusted using the received message. The application, via message 1146, may cause selection of content to provide to the user via the card holder device 1114. The selection may further consider information available to the card holder device 1114 such as location, other installed applications, other executing applications, resource availability, resource level, etc.). Once identified, the content may be provided via message 1148. As discussed above, the content may be provided via the card holder device 1114 during or proximate to the time of the transaction involving the card swipe at message 1120.

FIG. 12 shows a message flow diagram of an example batch transaction processing with transaction data compression and content provided based on the compressed transaction data. Some of the entities shown in FIG. 12 overlap with those shown in FIG. 11. Added to FIG. 12 is a card network server 1202. The card network server 1202 is an electronic device operated by the credit card network to which a given card belongs such as VISA.

The merchant system 1110 may transmit a batch of transaction data for multiple transactions with multiple users via message 1220. The batch of transaction data from a single merchant may include hundreds, thousands, or millions of individual transaction records. The merchant system 1110 may transmit the message 1220 to the acquisition server 1112 to initiate payment for the transactions. The acquisition server 1112, via message 1222, may transmit those transactions from a specific card network to the card network server 120 to request payment from the specific network. Because a single card network may have multiple card issuers (e.g., banks, credit unions, etc.), the card network server 1202 splits the batch of transactions by card issuer. The transactions for a specific issuer are transmitted via message 1224 to, as shown in FIG. 12, the card issuer 1114. The card issuer 1114 stores the transaction data. Because new information is now available, the card issuer 1114 may also initiate a recompression of the transaction data in light of the new transactions. The storage and recompression may be performed via message 1226.

The new transaction data may also indicate that the models used to compress the transaction data should be retrained. For example, if the new transactions represent a significant percentage of the overall transaction data stored by the system 100, the retraining of the models may be desirable to ensure an accurate and current view of the users. The retraining may also be needed to account for new transactions for new users who were previously not included in the training process.

Via message 1230, the card issuer 1114 may initiate a transfer of funds to settle one or more of the transactions included in the transaction data batch. As shown in FIG. 12, the card network server 1202, via message 1232, may also store and compress transaction data. The card network server 1202 may also initiate a transfer of funds to settle one or more of the transactions included in the transaction data batch via message 1234 and, ultimately, to transfer funds to the merchant system 1110 via message 1236.

The card issuer 1114 may interface with the card holder. For example, the card issuer 1114 may provide an interactive application for reporting transaction information to the card holder such as via the card holder device. Using the compressed transaction records, users may be identified to receive particular content. In some implementations, the profile target service 110 shown in FIG. 1 may perform the selection of users and/or content to be provided. Via message 1240, the selected content may be provided to the identified user. The content may be provided to the card holder device 1116 by the content generating service 170 shown in FIG. 1.

The card issuer 1114 may interface via mail such as by printing and mailing content to the card holder. In such implementations, the content included in the message 1240 may be provided to a fulfillment server responsible for printing and mailing the content to the card holder.

Example Point-of-Sale Card Reader

FIG. 13 shows a schematic perspective view of an example card reader. As seen in FIG. 13, there is provided a point-of-sale card reader 1300 including 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 compression features described.

The point-of-sale card reader 1300 includes a keypad 16, which interfaces with the point-of-sale transaction circuitry to provide input signals indicative of transaction or event events at or near the point-of-sale card reader 1300. The point-of-sale card reader 1300 also includes a magnetic card reader 18 and a smart card reader 20, which may be adapted to receive a smart card 22.

The point-of-sale card reader 1300 also includes a display 24 and a printer 26 configured to provide output information prior to, during, or after a transaction. 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 compressed 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. 14 shows a functional block diagram of the exemplary card reader of FIG. 13. A controller 40 which interfaces with the keypad 16, the display 24, the printer 26, and with a targeted content generator 60 are shown. The controller 40, which may include card reader and/or point-of-sale terminal functionality may interface with the 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 reader 1300 to communicate messages such as with a point-of-sale system or other merchant transaction processing equipment.

The card reader 900 shown in FIG. 14 includes a wireless modem 43 and various types of communications points such as an RF port 44, and IR port 46, a serial port 48, and a USB port 50. The communication ports may also be used by the reader 1300 to communicate messages as described in this application. A removable media adapter 52 may also interface with the transaction circuitry 12. Removable media may be employed for storage, archiving, and processing of data relevant to the reader 1300 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 compressed transaction data. Using the compressed 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 card reader. For example, the display 24 may be used to show content to a user who presented a card at the card reader. During the transaction, such as part of the authorization process, a compressed transactional record for the user may be received by the card reader 1300 and processed by the targeted content generator 60. By comparing at least a portion of the compressed data to selection criteria associated with the obtained content, the targeted content generator 60 may identify a relevant content element for presentation and cause it to be presented.

Example System Implementation and Architecture

FIG. 15 is a block diagram showing example components of a transaction data processing system 1500. The processing system 1500 includes, for example, a personal computer that is IBM, Macintosh, or Linux/Unix compatible or a server or workstation. In one embodiment, the processing system 1500 includes a server, a laptop computer, a smart phone, a personal digital assistant, a kiosk, or a media player, for example. In one embodiment, the processing system 1500 includes one or more central processing unit (“CPU”) 1505, which may each include a conventional or proprietary microprocessor specially configured to perform, in whole or in part, one or more of the transaction data compression features described above. The processing system 1500 further includes one or more memory 1532, 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 1522, such as a hard drive, diskette, solid state drive, or optical media storage device. A specially architected transaction data store 1508 may be provided. The transaction data store 1508 may be optimized for storing raw and/or compressed transaction data as described above. In some implementations, the transaction data store 1508 may be designed to handle large quantities of data and provide fast retrieval of the records. To facilitate efficient storage and retrieval, the transaction data store 1508 may be indexed using compressed transaction data, such as those described above.

Typically, the components of the processing system 1500 are connected using a standards-based bus system 1590. In different embodiments, the standards-based bus system 1590 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 processing system 1500 may be combined into fewer components and modules or further separated into additional components and modules.

The processing system 1500 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, Android, 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 processing system 1500 may be controlled by a proprietary operating system. The operating system is configured to 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 processing system 1500 may include one or more commonly available input/output (I/O) devices and interfaces 112, such as a keyboard, mouse, touchpad, and printer. In one embodiment, the I/O devices and interfaces 1512 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 processing system 1500 may also include one or more multimedia devices 1542, such as speakers, video cards, graphics accelerators, and microphones, for example.

In the embodiment of FIG. 15, the I/O devices and interfaces 1512 provide a communication interface to various external devices. The processing system 1500 may be electronically coupled to one or more networks, which comprise one or more of a LAN, WAN, cellular network, satellite network, 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 data source and financial information data sources.

In some embodiments, information may be provided to the processing system 1500 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 OneSM) 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 processing system 1500, 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, but 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.

In the example of FIG. 15, the modules 1510 may be configured for execution by the CPU 1505 to perform, in whole or in part, any or all of the process discussed above, such as those shown in FIGS. 3, 5, 6, 8, 9, 11, and/or 12.

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 a processing system, card reader, point of sale device, acquisition server, card issuer server, 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.