WO2000052556A2

WO2000052556A2 - Method and apparatus for processing recurring buyer offers in a demand collection commerce system

Info

Publication number: WO2000052556A2
Application number: PCT/US2000/005741
Authority: WO
Inventors: Jay S. Walker; James A. Jorasch; Daniel E. Tedesco
Original assignee: Priceline-Com Incorporated
Priority date: 1999-03-03
Filing date: 2000-03-03
Publication date: 2000-09-08
Also published as: AU3866900A; WO2000052556A3

Abstract

The present invention provides a system (100) and method whereby to facilitate the creation and processing of recurrent Conditional Purchase Offers. A conditional purchase offer is received, including a buyer-specified condition, an offer price, a payment identifier, and an authorization to pay (108) the offer price with the payment identifier. At least one stipulation is identified for processing the conditional purchase offer on a recurrent basis. The conditional purchase offer is processed on a recurring basis in accordance with the stipulation.

Description

METHOD AND APPARATUS FOR PROCESSING RECURRING BUYER OFFERS IN A DEMAND COLLECTION COMMERCE SYSTEM

The present application is a continuation-in-part of U.S. patent application serial No. 08/997,170, filed 22 December 1997, which is a continuation- in-part of U.S. Patent Application Serial No. 08/923,683, filed September 4, 1997 and U.S. Patent Application Serial No. 08/943,266, filed October 3, 1997, each of which are continuation-in-parts of U.S. Patent Application Serial No. 08/889,319, filed July 8, 1997, which is a continuation-in-part of U.S. Patent Application Serial No. 08/707,660 (now U.S. Patent No. 5,794,207), filed September 4, 1996, each of which is incorporated in its entirety herein by reference.

Field of the Invention

The present invention relates generally to buyer-driven commerce systems, and more particularly to a buyer-driven commerce system that enables a buyer offer to be processed multiple times in accordance with predetermined stipulations. Background of the Invention

Most conventional systems for selling products are seller-driven commerce systems, wherein a seller establishes conditions, including price, for the sale of a product, and buyers determine whether or not to purchase that product.

Examples of seller-driven commerce systems include conventional retail systems, both in a traditional store environment, and in an electronic environment as established on the Internet. Amazon.com, for example, is representative of a traditional seller-driven commerce system, i.e. a bookstore, that has been implemented electronically on the Internet. It is the applicant's belief that the vast majority of consumer sales are transacted using the seller-driven model.

A heretofore less common method of selling products is buyer-driven commerce, where a buyer creates an offer setting the terms and conditions of a potential purchase. The buyer offer is made available to many sellers, for example through a paper or electronic 'want ad,' and interested sellers may contact the buyer to complete the transaction. While much infrastructure has long been established to support seller-driven commerce, buyer-driven commerce represents a somewhat newer, lesser used type of commerce having much less supporting infrastructure. Prior to the existence of electronic networks such as the Internet, and certain business models developed thereunder, applicant's believe no cost-effective infrastructure existed for supporting buyer-driven commerce systems. Facilities for supporting seller-driven commerce include, for example, highly-effective advertising channels, automated payment processing systems, established and readily available fulfillment systems, and other similar facilities for supporting steps of the seller-driven sales process. In contrast, many of the analogous facilities necessary to support buyer- driven commerce do not exist on the same established, economically feasible and effective scale.

Communications and advertising channels through which buyers may reach sellers are not, for example, as well established and effective as are the communications and advertising channels available for sellers to reach buyers. Similarly, it is typically more difficult and time-consuming for a seller to contact a buyer, consummate a transaction, and collect a payment based on a buyer-driven offer, than it is for a seller to perform these same functions in a more traditional seller-driven commerce environment. The development of electronic networks, as well as the invention of new commerce models and infrastructures using these networks, have moved towards making the process of buyer-driven commerce more practical and economically feasible on a large-scale basis.

Priceline.com Incorporated of Stamford, CT is a merchant that has successfully implemented a buyer-driven commerce system for the sale of products such as airline tickets, hotel accommodations, and automobiles. Priceline.com utilizes a Conditional Purchase Offer (CPO) Management System, described in U.S. Patent No. 5,794,207 and International Application Number PCT/US97/15492. that processes buyer-generated conditional purchase offers (CPOs) received from individual consumers. These CPOs contain one or more buyer-defined conditions for the purchase of goods or services, at a buyer-defined price. They may be guaranteed by a general purpose account, such as a debit or credit card account, thereby providing sellers with a mechanism for collecting payments on accepted CPOs. The CPO Management System operates to automatically process CPOs for potential fulfillment by a seller. Automated processing systems developed by priceline.com make the buyer-driven commerce system cost-effective on a large scale. The potential to receive customer offers backed by credit cards, i.e. "guaranteed demand", makes the system very effective for sellers. If a seller accepts a CPO, the CPO Management System may bind the buyer on behalf of the accepting seller, to form a legally binding contract between the parties.

The CPO Management System thus empowers individual consumers to obtain goods and services at their own specified prices. The CPO Management System provides numerous commercial advantages to sellers as well. For example, certain features of the system, including anonymity and data security, enable the seller to adjust his price and terms to meet a consumer offer without publicly undercutting his own retail price structure. This enables the seller to identify and accept incremental, price-sensitive sales in a manner not typically feasible through a conventional retail process.

One characteristic of a CPO as they are currently practiced is that they terminate on the occurrence of a predetermined time and/or a single fulfillment. Unfilled CPOs typically expire upon the passage of a predetermined period of time, for example as specified by a buyer, a seller, or a system operator. A successfully filled CPO becomes inactive, according to current practice, upon its first successful fulfillment by a seller.

While it is necessary in practice for a CPO to terminate, as all offers must eventually terminate, the present method of terminating CPOs provides some drawbacks. In particular, if a buyer wants to attempt and/or make multiple purchases using generally the same CPO terms and conditions, he must re-submit a new CPO after each CPO termination. This may prove difficult and/or time-consuming for a consumer, and may result in purchase opportunities being missed due to a failure to timely resubmit a CPO.

U.S. patent application serial No. 08/997,170, filed 22 December 1997 and incorporated by reference herein above, describes an automated buyer agent system for developing a CPO having variable conditions within buyer- specified limits. Using the described system, the terms and conditions of an unfilled CPO may be adjusted within the specified limits in an attempt to make the CPO more attractive to a seller. The CPO terminates either upon an acceptance and fulfillment by a seller, or upon expiring after remaining unfilled subsequent to adjusting the terms within the buyer's specified limits. In either case it does not solve the problems noted above.

"Buy orders" are known, for example as used on the stock market, wherein a buyer may place an order to buy a specified quantity of goods within defined limits, for example within a certain price range and/or a certain time period. Buy orders, however, represent a single order for multiple products. They are filled, to the best knowledge of Applicants, as quickly as supply becomes available. They do not permit a buyer to control the recurrence of multiple purchases.

Seller-driven commerce tools are known which prompt a buyer to make purchases at the convenience of a seller. Sales offers, promotional events, promotional mailings and the like are examples of tools that sellers use in efforts to motivate buyers to purchase products. Such seller-driven events, however, are not typically within the control of the buyer.

The present inventors have thus determined that it would be desirable to provide a method and system whereby a buyer could establish a CPO having a controllable recurrence. Such a system would enable a buyer to conveniently establish a recurring CPO, with changes to the CPO conditions as specified, to facilitate the processing of the CPO for the purchase of products on a recurring basis. Summary of the Invention

A principle object of the present invention is to provide a system and method to facilitate the creation and processing of recurrent Conditional Purchase Offers. In accordance with one aspect of the present invention there is provided a method and system of processing a buyer-driven commercial transaction, the method comprising the steps of: receiving a conditional purchase offer including a buyer-specified condition, an offer price, a payment identifier, and an authorization to pay the offer price with the payment identifier; identifying at least one stipulation for processing the conditional purchase offer on a recurrent basis; and processing the conditional purchase offer on a recurring basis in accordance with the stipulation.

In accordance with another aspect of the present invention there is provided a method and system of processing a buyer-driven commercial transaction, the method comprising the steps of: receiving a conditional purchase offer including a buyer-specified condition, an offer price, a payment identifier, and an authorization to pay the offer price with the payment identifier; identifying at least one stipulation provided by the buyer for processing the conditional purchase offer on a recurrent basis including at least one specified time for renewing the conditional purchase offer; processing the conditional purchase offer; terminating the conditional purchase offer; retrieving the at least one stipulation; and if the at least one stipulation is satisfied, renewing the conditional purchase offer at the specified time. In accordance with another aspect of the present invention there is provided a method and system of processing a buyer-driven commercial transaction, the method comprising the steps of: receiving a conditional purchase offer including a buyer-specified condition, an offer price, a credit card account identifier, and an authorization to pay the offer price with the credit card account identifier; identifying at least one stipulation provided by the buyer for processing the conditional purchase offer on a recurrent basis including at least one specified time for renewing the conditional purchase offer with at least one amended condition; making the conditional purchase offer available at a first time to a plurality of sellers to fill; terminating the conditional purchase offer; evaluating the predetermined stipulation; and making the conditional purchase offer available at the specified time to a plurality of sellers to fill, if the predetermined stipulation is met. Brief Description of the Drawing Figures These, and other objects, features and advantages of the invention will become apparent from a consideration of the detailed description below, in which:

Fig. 1 is a block diagram of a CPO Management System in accordance with the invention;

Fig. 2 is a block diagram of the central controller of Fig. 1; Fig. 3 is a table showing the data contents of an exemplary seller database;

Fig. 4 is a table showing the data contents of an exemplary buyer database;

Figs. 5 A-B together show a table showing the data contents of an exemplary recurrent offer database;

Fig. 6 is a table showing the data contents of an exemplary processed offer database;

Fig. 7 is a flow chart showing a process for registering a recurrent offer in accordance with the present invention;

Fig. 8 is a flow chart showing a process for creating and processing a first CPO of a plurality of recurrent CPOs;

Fig. 9 is a flow chart showing a process for processing a CPO; and Figs. 1 OA-C together show a flow chart showing a process for processing a recurrent offer in accordance with the present invention. Detailed Description of the Invention

The present invention has application in the field of buyer-driven commerce, used herein to described methods of commerce wherein buyers assemble and submit offers to sellers, the sellers having the opportunity to consider and fill the offer. One traditional method of buyer-driven commerce is the 'want ad,' which may be implemented today both electronically and in paper publications.

The present invention is operative to enable the creation and processing of recurrent buyer-driven offers. In accordance with the present invention, a buyer may create through a single submission an offer that will be assembled and processed recurrently in accordance with buyer stipulations. These stipulations may control, for example, the timing of recurrent buyer offers. For purposes of illustration, the present invention is shown and described with respect to the creation and processing of buyer offers for airline tickets. Using the present invention, a single submission may be used to create a series of recurrent offers for airline tickets on, for example, different dates. It will be understood that the present invention is not limited to offers for airline tickets, but may be practiced to create and process recurrent offers for essentially any goods and/or services. An important subset of buyer-driven commerce is the priceline.com model using conditional purchase offers (CPOs). A conditional purchase offer is a buyer offer that contains at least a buyer-specified condition for the purchase of a product, and a buyer-specified price. A conditional purchase order desirably has some financial obligation on the part of the buyer associated with it, for example a penalty for failure to execute on an offer accepted by a seller. A conditional purchase offer may also be binding, wherein a buyer at the time of offer commits to pay his offer price if a seller accepts the offer. Binding CPOs are typically guaranteed with a financial account identifier, for example a credit or debit card account number. The inclusion of a payment guarantee raises the buyer offer, or demand unit, to the level of "guaranteed demand," making the offer less risky and hence more cost-effective for a seller to consider.

Other features that are applicable to the CPO model include the provision of anonymity to a seller, and the provision of flexible terms and conditions in the buyer's CPO. By making the seller's identity anonymous, at least until the seller accepts an offer, sellers may participate in the system with a much diminished concern about undercutting their own retail structure. By requiring the CPO to include flexible terms, terms that may be specified by the seller (i.e. delivery date, quality, brand name, etc.), the seller is again given the ability to fill the offer with lessened concern about undercutting their own retail structure.

Referring now to Fig. 1, there is shown a CPO management system 100 including a central controller 200 for communicating CPOs and CPO-related information with a plurality of buyers 102 A- 102N, and communicating CPO and seller acceptance-related information with a plurality of sellers 106A- 106N. CPOs and related information may be communicated by any appropriate means, for example, through an electronic network, by telephone, or by mail. CPOs may be received directly from a buyer, or through an agent 104 on behalf of a buyer, the agent shown herein as operating with buyer 102 A.

Further with reference to Fig. 1, central controller 200 is connected to a credit card authorization system 108. Credit card authorization system 108 comprises one of many known commercial business systems that provide the service of authorizing a debit against a consumer credit card account, the account typically identified by an account number embossed on a credit card. Such credit card authorization systems are typically accessed using a telephone connection. In alternate embodiments, credit card authorization system 108 may comprise a system for authorizing a debit against a debit account, or against any other account that may be debited to pay a price. Other suitable payment schemes are discussed in

O'Mahony, Donal, Peirce, Michael, Tewari, Hitesh, Electronic Payment Systems,

Artech House, Inc., 1997, ISBN 0-89006-925-5.

In the described embodiment, buyers communicate with central controller 200 electronically via the Internet, and the central controller in turn communicates with sellers through an appropriate electronic data interface. Buyers

102A-102N would thus communicate with central controller 200 using an appropriate electronic terminal, for example a personal computer. Sellers 106 A-

106N likewise communicate with the central controller 200 through an appropriate computer, for example a personal computer, a server, or a mainframe computer. As will be discussed further below, selected sellers receive CPOs directly from central controller 200, while other sellers provide agency-based rules for use by the central controller to itself evaluate CPOs on behalf of such sellers.

With reference now to Fig. 2, central controller 200 is seen to comprise a generally conventional computer, including a central processing unit (CPU) 202 connected to random access memory 204, a read-only memory 206, and a clock 208. CPU 202 is further connected to a communications port 210, such as a modem or a network interface, and a storage device 212. Storage device 212 can comprise, for example, a conventional combination of magnetic, optical, and/or semiconductor memory.

In accordance with the present invention, storage device 212 is seen to include a seller database 300, a buyer database 400, a recurrent offer database 500, and a processed offer database 600, each of which is described in further detail below. Storage device 212 further includes software instructions for performing a recurrent offer registration process 700 and a recurrent offer evaluation process 800, each of which are also described in further detail below. Central controller 200 further includes those standard hardware and software components necessary to the operation of a computer, as are well known to those of ordinary skill in the art. Referring now to Fig. 3, seller database 300 is seen to include four data records, indicated at 30OA-300D. Each data record includes four data fields: a seller identifier field 302 containing an identifier assigned by central controller 200, a seller name field 304 including an alpha-numeric seller name, a seller contact information field 306 indicating an address or other method of communicating information with a seller, and a seller agent status field 308 indicating whether the seller has provided rules for local evaluation of a CPO by the central controller. Examining, for example, record 300A, Airline 1 is seen to be associated with identifier 1231 and to have an electronic contact address of 'E-ADDRESS#1'. The seller agent status is "no," indicating the seller has not provided rules for local evaluation of CPOs, and is thus to have direct access to CPOs in the manner described below. In contrast, Airline 2 as identified in data record 300B is seen to have provided CPO evaluation rules, which are available for use at a local database address "DBASE- ADDRESS#2." Though not shown, an external contact address or information may also be provided for Airline 2.

With reference now to Fig. 4, there is shown buyer database 400 including three data records 402A, 402B and 402C, each including four fields: a buyer identifier field 404 including an identifier either generated by central controller 200 or provided by a buyer (e.g. a social security number), a financial account identifier field 406 including a financial account identifier such as a credit or debit card number provided by the buyer, a buyer name field 408. and a contact information field 410 including buyer contact information. Examining, for example, record 402A, buyer Joe Smith is seen to have been assigned identifier 4567, to have provided credit card number 111 1-1111-11 1 1-1111 as a financial account identifier, and to have an electronic mail address of srnithfa.isp.com.

With reference now to Figs. 5A and B, recurrent offer database 500 is seen to include three data records 502A, 502B, 502C, each including ten data fields: a recurrent CPO identifier field 504 including a system-generated index number for identifying a recurrent CPO, a buyer identifier field 506 including buyer identifier data from field 404 of buyer database 400 for identifying a buyer, a conditions field 508 including buyer-supplied CPO conditions, and a timing field 510 including buyer-specified quantities and periodicity of purchase conditions for the CPO. Further included in database 500 are a price-per-unit field 512 including a buyer-specified offer price for each unit purchase, a total number of authorized purchases field 514 including the total number of purchases authorized by the buyer for a given CPO, a total number of purchases consummated to date field 516 calculated by the system as CPOs are fulfilled, a submission date/time field 518 supplied by the system when the CPO is received into the system, an expiration date/time field 520 containing an expiration date and optionally an expiration time supplied by the buyer and/or the system, and a status field 522 generated by the system indicating the status of the CPO. Status types and meanings are set out in Table 1 below.

Table 1

Continuing with reference to Figs. 5A and B, the combination of information available from fields 510 and 514 are used together to determine if and when a recurrent CPO is to be generated, and is referred to herein as the buyer recurrence "stipulations." The CPO conditions and recurrence stipulations for each of the illustrated data records are set out and evaluated in Table 2 below.

Table 2 It will thus be understood that, for each recurrent CPO illustrated in database 500, the CPO is repeatedly renewed in accordance with the conditions and the recurrence stipulations to provide multiple offers on desired products. As described above, recurrent CPOs are used to make offers on airline tickets in accordance with periodic ticket purchases specified by the buyer. It will be appreciated that the present invention is not limited to the purchase of airline tickets. Numerous other products, conditions and stipulations will be apparent to a reader.

While not shown, conventional, i.e. non-recurrent CPOs may be identified and stored for processing in database 500, and/or in a separate database. Recurrent CPOs may be identified as distinct from non-recurrent CPOs by, for example, the format of the CPO identifier.

With reference now to Fig. 6, processed offer database 600 is seen to include three data records 602A, 602B, 602C, each including eight data fields: a CPO identifier field 604 generated by the system each time a CPO is processed, a recurrent CPO identifier field 608 containing the recurrent CPO identifier data from field 504 of database 500 when the CPO is a recurrent CPO, a buyer identifier field

610 containing buyer identifier data from field 404 of database 400, and a conditions field 612 containing conditions for the CPO (for recurrent CPOs, copied from field 508 of database 500).

Further included in database 600 is a price-per-purchased-product unit field 614 including the CPO offer price (for recurrent CPOs, copied from field 512 of database 500), a posting date field 616 provided by the system and identifying the date the CPO was made available to buyers, an expiration date field

618 identifying the date the CPO is to expire (provided by the buyer and/or the system, and/or calculated by the system in accordance with the buyer conditions and recurrence stipulations described above), and a status field 620 containing the status of the CPO. The time between the posting date and the expiration date, for as long as the CPO remains unfulfilled, is termed the active period. The different available statuses are described in Table 3 below.

Table 3

Examining, for purposes of illustration, data record 602 A, CPO Identifier "019827038" is seen to identify a recurrent CPO "C92724" submitted by buyer " 1234" for a round-trip ticket from NY to LA, leaving on a Friday and returning on a Sunday. The particular posting date for this recurrent CPO is 1 October 1998 and it would have expired on 8 October 1998. However, the accepted status indicates the CPO was filled by a seller. It will be understood that recurrent CPO "C92724" will result in multiple CPOs such as this one, during different dates, in accordance with the buyer recurrence stipulations as set out in database 500 and discussed above. The CPO identified in data record 602A was generated in accordance with the buyer conditions and recurrence stipulations during the week of 4-9 October 1998.

Continuing to review the contents of database 600, data record 602B is seen to identify CPO data for a non-recurrent, expired CPO. Data record 602C is seen to include CPO data for recurrent CPO "C29176", in accordance with the buyer conditions and recurrence stipulations set out in database 500, and is seen to be active and available for a seller to fill.

Referring now to Fig. 7, a process 700 for receiving for processing, i.e. registering, recurrent CPOs is shown, the first step including receiving the recurrent CPO data from a buyer 102 into system 200 through communications port 210 (step 702). A recurrent CPO includes buyer conditions and recurrence stipulations within the CPO data that define the creation and processing of recurrent CPOs based on the single recurrent CPO submission. Buyer data is read from the recurrent CPO, including a buyer name, contact information, and a financial account identifier, and this buyer information is indexed with a buyer identifier in buyer database 400 (step 704). Continuing with Fig. 7, a recurrent CPO data record is created and the data is populated in recurrent CPO database 500 (step 706). Such data consists of that shown and described with respect to Fig. 5 above, including the buyer conditions and recurrence stipulations necessary to identify and process recurrent CPOs. As an optional step, available buyer credit based on the buyer financial account information may be verified (step 708) as between central controller 200 and credit card authorization system 108 (Fig. 1) in accordance with one of many such processes known in the art.

Still with reference to Fig. 7, the data in recurrent CPO database 500 is queried to identify buyer condition data (from field 508 of database 500) and the buyer recurrence stipulations (from fields 510 and 514) (step 710), and subsequently processed to generate the initial CPO (step 712).

Referring now to Fig. 8, the process 800 of generating a first CPO is initiated by processing buyer conditions to determine a product type (step 802). For purposes of illustration, these steps will be considered in view of the recurrent CPO data record 502A of Fig. 5. The conditions in field 508 are thus seen to identify a round-trip airline ticket from New York to Los Angeles, leaving on a Friday and returning on a Sunday.

Subsequent to the identification of a product, the buyer stipulations in data fields 510 and 514 are used to determine a first CPO active period. Again examining record 502A. the illustrated recurrent CPO is seen to authorize purchases of one ticket per week, up to five tickets during the period of 01 October 1998 through 01 May 1999. It will thus be seen that the first CPO of the recurrent CPOs is to be posted for the remainder of the week, from the date of receipt, which would enable a first ticket to be purchased by the first Friday following the recurrent CPO submission date. Because the submission date is a Thursday evening, the first CPO may be posted for that Thursday evening, 01 October 1998, specifying a ticket for a flight departing on Friday, 02 October 1998, and returning on Sunday, 04 October

1998. (In the event that the system cannot accommodate the purchase of an airline ticket with one day advance notice, the first CPO may be posted that evening, with an active period through the following week, for the purchase of a ticket having a departure date on the following Friday, 09 October 1998, and a return date on Sunday, 11 October 1998.)

Continuing with reference to Fig. 8, subsequent to analyzing the stipulations to determine the first CPO active period, the per-ticket offer price is retrieved from field 512 of database 500 (step 806), and the initial CPO is generated and stored in database 600 (step 808). Examining database 600, the initial CPO for recurrent CPO "C92724" is seen to have been stored in record 602A. The CPO described in record 602A thus shows an active period of 01 October 1998 (i.e. the submission date) through 08 October 1998 (the following Thursday) for the purchase of a round-trip ticket on that Friday (10/09/98), returning that Sunday (10/11/98). The offer price is three hundred dollars. The status in field 620 indicates that the offer has been accepted (and would no longer be active).

With reference now to Fig. 9, a process is shown for processing CPOs, including both recurrent and non-recurrent CPOs. To initiate process 900, a

CPO is identified for processing (step 902). That CPO is made available to remote sellers (also termed 'broadcast-based' sellers) (step 904) and compared to rules provided by rules-based sellers (also termed 'agency-based' sellers) (step 906). The step of making such an offer available to remote sellers may include, for example, transmitting the offer to the remote sellers electronically or by paper, and/or making the offer available for viewing by remote sellers, such as on an Internet website. The step of comparing such an offer to rules includes comparing the terms of the offer to rules of acceptance provided by a seller(s) for local processing and acceptance. Such rules, for example, may be collected and stored in a database in central controller

200.

It is next determined if any seller accepts the CPO (step 908). If neither of steps 904 or 906 identify an accepting seller, then the buyer is notified with a rejection of the offer (step 910). If an acceptance by a seller is identified in step 908, then the accepting seller is identified (step 912) and provided with the necessary buyer data (step 914). The buyer is likewise notified (step 916) of the acceptance, and provided necessary information relating to the seller.

Referring now to Fig. 10A, a recurrent offer evaluation process 1000 is shown for identifying and assembling recurrent offers for processing in accordance with Fig. 9 above. This process may be performed cyclically on a periodic basis, for example once per minute, or continuously on an ongoing basis. To initiate recurrent offer evaluation process 1000, the data in recurrent CPO identifier field 608 of processed CPO database 600 is accessed to identify recurrent offers (step 1002). If no recurrent offers exist in the database (step 1004), the process cycles back to perform the first step 1002 at the beginning of the next process cycle. If one or more recurrent CPOs are identified in database 600 (step 1004), the status and the expiration dates, in fields 522 and 520, respectively, are examined to determine if any recurrent CPO is newly expired or newly accepted (step 1006). Newly expired CPOs will have a status of active and an expiration date of post the last cycle of the current process. One method to determine if a CPO is newly accepted, is for the system to store the previous status conditions from the last process cycle, and compare them to the current status conditions in the most recent process cycle. If a newly accepted CPO is identified, the total purchases consummated field 516 of database 500 is incremented for the corresponding CPO data record (step 1008).

With reference now to Fig. 10B, the total purchases consummated (field 516 of database 500) is then compared to the total purchases authorized (field 514 of database 500) (step 1010). If they are equal, then the corresponding status in field 522 of database 500 is set to terminated (step 1012), and the process ends. If the total purchases consummated is less than the total purchases authorized, then the buyer stipulations are retrieved from fields 510 and 514 (step 1014), and it is determined if the CPO has expired (step 1015). A CPO has expired if the expiration date in field 518 is equal to or earlier than the current date. If the CPO is expired, then the status is set to "terminated" (step 1012) and the process ends. If, in accordance with the buyer stipulations, the CPO is not expired, then the active period for the next recurrent CPO is calculated (step 1016). For example, with respect to the CPO defined in data record 502 A, the next active period will be that which enables the purchase of a single round-trip ticket having the conditions specified: i.e. NY-LA, leave Friday, return Sunday.

With reference now to Fig. 10C, if the current date does not mark the beginning of the next CPO active period, then the process enters into a sub-loop for the particular recurrent CPO, cycling back to step 1016 while waiting for the beginning of the active period to arrive (step 1018). If the current date coincides with the calculated active period of the next recurrent CPO, (step 1018), then the corresponding recurrent CPO offer price is retrieved from field 512 (step 1020) to generate the recurrent CPO (step 1022) for storing in database 600 (step 1024). The newly recurrent CPO is then processed in accordance with the process of Fig. 9 above.

While the present invention has been shown and described with respect to specific embodiments, it is not thus limited. Numerous modifications, changes and improvements falling within the scope of the invention will occur to those skilled in the art.

Claims

What is claimed is:

1. A method of processing a buyer-driven commercial transaction, comprising: receiving a conditional purchase offer including a buyer- specified condition, an offer price, a payment identifier, and an authorization to pay said offer price with said payment identifier; identifying at least one stipulation for processing said conditional purchase offer on a recurrent basis; and processing said conditional purchase offer on a recurring basis in accordance with said stipulation.

2. The method of claim 1 wherein said processing step includes making said conditional purchase offer available to a plurality of sellers.

3. The method of claim 2 wherein said at least one stipulation is provided by a buyer.

4. The method of claim 3 wherein said at least one stipulation is based on a periodicity of time. 0

5. The method of claim 3 wherein said at least one stipulation is based on a quantity of purchases resulting from said conditional purchase offer.

6. A system for processing a buyer-driven commercial _< transaction, comprising: a processor; a memory connected to said processor and including instructions for controlling said processor, said processor operative with said instructions to 0 receive a conditional purchase offer including a buyer- specified condition, an offer price, a payment identifier, and an authorization to pay said offer price with said payment identifier, identify at least one stipulation for processing said conditional 5 purchase offer on a recurrent basis, and o process said conditional purchase offer on a recurring basis in accordance with said stipulation.

7. The system of claim 6 wherein said processing step includes making said conditional purchase offer available to a plurality of sellers.

5

8. The system of claim 7 wherein said at least one stipulation is provided by a buyer.

9. The method of claim 8 wherein said at least one stipulation is 10 based on a periodicity of time.

10. The method of claim 8 wherein said at least one stipulation is based on a quantity of purchases resulting from said conditional purchase offer.

11. A system for processing a buyer-driven commercial

15 transaction, comprising: means for receiving a conditional purchase offer including a buyer-specified condition, an offer price, a payment identifier, and an authorization to pay said offer price with said payment identifier; ^^υ means for identifying at least one stipulation for processing said conditional purchase offer on a recurrent basis; and means for processing said conditional purchase offer on a recurring basis in accordance with said stipulation.

2 12. A computer readable medium storing instructions for controlling a computer to process a buyer-driven commercial transaction, comprising: a program instruction for receiving a conditional purchase _Q offer including a buyer-specified condition, an offer price, a payment identifier, and an authorization to pay said offer price with said payment identifier; a program instruction for identifying at least one stipulation for processing said conditional purchase offer on a recurrent basis; and a program instruction for processing said conditional

35 purchase offer on a recurring basis in accordance with said stipulation.

13. A method of processing a buyer-driven commercial transaction, comprising: receiving a conditional purchase offer including a buyer- specified condition, an offer price, a payment identifier, and an authorization to pay said offer price with said payment identifier; identifying at least one stipulation provided by said buyer for processing said conditional purchase offer on a recurrent basis including at least one specified time for renewing said conditional purchase offer; processing said conditional purchase offer; terminating said conditional purchase offer; retrieving said at least one stipulation; and if said at least one stipulation is satisfied, renewing said conditional purchase offer at said specified time.

14. A method in accordance with claim 13 wherein said stipulation includes at least one amended buyer-specified condition for the renewed conditional purchase offer; and said renewing step including renewing said conditional purchase offer with said at least one amended condition.

15. A method in accordance with claim 13 wherein said terminating step is responsive to the expiration of said conditional purchase offer after a predetermined period of time.

16. A method in accordance with claim 13 wherein said terminating step is responsive to the successful fulfillment of said conditional purchase offer.

17. A system for processing a buyer-driven commercial transaction, comprising: a processor; a memory connected to said processor and storing instructions for controlling the operation of said processor; said processor operative with said instructions in said memory to receive a conditional purchase offer including a buyer-specified condition, an offer price, a payment identifier, and an authorization to pay said offer price with said payment identifier; identify at least one stipulation provided by said buyer for processing said conditional purchase offer on a recurrent basis including at least one specified time for renewing said conditional purchase offer; process said conditional purchase offer; terminate said conditional purchase offer; retrieve said at least one stipulation; and if said at least one stipulation is satisfied, renew said conditional purchase offer at said specified time.

18. A system in accordance with claim 17 wherein said stipulation includes at least one amended buyer-specified condition for the renewed conditional purchase offer; and said renewing operation including renewing said conditional purchase offer with said at least one amended condition.

19. A system in accordance with claim 17 wherein said terminating operation is responsive to the expiration of said conditional purchase offer after a predetermined period of time.

20. A system in accordance with claim 17 wherein said terminating operation is responsive to the successful fulfillment of said conditional purchase offer.

21. A system for processing a buyer-driven commercial transaction, comprising: means for receiving a conditional purchase offer including a buyer-specified condition, an offer price, a payment identifier, and an authorization to pay said offer price with said payment identifier; means for identifying at least one stipulation provided by said buyer for processing said conditional purchase offer on a recurrent basis including at least one specified time for renewing said conditional purchase offer; means for processing said conditional purchase offer; means for terminating said conditional purchase offer; o means for retrieving said at least one stipulation; and means for, if said at least one stipulation is satisfied, renewing said conditional purchase offer at said specified time.

22. A computer-readable medium storing instructions for 5 controlling a computer to process a buyer-driven commercial transaction, comprising: a program instruction for receiving a conditional purchase offer including a buyer-specified condition, an offer price, a payment identifier, and „ an authorization to pay said offer price with said payment identifier; a program instruction for identifying at least one stipulation provided by said buyer for processing said conditional purchase offer on a recurrent basis including at least one specified time for renewing said conditional purchase offer; 5 a program instruction for processing said conditional purchase offer; a program instruction for terminating said conditional purchase offer; 0 a program instruction for retrieving said at least one stipulation; and a program instruction for, if said at least one stipulation is satisfied, renewing said conditional purchase offer at said specified time. 5

23. A method of processing a buyer-driven commercial transaction, comprising: receiving a conditional purchase offer including a buyer- specified condition, an offer price, a credit card account identifier, and an authorization to pay said offer price with said credit card account identifier; identifying at least one stipulation provided by said buyer for processing said conditional purchase offer on a recurrent basis including at least one specified time for renewing said conditional purchase offer with at least one amended condition; 5 making said conditional purchase offer available at a first time to a plurality of sellers to fill; terminating said conditional purchase offer; evaluating said predetermined stipulation; and making said conditional purchase offer available at said specified time to a plurality of sellers to fill, if said predetermined stipulation is met.

24. A method in accordance with claim 23 and further including the step of repeating said steps of evaluating said predetermined stipulation and processing said conditional purchase offer again if said predetermined stipulation is met, until said predetermined stipulation is not met.

25. A system for processing a buyer-driven commercial transaction, comprising: a processor; a memory connected to said processor and storing instructions for controlling the operation of said processor; said processor operative with said instructions in said memory to receive a conditional purchase offer including a buyer-specified condition, an offer price, a credit card account identifier, and an authorization to pay said offer price with said credit card account identifier; identify at least one stipulation provided by said buyer for processing said conditional purchase offer on a recurrent basis including at least one specified time for renewing said conditional purchase offer with at least one amended condition; make said conditional purchase offer available at a first time to a plurality of sellers to fill; terminate said conditional purchase offer; evaluate said predetermined stipulation; and make said conditional purchase offer available at said specified time to a plurality of sellers to fill, if said predetermined stipulation is met.

26. A system in accordance with claim 25, said processor further operative to repeat said operations of evaluating said predetermined stipulation and processing said conditional purchase offer again if said predetermined stipulation is met, until said predetermined stipulation is not met.

27. A system for processing a buyer-driven commercial transaction, comprising: means for receiving a conditional purchase offer including a buyer-specified condition, an offer price, a credit card account identifier, and an authorization to pay said offer price with said credit card account identifier; means for identifying at least one stipulation provided by said 0 buyer for processing said conditional purchase offer on a recurrent basis including at least one specified time for renewing said conditional purchase offer with at least one amended condition; means for making said conditional purchase offer available at a first time to a plurality of sellers to fill; means for terminating said conditional purchase offer; means for evaluating said predetermined stipulation; and means for making said conditional purchase offer available at said specified time to a plurality of sellers to fill, if said predetermined stipulation is ⁰ met.

28. A computer-readable medium storing instructions for controlling a computer to process a buyer-driven commercial transaction, comprising:

25 a program instruction for receiving a conditional purchase offer including a buyer-specified condition, an offer price, a credit card account identifier, and an authorization to pay said offer price with said credit card account identifier;

~_ft a program instruction for identifying at least one stipulation provided by said buyer for processing said conditional purchase offer on a recurrent basis including at least one specified time for renewing said conditional purchase offer with at least one amended condition; a program instruction for making said conditional purchase

35 offer available at a first time to a plurality of sellers to fill; a program instruction for terminating said conditional purchase offer; a program instruction for evaluating said predetermined stipulation; and a program instruction for making said conditional purchase offer available at said specified time to a plurality of sellers to fill, if said predetermined stipulation is met.