US20030055744A1 - Method and apparatus for managing the sale of aging products - Google Patents
Method and apparatus for managing the sale of aging products Download PDFInfo
- Publication number
- US20030055744A1 US20030055744A1 US10/279,303 US27930302A US2003055744A1 US 20030055744 A1 US20030055744 A1 US 20030055744A1 US 27930302 A US27930302 A US 27930302A US 2003055744 A1 US2003055744 A1 US 2003055744A1
- Authority
- US
- United States
- Prior art keywords
- offer
- product
- price
- effective
- period
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Images
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/04—Payment circuits
-
- 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
-
- 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/20—Point-of-sale [POS] network systems
-
- 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/20—Point-of-sale [POS] network systems
- G06Q20/201—Price look-up processing, e.g. updating
-
- 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/06—Buying, selling or leasing transactions
-
- 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/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
-
- 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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F9/00—Details other than those peculiar to special kinds or types of apparatus
- G07F9/02—Devices for alarm or indication, e.g. when empty; Advertising arrangements in coin-freed apparatus
- G07F9/026—Devices for alarm or indication, e.g. when empty; Advertising arrangements in coin-freed apparatus for alarm, monitoring and auditing in vending machines or means for indication, e.g. when empty
Definitions
- the present invention relates to methods and apparatus for managing the sale of products and, more particularly, to methods and apparatus for managing the sale of aging products.
- a store typically sells the product to a consolidator or factory outlet at a fraction of the product cost.
- the expenses incurred in “blowing out” (“liquidating”) a product include packaging, delivery and the loss to the seller for selling below cost. Accordingly, stores are averse to blowing out aging products, and instead prefer to sell aging products to customers.
- a catalog merchant publishes catalogs of products and corresponding prices, and distributes the catalogs to potential customers.
- a catalog merchant typically prints several versions of each catalog in advance, each version having anticipated product prices during the course of a season or year. Each version is distributed at a different time, for example, a new catalog every month, in order to inform potential customers of the new prices. Accordingly, the catalog merchant often must establish prices well in advance of when those prices will become effective.
- the catalog merchant may have to reprint a new version if it is desirable to deviate from the pre-established prices. Such a deviation may arise in response to unanticipated conditions. For example, the catalog merchant may lower list prices of a product in response to a similar, unanticipated price reduction by a competitor. If the catalog merchant lowers list prices, it must either (i) incur substantial expenses reprinting and redistributing catalogs, or (ii) forego advertising the new, list prices, and thereby forego most of the benefits of lowering those prices. Accordingly, catalog merchants typically cannot respond easily to unanticipated conditions that affect product prices.
- Some stores offer “tiered” prices, in which a series of subsequently lower prices for a product take effect over correspondingly subsequent periods of time. For example, a product price might be $100.00 during January (a first tier), $80.00 during February (a second tier) and $70.00 thereafter (a third tier). Tiered prices do not allow a seller to sell a product rapidly, for example, if there is a sudden need to clear old products to make space for new products. On the contrary, tiered prices tend to discourage customers from returning until the lowered prices are in effect. For example, customers willing to pay only the third tier price would not return until that price was in effect.
- Tiered prices represent an attempt to predict demand for a product during different periods of time.
- tiered prices do not allow a seller to anticipate prices that customers are willing to pay until after the customers actually make purchases. Consequently, when a seller sets a tier price in order to sell the product quickly, the seller may inadvertently set the tier price too low, and make less profit than was attainable. Conversely, a seller may inadvertently set the tier price too high, and thus fail to move the product as quickly as desired.
- tiered prices do not produce commitments to purchase products at any particular price or time. Customers may or may not return to visit the seller during the periods of future tiers. Thus, tiered prices do not allow a seller to accurately manage the timing or number of sales of products.
- An object of the present invention is to provide a method and apparatus for enabling a seller to more accurately manage the sale of aging products.
- a store controller stores a series of prices for a product. Each price has a respective effective period during which that price is effective.
- a customer submits an offer to buy the product at an “offer price” that is one of the series of prices.
- the offer also has an offer period that elapses when the respective effective period of the product price elapses. The offer period thereby defines a period during which the offer is effective and after which the offer cannot be accepted.
- Each offer further specifies (i) a customer identifier for identifying the customer, and (ii) funds or a payment identifier for specifying an account from which funds (typically the offer price) may be collected if the offer is accepted.
- the payment identifier is typically a credit card number, checking account number or other means for specifying funds. The payment identifier thus provides the seller with assurance that payment for the product will be available if the offer is accepted. Accordingly, the seller may more accurately make decisions on the sale of products.
- the store controller operates to determine whether to accept the offer in accordance with operator-set criteria. Offers are effective and may be accepted at any time during the corresponding offer period, and particularly when it is desirable to move an aging product. For example, offers can be accepted if the corresponding product must be sold and the offer price is above a predetermined threshold. If the offer is accepted, the store controller (i) initiates the use of the payment identifier, if any, to collect the offer price, and (ii) uses the customer identifier to identify the customer as having paid for the product. Thus, the customer pays for the product and the seller must deliver the product or otherwise inform the customer that the product has been sold to him.
- FIG. 1 is a schematic illustration of a system for managing the sale of aging inventory provided in accordance with the present invention.
- FIG. 2 is a schematic illustration of a store of the system of FIG. 1.
- FIG. 3 is a schematic illustration of a store controller of the store of FIG. 2.
- FIG. 4 is a schematic illustration of a product price database of the store controller of FIG. 3.
- FIG. 5 is a schematic illustration of an offer database of the store controller of FIG. 3.
- FIG. 6 is a schematic illustration of an acceptance database of the store controller of FIG. 3.
- FIG. 7 is a schematic illustration of an inventory database of the store controller of FIG. 3.
- FIG. 8 is a schematic illustration of exemplary records of databases of the store controller of FIG. 3.
- FIG. 9 is a flowchart depicting a method for submitting an offer for a product.
- FIG. 10 is a flowchart depicting an embodiment of a method for managing stored offers for products.
- FIG. 11 is a flowchart depicting another embodiment of a method for managing stored offers for products.
- FIGS. 12A and 12B are flowcharts depicting yet another embodiment of a method for managing stored offers for products.
- FIG. 13 is a flowchart depicting a method for determining whether to accept an offer for a product.
- FIG. 14 is a flowchart depicting a method for determining if a product is available.
- FIG. 15 is a flowchart depicting a method for determining whether to accept offers.
- FIG. 16 is a schematic illustration of the central controller of FIG. 1.
- FIG. 17 is a schematic illustration of a store database of the central controller of FIG. 16.
- FIG. 18 is a flowchart depicting a method for aggregating the offer databases of two or more sellers.
- the term “seller”, as used herein, refers to an entity, such as a store, a chain of stores or a catalog merchandiser, that sells products to customers at prices that are set by the entity, not by a customer.
- product means any type of good or service that is offered for sale and/or sold by a seller.
- list price means a price that is set by the seller and displayed to customers, and which is therefore charged to customers who do not submit offers, but instead immediately purchase products.
- a store or other seller establishes, for each of a plurality of products, a series of subsequently decreasing prices and corresponding effective periods.
- the prices apply to offers that customers may submit for the products.
- the prices and periods are printed in a catalog or on a product tag, thereby informing potential customers of the series of prices.
- a customer desiring to buy a product may either (i) pay list price and purchase the product immediately; or (ii) submit an offer at a (reduced) offer price selected from the series of prices.
- the customer provides the offer to a clerk operating a POS terminal. If an offer is submitted, it may be accepted, if at all, at any time before the corresponding effective period elapses.
- each of the series of prices is lower than the list price of the product
- a seller By receiving and storing offers to purchase products, a seller can more precisely manage the sale of those products. Since the acceptance of offers is seller-driven, the seller may accept at any time desired. If a product is selling as quickly as desired at a list price set by the seller, the offers for that product need not be accepted, and the seller receives the profit accruing from the list price. On the other hand, if a product is not selling as quickly as desired, the seller may accept some or all stored offers for the product. Customers provide guaranteed commitments with their offers to buy the products, so the seller is assured that accepting an offer yields a guaranteed sale. Thus, the seller need not wait for customers to learn about a sale before products can be sold to customers at “sale prices”.
- the seller may continue selling the product at the list price, which is typically higher than the offer prices. Other customers will not easily determine what offer prices have been accepted, so the list price will not appear unduly high by comparison. Thus, many customers will still find the higher list price acceptable and pay that price.
- submitted offers allow the seller to determine prices that customers are willing to pay before the customers actually buy products.
- the seller can accurately manage the sale of aging products while avoiding the drawbacks associated with lowering prices.
- a system 100 for managing the sale of aging inventory comprises a central controller 102 connected to each of stores 104 , 106 and 108 .
- the stores 104 , 106 and 108 are typically related stores, such as a chain of retail franchisees. Although three stores are shown in FIG. 1, it will be understood by those skilled in the art that the invention is applicable to one or more stores.
- the central controller 102 manages the sale of products in each of the stores 104 , 106 and 108 .
- the central controller 102 allows the stores 104 , 106 and 108 to cooperate, and thus manage the sale of products more efficiently.
- a single seller operates alone, rather than together with a group of related sellers.
- the functionality of the central controller 102 may be embodied in an apparatus such as a store controller operated by a single seller. Accordingly, a single seller embodiment is first described below, followed by an embodiment with a plurality of sellers.
- FIG. 2 depicts the store 104 in more detail.
- Stores 106 and 108 are similar to the store 104 , and so a detailed illustration of each is omitted.
- the store 104 includes a store controller 120 connected to each of point-of-sale (POS) terminals 122 , 124 and 126 .
- POS point-of-sale
- the point-of-sale terminals 122 , 124 and 126 are typically cash registers, desktop computers or similar devices at which offers may be entered, as described below. Any number of point-of-sale terminals may be connected to the store controller 120 , although three are shown in FIG. 2 for purposes of illustration.
- the store controller 120 is connected to the central controller 102 .
- the functionality of the central controller 102 may be embodied in an apparatus within a single seller. Accordingly, the store controller 120 may also perform some or all of the functions of the central controller 102 , rather than be connected to a separate central controller 102 as shown in FIG. 2.
- FIG. 3 depicts the store controller 120 in more detail.
- the store controller 120 comprises a processor 140 , such as one or more conventional microprocessors, and a data storage device 142 , such as a RAM, floppy disk, hard disk or combination thereof, which is connected thereto.
- the processor 140 is also connected to the central controller 102 and each of the point-of-sale terminals 122 , 124 and 126 .
- the processor 140 and the storage device 142 may each be (i) located entirely within a single computer; (ii) connected to each other by a remote communication link, such as a serial port cable, telephone line or radio frequency transceiver; or (iii) a combination thereof.
- the store controller 120 may comprise one or more computers connected to a remote server computer for maintaining databases.
- the storage device 142 stores (i) a program 144 for controlling the processor 140 in accordance with the present invention, and particularly in accordance with the processes described in detail hereinafter; (ii) a product price database 146 ; (iii) an offer database 148 for storing offers from customers for products; (iv) an acceptance database 150 for storing accepted offers; and (v) an inventory database 152 for storing the quantity available of each product.
- the program 144 includes program elements that may be necessary, such as “device drivers” for interfacing 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.
- Each of the databases 146 , 148 , 150 and 152 are described in detail below and depicted with exemplary entries in the accompanying figures. As will be understood by those skilled in the art, the schematic illustrations and accompanying descriptions of the databases presented herein are exemplary arrangements for the stored information. A number of other arrangements may be employed besides the tables shown.
- the product price database 146 stores entries 153 , 154 and 155 , each having a product identifier 156 which uniquely indicates a product and a corresponding price 158 of the product.
- the prices stored in the product price database 146 are not list prices, but are instead prices set by the seller for customers who submit offers. In other words, in lieu of a purchase at list price, a customer may instead choose to submit an offer to purchase a product at an offer price selected from a series of seller-defined prices. Accordingly, in the embodiment illustrated in FIG. 4, each entry defines a product and a price at which customers may submit an offer for the product.
- each product has a series of tiered prices, and consequently two or more entries in the product price database 146 may have identical product identifiers.
- the product price database 146 also stores, for each price, a respective effective period 160 during which that price is effective.
- the effective period is typically a day, range of days or set of days. However, some products can have an effective period that is always in effect after a predetermined date, so the product always has one price after that date.
- the effective periods are typically sorted such that each effective period increases in comparison to the previous effective period. In addition, since the price of a product typically decreases with time, each of the series of prices decreases in comparison to the previous price as the effective periods increase in comparison to each previous effective period.
- each entry in the product price database 146 may include a product identifier and several prices and effective periods.
- the offer database 148 stores entries 170 and 172 , each having an offer identifier 173 for uniquely identifying each offer, a product identifier 174 which indicates a product, and a corresponding offer price 176 for the product. Accordingly, each entry defines an offer to purchase a product at an offer price.
- the offer price is selected from the series of prices of the product stored in the product price database 146 .
- the offer database 148 also stores, for each entry, a customer identifier 178 that indicates a customer who submitted the offer for the product.
- a payment identifier 180 may also be stored in the offer database 148 , thereby specifying an account from which the offer price or other amount of funds may be collected.
- the specified account typically is a credit card, debit card, savings account or checking account from which funds are transferred if the seller accepts the offer.
- an offer price has an offer period during which the offer is effective and may be accepted. After the offer period has elapsed, the offer may not be accepted. For example, an offer at the first tier price remains effective until the first tier period has elapsed. Thus, the customer is assured that his (typically higher) offer price will expire after other (typically lower) offer prices are entertained.
- An offer period 181 indicates a period during which the offer is effective, and may be either (i) a period which elapses when the effective period of the selected price elapses; or (ii) a customer-selected period which elapses sooner than the effective period of the selected price.
- the acceptance database 150 stores entries 190 , 192 and 194 , each having an acceptance identifier 196 for uniquely identifying the entry, an offer identifier 198 which indicates an offer from the offer database 148 (FIG. 5) that has been accepted, and the date 200 of acceptance. Based on the offer identifier 198 , information that corresponds to the offer may be determined from the offer database 148 . For example, based on the offer identifier 198 , the corresponding product identifier 174 (FIG. 5) and offer price 176 (FIG. 5) may be determined from the offer database 148 . In other embodiments, corresponding information may be also stored in the acceptance database 150 , as well as in the offer database 148 .
- the inventory database 152 stores entries 202 and 204 , each having a product identifier 206 which indicates a product and a quantity 208 of each product. Accordingly, each entry defines how many items of each product are available for purchase.
- the product identifier 206 may be compared with product identifiers in the offer database 148 (FIG. 5), thereby matching entries in the inventory database 152 with entries in the offer database 148 (FIG. 5).
- the quantity available may be determined from the inventory database 152 .
- FIG. 8 illustrates exemplary records used in the acceptance of an offer for a product.
- a product price database 210 which is an embodiment of the product price database 146 of FIG. 4, stores two prices and effective periods for a product identified by product identifier “1111”.
- An offer database 220 which is an embodiment of the offer database 148 of FIG. 5, stores an offer for the product “1111” for an offer price of $7.50. The offer was submitted by, or on behalf of, a customer identified by “AVL204”, and a payment identifier specifies a credit card account number to pay for the product if the offer is accepted.
- An inventory database 230 which is an embodiment of the inventory database 152 of FIG. 7, stores the quantity of the product “1111”. As seen in FIG. 8, there are seventeen units of product “1111” available.
- An acceptance database 240 which is an embodiment of the acceptance database 150 of FIG. 6, stores an entry indicating an acceptance of the offer “1”, and thereby indicates that the customer “AVL204” has purchased the product “1111”. Accordingly, use of the payment identifier is initiated to collect the $7.50 from the credit card account, and the product is delivered to the customer or set aside for the customer.
- a method 250 illustrates the steps taken when a customer submits an offer for a product, and the offer is entered into a POS terminal.
- a POS terminal may be a cash register at a retail store, or a desktop computer operated by a customer service representative of a catalog merchant.
- the customer name, address and credit card number are entered into the POS terminal (step 252 ). If the customer has previously submitted an offer and a corresponding customer identifier established (step 254 ), then that customer identifier is retrieved (step 256 ). If a customer identifier does not already exist, then a new, unique customer identifier is generated (step 258 ) to identify the customer.
- a product identifier for a desired product is entered into the POS terminal (step 260 ), and an offer price is also entered into the POS terminal (step 262 ).
- the offer price is selected from a series of prices for the product.
- the customer obtains the product identifier and product price(s) from a catalog or a product tag bearing a product number and product price(s), and provides the same to a clerk operating the POS terminal.
- the offer has an associated offer period during which the offer is effective and after which the offer cannot be accepted.
- the offer period elapses when the effective period of the selected price elapses.
- the customer may specify that the offer period elapse even sooner than the effective period of the price. For example, although a selected price may be effective until the end of June, the customer may specify that the offer is effective until the beginning of June. Any customer-specified offer period is entered into the POS terminal (step 264 ).
- the above-described information that is entered into the POS terminal is then transmitted to the store controller 120 (FIG. 2) for storage (step 266 ). After transmission, the offer is stored and may be accepted when the seller desires if the offer remains effective. Described below are several embodiments of a method for managing stored offers for products, each provided in accordance with the present invention.
- a method 280 illustrates steps performed by the store controller 120 (FIG. 2) in managing and accepting the stored offers for products.
- the method 280 may alternatively be performed by the central controller 102 (FIG. 1) in an embodiment with more than one seller.
- prices and corresponding effective periods for each of a plurality of products are stored (step 282 ). Such prices and periods may be entered and changed as needed. For example, when new products are introduced or old products are discontinued, corresponding prices and effective periods for each product can be entered or deleted, respectively.
- the offer, customer identifier and payment identifier are each received from the POS terminal (steps 284 , 286 and 288 ). Still more information, such as the customer name and address, may be received from the POS terminal as well.
- Each of the offer, customer identifier and payment identifier may also be verified after being received. For example, the payment identifier may be verified by determining that an amount of funds are available, or attempting to “freeze” (make unavailable to the customer) an amount of funds in an account, as assurance that such funds remain available to the seller if the stored offer is accepted.
- the offer, customer identifier and payment identifier are then stored (step 290 ), and may be retrieved for subsequent evaluation, review and/or acceptance of the offer.
- any of a number of methods may be used in determining whether to accept the offer (step 292 ). If any offer is accepted (step 294 ), then use of the corresponding payment identifier is initiated in order to collect the offer price (step 296 ).
- the payment identifier is a credit card number, so initiating use of the credit card number can comprise charging the offer price to the credit card number.
- the corresponding customer identifier is utilized to identify the customer as having paid for the product (step 298 ). For example, an entry in a “product delivery database” may be made to initiate delivery of the product to the customer, or a receipt may be printed out bearing the name of the customer and the product bought.
- a method 310 is another embodiment of a method for managing stored offers for products.
- the method 310 is similar to the method 280 (FIG. 10) described above, and like steps are numbered with like figure numerals in FIGS. 10 and 11.
- the method 310 differs from the method 280 (FIG. 10) in that a collection identifier is received from the POS terminal (step 312 ), rather than a payment identifier (step 288 of FIG. 10).
- the collection identifier specifies an amount of collected funds, and may be, for example, an entry indicating an amount of cash tendered at the POS terminal or an amount of funds authorized and tendered from a credit card account.
- the received collection identifier is also stored (step 314 ).
- a customer submits an actual payment before the offer is accepted by the seller, rather than an account number used to effect a payment after acceptance of the offer by the seller.
- step 316 If an offer is not accepted (step 294 ) by the seller, then the corresponding collected funds are refunded (step 316 ). Such a refund may be accomplished in any of several ways. For example, a voucher may be printed and delivered to the customer, a credit card account may be credited or an entry may be entered in a database for indicating an amount of store credit due to the customer.
- FIGS. 12A and 12B depict a method 330 of yet another embodiment for managing stored offers for products which is similar to the method 280 (FIG. 10) described above.
- the method 330 includes yet further steps that may be desirable in managing offers, and particularly in managing when to accept and/or delete (clear or make unacceptable) offers.
- the offer is stored, it is determined if the product is available (step 344 ). If the product is not available, the offer is deleted (step 346 ) since the offer cannot be accepted.
- the availability of each product is determined from an associated inventory entry indicating a quantity available. Typically, the product is deemed to be “available” if the quantity is greater than zero. Alternatively, it may be desirable to sell the product only if more than a predetermined amount of the product is available. In such an embodiment, a quantity greater than a predetermined amount would indicate that the product is available.
- the offer period is evaluated in order to determine if the offer is still effective (step 348 ). Such an evaluation may comprise, for example, determining if the current date is within the offer period, or determining if the offer period is about to expire. If the offer is not effective, the offer is deleted (step 346 ) since it cannot be accepted.
- the offer is evaluated to see if it is desirable to accept the offer (step 352 ). Such an evaluation may comprise, for example, accepting all offers for a product, or accepting the highest offer price. If the offer is accepted, use of the payment identifier is initiated to collect payment for the product (step 358 ). In addition, the customer identifier is utilized to identify the customer as having paid (step 360 ).
- the seller may cancel an accepted offer, and refund any funds, if any, which were collected in connection therewith.
- a method 380 comprises steps for determining to accept offers for a selected product, based on whether there are effective offers for the selected product.
- the method 380 is especially advantageous when there are one or more particular products which must be moved.
- Inventory data is stored for each of a plurality of products (step 382 ), thereby indicating a quantity available of each product.
- a plurality of offers is stored (step 384 ).
- a group of effective offers is identified (step 386 ).
- the offers may also be compared with a predetermined date, such as “July 1”, in order to identify offers which are effective only before the predetermined date. Thus, offers that cannot be accepted after July 1 (expiring offers) may be determined.
- step 388 If there are any effective offers (step 388 ), and if the desired products are available (step 390 ) then use of the corresponding payment identifiers are initiated to collect the offer prices from the customers (step 392 ), and the products are delivered to the customers.
- whether a product is available may be determined from an inventory database storing a quantity available of the product.
- a product can be deemed available if any of the sellers have the product available.
- the inventory databases of each seller are accessed in order to find a seller having a product quantity that is greater than zero. As appropriate, products can be shipped between multiple participating sellers.
- FIG. 14 illustrates in simplified form a method 400 for determining if a product is available in a multiple-seller embodiment. If a selected product is not available at a first store (step 402 ), then it is also determined if the selected product is available at any other related stores (step 404 ). If any store does have the product available, then the offer is accepted, use of the payment identifier is initiated (step 406 ) and the product is shipped to the customer or to a store selected by the customer.
- FIG. 15 illustrates a method 410 for determining whether to accept offers based on a selected product to move.
- a plurality of stored offers are recalled (step 412 ), and the product identifier of each offer is compared to the selected product identifier (step 414 ) to identify offers for the selected product.
- Offers that correspond to the selected product are identified (step 416 ). If one or more offers correspond to the selected product (step 418 ), use of the corresponding payment identifier is initiated to collect the offer price (step 420 ).
- Criteria described above include accepting (i) all expiring offers; (ii) all offers for a selected product; (iii) all offers for available products; and (iv) a combination thereof.
- the central controller 102 allows a plurality of sellers to cooperate, and thus to manage the sale of products more effectively.
- the central controller 102 aggregates each of the inventory databases of the sellers and aggregates the offer databases of the sellers.
- the central controller 102 can determine (i) which products are available from each of the sellers (supply of products); and (ii) which offers have been submitted to each of the sellers (demand for products).
- the offers of a store can be matched with products of other stores, and a customer offer can be satisfied from any store having the desired product.
- each participating store may sell more products and satisfy more customer demand than any store could have done alone.
- the particular store of a chain of stores that a customer visits is immaterial in meeting customer demand.
- FIG. 16 depicts the central controller 102 of FIG. 1 in more detail.
- the central controller 102 comprises a processor 470 , such as one or more conventional microprocessors, and a data storage device 472 , such as a RAM, floppy disk, hard disk or combination thereof, which is connected thereto.
- the processor 470 is also connected to the store controller 120 (FIG. 2). As described above, any number of stores, and thus store controllers, may be connected to the central controller 102 although only one is depicted in FIG. 16.
- the processor 470 and the storage device 472 may each be (i) located entirely within a single computer; (ii) connected thereto by a remote communication link, such as a serial port cable, telephone line or radio frequency transceiver; or (iii) a combination thereof.
- the central controller 102 may comprise one or more computers connected to a remote server computer for maintaining databases.
- the storage device 472 stores (i) a program 474 for controlling the processor 470 in accordance with the present invention, and particularly in accordance with the processes described in detail hereinafter; and (ii) a store database 476 for storing information on each store that is connected to the central controller 102 .
- the program 474 also includes program elements that may be necessary, such as “device drivers” for interfacing 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 store database 476 stores entries 480 and 482 , each having (i) a store identifier 484 for uniquely identifying a store connected to the central controller 102 (FIG. 16); (ii) an address 486 of the store; and (iii) a network address 488 for specifying a network address of the corresponding store controller, thereby allowing the central controller 102 to communicate with the corresponding store.
- FIG. 18 illustrates a method 500 for aggregating the offer databases of two or more sellers, thereby permitting offers separately submitted to multiple stores to be compared and evaluated.
- a first set of offers submitted to a first seller is stored in a first offer database (step 502 ), and a second set of offers submitted to a second seller is stored in a second offer database (step 504 ).
- the offer databases may be stored on the respective store controllers, or may be stored on the central controller 102 (FIG. 16).
- a selected product to move is compared with the products of the first set of offers (step 506 ).
- the first set of offers is typically the offers submitted at the store desiring to move the product. Thus, “local” offers are compared and evaluated before the offers of other stores. If any offers in the first set of offers correspond to the selected product (step 508 ), then use of the corresponding payment identifier is initiated in order to collect the offer price (step 509 ).
- step 510 If no offers in the first set of offers correspond to the selected product, then the selected product is compared with the products of the second set of offers (step 510 ). If any offers in the second set of offers correspond to the selected product (step 512 ), then use of the corresponding payment identifier is initiated in order to collect the offer price (step 509 ). It will be understood that any of the evaluation criteria described above can be used to manage the offer acceptance process amongst multiple sellers.
- the store controller may instead provide a phone number of the customer so that the customer may be called and informed that his offer has been accepted.
- the customer typically may select from a series of seller-defined product prices, in other embodiments the customer may select his own offer price.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Entrepreneurship & Innovation (AREA)
- Game Theory and Decision Science (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Description
- The present application is a continuation-in-part of co-pending patent application Ser. No. 08/707,660, entitled “METHOD AND SYSTEM FOR A CRYPTOGRAPHICALLY ASSISTED COMMERCIAL NETWORK SYSTEM DESIGNED TO FACILITATE BUYER-DRIVEN CONDITIONAL PURCHASE OFFERS”, filed on Sep. 4, 1996.
- The present invention relates to methods and apparatus for managing the sale of products and, more particularly, to methods and apparatus for managing the sale of aging products.
- Retail stores and other sellers often cannot “move” (sell) products as fast as desired. It is particularly difficult to sell aging products, since aging products may have become unfashionable, out of season, less useful or otherwise less desirable to customers. Retaining aging products occupies space needed for better selling products, and, even worse, can make other products appear unattractive by association.
- If a product has not sold for a significant amount of time, or if it is otherwise desirable to quickly dispose of (“blow out”) the product, a store typically sells the product to a consolidator or factory outlet at a fraction of the product cost. The expenses incurred in “blowing out” (“liquidating”) a product include packaging, delivery and the loss to the seller for selling below cost. Accordingly, stores are averse to blowing out aging products, and instead prefer to sell aging products to customers.
- In order to facilitate the sale of aging products without suffering the adverse effects of blowing out those products, stores often must lower the list prices (displayed prices) of those products to entice customers to purchase them. Unfortunately, lowering a list price of a product results in a lower profit, and possibly even a loss, on each sale of that product. Lowered prices may also make other, related products appear unduly expensive by comparison, thereby decreasing sales of those related products. Accordingly, it is desirable to sell aging products as quickly as possible. In addition, it would also be desirable to minimize or eliminate the publishing of lower list prices.
- However, even lowering list prices does not move products until customers become aware of the lower prices. Customers may not become aware of the new prices until they visit the seller. Advertising new prices may increase customer awareness of new prices, but advertising is costly. Accordingly, lowering list prices does not allow a seller to accurately manage the timing and number of sales of aging products.
- Lowering list prices can be even more costly to catalog merchants. A catalog merchant publishes catalogs of products and corresponding prices, and distributes the catalogs to potential customers. A catalog merchant typically prints several versions of each catalog in advance, each version having anticipated product prices during the course of a season or year. Each version is distributed at a different time, for example, a new catalog every month, in order to inform potential customers of the new prices. Accordingly, the catalog merchant often must establish prices well in advance of when those prices will become effective.
- Because the different versions of the catalog are often printed well before the corresponding product prices are effective, the catalog merchant may have to reprint a new version if it is desirable to deviate from the pre-established prices. Such a deviation may arise in response to unanticipated conditions. For example, the catalog merchant may lower list prices of a product in response to a similar, unanticipated price reduction by a competitor. If the catalog merchant lowers list prices, it must either (i) incur substantial expenses reprinting and redistributing catalogs, or (ii) forego advertising the new, list prices, and thereby forego most of the benefits of lowering those prices. Accordingly, catalog merchants typically cannot respond easily to unanticipated conditions that affect product prices.
- Some stores offer “tiered” prices, in which a series of subsequently lower prices for a product take effect over correspondingly subsequent periods of time. For example, a product price might be $100.00 during January (a first tier), $80.00 during February (a second tier) and $70.00 thereafter (a third tier). Tiered prices do not allow a seller to sell a product rapidly, for example, if there is a sudden need to clear old products to make space for new products. On the contrary, tiered prices tend to discourage customers from returning until the lowered prices are in effect. For example, customers willing to pay only the third tier price would not return until that price was in effect.
- Tiered prices represent an attempt to predict demand for a product during different periods of time. However, like most conventional pricing schemes, tiered prices do not allow a seller to anticipate prices that customers are willing to pay until after the customers actually make purchases. Consequently, when a seller sets a tier price in order to sell the product quickly, the seller may inadvertently set the tier price too low, and make less profit than was attainable. Conversely, a seller may inadvertently set the tier price too high, and thus fail to move the product as quickly as desired.
- In addition, tiered prices do not produce commitments to purchase products at any particular price or time. Customers may or may not return to visit the seller during the periods of future tiers. Thus, tiered prices do not allow a seller to accurately manage the timing or number of sales of products.
- It is particularly difficult to coordinate the sale of aging products between a group of related stores, such as a chain of franchisees. One store may have difficulty selling a product, while another store has customers waiting to buy that same product. To the best of applicants' knowledge, no effective system exists for managing this disparity between supply and demand at related stores. Accordingly, aging products may not be sold to the waiting customers as rapidly as desirable, if at all.
- It would be advantageous to provide methods and apparatus for managing the sale of aging products. Ideally, such methods and apparatus would allow stores to abate or overcome the above-described disadvantages.
- An object of the present invention is to provide a method and apparatus for enabling a seller to more accurately manage the sale of aging products.
- In accordance with the present invention, a store controller stores a series of prices for a product. Each price has a respective effective period during which that price is effective. A customer submits an offer to buy the product at an “offer price” that is one of the series of prices. The offer also has an offer period that elapses when the respective effective period of the product price elapses. The offer period thereby defines a period during which the offer is effective and after which the offer cannot be accepted.
- Each offer further specifies (i) a customer identifier for identifying the customer, and (ii) funds or a payment identifier for specifying an account from which funds (typically the offer price) may be collected if the offer is accepted. The payment identifier is typically a credit card number, checking account number or other means for specifying funds. The payment identifier thus provides the seller with assurance that payment for the product will be available if the offer is accepted. Accordingly, the seller may more accurately make decisions on the sale of products.
- The store controller operates to determine whether to accept the offer in accordance with operator-set criteria. Offers are effective and may be accepted at any time during the corresponding offer period, and particularly when it is desirable to move an aging product. For example, offers can be accepted if the corresponding product must be sold and the offer price is above a predetermined threshold. If the offer is accepted, the store controller (i) initiates the use of the payment identifier, if any, to collect the offer price, and (ii) uses the customer identifier to identify the customer as having paid for the product. Thus, the customer pays for the product and the seller must deliver the product or otherwise inform the customer that the product has been sold to him.
- FIG. 1 is a schematic illustration of a system for managing the sale of aging inventory provided in accordance with the present invention.
- FIG. 2 is a schematic illustration of a store of the system of FIG. 1.
- FIG. 3 is a schematic illustration of a store controller of the store of FIG. 2.
- FIG. 4 is a schematic illustration of a product price database of the store controller of FIG. 3.
- FIG. 5 is a schematic illustration of an offer database of the store controller of FIG. 3.
- FIG. 6 is a schematic illustration of an acceptance database of the store controller of FIG. 3.
- FIG. 7 is a schematic illustration of an inventory database of the store controller of FIG. 3.
- FIG. 8 is a schematic illustration of exemplary records of databases of the store controller of FIG. 3.
- FIG. 9 is a flowchart depicting a method for submitting an offer for a product.
- FIG. 10 is a flowchart depicting an embodiment of a method for managing stored offers for products.
- FIG. 11 is a flowchart depicting another embodiment of a method for managing stored offers for products.
- FIGS. 12A and 12B are flowcharts depicting yet another embodiment of a method for managing stored offers for products.
- FIG. 13 is a flowchart depicting a method for determining whether to accept an offer for a product.
- FIG. 14 is a flowchart depicting a method for determining if a product is available.
- FIG. 15 is a flowchart depicting a method for determining whether to accept offers.
- FIG. 16 is a schematic illustration of the central controller of FIG. 1.
- FIG. 17 is a schematic illustration of a store database of the central controller of FIG. 16.
- FIG. 18 is a flowchart depicting a method for aggregating the offer databases of two or more sellers.
- For clarity, the following definitions apply:
- The term “seller”, as used herein, refers to an entity, such as a store, a chain of stores or a catalog merchandiser, that sells products to customers at prices that are set by the entity, not by a customer.
- The term “product”, as used herein, means any type of good or service that is offered for sale and/or sold by a seller.
- The term “list price”, as used herein, means a price that is set by the seller and displayed to customers, and which is therefore charged to customers who do not submit offers, but instead immediately purchase products.
- In accordance with the present invention described herein, a store or other seller establishes, for each of a plurality of products, a series of subsequently decreasing prices and corresponding effective periods. The prices apply to offers that customers may submit for the products. The prices and periods are printed in a catalog or on a product tag, thereby informing potential customers of the series of prices.
- A customer desiring to buy a product may either (i) pay list price and purchase the product immediately; or (ii) submit an offer at a (reduced) offer price selected from the series of prices. The customer provides the offer to a clerk operating a POS terminal. If an offer is submitted, it may be accepted, if at all, at any time before the corresponding effective period elapses.
- Typically, each of the series of prices is lower than the list price of the product Thus, if a customer is willing to wait to receive a product, or is willing to risk never having his offer accepted and thus never receiving the product, he pays a lower price than if he had paid list price to immediately purchase the product.
- By requiring the customer to offer at a price selected from one of the series of seller-determined prices, rather than at an arbitrary price selected by the customer, the seller overcomes customer reluctance to select a reasonable offer price. Selecting one of a few seller-defined prices reasonably assures the customer that he has not inadvertently submitted an offer that is too low to ever be accepted or too high to be a “smart” offer.
- By receiving and storing offers to purchase products, a seller can more precisely manage the sale of those products. Since the acceptance of offers is seller-driven, the seller may accept at any time desired. If a product is selling as quickly as desired at a list price set by the seller, the offers for that product need not be accepted, and the seller receives the profit accruing from the list price. On the other hand, if a product is not selling as quickly as desired, the seller may accept some or all stored offers for the product. Customers provide guaranteed commitments with their offers to buy the products, so the seller is assured that accepting an offer yields a guaranteed sale. Thus, the seller need not wait for customers to learn about a sale before products can be sold to customers at “sale prices”.
- Since the offers may be held confidential, the seller may continue selling the product at the list price, which is typically higher than the offer prices. Other customers will not easily determine what offer prices have been accepted, so the list price will not appear unduly high by comparison. Thus, many customers will still find the higher list price acceptable and pay that price.
- In addition, due to the time factor of the tiered prices, customers are assured that their offer price will be accepted before lower offer prices are accepted. Thus, customers are assured that offering a relatively high offer price provides an advantage over customers that offer a lower offer price.
- Furthermore, submitted offers allow the seller to determine prices that customers are willing to pay before the customers actually buy products. Thus, the seller can accurately manage the sale of aging products while avoiding the drawbacks associated with lowering prices.
- Referring to FIG. 1, a
system 100 for managing the sale of aging inventory comprises acentral controller 102 connected to each ofstores stores - As described in detail below, the
central controller 102 manages the sale of products in each of thestores central controller 102 allows thestores central controller 102 may be embodied in an apparatus such as a store controller operated by a single seller. Accordingly, a single seller embodiment is first described below, followed by an embodiment with a plurality of sellers. - FIG. 2 depicts the
store 104 in more detail.Stores store 104, and so a detailed illustration of each is omitted. Thestore 104 includes astore controller 120 connected to each of point-of-sale (POS)terminals sale terminals store controller 120, although three are shown in FIG. 2 for purposes of illustration. - The
store controller 120 is connected to thecentral controller 102. As described above, in certain embodiments, the functionality of thecentral controller 102 may be embodied in an apparatus within a single seller. Accordingly, thestore controller 120 may also perform some or all of the functions of thecentral controller 102, rather than be connected to a separatecentral controller 102 as shown in FIG. 2. - FIG. 3 depicts the
store controller 120 in more detail. Thestore controller 120 comprises aprocessor 140, such as one or more conventional microprocessors, and adata storage device 142, such as a RAM, floppy disk, hard disk or combination thereof, which is connected thereto. Theprocessor 140 is also connected to thecentral controller 102 and each of the point-of-sale terminals - The
processor 140 and thestorage device 142 may each be (i) located entirely within a single computer; (ii) connected to each other by a remote communication link, such as a serial port cable, telephone line or radio frequency transceiver; or (iii) a combination thereof. For example, thestore controller 120 may comprise one or more computers connected to a remote server computer for maintaining databases. - The
storage device 142 stores (i) aprogram 144 for controlling theprocessor 140 in accordance with the present invention, and particularly in accordance with the processes described in detail hereinafter; (ii) aproduct price database 146; (iii) anoffer database 148 for storing offers from customers for products; (iv) anacceptance database 150 for storing accepted offers; and (v) aninventory database 152 for storing the quantity available of each product. - The
program 144 includes program elements that may be necessary, such as “device drivers” for interfacing 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. Each of thedatabases - Referring to FIG. 4, the
product price database 146stores entries product identifier 156 which uniquely indicates a product and acorresponding price 158 of the product. The prices stored in theproduct price database 146 are not list prices, but are instead prices set by the seller for customers who submit offers. In other words, in lieu of a purchase at list price, a customer may instead choose to submit an offer to purchase a product at an offer price selected from a series of seller-defined prices. Accordingly, in the embodiment illustrated in FIG. 4, each entry defines a product and a price at which customers may submit an offer for the product. Typically, each product has a series of tiered prices, and consequently two or more entries in theproduct price database 146 may have identical product identifiers. - The
product price database 146 also stores, for each price, a respectiveeffective period 160 during which that price is effective. The effective period is typically a day, range of days or set of days. However, some products can have an effective period that is always in effect after a predetermined date, so the product always has one price after that date. The effective periods are typically sorted such that each effective period increases in comparison to the previous effective period. In addition, since the price of a product typically decreases with time, each of the series of prices decreases in comparison to the previous price as the effective periods increase in comparison to each previous effective period. - Those skilled in the art will understand that a number of other arrangements may be employed for the
product price database 146 besides the table shown in FIG. 4. For example, in other embodiments, each entry in theproduct price database 146 may include a product identifier and several prices and effective periods. - Referring to FIG. 5, the
offer database 148stores entries offer identifier 173 for uniquely identifying each offer, aproduct identifier 174 which indicates a product, and acorresponding offer price 176 for the product. Accordingly, each entry defines an offer to purchase a product at an offer price. The offer price is selected from the series of prices of the product stored in theproduct price database 146. - The
offer database 148 also stores, for each entry, acustomer identifier 178 that indicates a customer who submitted the offer for the product. Apayment identifier 180 may also be stored in theoffer database 148, thereby specifying an account from which the offer price or other amount of funds may be collected. The specified account typically is a credit card, debit card, savings account or checking account from which funds are transferred if the seller accepts the offer. - As described above, an offer price has an offer period during which the offer is effective and may be accepted. After the offer period has elapsed, the offer may not be accepted. For example, an offer at the first tier price remains effective until the first tier period has elapsed. Thus, the customer is assured that his (typically higher) offer price will expire after other (typically lower) offer prices are entertained. An
offer period 181 indicates a period during which the offer is effective, and may be either (i) a period which elapses when the effective period of the selected price elapses; or (ii) a customer-selected period which elapses sooner than the effective period of the selected price. - Referring to FIG. 6, the
acceptance database 150stores entries acceptance identifier 196 for uniquely identifying the entry, anoffer identifier 198 which indicates an offer from the offer database 148 (FIG. 5) that has been accepted, and thedate 200 of acceptance. Based on theoffer identifier 198, information that corresponds to the offer may be determined from theoffer database 148. For example, based on theoffer identifier 198, the corresponding product identifier 174 (FIG. 5) and offer price 176 (FIG. 5) may be determined from theoffer database 148. In other embodiments, corresponding information may be also stored in theacceptance database 150, as well as in theoffer database 148. - Referring to FIG. 7, the
inventory database 152stores entries product identifier 206 which indicates a product and aquantity 208 of each product. Accordingly, each entry defines how many items of each product are available for purchase. Theproduct identifier 206 may be compared with product identifiers in the offer database 148 (FIG. 5), thereby matching entries in theinventory database 152 with entries in the offer database 148 (FIG. 5). Thus, for each offer in theoffer database 148, the quantity available may be determined from theinventory database 152. - FIG. 8 illustrates exemplary records used in the acceptance of an offer for a product. A
product price database 210, which is an embodiment of theproduct price database 146 of FIG. 4, stores two prices and effective periods for a product identified by product identifier “1111”. Anoffer database 220, which is an embodiment of theoffer database 148 of FIG. 5, stores an offer for the product “1111” for an offer price of $7.50. The offer was submitted by, or on behalf of, a customer identified by “AVL204”, and a payment identifier specifies a credit card account number to pay for the product if the offer is accepted. - An
inventory database 230, which is an embodiment of theinventory database 152 of FIG. 7, stores the quantity of the product “1111”. As seen in FIG. 8, there are seventeen units of product “1111” available. - An
acceptance database 240, which is an embodiment of theacceptance database 150 of FIG. 6, stores an entry indicating an acceptance of the offer “1”, and thereby indicates that the customer “AVL204” has purchased the product “1111”. Accordingly, use of the payment identifier is initiated to collect the $7.50 from the credit card account, and the product is delivered to the customer or set aside for the customer. - Referring now to FIG. 9, a
method 250 illustrates the steps taken when a customer submits an offer for a product, and the offer is entered into a POS terminal. Such a POS terminal may be a cash register at a retail store, or a desktop computer operated by a customer service representative of a catalog merchant. The customer name, address and credit card number are entered into the POS terminal (step 252). If the customer has previously submitted an offer and a corresponding customer identifier established (step 254), then that customer identifier is retrieved (step 256). If a customer identifier does not already exist, then a new, unique customer identifier is generated (step 258) to identify the customer. - A product identifier for a desired product is entered into the POS terminal (step260), and an offer price is also entered into the POS terminal (step 262). As described above, the offer price is selected from a series of prices for the product. Typically, the customer obtains the product identifier and product price(s) from a catalog or a product tag bearing a product number and product price(s), and provides the same to a clerk operating the POS terminal.
- The offer has an associated offer period during which the offer is effective and after which the offer cannot be accepted. As described above, the offer period elapses when the effective period of the selected price elapses. In addition, the customer may specify that the offer period elapse even sooner than the effective period of the price. For example, although a selected price may be effective until the end of June, the customer may specify that the offer is effective until the beginning of June. Any customer-specified offer period is entered into the POS terminal (step264).
- The above-described information that is entered into the POS terminal is then transmitted to the store controller120 (FIG. 2) for storage (step 266). After transmission, the offer is stored and may be accepted when the seller desires if the offer remains effective. Described below are several embodiments of a method for managing stored offers for products, each provided in accordance with the present invention.
- Referring to FIG. 10, a
method 280 illustrates steps performed by the store controller 120 (FIG. 2) in managing and accepting the stored offers for products. Themethod 280 may alternatively be performed by the central controller 102 (FIG. 1) in an embodiment with more than one seller. Prices and corresponding effective periods for each of a plurality of products are stored (step 282). Such prices and periods may be entered and changed as needed. For example, when new products are introduced or old products are discontinued, corresponding prices and effective periods for each product can be entered or deleted, respectively. - The offer, customer identifier and payment identifier are each received from the POS terminal (
steps - As described below, any of a number of methods may be used in determining whether to accept the offer (step292). If any offer is accepted (step 294), then use of the corresponding payment identifier is initiated in order to collect the offer price (step 296). Typically, the payment identifier is a credit card number, so initiating use of the credit card number can comprise charging the offer price to the credit card number. In addition, the corresponding customer identifier is utilized to identify the customer as having paid for the product (step 298). For example, an entry in a “product delivery database” may be made to initiate delivery of the product to the customer, or a receipt may be printed out bearing the name of the customer and the product bought.
- Referring to FIG. 11, a
method 310 is another embodiment of a method for managing stored offers for products. Themethod 310 is similar to the method 280 (FIG. 10) described above, and like steps are numbered with like figure numerals in FIGS. 10 and 11. Themethod 310 differs from the method 280 (FIG. 10) in that a collection identifier is received from the POS terminal (step 312), rather than a payment identifier (step 288 of FIG. 10). The collection identifier specifies an amount of collected funds, and may be, for example, an entry indicating an amount of cash tendered at the POS terminal or an amount of funds authorized and tendered from a credit card account. The received collection identifier is also stored (step 314). Thus, in the present embodiment a customer submits an actual payment before the offer is accepted by the seller, rather than an account number used to effect a payment after acceptance of the offer by the seller. - If an offer is not accepted (step294) by the seller, then the corresponding collected funds are refunded (step 316). Such a refund may be accomplished in any of several ways. For example, a voucher may be printed and delivered to the customer, a credit card account may be credited or an entry may be entered in a database for indicating an amount of store credit due to the customer.
- FIGS. 12A and 12B depict a
method 330 of yet another embodiment for managing stored offers for products which is similar to the method 280 (FIG. 10) described above. Themethod 330 includes yet further steps that may be desirable in managing offers, and particularly in managing when to accept and/or delete (clear or make unacceptable) offers. - Prices, corresponding effective periods and the quantity for each of a plurality of products are stored (step332). An offer for a product, a customer identifier and a payment identifier are each received from the POS terminal (
steps - After the offer is stored, it is determined if the product is available (step344). If the product is not available, the offer is deleted (step 346) since the offer cannot be accepted. The availability of each product is determined from an associated inventory entry indicating a quantity available. Typically, the product is deemed to be “available” if the quantity is greater than zero. Alternatively, it may be desirable to sell the product only if more than a predetermined amount of the product is available. In such an embodiment, a quantity greater than a predetermined amount would indicate that the product is available.
- The offer period is evaluated in order to determine if the offer is still effective (step348). Such an evaluation may comprise, for example, determining if the current date is within the offer period, or determining if the offer period is about to expire. If the offer is not effective, the offer is deleted (step 346) since it cannot be accepted.
- However, if the offer is effective, then the offer is evaluated to see if it is desirable to accept the offer (step352). Such an evaluation may comprise, for example, accepting all offers for a product, or accepting the highest offer price. If the offer is accepted, use of the payment identifier is initiated to collect payment for the product (step 358). In addition, the customer identifier is utilized to identify the customer as having paid (step 360).
- In some embodiments, the seller may cancel an accepted offer, and refund any funds, if any, which were collected in connection therewith.
- The above described embodiments of a method for managing stored offers for products illustrate, among other things, steps performed before and after an offer is accepted. The description that follows explains methods for determining whether to accept an offer.
- Referring now to FIG. 13, a
method 380 comprises steps for determining to accept offers for a selected product, based on whether there are effective offers for the selected product. Themethod 380 is especially advantageous when there are one or more particular products which must be moved. Inventory data is stored for each of a plurality of products (step 382), thereby indicating a quantity available of each product. In addition, a plurality of offers is stored (step 384). - A group of effective offers is identified (step386). The offers may also be compared with a predetermined date, such as “July 1”, in order to identify offers which are effective only before the predetermined date. Thus, offers that cannot be accepted after July 1 (expiring offers) may be determined.
- If there are any effective offers (step388), and if the desired products are available (step 390) then use of the corresponding payment identifiers are initiated to collect the offer prices from the customers (step 392), and the products are delivered to the customers.
- In single-seller embodiments, whether a product is available may be determined from an inventory database storing a quantity available of the product. In an embodiment with more than one seller, a product can be deemed available if any of the sellers have the product available. In such an embodiment, the inventory databases of each seller are accessed in order to find a seller having a product quantity that is greater than zero. As appropriate, products can be shipped between multiple participating sellers.
- FIG. 14 illustrates in simplified form a
method 400 for determining if a product is available in a multiple-seller embodiment. If a selected product is not available at a first store (step 402), then it is also determined if the selected product is available at any other related stores (step 404). If any store does have the product available, then the offer is accepted, use of the payment identifier is initiated (step 406) and the product is shipped to the customer or to a store selected by the customer. - It may be desirable to sell a selected product at any reasonable price, especially if it is necessary to rapidly move the selected product. FIG. 15 illustrates a
method 410 for determining whether to accept offers based on a selected product to move. A plurality of stored offers are recalled (step 412), and the product identifier of each offer is compared to the selected product identifier (step 414) to identify offers for the selected product. Offers that correspond to the selected product are identified (step 416). If one or more offers correspond to the selected product (step 418), use of the corresponding payment identifier is initiated to collect the offer price (step 420). - A variety of other criteria may be used in determining whether it is desirable to accept an offer. Criteria described above include accepting (i) all expiring offers; (ii) all offers for a selected product; (iii) all offers for available products; and (iv) a combination thereof. In other embodiments, it may be desirable to accept an offer for a selected product if (i) the quantity available of the product is greater than a predetermined threshold; (ii) the number of offers for the product is greater than a predetermined threshold; (iii) the average offer price for the product is greater than a predetermined threshold; (iv) the number of “reasonable” offers for the product is greater than a predetermined threshold; (v) sales of the product are less than a predetermined threshold; or (vi) a combination thereof.
- As described above, the central controller102 (FIG. 1) allows a plurality of sellers to cooperate, and thus to manage the sale of products more effectively. In particular, the
central controller 102 aggregates each of the inventory databases of the sellers and aggregates the offer databases of the sellers. Thus, thecentral controller 102 can determine (i) which products are available from each of the sellers (supply of products); and (ii) which offers have been submitted to each of the sellers (demand for products). The offers of a store can be matched with products of other stores, and a customer offer can be satisfied from any store having the desired product. Thus, each participating store may sell more products and satisfy more customer demand than any store could have done alone. In summary, the particular store of a chain of stores that a customer visits is immaterial in meeting customer demand. - FIG. 16 depicts the
central controller 102 of FIG. 1 in more detail. Thecentral controller 102 comprises aprocessor 470, such as one or more conventional microprocessors, and adata storage device 472, such as a RAM, floppy disk, hard disk or combination thereof, which is connected thereto. Theprocessor 470 is also connected to the store controller 120 (FIG. 2). As described above, any number of stores, and thus store controllers, may be connected to thecentral controller 102 although only one is depicted in FIG. 16. - The
processor 470 and thestorage device 472 may each be (i) located entirely within a single computer; (ii) connected thereto by a remote communication link, such as a serial port cable, telephone line or radio frequency transceiver; or (iii) a combination thereof. For example, thecentral controller 102 may comprise one or more computers connected to a remote server computer for maintaining databases. - The
storage device 472 stores (i) aprogram 474 for controlling theprocessor 470 in accordance with the present invention, and particularly in accordance with the processes described in detail hereinafter; and (ii) astore database 476 for storing information on each store that is connected to thecentral controller 102. - The
program 474 also includes program elements that may be necessary, such as “device drivers” for interfacing 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. - Referring to FIG. 17, the
store database 476stores entries store identifier 484 for uniquely identifying a store connected to the central controller 102 (FIG. 16); (ii) anaddress 486 of the store; and (iii) anetwork address 488 for specifying a network address of the corresponding store controller, thereby allowing thecentral controller 102 to communicate with the corresponding store. - FIG. 18 illustrates a
method 500 for aggregating the offer databases of two or more sellers, thereby permitting offers separately submitted to multiple stores to be compared and evaluated. A first set of offers submitted to a first seller is stored in a first offer database (step 502), and a second set of offers submitted to a second seller is stored in a second offer database (step 504). The offer databases may be stored on the respective store controllers, or may be stored on the central controller 102 (FIG. 16). - A selected product to move is compared with the products of the first set of offers (step506). The first set of offers is typically the offers submitted at the store desiring to move the product. Thus, “local” offers are compared and evaluated before the offers of other stores. If any offers in the first set of offers correspond to the selected product (step 508), then use of the corresponding payment identifier is initiated in order to collect the offer price (step 509).
- If no offers in the first set of offers correspond to the selected product, then the selected product is compared with the products of the second set of offers (step510). If any offers in the second set of offers correspond to the selected product (step 512), then use of the corresponding payment identifier is initiated in order to collect the offer price (step 509). It will be understood that any of the evaluation criteria described above can be used to manage the offer acceptance process amongst multiple sellers.
- Although the present invention has been described with respect to a preferred embodiment thereof, those skilled in the art will understand that various substitutions may be made to those embodiments described herein without departing from the spirit and scope of the present invention. For instance, rather than initiating use of a payment identifier such as a credit card number to collect funds when an offer is accepted, the store controller may instead provide a phone number of the customer so that the customer may be called and informed that his offer has been accepted. In addition, although the customer typically may select from a series of seller-defined product prices, in other embodiments the customer may select his own offer price.
Claims (53)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/279,303 US20030055744A1 (en) | 1997-10-06 | 2002-10-22 | Method and apparatus for managing the sale of aging products |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/943,965 US6119100A (en) | 1996-09-04 | 1997-10-06 | Method and apparatus for managing the sale of aging products |
US09/563,715 US6507822B1 (en) | 1997-10-06 | 2000-05-02 | Method and apparatus for managing the sale of aging products |
US10/279,303 US20030055744A1 (en) | 1997-10-06 | 2002-10-22 | Method and apparatus for managing the sale of aging products |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/563,715 Continuation US6507822B1 (en) | 1997-10-06 | 2000-05-02 | Method and apparatus for managing the sale of aging products |
Publications (1)
Publication Number | Publication Date |
---|---|
US20030055744A1 true US20030055744A1 (en) | 2003-03-20 |
Family
ID=24251598
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/563,715 Expired - Lifetime US6507822B1 (en) | 1997-10-06 | 2000-05-02 | Method and apparatus for managing the sale of aging products |
US10/279,303 Abandoned US20030055744A1 (en) | 1997-10-06 | 2002-10-22 | Method and apparatus for managing the sale of aging products |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/563,715 Expired - Lifetime US6507822B1 (en) | 1997-10-06 | 2000-05-02 | Method and apparatus for managing the sale of aging products |
Country Status (3)
Country | Link |
---|---|
US (2) | US6507822B1 (en) |
AU (1) | AU2000267746A1 (en) |
WO (1) | WO2001084416A2 (en) |
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040128224A1 (en) * | 2002-12-31 | 2004-07-01 | Autotrader.Com, Llc | Efficient online auction style listings that encourage out-of-channel negotiation |
US20050071245A1 (en) * | 2003-09-25 | 2005-03-31 | Norins Arthur L. | System and method for transacting for a perishable object having an uncertain availability |
US7467103B1 (en) * | 2002-04-17 | 2008-12-16 | Murray Joseph L | Optimization system and method for buying clubs |
US7680696B1 (en) | 2002-01-12 | 2010-03-16 | Murray Thomas G | Computer processing system for facilitating the order, purchase, and delivery of products |
US7937294B1 (en) | 2002-01-12 | 2011-05-03 | Telegrow, Llc | System, and associated method, for configuring a buying club and a coop order |
US8271337B1 (en) | 2003-09-25 | 2012-09-18 | Nor1, Inc. | System and method for transacting for an upgrade having an uncertain availability |
US20120253910A1 (en) * | 2011-03-09 | 2012-10-04 | Lot18, Inc. | Group buying incentivized by risk and impact adjusted rewards |
US8392278B1 (en) * | 2007-05-30 | 2013-03-05 | Konot Ltd | Method and system for selling items |
WO2015042458A1 (en) * | 2013-09-20 | 2015-03-26 | Ebay Inc. | Recommendations for selling past purchases |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6507822B1 (en) * | 1997-10-06 | 2003-01-14 | Walker Digital, Llc | Method and apparatus for managing the sale of aging products |
US6876991B1 (en) | 1999-11-08 | 2005-04-05 | Collaborative Decision Platforms, Llc. | System, method and computer program product for a collaborative decision platform |
US10055772B1 (en) | 2000-01-14 | 2018-08-21 | Versata Development Group, Inc. | Method and apparatus for product comparison |
US7206756B1 (en) * | 2000-01-14 | 2007-04-17 | Trilogy Development Group, Inc. | System and method for facilitating commercial transactions over a data network |
US7069235B1 (en) * | 2000-03-03 | 2006-06-27 | Pcorder.Com, Inc. | System and method for multi-source transaction processing |
US20010047308A1 (en) * | 2000-03-31 | 2001-11-29 | Joseph Kaminsky | Concurrent dynamic pricing marketing and selling system |
US8412547B1 (en) | 2000-04-24 | 2013-04-02 | Trilogy Development Group, Inc. | Commerce server architecture and method for using same |
US7908200B2 (en) * | 2000-05-16 | 2011-03-15 | Versata Development Group, Inc. | Method and apparatus for efficiently generating electronic requests for quote |
KR100395419B1 (en) * | 2000-10-02 | 2003-08-21 | 주식회사 에스에이치티 | Method and system for deciding price of product on the basis of valid date of product |
US7447646B1 (en) | 2004-09-23 | 2008-11-04 | Amazon Technologies, Inc. | Method and computer-readable medium for automated dynamic pricing of products with parameter-driven state transitions |
EP2050017A2 (en) | 2006-08-10 | 2009-04-22 | Medcom Solutions, INC. | System and method for uniformly pricing items |
US10339532B2 (en) | 2006-08-10 | 2019-07-02 | Medcom Solutions, Inc. | System and method for uniformly pricing items |
US20080040209A1 (en) * | 2006-08-11 | 2008-02-14 | Pitney Bowes Incorporated | Rental article handling at an end of a rental stream |
US11887170B1 (en) | 2018-07-11 | 2024-01-30 | Medcom Solutions, Inc. | Medical procedure charge restructuring tools and techniques |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6119100A (en) * | 1996-09-04 | 2000-09-12 | Walker Digital, Llc. | Method and apparatus for managing the sale of aging products |
US6507822B1 (en) * | 1997-10-06 | 2003-01-14 | Walker Digital, Llc | Method and apparatus for managing the sale of aging products |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3581072A (en) * | 1968-03-28 | 1971-05-25 | Frederick Nymeyer | Auction market computation system |
US4674044A (en) * | 1985-01-30 | 1987-06-16 | Merrill Lynch, Pierce, Fenner & Smith, Inc. | Automated securities trading system |
JPH05225451A (en) * | 1992-02-14 | 1993-09-03 | Hitachi Ltd | Pos terminal |
US5794219A (en) * | 1996-02-20 | 1998-08-11 | Health Hero Network, Inc. | Method of conducting an on-line auction with bid pooling |
GB9320404D0 (en) | 1993-10-04 | 1993-11-24 | Dixon Robert | Method & apparatus for data storage & retrieval |
US5642279A (en) | 1994-08-09 | 1997-06-24 | New England Audio Company | Technique for utilizing a computer system to provide price protection to retail customers |
US5664115A (en) * | 1995-06-07 | 1997-09-02 | Fraser; Richard | Interactive computer system to match buyers and sellers of real estate, businesses and other property using the internet |
US5826244A (en) * | 1995-08-23 | 1998-10-20 | Xerox Corporation | Method and system for providing a document service over a computer network using an automated brokered auction |
US5873069A (en) | 1995-10-13 | 1999-02-16 | American Tv & Appliance Of Madison, Inc. | System and method for automatic updating and display of retail prices |
US5758328A (en) * | 1996-02-22 | 1998-05-26 | Giovannoli; Joseph | Computerized quotation system and method |
US5988498A (en) | 1997-06-25 | 1999-11-23 | Ncr Corporation | Method of delaying availability of price changes to checkout terminals following EPL price changes |
-
2000
- 2000-05-02 US US09/563,715 patent/US6507822B1/en not_active Expired - Lifetime
- 2000-08-15 AU AU2000267746A patent/AU2000267746A1/en not_active Abandoned
- 2000-08-15 WO PCT/US2000/022370 patent/WO2001084416A2/en active Application Filing
-
2002
- 2002-10-22 US US10/279,303 patent/US20030055744A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6119100A (en) * | 1996-09-04 | 2000-09-12 | Walker Digital, Llc. | Method and apparatus for managing the sale of aging products |
US6507822B1 (en) * | 1997-10-06 | 2003-01-14 | Walker Digital, Llc | Method and apparatus for managing the sale of aging products |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7680696B1 (en) | 2002-01-12 | 2010-03-16 | Murray Thomas G | Computer processing system for facilitating the order, purchase, and delivery of products |
US7937294B1 (en) | 2002-01-12 | 2011-05-03 | Telegrow, Llc | System, and associated method, for configuring a buying club and a coop order |
US7467103B1 (en) * | 2002-04-17 | 2008-12-16 | Murray Joseph L | Optimization system and method for buying clubs |
US20040128224A1 (en) * | 2002-12-31 | 2004-07-01 | Autotrader.Com, Llc | Efficient online auction style listings that encourage out-of-channel negotiation |
US7921052B2 (en) * | 2002-12-31 | 2011-04-05 | Autotrader.Com, Inc. | Efficient online auction style listings that encourage out-of-channel negotiation |
US20050071245A1 (en) * | 2003-09-25 | 2005-03-31 | Norins Arthur L. | System and method for transacting for a perishable object having an uncertain availability |
US7249062B2 (en) * | 2003-09-25 | 2007-07-24 | Nor1, Inc. | Method for transacting for a perishable object having an uncertain availability |
US8271337B1 (en) | 2003-09-25 | 2012-09-18 | Nor1, Inc. | System and method for transacting for an upgrade having an uncertain availability |
US8392278B1 (en) * | 2007-05-30 | 2013-03-05 | Konot Ltd | Method and system for selling items |
US20120253910A1 (en) * | 2011-03-09 | 2012-10-04 | Lot18, Inc. | Group buying incentivized by risk and impact adjusted rewards |
WO2015042458A1 (en) * | 2013-09-20 | 2015-03-26 | Ebay Inc. | Recommendations for selling past purchases |
Also Published As
Publication number | Publication date |
---|---|
WO2001084416A2 (en) | 2001-11-08 |
AU2000267746A1 (en) | 2001-11-12 |
US6507822B1 (en) | 2003-01-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6119100A (en) | Method and apparatus for managing the sale of aging products | |
US6507822B1 (en) | Method and apparatus for managing the sale of aging products | |
US6754636B1 (en) | Purchasing systems and methods wherein a buyer takes possession at a retailer of a product purchased using a communication network | |
US8010417B2 (en) | System and process for local acquisition of products priced online | |
US8818869B2 (en) | Method and apparatus for managing subscriptions | |
US6970837B1 (en) | Methods and apparatus wherein a buyer arranges to purchase a first product using a communication network and subsequently takes possession of a substitute product at a retailer | |
US8355947B2 (en) | Methods and systems for processing rebates | |
US7107228B1 (en) | Systems and methods wherein a buyer purchases a product at a first price and physically acquires the product at a location associated with a merchant that offers the product for sale at a second price | |
JP2002519775A (en) | Method and system for supplementary product sales in point of sale system | |
US20030023483A1 (en) | System and method for managing consumer purchasing data | |
JP2003516592A (en) | Combined in-store and online participant reward redemption systems and methods | |
JP2001312606A (en) | System and method for electronic transaction | |
US20110264505A1 (en) | Method and system to allow individual sellers to automatically clearance one-of-a-kind listings | |
KR20050106183A (en) | A method for providing an on-line shopping search service and a system thereof | |
KR100426348B1 (en) | Business method of on-line shopping malls reduced the selling price in case of purchasing a numerous products at the same time | |
WO2000079410A2 (en) | Purchasing systems and methods wherein a buyer takes possession at a retailer of a product purchased using a communication network | |
AU775975B2 (en) | System and process for local acquisition of products priced online | |
KR20200093145A (en) | On-demand goods trading system and methods based provider | |
JP2003067600A (en) | Production plan and sales system for product no longer in production | |
KR20030013986A (en) | An apparatus and a method of buying by uniting on-line and off-line and a storage media for having program source thereof | |
JP2002215952A (en) | Price decision system, price decision method and price deciding server | |
JP2002073769A (en) | Ordered commodity nondelivery controller | |
JP2001290983A (en) | Method, system and terminal for transaction, and recording medium | |
JP2002109290A (en) | Materials supplying method, computer network system, server and recording medium | |
JP2002517043A (en) | Method and apparatus for selling aged food as a substitute for an order |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: JSW INVESTMENTS, LLC, CONNECTICUT Free format text: SECURITY INTEREST;ASSIGNOR:WALKER DIGITAL, LLC;REEL/FRAME:013740/0219 Effective date: 20021226 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: WALKER DIGITAL, LLC, CONNECTICUT Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:JSW INVESTMENTS, LLC;REEL/FRAME:017783/0080 Effective date: 20050527 |
|
AS | Assignment |
Owner name: WALKER DIGITAL, LLC, CONNECTICUT Free format text: RELEASE OF SECURITY INTEREST;ASSIGNOR:JSW INVESTMENTS, LLC;REEL/FRAME:018668/0615 Effective date: 20050527 |