CA2351742A1 - Method and system for obtaining consumer transaction information - Google Patents

Abstract

The invention is a computer-implemented method and system for obtaining consumer transaction information from consumers' online accounts on World Wide Websites. The method comprises the automated steps of transmitting a consumer's account access information to a website containing the consumer's online account, downloading a series of generally private HTML files from the websites in order to navigate to and download an HTML file associated with a web page including desired transaction information, scanning and parsing the HTML to copy the transaction information therefrom, and storing the copied transaction information into a database.
The process of navigating through the website to find the HTML file containing the desired transaction information involves downloading a sequence of HTML
pathway files one by one. Each pathway file contains the URL for the next pathway file, which is used to request the next pathway file. The final pathway file in the sequence contains the desired consumer transaction information. In a preferred embodiment, the method and system of the invention is used to administer a consumer rewards program.

Description

:l CTRIBE.001 A PATENT
METHOD AND SYSTEM FOR OBTAINING CONSUMER TRANSACTION
INFORMATION
S
Related Application This application claims priority under 35 U.S.C. ~ 119(e) from a U.S.
provisional patent application, Serial No. 60/213,636, entitled "SYSTEM FOR
OBTAINING CONSUMER TRANSACTION INFORMATION," filed on June 23, 2000.
Field of the Invention The present invention relates generally to advertising and more particularly to a method of obtaining consumer transaction data to bolster advertising revenue.
Background of the Invention One of the primary manners of generating revenue across wide area networks, such as the global World Wide Web, is through advertising for other online or for offline merchants. One manner of advertising is to offer shoppers rewards for purchases made after viewing an advertisement at a particular location. For example, a common rewards program involves displaying the advertisement for a promotional special on a rewards program website. If the consumer elects to accept the offer, the advertising merchant receives revenue from the sale, and generally will pay a commission to the advertiser that generated the sale.
As used herein, "advertising merchant" and "merchant customer" refer to a merchant that places advertisements in various media for the purpose of attracting consumers to the merchant's online or offline retail sites to generate sales.
As used herein, "advertiser" and "rewards program" refer to a party that channels or directs advertisements for various advertising merchants or merchant customers to consumers.
Businesses that generate revenue through advertising, whether through a rewards program or some other advertising model, generally have a need for transaction information. One use of transaction information is simply to track the buying habits of particular consumers. Such information facilitates more targeted and therefore more successful advertising. Because targeted advertising has a higher statistical likelihood of success, advertising merchants are generally willing to pay more for targeted advertisements. In the context of a rewards or referral program, the site that offers the reward to the consumer typically wishes to confirm a consumer's actual purchase associated with the promotional offer. Similarly, any type of program that relies upon commissions for actual sales requires proof of the fact that the advertising party generated the sale. Even straight payment-for-display advertising arrangements can benefit from proven correlations between viewing an ad and actual purchases.
With reference to Figure 1, there are many sources of consumer transaction information, including all of the parties involved in a credit card transaction.
Accordingly, many rewards programs and other advertising business models rely upon information generated through credit card purchases. One advantage of such a system is that the program can be employed regardless of the channel used by the consumer, whether online or at offline, physical store locations.
As shown at the point marked "1" in Figure 1, when a consumer 10 is ready to purchase a product at a store (or online), the merchant swipes the consumer's card 14 at a merchant location 12 (or the consumer enters credit card information into his terminal if shopping online). This credit card 14 is then checked for authorization and available funds in the consumer's credit card account. Accordingly, a request is transmitted from the merchant location 12 to the merchant's bank 16, as indicated at reference numeral 2.
Due to the high volume of credit card transactions and the specialized nature of the data processing for routing such requests, the merchant bank 16 typically employs an outsourced merchant processor 18. The outsourced merchant processor 18 analyzes the request and credit card information in order to route the request through the correct channels for authorization, as indicated at reference numeral 3 on Figure 1.
From the merchant's bank 16 and outsourced processor 18, the request for authorization travels over a credit card net<vork 20, such as provided by VisaT''', MasterCardT"', American ExpressT''', DiscoverT''', etc. This network 20 ties merchant banks 16 to consumer banks 22 that issue credit cards 14 to consumers 10. Like the merchant bank 16, the consumer or "credit card issuing" bank 22 employs outsourced banking processors 24 to handle the data. With the aid of the outsourced banking processor 24, the credit card issuing bank 22 checks the account and approves or denies the request, as indicated at reference numeral S.
Thus, all the parties along the path traveled by the information in the course of requesting and approving or denying authorization have access to consumers' transaction information. Thus, a party wishing to have access to such transaction information, such as an advertiser, can form agreements with parties at any level of this information pathway.
Unfortunately, in order to maximize the information received, the advertiser would have to form agreements with multiple parties. For example, information at the merchant banks 16 level or at the credit card issuing banks 22 level is impractical, since thousands of such parties exist. The credit card nehvorks 20, such as VisaT"' or MasterCardT"' networks, are typically not willing to part with consumer transaction inforn~ation.
There is a relatively small number of outsourced merchant processors 18, however, such that it might be practical to form agreements with each of the outsourced merchant processors, in theory. A number of so-called "data miners" 26 therefore do obtain their information from these outsourced merchant processors 18, providing a wealth of consumer transaction history for advertisers to analyze.
Unfortunately, exclusive relationships have developed between outsourced merchant processors 18 and the third party data miners 26, which in practice has prevented any one party from obtaining all possible credit card transaction information. Accordingly, the outsourced merchant processors 18 and the third party data miners 26 are unsatisfactory sources for consumer transaction information for some advertisers' purposes.
Another possible source of consumer transaction information is the merchants 12 themselves. The merchants 12 have the advantage of sharing a common interest with the advertisers of determining how well their advertising is working. The merchants 12 are a particularly advantageous source of information for rewards programs, since the party offering the rewards often is already involved in consumers' transactions with the merchant 12 to provide promotional advertising.
Merchants 12, ' however, would rather not complicate the transaction with the advertiser, such as by having to give the advertiser limited (and therefore individually tailored) access to the merchant's databases.
Moreover, in order for an advertiser to learn about consumer habits generally, rather than just the customers of a select few merchants, the advertisers would have to obtain this information from thousands upon thousands of merchants 12, the vast majority of which would not already have advertising agreements with the advertiser. It is, of course, impossible to assure that all transactions would be covered by such agreements.
1 p Accordingly, a need exists for methods of acquiring transaction information, particularly to support advertising revenue.
Summary of the Invention Accordingly, it is a principle object and advantage of the present invention to 1 S provide new and improved methods of acquiring customers' transaction information.
The present invention recognizes that a particularly advantageous source of consumers' transaction information is the consumers themselves, and that the information can be obtained from consumers' online accounts, such as online credit card accounts. The information can be obtained from such accounts through the use of "data 20 scraping," a method of acquiring inforn~ation written into files (e.g., HTML files) that are readable by browsers to form pages (e.g., web pages) accessible across wide area net<vorks, such as the Internet.
One advantage of this method of obtaining transaction data is that it does not involve any action on the part of the consumers, except for initially providing online 25 account access information and authorization to the transaction information scraping service provider ("the data scraper"). Also, in the specific context of a rewards program, it does not involve any action on the part of the participating merchants, except for initially setting up promotional offers with the data scraper.
After these initial steps, all of the data scraping is invisible to the merchants and consumers, which 30 conduct transactions in a conventional manner.

The methods described herein for scraping transaction information from consumers' online accounts may be applied in many different contexts, one of which is a consumer rewards program. Other applications may include, for example, analysis of consumers' purchasing activities in order to evaluate the effectiveness of advertising.
Companies that monitor consumers' Internet browsing activities would like to determine the effectiveness of online advertisements that the consumers' view.
Additionally, there are many other applications and uses of the scraped transaction information that can be obtained by the methods described herein.
In accordance with one aspect of the invention, a method is provided for administering a consumer rewards program in which rewards are offered to consumers for consumers' purchases of advertised goods and services of participating merchants.
The method comprises: receiving a consumer's indication of an interest in a promotional offer associated with a selected one of the participating merchants in exchange for an offered reward. Transaction information is scraped from the consumer's online credit card account. This transaction inforTnation is scanned for purchase data indicating that the consumer made a purchase from the selected merchant associated with the promotional offer in which the consumer had indicated interest.
In accordance with another aspect, the present invention provides a rewards program system in which rewards are offered to consumers for consumers' purchases of advertised goods and services of participating merchants, comprising a consumer interface and a transaction information scraping engine. The consumer interface is configured to display rewards offered for purchases from a selected one of the participating merchants. The transaction information scraping engine is configured to scrape transaction information from the consumer's account on an account website. The rewards program system gives the rewards to consumers for purchases.
Preferably, the system also includes a rewards analysis engine configured to scan transaction information scraped by the transaction information scraping engine, in order to find purchase data indicating whether a consumer purchased selected goods and services from a selected merchant.
In accordance with another aspect, the present invention provides a method of obtaining transaction information from a consumer's online account. The method -S-includes transmitting account access information to the account in order to access the account, and obtaining transaction information from the account, wherein the accessing and obtaining steps are automated.
In accordance with another aspect, the present invention provides a method of obtaining a desired subset of data included within a consumer's private account. The account information site is accessible over a public network (e.g., the World Wide Web), but the account is accessible only when one or more private access codes (e.g., username and password) are transmitted to the site. The method includes transmitting one or more private access codes are transmitted to the site, which causes the site to permit access to the account. A pathway file, such as an HTML file, is received from the site, the pathway file including a nehvork address for a next pathway file in a sequence of pathway files. The received pathway file is scanned to find the network address of the next pathway file in the sequence. The next pathway file in the sequence is then requested by transmitting the network address of the next pathway file to the site.
Then, the above-described receiving, scanning, and requesting steps are repeated for additional pathway files in the sequence, if any, until a final pathway file is received from the site. The final pathway file includes the desired subset of data. The final pathway file is scanned to obtain the desired subset of data.
In accordance with another aspect of the present invention, a method of advertising is provided. The method includes displaying advertisements to consumers.
Transaction information of the consumer is periodically and automatically obtained by mining the transaction infom~ation using consumer online account access information.
Consumer viewing of the advertisements is matched with actual purchases reflected in said transaction information, purchases associated with said advertisements.
For purposes of summarizing the invention and the advantages achieved over the prior art, certain objects and advantages of the invention have been described herein above. Of course, it is to be understood that not necessarily all such objects or advantages may be achieved in accordance with any particular embodiment of the invention. Thus, for example, those skilled in the art will recognize that the invention may be embodied or carried out in a manner that achieves or optimizes one advantage or group of advantages as taught herein without necessarily achieving other objects or advantages as may be taught or suggested herein.
All of these embodiments are intended to be within the scope of the invention herein disclosed. These and other embodiments of the present invention will become S readily apparent to those skilled in the art from the following detailed description of the preferred embodiments having reference to the attached figures, the invention not being limited to any particular preferred embodiments) disclosed.
Brief Description of the Drawings Figure I is a schematic diagram of an information pathway followed by requests for authorization on credit card transactions and responses thereto;
Figure 2 is a schematic diagram of a screen-scraping method of obtaining information on a wide area network;
Figure 3 is a schematic diagram illustrating the relationships among parties in a I S system in accordance with a preferred embodiment of the present invention;
Figure 4 illustrates generally a method of obtaining transaction inforn~ation in accordance with the preferred embodiment;
Figure 5 is a system component diagram describing the relationship behveen consumers, a transaction data scraping service, and an account website, according to a preferred embodiment of the present invention;
Figure 6 is an example of a web page from an online account website, which a customer downloads after initially logging in to the customer's online account; that can be scraped for transaction data according to the methods of the present invention;
Figure 7 is an example of a web page from an online account website, from which a customer can select and download a statement for a billing period;
Figure 8A is an example of a web page from an online account website, containing summary information for one billing period;
Figure 8B is an example of a web page from an online account website, containing transaction information for one billing period;
Figure 9 is a flowchart illustrating a method of navigating through a sequence of web pages of a website and scraping transaction data therefrom;

Figure 10 is an example of a portion of HTML code for a web page that presents a consumer's transactional information;
Figure 11 is a flowchart illustrating a method of scanning and parsing an HTML
file that corresponds to a web page containing a consumer's transactional information, and extracting the transactional data elements therefrom;
Figure 12 is an exemplary list of transactions scraped from a website according to the methods of the present invention.
Figure 13 is a flowchart illustrating a method of scanning transactions for specific merchants or SKU numbers; and Figure 14 is an example of a lookup table used in conjunction with the method described by Figure 12.
Detailed Description of the Preferred Embodiment While the preferred .embodiments are described in the context of a rewards program, the skilled artisan will readily appreciate that the principles described herein will have application in a number of other contexts. For example, advertisers and their merchant customers have a general need for the type of consumer transaction information that can be obtained by the systems and methods described herein.
The preferred embodiments have particular advantage, however, in the context of a rewards program for shoppers.
Advertisers and Consumer Transaction lnformation As described~in the Background of the Invention, advertisers and their merchant customers have a need for consumer transaction information. One source of such information that is often overlooked is the consumer himself. Traditionally, the consumer has not been viewed as a particularly good source of this information. If, for example, the consumer simply reported his or her own transactions, there would still be a need for independent verification of any transactions reported. Reliable information provided to the consumer is unfortunately in the form of a credit card monthly statement. Because it is a paper document, this information is not readily accessible for mass analysis.
_g_ Ever more frequently, however, such personal account transaction information is more accessible in electronic form through the individual consumer. Most credit card companies, for example, currently offer consumers the option of obtaining their own account information online, such as over the World Wide Web or Internet.
Accordingly, in the preferred embodiments, the advertiser can also gain access to this information online. In the preferred embodiments, access is granted by permission of the individual consumer. The offer of a rewards program provides the consumer with a reason to grant permission to the advertiser to gain such information.
In the broadest concept of the preferred embodiment, however, it is not necessary that the methods and systems described herein be implemented in conjunction with a rewards program.
Screen Scraping With reference initially to Figure 2, the method employs a version of a 1 S technology known as "screen scraping." The general method involves searching the wide area network for information that falls into a particular category and gathering the information into a database. At an originating location, referred to in Figure 2 as a scraper web site or computer 30, the process is initiated. Signals are sent across communication channels to other sites on the network. Information is read from those other sites, which are labeled "scraped sites" 32 (one shown) in Figure 2.
This data is copied into a database 34 at or tluough the scraper site 30. Screen scraping is to be distinguished from conventional search engines, which merely identify the locations of information for the user to view by himself, by visiting the location (e.g., web site) of the information. In contrast, the scraping engine copies selected information from other web sites for other uses.
Screen scraping has been previously employed by specialized search engines known as search spiders. One particular search spider, known as a "shopping bot,"
traverses the wide area network looking for prices at different sites for the same product.
The shopping bot gathers the price information in a database for producing a list for comparative shopping by consumers or for a retailer to use in setting its own price.

A more recent application of screen scraping technology is that of account aggregation. Account aggregators provide a service to customers by centralizing information on their customers' accounts. For example, an individual may have a credit card account, a brokerage account and an air miles account. The customer informs the account aggregator of lus or her account access information, i.e., account numbers, user names, passwords, etc., to access the account information on the network.
Using screen scraping technology, the account aggregator uses the account access information to access the customer's accounts on the network and copy summary information, such as present account balances. This information is copied and sorted by the account aggregator, and presented to the customer in summary forn~at. The customer can thus view his or her account balances for several accounts at a single location, without having to separately log on to each of his or her accounts.
Preferred Rewards Program 1 S With reference to Figure 3, the preferred embodiments also employ screen scraping technology, but in the context of a business model that derives revenue from advertising activity.
The business model of a rewards program to encourage consumer spending is well known. Examples include the cash back award offered by DiscoverT"', whereby credit card purchases (at any merchant) are rewarded by giving back to the credit card holder a percentage of the amount spent. Similarly, American Express offers a Membership RewardsT"' program, in which dollar amounts of consumer transactions are tallied as points, arid points can be redeemed for products or services. Many credit cards offer air miles for usage of their credit card. In all of these examples, the credit card company itself performs the transactions for which the consumer is rewarded and has no need to independently verify the transactions.
Another example of a known rewards program is a species of advertising conducted by independent third parties. These programs are particularly well adapted for operation across data networks such as the Internet or World Wide Web.
Typically, the rewards program draws customers (i.e., individual consumers) by the offer of promotional offers related to specific providers of goods and services ("merchants" or "vendors"). For example, the rewards program can offer consumers coupons or rebates that reduce the effective purchase prices on particular sales items or services. Normally, the merchants pay commissions to the rewards program for generating increased consumer interest in the merchants' goods and services. In some arrangements, preferred by the merchants, the merchant pays the rewards program a commission only for actual sales generated by the rewards program.
The rewards program administrator therefore wishes to prove generation of particular sales. In the case of coupons, the fact that the rewards program generated a sale is easily verified by a physical coupon that the consumer gives to the merchant.
Where rebates are offered, however, some other form of proof is required to determine that the rewards program generated the sale before the merchant will pay a commission to the rewards program.
Similarly, companies or advertisers that operate on other advertising models will generally wish to verify that their advertising generates actual sales. Direct evidence of I S sales generation, through consumer transaction information, is advantageous to this goal. Such transaction data enables direct correspondence between sales and the advertiser's revenue, such that the advertiser's revenue is really a commission. The rewards program is one example of commissions offered for generation of individual sales.
More generally, advertisers can benefit from the information on consumer behavior and spending habits that is reflected in consumer transaction information.
Among other uses, an advertiser can better target its advertising in order to increase its advertising rates (e.g., $/page for print media, $/minute for television ads, $/page view for network media, etc.). Simply put, merchants pay more for advertising that works.
In the context of rewards programs, one source of information on consumer transactions is the merchant himself. The merchant can grant the rewards program limited access to its own transaction information. The rewards program can then sort through the data to match actual transactions with the rewards program activity of its members. Unfortunately, granting limited access to its databases is a burden on the merchant and encourages the merchant to seek alternative methods of promotion.
-l 1-Referring to Figure 3, interactions among a consumer 50, a merchant 55, a credit card issuing bank 60 and an advertiser 65 are illustrated in accordance with the preferred embodiment. As shown, the preferred embodiment does not require any direct information transfer between the merchant 55 and the advertiser 65. Rather, the information transfer is invisible to the merchant 55. Accordingly, the only dealings that the merchant 55 need have with the advertiser 65 is to set up the promotional offers, which involves no more than the merchant's traditional advertising activities.
Moreover, as will be understood from the discussion below, after enrollment with the advertiser 65, the transfer of information is also invisible to the consumer 50. The consumer 50 only needs to indicate interest in a promotional offer and conclude the transaction with a purchasing instrument, such as a credit card, that has been registered with the advertiser 65. Behind the scenes, the advertiser 65 matches consumer interaction with the promotional offer to the completed transaction, preferably in an automated fashion.
In particular, the preferred advertiser comprises a rewards program 65, as described above. The rewards program 65 initially sets up arrangements with a plurality of merchants 55 (i.e., providers of sales or services). The arrangements include the provision of promotional offers to the rewards program 65, generally having conditions attached to each promotion. Alternatively, the merchant 55 can have a general arrangement with the rewards program 65, leaving the details of implementing promotional offers to the discretion of the rewards program.
Due to the number and/or variety of merchants 55 represented by the rewards program 65, consumers 50 are attracted to enroll as customers or members of the rewards program 65. In order to avail himself or herself of the rebates or other promotional offers, the consumer 50 registers a credit card, debit card or other purchasing instrument with the advertiser through a customer interface 70, preferably comprising a web site. For purposes of illustration, a credit card is employed in the figures as an exemplary purchasing instrument. Typically, the consumer 50 already has the credit card in his or her name, and simply provides the rewards program with credit card account information 72, including any account access information needed to access the credit card account, such as passwords or personal identification numbers.
The credit card account information 72 is stored in a database, preferably in a batch with information from other customers 50 of the rewards program 65.
The rewards program 65 also manages a number of other databases, such as the illustrated transaction information 74, rewards account information 76 and offer S activation information 78, each of which will be better understood from the discussion of the process set forth below. Additionally, the rewards program 65 administers numerous software algorithms, such as the illustrated scraping engine 80 and rewards analysis engine 82.
As shown in Figure 4, after registering 100, the consumer uses the rewards program by logging on 105 to the rewards program web site. The consumer can search or surf through the site's promotional offers. After viewing a number of offers, the consumer may settle on a particular offer that suits his or her needs. An exemplary promotional offer might be for a 20% rebate on all purchases over $50.00 made at ACIT7C department store on a certain Tuesday. The consumer indicates interest in the offer by "activation" 110 of the offer, such as by mouse clicking or cursoring over to a displayed button for that purpose. The activation 110 of a promotional offer, including the conditions thereof, is stored along with other such activations in the activations information database 78. It will he understood that, in other arrangements, a promotional offer may not have conditions associated with it, or the only condition might be the location of merchant or brand of the product (when offered, e.g., by a manufacturer).
In the illustrated embodiment, activation 110 is required for the consumer to avail himself or herself of the offer. In other arrangements, the skilled artisan will appreciate that "activation" can be automated by detecting the consumer's page view, if the merchant would accept that such activation could serve as adequate proof that the rewards program generated a later sale.
After activation 110, in order to take advantage of the promotional offer, the consumer makes a purchase 115 in a conventional manner using his or her credit card that was registered with~the rewards program. The consumer does not need to carry any coupon or inform the merchant of the promotional offer, but may need to ensure that the purchase meets the conditions of the promotional offer. The merchant does not need to make any special arrangements for the purchase, but rather processes the credit card transaction as usual, i.e., with an authorization check (see Figure 1) and submission of invoice for the completed transaction. The purchase 1 I S can be made either online or offline.
Referring to both Figure 3 and Figure 4, independently of the consumer-merchant direct transaction, the scraping engine 80 of the rewards program 65 scrapes or mines 120 data regarding the transaction. The scraping engine 80 performs this mining 120 by using the credit card account information 72 (Figure 3) provided by the consumer 50 to access the consumer's credit card account online. Preferably, the engine 80 batches all members' registered credit card information 72, sorted by issuing bank or credit card brand. The engine 80 then enters the web site of the issuing bank 60 (or credit card company) and navigates through the web site until detailed transaction information is found. This information is downloaded into the transaction information database 74. Preferably, transaction information for all members' registered cards for that site (e.g., all Citibank VisaT"' cards) is downloaded before the scraping engine 80 leaves the site. The scraping engine 80 can be configured to mine for members' transaction data periodically, e.g., once a month. The scraping process is described in more detail below.
It will be understood that a single member 50 may have more than one account associated with a given credit card company, and that the scraping engine can be adapted to download the transaction inforn~ation associated with some or all of the member's accounts. Also, it will be understood that, collectively, the members SO of the rewards program 65 will likely have' accounts with many different credit card companies. Further, any single member SO may have accounts with several different credit card companies. Preferably, the scraping engine 80 mines transaction data from all sites for the registered credit cards.
The aggregated transaction data 74 is then analyzed by the rewards analysis engine 82 to match 125 the customer activations 78 with corresponding transactions 74.
The rewards analysis engine 82 also verifies 130 that the matched transactions meet all of the conditions of the promotional offer that was activated 110 by the consumer. For example, the exemplary promotional offer described above was for a 20% rebate on all purchases over $50.00 made at Acme department store on a certain Tuesday. The transaction data 74 includes sufficient information to determine whether the consumer made his or her purchase in the Acme department store, and whether the purchase was for more than $50.00, and whether the purchase was made on the Tuesday for which the S offer was good. If the conditions are met, the consumer qualifies for the offered reward (e.g., a 20% rebate on that purchase).
The rewards analysis engine 82 may also check 135 the transaction data 74 for any returns that might affect current rewards or previously issued rewards.
For example, if the consumer 50 bought a $100.00 baseball glove at the Acme department store one month and received a $20.00 rebate from the rewards program 65, the rewards analysis engine 82 in present and subsequent cycles will check for whether that same glove was later returned. If the transaction inforn~ation 74 shows the same glove was returned two months later, the rewards analysis engine 82 will deduct $20.00 from the customer's rewards account 76. Typically, returns on a credit card transaction are credited to the customer's credit card account, so this return information is also readily available through the system and method of the preferred embodiment, without intruding into the merchant's own records and without entering into agreements with the credit card companies, banks or processors of Figure 1. Preferably, a return is matched with a purchase by a credit entry having the same amount and merchant as a previous purchase.
Having matched 125 and analyzed 130 the credit card transaction data 74 for meeting the conditions of the promotional offer activations 78 (and preferably having checked 135 for returns), the rewards analysis engine 82 adjusts 140 the balance of the consumers' rewards balance. This adjustment 140 may be a credit (for meeting conditions of a promotional offer after activation) or a debit (for returning an item on which a reward had previously been issued) to the rewards account in the rewards account database 76.
Periodically, e.g., once a month, any positive balance on a customer's rewards account results in issuance 145 of a check. The consumer then receives the check 150.
In the end, the consumer 50 has merely looked 105 for interesting offers on the rewards program customer interface or web site 70, activated 110, and made the purchase 115 with his or her registered credit card as he or she normally would. The merchant 55 has merely set up the promotional offers with the rewards program 65 and made credit card sales to consumers 50 as it normally would. The bulk of the work in mining data 120 and analyzing 125, 130, 135 for suitability of a reward is done by the S rewards program 65. The system thus increases convenience for both the consumer 50 and the merchant 55, relative to conventional rewards programs currently administered, whether through credit/debit/dining cards or over computer networks by Internet web sites. Moreover, the rewards program 65 can avoid the cost and complication of making agreements with purchasing instrument issuers (e.g., banla) or third party processors.
It will be understood that the data obtained from the processes noted above will have numerous uses, as evidenced by the current high level of interest in consumer spending patterns and prices paid for reliable information in this regard.
Transaction Data Scraping System Figure S is a system component diagram illustrating the relationship between one or more consumer computers 160 (hereinafter "consumers" or "customers"), a Transaction Data Scraping Service 162, and an Account Website 164 containing consumers' online accounts, according to one embodiment of the present invention.
The consumers 160, Scraping Service 162, and Account Website 164 communicate via a wide area network, such as the Internet 166 or World Wide Web. The consumer computers 160 are typically home computers, laptops, or wireless intemet devices, but could be any suitable network devices. The components of the Scraping Service may be provided within a computer, a server, or any other suitable device.
Although described herein as an Internet site, the Account Site 164 could be of another type.
As used herein, the term "website" refers to one or more interrelated web page files and other files and programs on one or more web servers, the files and programs being accessible over a computer network, such as the Internet, by sending a hypertext transfer protocol (HTTP) request specifying a uniform resource locator (URL) that identifies the location of one of said web page files, wherein the files and programs are owned, managed or authorized by a single business entity. Such files and programs can include, for example, hypertext markup language (HTML) files, common gateway interface (CGI) files, and Java applications. The web page files preferably include a home page file that corresponds to a home page of the website. The home page preferably serves as a gateway or access point to the remaining files and programs contained within the website. Preferably, all of the files and programs are located under, and accessible within, the same netlvork domain as the home page file.
Alternatively, the files and programs can be located and accessible through several different network domains.
A website typically includes a plurality of web pages, such as the above-mentioned home page. A web page comprises that which is presented by a standard web browser in response to an http request specifying the URL by which the web page file is identified. A web page can include, for example, text, graphics, animation, and sound.
As used herein, the terns "customer" refers to a consumer that permits the Scraping Service 162 to scrape the consumer's online account(s), such as on the Account Website 164. In this context, the terms "customer" and "consumer" may be used interchangeably herein. "Customer" is not to be confused with "merchant customer," which herein refers to a merchant whose promotional offers are advertised by the advertiser or rewards program 65 (Figure 3).
As illustrated in Figure S, the Transaction Data Scraping Service 162 includes a Customer Interface 168, one or more Scraping Modules 170, a Transaction Analysis Module 171, a Customer Account Access Data Storage 172, and a Transaction Information Storage 174. The scraping service 162 may contain more or less elements than those shown in Figure S, as may be necessary for implementing a data scraping service as described herein. In contrast to the advertiser 65 described in Figure 3, which is specifically described in the context of a consumer rewards program, the Scraping Service 162 can be used for any application that requires scraping consumer transaction data from an consumer's online account. The interface 168, which may be web-based, is preferably configured to receive a consumer's account access data (e.g., username and password) and store such information in the storage 172. Preferably, the storage 172 is configured to store a large number of consumers' account access data.

The Scraping Module 170 is preferably configured to access a consumer's online account information from an account on a website, such as the Account Website 164.
Preferably, the module 170 is configured to scrape data from any number of different consumer accounts maintained on the website 164. Also, the service 162 may contain at least one module 170 for every different website 164 that is to be scraped for data, since each website is likely to be formatted differently and, thus, require a unique scraping program. The storage 174 is preferably configured to store a large multitude of transactions in groups, each group having an association to an individual customer.
Each transaction may include, for example, a transaction date, a vendor description, and an amount of currency. The Transaction Analysis Module 171 is preferably configured to read and analyze transactions stored in the Transaction Information Storage 174. For example, the module 171 may be configured to find transactions involving specific merchants, products, or sen~ices, or to find transactions of desired currency amounts. If desired, the module 171 can be integrated within the modules) 170.
Account Website to be Scraped The Account Website 164 is any website that maintains consumers' private accounts of transaction data, such as a credit card issuer website. In Figure 5, the website 164 contains a consumer interface 176, a consumer account information database 177, and a web page construction engine 180. The interface 176 is typically web-based and is normally configured to permit access to consumers' account information, including transaction data, upon receiving a consumer's account access data, such as a username and password. The interface 176 is configured to present account information to the consumer 160 in the form of web pages containing personalized data. The engine 180 is configured to construct HTML files corresponding to such web pages. The engine 180 may include, for example, CGI scripts. The HTML
files normally contain the consumer's account data, such as transaction information.
The database 177 is configured to store consumers' account information, including consumer transaction information 178. Typically, the credit card issuer continually updates the information in the databases 177 and 178 to reflect the most current data.
The engine 180 accesses the database 177 to construct HTML files that correspond to web pages containing a consumer's account data, including transaction information, as known in the art. Normally, the account data is contained within the HTML code of such web pages.
Figures 6-8 illustrate sample web pages that may be presented by the online Account Website 164 (Figure 5). Those of ordinary skill in the art will readily appreciate that the web pages of a website to be scraped can be formatted and organized in any of a large variety of ways. Also, the website can have any number of different types of web pages, options, etc. The web pages illustrated in Figures 6-8 describe merely one example of a website that can be scraped for transaction data.
Those of ordinary skill in the art will readily appreciate from the teachings herein that transaction data can be scraped from a website regardless of its particular form, by using the methods described herein.
The website to be scraped may be maintained or operated by any company that manages consumers' accounts of transactions, such as a credit card issuer, a brokerage company, a frequent flyer miles company, etc. The website illustrated in Figures 6-8 is a credit card issuer website. The website normally maintains one or more accounts for each consumer. Typically, a consumer accesses an account by entering account access data, such as one or more of a username, password, mother's maiden name, birthday, credit card number, etc. After logging in, the consumer gains access to various account information, such as current balances, amounts owed, transaction data, etc., which the consumer can review online. Also, the website may permit the consumer to conduct transactions relating to the account while logged on, such as paying account balances, requesting cash advances, etc. At any time, the consumer can log off, ending the online account sessron.
Figure 6 shows an example of a web page 200 that a consumer's browser downloads after the consumer logs in from the website's home page or account login page. The illustrated web page 200 contains hyperlinks 202, 204, 206, and 208 to other web pages within the website. Activation of the hyperlink 202, "ACCOUNT
SUMMARY," causes the consumer's browser to submit an HTTP request for a web page containing the consumer's account summary data. Activation of the hyperlink 204, "UNBILLED ACTIVITY," results in a request for a web page containing a summary of the consumer's unbilled transactions. Activation of the hyperlink 206, "STATEMENTS," results in a request for a web page from which a consumer can choose from a selection of account statements, for downloading and viewing.
Activation of the hyperlink 208, "MAKE A PAYMENT," results in a request for a web page from which a consumer can make an electronic payment to the credit card issuer.
Box 210 represents hyperlinla corresponding to various other options available to the consumer, such as sales offers, automatic payment schemes, contact options, help screens, online tutorials, requests to add more accounts, etc.
Figure 7 shows an example of a web page 212 from which a consumer can select a statement for downloading and viewing. As illustrated, the web page 212 contains a statement date selection box 214, comprising a drop-down menu. The consumer can activate the drop-down menu to select the date of a statement that the consumer wishes to download and view. Box 216 represents hyperlinks corresponding to various other options available to the consumer. For example, there may be a hyperlirrk for downloading a selected statement to an application program on the consumer's home computer, such as QuickenT''', and/or hyperlinla similar to those described above for the web page 200 (Figure 6).
Figures 8A and 8B show examples of web pages containing the consumer's statement for one billing period. Figure 8A shows a web page 218 containing statement summary information for the billing period, including the closing balance 220, minimum payment due 222, payment due date 224, available credit 226, payments and adjustments 228, purchases 230, cash advances and checks 232, and finance charges 234. Figure 8B shows a web page 235 containing a list of transactions 236 for the statement-billing period. In the illustrated web page 235, each listed transaction includes a transaction date, post date, vendor/item description, and currency amount, presented in columns 238, 240, 242, and 244, respectively. As used herein, the "vendor/item description" is a description of the selling merchant and/or the goods or services sold in a consumer's transaction. Those of ordinary skill in the art will appreciate that the transaction data may be presented differently than shown in Figure 8.
Also, the transactions may be grouped into different categories or groups of categories, including, for example, payments and adjustments, purchases, cash advances, checks, fees, etc. For simplicity, the web page 235 lists all of the transactions in one group.
The transactions are normally contained within the HTML file that corresponds to the web page 235.
Those of ordinary skill in the art will understand that the web pages illustrated in S Figures 6-8 are merely exemplary of a website that can be scraped. Such a website can be presented in many different ways. For example, the account summary information and transaction data may be presented on the same web page and may require scrolling.
Also, different types of transactions may be presented on different web pages.
For example, billed transactions may be presented on a different web page than unbilled transactions. Regardless of the organization scheme of the website, once the general format of data presentation is known, any and all desired transaction data can be obtained by the methods described herein.
The Account Website 164 (Figure 5) may utilize various security systems to provide a more secure environment for transactions with consumers. For example, the website 164 may use an encryption system, such as Secure Sockets Layer ("SSL"), to ensure privacy when communicating with consumers' web browsers. Preferably, the Scraping Module 170 is configured to open up a "socket" or SSL connection bet<veen the Scraping Service 162 and the website 164. Also, the website 164 may transmit and request digital certificates, such as those provided by companies such as VERISIGNT''', which permit the parties (the website 164 and a client browser) to verify each other's identity. Preferably, the module 170 is configured to accept the website's certificates and present its own certificates if requested by the website 164. Further, the website 164 may assign a session identification ("session ID") every time a login is initiated.
The session ID is typically a non-persistent cookie that a website stores in a client's web browser. The website may request the session ID every time the consumer requests to view a private web page. When the consumer logs off, the website 164 may invalidate the previously assigned session ID, so that the consumer cannot continue to view private web pages unless the consumer logs in again and receives a new session ID.
Preferably, the module 170 is configured to store the assigned session ID and submit it when requested by the website 164.

Preferred Method of Scrapin , Transaction Data When an individual consumer enters or accesses his or her online account on a website such as the illustrated Account Website 164 (Figure 5), the consumer may have to download a series of different web pages in order to view desired information, such as transaction information. For example, in the website described by Figures 6-8, a consumer must download a sequence of web pages to retrieve desired transaction information. Specifically, the consumer must (1) enter his or her account access information to download the web page 200, (2) click on the "STATEMENTS"
hyperlink 206 to download the web page 212, (3) choose a statement date from the drop-down menu 214 to download a web page 218, and, (4) activate a hyperlink to download the web page 235, which contains the desired transaction information.
The web pages 200, 212, 218, and 235 may be created by the web page construction engine 180 as the consumer navigates through the website 164. Thus, in order to scrape data from the ~veb page 235, the Scraping Module 170 preferably requests that the engine 180 constmct the web pages 200, 212, 218, and 235. The module 170 employs the HTML code for the web page 200 to obtain the URL for the web page 212. Then, the module 170 employs the HTML code for the web page 212 to obtain the URL for the web page 218. Then, the module 170 employs the HTML code for the web page 218 to obtain the URL for the web page 235. Once the module 170 has the URL for the web page 235, it can download the associated HTML file and copy transaction information therefrom.
Thus, in order to scrape desired data from an Account Website 164 (Figure 5), it may be necessary to navigate through a sequence of web pages according to a known protocol or program. The HTML files that correspond to the pages of such a "web page sequence" are normally constructed after the account session begins. These HTML files are herein referred to as "pathway files," since they define a navigation path that the Scraping Module 170 travels in order to scrape the desired data. Each pathway file in the sequence contains a network address, such as a URL, for the next pathway file in the sequence. The module 170 downloads the pathway files one by one in the sequence, extracting the address for the next pathway file after each download. The extracted address is then used to request the next pathway file in the sequence. The final pathway file in the sequence contains the desired data. Although described herein as HTML
files, pathway files may comprise any type of file used to display information over a wide area network.
With reference to Figure 5, in order to enable the Transaction Data Scraping S Service 162 to scrape transaction data from the Account Website 164, the customer 160 initially enters his or her account access data (e.g., username and password) into the Customer Account Access Data Storage 172 via the Customer Interface 168. This step is generally done only once, unless the customer access data is changed (e.g., a new password is set after an old password expires). The Scraping Module 170 uses the account access data to access the customer's account on the website 164.
Figure 9 illustrates a process of scraping a customer's transaction information from a website using the system of Figure 5. Initially, the Scraping Module 170 (Figure 5) opens an SSL connection or "socket" between the Transaction Data Scraping Service 162 and the website 164 (step 250). The process of opening a socket is well known in 1 S the an. The module 170 retrieves the customer's account access information from the storage 172, and transmits the information to the customer interface 176 of the website 164 (step 252). The web page constmction engine 180 creates the HTML files for a plurality of web pages that reflect the customer's current account status (step 254).
Normally, the engine 180 accesses current data from the consumer account information database 177 in creating the HTML files. Alternatively, the engine 180 could create each HTML file as it is requested, instead of creating all of the HTML files in one step af3er login. Next, the module 170 downloads the HTML file that corresponds to the web page presented after a customer logs in to the website 164 (step 256).
This is the first HTML file, or "pathway file," in the web page sequence that leads to the desired transaction data (or second, if the initial login web page is considered to be a part of the sequence). The module 170 scans the downloaded HTML file to find the URL of the next web page in the sequence or pathway (step 258). The module 170 may need to filter or parse the HTML code to isolate and copy the desired URL. The module then sends an HTTP request for the next HTML or pathway file in the sequence, and downloads the next HTML file (step 260).

The Scraping Module 170 repeats steps 258 and 260 until it downloads an HTML file containing desired transaction data (such as the web page 235 illustrated in Figure 8B), also referred to herein as a "final pathway file" or "transaction data web page" (step 262). The module 170 scans and parses or filters the HTML code of the final pathway file to obtain the customer's transaction data (step 264). This step is described in greater detail in Figure 10. The module 170 then stores the transaction data into a database, such as the Transaction Information Storage 174, preferably with an association to the specific customer (e.g., rewards program member) whose account was scraped (step 266). Finally, the module 170 downloads and parses additional HTML
files containing any other desired transaction data (step 268).
The process of scanning and parsing or filtering an HTML file for desired transaction data requires some knowledge of how the data is written into the HTML
code. Figure 10 shows a portion of 1-1TML code from a web page that lists multiple transactions, such as the web page 235 of Figure 8B. The portion of code shown in Figure 10 includes only one complete transaction entry 270. However, the entry 270 is normally just one of many transaction entries in the HTML file. Normally, all of the transactions are presented in a uniforn~ format on the web page. With knowledge of the presentation format, the HTML code can advantageously be scanned for tokens that are known to identify the content (e.g., transaction data) that is written into the code. As used herein, a "token" is a portion of HTML code. Typically, a specific token appears once for every transaction written into the code. For example, in the code shown in Figure 10, the text "width=100%," indicated by reference numeral 272, appears once for i each transaction entry. Thus, each occurrence of "width=100%" signifies a new transaction in the code. The Scraping Module 170 (Figure 5) is preferably configured to identify transactions in the illustrated portion of HTML code by scanning for such tokens 272.
Normally, each transaction written into the HTML code, such as transaction 270 in Figure 10, contains several different transaction data elements that can be identified by locating known tokens within the transaction. The illustrated transaction includes four data elements: a transaction date 274 (shown in Figure 10 as "03/14/00"), a post date 276 ("03/15"), a vendor/item description 278 ("WAL MART WATER"), and a currency amount 280 ("$48.32"). The Scraping Module 170 (Figure 5) is preferably configured to scan the transaction 270 for tokens that identify the individual data elements. For example, the module 170 can scan the transaction 270 for the first appearance of the token 'size-- '2">', indicated by reference numeral 282.
This token S immediately precedes the transaction date 274 of the transaction. Then, the module 170 can continue scanning the code for the first appearance of the token "</font>," indicated by reference numeral 284. This token immediately follows the transaction date 274.
The module 170 can then copy all of the data appearing between the tokens 282 and 284, which is the transaction date 274. Similarly, the module 170 can scan for tokens that precede and follow the other data elements 276, 278, and 280, and thereby obtain the post date, vendor/item description, and the currency amount. In the illustrated embodiment, the tokens that identify the data elements 276, 278, and 280 are the same as the tokens that identify the transaction date 274. In this case, therefore, the sequence in which these transaction data elements are presented is also known in order to associate the elements with the correct fields in the transaction information storage 174 (Figure 5). However, those of skill in the art will understand that the data elements in the transaction 270 may each be preceded and followed by different tokens in the HTML code. All that is required to obtain the desired transaction data is knowledge of the specific tokens that identify each data element.
Those of ordinary skill in the art will understand that the method described above may not require scanning for tokens that both precede and follow the desired data elements. The Scraping Module 170 may be configured to scan only for tokens that immediately precede (or immediately follow) the data elements, and then analyze the data that follows (or precedes) each token to identify the data element that is sought.
Further, it is not necessary to scan only for tokens that immediately precede or follow the desired data elements.
Figure 11 illustrates a process of scanning and parsing an HTML file for desired transaction data written into the HTML code. In the illustrated process, the HTML code includes transaction entries that include at least a transaction date, a vendor/item description, and a currency amount. The illustrated process scans only for the transaction date, vendor/item description, and currency amount. However, additional data elements in the transaction entries, such as the transaction post date, can also be scanned for if desired. Those of ordinary skill in the art will understand that any desired subset of data elements included within the transaction entries can be scanned for by the methods described herein.
With reference to Figure I1, according to the invention, the Scraping Module 170 (Figure S) identifies the transactions by scanning the HTML code for tokens that are known to precede the transactions. The module 170 initially scans the code for a first "transaction-identifying token" (step 286), such as the token 272 in Figure 10. The module 170 scans the HTML code following the first transaction-identifying token until it finds a token known to immediately precede the transaction date (step 288), such as the token 282 in Figure 10. The module 170 continues scanning the HTML code until it finds a token known to immediately follow the transaction date (step 290), such as the token 284 in Figure 10. The module 170 copies the text of the HTML code that appears between the tokens found in steps 288 and 290, and stores the copied text into a 1 S database, along with an identification of the copied text as the transaction date (step 292).
The Scraping Module 170 continues scanning the HTML code for tokens known to immediately precede (step 294) and immediately follow (step 296) the vendor/item description. The module 170 copies and stores the text appearing between the tokens found in steps 294 and 296, along with an identification of the text as the vendor/item description (step 298). The module 170 continues scanning the HTML code for tokens known to immediately precede (step 300) and immediately follow (step 302) the i currency amount. The module 170 copies and stores the text appearing between the tokens found in steps 300 and 302, along with an identification of the text as the currency amount (step 304). The module 170 can repeat these steps for any additional data elements, if desired. It will be understood that the data elements may be presented in a different sequence than as shown in Figure 10, and that the method described herein can be used regardless of the sequence of data elements in the transaction entries. When all of the desired data elements of the subject transaction are copied and stored, the module 170 continues scanning the HTML code until it finds the next transaction-identifying token (step 306). The module 170 repeats steps 288 to 306 until all of the desired transaction data is identified, copied, and stored (step 308).
The process illustrated in Figure 11 constitutes a scrape of one web page containing transaction data. Additional web pages can be scraped in the same manner.
S Generally, one customer's account may include a plurality of web pages that contain transaction data, any number of which can be scraped in the manner described.
Having scraped transaction data for one customer, the Scraping Module 170 (Figure 5) can continue scraping a website for transaction data of additional customers. In a preferred embodiment, the module 170 scrapes a plurality of customers' accounts at the same website 164 in one batch.
Once all of the desired transaction data is scraped from the website 164, it can be stored in any desired format. Figure 12 shows a list of transactions organized in three columns, corresponding to the transaction date, vendor/item description, and amount of currency for each transaction. The transactions in the list may represent any subset of 1 S transactional information from a scraped website, such as some or all of the transactions shown in a single customer's account(s).
Analysis of Scraped Transaction Data After a customer's transaction data is scraped and the transaction data elements are separated and stored, the data can be analyzed in any desired manner and for any desired purpose. In one application, the transaction data can be scanned to find any transactions with specific vendors. This application is particularly useful in administering a rewards program 65 (Figure 3), as described above, since the rewards program administrator would like to verify the customer's transactions with participating merchants 55.
In a normal credit card transaction, the transaction information (e.g., transaction time and date, location, vendor description, item description, and currency amount) is transmitted to the credit card company through a point of sale device [Is there a common name for this device?]. The device provides a vendor/item description that identifies the merchant, the goods purchased, and perhaps the store location (note that if the sale is over the Internet there is no store location) by a text string containing, for example, 5 to 100 characters. The text string may include any combination of letters, numbers, and other characters. Complicating matters, different store locations may describe the same merchant by different text strings. For example, one point of sale device may describe a transaction with the merchant MONTGOMERY WARDST'" as S "JKL*--1163092110 MONTGOMWARD." In this example, "1163092110" is a stock keeping unit ("SKU") number that identifies the product or service sold, and "MONTGOMWARD" identifies the merchant. A different point of sale device, perhaps at a different store location, might describe the same transaction as "FWT**--1163092110 WARD," in which "WARD" identifies the merchant. There may be any number of different substrings that point of sale devices use to describe the merchant.
In order to analyze a vendor description or text string to determine whether it describes one of a set of specific merchants, it is preferred to scan for each of the known substrings for each specific merchant.
Figures 13 and 14 illustrate a method of scanning transaction listings to find any 1 S transactions with specific merchants or that involve specific SKU numbers.
Each transaction listing may include, for example, a date, a vendor/item description, and a currency amount. Figure 13 is a flow diagram that illustrates the steps in the method.
Figure 14 is an example of a lookup table 320 for use in implementing the method. The table 320 includes a first column 322 and a second column 324. The first column 322, shown having the heading "WANT TO FIND," contains text strings that are desired to be scanned for, including, for example, SKU numbers and merchant descriptions.
The second column 324, shown having the heading "WANT TO AVOID," contains text strings that are to be'specifically avoided.
Each text string in the first column 322 of the lookup table 320 may correspond to one or more text strings in the second column 324 that include the string in the first column. For example, suppose the SKU number "1163092110" is the code for "black socks," and the SKU number "Al 163092110" is the code for "blue socks." Both strings contain "1163092110." It may be desirable to scan only for transactions involving black socks. However, since the SKU number for blue socks contains the SKU
number for black socks, searching the transactions for the SKU number for black socks will produce search results containing all of the transactions for both black socks and blue socks. Thus, the SKU number for blue socks is listed in the second column 324 of strings to be avoided. As another example, suppose the string "WARD" describes the merchant MONTGOMERY WARDST"'. Also, suppose that transaction description strings sometimes contain the substrings "EDWARD," "REWARD," and "AWARD."
It may be desirable to scan only for transactions with MONTGOMERY WARDSTnn Tlms, "WARD" is entered in the first column 322, and "EDWARD," "REWARD," and "AWARD" are entered in the second column 324. Some strings in the first column may not have any corresponding strings in the second column 324. For example, the string "MONTGOMWARD" may not be a substring of any strings that are to be avoided.
Figure 13 illustrates a preferred method of scanning a group or list of transactions for specific merchants or SKU numbers. Initially, the Transaction Analysis Module 171 (Figure 5) reads the text string of the first transaction (step 330). The module 171 then detemlines if the text string contains any substrings that are being scanned for, i.e., that appear in the first column 322 of the lookup table 320 of Figure 14 (decision box 332). If the text string does not contain any such substrings, the module 171 determines whether the analyzed transaction is the last transaction in the group (decision box 334). If not, the module 171 reads the text string of the next transaction in the group (step 336) and again asks if it contains any substrings that are specifically sought (decision box 332). For each transaction text string that does not contain any specifically sought substrings, the module 171 loops through steps 332, 334, and 336.
If a text string of a transaction contains a substring that is specifically sought (i.e., a "yes" answer in decision box 332), the Transaction Analysis Module determines whether the substring is part of a larger string that is to be specifically avoided, i.e., appears in the second column 324 of the lookup table 320 (decision box 338). For example, the module 171 may have determined in decision box 332 that the text string contains "WARD," but still needs to determine whether this substring is part of a larger undesired string, such as "REWARD." If not (i.e., a "no" answer in decision box 338), then the transaction is copied and stored in a separate database (step 340). If the substring is a part of a larger undesired string (i.e., a "yes" answer in decision box 338), then the transaction is not stored, and the module 171 proceeds to decision box 334: If the transaction is the last transaction in the group, then the module 171 stops the process (step 342).
It will be understood that the transaction listings can be analyzed for various other applications, by the methods herein described. For example, the transaction S listings can be scanned to find all transactions on a specific date or within a specific range of dates, or even within a specific time range within a single day.
Also, the transaction listings can be scanned to find any transactions of a specific currency amount. For example, the transactions can be scanned to find any transactions above $500, or within $450-$SSO. Many other applications will be apparent from the teachings herein.
Referring again to Figure 3, a preferred application or analysis of the transaction information supports the administration of a consumer rewards program 65.
Accordingly, the rewards analysis engine 82 scans the transaction listings associated with a customer 50, which are preferably stored in the transaction infom~ation storage 74, to find all of the transactions that the customer 50 made with participating merchants 55. In other words, the engine 82 scans for transactions containing vendor descriptions of participating merchants 55. The engine 82 may be configured to scan the promotional offers associated with the merchants 55 with which the customer 50 transacted, to determine if the customer's transactions satisfied the conditions of any of the promotional offers. If desired, the engine 82 can read the customer's activations of promotional offers associated with the merchants S5, which are preferably stored in the activation information storage 78, and determine whether the customer satisfied the conditions thereof.' Having verified the customer's transactions associated with the promotional offers, the engine 82 preferably adjusts the customer's rewards account accordingly.
Although this invention has been disclosed in the context of certain preferred embodiments and examples, it will be understood by those skilled in the art that the present invention extends beyond the specifically disclosed embodiments to other alternative embodiments and/or uses of the invention and obvious modifications and equivalents thereof. Further, the various features of this invention can be used alone, or in combination with other features of this invention other than as expressly described above. Thus, it is intended that the scope of the present invention herein disclosed should not be limited by the particular disclosed embodiments described above, but should be determined only by a fair reading of the claims that follow.

Claims (37)

1. A method of administering a consumer rewards program in which rewards are offered to consumers for consumers' purchases of advertised goods and services of participating merchants, comprising:
receiving a consumer's indication of an interest in a promotional offer associated with a selected one of said participating merchants in exchange for an offered reward;
scraping transaction information from said consumer's online credit card account; and scanning said transaction information for purchase data indicating that the consumer made a purchase from the selected merchant associated with the promotional offer in which the consumer had indicated interest.

2. The method of Claim 1, further comprising giving said consumer said offered reward if said scraped transaction information contains said purchase data.

3. The method of Claim 1, wherein said promotional offer has specific conditions that the consumer must satisfy in order to receive said reward, said method further comprising scanning said transaction information for condition satisfaction data indicating that the consumer satisfied said specific conditions.

4. The method of Claim 3, further comprising giving said consumer said offered reward if said scraped transaction information contains said purchase data and said condition satisfaction data.

5. The method of Claim 1, further comprising informing said selected merchant whether said scraped transaction data contains said purchase data.

6. The method of Claim 3, further comprising informing said selected merchant whether said scraped transaction data contains said purchase data and said condition satisfaction data.

7. The method of Claim 1, said method being implemented by a computer program.

8. A rewards program system in which rewards are offered to consumers for consumers' purchases of advertised goods and services of participating merchants, comprising:

a consumer interface configured to display rewards offered for purchases from a selected one of said participating merchants; and a transaction information scraping engine configured to scrape transaction information from said consumer's account on an account website;
wherein said rewards program system gives said rewards to consumers for purchases.

9. The rewards program system of Claim 8, further comprising a rewards analysis engine configured to scan transaction information scraped by said transaction information scraping engine, in order to find purchase data indicating whether a consumer purchased selected goods and services from a selected merchant.

10. The rewards program system of Claim 8, wherein said rewards are offered with specific conditions that the consumers must satisfy to receive the rewards, said rewards analysis engine configured to scan transaction information scraped by said transaction information scraping engine, in order to find condition satisfaction data indicating whether a consumer satisfied the specific conditions associated with an offer.

11. The rewards program system of Claim 8, wherein said transaction information scaping engine is configured to scrape transaction information from HTML
files associated with web pages.

12. The rewards program system of Claim 8, wherein said transaction information scaping engine is configured to scrape transaction information from a private online credit card account.

13. A method of obtaining transaction information from a consumer's private online account, comprising:
transmitting account access information to said account in order to access said account; and obtaining transaction information from said account;
wherein said accessing and obtaining steps are automated.

14. The method of Claim 13, wherein said transaction information comprises information relating to purchasing transactions.

15. The method of Claim 14, wherein said transaction information includes one or more of dates, vendor identifications, vendor locations, and currency amounts of said transactions.

16. The method of Claim 13, further comprising storing transaction information from different online accounts in a common database.

17. The method of Claim 16, further comprising providing access to said database to others.

18. The method of Claim 13, further comprising using said transaction information to verify said consumer's transactions made in connection with a rewards program.

19. The method of Claim 13, wherein said account is accessible via an Internet site.

20. The method of Claim 13, wherein said access information comprises said consumer's username and password for said online account.

21. The method of Claim 13, wherein said transaction information is initially stored in code readable by an Internet browser, and obtaining comprising:
downloading at least a portion of said code; and extracting said transaction information from said portion of said code.

22. The method of Claim 21, wherein said code is HTML code.

23. The method of Claim 21, wherein extracting comprises:
scanning said code for a first transaction-identifying token known to precede text that contains data elements relating to a first transaction;
scanning said text for a token known to precede a desired data element of said first transaction; and storing said data element in a database.

24. The method of Claim 23, wherein said data element comprises one of a transaction date, vendor/item description, and an amount of currency.

25. The method of Claim 23, wherein extracting further comprises repeating said scanning said text, scanning said code and storing for additional data elements relating to said first transaction.

26. The method of Claim 23, wherein said extracting step further comprises repeating said two scanning steps and said storing step for each of an additional number of transactions having associated data elements written into said code.

27. A method of obtaining a set of data included within a consumer's private account maintained on an account information site accessible over a public network, said account being accessible only when one or more private access codes are transmitted to said site, the method comprising the following computer-implemented steps:

transmitting said one or more private access codes to said site, which causes said site to permit access to said account;
receiving a pathway file from said site, said pathway file including a network address for a next pathway file in a sequence of pathway files;
scanning the received pathway file to find the network address of the next pathway file in said sequence;
requesting the next pathway file in said sequence by transmitting the network address of the next pathway file to said site;
repeating said receiving, scanning, and requesting steps for additional pathway files in said sequence, if any, until a final pathway file is received from said site, said final pathway file including said set of data; and scanning said final pathway file to find said set of data.

28. The method of Claim 27, wherein said set of data comprises purchasing transaction information.

29. The method of Claim 28, wherein said transaction information comprises a list of transactions, each transaction including one or more of a transaction date, vendor description, and currency amount.

30. The method of Claim 27, wherein said network comprises the Internet.

31. The method of Claim 27, wherein said pathway files comprise HTML
files.

32. The method of Claim 27, wherein the network addresses of the pathway files comprise URLs.

33. A method of advertising, comprising:

displaying advertisements to a plurality of consumers;
periodically and automatically obtaining transaction information of said plurality of consumers by mining said transaction information using consumer online account access information; and matching consumer viewing of said advertisements with actual purchases reflected in said transaction information, said purchases associated with said advertisements.

34. The method of Claim 33, wherein said advertisements comprise promotional offers in a rewards program.

35. The method of Claim 34, wherein displaying further comprises accepting consumer indications of interest in said promotional offers.

36. The method of Claim 35, wherein matching comprises correlating said consumer indications of interest with said actual purchases.

37. The method of Claim 36, further comprising crediting a consumer rewards account when an indication of interest is matched with an actual purchase.