TECHNICAL FIELD

[0001 ] This invention pertains to the field of networked hardware, data structures, and automated methods associated with point-of-sale automated data collection, and more particularly to such data structures and methods for resolving the identity of consumers interacting with an automated point-of-sale (POS) system.

BACKGROUND ART

[0002] References mentioned in this background section are not admitted to be prior art with respect to the present invention.

[0003] Retailers operating brick-and-mortar stores have long recognized that it would be advantageous to identify consumers who make a purchase at a particular point of sale (POS). With this information, the retailer could recognize its most valued customers and offer them special incentives, and also may be able to more precisely target its marketing efforts to consumers based on their purchase history with the retailer. If the consumer utilizes an electronic enabled tender type, such as a debit card, credit card, electronic wallet, or electronic check, then the retailer may learn the name of the consumer through this transaction. This information is pulled from the tender method using electronic POS systems. But the name alone does not allow the retailer to uniquely identify a consumer because names are not unique, and thus the retailer has no way of knowing which of any number of consumers who share that name actually made the purchase.

[0004] One attempt to overcome this problem is the issuance of loyalty cards or similar electronic devices to consumers. In this approach, the retailer maintains a database that associates the code on each loyalty card with the particular consumer to whom the card is issued. This database is linked with the retailer’s POS systems. When a purchase is made, the consumer is enticed to present the card at the POS in order to receive discounts, loyalty points, or the like. The retailer can unambiguously identify a consumer at the POS using this method, but the method requires the consumer to present the loyalty card at each purchase. Many consumers do not like using loyalty cards, or they may lose or misplace their cards, in which case no data may be captured at the POS concerning the consumer and the consumer’s purchases.

[0005] Another attempt to overcome this problem is known as trade area append.

This approach utilizes a broad-based consumer database containing matched names, addresses, and various other data about consumers within a certain jurisdiction. For example, one such database is the InfoBase database maintained by Acxiom LLC, which tracks a large range of demographic and other data about consumers in the United States. The trade area append approach takes the consumer name derived from the tender data received at the POS, and then looks for a record in the consumer database with both a matching name and a residential address that is within a defined trade area around the physical location of the retailer POS. If a match is found, then this consumer is presumed to be the purchaser because consumers shopping at a brick-and-mortar retailer are likely to reside in the area near the retail location.

[0006] The trade area append approach has a number of shortcomings. First, duplicate consumer names may be found within the defined trade area. In this case, there is no additional data by which the system may break the“tie” between the different consumers in the trade area with the same name, and so it is impossible to determine which of these consumers engaged in the purchase transaction. Reducing the size of the trade area lessens the risk of duplicate consumer names being returned, but also increases the risk that a consumer may be entirely missed. Second, a consumer may reside outside of the trade area and nevertheless be shopping at a particular retailer. This may occur, for example, when the consumer is travelling, or the consumer may simply be willing to travel farther than expected in order to shop at a retailer the consumer finds particularly desirable. In this case, the trade area append approach may return no hits. Third, even if a single name is returned by trade area append, it is possible that the consumer who engaged in the transaction resides outside of the trade area and just happens to have the same name as a single consumer who does reside in the trade area. In this case, the trade area append approach will return a single result, but the result will be incorrect.

[0007] Due to the limitations of existing systems for resolving consumer identity based on tender data at a retailer POS, an improved database structure and electronic system to perform this function, which is capable of unambiguously resolving the identity of the consumer more accurately than trade area append yet without the requirement of loyalty cards, would be highly desirable.

DISCLOSURE OF INVENTION

[0008] The present invention is directed to an improved system and method for identifying a consumer at a retailer POS that incorporates a virtual wallet database and a consortium processor into a network. The virtual wallet database contains consumers’ names, addresses, card data, and other identifiers. The consortium processor, which utilizes a database or databases not directly accessible by the retailer, maintains information known to the provider of the electronic tender method utilized by the consumer. In order to protect the privacy of consumers, applicable regulations in many jurisdictions prevent such providers from supplying to the retailer the full data maintained in their databases. The consortium processor may be maintained by, or utilize data provided by, a consortium of financial services providers, including but not limited to the various entities that issue credit cards. Alternatively, or in addition to, the financial services providers, the consortium may include payment processors, which are companies appointed by a merchant to handle transactions for banks; TSYS is one example of a payment processor.

[0009] In certain implementations, the system first checks tender data from a retailer POS against the virtual wallet database. If a match is found, then the consumer identity is confirmed. If there is no match from the virtual wallet database, then a trade area append routine is employed in an effort to find a matching consumer within the retailer POS trade area. If no match is found, then the record is flagged as unidentified. If a match is found using trade area append, the applicable address is attached to the consumer data captured at the POS, and this record is sent to the consortium. The consortium compares this data to its own records, and returns a simple match or no-match (i.e. ,“yes” or “no”) result. The virtual wallet database is then updated with newly identified consumers or a new tender type is added to an existing record for a consumer in the database, as applicable. In the case of multiple potential matches, the process may be run multiple times up to the match request at the consortium.

[0010] These and other features, objects and advantages of the present invention will become better understood from a consideration of the following detailed description in conjunction with the drawings as described following:

BRIEF DESCRIPTION OF DRAWINGS

[0011 ] Fig. 1 is a schematic illustrating the components of a system according to an implementation of the invention.

[0012] Fig. 2 is a flow chart illustrating the steps of a real-time method according to an implementation of the invention.

[0013] Fig. 3 is a flow chart illustrating the steps of a batch method according to an implementation of the invention.

BEST MODE FOR CARRYING OUT THE INVENTION

[0014] Before the present invention is described in further detail, it should be understood that the invention is not limited to the particular implementations described herein, and that the terms used in describing the particular

implementations are for the purpose of describing those particular

implementations only, and are not intended to be limiting. The scope of the present invention will be limited only by the claims.

[0015] Referring to Fig. 1 , the major components of a system used to implement the present invention according to one implementation may be described. The retailer point of sale (POS) system 10 refers to the electronic systems and network components physically located at the retail location where a consumer makes a purchase, and where the tender information (such as card number and issuer information) are ingested while processing payment for the goods or services provided to the consumer. Retailer POS system may, for example, be a card reader networked to a register at the retailer point of sale, but in other embodiments may consist of any method for a retailer to receive electronic payment information for a transaction. This data is passed via an electronic network to an“enhanced” trade area append (TAA) processor 40, which may be implemented as software executing on a computer server or servers. TAA processor 40 is maintained by the provider of the consumer resolution service, and its functions are more fully described with reference to Fig. 2 below.

[0016] TAA processor 40 communicates with the consortium check processor 46 in order to bounce the prospective identifier (e.g., consumer name/address or, for cards with embedded chips, an encrypted packet) match against the one or more consortium processor databases 44 in order to determine if the prospective identifier match is in fact correct. This processing only occurs if electronic payment data is received in a transaction with a consumer whose data is not already found in a record at one or more virtual wallet databases 42, which are in communication with TAA processor 40. It may be noted that although two virtual wallet databases are illustrated in Fig. 1 , the system can include any number of physically separate databases in order to implement the functionality of virtual wallet databases 42. Virtual wallet databases 42 track the matched name, address, card data, and other information for a consumer that was gained through previous transactions, and also allow for updates from TAA processor 40 once a new match is made.

[0017] As will be explained in more detail below with reference to Fig. 2, TAA

processor 40 may, in some implementations, be in communication with a comprehensive computer database or databases, such as may be made available from a third-party data services provider. The comprehensive computer database provides address data for a consumer if there is no record

corresponding to that consumer in the one or more virtual databases 42. This information is passed to real-time consortium check processor 46. Alternatively, the retailer may maintain its own database that serves the same purpose as a data provider comprehensive computer database. The information in this retailer database may be populated with data from a data services provider, or may be collected in any alternative manner.

[0018] Real-time consortium check processor 46 serves as a front end to one or more consortium partner processors 44. It receives a message from TAA processor 40 in order to check whether the candidate identifier (e.g.,

name/address) match for a particular consumer does in fact correspond to a consumer with the particular tender data presented electronically to retailer POS system 10. Each of the consortium partner processors receives the tender data, and compares it to its own internal databases. These databases may, for example, be consumer databases maintained by credit card issuers. This type of data cannot be made directly available to retailer systems in order to protect the privacy of the consumer card holders. Card issuers are required by applicable regulations to protect this information. The real-time consortium check processor 46 thus serves as an intermediary that protects against any possible disclosure of information between the consortium partners and the retailer.

[0019] TAA processor 40 can send a message to retailer system 48 at customer real-time intake process 50 in order to provide the retailer with information that is gained after a successful real-time check at consortium check processor 46. The system also allows for batch updates to retailer system 48 through batch intake process 52 from virtual wallet databases 42. In this implementation of the invention, a staging server 56 may be used to communicate batch information from consortium partner batch databases 54. This allows the invention to operate either in real-time mode, during which a check is made as to the correctness of the prospective identifier match while the transaction is

processing, but also allows for the various updates to take place at a later time and the results delivered in batch mode. Batch mode updates may be delivered at regularly scheduled intervals, such as daily.

[0020] Turning now to Fig. 2, the steps in a real-time automated process using the system described with reference to Fig. 1 may now be described. Processing begins at POS system 10, where the identifier and tender data are received through some form of electronic payment at step 12. At decision block 14, the Enhanced TAA processor determines if the information input at POS system 10 matches a record already resident in a virtual wallet database 42. If so, then a confidence score for that consumer’s identity is assigned at step 16, system logs are updated at step 18, and processing returns to the client (i.e. , the retailer computer system) at step 20. No other matching is required in this case because this consumer has apparently already performed a transaction while the system was employed, whereby that consumer’s data was previously added to a virtual wallet database 42.

[0021 ] If the information input at POS system 10 does not match a record already resident in a virtual wallet database 42, then at step 22 a trade area append process is performed. In this step, assuming the identifier is a consumer name, then the consumer’s name is matched against a comprehensive consumer database containing consumer names and addresses. For each consumer record with a matching name that is found, the system then executes code to determine if that consumer resides within a defined trade area of the retailer.

The trade area may be defined in any of a number of ways, such as a defined absolute distance from the retailer; a defined road-travel distance from the retailer; or a metropolitan statistical area in which the retailer is located. These examples are not limiting, and any number of other trade area definitions may be employed. The result of this step is a prospective match between the consumer name and an address for that consumer.

[0022] At step 23, it is determined if the consumer name is found as a result of the trade area append from decision block 23. If not, then a no-match result is returned at step 25, and processing proceeds to block 18 to update logs and then step 20 to return the result to the client as before. If the consumer name is found in the trade area step 22 as asked at decision block 23, then processing proceeds to decision block step 24, at which the prospective consumer name and address are sent to consortium check processor 46, and the returned data indicates whether or not this is a correct match. This returned data may include a string indicating a match, such as“yes” and“no” options or Ύ” and“N” options, or may be a single bit, with options of“1” or“0” indicating whether a match was made. Any number of other means of communicating this information may be employed in other implementations.

[0023] If a match is returned by consortium check processor 46, then the virtual wallet database 42 is updated with the consumer tender data at block 26, and processing continues at step 16 as described above. In this case, the system has successfully identified an individual consumer despite the fact that the individual consumer was not present in a virtual wallet database 42. But because the virtual wallet databases 42 are updated at step 26, subsequent processing with respect to this consumer using this particular tender data will result in a“yes” result at decision block 14, thereby avoiding the necessity of trade area append and the electronic communications to and from consortium check processor 46.

[0024] If, at decision block 24, the prospective consumer name and address are not yet confirmed as a match or no-match result based on the response from consortium check processor 46, then processing moves to step 28, where the prospective data is held in a queue for an unconfirmed match. A poll is conducted at decision block 30, checking to see if the time for the data being held in the queue exceeds a set time limit. If it does not, then processing moves back to step 22, where the trade area append is run again. Note that this process can be repeated any number of times based on the timer setting. It should also be noted that this process can be repeated for multiple prospective matches; for example, if the trade area append processing at step 22 returns two or more potential consumer name and address matches, then each of those may be checked at step 24 by communications to/from consortium check processor 46.

[0025] Once the timer is exceeded at decision block 30, then processing moves to block 16 to assign a confidence code, and then to step 26 to update the virtual wallet database with the matched consumer information. In addition, logs are updated at step 18, and processing returns to the client at block 20. The confidence codes are assigned based on the quality of the match. In one example, the following codes are assigned:

400: found in virtual wallet

300: name/address/consortium match

220: name/address match

200: name/consortium match

150: address/consortium match

The logs are stored in a JSON format and holding the timing, unique transaction IDs, dates, status codes, match confidence, consortium member ID, and information sent to the services provider. Information returned from the services provider is used for tracking, reporting, and invoice creation. [0026] Referring now to the flow diagram of Fig. 3, a batch mode operation can be described with respect to certain implementations of the present invention. Each consortium member can send updated data in refresh files, shown at block 36. The first step of the process is to attempt to assign a unique key based on information from the name, address, or other information on the record at step 38. This record will update the consortium database tables in the virtual wallet at step 40. After the new records are added, all existing unconfirmed records 23 are merged at step 44 with new added records 21. The purpose is to find new matches. If no match is found when the new records arrive, they remain unconfirmed records at step 56 and are checked to see if the data has reached contract expiration time at step 58. If the records are still within the contracted archive period, then there is no further processing and the process ends at step 62. If the records have reached the contracted archive period, then the record is marked for deletion in the virtual wallet database at step 60, and will be removed in the next maintenance window.

[0027] If a match is found at step 46, then the virtual wallet is updated at step 48, the correct confidence code is assigned at step 50, and the status of each such record is changed to confirmed at step 52. Processing then returns to the client at step 54.

[0028] Unless otherwise stated, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, a limited number of the exemplary methods and materials are described herein. It will be apparent to those skilled in the art that many more modifications are possible without departing from the inventive concepts herein.

[0029] All terms used herein should be interpreted in the broadest possible

manner consistent with the context. When a grouping is described herein, all individual members of the group and all combinations and subcombinations possible of the group are intended to be individually included in the disclosure. When a range is described herein, all subranges and individual points within that range are intended to be separately included in the disclosure. All references cited herein are hereby incorporated by reference to the extent that there is no inconsistency with the disclosure of this specification.

[0030] The present invention has been described with reference to certain

preferred and alternative implementations that are intended to be exemplary only and not limiting to the full scope of the present invention, which is set forth solely in the appended claims.