EP1034502A1 - An on-line incentive system - Google Patents

Abstract

An on-line incentive system provides a means for a consumer to enter an earning activity to earn value from the merchant. If the consumer qualifies, value, in the form of private label currency, is transferred from the merchant to the consumer without re-directing the consumer away from the merchant's web site. The merchant requests authorization to a clearinghouse site to transfer value from the merchant to the consumer via a value transfer network. The request is dispatched, via the Internet, from the merchant site to the clearinghouse site. If the value transfer is unsuccessful, then the incentive management system enters asynchronous retransmission mode, wherein the value transfer is periodically initiated from the merchant location to the clearinghouse location. 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 the consumer that indicates the status of the authorization request.

Description

AN ON-LINE INCENTIVE SYSTEM

BACKGROUND OF THE INVENTION

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.

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 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

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 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

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. 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.

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

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 mmimizing 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

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

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

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

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 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

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

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

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

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 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

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

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

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

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 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

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

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

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.

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 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.

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.

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.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Private Label Currency System:

In a preferred embodiment, an incentive system involves interaction

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 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

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

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

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

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. 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

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

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

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

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 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

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 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

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

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 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

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, 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

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

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- 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

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

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

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

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 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

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

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

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

pending the capture and charge back phases of the transaction.

For the authorization phase, the incentive management system

executes fraud control procedures to ensure that the consumer is valid (e.g. , 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

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

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

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).

Earning Activity:

The "earning activity" for the incentive program may include any 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

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

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.

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

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. 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.

Remote Incentive Management Syste 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

"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

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).

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 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

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. 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

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

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 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

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

location. For the incentive management system shown in Figure 3, the merchant's web server 300 requires minimal software mnning 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

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

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, 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

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

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.

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

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. 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

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.

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

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

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 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

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

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.

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.

Value Transfer Network:

In one embodiment, the incentive management system implements 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

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

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

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

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 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

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

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

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

(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. Table 1

Merchant ID

Sequence #

Date Stamp

Promotion ID

Amount Awarded

Consumer's E-Mail Address

Authentication Token

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

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

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

field, provides some sort of authentication, originated by the consumer, to bind 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.

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

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

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

to the number of consumers. Accordingly, the key management problem is

reduced because the keys are securely maintained by only the merchants and

clearinghouse. 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.

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

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

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,

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 ma taining perimeter security. For these merchant locations, the http protocol may be used. If several protocols and ports are supported at the

merchant site, then ma taining a secure perimeter at the merchant site becomes

more difficult.

In one embodiment, if the remote incentive management system does

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

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

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

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 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

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

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.

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.

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, 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

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

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

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

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 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

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.

Table 2

Sequence #

Merchant ID

Time

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

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 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

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 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

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.

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 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

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

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.

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

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 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

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

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

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

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 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

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.

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

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

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 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

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

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,

through use of software rarming 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

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 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

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

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

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

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 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:

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

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.

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

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 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

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

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

consumer supplies, to fully activate an account: history of participation in a

merchant's earning activities, an identification (TD) 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

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 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.

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

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

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

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 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.

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

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

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

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 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

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

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

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).

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 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

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

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

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

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 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.

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

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

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

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 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

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

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

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

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 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

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

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

software that includes a plurality of computer executable instmctions 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

only memory (CD - ROM). In one hardware implementation, the incentive

system may comprise a dedicated processor including processor instmctions for

performing the functions described herein. Circuits may also be developed to 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 mnning on a server.

Although the present invention has been described in terms of

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

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. The method as set forth in claim 9, further comprising the step of

logging said value transfer transaction at said merchant location.

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. 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. 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. 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. 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. 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. 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. 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.