System and method for secure provision of customer data in a loyalty program

CROSS REFERENCE TO RELATED APPLICATIONS

0001This application claims priority to, and is a continuation of, U.S. Ser. No. 13/290,740, filed Nov. 7, 2011, and entitled “System and Method for Secure Management of Customer Data in a Loyalty Program.”

FIELD OF THE INVENTION

0002The invention relates generally to data security and, more particularly, to the secure management of customer data in a loyalty program.

BACKGROUND

0003When a customer joins and utilizes a loyalty program of a merchant, a great deal of customer data may be collected and maintained. Although some such data is utilized in performing transactions such as effectuating payment and confirming membership, some customer data that is collected may also be useful for purposes beyond those necessary in conducting a transaction. For example, customer information may prove valuable to merchants for marketing to the most promising customers. By providing offers to customers associated with certain characteristics within certain demographics, a merchant can increase the return on marketing efforts that would be more expensive to administer to larger populations.

0004The customer also potentially benefits from sharing such information by, for example, receiving information on products potentially relevant to his or her interests. As such, a customer may be encouraged to join a loyalty program of a particular merchant, in which case rewards may be offered to the customer partly in exchange for the ability to use his or her information to market more effectively. Conventionally, however, membership in such a loyalty program has often been accompanied by problems. One problem is that the customer may become inundated with offers and advertising via email, postal mail and so forth. Compounding this problem is the common practice of businesses selling customer information to other businesses, marketing companies, mailing lists and so forth, thereby further increasing the amount of unwanted offers and advertising. This dissemination of customer information may also pose a security risk, as it may be used by others to compromise financial accounts and personal identities. Furthermore, when such problems occur, it may be difficult or impossible for the customer to undo the damage thereafter.

0005Aware that these problems exist, a customer who might otherwise choose to participate in a loyalty program may decide to forgo participation, thereby depriving the customer, merchant and potentially other businesses from the marketing advantages that could have been obtained. Therefore, a need exists for a means of managing customer data and utilizing such information for marketing purposes without compromising the interests, preferences or security of the customer.

SUMMARY OF THE INVENTION

0006The invention overcomes the limitations of the prior art by providing a method and system for anonymous marketing to participating customers in a loyalty program. Customer data is obtained from the participating customers and stored in a customer database. The customer data includes, for each customer, personal identification data which inherently reveals the identity of the customer and/or a means for directly contacting that customer. For a business entity that wishes to utilize the customer data for marketing purposes, anonymous customer data is provided to the business entity without sharing the personal identification data with the business entity. An anonymous designation of target customers is then obtained from the business entity based on the anonymous customer data. Marketing information is then provided to the target customers on behalf of the business entity without ever having shared personal identification data with the business entity.

0007In various embodiments, the loyalty program may be one of a number of loyalty programs made available to customers of a corresponding number of different merchants. The program may be implemented in part by a loyalty server including a loyalty gateway and customer database. The loyalty gateway may include a customer server component for interacting with the customers such as via communication with a loyalty wallet installed on a mobile communication device of a customer. The loyalty gateway may further include a business server component for interacting with business entities interested in marketing to participating customers. Such a business entity might be a participating merchant in the loyalty program, a non-participating merchant, or a marketing entity that further disseminates customer related data to other businesses. The loyalty server may further provide a means for providing marketing information to target customers by email, text message, postal mail or via a software application such as the loyalty wallet application.

0008The anonymous customer data may be provided in the form of group data that represents a number of customers and does not reveal the personal identification data of any individual customer. The anonymous customer data may also be provided in the form of anonymized individual data that can be uniquely referenced by a handle having an association with personal identification data where such association is maintained within the loyalty server but not provided to business entities. In various embodiments, the anonymous customer data of a given customer may be provided to business entities only with the permission of that customer, in which case the customer may also be compensated for such permission in a variety of ways. The anonymous designation of customers may be obtained from the business entity in the form of a selection of handles as explained above. Alternatively, the business entity may specify criteria to apply in selecting target customers. The business entity may also provide marketing content to the loyalty server to be provided to the target customers, or may provide a selection of content maintained by the loyalty server. Marketing information may be provided to a customer only with the permission of that customer, in which case the customer may also be compensated for such permission in a variety of ways.

BRIEF DESCRIPTION OF EXEMPLARY DRAWINGS

0009A more complete understanding of the present invention may be derived by referring to the detailed description and claims when considered in connection with the Figures, wherein like reference numbers refer to similar elements throughout the Figures, and:

0010<figref idref="DRAWINGS">FIG. 1</figref> is a system diagram illustrating system components for automatically enrolling and participating in a merchant loyalty campaign in accordance with an exemplary embodiment of the present invention;

0011<figref idref="DRAWINGS">FIG. 2</figref> is a flow diagram illustrating an automatic enrolment process in accordance with an exemplary embodiment of the present invention; and

0012<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram illustrating a payment transaction in accordance with an exemplary embodiment of the present invention.

0013<figref idref="DRAWINGS">FIG. 4</figref> is a data structure diagram showing a customer data table and an anonymous customer data table in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

0014An embodiment of the present invention provides for secure utilization of customer data for marketing to participating customers in a loyalty program corresponding to one of potentially numerous loyalty campaigns of different merchants. Loyalty campaigns are marketing campaigns that are designed to reward, and therefore encourage, loyal buying behavior. The marketing value of loyalty campaign participation extends beyond attracting previous customers to repeat business with the merchant, however. Many loyalty campaign providers request or require a minimal amount of identifying information and demographic data from the participant. This information has been a valuable tool used by marketers to design highly targeted marketing campaigns that will produce optimal returns on marketing budgets.

0015In one implementation, the invention utilizes a loyalty wallet environment that uniquely enables a mobile communication device to host an interface to a remote loyalty campaign processing and data storage system. This interface provides access to the variously disclosed features by way of a loyalty gateway, which itself receives and sends customer related information via a payment gateway and/or wireless network. Specifically, the invention includes a device and system for processing and storing information relating to customer transaction instruments, communication devices, purchases, loyalty campaign participation, merchant information, and loyalty campaign parameters.

0016With reference to <figref idref="DRAWINGS">FIG. 1</figref>, a system in which the present invention can be implemented includes a communication device <b>110</b> which is used by a customer to access and perform the disclosed functions for enrolling and participating in merchant loyalty campaigns. The communication device <b>110</b> is, for example, a mobile communication device such as a mobile phone. The disclosed communication device <b>110</b> includes a wallet application <b>105</b>, which provides, via a network <b>140</b>, an interface to a loyalty gateway <b>130</b> for facilitating origination, transmission, and receipt of wallet data that is maintained at the loyalty gateway <b>130</b>. In one embodiment, the wallet application <b>105</b> adds a secondary security layer to the base security architecture of a commercially available communication device <b>110</b>.

0017In another embodiment, the loyalty gateway <b>130</b> serves as the primary intercept point for transactions originating at a POS device <b>120</b> or any other entity that compiles and sends a transaction authorization request. Accordingly, the loyalty gateway <b>130</b> receives transaction information in the form of an authorization request, extracts data needed to facilitate loyalty features, and routes the authorization request to an appropriate payment gateway <b>125</b> for transaction authorization. When the payment gateway <b>125</b> has processed the transaction request, an authorization response is sent back to the loyalty gateway <b>130</b> where any number of functions can be performed on the message in accordance with any applicable loyalty features as disclosed herein. Finally, the authorization response is sent from the loyalty gateway to the POS device <b>120</b>.

0018While various embodiments for processing transaction requests are presented herein in accordance with the disclosed loyalty features, practitioners will appreciate that the ordering of routing and processing steps are presented for explanation only and are not intended to limit the scope of the invention. The variously disclosed processing and transmission steps may be performed by any number of computing devices or may be performed by a combination of devices, for example, and in varying orders. For example, the loyalty gateway <b>130</b> may modify a transaction authorization request based on loyalty information prior to passing the request to the payment gateway <b>125</b>. In another example, the loyalty gateway <b>130</b> may not modify the authorization request, but instead modify the authorization response received from the payment gateway <b>125</b> based on the loyalty information.

0019As used herein, a “communication device” may comprise any hardware, software, or combination thereof configured to send, receive, process and store information in digital form for the purpose of invoking and managing the disclosed payment and loyalty transactions. More specifically, the communication device <b>110</b> may be embodied as any combination of hardware and/or software components configured to interact with various other hardware and/or software components to provide the disclosed loyalty campaign enrolment and wallet features.

0020It should be noted that although the present invention is described with respect to a communication device <b>110</b>, the invention is not so limited. The invention is suitable for any device or instrument capable of storing distinct data sets, which may be provided by multiple distinct entities where the distinct data sets may be formatted, one different from another. The data sets may correspond to an account comprising, for example, a calling card, a loyalty, debit, credit, incentive, direct debit, savings, financial, membership account or the like. While the information provided by the account issuers may be described as being “owned” by the issuers, the issuers or their designees may simply be a manager of the account.

0021The communications device <b>110</b> and, more specifically, the wallet application <b>105</b> includes an interface that enables the customer to enroll in a merchant loyalty campaign, receive an offer from a merchant, accept an offer by entering a redemption code, receive and view information relating to a transaction, add transaction instruments to a remote wallet database <b>135</b>, manage transaction instruments, manage offers and coupons from a plurality of merchants, and the like.

0022As used herein, the terms “customer”, “consumer”, “user,” “end user,” “cardholder”, “accountholder”, or “participant” may be used interchangeably with each other, and each shall mean any person, entity, machine, hardware, software, and/or business. Furthermore, the terms “business” or “merchant” may be used interchangeably with each other and shall mean any person, entity, machine, hardware, software, or business. Further still, the merchant may be any person, entity, software, and/or hardware that is a provider, broker, and/or any other entity in the distribution chain of goods or services.

0023The disclosed device and system provides real-time customer access to loyalty campaign enrolment, program participation, transaction instrument management, electronic receipts, electronic coupons, and any of the other features disclosed herein. In one embodiment, the communication device <b>110</b> shares information with the loyalty gateway <b>130</b> by way of a wireless communication network. The wallet application <b>105</b> may interact directly or indirectly with various components of the device and system to receive, process, store, and/or send information over the communications network.

0024Communication between various entities of the invention is accomplished through any suitable communication means, such as, for example, a telephone network, intranet, Internet, payment network (point-of-sale device, personal digital assistant, cellular phone, smart phone, appliance, kiosk, etc.), online communications, off-line communications, wireless communications, and/or the like. One skilled in the art will also appreciate that, for security reasons, any databases, systems, or components of the present invention may consist of any combination of databases or components at a single location or at multiple locations, wherein each database or system includes any of various suitable security features, such as firewalls, access codes, encryption, decryption, compression, decompression, and/or the like.

0025The transaction instrument <b>115</b> may be used to communicate to the merchant POS device <b>120</b> information from one or more data sets associated with the transaction instrument. This information may be encoded within the transaction device <b>115</b> and communicated to a merchant POS device <b>120</b> by way of, for example, reading a barcode, scanning a magnetic strip, manual key entry, voice entry, radio data transmission, infrared data signals, and the like. In one example, membership data and credit card data associated with a transaction account or device may be transmitted using any conventional protocol for transmission and/or retrieval of information from an account or associated transaction card (e.g., credit, debit, gift, stored value, loyalty, etc.). In another exemplary embodiment, a transaction instrument <b>115</b> may comprise an electronic coupon, voucher, and/or other such instrument. Moreover, the transaction instrument <b>115</b> may be used to pay for acquisitions, obtain access, provide identification, pay an amount, receive payment, redeem reward points, and/or the like.

0026In various exemplary embodiments, the transaction instrument <b>115</b> may be embodied in form factors other than, for example, a card-like structure. As described herein, the transaction instrument <b>115</b> and the communication device <b>110</b> may be one in the same, but not necessarily so. For example, account information that is conventionally read from a magnetic stripe of a credit card, may instead be maintained within the disclosed wallet application and transmitted to a gateway based on a user command issued to the communication device <b>110</b>. In addition to a smart phone, the communication device <b>110</b> may comprise a typical Radio Frequency (RF) device, which may be implemented in a similar manner as is disclosed in U.S. application Ser. No. 12/553,901, entitled “System and Method for Facilitating Secure Voice Communication Over a Network”, which is commonly assigned, and which is incorporated herein by reference.

0027As used herein, loyalty campaign enrolment allows a customer to participate in various forms of incentive programs such as, for example, a merchant reward program. A loyalty campaign may include one or more loyalty accounts. Exemplary loyalty campaigns include frequent flyer miles, on-line points earned from viewing or purchasing products from websites, and programs associated with diner's cards, credit cards, debit cards, hotel cards, calling cards, and/or the like. Specifically, and within the context of the present invention, a loyalty campaign includes a distribution of coupons to a defined group of customers that participate with the invention to receive, manage, and redeem such coupons electronically.

0028Generally, the customer is both the owner of the transaction account and the participant in the loyalty campaign, however; this association is not necessary. For example, a participant in a loyalty campaign may gift loyalty points and/or coupons to a user who pays for a purchase with his own transaction account, but uses the gifted loyalty points instead of paying the monetary value. It is further contemplated, that where methodologies are used to group like customers into “households”, the owner of a transaction account used to facilitate a purchase transaction and the owner of a loyalty account may not me one in the same. For example, a child may receive benefit of her father's loyalty campaign participation while using her own credit card to facilitate a purchase from a merchant.

0029A “loyalty account number”, “code,” “account,” “account number,” “account code”, “identifier,” or “membership identifier,” as used herein, includes any device, code, or other identifier/indicia is suitably configured to allow a customer to interact or communicate with the disclosed system, such as, for example, authorization/access code, Personal Identification Number (PIN), Internet code, other identification code, and/or the like that is normally encoded within a SIM card, rewards card, charge card, credit card, debit card, prepaid card, telephone card, smart card, magnetic strip card, bar code card, radio frequency card and/or the like. However, in the context of the present invention, such information may be maintained at the loyalty gateway <b>130</b> or any other component capable of securely storing data such that sensitive account information may not be compromised if the communication device <b>110</b> becomes lost or stolen. A reference to the disparately stored account information may be maintained within and/or accessed from the memory portion of the disparately located communication device <b>110</b>.

0030The account code may be distributed and stored in any form of plastic, electronic, magnetic, radio frequency, audio and/or optical device capable of transmitting or downloading data from itself to a second device. An account code may be, for example, a sixteen-digit credit card number, although each credit provider has its own numbering system, such as the fifteen-digit numbering system used by an exemplary loyalty system. Each company's credit card numbers comply with that company's standardized format such that the company using a sixteen-digit format may generally use four spaced sets of numbers, as represented by the number “0000 0000 0000 0000”. The first five to seven digits are reserved for processing purposes and identify the issuing bank, card type and etc. In this example, the last sixteenth digit is used as a sum check for the sixteen-digit number. The intermediary eight-to-ten digits are used to uniquely identify the customer. In addition, loyalty account numbers of various types may be used.

0031The “transaction information” in accordance with this invention may include the nature or amount of transaction, as well as, a merchant, customer, and/or issuer identifier, security codes, routing numbers, and the like. In various exemplary embodiments of the invention, one or more transaction accounts may be used to satisfy or complete a transaction. For example, the transaction may be only partially completed using the transaction account(s) correlating to the application tenant information stored on the transaction device with the balance of the transaction being completed using other sources. Cash may be used to complete part of a transaction and the transaction account associated with a user and the transaction device, may be used to satisfy the balance of the transaction. Alternatively, the user may identify which transaction account, or combination of transaction accounts, stored on the transaction device the user desires to complete the transaction. Any presently known or future methods and/or systems configured to manipulate the transaction information for transport and/or processing over a network may be implemented without departing from the scope of the invention.

0032One skilled in the art will appreciate that a network may include any system for exchanging data or transacting business, such as the Internet, an intranet, an extranet, WAN, LAN, satellite communications, cellular network, and/or the like. It is noted that the network may be implemented as other types of networks such as, for example, an interactive television (ITV) network. The users may interact with the system via any input device such as a keyboard, mouse, kiosk, personal digital assistant, handheld computer, cellular phone, smart phone, and/or the like. Similarly, the features of the invention may be used in conjunction with any type of personal computer, network computer, workstation, minicomputer, mainframe, or the like running any operating system such as any version of Windows, Windows XP, Windows Vista, Windows NT, Windows 2000, Windows 98, Windows 95, MacOS, OS/2, BeOS, Linux, UNIX, Solaris, or the like. Moreover, although the invention is frequently described herein as being implemented with specific communications protocols, it may be readily understood that the invention could also be implemented using IPX, AppleTalk, IP-6, NetBIOS, OSI or any number of existing or future protocols. Moreover, the system may contemplate the use, sale or distribution of any goods, services or information over any network having similar functionality described herein.

0033The security layer of the wallet application <b>105</b> includes a security interface for collecting user credentials. As used herein, the “security interface” comprises any hardware, software, or combination thereof, which is configured to accept an input by any of the parties described herein. An “input” may be defined as, for example, key presses on a physical keyboard, button selection on a touch screen, a verbal command, a biometric sample read, and the like. Inputs may include, for example, a fingerprint, voiceprint, iris scan, facial feature recognition, and the like. However, practitioners will appreciate that entry of a PIN, or any other indicia described herein, may be performed by any means known in the art.

0034In one embodiment, for example, a communication device <b>110</b> comprising a smart phone may be used by an account holder to speak a pass phrase. The pass phrase is converted to a digital representation and interpreted by way of voice recognition. Voice recognition, as used herein, refers to systems and processes that translate the spoken word into a specific response. Voice recognition systems are configured to understand the spoken word, not to establish the identity of the user. An example of a voice recognition system is that of an automated call center wherein a user is prompted to press a number on the phone keypad or speak a command to select a menu item.

0035In another embodiment, the communication device <b>110</b> or any other component of the invention, may invoke voice verifćation in order to match the voice pattern of the speaker to a stored voice print. Voice verification, as used herein, refers to systems and processes that verify the vocal characteristics of a voice sample against those associated with an enrolled user. The voice verification system may use pattern-matching technologies to determine whether a sample voiceprint matches that of a stored voiceprint. Voice recognition, as used herein, refers to systems and processes that translate the spoken word into a specific response. Voice recognition systems are configured to understand the spoken word, not to establish the identity of the user. An example of a voice recognition system is that of an automated call center wherein a user is prompted to press a number on the phone keypad or speak a command to select a menu item.

0036Prior to using the voice authentication embodiment, the user may enroll and setup an account with a verification system. The verification system may reside as a standalone server that is geographically disparate from the components of the loyalty gateway <b>130</b> and may reside in embodiments comprising program code, specialized hardware components, or a combination thereof.

0037An existing user may be provided with a set of credentials especially configured to access the verification system, or may enter existing credentials that are readily used to access general account information at the loyalty gateway <b>130</b>. For example, the customer may call a number to access a loyalty gateway primary automated menu and select or speak an option that switches the user's call to the verification system. When the customer's call is received at the verification system, the customer is directed to select or speak an option from the verification system menu. For example, a voice prompt may instruct the user to press 1 or say “one” to setup a voice ID account, press 2 or say “two” to modify one or more stored voice print models, or press 3 or say “three” to create a new stored voice print model.

0038Practitioners will appreciate that the following enrolment steps are presented for explanation only and does not necessarily represent various other embodiments of the invention as disclosed herein. Further, loyalty campaign enrolment process steps may be added, combined, and/or eliminated without departing from the scope of the invention. The following describes an exemplary enrolment process as may be facilitated, in part, through an incorporation of the wallet application <b>105</b> and the services it provides. However, those of ordinary skill will appreciate that the various functional elements of the wallet application <b>105</b> and loyalty gateway <b>130</b> may be provided through any combination of software and hardware components, which are suitable configured to facilitate a subset of the process steps disclosed herein.

0039When a customer presents a transaction instrument to a merchant to facilitate a payment transaction, the transaction information is read, formatted, and sent by the merchant POS device <b>120</b> to a payment gateway <b>125</b>. As described herein, the transaction information may include various types of data that are used to identify the customer, merchant, transaction account, and settlement entity. For the purpose of explanation, it should be assumed that the transaction information includes, at a minimum, a transaction account identifier and a merchant identifier.

0040As used herein, a payment gateway <b>125</b> comprises any hardware, software, or combination thereof, which is configured to perform transaction instrument processing, billing, reporting and settlement. The payment gateway <b>125</b> further provides operational services to acquiring and issuing banks, manages the process of transferring authorized and captured transaction account funds between different financial accounts such as, for example, the merchants checking account. In an exemplary embodiment, the payment gateway <b>125</b> performs transaction authorization in the conventional manner and transmits the transaction information, or subset thereof, to the loyalty gateway <b>130</b>.

0041In one embodiment, the loyalty gateway <b>130</b> determines whether a Mobile Device Number (MDN) is included in the transaction information. As used herein, a MDN is used to specifically identify the communication device <b>110</b>; however, practitioners will appreciate that other identifiers may be used within the disclosed processes without departing from the scope of the invention. Additional identifiers may include, for example, device specific indicia such as a processor ID and SIM ID, or may comprise user specific indicia such as a driver license number.

0042When the loyalty gateway <b>130</b> determines that the transaction information does not include a MDN, then a query is invoked to search the remote wallet database <b>135</b> for wallet information corresponding to the transaction account identifier and second, the merchant identifier. When wallet data corresponding to first, the transaction account identifier and merchant identifier is located within the remote wallet database <b>135</b>, then the MDN from the returned database record(s) is extracted; otherwise, the merchant is alerted via a response message to the merchant POS device <b>120</b> that the customer's transaction instrument <b>115</b> is not enrolled in the merchant's loyalty campaign. This provides the merchant with an opportunity to enroll the customer in the merchant's loyalty campaign. The enrolment process will be described in greater detail herein.

0043If the customer has not yet installed and configured the wallet application <b>105</b>, the transaction instrument information is associated with the customer's MDN at the loyalty gateway <b>130</b>. In response, the loyalty gateway <b>130</b> transmits a Short Message Service (SMS) message to the customer's communication device <b>110</b>, which includes a link to an installation application for the native wallet application <b>105</b>. In another embodiment, the customer may enroll via an enrolment code that is included on the consumer's electronic receipt that is received by way of SMS message to the customer's communication device <b>110</b>.

0044Practitioners will appreciate that any number of methods may be implemented in order to encourage an enrolled customer to install the wallet application <b>105</b> to their communication device <b>110</b> such as, for example, by way of an email message, voice message, and the like, which may be retrieved by the customer from any known device. In one embodiment, the customer may receive and redeem a shareable coupon that is received by the customer from a second customer. For example, as an enrolled participant in Merchant A's loyalty program, Joe receives an electronic coupon for ten-percent off of his next purchase from Merchant A. Joe may forward the coupon via SMS to his friend, Beth. When Beth wishes to redeem the “gifted” coupon, the loyalty gateway <b>130</b> automatically enrolls Beth in the issuing merchant's loyalty campaign and allows her to install the wallet application <b>105</b> to her communication device <b>110</b>.

0045There may be a circumstance when the customer presents a transaction instrument <b>115</b> at the merchant POS device <b>120</b> that has been used previously in transactions with other merchants; however, it has not been used at the present merchant. When this is the case, the loyalty gateway <b>130</b> searches for a wallet using the transaction instrument identifier (e.g., credit card number). If a wallet record corresponding to the transaction instrument identifier is located, then the associated MDN is retrieved from the wallet record. On determining that MDN is associated with another merchant's loyalty campaign, the loyalty gateway <b>130</b> updates the customer's wallet information to automatically enroll the customer into the present merchant's loyalty campaign. In another embodiment, the loyalty gateway <b>130</b> sends a SMS message with an offer to the customer's communication device <b>110</b>. The customer may redeem the offer by responding to the SMS, which causes the loyalty gateway <b>130</b> to enroll the customer in the merchant's loyalty program.

0046When facilitating a payment transaction at a merchant, the customer's transaction instrument <b>115</b> is read or entered at the point of sale in the conventional manner. Depending on the type of transaction (e.g., in-store, online, phone-order), the transaction instrument <b>115</b> may be read or entered at a merchant POS device <b>120</b>, personal computing device, or telephone. If the customer is enrolled in the merchant's loyalty campaign, an electronic purchase receipt is transmitted from the loyalty gateway <b>130</b> to the customer's communications device <b>110</b>. The purchase receipt includes a summary of the transaction (e.g., item description, item price, applicable sales tax, purchase total) and an offer. The purchase receipt may further include a redemption code that is uniquely generated for the specific customer.

0047The redemption code may, for example, entitle the customer to a discount on a subsequent purchase of a similar item, a discount on a different item, a discount on an item or service provided by an associated merchant, a free item, a number of points to be credited to the customer's loyalty account, and the like. The customer may choose to save the receipt, offer, and/or redemption code for review or for later redemption. The customer may also redeem the offer to receive a discount for the current purchase. In one embodiment, the customer responds to a SMS message received at the communication device <b>110</b> from the loyalty gateway <b>130</b>, with a return SMS message that includes the redemption code. A more detailed description of the enrolment and redemption processing steps as previously described are included below.

0048The transaction processing begins when the customer enters or swipes a transaction instrument at a POS device <b>120</b> or enters the information at a checkout web page. Transaction information including the transaction instrument identifier and merchant identifier is sent to the payment gateway <b>125</b> for presale processing. As described herein, the transaction information from the POS device <b>120</b> may first be sent to the loyalty gateway <b>130</b> or any other gateway, prior to being sent to the payment gateway <b>125</b>. If the transaction information includes a MDN, then this is indicative that the customer provided their mobile number to the merchant at the point of sale.

0049As previously described, a MDN may be provided at the point of sale when a customer wishes to enroll in the merchant's loyalty campaign and has not previously enrolled with any other merchant. Nevertheless, the loyalty gateway <b>130</b> may search the wallet database <b>135</b> for the MDN to ensure that the customer had not previously enrolled. If the MDN is located, then stored records corresponding to the MDN may be used to enroll the customer in the current merchant's loyalty campaign. Otherwise, the transaction information, including the transaction instrument and merchant identifiers, are used to create a new wallet record, thereby enrolling the customer in the merchant's loyalty campaign.

0050Alternatively, if the merchant identifier is located and the transaction instrument identifier is not, then the loyalty gateway <b>130</b> performs a search to determine whether the customer's MDN corresponds to the merchant identifier. If this is the case, then the customer may have previously enrolled in the merchant's loyalty campaign using a different transaction instrument and the current transaction instrument is assumed to not have been previously used with the current merchant. As such, the loyalty gateway <b>130</b> adds the current transaction instrument identifier to the customer's wallet, thereby allowing future use of the transaction instrument for participation in the merchant's loyalty campaign.

0051More specifically, the loyalty gateway <b>130</b> is configured to determine when a parameter for an enrolled customer is different than the parameters stored in the wallet database <b>135</b> and update the customer's information to reflect such changes. For example, Beth previously purchased an item from Joe's Jewelers using her American Express credit card and enrolled in Joe's Jewelers' loyalty campaign by responding to an invitation from the merchant and/or merchant POS device <b>120</b>. At the time of her enrolment, Beth's American Express account number was associated with her cell phone number. On a subsequent visit to Joe's Jewelers, Beth purchases another item using her Visa credit card. Because Beth's Visa credit card account number has not been associated with her wallet at the loyalty gateway <b>130</b>, there is no way to identify Beth as a being enrolled in Joe's loyalty campaign other than by identifying her by her cell phone number. Therefore, Beth provides her cell phone number at Joe's Jewelers' POS device, the cell phone number is used by the loyalty gateway to identify Beth as an enrolled customer, and Beth's wallet is updated to include her previously absent Visa account information. When Beth makes subsequent purchases from Joe's using either her American Express or Visa credit cards, the loyalty gateway will identify Beth as an enrolled member without requiring her to provide her cell phone number.

0052When the transaction information received by the loyalty gateway <b>130</b> does not include a

0053MDN, the transaction account and merchant identifiers are used to locate a record corresponding to the merchant and transaction instrument. If a record corresponding to the transaction instrument identifier is located but the merchant identifier is not, then the customer is assumed to be enrolled in another merchant's loyalty campaign. As a result, the transaction information is used to automatically enroll the customer in the current merchant's loyalty campaign.

0054In another embodiment, the customer may notify the merchant that they are enrolled in that merchant's loyalty campaign and provide the merchant with their enrolled MDN. This is useful, for example, when the customer is using cash, which cannot be used to draw an association with a customer's wallet. When the customer's MDN is entered at the merchant POS device <b>120</b>, the MDN is transmitted to the loyalty gateway <b>130</b> with the transaction information where it is used to locate the customer's wallet information.

0055When the customer is enrolled in the merchant's loyalty campaign, the loyalty gateway <b>130</b> determines whether the subscribed loyalty campaign is in effect and whether the customer is entitled to receive and/or redeem a coupon for the present transaction. Those of ordinary skill in the art will appreciate that the disclosed loyalty gateway <b>130</b> may enable the merchant to specify parameters to be applied to any number of loyalty campaign schemes. In an effort to sell more Craftsman® tools, for example, the merchant may specify that loyalty campaign participants purchasing Craftsman tools are to be issued an instant coupon for 20% off of the tool's normal purchase price, while purchases of all other tools entitle participants to receive coupons for 10% off.

0056When an enrolled customer is eligible to receive a reward (i.e., coupon or offer), then the loyalty gateway <b>130</b> retrieves offer parameters and applies them to the transaction information. For example, if a coupon exists that entitles the customer to 10% off of their purchase; the loyalty gateway <b>130</b> deducts 10% off of the purchase price in the transaction information. When the transaction information has been modified, then it is sent to the payment gateway <b>125</b> to be processed in the conventional manner.

0057In one embodiment, the customer's purchase entitles the customer to a discount that might be applied to a future purchase. In this case, the loyalty gateway <b>130</b> retrieves coupon information and sends it to the customer's communication device. When received, the customer can view, store, or gift the coupon to another customer.

0058In another embodiment, the electronic coupon, which is sent to the communication device, serves as a token. More specifically, the electronic coupon includes electronic token information that allows the customer to be identified when the coupon is redeemed. Practitioners will appreciate that there are any number of data that may be included in the electronic coupon that may be used for any number of purposes. For example, redemption of a coupon may also serve as a secure payment means that facilitates a financial transaction without requiring presentment of a separate transaction instrument.

0059Several scenarios and examples have been provided to describe various methods for enrolling a customer into a merchant loyalty campaign. It is contemplated that in addition to the presented scenarios, other scenarios may require minor variations in the sequence of steps and/or the nature of the performed steps. For example, practitioners will appreciate that the invention may be implemented for varying types of purchase transactions including traditional purchases invoked within a merchant's storefront, online purchases from a merchant's website, telephone purchases, and the like.

0060The above description provides an overview of the enrollment process, primarily from the perspective of the customer. Practitioners will appreciate that the benefits produced through the implementation of the disclosed system and device provides many benefits both to the consumer and to the merchant. The following description of <figref idref="DRAWINGS">FIG. 2</figref> is intended to demonstrate an exemplary process flow for enrolling a customer into a loyalty campaign, in particular, as a merchant implemented loyalty campaign. However, practitioners will appreciate that the disclosed system and method is applicable to any number of disparate merchants as a holistic loyalty campaign solution, which may be implemented and administered through a third-party provider.

0061To provide merchants with the ability to cost-effectively offer their customers participation in a loyalty campaign, the disclosed device and system eliminates any need to issue a branded loyalty instrument (i.e., rewards card). Rather, the invention provides a seamless enrolment process using any issuer's transaction instrument (e.g., smart card, credit card, debit card, pre-paid card, etc.) as it is used through a normal transaction process. In other words, a transaction instrument with a unique Primary Account Number (PAN), for example, may serve as the loyalty instrument.

0062With reference to <figref idref="DRAWINGS">FIG. 2</figref> and continued reference to <figref idref="DRAWINGS">FIG. 1</figref>, the enrolment process is invoked when a merchant reads a transaction instrument at a merchant POS device <b>110</b> and the transaction information is passed through a payment gateway <b>125</b> to a loyalty gateway (step <b>205</b>). In another embodiment, the transaction information is sent from the merchant POS device <b>110</b> to the loyalty gateway <b>130</b>. In addition to the processing steps described herein, the loyalty gateway <b>130</b> determines an appropriate payment gateway <b>125</b> based on the transaction information (or stored data corresponding to a subset of the transaction information), and sends an authorization request including the transaction information to the identified payment gateway <b>125</b> for authorization.

0063On receiving the transaction information from either the merchant POS device <b>110</b> or the payment gateway <b>125</b>, the loyalty gateway <b>130</b> determines whether the read transaction instrument has been enrolled (step <b>210</b>) in the merchant's loyalty campaign. If the loyalty gateway <b>130</b> determines that the transaction instrument has been enrolled (step <b>215</b>), a flag is returned indicating that the transaction instrument has already been enrolled with either the present merchant or another merchant (step <b>220</b>). When a communication device <b>110</b> has been previously enrolled by another merchant, the merchant POS device <b>120</b> displays a prompt to determine whether the customer would like to enroll with the present merchant as well. Alternatively, the customer may be automatically enrolled with the merchant without presenting a prompt.

0064If the loyalty gateway <b>130</b> determines that the transaction instrument has not been enrolled (step <b>215</b>), a flag is returned back to the merchant POS device <b>120</b> indicating that the transaction instrument has not been enrolled (step <b>225</b>). The merchant POS device <b>120</b> displays a prompt stating that this is a new customer and requesting the customer's communication device <b>110</b> identifier (i.e., phone number) (step <b>230</b>).

0065In one embodiment, the merchant may bypass an enrolment prompt while facilitating anonymous enrolment of a communication device <b>110</b> (i.e., without a mobile number). To encourage participation by a merchant who routinely skips the prompt, the system may generate an exception report, which gives the provider information useful in educating the merchant on the benefits that loyalty campaign participation provides. It should be noted that data corresponding to anonymously enrolled transaction instruments may further provide analysis of consumer behavior and can help to build a business case to the merchant showing the value that might be realized through offering a loyalty campaign to its customers.

0066Anonymous enrolment also allows the merchant to encourage repeat buying from previous customers retroactively, even after deciding to implement a loyalty campaign. In other words, customers can be provided offers from the merchant based on purchases made prior to a loyalty campaign being made available to them from the merchant. Because the loyalty gateway <b>130</b> maintains information linking a MDN to a transaction instrument identifier, a customer who has previously enrolled with any other participating merchant can be identified. As such, when a merchant implements a new loyalty campaign through the loyalty gateway <b>130</b>, anonymous records corresponding to past transactions can be linked to a customer's MDN, allowing coupons and/or offers to be sent to the customer's communication device <b>110</b> based on previous purchases.

0067The communication device <b>110</b> identifier (i.e., MDN) is sent to the loyalty gateway <b>130</b> and is associated with the customer's transaction instrument (step <b>235</b>). The association may be flagged to denote that the address is “unconfirmed.” In one embodiment, a threshold number of “unconfirmed” associations may be set in order to create an exception that requires remediation with a merchant.

0068A message (i.e., SMS) is sent to the communication device <b>110</b> requesting the customer's confirmation of the association (step <b>240</b>). An affirmative response from the customer, sent back to the loyalty gateway <b>130</b>, changes the association state to “confirmed” and creates an initial (mostly empty) customer profile (step <b>245</b>). If other transaction instruments have been associated with the communication device <b>110</b> identifier, then all the associated transaction instruments may share a common profile. As an anti-fraud measure, transaction instruments with significantly different names in the track data may not be linked together and the transaction instrument identifier may be flagged as potentially fraudulent. In such a case, remediation may be desirable.

0069The above describes an exemplary enrolment process, whereby merchants are able to encourage customer participation in a loyalty campaign without incurring the expenses associated with an addition to or modification of POS hardware. Other expenses relating to issuance of loyalty account instruments (i.e., loyalty card) and loyalty account maintenance are mitigated through an implementation of the above automatic enrolment process.

0070Moreover, due to the consolidation of the customer enrolment and participation processes by a single entity (i.e., the loyalty gateway), reporting features enable the provider to build a business case that is useful in encouraging merchant participation. For example, a provider may approach a merchant as follows: “Did you know that 70% of your revenue comes from the 10% of your customers that use you more than once each month? Imagine what would happen if you turned the other 90% into repeat customers.”

0071In accordance with one embodiment, the system includes a wallet interface that operates as a wallet application <b>105</b> at the user's communication device <b>110</b>. As used herein, a “wallet” may comprise any hardware and/or software suitably configured to manage and store personal information within a memory structure of a computing device, including a loyalty gateway <b>130</b> and a remote communication device <b>110</b>. The wallet application <b>105</b> includes various interface elements, which allow the user to configure and manage various system features as disclosed herein. These interface elements may be presented in the form of one or more progressive interfaces (i.e., wizard) that guide the customer through wallet application <b>105</b> installation and configuration. The various example wizard interfaces described below are presented for explanation only and are not intended to limit the scope of the invention. For example, while the term “wizard” is commonly used in the context of a series of visual screens, the processes described herein may be facilitated by way of audio prompts and verbal responses.

0072During wallet application <b>105</b> installation, or at any point following, the user is presented with a wizard interface from which to enter and/or modify personal account information. Practitioners will appreciate that any number of present and/or future known methods may be implemented in order to minimize manual data entry tasks. The system knows the name associated with a presented transaction instrument and can use that to search for the user in his “contacts” list. The personal information For example, when a phone number for the communication device <b>110</b> can be located, the contacts stored within that communication device <b>110</b> may be searched, thus enabling the wizard to pre-populate various fields from information that is associated with the phone number. Additional interface screens for entering and/or modifying personal information may include, for example, editable text boxes for entering a first name, middle name, last name, secondary phone number, mailing address, email address, credit card numbers, and the like. All, or a subset, of this information may be programmatically extracted and parsed from various memory regions within the communication device <b>110</b> or acquired from existing customer records stored in the remote wallet database <b>135</b>.

0073Just as a “wallet” as conventionally known stores items containing sensitive information (e.g., driver license, social security card, credit cards, loyalty cards, access cards, photos, etc.); the wallet application <b>105</b> disclosed herein likewise facilitates storage of sensitive and private information that should be inaccessible by unauthorized individuals. As such, the wallet application <b>105</b> is managed by a security component, which may incorporate any number of security schemes configured to manage user permissions and restrict access from unauthorized users.

0074Accordingly, when an installation and configuration process is instantiated, the customer may be prompted to enter a Personal Identification Number (PIN), for example, that is to be used to authenticate the customer in order to invoke subsequent tasks and/or transactions. Practitioners will appreciate that the invention may implement any known method for performing user authentication including for example, PIN or password entry, voice sampling, iris scanning, finger printing, and the like. Nevertheless, the user is prompted to provide a secret code and/or biometric sample, which is stored within a remote data store and keyed by a unique identifier of the communication device.

0075During wallet application <b>105</b> installation, the customer is provided with an option to cancel the installation and configuration process. Canceling this process causes the data that has been entered up to the moment of cancellation to be stored in a temporary memory location within the communication device <b>110</b> or at the remote wallet database <b>135</b>. This enables the installation and configuration process to be resumed at a later time, without requiring the customer to reenter the information that had already been provided. When the wallet application installation remains incomplete (i.e., installation was interrupted prior to completion), the customer may be prompted at defined intervals (e.g., every two days) alerting that wallet application installation and configuration was not completed and allowing the customer to opt to resume wallet installation and configuration at the point that it was previously interrupted.

0076The wallet application installation and configuration process further allows the customer to enter transaction instrument <b>115</b> information for storage and subsequent retrieval. Accordingly, the user may be presented with an interface displaying an empty or partially populated list of transaction instruments along with an interface button that may be selected when the user wishes to provide information relating to additional transaction instruments.

0077The wallet application <b>105</b> provides various interfaces that reside between the customer and the loyalty gateway <b>130</b>. A subset of these interfaces allows the customer to populate their wallet with transaction instrument <b>115</b> information. In one embodiment, to add a transaction instrument <b>115</b> by way of the wallet application <b>105</b>, the customer is presented with an interface that includes, for example, a list of credit card types (e.g., Visa, MasterCard, American Express, Discover, etc.), an edit box for card number entry, a date selector for the expiration date, and an edit box for entry of a Card Verification Code (CVC). Moreover, when the transaction instrument <b>115</b> is a debit card, a field is provided for entry of the debit card PIN. If the customer elects to save the entered information, the transaction instrument information is transmitted to the loyalty gateway <b>130</b> via secured socket connection, for example, where it is stored in the remote wallet database <b>135</b>.

0078In addition to allowing the customer to add transaction instrument information through the disclosed wallet application, the invention provides a means for entering other information relating to other types of transaction accounts that may, or may not, have an associated transaction instrument (e.g., a bank checking account). For example, the customer may choose to pay for a service by way of an electronic check, rather than by a debit or credit card. As such, a wallet interface of the wallet application <b>105</b> may include fields for entering a bank routing number and a bank account number. Moreover, practitioners will appreciate that other types of account information may be entered for wallet storage including, for example, loyalty account information, a Social Security Number, a driver license number, secure access codes, membership information, and the like.

0079As described herein, the invention provides efficient enrolment of customers to a merchant loyalty campaign without requiring the merchant to issue loyalty cards to those customers. However, there may be scenarios where it would be desirable for a customer to be able to manually add a loyalty card to their wallet application <b>105</b>. For example, a customer may have previously acquired a number of loyalty cards from various merchants prior to enrolling in a merchant loyalty campaign using the disclosed automatic enrolment process. Therefore, the customer may access an interface of the wallet application <b>105</b>, which includes editable fields for entering the loyalty card name, loyalty account number, and any other relevant information to be stored.

0080Information entered and/or modified within the interface fields may be added to the customer's wallet records, which in one embodiment, are stored in the remote wallet database <b>135</b>. As such, the customer may be presented with options (i.e., buttons) to save or reject the customer-entered additions. An election to save the information causes the wallet application <b>105</b> at the communication device <b>110</b> to transmit the data to the loyalty gateway <b>130</b> where the data is processed and saved to the remote wallet database <b>135</b>.

0081In addition to providing the previously described features, the wallet application <b>115</b> operating at the communications device <b>110</b> allows the customer to manage information that is maintained at the remote wallet database <b>135</b>. This information is assumed to be private in nature; however, methods for managing, processing, and storing other types of less-sensitive information are contemplated.

0082To allow the customer to modify personal account information, the customer invokes the wallet application <b>105</b>. The wallet application security layer is made active, prompting the customer to enter an authentication credential. As described herein, an authentication credential may comprise a code and/or biometric sample that are verified against a stored code or a stored biometric sample. For explanation, an authentication credential is used herein as comprising a PIN.

0083The wallet application <b>105</b> sends the PIN and MDN to the loyalty gateway <b>130</b>. Upon successful verification of the PIN, the wallet application <b>105</b> presents the customer with a screen (interface) that includes interface buttons that may be selected to access general account information, transaction instruments, and transaction records. Based on the customer's selection, the wallet application <b>115</b> presents one or more interfaces that include the related information, and where appropriate, provides the customer an ability to modify the information. For example, a customer selecting an “Account Information” interface button is presented with an interface screen that includes fields for first name, middle name, last name, phone number, and email address. The “Account Information” interface may itself include interface buttons that invoke views of billing information, shipping information, and a screen to modify authentication credentials (e.g., PIN).

0084Those of ordinary skill in the art will appreciate that the specific arrangement of the various interface screens and user interface elements, presented herein by way of example, are intended for explanation only and do not limit the scope of the invention. In one embodiment, for example, all information relating to “Billing Information” may be displayed in a single scrolling interface screen. In another embodiment, fields relating to “Billing Information” may be divided into a number of screens, grouping similar information among each screen.

0085Similar to what has been described above, the invention allows a user to modify other types of information in order to manage the records that are maintained within the remote wallet database <b>135</b>. In one embodiment, a loyalty gateway <b>130</b> administrator defines policies governing which information may be added, modified, or deleted by a user. Transaction instrument types that are accessible by the customer and would typically be modifiable include, for example, transaction instrument, credit card, debit card, bank account, and loyalty card. In another embodiment, the customer may also store scanned images of items such as a driver license, membership card, Social Security card, employee badge, and access card.

0086As described herein, the wallet application <b>105</b> provides a number of interfaces that allow the customer to search, view, and enroll in loyalty campaigns. The interface also allows the customer to review their wallet contents. Similar to a conventional wallet, the wallet application <b>105</b> helps the customer organize and maintain various transaction instruments, loyalty cards, access cards, membership cards, identity cards, and the like. However, the wallet application <b>105</b> also includes various features that assist the customer in facilitating loyalty account management including enrolment, monitoring, and redemption. The following describes features of the invention that are directed toward the execution of purchase transactions in relation to loyalty campaign participation.

0087The “pending transactions” interface provides an interface button that allows the customer to optionally change payment information. The change payment information interface screen allows the customer to select a transaction instrument to run the payment transaction against. For example, a customer at a merchant POS device <b>120</b> hands the merchant his MasterCard credit card and the transaction information is submitted to the loyalty gateway <b>130</b> via the payment gateway <b>125</b>. The transaction instrument identifier is used by the loyalty gateway <b>130</b> to identify the customer and retrieve the phone number for the customer's communication device <b>110</b>. As described above, the loyalty gateway <b>130</b> sends a push notification or SMS, invoking an alert notifying the customer of the pending transaction. While viewing the pending transactions interface, the customer selects the “change payment information” button and is presented with an interface listing each of the transaction instruments that have previously been added to the customer's wallet. The customer selects his Discover Card transaction instrument and an updated pending transactions interface reflects the change. The customer selects the “accept transaction” interface button causing the transaction information to be sent to the payment gateway <b>125</b> as an authorization request.

0088In one embodiment, the customer may interact with the loyalty gateway <b>130</b> via the communication device <b>110</b> to select an offer that has not necessarily been solicited. Accordingly, the customer invokes the wallet application <b>105</b> to retrieve and view a number of merchants offering enrolment in loyalty campaigns. The customer may limit a list of merchants by merchant type, product/service type, geographical region, price range, and the like.

0089The customer may further select a merchant from a list of merchants returned by the loyalty gateway <b>130</b> and enroll in the selected merchant's loyalty campaign. Manual enrolment may include requiring the customer to enter information that is used at the loyalty gateway <b>130</b> to create/update records corresponding to the specific customer. In another embodiment, all or a subset of, the enrolment information is acquired from stored customer information such that manual entry is minimized or eliminated. It should be appreciated that “enrolment information” may include any number of individual data items such as, for example, first name, last name, mailing address, city, state, postal code, email address, credit card name, credit card number, expiration date, CVC code, and etc. Enrolment information may be entered into fields provided by a wallet application <b>105</b> interface, automatically submitted from a stored customer profile, acquired from a third-party source, or any combination thereof.

0090The customer may interact with the wallet application <b>105</b> in order to perform a number of additional tasks including, for example, viewing a loyalty account point balance, viewing acquired coupons, viewing cumulative savings, viewing transaction summaries, searching for promotions, and the like. The customer may also select point promotions that are available based on the customer's balance of loyalty points. In one embodiment, the customer may select to redeem a point balance toward a future purchase. The loyalty gateway <b>130</b> is notified of the request to redeem a balance of points and a pending redemption is recorded. When executing the subsequent purchase transaction, the pending points are automatically redeemed and the monetary value of the redemption is deducted from the purchase price.

0091As will be appreciated by one of ordinary skill in the art, any number of loyalty campaign configurations may be implanted within the context of the presented embodiments. Moreover, issuance, maintenance, and redemption of loyalty account balances may be managed by any party by way of any known computing hardware components, software systems, network infrastructure, or a combination thereof. Moreover, a variety of existing loyalty campaigns may be implemented in conjunction with the disclosed enrolment process without departing from the scope of the invention.

0092In one embodiment, an enrolled customer, having an established wallet at the loyalty gateway <b>130</b>, selects a default payment type prior to entering into a payment transaction. As used herein, the “payment type” refers to the transaction instrument, or transaction account, that the customer wishes to execute for a purchase transactions. The payment type may be modified by the customer at the time of transaction confirmation or by the loyalty gateway <b>130</b> prior to the customer's confirmation. For example, an enrolled customer may configure his wallet to include information relating to his American Express, Visa, and MasterCard credit cards. Prior to a subsequent purchase, the customer may select the Visa credit card as the “default” transaction instrument. Thereafter, the loyalty gateway <b>130</b> will select the Visa transaction instrument information from the remote wallet database <b>135</b> in response to receiving transaction information from the merchant POS device <b>120</b>, even when the customer's American Express credit card was scanned at the merchant POS device <b>120</b>. Upon confirmation by the customer, information relating to the American Express credit card will be substituted with information relating to the Visa credit card. The transaction information, including the Visa transaction instrument identifier, will be sent from the loyalty gateway <b>130</b> to the payment gateway <b>125</b>.

0093In accordance with this embodiment; it is feasible that the customer could present a first transaction instrument <b>115</b> to a merchant, while the payment gateway <b>125</b> executes the purchase transaction using a second transaction device. This significantly eliminates the need for the customer to carry multiple transaction instruments, in that the customer need only to present a single card to merchants, assuming that the transaction instrument has been added to the customer's wallet along with one or more other transaction instruments. The single card may be associated with a plurality of disparate transaction instruments in the customer's wallet; any one of the plurality being selectable to finalize a payment transaction.

0094Moreover, the enrolled customer may define rules at the loyalty gateway <b>130</b> that govern how specific transaction instruments are to be used for payment transactions. Rule parameters are used by the loyalty gateway <b>130</b> to determine when a specific rule is to be implemented. For example, a customer may designate his Visa credit card as the default payment type. He may further create a rule that states that when a transaction exceeds $100, the transaction instrument should be switched to his American Express credit card.

0095Other rules and rule parameters may relate to purchase amount, date of purchase, merchant identifier, merchant type, geographic region, product identifier, purchase type, and the like. In other words, the defined rules and rule parameters govern exactly how and when transaction instruments in the customer's wallet are used. Further, rules may include sub-rules. For example, a rule may state that for any transaction that exceeds $500 for office supplies; 60% of the transaction amount should be authorized against a first transaction instrument, and the remaining balance should be authorized against a second transaction instrument. However, those of ordinary skill in the art will appreciate that any number of rules and rule variances may be defined without departing from the scope of the invention.

0096With reference to <figref idref="DRAWINGS">FIG. 3</figref> and continued reference to <figref idref="DRAWINGS">FIG. 1</figref>, a customer who is enrolled with the loyalty gateway <b>130</b> uses their transaction instrument <b>115</b> at a merchant POS device <b>120</b> to submit payment for a purchase (step <b>305</b>). The merchant POS device <b>120</b> sends transaction information to a payment gateway <b>125</b> for transaction authorization (step <b>310</b>). The transaction information includes data elements that would normally be included in a conventional transaction authorization request. At a minimum, the transaction information includes at least one of a transaction account identifier and/or a MDN that is associated with the customer's communication device <b>110</b>.

0097The payment gateway <b>125</b> submits the transaction information (or a subset thereof) to the loyalty gateway <b>130</b>, which performs a search of the remote wallet database <b>135</b> for records corresponding to either the MDN, transaction instrument identifier, or both (step <b>315</b>). If information is returned indicating that the customer has not been enrolled in with the loyalty gateway (step <b>320</b>), then a SMS message is sent from the loyalty gateway <b>130</b> to the communication device <b>110</b> inviting the customer to enroll with the loyalty gateway (step <b>325</b>) in order to establish a wallet. The SMS may optionally include a link to allow the customer to download and install the wallet application <b>105</b>. Moreover, the SMS may include a coupon code that the customer may redeem toward the current purchase transaction, pending the customer's enrolment with the loyalty gateway <b>130</b>.

0098When it has been determined that the customer is enrolled and has established a wallet at the loyalty gateway <b>130</b>, the loyalty gateway <b>130</b> sends a push notification to the communication device <b>110</b> (step <b>330</b>). Upon receipt of the push notification, the wallet application <b>105</b> displays an alert notifying the customer of the pending transaction (step <b>335</b>). In one embodiment, a listener component invokes a visual alert with the number of pending transactions.

0099The listener component runs as a background process at the communication device <b>110</b>.

0100The listener component is configured to “listen” for specific events in order to perform a number of functions. For example, the listener component may detect when a push notification is received at the communication device <b>110</b> from the loyalty gateway <b>130</b>. In response, the listener component invokes the communication device <b>110</b> to play an audible tone and display a visual alert in accordance with the device's configuration settings in order to notify the customer that a transaction is pending. Further, the listener component may be configured to invoke the wallet application <b>105</b> when a defined event is detected such as, for example, when the wallet application <b>105</b> has not been fully installed and configured as describe above.

0101Referring again to <figref idref="DRAWINGS">FIG. 3</figref>, the customer may select a view option from the visual alert and the wallet application <b>105</b> is invoked, prompting the customer to enter their PIN (or other authentication credential) (step <b>340</b>). The wallet application <b>105</b> sends the PIN and a device identifier (e.g., a MDN) to the loyalty gateway <b>130</b>, which acquires personal account information and transaction records from the remote wallet database <b>135</b>. The acquired information is sent to the communication device <b>110</b> and the wallet application <b>105</b> presents the customer with a pending transactions interface (step <b>345</b>). In one embodiment, the pending transactions interface may include information relating to the merchant's name, transaction date/time, transaction amount, and default transaction instrument. The pending transactions interface may further include interface buttons to view transaction details, a detailed disclosure, default payment information, accept transaction, decline transaction, and change payment type.

0102When the customer views and confirms the transaction and selects an interface button to “accept” the transaction, the communication device <b>110</b> sends the confirmation to the loyalty gateway (step <b>350</b>). The loyalty gateway <b>130</b> modifies data in the original authorization request (e.g., modifies the payment type based on the transaction amount), sends the modified authorization request to the payment gateway <b>125</b>, and updates the customer's records in the remote wallet database <b>135</b> to reflect the purchase transaction (step <b>355</b>). Optionally, the loyalty gateway sends a transaction receipt, or a link to the transaction receipt, to the customer's communication device <b>110</b>.

0103The above embodiment may be implemented alone or in combination with the loyalty embodiments presented herein. Practitioners will appreciate that the examples presented are for explanation only and do not limit the scope of the invention in any way. It is also important to note that the associations between records in the remote wallet database <b>135</b> may be based on any field or combination of data fields. For example, when a first transaction instrument is scanned at a merchant POS device <b>120</b>, the transaction instrument identifier may be used to locate an associated second transaction instrument identifier, which is then used to complete the purchase transaction. It is further contemplated that the MDN of the communication device <b>110</b> may be used to locate associated remote wallet database records.

0104As explained above, the present invention provides a method and system for anonymous marketing to participating customers in a loyalty program. The invention may be implemented within a loyalty management system which facilitates multiple loyalty management campaigns corresponding to multiple merchants who customers may do business with and whose loyalty programs they may choose to join. Such a loyalty management system may be implemented, for example, in a system similar to that shown in <figref idref="DRAWINGS">FIG. 1</figref>. The loyalty management system includes a number of loyalty clients, each representing a customer who is enrolled or potentially enrolled in one or more loyalty programs. Each loyalty client includes, for example, a communication device <b>110</b> and wallet application <b>105</b>. The loyalty management system further includes a loyalty server which can be implemented as a computer system that includes, for example, the loyalty gateway <b>130</b> and the remote wallet database <b>135</b>. The loyalty gateway <b>130</b> includes a customer server component which interfaces with a number of communication devices <b>110</b> of customers enrolled or potentially enrolled in one or more loyalty programs. For instance, the customer server component may interact with each wallet application <b>105</b> on each communication device <b>110</b>.

0105Upon enrollment in the loyalty program by a customer and/or at any time(s) thereafter, the loyalty server obtains customer data from the customer. For example, the customer server component of loyalty gateway <b>130</b> obtains customer data from the wallet application <b>105</b> for the corresponding customer via network <b>140</b>. The loyalty server then stores the customer data in a customer database. For example, the loyalty gateway <b>130</b> stores the customer data in the remote wallet database <b>135</b>.

0106At least a portion of the customer data includes “personal identification data” that, for a given customer, inherently reveals the identity of the customer and/or a means of directly contacting the customer. Personal identification data includes, for example, publicly identifying information such as a customer name, social security number, drivers license number and so forth. Personal identification data may also include various means of contacting the customer directly (via mechanisms primarily and/or regularly used by the customer for communications needed or desired by the customer) such as a home postal address, business postal address, home phone number, business phone number, personal mobile phone number, one or more primary email addresses, and so forth.

0107Customer data may also include “non-identifying data” that does not inherently reveal the identity or means of directly contacting the customer. Such non-identifying data may include demographic data such as gender, age range, income bracket, geographic region and so forth. Non-identifying data may also include loyalty and purchase related information such as which merchant loyalty programs the customer is enrolled with, marketing and contact preferences, categories of products purchased, methods of payment performed and/or used, payment history characteristics, other non-specific payment information, and so forth.

0108The loyalty server interacts with one or more business entities who may wish to provide marketing information to participating customers. For example, the loyalty gateway <b>130</b> includes a business server component which interacts with a computer system of each such business entity over an appropriate network capable of data communication. A business entity may be a merchant such as a participating merchant providing a loyalty program through the loyalty management system, a non-participating merchant who wishes to sell and/or market to customers, or a marketing entity who provides customer information to other businesses, such as a marketing service or the like.

0109The loyalty server provides to the business entities anonymous customer data that does not reveal personal identification data to the business entities. For example, the loyalty gateway <b>130</b> provides the anonymous customer data to a computer system of each such business entity over an appropriate network capable of data communication. As one example of anonymous customer data, the loyalty server may provide “group data” that represents a number of customers without revealing any individual data with respect to those customers.

0110As another example of anonymous customer data, the loyalty server may provide, for each of one or more individual customers, “anonymized individual data” that comprises, for each customer, (a) non-identifying data (as described above) and (b) a reference indicia such as a unique ‘handle’ by which the anonymized individual data is specified and by which the customer is thereby uniquely but anonymously referenced. The handle may be implemented in the form of any appropriate data value which uniquely references an individual customer without revealing in itself the personal identification data of the customer. The loyalty server maintains an association that associates the handle with the personal identification data of the customer, but the loyalty server does not share that association with the business entities. The association may be implemented in any way suitable to link or logically connect the handle to the personal identification data, such as by any appropriate database method or data structure, data set, binary large object, etc.

0111<figref idref="DRAWINGS">FIG. 4</figref> shows example data structures for managing customer data using handles as defined above for the purposes described herein. In <figref idref="DRAWINGS">FIG. 4</figref>, customer data table <b>400</b> is maintained by the loyalty server. Customer data table <b>400</b> may be stored, for example, in the remote wallet database <b>135</b> and accessed by the loyalty gateway <b>130</b>. Customer data table <b>400</b> includes a customer data record <b>402</b> for each customer. Each customer data record <b>402</b> includes a personal identification data portion <b>404</b> holding personal identification data for the corresponding customer, a non-identifying data portion <b>406</b> holding non-identifying data for the same corresponding customer, and is further provided with a handle portion <b>408</b> holding a handle for that same corresponding customer.

0112Also shown in <figref idref="DRAWINGS">FIG. 4</figref> is an example data structure by which the anonymous customer data can be provided to the business entity. Anonymous customer data table <b>410</b> includes an anonymized individual data record <b>412</b> for each individual customer. Each anonymized individual data record <b>412</b> contains a handle portion <b>418</b> holding a handle for the corresponding customer and a non-identifying data portion <b>416</b> holding non-identifying data for the same corresponding customer. The anonymous customer data may be provided to the business entity by transferring all or a portion of the anonymous customer data table <b>410</b>, such as over a network capable of data communication, to a computer system of the business entity. Alternatively, a business entity registered with the loyalty server might be given access to a limited portion of the customer database consistent with what is represented by the customer data table <b>410</b> or a portion thereof, or by any other means that does not provide the business entity with access to personal identification data.

0113Upon providing anonymous customer data to a business entity, the loyalty server can then obtain an anonymous designation of target customers to whom the business entity wants marketing information to be provided by appropriate means. As one example, where anonymous customer data was provided to the business entity in the form of anonymized individual data that is specified by a handle as described above, the business server component of loyalty gateway <b>130</b> can obtain from the business entity a selection of handles which uniquely but anonymously reference the desired target customers by virtue of uniquely specifying the anonymized individual data of each of said target customers as explained above. Returning to <figref idref="DRAWINGS">FIG. 4</figref>, for example, a business entity may consider the non-identifying data in the non-identifying data portion <b>416</b> of each anonymized individual data record <b>412</b> that was provided to the business entity. The business entity may then select the handle in the handle portion <b>418</b> of each anonymized individual data record <b>412</b> that holds, in non-identifying data portion <b>416</b>, non-identifying data considered by the business entity to be indicative of a good candidate for marketing. Such selection may be made, for example, by a representative of the business entity based on personal judgment or based on defined methods, or effectuated by software executed on a computing device of the business entity which applies defined rules to the non-identifying data to render such selections.

0114As another example which, in this case, does not necessarily require the sharing of individually referenced customer data with the business entity, the business server component of loyalty gateway <b>130</b> can obtain from the business entity one or more specified criteria for the loyalty gateway <b>130</b> to apply in selecting the target customers. For example, the business entity might specify customers who are males between the ages of 20 and 40. Where the loyalty server has provided the business entity with anonymous customer data such as group data or anonymized individual data as described above, the business entity may utilize such anonymous customer data in determining the criteria. Alternatively, the business entity may determine the criteria by independent judgment or other means.

0115The loyalty server may also obtain marketing content from the business entity to be provided to the target customers. Or, where such content is already maintained on the loyalty server or at some location accessible by the loyalty server, the business entity may provide a designation of marketing content suitable to identify what is to be provided to the target customers. Alternatively, such content may have been preselected by the business entity or by the loyalty server based on information associated with the business entity. Marketing content may include text, image data, audiovisual data, formatting, links to web content, or the like.

0116Once the target customers have been designated, the loyalty server obtains the personal identification data necessary to contact the target customers and uses it to provide marketing information (such as marketing content provided or designated by the business entity) to the target customers. This may be done in different ways depending on the way in which the target customers have been designated. For example, where criteria have been designated by the business entity, the loyalty gateway <b>130</b> may apply the criteria to retrieve the personal identification data of customers who correspond to such criteria such as by an exact match, closest matches, falling within a defined range and so forth. A designated volume of target customers may be selected, preselected or predefined by the business entity or loyalty server based on the objectives at hand. A number of target customers corresponding to the designated volume may then be selected based on an extent to which the criteria are met and/or surpassed, random selection methods or other means.

0117Where selected handles have been provided by the business entity as described above, the loyalty gateway <b>130</b> may utilize the selected handles to obtain the personal identification data from a customer database such as the remote wallet database <b>135</b>. Returning to <figref idref="DRAWINGS">FIG. 4</figref>, for example, the loyalty gateway <b>130</b> identifies those customer data records <b>402</b> in the customer data table <b>400</b> which contain in handle portion <b>408</b> one of the selected handles. The loyalty gateway <b>130</b> then obtains the personal identification data in the personal identification data portion <b>404</b> of each of the identified customer data records <b>402</b> and provides marketing information to the target customers based on the personal identification data obtained.

0118The loyalty server may provide the marketing information to the target customers by any of a number of available means. For a given customer, for example, the loyalty gateway <b>130</b> may provide the marketing information by email to an email address maintained on the remote wallet database <b>135</b>, by a text message (SMS, etc.) to a number maintained on the remote wallet database <b>135</b>, by postal mail to a postal address maintained by the remote wallet database <b>135</b>, or via the loyalty wallet application <b>105</b> installed on the communication device <b>110</b> of the customer as identified by appropriate means. The loyalty server may provide the marketing information by different means to different target customers, such as based on selected or predefined customer preferences, available contact information and so forth.

0119It should be understood that the above described loyalty management system provides a method and system that allows for the provision of marketing information to customers designated by business entities without revealing the personal identification data of the customers to such business entities. Furthermore, the utility and value of such a loyalty system may be enhanced by additional features. For example, the loyalty server may be provided with a number of security functions to protect the customer data from unauthorized access. Such functions may include firewalls, passwords, and encryption and so forth, and will be selected by one of ordinary skill in the art as appropriate for the system at hand.

0120Additionally, the loyalty server may be configured so as to provide the anonymous customer data to business entities only upon obtaining permission from the customer, such as through an opt-in or an opt-out selection provided via the wallet application <b>105</b>. Similarly, and either separately or in combination with this feature, the loyalty server may provide marketing material to customers only upon obtaining permission from the customer, such as through an opt-in or an opt-out selection provided via the wallet application <b>105</b>. Additionally, the loyalty server may provide compensation to customers who choose to allow their anonymous customer data to be provided to business entities and/or customers who choose to allow marketing information to be provided to them on behalf of business entities. Such compensation may be in the form of, for example, offers or credits provided via the wallet application <b>105</b>, establishment of (or addition to) a stored monetary value that is maintained by the wallet application <b>105</b>, electronic coupons or vouchers provided via email, text or other means to the communication device <b>110</b> or to another personal computing system of the customer, or physical coupons or vouchers provided via postal mail or as a printable document provided via electronic means.

0121It should also be understood that, while the invention has been described in terms of a synergistic combination of functions including a marketing analysis function whereby marketing data is provided to businesses and a marketing function whereby marketing information in provided to customers, these functions may be provided independently from each other in accordance with various embodiments of the present invention. For example, the loyalty server may provide anonymous customer data to business entities for use in marketing analysis that does not directly result in their marketing to participating customers via the loyalty server. As another example, the loyalty server may provide marketing information to customers falling within criteria designated by a business entity without any customer data having been shared with the business entity, such as where the designation is based on independent judgment or data of the business entity. Furthermore, while the invention has been described in the context of a loyalty wallet environment, it should be understood that some described features may be applicable and novel in a general payment wallet environment and, as such, the present specification may support inventions not necessarily limited to a loyalty based wallet environment. In such case, relevant functions described herein as being performed by a loyalty management system, loyalty server, loyalty gateway <b>130</b> and so forth may be performed by a wallet management system, wallet server, wallet gateway and so forth, respectively.

0122Any databases discussed herein may be any type of database, such as relational, hierarchical, graphical, object-oriented, and/or other database configurations. Common database products that may be used to implement the databases include DB2 by IBM (White Plains, N.Y.), various database products available from Oracle Corporation (Redwood Shores, Calif.), Microsoft Access or Microsoft SQL Server by Microsoft Corporation (Redmond, Wash.), or any other suitable database product. Moreover, the databases may be organized in any suitable manner, for example, as data tables or lookup tables. Each record may be a single file, a series of files, a linked series of data fields or any other data structure. Association of certain data may be accomplished through any desired data association technique such as those known or practiced in the art. For example, the association may be accomplished either manually or automatically. Automatic association techniques may include, for example, a database search, a database merge, GREP, AGREP, SQL, and/or the like. The association step may be accomplished by a database merge function, for example, using a “key field” in pre-selected databases or data sectors.

0123More particularly, a “key field” partitions the database according to the high-level class of objects defined by the key field. For example, certain types of data may be designated as a key field in a plurality of related data tables and the data tables may then be linked on the basis of the type of data in the key field. In this regard, the data corresponding to the key field in each of the linked data tables is preferably the same or of the same type. However, data tables having similar, though not identical, data in the key fields may also be linked by using AGREP, for example. In accordance with one aspect of the present invention, any suitable data storage technique may be utilized to store data without a standard format. Data sets may be stored using any suitable technique, including, for example, storing individual files using an ISO/IEC 7816-4 file structure; implementing a domain whereby a dedicated file is selected that exposes one or more elementary files containing one or more data sets; using data sets stored in individual files using a hierarchical filing system; data sets stored as records in a single file (including compression, SQL accessible, hashed via one or more keys, numeric, alphabetical by first tuple, etc.); block of binary (BLOB); stored as ungrouped data elements encoded using ISO/IEC 7816-6 data elements; stored as ungrouped data elements encoded using ISO/IEC Abstract Syntax Notation (ASN.1) as in ISO/IEC 8824 and 8825; and/or other proprietary techniques that may include fractal compression methods, image compression methods, etc.

0124In one exemplary embodiment, the ability to store a wide variety of information in different formats is facilitated by storing the information as a Binary Large Object (BLOB). Thus, any binary information may be stored in a storage space associated with a data set. As discussed above, the binary information may be stored on the financial transaction instrument or external to but affiliated with the financial transaction instrument. The BLOB method may store data sets as ungrouped data elements formatted as a block of binary via a fixed memory offset using fixed storage allocation, circular queue techniques, or best practices with respect to memory management (e.g., paged memory, least recently used, etc.). By using BLOB methods, the ability to store various data sets that have different formats facilitates the storage of data associated with the financial transaction instrument by multiple and unrelated owners of the data sets. For example, a first data set which may be stored may be provided by a first issuer, a second data set which may be stored may be provided by an unrelated second issuer, and yet a third data set which may be stored, may be provided by an third issuer unrelated to the first and second issuer. Each of these three exemplary data sets may contain different information that is stored using different data storage formats and/or techniques. Further, each data set may contain subsets of data, which also may be distinct from other subsets.

0125The data set annotation may be used for various types of status information as well as other purposes. For example, the data set annotation may include security information establishing access levels. The access levels may, for example, be suitably configured to permit only certain individuals, levels of employees, companies, or other entities to access data sets, or to permit access to specific data sets based on the transaction, merchant, issuer, user or the like. Furthermore, the security information may restrict/permit only certain actions such as accessing, modifying, and/or deleting data sets. In one example, the data set annotation indicates that only the data set owner or the user are permitted to delete a data set, various identified merchants are permitted to access the data set for reading, and others are altogether excluded from accessing the data set. However, other access restriction parameters may also be used allowing various entities to access a data set with various permission levels as appropriate.

0126One skilled in the art will also appreciate that, for security reasons, any databases, systems, devices, servers or other components of the present invention may consist of any combination thereof at a single location or at multiple locations, wherein each database or system includes any of various suitable security features, such as firewalls, access codes, encryption, decryption, compression, decompression, and/or the like.

0127The present invention may be described herein in terms of functional block components, optional selections and/or various processing steps. It should be appreciated that such functional blocks may be realized by any number of hardware and/or software components suitably configured to perform the specified functions. For example, the present invention may employ various integrated circuit components, e.g., memory elements, processing elements, logic elements, look-up tables, and/or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. Similarly, the software elements of the present invention may be implemented with any programming or scripting language such as C, C++, Java, COBOL, assembler, PERL, Visual Basic, SQL Stored Procedures, extensible markup language (XML), Microsoft.Net with the various algorithms being implemented with any combination of data structures, objects, processes, routines or other programming elements. Further, it should be noted that the present invention may employ any number of conventional techniques for data transmission, messaging, data processing, network control, and/or the like. Still further, the invention could be used to detect or prevent security issues with a client-side scripting language, such as JavaScript, VBScript or the like. For a basic introduction of cryptography and network security, the following may be helpful references: (1) “Applied Cryptography: Protocols, Algorithms, And Source Code In C,” by Bruce Schneier, published by John Wiley &amp; Sons (second edition, 1996); (2) “Java Cryptography” by Jonathan Knudson, published by O'Reilly &amp; Associates (1998); (3) “Cryptography &amp; Network Security: Principles &amp; Practice” by Mayiam Stalling, published by Prentice Hall; all of which are hereby incorporated by reference.

0128It should be appreciated that the particular implementations shown and described herein are illustrative of the invention and its best mode and are not intended to otherwise limit the scope of the present invention in any way. Indeed, for the sake of brevity, conventional data networking, application development and other functional aspects of the systems (and components of the individual operating components of the systems) may not be described in detail herein. It should be noted that many alternative or additional functional relationships or physical connections might be present in a practical transaction instrument distribution system.

0129As may be appreciated by one of ordinary skill in the art, the present invention may be embodied as a method, a data processing system, a device for data processing, a financial transaction instrument, and/or a computer program product. Accordingly, the present invention may take the form of an entirely software embodiment, an entirely hardware embodiment, or an embodiment combining aspects of both software and hardware or other physical devices. Furthermore, the present invention may take the form of a computer program product on a tangible computer-readable storage medium having computer-readable program code means embodied in the storage medium. Any suitable tangible computer-readable storage medium may be utilized, including hard disks, CD-ROM, optical storage devices, magnetic storage devices, and/or the like.

0130These computer program instructions may also be stored in a computer-readable memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement functions of flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus include steps for implementing the functions specified in the flowchart block or blocks.

0131In the foregoing specification, the invention has been described with reference to specific embodiments. However, it may be appreciated that various modifications and changes may be made without departing from the scope of the present invention. The specification and figures are to be regarded in an illustrative manner, rather than a restrictive one, and all such modifications are intended to be included within the scope of present invention. Accordingly, the scope of the invention should be determined by the appended claims and their legal equivalents, rather than by the examples given above. For example, the steps recited in any of the method or process claims may be executed in any order and are not limited to the order presented.

0132Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as critical, required, or essential features or elements of any or all the claims. As used herein, the terms “comprises”, “comprising”, or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

0133Further, no element described herein is required for the practice of the invention unless expressly described as “essential” or “critical”.