WO2000013124A1

WO2000013124A1 - Apparatus and method for low fare searching in a computer network

Info

Publication number: WO2000013124A1
Application number: PCT/US1999/019837
Authority: WO
Inventors: John Bamforth; Fuad Ayyash; Yasuharu Tsuji; John Lewis
Original assignee: Sabre Inc.
Priority date: 1998-08-31
Filing date: 1999-08-30
Publication date: 2000-03-09
Also published as: AU5698799A

Abstract

A method and apparatus for performing low price searches in a computer network is presented. Search request data identifying a particular item is received at a processor. Availability information reflecting availability of a set of items in an inventory is then obtained, each item in the set corresponding to the particular item. After obtaining the information, it is ascertained whether the search request data includes a target price reflecting a user's price preference associated with the item. A determination is then made as to whether price information associated with each item in the set substantially satisfies the target price. After which, a selection of an item from the set is confirmed based on the determination.

Description

APPARATUS AND METHOD FOR LOW FARE SEARCHING IN A COMPUTER NETWORK Related Application

This application claims the benefit of U.S. Provisional Application No. 60/097,829, filed August 31, 1998, the disclosure of which is expressly incorporated herein by reference in its entirety. Technical Field

The present invention relates to the field of computerized reservation systems such as airline reservation systems used by airline ticket agents and travel agents. More particularly, the invention relates to a system and method for performing a low fare search in a computer-based network. Background Art

A computerized reservation system (CRS) provides a communications network for travel agents and other users to book airline reservations. Travel-related businesses and other companies may interface their computer systems with a CRS in order to make information concerning their services available via the CRS. For example, a hotel company may interface its reservation system with a CRS so that when a person books an airline reservation, he or she may also make a hotel reservation through the same network. The major computerized reservation systems currently in use throughout the world share a common heritage. They also have common business assumptions that were true nearly two decades ago. Examples of such reservation systems are known or referred to under the following trade names and service marks: SABRE; AMADEUS; WORLDSPAN; SYSTEM ONE; APOLLO; GEMINI; GALILEO; and AXESS. Under these systems, a customer chooses an itinerary, based on their desired travel dates and times, and books the itinerary through the CRS. A pricing system then computes a price for this itinerary. Pricing systems typically allow a user to vary their selection based on the class of service, thus enabling a user to select the cheapest fare for a fixed itinerary. This was ideal prior to airline deregulation and still works well for certain business travelers. The conventional systems, however, suffer from a number of limitations and drawbacks that are related to a number of factors. These factors include the increase in the number of options available to travelers, the daily changes in flight fares, and the various restrictions that may apply to certain fares. For example, thousands of separate fare changes are made and published every day for flights in the United

States. Only some of those fares are reflected in the existing CRS's. Often, when a travel agent or user requests the lowest fare itinerary, many of the returned fares are accompanied by a message that indicates that the fare shown on the screen is subject to restrictions or changes that are not checked automatically. The travel agent or user must then decide whether or not the fare is valid based on certain rules. If the fare is not valid, the travel agent or user must display the fares and the rules for each fare, or look at the most recent rulebook available at the time and hope that the information there still holds. In certain cases, the travel agent may need to telephone the particular airline or airlines to check each fare. This problem is compounded when the travel agent or user seeks to investigate the trade-offs between several different itineraries. For example, the trade-offs between the cost of the travel in terms of ticket price, travel time, and convenience. This makes it difficult to find the best value for a particular itinerary, while at the same time increasing the time it takes to arrange a particular trip. Accordingly, there is presently a need exists for a system or process for efficiently finding the lowest fare through a network environment. There is also a need for an automated system or process for identifying and arranging an itinerary for any given traveler's needs.

Disclosure of the Invention A method consistent with the present invention provides for low price searching. In this method search request data identifying a particular item is received at a processor. Availability information reflecting availability of a set of items in an inventory is then obtained, each item in the set corresponding to the particular item. After obtaining the information, it is ascertained whether the search request data includes a target price reflecting a user's price preference associated with the item. A determination is then made as to whether price information associated with each item in the set substantially satisfies the target price. After which, a selection of an item from the set is confirmed based on the determination.

An apparatus consistent with the present invention performs low price searching. The apparatus receives search request data identifying a particular item. Availability information reflecting availability of a set of items in an inventory is then obtained, each item in the set corresponding to the particular item. After obtaining the information, it is ascertained whether the search request data includes a target price reflecting a user's price preference associated with the item. A determination is then made as to whether price information associated with each item in the set substantially satisfies the target price. After which, a selection of an item from the set is confirmed based on the determination.

Brief Description of The Drawings The accompanying drawings are incorporated in and constitute a part of this specification and, together with the description, explain the advantages and principles of the invention. In the drawings,

FIG. 1 is a diagram of an exemplary computer network environment in which the features and aspects of the present invention may be implemented;

FIG. 2 is a diagram of an exemplary computer network in which the broker of the present invention may be implemented; FIG. 3 is an exemplary flow chart consistent with the low fare search method of the present invention;

FIG. 4 is an exemplary flow chart of a process for selecting the type of low fare search, in accordance with an aspect of the invention;

FIG. 5 is an exemplary flow chart consistent with the shopper/looker processing of the present invention; and

FIG. 6 is an exemplary flow chart consistent with the booker processing of the present invention.

Detailed Description The following detailed description of the invention refers to the accompanying drawings. While the description includes exemplary embodiments, other embodiments are possible, and changes may be made to the embodiments described without departing from the spirit and scope of the invention. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims and their equivalents.

The search technique of the present invention provides for efficient searches for low fares in a computer network. Search request data is sent from a client system to a broker. If the search request data includes a target price, then the broker performs a booking operation. The booking operation books a reservation for a customer if search response data received by the broker from a host system is not greater than the target price. This target price is supplied by the customer. If the search request data does not include a target price, then the broker performs a shopper operation. The shopper operation returns an output message with low fare information to the client system without booking a reservation.

FIG. 1 is a diagram of a network environment 100 including one or more CRS's. CRS's are networks permitting access to, for example, travel-related information for making reservations or obtaining such information. CRS's may use and provide other types of information, depending upon the computer systems interfaced with a particular CRS or the information accessible by the CRS. CRS's are commonly referred to as computer reservation systems or central reservation systems. In European countries, for example, CRS's are often referred to as global distribution systems. The term "computerized reservation system" and the abbreviation "CRS" are intended to encompass computerized reservation systems, computer reservation systems, central reservation systems, and global distribution systems. Examples of CRS's include those known by the following trade names and service marks: SABRE; AMADEUS; WORLDSPAN; SYSTEM ONE; APOLLO; GEMINI; GALILEO; and AXESS.

Network environment 100 illustrates an architecture for customers or service providers to link together through computerized reservation systems, such as CRS 112 or 126. For example, customer machines 101 and 102 may represent machines located at a particular business or other entity for providing travel-related and other services for that business or entity. Customer machines 101 and 102 are typically interfaced through a frame relay 103 and a router 104 to a server machine 105. Router 104 provides for routing of a protocol over frame relay 103 for long distance communication. Server machine 105 provides necessary interaction between the ultimate customer machines and a CRS, for example, CRS 126.

Server machine 105 is typically interfaced through a universal data router (UDR) 106 to a network 110. UDR 106 may include several servers, as explained below, for performing data conversion for server 105 to communicate with a CRS, for example, CRS 126. Network 110 may represent a telephony network such as the Societe Internationale Telecommunications Aeronautiques (SIT A) network. Network 110 interfaces UDR 106 with a front end processor 111, which provides an interface to a CRS 112. A CRS usually includes a front end processor, which are known mainframe components, providing functionality for interfacing the CRS with a network. Customer machines 101 and 102 may also be interfaced with other CRS's through UDR 106. Therefore, when a person at customer machine 101 or 102 desires to, for example, book a travel-related reservation or access other types of information, a communications link is established through the various elements between the customer machine and CRS 112 or 126. CRS 112 may also be connected to a client system 117 through a broker 116. These units are explained in more detail in conjunction with FIG. 2.

In addition, network 110 may interface travel agent machines 114 and 115 with CRS 112 or 126. In particular, network 110 may interface a local area network

(LAN) 113 connected to travel agent machines 114 and 115. Travel agent machines 114 and 115, if located overseas, may also be linked into CRS 112 or 126. In such a case, network 110 may interface token ring LAN 113 through an international telephone or computer network (not shown). Other companies or service providers may also provide information available via CRS 112. Such information may be provided, for example, by interfacing service provider machines or other computer systems 124 and 125 through UDR 120 to front end processor 111. UDR 120, which may include several servers, provides data conversion to interface the service provider machines 124 and 125 in accordance with the protocol used by CRS 112. Alternatively, service provide machines 124 and 125 may interface with UDR 106 and/or CRS 126. FIG. 2 is a diagram of a computer network 200 in which the present invention may be implemented. Host 201 can be configured as a CRS similar to those described above with reference to FIG. 1. For example, host 201 can be implemented by any of a number of different types of CRS's including a SABRE Host, or any of the other aforementioned CRS types. Host 201 is connected to broker 202 through a link that is preferably compliant with a known protocol, such as the TCP/IP protocol. Broker 202 can be implemented using a server machine equipped with a Pentium II processor from Intel Corporation, RAM, hard drives, and a network card such as the Ethernet 10/100 LAN card. Broker 202 also includes operating system and software, including at least Microsoft NT Server Version 4.0,

Microsoft Service Pack Version 3.0, and DATABAHN™ Version 1.0. The broker 202 is capable of sending requests to the Host 201 in multiple sessions that can be substantially simultaneous. Sending multiple requests in substantially simultaneous sessions is known in the art. As further described below, broker 202 can be implemented with the low fare search function and other features and aspects of the present invention.

Broker 202 is connected to client system 203 through a link that is preferably compliant with a known protocol, such as the TCP/IP protocol. Client system 203 is a system for entering low fare search request data to be used by broker 202 to perform a low fare search. One example of a possible client system is the Gallery

System available from Cendant. Client system 203 is also connected to a database 205 for shipping products and a membership system 204. Users 208, 209, 210 can access client system 203 through session management tool 206 or through the Internet 207. Session management tool 206 is a known tool that manages the access of multiple users to a central system via time-sharing. Users 208, 209, 210 can be customers, travel agents, and the like.

FIG. 3 is an exemplary flowchart of the processes and operation that occur between client system 203, broker 202, and host 201, in accordance with various aspects of the invention. A customer enters travel plan data using a graphical user interface, web-based mask, or other user interface. The travel plan data may comprise basic flight request data (e.g., origin / destination city pair codes, departure/return date and time, preferred carrier codes, etc.) and other travel data. The customer sends this data to client system 203, where the travel plan data is converted into low fare search request data. The client system 203 sends the low fare search request data to the broker 202 (step 305). An example of the manner and format by which client system 203 sends the data to broker 202 is described below.

The broker 202 initializes various tables and variables that will be needed, receives the request data, parses and verifies the data, and checks for errors (step 310). If the broker 202 determines that the received data is not valid (step 315), then an appropriate error message is sent to the client system (step 320). An example of request data that is considered invalid occurs when a customer enters an invalid number of passengers or an invalid class of service. After being notified that the request data is invalid (step 315), the customer must re-enter the data (step 320), so that the corrected request data can be sent to the broker 202.

If the broker 202 determines that the received data is valid (step 315), then the broker builds low fare search requests in a format that is appropriate for the particular type of host 201 that is being utilized (step 330). Multiple search requests are built because the search technique of the present invention requires that the lowest fare be found in several different respects (i.e. lowest available fare, lowest published fare). In this manner, the customer will be provided with more data to allow for an informed decision. The broker 202 builds these requests using known methods. The search requests could be, for example, built using the functionality of the DATABAHN™ application or similar applications. In general, DATABAHN™ is an application in which there is a translation from search request data in an input data format (i.e., SDS) to a format that is understood by a CRS. Translation from the CRS format to an output data format (i.e., SDS) also occurs. After creating and initializing multiple sessions with the host 201, and opening a connection to the host, the broker 202 sends the low fare search requests to the host 201 (step 335). Generally, one session is associated with one request. So, if there are three requests, then there would be three sessions. After receiving the search requests, the host 201 processes the requests and returns the relevant search data (step 340). The broker 202 then verifies the search data (step 345), extracts the relevant lowest fare search data and stores lowest fare search data in a table for processing (step 350).

After storing the data, the broker 202 sorts or filters the lowest fare search data (step 355). For example, broker 202 might sort the data from lowest to highest total fare price. The broker 202 then constructs an output message (step 360) and sends the output message to the client 203 along with any other responses received from the host 201 in a multi-message format. The functionality of the DATABAHN™ application or similar applications can be used to send the responses in the appropriate format. FIG. 4 is an exemplary flowchart depicting various operations and processes performed by broker 202 in accordance with the features of the present invention. Broker 202 receives request data from the client system 203 in accordance with the process depicted in FIG. 3 (step 405). When entering data into the client system 203 to send to the broker 202, the customer may have the option of designating either an information only request or a tentative booking request. Generally, a customer makes the choice by either specifying a target price or not specifying a target price. If a target price is set, then a tentative booking request is made. If a target price has not been set, then an information only request has been made. If an information only request has been chosen by the customer (step 410), then the broker 202 starts to perform a shopping operation (step 415). The shopping operation might be preferable to a customer who is not certain of their travel plans or does not wish to make reservations, but merely wants to see the going rates and/or to estimate travel expenses. If, on the other hand, a tentative booking request is sent to the broker 202 (step 410), then the broker will proceed to perform a booking operation (step 420). It is called a tentative booking request because even after a booking has been made, there needs to be a confirmation of the booking at a later time, perhaps with some form of payment. Once confirmation has been received, a booking can become permanent.

FIG. 5 is an exemplary flowchart depicting the various processes and operations of the shopper operation of the present invention. After it has been determined that there is an information only request, the broker 202 examines the low fare search request data (step 505). As part of the request data from the client system 203, broker 202 may receive the following data so that it can properly generate a response: departure date; departure time; return date; return time; departure city; return city; direct/non-stop indicator; number of passengers; class of service; carrier code client; carrier code customer; passenger type. Of the above listed data, departure date, departure city, and return city are data that may be minimally required for processing of the request to be properly completed. The other data may be optional. This request data may be sent to the broker 202 in a particular format, such as the Sabre Data Stream (SDS) format. Once the request data has been examined, a determination is made as to whether or not the customer specified a preferred carrier (step 510). If the customer did not specify a carrier (step 510), then the broker 202 builds a search request to find the lowest available fare without identifying a preferred carrier and sends the request to the host 201 (step 515). The host 201 processes the request and returns the search data back to the broker 202 in accordance with the features of FIG. 3.

The broker 202 can also build a search request to find the lowest available fare using the client's preferred carriers (step 520). For example, the client that is providing the client system 203 might have a pre-arranged deal with several airlines. The client would probably prefer the customer to use the airline with which business is usually done. This request is also sent to the host 201, where it is processed (step

520). The broker then builds a search request to find the lowest published fare and sends the request to the host 201 (step 525). Generally, the lowest published fare is determined by the broker 202 by first identifying the lowest fare in the data received from the host 201 that is validated against the service available. For example, if a low fare is displayed, but the header information indicates that the carrier has no service in the market, the fare would be eliminated. The elimination of fares decreases the amount of time spent trying to find the lowest fare. Next, based on biasing the system for the client's preferred carriers, the lowest fare is identified and determined for the travel dates and city pairs specified in the request data. Once identified, the travel restrictions (i.e., rules) for the lowest fare will be cached for messaging back to the client system. In that manner, the lowest published fare is found. It should be understood that although FIG. 5 shows the various search requests being processed in a sequential manner, at least some of these requests can be processed and sent to the Host 201 substantially simultaneously utilizing multiple sessions. After receiving all of the requested search data from the host 201 , the broker

202 processes the data in accordance with the features of FIG. 3 and then sends an output message back to the client 203 (step 530). The message may include the lowest available fare that was found when using no carrier designation, the lowest available fare that was found when using the client's preferred carriers, and the lowest published fare that was found. Along with each of the fares, the corresponding rules for each fare are sent. Rules are carrier defined conditions that go along with a particular fare. For example, a fare might only be valid if made two weeks in advance of the departure date. The message sent to the client 203 from the broker 202 is generally known as a message definition record (MDR) and is preferably sent using the SDS format, which is further explained below.

If the customer has specified a preferred carrier (step 510), then processing is different. The broker 202 builds a search request to find the lowest available fare without identifying a preferred carrier and sends this request to the host 201 (step 535). Then, the broker 202 builds a search request to find the lowest available fare using the client's preferred carriers and sends that request to host 201 also (step

540). During these steps, the host 201 is still operating normally (i.e., processing the requests and returning search data). Once the broker 202 has received both sets of search data from the host 201, the broker compares the lowest fare using no carrier with the lowest fare using the client's carriers and selects the lowest of the fares (step 545). The client can specify multiple carriers, so this comparison can be between more than two fares. The broker 202 then builds a search request to find the lowest available fare using the customer's preferred carriers and sends the request to the host 201 (step 550). The last request to get built and sent to the host 201 is to find the lowest published fare (step 555). After receiving all of the requested search data from the host 201, the broker 202 processes the data in accordance with the features of FIG. 3, and then sends an output message back to the client 203 (step 560). The message may include the lowest available fare that was found when using the customer's preferred carriers, the lowest of the fares from the comparison between the fare with no carrier and the fares of the client's carriers, and the lowest published fare that was found. Along with each of the fares, the corresponding rules for each fare are sent. The message sent to the client 203 from the broker 202 is sent using the SDS format. It should be understood that although FIG. 5 shows the various search requests being processed in a sequential manner, at least some of these requests can be processed and sent to the Host 201 substantially simultaneously utilizing multiple sessions. FIG. 6 is an exemplary flowchart of the various processes and operations for performing the booking operation, in accordance with the present invention. After it has been determined that there is a tentative booking request, the broker 202 examines the low fare search request data (step 605). As part of the request data from the client system 203, the broker 202 may receive one or more of the following data so that it can properly generate a response: departure date; departure time; return date; return time; departure city; return city; direct/non-stop indicator; number of passengers; class of service; carrier code client; carrier code customer; adjustment for departure; adjustment for return; passenger type; member source; member number; e-mail address; target price; passenger last name; passenger first name; mailing address; city; state; zip code; home phone; work phone; market code; agent sine; ticketing time limit; and customer number. Of the above listed data, departure time, return date, return time, direct/non-stop indicator, carrier code customer, adjustment for departure, adjustment for return, passenger type, and e-mail address may be optional data and all other data may be mandatory. The adjustments for departure and return are of particular interest. This data allows the customer to indicate that he or she is flexible with respect to when he or she departs or returns. The broker 202 performs searches for low fare data with respect to this flexibility, thereby giving the customer a better chance of finding a fare that meets the target price. Member source and member number are for users that belong to certain organizations that might make them eligible for special rates. Market code is an identification of the pertinent market being dealt with. Agent sine is an identification of an agent that may be using the system.

Once the request data has been examined, a determination is made as to whether or not the customer specified a preferred carrier (step 610). If the customer did not specify a carrier (step 610), then the broker 202 builds a search request to find the lowest available fare without identifying a preferred carrier and sends this request to the host 201 (step 615). Then, the broker 202 builds a search request to find the lowest available fare using the client's preferred carriers and sends that request to host 201 (step 620). Once the broker 202 has received both sets of search data from the host 201 , the broker compares the lowest fare using no carrier with the lowest fare using the client's carriers and selects the lowest of the fares (step 625). If the lowest fare from the comparison is not greater than the target price specified by the customer (step 635), then the broker 202 builds a passenger name record (PNR) and sends it to the client 203. Building a passenger name record is an indication that a tentative booking has occurred.

If the lowest fare from the comparison is greater than the target price (step 635), then the broker builds a search request to find the lowest published fare and sends the request to the host 201 (step 640). After receiving all of the requested search data from the host 201, the broker 202 processes the data in accordance with the features of FIG. 3, and then sends an output message back to the client 203

(step 645). The message may include the lowest available fare that was found when using no carrier designation, the lowest available fare that was found when using the client's preferred carriers, and the lowest published fare that was found. Along with each of the fares, the corresponding rules for each fare may be sent. It should be understood that although FIG. 6 shows the various search requests being processed in a sequential manner, at least some of these requests can be processed and sent to the Host 201 substantially simultaneously utilizing multiple sessions.

If the customer did specify a preferred carrier (step 610), then processing proceeds in a different manner. First, the broker 202 builds a search request to find the lowest available fare using the customer's preferred carriers and sends the request to the host 201 (step 650). After, the broker 202 has received the search data from the host 201, the lowest available fare is compared to the target price

(step 655). If the lowest fare is not greater than the target price (step 655), then the broker 202 builds a PNR and sends it to the client 203 (step 660).

If the lowest fare is greater than the target price (step 655), then the broker 202 builds a search request to find the lowest available fare without identifying a preferred carrier and sends this request to the host 201 (step 665). Then, the broker 202 builds a search request to find the lowest available fare using the client's preferred carriers and sends that request to host (step 670). Once the broker 202 has received both sets of search data from the host 201, the broker compares the lowest fare using no carrier with the lowest fare using the client's carriers and selects the lowest of the fares (step 675). The last request to get built and sent to the host 201 is to find the lowest published fare (step 680). After receiving all of the requested search data from the host 201, the broker 202 processes the data in accordance with the features of FIG. 3 and then sends an output message back to the client 203 (step 685). The message may include the lowest available fare that was found when using the customer's preferred carriers, the lowest of the fares from the comparison between the fare with no carrier and the fares of the client's carriers, and the lowest published fare that was found. Along with each of the fares, the corresponding rules for each fare may be sent. The message sent to the client 203 from the broker 202 is preferably sent using the SDS format. It should be understood that although FIG. 6 shows the various search requests being processed in a sequential manner, at least some of these requests can be processed and sent to the Host 201 substantially simultaneously utilizing multiple sessions.

The processing of the broker 202 described above is not limited to the specific methods disclosed above. For example, in addition to finding the lowest available fare and the lowest published fare, the broker 202 can identify the lowest applicable fare based on the specified travel dates and city pairs, and send this information back to the client system. The lowest applicable fare is generally the lowest fare that meets the customer's needs that is not necessarily bookable (i.e., available) at the time. This information is useful to the customer because a lowest applicable fare could be lower than a lowest available fare. If that is the case, then a customer might want to wait until the lower fare became available before actually making travel arrangements.

While the present invention has been described in connection with a preferred embodiment, many modifications will be readily apparent to those skilled in the art, and this application is intended to cover any adaptations or variations thereof. This invention should be limited only by the claims and equivalents thereof.

Claims

WHAT IS CLAIMED IS:

1. A method for low price searching comprising the steps, performed by a processor, of: a) receiving search request data identifying a particular item; b) obtaining availability information reflecting availability of a set of items in an inventory, each item in the set corresponding to the particular item; c) ascertaining whether the search request data includes a target price reflecting a user's price preference associated with the item; d) determining whether price information associated with each item in the set substantially satisfies the target price; and e) confirming a selection of an item from the set based on the determination.

2. The method of claim 1, further comprising: bypassing steps c) through e) based on a determination that the search request data does not include a target price.

3. The method of claim 1 , wherein said particular item is a travel itinerary.

4. The method of claim 1, wherein the search request data indicates flexibility in departure and/or return date.

5. The method of claim 1, wherein the search request data is entered by a customer on a user interface.

6. The method of claim 5, wherein the user interface is web-based.

7. The method of claim 1 , wherein the search request data includes a customer's preferred carriers and/or a client's preferred carriers.

8. The method of claim 1, wherein the obtaining step further comprises: building search requests based on said search request data; and sending search requests to a host system, wherein the availability information is received from the host system in response to the search requests.

9. The method of claim 8, wherein said search requests are sent to the host system in multiple sessions that occur substantially simultaneously.

10. The method of claim 1, wherein the confirming step further comprises: booking a reservation if the price information is not greater than the target price.

11. The method of claim 10, wherein the booking step comprises building a passenger name record (PNR).

12. An apparatus for low price searching comprising: means for receiving search request data identifying a particular item; means for obtaining availability information reflecting availability of a set of items in an inventory, each item in the set corresponding to the particular item; means for ascertaining whether the search request data includes a target price reflecting a user's price preference associated with the item; means for determining whether price information associated with each item in the set substantially satisfies the target price; and means for confirming a selection of an item from the set based on the determination.

13. The apparatus of claim 12, wherein said particular item is a travel itinerary.

14. The apparatus of claim 12, wherein the search request data indicates flexibility in departure and/or return date.

15. The apparatus of claim 12, wherein the search request data is entered by a customer on a user interface.

16. The apparatus of claim 15, wherein the user interface is web-based.

17. The apparatus of claim 12, wherein the search request data includes a customer's preferred carriers and/or a client's preferred carriers.

18. The apparatus of claim 12, wherein the means for obtaining further comprises: means for building search requests based on said search request data; and means for sending search requests to a host system, wherein the availability information is received from the host system in response to the search requests.

19. The apparatus of claim 18, wherein said search requests are sent to the host system in multiple sessions that occur substantially simultaneously.

20. The apparatus of claim 12, wherein the means for confirming further comprises: means for booking a reservation if the price information is not greater than the target price.

21. The apparatus of claim 20, wherein the means for booking builds a passenger name record (PNR).