Background of the Invention Most systems for processing the sale of products are seller-driven, whereby the seller prices, packages and configures the product, and the buyer decides whether or not to accept. Traditionally, the seller must attract buyers and complete the sale. Thus, in a seller-driven system, the advertising cost of the transaction and the attendant risks that such advertising will be unsuccessful falls upon the seller.

Typically, goods and services are sold in a retail environment using a seller-driven protocol, whereby the seller generally sets a non-negotiable price that the buyer may accept or reject. Other forms of commerce provide more flexibility and permit the exchange of offers and counteroffers. In an auction, for example, the buyer does not find the seller, rather the seller attracts numerous buyers who collectively determine the final selling price, which the seller may subsequently reject unless the item auctioned is being sold without a reserve. Other commerce systems, such as NASDAQ or the New York Stock Exchange (NYSE), are exchange-driven, where buyers and sellers are matched by offering an efficient, fair and orderly marketplace.

Such exchange-driven systems favor neither buyers nor sellers, but simply effectuate communications that allow for the matching process to take place. An example of an automated exchange-driven commerce system for trading futures is disclosed in United States Patent Number 4,903,201.

A buyer-driven system, on the other hand, is one where the buyer dictates the terms of the offer and the seller decides whether or not to accept. A"help wanted"advertisement, for example, is a buyer-driven inquiry since the employer is looking to locate and buy the services of a qualified employee. The inquiry is advertised to a large number of potential employees, who may respond by submitting their resumes to the prospective employer. Generally, buyer-driven systems are more

preferable than other systems for processing the sale of products. For example, buyer- driven systems provide buyers with more control over the terms and conditions of the purchase of a desired product. Additionally, when a large number of potential sellers exist, but those sellers do not have the resources to advertise globally, buyers can take the initiative to communicate their needs to the sellers.

Unilateral buyer-driven systems seek to consummate contracts between buyers and sellers based on acceptance of an offer by performance of a designated task.

For example, in a reward system, a"buyer"broadcasts or publishes an offer for a reward to anyone who completes a particular task. Thus, unilateral systems can be utilized only for limited types of transactions that allow for acceptance by performance.

Bilateral buyer-driven systems, on the other hand, seek to consummate contracts between buyers and sellers based on mutual promises to perform. Bilateral buyer- driven systems, however, require buyers to invest a lot of time, money and other resources to locate an indefinite number of potential sellers and communicate the buyer's purchasing needs to each seller. Any benefits to the consumer with conventional bilateral buyer-driven systems, however, including a potentially lower price, are typically outweighed by the amount of time and money expended in the effort.

In addition, buyer-driven systems impose inherent costs on sellers as well. If each buyer has a different set of purchasing specifications and communicates his needs using non-uniform language, sellers must pay a substantial cost to review and understand each individual request. Moreover, sellers are often not amenable to customizing their products for individual buyers.

An example of a regularly used bilateral buyer-driven process is the system utilized by large organizations, such as companies or governments, who want to purchase significant amounts of goods or services at the lowest possible price. Initially, purchasers formulate a detailed written specification, typically called a"Request for Proposal" (RFP), setting forth the quantities and requirements of what they are looking to buy. Once finalized, the RFPs are then distributed to a list of known potential suppliers. Potential suppliers then screen the RFPs to identify those that they might be able to fulfill, and thereafter determine whether or not to invest the necessary time and effort to submit a formal binding proposal to the buyer by a deadline established in the RFP. Once submitted, the proposals are evaluated by the buyer, and the supplier

corresponding to the selected proposal is notified that it has"won"the business at the price quoted.

Large organizations can take advantage of the benefits afforded by the RFP process because their volume buying represents a worthwhile opportunity for suppliers to compete for their business and large organizations have the resources to communicate their buying needs to a sufficient number of suppliers. As a result, large organizations can often achieve substantial unit cost savings, especially on commodities or commodity services (such as paper clips or long distance service) and on perishable items (such as airline tickets and hotel rooms). Individual consumers, however, cannot effectively participate in such bilateral buyer-driven systems because they generally do not have the buying power and resources of large organizations.

As commerce seeks to utilize the inherent advantages of the Internet, many systems for processing the sale of products, such as malls, catalogs and auction houses, are being implemented on the Internet. These approaches generally seek to create better seller or exchange-driven systems whereby the sale of goods and services is made more efficient. While there have been some attempts to use the Internet to effectuate bilateral buyer-driven transactions, those attempts have been largely unsuccessful. For example, buyers can post"wanted"advertising at little or no cost on "bulletin board"type Internet sites. Thus, consumers can essentially post their own RFP to a large number of sellers willing to sell them the exact product they are looking for.

In practice, however, it is impractical for potential sellers to frequent the various "bulletin board"sites or respond to the individual RFPs which typically have diverse formats, conditions, terms, and language styles. In addition, sellers are deterred from using such a process because there is (i) no guarantee of the authenticity of the RFP, (ii) the cost of negotiating with individual consumers is often too high, and (iii) it is difficult to enforce any agreement (including payment guarantees) which may be reached between the consumer and the seller. In turn, the absence of a critical mass of sellers reduces the incentive for buyers to post their RFPs.

Many industries, as well as consumers, would benefit from an effective bilateral buyer-driven system. Recently, for example, the travel industry has experienced explosive worldwide growth. As travel capacity continues to increase, it is expected that capacity will outpace projected traveler volumes, thereby reducing

utilization and putting pressure on pricing. In order to deal with such pricing and inventory challenges, many travel-related sellers have developed sophisticated revenue management systems (RMSs) to optimize revenue by dynamically setting the price for available inventory. Generally, when inventory is first added by a seller, the seller's revenue management system attempts to maximize revenue for the inventory by establishing a plurality of price classes and then allocating the inventory and price assigned to each price class. The revenue management system thereafter continues to monitor the actual demand within each price class relative to forecasted demand, dynamically reevaluating the inventory allocation and pricing of each price class for given inventory.

While conventional revenue management systems employ sophisticated tools to anticipate future travel needs, forecasting errors invariably lead to unanticipated excess capacity. In addition, a seller can utilize its revenue management system to forecast anticipated excess capacity, such as excess capacity on a given flight associated with seats that are predicted to be empty. Furthermore, unexpected external events, such as a price war or extreme weather conditions, can also affect a seller's excess capacity. Thus, in an attempt to reduce such excess capacity, sellers periodically reevaluate the inventory allocation and pricing. Travel-related sellers cannot simply discount the published prices for such unsold inventory, however, without either starting a price war or compromising their own underlying price structure (i. e., without also reducing its full-fare prices for full-fare travelers). Thus, there is currently no effective way for travel-related sellers to dispose of such excess capacity.

Travel-related sellers recognize that there is a large source of latent demand associated with leisure travelers who are willing to travel at a favorable price.

There is currently no effective way, however, for such sellers to receive an offer from a buyer for leisure travel at a particular price set by the buyer, below the seller's published price. In particular, there is no effective way for the seller to be confident that if the seller accepts the buyer's offer, the buyer will travel in accordance with the offer, without using the information to ascertain the seller's underlying level of price flexibility, which, if known to a seller's competitors or buyers, could dramatically impact the seller's overall revenue structure.

Similarly, with the long distance telephone market becoming nearly saturated with supply, competition among long distance carriers for new business has increased dramatically. Although the costs associated with long distance calls have dropped and are expected to continue dropping dramatically in the United States and other countries as the result of increased competition, the cost of a long distance call remains sufficiently high to discourage many people from placing as many long distance calls as they would like. In addition, most callers are typically unfamiliar with the rate structure associated with placing calls to various geographical areas at various times of day. Thus, the inability to identify and control the cost of a long distance call has further contributed to the reluctance of many people to place more long distance calls.

While many large customers, such as corporate customers, often have sufficient leverage to negotiate their long distance rates with a long distance carrier, or to permit carriers to bid for their account, it is impractical, given current telephone systems, for long distance providers to individually negotiate long distance rates with the average consumer. In addition, many large customers have accounts with a number of different long distance carriers, and employ"least cost routing"technology in their proprietary private branch exchange (PBX) switches or other customer-premises equipment. This technology enables them to select the most cost-effective carrier on a per-call basis using stored rate information. Again, such a cost-reduction solution is not available to the average consumer, who typically has only one long distance provider.

While systems have been developed to allow consumers to identify a long distance carrier offering the most cost-effective published rate to complete a call, such systems do not facilitate real-time negotiation with individual carriers, or permit one or more telephone calls to be completed in accordance with restrictions specified by the calling party.

In addition, conventional commerce systems limit the ability of resellers of tickets for events, such as a concert, play or sporting event, to advertise ticket availability and complete a ticket transaction. Currently, ticket resellers may utilize classified advertisements, electronic bulletin boards or"chat rooms"on the Internet to advertise ticket availability. Such advertisements are difficult to remove from the public realm once the tickets are resold. Thus, a person selling a ticket may get

inquiries after the ticket has been sold. In addition, the buyer requires physical possession of the actual ticket, and delivery immediately prior to the event may be problematic. Furthermore, buyers and sellers of tickets possess a general distrust of each other. Unless a buyer is face-to-face with a ticket reseller, the buyer is typically unwilling to pay for tickets without some assurance of delivery. Likewise, a ticket reseller is typically unwilling to deliver tickets without payment in advance.

Conventional ticket reselling systems, however, do not provide any mechanism for guaranteeing the authenticity of either the buyer or the seller.

In addition to the above-described drawbacks of known commerce systems, sellers often require information relevant to a buyer's offer from a third party in order to determine whether to accept the offer. For example, potential buyers of artworks require that the artworks be accompanied by a trusted third party's"seal of approval."Such a seal would typically authenticate that the artworks are genuine, and also appraise their value. Similarly, potential lenders of funds require the credit history or a"credit score"of a potential borrower. Lenders would typically not accept such critical information from the potential borrower, since the borrower might try to alter the information to appear more credit-worthy. The credit information must come from a trusted third party.

Accordingly, an offer to borrow funds, which would include borrower- specified conditions, such as an interest rate and loan amount, would, by itself, be insufficient for the lender to determine whether to accept the offer. Potential lenders would not be able to ascertain whether the offer was acceptable in terms of credit risk and credit worthiness. Thus, buyers would not be able to usefully make such offers.

Current systems for evaluating borrower credit risks in connection with the sale of financial products, such as the system disclosed in United States Patent Number 5,611,052, do not permit potential borrowers to specify desired loan conditions. In addition, the system disclosed in United States Patent Number 5,611,052 does not prevent people who do not intend to buy from inundating a seller of financial products with worthless loan applications.

As apparent from the above deficiencies with conventional systems for processing the sale of products, a need exists for a bilateral buyer-driven system, capable of being utilized by individual consumers to communicate their purchasing

needs globally to potential sellers, which addresses the deficiencies of the prior art. A further need exists for a bilateral buyer-driven system which authenticates the terms and conditions of buyer offers. There is also a need for third party administration in such a bilateral buyer-driven system to resolve contract disputes between the parties, increase buyer and seller confidence in the system and establish standard protocols, formats, terms and language to be used in buyer-specified offers. A further need exists for a system that permits a seller to sell excess capacity when actual demand fails to meet forecasted demand. Another need exists for a buyer-driven system that permits a buyer to obtain products at a price set by the buyer, typically below the published price of the product. Yet another need exists for a system that permits sellers to stimulate sales of excess inventory or capacity, without compromising the seller's published price structure. Finally, there is a further need for a system that allows sellers to evaluate the acceptability of an offer from a buyer in light of information relevant to the offer from a third party.

Summary of the Invention A conditional purchase offer (CPO) management system for consummating a binding contract between a remote prospective buyer and a remote potential seller is disclosed, including a memory device, and a processor disposed in communication with the memory device, the processor configured to receive from the remote prospective buyer (a) a purchase offer containing at least one condition, and (b) a payment identifier for specifying a general purpose financial account from which funds may be paid for a purchase meeting the at least one condition, the processor further configured to transmit the purchase offer to a plurality of remote potential sellers, and receive from at least one of the remote potential sellers an unconditional acceptance of the offer. In one embodiment of the invention, the processor is further configured to initiate the use of the payment identifier to effect payment for the purchase from the buyer, and the general purpose financial account is a credit card account. In various embodiments of the invention, the at least one condition may be selected from the group consisting of price, quantity, delivery date, quality, geographic location, and anonymity.

A system according to another embodiment of the present invention, that permits the CPO management system to accept or reject a given CPO on behalf of certain agency-based sellers who have delegated such authority to the CPO management system, is disclosed, including a communications port and a processor. The communications port obtains a purchase offer for travel from a customer and receives one or more rules from a plurality of sellers. The purchase offer contains at least one customer-defined condition and each of the rules contains one or more seller-defined restrictions. The processor compares the purchase offer to the rules to determine whether the customer-defined condition satisfies each of the seller-defined restrictions of at least one of the rules.

In one embodiment, if a CPO is accepted by more than one seller, the CPO management system executes a post-sell multi-bind process to permit each accepting seller to directly market to the customer and post-sell their product. Thus, the customer still selects for himself which seller acceptance to utilize, based on materials or incentives furnished by each seller. The customer is bound by the CPO management system, in accordance with the terms of the CPO, and is obligated to purchase the goods or services specified by the CPO, but the buyer may decide which seller to utilize, based on materials or incentives provided to the customer directly by each accepting seller.

A CPO submitted by a customer can specify one or more preferred sellers. Thus, the CPO management system provides the CPO to each specified seller to determine if one or more of the sellers are willing to accept the CPO. In a supplemental embodiment, the CPO management system preferably executes an excluded seller CPO evaluation process to provide the CPO to the excluded sellers who may make counteroffers to the customer, in an attempt to obtain the business, before one of the specified sellers accepts the CPO. The CPO can be provided to the excluded sellers before, or contemporaneously with, the preferred sellers.

A system according to another embodiment of the present invention, suitable for processing the sale of packages of goods and services, is disclosed, including a communications port and a processor. The communications port receives a purchase offer for a package from a customer. The purchase offer contains a description of each component item and a payment identifier for specifying a general- purpose account from which funds may be paid. The processor deconstructs the

package purchase offer into a plurality of component purchase offers and determines if each of the component purchase offers are accepted by one or more potential sellers.

The customer is thereby bound to purchase the package if an acceptance is received for each of the component purchase offers.

A system according to another embodiment of the present invention, suitable for processing purchase offers for one or more telephone calls, is disclosed, including a communications port and a processor. The communications port obtains a purchase offer from a customer for one or more telephone calls and provides the purchase offer to a plurality of potential carriers. The purchase offer contains at least one customer-defined condition and a payment identifier for specifying a manner in which funds will be paid. The processor determines if one or more of the carriers accepts the purchase offer and binds the customer to purchase the telephone calls if an acceptance is received for the purchase offer.

A method according to another preferred embodiment of the present invention suitable for reselling event tickets includes: a potential buyer electronically transmitting a guaranteed purchase offer for a ticket to a central controller; the central controller electronically making the offer available to a plurality of potential sellers; a first-accepting seller transmitting an acceptance of the offer to the central controller; and the central controller transmitting this acceptance to the buyer along with a code to use at a venue to verify his purchase of the ticket.

Thus, one preferred embodiment of the present invention provides individuals a quick and easy way to purchase a ticket from a ticket reseller, and allows them to avoid the traditional problems of the ticket resale market. Moreover, ticket resellers can sell a ticket based on a guaranteed purchase offer provided by a potential buyer. In addition, the present invention includes mechanisms which prevent fraud both during and after the transaction.

Generally, according to a further embodiment of the present invention, that permits sellers to evaluate the acceptability of an offer from a buyer in light of information relevant to the offer from a third party, a central controller receives an offer signal including at least one condition signal. The offer signal defines a conditional purchase offer having at least one condition from a customer. The central controller also receives a payment identifier signal for specifying an account from which funds

may be paid. An informational signal relevant to the offer is received from a third party. The informational signal typically includes relevant information that would not be trusted if it came from the borrower submitting the conditional purchase offer.

A more complete understanding of the present invention, as well as further features and advantages of the present invention, will be obtained by reference to the following detailed description and drawings.

Brief Description of the Drawings Figure 1 illustrates a first embodiment of the present invention.

Figure 2 is a block diagram showing one embodiment of the central controller.

Figure 3 is a block diagram showing one embodiment of the seller interface.

Figure 4 is a block diagram showing one embodiment of the buyer interface.

Figure 5 illustrates an embodiment showing how a conditional purchase offer is generated.

Figure 6 illustrates an embodiment showing the acceptance of a conditional purchase offer by the central controller.

Figure 7 illustrates an embodiment showing the activation of a conditional purchase offer.

Figure 8 illustrates one embodiment of the maintenance of active conditional purchase offers.

Figure 9 illustrates an embodiment showing the seller selecting a conditional purchase offer.

Figures 10 and 11 illustrate an embodiment showing the binding of a conditional purchase offer.

Figure 12 illustrates an exemplary procedure for exchanging goods and payment between buyer and seller.

Figure 13 illustrates an exemplary payment method.

Figures 14 through 17 illustrate an exemplary authentication procedure using cryptographic protocols.

Figures 18 and 19 illustrate an exemplary embodiment for counteroffers by a seller.

Figure 20 illustrates an embodiment showing the use of a trusted server and a bonding agency.

Figure 21 is a schematic block diagram illustrating a conditional purchase offer (CPO) management system in accordance with one embodiment of the present invention.

Figure 22 is a schematic block diagram of the exemplary CPO management central server of Figure 21.

Figure 23 is a schematic block diagram of the exemplary secured airline server of Figure 21.

Figure 24 is a schematic block diagram of the exemplary central reservation system of Figure 21.

Figure 25a is a schematic block diagram of the exemplary reservation management system (RMS) of Figure 21.

Figure 25b illustrates the interaction between the RMS, the airline reservation system and the various databases depicted in Figure 25a, during a conventional pricing and allocation process and the CPO rules generation process of Figure 39.

Figure 25c illustrates the actual demand over time for airline tickets within a given fare class, relative to forecasted demand.

Figure 26 illustrates a sample table from the customer database of Figure 22.

Figure 27 illustrates a sample table from the airline database of Figure 22.

Figure 28 illustrates a sample table from the flight schedule database of Figures 22 and 24.

Figures 29a and 29b, collectively, illustrate a sample table from the CPO database of Figure 22.

Figure 30a illustrates a sample table from the secured airlines rules database of Figure 23.

Figures 30b and 30c, collectively, illustrate alternative sample tables to the secured airlines rules database of Figure 23.

Figure 31 illustrates a sample table from the counteroffer rules database of Figure 23.

Figure 32 illustrates a sample table from the secured airline audit database of Figure 23.

Figure 33 illustrates a sample table from the pricing and restrictions database of Figures 24 and 25a.

Figure 34 illustrates a sample table from the seat allocation database of Figures 24 and 25a.

Figure 35 illustrates a sample table from the forecast and demand analysis database of Figure 25a.

Figures 36a through 36c, collectively, are a flow chart describing an exemplary CPO management process implemented by the CPO management central server of Figure 22.

Figures 37a and 37b, collectively, are a flowchart describing an exemplary evaluation process implemented by the secured airline server of Figure 23.

Figure 38 is a flow chart describing an exemplary audit process implemented by the secured airline server of Figure 23.

Figure 39 is a flow chart describing an exemplary CPO rule generation process implemented by the revenue management system of Figure 25a.

Figures 40a and 40b, collectively, illustrate an alternative sample table from the CPO database of Figure 22 for a cruise implementation.

Figure 41 illustrates an alternative sample table from the secured rules database of Figure 23 for a cruise implementation.

Figure 42 is a flow chart describing an exemplary post-sell multi-bind process which may be implemented by the CPO management central server of Figure 22.

Figure 43 illustrates a sample table from the excluded operator counteroffer database which may be implemented by the CPO management central server of Figure 22 in conjunction with the flow chart of Figures 44a and 44b.

Figures 44a and 44b, collectively, are a flow chart describing an exemplary excluded seller CPO evaluation process which may be implemented by the CPO management central server of Figure 22.

Figure 45 is a schematic block diagram illustrating a package conditional purchase offer (CPO) management system in accordance with one embodiment of the present invention.

Figure 46 is a schematic block diagram of the exemplary central controller of Figure 45.

Figure 47 is a schematic block diagram of the exemplary secured server of Figure 45.

Figure 48 is a schematic block diagram of an exemplary buyer or seller interface of Figure 45.

Figure 49 illustrates a sample table from the buyer database of Figure 46.

Figure 50 illustrates a sample table from the seller database of Figure 46.

Figure 51 illustrates a sample table from the package CPO database of Figure 46.

Figure 52 illustrates a sample table from the component CPO database of Figure 46.

Figure 53 illustrates a sample table from the market price database of Figure 46.

Figures 54a and 54b illustrate sample tables from the secured seller rules database of Figure 47.

Figures 55a through 55c, collectively, are a flow chart describing an exemplary package CPO posting process implemented by the central controller of Figure 46.

Figures 56a through 56c, collectively, are a flowchart describing an exemplary package CPO monitoring process implemented by the central controller of Figure 46.

Figure 57 is a flow chart describing an exemplary component CPO rule evaluation process implemented by the secured server of Figure 47.

Figure 58A is a schematic block diagram illustrating a conditional purchase offer (CPO) management system in accordance with one embodiment of the present invention.

Figure 58B is a schematic block diagram illustrating a conditional purchase offer (CPO) management system in accordance with an alternate embodiment of the present invention.

Figure 59 is a perspective view of an illustrative telephone set utilized by the calling party of Figures 58A or 58B.

Figure 60 is a schematic block diagram of a central server used by the CPO management system of Figure 58.

Figure 61 illustrates a sample table from the customer database of Figure 60.

Figure 62 illustrates a sample table from the carrier database of Figure 60.

Figure 63 illustrates a sample table from the published rate database of Figure 60.

Figure 64 illustrates a sample table from the CPO database of Figure 60.

Figures 65a and 65b, collectively, are a flow chart describing an exemplary CPO management process implemented by the central server of Figure 60.

Figures 66a and 66b, collectively, are a flow chart describing an exemplary IVRU process implemented by the central server of Figure 60.

Figure 67 is a schematic view of a system according to one embodiment of the present invention.

Figure 68 is a schematic view of a central controller used in the system of Figure 67.

Figure 69 is a schematic view of a remote user terminal used in the system of Figure 67.

Figure 70 is a schematic view of a venue controller used in the system of Figure 67.

Figure 71 a is a table illustrating the contents of an event table used in the system of Figure 67.

Figure 71b is a table illustrating the contents of a venue table used in the system of Figure 67.

Figure 71c is a table illustrating the contents of a customer table used in the system of Figure 67.

Figure 71d is a table illustrating the contents of an offer table used in the system of Figure 67.

Figure 7 1 e is a table illustrating the contents of a transaction table used in the system of Figure 67.

Figure 72a is a table illustrating the contents of a ticket table used in the system of figure 67.

Figure 72b is a table illustrating the contents of a replacement ticket table used in the system of figure 67.

Figures 73a-73g are flow diagrams depicting a method of submitting and accepting a guaranteed offer to buy an event ticket over the Internet according to one embodiment of the present invention.

Figure 74 is a schematic illustration of a system for processing the sale of products provided in accordance with the present invention.

Figure 75a is a schematic illustration of an embodiment of a central controller of the system of Figure 74.

Figure 75b is a schematic illustration of another embodiment of a central controller of the system of Figure 74.

Figure 76 is a schematic illustration of a borrower database of the central controller of Figures 75a and 75b.

Figure 77 is a schematic illustration of a lender database of the central controller of Figures 75a and 75b.

Figure 78 is a schematic illustration of an offer database of the central controller of Figures 75a and 75b.

Figure 79 is a schematic illustration of a credit report database of the central controller of Figures 75a and 75b.

Figure 80 is a schematic illustration of a collateral database of the central controller of Figures 75a and 75b.

Figure 81a is a schematic illustration of a response database of the central controller of Figure 75a.

Figure 81b is a schematic illustration of a rule database of the central controller of Figure 75b.

Figures 82a and 82b are flowcharts showing a method for processing sales of a loan between a borrower terminal and lender terminals.

Figure 82c is a flowchart showing another method for processing sales of a loan between a borrower terminal and lender terminals.

Detailed Description of Preferred Embodiments The method and apparatus of one embodiment of the present invention will now be discussed with reference to Figures 1,2,3, and 4. In a preferred embodiment, the present invention includes central controller 200, seller interface 300, buyer interface 400, and associated databases. The present invention receives conditional purchase offers from buyers, makes them available for viewing by potential sellers, and allows sellers to bind them. Thus, a buyer is able to communicate his commitment to follow through on an offer to a seller, giving the seller confidence that if he can produce the goods, the buyer has the ready capacity to pay.

SYSTEM ARCHITECTURE The system architecture of a first embodiment of the apparatus and method of the present invention is illustrated with reference to Figures 1 through 4. As shown in Figure 1, the apparatus of the present invention comprises seller interface 300, central controller 200, and buyer interface 400 (collectively the"nodes"). Each node is connected via an Internet connection using a public switched phone network, such as those provided by a local or regional telephone operating company. Connection may also be provided by dedicated data lines, cellular, Personal Communication Systems ("PCS"), microwave, or satellite networks. Seller interface 300 and buyer interface 400 are the input and output gateways for communications with central controller 200.

Using the above components, the present invention provides a method and apparatus to post conditional purchase offers, make them available to potential sellers, and allow sellers to bind the offers to form a legally binding contract.

As shown in Figure 2, central controller 200 includes central processor (CPU) 205, cryptographic processor 210, RAM 215, ROM 220, payment processor 230, clock 235, operating system 240, network interface 245, and data storage device 250.

A conventional personal computer or computer workstation with sufficient memory and processing capability may be used as central controller 200. In one embodiment it operates as a web server, both receiving and transmitting CPOs 100 generated by buyers. Central controller 200 must be capable of high volume transaction processing, performing a significant number of mathematical calculations in processing communications and database searches. A Pentium microprocessor such as the 100 MHz P54C, commonly manufactured by Intel Inc., may be used for CPU 205. This processor employs a 32-bit architecture. Equivalent processors include the Motorola 120 MHz PowerPC 604 or Sun Microsystem's 166 MHz UltraSPARC-1.

An MC68HC16 microcontroller, commonly manufactured by Motorola Inc., may be used for cryptographic processor 210. Equivalent processors may also be used. This microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 16 MHz configuration and requires less than one second to perform a 512-bit RSA private key operation. Cryptographic processor 210 supports the authentication of communications from both buyers and sellers, as well as allowing for anonymous transactions. Cryptographic processor 210 may also be configured as part of CPU 205.

Other commercially available specialized cryptographic processors include VLSI Technology's 33MHz 6868 or Semaphore Communications'40 MHz Roadrunner284.

Referring again to Figure 2, payment processor 230 comprises conventional microprocessors (such as the Intel Pentium), supporting the transfer and exchange of payments, charges, or debits, attendant to the method of the apparatus.

Payment processor 230 may also be configured as part of CPU 205. Processing of credit card transactions by payment processor 230 may be supported with commercially available software, such as the Secure Webserver manufactured by Open Market, Inc.

This server software transmits credit card numbers electronically over the Internet to servers located at the Open Market headquarters where card verification and processing is handled. Their Integrated Commerce Service provides back-office services necessary to run Web-based businesses. Services include on-line account statements, order-taking and credit card payment authorization, credit card settlement, automated sales tax

calculations, digital receipt generation, account-based purchase tracking, and payment aggregation for low-priced services.

Data storage device 250 may include hard disk magnetic or optical storage units, as well as CD-ROM drives or flash memory. Data storage device 250 contains databases used in the processing of transactions in the present invention, including buyer database 255, seller database 260, CPO database 265, counteroffer database 267, seller response database 270, purchase confirmation database 275, contract detail database 280, payment database 285, cryptographic key database 290, and audit database 295. In a preferred embodiment database software such as Oracle7, manufactured by Oracle Corporation, is used to create and manage these databases.

Data storage device 250 also stores information pertaining to buyer account 297, seller account 298, and escrow account 299.

Buyer database 255 maintains data on buyers with fields such as name, address, credit card number, phone number, ID number, social security number, electronic mail address, credit history, past system usage, public/private key information, etc. This information is obtained when the buyer first registers with the system, or immediately prior to posting his first CPO 100. Buyer database 255 also contains the tracking number of each CPO 100 generated by the buyer, and the tracking number of each seller response 110 and counteroffer 140 directed to the buyer's CPOs 100.

Seller database 260 maintains data on sellers with fields such as name, contact information, public/private key information, payment preferences, type of business, and goods sold. Contact information comprises a phone number, web page URL, bulletin board address, pager number, telephone number, electronic mail address, voice mail address, facsimile number, or any other way to contact the seller. Upon registration, the seller may be required to demonstrate evidence of ability to deliver on bound CPOs 100. An airline, for example, might submit a listing of the city pairs they service so that central controller 200 can quickly determine whether the airline is capable of satisfying a given CPO 100.

CPO database 265 tracks all CPOs 100 with fields such as status, tracking number, date, time, subject, price, expiration date, conditions, and buyer identification number. This database is valuable in the event of disputes between buyers

and sellers regarding payment, because details of the contract can be produced. CPO database 265 may also store bond certificate 172.

Counteroffer database 267 tracks all counteroffers 140. The structure of this database is identical to CPO database 265, except for the addition of a field for CPO tracking number that allows counteroffer 140 to be correlated with a particular CPO 100.

Seller response database 270 tracks all seller responses 110 with fields such as seller name, seller ID number, date, time, seller response tracking number, and associated CPO tracking number.

Purchase confirmation database 275 tracks the messages sent to the buyer and seller confirming completed transactions (bound contracts). Fields include buyer name, buyer ID number, seller name, seller ID number, purchase confirmation tracking number, and associated CPO tracking number.

Contract detail database 280 contains form background provisions for inclusion in CPOs 100. These form provisions effectively fill the gaps between conditions specified by the buyer, specifying the generic contract details common to most CPOs 100.

Payment database 285 tracks all payments made by the buyers with fields such as buyer name, buyer ID number, amount of payment, and associated CPO tracking number. This database may also store credit card numbers of buyers.

Cryptographic key database 290 facilitates cryptographic functions, storing both symmetric and asymmetric keys. These keys are used by cryptographic processor 210 for encrypting and decrypting CPOs 100, seller responses 110, purchase confirmations 120, counteroffers 140, and buyer responses 150.

Audit database 295 stores transactional information relating to the posting of CPOs 100, allowing it to be retrieved for later analysis.

Buyer account 297 tracks all information pertaining to the buyer's account with fields such as buyer's name, bank and credit account numbers, and debit or credit transactions. This account may be a pointer to account data stored at the buyer's bank.

Seller account 298 tracks all information pertaining to the seller's account with fields such as seller's name, bank and credit account numbers, and debit or credit transactions. Buyer payments for CPOs 100 may be sent to this account.

Escrow account 299 is an account that temporarily holds buyer funds before they are placed in seller account 298.

Network interface 245 is the gateway to communicate with buyers and sellers through respective buyer interface 400 and seller interface 300. Conventional internal or external modems may serve as network interface 245. Network interface 245 supports modems at a range of baud rates from 1200 upward, but may combine such inputs into a Tl or T3 line if more bandwidth is required. In a preferred embodiment, network interface 245 is connected with the Internet and/or any of the commercial on- line services such as America Online, CompuServe, or Prodigy, allowing buyers and sellers access from a wide range of on-line connections. Several commercial electronic mail servers include the above functionality. NCD Software manufactures "Post. Office," a secure server-based electronic mail software package designed to link people and information over enterprise networks and the Internet. The product is platform independent and utilizes open standards based on Internet protocols. Users can exchange messages with enclosures such as files, graphics, video and audio. The system also supports multiple languages. Alternatively, network interface 245 may be configured as a voice mail interface, web site, BBS, or electronic mail address.

While the above embodiment describes a single computer acting as central controller 200, those skilled in the art will realize that the functionality can be distributed over a plurality of computers. In one embodiment, central controller 200 is configured in a distributed architecture, wherein the databases and processors are housed in separate units or locations. Some controllers perform the primary processing functions and contain at a minimum RAM, ROM, and a general processor. Each of these controllers is attached to a WAN hub that serves as the primary communication link with the other controllers and interface devices. The WAN hub may have minimal processing capability itself, serving primarily as a communications router. Those skilled in the art will appreciate that an almost unlimited number of controllers may be supported. This arrangement yields a more dynamic and flexible system, less prone to catastrophic hardware failures affecting the entire system. The trusted server

embodiment provides more details of such a distributed environment, describing operations server 160, trusted server 165, and bonding agency 170. The hardware of these servers would be configured similarly to that described for central controller 200.

Figures 3 and 4 describe seller interface 300 and buyer interface 400, respectively. In an exemplary embodiment they are both conventional personal computers having an input device, such as a keyboard, mouse, or conventional voice recognition software package; a display device, such as a video monitor; a processing device such as a CPU; and a network interface such as a modem. These devices interface with central controller 200. Alternatively, seller interface 300 and buyer interface 400 may also be voice mail systems, or other electronic or voice communications systems. As will be described further in the following embodiments, devices such as fax machines or pagers are also suitable interface devices.

Referring now to Figure 3, there is described seller interface 300 which includes central processor (CPU) 305, RAM 315, ROM 320, clock 335, video driver 325, video monitor 330, communication port 340, input device 345, modem 350, and data storage device 360. Cryptographic processor 335 and biometric device 355 may be added for stronger authentication as described later. A Pentium microprocessor such as the 100 MHz P54C described above may be used for CPU 305. Clock 335 is a standard chip-based clock which can serve to timestamp seller response 110 or counteroffer 140 produced with seller interface 300.

Modem 350 may not require high-speed data transfer if most seller responses 110 and counteroffers 140 produced are text-based and not too long. If a cryptographic processor is required, the MC68HC16 microcontroller described above is used. The structure of biometric device 355 will be described below in conjunction with the cryptographic authentication embodiment.

Data storage device 360 is a conventional magnetic-based hard disk storage unit such as those manufactured by Conner Peripherals. Message database 370 may be used for archiving seller responses 110 and counteroffers 140, while audit database 380 may be used for recording payment records and communications with central controller 200.

Referring now to Figure 4, there is described buyer interface 400 which includes central processor (CPU) 405, RAM 415, ROM 420, clock 435, video driver

425, video monitor 430, cryptographic processor 435, communication port 440, input device 445, modem 450, and data storage device 460. All of these components may be identical to those described in Figure 3.

There are many commercial software applications that can enable the communications required by seller interface 300 or buyer interface 400, the primary functionality being message creation and transmission. Eudora Pro manufactured by Qualcomm Incorporated, for example, provides editing tools for the creation of messages as well as the communications tools to route the message to the appropriate electronic address. When central controller 200 is configured as a web server, conventional communications software such as the Netscape navigator web browser from Netscape Corporation may also be used. The buyer and seller may use the Netscape Navigator browser to transmit CPO 100, seller response 110 or counteroffers 140. No proprietary software is required.

ONLINE EMBODIMENT In one embodiment of the present invention, communications between buyers and sellers take place via electronic networks, with central controller 200 acting as a web server. The buyer logs on to central controller 200, creates CPO 100, and then disconnects from the network. CPO 100 is made available to potential buyers by posting CPO 100 on the web page of central controller 200. Periodic maintenance is performed by central controller 200 to ensure that active CPOs 100 have not expired, and that the buyer has sufficient credit available to pay a seller who elects to bind CPO 100. Seller responses 110 are transmitted electronically to central controller 200 which contacts the buyer to indicate that CPO 100 has been bound. Central controller 200 transfers credit card information to the seller as soon as CPO 100 is bound.

With reference to Figure 5, there is described the process by which the buyer formulates CPO 100. At step 500, the buyer logs on to central controller 200 using buyer modem 450 of buyer interface 400, establishing a communication link. It should be noted that the buyer may be an individual, a corporation, a partnership, a government, or any other entity. In one embodiment, central controller 200 has a page on the World Wide Web, allowing the buyer to provide information through the interface of conventional web browser software such as Netscape Navigator, manufactured by Netscape, Inc. At step 510, the buyer selects the subject of the goods

he wants to purchase by selecting from a list of possible subjects. As shown in box 515, subjects might include airline tickets, hotel rooms, rental cars, insurance, mortgages, clothing, etc. After the subject is selected, a form is displayed on video monitor 430 of buyer interface 400. This form is an electronic contract with a number of blanks to be filled out by the buyer, with each blank representing a condition of CPO 100.

At step 520, the buyer enters a description of the goods. A business traveler, for example, might want to fly from San Francisco to New York. The description of the goods might be two first class round-trip tickets between those city pairs, leaving May 7 and returning May 12. There would be a place on the form for originating city, destination city, date of departure, date of return, number of tickets, class of service, etc. The buyer simply fills in the blanks. The buyer then adds other conditions at step 530. The buyer, for example, may only want a nonstop ticket on a flight arriving at the destination city before midnight. These conditions would be similarly entered into CPO 100. As indicated in box 535, conditions could include the provision that a flight must arrive before midnight, a hotel room must be non-smoking, or a rental car must not be a compact. Conditions are the terms of CPO 100, allowing the buyer to tailor CPO 100 for his specific needs. Conditions may also be based on other conditions. For example, one condition might state that four out of five other specified conditions must be met. Alternatively, each condition of CPO 100 could be given a point value, with CPO 100 requiring only that conditions be satisfied up to a certain total point value. For example, the buyer may indicate that a window seat is worth two points, an aisle seat one point, and a nonstop flight four points, etc. CPO 100 could require that ten"points"must be met in order to satisfy the conditions of CPO 100. Conditions could also indicate that for twenty-four hours following the first attempted binding of CPO 100, other sellers may make offers to bind, with the original binding seller completing the contract only if no better offer has been received.

Conditions could even be based on external events. For example, the buyer could create CPO 100 which offered to buy airline tickets only in the event that it was snowing in November in the destination city.

At step 540, the buyer adds an expiration date to CPO 100, if desired.

This allows a buyer to post CPO 100 without worrying that he will later be bound after his needs have changed. At step 550, the buyer enters a price. In a CPO 100 for a

rental car, for example, the buyer may enter a price of fifty dollars for a three-day rental.

At step 560, the buyer attaches his name or a unique user ID number to CPO 100. This ID number is received from central controller 200 when the buyer registers for the service, or is chosen by the buyer and then registered with central controller 200 by phone. Central controller 200 maintains a database of buyer ID numbers in buyer database 255, and issues (or allows) only unique numbers. If less security is required, the user's telephone number could serve as the ID number since it has the advantages of being both unique and easily remembered. If additional security is required, those procedures described in the cryptographic embodiment may be implemented.

Once the above elements have been developed, the buyer transmits them to central controller 200 at step 570. The buyer does this by clicking on a"send"button located on the screen in which he entered the terms of CPO 100. At step 580, boilerplate legal language is added to the components of CPO 100 to form a complete CPO 100. The legal language is pulled from contract detail database 280 that stores a plurality of paragraphs. These paragraphs are linked together with the above contract elements to form a complete CPO 100. The only element missing which prevents CPO 100 from being recognized as a legitimate contract is the name and signature of the seller.

Instead of a World Wide Web-based interface, buyers may also transmit CPO 100 data via electronic mail, voice mail, facsimile, or postal mail transmissions.

With voice mail, the buyer calls central controller 200 and leaves CPO 100 in audio form. These CPOs 100 may be transcribed into digital text at central controller 200, or made available to potential sellers in the same audio format. In a postal mail embodiment, central controller 200 acts more like a router, directing CPOs 100 to the potential sellers, creating multiple copies of CPO 100 if necessary. CPO 100 may also be posted to bulletin boards or web pages operated by central controller 200. Central controller 200 supports a plurality of transmission methods, allowing for a wide variety of formats of CPOs 100. Some formats may be changed, however, before further processing by central controller 200. CPOs 100 transmitted by mail in paper form, for example, may be scanned-in and digitized, using optical character recognition software to create digital text. These embodiments are more fully described in the off-line embodiment described later.

Referring now to Figure 6, CPO 100 is received and checked to see that sufficient credit is available to cover the stated price of CPO 100, before CPO 100 is made available to potential sellers. At step 600, central controller 200 extracts price and expiration date information from CPO 100. At step 610, payment processor 230 submits a pre-authorization of the price of CPO 100 to the credit card clearinghouse.

This serves to"lock up"a portion of the available credit on the buyer's credit card, preventing him from using up this credit while CPO 100 is still active. At step 620, the credit card clearinghouse responds to the pre-authorization, indicating whether sufficient credit is available. If sufficient funds are not available to cover the price of CPO 100, another credit card number is requested from the buyer at step 630. Once an additional credit card number has been transmitted, central controller 200 then resubmits the pre-authorization at step 610. At step 640, the expiration date of CPO 100 is checked to see if it has already expired. If it has expired, CPO 100 is rejected at step 650 and returned to the buyer. If CPO 100 has not yet expired, it is accepted at step 660.

Referring now to Figure 7, there is illustrated an embodiment in which CPO 100 is activated and made available to potential sellers. At step 700, a unique tracking number is added to CPO 100. Central controller timestamps CPO 100 at step 710, and then stores CPO 100 in CPO database 265. CPO database 265 contains a record for each CPO 100, and includes fields such as status, subject, tracking number, timestamp, description of goods, price, expiration date, conditions, and buyer ID number. The status field has values of"pending,""active,""expired,"and"completed." A status of"pending"means that the CPO is not currently available to potential sellers.

Either it is still being processed by central controller 200, or it has been temporarily suspended by the buyer. An"active"CPO 100 is available to potential sellers and can be bound. An"expired"CPO 100 can no longer be bound. CPOs 100 that have been bound by a seller have a status of"completed." After being stored at step 720, CPO 100 may go through a series of processing steps. One step, if necessary, is language translation, either creating a standard language that all CPO 100s must be written in, or translating to the language most appropriate for the sellers to which it will be sent. This translation is provided by language experts at central controller 200, or by automatic translation software such as

Systran Professional, manufactured by Systran Software. Twelve bi-directional language combinations are available, including English to/from French, Italian, German, Spanish, Portuguese, and Japanese. Another step, if necessary, is to edit for spelling or grammatical errors. CPO 100 might also be reviewed for clarity. Any CPO 100 with an unclear term or condition would be returned to the buyer for clarification.

A buyer listing a destination city of"Chicago"might have CPO 100 returned for clarification or correction.

Referring again to Figure 7, the status of the database record for CPO 100 is set to"active"at step 730. At step 740, the subject of CPO 100 is extracted from the subject field. At step 750, CPO 100 is posted in an appropriate subject area. This allows central controller 200 to display CPO 100 only to the most appropriate sellers.

In a World Wide Web environment, central controller 200 has a web page for each possible subject area. Thus all CPOs 100 requesting airline tickets would be displayed on the airline ticket web page. This makes it much easier for potential sellers to find appropriate CPOs 100 they might want to bind as they can go right to the subject whose goods they can provide. In an alternative embodiment, CPO 100 is electronically mailed to potential sellers, either individually or in groups. Potential sellers could elect to receive all CPOs 100, only those CPOs 100 in their subject area, or a subset of CPOs 100 representing a particular condition. For example, a car rental company might request that all car rental CPOs 100 for luxury cars be sent to them.

In an embodiment in which CPOs 100 are being transmitted to the seller, it is important to note that there are a number of hardware options for seller interface 300. Suitable seller interfaces 300 include fax machines, personal digital assistants (PDAs) with wireless connections, and beepers or pagers. For example, a rare coin dealer could instruct central controller 200 to beep him whenever CPO 100 appeared for Morgan Silver Dollars, providing details of CPO 100 over the beeper network, or informing the seller to log on to central controller 200 for further details.

Referring now to Figure 8, there is illustrated a procedure for the maintenance of CPOs 100. At step 800, central controller 200 searches CPO database 265. At step 810, the expiration date field of each database record of CPO 100 is compared to the current date. If the expiration date of CPO 100 is earlier than the current date, the status of CPO 100 is changed to"expired"at step 820. At step 830,

payment processor 230 contacts credit card clearinghouse to verify that the buyer's credit card is still valid. If the card is not valid, the status of CPO 100 is changed to "expired"at step 840. The maintenance process is completed at step 850 once all "active"CPO database records have been examined.

Figure 9 illustrates the process by which a potential seller selects CPO 100. At step 900, the potential seller logs on to central controller 200 using modem 350 of seller interface 300. At step 910, the potential seller selects an appropriate subject area. For example, a large Chicago hotel that had just experienced the cancellation of a block of rooms for a convention might search in the hotel subject area in the hopes of finding a CPO 100 requesting a room in Chicago on those dates. At step 920, the potential seller browses the list of available CPOs 100 (i. e. those with a status of "active"). CPOs 100 may be listed with minimal details, with additional information available only if the potential seller is interested in binding CPO 100. A hotel CPO 100 might be listed as"hotel-09/16/96-Chicago-single occupancy-$85."A potential seller wanting more information about CPO 100 may request additional data at step 940. In one embodiment, each CPO 100 is hyperlinked to a separate web page that provides complete details. The potential seller clicks on CPO 100 and is immediately transferred to the page of supporting detail. This detail might include the required type of bed, fitness facilities, and restaurants. In another embodiment, CPO 100 is electronically transmitted directly to the seller, via electronic mail, fax, telephone, beeper, etc.

Figures 10 and 11 illustrate the process by which CPO 100 is bound by a seller. At step 1000, the potential seller selects CPO 100 that he would like to bind, developing seller response 110 that represents his intention to bind. At step 1010, central controller 200 receives seller response 110 from the potential seller. Central controller 200 then timestamps seller response 110 and authenticates the identity of the seller, as well as verifying his probable capacity to deliver the goods. The timestamp allows central controller 200 to determine the first unconditional acceptance to be received. If two seller responses 110 are received within a few seconds of each other, the timestamp allows central controller 200 to decide which was received first.

Alternatively, the timestamp may be appended to seller response 110 at the time it is transmitted from seller interface 300, using clock 335 of seller interface 300.

Authentication of the seller's identity involves central controller 200 extracting the seller ID from seller response 110 and looking up the seller's identity in seller database 260. Information in seller database 260 then provides an indication of the seller's ability to deliver the goods. Before a seller can bind CPO 100 for an airline ticket, for example, central controller 200 must authenticate that the seller is an airline.

If necessary, central controller 200 may verify that the seller can provide the specific good requested. Rather than just verifying that the seller is an airline, central controller 200 may verify that it serves the city pairs requested by the buyer. In another embodiment, the seller incorporates seller response 110 into CPO 100, signing CPO 100 by adding an indication that the contract is agreed to. This indication could be a digital signature, or could involve adding a symbol or indicia representative of the seller.

Central controller 200 then verifies the status of CPO 100 at step 1030, determining whether or not the status of CPO 100 is"active"at step 1040. If CPO 100 is currently"active,"a unique tracking number is added to seller response 110 at step 1060. Central controller 200 then stores seller response 110 in seller response database 270 at step 1070. If the status of CPO 100 is not"active"at step 1040, seller response 110 is refused by central controller 200 and transmitted back to the potential seller at step 1050.

In another embodiment, the seller transmits seller response 110 directly to the buyer at step 1010. The buyer may then send seller response 110 to central controller 200 for verification and authentication, or he may choose to accept seller response 110 without verification and authentication.

In Figure 11, the payment process is begun at step 1100 when the credit card number and approval code for the selected CPO 100 is transmitted to the seller. At step 1110 CPO 100 is bound, turning CPO 100 into a legally binding contract between the buyer and seller. The binding process requires that the status of CPO 100 be changed to"completed,"preventing subsequent sellers from being able to bind CPO 100. The binding process also requires that the seller ID be added to CPO 100. At step 1120, central controller 200 sends purchase confirmation 120 to the seller and then sends it to the buyer at step 1130.

In another embodiment, multiple sellers may bind CPO 100. In this case, CPO 100 may maintain its status of"active"until a given number of sellers have

responded, and only then is the status of CPO 100 changed to"completed."For example, a rare coin dealer may post CPO 100 offering a hundred dollars for a specific type of coin. A condition of CPO 100 may state that the offer is open to the first ten sellers to respond, allowing for ten bindable contracts. Another option is to open CPO 100 to any number of bindings, or any number of bindings up to the funds available by the buyer.

There are many methods by which the providers of the system could derive a revenue stream. In one embodiment, a flat fee is charged for every CPO 100 submitted. There could also be flat fees that would cover any number of CPOs 100 over a given period of time, allowing buyers to subscribe to the service much as they would subscribe to a newspaper. In another embodiment, central controller 200 calculates a discounted value of the price in which sellers receive only a percentage of the price of CPO 100. In another embodiment, advertisers pay to have messages listed along with CPOs 100, supplementing the costs of operating the system. Alternatively, the method and apparatus of the present invention may be employed without a payment feature.

Figure 12 illustrates the exchange of goods between buyer and seller. At step 1200, the seller transfers the specified goods to the buyer. This transfer could involve the delivery of physical goods as well as digital goods. Physical goods might include cars, jewelry, computer equipment, etc. Digital goods might include documents, tickets, access codes, etc. A hotel, for example, might transfer a confirmation number to the buyer, to be presented upon check-in at the hotel. At step 1210, the buyer examines the delivered goods to see if they meet all conditions and terms of CPO 100. A buyer purchasing a hotel room, for example, would verify that the room was for the correct date and was in the correct city. At step 1220, if the goods do not meet the buyer's conditions as described in CPO 100 the buyer contacts an arbiter at central controller 200 for dispute resolution. This process is described in more detail in the dispute resolution embodiment described later. At step 1240 the transaction is complete.

PAYMENT PREFERENCES Figure 13 illustrates a protocol in which central controller 200 establishes buyer account 297. At step 1300, the buyer selects his preferred method of payment.

Preferred methods might include credit cards, personal checks, electronic funds transfer,

digital money, etc. At step 1310, the buyer transmits payment data corresponding to his preferred method of payment to central controller 200. As indicated by box 1315, such payment data might include credit card number or bank account number. These payment methods are meant to be merely illustrative, however, as there are many equivalent payment methods commonly known in the art that may also be used. If the buyer wants to pay by credit card, for example, payment data would include his credit card account number, expiration date, name of issuing institution, and credit limit. For electronic funds transfer, payment data includes the name of the buyer's bank and his account number. At step 1320, central controller 200 stores payment data and payment preferences in payment database 285.

At step 1330, central controller 200 establishes buyer account 297 that either stores money transferred by the buyer or serves as a pointer to an account of the buyer outside the system. For buyers using credit cards, for example, buyer account 297 contains the credit card number, expiration date, and name of issuing institution.

Buyers could also transfer money to central controller 200 to be stored in buyer account 297, which would operate like a conventional checking account. Central controller 200 would send a check to the seller written on buyer account 297. Alternatively, central controller 200 could electronically move the funds directly from buyer account 297 to seller account 298. At step 1340, central controller 200 contacts the bank or card issuer to confirm that funds are available. A buyer is thus unable to use a credit card with no credit available to establish buyer account 297.

The above protocols may be similarly applied to sellers, allowing for the creation of seller account 298. The primary difference being that seller account 298 is primarily used for deposits, with money flowing from seller to buyer in the case of deposit returns or refunds when the buyer does not find the received goods acceptable.

Verification of funds available is therefore not as important for sellers.

Although the on-line embodiment describes a protocol in which central controller 200 transmits credit card information to the seller for processing, there are of course many payment protocols under which payment may be transferred from buyer to seller. In one embodiment, processing the credit card is performed by central controller 200, not the seller. Central controller 200 looks up the credit card number of the buyer in payment database 285. This credit card number is transmitted to payment processor

230. Payment processor 230 contacts the credit card clearinghouse to get an authorization number. The billable amount appears on the credit card statement of the buyer in his monthly statement. The clearinghouse posts this amount to seller account 298. Central controller 200 updates payment database 285 to indicate that payment has been made. Central controller 200 could also arrange for payment to be made directly between buyer and seller by providing payment information to each party. The buyer, for example, might receive the checking account number of the seller. Account information could also be embedded into CPO 100 and seller response 110, allowing buyer and seller to complete payment once they each had a copy of CPO 100.

Another method of payment involves procedures using digital cash.

Central controller 200 looks up the buyer's electronic delivery address in payment database 285. This address is transmitted to payment processor 230, with the digital cash being downloaded from the buyer. Central controller 200 updates payment database 285 to indicate that payment has been made. This address might be an electronic mail address if the digital cash is to be transferred by electronic mail, or it could be an Internet Protocol address capable of accepting an on-line transfer of digital cash. This electronic delivery address is sent to payment processor 230. The digital cash is downloaded to seller account 298 or directly to the seller. Central controller 200 then updates payment database 285 to indicate that payment has been made. Using these digital cash protocols, it is possible for the buyer to include payment along with CPO 100 in electronic form.

The practice of using digital cash protocols to effect payment is well known in the art and need not be described here in detail. For reference, one of ordinary skill in the art may refer to Daniel C. Lynch and Leslie Lundquist, Digital Money, John Wiley & Sons, 1996; or Seth Godin, Presenting Digital Cash, Sams Net Publishing, 1995.

DELAYED PAYMENT EMBODIMENT Although the on-line embodiment describes a protocol in which sellers receive payment immediately upon binding CPO 100, other embodiments may be implemented in which payment is delayed until the goods have been received by the buyer, or delayed until some predetermined date. Partial payments and installment payments are also supported by the system

Escrow account 299 allows payment to be delayed until the seller completes delivery of the goods, while at the same time ensuring that the buyer will in fact make payment. Central controller 200 establishes escrow account 299 as a temporary holding account. When the seller binds CPO 100 at step 1110, funds are transferred from buyer account 297 to escrow account 299. Only after the goods have been received by the buyer are funds transferred from escrow account 299 to seller account 298. The buyer may transmit a digitally signed release message to central controller 200, authorizing the release of the escrowed funds to the seller.

In another embodiment, the buyer makes a partial payment when CPO 100 is bound, and then completes payment when the goods are received. The fraction of the offered price of CPO 100 to be paid upon binding is a condition of CPO 100 and is stored in payment database 285 when CPO 100 is bound. Central controller releases this portion of the funds at step 1110, and then releases the remaining portion after goods have been delivered at step 1200. The partial payment made upon binding may be non-refundable. This would allow a hotel, for example, to sell hotel room reservations that are cancelable on two days notice, with cancellations within the two- day period resulting in forfeiture of deposit.

In yet another embodiment, CPO 100 describes the use of installment payments. The first payment is made when CPO 100 is bound, followed by regular payments as specified in the conditions of CPO 100. The dates at which payments are to be made are stored in payment database 285.

COUNTEROFFER EMBODIMENT In one embodiment of the present invention, sellers respond to CPO 100 not by binding it, but by making a counteroffer with modified and/or additional conditions. An airline, for example, might view CPO 100 for a first class ticket for five hundred dollars. The airline may be willing to sell for six hundred dollars, and thus want to develop and issue a counteroffer rather than electing to bind CPO 100. This counteroffer is similar to CPO 100 except that the buyer is binding the seller instead of the seller binding the buyer. The counteroffer is also directed to a specific party (the buyer), unlike CPO 100 that may be directed to a plurality of sellers.

Figure 18 illustrates the development of counteroffer 140. At step 1800, the potential seller selects CPO 100 for which he wants to make a counteroffer. At step

1810, the seller prepares counteroffer 140 with modified conditions. The seller follows the same process that the buyer uses to generate CPO 100 (steps 500 through 580), selecting the conditions of counteroffer 140. Alternatively, the seller is presented with an electronic copy of CPO 100 and is allowed to edit those conditions that the seller wants to change. For example, a car rental company might take the buyer's request for a ten dollar per day luxury car and counteroffer with a twenty-dollar per day compact car.

At step 1820, the seller attaches the tracking number of CPO 100 to counteroffer 140.

Central controller 200 receives counteroffer 140 at step 1830, setting the status to "active."Central controller 200 then adds a unique tracking number to counteroffer 140 at step 1840, and stores it in counteroffer database 267 at step 1850. Central controller 200 extracts the tracking number of CPO 100 attached to counteroffer 140 in order to find the buyer to whom counteroffer 140 is transmitted at step 1860.

Figure 19 illustrates the process by which the buyer responds to counteroffer 140. At step 1900, the buyer decides whether or not to bind counteroffer 140. If he does not bind, counteroffer 140 is transmitted back to the potential seller at step 1910. If the buyer does decide to bind, buyer response 150 is transmitted to central controller 200 at step 1920. At step 1930, funds are removed from buyer account 297 and placed in seller account 298. At step 1940, the status of counteroffer 140 is changed to"completed."Purchase confirmation 120 is transmitted to the seller at step 1950 and transmitted to the buyer at step 1960. Procedures for the exchange of goods are completed as described in Figure 12.

OFF-LINE EMBODIMENT In one embodiment of the present invention, buyers and sellers communicate in an off-line manner with central controller 200. Rather than sending electronic mail or using web-based servers, buyers and sellers use a telephone, fax machine, postal mail, or other off-line communication tool.

A buyer may use a telephone, for example, to generate CPO 100. The buyer calls central controller 200 and is connected with an agent. The buyer provides the terms of CPO 100 such as subject, description of goods, conditions, expiration date, price, etc. The buyer also provides his buyer ID, password, or private key so that central controller 200 can authenticate his identity. The agent puts this data into digital form by typing it into a terminal and then adds legal language to form CPO 100. CPO

100 is then transmitted to central controller 200 where it is made available to potential sellers as described in the on-line embodiment.

In an alternative embodiment, the buyer calls central controller 200 and is connected with a conventional Interactive Voice Response Unit (IVRU) which allows the buyer to enter some or all of the terms of CPO 100 without the assistance of a live agent. The buyer initially selects from a menu of subjects using the touch-tone keys of his phone, and then the call is either directed to a live agent specializing in that subject area, or the buyer is prompted for further terms of CPO 100.

Potential sellers may also use a telephone to browse and bind CPOs 100.

The potential seller calls central controller 200 and selects a subject. Central controller 200 then converts the text of each CPO 100 into audio form, reading the entire list to the potential seller. At any time during the reading of CPOs 100, the potential seller may press a combination of keys on his telephone to select CPO 100 for binding. The seller enters seller ID number and is authenticated by central controller 200 prior to the binding of CPO 100. Potential sellers could also enter parameters before having the list of CPOs 100 read to them. An airline, for example, might request that all airline CPOs 100 for more than eight hundred dollars be read, skipping any CPO 100 with a lower price.

Buyers may also communicate with an agent at central controller 200 through faxes or postal mail. The agent receives the message and proceeds to digitize it and form CPO 100 as described above.

CRYPTOGRAPHIC AUTHENTICATION EMBODIMENT In the previous embodiments, authentication of the buyer and seller involves checking the attached ID or name and comparing it with those stored in seller database 260 and buyer database 255. Although this procedure works well in a low security environment, it can be significantly improved through the use of cryptographic protocols. These protocols not only enhance the ability to authenticate the sender of a message, but also serve to verify the integrity of the message itself, proving that it has not been altered during transmission. A small airline, for example, could be prevented from binding CPOs 100 requiring performance by a large carrier as their identity would not be authenticated. Encryption can also prevent eavesdroppers from learning the contents of the message. A competing airline, for example, could be prevented from

reading any intercepted seller response 110 generated by another competitor. Such techniques shall be referred to generally as cryptographic assurance methods, and will include the use of both symmetric and asymmetric keys as well as digital signatures and hash algorithms.

The practice of using cryptographic protocols to ensure the authenticity of senders as well as the integrity of messages is well known in the art and need not be described here in detail. For reference, one of ordinary skill in the art may refer to Bruce Schneier, Applied Cryptography, Protocols, Algorithms, And Source Code In C, (2d Ed, John Wiley & Sons, Inc., 1996).

Figure 14 describes a symmetric key embodiment in which the seller and central controller 200 share a key. Thus both encryption and decryption of seller response 110 are performed with the same key. This encryption may be implemented with an algorithm such as DES (U. S. Government standard, specified in FIPS PUB 46), or with any of several algorithms known in the art such as IDEA, Blowfish, RC4, RC2, SAFER, etc. The seller encrypts seller response 110 with his assigned symmetric key at step 1400, using cryptographic processor 310 of seller interface 300. The key may be stored in message database 370 or otherwise stored or memorized by the seller. The encrypted seller response 110 is then transmitted to cryptographic processor 210 of central controller 200 at step 1410. Cryptographic processor 210 extracts the seller ID from seller response 110 at step 1420 and looks up the symmetric key of the seller in cryptographic key database 290 at step 1430, decrypting seller response 110 with this key at step 1440. Cryptographic key database 290 contains algorithms and keys for encrypting, decrypting and/or authenticating messages. At step 1450, if the resulting message is intelligible, then it must have been encrypted by the same key, authenticating that the seller must have indeed been the author of seller response 110.

This procedure makes it significantly more difficult for an unauthorized seller to represent himself as a legitimate seller. Without cryptographic procedures, an unauthorized seller who obtained a sample seller response 110 from a legitimate seller would be able to extract the seller ID and then attach this ID number to unauthorized seller responses 110. When seller response 110 has been encrypted with a symmetric key, however, an unauthorized seller obtaining a sample seller response 110 only discovers the seller's ID number, not the symmetric key. Without this key, the

unauthorized seller cannot create a seller response 110 that will not be discovered by central controller 200, since he cannot encrypt his message in the same way that the authorized seller could. The symmetric key protocol also ensures that seller response 110 has not been tampered with during transmission, since alteration of the message requires knowledge of the symmetric key. An encrypted seller response 110 also provides the seller with more anonymity.

Referring now to Figure 15, there is shown an asymmetric key protocol in which seller response 110 is encrypted with a private key and decrypted with a public key. Two such algorithms for this procedure are RSA and DSA. At step 1500, the seller encrypts seller response 110 with his private key using cryptographic processor 310, transmitting seller response 110 to central controller 200 at step 1510.

Cryptographic processor 210 extracts the seller ID at step 1520 and looks up the seller's associated public key in cryptographic key database 290 at step 1530, decrypting seller response 110 with this public key at step 1540. As before, if seller response 110 is intelligible then central controller 200 has authenticated the seller at step 1550. Again, unauthorized sellers obtaining seller response 110 before it was received by central controller 200 are not able to undetectably alter it since they do not know the private key of the seller. Unauthorized sellers would, however, be able to read the message if they managed to obtain the public key of the seller. Message secrecy is obtained if the seller encrypts seller response 110 with his public key, requiring the attacker to know the seller's private key to view seller response 110.

Figure 16 shows a cryptographic technique using digital signatures to provide authentication and message integrity. One such algorithm is DSA (Digital Signature Algorithm), the U. S. Government standard specified in FIPS PUB 186. As in the asymmetric protocol described above, each seller has an associated public and private key. The seller signs seller response 110 with his private key at step 1600 with cryptographic processor 310 and transmits it to central controller 200 at step 1610.

Central controller cryptographic processor 210 extracts the seller ID at step 1620 and looks up the seller's public key at step 1630, verifying the signature using seller response 110 and the public key of the seller at step 1640. If seller response 110 is intelligible, then central controller 200 accepts seller response 110 as authentic at step 1650.

Referring now to Figure 17, there is described a cryptographic technique using message authentication codes for verifying the authenticity and integrity of seller response 110. In the hash protocol of the present invention, the seller and central controller 200 share a symmetric key, which the seller includes in a hash of seller response 110 at step 1700. In the hash protocol, a one-way function is applied to the digital representation of seller response 110, generating a code that acts much like the fingerprint of seller response 110. Any of the MAC algorithms, such as RIPE-MAC, IBC-Hash, CBC-MAC, and the like may be applied in this application. After transmitting seller response 110 to central controller 200 at step 1710, cryptographic processor 210 extracts seller ID from seller response 110 at step 1720. Then cryptographic processor 210 looks up the seller's symmetric key at step 1730 and hashes seller response 110 with this symmetric key at step 1740, comparing the resulting hash value with the hash value attached to seller response 110. If the values match at step 1750, the integrity of seller response 110 is verified along with the authenticity of the seller.

Although cryptographic techniques can provide greater confidence in the authenticity of seller response 110, they are useless if the seller's cryptographic keys are compromised. An attacker obtaining the symmetric key of another seller is indistinguishable from that seller in the eyes of central controller 200. There is no way to know whether the seller was the true author of seller response 110, or an attacker with the right cryptographic keys. One way to solve this problem (known as undetected substitution) is to use biometric devices such as a fingerprint reader, voice recognition system, retinal scanner and the like. These devices incorporate a physical attribute of the seller into seller response 110, which is then compared with the value stored in seller database 260 at central controller 200. In the present invention, such devices attach to seller interface 300.

Fingerprint verification, for example, may be executed before the creation of seller response 110, during the generation of seller response 110 in response to prompts from central controller 200, at some predetermined or random times, or continuously by incorporating the scanning lens into seller interface 300 such that the seller is required to maintain his finger on the scanning lens at all times for continuous verification while seller response 110 is generated.

An example of such an identification device is the FC100 FINGERPRINT VERIFIER available from Startek, a Taiwanese company. The FC100 is readily adaptable to any PC via an interface card. The fingerprint verifier utilizes an optical scanning lens. The seller places his finger on the lens, and the resulting image is scanned, digitized, and the data compressed and stored in memory. Typically, a 256- byte file is all that is required. Each live-scan fingerprint is compared against the previously enrolled/stored template, stored in data storage device 360. If the prints do not match, the cryptographic algorithms executed by cryptographic processor 335 may prevent the seller from generating a seller response 110.

In a voice verification embodiment, the seller's voice is used to verify his identity. This embodiment has the advantage of not requiring the use of any specialized hardware since it can be implemented over a standard phone connection. The seller's identity is verified at central computer 200. The process of obtaining a voice-print and subsequently using it to verify a person's identity is well-known in the art, and therefore need not be described in detail herein. One of ordinary skill in the art may refer to SpeakEZ, Inc. for voice identification/verification technology. Conventional speaker identification software samples the seller's voice. This sample is stored at central controller 200 in seller database 260. Each time the seller wants to transmit seller response 110 to central controller 200, he is required to call central controller 200 and speak into the phone at the prompt for a voice sample. If this sample matches that stored in seller database 260, the seller is provided a password which is incorporated into the digital signature appended to seller response 110. Any seller response 110 received without an appropriate voice match password is not accepted. The voiceprint may also be stored in a database within data storage device 360 of seller interface 300, to verify the seller's identity locally prior to allowing seller response 110 to be created.

Although the above cryptographic and biometric protocols describe the authentication and validation of seller response 110, they may be equally applied to the authentication and validation of CPO 100, counteroffer 140, buyer response 150, purchase confirmation 120, or any other message or communication between buyers, sellers, and central controller 200.

ANONYMOUS TRANSACTIONS EMBODIMENT As mentioned previously, the present invention provides for the anonymity of both buyers and sellers. Such anonymity is accomplished by eliminating all references to the names of the individuals for all transactions. A buyer, for example, would include his ID in CPO 100 rather than his name, preventing the seller receiving CPO 100 from discovering the buyer's identity. This is desirable if the buyer were a biotech firm that did not want rivals to know the type of lab equipment that the company was looking for.

In a similar manner, sellers may also want to keep their identity a secret.

An airline might not want the public to know that they are heavily discounting fares between certain cities.

Although using ID numbers can provide anonymity, both for buyers and sellers, there are a number of potential weaknesses. First, if the database of ID numbers, stored in buyer database 255 or seller database 260, and their respective buyers/sellers is compromised, anonymity is destroyed since the message sender can be looked up in buyer database 255 or seller database 260. To prevent this, the ID numbers are encrypted with the public key of central controller 200, so that even if it is stolen it is useless without the private key.

Although we have described only one possible method for maintaining anonymity, there are other equivalents. For example, if the embodiment included telephone messaging, the identity of the buyer and seller could be maintained using conventional voice modification techniques. If CPO 100 or seller response 110 were in a paper form, the form could be scanned using optical character recognition and translated into digital form, discarding any information that could be found in the original document.

TRUSTED SERVER EMBODIMENT In one embodiment of the present invention, central controller 200 is separated into three distinct elements: operations server 160, trusted server 165, and bonding agency 170. Each server performs a distinct task in the process of managing CPO 100. This separation makes it more difficult for attackers to compromise the system, as they must defeat the security of three separate systems instead of one. As indicated in Figure 20, these servers work in conjunction with buyer interface 400 and

seller interface 300. Operations server 160 has the task of posting CPOs 100, and accepts all transactions previously authenticated by trusted server 165. Trusted server 165 authenticates the identity of buyers and sellers, while bonding agency 170 verifies the ability of buyers to pay and the ability of sellers to deliver on bound CPOs 100. In this embodiment, each server type may be distributed over a number of servers.

The following protocols describe the interactions of the three servers and assume the following: 1. Everyone knows the public keys of operations server 160, trusted server 165, and bonding agency 170.

2. The buyer and potential seller have bond certificates 172, as discussed below.

3. Public keys can be used both for encryption and for signing.

Before CPO 100 is accepted by operations server 160, it must bear the digital signature of both trusted server 165 and bonding agency 170. Because of this, CPO 100 contains two additional elements--a trusted server ID and a bond certificate.

The trusted server ID is the ID number of the trusted server 165 that authenticated the buyer who created CPO 100. The"bond certificate"is a public key certificate, with the certifier (bonding agency 170) specifying a set of valid dates for bond certificate 172, a limit to the amount covered, and a set of additional conditions.

These additional conditions may require on-line checking of a revocation list, may specify operations server 160 and trusted server 165 to be used, etc. The private key corresponding to the public key certified is not known to bonding agency 170--only to the user. Knowledge of that private key is used as proof of identity for the bondholder.

(This allows buyer and seller anonymity in many cases, though of course, neither will be anonymous to bonding agency 170 except in very special cases.) Bond certificate 172 for the buyer will be referred to as BCB, while the corresponding public and private keys will be referred to as PKB and SKB, respectively.

CPO 100 is posted by an interaction between the buyer, trusted server 165, and operations server 160. This part of the protocol is possible with nothing more than encrypted e-mail transmitted among the parties.

Before CPO 100 may be posted, the buyer must get approval from trusted server 165. This is required so that both the buyer and operations server 160 know that trusted server 165 they've designated to decide whether or not the contract has been fulfilled is actually willing to accept CPO 100. Operations server 160 will not accept CPO 100 without a TRUSTED ACCEPTANCE message as described below.

The trusted server 165, in turn, will not issue a TRUSTED ACCEPTANCE unless it is convinced that the buyer's CPO 100 is fresh (not a replay), and that the buyer's ability to pay is guaranteed by bonding agency 170.

The buyer must also be convinced that he is being issued a fresh TRUSTED ACCEPTANCE.

The protocol works as follows: 1. The buyer forms UO ="REQUEST FOR TRUSTED APPROVAL" XO = U0, CPO, R0, Additional Terms and sends to trusted server 165 MO = PKEPKA (X0, Sign SKB (XO)).

2. Trusted server 165 responds with U1 ="TRUSTED CPO CHALLENGE" R1 = a 160-bit random number X 1 = U 1 hash (XO), RI and sends to the buyer M1 = PKEPKB (XI, SignSKA (X1)).

3. The buyer responds to this with U2 ="BUYER CPO RESPONSE" X2 = U2, hash (X 1) and sends to trusted server 165 M2 = PKEPKA (X2, SignSKB (X2)).

4. Trusted server 165 responds with U3 ="TRUSTED CPO ACCEPTANCE"

T3 = Timestamp X3 = U3, hash (X2), T3, CPO and sends to the buyer M3 = PKEPKB (X3, SignSKA (X3)).

5. The buyer stores X3 as TRUSTED ACCEPTANCE.

In order for operations server 160 to post CPO 100, it must be convinced that CPO 100 has a fresh TRUSTEDACCEPTANCE, and that it is guaranteed by bonding agency 170. This works as follows: 1. The buyer forms RO = random 160-bit number UO ="CPO SERVER SUBMISSION" XO = U0, R0, TRUSTED ACCEPTANCE and then sends to operations server 160 MO = PKEPKS (X0, SignSKB (XO)).

2. Operations server 160 receives MO and verifies it. If it's fresh (not a replay), and if operations server 160 is willing to post CPO 100, it forms Rl = a random 160-bit number Ul ="SERVER CPO CHALLENGE" X1 = 1, hash (XO), R 1 and then encrypts and sends to the buyer MI = PKEPKB (XI, SignSKS (Xl)).

3. The buyer forms U2 ="CPO RESPONSE TO SERVER CHALLENGE" and then sends to operations server 160 M2 = PKEPKS (X2, SignSKB (X2)).

4. If this message's signature verifies properly, then operations server 160 posts the CPO. Operations server 160 forms U3 ="POSTED CPO RECEIPT" CPO = U3, hash (X2), CPO.

It then sends to the buyer M3 = PKEPKB (CPO, SignSKS (CPO)).

At the end of this protocol, the buyer has a receipt to acknowledge that his CPO 100 has been posted, and operations server 160 is convinced that the holder of bond certificate 172 has just agreed to CPO 100, and has the approval of trusted server 165.

The potential seller has a bonding certificate 172 (BCP) of his own.

Before he is allowed to browse CPOs 100 in real time (with the ability to bind them), he must go through a protocol. (CPOs 100 may be available to people who aren't browsing, but nobody is allowed to bind CPOs 100 until they go through this protocol.) The purpose of this protocol is to prove that the seller is guaranteed by bonding agency 170 to be capable of delivering the required goods, and also to decrease the computational load on operations server 160 by establishing a secret authentication key, Kp. All of this decreases the computational expense of allowing the potential seller to browse CPOs 100.

1. The potential seller forms RO = a random 160-bit number T = a time range UO ="REQUEST FOR ACCESS TO BROWSE" XO = UO, RO, T, BCP and sends to operations server 160 MO = PKEPKS (X0, SignSKP (XO)).

2. Operations server 160 decides whether to grant the potential seller access. If so, it forms Ru = a random 160-bit number U I ="SERVER BROWSE-ACCESS CHALLENGE" X1 = Ul, hash (XO), RI and sends to the potential seller, MI = PKEPKP (XI, SignSKS (XI)).

3. The potential seller responds by forming U2 ="BROWSE-ACCESS RESPONSE" and sends to operations server 160 M2 = PKEPKS (X2, SignSKP (X2)).

4. Operations server 160 verifies the signature, and then responds by forming U3 ="BINDING KEY" Kp = a random secret key to be used for binding CPOs 100.

T = a time range (from first protocol message) X3 = U3, hash (X2), T, Kp and sends to the potential seller M3 = PKEPKP (X3, SignSKS (X3)).

At the end of this protocol, the potential seller holds the secret shared key with which he is allowed to bind CPO 100, within the time limits specified in the last message. The potential seller and operations server 160 are both convinced that they have interacted with one another in real-time, and operations server 160 knows that the potential seller's capacity to deliver on bound CPOs 100 are guaranteed by bonding agency 170.

As the potential seller browses CPOs 100, each is sent to him by operations server 160, authenticated under Kp, and including a random challenge to prevent replay attacks. When the potential seller wants to bind one, he forms an offer to bind CPO 100, and sends it, along with the hash of the authenticated CPO 100, authenticated under Kp. Operations server 160 is convinced that this is a valid offer to bind CPO 100, and that it's happening in real time. It responds by sending him BOUNDCPO.

1. Operations server 160 forms UO ="CPO OFFER" RO = a random 160-bit number, XO = U0, R0, CPO description and sends the potential seller MO = PKEPKP (X0, AuthKp (XO)).

(Note that this step is repeated for each CPO 100 browsed.)

2. The potential seller forms Ul ="CPO OFFER TO BIND" R1 = a random 160-bit number X1 = U1, hash (XO), R 1, Offer Details and encrypts and sends to operations server 160 M 1 = PKEPKS (X 1, AuthKp (X 1)).

3. If the offer is acceptable to operations server 160, then it forms U2 ="SERVER BINDING OF CPO" T = timestamp X2 = U2, hash (X1), BCP, T, CPO, Offer Details and encrypts and sends to the potential seller M2 = PKEPKP (X2, SignSKS (X2)).

4. The potential seller stores X2, SignSKS (X2) as BOUNDCPO.

The"Offer Details"field of BOUNDCPO specifies the conditions of CPO 100. In most cases, this will involve delivering some goods in exchange for payment, possibly in the presence of an agent from trusted server 165. In some cases, however, this will involve intermediaries, to preserve anonymity for the potential buyer, the seller, or both. it is important that the potential seller has the BOUNDCPO so that he can prove his identity to the buyer or an intermediary with a simple challenge- response protocol.

This set of protocols describes one possible implementation of an infrastructure to support CPOs 100. It is important to note that operations server 160, trusted server 165, and bonding agency 170 can conceivably be the same entity. In this case, these protocols can be dramatically simplified.

BARTER EMBODIMENT Not all transactions require the transfer of money from buyer to seller. In a barter transaction the distinction between buyer and seller disappears, resulting in a contract between a first party and a second party. The first party posts CPO 100, and the second party binds it. Instead of getting cash, the second party receives goods from

the first party. A first party who wanted to get rid of a motorcycle, for example, could post CPO 100 in which he offered to exchange the motorcycle for a first class ticket from New York to London.

ARBITRATION PROTOCOLS Although the previous embodiments have described the delivery of goods from seller to buyer as the end of the process, there will inevitably be disputes arising from some transactions, requiring follow-up activity to resolve these disputes.

The present invention can support dispute resolution in two ways.

First, language can be built into every CPO 100 requiring that both parties submit to binding arbitration of all disputes, helping to avoid more costly and time consuming legal battles in a court of law. Additionally, liquidated damages may be set which specify damage amounts for particular infractions of CPO 100.

Second, central controller 200 can support the arbitration process by providing an arbiter for each dispute. Such arbitration might be required when goods shipped from the seller do not correspond to the conditions of CPO 100. A buyer seeking a non-stop airline ticket, for example, might seek damages against a seller who delivered a ticket with one or more stops. Similarly, a business traveler whose CPO 100 for a non-smoking hotel room might seek damages from the hotel which bound the CPO with a smoking room. Instead of seeking damages, the buyer may seek replacement of the goods, such as another airline ticket that was non-stop. In an arbitration involving airline tickets, the buyer may submit a copy of the ticket to central controller 200 along with the tracking number of CPO 100, allowing the arbiter to establish whether or not the seller fulfilled the conditions of CPO 100. Sellers may also initiate arbitration proceedings if they have shipped the goods and have not yet received payment from the buyer.

In an alternative embodiment, transaction data can be sent to third party arbiters outside the system. Central controller 200 may send a copy of CPO 100, seller response 110, and purchase confirmation 120 to the arbiters. Cryptographic keys may also be provided to the arbiters if there are questions of authenticity or non-repudiation.

APPLICATIONS OF THE INVENTION In order to clarify the application of the present invention, the following examples demonstrate potential needs of end users: CPO: Airline tickets Four tickets needed From Chicago, O'Hare or Midway to Phoenix.

Leaving on April 12 or 13 Returning on April 18 or 19.

Any of the six largest carriers acceptable.

Change of planes is acceptable if layover is less than 2 hours.

Ill bind at $180 per ticket, excluding tax.

CPO: Hotel accommodations Five nights lodging Arrive April 12 or 13, Depart April 18 or 19 Within 30 minutes drive time of downtown Phoenix.

Double bed Non-smoking Hotels, motels or bed & breakfasts are acceptable Must be AAA approved or Mobil 2* or better.

Ill bind at $55 per night (excluding tax).

CPO: New car purchase 1997 Ford Taurus Must be in dealer stock GL package w/air conditioning AM/FM/Cassette (Stock #1224-099) May have other options already installed Can be white, tan, green or maroon Must have 100 miles or less, never titled.

No dealer demo cars Delivered to me no later than July 15,1996 Loan pre-approval: Chase Manhattan #1220-998-887AD-21 I'll bind at $21,350

CPO: Car insurance 1997 Ford Taurus 1 driver, age 40, male Reside in Ridgefield, CT Drive to work 30 miles Collision included $500 deductible Glass coverage included No speeding infractions in last 3 years No accident in past 3 years 1MM liability umbrella Driver's license # CT 1222-221-2298 Carrier must be rated A or better by AM Best. ni bind at $1,200 per year CPO: U. S. silver dollars 1886 Morgan Philadelphia mint mark Sealed in ANA packaging MS94 or better grade I will purchase up to 6 total Sellers may fulfill all or part of order I'll bind at $225 each Offer Administrator: Coinworld, P. O. Box 1000, N. Y., N. Y.

Mr. K. Smith 212-222-1000 CPO: Industrial commodity My company wants to purchase 40 tons of steel Grade 120 Delivered FOB to NY, NY Class 4 Slabs or Class 12 ingots Alloy RT-12 or equivalent Deliver by August 1,1996 Maximum price known to Citibank

First bid below maximum will bind Citibank to provide instant price verification 1 bid per supplier per day (GMT) E-mail @ metals. biddesk4022Citi. com Letter of Credit payment, Citibank 100-887-9877 CPO: Credit Card Application VISA Gold Card Credit line $5,000 Interest rate 12% or lower Ill bind at $10 per year Financial history available at http ://www. provider/-shapiro23 CPO: Reward for Return Briefcase lost with important computer disks inside Disks labeled RT-554 IBM Case is brown leather, brass snaps, RL monogram Left on NYC subway, April 7,1996 F Train.

Ill bind at $500 Provide lost & found receipt # to claim reward Offer Administrator: NYC Police Lost & Found Mr. K. Smith 212-555-1000 INDUSTRIAL APPLICABILITY In view of the foregoing detailed description, it is evident that the instant invention may be used to create one or more of the following systems, among others: -a system which allows a seller to meet the terms of the purchase offer to bind the buyer to accept the seller's fulfillment of that offer; -a system which allows the seller to be able to collect funds immediately upon his acceptance of the buyer's terms as set forth in the purchase offer; -a system that allows for a trusted third-party administrator whose decision regarding the fulfillment, adequacy or interpretation of any aspect of the process shall be binding on the parties;

-a system which allows the seller to receive part of his payment upon agreeing to the buyer's purchase offer, and a subsequent payment upon delivery of the goods or services called for in the buyer's purchase offer; -a system which allows either buyers or sellers to remain anonymous up until such time as an agreement is consummated and for buyers to remain anonymous even after the agreement is consummated by using the trusted third-party as a relay system for delivery of goods or services called for by the buyer's purchase offer; -a system which ensures that buyers using the inventive system are not inundated with inquiries or acceptances from unqualified sellers; -a system which provides a system in which the identity of the buyer is authenticated along with the integrity of the buyer's purchase offer.

-a system in which the identity of the seller is authenticated in order to determine the seller's capacity to satisfy the conditions of the purchase offer; -a system which allows sellers to submit authenticatable counteroffers to the buyer; -a system in which counteroffers may allow the buyer to bind the seller to the counteroffer, subject to the authenticatable terms of that counteroffer; -a system which allows for delivery of digitally-based products such as certificates of insurance from the seller to the buyer according to the terms of the buyer's purchase offer and the cryptographic validation of such delivery; -a system which allows for purchase offers where more than one seller may bind the buyer to the purchase offer; and -a system which shows how all or part of the system can be practiced using non-electronic means such as printed media or advertisements in newspapers.

In view of the aforementioned detailed description of the present invention, it is readily apparent that the present invention provides a method and apparatus for prospective buyers of goods or services to communicate a binding purchase offer globally to potential sellers, for sellers conveniently to search for relevant buyer purchase offers, and for sellers to bind a buyer to a contract based on the buyer's purchase offer. Additionally, the present invention can effectuate performance of the agreement between the buyer and seller by guaranteeing buyer payment for the purchase. The present invention is therefore a highly effective bilateral buyer-driven

commerce system which improves the ability of buyers to reach sellers capable of satisfying the buyer's purchasing needs and improves sellers'ability to identify interested buyers.

In one embodiment of this invention, communications between buyers and sellers are conducted using an electronic network and central controller. A buyer who wishes to make a purchase accesses the central controller located at a remote server. The buyer will then create a conditional purchase offer ("CPO") by specifying the subject of the goods he wishes to purchase, a description of the goods he wishes to obtain, and any other conditions the buyer requires. For example, a typical CPO could specify that the buyer wants to purchase a block of four airline tickets from Chicago's 0'Hare Airport to Dallas, Texas, the tickets must be from any of the six largest U. S. carriers, the buyer is willing to change planes no more than once so long as the scheduled layover is less than two hours, and the buyer is willing to pay $ 180 per ticket, plus any applicable taxes.

The buyer then attaches a user identification to the CPO and transmits the CPO to the central controller. Under the present invention, the CPO may be transmitted via numerous means including a world-wide-web interface, electronic mail, voice mail, facsimile, or postal mail. Standard legal provisions and language are then integrated with the CPO to"fill in the gaps"of the buyer's purchase offer. Alternatively, the CPO may be developed while the buyer is on-line with the central controller.

Before communicating the CPO to potential sellers, the central controller authenticates the buyer's identification number against a buyer database. The central controller may require that the buyer provide a credit card number and may also ensure that the buyer has sufficient credit available to cover the purchase price specified in the CPO by contacting the credit card clearinghouse. The central controller then assigns a unique tracking number to the CPO and globally displays the CPO in a manner such that it is available to be viewed by any interested potential sellers. CPOs may be displayed by subject category to make it easier for potential sellers to identify relevant CPOs. Thus, a seller could log onto a web-site, for example, and see a listing of CPO subject categories. The seller could then choose a particular subject and have the ability to browse CPOs which correspond to that subject category. In one embodiment, the

seller may be required to provide qualifications in order to view the CPOs of a given subject category.

If, after reviewing a particular CPO, a potential seller wishes to accept the CPO the seller communicates his intent to the central controller. The central controller then timestamps the message from the seller and authenticates the identity of the seller and his capacity to deliver the goods sought by the buyer. The system then verifies that the particular CPO is still"active"and capable of being accepted. If a CPO is capable of being accepted only by one seller, it is"completed"when the first qualified seller accepts it. Subsequent sellers will not be able to accept a"completed"CPO. If a seller accepts an active CPO, a unique tracking number is assigned to the seller's acceptance. The acceptance is then stored in a database. The buyer and seller are now parties to a legally binding contract.

In another embodiment, the central controller manages the payment system between the buyer and seller automatically. Various methods of payment may be utilized by the invention, including credit cards, personal checks, electronic funds transfer, debit cards, and digital cash. The payment system may also involve the use of an escrow account associated with the buyer wherein funds advanced by the buyer to cover the purchase of a desired good can be kept pending acceptance by a qualified seller. Moreover, the timing of payment to the seller can be varied. The seller can be paid immediately after the seller accepts the CPO or payment can be delayed until after the seller performs his obligations under the contract.

In yet another embodiment of the present invention, a seller is given the option to respond to a CPO by issuing a binding counteroffer with conditions different from the original CPO. The seller transmits the counteroffer to the central controller that then forwards the counteroffer to the buyer. The buyer is then given the option of accepting the counteroffer and thereby binding the seller to a contract.

The present invention can also be practiced in off-line embodiments.

Instead of using electronic mail or web-based servers, buyers and sellers may communicate with the central controller via telephone, facsimile, postal mail, or another off-line communication tool. For example, buyers may use telephones to create CPOs (with or without the assistance of live agents) and potential sellers may use a telephone to browse and bind CPOs.

In another on-line embodiment, cryptographic protocols are used to authenticate the identity of buyers and/or sellers and verify the integrity of buyer and seller communications with the central controller. Using cryptography and biometrics, the central controller can make it significantly more difficult for unauthorized persons to tamper with the system by passing themselves off as legitimate buyers or sellers or eavesdropping on system communications.

Anonymity is another advantage of the present invention. For numerous privacy and competitive reasons, buyers and sellers often prefer not to have their identities revealed to the general public when engaging in commercial transactions. The present invention effectuates the anonymity of buyers and sellers through the use of identification numbers stored in a database secured by the central controller.

One embodiment of the present invention divides the functionality of the central controller into three components and embodies them in three separate servers: an operations server, a trusted server, and a bonding agency. The trusted server authenticates the identity of buyers and sellers while the bonding agency verifies their ability to pay or deliver goods. The operations server posts the CPO, relying upon messages from the other two servers for validation. This configuration allows for greater specialization of the servers.

Another embodiment of the present invention does not require a transfer of money from a buyer to a seller. Instead, the system may be used to consummate a contract involving an exchange of goods, services, or other non-monetary consideration.

Finally, an embodiment of the present invention includes a mechanism for resolving disputes between buyers and sellers arising out of agreements consummated using the system. The parties may be required in CPOs to stipulate to binding arbitration and may be assisted in the arbitration process by the central controller. The central controller may serve as an arbitrator or may refer the dispute to a third-party arbitrator for resolution.

What the present invention accomplishes, which no previous system has done before, is literally to hang buyer money out on a clothesline for all sellers to see.

Attached to the money is a note describing what the seller has to agree to do in order to take the money down off the clothesline. There is no uncertainty or waste of time on

the part of the seller. He knows that if he can meet the conditions set forth by the buyer, he can immediately close the sale and get paid for it. No hassles. No negotiations.

The invention also allows buyers to reach a large number of remotely located sellers who normally would not be able to afford to find the buyer, but who may be able to provide the buyer with the exact deal the buyer desires. For instance, this might be the case for a car buyer who could precisely define the car and option packages he wanted for a specified price. The present invention allows such a buyer to issue a binding purchase offer that is globally communicated to authorized dealers in the U. S.. Any one of those dealers could then decide whether or not to accept the offer.

The buyer's advantage is particularly significant when the sellers of products sought by the buyer have no inventory carrying costs, as is the case with insurance sales.

Insurance buyers could use the present invention to cast a wide net to reach thousands of potential insurance sellers and potentially find a seller willing to satisfy the buyer's specified purchase conditions.

It is a goal of the present invention to provide a robust system that matches buyers'requirements with sellers capable of satisfying those requirements. The invention provides a global bilateral buyer-driven system for creating binding contracts incorporating various methods of communication, commerce and security for the buyer and the seller. The power of a central controller to field binding offers from buyers, communicate those offers globally in a format which can be efficiently accessed and analyzed by potential sellers, effectuate performance of resulting contracts, resolve disputes arising from those contracts, and maintain billing, collection, authentication, and anonymity makes the present invention an improvement over conventional systems.

AGENCY-BASED SELLERS The method and apparatus of another embodiment of the present invention, which permits the CPO management system to accept or reject a given CPO on behalf of certain agency-based sellers who have delegated such authority to the CPO management system, will now be discussed with reference to Figures 21 through 40.

Figure 21 shows a conditional purchase offer (CPO) management system 2100 for receiving conditional purchase offers from one or more customers or travel agents 2110, hereinafter referred to as customer 2110, and for evaluating the received CPOs against a number of CPO rules defined by a plurality of sellers, such as airlines 2120,2130 or

cruise operators (not shown), to determine whether any seller is willing to accept a given CPO. As discussed further below, if a seller accepts a given CPO, the CPO management system 2100 binds the customer 2110 on behalf of the accepting seller 2130, to form a legally binding contract.

As used herein, a CPO is a binding offer containing one or more conditions submitted by a customer 2110 for the purchase of an item, such as air travel, at a customer-defined price. In the illustrative airline embodiment, the customer- defined conditions would include itinerary parameters, such as the origin and destination cities; acceptable dates and times of departure and return; and whether connecting flights or stopovers are acceptable to the customer. In addition, the parameters of a CPO may allow a customer to specify one or more preferred airline (s), flights, seat assignments, seat class, aircraft type, refund/change rules, or maximum layover time. In a cruise embodiment, the customer-defined conditions would also include itinerary parameters, such as the origin and destination cities; acceptable dates and times of departure and return; as well as one or more preferred cruise operators, ship type, cabin class, and dining preference.

As discussed further below, a CPO rule is a set of restrictions defined by a given seller, such as an airline, to define a combination of such restrictions for which the seller is willing to accept a predefined minimum price. In a preferred embodiment, the CPO rules are generated by the revenue management system 2500 of the respective airline or cruise operator. In alternate embodiments, the CPO rules may be generated by a yield management system, a profit management system, or any system that controls and manages inventory.

As discussed more fully below in conjunction with Figures 25b and 39, the revenue management system 2500 will employ a CPO rules generation process 3900 to generate CPO rules by evaluating current inventory, pricing and revenue information, as well as historical patterns and external events, to forecast future travel. Thereafter, the CPO rules are utilized by the CPO management system 2100 to render a decision to either accept, reject or counter a CPO on behalf of a particular airline or cruise operator.

According to a feature of the present invention, the CPO rules are dynamic in nature and may be updated by a given airline or other seller, as necessary.

For example, a CPO rule for a given airline can specify that the airline will accept any CPO for travel between Newark, New Jersey (EWR) and Orlando, Florida (MCO) during the month of October, 1997, provided that (i) the customer travels between Tuesday and Thursday, (ii) the tickets are booked within 21 days of departure, (iii) the price is at least $165 per ticket, (iv) K-class inventory is available on all flight segments of the customer's itinerary, and (v) there are at least two (2) passengers travelling together.

Although the CPO management system 2100 is illustrated herein as a system for selling airline or cruise tickets, the CPO management system 2100 could be utilized to sell any good or service product, such as automobiles, insurance, computer equipment, or hotel accommodations, as would be apparent to a person of ordinary skill.

For a more detailed discussion of a general CPO management system for selling such items, see U. S. Patent Application Serial No. 08/707,660, filed September 4,1996, the parent application to the present invention, which is incorporated by reference herein. It is noted that in such alternate embodiments, the revenue management system 2500, discussed below in conjunction with Figures 25a through 25c, may be embodied as an inventory management system or any other system utilized by the seller to establish pricing and inventory information for the respective item.

CPO MANAGEMENT SYSTEM As shown in Figure 21, the CPO management system 2100 preferably includes a CPO management central server 2200 and one or more secured airline servers 2300. As discussed further below in conjunction with Figure 23, each secured airline server 2300 may be associated with one or more airlines or cruise operators and each server 2300 stores, among other things, the CPO rules defined by any associated sellers, such as the airline 2120. Each secured airline server 2300 may be remotely located from the CPO management central server 2200, as shown in Figure 21, or may be integrated with the CPO management central server 2200. In one remote embodiment, the secured airline server 2300 associated with each airline or cruise operator may be physically located at a processing facility secured by the particular airline or cruise operator, or at the physical location of a third party. In this manner, the airline or cruise operator can evaluate CPO rules independently.

The particular location of the secured airline servers 2300 will dictate the nature of the information that is transmitted between the airlines 2120,2130 or cruise operators (not shown) and the CPO management system 2100, as would be apparent to a person of ordinary skill. For example, if the secured airline servers 2300 are integrated with the CPO management central server 2200, or are otherwise remotely located from the respective airlines 2120,2130 or cruise operators (not shown), then the respective airline 2120,2130 or cruise operator will transmit the CPO rules to the location of the airline's associated secured airline server 2300 for storage of the CPO rules and application of the CPO rules against each received CPO. Likewise, if the secured airline servers 2300 are physically located at the processing facility secured by the associated airline or cruise operator, then the CPO management central server 2200 will transmit the CPOs to each airline or cruise operator for processing and the airlines or cruise operator will return the response for each CPO to the CPO management central server 2200. Thus, the CPO management system 2100 can determine if one or more sellers accepts a given CPO by providing the CPO to each seller and receiving an acceptance or rejection, or by applying the CPO to the CPO rules to render a decision to either accept, reject or counter a CPO on behalf of a particular seller.

The CPO rules contain sensitive information, including price flexibility and available capacity, which, if known to a seller's competitors or customers, could dramatically impact the seller's overall revenue structure. Thus, according to a feature of the present invention, the CPO rules are preferably securely stored by each airline server 2300, if necessary, to prevent one seller, such as airline 2120, from accessing, obtaining or altering the CPO rules of another seller, such as airline 2130. In one embodiment, the secured airline servers 2300 utilize computer security techniques, such as database access control mechanisms. In this manner, the integrity and confidentiality of the CPO rules are maintained in the potentially hostile computing environment.

In addition, according to a further feature of the invention, the CPO management system 2100 prevents customers 2110 from submitting multiple CPOs containing a progressively increasing price in order to identify the seller's defined minimum price for a given flight or berth. For example, if the CPO will be binding upon the customer 2110 if accepted by any airline 2120 or cruise operator, the customer 2100 will be discouraged from"pinging"the CPO management system 2100 to identify

the seller's underlying price flexibility. In addition, the CPO management system 2100 can limit the number of CPOs that any customer 2110 can submit within a predefined time period.

In alternate embodiments, the customer or travel agent 2110 can be charged a fee or a penalty if a ticket is not booked when at least one airline has accepted the CPO or the CPO management system 2100 can evaluate a rating of said customer 2110 containing information regarding the likelihood that said customer 2110 will book a ticket corresponding to said CPO. For a more detailed description of a suitable rating system, see U. S. Patent Application Serial No. 08/811,349, filed March 4,1997, entitled AIRLINE PRICE INQUIRY METHOD AND SYSTEM, assigned to the assignee of the present invention and incorporated by reference herein. In one embodiment, the evaluated rating comprises a ratio of bookings to purchase offers by the customer 2110.

In this manner, the airline or cruise operator can be confident that if the seller accepts the customer's offer, the customer will book the ticket without using the information to ascertain the seller's underlying level of price flexibility. The particular location of a given secured airline server 2300 may also impact the level of security measures that the associated airline (s) or cruise operator (s) may desire for the sensitive CPO rules. For example, if a given secured airline server 2300 is dedicated to a single airline and is physically located at a processing facility secured by the associated airline, then the respective airline may implement its own minimal security measures to control the processing of each CPO against its own CPO rules, if desired, and thereby maintain the integrity and confidentiality of the price-sensitive information incorporated into the CPO rules. If, however, a given secured airline server 2300 stores the CPO rules for a plurality of airlines or cruise operators and is remotely located from such airlines or cruise operators, then the importance of implementing computer security and database access control mechanisms may be increased, as would be apparent to a person of ordinary skill.

As discussed further below, each customer 2110 contacts the CPO management system 2100, for example, by means of telephone, facsimile, online access, e-mail, in-person contact or through a travel agent, and provides the CPO management system 2100 with the terms of their CPO. It is noted that each customer 2110 may employ a general-purpose computer for communicating with the CPO management

system 2100. The general-purpose computer of each customer 2110 is preferably comprised of a processing unit, a modem, memory means and any software required to communicate with the CPO management system 2100.

Once the terms of the CPO have been received by the CPO management system 2100, the CPO management central server 2200 will execute a CPO management process 3600, discussed below in conjunction with Figures 36a through 36c, to compare the received CPO against the CPO rules of each airline or cruise operator. As a result of this comparison, the CPO is either accepted, rejected or countered. Thereafter, the customer 2110 is notified of the response of the airlines or cruise operators to the CPO. If a seller accepts the CPO, or if the customer 2110 accepts a counteroffer from a seller, a ticket is then booked by the CPO management system 2100 with the appropriate restrictions which meet the conditions defined by the customer 2110.

According to a further feature of the present invention, the minimum requirements of a CPO are designed to discourage utilization of this system by business travelers or last minute travelers who are typically willing to pay full-fare. For example, business travelers will be discouraged if the CPO rules require a Saturday night stay or significant flexibility by the customer 2110 on the time of both the departure and return portions of the customer's itinerary. In this manner, business travelers, who are typically unwilling to lose up to a full day at either end of their trip, will be discouraged from purchasing such discounted tickets. Thus, the present invention permits airlines to fill otherwise empty seats in a manner that stimulates latent and unfulfilled leisure travel demand while leaving underlying fare structures of the airlines 2120,2130 intact.

Likewise, in embodiments where the CPO management system is utilized for the sale of any item, the minimum requirements of a CPO are preferably designed to discourage utilization of this system by customers who are typically willing to pay the full retail price. For example, when selling fashion items, CPO customers can be required to purchase fashions from the previous season. Similarly, the CPO rules can be designed to require the purchase of multiple quantities of a given item, and thereby discourage use by consumers looking for one item, who are more likely to pay the full retail price.

In a preferred embodiment, the CPO management system 2100 may optionally access a central reservation system (CRS) 2400, discussed below in conjunction with Figure 24, to perform itinerary queries that will identify particular flights or berths which satisfy a given itinerary, and to make reservations. The central reservation system (CRS) 2400 may be embodied, for example, as an existing conventional reservation system, such as Apollo, Sabre, System One or Worldspan.

In addition, the CPO management system 2100 could alternatively access the proprietary reservation systems (ARSs) 2150 of each airline or cruise operator to perform such itinerary queries and to make reservations with the respective airline or cruise operator. The airline reservation systems (ARSs) 2150 maintained by each airline 2120, are each essentially a subset of the central CRS 2400. Thus, in view of the overlapping functions and capabilities of the CRS 2400 and the proprietary reservation systems 2150 of each airline or cruise operator, the CPO management system 2100 could access any of such systems to obtain required information, and the terms"CRS" and"ARS"are used interchangeably herein.

As shown in Figure 21, each airline 2120,2130 or cruise operator (not shown), also has a revenue management system (RMS) 2500, discussed further below in conjunction with Figures 25a through 25c. The RMS 2500 may be embodied as a conventional RMS, as modified herein to generate CPO rules and to otherwise allocate and price airline or cruise tickets for sale to CPO customers.

Generally, the revenue management systems (RMSs) 2500 are utilized to optimize revenue per flight or berth, in a known manner. An RMS performs seat or cabin inventory control by periodically adjusting nested booking limits ("buckets") for the various fare classes, in order to optimize the passenger mix and thereby maximize the generated revenue.

The CPO management system 2100, customer 2110, airlines 2120,2130, cruise operators (not shown) and central reservation system 2400 (collectively, the "nodes") preferably transmit digitally encoded data and other information between one another. The communication links between the nodes preferably comprise a cable, fiber or wireless link on which electronic signals can propagate. For example, each node may be connected via an Internet connection using a public switched telephone network (PSTN), such as those provided by a local or regional telephone operating company.

Alternatively, each node may be connected by dedicated data lines, cellular, Personal Communication Systems ("PCS"), microwave, or satellite networks.

Figure 22 is a block diagram showing the architecture of an illustrative CPO management central server 2200. The CPO management central server 2200 preferably includes certain standard hardware components, such as a central processing unit (CPU) 2205, a random access memory (RAM) 2210, a read only memory (ROM) 2220, a clock 2225, a data storage device 2230, and communications ports 2240,2250, 2260. The CPU 2205 is preferably linked to each of the other listed elements, either by means of a shared data bus, or dedicated connections, as shown in Figure 22.

The CPU 2205 may be embodied as a single commercially available processor, such as Intel's Pentium 100 MHz P54C microprocessor, Motorola's 120 MHz PowerPC 604 microprocessor or Sun Microsystem's 166 MHz UltraSPARC-I microprocessor. Alternatively, the CPU 2205 may be embodied as a number of such processors operating in parallel.

The ROM 2220 and/or data storage device 2230 are operable to store one or more instructions, discussed further below in conjunction with Figure 36, which the CPU 2205 is operable to retrieve, interpret and execute. For example, the ROM 2220 and/or data storage device 2230 preferably store processes to accomplish the transfer of required payments, charges and debits, between the airlines 2120,2130 and customers 2110. In particular, as discussed below in conjunction with Figure 36c, the CPO management process 3600 preferably transmits the credit card information associated with a given customer 2110 to the credit card issuer for payment, if a ticket is actually issued to the customer 2110. The processing of such accounting transactions are preferably secured in a conventional manner, for example, using well-known cryptographic techniques.

The CPU 2205 preferably includes a control unit, an arithmetic logic unit (ALU), and a CPU local memory storage device, such as, for example, a stackable cache or a plurality of registers, in a known manner. The control unit is operable to retrieve instructions from the data storage device 2230 or ROM 2220. The ALU is operable to perform a plurality of operations needed to carry out instructions. The CPU local memory storage device is operable to provide high-speed storage used for storing temporary results and control information.

As discussed further below in conjunction with Figures 26 through 29, respectively, the data storage device 2230 includes a customer database 2600, an airline database 2700, a flight schedule database 2800, and a CPO database 2900. The customer database 2600 preferably stores information on each customer of the CPO management system 2100, including biographical information and billing information, such as a credit card number. The airline database 2700 preferably stores information on each airline which is registered with the CPO management system 2100 to sell airline tickets to CPO customers, including address and contact information. The flight schedule database 2800 preferably stores specific flight information for each O & D Pair. Finally, the CPO database 2900 preferably contains a record of each CPO being processed by the CPO management system 2100, including the terms of the CPO and the associated status.

In addition, the data storage device 2230 includes a CPO management process 3600, discussed further below in conjunction with Figure 36. Generally, the CPO management process 3600 receives each CPO from a customer 2110, compares the CPO against the CPO rules of each airline 2120,2130, and determines whether to accept, reject or counter the CPO on behalf of an airline.

The communications port 2240 connects the CPO management central server 2200 to the central reservation system (CRS) 2400 and the proprietary reservation systems (ARSs) 2150 maintained by each airline 2120,2130. The communications port 2250 connects the CPO management central server 2200 to individual customers and travel agents, such as the customer 2110, for example, by means of an Internet connection using the public switched telephone network (PSTN).

The communications port 2260 connects the CPO management central server 2200 to any remote secured airline servers 2300. The communications ports 2240,2250,2260 each preferably include multiple communication channels for simultaneously establishing a plurality of connections. It is noted that although the CPO management central server 2200 is illustrated as having three separate communication ports 2240, 2250,2260, the CPO management central server 2200 could alternatively be implemented with a single connection to an Ethernet network, which in turn provides the central server 2200 with a connection to the various nodes.

Figure 23 is a block diagram showing the architecture of an illustrative secured airline server 2300. As previously indicated, the CPO management system 2100 may utilize one or more secured airline servers 2300, each supporting one or more airlines 2120,2130. Each secured airline server 2300 preferably includes certain standard hardware components, such as a central processing unit (CPU) 2305, a random access memory (RAM) 2310, a read only memory (ROM) 2320, a clock 2325, a data storage device 2330, and communications ports 2340,2345. Each of these components may be identical to those described above in conjunction with Figure22.

As previously indicated, in one embodiment, the CPO rules may be stored in a secure database to maintain the integrity and confidentiality of the highly sensitive information included in each CPO rule. Thus, the secured airline server 2300 preferably uses a secure database, such as the products commercially available from Oracle, Informix or IBM.

As discussed further below in conjunction with Figures 30 through 32, respectively, the data storage device 2330 includes a secured airline rules database 3000, a counteroffer rules database 3100, and a secured airline audit database 3200.

The secured airline rules database 3000 preferably maintains the CPO rules for the one or more airlines associated with the secured airline server 2300. The counteroffer rules database 3100 is preferably stored by each secured airline server 2300 to maintain a set of tolerances which may be utilized by the CPO management system 2100 to generate a counteroffer to a CPO on behalf of an airline, if the CPO is within predefined tolerances of one or more restrictions associated with a given CPO rule. As previously indicated, the secured airline rules database 3000 and the counteroffer rules database 3100 may be stored in an encrypted format to maintain the integrity and confidentiality of the highly sensitive information included in the CPO rules. The secured airline audit database 3200 preferably maintains an audit trail for each CPO that is processed by the CPO management system 2100.

In addition, the data storage device 2330 includes an evaluation process 3700 and an audit process 3800, discussed further below in conjunction with Figures 37 and 38, respectively. Generally, the evaluation process 3700 is a subroutine executed by the CPO management process 3600, which receives a CPO and compares the CPO against the rules of one airline, such as the airline 2120, to generate a response on behalf

of the airline to the given CPO. The audit process 3800 is a subroutine executed by the CPO management process 3600 to maintain an audit trail for each CPO that is processed by the CPO management system 2100.

The communications port 2340 connects the secured airline server 2300 to the CPO management central server 2200. The communications port 2345 connects the secured airline server 2300 to the associated airlines (s) 2120. The communications ports 2340,2345 preferably include multiple communication channels for simultaneously establishing a plurality of connections.

CENTRAL RESERVATION SYSTEM Figure 24 is a block diagram showing the architecture of an illustrative central reservation system (CRS) server 2400. The CRS 2400 preferably includes certain standard hardware components, such as a central processing unit (CPU) 2405, a random access memory (RAM) 2410, a read only memory (ROM) 2420, a clock 2425, a data storage device 2430, and a communications port 2440. Each of these components may be identical to those described above in conjunction with Figure 22.

The ROM 2420 and/or data storage device 2430 are operable to store one or more instructions, for processing (1) flight information received from the airlines; (2) itinerary inquiries regarding flight availability; and (3) ticket bookings, in a known manner, which the CPU 2405 is operable to retrieve, interpret and execute.

As discussed further below in conjunction with Figures 28,33 and 34, respectively, the data storage device 2430 includes a flight schedule database 2800, a pricing and restrictions database 3300, and a seat allocation database 3400. As previously indicated, the flight schedule database 2800 contains essentially the same flight information as the database of the same name which is stored by the CPO management central server 2200, namely, specific flight information for each O & D Pair. The pricing and restrictions database 3300 maintains pricing information and related restrictions for each fare class on a given flight offered by the airlines 2120, 2130. The seat allocation database 3400 maintains available inventory information for each fare class on a given flight offered by the airlines 2120,2130.

The communications port 2440 connects the CRS 2400 to the CPO management central server 2200 and to each airline, such as the airlines 2120,2130.

The CRS 2400 preferably includes an electronic mail processor 2450 for processing and

storing e-mail messages transmitted between the CRS 2400 and the various customers 2110, airlines 2120,2130 and the CPO management system 2100.

REVENUE MANAGEMENT SYSTEM Figure 25a is a block diagram showing the architecture of an illustrative revenue management system (RMS) 2500, as maintained by each airline, such as the airline 2120. As previously indicated, the RMS 2500 may be embodied as a conventional RMS, such as an RMS commercially available from Sabre Decision Technologies, as modified herein to generate CPO rules and to otherwise allocate and price airline tickets for sale to CPO customers. In this manner, the RMS 2500 makes a portion of the inventory of an airline 2120 available for sale to CPO customers 2110. It is noted that the RMS for many airlines performs only the function of inventory allocation and does not incorporate a pricing function. In such cases, a separate system, such as a manual process, is utilized to price inventory that has been allocated by the RMS. In the illustrative embodiment disclosed herein, the RMS 2500 performs both the inventory allocation and pricing functions.

The RMS 2500 preferably includes certain standard hardware components, such as a central processing unit (CPU) 2505, a random access memory (RAM) 2510, a read only memory (ROM) 2520, a clock 2525, a data storage device 2530, and a communications port 2540. Each of these components may be identical to those described above in conjunction with Figure 22.

The ROM 2520 and/or data storage device 2530 are operable to store one or more instructions, for analyzing current seating inventory and revenue, as well as historical patterns, to allocate and price available seat inventory in an effort to maximize revenue for the airline, which the CPU 2405 is operable to retrieve, interpret and execute.

As discussed further below in conjunction with Figures 33 through 35, respectively, the data storage device 2530 includes a pricing and restrictions database 3300, and a seat allocation database 3400, which each contain essentially the same information as the databases of the same name stored by the CRS 2400, as well as a forecast and demand analysis database 3500. As previously indicated, the pricing and restrictions database 3300 maintains pricing information and related restrictions for each fare class on a given flight offered by the associated airline 2120, and the seat allocation

database 3400 maintains available inventory information for each fare class on a given flight offered by the associated airline 2120. The forecast and demand analysis database 3500 contains information on each selling price for each fare class for a given flight, and the forecasted demand at each selling price as established by the RMS 2500. In addition, the data storage device 2530 preferably includes a CPO rules generation process 3900, discussed below in conjunction with Figure 39, to generate CPO rules by evaluating current inventory, pricing and revenue information, as well as historical patterns, to forecast future travel.

The communications port 2540 connects each RMS 2500 to the CRS 2400 and the CPO management system 2100.

Figure 25b illustrates the manner in which the RMS 2500 utilizes a number of databases and other tools in implementing a conventional pricing and allocation process and the CPO rules generation process 3900. The particular format and content of the illustrative databases shown in Figure 25b are discussed in detail below in conjunction with Figures 33 through 35. It is noted that the conventional pricing and allocation process and the CPO rules generation process 3900 may be executed by the RMS 2500 initially when a flight is first added to the flight schedule, and then periodically to reallocate and price available inventory in response to demand and external events.

Thus, when a flight is first added to the flight schedule of an airline 2120, a record of the flight is preferably created by the airline reservation system 2150 in the flight schedule database 2800 with the appropriate itinerary information. In addition, the RMS 2500 will perform a conventional pricing and allocation process in conjunction with the CPO rules generation process 3900, shown in Figure 39, to initially populate the respective fields of the pricing and restrictions database 3300, seat allocation database 3400, and forecast and demand analysis database 3500 for the flight, as shown in Figure 25b.

Generally, during the initial pricing and allocation process for a given flight, the RMS 2500 attempts to maximize revenue by establishing a plurality of fare classes and allocating the number of seats and price assigned to each fare class. The initial seat allocation and pricing information is stored in the seat allocation database 3400 and the pricing and restrictions database 3300, respectively. The initial price for

each fare class and the forecasted demand is preferably stored in the forecast and demand analysis database 3500. In one embodiment, a separate fare class can be established by the RMS 2500 for selling tickets to CPO customers. Since tickets to CPO customers are generally sold at a discount, the RMS 2500 preferably only initially allocates seats to the CPO fare class which are forecasted to be empty or unlikely to be sold when the flight actually departs. As is well known, an airline can utilize a conventional RMS 2500 to predict, based on available historical data, whether or not there will be empty seats on a given flight.

As shown in Figure 25b, the airline reservation system (ARS) 2150 will access the established pricing and restrictions database 3300 and seat allocation database 3400 to perform itinerary queries. In addition, as tickets are sold by the airline 2120, the ARS 2150 will preferably decrement the available inventory in the seat allocation database 3400. In this manner, the seat allocation database 3400 maintains an up-to-date representation of the available inventory on each flight.

The RMS 2500 will continue to monitor the actual demand 2560 within each fare class relative to forecasted demand 2570, as illustrated by Figure 25c, dynamically reevaluating the inventory allocation and pricing of each fare class for a given flight in order to minimize the unanticipated excess inventory delta 2580. The RMS 2500 monitors current actual demand information by retrieving detailed inventory data from the seat allocation database 3400 or summary information from the forecast and demand analysis database 3500. In addition, the RMS 2500 will utilize the historical demand information stored in the forecast and demand analysis database 3500 for prior periods, which essentially provides a demand curve for each selling price of a given fare class on each flight. For example, when allocating and pricing inventory for a given flight, the RMS 2500 may analyze demand trends for similar flights from previous relevant time periods, in a known manner. It is also noted that conventional RMSs typically respond to competitive forces and other external events, such as price wars or increased demand due to a large event, such as the Olympics, as shown in Figure 25b.

According to a feature of the present invention, an airline 2120 can correct for forecasting errors, if necessary, or other competitive forces which have produced unanticipated excess capacity 2580, by releasing tickets for sale to CPO

customers. Due to the confidential nature of the CPO rules, and the discouraged use of CPO tickets by full-fare business travelers, the airlines 2120,2130 can sell such excess capacity at a discount, without undermining its existing published fare structure. Thus, in a preferred embodiment, the RMS 2500 will periodically execute the CPO rule generation process 3900, discussed below in conjunction with Figure 39, to generate CPO rules that encourage the sale of tickets to CPO customers.

DATABASES Figure 26 illustrates an exemplary customer database 2600 that preferably stores information on each customer of the CPO management system 2100, including biographical information and billing information, such as a credit card number. The customer database 2600 maintains a plurality of records, such as records 2605-2615, each associated with a different customer. For each customer name listed in field 2640, the customer database 2600 includes the customer's address in field 2645 and credit card number in field 2655. In addition, the customer account database 2600 preferably includes an identification (ID) number in field 2660. The ID number stored in field 2660 may be utilized, for example, to index a historical database (not shown) of previous ticket purchases and CPOs associated with the customer.

Figure 27 illustrates an exemplary airline database 2700 which preferably stores information on each airline which is registered with the CPO management system 2100 to sell airline tickets to CPO customers, including address and contact information. The airline database 2700 maintains a plurality of records, such as records 2705-2715, each associated with a different airline. For each airline name listed in field 2740, the airline database 2700 includes address and contact information in fields 2745 and 2750, respectively. The contact information may comprise, for example, the name of an individual employee of the airline 2120 and a corresponding telephone number, web page URL, bulletin board address, pager number, telephone number, electronic mail address, voice mail address or facsimile number.

In addition, in an embodiment where the CPO rules of a given airline are stored in an encrypted format, the cryptographic key of the associated airline is preferably stored in field 2755 of the airline database 2700. Finally, the airline database 2700 preferably stores an indication in field 2760 of the percentage of CPOs which have been offered to each airline which have actually been accepted by the respective airline.

In this manner, the CPO management system 2100 can offer a particular CPO to airlines in a sequence that is ranked in accordance with the CPO acceptance rate, as discussed further below in conjunction with Figure 36b. In alternate embodiments, the airline database 2700 can incorporate fields to facilitate the processing of CPOs in accordance with sequences based on (i) the amount of inventory made available by each airline for sale to CPO customers, (ii) priorities negotiated by each airline, such as an airline priority over certain routes, or (iii) the highest commission rates paid by the airlines to the CPO management system 2100.

Figure 28 illustrates an exemplary flight schedule database 2800 that preferably stores specific flight information for each O & D Pair, as well as connection information. The flight schedule database 2800 maintains a plurality of records, such as records 2805-2815, each associated with a different flight. For each O & D Pair listed in fields 2840 and 2845, the flight schedule database 2800 includes the date of each flight in field 2850, as well as the times of departure and arrival of the respective flight in fields 2855 and 2860. The airline and flight number associated with each flight are preferably indicated in fields 2865 and 2870, respectively, and any required connections are indicated in field 2875.

Figures 29a and 29b illustrate an exemplary CPO database 2900 which preferably contains a record of each CPO being processed by the CPO management system 2100, including the terms of the CPO and the associated status. The CPO database 2900 maintains a plurality of records, such as records 2905 and 2910, each associated with a different CPO being processed by the system 2100. For each CPO identified by CPO number in field 2920, the CPO database 2900 includes the date the CPO was received in field 2925, and an identification (ID) number for the travel agent, if any, associated with the CPO in field 2930. It is noted that the travel agent ID number stored in field 2930 may be utilized, for example, to index a historical database (not shown) of previous ticket purchases and CPOs associated with the travel agent.

In addition, the CPO database 2900 identifies the customer by name in field 2935, and by identification number in field 2940 and identifies any companion passengers in field 2945. The ID number stored in field 2945 is preferably utilized to cross-reference the corresponding information stored for the customer in the customer database 2600.

The parameters of the customer's itinerary and other pertinent restrictions are stored in fields 2950 through 2995 of the CPO database 2900. Specifically, the origin and destination cities are identified in fields 2950 and 2955, respectively, and any connection restrictions specified by the customer 2110 are recorded in field 2960. The dates of the customer's departure and return are stored in fields 2965 and 2970, respectively. In an alternate embodiment (not shown), the CPO database 2900 could also permit the customer 2110 to specify particular time-of-day (range) restrictions for the departure and return flights.

The CPO database 2900 preferably stores an indication of the total number of passengers traveling together in field 2975, and sets forth the price the customer is willing to pay per ticket in field 2980. Any other miscellaneous restrictions specified by the customer will be recorded in field 2985, such as preferred airline (s), flights, or seat assignments. Field 2990 records the current status of the respective CPO, such as pending, accepted, rejected or expired. Finally, if the CPO ultimately results in a ticket being booked for the customer, the passenger name record number (PNR) associated with the ticket is stored in field 2995. Generally, a PNR is a record stored by the CRS 2400 containing information for each ticketed passenger, including: record number, passenger name (s), address for ticketing, billing information, such as credit card number, carrier (s) and flight number (s) for all segments, seat assignments, inventory class, aircraft type, airline-issued authorization code for discounted fare, selling price, and additional comments.

As discussed further below, rather than reject a CPO, one or more airlines may issue a binding counteroffer to the CPO, which the customer 2110 may accept or reject. If a counteroffer is issued to a customer 2110, then a record of the counteroffer with any associated restrictions, is preferably created in the CPO database 2900. For example, if an airline 2120 issues a counteroffer to the CPO number 23456 stored in record 2905 of the CPO database 2900, then the status of the initial CPO is changed to"counter", and a further record (not shown) corresponding to the counteroffer may be stored in the CPO database 2900 under a modified CPO number indicating the counteroffer, such as CPO number 23456-CO1.

Figure 30a illustrates an exemplary secured airline rules database 3000 which preferably maintains the CPO rules for one or more airlines associated with a

particular secured airline server 2300. As previously indicated, the secured airline rules database 3000 may be stored in an encrypted format to maintain the integrity and confidentiality of the highly sensitive information included in the CPO rules. The secured airline rules database 3000 maintains a plurality of records, such as records 3002 and 3004, each associated with a different CPO rule. For each CPO rule identified by rule number in field 3010, the secured airline rules database 3000 includes the associated restrictions defined by the respective airline in fields 3012 through 3044.

According to a feature of the invention, the CPO rules that are processed by the CPO management system 2300 may be of varying complexity. The particular restrictions set forth in the illustrative secured airline rules database 3000 are representative of the principles of the invention only. An airline can incorporate a subset of such restrictions and/or incorporate additional restrictions, as would be apparent to a person of ordinary skill. For example, the CPO rules of an airline 2120 may also incorporate restrictions on the minimum number of nights associated with the itinerary, or require the customer 2110 to have a Saturday night stay.

For illustrative purposes, the secured airline rules database 3000 shown in Figure 30a, allows an airline to create CPO rules by specifying some or all of the following restrictions in fields 3012 through 3044: origin and destination cities, connection restrictions, flight numbers included or excluded, dates and times of departure, departure days of the week, dates and times of return, return days of the week, number of passengers traveling, length of haul, average yield per seat, minimum price per ticket, inventory restrictions or seat availability, and advance purchase requirements.

For example, record 3002, shown in Figure 30a, is associated with a CPO rule for a given airline which specifies that the airline will accept any CPO for travel from Newark, New Jersey (EWR) to Orlando, Florida (MCO) during the month of October, 1997, provided that (i) the customer travels on any flight departing on a Tuesday through Thursday, (ii) the tickets are booked within 21 days of departure, (iii) the price is at least $165 per ticket, (iv) K inventory is available on all flight segments of the customer's itinerary and (v) at least two (2) passengers are travelling together.

Similarly, record 3004, shown in Figure 30a, is associated with a CPO rule for a given airline which specifies that the airline will accept any CPO having a

price of at least $150, for two or more people traveling together between New York, NY (JFK) and Chicago, IL (ORD) during April or May, 1997 where Q or K inventory is available on any flight between 11 a. m. and 2 p. m., where the flight departs on a Tuesday and returns on a Monday through Thursday, and is booked between 7 and 21 days prior to travel and can be routed through the airline's Cleveland, OH or Pittsburgh, PA hubs.

In an alternate or supplemental embodiment, the secured airline rules database 3000 can be implemented using a pair of inventory and pricing databases 3050, 3075, illustrated in Figures 30b and 30c, respectively. In this embodiment, the CPO rules stored in the inventory database 3050 contain actual inventory on each flight that the airline has released for sale to CPO customers. The inventory database 3050 maintains a plurality of records, such as records 3052-3056, each associated with a different CPO rule and flight. For each CPO rule identified by rule number in field 3060, the inventory database 3050 includes an indication of the airline, flight number and dates in fields 3062 through 3066, respectively. In addition, the number of seats that may be sold by the CPO management system 2100 on each flight is indicated in field 3068. In a preferred embodiment, as inventory is sold by the CPO management system 2100, the available inventory recorded in the inventory database 3050 will be decremented.

The pricing database 3075, shown in Figure 30c, maintains a plurality of records, such as records 3080-3084, each associated with a different O & D Pair. For each O & D Pair identified in fields 3090 and 3092, respectively, the pricing database 3075 includes an indication of the airline, dates and minimum price in fields 3088,3093 and 3096, respectively.

Thus, in such an alternate or supplemental embodiment, prior to accessing the inventory database 3050, the CPO management system 2100 will preferably query the CRS 2400 to identify possible flights which satisfy the customer's itinerary restrictions. Thereafter, the CPO management system 2100 will access the inventory database 3050 to determine if the airline has released any inventory on such identified flights to the CPO management system 2100 for sale to CPO customers. In one embodiment, the list of identified flights from the CRS 2400 can be sequenced to optimize customer preferences, and the inventory database 3050 can be searched in the

order of the sequenced list of flights, until available inventory is identified. Finally, if any available inventory satisfying the customer's itinerary is identified, then the CPO management system 2100 will access the pricing database 3075 shown in Figure 30c, to determine if the price specified by the customer exceeds the minimum price defined by the airline, as set forth in field 3096 of the pricing database 3075.

Figure 31 illustrates an exemplary counteroffer rules database 3100 which preferably stores a set of tolerances which may be utilized by the CPO management system 2100 to generate a counteroffer to a CPO if the CPO is within predefined tolerances of one or more restrictions associated with a given CPO rule.

The counteroffer rules database 3100 maintains a plurality of records, such as records 3105 and 3110, each associated with a different CPO rule. For each CPO rule identified by rule number in field 3120, the counteroffer rules database 3100 includes acceptable tolerances on the dates and times of departure and return in fields 3125 through 3140.

In addition, the counteroffer rules database 3100 includes tolerances on the number of passengers traveling, length of haul and yield in fields 3145 through 3155, respectively.

Finally, the counteroffer rules database 3100 records any permissible tolerances on the minimum price and advance purchase requirements in fields 3160 and 3165, respectively.

As shown in Figure 31, the counteroffer rules database 3100 includes counteroffer rule number 45687 in record 3105, corresponding to CPO rule number 45687 from Figure 30a. As illustrated in Figure 31, the CPO management system 2100 is authorized to generate a counteroffer on behalf of an airline 2120 associated with CPO rule number 45687, if a given CPO fails to meet one or more of the restrictions of CPO rule number 45687, but the restrictions which are not met are within the predefined tolerances set forth in the counteroffer rules database 3100. For example, if a given CPO includes a customer-defined price of $140.00, but all other airline-defined restrictions of CPO rule number 45687 are met, a counteroffer should be generated containing a price of $150.00 since the price variation is within ten percent (10%) of the minimum price associated with CPO rule number 45687, as authorized by counteroffer rule number 45687.

Figure 32 illustrates an exemplary secured airline audit database 3200 which preferably maintains an audit trail for each CPO which is processed by the CPO

management system 2100. The secured airline audit database 3200 maintains a plurality of records, such as records 3205-3215, each associated with a different CPO that has been processed by the CPO management system 2100. For each CPO identified by CPO number in field 3220, the secured airline audit database 3200 includes the response of the respective airline to the CPO in field 3225, and the date and time of the CPO in fields 3230 and 3235, respectively. In addition, if a ticket is booked for the customer 2110 on any airline, then the secured airline audit database 3200 preferably stores the passenger name record (PNR) number associated with the ticket in field 3240 and an indication of whether or not the ticket was booked on the respective airline in field 3245. In a preferred embodiment, the entry in field 3245 indicates whether the ticket was booked (a) on the respective airline associated with the database, (b) with another airline or (c) if no ticket was issued at all. In this manner, the CPO management system 2100 can establish that a ticket was actually booked for each CPO which was accepted by at least one airline.

Figure 33 illustrates an exemplary pricing and restrictions database 3300 which maintains pricing information and related restrictions for each flight offered by the airlines 2120,2130, as established and updated by the RMS 2500. The pricing and restrictions database 3300 includes a plurality of records, such as records 3305-3315, each associated with a different flight. For each flight identified by flight number in field 3325, the pricing and restrictions database 3300 includes the date of the flight in field 3330 and the respective price and restrictions associated with each inventory class in fields 3335 through 3350.

Figure 34 illustrates an exemplary seat allocation database 3400 which maintains available inventory information for each fare class on a given flight offered by the airlines 2120,2130, as allocated and updated by the RMS 2500. In addition, as inventory is sold by an airline, the airline's ARS 2150 will preferably decrement the available inventory recorded in the seat allocation database 3400. The seat allocation database 3400 includes a plurality of records, such as records 3405-3420, each associated with a different flight. For each flight identified by flight number in field 3425, the seat allocation database 3400 includes the departure date of the flight in field 3430 and the respective inventory available in each inventory class in fields 3435 through 3440. In addition, the seat allocation database 3400 preferably includes an

indication of the total number of seats booked on the flight in field 3445 and total capacity available on the flight in field 3450.

Figure 35 illustrates an exemplary forecast and demand analysis database 3500, which records each selling price for each fare class for a given flight, and the forecasted demand at each selling price as established by the RMS 2500. As previously indicated, when a flight is first added to the flight schedule of an airline 2120, a record of the initial price for each fare class and the forecasted demand is preferably created in the forecast and demand analysis database 3500. In addition, new records are preferably created for each new selling price that is established for each fare class by the RMS 2500, as part of the dynamic inventory reallocation process.

The forecast and demand analysis database 3500 includes a plurality of records, such as records 3505-3525, each associated with a different selling price for a given fare class on a given flight. For each flight number identified in field 3530, the forecast and demand analysis database 3500 includes the departure date, and origin and destination cities in fields 3535 through 3545, respectively, and the corresponding offered prices and fare classes in fields 3550 and 3555, respectively. Finally, the forecast and demand analysis database 3500 preferably records the actual quantity of tickets sold by the airline at each offered price for each fare class in field 3560 and the corresponding forecasted quantity in field 3565. The actual quantity of tickets sold may be recorded in field 3560 in real-time as tickets are actually sold or by means of batch processing on a periodic basis.

PROCESSES As discussed above, the CPO management central server 2200 preferably executes a CPO management process 3600, shown in Figures 36a through 36c, to receive each CPO from a customer 2110 and to compare the CPO against the rules of each airline in order to determine whether to accept, reject or counter the CPO on behalf of an airline. As illustrated in Figure 36a, the CPO management process 3600 begins the processes embodying the principles of the present invention during step 3604, when a customer or travel agent accesses the CPO management system 2100.

Thereafter, during step 3608, the CPO management central server 2200 will receive the customer information, itinerary, price and other restrictions from the customer 2110 which are required to populate the customer database 2600, if required

for a new customer, and the CPO database 2900. A record of the CPO is preferably created in the CPO database 2900 with the received information during step 3612, and with the status field set to"pending." Appropriate legal language is preferably displayed or read to the customer 2110 during step 3616, and the CPO management system 2100 will wait for an acknowledgment from the customer 2110 to form a binding conditional purchase offer (CPO). The price is extracted from field 2980 of the CPO database 2900 and the appropriate customer information, including credit card number, is extracted from the customer database 2600 during step 3620. Thereafter, the merchant ID associated with the CPO management system 2100, together with an appropriate billing descriptor, the total purchase amount (preferably equal to the price specified by the customer 2110) and the credit card information, are transmitted to the credit card issuer during step 3624 for pre-authorization.

A test is then preferably performed during step 3628 to determine if an authorization code has been received from the credit card issuer. If it is determined during step 3628 that the credit card issuer has not authorized the purchase amount, then another credit card is preferably requested from the customer 2110 during step 3632 and program control returns to step 3624 to continue processing in the manner described above.

If, however, it is determined during step 3628 that the credit card issuer has authorized the purchase amount, then the CPO is accepted for processing during step 3636 and program control continues to step 3640 (Figure 36b). The CPO management process 3600 preferably executes the evaluation process 3700, discussed below in conjunction with Figure 37, for each airline during step 3640. The CPO record created during step 3612 is passed to the evaluation process 3700 for comparison against the CPO rules of one airline, such as the airline 2120, to generate a response for the airline to the given CPO. As previously indicated, the airline's response to a CPO may be to accept, reject or counter the CPO. As discussed further below, the evaluation process 3700 will return the airline's response to the CPO, as well as a flight number if the CPO is accepted or countered by the airline.

In an alternate embodiment, the evaluation process 3700 can be performed for each airline in a predefined sequence until one airline accepts the CPO.

For example, the evaluation process 3700 can be performed in sequence based upon (i) the amount of inventory made available by each airline for sale to CPO customers, (ii) the CPO acceptance rate of each airline, as recorded in the airline database 3700, (iii) priorities negotiated by each airline, such as an airline priority over certain routes, or (iv) the highest commission rates paid by the airlines to the CPO management system 2100. In this manner, the sequence can be determined by factors that incent participation by the airlines, and/or by factors that optimize revenue to the CPO management system 2100. It is noted that in the preferred embodiment, the customer 2110 will pay the price defined by the customer if the CPO is accepted by an airline, regardless of the minimum price the airline would be willing to accept or whatever sequencing criteria is utilized by the CPO management system 2100 to process the CPO.

As shown in Figure 36b, a test is preferably performed during step 3644 to determine if the CPO was accepted by at least one airline. If it is determined during step 3644 that the CPO was accepted by at least one airline then a further test is preferably performed during step 3648 to determine if the CPO was accepted by more than one airline. If it is determined during step 3648 that the CPO was not accepted by more than one airline then program control proceeds directly to step 3672 (Figure 36c) to book the ticket.

If, however, it is determined during step 3648 that the CPO was accepted by more than one airline, then a tie breaker algorithm is preferably executed during step 3652 to determine which airline acceptance to utilize. For example, the tie breaker algorithm can select an airline offering an itinerary which maximizes the convenience to the customer 2110, maximizes the profit to the CPO management system 2100 or optimizes the inventory available for sale by the CPO management system 2100. It is noted that in the alternate embodiment, where the evaluation process 3700 is performed for each airlines in a predefined sequence until one airline accepts the CPO, a tie breaker algorithm will not be required. In a further alternate embodiment, the customer 2110 may select for himself which airline acceptance to utilize. Thereafter, program control proceeds to step 3672 (Figure 36c) to book the ticket.

In order to book the ticket, the information required to create a passenger name record (PNR) is extracted from the customer database 2600, the CPO database

2900 and the inventory and flight information received from the evaluation process 3700 or CRS 2400. As previously indicated, a PNR generally includes the following parameters: record number, passenger name (s), address for ticketing, billing information, such as credit card number, flight number (s) for all segments, carrier (s), seat assignments, inventory class, aircraft type, airline-issued authorization code for discounted fare, selling price, and additional comments.

Thereafter, during step 3674, the PNR is transmitted to the airline reservation system 2150 of the airline upon which the ticket will be booked or the CRS 2400 to establish a reservation. The CPO management process 3600 will then transmit the merchant ID associated with the CPO management system 2100, together with an appropriate billing descriptor, the total purchase amount (preferably equal to the price specified by the customer 2110) and the credit card information, to the credit card issuer during step 3678 for payment.

The record of the CPO in the CPO database 2900 is updated during step 3682 with the assigned PNR number and the status field is changed to"accepted." Finally, an audit process 3800, discussed below in conjunction with Figure 38, is executed by the CPO'management process 3600 during step 3686 for each airline to maintain an audit trail for each CPO which is processed by the CPO management system 2100. As previously indicated, the audit process 3800 will create an entry in the secured airline audit database 3200 which can be utilized to establish that a ticket was actually booked by the CPO management system 2100 for each CPO which was accepted by at least one airline.

If, however, it was determined during step 3644 (Figure 36b) that the CPO was not accepted by at least one airline, then a further test is performed during step 3656 to determine if at least one airline provided a counteroffer to the CPO. If it is determined during step 3656 that at least one airline did provide a counteroffer to the CPO, then the status of the initial CPO is changed to"counter", and a record of the counteroffer is preferably created in the CPO database 2900 during step 3660, for example using the original CPO number with a"-CO"extension. Thereafter, the counteroffer (s) are transmitted to the customer 2110 during step 3664. In an alternate embodiment, if the CPO is within predefined tolerances, rather than receiving one or more counteroffers, the customer 2110 can be instructed to resubmit the CPO at a later

time, or the CPO management system 2100 can periodically reexecute the CPO until the CPO is accepted or until the CPO expires. It is noted that in view of the dynamic nature of the CPO rules, a CPO that is initially rejected may be subsequently accepted by one or more airlines.

A test is then preferably performed during step 3668 to determine if the customer 2110 accepted one of the counteroffer (s). If it is determined during step 3668 that the customer 2110 did accept a counteroffer, then program control proceeds to step 3672 (Figure 36c) to book the ticket, in the manner described above. If, however, it is determined during step 3668 that the customer 2110 did not accept a counteroffer, then program control proceeds to step 3696 (Figure 36c), where the CPO management process 3600 will transmit the customer's rejection of the counteroffer to the airline (s) making the counteroffer. Thereafter, during step 3698, the CPO management process 3600 will update the status of the counteroffer associated with the CPO in the CPO database 2900 to"rejected."Program control proceeds to step 3686 in the manner described above and then terminates during step 3699.

If, however, it was determined during step 3656 (Figure 36b) that no airlines provided a counteroffer to the CPO, then program control proceeds to step 3690 (Figure 36c), where the CPO management process 3600 will transmit the rejection of the CPO to the customer 2110. Thereafter, the status of the CPO in the CPO database 2900 is updated to"rejected"during step 3694. Program control proceeds to step 3686 in the manner described above and then terminates during step 3699.

As discussed above, the CPO management process 3600 executes an evaluation process 3700, during step 3640. An exemplary evaluation process 3700 is shown in Figures 37a and 37b. In one embodiment, the evaluation process 3700 is preferably customized for each airline, so that each evaluation process 3700 receives the CPO record from the CPO management process 3600 in a standard format for comparison against the rules of the associated airline, such as the airline 2120, and returns a standard response of the airline to the CPO, such as accept, reject or counter.

In addition, if the response of the airline is to accept or counter the CPO, the evaluation process 3700 preferably also returns the selected flight number.

As shown in Figure 37a, the evaluation process 3700 initially extracts the O & D Pair from the CPO record during step 3705 and thereafter identifies all CPO

rules in the secured airline rules database 3000 which are pertinent to the extracted O & D Pair during step 3710. The customer defined restrictions from fields 2960 through 2995 of the CPO record are then compared to the corresponding airline defined restrictions from fields 3016 through 3044 of the secured airline rules database 3000 during step 3715, for each CPO rule identified during the previous step.

Thereafter, a test is performed during step 3720 to determine if the CPO satisfies at least one airline rule. For example, CPO number 23452, stored in record 2910 of the CPO database 2900 (Figures 29a and 29b), defines an O & D Pair of New York (JFK) to Chicago (ORD). Thus, the evaluation process 3700 will access the secured airline rules database 3000 and identify all CPO rules for this O & D Pair. In the illustrative secured airline rules database 3000 shown in Figure 30a, CPO rule number 23452 is identified as the only rule pertinent to this O & D Pair. Thereafter, each of the customer defined restrictions from fields 2960 through 2995 of the CPO number 23452 are compared to the corresponding airline defined restrictions from fields 3016 through 3044 of CPO rule number 23452. Since the customer is willing to make one stop (field 2960), the airline requirement of routing through Cleveland or Pittsburgh (field 3016) can be satisfied. In addition, the customer's dates of departure and return requirements (fields 2965 and 2970) satisfy the airline's dates, times and day of week requirements for both the departure and return legs of the trip (fields 3020 through 3032). In addition, the number of passengers traveling satisfies the airline requirement set forth in field 3034 and the customer's price (field 2980) exceeds the airline's defined minimum price (field 3040). Thus, CPO number 23452 will be accepted by the airline associated with CPO rule number 45687, provided that Q or K inventory is available (field 3042) and the CPO is being processed between 7 and 21 days prior to flight (field 3044).

In one embodiment, the CPO management system 2100 allows the airlines 2120,2130 to specify CPO rules in a format that accepts a given CPO, conditioned upon the CPO management system 2100 finding inventory available that meets the requirements of the airline, as set forth in the CPO rule, and the requirements of the customer 2110, as set forth in the CPO itself. For example, CPO rule number 23452, shown in Figure 30a, is conditioned upon Q or K inventory being available.

Thus, if it is determined during step 3720 that the CPO satisfies at least one airline rule, then a further test is preferably performed during step 3725 to determine if any of the satisfied rules are conditioned on inventory being available.

If it is determined during step 3725 that none of the satisfied rules are conditioned on inventory being available, then program control proceeds directly to step 3735, discussed below. If, however, it is determined during step 3725 that one or more satisfied rules are conditioned on inventory being available, then the CRS or ARS is accessed during step 3730 to identify flights, if any, with seats available and meeting the appropriate restrictions of both the satisfied CPO rule and the CPO.

Thereafter, a test is performed during step 3735 to determine if more than one flight satisfying the CPO has been identified. If it is determined during step 3735 that only one satisfactory flight has been identified, then program control proceeds directly to step 3745 (Figure 37b), discussed below.

If, however, it is determined during step 3735 that more than one satisfactory flight has been identified, then one flight is selected during step 3740 (Figure 37b) which most closely matches the customer preferences set forth in the CPO or maximizes the convenience for the customer. Alternatively, each airline 2120 can define its own criteria for the CPO management system 2100 to utilize to select a single flight. Thereafter, the response will be set to"accept"during step 3745, and program control will return to the CPO management process 3600 during step 3770 with the defined response and selected flight number.

If, however, it was determined during step 3720 (Figure 37a) that the CPO does not satisfy at least one airline rule, then program control proceeds to step 3750 (Figure 37b), where a further test is performed to determine if the CPO is within tolerances specified by the airline for generating a counteroffer. As previously indicated, the counteroffer rules database 3100 is preferably stored by each secured airline server 2300 to maintain a set of tolerances which may be utilized by the CPO management system 2100 to generate a counteroffer to a CPO on behalf of an airline, if the CPO is within predefined tolerances of one or more restrictions associated with a given CPO rule.

Thus, if it is determined during step 3750 that the CPO is within tolerances specified by the airline for generating a counteroffer, then a counteroffer is

generated during step 3760 with the appropriate modified terms, as retrieved from the counteroffer rules database 3100. Thereafter, the response will be set to"counter" during step 3765, and program control will return to the CPO management process 3600 during step 3770 with the defined response and selected flight number.

If, however, it is determined during step 3750 that the CPO is not within tolerances specified by the airline for generating a counteroffer, then the response will be set to"rejected"during step 3755, and program control will return to the CPO management process 3600 during step 3770 with the defined response and the selected flight number equal to null.

As previously indicated, the CPO management process 3600 preferably executes an audit process 3800 during step 3686 for each airline to maintain an audit trail for each CPO that is processed by the CPO management system 2100. An exemplary audit process 3800 is shown in Figure 38. The audit process 3800 will preferably create an entry in the secured airline audit database 3200 which can be utilized by the CPO management system 2100 to establish that a ticket was actually booked by the CPO management system 2100 for each CPO which was accepted by at least one airline. In this manner, the airlines 2120 can be assured that the risk of a customer 2110, another airline 2130 or a third party utilizing the CPO management system 2100 to obtain the underlying price flexibility of the airline 2120 is minimized.

As shown in Figure 38, the audit process 3800 will initially decrement the inventory in the secured airline rules database, if necessary, during step 3810. For example, inventory should be decremented only if the ticket was ultimately booked by the associated airline, and the CPO rule which was utilized to accept the CPO actually included inventory released by the airline for sale to CPO customers, as opposed to a CPO rule which was conditioned upon inventory being available.

Thereafter, the audit process 3800 preferably creates a record of the CPO in the secured airline audit database 3200, during step 3815, including the CPO number, the PNR associated with the ticket issued by the CPO management system 2100, if any, to the customer 2110, and an indication of whether the ticket, if any, was booked on the corresponding airline. Program control will then return to the CPO management process 3600 during step 3820.

An illustrative CPO rules generation process 3900, shown in Figure 39, is preferably executed by the RMS 2500 initially when a flight is first added to the flight schedule, and then periodically to reallocate and price available inventory in response to demand and external events. Thus, a test is initially performed during step 3905 to determine if the current inventory allocation by the RMS 2500 is the initial allocation for the flight being allocated. If it is determined during step 3905 that the current inventory allocation is the initial allocation for the flight being allocated, then a further test is performed during step 3910 to determine if the flight is predicted, using conventional methods, to likely depart with empty seats.

If it is determined during step 3910 that the flight is not likely to depart with empty seats, then program control will terminate during step 3985. If, however, it is determined during step 3910 that the flight is likely to depart with empty seats, then the CPO rule generation process 3900 will preferably allocate the empty seats to a special fare class for CPO customers during step 3915. Thereafter, an appropriate minimum fare and other restrictions for such tickets will be established during step 3920.

The pricing and restrictions database 3300, seat allocation database 3400, and forecast and demand analysis database 3500 for the flight will be updated during step 3925 with the newly established fare class, the allocated inventory and the initial price. Thereafter, the CPO rules generation process 3900 will preferably generate a CPO rule containing the allocated inventory, established minimum price and other restrictions during step 3930 and then transmit the generated CPO rule to the associated secured airline server 2300 during step 3935. Program control will then terminate during step 3985.

If, however, it was determined during step 3905 that the current inventory allocation is not the initial allocation for the flight being allocated, then program control proceeds to step 3950 to reallocate a previous allocation for one or more fare classes of a given flight in order to minimize the unanticipated excess inventory delta 2580. Thus, a test is performed during step 3950 to determine if the forecasted demand exceeds the actual demand by more than a predefined tolerance for any fare class. In one embodiment, the RMS can make this determination utilizing the summary information recorded in fields 3560 and 3565 of the forecast and demand

analysis database 3500. In addition, the RMS 2500 can generate the predefined tolerance utilized in step 3950 by analyzing historical demand information stored in the forecast and demand analysis database 3500 for prior periods.

If it is determined during step 3950 that the forecasted demand does not exceed the actual demand by more than a predefined tolerance for any fare class, then there is no need to reallocate the existing allocation and program control will terminate during step 3985. It is noted that if actual demand exceeds forecasted demand, the RMS 2500 can remove inventory that was previously allocated for sale to CPO customers.

If, however, it is determined during step 3950 that the forecasted demand does exceed the actual demand by more than a predefined tolerance for any fare class, then the RMS 2500 will preferably allocate the excess capacity, or a portion thereof, for sale to CPO customers during step 3955. Thereafter, an appropriate minimum fare and other restrictions for such tickets will be established during step 3960.

The pricing and restrictions database 3300, seat allocation database 3400, and forecast and demand analysis database 3500 for the flight will be updated during step 3965 with the reallocated inventory and the established price. Thereafter, the CPO rules generation process 3900 will generate a CPO rule containing the allocated inventory, established minimum price and other restrictions during step 3970 and then transmit the generated CPO rule to the associated secured airline server 2300 during step 3980. Program control will then terminate during step 3985.

CRUISE IMPLEMENTATION Although the CPO management system 2100 has been primarily illustrated herein as a system for selling airline tickets, the CPO management system 2100 could be utilized to sell cruise tickets as well, as would be apparent to a person of ordinary skill. In such an embodiment, each secured airline server 2300 would be associated with one or more cruise operators, as opposed to airlines, and each secured server 2300 stores, among other things, the CPO rules defined by any associated cruise operators, in a similar manner to the secured server 2300 described above in an airline implementation.

In addition, the revenue management system 2500 and the airline reservation system 2150 would be embodied as the revenue management system and reservation system, respectively, of each cruise operator. The cruise revenue

management system establishes pricing and inventory information and generates CPO rules in a similar manner to the revenue management system described above in an airline implementation. Similarly, the cruise reservation system performs itinerary queries and makes reservations with the respective cruise operator in a similar manner to the reservation system described above in an airline implementation.

Thus, the CPO management system 2100 receives CPOs from potential cruise travelers and evaluates the CPOs against a set of CPO rules provided by each of a plurality of cruise operators. An illustrative CPO database 4000 for a cruise implementation is illustrated in Figures 40a and 40b. The CPO database 4000 preferably stores a record of each CPO being processed by the CPO management system 2100, including the terms of the CPO and the associated status. The CPO database 4000 maintains a plurality of records, such as records 4005 and 4010, each associated with a different CPO being processed by the system 2100. For each CPO identified by CPO number in field 4020, the CPO database 4000 includes the date the CPO was received in field 4025, and an identification (ID) number for the travel agent, if any, associated with the CPO in field 4030. It is noted that the travel agent ID number stored in field 4030 may be utilized, for example, to index a historical database (not shown) of previous ticket purchases and CPOs associated with the travel agent.

In addition, the CPO database 4000 identifies the customer by name in field 4035, and by identification number in field 4040. Any companion passengers are identified in field 4045. The ID number stored in field 4040 is preferably utilized to cross-reference the corresponding information stored for the customer in the customer database 2600.

The parameters of the customer's itinerary and other pertinent restrictions are stored in fields 4050 through 4085 of the CPO database 4000. Specifically, the origin and destination ports are identified in fields 4050 and 4055, respectively, and any port restrictions specified by the customer 2110 are recorded in field 4060. The departure and return dates are stored in fields 4065 and 4070, respectively.

The CPO database 4000 preferably stores an indication of the total number of passengers traveling together in field 4075, and sets forth the price the customer is willing to pay per ticket in field 4080. Any other miscellaneous restrictions specified by the customer will be recorded in field 4085, such as preferred cruise

operator (s), berths, cabin assignments or meal times. Field 4090 records the current status of the respective CPO, such as pending, accepted, rejected or expired.

An illustrative secured rules database 4100 for a cruise implementation is shown in Figure 41 for maintaining the CPO rules for one or more cruise operators associated with the respective secured server 2300. The secured rules database 4100 may be stored in an encrypted format to maintain the integrity and confidentiality of the highly sensitive information included in the CPO rules. The secured rules database 4100 maintains a plurality of records, such as records 4102 and 4104, each associated with a different CPO rule. For each CPO rule identified by rule number in field 4110, the secured rules database 4100 includes the associated restrictions defined by the respective cruise operator in fields 4112 through 4144.

According to a feature of the invention, the CPO rules that are processed by the CPO management system 2100 may be of varying complexity. The particular restrictions set forth in the illustrative secured rules database 4100 are representative of the principles of the invention only. A cruise operator, airline or other seller can incorporate a subset of such restrictions and/or incorporate additional restrictions, as would be apparent to a person of ordinary skill.

For illustrative purposes, the secured rules database 4100 shown in Figure 41, allows a cruise operator to create CPO rules by specifying some or all of the following restrictions in fields 4112 through 4144: origin ports, cruise numbers (included or excluded), dates and times of departure, departure day of the week, dates and times of return, return day of the week, number of passengers traveling, length of haul, average yield per cabin, minimum price per ticket, inventory restrictions or cabin availability, and advance purchase requirements.

For example, record 4102, shown in Figure 41, is associated with a CPO rule for a given cruise operator which specifies that the cruise operator will accept any CPO for travel from St. Thomas during the month of October, 1997, provided that (i) the customer travels on any cruise departing and returning on a Tuesday through Thursday, (ii) the tickets are booked within two (2) months of departure, (iii) the yield is at least $1.20 per mile per cabin and the price is at least $529 per person, (iv) is not for luxury class travel and (v) at least two (2) passengers are travelling together.

POST-SELL FOR MULTIPLE BINDS As discussed above, if a CPO is accepted by more than one airline or cruise operator, then a tie breaker algorithm is preferably executed by the CPO management process 3600 during step 3652 to determine which airline acceptance to utilize. For example, the tie breaker algorithm can select a seller offering an itinerary which maximizes the convenience to the customer 2110, maximizes the profit to the CPO management system 2100, optimizes the inventory available for sale by the CPO management system 2100 or permits the customer 2110 to select for himself which airline or cruise operator acceptance to utilize. In an alternate implementation, if a CPO is accepted by more than one cruise operator, the CPO management system 2100 executes a post-sell multi-bind process 4200, shown in Figure 42, to permit each accepting seller to directly market to the customer 2110 and post-sell their product.

Thus, the customer 2110 still selects for himself which cruise operator acceptance to utilize, based on materials or incentives furnished by each seller. The customer 2110 is still bound by the CPO management system 2100, in accordance with the terms of the CPO. In other words, the customer 2110 is obligated to purchase the goods or services specified by the CPO, but the buyer must decide which cruise operator to utilize, based on materials provided to the customer 2110 directly by each accepting cruise operator.

For example, a customer 2110 may submit a CPO for a cruise during the month of March, 1998, anywhere in the Virgin Islands, in a grade A cabin with late dining, for $800.00. The CPO is provided to a plurality of cruise operators. Three cruise operators accept the CPO. The CPO management system 2100 then binds the customer 2110 on the credit card account identified with the offer, in accordance with the restrictions of the CPO. The CPO management system 2100 then provides a channel of communication between the customer 2110 and the accepting sellers, or provides the customer contact information to each accepting cruise operator, who each attempt to market their product in an attractive manner. The customer 2110 then selects one of the three accepting sellers. Thus, each cruise operator knows that they have a one-in-three chance of selling a cruise, at the price specified by the CPO. It is anticipated that cruise operators would aggressively market to such guaranteed purchasers, particularly in view of the high marginal profits associated with each cruise traveler.

It is noted that the channel of communication provided by the CPO management system 2100 between the customer 2110 and each accepting seller may be an interactive web-site or other electronic mechanism that permits each accepting seller to present the customer 2110 with detailed information about the cruise they are attempting to market. For example, the interactive web-site might include virtual representations of different aspects of the cruise package, such as the actual cruise ship and cabins, as well as the various ports that the cruise will visit and the available activities. In this manner, the buyer can explore the virtual cruise representation using known technology.

Figure 42 illustrates an illustrative post-sell multi-bind process 4200 which may be implemented by the CPO management central server of Figure 22 to permit each accepting seller to directly market to the customer 2110 in an attempt to post-sell their product. The post-sell multi-bind process 4200 is preferably executed by the CPO management process 3600 during step 3652, in lieu of the tie breaker algorithm, to determine which cruise operator acceptance to utilize. As illustrated in Figure 42, the post-sell multi-bind process 4200 begins during step 4210, by instructing the accepting cruise operators or other sellers to provide post-sell information for a designated customer 2110. The CPO management system 2100 then preferably receives the post-sell information from the accepting operators during step 4220 and transmits, or otherwise makes available, the received information to the customer 2110 during step 4230. Finally, the post-sell multi-bind process 4200 receives the decision of the customer 2110 regarding which operator to utilize, before program control returns to the CPO management process 3600 during step 4250.

In an alternate implementation, if a CPO is accepted by more than one cruise operator, then the CPO management system 2100 can bind each of the accepting sellers to the one CPO. The original buyer can be assigned one of the sellers in accordance with the tie breaker algorithm or the alternative post-sell multi-bind process 4200 disclosed herein. In this manner, the CPO management system 2100 can then resell the excess inventory to other buyers at or above the price associated with the initially accepted CPO.

EXCLUDED SELLER CPO EVALUATION As previously indicated, a CPO submitted by a customer 2110 can specify one or more preferred airline (s), cruise operators or other sellers, as applicable.

Thus, the CPO management system 2100 will provide the CPO to each specified seller to determine if one or more of the sellers are willing to accept the CPO. In a supplemental embodiment, the CPO management system 2100 preferably executes an excluded seller CPO evaluation process 4400, discussed below in conjunction with Figures 44a and 44b, to provide the CPO to the excluded sellers who may make counteroffers to the customer 2110 before one of the specified sellers accepts the CPO.

The excluded sellers may make counteroffers which are more favorable than the original terms of the CPO specified by the customer 2110, in an attempt to obtain the business. In this manner, the CPO management system 2100 can sell the rights to receive CPO information to excluded sellers or collect a larger percentage commission for any counteroffers which are accepted by a customer 2110.

For example, in the cruise industry, first time cruisers tend to develop a specific brand loyalty. Thus, when considering future cruises, such customers 2110 may submit a CPO to a very limited number of cruise operators. The CPO management system 2100 would submit the CPO to the specified cruise operators, in accordance with the terms of the CPO, and also submit the CPO to one or more excluded cruise operators. The CPO management system 2100 preferably utilizes an excluded operator counteroffer database 4300, shown in Figure 43, to maintain any counteroffers received from the excluded operators, before the CPO is accepted by one of the customer- specified operators.

An illustrative excluded operator counteroffer database 4300 for a cruise implementation is shown in Figure 43. The excluded operator counteroffer database 4300 maintains a plurality of records, such as records 4305 through 4315, each associated with a different counteroffer received from an excluded operator. For each counteroffer identified by number in field 4325, the excluded operator counteroffer database 4300 includes the corresponding CPO number, a customer identifier, the excluded operator, the terms of the counteroffer and the associated status in fields 4330 through 4350, respectively. For example, if a customer's CPO initially specified that the offer be submitted to Holland AmericaLine or Seaborn Cruise Lines, the CPO

management system 2100 might first submit the offer to Carnival, Princess and Royal Caribbean Cruise Lines. As shown in Figure 43, each of the excluded operators submit counteroffers of $600, $600 and $575, respectively. If none of the operators originally specified by the customer's CPO have not yet accepted, then the customer 2110 is provided the option of accepting one of the counteroffers. If the customer 2110 accepts a counteroffer, then the customer 2110 is bound to the terms of the counteroffer, and the original CPO is cancelled.

Figures 44a and 44b describe an illustrative excluded seller CPO evaluation process 4400. This process 4400 may be implemented by the CPO management central server of Figure 22 to provide the CPO information to the sellers excluded by the terms of the original offer. Those excluded sellers can then attempt to obtain the business, before one of the sellers specified by the terms of the CPO accepts the CPO. As discussed below, the excluded seller CPO evaluation process 4400 is preferably executed in conjunction with the CPO management process 3600. As illustrated in Figure 44a, the excluded seller CPO evaluation process 4400 begins during step 4405, upon receipt of a CPO from a customer 2110 and storage of the CPO in the CPO database 2900 or 4000. Thereafter, the CPO is evaluated during step 4410 to retrieve any operators specified by the customer 2110. The operator database is accessed during step 4415 to identify potential operators to which the CPO information can be provided.

A test is then performed during step 4420 to determine if there are one or more operators excluded from the terms of the CPO. If it is determined during step 4420 that no operators are excluded from the customer's CPO, then the CPO management process 3600 continues operation as described above. If, however, it is determined during step 4420 that one or more operators are excluded from the customer's CPO, then the CPO information is preferably transmitted to each specified and excluded operator during step 4430. It is noted that the CPO can be provided to excluded operators before specified operators, or concurrently.

Any counteroffers are then received from the excluded operators during step 4435, and stored in the excluded operator counteroffer database 4300 during step 4440. Each of the received counteroffers are then presented to the customer 2110 during step 4445. A test is then performed during step 4450 to determine if the customer

2110 accepts any of the counteroffers before the original CPO is accepted by any of the specified operators. If it is determined during step 4450 that the customer 2110 does not accept any of the counteroffers before the original CPO is accepted by any of the specified operators, then the CPO management process 3600 continues operation as described above.

If, however, it is determined during step 4450 that the customer 2110 has accepted a counteroffer before the original CPO is accepted by any of the specified operators, then the original CPO is terminated or cancelled and the status of the original CPO in the CPO database 2900,4000 is changed to"cancelled"during step 4460.

Thereafter, the status of the accepted counteroffer is changed to"accepted"and the status of the rejected counteroffers, if any, are changed to"rejected"in the excluded operator counteroffer database 4300 during step 4465. Finally, program control returns to the CPO management process 3600 and continues in the manner described above.

Although the post-sell multi-bind process 4200 and the excluded seller CPO evaluation process 4400 have been illustrated herein in a cruise embodiment, it is noted that the post-sell multi-bind process 4200 and the excluded seller CPO evaluation process 4400 are applicable in other industries as well, including the airline and other travel-related industries, the long distance telephone industry and the finance industry, as would be apparent to a person of ordinary skill.

PACKAGE CPO MANAGEMENT SYSTEM A further embodiment of the present invention, suitable for processing the sale of packages of goods and services, is discussed below in conjunction with Figures 45 through 57. Figure 45 shows a conditional purchase offer (CPO) management system for receiving and processing CPOs from one or more buyers, utilizing buyer interfaces 4800, for packages of component goods or services. In one embodiment, the package CPO management system 4500 deconstructs or breaks up an overall package CPO into component CPOs which are individually offered to sellers.

The package CPO management system 4500 processes the individual component CPOs associated with each package CPO to determine whether one or more sellers, utilizing seller interfaces 4801-4806, are willing to accept each of the individual components of a given package CPO. As discussed further below, if each of the individual component CPOs of a given package CPO are accepted by one or more sellers, the package CPO

management system 4500 binds the buyer, on behalf of each of the accepting sellers, to purchase the entire package. In this manner, a legally binding contract is formed.

As used herein, a package CPO is a binding offer containing one or more conditions submitted by a buyer for the purchase of a package of component goods or services or both, such as air travel, hotel and car rental, at a buyer-defined price. In the illustrative travel embodiment, the buyer-defined conditions for a package CPO would generally include overall price and itinerary parameters, such as the origin and destination cities; acceptable dates and times of travel; and desired class of service for each individual component. In addition, a buyer may optionally provide more detailed specifications for one or more individual components of an overall package CPO, such as whether connecting flights or stopovers are acceptable to the buyer for the airline portion of a travel-related package CPO, or a preferred provider for one or more individual component goods or services.

According to one feature of the present invention, the package CPO management system 4500 preferably deconstructs an overall package CPO into component CPOs which are individually offered to sellers. In an alternate embodiment, the package CPO management system 4500 provides the overall package CPO to each seller, with sellers being able to separately accept each component of the package CPO.

It is noted that the individual components of a package CPO can be for identical products. For example, a buyer can submit a purchase offer for six (6) general admission tickets to a particular sporting event. The package CPO management system 4500 can provide the purchase offer to sellers as an integral CPO for six tickets which may only be accepted by one seller. Alternatively, the package CPO management system 4500 can deconstruct the overall package CPO for six tickets into a number of component CPOs for one or more tickets which are individually offered to sellers. In one implementation, an overall package CPO for bulk goods can be deconstructed into component CPOs which are optimized into units which are most likely to be accepted.

In the above ticket example, the package CPO management system 4500 can decompose the request for six tickets into three component CPOs for two tickets each, assuming that most sellers are looking to sell pairs of tickets.

In one preferred embodiment, the package CPO management system 4500 reserves a margin off of the total offer price, before calculating the offer price for

each component CPO. The reserved margin amount may be determined based on the likelihood that all components of the overall package will be bound. In this manner, the margins mitigate the risk incurred by the package CPO management system 4500 as a result of a failure to bind all components of a package CPO.

As discussed further below in conjunction with Figure 56, the package CPO management system 4500 can utilize the reserved margin or portions thereof to increase the offer price of one or more component CPOs that remain unaccepted by sellers. For example, if a buyer were to submit an offer for a vacation package with a total cost not to exceed one thousand dollars ($1, 000.00), the package CPO management system 4500 may retain a one hundred dollar margin ($100), or ten percent (10%), to utilize if components of the desired package cannot be bound with the offer prices allocated from the initial $900. If, however, the package CPO management system 4500 is successful in binding the entire package with the initially allocated $900, then the package CPO management system 4500 can retain the $100 margin as profit, return the margin to the buyer, or place the unused margin in a fund to help bind the component CPOs of other package CPOs.

In order to calculate an offer price for each component CPO, the package CPO management system 4500 preferably initially determines the total market price of the package based on the market price of each individual component good or service within the package. The package CPO management system 4500 then calculates an offer price for each component CPO based on the total price offered by the buyer for the entire package, as adjusted by the reserved margin, if appropriate, multiplied by the ratio of the market price of the respective component CPO to the total market price of the package. For example, if a buyer submits an offer for a travel package consisting of air travel, hotel accommodations and a car rental, with a total cost for the package not to exceed one thousand dollars ($1,000.00), and with each component item having a market price of $420, $400 and $250, respectively, the package would have a total market price of $1070. If a $100 margin is initially retained by the package CPO management system 4500, the $900 adjusted package CPO price would be allocated to the individual component CPOs as follows based on the market prices: $360 (40%) for airline tickets, $333 (37%) for hotel accommodations and $207 (23%) for car rental.

The package CPO management system 4500 then processes the individual component CPOs to determine whether one or more sellers are willing to accept each of the individual component CPOs of the overall package CPO. If successful, the package CPO management system 4500 binds the buyer, on behalf of each of the accepting sellers, to purchase the entire package. As discussed further below, as each individual component CPO is accepted by a seller, the package CPO management system 4500 preferably enters a"pre-bind"agreement with the seller, whereby the component good or service is reserved for a predefined time period to permit the package CPO management system 4500 to complete the processing of the remaining active component CPOs. A seller who accepts a component CPO may permit the package CPO management system 4500, for example, a two-week period within which the package CPO management system 4500 must complete the package. It is noted that such a limited predefined"pre-bind"period protects sellers from reserving a product that cannot be later sold.

In an alternate implementation, the package CPO management system 4500 can enter binding agreements with each seller who elects to accept a component CPO. In this implementation, if parts of the package were bound, and others were not at the time of expiration, the package CPO management system 4500 could fund the difference to complete the unaccepted components of the package at or near market prices. In a further alternate implementation, the package CPO management system 4500 can provide component CPOs to sellers in a particular serial order, based on the likelihood that each component of the package will bind.

In addition, a seller can preferably be ensured that the package CPO management system 4500 could not continue shopping an accepted component CPO to the seller's competitors after a pre-bind is obtained by encrypting the initial pre-bind.

For example, a seller who pre-binds a given component CPO can encrypt their identifying characteristics before transmitting their acceptance to the package CPO management system 100 so that the package CPO management system 4500 can identify the seller's industry, such as airline, and authorization to accept offers, but could not identify the seller's specific identity until the entire package was complete.

Although the package CPO management system 4500 is illustrated herein as a system for processing travel-related package CPOs, the package CPO

management system 4500 could be utilized to process packages of any component goods or services or both, such as automobiles and related insurance, computers and related peripheral equipment, or bulk goods, as would be apparent to a person of ordinary skill.

PACKAGE CPO MANAGEMENT SYSTEM As shown in Figure 45, the package CPO management system 4500 preferably includes a central controller 4600 and one or more secured servers 4700, for communicating with one or more buyer or seller interfaces 4800-4806. The package CPO management system 4500 may provide a given component CPO to selected sellers based on the industry associated with the component CPO or other predefined screening criteria, as shown in Figure 45, so that sellers only obtain component CPOs that they may be interested in or are authorized to screen. Alternatively, the package CPO management system may provide all component CPOs to all sellers for screening.

According to one feature of the present invention, the package CPO management system 4500 preferably provides an optional agency feature that permits the package CPO management system 4500 to accept or reject a given component CPO on behalf of certain agency-based sellers who have delegated such authority to the package CPO management system 4500. Thus, the package CPO management system 4500 preferably (i) evaluates component CPOs on behalf of certain agency-based sellers who have delegated authority to the package CPO management system 4500 to accept or reject a given component CPO, and (ii) permits broadcast-based sellers to evaluate component CPOs independently. Thus, the package CPO management system 4500 can preferably provide one or more component CPOs of a received package CPO to each broadcast-based seller, for the seller to independently determine whether or not to accept a given component CPO. It is noted that the package CPO management system 4500 can provide a component CPO to each appropriate broadcast-based seller, for example, by means of a broadcast transmission, or by means of posting the component CPO, for example, on an electronic bulletin board accessible by each broadcast-based seller. Alternatively, the package CPO management system 4500 can evaluate one or more component CPOs of a received package CPO against a number of CPO rules defined by one or more agency-based sellers, to decide on behalf of an agency-based seller to accept or reject a given component CPO. Thus, the package CPO management

system 4500 can determine if one or more sellers accepts a given component CPO by providing the component CPO to each seller and receiving an acceptance or rejection, or by applying the component CPO to the CPO rules to render a decision to either accept, reject or counter a component CPO on behalf of a particular seller.

As discussed further below, a CPO rule is a set of restrictions defined by a given agency-based seller, such as seller 4804, to define a combination of such restrictions for which the seller is willing to accept a predefined minimum price. In one embodiment, the CPO rules are generated by the revenue management system, yield management system, or profit management system of the respective agency-based seller, or by any system that controls and manages inventory. For a more detailed discussion of CPO rules, the manner in which they are generated and related security issues, see U. S. Patent Application Serial No. 08/889,319, entitled Conditional Purchase Offer Management System, filed July 8,1997, the parent application to the present invention, which is incorporated by reference herein. Generally, the revenue management system, for example, will employ a CPO rules generation process to generate CPO rules by evaluating current inventory, pricing and revenue information, as well as historical patterns and external events, to forecast future travel.

For example, a CPO rule for a given agency-based airline can specify that the airline will accept any component CPO for travel between Newark, New Jersey (EWR) and Orlando, Florida (MCO) during the month of October, 1997, provided that (i) the customer travels between Tuesday and Thursday, (ii) the tickets are booked within 21 days of departure, (iii) the price is at least $165 per ticket, (iv) K-class inventory is available on all flight segments of the customer's itinerary, and (v) there are at least two (2) passengers travelling together.

As discussed further below in conjunction with Figure 47, each secured server 4700 may be associated with one or more agency-based sellers and each server 4700 stores, among other things, the CPO rules defined by any associated agency-based sellers, such as sellers 4804 and 4806. Each secured server 4700 may be remotely located from the central controller 4600, as shown in Figure 45, or may be integrated with the central controller 4600. In one remote embodiment, the secured server 4700 associated with each agency-based seller may be physically located at a processing facility secured by the particular seller, or at the physical location of a third party.

As discussed further below, each buyer contacts the package CPO management system 4500, for example, by means of telephone, facsimile, online access, e-mail, in-person contact or through an agent, and provides the package CPO management system 4500 with the terms of their package CPO. It is noted that each buyer may employ a general-purpose computer, such as the buyer interface 4800, discussed below in conjunction with Figure 48, for communicating with the package CPO management system 4500. The general-purpose computer of each buyer is preferably comprised of a processing unit, a modem, memory means and any software required to communicate with the package CPO management system 4500.

Once the terms of the package CPO have been received by the package CPO management system 4500, the central controller 4600 will execute a package CPO posting process 5500, discussed below in conjunction with Figures 55a through 55c, to deconstruct the overall package CPO into component CPOs, and thereafter (i) provide each component CPO to the appropriate broadcast-based sellers and (ii) evaluate each component CPO against the appropriate CPO rules of each appropriate agency-based seller. In addition, once the component CPOs have been posted, the package CPO management system 4500 will preferably periodically execute a package CPO monitoring process 5600, discussed further below in conjunction with Figures 56a through 56c, to determine if each component CPO of an overall package CPO is accepted by an appropriate seller. If each of the individual component CPOs of a given package CPO are accepted by one or more sellers, the package CPO management system 4500 notifies the buyer, on behalf of each of the accepting sellers, that he has been bound to purchase the entire package with the appropriate restrictions which meet the conditions defined by the buyer.

The package CPO management system 4500 and buyer and seller interfaces 4800-4806 (collectively, the"nodes") preferably transmit digitally encoded data and other information between one another. The communication links between the nodes preferably comprise a cable, fiber or wireless link on which electronic signals can propagate. For example, each node may be connected via an Internet connection using a public switched telephone network (PSTN), such as those provided by a local or regional telephone operating company. Alternatively, each node may be connected by

dedicated data lines, cellular, Personal Communication Systems ("PCS"), microwave, or satellite networks.

Figure 46 is a block diagram showing the architecture of an illustrative central controller 4600, The central controller 4600 preferably includes certain standard hardware components, such as a central processing unit (CPU) 4605, a random access memory (RAM) 4610, a read only memory (ROM) 4620, a clock 4625, a data storage device 4630, an operating system 4650, a payment processor 4660 and a network interface 4680. The CPU 4605 is preferably linked to each of the other listed elements, either by means of a shared data bus, or dedicated connections, as shown in Figure 46.

The CPU 4605 may be embodied as a single commercially available processor, such as Intel's Pentium 100 MHz P54C microprocessor, Motorola's 120 MHz PowerPC 604 microprocessor or Sun Microsystem's 166 MHz UltraSPARC-1 microprocessor. Alternatively, the CPU 4605 may be embodied as a number of such processors operating in parallel.

The ROM 4620 and/or data storage device 4630 are operable to store one or more instructions, discussed further below in conjunction with Figures 55 and 56, which the CPU 4605 is operable to retrieve, interpret and execute. The payment processor 4660 preferably implements known processes to accomplish the transfer of required payments, charges and debits, between the sellers and buyers, by means of a conventional electronic funds transfer (EFT) network. In particular, as discussed below in conjunction with Figure 56, the package CPO monitoring process 5600 preferably transmits the credit card information associated with a given buyer to the credit card issuer for payment, if a package is actually purchased by the buyer. The processing of such accounting transactions are preferably secured in a conventional manner, for example, using well-known cryptographic techniques.

The CPU 4605 preferably includes a control unit, an arithmetic logic unit (ALU), and a CPU local memory storage device, such as, for example, a stackable cache or a plurality of registers, in a known manner. The control unit is operable to retrieve instructions from the data storage device 4630 or ROM 4620. The ALU is operable to perform a plurality of operations needed to carry out instructions. The CPU local memory storage device is operable to provide high-speed storage used for storing temporary results and control information.

As discussed further below in conjunction with Figures 49 through 53, respectively, the data storage device 4630 includes a buyer database 4900, a seller database 5000, a package CPO database 5100, a component CPO database 5200 and a market price database 5300. The buyer database 4900 preferably stores information on each buyer of the package CPO management system 4500, including biographical information and billing information, such as a credit card number. The seller database 5000 preferably stores information on each seller which is registered with the package CPO management system 4500 to sell component goods or services to package CPO buyers, including identifier and name information. The package CPO database 5100 preferably contains a record of each package CPO being processed by the package CPO management system 4500, including an indication of the component CPOs within each package CPO and the associated status. The component CPO database 5200 preferably contains a record of each component CPO being processed by the package CPO management system 4500, including the terms of each component CPO and the associated status. Finally, the market price database 5300 preferably stores market price information for each component good or service processed by the package CPO management system 4500.

In addition, the data storage device 4630 includes a package CPO posting process 5500 and a package CPO monitoring process 5600, discussed further below in conjunction with Figures 55 and 56, respectively. Generally, the package CPO posting process 5500 deconstructs the package CPO into component goods or services, and thereafter (i) posts each component CPO to the appropriate broadcast-based sellers and (ii) evaluates each component CPO against the appropriate CPO rules of each agency- based seller. The package CPO monitoring process 5600 determines if each component CPO of a posted package CPO is accepted by an appropriate seller and, if accepted, provides buyer information to each accepting seller. In this manner, if each of the individual component CPOs of a given package CPO are accepted, the package CPO management system 4500 notifies the buyer, on behalf of each of the accepting sellers, that he has been bound to purchase the entire package.

The network interface 4680 connects the central controller 4600 to the buyer and sellers, for example, by means of an Internet connection using the public switched telephone network (PSTN). The network interface 4680 preferably includes

multiple communication channels for simultaneously establishing a plurality of connections.

Figure 47 is a block diagram showing the architecture of an illustrative secured server 4700. As previously indicated, the package CPO management system 4500 may utilize one or more secured servers 4700, each supporting one or more agency-based sellers 4804,4806. Each secured server 4700 preferably includes certain standard hardware components, such as a central processing unit (CPU) 4705, a random access memory (RAM) 4710, a read only memory (ROM) 4720, a clock 4725, a data storage device 4730, and a communications port 4740. Each of these components may be identical to those described above in conjunction with Figure 46.

As previously indicated, in one embodiment, the CPO rules may be stored in a secure database to maintain the integrity and confidentiality of the highly sensitive information included in each CPO rule. Thus, the secured server 4700 preferably uses a secure database, such as the products commercially available from Oracle, Informix or IBM.

As discussed further below in conjunction with Figure 54, the data storage device 4730 includes a secured seller rules database 5400. The secured seller rules database 5400 preferably maintains the CPO rules for the one or more agency- based sellers associated with the secured server 4700. As previously indicated, the secured seller rules database 5400 may be stored in an encrypted format to maintain the integrity and confidentiality of the highly sensitive information included in the CPO rules. In addition, the data storage device 4730 includes a component CPO rule evaluation process 5700, discussed further below in conjunction with Figure 57.

Generally, the component CPO rule evaluation process 5700 is a subroutine executed by the package CPO posting process 5500, which receives a component CPO and compares the CPO against the rules of one or more agency-based sellers to generate a response on behalf of the sellers to the given component CPO.

The secured server 4700 may optionally maintain an audit trail for each component CPO that is processed by the package CPO management system 4500. For a discussion of a suitable audit system, see the parent application to the present invention, incorporated by reference herein above.

The communications port 4740 connects the secured server 4700 to the central controller 4600. The communications port 4740 preferably includes multiple communication channels for simultaneously establishing a plurality of connections.

Figure 48 is a block diagram showing the architecture of an illustrative buyer or seller interface 4800-4806. The interface 4800 preferably includes certain standard hardware components, such as a central processing unit (CPU) 4808, a random access memory (RAM) 4810, a read only memory (ROM) 4820, a clock 4825, a data storage device 4830, and a communications port 4840. Each of these components may be identical to those described above in conjunction with Figure 46. In addition, the interface 4800 preferably includes a video monitor 4850 and related video driver 4860, and an input device 4870, such as a keyboard or mouse.

The data storage device 4830 preferably includes a message database 4880 for storing messages required by the respective buyer or seller interface 4800-4806 to communicate with the central controller 4600 of the package CPO management system 4500. The communications port 4840 connects the interface 4800 to the central controller 4600 or the secured server 4700, for broadcast-based and agency-based sellers, respectively.

Figure 49 illustrates an exemplary buyer database 4900 that preferably stores information on each buyer of the package CPO management system 4500, including biographical information and billing information, such as a credit card number. The buyer database 4900 maintains a plurality of records, such as records 4905-4915, each associated with a different buyer. For each buyer identifier in field 4920, the buyer database 4900 includes the corresponding buyer name and address in fields 4925 and 4930, respectively, and credit card number in field 4935. In addition, the buyer database 4900 preferably includes an indication of the CPOs associated with the buyer in field 4940, which may be package CPOs as described herein or general CPOs as described in the parent application to the present invention. The identifier stored in field 4920 may be utilized, for example, to index a historical database (not shown) of previous purchases and CPOs associated with the buyer.

Figure 50 illustrates an exemplary seller database 5000 which preferably stores information on each seller which is registered with the package CPO management system 4500 to sell component goods or services to package CPO buyers, including

identifier and name information. The seller database 5000 maintains a plurality of records, such as records 5005-5030, each associated with a different seller. For each seller identifier listed in field 5035, the seller database 5000 includes the corresponding seller name in field 5040. In addition, the seller database 5000 preferably records a tracking number in field 5045 for any CPOs associated with each seller. It is noted that the information recorded in field 5045 could be similarly recorded by including a seller ID field in the package CPO database 5100, discussed below.

Figure 51 illustrates a package CPO database 5100 which preferably contains a record of each package CPO being processed by the package CPO management system 4500, including an indication of the component CPOs within each package CPO and the associated status. The package CPO database 5100 maintains a plurality of records, such as records 5105-5110, each associated with a different package CPO. For each package CPO listed in field 5120, the package CPO database 5100 includes the status and original offer price in fields 5125 and 5130, respectively.

In addition, the package CPO database 5100 preferably records the margin factor, remaining margin, adjusted package CPO price and per-allocation-margin percentage in fields 5135 through 5150, respectively. The manner in which the margin variables are processed by the package CPO management system 4500 are discussed below in conjunction with Figure 56. The posting and expiration dates of the package CPO, as well as the total posting duration period and posting time required for each margin allocation are stored in fields 5155 through 5170, respectively. The individual component goods or services within each package CPO are optionally identified in field 5175, and the conditions and component numbers associated with each component are set forth in fields 5180 and 5185. It is noted that the information recorded in fields 5175 and 5180 could alternatively be retrieved from the component CPO database 5200 using the component CPO numbers recorded in field 5185. Finally, an identifier of the buyer associated with each package CPO is preferably recorded in field 5190.

Figure 52 illustrates an exemplary component CPO database 5200 which preferably contains a record for each component CPO being processed by the package CPO management system 4500, including the terms of the component CPO and the associated status. The component CPO database 5200 maintains a plurality of records, such as records 5205 through 5230, each associated with a different component CPO

being processed by the system 4500. For each component CPO identified by component CPO number in field 5240, the component CPO database 5200 includes the status or expiration date for pre-bound component CPOs in field 5245, as well as the corresponding subject, price and conditions associated with the component CPO in fields 5250 through 5260, respectively. Finally, an identifier of the buyer associated with each component CPO is preferably recorded in field 5265.

Figure 53 illustrates an exemplary market price database 5300 that preferably stores market price information for each component good or service processed by the package CPO management system 4500. As discussed further below in conjunction with Figure 55, the package CPO posting process 4500 preferably utilizes the market price information to allocate the overall package price to each component good or service. The market price database 5300 maintains a plurality of records, such as records 5305 through 5345, each associated with a different component good or service processed by the system 4500. For each component good or service identified in field 5360, the market price database 5300 identifies the available quality or service levels for each good or service in field 5365, as well as the corresponding market price set forth in field 5375, for each time period indicated in field 5370. It is noted that the market price for each service level of round trip airline travel is preferably recorded for each originating and destination city pair (O & D Pair).

As previously indicated, the secured server 4700 preferably maintains one or more secured seller rules databases 5400 to store the CPO rules for the one or more agency-based sellers associated with the secured server 4700. An example of a secured seller rules database 5400 is shown in Figure 54a for an agency-based airline and in Figure 54b for an agency-based hotel.

Figure 54a illustrates an exemplary secured airline rules database 5400 which preferably maintains the CPO rules for one or more agency-based airlines associated with a particular secured server 4700. As previously indicated, the secured airline rules database 5400 may be stored in an encrypted format to maintain the integrity and confidentiality of the highly sensitive information included in the CPO rules. The secured airline rules database 5400 maintains a plurality of records, such as records 5402 and 5404, each associated with a different CPO rule. For each CPO rule identified by rule number in field 5410, the secured airline rules database 5400 includes

the associated restrictions defined by the respective agency-based airline in fields 5412 through 5444.

Figure 54b illustrates an exemplary secured hotel rules database 5450 which preferably maintains the CPO rules for one or more agency-based hotels associated with a particular secured server 4700. As previously indicated, the secured hotel rules database 5450 may be stored in an encrypted format to maintain the integrity and confidentiality of the highly sensitive information included in the CPO rules. The secured hotel rules database 5450 maintains a plurality of records, such as records 5452 through 5456, each associated with a different CPO rule. For each CPO rule identified by rule number in field 5460, the secured hotel rules database 5450 identifies the applicable hotel sites in field 5465 and includes the associated restrictions defined by the respective agency-based hotel in fields 5470 through 5490.

As discussed above, the central controller 4600 preferably executes a package CPO posting process 5500, shown in Figures 55a through 55c, to deconstruct the package CPO into component goods or services, and thereafter (i) post each component CPO to the appropriate broadcast-based sellers and (ii) evaluate each component CPO against the appropriate CPO rules of each agency-based seller. As illustrated in Figure 55a, the package CPO posting process 5500 begins the processes embodying the principles of the present invention during step 5505, when a buyer submits a CPO for a package of component goods or services.

Thereafter, the central controller 4600 will receive the conditions associated with the package CPO from the buyer, including a description of each component good or service, and an identifier of a general purpose account, such as a credit or debit card account from which funds may be paid during step 5510, and then receive the price and expiration date for the package CPO from the buyer during step 5515. In this manner, the offer is guaranteed with a general purpose account, for example, using a line of credit on a credit card account. Appropriate legal language is preferably displayed or read to the buyer during step 5520 to form a binding package CPO. A package CPO number is generated during step 5525, and the package CPO information, including the buyer identifier, package CPO price and expiration date, and conditions for the component goods or services, is then entered into the package CPO database 5100 during step 5530.

As previously indicated, the package CPO management system 4500 preferably reserves a margin off of the total package offer price, before calculating the offer price for each component CPO. Thus, an appropriate margin is calculated during step 5535 by multiplying the package CPO price by the margin factor recorded in the package CPO database 5100. Thereafter, the calculated margin is recorded in the "remaining margin"field 5140 of the package CPO database 5100 during step 5540 (Figure 55b). The adjusted CPO price is then calculated by subtracting the calculated margin from the original total package offer price, which is then entered into the package CPO database 5100 during step 5545. The status of the package CPO is set to "active"in field 5125 of the package CPO database 5100 during step 5550.

The market price of each component good or service in the package CPO is retrieved during step 5555 from the market price database 5300. The market price of the overall package CPO is calculated during step 5560 by adding the market price of each individual component CPO in the overall package. The individual CPO prices for each component CPO are then calculated during step 5565, for example, by allocating the adjusted package CPO price, as calculated during step 5545, in accordance with the ratio of the market price of the respective component good or service to the total market price.

A CPO number is then generated for each component CPO during step 5570 and recorded in the"component CPO numbers"field of the package CPO database 5100 during step 5575 (Figure 55c). A new record is created in the component CPO database 5200 for each component CPO during step 5580, before each component CPO is provided to each broadcast-based seller and the component CPO rule evaluation process 5700 is executed for each agency-based seller during step 5590. Program control terminates during step 5595.

As discussed above, the central controller 4600 preferably executes a package CPO monitoring process 5600, shown in Figures 56a through 56c, to determine if each component CPO of a posted package CPO has been accepted by an appropriate seller and, if accepted, provides buyer information to each accepting seller. In this manner, if each of the individual component CPOs of a given package CPO are accepted, the package CPO management system 4500 notifies and binds the buyer, on behalf of each of the accepting sellers, to purchase the entire package. The package

CPO monitoring process 5600 may be periodically executed to determine the status of each component CPO, or executed continuously.

As illustrated in Figure 56a, the package CPO monitoring process 5600 begins the processes embodying the principles of the present invention during step 5605, by performing a test to determine if all of the component CPOs within a given package CPO have been pre-bound at currently posted prices. It is noted that in the illustrative embodiment, the first seller to accept a given component CPO is awarded the component CPO. For a discussion of other mechanisms for determining which seller among a plurality of accepting sellers should be awarded a component CPO, see the parent application to the present invention, incorporated by reference herein above. If it is determined during step 5605 that all of the component CPOs within a given package CPO have been pre-bound at currently posted prices, then buyer identification information, including the buyer's name, address and credit card account number, is retrieved from the buyer database 4900 during step 5650. Thereafter, the buyer identification number is transmitted to each seller who accepted a component CPO during step 5655. The package CPO monitoring process 5600 transmits the merchant identifier of the package CPO management system 4500, together with the buyer's credit card account number, a billing descriptor and the purchase amount for the package CPO to the credit card issuer for payment authorization during step 5660, via a conventional credit card authorization network.

The status field 5125 of the package CPO database 5100 is updated during step 5665 to indicate that the respective package CPO was completed, before program control terminates during step 5670.

If, however, it was determined during step 5605 that all of the component CPOs within a given package CPO have not been pre-bound at currently posted prices, then the expiration date of the package CPO is retrieved from field 5160 of the package CPO database 5100 during step 5610 (Figure 56b). A test is then performed during step 5615 to determine if the package CPO has expired. If it is determined during step 5615 that the package CPO has expired, without each component being pre-bound, then the package CPO monitoring process 5600 communicates (1) termination of any pre-bind agreements for component CPOs within the expired package CPO which were accepted by one or more sellers to the respective sellers during step 5635; and (11) expiration of

the package CPO to the respective buyer during step 5640. In an alternate embodiment, the buyer can be invited to resubmit a revised package CPO if the original package CPO is not accepted. In addition, the package CPO management system 4500 might attempt to compile a counteroffer for the buyer, based on acceptances of individual components received by the package CPO management system 4500. Thereafter, program control terminates during step 5645.

If, however, it is determined during step 5615 that the package CPO has not expired, then the package CPO monitoring process 5600 will adjust the status field 5125 of the package CPO database 5100 during step 5620 to indicate the percentage of the overall package CPO which is currently pre-bound, for example, by accessing the package CPO database 5100 to identify the number of components in the package CPO, and identifying the number of components which are currently pre-bound. Thereafter, the"total posting duration"parameter is retrieved from field 5165 of the package CPO database 5100 during step 5625, which is then multiplied by the"posting time required for each margin allocation"parameter set forth in field 5170.

A test is then performed during step 5630 to determine if the package CPO has been active for the posting time required to allocate additional margin to increase the price of each component CPO which has not yet been pre-bound. If it is determined during step 5630 that the package CPO has not been active for the posting time required to allocate additional margin, then program control returns to step 5605 (Figure 56a) and continues processing in the manner described above. If, however, it is determined during step 5630 that the package CPO has been active for the posting time required to allocate additional margin, then the percent composition of each remaining active component CPO is calculated during step 5675 (Figure 56c) relative to the total price of all remaining active component CPOs.

The"per allocation margin percentage"is then retrieved during step 5680 from field 5150 of the package CPO database 5100. The amount of margin to be allocated to remaining active component CPOs is then calculated during step 5682 by multiplying the retrieved"per allocation margin percentage"value by"remaining margin"value recorded in field 5140 of the package CPO database 5100. Thereafter, the allocable margin is applied to each remaining active component CPO in appropriate percentages during step 5684 by multiplying the price percentages of the remaining

active component CPOs (as determined during step 5675) by the calculated allocable margin amount.

For example, if one component of a three component package is initially pre-bound at the originally posted price, and the remaining two components are not bound within the posting time required to allocate additional margin, then the package CPO monitoring process 5600 preferably allocates part of the margin between the two remaining component CPOs. The amount allocated to each component CPO is preferably determined by their respective initially posted prices. Assume in the example discussed above, where a buyer submits an offer for a travel package consisting of air travel, hotel accommodations and a car rental, with a total cost for the package not to exceed one thousand dollars ($1,000.00), that the first component to prebind was the airline tickets at $360. Thus, the package CPO monitoring process 5600 will allocate a portion of the remaining margin to the offer prices for the hotel and car rental component CPOs. In a preferred embodiment, since the hotel component CPO accounts for 62% of the total remaining CPO prices ($333/ ($333 + $207)), the offer price of the hotel component CPO is increased by 62%, or $31, of the money taken from the margin ($50). Likewise, the car rental component CPO offer price would be increased by 38% or $19. If one or more components are again not bound for the posting time required to allocate additional margin, more of the margin is preferably allocated.

The"remaining margin"recorded in field 5140 is adjusted during step 5688 by subtracting the margin allocated in the previous step. Thereafter, during step 5690, the remaining active CPOs with the newly adjusted prices are provided to broadcast-based sellers and the component CPO rule evaluation process 5700 is executed for each appropriate agency-based seller. Finally, program control returns to step 5605 (Figure 56a) and continues processing in the manner described above, until all component CPOs are pre-bound, or until the package CPO expires. In this manner, the offer prices are increased with additional allocated margin for each component CPO that remains unaccepted for each time period required to allocate additional margin. As discussed above, the package CPO posting process 5500 and the package CPO monitoring process 5600 each execute a component CPO rule evaluation process, during steps 5590 and 5690, respectively, for agency-based sellers to compare the

component CPOs against the rules of one or more agency-based sellers to generate a response on behalf of the sellers to the given component CPO. An illustrative component CPO rule evaluation process 4700 is shown in Figure 57. In one embodiment, the component CPO rule evaluation process 5700 is customized for each agency-based seller, so that each evaluation process 5700 receives the component CPO record from the central controller 4600 in a standard format for comparison against the rules of the associated seller, and returns a standard response of the seller to the component CPO, such as"accept"or"reject." As shown in Figure 57, the component CPO rule evaluation process 5700 initially identifies all CPO rules in the secured seller rules database 5000 which are pertinent to the component CPO during step 5710. Thereafter, during step 5720, the buyer defined conditions from the component CPO record in the component CPO database 5200 are then compared to the corresponding seller defined restrictions from the secured seller rules database 5000 during step 5720, for each CPO rule identified during the previous step.

Thereafter, a test is performed during step 5730 to determine if the component CPO satisfies a CPO rule. If it is determined during step 5730 that the component CPO does not satisfy one CPO rule, then program control terminates during step 5770. If, however, it is determined during step 5730 that the component CPO does satisfy a CPO rule, then the component CPO number is retrieved from the component CPO database 5200 during step 5740, and then entered into the"CPO tracking number" field 5045 of the seller database 5000. The status of the component CPO in field 5245 of the component CPO database 5200 is updated to"pre-bind completed"during step 5760, before program control terminates during step 5770. In addition, a pre-bind expiration date can be added to field 5245, if mandated by the seller.

CPO MANAGEMENT SYSTEM FOR TELEPHONE CALLS A further embodiment of the present invention, suitable for processing purchase offers for one or more telephone calls, is discussed below in conjunction with Figures 58 through 66. Figures 58A and 58B show a conditional purchase offer (CPO) management system 5800 for receiving and processing CPOs for telephone calls from one or more calling parties, such as calling party 5810. The CPO management system 5800 processes the CPO to determine whether one or more long distance carriers, such

as interexchange carriers 5820-5824, are willing to accept a given CPO and complete a telephone call in accordance with restrictions defined by the calling party 5810. In the United States, for example, the interexchange carriers 5820-5824 may be AT&T, Sprint and MCI. As discussed further below, if an interexchange carrier 5820 accepts a given CPO, the CPO management system 5800 binds the calling party 5810 on behalf of the accepting interexchange carrier 5820, to form a legally binding contract.

As used herein, a CPO is a binding offer containing one or more conditions, submitted by a calling party 5810 for the completion of one or more telephone calls, typically at a price defined by the calling party. In this manner, a calling party 5810 can preferably submit a CPO for an individual telephone call, a package of calls to one or more called parties 5830, or for a contract to provide telephone service for a predefined period of time. In the illustrative embodiment, the conditions defined by the calling party 5810 may include the telephone number to be called, the maximum price, one or more preferred carriers, if any, as well as any time limitations, such as a particular time-of-day or minimum call duration. The maximum price may preferably be specified by the calling party 5810 in terms of a price for a fixed period of time, such as ten dollars ($10) for a twenty (20) minute telephone call, or in terms of a rate-per-minute, such as fourteen cents per minute ($0.14/minute).

CPO MANAGEMENT SYSTEM Figure 58A shows an illustrative network environment for interconnecting the CPO management system 5800 with one or more calling parties 5810 and one or more interexchange carriers 5820-5824 who may route a call to a desired called party 5830. According to a feature of the present invention, a calling party 5810, desiring to call a called party 5830, typically identified by a Plain Old Telephone Service (POTS) telephone number, may submit an offer to the CPO management system 5800 for a telephone call in accordance with restrictions defined by the calling party. In one preferred implementation, the calling party 5810 uses a telephone set 5900, shown in Figure 59, to dial the telephone number assigned to the CPO management system 5800, such as a toll-free telephone number, or"800 number," before dialing the telephone number of the called party 5830 to provide the CPO management system 5800 with the terms of the CPO. Alternatively, the calling party 5810 can initially contact the CPO management system 5800 by means of facsimile.

Once the calling party 5810 initially contacts the CPO management system 5800, the calling party 5810 then submits the terms of the CPO to the CPO management system 5800, such as the maximum price for the call and the telephone number of the called party 5830.

In a further variation, shown in Figure 58B, the calling party 5810 can initially contact the CPO management system 5800 by means of online access or e-mail using a subscriber terminal 5815, such as a general-purpose computer, to access the Internet 5870. This online embodiment is particularly suited for a calling party 5810 desiring to submit a CPO for a package of calls to one or more called parties 5830, or for a contract to provide telephone service for a predefined period of time.

The terms of the CPO may optionally be displayed to the calling party 5810 on the telephone set 5900, as shown in Figure 59. In addition, the telephone set 5900 can be specially configured with software for transmitting a CPO to the CPO management system 5800 or directly to the interexchange carriers 5820. For example, a speed dial button of the telephone set 5900 can be programmed to automatically transmit the terms of a CPO to the CPO management system 5800 or directly to the interexchange carriers 5820. In this manner, the calling party 5810 would program the terms of a given CPO using the keypad and function keys on the telephone set 5900, and then initiate transmission of the CPO using the speed dial button.

As shown in Figure 58A, when the calling party 5810 dials the telephone number assigned to the CPO management system 5800, a connection is typically first established to a local switch operator 5850, which is the telephone switching system, for example, of the local telephone company. The local switch operator 5850 in turn connects the calling party to the Public Switched Telephone Network (PSTN). The local switch operator 5850 is capable of establishing a connection between the calling party 5810 and one of a number of interexchange carriers 5820-5824 over a communications link 5860, in a manner well-known in the telephony art. The interexchange carriers 5820 may be, for example, providers of long distance carrier networks, including circuit and packet switched networks or combinations thereof, and the communications link 5860 may be a cable, fiber or wireless link on which electronic signals can propagate. It is noted that with the increasing trend for long distance carriers to provide local telephone service in many areas, and vice versa, the distinction between the local switch

operator 5850 and the interexchange carriers 5820-5824 may become transparent. One or more of the interexchange carriers 5820 may be able to route a call between a given calling party 5810 and a desired called party 5830. For a more detailed discussion of the manner in which a connection is made between a given calling party 5810 and a desired called party 5830, over a long distance carrier network by an interexchange carrier 5820, see U. S. Patent Number 4,191,860, incorporated by reference herein.

According to a feature of the present invention, the CPO management system 5800 preferably provides an optional agency feature that permits the CPO management system 5800 to accept or reject a given CPO on behalf of certain agency- based interexchange carriers 5820 who have delegated such authority to the CPO management system 5800. Thus, the CPO management system 5800 preferably (i) evaluates CPOs on behalf of certain agency-based interexchange carriers 5820 who have delegated authority for deciding to accept or reject a given CPO to the CPO management system 5800; and (ii) permits broadcast-based interexchange carriers 5820 to evaluate CPOs independently. Thus, the CPO management system 5800 can provide a CPO to each broadcast-based interexchange carrier 5820, for the interexchange carrier 5820 to independently determine whether or not to accept a given CPO. It is noted that the CPO management system 5800 can provide a CPO to each broadcast-based interexchange carrier 5820, for example, by means of a broadcast transmission, or by means of posting the CPO, for example, on an electronic bulletin board accessible by each broadcast-based interexchange carrier 5820.

In addition, the CPO management system 5800 can evaluate a CPO against a number of CPO rules defined by one or more agency-based interexchange carriers 5820, to decide on behalf of an agency-based interexchange carrier 5820 to accept or reject a given CPO. Thus, the CPO management system 5800 can determine if one or more carriers accepts a given CPO by providing the CPO to each carrier and receiving an acceptance or rejection, or by applying the CPO to the CPO rules to render a decision to either accept, reject or counter a CPO on behalf of a particular carrier.

As discussed further below, a CPO rule is a set of restrictions defined by a given agency-based interexchange carrier 5820, to define a combination of such restrictions for which the interexchange carrier 5820 is willing to accept a commitment to complete one or more telephone calls. In a preferred embodiment, the CPO rules are

generated by some type of revenue management system, yield management system, or profit management system of the respective agency-based interexchange carrier 5820, or by any system that controls and manages network capacity. For a more detailed discussion of CPO rules, the manner in which they are generated and related security issues, see U. S. Patent Application Serial No. 08/889,319, entitled Conditional Purchase Offer Management System, filed July 8,1997, the parent application to the present invention, which is incorporated by reference herein. Generally, the revenue management system, for example, will employ a CPO rules generation process to generate CPO rules by evaluating current network capacity, pricing and revenue information, as well as historical patterns and external events, to forecast future calling demand.

Once the terms of a CPO have been received by the CPO management system 5800, a central server 6000, discussed below in conjunction with Figure 60, will execute a CPO management process 6500, discussed below in conjunction with Figures 65a and 65b, to (i) provide each CPO to the interexchange carriers 5820 and (ii) to determine if the terms of the offer have been accepted by any interexchange carrier 5820. Thereafter, the CPO management system 5800 or the accepting interexchange carrier 5820 notifies the calling party 5810 of the response of the interexchange carriers 5820 and, if accepted, the calling party 5810 is bound to complete and pay for one or more calls having the appropriate restrictions which meet the conditions defined by the calling party 5810.

The CPO management system 5800 may optionally maintain an audit trail for each CPO that is processed by the CPO management system 5800. For a discussion of a suitable audit system, see the parent application to the present invention, incorporated by reference herein above.

According to a further feature of the invention, the CPO management system 5800 prevents calling parties 5810 from identifying the carrier's minimum price for the one or more telephone calls associated with a given CPO. For example, the CPO management system 5800 preferably does not disclose the carrier's minimum price to calling parties and optionally limits the number of CPOs that any calling party 5810 can submit within a predefined time period. In addition, the binding nature of the present invention discourages calling parties 5810 from submitting CPOs merely to identify the

minimum price, since the calling party 5810 will be obligated to complete one or more telephone call (s) in accordance with the terms of the CPO. In alternate embodiments, the calling party 5810 can be charged a fee or a penalty if a call is not completed when at least one carrier 5820 has accepted the CPO, or the CPO management system 5800 can evaluate a rating of the calling party 5810 containing information regarding the likelihood that the calling party 5810 will complete one or more telephone calls corresponding to said CPO. For a more detailed description of a suitable rating system, see U. S. Patent Application Serial No. 08/811,349, filed March 4,1997, entitled AIRLINE PRICE INQUIRY METHOD AND SYSTEM, assigned to the assignee of the present invention and incorporated by reference herein. In one embodiment, the evaluated rating comprises a ratio of completed calls to purchase offers by the customer 5810. In this manner, the carriers 5820 can be confident that if the carrier accepts the calling party's offer, the calling party 5810 will complete the call (s) without using the information to ascertain the carrier's underlying level of price flexibility.

Figure 60 is a block diagram showing the architecture of an illustrative CPO management central server 6000. The CPO management central server 6000 preferably includes certain standard hardware components, such as a central processing unit (CPU) 6005, a random access memory (RAM) 6010, a read only memory (ROM) 6020, a clock 6025, a data storage device 6030, and a communications port 6040. The CPU 6005 is preferably linked to each of the other listed elements, either by means of a shared data bus, or dedicated connections, as shown in Figure 60. The CPU 6005 may be embodied as a single commercially available processor, such as Intel's Pentium 100 MHz P54C microprocessor, Motorola's 120 MHz PowerPC 604 microprocessor or Sun Microsystem's 166 MHz UltraSPARC-I microprocessor. Alternatively, the CPU 6005 may be embodied as a number of such processors operating cooperatively.

The ROM 6020 and/or data storage device 6030 are operable to store one or more instructions, discussed further below in conjunction with Figures 65 and 66, which the CPU 6005 is operable to retrieve, interpret and execute. For example, the ROM 6020 and/or data storage device 6030 preferably store processes to accomplish the transfer of required payments, charges and debits, between the calling parties 5810 and interexchange carriers 5820-5824.

The CPU 6005 preferably includes a control unit, an arithmetic logic unit (ALU), and a CPU local memory storage device, such as, for example, a stackable cache or a plurality of registers, in a known manner. The control unit is operable to retrieve instructions from the data storage device 6030 or ROM 6020. The ALU is operable to perform a plurality of operations needed to carry out instructions. The CPU local memory storage device is operable to provide high-speed storage used for storing temporary results and control information.

As discussed further below in conjunction with Figures 61 through 64, respectively, the data storage device 6030 preferably includes a customer database 6100, a carrier database 6200, a rate database 6300, and a CPO database 6400. The customer database 6100 preferably stores information on each customer of the CPO management system 5800, including biographical information and an indication of the local telephone company serving each customer. The carrier database 6200 preferably stores information on each carrier which is registered with the CPO management system 5800 to provide long distance telephone service to calling parties, including address information. The rate database 6300 preferably stores published rate information for each carrier identified in the carrier database 6200. Finally, the CPO database 6400 preferably contains a record of each CPO being processed by the CPO management system 5800, including the terms of the CPO and the associated status.

In an embodiment where the CPO management system 5800 provides an agency feature that permits the CPO management system 5800 to accept or reject a given CPO on behalf of certain agency-based interexchange carriers 5820 who have delegated such authority to the CPO management system 5800, the CPO management central server 6000 preferably includes a CPO rules database (not shown) for storing the CPO rules. The CPO rules may be stored in a secure database to maintain the integrity and confidentiality of sensitive information included in each CPO rule.

In addition, the data storage device 6030 includes a CPO management process 6500, discussed further below in conjunction with Figures 65a and 65b, and an IVRU process 6600, discussed further below in conjunction with Figures 66a and 66b.

Generally, the CPO management process 6500 receives each CPO from a calling party 5810, provides the CPO to each appropriate interexchange carrier 5820 and thereafter determines if the terms of the offer have been accepted by any interexchange carrier

5820. The IVRU process 6600 is preferably invoked by the CPO management process 6500 to receive the parameters of the CPO from the calling party 5810.

The communications port 6040 connects the CPO management central server 6000 to the local switch operator 5850 and interexchange carriers 5820-5824.

The communications port 6040 preferably includes multiple communication channels for simultaneously establishing a plurality of connections.

DATABASES Figure 61 illustrates an exemplary customer database 6100 that preferably stores information on each customer (calling party) of the CPO management system 5800, including biographical information and an indication of the local telephone company serving each customer. The customer database 6100 maintains a plurality of records, such as records 6105-6125, each associated with a different customer. For each customer name listed in field 6140, the customer database 6100 includes the customer's address in field 6145, the manner in which the customer is bound in field 6150, an indication of the local telephone company serving the customer in field 6155 and the customer's telephone number in field 6160. The telephone number stored in field 6160 may be utilized, for example, as a customer identifier to index a historical database (not shown) of previous transactions associated with the customer.

As shown in field 6150, a given customer may be bound by a pre- existing written or electronic contract on file, which may, for example, authorize an accepting interexchange carrier 5820 to charge the calling party 5810 for a given call on the calling party's telephone statement or by means of a charge to a credit card, or other general-purpose account. As discussed below, the calling party 5810 may be billed for telephone calls completed in accordance with the present invention by the CPO management system 5800 or the local switch operator 5850, on behalf of the accepting interexchange carrier 5820, or directly by the accepting interexchange carrier 5820, in a conventional manner.

In an implementation where a CPO obligates a calling party 5810 to achieve minimum usage for a predefined time period, for example, where a calling party 5810 agrees to spend at least two hundred dollars ($200) over twelve (12) months to obtain a lower rate, the agreed upon terms can be immediately charged to a credit card,

or charged on a monthly basis. In addition, the credit card may not be charged unless the calling party 5810 fails to meet the obligations of the CPO. For example, the calling party 5810 may be billed directly for calls as charges are incurred, and the remaining balance may be charged to the credit card account at the end of the agreed term. In addition, a calling party 5810 can be charged a penalty if the calling party 5810 does not agree to complete the call after the CPO is accepted by an interexchange carrier 5820.

Figure 62 illustrates an exemplary carrier database 6200 which preferably stores information on each carrier which is registered with the CPO management system 5800 to provide long distance telephone service to calling parties, including address information. The carrier database 6200 maintains a plurality of records, such as records 6205-6225, each associated with a different carrier. For each carrier name listed in field 6240, the carrier database 6200 includes address information in field 6245. In addition, in an embodiment where the CPO rules of a given carrier are stored in an encrypted format, or otherwise where secure transmissions are required, the cryptographic key of the associated carrier is preferably stored in field 6250 of the carrier database 6200. Finally, the carrier database 6200 preferably stores an indication in field 6255 of the percentage of CPOs which have been offered to each carrier which have actually been accepted by each respective carrier. In this manner, the CPO management system 5800 can offer a particular CPO to carriers in a sequence that is ranked in accordance with the CPO acceptance rate. In alternate embodiments, the carrier database 6200 can incorporate fields to facilitate the processing of CPOs in accordance with sequences based on (i) priorities negotiated by each carrier, or (ii) the highest commission rates paid by the carriers to the CPO management system 5800.

Figure 63 illustrates an exemplary rate database 6300 that preferably stores published rate information for each carrier identified in the carrier database 6200.

The rate database 6300 maintains a plurality of records, such as records 6305-6325, each associated with a different carrier. For each carrier identified in field 6340, the rate database 6300 preferably includes the corresponding domestic rate and international rate in fields 6345 and 6350, respectively.

Figure 64 illustrates an exemplary CPO database 6400 which preferably contains a record of each CPO being processed by the CPO management system 5800, including the terms of the CPO and the associated status. The CPO database 6400

maintains a plurality of records, such as records 6405-6425, each associated with a different CPO being processed by the system 5800. For each CPO identified by CPO number in field 6440, the CPO database 6400 includes the date the CPO was received in field 6445, an identification (ID) number for the customer associated with the CPO in field 6450 and an indication of the telephone number to be called in field 6455. The parameters of the calling party's CPO are stored in field 6460 of the CPO database 6400. The CPO database 6400 preferably stores the price the calling party is willing to pay for the call in field 6470. Field 6465 indicates the accepting carrier, once accepted and field 6475 records the current status of the respective CPO, such as pending, accepted, rejected or expired.

PROCESSES As discussed above, the CPO management central server 6000 preferably executes a CPO management process 6500, shown in Figures 65a and 65b, to receive each CPO from a calling party 5810, provide the CPO to each appropriate interexchange carrier 5820 and thereafter determine if the terms of the offer have been accepted by any interexchange carrier 5820. As illustrated in Figure 8a, the CPO management process 6500 begins the processes embodying the principles of the present invention during step 6505, upon receipt of a call from a calling party 5810, for example, via a private branch exchange (PBX) switch of the CPO management system 5800.

Thereafter, during step 6510, the CPO management process 6500 will extract the automatic number identification (ANI) number associated with the incoming call. A new record is then created in the customer database 6100 during step 6515 using the extracted ANI number as the customer identifier recorded in field 6160. Thereafter, the IVRU process 6600, discussed below in conjunction with Figures 66a and 66b, or another customer interface process, is preferably executed during step 6525 to receive the parameters of the CPO from the calling party 5810, including the telephone number of the called party 5830, the maximum price, the manner in which the CPO will be bound and any time limitations and other applicable restrictions. The received parameters of the CPO are then stored in the CPO database 6400 during step 6530, indexed by the customer identifier (ANI) and then provided to the appropriate carriers during step 6535 (Figure 65b). It is noted that the CPO management system 5800 can filter the CPOs provided to each carrier, for example, by only providing the CPO to

carriers who can route a call between the calling party 5810 and the desired called party 5830 or only providing the CPOs to carriers designated by the calling party 5810. It is further noted that the CPO management process 6500 preferably evaluates the CPO against the CPO rules provided by any agency-based carriers during step 6530 as well.

A response to the CPO is preferably received from each carrier during step 6540. A test is then performed during step 6545 to determine if the terms of the CPO have been accepted by a carrier. If it is determined during step 6545 that the terms of the CPO have not been accepted by a carrier, then the calling party 5810 is preferably notified during step 6550 that the CPO has been rejected. The status of the CPO in the CPO database 6400 is then changed to"rejected"during step 6555, before program control terminates during step 6560.

If, however, it is determined during step 6545 that the terms of the CPO have been accepted by a carrier, then the full customer record from the CPO database 6400 is preferably provided to the accepting carrier during step 6570 for the carrier to complete the call in accordance with the terms specified by the CPO. It is noted that the calling party 5810 may be billed for the call by the CPO management system 5800 or the local switch operator 5850 on behalf of the accepting interexchange carrier 5820, or directly by the accepting interexchange carrier 5820, in a conventional manner. The local switch operator 5850 typically receives a percentage of the total cost to complete the call. Finally, the status of the CPO in the CPO database 6400 is then changed to "accepted"during step 6575, before program control terminates during step 6580.

As indicated above, the CPO management process 6500 preferably executes the IVRU process 6600, shown in Figures 66a and 66b, during step 6525 to receive the parameters of the CPO from the calling party 5810, including the telephone number of the called party 5830, the maximum price, and any time limitations and other applicable restrictions. As shown in Figure 66a, the IVRU process 6600 begins the processes embodying the principles of the present invention during step 6610 by prompting the calling party 5810 for the telephone number of the called party 5830.

Thereafter, the interactive voice response unit (IVRU) captures the response of the calling party 5810 during step 6620 and provides the number to be called to the CPU 6005.

The IVRU then prompts the calling party 5810 for the price the calling party 5810 wishes to pay for the call and the manner in which the CPO will be bound, such as a charge to a credit card account, during step 6630, and captures the response during step 6640 providing the maximum price for the call to the CPU 6005.

Thereafter, the IVRU prompts the calling party 5810 for any other restrictions or specifications associated with the CPO during step 6650, including, for example, a time limit for the call, one or more desired carriers, if any, and a time limit for how long the CPO should be pending. The IVRU then captures the response of the calling party 5810 during step 6660 and provides the additional restrictions or specifications to the CPU 6005. Finally, the IVRU process 6600 instructs the calling party 5810 to hang up and wait for a response during step 6670 (Figure 66b), before program control terminates during step 6680.

In this manner, the restrictions of the CPO are received by the CPO management system 5800 and then provided to each appropriate interexchange carrier 5820. If accepted, the interexchange carrier 5820 will complete the call between the calling party 5810 and the desired called party 5830, in accordance with the terms of the CPO, and the calling party 5810 is obligated to pay the accepting interexchange carrier 5820 for the cost of the call.

In the embodiment shown in Figure 58A, a calling party 5810 desiring to place a call to a called party 5830 picks up the telephone set 5900 and dials a telephone number associated with the CPO management system 5800. The call is preferably received by a PBX switch or a related call processor. The telephone number of the calling party 5810 is then extracted from the call information, and used to access or create a record in the customer database 6100. The calling party 5810 is then connected to either an IVRU or a live operator to submit the terms of the calling party's CPO, such as the number to be called and the maximum cost. The caller then is preferably instructed to hang up and wait for a response.

Once the CPO is received and processed by the CPO management system 5800, it is then provided to a plurality of carriers. Each carrier 5820-5824 then determines whether to accept or reject the CPO, for example, based on one or more rules based on network capacity balancing. If the CPO is accepted, the CPO management system 5800 or the accepting carrier 5820 notifies the buyer and places the

call over the network of the accepting carrier. If there is a time limit or other restrictions associated with the call, the calling party 5810 is preferably notified at the time the call is initially established.

The calling party 5810 may be billed for the call, for example, by the CPO management system 5800, the accepting carrier 5820, or by the local telephone company operating the local switch 5850. In this manner, the call may be individually charged to a general purpose account, such as a credit card, or may be paid for by means of the calling party's conventional telephone bill.

Similarly, the embodiment shown in Figure 58B, a calling party 5810 desiring to submit a CPO for telephone service for a predefined period of time, may contact the CPO management system 5800 using a subscriber terminal 5815. The CPO can specify, for example, the rate at which the subscriber is willing to pay for the telephone service and the length of the contractual obligation, as well as any flexibilities or restrictions that the calling party is willing to adhere to, in return for a discounted rate, such as calling during off-peak hours or a minimum spending obligation.

Once the CPO is received and processed by the CPO management system 5800, the CPO is then provided to a plurality of carriers. Each carrier 5820-5824 then determines whether to accept or reject the CPO. If the CPO is accepted, the CPO management system 5800 or the accepting carrier 5820 notifies the buyer and switches the long distance provider for the calling party to the accepting carrier 5820, in an appropriate manner.

CPO MANAGEMENT SYSTEM FOR EVENT TICKETS Another embodiment of the present invention will now be discussed with reference to Figures 67 through 73g. The embodiment shown in Figures 67

through 73 allows a buyer to present a guaranteed purchase offer for a ticket to a certain event, such as a hockey game, to a number of potential sellers. The sellers may review the offer, and accept the offer if the terms are agreeable. Thus, a buyer may quickly submit an offer to purchase tickets which are guaranteed to be delivered in a safe, convenient manner.

With reference to Figures 67-72b, the system architecture of one embodiment of the apparatus and method of the present invention is illustrated. As shown in Figure 67, the apparatus of the present invention generally comprises a venue controller 7000, a central controller 6800, a credit card processor 6830 and a remote user terminal 6900. The remote user terminal 6900 is connected to the central controller 6800 through a network 6845.

Using the above components, the present embodiment of the invention provides a method and apparatus to allow a central controller to facilitate the purchase and sale of event tickets. Specifically, central controller 6800 receives and posts offers to purchase tickets for a particular event. Such offers are guaranteed, for example, using a line of credit on a credit card account. Central controller 6800 further makes each offer available to a plurality of potential sellers, and allows sellers to accept the offer and thereby form a legally binding contract.

As shown in Figure 68, central controller 6800 includes central processing unit (CPU) 6805, random access memory (RAM) 6815, read only memory (ROM) 6820, clock 6835, input/output ("I/O") port 6855, and data storage device 6850. The data storage device 6850 is a memory device containing an event table 7100, a venue table 7120, a customer table 7130, an offer table 7150, and a transaction table 7180, discussed in

greater detail with reference to Figures 71a through 71e, respectively.

Figure 71a illustrates an exemplary event table 7100 that preferably stores information on events for which tickets may be resold using the system of Figure 67, including location and scheduling information. Event table 7100 maintains a plurality of records, such as record 7114, each associated with a different event. For each event identifier listed in event ID field 7102, event table 7100 includes an event type code stored in field 7104 and an event description stored in field 7106. The event type code stored in field 7104 represents the format of the event, for instance, a National Hockey League game is denoted as "NHL."The event description stored in field 7106 describes the specific event.

Event table 7100 also preferably includes a venue ID stored in field 7106. The venue ID stored in field 7106 may be utilized, for example, to index venue table 7120, more fully described with reference to Figure 71b. As shown in Figure 71a, each record stored in event table 7100 further includes a date stored in field 7110 and a time stored in field 7112. The date and time of fields 7110 and 7112, respectively, represent the starting time of the event associated with the record. The information stored in this table may be supplied to the central controller 6800 from any number of sources, including promoters, venues and potential buyers and sellers.

Figure 71b illustrates an exemplary venue table 7120. Each record of venue table 7120, such as record 7128, preferably stores data associated with and describing a venue. Venue table 7120 is preferably indexed by field 7122 which stores a unique venue identifier. Venue table 7120 further stores a theater, auditorium or stadium name in field 7124 and an address

in field 7126.

Figure 71c illustrates an exemplary customer table 7130 which preferably stores information on each customer registered with the electronic ticket sales system. Customer database 7130 maintains a plurality of records, such as records 7146 and 7148, each associated with a different customer. Customers registered in customer table 7130 may buy tickets, sell tickets or both buy and sell tickets. Customer table 7130 stores a unique customer identifier for each customer in field 7132 and name and address information in fields 7134 and 7136. Preferably, the data maintained in customer table 7130 is provided by the customer during a registration process, at which time the customer is assigned a unique customer identifier.

Customer table 7130 further stores customer credit card data. The customer's credit card number is stored in field 7138. The expiration date of the customer's credit card is stored in field 7140, and the name of the cardholder as it appears on the credit card is stored in field 7142.

Figure 71d illustrates an exemplary offer table 7150 that preferably stores information relating to offers posted using the ticket sales system of the present embodiment. Offer table 7150 maintains a plurality of records, such as records 7170 and 7172, each associated with an offer to buy or sell tickets.

Each record of offer table 7150 includes a unique offer identifier stored in field 7151 that is assigned by central controller 6800 when the offer is posted. Each record of offer table 7150 includes fields for identifying the customer making the offer, conditions of the offer, the customer accepting the offer, and administrative information related to the offer.

The customer identifier of the customer extending the offer is stored in field 7152.

Information relating to the customer extending the offer may be easily obtained using the customer identifier of field 7152 as an index into customer table 7130. Each record in offer table 7150 further stores an event identifier in field 7153. The event identifier indicates the event to which the offered ticket (s) relate. Information regarding the event may be easily obtained using the event identifier of field 7153 as an index into event table 7100.

Each record of offer table 7150 further includes fields 7154 and 7155 that store the date the offer was made and the last day on which the offer may be accepted, respectively. Data indicating an offer type and offer status are also stored in each record of offer table 7150 in fields 7156 and 7157. Field 7156 stores a code indicating whether the offer is an offer to buy or an offer to sell one or more tickets. Field 7157 stores a code indicating the status of the offer.

Offer status possibilities include: pending, active, expired and fulfilled.

Field 7158 of each record in the offer table stores the number of seats to which the offer applies.

Data identifying the location of seats related to the offer populate fields 7159-7164. In the event an offer requires a range of seat locations, data stored in fields 7159-7161 are used to identify the first seat in a range, and data stored in fields 7162-7164 are used to identify the last seat in a range. Field 7165 stores the price per seat.

In addition, each record of offer table 7150 includes administrative data in fields 7166-7169. Data stored in field 7166 stores an amount of credit authorized to support the offer. Once an offer has been accepted, field 7167 stores a transaction identifier that may be used as an index into transaction table 7180, discussed more completely with

reference to Figure 71e. Each record of offer table 7150 optionally stores a pointer to a related, or linked, offer record. The pointer is stored in field 7168 and represents the offer identifier of the next related record in offer table 7150. Finally, field 7169 of each record of offer table 7150 stores one or more serial numbers of the original tickets that a seller would like to sell.

Once an offer is accepted, central controller 6800 adds a transaction record to transaction table 7180. Figure 71e illustrates an exemplary transaction table 7180 that preferably stores information relating to each accepted offer. Each accepted offer is assigned a unique transaction identifier that is stored in field 7181 of transaction table 7180 and field 7167 of offer table 7150. An offer identifier of an associated record in offer table 7150 is stored in field 7182. This offer identifier may be used as an index into offer table 7150 to retrieve information regarding the offer associated with a transaction record.

Each record of transaction table 7180 preferably further includes field 7183 which stores the date the associated offer was accepted and field 7184 which stores the total value of the transaction. Field 7185 stores the amount charged to the buyer's credit card; field 7186 stores the amount of the seller's credit line reserved to support the acceptance; and field 7187 stores the fee charged for processing the transaction. Each record of transaction table 7180 also stores a date in field 7188 indicating the date the ticket (s) are received by the operator of controller 6800.

The customer identifier of the seller is stored in field 7189, and data identifying the ticket (s) is stored in fields 7190 and 7194. Field

7190 stores the original ticket number (s), and field 7194 stores new ticket number (s). The new ticket numbers are assigned to distinguish original tickets from resold tickets and promote efficient resolution of potential conflicts between ticket holders.

Optionally, central controller 6800 may include a contract detail table (not shown) containing form contract provisions which the central processor 6800 retrieves and transmits to users at various times.

For example, the contract table may include a contract provision that is transmitted to a buyer and incorporated into the guaranteed purchase offer. The contract table may also include a contract provision which is transmitted to a seller prior to requesting an acknowledgment of his intent to bind a buyer's offer and create a legally binding contract. These form provisions effectively fill the gaps between conditions specified by the buyer, specifying the generic contract details common to most contracts of this nature.

Referring now to Figure 69, remote user terminal 6900 will now be described in greater detail.

Remote user terminal 6900 can be a personal computer, screenphone, stand alone kiosk, or any other device through which a customer can access the central controller 6800. Remote user terminal 6900 generally includes a central processing unit ("CPU") 6905 that controls the operation of remote user terminal 6900.

CPU 6905 is electronically connected to a random access memory ("RAM") 6915, a read only memory ("ROM") 6920, an input/output port 6925, a clock 6935, a communication port 6940 and a data storage device 6960.

CPU 6905 receives inputs from a remote user with the input/output port 6925 and an input device 6945, such as a keyboard. CPU 6905 transmits outputs to a remote user via the input/output port 6925 and a video monitor 6930. Further, the communication port 6940 provides

the communication path to network 6845. Finally, the data storage device 6960 is a memory device containing central controller interface software 6965.

Referring now to figure 70, venue controller 7000 will now be described in greater detail. Venue controller 7000 generally includes a central processing unit ("CPU") 7010 that controls the operation of venue controller 7000. The CPU 7010 is electronically connected to a random access memory ("RAM") 7020, a read only memory ("ROM") 7030, a clock 7040, a communication port 7050 that provides a communication path to central controller 6800, and a data storage device 7060. Data storage device 7060 is a persistent memory device containing a ticket table 7210 and a replacement ticket table 7230. Venue controller 7000 further includes input device 7080 for receiving input data and output device 7070 for presenting or displaying information to an operator.

Figure 72a illustrates an exemplary ticket table 7210 that preferably stores information about tickets issued for various seats at a particular venue.

Each ticket has a specific ticket number assigned to it by venue controller 7000 prior to issuance. Each record of ticket table 7210 preferably includes field 7211 that identifies the event for which the ticket is valid, field 7212 that identifies the number assigned to each ticket issued for an event, and fields 7214- 7220 that represent the location of the seat in the auditorium (i. e. the section, row and seat, respectively). Ticket table 7210 could also contain fields representing other information specific to a venue, an event, or a seat.

Figure 72b illustrates an exemplary replacement ticket table 7230 that preferably stores data relating to original ticket numbers that have been voided and assigned replacement ticket numbers.

128

Replacement ticket table 7230 stores the ticket numbers that have been resold by the central controller 6800 in field 7232 and stores the replacement ticket numbers in field 7242. Each record of ticket table 7230 further includes a field 7231 that stores an event identifier and a field 7240 that stores a buyer identifier.

It will be recognized by one of ordinary skill that the present invention could be constructed and operated without the illustrated distributed processing architecture. If venues and ticket distributors so desired, central controller 6800 could incorporate all or part of the database of venue controller 7000 and perform all or part of the processing steps performed by venue controller 7000 in the present embodiment. In such an alternate embodiment, data processing and data storage could be centralized, and venues could access the data as appropriate using conventional remote terminals or work stations.

In one embodiment of the present invention, communications between potential buyers and sellers take place via an electronic or digital network, such as the Internet, with central controller 6800 hosting an Internet web site that users can access or"log on" to by means of a personal computer. It is important to note that users can access the central controller via other communications links such as a conventional telephone line linked to a voice response unit ("VRU").

To use the ticket reselling service, a user who is a potential buyer logs on to central controller 6800 through network 6845, creates and submits a guaranteed purchase offer, and disconnects from the network 6845. In one embodiment, a guaranteed purchase offer is a legally binding offer to purchase tickets that is backed by a pre-authorized credit card transaction. Upon receiving the offer, central

controller 6800 contacts the buyer's credit card issuer to ensure that the buyer has a valid credit card account and/or sufficient credit to pay for the requested tickets. The guaranteed purchase offer is then made available to potential sellers. by posting the offer using the web site linked to central controller 6800. Periodic maintenance is performed by central controller 6800 to ensure that"active"offers have not expired. A potential seller can use the system of the present invention to browse offers and submit an electronic acceptance of a desirable offer. The acceptance by the potential seller is transmitted electronically to central controller 6800. Central controller 6800 processes the acceptance and contacts the seller's credit card issuer to ensure that there is sufficient credit to cover a potential penalty for non- performance. This reservation of the seller's credit is intended to promote trust between the parties and, thereby, protect the transaction. After verifying available credit, both parties are notified of the binding transaction, and the tickets are electronically voided and assigned a replacement ticket number. The seller is then required to surrender the voided tickets. This may be accomplished by returning them to the venue, or the seller may mail the tickets to the operator of central controller 6800. Upon receiving the surrendered tickets, the operator of central controller 6800 directs payment to be transferred to the user selling the tickets.

With reference to Figure 73a, a process by which a user logs on and begins using the system will now be described. As shown in step 7300, a user operating a remote terminal 6900 establishes a connection with the central controller 6800 through network 6845. The user may be either a potential buyer wishing to place a guaranteed purchase offer for

tickets, or a potential seller wishing to review offers for tickets.

At step 7302, central controller 6800 requests a customer ID from the user. At step 7304, central controller 6800 determines how to proceed based on whether or not the user already has a customer ID.

If the user is registered with this service, and remembers his customer ID, he transmits his customer ID to central controller 6800 at step 7312, and the process continues with step 7314.

If, on the other hand, the user is not registered with the service, or does not remember his customer ID, he must submit a negative response at step 7304 and present relevant customer information to central controller 6800, as shown by step 7306. At step 7308, central controller 6800 creates a record of the customer based on the received customer information. This information, including name, address, credit card and number, expiration date, and name as it appears on the credit card, is stored in customer table 7130. At step 7310, central controller 6800 compares the information provided by the user with information already stored in customer table 7130. If a match is found, central controller 6800 retrieves the customer ID from field 7132 of customer table 7130, and transmits the customer ID number to the user. This service is provided for users who have given information previously, but do not remember their customer ID number. If no match is found, the central controller 6800 assigns a new customer ID to the user, stores it in field 7132 of customer table 7130, and transmits it to the user.

At step 7314 the user indicates whether he would like to submit a guaranteed purchase offer, or review offers from potential buyers. The process steps relating to submitting offers are described more fully

with reference to figures 73b-73c. The process steps relating to reviewing offers are described more fully with reference to figures 73d-73g. In an alternative embodiment, the user could also elect to advertise the availability of tickets for a certain event to potential buyers. Furthermore, a user could elect to review such advertisements, to get a better understanding of what a fair price might be, prior to submitting an offer.

Figures 73b and 73c illustrate the process steps executed following the user's choice at step 7314 to submit a guaranteed purchase offer. At step 7316, the central controller transmits general venue and event information to user terminal 6900 for display to the user. For instance, in one embodiment, central controller 6800 may provide a number of options to the user in order to pinpoint the specific event that the user would like to attend. The user could directly request a particular event, or proceed through a group of narrowing choices to ultimately find the right event. A user, for example, may be asked to identify any of the fields from event table 7100. Depending on the amount of information provided, the choice of events will be narrowed accordingly. For instance, if the user provides only the event type (e. g."NHL"), central controller 6800 scans the event table 7100 and provides all matches found in the event type field 7104. This may be a long list of events, however, central controller 6800 may prompt the user for more information to narrow the list. The user may then select from the narrow list to find the event for which he is looking. For example, the user may specify only Saturday matinee performances of a particular Broadway production in order to narrow the list. Central controller 6800 then provides the user with the correct event information, including the event ID from field

7102 of the event table 7100. The user includes this event ID as part of their guaranteed purchase offer so that it may be tracked by central controller in the offer table 7150.

Next, at step 7318, the user selects the desired event based on the event ID number. At step 7320, central controller 6800 requests certain information from the user pertaining to the offer, such as (1) the number of tickets desired; (2) the price for each ticket; (3) the location desired for each ticket; and (4) optionally, a date through which the offer is valid.

The user indicates the number of tickets he would like and the price he is willing to spend, based on the particular location of the tickets. The user may choose the exact location of seats that correspond to the price he is willing to pay using a graphical representation of the venue. For instance, based on the venue ID number (stored in field 7122 of venue table 7120), central controller 6800 retrieves from memory and provides to the user at remote user terminal 6900 a graphical representation of seating at that particular venue. In one embodiment, central controller 6800 first provides a broad general outline of the entire venue (e. g., display by sections). The user can then click on a particular area to narrow his search for exact seats. With each successive selection click, the display screen at user terminal 6900 narrows the scope of displayed seating until the user finds the seats he desires. The user can then select the group of seats which corresponds to the purchase offer.

Central controller 6800 stores the selected seats in fields 7159-7164 of the offer table 7150. If the user

prefers to select one section or multiple sections instead of specific seats, he can enter a range of selections. Central controller 6800 then stores this broader selection by only using the section fields 7159 and 7162, and leaving the other four fields empty.

Further, the user may provide a close date to denote a date on which the offer expires. As previously discussed, central controller 6800 periodically reviews this close date, and changes the status of the offer to"expired"in field 7157 of the offer table 7150 once the date has passed.

At step 7322, central controller 6800 receives the offer information transmitted by the user, and as shown in step 7324, central controller 6800 creates a record of the offer in offer table 7150. At step 7328, the user is asked if he would like to make additional offers. At this point, if the user would like to make an offer for a separate event, he may go through the same process discussed in steps 7316-7324.

However, if the user would like to make a related, or linked offer to the offer previously provided, they may do so as follows. First, in one embodiment they provide the same event ID as at step 7318. Next, after submitting the same general information previously discussed, the user indicates that this offer is linked. The central controller then assigns the offer ID number created for the initial offer as the link ID number for the related offer, and stores in the link ID field 7168 of the offer table 7150.

A user might provide a linked offer based on the type of seat desired. For instance, the user might select a number of the"high quality"seats in a particular venue, and offer a higher purchase price.

The linked offer would include"lower quality"seats for a particular venue, perhaps at a lower purchase price. Thus, based on the link ID, potential sellers

will consider both offers together during their review.

Also, the user may link offers for two separate events as opposed to the same one. For example, instead of linking offers based on seat selection and price, the user may prefer to attend one of two events in the local area, but not both. Thus, he could link these offers so that potential sellers would be made aware that the offers were conditioned against an"either/or"proposition.

The central controller 6800 assigns an offer ID number to each offer in the offer ID field 7151, and assigns this number as the link ID number for linked offers in link ID field 7168. Also, the offer date field 7154 is populated with a timestamp (e. g., date and time) indicating when the offer was posted. Next, central controller 6800 assigns the value"pending"to the status field 7157. This value will change to "active"upon receipt of authorization from the user's credit card issuer. Further, central controller 6800 calculates the authorized amount, and stores it in authorized amount field 7166. The authorized amount field represents the amount of the user's credit which is reserved to"back up"the offer and is usually equal to the total transaction amount. By reserving a portion of the user's credit, the ticket seller and ticket service can be guaranteed that they will receive payment if the offer is accepted. In case of linked offers to buy, the authorized amount is the highest transaction amount of the linked offers. When a linked offer is accepted, the system automatically considers all related offers to be withdrawn. Finally, central controller 6800 stores all the information provided by the user, including the seat location based on the graphical representation of the venue, in the respective fields of the offer table 7150.

At step 7330, the central controller 6800

extracts legal contract language from the contract detail table (not shown) and transmits to the user at user terminal 6900. This language describes the legal implications of offering the guaranteed purchase offer, and the process is similar to reviewing terms before signing a written contract. If the user elects not to abide by these terms, he may cancel the offer.

However, if the user does elect to abide by the terms, the user transmits a positive acknowledgment to central controller 6800, and is legally bound to the terms of the guaranteed purchase offer.

In Figure 73c, central controller 6800 then contacts the user's credit card issuer at step 7332 to receive authorization for the offer. First, central controller 6800 collects the user name, address, credit card type, credit card number, and expiration date from customer table 7130, based on the customer ID from the offer table 7150. This information along with the authorization amount from field 7166 of the offer table 7150 is transmitted to the credit card issuer through credit card processor 6830.

At step 7334, the central controller 6800 receives either an authorization or rejection from the credit card issuer through credit card processor 6830.

The credit card issuer may reject the request for any number of reasons, including an expired card, overextended credit limit, or delinquency in payments.

Upon rejection, at step 7336 central controller 6800 notifies the user at user terminal 6900 of this rejection and requests separate credit card information. Alternatively, the user may transmit information corresponding to a separate credit card, which supplements or replaces his present information in the customer table 7130. If alternative credit card information is provided, step 7332 is repeated in order to receive authorization for the charge. Upon

receiving authorization from the credit card issuer through the credit card processor 6830, central controller 6800 updates offer table 7120, including changing status field 7157 to"active"to confirm the posted offer.

Figures 73d-73g illustrate the processing steps executed based on the user's choice at step 7314 to review offers from potential buyers. At step 7340, central controller 6800 transmits general venue and event information to user terminal 6900 for display to the user. As discussed earlier at step 7316, central controller 6800 may provide a number of options to the user to identify the exact event the user wishes to review. Ultimately, central controller 6800 provides the user with the event ID from field 7102 of the event table 7100. At step 7342, the user supplies the event ID to central controller 6800 so it may identify associated offers in offer table 7150.

At step 7344, central controller 6800 identifies offer records associated with the selected event ID and having an"active"status. Central controller 6800 transmits this data to user terminal 6900 for display to the user. The user may review all offers for the specific event together, or one at a time. In one embodiment, the user may review each individual offer through a graphic display of the venue, to pinpoint exactly where the buyer is requesting seats. In some cases, the offer may be for seats anywhere in the entire arena. In others, the offer may only be for a specific range of sections, rows or seats. In one embodiment, the user may be able to enter their exact ticket information to confirm whether it meets the requirements of the offer.

As previously discussed, linked offers will be appropriately identified upon presentation to the user. In this case, central controller 6800 allows

associated linked offers to be reviewed simultaneously, so that the user can compare the conditional offers submitted from a single buyer.

Next, at step 7346, central controller 6800 receives either a request to accept a particular offer, or a request to review offers for other events. In the latter case, steps 7340,7342 and 7346 will be repeated. It should be noted that the user may exit the system at any time prior to accepting an offer.

After the user transmits a request to accept a particular offer, at step 7348 the user transmits the original ticket number and seat location (i. e. section, row and seat) to central controller 6800. Upon receiving this information from the user, central controller 6800 at step 7350 transmits the original ticket number and seat location to the venue controller 7000 for verification of the ticket's validity.

Referring now to Figure 73e, at step 7352 venue controller 7000 retrieves a record from ticket table 7210 matching the ticket number transmitted by central controller 6800 in step 7350. Venue controller 7000 verifies that the transmitted ticket number matches the transmitted seat location at steps 7354 and 7356. If the transmitted ticket and seat location do not match, at step 7358, venue controller 7000 transmits an invalid combination message to central controller 6800. Central controller 6800 then transmits a message to user terminal 6900 indicating that the ticket number and seat location are an invalid combination at step 7360. Upon receiving the invalid combination message at user terminal 6900, the user can resubmit the ticket and seat location to central controller 6800 at step 7370. The process then loops back to step 7350. If the ticket number and seat location combination is valid, the process continues with step 7372.

At step 7372 of Figure 73f, central controller 6800 transmits to user terminal 6900 legal contract language which is displayed to the user selling his ticket. As previously indicated, this contract language may be stored in a contract detail table (not shown). This language describes the legal implications of accepting the guaranteed purchase offer, and the process is similar to reviewing terms before signing a written contract. If the user selling his ticket elects not to abide by these terms, the user may cancel his acceptance. However, if the user elects to abide by the terms, the user transmits a positive acknowledgment to central controller 6800, and is legally bound to the acceptance.

Central controller 6800 then contacts the user's credit card issuer at step 7376 to receive authorization for the acceptance. Central controller 6800 requests authorization from the credit card issuer to reserve a portion of the user's credit based on the offer information and credit information collected from the user at step 7306 and stored in customer table 7130. This credit reservation is a fraud deterrent and may be used as a penalty in the event the seller fails to deliver the tickets. Such a penalty creates buyer confidence and provides assurance. to a user buying the ticket that the user selling the ticket will, in fact, relinquish the tickets. The penalty could be paid to the user buying the ticket if the user selling the ticket attempts to repudiate the agreement. This penalty may be determined in a number of ways including imposing a flat penalty on the user selling the ticket or imposing a penalty equal to the entire amount offered by the user buying the ticket.

At step 7374, central controller 6800 collects information from the user selling the ticket.

The information may include the user name, address,

credit card number and expiration date from customer table 7130, based on the customer ID retrieved from the offer table 7150. This information, along with the authorization amount from field 7166 of the offer table 7150, is transmitted to the credit card issuer through credit card processor 6830.

At step 7376, central controller 6800 receives either an authorization or rejection from the credit card issuer through credit card processor 6830.

The credit card issuer may reject the request for any number of reasons, including an expired card, overextended credit limit, or delinquency in payments.

Upon rejection, at step 7328 central controller 6800 notifies the user at user terminal 6900 of the rejection and requests alternate credit card information. The user may attempt to transmit the same credit information as provided earlier, because the user may have mistakenly transmitted incorrect information earlier. Alternatively, the user may transmit information corresponding to an alternate credit card, which will supplement or replace the credit card information in customer table 7130.

Further, the user could cancel the transaction altogether. If alternative credit card information is provided, step 7374 is repeated in order to receive authorization for the charge.

If central controller 6800 receives authorization from the credit card issuer through credit card processor 6830, the process continues with step 7380 wherein central controller 6800 generates and assigns a transaction ID to the sale. This transaction ID is stored in field 7167 of the offer table 7150.

Further, central controller 6800 creates a new record in transaction table 7180, indexed by the assigned transaction ID. The assigned transaction ID is also stored in field 7181 of transaction table 7180. The

original ticket number 7190 field of transaction table 7180 is populated with the appropriate ticket number (s) from the user selling the ticket. Further, central controller 6800 timestamps the acceptance using date field 7183 indicating when the acceptance was posted.

Once the guaranteed purchase offer has been accepted, central controller 6800 uses the customer ID from field 7152 as an index into customer table 7130 to retrieve the name of the user buying the ticket. At step 7382, central controller 6800 transmits the name of user buying the ticket to the venue controller 7000.

At step 7384, venue controller 7000 creates a new record in replacement ticket table 7230. The new record is populated with information indicating the buyer's name, the original ticket number, the section, row and seat of the ticket. As shown at step 7386, the new record is further populated with a replacement ticket number assigned by venue controller 7000. The replacement ticket number is then transmitted to central controller 6800.

Once central controller 6800 has received the replacement ticket number 7242 from venue controller 7000, central controller 6800 then updates the new ticket number field 7194 of transaction table 7180 at step 7388. At step 7390, central controller 6800 determines the payment due and charges the credit card, of the user buying the ticket, the price of the ticket plus a processing fee 7187. Central controller 6800 also updates field 7185 of the transaction table 7180 with the amount charged. Finally, central controller 6800 updates field 7189 with the seller ID of the user accepting the offer, and central controller 6800 updates field 7186 with the seller amount authorized in the event that the seller tries to use his sold ticket.

Field 7184 is updated based on buyer amount charged 7185 less the processing fee 7187. Although fees of

the present embodiment are illustrated as being stored in a table, such fees could easily be calculated instead of being retrieved from a table.

At step 7392, central controller 6800 transmits a message to user terminal 6900 to notify the user selling the ticket that it will credit his credit card account with the sale amount of the ticket as soon as central controller 6800 receives verification that the original tickets have been surrendered.

At step 7394 the central controller transmits replacement ticket number 7292 and a message to the user buying the ticket indicating that his guaranteed offer has been accepted. The user buying the ticket may then print the replacement ticket number, take it to the venue and use it to gain access to the desired event, at step 7396. The cancellation of the original number and issuance of a replacement ticket number tied to the purchasing user's name is done in order to prevent fraud by either the ticket seller and/or the purchaser.

For instance, if a seller arrives at a venue with a ticket, and a purchaser also arrives to the same venue with a replacement ticket for the same seat, the venue controller can be accessed to determine which ticket is valid. The replacement ticket always supersedes the original ticket, provided it is registered in the replacement ticket table 7230 of the venue controller 7000. If such fraud is attempted by the seller and detected by central controller 6800, the central controller can charge the seller's credit card account the seller amount authorized in field 856 of transaction table 7180.

As another example, if two people arrive at the venue with the same replacement ticket, the venue controller can be accessed to determine the rightful owner, based on the contents of the new buyer name

field 7240, of replacement ticket table 7230. These measures taken against fraud will assure customers that there will be no problems in using central controller 6800 to buy and sell tickets.

Finally, at step 7398, central controller 6800 receives verification that the original ticket has been received from the seller, and credits the credit card account of the user selling the ticket with the transaction amount 7184. Central controller further updates the date tickets received field 7188 accordingly. Surrender of the ticket is preferably accomplished by delivery of the ticket to a will call window of the venue, however other surrender arrangements are possible, such as through the postal service or Federal Express. Once the ticket has been surrendered and the transaction is complete, central controller 6800 updates status field 7157 of the offer table 7150 to"completed"for tracking purposes. Upon receipt of the surrendered tickets, central controller 6800 credits the account of the user selling the tickets.

Although the preferred method of surrendering the original tickets is using the mail or other delivery mechanism, numerous alternate embodiments are possible. Using one alternate embodiment, ticket redemption could be constructively accomplished at the time an offer to buy is irrevocably accepted. The alternate embodiment employs event tickets that can be physically altered to render them invalid or void.

Each ticket includes a unique ticket number that is pre-printed on the face of the ticket, but obscured from view by a scratch-off covering, such as an opaque latex coating. The ticket number is unknown to the ticket holder unless the scratch-off covering is removed.

At the time of acceptance, the seller

possessing the tickets is instructed to remove the covering over the ticket number on each ticket to be sold. The ticket number is provided to central controller 6800 to verify that the ticket seller is, in fact, in possession of valid tickets. The ticket number provided for each ticket involved in the transaction is then electronically voided and replacement ticket number is assigned as previously described.

The act of revealing the ticket number not only serves to verify the ticket seller's possession of the tickets, but also eliminates the need for the seller to surrender the tickets because removal of the scratch-off covering voids the tickets. While this alternate embodiment requires additional structure with respect to the event tickets, it eliminates the need to reserve a portion of the seller's credit line as a penalty for failing to return the unused tickets.

An illustrative example of the invention will now be described using the data populating various fields of the figures. Record 7172 of the offer table 7150 is a guaranteed offer to buy as indicated by type field 7156 that has been submitted by user 4000 as identified by customer ID field 7152. User 4000, as denoted by record 7148 in the customer table 7130 is Sue Black, residing at 101 Pink Ave in Norwalk, CT.

The credit card number submitted to central controller 6800 is Discover card number 4444-4444-4444-4444 that expires 9/02 and was issued to Susan Black.

In record 7172 of the offer table 7150, Sue Black has posted a guaranteed offer to buy two tickets to event ID E001, as denoted by event ID field 7153, for $200.00 per ticket in the first row of the first section of the venue. As denoted by record 7114 of event table 7100, event E001 is an NHL game, specifically NJ Devils vs. New York Rangers, occurring

on 5/6/97 at 7: 30 PM at"MSG"as denoted by venue ID field 7108. Record 7126 of venue table 7120 identifies MSG as the Madison Square Garden venue in New York, NY.

In addition to this guaranteed purchase offer, Sue Black has also posted a link offer as denoted by linked ID field 7168. This linked offer has an ID code of 0333. Record 7170 of offer table 7150 has the offer ID 0333, and is therefore the offer that is linked to record 7172. Record 7170 is an offer by Sue Black to purchase four tickets to the NHL game NJ Devils vs. New York Rangers having the same date and time as the offer request of record 7172. In record 7170, Sue Black indicates that she will pay $250 each for four tickets in the first row of the first section of the venue. Because offer 7170 is linked to offer 7172, Sue Black has indicated that she would like one or the other of the two offers.

Field 7166 of offer table 7150 indicates that $1,000 has been authorized by Discover for account 4444-4444-4444-4444 for both records 7170 and 7172, submitted by Sue Black. $1,000 is the maximum possible amount that Sue Black's offers could cost her if one of them is fulfilled.

For record 7172, the transaction ID field 7167 has been populated with a transaction ID, indicating that a buyer has accepted Sue Black's guaranteed offer to buy. Status field 7157 of record 7172 registers that the offer has been fulfilled, and the status record 7170 is expired, since it was linked to record 7172 in a way indicating that if one was filled, the other should be disregarded.

Record 7195 of transaction table 7180 describes the detail of transaction TR001, which is the acceptance of Sue Black's guaranteed offer to buy by seller 2000, as indicated by seller ID field 7189.

Record 7170 of the customer table 7130

indicates that customer having the ID number 2000, as indicated by customer ID field 7132, is Jill Janson, residing in 456 Red Drive, Atlanta GA, and having Master Card number 2222-2222-2222-2222 with expiration date 9/99 registered with central controller 6800.

Record 7195 indicates that Sue Black was charged $420 on 5/2/97 for her purchase of seats 003 and 004 of row 1, seat 1 of the event tied to the record of her guaranteed purchase offer in offer table 7150. Record 7195 also indicates that Jill Janson has sold her original ticket numbers 667913 and 667914, stored in the original ticket number field 810, for section 001, row 001, and seat 003 and 004. The seller amount authorized field 7185 stores $400, the amount that central controller 6800 has been authorized by Mastercard to debit from account 2222-2222-2222-2222 in the event that Jill Janson does not honor her agreement to sell her tickets. All or a portion of this amount can be credited to Sue Black if there is a problem using her new ticket number for access to the venue event.

The date tickets received field 7188 is blank for this record, indicating that central controller 6800 has not yet received verification that Jill Janson has surrendered her tickets. Once central controller 6800 has received verification that Jill Janson has surrendered her tickets, Jill Janson's credit card account will be credited $380, the amount stored in transaction amount field 7184.

Central controller 6800 has issued replacement ticket numbers to Sue Black for both seats.

These replacement ticket numbers are stored in field 7194. Preferably, Sue Black will print out these replacement ticket numbers and take them with her to the venue to gain access to the event.

Records 7222 and 7224 of ticket table 7210

store information relating to the original tickets issued to Jill Janson. Records 7244 and 7246 of replacement ticket table 7230 store the replacement ticket numbers issued by central controller 6800 to Sue Black, which replace the original ticket numbers given to Jill Janson. These records are stored by venue controller 7000 to be used in the event of fraud as previously described.

It is important to note that in the embodiment described above, the notification of the parties, both buyer and seller is performed through contacting their respective remote user terminals. This notification can also be performed using conventional technology including but not limited to telephone, facsimile, e-mail and paging.

In addition to the guaranteed offer and acceptance system of the present invention, the present embodiment is also well suited for other aspects of ticket resale. For example, the present embodiment can include a registration process for certain events or tickets. Such a process would enable a prospective ticket buyer to set up a ticket watch which could be implemented by central controller 6800. Central controller 6800 could periodically poll offers to determine if specific tickets are available.

Availability could be transmitted to a user via conventional telephone lines, E-mail, facsimile or pager. A notification preference could be determined by the user during the registration process.

Another aspect of ticket resale that is well suited to the present embodiment is advertising.

Instead of simply allowing users to place, review and accept offers, the system could provide advertising for products related to events and tickets.

CPO AND THIRD PARTY INPUT MANAGEMENT SYSTEM The method and apparatus of another

embodiment of the present invention, which allows sellers to evaluate the acceptability of an offer from a buyer in light of information relevant to the offer from a third party, will now be discussed with reference to Figures 74 through 82. Although the description which follows in conjunction with Figures 74 through 82 employs a finance-related embodiment for purposes of illustration, those skilled in the art will understand that the scope of the present invention is not limited thereto. Accordingly, in the description below, sellers and buyers may be referred to as lenders and borrowers, respectively.

Referring to Figure 74, a system 7410 for processing the sale of products comprises a central controller 7412 which communicates with a borrower terminal 7414, third parties 7416 and 7418, and lender terminals 7420,7422 and 7424 via the Internet or other suitable communication network. The illustrated numbers of borrower terminals, third parties and/or lender terminals are illustrative, not limiting. It will be understood by those skilled in the art that any number of borrower terminals, third parties and/or lender terminals may communicate with the central controller 7412 in alternate embodiments of the present invention.

The borrower terminal 7414 is typically a computer or other apparatus for generating and transmitting signals to the central controller 7412.

Ideally, the borrower terminal is a conventional personal computer, such as one based on an Intel 80386 microprocessor, that is connected to a modem or other remote communication device. A customer desiring to purchase a product (good or service) operates the borrower terminal 7414 to transmit an offer signal including at least one condition signal to the central controller 7412. The offer signal defines a

conditional purchase offer having at least one condition from the customer.

In the present embodiment, the customer is a "borrower"who desires to obtain a loan (i. e., he desires to"purchase"a loan). Accordingly, the offer signal defines an offer to obtain a loan. As described in detail below, the offer may comprise any of a variety of conditions, and so the offer signal comprises one or more condition signals specifying the borrower's desired conditions. For example, the borrower may desire a particular monthly payment amount for the loan and/or a particular interest rate.

The borrower terminal 7414 also transmits to the central controller 7412 a payment identifier signal for specifying a general-purpose account from which funds may be paid. The payment identifier signal specifies, for example, a credit card number or checking account number of an account owned by the borrower.

The payment identifier signal is used to effectively"bind"the borrower by identifying funds to be paid if the borrower fails to carry out (consummate) his offer to purchase. The payment identifier thereby assures potential lenders that the offer is genuine and binding. For example, if the borrower reneges, the payment identifier may be used to collect an amount of funds sufficient to offset the lender's costs in processing the borrower's offer. The specific amount of funds to collect can be either set by the central controller 7412, or may be left to the discretion of the lender.

In other embodiments, the payment identifier may additionally be used to collect other fees, even if the borrower consummates his offer. For example, the payment identifier may be used to collect loan transaction fees or even monthly loan payments.

If a lender operates a lender terminal to accept the offer, thereby incurring costs processing the offer, the lender is assured that he (i) may sell the loan to the borrower if he can satisfy the loan conditions; or (ii) if the borrower fails to abide by the terms of the offer (e. g., the borrower fails to consummate the loan), the lender collects a penalty payment paid from the account specified by the payment identifier signal. In both cases, the lender is assured that acceptance of the offer will yield funds, and thus acceptance of the offer is not as risky as in other systems for processing the sale of products.

As described above, sellers often require information relevant to the offer from a third party in order to determine whether to accept the offer. For example, the offer signal from the borrower would not be evaluated and accepted by a lender unless the lender knew the borrower's credit history or credit score.

Accordingly, the system 7410 includes third parties 7416 and 7418 for providing the central controller 7412 with informational signals. The informational signals desirably define any information that (i) should not be viewed and/or altered by the buyer, and/or (ii) is necessary to determine the validity and/or value of the offer. The third parties 7416 and 7418 may be, for example, a credit-reporting bureau, which provides the central controller 7412 with credit information about the borrower, and an appraiser for appraising the value of loan collateral submitted by the borrower.

The central controller 7412 receives and stores the transmitted offer signal, payment identifier signal and informational signal. As described in detail below, the signals are stored in several databases, thereby facilitating the searching for and retrieval of data represented in the databases. The central controller 7412 uses the stored signals to

allow any of the lender terminals 7420,7422 and 7424 to accept the offer, if the offer is considered adequate.

If a lender terminal accepts the offer, the borrower is bound to abide by the terms of the offer.

If the borrower does not, for example if the borrower does not sign the necessary loan paperwork, the central controller 7412 initiates the use of the payment identifier signal to collect the funds. For example, the central controller 7412 may transmit the payment identifier signal to the lender terminal, thereby allowing the lender to collect the funds.

Alternatively, the central controller 7412 may itself use the payment identifier signal to collect the funds.

The central controller 7412 may manage the acceptance of offers in various ways. In embodiments described below, accepting an offer can include (i) transmitting the offer signal to lender terminals, and in turn receiving acceptance signals from lender terminals, or (ii) comparing the offer signal with seller's rules, and determining whether the offer satisfies any of the rules.

Figure 75a illustrates a central controller 7530, which is an embodiment of the central controller 7412 (Figure 74) that is used when accepting an offer includes the step of receiving acceptance signals from lender terminals. The central controller 7530 includes a central processing unit 7531, such as one or more conventional microprocessors, and a storage device 7532, such as a RAM, floppy disk, hard disk or combination thereof, which is connected to the central processing unit 7531. The central processing unit 7531 and the storage device 7532 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, the central controller 7530 may comprise one or more computers connected to a remote server computer for maintaining databases.

The storage device 7532 stores (i) a program 7533 for controlling the central processing unit 7531 in accordance with the present invention, and particularly in accordance with the processes described in detail hereinafter; (ii) a borrower database 7534 for maintaining information on each borrower who submits an offer; (iii) a lender database 7536 for maintaining information on each lender who may accept an offer; (iv) an offer database 7538 for specifying each offer submitted to the central controller; (v) a credit report database 7540 for storing informational signals describing credit worthiness; (vi) a collateral database 7542 for storing informational signals describing collateral used in connection with the offers; and (vii) a response database 7544 for specifying each acceptance received by the central controller.

The program 7533 also includes necessary program elements, 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 7534,7536,7538,7540,7542 and 7544 are described in detail below.

Figure 75b illustrates a central controller 7560, which is an embodiment of the central controller 7412 (Figure 74) that is used when accepting an offer includes the step of determining whether the offer satisfies any lender-specified rules. The central controller 7560 includes a central processing unit 7561 and a storage device 7562 connected to the central

processing unit 7561. The central processing unit 7561 and the storage device 7562 may each be implemented in a manner similar to the central processing unit 7531 and the storage device 7532 of Figure 75a.

The storage device 7562 likewise stores (i) a program 7533 for controlling the central processing unit 7561 in accordance with the present invention; (ii) a borrower database 7534 for maintaining information on each borrower who submits an offer; (iii) a lender database 7536; (iv) an offer database 7538; (v) a credit report database 7540; and (vi) a collateral database 7542; and further stores (vii) a rules database 7564 for storing lender-specified rules for accepting offers. The program 7533 and the databases 7534,7536,7538,7540 and 7542 function as described above, and the rules database 7564 is described in detail below.

Referring to Figure 76, the borrower database 7534 of Figures 75a and 75b stores exemplary records 7670 and 7672, each of which corresponds to a borrower who submits an offer. Each record stores an offer identifier 7674 that is generated by the central controller 7412 (Figure 74) and uniquely identifies an offer made by the borrower. Each record also stores the name 7676, address 7678 and telephone number 7680 of the borrower.

Referring to Figure 77, the lender database 7536 of Figures 75a and 75b stores exemplary records 7790 and 7792, each of which corresponds to a lender who may accept an offer. Each record stores a lender identifier 7794 that is generated by the central controller 7412 (Figure 74) and uniquely identifies a lender, as well as the name 7796, address 7798 and telephone number 7800 of the lender.

Referring to Figure 78, the offer database 7538 of Figures 75a and 75b stores exemplary records

7810,7812 and 7814, each of which corresponds to a received offer. Each record stores an offer identifier 7816 that (i) uniquely identifies an offer, and (ii) corresponds to one of the offer identifiers 7674 of the borrower database 7534 of Figure 76. Each record further stores the date 7818 and time 7820 at which the offer was received, and conditions of the offer, such as a loan amount 7822, a monthly payment 7824, a loan term 7826 and a loan interest rate 7828. Each record may also have an expiration date 7830 and expiration time 7832, after which the corresponding offer may not be accepted. A loan type 7834 may also be stored in embodiments where it is desirable for lenders to know, for example, whether the desired loan is secured.

Referring to Figure 79, the credit report database 7540 of Figures 75a and 75b stores exemplary records 7942,7944 and 7946, each of which corresponds to a received offer. Each record stores an offer identifier 7948 that (i) uniquely identifies an offer, (ii) corresponds to one of the offer identifiers 7674 of the borrower database 7534 of Figure 76, and (iii) corresponds to one of the offer identifiers 7816 in the offer database 7538 of Figure 78. For each offer, there is also stored a credit report identifier 7950 that is generated by the central controller 7412 (Figure 74) and uniquely identifies the results of a credit check or other evaluation of a borrower who submitted the corresponding offer. A credit score 7952 defines the results of that evaluation.

Referring to Figure 80, the collateral database 7542 of Figures 75a and 75b stores exemplary records 8060,8062,8064 and 8066, each of which corresponds to a received offer. Each record stores an offer identifier 8068 that uniquely identifies an offer and corresponds to the offer identifiers described above in connection with Figures 76,78 and 79. For

each offer, there is also stored the type 8070 of collateral, a description 8072 of the collateral and a value 8074 of the collateral.

Referring to Figure 81a, the response database 7544 of Figure 75a stores exemplary records 8180 and 8182, each of which corresponds to a received response to an offer. Each record stores an offer identifier 8184 that uniquely identifies an offer and corresponds to the offer identifiers described above in connection with Figures 76,78,79 and 80. Each record also stores a response identifier 8186 that uniquely identifies each received response, a lender identity 8188, and conditions of the loan that the lender is willing to provide, such as a loan amount 8190, a periodic payment amount 8192, a loan term 8194 and a loan interest rate 8196. The time 8198 and date 8200 of the response are also stored in the response database 7544.

Referring to Figure 81b, the rule database 7564 of Figure 75b stores exemplary records 8212 and 8214, each of which corresponds to a rule defining criteria for when a lender will accept an offer. Each record stores a rule identifier 8216 that uniquely identifies a rule, a lender identity 8218 identifying the lender who accepts offers satisfying the rule and rule restrictions 8220 which specify the criteria for accepting an offer.

Figures 82a and 82b illustrate a method 8230 for processing sales of a loan between a borrower terminal and one or more lender terminals. The illustrated method 8230 is performed by the central controller 7530 of the embodiment of Figure 75a, in which accepting an offer includes receiving acceptance signals from lender terminals. The central controller receives from the borrower terminal an offer signal (step 8232). As described above, the offer signal

includes at least one condition signal, and the offer signal thereby defines an offer having at least one condition from a borrower.

A payment identifier signal is received from the borrower terminal (step 8234). The payment identifier signal, such as a credit card number or checking account number, specifies an account from which funds may be paid.

The central controller validates the payment identifier signal (step 8236). The payment identifier signal may be validated by freezing an amount of funds in the account or otherwise making the funds unavailable to the borrower and thereby ensuring that such funds remain available to an accepting seller. If the payment identifier signal is not valid, the borrower terminal is requested to retransmit the offer and payment identifier signal (step 8238). The central controller also validates the received offer signal (step 8240), thereby determining whether the received offer signal meets predetermined validation criteria.

If the offer signal does not meet the predetermined validation criteria, the borrower terminal is requested to retransmit the offer and payment identifier (step 8238).

Validation typically comprises performing a financial calculation to determine whether the received offer signal defines a meaningful offer. For example, if an offer signal includes a loan amount, interest rate, loan period and monthly payment amount, a financial calculation can determine whether the specified offer is meaningful. Financial calculations are known, and described in Chapter Three of "Principles of Corporate Finance, Fourth Edition", by Richard A. Brealey and Stewart C. Myers, incorporated herein by reference as part of the present disclosure.

The central controller also requests and receives an

informational signal including credit information from a third party (step 8242). The informational signal may further include other information relevant to the offer, such as an appraisal value of collateral offered by the borrower. As described above, more than a single third party may supply desired informational signals to the central controller.

The central controller then transmits the offer signal and the informational signal (s) to one or more lender terminals (step 8244). The central controller in turn receives, from at least one of the lender terminals, one or more acceptance signals responsive to the transmitted offer signal and informational signal (step 8246). One of the acceptance signals is selected (step 8248), and the corresponding lender terminal is identified (step 8250). The borrower is thereby bound to the identified lender under the terms and conditions of the offer. If the borrower later reneges by not abiding by the terms of the offer (step 8252), use of the payment identifier signal is initiated in order to collect the funds (step 8254). For example, the central controller may collect the funds, or may transmit the payment identifier signal to the identified lender terminal, allowing the lender to directly collect the funds.

The step 8248 of selecting one acceptance signal may be performed in a number of ways. For example, the first received acceptance signal or a random one of the acceptance signals may be selected.

In still another embodiment, the acceptance signals may be sorted according to a predetermined sort criteria, such as sorted by lowest interest rate or lowest monthly payment amount. Selecting the first of the sorted acceptance signals would then provide the lowest interest rate or monthly payment, respectively. A number of"tie-breaking"methods may be used to select

one acceptance signal from a group of equally attractive acceptance signals.

It may also be desirable to allow the borrower to select the acceptance signal, and thus choose the lender. In such an embodiment, a plurality of lender signals is transmitted to the borrower. Each lender signal indicates a lender, which in turn corresponds to one of the plurality of acceptance signals. The borrower terminal then provides the central controller with a selection signal indicative of a selected lender signal. The selection signal thereby indicates a corresponding acceptance signal, which is selected.

Selection of an acceptance signal may also occur through a condition specified by the offer. For example, an offer may comprise condition signals indicative of a loan amount, a periodic payment amount and a request for a lowest interest rate. Thus, the acceptance signal indicating the lowest interest rate received within a predetermined time is selected.

Similarly, an offer may comprise condition signals indicative of a loan amount, an interest rate and a request for a lowest periodic payment amount. Such an offer may further comprise a condition signal indicative of a maximum loan period. Accordingly, the acceptance signal indicating the lowest periodic payment amount is selected.

Figure 82c illustrates another embodiment of a method 8260 for processing sales of a loan between a borrower terminal and one or more lender terminals.

The illustrated method 8260 is performed by the central controller 7560 of the embodiment of Figure 75b, in which accepting an offer includes comparing the offer signal with seller's rules, and determining whether the offer satisfies any of the rules.

As described above in connection with

Figures 82a and 82b, the central controller receives from the borrower terminal an offer signal (step 8262), and also receives a payment identifier signal (step 8264). The central controller validates the payment identifier signal (step 8266). If the payment identifier is not valid, the borrower terminal is requested to retransmit the offer and payment identifier (step 8268). The central controller also validates the received offer signal (step 8270), thereby determining whether the received offer signal meets predetermined validation criteria. If the offer is not meaningful, the borrower terminal is requested to retransmit the offer and payment identifier (step 8268). The central controller also requests and receives an informational signal including credit information from a third party (step 8272).

The central controller stores at least one rule signal from each of a plurality of sellers (step 8274). Each rule signal includes at least one seller- defined restriction. Some restrictions may involve offer conditions, while other restrictions may involve the informational signal. For example, a rule may include the restrictions that the loan amount must be less than $100,000 and the credit score must be greater than eighty. It will be understood by those skilled in the art that the step 8274 of storing the rule signals may occur either before or after the offer signal is received.

The offer signal and the informational signal are compared with at least one rule signal (step 8276).

If it is determined that the conditions of the offer and the informational signal satisfy each seller- defined restriction of any rule (step 8278), the corresponding lender is identified (step 8280). If more than one rule is satisfied, one rule is selected in accordance with any of the methods described above.

The borrower is thereby bound to the identified lender under the terms and conditions of the offer. If the borrower later reneges by not abiding by the terms of the offer (step 8282), use of the payment identifier signal is initiated in order to collect the funds (step 8284), as described above.

Those skilled in the art will recognize that the method and apparatus of the present invention has many applications, and that the present invention is not limited to the representative examples disclosed herein. Moreover, the scope of the present invention covers conventionally known variations and modifications to the system components described herein, as would be known by those skilled in the art.