HK1133107A - A purchase-transaction-settled online consumer referral and reward service using real-time specific merchant sales information - Google Patents

Description

Online customer referral and reward service for settlement of purchase transactions using real-time merchant-specific sales information

Priority claims/related applications

U.S. provisional application Ser. No.60/788407 entitled "A Purchase-Transaction-selected one line Consu mer Referand redirected Service Using Real-Time Specific Merchant SalesInformation", filed 2006, 3/31, in accordance with 35 USCs 119(e) and 120, which is incorporated herein by reference in its entirety.

Appendix

Appendix A (page 15) is an example of a merchant Web site flow and merchant Web user interface for the online customer referral and reward service for settlement of purchase transactions, appendix A forming part of the specification. In particular, appendix A contains (1) a merchant web flow description; (2) a merchant site start page UI; (3) setting a guide step description for the new merchant; (4-5) merchant commission/reward setting UI; (6-9) a merchant offer publishing UI; (10) an enterprise profile setting UI; (11) a sales View UI; (12) the customer views the UI; (13) an account setting UI; (14) setting a UI for offline transaction tracking; and (15) merchant virtual terminal transaction tracking.

Appendix B (page 6) is an example of a customer web site flow and customer user interface for the online customer referral and reward service for settlement of the purchase transaction, appendix B forming part of the specification. In particular, appendix B contains (1) a client UI workflow diagram; (2) a client initiated web UI; (3) displaying a web UI of the web UI, and registering a client to search for quotations on the digital map on the displayed web UI; (4) a web UI displaying details of merchant offers; (5) allowing the customer to manually report the purchases he made to obtain a web UI of feedback; (6) a web UI of customer account settings is displayed.

Technical Field

The present invention relates to systems and methods for customer referral and reward for settlement of purchase transactions, and more particularly to computer-implemented systems and methods for customer referral and reward for settlement of purchase transactions. The present invention combines online customer destination strategies, syndication strategies, and viral marketing strategies into a card-based loyalty component that captures customer actions, thereby combining into a CPT (cost per transaction) advertising model.

Background

In an effort to expand the utility of market research and its advertising, businesses are currently focusing on media other than traditional media (i.e., print advertisements, TV, radio) and evaluating the ever-emerging interactive communication channels such as those provided by the internet, interactive cable television (e.g., Comcast local autopping), and the growing array of mobile devices (e.g., web-enabled cell phones, handheld computers, internet-connected GPS navigators in automobiles). In addition, many systems and enterprise models are designed to develop and utilize these channels, either as discrete advertising services, or as business targeting services, or a hybrid combination thereof. However, existing systems and methods have not been used to meet a set of key requirements common to both "online" and "local" businesses, especially in the Small and Medium Business (SMB) market. These key requirements suggest that many merchants are unable or unwilling to risk shifting their advertising costs to 1) unproven in generating measurable sales revenue directly in local brick and mortar outlets and service enterprises, 2) too complex to manage without specialized experienced marketers (as evidenced by "search keyword" optimization and bidding websites), and 3) online models that are prone to fraud or manipulation (as evidenced by so-called "pay-per-click" online advertising and existing merchant rating systems).

It would be desirable to address these key needs by 1) introducing a "transaction settlement," in particular, an offline in-store sales transaction settlement online advertising system that charges merchants only for advertisements that result in sales captured at or near the point of sale (POS), 2) eliminating the need for merchants to manage optimized online advertisements to drive online customers to the complexity of their place of business, and 3) by utilizing POS transactions as a control function, substantially eliminating the fraud and manipulation of currently popular click-through advertisements and merchant rating systems. Thus, it would be desirable to create a proprietary system of man-in-the-middle advertising that keeps the risk of sales results away from the merchant and separate the risk from online advertising publishers (such as Google or Yahoo). It would also be desirable to create a proprietary commission bidding system in which merchants raise customer loyalty reward points (recorded on magnetic cards swiped with each transaction) to attract more customers and thereby generate more revenue for the service provider.

Examination of the prior art shows that while many existing systems provide similar functional components such as advertising price bidding (typically applied to online clicks or other online user activities), directory services (charging listing fees or even directing customers to businesses free), membership loyalty cards for tracking and rewarding sales transactions, these systems are completely different from what is needed in terms of the combined functionality specifically designed and wholly addressed to meet the needs of local merchants (as described above).

There are many simplified merchant-customer interactions, but in key areas, including (but not limited to) 1) charging models (click-to-ad-fee versus sales commission fees, particularly with respect to offline in-store sales), 2) coverage of offline purchases including cash transactions, 3) easy and near real-time bid publishing using digital maps and web-based User Interfaces (UIs), 4) geographic proximity and time-based ad relevance targeting, different existing online shopping and customer referral services.

Online inventory search-local transaction and retrieval: one existing system provides customers with online access to product/service availability and related information, simplifying the direct processing of online orders that are subsequently retrieved at the local merchant's location. Although the system may be described as an online information conveyance system that simplifies offline commodity transactions and extraction, the system is severely limited in terms of affiliated merchants due to the need for highly integrated and centralized inventory tracking. The expense of requiring data processing integration, and the fact that the system does not support online advertising in exchange for commissions, makes it incompatible with the requirements of SMB merchants and significantly different from the systems required.

Online business-to-business (B2B) member referral: another existing system enables a single online merchant to obtain directed customers from other online sites in exchange for a fee. In this system, one merchant/member cooperates with many partner (online) merchants (usually complementary in service). Hyperlink systems are used to direct customers from affiliated web sites to merchants that can meet the needs, and point counting systems or cash-based systems are used to provide merchant incentives. Such systems are not used to facilitate self-serve advertising and special offers in near real-time by merchants to generate local traffic at fixed locations or locally in the enterprise. Instead, it is primarily used to establish a community of networked merchants that transact most of their business online and benefit when they direct customers to associated websites. The system is not used to reward customers with loyalty points or reward rewards for their purchases.

Online search: the distribution of search engine merchant sponsored (fee-based) advertising content, or engine indexed content (free to the merchant), directs customers to the merchant. In general, these systems can be divided into three different categories: 1) a general search (e.g., Google,http:// www.google.com2) Local search (e.g., Google Local,http:// local.google.comand 3) shopping searches (e.g., Google Froogle,http:// froogle.google.com). 1) Ordinary search: these sites typically provide an index of merchant advertising free web sites and generate revenue by placing paid advertisements in front of customers conducting searches. They do not focus on local merchandise promotions, and thus they do not provide an efficient system that enables merchants to post their own offers, and a means to track the resulting sales transactions originating from local customers. Conventional search engines charge advertisers on "clicks" or other online activity, and they do not provide a means to capture and track the resulting offline transactions. The complexity and cost of merchants to select optimal activities based on keywords, and bidding, also prevents the widespread use of search engines by local small merchants who lack the required skills and resources. 2) And (6) local searching. These websites provide proximity-based content retrieval and advertising. However, similar to common search engines, they do not use commission-based systems for online advertising where revenue is driven by offline transactions (especially offline transactions such as POS). 3) Shopping searches are similar in basic function to ordinary searches, except that these websites provide a process for transacting online sales. For merchants, advertising is still a pre-paid cost (up front cost) and as a result cannot be tracked to actual sales transactions occurring offline (as in local stores).

Online directory websiteIs comprised of online yellow pages (e.g., Verizon's)http://www.superpages.com) And local information aggregation websites (such as City search)http://www.citysearch.com) The existing category of (a). Some of them are online versions of the paper yellow pages book, and some are syndicated information sites related to local communities. These websites have two layers of merchant data (1) contact information, such as business names, addresses and contact information, and (2) more specific information, such as profiles, reviews and general merchandise promotion information, user reviews. They either generate their content free of charge to the merchant, or the merchant pays a listing fee or pays a fee per online activity for the website to advertise. These websites do not have the ability to match advertisements to actual sales results (effects) as compared to the desired systemA system of contacts. In addition, these websites do not have the ability for merchants to publish their own offers in addition to submitting contact information, thereby making it impossible to display advertisements in near real-time.

Online coupon websiteIs another category of prior art. By definition, a coupon is a cut on a particular product or service. At first glance, these websites (systems) look similar to the desired system. However, these systems are designed in such a way as to limit the nature of merchant offers to specific goods or services for which a high discount is typically offered as an incentive to member customers (which are sometimes charged a "club" or "membership fee" to participate in couponing). In contrast, the desired system does not limit advertising offers to specific items or services, nor does it require, or even encourage, local merchants to discount their products or services too much. Instead, the desired system uses a commission bidding engine to reward the customer for each common transaction with the member merchant's business and provides many other important benefits to the customer, such as a reliable merchant rating system. It is further noted that many coupon services require some type of dedicated bar code scanner at the point of sale to redeem the coupons and track the transaction. Some coupon websites (e.g.,http://Valpak.com) Is an online version of an offline B2C direct mailing service (e.g., ValPak), and only publishes offline coupons online. These websites lack real-time quote publishing capabilities. Nor do they have a commission-based charging structure. Instead, its revenue comes from the floor listing fees. Although some examples of online coupon sites are being tested with commission-based fee structures (i.e., Google press release, March 20, 2007), these sites suffer from the following drawbacks: 1) applicable only to online sales and not to offline commerce, 2) limiting offers to specific products where the primary sales incentive is a high discount.

Online classification service: these services are usually concentrated on a single customer who wants to sell a particular item (or service), such as craigslistOn a station basis, they require a pre-paid advertising fee (much like newspaper classified advertisements). There are hybrid models that provide advertisers with the added benefit of online advertising exposure offline (newspaper classified ads). None of this category of services provide POS tracking as part of a commission or revenue model. These services also do not provide customer feedback (i.e., loyalty points redeemable for cash). Furthermore, they do not enable merchants to increase their store traffic in a general (not item or service specific) way, such as a directory service.

In addition, overlap with desired system functionality occursCustomer reward/loyalty program. They fall into two categories: 1) open-loop or semi-open-loop transaction models, and 2) closed-loop transaction models. These terms indicate the ability of a client/member to redeem or otherwise use their accumulated points outside of the business company with which they transact business. Systems of this category include airline frequent traveler programs, retail store and gas station frequent traveler programs. One of the many differences in the required system compared to this category of prior art is the ability of the merchant to generate and direct the volume of customer traffic used by the system using real-time offer publishing, proximity and time based ad targeting, and commission based voting systems.

Online communityIs another prior art that shares certain properties with the desired system, but is quite different. In this model, an online community of customers (e.g., a blog site (e.g., MySpace,http://www.myspace.com) Or a user generated content website (e.g., YouTube,http://www.youtube.com) Individuals with the same idea may be supported in exchange for merchant reviews. While this is a key function of the system as an additional benefit to its customers (the difference is an added value to the design culture reliability and trust of the desired system, as it limits input to customers handling real purchases), these online communities are not used to convey proximity and time-constrained advertising to local merchants, nor do they provide advertisers with a charging model based on in-store sales commissions.

Thus, none of the known systems and methods provide a proprietary-based computerized system of transaction settlement-based (POS) advertising, commission bidding and broker orchestrated online advertising services that incorporates card-based loyalty components that capture customer actions, thereby incorporating 1) online customer destination strategies, 2) syndication strategies, 3) viral marketing strategies of the CPT (per-transaction cost, especially for offline transactions) advertising model.

Disclosure of Invention

An online customer referral and reward system and method for settling a purchase transaction using real-time merchant-specific sales information is provided. The system and method provide online services in which merchants and customers attract each other by issuing and looking up specific meaningful and useful sales offers about a product or service. The system and method allows merchants to publish and update specific sales offers online in real time, and to direct customers and track transactions, in a manner that works in concert with the merchant's existing business management and communication systems. The system provides risk-free customer referral services in which a service fee is charged after a purchase is made and each merchant is allowed to determine a service fee that may be based on the merchant's profit margin and market competitiveness.

The constituent functions of the system and method may include: (1)commission tracking and accounting system: the merchant pays a portion of the sales deal ("commission") to the service provider as a reward for communicating advertising-driven referrals, (2)Commission bidding system: merchants engage in competitive bidding with each other, raising the commission rate (from a certain minimum) to pay for a larger referral share in competitive market situations; (3) in real time and on demandMerchant quotation publishing system: a computer-based self-service system that cooperates with a variety of merchant business communication channels (including web, wireless, telephone, facsimile), facilitates merchant creation and submission of offers to (a) advertise particular products or services, or (b) convey non-item or service specific information that is used to facilitate augmentationShop traffic (in contrast to (a) pushing a particular sale of goods or services, such as a restaurant with a guest cook or musician, providing a special parking space, speeding up service response time. additionally, the published offer may contain a "frame" that is a number of constraints applicable to the offer, including time, place, target customer, etc. the merchant publication system generates near real-time automated web publishing by utilizing a commercially available digital map user interface (5)Online advertisement targeting system: it uses time, physical location and customer-provided input (from stored customer interest profiles, user queries or pre-requisites to the service provider) to determine advertisement relevance, which is then used to target advertisements to only interested customers; (6) based on a computerQuotation transmission system: post targeted merchant offers to consulting customers using a variety of personal communication channels including the internet, wireless, wired channels, telephone, fax and mail; (7)transaction tracking system: the system facilitates the capture and recordation of cash, credit card or stored value transaction card based purchases at or near the point of sale and point of sale; (8)customer reward/loyalty system: the system rewards the customer/buyer with a portion of the commission collected from the seller, and also helps to promote new customers and merchant members to reward customers.

The system and method provides a one-stop online space for customers who find sales offers that meet their needs, which direct those affected customers to make purchases to the issuing merchant using any existing means of purchase payment. The system also shares rewards with customers by rewarding those customers who report purchases as a result of using the referral service.

For service providers, the system and method provide techniques and means for merchants and customers to generate purchase agreements based on useful and meaningful sales offers and accommodate existing technologies and means used in merchant sales, customer purchases, and payment settlement. The system and method efficiently tracks purchase transactions resulting from the use of referral services without requiring technical integration between the service provider and the merchant and without requiring updates to the merchant's existing merchandising system.

The system and method provide an online marketplace that associates customers seeking specific products or services at specific times and locations with merchants offering the desired products or services at the specific times and locations. The system and method also generally tracks the purchase transactions that occur between the issuing merchant and the referring customer, regardless of whether the transaction is online (at a web store) or offline (at a brick-and-mortar retail store), or what payment means (cash, check, credit/debit card, etc.) is used. Each affiliated merchant decides a service fee to be paid to the service provider for each purchase transaction completed by the referral service, and the merchant is charged only after the transaction is completed. The present invention also shares the reward with the directed customer (i.e., for each transaction the customer makes for the referral service), and the customer receives the reward in the form of a monetary value.

Drawings

FIG. 1 illustrates an exemplary implementation of an architecture of a customer referral and feedback system;

FIG. 2 illustrates an example of a purchase transaction workflow when utilizing the system shown in FIG. 1;

FIG. 3 illustrates an example of a transaction report record for the system shown in FIG. 1;

FIG. 4 illustrates an example of a merchant database schema for the system shown in FIG. 1;

FIG. 5 illustrates an example of a customer database schema for the system shown in FIG. 1;

FIG. 6 illustrates an example of a transaction database schema for the system shown in FIG. 1;

FIG. 7 illustrates a service model of the system shown in FIG. 1;

FIG. 8 illustrates the Sinddar model of the system shown in FIG. 1.

Detailed Description

In an exemplary embodiment, the system and method of the present invention is described in the context of a web-based client/server architecture client referral and reward system. It will be appreciated, however, that the system and method of the present invention has greater utility because the system and method may be implemented in other ways with other architectures that are within the scope of the system.

In the following description, certain details are set forth in order to provide a thorough understanding of various embodiments of the systems and methods. However, it will be apparent to one skilled in the art that other embodiments may be practiced without the specific details. In other instances, well-known structures and methods associated with computer and communication systems, communication networks, and the like, have not been shown or described in detail to avoid unnecessarily obscuring the description of the invention and the embodiments.

In the following specification and claims, the terms "comprise" and variations thereof are to be understood in an open-ended sense, i.e., "including but not limited to," unless the context clearly requires otherwise.

Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, or all embodiments. Furthermore, the particular features may be combined in any suitable manner in one or more embodiments to yield yet further embodiments.

Headings are provided for convenience only and do not interpret the scope of the disclosure or claimed invention.

SUMMARY

The system and its constituent functions may include: (1)commission tracking and accounting system: the merchant pays a portion of the sales deal ("commission") to the service provider as a reward for communicating advertising-driven referrals, (2)Commission bidding system: merchants engage in competitive bidding with each other, raising the commission rate (starting from a certain minimum) to pay for a larger premium share for competitive market situations; (3) in real time and on demandMerchant quotation publishing system: a computer-based self-service system that works with a variety of merchant business communication channels (including web, wireless, telephone, fax), the system facilitates merchants creating and submitting offers to (a) advertise particular products or services, or (b) convey non-item or service specific information that facilitates increased store traffic (providing special parking spaces, faster service response times than pushing a particular sale of an item or service in (a), such as a restaurant with a guest cook or musician; additionally, published offers may contain "frames", the merchant publication system generates near real-time automated web publications by utilizing a commercially available digital map user interface; (5).Online advertisement targeting system: it uses time, physical location and customer-provided input (from stored customer interest profiles, user queries or pre-requisites to the service provider) to determine advertisement relevance, which is then used to target advertisements to only interested customers; (6) based on a computerQuotation transmission system: post targeted merchant offers to consulting customers using a variety of personal communication channels including the internet, wireless, wired channels, telephone, fax and mail; (7)transaction tracking system: the system facilitates the capture and recordation of cash, credit card or stored value transaction card based purchases at or near the point of sale and point of sale; (8)customer reward/loyalty system: the system compensates the customer/buyer with a portion of the commission collected from the vendor, and also helps to promote new customers andthe merchant member feeds back to the customer. These functions of the system are provided by the components and tasks described in more detail below with reference to FIG. 1. The service model of the system shown in fig. 1 is shown in fig. 7, while the syndication model of the system shown in fig. 1 is shown in fig. 8.

The system and method involve the following: a service provider, a plurality of merchants selling products/services, a plurality of customers purchasing products/services, and a plurality of payment processors (optional) that settle payment for purchases. Merchants affiliated with the system ("affiliated merchants") publish and update their specific sales offers to the service provider in real time. The customer looks up from the service provider for a particular sales offer that meets his needs at the desired time and place. The customer who accepts the merchant offer (the "directed customer") is then directed to the merchant to purchase the desired product or service. The service provider tracks purchase transactions between affiliated merchants and the referring customer. The service provider charges a service commission to the affiliate merchant that sells products/services based on the referral, for each settled purchase transaction resulting from the referral service, and rewards the directed customer for the purchase of the product/service through the referral service with a portion of the service commission.

Fig. 1 illustrates a component architecture of a customer referral and reward service system and method for transaction settlement. At the highest level, the system consists of three components: service provider component 101 and two remote components-merchant component 201 and customer component 401. Each of these components is briefly described below, and is subsequently described in more detail below.

In an exemplary embodiment, the components, units and modules shown in fig. 1 are implemented using software, where each module, component or module has a plurality of lines of computer code that, when executed by a processing unit, perform the functions and operations described below. In an example embodiment, the service provider component 101 (and its units and modules) are implemented as one or more server computers having one or more processing units, memory and connections, wherein the computer code of the elements of the service provider component 101 is executed by the processing units of the one or more server computers. In the exemplary embodiment, merchant component 201 is implemented as a computer system (located at the merchant location if the merchant supports such an interface) that executes computer code of merchant interface 203 to implement the merchant interface, although merchant component 201 could also be a telephone line or facsimile line that allows the merchant to interact with the service provider. Similarly, client component 401 may be a computer system that displays a user interface, such as by displaying the user interface using a typical browser application that executes lines of computer code (in the illustrative embodiment, HTML code) to implement client interface 403.

1. Service provider component 101

This is the main functional component of the system. The service provider uses this component to interact with the remote components 201 and 401 and achieve the objectives of the system.

2. Merchant component 201

This component is a remote component running at the merchant location that facilitates the required communication between each of the plurality of merchants 501 and the service provider component 101.

3. Client component 401

The component is a remote component that runs at the customer site, facilitating the required communication between each of the plurality of customers 502 and the service provider component 101. A customer is an individual who can purchase and pay for goods and services offered by a merchant. For a service provider, after registering with the system, the customer becomes a member customer. Once the system authenticates a member client, the client becomes a logged-on client. A logon client is a client that is capable of performing all of the supported client tasks described below in connection with the system.

Assembly structure

I. Service provider component 101

The service provider component contains three services: merchant service 111, customer service 171, and transaction service 151. Each of these services is described in more detail below.

1. Merchant service 111

This is the module in the service provider component 101 that is responsible for serving the merchant (represented by merchant 501) through the merchant component 201 used directly by the merchant 501. The merchant service communicates with remote merchant component 201 to accomplish the merchant service tasks described below.

A. Merchant task

i. Merchant registration task

The merchant is required to register with a registration module 121 that is part of the merchant front end 112 before the merchant can post its offers using the system. Through this registration process, the merchant provides time-invariant information to the service provider regarding the merchant and the business, including (but not limited to) the business name, location, contact, business description, and the like. Once registered, the merchant becomes a affiliated merchant and a merchant account and profile is created for it. After this one-time registration, the merchant authenticates himself to the service provider using his own credentials (such as a unique merchant ID and password).

Sales offer editing task

The affiliated merchant publishes or updates his specific location and time specific sales offers (via offer editing module 122 in the merchant front-end 112). He can publish or update his sales quotes at any time when needed. For example, a Seattle restaurant member may be able to edit the offer for a dinner that is ad hoc for the current evening afternoon. The offer may include a dish name, a description, an image, a particular price today, and a time at which the particular price dish was provided. The service provider runs an automatic approval process and approved quotes are published to the customer in real time.

Service commission specified task

The merchant is required to specify a service commission for each transaction via the commission specification module 123 of the merchant front end 112 before any sales offers can be posted to the customer. The service provider charges the affiliated merchant a designated commission for each purchase transaction that occurs from the directed customer to the merchant. Affiliate merchants can update (reassign) service commissions at any time. The service provider may publish a lower minimum for each merchant, or the lower minimum may be published based on merchant industry type, type of merchandise promotion, point of sale, or combinations thereof.

Commission bidding

In one embodiment, a commission bidding process can be utilized to determine a service commission. The bidding process allows the Service Provider (SP) to specify multiple minimum values for sales commissions. By default, every eligible sale from a member merchant will be charged a predefined minimum commission. The commission for each sale may be specified according to one or more of the following criteria: 1) a category of fees that can include at least a) a percentage of a commission based on the value of the transaction; or b) as a flat fee commission for each transaction, regardless of the actual transaction value; 2) a merchant location, which may have a location hierarchy, such as a) country ═ US; b) state ═ washington state; and c) city-Redmond, SP can specify a specific minimum commission for each location; 3) a business category of a merchant, which may have a category hierarchy, such as a level 1 car, a level 2 repair, and a level 3 body repair; 4) the time period, such that the SP can change the minimum commission at any given time, such as 1% weekday and 2% weekend, and there can be multiple time dimensions acting together, such as dimension 1: sunday, vitamin 2: part of a workday, etc.; and 5) the type of sale or buyer (target commission), where the SP support merchant selects different target commissions, such as regular sales commissions that support the same commission for each sale, and new buyer commissions that pay a higher commission to the SP for each new customer.

The system permits each Service Provider (SP) to allow and encourage local merchants to raise their commission above a prescribed and applied minimum commission value to obtain preferential customer referrals. A portion of these commissions may also be shared with the customer as a loyalty award for the service by crediting the customer's loyalty card. For example, assume that there are two chinese restaurants a and B adjacent to each other, providing the same kind and quality of food, and serving the same quality. Further assume that Chinese restaurants A and B indicate to the SP that they will pay 2% and 1% commissions for each sale originating from the promoted customer, respectively. When a nearby client searches for "special lunch in Chinese restaurant" (assuming that special lunch for Chinese restaurants A and B are similar), since the SP expects a higher commission from Chinese restaurant A, the SP chooses to recommend Chinese restaurant A to the searching client more strongly than what is offered to Chinese restaurant B (e.g., higher rank in display order, or more times an ad shows impressions). One of the ways this preferential referral is to show the Chinese restaurant A's offer more prominently on a digital map based user interface. If the searching user is using a text search, the SP can rank Chinese restaurant A before Chinese restaurant B on the returned results list. This service allows merchants to update their commission to SPs at any time with any supported publishing method (i.e., web interface or call center). The service also provides commission optimization support, where SPs can provide business intelligence that reflects current market competition and customer behavior to continually assist member merchants in optimizing (selecting the best commission structure and commission value) to maximize sales. The material provided to the merchant should be aggregated and include only anonymous information that protects the privacy of the customer. For example, the SP may suggest that merchants increase their commission to market average to increase sales.

Performance and Business Intelligence (BI) reporting tasks

The service provider (using the reports in the merchant front-end 112 and the BI module 124) provides two levels of reporting to affiliated merchants: performance reports and BI reports. Performance reporting is a standard level reporting service to affiliated merchants that focuses on the performance of issued sales offers (such as the number of transactions originating from directed customers).

BI reports are high-level reports that include market intelligence about competitors, customers, and sales. For example, BI reports provide each affiliated merchant with a measure of the effectiveness of each offer relative to other offers originating from the same merchant. The report also evaluates the effectiveness of the merchant's designated commission against competitors of merchants in the same marketplace, helping affiliated merchants adjust service commissions, if needed.

v. accounting tasks

This task (implemented using the billing module 125 in the merchant front end 112) enables the service provider to bill affiliated merchants for successful purchase transactions originating from the referring customer. This task is performed once the service provider confirms a successful transaction completed between the affiliated merchant and the referred customer, in order to charge the affiliated merchant that generated the sale a pre-specified commission on the service.

B. Business service function module

As shown in FIG. 1, merchant service 111 is comprised of three functional modules that work together to accomplish the merchant service tasks mentioned above. These modules are a merchant front end 112, a merchant management module 113 and a merchant data module 114.

i. Merchant front-end module 112

This is the module by which the merchant interacts with the merchant services of the service provider to accomplish the merchant tasks mentioned above. It contains one functional unit for each merchant task, i.e.,

a. registration unit 121

This element allows merchants to register themselves with the system and become merchant members (aka affiliated merchants). The registration unit may be implemented in software and may perform a registration step that includes creating a merchant account with the owner credential. This unit also allows affiliated merchants to create multiple business partners and assign credentials to them. In this registration, the merchant sign-up also specifies transaction tracking options such as credit card terminal tracking, service provider's own virtual terminal tracking, manual tracking, and the like. In this process, an accounting program is established so that the service provider can properly charge and withdraw the funds for the commission obtained.

The registration process also includes an initialization step in which the registered merchant creates a business profile, initially sets commissions and customer return plans. During this registration process, the new merchant may also choose to create and publish any special offers, as well as to create and publish a complete inventory of goods (named as regular offers in the system).

The registration element works with all supported merchant interfaces 203, including via the internet on desktop computers and mobile devices. In addition to the exemplary software implementation described above, the merchant may use other business communication means (such as telephone fax, or mail) to facilitate registration, wherein the actual registration is accomplished by the service provider on behalf of the subscribing merchant in near real-time, such as over the telephone, or offline or near real-time, such as when a paper form filled out by the merchant is received via fax or mail. Thus, the merchant selects the easiest way defined by the merchant interface 203 that the merchant can use to register with the service provider so that merchants with different interfaces, including online merchants and offline merchants, can use the system.

b. Quotation editing unit 122

This element may be implemented as a component of the system software, allowing merchants to create, update, and publish their offers in a self-service mode. The quote may be a static business profile, semi-static general merchandise information, and dynamic (time-varying, or valid only for a specified time) special quote. Offer editing software may be implemented in a variety of formats to accommodate supported merchant interfaces 203, including web and mobile publishing. Alternatively, offer editing software may be implemented in a live (live) assistance mode, such as when a service provider assists a merchant by telephone calling through a call center when the merchant completes the issuance of an offer or a constraint associated therewith using merchant interface 203. With this assisted model of merchant self-service distribution, the initiating merchant is not required to access the internet, thereby enabling offline merchants (entity retail businesses without any web or internet) to still benefit by utilizing their system.

c. Commission specifying unit 123

This is an element of the system that allows merchants to specify and update their commission offers (within a specified set of constraints) at any time for each subsequent qualifying transaction generated by a service provider member customer. Like other system elements described thus far, the commission specification software can support a variety of merchant interfaces 203, such as through the internet or through a mobile device.

In addition to operating in a merchant self-service mode and being implemented as a software-based service, the system elements may also operate in a service provider assisted mode, wherein the service provider creates or updates a commission on behalf of an originating merchant. For example, as an alternative to using the service provider software, the merchant may simply contact the service provider call center using his telephone (or fax machine) and verbally update his commission offers (which are entered into the service provider database as changes to his account).

d. Report and BI unit 24

This is the element in the system that generates business reports for member merchants, data mines all recorded data, and makes recommendations to merchants on how to improve their sales based on automated analysis of the saved data. This element covers merchant sales transaction bookkeeping and optimization.

The basic report may cover the deals and associated promotional offer activities, specifying or suggesting causal relationships to them (which may be based on statistical methods and/or time-based associations). The basic reports cover merchant sales, commission charges, customer feedback, price generation/updating and timing-based relationships between the above. By further mining the historical data of the records, advanced reports/intelligence can be generated. Based on this analysis (intelligence), the service provider can make sales optimization recommendations to the merchant. For example, the provider may suggest that merchants increase their commission offers to drive higher customer traffic as a means of keeping off competitors. Both basic (standard) reports and BI (advanced reports) may be provided with or without charge.

e. Accounting unit

This is the system element responsible for calculating, charging and collecting commissions from member merchants. It may include real-time charging (trade time charging) and delayed/bulk charging (e.g., repeated monthly billing). In a real-time charging scenario, the system charges the appropriate fee directly when a qualifying transaction occurs. In the offline charging scenario, the system records the commission due by the selling merchant and charges the merchant periodically.

For each member merchant, this capability of the accounting unit is dependent on the third party payment processor used by the merchant. The accounting unit 125 is implemented to work with the various payment processors 504. In actual billing, it may work with, without limitation, a credit card processor, a debit card processor, a prepaid card processor, an electronic check processor, a third party member processor, a networked point of sale (POS) system, and the like. In offline accounting, it may work with (without limitation) cash, paper checks, non-networked POS systems, and the like.

Merchant data module 114

This module contains a persistent database that holds data for merchant services. In particular, the sub-module contains a collection of data sets for serving merchants. The stored data is managed by merchant management submodule 113 and meets the data requirements of the system elements in the merchant front end 112 submodule. An example of an exemplary merchant database schema is shown in FIG. 4. The member database of the merchant data module may include:

a. profile database 141

The database maintains merchant data obtained through the registration process that does not change over time. More specifically, this is a holding merchantData sets of account and profile information including, but not limited to, owner accounts and credentials, partner accounts and credentials. The enterprise profile data contains a description of the enterprise that changes infrequently, such as the name of the enterprise, location, logo, hours of operation, contact information, and so forth. The data set also maintains transaction tracking and billing configurations set by the merchant. The data set may also hold merchant ratings and/or merchant "recommendations". These may be posted by customers who have completed a valid sales transaction with a particular merchant (to minimize false or fraudulent rating entries). The merchant rating (or "recommendation") may be at the service provider website, or at an established third party social network, such ashttp://www.myspace.comIn a number of ways among the clients.

b. Editing a quote database

The database holds all sales offers compiled by affiliated merchants. The merchant also writes to the database when updating its offer. The data set holds descriptions and states of at least two offers: conventional quotes and special quotes. Conventional quotes are data items describing less varying, if any, product or service items that are priced less varying. For example, the collection of regular items may be a menu, retail catalog, and the like for the food and beverage service industry.

The edit offer data set may also contain special offers that are short-term offers of the merchant with limited validity time. The temporary reduction of milk price the day before the store closes is an example of a special offer.

It should be noted that the offers may or may not be dependent on pricing or pricing changes (discounts, etc.). A quote may be any message that attracts the customer to a location of the business. It may contain general non-item or discount-related information (e.g., free hot dogs) that merchants use to increase customer flow. Another example of a general promotion is a restaurant owner issuing a free parking or special seat cook offer.

c. Commission database 143

The database holds service commissions specified by affiliated merchants. The data set contains a collection of commission designations compiled by the member merchants. The commission specifies the amount of money to be charged by the service provider to the sales member merchant, which may be a percentage of the eligible sales transactions or a fixed value for each transaction. It also includes a set of transaction limit criteria such as time period, target sales, target buyer, etc. One example may be a commission of 1% per sales transaction, and another example may be a commission of $ 5.00 per transaction-it may also be limited in time to a certain period of time, such as only applicable to transactions that occur between specified calendar dates. Other embodiments of commission designation may exist so long as the service provider obtains payment as a result of bringing sales to the sales merchant.

In general, the service provider may require a minimum commission value specified for each commission. For example, the provider may require a minimum commission of no less than 1% or $ 5.00 for the larger. The system allows merchants to raise their commission designations in order to obtain preferential customer referrals. Essentially, when merchant a represents a higher commission to the provider, and assuming all other conditions are the same, the provider will recommend merchant a more strongly to the customer than merchant B.

d. Performance database 144

The merchant service continuously tracks the performance of various aspects of the issued quote and saves the performance data in the database. The data set contains merchant business performance data including (but not limited to) the following: transaction records (from transaction processing data 161), buyer data, quote delivery data sales events and causality of quote events (along time and other dimensions). It may contain derived higher level BI data and conclusions in addition to the original recording.

e. Billing database 145

This is a database that holds billing related data for each affiliated merchant.

Merchant administration module 113

This is the central functional module of the merchant service 111 in which all the required logic and processing is implemented to accomplish the merchant's tasks. The module obtains merchant input from the merchant front-end module and sends merchant-restricted information to the merchant front-end module. In addition, this module reads the unchanged merchant data from the database in the merchant data module 114 and writes the unchanged merchant data to the database in the merchant data module 114.

This submodule controls the workflow of tasks performed by different elements in the merchant's front-end when needed. It also centrally manages data manipulation for data security and privacy of the merchant services 111 module. Another function of this submodule is to communicate with peer management submodules, transaction management module 159 and customer management module 173, among other modules of service provider component 101, to effect data transfer and task synchronization when needed.

One simple verification example that proves the flow control of this sub-module is to prohibit non-registered users attempting to use the merchant interface from performing merchant-member specific tasks such as offer editing 122, offer specification 123, report & BI 124, and billing 125.

The service provider administrator also uses this sub-module to centrally manage merchant services 111. Additionally, a merchant support team of the service provider works through the management submodule to assist the merchant and to perform tasks related to the merchant in a provider-assisted mode.

Various examples of merchant flows and merchant user interfaces for the services described above and below are provided in appendix A, which forms a part of this specification.

2. Customer service 171

Customer service helps customers find a desired offer and directs the customer to purchase services/products from affiliated merchants making the offer. It also rewards the customer based on the purchase transactions completed by the customer. The customer service performs three tasks related to the customer, namely registration, referral and feedback. The service provider serves the customer (denoted customer 502) by means of the module through a customer component 401 running on the customer side.

A. Client tasks

i. Customer registration tasks

Customers willing to get feedback register themselves with the registration module 181 as part of the customer front end 172. By performing this task, the service provider creates a secure account for each registered customer. Once registered, the customer authenticates himself to the service provider using his account credentials. The registered customers are eligible for feedback from the service provider. During registration, the customer may have the option of requesting the service provider to directly forward the reward to his/her designated third party deposit account (e.g., a bank account), authorize a charity, or some other legitimate donation that may even include a participation right to purchase service provider traffic. Typically, the customer will choose (system default) to return it as a discount for future purchases from the in-network affiliate merchant.

ii. client referral task

This task (implemented using the referral module 182 in the client front-end 172) accepts and processes client input describing the demand (or item search request), including the product or service category of the demand, time and place constraints, and the like. The task then searches the published quotes and returns the best matching quote to the customer. The service provider then provides a number of methods (via the user interface) to direct the customer to the merchant's physical location, or in the case of the service provider (i.e., the water pipe service), the system can direct the merchant to the customer's location.

Client feedback task

Once the service provider confirms (confirms) that a valid sales transaction has occurred between the affiliated merchant and the directed customer, a customer reward task is performed to reward the customer for making purchases in monetary value.

B. Client function module

The customer service consists of four functional modules: customer front end 172, customer management module 173, merchant data module 174, and customer data module 175.

i. Client front-end module 172

This is the module that the customer service uses to interact with the customer. It contains three functional units, each serving one of the customer service tasks mentioned above.

a. Registration unit 181

This is the front-end component with which the customer interacts to register its unique identification and account information. This function also fixes the unique identification number on the customer's membership card to the customer's account and is used to track the source of the customer's card so that the service can track the source directing the customer into the network (a key part of the reward return system that promotes merchant and customer counseling). An example of a data flow in such a process is: account creation, membership creation, reward distribution settings, and membership exchange.

In this implementation, the new user first creates a customer account. He may then add one or more personal members to the account. Members share the account but are assigned different member IDs. Since they are in the same account, they can collectively aggregate their feedback together. At this step, the customer can set up their ID alias, such as using their phone number or email address as an alias for the formal membership ID. The next step is to let the service provider know the way to distribute feedback for the account. The service provider has a variety of ways to support the distribution of the reward, including (but not from) using the reward for the next purchase. There may also be various sub-options, such as: a. closed loop transaction restrictions, i.e., reward is used as a future discount only at merchants who issue the reward; b. open loop transactions, i.e., where the merchant also uses the reward as a future discount within other networks, distributes the reward in cash, distributes the reward in direct deposit to a designated financial institution, and sends the reward to a third party, such as an authorized charity, a designated savings account, a lottery pool, investments (including but not limited to equity purchases at a service provider, etc.).

The last step in this implementation is the home exchange. By doing this, the membership of the member customer is linked with membership (e.g., credit card, grocery card, etc.) in the network of other customers. When a qualified purchase is made, the registered credit card or grocery card may be identified and used as a proof of membership.

b. Pushing unit 182

This is the front-end component with which the customer interacts to track and verify the identity of the person (customer or merchant member) that directs them to join the system. This component uses the customer request from the merchant data (e.g., via customer interface 403), the customer profile data set stored in customer data module 175 to find matching merchants and offers, and passes the resulting information to the customer. If the customer is interested in the offer, he may go to the merchant's physical location to make the purchase.

The merchant data used by the referral unit 182 includes profile data, feedback levels (feedback that is part of a specified commission), offers (regular and special), and other merchant demographic and shopping behavior data.

The customer need (demand) data obtained by the system may include: item descriptions (expressed as keywords or concepts), location proximity (manually entered or detected on a computing device running the customer interface 403), when (indicating a time constraint when the item is needed), (price interval of a product or service search), (reviews/ratings of vendors and/or offered products/services), and so forth. The user may be allowed to customize or set preferences of the user interface to accommodate the manner in which the user prefers to enter data (i.e., default field values may be set, input tables rearranged, etc.).

Customer needs may be given or captured. The demand submitted by a customer to a service provider is considered "given"; while the demand detected by the service provider is considered "captured".

Various Data Mining (DM) and Information Retrieval (IR) algorithms may be applied to rank offers and merchants according to specified requirements. In this system, one factor that this algorithm takes into account is the commission designation of the merchant. The service provider promotes traffic more strongly (or displays advertisements of merchants more frequently or more prominently) than merchant offers that provide a lower commission for similar items or services.

The referral unit 182 may support both "soft referrals" and "hard referrals". When a sales transaction is completed between a member merchant and a member customer, the soft referral is considered successful and effective regardless of whether the transaction is a direct result of the specifically advertised item or service. Instead, hard referrals ask the merchant for proof of a particular offer before a transaction can be made. The merchant may determine which referral means to use; this information may be published to the customer.

c. Feedback unit 184

This is about the front-end component of the interaction of the reward task with the client. The component is also responsible for electronically transmitting or handing off customer returns with a customer-specified return deposit 505 (e.g., a bank account). In particular, the system component executes a customer reward program based on each customer's eligible purchases. In one implementation, the provider specifies a fixed ratio between the reward and the commission. That is, the provider always returns a portion of the commission obtained from the affiliate vendor to the affiliate customer making the purchase. For the sake of illustration, we assume in this application that this ratio is 1/3. In this implementation, the feedback step is performed as follows:

1. the member customer makes a qualified purchase with the member merchant.

2. The service provider receives a commission to the vendor on a pre-specified standard or scale.

3. The seller pays a commission.

4. The service provider transfers 1/3 the commission obtained to the customer making the purchase as a reward for the purchase he generated in step 1.

The reward unit 184 also distributes the reward obtained by the customer to a designated reward repository 505, as specified in the customer registration element 181.

Merchant data module 174

The merchant data module in the customer service holds data originating from the merchant's issued offers 191, which is used to answer the customer request, resulting in an referral to a qualified merchant. The module may also contain a cache of merchant data used by customer-related tasks. An example of a database schema for a customer database is shown in fig. 5. This module contains a published offer database 191, which is a physical or logical copy of the edit offer database 142 in the merchant data module 114 of the merchant service 111. It contains the price quotes that are available to the customer as confirmed by the service provider.

Client data module 175

This is another data sub-module under customer service 171 that contains customer profile and behavior data. It may also store invariant customer data, including two logical databases: customer database 192 and feedback database 193.

a. Customer database 192

The database contains information about registered customers including profiles, account credentials, feedback storage designations, etc. It may also contain behavioral data over time, as well as derived business intelligence data and findings.

b. Feedback database 193

The database contains a history of rewards from registered customers who received the rewards from the service provider. The data set contains feedback records in place of the transaction data stored in the transaction 162 data set. The data set provides the basis for customer feedback.

Customer management module 173

This module is a central management module of the customer service 171 in which all the customer related logic and algorithms are implemented. It communicates with the client front-end module to obtain data from and send data to the client. It also centrally manages data manipulation in terms of data security and privacy for its overlying customer service 151 module, reading and writing to the merchant data module 174 and customer data module 175. The customer management module also communicates with other member services of the system in the service provider component 101, namely the merchant management module 113 and the transaction management module 173, to enable data transfer and task synchronization when needed. For example, this module interfaces with merchant management module 113 in merchant service 111 to synchronize published offers database 191 with compiled offers database 142 and to pass information from customer data module 175 to the merchant service for merchant reporting and billing. The customer management module also has a direct connection with the transaction management module 159 of the transaction service 151 for transaction/customer related data exchange.

The service provider administrator also centrally manages customer services 171 using this sub-module. In addition, a customer support team of the service provider works through the management submodule to assist the customer and to perform tasks related to the customer in a provider-assisted mode.

Numerous examples of customer flows and customer user interfaces for the services described above and below are provided in appendix B, which forms a part of this description.

3. Transaction service 151

In a preferred embodiment of the present invention, the service provider does not control or own the actual purchase transaction; the system module under the service provider component 101 handles purchase transactions between merchants and customers. The seller and purchasing user can complete the purchase transaction at any location (online or offline) by any means of payment (cash, check, credit card, debit card, etc.). However, the system tracks, validates and records those qualifying transactions that occur between affiliated merchants and registered customers so that the service provider can correctly charge the merchant a commission and pass a portion of the commission as a reward to the purchasing customer. The transaction service consists of the following tasks to track, validate and record qualified transactions:

A. transaction tasks

i. Transaction integration tasks

This task (implemented with the integration module 153 as part of the transaction front-end module 152) integrates transaction tracking with electronic payment settlement means through a plurality of payment processors 504. The payment processor may be owned by the merchant, or owned by a third party payment clearing house, or an online or mobile payment service provider. Agreement is obtained with the affiliated merchant, and the service provider performs transaction integration tasks to integrate the transaction service with any/all of the electronic payment processors used by the merchant. Once integrated, the service provider immediately tracks transactions occurring that are settled by the integrated settlers.

Note that the system also tracks transactions through payment systems that are not integrated with the service provider. The integrated tracking captures transactions in real time as they occur, while in the case of non-integrated tracking, the purchasing consumer may report the transactions that occurred after they occurred.

Transaction tracking tasks

This task, which is accomplished using the tracking module 154 of the transaction front-end module 152, tracks the purchase transactions that occur between affiliated merchants and the referring customer. When the payment processor is integrated with the transaction service, the processor automatically passes information of the eligible transactions to the transaction service. For example, assume that the task is combined with a credit card payment clearing house. In this case, the service provider immediately tracks all transactions as they are settled by the clearing house.

The task also tracks those purchase transactions whose payment means is not an electronic payment means, or is not integrated with the service provider. The system facilitates a customer-initiated tracking method in which a purchasing customer (or vendor on behalf of the customer) reports to a service provider that a transaction has occurred after payment has been settled.

By supporting combined transaction tracking and manual transaction tracking, the system is able to provide its services to all merchants and customers regardless of the specific payment settlement means.

Transaction confirmation task

Once the purchase transaction is reported by the transaction tracking task, the purchase transaction is forwarded to a transaction confirmation task (implemented using a confirmation module 155 in the transaction front end 152) to confirm the transaction. This task is essential in order to minimize fraudulent transaction reports. In this task, the service provider of the system tests the authenticity of the tracked transaction based on the reported transaction information.

Transaction record task

This task (implemented using the logging module 156 in the transaction front end 152) receives information for the confirmed transaction from the transaction confirmation task and logs information about the transaction in a permanent transaction database. After the service provider records the transaction, the service provider bills the vendor for the service fee and rewards the purchasing customer in monetary amounts.

B. Transaction function module

The transaction service component consists of those modules that perform the transaction tasks described above: a transaction front-end module 152, a transaction management module 159, and a transaction data module 161.

i. Transaction front end module 152

The module interacts with the merchant, customer and payment processor to track transactions. This is a system submodule, comprising a set of system elements, which communicates with the merchant component 201, the customer component 401 and the payment processor 504 in order to track, confirm and record sales transactions. It comprises functional units for the respective transaction tasks:

a. combining unit 153

This unit is integrated with the payment processor 504 to enable automated transaction reporting and contains a plurality of software modules, each of which cooperates with a different payment processor 504 to track qualifying transactions conducted through the payment processor 504. For example, the binding element may cooperate with third party credit card terminals, the provider's own tracking terminal, and manual cash transactions and track transactions occurring thereon. A plurality of software may be embedded in the payment processor hardware. This element ensures that the payment processor in use is properly cooperating with the tracking element 154.

b. Tracking unit 154

This unit cooperates with the payment processor 504 to enable automatic transaction tracking or cooperates with the customer through the customer interface 403 and cooperates with the merchant through the merchant interface 203 to enable manual transaction/sales tracking. It has three categories of implementations: direct tracking from the merchant via the merchant interface 203, indirect tracking from a third party payment processor 504, and direct tracking from the customer interface 403.

The merchant may track the sales transaction using the provider-supplied merchant interface 203. In this case, the tracking element 154 receives verified transaction data directly from the merchant interface 203.

The tracking element 154 may also cooperate with a plurality of third party payment processors. In this case, after the payment processor is combined with the combination element 153, it receives transaction data from the supported payment processor 504. The tracking element pumps data through the validation element 155. The tracking element cooperates with a plurality of payment processors 504 via a combination unit 153.

The tracking element 154 may also cooperate with the customer interface 403 to enable transaction tracking. An example will be referred to later in this section.

The tracking software supports two types of transaction tracking, real-time or offline. In real-time tracking, software running on the payment processor 504 transmits the necessary data to the tracking element 154 as the transaction occurs. All subsequent options (confirmation 155, logging 156) also occur in real time. The net effect is that when a transaction occurs, the transaction is tracked, confirmed and recorded. Real-time transaction tracking requires software integration.

Another type of trace 154 is an offline trace, which may or may not require software integration. For example, in the case of a cash transaction between a vendor and a purchasing user, the service provider may implement a set of user interfaces in the customer interface 403 to work on the Internet or mobile device so that after the transaction occurs, the buyer can report the occurring transaction to the provider via web page, email, or short message on the mobile device.

c. Confirmation unit 155

The unit tests the authenticity of the tracked transaction by making the necessary confirmation against the transaction data based on the reported transaction data forwarded from the tracking unit to minimize possible fraud. It cross-checks the received data against known and trusted stored data.

As a possible embodiment, a confirmation algorithm for manual transactions is illustrated below.

1. The provider issues to the merchant a set of stickers, each printed with a unique label number and having an expiration date.

2. When a merchant makes a sale to a member customer, he gives such a sticker to the buyer.

3. The buyer customer later logs into the system on the customer interface 403 and, using the obtained tag number, and possibly the name of the vendor and the approximate date and time of purchase, fills out a form online reporting the purchase.

4. The customer interface 403 communicates the reported transaction data (from the buyer) to the tracking element 154.

5. The tracking element 154 passes the data to the validation unit 155.

6. The validation unit 155 cross-checks the received data (tag number, selected merchant and approximate time of purchase) against a transaction data set containing the original record of the tag number, issuer, and expiration date of the tag number.

7. When any cross-checks fail, the validation unit 155 will invalidate the reported transaction.

Note that in this embodiment, the merchant can only specify a commission with a fixed monetary value, since the transaction price is neither reported nor confirmed.

When the transaction data originates from the third party payment processor 504, the payment processing software passes on the necessary identification/credential data (e.g., processor device ID, partner/owner account used when processing the transaction, customer membership, etc.) to the validation unit 155. Where the sales price can be tracked and verified, the merchant can specify a commission as a percentage of the sales price.

d. Recording unit 156

The unit records the confirmed transactions in the reward database 13 to enable merchant billing and customer reward. In particular, the component writes the transaction record into the transaction data set 162, along with other necessary environmental values, such as time of recording, etc., as reported by the validation result.

Transaction data module 161

This is the data submodule under the transaction service 151 that stores data related to transactions in the following databases:

a. transaction database 162

The saved transaction records are used by merchant service 111 and customer service 171. An example of a transaction database schema is shown in fig. 6. The merchant service uses the transaction records for merchant reporting and billing, and the customer service uses these records to feed back to the referring customer. In particular, the data comprises transaction records received from the tracking unit 154 and processed by the validation unit 155 and the logging unit 156.

Transaction management module 159

This module is the central management module that implements all transaction processing logic and processes. The management module manages and communicates with the front-end module to receive, validate and record transaction information. It also centrally manages data manipulation for the transaction service module 151 in terms of data security and privacy, reading and writing transaction data modules to access transaction records. Another function of this submodule is to communicate with the same type of management submodule in the other modules of the service provider component 101, namely, the merchant management module 113 and the customer management module 173, to effect data transfer and task synchronization when needed.

The service provider administrator also centrally manages the transaction service 111 using this sub-module.

Merchant component 201

The merchant component is a remote component that runs on the merchant side and acts as an interaction bridge between the merchant 501 and the service provider. It consists of a merchant interface module 203. A merchant is defined herein as an owner of a business, or a business partner of the owner. After logging in, the business owner can perform all tasks supported in the merchant service 111. After proving themselves to the merchant service 111, the business partners can only perform transaction tracking. For the service provider, after registration, the merchant becomes a member merchant. Once the system has verified a member merchant, the merchant is considered to be logged in. The registered merchant is the merchant that is able to perform all of the supported merchant tasks.

1. Merchant interface module 203

The module interacts directly with the merchant and the merchant's business system. It also communicates with the merchant front end 112 to complete merchant tasks.

The merchant may use one or more implementations of the module consistent with him and/or his business management system. The module implementation may be a tangible implementation installed on the merchant terminal computer (e.g., a Web UI) or may be an intangible implementation that is kept in mind by the merchant (such as a telephone number of a service provider). Another implementation of such a merchant interface may be a merchant-side program that cooperates with a merchant's computerized business management system and communicates with the service provider.

The component also provides for programmable and manual implementations to cooperate with the tracking unit 154 to enable merchants to manually report transactions.

This element contains a plurality of user interfaces for merchants to interact with merchant services 111. This is a user interface that cooperates with the merchant front end 112 to perform merchant registration, offer editing, commission designation, reporting sales, reporting and billing.

This element is used by the merchant 501 and communicates with the merchant service 111 over the existing traffic communication channel used by the merchant 501. The elements may be implemented as software or provided in the form of hardware.

For businesses that use the internet for business communications, this element may be implemented as a set of web pages or a web site. For merchants that do not have commercial (or personal use) internet access, in this element, telephones and fax machines may be used as the merchant interface.

Client component 401

The client component is a remote component that runs on the client side, simplifying communications between the client 502 and the service provider. It consists of a client interface module.

1. A customer interface module 403.

This module interacts directly with the customer and communicates with a customer front end 172 located on the service provider side to accomplish the customer tasks of the system. The module has a variety of implementations of different communication technologies suitable for use by the customer, ranging from those that are tangible implementations, software installed on the customer's computer/device (such as Web UIs, mobile UIs), or hardware issued to the customer with the necessary software embedded (e.g., dedicated devices), to intangible implementations (e.g., telephone numbers of calling service providers). The customer selects the implementation or implementations of the module that are most appropriate for them. The customer also uses the interface to interact with the transaction tracking unit 154 to report transactions themselves.

More specifically, this element contains a plurality of user interfaces for individual customers to interact with customer service 171. This is a user interface that cooperates with the customer front end 172 to perform tasks such as customer registration, referrals (finding desired products/services), reporting purchases, and getting reward for eligible purchases. The multiple user interfaces of this element may be used with a variety of personal communication channels through which customers can contact the service provider. These channels include, but are not limited to, the internet, wireless networks, and telephone networks.

Mobile advertising, cable television advertising and map display

The service and system may generate mobile advertisements, cable television advertisements, and map displays with advertisements that are displayed to the customers of the system and presented to the customers on offer. Mobile advertisements may appear on mobile devices via the web (a commercial example of which is located on a mobile device)http://air2web.com). One commercial example of a cable advertisement is the Comcast classifications ON DEMAND, where cable viewers use their remote controls to view local car listings at the Comcast's ON DEMAND service. The service described above may use mobile and cable television advertisements provided by third parties as ad delivery channels for customers to receive merchant offers.

The service may also present offers to customers using a digital map display with advertisements. Many commercial digital map service providers (notably, Microsoft Virtual Earth)http:// local.live.comAnd Google Earthhttp://local.google.com) Allowing merchants to post their information on a map. In these typical systems, the merchant information displayed on the map remains at the contact information level, although some map providers allow for links from the map to the merchant's web site. The above-mentioned services can use these with service advertisementsMap display systems are known. In one embodiment of the system, the service provider may host a map application, overlaying the quote data on the map using a map API (self-hosting mode). In another embodiment, the provider may pass the offer to a digital map owned by a third party (e.g., Google's own map website) and have the third party present the offer to the customer (sindick mode). In this service, map advertisements can be displayed in view of local shopping-specific searches (the service supports more and specific parameters such as time periods and price intervals), and the map advertisements support the presentation of real-time specific offers on the map (see UI screenshots in appendix B).

Purchase 503

As shown in fig. 1, the system/service allows a purchase transaction 503 to occur between a merchant 501 and a customer 502. A purchase is an action that occurs between a merchant and a customer that involves (1) transferring ownership of a product from the merchant to the purchasing customer, or generating a lease of the product from the merchant to the purchasing customer, or servicing the purchasing customer by the merchant, and (2) the purchasing customer paying in exchange for ownership or lease of the product, or the monetary value of the service provided by the merchant. The entire process is called a trade, and the monetary value of the return is called a deal price, a sale price (from the perspective of the seller), or a purchase price (from the perspective of the purchasing customer). The purchase action may be settled and recorded by the payment processor 504.

Payment processor 504

For purposes of this application, a payment processor is a tracking device or method that tracks the occurrence of qualified transactions (i.e., transactions that occur between member merchants and member customers). It may be implemented as software, hardware, or a combination of software and hardware by a service provider or a third party.

The present application may support a variety of payment processors, including those operating in credit card terminals, payment processors operating on the internet, and the like.

Workflow process

Figure 2 illustrates the workflow of the referral and reward service for settlement of transactions in the preferred embodiment. The workflow provides for interaction between affiliated merchants, registered customers, service providers and (optionally) payment processors.

The workflow begins at step 2000. First, affiliated merchants specify offers to the service provider by compiling new offers or updating existing offers (2001). The service provider then publishes the offer to the customer once validated (2002). The customer goes online and uses the referral service to find a bid that matches his demand (2003). The customer then becomes a directed customer and the service provider directs the customer to the vendor (2004).

The purchase is made between the registered customer and the seller that published the offer, at the merchant's place of business (2005). The actual purchase may be made online in an online store or offline in a brick and mortar retail store, and any payment means may be used. In the preferred embodiment, the system does not own the purchase payment settlement. Payment and settlement may be accomplished by the vendor or third party payment processor (2006). After settling the payment, the customer, merchant (requested by and on behalf of the customer) or payment processor reports the transaction to the service provider (2007).

When the service provider receives information about the transaction, the service provider validates the transaction (2008) to ensure that it received no fraudulent transactions. Assuming that the transaction reported is a valid transaction, the service provider records the transaction (2009).

Once the transaction is recorded, the service provider charges the merchant a service fee for the services offered to result in the transaction (2010). The service provider also remunerates the purchasing customer with a portion of the fee it obtained from the vendor (2011).

Preferred embodiments of Merchant service

I. Merchant interface device

The system provides a variety of merchant interfaces to enable merchants to interact with service providers to perform tasks associated with the merchants, and to report transactions that occur. Merchants select and use interfaces that are consistent with their business communication means (Web, phone, etc.) and their business management means (computerized, manual, a combination of both). In a preferred embodiment of the system, the following merchant interface means are provided: web-based user interfaces (Web UI) and telephone-based user interfaces (phone).

Merchants with internet access are able to interact with service providers using a Web UI. Merchants without internet access can pick up the phone and call the service provider to accomplish the same merchant-related tasks in the system.

The service provider also provides a programming interface means for the merchant's computerized management system to communicate with the service provider's computer system without any human intervention. This is an integration option.

Merchant affiliation

In order to use the services provided by the service provider, the merchant needs to register with the service provider. Once registered, the merchant becomes a affiliated merchant with the service provider and is able to post its sales offers to the customer. After registration, the affiliated merchant authenticates himself to the service provider using his account credentials.

Merchant offer editing

The service provider of the system provides the affiliated merchant with a variety of means (as part of the merchant interface) to edit and update the sales offers. In a preferred embodiment, the system supports manual and automatic offer editing and updating.

1. Artificial operation

If the merchant has internet access, he can edit and update his offers using the merchant Web interface. Service providers also provide telephone service so that businesses that do not have internet access or do not use the Web can make telephone calls to edit or update their offers. The incoming merchant may enter data using a numeric keypad or using voice recognition technology, or he may speak to support personnel if desired. Manual editing is well suited to merchants who have a limited number of offers and/or need only update the offers a few times per day. Manual editing may also be used for merchants that do not have computerized management systems.

2. Automation

For merchants that use computerized business management systems that have a large number of products or services available and that require frequent updates, their systems may be programmed to use a set of offered Application Programming Interfaces (APIs) to communicate with the merchant front-end on the part of the service provider to automatically edit and update offers without human intervention by the merchant.

Merchant offer specification

In a preferred embodiment of the system, the publishable merchant offer contains at least a textual and/or multimedia format description of these aspects: body and frame (aka constraints).

The bid body describes the nature of the bid, including (but not limited to) the purpose, function, design, features and benefits of the bid. The body of the offer is less likely to change compared to the framework of the offer. The frame of the quote includes the sales range of the subject, including (but not limited to) the quantity, the price, the time that the price was committed and a description of the geographic location. The frame of the offer typically changes more frequently than the offer body itself. Note that the offer may have one body and multiple frames, each with a different description. Updating a bid means updating the body, the framework, or both.

V. quotation publication

Once the offer is edited or updated, the service provider immediately performs an automated process to certify or reject the offer in accordance with the required offer specification and certain business rules. Once approved, the quote is published to the customer in real time. The merchant may also have a delayed publication in which for the merchant's offer he may choose the time at which the offer is published to the customer.

Merchant service charge (commission)

After the affiliated merchant conducts a purchase transaction with the directed customer, the service provider charges the affiliated merchant a service fee ("commission"). The service fee is pre-specified by the merchant. Typically, each merchant should determine his service fee to the service provider based on: (1) the service fee cannot be below the minimum value published by the service provider, (2) the service fee should be competitive in the market (online or offline) in which the merchant is located.

The service provider may define a minimum service charge for each merchant, each category of merchant, each geographic market, and/or for a certain period of time. When the merchant does not specify a service fee, or the specified service fee is below the provider's minimum, no quote is posted.

The service provider lets the merchant know that when there are two offers that both meet the customer's needs, offer O1 from merchant a with a higher service fee will be presented to the customer more quickly than offer O2 from another merchant B with a lower service fee. Thus, merchants paying higher service fees have the advantage of getting more referrals from the service provider.

In addition, the system provides a plurality of service fee models for use by affiliated merchants, each model having different outcomes in terms of implementation and transaction tracking complexity. In a preferred embodiment, the service provider may provide these fee models to affiliated merchants:

1. fee model with membership condition and fixed value

2. Membership conditioned and fixed percentage fee model

3. Price quotation condition and fixed value expense model

4. Quoted and fixed percentage cost model

Different trade qualification criteria exist for the member condition model and the offer condition model. Under the membership condition model, the service provider charges a commission to the vendor member for each transaction, regardless of what is sold, as long as the buyer is a member customer of the service provider. In order to charge merchants under the quote condition model, in addition to feeding back qualifications, the transaction record must also indicate that the customer purchased the product or service advertised by the quote at the time the published quote was valid.

The membership model simplifies purchase transactions and purchase tracking because the only evidence that a purchase qualifies is reward eligibility. On the other hand, the offer condition model is more targeted because it attracts customers to purchase only advertised products or services. But to prove that such a purchase is satisfactory, proof of offer is also required at the time of purchase.

The fixed percentage model differs from the fixed value model in how the commission is calculated. According to the fixed value model, the vendor specifies a service fee in monetary value (e.g., $ 0.50). The service provider charges the specified monetary value for the purchase transaction regardless of the actual sales price of the purchase transaction. On the other hand, according to the fixed percentage model, the vendor specifies a percentage (e.g., 5%) as the service rate. When a qualified transaction is generated, the service provider charges the percentage of the actual selling price.

The fixed-valued model is easier to implement in terms of transaction tracking than the fixed-percentage model because transaction reports do not require actual sales prices nor does the service provider need to confirm purchase prices.

In this system, each merchant can select the charging model to use and publish this knowledge to the customer as part of the merchant's offer. Due to the transaction tracking options each merchant has, the set of fee models available to the merchant may be limited. For example, to minimize transaction reporting fraud, a service provider may only allow a merchant to use a fixed percentage model when the merchant can only use manual tracking in which the merchant's customers manually report to the service provider that transactions occurred.

Merchants may also select and/or customize their reward programs to suit different business needs. Mature merchants may wish to have repeated purchases from an existing customer base. In this case, the merchant may select a universal reward program in which all purchases are given the same reward regardless of whether the purchases originate from new customers or from existing customers. Instead, new services require new customers. In this case, the merchant may select a new customer plan where he can increase the reward criteria for purchases originating from the new customer.

In a preferred embodiment, the service provider may also incrementally reward affiliated merchants with high sales volumes. The feedback may be provided in the form of a service fee discount. The system provider defines multiple levels of fee discounts. The higher the level at which the merchant is located, the higher the discount applied to the merchant's service fee. When an affiliated merchant reaches a certain discount level measured by the sales volume from the service provider over a period of time, its service fee is reduced by the discount specified at that level.

Preferred embodiments of customer service

I. Customer interface

The system provides a variety of customer interfaces to enable the co-customers to register themselves, report transactions, look up quotes, and get rewards after purchases. The customer can select the customer interface device that is best suited for him/her and can switch at any time. In a preferred embodiment, a set of customer interfaces is provided including, but not limited to, a Web-based user interface (Web UI), a user interface running on a mobile device (mobile UI), a telephone call (phone), and a postal service (mail).

When a customer has a laptop or desktop computer with internet access, the Web UI is the most convenient way to interact with the service provider, on which all customer-related tasks can be performed. When the client walks, the mobile UI may be its best choice. Alternatively, the customer may also place a telephone call to the service provider in order to perform tasks associated with the customer. The mail interface is used primarily as a means for customers to report transactions to the service provider.

Feedback plan membership

As a result of using the referral service, the registered customer is entitled to receive monetary value feedback from the service provider for conducting a purchase transaction. A secure account is created for each registered customer with the correct credentials, such as customer ID and password. The credentials validate the identity of the registered client.

Each registered customer is a member of a reward program initiated by the service provider. A reward profile is created that the customer can access with his registered credentials. The service provider also sends the customer a reward member card that the customer can use to confirm that he/she is a reward member when needed.

Looking up quotes

The customer may begin using the referral service by querying the referral service for published offers to meet his/her needs. He can query using any interactive customer interface, including email. For example, he may query using a client Web UI, using a mobile UI when on the road, or he may instead query using a phone call.

Similar to the merchant-derived offer specification, a valid customer-derived query also contains two aspects: body and frame (aka constraints). The body of the query describes the nature of the requirements, while the framework of the query describes the condition of the requirements, such as when and where the requirements should be fulfilled.

In addition to having the customer enter the query itself, some/all of the query specification may also be formed by the remote customer component (fig. 1, 403) and automatically passed to the service provider along with the remainder of the query (if any) that the customer manually fills out. One example of such an automatic query formation is when a user is using a mobile UI on his/her mobile device. In this case, the device location may be captured and passed to the referral service of the service provider without requiring the customer to manually enter his location.

Directing the customer to find a merchant

The preferred embodiment of the system uses a variety of methods to direct a customer to a merchant that publishes a bid to complete a "directed purchase". The directed purchase entitles the purchasing consumer to obtain quoted prices from the merchant and to receive feedback from the service provider. The referral methods range from those that are fully technically integrated with the business system of the merchant to those that support manual referrals. Depending on the cost model adopted by the vendor, the referral method and the evidence required from the purchasing customer vary.

1. Under membership-conditioned fee model

Under this model, there is no need for evidence of a special quote being posted by the vendor. In fact, the customer is automatically entitled to all published offers as long as he can prove to the merchant that he is a reward program member (e.g., by presenting his reward member card to the merchant, or swiping his reward member card through the merchant's card reader). All purchases he generates qualify for reward regardless of what he purchases from the merchant. In this case, the referral evidence is a rewarding membership of the client.

2. Under the price quotation condition expense model

Under this model, in addition to its membership, the customer must also demonstrate to the merchant at the time of purchase the special offers he accepts the promised offer commitment. Otherwise, the purchase is ineligible as a directed purchase and the customer is not entitled to reward. The format in which the merchant approves the evidence of acceptance of the offer varies with, or lacks, how the merchant associates with the service provider in connection with referral services.

For example, when a merchant's computerized management system is integrated with a service provider, once a customer accepts an offer offline, the service provider can electronically communicate the offer acceptance to the merchant. At the same time, the service provider may also transmit the customer's reward membership to the merchant. At the time of purchase, the customer only needs to prove his membership to be offered an offer to make the purchase.

On the other hand, the customer may download and print the offer, which is then brought with him to the merchant for purchase, if the merchant is able to accept a printed copy of his offer and redeem it. Or when the proof of mouth is sufficient for the merchant to redeem the offer, the customer may simply go to the merchant, verbally mention his offer from the service provider and make the purchase.

The service provider may publish and referral methods to the customer in a referral service along with the following information regarding evidence needed to effect a qualified purchase: (1) a cost model for each merchant, (2) a method of proof that each accepted eligible directed purchase.

V. customer feedback

The system discloses a cross-merchant customer reward program initiated by the service provider. For each eligible purchase transaction, the purchasing customer receives feedback in the form of a monetary value that is a fraction of the service fee that the service provider receives from the vendor. The service provider may also choose to implement the customer reward program in accordance with an open-loop model (using all the reward revenue outside the network), a semi-open-loop model (where the reward revenue is used for future in-network purchases regardless of which network merchant the customer purchases), or a closed-loop model (where the reward revenue is later used only to purchase the products or services of the merchant who sent the reward).

In an open loop reward program, the service provider creates an account for each registered customer and adds the value of the reward to the account once the reward is issued to the customer.

Upon instruction from the registered customer, the service provider transfers the monetary value from the customer's reward account to the customer itself, or to a third party account designated by the customer. For example, the accumulated reward may be transferred to the customer's deposit account at the bank, either once or periodically.

In addition to providing feedback on transactions, the system uses a mechanism to further incrementally feedback those registered customers who have made large numbers of transactions over a period of time. The service provider defines a reward tier, each tier having a different reward percentage that is the percentage of the service provider's service fee to be forwarded to the purchasing customer at that reward level. The higher the feedback level, the greater the feedback percentage will be.

Transaction service preferred embodiment

I. Confirmation report recording

To understand the transactions that occurred and to minimize possible transaction reporting fraud, the service provider confirms each reported transaction before it can be recorded, and then charges the seller and rewards the purchasing customer. The transaction report record submitted to the transaction tracking unit (154, fig. 1) must contain proof of confirmation from both the seller side and the purchasing customer side. The required authentication data varies with the cost model on which the transaction is based.

The table in fig. 3 lists the data items typically required in a transaction record. The record must contain the correct verification information for the vendor and the correct verification information for the purchasing customer. In the transaction area, it must contain, at a minimum, a unique transaction id (utid), as well as the time and place of the transaction. If the merchant uses the offer condition model, then the Offer ID (OID) must also be included in the record. When the merchant uses a pay-per-price model, the transaction report record must contain a price number. These data items are explained below:

1. merchant account verification

The seller provides the correct authentication information to enable the service provider to trust the seller of the transaction and to associate the transaction with the correct affiliated merchant.

2. Customer account verification

The purchasing client provides the correct authentication information to enable the service provider to trust the buyer of the transaction and to associate the transaction with the correct registered client.

3. Unique Transaction ID (UTID)

The service provider may generate a unique, non-repeating UTID number. The UTID may also be provided by the merchant or a third party transaction tracking provider as long as they do not conflict with existing and future UTIDs.

4. Price quote ID (OID)

The service provider may assign a unique number (OID) to each published quote. For each bid update, the OID may be changed. If the vendor uses a quoted cost model, the report record needs to contain the OID.

5. Time of day

This field records the transaction time.

6. Location of a site

This field records the transaction location.

7. Price

This field records the selling price in the transaction. Price figures are only required when the merchant uses a cost model that charges by price.

Transaction report

This section details the transaction reporting steps in the workflow (fig. 2, 2007). The preferred embodiment supports a number of methods to enable parties in a directed transaction (merchant, customer, or payment processor) to report transaction records to a service provider. The supported reporting methods can be classified into: (1) a reporting method combined with electronic payment settlement, and (2) a reporting method not combined with electronic payment settlement.

In the combined case, the payment settlement system obtains necessary additional information from the purchasing client at the time of making the purchase. After the payment is settled, the payment settlement processor electronically transmits a record containing the necessary information about the transaction that occurred to the service provider via a communication channel trusted by the provider.

Without being bound, the customer collects the necessary information, compiles a transaction record, and sends the transaction record to the service provider using any of a variety of customer user interface devices (e.g., Web UI, mobile UI, or email) in accordance with a trust relationship with the service provider (e.g., requiring the customer to log in). On the other hand, if the merchant agrees to submit transaction records on behalf of the purchasing customer, the merchant collects, compiles, and communicates the transaction records to the service provider. The merchant may report the transaction using any of a variety of provider-trusted merchant UIs. Another reporting mode supported by the system is to have the merchant and customer report together through their respective authenticated interface channels with the service provider, each party reporting a partial record. The service provider may then cross-check the authenticity of the partial report and create a complete record if the validation is successful.

The following details the case where different reporters are supported to report directed transactions:

1. integrated transaction reporting

In this case, the payment settlers (the merchant themselves or a third party payment processor) system settle the payment and electronically pass the transaction to the service provider. The settlers create a trusted connection with the service provider using the vendor's account credentials. Once verified, the service provider trusts the data items in the report record.

In such a transaction record, the only data item from the customer is the customer's reward membership. As part of the payment process, the buyer needs to provide customer reward account credentials to the payment system. There are several ways to provide customer feedback on account credentials, including (1) swiping a membership card, and (2) manually entering a membership ID. The payment system writes the customer member credentials as part of a transaction report record to be transmitted to the service provider.

If the merchant employs a price quoted fee model, the payment system needs to add the price quote ID to the transaction record. If the merchant employs a fee model that charges by price, the payment system needs to add the sales price to the transaction record. When the quote ID and the sales price are received through a trusted channel, the service provider will trust both items of information.

Integrated reporting is the most convenient method of transaction reporting. If the record is valid, the seller is billed for service immediately and the purchasing customer is rewarded immediately. However, the combined report requires a systematic combination between the accounting system and the service provider's computer system.

2. Uncombined transaction reporting-merchant representative customer reporting

In this case, the merchant is responsible for collecting the necessary information relating to the transaction and communicating the data to the service provider on behalf of the customer. The merchant may communicate with the service provider using any merchant interface device. The merchant verifies and creates a trusted connection with the service provider to report the transaction. Thus, the service provider trusts the merchant data about the transaction. Similar to the combined transaction reporting scenario, the only information that a merchant needs to obtain from a customer is the merchant's reward membership.

The merchant either collects all the data electronically with his computerized management system or manually collects some/all of the data to be reported. There may be delays in merchant charging and customer return depending on the collection and transmission techniques used by the merchant.

For example, when a vendor has a computer connected to the internet in a store, he can use the service provider's virtual terminal tracking. "virtual terminal" refers to a web page on a provider's merchant website. After proper verification, the vendor is trusted by the service provider and can enter the necessary transaction data items on the web page and then submit the record.

3. Uncombined transaction report-customer report

In this case, the customer is fully responsible for collecting the required transaction reporting information and submitting the records to the service provider. The customer creates a trusted access relationship with the service provider using any customer interface device supported, including email. Thus, the service provider trusts the reported customer data. To ensure that the customer does not falsify the transaction for reporting, the customer is required to obtain a UTID number from the vendor. When reporting prices, the customer also needs to submit valid price evidence.

Depending on the customer interface device used to report the transaction, the delay in merchant charges and customer rewards can vary between a short time (when the customer reports using the Web or mobile UI once the transaction has occurred) and a long time (days). In fact, customer reward incentives are a means of encouraging customers to quickly report on purchases that occur.

4. Uncombined reporting, merchant and customer co-reporting

In this case, the merchant and customer agree to report transaction records together, the merchant may collect and report the merchant and transaction data fields section of FIG. 3, and the customer may report the customer data plus the UTID. Each party reports its data to the service provider via a respective trusted connection. Both parts of the report are then trusted by the service provider. The service provider combines the two part records according to the UTID.

The delay in merchant charges and customer returns depends on how quickly both parties submit portions of their transaction records.

In summary, the transaction reporting features provided in the present invention generally track transactions that occur regardless of the purchase channel (e.g., online or offline purchase), the payment means used (e.g., cash, check, credit card, debit card, etc.), or the payment settlement used (e.g., merchant's own settlement, third party settlement). Thus, the present invention ensures that the merchant is served to its fullest capacity by directing customers to the merchant's existing retail store.

Confirmation of transaction

The first step in confirming the transaction reported is to require the reporting party to transmit the data with proper verification. The service provider then uses the reported transaction-related data to attribute the transaction to the correct affiliate and to the correct registered customer. Validation also serves the purpose of reducing transaction reporting fraud.

It is not possible for a verified merchant to report a non-existent transaction because the service provider would charge the reporting merchant for each transaction reported and confirmed. However, the authenticated customer may report fraudulent or non-existent transactions for additional feedback. The following is one feature that the preferred embodiments may use to reduce customer transaction reporting fraud. When a customer reports a transaction, the customer must obtain a unique transaction id (utid) number from the merchant. If there is no UTID or an unrecognizable UTID, the submitted transaction record is not validated. The provisioned UTID may be checked by the service provider and associated with the merchant. The UTID may also be associated with a particular time or range of times by the time at which the transaction with the UTID should occur.

In a preferred embodiment of the system, once the transaction tracking unit (154, fig. 1) of the service provider receives the transaction record over the verified connection, it passes the record to the transaction confirmation unit (155, fig. 1). The validation process performs at least the following tests against the transaction records it receives. Only if all of the following tests pass is the submitted transaction confirmed.

1. And (5) confirming by the merchant. The vendor must be an existing affiliated merchant.

2. And (5) customer confirmation. The purchasing customer must be an existing registered customer.

3. And (6) confirming the transaction. The UTID must be the UTID already assigned to the submitting merchant when reported by the customer.

Other tests of the offer condition model may include:

the offer ID (oid) must be the ID of the offer published by the submitting merchant.

The time and place of the transaction reported must be within an effective price frame.

Other tests of the pay-per-price model may include:

when a record is submitted from a customer, valid evidence of a sales receipt must be provided, and the price on the receipt must match the price reported.

Operation of

Is provided with

First, the service provider sets up the service provider component (fig. 1, 101) and publishes the merchant component 201 and the customer component 401.

The merchant downloads the actual merchant component to its management system and installs it, or notes how to communicate with the service provider component using an intangible merchant interface. The merchant may communicate with the service provider using any reporting means. Once the merchant completes the installation interface to communicate with the service merchant, he can perform the merchant registration task using the preferred merchant interface. After registration is successful, the merchant becomes a affiliated merchant for the service provider. He may then use the merchant services provided by the service provider.

If the merchant owns an electronic payment settlement system, he can use integrated transaction tracking after programming the settlement system with the provided transaction API. If a merchant uses a third party electronic payment settlement system and the system performs integrated transaction tracking, the merchant can set up using integrated tracking by informing the payment settlers of their affiliated merchant account credentials.

The service provider independently cooperates with third party payment processing services to enable transaction tracking integration.

Before any quote is published, affiliates need to determine their service fee model and fee schedule and notify the service provider.

The client downloads and installs the actual client component 401 onto the appropriate computer or device (Web UI, mobile UI, etc.) that he will use to communicate with the service provider. The customer may interact with the service provider using any combination of customer interfaces. The client then performs the registration task to become a registered client. One option a registered customer has is to specify a financial account that the service provider can credit for the reward. Once the customer is registered, the service provider issues a reward membership card to the customer.

Use of services

Affiliated merchants are able to perform any merchant service tasks at any time. Primarily, merchants publish and update their sales offers using the service, report transactions on behalf of requesting customers (if the customers agree to do so), monitor the effect of their offers, verify the effectiveness of their fee models and fee schedules, and pay service fees to service providers. The service provider provides each merchant with a merchant report that reports and summarizes the relevant activity once a month.

Customers primarily use the system to search for and obtain bids that are consistent with their needs. The customer then goes to the merchant to purchase goods and services by displaying the required referral evidence. The customer then has the payment processor or merchant report the transactions that occurred, or he may report himself. The customer may also access his reward account. The service provider provides a monthly report to each customer and a customer report summarizing the relevant activity.

Alternative embodiments

Payment processor

An alternative embodiment of the system is to include its own payment processor (fig. 1, 504) that will be tightly coupled to the transaction tracking unit 154. In this way, the service provider provides the affiliated merchant with a default payment settlement option that always tracks the directed transaction on the fly. Another implication is that with the owning payment processor, the service provider can change the customer reward account to a credit or debit account in such a way that the reward value can be used directly for future purchases through the owning payment processor. This also means that the issued reward card can be used as a credit or debit card in a retail transaction.

Customer referral

In an alternative embodiment, the service provider can add additional service features to the customer referral service. For example, a shipping service may be implemented as a way of customer referrals. Instead of having to have the guided customer go to the merchant for a purchase, once the customer accepts the offer, the product or service may be immediately shipped to the customer.

Another alternative is applicable to customers who do not want or have time to view products at a physical retail store. For these customers, the referral service can direct the merchant to prepare products for the customer before the customer arrives at the store. The customer can quickly pick, pay for and leave products that were pre-selected by the referral service.

In another alternative embodiment, a reverse referral service can be implemented. Rather than directing the customer to the merchant, the merchant may also be directed to the customer. In the case of reverse referral, the customer publishes the requirements through the service provider. Merchants search for needs that they can service and publish offers that are appropriate for those needs.

Merchant offer aggregation and distribution to customer destinations

The system also enables the service provider to collect offers from merchants and deliver offers to customers through a number of online customer destinations or third party content publishers, including but not limited to search engines (i.e., Google, Yahoo), content sites, online directory sites, online community sites. In addition, the service provider may also communicate the collected merchant offers to other third party customer destinations through various delivery channels, including, for example, Short Message Service (SMS), which communicates the merchant offers for viewing on a mobile device, and interactive cable TV, among others. All of these customer destinations may use a variety of different fee models to communicate merchant offers to customers, including a pay-per-click (CTC) and a pay-per-list fee model.

In essence, the service provider may become a merchant offer aggregator and broker that communicates collected offers to associated customer destinations; these associated destinations in turn pass the received offers to the various customers. When the transfer of an offer from the associated destination to the customer results in a purchase at the POS in the store, the service provider may pay a portion of the transaction fee received to the functioning customer destination.

Thus, the system provides a way to distribute revenue received from a transaction fee from a merchant (using a revenue distribution module as part of the transaction front end 152 in the exemplary embodiment) to associated customer destinations that help direct customers to the merchant storefront for purchases. The process may include an offer collection process (described above), an offer distribution process, an offer communication process, a purchase transaction process, a commission collection process, an offer communication-purchase causality determination process, and an income distribution process. In the offer collection process, the service provider collects offers from the affiliated merchants. During the offer distribution process, at least one associated customer destination presents the received special offer to one or more customers. During a purchase transaction (described above), a customer affected by the presented offers arrives at the physical location of the merchant publishing the offer (i.e., the store) and makes a purchase, which is captured on the service membership card. In the commission collection process (described above), the service provider collects a commission from the seller based on a predetermined rate, such as a percentage of the purchase price or a fixed monetary value as described above. In the bid communication-purchase causality determination process, the service provider and associated customer destination determine the causality of user activity (e.g., clicks on search keyword advertisements or impressions on display advertisements) from the customer destination to the resulting purchase transaction. Where integration of usage and transactions is required. In the revenue distribution process, the service provider distributes a portion of the revenue received from the vendor to each associated customer destination for the service in the bid communication process according to the causality determined in the bid communication-purchase causality determination process. In the above approach, the offer delivery process is another extension of the offer delivery process described above, in that there may be multiple associated customer destinations in addition to the provider's own customer destination (if one exists).

In some embodiments of the offer communication-purchase causality determination process and the revenue distribution process, data from both parties may be collectively utilized to statistically determine the causality of a user's activities at a customer destination with a resulting purchase. For example, a portion of the commission (referred to as the payable portion of the commission) can be paid to the active customer destination. The conversion denominator may be determined by the aggregate total of the user's activities for the merchandising information published by all participating customer destinations. The service provider may allocate a portion of the redeemable fee to each participating customer destination in proportion to the number of online user activities occurring at that destination relative to the total number of user activities aggregated across all associated customer destinations. For example, if there are 100 clicks from all participating customer destinations that result in a purchase, then each click obtains 1% of the payable portion of the transaction fee (one transaction divided by 100 clicks). Assuming that one customer destination a contributes 60 clicks and the other destination B contributes 40 clicks, then destination a and destination B receive 60% and 40% of the billable revenue, respectively, from the service provider. It will be apparent that other, possibly more complex, statistical algorithms and modeling may be used to determine revenue expense allocations associated with transaction fees among customer destinations.

In other embodiments of the offer communication-purchase causality determination process and the revenue distribution process, online users conducting online activities that result in the generated in-store purchases may be identified and associated with the actual customers who purchased the products or services in the generated transactions. In other words, causality can be determined at the level of a single customer. Such online user identification and contact with an offline buyer can be made explicitly by identifying the user in a generic identification system suitable for online activities and in-store purchases, or creating a linkage between an offline customer identification system and one or more online user identification systems.

One explicit identification option is that the customer destination requires the user to log in with the service provider's customer membership. Online user/in-store buyer contacts can also be created implicitly and/or algorithmically for anonymous online users. The destination user and the in-store purchase may be associated taking into account other parameters of the online user activity and the in-store purchase (other than and/or in addition to the user identification). The parameters that may be used may include time and location relationships between online customer destination activities and in-store purchases.

Another explicit identification option is that the customer destination can install specialized "click-to-record" software detection and conversion products, either as an extension to the customer tracking methods they are currently using, or as a new service that can be offered by the service provider, or developed by the customer destination provider (subject to the design requirements of the service provider). Such extension software will generate a unique identification code for each click activity of a customer on a bid displayed by a customer destination. The spreading code (which may preserve the anonymity of the customer) is then transmitted back to the service provider's database where it is reconciled with subsequent sales transactions for the particular customer whose online "click" activity generated the spreading code. The online customer destination will then be assigned a percentage of the commission charged by the service provider.

Although the foregoing relates to a particular embodiment of the present invention, it will be appreciated by those skilled in the art that changes in this embodiment may be made without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims.

Appendix A

Appendix B

Claims (36)

1. A computer-implemented system for tracking sales transactions, particularly offline sales transactions, comprising:

a service provider component implemented on a computing device, wherein the service provider component further comprises a merchant unit, a transaction unit, and a customer unit, wherein the merchant unit, the transaction unit, and the customer unit all further comprise lines of computer code executed by a processing unit of the computing device, the lines of computer code running the merchant unit, the transaction unit, and the customer unit, the merchant unit, the transaction unit, and the customer unit implementing a method of tracking sales transactions, particularly offline transactions, the method comprising:

providing, by an online advertising system associated with the service provider component, sales offers for a particular merchant to the customer;

tracking a plurality of sales transactions submitted to a service provider component, in particular offline sales transactions;

validating each sales transaction at the service provider component to determine whether the sales transaction is a validated referral sales transaction for the particular merchant; and

the service provider component charges the specific merchant a commission for the confirmed referral sale transaction.

2. The system of claim 1, wherein the method of tracking sales transactions, particularly off-line sales transactions, further comprises providing feedback to the customer by the service provider component regarding referral of the sales transactions.

3. The system of claim 1, wherein in the method of tracking sales transactions, tracking a plurality of sales transactions, particularly offline sales transactions, further comprises capturing sales transactions near a point of sale of the sales transactions and storing the sales transactions in a central database associated with a customer referral and reward system for settlement of the transactions.

4. The system of claim 3, wherein in the method of tracking sales transactions, capturing sales transactions, particularly offline sales transactions, further comprises capturing each sales transaction at a point of sale with a card or membership evidence, wherein the card further comprises a magnetic stripe card or a credit card.

5. The system of claim 1, further comprising an online advertising system associated with the service provider component, the online advertising system further comprising the mobile device or the interactive cable television system.

6. The system of claim 1, further comprising a merchant component located at each merchant location, the merchant component allowing the merchant to interface with the merchant unit of the service provider component.

7. The system of claim 1, further comprising a customer component at each customer location that allows the customer to interface with the merchant unit of the service provider component.

8. The system of claim 1, wherein the merchant unit further comprises a trusted merchant rating stored in the merchant unit that rates each merchant.

9. The system of claim 1, wherein providing a sales offer further comprises providing a broker-ordered advertisement to the user.

10. The system of claim 1, wherein the merchant unit further comprises a commission bidding unit, wherein the merchant makes a higher commission and the higher commission sales offer is displayed more prominently to the user.

11. A method of tracking sales transactions, in particular offline transactions, the method comprising:

providing, by an online advertising system associated with a customer referral and reward system for settlement of transactions, sales offers for a particular merchant to customers;

tracking a plurality of sales transactions, particularly offline transactions, submitted to a customer referral and reward system for transaction settlement;

validating each sales transaction at a customer referral and reward system for transaction settlement to determine whether the sales transaction is a referral sales transaction for the particular merchant; and

the customer referral and reward system for transaction settlement collects a commission for the referral sales transaction from the particular merchant.

12. The method of claim 11, further comprising providing feedback to the customer about the referral sale transaction by a customer referral and feedback system for settlement of the transaction.

13. The method of claim 11, wherein tracking a plurality of sales transactions, particularly off-line transactions, further comprises capturing the sales transactions near a point of sale of the sales transactions and storing the sales transactions in a central database associated with a customer referral and reward system for settlement of the transactions.

14. The method according to claim 13, wherein capturing sales transactions, in particular offline transactions, further comprises capturing each sales transaction at a point of sale using a card or membership evidence, wherein said card further comprises a magnetic stripe card or a credit card.

15. The method of claim 11, wherein the online advertising system further comprises a mobile device or an interactive cable television system.

16. The method of claim 11, further comprising determining a trusted merchant rating stored in the merchant unit that rates each merchant.

17. The method of claim 11, wherein providing a sales offer further comprises providing a broker-ordered advertisement to the user.

18. The method of claim 11, further comprising establishing a commission bidding system wherein merchants offer higher commissions and sales offers with higher commissions are displayed more prominently to users.

19. A computer-implemented merchant advertising system, comprising:

a service provider component implemented on a computing device, wherein the service provider component further comprises a merchant unit, a transaction unit, and a customer unit, wherein the merchant unit, the transaction unit, and the customer unit all further comprise a plurality of lines of computer code executed by a processing unit of the computing device, the plurality of lines of computer code running the merchant unit, the transaction unit, and the customer unit, the merchant unit, the transaction unit, and the customer unit implementing a merchant advertising method, the method comprising:

providing a merchant interface to each merchant of a merchant advertising system, the merchant interface providing real-time control over the publishing, updating, and modifying of online advertisements for a particular merchant, each online advertisement having a geographic area associated with the online advertisement and a commission to be paid to a service provider in accordance with a sale generated by the online advertisement;

electronically displaying online advertisements in each online advertisement in a particular geographic area on a map for all merchants based on the geographic area associated with the online advertisement; and

a commission bidding system is utilized to bid on a commission associated with each online advertisement, wherein the commission paid to the service provider and loyalty reward to the customer for the particular online advertisement is reduced based on the bid.

20. The system of claim 19, wherein the merchant advertising method further comprises selecting the online advertisements displayed to the customers in the geographic area based on a commission on each online advertisement in the geographic area.

21. The system of claim 20, wherein selecting the online advertisement further comprises selecting the particular online advertisement based on a highest commission associated with the particular online advertisement.

22. The system of claim 19, wherein displaying online advertisements in a particular geographic area further comprises displaying a map on a web browser.

23. The system of claim 19, wherein displaying the online advertisement in the particular geographic area further comprises displaying a map using a Global Positioning System (GPS) navigation system.

24. The system of claim 19, wherein the online advertisement further comprises an advertisement generated based on a search specific to local shopping.

25. The system of claim 19, wherein the online advertisement further comprises a real-time bid presented on the map.

26. A merchant advertising method, the method comprising:

providing a merchant interface to each merchant of a merchant advertising system, the merchant interface providing real-time control of the publishing, updating and modifying of online advertisements for a particular merchant, each online advertisement having a geographic area associated with the online advertisement and a commission to be paid to a service provider upon utilization of the online advertisement;

electronically displaying online advertisements in each online advertisement in a particular geographic area on a map for all merchants based on the geographic area associated with the online advertisement; and

a commission bidding system is utilized to bid on a commission associated with each online advertisement, wherein the commission paid to the service provider and loyalty reward to the customer for the particular online advertisement is reduced based on the bid.

27. The method of claim 26, further comprising selecting the online advertisements to display to customers in the geographic area based on a commission on each online advertisement in the geographic area.

28. The method of claim 27, wherein selecting the online advertisement further comprises selecting the particular online advertisement based on a highest commission associated with the particular online advertisement.

29. The method of claim 26, wherein displaying online advertisements in a particular geographic area further comprises displaying a map on a web browser.

30. The method of claim 26, wherein displaying the online advertisement in the particular geographic area further comprises displaying a map using a Global Positioning System (GPS) navigation system.

31. The method of claim 26, further comprising generating an online advertisement, the online advertisement generated based on a search specific to local shopping.

32. The method of claim 26, further comprising causing the advertisement to be displayed on the map in real time.

33. A method of allocating revenue derived from transaction fees from one or more merchants to one or more associated customer destinations that assist in pushing customers to one or more merchant storefronts for purchases, the method comprising:

collecting one or more offers from one or more merchants;

distributing the one or more offers to a plurality of associated customer destinations;

at least one associated customer destination communicating the one or more offers to one or more customers;

capturing a product purchase from a customer to a vendor in accordance with the communicated offer; and

allocating a commission from the purchase between the captured vendor and the at least one associated customer destination.

34. The method of claim 33, wherein allocating the commission further comprises determining a causal relationship between the purchase and a user action associated with the at least one associated customer destination, and allocating the commission based on the determined causal relationship between the purchase and the at least one associated customer destination.

35. The method of claim 33, further comprising charging the vendor a commission on the captured purchase.

36. The method of claim 35, wherein collecting the commission further comprises collecting the commission based on a percentage of the purchase price or a fixed monetary value.