AU6287199A - An on-line incentive system - Google Patents

Description

WO 00/21008 PCT/US99/23077 AN ON-LINE INCENTIVE SYSTEM BACKGROUND OF THE INVENTION 5 Field of the Invention: The present invention is directed toward the field of on-line incentive programs, and more particularly to a remote incentive management system that utilizes private label currency. 10 Art Background: In general, merchants (e.g., proprietors of goods and services) participate in incentive programs to entice customers or consumers to purchase products or services. Typically, merchants participate in incentive programs to reward customers for purchasing merchandise. The merchant's general goal is 15 to confer the maximum benefit on the customer while minimizing the merchant's overhead and cost. One type of incentive program confers a single product or service to the customer as an award. The frequent flyer mile program is an example incentive program that confers a single predefined benefit to the customer. In a 20 frequent flyer mile program, credit cards, associated with airlines, permit customers to receive frequent flyer miles in exchange for the customer's use of the credit card. The frequent flyer mile incentive programs typically award the WO 00/21008 PCT/US99/23077 2 customer one frequent flyer mile for each dollar spent using the credit card. The customer subsequently redeems the frequent flyer miles earned for airline tickets or upgrades in accordance with the rules of the frequent flyer mile program. In a second type of incentive program, the customer may receive 5 incentive "points" or stamps for a purchase based on the value of the purchase. For example, if a customer purchases a $1,000 item, then the customer may receive 1,000 points. For this type of incentive program, the customer is provided with a means for redeeming the points. Typically, the customer may select items from a catalog to redeem the points for merchandise or services. 10 Although the catalog provides the customer with a greater selection than the predetermined benefit program, the customers benefit is constrained to items in the catalog. A merchant, when setting up the incentive program, must select how the customer will receive benefit from participation in the incentive program. 15 For example, the merchant may set up the incentive program with a vendor or supplier of the value, such as a frequent flyer mile program, so that the customer receives a pre-determined benefit (e.g., frequent flyer miles) after the customer purchases the merchant's product. Alternatively, the merchant may develop a catalog of merchandise for which the customer may redeem items based on the 20 amount awarded. Accordingly, because the merchant desires to confer the maximum benefit on the customer, it is desirable, when implementing an incentive program, to provide the customer with a wide array of choices while WO 00/21008 PCT/US99/23077 3 minimizing the overhead required by the merchant to implement the incentive program. As outlined above, incentive programs are currently used for credit card transactions, as well as customer transactions performed at a merchant's 5 store. However, the Internet provides numerous opportunities for conducting transactions, including electronic commerce. The potential for commerce over the Internet is great because a user, through use of a computer logged onto the Internet, may reach a huge number of merchants. Because incentive programs are an effective way of motivating customers to purchase goods or services, it is 10 desirable to implement an incentive program for use with the Internet. One implementation of an on-line incentive program is to completely implement the incentive program on a clearinghouse web site, distinct from merchants' web sites. For this implementation, a user is directed from a merchant's web site to the clearinghouse web site to conduct the transactions 15 required to confer benefit upon the customer. However, directing the customer away from the merchant's web site is undesirable. Furthermore, because the incentive program is implemented solely at the clearing house site, the merchant loses all control over the parameters of the incentive program. Therefore, it is desirable to provide a balance between allowing the merchant to control certain 20 aspects of the incentive program, while maximizing the benefit the customer receives for participating in the incentive programs. Networks have been developed to transfer sensitive financial WO 00/21008 PCT/US99/23077 4 information, such as credit information, from a customer to a clearinghouse. For example, credit cards and automatic teller machines (ATM) cards are used in a secure fashion to transfer financial information from a consumer to a merchant via the credit card or bank clearinghouse. Because the systems are vulnerable to 5 attack, many safeguards have been implemented to ensure that such transactions are secure to prevent fraud and theft. However, these general safeguards are tailored to accommodate value transactions from a consumer to a merchant. As is described fully below, the present invention implements a value transfer network that implements safeguards and protections to optimize a system that 10 transfers value from merchants to consumers (i.e., in the reverse direction of the typical purchase transaction). SUMMARY OF THE INVENTION An on-line incentive system provides a means for a consumer to 15 enter an earning activity to earn value from the merchant. The value is initially conferred in the form of private label currency. If the consumer qualifies, value is transferred from the merchant to the consumer without re-directing the consumer away from the merchant's web site. In this way, the consumer's focus of activity remains at the merchant's web site. At the clearinghouse, the 20 consumer is provided a means to redeem the private label currency value for goods and services. In one embodiment, software at the merchant's web site determines WO 00/21008 PCT/US99/23077 5 whether the consumer qualifies to earn value by defining parameters that determine the earning activity. A request for authorization, originating at the merchant's location, is dispatched to a clearinghouse to transfer value from the merchant to the consumer. In one embodiment, the functionality that determines 5 whether the consumer qualifies to earn value is performed on the merchant's web server, payment server or fulfillment server, and the functionality to request authorization to a clearinghouse resides on a separate remote incentive management server. In one embodiment, the incentive management system includes a 10 value transfer network. The value transfer network provide a secure and reliable means to transfer value from a merchant to a consumer. Through use of the value transfer network, a request is generated, at the merchant's location, to authorize a value transfer from a merchant's account to a consumer's account. The request is dispatched, via the Internet or a private network, from the 15 merchant site to the clearinghouse site. If the value transfer is unsuccessful, then the incentive management system enters an asynchronous retransmission mode, wherein the value transfer is periodically initiated from the merchant location to the clearinghouse location until a transaction confirmation is received at the clearinghouse site. Also, the value transfer, signed and encrypted, is logged in 20 the form of human readable text. At the clearinghouse site, authorization for the value transfer is determined, and a response message that indicates a status for the authorization is dispatched to the merchant. Thereafter, a response is sent to WO 00/21008 PCT/US99/23077 6 the consumer that indicates the status of the authorization request. The consumer may receive a response via e-mail. Thus, the consumer receives a real-time response regarding the result of the value transfer. The earning activity may include any action or response the 5 merchant seeks to elicit from the consumer. In one embodiment, the merchant seeks, in a "lend" earning activity, the lending of the consumer's attention in a manner pre-defined by the merchant. A "send" earning activity generally involves the merchant's desire for the consumer to send information requested by the merchant. In a "bend" earning activity, the merchant seeks to bend the 10 behavior of the consumer in a manner pre-defined by the merchant. Also, a "spend" earning activity motivates the consumer to purchase merchandise or services offered by the merchant. BRIEF DESCRIPTION OF THE DRAWINGS 15 Figure 1 is a diagram illustrating one embodiment for an on-line incentive system. Figures 2a - 2c illustrate an example of a consumer's host display during a real-time value transfer transaction in accordance with one embodiment of the present invention. 20 Figure 3 illustrates one embodiment to deploy a remote incentive management system at the merchant's location. Figure 4 is a flow diagram illustrating one embodiment for remote WO 00/21008 PCT/US99/23077 7 incentive management software operating at the merchant's location. Figure 5 is a flow diagram illustrating one embodiment for processing a request for authorization message in the remote incentive management system. 5 Figure 6 is a flow diagram illustrating one embodiment for processing request for point authorization (RFA) messages at the clearinghouse location. Figure 7 illustrates one embodiment of a remote incentive management system implemented at the merchant's location. 10 Figure 8 is a flow diagram illustrating one embodiment for consumer private label currency redemption. Figure 9 illustrates a high level block diagram of a general purpose computer system in which the servers of the incentive system of the present invention may be implemented. 15 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Private Label Currency System: In a preferred embodiment, an incentive system involves interaction 20 among a consumer, a merchant, and a clearinghouse. Figure 1 illustrates one embodiment for an on-line incentive system. In one embodiment, the incentive system is implemented as an Internet incentive system. In general, the incentive WO 00/21008 PCT/US99/23077 8 system 100 involves three entities: a consumer 110, a merchant 120, and a clearinghouse 130. For purposes of simplicity, the consumer, merchant, and clearinghouse are referred to in the singular form; however, the incentive program typically supports many consumers and merchants, and may involve 5 more than a single clearinghouse. For purposes of explanation, a consumer is any entity, whether an individual or business, for which a merchant desires to transfer or confer value. A merchant, as used herein, generally refers to any entity that desires to transfer value to a consumer in exchange for certain behavior or activity. A clearinghouse, as used herein, denotes an entity that 10 redeems consumer value, conferred by the merchant, for services or goods of suppliers. In general, a consumer earns or receives value, or private label currency, from a merchant, and the consumer subsequently redeems the value for goods and services via the clearinghouse. In a preferred embodiment, the 15 communications to support a value transfer from the merchant to the consumer, and the subsequent redemption by the consumer, occur over the open Internet. The "Z" shaped double headed arrows, shown on Figure 1, denote bi-directional communication via the Internet. Although the value transfer and value redemption of the present invention is described in conjunction with 20 communication over the Internet, any form of communication, such as a direct telephone line connection, may be used without deviating from the spirit and scope of the invention.

WO 00/21008 PCT/US99/23077 9 In one embodiment, to receive value, the consumer 110 surfs up to a web site of merchant 120, and the consumer 110 enters an "earning activity", specified by the merchant 120. As described more fully below, the earning activity may include any behavior or activity the merchant seeks to extract from 5 the consumer 110. Once the consumer 110 has completed the earning activity to the satisfaction of the merchant 120, value for the earning activity is transferred from the merchant 120 to the clearinghouse 130. Thereafter, the consumer 110 may contact a web site, supported by the clearinghouse 130, to redeem value for goods and services. As described more fully below, the 10 consumer 110 must perform a one time authorization to redeem the value at the clearinghouse 130. The incentive system consists of a plurality of merchants 120 who are association with the clearinghouse 130. In general, the private label currency is not bound to a specific redemption item, such as frequent flyer miles, or bound 15 to a specific catalog. With this system, the consumer 110 may earn value from different merchants, who participate in the incentive program, for deposit, and subsequent redemption, of the value at a single repository (e.g., the clearinghouse 130). In one embodiment, the value, or private label currency, is measured in points, and the consumer 110 redeems "X" points of the private label 20 currency for "X" amount of services and/or products. The use of private label currency system of the present invention provides a vehicle for merchants to implement incentive programs while WO 00/21008 PCTIUS99/23077 10 protecting the pricing policies of the merchants. If an incentive program uses currency (e.g., cash or credit), then the consumer may readily ascertain, and consequently calculate, a monetary value for the value transferred from the merchant to the consumer. For example, if a consumer receives, in an incentive 5 program, one dollar of value for every one hundred dollars purchased, then the incentive discount is readily understood by the consumer. Thus, the use of public currency in an incentive program exposes the pricing policy (e.g., purchase price minus the amount of currency earned) directly to the consumer. However, with use of private label currency, which is later redeemed by the 10 consumer for some other value, the monetary amount conferred by the merchant to the consumer is not readily evident, and thus the pricing policy of the merchant is preserved. In general, the clearinghouse 130 operates as a repository of value earned by the consumer at one or more merchants. As shown in Figure 1, the 15 clearinghouse 130 is coupled to the suppliers 140, to indicate a relationship between the suppliers 140 and the clearinghouse 130. Specifically, the clearinghouse 130 transforms the private label currency for some form of value provided by the supplier 140. For example, the consumer 110 may redeem the private label currency for frequent flyer miles. In this example, the supplier 140 20 represents an airline, or airline coalition, that awards frequent flyer miles to the consumer after the clearinghouse 130 transfers hard currency to the supplier 140 (e.g., airline provider). The consumer 110 may redeem the private label currency WO 00/21008 PCT/US99/23077 11 for any type of value, such as cash, credit, tangible goods, services, etc. In one embodiment, the merchant 120 and clearinghouse 130 have a prearranged contractual relationship. Specifically, the merchant 120 purchases value or private label currency, and the clearinghouse 130 maintains a merchant 5 account that reflects the amount of value held by that merchant. As described more fully below, as the consumer 110 earns value from a merchant, value is debited from the merchant account, and credited to the consumer account under predetermined rules (e.g., completion of all phases of the transaction). The clearinghouse 130 also maintains a consumer account from which the consumer, 10 through a redemption process, transforms value into goods and/or services of suppliers 140. Figures 2a - 2c illustrate examples of consumer host displays during a real-time value transfer transaction in accordance with one embodiment of the present invention. The "Z shaped" line indicates communication over the Internet 15 from the consumer's host to the merchant's web site. A consumer, utilizing a web browser, such as Netscape Navigator or Microsoft* Explorer, "surfs up" to a merchant's web site. In some way, the merchant's web site invites the consumer to enter an earning activity. Figure 2a illustrates an example display at the consumer's host that invites the consumer to commence an earning activity 20 at the merchant's web site. As described more fully below, an earning activity may entice the consumer to: purchase products and/or services; lend time to a predefined activity on the merchant's web site; bend their behavior in some pre- WO 00/21008 PCT/US99/23077 12 defined way; or send information about themselves to the merchant. In one embodiment, after the consumer enters the earning activity, the merchant notes that the consumer entered the earning activity, and verifies the operation of the remote incentive management system (Figure 3). If the 5 incentive management system is not operable, then the merchant notifies the consumer host that value will not be earned at this time for the earning activity. If the incentive management system is operable, and the customer completes the earning activity, as defined by the merchant, then the merchant generates a request for authorization to the clearinghouse 130 (Figure 1). If the 10 clearinghouse 130 authorizes the transaction in response to the request for authorization, then a response message is generated and sent to the merchant 120. Thereafter, the merchant 120 notifies the consumer 110 that value has been earned for the earning activity. Figure 2b illustrates an example display response to notify the 15 consumer that the value has been earned (e.g., congratulations you have earned value). If a failure occurs in the value transfer network (e.g., the network between the merchant 120 and the clearinghouse 130), then the consumer is notified that value will be earned pending verification that the earning activity and the consumer comply with predetermined rules or criteria as shown in the 20 example display of Figure 2c. As illustrated by the above example, the incentive management system provides, with respect to the consumer, a "real-time" response to inform WO 00/21008 PCT/US99/23077 13 the consumer as to the status of the earning transaction. Accordingly, by providing a real-time response to the consumer regarding the consumer's value earned, the consumer receives a greater sense of satisfaction when participating in an incentive program, and is more likely to participate in additional incentive 5 programs. In one embodiment, the incentive management system of the present invention processes value or private label currency transactions as multiple phase transactions. The use of multiple phase transactions provides a rational model for debiting value from the merchant's account. In one embodiment, value 10 transfer includes three phases: authorization, capture, and charge back. During the authorization phase, the clearinghouse determines whether the merchant has sufficient credit (e.g., value) to commit the transaction. During the second phase, capture, actual transfer of value occurs from the merchant's account into the consumer's account. The last phase, charge back, permits removing value 15 from a consumer's account if, subsequent to the capture phase, circumstances arise that invalidate the transaction. In general, the clearinghouse implements the value transfer phases of authorization, capture, and charge back. Accordingly, although the clearinghouse conducts real-time authorization to deposit value into the consumers account, value is only ultimately conferred to the consumer 20 pending the capture and charge back phases of the transaction. For the authorization phase, the incentive management system executes frawi control procedures to ensure that the consumer is valid (e.g., WO 00/21008 PCT/US99/23077 14 consumer qualifies to receive the value), and it determines whether the merchant is capable of conferring the value. In one embodiment, to implement the capture phase, the incentive management system allows the merchant to view transactions to make a determination as to whether the value, previously transferred from the 5 merchant account to the consumer account, is valid. For example, if the earning activity is based on a consumer purchase, then the merchant capture and charge back phases may be consistent with the financial transactions associated with a purchase (e.g., a credit card transaction). For this example, if a dispute or charge back occurred with the credit card, then the merchant would not capture 10 value for transfer to the consumer account. In one embodiment, to implement the capture phase, value is transferred to the consumer account after a predetermined amount of time unless the merchant explicitly voids the transaction. In a second embodiment to implement the capture phase, the merchant sends a confirmation to the incentive 15 management system to commit the value transaction (e.g., debit of the merchant account and credit of the consumer account). To implement a charge back in the incentive management system, the merchant executes an additional transaction to the clearinghouse to revoke value from the consumer (e.g., void the value transaction). 20 Earning Activity: The "earning activity" for the incentive program may include any WO 00/21008 PCTIUS99/23077 15 activity or behavior that the merchant seeks to extract from the consumer. In one embodiment, earning activities include events that occur across the entire consumer relationship cycle, including the introduction of relations between a consumer and a merchant. A "lend" earning activity involves the consumer 5 lending some time and attention to an activity sought by the merchant. The lend earning activity may include any activity that requires the consumer to lend attention to the merchant. For example, the merchant may want consumers to read an advertisement posted on a merchant's web page. A "send" earning activity involves the consumer sending information 10 about themselves to the merchant. The merchant may desire to award value to consumers for a send earning activity in order to conduct market research. For example, the merchant may request, for a send earning activity, that the consumer complete a survey that includes preferences, tastes, demographic information, etc. 15 A third earning activity, referred to as a "bend" earning activity, is used by the merchant to change the behavior of a consumer. For example, a bank may desire to award those customers who use an on-line banking service to conduct bank transactions. For this example, the merchant seeks to change the behavior of a consumer by enticing the consumer to use on-line banking services 20 instead of using a live teller. By further way of example, in an attempt to reduce overhead, a delivery service may want its customers to place orders through an on-line delivery request form.

WO 00/21008 PCT/US99/23077 16 A fourth category of earning activity, referred to as a "spend" earning activity, involves a merchant that rewards consumers for purchasing products and/or services from the merchant. For example, a merchant may award value to a consumer based on the dollar amount of the consumer purchase. 5 Remote Incentive Management System Deployment: Figure 3 illustrates one embodiment to deploy a remote incentive management system at the merchant's location. The remote incentive management server 315, and software operating thereon, is characterized as 10 "remote" because the functionality is implemented at the merchant's location, and is thus remote from the clearinghouse location. For this implementation, the merchant 120 (Figure 1) includes a merchant web server 300, a remote incentive management server 315, a transaction log 320, and the merchant's firewall 325. In addition, software running on the merchant's web server 300 communicates 15 with software running on the remote incentive management server 315 via a request for authorization-application program interface (RFA-API) 310. In one embodiment, the merchant's web server 300 and remote incentive management server 315 are coupled at the merchant's location via a local area network (LAN). 20 An implementation for the clearinghouse is also shown in Figure 3. The clearinghouse is implemented through a consumer's account server/database 335, clearinghouse incentive management server 340, merchant's account WO 00/21008 PCT/US99/23077 17 database 350, and the clearinghouse firewall 355. The consumer, who interacts with both the merchant and clearinghouse, is represented by block 330, denoted as the consumers Internet access. The "Z" shaped lines, terminated with arrows, connote an interface over the Internet. The consumers Internet access 330 5 communicates, over the Internet, to the merchant's web server 300, as well as the consumers account server/database 335. As described fully below, the value transfer network involves communication over the Internet between the remote incentive management server 315 and the clearinghouse incentive management server 340. 10 As shown in Figure 3, for this embodiment, the functionality for the remote incentive management system is implemented on a server (315) distinct from the merchant's web server 300. In addition, a merchant may have several web servers at the merchant's location, and one or more web servers may communicate to the remote incentive management server 315. In one alternative 15 embodiment, functionality for the incentive management system is implemented remote from the merchant's location. For example, the incentive management system may be implemented as part of the payment and fulfillment system. In another alternative embodiment, the merchant's web server may include the remote incentive management system software, and may directly communicate 20 to the clearinghouse incentive management server 340. However, running the remote incentive management software on a separate server than the merchant's web server has several advantages when implementing a remote incentive WO 00/21008 PCT/US99/23077 18 management system. To implement the functionality of the remote incentive management software, as described herein, on the merchant's web server 300, significant modifications of the merchant's web server software would be required. For 5 example, transactional software, which implements complex transactions such as electronic commerce, often requires replacing the merchant's web server software with entirely new software. The partitioning of the merchant's web server 300 with the remote incentive management server 315 is a very different solution for implementing complex transaction functionality at the merchant's 10 location. For the incentive management system shown in Figure 3, the merchant's web server 300 requires minimal software running on the merchant's web server 300. The remote incentive management server 315 implementation allows for a clear and clean partition between the merchant's web server and functions 15 associated with the incentive system. In general, the merchant's web server is a very vulnerable part of the overall perimeter security of the merchant's computer system. For purposes of security, a firewall, designated in Figure 3 as merchant's firewall 325, is implemented to monitor and limit entry onto to the merchant's web server 300. The server division between the merchant's web 20 server and the remote incentive management server allows for a clean partition of liability between the merchant and the clearinghouse. For example, if a security break in occurs on the merchant's web server due to a security breach, WO 00/21008 PCT/US99/23077 19 then liability will not fall on the incentive management system due to the simple interaction (e.g., one API call) between the merchant's web server 300 and the remote incentive management server 315. Thus, the remote incentive management server 315 does not compromise the security of the merchant's web 5 server. If such a security breach does occur, the point of entry or break in, as between the merchant's web server software and the remote incentive management software, is evident. If the incentive management software was fully implemented on the merchant's web server, and a security break in or security breach occurred on the merchant's web server, then the incentive 10 management software may be a point of attack that results in breach of the merchant's perimeter security. Furthermore, the server division allows the merchant to protect cryptographic keys that reside in the remote incentive management server 315 because the server 315 is not part of the outer perimeter of security at the merchant's location. 15 The separation of functionality between the merchant's web server 300 and the remote incentive management server 315 further allows for the merchant to fully define the earning activity. In a preferred embodiment, the merchant fully implements the functionality to support the earning activity on the merchant's web server 300. In this way, the merchant solely determines the 20 conditions for which a consumer earns value through the earning activity. By allowing the merchant to fully control the earning activity, the incentive management system provides the greatest flexibility to the merchant.

WO 00/21008 PCT/US99/23077 20 In one embodiment, the merchant's web server software communicates with the remote incentive management server software via the RFA-API 310. In general, the RFA-API 310 is an application program interface, which runs on the merchant's web server, that the merchant's software 5 calls to start a value transaction. The RFA-API call starts a "client/server" transaction between the merchant's web server 300 and the remote incentive management server 315. The RFA-API provides the link to separate the process between the merchant's web server 300 and the remote incentive management server 315 to commence a value transfer transaction. 10 As discussed more fully below, a call to the RFA-API, by the merchant software, signifies: entry of a consumer into the merchant defined earning activity; and the commencement of a value transfer to deposit value in the consumer's account. Because the RFA-API is conducted over a local area network, a less secure transaction between the merchant's web server 300 and the 15 remote incentive management server 315 is required than a transaction that pierces the merchant's perimeter security. The RFA-API is ported across a wide variety of platforms to provide maximum flexibility to interface the merchant's web server software to the remote incentive management system software. In one embodiment, the RFA-API calls support calls from any programming 20 language, such as C, C++, Perl, Java, etc. In one embodiment, as an enhancement to the incentive system, the remote incentive management system executes rules that define certain WO 00/21008 PCTIUS99/23077 21 parameters for the earning activity (i.e., earning activity rules). In general, the earning activity rules, executed by the remote incentive management system, facilitate the merchant's implementation of functionality that defines the earning activity. For example, earning activity rules, when executed, may impose 5 limitations and constraints on the consumer's qualification to earn value in a manner desirable for many types of incentive programs. In one embodiment, the merchant may select which rules to enforce, and thereby customized the use of the earning activity rules. In another implementation for a remote incentive management 10 system, a "minting engine" is executed at the consumer. In general, the minting engine performs the functionality to effectuate a value transfer from a merchant to the consumer. In one embodiment, the minting engine is software running on the consumer's computer. In operation, the consumer enters an earning activity, at the merchant's web site, to earn value from the merchant as described above. 15 If the consumer qualifies, the merchant enables the consumer's minting engine to begin the value transfer from the merchant's account to the consumer's account. Thereafter, the consumer initiates a value transfer request to a clearinghouse to effectuate the transfer of value from the merchant to the consumer. 20 Value Transfer Network: In one embodiment, the incentive management system implements WO 00/21008 PCT/US99/23077 22 functionality for a value transfer network through software operating on the remote incentive management server 315. Figure 4 is a flow diagram illustrating one embodiment for incentive management software operating at the merchant's location. Prior to executing a value transfer transaction, the consumer enters an 5 earning activity on the merchant's web server, as shown in block 400. As shown in blocks 410 and 420, if the remote incentive management system is operable, then it records the consumer's entry into the earning activity. As shown in blocks 410 and 430, if the incentive management system is not operable, then the consumer is notified that value will not be awarded at this time for the earning 10 activity. In one embodiment, the merchant's software determines whether the incentive management system is operable through a call to the RFA-API. A non operable incentive management system may be a result of the remote incentive management server 315 being down. This initial call to the remote incentive system provides feedback to the consumer, such that if the remote incentive 15 management system is not working, the consumer learns that he or she will not earn value for completion of the earning activity. This initial call significantly reduces the probability of failure in the value transfer network by insuring that the remote incentive management server 315 is initially operable. If a consumer is allowed to complete the earning activity without warning that the consumer 20 will not receive value for the earning activity, then the consumer will be dissatisfied with the incentive program. Thus, with regard to the consumer, the initial check to determine operability of the remote incentive management server WO 00/21008 PCT/US99/23077 23 315 permits a graceful shutdown of the incentive program. As shown in block 440 of Figure 4, the incentive management system waits until the consumer completes the earning activity. When the consumer completes the earning activity, the merchant verifies the completion of 5 the earning activity as shown in block 450. For example, the merchant may impose several conditions or rules on the earning activity, and this step verifies that the consumer complied with these rules or conditions. After verification, the merchant executes a second call to the incentive management system via the RFA-API as shown in block 460. As shown in block 470, the incentive 10 management system creates a secure request for point authorization (RFA) message. In one embodiment, the RFA message is processed for transmission over the open Internet. In addition to creating the secure RFA message, the incentive management systems logs the RFA message in the transaction log 320 (Figure 3) as shown in block 480. As shown in block 490, the RFA message is 15 dispatched over the Internet to the clearinghouse. Figure 5 is a flow diagram illustrating one embodiment for processing a request for authorization message in the remote incentive management system. As discussed above, the remote incentive management system, operating at the merchant's location, creates a secure RFA message 20 (block 470, Figure 4). As shown in block 500, the remote incentive management system generates a clear text message requesting the value transfer. Table 1 lists several fields for RFA message.

WO 00/21008 PCT/US99/23077 24 Table 1 Merchant ID Sequence # 5 Date Stamp Promotion ID Amount Awarded Consumer's E-Mail Address Authentication Token 10 The merchant identification (ID) field uniquely identifies the merchant. The sequence # field stores a number to order or sequence multiple RFA messages. For example, multiple RFA messages may be transferred for a value transfer. With the sequence #, the clearinghouse incentive management server 340 may 15 determine the original sequence of the messages. The date stamp, resolved to the nearest second, reflects the time the message was created, and thus uniquely identifies the message. A promotional ID field identifies the particular promotion for which the value has been earned. This permits the clearinghouse to track and record information regarding various promotions that a merchant 20 may run. The RFA message further includes an amount awarded to the consumer. For example, if the private label currency is measured in points, then the amount awarded is a specific amount of points. The consumers e-mail address is also included so that the clearinghouse, if necessary, may attempt to contact the consumer. The last field shown in Table 1, the authentication token 25 field, provides some sort of authentication, originated by the consumer, to bind WO 00/21008 PCT/US99/23077 25 the network identity of the consumer to a social identity of the consumer. The incentive management system encrypts the clear text RFA message as shown in block 510. In one embodiment, the incentive management system implements private key cryptography to encrypt RFA messages. 5 Although the incentive management system is described using private key cryptography, any algorithm that encodes or encrypts the RFA message may be used without deviating from the spirit or scope of the invention. In a preferred embodiment, an encryption technique is used that optimizes security and speed of the encryption (i.e., the level of security is maximized while the overhead to 10 encrypt the message is minimized). In general, with private key cryptography, a single secret key is used to both encrypt a message as well as decrypt the message. Typically, public key cryptography is used when there are a large number of users. For example, to encrypt a message between a consumer and a merchant, a public key cryptography system would require excessive key 15 management due to the large number of potential consumers. The private key cryptography algorithms may be executed more quickly than public key cryptography algorithms. However, private key cryptography introduces key management problems that do not exist in public key cryptography. In an incentive management system, there are relatively few merchants in relationship 20 to the number of consumers. Accordingly, the key management problem is reduced because the keys are securely maintained by only the merchants and clearinghouse.

WO 00/21008 PCT/US99/23077 26 In one embodiment, the keys, to encrypt the RFA message, are stored in the remote incentive management server 315 (Figure 3). The remote incentive management server, which is isolated from the perimeter security of the merchant's location, provides a secure location to maintain the secret keys. 5 As shown in block 520 of Figure 5, the remote incentive management system signs the encrypted message using a signature key. A digital signature technique is a well known technique to authenticate a message. As is well known, a digital signature is derived from the specific message, as well as the merchant's secret key. Specifically, the use of a digital signature 10 authenticates that the message originated from the merchant, and thus the digital signature detects any tampering of the message that may have occurred over the open Internet. As shown in block 530, the signed/encrypted RFA message is dispatched to the clearinghouse over the Internet. In one embodiment, two 15 protocols are used to transfer the signed/encrypted RFA message over the Internet. Because the RFA messages are relatively small, a UDP protocol can be used to transfer the RFA message. The UDP protocol is a highly unreliable protocol for transmitting messages over the Internet. In a second embodiment, the http protocol is used to transmit the RFA message. The http protocol, 20 although requires higher overhead, is generally more reliable than the UDP protocol. Some merchants may only support a single protocol to reduce the complexity in maintaining perimeter security. For these merchant locations, the WO 00/21008 PCT/US99/23077 27 http protocol may be used. If several protocols and ports are supported at the merchant site, then maintaining a secure perimeter at the merchant site becomes more difficult. In one embodiment, if the remote incentive management system does 5 not receive a reply after a predetermined amount of time, the remote incentive management system repeats the functions in blocks 520 and 530 (e.g., re-signs the encrypted RFA message and dispatches the new message to the clearinghouse over the Internet). In another embodiment, as shown in Figure 5, the remote incentive management system only repeats the function in block 530 by 10 dispatching the new message to the clearinghouse over the Internet. If the remote incentive management system does receive a reply from the clearinghouse, then it logs the transaction in the transaction log 320 (Figure 3) as shown in block 550. In one embodiment, the transaction log 320 records all significant transactions that occur in the incentive system. The transaction log 15 320 is a human readable text log to allow an administrator to manually review incentive system transactions. The entries to the transaction log 320 are signed and encrypted so that there is no possibility that a log message will be resent, thereby executing two value transfers for the same earning activity. As shown in block 560 of Figure 5, the incentive management 20 system responds to the merchant's web server software (e.g., CGI program), with a response to the RFA message. Figure 6 is a flow diagram illustrating one embodiment for processing RFA messages at the clearinghouse location. As WO 00/21008 PCT/US99/23077 28 shown in block 600, the clearinghouse receives the RFA message via the Internet. For purposes of explanation, the clearinghouse processes are executed on the clearinghouse incentive management server 340 (Figure 3). As shown in block 610, the clearinghouse incentive system validates the merchant's digital 5 signature on the RFA message. In general, this step includes executing an algorithm to ascertain whether the RFA message had been forged, altered in transit, or damaged in transit. The clearinghouse incentive system also verifies that the RFA message was not already received (e.g., the RFA message has already been processed). If the RFA message was previously processed, then the 10 clearinghouse incentive system confirms that value transfer has occurred. As shown in block 620, fraud control procedures are executed. In one embodiment, there are two general classes of fraud control procedures: 1) procedures derived from contractual terms between the merchant and the clearinghouse; and 2) statistical procedures that detect abnormal transactions. 15 The contractual terms class of fraud procedures, which are dictated by the merchant, detect violations of rules that govern the transfer of value to a consumer. For example, the merchant may: limit the amount of value conferred to a consumer; limit the amount of times value may be transferred to a consumer; and limit the total value that may be transferred to a consumer. 20 These rules are mere examples, and the merchant may define any constraints for subsequent implementation as fraud control procedures. The statistical fraud control procedures detect abnormal transactions, WO 00/21008 PCT/US99/23077 29 and they are not merchant specific. For example, this class of fraud control procedures may detect that a single consumer is earning a significant amount of value from different merchants within a small period of time. Statistically, such an activity may identify fraud or abuse to the overall incentive system. A further 5 example of this class of fraud control procedures includes detecting value transfer from a single consumer from multiple merchants at substantially the same time. As demonstrated in Figures 2a - 2c, the incentive system provides a real-time response to the consumer. Therefore, one important aspect of implementing fraud control procedures is the consideration of the amount of 10 processing time required to execute the fraud control procedures. In one embodiment, a balance is stricken between the amount of fraud control procedures executed during the real-time processing, and the response time associated therewith. For example, the incentive management system may balance the results obtained from executing fraud control procedures against the 15 amount of time taken to execute the procedure. If the fraud control procedures detect fraud (e.g., abnormal behavior), then the clearinghouse incentive system generates a digitally signed and encrypted response message that indicates detection of fraud as shown in blocks 630 and 650 of Figure 6. Alternatively, if fraud is not detected, then the 20 clearinghouse incentive system executes a two phase transaction commitment to debit the merchant's account and credit the consumer's account the value specified in the RFA message, as shown in blocks 630 and 640. The WO 00/21008 PCT/US99/23077 30 clearinghouse incentive system utilizes the merchant ID and the authentication token fields of the RFA message to debit the merchant account and credit the consumer account. As discussed above, although the authentication phase is executed at this time, post solution activity (e.g., capture and charge back), may 5 occur to reverse the transaction. As shown in block 650, the clearinghouse incentive system generates a response message. Table 2 lists a number of fields for a response message configured in accordance with one embodiment. 10 Table 2 Sequence # Merchant ID Time 15 Status Code The clearinghouse incentive system, to generate the response message, calculates a sequence number for the sequence # field. The sequence number mimics the sequence number contained in the RFA message. The merchant ID, also 20 contained in the RFA message, uniquely identifies the corresponding merchant. The time field inserts a date stamp, resolved to the nearest second, for the response message. The status code field, listed in Table 2, indicates a status for the corresponding RFA message. In one embodiment, the clearinghouse incentive system generates one of four status codes. A deposit succeeded status WO 00/21008 PCT/US99/23077 31 code indicates that the value transfer transaction was committed (e.g., the merchant account was debited and the consumer account was credited). A second type of status code indicates that the request for authorization has been denied due to a condition detected in the fraud control procedures. A third type 5 of status code, which also connotes a denied authorization status, indicates that there is insufficient value in the merchant's account to execute the transaction. An additional type of denied status code indicates that the consumer credential, as identified through the authentication token, is insufficient. For example, the authentication token, which identifies the consumer, may not be sufficient to 10 verify the consumer is the person or entity that the consumer purports to be. In one embodiment, the clearinghouse incentive system records information regarding the transaction so as to compile profiles regarding transactions in the incentive program. For example, from the clearinghouse profiles, the clearinghouse may generate information identifying a type of 15 consumer that participated in one or more promotional activities sponsored by the merchant. The clearinghouse may generate profiles across all merchants to indicate the type of consumer that is attracted to particular types of promotions. With the RFA and response message information, the clearinghouse incentive system may generate numerous types of profiles. 20 Also, as shown in block 650 of Figure 6, the clearinghouse incentive system digitally signs and encrypts the response message. In one embodiment, the clearinghouse incentive system utilizes a symmetric cryptography algorithm WO 00/21008 PCT/US99/23077 32 to encrypt the response message with the merchant's secret key. However, any algorithm may be used to digitally sign and encrypt the response message. As shown in block 660 of Figure 6, the clearinghouse incentive system transmits the response message from the clearinghouse location to the 5 merchant location over the Internet. At the merchant location, the remote incentive management system decrypts the response message, as well as verifies the authenticity of the message through analysis of the digital signature as shown in block 670. The status of the message, as indicated in the response message status code, is recorded or logged in the transaction log 320 (Figure 3) as shown 10 in block 680. If the RFA message was generated in the asynchronous retransmission mode (see below), then the pending status for the asynchronous transaction is removed from the asynchronous transaction log. As shown in block 690, the remote incentive management system delivers a message to the consumer to indicate the status of the transaction. 15 In a preferred embodiment, the value transfer network of the incentive system insures reliable transfer of value transactions. As discussed above, the first call to the RFA-API 310, initiated after the consumer enters the earning activity, ensures that the remote incentive management system (e.g., server) is operable. This procedure minimizes system failure by indicating to the 20 consumer, before the consumer completes the earning activity, that a failure has occurred. Although the remote incentive management system may be operable, a failure may occur in transmitting the RFA message from the remote incentive WO 00/21008 PCT/US99/23077 33 management server to the clearinghouse (e.g., an Internet failure). For purposes of nomenclature, the real-time response to a consumer, as described in conjunction with Figures 2a-2c, is the synchronous mode of operation. If a failure occurs in providing a real-time response to the value transfer, then the 5 remote incentive management system enters an asynchronous retransmission mode. In general, when operating in the asynchronous retransmission mode, the remote incentive management system generates RFA messages on its own initiative. In one embodiment, value transfers, which are not successfully 10 executed due to a failure in the value transfer network, are signed, encrypted, and logged in an asynchronous transaction log. For this embodiment, RFA messages logged in the asynchronous transaction log are signed and encrypted to prevent the unauthorized tampering of RFA messages. Periodically, the remote incentive management server 315 initiates transfer of an RFA message on its own 15 initiative. For example, if the failure in the value network is attributable to the Internet, then the remote incentive management system resends the RFA message periodically. In one embodiment, when operating in the asynchronous retransmission mode, if a large amount of value is transferred to the consumer, then the incentive management system sends an e-mail message to the consumer 20 to verify that value has been awarded to the consumer. As discussed above in conjunction with Figure 2c, if a network failure does occur, the consumer is notified that value will be transferred pending compliance with the incentive WO 00/21008 PCT/US99/23077 34 program conditions. If an asynchronous retransmission mode attempt is successful, such that the remote incentive management system receives a response message with a success status code, then the asynchronous retransmission mode transaction is removed from the asynchronous 5 retransmission mode log. If after several attempts the value transfer is unsuccessful, then the merchant notifies the clearinghouse of the value transfer via alternative means (e.g., means other than message transmission over the Internet). This notification, via alternative means, insures reliability of the value transfer. 10 Under this condition, the remote incentive management system may log the transactions to a permanent storage medium. Through use of the permanent storage medium, the transactions may be transferred to the clearinghouse, including physically transferring the permanent storage medium to the clearinghouse. Accordingly, the incentive system of the present invention 15 ensures reliable service to deposit value in a consumers account. In one embodiment, to further ensure reliability of the value transfer network, the remote incentive management system and the clearinghouse incentive system periodically execute "ping" transactions. For this embodiment, the remote incentive management system periodically sends a message, to 20 execute the ping transaction, that tests the communications link between remote incentive management system and the clearinghouse incentive system. At a minimum, the information, associated with a ping transaction, is signed and WO 00/21008 PCT/US99/23077 35 encrypted, and includes a time stamp to identify when the message was sent. However, the message may include any parameter. If successful, the remote incentive management system receives a signed and encrypted response from the clearinghouse incentive system, which also includes a time stamp to indicate 5 when the response was sent. Similarly, the response may include any parameter. Also, the clearinghouse incentive system may initiate the ping transaction. The remote incentive management system, residing at the merchant's location, may be administered remotely. In general, any number of functions, pertaining to the remote incentive management system, may be remotely 10 administered. For example, remote administration may include functions: to read the transaction log, to update software for the remote incentive management system, to shut down one or more incentive programs, to update the IP address, to change the frequency of the ping operation, etc. In one embodiment, the remote incentive management system is administered from the clearinghouse, 15 through use of software running on a server at the clearinghouse. Figure 7 illustrates one embodiment of a remote incentive management system implemented at the merchant's location. The merchant web server 300 is shown coupled to the incentive management system 400, which in one embodiment, comprises a separate server. As discussed above, the remote 20 incentive management system may be implemented on a single server. In one embodiment, the merchant's implementation on the merchant web server 300 includes a CGI program, designated as box 700 on Figure 7. However, the WO 00/21008 PCTIUS99/23077 36 functionality for the merchant's web server 300 may be implemented using NSAPI, ISAPI, and other similar server side scripting techniques. The double line, which terminates in an arrow, signifies that the CGI program 700 runs on the merchant web server 300. In general, the CGI program 700 includes three 5 basic functions. First, the CGI program 700 defines all parameters associated with the earning activity, including verification of completion of the earning activity. The CGI program, as a second function listed in block 700, calls the remote incentive management routines for a request for authorization (RFA) to transfer value to a consumer. As shown in Figure 3, in one embodiment, the 10 merchant web server software calls the RFA-API 310, shown in Figure 7 in box 310. As discussed above, the RFA-API 310 is a hook into the software of the remote incentive management system 400. As a third basic function, the CGI program 700 displays responses/results to the consumer (see Figures 2a, 2b, and 2c). The arrow, which couples the web server 300 to the remote incentive 15 management system 400, may be a network connection over a local area network (LAN). For this embodiment, the merchant fully implements the promotion functionality on the merchant web server 300. This implementation permits the merchant to maintain a customized web site while implementing the incentive 20 program. If a merchant, prior to implementing the incentive program, has functionality on a web page to support electronic commerce, then the merchant need only modify the web site to include the promotional aspects, such as the WO 00/21008 PCTIUS99/23077 37 addition of promotional pages. Accordingly, the merchant has full control and flexibility to implement the functionality to support the earning activity. Consumer Private Label Currency Redemption: 5 Referring again to Figure 3, one embodiment for a consumer private label currency redemption system is illustrated. The consumer, which gains access to the Internet via the consumers Internet Service Provider 330, locates a clearinghouse Internet site. This connection is illustrated by the "Z" shaped lines and corresponding arrows on Figure 3. In one embodiment, the 10 clearinghouse web site is supported by the clearinghouse incentive management server 340. Alternatively, a separate server, dedicated to the redemption process, may be implemented. The clearinghouse incentive management server 340 has access to the consumer account 335, as indicated by the line coupling the server 340 with the consumers account 335. 15 In general, the process of redemption involves a consumer that requests the transformation of the private label currency value into some other form of value. Figure 8 is a flow diagram illustrating one embodiment for consumer private label currency redemption. As shown in block 800, the consumer contacts the clearinghouse web site that supports the private label 20 currency redemption. The redemption process may be implemented on one or more web pages on the clearinghouse web site. A consumer, prior to redeeming any value, must authenticate himself or herself by effectively binding the WO 00/21008 PCT/US99/23077 38 consumer's network identity, used to earn the value, to the consumer's social identity. As shown in block 810, the consumer authenticates himself or herself to the clearinghouse incentive system. In one embodiment, to authenticate themselves, consumers submit a digital identification as well as a password if the 5 consumer has an account with the clearinghouse. If the consumer does not have an account, then the consumer must open a consumer account. In one embodiment, the authentication step is the same information used to generate the authentication token in the RFA message (Table 1). In general, to open an account, the consumer supplies information 10 to the clearinghouse. The type and amount of information supplied varies depending upon how risk is allocated for the incentive program. In one embodiment, at a minimum, the consumer supplies, to the clearinghouse, his/her name and e-mail address. Thereafter, the clearinghouse sends an e-mail to the consumer requesting additional information. In response to this e-mail, the 15 consumer supplies, to fully activate an account: history of participation in a merchant's earning activities, an identification (ID) to uniquely identify the consumer, and/or a digital certificate. In one embodiment, the digital certificate conforms to a digital certificate as defined by the standard x509.3. As shown in blocks 810 and 870, if the consumer is not 20 authenticated, then the consumer receives notice that the authentication has failed. If the authentication is successful, then the clearinghouse incentive system displays account information, for the corresponding consumer, as well as a WO 00/21008 PCT/US99/23077 39 redemption catalog as shown in blocks 810 and 820. In general, the account information includes the amount of value or private label currency earned by the consumer. For example, the account information may indicate the number of points awarded to the consumer. 5 The redemption catalog lists the goods and services available to the consumer for redemption of value. The services and goods may include frequent flyer miles, cash, credit, or any other goods and/or services. The redemption catalog may include, in addition to the list of goods and/or services, the amount of value required to redeem various goods and/or services. The redemption 10 catalog may also indicate a relative correspondence of value between the redemption catalog and the consumers earned value. For example, the consumer may redeem, for each point earned, one frequent flyer mile. As shown in block 830 of Figure 8, to redeem value, a consumer chooses a redemption item from the redemption catalog. In general, this step 15 involves some way for the consumer to transform value from the private label currency system into a good and/or a service. As shown in block 840 of Figure 8, the clearinghouse incentive system executes fraud control procedures. In general, the fraud control procedures insure that the consumer meets some statistical criteria prior to execution of the redemption process. For example, in 20 one embodiment, more stringent fraud control procedures may be executed where the consumer attempts to redeem a large amount of value. If fraud is detected (e.g., the consumer does not meet the statistical criteria), then the consumer WO 00/21008 PCT/US99/23077 40 receives notice that value will not be redeemed as shown in blocks 850 and 870. Alternatively, if fraud is not detected, then the incentive system debits the consumer account, and begins the supplier fulfillment process as shown in block 860. 5 In general, supplier fulfillment involves initiating the process to deliver the redemption good and/or service. For example, if the redemption item is frequent flyer miles, then the clearinghouse executes the necessary steps to deliver the redeemed value to the supplier, an airline. In turn, the supplier actually confers the redeemed value. For the frequent flyer miles award program 10 example, the supplier, an airline, awards the frequent flyer miles to the consumer. In the final step of the on-line redemption process, the consumer receives notice of the updated account information as shown in block 870. The updated account information includes the new total of value or private label 15 currency held by the consumer. For example, if the consumer, prior to redemption, had 2,000 points, and redeemed 1,000 points for a redemption item, then the incentive system displays the balance of 1,000 points as the updated account information. As discussed above, consumers, to participate in an earning activity 20 as well as redeem value, authenticate themselves. In general, a consumer authentication refers to the binding of a net identification to a social identification for a consumer. An authentication requirement raises the barrier of entry to a WO 00/21008 PCT/US99/23077 41 consumer to start earning value through an earning activity. It is desirable to lower the entry barrier to entice consumers to perform earning activity to earn value. However, if the consumer authentication requirement is minimal, then the system is susceptible to fraud and abuse. For example, a "Robin Hood" attacker 5 may attempt to drain all value from a merchant, even though the Robin Hood attacker has no intent to redeem the value. A "Doppleganger" attacker attempts to appear as many people, and the attacker seeks to gain an excessive amount of value. Thus, for the preferred embodiment, a balance is drawn between the competing interests of having a low authentication barrier to entice consumers to 10 earn value verse having a high authentication barrier to prevent fraud and abuse of an incentive program. In one embodiment, a first time consumer authentication process creates clearinghouse members by generating a consumer account with the clearinghouse (e.g., account information exists for the consumer in the consumer 15 account database 335 (Figure 3)). The first time consumer authentication is a one time only process. After completion of the first time consumer authentication process, the consumer performs a "normal" authentication, prior to entering an earning activity, whereby a consumer provides a UID-password or a public key certificate (e.g., the authentication token). 20 In one embodiment, the incentive system supports deferred authentication. In general, deferred authentication permits a consumer to enter an earning activity prior to the first time authentication. For this scenario, the WO 00/21008 PCT/US99/23077 42 consumer value earned during the earning activity is deposited into an inactive account. One rationale to implement a deferred authentication system is that once consumers earn value, they will be more motivated to perform the more rigorous first authentication procedure. For purposes of nomenclature, the 5 inactive account is referred to as a "pending transaction pool." In allowing deferred authentication, value is held in the pending transaction pool until the consumer performs the first authentication. Thus, value is only redeemable after the value has been transferred from the inactive account to a consumer account (e.g., after the first authentication). In a preferred 10 embodiment, the value held in the pending transaction pool expires after a predetermined amount of time, such as two weeks. Value held in the pending transaction pool may expire for any number of reasons. The consumer, who completed the earning activity prior to the first consumer authentication, has forgot to perform the first authentication, and therefore the value has expired 15 unintentionally. Value in the pending transaction pool may also expire from an attempted security breach, or an attempted denial of service attack. The use of the pending transaction pool presents an additional issue of billing between the clearinghouse and the merchant. In one embodiment, the merchant is billed (e.g., value is debited from the merchant account) when value 20 enters an inactive account. In a second embodiment, the merchant account is debited only when the consumer performs the first authentication, and the value is transferred to a specific consumer account. In a third embodiment, a WO 00/21008 PCT/US99/23077 43 combination of the first two embodiments is implemented, such that a portion of the value is debited from the merchant's account when the value enters an inactive account, and if the value is transferred to a specific consumer account, then the remaining portion of value is debited from the merchant account. 5 Computer System: Figure 9 illustrates a high level block diagram of a general purpose computer system in which the servers of the inventive system of the present invention may be implemented. A computer system 1000 contains a processor 10 unit 1005, main memory 1010, and an interconnect bus 1025. The processor unit 1005 may contain a single microprocessor, or may contain a plurality of microprocessors for configuring the computer system 1000 as a multi-processor system. The main memory 1010 stores, in part, instructions and data for execution by the processor unit 1005. If the incentive system of the present 15 invention is wholly or partially implemented in software, the main memory 1010 stores the executable code when in operation. The main memory 1010 may include banks of dynamic random access memory (DRAM) as well as high-speed cache memory. The computer system 1000 further includes a mass storage device 20 1020, peripheral device(s) 1030, portable storage medium drive(s) 1040, input control device(s) 1070, a graphics subsystem 1050, and an output display 1060. For purposes of simplicity, all components in the computer system 1000 are WO 00/21008 PCTIUS99/23077 44 shown in Figure 9 as being connected via the bus 1025. However, the computer system 1000 may be connected through one or more data transport means. For example, the processor unit 1005 and the main memory 1010 may be connected via a local microprocessor bus, and the mass storage device 1020, peripheral 5 device(s) 1030, portable storage medium drive(s) 1040, graphics subsystem 1050 may be connected via one or more input/output (I/O) busses. The mass storage device 1020, which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by the processor unit 1005. In the software embodiment, the mass storage 10 device 1020 stores the incentive system software for loading to the main memory 1010. The portable storage medium drive 1040 operates in conjunction with a portable non-volatile storage medium, such as a floppy disk or a compact disc read only memory (CD-ROM, to input and output data and code to and 15 from the computer system 1000. In one embodiment, the incentive software is stored on such a portable medium, and is input to the computer system 1000 via the portable storage medium drive 1040. The peripheral device(s) 1030 may include any type of computer support device, such as an input/output (I/O) interface, to add additional functionality to the computer system 1000. For 20 example, the peripheral device(s) 1030 may include a network interface card for interfacing the computer system 1000 to a network. The input control device(s) 1070 provide a portion of the user WO 00/21008 PCTIUS99/23077 45 interface for a user of the computer system 1000. The input control device(s) 1070 may include an alphanumeric keypad for inputting alphanumeric and other key information, a cursor control device, such as a mouse, a trackball, stylus, or cursor direction keys. In order to display textual and graphical information, the 5 computer system 1000 contains the graphics subsystem 1050 and the output display 1060. The output display 1060 may include a cathode ray tube (CRT) display or liquid crystal display (LCD). The graphics subsystem 1050 receives textual and graphical information, and processes the information for output to the output display 1060. The components contained in the computer system 1000 are 10 those typically found in general purpose computer systems, and in fact, these components are intended to represent a broad category of such computer components that are well known in the art. The incentive system may be implemented in hardware, software, or both. For the software implementation, the incentive management system is 15 software that includes a plurality of computer executable instructions for implementation on a general purpose computer system (e.g., one or more servers). Prior to loading into a general purpose computer system, the incentive system software may reside as encoded information on a computer readable medium, such as a magnetic floppy disk, magnetic tape, and compact disc read 20 only memory (CD - ROM). In one hardware implementation, the incentive system may comprise a dedicated processor including processor instructions for performing the functions described herein. Circuits may also be developed to WO 00/21008 PCT/US99/23077 46 perform the functions described herein. The transaction log, customer account and merchant account may be implemented as databases stored in memory for use by the incentive system software running on a server. Although the present invention has been described in terms of 5 specific exemplary embodiments, it will be appreciated that various modifications and alterations might be made by those skilled in the art without departing from the spirit and scope of the invention.

Claims (20)

1. CLAIMS What is claimed is: 1. A method for implementing an on-line incentive system, said method

   comprising the step of:

   providing, at a merchant's web site, a means for a consumer to enter an

   earning activity to earn value from said merchant; and

   transferring value from said merchant to said consumer for participation in

   said earning activity, if said consumer qualifies, without re-directing said

   consumer away from said merchant's web site, whereby said consumer's focus

   of activity remains at said merchant's web site.
2. 2. The method as set forth in claim 1 , wherein the step of transferring

   value comprises the step of providing, at a merchant's web site, a means for

   determining whether said consumer qualifies to earn value by defining parameters

   that determine said earning activity, wherein said consumer remains at said

   merchant's web site to earn value from said merchant.
3. 3. The method as set forth in claim 1 , further comprising the step of

   requesting authorization to a clearinghouse site to transfer value from said

   merchant to said consumer.
4. 4. The method as set forth in claim 1, further comprising the steps of: executing the step of providing a means for a consumer to enter an earning

   activity and a step of providing a means for determining whether said consumer

   qualifies to earn value on a merchant's web server; and

   executing a step of requesting authorization to a clearinghouse site to

   transfer value from said merchant to said consumer on a server distinct from said

   merchant's web server.
5. 5. The method as set forth in claim 1 , wherein the step of providing a

   means for a consumer to earn value through an earning activity comprises the

   step of providing a means for a consumer to lend attention in a manner pre-

   defined by said merchant.
6. 6. The method as set forth in claim 1, wherein the step of providing a

   means for a consumer to earn value through an earning activity comprises the

   step of providing a means for a consumer to send information requested by said

   merchant.
7. 7. The method as set forth in claim 1, wherein the step of providing a

   means for a consumer to earn value through an earning activity comprises the

   step of providing a means for a consumer to conduct an activity in a manner pre-

   defined by said merchant.
8. 8. The method as set forth in claim 1, wherein the step of providing a

   means for a consumer to earn value through an earning activity comprises the

   step of providing a means for a consumer to purchase merchandise offered by the

   merchant.
9. 9. A method for transferring value, conferred by a merchant, to a

   consumer, said method comprising the steps of:

   generating, at said merchant's location, a request to authorize a value

   transfer from a merchant account for said merchant to said consumer;

   dispatching said request from the merchant site to a clearinghouse site;

   authorizing, at said clearinghouse site, said value transfer from said

   merchant account for said merchant to said consumer;

   generating, at said clearinghouse site, a response message that indicates a

   status for said authorization; and

   generating a response to said consumer that indicates said status of said

   authorization request.
10. 10. The method as set forth in claim 9, further comprising the steps of:

    depositing said value into an account for said consumer; and

    debiting said value in said merchant's account.
11. 11. The method as set forth in claim 9, further comprising the step of

    re-sending said request message if a failure occurs in transmission between said

    merchant site and said clearinghouse site.
12. 12. The method as set forth in claim 9, further comprising the step of

    logging said value transfer transaction at said merchant location.
13. 13. The method as set forth in claim 12, wherein the step of logging said

    value transfer transaction comprises the step of logging said value transfer

    transaction as human readable text.
14. 14. The method as set forth in claim 12, wherein the step of logging said

    value transfer transaction further comprises the step of digitally signing and

    encrypting said value transfer transaction.
15. 15. The method as set forth in claim 9, wherein the step of generating

    a request to authorize comprises the step of encrypting said request message

    utilizing a private key cryptographic algorithm.
16. 16. The method as set forth in claim 9, further comprising the steps of:

    providing a means, for said merchant, to capture said value transfer; and

    providing a means, for said merchant, to execute a charge back against said value transfer.
17. 17. The method as set forth in claim 9, wherein the step of authorizing

    said value transfer comprises the step of executing fraud control procedures to

    detect consumer attempting to defraud said incentive system.
18. 18. The method as set forth in claim 9, wherein the step of authorizing

    said value transfer comprises the step of authorizing said value transfer for

    consumers not yet authenticated with said incentive system.
19. 19. The method as set forth in claim 18, further comprising the step of

    transferring said value into an inactive account pending authentication by said

    consumer.
20. 20. A method for implementing an incentive system, said method

    comprising the steps of:

    providing, at a merchant site, a means for a consumer to earn value,

    conferred by said merchant, through an earning activity;

    transferring, from said merchant to said clearinghouse, said value conferred

    in the form of a general private label currency; and

    providing, at said clearinghouse, a means for said consumer to redeem said

    private label currency value for goods and services.