Abstract:
A system and method for constructing an ID code for a loyalty program from non-restricted information from a payment card or other ID card having restricted information.

Description:
This application claims benefit of 60/397,046, filed Jul. 19, 2002. 

   FIELD OF THE INVENTION 
   The present invention generally relates to the use of an identification (ID) card issued for another purpose as the ID for a Loyalty program. Many ID cards, such as payment cards, have restrictions on the use of the “account number” or “account code” that prevent a merchant who is accepting payment card from using the Account Code for any purpose other than payment. 
   BACKGROUND OF THE INVENTION 
   With the advent of permission-based marketing, loyalty programs, and other marketing approaches that use the customer&#39;s identification card to trigger the promotions to the customer, it has been demonstrated that the more information collected about the customer, the more successful the promotion. Additionally, if frequent customers are rewarded by these systems, the loyalty of the customer is improved, resulting in increased business for the merchant. Since one of the most significant expenses related to setting up of a loyalty program is the issuance of IDs to the customers, the cost of the setup will not proportionate to the size of the merchant. This discourages small merchants from using loyalty programs as marketing tools. 
   A second problem is that existing loyalty programs have found that the customers dislike systems where two cards must be “swiped” in order to complete a transaction. Thus, loyalty programs based on both an ID card and a separate payment card have proven to be less successful than ones based on a combined payment card/loyalty card, like those issued by some petroleum companies. 
   The use of various bankcards has come into common use for payment of transactions. These bankcards are scanned at the point of sale. They contain a unique identifier for the user. These identifiers are variously called “Account Code”, “account number” or another name. The term “Account Code” will be used herein to mean any of these, as there is no need that the Account Code be strictly numeric. Unfortunately, some of the fields have restricted use, namely the unique identifier Account Code. Other items encoded on the card are not restricted, but are not unique. 
   The present invention uniquely uses the non-restricted information to develop a customer ID that has a low probability of having duplicates, such that the customer ID can be used in a loyalty program, thereby reducing the cost of the deployment of a loyalty program. 
   SUMMARY OF THE INVENTION 
   A second ID for the user of ID cards having restriction on the use of the Account Code in a manner such that the second ID code has a lower probability of being duplicated in the retail store than an ID code derived from the Card Holder Name field. 
   The present invention associates the derived ID code used by an entity to that entity, based on the information extracted from the cards. 
   A system in the form of programming instructions and computing equipment embodied in one or more servers and peripheral equipment, that provides a loyalty program to customers of a retail store. This system provides for the following: definition of rules for extraction of unrestricted information from ID cards, a synthesis means for converting the extracted information into a second ID code, and a database means for storing the results of the correlation. 
   When the system is running a control mechanism extracts the unrestricted information from the ID card, constructs the second ID code, and uses the second ID code to access the loyalty program for the retail location where the ID card has been used. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is a diagram of a computer System, which is adapted to perform the method of the invention. 
       FIG. 2  is a diagram of a computer system representative of a Point-of-Sale Terminal. 
       FIG. 3  is a diagram of a computer system called the Venue Server. 
       FIG. 4  is a data table that describes an Identification Card. 
       FIG. 5  is a data table that describes the User Table. 
       FIG. 6  is the ID Construction Routine. 
       FIG. 7  is a diagram of the Transform Routine. 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     FIG. 1  is a diagram of a network of computers adapted to perform the method of the invention. Venue Server  101  is connected via LAN  100  to one or more Point-of-Sale Terminals  102 . Normal Point-of-Sale Terminal activities are conducted between the Venue Server  101  and Point-of-Sale Terminal  102 . 
   In a retail store, there is a Venue Server  101  coordinating the activities of one or more Point-of-Sale Terminals  102 , which are used to process customer transactions. When a loyalty program is implemented the Venue Server  101  maintains records of the customer and the rewards that customer is due. When the customer is identified at the Point-of-Sale Terminal  102  by reading a payment card or other ID card, the system described herein, uses the information in the card to produce a User ID  500  (See  FIG. 5 , User Table) from the information in the identification card (See  FIG. 4 , Identification Card), using a set of transforms described in  FIG. 6 , ID Construction Routine and  FIG. 7 , Transform Routine. 
     FIG. 2  is a diagram of a Point-of-Sale Terminal seen in FIG.  1 . Point-of-Sale Terminals are configured using a Cash Register Microcomputer  207  of conventional design. Attached to the Cash Register Microcomputer  207  are various input and output devices including: a LAN  209 , Printer  200 , Clerk Interface  201 , User Interface  206 , and Magnetic Stripe Reader  202 . The Clerk Interface  201  is normally involved with checkout processing. Output device, Printer  200 , is for hardcopy printouts such as receipts, advertisements, coupons, and other information. These are attached via electronic Local Bus  208  links, which normally are serial IO like an RS232 serial port. Magnetic Stripe Reader  202  reads the user ID card and provides the contents to Application  310  in  FIG. 3 , Venue Server, which performs the method of this invention as described in  FIG. 7 , Construction of User ID. Processor Memory  203  contains Application  204  and Application Data  205  needed to run  FIG. 2 , Point-of-Sale Terminal. 
   During the course of the customer&#39;s transaction, the customer swipes a payment card or other identification card in Magnetic Stripe Reader  202 . This information travels by way of Local Bus  208  to the Cash Register Microcomputer  207  to the Venue Server  101  where it is processed as described above. The Loyalty Application communicates with the customer using User Interface  206  and Printer  200 . 
   The Clerk Interface  201  is present in attended retail checkout stations, such as is found in grocery stores, pharmacies, and convenience stores. It is not present, nor is it required by this invention, in unattended environments, such as gas dispensers, ATMs, or self-checkout grocery stations. 
     FIG. 3  depicts venue server  101  from FIG.  1 . Venue server  101  is described as though it is implemented as a separate computer system; however, the function provided can be performed by other computer systems in the venue or remotely from the venue via communications lines. CPU  300  controls the various components by the logic described in the programs in Program Memory  309 . Internally various components communicate via Local Bus  308 . Tables and databases are in Data Memory  302 . These are stored on Disk Drive(s)  306  for long-term storage. The tables used are: Identification Card  303  (described in  FIG. 4 , Identification Card) and User Table  304  (described in  FIG. 5 , User Table). Additionally, there is the data required for the Loyalty Application  311 , which is stored in Loyalty Program Database  305 , which is dependent on the loyalty program for its format. Application  310 , in Program Memory  309 , makes use of commercially available Database Software  301  to provide storage, selection and retrieval functions that it needs to perform the store functions. 
   During the course of Point-of-Sale transactions the users Identification Card information is captured and Application  310  routes that information to Loyalty Application  311 , initiating processing of the application. Loyalty Application  311  subsequently uses ID Construction Routine  312  to build the User ID  500 , which is used by the Loyalty Application  311  to access  FIG. 5 , User Table, enabling the loyalty program&#39;s function. While this embodiment is in the context of a loyalty program, it works equally well for any application that needs to use an ID and has access to the information on a user identification card that was not intended to be used with that application, and has restrictions on the use of some of the data on the ID card. 
   Venue server  101  also communicates via Local Area Network Adapter  307  to LAN  100  in FIG.  1  and other components of the system. 
     FIG. 4  is the Identification Card. It contains Format Code  400  that is used to distinguish the card format. In this embodiment it contains a “B”, which indicates the following format: Account Code  401  that is up to 19 characters in length, Country Code  402  that is three characters, User Name  403  that is from 2 to 26 characters long, Expiration Date Year  404  that is two characters in YY format, Expiration Date Month  405  that is two characters in MM format, Optional Data  406  that is enough to fill out a maximum track length of 79 characters, and LRC  407 . These are read from the users Identification Card. Some possible types of Identification Cards are Credit, Debit, ATM, and Loyalty cards. In this embodiment, the format shown is extracted from the ISO/IEC standard 7811; however, any standard that can be distinguished from the ISO/IEC standard by using Format Code  400  can be used. Other embodiments could use any well-defined format to accomplish the same effect. 
     FIG. 5  illustrates User Table that contains a User ID  500  which is the ID used in the Loyalty Application  311  and is generated by  FIG. 6  ID Construction Routine. It also contains User Name  501 , which is extracted from  FIG. 4 , Identification Card, and Loyalty Program Data  502 , which is specific to the loyalty program implementation and is not described herein. 
     FIG. 6 , ID Construction Routine starts with control in Step  600  which accepts the previously read card stripe information as in  FIG. 4 , Identification Card and extracts the Account Code  401 , User Name  403 , Expiration Date Month  405 , Optional Data  406  and LRC  407 . It then passes control to Step  601 . 
   Step  601  calls the  FIG. 7 , Transform Routine to produce an intermediate form of the desired User ID  500 , and then passes control to Step  602 , which passes the final form of User ID  500  to the requesting program. In this case it would be a loyalty program, but in other embodiments it would be returned to other applications. 
     FIG. 7  illustrates details of the Transform Routine, which is entered at Step  700  and accepts the Account Code, Country Code, Name, Expiration Month, Expiration Year, Optional Data, and LRC from the calling routine. 
   Control then passes to Step  701 , which backs out the data that is not preserved when a card is reissued or renewed. That data is normally the Country Code, Expiration Year, and Optional Data. The back-out is performed using the inverse operation that was used to compute the LRC  407 . In this embodiment an Exclusive-Or is used. The control passes to Step  702 . 
   Step  702  compresses User Name  403  into a dense code using a Huffman code producing a compressed user name. In other embodiments other compression algorithms may be used, including not compressing the field. Next the compressed user name and the fields selected to contribute information to the User ID  500  (Expiration Date Month  405 , and LRC  407 ) are concatenated, and a CRC is calculated over the concatenated data, yielding a number that is used as the User ID  500 . In other embodiments various combinations of the  FIG. 4 , Identification Card fields and sub-fields can be used to implement the invention. An example of a sub-field would be the use of the first 8 digits of the Account Code  401 , as would be allowable when the restriction on the use of Account Code  401  applies only when the entire Account Code  401  can be reconstructed from the derived field or fields. Additional, other embodiments can use methods other than a CRC calculation to produce a User ID  500  that contains information from all the data elements used to produce it. Some algorithms suitable are: Universal Hash algorithms, encryption, arithmetic folding, and division using the remainder as the ID.