HK1170323A - Systems and methods for targeted advertisement delivery - Google Patents

Description

System and method for targeted advertisement placement

Cross reference to related applications

The present application claims priority from provisional U.S. patent application serial No.61/250,484 entitled "Systems and methods for Targeted Advertisement Delivery" filed on 9.10.2009, provisional U.S. patent application serial No.61/231,244 entitled "Systems and methods for Profile-Based Advertisement Delivery" filed on 4.8.2009, and U.S. patent application serial No.12/849,793 entitled "Systems and methods for Targeted Advertisement Delivery" filed on 3.8.2010, which are hereby incorporated by reference.

Technical Field

At least some embodiments of the invention relate to the processing of transaction data, such as a record of payments made via credit cards, debit cards, pre-paid cards, and the like, and/or providing information based on the processing of transaction data.

Background

Millions of transactions occur each day through the use of payment cards, such as credit cards, debit cards, prepaid cards, and the like. Records of corresponding transactions are recorded in a database for use in settlement and financial records (e.g., to meet government mandated requirements). Such data may be mined and analyzed for trend, statistical, and other analyses. Sometimes such data is mined for specific advertising objectives in order to provide Targeted Offers to account holders, as described in PCT publication No. wo 2008/067543a2 entitled "Techniques for Targeted Offers" published on 5.6.2008.

U.S. patent application publication No.2009/0216579 entitled "Tracking Online advertising Payment Services" published on 8/27 of 2009 discloses one such system: the payment service identifies the activities of the user using the payment card as corresponding to the offers associated with the online advertisements presented to the user.

U.S. patent No.6,298,330, entitled "Communicating with an aComputer Based on the official purification of a particulate conditioner," issued on 2.10.2001 discloses one such system: in response to receiving an identifier, such as a cookie, corresponding to the computer, targeted advertisements are placed to the computer.

U.S. patent No.7,035,855, entitled "Process and System for integrating Information from substrates for Purposes of purifying Consumer behavor", issued 25.4.2006 discloses one such System: consumer transaction information is used to predict consumer behavior.

U.S. patent No.6,505,168 entitled System and Method for gaining and Standardizing Customer Purchase Information for target marking, issued on 7.1.2003, discloses one such System: categories and subcategories are used to organize purchase information by credit card, debit card, check, and the like. Customer purchase information is used to generate customer preference information for targeted sales.

U.S. patent No.7,444,658, entitled "Method and System to performance Content Targeting," issued on 28.10.2008 discloses one such System: advertisements to be sent to the user are selected based on the user classification performed using the credit card purchase data.

U.S. patent application publication No.2005/0055275, published 10/3/2005 and entitled "System and Method for analyzing marking errors," discloses one such System: the system uses card transaction data to assess the cause and effect of advertising and marketing programs.

U.S. patent application publication No.2008/0217397, published on 11.9.2008 and entitled "Real-Time aware decisions," discloses a system for facilitating transactions with Real-Time incentive determinations for cardholders, where incentives may be provided to cardholders as credit scores on the cardholders' statements.

The details of the above-discussed patent documents are incorporated herein by reference.

Drawings

The embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.

FIG. 1 illustrates a system for providing services based on transactional data, according to one embodiment.

FIG. 2 illustrates the generation of an aggregated spending profile according to one embodiment.

FIG. 3 illustrates a method of generating an aggregated spending profile, according to one embodiment.

FIG. 4 illustrates a system for providing information based on transaction data, according to one embodiment.

FIG. 5 illustrates a transaction terminal according to one embodiment.

Figure 6 illustrates an account identification device according to one embodiment.

FIG. 7 illustrates a data processing system in accordance with one embodiment.

Fig. 8 illustrates a structure of account data for providing loyalty programs, according to one embodiment.

FIG. 9 illustrates a system for obtaining purchase details according to one embodiment.

FIG. 10 illustrates a system for providing a profile to target advertisements, according to one embodiment.

FIG. 11 illustrates a method of providing a profile for an advertisement, according to one embodiment.

Detailed Description

Introduction to the design reside in

In one embodiment, transaction data, such as records of transactions conducted through credit accounts, debit accounts, pre-deposited accounts, bank accounts, stored value accounts, and the like, is processed to provide information for various services, such as reporting, benchmarking, advertising, content or offer selection, customization, personalization, prioritization, and the like.

In one embodiment, an advertising network is provided based on a transaction processing device to present personalized or targeted advertisements/offers on behalf of advertisers. The computing device of (or associated with) the transaction processing device uses the transaction data and/or other data, such as account data, merchant data, search data, social network data, Web data, and so forth, to develop intelligent information about an individual customer, or some type of customer or group of customers. The intelligent information may be used to select, identify, generate, adjust, prioritize, and/or personalize customer-oriented advertisements/offers. In one embodiment, the transaction processing device is further automated to process advertising fees charged to the advertiser using an account of the advertiser in response to the advertising campaign.

In one embodiment, the computing device associates the transaction with an activity that occurs outside of the transaction (such as an online advertisement presented to the customer that results, at least in part, in an offline transaction). The association data may be used to indicate success of the advertisement and/or to improve intelligent information regarding how individual customers and/or various types of customers or groups of customers respond to the advertisement.

In one embodiment, the computing device associates transactions with, or provides information that facilitates, the customer's online activities (e.g., searching, Web browsing, social networking, and consuming advertisements), with other activities, such as watching television programs, and/or with events, such as meetings, announcements, natural disasters, accidents, news announcements, and the like.

In one embodiment, the correlation results are used in a predictive model to predict transaction and/or consumption patterns based on activities or events, predict activities or events based on transaction or consumption patterns, provide alerts or reports, and the like.

In one embodiment, a single entity operating the transaction processing device performs various operations in the services provided based on the transaction data. For example, in the presentation of personalized or targeted advertisements, a single entity may perform operations such as generating intelligent information, selecting relevant intelligent information for a given audience, selecting, identifying, adjusting, prioritizing, personalizing and/or generating advertisements based on the selected relevant intelligent information, facilitating placement of personalized or targeted advertisements, and the like. Alternatively, the entity operating the transaction processing device cooperates with one or more other entities to provide information to the entities to allow the entities to perform at least some operations of presenting personalized or targeted advertisements.

In one embodiment, a search engine, publisher, advertiser, advertising network, online merchant, or other entity may present personalized or targeted information or advertisements to a user or customer. The transaction processing device uses transaction data, account data, merchant data, and/or other data to develop intelligent information about individual customers and/or various types of customers or groups of customers. The intelligent information may then be used to identify, generate, select, prioritize, and/or adjust personalized or targeted advertisements for the customer.

In one embodiment, intelligent information is provided in real-time through a portal of a transaction processing facility to facilitate providing targeted advertisements to customers across multiple channels. The ability to deliver targeted ads improves ad relevance to customers and improves return on investment by allowing advertisers to reach their desired audience and allowing, for example, search engines to improve click-through rates.

In one embodiment, targeted advertisements are delivered for online presentation to customers. For example, a customer may visit a search engine, publisher, advertiser, or online merchant's website. During the visit to the website, user data is collected, such as an identifier of the customer (e.g., cookie ID, IP address, etc.). Other user data and contextual information (e.g., user behavior) may also be collected to customize the advertising offers.

In one embodiment, the user-specific profile is selected or calculated in real-time for the customer identified by the user data. The user-specific profile may describe the customer with varying levels of specificity. As discussed in more detail below, targeted advertisements may be selected, generated, customized, prioritized, and/or adjusted in real-time for online presentation to a customer based on a user-specific profile.

Further details and examples regarding providing transaction-based intelligence for targeted advertising in one embodiment are provided in the section entitled "targeted advertising".

System for controlling a power supply

FIG. 1 illustrates a system for providing services based on transactional data, according to one embodiment. In FIG. 1, the system includes a transaction terminal (105) for initiating a financial transaction for a user (101), a transaction processing device (103) to generate transaction data (109) through processing of financial transactions of the user (101) (as well as financial transactions of other users), a profile generator (121) to generate transaction profiles (127) based on the transaction data (109) to provide information/intelligence regarding user preferences and consumption patterns, an interaction point (107) to provide information and/or offers to the user (101), a user tracker (113) to generate user data (125) using the interaction point (107) to identify the user (101), a profile selector (129) to select a profile (131) specific to the user (101) identified by the user data (125), and a media controller (115) to select, at the interaction point (107), a profile selector (129), An advertisement selector (133) that identifies, generates, adjusts, prioritizes, and/or personalizes advertisements for presentation to a user (101).

In one embodiment, the system further includes a correlator (117) that correlates the user-specific advertisement data (119) with the deals generated by the user-specific advertisement data (119). The correlation results (123) may be used by the profile generator (121) to refine the transaction profile (127).

In one embodiment, the transaction profile (127) is generated from the transaction data (109) in the manner shown in fig. 2 and 3. For example, in FIG. 3, an aggregate spending profile (341) is generated by factor analysis (327) and cluster analysis (329) to aggregate (335) consumption patterns/behaviors reflected in the transaction record (301).

In one embodiment, a data repository (149) as shown in FIG. 4 is coupled with the transaction processing device (103) to store transaction data (109) and other data, such as account data (111), transaction profiles (127), and associated results (123). In fig. 4, the portal (143) is coupled to the data repository (149) to provide data or information derived from the transaction data (109) in response to a query request from a third party or as an alert or notification message.

In fig. 4, the transaction processing device (103) is coupled between an issuer processor (145) controlling a consumer account (146) and a transferee processor (147) controlling a merchant account (148). The account identification device (141) is configured to carry account information (142) identifying a consumer account (146) with an issuer processor (145) and to provide the account information (142) to a merchant's transaction terminal (105) to initiate a transaction between the user (101) and the merchant.

Fig. 5 and 6 show examples of a transaction terminal (105) and an account identification device (141). Fig. 7 illustrates an architecture of a data processing system that may be used to implement at least some of the components of the system, such as interaction points (107), transaction processing devices (103), portals (143), data repositories, account identification devices (141), transaction terminals (105), user trackers (113), profile generators (121), profile selectors (129), advertisement selectors (133), media controllers (115), and so forth, with more or fewer elements. Some embodiments use more or fewer components than those shown in fig. 1 and 4-7, as discussed further in the section entitled "variants".

In one embodiment, the transaction data (109) relates to a financial transaction processed by the transaction processing device (103); and the account data (111) relates to information about the account holder participating in the transaction. Further data, such as merchant data relating to the location, business, products, and/or services of the merchant that received payment from the account holder as a result of the purchase, may be used to generate a transaction profile (127, 341).

In one embodiment, financial transactions are conducted via an account identification device (141), such as a financial transaction card (e.g., credit card, debit card, bank card, etc.); financial transaction cards may be embodied as a variety of devices, such as plastic cards, chips, Radio Frequency Identification (RFID) devices, mobile phones, Personal Digital Assistants (PDAs), and the like; while the financial transaction card may be represented by an account identifier (e.g., account number or alias). In one embodiment, financial transactions are conducted by directly using account information (142) without physically presenting an account identification device (141).

Further features, modifications, and details are provided in various portions of this specification.

Centralized data warehouse

In one embodiment, the transaction processing device (103) maintains a centralized data repository (149) organized around the transaction data (109). For example, the centralized data repository (149) may include and/or support the determination of: spending band distributions, transaction counts and amounts, merchant categories, merchants by state, cardholder segments by speed score, and spending within merchant targets, competitive collections, and cross-sections.

In one embodiment, a centralized data repository (149) provides centralized management, but allows decentralized execution. For example, third party strategic market analysts, statisticians, sellers, promoters, business leaders, and the like, may access the centralized data warehouse (149) to analyze client and shopper data, provide subsequent analysis of client contributions, develop trend models to improve conversion of marketing campaigns, develop segmentation models for marketing, and the like. A centralized data repository (149) may be used to manage advertising campaigns and analyze response profitability.

In one embodiment, the centralized data repository (149) includes merchant data (e.g., data about sellers), customer/business data (e.g., data about buyers), and records of transactions between sellers and buyers over a period of time (301). The centralized data repository (149) may be used to support corporate sales forecasts, fraud analysis reports, sales/Customer Relationship Management (CRM) business intelligence, credit risk forecasting and analysis, advanced authorization reports, merchant benchmarking, business intelligence for small businesses, rewards, and the like.

In one embodiment, the transaction data (109) is combined with external data, such as surveys, benchmarks, search engine statistics, demographics, competitive information, email, etc., to mark key events and data values, set customer, merchant, data or event triggers, and drive new transactions and new customer contacts.

Transaction profiles

In fig. 1, a profile generator (121) generates a transaction profile (127) based on transaction Data (109), account Data (111), and/or other Data, such as Non-transaction Data, a list of items desired, information provided by merchants, address information, information from social networking websites, information from credit consulting companies, information from search engines, information about insurance claims, information from DNA databases, and other examples discussed in U.S. patent application No.12/614,603, entitled "analytical Local Non-reactive Data with reactive Data in predictive mode," filed 11/9 of 2009, which is incorporated herein by reference.

In one embodiment, the transaction profile (127) provides intelligent information about the user's (101) behavior, patterns, preferences, trends, frequency, trends, and budget while shopping. In one embodiment, the transaction profile (127) includes information about what the user (101) owns, such as points, miles, or other rewards currency, available credit, and received offers, such as coupons loaded into the user's (101) account. In one embodiment, the transaction profile (127) includes information based on past coupon/coupon rendering patterns. In one embodiment, the transaction profile (127) includes information about shopping patterns for purchases at retail stores as well as online purchases, including frequency of purchases, amount spent per purchase, distance of merchant location (retail) from account holder's address, and so forth.

In one embodiment, the transaction processing device (103) provides at least a portion of the intelligence for prioritization, generation, selection, customization, and/or adjustment of advertisements for placement within a transaction process involving the transaction processing device (103). For example, the advertisement may be presented to the customer in response to the customer making a payment through the transaction processing device (103).

Some transaction profiles (127) are specific to the user (101), or a group of users in which the user's (101) account or user (101) is a member, such as a family, a company, a neighborhood, a city, or a group identified by some characteristic related to online activity, offline shopping activity, merchant propensity, and so forth.

In one embodiment, the profile generator (121) periodically generates and updates the transaction profile (127) in a batch mode. In other embodiments, the profile generator (121) generates the transaction profile (127) in real time, or on time, in response to a request for the transaction profile (127) received in the portal (143).

In one embodiment, the transaction profile (127) includes values for a set of parameters. Calculating the values of the parameters may involve counting transactions meeting one or more criteria and/or constructing a statistically based model in which a statistical algorithm is applied to one or more of the calculated or transformed values, the statistical algorithm weighting each value to optimize its common predictability for various predetermined purposes.

Further details and examples regarding transaction profiles (127) in one embodiment are provided in the section entitled "aggregated spending profile".

Non-transaction data

In one embodiment, transaction data (109) is analyzed along with non-transaction data to generate transaction profiles (127) and/or to make predictive models.

In one embodiment, transactions are associated with non-transaction events such as news, meetings, movies, announcements, market changes, natural disasters, and the like to establish causal relationships to predict future transaction or consumption patterns. For example, the non-transactional data may include the geographic location of a news event, the date of an event from an event calendar, the name of an artist who is about to arrive at a concert, and so forth. Non-transactional data may be obtained from, for example, a newspaper, a website, a blog, a social networking site, and so forth.

In one embodiment, when causal relationships between transactional and non-transactional events are known (e.g., based on prior findings, domain knowledge, expertise), these relationships may be used in a predictive model to predict future transaction or consumption patterns based on recently occurring or real-time occurring events.

In one embodiment, the non-transaction data relates to events occurring in a geographic region local to the user (101) performing the corresponding transaction. In one embodiment, the geographic area is local to the user (101) when the distance from the user (101) to a location in the geographic area is within a convenient range for daily or regular travel, such as 20, 50, or 100 miles from the address of the user (101), or when the address of the user (101) is within the same city or zip code area. An example of the analysis of local non-Transactional Data as well as Transactional Data (109) in one embodiment is provided in U.S. patent application No.12/614,603, filed on 9.11.2009 and entitled "Analyzing local localized non-Transactional Data with Transactional Data in predictive models," which is hereby incorporated by reference herein.

In one embodiment, the non-transactional data is not limited to only local non-transactional data. For example, national non-transactional data may also be used.

In one embodiment, the transaction record (301) is analyzed in the frequency domain to identify characteristics of periodicity in the spending event. Periodic features in past transaction records (301) may be used to predict the probability of a time window in which similar transactions will occur. For example, analysis of the transaction data (109) may be used to predict when a next transaction with a periodic characteristic will occur, with which merchant, the probability of a repeat transaction with a certain dollar amount, the probability of an anomaly, the opportunity to provide an advertisement or offer such as a coupon, etc. In one embodiment, the periodic characteristic is detected by counting the number of occurrences of transaction pairs that occur within a set of predetermined time intervals and separating the transaction pairs based on the time intervals. Certain examples and techniques for predicting future transactions Based on detection of periodic features in one embodiment are provided in U.S. patent application serial No.12/773,770, filed on 4/5/2010 and entitled "Frequency-Based Transaction Prediction and processing," which is hereby incorporated by reference herein.

The techniques and details of predictive models in one embodiment are provided in U.S. patent nos. 6,119,103, 6,018,723, 6,658,393, 6,598,030, and 7,227,950, which are hereby incorporated by reference.

In one embodiment, the offer is based on the distance of the service point to the coupon recipient, such that the user (101) obtains the service in person. In one embodiment, offers are selected based on transaction history and shopping patterns in the transaction data (109) and/or distances between the user (101) and the merchant. In one embodiment, the offer is provided in response to a request from the user (101), or in response to detection of the user's (101) location. Us patent application serial No.11/767,218 entitled "Supply of Requested Based on Point-of Service to operational Distance" filed on 22.6.2007, us patent application serial No.11/755,575 entitled "Supply of Requested Based on operational Distance History" filed on 30.5.2007, us patent application serial No.11/755,575 entitled "Supply of Requested Based on operational Distance History" filed on 13.9.2007, us patent application serial No.2009/0076896 entitled "Merchant supplied to a consistent with a Predetermined Distance" filed on 13.2007, us patent application serial No.2 entitled "open Based on operational Distance" filed on 13.9.387, us patent application serial No.2009/0076925 entitled "open Based on Point-of Service Distance" filed on 13.9.3, and us patent application serial No. 64 entitled "filed Based on Point-of Service Distance" filed on 64.2 filed on 9.4.12 428,302, which are hereby incorporated by reference herein, provide examples and details of at least one embodiment.

Targeted advertising

In fig. 1, an advertisement selector (133) prioritizes, generates, selects, adjusts, and/or customizes available advertisement data (135) to provide user-specific advertisement data (119) based at least in part on a user-specific profile (131). An advertisement selector (133) generates, identifies, selects and/or prioritizes advertisement data for the user (101) using the user-specific profile (131) as a filter and/or a set of conditions. The media controller (115) delivers user-specific advertisement data (119) to the interaction points (107) for presentation to the user (101) as targeted and/or personalized advertisements.

In one embodiment, the user data (125) includes characteristics of context in the interaction point (107). As such, the use of the user-specific profile (131) selected using the user data (125) includes considering a context at the interaction point (107) when selecting the user-specific advertisement data (119).

In one embodiment, the ad selector (133) uses not only the user-specific profile (131), but also information about the context at the interaction point (107) when selecting the user-specific ad data (119). For example, in one embodiment, the user data (125) includes information about the context at the interaction point (107); and the advertisement selector (133) explicitly uses the context information when generating or selecting the user-specific advertisement data (119).

In one embodiment, the advertisement selector (133) may query for specific information about the user (101) before providing the user-specific advertisement data (119). The query may be passed to an operator of the transaction processing device (103), in particular to the transaction processing device (103) or to the profile generator (121). For example, the query from the advertisement selector (133) may be transmitted and received according to an application programming interface or other query interface of the transaction processing device (103), a profile generator (121) or portal (143) of the transaction processing device (103).

In one embodiment, the query communicated from the ad selector (133) may request intelligent information about the user (101) at any level of specificity (e.g., segment level, individual level). For example, the query may include a request for a certain field or a certain type of information in the cardholder's aggregated spending profile (341). As another example, the query may include a request for a level of spending by a user (101) in a business category for a previous period of time (e.g., six months).

In one embodiment, the advertisement selector (133) is operated by an entity separate from the entity operating the transaction processing device (103). For example, the advertisement selector (133) may be operated by a search engine, publisher, advertiser, advertising network, or online merchant. User-specific profiles (131) are provided to an advertisement selector (133) to facilitate customization of user-specific advertisement data (119).

In one embodiment, advertisements are targeted based on shopping patterns for merchant categories (e.g., as represented by Merchant Category Codes (MCCs)) that have a high associated spending propensity with other merchant categories (e.g., other MCCs). For example, in the context of a first MCC for a target audience, a profile identifying a second MCC with a high associated spending propensity with the first MCC may be used to select an advertisement for the target audience.

In one embodiment, the aggregated spending profile (341) is used to provide intelligent information about consumption patterns, preferences, and/or trends of the user (101). For example, a predictive model may be built based on the aggregated spending profile (341) to estimate the demand of the user (101). For example, the factor values (344) and/or the aggregate ID (343) in the aggregated spending profile (341) may be used to determine spending preferences for the user (101). For example, the channel distribution (345) in the aggregated spending profile (341) may be used to provide customized offers for a particular channel based on the consumption patterns of the user (101).

In one embodiment, mobile advertisements, such as offers and coupons, are generated and disseminated based on some aspects of previous purchases, such as time, location, and characteristics of the purchase, among others. In one embodiment, the magnitude of the benefit of the offer or coupon is based on the amount of the purchase or the amount spent on previous purchases and/or subsequent purchases that may be eligible to redeem the offer. Further details and examples of one embodiment are provided in provisional U.S. patent application serial No.11/960,162, entitled "Mobile coupon method and Portable conditioner Device for using Same" assigned publication No.2008/0201226, 12/19 of 2007, which is hereby incorporated herein by reference.

In one embodiment, a user (101) is provided with a conditional reward; and the transaction processing device (103) monitors transactions of the user (101) to identify a cash exchangeable reward meeting the corresponding condition. In one embodiment, the conditional reward is selected based on transaction data (109). Further details and examples of one embodiment are provided in provisional U.S. patent application serial No.11/862,487 entitled "Consumer specific conditional replies" filed on 27.9.2007, which is hereby incorporated by reference. Techniques for detecting satisfied conditions for conditional rewards may also be used to detect satisfaction of conditions specified for locating transactions generated by online activities (e.g., online advertisements, searches, etc.) to associate the transactions with the corresponding online activities.

Further details regarding Targeted offer delivery in one embodiment are provided in U.S. patent application Ser. No.12/185,332, assigned publication No.2010/0030644 and entitled "Targeted delivery by Payment Processor History of Cashless Acquired Merchant transfer on Issued ConsumerAccount", filed on 4.8.2008.

Configuration file matching

In fig. 1, a user tracker (113) acquires and generates context information about a user (101) at an interaction point (107), including user data (125) characterizing and/or identifying the user (101). A profile selector (129) selects a user-specific profile (131) from the set of transaction profiles (127) generated by the profile generator (121) based on a match of the characteristics of the transaction profiles (127) and the characteristics of the user data (125). For example, the user data (125) indicates characteristics of a group of users (101); and the profile selector (129) selects a user-specific profile (131) for a particular user or group of users that best matches the feature set specified by the user data (125).

In one embodiment, the profile selector (129) receives the transaction profile (127) in batch mode. A profile selector (129) selects a user-specific profile (131) from the batched transaction profiles (127) based on the user data (125). Alternatively, the profile generator (121) generates the transaction profile (127) in real-time; and the profile selector (129) uses the user data (125) to query the profile generator (121) to generate the user-specific profile (131) in real-time, or on-time. A profile generator (121) generates a user-specific profile (131) that best matches the user data (125).

In one embodiment, the user tracker (113) identification identifies the user (101) based on user activity on the transaction terminal (105) (e.g., a group of websites are visited, a type of web page is currently being visited, search behavior, etc.).

In one embodiment, the user data (125) includes an identifier of the user (101), such as a Globally Unique Identifier (GUID), a Personal Account Number (PAN) (e.g., a credit card number, or other card account number), or other identifier within a set of identifiers of the same type that uniquely and permanently identifies the user (101). Alternatively, the user data (125) may include other identifiers, such as an Internet Protocol (IP) address identifying the user (101) of the user (101) in a local, temporary, transient, and/or anonymous manner, a user (101) name or username, or a browser cookie ID. Some of these identifiers for the user (101) may be provided by a publisher, advertiser, advertising network, search engine, merchant, or user tracker (113). In one embodiment, such identifiers are associated with users (101) based on overlap or proximity of their usage periods to build an identification reference table.

In one embodiment, the identification reference table is used to identify account information (142) (e.g., account number (302)) based on characteristics of the user (101) captured in the user data (125), such as a browser cookie ID, an IP address, and/or a timestamp related to the use of the IP address. In one embodiment, the identification reference table is maintained by an operator of the transaction processing device (103). Alternatively, the identification reference table is maintained by an entity other than an operator of the transaction processing device (103).

In one embodiment, the user tracker (113) determines certain characteristics of the user (101) to describe the type of user or a group of users in which the user (101) is a member. The transaction profiles of the group are used as user-specific profiles (131). Examples of such features include geographic location or neighborhood, type of online activity, particular online activity, or merchant propensity. In one embodiment, groups are defined based on aggregate information (e.g., by time, or family), or segments (e.g., by cluster, trend, demographic distribution, cluster ID, and/or factor value). In one embodiment, the groups are defined in part by one or more social networks. For example, a group may be defined based on social distance from one or more users on a social networking website, interactions between users on a social networking website, and/or general data in the social networking profile of users in a social networking website.

In one embodiment, the user data (125) may match different profiles with different degrees of certainty at different granularities or resolutions (e.g., account, user, home, company, neighborhood, etc.). The profile selector (129) and/or profile generator (121) may determine or select the user-specific profile (131) with an acceptable certainty at the finest granularity or resolution. As such, the user-specific profile (131) is most specific to or closely associated with the user (101).

In one embodiment, the advertisement selector (133) uses further data in prioritizing, selecting, generating, customizing and adjusting the user-specific advertisement data (119). For example, the advertisement selector (133) may use the search data in conjunction with the user-specific profile (131) to provide offers or benefits to the user (101) at the interaction point (107). For example, the user-specific profile (131) may be used to personalize an advertisement, such as adjusting the position of the advertisement relative to other advertisements, adjusting the appearance of the advertisement, and so forth.

Browser COOKIE

In one embodiment, the user data (125) identifies the user (101) using browser cookie information. The browser cookie information is matched to the account information (142) or account number (302) to identify a user-specific profile (131), such as an aggregate spending profile (341), to present valid, timely, and relevant marketing information to the user (101) through preferred communication channels (e.g., mobile communications, Web, mail, email, POS, etc.) within a time window that may impact the spending behavior of the user (101). Based on the transactional data (109), the user-specific profile (131) may improve audience targeting for online advertisements. In this manner, customers will get better advertisements and offers presented to them; and advertisers will get better return on investment for their advertising campaigns.

In one embodiment, a browser cookie identifying online activity of the user (101), such as Web browsing, online searching, and using a social networking application, may be matched with an identifier of the user (101) in account data (111), such as an account number (302) of the user's (101) financial payment card or account information (142) of the user's (101) account identification device (141). In one embodiment, the identifier of the user (101) may be uniquely identified by matching an IP address, a timestamp, a cookie ID, and/or other user data (125) observed by the user tracker (113).

In one embodiment, a lookup table is used to map browser cookie information (e.g., IP address, timestamp, cookie ID) to account data (111) identifying the user (101) in the transaction processing device (103). The look-up table may be built by associating overlapping or common portions of user data (125) observed by different entities or different user trackers (113).

For example, in one embodiment, the first user tracker (113) observes the card number of the user (101) at a particular IP address within a time period identified by the timestamp (e.g., through an online payment process); the second user tracker (113) observes a user (101) having a cookie id at the same IP address for a time period that is close to or overlaps with the time period observed by the first user tracker (113). As such, the cookie id as observed by the second user tracker (113) may be linked to the card number of the user (101) as observed by the first user tracker (113). The first user tracker (113) may be operated by the same entity operating the transaction processing device (103) or by a different entity. Once the association between the cookie ID and the card number is established through a database or lookup table, the cookie ID may then be used to identify the user's (101) card number and account data (111).

In one embodiment, the portal (143) is configured to view the card number of the user (101) when the user (101) uses the IP address to conduct an online transaction. As such, the portal (143) may identify the consumer account (146) based on an association of the IP address used to identify the user (101) and the IP address recorded in association with the consumer account (146).

For example, in one embodiment, when a user (101) makes an online payment by submitting account information (142) to a transaction terminal (105) (e.g., an online store), the transaction processing device (103) obtains an IP address from the transaction terminal (105) through the transferor processor (147). The transaction processing device (103) stores data indicating the use of account information (142) at the IP address at the time of the transaction request. When the IP address in the query received in the portal (143) matches an IP address previously recorded by the transaction processing device (103), the portal (143) determines that the user (101) identified by the IP address in the request is the same user (101) associated with the account of the transaction initiated at the IP address. In one embodiment, there is a match when the time of the query request is within a predetermined time of the transaction request, such as a few minutes, an hour, a day, etc. In one embodiment, the query may also include a cookie ID representing the user (101). Thus, by matching the IP address, the cookie ID is permanently associated with the account information (142).

In one embodiment, the portal (143) directly obtains the IP address of the online transaction. For example, in one embodiment, the user (101) selects account information (142) for an online transaction to be protected using a password in the account data (111). When account information (142) is entered into a transaction terminal (105) (e.g., an online store or online shopping cart system), the user (101) connects to the portal (143) to verify the password (e.g., through a pop-up window, or through a Web browser that redirects the user (101)). After the password passes the authentication through the portal (143), the transaction processing device (103) accepts the transaction request. Through this verification process, the portal (143) and/or transaction processing device (103) obtains the IP address of the user (101) when the account information (142) is used.

In one embodiment, the user's (101) Web browser passes the password provided by the user directly to the portal (143) without going through the transaction terminal (105) (e.g., the merchant's server). Alternatively, the transaction terminal (105) and/or the transferee processor (147) may relay the cryptographic communication to the portal (143) or the transaction processing device (103).

In one embodiment, the portal (143) is configured to identify the consumer account (146) based on the IP address identified in the user data (125) by mapping the IP address to a street address. For example, in one embodiment, the user data (125) includes an IP address identifying the user (101); and the portal (143) may use a service that maps IP addresses to street addresses. For example, an internet service provider knows the street address of the currently specified IP address. Once the street address is identified, the portal (143) may use the account data (111) to identify a consumer account (146) having a current address at the identified street address. Once the consumer account (146) is identified, the portal (143) may provide a transaction profile (131) specific to the consumer account (146) of the user (101).

In one embodiment, the portal (143) uses a variety of methods to identify the consumer account (146) based on the user data (125). The portal (143) combines the results from the different methods to determine the most likely consumer account (146) for the user data (125).

Details regarding identification of consumer accounts (146) based on user data (125) in one embodiment are provided in U.S. patent application serial No.12/849,798, filed on 3.8.2010, which is hereby incorporated by reference.

Closing the cycle

In one embodiment, a correlator (117) is used to track consumer behavior, "off cycles," for "offline" activity that spans and is at least partially generated by online activity. In one embodiment, online activities such as searching, Web browsing, social networking, and/or consuming online advertisements are associated with respective transactions to generate associated results (123) in FIG. 1. The corresponding transaction may occur offline at a "brick and mortar" retail store, or online, but in a context outside of the online activity, such as a credit card purchase performed in a manner that is not visible to a search company that facilitates the search activity.

In one embodiment, the correlator (117) will identify the transactions resulting from the search or online advertisement. For example, in response to a query from the user tracker (113) about the user (101), the correlator (117) identifies an offline transaction performed by the user (101) and sends a correlation result (123) about the offline transaction to the user tracker (113), which allows the user tracker (113) to combine information about the offline transaction and the online activity to provide a significant marketing advantage.

For example, a marketing department may associate an advertising budget with an actual sales volume. For example, the salesperson may use the correlation results (123) to study the impact of actual sales volume for certain prioritization policies, customization schemes, and so forth. For example, the correlation results (123) may be used to adjust or prioritize the location of advertisements on websites, search engines, social networking sites, online marketplaces, and the like.

In one embodiment, the profile generator (121) uses the correlation results (123) to enhance the deal profile (127) with data indicating the conversion rate from search or advertisement to shopping deals. In one embodiment, the correlation results (123) are used to generate a predictive model to determine what the user (101) is likely to purchase when the user (101) searches using certain keywords or when presenting advertisements or offers to the user (101). In one embodiment, the portal (143) is configured to report the correlated results (123) to a partner, such as a search engine, publisher, or merchant, to allow the partner to use the correlated results (123) to measure effectiveness of advertising and/or search result customization, arrange rewards, and the like.

Illustratively, the search engine entity may display a search page with specific advertisements for flat panel televisions produced by companies A, B and C. The search engine entity may then compare the particular advertisement presented to a particular consumer with the consumer's transaction data and may determine that the consumer purchased a flat panel television produced by company B. The search engine entity may then use this information, as well as other information derived from the behavior of other consumers, to determine the effectiveness of the advertisements provided by companies A, B and C. The search engine entity may determine whether the location, appearance, or other characteristics of the advertisement result in an actual sales increase. The advertisements (e.g., location, appearance, etc.) may be adjusted to promote maximum sales.

In one embodiment, the correlator (117) matches online activity and transactions based on a match of user data (125) provided by the user tracker (113) and records of transactions, such as transaction data (109) or transaction records (301). In another embodiment, the correlator (117) matches online activities and transactions based on the redemption of benefits/offers provided in the user-specific advertising data (119).

In one embodiment, the portal (143) is configured to receive a set of conditions and an identification of the user (101), determine whether there are any transactions of the user (101) that satisfy the set of conditions, and if so, provide an indication of the transactions that satisfy the conditions and/or certain details about the transactions that would allow the requestor to associate the transactions with certain user activities (e.g., search, Web browsing, consuming advertisements, etc.).

In one embodiment, the requestor may not know the account (302) of the user (101); and the portal (143) maps the identifier provided in the request to the account (302) of the user (101) to provide the requested information. Examples of identifiers provided in the request to identify the user (101) include an identification of the iFrame of the web page visited by the user (101), a browser cookie ID, an IP address, and a date and time corresponding to the IP address usage, and so forth.

The information provided by the portal (143) may be used for pre-purchase sales activities, such as customizing content or offers, prioritizing content or offers, selecting content or offers, and so forth, based on the user's (101) consumption patterns. The content that is customized, prioritized, selected, or recommended may be search results, blog entries, items for sale, and so forth.

The information provided by the portal (143) may be used for post-purchase activities. For example, the information may be used to associate an offline purchase with an online activity. For example, the information may be used to determine purchases made in response to media events such as television programs, advertisements, news announcements, and the like.

Provisional U.S. patent application serial No.12/849,789, titled "Systems and Methods for Profile-based Adaptation Delivery" on 3.2010, provisional U.S. patent application serial No.61/231,244, titled "Systems and Methods for Online Search until official publication Tracking" on 4.2009, provisional U.S. patent application serial No.61/231,251, titled "Systems and Methods for Online Search retrieval Tracking" on 8.7.2009, provisional U.S. patent application serial No.61/232,114, titled "Closed Loop processing incorporated Data" on 7.2009, provisional U.S. patent application serial No.61/232,354, provisional U.S. patent application serial No.10, titled "Closed Loop processing binding mapping for Data" on 8.7.2009, and provisional patent application serial No. 46 61/232,742, titled "on 3.2009 patent application serial No. 468 The details of placing, online activity and offline purchase tracking, identifying user-specific profiles (131) based on user data (125), such as IP addresses, and targeted placement of advertisements/benefits/offers are incorporated herein by reference.

Matching advertisements with deals

In one embodiment, the correlator (117) is configured to receive information about user-specific advertisement data (119), monitor transaction data (109), identify transactions that may be considered results of advertisements corresponding to the user-specific advertisement data (119), and generate a correlation result (123), as shown in fig. 1.

When both the advertisement and the corresponding transaction occur during the online checkout process, the website for the online checkout process may be used to associate the transaction and the advertisement. However, advertisements and transactions may occur in separate processes and/or under the control of different entities (e.g., when shopping off-line at a retail store, while advertisements are presented outside of the retail store). In one embodiment, the correlator (117) uses a set of correlation conditions to identify transactions that can be considered the result of an advertisement.

In one embodiment, the correlator (117) identifies transactions linked or associated to user-specific advertisement data (119) based on various conditions. For example, the user-specific advertising data (119) may include coupons that provide benefits in accordance with purchases made based on the user-specific advertising data (119). The use of coupons identifies user-specific advertising data (119), thus allowing the correlator (117) to associate transactions with the user-specific advertising data (119).

In one embodiment, the user-specific advertisement data (119) is associated with an identity or characteristic of the user (101), such as a Globally Unique Identifier (GUID), a Personal Account Number (PAN), an alias, an IP address, a name or username, a geographic location or neighborhood, a home, a group of users, and/or user data (125). The correlator (117) may link or match the deal with the advertisement based on the identity or characteristics of the user (101) associated with the user-specific advertisement data (119). For example, the portal (143) may identify queries that track user data (125) of the user (101) and/or characteristics of the user-specific advertisement data (119); and the correlator (117) identifies one or more deals that match characteristics of the user data (125) and/or the user-specific advertisement data (119) to generate the correlation result (123).

In one embodiment, the correlator (117) identifies characteristics of the transaction and uses the characteristics to search for advertisements that match the transaction. Such features may include GUIDs, PANs, IP addresses, card numbers, browser cookie information, coupons, aliases, and so forth.

In fig. 1, the profile generator (121) uses the association result (123) to enhance the transaction profile (127) generated from the profile generator (121). The correlation results (123) provide details about the purchase and/or indicate the effectiveness of the user-specific advertising data (119).

In one embodiment, the association results (123) are used to indicate the effectiveness of the advertisement to the advertiser, to process incentives or rewards associated with the advertisement, to obtain at least a portion of advertising revenue based on the effectiveness of the advertisement, to improve selection of the advertisement, and so forth.

Coupon matching

In one embodiment, the correlator (117) identifies a transaction as a result of an advertisement (e.g., 119) when a benefit or offer provided in the advertisement is redeemed by the transaction processing device (103) with the purchase identified in the advertisement.

For example, in one embodiment, when an offer is extended to a user (101), information about the offer may be stored in association with the user's (101) account (e.g., as part of the account data (111)). The user (101) may access a portal (143) of the transaction processing device (103) to view the stored offers.

The offers stored in the user (101) can be redeemed by the transaction processing device (103) in various ways. For example, in one embodiment, the correlator (117) may download the offer to the transaction terminal (105) through the transaction processing device (103) when a characteristic of the transaction at the transaction terminal (105) matches a characteristic of the offer.

After the offer is downloaded to the transaction terminal (105), the transaction terminal (105) automatically applies the offer when conditions for the offer are met in one embodiment. Alternatively, the transaction terminal (105) allows the user (101) to selectively apply offers downloaded by the correlator (117) or the transaction processing device (103). In one embodiment, the correlator (117) transmits an alert signal to the user (101) in a separate interaction point (107) (e.g., a mobile phone) to alert the user (101) to redeem the offer. In one embodiment, the transaction processing device (103) applies an offer (e.g., by crediting) without downloading the offer (e.g., a coupon) to the transaction terminal (105). Examples and details of redemption of offers by credit are provided in U.S. patent application serial No.12/566,350 entitled "Real-timestateful creations and Notifications," filed 24/9/2009, which is incorporated herein by reference.

In one embodiment, the offer is captured as an image and stored in association with an account of the user (101). Alternatively, the offer is captured in a text format (e.g., a code and a set of conditions) without copying the original image of the coupon.

In one embodiment, when the coupon is redeemed, the advertisement in which the coupon is presented is associated with the transaction in which the coupon was redeemed, and/or it is determined that the advertisement in which the coupon is presented resulted in the transaction. In one embodiment, the correlator (117) identifies the advertisement that caused the purchase without identifying the particular deal corresponding to the advertisement.

Details regarding the redemption of offers by the transaction processing device (103) in one embodiment are provided in U.S. patent application serial No.12/849,801, filed on 3.8.2010, which is incorporated herein by reference.

On ATM and POS terminals

In one example, the transaction terminal (105) is an Automated Teller Machine (ATM) and is also an interaction point (107). When a user (101) approaches the ATM to conduct a transaction (e.g., cash is withdrawn via a credit or debit card), the ATM transmits account information (142) to the transaction processing device (103). The account information (142) may also be considered as user data (125) selecting a user-specific profile (131). A user-specific profile (131) may be sent to an advertising network to query for targeted advertisements. After the advertising network matches the user-specific profile (131) with user-specific advertising data (119) (e.g., targeted advertisements), the transaction processing device (103) may send the advertisements to the ATM along with authorization for cash withdrawal.

In one embodiment, the advertisements shown on the ATM include coupons that provide benefits to the user (101) in making purchases based on the advertisements. The user (101) may view the offers presented in the blank on the ATM screen and choose to load or store the coupons in a memory device of the transaction processing device (103) under the user's (101) account. The transaction processing device (103) communicates with the bank to process the cash withdrawal. After the cash withdrawal, the ATM prints a receipt that includes a confirmation of the coupon or copy of the coupon. The user (101) may then use the coupon printed on the receipt. Alternatively, when the user (101) uses the same account for related purchases, the transaction processing device (103) may automatically apply or download coupons stored under the user's (101) account to the related transaction terminal (105) or transmit the coupons to the user's (101) mobile phone to allow the user (101) to use the coupons through the display of the coupons on the mobile phone. The user (101) may access a Web portal (143) of the transaction processing device (103) to view the status of coupons collected in the user's (101) account.

In one embodiment, the advertisement is forwarded to the ATM for authorization via a data stream. In another embodiment, the ATM makes a separate request to a server (e.g., a Web portal) of the transaction processing device (103) to obtain the advertisement. Alternatively, or in combination, the user (101) is provided with advertisements (including coupons) at separate, different points of interaction, such as through a text message to the user's (101) mobile phone, through an email, through a bank statement, and so forth.

Details of presenting targeted advertisements on ATMs based on purchase preference and location Data in one embodiment are provided in U.S. patent application serial No.12/266,352 entitled "System incorporating automated teller Machine with Data Bearing Medium," filed on 6.11.2008, which is hereby incorporated by reference.

In another example, the transaction terminal (105) is a POS terminal (e.g., a self-checkout register) at a checkout station in a retail store. When a user (101) pays for a purchase through a payment card (e.g., credit or debit card), the transaction processing device (103) provides targeted advertisements with coupons retrieved from the advertising network. The user (101) may load the coupon into the payment card's account and/or obtain a hard copy of the coupon from the receipt. When the coupon is used for a transaction, the advertisement is linked to the transaction.

Details of presenting targeted advertisements during authorization of financial payment card transactions in one embodiment are provided in U.S. patent application serial No.11/799,549, assigned publication No.2008/0275771 and entitled "merchat Transaction Based Advertising," filed on 1/5 of 2007, which is hereby incorporated by reference.

In one embodiment, user-specific advertising data (119), such as coupons or coupons, is provided to the user (101) through the transaction terminal (105) along with an authorization message during authorization of the transaction processed by the transaction processing device (103). The authorization message may be used to communicate rewards that the user (101) is entitled to in response to the current transaction, the status and/or balance of rewards in the loyalty program, and the like. Examples and details relating to the authorization process in one embodiment are provided in U.S. patent application serial No.11/266,766, entitled Method and System for communicating functional Programs, assigned publication No.2007/0100691, on day 11/2 of 2005, which is hereby incorporated by reference.

In one embodiment, when a user (101) is performing a transaction with a first merchant through a transaction processing device (103), the transaction processing device (103) may determine whether characteristics of the transaction satisfy a condition specified for an announcement, such as an advertisement, a coupon, or a coupon, from a second merchant. If the condition is satisfied, the transaction processing device (103) provides an announcement to the user (101). In one embodiment, the transaction processing device (103) may offer an advertised opportunity to a group of merchant auctions. Examples and details of one embodiment relating to the delivery of such an announcement are provided in U.S. patent application serial No.12/428,241 entitled "Targeting merchanning advertisements gathered by Consumer Activity Relative to source Merchant", filed on 4/22 of 2009, which is hereby incorporated by reference.

Details regarding placement of advertisements at interaction points associated with user transaction interactions in one embodiment are provided in U.S. patent application serial No.12/849,791, filed on 8/3 2010, which is hereby incorporated by reference.

At third party sites

In yet another example, the user (101) may access a third party website, also in FIG. 1 an interaction point (107). The third-party website may be a Web search engine, a news website, a blog, a social networking site, and so forth. The behavior of the user (101) on the third-party website may be tracked by a browser cookie that uses the browser's storage space to store information about the user (101) at the third-party website. Alternatively, or in combination, the third-party website uses server logs to track the user's (101) activities. In one embodiment, a third-party website may allow an advertising network to present advertisements on certain portions of a web page. The advertising network uses its server log and/or browser cookies to track user behavior. For example, the advertising network may use browser cookies to identify a particular user across multiple websites. Based on referrer Uniform Resource Locators (URLs) that cause the advertising network to load advertisements in various web pages, the advertising network may determine the online behavior of the user (101) by analyzing the web pages that the user (101) has visited. Based on the tracked online activities of the user (101), user data (125) characterizing the user (101) may be formed to query the profile selector (129) to obtain a user-specific profile (131).

In one embodiment, the cookie identity of the user (101), as tracked using cookies, may be associated with an account of the user (101), a household of the user (101), a company of the user (101), or other group that includes the user (101) as a member. As such, the cookie identity may be used as user data (125) to retrieve user-specific profiles (131). For example, when a user (101) makes an online purchase from a web page containing advertisements tracked using a cookie identity, the cookie identity may be associated with an online transaction, and thus an account of the user (101). For example, when the user (101) accesses a web page after authenticating the user (101), and the web page includes advertisements from an advertising network, the cookie identity may be associated with the authenticated identity of the user (101). For example, when a user (101) logs into a Web portal to the transaction processing device (103) to access the user's (101) account, the identity of the cookie used by the advertising network on the Web portal may be associated with the user's (101) account.

Other online tracking techniques may also be used to associate the cookie identity of the user (101) with an identifier of the user (101) known to the profile selector (129), such as a GUID, PAN, account number, customer number, social security number, etc. The cookie identity may then be used to select a user-specific profile (131).

Multiple communications

In one embodiment, an entity operating the transaction processing device (103) may provide intelligence for providing multiple communications regarding advertisements. The plurality of communications may be directed to two or more interaction points interacting with the user (101).

For example, after the user (101) is provided with an advertisement through the transaction terminal (105), a reminder or modification to the advertisement may be sent to the user (101) through a separate interaction point (107), such as a mobile phone, email, text message, etc. For example, the advertisement may include a coupon that provides a purchase-specific benefit to the user (101). If the correlator (117) determines that the coupon has not been redeemed, the correlator (117) may send a message to the user's (101) mobile phone alerting the user (101) about the offer and/or modifying the offer.

An example of multiple communications related to offers in one embodiment is provided in U.S. patent application serial No.12/510,167 entitled "successful communications with an Offer Recipient" filed on 27.7.2009, which is hereby incorporated by reference herein.

Auction engine

In one embodiment, the transaction processing device (103) provides a portal to allow various clients to bid according to a cluster (e.g., according to a target entity in a cluster for marketing, monitoring, research, etc.).

For example, the cardholder may register in the program to receive offers such as promotions, discounts, winnings, reward points, direct mail coupons, email coupons, and the like. The cardholder may register with the issuer or with the portal (143) of the transaction processing device (103). Based on the transaction data (109) or transaction record (301) and/or registration data, the profile generator (121) will identify clusters of cardholders and a value representing the affinity of the cardholders to the clusters. Various entities may bid according to the clusters and/or values to gain access to a cardholder, such as the user (101). For example, an issuer may bid on accessing an offer; the transferee and/or merchant may bid on the customer segment. The auction engine receives bids and awards segments and offers based on the received bids. Thus, the customer can be extremely cheap; and the merchant may obtain customer communications and thus obtain sales.

Certain techniques for identifying segments of a user (101) for marketing are provided in U.S. patent application serial No.12/288,490 entitled "Opportunity Segmentation" of assigned publication No.2009/0222323, filed on 20.10.2008, assigned publication No.2009/0271305, filed on 23.4.2008, U.S. patent application serial No.12/108,342 entitled "patent porting Optimization", assigned publication No.2009/0271327, filed on 23.4.2008, and assigned publication No.12/108,354 entitled "patent porting Optimization", which are incorporated herein by reference.

Social network authentication

In one embodiment, the transaction data (109) is combined with social network data and/or search engine data to provide benefits (e.g., coupons) to consumers. For example, the data exchange device may identify cluster data based on consumer search engine data, social network data, and payment transaction data to identify similar groups of individuals that will respond positively to particular types of benefits, such as coupons and loyalty points. An advertising campaign may be formed to target clusters of cardholders.

In one embodiment, search engine data is combined with social network data and/or transactional data (109) to evaluate effectiveness of advertisements and/or transition patterns of advertisements. For example, after a search engine involves a consumer displaying advertisements about a flat panel television, the social network used by the consumer may provide information about related purchases made by the consumer. For example, the consumer's blog and/or transaction data (109) may indicate that the flat panel television purchased by the consumer is from company B. As such, search engine data and social network data and/or transaction data (109) may be combined to associate advertisements with purchases generated by the advertisements and to determine transition patterns for the advertisements to consumers. The advertisements may be adjusted (e.g., location, appearance, etc.) to improve the effectiveness of the advertisements, thus increasing sales.

Loyalty programme

In one embodiment, the transaction processing device (103) uses the account data (111) to store information for third party loyalty programs. A transaction processing device (103) processes payment transactions made through financial transaction cards such as credit cards, debit cards, bank cards and the like; while the financial transaction card may be used as a loyalty card for a corresponding third party loyalty program. Because the third party loyalty program owner is present on the transaction processing device (103), the consumer does not have to carry multiple separate loyalty cards (e.g., one for each merchant that provides the loyalty program); without the merchant having to spend a significant amount of setup and invest a fee to establish the loyalty program. Loyalty programs hosted on the transaction processing device (103) may provide flexible awards for consumers, retailers, manufacturer-issuers, and other types of business entities participating in loyalty programs. The loyalty program is integrated into the customer's account on the transaction processing device (103), allowing new gifts, such as cross-issuing (cross-issuing) or loyalty-issuing bundles.

In one embodiment, an entity operating the transaction processing device (103) hosts a third party's loyalty program using account data (111) of a user (e.g., 101). A third party such as a merchant, retailer, manufacturer, issuer, or other entity interested in promoting certain activities and/or activities may provide loyalty rewards on the consumer's existing account. The incentive provided by the loyalty program may drive the behavior change without the hassle of loyalty card creation. In one embodiment, a loyalty program hosted by an account of a user (e.g., 101) of a transaction processing device (103) allows a consumer to carry fewer cards and may provide more data to a merchant than a traditional loyalty program.

Loyalty programs integrated with accounts of users (e.g., 101) of transaction processing devices (103) may provide an agile plan that allows for better adjustment for driving changes in consumer behavior across transaction channels (e.g., online, offline, through mobile devices). Loyalty programs may be executing programs that accumulate benefits to customers (e.g., points, miles, cash returns), and/or programs that provide benefits in one-time or time-limited form (e.g., rewards, discounts, incentives).

Fig. 8 illustrates the structure of account data (111) for providing loyalty programs, according to one embodiment. In fig. 8, data relating to a third party loyalty program may include an identifier of a loyalty benefit provider (183) linked to a set of loyalty program rules (185) and a loyalty record (187) of the loyalty program campaign with account identifier (181). In one embodiment, at least a portion of the data relating to the third party loyalty program is stored under an account identifier (181) of the user (101), such as a loyalty record (187).

Fig. 8 shows data relating to a third party loyalty programme for a loyalty benefit provider (183). In one embodiment, the account identifier (181) may be linked to multiple loyalty benefit providers (e.g., 183) corresponding to different third party loyalty programs.

In one embodiment, the third party loyalty program of the loyalty benefit provider (183) provides offers such benefits as discounts, rewards, incentives, cash back, gifts, coupons, and/or privileges to the user (101) identified by the account identifier (181).

In one embodiment, the association between the account identifier (181) and the loyalty benefit provider (183) in the account data (111) indicates that the user (101) with the account identifier (181) is a member of the loyalty program. As such, the user (101) may use the account identifier (181) to access privileges provided to members of the loyalty program, such as access to member-only areas, facilities, stores, products, or services, rights to only extend to discounts by members, or opportunities to engage in certain activities, purchase certain items, or receive certain services reserved for members.

In one embodiment, privileges can be used without making a purchase. The user (101) may be privileged based on a status of being a member of the loyalty program. The user (101) may use the account identifier (181) to show the status of being a member of the loyalty program.

For example, the user (101) may provide an account identifier (181) (e.g., an account number of a credit card) to the transaction terminal (105) to initiate an authorization process for a particular transaction that is designed to check the membership status of the user (101) as if the account identifier (181) was used to initiate an authorization process for a payment transaction. The special transaction is designed to verify membership status of the user (101) by checking whether the account data (111) is associated with the loyalty benefit provider (183). If the account identifier (181) is associated with a corresponding loyalty benefit provider (183), the transaction processing device (103) provides an approval indication during the authorization process to indicate that the user (101) is a member of the loyalty program. The approval indication may be used as a form of identification that allows the user (101) to access the member's privileges, such as access to services, products, opportunities, facilities, discounts, permissions reserved for the member.

In one embodiment, when the account identifier (181) is used to identify the user (101) as a member of the access member privileges, the transaction processing device (103) stores information regarding access of the corresponding member privileges in the loyalty record (187). The profile generator (121) may use the information accumulated in the loyalty records (187) to enhance the transaction profile (127) and provide personalized/targeted advertising to the user (101) with or without further benefit offerings (e.g., discounts, incentives, rebates, cash backs, rewards, etc.).

In one embodiment, the association of the account identifier (181) with the loyalty offer provider (183) also allows the loyalty benefit provider (183) to access at least a portion of the account data (111) relating to the loyalty program, such as loyalty records (187), as well as certain information about the user (101), such as name, address, and other demographic data.

In one embodiment, the loyalty program allows the user (101) to accumulate benefits, such as reward points, cash back, level of discount, etc., according to loyalty program rules (185). For example, the user (101) may accumulate reward points for transactions that satisfy the loyalty program rules (185); and the user (101) may use the reward points to redeem cash, gifts, discounts, and the like. In one embodiment, the loyalty record (187) stores the accumulated benefit; when an event occurs that satisfies the loyalty program rules, the transaction processing device (103) updates the loyalty record (187) associated with the loyalty benefit provider (183) and the account identifier (181).

In one embodiment, when the payment transaction is performed using the account identifier (181), the accumulated benefit as indicated in the loyalty record (187) may be redeemed when the payment transaction satisfies the loyalty program rules. For example, the user (101) may redeem several points to offset or reduce the amount of the purchase price.

In one embodiment, when the user (101) uses the account identifier (181) to make a purchase as a member, the merchant may further provide information about the purchase; and the transaction processing device (103) may store information about the purchase as part of the loyalty record (187). The information about the purchase may identify a particular good or service purchased by the member. For example, a merchant may provide inventory unit (SKU) level purchasing details to a transaction processing device (103), which are then stored as part of a loyalty record (187). The loyalty benefit provider (183) may use the purchasing details to study the purchasing behavior of the user (101); and the profile generator (121) may augment the transaction profile (127) with SKU level purchase details.

In one embodiment, SKU-level purchase details are requested from the merchant or retailer via an authorization response (e.g., as shown in fig. 9) when the user's (101) account (146) is registered with a loyalty program that allows the transaction processing device (103) (and/or the issuer processor (145)) to collect the purchase details.

In one embodiment, the profile generator (121) may generate a transaction profile (127) based on the loyalty record (187) and provide the transaction profile (127) to the loyalty benefit provider (183) (or other entity when permitted).

In one embodiment, the loyalty benefit provider (183) may use the transaction profile (e.g., 127 or 131) to select candidates for membership issuance. For example, the loyalty program rules (185) may include one or more criteria that may be used to identify which customers are eligible to participate in the loyalty program. The transaction processing device (103) may be configured to automatically provide membership in the loyalty program to a qualified customer when the corresponding customer is performing a transaction via the transaction processing device (103) and/or via an interaction point (107) (e.g., ATM, mobile phone, receipt, statement, website, etc.) that may be accessed by an entity operating the transaction processing device (103). The user (101) may accept membership by responding to the advertisement. For example, the user (101) may load membership into an account in the same manner as coupons are loaded into the user's (101) account.

In one embodiment, the membership is provided as a coupon or associated with another offer of benefit such as a discount, reward, or the like. When the coupon or benefit is redeemed through the transaction processing device (103), the account data (111) is updated to register the user (101) in the corresponding loyalty program.

In one embodiment, a merchant may register a user (101) in a loyalty program when the user (101) makes a purchase at the merchant's transaction terminal (105).

For example, when the user (101) conducts a transaction at an ATM, performs a self-checkout at a POS terminal, or conducts a purchase transaction at a mobile phone or computer, the user (101) may be prompted to join a loyalty program when the transaction is being authorized by the transaction processing device (103). If the user (101) accepts membership, the account data (111) is updated to have an account identifier (181) associated with the loyalty benefit provider (183).

In one embodiment, the user (101) may be automatically registered into the loyalty program when the user's (101) profile meets a set of conditions specified in the loyalty program rules (185). The user (101) may not participate in the loyalty program.

In one embodiment, the loyalty benefit provider (183) may personalize and/or direct loyalty offers based on the user's (101) specific (or linked to the user's (101) transaction profile (131)). For example, the loyalty program rules (185) may use the user-specific profile (131) to select a gift, reward, or incentive for the user (101) (e.g., to redeem a benefit such as reward points accumulated in the loyalty record (187)). The user-specific profile (131) may be augmented with loyalty records (187), or generated based on loyalty records (187). For example, the profile generator (121) may use a subset of the transaction data (109) associated with the loyalty record (187) to generate the user-specific profile (131), or provide greater weight to the subset of the transaction data (109) associated with the loyalty record (187), while also using other portions of the transaction data (109) in deriving the user-specific profile (131).

In one embodiment, the loyalty program may involve different entities. For example, a first merchant may provide an award as a discount, or gift, from a second merchant that has a business relationship with the first merchant. For example, an entity may allow a user (101) to accumulate loyalty benefits (e.g., reward points) through purchase transactions at a set of different merchants. For example, a group of merchants may offer loyalty programs in combination, where loyalty benefits (e.g., reward points) may be accumulated through purchases made at any one of the merchants in the group and may be exchanged for cash when purchases are made at any one of the merchants.

In one embodiment, information identifying the user (101) as a member of the loyalty program is stored in a server connected to the transaction processing device (103). Alternatively or in combination, information identifying the user (101) as a member of the loyalty program may also be stored in the financial transaction card (e.g., in the chip, or in the magnetic stripe).

In one embodiment, loyalty program providers (e.g., merchants, manufacturers, openers, retailers, clubs, organizations, etc.) may compete with one another in conducting loyalty program-related offers. For example, loyalty program providers may bid on loyalty program-related offers; and the ad selector (133) (e.g., under control of an entity operating the transaction processing device (103), or a different entity) may prioritize the offers based on the bids. When the offer is accepted or redeemed by the user (101), the loyalty program provider pays a fee in accordance with the corresponding bid. In one embodiment, the loyalty program provider may make a maximum bid that either automatically bids or specifies an upper limit for the bid; while the actual bid is determined to be the lowest bid possible that is greater than the competitor's bid without exceeding the upper limit.

In one embodiment, an offer is provided to the user (101) in response to the user (101) being identified by the user data (125). If the user-specific profile (131) meets the conditions specified in the loyalty program rules (185), the user (101) may be presented with an offer from the loyalty benefit provider (183). When there are multiple offers from different providers, the offers may be prioritized according to the bids.

In one embodiment, the provider may place bids based on characteristics of the user data (125) that may be used to select the user-specific profile (131). In another embodiment, bids may be placed on a set of transaction profiles (127).

In one embodiment, the loyalty program based offer is provided to the user (101) on time when the offer is acceptable and redeemable by the user (101). For example, when the user (101) is paying for purchases made from a merchant, the user (101) may be presented with an offer to register with a loyalty program provided by the merchant or related provider. If the user (101) accepts the offer, the user (101) is eligible to receive a member discount on the purchase.

For example, when the user (101) is paying for purchases made from merchants, reward benefits may be provided to the user (101) based on loyalty program rules (185) and loyalty records (187) associated with the user's (101) account identifier (181) (e.g., reward points accumulated in a loyalty program). As such, user effort to redeem reward points may be reduced; and the user experience may be improved.

In one embodiment, a method of providing loyalty programs includes the use of a computing device of a transaction processing device (103). The computing device processes a plurality of payment card transactions. After the computing device receives a request to track a transaction for a loyalty program, such as loyalty program rules (185), the computing device stores and updates loyalty program information in response to transactions that occur in the loyalty program. When a customer satisfies a condition defined in a loyalty program, such as loyalty program rules (185), the computing device provides benefits to the customer (e.g., 101).

Assigned publication No.2008/0059302, filed on day 22 of 2007, and entitled "Loyalty Program Service," U.S. patent application serial No.11/767,202, assigned publication No.2008/0059306, filed on day 30 of 2007, and U.S. patent application serial No.11/848,112, assigned publication No.2008/0059307, filed on day 30 of 2007, and entitled "Loyalty Program incorporated determination," examples of Loyalty programs through Collaboration between cooperating components in a payment processing system including a transaction processing device (103) in one embodiment are provided in U.S. patent application serial No.11/848,179, filed on day 22 of 2007, which are incorporated herein by reference.

An example of processing the redemption of accumulated loyalty benefits by a Transaction processing device (103) in one embodiment is provided in U.S. patent application serial No.11/835,100, assigned publication No.2008/0059303, and entitled "Transaction Evaluation for Providing Rewards", filed on 8/7 of 2007, which is hereby incorporated by reference.

In one embodiment, the incentive, reward, or benefit provided in the loyalty program is based on the presence of the associated transaction. For example, in one embodiment, an incentive is provided if a financial payment card is used to make a reservation in the reservation system and then to pay for the goods or services that are reserved. Further details and examples of one embodiment are provided in U.S. patent application serial No.11/945,907 entitled "inclusive Wireless communication reservation," assigned publication No.2008/0071587, 27/11/2007, which is hereby incorporated by reference.

In one embodiment, the transaction processing device (103) provides centralized loyalty program management, reporting, and membership services. In one embodiment, membership data is downloaded from a transaction processing device (103) to a point of acceptance device such as a transaction terminal (105). In one embodiment, loyalty transactions are reported from the point of acceptance device to the transaction processing device (103); and data indicating loyalty points, rewards, benefits, etc. is stored in the account identification device (141). Further details and examples of one embodiment are provided in U.S. patent application serial No.10/401,504 entitled "Network central Loyalty System," assigned publication No.2004/0054581, 3/27/2003, which is incorporated herein by reference.

In one embodiment, the portal (143) of the transaction processing device (103) is used to manage rewards or loyalty programs for entities such as issuers, merchants, and the like. A cardholder such as a user (101) rewards offers/benefits from merchants. The portal (143) and/or transaction processing device (103) tracks the merchant's transaction records for rewards or loyalty programs. Further details and examples of one embodiment are provided in U.S. patent application serial No.11/688,423 entitled "Reward Program Manager" assigned publication No.2008/0195473, 3/20 of 2007, which is hereby incorporated by reference.

In one embodiment, the loyalty program includes multiple entities providing access to detailed transaction data, which allows flexibility in the customization of the loyalty program. For example, an issuer or merchant may sponsor a loyalty program to provide rewards; and the portal (143) and/or transaction processing device (103) stores the loyalty currency in the data repository (149). Further details and examples of one embodiment are provided in U.S. patent application serial No.12/177,530 entitled "Multi-VenderMulti-Loyalty Current Program," assigned publication No.2009/0030793, filed on 22.7.2008, which is incorporated herein by reference.

In one embodiment, the incentive plan is created on a portal (143) of the transaction processing device (103). The portal (143) collects offers from a plurality of merchants and stores the offers in a data store (149). Offers may have associated conditions for their distribution. The portal (143) and/or the transaction processing device (103) may recommend the offer based on the transaction data (109). In one embodiment, the transaction processing device (103) automatically applies the benefit of the offer during processing of the transaction when the transaction satisfies a condition associated with the offer. In one embodiment, a transaction processing device (103) communicates with a transaction terminal (105) to create, customize, and/or update offers based on market focus, product categories, service categories, targeted consumer demographics, and the like. Further details and examples of one embodiment are provided in U.S. patent application serial No.12/413,097 entitled "merchat Device Support of an integrated offer Network," assigned publication No.2010/0049620, 3/27 of 2009, which is hereby incorporated by reference.

In one embodiment, the transaction processing device (103) is configured to provide offers from merchants to the user (101) through the payment system to access and redeem offers that are convenient to the user (101). The offer may be triggered and/or customized for a previous transaction and may only be valid for a limited length of time from the date of the previous transaction. If the transaction processing device (103) determines that a subsequent transaction processed by the transaction processing device (103) is eligible for redemption of the offer, the transaction processing device (103) may transfer the redemption of the offer into the consumer account (146) and/or provide a notification message to the user (101). Further details and examples of one embodiment are provided in provisional U.S. patent application serial No.61/222,287 entitled "benefets Engine Providing benefets Based on mercury Preferences", filed on 7/1 of 2009, which is hereby incorporated by reference.

Details regarding Loyalty Programs in one embodiment are provided in provisional U.S. patent application serial No.61/250,440, entitled Systems and Methods to provide Loyalty Programs, filed on 9/10/2009, which is incorporated herein by reference.

SKU

In one embodiment, the merchant generates a Stock Keeping Unit (SKU) or other specific information identifying the specific goods and services purchased by the user (101) or customer. SKU information may be provided to an operator of a transaction processing device (103) that processes a purchase. An operator of the transaction processing device (103) may store the SKU information as part of the transaction data (109) and reflect the SKU information for a particular transaction in a transaction profile (127 or 131) associated with the person involved in the transaction.

When a user (101) shops at a traditional retail store or browses an online merchant's website, a profile of SKU levels specifically associated with the user (101) may be provided to select advertisements that are appropriately targeted to the user (101) (e.g., via a mobile phone, POS terminal, Web browser, etc.). The profile for the SKU level of the user (101) may include an identification of goods and services historically purchased by the user (101). Additionally, the profile for the SKU level of the user (101) may identify the identity of goods and services that the user (101) may purchase in the future. The identification may be based on historical purchases reflected in a configuration file determined to be similar to the SKU level of other individuals or groups of the user (101). Accordingly, return on investment by advertisers and merchants can be greatly improved.

In one embodiment, the user-specific profile (131) is an aggregate spending profile (341) generated using the SKU level information. For example, in one embodiment, the factor values (344) correspond to factor definitions (331) generated based on aggregated costs in different categories of products and/or services. Typical merchants offer many different categories of products and/or services.

In one embodiment, a user (101) may conduct transactions with various online and "physical" merchants. The transaction may involve the purchase of various goods and services. The goods and services may be identified by SKU numbers or other information that specifically identifies the goods and services purchased by the user (101).

In one embodiment, the merchant may provide the operator of the transaction processing device (103) with SKU information (e.g., SKU-level purchase details) regarding the goods and services purchased by the user (101). In one embodiment, as described in more detail below, the SKU information may be provided to an operator of the transaction processing device (103) along with the loyalty program. The SKU information may be stored as part of the transaction data (109) and associated with the user (101). In one embodiment, SKU information for purchasing items in a transaction facilitated by an operator of a transaction processing device (103) may be stored as transaction data (109) and associated with its associated purchaser.

In one embodiment, SKU level purchase details are requested from the merchant or retailer via an authorization response (e.g., as shown in fig. 9) when the user's (101) account (146) is registered with a plan that allows the transaction processing device (103) (and/or the issuer processor (145)) to collect the purchase details.

In one embodiment, based on the SKU information and perhaps other transaction data, the profile generator (121) may create a SKU-level transaction profile for the user (101). In one embodiment, the profile generator (121) may create a SKU-level transaction profile for each individual transacting with the operator of the transaction processing device (103) based on SKU information associated with the transaction of each individual.

In one embodiment, SKU information associated with a group of buyers can be combined to create a transaction profile describing the SKU level of the group. Groups may be defined based on one or various considerations. For example, a group may be defined by common demographic characteristics of its members. As another example, a group may be defined by a common purchase pattern of its members.

In one embodiment, the user (101) may later consider purchasing additional goods and services. The user (101) may shop at a conventional retailer or an online retailer. For an online retailer, for example, the user (101) may browse the online retailer, publisher, or merchant's website. The user (101) may be associated with a browser cookie, for example, to identify the user (101) and track browsing behavior of the user (101).

In one embodiment, the retailer may provide a browser cookie associated with the user (101) to an operator of the transaction processing device (103). Based on the browser cookie, an operator of the transaction processing device (103) may associate the browser cookie with the personal account number of the user (101). The association may be performed by an operator of the transaction processing device (103) or another entity in various ways, such as, for example, using a look-up table.

Based on the personal account number, the profile selector (129) may select a user-specific profile (131) that constitutes a profile of a SKU level specifically associated with the user (101). The SKU level profile may specifically reflect a user's (101) individual, previous purchases, and/or the type of goods and services purchased by the user (101).

The profile for the SKU level of the user (101) may also include an identification of goods and services that the user (101) may purchase in the future. In one embodiment, the identification may be used for selection of advertisements for goods and services that may be of interest to the user (101). In one embodiment, the identification of the user (101) may be based on information of SKU levels associated with historical shopping for the user (101). In one embodiment, the identification of the user (101) may alternatively or additionally be based on a transaction profile associated with others. The recommendations may be determined by predictive correlations and other analytical techniques.

For example, the identification of the user (101) may be based on a transaction profile of another person. The profile selector (129) may apply a predetermined condition to identify another person deemed to be sufficiently similar to the user (101) to a predetermined extent. The identification of others may be based on various factors including, for example, demographic similarity and/or purchase pattern similarity between the user (101) and others. As one example, a common purchase of the same item or related items by the user (101) and others may result in an association between the user (101) and others and produce a determination that the user (101) and others are similar. Once the other people are identified, the transaction profiles that make up the SKU level profiles of the other people can be analyzed. Through predictive correlation and other modeling and analysis techniques, historical purchases reflected in profiles of other people's SKU levels can be used to predict future purchases by the user (101).

As another example, the identification of the user (101) may be based on a transaction profile of a group of people. The profile selector (129) may apply predetermined conditions to identify a plurality of individuals deemed to be sufficiently similar to the user (101) to a predetermined extent. The identification of others may be based on various factors including, for example, demographic similarity and/or purchase pattern similarity between the user (101) and others. Once the group of others is identified, the transaction profiles of the SKU levels comprising the group may be analyzed. Through predictive correlation and other modeling and analysis techniques, historical purchases reflected in the SKU level profiles of the group can be used to predict future purchases by the user (101).

A profile of SKU levels of the user (101) may be provided to select appropriately targeted advertisements. Because the profile for the SKU level of the user (101) may include an identification of goods and services that the user (101) may purchase, the user (101) may be presented with advertisements corresponding to the identified goods and services. In this way, targeted advertising to the user (101) may be optimized. In addition, advertisers and publishers of advertisements may improve their return on investment and may improve their ability to cross sell goods and services.

In one embodiment, a profile that has been identified as a SKU level similar to others of the user (101) may be used to identify users (101) that may exhibit a high propensity to purchase goods and services. For example, if the profile of the other's SKU level reflects a quantity or frequency of purchases determined to meet a threshold, then the user (101) may also be classified or predicted to exhibit a high propensity for purchase. Accordingly, the type and frequency of advertisements that take such trends into account may be tailored appropriately for the user (101).

In one embodiment, the configuration file for the SKU level of the user (101) may reflect a transaction with a particular merchant or multiple merchants. A peer or similar enterprise, considered a particular merchant or multiple merchants, may be provided with a configuration file for the SKU level of the user (101). For example, a merchant may be considered a peer of a business in that the merchant provides goods and services similar to or related to those of the business. A profile reflecting the SKU level of transactions with peer merchants may be used by businesses to better predict the purchasing behavior of users (101) and optimize the presentation of targeted advertisements to users (101).

Details regarding SKU-Level configuration files in one embodiment are provided in provisional U.S. patent application serial No.61/253,034, filed on 19/10/2009 and entitled "Systems and Methods for adapting Services Based on an SKU-Level Profile," which is hereby incorporated by reference.

Details of purchase

In one embodiment, the transaction processing device (103) is configured to selectively request purchase details in response to the authorization. When the transaction processing device (103) (and/or the issuer processor (145)) requires purchase details, such as the identity of the specific goods purchased and/or their price, the authorization response transmitted from the transaction processing device (103) will include an indicator of the request for purchase details for the transaction being authorized. The merchant will determine whether to submit the purchase details based on whether there is a demand indicated in the authorization response from the transaction processing device (103).

For example, in one embodiment, the transaction processing device (103) is configured to redeem the manufacturer coupon by checking the account credit. The manufacturer may provide a user (e.g., 101) with promotional offers such as coupons for rebates, discounts, cash returns, reward points, gifts, and the like. Offers may be provided to users (e.g., 101) through various channels, such as websites, newspapers, direct mail, targeted advertisements (e.g., 119), loyalty programs, and so forth.

In one embodiment, when the user (101) has one or more pending offers under the consumer account (146) and uses the consumer account (146) to pay for a purchase made from a retailer that supports redemption of the offers, the transaction processing device (103) will use the authorization response to request purchase details, match the offer details with the items that are proven to be purchased in the purchase details to identify the offers that can be exchanged for cash, and manage funds for redeeming the offers that can be exchanged for cash between the user (101) and the manufacturer that funded the corresponding offers. In one embodiment, the request for purchase details is provided in real time with the authorization message; while the exchange and matching of purchase details may be done outside the authorization process in real time or at the end of the day through batch files for multiple transactions.

In one embodiment, the offer is associated with a consumer account (146) of the user (101) to automate the process of redemption of the offer. If the user (101) pays for a purchase using the user's (101) consumer account (146), the transaction processing device (103) (and/or the issuer processor (145)) processes the payment transaction and automatically identifies offers suitable for redemption under consideration for the purchase and provides qualified benefits to the user (101). In one embodiment, the transaction processing device (103) (or issuer processor (145)) will detect the applicable offer for redemption and provide the benefit of being redeemed by crediting the account without requiring the user (101) to perform additional tasks.

In one embodiment, once the user (101) uses the consumer account (146) to make the requested purchase according to the offer's requirements, the benefit of the offer is fulfilled by the transaction processing device (103) (or issuer processor (145)) without the user (101) performing any special operations at and/or after checkout, other than paying with the user's (101) consumer account (146), such as a credit card account, loyalty card account, private label card account, coupon card account, or prepaid card account, registered to the automated plan for redemption.

In one embodiment, redemption of the offer (e.g., manufacturer coupon) requires the purchase of a particular product or service. After verifying that a particular product or service is purchased, the user (101) is entitled to the benefit of the offer. In one embodiment, the transaction processing device (103) (or issuer processor (145)) dynamically requests purchase details through an authorization response to determine eligibility of the purchase for redemption of such an offer.

In one embodiment, the method of requesting purchase details on demand by (or in conjunction with) an authorization process is used in other situations where transaction level data is required on a case-by-case basis as determined by the transaction processing device (103).

For example, in one embodiment, the transaction processing device (103) and/or the issuer processor (145) determines that the user (101) has registered to receive purchase item details electronically, and the transaction processing device (103) and/or the issuer processor (145) may issue a request as needed; and the purchase details may be stored for later download into a personal accounting software application or a business accounting software application.

For example, in one embodiment, the transaction processing device (103) and/or the issuer processor (145) determine that the user (101) has registered to automate the process of reimbursement for eligible healthcare goods under certain healthcare accounts, such as a Health Savings Account (HSA), Flexible Spending Arrangement (FSA), and the like. In response to such a determination, the transaction processing device (103) and/or the issuer processor (145) requests purchase details to automatically identify the purchase of qualified healthcare goods, capture and report evidence showing qualification, bill receipts or equivalent information for compliance with rules, regulations and legal reporting purposes (e.g., as required by the U.S. national tax agency), and/or make an reimbursement for funds with the corresponding healthcare account.

FIG. 9 illustrates a system for obtaining purchase details according to one embodiment. In fig. 9, when the user (101) pays for a purchase using the consumer account (146), the merchant or retailer's transaction terminal (105) sends an authorization request (168) to the transaction processing device (103). In response, an authorization response is transmitted from the transaction processing device (103) to the transaction terminal (105) to inform the merchant or retailer of the decision to approve or decline the payment request, as determined by the issuer processor (145) and/or the transaction processing device (103). The authorization response (138) typically includes an authorization code (137) that identifies the transaction and/or indicates that the transaction is approved.

In one embodiment, when the transaction is approved and there is a need for purchase details (169), the transaction processing device (103) (or issuer processor (145)) will provide an indicator of the request for purchase details (139) in an authorization response (138). An optional request (139) allows the transaction processing device (103) (and/or the issuer processor (145)) to request purchase details (169) from the merchant or retailer on demand. When there is a request (139) for purchase details in the authorization response (138), the transaction terminal (105) will provide the purchase details (169) associated with the payment transaction to the transaction processing device (103) either directly or indirectly through the portal (143). When there is no request (139) in the authorization response (138), the transaction terminal (105) does not have to provide purchase details (169) of the payment transaction.

In one embodiment, when the transaction is approved but the purchase details (169) are not needed, no indicator of the request for purchase details (139) is set in the authorization response (138).

In one embodiment, prior to transmitting the authorization response (138), the transaction processing device (103) (and/or the issuer processor (145)) determines whether there is a need for transaction details. In one embodiment, the request (139) for the purchase details (169) is not provided in an authorization response (138) for the payment transaction when the purchase details (169) for the payment transaction are not needed. When there is a need for purchase details (169) for the payment transaction, a request (139) for the purchase details (169) is provided in an authorization response (138) for the payment transaction. When the authorization response message does not explicitly request detailed purchase data, the merchant or retailer does not have to send the detailed purchase data to the transaction processing device (103).

As such, the transaction processing device (103) (or the issuer processor (145)) does not necessarily require all merchants or retailers to transmit detailed purchase data (e.g., SKU-level purchase details) for all payment transactions processed by the transaction processing device (103) (or the issuer processor (145)).

For example, when the consumer account (146) of the user (103) has collected manufacturer coupons for products or services that may be sold by the merchant or retailer operating the transaction terminal (105), in one embodiment, the transaction processing device (103) will request purchase details (169) via the authorization response (138). If the purchase details (169) show that conditions for redemption of the manufacturer's coupon are met, the transaction processing device (103) will provide the user (101) with the benefit of the manufacturer's coupon through the points of the statement of the consumer account (146). This automation of the fulfillment of the manufacturer's coupons frees the merchant/retailer from the effort and complexity of handling the manufacturer's benefits and improves the user experience. Additionally, retailers and manufacturers are provided with new consumer promotional distribution channels through the transaction processing device (103), which can direct offers based on the transaction profile (127) and/or transaction data (109) of the user (101). In one embodiment, the transaction processing device (103) may use an offer for a loyalty/rewards program.

In another example, if the user (101) engages in a plan requesting the transaction processing device (103) to track and manage the purchase details (169) of the user (103), the transaction processing device (103) will request the transaction details (169) with an authorization response (138).

In one embodiment, the message of the authorization response (138) is configured to include a field indicating whether purchase details of the transaction are requested.

In one embodiment, the authorization response message includes a field indicating whether the account (146) of the user (101) is a participant in the coupon redemption network. When the field indicates that the user's (101) account (146) is a participant in the coupon redemption network, the merchant or retailer will submit purchase details (169) of the payment made using the user's (101) account (146).

In one embodiment, when there is a request (139) for purchase details (169) in the authorization response (138), the merchant's or retailer's transaction terminal (105) stores the purchase details (169) with the authorization information provided in the authorization response (138). When a transaction is submitted to the transaction processing device (103) for settlement, purchase details (169) are also submitted with the request for settlement.

In one embodiment, the purchase details (169) are transmitted to the transaction processing device (103) through a communication channel separate from a communication channel used for the authorization and/or settlement request for the transaction. For example, a merchant or retailer may report purchase details to the transaction processing device (103) through the portal (143) of the transaction processing device (103). In one embodiment, the report includes an identification of the transaction (e.g., authorization code (137) and purchase details (e.g., SKU number, Universal Product Code (UPC)) for the payment transaction.

In one embodiment, the portal (143) of the transaction processing device (103) may also further communicate with a merchant or retailer to reduce the amount of purchase detail data to be transmitted by the transaction processing device (103). For example, in one embodiment, the transaction processing device (103) provides an indication of the category of service or product for which purchase details (169) are requested; while the merchant or retailer will only report items in these categories. In one embodiment, the portal (143) of the transaction processing device (103) will ask the merchant or retailer to indicate whether the purchased goods include a set of goods required for redemption of the offer.

In one embodiment, the merchant or retailer will complete the purchase based on the indication of approval provided in the authorization response (138). When an indicator (e.g., 139) is present in the authorization response (138), the merchant (e.g., inventory management system or transaction terminal (105)) will capture the purchase details (169) and retain them in the electronic data file. The purchase details (169) include an identification of the individual items purchased (e.g., SKUs and/or UPCs), their prices, and/or a short description of the items.

In one embodiment, the merchant or retailer will send the transaction purchase data file to the transaction processing device (103) (or the issuer processor (145)) at the end of the day or according to some other predetermined schedule. In one embodiment, a data file of purchase details (169) is transmitted with the request to settle the transaction approved by the authorization response (138). In one embodiment, the data file of purchase details (169) is transmitted separately from the request to settle the transaction approved by the authorization response (138).

Further details and examples of one embodiment of offer fulfillment are provided in provisional U.S. patent application serial No.61/347,797 entitled "Systems and Methods for retrieval of Offers" filed 24/5 2010, which is incorporated herein by reference.

Targeted advertising

FIG. 10 illustrates a system for providing a profile to target advertisements, according to one embodiment. In fig. 10, the portal (143) is used to provide a user-specific profile (131) in real-time in response to a request to identify a user (e.g., 101) using user data (125) of an interaction point (e.g., 107) on which an advertisement may be presented.

In one embodiment, the profile selector (129) selects a user-specific profile (131) from the set of transaction profiles (127) based on a match of the characteristics of the user of the transaction profile (127) and the characteristics of the user data (125). Transaction profiles (127) previously generated by the profile generator (121) using the transaction data (109) are stored in a data store (149).

In one embodiment, the user data (125) indicates characteristics of a group of users (101); and the profile selector (129) uses the user data (125) to determine the identity of the user (101) uniquely associated with the transaction profile (131). One example of such an identity is account information (142) identifying a consumer account (146) of the user (101), such as an account number (302) in a transaction record (301). In one embodiment, the user data (125) does not include the identity of the user (101); and the profile selector (129) determines the identity of the user (101) based on a match of information associated with the identity of the user (101) and information provided in the user data (125), such as by matching an IP address, a street address, a browser cookie ID, a pattern of online activity, a pattern of purchase activity, and so forth.

In one embodiment, after determining the identity of the user (101) using the user data (125), the profile generator (121) generates a user-specific profile (131) in real-time from the transaction data (109) of the user (101). In one embodiment, the user-specific profile (131) is computed after receiving the user data (125); and providing a user-specific profile (131) in response to the request for providing user data (125). As such, the user-specific profile (131) is computed in real-time with respect to the request, or the request is served in quasi-real-time.

In one embodiment, the profile selector (129) selects a user-specific profile (131) for a particular user or group of users and that best matches the feature set specified by the user data (125). In one embodiment, the profile generator (121) generates a user-specific profile (131) that best matches one or more users identified by the user data (125).

In another embodiment, a portal (143) of a transaction processing facility (103) is configured to provide a set of transaction profiles (127) in a batch mode. A profile user, such as a search engine, publisher or advertising agency, will select a user-specific profile (131) from a set of previously received transaction profiles (127).

FIG. 11 illustrates a method of providing a profile for an advertisement, according to one embodiment. In FIG. 11, a computing device receives (201) transaction data (109) relating to a plurality of transactions processed on a transaction processing device (103), receives (203) user data (125) about a user (101) to whom an advertisement (e.g., 119) is to be presented, provides (205), based on the transaction data (109), a user-specific profile (131) to select, generate, prioritize, customize, or adjust the advertisement (e.g., 119).

In one embodiment, the computing device includes at least one of: a portal (143), a profile selector (129), and a profile generator (121). The computing device will provide the user-specific profile (131) to the third party in real-time in response to a request to identify the user (101) using the user data (125).

In one embodiment, a computing device will receive a request for a profile (e.g., 131 or 341) to customize information for presentation to a user (101) identified in the request, and in response to the request identifying the user (101), provide a profile (e.g., 131 or 341) generated based on transaction data (e.g., 109 or 301) of the user (101). In one embodiment, the information includes advertisements (e.g., 119) identified, selected, prioritized, adjusted, customized, or generated based on a profile (e.g., 131 or 341). In one embodiment, the advertisement includes at least an offer such as a discount, incentive, reward, coupon, gift, cash back, benefit, product or service. In one embodiment, the computing device will generate and/or present information to the user (101) that is customized according to the configuration file (e.g., 131 or 341); alternatively, a third party, such as a search engine, publisher, advertiser, advertising network, or online merchant, will customize the information and/or present the information to the user (101) according to a profile (e.g., 131 or 341). In one embodiment, adjusting the advertisement or information includes adjusting an order of the advertisement or information relative to other advertisements or information, adjusting a placement location of the advertisement or information, adjusting a presentation format of the advertisement or information, and/or adjusting an offer presented in the advertisement or information. Details regarding targeted advertising in one embodiment are provided in the section entitled "targeted advertising".

In one embodiment, the transaction data (e.g., 109 or 301) relates to a plurality of transactions processed in the transaction processing device (103). Each transaction is processed by the transaction processing device (103) to pay the transferee from the issuer in response to the account identifier submitted to the transferee by the merchant as issued to the user by the issuer. The issuer will make payment on behalf of the user (101) and the transferee will receive payment on behalf of the merchant. Details regarding the transaction processing device (103) and the portal (143) in one embodiment are provided in the section entitled "Portal based transaction data".

In one embodiment, the configuration file (e.g., 131 or 341) aggregates the transaction data (e.g., 109 or 301) for the user (101) using a plurality of values (e.g., 344 or 346) representing aggregate costs for various domains. In one embodiment, values are calculated for factors identified from a factor analysis (327) of a plurality of variables (e.g., 313 and 315). In one embodiment, the factor analysis (327) is based on transaction data (e.g., 109 or 301) associated with a plurality of users. In one embodiment, variables (e.g., 313 and 315) aggregate transactions based on merchant categories (e.g., 306). In one embodiment, the variables include a spend frequency variable (e.g., 313) and a spend amount variable (e.g., 315). In one embodiment, transactions processed by a transaction processing device (103) are classified into a plurality of merchant categories (e.g., 306); and the plurality of values (e.g., 344 or 346) is less than the plurality of merchant categories (e.g., 306) to aggregate the aggregated cost in the plurality of merchant categories (e.g., 306). In one embodiment, each of the plurality of values (e.g., 344 or 346) indicates a level of aggregate spending for the user. In one embodiment, a computing device is to generate a profile (e.g., 131 or 341) using transaction data (e.g., 109 or 301) of a user (101) based on a cluster definition (333) and a factor definition (331), where the cluster definition (333) and the factor definition (331) are generated based on transaction data of a plurality of users that may or may not include the user (101) represented by the profile (e.g., 131 or 341). The section entitled "deal profile" and the section entitled "aggregated spending profile" provide details about the deal profile (e.g., 133 or 341) in one embodiment.

In one embodiment, prior to receiving the request in the computing device, a configuration file (e.g., 131 or 341) is computed; and the computing device will select a profile (e.g., 131 or 341) from the plurality of profiles (101) based on a request identifying the user (101).

In one embodiment, the computing device will identify transaction data (e.g., 109 or 301) for the user (101) based on a request identifying the user (101), and in response to the request, compute a profile (e.g., 131 or 341) based on the transaction data (e.g., 109 or 301) for the user (101).

In one embodiment, a user (101) is identified in a request received in a computing device by an IP address, such as an IP address of an interaction point (107); and the computing device will identify an account identifier, such as an account number (302) or account information (142), for the user (101) based on the IP address. For example, in one embodiment, the computing device will store account data (111) that includes a street address of the user (101), map the IP address to a street address of the computing device (e.g., 107) of the user (101), and identify an account identifier (e.g., 302 or 142) of the user (101) based on a match of the street address of the computing device and the street address of the user (101) stored in the account data (111).

In one embodiment, the user (101) is identified in the request by an identifier of a browser cookie associated with the user (101). For example, in one embodiment, a lookup table is used to match an identifier of a browser cookie with an account identifier (e.g., 302 or 142).

Details regarding identifying users in one embodiment are provided in the sections entitled "profile matching" and "browser COOKIE".

One embodiment provides a system comprising a transaction processing device (103) that processes a transaction. Each transaction is processed by the transaction processing device (103) to make a payment from the issuer to the transferor in response to the customer's account identifier submitted by the merchant to the transferor as issued by the issuer. The issuer will make payment on behalf of the customer and the transferee will receive payment on behalf of the merchant. The system also includes a data store (149) that stores transaction data (109) that records transactions processed at the transaction processing device (103), a profile generator (121) that generates a profile (e.g., 131 or 341) for the user (101) based on the transaction data, and a portal (143) that receives a request identifying the user (101) and provides the profile (e.g., 131 or 341) in response to the request to facilitate customization of information presented to the user (101). In one embodiment, the profile includes a plurality of values (e.g., 344 or 346) representing aggregate spending by the user (101) in various areas to aggregate transactions by the user (101).

In one embodiment, the system further includes a profile selector (129) that selects a profile (e.g., 131 or 341) from the plurality of profiles (127) generated by the profile generator (121) based on a request identifying the user (101). A profile generator (121) generates a plurality of profiles (127) and stores the plurality of profiles (127) in a data store (149).

In one embodiment, the system further includes an advertisement selector (133) that generates, selects, adjusts, prioritizes, or customizes advertisements in the information based on the configuration file (e.g., 131 or 341).

Details regarding the system in one embodiment are provided in sections entitled "System," centralized data warehouse, "and" hardware.

Variants

Some embodiments use more or less components than those shown in fig. 1 and 4-7. For example, in one embodiment, the user-specific profile (131) is used by the search engine to prioritize search results. In one embodiment, the correlator (117) will associate transactions with online activities such as search, Web browsing, and social networking, in place of or in addition to user-specific advertising data (119). In one embodiment, the correlator (117) will associate transaction and/or consumption patterns with news announcements, market changes, events, natural disasters, and the like. In one embodiment, data to be associated with the transaction data (109) by the correlator may not be personalized by the user-specific profile (131) and may not be user-specific. In one embodiment, a plurality of different devices are used at an interaction point (107) to interact with a user (101); while some devices may not be able to receive input from the user (101). In one embodiment, there is a transaction terminal (105) for initiating transactions for a plurality of users (101) with a plurality of different merchants. In one embodiment, the account information (142) is provided directly (e.g., over the telephone or the internet) to the transaction terminal (105) without the use of an account identification device (141).

In one embodiment, at least some of the profile generator (121), correlator (117), profile selector (129), and ad selector (133) are controlled by an entity operating the transaction processing device (103). In another embodiment, at least some of the profile generator (121), correlator (117), profile selector (129), and ad selector (133) are not controlled by an entity operating the transaction processing device (103).

For example, in one embodiment, an entity operating the transaction processing device (103) provides intelligence (e.g., a transaction profile (127) or a user-specific profile (131)) for selecting advertisements; while a third party (e.g., a Web search engine, publisher, or retailer) may present the advertisement in a context external to the transaction involving the transaction processing device (103) before the advertisement results in a purchase.

For example, in one embodiment, a customer may interact with a third party at an interaction point (107); while the entity controlling the transaction processing device (103) may allow a third party to query for intelligent information (e.g., transaction profiles (127), or user-specific profiles (131)) using the user data (125), in this way, the third party is notified of the intelligent information for targeted advertising, which may be more useful, effective, and strongly appealing to the user (101). For example, an entity operating the transaction processing device (103) may provide intelligent information without generating, identifying, or selecting advertisements; while a third party receiving the intelligent information may identify, select and/or present the advertisement.

Using transaction data (109), account data (111), correlation results (123), context at the point of interaction, and/or other data, relevant and strongly engaging messages or advertisements can be selected for a customer at the point of interaction (e.g., 107) for targeted promotions. In this manner, messages or advertisements are provided at optimal times that affect or enhance brand perception and revenue generation behavior. The customer receives advertisements in the media channel that they like and/or use most frequently.

In one embodiment, the transaction data (109) includes the transaction amount, the identity of the payee (e.g., merchant), and the date and time of the transaction. The identity of the payee may be associated with the payee's business, service, product, and/or location. For example, the transaction processing device (103) maintains a database of merchant data, including merchant locations, businesses, services, products, and so forth. As such, the transaction data (109) may be used to determine purchasing behavior, patterns, preferences, trends, frequency, budget, and/or trends of customers with respect to various types of businesses, services, and/or products and with respect to time.

In one embodiment, the products and/or services purchased by the user (101) are also identified by information transmitted from the merchant or service provider. As such, the transaction data (109) may include an identification of individual products and/or services, which allows the profile generator (121) to generate the transaction profile (127) at a fine granularity or resolution. In one embodiment, the granularity or resolution may be at the level of different products and services that may be purchased (e.g., Stock Keeping Unit (SKU) level), or categories or types of products or services, or suppliers of products or services, and so on.

The profile generator (121) may consolidate transaction data for a person having multiple accounts to derive intelligent information about the person to generate a profile for the person (e.g., a transaction profile (127), or a user-specific profile (131)).

The profile generator (121) may consolidate transaction data for a family having multiple accounts held by family members to derive intelligence information about the family to generate a profile for the family (e.g., a transaction profile (127), or a user-specific profile (131)).

Similarly, the profile generator (121) may consolidate transaction data for a group of people, the group identified by certain characteristics such as gender, income level, geographic location or area, preferences, characteristics of past purchases (e.g., merchant category, purchase type), clusters, trends, demographics, social networking characteristics (e.g., relationships on social networking websites, preferences, activities), and so forth. The consolidated transaction data may be used to derive intelligence information about the group to generate a profile for the group (e.g., transaction profile (127), or user-specific profile (131)).

In one embodiment, the profile generator (121) may merge transaction data based on the user data (125) to generate a user data (125) specific profile.

Since the transaction data (109) is a record and history of past purchases, the profile generator (121) can derive intelligent information about customers using one account, customers using multiple accounts, homes, companies, or other customer groups, what the target audience is likely to purchase in the future, how often, and their possible budget for such future purchases. The intelligent information is useful for selecting the most useful, effective and strongly engaging advertisements for the customer, thus increasing the efficiency of the promotion process.

In one embodiment, transactional data (109) is enhanced with correlation results (123) that correlate past advertisements with purchases generated at least in part by the advertisements. In this manner, the intelligent information may be more accurate in helping to select advertisements. The intelligent information may indicate not only what the audience is likely to purchase, but also how likely the audience will be affected by the advertisement for certain purchases, as well as the relative effectiveness of different forms of advertisements to the audience. In this manner, the advertisement selector (133) may select advertisements that best use the opportunity to communicate with the audience. Further, the Transactional Data (109) may also be enhanced by other Data elements, such as plan registration, affinity plans, redemption of reward points (or other types of offers), online activities such as Web searching and Web browsing, social network information, and the like, based on account Data (111) and/or other Data, such as non-Transactional Data discussed in U.S. patent application No.12/614,603 entitled "analytical LocalNon-Transactional Data with Transactional Data in PredictiveModels," filed on 9.2009, which is hereby incorporated by reference.

In one embodiment, an entity operating the transaction processing device (103) provides the intelligent information in real time as requests for the intelligent information are issued. In other embodiments, the entity operating the transaction processing device (103) may provide the intelligent information in a batch mode. The intelligent information may be communicated through online communication (e.g., through an Application Programming Interface (API) on a website, or other information server), or through physical transport of a computer-readable medium that stores data representing the intelligent information.

In one embodiment, intelligent information is communicated to various entities in the system in a manner similar to and/or parallel to the information flow of mobile funds in the transaction system. The transaction processing device (103) routes information in the same way as it routes money involved in the transaction.

In one embodiment, the portal (143) provides a user interface to allow the user (101) to select items offered on different merchant websites and store the selected items in a list of items desired to be purchased for comparison, review, purchase, tracking, and the like. Information gathered by a list of items desired to be purchased may be used to refine the transaction profile (127) and derive intelligence as required by the user (101); targeted advertisements may be placed to the user (101) through a list of items desired for purchase user interface provided by the portal (143). An example of a user interface System for Managing a list of Items desired to be purchased is provided in U.S. patent application serial No.12/683,802 entitled "System and Method for Managing Items of interest Selected from Online businesses" filed on 7/1/2010, which is hereby incorporated by reference.

Aggregated spending profile

In one embodiment, the characteristics of a customer's transaction patterns are aggregated by clusters, factors, and/or categories of shopping. The transaction data (109) may include a transaction record (301); in one embodiment, however, an aggregate spending profile (341) is generated from the transaction record (301) to aggregate spending activities reflected in the transaction record (301) in the manner illustrated in FIG. 2.

In one embodiment, each of the transaction records (301) is for a particular transaction processed by the transaction processing device (103). Each of the transaction records (301) provides information about a particular transaction, such as an account number (302) of a consumer account (146) used to pay for a purchase, a date (303) (and/or time) of the transaction, an amount (304) of the transaction, an ID (305) of a merchant receiving payment, a category (306) of the merchant, a channel (307) through which the purchase was made, and so forth. Examples of channels include online, offline stores, over the phone, and so forth. In one embodiment, the transaction record (301) may also include a field identifying the type of transaction, such as card, cardless, or the like.

In one embodiment, a "card present" transaction involves a transaction by physically presenting an account identification device (141) to a merchant, such as a financial transaction card (e.g., by swiping a credit card at the merchant's POS terminal); whereas a "card-less" transaction involves presenting account information (142) of a consumer account (146) to a merchant to identify the consumer account (146), without physically presenting an account identification device (141) to the merchant or transaction terminal (105).

In one embodiment, certain information about the transaction may be queried in a separate database based on other information recorded for the transaction. For example, the database may be used to store information about merchants, such as geographic locations of the merchants, categories of the merchants, and so forth. As such, the merchant ID (305) recorded for the transaction may be used to determine corresponding merchant information related to the transaction.

In one embodiment, the transaction record (301) may also include details regarding products and/or services involved in the purchase. For example, a list of items purchased at a transaction may be recorded with a corresponding purchase price for the items and/or a corresponding quantity of items purchased. The products and/or services may be identified by Stock Keeping Unit (SKU) numbers or product category IDs. The purchase details may be stored in a separate database and may be queried based on an identifier of the transaction.

When there is a large amount of data representing the transaction record (301), the consumption pattern reflected in the transaction record (301) may be difficult for ordinary people to recognize.

In one embodiment, a large number of transaction records (301) are aggregated (335) into an aggregated spending profile (e.g., 341) to concisely present statistical spending profiles reflected in the transaction records (301). The aggregated spending profile (341) presents statistical characteristics of the transaction records (301) of the entity using values derived from statistical analysis in a manner that is easily understood by the average person.

In FIG. 2, transaction records (301) are aggregated (335) by factor analysis (327) to aggregate variables (e.g., 313, 315) and to separate entities by consumption patterns by cluster analysis (329).

In fig. 2, a set of variables (e.g., 311, 313, 315) is defined based on parameters recorded in a transaction record (301). Variables (e.g., 311, 313, and 315) are defined in a manner that has a meaning that is easily understood by an average person. For example, the variable (311) measures the aggregate cost in the superclass; a variable (313) measures frequency of spending in various domains; and variable (315) measures the amount spent in various domains. In one embodiment, each domain is identified by a merchant category (306) (e.g., as represented by a Merchant Category Code (MCC), North American Industrial Classification System (NAICS) code, or similarly standardized category code). In other embodiments, the domain may be identified by a product category, a SKU number, or the like.

In one embodiment, the same category of variables (e.g., frequency (313) or amount (315)) are defined to be clustered on a set of mutually exclusive domains. The transaction is classified into only one of mutually exclusive domains. For example, in one embodiment, a spending frequency variable (313) is defined for a set of mutually exclusive merchants or categories of merchants. Transactions belonging to the same category are aggregated.

Examples of spending frequency variables (313) and spending amount variables (315) defined for various merchant categories (e.g., 306) in one embodiment are provided in U.S. patent application serial No.12/537,566 entitled "Cardholder clusterics" filed on 8/7 of 2009 and provisional U.S. patent application serial No.61/182,806 entitled "Cardholder clusterics" filed on 6/1 of 2009, which are hereby incorporated by reference.

In one embodiment, super-categories (311) are defined to group categories (e.g., 306) used in transaction records (301). The super classes (311) may be mutually exclusive. For example, each merchant category (306) is classified as being under only one super merchant category, but not under any other super merchant category. Since the generation of a list of super classes typically requires profound domain knowledge about the businesses of merchants in the various classes, super class (311) is not used in one embodiment.

In one embodiment, aggregating (317) includes applying the definitions (309) of the variables (e.g., 311, 313, and 315) to the transaction record (301) to generate variable values (321). The transaction records (301) are aggregated to generate aggregated metrics (e.g., variable values (321)) that are not transaction-specific, such as the frequency of purchases made at different merchants or different groups of merchants, the amount spent at different merchants or different groups of merchants, and the number of unique purchases across different merchants or different groups of merchants, among others. Aggregation may be performed 317 for a particular time period and for various levels of entities.

In one embodiment, transaction records are aggregated (301) based on purchasing entities. Aggregation (317) may be performed at an account level, a person level, a family level, a company level, a neighborhood level, a city level, an area level, and so forth, to analyze consumption patterns across various domains (e.g., sellers, products, or services) for respective aggregated purchasing entities. For example, transaction records (301) for a particular account (e.g., as presented by account number (302)) may be aggregated for account-level analysis. To aggregate transaction records (301) at an account level, transactions with a particular one or more merchants in a particular category are counted according to a variable definition (309) for a particular account to generate a frequency metric (e.g., 313) for the account relative to the particular merchant or category of merchants; for a particular account, the transaction amounts (e.g., 304) of a particular merchant or class of merchants are summed to generate an average spend amount for the account with respect to the particular merchant or class of merchants. For example, transaction records (301) for a particular person with multiple accounts may be aggregated for person-level analysis, for a particular household, transaction records (301) for household-level analysis, and transaction records (301) for a particular business may be aggregated for business-level analysis.

The aggregation (317) may be performed for a predetermined period of time, such as for transactions that occurred in the past month, the past three months, the past twelve months, and so forth.

In another embodiment, transaction records are aggregated (301) according to the selling entity. Consumption patterns in selling entities across various buyers, products or services can be analyzed. For example, transaction records for a particular merchant for transactions having multiple accounts may be aggregated (301) for merchant-level analysis. For example, transaction records for a particular group of merchants may be aggregated (301) for analysis at the merchant group level.

In one embodiment, an aggregation (317) is formed separately for different types of transactions, such as online, offline, transactions conducted over the phone, and/or "card present" transactions versus "card absent" transactions, which aggregation (317) may be used to identify consumption pattern differences between the different types of transactions.

In one embodiment, the variable values (e.g., 323, 324,. 325) associated with the entity ID (322) are treated as random samples of the respective variables (e.g., 311, 313, 315) sampled for the instance of the entity represented by the entity ID (322). Statistical analysis (e.g., factor analysis (327) and cluster analysis (329)) is performed to identify patterns and associations in the random sample.

For example, the cluster analysis (329) may identify a set of clusters, such as a cluster definition (333) (e.g., a location of a center of gravity of a cluster). In one embodiment, each entity ID (322) is represented as a point in a mathematical space defined by a set of variables; whereas the variable values (323, 324.., 325) of the entity ID (322) determine the coordinates of the points in space, and thus the locations of the points in space. Various points may be concentrated in various regions; and the cluster analysis (329) is configured to form a positioning of the points to drive clustering of the points. In other embodiments, the clustering analysis (329) may also be performed using a self-organizing map (SOM) technique that may identify and show clusters of multidimensional data using representations on a two-dimensional graph.

Once the cluster definition (333) is obtained from the cluster analysis (329), the identity of the cluster containing the entity ID (322) (e.g., cluster ID (343)) may be used to characterize the spending behavior of the entity represented by the entity ID (322). Entities in the same cluster are considered to have similar spending behavior.

Similarities and differences between entities such as accounts, individuals, families, etc., as represented by entity IDs (e.g., 322) and characterized by variable values (e.g., 323, 324.., 325) may be identified through cluster analysis (329). In one embodiment, after identifying a number of clusters of entity IDs based on a pattern of aggregated metrics, a set of profiles may be generated for the clusters to represent characteristics of the clusters. Once the clusters are identified, each of the entity IDs (e.g., corresponding to an account, person, family) can be assigned to one cluster; while the profile of the corresponding cluster may be used to represent, at least in part, an entity (e.g., account, person, family). Alternatively, a relationship between an entity (e.g., account, person, family) and one or more clusters may be determined (e.g., based on a measure of proximity to each cluster). As such, the cluster-related data may be used in a transaction profile (127 or 341) to provide information about the behavior of an entity (e.g., account, person, family).

In one embodiment, more than one group of cluster definitions (333) are generated from the cluster analysis (329). For example, the cluster analysis (329) may generate different groups of cluster solutions corresponding to different numbers of identified clusters. A set of cluster IDs (e.g., 343) can be used to aggregate (335) spending behavior for entities represented by the entity ID (322) based on typical spending behavior for the respective cluster. In one example, two clustering solutions are obtained; one of the clustering solutions has 17 clusters that classify entities in a relatively coarse manner; while other clustering solutions have 55 clusters that classify entities in a relatively subtle manner. The cardholder may be identified by spending activity in one of the 17 clusters and one of the 55 clusters in which the cardholder resides. As such, the cluster ID groups corresponding to the cluster solution groups provide hierarchical identification of entities among the clusters of different levels of resolution. Spending behavior of a cluster is represented by a cluster definition (333), such as a parameter (e.g., variable value), that defines a center of gravity of the cluster.

In one embodiment, the random variables (e.g., 313 and 315) as defined by definition (309) have some degree of association, not independent of each other. For example, merchants of different merchant categories (e.g., 306) may have overlapping businesses, or have certain business relationships. For example, certain products and/or services of certain merchants have causal relationships. For example, certain products and/or services of certain merchants are mutually exclusive to some extent (e.g., a purchase from one merchant may have a certain probability of precluding a user (101) from making a purchase from another merchant). Such relationships can be complex, difficult to quantify by examining only the categories. Further, such relationships may change over time as economics change.

In one embodiment, factor analysis (327) is performed to reduce redundancy and/or associations between variables (e.g., 313, 315). The factor analysis (327) identifies definitions (331) of factors, each of which represents a combination of variables (e.g., 313, 315).

In one embodiment, the factor is a linear combination of a plurality of aggregated metrics (e.g., variables (313, 315)) determined for various domains (e.g., merchant or merchant category, product or product category). Once the relationship between the factors and the aggregated metrics is determined by factor analysis, the values of the factors can be determined from a linear combination of the aggregated metrics and used in a transaction profile (127 or 341) to provide information about the behavior of the entity (e.g., account, person, family) represented by the entity ID.

Once the factor definitions (331) are obtained from the factor analysis (327), the factor definitions (331) may be applied to the variable values (321) to determine the factor values (344) of the aggregated expense profile (341). Because of the reduction in redundancy and associations among the factors, the number of factors is typically much smaller than the number of original variables (e.g., 313, 315). As such, the factor value (344) represents a concise summary of the original variables (e.g., 313, 315).

For example, there may be thousands of variables relating to frequency and amount spent for different merchant categories; while factor analysis (327) may reduce the number of factors to less than a hundred (or even less than twenty). In one example, a twelve factor solution is obtained, which allows thousands of raw variables to be combined using twelve factors (313, 315); as such, spending behavior for thousands of merchant categories may be aggregated by twelve factor values (344). In one embodiment, each factor is a combination of at least four variables; whereas typical variables contribute to more than one factor.

In one example, hundreds or thousands of transaction records (301) for a cardholder are converted into hundreds or thousands of variable values (321) for various merchant categories, which are aggregated (335) by factor definition (331) and cluster definition (333) into twelve factor values (344) and one or two cluster IDs (e.g., 343). The aggregated data can be easily interpreted by a person to determine the spending behaviour of the cardholder. The user (101) can easily specify the resulting spending behavior requirement (e.g., query the client's segment, or request the orientation of the client's segment) based on the factor values (344) and cluster ID. The reduced size of the aggregated data reduces the data communication bandwidth requirements for communicating the spending behavior of the cardholder over the network connection and may simplify the processing and utilization of data representing the spending behavior of the cardholder.

In one embodiment, the behavior and characteristics of the clusters are studied to identify descriptions of the types of representative entities found in each cluster. Clusters may be named based on the type of representative entity to allow one of ordinary skill to easily understand the typical behavior of a cluster.

In one embodiment, the behavior and characteristics of the factors are also studied to identify the dominant aspect of each factor. Clusters may be named based on the dominant aspect to allow the average person to easily understand the meaning of the factor values.

In fig. 2, the aggregate spending profile (341) for the entity represented by the entity ID (e.g., 322) includes a cluster ID (343) and a factor value (344) determined based on the cluster definition (333) and the factor definition (331). The aggregated spending profile (341) may also include other statistical parameters, such as diversity index (342), channel distribution (345), category distribution (346), zip code (347), and so forth, as discussed further below.

In one embodiment, the diversity index (342) may include an entropy value and/or a kini coefficient to represent the diversity in spending by the entity represented by the entity ID (322) across different regions (e.g., different business categories (e.g., 306)). When the diversity index (342) indicates that the diversity of the spending data is below a predetermined threshold level, the variable value (e.g., 323, 324.., 325) of the corresponding entity ID (322) may be excluded from the cluster analysis (329) and/or the factor analysis (327) due to a lack of diversity. When the diversity index (342) of the aggregated spending profile (341) is below a predetermined threshold, the factor value (344) and the cluster ID (343) may not accurately represent the spending behavior of the corresponding entity.

In one embodiment, the channel profile (345) includes a set of percentage values that indicate the percentage of money spent on different channels of purchase (e.g., online, over the phone, at a retail store, etc.).

In one embodiment, the category distribution (346) includes a set of percentage values that indicate the percentage of money spent in different super categories (311). In one embodiment, thousands of different merchant categories (e.g., 306) are represented in the transaction record (301) by a Merchant Category Code (MCC) or North American Industrial Classification System (NAICS) code. These business categories (e.g., 306) are classified or merged into fewer than one hundred super categories (or fewer than twenty). In one example, based on domain knowledge, fourteen super categories are defined.

In one embodiment, the aggregated spending profile (341) includes aggregated metrics (e.g., frequency, average spending amount) determined for a set of predefined, mutually exclusive merchant categories (e.g., super category (311)). Each of the super merchant categories represents a type of product or service that a customer may purchase. The transaction profile (127 or 341) may include aggregated metrics for each of the set of mutually exclusive merchant categories. Aggregated metrics determined for pre-defined, mutually exclusive business categories may be used in a transaction profile (127 or 341) to provide information about the behavior of the respective entity (e.g., account, person, or family).

In one embodiment, the zip code (347) in the aggregated spending profile (341) represents the prevailing geographic area in which the spending associated with the entity ID (322) occurred. Alternatively or in combination, the aggregated spending profile (341) may include a distribution of transaction amounts over a set of zip codes that account for a majority (e.g., 90%) of the transaction or transaction amount.

In one embodiment, factor analysis (327) and cluster analysis (329) are used to aggregate spending behavior across various regions, such as different merchants, different products and/or services, different consumers, and so forth, as described by merchant category (306). The aggregated spending profile (341) may include more or fewer fields than those shown in fig. 2. For example, in one embodiment, the aggregate spending profile (341) also includes an aggregate spending amount over a period of time (e.g., the last twelve months); in another embodiment, the aggregated spending profile (341) does not include a category distribution (346); in yet another embodiment, the aggregated spending profile (341) may include a set of distance measures to the center of gravity of the cluster. The distance metric may be defined based on a variable value (323, 324.., 325) or based on a factor value (344). The factor value of the center of gravity of a cluster may be estimated based on the entity ID (e.g., 322) closest to the center of gravity in the corresponding cluster.

Other variables may be used in place of, or in addition to, the variables (311, 313, 315) shown in fig. 2. For example, the aggregate spending profile (341) may be generated using variables that measure shopping radius/distance from the account holder's primary address to the merchant location for offline shopping. When such variables are used, transaction patterns can be identified based at least in part on the clusters and according to shopping radius/distance and geographic area. Similarly, the factor definition (331) may include consideration of shopping radius/distance. For example, transaction records may be aggregated based on shopping radius/distance and/or extent of geographic area (301). For example, factors that naturally combine geographic regions may be determined based on associations of consumption patterns in various geographic regions using factor analysis.

In one embodiment, the aggregating (317) may involve a determination of a deviation from a trend or pattern. For example, an account has made a certain number of purchases in a merchant week for the last six months. However, the number of purchases over the past two weeks is less than the average per week. The measure of deviation from a trend or pattern may be used (e.g., as a parameter in a transaction profile (127 or 341), or in a variable definition (309) for factor analysis (327) and/or cluster analysis) to define behavior of an account, person, family, and so forth.

FIG. 3 illustrates a method of generating an aggregated spending profile, according to one embodiment. In FIG. 3, a computational model is built (351) for variables (e.g., 311, 313, and 315). In one embodiment, the variables are defined in a manner that captures certain aspects of spending statistics, such as frequency, amount, and so forth.

In fig. 3, data from related accounts is combined (353). For example, when a change has occurred to a cardholder's account number within a period of time under analysis, transaction records (301) under different account numbers for the same cardholder are combined under one account number representing the cardholder. For example, when performing analysis at a person's level (or at a family level, business level, social group level, city level, or regional level), the transaction records (301) in different accounts for a person (or at a family, business, social group, city, or region) may be combined under one entity ID (322) representing the person (or at a family, business, social group, city, or region).

In one embodiment, recurring/installment transactions are combined (355). For example, multiple monthly payments may be combined and treated as only one purchase.

In fig. 3, account data is selected 357 based on a set of conditions related to activity, consistency, diversity, etc.

For example, when a cardholder uses a credit card to purchase only gasoline, the diversity of the cardholder's transactions is low. In such cases, transactions in the cardholder's account may not be statistically meaningful to indicate the consumption patterns of the cardholder in the various merchant categories. As such, in one embodiment, if the diversity of transactions associated with the entity ID (322) is below a threshold, the variable values (e.g., 323, 324.., 325) corresponding to the entity ID (322) are not used in the cluster analysis (329) and/or the factor analysis (327). Diversity may be checked based on a diversity index (342) (e.g., entropy or kini coefficient), or based on counting different merchant categories in a transaction associated with the entity ID (322); and when the count of the different merchant categories is less than a threshold (e.g., 5), the transactions associated with the entity ID (322) are not used in the cluster analysis (329) and/or factor analysis (327) due to a lack of diversity.

For example, when a cardholder only uses a credit card infrequently (e.g., when running out of cash), the limited transactions of the cardholder may not be statistically meaningful in indicating the spending behavior of the cardholder. As such, in one embodiment, when the number of transactions associated with the entity ID (322) is below a threshold, the variable value (e.g., 323, 324.., 325) corresponding to the entity ID (322) is not used in the cluster analysis (329) and/or the factor analysis (327).

For example, when the cardholder uses a credit card for only a portion of a time period under analysis, the transaction record (301) for that time period may not reflect consistent behavior of the cardholder over the entire time period. The consistency can be checked in various ways. In one example, if the total number of transactions is zero within the first and last months of the time period under analysis, the transactions associated with the entity ID (322) are not coherent for that time period, and as such, are not used in the cluster analysis (329) and/or the factor analysis (327). Other conditions may be developed to detect inconsistencies in the transaction.

In fig. 3, a computational model (e.g., as represented by variable definitions (309)) is applied (359) to the remaining account data (e.g., transaction records (301)) to obtain data samples of the variables. Data points associated with entities other than those whose transactions fail to meet minimum requirements for activity, consistency, diversity, etc., are used in factor analysis (327) and cluster analysis (329).

In fig. 3, data samples (e.g., variable values (321)) are used to perform (361) factor analysis (327) to identify factor solutions (e.g., factor definitions (331)). The factor solution may be adjusted (363) to improve similarity among the factor values of different sets of transaction data (109). For example, the factor definition (331) may be applied to transactions within a time period under analysis (e.g., the past twelve months) and separately applied to transactions in a previous time period (e.g., the twelve months prior to the past twelve months) to obtain two sets of factor values. The factor definition (331) may be adjusted to improve the correlation between the two sets of factor values.

The data samples may also be used to perform (365) a cluster analysis (329) to identify a clustering solution (e.g., a cluster definition (333)). The clustering solution may be adjusted (367) based on different sets of transactional data (109) to improve similarity in cluster identification. For example, the cluster definition (333) may be applied to transactions within a time period under analysis (e.g., the past twelve months) and separately applied to transactions in a previous time period (e.g., the twelve months prior to the past twelve months) to obtain two sets of cluster identifications for various entities. The cluster definition (333) may be adjusted to improve the correlation between the two sets of cluster identifications.

In one embodiment, the number of clusters is determined from a cluster analysis. For example, a set of cluster seeds may be initially identified and used to run a known clustering algorithm. The size of the data points in the cluster is then examined. When a cluster contains less than a predetermined number of data points, the cluster can be deleted to rerun the cluster analysis.

In one embodiment, normalized entropy is added to the clustering solution to obtain improved results.

In one embodiment, human understandable features of the factors and clusters are identified (369) to name the factors and clusters. For example, when a cluster's spending behavior looks like an internet loyalty behavior, the cluster may be named "internet loyalty" so that a cardholder's spending preferences and patterns can be easily perceived if the cardholder is found in the "internet loyalty" cluster.

In one embodiment, the factor analysis (327) and cluster analysis (329) are performed periodically (e.g., once a year, or once six months) to update the factor definition (331) and cluster definition (333), which may change over time as economic and social changes.

In fig. 3, the transaction data (109) is aggregated (371) using factor solutions and cluster solutions to generate an aggregated spending profile (341). The aggregated spending profile (341) may be updated more frequently than factor solutions and clustering solutions when new transaction data (109) is available. For example, the aggregated spending profile (341) may be updated quarterly or monthly.

Various adjustments may be made to the variables (e.g., 313, 315) used for the factor analysis (327) and the cluster analysis (329). For example, the transaction records (301) may be filtered, weighted, or constrained according to different rules to improve the capacity of the aggregated metrics.

For example, in one embodiment, variables (e.g., 313, 315) are normalized and/or normalized (e.g., using statistical means, and/or variances).

For example, by filtering and weighting, variables of the aggregated metrics (e.g., 313, 315) may be adjusted to predict future trends in spending behavior (e.g., for ad selection), identify abnormal behavior (e.g., for fraud prevention), or identify changes in consumption patterns (e.g., for ad audience metrics), among others. The aggregated metrics, factor values (344), and/or cluster IDs (343) generated from the aggregated metrics may be used in transaction profiles (127 or 341) to define the behavior of accounts, individuals, households, and so forth.

In one embodiment, the transactional data (109) may be aged to provide more recent data with more weight than older data. In other embodiments, the transaction data (109) is aged upside down. In a further embodiment, the transaction data is adjusted seasonally (109).

In one embodiment, variables (e.g., 313, 315) are constrained to eliminate extreme outliers. For example, the minimum and maximum values of the amount spent (315) may be constrained based on the values of some percentiles (e.g., one percentile value as minimum and 99 percentile value as maximum) and/or some predetermined values. In one embodiment, the spending frequency variable is constrained based on the value of certain percentiles and the median value (313). For example, the minimum value of the spending frequency variable (313) may be constrained to P₁-k×(M-P₁) Wherein P is₁Is a percentile value, M is a median value, and k is a predetermined constant (e.g., 0.1). For example, the maximum value of the spending frequency variable (313) may be constrained to P₉₉+a×(P₉₉-M), wherein P₉₉Is a 99 percentile value, M is a median value, and k is a predetermined constant (e.g., 0.1).

In one embodiment, variable pruning is performed to reduce the number of variables (e.g., 313, 315) that have a smaller impact on the clustering solution and/or the factor solution. For example, for cluster analysis (329), variables with a standard variation less than a predetermined threshold (e.g., 0.1) may be discarded. For example, an analysis of variance (ANOVA) may be performed to identify and remove variables that are not more meaningful than a predetermined threshold.

The aggregated spending profile (341) may provide information about spending activity for various application domains, such as marketing, fraud detection and prevention, credit value assessment, credit rating, and the like,

For example, clustering can be used to optimize offers for various groups within an advertising campaign. Using factors and clusters to target advertisements may increase the speed of generating a targeting model. For example, using variables based on factors and clustering (thus, omitting the necessity of using a large number of commitment variables) can improve the predictive model and increase the efficiency of targeting by reducing the number of variables examined. Variables formed based on factors and/or clusters can be used with other variables to build predictive models based on spending behavior.

In one embodiment, the aggregated spending profile (341) may be used to monitor risk in transactions. For each entity, the factor value is typically consistent over a certain period of time. Sudden changes in the values of some factors may indicate a change in financial status, or an account theft. A model formed using factors and clusters may be used to identify a series of transactions that do not follow the standard patterns specified by factor values (344) and/or cluster IDs (343). The potential ability to pay-free can be predicted by analyzing the variation of the factor values over a certain period of time; while significant changes in spending behavior may be detected to deter and/or prevent fraudulent activity.

For example, the factor values (344) may be used in regression models and/or neural network models to detect certain behaviors or patterns. Since the factors are relatively non-collinear, the factors may function well as independent variables. For example, factors and clusters may be used as independent variables in the tree model.

For example, a proxy account may be selected for use in constructing a quasi-control group. For example, for a given account a in a cluster, the account B in the same cluster that is closest to account a may be selected as the proxy account for account B. Proximity may be determined by certain values in the aggregated spending profile (341), such as factor values (344), category distributions (346), and so forth. For example, the distance between accounts may be compared using Euclidean distances defined based on a set of values from the aggregated spending profile (341). Once identified, the proxy account may be used to reduce or omit bias in the metric. For example, to determine the effectiveness of an advertisement, the consumption pattern response of account A, on which the advertisement is presented, may be compared to the consumption pattern response of account B, on which the advertisement is not presented.

For example, the aggregated spending profile (341) may be used for segmentation and/or filtering analysis, such as selecting cardholders with similar spending behavior identified by factors and/or clusters for targeted advertising campaigns, and selecting and determining a set of merchants (e.g., offers for bundling) that may potentially be marketed to cardholders originating from a given cluster. For example, a query interface may be provided to allow a query to identify a targeted population based on a set of conditions formed using the values of the clusters and factors.

For example, the aggregated spending profile (341) may be used in spending comparison reports, comparing the population of interest segments to the overall population, determining how different the cluster distributions and average factor values differ, and constructing reports for merchants and/or accounts for benchmarking purposes. For example, reports may be generated from the clusters in an automated manner for the merchant. For example, the aggregated spending profile (341) may be used in a geographic report by identifying the geographic area where the cardholder shops most frequently and comparing the primary spending location to the cardholder's home location.

In one embodiment, the profile generator (121) provides affinity relationship data in the transaction profile (127) so that the transaction profile (127) can be shared with business partners without compromising privacy of the user (101) and transaction details.

For example, in one embodiment, the profile generator (121) will identify clusters of entities (e.g., accounts, cardholders, families, businesses, cities, areas, etc.) based on consumption patterns of the entities. The clusters represent entity segments identified based on consumption patterns of entities reflected in the transaction data (109) or transaction records (301).

In one embodiment, the clusters correspond to cells or regions in a mathematical space containing the entities of the respective groups. For example, a mathematical space representing features of a user (101) may be divided into clusters (cells or regions). For example, the cluster analysis (329) may identify one of the clusters in the cell or region that contains the entity ID (e.g., 322) in a space having multiple dimensions corresponding to the variables (e.g., 313 and 315). For example, the clusters may also be identified as cells or regions in the space defined by the factors using the factor definitions (331) generated from the factor analysis (327).

In one embodiment, parameters in the spending profile (341) for aggregation may be used to define segments or clusters of entities. For example, the value of the cluster ID (343) and the range of the set of factor values (344) and/or other values may be used to define the segment.

In one embodiment, a set of clusters is normalized to represent the preferences of an entity in various groups of certain products or services. For example, a standardized set of clusters may be formed for people who shop, for example, at home improvement stores. Cardholders in the same cluster have similar spending behavior.

In one embodiment, trends or likelihoods that a user (101) is in a particular cluster (i.e., the user's affinity for a cell) may be characterized based on past purchases using a value. The same user (101) may have different affinity values for different clusters.

For example, a set of affinity values may be calculated for an entity based on the transaction record (301) to indicate the proximity or preference of the entity to the set of standardized clusters. For example, a cardholder having a first value representing an affinity of the cardholder to a first cluster may have a second value representing an affinity of the cardholder to a second cluster. For example, if a consumer purchases a large number of electronic devices, the affinity value of the consumer to the cluster of electronic devices is relatively high.

In one embodiment, other indicators are formed across the community of merchants and cardholder behavior and provided in a profile (e.g., 127 or 341) to represent the risk of the transaction.

In one embodiment, if the user (101) is shown in another cell, the relationship of a pair of values from two different clusters provides an indication of the likelihood that the user (101) is in one of the two cells. For example, if the likelihood of the user (101) purchasing each of the two types of products is known, the score may be used to determine the likelihood of the user (101) purchasing one of the two types of products if the user (101) is known to be interested in the other type of product. In one embodiment, a graph of the clustered values is used in a configuration file (e.g., 127 or 341) to characterize spending behavior of a user (101) (or other type of entity, such as a family, company, neighborhood, city, or other type of group defined by other overall parameters (such as time of day, etc.)).

In one embodiment, the clustering and affinity information is standardized to allow sharing between business partners such as transaction processing organizations, search providers, and marketers. Purchase statistics and search statistics are generally described in different ways. For example, the purchase statistics are based on the merchant, merchant category, SKU number, product description, and so forth; and the search statistics are based on the search terms. Once the clusters are normalized, the clusters can be used to link purchase information based on merchant category (and/or SKU number, product description) with search information based on search terms. As such, search preferences and purchase preferences may be mapped to one another.

In one embodiment, purchase data and search data (or other third party data) are associated based on a mapping to standardized clusters (cells or segments). The purchase data and the search data (or other third party data) may be used together to provide benefits or offers (e.g., coupons) to the consumer. For example, standardized clusters may be used as marketing tools that provide relevant benefits to consumers within or associated with a common cluster, including coupons, billing points, and the like. For example, the data exchange device may obtain cluster data based on consumer search engine data and actual payment transaction data to identify similar groups of individuals that may respond positively to particular types of benefits, such as coupons and loyalty points.

Details regarding aggregated expense profiles (341) in one embodiment are provided in U.S. patent application serial No.12/777,173, entitled Systems and Methods to investment Transaction Data, filed on 10/2010, which is incorporated herein by reference.

Portal based on transaction data

In fig. 1, a transaction terminal (105) initiates a transaction for a user (101) (e.g., a customer) for processing by a transaction processing device (103). The transaction processing device (103) processes the transaction and stores transaction data (109) relating to the transaction together with account data (111) such as an account profile of an account of the user (101). The account data (111) may also include data about collecting the user (101) from an issuer or merchant, and/or other sources such as social networks, credit consulting companies, information provided by merchants, address information, and the like. In one embodiment, the transaction may be initiated by the server (e.g., based on a stored calendar of recurring payments).

Over a period of time, the transaction processing device (103) accumulates transaction data (109) for different users (e.g., 101) from transactions initiated on different transaction terminals (e.g., 105). As such, the transaction data (109) includes information about purchases made by various users (e.g., 101) at various times via different shopping options (e.g., online purchases, offline purchases from retail stores, mail order, orders over the phone, etc.).

In one embodiment, the accumulated transaction data (109) and corresponding account data (111) are used to generate intelligent information about purchasing behavior, patterns, preferences, trends, frequency, amount, and/or trends of a user (e.g., 101) as an individual or as a member of a group. The intelligent information may then be used to generate, identify, and/or select targeted advertisements for presentation to the user (101) at the point of interaction (107), during the transaction, after the transaction, or when other opportunities arise.

FIG. 4 illustrates a system for providing information based on transaction data (109), according to one embodiment. In fig. 4, a transaction processing device (103) is coupled between an issuer processor (145) and a transferee processor (147) to facilitate authorization and settlement of transactions between a consumer account (146) and a merchant account (148). The transaction processing device (103) records transactions in a data repository (149). The portal (143) is coupled to the data repository (149) to provide information based on transaction records (301) such as transaction profiles (127) or aggregate spending profiles (341). The portal (143) may be implemented as a Web portal, telephone gateway, file/data server, or the like.

In one embodiment, the portal (143) is configured to receive a query from the profile selector (129), the ad selector (133), and/or a third party identifying the search criteria and, in response, provide the transaction-based intelligence requested by the query.

For example, in one embodiment, the query will specify that a plurality of account holders request portals (143) provide account holders' transaction profiles (127) in a batch mode.

For example, in one embodiment, the query will identify the user (101) requesting the user's (101) user-specific profile (131) or aggregate spending profile (341). The user (101) may be identified using account data (111) such as an account number (302) or user data (125) such as a browser cookie ID, IP address, and the like.

For example, in one embodiment, the query will identify a retail location; and the portal (143) will provide a profile (e.g., 341) summarizing the aggregate spending patterns for users who have made purchases at the retail location over a period of time.

For example, in one embodiment, the query will identify a geographic location; and the portal (143) will provide a profile (e.g., 341) that aggregates aggregated spending patterns for users who have arrived or are expected to visit the geographic location over a period of time (e.g., determined or predicted based on the location of the user's interaction point (e.g., 107)).

For example, in one embodiment, the query will identify a geographic region; while the portal (143) will provide a profile (e.g., 341) summarizing the aggregate spending patterns for users residing in the geographic area (e.g., as determined by the account data (111)), for users who have conducted transactions within the geographic area over a period of time (e.g., as determined by the location of the transaction terminal (e.g., 105) used to process the transactions).

In one embodiment, the portal (143) is configured to register certain users (101) to participate in various programs, such as loyalty programs that provide rewards and/or offers to the users (101).

In one embodiment, the portal (143) will register the interests of the user (101) or obtain permission from the user (101) to collect further information about the user (101), such as data capturing purchasing details, online activity, etc.

In one embodiment, a user (101) may register through an account opening row; and the registration data in the consumer account (146) may be propagated to the data repository (149) upon approval from the user (101).

In one embodiment, the portal (143) will register with the merchant and provide services and/or information to the merchant.

In one embodiment, the portal (143) will receive information from a third party such as a search engine, merchant, website, and the like. Third party data may be associated with transaction data (109) to identify relationships between purchases and other events, such as searches, news announcements, meetings, and the like, and to improve predictive capabilities and accuracy.

In fig. 4, the consumer account (146) is under the issuer processor (145). The consumer account (146) may be owned by an individual, or an organization such as a business, school, etc. The consumer account (146) may be a credit account, a debit account, or a stored value account. The issuer may provide the consumer (e.g., user (101)) with an account identification device (141) to identify the consumer account (146) using the account information (142). In one embodiment, the respective consumer of the account (146) may be called an account holder or cardholder even if the consumer is not physically issued a card or account identification device (141). The issuer processor (145) will charge a fee from the consumer account (146) to pay for the purchase.

In one embodiment, the account identification device (141) is a plastic card having a magnetic stripe that stores account information (142) identifying the consumer account (146) and/or the issuer processor (145). Alternatively, the account identification device (141) is a smart card having an integrated circuit chip that stores at least account information (142). In one embodiment, the account identification device (141) comprises a mobile phone with an integrated smart card.

In one embodiment, the account information (142) is printed or embossed on the account identification device (141). The account information (142) may be printed as a barcode to allow the transaction terminal (105) to read the information through an optical scanner. The account information (142) may be stored in a memory of the account identification device (141) and configured to be read by wireless, contactless communication, such as near field communication by magnetic field coupling, infrared communication or radio frequency communication. Alternatively, the transaction terminal (105) may require contact with an account identification device (141) to read the account information (142) (e.g., by reading the card's magnetic stripe using a magnetic stripe reader).

In one embodiment, the transaction terminal (105) is configured to transmit an authorization request message to the transferee processor (147). The authorization request includes account information (142), a payment amount, and information about the merchant (e.g., an indication of a merchant account (148)). The transferee processor (147) requests the transaction processing device (103) to process the authorization request based on the account information (142) received in the transaction terminal (105). The transaction processing device (103) routes the authorization request to the issuer processor (145) and processes and responds to the authorization request when the issuer processor (145) is unavailable. The issuer processor (145) will determine whether to authorize the transaction based at least in part on the balance of the consumer account (146).

In one embodiment, the transaction processing device (103), the issuer processor (145), and the transferee processor (147) may each include a subsystem that identifies risk in the transaction and may decline the transaction based on the risk assessment.

In one embodiment, the account identification device (141) includes security functions to prevent unauthorized use of the consumer account (146), such as a logo to show the authenticity of the account identification device (141), encryption to protect account information (142), and the like.

In one embodiment, the transaction terminal (105) is configured to interact with an account identification device (141) to obtain account information (142) identifying a consumer account (146) and/or an issuer processor (145). The transaction terminal (105) is in communication with a transferee processor (147) that controls a merchant account (148) of the merchant. The transaction terminal (105) may communicate with the transferee processor (147) through a data communication connection, such as a telephone connection, an internet connection, and the like. The transferee processor (147) will accept payment to the merchant account (148) on behalf of the merchant.

In one embodiment, the transaction terminal (105) is a POS terminal of a conventional, offline, "physical" retail store. In another embodiment, the transaction terminal (105) is an online server that receives account information (142) for a consumer account (146) from the user (101) over a Web connection. In one embodiment, a user (101) may provide account information by telephone, through verbal communication with a representative of the merchant; and the representative enters account information (142) into the transaction terminal (105) to initiate the transaction.

In one embodiment, account information (142) may be directly entered into the transaction terminal (105) to make payment from the customer account (146) without physically presenting the account identification device (141). When a transaction is initiated without physically presenting the account identification device (141), the transaction is classified as a "card not present" (CNP) transaction.

In one embodiment, the issuer processor (145) may control more than one consumer account (146); the transferee processor (147) may control more than one merchant account (148); and the transaction processing device (103) is coupled between a plurality of issuer processors (e.g., 145) and a plurality of transferee processors (e.g., 147). An entity (e.g., a bank) may operate an issuer processor (145) and a transferee processor (147).

In one embodiment, the transaction processing device (103), the issuer processor (145), the acquirer processor (147), the transaction terminal (105), the portal (143), and other devices and/or services that access the portal (143) are connected together through a communication network such as a local area network, a cellular telecommunications network, a wireless wide area network, a wireless local area network, an intranet, and the internet. In one embodiment, a dedicated communication channel is used between the transaction processing device (103) and the issuer processor (145), between the transaction processing device (103) and the acquirer processor (147), and/or between the portal (143) and the transaction processing device (103).

In one embodiment, the transaction processing device (103) uses a data repository (149) to store records about transactions, such as transaction records (301) or transaction data (109). In one embodiment, the transaction processing device (103) comprises a powerful computer, or a cluster of computers functioning as a unit controlled by instructions stored on a computer readable medium.

In one embodiment, the transaction processing device (103) is configured to support and provide authorization services, exception file services, and clearing and settlement services. In one embodiment, the transaction processing device (103) has a subsystem that processes authorization requests and another subsystem that performs clearing and settlement services.

In one embodiment, the transaction processing device (103) is configured to process different types of transactions, such as credit card transactions, debit card transactions, prepaid card transactions, and other types of commercial transactions.

In one embodiment, a transaction processing device (103) facilitates communication between an issuer processor (145) and a transferee processor (147).

In one embodiment, the transaction processing device (103) is coupled to a portal (143) (and/or profile selector (129), advertisement selector (133), media controller (115)) to charge a fee for providing transaction-based intelligent information and/or advertising services.

For example, in one embodiment, the system shown in FIG. 1 is configured to deliver advertisements to interaction points (107) of a user (101) based on transaction-based intelligence information; and the transaction processing device (103) is configured to charge an advertisement fee to an advertiser's account in communication with an issuer processor that controls the advertiser's account. The advertising fee may be charged in response to presentation of the advertisement, or in response to completion of a predetermined number of presentations, or in response to a transaction resulting from presentation of the advertisement. In one embodiment, the transaction processing device (103) is configured to charge a periodic fee (e.g., monthly, annual) to an advertiser's account in communication with a corresponding issuer processor similar to the issuer processor (145) of the consumer account (146).

For example, in one embodiment, the portal (143) is configured to provide transaction-based intelligence information in response to a query received in the portal (143). The portal (143) will identify the requesting party (e.g., by authentication, or address of the requesting party) and instruct the transaction processing device (103) to charge a fee to the corresponding requesting party's consumer account (e.g., 146) for the transaction-based intelligence. In one embodiment, a fee is charged to the requestor's account in response to placement of the intelligent information through the portal (143). In one embodiment, the requestor's account is charged a periodic subscription fee for access to the portal's (143) query capabilities.

In one embodiment, the information services provided by the system shown in FIG. 1 include multiple parties, such as an entity operating the transaction processing device (103), an entity operating the advertisement data (135), an entity operating the user tracker (113), an entity operating the media controller (115), and so forth. The transaction processing device (103) is used to generate transactions that settle fees, charges, and/or allocate revenues using the accounts of the respective parties. In one embodiment, the account information for the parties is stored in a data store (149) coupled to the transaction processing device (103). In some embodiments, separate billing engines are used to generate transactions to settle fees, charges, and/or allocate revenues.

In one embodiment, the transaction terminal (105) is configured to submit an authorized transaction to the transferee processor (147) for settlement. The amount of settlement may be different from the amount specified in the authorization request. A transaction processing device (103) is coupled between the issuer processor (145) and the acquirer processor (147) to facilitate clearing and settlement of transactions. Clearing includes an exchange of financial information between the issuer processor (145) and the transferor processor (147); and settlement includes the exchange of funds.

In one embodiment, the issuer processor (145) will provide funds to make payment on behalf of the consumer account (146). The transferee processor (147) will receive funds on behalf of the merchant account (148). An issuer processor (145) and a transferee processor (147) communicate with the transaction processing device (103) to coordinate the transfer of funds for the transaction. In one embodiment, the funds are transferred electronically.

In one embodiment, the transaction terminal (105) may submit the transaction directly for settlement without separately submitting an authorization request.

In one embodiment, the portal (143) provides a user interface that allows the user (101) to organize transactions with one or more open banks in the user's one or more consumer accounts (146). The user (101) may organize transactions using information and/or categories identified in the transaction record (301), such as merchant category (306), transaction date (303), amount of money (304), and so forth. Examples and techniques in one embodiment are provided in U.S. patent application serial No.11/378,215, entitled "Method and System for managing purification information," filed on 16.3.2006, which is hereby incorporated by reference.

In one embodiment, the portal (143) provides transaction-based statistics, such as indicators for retail spending monitoring, indicators for merchant benchmarking, indicators of industry/market segments, consumption patterns, and so forth. Further examples may be found in U.S. patent application serial No.12/191,796, entitled "merchat bearing marking Tool," assigned publication No.2009/0048884, 14/2008, and provisional U.S. patent application serial No.61/258,403, entitled "Systems and Methods for Analysis of Transaction Data," assigned 5/11/2009, which are hereby incorporated by reference.

Transaction terminal

FIG. 5 illustrates a transaction terminal according to one embodiment. In fig. 5, the transaction terminal (105) is configured to interact with the account identification device (141) to obtain account information (142) about the consumer account (146).

In one embodiment, the transaction terminal (105) includes a memory (167) coupled to a processor (151), the processor (151) controlling the operation of a reader (163), an input device (153), an output device (165), and a network interface (161). The memory (167) may store instructions and/or data such as an identification associated with the merchant account (148) for the processor (151).

In one embodiment, the reader (163) comprises a magnetic stripe reader. In another embodiment, the reader (163) comprises a contactless reader, such as a Radio Frequency Identification (RFID) reader, a Near Field Communication (NFC) device configured to read data by magnetic field coupling (according to ISO standard 14443/NFC), a bluetooth transceiver, a WiFi transceiver, an infrared transceiver, a laser scanner, or the like.

In one embodiment, the input device (153) includes a button that can be used to enter account information (142) directly into the transaction terminal (105) without the physical presence of the account identification device (141). The input device (153) may be configured to provide further information, such as a Personal Identification Number (PIN), password, zip code, etc., to initiate a transaction, which may be used to access the account identification device (141) or in conjunction with account information (142) obtained from the account identification device (141).

In one embodiment, the output device (165) may include a display, speaker, and/or printer to present information, such as the results of the authorization request, receipt of the transaction, advertisements, and the like.

In one embodiment, the network interface (161) is configured to communicate with the transferee processor (147) through a telephone connection, an internet connection, or a dedicated data communication channel.

In one embodiment, the instructions stored in the memory (167) are configured to cause the transaction terminal (105) to send an authorization request message to the transferee processor (147) to initiate the transaction. The transaction terminal (105) may or may not send a separate request for clearing and settlement of the transaction. The instructions stored in the memory (167) are also configured to cause the transaction terminal (105) to perform other types of functions discussed in this specification.

In one embodiment, the transaction terminal (105) may have fewer components than those shown in fig. 5. For example, in one embodiment, the transaction terminal (105) is configured for "cardless" transactions; while the transaction terminal (105) does not have a reader (163).

In one embodiment, the transaction terminal (105) may have more components than those shown in fig. 5. For example, in one embodiment the transaction terminal (105) is an ATM machine that includes components that dispense cash under certain conditions.

Account identification device

Figure 6 illustrates an account identification device according to one embodiment. In fig. 6, account identification device (141) is a device that carries account information (142) identifying a consumer account (146).

In one embodiment, the account identification device (141) includes a memory (167) coupled to a processor (151), the processor (151) controlling the operation of a communication device (159), an input device (153), an audio device (157), and a display device (155). The memory (167) may store instructions and/or data such as account information (142) associated with the consumer account (146) for the processor (151).

In one embodiment, the account information (142) includes an identifier identifying an issuer among the plurality of issuers (and thus, the issuer processor (145)), and an identifier identifying a consumer account among the plurality of consumer accounts controlled by the issuer processor (145). The account information (142) may include an expiration date of the account identification device (141), a name of a consumer holding the consumer account (146), and/or an identifier identifying the account identification device (141) among a plurality of account identification devices associated with the consumer account (146).

In one embodiment, the account information (142) may also include loyalty program accounts, accumulated rewards of the customer in the loyalty program, the address of the customer, the balance of the customer's account (146), traffic information (e.g., subway or train-moon tickets), access information (e.g., access indicia), and/or customer information (e.g., name, date of birth), among others.

In one embodiment, the memory includes non-volatile memory, such as a magnetic stripe, memory chip, flash memory, Read Only Memory (ROM) to store account information (142).

In one embodiment, the information stored in the memory (167) of the account identification device (141) may also take the form of data tracks traditionally associated with credit cards. Such tracks include track 1 and track 2. Track 1 ("international air transport association") stores more information than track 2 and contains the cardholder's name and account number and other discretionary data. Track 1 is sometimes used by the airline when making reservations with credit cards. Track 2 ("american banking association") is currently the most commonly used and is read by ATM and credit card detectors. The ABA (American banking Association) designs the specification for track 1 and the bank complies with the specification. It contains the cardholder's account number, encrypted PIN, and other discretionary data.

In one embodiment, the communication device (159) includes a semiconductor chip to enable a transceiver to communicate with the reader (163) and an antenna to provide and/or receive wireless signals.

In one embodiment, the communication device (159) is configured to communicate with a reader (163). The communication device (159) may include a transmitter to transmit the account information (142) via wireless transmission, such as radio frequency signals, magnetic coupling or infrared, bluetooth or WiFi signals, and so forth.

In one embodiment, the account identification device (141) is in the form of a mobile phone, Personal Digital Assistant (PDA), or the like. The input device (153) may be used to provide input to the processor (151) to control operation of the account identification device (141), while the audio device (157) and display device (155) may present status information and/or other information such as advertisements or offers.

In one embodiment, the communication device (159) may access account information (142) stored on the memory (167) without going through the processor (151).

In one embodiment, the account identification device (141) has fewer components than those shown in FIG. 6. For example, in one embodiment, the account identification device (141) is free of an input device (153), an audio device (157), and a display device (155); in yet another embodiment, the account identification device (141) has no components (151) and 159).

For example, in one embodiment, the account identification device (141) presents a credit card, smart card, or consumer appliance with optional features such as a magnetic stripe or smart card.

One example of an account identification device (141) is a magnetic strip attached to a plastic substrate in the form of a card. The magnetic stripe is used as a memory (167) for an account identification device (141) that provides account information (142). Consumer information such as account number, expiration date, and consumer name may be printed or embossed on the card. In one embodiment, the semiconductor chip implementing the memory (167) and the communication device (159) may also be embedded in a plastic card to provide account information (142). In one embodiment, the account identification device (141) has a semiconductor chip but no magnetic stripe.

In one embodiment, the account identification device (141) is integrated with a security device such as a currency card, Radio Frequency Identification (RFID) tag, social security card, transponder, or the like.

In one embodiment, the account identification device (141) is a handheld, compact device. The account identification device (141) in one embodiment has a size suitable for being placed in a consumer's wallet or pocket.

Some examples of account identification devices (141) include credit cards, debit cards, stored value instruments, payment cards, gift cards, smart media cards, payroll cards, health care cards, wristbands, key fob instruments, supermarket discount cards, transponders, and machine-readable media containing account information (142).

Interaction point

In one embodiment, the interaction point (107) will provide an advertisement to the user (101) or provide information derived from the transactional data (109) to the user (101).

In one embodiment, the advertisement is a marketing interaction that may include an advertisement and/or benefit of interest, such as a discount, incentive, reward, coupon, gift, cash back, or opportunity (e.g., special-value ticket/entrance). The advertisement may include a offering of a product or service, an announcement of a product or service, or a presentation of a brand of a product or service, or a notice of an event, fact, opinion, or the like. Advertisements may be presented in text, graphics, audio, video, or animation, as well as print, Web content, interactive media, and so forth. The advertisement may be presented in response to the presentation of a financial transaction card, or in response to a financial transaction card being used to conduct a financial transaction, or in response to other user activity, such as browsing a web page, submitting a search request, conducting an online communication, entering a wireless communication area, and so forth. In one embodiment, the presentation of the advertisement may not be the result of a user action.

In one embodiment, the interaction point (107) may be one of various endpoints of a transaction network, such as a point of sale (POS) terminal, an Automated Teller Machine (ATM), an electronic self-service terminal (or a computer self-service terminal or an interactive self-service terminal), a self-checkout terminal, a vending machine, a gas pump, a website of a bank (e.g., a credit card issuer or a transferee bank), a bank statement (e.g., a credit card statement), a website of a transaction processing device (103), a website of a merchant, a checkout website, or a webpage for online shopping, and so forth.

In one embodiment, the interaction point (107) may be the same as the transaction terminal (105), such as a point of sale (POS) terminal, an Automated Teller Machine (ATM), a mobile phone, a computer of a user of an online transaction, etc. In one embodiment, the point of interaction (107) may be located with or near the transaction terminal (105) (e.g., a video monitor or display, a digital sign), or generated by the transaction terminal (e.g., a receipt generated by the transaction terminal (105)). In one embodiment, the interaction point (107) may be separate from and not located with the transaction terminal (105), such as a mobile phone, a personal digital assistant, a user's personal computer, a user's voicemail box, a user's email inbox, a digital sign, and so on.

For example, an advertisement may be presented on a portion of the media used for a transaction with a customer, which may be unused and as such is referred to as "white space. The white space may be located on printed matter (e.g., a receipt printed for the transaction, or a printed credit card statement), on a video display (e.g., a display monitor at a POS terminal for retail transactions, an ATM for cash withdrawals or funds transfers, a personal computer for online shopping at the customer), or on an audio channel (e.g., an Interactive Voice Response (IVR) system for transactions over a telephone device).

In one embodiment, the whitespace is part of a media channel that may be used to present messages from a transaction processing device (103) with the processing of a transaction by a user (101). In one embodiment, the white space is located in a media channel for reporting information about the user's (101) transaction (e.g., authorization status, confirmation messages, verification messages), in a user interface for verifying a password for online use of account information (142), in a monthly statement, warning, or report, or in a web page provided by the portal (143) for accessing a loyalty program associated with the consumer account (146) or in a registry.

In other embodiments, the advertisements may also be presented through other media channels that may not be involved in the transactions processed by the transaction processing device (103). For example, advertisements may be presented on publications or announcements (e.g., newspapers, magazines, books, catalogs, radio broadcasts, television, digital signage, and the like, which may be in electronic form, or in printed or painted form). The advertisement may be presented on paper, on a website, on a billboard, on a digital sign, or on an audio portal.

In one embodiment, the transaction processing device (103) purchases rights to use the media channel from the owner or operator of the media channel and uses the media channel as advertising space. For example, white space at a point of interaction (e.g., 107) with a customer for a transaction processed by the transaction processing device (103) may be used to place advertisements related to the customer performing the transaction; while advertisements may be selected based at least in part on intelligent information derived from the accumulated transaction data (109) and/or context at the interaction point (107) and/or the transaction terminal (105).

Generally, the interaction point (e.g., 107) may or may not be capable of receiving input from the customer and may or may not be co-located with the transaction terminal (e.g., 105) that initiated the transaction. The white space used to present the advertisement at the interaction point (107) may be on a portion of the geographic display space (e.g., on the screen) or on the temporal space (e.g., in an audio stream).

In one embodiment, the interaction point (107) may be used primarily to access services not provided by the transaction processing device (103), such as services provided by search engines, social networking websites, online marketplaces, blogs, news sites, television program providers, radio stations, satellites, publishers, and so forth.

In one embodiment, a consumer device is used as the interaction point (107), which may be a non-portable consumer device or a portable computing device. The consumer device will provide media content to the user (101) and may receive input from the user (101).

Examples of non-portable consumer devices include computer terminals, televisions, personal computers, set-top boxes, and the like. Examples of portable consumer devices include portable computers, cellular telephones, Personal Digital Assistants (PDAs), pagers, social security cards, wireless terminals, and the like. The consumer device may be implemented as a data processing system as shown in fig. 7 with more or fewer components.

In one embodiment, the consumer device includes an account identification device (141). For example, a smart card used as an account identification device (141) is integrated with a mobile phone or a Personal Digital Assistant (PDA).

In one embodiment, the interaction point (107) is integrated with the transaction terminal (105). For example, the self-checkout terminal includes a touch panel that interacts with the user (101); and the ATM machine includes a user interface subsystem for interacting with a user (101).

Hardware

In one embodiment, the computing device is configured to include some of the modules or components shown in fig. 1 and 4, such as the transaction processing device (103), the profile generator (121), the media controller (115), the portal (143), the profile selector (129), the ad selector (133), the user tracker (113), the correlator, and their associated storage devices, such as the data warehouse (149).

In one embodiment, at least some of the modules or components shown in fig. 1 and 4, such as the transaction processing device (103), transaction terminal (105), interaction point (107), user tracker (113), media controller (115), correlator (117), profile generator (121), profile selector (129), advertisement selector (133), portal (143), open bank processor (145), transferee processor (147), and account identification device (141), may be implemented as a computer system, such as the data processing system shown in fig. 7, with more or fewer components. Some modules may share hardware or be combined on a computer system. In one embodiment, a computer network may be used to implement one or more of the modules.

In addition, the data shown in FIG. 1, such as transaction data (109), account data (111), transaction profile (127), and advertisement data (135) may be stored in a storage device of one or more computers that may be accessed by the corresponding modules shown in FIG. 1. For example, transaction data (109) may be stored at a data repository (149), and the data repository (149) may be implemented as the data processing system shown in fig. 7 with more or fewer components.

In one embodiment, the transaction processing device (103) is a payment processing system, or payment card processor, such as a card processor for credit cards, debit cards, and the like.

FIG. 7 illustrates a data processing system in accordance with one embodiment. Although FIG. 7 illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components. One embodiment may use other systems with fewer or more components than those shown in fig. 7.

In fig. 7, data processing system (170) includes an interconnect (171) (e.g., a bus and system core logic) that interconnects microprocessor (173) and memory (167). In the example of fig. 7, microprocessor (173) is coupled to cache memory (179).

In one embodiment, an interconnect (171) interconnects the microprocessor (173) and the memory (167) and to an input/output (I/O) device (175) through an I/O controller (177). The I/O devices (175) may include display devices and/or peripheral devices such as mice, keyboards, modems, network interfaces, printers, scanners, cameras, and other devices known in the art. In one embodiment, when the data processing system is a server system, some I/O devices (175), such as printers, scanners, mice, and/or keyboards, are optional.

In one embodiment, interconnect (171) includes one or more buses connected to each other through various bridges, controllers and/or adapters. In one embodiment, the I/O controller (177) includes a USB (Universal Serial bus) adapter for controlling USB peripheral devices and/or an IEEE-1394 bus adapter for controlling IEEE-1394 peripheral devices.

In one embodiment, the memory (167) includes one or more of the following: ROM (read only memory), volatile RAM (random access memory), and non-volatile memory such as a hard disk drive, flash memory, and the like.

Volatile RAM is typically implemented as dynamic RAM (dram) which continuously requires power in order to refresh or maintain the data in the memory. The non-volatile memory is typically a magnetic hard drive, a magnetic optical drive, an optical drive (e.g., a DVD RAM), or other type of memory system that retains data even after power is removed from the system. The non-volatile memory may also be a random access memory.

The non-volatile memory may be a local device coupled directly to the rest of the components in the data processing system. Non-volatile memory that is remote from the system, such as a network storage device coupled to the data processing system through a network interface such as a modem or Ethernet interface, may also be used.

In this specification, certain functions and operations are described as being performed by or caused by software code to simplify description. However, such expressions are also used to specify the functions performed by the code/instructions executed by a processor, such as a microprocessor.

Alternatively, or in combination, the functions and operations as described herein may be implemented using special purpose circuits, with or without software instructions, such as using an Application Specific Integrated Circuit (ASIC) or a Field Programmable Gate Array (FPGA). Embodiments may be implemented using hardwired circuitry, without or in combination with software instructions. As such, the techniques are not limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system.

While an embodiment may be implemented in the form of a fully functional computer and computer system, the embodiments are capable of being distributed as a computing article of manufacture in a variety of forms, and are equally applicable regardless of the particular type of machine or computer-readable medium used to actually carry out the distribution.

At least some disclosed aspects may be implemented at least in part in software. That is, the techniques may be performed in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM, volatile RAM, non-volatile memory, cache, or a remote storage device.

The routines executed to implement the embodiments, may be implemented as part of an operating system or as part of a specific application, component, program, object, module or sequence of instructions referred to as a "computer program. The computer programs typically comprise one or more sets of instructions in various memory and storage devices in the computer at various times, which when read and executed by one or more processors in the computer, cause the computer to perform the operations necessary to execute the elements relating to the various aspects.

A machine-readable medium may be used to store software and data which when executed by a data processing system causes the system to perform various methods. Executable software and data may be stored in various locations including, for example, ROM, volatile RAM, non-volatile memory, and/or cache. Portions of this software and/or data may be stored in any of these storage devices. In addition, data and instructions may be obtained from a centralized server or a peer-to-peer network. Different portions of the data and instructions may be obtained from different centralized servers and/or peer-to-peer networks at different times, in different communication sessions, or in the same communication session. The data and instructions may be fetched in their entirety prior to execution of the application. Alternatively, certain portions of the data and instructions may be dynamically fetched just in time as execution requires. As such, it is not necessary that the data and instructions be located entirely on the machine-readable medium at a particular time.

Examples of computer readable media include, but are not limited to, recordable and non-recordable type media such as volatile and non-volatile memory devices, Read Only Memory (ROM), Random Access Memory (RAM), flash memory devices, floppy and other removable disks, magnetic disk storage media, optical storage media (e.g., compact disk read Only memory (CD ROM), Digital Versatile Disks (DVDs), etc.), among others. A computer readable medium may store instructions.

The instructions may also be embodied in digital and analog communications links for electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.). However, propagated signals, such as carrier waves, infrared signals, digital signals, and the like, are not tangible, machine-readable media and are not configured to store instructions.

Generally, a machine-readable medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant, manufacturing tool, any device with a set of one or more processors, etc.).

In various embodiments, the present techniques may be implemented using hardwired circuitry in combination with software instructions. As such, the techniques are not limited to any specific combination of hardware circuitry and software nor to any particular source for the instructions executed by the data processing system.

Other aspects

The description and drawings are merely illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the present invention. However, in certain instances, well-known or conventional details are not described in order to avoid obscuring the present description. References to one embodiment of the invention are not necessarily references to the same embodiment; and, such references mean at least one.

The headings used herein are for ease of reference only and should not be construed to limit the invention or the claims below in any way.

Reference to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. In addition, various features are described which may be exhibited by one embodiment and not by others. Similarly, various requirements are described which may be requirements for one embodiment but not other embodiments. Any combination of the various features described in this specification is also included herein, unless explicitly stated and/or clearly excluded from compatibility.

The details of the above-discussed patent documents are incorporated herein by reference.

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope as set forth in the following claims. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense.

Claims (20)

1. A computer-implemented method, comprising:

in a computing device, receiving a request for a configuration file to customize information for presentation to a user identified in the request; and

providing, by the computing device, a profile generated based on transaction data of the user in response to the request identifying the user; wherein the transaction data relates to a plurality of transactions processed at a transaction processing device, each of the transactions processed to make a payment from an issuer to a transferee via the transaction processing device in response to an account identifier of a customer submitted by a merchant to the transferee as issued by the issuer to the user, the issuer making a payment on behalf of the user, the transferee receiving the payment on behalf of the merchant.

2. The method of claim 1, further comprising: based on the factors identified from the factor analysis for the plurality of variables, a plurality of values of the profile are calculated to aggregate the user's transaction data and represent the aggregate costs in the various domains.

3. The method of claim 2, wherein the factor analysis is based on transaction data associated with a plurality of users.

4. The method of claim 2, wherein the variables aggregate transactions based on merchant category.

5. The method of claim 4, wherein the variables include a spending frequency variable and a spending amount variable.

6. The method of claim 2, wherein the configuration file is computed prior to the request; and the method further comprises:

selecting the profile from a plurality of profiles based on a request identifying the user.

7. The method of claim 2, further comprising:

identifying transaction data for the user based on the request identifying the user; and

in response to the request, the profile is calculated based on the transaction data.

8. The method of claim 2, wherein transactions processed by the transaction processing device are classified into a plurality of merchant categories; and, the plurality of values is less than the plurality of merchant categories to aggregate the aggregate costs in the plurality of merchant categories.

9. The method of claim 8, wherein each of the plurality of values indicates a level of aggregate spending for the user.

10. The method of claim 2, wherein the user is identified in the request by an IP address; and the method further comprises:

based on the IP address, an account identifier of the user is identified.

11. The method of claim 10, further comprising:

storing account data including a street address of a user;

mapping the IP address to a street address of a computing device; and

identifying an account identifier for the user based on a match of a street address of the computing device and a street address of the user stored in the account data.

12. The method of claim 2, wherein the user is identified in the request by an identifier of a browser cookie associated with the user.

13. The method of claim 2, further comprising:

generating the information customized according to the configuration file; and

presenting the information to the user.

14. The method of claim 13, wherein the information comprises a prioritized, adjusted, or generated advertisement selected based on the profile.

15. The method of claim 14, wherein the advertisement includes at least an offer selected from the group consisting of: discounts, incentives, rewards, coupons, gifts, cash returns, benefits, products, and services.

16. The method of claim 1, further comprising:

generating the profile using the transaction data of the user based on a cluster definition and a factor definition, wherein the cluster definition and the factor definition are generated based on the transaction data of a plurality of users.

17. A computer storage medium storing instructions that, when executed on a computer system, cause the computer to perform a method comprising:

in a computing device, receiving a request for a configuration file to customize information for presentation to a user identified in the request; and

in response to a request identifying the user, providing, by the computing device, a profile generated based on transaction data of the user, the profile summarizing the transaction data of the user;

wherein the transaction data relates to a plurality of transactions processed at a transaction processing device, each of the transactions processed to make a payment from an issuer to a transferee via the transaction processing device in response to an account identifier of a customer submitted by a merchant to the transferee as issued by the issuer to the user, the issuer making a payment on behalf of the user, the transferee receiving the payment on behalf of the merchant.

18. A system, comprising:

transaction processing apparatus for processing transactions, each of said transactions being processed to make a payment from an issuer to a transferee via said transaction processing apparatus in response to a customer's account identifier submitted by a merchant to the transferee as issued by the issuer, the issuer making the payment on behalf of the customer, the transferee receiving the payment on behalf of the merchant;

a data repository storing transaction data recording the transactions processed at the transaction processing device;

a profile generator that generates a profile for a user based on the transaction data, the profile including a plurality of values representing an aggregate spending of the user in various domains; and

a portal that receives a request identifying the user and provides the configuration file in response to the request to facilitate customization of information to be presented to the user.

19. The system of claim 18, further comprising:

a profile selector that selects the profile from a plurality of profiles generated by the profile generator based on a request identifying the user;

wherein the configuration file generator generates the plurality of configuration files and stores the plurality of configuration files in the data repository.

20. The system of claim 18, further comprising:

an advertisement selector to customize advertisements presented in the information according to the configuration file.