WO2000039727A2 - Procede et dispositif servant a produire des avantages et des penalites croises - Google Patents

Procede et dispositif servant a produire des avantages et des penalites croises Download PDF

Info

Publication number
WO2000039727A2
WO2000039727A2 PCT/US1999/030504 US9930504W WO0039727A2 WO 2000039727 A2 WO2000039727 A2 WO 2000039727A2 US 9930504 W US9930504 W US 9930504W WO 0039727 A2 WO0039727 A2 WO 0039727A2
Authority
WO
WIPO (PCT)
Prior art keywords
customer
vendor
obligation
item
price
Prior art date
Application number
PCT/US1999/030504
Other languages
English (en)
Other versions
WO2000039727A8 (fr
Inventor
Jay S. Walker
James A. Jorasch
Daniel E. Tedesco
Deirdre O'shea
Stephen C. Tulley
Keith Bemer
Original Assignee
Walker Digital, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/219,267 external-priority patent/US7831470B1/en
Application filed by Walker Digital, Llc filed Critical Walker Digital, Llc
Priority to AU27125/00A priority Critical patent/AU2712500A/en
Publication of WO2000039727A2 publication Critical patent/WO2000039727A2/fr
Publication of WO2000039727A8 publication Critical patent/WO2000039727A8/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems

Definitions

  • the present invention relates to methods and apparatus for facilitating commerce.
  • a vendor may also offer promotions to provide an incentive for customers to make purchases. For example, a vendor may offer a "buy one get one free" promotion whereby a purchase of an item yields the benefit of an additional item at no cost. Similarly, a vendor may provide a discount on a purchase in exchange for signing up for a credit card account provided by the vendor.
  • Promotions may also be provided among two or more vendors. For example, a first vendor may advertise that if a particular product is purchased, another product may be purchased from or given away by a second vendor.
  • the second vendor typically requires that, in return, an obligation be fulfilled, such as signing up to become a customer of the second vendor.
  • a controller receives an indication of items that a customer is to purchase from a first vendor.
  • the items have an associated total price, such as the sum of the retail prices of the items and any applicable taxes.
  • the controller transmits an indication of an offer for a benefit from a second vendor.
  • the benefit may be, for example, a subsidy such that the items may be purchased for less than the total price.
  • the offer also defines an obligation that the customer must fulfill in exchange for the benefit. For example, the customer may be obligated to participate in another transaction with the second vendor.
  • the items are provided to the customer for less than the total price. It is then determined whether the customer has fulfilled the obligation.
  • a penalty is applied. For example, a credit card account of the customer may be charged to recoup an amount of the previously-provided subsidy.
  • FIG. IA is a schematic illustration of an embodiment of an apparatus for providing an offer in accordance with the present invention.
  • FIG. IB is a schematic illustration of another embodiment of an apparatus for providing an offer in accordance with the present invention.
  • FIG. 2 is a schematic illustration of a device that may be a controller of
  • FIG. 1 A or alternatively a vendor server of FIG. IB.
  • FIG. 3 is a schematic illustration of a vendor server of FIG. IA.
  • FIG. 4 is a tabular representation of an embodiment of a customer database of FIG. 2.
  • FIG. 5 is a tabular representation of an embodiment of a vendor database of FIG. 2.
  • FIG. 6 is a tabular representation of an embodiment of a transaction database of FIG. 2.
  • FIG. 7 is a tabular representation of an embodiment of a subsidizer database of FIG. 2.
  • FIG. 8 is a tabular representation of an embodiment of an offer rules database of FIG. 2.
  • FIGS. 9A and 9B are a tabular representation of an embodiment of an offers database of FIG. 2.
  • FIG. 10 is a tabular representation of an embodiment of an offer summary database of FIG. 2.
  • FIG. 11 is a tabular representation of an embodiment of an item database of FIG. 3.
  • FIG. 12 is a flow chart illustrating an embodiment of a method for providing an offer for a benefit to a customer.
  • FIG. 13 is a flow chart illustrating an embodiment of a method for providing items for less than their total price.
  • FIG. 14A is a flow chart illustrating an embodiment of a method for determining whether a customer has fulfilled his obligation.
  • FIG. 14B is a flow chart illustrating an embodiment of a method for determining whether obligation expiration dates have passed without corresponding obligations having been fulfilled.
  • FIG. 15 is a flow chart illustrating an embodiment of a method for applying a penalty.
  • FIG. 16 illustrates an example of a billing statement.
  • the budgets, such as acquisition budgets, of various vendors may be advantageously used to facilitate commerce.
  • a customer that purchases items from a first vendor may be paid, directly or indirectly, by a second vendor (a "subsidizing vendor"), so that the customer pays a reduced price, perhaps nothing at all, for his desired items.
  • the customer participates or agrees to participate in a transaction with the second vendor.
  • this "transaction" may be any interaction with the second vendor or another party.
  • the customer may be required to sign up for a service that is provided by the second vendor. Since many service providers are willing to pay significant amounts of money (e.g.
  • the ability to acquire a customer by essentially "intervening" in a sale between others can benefit all parties involved.
  • Even a vendor that has not traditionally used an acquisition budget or other budget in this manner may be willing to pay a particular amount of money in exchange for, e.g., acquiring a new customer of a provided service, having a customer purchase an item, having a customer participate in a survey.
  • the customer is benefited by the reduced price of his items
  • the first vendor is benefited by the increased sales and customer satisfaction that such an arrangement can bring
  • the second vendor is benefited by the additional transaction, particularly the acquisition of a new customer in one embodiment.
  • the customer may participate in the transaction with the subsidizing vendor after he receives the benefit.
  • the customer may be required to sign up for a particular service within a week, or may be required to purchase something from the subsidizing vendor during a predetermined period of time. Since the benefit is provided before the customer fulfils his obligation, there is the risk that the customer will receive the benefit yet not fulfill his obligation at all.
  • Applicants have also recognized that it can be advantageous to deter such customers from reneging on their respective obligations.
  • the present invention includes various ways to apply a penalty if the customer has not fulfilled the obligation. The threat of the penalty deters customers from not fulfilling their respective obligations.
  • subsidizing vendors become more willing to provide benefits.
  • subsidizing vendors become more willing to provide greater benefits (e.g. higher reductions in purchase prices) since customers are more likely to in turn provide the subsidizing vendors with what they desired.
  • the present invention allows a benefit to be provided before the second transaction is completed or even initiated, a greater variety of such second transactions may be requested of the customer.
  • the present invention allows both customers and vendors to benefit, and commerce is greatly facilitated.
  • an apparatus 100 includes a controller 110 that is in communication with a vendor server 120.
  • the controller 110 and the vendor server 120 may comprise computers, such as those based on an Intel® Pentium® microprocessor, that are adapted to communicate via the Internet (e.g. via a modem) or other medium.
  • Any number of vendor servers may be in communication with the controller 110.
  • Each such vendor server can be associated with a different vendor.
  • devices in communication with each other need not be continually transmitting to each other. On the contrary, such devices need only transmit to each other as necessary, and may actually refrain from exchanging data most of the time. For example, a device in communication with another device via the Internet may not transmit data to the other device for weeks at a time.
  • the vendor server 120 may be a "Web server" of a vendor (e.g. a retail seller).
  • a vendor server may be operable to generate and/or serve Web pages (documents on the World Wide Web that typically include an HTML (Hypertext Markup Language) file and associated graphics and script files) that may be accessed via the World Wide Web and allow purchases from the vendor to be made in a manner known in the art.
  • a Web site typically consists of several such Web pages and associated databases served by one or more HTTP (Hypertext Transfer Protocol) servers (e.g. the vendor server 120) on the World Wide Web.
  • the vendor server 120 may be a computer involved in operating a physical store. Such a computer, for example a point of sale (POS) server, would perform such tasks as inventory management and transaction processing for the store.
  • POS point of sale
  • the controller 110 is also in communication with a subsidizing vendor server 140.
  • the subsidizing vendor server 140 may also comprise a computer, such as those based on an Intel® Pentium® microprocessor, that is adapted to communicate via the Internet (e.g. via a modem) or other medium. Any number of subsidizing vendor servers may be in communication with the controller 110.
  • the subsidizing vendor server 140 may be a "Web server" of a subsidizing vendor.
  • the subsidizing vendor server 140 may be operable to generate and/or serve Web pages that may be accessed via the World Wide Web and allow transactions with the subsidizing vendor in a manner known in the art.
  • the subsidizing vendor server 140 may be a computer such as a POS terminal server that is involved in operating a physical store. Such a computer would perform such tasks as inventory management and transaction processing for the store.
  • the subsidizing vendor server 140 may merely provide offers for benefits as described below.
  • the vendor server 120 may be in communication with a customer terminal 130 that transmits data regarding a customer transaction (e.g. a purchase). Any number of customer terminals may be in communication with the vendor server 120.
  • the customer terminal 130 may be a POS terminal, such as the NCR 7454 manufactured by NCR Corporation or the IBM 4683 manufactured by International Business Machines. As is known in the art, POS terminals perform such processes as calculating the total price of goods or services to be purchased, and calculating the amount of change due to a customer. POS terminals may furthermore track purchases made and adjust databases of inventory accordingly.
  • a typical POS terminal includes or is operably connected to such input devices as (i) an optical bar code scanner for reading bar codes and transmitting signals indicative of those bar codes to the processor of the POS terminal, and/or (ii) a card reader operative to read cards such as magnetic strip cards that have magnetizable strips or surfaces on which data may be recorded.
  • the card reader in turn transmits signals representing such read data to the processor 202.
  • One such card reader is the OMNF M 1450 payment terminal, manufactured by VeriFone, Inc., which includes a built-in, magnetic-stripe reader, a PIN pad and an integrated smart card reader.
  • the customer terminal 130 may be a computer, such as those based on an Intel® Pentium® microprocessor, that is adapted to communicate via the Internet (e.g. via a modem) or other medium. Such computers are able to appropriately access a Web page to communicate with a vendor server in a manner that is known to those skilled in the art.
  • a computer such as those based on an Intel® Pentium® microprocessor, that is adapted to communicate via the Internet (e.g. via a modem) or other medium.
  • Such computers are able to appropriately access a Web page to communicate with a vendor server in a manner that is known to those skilled in the art.
  • the customer terminal 130 may be a portable type of computer, such as a laptop computer, a palm-top computer, a hand-held computer, or a "PDA" (Personal Digital Assistant).
  • the customer terminal 130 may be the Nino 300 pen-based Personal Companion, manufactured by Philips Electronics N.V.; or the InfoMobile smart phone manufactured by Samsung Electronics, each of which utilizes the Windows® CE operating system of Microsoft Corporation.
  • the customer terminal 130 may be a telephone, an automated teller machine (ATM), a slot machine, a vending machine or other device that provides goods or services to a customer.
  • the vendor server in such an embodiment could include an IVRU (Interactive Voice Response Unit), such as the
  • An IVRU allows a user of a DTMF (Dual Tone Multi-Frequency) signal-generating telephone to communicate with a computer.
  • the DTMF signals received from the user's telephone are interpreted by the vendor server and transformed into commands for the computer.
  • the vendor server may also communicate with the user by generating and transmitting voice or other audio signals, such as an list of INRU menu options, as directed by the vendor server.
  • controller 110 is especially advantageous in an embodiment where a plurality of subsidizing vendors and/or a plurality of vendor servers serving customers participate in the described invention.
  • a parent application U.S. Patent Application No. 09/274,281 entitled “METHOD AND APPARATUS FOR PROVIDING CROSS-BENEFITS VIA A CENTRAL AUTHORITY", filed March 22, 1999, the entirety of which is incorporated by reference herein as part of the present disclosure, discloses an invention utilizing such a controller.
  • an apparatus 150 represents another embodiment of an apparatus for facilitating commerce in accordance with the present invention.
  • a vendor server 160 communicates with a customer terminal 170, and also with a subsidizing vendor server 180 without the intervening controller 110.
  • the embodiment illustrated by FIG. IB is appropriate for a direct relationship between the vendor servicing customers and the subsidizing vendor.
  • reference numeral 200 indicates a device that may be the controller 110 (FIG. 1 A).
  • the functionality of the device 200 may be performed by another device, such as the vendor server 160 (FIG. IB), which operates to directly or indirectly provide a customer with an offer for a subsidy from a second vendor.
  • the device 200 comprises a processor 202, such as an Intel® Pentium® microprocessor.
  • the processor 202 is in communication with a data storage device 210, such as an appropriate combination of magnetic, optical and/or semiconductor memory.
  • the data storage device 210 may comprise one or more of a ROM, RAM and hard disk.
  • the processor 202 and the data storage device 210 may each be (i) located entirely within a single computer or other computing device; (ii) connected to each other by a remote communication medium, such as a serial port cable, telephone line or radio frequency transceiver; or (iii) a combination thereof.
  • the controller 110 may comprise one or more computers that are connected to a remote server computer for maintaining databases.
  • the data storage device 210 stores a program 220 for controlling the processor 202.
  • the processor 202 performs instructions of the program 220, and thereby operates in accordance with the present invention, and particularly in accordance with the methods described in detail herein.
  • the program 220 may be stored in a compressed, uncompiled and/or encrypted format.
  • the program 220 furthermore includes program elements that may be necessary, such as an operating system, a database management system and "device drivers" for allowing the processor
  • the storage device 210 also stores (i) a customer database 230, (ii) a vendor database 240, (iii) a transaction database 250, (iv) a subsidizer database 260, (v) an offer rules database 270, (vi) an offers database 280 and (vii) an offer summary database 290.
  • the databases 230, 240, 250, 260, 270, 280 and 290 are described in detail below and depicted with exemplary entries in the accompanying figures.
  • FIG. 3 illustrates the vendor server 120 of FIG. 1 A.
  • the vendor server may communicate with a subsidizing vendor server 180 without the intervening controller 110. Accordingly, the description of the vendor server 120 is applicable to the vendor server 160 of FIG. IB.
  • the databases stored by the data storage device of the vendor server could include the databases depicted in FIGS.
  • the vendor server 120 comprises a processor 302, such as an Intel® Pentium® microprocessor, which is in communication with a customer terminal 315 and the controller 110. Any number of customer terminals may be in communication with the processor 302.
  • the processor 302 is also in communication with a data storage device 310, such as an appropriate combination of magnetic, optical and/or semiconductor memory.
  • the data storage device 310 may comprise one or more of a ROM, RAM and hard disk.
  • the processor 302 and the data storage device 310 may each be (i) located entirely within a single computer or other computing device; (ii) connected to each other by a remote communication medium, such as a serial port cable, telephone line or radio frequency transceiver; or (iii) a combination thereof.
  • the vendor server 120 may comprise one or more computers that are connected to a remote server computer for maintaining databases.
  • the data storage device 310 stores a program 320 for controlling the processor 302.
  • the processor 302 performs instructions of the program 320, and thereby operates in accordance with the present invention, and particularly in accordance with the methods described in detail herein.
  • the program 320 furthermore includes program elements that may be necessary, such as an operating system, a database management system and "device drivers" for allowing the processor 302 to interface with computer peripheral devices. Appropriate device drivers and other necessary program elements are known to those skilled in the art, and need not be described in detail herein.
  • the data storage device 310 also stores (i) a customer database 330, (ii) an item database 340, and (iii) a transaction database 350.
  • the customer database 330 and the transaction database 350 of the vendor server 120 may be similar or identical to the customer database 230 and transaction database 250 of the controller 110.
  • the controller 110 may store data that is derived or copied from the vendor server 120, and vice versa. If each vendor server stores data regarding its own customers and its own transactions, the controller 110 could aggregate this data from each vendor server to store in its customer database 230 and transaction database 250, respectively.
  • the databases 230 and 250 of the controller 110 would then store customer and transaction data for each vendor.
  • the databases 330, 340 and 350 are described in detail below and depicted with exemplary entries in the accompanying figures.
  • a table 400 represents an embodiment of the customer database 230 (FIG. 2) and/or the customer database 330 (FIG. 3).
  • the table 400 includes entries 402, 404, 406 and 408, each defining a customer that may purchase items from a vendor.
  • the data of an entry may be input, for example, when a customer registers for a frequent shopper card or when a customer first makes a purchase from a vendor.
  • the table 400 may include any number of entries.
  • the table 400 also defines fields for each of the entries 402, 404, 406 and 408.
  • the fields specify (i) a customer identifier 420 that uniquely identifies the customer, (ii) a name 422 of the customer, (iii) a billing address 424 of the customer, (iv) credit card information 426 (or another payment identifier) which may be used to render payment in purchasing the items, (v) an electronic mail ("e- mail") address 428 for facilitating communication with the customer, (vi) whether the customer may receive offers 430 for benefits, and (vii) a number of times 432 the customer has reneged on his obligations.
  • the data may be received when the customer makes a purchase from a vendor's Web site by requiring the customer to enter information into an HTML form provided on a Web page of the Web site.
  • the data specified by the field 430 may be initially set to "YES” and updated to reflect, for example, that the customer desires not to receive any offers, or that the customer has been barred from receiving offers (e.g. after reneging more than a particular number of times).
  • the data specified by the field 432 may be initially set to "0" and updated to reflect, for example, the number of times that the customer has not met his obligations.
  • data stored in the customer database 330 may be accessed by all vendors that service customers and all subsidizing vendors that are in communication with the controller 110. Thus, the customer need not take any steps to provide information such as a credit card account number when participating in a transaction with such vendors. Appropriate security features may be included to allow selective access to such data, as is apparent to those skilled in the art.
  • a table 500 represents an embodiment of the vendor database 240 (FIG. 2).
  • the table 500 includes entries 502, 504, 506 and 508, each defining a vendor that services customers and that may have those customers receive offers for subsidies.
  • the data of an entry may be input, for example, when the corresponding vendor registers for participation in the program described herein for providing offers for benefits.
  • the table 500 may include any number of entries.
  • the table 500 also defines fields for each of the entries 502, 504, 506 and 508.
  • the fields specify (i) a vendor identifier 520 that uniquely identifies the vendor, (ii) a vendor name 522, (iii) a vendor e-mail address 524 for facilitating communication with the vendor, and (iv) an amount owed 526 to the vendor (e.g. promised but unpaid subsidy amounts) from a subsidizing vendor (or other party).
  • the data specified by the fields 522 and 524 may be received from the corresponding vendor (e.g. via the corresponding vendor server). For example, the data may be provided when the vendor registers with the controller 110 in the embodiment of FIG. IA.
  • the data specified by the field 526 may be increased as the vendor provides subsidy amounts and decreased as the vendor receives reimbursement (e.g. from a subsidizing vendor) for previously-provided subsidy amounts.
  • the controller 1 10 in the embodiment of FIG. 1 A, or the vendor server 160 in the embodiment of FIG. IB would generate a unique vendor identifier to store in the field 520 of the entry corresponding to the new vendor.
  • the new vendor may submit a value to be used as the vendor identifier. Once information is stored for a vendor, it may be retrieved upon reference to the appropriate vendor identifier.
  • a table 600 represents an embodiment of the transaction database 250 (FIG. 2) and/or the transaction database 350 (FIG. 3).
  • the table 600 includes entries 602, 604 and 606, each defining a transaction with a vendor server. Typically, the transaction includes a purchase of items by a customer. Those skilled in the art will understand that the table 600 may include any number of entries.
  • the table 600 also defines fields for each of the entries 602, 604 and 606.
  • the fields specify (i) a transaction identifier 620 that uniquely identifies the transaction, (ii) a vendor identifier 621 that identifies the vendor, (iii) a time 622 of the transaction, (iv) the items ordered 624, (v) credit card information 626 that may define a credit card account that was charged to pay for the items purchased, (vi) an amount charged 628 for the items, (vii) a delivery address 630 for the items, and (viii) a customer identifier 632 (if any) that identifies the customer that made the purchase.
  • the data specified by the fields 624, 626, 630 and 632 may be received via the corresponding customer terminal, while the data specified by the fields 620, 621, 622 and 628 may be generated by the corresponding vendor server.
  • the origination of the data specified by the various fields will depend on the particular embodiment of the present invention.
  • the items ordered may be identified by being scanned by a bar code scanner that transmits a representative signal to a POS terminal.
  • the items ordered may have been selected by a customer via a Web page displayed by his personal computer, or via a customer's telephone in communication with an IVRU.
  • Other ways to indicate items that the customer desires to purchase will be apparent to those skilled in the art.
  • the credit card information may be read by a card reader that transmits a representative signal to a POS terminal.
  • the credit card information may be entered by a customer into a form on a Web page that is displayed by his personal computer.
  • the credit card information may instead have been previously read, stored and retrieved from the customer database or a cookie stored on the customer terminal.
  • Other payment identifiers besides credit card information may be employed, such as debit card numbers or electronic cash identifiers.
  • the use herein of a credit card as a means of payment is merely exemplary and not limiting on the scope of the present invention.
  • a unique transaction identifier (field 620) may be generated and the time of the transaction (field 622) may be recorded (e.g. with reference to a clock signal generated by the customer terminal, vendor server, controller or other device).
  • the transaction identifier and the time are stored in the fields 620 and 622 respectively of the entry corresponding to the new transaction.
  • the data represented by an entry of the table 600 may be transmitted from the customer device to the controller 1 10 in the embodiment of FIG. IA, or to the vendor server 160 in the embodiment of FIG. IB.
  • a table 700 represents an embodiment of the subsidizer database 260 (FIG. 2).
  • the table 700 includes entries 702, 704 and 706, each defining a subsidizing vendor that may subsidize purchases or provide other benefits to customers of other vendors.
  • the data of an entry may be input, for example, when a subsidizing vendor registers for participation in the program described herein for providing offers for benefits.
  • the table 700 may include any number of entries.
  • the table 700 also defines fields for each of the entries 702, 704 and 706.
  • the fields specify (i) a subsidizing vendor identifier 720 that uniquely identifies the subsidizing vendor, (ii) a name 722 of the subsidizing vendor, (iii) an account 724 (if any) that is used to pay for the subsidies or other benefits, (iv) an amount owed 726 by the subsidizing vendor (e.g. in exchange for subsidies provided to customers on behalf of the subsidizing vendor), and (v) a rank 728 used to prioritize subsidizing vendors and/or subsidies provided by or on behalf of those subsidizing vendors.
  • the data specified by the fields 722 and 724 may be received from the corresponding subsidizing vendor (e.g. via the corresponding vendor server).
  • the data may be provided when the subsidizing vendor registers with the controller 110 in the embodiment of FIG. IA, or with the vendor server 160 in the embodiment of FIG. IB.
  • the controller 110 in the embodiment of FIG. IA, or the vendor server 160 in the embodiment of FIG. IB would generate a unique subsidizing vendor identifier to store in the field 720 of the entry corresponding to the new subsidizing vendor.
  • the new subsidizing vendor may submit a value to be used as the subsidizing vendor identifier.
  • the amount owed (field 726) is calculated and updated for each subsidizing vendor. Typically, the amount owed is increased when an offer from a particular subsidizing vendor is accepted by a customer, or when the corresponding subsidy is provided to the customer. The amount owed is likewise decreased when the subsidizing vendor repays the vendor which provided the subsidy amount.
  • the rank (field 728) of each subsidizing vendor is updated by the controller 110 according to a ranking scheme.
  • a subsidizing vendor may pay for a preferential rank, and/or rank may be determined by the number (or percentage) of corresponding offers from the subsidizing vendor that are accepted.
  • the ranks may be established periodically (e.g. once per year) or substantially continuously based on various criteria such as profitability to the vendor servicing the customer or to the entity operating the controller 110.
  • a table 800 represents an embodiment of the offer rules database 270 (FIG. 2).
  • the table 800 includes entries 802, 804, 806, 808 and 810, each defining, among other things, an offer rule.
  • the vendor provides an offer for a specified benefit, such as a subsidy.
  • the data of an entry may be input, for example, when a subsidizing vendor registers for participation in the subsidizing program described herein.
  • the table 800 may include any number of entries.
  • the table 800 also defines fields for each of the entries 802, 804, 806, 808 and 810.
  • the fields specify (i) an offer rule identifier 820 that uniquely identifies the offer rule, (ii) a subsidizing vendor identifier 822 that uniquely identifies the subsidizing vendor and that corresponds to a subsidizing vendor identifier of the subsidizer database 260, (iii) customer activity 824 (if any) that is required in order for an offer to be provided, (iv) a subsidy amount 826, (v) when the offer rule is effective 828 (i.e. other requirements in order to satisfy the offer rule), (vi) an additional transaction 830 (i.e. an obligation) that is required of the customer in exchange for the subsidy, (vii) an obligation expiration date / time 832 by which the obligation must be fulfilled (i.e.
  • the data may be provided when the subsidizing vendor registers with the controller 110 in the embodiment of FIG. 1 A, or with the vendor server 160 in the embodiment of FIG. IB.
  • the controller 110 in the embodiment of FIG. 1 A, or the vendor server 160 in the embodiment of FIG. IB would generate a unique offer rule identifier to store in the field 820 of the entry corresponding to the new offer rule.
  • the corresponding subsidizing vendor identifier would also be stored in the field 822.
  • the customer activity that is required in order for an offer to be provided may be set by the subsidizing vendor.
  • the required customer activity may be set for each subsidizing vendor by the controller 1 10 in the embodiment of FIG. IA, or the vendor server 160 in the embodiment of FIG. IB.
  • the subsidizing vendor may be unable to decide which type of customer activity should be required.
  • the required customer activity may be set and thereafter dynamically adjusted based on acceptance rates of provided offers.
  • the penalty field 834
  • respective portions of the penalty may be set by the controller 110 and the subsidizing vendor.
  • the subsidizing vendor may set a portion of the penalty amount to be equal to the subsidy amount, and the controller 110 may set the remaining portion of the penalty amount to be a $3 supplemental fee, as illustrated by the entry 804 and its respective field 834.
  • a table 900 represents an embodiment of the offers database 280 (FIG. 2).
  • the table 900 includes entries 902, 904, 906, 908 and 910, each defining an offer for a subsidy that was provided to a customer during a transaction with the vendor.
  • entries 902, 904, 906, 908 and 910 each defining an offer for a subsidy that was provided to a customer during a transaction with the vendor.
  • the table 900 may include any number of entries.
  • the table 900 also defines fields for each of the entries 902, 904, 906, 908 and 910.
  • the fields specify (i) an offer identifier 920 that uniquely identifies the offer, (ii) a transaction identifier 922 that uniquely identifies the transaction during which the offer was provided, (iii) a subsidizing vendor identifier 924 that uniquely identifies the subsidizing vendor on whose behalf the vendor provides the offer, (iv) an identifier of an offer rule 926 that was applied during the transaction, (v) when the offer was provided 928, (vi) an expiration date 930 (if any) for the offer, (vii) a subsidy amount 932, (viii) a total price 934 that the customer would have to pay without the subsidy, (ix) a total price 936 that the customer would have to pay with the subsidy, (x) when the offer was accepted 938 (if it was accepted), (xi) whether the obligation corresponding to the subsidy was fulfilled 940, (xii) an actual fulfill date 942 by which the obligation was fulfilled (if it was fulfilled), and (xiii) whether the obligation expiration date
  • the subsidy amount may be a fixed amount, such as $50.
  • the subsidy amount may further be dependent on various criteria such as the total price of the items. For example, the subsidy amount could be for the lesser of the total price and $50.
  • the subsidy amount could be for the lesser of a portion of the total price and $50.
  • the subsidy amount could be for the lesser of $50 and half the total price.
  • the data specified by the fields 928, 934, 936 and 938 may be received from the corresponding customer terminal for each offer that has been provided. For example, when the offer is provided a new entry of the table 900 may be created. At that time, the date and time that the offer was provided (field 928) may be recorded (e.g. with reference to a clock signal generated by the customer terminal, vendor server, controller or other device), and the total price (field 934) and the total price with the subsidy amount (field 936) may be received, e.g., from the POS terminal.
  • the field 938 of the new entry would initially be set to "open" to indicate that the offer is open (not yet accepted or rejected). The field 938 may be updated accordingly when an offer is rejected or accepted.
  • Fields 922, 924 and 926 of the new entry would be set to the appropriate identifiers upon reference to, e.g., the transaction identifier field 620, the subsidizing vendor identifier field 720 and the offer rule identifier field 820 respectively.
  • the offer expiration date could be calculated from the date and time when the offer was provided (field 928) (e.g. a predetermined time after the time in field 928 or "none" if there is no desired expiration date).
  • the subsidy amount (field 932) is determined from the corresponding offer rule applied, as described above with respect to field 826. Whether the obligation was fulfilled (field 940) for the new entry would initially be set to "NO" to indicate that the corresponding obligation has not yet been fulfilled.
  • the field 940 may be updated accordingly when an obligation is fulfilled, or "partially fulfilled” (e.g. some but not all required acts have been performed).
  • the actual fulfill date (field 942) of the new entry would initially be set to "N/A" ("not applicable") to indicate that the obligation has not been fulfilled. If the obligation is fulfilled, the date and time when it is fulfilled is recorded and stored in field 942. Whether the obligation expiration date has passed (field 944) for the new entry would initially be set to "NO" to indicate that the obligation expiration date has not yet passed. Periodically the controller 110 may determine whether the current date and time is after any obligation expiration date of the entries. If so, and if the corresponding obligation has not been fulfilled, then the field 944 is set to "YES". If the corresponding obligation is fulfilled before the obligation expiration date, the field 944 is set to "N/A" to indicate that the obligation was fulfilled within the required time period.
  • the controller 110 in the embodiment of FIG. 1 A, or the vendor server 160 in the embodiment of FIG. IB would generate a unique offer identifier to store in the field 920. Once information is stored for an offer, it may be retrieved upon reference to the appropriate offer rule identifier.
  • a table 1000 represents a record of an embodiment of the offer summary database 290 (FIG. 2).
  • the offer summary database 290 would typically include a plurality of records, each record defining a summary of offers for subsidies that have been provided on behalf of a particular subsidizing vendor.
  • the table 1000 includes a subsidizing vendor identifier
  • the table 1000 also includes entries 1010 and 1012, each defining offers provided due to satisfaction of a particular offer rule of the subsidizing vendor. Those skilled in the art will understand that the table 1000 may include any number of entries.
  • the table 1000 also defines fields for each of the entries 1010 and 1012.
  • the fields specify (i) an offer rule identifier 1020 that uniquely identifies the offer rule, (ii) a number 1022 of offers provided due to satisfaction of the offer rule, (iii) a number 1024 of these offers that were accepted, (iv) a number 1026 of these offers that are reneged offers, and (v) an amount 1028 of the subsidies due in connection with the accepted offers.
  • the information stored in the offer summary database 290 may be organized in other ways, such as by the vendor through which the offer was provided. Such an embodiment would allow a comparison of the acceptance rate of offers at different vendors.
  • the controller 110 in the embodiment of FIG. 1 A, or the vendor server 160 in the embodiment of FIG. IB would create a record such as the record 1000 and store the appropriate subsidizing vendor identifier 1002.
  • a corresponding entry is created and the offer rule identifier is stored in field 1020 of the entry.
  • the data specified by the fields 1022, 1024, 1026 and 1028 may be adjusted as offers are provided, as acceptances of the offers are received and as reneges of offers are detected. For example, when an offer is provided, the corresponding offer rule is identified and thus the corresponding entry is identified.
  • the field 1022 of that entry is increased by one to reflect the newly provided offer.
  • field 1024 of that entry is increased by one to reflect the new acceptance and the amount of the subsidy associated with the accepted offer is added to the field 1028 of the entry. If an obligation is not fulfilled, the field 1026 of the appropriate entry is adjusted accordingly.
  • the sum for all entries of the number of offers (indicated by the field 1022) is stored as the total number of offers 1004 for the corresponding record.
  • the sum for all entries of the number of offers accepted (indicated by the field 1024) is stored as the total number of offers accepted 1006 for the corresponding record;
  • the sum for all entries of the number of reneged offers (indicated by the field 1026) is stored as the total number of reneged offers 1008 for the corresponding record;
  • the sum for all entries of the amount of subsidies due (indicated by the field 1028) is stored as the total amount of subsidies 1009 for the corresponding record.
  • a table 1100 represents an embodiment of the item database 340 (FIG. 3).
  • the table 1100 includes entries 1102 and 1104, each defining an item sold via a vendor server. Those skilled in the art will understand that the table 1100 may include any number of entries.
  • the table 1100 also defines fields for each of the entries 1102 and 1104. The fields specify (i) an item identifier 1120 that uniquely identifies the item, (ii) an item description 1122, (iii) an item price 1124 for which the item is typically sold, and (iv) an availability 1126 of the item which may be based on an inventory level of the item. For each entry of the table 1100, the data specified by the fields 1122,
  • the data may be provided when a vendor prepares to sell the item, and adjusted as the vendor receives new inventory and sells existing inventory.
  • the vendor server Upon the entering of a new item, the vendor server would generate a unique item identifier to store in the field 1120 of the entry corresponding to the new item. Once information is stored for an item, it may be retrieved upon reference to the appropriate item identifier.
  • a flow chart 1200 illustrates an embodiment of a method for providing an offer for a benefit (e.g. a reduced price) to a customer that is to purchase items from a vendor.
  • a benefit e.g. a reduced price
  • the illustrated method is described below as being performed by the controller 110 in the embodiment of FIG. 1 A, the illustrated method may alternatively be performed, e.g., by the vendor server 160 in the embodiment of FIG. IB.
  • An indication of items a customer is to purchase from a first vendor is received (step 1202), typically from a customer terminal.
  • Such an indication may be received via a Web server, for example, in an embodiment where the first vendor sells via the Internet.
  • the Web server which may be the vendor server, may receive data from the customer terminal, and such data would indicate, for example, item identifiers of items selected for purchase, hyperlinks that the customer clicks on, buttons that the customer actuates, mouse movements or other data input to the customer terminal.
  • the indication of items to purchase may be received from a "cookie" stored on the customer terminal (e.g. on a personal computer of the customer). Such a cookie is a block of data that a Web server (e.g.
  • the vendor server stores on a client system (e.g. a customer terminal).
  • a client system e.g. a customer terminal
  • the browser of the customer terminal sends a copy of the cookie back to the Web server.
  • Cookies may be used to identify users of the customer terminal, to instruct the Web server to send a customized version of a Web page, to submit account information for the user, and for other administrative purposes.
  • the data stored in the cookie may also indicate, for example, the customer identifier and whether the customer is barred from receiving further offers.
  • the indication of items to purchase may be received via a telephone, for example, in an embodiment where a vendor sells via an IVRU.
  • the information may also be received via a POS terminal, for example, in an embodiment where a vendor sells at a retail store.
  • the POS terminal receives data such as Universal Product Codes ("UPC") that identify items scanned with a bar code scanner, prices of those items, and information received from a customer's frequent shopper card.
  • UPC Universal Product Codes
  • the information may be received via a device, such as a PDA (Personal Digital Assistant) or a scanner mounted on a shopping cart, that the customer uses to indicate the items he has selected for purchase or the items in which he his otherwise interested.
  • PDA Personal Digital Assistant
  • the indication of items to purchase may also be received via a sensor that senses the presence or location of a customer.
  • a sensor that senses the presence or location of a customer.
  • infrared or pressure sensors may be disposed in a store and operable to sense when a customer is near particular products or areas.
  • the indication of items to purchase may also be received via a device that scans items with a bar code scanner and provides the prices of those items that are scanned. Such devices are known and are frequently located in supermarkets to allow customers to determine the prices of items, especially items that are on sale or otherwise subject to special pricing.
  • An offer for a subsidy from a second vendor is selected (step 1204). For example, in an embodiment where one or more rules (and thus one or more subsidies) are included, if a rule is satisfied then a corresponding offer for a subsidy is provided.
  • a subsidizing vendor may be selected from a plurality of subsidizing vendors, and a subsidy from the selected subsidizing vendor is selected and offered. Rules may specify which subsidizing
  • the subsidy may be selected based on the items to purchase. For example, a rule may specify the following required customer activity in order for a particular offer to be provided: the customer must purchase a particular item or items. Similarly, the customer may be required to purchase one or more items that have a particular price (e.g. a price greater than $10.00) in order for a particular offer to be provided.
  • a particular price e.g. a price greater than $10.00
  • the subsidy may also be selected based on the total price and the subsidy amount of the subsidy.
  • the subsidy may be selected such that the subsidy amount is close to (e.g. within $5 of) the total price of the items.
  • an overly generous subsidy amount is not provided (e.g. a $500 subsidy amount for a $100 total price), and a subsidy amount that is too small to cover the total price of the items is also not provided (e.g. $10 subsidy amount for a $100 total price).
  • the subsidy is selected based on the amount of funds requested (e.g. the total price).
  • the benefit may but need not be a subsidy amount, those skilled in the art will understand that other types of benefits may be based on various factors such as the items the customer desires to purchase, the prices of the items or the total price of the items.
  • the benefit may comprise a "product upgrade", such that the customer receives different items than the ones he selected to purchase.
  • the benefit may comprise a free or discounted item that is separate from those the customer initially selected to purchase.
  • An indication of the offer is transmitted to the customer (step 1206), typically via the customer terminal and a corresponding offer is created in the offers database 280.
  • a corresponding offer is created in the offers database 280.
  • text and or images may be displayed on a Web page that is displayed on the customer terminal, text may be displayed on a monitor of a POS terminal, or an audio signal may be transmitted via an INRU to a telephone.
  • the indication of the offer is transmitted before the items are purchased. Such an embodiment can be advantageous by "surprising" the customer with an unexpected benefit.
  • the indication of the offer may be transmitted after the items are purchased. Such an embodiment can be advantageous in environments where it is not practical or desirable to interject with an offer before a transaction is completed.
  • the indication of the offer may be transmitted via a device, such as a PDA (Personal Digital Assistant) or a display mounted on a shopping cart of the customer, that accompanies the customer as he browses a store.
  • a display disposed in a particular location in the store e.g. below a product display
  • the indication of the offer may be transmitted via a device that scans items with a bar code scanner and provides the prices of those items scanned.
  • a device could display an offer upon scanning the bar code of an item.
  • a plurality of offers instead of only one, may be provided to the customer.
  • the plurality of offers may be for subsidies from one or more subsidizing vendors.
  • the customer may accept one or more of the offers.
  • the customer may thus obtain a plurality of benefits from a plurality of different subsidizing vendors. For example, the customer may accept a plurality of offers in order to receive an aggregate subsidy amount that equals or exceeds an amount that is requested / desired by the customer.
  • the offer specifies a subsidy amount and an obligation to fulfill in exchange for the subsidy amount.
  • an additional transaction may be required of the customer.
  • the customer may be required to sign up for a service that is provided by the subsidizing vendor (e.g. initiate a service agreement with the second vendor). The customer may be required to switch from a current service provider to the subsidizing vendor, so that the service will no longer be provided by the customer's current service provider.
  • Examples of services include telephone service, Internet service, banking services, credit card account services, insurance service, securities trading service, utilities service, satellite television service, and cable television service, but many other services may be provided by the subsidizing vendor.
  • Telephone service can include long distance service such as is provided by Sprint Communications Company, L.P or wireless telephone service such as is provided by AT&T.
  • Signing up for banking services may further include the requirement to transfer a particular minimum balance to a new bank account.
  • Signing up for credit card account services may similarly include the requirement to apply for a credit card account and also transfer a particular minimum balance to a new or existing credit card account.
  • Signing up for securities trading services may include the requirement to open an account with a particular minimum balance amount.
  • the additional transaction may involve an existing account.
  • the customer may be required to transfer a particular minimum balance to an existing credit card account, savings account or checking account.
  • the customer may be required to execute a minimum number of trades using his securities trading account.
  • the additional transaction may be the purchase of one or more items.
  • the customer may be required to buy a particular item or a minimum dollar amount of items from the subsidizing vendor or another predetermined vendor.
  • the additional transaction may be the sampling of one or more items.
  • the customer may be required to test drive a particular vehicle or download software on a trial basis.
  • the additional transaction may include listening to and/or viewing an advertisement, participating in a survey or otherwise providing information, refraining from a particular activity, or installing particular software.
  • a response to the offer is then received from the customer terminal (step
  • the customer may indicate his response by, for example, clicking a button on a
  • Web page actuating particular keys on a touch-tone telephone, verbally responding via a telephone to an JNRU, actuating a button on a keypad in communication with a POS terminal, or verbally responding to a cashier who in turn actuates buttons on the POS terminal.
  • step 1210 and 1212 If the response does not indicate an acceptance of the offer, then the transaction with the customer is processed conventionally (steps 1210 and 1212).
  • the credit card number may have been received at any time, although FIG. 12 illustrates an embodiment in which the credit card number is received following acceptance of the offer. For example, the credit card number may have been received before the offer for the subsidy was transmitted.
  • the received credit card number may be used to pay for the items and/or to pay a penalty amount if the customer subsequently fails to fulfill his obligation.
  • the customer may be required to provide more than one credit card number, (ii) it may be required that the credit card number identifies an account that has been open for a predetermined amount of time, and/or (iii) it may be required that the credit card number identifies an account that has been used a predetermined number of times.
  • the items are provided to the customer for less than the total price of the items (step 1216). Thus the customer is charged a lower price for the items than he otherwise would have been charged.
  • the customer may even receive the items for free and or receive a credit (e.g. money back or store credit).
  • the benefit to the customer may be different than a reduced price on the items he desires to purchase.
  • the customer may be given a product upgrade to another (higher value) item or the customer may be given an additional item for a reduced price or for free.
  • the customer may also be provided with cash, store credit or another monetary award.
  • the obligation to fulfill in exchange for the subsidy typically includes an obligation expiration date by which the obligation must be fulfilled. If the customer has not fulfilled his obligation by any applicable obligation expiration date, a penalty is applied (steps 1218 and 1220).
  • An entry is created in the transaction database 250 to reflect, e.g., the time of the transaction, the items ordered, and the amount charged.
  • the corresponding entry of the offers database is updated to reflect, e.g. whether the offer was accepted.
  • a flow chart 1300 illustrates an embodiment of a method for providing items for less than their total price, described above with respect to step 1216.
  • the illustrated method is described below as being performed by the controller 110 in the embodiment of FIG. IA, the illustrated method may alternatively be performed, e.g., by the vendor server 160 in the embodiment of FIG. IB.
  • the subsidy amount of the selected subsidy is determined (step 1302).
  • the 280 (FIG. 2) is accessed to determine the subsidy amount (e.g. with reference to the field 932 of FIG. 9).
  • the total price of the items is charged to the specified credit card account (step 1304), and the subsidy amount is credited to the credit card account (step 1306).
  • the credit card account is charged $60 for the items by (i) a charge of $80 in a first credit card account adjustment, and (ii) a credit of $20 in a second credit card account adjustment.
  • the crediting may, but need not, be performed after the charging.
  • the crediting may be performed after the charging in order to, for example, assure that a line item for the charged amount (e.g. $80 in the above example) appears above a line item for the credited amount (e.g. $20 in the above example).
  • the credit to the credit card account is initiated by transmitting credit data to a credit card clearinghouse.
  • the credit data includes, among other things, the amount of the credit, the credit card account number and a "merchant identifier" of the merchant (e.g. the vendor) initiating the charge.
  • the credit data may further include a unique offer identifier, such as is stored in field 920 for the corresponding entry of the offers database 280, that identifies the offer.
  • the offer identifier may be printed on the customer's credit card bill, allowing the customer to identify the offer (e.g. to assure that a subsidy amount was in fact applied or to request information regarding the offer).
  • the transaction between the customer and the vendor is marked as paid in full (step 1308) since customer has paid the amount required. Accordingly, conventional actions such as printing a receipt for the transaction (if at a POS terminal) or initiating delivery of the items (if ordered remotely via a Web site) may be performed once the transaction is paid in full.
  • the embodiment illustrated in FIG. 13 is only one of several embodiments.
  • the customer may be charged in a single credit card account adjustment, rather than in two as is described in FIG. 13. For example, if the items the customer desires to purchase are $80, and a subsidy amount for the subsidy is $20, the specified credit card account may be charged $60 in a single credit card account adjustment.
  • a flow chart 1400 illustrates an embodiment of a method for determining whether a customer has fulfilled his obligation described above with respect to step 1218.
  • the illustrated method is described below as being performed by the controller 110 in the embodiment of FIG. 1 A, the illustrated method may alternatively be performed, e.g., by the vendor server 160 in the embodiment of FIG. IB.
  • a signal is received, and the signal represents a fulfillment code and an offer (step 1402).
  • the signal may be received from, e.g., the subsidizing vendor server or the customer terminal.
  • the customer may receive the fulfillment code after he has fulfilled his obligation, and in turn input the code to the central controller, e.g., via a voice response unit, email message or a form on a Web site.
  • the customer's terminal may also have a stored file (e.g. a cookie) that stores the fulfillment code and that is read by the controller 110 when the customer accesses a particular Web site.
  • the fulfillment code may have been stored in the cookie after the customer fulfilled an obligation online. In such an embodiment, the customer would need only access a Web site, rather than enter the fulfillment code himself.
  • the subsidizing vendor server may input the code to the central controller, e.g., via a Web site, email message or a voice response unit when the customer fulfills his obligation.
  • the fulfillment code may be anything that indicates that the customer has fulfilled his obligation.
  • the fulfillment code may be a set of numeric or alphanumeric characters that are recognized as indicating fulfillment of the obligation.
  • the fulfillment code in such an embodiment will ideally be difficult to forge, and will not be useful if it is copied and used again by the same customer or by another party.
  • One method for generating a code which may be used as a fulfillment code is to encrypt one or more data elements to generate an encrypted value.
  • Such methods are known to those skilled in the art, and are disclosed, for example, in commonly-owned, U.S. Patent Application Serial No. 08/919,339, entitled “METHOD AND DEVICE FOR GENERATING A SINGLE-USE FINANCIAL ACCOUNT NUMBER", filed August 28, 1997, incorporated by reference herein as part of the present disclosure.
  • an offer identifier, a subsidizing vendor identifier, a private key and/or a random number may be encrypted to generate a fulfillment code.
  • the central controller 110 may store a database that records which fulfillment codes have been received.
  • the controller 110 may detect such duplicate use (known as a "replay attack") and refuse to recognize the corresponding obligation as fulfilled.
  • Encrypting data to generate the fulfillment code also permits that data to be determined from the fulfillment code. For example, if the fulfillment code is generated by encrypting the offer identifier, then the offer identifier may be determined by decrypting the fulfillment code, as is also described in the above-referenced patent application. Accordingly, the fulfillment code may indicate any data that may be useful in determining whether an obligation has been fulfilled, such as the customer identifier and the corresponding obligation expiration date.
  • Another method for generating a code that may be used as a fulfillment code is to select a code from a set of predetermined codes. Such methods are also described in the above-referenced patent application. For example, there may be a database of hundreds of unique codes. When a code is needed, one is selected from the database, and is marked in the database as unavailable for future use. Thus, a code in the database is not reused when there are other codes that have not yet been selected.
  • the received signal represents a fulfillment code and an offer.
  • the signal may represent the fulfillment code, which in turn indicates an offer
  • the signal may represent the fulfillment code and the offer separately.
  • the offer may be represented by the corresponding offer identifier, which can be either separate from the fulfillment code or ascertainable from the fulfillment code.
  • Each subsidizing vendor server may be operable to generate fulfillment codes in accordance with any of the above-described methods. For example, each subsidizing vendor may generate a fulfillment code and provide that fulfillment code to a customer when that customer fulfills his obligation. Alternatively, the subsidizing vendor may generate a fulfillment code and provide that fulfillment code to the central controller 110. From the received signal, the corresponding entry of the offers database
  • the received signal may indicate an offer identifier, and thus the entry of the offers database 280 that includes this offer identifier in the corresponding field 920 may be identified.
  • the obligation expiration date may be determined. If it is determined that the obligation expiration date has passed (step 1406), then the identified entry is updated accordingly (step 1408). For example, the entry may be updated to show that the obligation was not fulfilled and that the obligation expiration date has passed by modifying the data stored in fields 940 and 944 respectively.
  • the fulfillment code may be validated to determine whether the obligation was fulfilled. As described above, in one embodiment the fulfillment code may be decrypted to yield one or more data elements of interest. Thus, the fulfillment code may show that the obligation was fulfilled if, for example, (i) a valid data element is produced from such decryption, (ii) the data element indicates a customer identifier that matches a customer identifier input by the customer, (iii) the data element indicates a vendor identifier that matches a vendor identifier input by the customer, and/or (iv) the data element indicates a date (e.g. when the obligation was fulfilled) that matches a date input by the customer.
  • the fulfillment code may show that the obligation was fulfilled if, for example, (i) the fulfillment code is determined to match any of the codes that were stored in the database, (ii) the fulfillment code is determined to not have been redeemed previously, and/or (iii) the fulfillment code is determined to be a code that was stored in the database which the particular subsidizing vendor could access.
  • the controller 110 transmits a message (step 1412) indicating that the fulfillment code is invalid.
  • the message may be transmitted to the party from which the signal was received in step 1402. For example, if the customer had logged onto a Web page to transmit the fulfillment code to the controller 110, then the controller 110 may in turn transmit the message via a Web page displayed to the customer.
  • the controller 110 updates the entry (step 1414) of the offers database 280 that was identified in step 1404. For example, the entry may be updated to show that the obligation was fulfilled and the date and time that the obligation was fulfilled by modifying the data stored in fields 940 and 942 respectively.
  • controller 110 may generate an HTML form and present that form to the customer via a Web page.
  • the form may be presented in a "frame" of his browser, so the customer may view a plurality of Web sites (e.g. Web sites of the vendor and the subsidizing vendor) simultaneously.
  • the customer would in turn input information via that form, and the information would be received by the controller 110.
  • the controller would be able to easily determine if and when the customer has fulfilled his obligation.
  • a cookie storing the fulfillment code could be stored on the customer terminal, and that cookie could be read when the customer terminal accesses a
  • controller 110 may determine a service provider that currently provides a service to the customer. For example, the controller 110
  • the controller 110 may access a database of customers of the subsidizing vendor, or may query the subsidizing vendor to receive an indication of whether a particular customer is serviced by the subsidizing vendor. The controller may thus determine whether the service in question is provided by the subsidizing vendor.
  • a subsidizing vendor may itself determine that the customer has not fulfilled his obligation by the obligation expiration date, and then inform the controller 110 or corresponding vendor that serviced the customer.
  • the subsidizing vendor may also apply the penalty instead of the controller
  • the controller 110 may instead receive an indication that the customer has switched service providers. For example, the controller 110 may access a database to determine new customers (e.g. signed up within the past thirty days) of the subsidizing vendor. From this database, the controller 110 may determine if any of the new customers had been offered a subsidy. If so, and if the subsidy included an obligation to switch service providers to this subsidizing vendor, then it is determined that these new customers have fulfilled their obligation.
  • the controller 110 may access a database to determine new customers (e.g. signed up within the past thirty days) of the subsidizing vendor. From this database, the controller 110 may determine if any of the new customers had been offered a subsidy. If so, and if the subsidy included an obligation to switch service providers to this subsidizing vendor, then it is determined that these new customers have fulfilled their obligation.
  • the customer's actions may be similarly monitored to determine whether his obligation is fulfilled.
  • the controller 110 may request information on the transactions the customer participated in with the subsidizing vendor.
  • the appropriate subsidizing vendor server can respond with, e.g., data from its transaction database that indicate such transactions.
  • the subsidizing vendor may alternatively provide the controller 110 with access to its transaction database, which is searched by the controller 110.
  • the controller 110 may thus determine whether the customer has purchased from the subsidizing vendor at least a predetermined number of times during the predetermined period of time. For example, the obligation may be to purchase five or more times this month from the subsidizing vendor. Similarly, the controller 110 may determine whether the customer has purchased from the subsidizing vendor at least a predetermined number of times during each of a plurality of predetermined periods of time. For example, the obligation may be to purchase five or more times from the subsidizing vendor during each month of this year.
  • a flow chart 1450 illustrates an embodiment of a method for determining whether obligation expiration dates have passed without a corresponding obligation having been fulfilled.
  • the illustrated method may be performed periodically, such as once at the end of each day, in order to determine which obligations have not been fulfilled by their respective obligation expiration dates.
  • an appropriate penalty maybe assessed (if appropriate), the customer may be reminded of his obligation, or the customer may be encouraged to fulfill the obligation.
  • the illustrated method is described below as being performed by the controller 110 in the embodiment of FIG. 1 A, the illustrated method may alternatively be performed, e.g., by the vendor server 160 in the embodiment of FIG. IB.
  • the controller 110 selects an entry in the offers database 280 (step 1452). For example, the controller may select the first entry in the offers database 280. From the entry, it is determined whether the corresponding obligation has been fulfilled (step 1454). For example, the field 940 of the entry indicates whether the corresponding obligation was fulfilled. If the corresponding obligation has been fulfilled, then it is determined whether there are more entries to select (step 1462). If so, another entry is selected (step 1452), for example, the next entry stored sequentially in the offers database 280.
  • the corcesponding obligation has not been fulfilled, then it is determined whether the corresponding obligation expiration date has passed (step 1456).
  • the obligation expiration date is stored in field 832 of the selected entry, and the current date may be determined with reference to a signal received from an internal clock device or an external reference. If the current date is after the obligation expiration date, then the obligation expiration date has passed.
  • a penalty is applied (step 1458) as described herein. If the obligation expiration date has not passed, then the controller 110 can, if desired, transmit a message to the customer (step 1460).
  • the message may be transmitted, for example, via email, via a Web site when the customer next accesses the Web site or via a telephone INRU.
  • the message may indicate, for example, the obligation expiration date and the amount by which the customer has "partially fulfilled" the obligation.
  • Such a message can serve to both remind the customer of his obligation and inform him of what remains to be done to fulfill his obligation. For example, if an obligation involves ten periodic actions (e.g.
  • the "partial fulfillment" of the obligation can be the number (less than ten) that the customer has performed to date. If it is unlikely that a customer will fulfill his obligation, other appropriate actions may be taken.
  • Each additional entry of the offers database 280 is selected and processed as described above.
  • the above-described message may also be transmitted in response to an inquiry from a customer.
  • the customer may input his customer identifier to the controller 110 via a Web page.
  • the controller 110 in turn responds by displaying a Web page that specifies each obligation of the customer, the corresponding obligation expiration date and the amount by which the customer has partially fulfilled the obligation.
  • a customer may check his record of compliance with obligations.
  • the above-described message may also be provided to the customer in subsequent transactions. Such a message would remind the customer of previous obligations and thus the need to fulfill future obligations.
  • a flow chart 1500 illustrates an embodiment of a method for applying a penalty, described above with respect to step 1220.
  • the illustrated method is described below as being performed by the controller 110 in the embodiment of FIG. IA, the illustrated method may alternatively be performed, e.g., by the vendor server 160 in the embodiment of FIG. IB.
  • a penalty amount is determined (step 1502) in any of a number of ways.
  • the penalty amount may be the difference between the total price and the price charged for the items.
  • the penalty amount could equal the sum of the subsidy amount (or a portion thereof) and a supplemental fee. Referring again to the above example, $5 could be added to the $20 subsidy amount to produce a $25 penalty amount. The $5 supplemental fee serves to more strongly deter reneging, since the customer would be in a worse position than if he had never accepted the offer for the subsidy.
  • the subsidizing vendor may select how the penalty amount is calculated. For example, the subsidizing vendor may opt to have a $10 supplemental fee included, and may further opt to apply the same penalty amount regardless of the degree to which the obligation has been partially fulfilled. Alternatively, controller
  • the customer or the vendor from which the customer originally purchased the items may select how the penalty amount is calculated.
  • the credit card account number to which the penalty amount is to be charged is also determined (step 1504).
  • the appropriate entry of the offers database 280 specifies a transaction identifier in field 922.
  • the transaction identifier indicates an entry of the transaction database 250 that may specify credit card information in field 626.
  • the entry of the transaction database 250 may specify a customer identifier in field 632.
  • the customer identifier can indicate an entry of the customer database 230, which in turn may specify credit card information in field 426.
  • the two fields 626 and 426 may each specify a different credit card account.
  • each entry of the customer database 230 may store in field 426 a credit card account that the customer desires to use as a default credit card account, while each entry of the transaction database 250 may store in field 626 a credit card account that was actually used by the customer in a transaction. Accordingly, the penalty amount may be charged to the credit card account that was actually used by the customer in a transaction, or to a default credit card account.
  • the penalty amount is charged to the credit card account (step 1506).
  • the charge to the credit card account is initiated by transmitting charge data to a credit card clearinghouse.
  • the charge data includes, among other things, the amount of the charge and the credit card account number.
  • the charge data may further include a unique offer identifier, such as is stored in field 920 for the corresponding entry of the offers database 280, that identifies the offer.
  • the offer identifier may be printed on the customer's credit card bill, allowing the customer to identify the offer (e.g. to request information regarding the offer).
  • the controller 110 may charge an account of the vendor from which the customer originally purchased the items. Such a charge is useful where it is necessary to provide that vendor with an incentive to only provide offers to customers that are unlikely to renege. Since the vendor is penalized if the customer reneges, the vendor will typically take steps if possible to reduce offers given to customers that may, or are likely to, renege.
  • a credit card account may be used in applying a penalty.
  • another account such as a debit account or an escrow account may be charged.
  • a customer may be sent a bill (e.g. via postal mail or electronic mail) for a penalty amount.
  • the penalty is described as a charge to a credit card account, the present invention encompasses further types of penalties.
  • the penalty may include withholding provision of the items to the customer until the customer has fulfilled the obligation. For example, appropriate "ship now" commands to the shipping department or entity responsible for delivery can be suppressed or delayed until the obligation is fulfilled. Alternatively, the shipping department or entity responsible for shipping can be instructed to await instructions before shipping.
  • the penalty may include having the customer accept another offer for a subsidy.
  • the controller 110 could transmit to the customer an indication of a second offer for a second subsidy from the subsidizing vendor.
  • the second offer would define a second obligation, which may or may not be the same as the first obligation of the original offer. When the customer accepts the second offer, the first obligation could be deemed fulfilled. If the customer does not accept the second offer, another penalty (e.g. a penalty amount charged to his credit card account) could be applied.
  • the penalty may include preventing the customer from receiving offers for subsidies (or particular categories of offers for subsidies) in the future.
  • the controller 110 may adjust the field 430 of the appropriate entry of the customer database 230.
  • the penalty may include preventing the customer from making purchases from the vendor that provided the customer with the items.
  • the penalty may include disabling one or more of the items purchased in order to deprive the customer of the use of the items.
  • the controller 110 can prevent the software from operating, e.g., by transmitting a code that prevents the software from being executed, by refusing to transmit a code required to reactivate expired software or by refusing to allow the software to access a required Web site.
  • a billing statement 1600 illustrates the effect of various subsidy amounts and penalties on a customer's credit card account.
  • the billing statement 1600 is provided for purposes of illustration only.
  • the billing statement 1600 includes indicia 1602 and 1604 that indicate the customer name and the credit card account number respectively.
  • the billing statement 1600 also includes indicia 1610, 1612, 1614 and 1618 that each indicates a credit card account adjustment (e.g. a charge or a credit to the credit card account).
  • Each such credit card account adjustment includes a field for (i) a date 1620 of the credit card account adjustment, (ii) a description 1622 of the credit card account adjustment, and (iii) an amount 1624 of the charge or credit.
  • each charge amount is shown as a positive value and each credit amount is shown as a negative value.
  • the indicia 1610 and 1612 indicate credit card account adjustments that occur when the customer purchases items from a first vendor ("Amazon.com®").
  • the indicia 1610 indicate a charge for the total price of the items ("$25.00"), and the indicia
  • the indicia 1612 indicate a credit for the subsidy amount ("-$25.00"). Since the charge of $25.00 is equal in magnitude to the credit of $25.00, the net effect is that the customer is charged $0 for the items. Thus the items are provided to the customer for free.
  • the indicia 1612 also indicate an offer code "12345678" that uniquely identifies the offer for the subsidy amount, which the customer has accepted.
  • the indicia 1614 and 1616 indicate credit card account adjustments that occur after a penalty is applied.
  • the indicia 1614 indicate a charge for the difference between the total price of the items ($25.00) and the price charged for the items ($0). The difference is the subsidy amount of $25.00, which was indicated previously by the indicia 1612.
  • the charge indicated by the indicia 1614 serves to "reverse" the subsidy amount previously given to the customer.
  • the indicia 1616 indicate a charge for a supplemental fee of $5.00.
  • the net effect of the credit card account adjustments ($30) is a charge greater than the charge for the total price of the items ($25).
  • Amounts collected in connection with applied penalties may be provided to the respective subsidizing vendors to compensate them for subsidy amounts they provided.
  • other parties besides the subsidizing vendor may receive a portion or all of the penalty amounts.
  • the entity operating or controlling the central controller may receive, e.g. the portion of the penalty amount that is in excess of the original subsidy amount.
  • Such amounts may themselves be provided as subsidy amounts to the same or other customers.
  • a customer of an on-line book vendor selects three books having a total price of $80.
  • the customer is presented with an offer via a Web page.
  • the offer specifies that the customer may receive the three books for free if he agrees to sign up within a week for at least six months of AT&T long distance telephone service.
  • the customer accepts and signs up for the service within a week. However, he cancels the service after three months. His credit card account is charged $40 (half of the subsidy amount). Alternatively, his last long distance telephone bill could include the $40 charge.
  • a customer in a retail store brings $30 of items to a POS terminal.
  • the customer is presented with an offer via the POS terminal, which is read to him by the cashier operating the POS terminal.
  • the offer specifies that the customer may receive the items for free and also receive a $10 gift certificate if he agrees to rent one video tape per week at Blockbuster® for the next two months.
  • a customer withdrawing cash from his bank account via an ATM is provided with an extra $10 if he agrees to immediately participate in a survey at the ATM.
  • a customer accessing an online car magazine is offered a free subscription in exchange for test driving a particular vehicle from a particular car dealer. After accepting the offer, the customer is provided a unique twelve-digit code. The customer does test drive the required vehicle, and provides the car dealer with the twelve-digit code. The car dealer in response enters the customer's twelve-digit code and the car dealer's own ten-digit code into a particular Web site used for verifying obligation fulfillment. The car dealer prints a receipt for the customer to show that the car dealer did in fact verify fulfillment of the obligation.
  • a customer of an on-line vendor receives an offer for a discount off of his purchase if he agrees to install a plug in to his browser that directs the browser to display banner advertisements of a particular Web site.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Une unité de commande reçoit l'indication des articles qu'un client doit acheter à un premier vendeur. Ces articles possèdent un prix total associé, tel que la somme de leurs prix de vente au détail et de toutes taxes pouvant être appliquées. En réponse à l'indication reçue, l'unité de commande transmet l'indication d'une offre d'avantage provenant d'un deuxième vendeur. Cet avantage peut, par exemple, consister en un rabais, de sorte qu'on peut acheter les articles à un prix inférieur au prix total. L'offre définit également une obligation que le client doit remplir en échange de l'avantage. Par exemple, le client peut être obligé de participer à une autre transaction avec le deuxième vendeur. A réception de l'indication que le client accepte l'offre, ce dernier peut acquérir les articles à un prix inférieur au prix total. On détermine ensuite si le client a rempli l'obligation. Si ce n'est pas le cas, on applique une pénalité. Par exemple, un compte de carte de crédit du client peut être débité afin de compenser le montant du rabais accordé précédemment.
PCT/US1999/030504 1998-12-23 1999-12-21 Procede et dispositif servant a produire des avantages et des penalites croises WO2000039727A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU27125/00A AU2712500A (en) 1998-12-23 1999-12-21 Method and apparatus for providing cross benefits and penalties

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US09/219,267 1998-12-23
US09/219,267 US7831470B1 (en) 1996-09-04 1998-12-23 Method and apparatus for facilitating electronic commerce through providing cross-benefits during a transaction
US32235199A 1999-05-28 1999-05-28
US09/322,351 1999-05-28

Publications (2)

Publication Number Publication Date
WO2000039727A2 true WO2000039727A2 (fr) 2000-07-06
WO2000039727A8 WO2000039727A8 (fr) 2001-11-01

Family

ID=26913722

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/030504 WO2000039727A2 (fr) 1998-12-23 1999-12-21 Procede et dispositif servant a produire des avantages et des penalites croises

Country Status (2)

Country Link
AU (1) AU2712500A (fr)
WO (1) WO2000039727A2 (fr)

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
No Search *

Also Published As

Publication number Publication date
AU2712500A (en) 2000-07-31
WO2000039727A8 (fr) 2001-11-01

Similar Documents

Publication Publication Date Title
US9697553B2 (en) Method and apparatus for providing cross-benefits based on a customer activity
US8781889B2 (en) System for providing offers using a billing statement
US8571943B2 (en) Systems and methods for providing transferable item prices
US7774240B2 (en) Methods wherein a security deposit facilitates a transaction in which a benefit is applied in exchange for performance of a task
US8706632B2 (en) Method and apparatus for processing credit card transactions
US20020169664A1 (en) System for providing offers using a billing statement
US20020147663A1 (en) Systems and methods for facilitating a transaction by use of third party subsidies
US8473341B1 (en) System to provide price adjustments based on indicated product interest
US20080288340A1 (en) System and method for providing a pre-paid rebate card
WO2000039720A1 (fr) Procede et appareil servant a generer des benefices paralleles lies a l'activite d'un client
WO2000039727A2 (fr) Procede et dispositif servant a produire des avantages et des penalites croises
WO2001008025A2 (fr) Systemes et procedes pour evaluer des informations associees a une transaction pour determiner une offre de subvention
WO2001004786A2 (fr) Systemes et procedes permettant de fournir une offre promotionnelle par l'intermediaire d'un dispositif de client
JP2004510212A5 (fr)
KR20010097935A (ko) 정기금전채무 이행 지원 시스템 및 방법

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

AK Designated states

Kind code of ref document: C1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

D17 Declaration under article 17(2)a
122 Ep: pct application non-entry in european phase